From owner-freebsd-hardware@FreeBSD.ORG Fri Oct 11 19:50:28 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 439604A8; Fri, 11 Oct 2013 19:50:28 +0000 (UTC) (envelope-from rp_freebsd@mac.com) Received: from nk11p00mm-asmtp001.mac.com (nk11p00mm-asmtp001.mac.com [17.158.161.0]) by mx1.freebsd.org (Postfix) with ESMTP id 254552E9D; Fri, 11 Oct 2013 19:50:27 +0000 (UTC) Received: from nk11p00mm-spool004.mac.com ([17.158.161.119]) by nk11p00mm-asmtp001.mac.com (Oracle Communications Messaging Server 7u4-27.08(7.0.4.27.7) 64bit (built Aug 22 2013)) with ESMTP id <0MUI004Y1PMHVW70@nk11p00mm-asmtp001.mac.com>; Fri, 11 Oct 2013 18:49:32 +0000 (GMT) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.10.8794,1.0.431,0.0.0000 definitions=2013-10-11_07:2013-10-11,2013-10-11,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-1310110081 MIME-version: 1.0 Received: from localhost ([17.158.233.93]) by nk11p00mm-spool004.mac.com (Oracle Communications Messaging Server 7u4-27.08(7.0.4.27.7) 64bit (built Aug 22 2013)) with ESMTP id <0MUI00GQNPMHKN20@nk11p00mm-spool004.mac.com>; Fri, 11 Oct 2013 18:49:29 +0000 (GMT) To: John Baldwin From: Ravi Pokala Subject: Re: What's the state of AF-4Kn support? Date: Fri, 11 Oct 2013 18:49:29 +0000 (GMT) X-Mailer: iCloud MailClient1T.110221 MailServer1T32 X-Originating-IP: [66.2.48.195] Message-id: <4a88054e-d435-4d4b-959b-eb809b99e34d@me.com> In-reply-to: <201310101657.22675.jhb@freebsd.org> Content-Type: text/plain; CHARSET=US-ASCII; format=flowed Content-Transfer-Encoding: 7BIT X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: freebsd-hackers@freebsd.org, Jia-Shiun Li , freebsd-hardware@freebsd.org 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: Fri, 11 Oct 2013 19:50:28 -0000 Yes, the BIOS calls have always only used 512 byte sectors. There would have to be an updated spec for those, and it would be a bit of a PITA to use. I suspect the "right" answer for this on x86 is UEFI. Yeah, that's the conclusion I reached as well. Though it occurs to me, aren't we already part-way there w/ our IA64 support? EFI originated w/ Itanium and was required to boot those systems, so shouldn't we be able to leverage much of that work for (U)EFI on amd64? In any case, the primary motivator (at least, for me) is being able to boot from AF-4Kn drives; based on the most recent roadmaps I've seen, the enterprise HDD vendors are committing to support AF-512e for a good while longer, so it's not as urgent as I thought it was when I opened this thread a few weeks ago. Thanks, --rp On Oct 10, 2013, at 01:57 PM, John Baldwin wrote: On Monday, September 23, 2013 10:58:19 am Ravi Pokala wrote: -----Original Message----- From: Jia-Shiun Li Date: Sunday, September 22, 2013 11:22 PM To: Ravi Pokala Cc: "freebsd-hardware@freebsd.org" , Subject: Re: What's the state of AF-4Kn support? >On Wed, Sep 18, 2013 at 10:49 PM, Ravi Pokala wrote: >> >>... > >CC -hackers. > >Thanks for the clarification. Is there any 4Kn HDDs shopping now? I am >not aware of any. Good question. I had the impression that some currently shipping drives were AF-4Kn, but spot-checking some of the drives listed in src/cam/ata/ata_da.c::ada_quirk_table[] against their datasheets, suggests that they're AF-512e. So, their being flagged w/ ADA_Q_4K is "just" a performance optimization. >BTW I believe UFS and ZFS have proper design for 4K-sectors, but FreeBSD >needs some ecosystem connections to get samples early to test, >incorporate supports and validate for it. Or we will need to wait until >it appears on market and someone got caught into some kind of bugs. Yeah, based on my reading of the code, it looks like the ATACAM layer and higher (GEOM, filesystems) take the physical block size into account. That just leaves the bootstrap code. Now that I've taken a second look, it seems as though at least 'pmbr' only works in terms of 512 bytes. :-( Yes, the BIOS calls have always only used 512 byte sectors. There would have to be an updated spec for those, and it would be a bit of a PITA to use. I suspect the "right" answer for this on x86 is UEFI. -- John Baldwin