Forgot your password?
typodupeerror
Linux

Linux 3.6 Released 143

Posted by samzenpus
from the brand-new dept.
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."
This discussion has been archived. No new comments can be posted.

Linux 3.6 Released

Comments Filter:
  • by o5770 (2739857) on Monday October 01, 2012 @11:00AM (#41513395)
    While the new features like quota groups, snapshot diffs and tcp "fast open" are great, what's really bothering this version is its tendency to
  • by Anonymous Coward on Monday October 01, 2012 @11:09AM (#41513503)

    Swap over NFS is something I've been waiting a long time for =)

  • by Anonymous Coward on Monday October 01, 2012 @11:15AM (#41513563)
    • by Microlith (54737)

      Yup. I'm a fan of hardware arbitrarily failing to function. Looking at the list of distros that use it, they're all pretty much irrelevant at this point.

    • Re: (Score:2, Interesting)

      by unixisc (2429386)
      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?
    • I would really like to know why in Linux the drivers are included with the kernel, and not as separate packages.
  • TCP Fast Open (Score:4, Interesting)

    by w1z7ard (227376) <(moc.liamg) (ta) (enoiccip.olemrac)> on Monday October 01, 2012 @11:31AM (#41513699) Homepage
    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."
    • by Viol8 (599362)

      4% just possibly, 41%? Highly unlikely. The main slowdown on loading pages or any data is DNS lookup then the data itself. The time taken for actually doing all the TCP negotiation for a connection is trivial in comparison. Its only a few small packets after all.

      • Opening a TCP connection requires, at the absolute minimum (using the right tricks), one packet each way. A DNS query needs one packet each way, assuming the server has the answer cached. The DNS server is usually going to be closer, so the DNS query should almost always take less time than opening a TCP session.
        • by Viol8 (599362)

          "A DNS query needs one packet each way, assuming the server has the answer cached."

          Its pretty unlikely your local DNS server is going to have all the addresses in even a single web page cached , never mind an entire site. And if it doesn't then the query has to wander back up the DNS tree with all the packet passing that entails - which is what takes the time.

      • Re:TCP Fast Open (Score:5, Interesting)

        by Marillion (33728) <ericbardesNO@SPAMgmail.com> on Monday October 01, 2012 @12:09PM (#41514119)
        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.
      • by Bengie (1121981)
        Think high latency connections, like 3G/Satellite where a 3-way handshake is expensive.
    • by PhrostyMcByte (589271) <phrosty@gmail.com> on Monday October 01, 2012 @01:53PM (#41515713) Homepage

      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.

      • by snadrus (930168)
        The difference being this is a previously-unimplemented feature of a standard approved a decade ago, so lots of eyes have already considered it.
  • BTRFS experiences? (Score:5, Interesting)

    by timeOday (582209) on Monday October 01, 2012 @11:31AM (#41513703)
    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!)
    • by siDDis (961791)

      I'm not using BTRFS yet, however as send & receive in BTRFS is similar to the ZFS send & receive implementation you can do really cool things like superquick backup of a gigantic PostgreSQL Database.

      The workflow is as following
      Execute "pg_start_backup(‘snapshotting’,true)"
      Snapshot the filesystem with PostgreSQL data
      Execute "pg_stop_backup()"
      Send the snapshot to your backup server

      • I do that with ext4 already. Hell I do that with ext2.
        • by Bengie (1121981)
          Can you add randomly sized disks to EXT4 and transparently grow the volume? Yeah, didn't think so.

          I'm not saying EXT4 is "bad", I'm just saying BTRFS has A LOT more useful features, just less tested and has some trade-offs.
          • by flok (24996) <mail@vanheusden.com> on Monday October 01, 2012 @01:55PM (#41515755) Homepage Journal
            If you have LVM underneath the ext4 filesystem, you can indeed randomly grow the fs.
            • by Rich0 (548339) on Monday October 01, 2012 @03:27PM (#41516987) Homepage

              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.

            • by Bengie (1121981) on Monday October 01, 2012 @03:42PM (#41517175)
              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.
              • by Dolda2000 (759023)

                You don't normally use LVM for RAID1 (you can, but it kind of sucks and is a bit immature). Normally, you'd use mdraid for that, and then construct a LVM PV from the resulting mdraid device(s).

                Neither ext3, LVM nor mdraid checks for silent corruption, however. That's strictly a feature of filesystems like ZFS or btrfs that explicitly checksum all data.

              • by Cato (8296)

                LVM has some issues of its own, and requires careful setup to avoid data loss. Also its snapshots are quite buggy and slow. See http://serverfault.com/questions/279571/lvm-dangers-and-caveats/279577#279577 [serverfault.com] for details.

          • Thin provisioning etc, as well ext4 lets you shift the journal and do full ordered write (so you can use an SSD for a journal, and avoid all that sync() to slow hard disk and have bulletproof journaling with both data and metadata, ordered properly).
    • by Anonymous Coward

      A bit dated, but I had a pretty large data loss about a year ago-- about 6 months into my btrfs experiment. Most files were backed up, but I did lose a bit of work.

      btrfs also uses quite a bit of memory (no, modern desktop users will not notice), but I was playing around with btrfs on my arm board, and the mem overhead was noticeable.

      I ended up deciding to let others be the alpha testers.

    • by Bigby (659157)

      I use it on a MythTV server. I don't know if it is has been added yet, but it was lacking support to remove a stripped device. I want it to re-balance off of that disk, so I can replace it or upgrade it.

      Can /boot be btrfs yet?

      Otherwise it is pretty cool.

    • by mcelrath (8027) on Monday October 01, 2012 @01:53PM (#41515725) Homepage

      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.

      • by Rich0 (548339)

        Still waiting for more stability and raid5 support, but I agree, it definitely is going to be the way to go at some point.

      • It was only in the last year or two that ext4 got to the point where it was considered reliable enough for production use. That was released in 2008 and we didn't switch any production stuff over until 2010 or 2011.

        I expect btrfs to have a similar roll-out period which means you won't see it heavily used in production until late-2013 or 2014. Especially since it's still being actively hacked upon and doesn't seem to be feature complete yet.

        Pessimistic view says 2015 before it's a safe choice for produ
      • Wait..

        Perhaps corruption was not BARTFS but because you unmount before sync after your ATI panics!
        TRY: REISUB
        • by mcelrath (8027)

          Good catch! Sadly, in fact I have been doing U before S. I even knew what both of them did!!!!

          Well, score one more for btrfs, that my idiocy did not result in any disk corruption.

    • I've used it for a couple years now. My experience:

      The good:

      Snapshots are a killer feature.
      Integrated redundancy is much nicer than RAID.
      Integrating LVM into the FS is very nice.

      The bad:

      sync is SLOW, and dpkg will suffer. You can work around it by creating a snapshot and then running 'eatmydata apt-get whatever' - and accept that you'll have to roll back if you have a power failure mid-install.

      It finally has a functional fsck, but I don't trust it yet with mission-critical data.

      Generally it works well, bu

      • by mcelrath (8027)
        I think fsck is a non issue. I can't count the number of times fsck has swiss-cheesed my disk, filling /lost+found with thousands of numbered files. In no way is that kind of treatment of my data a "recovery". What btrfs had that is far more valuable than fsck is snapshots. I'll take a mountable, old snapshot over numbered inodes in /lost+found any day.
    • by unixisc (2429386)
      In fact, how does BTRFS compare to BSD and other unix file systems like ZFS, Hammer, XFS, UFS, Veritas and so on?
  • Mostly about btrfs (Score:4, Interesting)

    by javilon (99157) on Monday October 01, 2012 @11:41AM (#41513805) Homepage

    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?

    • by mlts (1038732) * on Monday October 01, 2012 @12:09PM (#41514117)

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

    • by Anonymous Coward

      Dunno...I couldn't trust it for production, so I don't have a production setup. I tried to simulate bad blocks by writing random zeroes to random places on an unmounted FS, for different file systems. For mounting and repairing the FS, my order of confidence would be in ext4, then XFS, then ZFS on FreeBSD (especially mirrored), UFS on FreeBSD, then JFS, then NILFS2. As far as btrfs goes, errors seem to panic the kernel--does btrfs default to errors=panic?--and even when using the built-in RAID1, btrfs wo

  • by 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.

    • by Rich0 (548339)

      How often does an entire stripe become empty? And the software RAID layer would need to keep track of cumulative TRIMS on all the blocks in the stripe so that it could issue the TRIM when the whole thing becomes empty. Then you need someplace to store that metadata, and will doing that cause more problems than the TRIM fixes?

      That said, might be nice if it worked since a rebuild could skip known-empty areas.

      Of course, eventually btrfs is likely to make many md applications obsolete. Obviously it isn't the

    • by Mad Merlin (837387) on Monday October 01, 2012 @05:58PM (#41518805) Homepage

      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.

  • As a Linux noob, how do I learn what all of those words mean? The only one I even vaguely recognize is TCP and i don't even know what that is. Until someone responds, I'll be at Google.
  • Ask Woz thread: 318 comments
    Linux 3.6 thread: 82 comments

    I guess we know what stuff matters. :/

An optimist believes we live in the best world possible; a pessimist fears this is true.

Working...