On Sat, 30 Jan 2016 20:00:19 +0000 Simon Slavin <slavins at bigfraud.org> wrote:
> On 30 Jan 2016, at 7:56pm, James K. Lowden <jklowden at schemamania.org> > wrote: > > > Given that the fsync has returned successfully, I don't know of any > > hardware that then will take 1000 ms to complete the write. That's > > the basis for my "subsecond interval" assumption. > > Writing to a RAID which has other write commands queued. As Keith says, you get what you pay for. I would say that hardware that behaves as you describe is broken. Hardware must expose some kind of "yes, defintely writen" notification interface. If it does, that's what fsync abstracts. If it doesn't, it's broken, because "write" only means, "whatever, dude". A 7200 RPM drive is capable of ~75 I/O operation/second. To reach my 1-second threshold, the RAID controller would have to have that many queued operations. Not only that: it would have to have the chutzpah to claim to have written the data, knowing it couldn't guarantee its promise. Is Bernie Madoff consulting for Seagate? You might know more about this than I do. The last time I dealt with anything in the vicinity, write-queue depths of 10 were considered problematic. 100 would have been catastrophic. Stefan Meinlschmidt mentioned "on Linux the interval can be, IIRC, up to 30s". I think that's a point of confusion. That 30s sounds to me suspiciously like the kernel's sync checkpoint interval. Surely buffered writes inside the device are not subject to "up to" 30s; the device (in general) has no such timer. --jkl
