On Mon, Mar 07, 2022 at 06:12:29PM +1100, Dave Chinner wrote: > The generic interface that the kernel provides for zoned storage is > called ZoneFS. Forget about the fact it is a filesystem, all it > does is provide userspace with a named zone abstraction for a zoned > device: every zone is an append-only file. We seem to be reaching consensus on a path forward to use ZoneFS for raw access. > > 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. > > On that I disagree - any argument that starts with "we need raw > zoned block device access to ...." is starting from an invalid > premise. This seems reasonable given the possibility to bring folks forward with ZoneFS. > We should be hiding hardware quirks from userspace, not > exposing them further. ZoneFS requires a block device and such block device cannot be exposed if the zone size != PO2. So sadly ZoneFS cannot be used by !PO2 ZNS drives. > IMO, we want writing zone storage native applications to be simple > and approachable by anyone who knows how to write to append-only > files. We do not want such applications to be limited to people who > have deep and rare expertise in the dark details of, say, largely > undocumented niche NVMe ZNS specification and protocol quirks. > > ZoneFS provides us with a path to the former, what you are > advocating is the latter.... That surely simplifies things if we can use ZoneFS! Some filesystems who want to support zone storage natively have been extended to do things to help with these quirks. My concerns were the divergence on approaches to how filesystems use ZNS as well. Do you have any plans to consider such efforts for XFS or would you rather build on ZoneFS somehow? Luis
