> Kai Henningsen writes:
> > acahalan@cs.uml.edu (Albert D. Cahalan) wrote on 09.06.99 in
> > <199906090525.BAA05821@jupiter.cs.uml.edu>:
>
> >> Trying to do dynamic device numbers and/or names with the current system
> >> is a bad joke.
> >
> > I'm using that right now. Ok, so those numbers don't change all that
> > often, but when they do, it still works.
>
> I didn't say you couldn't find any hack at all. You found one in fact,
> and it sure looks like a bad joke.
Sorry if I don't share your ideas about humour.
> > scsidev can create aliases for all those scsi devices; specifically, it
> > can create aliases depending on scsi id data (manufacturer, model, serial
> > number). I use this and mount all my partitions (even swap) via those
> > names.
> >
> > It works fine as long as the kernel doesn't renumber the disk holding the
> > root and/or boot partition, because those happen before I get access. (And
>
> Well, that sucks. Devfs doesn't have that problem.
>
> > I could probably handle root from an initrd, but right now it doesn't seem
> > worth the bother.)
>
> Why such a bother? Devfs is easy to use, unlike your hack.
Setting up initrd is where the bother is. Scsidev won't need any change at
all. And would you please explain how devfs copes with this without having
an initrd? Where, exactly, does it find the information where the root
partition has migrated to?
Or do you mean to say it only solves those situations where the controller-
target pair doesn't change? Because scsidev doesn't share that particular
restriction.
> > All the other disks can be freely rearranged, and the machine will
> > automatically mount the right partitions. (Now if I also had something to
> > recognize renumbered partitions, like a file system uuid ... should be
> > easy to add, anyway.)
> >
> > This setup is slightly complicated by the r/o root mount, but I solve this
> > by allocating two small ram disks (on /tmp and /dev/scsi) the first time
> > around, which get thrown away once they're no longer needed.
>
> Arrrgh!!!
>
> Can't you see all the contortions you are going through?
Where's the problem with that? It's fast, it does what I want, it only
needs set up once (and that could be done by the distribution).
>If you need to
> mount two small ram disks to deal with the r/o root mount, something is
> very wrong. I'd say you have chosen an inappropriate solution.
Bull. That just shows that having only read-only file systems is awkward -
big surprise, we knew that already.
> Yes, your system does work. You found a way to avoid devfs,
But it's not "a way to avoid devfs". As far as I can make out, it gives me
something that devfs *doesn't* give me.
Maybe I need to show you my /etc/scsi.alias file to make you understand:
alias=QGP, manufacturer=QUANTUM, model=XP34301, devtype=disk, serial_number="474508450481"
alias=TXM, manufacturer=TOSHIBA, model="CD-ROM XM-4101TA", devtype=cdrom
alias=IDCRS, manufacturer=OEM, model=DCRS04Z, devtype=disk, serial_number=" 13034022"
alias=IDCAS, manufacturer=IBM, model=DCAS-34330, devtype=disk, serial_number="B3G17619"
alias=QAt, manufacturer=Quantum, model=XP34300, devtype=disk, serial_number="PCB=ZG54951879 U; HDA=MP61654259"
alias=IDGHS, manufacturer=IBM, model=DGHS18Z, devtype=disk, serial_number=" 680B2E55GK"
So: I can completely change my SCSI controller setup (say, invest in one
controller per device), completely renumber all the disks, and
/dev/scsi/QGP will still point to the same disk.
How do you do *that* with devfs?
>but you ended
> up with something far more complicated and kludgy. Considering the problems
> with your root filesystem, your system might even be less reliable.
"Problems"? "Less reliable"?
Go pull the other one, it has bells on it.
MfG Kai
-
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/