GRUB 1.99 Released With Support For ZFS and BtrFS 175
kthreadd writes "GNU GRUB has been updated to version 1.99. Among the many improvements are support for two new filesystems, BtrFS and ZFS. For Linux users this means that it's now possible to move to BtrFS entirely and not use it only for non-bootable volumes."
Awesome (Score:2)
I was just wondering when we'd get support for ZFS, now that I can install GRUB2 on FreeBSD. Now, next chance I get, I can reinstall the various OSes on my computer and hopefully create a situation where I can triple boot things.
Needs better support for really old tech. (Score:5, Funny)
Until it supports booting from paper tape or punch card, I'm not going to trust it 100%
Re: (Score:3)
Filesystem bandwagon (Score:3)
I know about ZFS (somewhat), but what's the big appeal of Ext4 and BtrFS ? Cool that Grub can boot from them, but do they confer any tangible benefits for desktop users ?
For personal use, I care about two things:
1. How safe is my data
2. How quickly can I access it
Ext3 seems to address both concerns quite acceptably, so what do these newer filesystems do better ? And why would anyone want to use that on their boot partition ?
Re:Filesystem bandwagon (Score:5, Insightful)
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: (Score:2)
Re:Filesystem bandwagon (Score:4, Interesting)
I'd take a look here: Btrfs [wikipedia.org] The main problem I have with it is that there's a large number of filesystems out there and while that's not really a bad thing, it makes interoperability a real headache sometimes. Personally, I'd rather have a somewhat less than perfect filesystem (assuming that it is reliable than a huge variety of specialty filesystems which may or may not be readable under any other OS.
And apart from ZFS suffering from NIH problems as well as the CDDL licensing, I really don't see any compelling reason to add yet another filesystem that does largely the same thing.
Re: (Score:2)
And apart from ZFS suffering from NIH problems as well as the CDDL licensing, I really don't see any compelling reason to add yet another filesystem that does largely the same thing.
The licensing is by far the biggest problem with ZFS. It will never be part of the kernel - so this isn't ZFS vs btrfs, but rather btrfs vs nothing (or ext4/etc).
Re: (Score:2)
ZFS doesn't really suffer from licensing problems. The OpenSolaris derived implementations (Solaris/FreeBSD/OpenIndiana), do however suffer from that problem.
I would like to point out that ZFS has been available under GPL for a long time as GRUB patches to Solaris/OpenSolaris/Solaris_Express, and just recently integrated into the mainstream GRUB.
The only milestone to adopting it in Linux is the insane amount of work. The GRUB implementation is GPL and it clearly exposes the internals of ZFS enough to implem
Re: (Score:2)
Re: (Score:2)
Well, how else do you explain Linux' obsession with having a filesystem that nobody else can use?
I've lost enough data over time from those filesystems going down in flames to realize that historically they suck. Now Btrfs and Ext4 are a lot better, but lets be honest about the fact that historically Linux has had serious problems with its filesystems and one has to be kind of wonky to trust it with any important data.
I'm not sure how to interpret that other than NIH, bear in mind that the primary reason fo
Re: (Score:2)
Re: (Score:2)
Google would [arstechnica.com] disagree [slashdot.org] with you.
Re: (Score:2)
Yeah... important data like your Oracle databases.
Now, since Linux has an open development model people have always been free to live dangerously. You always have the option of being an early adopter and you can get burned by that. However, that's not a Linux failing. That is trolls trying to use the openness of Linux against it.
Re: (Score:2)
> Well, how else do you explain Linux' obsession with having a filesystem that nobody else can use?
This is just FUD and nonsense.
ANYONE ELSE can use a Linux file system. It's Free Software
The idea that Linux filesystems are any less robust than alternatives is also just FUD and nonsense.
Many of us have been abusing Linux for a good number of years without significant incident or any incidents at all.
Re: (Score:2)
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: (Score:2)
Oh since you say you know something about ZFS, BtrFS is basically an open ZFS, so that should tell you something.
Re: (Score:2)
Interestingly, they're both products of Larry Ellison.
The Ext* series of filesystems still has a place against the megacorps?
Re: (Score:3)
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
Re: (Score:2)
Re: (Score:2)
Wrong? It was an extreme simplification but BtrFS' features are very similar to ZFS.
Re: (Score:2)
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: (Score:2)
The main advantage that btrfs has isn't speed, but that it can do copy-on-write. For a home user that for example means that he could copy his whole root file system before a dist-upgrade and thus have an easy way to undo the dist-upgrade when he doesn't like it, i.e. two commands that take a second to run thanks to copy-on-write instead of messing with a full backup and replay that might take an hour. Or the ability to have timemachine like backup functionality with essentially no overhead.
Re: (Score:2)
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: (Score:2)
Btrfs is faster than traditional filesystems for many loads, too. It does suffer from abysmal fsync() speed, though. The latter applies to certain databases -- which are essentially filesystems in a file, and dpkg which fsync()s both the updated files and its info files every roughly a single byte or so. Dpkg includes hacks like sync_file_range(temp file); fsync(temp file); close(temp file); opendir(dir); fsync(dir); rename(temp file, real file); fsync(dir); -- for every single file it operates on, to wo
Re: (Score:2)
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" :-)
About the same as ext4, give or take. The reasons for going from ext4 to btrfs are much the same as going from UFS to ZFS. F
Re: (Score:2)
Personally, I don't see a reason to use Ext4 yet on
Boot separate from partitions (Score:4, Informative)
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: (Score:2)
And for others there is just one operating system and bootloader might as well sit on / partition. And everybody is happy.
GRUB as an OS? (Score:3)
Re: (Score:2)
Well, one of the nice things about linuxbios/etc is that it offers a great deal more versatility.
Do you really want to have to have a hard drive installed just so that you can boot off of an OS image on a SAN? Or a USB drive or whatever?
The whole purpose of a boot loader is to find a kernel and boot it. Anything that makes it possible for the bootloader to find a kernel on a more exotic architecture is perfectly in-scope as far as I'm concerned, as long as it doesn't leave anything behind in RAM once it i
Re: (Score:2)
Any kernel, anywhere? There's already a tool that can do that. It's called Linux. And it has far more capability than GRUB. Can GRUB grab a kernel via rsync over ssh and boot it? Linux can (be set up to) do that.
See Kexec [ibm.com].
I'd rather be able to just have a fixed place to put a kernel, and have that place always boot. LILO isn't good enough because it requires running its "lilo" command to build a block index. The better way to very simply boot a kernel is to sequentially write that kernel to it's own
Re: (Score:2)
Any kernel, anywhere? There's already a tool that can do that. It's called Linux. And it has far more capability than GRUB. Can GRUB grab a kernel via rsync over ssh and boot it? Linux can (be set up to) do that.
See Kexec [ibm.com].
And without burning linux in your BIOS, how do you propose to run it on a system that lacks a hard drive? The best you can do right now is PXE, and that has a lot of limitations. At the very least you need to control the dhcp server to do it.
The parent was arguing that bootloaders should be simple, and I was arguing that complexity is fine if it suits their purpose, which is loading the kernel. I'd love to see LinuxBIOS being standard on all PCs, as it is a more versatile way of finding and loading the k
Re: (Score:2)
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? (Score:4, Funny)
When it has integrated EMACS?
MOD PARENT UP. (Score:2)
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: (Score:3)
I want my BIOS so bad ass it runs BSD and needs its own BIOS.
Re: (Score:2)
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: (Score:2)
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: (Score:2)
Solaris, uses Grub.
Re: (Score:2)
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: (Score:2)
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: (Score:2)
Leave it to Linux (Score:2)
GRUB 2 at 1.99 *brain explodes*
limited Gparted support for BtrFS (Score:2)
It's neat that we can boot off of them... (Score:4, Funny)
This is really cool. Now when one of these filesystems becomes stable in Linux, we'll be ready to go. Look out 2025--here I come!
Re: (Score:2, Interesting)
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
1.99?! (Score:2)
Re: (Score:2)
Re: (Score:2)
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: (Score:2)
Any improvment in diagnostics? (Score:2)
Has this been addressed in the new version?
My thoughts after several months with Btrfs for / (Score:2)
I've actually been running the system I'm typing from with Btrfs on the root partition for some time now. Since I always have an ext2 /boot partition, I didn't have to worry about this.
I still wouldn't recommend using Btrfs for / unless you have a separate /home partition, though: there is not yet any fsck.btrfs! In addition to a separate /home partition, I'd recommend having another Linux install with ext4 alongside it, so if something does go wrong with your Btrfs partition, you can boot a fully functiona
Re: (Score:2)
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. :-)
Boot from RAID5! (Score:2)
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.
Re:Does this matter? (Score:4, Insightful)
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: (Score:3)
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? (Score:5, Insightful)
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: (Score:2)
Re: (Score:2)
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 sim
Re:Does this matter? (Score:4, Interesting)
"In 2008 the principal developer of the ext3 and ext4 file systems, Theodore Ts'o, stated that ext4 is a stop-gap and that Btrfs is the way forward,[10] having "a number of the same design ideas that reiser3/4 had". http://en.wikipedia.org/wiki/Btrfs [wikipedia.org] & http://lkml.org/lkml/2008/8/1/217 [lkml.org]
Re: (Score:3)
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? (Score:5, Informative)
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. [kernel.org] )
Re: (Score:2)
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: (Score:3)
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: (Score:2)
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, fo
Re: (Score:2)
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: (Score:3, Insightful)
If you get random file corruption on Windows, you either have serious hardware failure or use Windows 98.
Re: (Score:2)
Re: (Score:3)
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
Re: (Score:2)
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: (Score:2)
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. Yo
Re: (Score:2)
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: (Score:2)
Unless it's from the hookers!
Re: (Score:2, Informative)
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: (Score:2)
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: (Score:3)
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
Re: (Score:2)
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: (Score:2)
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
Re: (Score:2)
Re: (Score:2)
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...
Re: (Score:2)
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: (Score:2)
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: (Score:2)
Yeah it always workrkrkrkrkrkrkrkrkrkrkrkrkrkrkrkrkrk
I never had a probobobobobobobobobobobobobobobobob
Re: (Score:3)
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: (Score:2)
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: (Score:2, Insightful)
With GRUB you had a conf file
which is simpler?
Fixed that for you... /boot/grub/grub.cfg, an /etc/default/grub with some stuff in it and a couple of files in /etc/grub.d/
Now with grub2 you have three config files (at least in Ubuntu); a read-only
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: (Score:2)
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 m
Re: (Score:2)
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? (Score:5, Funny)
LI
Re: (Score:2)
Re: (Score:2)
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: (Score:2)
Re: (Score:2)
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? (Score:4, Insightful)
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: (Score:2)
...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: (Score:2)
Re: (Score:2)
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: (Score:2)
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: (Score:2)
But the lack of grub-probe is the only reason this system:
sauer@hotrod:~$ awk '$1!~"#"&&$2~"/(boot)?$"' /etc/fstab /boot xfs noatime,nodiratime,sync 0 2
UUID=e332a6e4-9e5f-420c-a86e-f376d70e0fdb / btrfs noatime,nodiratime,compress,ssd 0 1
UUID=0c39bf26-ffb4-4eed-ac2c-2114b8681a12
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, b