Re: [LSF/MM/BPF BoF] BoF for Zoned Storage

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 03.03.2022 06:32, Javier González wrote:

On 3 Mar 2022, at 04.24, Luis Chamberlain <mcgrof@xxxxxxxxxx> wrote:

Thinking proactively about LSFMM, regarding just Zone storage..

I'd like to propose a BoF for Zoned Storage. The point of it is
to address the existing point points we have and take advantage of
having folks in the room we can likely settle on things faster which
otherwise would take years.

I'll throw at least one topic out:

 * Raw access for zone append for microbenchmarks:
     - are we really happy with the status quo?
   - if not what outlets do we have?

I think the nvme passthrogh stuff deserves it's own shared
discussion though and should not make it part of the BoF.

 Luis

Thanks for proposing this, Luis.

I’d like to join this discussion too.

Thanks,
Javier

Let me expand a bit on this. There is one topic that I would like to
cover in this session:

  - PO2 zone sizes
      In the past weeks we have been talking to Damien and Matias around
      the constraint that we currently have for PO2 zone sizes. While
      this has not been an issue for SMR HDDs, the gap that ZNS
      introduces between zone capacity and zone size causes holes in the
      address space. This unmapped LBA space has been the topic of
      discussion with several ZNS adopters.

      One of the things to note here is that even if the zone size is a
      PO2, the zone capacity is typically not. This means that even when
      we can use shifts to move around zones, the actual data placement
      algorithms need to deal with arbitrary sizes. So at the end of the
      day applications that use a contiguous address space - like in a
      conventional block device -, will have to deal with this.

      Since chunk_sectors is no longer required to be a PO2, we have
      started the work in removing this constraint. We are working in 2
      phases:

        1. Add an emulation layer in NVMe driver to simulate PO2 devices
	when the HW presents a zone_capacity = zone_size. This is a
	product of one of Damien's early concerns about supporting
	existing applications and FSs that work under the PO2
	assumption. We will post these patches in the next few days.

        2. Remove the PO2 constraint from the block layer and add
	support for arbitrary zone support in btrfs. This will allow the
	raw block device to be present for arbitrary zone sizes (and
	capacities) and btrfs will be able to use it natively.

	For completeness, F2FS works natively in PO2 zone sizes, so we
	will not do work here for now, as the changes will not bring any
	benefit. For F2FS, the emulation layer will help use devices
	that do not have PO2 zone sizes.

     We are working towards having at least a RFC of (2) before LSF/MM.
     Since this is a topic that involves several parties across the
     stack, I believe that a F2F conversation will help laying the path
     forward.

Thanks,
Javier




[Index of Archives]     [Linux RAID]     [Linux SCSI]     [Linux ATA RAID]     [IDE]     [Linux Wireless]     [Linux Kernel]     [ATH6KL]     [Linux Bluetooth]     [Linux Netdev]     [Kernel Newbies]     [Security]     [Git]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Device Mapper]

  Powered by Linux