On Jan 19 10:38, Niklas Cassel wrote: > Hello all, > > > When testing with the ZNS code that is in nvme-next, > I can zone append, targeting the first zone by specifying zslba 0, > and then just put that call it in a while loop, it will > manage to fill up not just zone0, but the whole drive. > > Since zslba is defined as: > "Zone Start Logical Block Address (ZSLBA): This field indicates the 64-bit > address of the lowest logical block of the zone in which the data and > metadata, if applicable, associated with this command is to be stored." > > Should an append that specifies zslba 0 (== zone 0), be allowed > to write into zone 1 (and beyond). > > According to 2.3.1.1 "Writing in Sequential Write Required Zones", > we should get either a "Zone Boundary Error" or "Zone Is Full" error, > depending on zone 0 write pointer, combined with how many LBAs we try > to append. > > > Looking at the code, I think that this has to be handled in > either nvme_check_zone_write() or nvme_advance_zone_wp(). > > Considering that Dmitry and Klaus were discussing when to advance > the write pointer, etc, for several of the patch series revisions, > I think it is better to leave a potential fix to you guys. >
Right. The reason we're not getting a zone boundary error is because the boundary condition is checked before assigning an LBA, so we always check against ZSLBA. I can see that in my old branch I'm checking the write *after* assigning the SLBA, so it didn't exhibity that behavior. I'll draw up a fix based on that. Thanks Niklas!
signature.asc
Description: PGP signature