Recent Features
| |||||||||||||
what's needed is a application barrier() callwhat's needed is a application barrier() callPosted Sep 10, 2009 6:51 UTC (Thu) by njs (guest, #40338)In reply to: what's needed is a application barrier() call by dlang Parent article: POSIX v. reality: A position on O_PONIES
I dunno, I'm not an expert, though "prohibiting reordering in the device stack" raises a big red flag for me -- reordering is pretty much the entire way you get speed out of spinning-disk hard drives!
But whether my analysis is accurately pin-pointing the problem or not, with all respect, I think I'll trust Val's word over yours that there *is* a problem :-).
(Log in to post comments)
what's needed is a application barrier() call Posted Sep 10, 2009 7:01 UTC (Thu) by dlang (✭ supporter ✭, #313) [Link]
it's only prohibiting reordering around the barrier, not all reordering.
Val is definantly right about the difficulty in doing it the best possible way, as I noted my approach would run some possibility of the COW causing out of memory problems, but I suspect that it's a 90% solution.
what's needed is a application barrier() call Posted Sep 10, 2009 7:35 UTC (Thu) by njs (guest, #40338) [Link]
But now you're synchronizing all writes by all processes everywhere on the disk, not just the two blocks that actually got written to in this one file somewhere. If apps used that sort of barrier() too often then I think you'd end up with disk throughput that looks like you mounted with -o sync -- very little reordering would ever be allowed.
I guess this is complicated by the question of when dirty blocks get flushed, and in how large batches; maybe it's solvable. But I don't think memory is the main concern, at least.
what's needed is a application barrier() call Posted Sep 10, 2009 7:48 UTC (Thu) by dlang (✭ supporter ✭, #313) [Link]
you are absolutely correct, that's why I say it's only a 90% solution, but it may be something that gives you most of the benefit for a fraction of the effort.
|
|||||||||||||