Re: [RFC] add FIEMAP ioctl to efficiently map file allocation

On 3 May 2007, at 08:49, Andreas Dilger wrote:

On May 02, 2007  20:57 +1000, David Chinner wrote:

quoted

On Wed, May 02, 2007 at 10:36:12AM +0100, Anton Altaparmakov wrote:

quoted

HSM_READ is definitely _NOT_ required because all
it means is "if the file is OFFLINE, bring it ONLINE and then return
the extent map".

You've got the definition of HSM_READ wrong. If the flag is *not*
set, then we bring everything back online and return the full extent
map.

Specifying the flag indicates that we do *not* want the offline
extents brought back online.  i.e. it is a HSM or a datamover
(e.g. backup program) that is querying the extents and we want to
known *exactly* what the current state of the file is right now.

So, if the HSM_READ flag is set, then the application is
expecting the filesytem to be part of a HSM. Hence if it's not,
it should return an error because somebody has done something wrong.

In my original proposal I specifically pointed out that the
FIEMAP_FLAG_HSM_READ has the OPPOSITE behaviour as the  
XFS_IOC_GETBMAPX
BMV_IF_NO_DMAPI_READ flag.  Data is retrieved from HSM only if the
HSM_READ flag is set.  That's why the flag is called "HSM_READ"  
instead
of "HSM_NO_READ".

Cool.  I did not misunderstand after all then. (-:

The reason is that it seems bad if the default behaviour for calling
ioctl(FIEMAP) would be to force retrieval of data from HSM, and  
this is
only disabled by specifying a flag.  It makes a lot more sense to just
leave the data as it is and return the extent mapping by default (i.e.
this is the principle of least surprise).  It would probably be  
equally
surprising and undesirable if the default behaviour was to force all
data out to HSM.

For that matter, I'm also beginning to wonder if the FLAG_HSM_READ  
should
even be a part of this interface?  I have no problem with returning a
flag that reports if the data is migrated to HSM and whether it is  
UNMAPPED.

Having FIEMAP force the retrieval of data from HSM strikes me as  
something
that should be a part of a separate HSM interface, which also needs  
to be
able to do things like push specific files or parts thereof out to  
HSM,
set the aging policy, and return information like "where does the HSM
file live" and "how many copies are there".

That would seem sensible to me also.  Just like David argued that  
causing the data to be in a fixed location should be a separate  
interface rather than part of FIEMAP so by analogy the same should  
apply to touching HSM.

Best regards,

	Anton
-- 
Anton Altaparmakov <aia21 at cam.ac.uk> (replace at with @)
Unix Support, Computing Service, University of Cambridge, CB2 3QH, UK
Linux NTFS maintainer, http://www.linux-ntfs.org/