From mboxrd@z Thu Jan 1 00:00:00 1970 From: Christoph Hellwig Subject: Re: [RFC] unifying write variants for filesystems Date: Mon, 3 Feb 2014 07:12:42 -0800 Message-ID: <20140203151242.GA6868@infradead.org> 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> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Cc: Jens Axboe , Dave Kleikamp , Sage Weil , Christoph Hellwig , Mark Fasheh , xfs@oss.sgi.com, Steve French , Joel Becker , linux-fsdevel , Linus Torvalds , Anton Altaparmakov To: Al Viro Return-path: Content-Disposition: inline In-Reply-To: <20140201224301.GS10323@ZenIV.linux.org.uk> 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 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. > * 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. _______________________________________________ xfs mailing list xfs@oss.sgi.com http://oss.sgi.com/mailman/listinfo/xfs