Re: glabel "force sectorsize" patch

On Sun, Aug 8, 2010 at 14:02, Ivan Voras <ivoras_at_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?