Re: What's the state of AF-4Kn support?

-----Original Message-----
From: Jia-Shiun Li <[email protected]>
Date: Wednesday, September 18, 2013 3:37 AM
To: Ravi Pokala <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: What's the state of AF-4Kn support?

>On Sat, Sep 14, 2013 at 3:14 PM, Ravi Pokala <[email protected]> wrote:
>> What does 4Kn support look like in -HEAD? I know UFS's defaults (32KB
>>blocks / 4KB fragments) are 4Kn-friendly, and that `gpart' handles
>>alignment properly. What about direct drive I/O (i.e. do the device
>>drivers do the proper read/modify/write stuff if you try to write a
>>partial block)? What about the bootstrap code; I've looked at pmbr.s and
>>gptboot.c, and it's not clear if they DTRT in the face of 4Kn drives.
>
>RMW is done in HDD firmware. The HDDs still do 512b-sector I/Os, only
>giving additional hint that physically it is 4K and if aligned
>performance would be better. Functionally speaking there is no difference
>from not-so-advanced-format (if cost-down is an advance) HDDs.
>
>Jia-Shiun.

Hi Jia-Shiun,

What you describe is the 'AF-512e' format - 4KB physical sectors
*emulating* 512B logical sectors. See [
https://en.wikipedia.org/wiki/Advanced_Format#Advanced_Format_512e ;
http://www.idema.org/?page_id=2153 ]. With AF-512e, yes, the HDD firmware
does the read/modify/write for I/Os smaller than the physical sector size.
It is intended to be a low-cost/transitional format, allowing the HDD
vendors to get the advantages of 4KB physical sectors (better error
detection/correction algorithms, better areal density => lower cost) w/o
breaking compatibility with decades of firmware and software that expect
512B logical sectors.

What I'm asking about is AF-4kn - 4KB *logical* as well as physical
sectors. All the enterprise HDD vendors have told us is that AF-4Kn drives
expect data IO to be 4KB, and will reject smaller transfers. (*metadata*
IO - SMART, IDENTIFY_DEVICE, READ_LOG/WRITE_LOG, etc - will remain 512B.)

Doing some more digging, I found this post from ivoras which I missed the
first time around [
http://ivoras.net/blog/tree/2011-01-01.freebsd-on-4k-sector-drives.html ];
that tends to support my initial assessment - filesystem stuff should Just
Work[tm] - plus adds the detail that direct drive I/O (the example he
gives is trying to `dd' 10 bytes) will be rejected because it is smaller
than the raw-device access granularity. I've also looked at 'ata_da.c' and
see that adaregister() looks at both quirks and IDENTIFY_DEVICE data to
determine the logical block size.

So, that leaves the bootstrap code as the remaining question-mark. Does
anyone what AF-4Kn support looks like there?

--rp


_______________________________________________
[email protected] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hardware
To unsubscribe, send any mail to "[email protected]"