Cc: Eric W. Biederman <ebiederm@...>, Theodore Tso <tytso@...>, Andrew Morton <akpm@...>, <clameter@...>, <linux-kernel@...>, Mel Gorman <mel@...>, William Lee Irwin III <wli@...>, Jens Axboe <jens.axboe@...>, Badari Pulavarty <pbadari@...>, Maxim Levitsky <maximlevitsky@...>
You don't manipulate data except for copy_from_user, copy_to_user.
That is easy comparatively to deal with, and certainly doesn't
need vmap.
Meta-data may be trickier, but a lot of that depends on your
individual filesystem and how it organizes it's meta-data.
Potentially. This is a just a meta data problem, and possibly we
solve it with something like vmap. Possibly the filesystem won't
cross those kinds of boundaries and we simply never care.
The fact that it is a meta-data problem suggests it isn't the fast
path and we can incur a little more cost. Especially if we filesytems
with large block sizes are rare.
Bleh. It has been to many days since I have hacked that code I forgot
which piece that was. Yes. prepare_to_write is called before
we write to the page cache from the filesystem.
We already handle multiple page writes fairly well in that context.
prepare_write, commit_write may need a page cache but it may not.
All that really needs to happen is that all of the pages that
are part of the block get marked dirty in the page cache so one
won't get written without the others.
Yes, instead of having to redesign the interface between the
fs and the page cache for those filesystems that handle large
blocks we instead need to redesign significant parts of the VM interface.
Shift the redesign work to another group of people and call it a trivial.
That is hardly a gain when it looks like you can have the same effect
with some moderately simple changes to mm/filemap.c and the existing
interfaces.
Eric
-
