Date: Mon, 26 Jun 2006 19:10:35 +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: <20060626171035.GE12511@garage.freebsd.pl> In-Reply-To: <46568.1151325825@critter.freebsd.dk> References: <20060626113705.GC12511@garage.freebsd.pl> <46568.1151325825@critter.freebsd.dk>
next in thread | previous in thread | raw e-mail | index | archive | help
--lteA1dqeVaWQ9QQl
Content-Type: text/plain; charset=iso-8859-2
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
On Mon, Jun 26, 2006 at 12:43:45PM +0000, Poul-Henning Kamp wrote:
> In message <20060626113705.GC12511@garage.freebsd.pl>, Pawel Jakub Dawide=
k writ
> es:
>=20
> >> 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.
>=20
> Of course you can not just take the last sector, nor any other sector
> for that matter.
>=20
> 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:
>=20
> 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=20
> 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.
--=20
Pawel Jakub Dawidek http://www.wheel.pl
pjd@FreeBSD.org http://www.FreeBSD.org
FreeBSD committer Am I Evil? Yes, I Am!
--lteA1dqeVaWQ9QQl
Content-Type: application/pgp-signature
Content-Disposition: inline
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (FreeBSD)
iD8DBQFEoBULForvXbEpPzQRAhhyAJ9Q0xv7NxLe2cH+jVsRii+Lm4Ds3wCg0E5g
hPpGh9YRxaI7GFe+VWCYBv0=
=MWBW
-----END PGP SIGNATURE-----
--lteA1dqeVaWQ9QQl--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20060626171035.GE12511>