LKML Archive on
help / color / mirror / Atom feed
From: David Chinner <>
To: Takashi Sato <>
Subject: Re: [RFC PATCH] freeze feature ver 1.0
Date: Tue, 25 Mar 2008 12:33:14 +1100	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <>

On Mon, Mar 24, 2008 at 08:11:36PM +0900, Takashi Sato wrote:
> Hi,
> This is the rebased freeze feature patch for linux-2.6.25-rc6.
> We can take a backup which keeps the filesystem's consistency with it.
> I have tested it cooperating with
> DRBD (Distributed Replicated Block Device (
> and made sure that I could take the consistent backup with a short
> frozen time (several seconds) while using the filesystem.
> The detailed procedure for my test is below.
> 1. Set up the replication between server A (primary) and
>    server B (secondary)
> 2. Make the ext3 filesystem on server A and mount it
>    (Run Linux kernel compile by 5 threads in parallel on it)
> 3. Freeze the filesystem on server A to block I/O and
>    keep the filesystem's consistency
> 4. Detach the secondary volume on server B
>    (e.g /sbin/drbdadm detach r0)
> 5. Unfreeze the filesystem on server A
> 6. Use the secondary volume on server B
>    I confirmed the followings.
>    - fsck didn't report any errors.
>    - It could be mounted correctly.
>    - Linux kernel compiles could re-start correctly.
> There is no functional change from the previous version.
> All of comments from ML have already been reflected in this patch.

Can you please split this into two patches - one which introduces the
generic functionality *without* the timeout stuff, and a second patch
that introduces the timeouts.

I think this timeout stuff is dangerous - it adds significant
complexity and really does not protect against anything that can't
be done in userspace.  i.e. If your system is running well enough
for the timer to fire and unfreeze the filesystem, it's running well
enough for you to do "freeze X; sleep Y; unfreeze X".  If you are
trying to protect against a freeze operation that hangs then
the filesystem needs fixing, not some new API to work around a bug....

FWIW, there is nothing to guarantee that the filesystem has finished
freezing when the timeout fires (it's not uncommon to see
freeze_bdev() taking *minutes*) and unfreezing in the middle of a
freeze operation will cause problems - either for the filesystem
in the middle of a freeze operation, or for whatever is freezing the
filesystem to get a consistent image.....


Dave Chinner
Principal Engineer
SGI Australian Software Group

  reply	other threads:[~2008-03-25  1:33 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-03-24 11:11 Takashi Sato
2008-03-25  1:33 ` David Chinner [this message]
2008-03-28  9:01 Takashi Sato
2008-03-30 22:31 ` David Chinner

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \ \ \ \ \ \ \ \ \
    --subject='Re: [RFC PATCH] freeze feature ver 1.0' \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

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).