Things Of Which I Am Unfond

This could be a very long list, but no worries, I’m limiting it to one topic only. The xfs file system on USB on the Odroid XU4 under Armbian. Yeah, that specific.

I’ve been running the Odroid XU4 from a hard disk for quite a while. Some many weeks (months?) ago I decided to try an upgrade on the O/S, so unmounted the disk partitions and did the upgrade to the underlying micro_SD card file system. By mounting a “real disk” partition on top of the underlying SD file system, I have an automatic backup copy of the system should it suddenly fail. Just change /etc/fstab to NOT mount the partition on top of the SD card and boot. Or, in this case, update the SD card and if IT fails, reboot with the partions mounted on top and then fix things.

Well, OK, the update / upgrade seems to be working fine and I figure it’s time to put those partitions back in service

I change the mount point to the /{diskname}/{partition_name} convention I use for mounting partitions to work on things, and they won’t mount. What the? I try a reboot. I try xfs_repair and a reboot. Syslog tells me “no joy”:

Aug 8 10:08:05 localhost kernel: [ 224.679625] XFS (sda3): Corruption warning: Metadata has LSN (23:2837) ahead of current LSN (1:2). Please unmount and run xfs_repair (>= v4.3) to resolve.
Aug 8 10:09:21 localhost kernel: [ 300.531145] XFS (sda3): Corruption warning: Metadata has LSN (23:2837) ahead of current LSN (1:2). Please unmount and run xfs_repair (>= v4.3) to resolve.
Aug 8 10:22:18 localhost kernel: [ 18.012409] XFS (sda3): Corruption warning: Metadata has LSN (23:2837) ahead of current LSN (1:2). Please unmount and run xfs_repair (>= v4.3) to resolve.
Aug 8 10:22:18 localhost kernel: [ 19.502599] XFS (sda6): Corruption warning: Metadata has LSN (1:5353) ahead of current LSN (1:2). Please unmount and run xfs_repair (>= v4.3) to resolve.
Aug 8 10:22:18 localhost kernel: [ 19.811226] XFS (sda7): Corruption warning: Metadata has LSN (8:2200) ahead of current LSN (1:2). Please unmount and run xfs_repair (>= v4.3) to resolve.
Aug 8 10:22:18 localhost kernel: [ 20.057739] XFS (sda8): Corruption warning: Metadata has LSN (1:784) ahead of current LSN (1:2). Please unmount and run xfs_repair (>= v4.3) to resolve.
Aug 8 10:22:18 localhost kernel: [ 20.326325] XFS (sda9): Corruption warning: Metadata has LSN (1:1618) ahead of current LSN (1:2). Please unmount and run xfs_repair (>= v4.3) to resolve.
Aug 8 10:22:18 localhost kernel: [ 20.579840] XFS (sda10): Corruption warning: Metadata has LSN (1:1688) ahead of current LSN (1:2). Please unmount and run xfs_repair (>= v4.3) to resolve.
Aug 8 10:22:18 localhost kernel: [ 20.816638] XFS (sda11): Corruption warning: Metadata has LSN (1:9391) ahead of current LSN (1:2). Please unmount and run xfs_repair (>= v4.3) to resolve.

But I RAN xfs_repair… and I had just done an update / upgrade on the system so it IS the newest… isn’t it?

root@odroidxu4:/# xfs_repair -V 
xfs_repair version 3.2.1


So to “fix” whatever is wrong I need “v4.3” or newer, and the newest I’ve got is v3.2.1 and no newer. I.E. I’m screwed on that approach.

It also looks like the USB 3.0 (or how it interacts with xfs file systems) is still not quite right. It works, but it was very slow. I moved the USB 3.0 disk (on which swap, /tmp, and my home directory live) to the USB 2.0 hub plugged into the USB 2.0 port and things are FASTER. Sigh.

At one time, the Systems Programmers who worked on the file systems were extraordinarily careful and always assured 2 things:

