On 2019/3/31 下午7: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() fsync() on block device is interpreted into FLUSH bio. If all/most consumer level SATA HDD/SSD devices are lying, then there is no power loss safety at all for any fs. As most fs relies on FLUSH bio to implement barrier. And for fs with generation check, they all should report metadata from the future every time a crash happens, or even worse gracefully umounting fs would cause corruption. Thanks, Qu > > unless the write cache is turned off with hdparm, > > hdparm -W0 /dev/sda > > similarly to RAID controllers. > > see below > > https://brad.livejournal.com/2116715.html > > https://queue.acm.org/detail.cfm?id=2367378 > > > - >
Attachment:
signature.asc
Description: OpenPGP digital signature
