Re: Accessing disks via their serial numbers.

On Mon, Jun 26, 2006 at 06:46:19PM +0000, Poul-Henning Kamp wrote:
In message <20060626171035.GE12511@xxxxxxxxxxxxxxxxx>, Pawel Jakub Dawidek writ
2. It doesn't provide a solution for gmirror or any other class.

Who said it will?

I did.

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.

Wanna bet ?

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?

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.

No I will not.

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.

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, [...]

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:

1. A new journaled filesystem which initially does not support
subdirectories, FIFOs and symlinks.

2. A hare-brained hack to add journaling to an existing mission
critical (for FreeBSD) filesystem by means of layering
violations and quick hacks.

Yes, we commit the former, hoping it will grow to completion.

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.

I beg to differ: You are.

This is why I brought this to arch@.

You only brought it to arch@ because I asked you to, [...]

You suggested this, but the purpose was what I wrote.

--
Pawel Jakub Dawidek http://www.wheel.pl
pjd@xxxxxxxxxxx http://www.FreeBSD.org
FreeBSD committer Am I Evil? Yes, I Am!

Attachment: pgp3B2DvUOVAW.pgp
Description: PGP signature

Relevant Pages