From: Oliver Neukum <Oliver.Neukum@lrz.uni-muenchen.de>
To: Jesse Pollard <pollard@tomcat.admin.navo.hpc.mil>,
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 21:50:20 +0200 [thread overview]
Message-ID: <01032821502009.01508@idun> (raw)
In-Reply-To: <200103281905.NAA41794@tomcat.admin.navo.hpc.mil>
> > And what would you do if the names collide ?
>
> refuse to mount - give the admin time to fix them in single user mode
That means that it could only be used for optional filesystems otherwise
booting unattended is put into question.
A user set for a practical joke could prevent booting by leaving a medium in
the drive. You could add options for not considering removable media, etc,
but you get to a stage where you design workarounds. That'd be bad for core
filesystems. Thus the need for a second improved system remains.
Aside from that adding the name to /proc/partions is a good idea but not
universally usable.
> I'm still thinking about how the root filesystem could be mounted during
> boot where devfs and /proc are not yet mounted.
Enable the kernel command line to understand devfs names.
> 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
This is the problem. I wouldn't trust it.
> Is this reasonable? Perhaps not for small systems, but when lots of dynamic
> devices are available it is needed
It is reasonable. GUIs could use a unified way to learn volume names.
Regards
Oliver
next prev parent reply other threads:[~2001-03-28 19:52 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
2001-03-28 19:50 ` Oliver Neukum [this message]
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=01032821502009.01508@idun \
--to=oliver.neukum@lrz.uni-muenchen.de \
--cc=jesse@cats-chateau.net \
--cc=linux-kernel@vger.kernel.org \
--cc=pollard@tomcat.admin.navo.hpc.mil \
/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