GRUB 1.99 Released With Support For ZFS and BtrFS

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

Comments

Does this matter?

[Anonymous Coward]

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

Re:Does this matter?

[SanityInAnarchy]

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?

[Anonymous Coward]

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

Re:Does this matter?

[Anonymous Coward]

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?

[kvvbassboy]

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?

[DarkOx]

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?

[mikael_j]

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?

[Kamiza Ikioi]

"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 & http://lkml.org/lkml/2008/8/1/217

Re:Does this matter?

[MrHanky]

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

Re:Does this matter?

[GooberToo]

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?

[snowgirl]

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?

[Anonymous Coward]

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?

[petermgreen]

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?

[Electricity Likes Me]

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

Re:Does this matter?

[zsitvaij]

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

Re:Does this matter?

[Anonymous Coward]

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

[SETIGuy]

Way back when, when the option was xfs or ext3, not getting forced fsck after a crash was a big plus for xfs. I don't think I've ever had xfs_repair do anything.

I have a NAS box with 4x750GB RAID5 formatted ext3. The processor and I/O is so slow that it has never finished an fsck even after I've waited for two weeks since it started. That was intolerable so I hacked into it and after building xfs.ko, found that support for linux xfs on big endian processors is non-existent. So what I do now is pull the drives, put them in an x86 linux system and do the fsck there if the thing crashes. Never buy a NAS box that uses ext3.

Re:Does this matter?

[PhrstBrn]

Funny you say that. I rebooted a server today (clean/soft reboot, not hard reboot), and one of the XFS filesystems never came back up. I had to run xfs_repair on a tiny 20TB volume.

That utility produces lots of dots, and no useful output. No idea if it's even fixed, I clocked out before it finished.

Re:Does this matter?

[Per Wigren]

Hardware has problems. Bitflips on HDDs cause files to get corrupted randomly in Windows as well as MacOS X and Linux if you use EXT4, XFS, etc as your filesystem. The solution is filesystems like BtrFS and ZFS because they can (and WILL on all HDDs, given enough time) detect and repair corruptions. RAID can also solve that problem to some degree but only if it verifies the data upon reading, something neither RAID controllers nor software RAID usually do.

Re:Does this matter?

[smi.james.th]

Perhaps it might be more accurate to say that the purpose of btrfs is to implement many zfs features in Linux which couldn't be previously... Correct me if I'm wrong, but it's for licencing reasons that Linux distros don't ship with zfs?

Re:Does this matter?

[SanityInAnarchy]

The big things that XFS always had just built in were:

Extended attributes, including ACLs. Even ext3 has these now, though you at least need to set the mount options properly (and maybe even tune the fs itself), but XFS just had them built in.

Lazy allocation / Allocate on flush. Here, XFS wins with files of any size. Essentially, the idea is that you let stuff buffer until you have to write, either from memory pressure or from a sync() call (or fsync, really), then you write a bunch of stuff all at once. You delay allocating them until that final flush -- that is, you allocate them in terms of what df shows, but you don't decide where they go until then. This helps a lot with fragmentation, and probably even with overall write performance. Where you run into trouble is when you have something really aggressive, like Reiser4, where it'll happily buffer hundreds of megabytes, gigabytes even, over several hours, until something forces a write -- for one, unless you handle fsync specially, it's going to really, really suck.

My favorite hack about lazy allocation, which I've never been able to confirm whether or not this is actually done, is the idea that if you were to create a tempfile, then delete it before anything's flushed, you'd never touch the disk. There are all kinds of tweaks where we put things on a tmpfs -- I know Ubuntu does it for /dev, /var/run, and /var/lock, for instance, and I know people sometimes put stuff in /tmp -- but none of these things would technically be required in that case. Make it more aggressive, and you have the possibility of unpacking a tarball, compiling, installing, then nuking the tarball and compilation directory, without anything except the actual binaries ever touching the disk.

Journaling. Back in the day, there were really only two filesystems in the game for this: XFS and ReiserFS. (I might be forgetting about JFS, but that's because I don't really know when that became viable.) ReiserFS is still one of the best with small files, which is probably why you're thinking you'd use XFS for larger filesystems.

Snapshot support. You could (in a very temporary way) force XFS into a momentarily-consistent on-disk state, with all writes blocking, meaning you get a more consistent LVM snapshot.

