Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1761317AbYF3MV0 (ORCPT ); Mon, 30 Jun 2008 08:21:26 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1757368AbYF3MVQ (ORCPT ); Mon, 30 Jun 2008 08:21:16 -0400 Received: from TYO202.gate.nec.co.jp ([202.32.8.206]:55550 "EHLO tyo202.gate.nec.co.jp" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1757213AbYF3MVP (ORCPT ); Mon, 30 Jun 2008 08:21:15 -0400 To: "akpm@linux-foundation.org" , "viro@ZenIV.linux.org.uk" Cc: "linux-ext4@vger.kernel.org" , "xfs@oss.sgi.com" , "dm-devel@redhat.com" , "linux-fsdevel@vger.kernel.org" , "linux-kernel@vger.kernel.org" , "axboe@kernel.dk" , "mtk.manpages@googlemail.com" Subject: [PATCH 0/3] freeze feature ver 1.8 Message-Id: <20080630212005t-sato@mail.jp.nec.com> Mime-Version: 1.0 X-Mailer: WeMail32[2.51] ID:1K0086 From: Takashi Sato Date: Mon, 30 Jun 2008 21:20:05 +0900 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 4171 Lines: 99 Hi Andrew and Alexander, I've addressed Andrew's comments in these patches. Please see my previous mail for details of changes. But only following change is different from my previous mail. I wrote: >>> +void del_freeze_timeout(struct block_device *bdev) >>> +{ >>> + if (delayed_work_pending(&bdev->bd_freeze_timeout)) >> >> Is this test needed? > > It's not necessary because cancel_delayed_work_sync checks it itself. > I will remove it. It's possible that the delayed work task (freeze_timeout()) calls del_freeze_timeout(). If the delayed work task calls cancel_delayed_work_sync() to delete itself, a deadlock will occur. So we need the test of delayed_work_pending(). Currently, ext3 in mainline Linux doesn't have the freeze feature which suspends write requests. So, we cannot take a backup which keeps the filesystem's consistency with the storage device's features (snapshot and replication) while it is mounted. In many case, a commercial filesystem (e.g. VxFS) has the freeze feature and it would be used to get the consistent backup. If Linux's standard filesytem ext3 has the freeze feature, we can do it without a commercial filesystem. So I have implemented the ioctls of the freeze feature. I think we can take the consistent backup with the following steps. 1. Freeze the filesystem with the freeze ioctl. 2. Separate the replication volume or create the snapshot with the storage device's feature. 3. Unfreeze the filesystem with the unfreeze ioctl. 4. Take the backup from the separated replication volume or the snapshot. [PATCH 1/3] Implement generic freeze feature I have modified to set the suitable error number (EOPNOTSUPP) in case the filesystem doesn't support the freeze feature. The ioctls for the generic freeze feature are below. o Freeze the filesystem int ioctl(int fd, int FIFREEZE, arg) fd: The file descriptor of the mountpoint FIFREEZE: request code for the freeze arg: Ignored Return value: 0 if the operation succeeds. Otherwise, -1 o Unfreeze the filesystem int ioctl(int fd, int FITHAW, arg) fd: The file descriptor of the mountpoint FITHAW: request code for unfreeze arg: Ignored Return value: 0 if the operation succeeds. Otherwise, -1 [PATCH 2/3] Remove XFS specific ioctl interfaces for freeze feature It removes XFS specific ioctl interfaces and request codes for freeze feature. This patch has been supplied by David Chinner. [PATCH 3/3] Add timeout feature The timeout feature is added to freeze ioctl. And new ioctl to reset the timeout period is added. o Freeze the filesystem int ioctl(int fd, int FIFREEZE, long *timeout_sec) fd: The file descriptor of the mountpoint FIFREEZE: request code for the freeze timeout_sec: the timeout period in seconds If it's 0 or 1, the timeout isn't set. This special case of "1" is implemented to keep the compatibility with XFS applications. Return value: 0 if the operation succeeds. Otherwise, -1 o Reset the timeout period This is useful for the application to set the timeout_sec more accurately. For example, the freezer resets the timeout_sec to 10 seconds every 5 seconds. In this approach, even if the freezer causes a deadlock by accessing the frozen filesystem, it will be solved by the timeout in 10 seconds and the freezer can recognize that at the next reset of timeout_sec. int ioctl(int fd, int FIFREEZE_RESET_TIMEOUT, long *timeout_sec) fd:file descriptor of mountpoint FIFREEZE_RESET_TIMEOUT: request code for reset of timeout period timeout_sec: new timeout period in seconds Return value: 0 if the operation succeeds. Otherwise, -1 Error number: If the filesystem has already been unfrozen, errno is set to EINVAL. Any comments are very welcome. Cheers, Takashi -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/