On 2020/04/22 3:05, Pierre Labat (plabat) wrote: > Hi, > > We (Micron San Jose CA) have a few FIO changes to propose. The general goal > of these changes is to increase the test coverage for zoned devices. Below is > a summary. > > 1. A ZNS namespace has a maximum number of open zones (aka number of zones > one can write in parallel) that may be smallish. There is another ZNS > limitation that is the maximum number of "active" zones (active=zone in > state open or closed). This number can be much bigger than the maximum number > of open zones. > > This Fio change allows to test the device in regards to this maximum number > of active zones. > > Fio is given a maximum number of active zones. The threads/jobs (their number > is limited to the maximum number open zones) write a bit into one active > zone, close it, jumps to another active zone (open it (write implicit open)) > and so on. The writing threads keep ping ponging across the active zones > writing a bit each time and then closing the zone. An active zone is > re-opened when a writing thread write again in the zone (implicit open). As a > consequence, the write load is spread across all active zones while never > passing the max number of active zones. When you say "close the zone" do you mean an explicit close ? If yes, that is one more system call (ioctl) and NVMe command to issue for every single write command. Performance will be horrible. > Then at some point some active zones get full. When that happens they are > not "active" anymore. Fio selects other zones automatically, they will become > active on the first write. As a consequence, over time, the active zones move > across the namespace (but they stay in the window specified by fio). That > gives a good workout to the device running it at its max limit of active > zones and jumping (to write in a zone) at high rate from one zone to > another. All of this is the exact description (minus the "close the zone") of what the current max_open_zone=X option does. It will select X zones for writing and will keep writing these zones until they are full, at which point, other zones are selected. This means that you will always get the number of active zones and the number of implicitly open zones to be equal. If the fio command line specifies max_open_zones=X with X <= max active zones for the device, there will be no write IO rejected by the drive. > > 2. An application can "finish" a zone without writing it in full. For example > an app could only write half a zone and then finish it. That changes the > state of the zone to "full". The app cannot write anymore in the zone. The > zone will have to be reset at some point. > > We have a change in FIO that allows to test that. A new option tells FIO to > stop writing in a zone when reaching some threshold and to "finish" it. At > that point, FIO sends a zone management command to finish the zone and > consider the zone full (even if it is not actually full of app data). We could indeed add this fairly easily as that is how zone reset rate also works. However, I personally do not see any good use case for the finish operation. "because we can" not being the best justification for new code, it may be good to put forward a use case. Of note is that fio is a performance measurement tool, not a drive test tool, so implementing this for "testing" the finish operation does not sound to me like a good idea either. > 3. Another change is relaxing the checks in zbd_verify_sizes() in regards to > read IO on zoned devices. The reading can start anywhere in a zone (below the > WP), it doesn't need to always start at the zone beginning. This is indeed true for sequential read workloads. But not for random reads. Are you referring to sequential read ? That should be easy to fix, but again, the usefulness of this is not clear to me. > I would have to move these changes on latest fio and do some cleanup before > having patches ready. ZNS needs zone capacity support too. We have patches ready to go for that one. Waiting for kernel side patches first though, otherwise, testing is not possible. > > Let me know if that make sense to add the above to fio. > > Best regards, > > Pierre > > -- Damien Le Moal Western Digital Research
