> Firstly, most behavior-changing fm_flags have been removed. We're > left with SYNC and XATTR now. This is a very good thing because frankly, I > think fiemap should be targeted as a straight-forward and relatively > uncomplicated API for exposing extents as they appear on disk. Think "one > notch above extent-based FIBMAP replacement". There's a flip side to this - > 'complicated' file systems should be free to implement their own > complementary ioctls where there is a unique need that FIEMAP does not > address. Things like non-trivial device mappings, encryption specifics > (beyond 'this extent is encrypted'), don't belong here. Keeping the SYNC and XATTR flags seems contradictory to above statement. If more complicated filesystems are encouraged to implement their own ioctls for non-generic things, then why does the new syscall need to support xfs-specific things so that you can supersede its existing ioctl? Honestly, I can see XATTR used generically, even though most filesystems don't store the XATTR as a tree. (jfs stores it in a single extent.) SYNC really doesn't look like it belongs, and it's only there so that the new ioctl acts like the xfs ioctl. Shaggy -- David Kleikamp IBM Linux Technology Center -- 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
