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

I'd really like to see btrfs start to stabilize and become more mainstream, but everything still seems to say that it's experimental.

The main reasons that I want it on my desktop are:

  * easy backups
  * checksums
  * maybe it will become integrated with package manager (I'm on ubuntu) so that I can roll back package updates if they don't work properly


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.


The fsck for btrfs is still not quite there. If you are using multiple disks with btrfs's mirroring/checksums, hopefully you won't get hit by HDD hiccups leading to metadata corruptions which btrfs's fsck can't yet handle. I certainly wouldn't recommend running btrfs on a single HDD/SSD unless you are doing frequent backups and don't mind losing state between backups if you get unlucky.

Also, please note that btrfs snapshots != backups. They will not save you in case of device failure. Checksums also won't help you if there are kernel bugs.


I have been running Ubuntu 12.04 with my / as btrfs for a couple of months now, with no trouble (and not even thinking about it truth be told). That said, I left my /home ext4 because I didn't know how much to trust it.


Did the same, btrfs for everything but home and will switch to ext4 with 12.10 because it feels much slower then the ext3 i had earlier. But i'll be sure when i upgrade.

To be honest, what do i need btrfs for? I don't (and likely wouldn't) use all of its advanced features anyway.. In all the benchmarks ext4 seems to be a reasonable choice in terms of speed and stability.


I am looking forward to when we have fire and forget snapshotting system so that we all have rolling backups. I would also like the send snapshot features they have added recently for keeping multiple drives in sync (I currently use unison, but I think this could be faster/better).

Plus copy on write should be pretty cool (cp becomes as fast as mv), though I could see it allowing me to engage in some suboptimal behaviors of copying tons of stuff and counting on CoW to avoid actual duplication.




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

Search: