Originally posted by Michael
View Post
Announcement
Collapse
No announcement yet.
Autonomously Finding Performance Regressions In The Linux Kernel
Collapse
X
-
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.
Comment
-
Originally posted by mirza View PostWait, 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?
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.
Comment
-
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.
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.
Comment
Comment