Ubuntu Has Plans For Btrfs In 2011, 2012

[Yfrwlf]

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.

Hmm, so Fedora is using Grub1 still?

[RahulSundaram]

Hmm, so Fedora is using Grub1 still?

GRUB1 is the default. GRUB2 is a development snapshot still. There has been no stable release yet and it appears the configuration file formats might change yet. Fedora does include GRUB2 in the repository but you will have to choose it explicitly.

[kebabbert]

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)

Well if you refer to Sun's ZFS, yes, it caches very agressively. But I have ran ZFS on a Pentium 4 and 1GB RAM for over a year. It does work, albeit slowly. I got like 30MB/sec on my ZFS raid. As ZFS is 128bit, it likes 64bit CPUs, and then reaches easily several 100s of MB/sec.

ZFS does not need 4GB of RAM and 64 bit CPUs to work well. Yes it will be slow, but it will work. If you need good performance on an Enterprise server, you need several GB of RAM for disk cache.

I doubt BTRFS will have decent performance with less than 4GB RAM on an Enterprise server. Maybe you have only used desktops and extrapolate your conclusions to Enterprise servers. To cache well you NEED much RAM. BTRFS will be not different, it will also need lots of RAM to cache well. It is impossible to cache well, if you have too little RAM.



Regarding safey about ext3, JFS, ReiserFS, XFS, etc - they all suck. They can not handle basic silent corruption scenarios and corrupt data easily, without even telling you. I doubt that BTRFS will be able to handle silent corruption better no research has been done on BTRFS yet. Sure, all filesystems have checksums, and discs have checksums to detect errors, etc, but still many errors are unnoticed. To handle silent corruption is difficult and many years of experience is needed from Enterprise environments. To make bullet proof silent corruption detection is VERY difficult, all fileystems (except ZFS) fail this test. (All these statements above are based on research from computer scientists. You can google those PhD dissertations and papers, or, I can post them here for you that shows that Linux file systems fail corruption detection tests, except BTFS because it has not been tested yet. ZFS detected all data corruption tries.)

[Drago]

Well ZFS is open source, so BtrFS need not to reinvent the wheel, right?

[waucka]

Well ZFS is open source, so BtrFS need not to reinvent the wheel, right?

ZFS is under a license that is not compatible with the GPL, thus the code cannot simply be added to the Linux kernel. We would need an entirely new implementation of it.

Also, btrfs aims to ultimately offer more than ZFS. I couldn't tell you what, since I haven't been following filesystem development very closely, but the btrfs developers have said that they intend to "leapfrog" ZFS.

[kebabbert]

ZFS is under a license that is not compatible with the GPL, thus the code cannot simply be added to the Linux kernel. We would need an entirely new implementation of it.

Though ZFS ports exists. FreeBSD runs it. And Apple OS X ran it for a while, until Steve Jobs demanded special treatment for the license.

Also, btrfs aims to ultimately offer more than ZFS. I couldn't tell you what, since I haven't been following filesystem development very closely, but the btrfs developers have said that they intend to "leapfrog" ZFS.

But this is good. Competition is always good! This forces ZFS and BTRFS to become better!

On a side note, it is said that it takes half a decade for a file system to stabilize after release v1.0. Look at ZFS, even now it still has bugs. And ZFS will not rest. When BTRFS has been released, ZFS will have made great strides. BTRFS looks at ZFS and tries to mimic it. It is a bad strategy I think, instead it should try to be original instead of copying. It is like Microsoft copying Mac OS X with Windows 7.

[kebabbert]

DTrace with the same license, is ported to Mac OS X - so the license is not actually a problem when we talk about ZFS. DTrace is also ported to QNX and FreeBSD.

[bugmenot2]

GRUB2 is a development snapshot still. There has been no stable release yet and it appears the configuration file formats might change yet. Fedora does include GRUB2 in the repository but you will have to choose it explicitly.

grub2 has had multiple stable releases (most recently 1.97 and 1.98). I'f you're only going by version numbers then grub legacy, at 0.97, has also never had a stable release. It is true though that the grub.cfg syntax may change slightly in future releases.

[kraftman]

BTRFS looks at ZFS and tries to mimic it. It is a bad strategy I think, instead it should try to be original instead of copying. It is like Microsoft copying Mac OS X with Windows 7.

Why it's a bad strategy? I think btrfs is here to kill ZFS.

[movieman]

DTrace with the same license, is ported to Mac OS X - so the license is not actually a problem when we talk about ZFS.

How is porting to Mac OS X relevant to porting to Linux?

I was reading a thread on one of the ZFS mailing lists recently talking about why ZFS will probably never be in the Linux kernel, and that's both because of the license and because it's a very bad fit for the Linux filesystem model.

Incidentally, Oracle now both own ZFS and support btrfs development so I'll be interested to see what they do from here.