Okay, I'm going to propose solving this properly. The solution is that
the following structure:
struct bd_media {
uint64_t m_nblks;
boolean_t m_readonly;
};
Will grow a new member expressing the block size:
struct bd_media {
uint64_t m_nblks;
uint32_t m_blksize;
boolean_t m_readonly;
};
*However*, in order to keep things simple and efficient in the code, the
rule is that the blksize *must* be a power of two. If the block size is
not a power of two, then the driver will have to do the RMW thing to
fake one up. (With the associated performance penalties.)
This should allow non-spinning media to work fine with blkdev, even with
larger block sizes.
Note that I can only test 512 byte blocks, so architecturally the
solution will be complete, but the resulting code *may* have bugs that I
won't know about until we have media with larger block size requirements.
- Garrett
Darren J Moffat wrote:
> Garrett D'Amore wrote:
>> Darren J Moffat wrote:
>>> With the updated name I have only one possible small issue.
>>>
>>> You said the driver is hardcoded to 512 byte blocks, yet the
>>> industry is moving towards 4k blocks. Is that likely to be an issue
>>> for devices driven by 'blkdev' ?
>>
>> I don't think so. If the application (or other code) issues smaller
>> I/Os, the underlying driver will have to implement as RMW. If the
>> filesystem or app code uses 4K aligned and sized buffers, then there
>> won't be a need to do RMW.
>
> I understood how that side would work.
>
>> We might need to change the code slightly to express the 4K size in
>> the various ioctls, but that can happen latter when I run into such a
>> device. (The current devices supported by this device driver all use
>> 512 byte blocks.)
>
> My concern is when there are devices that use 4K size blocks instead
> of 512 byte blocks. Is there anything in the architecture of bd that
> means they can't easily be supported by this bd driver ?
>
