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

TCP Fast Open

[w1z7ard]

Sounds like a great feature! From the article:

"Fast Open could result in speed improvements of between 4% and 41% in the page load times on popular web sites. In this version only the client-side has been merged."

BTRFS experiences?

[timeOday]

I'd be interested to hear what uses people have found for the advanced features of BTRFS. (BTRFS snapshots on a RAID1 volume seem like a great /home partition?) Since BTRFS is gradually evolving it's kind of hard to get a grasp of what is currently available and trustworthy (although this approach is vastly preferable to Microsoft's approach [wikipedia.org] to revolutionizing the filesystem - aim high and never deliver!)

Mostly about btrfs

[javilon]

The most active area seems to be btrfs. What is the general opinion, is it ready for general usage?

Any one with feedback from production setups?

Still no TRIM on software RAID (md)

[Anonymous Coward]

Still no TRIM on software RAID (md).

Astounding that all the other components (major filesystems, device mapper, LVM) support TRIM but the underlying md devices still don't.

Re:Mostly about btrfs

[mlts]

btrfs is coming along, but most distros still tend to have ext4 as a default. The one thing that btrfs really and desperately needs is filesystem deduplication. Even Windows now has that in place (although it is of a delayed variety where a background task searches for identical blocks and replaces the copies with pointers.)

Re:TCP Fast Open

[Marillion]

On the and-user client side, there may not be much noticeable improvement. But on servers and/or load-balancing front ends this type of improvement could be quite significant.

Sounds like Windows' IIS

[PhrostyMcByte]

This sounds a bit like they generalized the clever latency-saving behavior of IE [slashdot.org] which skips the TCP handshake when talking to IIS and leaves connections half-open. Latency could indeed be greatly improved for servers supporting it.

Re:BTRFS experiences?

[Rich0]

Sure, if you don't mind it being a pain to dynamically reallocate space between all your filesystems.

Oh, can you copy a 300GB file full of data in a few milliseconds and have the copy only occupy the space necessary to capture the differences between them? No, I don't want a hard link - I want changes to either file to not affect the other.

You can also instantly snapshot files, directories, or the entire filesystem, and the snapshots are first-class citizens (they can be modified, be used in place of the originals, etc).

Oh, and if the power dies in the middle of writing a RAID stripe you don't lose anything beyond the changes to the files you were intending to modify.

Btrfs will be the standard filesystem on linux in a few years - nobody really doubts that. Its main issue now is that it is still fairly immature.

Re:BTRFS experiences?

[Bengie]

I know I tend to play Devil's advocate in an almost trollish way, but it invokes great responses like your's and bluefoxlucid. It seems if you don't get people defensive on the internet, they tend to ignore your posts and don't reply with potentially great stuff.

Anyway, I didn't know about LVM and it looks quite "great". One question I have about it is that it supports allowing a volume to have a RAID1 style backing. If some of the data got silently corrupted in one of the mirrors, how would EXT4 decide which data to choose and how would it fix it or does LVM do this?

The biggest logical issue I've seen with separating volume managers from the FS is that the two typically don't communicate. This lack of communication hurts the overall resiliency. Not to say the FS and volume manager couldn't communicate via an API or something.

Re:And if you're not a fan of binary blobs

[unixisc]

Yeah, good choice if you don't want your wi-fi or networking or 3D graphics accelaration to not work just b'cos the drivers aren't liberated firmware. Although that would beg the question - why not use Hurd, which would probably be GPL3 or beyond?