Online growing -- I think ReiserFS did this, too, and I'm fairly sure ext2/3/4 do now. Not really useful unless you're running on top of something like LVM, but if you are, you could (in theory) shove a new disk into a hotplug system, add it to LVM as a new physical volume, grow your XFS device, and then grow the filesystem onto it. This would also be useful in an environment like Amazon EC2, if Amazon were to allow EBS (Elastic Block Storage) devices to be expanded online -- but even if they don't, you could probably do similar LVM or RAID hacks to accomplish the same thing.

Good at big IO and big files. Media, databases, anything where you've got large files that you need to have reliably fast IO to -- you can have guaranteed throughput, direct IO, etc. Uses extents for allocation, so the more contiguous your files are (and thus, the less fragmented), the less space and overhead you waste on allocation.

64-bit, with massive max sizes. By the time my filesystem gets to 8 terabytes, I'm not going to want to switch filesystems to make jump to 16.

Online defragmentation. Yes, yes, we know, Linux filesystems don't tend to get as fragmented. It can still be useful.

Rock-solid with most (if not all) of the above on IRIX, and I've heard it described as "They ported Linux to XFS, not the other way around."

I'll admit, I peeked at Wikipedia and was reminded of a few more things, including some that I never really cared about, but XFS is a pretty big, solid filesystem. Less than half of what I just listed is true for JFS, though a lot more have since become true for ext3, and I now see very little advantage to XFS over ext4. However, it has historically been bad at lots of metadata updates, which is what you see when working with lots of small files.

Re:Does this matter?

[SanityInAnarchy]

I'm not seeing FreeBSD or Solaris getting btrfs in the first place. Barring some serious efforts on the part of the btrfs team, this just isn't going to happen -- btrfs, being in Linux, would be GPL'd.

But it is a replacement in that I would rather be using Linux than either FreeBSD or Solaris, so if btrfs can do what ZFS does, maybe even improve on it a little, I'm going to be very, very happy.

It is, however, the easiest way to describe what the point of having both btrfs and ext4 is. Ext4 is actually a simple, natural progression from ext3, and you can upgrade from ext3 to ext4, in-place, with no surprises and expect everything to work exactly as it always has, only better. Btrfs is at least modeled on ZFS (and Reiser4) and isn't stable yet -- and even when it is, the biggest draw is going to be people who really want ZFS, but also want Linux. For anyone currently using ext4, I doubt it's going to be that compelling of an upgrade, though again, it's likely to be simple, natural, in-place, and with few surprises.

Re:Does this matter?

[SanityInAnarchy]

Technically, the e2fsck isn't even needed. I'm fairly sure the tune2fs can be done on a mounted filesystem, which means you can run that, then edit fstab so the fs mounts as ext4, then reboot -- much more convenient to do all filesystems (including root) like that. Then, each write is going to take advantage of the new tweaks, so you convert slowly, instead of all at once.

I prefer your way, but then, I don't have many machines that I can't take down for a few hours if I need to.

Re:Does this matter?

[SanityInAnarchy]

Yeah, I was actually a bit annoyed about that. I'm not convinced he killed his wife, but fine, suppose he did. The code didn't murder anyone, and it's open source. Why abandon it?

But yeah, the project did die, and looking at btrfs, I see most of the ideas from Reiser4 and ZFS. There are still a few big things missing, though. Biggest idea that I miss from Reiser4 is the prospect of real transactions -- it looks like there's something similar happening, but I'd still really like to have a situation where, for instance, a software update, config change, etc, could be done atomically.

Re:Does this matter?

[GooberToo]

My understanding from reading the LKML in the past is that you "conversion" is still insufficient and falls short of an actual reformatting.

Re:Does this matter?

[m50d]

Shame they didn't just finish off reiser4, which I believe was almost done.

Re:Does this matter?

[corychristison]

I also use Gentoo. /boot is ext2
/ is JFS /home is JFS /Media is XFS /tmp is tmpfs /var/tmp is symlinked back to /tmp /tmp is limited to 4GB so it doesn't use up all of my RAM (8GB). Haven't had any oases with portage/emerge saturating it. Not even a rebuild of openoffice.
I've only

Re:Does this matter?

[SETIGuy]

Ouch. Hopefully it's still faster than an ext3 fsck.

Re:Does this matter?

[PhrstBrn]

