Linux 3.2 Has Been Released 271
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."
Btrfs (Score:5, Interesting)
Re:Btrfs (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.
Re:Btrfs (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.
Re: (Score:3)
This.
Don't know about this new version, but I tried btrfs on ubuntu a few months ago, on a box I use mostly with photo and video editing software. It was slow to the point of being completely unusable. Specially for non destructive photo editing, where the software creates and modifies (replaces) small files with metadata for each action you perform on the images. Have being using ext4 since then, and everything is ok.
Re:Btrfs (Score:5, Funny)
In other words, "better you than me."
Re: (Score:3)
What part of "better you than me." sounded to you like he was bitter? I read it as quite humorous.
Re: (Score:3)
Depends are we talking about the ordinary 'user' here or the ordinary "user of btrfs", which is pretty extraordinary when compared with the population of general PC users. A PRENDEND bug report that I would think might be useful would be:
I have ~?TB volume composed of three drives each with a single partition of sizes X, Y, and Z. I have noticed that after I remove a snapshot really big files, in my case some VM images of size T, get corrupted, in that they seem to contain old data that would have been i
Re: (Score:2)
Re:Btrfs (Score:5, Informative)
Re: (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.
Re:Btrfs (Score:5, Funny)
Re: (Score:2)
Re:Btrfs (Score:5, 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.
Re:Btrfs (Score:4, 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.
Re:Btrfs (Score:4, Informative)
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...
Re:Linux "fine security record" in 2011 (lol, NOT) (Score:5, Funny)
Re: (Score:3, Insightful)
even Windows hasn't had such issues in over a goddamn decade.
Windows is not a filesystem. And that's only relevant if NTFS has the same features as ZFS: Ext doesn't have the same issues either.
Re: (Score:3)
Windows may not be a filesystem, but it only ships with one sane choice of general-purpose filesystem, and that choice is NTFS. Therefore, Windows == NTFS for the purpose of a discussion in the context of filesystems. Not literally, but plainly for all intents and purposes.
(Counterarguments about Windows also shipping with crappy filesystem(s) needn't apply, since Linux/*BSD ships with those too. And HPFS, the only other then-viable choice from IBM/MSFT, and perhaps the only o
Re:Btrfs (Score:5, 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.)
Re:Btrfs (Score:5, Informative)
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: (Score:3)
Right. So I shouldn't store a massive many-user maildir on NTFS, and I shouldn't keep huge single-file datasets there either. Got it.
But those are corner-cases, of which I'm sure there are some that ext2/3/4 falls down on as well: Ain't nothin' perfect.
For common use, where there often aren't more than a few hundred smallish files in a directory or any one file exceeding a few gigabytes: What's the problem?
And even then: If I push the envelope with NTFS and do those horrible, horrible things with it:
Re: (Score:2)
Which is why I wrote that people are pissed off with it but I don't know if it's a real problem. Some other file systems have been tweaked specificly for those corner cases anyway, and that's where I don't use NTFS if I can help it. Sometimes I can't help it and users complain until I move the stuff off the local drive onto a network drive with a different file system that even if it physically has a lower data access speed than local drives gets the job done more quickly.
Re: (Score:3)
Well, the file system should be loosened so it can move about the whole partition. Otherwise you lose space.
Besides, the defragmentation engine in NT, which was licensed from the folks who make Diskeeper, is extremely robust. I'm as much of a critic of Microsoft as they come; my opinion of Microsoft borders on hatred. But I've got nothing bad to say about NTFS other than to comment the need for constant defragging is a pain. But as far as robustness, in almost 20 years, I can honestly say I've almost ne
Re: (Score:2)
Yes that can be a real problem for people with lots of files. Years ago I did programming on Windows (thank god anymore) there were literally thousands of files in my home dir.
The problem was there was this threshold of number of files which if you crossed it brought the FS to a crawl. I could notice that by deleting a few files then suddenly performance was back (except for the defragmentation induced one) once you crossed this boundary performance were back to a crawl.
Add to that the windows inherent pess
Re: (Score:2)
Actually, AC: I think I know what I'm "probably thinking of," and FAT (in any incarnation) isn't it.
Re:Btrfs (Score:5, Insightful)
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.
Re:Btrfs (Score:5, Insightful)
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?
Re: (Score:2)
For many filesystems, failing a fcsk means reaching for the format tools and the last (verified) backup. You are backing up everything, right?
So... you just killed your own rant by saying in the end "you should really have an fsck for an experimental filesystem so you know when it failed?"
Re: (Score:2)
my favorite part of this Microsoft FUD is
Phishers/Spammers FAVOR attacking LAMP
Like there is another web server stack on the Internet.
Re:Btrfs (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. :)
Re: (Score:2)
I don't think it's exposed yet, but hey, that's what the future is for.
I suspect there are plenty of userspace operations that need ordering but that don't actually need the performance hit of guaranteed durability.
Re: (Score:2)
Nope. This is with old fashioned spinning media.
It's a known problem. Google "btrfs dpkg"... it's just a question of which side wants to tackle it first.
Re: (Score:2)
Re: (Score:2)
Ok, but the tree can go for a pout in a corner and you'll just get kernel panics on restart - this happened to me. No power outage, just a normal reboot and poof... it was repairable using the btrfs-zero-log tool.... but it wasn't a pleasant 10 minutes while I was thinking.. "What did I do, why why why did I think it was good to try out btrfs?" Of course once I got it booting again, I kept right on using btrfs :-) I love the snapshot thing... very useful
Re: (Score:2)
I have herd a number of recommend that for a personal desktop you could use it for non user files (ext for home and boot and btrfs for ever thing else).
The idea being that if something goes wrong you can just reinstall (30 min for me if I cache my updates).
You just have weigh up the risk and minimize the damage. Unless you are using it with something like snapper (fs snapshot and roll back) or a stopwatch you will never know the difference unless it gets corrupted.
Re:Btrfs (Score:4, 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 [fedoraproject.org] 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.
Popcorn loaded, commence fanatical BS... (Score:5, 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 :)
Re: (Score:3, Interesting)
I still say we should lynch EXT3/4(even though I use it) due to it's complete /inability/ to undelete files. /never/ manage to accidentally delete files and /always/ have recent backups handy.
Because, as we all know, people
Re: (Score:2)
People generally only make that mistake once or twice before they become a bit more clued up and invest in a backup option, even on OS's that provide undelete (Windows). Agreeably it doesn't save you when you create and then lose a file between the backup times.
It might be a nice option to have, so long as it doesn't inhibit/hinder the existing system. I think an entirely different filesystem would be a better option, something with inbuilt versioning/history.
Re:Popcorn loaded, commence fanatical BS... (Score:5, 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.
Re: (Score:3)
Agreed. I alias rm to 'rm -i' so that I have to at least type -f if I really mean it :)
rm -i (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
Re: (Score:2)
I now alias "r" as "rm -i". "r" by itself does not have default behavior on most computers.
I have a friend that used to alias "r" for "rm" and "e" for "emacs". Once he had to restore his thesis from day or two old backup he stopped doing that :)
Re:rm -i (Score:5, Funny)
It's dangerous to use "rm" when I really mean "rm -i"; habits are strong things.
Especially muscle-memory habits.:wq
Re: (Score:2)
Especially muscle-memory habits.:wq
The number of times I've typed that into notepad....
Re: (Score:3)
Set HISTCONTROL to ignorespace. Then bash will not save any commands that begin with a space.
Re: (Score:2)
Agreed. I alias rm to 'rm -i' so that I have to at least type -f if I really mean it :)
...and then, you get into habit of using -f when you're sure you want to delete, and soon you get the habit of using -f with rm. Which, needless to say, is pretty dangerous habit to have.
Re: (Score:2)
LOL, yes I'm aware of that danger. Unless I'm wiping out an entire folder recursively or something, I don't bother with the -f flag. FreeBSD has a -I now (capital i) which only prompts you if more than 3 files are going to be deleted. This isn't available on Mac, but I think Linux has it as well.
Re: (Score:2)
If thats a problem then just replace the rm command with something less final.
Re: (Score:2, Informative)
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: (Score:2)
Re:Popcorn loaded, commence fanatical BS... (Score:5, Funny)
I want a computer which lets me unsee certain image files.
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
Three, only works with EXT2. Which it works perfectly well on. But nothing later.
Y'know, tossing a copy of the deleted inode entries(in a different format) somewhere else on disk, to be used only when space runs low would solve all of the many, many topics out there about people losing data due to a mistake etc. Perhaps an option that could easily be disabled for the tech-savvy(See: the number of people who use the stock desktop on, e.g. ubuntu, even when a seperate desktop is available easily via apt-get).
Re: (Score:3)
Re: (Score:2)
I don't know about you, but my browser keeps a history of which files I've downloaded.
But if you know so little about the PDF that you can't find it again, then it obviously wasn't that important to you.
Re: (Score:3)
Re: (Score:2)
That's really anything to do with the file system anyway. Recycle Bin isn't a feature of NTFS/FAT, it's a feature of Windows, and there's plenty of things available in Linux that do the same thing for EXT3/4 and I assume work fine for any natively supported FS. It's not like it's magically "undeleting" files, it just moves them to some other location, which the OS may choose to handle differently to normal directories.
Even after you remove it from there, the data's still on the disk, until that part of the
Re: (Score:2)
.Trash-1001 (Score:2)
Versus something like a "I'm 'deleted'" bit on the file you lose a bit of space but don't have to move the file to "delete" it.
How is that different from moving the directory entries for loads of files into the "I'm deleted" folder, as has been done on the Mac since 1991 and on Windows since 1995? None of the data gets moved; the inodes (or whatever FAT, HFS, and NTFS call them) stay in the same place.
None of this as you get on a windows system deleting files on a remote system being permanent and not making it to your recycle bin etc
I seem to remember at least some versions of the Nautilus file manager creating an invisible ".Trash-1001" folder on an SMB share and then "deleting" files by moving them into that folder.
Re: (Score:2)
I put everything that I use or create for school in a version control system, bzr in this case. Saving a file is just a commit away.
Re: (Score:2)
I've never lost data on ext3 without a hardware failure. Yeah, ext4 sucked before they stopped saying 'the users are wrong' and made the filesystem non-braindead, but I haven't lost any data since.
As for fsck, I remember ext4 would regularly fsck at boot before they fixed it, so I have a hard time believing that it's only just gained that capability?
Re:Popcorn loaded, commence fanatical BS... (Score:5, Funny)
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.
Re: (Score:2)
I tried btrfs when I recently installed ubuntu on a new netbook. It was taking 15 minutes to fsck the disk on startup. This file system seems a long way from being used by default.
Re: (Score:2)
Where'd you get fsck for btrfs?
Re: (Score:2)
Thats a good question. I thought it was running fsck because it took forever to mount on startup. But maybe the mount was slow for other reasons.
Re: (Score:2)
I bet you use emacs
Re: (Score:2)
tsk.... notepad.exe ftw! ;)
( okay, I use vim )
Re: (Score:3)
Ext4's only major flaw is that it does not have snapshots. That can be fixed, actually.
Re: (Score:3)
Why? The last time I had a look at BTRFs it was at least in a VM significantly slower than EXT4.
This was noticable at every corner of the OS.
I would not use it for production, at least not in a scenario where I/O performance matters, but the features are neat. I love
the snapshotting. But my personal guess is it is at least a year away from being a viable EXT4 replacement.
Re: (Score:2)
Do you remember when Ext4 came out? A bunch of people had data loss after system crashes. It was explained that this was intentional behavior, as specified by the POSIX standard, and the safer behavior of Ext3 was unintentional. Of course, no one cares when they're looking at a tree full of zero byte files, so the file system fanatics rose hell and got them to patch Ext4. So file system fanatics have their uses.
Good stuff! (Score:5, Funny)
Re:Good stuff! (Score:5, Funny)
Maybe it's because we all know what comes next - 3.11, Linux for workgroups and then the dreaded Linux 95!
Re: (Score:2)
Actually with Linux' numbering scheme, we will probably get to 3.11, after 3.10 and 3.9. You just have to wait another couple years for the punchline.
Re: (Score:2)
I installed Slackware '96 about 15 years ago. It was 1 better than that other "operating system" that came out about the same time.
--Joe
Re: (Score:2)
Re: (Score:2)
What 4?
Actually, it's WATFOR, and the next iteration will be WATFIV.
Wow (Score:3)
Re: Wow (Score:2)
Carol Marcus?
I'd much rather take her daughter, Samantha Mathis:
http://celebritynet.cz/photos/0/b/5/0b54be45ee551a354ab31998d2f1a689.jpg [celebritynet.cz]
http://www.moviespad.com/photos/samantha-mathis-lost-b6bc2.jpg [moviespad.com]
http://www.allcelebspics.com/wp-content/gallery/samantha-mathis/Samantha%20Mathis_1295188973516939.jpg [allcelebspics.com]
Re:Wow (Score:4, Funny)
Re:Wow (Score:4, Funny)
Re: (Score:2)
Version number MADNESS (Score:2, Funny)
Wake me when we get to 7.1. At this rate it ought to be sometime this fall.
Re: (Score:2)
Re: (Score:2)
Sort of. The actual version number of java is still 1.6, 1.7, etc, but it's always referred to (by Oracle officially and by people generally) as Java 6, Java 7, etc. I'm not entirely sure when they did that, but the guy sat at the desk next to me has a "Java 2" book. I guess they got to 1.2 and wanted to make it sound big, but didn't want to change the version number?
Who knows what they'll do when they hit version 2.0.
Re: (Score:2)
You might be thinking of Emacs.
Past version 1.12 they dropped the 1, hence why they're up to 23.3 now.
Re: (Score:2)
http://en.wikipedia.org/wiki/Solaris_(operating_system)#Version_history
Everybody Clear?
Looks like a really good release (Score:2)
This looks to be a really strong, likely to be long-supported, kernel. Providing that the Googleification of the TCP stack doesn't hurt local 1-10Gbps performance, that is. Have a care if you do your own kernel compiles... the whole Ethernet driver subsystem has been merged together.
ext4 blocks? (Score:2)
Now that it's stable and used, is it safe to extend it with such a powerful "block" option, and risk a potential regression?
Re: (Score:2)
IIRC weren't they not using ext4 because it was missing some crucial features like fsck support?
Good: x86 PC will read my NAS 16k ext3 :) (Score:2)
Very good news: standard Linux box will read my NAS' drives without using specific package and user space FS tools.
The NAS has a Debian Sparc system with ext3 16k blocks. Recovering the data when the NAS is dead (or has problems) is always a concern. Knowing I will be able to start a PC with Linux Live CD and plug those disks to recover my data is a relief.
I hope this NAS will also accept USB drives with ext3 16k FS made by x86 Linux (it doesn' read ext3 4k FS). I've prepared some with thorough blocks rw
google cache of kernelnewbies (Score:2)
google cache result for kernelnewbies.org/Linux_3.2 [googleusercontent.com]
Re: (Score:3)
A 3.2-rc7 kernel is already in Debian's experimental repository fwiw.
Re: (Score:3, Interesting)
That was Ubuntu, as I recall, and not necessarily the greater kernel community. I'm sure they'd rather play it safe and have a slightly more power hungry but stable system than risk crashing people's systems because OEMs are incompetent and can't report their shit properly.
Re: (Score:2)
No, as I understand it, it is actually in the kernel. I think the problem was found in Ubuntu simply because it's the most popular (?) linux distro.
Re: (Score:2)
This one? http://www.phoronix.com/scan.php/images/www.phoronix.com/scan.php?page=news_item&px=MTAyMjk [phoronix.com]
Wait for 3.3
Re: (Score:2)
But Fedora is more than twice as good already, that would be too elitist.
Re: (Score:2)
Re: (Score:2)