On 04/21, Damien Le Moal wrote: > On 4/21/23 08:44, Bart Van Assche wrote: > > On 4/20/23 16:37, Damien Le Moal wrote: > >> Why would you need to handle the max active zone number restriction in the > >> scheduler ? That is the user responsibility. btrfs does it (that is still buggy > >> though, working on it). > > > > Hi Damien, > > > > If the user (filesystem) restricts the number of active zones, the code > > for restricting the number of active zones will have to be duplicated > > into every filesystem that supports zoned devices. Wouldn't it be better > > if the I/O scheduler tracks the number of active zones? > > I do not think so. The reason is that for a file system, the block allocator > must be aware of any active zone limit of the underlying device to make the best > decision possible regarding where to allocate blocks for files and metadata. For Well, I'm wondering what kind of decision FS can make when allocating zones? > btrfs, we added "active block groups" management for that purpose. And we have > tracking of a block group active state so that the block allocator can start > using new block groups (inactive ones) when previously used ones become full. We > also have a "finish block group" for cases when there is not enough remaining > free blocks in a group/zone (this does a finish zone operation to make a > non-full zone full, that is, inactive). > > Even if the block IO scheduler were to track active zones, the FS would still > need to do its own tracking (e.g. to be able to finish zones when needed). So I Why does FS also need to track the # of open zones redundantly? I have two concerns if FS needs to force it: 1) performance - waiting for finish_zone before allocating a new zone can break the IO pipeline and block FS operations. 2) multiple partition support - if F2FS uses two partitions, one on conventional partition while the other on zoned partition, we have to maintain such tracking mechanism on zoned partition only which gives some code complexity. In general, doesn't it make sense that FS (not zoned-device FS) just needs to guarantee sequential writes per zone, while IO scheduler needs to limit the # of open zones gracefully? > do not see the point in having the block scheduler doing anything about active > zones. >
