Received: by 2002:a05:6a10:a0d1:0:0:0:0 with SMTP id j17csp3192672pxa; Tue, 18 Aug 2020 08:52:21 -0700 (PDT) X-Google-Smtp-Source: ABdhPJx7XGwLO647jsWX7r1cnxKVtUjY92wF/PlZjMHrd5RRk0Mss4EBak1n1zLk8Gqz837XuaLS X-Received: by 2002:a17:906:d288:: with SMTP id ay8mr20406506ejb.373.1597765941345; Tue, 18 Aug 2020 08:52:21 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1597765941; cv=none; d=google.com; s=arc-20160816; b=Bc4y6dDU8O/GEiZlLrYxp71ZrhDdwuFrv7umXDRqil5VTXon9opNeiTkZjV1mgBSpf Zi3HCTYoLy/DLHI2wsDVQ/rZa/zp9P11pvcU+hPwjteBLrglFhgC6uNO1S+/+tfBCoBb y2bkk/MUZEBc3+qHZJz0P3mnmxVW+OX03lx0FXhj67YwvfQO4uCDzGaFx060fNZJquMN B5M7reZXa+nnNHCtQPxfJu6hvJOA1frDAS0xHb46EwoX2ZZWlDxXggJqzZYaGUS381ni w4CRpNzdCx9sB8AA9YZZ6elxf9Ui8YXe3gVp4d694RGRiPCbeil4FpQpgvj2Jpy/5WaQ S10w== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date; bh=eptm71g210Dq8Rv4OPb+PjuavEd1Ut6jFEaNej3I9C8=; b=CEdKxinMR5uMfEKBoFvHWRLxZlVhmppXl86DM0/vSpuWD5TZezz0oKrNN83QmOqA65 L2XQNM99LupHa1crFDtvs5DuMpeg1WQiekbTnHHGb5GmW9iPBvgxt7n/iD1ji1xUalAN RbrRQEz/QWw88IOwb+XC7KDKaIgb6T/cWa08cq7ouYikDa8HUi3owWA4CclBkWOVOWln PKuQVeN+AdPlSV+07B2N92lXlPNQrfmc133mtoKYff9qknHK1L2WGBQTr9kXwajmgiOz aq3P17IlzMy5GCJL9EYT7BGHtmn8trzQ5xh8oZOgNgYCCgKSmL5/ItqA0Pq+EVXwD9aR Rk6A== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id v24si13633709ejo.749.2020.08.18.08.51.57; Tue, 18 Aug 2020 08:52:21 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726588AbgHRPvH (ORCPT + 99 others); Tue, 18 Aug 2020 11:51:07 -0400 Received: from verein.lst.de ([213.95.11.211]:34034 "EHLO verein.lst.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727929AbgHRPuN (ORCPT ); Tue, 18 Aug 2020 11:50:13 -0400 Received: by verein.lst.de (Postfix, from userid 2407) id C273F68AFE; Tue, 18 Aug 2020 17:50:04 +0200 (CEST) Date: Tue, 18 Aug 2020 17:50:04 +0200 From: Christoph Hellwig To: Javier Gonzalez Cc: Christoph Hellwig , Kanchan Joshi , kbusch@kernel.org, Damien.LeMoal@wdc.com, axboe@kernel.dk, sagi@grimberg.me, linux-nvme@lists.infradead.org, linux-kernel@vger.kernel.org, johannes.thumshirn@wdc.com, Nitesh Shetty , SelvaKumar S Subject: Re: [PATCH 2/2] nvme: add emulation for zone-append Message-ID: <20200818155004.GA26688@lst.de> References: <20200818052936.10995-1-joshi.k@samsung.com> <20200818052936.10995-3-joshi.k@samsung.com> <20200818071249.GB2544@lst.de> <20200818095033.h6ybdwiq3ljagl5a@mpHalley.local> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20200818095033.h6ybdwiq3ljagl5a@mpHalley.local> User-Agent: Mutt/1.5.17 (2007-11-01) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Aug 18, 2020 at 11:50:33AM +0200, Javier Gonzalez wrote: > I understand that the NVMe process was agitated and that the current ZNS > implementation in Linux relies in append support from the device > perspective. However, the current TP does allow for not implementing > append, and a number of customers are requiring the use of normal > writes, which we want to support. The NVMe TPs allow for lots of things, but that doesn't mean we have to support it. > Do you have any early suggestion on how you this patch should look like > to be upstreamable? My position is that at this point in time we should not consider it. Zone Append is the major feature in ZNS that solves the issue in ZAC/ZBC. I want to see broad industry support for it instead of having to add more code just for zone append emulation than actual current ZNS support. If in a few years the market place has decided and has lots of drives available in the consuer market or OEM channels we'll have to reconsider and potentially merge Zone Append emulation. But my deep hope is that this does not happen, as it sets us back 10 years in the standards of zoned storage support again.