Re: [PATCH 09/11] block: Introduce zone write pointer offset caching

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 2020/03/11 15:24, Christoph Hellwig wrote:
> On Wed, Mar 11, 2020 at 12:34:33AM +0000, Damien Le Moal wrote:
>> Yes, I agree with you here. That would be nicer, but early attempt to do so
>> failed as we always ended up with potential races on number of zones/wp array
>> size in the case of a device change/revalidation. Moving the wp array allocation
>> and initialization to blk_revalidate_disk_zones() greatly simplifies the code
>> and removes the races as all updates to zone bitmaps, wp array and nr zones are
>> done under a queue freeze all together. Moving the wp array only to sd_zbc, even
>> using a queue freeze, leads to potential out-of-bounds accesses for the wp array.
>>
>> Another undesirable side effect of moving the wp array initialization to sd_zbc
>> is that we would need another full drive zone report after
>> blk_revalidate_disk_zones() own full report. That is costly. On 20TB SMR disks
>> with more than 75000 zones, the added delay is significant. Doing all
>> initialization within blk_revalidate_disk_zones() full zone report loop avoids
>> that added overhead.
> 
> That explanation needs to got into the commit log.
> 

OK. Will do.

-- 
Damien Le Moal
Western Digital Research




[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [SCSI Target Devel]     [Linux SCSI Target Infrastructure]     [Kernel Newbies]     [IDE]     [Security]     [Git]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux ATA RAID]     [Linux IIO]     [Samba]     [Device Mapper]

  Powered by Linux