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

And if you're not a fan of binary blobs

[Anonymous Coward]

there's Linux-libre.

http://linux-libre.fsfla.org/pub/linux-libre/releases/LATEST-3.6.0/ [fsfla.org]
http://en.wikipedia.org/wiki/Linux-libre [wikipedia.org]

Re:The consumers want to know

[Anonymous Coward]

It was some fine Tuesday back in 2008-09. Why do you ask?

Re:Mostly about btrfs

[bluefoxlucid]

Because you have people like me who say, "What we should do for deduplication is hash blocks and keep them in a fast bucket hash table cached in RAM and pointed to in the block index. Then we can occasionally compare identically-hashed pointers to see if the blocks are the same, and if so drop one or the other pointer and repoint the others. This dropping can be done by selecting the one with the highest use count as our new pointer, and altering old pointers as they're accessed rather than actively, until the duplicate pointer is empty." Someone says, "PATENTED ALREADY LOL!" It's not "I patented data dedup," it's "Here's every way I can think of to do it, PATENT NOW! Oh you did something vaguely similar to this one, that's mine..."

Re:Ok, ok, question

[jones_supa]

Try kernelnewbies.org and Wikipedia also.

Re:Ok, ok, question

[Lennie]

You might want this page then:

http://kernelnewbies.org/Linux_3.6 [kernelnewbies.org]

It usually has links to http://www.h-online.com/ [h-online.com] http://lwn.net/ [lwn.net] and/or Wikipedia which hopefully explains it in a way you'll understand.

Re:Mostly about btrfs

[Bengie]

Any transactional FS(ZFS/BTRFS) shouldn't need fsck. You always start from the last commited transaction or snapshot.

Re:BTRFS experiences?

[mcelrath]

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 [kernel.org]). Furthermore there is apt-btrfs-snapshot [patshead.com] 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 [wikipedia.org] 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.

Comment removed

[account_deleted]

Comment removed based on user account deletion

Re:Still no TRIM on software RAID (md)

[Mad Merlin]

Support for TRIM on RAID linear/0/1/10 md devices was quite recently added. The patch series is here: https://lkml.org/lkml/2012/3/11/261 [lkml.org]. I can't find the actual merge now, but I believe it'll be in 3.7.