Re: [ANNOUNCE] new new aops patchset

[Nick Piggin <npiggin@suse.de>]

On Tue, Apr 03, 2007 at 10:35:19AM -0700, Badari Pulavarty wrote:
> On Mon, 2007-04-02 at 14:09 +0200, Nick Piggin wrote:
> > Updated aops patchset against 2.6.21-rc5.
> > 
> > http://www.kernel.org/pub/linux/kernel/people/npiggin/patches/new-aops/
> > 
> > Files/dirs are 2.6.21-rc5-new-aops*
> 
> Here is the ext4 support for it. This is a simple port from 
> ext3 code. Ran fsx without any problems :)

Thanks. Again, I guess this needs updating for write_failure backout :(


> BTW, I never clearly understood what exactly the problem these
> new interfaces are solving and how :( I can dig through the
> archives and try to figure out. Would you care to put a 
> small description of the *actual* problem and how these
> new aops are needed (vs hacking the existing methods).

OK, so the problem from my point of view is the pagecache write
deadlock:

http://www.kernel.org/pub/linux/kernel/people/npiggin/patches/new-aops/2.6.21-rc5-new-aops/broken-out/mm-pagecache-write-deadlocks.patch

The problem with that fix is that it requires an extra copy (I
thought long and hard about different ways to fix this without
changing the aops API and without taking a performance hit).

It was pretty clear that the problem can be fixed easily and efficiently
in the mm/ code if the the API can be changed a bit (eg.
allow commit_write to commit a range which is smaller than the
prepare_write range).

The problem with changing the API is that you break all filesystems,
and out of tree filesystems. Even if we ignore the out of tree ones,
the existing ones can have difficult and subtle issues that I cannot
fix alone.

So I decided that the best way to go is to introduce the "slow" fix
for everyone, then add these new aops. Once everyone is moved to
the new aops, we remove the old ones and a lot of old cruft with
them.

So at this point we can make a clean break and come up with an API
that is not only capable of fixing the deadlock, but is also better
suited to modern filesystems (prepare_write was intorduced in 2.2 or
2.0 IIRC, and probably suffered from deadlocks even then!).

I don't know if write_begin/ write_end is final yet (which is why we
need your input), but it already does help a lot with the clustered
filesystems right now.

The reason we also have the (still unused) perform_write, is that was
my first attempt at a new interface. The problem with that is that
it is difficult to provide generic block helpers that are usable in
more complex ways. It also cannot be used for source data other than
memory in iovecs. However the reason why it is still there is because
I already introduced the iov_iter and infrastructure for it, and I
think it is a very nice, clean interface, and can be good for
high performance writes (I got positive results even with a naive
ext2 implementation).

Does that answer your question?

Thanks,
Nick