Date: Sun, 08 Aug 2010 21:08:58 +0200 From: Ivan Voras <ivoras@freebsd.org> To: freebsd-geom@freebsd.org Cc: freebsd-hackers@freebsd.org, freebsd-current@freebsd.org Subject: Re: glabel "force sectorsize" patch Message-ID: <i3mvcc$ekr$1@dough.gmane.org> In-Reply-To: <AANLkTinx%2B8wTRMiyQ1yPPJXkYSTEBa=2HYJoWM_nrhq-@mail.gmail.com> References: <AANLkTinBA04YM=uwNJ4sog2KMACUQfpJm7f-CjnRB39x@mail.gmail.com> <20100808103055.GA2037@garage.freebsd.pl> <i3m6c9$7ch$1@dough.gmane.org> <AANLkTinx%2B8wTRMiyQ1yPPJXkYSTEBa=2HYJoWM_nrhq-@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On 8.8.2010 14:57, Marius Nünnerich wrote: > On Sun, Aug 8, 2010 at 14:02, Ivan Voras <ivoras@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. 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. 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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?i3mvcc$ekr$1>