[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <E1KGSvZ-0006dB-53@pomaz-ex.szeredi.hu>
Date: Wed, 09 Jul 2008 08:13:21 +0200
From: Miklos Szeredi <miklos@...redi.hu>
To: tytso@....edu
CC: pavel@...e.cz, hch@...radead.org, t-sato@...jp.nec.com,
akpm@...ux-foundation.org, viro@...IV.linux.org.uk,
linux-ext4@...r.kernel.org, xfs@....sgi.com, dm-devel@...hat.com,
linux-fsdevel@...r.kernel.org, linux-kernel@...r.kernel.org,
axboe@...nel.dk, mtk.manpages@...glemail.com
Subject: Re: [PATCH 3/3] Add timeout feature
On Tue, 8 Jul 2008, Theodore Tso wrote:
> On Wed, Jul 09, 2008 at 10:52:54AM +1000, Dave Chinner wrote:
> > If you walk enough inodes while the filesystem is frozen, it
> > theoretically could happen. Typically a filesystem is only for a
> > few seconds at a time so in the real world this has never, ever been
> > a problem.
>
> I had argued for the timeout (and so it's mostly my fault that
> Takashi-San included it as a feature) mainly because I was (and still
> amm) deeply paranoid about the competence of the application
> programers who might use this feature. I could see them screwing up
> leaving it locked forever --- perhaps when their program core dumps or
> when the user types ^C and they forgot to install a signal handler,
> leaving the filesystem frozen forever.
A much better way to deal with that would be to limit the freeze to
the lifetime of the process somehow. E.g. the freeze ioctl sets a bit
in struct file (I'm sure we have some available) and release on the
file checks this bit and thaws the filesystem.
This would mean that freeze and thaw will have to be done on the same
file descriptor, but this isn't unreasonable to expect, is it?
Miklos
--
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists