Slashdot Mirror


Linux 3.2 Has Been Released

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

27 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 francium+de+neobie · · Score: 5, Informative

      There's no fsck.. So unless you're 100% sure your Linux machine never crashes and your power supply is never interrupted - don't.

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

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

    5. 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
    6. Re:Btrfs by 0123456 · · Score: 4, Informative

      If this is the case, whats the fucking point really? BTRFS was heralded are the replacement for ZFS, but you are seriously telling me that after all this time, you can still lose a large amount of data and end up with a corrupt filesystem after such a trivial thing as a powerloss? Really?

      BTRFS has only been around for a short time and I don't believe any OS uses it as the default filesystem yet. And you're surprised that it still has problems?

      And I don't remember anyone claiming that BTRFS would replace ZFS, merely that it would eventually have many of the same capabilities that ZFS has.

    7. Re:Btrfs by tetromino · · Score: 5, Insightful

      If this is the case, whats the fucking point really?

      The fucking point is to encourage beta-testers. Bleeding-edge users who know what they are doing and don't care about data loss are being offered the chance to test a new and interesting filesystem and (ab)use it in ways that upstream developers had not thought of, hopefully uncovering major bugs before the thing will get marked as feature-complete and enabled by default for new installs by major distros.

    8. Re:Btrfs by ILongForDarkness · · Score: 4, Funny

      format /dev/null as BTRFS then?

    9. Re:Btrfs by waveclaw · · Score: 5, Insightful

      Bleeding-edge users who know what they are doing and don't care about data loss are being offered the chance to test a new and interesting filesystem

      Amen.

      fsck's only job is to make that junk that was a filesystem look something like a filesystem again. Nothing in there about making it look like the particular filesystem you used to have. fsck is not backups. fsck will not (necessarily) get your data back. fsck may eat kittens on a bad day. What fsck does hand back to you should not be trusted and should certainly be verified.

      If you think that pulling most of what was /home, /var, /srv or /opt out of lost+found is fun, just remember that corrupted directory and filenames get named after their inodes. Nothing like trying to figure out of 1234567 or 1234568 was the start of the quarterly financials report.

      If you are relying upon a fsck to get your data back after a power outage, you have more faith in your filesystem than you should. It's a nice validation tool, with the caveat that a False Negative means you go back to using a damaged filesystem for more fun later, rather than now.

      BUT if you have backups, please do test. Having talked to the BTRFS team directly at LINUXCON, Mr. Chacon and folks are pretty cool about getting feedback. And you can do nifty things like snapshots for backups on RAID10 or thin disks on virtual machines which don't inflate during formatting.

      For many filesystems, failing a fcsk means reaching for the format tools and the last (verified) backup. You are backing up everything, right?

      --

      "You cannot have a General Will unless you have shared experiences. You cannot be fair to people you don't know."
    10. Re:Btrfs by Sloppy · · Score: 4, Funny

      Short answer: no.

      Long answer: Please!

      In other words, "better you than me."

      --
      As copyright owner of this comment, I authorize everyone to defeat any technological measure which limits access to it.
    11. 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.)

    12. Re:Btrfs by subreality · · Score: 5, Informative

      BTRFS is journaled (the log tree), so you don't lose data due to a power failure. It just replays the journal when you mount it again.

      btrfsck is only really needed to recover from something unanticipated happening. Like software bugs. The kind that you'd expect in a new filesystem. So it's absolutely not ready for prime-time until a fsck is released.

      For non-critical systems it's completely usable for people who like to experiment with the new toys. I've been using it for a year on my laptop (including multiple power losses and other shenanigans) with no problems.

      My experience so far:

      Good:

      Snapshots (and subvolumes) are a killer feature. Having hourly and daily versions of everything is wonderful. I have subvolumes for root (@) and /home (@home). If I want to roll back my entire system but keep my homedir, I can simply: "cd /snap ; mv @ @-2012.01.04-broken ; btrfs subv snap @-2012-01-02--00-40-39-apt @ ; reboot". Translated - Save a copy of my current root; create a new root from the last snapshot that was automatically created when I last ran apt-get ; then reboot (all shutdown continues in the @-2012.01.04-broken subvolume, it doesn't corrupt the new @). Killer. Feature.

      Bad:

      fsync is god.awful.slow. And dpkg does a whole lot of fsync. It's completely unacceptable performance, and either btrfs has to get faster or dpkg has to be a little more miserly with fsync. If dpkg could send write barriers instead of syncs it'd probably solve it, but who knows. For the time being: "apt-get install eatmydata; ln -s `which eatmydata` /usr/local/bin/aptitude ; ln -s `which eatmydata` /usr/local/bin/apt-get" . eatmydata preloads a library that overrides sync and fsync (they're simply ignored). dpkg is now screaming fast, but I run the risk of completely screwing its metadata if there's a crash or poweroff while it's doing something. So the solution is I have a /etc/apt/apt.conf.d/80-snapshot that creates a snapshot before every apt run. If something goes wrong, I just roll back the system like I mentioned under Good.

      So in summary: Some good, some bad, definitely not fully baked yet, but completely usable if you're adventurous. No fsck required. Yet. Keep backups. :)

    13. Re:Btrfs by dbIII · · Score: 4, Informative

      Performance can be a pain with very large files and with a lot of very small ones, and it's the people with such uses that are pissed off with NTFS - I'm not sure that can be classed as a "real problem".
      Any security considerations can be ignored since if you took those seriously you wouldn't be advertising something even worse in that respect than plain 20 year old FTP.

    14. 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."
    15. Re:Btrfs by NotBorg · · Score: 3, Informative

      It didn't happen in Fedora 16 as once planned but they're apparently going to make a go of it in Fedora 17: http://www.h-online.com/open/news/item/Btrfs-and-new-file-system-structure-agreed-for-Fedora-17-1389851.html

      Tick tick tick...

      --
      I want this account deleted.
  2. Popcorn loaded, commence fanatical BS... by inflex · · Score: 4, Insightful

    Waiting to see the usual fanatical wars over filesystems... people calling for the death of the EXT3/4 system.

    Personally the whole fanatical thing seems a bit silly - who'd have ever thought that people would lynch each other over having different options for different purposes/tasks, the very core of the whole idea of what we do and strive for. I'm fine with ext4, thanks :)

    1. Re:Popcorn loaded, commence fanatical BS... by martin-boundary · · Score: 4, Funny

      Personally the whole fanatical thing seems a bit silly

      That's not silly! There are two reasons for silliness. Surprise and fear. Fear and surprise... and ruthless efficiency. There are *three* reasons for silliness, these being fear, surprise, and ruthless efficiency... and an almost fanatical devotion to the Pope. *Amongst* the reasons for silliness are such elements as fear, surprise, ruthless efficiency and ... Ok, you're right, fanatical is silly after all.

    2. Re:Popcorn loaded, commence fanatical BS... by DarkOx · · Score: 4, Insightful

      Then what you should do is change you shell so rm is a functIon that moves stuff to the "trash" rather than compromise the on disk format of the file system so an operation "unlink" which is supposed to be destructive can be undone. Solve the problem in the correct place.

      --
      Repeal the 17th Amendment TODAY! Also Please Read http://www.gnu.org/philosophy/right-to-read.html
    3. Re:Popcorn loaded, commence fanatical BS... by MichaelSmith · · Score: 4, Funny

      I want a computer which lets me unsee certain image files.

  3. Good stuff! by ickleberry · · Score: 5, Funny

    I never did like the number "3.1" for some reason

    1. Re:Good stuff! by Nursie · · Score: 5, Funny

      Maybe it's because we all know what comes next - 3.11, Linux for workgroups and then the dreaded Linux 95!

  4. Re:Wow by wbr1 · · Score: 3, Funny

    yep you're right.. no hair, no brains, no memory, no women.. life sucks!

    --
    Silence is a state of mime.
  5. Re:Wow by rubycodez · · Score: 3, Funny

    I definitely still like women, I just can't remember why....

  6. rm -i by steveha · · Score: 5, Insightful

    I used to alias "rm" as "rm -i".

    Then, one day, I was using someone else's computer. I used "rm" with the expectation that it would prompt me, but this person never bothered to set it up that way, and I had the fearful experience of worrying whether it was deleting too much. I hadn't been too careless that time, but it got me thinking. It's dangerous to use "rm" when I really mean "rm -i"; habits are strong things.

    So I made a change that I still use. I now alias "r" as "rm -i". "r" by itself does not have default behavior on most computers. Now if I absent-mindedly type "r *.txt" on someone else's computer, I get "r: command not found" and I edit the command to say "rm -i".

    I suppose I should have used "rmi" or something like that, just in case I am a guest somewhere that "r" was aliased to something crazy. In practice, it hasn't been a problem. I use more aliases than most people seem to; they seem to be content with the defaults. I seem to be the only one I know who likes one-letter aliases.

    Hmm, I guess I might accidentally run the R statistics package someday?

    steveha

    --
    lf(1): it's like ls(1) but sorts filenames by extension, tersely
    1. Re:rm -i by dotancohen · · Score: 4, Funny

      It's dangerous to use "rm" when I really mean "rm -i"; habits are strong things.

      Especially muscle-memory habits.:wq

      --
      It is dangerous to be right when the government is wrong.
  7. Re:Linux "fine security record" in 2011 (lol, NOT) by Ginger+Unicorn · · Score: 4, Funny

    the fools... if only they'd used HOSTS FILES

    --
    (1.21 gigawatts) / (88 miles per hour) = 30 757 874 newtons