On Sun, Jan 03, 2016 at 04:20:58AM -0800, Christoph Hellwig wrote: > I really don't like the separate XFS_IOEND_COW flag. This should > be an ioend type just like XFS_IO_DELALLOC, XFS_IO_UNWRITTEN and > XFS_IO_OVERWRITE. We might need some work in the direct I/O > completions for that to really work, though. The COW completion is an ioend flag (instead of an ioend type) *because* of how I thought directio completions work. :) It looked to me like you could only have one ioend for a dio, and that there wasn't a clean way to make XFS have multiple ioends for a particular dio. Since the remap operation remaps everything it finds in the COW fork for a given part of a file and leaves the rest alone, it seemed natural to encode COW as a flag in the ioend, leave the ioend type as XFS_IO_OVERWRITE, and try to have as few ioends as possible. For dio writes I can COW write almost as fast as a regular overwrite. I further observed with the RFCv3 COW (which did have a separate ioend type for COW) that random writes had a tendency to create a /lot/ of ioends. If you let all these writes accumulate and then flushed them out with a single fsync, the scatteredness of the COW blocks caused the creation of a lot of ioends, which then caused a thundering herd when all those ioends had to be pushed separately through the workqueue. Changing the ioend handling to the way it is in RFCv4 greatly reduced the number of ioends that have to be processed, and dramatically improved write speeds. (I also fixed a bug where it would create ioends for each COW block in a streaming write; both fixes make v4's COW 5x faster on a ramdisk than v3's.) Did I overlook some subtlety with ioends? So far it's worked fine as-is. --D > > _______________________________________________ > xfs mailing list > xfs@xxxxxxxxxxx > http://oss.sgi.com/mailman/listinfo/xfs _______________________________________________ xfs mailing list xfs@xxxxxxxxxxx http://oss.sgi.com/mailman/listinfo/xfs
