On Jul 03, 2008 16:17 +0100, Jamie Lokier wrote: > jim owens wrote: > > FIEMAP_EXTENT_NO_BYPASS > > > > As in "you can't bypass the filesystem" to directly access it. > > Can we also commit to this, when FIEMAP_EXTENT_NO_BYPASS is *not* set: > > 1. The data at fe_physical, and *will not move* so long as nothing > modifies *that particular file*? > > 2. Both reading *and writing* the file bypassing the filesystem are ok. I don't think any such guarantee can be made. What if the file is truncated and rewritten after the FIEMAP is called? The filesystem can't guarantee that will not happen. I think the only way to make sure of constant mapping is to call FIEMAP before and after the blocks are read. > The reason for 2 is that some filesystems checksum the data and/or > replicate it, and won't be readable if you write to it directly. EEEEEK. The _intent_ of FIEMAP is mostly for reporting fragmentation, and possibly to allow a "generic" defragmenter to be written. At an outside stretch I could imagine some tools like "dump" wanting direct read access to the file data. Directly writing underneath a filesystem is major bad news and will likely corrupt the filesystem because you can never be sure that there aren't dirty pages in the page cache that will overwrite your "direct" write, or that your write isn't racy with an unlink or truncate. 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
