Skip site navigation (1)Skip section navigation (2)
Date:      Sun, 8 Aug 2010 14:57:20 +0200
From:      =?UTF-8?Q?Marius_N=C3=BCnnerich?= <marius@nuenneri.ch>
To:        Ivan Voras <ivoras@freebsd.org>
Cc:        freebsd-hackers@freebsd.org, freebsd-current@freebsd.org, freebsd-geom@freebsd.org
Subject:   Re: glabel "force sectorsize" patch
Message-ID:  <AANLkTinx%2B8wTRMiyQ1yPPJXkYSTEBa=2HYJoWM_nrhq-@mail.gmail.com>
In-Reply-To: <i3m6c9$7ch$1@dough.gmane.org>
References:  <AANLkTinBA04YM=uwNJ4sog2KMACUQfpJm7f-CjnRB39x@mail.gmail.com>  <20100808103055.GA2037@garage.freebsd.pl> <i3m6c9$7ch$1@dough.gmane.org>

next in thread | previous in thread | raw e-mail | index | archive | help
On Sun, Aug 8, 2010 at 14:02, Ivan Voras <ivoras@freebsd.org> wrote:
> 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.

I do not like this at all. Even if it's just for the KISS and POLA
principles. A geom should do one thing and do it right imo.
Why not write a new geom class that does what you want?



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?AANLkTinx%2B8wTRMiyQ1yPPJXkYSTEBa=2HYJoWM_nrhq->