Beta
×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

GRUB 1.99 Released With Support For ZFS and BtrFS

CmdrTaco posted more than 2 years ago | from the boot-grub-joke-goes-here dept.

GNU is Not Unix 175

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."

cancel ×

175 comments

Sorry! There are no comments related to the filter you selected.

Does this matter? (0)

Anonymous Coward | more than 2 years ago | (#36155768)

So is BtrFS reliable enough for a stable Linux distro? Or will it be ignored in favor of Ext4?

Re:Does this matter? (3, Insightful)

SanityInAnarchy (655584) | more than 2 years ago | (#36155896)

Ext4 is stable now, and was an easy upgrade from ext3, both in terms of development and in terms of converting your existing filesystems -- one command, and then just remount as ext4, no time-consuming and dangerous conversion needed.

BtrFS looks to be better than ext4 in every way except the above -- and I haven't been following it for awhile, so as far as I know, btrfs might be rock-solid stable by now.

Put another way, ext4 is a replacement for ext3, whereas btrfs is a replacement for zfs.

Re:Does this matter? (1)

Anonymous Coward | more than 2 years ago | (#36155962)

I'd say that btrfs will be the replacement of ext4. Just not yet (at least for me).

Re:Does this matter? (0)

Anonymous Coward | more than 2 years ago | (#36156076)

Ext4 is stable now, and was an easy upgrade from ext3, both in terms of development and in terms of converting your existing filesystems -- one command, and then just remount as ext4, no time-consuming and dangerous conversion needed.

BtrFS looks to be better than ext4 in every way except the above -- and I haven't been following it for awhile, so as far as I know, btrfs might be rock-solid stable by now.

I was mostly wondering because I remember how XFS and JFS were largely ignored by major distros. I use them both on Gentoo, but well... Gentoo's really not mainstream.

Re:Does this matter? (1)

CarsonChittom (2025388) | more than 2 years ago | (#36157022)

I was mostly wondering because I remember how XFS and JFS were largely ignored by major distros. I use them both on Gentoo, but well... Gentoo's really not mainstream.

XFS, at least, was—I'm going on memory here, so somebody correct me if I misspeak—largely ignored because the only place it really shines is when you have lots of very large files (i.e., a typical use on an SGI machine editing video). For a bunch of smaller files (i.e., the normal use case), its performance was worse, or at least no better, than other options, and it wasn't as well supported.

Re:Does this matter? (1)

kvvbassboy (2010962) | more than 2 years ago | (#36156280)

To be honest, nothing matters nearly as much as stability. Unless BtrFS increases my read and write times for both small and large files by a huge amount, a from ext4 to this won't be noticeable for most users. On the other hand, if your files start getting corrupted randomly (like in Windows), people are going to be extremely loud in voicing there dissent.

Re:Does this matter? (0)

Dog-Cow (21281) | more than 2 years ago | (#36156922)

What apps do you run in Windows that cause file corruption? Perhaps you should check your HD for physical defects?

Re:Does this matter? (0)

Anonymous Coward | more than 2 years ago | (#36158460)

--What apps do you run in Windows that cause file corruption? Perhaps you should check your HD for physical defects?...--

Thats simple Windows it is the corruption .

Re:Does this matter? (2, Insightful)

MrHanky (141717) | more than 2 years ago | (#36157132)

If you get random file corruption on Windows, you either have serious hardware failure or use Windows 98.

Re:Does this matter? (0)

Anonymous Coward | more than 2 years ago | (#36157438)

On the other hand, if your files start getting corrupted randomly (like in Windows), people are going to be extremely loud in voicing there dissent.

Hello Mr. Kvvb Assboy,

Can you please explain how these files are getting corrupted randomly in Windows? It sounds like your issue might be more related to hardware, in which case these files will be corrupted no matter what operation system / file system you are using.

Re:Does this matter? (2)

DarkOx (621550) | more than 2 years ago | (#36156694)

BtrFS can upgrade in place as well, and even better it can leave the old file system meta data intact so until you commit the snapshot you can even down grade back to ext2/3 if you like; but you'd loose any other changes made to the file system since the switch to BtrFS as well.

Re:Does this matter? (4, Insightful)

mikael_j (106439) | more than 2 years ago | (#36156822)

Put another way, ext4 is a replacement for ext3, whereas btrfs is a replacement for zfs.

I think you mean that btrfs is a replacement for ext4. Maybe I'm naive and a bit reactionary but I'm just not seeing FreeBSD and Solaris switching to btrfs just because the Linux crowd says it's the greatest thing since sliced bread...

Re:Does this matter? (3, Interesting)

Kamiza Ikioi (893310) | more than 2 years ago | (#36156844)

"In 2008 the principal developer of the ext3 and ext4 file systems, Theodore Ts'o, stated that ext4 is a stop-gap and that Btrfs is the way forward,[10] having "a number of the same design ideas that reiser3/4 had". http://en.wikipedia.org/wiki/Btrfs [wikipedia.org] & http://lkml.org/lkml/2008/8/1/217 [lkml.org]

Re:Does this matter? (2)

GooberToo (74388) | more than 2 years ago | (#36157222)

Ext4 is stable now, and was an easy upgrade from ext3, both in terms of development and in terms of converting your existing filesystems -- one command, and then just remount as ext4, no time-consuming and dangerous conversion needed.

There is a trade off most people don't realize. Ext4 allows for a safe, simple migration from ext3, but in doing so, you do not receive all of the ext4 benefits. Ext4 on disk format differs from ext3. When ext4 mounts an ext3 partition, it is limited to the constraints available of an ext3 on disk format. Otherwise, there would be no need for ext4 to have its own format. To obtain all of the ext4 performance, tweaks, and reliability benefits, you MUST perform an ext4 format.

Re:Does this matter? (5, Informative)

zsitvaij (1150191) | more than 2 years ago | (#36158232)

To obtain all of the ext4 performance, tweaks, and reliability benefits, you MUST perform an ext4 format.

That's not entirely correct. With two commands, you get a full conversion from ext3 to ext4 without a reformat, leaving your data in place:
tune2fs -O extents,uninit_bg,dir_index /dev/DEV
e2fsck -fDC0 /dev/DEV

(On an unmounted filesystem, obviously. Source. [kernel.org] )

Re:Does this matter? (2)

snowgirl (978879) | more than 2 years ago | (#36157402)

I like BtrFS, I used to use ReiserFS, but then apparently he killed his wife or something and it pretty much killed the project. BtrFS seems to be a cool similar form of idea, but updated... like a Reiser4, but without the negative connotation...

Re:Does this matter? (1)

petermgreen (876956) | more than 2 years ago | (#36157602)

hmm, at least from the wikipedia article it doesn't appear to have the killer feature of zfs which is the ability to provide "better than raid" protection for your data though keeping both checksums and multiple copies of the data on different drives.

Re:Does this matter? (1)

Electricity Likes Me (1098643) | more than 2 years ago | (#36158180)

The lack of this in other systems is actually really annoying, since the essential benefit is that if a file gets corrupted then the remaining disks can "vote" on which copy of the data is actually the correct one. As I understand it, in all the common RAID configurations, no such system is implemented even if multi-redundancy is available (i.e. in RAID6 there could be several potentially true copies of your data).

Awesome (1)

hedwards (940851) | more than 2 years ago | (#36155770)

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.

FIRST POST (-1)

Anonymous Coward | more than 2 years ago | (#36155778)

W00t.

whooptie-dolittle (0)

Anonymous Coward | more than 2 years ago | (#36155966)

right, but then why would anyone actually use BtrFS anyway? Maybe things have changed, but my last experience with it went kind of like this:

Hmmm...Ahhhh...hey, cool?!AAAHHH!!!!OMGWTFZOMBIES?!?! (reload software)

Needs better support for really old tech. (4, Funny)

thomasdz (178114) | more than 2 years ago | (#36156052)

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

Re:Needs better support for really old tech. (2)

rubycodez (864176) | more than 2 years ago | (#36156300)

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?

why GRUB? (1)

droidsURlooking4 (1543007) | more than 2 years ago | (#36156060)

My distro ditched LILO a while ago and I miss it terribly. A simple conf file. What more could you ask?

Re:why GRUB? (1)

ae1294 (1547521) | more than 2 years ago | (#36156224)

My distro ditched LILO a while ago and I miss it terribly. A simple conf file. What more could you ask?

Blackjack, Hookers and Blow; provided by the maintainers.

Re:why GRUB? (1)

CarsonChittom (2025388) | more than 2 years ago | (#36157042)

In fact, forget the blackjack!

Re:why GRUB? (0)

Anonymous Coward | more than 2 years ago | (#36156230)

Have a look at /boot/grub/grub.conf sometime. Rather simple.

Re:why GRUB? (1)

rubycodez (864176) | more than 2 years ago | (#36156320)

guess again, old timer. Have a look at /etc/grub.d/ sometime, it's a nightmare

Re:why GRUB? (1)

GameboyRMH (1153867) | more than 2 years ago | (#36156540)

A "nightmare?" It's different. And if you want to see a nightmare, try setting persistent custom bootloader options with grub1, or changing the options for all your boot entries. Happy find-and-replacing.

Re:why GRUB? (1)

rubycodez (864176) | more than 2 years ago | (#36157800)

find-and-replacing in text files is what Unix has been all about for decades, trivial and easy. many nice solution scripts have been written for the "legacy grub" regarding presistent options that are still much simpler than the /etc/grub.d mess

Re:why GRUB? (3, Insightful)

Microlith (54737) | more than 2 years ago | (#36156332)

With GRUB ~= 2.0, you aren't supposed to mess with grub.conf. You're supposed to mess with a shitpile of external .conf files and command line tools.

Re:why GRUB? (0)

Anonymous Coward | more than 2 years ago | (#36156258)

So, what exactly is grub.conf? Chopped liver?

Re:why GRUB? (1)

rubycodez (864176) | more than 2 years ago | (#36156344)

gone in many modern distros, replaced by a directory full of complex stuff

Re:why GRUB? (1, Informative)

Hatta (162192) | more than 2 years ago | (#36156290)

I agree. From an ease of use perspective LILO was the shit. Never had a problem with LILO that couldn't be solved by booting a live CD and rerunning LILO. Grub, I've had no end of troubles with.

Unfortunately, Grub is pretty much essential if you want to do anything modern with your filesystems. Use any encryption, LVM, or RAID and you need Grub.

maybe you should study grub (1)

dutchwhizzman (817898) | more than 2 years ago | (#36156584)

So you can boot a live CD and fix grub just like you did with lilo. It would save you a lot of time posting complaints about it on forums.

Re:maybe you should study grub (1)

Hatta (162192) | more than 2 years ago | (#36156708)

Sure, you can reboot a live CD and reinstall Grub, or run grub-update again. Most of the time that works. Once in a while it won't, and requires some serious brow furrowing to fix. LILO always worked. ALWAYS.

There's no amount of "study" on my part that could make Grub as reliable as LILO. There's also no amount of study that would make LILO as featureful as Grub.

Re:maybe you should study grub (0)

Anonymous Coward | more than 2 years ago | (#36156854)

If grub doesn't work, it's because you fucked it up. Stop being an idiot and messing up your bootloader. If your distro somehow messed up, it is a matter of running grub-update. If it takes anything else, you did something stupid.

Re:maybe you should study grub (2)

Hatta (162192) | more than 2 years ago | (#36156958)

I certainly can't claim to have never done anything stupid. But isn't it funny how I never did anything stupid when LILO was the popular boot loader?

Sure, i'll cop to being an idiot. In fact, that's my whole point. LILO was idiot proof, Grub is not.

Re:maybe you should study grub (2)

Dishevel (1105119) | more than 2 years ago | (#36158022)

There's no amount of "study" on my part that could make Grub as reliable as LILO. There's also no amount of study that would make LILO as featureful as Grub.

More features almost never equals better stability.

Re:why GRUB? (1)

Nimey (114278) | more than 2 years ago | (#36156632)

I've never had trouble with Grub. This is likely because I just let the package manager deal with it and new kernels, rather than building my own.

The only problem I've ever had with it was PEBKAC: I upgraded the kernel and purged the old one, but didn't let the Grub updater run. A quick boot with a live CD let me edit the conf file and all was good.

Re:why GRUB? (2)

Hatta (162192) | more than 2 years ago | (#36156886)

I actually stopped building my own kernels around the time that everyone switched over to grub. I wish I could remember what specifically caused my problem, but I do remember running grub-install over and over, grub swearing up and down that it was installed and read my config, then rebooting and getting nothing. I'm pretty sure this was before I did root on raid/luks/lvm too.

I don't even mind when things break all that much. It can be fun to track down the problem and fix it. Grub is just inscrutable, it gave me no information to help troubleshoot, and I couldn't get any help from the Grub IRC.

The only problem I've ever had with it was PEBKAC: I upgraded the kernel and purged the old one, but didn't let the Grub updater run. A quick boot with a live CD let me edit the conf file and all was good.

The funny thing is, you had to do the same thing with LILO. If you didn't rerun 'lilo' after editing its configuration, it wouldn't boot. The big selling point of Grub was that you didn't have to do this. Grub will figure everything out they said. That didn't quite work out.

Re:why GRUB? (0)

Anonymous Coward | more than 2 years ago | (#36157248)

One thing that's useful in Grub is that you can often work around conf problems from within Grub. Edit the existing entry kernel line and tab-complete to get the right filename and hit b to boot. Then remember to fix up the conf file after it boots.

Re:why GRUB? (1)

Tanktalus (794810) | more than 2 years ago | (#36157460)

Running Gentoo, I build my kernels. I created a "cp_kernel" script that would copy the kernel (after building) to /boot and rebuild my grub.conf, all in one fell swoop. That way, I could never get them out of sync. I also wrote a corresponding rm_kernel script that would remove the kernel from /boot, remove it from /usr/src and the modules from /lib/modules, and rebuild my grub.conf. Again, all one command. So I can't screw it up.

It'd be nice, though, if it weren't so convoluted. I've made it easy for myself, but that only helps me. If there were a "make install" target in the kernel that copied the correct file(s) to /boot, including some simple file describing everything that a boot loader would need to know about it (for the current machine), then grub or lilo or whatever would be able to read those files to see what kernel options were available. Package managers (i.e., distros) would have to modify those files in their post-install code to fit the current machine, of course. Unless there were saner defaults (e.g., the root filesystem labelled in a separate config file instead of with each kernel).

Basically, the boot-loader devs and the kernel devs and the distros come together to define a common standard for interoperability, much like OpenDesktop between Gnome, KDE, and likely others, to make installing and uninstalling kernels safer, regardless of bootloader (lilo or grub or other), distro, or method of kernel install (distro-managed .rpm or .deb, or manual compile/install from distro-managed sources, or manual compile/install from vanilla sources even on a distro-managed system). But now I'm just talkin' nonsense.

Re:why GRUB? (0)

Anonymous Coward | more than 2 years ago | (#36158676)

On Gentoo, I just "make install" my kernels. That target copies the new kernel to /boot/vmlinuz-2.6.xx-xx, links "/boot/vmlinuz.old" to the current kernel, and links "/boot/vmlinuz" to the new one. Don't need to update Grub or the config, unless the new kernel changed something substantially (like the move from /dev/sdx to /dev/hdx to refer to SATA drives).

Re:why GRUB? (0)

Anonymous Coward | more than 2 years ago | (#36158720)

Alternately, you can switch to a simpler OS. I went Debian -> OpenBSD about 7 years ago, and used RAID & encryption without grubby headaches. ;) To dual-boot with Windows, I just use the WinXP boot loader, but sometimes I don't even bother with all that (hardly ever use Windows).

Re:why GRUB? (1)

ArsonSmith (13997) | more than 2 years ago | (#36156520)

with LILO you had a conf file and a command you had to run

With GRUB you have a conf file

which is simpler?

Re:why GRUB? (0)

Anonymous Coward | more than 2 years ago | (#36156612)

Erh... GRUB is like Linux operating system when compared to LILO. Even that GRUB and LILO loads both the linux operating system to RAM and then executes it and pass control for it, LILO was better.

Simple and clean. One config file and lilo command what to run manually if something did not work.

With GRUB, you have one very complex config file and god knows how many different errors and possibilities what went wrong with last boot what you can not solve just by running grub-setup script or reinstalling GRUB.

I have fighted with GRUB problems more than with LILO problems ever needed.

Yes, today GRUB has much needed features but still it is too difficult and too easy to get broken.

Re:why GRUB? (2, Insightful)

Anonymous Coward | more than 2 years ago | (#36157476)

With GRUB you had a conf file

which is simpler?

Fixed that for you...
Now with grub2 you have three config files (at least in Ubuntu); a read-only /boot/grub/grub.cfg, an /etc/default/grub with some stuff in it and a couple of files in /etc/grub.d/
Once you change anything in one of them you have to run 'update-grub' and it'll generate the grub.cfg from the other files.

- Peder

Re:why GRUB? (0)

Anonymous Coward | more than 2 years ago | (#36158242)

and it'll generate the grub.cfg from the other files

So GRUB has a conf file. You're confusing GRUB with the distro that you're using.

Re:why GRUB? (1)

0100010001010011 (652467) | more than 2 years ago | (#36158382)

Grub STILL has only one config file: grub.cfg.

update-grub has 2 config file locations: /etc/default and /etc/grub.d. The reason grub.cfg looks so messy is it was auto generated. Auto generated code typically has extra fluff in it. Those config locations just tell the auto generation script what it should do. Look for Linuxes, Look for other OSes, Set the default grub options.

You are more than welcome to write your own grub.cfg file and make it as bare as possible. It's quite easy and it's what I did on my multi-disk boot USB stick. (I use the loop back command in grub all the time.)

1) Tell it where root is
2) Tell it what kernel to load
3) Tell it what initial ramfs to load.

Re:why GRUB? (1)

Ant P. (974313) | more than 2 years ago | (#36158544)

with LILO you had a conf file and a command you had to run

One "make install" in the kernel source directory which automatically runs the LILO install script in /etc/kernel/postinst.d/.

With GRUB you have a conf file

You forgot the part where you create the initrd to include your filesystem drivers.

Re:why GRUB? (1)

Anonymous Coward | more than 2 years ago | (#36156590)

slackware still use the good'ol LILO

Re:why GRUB? (0)

Anonymous Coward | more than 2 years ago | (#36156744)

GRUB 1 had a simple conf file too.
GRUB 2 is that over-engineered piece of shit we both learned to hate.

Q: Elegance, where are thou?
A: I'm with emergence and efficiency.
Q: And where would that be?
A: Right out the window, my dear!

Re:why GRUB? (1)

trust_jmh (651322) | more than 2 years ago | (#36156764)

My distro ditched LILO a while ago and I miss it terribly. A simple conf file. What more could you ask?

User friendliness.
i.e. One program you install and everything works; during which installing gives you simple muiti-choice setup options.
Considered using Debian?

Re:why GRUB? (4, Funny)

MrHanky (141717) | more than 2 years ago | (#36157256)

LI

Re:why GRUB? (0)

Anonymous Coward | more than 2 years ago | (#36157434)

heheh
"note to self: don't forget to re-run LILO after changing its config file"

Filesystem bandwagon (2)

billcopc (196330) | more than 2 years ago | (#36156276)

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 (4, Insightful)

GameboyRMH (1153867) | more than 2 years ago | (#36156620)

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).

Re:Filesystem bandwagon (2)

dutchwhizzman (817898) | more than 2 years ago | (#36156650)

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 (3, Interesting)

hedwards (940851) | more than 2 years ago | (#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:Filesystem bandwagon (1)

Rich0 (548339) | more than 2 years ago | (#36157848)

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:Filesystem bandwagon (1)

Simon80 (874052) | more than 2 years ago | (#36157864)

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 ext4 metadata is stored in a sparse Btrfs file, preventing the metadata's destruction until it that file is deleted, finalizing the conversion. I wish I could remember the thing I originally read, but this [lwn.net] article I just found is also really informative.

Re:Filesystem bandwagon (1)

hedwards (940851) | more than 2 years ago | (#36158164)

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 for Ext4 is because Ext3 blew chunks and they needed something to fill the gap until Btrfs was finished. But even their, if you're going to create something from scratch, why not create something that's compatible with what other folks are doing? Is it really that important to have a huge interoperability moat around the environment?

Re:Filesystem bandwagon (1)

Sancho (17056) | more than 2 years ago | (#36157924)

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.

Re:Filesystem bandwagon (1)

GameboyRMH (1153867) | more than 2 years ago | (#36156662)

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

Re:Filesystem bandwagon (0)

Anonymous Coward | more than 2 years ago | (#36157092)

BtrFS is basically an open ZFS, so that should tell you something.

WRONG!

Please educate yourself; knowledge is right here [lwn.net] .

Re:Filesystem bandwagon (1)

GameboyRMH (1153867) | more than 2 years ago | (#36157184)

Wrong? It was an extreme simplification but BtrFS' features are very similar to ZFS.

Re:Filesystem bandwagon (1)

Sancho (17056) | more than 2 years ago | (#36158086)

Not the AC.

One thing to realize is that the CDDL is an open license. It is incompatible with the GPL, which makes some people think that it's not open. This means that it can't be incorporated into the kernel (under most interpretations of the GPL and CDDL.)

A different issue is the possibility that Btrfs infringing on Sun's patents. If Btrfs starts gaining any traction, you can bet that Sun will sue over it, whether or not there's any actual merit to the case.

Re:Filesystem bandwagon (0)

Anonymous Coward | more than 2 years ago | (#36158316)

Saying that their "features are very similar" is not the same by a long shot as saying "BtrFS is basically an open ZFS". Btrfs and ZFS are fundamentally different. Read the article I linked.

Re:Filesystem bandwagon (0)

Anonymous Coward | more than 2 years ago | (#36156692)

Posting AC for obvious reasons, BtrFS aka "butter face" or "but her face" FS is basically just another FS with a poor reimplementation of LVM and MD-software RAID smashed into it. Its very anti-unix philosophy, instead of using three tools, each of which does one job to near-perfection, it goes all windoze-y and tries to do everything all in one whoppin' big binary and of course fails. I'm surprised they didn't add a bootloader and full 3-D with shaders framebuffer. Maybe next time.

The thing that always kills me about "alternative FS" that are 5% faster, is you only get a couple months ahead of a guy using good ole ext2 on a newer drive, or a couple hundred ahead of a better piece of (NAS?) hardware. And it only costs thousands of dollars of admin time and lost productivity and lost data when it inevitably crashes, so with a cost benefit analysis like that, I can't imagine why anyone even bothers to try.

Re:Filesystem bandwagon (1)

grumbel (592662) | more than 2 years ago | (#36157120)

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:Filesystem bandwagon (1)

Rich0 (548339) | more than 2 years ago | (#36157876)

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.

Re:Filesystem bandwagon (1)

KiloByte (825081) | more than 2 years ago | (#36157882)

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 work around bugs in ext3/4. This ends up nearly an order of magnitude slower on btrfs. If dpkg had support for btrfs transactions, it'd be that order of magnitude faster than ext4.

Re:Filesystem bandwagon (0)

Anonymous Coward | more than 2 years ago | (#36158444)

Meaning it is -- essentially -- still utterly useless compared to ZFS.
It doesn't even have automated scrubbing. WHAT'S THE POINT OF THE CHECKSUMMING THEN??
I don't trust it more than Windows ME's instability... squared.

Re:Filesystem bandwagon (0)

Anonymous Coward | more than 2 years ago | (#36158512)

1. Your backup determines how safe your data is, if you need safety for your data, at all.
2. Yes, that is affected by using BTRFS in quite a few scenarios. BTRFS has compression support (which can help performance, its a trade-off between some memory+cpu+latency and throughput). Other features also help.

2a. It is however worthy of note this is not some minor addition to another filesystem on Linux, like ext4. It is an entirely different filesytem, a complex piece of software, and so comparisons between it and ext4 will be complex, too - some usabe patterns will certainly perform worse on btrfs than ext4. If you actually do care about getting more performance out of the filesystem you're using, you'll best test the filesystems and maybe all their settings out, on your own.

As for why they would be used as /boot: I guess the practical reason for supporting them is probably most commonly for uses when there is no seperate boot partition. That is not an uncommon setup. But well, if people had some specific reason to have a /boot with another filesystem, why not - it is a big world, maybe someone with a need for security only wants to have things enabled in their kernel that he/she reviwed... or what not.

Boot separate from partitions (3, Informative)

hoggoth (414195) | more than 2 years ago | (#36156486)

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...

Re:Boot separate from partitions (1)

Tranzistors (1180307) | more than 2 years ago | (#36157654)

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

booting to zfs (0)

Anonymous Coward | more than 2 years ago | (#36156582)

Hmm, last time I checked if you want to use ZFS on Linux, you need to run it in userspace (FUSE) or as a add on kernel module. I wonder how that would tie in with this latest GRUB. It seems that those restrictions could make it hard to boot from. Regardless, I'm happy with ZFS on OpenIndiana, it's a great file server.

Re:booting to zfs (0)

Anonymous Coward | more than 2 years ago | (#36157026)

There is a Linux kernel module available for ZFS nowadays (zfsonlinux.org), and it works pretty well. Of course, most people using that are likely not booting from ZFS, but I hear that it's been possible, and this'll make it certainly so. Linux aside, OpenIndiana (for sure) and Solaris (I think) do use GRUB, and FreeBSD can use GRUB, and having a mainline GRUB that can boot ZFS is a good thing.

GRUB as an OS? (2)

gr8_phk (621180) | more than 2 years ago | (#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:GRUB as an OS? (1)

Anonymous Coward | more than 2 years ago | (#36157114)

in principle you want the boot loader to be small, not constantly incorporating operating system features

I don't think you understand GRUB. Its purpose has never been to be small or elegant, believe me... but that niche was already full of LILO anyway.

I still use LILO. It works with anything because it does not read or use filesystems. Simple, small, elegant - but requires a level of knowledge that most linux users no longer have.

Re:GRUB as an OS? (1)

KiloByte (825081) | more than 2 years ago | (#36157998)

LILO is mostly dead, though. It was completely dead for many years until Joachim Wiedor stepped up to maintain it at a last minute just as it was going to get the boot from Debian. It still isn't kicking much.

Re:GRUB as an OS? (1)

Skapare (16644) | more than 2 years ago | (#36158170)

But LILO isn't it, either, especially due to the way it manages indexing blocks, which is a major hassle. Had it not been for the DOS MBR partition table limitations, an early (and probably still used) bootloader might have placed kernel and initrd images directly in raw partitions. Now we have GPT with at least 128 partitions (it can do even more, but a certain OS won't support it) and there should be plenty of slots to slip in an OS or two, sequentially, without any need for a table of block indexes.

Re:GRUB as an OS? (1)

Rich0 (548339) | more than 2 years ago | (#36157918)

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 is done doing its job.

Re:GRUB as an OS? (1)

Skapare (16644) | more than 2 years ago | (#36158254)

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 partition. Since we have GPT, now, we have plenty of partition slots to put in alternate backup kernels in case the new one won't run.

Re:GRUB as an OS? (0)

Anonymous Coward | more than 2 years ago | (#36158464)

First to you know. Linux kernel is not just anykind kernel. It is a monolithic kernel what means Linux kernel is the whole operating system and not just a kernel like microkernels Mach and L4 are.

Linux is already on own partition and it is called /boot if you just create a own partition for it and do not keep just root partition. The /boot partition (or directory) includes the images of the Linux OS to be loader.
You can even create a start CD/DVD disk or floppy or even a network what includes the Linux images and configs what drives/partitions to mount so Linux can find INIT (or replacement) and it can then start running other non-OS (what INIT is as well) programs like bash and so on so the whole system is started as ordered (scripts).

But, computer BIOS or EFI are stupid ones. The do not know what blocks to read from the computer media or what files to read if the data is changing (upgraded). Thats why we have bootloaders what takes place of first 512 blocks and there is the information where the bootloader exist and then run it, what then reads own configs what OS's are installed and loads it as ordered and transfers rights to it and then it loads first non-OS software parts like INIT, Bash and so on.

That, how many partitions we have has no meaning. We can still use Unix systems even with one partition.

LILO idea is simple. When the Linux OS image is changed (Linux kernel is the operating system) then LILO needs to be updated and the LILO command checks the block information where the Linux OS image is stored and writes that information to MBR to inform what to read. Problems comes when Linux OS image is changed and LILO in MBR is not updated, as the MBR includes wrong blocks and Linux OS is not loaded correctly.

So fix to that is bootloaders like GRUB.

MBR has GRUB and GRUB can be loaded fully. GRUB does not care about blocks, it understands filesystems and file hierarcharies and different directories where OS images are stored and by what name. It can load the image from disk and execute it. More flexible and offers more possibilities than LILO, but is much easier to brake down in multiple different ways.

Re:GRUB as an OS? (0)

Anonymous Coward | more than 2 years ago | (#36158276)

Bootloaders idea is to find the OS and load it. Linux kernel is the operating system, bootloader loads it and executes it and that is simply its job. After Linux OS is loader, it loads first non-OS process what is INIT (or similar).
Bootloader can load just the microkernel what then knows what part of the disk to read to load filesystem modules and execute their process and then load other OS modules after running INIT or similar non-OS process.

Re:GRUB as an OS? (3, Funny)

Opyros (1153335) | more than 2 years ago | (#36158152)

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

When it has integrated EMACS?

Re:GRUB as an OS? (2)

Kamiza Ikioi (893310) | more than 2 years ago | (#36158448)

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

Re:GRUB as an OS? (1)

0100010001010011 (652467) | more than 2 years ago | (#36158456)

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?

Leave it to Linux (1)

OverlordQ (264228) | more than 2 years ago | (#36157166)

GRUB 2 at 1.99 *brain explodes*

Re:Leave it to Linux (1)

indre1 (1422435) | more than 2 years ago | (#36157674)

It's like the Y2K bug all over again when Grub 2 reaches 2.00. Hope they get it sorted out before new Grub version has to be released.

Re:Leave it to Linux (0)

Anonymous Coward | more than 2 years ago | (#36157682)

and Windows 7 version 6.1.7601 is linux....

limited Gparted support for BtrFS (2)

bitsent (1295282) | more than 2 years ago | (#36157182)

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

I Fucking Hate GRUB (0)

Anonymous Coward | more than 2 years ago | (#36157188)

Blah blah blah, it's better than LILO, or whatever.

GRUB Fucking sucks. Burn the software and hang the developers. I hate it.

It's neat that we can boot off of them... (3, Funny)

Erpo (237853) | more than 2 years ago | (#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:It's neat that we can boot off of them... (2, Interesting)

Anonymous Coward | more than 2 years ago | (#36157328)

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 userspace tool).

1.99?! (1)

thePowerOfGrayskull (905905) | more than 2 years ago | (#36157886)

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?!

Re:1.99?! (1)

Skapare (16644) | more than 2 years ago | (#36158102)

Somewhere around 1.9999999999999999999999999999 I suppose

Re:1.99?! (0)

Anonymous Coward | more than 2 years ago | (#36158560)

Er.... 1.100? Version numbers are NOT decimals, you know...

Load More Comments
Slashdot Login

Need an Account?

Forgot your password?

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>