From owner-svn-src-all@FreeBSD.ORG Tue Dec 7 09:51:45 2010 Return-Path: Delivered-To: svn-src-all@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DE1E3106564A; Tue, 7 Dec 2010 09:51:44 +0000 (UTC) (envelope-from pjd@garage.freebsd.pl) Received: from mail.garage.freebsd.pl (60.wheelsystems.com [83.12.187.60]) by mx1.freebsd.org (Postfix) with ESMTP id 186558FC13; Tue, 7 Dec 2010 09:51:43 +0000 (UTC) Received: by mail.garage.freebsd.pl (Postfix, from userid 65534) id 857D045C8A; Tue, 7 Dec 2010 10:51:42 +0100 (CET) Received: from localhost (pdawidek.whl [10.0.1.1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.garage.freebsd.pl (Postfix) with ESMTP id F408E456B1; Tue, 7 Dec 2010 10:51:36 +0100 (CET) Date: Tue, 7 Dec 2010 10:51:37 +0100 From: Pawel Jakub Dawidek To: Alexander Motin Message-ID: <20101207095137.GC1700@garage.freebsd.pl> References: <201012061218.oB6CI3oW032770@svn.freebsd.org> <20101206195327.GD1936@garage.freebsd.pl> <201012061518.49835.jhb@freebsd.org> <4CFD514E.8010103@FreeBSD.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="qtZFehHsKgwS5rPz" Content-Disposition: inline In-Reply-To: <4CFD514E.8010103@FreeBSD.org> User-Agent: Mutt/1.4.2.3i X-PGP-Key-URL: http://people.freebsd.org/~pjd/pjd.asc X-OS: FreeBSD 9.0-CURRENT amd64 X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) on mail.garage.freebsd.pl X-Spam-Level: X-Spam-Status: No, score=-5.9 required=4.5 tests=ALL_TRUSTED,BAYES_00 autolearn=ham version=3.0.4 Cc: svn-src-head@freebsd.org, svn-src-all@freebsd.org, src-committers@freebsd.org, Ivan Voras , John Baldwin Subject: Re: svn commit: r216230 - head/sys/cddl/contrib/opensolaris/uts/common/fs/zfs X-BeenThere: svn-src-all@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "SVN commit messages for the entire src tree \(except for " user" and " projects" \)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Dec 2010 09:51:45 -0000 --qtZFehHsKgwS5rPz Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Dec 06, 2010 at 11:10:38PM +0200, Alexander Motin wrote: > On 06.12.2010 22:18, John Baldwin wrote: > >On Monday, December 06, 2010 2:53:27 pm Pawel Jakub Dawidek wrote: > >>On Mon, Dec 06, 2010 at 08:35:36PM +0100, Ivan Voras wrote: > >>>Please persuade me on technical grounds why ashift, a property > >>>intended for address alignment, should not be set in this way. If your > >>>answer is "I don't know but you are still wrong because I say so" I > >>>will respect it and back it out but only until I/we discuss the > >>>question with upstream ZFS developers. > >> > >>No. You persuade me why changing ashift in ZFS, which, as the comment > >>clearly states is "device's minimum transfer size" is better and not > >>hackish than presenting the disk with properly configured sector size. > >>This can not only affect disks that still use 512 bytes sectors, but > >>doesn't fix the problem at all. It just works around the problem in ZFS > >>when configured on top of raw disks. >=20 > Both ATA and SCSI standards implemented support for different logical=20 > and physical sector sizes. It is not a hack - it seems to be the way=20 > manufacturers decided to go. At least on their words. IMHO hack in this= =20 > situation would be to report to GEOM some fake sector size, different=20 > from one reported by device. In any way it is the main visible disk=20 > characteristic, independently of what it's firmware does inside. We can be smarter than that, really. We all know the disk presents 512 bytes sectors only(?) because most of the software out there (including Windows, I guess) will simply break when they see disk with 4kB sector. We were trying very hard not to be limited to 512 byte sectors and we actually succedded: GEOM supports any sector size just fine, most (if not all) GEOM classes support power of 2 sectors just fine, even our two main file systems (UFS and ZFS) support !512 sectors. After all this work do we really don't want to take advantage of it? Maybe other operating systems can't deal with 4kB sectors, but we can, we were well prepared for this, why do we want to forget about that? --=20 Pawel Jakub Dawidek http://www.wheelsystems.com pjd@FreeBSD.org http://www.FreeBSD.org FreeBSD committer Am I Evil? Yes, I Am! --qtZFehHsKgwS5rPz Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.14 (FreeBSD) iEYEARECAAYFAkz+A6kACgkQForvXbEpPzRTwwCeOhTQ3y2194aTCzvMvTmXltki SM0AoLcFYqQEWZ/EXPEL813z/68bqItO =IuP1 -----END PGP SIGNATURE----- --qtZFehHsKgwS5rPz--