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

Javier González
2022-03-07T14:35:19Z

> On 7 Mar 2022, at 14.55, James Bottomley <James.Bottomley@hansenpartnership.com> wrote:
>
> ﻿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.

Thanks for the history on the raw device. It’s good to the perspective on history repeating itself.

I believe that the raw block device is different than the raw character device and we see tons of applications that don’t want FS semantics relying on them. But I get your point.

If we agree to get ZoneFS up to speed and use it as the general API for zone devices, then I think we can refocus there.

As I mentioned in the last reply to to Dave, the main concern for me at the moment is supporting arbitrary zone sizes in the kernel. If we can agree on a path towards that, we can definitely commit to focus on ZoneFS and implement support for it on the different places we maintain in user-space.