From mboxrd@z Thu Jan 1 00:00:00 1970 From: Ted Ts'o Subject: Re: Use case for "loop: Issue O_DIRECT aio with pages"? Date: Fri, 2 Mar 2012 03:14:07 -0500 Message-ID: <20120302081407.GA22215@thunk.org> References: <20120301231524.GG32588@thunk.org> <4F503545.8030308@zabbo.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Dave Kleikamp , linux-fsdevel@vger.kernel.org, Chris Mason To: Zach Brown Return-path: Received: from li9-11.members.linode.com ([67.18.176.11]:56374 "EHLO test.thunk.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751499Ab2CBIOL (ORCPT ); Fri, 2 Mar 2012 03:14:11 -0500 Content-Disposition: inline In-Reply-To: <4F503545.8030308@zabbo.net> Sender: linux-fsdevel-owner@vger.kernel.org List-ID: On Thu, Mar 01, 2012 at 09:49:41PM -0500, Zach Brown wrote: > > >*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. > > As I understood it, lo those years ago, the use case was virtual guests > provisioned on loopback devices on files in the host file system. > > In this use case either having loop implement a second writeback cache > or having it only capable of one sync IO in flight at a time is pretty > bad when you're trying to offer consistent and performant file systems > to the guest. I'm confused though why the guests would be pointed at the loopback device, as opposed to just simply attaching to the file directly. Or is this some kind of Xen limitation? With qemu/kvm I don't see why it would make sense to indirect through the loop device.... - Ted