Slashdot Mirror
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."
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.
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.
Don't thank God, thank a doctor!
I'd say that btrfs will be the replacement of ext4. Just not yet (at least for me).
Until it supports booting from paper tape or punch card, I'm not going to trust it 100%
Karma: Excellent. 15 moderator points expire sometime.
My distro ditched LILO a while ago and I miss it terribly. A simple conf file. What more could you ask?
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 ?
-Billco, Fnarg.com
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.
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...
- For the complete works of Shakespeare: cat
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.
I was promised a flying car. Where is my flying car?
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.
Repeal the 17th Amendment TODAY! Also Please Read http://www.gnu.org/philosophy/right-to-read.html
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...
Greylisting is to SMTP as NAT is to IPv4
"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
I8-D
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.
Comment removed based on user account deletion
Comment removed based on user account deletion
If you get random file corruption on Windows, you either have serious hardware failure or use Windows 98.
GRUB 2 at 1.99 *brain explodes*
Your hair look like poop, Bob! - Wanker.
I would probably switch from Ext4 to BtrFS if it had full Gparted support.
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.
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!
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...
WARNING! This girl exceeds the MAXIMUM SAFE standards established by the FDA for BRATTINESS
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.
note: i'm known as plugwash most places but i screwd up registering that here somehow in the past and now can't register
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?!
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).
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: /dev/DEV /dev/DEV
tune2fs -O extents,uninit_bg,dir_index
e2fsck -fDC0
(On an unmounted filesystem, obviously. Source. )
Has this been addressed in the new version?
I've actually been running the system I'm typing from with Btrfs on the root partition for some time now. Since I always have an ext2 /boot partition, I didn't have to worry about this.
I still wouldn't recommend using Btrfs for / unless you have a separate /home partition, though: there is not yet any fsck.btrfs! In addition to a separate /home partition, I'd recommend having another Linux install with ext4 alongside it, so if something does go wrong with your Btrfs partition, you can boot a fully 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.
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
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.
Support SETI@home
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.
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."
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.
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.
My other account has a 3-digit UID.
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...
SCREW THE ADS! http://adblock.mozdev.org/ Proud user of teh Fox of Fire - Registered Linux User #289618
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. :-)
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?
One thing I know, and that is that I am ignorant...
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.
Don't thank God, thank a doctor!
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.
Don't thank God, thank a doctor!
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.
Don't thank God, thank a doctor!
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.
Don't thank God, thank a doctor!
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.
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.
My understanding from reading the LKML in the past is that you "conversion" is still insufficient and falls short of an actual reformatting.
Shame they didn't just finish off reiser4, which I believe was almost done.
I am trolling
I also use Gentoo. /boot is ext2 /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.
/ is JFS
I've only
Ouch. Hopefully it's still faster than an ext3 fsck.
Support SETI@home
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.
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.
All of the above was encrypted with a Quad ROT-13 method. Unauthorized decryption is in violation of the DMCA.
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. :(
WARNING! This girl exceeds the MAXIMUM SAFE standards established by the FDA for BRATTINESS