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 -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
