Re: [PATCH 1/4] vfs: vfs-level fiemap interface

[Chris Mason <chris.mason@oracle.com>]

On Wed, Sep 17, 2008 at 04:02:12PM +0100, Jamie Lokier wrote:
> Jörn Engel wrote:
> > Apart from the typo above, here is a more discouraging version:
> > 
> >   In general, accessing the block device directly is strongly discouraged.
> >   Exceptions exist mainly in the form of boot loaders like lilo and grub,
> >   at a time when the filesystem is not (cannot be) mounted.
> > 
> >   If the flag DATA_ENCODED is set, however, even this exception is no
> >   longer valid.  The content is encoded in some form.  Details are
> >   unknown, it could be compressed, encrypted or something else.
> 
> I'm not clear about something from the above description.
> 
> If I were writing a journalling / tree-like filesystem, and I did
> store data in blocks without encoding, but fsync() only waits for them
> to be committed to journal, not their final destination, and also they
> might be moved around - should I set DATA_ENCODED or not?  (And should
> I return the temporary location in the long-running journal since
> that's the only place the data is committed at the time of the call?)
> 
> 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.

-chris

--
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html