glabel "force sectorsize" patch
Pawel Jakub Dawidek
pjd at FreeBSD.org
Sun Aug 8 13:05:51 UTC 2010
On Sun, Aug 08, 2010 at 02:02:17PM +0200, Ivan Voras wrote:
> On 8.8.2010 12:30, Pawel Jakub Dawidek wrote:
> > 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:
It isn't its secondary function either.
> * 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.
That's an excellent argument. But you know what? The em(4) is also in
GENERIC, why not to add it in there?
> * 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 never said that. I do want people to depend on glabel, because it is
free of such ugly hacks, so I know it won't bite them in the future.
I don't want people to start depend on the fact that glabel supports
changing sector sizes.
Once we start supporting 4kB sectors properly people configuration will
stop working, because glabel won't be able to read its metadata anymore.
Your hack will break all configurations that started to depend on your
hack. In what I proposed, GEOM provider will be presented to glabel (or
any other GEOM class) as 4kB provider and everything will just work,
also after adding proper support for 4kB sectors.
> 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'll repeat. You won't commit this patch, because it is totally wrong
solution and can only do a lot of damage in the future.
If you look forward, even temporary solutions can be done right.
Pawel Jakub Dawidek http://www.wheelsystems.com
pjd at FreeBSD.org http://www.FreeBSD.org
FreeBSD committer Am I Evil? Yes, I Am!
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 196 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-current/attachments/20100808/68c6a9a8/attachment.pgp
More information about the freebsd-current