From owner-svn-src-all@FreeBSD.ORG Tue Dec 7 11:31:32 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 8DC0F106564A; Tue, 7 Dec 2010 11:31:32 +0000 (UTC) (envelope-from mavbsd@gmail.com) Received: from mail-fx0-f54.google.com (mail-fx0-f54.google.com [209.85.161.54]) by mx1.freebsd.org (Postfix) with ESMTP id 1ABEA8FC13; Tue, 7 Dec 2010 11:31:30 +0000 (UTC) Received: by fxm16 with SMTP id 16so10442882fxm.13 for ; Tue, 07 Dec 2010 03:31:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=RMVV1vf8qTg0XWZQn3NDatFJi8SjTWWyhc1JAleLw3M=; b=GbWu1jO5VawhIw6/rCwaJpSgvIxE/SmnF+oTiJ14UpoYWyEoJ3s7XBId6pWTmfD44C YIzhNQ5pJos4eOqn4njltQIc1Sd1T6gu4ifVvzlxI3rAQK698P2gxMTGxIrgAA+KpMfn iWrGNauYco0R8gysEf11TT37FZEcMdMjEvRtk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=ecuFqYSeGVZLUy07hEvjEN32QXZVLSUTxeQvoLgEPjXKDH3yZU+9Yu7Im2KWyH434H 40boGAHyd+44BzzVB62aYOlXniIb6ypNM5Qfv/m87D1McRbGYPbNfTM4GE1JWePCkmR9 z2EbghWNeDqE8r9ZbPnR5CZonI3ZPTH9gD7AM= Received: by 10.223.81.67 with SMTP id w3mr7035928fak.110.1291721490219; Tue, 07 Dec 2010 03:31:30 -0800 (PST) Received: from mavbook.mavhome.dp.ua (pc.mavhome.dp.ua [212.86.226.226]) by mx.google.com with ESMTPS id n3sm1876871fax.31.2010.12.07.03.31.27 (version=SSLv3 cipher=RC4-MD5); Tue, 07 Dec 2010 03:31:28 -0800 (PST) Sender: Alexander Motin Message-ID: <4CFE1B0F.90908@FreeBSD.org> Date: Tue, 07 Dec 2010 13:31:27 +0200 From: Alexander Motin User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.12) Gecko/20101104 Thunderbird/3.1.6 MIME-Version: 1.0 To: Pawel Jakub Dawidek 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> <20101207110410.GE1700@garage.freebsd.pl> In-Reply-To: <20101207110410.GE1700@garage.freebsd.pl> Content-Type: text/plain; charset=KOI8-R; format=flowed Content-Transfer-Encoding: 7bit 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:31:32 -0000 On 07.12.2010 13:04, Pawel Jakub Dawidek wrote: > 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. I can't say anything about it. Ivan told me that it's not. You may discuss it between yourselves and I'll listen. :) > If we decide to align other things to stripesize we can still break > compatibility with other operating systems. Not necessary. Some places indeed may have some legacy requirements, for example, in theory MBR want partition to be aligned to "track boundary" (but I've seen many pre-formatted SD cards with MBR violating it to align partition to flash sector). Same time for BSD label I see no problem to align partitions any way we want. I also see no problems to make FAT cluster, UFS block/fragment, etc, to match some sizes. > 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. I agree that minimal I/O size of 64K or 128K may be too much. In this case I've proposed Ivan to limit maximum used stripesize with some lower value, possibly tunable. But he preferred to not introduce new constants. I think we should not depend that stripesize should be small or big or power-of-2 or anything else. World is not uniform. Even for RAID it can theoretically vary from 1 sector to half of the disk. We have to reconsider it each time we are going to use it, taking to account local limitations and preferences. -- Alexander Motin