????? ???????????? wrote:
> Why is m_blksize unsigned 32bit?
> Do you want to repeat the story of '640KB are enough'?
> Please make m_blksize an uint64 for the sake of future users who want
> to address more than 4GB as block.
>
The block size is the minimum addressable unit of data. It is *not* the
maximum address. In fact, with the way this is specified, you could in
theory describe a device capable of storing 2^92 bytes of data.
Although to achieve that, you'd have to use 4GB blocks.
The largest block size in any common use today is 64K, which is far far
short of 4GB. If you had a 4GB block size, then you would *have* to
transfer full 4GB just to do a minimum read. I don't think any such
devices are likely within the next decade or three. (Maybe not ever.)
- Garrett
> On Wed, Dec 2, 2009 at 5:34 PM, Garrett D'Amore <gdamore at sun.com> wrote:
>
>> 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 ?
>>>
>>>
>> _______________________________________________
>> opensolaris-arc mailing list
>> opensolaris-arc at opensolaris.org
>>
>>
>
>
>
>
