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=-4.1 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS, URIBL_BLOCKED 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 D9004C433DF for ; Fri, 31 Jul 2020 07:58:57 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id B80AC20829 for ; Fri, 31 Jul 2020 07:58:57 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="cqcr9/BG" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1731706AbgGaH6x (ORCPT ); Fri, 31 Jul 2020 03:58:53 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:47080 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1731684AbgGaH6w (ORCPT ); Fri, 31 Jul 2020 03:58:52 -0400 Received: from mail-wm1-x341.google.com (mail-wm1-x341.google.com [IPv6:2a00:1450:4864:20::341]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 7B01BC061574; Fri, 31 Jul 2020 00:58:52 -0700 (PDT) Received: by mail-wm1-x341.google.com with SMTP id g8so7782904wmk.3; Fri, 31 Jul 2020 00:58:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=cTyazyYhJvUjN7a2Z4vhY4OPwuV7RiSwhqqKSl6uwS4=; b=cqcr9/BGTVGV5eLNZYxJLpiQ9zQ9uUBx0U9phhALKfBmj3H1Ly5IjBDuCR8W6fB43t Z/+OylPZCJR+MuNTHsIH2hggC/RuHaGQ6B0nlf/ZI0AcnhG1twITAS4fET/myTe8HQ9c l33p4GTO7epKW9P+rpzY85naKonMEwkUBVbxsuQ4TQVmlJaGYBj3cjymi5aglGlEPS4Q 6scVBWiakVdV5WPNCQ8JNjoiQQFRRTfxiIyP/1DmUnZn4f93aE0oR8gSLGC5s79KaOYD s1aXsGM6/VUA6w8NHWBfjIjWPFWhxFPsIq5yNMQqlyXoH/cmzyoPY1mKaOlwAzpuXNAN BXZA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=cTyazyYhJvUjN7a2Z4vhY4OPwuV7RiSwhqqKSl6uwS4=; b=rosesuFqrodKRlgvhlzq4nhl8nWOnv+CQYPAaflh7RWZWLCgCs3L3IyAeYKlCKVq6z RSZR7jLjsJ8tiABwovNJOTX/wWM7n66DGZrZDhxo9xlSeS8Ni6iqy8zX46MG4s3yyfLE LkXKSG9qg7gq8Pfr4Dr72E/JsB7aBQ3lbBRm5QLh3QF/zAPhAKikOZJ3wWoaFyEvhczX LzRAW12y/LzS7freXEOl0YPwaei2nN7lRMB/dKCkC+AakWGu/9xAxpZQTNAjy8pVS6z9 Tior3FCvb1+RpCIV6JI5KBrCqoGGfVASSkdQWRzeLzaojhfuWI1ttE0k7n+5IdduhLvX eI/w== X-Gm-Message-State: AOAM533sIU6CM9qFHWx/jshyL7IyyNqvYFqi62+Xovv3iy49rf4xmrVu NJeDLAu0a6ILRzC633d1CtEXSJT1g2im+T9WWpA= X-Google-Smtp-Source: ABdhPJxNw7Svuw5TllltfhvwrWmcKb/9/XdA7oHnRTAloSkB3rov2jCYV3IjcA5AbRGDfz1qzi3lBfppauTNKt8MG64= X-Received: by 2002:a05:600c:21cd:: with SMTP id x13mr2898582wmj.155.1596182331066; Fri, 31 Jul 2020 00:58:51 -0700 (PDT) MIME-Version: 1.0 References: <80d27717-080a-1ced-50d5-a3a06cf06cd3@kernel.dk> <65a7e9a6-aede-31ce-705c-b7f94f079112@kernel.dk> <20200731064526.GA25674@infradead.org> In-Reply-To: From: Kanchan Joshi Date: Fri, 31 Jul 2020 13:28:24 +0530 Message-ID: Subject: Re: [PATCH v4 6/6] io_uring: add support for zone-append To: Damien Le Moal Cc: "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 Content-Type: text/plain; charset="UTF-8" Sender: io-uring-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: io-uring@vger.kernel.org On Fri, Jul 31, 2020 at 12:29 PM Damien Le Moal wrote: > > On 2020/07/31 15:45, hch@infradead.org wrote: > > On Fri, Jul 31, 2020 at 06:42:10AM +0000, Damien Le Moal wrote: > >>> - We may not be able to use RWF_APPEND, and need exposing a new > >>> type/flag (RWF_INDIRECT_OFFSET etc.) user-space. Not sure if this > >>> sounds outrageous, but is it OK to have uring-only flag which can be > >>> combined with RWF_APPEND? > >> > >> Why ? Where is the problem ? O_APPEND/RWF_APPEND is currently meaningless for > >> raw block device accesses. We could certainly define a meaning for these in the > >> context of zoned block devices. > > > > We can't just add a meaning for O_APPEND on block devices now, > > as it was previously silently ignored. I also really don't think any > > of these semantics even fit the block device to start with. If you > > want to work on raw zones use zonefs, that's what is exists for. > > Which is fine with me. Just trying to say that I think this is exactly the > discussion we need to start with. What interface do we implement... > > Allowing zone append only through zonefs as the raw block device equivalent, all > the O_APPEND/RWF_APPEND semantic is defined and the "return written offset" > implementation in VFS would be common for all file systems, including regular > ones. Beside that, there is I think the question of short writes... Not sure if > short writes can currently happen with async RWF_APPEND writes to regular files. > I think not but that may depend on the FS. generic_write_check_limits (called by generic_write_checks, used by most FS) may make it short, and AFAIK it does not depend on async/sync. 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 block-device these checks are not done, but there is another place when it receives writes spanning beyond EOF and iov_iter_truncate() adjusts it before sending it down. And we return failure for that case in V4- "Ref: [PATCH v4 3/6] uio: return status with iov truncation" -- Joshi