Date: Mon, 26 Jun 2006 22:25:37 +0200 From: Pawel Jakub Dawidek <pjd@FreeBSD.org> To: Poul-Henning Kamp <phk@phk.freebsd.dk> Cc: John-Mark Gurney <gurney_j@resnet.uoregon.edu>, freebsd-arch@freebsd.org Subject: Re: Accessing disks via their serial numbers. Message-ID: <20060626202537.GF12511@garage.freebsd.pl> In-Reply-To: <56651.1151347579@critter.freebsd.dk> References: <20060626171035.GE12511@garage.freebsd.pl> <56651.1151347579@critter.freebsd.dk>
next in thread | previous in thread | raw e-mail | index | archive | help
--oFbHfjnMgUMsrGjO Content-Type: text/plain; charset=iso-8859-2 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Jun 26, 2006 at 06:46:19PM +0000, Poul-Henning Kamp wrote: > In message <20060626171035.GE12511@garage.freebsd.pl>, Pawel Jakub Dawide= k writ > >> 2. It doesn't provide a solution for gmirror or any other class. > > > >Who said it will? >=20 > I did. >=20 > Solving the harder problem adequately would also give you solution > for g_mirror, whereas just doing the quick&dirty hack would give > us bugwards compatibility issues for the next N years, even if > somebody more inclined to solve problems right subsequently does > the right thing. I've no idea how it is related to the subject beeing discussed here. Please read again. > >> 3. It adds a whole slew of issues with respect converting freeform > >> serial numbers pathnames (What about serial numbers with hebrew > >> letters in them ?) > > > >Heh... It doesn't seem to be a problem for > >UFS/NTFS/ReiserFS/Ext2FS/MSDOSFS labels. >=20 > Wanna bet ? >=20 > Does g_label even bother to reject label names which contains '/' ? No. I removed those checks, because users wanted to use such functionality. It was discussed on FreeBSD mailing lists. > >> 4. It prevents cold-state swapout of disk drives. > > > >Why? >=20 > Because /etc/fstab contains the serial number of the disk you just > junked and the new one has a different serial number. It doesn't prevent user from doing it. It is a tool, not policy. User should be aware of what he is doing, this is quite straight-forward. > >> The right solution seems to be to work on grow(ufs)fs so that it > >> can reliably steal the last sector from a filesystem. > > > >Are you going to implement it? That's not an argument, Poul-Henning. > >Quite everything can be refused using "the ideal solution will be..." > >argument. >=20 > No I will not. >=20 > I do suspect however, that after a lot of pointless discussions, > you will end up implementing it this way, because I am surely going > to put as many roadblocks in front of your hackish scheme as I can. Fortunately, FreeBSD is not OpenBSD and you are not Theo. Funny, I didn't gave any complete or even half-complete scheme to review. I just started discussion to design scheme, which will allow to fetch various attributes from the disks. And this is why I can't understand your point at all. What hacks are you talking about? > >> Finally, I am not against giving meaningful access to VPD[1] for disks, > >> but I think we should have a unified subsystem for that, as all sorts > >> of other hardware also have VPD data that would be relevant. > > > >Again. Let's say I've time to work on such functionality for disks only. >=20 > Then you should not even begin to touch it. And who is saying that... > >Let me provide few examples. Should we backout GEOM, because it doesn't > >support mediasize changing, [...] >=20 > There is a big difference between something which is architecturally > sound but incomplete and something which is an architectural mess. What exactly is a mess you are talking about? > We don't back out the former, we complete them, and hopefully > everybody had learned by now to not even commit the latter in the > first place. Who complete them? This what you keep forgetting. Maintaining the code is no less important. > Let me give you two relevant examples to think about: >=20 > 1. A new journaled filesystem which initially does not support > subdirectories, FIFOs and symlinks. >=20 > 2. A hare-brained hack to add journaling to an existing mission > critical (for FreeBSD) filesystem by means of layering > violations and quick hacks. >=20 > Yes, we commit the former, hoping it will grow to completion. >=20 > No, we don't commit the latter because it will be a maintenance > nightmare from day 1. I'm not going to discuss gjournal with you, because you simply won't take time to understand how it works. The only layering violation which exists there is because GEOM is not that flexible as it should be. But it will be removed. GJorunal has a maintainer. Simlar mechanism is implemented in Linux and works quite well there. > >I'm not saying we should accepts all hacks proposed, but I'm not trying > >to design a hack here. >=20 > I beg to differ: You are. >=20 > >This is why I brought this to arch@. >=20 > You only brought it to arch@ because I asked you to, [...] You suggested this, but the purpose was what I wrote. --=20 Pawel Jakub Dawidek http://www.wheel.pl pjd@FreeBSD.org http://www.FreeBSD.org FreeBSD committer Am I Evil? Yes, I Am! --oFbHfjnMgUMsrGjO Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (FreeBSD) iD8DBQFEoELBForvXbEpPzQRAlq0AKDgTrKvwfaWuCzyHuBatWvDGL29TQCghJQ2 /rz5TkhJrB7kHJbnWoIyRhU= =iWks -----END PGP SIGNATURE----- --oFbHfjnMgUMsrGjO--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20060626202537.GF12511>