[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20080714063617.GF31949@elf.ucw.cz>
Date: Mon, 14 Jul 2008 08:36:17 +0200
From: Pavel Machek <pavel@...e.cz>
To: jim owens <jowens@...com>
Cc: linux-fsdevel@...r.kernel.org, Dave Chinner <david@...morbit.com>,
Theodore Tso <tytso@....edu>,
Arjan van de Ven <arjan@...radead.org>,
Miklos Szeredi <miklos@...redi.hu>, 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-kernel@...r.kernel.org,
axboe@...nel.dk, mtk.manpages@...glemail.com
Subject: Re: [PATCH 3/3] Add timeout feature
On Sun 2008-07-13 13:15:43, jim owens wrote:
> Pavel Machek wrote:
>
>>> This means ONLY SOME metadata (or no metadata) is flushed and
>>> then all metadata updates are stopped. User/kernel writes
>>> to already allocated file pages WILL go to a frozen disk.
>>
>> That's the difference here. They do write file data, and thus avoid
>> mmap()-writes problem.
>>
>> ...and they _still_ provide auto-thaw.
>> Pavel
>
> One of the hardest things to make people understand is that
> stopping file data writes in the filesystem during a freeze
> is not just dangerous, it is also __worthless__ unless you
> have a complete "user environment freeze" mechanism.
Eh?
> And unless each independent component has a freeze and they
> can all be coordinated, the data in the pipeline is never
> stable enough to say "if you stop all writes to disk and
> take a snapshot, this is the same as an orderly shutdown,
> backup, restore, and startup".
If you also freeze data writes, at least snapshot is not worse than
_unexpected_ shutdown.
And apps should already be ready for unexpected shutdowns (using fsync
etc).
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
--
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