On Wed, Apr 01, 2009 at 03:29:29PM -0700, david@xxxxxxx wrote:On Wed, 1 Apr 2009, Andreas T.Auer wrote:On 01.04.2009 22:15 david@xxxxxxx wrote:except if another file in the directory gets modified while it'sThank you, David, for this use case, but I think the problem could be
writing out the first two, that file now would need to get written out
as well, before the metadata for that directory can be written. if you
have a busy system (say a database or log server), where files are
getting modified pretty constantly, it can be a long time before all
the file data is written out and the system is idle enough to write
the metadata.
solved quite easily:
At any write-out time, e.g. after collecting enough data for delayed
allocation or at fsync()
1) copy the metadata in memory, i.e. snapshot it
2) write out the data corresponding to the metadata-snapshot
3) write out the snapshot of the metadata
In that way subsequent metadata changes should not interfere with the
metadata-update on disk.
the problem with this approach is that the dcache has no provision for
there being two (or more) copies of the disk block in it's cache, adding
this would significantly complicate things (it was mentioned briefly a
few days ago in this thread)
It seems that it's obviously the "right way" to solve the problem
though. How much does the dcache need to know about this "in flight"
block (ok, blocks - I can imagine a pathological case where there
were a stack of them all slightly different in the queue)?
You'd be basically reinventing MVCC-like database logic with
transactional commits at that point - so each fs "barrier" call
would COW all the affected pages and write them down to disk.