On Thu, Jan 28, 2016 at 05:16:56AM -0800, Christoph Hellwig wrote: > Any chance to get a review for this? It should really help > with sorting out the buffered I/O COW code. > I haven't taken a closer look at the patch yet. I was kind of waiting for Dave to chime in because I'm a little confused over the back and forth nature of dio/ioend completion lately. My understanding is that the original requirement for ioends here was to track the state necessary in order to defer (to wq) completions that had to allocate transactions. Eventually, the deferred buffer state was implemented and we no longer required an ioend for that, so we removed the ioends here: 2ba6623 xfs: don't allocate an ioend for direct I/O completions Then just a couple months later, we merged the following to re-add the ioend into the dio path: d5cc2e3f xfs: DIO needs an ioend for writes I recall reviewing that one, but looking back afaict the ioend was used simply to enable reuse of the ioend completion code. Now we have this patch which presumably removes much of that code to eliminate the ioend allocation overhead. Neither this patch nor the previous has any technical reasoning for one approach over the other in the commit logs, so afaics this appears to be a matter of preference. Can we get some agreement (or discussion) on what the right interface is to transfer information to dio completion? E.g., is this allocation overhead noticeable? Is ioend usage problematic for other reasons (such as copy-on-write)? Going back to the previous patch, were there explicit reasons for using ioends aside from code reuse? Note that the subsequent commit 6dfa1b67 ("xfs: handle DIO overwrite EOF update completion correctly") does refer to some problems not running dio completions in the right context... Dave? Brian > _______________________________________________ > xfs mailing list > xfs@xxxxxxxxxxx > http://oss.sgi.com/mailman/listinfo/xfs _______________________________________________ xfs mailing list xfs@xxxxxxxxxxx http://oss.sgi.com/mailman/listinfo/xfs