Slashdot Mirror
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."
It is something the FS should handle. The "Just fix the program," is a bad answer because while maybe one could change Firefox, you'll find another program that can't be changed because the nature of what it does requires many syncs.
The low level systems should be robustly written to do what apps need, they shouldn't be telling apps "You can't do that."
One really nice thing about ext4 vs. previous versions is the dreaded 20 minute fsck every 40th or so boot only takes about 10-20 seconds now.
The soylentnews experiment has been a dismal failure.
What is the rationale for moving up to 3.4 so soon?
Obviously big tech companies, as well as the Mozilla Foundation play the versioning game aggressively, but the Linux kernel always had a reputation of being conservative.
Sync (or fsync) is the way to ensure that files are committed to disk and not just cached somewhere. This is a precondition for reliable "restore session" and similar functionality. However, application developers cannot rely on the OS to sync data in the background, because e.g. on a laptop where frequent disk access is both expensive (battery life) and risky (physical motion), the OS will cache as much as possible. If FF did not sync, the OS might delay writes for hours, which means a computer crash leads to lost hours of browsing history for the user. It doesn't sound like a big deal, but I can tell you that it is infuriating as a user to see a browser say, "whoops, I lost your tabbed windows, hope you weren't using the WWW for anything important!". Not having looked at the source myself, I don't know if it's possible to optimize FF's sync behavior; but I do know that it's impossible to eliminate it.
no because if you lose a disk in a striped array you lose everything. (perhaps you are thinking raid1 in which case it protects you from disk failure but does not provide backups)
but soon they will be working on a btrfs send\receive system so you would be able to take snapshots and push to another disk
IMO there are a number of different failure states that you must cater for.
1. Human failures (the oh shit I deleted something): a snap shot capable file system helps protect you from these (not perfect but fairly good)
2. Hardware failures (disks are dead): traditional backup systems work here (or btrfs\zfs send\receive) disk failures can have reduced impact due to mirroring your data (or strip plus parity) checksums and COW help defend against silent failure
3. Software failures (the OS is hosed, partition table is dead): traditional backup systems work here (or btrfs\zfs send\receive) (though COW file systems and marking shit read-only helps)
4. oh shit the building burnt down: Hope you do offsite backups
BTRFS helps in the first 3 by bringing awesome features to the table (snapshots, COW(so you can walk back up the tree to recover) and mirroring your data on multiple disks) but is only something that can supplement a backup system not replace it at all
only a good backup system helps in the 4th situation.
"Journaling makes sense for servers; not so much for personal boxes."
I'm sorry my friend but you must be insane. I don't go uncleanly powering off my boxes intentionally but it still happens a couple times over the course of a month for various reasons (power flickers and the like). In my experience ext2 will fsck its way back to functionality 4 or 5 times tops before it won't fix or the data lost in the fixing is something critical.
Linux was a fun toy and nothing more before ext3 because ext2 is the most destructible filesystem on earth. Don't get me wrong, I played with that toy but that is all it was.
Wow. Am I out of the loop, or what? We're up to ext*4* now? I'm still using (happily) ext2. Yeah, I've heard of btrfs, but why change if what you're using works? Journaling makes sense for servers; not so much for personal boxes.
Yes, you are way behind. Ext3 became part of Linux eleven years ago and added journaling to ext2. Some of us have been using superior journaling file systems like Reiserfs3, XFS, JFS and Reiserfs4 for many years. Journaling is a good idea for all file systems because it allows much stronger metadata and sometimes data consistency guarantees. In other words, though hardware failures and unexpected shutdowns can cause data loss on any file system, journaled ones are more likely to know which data are corrupt and which aren't. Btrfs improves on that by also checksumming everything so no corruption can ever go unnoticed. This is increasingly important as disks get bigger and errors become more likely. Another thing that's perhaps especially nice for desktop and laptop systems is that journeled filesystems can generally be checked for consistency very quickly, meaning you much less oftend need to do a lengthy fsck.
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.
How do you make a file system out of parts, though? e.g. how do you tackle, say, snapshotting, or online volume resizing, efficiently onto an existing FS that was not designed with those features in mind?
The problem is not the memory but the CPU cache. No reason to clog it with bloated 64 bits pointers when 32 bits pointers will do.
Mada mada dane.
It's a common FUD. Nowaday Linux audio works just fine
Well, sometimes getting audio to work is beyond the control of the Linux kernel. If the system has integrated audio on the motherboard (e.g. a laptop) the ACPI DSDT (Differentiated System Description Table) supplied by the manufacturer in the ROM can instruct the hardware to behave differently under different operating systems, or provide different descriptions of the hardware (e.g. audio inputs and outputs) to different operating systems. That's why it's common to have little glitches in Linux audio, like not having the right mixer controls.
The DSDT is written in a language called ACPI Source Language (ASL). Intel and Microsoft both provide compilers for ASL, but the MS compiler accepts buggy, non-compliant DSDTs. Since for some vendors (Toshiba) the job is considered done when stuff works under the current version of windows, they ship their laptops with DSDTs that won't work under anything but Windows and might not work in future versions of Windows.
Since the kernel writers have no way of knowing what specific hardware is in your machine except what your machine tells the kernel, they can't fix this. It's entirely the manufacturer's fault, although users blame Linux because everything works in Windows. Getting stuff working isn't exactly a nightmare, but it's beyond most users' capability. You extract the DSDT from ROM, decompile it, fix the bugy ASL, compile it, then put the fixed DSDT in your initramfs (remembering to do this again every time you install a new kernel). Sometimes using a linux boot parameter to masquerade as Windows to the hardware works.
So to recap: the Linux audio system may be fine, the hardware drivers may be fine, but if the manufacturer fails to supply a correct description of what the hardware contains to the Linux kernel, audio might not work.
Disclaimer -- this information is a few years out of date, as I've stopped using Toshiba laptops and use Asus instead. However I'm fairly sure it still exists with certain manufacturer's laptops, which have worked flawlessly for me under Linux.
Post may contain irony: discontinue use if experiencing mood swings, nausea or elevated blood pressure.