On Mon, Jul 07, 2008 at 07:01:24PM -0400, jim owens wrote: > Anton Altaparmakov wrote: > >> It is completely irrelevant whether the information is still valid >> after the fiemap returns. > > So if that is true, any XFS utility that does more than PRINT > the extent map based on doing JUST a fiemap is subject to > erronious results. No, that's an incorrect conclusion. The fact that the file can change *after* the mapping is done is taken into account by the application. The XFS utilities assume that the mapping is atomic, but can change after the mapping has been taken. Indeed, there's usually bigger issues to deal with than this e.g. defrag has to deal with the file not changing for the entire copy process, not just the mapping part. e.g., xfs_fsr uses atomic primitives and inode change detection to avoid the need exclusively lock out all other access whilst doing the defragmentation..... > I agree with everyone who says that to do useful work with > the output of fiemap, you need a set of syscall functions > that have this effect: > > mandatory_exclusive_file_lock(); > [optional] fsync(); or force_allocation(); > fiemap(); > [do ugly userspace stuff] > release_mandatory_exclusive_file_lock(); Yes, but file locking and application level synchronisation is outside the scope of the fiemap syscall. I'm not disagreeing that this is not needed, just that such application level synchronisation has no direct relevance to the fiemap API. OTOH, an atomic sync+map is relevant fiemap as this is the only API that can provide it. We often do stuff with atomic primitives to avoid unnecessary and/or expensive locking and that's all this is - an atomic mapping primitive. You may not consider it useful, but some of us do.... Cheers, Dave. -- Dave Chinner david@xxxxxxxxxxxxx -- 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
