On 12/20/14 17:52, Alphazo wrote: > Hello, > > I'm pretty new to XFS. I'm considering moving away from ext4 to XFS because > of the new self-describing option, performance and reliability improvements > that XFS went through over the past year. Now I'm puzzled with the new free > inode btree option (finobt). I tried to find some documentation about it > but couldn't find the pros or cons. So from an end-user perspective with a > couple of TB worth of photos: > - Does it improve overall reliability? > - Does it provide faster fsck/repair? > - Does it improve any read or write operation? > - Is it safe to use and does it recover as well as with finobt=0? > - What is the typical case for enabling it and would you recommend using it > for any new fs creation? > > Thank you in advance for your pointers. > Alphazo As a user... You could try it out and see: mkfs.xfs -m crc=1,finobt=1 <block_device_to_format> Here, on old junk hardware, finobt aids greatly in multitasking on small-file creation. It may not have the same effect on your hardware. finobt has given very, very little trouble since it was accepted into the kernel code and xfsprogs. Recovery and reliability have become roughly equal between old XFS, new XFS, and new XFS with finobt. They just approach the problem in different ways. With old XFS, I rely heavily on xfs_repair and xfsdump to show filesystem issues. With new XFS, the kernel code is more likely to complain as the issues are happening. finobt introduces the slightest bit of overhead that might be noticed at the point of resource exhaustion. Otherwise, its overhead might be hard to spot. As for safety and reliability, I'm working with kernel 3.18 with the drives' write caches shut off and using the latest xfsprogs. It works great. The new v5-superblock XFS progresses at a fast pace, and it helps greatly to keep up with it. kernel 3.18 seems to be a better kernel, period. YMMV. Try a test filesystem first and test to your liking first. If something goes wrong, you should find that out in two weeks of testing the file system. Just curious, though, with that volume of images, is there a possibility of making a read-only filesystem? That would take a lot of the safety and recovery issues out of the equation, even if you stick with ext4. It would make your main concern to sha256sum the files so that you can check them later for bit-rot. Good luck! Michael _______________________________________________ xfs mailing list xfs@xxxxxxxxxxx http://oss.sgi.com/mailman/listinfo/xfs
