lkml.org 
[lkml]   [1996]   [Jun]   [24]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectDrive/partition identifying [Was: Ideas for v2.1]

This is another attempt to send this message, I tried it on last Thursday,
but now I'm certain it did not made to the list. No idea why...

[The current thread is SCSI device numbering; since I've been following
it, Micheal Neuffer said something which I describe here exist on some
other system.]

Ok, the whole thing started, because most of you don't like your
drives changing names once you remove/insert drives to your SCSI
chain. Some of you were using other Unixes, which have the quite well
working device names, which are in the form like `c0t0d0s0',
identifying the controller, target id, drive number, partition number,
respectively.

Fine, it allows to hook `alien' drives into your system, without
disturbing its operation, assuming you don't tinker with any of the
current drives. What it can't cope, is if you have more controllers,
and must move a drive from one to the other, or if you take your disk
to your friend, and can only attach it at a different ID, or different
controller... (In this case, it's not a real problem, since you would
mount it only after the system is up, and then you already know where
has it landed.)

I've been toying with a different idea for quite some long time, since
I've been using Amigas for some years on, (and Linux/m68k too, for a
shorter time.. :)

I saw someone (Leonard?) was thinking about identifying a disk as a whole,
that's almost okay, but I think it's not the right approach. I.e. you
usually don't think that 'Let me mount root on *THAT* drives' fourth
partition', but `let me mount the root partition'. So, what would
make this possible?

Let's make another fs, volfs, which is normally mounted on /vol. Ok,
I hear you crying (Gosh, another devfs fanatic, go away!), but not :)
This is not a general /dev replacement, but a way to refer to the
partitions (i.e. given block range of a particular disk) conveniently.

That most of you think it's enough to identify disks as a whole may be
because you (ehm.. we) are just lucky, and have a partitioning system
which has the feature, that you still have /dev/hda4, even if you
remove /dev/hda2.. On other systems, this may not be the case. Of
course, this may well depend on the partitioning *program*, i.e. you
may have this luck if you prepare your program to act this way, but
for example on an Amiga if you remove a partition, the partitions
which are after the removed one are reordered. But users there don't
care about this, because the partitions are not identified by their
position in the partition table, but their 'label'.

So let me show a hypothetical system, with volfs running...

You have a simple mtab like:
/vol/desktop-root / ext2 rw 0 1
/vol /vol vol rw 0 0
/proc /proc proc rw 0 0
/vol/work /opt/work ext2 rw 0 1
/vol/my-sources /usr/src ext2 rw 0 1

So as you may guess, /vol is a pseudo fs, like proc (but is not in the
procfs itself to let it live without procfs. IMHO this way it's
cleaner). /vol entries are built by the kernel in the partition
reading code, almost like currently, but tries to assign a `label' to
each partition, which is partition scheme dependent. On an Amiga
disk, you already have this label, but on MSDOS partitions, you may
have to read the boot block of the partition and maybe use that
'MSDOS5.0' place for some label. (This place may be difficult to find..)

To sidestep the flame, which I can await from being a devfs fanatic, I
would say again that these are not *normal* replacement for the block
device entries, just used for mounting it. Since mounting is done by
the superuser, we don't need to save the permissions on these
`devices'. If you really want to tinker with partitions, you would
use the normal hd[a-e], sd[a-e], xda, whatever entries, as you
wouldn't want to be fooled by those funny partition names, do you? :)
So you may still need those entries for setting up your system, but
after it is ready, you don't need to care, where are your partitions.

If you visit a friend with your disk, you may connect it to his
system, and let him say mount -t ext2 /vol/ancient-root /mnt (assuming
you `label' your partition in a `decent' way to at least minimize name
clashes) and he doesn't need to go to singleuser to prevent to mount
the wrong partitions. Or if you wanted to help him recovering a not
booting system, you just say: lilo: root=/vol/ancient-root ro, and
voila, *your* system is booting, and doesn't depend how the drives are
ordered. In fact, you can now reorder your disks any way you want;
add partitions anywhere; remove unused disks or partitions at your
will; cope with broken IDE disks which don't like to be slave, only
master; connect and renumber a SCSI disk, which used to be on a target
ID which is now in use, and so on. The booting won't blow in your
face, because you have a different drive on /dev/hdc than you used to,
but simply tells that it can't find /vol/redhat-var, and proceeds.

There is a drawback to booting with these devices, as lilo may not
find where your boot partition has gone (which is usually painful
anyway, so let me just assume you know how to tinker with boot
drives), and also additionally we should teach lilo, that
root=/vol/xxx doesn't need to be interpreted, since is not a fs, but
let it pass this `label' to the kernel, which will scan the attached
drives, and find its own root. Maybe it's that simple as using a
/dev/vol entry (similarly to /dev/nfs for nfs booting), and and option
like vol=/vol/xxx.

I see only a single `security' (in fact, paranoidity [sp?])
drawback... If you are using it, you can't get rid of the /vol
entries easily, as can be in the case of /dev. But that's ok for me,
since paranoids will use the old (normal) /dev, and take their own
paranoid measures. BTW, they usually don't like any other disks in
their system, so they won't use this approach anyway... But for the
people, this can make media exchange a whole lot easier..

Also, with this approach, we don't need 32-bit, 64-bit, 1024-bit or
whatever device numbers just to identify uniquely every partition, it
could fit nicely even in current systems (but certainly not in 2.0,
exactly because of the zero at the end.. :) [And also makes this
kdev_t growing transition a bit more transparent, IMHO]

Another point: we may have a separate /vol/disk and /vol/cdrom
directory, for obvious uses.. :) For removable drives, or cdroms, we
maybe need to be define logical names, like /vol/cdrom/sonycd for
drives, but these should be attachable from user space to ease the
support of multi-lun devices.

Comments?

Janos






\
 
 \ /
  Last update: 2005-03-22 13:37    [W:0.042 / U:1.188 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site