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]

[Matias Bjørling]

> -----Original Message-----
> From: Bart Van Assche <bvanassche at acm.org>
> Sent: Friday, 23 September 2022 01.56
> To: Damien Le Moal <damien.lemoal at opensource.wdc.com>; Mike Snitzer
> <snitzer at redhat.com>; Pankaj Raghav <p.raghav at samsung.com>
> Cc: agk at redhat.com; snitzer at kernel.org; axboe at kernel.dk; hch at lst.de;
> pankydev8 at gmail.com; gost.dev at samsung.com; linux-kernel at vger.kernel.org;
> linux-nvme at lists.infradead.org; linux-block at vger.kernel.org; dm-
> devel at redhat.com; Johannes Thumshirn <Johannes.Thumshirn at wdc.com>;
> jaegeuk at kernel.org; Matias Bjørling <Matias.Bjorling at wdc.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