Slashdot Mirror

← Back to Stories (view on slashdot.org)

Linux 3.2 Has Been Released

Posted by samzenpus on from the check-it-out dept.

diegocg writes "Linux 3.2 has been released. New features include support for Ext4 block size bigger than 4KB and up to 1MB, btrfs has added faster scrubbing, automatic backup of critical metadata and tools for manual inspection; the process scheduler has added support to set upper limits of CPU time; the desktop responsiveness in presence of heavy writes has been improved, TCP has been updated to include an algorithm which speeds up the recovery of connection after lost packets; the profiling tool 'perf top' has added support for live inspection of tasks and libraries. The Device Mapper has added support for 'thin provisioning' of storage, and a support for a new architecture has been added: Hexagon DSP processor from Qualcomm. New drivers and small improvements and fixes are also available in this release. Here's the full list of changes."

10 of 271 comments (clear)

  1. Btrfs by davegaramond · · Score: 4, Interesting

    So does this mean I can start using btrfs, at least for personal workstations? I've got a new box at the office waiting to be setup, with a 120GB Corsair SSD as the main system disk, normal 2TB harddisk as backup/media storage. Will be using Debian. Should I use btrfs?

    1. Re:Btrfs by Anonymous Coward · · Score: 5, Interesting

      Short answer: no.

      Long answer: Please! The more people exercising the code, the more bugs will be revealed, and the more confident the developers can be. But you will have to be ready for some performance regressions and data loss danger. For the brave.

    2. Re:Btrfs by Anonymous Coward · · Score: 3, Interesting

      Even without any crashes or power fails, I've managed to corrupt BTRFS in testing, with just a defrag (as recently as 3.2-RC6). I wouldn't look at BTRFS for a while, at least until it's no longer marked experimental. By all means test away, but don't assume you'll be able to get to any data you put in it.

    3. Re:Btrfs by Anonymous Coward · · Score: 5, Interesting

      Performance is still pretty bad, especially when deleting many small files. It can take minutes with BTRFS, while EXT4 does it almost instantly in comparison.

    4. Re:Btrfs by mattbee · · Score: 3, Interesting

      btrfs is tanatlizing for VMs because of the copy-on-write file behaviour (i.e. "cp --reflink a b" creates b instantly regardless of the size of a), but http://lists.fedoraproject.org/pipermail/devel/2011-July/154251.html is still an issue, as far as I'm aware. So storing VMs, where you access them with O_SYNC, just gets slower over time until it's unusable. I'm not quite brave enough to suggest that any of our customers use it, at least until there's a working fsck.

      --
      Matthew @ Bytemark Hosting
    5. Re:Btrfs by adolf · · Score: 4, Interesting

      I'm just one man, but I've tried hard over the past decade to find a real problem with NTFS (and I've been sternly bitten by ReiserFS and ext2/3 over that same period), and just haven't: It's worked on the many hundreds of computers I've fondled just fine, and even seems to survive mild hard disk failure with some amount of reasonableness.

      What, in your opinion, makes NTFS a pain in your ass? (I ask because I'm curious and want to avoid any such scenario, not because I am predisposed to attack your observations.)

      --
      Kid-proof tablet..
    6. Re:Btrfs by ducman · · Score: 3, Interesting

      I MISS btrsf!

      I had a home server with 6TB of disk using btrfs and a second server with the same amount of disk, also using btrfs for backup. I had a power failure while the rsync backup was running, and both btrfs filesytems were mangled. I managed to recover most of the stuff after a couple days' worth of work, but I definitely changed back to xfs on LVM2.

      Btrfs was so much simpler, and I was able to maintain > 60 Mb/s write speeds to a set of crapy disks that only manage 12-14 Mb/s writes, now. I know I could RAID my disks to get back to those speeds, but with btrfs I was able to grow my server by replacing one disk at a time. With RAID and LVM2, it's not worth that much effort for a home media server.

      --
      "We have nothing in common, your attitude annoys me, and your political views are appalling."
  2. Re:Popcorn loaded, commence fanatical BS... by RobbieThe1st · · Score: 2, Interesting

    I still say we should lynch EXT3/4(even though I use it) due to it's complete /inability/ to undelete files.
    Because, as we all know, people /never/ manage to accidentally delete files and /always/ have recent backups handy.

  3. Re:Forgive my ignorance by Microlith · · Score: 2, Interesting

    That was Ubuntu, as I recall, and not necessarily the greater kernel community. I'm sure they'd rather play it safe and have a slightly more power hungry but stable system than risk crashing people's systems because OEMs are incompetent and can't report their shit properly.

  4. Re:Version number MADNESS by Anonymous Coward · · Score: 1, Interesting

    Wake me when we get to 7.1. At this rate it ought to be sometime this fall.

    Whats your problem? Linus chose to drop the extra number because it had become meaningless with the current development model of the kernel, and I have to agree with him that saying '2.6.34.3" was annoying in conversations; its much easier to just say 'oh im on kernel 3.{0,1,2} " Its quick, simple, rolls off the tongue much more easily. Also, major version numbers are still used to denote an API/ABI break. So unless you're telling me that Linus is going to accept patches that break the API/ABI on FOUR seperate occasions in the span of 7 months or so, the exaggeration is even more over the top than a normal expression

    -- Reaper924