XFS: Recent and Future Adventures in Filesystem Scalability - Dave Chinner

I wonder if you know about Dave Chinner's talk, which addresses the metadata performance issue. (they fixed it) [VIDEO]

> XFS is probably the best bet on Linux Yes, agree. However, I also lost files on it (had files overwritten with 0s, as other people already commented here). Also, it's your best bet of you don't need the extra features provided by ZFS. Thanks to its checksum validation, I detected bad SATA cables three times already (on different systems), instead of getting corrupted data. >it was beautifully designed and implemented by SGI back in the day. Hopefully the ChatGPT generation don't start modifying that code too much. Except it's not what happened. Please check this talk from Dave Chinner, where he explains how XFS was developed and ported to Linux and then made robust and stable by him and other contributors. The disk format has changed many times, now it's robust and resilient against metadata corruption. XFS Development talk by Dave Chinner [VIDEO] History of Linux FS, also by Dave Chinner: [LINK]

> A while ago, I read somewhere that XFS is good for a small number of large files, whereas ReiserFS is good for a large number of small files. I don't know whether that's true anymore if it ever was It used to be true. XFS has for a long time been the very fastest real filesystem available when it comes to moving data, and one of the slowest ones in real-world use when it comes to changing metadata. Untarring a kernel tarball a second time (on top of the first) is pretty much the canonical benchmark for metadata operations, and the one where XFS used to be at it's absolute worst. XFS is in the news right now exactly because they have fixed that deficiency. It's still faster than ext*, zfs and btrfs in pretty much everything else, but now it's comparable to them when modifying metadata. So this is exactly the right benchmark to use, because it's the one where there has been recent change. Video of Dave Chinner presenting this at linux.conf.au: [VIDEO]