4K is probably too conservative, it only applies if you have a
swap-backed vn device at the bottom, which would be a truly
weird thing to do with vinum.

Don't spend too much time on tracking the sector size yet.  I think
the si_bsize stuff needs some thinking before we do more with it.


In message <[EMAIL PROTECTED]>, Greg Lehey writes:
>On Thursday, 26 August 1999 at 16:25:14 -0700, Matthew Dillon wrote:
>>>>>      int devminor;                                            /* minor number */
>>>>>      devminor = minor(dev);
>>>>> +    dev->si_bsize_phys = DEV_BSIZE;
>>>>> +    dev->si_bsize_best = BLKDEV_IOSIZE;
>>>>> +    dev->si_bsize_max = MAXBSIZE;
>>>> Bingo!  Thank you.
>>> Cool, I expect grog will commit it soon.
>So did I until I read this message.
>>     The patch for ccd is not quite right.  Here is the patch from my
>>     big fat patch at
>>     The problem is that you cannot simply set the physical sector
>>     size to DEV_BSIZE if the underlying device has a larger sector
>>     size.  If you do, specfs's blocksize alignment (another fix in
>>     my big fat patch) will be incorrect and result in an I/O error
>>     on the physical media.
>>     For example, swap-backed VN devices have a sector size of one page,
>>     i.e. 4K.
>Vinum currently doesn't track the sector size of the drives.  I'll
>have to put some code in there to DTRT.  In the meantime, I'll set
>si_bsize_best to 4K in the hope that this will be OK.  Are there any
>larger block sizes in current use?
>See complete headers for address, home page and phone numbers
>finger [EMAIL PROTECTED] for PGP public key

Poul-Henning Kamp             FreeBSD coreteam member
[EMAIL PROTECTED]               "Real hackers run -current on their laptop."
FreeBSD -- It will take a long time before progress goes too far!

To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Reply via email to