On Wed, 2005-02-02 at 14:34 -0800, Andrew Morton wrote:
> Anton Altaparmakov <[EMAIL PROTECTED]> 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 [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
