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

[James Bottomley <James.Bottomley@HansenPartnership.com>]

On Sat, 2022-03-05 at 08:33 +0100, Javier González wrote:
[...]
> However, there is no users of ZoneFS for ZNS devices that I am aware
> of (maybe for SMR this is a different story).  The main open-source
> implementations out there for RocksDB that are being used in
> production (ZenFS and xZTL) rely on either raw zone block access or
> the generic char device in NVMe (/dev/ngXnY). This is because having
> the capability to do zone management from applications that already
> work with objects fits much better.
> 
> My point is that there is space for both ZoneFS and raw zoned block
> device. And regarding !PO2 zone sizes, my point is that this can be
> leveraged both by btrfs and this raw zone block device.

This is basically history repeating itself, though.  It's precisely the
reason why Linux acquired the raw character device: Oracle decided they
didn't want the OS abstractions in the way of fast performing direct
database access and raw devices was the way it had been done on UNIX,
so they decided it should be done on Linux as well.  There was some
legacy to this as well: because Oracle already had a raw handler they
figured it would be easy to port to Linux.

The problem Oracle had with /dev/raw is that they then have to manage
device discovery and partitioning as well.  It sort of worked on UNIX
when you didn't have too many disks and the discover order was
deterministic.  It began to fail as disks became storage networks.  In
the end, when O_DIRECT was proposed, Oracle eventually saw that using
it on files allowed for much better managed access and the raw driver
fell into disuse and was (finally) removed last year.

What you're proposing above is to repeat the /dev/raw experiment for
equivalent input reasons but expecting different outcomes ... Einstein
has already ruled on that one.

James