Page 5 of 5 FirstFirst ... 345
Results 41 to 45 of 45

Thread: Autonomously Finding Performance Regressions In The Linux Kernel

  1. #41

    Default

    Quote Originally Posted by Michael View Post
    @kraftman:

    Some of the tests (particularly some of the games) require some of the ia32-libs, so I just added that check on there if running 64-bit to always fetch those 32-bit libs. However, for Ubuntu 9.10 and others where it is no longer present, I will make a workaround.
    Thank you

  2. #42
    Join Date
    Jun 2009
    Posts
    24

    Default

    Quote Originally Posted by Michael View Post
    @kraftman:

    Some of the tests (particularly some of the games) require some of the ia32-libs, so I just added that check on there if running 64-bit to always fetch those 32-bit libs. However, for Ubuntu 9.10 and others where it is no longer present, I will make a workaround.
    command not found sounds more like it's not finding apt-get, not that ia32-libs is not there.

  3. #43

    Default

    There's a small mistake in the article:

    All that this PTS module needs to know is the starting and end points that return a different state, an accessible repository (Git, currently) to be tested to be tested,

  4. #44
    Join Date
    Dec 2008
    Location
    Halifax, NS, Canada
    Posts
    63

    Default

    Quote Originally Posted by mirza View Post
    Wait, this means that if I want to have consistent data on ext4 I must look at 5x slower PostgreSQL and other write-intensive applications? And proposed solution is either obscure mount switch with possibility of occasional file corruption or really _slow_ PostgreSQL. WTF?
    ... Or get a battery-backed SATA controller, like 3Ware's RAID cards.

    Although as others have said, it's the write cache in the disk that's the problem so only hard power-loss can cause the corruption that this change prevents. If you have a UPS, you can run with nobarrier. Linux crashing won't stop the disk from performing the buffered writes. (at least AFAIK. Is that true even if the crash causes a machine reset? i.e. on typical x86 hardware, does the system reset signal do anything that could flush the write buffer in a SATA hard drive?)

    If Linux just locks up and stops sending SATA commands, you're fine, because the disk will finish processing its queue.

  5. #45
    Join Date
    Jun 2009
    Posts
    24

    Default

    Quote Originally Posted by llama View Post
    ... Or get a battery-backed SATA controller, like 3Ware's RAID cards.

    Although as others have said, it's the write cache in the disk that's the problem so only hard power-loss can cause the corruption that this change prevents. If you have a UPS, you can run with nobarrier. Linux crashing won't stop the disk from performing the buffered writes. (at least AFAIK. Is that true even if the crash causes a machine reset? i.e. on typical x86 hardware, does the system reset signal do anything that could flush the write buffer in a SATA hard drive?)

    If Linux just locks up and stops sending SATA commands, you're fine, because the disk will finish processing its queue.
    unless you mount the partition with the sync option it is not safe to run without barriers even with a UPS.

    if te kernel goes haywire it may just stop sending commands, or it may lock up the SATA bus (or send garbage to the drive)

    but you are absolutly right that if you want good database performance you need battery backed cache, a 7200 rpm drive can only do ~160 seperate writes/sec, anytime you get numbers much higher than that you are seeing buffering take place, and if you don't have a battery on that buffer it means that a power failure could end up with things written in the wrong order, which may not be recoverable.

Posting Permissions

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