From mboxrd@z Thu Jan 1 00:00:00 1970 From: Anton Altaparmakov Subject: Re: [patch] loop.c to use write ops for fs requiring special locking Date: Thu, 2 Mar 2006 10:16:28 +0000 (GMT) Message-ID: References: <1141231737.15117.88.camel@technetium.msp.redhat.com> <20060301140902.53350bb6.akpm@osdl.org> Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: Robert S Peterson , linux-fsdevel@vger.kernel.org Return-path: Received: from ppsw-1.csi.cam.ac.uk ([131.111.8.131]:38547 "EHLO ppsw-1.csi.cam.ac.uk") by vger.kernel.org with ESMTP id S932398AbWCBKQq (ORCPT ); Thu, 2 Mar 2006 05:16:46 -0500 To: Andrew Morton In-Reply-To: <20060301140902.53350bb6.akpm@osdl.org> Sender: linux-fsdevel-owner@vger.kernel.org List-Id: linux-fsdevel.vger.kernel.org On Wed, 1 Mar 2006, Andrew Morton wrote: > Robert S Peterson wrote: > > Below is a small patch to loop.c I'd like to see in the kernel. > > > > This is an extension of Anton Altaparmakov's previous fix which allows > > loop.c to use the aop->write rather than prepare_write/commit_write if > > prepare_write/commit_write aren't available. > > There's a reason why we must use prepare_write/commit_write rather than > ->write() and ow-ow-my-brain-hurts I can't remember what it was. Anton, do > you recall? It is simply that it is faster on all file systems that can use prepare_write/commit_write and the "performance hungry" would have complained if it were to be removed. > > Right now, the current loop.c uses aop->prepare_write/commit_write > > unless there is no other option. However, due to special locking > > requirements, some backing filesystems may prefer the use of aop->write > > rather than prepare_write/commit_write. Since loop.c does not have > > advisory locking, the backing fs should have a choice of which to use. > > > > In the case of GFS, for example, loop.c's use of aop->prepare_write > > circumvents proper cluster locking and transaction building, so using > > aop->write is the right thing for loop.c to do. > > > > How the patch works: > > If the backing filesystem has special locking requirements (new flag in > > fs_flags) loop.c uses aop->write rather than prepare_write/commit_write. > > > > I think you'll find that cryptoloop doesn't work (see "ow-ow", above). *blink* Why should it not work? cryptoloop is exactly the reason for the performance hit with using ->write rather than prepare_write/commit_write as we need to allocate a temporary page, do the transformation from the source page to the temporary page, then send the temporary page to ->write, and finally release the page. Ugly but the only way to allow transformations in-flight I could see when writing the ->write using code for loop.c... Best regards, Anton -- Anton Altaparmakov (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/