Re: Linux 2.6.29

[Bill Davidsen]

david@xxxxxxx wrote:
> On Wed, 1 Apr 2009, Andreas T.Auer wrote:
> > 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)

I think the sync point should be between the file system and the dcache, 
with the data only going into the dcache when it's time to write it. 
That also opens the door to doing atime better at no cost, atime changes 
would be kept internal to the file system, and only be written at close 
or fsync, even on a mount which does not use noatime or relatime. The 
file system can keep that information and only write it when appropriate.

--
bill davidsen <davidsen@xxxxxxx>
 CTO TMR Associates, Inc

"You are disgraced professional losers. And by the way, give us our money back."
   - Representative Earl Pomeroy,  Democrat of North Dakota
on the A.I.G. executives who were paid bonuses  after a federal bailout.


--
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/