UUIDs on drives

[Neil]

On Sat, Aug 16, 2008 at 8:55 PM, Derek Broughton <news at pointerstop.ca> wrote:
> ghe wrote:\
>> Good point. But they're still plugged into port #0 or #35 or something
>> on the USB chip. There's still an order at the hardware level, even
>> though it may not mean a lot at the software level.
>
> It can't mean _anything_ unless I always plug my USB devices into the same
> slots.

That sounds a lot like Windows (although of verrrrry different reasons):
If I plug a webcam on a XP machine into another USB slot it will stop
working untill I reinstalled the drivers, and then I have 50% chance
of having 2 webcams available




But seperate from this, it seems like a discussion that needs some
cleaning (for those that have just tuned in:
http://www.nabble.com/Re:-UUIDs-on-drives-(Derek-Broughton)-td18995373.html
is the entire discussion).

There are 2 sides to this. There will probably be no consenses
whatsoever, but only a nice and probably heated discussion, a good
one, because it involves quite important things.

Side 1: The abstraction of hardware addresses by software layers has
missed it's target, we might even be better of returning to names that
aply to the physical adresses involved.
If we had some coupling to whatever the disk is and where it is we
could simply replace a broken disk because we know where our disks
are. Just look at the adress, count a bit and pull and refit. We would
not be able to move the disk around (like to a new slot) but we would
always be able to find the correct drive. And as long as the hardware
doesn't move around the OS will know where it is.

This has some merrits, and some downsides
Merrits
1. As said: we'd know where our disks are at. When pulling one disk
for safe storage (because you really need to run bartPE for a
something and don't trust windoze (like the most of us)) you'd know
what disk to pull to save your /home.
2. Grub would always know where to boot from.

Downsides
1. This would never work properly for USB disks

I might add that we could even say the addresses should be coupled
directly. IE: IDE 2 slave would always be IDE4, no matter whether
other disks are connected. Sata 4 would always be SATA4, not
concerning whether 1, 2 and 3 are connected. This would make the
layout more solid. If a disk is attached to IDE 2 slave and a disk is
added to IDE 1 master the name of IDE4 would not change.
There are a lot of these UUID's so they will not repeat easily. We can
always double it's size.

Side 2: The abstraction of hardware addresses by software layers is
growing to perfection.

Merrits:
1. The UUID of a partition is coupled to quite solid things. You can
move the disk around and these things do not change.
2. USB sticks move a lot.

Downsides:
1. You cannot resize a partition without changing it's UUID. If a
partition is resized the UUID should ba changed in all the places it
is used. With, for example, a backup disk that moves between PC's this
is impossible
2. We need to search a bit to find where a disk phisically is.


I probably haven't captured all the arguments. Be free to add, but
please do not quote this to argue (except for the "I might add" bit
and the first part)

Neil
-- 
There are two kinds of people:
1. People who start their arrays with 1.
1. People who start their arrays with 0.