Announcement

Collapse
No announcement yet.

The Performance Impact Of Ubuntu's Wubi Windows Installer

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

  • The Performance Impact Of Ubuntu's Wubi Windows Installer

    Phoronix: The Performance Impact Of Ubuntu's Wubi Windows Installer

    Being developed since 2007 and integrated in Ubuntu since 2008 with their Ubuntu 8.04 LTS release has been Wubi, the Windows-based Ubuntu Installer. While most Linux users tend to install Ubuntu using the LiveCD or the alternate CD installer, by using Wubi you can setup a full desktop from within Microsoft Windows. Wubi places Ubuntu into a disk image still residing on the Windows partition, thereby making it easy to install and remove without risking any problems of messing up your drive's partitions. While Wubi may lower the barrier for entry to trying out an Ubuntu Linux desktop, it does not come without some performance penalties associated to using the loop-mounted device stored on the Microsoft file-system.

    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
    Wow, and article I actually found interesting. It's been a while...

    Comment


    • #3
      when linux is installed "on top" of something, writes requiring a fsync (sync to disk) are cached instead of being performed.
      this operation is very slow, and used for every single transaction in databases such as postgresql or sqlite unless disabled (and it's not)

      that explains the performance difference for the databases

      While you do point out that the operations are performed asynch, i don't think you stress this out enough:

      The performance difference is absolutely NORMAL and the benchmark result is absolutely BOGUS for databases (and any bench using some database library doing the same thing)

      if you think that's not relevant, just disable fsync on your native linux. applications won't work as expected (no enforced physical write) but performance will be greatly improved for databases. (faster than wubi)


      Note that proper apps disable fsync in sqlite when the data integrity / enforced push to physical disk is not required.

      Comment


      • #4
        I would like to see a comparison of Wubi vs various emulators on windows (vmware,virtualbox etc). Then I can make some decisions on which is the correct technology to roll out to users.

        thanks

        Comment


        • #5
          Originally posted by zouboulou View Post
          when linux is installed "on top" of something, writes requiring a fsync (sync to disk) are cached instead of being performed.
          this operation is very slow, and used for every single transaction in databases such as postgresql or sqlite unless disabled (and it's not)

          that explains the performance difference for the databases

          While you do point out that the operations are performed asynch, i don't think you stress this out enough:

          The performance difference is absolutely NORMAL and the benchmark result is absolutely BOGUS for databases (and any bench using some database library doing the same thing)

          if you think that's not relevant, just disable fsync on your native linux. applications won't work as expected (no enforced physical write) but performance will be greatly improved for databases. (faster than wubi)


          Note that proper apps disable fsync in sqlite when the data integrity / enforced push to physical disk is not required.
          It is Normal for the type of configuration that occurs. But it does mean that writes are most likely getting deferred which usually will mean that if you have a system crash there is an increased chance of corruption in databases and possibly other file system operations.

          Usually the authors of subsystems make a conscious decision to checkpoint operations at particular points. If some part in the filesystem stack doesn't honor the sync semantics bad things can happen.

          The particular semantics for fsync (and implied for other variants like O_SYNC are below. I have highlighted the key part.

          fsync() transfers ("flushes") all modified in-core data of (i.e., modified buffer cache pages for) the file referred to by the file descriptor fd to the disk device (or other permanent storage device) where that file resides. The call blocks until the device reports that the transfer has completed.
          If there is a crash immediately after fsync, data will be lost on a based architecture WUBI. If a user wants to take action to disable fsync at the system level, they can. If an app wants to disable fsync when it isn't needed, they can. But a system architecture shouldn't implicitly change the default semantic.

          Michael's reference to the KVM/QEMU stack issues last year (and my motivation for the "five stages of benchmark loss") is sound. After dealing with 4 different projects (QEMU/KVM/SQLite/Ubuntu) a change was made to QEMU to honor barriers. Of course these benchmarks are considerably slower in KVM (well I expect them to be), but the default semantics are now being honored.

          It would most likely be same issue here.

          For completeness, there is a launchpad bug here - https://bugs.launchpad.net/wubi/+bug/664683

          Matthew

          Comment


          • #6
            Originally posted by 27escape View Post
            I would like to see a comparison of Wubi vs various emulators on windows (vmware,virtualbox etc). Then I can make some decisions on which is the correct technology to roll out to users.

            thanks
            Neither, native installation is better since the only real difference between these installs is that one is riding on top of NTFS with different mount options basically. As another reader pointed out, it isn't actually writing those changes to disk in some of the tests..

            Another case of comparing apples to oranges? Has to be. If you modified mount options so that the same options were actually being carried out on both systems, then you'd have a fair comparison. There's already been comparisons here on Phoronix about NTFS vs. EXT4 and whatnot. Regardless of that though, these test are the real performance differences users will see between those two default installations, which is useful data in and of itself in any case, even if one is highly unsafe data integrity-wise.

            Comment


            • #7
              [QUOTE=mtippett;153104
              If there is a crash immediately after fsync, data will be lost on a based architecture WUBI. If a user wants to take action to disable fsync at the system level, they can. If an app wants to disable fsync when it isn't needed, they can. But a system architecture shouldn't implicitly change the default semantic.
              [/quote]
              Oh i'm not recommending it, i just heard too many times how layering some fs on top of another and thus bypassing fsync was a "perf optimization that makes sense" that i shielded my post against that.
              I don't recommend cutting one's own finger either but they can do that too =)

              Michael's reference to the KVM/QEMU stack issues last year (and my motivation for the "five stages of benchmark loss") is sound. After dealing with 4 different projects (QEMU/KVM/SQLite/Ubuntu) a change was made to QEMU to honor barriers. Of course these benchmarks are considerably slower in KVM (well I expect them to be), but the default semantics are now being honored.

              It would most likely be same issue here.

              For completeness, there is a launchpad bug here - https://bugs.launchpad.net/wubi/+bug/664683

              Matthew
              Ok, I didn't realize it was his reference here. Pretty cool that QEMU honors barriers actually. Still, the fsync issues in benchmarks remains.

              Comment


              • #8
                Originally posted by zouboulou View Post
                Oh i'm not recommending it, i just heard too many times how layering some fs on top of another and thus bypassing fsync was a "perf optimization that makes sense" that i shielded my post against that.
                I don't recommend cutting one's own finger either but they can do that too =)

                Ok, I didn't realize it was his reference here. Pretty cool that QEMU honors barriers actually.
                It took about a week of pain to get that accepted. I had given up when one of the more quiet lead developers looked over the details and created/applied the patch.

                Still, the fsync issues in benchmarks remains.
                Do you mean that the benchmarks should not be used or that there is an fsync issue that needs to be resolved in the system under test?

                Comment


                • #9
                  Wubi is an excellent and indispensable tool

                  WUBI IS GREAT!!!

                  At my job we have to use Windows, also on the laptops.

                  Thanks to Wubi, I could install Linux on my workplace' laptop and remove it when I had to return it for an upgrade. The IT-dept never knew and have never complained.

                  Wubi is an excellent and indispensable tool!!!

                  Comment


                  • #10
                    Do you mean that the benchmarks should not be used or that there is an fsync issue that needs to be resolved in the system under test?

                    There are two levels to this:

                    The shallow answer:

                    The methodology used is deeply flawed and none of the disk benchmarks used Phoronix really matter. This is a constant issue with this website. Early on people tried to point out the flaws, but right now people that actually depend on benchmarks for doing performance testing on real-world systems just roll their eyes when anything to do with file systems is mentioned in phoronix.

                    Some benchmarks may have useful information, but it's extremely difficult to know what information is bogus and what is good. The signal to noise ratio is too low to make much use of them.

                    Game benchmarks are performed using actual games. So they are useful. Unlike the disk benchmarks.


                    The deep answer:

                    The benchmarks are actually showing the relative performance of the different configurations.

                    It's just that what is actually being benchmarked is NOT what the article says is being benchmarked. It's something else entirely.


                    ----------------

                    One thing to keep in mind is that whenever you see file systems that seem to be performing very much faster then another one... the one that is doing stuff fast is generally going to be much riskier for your data then one that is doing things properly.

                    The only conclusion I can really draw is that:

                    If your using Wubi and you lose power to your machine or experience a crash your more likely to loose your data then if your using standard Ubuntu.

                    Comment

                    Working...
                    X