On Fri, Jul 04, 2008 at 01:13:25PM +0100, Jamie Lokier wrote: > Dave Chinner wrote: > > The point of this SYNC flag is to ensure that you get nothing other > > than blocks mapped to disk - no delalloc regions, etc. The only sane > > way to do that is an atomic 'sync+map' operation. This is not a > > filesystem specific feature - it's what the SYNC flag should be > > defined as providing. > > Wait a minute. > > I think Jim, and you Dave, have imagined different use-cases > for FIEMAP - and that's the reason for this difference of opinion. > > The two use-cases are: > > 1. To get a detailed fragmentation report, which is guidance (and > can only be guidance: it may be invalid the moment it's returned). > > 2. To get a block mapping suitable for _reading_ those blocks from > the physical device directly (e.g. LILO). > > For 1, atomic 'sync+map' does make sense, if you want the report to > not have any delalloc extents, and you want to operate on files which > are being modified by other processes. > > For 2, Jim appears to be correct that atomic 'sync+map' is not useful. > You can only read blocks if the mapping remains stable after returning > it, which means the application _must_ ensure no process is modifying > the file, and that it's on a filesystem which doesn't arbitrarily move > blocks when it feels like it. Given that, > 'make_sure_nothing_modifies; atomic(sync + map); read data; > ok_you_can_modify' is no different from 'make_sure_nothing_modifies; > fsync(); map; read data; ok_you_can_modify'. Like: # xfs_freeze -f <mntpt> # xfs_bmap -vvp <file> # <do something nasty with direct block access> # xfs_freeze -u <mntpt> > You've explained that it does provide a > guarantee: the resulting map will be valid for a consistent snapshot > of the file at some instant in time during the FIEMAP call. In other > words, with concurrent modifiers, atomic sync+map ensures no delalloc > regions (is there anything else?) in the map, while fsync() + map gets > close but does not ensure it. Synchronisation with direct I/O, ensures unwritten extent conversion completion with concurrent async direct I/O before mapping, space preallocation, etc. > Dave, can you give an actual situation where you have seen atomic > 'sync+map' used with XFS where it is necessary for an application to > behave correctly? The only application that uses the XFS ioctls are xfs utilities, and they tend to work around the assumption that the mapping operation returns a consistent map at the time the call was made. > I'm having trouble thinking of one, other than "the > current app code doesn't know what to do with a delalloc extent". No, the XFS utilities want to know mappings, not delalloc extents - i.e. they want to know where on disk stuff is, not where in memory it is. That being said, there have been times when I've wanted to know what ranges of the file were on disk or in memory when analysing problems... 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
