From owner-freebsd-questions@freebsd.org Fri Sep 11 16:10:21 2015 Return-Path: Delivered-To: freebsd-questions@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 63E0CA02155 for ; Fri, 11 Sep 2015 16:10:21 +0000 (UTC) (envelope-from milios@ccsys.com) Received: from cargobay.net (cargobay.net [198.178.123.147]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 43D83117E for ; Fri, 11 Sep 2015 16:10:21 +0000 (UTC) (envelope-from milios@ccsys.com) Received: from [192.168.0.4] (cblmdm72-240-160-19.buckeyecom.net [72.240.160.19]) by cargobay.net (Postfix) with ESMTPSA id 5CAAB6E1; Fri, 11 Sep 2015 16:05:43 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) Subject: Re: followup storage question From: "Chad J. Milios" X-Mailer: iPhone Mail (12H321) In-Reply-To: <55F2ED46.6060708@hiwaay.net> Date: Fri, 11 Sep 2015 12:10:18 -0400 Cc: FreeBSD Questions !!!! Content-Transfer-Encoding: quoted-printable Message-Id: <75729A18-AEB5-4B95-B20C-4C2298EC61E6@ccsys.com> References: <55F2D086.6060509@hiwaay.net> <55F2ED46.6060708@hiwaay.net> To: "William A. Mahaffey III" X-BeenThere: freebsd-questions@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: User questions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Sep 2015 16:10:21 -0000 > On Sep 11, 2015, at 11:02 AM, William A. Mahaffey III wro= te: >=20 > Hmmmm .... OK, however if I carefully 'gpart -a 4k' the underlying partiti= ons aligned, then wouldn't the resulting ZFS above also be aligned ? Thanks to gpart's -a setting the partition will be a multiple of 4k in size a= nd aligned upon the outer context (disk) at 4k boundaries but the alignment/= size of [each/every] i/o request that ZFS sends to the device node, well tha= t is a different story. That is what the ashift value controls and it gets s= tamped onto the new vdev when ZFS first christens a device/partition. The sy= sctl or gnop helps us ensure the ashift value we bake into a vdev is truly t= he value we want after all the low down dirty deceitful layers of abstractio= n beneath that are often lying to us. The situation's no better on any other operating system, even if they hide i= t better that only opens up the possibility it makes wrong guesses. This is j= ust a growing pain resulting from ever increasing disk/file sizes/densities v= s the demand for backward compatibility.=