USB, FireWire, newer interfaces and disks

Trever Adams (trever_Adams@bigfoot.com)
Thu, 10 Jun 1999 04:29:54 -0600


I saw someone ask how we can handle disks on those newer interfaces
without scsi id's, eidi placement/jumper settings, or other physical
ways of finding the disk. I then read the persons post "Why I run
FreeBSD." I read something there that hit what I have been thinking for
a few weeks on the head, and lent validity.

First I must say, I am fairly new to Linux programming (3 to 4 years).
I am self taught in C, so my code isn't the best, and I am not versed in
the kernel yet (though I have spent about an hour a week reading patches
(beyond linux kernel) and the source to learn it). So all that I say
MUST be taken with a jar of salt.

Disk labeling: This is about our only choice for reliable systems if
the disks use FireWire or another interface (which, yes, I wish Linux
already supported, and that FireWire disks were out).

How does this work? Good question. I am not entirely sure what is the
cleanest way to do this. I am not sure how Sun partition and disk
labels work. Somewhere, somehow we need to be able to do two things.

Thing 1: We need a place to store an ID for the entire disk. This may
not translate directly (in kernel space to user space) as
/dev/somesuchdevice. It would likely just translate as something like
"FirewireDisk:Label" in kernel space, and some user space (very LIGHT
daemon) would have to translate it to /dev/somesuchdevice based on
something in /etc/firewire.conf or something like that.

Thing 2: This one involves raid and other similar setups, especially of
the software variety. Given that we ever have hot swap on the
non-hardware raid setups, this will become a must. The raid code (not
raid 0 (that is striping without parity isn't it?), obviously) must be
able to handle the removal of a disk, the creating of missing disk data
(or accessing it in the case of simple mirror) when it is accessed, and
upon the insertion of a new/blank/replacement drive into the interface
chain, it needs to be able to some how notify the super user (yeah, I
know, he is likely the one replacing the disk...), probably via system
logging or something, that he now needs to setup the new drive and tell
him what "LABEL", partitions/sizes, etc. to give the drive.

Thing 3: (USER SPACE) Actually two things. The daemon mentioned above,
and a tool to ease the "LABELING" and setting up of drives, especially
for the raid situation.

Again, take this with salt, but I have been thinking through this since
Linus gave his now infamous "there is no way to know which device is
what (yes, heavily paraphrased)" speech about USB. I am afraid on most
devices, he may be very right, on media (especially writeable), I
believe he is incorrect and we need a method such as this.

In thought,
Trever Adams

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/