Announcement

Collapse
No announcement yet.

Ubuntu Acknowledges Boot Speed Problem

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • Ubuntu Acknowledges Boot Speed Problem

    Phoronix: Ubuntu Acknowledges Boot Speed Problem

    Developers at the Ubuntu Developer Summit have acknowledged the boot speed problem in Ubuntu 11.10 and are looking to improve the time it takes to boot Ubuntu Linux for the 12.04 release...

    Phoronix, Linux Hardware Reviews, Linux hardware benchmarks, Linux server benchmarks, Linux benchmarking, Desktop Linux, Linux performance, Open Source graphics, Linux How To, Ubuntu benchmarks, Ubuntu hardware, Phoronix Test Suite

  • #2
    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.)
    Last edited by DaemonFC; 04 November 2011, 05:45 PM.

    Comment


    • #3
      Originally posted by DaemonFC View Post
      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


      • #4
        Originally posted by movieman View Post
        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


        • #5
          Boot speed problem? Start using an SSD and Gnome 3

          Comment


          • #6
            Well, I guess they should just get rid of upstart and start using systemd like everybody else.

            Comment


            • #7
              Any chance we can get some charts looking at boot times of some of the other major distros over the past few releases?

              Comment


              • #8
                Originally posted by Lemmiwinks View Post
                Boot speed problem? Start using an SSD and systemd
                FTFY

                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


                • #9
                  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


                  • #10
                    Originally posted by Kivada View Post
                    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.

                    Comment

                    Working...
                    X