Re: [PATCH 0/4] Fiemap, an extent mapping ioctl - round 2

[Andreas Dilger <adilger@sun.com>]

On Jul 03, 2008  16:17 +0100, Jamie Lokier wrote:
> jim owens wrote:
> >   FIEMAP_EXTENT_NO_BYPASS
> > 
> > As in "you can't bypass the filesystem" to directly access it.
> 
> Can we also commit to this, when FIEMAP_EXTENT_NO_BYPASS is *not* set:
> 
>    1. The data at fe_physical, and *will not move* so long as nothing
>       modifies *that particular file*?
> 
>    2. Both reading *and writing* the file bypassing the filesystem are ok.

I don't think any such guarantee can be made.  What if the file is
truncated and rewritten after the FIEMAP is called?  The filesystem
can't guarantee that will not happen. I think the only way to make
sure of constant mapping is to call FIEMAP before and after the blocks
are read.

> The reason for 2 is that some filesystems checksum the data and/or
> replicate it, and won't be readable if you write to it directly.

EEEEEK.  The _intent_ of FIEMAP is mostly for reporting fragmentation,
and possibly to allow a "generic" defragmenter to be written.  At an
outside stretch I could imagine some tools like "dump" wanting direct
read access to the file data.

Directly writing underneath a filesystem is major bad news and will
likely corrupt the filesystem because you can never be sure that there
aren't dirty pages in the page cache that will overwrite your "direct"
write, or that your write isn't racy with an unlink or truncate.

Cheers, Andreas
--
Andreas Dilger
Sr. Staff Engineer, Lustre Group
Sun Microsystems of Canada, Inc.