Accessing disks via their serial numbers.

Poul-Henning Kamp phk at phk.freebsd.dk
Mon Jun 26 13:15:25 UTC 2006


In message <20060626113705.GC12511 at garage.freebsd.pl>, 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.

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.


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.

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

3.	It adds a whole slew of issues with respect converting freeform
	serial numbers pathnames (What about serial numbers with hebrew
	letters in them ?)

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

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


And let me just conclude by saying that I fully appreciate what you
are trying to do, and I would very much like to see the problem solved
in a reliable and usable manner, but as always, I am firmly against
quick paste-over-the-problem solutions.

The right solution seems to be to work on grow(ufs)fs so that it
can reliably steal the last sector from a filesystem.

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.

Poul-Henning
      
[1]

VPD = "Vital Product Data" = serial numbers, model numbers, ECO
levels, firmware versions etc.

Rumours has it that an internal survey by IBM many years ago showed
that almost a third of all shutdowns performed by their technicians
were to verify information written on the circuitboards with fiber
pens.  The resulting ability to read it electronically was called
"Vital" because Field Engineers did not have to shut down your
system to read it.

-- 
Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20
phk at FreeBSD.ORG         | TCP/IP since RFC 956
FreeBSD committer       | BSD since 4.3-tahoe    
Never attribute to malice what can adequately be explained by incompetence.


More information about the freebsd-arch mailing list