Hours of tiny transfers at the end of a ZFS resilver?
Steven Hartland
killing at multiplay.co.uk
Tue Feb 16 09:09:16 UTC 2016
On 16/02/2016 03:31, Ravi Pokala wrote:
>> Date: Mon, 15 Feb 2016 21:08:43 +0000
>> From: Steven Hartland <killing at multiplay.co.uk>
>> To: freebsd-fs at freebsd.org
>> Subject: Re: Hours of tiny transfers at the end of a ZFS resilver?
>> Message-ID: <56C23E5B.7060207 at multiplay.co.uk>
>> Content-Type: text/plain; charset=windows-1252; format=flowed
> Hi Steve,
>
>>> [*] This is probably a good segue into discussing why we even have the ADA_Q_4K quirk, and whether we should get rid of it...? --rp
>> The 4k quirks exists because a large amount of devices don't report 4k correctly instead just reporting 512 for both logical and physical even when they are actually 4k or larger physical sector size.
> If true, that's a gross violation of ATA, and I would consider that a disqualifying firmware bug. After over a decade at a storage vendor, I've seen some *really* stupid firmware issues, but lying about the sector size would be a new low. :-(
>
> Are we sure that they are really, truly claiming to be 512n rather than AF-512e, rather than us mis-parsing the sector sizes due to the aforementioned kernel bugs? If someone running -CURRENT has a drive which has the ADA_Q_4K quirk, could you paste the output of `geom disk list $DRIVE'?
>
My head box doesn't have the feature that would do what you're after but
here's what camcontrol says for one such device:
camcontrol identify ada0
pass1: <Corsair Force GS 5.05A> ATA8-ACS SATA 3.x device
pass1: 300.000MB/s transfers (SATA 2.x, UDMA6, PIO 8192bytes)
protocol ATA/ATAPI-8 SATA 3.x
device model Corsair Force GS
firmware revision 5.05A
serial number 1304790400009741003E
WWN 0000000000000000
cylinders 16383
heads 16
sectors/track 63
sector size logical 512, physical 512, offset 0
LBA supported 250069680 sectors
LBA48 supported 250069680 sectors
PIO supported PIO4
DMA supported WDMA2 UDMA6
media RPM non-rotating
This is 4k underlying, SSD's are by far and away the worst culprits for
this.
Regards
Steve
More information about the freebsd-fs
mailing list