Re: Accessing disks via their serial numbers.

On Mon, Jun 26, 2006 at 12:43:45PM +0000, Poul-Henning Kamp wrote:
In message <20060626113705.GC12511@xxxxxxxxxxxxxxxxx>, Pawel Jakub Dawidek writ
es:

And what is last sector occupied by ?

This is simlar situation to the most common problem with gmirror(8).
When people decide to put their file system onto a mirror, it will eat
partition's last sector, which isn't always safe.
When disk is already partitioned and file systems are there, you cannot
just take the last sector.

Of course you can not just take the last sector, nor any other sector
for that matter.

If you look at how everybody else (Veritas etc) does this, they reduce
the size of the filesystem by the number of sectors they steal.

File systems are not the whole world. MBR or BSDlabel or GPT can store
provider's size in the metadata, so when ad0, ad0s1 and ad0s1 starts at
the same physical offset, it knows which one to choose. Belive me or not
it is a real PITA.

If they can't adjust the filesystem size (either because the sector
is occupied or because they don't recognize the filesystem) they
refuse, leaving it up to the system administrator to solve the problem.

Then, administrator has to dump all data to some external storage,
repartition the disks, create file systems from the begining and restore
the data. Very user-friendly.

In this context I see your serial number proposal as a very poor
substitute for a sensible solution because:

1. It doubles the size of the GEOM mesh by creating an alias
for all disk devices at the bottom of the mesh.

Is that a problem? Are there any limitations in GEOM?
And remember, glabel is optional.

2. It doesn't provide a solution for gmirror or any other class.

Who said it will? I just mentioned where I found stealing last sector a
hard task. That's all. I never said that accessing disks via their
serial numbers will help. And actually it will help to solve different
problem. Sometimes you need to hardcode provider's name into gmirror's
(or whatever) metadata ('c' partition is one of the reasons), which asks
for troubles, because disk name /dev/ can change when you add/remove
another disk. This will leave you without your mirror device. Storing
serial number there will definitely help here.

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.

4. It prevents cold-state swapout of disk drives.

Why?

5. Not all diskdrives can be supported, some don't have serial
numbers you can read (USB-sticks seems particular bad).

Sure. And this is the reason we can't do it for those who have?

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.

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.
So if you don't want to work on more general solution, you should not
use it as an argument against less general one, leaving no alternatives.
This is your standard argument, Poul-Henning. Please try harder and be
constructive.

Let me provide few examples. Should we backout GEOM, because it doesn't
support mediasize changing, inserting provider between two existing ones
and because classes unloading is broken from the very begining?
Should we remove devfs, because it is not stable?
Should we remove jails, because there is no resourse limits support, no
multiple IPs support nor IPv6 support?

No, because it is better than what we had before and noone came with a
better solution.

I'm not saying we should accepts all hacks proposed, but I'm not trying
to design a hack here. This is why I brought this to arch@.
I've a hackish extension for glabel(8), which dives into ATA internal
structures to get disks serial number, but this is not what I'd like to
see in our CVS.

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

Attachment: pgpquxPc7WqfV.pgp
Description: PGP signature

Relevant Pages