Linux 3.4 Released

jrepin writes with news of today's release (here's Linus's announcement) of Linux 3.4: "This release includes several Btrfs updates: metadata blocks bigger than 4KB, much better metadata performance, better error handling and better recovery tools. There are other features: a new X32 ABI which allows to run in 64 bit mode with 32 bit pointers; several updates to the GPU drivers: early modesetting of Nvidia Geforce 600 'Kepler', support of AMD RadeonHD 7xxx and AMD Trinity APU series, and support of Intel Medfield graphics; support of x86 cpu driver autoprobing, a device-mapper target that stores cryptographic hashes of blocks to check for intrusions, another target to use external read-only devices as origin source of a thin provisioned LVM volume, several perf improvements such as GTK2 report GUI and a new 'Yama' security module."

Comments

btrfs needed the work

[bzipitidoo]

I tried btrfs, and ended up going back to ext4. Hoped btrfs might be a good choice for a small hard drive, and it is-- it uses space more efficiently. But it's not a good choice for a slow hard drive or the obsolete computer that the small size goes with.

Firefox ran especially poorly on btrfs. I was told this is because Firefox does lots of syncs, and btrfs had very poor performance on syncs. Maybe this improvement in performance on metadata is just the thing to fix that?

Re:btrfs needed the work

[Gothmolly]

Fix Firefox? Why does it "need" to do a lot of syncs?

Re:btrfs needed the work

[isopropanol]

Also, put your firefox browser.cache.disk.parent_directory on tmpfs on single user systems.

Re:btrfs needed the work

[arth1]

Checksumming, built-in RAID support, snapshotting, transparent compression, online volume resizing, et alia. Basically, a lot of stuff that is very interesting at the enterprise level and to serious nerds who like to do strange things with their volume management, but nothing particularly important to the average user.

This is known as featuritis, and is anathema to the Unix way, where each part should do just one thing, and do it extremely well.
In my opinion, it's not interesting for enterprise because you get mediocre features, like RAID support that doesn't cover RAID5, no online file system check, not all operations being atomic, and xattrs stored separate from the inode, making it sloooow with SELinux (and presumably Samba with windows per-file security support).

It's basically a non-Oracle-owned version of ZFS, if you know what that is.

Er. While some might consider Btrfs a poor man's version of ZFS, both are Oracle owned.
The main difference is that ZFS was designed from the ground up, while Btrfs builds largely on ext2, with a few reiserfs ideas and the kitchen sink thrown in.

But it will be interesting to see which COW file system will become most popular. My money is on NILFS, if nothing else because Oracle gives people a bad taste in their mouths, but ICBW.

For non-COW enterprise, I'll stick with XFS and JFS for now.

Re:btrfs needed the work

[waveclaw]

This is known as featuritis, and is anathema to the Unix way, where each part should do just one thing, and do it extremely well.

All btrfs does is manage a B-tree filesystem. All grep does is apply a regular expression to a string.

However, the UNIX way is not always even a good thing.

It is also the UNIX way to duplicate a single thing a hundred times for each little feature variation (grep, egrep, fgrep, most of Perl.) That can also be unpleasant for the end user (xterm, gnome-terminal, kterm, gterm, LXterm, terminator, editing Perl.) Great for a system administrator who is expert at their particular tool and only that tool but horrible for everyone else.

That's without getting into the UNIX Way for (lack of) documentation. Or how that one thing is so often the wrong thing so it doesn't matter how well that one tool does it.

btrfs is famously called a rampant layering violation. The roll-up of filesystem-management features in one place actually lets the developers avoid duplicating code (which may actually be about as non-UNIXy as you can get in some ways.) Code that now knows about certain information normally hidden from it can do things differently. This is sometimes better (rapid mkfs) or worse (fsck tool was apparently hard to write.)

In my opinion, it's not interesting for enterprise because you get mediocre features, like RAID support that doesn't cover RAID5, no online file system check

In my opinion, if your enterprise system depends on fsck and not good backups then you don't have an enterprise system. Yes, xfs_repair can do amazing things to mostly trashed disks. But one day your data will take a good fscking where only surviving copy will be the backup copy.

RAID5 implementation from Intel is in the tree, but waiting until after the fsck is done. And btrfsck has been around since, oh, February? And the btrfs-progs you should be using with the 3.4 kernel have btrfsctl included?

I was hoping the RAID5 code was going to land in 3.4, actually. Reading the pull request says that RAID5/6 should be in 3.5. Oh, well.

Of course, if you have enough money to buy an "enterprise" solution, your SAN/NAS should do the thing doing RAID for you anyway.

My major criticism of btrfs is the horrid sync performance. Hosting virtual machines tends to require lots of small writes to disk that make btrfs incredibly non-performant.

btrfs has many sexy, sexy features for a world of enterprise SAN storage and virtual machine hosting. It has thin disks, balanced meta-data, flexible storage, SSD optimized modes, multiple snapshot layers, checksummed data on disk. All of this just because it does one thing and does it well: manage a B-Tree database.

Today it's is just not there in the I/O department, sadly. Probably good for inside the virtual machine guests, though. Only testing will tell.

My money is on NILFS, if nothing else because Oracle gives people a bad taste in their mouths, but ICBW.

Wow, speaking of niche file systems. Log file systems have quite a long history. Of horrible performance and fragmentation. But if we all end up on SSDs, that won't matter. Underlying any file system you put on it, an SSD implements storage as a circular log and performance is fast enough to not depend on huge uncommitted disk caches.

Re:Most programs don't need a 64-bit address space

[Mr Z]

Yes, but so what? A system that supports x32 should also support x86-64. So, if you're relying on ASLR for security purposes, compile those sensitive apps as x86-64.

Granted, the potential attack surface grows as you consider larger and larger threats. For example, a GCC compiled as x32 makes a fair bit of sense. What about Open/Libre Office? Well, that depends on if you open untrusted documents that might try to exploit OOo / LO. (Odds seem pretty low, though.) And what about Firefox? Far less to trust on the web...

So, at some point, you have to make a tradeoff between the marginal benefit of increased performance/better memory footprint in x32 mode vs. increased security against certain overflow attacks that ASLR offers. For most people in most situations, the former likely wins for anything with a decent memory footprint. For people building hardened Internet-facing servers, the latter probably wins.

Re:Most programs don't need a 64-bit address space

[smash]

You've seen the prices of 16+ GB of ram recently, right? Shaving a few bytes here and there in your CODE (not in your data, which is far and away larger) by writing for 32 bit pointer use in the days where 16GB of ram is under a hundred bucks is retarded.

Re:yes but...

[shutdown -p now]

It's a common FUD. Nowaday Linux audio works just fine

My desktop still can't auto-switch between speakers and headphones when the latter are plugged in and out, on any distro (it just plays sound through both of them). The relevant bugs have been in Ubuntu database for years now.