| |||||||||||||
Goodness gracious, are we fixing the right problem?Goodness gracious, are we fixing the right problem?Posted Mar 17, 2012 22:53 UTC (Sat) by davecb (subscriber, #1574)In reply to: Goodness gracious, are we fixing the right problem? by giraffedata Parent article: The trouble with stable pages
I quite agree: there should be several other ways to meet our needs than the one we first tried. My father used to say "if you can't think of at least three ways to do something, your not thinking hard enough". We've suggested two, perhaps others can suggest some more.
A minor niggle about deferring writes of locked pages: you need to delay not just the locked page but also any the depend upon it. When updating files, for example, you need to write the file data, the inode data and then the directory (if the file is new). Delaying the file write until after the inode write breaks the critical ordering we depend upon for consistency.
Of course, one might also change the logic to achieve consistency during writes by something other than critical orderings at this low a level: a good commit log of both metadata and data would allow us to enthusiastically reorder writes so much we could start risking starvation (;-))
--dave
(Log in to post comments)
Goodness gracious, are we fixing the right problem? Posted Mar 17, 2012 23:49 UTC (Sat) by giraffedata (subscriber, #1954) [Link] you need to delay not just the locked page but also any the depend upon it. Where such ordering is required, it must be implemented today with write barriers, because otherwise the device driver, not to mention the device, is free to do I/Os from the queue in any order it pleases. But I don't think anyone would be updating a page that is scheduled for I/O and is in front of a write barrier - it would defeat the purpose.
Goodness gracious, are we fixing the right problem? Posted Mar 18, 2012 0:03 UTC (Sun) by davecb (subscriber, #1574) [Link]
I fear one might do so unintentionally (;-))
--dave (exceedingly fallible) c-b
|
|||||||||||||