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->