From mboxrd@z Thu Jan 1 00:00:00 1970 From: Zach Brown Subject: Re: Use case for "loop: Issue O_DIRECT aio with pages"? Date: Thu, 01 Mar 2012 21:49:41 -0500 Message-ID: <4F503545.8030308@zabbo.net> References: <20120301231524.GG32588@thunk.org> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Dave Kleikamp , linux-fsdevel@vger.kernel.org, Chris Mason To: Ted Ts'o Return-path: Received: from lulu.zabbo.net ([69.168.54.52]:34782 "EHLO lulu.zabbo.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1757080Ab2CBCto (ORCPT ); Thu, 1 Mar 2012 21:49:44 -0500 In-Reply-To: <20120301231524.GG32588@thunk.org> Sender: linux-fsdevel-owner@vger.kernel.org List-ID: > *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 believe one motivations for using loopback files is the ability to use ocfs2's reflinks to get cluster-wide cow snapshoting of guest file systems in files in ocfs2. But I'll let Dave (or Chris?) share more about how this stuff is actually used. Really, if we had our way, file systems would offer the bio submission and completion interface for file data. Then loopback dev IO <-> file system IO would be trivial. The aio+dio iocbs are an existing aproximation :/. - z