From mboxrd@z Thu Jan 1 00:00:00 1970 From: James Bottomley Subject: Re: Use case for "loop: Issue O_DIRECT aio with pages"? Date: Fri, 02 Mar 2012 14:50:02 -0600 Message-ID: <1330721402.2786.68.camel@dabdike.int.hansenpartnership.com> References: <20120301231524.GG32588@thunk.org> <20120302141433.GE5054@shiny> Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit Cc: Ted Ts'o , Zach Brown , Dave Kleikamp , linux-fsdevel@vger.kernel.org, James Bottomley To: Chris Mason Return-path: Received: from bedivere.hansenpartnership.com ([66.63.167.143]:54082 "EHLO bedivere.hansenpartnership.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755653Ab2CBUuF (ORCPT ); Fri, 2 Mar 2012 15:50:05 -0500 In-Reply-To: <20120302141433.GE5054@shiny> Sender: linux-fsdevel-owner@vger.kernel.org List-ID: On Fri, 2012-03-02 at 09:14 -0500, Chris Mason wrote: > On Thu, Mar 01, 2012 at 06:15:24PM -0500, Ted Ts'o wrote: > > > >My latest focus is on completing the work started on by Zach Brown to > > > >add a kernel interface to allow kernel code to submit aio, and having > > > >the loop device submit direct IO requests to the underlying file system. > > > > So I've been taking a lot at your patch series, and one of the things > > which would help me understand the requirements behind what you are > > doing is *why* is it interesting to allow kernel code to submit aio > > requests, and loop devices to be able to direct I/O requests all the > > way to the underlying file systems. In other words, what's the use > > case that you're most interested in that these patches would enable? > > I'll let James talk about the parallels use case, which includes some > nice building blocks on top of just exporting a file as a block device. Our use case is even more simple: containers are a simple slicing up of the existing operating system sharing the same kernel. There are performance impacts (mostly because the journal becomes a hot spot) from running a bunch of containers in a single filesystem as chroots (the current setup), so we want to transition to an image file based system like VMs use. To do that we need a device mapping to an image file per container and, since we don't have a hypervisor, the only way to do this today is via loop. We basically want to redo the current loop device to make it far more performant (get rid of double caching using DIO etc.) and, of course, less crash prone. James