1) They worked absolutely reliably and efficiently (even if there were limitations on what they could do).
2) The tools to “fix it” were always in sync with the file system.

Furthermore, any, and I do mean ANY, incompatible release of the file system was given a new number (and sometimes a whole new name).

Well, we know that has failed on the ext file systems, where ext4 has two mutually incompatible versions and moving a file system on USB drive (or SD card) to a system running the “newer” version will silently and indelibly mark it / change it such that it can no longer work on the “older” version. VERY painful for folks with several systems and a disk that moves between them (as not all systems can or ought to upgrade at the same time).

That was the reason I first “back leveled” all the ext4 file systems that might move between systems to ext3; then later, started slowly converting them to xfs file systems as that was shown to be reliable and relatively stable.

Now this pops up on xfs.

Now I’m pretty darned sure that ALL those partitions did not just suddenly “corrupt” at the same time all on their own. To me, it sure smells like some kind of incompatible upgrade silently blocking things. The /tmp file system and the place my home-dir lives on this machine are both working from that disk, so why that’s the case is also a bit unclear. I think I just did a reformat on /tmp long long ago as, well, it was just temp space. The home dir on that disk gets mounted on lots of other systems so might well have been “marked new” somewhere else or “fixed” with a newer xfs_progs on some other system. Minor things like running fsck or xfs_repair are not high on my “must remember for months” list…

Is this a catastrophe?

No, not at all. These are all file systems where I wanted to mount them to overwrite them with the newer version from the SD card upgrade anyway. On the list from /etc/fstab below, the ntfs partition works fine, as does swap. I’ve mentioned that /tmp and the SG2_home partition are working fine too. What’s not working fine? var, lib, usr, root, bin, sbin, etc. All “system partitions” with parts of the name space on them so that high read/write activity would be to/from real disk and not ‘wear’ the micro-SD card.

LABEL=SG2_ntfs		/SG2/ms		ntfs	defaults,noauto,noatime
LABEL=SG2_swap		swap		swap	sw,pri=128,defaults
LABEL=SG2_var		/SG2/var	xfs	defaults		0 2
LABEL=SG2_tmp		/tmp		xfs	defaults,noatime	0 1
LABEL=SG2_lib		/SG2/lib	xfs	defaults		0 3
LABEL=SG2_usr		/SG2/usr	xfs	defaults		0 3
LABEL=SG2_root		/SG2/root	xfs	defaults		0 4
LABEL=SG2_bin		/SG2/bin	xfs	defaults		0 4
LABEL=SG2_sbin		/SG2/sbin	xfs	defaults		0 4
LABEL=SG2_etc		/SG2/etc	xfs	defaults		0 4
LABEL=SG2_home		/SG2/xfs	xfs	defaults,noatime	0 5

Easy enough to just reformat them, then copy stuff over… Except that I usually like to look over the “old” versions to make sure there isn’t something I’ve install on it that I forgot to put on the newer one, or something (like /etc/fstab) where I’ve updated it for changes to some other disk and didn’t do this copy. I ran into that on another disk (the one used with the Pi M3 as system home dir space) where this SD card image /etc/fstab still thought those paritions were ext3 instead of xfs. Oddly, that disk had all the xfs partitions work but only after running xfs_repair on them. One now wonders (and hopes) if it will still “boot fine” on the Pi M3…

I think that, first, I’ll just try a simple reboot with those /SG2 partitions “made live” and see if it is just fine running on those old versions. That would tend to confirm there’s no actual file system damage, just incompatibility.

In Conclusion

So not exactly the end of the world as we know it. Really a very minor issue mostly having to do with what path I take to copy stuff to the disk partitions (mount / inspect / erase / copy vs format / mount / copy) BUT:

Really? They can’t keep THE SAME FILE SYSTEM consistent across minor releases? They make INCOMPATIBLE upgrades ASSUMING that the whole system “goes when it goes” and NO DISK EVER is movable between systems?


File Systems are things you do NOT “improve” for years at a time, just bug fix. Then, when a new and anything less than 100% forward AND BACKWARDs compatible release is made you give it a whole new number and issue warnings and caveats.

This is the kind of stuff that causes Systems Admins to abandon a given provider. I’ve already abandoned ext4 and will not use it (other than for the initial build / boot space where the installer chooses for you, it is hard to change, and it will not be moving between systems sort of by definition…). I’ll wait for ext5 first.

I thought I had a nice stable solution in xfs. IF this works when booted on the old partitions (with old xfs code) OR if any other similar “looks like incompatible versions” event gets in my grill, well, it’s pretty darned easy to just move things back to ext3 and not worry about it.Since nobody is “screwing around with” ext3 any longer, I have good confidence it will be stable for the next couple of years and not suddenly develop “new version syndrome”…

Subscribe to feed

About E.M.Smith

A technical managerial sort interested in things from Stonehenge to computer science. My present "hot buttons' are the mythology of Climate Change and ancient metrology; but things change...
This entry was posted in Tech Bits and tagged , , , , . Bookmark the permalink.

13 Responses to Things Of Which I Am Unfond

  1. E.M.Smith says:

    Well, not surprising but the attempt to reboot on those partitions fails due to the OS at boot time expecting the “newer” xfs layout prior to the mount command.

    OTOH, I’ve rebooted on the Pine RockPro64 Armbian Ubuntu as it is more likely to be THE newest stuff (since they had to do a lot of new porting work to get both 64 bit AND the newer chip set going and generally will not do that off back-level code absent some kid of necessity).

    Here, it looks like the xfs_repair is happy to “fix it”. Note that I’ve aliased xfs_repair to “fscx” as I hate typing long commands especially if full of – or _ chars:

    root@rockpro64:~# cat /usr/local/bin/fscx
    xfs_repair $*
    root@rockpro64:~# fscx /dev/sdc3
    Phase 1 - find and verify superblock...
    Phase 2 - using internal log
            - zero log...
            - scan filesystem freespace and inode maps...
            - found root inode chunk
    Phase 3 - for each AG...
            - scan and clear agi unlinked lists...
            - process known inodes and perform inode discovery...
            - agno = 0
            - agno = 1
            - agno = 2
            - agno = 3
            - process newly discovered inodes...
    Phase 4 - check for duplicate blocks...
            - setting up duplicate extent list...
            - check for inodes claiming duplicate blocks...
            - agno = 0
            - agno = 1
            - agno = 2
            - agno = 3
    Phase 5 - rebuild AG headers and trees...
            - reset superblock...
    Phase 6 - check inode connectivity...
            - resetting contents of realtime bitmap and summary inodes
            - traversing filesystem ...
            - traversal finished ...
            - moving disconnected inodes to lost+found ...
    Phase 7 - verify and correct link counts...
    Maximum metadata LSN (23:2837) is ahead of log (1:2).
    Format log to cycle 26.

    I THINK that “format log to cycle 26” is the fix to the broken bit… I’ll find out in a while after doing the same to all the other partitions and they swapping back to the Odroid Xu4.

    The version is certainly new enough:

    root@rockpro64:~# xfs_repair -V
    xfs_repair version 4.9.0

    So I’m pretty sure I have my path forward via “repair on RockPro64, return to XU4 / mount / inspect / delete / copy”…

    BUT it ought not to have required me to do this… Work past someone else’s stupidity with incompatibility issues…

    OTOH, this is a good example of how a Systems Programmer “flows around” problems.

  2. E.M.Smith says:

    And there it is. After doing the “repair” on all of the file systems, they now mount on the RockPro64, and I can almost certainly return the disk to the XU4 and have things mount / work again…

    /dev/sdc1         4194296    727116    3467180  18% /SG2/ms
    /dev/sdc3        20961280   9620848   11340432  46% /SG2/var
    /dev/sdc5         4184064     33024    4151040   1% /SG2/tmp
    /dev/sdc6         4184064    131956    4052108   4% /SG2/lib
    /dev/sdc7        12572672   1977192   10595480  16% /SG2/usr
    /dev/sdc8         1038336     33624    1004712   4% /SG2/root
    /dev/sdc9         1038336     39552     998784   4% /SG2/bin
    /dev/sdc10        1038336     42080     996256   5% /SG2/sbin
    /dev/sdc11        1038336     38044    1000292   4% /SG2/etc
    /dev/sdc12     1900148220  54925020 1845223200   3% /SG2/home

    This also, IMHO, pretty much confirms that there is just an upgrade to how “LSN” vs the Log works and that it is not compatible with the older xfs_repair program nor can things be mounted until the old file system is “brought up to date”.

    OK, Note To Self:

    As time permits and as systems are likely to change and / or disks that move between systems: Depricate the use of xfs on those disks and revert back to ext3 that “just works everywhere”…

    Since that’s most of my USB drives that are not on the file server, that’s most of my smaller (under 4 TB) drives. About 1/2 dozen and about 2 dozen file systems….

    This link confirms it is an incompatibility change:

    What happened here? Apparently, with the XFS v5 superblock the userspace tools (xfsprogs) also changed.

    And so it happened that xfs_repair version 3.2.1 tried to check an XFS file system that had already enabled its v5 superblock format. But the version is too old to handle v5 superblocks and left the file system in an corrupt state.

    So it is a “v5” change incompatibility…

    OK, I can cope with that.

    Step One:

    On ANY system where I’m going to do an upgrade, revert the file systems to ext3 in the process.

    Step 2:

    On ANY disk that moves between systems (i.e. pretty much ANY SD card, micro-SD card, or USB drive…) as time permits, revert the file systems to ext3 (OR, maybe, find some other more stable file system?)


    The “Dick With Factor” is high in them…

  3. E.M.Smith says:

    And here we are after a “reboot” on the XU4. I’d forgotten that I’d left the fstab set to overlay the (newer) micro_SD card directories with the USB disk partitions… but it worked fine. So not only do those partitions now mount (again) but they also clearly are working just fine too:

    chiefio@odroidxu4:~$ df
    Filesystem      1K-blocks      Used  Available Use% Mounted on
    udev                10240         0      10240   0% /dev
    tmpfs              204484       632     203852   1% /run
    /dev/mmcblk1p1   30335916   3222584   26775544  11% /
    tmpfs                5120         4       5116   1% /run/lock
    tmpfs             1461620         0    1461620   0% /run/shm
    /dev/sda5         4184064     37288    4146776   1% /tmp
    /dev/sda3        20961280   9642348   11318932  47% /var
    /dev/sda6         4184064    136212    4047852   4% /lib
    /dev/sda7        12572672   1989800   10582872  16% /usr
    /dev/sda8         1038336     34728    1003608   4% /root
    /dev/sda9         1038336     40656     997680   4% /bin
    /dev/sda10        1038336     43184     995152   5% /sbin
    /dev/sda11        1038336     39148     999188   4% /etc
    /dev/sda12     1900148220  56818568 1843329652   3% /SG2/xfs

    Now comes the “Great Fun” of deciding just which of them to turn back into ext3 and in what order as I get back to doing an upgrade of the partitions on this disk… Or maybe just deciding to leave things running from the SD card after all.

    It isn’t like it’s a big performance increase (it is faster on writes to USB disk, but the random read nation of the chip makes various reads damn fast, especially when you consider seeks from, say / bin to /usr to /var to /tmp and all)

    I’ll almost certainly keep /var and /tmp as Real Disk (ext3) since that saves SD card wear big time. But the others? They are almost “read only”… (part of the point behind /var was to move the things that are written off of places like /usr so it could be mounted read-only as a security feature – and I’ve made a compressed read-only version of /usr and run from it, just to test the ability).

    So, at this point, I’ve fixed the problem. Identified the root cause (mostly). Selected a longer term “avoid this ever again anywhere else” strategy (different file system likely ext3) and all that is left is the “slog” of moving data around.

    Well, it is what it is.

    So my plan had been to work from the XU4 for a while, and I’m still going to do that, but there will be “gaps” in my participation as I do things like reformat /usr into ext3 and reload it (or potential do an integration check between the chip version and the disk version, then dump / format / reload the data). I’m going to do /tmp right now as it is, frankly, trivial to do. No state is preserved across boots so it’ just comment out the mount in the fstab, reboot, format it as ext3, reactivate the mount in fstab, reboot. Maybe 10 minutes if I’m slow…

    But first I think I’ll make a cup-a caffeine and contemplate the issue of “which version of OS” files to keep. I’ve been running n the SD chip for longer than I’d originally expected and it is possible (likely?) I’ve got stuff in both versions I care about (or at least need to now to reinstall). For example, I’ve done a fair amount of the MariaDB / Python stuff using the chip based OS and I’m not sure all that got installed in the USB Disk partitions. My Bad for not addressing the “issue” when I first did the chip upgrade and then the on-disk versions were inaccessible. OTOH, it lied to me and claimed a corrupted disk when it was rally an incompatible file system upgrade, so it is ALMOST reasonable that I’d assume it was a bigger and badder issue and “set it aside” for a while.

    In any case, I’m at it now…

    So off to Caffeine and Contemplation land for determining “order of comparison and conversion”…

  4. Taz says:

    EXT3 was very rugged.
    NTFS was reliable too – even if it came from MS.

    Linux has too many file systems and not enough maintainers.

  5. Ossqss says:

    SP level stuff can be picky. You have it or don’t. Just sayin, similar to how Windows 7 is the end of the world for many in January. I am not an expert, just an observer without Holiday Inn Express experience. ;-)

  6. E.M.Smith says:


    Quite true. I’d add that it also has way too many “developers” and not enough QA & Bug Fixer Maintainers… and the “developers” are more interested in changing things than they are in assuring they work 100% (and don’t blow up in folks faces…).

    Too many who have forgotten the Unix Way of “Do one simple thing and do it very well”.


    IMHO the biggest problem isn’t how hard it is to do SysProg work, but how much folks love to throw in hundreds of options and “features” and generally turn everything into a Swiss Army Knife… which exponentially grows “issues” for regression testing and QA and also exponentially grows bugs and inverse-square or better reduces reliability and usability.

    This, also IMHO, shows up in the folks who just love EMACS. Why have an editor that’s just a reliable rock of an editor when you can turn it into damn near it’s own operating system and build environment? Similarly the FireFox folks who recently complained at me for my complaint that moving to a new language, new compiler backend (LLVM so whole new libraries) while adding “features” nobody really wanted or needed at a furious rate had made it into a Fat Pig that was becoming unusable (and already could not be built on anything without more than 4 GB of memory, 8 preferred). Their response? ~”Modern Browsers are like their own OS”… Like that’s a good thing.

    Heck, some manual pages that were about, well, one page long with maybe 5 flags are now 5 pages long with 100+ flags. By the time you read the manual page you forget what problem you were trying to solve anyway. (For example, just try to find out what all stuff you can / must set in SystemD to make your system work right – not even worrying about how to fix it when it is wrong).

    Oh Well…

    Eventually it will get so “feature rich” it will be impossible to make it work correctly. Then someone will start making a new clean OS again. I’m getting ever more motivated to move at least one of my systems back to BSD. It has been kept fairly true to The Unix Way and is much cleaner…

  7. beththeserf says:

    Things of which I am unfond…

    Whiskers on kittens
    ‘n warm winter mittens,
    Anti-fa violence’n
    Occupy sit-ins,
    Remainers in Britain,
    EU rule from afar,
    these are a few of
    my least favorite things…
    Google and Soros
    ‘n other control-freaks,
    media hypo that censures
    cits’ free-speech,
    Climate-sci modellers’
    splicings and tweaks,
    these are a few of my
    least favorite tricks…
    When the dog bites
    when the bee stings,
    when I’m feeling sad,
    I simply remember
    my un-favorite things,
    and then I git really mad.

  8. H.R. says:

    Excellent, Beth. Well done.

  9. p.g.sharrow says:

    thanks beth, my first smile of the day, or was it a grimace , no I’m sure it was a smile, at least maybe a snile…pg

  10. E.M.Smith says:

    FWIW, after moving the disk with the MariaDB (on the Pi M3) to ext3 and remounting it as /(disk)/ext instead of as /(disk)/xfs AND changing the symbolic link in /var/lib to point at it; MariaDB gives an error on trying to launch. So I’ve broken something.

    No big deal. I’ll fool around with it some more and try to fix it. But really, I’m doing an entire “redo from scratch” effort and would be scrubbing / restarting anyway. All table definitions, data loading scripts, raw data, formatted data, report SQL & Python are all saved in a different directory and I’d frequently just drop all the tables (even have a script to do it with one command) and then reload them all as part of testing things.

    So worst case is that I get to just do a “re-install MariaDB” step and then reload everything.

    I also have it running on at least 3 other platforms, so it isn’t like loss of one will slow me down. BUT it is curious that something that ought not to have had any effect has had an effect.


    My first Grin of the day too! 8-)

  11. beththeserf says:

    Thx, H.R. p.g and E.M. We hafta’ laugh at them or …

  12. E.M.Smith says:

    While my 1/2 TB of “home directory” gets dumped so I can make that disk ext3, I decided to stick two other “modest use” disks into the Evo that’s running Debvuan and check their status.

    The 3 TB is readable, so that xfs file system as NOT yet been “upgraded” to be incompatible with this slightly older release. It has just under 1/2 TB of data on it. The 2 TB disk, unfortunately, reports errors and can not mount the xfs file systems.

    I’m pretty sure I’d plugged it into the RockPro64 (newest OS Armbian Ubuntu with new xfs version) so it likely had The Deed Done on it then. It’s about 90% full.

    So that’s about 2.5 TB to dump, format, and restore AFTER my home directory is done on the other system AND after I can boot up the RockPro64 to use xfs_repair on the 2 TB disk to get it back to readable.

    I wonder how many folks will plug a USB disk in one system, then into another and have it crap out, and think their disk is just dead… That’s why this kind of thing is so horrible. A whole lot of potential for a whole lot of damage where the actual cause and fix is hidden.

    I figure most of the rest of the weekend will have one system or the other “shoveling bits” proactively to make sure no other disks get “hit” with this.

  13. E.M.Smith says:

    Well, a few days later and MOST of my disks are no longer at risk of a rogue xfs_repair causing them to be messed up.

    About 9 TB done. I do have 3.5 TB worth of “other smaller disk” that I need to look at, but it has not been plugged into anything in the last several months, so any xfs file system on it will be “old type” anyway. Near as I can tell, so far the only system with the “new” xfs is the RockPro64, so only disks that it “fondled” were a little confused by the process (and the xfs_repair on the RockPro64 could get the failed systems back to running).

    MOST of my disks had not touched it, so it was a simple Dump / Format / Load to get things back into low risk ext3 format.

    I did have 2 “problems”, both fixed fairly easily (but one of which could have been horrible on a different partition or if more of them were involved)

    First, the easier one:

    MariaDB on the Raspberry Pi refused to start with a socket error

    ERROR 2002 (HY000): Can't connect to local MySQL server through socket {blah de blah blah}

    That was traced back to the interaction of Mysql / MariaDB pig headedness about path names interacting with my choice to put the file system name in the mount point. So “WDTB/xfs/…” became “WDTB/ext/…” and MariaDB choked on it.

    Oh, yeah, there’s some config files with a hard coded path name in them in /etc/mysql that needed xfs changed to ext.

    The other problem – screwed up disk partition:

    I have many partitions on the XU4 for various system bits. /var /tmp /bin /sbin and more. Yeah, very old school. BUT it also lets me use them as an overlay mount and then, if an install / upgrade fails, I can just unmount them and the base case shows up and runs. (So mount /var from a disk over /var on the uSD card and the old /var is still on the card, but hidden by the one on disk).

    MOST of those I got recovered with xfs_repair on the RockPro64, then made into tarballs, the filesystem remade as ext3 (using gparted) and the tarball reloaded. Somewhere between the start of this and yesterday I’d moved to the XU4 to do the last few.. That was FINE until I hit /SG2/root that mounts over /root. It was not “fixed” (i’d missed it when doing them on the RockPro64).

    No Worries I think, I’ll just do xfs_repair here. It gave errors. What? Try that again… MORE errors and {FOO} moved to lost+found. checking version (xfs_repair -V) it’s the older one.

    Well, fine, back to the RockPro64… It “fixes it” but now EVERY file is in lost+found without any usable name. Just numbers.

    It seems that running the older (“wrong” now) version of xfs_repair twice screws up the journal / file system enough that the only recovery is moving everything into lost+found.

    /root is small enough, I probably could have unscrambled those eggs (and did look at it), but booting on the uSD version of /root (even with the disk version of everything else mounted) worked fine (shown no incompatibility had snuck in.) So the easy fix was just to dump the uSD /root to a tarball, restore it into /SG2/root, and THEN change /etc/fstab to mount that partition as /root over the uSD card version as a mount point.

    Rebooted, all is well.

    Now, HAD I made that mistake on a bigger partition without current backups, I’d have been in a world of hurt.

    It was to prevent that kind of “surprise Aw Shit” from not handing each partition correctly “whenever” it ran into the newer xfs code that was the driving force behind doing all this conversion now, in one go, with full awareness of the issues and focus on careful dump / restore and mount order on what machines.

    I can now breath easier and not worry about the bulk of my disks & data as they are now ext3.

    What is left to do will not be allowed to touch the RockPro64 prior to being converted (and prior t any other of my computers being “updated” to that xfs version).

    So all in all “Not Bad”. Pretty much everything is running as it ought to on my most used boards and disks, with very few xfs file systems left (and them not very important). I no longer need to worry about “disk drive VD” making a file system sick or corrupted from a newer xfs version diddling it, then moving to an older system.

    So, with that, I’m taking a small break from “seat time” ;-)

    UPDATE: (A few hours later and after dinner)

    The other 3.5 TB of USB disks was in great shape. 2.5 TB had no xfs file systems at all. I knew that I’d treated them as low priority and left some large part as ext3 when I started migrating TO xfs some many months back. Only one disk had any xfs file systems on it (2 of them) and while the total size was about 3/4 TB, only about 75 GB of data was present, so a fairly rapid dump, reformat to ext3, reload cycle. Now almost all partitions are ext3 on almost all my disks.

    There’s a few that are ext4 (despite it having a similar “issue” of an incompatible upgrade). These are partitions on a u-SD card where they will most likely only ever be seen by that OS version (i.e. not moved from system to system much) and since I have a lot of SD cards, a lot of time to search them all for not much (any?) risk reduction. Similar situation for a couple of xfs partitions on uSD cards with a matching OS. Whenever (if ever) I find myself using one I can “fix it” then… though there are fair odds many of them are “efforts” that have now been deprecated. Basically, that time is past… Then there’s the disks on the nfs file server. Again, never moved anywhere else so no real need to care what they are as an “automatic incompatible upgrade” won’t be done to them (be they ext4, xfs, whatever). Just no gain and a lot of pain to dump an 8 TB disk (onto what, btw…) just to change the format when all it does is sit on a file server that gets updated about once every 2nd years ;-)

    So I’m declaring this effort entirely finished now. All Real Disks (not on dedicated servers) have been made ext3 and are free to move about the systems without risk of incompatibility or data loss from “upgrade and xfs_repair kills it”…

Comments are closed.