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

[Andreas Dilger <adilger@Sun.COM>]

On Jun 26, 2008  13:19 +0100, Jamie Lokier wrote:
> Andreas Dilger wrote:
> > "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.

Well, in most cases the physical addresses are valid (except if
FIEMAP_EXTENT_NET), but the point of NO_DIRECT is that if some
application were to read the data directly from disk (e.g. lilo,
or dump) it won't necessarily get the data it expects.

I agree the name is a bit confusing, and maybe a clarification should
be made w.r.t. the fact it has nothing to do with O_DIRECT, but I
can't think of a better name for it.  The NO_DIRECT flag will normally
have another qualifier that explains why it isn't directly accessible,
but apps which don't care WHY it isn't accessible don't need to check
for each of those flags.

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

There is already the FIEMAP_EXTENT_NOT_ALIGNED flag, which is the
opposite of what you ask for - it marks extents that are not properly
aligned to block boundaries:

	* FIEMAP_EXTENT_NOT_ALIGNED
	Extent offsets and length are not guaranteed to be block aligned.


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