Follow Slashdot stories on Twitter

 


Forgot your password?
Close
typodupeerror
×
GNU is Not Unix News

GRUB 1.99 Released With Support For ZFS and BtrFS 175

Posted by CmdrTaco from the boot-grub-joke-goes-here dept.
kthreadd writes "GNU GRUB has been updated to version 1.99. Among the many improvements are support for two new filesystems, BtrFS and ZFS. For Linux users this means that it's now possible to move to BtrFS entirely and not use it only for non-bootable volumes."
This discussion has been archived. No new comments can be posted.

GRUB 1.99 Released With Support For ZFS and BtrFS More

GRUB 1.99 Released With Support For ZFS and BtrFS

Comments Filter:

  • I was just wondering when we'd get support for ZFS, now that I can install GRUB2 on FreeBSD. Now, next chance I get, I can reinstall the various OSes on my computer and hopefully create a situation where I can triple boot things.

  • Needs better support for really old tech. (Score:5, Funny)

    by thomasdz ( 178114 ) on Tuesday May 17, 2011 @12:35PM (#36156052)

    Until it supports booting from paper tape or punch card, I'm not going to trust it 100%

    • silly, don't need grub but of course inux S390 can boot from card reader (virtual or physical), it the way its usually done under Hercules, for example. Since the console or running z/VM can boot other OS, why would you need grub?

  • Filesystem bandwagon (Score:3)

    by billcopc ( 196330 ) <vrillco@yahoo.com> on Tuesday May 17, 2011 @12:45PM (#36156276) Homepage

    I know about ZFS (somewhat), but what's the big appeal of Ext4 and BtrFS ? Cool that Grub can boot from them, but do they confer any tangible benefits for desktop users ?

    For personal use, I care about two things:

        1. How safe is my data
        2. How quickly can I access it

    Ext3 seems to address both concerns quite acceptably, so what do these newer filesystems do better ? And why would anyone want to use that on their boot partition ?

    • Re:Filesystem bandwagon (Score:5, Insightful)

      by GameboyRMH ( 1153867 ) <gameboyrmh@@@gmail...com> on Tuesday May 17, 2011 @01:05PM (#36156620) Journal

      Ext4 is a more error-resistant (safer) and potentially faster Ext3. If you don't know what BtrFS is good for, you don't need to use BtrFS (although it could become a mainstream filesystem some day).

    • BtrFS is essentially moving towards ZFS regarding features. EXT4 has a few features that make it more scalable than ext3. You'd want this on your boot partition so you can remove support for legacy filesystems that are "only good for boot partitions" from your kernel.

    • Re:Filesystem bandwagon (Score:4, Interesting)

      by hedwards ( 940851 ) on Tuesday May 17, 2011 @01:06PM (#36156654)

      I'd take a look here: Btrfs [wikipedia.org] The main problem I have with it is that there's a large number of filesystems out there and while that's not really a bad thing, it makes interoperability a real headache sometimes. Personally, I'd rather have a somewhat less than perfect filesystem (assuming that it is reliable than a huge variety of specialty filesystems which may or may not be readable under any other OS.

      And apart from ZFS suffering from NIH problems as well as the CDDL licensing, I really don't see any compelling reason to add yet another filesystem that does largely the same thing.

      • Re: (Score:2)

        by Rich0 ( 548339 )

        And apart from ZFS suffering from NIH problems as well as the CDDL licensing, I really don't see any compelling reason to add yet another filesystem that does largely the same thing.

        The licensing is by far the biggest problem with ZFS. It will never be part of the kernel - so this isn't ZFS vs btrfs, but rather btrfs vs nothing (or ext4/etc).

        • Re: (Score:2)

          by d3vi1 ( 710592 )

          ZFS doesn't really suffer from licensing problems. The OpenSolaris derived implementations (Solaris/FreeBSD/OpenIndiana), do however suffer from that problem.
          I would like to point out that ZFS has been available under GPL for a long time as GRUB patches to Solaris/OpenSolaris/Solaris_Express, and just recently integrated into the mainstream GRUB.
          The only milestone to adopting it in Linux is the insane amount of work. The GRUB implementation is GPL and it clearly exposes the internals of ZFS enough to implem

      • Re: (Score:2)

        by Simon80 ( 874052 )
        I think it's grossly unfair to characterize the huge amount of effort that someone puts into a filesystem as merely being a case of NIH, when something genuinely interesting and better is being produced. For example, you can remove a disk from a Btrfs volume (or shrink the volume) while it's in use. There's also a tool that not only converts ext3/4 volumes to Btrfs in-place, but also does it in such a way that you can mount the volume in Btrfs, change your mind, and go back to using it in ext4, because the

        • Well, how else do you explain Linux' obsession with having a filesystem that nobody else can use?

          I've lost enough data over time from those filesystems going down in flames to realize that historically they suck. Now Btrfs and Ext4 are a lot better, but lets be honest about the fact that historically Linux has had serious problems with its filesystems and one has to be kind of wonky to trust it with any important data.

          I'm not sure how to interpret that other than NIH, bear in mind that the primary reason fo

          • Re: (Score:2)

            by Simon80 ( 874052 )
            I've been using Linux for 5+ years with no data loss, but maybe it was more problematic before then, I don't know. Ext3 was standard by the time I switched over. As to why Linux has its own filesystems, there's actually a much more reasonable explanation [kerneltrap.org] for that than NIH syndrome. Besides, that accusation doesn't make sense when every other popular OS also has its own filesystem. It's not like they're deliberately avoiding a standard. Which other incompatible FS are they supposed to be compatible with?

          • Re: (Score:2)

            by ichthus ( 72442 )

            lets be honest about the fact that historically Linux has had serious problems with its filesystems and one has to be kind of wonky to trust it with any important data.

            Google would [arstechnica.com] disagree [slashdot.org] with you.

            • Re: (Score:2)

              by jedidiah ( 1196 )

              Yeah... important data like your Oracle databases.

              Now, since Linux has an open development model people have always been free to live dangerously. You always have the option of being an early adopter and you can get burned by that. However, that's not a Linux failing. That is trolls trying to use the openness of Linux against it.

          • Re: (Score:2)

            by jedidiah ( 1196 )

            > Well, how else do you explain Linux' obsession with having a filesystem that nobody else can use?

            This is just FUD and nonsense.

            ANYONE ELSE can use a Linux file system. It's Free Software

            The idea that Linux filesystems are any less robust than alternatives is also just FUD and nonsense.

            Many of us have been abusing Linux for a good number of years without significant incident or any incidents at all.

      • Re: (Score:2)

        by Sancho ( 17056 ) *

        And apart from ZFS suffering from NIH problems as well as the CDDL licensing, I really don't see any compelling reason to add yet another filesystem that does largely the same thing.

         

        But the licensing is a dealbreaker on Linux. Btrfs being licensed GPL means BSD can't use it. ZFS being licensed GPL means Linux can't use it.

    • Oh since you say you know something about ZFS, BtrFS is basically an open ZFS, so that should tell you something.

      • Interestingly, they're both products of Larry Ellison.
        The Ext* series of filesystems still has a place against the megacorps?

      • Re: (Score:3)

        by d3vi1 ( 710592 )

        The filesystem part, almost matches the ZFS features, but not quite.
        The rest: NO!
        ZFS does a lot more than just being a filesystem, the most important non-filesystem part being the storage pool management in a simple and sane way.
        Some of that might be achievable with LVM, but most of it NO!

        Returning to the filesystem part:
        When do you think that we'll get NFSv4 ACLs in Linux? Regardless of the filesystem.
        How about iSCSI integration (ZFS style)?
        How about transparent encryption?
        How about transparent compression

        • I'm a Solaris (and other) admin just getting into Linux, and can't for the life of me figure out a point to LVM. Reads from mirrored volumes aren't spread across the mirrors, eg., and who really gives a flip about the soft partitions? There's work on ZFS for Linuxes. I don't know that it has many resources behind it, but it'd sure be nice to have in a usable state. I don't give a rat's ass if it comes bundled into the kernel or not --- I just want it to work properly.

    • Re: (Score:2)

      by grumbel ( 592662 )

      The main advantage that btrfs has isn't speed, but that it can do copy-on-write. For a home user that for example means that he could copy his whole root file system before a dist-upgrade and thus have an easy way to undo the dist-upgrade when he doesn't like it, i.e. two commands that take a second to run thanks to copy-on-write instead of messing with a full backup and replay that might take an hour. Or the ability to have timemachine like backup functionality with essentially no overhead.

      • Re: (Score:2)

        by Rich0 ( 548339 )

        Copy on write also increases striped raid performance as long as there is a reasonable amount of free space, as it avoids having to read a stripe before writing it. This also depends on the whole "rampant layering violation" thing.

      • Btrfs is faster than traditional filesystems for many loads, too. It does suffer from abysmal fsync() speed, though. The latter applies to certain databases -- which are essentially filesystems in a file, and dpkg which fsync()s both the updated files and its info files every roughly a single byte or so. Dpkg includes hacks like sync_file_range(temp file); fsync(temp file); close(temp file); opendir(dir); fsync(dir); rename(temp file, real file); fsync(dir); -- for every single file it operates on, to wo

    • Re: (Score:2)

      by sqldr ( 838964 )

      1. How safe is my data

      Given that btrfs doesn't yet have an equivalent to fsck, not 100%. Then again, if you're running fsck on ext3/4, you've lost some data anyway. It's journalling, so chances of corruption are pretty low. Then again, anything I actually want to keep is in about 4 clones of a git repo. I believe the term for this is "backups" :-)

      2. How quickly can I access it?

      About the same as ext4, give or take. The reasons for going from ext4 to btrfs are much the same as going from UFS to ZFS. F

    • Ext4 trumps Ext3 as soon as you start dealing with files larger then a few hundred MB. When you delete a big file under Ext3, it spends ages and ages playing cleanup. Delete a big file under Ext4 and it takes under a second.

      Personally, I don't see a reason to use Ext4 yet on /boot and probably not the root partition either. When it comes to /boot and root, I prefer to stay very conservative and Ext4 is still a bit young (another 2 years and I'll be more comfortable with it). But I use ext4 all the tim

  • Boot separate from partitions (Score:4, Informative)

    by hoggoth ( 414195 ) on Tuesday May 17, 2011 @12:57PM (#36156486) Journal

    I like having the ability to wipe out and redo any partition without ruining my ability to boot into my other partitions. I typically multi-boot 3 or 4 partitions so this matters to me.

    So I always use an independent boot manager like GAG or PLOP that can boot just about anything else and is drop dead simple to reconfigure. Each partition gets it's own favorite PARTITION boot manager, Grub for Linux, BCD for Windows, etc...

    • And for others there is just one operating system and bootloader might as well sit on / partition. And everybody is happy.

  • GRUB as an OS? (Score:3)

    by gr8_phk ( 621180 ) on Tuesday May 17, 2011 @01:25PM (#36156928)
    At what point does GRUB become more of an OS than a bootloader? Adding multiple file system support seems odd. I understand the reason, but in principle you want the boot loader to be small, not constantly incorporating operating system features. Is there some problem with having a small boot partition that can only be formatted one way? The same issue happened with X.org where it gained memory management, font handling, etc - lots of stuff beyond just being a window system. The same also happened with MESA when it started getting hardware acceleration (for a soft implementation of OpenGL). The same feature creep is also happening with BIOS. Some of these projects need to define what they are and stick to that IMHO. Otherwise, we can just merge GRUB into the kernel and put the whole thing into the flash normally used for BIOS ;-) Maybe not a bad thing ( I think it's bad ) but certainly not 3 distinct software components.

    • Re: (Score:2)

      by Rich0 ( 548339 )

      Well, one of the nice things about linuxbios/etc is that it offers a great deal more versatility.

      Do you really want to have to have a hard drive installed just so that you can boot off of an OS image on a SAN? Or a USB drive or whatever?

      The whole purpose of a boot loader is to find a kernel and boot it. Anything that makes it possible for the bootloader to find a kernel on a more exotic architecture is perfectly in-scope as far as I'm concerned, as long as it doesn't leave anything behind in RAM once it i

      • Re: (Score:2)

        by Skapare ( 16644 )

        Any kernel, anywhere? There's already a tool that can do that. It's called Linux. And it has far more capability than GRUB. Can GRUB grab a kernel via rsync over ssh and boot it? Linux can (be set up to) do that.

        See Kexec [ibm.com].

        I'd rather be able to just have a fixed place to put a kernel, and have that place always boot. LILO isn't good enough because it requires running its "lilo" command to build a block index. The better way to very simply boot a kernel is to sequentially write that kernel to it's own

        • Re: (Score:2)

          by Rich0 ( 548339 )

          Any kernel, anywhere? There's already a tool that can do that. It's called Linux. And it has far more capability than GRUB. Can GRUB grab a kernel via rsync over ssh and boot it? Linux can (be set up to) do that.

          See Kexec [ibm.com].

          And without burning linux in your BIOS, how do you propose to run it on a system that lacks a hard drive? The best you can do right now is PXE, and that has a lot of limitations. At the very least you need to control the dhcp server to do it.

          The parent was arguing that bootloaders should be simple, and I was arguing that complexity is fine if it suits their purpose, which is loading the kernel. I'd love to see LinuxBIOS being standard on all PCs, as it is a more versatile way of finding and loading the k

    • Re:GRUB as an OS? (Score:4, Funny)

      by Opyros ( 1153335 ) on Tuesday May 17, 2011 @03:04PM (#36158152) Journal

      At what point does GRUB become more of an OS than a bootloader?

      When it has integrated EMACS?

      • That is both a hilarious joke and a very insightful take on the progression of GRUB; from my perspective, GRUB seems to be getting a little complicated for a bootloader. It's starting to make me nostalgic for LILO and Loadlin...

    • I want my BIOS so bad ass it runs BSD and needs its own BIOS.

    • The multiple file system support is not odd, it sounds exactly what a bootloader needs to do. It needs to load the OS bits. If the OS bits are on ZFS, HFS+, BTRFS, EXT4, FAT-32, etc, you need to have support for GRUB to read them.

      How else would you propose it works?

  • GRUB 2 at 1.99 *brain explodes*

  • I would probably switch from Ext4 to BtrFS if it had full Gparted support [sourceforge.net].

  • It's neat that we can boot off of them... (Score:4, Funny)

    by Erpo ( 237853 ) on Tuesday May 17, 2011 @01:49PM (#36157226)

    This is really cool. Now when one of these filesystems becomes stable in Linux, we'll be ready to go. Look out 2025--here I come!

    • Re: (Score:2, Interesting)

      by Anonymous Coward

      Actually, Btrfs is quite stable. I have been using it since the last december. Cero problems (except fragmentation, which is something that you should expect from COW-based filesystems like ZFS or Btrfs - fortunately, btrfs includes defragmentation tools). Developers have focused into making it stable instead of adding features (like being able to change the raid level of your filesystem). As far as I know, the only issue that is sttoping Btrfs from being declared as stable is the lack of fsck (which is an

  • The update is quite good; but seriously ... 1.99? What happens if you find a critical bug - you'll have to go 1.991... when does the insanity end?!
  • My chief complaint [saccade.com] against GRUB is the horrible diagnostics. Would it kill them to put in real error messages instead of unhelpful grunts like:

    ERROR 18

    Has this been addressed in the new version?

  • I've actually been running the system I'm typing from with Btrfs on the root partition for some time now. Since I always have an ext2 /boot partition, I didn't have to worry about this.

    I still wouldn't recommend using Btrfs for / unless you have a separate /home partition, though: there is not yet any fsck.btrfs! In addition to a separate /home partition, I'd recommend having another Linux install with ext4 alongside it, so if something does go wrong with your Btrfs partition, you can boot a fully functiona

  • It was added some time back, but don't forget about being able to boot from RAID5! Most people that I run into still don't know that you can do this. I've been doing it for awhile and it's great for my five-disk home server and a cheapy 4-disk 1U server system I have out in a colocate.

Slashdot Top Deals

Top Ten Things Overheard At The ANSI C Draft Committee Meetings: (10) Sorry, but that's too useful.

Close