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

[Jamie Lokier <jamie@shareable.org>]

Andreas Dilger wrote:
> > Is there a reason why fsync() before calling FIEMAP is unsuitable?
> 
> This was added because the xfsbmap operation always did an fsync before
> returning the extents.  I don't think it is strictly required, but it
> isn't harmful either.

It's not harmful but suggests it might do something important -
e.g. provide atomicity between the fsync and getting extends.

Can the documentation make it clear that it's exactly equivalent to
calling fsync() before - or, if that's not true, explain the diffence?

> > > * FIEMAP_FLAG_XATTR
> > > If this flag is set, the extents returned will describe the inodes
> > > extended attribute lookup tree, instead of it's data tree.
> > 
> > What is this for?  The meaning of the xattr tree sounds rather
> > filesystem specific to me.
> 
> This is to return the location of the xattr blocks for the inode.

Some filesystems will store xattrs as metadata - in exactly the same
as, say, the inode itself, it's permissions, mappings etc.

I'm not sure why xattrs get special treatment, compared with a
hypothetical FIEMAP_FLAG_METADATA for example, indicating which
physical blocks contain the inode itself, or it's other auxiliary
information.

(Aside: If there was a way to get physical block address for inodes
(without retrieving the inodes, using only the name) I know at least
one program that would benefit from that - it sorts stat() calls by
estimated inode block, which greatly speeds up scanning a large
filesystem.  I realise FIEMAP isn't an appropriate interface for
that.)

> > (I'm assuming 'direct access' means O_DIRECT).
> 
> "NO_DIRECT" has nothing to do with "O_DIRECT".  It just means that,
> per the description a few lines earlier, direct access to the file
> data is impossible (i.e. for lilo or other tool which thinks it can
> open "dev" and seek to "fe_physical" to read the data), or at best
> will have undefined results (e.g. you may get encrypted or compressed
> data back, or it is on the far side of a network interface).

Ok.  This wasn't clear, as 'direct access' means O_DIRECT elsewhere -
and some programs which use FIEMAP are likely to be the same ones
which use O_DIRECT.

Maybe calling it 'physical addressing' or something like that?

Because the field is called 'fe_physical', I'm thinking
FIEMAP_EXTENT_PHYSICAL is a much clearer flag name.  Also reversing
the sense, so it's _set_ when 'fe_physical' is a valid quantity.

(A flag FIEMAP_EXTENT_O_DIRECT to indicate when O_DIRECT access will
work sounds useful too, and quite easy to implement, btw.)

-- Jamie