Page 2 of 3 FirstFirst 123 LastLast
Results 11 to 20 of 30

Thread: Fedora Logical Volume Manager Benchmarks

  1. #11
    Join Date
    Jul 2008
    Posts
    1,731

    Default

    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'.

  2. #12
    Join Date
    Jan 2010
    Posts
    52

    Default

    Quote 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.

  3. #13
    Join Date
    Jul 2008
    Posts
    1,731

    Default

    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

  4. #14
    Join Date
    Jul 2008
    Location
    Berlin, Germany
    Posts
    858

    Default

    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

  5. #15
    Join Date
    Jul 2008
    Location
    Berlin, Germany
    Posts
    858

    Default

    Quote 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.

  6. #16
    Join Date
    Jul 2008
    Posts
    1,731

    Default

    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.

  7. #17
    Join Date
    Jan 2010
    Posts
    52

    Default

    Quote 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.

  8. #18
    Join Date
    Jul 2008
    Posts
    1,731

    Default

    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.

  9. #19
    Join Date
    Jul 2008
    Location
    Berlin, Germany
    Posts
    858

    Default

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

  10. #20
    Join Date
    Jan 2009
    Posts
    1,497

    Default

    Quote 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.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •