From mboxrd@z Thu Jan 1 00:00:00 1970 From: Dave Kleikamp Subject: Re: [RFC] unifying write variants for filesystems Date: Mon, 03 Feb 2014 10:50:02 -0600 Message-ID: <52EFC8BA.3010906@oracle.com> References: <20140114172033.GU10323@ZenIV.linux.org.uk> <20140118064040.GE10323@ZenIV.linux.org.uk> <20140118074649.GF10323@ZenIV.linux.org.uk> <20140118201031.GI10323@ZenIV.linux.org.uk> <20140119051335.GN10323@ZenIV.linux.org.uk> <20140120135514.GA21567@infradead.org> <20140201224301.GS10323@ZenIV.linux.org.uk> <20140203151242.GA6868@infradead.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Cc: Jens Axboe , Sage Weil , Mark Fasheh , xfs@oss.sgi.com, Steve French , Kent Overstreet , Joel Becker , linux-fsdevel , Linus Torvalds , Anton Altaparmakov To: Christoph Hellwig , Al Viro Return-path: In-Reply-To: <20140203151242.GA6868@infradead.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: xfs-bounces@oss.sgi.com Sender: xfs-bounces@oss.sgi.com List-Id: linux-fsdevel.vger.kernel.org On 02/03/2014 09:12 AM, Christoph Hellwig wrote: > On Sat, Feb 01, 2014 at 10:43:01PM +0000, Al Viro wrote: >> * WTF bother passing 'pos' separately? It's the same mistake that was >> made with ->aio_read/->aio_write and just as with those, *all* callers >> provably have pos == iocb->ki_pos. > > I think this landed with the initial aio support, which planned for > allowing AIO retries for a workqueue with a partially incremented > pos. None of this ever got merged, probably because it was too ugly > to live. Yeah, when these patches were first written, AIO looked a lot different. >> * We *definitely* want a variant structure with tag - unsigned long thing >> was just plain insane. I see at least two variants - array of iovecs >> and array of (at least) triples . Quite possibly - >> quadruples, with "here's how to try to steal this page" thrown in, if >> we want that as replacement for ->splice_write() as well (it looks like >> the few instances that do steal on pipe-to-file splices could be dealt >> with the same way as the dumb ones, provided that ->write_iter or whatever >> we end up calling it is allowed to try and steal pages). Possibly more >> variants on the read side of things... FWIW, I'm not sure that bio_vec >> makes a lot of sense here. > > bio_vec just is one of the many page+offset+len containers we have, I > guess Dave took it because loop uses it. We could either invent a new > one here or finally have a common one for the different uses all over > the kernel. With Kent's immutable bio_vec changes, peeking inside the bio to get to the bio_vec is uglier than it was before, so there's no need to stick with that. Shaggy _______________________________________________ xfs mailing list xfs@oss.sgi.com http://oss.sgi.com/mailman/listinfo/xfs