On 2020/11/24 10:12, Dmitry Fomichev wrote: >> -----Original Message----- >> From: Damien Le Moal <Damien.LeMoal@xxxxxxx> >> Sent: Monday, November 23, 2020 7:07 PM >> To: Dmitry Fomichev <Dmitry.Fomichev@xxxxxxx>; Bart Van Assche >> <bvanassche@xxxxxxx>; Jens Axboe <axboe@xxxxxxxxx>; >> fio@xxxxxxxxxxxxxxx; Aravind Ramesh <Aravind.Ramesh@xxxxxxx>; >> Naohiro Aota <Naohiro.Aota@xxxxxxx>; Niklas Cassel >> <Niklas.Cassel@xxxxxxx> >> Cc: Shinichiro Kawasaki <shinichiro.kawasaki@xxxxxxx> >> Subject: Re: [PATCH 00/15] ZBD fixes and improvements >> >> On 2020/11/24 4:18, Dmitry Fomichev wrote: >>>> -----Original Message----- >>>> From: Bart Van Assche <bvanassche@xxxxxxx> >>>> Sent: Friday, November 20, 2020 11:01 PM >>>> To: Dmitry Fomichev <Dmitry.Fomichev@xxxxxxx>; Jens Axboe >>>> <axboe@xxxxxxxxx>; fio@xxxxxxxxxxxxxxx; Aravind Ramesh >>>> <Aravind.Ramesh@xxxxxxx>; Naohiro Aota <Naohiro.Aota@xxxxxxx>; >>>> Niklas Cassel <Niklas.Cassel@xxxxxxx> >>>> Cc: Damien Le Moal <Damien.LeMoal@xxxxxxx>; Shinichiro Kawasaki >>>> <shinichiro.kawasaki@xxxxxxx> >>>> Subject: Re: [PATCH 00/15] ZBD fixes and improvements >>>> >>>> On 11/20/20 6:45 PM, Dmitry Fomichev wrote: >>>>> This patch series contains bug fixes and refactoring changes >>>>> related to support for Zoned Block Devices (ZBD) in fio. >>>>> The highlights: >>>>> >>>>> - fix several errors related to running workloads that span >>>>> a mix of conventional zones and write pointer zones. >>>>> - improve counting of sectors with data (SWD). >>>>> - remove dependencies on particular zone types in the code. >>>>> - add code to gracefully handle offline zones. >>>> >>>> Hi Dmitry, >>>> >>>> This patch series looks interesting. Out of curiosity, do you perhaps >>>> know how much of the modified code is covered by the tests in t/zbd? >>> >>> Hi Bart, >>> >>> All tests in t/zbd are passing with this series in place. This gives us >> confidence >>> that the patches don't break anything in terms of the existing functionality. >>> Most of the bugs that are fixed in this patchset were uncovered by running >> fio in >>> environments that go beyond the scope of t/zbd tests, such as ZNS, XMR, >> some >>> specific MaxOpen values, etc. and the fixes have been verified in these >> same >>> conditions. Having said that, the newer test #48 has become a very handy >> tool >>> for identifying zone deadlocks. >>> >>> One caveat about the paragraph above - some test script modifications are >>> needed to fully cover support for offline zones and I have some patches in >> the >>> works to add such functionality. I am planning to send these in in the near >> future. >>> The current tests do pass in the case of individually injected offline zones >> on a >>> drive and this level of testing should suffice for the time being. >>> >>> One thing that I thought about while writing this email - maybe we could >> add >>> a script to run t/zbd tests on a mixed null_blk with a good amount of >> conventional >>> zones? Damien, Shinichiro, do you think that such an addition would >> improve the >>> test coverage? >> >> Yes, we should add that to run-tests-against-zoned-nullb to avoid future >> possible regressions with conventional zones. And we should make sure that >> one >> test case runs over a range of mixed conv/seq zones. >> >> Going further, I think that we should merge run-tests-against-zoned-nullb >> and >> run-tests-against-zoned-nullb into a new script run-tests-against-nullb which >> would test all device configurations: regular nullb, zoned nullb with >> conventional zones (SMR disk like device), zoned nullb with seq zones only >> and >> zone capacity < zone size (ZNS like device). With that, test coverage would be >> improved to include all recent changes. > > I was thinking about adding a meta-script that would invoke the existing two > and some new scripts, but we could just merge all of them like you suggested. > The entire test would consist of several sections and each of them would run > the entire test-zbd-support script against different null_blk configurations. > I'll try to come up with something like that... This leaves the question - should > such a script be posted separately or be included in this series. IMO, it should > be a separate patch(set). Merging the scripts is I think better than adding yet another one: it becomes easy to understand which one to run :) If Jens is OK with it, I think sending the test changes as follow-up patches is fine so that we do not delay merging this series. > >> >>> >>> Best regards, >>> Dmitry >>> >>>> >>>> Thanks, >>>> >>>> Bart. >>> >> >> >> -- >> Damien Le Moal >> Western Digital Research > -- Damien Le Moal Western Digital Research
