On 2019-03-31 07:27, Alberto Bursi wrote:
On 30/03/19 13:31, Qu Wenruo wrote:
Hi,
I'm wondering if it's possible that certain physical device doesn't
handle flush correctly.
E.g. some vendor does some complex logical in their hdd controller to
skip certain flush request (but not all, obviously) to improve performance?
Do anyone see such reports?
And if proves to happened before, how do we users detect such problem?
Can we just check the flush time against the write before flush call?
E.g. write X random blocks into that device, call fsync() on it, check
the execution time. Repeat Y times, and compare the avg/std.
And change X to 2X/4X/..., repeat above check.
Thanks,
Qu
Afaik HDDs and SSDs do lie to fsync()
unless the write cache is turned off with hdparm,
Nope, not the case on modern Linux. The issue here was that Linux did
not issue a FLUSH bio as part of the completion of an fsync() system
call, and problem has long-since been fixed (and wasn't actually the
disk lying, but the kernel).
hdparm -W0 /dev/sda
similarly to RAID controllers.
And most RAID controllers don't actually lie either. The SCSI and ATA
standards both count a write that is stored in a _non-volatile_ cache as
completed, and any halfway-decent RAID controller will be using some
form of non-volatile storage for it's cache (classically battery-backed
SRAM, but there's been some shift to NOR or NAND flash storage recently,
and I've seen a couple of really expensive ones using more-exotic
non-volatile storage technologies).
see below
https://brad.livejournal.com/2116715.html
https://queue.acm.org/detail.cfm?id=2367378
