Re: [PATCH] block: align max append sectors to physical block size

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

 



On 2020/07/20 20:08, hch@xxxxxxxxxxxxx wrote:
> On Fri, Jul 17, 2020 at 10:55:49AM +0000, Damien Le Moal wrote:
>>>
>>> 2) add one new limit for write on seq zone, such as: zone_write_block_size
>>>
>>> Then the two cases can be dealt with in same way, and physical block
>>> size is usually a hint as Christoph mentioned, looks a bit weird to use
>>> it in this way, or at least the story should be documented.
>>
>> Yeah, but zone_write_block_size would end up always being equal to the physical
>> block size for SMR. For ZNS and nullblk, logical block size == physical block
>> size, always, so it would not be useful. I do not think such change is necessary.
> 
> I think we should add a write_block_size (or write_granularity) field.
> There have been some early stage NVMe proposal to add that even for
> conventional random/write namespaces.

OK. We can add that easily enough. The default value will be the logical block
size and only ZBC/ZAC SMR drives will need to set that to the physical block size.

But for regular 4Kn drives, including all logical drives like null_blk, I think
it would still be nice to have a max_hw_sectors and max_sectors aligned on 4K.
We can enforce that generically in the block layer when setting these limits, or
audit drivers and correct those setting weird values (like null_blk). Which
approach do you think is better ?


-- 
Damien Le Moal
Western Digital Research




[Index of Archives]     [Linux RAID]     [Linux SCSI]     [Linux ATA RAID]     [IDE]     [Linux Wireless]     [Linux Kernel]     [ATH6KL]     [Linux Bluetooth]     [Linux Netdev]     [Kernel Newbies]     [Security]     [Git]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Device Mapper]

  Powered by Linux