Re: devfs debate

[Andrew J. Anderson]

On Wed, 5 Aug 1998, Peter T. Breuer wrote:

> "A month of sundays ago Andrew J. Anderson wrote:"
>
> > These are the same screams of pain that SUN SunOS users use during the
> > transition to Solaris.  The difference there is that Solaris *forces* you
> 
> The screams are still there.  Ever tried to make the keyboard readable
> by mortals again after X dies?

You completely missed the point!  I'll say it again -- Solaris _forces_
you to use the new device scheme, devfs _does_not_.

> In contrast, suns _scsi_ naming scheme makes some sense.  But It don't
> see it as any better than sda = id 0, sdb = id 1.  sdaa = id 0 lun0,
> etc.  What's the fascination with humanly non-memorizable codes
> (shudder) as device names?

But that's not how it is now.  my sda is c0t3d0, my sdb is c0t5d0, my sdc
is c1t0d0, etc.  _if_ there were a one-to-one mapping like that I might
have a different opinion.  But again, that _is_not_ the behaviour of Linux
today.

> OK, have them, but put in the symbolic links with human names.

sigh.  that's what devfs _does_ if you let it.  Or you can _CHOOSE_ not to
even use it.  I'm not proposing to force you to use something different,
I'm asking you to acknowledge that there is a group of people in the Linux
community that would greatly benefit from this, and that there is no
reason to be opposing it as much as you have been.

> > > /dev/sda, /dev/sda[1-15] is simple.
> > 
> > Simple and IMNSHO totally inadequate as we grow into the so called
> 
> It only seems inadequate wrt multiple luns, and I suggest sdaa sdab etc
> for that.  I see no problem with sda being controller 0, id 0, ALWAYS.
> There can't be more than 15 units on a controller, can there?  So start
> higher up for the second controller (shudder, again; hopefully I'll
> never have two scsi controllers on a single machine).

So you're condemning those of us who do have multiple SCSI cards?  I have
one server with 5 dual channel cards that could't be run under linux
because it's SCSI support is inadequate to handle that without devfs or
something like it.

> > "enterprise computing" arena.  Tell me without digging through
> > /proc/scsi/scsi conslusively what /dev/sdc is?  You can't unless you're
> 
> I can if we change it always to be id 2 on controller 0.  That's a
> trivial change that doesn't break anything.  So where does your argument
> go now?

You're still thinking small.  Think data center.  Think data mining. 
Think *HUGE*.  Think 500 SCSI drives on one system (yes _hundred_).  Stop
thinking PeeCee.  Think SUN, Alpha.  Think terabytes. 

Now that you have that image, think 1,000 /dev/sd* entries and managing
that mess.  Let's see, /dev/sdaa-af are on controller 1, /dev/sdba-bf
are on controller 2, now quick -- what controller and device is /dev/sdjd?
I would claim, as others here would as well, I'm sure, that c10t4d0 is
easier to grok than counting your fingers to figure out that j is the 10th
letter of the alphabet.

> > Now, tell me what /dev/dsk/c0t0d0s0 is -- easy controller 0 target 0
> > device 0 slice 0.  The only ambiguity is which controller is 0?  That is
> 
> If that's important for you to know, so be it! I have the disks
> tagged with little stickers telling me if they're sda or sdb, etc.
> Why would I want to know unless I had physical contact with them?
> I don't see how it helps you either, since you'd still have to trace the
> wiring and examine the id's on the dipswitches.

I don't touch the hardware, ever! I remotely manage it. Because of the
unabiguousness of the naming convention I don't have to put cute little
stickers all over the machine and make it look like a 60's holdout.

And when one of those 500 drives fails (which statistics show will be once
ever few weeks in that size sample), I have to know which one to have
replaced.  That's why I have to know.  In a well designed and thought out
environment, it would be obvious which drive to replace without tracing
any wiring.  I do it every few weeks here and I have never had to trace
wiring or examine dip switches (think SCA and you'll know why I don't). 

> > space, not mere gigabytes.  We've got several hundred disks attached to
> > our SUN servers to do this.  Hmmmm. OK, let's extend /dev/sd? like the
> > /dev/pty?? devices so now we have /dev/sd?? to handle that many drives. 
> 
> This is a problem of scale.  It shouldn't be inflicted on those without
> problems of scale.

And devfs does this -- it allows those who don't have 500 drives to use
/dev/sd? and those who do to use the c0t0d0 nomenclature.

> > It may not be as "simple" as /dev/sda[1-15], but it also "screams" 
> > industry (SYSV) standard -- you know Solaris, HP-UX, IRIX, SCO, etc, etc.
> 
> Solaris = ugh in many respects like this. SCO ditto. These machines are not
> people-friendly. If you want to make your machine easier for a machine to
> administer, then don't be surprised when the human admins complain.

Yes, I agree Solaris isn't the best when it comes to a clean namespace,
nor is SCO, nor IRIX, nor HP-UX.  But the simple fact remans that there
_is_ a standard among the commercial unices that are in the data centers,
and if Linux has the _OPTION_ (that's the key here -- option) to have a
similar administrative interface, then the admins who aren't Linux fans
will be less apprehensive about learning a new system and trusting it.

Your clients hate SYSV.  OK, that's fine.  Don't use devfs.  Don't even
tell them about it.  But don't perpetuate a small system mentality on
Linux because you don't have a big enough system to benefit from the
changes.  Did you oppose SMP this much?  Look at the levels of complexity
that every part of the kernel has had added because of that, and SMP only
solves a "problem of scale" that most users don't have.

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
 Andrew Anderson                       http://amelia.db.erau.edu/~andrew/
               if(!(family_tree=fork())){redneck=TRUE;}