public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Jesse Pollard <pollard@tomcat.admin.navo.hpc.mil>
To: Oliver.Neukum@lrz.uni-muenchen.de, jesse@cats-chateau.net
Cc: linux-kernel@vger.kernel.org
Subject: Re: Larger dev_t
Date: Wed, 28 Mar 2001 13:05:25 -0600 (CST)	[thread overview]
Message-ID: <200103281905.NAA41794@tomcat.admin.navo.hpc.mil> (raw)
In-Reply-To: <01032820130006.01508@idun>

Oliver Neukum <Oliver.Neukum@lrz.uni-muenchen.de>:
> 
> > My suggestion would be to add a filesystem label (optional) to the
> > homeblock of all filesystmes, then load that identifier into the
> > /proc/partitions file. This would allow a search to locate the
> > device parameters for any filesystem being mounted. If the label
> > is unavailable, then it must be mounted manually or via the current
> > structure. This would work for floppy/CD/DVD (although SCSI versions
> > would have a relocation problem for these devices).
> 
> And what would you do if the names collide ?

refuse to mount - give the admin time to fix them in single user mode
changing a volumn name only should not be prevented. How to fix... let
the admin look in the /proc/partitions, take one (I'd pick the second
one seen) and change its name. Mount the first using the devfs associated
name and verify that the contents are what is expected. Mount the second
and see what it should be. This situation should only occur via a dd copy
of an entire volumn; the procedure on copying should include changing the
copied volumn name... This is almost equivalent to having multiple mirror
partitions, in which case a "mount the first seen" would be reasonable.

> This might work for drives with unique identifiers in hardware, but for 
> anything else it is a nice addition, but I wouldn't identify an essential 
> partition that way. Furthermore you need to address removable media. There a 
> way to specify a drive opposed to a filesystem or medium is needed.

I didn't mean to say that there should be NO way to reach a specific drive.
There should be a devfs entry that corresponds to the entries in the
/proc/partitions list. This is what I think mount should do anyway.
First search the /proc/partitions list for the volumn; then use the
associated entry in devfs to actually do the mount. It's just a way
to allow the reorganization of volume to device name mapping.

I'm still thinking about how the root filesystem could be mounted during
boot where devfs and /proc are not yet mounted.

There should be a similar way to map removable media devices (even if it
takes using device serial numbers) to fixed device names. That way a
symbolic link could be created to point to the correct physical device:

ie: I want my SCSI tape drive (serial number 06408-XXX) to be called "tape" 

locate the serial number in /proc/scsi/scsi. use devfs name that
corresponds to this device (scsi2/target 6/lun/00 or similar) and
create a symbolic link for it. This does assume that the serial number or
equivalent is available to be searched for. It also assumes that the
devfs name can be derived from the entry in /proc/scsi/scsi (or where ever
the specification ends up).

Is this reasonable? Perhaps not for small systems, but when lots of dynamic
devices are available it is needed

-------------------------------------------------------------------------
Jesse I Pollard, II
Email: pollard@navo.hpc.mil

Any opinions expressed are solely my own.

  reply	other threads:[~2001-03-28 19:06 UTC|newest]

