Autonomously Finding Performance Regressions In The Linux Kernel

[kraftman]

@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

[dlang]

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

[kraftman]

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,

[llama]

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.

[dlang]

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