Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 28 Aug 2013 13:07:34 +0100
From:      "Steven Hartland" <killing@multiplay.co.uk>
To:        "Will Andrews" <will@firepipe.net>
Cc:        scsi@freebsd.org
Subject:   Re: 8K quirks & making quirk table more structured
Message-ID:  <4B93F63AF2164724873DFAC7CF3C53E0@multiplay.co.uk>
References:  <CADBaqmibnA95T7x7UKZLYp3xZfgj0pLH00f1f%2BPEwcQbnBagmQ@mail.gmail.com><B0201D260A3B424B98AC36C27B8C0A71@multiplay.co.uk> <CADBaqmjYDPRB-d%2BL_jB4LGxXNak7Ptbf_Zb1XBfYZUb4ZYRNPg@mail.gmail.com>

next in thread | previous in thread | raw e-mail | index | archive | help
----- Original Message ----- 
From: "Will Andrews" <will@firepipe.net>
> On Sat, Aug 24, 2013 at 4:24 PM, Steven Hartland
> <killing@multiplay.co.uk> wrote:
>> That currently breaks the main reason for the output of
>> quirks in xpt_announce_quirks
> 
> The main reason for the output of quirks is for those that you can't
> find any other way.  Blocksize is something you can obtain from
> diskinfo, so what is the point of putting it in quirks?  Just to spam
> dmesg?

My current latest build (r254608) diskinfo doesn't provide stripesize
correctly, that and its another thing for admins to know about.

I know personally I've never used diskinfo, any info like that I need I
get from camcontrol devlist. Knowing the native settings vs the quirks
settings is also important, something that diskinfo doesn't provide
to my knowledge?

Having it on boot as discussed on the list before is very valuable
and not something I'd like to see removed.

>> Also it appears that the new method of setting lbppbe
>> in scsi would make the result dependent on block_len
>> which makes it potentially hard to predict the value
>> needed to set a drive to 4 etc.
> 
> A fair point.  I would prefer to address this issue in a followup
> commit, perhaps as part of harmonizing the quirk tables.  See below.

I don't see any more comments about harmonizing the quirk tables
below, did miss something?

>> In ata you use a different method entirely which its
>> not good for consistency as ideally we should have just
>> one set of quirks which work for scsi and ata.
> 
> Yes, but this problem already exists and is not made worse by this
> change.  We can debate this issue, but I consider it a separate one
> from converting the quirk entry type.

ATM you can cut and paste with a min work, with this change you
couldn't do that.

>> Also in ata you appear to have lost the output of quirks.
> 
> In ata, there aren't any quirks aside from 4K.

Yes but mentioned above its very useful and was specifically added
so again not something I'd like to see removed.

    Regards
    Steve

================================================
This e.mail is private and confidential between Multiplay (UK) Ltd. and the person or entity to whom it is addressed. In the event of misdirection, the recipient is prohibited from using, copying, printing or otherwise disseminating it or any information contained in it. 

In the event of misdirection, illegible or incomplete transmission please telephone +44 845 868 1337
or return the E.mail to postmaster@multiplay.co.uk.




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4B93F63AF2164724873DFAC7CF3C53E0>