On Fri, Mar 04, 2022 at 02:10:08PM -0800, Luis Chamberlain wrote: > On Fri, Mar 04, 2022 at 11:10:22AM +1100, Dave Chinner wrote: > > On Wed, Mar 02, 2022 at 04:56:54PM -0800, Luis Chamberlain 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. > > > > Reading through the discussion on this thread, perhaps this session > > should be used to educate application developers about how to use > > ZoneFS so they never need to manage low level details of zone > > storage such as enumerating zones, controlling write pointers > > safely for concurrent IO, performing zone resets, etc. > > I'm not even sure users are really aware that given cap can be different > than zone size and btrfs uses zone size to compute size, the size is a > flat out lie. Sorry, I don't get what btrfs does with zone management has anything to do with using Zonefs to get direct, raw IO access to individual zones. Direct IO on open zone fds is likely more efficient than doing IO through the standard LBA based block device because ZoneFS uses iomap_dio_rw() so it only needs to do one mapping operation per IO instead of one per page in the IO. Nor does it have to manage buffer heads or other "generic blockdev" functionality that direct IO access to zoned storage doesn't require. So whatever you're complaining about that btrfs lies about, does or doesn't do is irrelevant - Zonefs was written with the express purpose of getting user applications away from needing to directly manage zone storage. SO if you have special zone IO management requirements, work out how they can be supported by zonefs - we don't need yet another special purpose direct hardware access API for zone storage when we already have a solid solution to the problem already. > modprobe null_blk nr_devices=0 > mkdir /sys/kernel/config/nullb/nullb0 > echo 0 > /sys/kernel/config/nullb/nullb0/completion_nsec > echo 0 > /sys/kernel/config/nullb/nullb0/irqmode > echo 2 > /sys/kernel/config/nullb/nullb0/queue_mode > echo 1024 > /sys/kernel/config/nullb/nullb0/hw_queue_depth > echo 1 > /sys/kernel/config/nullb/nullb0/memory_backed > echo 1 > /sys/kernel/config/nullb/nullb0/zoned > > echo 128 > /sys/kernel/config/nullb/nullb0/zone_size > # 6 zones are implied, we are saying 768 for the full storage size.. > # but... > echo 768 > /sys/kernel/config/nullb/nullb0/size > > # If we force capacity to be way less than the zone sizes, btrfs still > # uses the zone size to do its data / metadata size computation... > echo 32 > /sys/kernel/config/nullb/nullb0/zone_capacity Then that's just a btrfs zone support bug where it's used the wrong information to size it's zones. Why not just send a patch to fix it? Cheers, Dave. -- Dave Chinner david@xxxxxxxxxxxxx
