Please create an account to participate in the Slashdot moderation system

 


Forgot your password?
Close
typodupeerror
×
Ubuntu Data Storage Linux News

Btrfs Could Be the Default File System In Ubuntu Meerkat 269

Posted by Soulskill from the shake-things-up dept.
An anonymous reader writes "The EXT family of file systems (ext2, ext3, ext4) have ruled many Linux distributions for a long time, and Ubuntu has been no exception. But things may no longer be the same for Ubuntu 10.10 Maverick Meerkat. Canonical's Scott James Remnant said in a blog post that plans are on for doing work to have btrfs as an installation option, and that the possibility of making it the default file system in Ubuntu 10.10 has not been ruled out."
This discussion has been archived. No new comments can be posted.

Btrfs Could Be the Default File System In Ubuntu Meerkat More

Btrfs Could Be the Default File System In Ubuntu Meerkat

Comments Filter:

  • Hmm... I am going to pass for now on servers... (Score:5, Interesting)

    by ls671 ( 1122017 ) * on Friday May 14, 2010 @04:32PM (#32213458) Homepage

    Hmm... I am going to pass for now on servers. I might try it on desktops/workstations. Not that I use Ubuntu at all. Btrfs is supported by kernel 2.6.32 on other distros as well if you care to configure it properly.

    I remember failure stories with other latest and greatest filesystems lately and I will let others continue to test and identify bugs before I use it on servers/SAN with critical data.

    From the btrfs wiki https://btrfs.wiki.kernel.org/index.php/Main_Page [kernel.org] :


    btrfs is a new copy on write filesystem for Linux...

    Btrfs is under heavy development, but every effort is being made to keep the filesystem stable and fast. As of 2.6.31, we only plan to make forward compatible disk format changes, and many users have been experimenting with Btrfs on their systems with good results. Please email the Btrfs mailing list if you have any problems or questions while using Btrfs.

    • From the article:

      [The decision to make btrfs default] would only made with the knowledge that production servers and desktops can be run on Lucid as a fully supported version of Ubuntu at the same time. I’d give it a 1-in-5 chance.

      So it would appear that you are not the only one who would only run it on a server...

      • From the article:

        [The decision to make btrfs default] would only made with the knowledge that production servers and desktops can be run on Lucid as a fully supported version of Ubuntu at the same time. I’d give it a 1-in-5 chance.

        So it would appear that you are not the only one who would only run it on a server...

        Of course, that should be who would not run it on a server...

    • I've run filesystems that were considered ok-but-early-adopter on servers before. Early XFS releases, for example. It's perhaps not really comparable as SGI had already developed XFS v1 on their workstations and so most of the code was fairly heavily-tested before the Linux port of XFS v2. But there's another consideration - if you look at the way btrfs is described, most of the individual components look a lot simpler than are used in other next-gen filesystems. The difference isn't great between, say, a b-tree and a b+tree or a b*tree, and most filesystem coders are well beyond the stage of making errors on simple abstract data types (right?), but simple components assembled in complex ways are generally more trust-worthy than complex components assembled in simple ways.

      In fact, going back to the early XFS days (when SGI released Red Hat installers and even a few releases before), I found XFS to be much more stable and much more reliable than reiserfs, even though reiserfs has been around longer and was considered mainstream.

      • reiserfs is a nightmare if you care the slightest about safety of your data.

        It comes from the guy who says any filesystem has to be recoded from scratch every five years. Having two separate machines have every single file >4KB shredded weeks after installing and some light use is appalling, especially that no other filesystem ever made me lose more than a handful of files per disaster (mechanical disk failures excluded).

        • Re:Hmm... I am going to pass for now on servers... (Score:5, Interesting)

          by icebike ( 68054 ) on Saturday May 15, 2010 @12:59AM (#32217564)

          Two is your sample size?

          I ran reiser on 108 production servers for years and never lost a byte of data due to the FS. It was robust as hell.

          We had two instances where power surges did take down a server all we needed to do was mount the drive in another machine and run reiserfsck. The resize capability was a godsend.

          I suggest your problem was somewhere other than Reiserfs.

        • Filesystem safety (Score:3, Interesting)

          by jd ( 1658 )

          I agree that reiserfs has issues, having lost a few filesystems that way. Filesystem integrity is not something calculated from how long the system is marked production or even how stable some find it. We need better tools to stress filesystems so we can quantifiably measure safety for specific types of work. (I expect different results for different conditions, since some find reiserfs works for them.) Just as well Slashdotters are so good at causing stress...

      • Re: (Score:2)

        by CAIMLAS ( 41445 )

        but simple components assembled in complex ways are generally more trust-worthy than complex components assembled in simple ways.

        This is (probably?) true. At least it sounds true. :)

        It doesn't hold true for XFS (I seem to recall the code was reasonably complex), but I've heard it holds true for ZFS. The first release of ZFS was incredibly small/few lines of code, and it's really not all that large as it sits today.

        In fact, going back to the early XFS days (when SGI released Red Hat installers and even a few releases before), I found XFS to be much more stable and much more reliable than reiserfs, even though reiserfs has been around longer and was considered mainstream.

        I started using XFS in the summer of 2000 on Linux (this was at least 6 months before reiserfs was released). I started building servers with it (Debian, of course) in the spring of 2001. In that time, I've had a total of t

    • Meego is already switching:

      http://www.phoronix.com/scan.php?page=news_item&px=ODIzOA [phoronix.com]

      This is happening sooner than I thought. Maybe people are just getting pig sick of long fscks on large drives and partitions, which ext4 just doesn't solve to any degree of sastisfaction? I know I am.

      Server-wise I run a lot of OpenVZ machines and snapshotting them through LVM and occasionally fscking the volume, which you have todo, is painful. ext3 has outlived its usefulness there. I could move to XFS but XFS

  • Ubuntu... (Score:3, Funny)

    by ProdigyPuNk ( 614140 ) on Friday May 14, 2010 @04:39PM (#32213542) Journal
    Making Debian look better with every release!

    • It's OK, now that someone leaked this top secret info, Ubuntu will back pedal, scrub the site of any mention of btrfs and then go back to the normal use of EXT$nextver.

      • Re: (Score:3, Insightful)

        by Requiem18th ( 742389 )

        Ubuntu won't install some poorly tested alpha quality file system until the next LTS and viceversa, a filesystem can't make it into ubuntu unless its buggy enough to get into the LTS a week after feature freeze.

    • Making Debian look better with every release!

      I don't know, there's been an Ubuntu machine in my music studio running mission critical applications for half a decade, and every time there's a new release, I install the new OS. Not once have I had to revert to the previous Ubuntu release.

      When I first decided that Linux had a place in my studio, for things like serving up samples, off-loading real-time effects processing chores (using ReaMote in Cockos Reaper) and rendering masters, I originally decided to us

      • I can second that.

        I'm a hard core Unix admin and systems programmer with over 25 years experience, and I can vouch that for desktop use, Ubuntu puts the polish on its 95%+ Debian core. Sure, I can make Debian function as a desktop, but always with every released version of Debian it requires my Unix experience to get everything to work.

        Debian is awesome for servers. But I'm using Ubuntu LTS on my laptop, home and work desktop.

  • ZFS comparison (Score:3, Informative)

    by GoNINzo ( 32266 ) <<moc.oohay> <ta> <ozNINoG>> on Friday May 14, 2010 @04:42PM (#32213580) Journal
    Alternately, you could consider using ZFS if you can live with the uncertainty of the opensolaris project. The major plus is that all the functionality is already there.

    ZFS has all the features that btrfs hopes to achieve already, plus major speed increases when using an SSD drive. When you have a read taking place in .3 ms instead of 9 ms, the speed increases are incredible.

    My hope is that ZFS can be salvaged after Oracle decides what to do with the opensolaris project. If it's on linux, even better.

    • Re: (Score:3, Informative)

      by EvanED ( 569694 )

      Alternately, you could consider using ZFS if you can live with the uncertainty of the opensolaris project. The major plus is that all the functionality is already there.

      Don't forget that FreeBSD has a native implementation of ZFS as well. (You can also get ZFS for FUSE, but as such it's probably not suited for a main file system.)

      • Re:ZFS comparison (Score:4, Interesting)

        by CAIMLAS ( 41445 ) on Friday May 14, 2010 @08:28PM (#32215974)

        Despite FreeBSD now having version 13 implementation of ZFS in 7.3 and 8.0 RELEASE, it's still a complete gongshow. (I'd argue that's largely the case with FreeBSD methods in general - lacking "best practices" and all that, but I'm sure I'd get flamed.)

        In the 7.x releases, there's support for ZFS. It works, mostly, with some cryptic kernel loader configuration changes to set memory allocation and the like - provided you've got at least 4GB of RAM. Otherwise, expect instability and file loss.

        In 8.0 RELEASE, this situation has been much improved. Except there's still no ability to boot from ZFS directly, and so you're stuck with a half-assed kludge. The workable technique of booting from USB devices in 7.x no longer is on account of the "new and improved" USB stack which uh, isn't improved on account of it barely ever working properly (storage doesn't get recognized, devices falling off the bus, little stuff). Oh yeah, and the "needs 4GB of RAM, or else" issue is still there, though in light of everything else is relatively minor.

        • Re: (Score:3, Informative)

          by Anonymous Coward

          FreeBSD 8-STABLE is now at zfs pool version 14 and you can now boot from zfs directly if you wish so. I don't because, well I use full disk encryption with geli so I need a separate boot partition anyway. And though my laptop indeed have 4GB of memory, I still have 2.5GB free after a few hours of using Gnome, Firefox, Thunderbird, PostgreSQL and a bunch of xterm... Although I use usb keys, webcam, mouse, printer, I don't have any usb related problems so I guess I'm just lucky.

          All in all, it beats the crap o

        • Re: (Score:2)

          by GiMP ( 10923 )

          Could we get some references in regard to problems with ZFS on FreeBSD with less than 4GB of RAM? Or at least, some personal experience or explanation for this statement? Preferably in regard to version 8, as arguably, anyone with problems on 7.x could "simply" upgrade.

          The ZFS Tuning Guide for FreeBSD indicates, simply, that one should have at least 1GB of RAM.

    • Re:ZFS comparison (Score:5, Informative)

      by phoenix_rizzen ( 256998 ) on Friday May 14, 2010 @04:55PM (#32213732)

      ZFS is also available in FreeBSD 7.0 and later. It's even marked as "production quality" in FreeBSD 8.0 and later.

      It's a few versions behind (ZFSv14) OpenSolaris (ZFSv24), but on par with Solaris 10 (ZFSv15). FreeBSD 8.1 should have ZFSv15 in it by the time it's released this summer. And there's work ongoing to bring ZFSv20-something into 9.0.

      • 8.0 and OpenSolaris both support booting from ZFS. (Using the latest Grub, which the OpenSolaris contributed the ZFS.mod).

        Having lost one of my mirrored boot drives and replacing it without a hiccup was nothing short of amazing. ZFS is very easy to use from the command line.

        After fighting with Xen on Linux (and the billion different config instructions.). I finally just installed it in OpenSolaris and was done with it. (It's as simple as an 'apt-get' in debian).
        My home server is a quad core CPU with 8GB of

      • Re: (Score:3, Informative)

        by Anonymous Coward

        ...except it's not production quality. Please skim the past 6-8 months of posts to the freebsd-fs and freebsd-stable lists: you'll be surprised at the number of error reports.

        Booting from a ZFS pool on FreeBSD is also somewhat broken; users are still reporting issues with it, and booting from raidz still doesn't appear possible. Supposedly booting from a ZFS mirror works.

        Simply put: if you want to use ZFS and expect stability, run OpenSolaris or Solaris 10.

    • btrfs may have a better foundation (Score:5, Interesting)

      by thule ( 9041 ) on Friday May 14, 2010 @05:11PM (#32213916) Homepage
      But btrfs may actually have a better foundation than ZFS. When ZFS was first conceived they didn't believe a file system could do btree's and COW. btrfs has proven that it can be done. See the section "btrfs: Pre-history" at:

      A short history of btrfs [lwn.net]

      • volume management (Score:2, Interesting)

        by Anonymous Coward

        But btrfs may actually have a better foundation than ZFS. When ZFS was first conceived they didn't believe a file system could do btree's and COW. btrfs has proven that it can be done. See the section "btrfs: Pre-history" at: A short history of btrfs [lwn.net]

        And ZFS incorporates volume management, so no more pvcreate/vgcreate/lvcreate rigamarole; and LVM doesn't even give you mirroring/RAID--you have you have to use a completely different software stack for that.

        You can have your b-trees, I'll take my "zpool create <mirror|raidz[1-3]> <devs>", thanks. "zfs send/recv" is also awesome.

        Just waiting for built-in crypto and "bp rewrite" now, but otherwise I've been happily using ZFS in production for a few years.

        • Re:volume management (Score:5, Informative)

          by diegocg ( 1680514 ) on Friday May 14, 2010 @06:27PM (#32214810)

          Obviously, Btrfs also does volume management without LVM. It even manages to do better than ZFS in some areas, for example Btrfs can reduce the pool capacity easily thanks to back references [kernel.org] (a new and cool fs technique which is being incorporated to Btrfs), whereas ZFS still can't reduce the capacity of a pool and it will take a lot of complexity to implement it (you really should read the link)

        • Re: (Score:2)

          by Cyberax ( 705495 )

          Btrfs has built-in volume management (including intelligent RAID) too...

      • Now why would they believe that in 2007? Volume Shadow Copy, implemented on MS Server 2003 and in Vista clients, uses COW on top of NTFS, which is B+ Tree. I mean reading that it sounds like the basic system they use is rather similar to NTFS. No problem there, NTFS works quite well, however it seems to be this sort of willful, or perhaps pretend, ignorance that such a thing didn't already exist and work well in a major OS.

        • NTFS? (Score:2)

          by thule ( 9041 )
          I don't know that NTFS implements their shadow system like btrfs. If they do, you might want to inform IBM and ACM Transactions on Computational Logic and let them know that they should have publish Microsoft's research instead. The paper the refer to was published August 2007.

          B-trees, Shadowing, and Clones [tau.ac.il] by Ohad Rodeh, IBM Haifa Research Labs.

    • Re:ZFS comparison (Score:5, Interesting)

      by jtosburn ( 63943 ) on Friday May 14, 2010 @05:12PM (#32213924)

      I think you don't give quite enough credit to btrfs; it isn't merely a johnny-come-lately, but rather another step forward in filesystem evolution. Try here [lwn.net] for a good article on btrfs, by one of the zfs developers, Valerie Aurora. If you like, just skip to the section entitled "btrfs: A brief comparison with ZFS", one flamebait bit of which is this: "In my opinion, the basic architecture of btrfs is more suitable to storage than that of ZFS."

      With that said, no one thinks it's ready for critical data storage yet.

    • Re:ZFS comparison (Score:4, Informative)

      by ducomputergeek ( 595742 ) on Friday May 14, 2010 @07:32PM (#32215444)

      Or you can run FreeBSD 8, which has ZFS and has had DTrace for a while now.

  • It hasn't been ruled out, but it is ruled unlikely (Score:5, Informative)

    by pwagland ( 472537 ) on Friday May 14, 2010 @04:47PM (#32213636) Journal
    From the article:

    It’s a tough gauntlet, and it would only made with the knowledge that production servers and desktops can be run on Lucid as a fully supported version of Ubuntu at the same time. I’d give it a 1-in-5 chance.

    There are quite a few pre-conditions for it to be made alpha, so it is not as likely as the summary makes it out to be.

    • Re: (Score:3, Funny)

      by emj ( 15659 )
      Thank you, exacly what I wanted to say. I mean it hasn't been ruled out that the Meerkat CDs will ship on ICMB from South Africa, which is slightly more likely than the CDs shipping with Btrfs as default.

  • Will btrfs have it or not? Stolen laptops want to know.

  • features (Score:5, Informative)

    by Lord Ender ( 156273 ) on Friday May 14, 2010 @04:52PM (#32213692) Homepage
    The main Btrfs features include:

    Extent based file storage (2^64 max file size)
    Space efficient packing of small files
    Space efficient indexed directories
    Dynamic inode allocation
    Writable snapshots
    Subvolumes (separate internal filesystem roots)
    Object level mirroring and striping
    Checksums on data and metadata (multiple algorithms available)
    Compression
    Integrated multiple device support, with several raid algorithms
    Online filesystem check
    Very fast offline filesystem check
    Efficient incremental backup and FS mirroring
    Online filesystem defragmentation
    Currently the code is in an early implementation phase, and not all of these have yet been implemented. See the Development timeline for detailed release plans.

    https://btrfs.wiki.kernel.org/index.php/Main_Page
  • Btrfs or butterfs. This should go smoothly. I hear it's throughput is very fast.

  • Ubuntu speculation? MeeGo confirmation wins. (Score:3, Informative)

    by Anonymous Coward on Friday May 14, 2010 @04:58PM (#32213752)

    Btrfs will be the default filesystem for MeeGo:

    http://article.gmane.org/gmane.comp.handhelds.meego.devel/1510 [gmane.org]

  • Granted, I'm usually a version behind on Ubuntu. I've just upgraded to 9.1 recently. However, with ReiserFS, EXT and other file systems seeming to be very well seasoned and working, why bring in something completely new?

    • Because stability is extremely boring. And difficult to charge for services on things that never break.

      • And difficult to charge for services on things that never break.

        Charge?

        10.10 won't be a LTS release, so nobody in their right mind would use it for enterprise servers/desktops, and I doubt anyone buys home desktop support from Canonical.

        • OEMs do. Canonical's business operations are largely opaque to the community. Sources of revenue I've discovered include: OEMs like Dell buying engineering support contracts for their Ubuntu laptop/netbook offerings, hardware manufacturers paying Ubuntu to port to their new platform, and OEMs like Toshiba paying Canonical to run certification testing.

          For netbooks, faster boot and performance is a feature worth pursuing. At this point all I've seen is Scott mention they'll try it and test it before the point

    • Re: (Score:3, Informative)

      by Artifakt ( 700173 )

      Reiser is basically out - it's simply not being developed fast enough to keep up with the curve. EXT 4 seems unstable.
      (Just my humble opinion, but I went back to EXT 3 for a complete reinstall of Kubuntu 9.4 after giving it a try for a good 3 months, and I've been installing various Linux's since stormlinux back in 2001. I haven't completely wiped an install (well, not at the cost of losing any data that might have even minimal value at all) and rebuilt from scratch in years, outside o

  • Right (Score:5, Insightful)

    by dnaumov ( 453672 ) on Friday May 14, 2010 @05:13PM (#32213938)
    This is a filesystem, where the developers keep finding major (including fatal) bugs basically every other week. If even the slightest idea of making it the default filesystem in a distribution scheduled for release in 6 months crosses your mind, seek professional help. Now.

    • Re: (Score:2)

      by Pecisk ( 688001 )

      In distribution, which have claimed several times, that they suggest to use LTS releases, leaving regular releases for early adopters.

      p.s. ZFS have had fatal bugs too after major stable release.

    • Re:Right (Score:5, Informative)

      by diegocg ( 1680514 ) on Friday May 14, 2010 @06:08PM (#32214576)

      Indeed. Btrfs is still making disk format changes. They aren't very serious, but hey, they are there. Not a sign of stability, no matter how much cheksumming you throw at it.

  • Better Options (Score:4, Insightful)

    by sunderland56 ( 621843 ) on Friday May 14, 2010 @05:33PM (#32214164)
    How about either
    • Having no default, and presenting a list of options (with suitable help, detailing why each would be a good or a bad choice); or
    • Having an intelligent default, based on disk capacity, use (i.e. boot volume or not), and technology (magnetic versus solid state)

    • Re: (Score:2, Insightful)

      by Daengbo ( 523424 )

      Your second point is very good, but Ubuntu has always been about opinionated choices. When 4.10 came out, it was decided to forgo the normal Linux 5 CD installation's 10 text editors, four word processors, and three browsers (practically required in the early 2000s because some apps worked for some things and not for others) and instead install just one type of each application on one CD. In short, having no default totally goes against their mission.

      The installer always gives you the option to go advanced

  • Speak on... who owns the inevitable patents on it? Where is the clear, explicit and irrevocable patent licensing or covenant on them?

    No... no, I think I'll pass on it. You're either trusty-worthy, or you're not.

  • Personally, I'm using reiserfs (that is, reiser3, not reiser4) solely due to its outstanding disaster recovery capabilities. No matter what happens to the media or the filesystem itself, "reiserfsck --rebuild-tree" is going to bring back everything that was not directly overwritten or corrupted. I've had many things happen to my disks (head crashes, several gigabytes from the beginnig of the partition being overwritten by a borked OS isntaller, "rm -rf blah/ *" instead of "rm -rf blah/*" and so on), and every single time, --rebuild-tree recovered everything that still was there to be recovered. As far as I know, this is due to the fact that all the filesystem metadata is distributed evenly throughout the partition, heavily replicated and identifiable using some kind of magic hashes even when there is no higher-order structure left (so a --rebuild-tree process can just do a linear scan of the damaged partition and find all the "dangling" inodes with ease).

    As far as I know, this is not possible (especially using the standard fsck utility as with reiserfs) with the ext* family of filesystems.

    So, does btrfs have similar capabilities? If so, I'm going to be quite interested in testing it, even though I'm not using Ubuntu.

    • Re:Is it better in the recovery department than ex (Score:4, Interesting)

      by kimvette ( 919543 ) on Friday May 14, 2010 @11:43PM (#32217206) Homepage Journal

      I used to run Reiserfs after having a VERY bad experience with EXT3, but I've since switched back to EXT3 now that it's a lot more mature.

      What did I like about Reiser? Exactly as you described; I never saw --rebuilt-tree fail. I've had NTFS and EXT2 and EXT3 partitions go bad but I have never had a ReiserFS partition become unrecoverable; if the drive spun up and could be enumerated by the OS, reiserfsck could retrieve everything even if it appeared lost. I also really liked the zero-slack feature (no wasted disk space!)

      Why did I finally abandon ship?

      Honestly, it was performance.

      Writes are fast under reiser -- VERY fast. It is super reliable - I've never expected any filesystem to be so resilient.

      What was wrong with it then?

      Deletes. Deletions take for-freaking-ever. Right-click a file on a reiserfs partition in konqueror, and wait and wait and wait (watch the minute hand move on a clock or watch!) for the context menu. Delete a folder containing 70K files? Start the delete, come back an hour later, and see the deletion is still going. It is dreadfully slow deleting files. Do the same to an EXT3 (or now, EXT4) partition, an XFS partition, or even NTFS (via NTFS-3G) partition, and the deletion will take seconds - or maybe a minute for really immense directories. Reiser? s. . . . l. . . . o. . . . .w. . . that was honestly the only thing I could find wrong with Reiser (the FS, obviously, not the mama-killing douche of a meatbag who is hopefully being raped and beat up daily)

  • Butterface.

Slashdot Top Deals

You are always doing something marginal when the boss drops by your desk.

Close