From owner-freebsd-geom@FreeBSD.ORG Sun Aug 8 12:02:29 2010 Return-Path: Delivered-To: freebsd-geom@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1D972106567C for ; Sun, 8 Aug 2010 12:02:29 +0000 (UTC) (envelope-from gcubfg-freebsd-geom@m.gmane.org) Received: from lo.gmane.org (lo.gmane.org [80.91.229.12]) by mx1.freebsd.org (Postfix) with ESMTP id 8A6978FC14 for ; Sun, 8 Aug 2010 12:02:28 +0000 (UTC) Received: from list by lo.gmane.org with local (Exim 4.69) (envelope-from ) id 1Oi4aA-00048o-8Z for freebsd-geom@freebsd.org; Sun, 08 Aug 2010 14:02:26 +0200 Received: from 89-164-126-197.dsl.iskon.hr ([89.164.126.197]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 08 Aug 2010 14:02:26 +0200 Received: from ivoras by 89-164-126-197.dsl.iskon.hr with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 08 Aug 2010 14:02:26 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-geom@freebsd.org From: Ivan Voras Date: Sun, 08 Aug 2010 14:02:17 +0200 Lines: 49 Message-ID: References: <20100808103055.GA2037@garage.freebsd.pl> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@dough.gmane.org X-Gmane-NNTP-Posting-Host: 89-164-126-197.dsl.iskon.hr User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.1.11) Gecko/20100711 Thunderbird/3.0.6 In-Reply-To: <20100808103055.GA2037@garage.freebsd.pl> Cc: freebsd-hackers@freebsd.org, freebsd-current@freebsd.org Subject: Re: glabel "force sectorsize" patch X-BeenThere: freebsd-geom@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: GEOM-specific discussions and implementations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Aug 2010 12:02:29 -0000 On 8.8.2010 12:30, Pawel Jakub Dawidek wrote: > On Sun, Aug 08, 2010 at 03:57:44AM +0200, Ivan Voras wrote: >> Hi, >> >> In order to help users having 4k sector drives which the system >> recognizes as 512 byte sector drives, I'm proposing a patch to glabel >> which enables it to use a forced sector size for its native-labeled >> providers. It is naturally only usable with glabel-native labels >> (those created by "glabel label") and not partition and file system >> labels because we cannot add arbitrary new fields to metadata of those >> types. >> >> The patch is here: >> >> http://people.freebsd.org/~ivoras/diffs/glabel_ssize.patch > [...] >> This mechanism is a band-aid until there's a better way of dealing >> with 4k drives. > > So why do you want to obfuscate glabel with it? For people to start > depend on it? Once we start supporting 4kB sectors what do we do with > such a change? Remove it and decrease version number? What people will > do with providers already labeled this way? > > If its temporary, just allow to list providers you want to increase > sector size in /boot/loader.conf. Once we start supporting it properly > people might simply remove it from loader.conf and it should just work. > > Glabel is not for that and I don't agree for such obfuscation. Of course, there are good and bad sides to it. My take on it is that the only bad side is that it really isn't glabel's primary function to (optionally) fixup geometry, while the good sides are: * glabel is in GENERIC and judging by the mailing lists' traffic it is one of the better used parts of the system so people are familiar with it. It is also already used as a perfectly valid fixup for device renaming, making both UFS and ZFS more stable for usage. * You can't really "make people depend on glabel" both because it is in GENERIC and because of it storing metadata in the last sector, making the rest of the drive completely usable without it in the event native 4k sector support is grown. I'd like to hear comments from the wider audience. In respect with your comment, I will compromise: as 4k sector drives have become available over the counter more than 6 months ago and so far I think this is the first effort to give some support for them, I will commit this patch before 9.0 code freeze only if no other support gets developed.