From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-3.8 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,USER_AGENT_GIT autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id A7993ECE58D for ; Wed, 9 Oct 2019 20:41:33 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 8C374218DE for ; Wed, 9 Oct 2019 20:41:33 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728804AbfJIUlc (ORCPT ); Wed, 9 Oct 2019 16:41:32 -0400 Received: from mx2.suse.de ([195.135.220.15]:46526 "EHLO mx1.suse.de" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1730955AbfJIUlc (ORCPT ); Wed, 9 Oct 2019 16:41:32 -0400 X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.220.254]) by mx1.suse.de (Postfix) with ESMTP id 759F7AF6B; Wed, 9 Oct 2019 20:41:30 +0000 (UTC) Received: by quack2.suse.cz (Postfix, from userid 1000) id 1CB231E422A; Wed, 9 Oct 2019 22:41:30 +0200 (CEST) From: Jan Kara To: Cc: Christoph Hellwig , darrick.wong@oracle.com, , Matthew Bobrowski , Jan Kara Subject: [PATCH 0/2] iomap: Waiting for IO in iomap_dio_rw() Date: Wed, 9 Oct 2019 22:41:24 +0200 Message-Id: <20191009202736.19227-1-jack@suse.cz> X-Mailer: git-send-email 2.16.4 Sender: linux-xfs-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-xfs@vger.kernel.org Hello, when doing the ext4 conversion of direct IO code to iomap, we found it very difficult to handle inode extension with what iomap code currently provides. Ext4 wants to do inode extension as sync IO (so that the whole duration of IO is protected by inode->i_rwsem), also we need to truncate blocks beyond end of file in case of error or short write. Now in ->end_io handler we don't have the information how long originally the write was (to judge whether we may have allocated more blocks than we actually used) and in ->write_iter we don't know whether / how much of the IO actually succeeded in case of AIO. Thinking about it for some time I think iomap code makes it unnecessarily complex for the filesystem in case it decides it doesn't want to perform AIO and wants to fall back to good old synchronous IO. In such case it is much easier for the filesystem if it just gets normal error return from iomap_dio_rw() and not just -EIOCBQUEUED. The first patch in the series adds argument to iomap_dio_rw() to wait for IO completion (internally iomap_dio_rw() already supports this!) and the second patch converts XFS waiting for unaligned DIO write to this new API. What do people think? Honza