Page 1 of 4 123 ... LastLast
Results 1 to 10 of 34

Thread: Ubuntu Has Plans For Btrfs In 2011, 2012

  1. #1
    Join Date
    Jan 2007
    Posts
    15,659

    Default Ubuntu Has Plans For Btrfs In 2011, 2012

    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

  2. #2
    Join Date
    Oct 2009
    Posts
    101

    Default

    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.

  3. #3
    Join Date
    Oct 2009
    Posts
    111

    Default

    Quote Originally Posted by waucka View Post
    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.

  4. #4
    Join Date
    Nov 2009
    Posts
    328

    Default

    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.

  5. #5
    Join Date
    Apr 2008
    Location
    Saskatchewan, Canada
    Posts
    466

    Default

    Quote Originally Posted by waucka View Post
    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.

  6. #6
    Join Date
    Aug 2008
    Posts
    116

    Default

    Quote Originally Posted by mat69 View Post
    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.

  7. #7
    Join Date
    Oct 2009
    Posts
    111

    Default

    Quote Originally Posted by JeanPaul145 View Post
    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.

  8. #8
    Join Date
    Aug 2008
    Posts
    116

    Default

    Quote Originally Posted by mat69 View Post
    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.

  9. #9
    Join Date
    Sep 2006
    Posts
    714

    Default

    Quote Originally Posted by mat69 View Post
    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.

  10. #10
    Join Date
    Apr 2010
    Location
    My Parents Basement
    Posts
    52

    Default 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/linux-bt.../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.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •