From mboxrd@z Thu Jan 1 00:00:00 1970 From: Zach Brown Subject: Re: [ATTEND] Attendance request Date: Thu, 02 Feb 2012 15:51:03 -0500 Message-ID: <4F2AF737.9020106@zabbo.net> References: <4F2ABF08.60502@oracle.com> <20120202202911.GC1032@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 To: Ted Ts'o Return-path: Received: from lulu.zabbo.net ([69.168.54.52]:59707 "EHLO lulu.zabbo.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1756480Ab2BBUvG (ORCPT ); Thu, 2 Feb 2012 15:51:06 -0500 In-Reply-To: <20120202202911.GC1032@thunk.org> Sender: linux-fsdevel-owner@vger.kernel.org List-ID: > We should talk; I'm currently working on an async bmap function for > ext4, which I then intended to use for a modified high-level AIO > support framework that allowed for async metadata access. That is, > I'm interested in solving the "AIO isn't really 'A'" problem. Well, for that one blocking case in the submission path. I certainly understand the desire to just make things less painful in this case, but I do wonder if the long-term win is to sink resources into trying to get threads executings async op so that the code paths don't have to be butchered into state machines around each potential blocking op. It's a lot of work to get it transparent and efficient, I know. But then we'd be out of the business of obfuscating our code paths. - z