Linux 3.6 Released 143
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 (Score:4, Interesting)
"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? (Score:5, Interesting)
Mostly about btrfs (Score:4, Interesting)
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) (Score:2, Interesting)
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 (Score:4, Interesting)
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 (Score:5, Interesting)
Sounds like Windows' IIS (Score:5, Interesting)
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? (Score:4, Interesting)
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? (Score:4, Interesting)
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 (Score:2, Interesting)