From owner-freebsd-stable@FreeBSD.ORG Thu Feb 17 20:46:42 2011 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 36F4A106564A for ; Thu, 17 Feb 2011 20:46:42 +0000 (UTC) (envelope-from lists@c0mplx.org) Received: from home.opsec.eu (home.opsec.eu [IPv6:2001:14f8:200::1]) by mx1.freebsd.org (Postfix) with ESMTP id E5C758FC0A for ; Thu, 17 Feb 2011 20:46:41 +0000 (UTC) Received: from pi by home.opsec.eu with local (Exim 4.72 (FreeBSD)) (envelope-from ) id 1PqAkN-000AWG-Ev for freebsd-stable@freebsd.org; Thu, 17 Feb 2011 21:46:43 +0100 Date: Thu, 17 Feb 2011 21:46:43 +0100 From: Kurt Jaeger To: freebsd-stable@freebsd.org Message-ID: <20110217204643.GJ34314@home.opsec.eu> References: <20110217115653.GH34314@home.opsec.eu> <20110217124515.GI34314@home.opsec.eu> <4D5D1D10.7010000@digsys.bg> <20110217180140.GL66849@dan.emsphone.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20110217180140.GL66849@dan.emsphone.com> Subject: Re: 3TB disc and block alignment X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Feb 2011 20:46:42 -0000 Hi! > > According to Hitachi, this is an 512b drive. > > Correct. This isn't a 4k drive. Datasheet: > > http://www.hgst.com/internal-drives/enterprise/ultrastar/ultrastar-7k3000 Hmm, wasn't the issues with 3T drives, that they internally use 4K blocks and emulate 512 and that therefore 8 block alignments are an performance issue ? The reason I'm asking: I encounter the problem of the lost secondary GPT table: Feb 17 22:15:44 vserv1 kernel: GEOM: ad7: the secondary GPT table is corrupt or invalid. Feb 17 22:15:44 vserv1 kernel: GEOM: ad7: using the primary only -- recovery suggested. Feb 17 22:15:44 vserv1 kernel: GEOM: ufsid/4d5d8faa10b63ac1: the secondary GPT table is corrupt or invalid. Feb 17 22:15:44 vserv1 kernel: GEOM: ufsid/4d5d8faa10b63ac1: using the primary only -- recovery suggested. I had this disc connected via some usb2sata adapter as da0, and there was no error message when I did the 'gpart create ad7' thing. When I now connect it to the some other box as ad7 and this error message appears: Which of the two has the problem with the controller not getting the large size disc correct ? -- pi@opsec.eu +49 171 3101372 9 years to go !