linux-kernel - RE: Please further explain Linux's "zoned storage" roadmap [was: Re: [PATCH v14 00/13] support zoned block devices with non-power-of-2 zone sizes]

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: <BYAPR04MB4968EB5E341049DFF973B9B1F1519@BYAPR04MB4968.namprd04.prod.outlook.com>
Date:   Fri, 23 Sep 2022 06:29:41 +0000
From:   Matias Bjørling <Matias.Bjorling@....com>
To:     Bart Van Assche <bvanassche@....org>,
        Damien Le Moal <damien.lemoal@...nsource.wdc.com>,
        Mike Snitzer <snitzer@...hat.com>,
        Pankaj Raghav <p.raghav@...sung.com>
CC:     "agk@...hat.com" <agk@...hat.com>,
        "snitzer@...nel.org" <snitzer@...nel.org>,
        "axboe@...nel.dk" <axboe@...nel.dk>, "hch@....de" <hch@....de>,
        "pankydev8@...il.com" <pankydev8@...il.com>,
        "gost.dev@...sung.com" <gost.dev@...sung.com>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "linux-nvme@...ts.infradead.org" <linux-nvme@...ts.infradead.org>,
        "linux-block@...r.kernel.org" <linux-block@...r.kernel.org>,
        "dm-devel@...hat.com" <dm-devel@...hat.com>,
        Johannes Thumshirn <Johannes.Thumshirn@....com>,
        "jaegeuk@...nel.org" <jaegeuk@...nel.org>
Subject: RE: Please further explain Linux's "zoned storage" roadmap [was: Re:
 [PATCH v14 00/13] support zoned block devices with non-power-of-2 zone sizes]

> -----Original Message-----
> From: Bart Van Assche <bvanassche@....org>
> Sent: Friday, 23 September 2022 01.56
> To: Damien Le Moal <damien.lemoal@...nsource.wdc.com>; Mike Snitzer
> <snitzer@...hat.com>; Pankaj Raghav <p.raghav@...sung.com>
> Cc: agk@...hat.com; snitzer@...nel.org; axboe@...nel.dk; hch@....de;
> pankydev8@...il.com; gost.dev@...sung.com; linux-kernel@...r.kernel.org;
> linux-nvme@...ts.infradead.org; linux-block@...r.kernel.org; dm-
> devel@...hat.com; Johannes Thumshirn <Johannes.Thumshirn@....com>;
> jaegeuk@...nel.org; Matias Bjørling <Matias.Bjorling@....com>
> Subject: Re: Please further explain Linux's "zoned storage" roadmap [was: Re:
> [PATCH v14 00/13] support zoned block devices with non-power-of-2 zone
> sizes]
> 
> On 9/21/22 16:55, Damien Le Moal wrote:
> > But again, that all depends on if Pankaj patch series is accepted,
> > that is, on everybody accepting that we lift the power-of-2 zone size
> constraint.
> 
> The companies that are busy with implementing zoned storage for UFS devices
> are asking for kernel support for non-power-of-2 zone sizes.
> 
> Thanks,
> 
> Bart.

Hi Bart,

With UFS, in the proposed copy I have (may been changed) - there's the concept of gap zones, which is zones that cannot be accessed by the host. The gap zones are essentially "LBA fillers", enabling the next writeable zone to start at a X * pow2 size offset. My understanding is that this specific approach was chosen to simplify standardization in UFS and avoid updating T10's ZBC with zone capacity support. 

While UFS would technically expose non-power of 2 zone sizes, they're also, due to the gap zones, could also be considered power of 2 zones if one considers the seq. write zone + the gap zone as a single unit. 

When I think about having UFS support in the kernel, the SWR and the gap zone could be represented as a single unit. For example:

UFS - Zone Report
  Zone 0: SWR, LBA 0-11
  Zone 1: Gap, LBA 12-15
  Zone 2: SWR, LBA 16-27
  Zone 3: Gap, LBA 28-31
  ...

Kernel representation - Zone Report (as supported today)
  Zone 0: SWR, LBA 0-15, Zone Capacity 12
  Zone 1: SWR, LBA 16-31, Zone Capacity 12
  ...

If doing it this way, it removes the need for filesystems, device-mappers, user-space applications having to understand gap zones, and allows UFS to work out of the box with no changes to the rest of the zoned storage eco-system. 

Has the above representation been considered?

Best, Matias