Become a fan of Slashdot on Facebook


Forgot your password?
GNU is Not Unix Open Source Operating Systems Upgrades Linux

Linux 3.4 Released 385

Posted by timothy
from the latest-in-a-long-long-run dept.
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."
This discussion has been archived. No new comments can be posted.

Linux 3.4 Released

Comments Filter:
  • by Baloroth (2370816) on Sunday May 20, 2012 @09:50PM (#40060827)

    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. It's basically a non-Oracle-owned version of ZFS, if you know what that is.

  • by Tacticus.v1 (1102137) on Sunday May 20, 2012 @09:53PM (#40060839)

    well comparing it to lvm ignores a significant amount of what btrfs is
    you would compare it with the entire stack
    mdadm + lvm +ext 3/4

    btrfs gets you:
    Checksums on data
    mirrored metadata on a single disk
    lots of flexibility (online resizing and reshaping(single disk to raid 1 to 0 to single disk (or some variant of it) ( additionally raid5/6 like systems are coming)
    easy striping and mirroring across different sized disks
    and probably more go check []

  • Re:Yes, 3.4 BUT... (Score:4, Informative)

    by Anonymous Coward on Sunday May 20, 2012 @09:57PM (#40060861)
    Yes! In the last RC! I'm not having that problem any more at all and 3.4 is rock solid on my systems.
  • Re:yes but... (Score:5, Informative)

    by Clarious (1177725) on Sunday May 20, 2012 @10:11PM (#40060925)

    It's a common FUD. Nowaday Linux audio works just fine, PulseAudio as a sound server (mixer) and ALSA to talk to the hardware, the rest (OpenAL, gstreamer, OSS, ESD) are either obsolete or totally different stuff unessential to audio playback. Earlier problems related to closed source softwares (Flash, Skype) or badly written HW drivers are mostly fixed.

  • by Clarious (1177725) on Sunday May 20, 2012 @10:15PM (#40060941)

    "Another" audio subsytem? Today standard is PulseAudio on ALSA, and that it has been like that for at least 4 years. Before ALSA there was OSS but Linux developers disagree with how OSS do the sound mixing and resampling in kernel space (for better latency, they said) and OSS went closed source for awhile. PulseAudio is an effort to unite all the sound server/mixer (ESD from GNOME, aRTs from KDE or ALSA's own dmix) plus some nifty features like better battery life (less wake ups per second).
    Update your FUD once in awhile, please.

  • by Anonymous Coward on Sunday May 20, 2012 @10:17PM (#40060951)

    The Pulse/Jack difference isn't power consumption, it's intended use.

    Pulse provides a simple API for just making noise.
    Jack provides a low-latency API (like you said) for the purposes for music creation and other things that require true low latency audio (and no, that doesn't include games) with a significant trade-off in complexity.

  • by Myria (562655) on Sunday May 20, 2012 @10:18PM (#40060955)

    The new x86-64 ABI with 32-bit pointers is cool because it allows you to get the architecture improvements of x86-64, such as extra registers and RIP-relative addressing, without increasing memory usage substantially due to larger data structures. Also, 64-bit operations will just use the 64-bit registers. The vast majority of programs simply do not need the extra address space.

    One reason that this ABI works so well is that the majority of the x86-64 instruction set uses 32-bit operations. Some operations involving pointers can be done in one instruction without using a temporary register to load a 64-bit constant.

    Windows actually also can support this, in theory, but you're on your own in trying to communicate with the Win32 API. The linker option /LARGEADRESSAWARE:NO causes the NT kernel to limit your program's address space to 2^31 bytes.

  • by Anonymous Coward on Sunday May 20, 2012 @10:23PM (#40060973)

    Actually, ironically Oracle "owns" btrfs! But it is Open Source.

  • by Tacticus.v1 (1102137) on Sunday May 20, 2012 @11:42PM (#40061347)

    GPL for ever.

    early in the development of BTRFS commits were sourced from vocal and stubborn devs that would protect it from being re-licensed source: []

  • by Jonner (189691) on Sunday May 20, 2012 @11:51PM (#40061383)

    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. It's basically a non-Oracle-owned version of ZFS, if you know what that is.

    Checksumming is useful to anyone who doesn't like corrupt data. Transparent compression is useful to anyone who likes to fit more stuff on their drives and access it faster. Btrfs is technically superior to ZFS though currently less mature. For better or worse, Btrfs is largely developed by Oracle employees so they do own part of it. Oracle could simply stop paying people to develop it but they can't take it away from Linux. Both ZFS and and Btrfs are available under Free and Open Source licenses though the licenses are are not compatible which is the primary reason ZFS cannot be included as part of Linux.

  • by Tacticus.v1 (1102137) on Monday May 21, 2012 @12:08AM (#40061473)

    >like RAID support that doesn't cover RAID5
    Is on the way targeted for 3.5 (was held for the fast offline check code)
    >no online file system check
    btrfs scrub start /blah

  • GNU? (Score:5, Informative)

    by unixisc (2429386) on Monday May 21, 2012 @12:28AM (#40061569)
    Why is the GNU logo the one that marks this story, when it's specifically about the Linux kernel, and not GNU userland? Among the keywords, GNU shouldn't even be there for this story, and the logo for this story should have just been the penguin logo.
  • by shaitand (626655) on Monday May 21, 2012 @12:34AM (#40061607) Journal

    "I'd say too conservative, if they were only updating the third digit every few months."

    I beg to differ. This is the kernel not some userland app or even a daemon. Stable releases are supposed to be reliable enough to trust with billions of dollars in data flow and human life support systems on the day of release.

  • by Anonymous Coward on Monday May 21, 2012 @02:26AM (#40062035)

    Start Pulseaudio? Never even heard of that. On windows I just chose the recording source Stereo Mix. Why does linux make it difficult?

    Starting from Windows 7 Microsoft has hidden the Stereo Mix option (due to pressure from Big Media?), so it's not that easy anymore.

  • by petermgreen (876956) <<plugwash> <at> <>> on Monday May 21, 2012 @05:19AM (#40062641) Homepage

    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.

    The problem with conventional raid is it has no way of knowing which redundant copy of the information is correct and indeed it may well end up overwriting the correct copy with the bad copy during a resync. So it protects against drives that fail but it doesn't protect against drives that quietly return bad data.

    In theory you could implement a raid layer with strong checksums so it knew which copy was bad, but the problem then becomes where to put those checksums (without creating a load of extra seeks).

    By implementing raid techniques as part of the filesystem the checksums can be stored with the existing metadata. Implementing raid as part of the filesystem also allows different redundancy policies to be applied to different data.

  • by KiloByte (825081) on Monday May 21, 2012 @06:33AM (#40062895)

    Yes, there is a massive speed difference. Unpacking a particular tarball takes 10 seconds on btrfs, 124 seconds on ext4.

    The problem is with certain broken programs that fsync after every single write. But that's a problem with those programs, not btrfs. The words "fsync" and "performance" don't belong in the same sentence. fsync may be legitimately uses when durability is actually needed, but in almost all use cases the programs want only consistency.

    An example: there's a file where a transaction consists of appending a few bytes to the file then updating something in the header. Let's say it's four bytes in both writes. The program can handle power loss between transactions or if it happens between the first write and a header update, but not any other reordering. The disk in question has 100MB linear speed and 10ms seek time. Even with some kind of a barrier syscall, ext4 would need to alternate writes anyway, plus it needs to write to the journal and inode. This gives you a whooping 25 transaction per second. btrfs and log-structured filesystems with atomic flushes get 25M instead (assuming infinitely fast CPU).

    The primary offender here is Firefox which fsyncs all the time. This not only slows down writes but also causes insane fragmentation. The data it protects is not vital in the first place (mostly browsing history), and if it used sqlite in WAL mode on relevant platforms instead it wouldn't have to fsync for consistency almost at all.

The human mind ordinarily operates at only ten percent of its capacity -- the rest is overhead for the operating system.