I watched it for about 5 hours before I left. It came back with nothing when I got there in the morning, just gone. I did some research and the symptoms were that of an older GPT+XFS bug (exact error, different version of GPT).

Partition was gone, recreating them didn't help, the filesystem was still hosed. Fortunately it was used as a scratch drive, but the "architect" who designed the backups for that system decided it was best to store the data archive on a series of USB disks on a shelf.... If I only could convince somebody to go buy a tape deck for that thing.

Re:Does this matter?

[cynyr]

A bad shutdown due to power loss, hardware starting to fail, a misbehaving process that writes directly to the part of the disk that the registry is in. Really the issue is that on windows the registry is either good, or bad. There is no "mostly" good.

Re:Does this matter?

[snowgirl]

Yeah, I was actually a bit annoyed about that. I'm not convinced he killed his wife, but fine, suppose he did.

Last I heard, he had led them to the body. That's usually pretty good evidence of guilty, but I held out doubt until then.

The code didn't murder anyone, and it's open source. Why abandon it?

Politics and people rarely ever act rationally. :(

Awesome

[hedwards]

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.

whooptie-dolittle

[Anonymous Coward]

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.

[thomasdz]

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.

[rubycodez]

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?

[droidsURlooking4]

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

Re:why GRUB?

[ae1294]

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?

[Anonymous Coward]

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

Re:why GRUB?

[Anonymous Coward]

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

Re:why GRUB?

[Hatta]

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.

Re:why GRUB?

[rubycodez]

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

Re:why GRUB?

[Microlith]

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?

[rubycodez]

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

Re:why GRUB?

[ArsonSmith]

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?

[GameboyRMH]

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?

[Anonymous Coward]

slackware still use the good'ol LILO

Re:why GRUB?

[Anonymous Coward]

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?

[Nimey]

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?

[Anonymous Coward]

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?

[trust_jmh]

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?

[Hatta]

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?

[Anonymous Coward]

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?

[MrHanky]

LI

Re:why GRUB?

[Anonymous Coward]

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

Re:why GRUB?

[Tanktalus]

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?

[Anonymous Coward]

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?

[rubycodez]

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?

[Anonymous Coward]

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?

[0100010001010011]

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?

[Ant P.]

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?

[Anonymous Coward]

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?

[Anonymous Coward]

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?

[Tanktalus]

I guess I'm too paranoid. I like to have at least the last known-working kernel still around to boot from if the new kernel doesn't work. I've had more than one occasion where I screwed up some kernel parameter.

Re:why GRUB?

[Nimey]

See, when I was building my own kernels in Debian and using grub (and no initrd), I wasn't vulnerable to that particular PEBKAC, because I always made a symlink from /vmlinuz to the updated kernel and grub just happily expected to see the kernel there. Lots easier than having to remember to run lilo.

Ubuntu doesn't use the symlink, so it has to keep its list of kernels updated.

Re:why GRUB?

[CharlyFoxtrot]

find-and-replacing in text files is what Unix has been all about for decades, trivial and easy.

You might want to take a look at what AIX and Solaris have been up to in the last decade. From the ODM to Solaris' SMF and its XML tangle, the basic text file has been steadily losing ground.

Re:why GRUB?

[Alrua]

It's been a while since I compiled a kernel in Gentoo, but as I recall "make install" will get you the kernel image copied to /boot and symliked to /boot/vmlinuz or somesuch. Even backing up the old symlink to /boot/vmlinuz.old.

So all you'd have to do is point the Grub config to /boot/vmlinuz, and you wouldn't have to touch it after a recompile.

Of course there were issues with new "make install"'s overwriting old ones, etc, but as I recall generally it worked quite reliably...

Re:why GRUB?

[Anonymous Coward]

You might want to take a look at what AIX and Solaris have been up to in the last decade. From the ODM to Solaris' SMF and its XML tangle, the basic text file has been steadily losing ground.

And neither AIX or Solaris are gaining much ground in the market either.

Re:why GRUB?

[Trogre]

...taking us back to the days of LILO, and the reason a lot of people migrated to GRUB 0.x in the first place.

Re:why GRUB?

[Anonymuous Coward]

You are more than welcome to write your own grub.cfg file and make it as bare as possible.

And it will be replaced the next time you update the kernel with apt-get upgrade.

And no, the grub.d idiocy is not a distribution thing: it's the recommended way to do things from upstream. Read the grub manual. grub.cfg was deliberately made more complex and obtuse in order to discourage people from messing with it by hand.

What pissed me more that that was that update-grub was running grub-probe some 20 times, each instance taking ~30 seconds and thrashing the disks violently.

Fortunately, on Debian it's pretty easy to stick with boot-legacy, which I did finally.

Re:why GRUB?

[davester666]

And the blow!

Re:why GRUB?

[The Wild Norseman]

Unless it's from the hookers!

Re:why GRUB?

[MareLooke]

Which is exactly what make install does, links your old kernel to vmlinuz.old and links the new one to vmlinuz. So you have an "old" entry with a known working kernel, unless you do multiple make installs without rebooting of course, but that would be a bit odd...

Filesystem bandwagon

[billcopc]

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

[GameboyRMH]

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

[dutchwhizzman]

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

[hedwards]

I'd take a look here: Btrfs 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

[GameboyRMH]

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

Re:Filesystem bandwagon

[Anonymous Coward]

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

[Anonymous Coward]

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

WRONG!

Please educate yourself; knowledge is right here.

Re:Filesystem bandwagon

[grumbel]

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

[GameboyRMH]

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

Re:Filesystem bandwagon

[Rich0]

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

[Simon80]

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 article I just found is also really informative.

Re:Filesystem bandwagon

[Rich0]

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

[KiloByte]

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

[Sancho]

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

[Sancho]

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

[hedwards]

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

[Anonymous Coward]

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

[Anonymous Coward]

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

[Anonymous Coward]

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.

Re:Filesystem bandwagon

[Simon80]

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 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:Filesystem bandwagon

[canistel]

I find that (sun taking people / business to court) very unlikely, considering that sun was purchased by oracle and oracle is involved in btrfs...

Re:Filesystem bandwagon

[Anonymous Coward]

So... apart from a massive, absolute show-stopper, you don't see any problems with using ZFS on linux?

That's nice :)

Re:Filesystem bandwagon

[ichthus]

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 disagree with you.

Re:Filesystem bandwagon

[ChunderDownunder]

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

Re:Filesystem bandwagon

[sqldr]

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

Re:Filesystem bandwagon

[d3vi1]

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 implement it, it is not suitable for a direct import. It is most probably suitable for documenting the filesystem layout for a brand new implementation. The reason is quite simple: the boot loader implementation has only a single goal: read any requested file on a filesystem (ignoring access rights, write support, checksumming, snapshots, properties, or other fancy stuff).

Re:Filesystem bandwagon

[d3vi1]

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?
How about inheritable ACLs (posix or NFSv4)?
How about data deduplication?
How about something similar to L2ARC? It gives a ZFS with two SSDs and 10 cheap 1TB Samsung 4200RPM drives (a total of about $2 with all the hardware), the same capacity and performance as 20+ 15k RPM fibre-channel drives ($20k just the drives).
How about incremental dumps? Btrfs is a COW filesystem that allows snapshots after all. Solaris had that, even in UFS for a long time.

You know how you should think about ZFS? As a $30.000 NetApp FAS2020 filler for free in any $1.000 computer.

I like and use Linux, but comparing ZFS with anything on the Linux side is like comparing an excavator with a shovel. Right now, anything on the Linux side is at best at NTFS feature level with arguably better performance, though investing in faster hardware might alleviate that.

Without DTrace and ZFS Solaris wouldn't really be irreplaceable today, but those two components make it the perfect OS for a little while longer.

Re:Filesystem bandwagon

[WuphonsReach]

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 time on data partitions.

Re:Filesystem bandwagon

[jedidiah]

> 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:Filesystem bandwagon

[jedidiah]

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:Filesystem bandwagon

[Anonymous Coward]

It will never be part of the kernel - so this isn't ZFS vs btrfs, but rather btrfs vs nothing (or ext4/etc).

Only a problem on Linux, and a self-imposed problem at that. Given the situation though, it is indeed clean-room re-implementation or nothing. It is a goal of the author of the GPL to make this very thing a legal requirement: if software isn't licensed under terms he found (and codified as) acceptable, and is worth having, said software should be independently re-authored and released under terms he does find acceptable. In other words, this is the GPL in action, as intended.

The licensing is by far the biggest problem with ZFS.

That's a matter of perspective; the licensors do not find the licensing to be a problem, which is what made it an allowable choice for them. People whose software's license is not incompatible with that of ZFS do not find it problematic. People whose software's license was explicitly conceived with the express purpose of superseding other licenses' limitations and grants of right with its own obviously "have a problem" with it; that is the designed legal goal of the GPL.

Re:Filesystem bandwagon

[cthulhu11]

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:Filesystem bandwagon

[Just Some Guy]

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

Multiple developers with non-overlapping needs. Next question?

Re:Filesystem bandwagon

[Rich0]

It will never be part of the kernel - so this isn't ZFS vs btrfs, but rather btrfs vs nothing (or ext4/etc).

Only a problem on Linux, and a self-imposed problem at that. Given the situation though, it is indeed clean-room re-implementation or nothing. It is a goal of the author of the GPL to make this very thing a legal requirement: if software isn't licensed under terms he found (and codified as) acceptable, and is worth having, said software should be independently re-authored and released under terms he does find acceptable. In other words, this is the GPL in action, as intended.

Agreed on all points, but I don't really see this as a big problem for linux. In five years we'll probably have btrfs have the level of adoption of ext3, and zfs will probably have less adoption than ufs/2/etc does now. In the end, licensing does make a difference.

The licensing is by far the biggest problem with ZFS.

That's a matter of perspective; the licensors do not find the licensing to be a problem, which is what made it an allowable choice for them. People whose software's license is not incompatible with that of ZFS do not find it problematic. People whose software's license was explicitly conceived with the express purpose of superseding other licenses' limitations and grants of right with its own obviously "have a problem" with it; that is the designed legal goal of the GPL.

Well, I'm not sure what publishing ZFS under the CDDL has gotten Sun (and now Oracle). ZFS was intended to breathe new life into Solaris, but it didn't work out all that well in the end - probably because it was too much under the control of a single company for anybody to want to trust it.

You mentioned clean-room re-implementation. I'm glad that the linux camp didn't go that route with ZFS (creating a binary compatible filesystem), but rather they created a new one aiming for a similar feature set. If ZFS were re-implemented it probably would have been forever in catchup mode, with the non-GPL implementation being considered the reference one. New features might not have been well-suited to the GPL implementation requiring refactoring/etc over time. By starting from scratch btrfs will start out behind, but it has the potential to move ahead.

You seem to be of the mindset that the GPL forces projects to shoot themselves in the foot by re-implementing things that others have already done. I'll agree that this is a downside to the GPL, but from what I've observed the costs are outweighed by the benefits. I think a lot more people are likely to contribute to a GPL project than a non-GPL one. Corporate contributors in particular have more incentive to contribute to a GPL project rather than a non-copyleft one as it is much harder for a competitor to get an advantage by leveraging the code. Sun was a bit of an exception - they wanted the benefits of open source but in this case they were already suffering because they were in direct competition with linux and generally losing, and they didn't want to make it possible for linux to leverage their code easily.

Re:Filesystem bandwagon

[maraist]

Because LVM is not the panacea you seem to make it out to be, and mdadm that don't span the entire disk partitions are a pain (I've been using advanced features of both for 5 years, namely non-symmetric disks FORCED together with lots of LTC). zfs/btrfs have seamless volume-size/volume-distribution/volume-affinity management. Technically I can replicate many/most of it's features with LVM/mdadm/extX, but most operations say 'should backup' - not trivial when 55% of disks are already utilized.

