Ext4 Advances As Interim Step To Btrfs 510
Heise.de's Kernel Log has a look at the ext4 filesystem as Linus Torvalds has integrated a large collection of patches for it into the kernel main branch. "This signals that with the next kernel version 2.6.28, the successor to ext3 will finally leave behind its 'hot' development phase." The article notes that ext4 developer Theodore Ts'o (tytso) is in favor of ultimately moving Linux to a modern, "next-generation" file system. His preferred choice is btrfs, and Heise notes an email Ts'o sent to the Linux Kernel Mailing List a week back positioning ext4 as a bridge to btrfs.
Re:Why not ZFS? (Score:5, Insightful)
...and that's it's biggest problem. ZFS duplicates a lot of functionality that belongs outside of a filesystem. All of the above can already be done using any Linux filesystem, so why keep around a second copy of all that code that implements those features for just a single filesystem?
ReiserFS was (is) in a similar situation, where it also duplicates a lot of functionality that doesn't belong in the filesystem. Not only does this make it harder to maintain, but it makes a lot of features filesystem specific that shouldn't be.
Re:BTRFS? REALLY? (Score:5, Insightful)
Why not? It's a good analogy for FOSS after all. Great software, robust and all, but her face...
Re:What I'd like (Score:4, Insightful)
Re:Why not ZFS? (Score:3, Insightful)
A FUSE ZFS guarantees it will never be the "default" filesystem anyway. BTRFS has a good shot at being your / in a couple of years.
Re:Why not ZFS? (Score:5, Insightful)
Also important, he might be more focused due to not being in prison for first degree murder
Re:BTRFS? REALLY? (Score:5, Insightful)
"Couldn't they come up with a better name than "BuTteR FaSe?" I know I can't be the only one who read it like that. Call it anything but that."
I read it as:
BeTteR FileSystem
I guess we'll have to part was :P
Re:Why not ZFS? (Score:5, Insightful)
The things you think belong outside of a filesystem only 'nelong' there because that's what years of narrowminded developing have tought you. Look at it this way: /everything/ related to filestorage is managed by ZFS. What could be more convenient than that? Because of this, ZFS can do things much faster and much more reliable than any combo of LVM with a filesystem. Why chain together tools yourself, and manually think about things you really shouldn't be thinking about, when you can have a good filesystem take care of it for you.
ZFS is easier to maintain, from a users perpective (and that's the job of development, to make usage easier, not ever the other way round).
Re:when ext4 is feature complete it will be the #3 (Score:2, Insightful)
NIH [wikipedia.org]
Re:Why not ZFS? (Score:4, Insightful)
Re:Why not ZFS? (Score:3, Insightful)
The GPL is restrictive as it is /because/ it ensures freedom for users. It is the /developers/ that the GPL bugs.
Bring on the GPL, I say! Boo to Sun for being anti-users.
/Mike
Re:Why not ZFS? (Score:4, Insightful)
Why chain together tools yourself, and manually think about things you really shouldn't be thinking about, when you can have a good filesystem take care of it for you.
Because that's the Unix way - build small components (applications) and chain them together to create something out of the parts. I mean, why have ls and grep when you can have lsgrepsortfind? Really, the point is to have small, easily maintained apps that do 1 thing well than 1 app that does everything possibly well, but more usually poorly as its difficult to maintain and ensure it works properly. Not to mention the bloat when it replicates functionality already provided.
This may not be the best model for a critical component like a filesystem, but on the other hand, reliability of a filesystem is paramount, so keeping it as small as possible is probably a good idea.
Re:Why not ZFS? (Score:1, Insightful)
Look at it this way: /everything/ related to filestorage is managed by ZFS. What could be more convenient than that?
Having it in a layer where it would work with every file system, without needing to reinvent everything again.
Back when there was only fat16, ntfs, ext2 used (Score:1, Insightful)
ext2 beat them all, hands down. Then for GNU Linux came cfs, hpfs, jfs, ext3, xiafs, reiserfs, onto ext4fs, and you know what was still easier to tune and outperformed all others in data retention and speed? You guessed right: ext2. Everything else is slowly becoming convalescent by needing complex database code that only makes stability no better when not a NAS mirror node, and worse is software writers depending on file system constructs through libraries outside ANSI C or worse by abstracting standard IO with said database. Doesn't anyone remember what simple functionality made Linux great, and now the same take it into a dark age of complexity to market their *ise Service route?
Re:Why not ZFS? (Score:3, Insightful)
RAID-Z uses copy-on-write to avoid RAID 5's required read for every non-cached write.
Of course, the very same copy-on-write will also result in massive file fragmentation, carefully smearing your dbf files over the entire platters, making your SAN caches useless. Over time resulting in horrible read performance.
ZFS is certainly a huge improvement for anyone used to ufs and disksuite, but I have to say that using it in the real world it's not all it's cracked up to be. A more layered approach would have made it easier to switch in and out features that turned out to be misfeatures in certain situations.
Mixing together the features of various layers is, imo, no matter how tempting, simply the wrong approach. Proceed further along that road and you get to record based filesystems or even more special-purpose variants. I mean, there are even more optimizations that you can do if you know the _contents_ of the files. But once you go down that road complexity will grow with every possible different situation you need to handle and you end up either with something far too complex or something unsuitable for many cases. Better then to do the best you can without extra knowledge, code special layers for special features, assume nothing, and let the possibly competent admin add appropriate layers for appropriate data.
Re:Back when there was only fat16, ntfs, ext2 used (Score:5, Insightful)
Re:BTRFS? REALLY? (Score:2, Insightful)
More tarty make-up, than actual looks, imo. Looks is a clean intuitive interface the responds quickly. Wobbly window frames and cubic desktops are just lipstick and eyeshadow. i.e. attention-seeking flash. Of course that's what some go for and it's good to be able to apply it if you want it. But I would liken it to real looks.
Re:Why not ZFS? (Score:4, Insightful)
If a filesystem detects errors it is helping me (at least) there. No matter what creates them.
I do not think SSDs will solve storage problems: there will be flaky adapters and other IF chips/firmware, etc.
Re:Back when there was only fat16, ntfs, ext2 used (Score:5, Insightful)
so I think that journalling will become obsolete in some near future.
I bet in 1992 you were still thinking color TV's wouldn't last either . . .
Look, a UPS is a great thing. I run one myself. Heck with more and more people switching to laptops a lot of people are running a "UPS" without even realizing it. The simple fact though is that modern processors and disks are so fast that the minimal speed impact of journaling is barely noticeable. It's certainly not worth giving up over some marginal speed gains.
I mean we're talking about a world where people will give up tons of speed in their computer just to make the WINDOWS WOBBLE when you move them, or to make teddy bears wave at them from the system tray. Do you honestly believe that they're going to risk having their files corrupt on an unexpected power outage for a fraction of a percent increase in meaningful speed?
Re:Back when there was only fat16, ntfs, ext2 used (Score:5, Insightful)
Look at the bottom of the page. That's from 2003. Of kernel 2.6.0. A lot of code changed since then.
I'm not sure what exactly you mean by this. Latency is mostly influenced by the hard disk. And on a desktop the disk shouldn't be a bottleneck anyway.
Except there's lots and lots of those files in a modern Linux system. Config files, icon files, and small libraries for instance. Additionally many files are searched in different paths, making a fast directory search important.
Just as a RAID is not a backup, an UPS isn't a disk journal. One of those days you'll get a long outage, or the power cable will turn out to fit badly into the power supply, have a kernel panic, the UPS won't switch to battery fast enough, etc. And then after several minutes of fsck something important might end up broken.
If the journal causes you a noticeable slowdown you probably aren't a typical user. In typical usage the disk should be mostly idle after boot.
I don't see a point in going forward insanely fast without brakes. I'll take the safety. I have an UPS on every computer, and still have a journalled FS, because there were times when the UPS was of no help. Like yesterday, when I upgraded my laptop's RAM, booted it, and found that with more than 2GB RAM, the BIOS maps the video RAM above 4GB. The video card showed its displeasure with that state of affairs by corrupting the display and locking up. Had no choice but to powercycle the box.
Re:Back when there was only fat16, ntfs, ext2 used (Score:5, Insightful)
Yeah, because systems never kernel panic, or crash for any other reason than power outages... Wake me up after you've been waiting for fsck to finish on your 1TB drive and it's been running for the last 72 hours.
Whether or not you've had a system shutdown uncleanly in the past, you certainly will at some time in the future, so why not just use ext3 and save yourself the headache of a 3 day long fsck?
It's also painfully obvious that you've never worked as a sysadmin before. You try explaining to your manager that the reason why your company's server will take 3 days to come back online is that you wanted to save a few microseconds of latency when users were accessing files...
Re:Back when there was only fat16, ntfs, ext2 used (Score:1, Insightful)
UPS is nice and so on, but how do you prevent crashes introduced by producers like ATI and Nvidia?
All hardware can fail, including UPSes. (Score:5, Insightful)
I used to do that, and then I got a UPS instead and switched back to pure ext2. The performance hit from journalling is simply too high to tolerate. A decent UPS (pretty much anything made by APC) will prevent the crashes in the first place, solving the problem completely and without any unnecessary overhead. With UPS prices being as low as they are, there is no excuse for not having one, so I think that journalling will become obsolete in some near future.
Our industrial UPS (which is orders of magnitude more reliable than any APC product ever made) recently exploded, burnt, and shorted out the entire building's power. It spiked thousands of volts through the protected equipment and destroyed a half-dozen servers. The fire was fierce enough to cause our fm200 system (halon equivalent) to dump, which put out the fire before the main battery bank was breached.
This was the first time I've ever seen an UPS bigger than a Chrysler fail, but I've seen dozens of failures from those crappy little APC units. At one time I had a stack of burnt-out ones in my basement (I used to salvage the batteries for cash).
If your disaster survivability plan depends on any single piece of hardware never failing, it's no good. Offsite backup is your friend.
Re:Why not ZFS? (Score:2, Insightful)
In btrfs, data structures have "back references", and the fsck can be used while the filesystem is mounted.
Welcome to the party [usenix.org]!
Sincerely, FreeBSD 5.0 - 2001
Re:Back when there was only fat16, ntfs, ext2 used (Score:1, Insightful)
Interesting benchmark from 2003... Reiserfs moves some of the work to your CPU to increase IO performance. Let's see those same benchmarks on a modern system. Unless you're running Linux on a PIII-500, you're better off with reiserfs or XFS.
Re:Back when there was only fat16, ntfs, ext2 used (Score:3, Insightful)
A decent UPS (pretty much anything made by APC) will prevent the crashes in the first place, solving the problem completely and without any unnecessary overhead. With UPS prices being as low as they are, there is no excuse for not having one, so I think that journalling will become obsolete in some near future.
While a UPS is certainly a must, it does not protect you from hardware faults completely. Ever have a cap burn out on your motherboard, or lightning strike through your network?
Or the most irritating one of all, get a static shock through the keyboard that resets the system?
Re:Why not ZFS? (Score:1, Insightful)
ZFS was designed without fsck because fsck doesn't recover filesystem data just metadata. ZFS metadata is written using "ditto" blocks. This means its written in two different places on the disk. When scrub is called and zfs finds metadata problems they are corrected using this redundant data. Thus fsck is useless.
What you're talking about is if you're actual data is damaged (ie the checksum doesn't match) then zfs can only correct this if its applied some sort of raid to the disk. As far as I'm aware fsck utilities can only correct metadata issues with the filesystems. Actual data corruption issues are beyond the scope of the standard fsck utility.