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 Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 19321C433FE for ; Fri, 30 Sep 2022 19:38:57 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229594AbiI3Tiz (ORCPT ); Fri, 30 Sep 2022 15:38:55 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:43898 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232376AbiI3Tiy (ORCPT ); Fri, 30 Sep 2022 15:38:54 -0400 Received: from mail-pj1-f46.google.com (mail-pj1-f46.google.com [209.85.216.46]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id D112C149780; Fri, 30 Sep 2022 12:38:52 -0700 (PDT) Received: by mail-pj1-f46.google.com with SMTP id l12so4952850pjh.2; Fri, 30 Sep 2022 12:38:52 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:in-reply-to:from:references:cc:to :content-language:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date; bh=gjDYcfQrPymPgf4zZHF6ExZnXFdO/ag78V3ukKEreZ8=; b=kb10rTWlUKTqJRtFUDbI2061gIYzUD719SiT2UKCGXQdo7XP3i1nx7UE5sII7iW6CQ fEr/CLkfds3t/VHl+4+rGM+6A01b87uRLNMgv7kxF3R5uFhUT/YFxil67oMyjjvxMdcr qvGu97KngDV4Mv5SGmhqKL9OUKDTJLXZWwvOEPsEm2PR++etO1w/1MLcuA2kTin98sub hQ8isdmZPD6NujUgigIuUNEYNbrwhOz7JBIcLosjeaXSgYu68/PyVIyHXaLcbe4nsyfx Kb1sUWNFc/E/nEyjUdaDtLYvHiTha96qUwa8RZef4qRnSr/+bg9y+iWLqW9aHOORtssj rPZg== X-Gm-Message-State: ACrzQf2FFeInIXQiZTKPK3pOsN/3Top2QCWFt1df7J6KxxAf5LKxLorc Y1IlR/gDxyiUeg4AlqpHxoM= X-Google-Smtp-Source: AMsMyM6wPTQbb/wpm4NYDTyzteu9Ju/f5nYNm4NlJda34lAJsiPgMThwpAp8l1Io6xLGw26w5R/LwQ== X-Received: by 2002:a17:90b:3149:b0:202:e9e9:632f with SMTP id ip9-20020a17090b314900b00202e9e9632fmr24463065pjb.96.1664566732077; Fri, 30 Sep 2022 12:38:52 -0700 (PDT) Received: from ?IPV6:2620:15c:211:201:56f2:482f:20c2:1d35? ([2620:15c:211:201:56f2:482f:20c2:1d35]) by smtp.gmail.com with ESMTPSA id z5-20020aa79f85000000b0052e6c058bccsm2187903pfr.61.2022.09.30.12.38.49 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 30 Sep 2022 12:38:51 -0700 (PDT) Message-ID: <0e5088a5-5408-c5bd-bf97-00803cb5faed@acm.org> Date: Fri, 30 Sep 2022 12:38:48 -0700 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.13.0 Subject: Re: [PATCH v15 00/13] support zoned block devices with non-power-of-2 zone sizes Content-Language: en-US To: Jens Axboe , Pankaj Raghav , hch@lst.de, Keith Busch Cc: jaegeuk@kernel.org, agk@redhat.com, gost.dev@samsung.com, snitzer@kernel.org, damien.lemoal@opensource.wdc.com, linux-kernel@vger.kernel.org, hare@suse.de, matias.bjorling@wdc.com, Johannes.Thumshirn@wdc.com, linux-block@vger.kernel.org, linux-nvme@lists.infradead.org, pankydev8@gmail.com, dm-devel@redhat.com, "Martin K. Petersen" References: <20220923173618.6899-1-p.raghav@samsung.com> <5e9d678f-ffea-e015-53d8-7e80f3deda1e@samsung.com> From: Bart Van Assche In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Precedence: bulk List-ID: X-Mailing-List: linux-block@vger.kernel.org On 9/30/22 08:13, Jens Axboe wrote: > On 9/29/22 12:31 AM, Pankaj Raghav wrote: >>> Hi Jens, >>> Please consider this patch series for the 6.1 release. >>> >> >> Hi Jens, Christoph, and Keith, >> All the patches have a Reviewed-by tag at this point. Can we queue this up >> for 6.1? > > It's getting pretty late for 6.1 and I'd really like to have both Christoph > and Martin sign off on these changes. Hi Jens, Agreed that it's getting late for 6.1. Since this has not been mentioned in the cover letter, I want to add that in the near future we will need these patches for Android devices. JEDEC is working on supporting zoned storage for UFS devices, the storage devices used in all modern Android phones. Although it would be possible to make the offset between zone starts a power of two by inserting gap zones between data zones, UFS vendors asked not to do this and hence need support for zone sizes that are not a power of two. An advantage of not having to deal with gap zones is better filesystem performance since filesystem extents cannot span gap zones. Having to split filesystem extents because of gap zones reduces filesystem performance. Thanks, Bart.