[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20080920135048.GA15698@think.oraclecorp.com>
Date: Sat, 20 Sep 2008 09:50:49 -0400
From: Chris Mason <chris.mason@...cle.com>
To: Jamie Lokier <jamie@...reable.org>,
Jörn Engel <joern@...fs.org>,
Theodore Tso <tytso@....edu>, Andreas Dilger <adilger@....com>,
Christoph Hellwig <hch@...radead.org>,
linux-fsdevel@...r.kernel.org, linux-ext4@...r.kernel.org,
akpm@...uxfoundation.org, Mark Fasheh <mfasheh@...e.com>,
mtk.manpages@...il.com
Subject: Re: [PATCH 1/4] vfs: vfs-level fiemap interface
On Sat, Sep 20, 2008 at 05:43:12PM +1000, Dave Chinner wrote:
> On Fri, Sep 19, 2008 at 06:38:02PM +0100, Jamie Lokier wrote:
> > Chris Mason wrote:
> > > On Wed, Sep 17, 2008 at 04:02:12PM +0100, Jamie Lokier wrote:
> > > > Assume that even reading after unmounting is not 100% safe, because
> > > > the data blocks could be relocated after calling FIEMAP (when the
> > > > filesystem must be mounted), and before the unmount.
> > >
> > > For the journal case at least, grub can walk through the log of the FS
> > > looking for up to date copies of things. It does this already for
> > > reiserfs because the btree can't be trusted at all without a log replay.
>
> OMFG.
Shrug, either we force the user to do something to get the blocks on
disk in a stable location or we have a bootloader that can parse the
disk format. It's either pain on the developers (patching grub) or pain
on every user, and the support people who have to remind them to rerun
grub-find-the-disk-blocks-just-like-lilo
-chris
--
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