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 - To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
