[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <49D4AFCA.1030405@tmr.com>
Date: Thu, 02 Apr 2009 08:30:02 -0400
From: Bill Davidsen <davidsen@....com>
To: david@...g.hm
CC: "Andreas T.Auer" <andreas.t.auer_lkml_73537@...us.ath.cx>,
linux-kernel@...r.kernel.org
Subject: Re: Linux 2.6.29
david@...g.hm 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@....com>
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@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists