Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

It will be marked as experimental for a long time. There isn't a magical point at which it will suddenly be perfect and bug free. That said kernel 3.2 was a major point of stability. https://btrfs.wiki.kernel.org/index.php/FAQ#Is_btrfs_stable....

It is integrated with the package manager on Ubuntu already. I just upgraded my laptop to Quantal and part of the upgrade process spotted I was using btrfs and created a snapshot. (It was a complete waste of time as I have automatically created hourly, daily, weekly and monthly snapshots.) Doing regular package updates is very slow with btrfs. This is due to fsync() being called several times per file.

You'll also want Quantal for an updated btrfs-tools package. For example it lets you do scrubbing. You also need it (and kernel 3.3+) to change raid levels after filesystem creation. The Ubuntu 12.04 installer does create and install to btrfs but didn't let you configure things like raid level so you were stuck with whatever it did.

I've been running all my systems on btrfs for several months now on Ubuntu 12.04 (kernel 3.2) on both SSD and HDD including using RAID 0, RAID 1, dmcrypt/LUKS, inplace conversion from ext4 and who knows what else. (Across my server, workstation, laptop and HTPC.)

The only problem I have had is when filesystems fill up. I've never lost data but it can be quite frustrating trying to find files to delete (also need to be removed from snapshots), rebalancing etc to get things running smoothly again. The various ways of doing df are mostly a work of fiction.

My data is duplicated to offline backups, Dropbox, multiple systems and git/hg repositories so the failure of any system would be annoying but I'd never lose anything. You should make sure you are in that position first, independent of what filesystems are being used.



"Doing regular package updates is very slow with btrfs. This is due to fsync() being called several times per file."

You mean that fsync()s are more expensive on btrfs, or ubuntu calls them more often when using btrfs for some reason?


The former - fsyncs are more expensive because they involve copy on write updates all the way up the tree to the root. Some of the fsyncs are there because of ext4 quirks. That all said, every kernel release brings big improvements in btrfs especially metadata handling. IOW it is currently the worst it will be.


Why not just sync the data change and sync the metadata changes only to a write-ahead log? Or if the data is logged also, you only need to sync the log.

I assume btrfs uses a log, right?


A tree is the main data structure. The inspiration is this pdf http://www.usenix.org/events/lsf07/tech/rodeh.pdf

There is a log to help with fsyncs. http://en.wikipedia.org/wiki/Btrfs


You can install apt-btrfs to get snapshots when installing thingsm and run "eatmydata apt-get install <x>" to remove fsyncing. Of course, you would be out of luck if the power went out in the middle of the installation, but it makes things much faster.


You can revert to the snapshot so there isn't really a problem, although that can be quite finicky and probably take longer to setup than the time saved avoiding fsyncs.

Note that btrfs will be just fine on unexpected power outage - the filesystem will just contain some random combination of old and new files affected by the installation.


Yeah, that's what I meant. The installation files will be in some inconsistent state, the filesystem itself will be fine.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: