lkml.org 
[lkml]   [1998]   [Aug]   [7]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: DEVFSv50 and /dev/fb? (or /dev/fb/? ???)
Terry L. Ridder writes:
> Hello Richard;
>
> Comments are below. I have attempted to snip out as much as possible
> for the sake of readability and to save bandwidth.
>
> Richard Gooch wrote:
> >
> > Terry L. Ridder writes:
> > > Hello Everyone;
> > >
> > > Some dev_fs's cheerleaders are attributing abilities to dev_fs
> > > which do not exist.
> >
> > And vice versa.
>
> I am not sure what you mean by this, so I will not even attempt
> to respond to it.

I mean: some detractors attribute failings to devfs which do not
exist.

> > > If you add a new SCSI controller to a system it is totally up to you
> > > to tell the kernel what order to probe the SCSI hosts. If you do not
> > > and you are using dev_fs /dev/sd/c0t3d0s1 and the SCSI host probing
> > > finds your new SCSI controller first you are out of luck. Because
> > > /dev/sd/c0t3d0s1 is no longer what you has before adding the new
> > > SCSI controller.
> > >
> > > So all these arguments that dev_fs "saves" you from the current
> > > SCSI rearranging are false. You still have to deal with the order
> > > in which SCSI hosts are probe.
> >
> > Incorrect. If you don't open your box and fiddle your controllers, you
> > are safe from SCSI rearranging. By far the most common operation is
> > that a SCSI device is removed/inserted. Moving controllers around is
> > far less common.
> > A typical situtation is where you have just one controller, but
> > devices are from time to time removed/inserted.
> > The single controller situtation would constitute the bulk of SCSI
> > systems.
>
> It is not incorrect. If a person adds a new SCSI controller to a system
> and does not explictly state what the SCSI host probing order should be
> there is absolutely nothing in dev_fs that would recognise this and
> prevent SCSI devices from being identified as /dev/sd/c0t3d0s0
> incorrectly.

I agree that devfs doesn't automagically solve this, It does however
provide the scsihosts= kernel parameter to deal with the numbering
issue. But that's besides the point.

> This is no different than the current /dev where the person does
> not take care in adding a new SCSI device. You have only now moved
> the problem to the SCSI controller level.

I'm sorry, you are simply wrong. You are arguing that because devfs
doesn't automagically deal with all possible SCSI reconfigurations,
that it doesn't solve some SCSI reconfigurations. That is not a
logical argument.

It is a simple fact that there are many SCSI systems where the
configuration of the controllers is not changed, although the
configuration of the devices is changed. No amount of arguing is going
to change this basic fact. Therefore, for the common case where the
controller configuration is stable, devfs provides a benefit for
people who fiddle their devices.

> Also, if and when I open a box up I am not doing it just to
> "fiddle" with anything, I am doing so because there is a definite
> purpose in doing so.

By "fiddle" I was not implying that there was no reasonable
justification to fiddling. Don't be so touchy. Read fiddle to mean
"change the configuration of your controllers" if you can't avoid
seeing negative connotations in the word "fiddle".

> I disagree quite strongly. In a server it is for more likely that I
> add or change a controller, than to change a hard drive.

This may be true for you, but it simply isn't true in general. Our
main fileserver here has 35 filesystems spread across 4
controllers, with a current capacity of over 100 GBytes. New discs are
added and old ones replaced on an ongoing basis, as drives die, are
bigger ones are installed and older ones are redeployed amongst our
network of workstations or secondary servers.
Devices are changed every few weeks (barring failures). It's been over
a year since a controller was added.

Our main supercomputer has over 50 GB of disc also with muliple
controllers. Many discs have died and been replaced, new ones
added. The controllers have not been changed since when we bought it
just over 3 years ago.

> I will also point out that a fair number of those who are using
> dev_fs are using it in a multiple controller scenario.

And a fair number have just a single SCSI controller (if at all). Even
an approximate ratio is unknown unless a poll was conducted.

> > Perhaps the ones you talk to do. Other don't care about the new names,
> > or are enthusiastic.
> >
> > ObMantra: no-one is forcing you to use the new names.
>
> Richard you are missing the point. It does not matter whether or not
> anyone is "forcing" anyone to use the new names, it matters at least
> to this one company in particular that if dev_fs goes in the kernel
> they will have nothing to do with linux. It is their decision.

That would be a silly and reactionary decision. It would be ridiculous
if Linux development were held to ransom by parties who could not deal
with the introduction of an entirely optional feature.

I have trouble believing that anybody could be that childish. You can
argue all you like about whether devfs is flawed, but for parties to
argue that some *optional* feature is unwanted is sufficient for them
to not use Linux is childish in the extreme.

Any business that was run along such lines would not last long. Such
hysterical reactions are unproductive. If there really are companies
out there who won't use Linux if the optional devfs is added, that is
not something the Linux community is likely to allow itself to be held
to ransom by.

Whether or not devfs makes it into the kernel, I am sure that it will
not be on the basis of some random company deciding to opt out because
they don't like the *optional* names. A company that were to make such
an irrational decision either has extremely stupid management or very
poor IT advice.

> > Please see above. Fiddling your controllers is much rarer. Therefore
> > the common case of removing/inserting devices is greatly helped.
>
> I disagree quite strongly. Given the improved reliability of hard
> drives compared to the early years, I am much more likely to add or
> change a controller, due to better scsi driver, better support from
> the vendor, preventive maintainance, than change a hard drive.

You have obviously led a charmed life. Or perhaps you haven't had to
administer large systems. Even us paying SGI top dollar for their
"special" drives didn't stop a few dying within a few months.
The simple facts are that hard drives die. They are less reliable than
controllers. I don't think you'll find anybody else on this list who
will disagree with this.

> > And as I have said, if there is sufficient demand, I can add
> > persistence to devfs itself. This is a side issue to the basic concept
> > of devfs.
>
> Richard, this is not a side issue, it is a basic design flaw in dev_fs.
> It should have been there from the every beginning, not treated as a
> "side issue".

It is a side issue. The main issue is having an automagically created
FS which has a more direct link between userspace and device drivers.
Persistence is secondary to the design.

> > > > Thinking technically, since when does someone use a letter as a
> > > > counter? You going to use a char in a for loop for your counter or an
> > > > int? For some very specific things where you want to say list off the
> > > > ascii character set you might do that, but I know I use an int when I'm
> > > > in need of a counter.
> > >
> > > What are you talking about?
> > > Please show me where in any of the kernel scsi code where a letter is
> > > being used for a counter.
> >
> > drivers/scsi/sd.c: sd_devname()
>
> You are definitely playing wih semantics here Richard.

No.

> In drivers/scsi/sd.c (linux-2.1.114) there are no for loops, while
> loops,
> do loops, etc of any kind.
> There are two sprintf's which do use 'a'.
> Calling that 'a' counter is really stretching it.

Conceptually that is a character counter. If you want to scan through
the SCSI devices from userspace, you do so like this: "sda", "sdb",
"sdc" and so on. There you need a literal character counter.

> > > > Another issue, what happenes when a drive doesn't respond to
> > > > SCSI probes? Happens all too often to me, and figuring out which drive
> > > > died would be MUCH harder to do w/ /dev/sda than w/ /dev/c0t0d0s0, not
> > > > impossible, but would certainly take a whole lot more time.
> >
> > Conveniently ignored, I note. He raises a valid point.
>
> I did ignore it because in my own mind have I am attempting to
> comprehend the System Administration style of those that use this
> as an arguement.

The style people have is often determined by the kinds of hardware
they have been exposed to. Just because you don't comprehend it
doesn't mean it is flawed.

> For nearly every system I am responsible for I have the following:
>
> A log book which has in it:
> What hard drive with vendor name, model number, serial number, scsi id,
> which controller it is attached to, filesystem type, whether it is part
> of a LVM group (HP-UX), md (linux), and mount point.
>
> In nearly 92% of all cases just by going to the log book I am
> able to tell exactly which drive, controller, etc is having problems.

And others have entirely different working environments. Their views
are equally valid.

> I personally do not rely on /dev anything when troubleshooting a
> problem.

So how do you mount things? How do you repartition?

> Yes some people may consider it "old fashion" but I still put labels
> on the hard drives which have nearly the same information as the log
> book.

Good for you. The places and work environments I've been exposed this
doesn't work so well.

> Also in 99.9% of the machines I am responsible for like machines are
> configured always the same way.
>
> So from my System Administration style this type of problem does
> not present itself.

So you have different problems than others. I know other sysadmins who
take a very different view from you. These people are very competent.
Just because you have a different scheme or work environment, doesn't
make you right or wrong. Just different. For some people
location-based device names are essential.

Regards,

Richard....

-
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.altern.org/andrebalsa/doc/lkml-faq.html

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