On Mon, Jul 07, 2008 at 05:16:50PM -0400, jim owens wrote: > Dave Chinner wrote: > >> Why? Have you ever used an extent mapping interface before? > > YES - for the past 9 years in Tru64 unix. > > Interfaces that were used by tools to defragment, print extmaps, > capture metadata for support, > perform backups > with directIO through the fs, move file extents between devices, Those are simple 'give me a mapping' cases - syncing first is appropriate for all those cases. Making it atomic so you only get blocks mapped to disk is also appropriate for all these cases.... > scan for fs errors, Deep filesystem specific knowledge is needed to do that properly, so it's not really a use case we've considered for a generic fiemap API. > allow a stacked cluster filesystem to read/write directly to > the raw device from other Tru64 nodes, Oh, that's just gross. > allow an IBM Tivoli client > to read/write directly to the raw SAN storage from anywhere, > (and probably some uses I've forgot). yes, that's a fairly common thing to do from a read-only snapshot of the filesystem. IOWs, the filesystem image is not changing so - block mapping is stable - no concurrent modifications The application has provided sane access synchronisation to the blocks, so it's not needed in fiemap. Great - your an expert in storage and you know that your application doesn't need use the FIEMAP_FLAG_SYNC.... > What I have been trying to point out in the fiemap discussion > is all learned from past mistakes. You're saying that like it's a bad thing. Learning from mistakes is how we improve things. 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
