Re: glabel "force sectorsize" patch

On Sun, Aug 8, 2010 at 21:08, Ivan Voras <ivoras_at_freebsd.org> wrote:
> On 8.8.2010 14:57, Marius Nünnerich wrote:
>> On Sun, Aug 8, 2010 at 14:02, Ivan Voras <ivoras_at_freebsd.org> wrote:
>
>>>>> This mechanism is a band-aid until there's a better way of dealing
>>>>> with 4k drives.
>
>> 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.
>
> As the addition will not modify general behaviour of glabel but add a
> new feature (which is actually clean and trivial to implement) invisible
> to most of the users, I don't think either KISS nor POLA are in any
> danger here.

"Adding a new feature" maps directly to KISS, especially if the
feature is in the wrong module.
POLA: I wouldn't guess that a blocksize resizing is hidden in a _part_
of glabel. I am not using the native glabel part at all, just the
named GPT partitions as most of the users seem to prefer nower days
(and I guess will get even more traction after Dan's blog post).

> I do agree that it shouldn't be glabel's job to do this but also am
> *very* strongly against shipping 9.0 without any support for 4k drives,
> and the way I've chosen is the lesser of two evils.

I am against workarounds for stupid hardware vendors most of the time.
Especially if it's just a minority, they break pola intentionally and
is fixed easily without this kludge. Afaik if you align your
Partitions to higher values (I use 1MB for example) ufs is not having
any performance issues (I have not benchmarked this myself).

> Code and patches by others are of course welcome. I'm hoping this
> discussion will trigger someone with experience in the lower levels of
> kernel to go and finally add the drive info parsing so it gets solved
> the right way :)
>
>> Why not write a new geom class that does what you want?
>
> I'm not against this approach also. Technically, if we go this way, the
> new GEOM class will be almost a line-for-line copy-paste of glabel with
> this single metadata field added, so I'd rather fold it into glabel.

I did not think of a new GEOM class that looks like glabel but one
that has no metadata stored on disk . It is then activated and
controlled by loader.conf variables. (Maybe like gnop? If I remember
correctly, I did not take a look at that class for ages).

This way you would get:
 - Your feature
 - no KISS violation, that class should be really simple
 - no POLA violation, feature is in a class with a discriptive name,
glabel is left alone
 - no metadata store problem (is it in the last 512 or 4K bytes?)
 - No problem with future compatibilty, a user would have to active
the class and it's configuration by hand, no magic here

Marius