Slashdot Mirror
Linux 3.6 Released
diegocg writes "Linux 3.6 has been released. It includes new features in Btrfs: subvolume quotas, quota groups and snapshot diffs (aka 'send/receive'). It also includes support for suspending to disk and memory at the same time, a TCP 'Fast Open' mode, a 'TCP small queues' feature to fight bufferbloat; support for safe swapping over NFS/NBD, better Ext4 quota support, support for the PCIe D3cold power state; and VFIO, which allows safe access from guest drivers to bare-metal host devices. Here's the full changelog."
there's Linux-libre.
http://linux-libre.fsfla.org/pub/linux-libre/releases/LATEST-3.6.0/
http://en.wikipedia.org/wiki/Linux-libre
I've been using btrfs on two computers for about a year now. I'd say it's quite stable. I'm using it for /home as well as a data partition, with zlib compression on /home. The snapshot feature is amazing and should be used liberally. Early on I experienced some disk corruption (mostly due to rapidly switching kernel versions 3.0, 3.2, 3.4, 3.5), which was not a problem because there existed snapshots on the disk. The primary partition can be corrupted, but if you have an uncorrupted snapshot, you can mount it. So, it's a good idea to get in the habit of making regular snapshots. I've been doing it by hand, but a daily rotating snapshots would be a great idea for reliability. There are many cron jobs, shell scripts and whatnot to accomplish this (e.g. Autosnap). Furthermore there is apt-btrfs-snapshot which on Debian/Ubuntu systems will automatically snapshot whenever upgrading/installing a package. This basically takes care of changes in /usr (and you'll need a cron job for /home). The only real drawback I've encountered is that dpkg is very slow (likely due to my use of zlib compression). But dpkg's database access has been a snail for a long time and is dpkg's problem (and I hope someone looks into this soon, it's pissing me off -- zlib just exacerbates the problem). But since apt-get upgrade can run in the background while I'm working, it doesn't really bother me.
I'm also using RAID1 on all magnetic disks (plus one SSD not in a RAID configuration). After countless disk failures, I just don't trust magnetic disks any further than I can throw them. And, they are cheap enough that two instead of one is not a huge burden. In the last year, I have not had occasion to recover from a failure due to RAID1, but I have experimented with mounting one half of the RAID1, and it operates normally. There are a few tricks to re-sync the drives when its partner is re-added to the array, that one should be aware of. It's not fully automatic. One of my RAID1 arrays is over two LVM volumes, with the left half consisting of a single 3 TB disk, and the right half consisting of three disks concatenated into a single LVM. This makes it easier to add disks later. LVM and btrfs can both resize.
A couple things to be aware of: you cannot place a swap file on a btrfs partition. So use another filesystem, a full partition, or just buy more RAM (my preferred solution). You should not use a kernel version less than 3.5. There have been many fixes between 3.0 and 3.4, and you're asking for trouble if you use btrfs on a 3.0 or 3.2 kernel. Since I installed 3.5 kernels on all my machines, I have not had any btrfs-related problems. FWIW, I regularly have to reboot because ATI's shitty video driver causes a kernel panic, sometimes via a hard reset. I have yet to see any filesystem corruption due to this. And everyone should know how to use the Magic SysRq key in the event of kernel panics too. (Alt-SysRq- REIUSB should unmount, sync, and boot, leaving filesystems in a consistent state)
I highly recommend BTRFS at this point. I'm not sure the distributions are up to noob auto-installs, but if you like to do things yourself, it offers a lot of advantages over ext4.
1^2=1; (-1)^2=1; 1^2=(-1)^2; 1=-1; 1=0.