Re: Question about cam 4K quirks

On 11/04/2016 15:24, Tomoaki AOKI wrote:
> Thanks for your answer!
>
> On Sun, 10 Apr 2016 16:15:56 +0100
> Steven Hartland <killing_at_multiplay.co.uk> wrote:
>
>>
>> On 10/04/2016 15:35, Tomoaki AOKI wrote:
>>> On Sun, 10 Apr 2016 06:59:04 -0600
>>> Alan Somers <asomers_at_freebsd.org> wrote:
>>>
>>>> On Sun, Apr 10, 2016 at 12:56 AM, Tomoaki AOKI <junchoon_at_dec.sakura.ne.jp>
>>>> wrote:
>>>>
>>>>> Hi. Maybe freebsd-hardware list would be the right place, but it's not
>>>>> so active. :-(
>>>>>
>>>>> Is 4K quirks needed for every HDDs/SSDs having physical sector size
>>>>> 4096?
>>>>>
>>>>> If so, I would be able to provide patch for Crucial M550 and MX200.
>>>>> (Possibly covers other models [BX200 etc.] by abstraction.)
>>>>>
>>>>>     M550(1TB):  device model          Crucial CT1024M550SSD1
>>>>>                 firmware revision     MU01
>>>>>     MX200(1TB): device model          Crucial CT1024MX200SSD1
>>>>>                 firmware revision     MU03
>>>>>       -> Abstracted with "Crucial CT*SSD*" or "Crucial CT*", as the part
>>>>>          "1024" should vary with its capacity and can be 3 to 4 digits
>>>>>          for now. I tried the former and confirmed "quirks=0x1<4K>"
>>>>>          appears, which doesn't appear without adding the entry.
>>>>>
>>>>>
>>>>> If not, is it sufficient if `camcontrol identify <device>` states
>>>>> "physical 4096" on "sector size" line for everything in kernel and
>>>>> related components (i.e., zfs-related ones)?
>>>>>
>>>>>
>>>>> Regards.
>>>> You only need quirk entries if the device fails to identify its physical
>>>> size correctly.  If "camcontrol identify" states "physical 4096", then
>>>> you're probably ok, but it's not the best place to ask.  "camcontrol
>>>> identify" asks the device directly, whereas "diskinfo -v" asks the kernel.
>>>> If "diskinfo -v" says "4096 stripesize" then you're definitely ok.
>>>>
>>>> -Alan
>>> Thanks for clarification.
>>>
>>> Tried "diskinfo -v" as you noted (of course running the kernel without
>>> adding quirks entry) and confirmed it saying "4096 # stripesize".
>>> So it's already OK with current ata_da.c and scsi_da.c (no quirks is
>>> needed).
>>>
>>> OTOH, trying with Samsung 850 evo (the last one I have for now,
>>> having quirks entry in current source), "diskinfo -v" says "4096
>>> # stripesize" while "camcontrol identify" says "physical 512".
>>> This should be why quirks entries are needed (and implemented) for it.
>> Correct, manufactures took the cop out route and return 512 for both
>> logical and physical sizes to avoid issues with bad OS support.
>> SSD's a particularly lazy in this regard.
>>> I think stripesize should be primarily for RAID configuration, but
>>> after 4k physical sectored drives  (so called AFT drives) appears,
>>> applied to even for single drive configuration, too. Right?
>> stripesize simply gives a hit as to performance when accessing the device.
> So now FreeBSD's ZFS defaults ashift 12, if I remember correctly, to
> align datasets with 4k.
ZFS calculates the most suitable given the reports physical and logical 
sector sizes, technically the default is ashift 9 unless altered by 
setting vfs.zfs.min_auto_ashift.
> And UFS has minimum blocksize of 4k (defaults
> 8k). And more, now gpart can align partitions as root specifies.
>
>>> If so, as writing blocks smaller than stripesize (except for the last
>>> block of a file) is nonsense for RAID configuration, all write access
>>> to HDDs/SSDs are constrained to use stripesize for minimum block size,
>>> right?
>> Nope, sectorsize constrains that.
> So possibly some filesystems can be mis-aligned even if the start point
> is properly aligned.
>
>   *Mis-aligned fragments should be allowed, though.
>
>> stripesize is only used as a way to help tune filesystem access patterns
>> e.g. in ZFS it is used to help determine the ashift value which in turn
>> determines the minimum allocatable block size. This helps optimise
>> performance while sacrificing storage space i.e. causing wastage.
> Exactly. :-)
> But there's large possibility of severe performance degradation caused
> by mis-aligned blocks, especially in HDD, and the capacities of HDDs
> became large, even in 2.5inch form factor. Defaulting block size to
> physical sector size would be reasonable, if any option to downsize to
> 512 bytes is provided.
That would be a step back, correcting the offset would be the better fix.
>   *If I remember correctly, block size of UFS is 4096 bytes at minimum,
>    but supports 512 bytes fragments for small files (and to concentrate
>    tail portions of large files). It would be in many cases reasonable
>    trade-off, too.
I don't use UFS so couldn't comment.