Thread overview: 95+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2001-03-27  9:29 Larger dev_t Andries.Brouwer
2001-03-27 18:48 ` Linus Torvalds
2001-03-27 19:28   ` H. Peter Anvin
2001-03-27 19:51     ` Linus Torvalds
2001-03-27 21:21       ` Alan Cox
2001-03-27 21:35         ` Linus Torvalds
2001-03-27 22:02           ` Andre Hedrick
2001-03-27 23:57             ` Linus Torvalds
2001-03-28 21:23               ` Martin Dalecki
2001-03-28 21:40                 ` H. Peter Anvin
2001-03-28 21:44                 ` Andre Hedrick
2001-03-27 22:16           ` Alan Cox
2001-03-27 22:16             ` H. Peter Anvin
2001-03-27 22:43               ` Russell King
2001-03-28 16:59                 ` Jeff Randall
2001-03-28  0:07             ` Linus Torvalds
2001-03-28  0:10               ` H. Peter Anvin
2001-03-28  0:24                 ` Linus Torvalds
2001-03-28  2:19               ` Alan Cox
2001-03-28  7:08                 ` Andre Hedrick
2001-03-28 21:32                 ` Martin Dalecki
2001-03-29  3:53                   ` Alan Cox
2001-03-29 11:02                     ` Martin Dalecki
2001-04-02 20:02                       ` Alan Cox
2001-04-03  7:25                         ` Martin Dalecki
2001-04-03 12:19                           ` Alan Cox
2001-04-03 12:13                             ` Martin Dalecki
2001-04-03 12:38                               ` Alan Cox
2001-04-04  8:08                                 ` Rogier Wolff
2001-03-30  6:54                   ` Kai Henningsen
2001-03-28 21:18             ` Martin Dalecki
2001-03-27 22:13         ` H. Peter Anvin
2001-03-27 22:55           ` Dan Hollis
2001-03-27 22:58             ` H. Peter Anvin
2001-03-27 23:42               ` Richard Gooch
2001-03-28  1:03             ` Paul Jakma
2001-03-28  1:35               ` Alexander Viro
2001-03-27 23:44           ` Andrew Pimlott
2001-03-28  0:28             ` Albert D. Cahalan
2001-03-28  3:58           ` Johan Kullstam
2001-03-28  4:23             ` Alexander Viro
2001-03-28 11:57             ` Jesse Pollard
2001-03-28 18:13               ` Oliver Neukum
2001-03-28 19:05                 ` Jesse Pollard [this message]
2001-03-28 19:50                   ` Oliver Neukum
2001-03-28 21:36             ` Martin Dalecki
2001-03-28 21:09           ` Martin Dalecki
2001-03-28 21:24             ` H. Peter Anvin
2001-03-28 21:46               ` Alexander Viro
2001-03-28 20:54     ` Martin Dalecki
2001-03-28 11:52   ` Pjotr Kourzanoff
2001-03-28 12:11   ` Tim Jansen
2001-03-27 19:27 ` Albert D. Cahalan
  -- strict thread matches above, loose matches on Subject: below --
2001-04-03 14:48 Wayne.Brown
2001-04-03 15:34 ` Bart Trojanowski
2001-04-02 21:59 Andries.Brouwer
2001-04-02 20:17 Andries.Brouwer
2001-04-02 21:45 ` Alan Cox
2001-04-03  7:28 ` Martin Dalecki
2001-04-03 10:09 ` Ingo Oeser
2001-04-03 12:06   ` Alan Cox
2001-04-03 12:20     ` Ingo Oeser
2001-04-03 12:15       ` Martin Dalecki
2001-04-03 12:53         ` Alan Cox
2001-04-03 16:05           ` Richard Gooch
2001-04-03 16:34             ` Alexander Viro
2001-04-03 16:58               ` Richard Gooch
2001-04-03 16:54             ` Alan Cox
2001-04-03 17:02               ` Richard Gooch
2001-04-03 12:41       ` Alan Cox
2001-04-03 23:28       ` Tim Wright
2001-03-27 22:38 Jesse Pollard
2001-03-27 22:44 ` H. Peter Anvin
2001-03-26 21:18 John Byrne
2001-03-26 22:12 ` Linus Torvalds
2001-03-26 23:41 ` Guest section DW
2001-03-25 12:31 Andries.Brouwer
2001-03-25 15:35 ` Wichert Akkerman
2001-03-25 16:15   ` Mitchell Blank Jr
2001-03-25 16:54     ` Michel Wilson
2001-03-25 17:12       ` Jeff Garzik
2001-03-25 17:00     ` Jamie Lokier
2001-03-25 17:07     ` Anton Altaparmakov
2001-03-25 17:37       ` Michel Wilson
2001-03-25 18:21   ` Guest section DW
2001-03-25 20:50     ` diego
2001-03-25 17:55 ` Gerry
2001-03-27  6:03 ` Linus Torvalds
2001-03-24 16:13 Andries.Brouwer
2001-03-24 14:25 Andries.Brouwer
2001-03-24 14:40 ` Jeff Garzik
2001-03-24 15:00   ` Alexander Viro
2001-03-25 14:22   ` Martin Dalecki
2001-03-25  3:24 ` Linus Torvalds
2001-03-25 14:35   ` Martin Dalecki

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=200103281905.NAA41794@tomcat.admin.navo.hpc.mil \
    --to=pollard@tomcat.admin.navo.hpc.mil \
    --cc=Oliver.Neukum@lrz.uni-muenchen.de \
    --cc=jesse@cats-chateau.net \
    --cc=linux-kernel@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox