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

Re:Btrfs

[francium de neobie]

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

Re:Btrfs

[0123456]

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.

Re:Popcorn loaded, commence fanatical BS...

[Anonymous Coward]

One workaround we did on our server over a decade ago was to hardlink basically everything to /shadow

Entries in /shadow went through periodic timed deletes, but that avoided irreparable stupidity.

Re:Btrfs

[subreality]

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

Re:Btrfs

[dbIII]

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.

Re:Btrfs

[NotBorg]

It didn't happen in Fedora 16 as once planned [slashdot.org] 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 [h-online.com]

Tick tick tick...