On Sep 08, 2009 09:47 +0100, Jamie Lokier wrote: > Andreas Dilger wrote: > > On Sep 07, 2009 16:26 +0000, Florian Weimer wrote: > > > * Andreas Dilger: > > > > If you are implementing a tool to use this, I would code it to try > > > > FIEMAP first, then FIBMAP (if it is running as root, or it gets > > > > fixed in some future kernel), then just do without (as it most likely > > > > does already today). > > > > > > If FIBMAP is unsafe, it's likely exposed by concurrent changes to the > > > file, so using it would still be unsafe for backup purposes. And I > > > really only need the number of the first block. (I want to optimize > > > reading of Maildir-style folders, mainly for backup purposes.) > > > > Given that the worst that can happen for your particular application > > if FIBMAP gets the wrong block number is a sub-optimal ordering for > > the file copy, there is no risk in doing this. > > > > For the FIEMAP code, since you only need the first block number, just > > pass it a single fiemap_extent so that it doesn't spend time generating > > a full list of extents that you don't need to use. > > With FIEMAP, filesystems which don't use extents will still scan a > potentially large region of the disk doing block lookups won't they, > just to maximise the size of the first extent in a large file? Partly true - if the caller only passes in space for a single extent to be returned then the traversal would stop as soon as a discontinuity is found. For ext2/ext3 this would happen at 12 blocks into the filesystem, because the first indirect block is allocated after the 12th data block, so the amount of scanning would be very small. > Assuming yes, FIBMAP would be faster than FIEMAP in those cases, which > may be a reason to give it the same permissions, so it can be used. By all means, I don't object to FIBMAP being fixed to allow non-root access, but until that happens (and then users start using those kernels) it won't work for non-root users. 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
