On 04/24, Christoph Hellwig wrote: > On Sat, Apr 22, 2023 at 07:25:33AM +0900, Damien Le Moal wrote: > > >> for allocating blocks. This is a resource management issue. > > > > > > Ok, so it seems I overlooked there might be something in the zone allocation > > > policy. So, f2fs already manages 6 open zones by design. > > > > Yes, so as long as the device allows for at least 6 active zones, there are no > > issues with f2fs. > > I don't think it's quite as rosy, because f2fs can still schedule > I/O to the old zone after already scheduling I/O to a new zone for > any of these 6 slots. It'll need code to wait for all I/O to the old > zone to finish first, similar to btrfs. F2FS should serialize all the writes across 6 active open zones. If not, I think it's a bug. The problem here is 1) open zone#1 through zone #6, 2) allocate all blocks in zone #1, 3) submit all writes in zone #1, 4) allocate blocks in zone #7, 5) submit all writes in zone #7, and so on. In this scenario, I'm asking why F2FS needs to wait for entire write completion between 3) and 4), which will impact performance a lot since 4) blocks syscalls.
