Announcement

Collapse
No announcement yet.

Fedora Logical Volume Manager Benchmarks

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

  • #11
    bullshit.
    with 2.6.38, 2.6.39, 3.0.0-rc:

    Disconnect usb device, boom kernel panic
    Add usb device boom kernel panic

    some other reasons, kernel panic

    your psu gets flaky
    your mobo gets flaky
    your fans clog up unnoticed
    your ram overheats
    your graphics drivers lock up the system
    some in kernel driver locks up the system.

    there are MANY reasons for a hard reboot. Power fluctuations are such a rare occurance (in civilized countries) they do not matter compared to kernel bugs or hardware failures.

    Or even the occasional 'oops, tripped over the cord'.

    Barriers are a must. Disabling them is a typical ext3/redhat/fedora move to blind the stupid. They want to look good in benchmarks made by people without a clue. Disabling barriers is like hitting the user in the face and telling him 'hey, I don't care if you lose all you files. I want to look good in stupid benchmarks'.

    Comment


    • #12
      Originally posted by Zapitron View Post
      The disabled write barrier risks (or lack thereof) (or controversy about "lack thereof") (or controversy about that supposed controversy) are discussed here. IMHO if you're using a UPS you can blow it off and not worry about write barriers. You're going to lose your data to user errors or simply due to using less-than-decade-debugged filesystems like ext4 or btrfs, long before write barriers are a factor. Again, IMHO.
      Thanks for the link, it helped me understand what barriers are. But as commits are usually written at the end, when can it happen that one block is not written and a commit is made? Some kind of disk I/O error? Even if that happens, the filesystem has to find out the anomaly pretty soon and fix it, so the risk is just those few seconds that the filesystem is in an inconsistent state.

      Comment


      • #13
        it is not only the problem of 'inconsist' state but also that there might be a HUGE window of a minute and more of 'you told the system to save the data and nothing happend' or 'you told the system to rename the file and it is still in progress'.

        Lots of people have lost lots of data because of idiotic defaults that are only set that way to look good in benchmarks conducted by people who
        a) don't have a clue or
        b) don't touch defaults or
        c) don't care or
        d) all of the above

        Comment


        • #14
          Write barriers don't directly help against data loss. They help against filesystem corruption.

          Kernel developers used to think that write barriers are slow and it is mostly safe to disable them[1], but Chris Mason came up with a write barrier torture test[2]. It demonstrated that on certain workloads, there is a 50% chance of your filesystem ending up corrupted when write barriers are disabled and the power fails.

          [1] http://lwn.net/Articles/283161/
          [2] http://thread.gmane.org/gmane.comp.f...tems.ext4/6702

          Comment


          • #15
            Originally posted by Zapitron View Post
            IMHO if you're using a UPS you can blow it off and not worry about write barriers.
            Unless your UPS breaks.

            Comment


            • #16
              and reiser4 show them that a fs using barriers can be fast. R4 went so far going into sync mode when barriers are not available.

              Of course r4 was blocked. Breaking and blocking had a long tradition. Breaking reiserfs had such a long tradition (demonstrating that 'get your code into the kernel and it will be fixed by us when we break it through changes elsewhere' was nothing but a lie). Reiser4 was blocked because of 'layer violations' - worse violations are ok with btrfs.

              The fact stands: fedora/redhat people don't care about your data. Only about looking good when stupid people run stupid benchmarks. Just like ext3.

              Comment


              • #17
                Originally posted by energyman View Post
                it is not only the problem of 'inconsist' state but also that there might be a HUGE window of a minute and more of 'you told the system to save the data and nothing happend' or 'you told the system to rename the file and it is still in progress'.

                Lots of people have lost lots of data because of idiotic defaults that are only set that way to look good in benchmarks conducted by people who
                a) don't have a clue or
                b) don't touch defaults or
                c) don't care or
                d) all of the above
                Tell me the good mount settings for EXT4 and I'll use them.

                Comment


                • #18
                  luckily ext4 does use barriers by default - and the fs can't do much if the layer above does not honor them. Well, reiser4 does something about it, but ext4 can't. So the defaults are ok, as long as you don't use barrier-destroying-lvm-setups.

                  Comment


                  • #19
                    LVM supports barriers too, since 2.6.33. Why they weren't enabled in the Fedora install I have no idea.

                    Comment


                    • #20
                      Originally posted by chithanh View Post
                      LVM supports barriers too, since 2.6.33. Why they weren't enabled in the Fedora install I have no idea.
                      Again, I don't think that fedora DISABLES them, the link I gave says the exact opposite.

                      Comment

                      Working...
                      X