Date: Sun, 8 Aug 2010 14:36:53 +0200 From: Pawel Jakub Dawidek <pjd@FreeBSD.org> 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: <20100808123653.GC2037@garage.freebsd.pl> 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
--xo44VMWPx7vlQ2+2 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable 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? > >=20 > > 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. > >=20 > > Glabel is not for that and I don't agree for such obfuscation. >=20 > 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. --=20 Pawel Jakub Dawidek http://www.wheelsystems.com pjd@FreeBSD.org http://www.FreeBSD.org FreeBSD committer Am I Evil? Yes, I Am! --xo44VMWPx7vlQ2+2 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.14 (FreeBSD) iEYEARECAAYFAkxepOUACgkQForvXbEpPzTsugCgzpbR4hcr74ZwU9NFoiUibiyx eF0An1jqSoN7hiDyIAL0r80ZtVVei9GG =KZuE -----END PGP SIGNATURE----- --xo44VMWPx7vlQ2+2--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20100808123653.GC2037>