I haven't done extensive testing of copy-on-write of btrfs v.s. LVM, but LVM cow is large-block oriented and thus painful for micro-writes of an underlying VM - I'm resorting to qemu's qcow2 on ext4 so I can get large-blocks with small COW, but it's still slow as a dog v.s. raw sparse-allocation. When I have time I'm going to play with btrfs's buffering/queuing of COW structures. I doubt it's any faster, but at least I don't have to suffer over-allocation (meaning it's free to allocate a partition in btrfs for a sparse VM, unlike w/ LVM).

Note, the ext4 gives me something that approaches raw LVM partitions for mysql INNODB data-blocks or VM images. (e.g. contiguous spans with little/no metadata random disk-accesses for multi-terabyte large files).

So I challenge the notion that ext2, netapp or bust. I've used just about all these configs.. iSCSI, aoe, dbrd, 3com, netapp, extX, XFS. It's just frustrating that the limitations of each of these toolchains don't seem to be mitigated by taking the best ideas from each approach. So right now, I'm cheering for btrfs, because it SEEMs like it could take the advantage of many capabilities (zfs just doesn't seem to have the performance, even though I love the RAID-Z concept - closer to netapp's WAFL in terms of RAID w/o consequences). The problem is that it's pointless to have a resizable partition if the least defined partition-size (root partition) NEEDS to be extX instead of btrfs.. So this lets my VM's boot with a more symmetric config.

Re:Filesystem bandwagon

[maraist]

Well, I doubt you can say 'no' overhead. COW fragments modified chains at 4K grains (of otherwise fully contiguous chunks with a single piece of meta-data (the starting disk-block+length). So if you have a large file that's random-access modified (like a DB), then it's read-performance will degrade overtime due to random seeks.. Though I bet it's better than qcow2 fragmentation since all data-block-references for a given file are contiguous in the "inode" record. Thankfully btrfs has defrag support so this can be mitigated, but for a 24/7 DB server that's not likely to be practical. Granted this is just one case, and I totally support the 'yum upgrade' then reboot/revert concept. :) Here's crossing my fingers.

Re:Filesystem bandwagon

[maraist]

? Do you mean the RAID-5 write-hole? R5 wasn't available as an option as of Fedora core 14. :( But I'm certainly waiting for it - means I can finally get away from R10 costs / drive-count limitations.

Re:Filesystem bandwagon

[maraist]

You probably don't like btrfs for boot - as this is probably too bleeding edge, but once solid, the advantage is high-degree of replication-factor for a small partition.
Say you put 100Meg.. You can have it replicated 4 ways across 2 disks - basically similar to using mdadm with a R1 for the first 100Meg of each disk.. But without having to have a complex setup that's isolated from the rest of the system.

Boot separate from partitions

[hoggoth]

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

[Tranzistors]

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

booting to zfs

[Anonymous Coward]

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

[Anonymous Coward]

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.

maybe you should study grub

[dutchwhizzman]

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

[Hatta]

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

[Anonymous Coward]

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

[Hatta]

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

[Dishevel]

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:maybe you should study grub

[cloudmaster]

Yeah it always workrkrkrkrkrkrkrkrkrkrkrkrkrkrkrkrkrk

I never had a probobobobobobobobobobobobobobobobob

GRUB as an OS?

[gr8_phk]

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?

[Anonymous Coward]

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?

[Rich0]

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?

[KiloByte]

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?

[Opyros]

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

When it has integrated EMACS?

Re:GRUB as an OS?

[Skapare]

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?

[Skapare]

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.

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?

[Anonymous Coward]

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?

[Kamiza Ikioi]

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

Re:GRUB as an OS?

[0100010001010011]

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?

Re:GRUB as an OS?

[Anonymous Coward]

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?

[Rich0]

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.

What if there isn't a disk on the machine? I agree that the only thing the bootloader needs to do is load the kernel, but that doesn't mean that it doesn't need to understand anything about advanced storage systems. There is stuff like PXE, but that has some limitations, and in the end you're just adding extra steps to the process.

If your BIOS could have a "URL of kernel" parameter, how would that be a bad thing?

Re:GRUB as an OS?

[Rich0]

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.

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

Re:GRUB as an OS?

[gmhowell]

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.

It's pining for the fjords.

Re:GRUB as an OS?

[Lord_Naikon]

Simple enough, each OS has its own boot loader installed on its root partition. The boot loader only needs to know how to interpret the filesystem for that particular OS and load its kernel. A simple boot manager is installed in the MBR that just knows how to "chainload" (i.e. boot a boot loader, regardless of filesystem).

Re:GRUB as an OS?

[0100010001010011]

Which is exactly what this does.
ZFS is FreeBSD/Solaris/OpenIndiana
BTRFS is where Linux is moving
EXT4 is where Linux is.

You just described exactly what GRUB does now.

Re:GRUB as an OS?

[Lord_Naikon]

Except that FreeBSD/Solaris/Windows all have there own loader and only linux uses the one from GRUB

Re:GRUB as an OS?

[Anonymous Coward]

Totally agree. I never understood why a bootloader has to "understand" file systems.

I do understand why giving it a pointer to the start of the kernel has its own problems (as done with lilo, for example). Once the file moves, you're SOL. But we learnt to live with that. Just call lilo each time you do strange things to your kernel images.

Maybe having it understand *one* filesystem (as syslinux does) and having the requirement that the boot partition be in this one filesystem is the way to go, after all.

But this monstergrub -- it's getting less and less attractive the more bloated it gets.

It seems to be a tendency in software. That's sad.

Re:GRUB as an OS?

[Anonymous Coward]

I thought EMACS had integrated GRUB by now?

Re:GRUB as an OS?

[0100010001010011]

Solaris, uses Grub.

Comment removed

[account_deleted]

Comment removed based on user account deletion

Comment removed

[account_deleted]

Comment removed based on user account deletion

Leave it to Linux

[OverlordQ]

GRUB 2 at 1.99 *brain explodes*

Re:Leave it to Linux

[indre1]

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

[Anonymous Coward]

and Windows 7 version 6.1.7601 is linux....

limited Gparted support for BtrFS

[bitsent]

I would probably switch from Ext4 to BtrFS if it had full Gparted support.

I Fucking Hate GRUB

[Anonymous Coward]

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

[Erpo]

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

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

1.99?!

[thePowerOfGrayskull]

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

[Skapare]

Somewhere around 1.9999999999999999999999999999 I suppose

Re:1.99?!

[Anonymous Coward]

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

Re:1.99?!

[thePowerOfGrayskull]

That depends entirely on which arbitrary numbering scheme this particular project is following.

Re:1.99?!

[Christian Smith]

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

99 + 1 = 100

Re:1.99?!

[thePowerOfGrayskull]

Well - that depends on the project. Each one has its own arbitrary naming standards. I mean, we are talking about "Version 1.99 of Grub 2"...

DO NOT USE BTRFS FOR YOUR ROOT PARTITION!

[Anonymous Coward]

BtrFS is definitely coming along nicely, and I'm not offering this as trollbait. But there are NO RECOVERY TOOLS THAT UNDERSTAND BTRFS. It's not worth having it as your root partition until you have the ability to do data recovery should anything go wrong. I spent the whole weekend rebuilding a partition table and had to find the magic salt of the partitions with a sector editor because no partition recovery tools can recognize btrfs partitions so that I could finish my exodus back to EXT4. (long story short I was resizing the btrfs partition with fdisk and miswrote the starting sector). Btrfs has great read performance, and I'll miss the LZO compression of small files and the space I was saving. But write/fsync performance SUCKED especially when I was running synaptic. I wouldn't discourage anyone from using it, just don't rely on it as your root partition. I should also add that while rsync'ing the files from my btrfs to my ext4 partition, I had to start over several times because of kernel panics. It's just not stable yet. Move along.

Any improvment in diagnostics?

[saccade.com]

My chief complaint 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?

Re:Any improvment in diagnostics?

[Anonymous Coward]

Kinda. There are real error messages, but you may not end up getting the error message text when an error occurs. It's obvious that the developer (and there is really only one guy who does 90% of the development) cares more about features than documentation or proper error messaging.

My thoughts after several months with Btrfs for /

[pxc]

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 functional OS without having to reach for a LiveCD. That said, the Btrfs filesystem has handled several hard shutdowns without issue (there's some problem with my Nvidia graphics card that's been causing intermittent/unpredictable hard freezes, impervious even to the Magic Sysrq key).

The cool thing about using Btrfs for the root partition on an ordinary system (this is why I'm trying it) is for fast, transparent filesystem compression. I have an OLPC XO-1, and a bootable FSF membership card, neither of which has much free space. The traditional solution to such space issues is to have a SquashFS (read-only) root partition to save space, and use a persistence file to store changes. But if the changes become too great, the persistence file will reach the size of the partition that holds it, and you have to recreate the SquashFS image to start using the system again. While the compression factor isn't quite as good for Btrfs compression (it can do gzip and lzo), it's still very handy when trying to get a full system into 2GB, and it lets you have read-write access with good performance, too.

Re:My thoughts after several months with Btrfs for

[mark_osmd]

I still wouldn't recommend using Btrfs for / unless you have a separate /home partition, though: there is not yet any fsck.btrfs!

Wrong, I think it was recently added, I can see it right now in my copy of btrfs-progs on Fedora 14: rpm -q --list btrfs-progs | grep fsck /sbin/btrfsck /usr/share/man/man8/btrfsck.8.gz

booting from btrfs

[chithanh]

For Linux users this means that it's now possible to move to BtrFS entirely and not use it only for non-bootable volumes.

Booting Linux from btrfs has been possible since the release of syslinux 4.0 in mid-2010.

Re:booting from btrfs

[Xtifr]

I would have thought that it would have been possible using LILO for about as long as btrfs has been available, since LILO doesn't read the filesystem and needs a list of physical disk sectors. (Hence the PITA flaw of needing to rerun the installer app, lilo(8), every time you updated your kernel.)

Re:booting from btrfs

[chithanh]

I agree that it should work in theory. However, Google turned up only posts that said it does not work. Another filesystem, reiser4, is only supported since LILO 21.6, so LILO appears not entirely filesystem-agnostic.

Re:booting from btrfs

[Xtifr]

Interesting. My guess is that it must have to do with the difficulty of the mapping from fs to physical disk sectors by the installer app rather than any limitation of the LILO boot loader itself, but I admit to less-than-complete expertise in this area.

Re:booting from btrfs

[Anonymuous Coward]

lilo relies on the FIBMAP ioctl in order to get the sectors occupied on the disk by a file.

It's the file system code in the kernel that should implement that ioctl. Other than lilo and a stupid tool I've put together to force-blank the contents of a file, I don't know about any other user of that ioctl.

btrfs only supported for grub-probe

[joel48]

From the actual announcement, it appears that btrfs is NOT supported for direct booting, but simply to be recognized by grub-probe, and a separate /boot is still required to have btrfs as the root fs.

"Add `grub-probe' support for the btrfs filesystem, permitting / to reside on btrfs as long as /boot is on a filesystem natively supported by GRUB."

Re:btrfs only supported for grub-probe

[cloudmaster]

But the lack of grub-probe is the only reason this system:

sauer@hotrod:~$ awk '$1!~"#"&&$2~"/(boot)?$"' /etc/fstab
UUID=e332a6e4-9e5f-420c-a86e-f376d70e0fdb / btrfs noatime,nodiratime,compress,ssd 0 1
UUID=0c39bf26-ffb4-4eed-ac2c-2114b8681a12 /boot xfs noatime,nodiratime,sync 0 2

is still using old grub instead of grub2. I just don't feel like manually editing the grub2 config, so I'll be glad when they finally get this version of grub2 into Ubuntu. :) I'm using btrfs not for all the cool features, but because it was the fastest on this system with a SSD. I did several bonnie++ / iozone / hdparm (ok, that doesn't count) benchmarks, and btrfs is by a pretty decent margin the best performing with my workload on my system with my solid state drive.

