[Date Prev][Date Next] [Thread Prev][Thread Next]
[Thread Index]
[Date Index]
[Author Index]
[dm-devel] Re: [PATCH 3/3] Add timeout feature
- From: Dave Chinner <david fromorbit com>
- To: Pavel Machek <pavel suse cz>
- Cc: axboe kernel dk, Takashi Sato <t-sato yk jp nec com>, mtk manpages googlemail com, "linux-kernel vger kernel org" <linux-kernel vger kernel org>, "xfs oss sgi com" <xfs oss sgi com>, Christoph Hellwig <hch infradead org>, "dm-devel redhat com" <dm-devel redhat com>, viro ZenIV linux org uk, "linux-fsdevel vger kernel org" <linux-fsdevel vger kernel org>, akpm linux-foundation org, "linux-ext4 vger kernel org" <linux-ext4 vger kernel org>
- Subject: [dm-devel] Re: [PATCH 3/3] Add timeout feature
- Date: Wed, 9 Jul 2008 09:10:27 +1000
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 fromorbit com
[Date Prev][Date Next] [Thread Prev][Thread Next]
[Thread Index]
[Date Index]
[Author Index]