Linux 4.3 File-System Comparison With Btrfs, EXT4, XFS, F2FS

[nanonyme]

Wrong ... btrfs is meant to be an unreliable *mockup* of ZFS. :-P

Btrfs has newer pieces of research in its guts than were available while ZFS architecture was designed. Read up on the B-tree usage, you find interesting differences there. Similar capability set is more because these things are what people want than copying things over

[darkbasic]

This is still in the wiki: https://btrfs.wiki.kernel.org/index.php/RAID56
"Parity may be inconsistent after a crash (the "write hole")"

So I wouldn't exactly call it reliable on par with ZFS because of that.

It's a pity that it hasn't still been addressed.

[blackiwid]

1. The slowest is the most interesting?

Its funny that most people here talk about the slowest tested filesystem, maybe speed is not (always) the most importent metric for a filesystem?


2. Fedora disklayout support

I use Btrfs as root and for home on many systems, sadly fedora boots system with btrfs directly on the disk without partiones fine but does not support it officialy, that leads to the funny behaviour that each kernel upgrade throughs some errors and does not update grub, but when I then manualy grub-mkconfig -o .../grub.cfg all works fine. but I have to do that manualy ofter, really stupid because its a overengineered artificial bug. one stupid if statement that exits the upgrade that makes no real sense. Tried to discuss that in the fedora mailing list, basicly a WONT-FIX (we dont "support" this layout) they sabotage that layout basicly but whatever.

Makes just sense for me, to stop using lvm/partitions, when btrfs has a subvolume feature, the functionality would be redundant. But I maybe live to much in the future. (not only on this field).


3. Compression

Compression in filesystems is not only not even primary for disk space savage somebody implied, its about speed, because reading bytes from even ssds is eextremly slow, if you can read less physical bytes to get as resuult more bytes your read/write speed of content from the disk increases much. And yes of course only for stuff that make sense to compress like text-files (only?) btrfs as far as I know only compresses this files and not the whole volume except you force it maybe to do it for everything.

[sdack]

1. The slowest is the most interesting?

Its funny that most people here talk about the slowest tested filesystem, maybe speed is not (always) the most importent metric for a filesystem?
...

You make a point. How indeed is it possible for a file system based on a b-tree implementation and garnished with a gazillion features to end up as the slowest file system?

[SystemCrasher]

Why the hell, no matter how much time passes, Btrfs stays slow and ext4 stays fast?

Because they are different to the hell. Look:

Btrfs offers crapload of features.
1) It checksums data, so read errors are detected. EXT4 only started to checksum metadata only and only recently. And no data checksum so far, if I remember. If you read garbage... in ext4 it could get unnoticed and you learn you've a problem when half of your data are garbage, so it got visible at topmost levels.

2) Dealing with RAIDs in EXT4... uhm, sure, have fun messing with LVM and somesuch, enjoying by stitching ancient techs together using duct tape and glue. But btrfs is much better in this regard. You see, btrfs does not minds if you just add one or few drives into the pool. It would use it and pool would just get some free space. Adding free space to system is not easy. Just connect new drive(s) to your hardware and show 'em to btrfs. No reformatting, no mandatory large-scale data movement, nothing.

3) Flexibility. No drives alignment clusterfuck. No requirement to have exactly N drives. On purely technical side, btrfs structures can contain and describe arbitrary mix of raid levels, as long as there is enough of drives with free space to perform write using requested RAID level. RAID could be per-file or per-subvolume (subvolume == "hierarchy", it's directory subtree, not a "partition"). When write requested, btrfs takes a look around and attempts to apply requested redundancy scheme. When write comes, its like this: assume we want mirror. Btrfs looks up 2 devices with free space. And puts one chunk on one of device and mirror copy on andother. It is not a big deal how exactly these devices are sized, etc. As long as there is free space on at least 2 devices left, write succeeds. This allows to add devices as needed, without bothering self with massive data moves or RAID level conversions. While arbitrary mix of RAID levels isn't here yet, it's up to allocator and tools, not filesystem core itself. These days, feature manifests itself as on-fly RAID conversion. You can convert RAID levels without unmounting, stopping, rebooting, or whatever. You just ask to go from RAID X to RAID Y. Conversion starts in background and storage lives with two different RAID schemes for some time when conversion in progress. Btrfs core is okay with RAID levels mix, that's why it happens so easy and unlike many other RAIDs it can be transparent, on-the-fly operation. Which does not assumes downtime and/or manual data movement, etc.

4) Snapshots and non-destructive writes. How long would it take for typical EXT4 user to undo effect of rm -rf in, say, /home? In btrfs you can do it in less than minute, if you had snapshots . Furthermore, one can have writeable snapshots. They are cool. Imagine you'vg got something like symlinks, but on block layer. You can have hierarchies originating from same set of blocks, that's what it would call shapshots. Once some files diverge, btrfs transparently marks different blocks as such, and programs never have to bother self with the fact 2 hierarchies were sharing some blocks. Then, cp --refink allows one to explicitly "link" blocks. When copy happens, cp hints filesystem it wants it to use same mechanic. So you can "copy" 20Gb file in a blink of eye. Filesystem would just change metadata to get idea now same 10Gb of blocks are used by 2 different files. When file content starts to diverge, CoW mechanic would kick in, making copy-on-write for differences. Those who mess with VMs or containers can find it very interesting option. Because if you deploy 20 identical containers or VMs, you do not have to store their content 20 times on disks. You rather have "core set of blocks", roughly equal to 1 container in size, it is referenced 20 times. As contents diverge, CoW does its job, making it to looks like if it was 20 independent hierarchies. And yep, on btrfs I can deploy 20 x 10Gb VMs or containers in time roughly equivalent to time requireed to move 10Gb. Once. That's where EXT4 would turn slow. In fact, it can turn something like 20 times slower. Because it can't reflink blocks and would have 20 copies of VMs. Actually shuffling 10Gb whole 20 times, hence moving 200Gb here and there. Not to mention it would take 200Gb on your drive, not mere 10Gb like 20 reflinked block copies would initially do (as containers/VMs diverge, it would get worse, but as long as they share some blocks, there is still some space gain).

5) Compression. In fact, LZO is kinda fast. If you have slow drive and fast CPU, compression could even improve write and especially read speed, contrary to expectations. Though it is mostly not about SSDs which tend to be fast.

6) Feel free to try to put it all together without BTRFS. What about ability to create snapshots while using RAIDs? And what would happen if you, say, want to go from RAID 1 to RAID 6 in some particular instance? Good luck to correctly move everything including snapshots, etc.

Sure, this implies some overhead. And it getting important on SSDs which are FAST.

Your question is basically like this: "why the hell each time I try to fly Airbus A380, it can't fly as fast as jet fighter?! What the hell?!". Now let's assume we want to transfer 500 humans from USA to Australia. Feel free to do it faster, cheaper and better using jet fighters. They fly faster after all, right?

[Pyth0n]

Two lines are blue and two are red - is that what you see

Actually light blue, dark blue and two very similar tints of red - on zoom one of them is pink, but on full-hd screen and with tired eyes they are (for me) almost identical. And no, I'm not colorblind (as far as I can tell )

[lsatenstein]

There is something that I did not see with the benchmarks, and that may be trivial. On a fully loaded 250gig partition, what is the amount of meta data filespace used versus file use, expressed as a percentage. I realize that the percentage can vary, but it would still be nice to know. Is it 2% or 5%