Date: Mon, 26 Jun 2006 18:46:19 +0000 From: "Poul-Henning Kamp" <phk@phk.freebsd.dk> To: Pawel Jakub Dawidek <pjd@FreeBSD.org> Cc: John-Mark Gurney <gurney_j@resnet.uoregon.edu>, freebsd-arch@freebsd.org Subject: Re: Accessing disks via their serial numbers. Message-ID: <56651.1151347579@critter.freebsd.dk> In-Reply-To: Your message of "Mon, 26 Jun 2006 19:10:35 %2B0200." <20060626171035.GE12511@garage.freebsd.pl>
next in thread | previous in thread | raw e-mail | index | archive | help
In message <20060626171035.GE12511@garage.freebsd.pl>, Pawel Jakub Dawidek writ
es:
>> 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.
I will readily admit that we are suffering from legacy mistakes in
this area, both the in-band BSD label and the "Dangerously Dedicated"
mode were grave mistakes. They probably looked like good ideas at
the time, but they weren't. (Think very carefully about the lesson
here before you introduce new shortcuts).
Other products I've worked with know how to modify the labels as
necessary. The Veritas procedure to mirror the root is one of the
most scary scripts I've ever run, but it worked perfectly every time,
or gave up doing no damage.
Yes, writing code like that is hard, takes time, takes lots of testing,
but that is what it takes to deliver a quality product.
>> 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 my experience it only happens when the filesystem type is not
recognized, and at least for Veritas, using the '-f(orce)' option
made it proceeed.
>> 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.
Yes, that is a problem, not because of the size in absolute
numbers, but because they all refer to the same underlying
devices. Imagine the rush during open/close/taste time.
>> 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.
>> 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 '/' ?
>> 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.
>> 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?
Yes, I rather think so.
>> 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.
>> 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.
If you can't do it in an architecturally sensible fashion, we are
better of if you don't do it.
>Please try harder and be constructive.
I am trying very hard to be constructive here, but you are so defensive
of your own half-baked scheme that you are not even considering the
proposals I make.
>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.
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.
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 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, and the reason
I asked you to, was to get this discussion into the archives where
it belongs.
Poul-Henning
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
phk@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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?56651.1151347579>