From owner-freebsd-arch@FreeBSD.ORG Fri Dec 25 11:38:09 2009 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A8EAE106566B for ; Fri, 25 Dec 2009 11:38:09 +0000 (UTC) (envelope-from serenity@exscape.org) Received: from ch-smtp01.sth.basefarm.net (ch-smtp01.sth.basefarm.net [80.76.149.212]) by mx1.freebsd.org (Postfix) with ESMTP id 653748FC0A for ; Fri, 25 Dec 2009 11:38:09 +0000 (UTC) Received: from c83-253-248-99.bredband.comhem.se ([83.253.248.99]:58571 helo=mx.exscape.org) by ch-smtp01.sth.basefarm.net with esmtp (Exim 4.68) (envelope-from ) id 1NO8FN-0007Ak-46; Fri, 25 Dec 2009 12:22:18 +0100 Received: from [192.168.1.5] (macbookpro [192.168.1.5]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mx.exscape.org (Postfix) with ESMTPSA id C0FFE1F57F8; Fri, 25 Dec 2009 12:22:14 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=us-ascii From: Thomas Backman In-Reply-To: <4B349ABF.2070800@FreeBSD.org> Date: Fri, 25 Dec 2009 12:22:08 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <469FFFC8-514B-41B9-AEEC-E4B7AB6CB886@exscape.org> References: <4B349ABF.2070800@FreeBSD.org> To: Alexander Motin X-Mailer: Apple Mail (2.1077) X-Originating-IP: 83.253.248.99 X-Scan-Result: No virus found in message 1NO8FN-0007Ak-46. X-Scan-Signature: ch-smtp01.sth.basefarm.net 1NO8FN-0007Ak-46 71b17cad7b06e00831995badaaabf3d8 Cc: FreeBSD-Current , freebsd-arch@freebsd.org Subject: Re: File system blocks alignment X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Dec 2009 11:38:09 -0000 On Dec 25, 2009, at 11:58 AM, Alexander Motin wrote: > Hi. >=20 > Recently WD released first series of ATA disks with increased physical > sector size. It makes writes not matching with 4K blocks inefficient > there. They don't expose this to the OS, though (not by default, anyway), but = chop it up into 8 512-byte sectors for compatibility reasons. Just thought I'd point that out - I'm not even sure if you can get them = to *not* do the compatibility thing and expose 4k-sized sectors. I'm sure your work is important for other setups, though, as proved. :) Regards, Thomas=