From owner-svn-src-all@FreeBSD.ORG Tue Dec 7 10:26:04 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 38AE2106566B; Tue, 7 Dec 2010 10:26:04 +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 C6E128FC18; Tue, 7 Dec 2010 10:26:02 +0000 (UTC) Received: by fxm16 with SMTP id 16so10394340fxm.13 for ; Tue, 07 Dec 2010 02:26:02 -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 :x-enigmail-version:content-type:content-transfer-encoding; bh=4OeLog5Xz7buH56eNgfASPIujvGmwUg9wkDe+qsBNbg=; b=eYy3sYwDTyYPW6NujezUsuMZrjylHirzERNaN4hkLtGjITX2DXgocj1DB2fd9Mxi5F 7nZL1q4GiT9KpLepP7bnz54AThRlmYE+Bsjf6ZVb0HG4v0g0jAaTN8OaHRMSTEiTANIf vzxYOHGi9nOMM1L6rNcefP07AzNQX9K2w8mxs= 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:x-enigmail-version:content-type :content-transfer-encoding; b=HShiyWbxWZxSvphZNPYY376PE3dxcU5kOX58DAKMFJ6+T6+byaZLVpa/HzGaeVZBs/ mTOlip8t+wYRz1aNletB3rbaVQS5BvuEUD3mGAwV0p+LuSpNhk5JD1VhBFK8I05Yjd5v SUDcj1HOntX9c/0HeMIHllyJket/X7e1xEP0M= Received: by 10.223.103.12 with SMTP id i12mr1940754fao.43.1291717561932; Tue, 07 Dec 2010 02:26:01 -0800 (PST) Received: from mavbook2.mavhome.dp.ua (pc.mavhome.dp.ua [212.86.226.226]) by mx.google.com with ESMTPS id 5sm1882611fak.47.2010.12.07.02.25.59 (version=SSLv3 cipher=RC4-MD5); Tue, 07 Dec 2010 02:26:00 -0800 (PST) Sender: Alexander Motin Message-ID: <4CFE0B9E.3060808@FreeBSD.org> Date: Tue, 07 Dec 2010 12:25:34 +0200 From: Alexander Motin User-Agent: Thunderbird 2.0.0.23 (X11/20091212) 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> In-Reply-To: <20101207095137.GC1700@garage.freebsd.pl> X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=KOI8-R 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 10:26:04 -0000 Pawel Jakub Dawidek wrote: > 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. >> Both ATA and SCSI standards implemented support for different logical >> and physical sector sizes. It is not a hack - it seems to be the way >> manufacturers decided to go. At least on their words. IMHO hack in this >> situation would be to report to GEOM some fake sector size, different >> from one reported by device. In any way it is the main visible disk >> 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? 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. -- Alexander Motin