linux-fsdevel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* [PATCH 0/3] freeze feature ver 1.8
@ 2008-06-30 12:20 Takashi Sato
  2008-06-30 13:54 ` Alasdair G Kergon
  0 siblings, 1 reply; 3+ messages in thread
From: Takashi Sato @ 2008-06-30 12:20 UTC (permalink / raw)
  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

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

^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: [PATCH 0/3] freeze feature ver 1.8
  2008-06-30 12:20 [PATCH 0/3] freeze feature ver 1.8 Takashi Sato
@ 2008-06-30 13:54 ` Alasdair G Kergon
  2008-07-01  9:12   ` [dm-devel] " Takashi Sato
  0 siblings, 1 reply; 3+ messages in thread
From: Alasdair G Kergon @ 2008-06-30 13:54 UTC (permalink / raw)
  To: Takashi Sato
  Cc: axboe@kernel.dk, mtk.manpages@googlemail.com,
	linux-kernel@vger.kernel.org, xfs@oss.sgi.com,
	dm-devel@redhat.com, viro@ZenIV.linux.org.uk,
	linux-fsdevel@vger.kernel.org, akpm@linux-foundation.org,
	linux-ext4@vger.kernel.org

On Mon, Jun 30, 2008 at 09:20:05PM +0900, Takashi Sato wrote:
> 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.
 
Is the following a fair summary?

1. Some filesystems have a freeze/thaw feature.  XFS exports this to
userspace directly through a couple of ioctls, but other filesystems
don't.  For filesystems on device-mapper block devices it is exported to
userspace through the DM_DEV_SUSPEND ioctl which LVM uses.

2. There is a desire to access this feature from userspace on non-XFS
filesystems without having to use device-mapper/LVM.

Alasdair
-- 
agk@redhat.com

^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: [dm-devel] [PATCH 0/3] freeze feature ver 1.8
  2008-06-30 13:54 ` Alasdair G Kergon
@ 2008-07-01  9:12   ` Takashi Sato
  0 siblings, 0 replies; 3+ messages in thread
From: Takashi Sato @ 2008-07-01  9:12 UTC (permalink / raw)
  To: Alasdair G Kergon
  Cc: akpm, viro, axboe, mtk.manpages, linux-kernel, xfs, dm-devel,
	linux-fsdevel, linux-ext4

Hi,

Alasdair G Kergon wrote:
>> 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.
>
> Is the following a fair summary?

Yes, you are right.
We'd like to use the freeze feature without device-mapper/LVM.

> 1. Some filesystems have a freeze/thaw feature.  XFS exports this to
> userspace directly through a couple of ioctls, but other filesystems
> don't.  For filesystems on device-mapper block devices it is exported to
> userspace through the DM_DEV_SUSPEND ioctl which LVM uses.
>
> 2. There is a desire to access this feature from userspace on non-XFS
> filesystems without having to use device-mapper/LVM.
>
> Alasdair

Cheers, Takashi 

^ permalink raw reply	[flat|nested] 3+ messages in thread

end of thread, other threads:[~2008-07-01  9:13 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2008-06-30 12:20 [PATCH 0/3] freeze feature ver 1.8 Takashi Sato
2008-06-30 13:54 ` Alasdair G Kergon
2008-07-01  9:12   ` [dm-devel] " Takashi Sato

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).