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=BAYES_00,DKIM_INVALID, DKIM_SIGNED,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS 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 9F3A1C433E1 for ; Fri, 31 Jul 2020 09:14:33 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 7F47422B40 for ; Fri, 31 Jul 2020 09:14:33 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=fail reason="signature verification failed" (2048-bit key) header.d=infradead.org header.i=@infradead.org header.b="Wb69ooOn" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1732077AbgGaJO3 (ORCPT ); Fri, 31 Jul 2020 05:14:29 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:58692 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728437AbgGaJO0 (ORCPT ); Fri, 31 Jul 2020 05:14:26 -0400 Received: from casper.infradead.org (casper.infradead.org [IPv6:2001:8b0:10b:1236::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 93E0BC061574; Fri, 31 Jul 2020 02:14:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=casper.20170209; h=In-Reply-To:Content-Type:MIME-Version: References:Message-ID:Subject:Cc:To:From:Date:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description; bh=DyRuVZfVmZ9wXsAnKUw/UMKGK/DVEVi7XnnFZ86g4Ac=; b=Wb69ooOnWGz7Vx9BWYBwagnAEF 9ZX96XA6F1W/DYv23WaUXijf6RhwSHjXkuLLG27H4Kd0LUGp2F7fhzVAfT/KghFYl9DqMzWW3Vjz/ DJaMvACKZoFV1EQ/IOxctYvT10DOg7B13E8M0MUmNguWSWijUjPcS5xQZ+USsTsitqFm94eArPrG/ 3q5G7bV7qwQkMDBFLJ3gzyEqCL3I+w8WwIGzwEErIZimbW7yZTHTFegeVHL4hoJOk+BgIlupPihjY qUBxwTDiVss3ydUiqnqSFrzEZOJPhZI5ANFelzxIy/efJEzfAIP4g8gaR3Db+UUBb0+4kaZi+grI6 2oADgoQg==; Received: from hch by casper.infradead.org with local (Exim 4.92.3 #3 (Red Hat Linux)) id 1k1R7I-0007uO-GQ; Fri, 31 Jul 2020 09:14:16 +0000 Date: Fri, 31 Jul 2020 10:14:16 +0100 From: "hch@infradead.org" To: Damien Le Moal Cc: Kanchan Joshi , "hch@infradead.org" , Jens Axboe , Pavel Begunkov , Kanchan Joshi , "viro@zeniv.linux.org.uk" , "bcrl@kvack.org" , Matthew Wilcox , "linux-fsdevel@vger.kernel.org" , "linux-kernel@vger.kernel.org" , "linux-aio@kvack.org" , "io-uring@vger.kernel.org" , "linux-block@vger.kernel.org" , "linux-api@vger.kernel.org" , SelvaKumar S , Nitesh Shetty , Javier Gonzalez , Johannes Thumshirn Subject: Re: [PATCH v4 6/6] io_uring: add support for zone-append Message-ID: <20200731091416.GA29634@infradead.org> References: <65a7e9a6-aede-31ce-705c-b7f94f079112@kernel.dk> <20200731064526.GA25674@infradead.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-SRS-Rewrite: SMTP reverse-path rewritten from by casper.infradead.org. See http://www.infradead.org/rpr.html Sender: linux-api-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-api@vger.kernel.org On Fri, Jul 31, 2020 at 08:14:22AM +0000, Damien Le Moal wrote: > > > This was one of the reason why we chose to isolate the operation by a > > different IOCB flag and not by IOCB_APPEND alone. > > For zonefs, the plan is: > * For the sync write case, zone append is always used. > * For the async write case, if we see IOCB_APPEND, then zone append BIOs are > used. If not, regular write BIOs are used. > > Simple enough I think. No need for a new flag. Simple, but wrong. Sync vs async really doesn't matter, even sync writes will have problems if there are other writers. We need a flag for "report the actual offset for appending writes", and based on that flag we need to not allow short writes (or split extents for real file systems). We also need a fcntl or ioctl to report this max atomic write size so that applications can rely on it.