Taking another run at this based on all the feedback (much appreciated). - Replaced rtdefault with rtdisable, this yields similar operational benefits when combined with the existing mkfs time setting of the inheritance flag on the root directory. Allows temporary disabling of real-time allocation without having to walk entire FS to remove flags (which could be time consuming). I still don't think it's super obvious to an admin the real-time flag was put there at mkfs time (vs. rtdefault being in mount flags), but this gets me half of what I'm after. - rtstatfs flag is removed, instead per Dave's suggestion we look for the inheritance flag on the directory inode, if so we fill the statfs struct with the real-time block info, otherwise data block info. Open to making this behavior a flag if folks are worried it might be a jarring change to folks used to the old behavior (i.e. data device info no matter what). - rtfallocmin no changes, need to think more about this. Still a pretty big fan of this option for reasons already stated; at least until a more elegant solution such as preferred AGs (we'd need a tunable size for the "preferred" AG, since our SSD partitions are a fraction of the size of a normal AG) can be implemented. The only other idea I have is to make a new ioctl e.g. "norealtime", which causes the RT bits to stay cleared regardless of inheritance bits on the containing directory. This would allowing the "steering" of files to the data device (e.g. SSD); this is probably a safer design than defaulting to SSD and steering to the HDD via the realtime ioctl. Richard Wareing (3): fs/xfs: Add rtdisable option fs/xfs: Add real-time device support to statfs fs/xfs: Add rtfallocmin mount option fs/xfs/xfs_file.c | 16 ++++++++++++++++ fs/xfs/xfs_inode.c | 6 ++++-- fs/xfs/xfs_ioctl.c | 7 +++++-- fs/xfs/xfs_mount.h | 2 ++ fs/xfs/xfs_super.c | 33 ++++++++++++++++++++++++++++++++- 5 files changed, 59 insertions(+), 5 deletions(-) -- 2.9.3 -- To unsubscribe from this list: send the line "unsubscribe linux-xfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
