LKML Archive on lore.kernel.org
help / color / mirror / Atom feed
From: Pavel Machek <pavel@ucw.cz>
To: Theodore Tso <tytso@mit.edu>, Eric Sandeen <sandeen@redhat.com>,
	Takashi Sato <t-sato@yk.jp.nec.com>,
	linux-ext4@vger.kernel.org, linux-fsdevel@vger.kernel.org,
	linux-kernel@vger.kernel.org
Subject: Re: [RFC] ext3 freeze feature
Date: Sat, 2 Feb 2008 13:52:07 +0000	[thread overview]
Message-ID: <20080202135207.GA4456@ucw.cz> (raw)
In-Reply-To: <20080125164229.GD17907@mit.edu>

On Fri 2008-01-25 11:42:29, Theodore Tso wrote:
> On Fri, Jan 25, 2008 at 10:34:25AM -0600, Eric Sandeen wrote:
> > > But it was this concern which is why ext3 never exported freeze
> > > functionality to userspace, even though other commercial filesystems
> > > do support this.  It wasn't that it wasn't considered, but the concern
> > > about whether or not it was sufficiently safe to make available.
> > 
> > What's the safety concern; that the admin will forget to unfreeze?
> 
> That the admin would manage to deadlock him/herself and wedge up the
> whole system...
> 
> > I'm also not sure I see the point of the timeout in the original patch;
> > either you are done snapshotting and ready to unfreeze, or you're not;
> > 1, or 2, or 3 seconds doesn't really matter.  When you're done, you're
> > done, and you can only unfreeze then.  Shouldn't this be done
> > programmatically, and not with some pre-determined timeout?
> 
> This is only a guess, but I suspect it was a fail-safe in case the
> admin did manage to deadlock him/herself.  
> 
> I would think a better approach would be to make the filesystem
> unfreeze if the file descriptor that was used to freeze the filesystem
> is closed, and then have explicit deadlock detection that kills the
> process doing the freeze, at which point the filesystem unlocks and
> the system can recover.

Hmm, not sure that works.

I have shell I used to freeze the ext3. Then it is pushed out by dirty
data waiting to be written to that ext3. Deadlock, with file
descriptor still open, and very hard to detect.

Ok, OOM killer will eventually hit the shell, close the fd and
unfreeze, but that is probably not what you want.

-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

  reply	other threads:[~2008-02-02 13:52 UTC|newest]

Thread overview: 30+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-01-25 10:59 Takashi Sato
2008-01-25 11:17 ` Pekka Enberg
2008-01-25 12:42   ` Takashi Sato
2008-01-26  5:17     ` David Chinner
2008-01-26 19:10     ` Christoph Hellwig
2008-01-25 12:18 ` Dmitri Monakhov
2008-01-25 13:33   ` Theodore Tso
2008-01-25 16:34     ` Eric Sandeen
2008-01-25 16:42       ` Theodore Tso
2008-02-02 13:52         ` Pavel Machek [this message]
2008-01-28 13:13     ` Takashi Sato
2008-02-01  3:03       ` Kazuto Miyoshi
2008-01-31  8:53     ` Daniel Phillips
2008-02-07  1:05     ` Takashi Sato
2008-02-08 10:48     ` Takashi Sato
2008-02-08 13:26       ` Andreas Dilger
2008-02-08 14:59         ` Christoph Hellwig
2008-02-15 11:51           ` Takashi Sato
2008-02-15 14:24             ` Eric Sandeen
2008-02-19 11:27               ` t-sato
2008-02-26  8:20                 ` [RFC] ext3 freeze feature ver 0.2 Takashi Sato
2008-02-26 16:39                   ` Eric Sandeen
2008-02-26 17:08                     ` Andreas Dilger
2008-02-27  8:31                       ` Takashi Sato
2008-03-07  9:13                 ` [RFC] freeze feature ver 1.0 Takashi Sato
2008-02-16 13:25             ` [RFC] ext3 freeze feature Christoph Hellwig
2008-02-13  8:23     ` Takashi Sato
2008-01-26  5:35 ` David Chinner
2008-01-26  5:39   ` David Chinner
2008-01-28 13:07   ` Takashi Sato

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:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

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

  git send-email \
    --in-reply-to=20080202135207.GA4456@ucw.cz \
    --to=pavel@ucw.cz \
    --cc=linux-ext4@vger.kernel.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=sandeen@redhat.com \
    --cc=t-sato@yk.jp.nec.com \
    --cc=tytso@mit.edu \
    --subject='Re: [RFC] ext3 freeze feature' \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

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