EXT4, Btrfs, NILFS2 Performance Compared 102
An anonymous reader writes "Phoronix has published Linux filesystem benchmarks comparing XFS, EXT3, EXT4, Btrfs and NILFS2 filesystems. This is the first time that the new EXT4 and Btrfs and NILFS2 filesystems have been directly compared when it comes to their disk performance though the results may surprise. For the most part, EXT4 came out on top."
Re:Another lame filesystem review (Score:1, Interesting)
Others have pulled you up on the SATA/SSD remark so I won't cover that again, but you are also a little confused about those filesystems being optimised for SSD.
If you read the NILFS page (http://www.nilfs.org/en/about_nilfs.html), it says nothing about SSD. It has features you might want on any storage, any benefits to SSD media is just a side effect.
NILFS2 is pretty interesting (Score:5, Interesting)
NILFS2 (http://www.nilfs.org/en/) is actually a pretty interesting filesystem. It's a log-structured filesystem, meaning that it treats your disk as a big circular logging device.
Log structured filesystems were originally developed by the research community (e.g. see the paper on Sprite LFS here, which is the first example that I'm aware of: http://www.citeulike.org/user/Wombat/article/208320 [citeulike.org]) to improve disk performance. The original assumption behind Sprite LFS was that you'll have lots of memory, so you'll be able to mostly service data reads from your cache rather than needing to go to disk; however, writes to files are still awkward as you typically need to seek around to the right locations on the disk. Sprite LFS took the approach of buffering writes in memory for a time and then squirting a big batch of them onto the disk sequentially at once, in the form of a "log" - doing a big sequential write of all the changes onto the same part of the disk maximised the available write bandwidth. This approach implies that data was not being altered in place, so it was also necessary to write - also into the log - new copies of the inodes whose contents were altered. The new inode would point to the original blocks for unmodified areas of the file and include pointers to the new blocks for any parts of the file that got altered. You can find out the most recent state of a file by finding the inode for that file that has most recently been written to the log.
This design has a load of nice properties, such as:
* You get good write bandwidth, even when modifying small files, since you don't have to keep seeking the disk head to make in-place changes.
* The filesystem doesn't need a lengthy fsck to recover from crash (although it's not "journaled" like other filesystems, effectively the whole filesystem *is* one big journal and that gives you similar properties)
* Because you're not repeatedly modifying the same bit of disk it could potentially perform better and cause less wear on an appropriately-chosen flash device (don't know how much it helps on an SSD that's doing its own block remapping / wear levelling...). One of the existing flash filesystems for Linux (JFFS2, I *think*) is log structured.
In the case of NILFS2 they've exploited the fact that inodes are rewritten when their contents are modified to give you historical snapshots that should be essentially "free" as part of the filesystem's normal operation. They have the filesystem frequently make automatic checkpoints of the entire filesystem's state. These will normally be deleted after a time but you have the option of making any of them permanent. Obviously if you just keep logging all changes to a disk it'll get filled up, so there's typically a garbage collector daemon of some kind that "repacks" old data, deletes stuff that's no longer needed, frees disk space and potentially optimises file layout. This is necessary for long term operation of a log structured filesystem, though not necessary if running read-only.
Another modern log structured FS is DragonflyBSD's HAMMER (http://www.dragonflybsd.org/hammer/), which is being ported to Linux as a SoC project, I think (http://hammerfs-ftw.blogspot.com/)
Re:JFS? (Score:3, Interesting)
JFS has been in "bugfix mode" for some time.
Comment removed (Score:3, Interesting)
Re:Yet another content-free Phoronix fluff article (Score:2, Interesting)
Re:Why is JFS the red-headed stepchild? (Score:5, Interesting)
Maybe it's just a case of, "it's a fine filesystem, but didn't really bring any compelling new features or performance gains to the table, so why bother"?
I think because it's just not sexy.
But, as you say, if you look into it it supports all the buzzwords. I use it for everything, and IME it's an excellent, lightweight, unobtrusive filesystem that gets the job done while staying out of my way (which is exactly what I want from a filesystem). It would be nice if it supported things like filesystem shrinking, which is very useful when rearranging partitions, and some of the new features like multiple roots in a single volume are really useful and I'd like JFS to support this, but I can live without them.
JFS also has one really compelling feature for me: it's cheap. CPU-wise, that is. Every benchmark I've seen show that it's only a little slower than filesystems like XFS but it also uses way less CPU. (Plus it's much less code. Have you seen the size of XFS?) Given that I tend to use low-end machines, frequently embedded, this is good news for me. It's also good if you have lots of RAM --- an expensive filesystem is very noticeable if all your data is in cache and you're no longer I/O bound.
I hope it sees more love in the future. I'd be gutted if it bit-rotted and got removed from the kernel.