On Jan 31, 2023 / 01:37, Shinichiro Kawasaki wrote: > On Jan 30, 2023 / 10:33, Niklas Cassel wrote: [...] > > > > I understand that you change the way that the accounting works, but > > I don't think that we should just totally change the definition of an > > existing option just because we think it should have been defined in > > another way. > > > > Can't you: > > -Change the accounting > > -Clarify the definition of the option, but keep it like it is, > > regardless if it causes zone lock contention or not. > > In case we would keep the current definition (accounting per job), still we can > avoid the wrong accounting and the zone lock contention by checking write range > overlap. If the option is specified together with multiple jobs with overlapping > write ranges, fio can error out so that users can know that the option does not > work as expected. However, I am reluctant to take this approach since its use > cases are limited (no write range overlap) and it adds 8 bytes to the struct > fio_file only for the option. > > > -Implement a new option that might be more optimal, and does not > > cause zone lock contention? > > This sounds good to me. The new option name can be zone_reset_threshold_per_dev. > > > -Potentially deprecate or remove the old zone_reset_threshold option. > > Yes, if we introduce the new option, I prefer to remove the old option. After further consideration, it does not look good to change the zone_reset_threshold option to the new one. I will post v2 series which keeps the definition of the option as it is, and resolves the issues with a different approach. -- Shin'ichiro Kawasaki
