Tom Lane <[EMAIL PROTECTED]> writes: > Doug McNaught <[EMAIL PROTECTED]> writes:
> > In my understanding, it means "all currently dirty blocks in the file > > cache are queued to the disk driver". The queued writes will > > eventually complete, but not necessarily before sync() returns. I > > don't think subsequent write()s will block, unless the system is low > > on buffers and has to wait until dirty blocks are freed by the driver. > > We don't need later write()s to block. We only need them to not hit > disk before the sync-queued writes hit disk. So I guess the question > boils down to what "queued to the disk driver" means --- has the order > of writes been determined at that point? It's certainy possible that new write(s) get put into the queue alongside old ones--I think the Linux block layer tries to do this when it can, for one. According to the manpage, Linux used to wait until everything was written to return from sync(), though I don't *think* it does anymore. But that's not mandated by the specs. So I don't think we can rely on such behavior (not reordering writes across a sync()), though it will probably happen in practice a lot of the time. AFAIK there isn't anything better than sync() + sleep() as far as the specs go. Yes, it kinda sucks. ;) -Doug ---------------------------(end of broadcast)--------------------------- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
