Re: Accessing disks via their serial numbers.
- From: "Poul-Henning Kamp" <phk@xxxxxxxxxxxxxx>
- Date: Mon, 26 Jun 2006 12:43:45 +0000
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.
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@xxxxxxxxxxx | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.
_______________________________________________
freebsd-arch@xxxxxxxxxxx mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-arch
To unsubscribe, send any mail to "freebsd-arch-unsubscribe@xxxxxxxxxxx"
- Follow-Ups:
- Re: Accessing disks via their serial numbers.
- From: Pawel Jakub Dawidek
- Re: Accessing disks via their serial numbers.
- References:
- Re: Accessing disks via their serial numbers.
- From: Pawel Jakub Dawidek
- Re: Accessing disks via their serial numbers.
- Prev by Date: Re: Accessing disks via their serial numbers.
- Next by Date: Re: What's up with our stdout?
- Previous by thread: Re: Accessing disks via their serial numbers.
- Next by thread: Re: Accessing disks via their serial numbers.
- Index(es):
Relevant Pages
|
