Date: Fri, 12 Sep 2014 11:11:35 +0200 From: Willem Jan Withagen <wjw@digiware.nl> To: Steven Hartland <killing@multiplay.co.uk>, Peter Wemm <peter@wemm.org>, freebsd-stable@freebsd.org Cc: Andriy Gapon <avg@freebsd.org>, Aristedes Maniatis <ari@ish.com.au> Subject: Re: getting to 4K disk blocks in ZFS Message-ID: <5412B8C7.3000803@digiware.nl> In-Reply-To: <A74B16E4AB0B4B3384E1936963123928@multiplay.co.uk> References: <540FF3C4.6010305@ish.com.au> <A0A549F7A4094F519A3660697AB4983F@multiplay.co.uk> <54114029.3060507@FreeBSD.org> <2128347.Ah5i0RTCvp@overcee.wemm.org> <541230F1.3060402@digiware.nl> <EC1EE440B161449CA1A578DBCCEEA274@multiplay.co.uk> <5412AED7.9040903@digiware.nl> <A74B16E4AB0B4B3384E1936963123928@multiplay.co.uk>
next in thread | previous in thread | raw e-mail | index | archive | help
On 12-9-2014 10:52, Steven Hartland wrote:
>
> ----- Original Message ----- From: "Willem Jan Withagen" <wjw@digiware.nl>
> To: "Steven Hartland" <killing@multiplay.co.uk>; "Peter Wemm"
> <peter@wemm.org>; <freebsd-stable@freebsd.org>
> Cc: "Andriy Gapon" <avg@freebsd.org>; "Aristedes Maniatis" <ari@ish.com.au>
> Sent: Friday, September 12, 2014 9:29 AM
> Subject: Re: getting to 4K disk blocks in ZFS
>
>
>> On 12-9-2014 10:17, Steven Hartland wrote:
>>>
>>> ----- Original Message ----- From: "Willem Jan Withagen"
>>> <wjw@digiware.nl>
>>>
>>>
>>>> On 11-9-2014 19:49, Peter Wemm wrote:
>>>>>> Another downside is 1/4th of uberblocks, 32 vs 128.
>>>>>> Also, automatic sector size detection works great for me and I've
>>>>>> never had
>>>>>> a need to manually tweak ashift.
>>>>>
>>>>> Unfortunately, I have. Same drive connected two different ways:
>>>>>
>>>>> da12 at mps1 bus 0 scbus1 target 11 lun 0
>>>>> da12: <ATA ST4000VN000-1H41 SC43> Fixed Direct Access SCSI-6 device
>>>>> da12: 600.000MB/s transfers
>>>>> da12: Command Queueing enabled
>>>>> da12: 3815447MB (7814037168 512 byte sectors: 255H 63S/T 486401C)
>>>>>
>>>>> ada1 at ahcich1 bus 0 scbus3 target 0 lun 0
>>>>> ada1: <ATA ST4000VN000-1H41 SC43> ATA-8 SATA 3.x device
>>>>> ada1: 600.000MB/s transfers (SATA 3.x, UDMA6, PIO 8192bytes)
>>>>> ada1: Command Queueing enabled
>>>>> ada1: 3815447MB (7814037168 512 byte sectors: 16H 63S/T 16383C)
>>>>> ada1: quirks=0x1<4K>
>>>>>
>>>>> The 4k flag is missing when it's on the sas controller. The Ident
>>>>> strings are changed.
>>>>>
>>>>> This came up elsewhere recently.
>>>>
>>>> I reported the same fact for the new set of WD REDs I installed.
>>>> Seems that ada and da have different quirks tables...
>>>> So disks on SATA connectors on the motherboard are diagnosed as being
>>>> 4Kb.
>>>> The disks on my twa don't get the quirk and are considered 512b
>>>
>>> LMK the ident strings and I'll look to update the quirks tables.
>>
>> Hi Steven,
>>
>> Well actually IMHO the quirk tables should be "joined".
>> Because it is nowadays very simple to get a sata device on a scsi-device
>> (da??) be it USB, or a controller that make the world look like
>> /dev/da?? Like the twa I have.
>> I guess the other way scis devices turning up under ATA would not be
>> common.
>
> You can't unfortunately as they report differently as you've found.
>
>> That said, it will not be so simple, otherwise somebody(tm) would have
>> done so already?
>>
>> the WD RED under ata:
>> ada4 at ahcich10 bus 0 scbus11 target 0 lun 0
>> ada4: <WDC WD30EFRX-68AX9N0 80.00A80> ATA-9 SATA 3.x device
>> ada4: Serial Number WD-WMC1T4089783
>> ada4: 300.000MB/s transfers (SATA 2.x, UDMA6, PIO 8192bytes)
>> ada4: Command Queueing enabled
>> ada4: 2861588MB (5860533168 512 byte sectors: 16H 63S/T 16383C)
>> ada4: quirks=0x1<4K>
>>
>> under twa
>> da0 at arcmsr0 bus 0 scbus8 target 0 lun 0
>> da0: <WDC WD30EFRX-68AX9N0 R001> Fixed Direct Access SCSI-5 device
>> da0: Serial Number WD-WMC1T4081674
>> da0: 250.000MB/s transfers (125.000MHz, offset 32, 16bit)
>> da0: Command Queueing enabled
>> da0: 2861588MB (5860533168 512 byte sectors: 255H 63S/T 364801C)
>> da0: Delete methods: <NONE(*)>
>
> Looks like there are entries which should match already there:
>
> {
> /* WDC Caviar Green Advanced Format (4k) drives */
> { T_DIRECT, SIP_MEDIA_FIXED, "ATA", "WDC WD????RX*", "*" },
> /*quirks*/DA_Q_4K
> },
> {
> /* WDC Caviar Green Advanced Format (4k) drives */
> { T_DIRECT, SIP_MEDIA_FIXED, "WDC WD??", "??RX*", "*" },
> /*quirks*/DA_Q_4K
> },
>
> What does camcontrol identify and camcontrol inquiry report?
What I understood from my previous discussion is that these entries are
specific ATA but are not tested on da-type devices.
This is on a relativly recent 9.3.
--WjW
[~wjw] root@zfs.digiware.nl# uname -a
FreeBSD zfs.digiware.nl 9.3-STABLE FreeBSD 9.3-STABLE #298 r270246M: Thu
Aug 21 12:37:58 CEST 2014
root@zfs.digiware.nl:/usr/obj/usr/srcs/src9/src/sys/ZFS amd64
[~wjw] root@zfs.digiware.nl# camcontrol inquiry /dev/da0
pass3: <WDC WD30EFRX-68AX9N0 R001> Fixed Direct Access SCSI-5 device
pass3: Serial Number WD-WMC1T4081674
pass3: 250.000MB/s transfers (125.000MHz, offset 32, 16bit), Command
Queueing Enabled
[~wjw] root@zfs.digiware.nl# camcontrol identify /dev/ada4
pass14: <WDC WD30EFRX-68AX9N0 80.00A80> ATA-9 SATA 3.x device
pass14: 300.000MB/s transfers (SATA 2.x, UDMA6, PIO 8192bytes)
protocol ATA/ATAPI-9 SATA 3.x
device model WDC WD30EFRX-68AX9N0
firmware revision 80.00A80
serial number WD-WMC1T4089783
WWN 50014ee6ae226f02
cylinders 16383
heads 16
sectors/track 63
sector size logical 512, physical 4096, offset 0
LBA supported 268435455 sectors
LBA48 supported 5860533168 sectors
PIO supported PIO4
DMA supported WDMA2 UDMA6
Feature Support Enabled Value Vendor
read ahead yes yes
write cache yes yes
flush cache yes yes
overlap no
Tagged Command Queuing (TCQ) no no
Native Command Queuing (NCQ) yes 32 tags
NCQ Queue Management no
NCQ Streaming no
Receive & Send FPDMA Queued no
SMART yes yes
microcode download yes yes
security yes no
power management yes yes
advanced power management no no
automatic acoustic management no no
media status notification no no
power-up in Standby yes no
write-read-verify no no
unload yes yes
general purpose logging yes yes
free-fall no no
Data Set Management (DSM/TRIM) no
Host Protected Area (HPA) yes no 5860533168/5860533168
HPA - Security no
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?5412B8C7.3000803>