Ubuntu Has Plans For Btrfs In 2011, 2012

[phoronix]

Phoronix: Ubuntu Has Plans For Btrfs In 2011, 2012

While the Btrfs file-system has been an install-time option for Fedora for a couple of releases already, Red Hat has even pushed support in RHEL6 for optionally using Btrfs, and then Intel and Nokia are using Btrfs as the default file-system in their MeeGo distribution, Ubuntu is now looking at joining the Btrfs party. However, it will not be for a while...

http://www.phoronix.com/vr.php?view=ODI0NA

[waucka]

Well, we are talking about the system responsible for storing people's super-important data. Haste could have dire repercussions. That said, having it available as an option is nice, and I think Ubuntu should aim to have experimental support for it in Maverick.

[mat69]

Well, we are talking about the system responsible for storing people's super-important data. Haste could have dire repercussions. That said, having it available as an option is nice, and I think Ubuntu should aim to have experimental support for it in Maverick.

Especially if the gain of such an important change is not that evident yet.

[Jimbo]

Totally agree, btrfs continues having kernel oops from time to time, its developers clearly recognize that it is in an experimental fase.

Its not the same an xorg crash than a fs + lose data crash.

[movieman]

I think Ubuntu should aim to have experimental support for it in Maverick.

There's experimental support in 9.10; I've had one of my non-essential partitions running btrfs for a few weeks and so far it's been more robust than ext4. What you can't do is format a btrfs partition at install time, nor can you boot from it if you manually create one.

My guess is that 2011-2012 is probably the right timescale for enabling it for general use.

[JeanPaul145]

Especially if the gain of such an important change is not that evident yet.

The gains of butter fs are:

* Online volume growth and shrinking
* Online block device addition and removal
* Online defragmentation
* Online balancing (movement of objects between block devices to balance load)
* Transparent compression (currently zlib)
* Subvolumes (separately-mountable filesystem roots)
* Snapshots (writeable, copy-on-write copies of subvolumes)
* File cloning (copy-on-write on individual files, or byte ranges thereof)
* Object-level (RAID1-like) mirroring, (RAID0-like) striping
* Checksums on data and metadata (currently CRC-32C)
* In-place conversion (with rollback) from ext3/4 to Btrfs
* File system seeding (Btrfs on read-only storage used as a copy-on-write backing for a writeable Btrfs)
* User-defined transactions
* Block discard support (reclaims space on some virtualization setups or improves wear leveling on SSDs by notifying the underlying device that storage is no longer in use)

Planned features include:

* Object-level (RAID5-like and RAID6-like) parity-based striping
* Online and offline filesystem check
* Incremental dumps
* Data deduplication

source: wikipedia

As you can see, this is already quite a feature list.

[mat69]

The gains of butter fs are:

* Online volume growth and shrinking
* Online block device addition and removal
* Online defragmentation
* Online balancing (movement of objects between block devices to balance load)
* Transparent compression (currently zlib)
* Subvolumes (separately-mountable filesystem roots)
* Snapshots (writeable, copy-on-write copies of subvolumes)
* File cloning (copy-on-write on individual files, or byte ranges thereof)
* Object-level (RAID1-like) mirroring, (RAID0-like) striping
* Checksums on data and metadata (currently CRC-32C)
* In-place conversion (with rollback) from ext3/4 to Btrfs
* File system seeding (Btrfs on read-only storage used as a copy-on-write backing for a writeable Btrfs)
* User-defined transactions
* Block discard support (reclaims space on some virtualization setups or improves wear leveling on SSDs by notifying the underlying device that storage is no longer in use)

Planned features include:

* Object-level (RAID5-like and RAID6-like) parity-based striping
* Online and offline filesystem check
* Incremental dumps
* Data deduplication

source: wikipedia

As you can see, this is already quite a feature list.

All that is not that important for a filesystem. Most important is that it works, works always and that it is relative fast.
I know very well that Btrfs offers some nice features, but that is no reason to jump the train early.

[JeanPaul145]

All that is not that important for a filesystem. Most important is that it works, works always and that it is relative fast.
I know very well that Btrfs offers some nice features, but that is no reason to jump the train early.

Adding experimental support for btrfs is not jumping the gun early - people who don't exacly know what they're doing or who need a guaranteed stable system will avoid it, but the fs will get huge amounts of testing because of the inclusion. Remember, lots of people are willing to test but compiling a kernel from source and adding userland support is a daunting task even if you DO know what you're doing.

[drag]

All that is not that important for a filesystem. Most important is that it works, works always and that it is relative fast.
I know very well that Btrfs offers some nice features, but that is no reason to jump the train early.

Nah. The most important thing for a file system is that it saves your information safely. At least with Linux. Baring any bugs or design flaws (like some of the more unfortunate Ext3 behaviors) you can almost always increase the performance of your file system by simply purchasing more RAM and letting all your data be in system cache.

This is really the most important thing for performance in desktops.

Now some server loads this is not true if your data on the drive cannot be contained in RAM.. but for 99% of desktop systems aggressive cache'ng is the primary consideration, I figure.

This is why it's important that when your benchmarking file system performance you have to take the RAM into account.

Like, for example, if your trying to benchmark a file system in a virtual machine and you find out your system is 75% faster in the VM then on the host system... this is because of aggressive cache'ng on the host side (putting your data at high risk in event of a system failure)

With the extra data protection and management features BTRFS offers then it's a desirable FS even if your performance is 50% of what it is in Ext4. Luckily for us, Linux devs are very performance sensitive and they will not do things like require your system to be 64bit and have over 4GBs of RAM for file system cache in order to have decent performance. (unlike some other systems from a certain sunny company)


---------------------

Personally I would not mind Ubuntu making BTRFS standard right now. All those massive numbers of users losing data and finding weird bugs in Btrfs would mean that the file system would mature at a very rapid pace making it safer for me to use personally sooner then would otherwise be possible.

Of course that sort of thing would be a downside for Ubuntu's users and Ubuntu's reputation.

[bugmenot2]

Btrfs support in grub2 stalled by legalities

The upsteam grub2 developers have been wanting to add btrfs support to grub2 but that effort has been stalled somewhat because of legal issues since grub2 is gplv3 and some needed files are gplv2 only:

http://www.mail-archive.com/[email protected]/msg03107.html

While in that mail Chris Mason states that "We can provide a GPLv3 version for this file." as far as I know this has yet to actually happen, even though that message is from back in September 2009.