On 2012-10-17, at 11:11 PM, Dave Chinner wrote: > So, I was bored a few days ago, and I was sick of having to run > xfs_db incorrectly report free space extents when the filesytem is > mounted, so I decided to extend fiemap to export freespace mappings > to userspace so I could get the information coherently through the > mounted filesystem. > > Yes, this could probably be considered interface abuse but, well, it > was simple to do because extent mapping is exactly what fiemap is > designed to do. Hence I didn't have to write new walkers/formatters > and I was using code I knew worked correctly. One question about the usage of this interface - is the ioctl() called on an open fd for the root inode, or is it called on any open fd in the filesystem? In some sense, getting the free space on the root (or preferably block dev inode if that would work) would make the most sense, since FIEMAP is intended to be related to a specific file. That said, it is a lot easier to use if it can be on any open file handle in the filesystem, and one could consider the free space as being related to every file in the filesystem (e.g. for the next block allocation or defrag migration). > There are two methods of mapping - one is reporting free space in > ascending extent start offset order, then other in ascending extent > length order. Both a useful to have (e.g. defragmenter might want to > know about the nearest free block to given offset or the largest > free extent in a given region). Either way, XFS keeps indexes > ordered in both ways, so they can be exported directly with minimal > overhead. > > The only "interesting" abuse of the interface is really the use of > FIEMAP_EXTENT_LAST. This means that the last extent in a freespace > index is being returned, rather than the last freespace extent. This > is done because filesystems often have multiple free space indexes, > and it may be difficult to sort/scan over multiple indexes in a > single map. I'm not sure I understand the distinction you are trying to convey here. Could you elaborate? > This means an application needs to keep track of what freespace has > been returned to it and adjust it's fiemap ranges apprpritately, or > be aware of the underlying filesystem structure to for requests that > don't span free space indexes. I don't see this a bug problem, > because any application that is digging in freespace maps needs to > know how the filesystem is structured to make any sense of the > infomration returned. As such, I see this interface purely for > filesystem diagnostics or utilities tightly bound to the filesystem > (e.g. xfs_fsr). > > I'll attach a patch for a small utility that uses this interace to > replicate the xfs_db freespace command in a short while so people > can see how it is used. that shoul dmake it easier to comment on. :) > > Cheers, > > Dave. > -- > 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 Cheers, Andreas -- 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
