[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <a68a2d40-dff4-bac6-bb05-57c5c88af66e@opensource.wdc.com>
Date: Fri, 29 Apr 2022 06:49:32 +0900
From: Damien Le Moal <damien.lemoal@...nsource.wdc.com>
To: Pankaj Raghav <p.raghav@...sung.com>, jaegeuk@...nel.org,
axboe@...nel.dk, snitzer@...nel.org, hch@....de, mcgrof@...nel.org,
naohiro.aota@....com, sagi@...mberg.me, dsterba@...e.com,
johannes.thumshirn@....com
Cc: linux-kernel@...r.kernel.org, clm@...com, gost.dev@...sung.com,
chao@...nel.org, josef@...icpanda.com, jonathan.derrick@...ux.dev,
agk@...hat.com, kbusch@...nel.org, kch@...dia.com,
linux-nvme@...ts.infradead.org, bvanassche@....org,
jiangbo.365@...edance.com, linux-fsdevel@...r.kernel.org,
matias.bjorling@....com, linux-block@...r.kernel.org
Subject: Re: [PATCH 12/16] zonefs: allow non power of 2 zoned devices
On 4/29/22 00:54, Pankaj Raghav wrote:
> On 2022-04-28 01:39, Damien Le Moal wrote:
>> On 4/28/22 01:02, Pankaj Raghav wrote:
>>> The zone size shift variable is useful only if the zone sizes are known
>>> to be power of 2. Remove that variable and use generic helpers from
>>> block layer to calculate zone index in zonefs
>>
>> Period missing at the end of the sentence.
>>
> Ack
>> What about zonefs-tools and its test suite ? Is everything still OK on
>> that front ? I suspect not...
>>
> I don't know why you assume that :). Zonefs had only one place that had
> the assumption of po2 zsze sectors:
> if (nr_zones < dev.nr_zones) {
> size_t runt_sectors = dev.capacity & (dev.zone_nr_sectors - 1);
>
> In my local tree I changed it and I was able to run zonefs tests for non
> po2 zone device. I have also mentioned it in my cover letter:
> ```
> ZoneFS:
> zonefs-tests.sh from zonefs-tools were run with no failures.
> ```
This is still not convincing given the code I saw. Additional test cases
need to be added with data verification & concurrent regular writes also
sent while doing copy to verify locking.
Which also reminds me that I have not seen any change to mq-deadline zone
write locking for this series. What is the assumption ? That users should
not be issuing writes when a copy is on-going ? What a bout the reverse
case ? at the very least, it seems that blk_issue_copy() should be taking
the zone write lock.
> I will make sure to add my private tree for zonefs in my cover letter in
> the next rev. But even without that change, a typical emulated npo2
> device should work fine because the changes are applicable only for
> "runt" zones.
--
Damien Le Moal
Western Digital Research
Powered by blists - more mailing lists