If this is your first visit, be sure to
check out the FAQ by clicking the
link above. You may have to register
before you can post: click the register link above to proceed. To start viewing messages,
select the forum that you want to visit from the selection below.

Facebook To Trial Btrfs Deployments

03-27-2014, 01:00 PM

Phoronix: Facebook To Trial Btrfs Deployments

While it should come as no surprise given that Facebook recently hired multiple Btrfs file-system developers, but they will be trying out the Btrfs file-system within real-world deployments at the social networking company...

Comment

I check btrfs out every six months or so and have yet to be convinced it is stable, and there are constant updates to the latest kernels so it is obviously very much still a work in progress....so I'm curious which kernel version and userspace environment facebook feels is stable enough for production deployment?

Comment

I check btrfs out every six months or so and have yet to be convinced it is stable, and there are constant updates to the latest kernels so it is obviously very much still a work in progress....so I'm curious which kernel version and userspace environment facebook feels is stable enough for production deployment?

According to the lwn article, facebook carries a few different kernels, with the latest being 3.10 (with 60 patches, iirc). I'd imagine that's what they'd use, if not something even more recent. Of more concern, though, is the problem with cfq and stable pages (that is, they're performance hit). There's some interesting discussion in the pgsql article as well regarding general io buffering issues.

Comment

[...]there are constant updates to the latest kernels so it is obviously very much still a work in progress....[...]

Now I'm not saying you're necessarily wrong, but it could be the most stable thing in the world and they're just working on making it faster. Compared to ext4, it is rather slow (hardly noticeable on an HDD though).

Comment

Now I'm not saying you're necessarily wrong, but it could be the most stable thing in the world...

Besides being not necessarily wrong, he is also absolutely not wrong.

Even still, there are serious issues with btrfs that make it unsuitable as a drop-in replacement for ext4. Just this week there was a discussion about how btrfs can get into a state where there is plenty of free space but chunks are not automatically reclaimed after files are deleted, which can result in out of space on either data or metadata, even though there is plenty of space overall. There was another issue on the email list discussed recently (I just skimmed it) that may or may not be related, but something with balance was not working the way some users expected, and the solution required some manual tweaking. And I still see posts every few weeks from someone whose btrfs filesystem has become corrupted and cannot be mounted, for whatever reason (this sort of thing is not supposed to happen to a production filesystem, especially a COW one)

The project management for btrfs continues to be poor. I think if there were a decent project manager, the remaining issues that are keeping btrfs from being production ready would be rapidly prioritized and fixed. But the project seems to wander aimlessly, never reaching production quality.

Comment

Even still, there are serious issues with btrfs that make it unsuitable as a drop-in replacement for ext4. Just this week there was a discussion about how btrfs can get into a state where there is plenty of free space but chunks are not automatically reclaimed after files are deleted, which can result in out of space on either data or metadata, even though there is plenty of space overall. There was another issue on the email list discussed recently (I just skimmed it) that may or may not be related, but something with balance was not working the way some users expected, and the solution required some manual tweaking. And I still see posts every few weeks from someone whose btrfs filesystem has become corrupted and cannot be mounted, for whatever reason (this sort of thing is not supposed to happen to a production filesystem, especially a COW one)

The project management for btrfs continues to be poor. I think if there were a decent project manager, the remaining issues that are keeping btrfs from being production ready would be rapidly prioritized and fixed. But the project seems to wander aimlessly, never reaching production quality.

nice summary !

even though I'm using it on the system partition - it out of a sudden yesterday showed a file with checksum missing (probably hardware: hdd (new - is that even possible ? I checked it with badblocks and smartctl, etc. etc.) , processor or RAM issue; could be a btrfs-issue though). Luckily it wasn't any important file

afaik got this also happening in the past - so this leaves this impression of btrfs randomly corrupting files on its own for me (of course could be wrong since it also detected a harddrive/partition that is on the verge of becoming broken - showing some more badblocks, internal errors); mentioned high memory usage (a memory leak ? on the mailing list), RAID handling when removing and re-adding a harddrive

and of course this issue with ENOSPEC/free space fragmentation and/or non-reclaim of free space

this might be a side-effect of Btrfs' COW nature but at this late (?) point of development it slowly should be tackled and must not need an manual (especially advanced user) intervention to continue to be usable

if development continues like that it will again take years until the round edges are smoothened out

it has come a long way and improved a lot but there's still the feeling that fundamental mechanisms and parts are missing underneath

Comment

It already has many features (such as volume management) that ZFS doesn't have.
What features in particular are you talking about? Personally I'm wating for proper RAID5/6 code, but other
than that I can't think of anything lacking. (Besides maybe support for raw block device export, which I don't
think is even planned).

Comment

It already has many features (such as volume management) that ZFS doesn't have.
What features in particular are you talking about? Personally I'm wating for proper RAID5/6 code, but other
than that I can't think of anything lacking. (Besides maybe support for raw block device export, which I don't
think is even planned).

local copies ?

copies=3

lz4 compression ?

more advanced checksums than crc32c (e.g. sha256) ?

easy to use / user-friendly expert tools ?

trivial errors or "features" that are not showing during routine checks ? (e.g. the checksum missing for space_cache)

an inode_cache that doesn't take minutes to regenerate after having shut down the "links" browser and in the process slowing down the system to a crawl ?

actual NO slowing down during heavy i/o writes of the *entire* system compared to ext4 ? (on dm-crypt)

stability ? (already got corrupted files on /home; after a few crashes (hardlocks) the /home directory got that much messed up that the kernel would panic or couldn't access /home anymore)

these are all working features that are currently available on ZFSonLinux

this is not to badmouth Btrfs - rather a rant since I'm personally interested in a 2nd drop-in filesystem that could also be used on /home instead of ZFS (which doesn't support realtime kernels yet and suspend-to-disk, probably suspend-to-ram neither) - especially on the laptop to fully use energy-saving and time-saving features while maintaining maximum data integrity & -safety