Date: Fri, 11 Sep 2015 12:10:18 -0400 From: "Chad J. Milios" <milios@ccsys.com> To: "William A. Mahaffey III" <wam@hiwaay.net> Cc: FreeBSD Questions !!!! <freebsd-questions@freebsd.org> Subject: Re: followup storage question Message-ID: <75729A18-AEB5-4B95-B20C-4C2298EC61E6@ccsys.com> In-Reply-To: <55F2ED46.6060708@hiwaay.net> References: <55F2D086.6060509@hiwaay.net> <alpine.BSF.2.20.1509110821560.6365@wonkity.com> <55F2ED46.6060708@hiwaay.net>
next in thread | previous in thread | raw e-mail | index | archive | help
> On Sep 11, 2015, at 11:02 AM, William A. Mahaffey III <wam@hiwaay.net> 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.=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?75729A18-AEB5-4B95-B20C-4C2298EC61E6>