Re: Linux 2.6.29

[david]

On Wed, 1 Apr 2009, Andreas T.Auer wrote:

> On 01.04.2009 22:15 david@xxxxxxx wrote:
> > On Wed, 1 Apr 2009, Bill Davidsen wrote:
> >
> > > david@xxxxxxx wrote:
> > > > it's not that it's deliberatly pushing metadata out ahead of file
> > > > data, but say you have the following sequence
> > > >
> > > > write to file1
> > > > update metadata for file1
> > > > write to file2
> > > > update metadata for file2
> > > >
> > > > if file1 and file2 are in the same directory your software can
> > > > finish all four of these steps before _any_ of the data gets pushed
> > > > to disk.
> > > >
> > > > then when the system goes to write the metadata for file1 it is
> > > > pushing the then-current copy of that sector to disk, which includes
> > > > the metadata for file2, even though the data for file2 hasn't been
> > > > written yet.
> > > >
> > > > if you try to say 'flush all data blocks before metadata blocks' and
> > > > have a lot of activity going on in a directory, and have to wait
> > > > until it all stops before you write any of the metadata out, you
> > > > could be blocked from writing the metadata for a _long_ time.
> > > If you mean "write all data for that file" before the metadata, it
> > > would seem to behave the way an fsync would, and the metadata should
> > > go out in some reasonable time.
> >
> > 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)

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/