From owner-svn-src-all@FreeBSD.ORG Tue Dec 7 11:04:17 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 D7855106564A; Tue, 7 Dec 2010 11:04:17 +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 78B708FC0C; Tue, 7 Dec 2010 11:04:16 +0000 (UTC) Received: by mail.garage.freebsd.pl (Postfix, from userid 65534) id CFC3A45C9B; Tue, 7 Dec 2010 12:04:15 +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 8790045684; Tue, 7 Dec 2010 12:04:10 +0100 (CET) Date: Tue, 7 Dec 2010 12:04:10 +0100 From: Pawel Jakub Dawidek To: Alexander Motin Message-ID: <20101207110410.GE1700@garage.freebsd.pl> References: <201012061218.oB6CI3oW032770@svn.freebsd.org> <20101206195327.GD1936@garage.freebsd.pl> <201012061518.49835.jhb@freebsd.org> <4CFD514E.8010103@FreeBSD.org> <20101207095137.GC1700@garage.freebsd.pl> <4CFE0B9E.3060808@FreeBSD.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="47eKBCiAZYFK5l32" Content-Disposition: inline In-Reply-To: <4CFE0B9E.3060808@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 11:04:17 -0000 --47eKBCiAZYFK5l32 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Dec 07, 2010 at 12:25:34PM +0200, Alexander Motin wrote: > It is really nice that we support bigger sector sizes. But unluckily we > are not the only OS in universe. Disks with data may move between > systems, partition could be shared, etc. We must keep compatibility -- > period. Can you predict what happen if we try to use some FAT partition > created by Windows (using 512bytes sectors) after we set disk sector > size to 4K? I have feeling that we won't even read partition table > properly, not speaking about FAT. Even GEOM classes supporting big > sector sizes depend on that size to be constant -- otherwise they will > just be unable to locate their own metadata in last sector. First valid argument, thank you:) BTW. What Ivan did changes ashift for existing ZFS pools as well, so it breaks them too. If we decide to align other things to stripesize we can still break compatibility with other operating systems. Also stripesize is really not good idea. For RAID5 it might be like 64kB or larger, which is definiately too large for ashift in ZFS or fragment size in UFS. --=20 Pawel Jakub Dawidek http://www.wheelsystems.com pjd@FreeBSD.org http://www.FreeBSD.org FreeBSD committer Am I Evil? Yes, I Am! --47eKBCiAZYFK5l32 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.14 (FreeBSD) iEYEARECAAYFAkz+FKUACgkQForvXbEpPzRTkACgl0xUFgpSNplwEEOTzjdITTvS fJUAn0bJw3iKuonr/mRJxkIK+sw9J78f =DTqA -----END PGP SIGNATURE----- --47eKBCiAZYFK5l32--