Date: Tue, 07 Dec 2010 12:25:34 +0200 From: Alexander Motin <mav@FreeBSD.org> To: Pawel Jakub Dawidek <pjd@FreeBSD.org> Cc: svn-src-head@freebsd.org, svn-src-all@freebsd.org, src-committers@freebsd.org, Ivan Voras <ivoras@freebsd.org>, John Baldwin <jhb@freebsd.org> Subject: Re: svn commit: r216230 - head/sys/cddl/contrib/opensolaris/uts/common/fs/zfs Message-ID: <4CFE0B9E.3060808@FreeBSD.org> In-Reply-To: <20101207095137.GC1700@garage.freebsd.pl> References: <201012061218.oB6CI3oW032770@svn.freebsd.org> <AANLkTine9rGq_cM4ruFXYq=-F7cMXcQAr-zKHuWoQs2z@mail.gmail.com> <20101206195327.GD1936@garage.freebsd.pl> <201012061518.49835.jhb@freebsd.org> <4CFD514E.8010103@FreeBSD.org> <20101207095137.GC1700@garage.freebsd.pl>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4CFE0B9E.3060808>