Ubuntu 12.10 File-Systems: Btrfs, EXT4, XFS

[russofris]

@russofris
for ext4 you could argue based on features. the main ones being less fragmentation, faster fsck, and more recently metadata checksums

Indeed. Unfortunately, I am still stuck with the perf/regression testing, and still have to write a CBA report for the directors. The other option is to wait for our vendor (RHEL or OEL) to adopt the new FS as a default/recommended option and implement it during the next cycle. To give you an example of what enterprise admins are up against, it took me almost 4 years and over 2 million dollars to migrate end-to-end from 1024 to 2048bit SSL. The meeting minutes from the project are available for your viewing.


F

[curaga]

Any reason to stop at 2k and not go to 4k?

[russofris]

Any reason to stop at 2k and not go to 4k?

A number of third party external interfaces are based upon custom SSL implementations (probably derived from extremely old OpenSSL) and do not support 4k certs. In addition, a number of handsets (we work with mobile devices) released prior to 2009 have no support for 4096bit, nor do they have an automated manner in which to update their truststores (Verisign's Class3 G5 2048bit migration was a major PITA). Mobile devices from the 2005-2007 era with 4096bit capabilities often suffer performance regressions with the the larger keys.

The low-end Andriod phones (the ones where the carriers do not update the OS, ever) are a plague on the IT industry. We're going to enter into an era of cellular botnets and malware infested devices soon. This isn't Android's fault, rather the result of carriers/manufacturers' hasty TTM and nonexistent life cycle planning. It isn't that the carrier "won't" update these devices, it's that they "can't".

The iPhone was a godsend. Not because it's better, but because "at least I know what to expect, and can still get someone to make retroactive fixes".

Sorry for the off-topic derailment of this thread.

F

[Ericg]

Wasn't the btrfs fsck incompatible with the other ones (ext4 etc) ??

Despite users just calling "fsck" fsck is actually a wrapper that checks what filesystem you are running it against it, and then re-calls the appropriate fsck program --> fsck.ext4, fsck.xfs, fsck.resierfs etc. Every filesystem needs its own custom fsck (except maybe ext2 and 3 can use eachothers. but ext4 probably needs its own after all its new features), the only common link is the name and thats just for consistency.


Ontopic: Im glad to see BTRFS maturing, and gaining speeds. its not as fast as ext4 but I definitely think that its usable in a desktop environment now without too much of a penalty, the only thing that bothers me is the possibility for large fragmentations and the fact that discard isnt enabled by default despite BTRFS detecting if its on an SSD automatically. I have an SSD so the fact discard isnt automatic is a bit of an annoyance, though admittedly fragmentation isnt as big of a deal to me since read's are all 1 universal speed unlike with traditional drives. I just always liked the fact that ext4 was good enough to not need a defragmentor most of the time.

Side note: Why is Btrfs so good at threaded IO? Like what the f*ck? Thats a huge jump up from ext4 and xfs. Is it because of BTRFS design or what?

[russofris]

Side note: Why is Btrfs so good at threaded IO? Like what the f*ck? Thats a huge jump up from ext4 and xfs. Is it because of BTRFS design or what?

My guess (when I see strange results like that) is that BTRFS is ignoring an fsync or flush of some type, and caching when it shouldn't be. I would be both surprised and pleased if this is not the case.

F

[devius]

My guess (when I see strange results like that) is that BTRFS is ignoring an fsync or flush of some type, and caching when it shouldn't be.

I'm 99,9% sure that's the case simply because physically the HDD in this test would never be able to achieve such high random write values. Even the fastest consumer HDD (Velociraptor 1TB) wouldn't be able to achieve even 1/10 of those 35MB/s.

[garegin]

i wonder when butter is gonna released as stable. it's funny that linux managed to ship a graphic server before a filesystem. even though linux is used heavily in the enterprise and a high-end filesystem is very important.

[WorBlux]

BTRFS has an SSD mount option which changes some of the underlying logic. To date, I have not seen a compelling set of benchmark results to call it faster than without the mount option on an SSD.

There are tools for BTRFS, including fsck. I do not know that I would call them stable (It's a relative term), nor do I believe that fsck is as essential as it was with the previous generation of filesystems.

F

From what I understand it just turns off the optimizations meant for spinning disks as it's wasted cpu cycles to perform them where the seek latency is the same throughout the entirety of the disk.

[Candide]

I had an interesting experience a few days ago with an old machine that I was upgrading for a friend. I installed Ubuntu for him 3 years ago and it has run fine. Then he wanted an upgrade, which I did. But the OS wouldn't survive more than a couple of reboots before totally crashing and burning, so serious that I couldn't repair it and had to reinstall. Happened a few times. So finally, I put Ubuntu (actually, Lubuntu) 12.04 on it using XFS as the file system, and it has been fine.

No doubt there's something funny going on with his hardware. But anyway, XFS works and EXT4 doesn't. I didn't try BTRFS. I'm just happy it works and will leave well enough alone. I am curious though if anyone else has seen this?

[jacob]

BTRFS has an SSD mount option which changes some of the underlying logic. To date, I have not seen a compelling set of benchmark results to call it faster than without the mount option on an SSD.

I think the mount option is deprecated, btrfs now automatically switches to that mode when it sees a SSD. Also AFAIK it's not supposed to make a performance difference, the purpose is rather to extend the device's life.