[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20061020185522.GG10128@ca-server1.us.oracle.com>
Date: Fri, 20 Oct 2006 11:55:22 -0700
From: Mark Fasheh <mark.fasheh@...cle.com>
To: Nick Piggin <nickpiggin@...oo.com.au>
Cc: Nick Piggin <npiggin@...e.de>, linux-kernel@...r.kernel.org,
akpm@...l.org, linux-fsdevel@...r.kernel.org
Subject: Re: + fs-prepare_write-fixes.patch added to -mm tree
On Fri, Oct 20, 2006 at 09:27:02AM +1000, Nick Piggin wrote:
> >Cool, I appreciate that.
>
> OK, I will be posting that mail tomorrow or next day... I'll summarise
> your concerns you've posted in this thread too.
Thanks.
> zeroing out the hole and marking it uptodate in case of a 0 length
> ->commit_write does sound like the right way to go. I probably haven't
> handled that correctly if it needs to be done in ext? or generic fs/
> routines...
I *think* we want to handle this in generic_file_buffered_write(). Between
->prepare_write() and ->commit_write(). Here's what I'm thinking:
generic_file_buffered_write() notices that it got a short copy from
copy_from_user_inatomic(). It can then call a helper which walks the buffer
heads attached to the page looking for BH_New regions which haven't been
written to yet. It can then zero those out. We pass the normal from/to
arguments over to ->commit_write() and those callbacks don't have to change
- they just continue as usual. The newly allocated regions get written out,
filling the holes with valid data and we avoid returning garbage from disk
on subsequent reads.
Ideas? "Holes" in the design? :)
--Mark
--
Mark Fasheh
Senior Software Developer, Oracle
mark.fasheh@...cle.com
-
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