[plug] xfs errors?

[William Kenworthy]

On 19/7/22 18:36, Brad Campbell wrote:
> On 19/7/22 17:37, Dean Bergin wrote:
>> Hello Brad,
>>
>> What an interesting journey you've shared with us. By by golly I've never had this sort of 'fun'
>>
>> Out of curiosity, what is your requirement that made you decide to use xfs over ext[234]?
>>
>> I've used xfs in the past when managing storage in jbod scenarios - since those drives didn't change in size (other than the occasional upgrade/increase in capacity) and where all same or double capacity so easier to manage to a degree - but I switched to using ext4 when I built my software raid + LVM2 as I found that xfs doesn't seem to support shrinking.
> G'day Dean,
>
> I detailed that particular journey back in 2020 after I spent literally weeks benchmarking one against the other.
>
> Thread starts here : http://lists.plug.org.au/pipermail/plug/2020-January/084245.html
>
> It's a pathological scenario really, but none the less a reality of the system I put together.
>
>> I think with a good backup strategy, filesystem is somewhat less important, but I suppose it depends on the application or your specific requirements.
>>
> This *is* the backup strategy. I have some 850 days of versioned backups of every machine on that drive. Have only had to use it a couple of times but those times have been invaluable : "I remember updating that document in Feb and must have accidentally deleted it some time in March. It's September, do you think you might be able to find it?". Bloody marvelous!
>
> When the drive fills up (about every 3 years), I write the start and end dates on it and pop it in the safe and bring up a new one. Not because I have a requirement to, but if in 10 years I want something that is on it I *might* get lucky and find it spins up. If it's critical data, it'll be on that drive and the other 3 drives I'll fill up between now and then and my current machine anyway.
>
> rsync backups with hardlinks are bloody awesome. But lots of them on one drive creates a shit-ton of inodes. Most of the current files have ~800 hard links. That requires a filesystem which manages metadata well, and xfs does it much faster than ext4. On the other hand, as I've just found out ext4 is a case of "slow and steady wins the race". xfs didn't lose any data, but its fsck handles unclean shutdowns a bit less elegantly than ext4.
>
> Even though the old drive has 600G free, I've worked up a new drive today with an xfs v5 filesystem with all new integrity options enabled and I'll probably shelve the old one once the rsync -c is complete.
>
> This was an interesting lesson for me, and I'll be putting my backup system raspberry pi 4 and USB attached disks on the UPS circuit.
>
> I learned another interesting lesson. There are instances (which I'll be trying to reproduce to verify) where Debian updates/upgrades might change the contents of a file but not the size or mtime and therefore rsync without the -c option misses it. I've spotted a few with my rsync -c run and when examining the difference it's certainly "intended" rather than corruption. That's an investigation for the "when I have time" shelf.
>
> Bad day when you don't learn something.
>
> Regards,
> Brad
> _______________________________________________
> PLUG discussion list: plug at plug.org.au
> http://lists.plug.org.au/mailman/listinfo/plug
> Committee e-mail: committee at plug.org.au
> PLUG Membership: http://www.plug.org.au/membership

Hi, another view:

I am using xfs on some old drives (WDgreen, red and seagate ironwolf) 
and newer M.2 and sata SSD  on an intel system for moosefs.  The the old 
drives are using odroid HC2 units (arm based, builtin USB3 to sata 
interface) Occaisionally one of the arm systems randomly fails to boot 
and invariably the xfs on that one is corrupt.  If xfs_repair fixes it 
within a shortish time its ok as moosefs will pickup and fix any corrupt 
files.  Otherwise I just reformat and let moosefs backfill it - faster 
that way!  I did try btrfs when initially setting it up, but found xfs 
more stable at the time.

I have found that ext4 is a somewhat fragile file-system when using 
hardlink based backups via "dirvish" - to the point it was a waste of 
time using it.  It seems better these days, but I used reiserfs and then 
btrfs with a lot better results (as in avoiding rampant filesystem 
corruption after only a few backup runs)

XFS has an experimental online scrub type system xfs_scrub that might be 
a good idea if its accumulating small errors at a constant rate but I 
have no experience in using it.

BillK