For our work archive/media store, we plan on sending files (massive projects, pictures & video, all of which we need to stream over 10g lan) first to a dedicated ‘uploads’ share. Once a file is placed in uploads, the root admin will manually move them (via Krusader) to the main 'Archives' unraid array (perhaps we could use a script to automate this copy, if no files are being renamed/deleted). In theory, once a file is written, it will rarely (if ever) be touched again.

 

The idea being, we can expose 'Archives' to all users (since it’s read only), and not have to worry about accidental deletion, ransomware, etc…

 

So given this specific use case, XFS or BTRFS for the main array? A feature we would like to have is some way to checksum/validate a file (not every read, just on initial write and then manually/periodically), and recover corrupted files from parity (hopefully without rebuilding the entire disk?).

 

Essentially what we’re trying to figure out is, are there any relevant differences (for this case) between the two file systems? I imagine it is not trivial to switch after picking one, so just trying to avoid buyers remorse before committing (currently leaning towards XFS…).

 

Thanks

Edited January 19, 20206 yr by unraidun

10 minutes ago, unraidun said:

So given this specific use case, XFS or BTRFS for the main array? A feature we would like to have is some way to checksum/validate a file (not every read, just on initial write and then manually/periodically), and recover corrupted files from parity (hopefully without rebuilding the entire disk?).

It might be worth pointing out that neither file system will allow for rebuilding files from parity - that is not how parity works (parity is about recovering failed drives).  You can only recover corrupted files from backups (which is one reason why you need a good backup strategy for important files).   At the moment only BTRFS has built-in checksumming to detect corruption when a file is accessed (it does not fix it - it just detects).   XFS is meant to be adding checksumming as part of the developments in the Linux 5.x series kernels but when it will be ready for use I have no idea.   In normal operation a correctly functioning hard drive should detect corruption at the hardware level before the OS even gets involved and return a read error so for most people that is sufficient.

1 hour ago, itimpi said:

It might be worth pointing out that neither file system will allow for rebuilding files from parity - that is not how parity works (parity is about recovering failed drives).

Hmm that's unfortunate. But in theory, if you have enough information to rebuild an entire disk, don't you also have enough information to rebuild a single file (assuming you know exactly where the bits exist)?

 

1 hour ago, itimpi said:

XFS is meant to be adding checksumming as part of the developments...

So in the meantime, there is NO way to validate a file after doing a copy in XFS? Again, willing to initiate some kind of manual scrub command (doesn't have to be automatic/native to the file system).

Anyone else with XFS experience able to comment on this? XFS must have some way to validate files (something like a btrfs scrub command) right?

As @itimpi pointed out, the hardware already performs a check when reading and writing to disks, in most circumstances this is enough guarantee for the disk operations.

 

If you want additional validation you will need to add a checksum to each file and verify these checksums after copying. A plugin like "Dynamix File Integrity" can do this. This method however only does verification but no restoral.

Edited January 22, 20206 yr by bonienl

8 hours ago, unraidun said:

XFS must have some way to validate files (something like a btrfs scrub command) right?

No it doesn't, most filesystem don't checksum the data, AFAIK Btrfs, ZFS and ReFS are the exceptions.

xfs does not have a verify write option. In order to accomplish what you are asking for you need to compare two sets of files. There are native Linux tools like md5sum that can accomplish this. Search for "Linux compare contents of two directories" and you should find plenty of examples.

Hrmm ok so I guess that's one major Pro for BTRFS.

 

But file validation aside, are there any other major differences one should consider when deciding on XFS vs BTRFS (for a typical file/media server)?

 

Honestly I'm still leaning towards XFS (I agree with you guys, the chances of the hardware not catching write errors is slim), but I just want to make sure there isn't something else I'm missing...