From mboxrd@z Thu Jan 1 00:00:00 1970 From: Robert S Peterson Subject: [patch] loop.c to use write ops for fs requiring special locking Date: Wed, 01 Mar 2006 10:48:57 -0600 Message-ID: <1141231737.15117.88.camel@technetium.msp.redhat.com> Mime-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit Return-path: Received: from mx1.redhat.com ([66.187.233.31]:53915 "EHLO mx1.redhat.com") by vger.kernel.org with ESMTP id S1751493AbWCAQoT (ORCPT ); Wed, 1 Mar 2006 11:44:19 -0500 To: fs-devel mailing list , Andrew Morton , Anton Altaparmakov Sender: linux-fsdevel-owner@vger.kernel.org List-Id: linux-fsdevel.vger.kernel.org Hi All, 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. 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. Feedback? Regards, Bob Peterson rpeterso@redhat.com --- linux-2.6.15.4.orig/drivers/block/loop.c 2006-02-10 01:22:48.000000000 -0600 +++ linux-2.6.15.4.patched/drivers/block/loop.c 2006-03-01 09:38:48.000000000 -0600 @@ -44,6 +44,11 @@ * backing filesystem. * Anton Altaparmakov, 16 Feb 2005 * + * Extension of Anton's idea: Use normal write file operations rather + * than prepare_write and commit_write when the backing filesystem + * requires special locking. + * Robert Peterson , 01 Mar 2006 + * * Still To Fix: * - Advisory locking is ignored here. * - Should use an own CAP_* category instead of CAP_SYS_ADMIN @@ -74,6 +79,7 @@ #include #include #include +#include #include @@ -781,7 +787,8 @@ static int loop_set_fd(struct loop_devic */ if (!file->f_op->sendfile) goto out_putf; - if (aops->prepare_write && aops->commit_write) + if (!(file->f_vfsmnt->mnt_sb->s_type->fs_flags & FS_REQUIRES_LOCKING) && + aops->prepare_write && aops->commit_write) lo_flags |= LO_FLAGS_USE_AOPS; if (!(lo_flags & LO_FLAGS_USE_AOPS) && ! file->f_op->write) lo_flags |= LO_FLAGS_READ_ONLY; diff -pur linux-2.6.15.4.orig/include/linux/fs.h linux-2.6.15.4.patched/include/linux/fs.h --- linux-2.6.15.4.orig/include/linux/fs.h 2006-02-10 01:22:48.000000000 -0600 +++ linux-2.6.15.4.patched/include/linux/fs.h 2006-02-28 17:18:48.000000000 -0600 @@ -83,6 +83,7 @@ extern int dir_notify_enable; /* public flags for file_system_type */ #define FS_REQUIRES_DEV 1 #define FS_BINARY_MOUNTDATA 2 +#define FS_REQUIRES_LOCKING 4 /* Filesystem requires locking */ #define FS_REVAL_DOT 16384 /* Check the paths ".", ".." for staleness */ #define FS_ODD_RENAME 32768 /* Temporary stuff; will go away as soon * as nfs_rename() will be cleaned up