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. -- 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
