If this is your first visit, be sure to
check out the FAQ by clicking the
link above. You may have to register
before you can post: click the register link above to proceed. To start viewing messages,
select the forum that you want to visit from the selection below.

I'm more than happy to have an initrd and a half second delay while it loads the XFS module to be free of Ext4. Ext4 is a dog. You can "feel" how much slower it is when doing something such as installing a DEB package.

It didn't start out that bad, but over time they have found things such as broken programs that expect Ext3 filesystem behavior, even when that behavior is wrong, and have had to emulate the behavior in Ext4 even when it means negating the performance advantages of things like delayed allocation and persistent preallocation. Ext4 has to do a fsync every 5 seconds which dramatically reduces the usefulness of many of the performance advantages that it had over Ext3.

XFS on the other hand, is getting faster at about the same rate Ext4 is slowing down.

Despite what FUDsters out there will tell you about XFS, I haven't lost any data to it. I'm not on any kind of fancy system and I don't have a UPS, and Duke Energy manages to knock out the power in this part of Indiana on a regular basis. (Not much more than a stiff breeze will suffice) (Note: My tax money pays for brand spanking new power plants in Iraq while the US state of Indiana to which I also pay taxes has something meant to run vacuum cleaners on in the 1970s.)

Frankly I think Ext4 sucks and I try to avoid it whenever I can. You can turn off some of the ridiculous hacks it employs, such as the one that makes it "safe" to use with bad programs that expect incorrect Ext3 fsync behavior. I'm not aware of myself using any such programs and frankly I wouldn't want to use a program for anything where I'd like to know for sure that my data is saved that isn't bothering to call fsync.

I would though, like to know how Ubuntu is planning to go after initrd removal. Does it keep one around if you don't want to use the horrible Ext4 file system, or will it be stupid and simply not boot? This problem could be avoided if they built the XFS module into the kernel image. I mean shit, they already have three modules for Ext2, two modules for Ext3, and a module for Ext4 all baked in right now even though you only need the Ext4 module to reliably handle all three. If they want to bitch about kernel bloat, they should do what Fedora 16 is doing and get rid of the ext2 and ext3 modules and allow ext4 to manage those file systems without changing their on disk format. (You even get optimizations that don't change the on disk format, like the much improved ext4 multi-block block allocator.)

Comment

It didn't start out that bad, but over time they have found things such as broken programs that expect Ext3 filesystem behavior, even when that behavior is wrong, and have had to emulate the behavior in Ext4 even when it means negating the performance advantages of things like delayed allocation and persistent preallocation.

There's nothing 'broken' about expecting a filesystem to work in a sensible manner. If you can only get performance improvements by ensuring the filesystem is corrupt if the computer crashes, that's fine for a special-purpose filesystem on computers which have UPS and other systems to reduce the odds of a crash, but hopeless for general-purpose use.

And, in any case, all that wonderful performance from unsafe file writes vanishes the moment you have to tell developers 'just use fsync if you don't want your files to be corrupt after a crash'.

Comment

There's nothing 'broken' about expecting a filesystem to work in a sensible manner. If you can only get performance improvements by ensuring the filesystem is corrupt if the computer crashes, that's fine for a special-purpose filesystem on computers which have UPS and other systems to reduce the odds of a crash, but hopeless for general-purpose use.

And, in any case, all that wonderful performance from unsafe file writes vanishes the moment you have to tell developers 'just use fsync if you don't want your files to be corrupt after a crash'.

Up until Linux 3.1, Ext3 didn't even use write barriers.If you didn't lose data in a crash, it's only because of a set of lucky coincidences. (Think race conditions)

Hard disk are unreliable regardless of file system. Even the safest/slowest file system can become corrupt whenever there is a crash. It should be the job of the program to make sure the data it saves gets committed. It is not the filesystem's job to cripple itself and slow itself down by an order of magnitude to compensate for some barely competent application.

Comment

I haven't tested my boot speeds with and without an initrd on my Gentoo system, but I can say that a kernel with OpenRC boots just as fast, if not slightly faster than kernel/initrd with Upstart.

When I tested out Exherbo, a kernel with systemd definitely boots slightly faster than any other distribution I tried out (except for distributions that specifically concentrate on boot speeds), although that's not a fair comparison since it was built from scratch and didn't have as many services running than a default Ubuntu installation.

Switching over to a kernel without an initrd will help, but not by a whole lot. A kernel with no initrd with systemd will probably help the most.

Comment

As always, who gives a fuck about boot speed? Unless I update the kernel I don't reboot so even if it took 10 mins to boot it wouldn't be a big deal and if you're running a "must always be on" server then why aren't you staggering your systems so that you aren't down regardless?

Its like the flicker free boot, was it necessary for anyone or anything? Does the flicker damage the monitor? If thats the case then why do I have a few CRTs with more then a decade of service still being used with no perceptible wear? If it's damaging to LCDs it must only effect craptacular models since my 5 year old Samsung LCDs have yet to fail me and the screen in my 2002 iBook still looks as good as the day I bought it.

Comment

As always, who gives a fuck about boot speed? Unless I update the kernel I don't reboot so even if it took 10 mins to boot it wouldn't be a big deal and if you're running a "must always be on" server then why aren't you staggering your systems so that you aren't down regardless?

Its like the flicker free boot, was it necessary for anyone or anything? Does the flicker damage the monitor? If thats the case then why do I have a few CRTs with more then a decade of service still being used with no perceptible wear? If it's damaging to LCDs it must only effect craptacular models since my 5 year old Samsung LCDs have yet to fail me and the screen in my 2002 iBook still looks as good as the day I bought it.

I'm pretty certain it isn't a question of hardware damage, it is a question of polish, and fit and finish.