On Wed, Jul 02, 2008 at 07:48:07PM -0400, jim owens wrote: > I'm back from vacation and ready to cause fiemap() trouble. > > Dave Kleikamp wrote: >> On Thu, 2008-06-26 at 09:15 -0500, Eric Sandeen wrote: >> >>>> SYNC really doesn't look like it belongs, and it's only there so that >>>> the new ioctl acts like the xfs ioctl. >>> >>> I disagree, while it may have been inspired by the xfs behavior, it's >>> not at all xfs specific. >>> >>> If a filesystem implements delalloc, you may want to know which ranges >>> are still delalloc in the fiemap output, or you may want to put them on >>> disk and know the actual physical location. And if you want a snapshot >>> of an actual, consistent layout of the file at a point in time, then you >>> need an atomic sync+map - for any filesystem. >> >> This makes sense. In fact, I could see always doing the sync if there >> are delalloc blocks to ensure that the location of the blocks will >> always be returned. >> > > I guess I was put off by Andreas' response that FIEMAP_FLAG_SYNC is >> there because xfsbmap had it "isn't harmful either". This seemed a bit >> weak, but I see that there is a better justification than just that. > > I say IT IS HARMFUL to have the FIEMAP_FLAG_SYNC. > > The email trail points out how this so-called atomic sync+map > will lead programmers to write bad code because it leads them > to think there is some valuable guarantee of consistency by > using the SYNC flag. This is not true. xfs_bmap provides an atomic sync and mapping. If the FIEMAP_FLAG_SYNC is pushed down to the filesystem, then XFS and all other filesystems can provide that same atomicity if desired. 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
