[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20080708231026.GP11558@disturbed>
Date: Wed, 9 Jul 2008 09:10:27 +1000
From: Dave Chinner <david@...morbit.com>
To: Pavel Machek <pavel@...e.cz>
Cc: Christoph Hellwig <hch@...radead.org>,
Takashi Sato <t-sato@...jp.nec.com>, akpm@...ux-foundation.org,
viro@...IV.linux.org.uk,
"linux-ext4@...r.kernel.org" <linux-ext4@...r.kernel.org>,
"xfs@....sgi.com" <xfs@....sgi.com>,
"dm-devel@...hat.com" <dm-devel@...hat.com>,
"linux-fsdevel@...r.kernel.org" <linux-fsdevel@...r.kernel.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
axboe@...nel.dk, mtk.manpages@...glemail.com
Subject: Re: [PATCH 3/3] Add timeout feature
On Mon, Jul 07, 2008 at 01:07:31PM +0200, Pavel Machek wrote:
> Hi!
>
> > I still disagree with this whole patch. There is not reason to let
> > the freeze request timeout - an auto-unfreezing will only confuse the
> > hell out of the caller. The only reason where the current XFS freeze
> > call can hang and this would be theoretically useful is when the
>
> What happens when someone dirties so much data that vm swaps out
> whatever process that frozen the filesystem?
a) you can't dirty a frozen filesystem - by definition a frozen
filesystem is a *clean filesystem* and *cannot be dirtied*.
b) Swap doesn't write through the filesystem
c) you can still read from a frozen filesystem to page your
executableѕ in.
d) if dirtying another unfrozen filesystem swaps out your
application so it can't run, then there's a major VM bug.
Regardless, until the app completes it is relying on the
filesystem being frozen, so it better remain frozen....
> I though that was why the timeout was there...
Not that I know of.
Cheers,
Dave.
--
Dave Chinner
david@...morbit.com
--
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