Re: RFC: [PATCH-2.6] Add helper function to lock multiple pagecache pages.

[Anton Altaparmakov]

On Wed, 2005-02-02 at 14:34 -0800, Andrew Morton wrote:
> Anton Altaparmakov <aia21@xxxxxxxxx> wrote:
> >
> > Below is a patch which adds a function 
> >  mm/filemap.c::find_or_create_pages(), locks a range of pages.  Please see 
> >  the function description in the patch for details.
> 
> This isn't very nice, is it, really?  Kind of a square peg in a round hole.

Only followed your advice.  (-;  But yes, it is not very nice at all.

> If you took the approach of defining a custom file_operations.write() then
> I'd imagine that the write() side of things would fall out fairly neatly:
> no need for s_umount and i_sem needs to be taken anyway.  No trylocking.

But the write() side of things don't need s_umount or trylocking with
the proposed find_or_create_pages(), either...

Unfortunately it is not possible to do this since removing
->{prepare,commit}_write() from NTFS would mean that we cannot use loop
devices on NTFS any more and this is a really important feature for
several Linux distributions (e.g. TopologiLinux) which install Linux on
a loopback mounted NTFS file which they then use to place an ext3 (or
whatever) fs on and use that as the root fs...

So we definitely need full blown prepare/commit write.  (Unless we
modify the loop device driver not to use ->{prepare,commit}_write
first.)

Any ideas how to solve that one?

> And for the vmscan->writepage() side of things I wonder if it would be
> possible to overload the mapping's ->nopage handler.  If the target page
> lies in a hole, go off and allocate all the necessary pagecache pages, zero
> them, mark them dirty?

I guess it would be possible but ->nopage is used for the read case and
why would we want to then cause writes/allocations?  Example: I create a
sparse file of 2TiB size and put some data in relevant places.  Then an
applications mmap()s it and does loads of reads on the mmap()ped file
and perhaps a write here or there.  Do we really want that to start
allocating and filling in all read holes?  That seems worse than having
a square peg for a round hole that is hidden away in a single function.

There is nothing in the proposed find_or_create_pages() that means it
needs to go into mm/filemap.c.  It could easily be a private function in
fs/ntfs/aops.c.  I just thought that other fs who want to support
writing to large block sizes might find it useful and having a shared
copy in mm/filemap.c would be better in that case.  But if it is too
ugly to go in mm/filemap.c then that is fine, too.

At the moment I cannot see a way to solve my problem without the
proposed find_or_create_pages().  )-:

Best regards,

        Anton
-- 
Anton Altaparmakov <aia21 at cam.ac.uk> (replace at with @)
Unix Support, Computing Service, University of Cambridge, CB2 3QH, UK
Linux NTFS maintainer / IRC: #ntfs on irc.freenode.net
WWW: http://linux-ntfs.sf.net/ & http://www-stu.christs.cam.ac.uk/~aia21/

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