GRUB WTFWHY?

[Anonymous Coward]

One of my favourite parts of ditching Ubuntu for Slackware these days is that it boots with LiLo instead.

In my 27 years of screwing around with computers, no piece of software has fucked me in the ass more times than GRUB. This includes everything from Commodore, Atari, Microsoft, Sun Microsystems, Apple, etc. Maybe I'm just doing it wrong or something, I dunno. But sometimes I wouldn't do anything, and it would just randomly mash the MBR on the Windows drive, unprovoked. Or sometimes chainloading works, sometimes it doesn't.

LiLo on the other hand, was always simple, elegant and very straightforward to set up and maintain.

"Tools should do one thing, and do it well."

MOD PARENT UP.

[The One KEA]

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

Re:MOD PARENT UP.

[zixxt]

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

LILO is still around, Its my boot manger because its Slackware default boot manager. It works like a charm....

Re:My thoughts after several months with Btrfs for

[pxc]

It's also here on my installation of Ubuntu Natty, but it still doesn't actually _fix_ any errors, although it's happy to tell you about them. :-P

But it is good to see that it exists in some form by now. :-)

ZFS is not just yet another filesystem

[Anonymous Coward]

ZFS has bunch of features that others lack (Btrfs might become ZFS replacement in the future, say 10 years from now). ZFS has copy on write, instant snapshots, end to end checksums, deduplication, raidz, stuff etc. all integrated well together.

It was designed for for huge filesystems, but I have adopted it to home and small office file servers too (I use OpenSolaris as fileserver OS only because of ZFS), it just makes management and reliability so much easier to achieve.

Boot from RAID5!

[lanner]

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.