On Tue, Aug 29, 2017 at 09:03:08AM -0700, Darrick J. Wong wrote: > First, should we land the incore extent map rework (not that I've seen a > patchset yet) so that the increased extent map fragmentation resulting > from cow/dedupe don't overwhelm the memory allocator with high order > allocations? Incore extent map memory usage hasn't been an issue here... Working on this now, but so far this hasn't been a major issue. The main workload where the extent list currently hurts and that prompted my work in this area doesn't even involve reflinks (sparse VM image). > Second, regarding realtime + reflink: Right now we don't forbid mounting > a filesystem with reflink enabled and a realtime device. You can't have > an inode with both realtime and reflink flags set, so if future xfs > supports it, old kernels won't totally stumble over those inodes. > (Though, EFSCORRUPTED is a little rude.) Is that ok? or should we (a) > make reflink work on realtime devices, (b) complain at mount time, or > (c) leave everything the way it is? I think the current situation is fine - if we add reflinks on the RT device we can just add a ROCOMPAT flag. -- 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
