linux-kernel - Re: [PATCH v4 00/13] support non power of 2 zoned devices

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20220517091834.dvkrab5l63v3b2zn@ArmHalley.local>
Date:   Tue, 17 May 2022 11:18:34 +0200
From:   Javier González <javier.gonz@...sung.com>
To:     Christoph Hellwig <hch@....de>
CC:     Pankaj Raghav <p.raghav@...sung.com>, <axboe@...nel.dk>,
        <damien.lemoal@...nsource.wdc.com>, <pankydev8@...il.com>,
        <dsterba@...e.com>, <linux-nvme@...ts.infradead.org>,
        <linux-fsdevel@...r.kernel.org>, <linux-btrfs@...r.kernel.org>,
        <jiangbo.365@...edance.com>, <linux-block@...r.kernel.org>,
        <gost.dev@...sung.com>, <linux-kernel@...r.kernel.org>,
        <dm-devel@...hat.com>
Subject: Re: [PATCH v4 00/13] support non power of 2 zoned devices

On 17.05.2022 10:10, Christoph Hellwig wrote:
>I'm a little surprised about all this activity.
>
>I though the conclusion at LSF/MM was that for Linux itself there
>is very little benefit in supporting this scheme.  It will massively
>fragment the supported based of devices and applications, while only
>having the benefit of supporting some Samsung legacy devices.

I believed we had agreed that non-power-of-2 zoned devices was something
to explore. Let me summarize the 3 main points we covered at different
times at LSF/MM:

   - This is not for legacy Samsung ZNS devices. At least 4 other
     vendors have reported building non-power-of-2 ZNS devices to meet
     customer demands on removing holes in the address space. It seems
     like there will be more ZNS devices with size=capacity out there
     than with PO2 sizes. Block device and FS support is very desirable
     for these.

   - We also talked about how the capacity not being a PO2 is the one
     introducing the fragmentation, as applications that already worked
     with SMR HDDs will have to change their data placement policy. The
     size is just a construction, but the real work is adopting the
     capacity.

   - Besides the previous poit, the fragmentation will happen from the
     moment we have available devices. This is not a kernel-only issue.
     We have SMR, ZNS, and soon another spec for zone devices. I
     understood that as long as we do not break any existing support, we
     would be able to expend the zoned ecosystem in Linux.

>So my impression was that this work, while technically feasible, is
>rather useless.  So unless I missed something important I have no
>interest in supporting this in NVMe.

Does the above help you reconsidering your interest in supporting this
in NVMe?