Re: Linux 2.6.29

From: david
Date: Thu Apr 02 2009 - 00:55:41 EST


On Thu, 2 Apr 2009, Bron Gondwana wrote:

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's
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.
Thank you, David, for this use case, but I think the problem could be
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)?

but if only one filesystem needs this caability is it really worth complicating the dcache for the entire system?

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.

one aspect of mvcc systems is that they eat up space and require 'garbage collection' type functions. that could cause deadlocks if you aren't careful.

David Lang
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/