From owner-freebsd-hardware@FreeBSD.ORG Wed Sep 18 15:50:11 2013 Return-Path: Delivered-To: freebsd-hardware@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 16F936D5 for ; Wed, 18 Sep 2013 15:50:11 +0000 (UTC) (envelope-from rp_freebsd@mac.com) Received: from st11p00mm-asmtp001.mac.com (st11p00mm-asmtpout001.mac.com [17.172.81.0]) by mx1.freebsd.org (Postfix) with ESMTP id E3277233A for ; Wed, 18 Sep 2013 15:50:10 +0000 (UTC) Received: from [192.168.1.3] (c-98-207-91-59.hsd1.ca.comcast.net [98.207.91.59]) by st11p00mm-asmtp001.mac.com (Oracle Communications Messaging Server 7u4-27.08(7.0.4.27.7) 64bit (built Aug 22 2013)) with ESMTPSA id <0MTB00JQ9T794W10@st11p00mm-asmtp001.mac.com> for freebsd-hardware@freebsd.org; Wed, 18 Sep 2013 14:50:02 +0000 (GMT) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.10.8794,1.0.431,0.0.0000 definitions=2013-09-18_06:2013-09-18,2013-09-18,1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1308280000 definitions=main-1309180065 User-Agent: Microsoft-MacOutlook/14.3.7.130812 Date: Wed, 18 Sep 2013 07:49:56 -0700 Subject: Re: What's the state of AF-4Kn support? From: Ravi Pokala Sender: Ravi Pokala To: "freebsd-hardware@freebsd.org" Message-id: Thread-topic: What's the state of AF-4Kn support? In-reply-to: MIME-version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7bit X-BeenThere: freebsd-hardware@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: General discussion of FreeBSD hardware List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Sep 2013 15:50:11 -0000 -----Original Message----- From: Jia-Shiun Li Date: Wednesday, September 18, 2013 3:37 AM To: Ravi Pokala Cc: "freebsd-hardware@freebsd.org" Subject: Re: What's the state of AF-4Kn support? >On Sat, Sep 14, 2013 at 3:14 PM, Ravi Pokala 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