[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <010901c86e19$adaf1730$41a8400a@bsd.tnes.nec.co.jp>
Date: Wed, 13 Feb 2008 17:23:14 +0900
From: "Takashi Sato" <t-sato@...jp.nec.com>
To: "Theodore Tso" <tytso@....EDU>, <linux-ext4@...r.kernel.org>,
<linux-fsdevel@...r.kernel.org>, <linux-kernel@...r.kernel.org>
Subject: Re: [RFC] ext3 freeze feature
Hi,
> P.S. Oh yeah, it should be noted that freezing at the filesystem
> layer does *not* guarantee that changes to the block device aren't
> happening via mmap()'ed files. The LVM needs to freeze writes the
> block device level if it wants to guarantee a completely stable
> snapshot image. So the proposed patch doens't quite give you those
> guarantees, if that was the intended goal.
I don't think a mmap()'ed file is written to a block device while a filesystem
is frozen. pdflush starts the writing procedure of the mmap()'ed file's
data and calls ext3_ordered_writepage. ext3_ordered_writepage calls
ext3_journal_start to get the journal handle. As a result, the process
waits for unfreeze in start_this_handle.
pdflush
: :
ext3_ordered_writepage
ext3_journal_start
ext3_journal_start_sb
journal_start
start_this_handle <--- wait here
I actually tried freezing the filesystem after updating the mmap()'ed
file's data. But, the writing to the block device didn't happen.
(It happened right after unfreeze.)
I don't think the freeze feature on the block device level is needed
because the writing for the mmap()'ed file is suspended on
the frozen filesystem.
Any comments are very welcome.
Cheers, Takashi
-
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