[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-ID: <5564.1238684153@redhat.com>
Date: Thu, 02 Apr 2009 15:55:53 +0100
From: David Howells <dhowells@...hat.com>
To: Nick Piggin <nickpiggin@...oo.com.au>, hch@...radead.org
Cc: dhowells@...hat.com, viro@...iv.linux.org.uk, nfsv4@...ux-nfs.org,
linux-kernel@...r.kernel.org, linux-fsdevel@...r.kernel.org
Subject: Re: [PATCH 22/43] CacheFiles: Add a hook to write a single page of data to an inode [ver #46]
Nick Piggin <nickpiggin@...oo.com.au> wrote:
> > Hook the Ext2 and Ext3 operations to the generic implementation.
>
> Is this really worthwhile?
I seem to remember being told that I'm not allowed to call such directly (by
Christoph Hellwig perhaps?), and that I should add an address space op to do
this.
> What do you do that write_begin/write_end doesn't?
This code calls write_begin() and write_end().
write_begin() and write_end() don't actually update the target page, and don't
so the osync stuff.
My code assumed file can be passed as NULL to write_begin() and write_end().
If file is, however, necessary then the backing fs can do something different.
cachefiles doesn't know.
Creating loads of file structs gives you ENFILE problems if you start opening
lots of files internally. This caused lots of argument when I proposed a
patch to allow the kernels to open files not on account.
I'm quite happy to ditch the extra address space op and put this code in
cachefiles itself. Doing it there would perhaps allow me to handle multiple
pages more easily.
> I have a patch around somewhere enable splice stealing into the pagecache
> with write_begin/write_end if you are worried about the copy.
I'm not sure what you mean.
> But how about you put this at the end of the series justified with some
> numbers?
I don't see how that helps. cachefiles has to do something to get the data
out.
David
--
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