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.
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
>
--
, _ _ ,
{ \/`o;====- Olga Kryzhanovska -====;o`\/ }
.----'-/`-/ olga.kryzhanovska at gmail.com \-`\-'----.
`'-..-| / Solaris/BSD//C/C++ programmer \ |-..-'`
/\/\ /\/\
`--` `--`
