>
> linux-kernel-digest Friday, 8 October 1999 Volume 01 : Number
4582
>
> In this issue:
>
> Re: devfs again, (was RE: USB device allocation)
> Re: devfs again, (was RE: USB device allocation)
> RE: PUBLIC CHALLENGE: (was RE: devfs again, (was RE: USB device a lloc
ation) )
> Re: how to write get_block?
> Re: devfs again, (was RE: USB device allocation)
> Re: devfs again, (was RE: USB device allocation)
> Re: devfs again, (was RE: USB device allocation)
> [patch] fixed mtrr support for intel P6
> Re: PUBLIC CHALLENGE: (was RE: devfs again, (was RE: USB device alloc
ation) )
> Re: PUBLIC CHALLENGE: (was RE: devfs again, (was RE: USB device a lloc
ation) )
> Re: 2.2.13pre15 aic78xx probs
> File-op
> RE: PUBLIC CHALLENGE: (was RE: devfs again, (was RE: USB device a lloc
ation) )
> Re: PUBLIC CHALLENGE: (was RE: devfs again, (was RE: USB device alloc
ation) )
> kswapd priority
> Re: USB device allocation
> Larger dev_t field
> (2.2.12) attempt to access beyond end of device
> Re: devfs again, (was RE: USB device allocation)
> RE: PUBLIC CHALLENGE: (was RE: devfs again, (was RE: USB device a lloc
ation) )
> Re: devfs again, (was RE: USB device allocation)
> RE: devfs again, (was RE: USB device allocation)
> RE: PUBLIC CHALLENGE: (was RE: devfs again, (was RE: USB device a lloc
ation) )
> RE: PUBLIC CHALLENGE: (was RE: devfs again, (was RE: USB device a lloc
ation) )
> Re: PUBLIC CHALLENGE: (was RE: devfs again, (was RE: USB device alloc
ation) )
> RE: devfs again, (was RE: USB device allocation)
> Re: Potential SCSI system bottleneck.
> Re: how to write get_block?
> RE: devfs again, (was RE: USB device allocation)
> Re: devfs again, (was RE: USB device allocation)
>
> See the end of the digest for information on subscribing to the
linux-kernel
> or linux-kernel-digest mailing lists.
>
> ----------------------------------------------------------------------
>
> From: Stephen Frost <sfrost@mail.snowman.net>
> Date: Fri, 8 Oct 1999 18:02:11 -0400 (EDT)
> Subject: Re: devfs again, (was RE: USB device allocation)
>
> On Thu, 7 Oct 1999 danielt@digi.com wrote:
>
> > 90% of the objections to having devfs in the kernel
> > are easily solved with "well don't use it then".
> > The remaining objections can be or _have_been_
> > dealt with in a rational manner.
> >
> > I personally do not use MISC binaries. I do not
> > use CPU's that lack FPU's. I have no FDDI or ATM
> > cards. I rarely use a system that has a sound card.
> >
> > All of these things are in the kernel, and I wouldn't
> > suggest removing them just because they are "unUnixlike"
> > or that I personally have no use for them.
> > I do NOT compile options I do not need/use into my kernels.
>
> This does not mean we should be everything into the kernel we can,
> so long as we can make it optional.
>
> Stephen
>
>
> Please read the FAQ at http://www.tux.org/lkml/
>
> ------------------------------
>
> From: Horst von Brand <vonbrand@inf.utfsm.cl>
> Date: Fri, 08 Oct 1999 13:38:01 -0400
> Subject: Re: devfs again, (was RE: USB device allocation)
>
> David Ford <david@kalifornia.com> said:
> > Horst von Brand wrote:
> > > Do the changes stick after a reboot? After a crash (or power outage)?
> > > Can I rename the files, and the changes stay?
>
> > if a userland daemon is sitting in the call path and catches the change
and
> > updates a config file, the update is retained just dandy.
>
> Great.
>
> chown(2) is now:
>
> - call kernel
> - kernel contacts userland daemon
> - daemon starts, reads database of managed files
> - daemon looks up the file being chown(2)ed
> - daemon grabs configuration file, locks it
> - daemon grovels around lucking for right line to fix
> - daemon writes out changed file, unlocks it
> - daemon tells kernel OK
> - kernel changes permissions (perhaps calling daemon again)?
> - system call returns
>
> That will look fine in lmbench, that's for sure.
>
> > again, this is silly. it really is. change is always forthcoming.
when you
> > stop changing, you stop learning and you stagnate and the world passes
you
> > by.
>
> Agreed. Insisting that a rather trivial naming mechanism solves all the
> problems with device management is silly. Even more so as it introduces as
> many problems as it really solves, only harder ones. And most of the
> problems it "solves" it just pushes into some dark corner, without really
> doing anything about them.
>
> > instead of thinking of how this horrible idea impacts you, think of what
> > possibilities may lie ahead. improve, don't disparage.
>
> I'm not being impacted by it, personally. Not directly, that is. But if
the
> Linux kernel gets screwed up because of too many "bright ideas" that just
> HAVE to be in the kernel for "possibilities ahead", I _do_ get impacted.
> I'm for bright ideas, I'm for change in the kernel. I'm against "just put
> it in the kernel, the kernel hackers will make it work somehow".
>
> Please, read "The Mythical Man Month" for a real horror story of where
> "possibilities ahead" got a real operating system. Look at the ISO
standard
> networking protocols, which were also invented by people with stars in
> their eyes about "possibilities ahead". Same with the original Apple Mac:
> Nice idea, woefully underpowered and overpriced. A certain software giant
> also lives on promising "possibilities ahead", and they (with all their
> resources!) haven't ever been able to deliver.
>
> Thanks, but no.
> - --
> Dr. Horst H. von Brand mailto:vonbrand@inf.utfsm.cl
> Departamento de Informatica Fono: +56 32 654431
> Universidad Tecnica Federico Santa Maria +56 32 654239
> Casilla 110-V, Valparaiso, Chile Fax: +56 32 797513
>
>
> Please read the FAQ at http://www.tux.org/lkml/
>
> ------------------------------
>
> From: Alexander Viro <viro@math.psu.edu>
> Date: Fri, 8 Oct 1999 13:41:03 -0400 (EDT)
> Subject: RE: PUBLIC CHALLENGE: (was RE: devfs again, (was RE: USB device a
lloc ation) )
>
> On Fri, 8 Oct 1999, Shawn Leas wrote:
>
> > I'm not sure I understand how device nodes on UFS/ext2/etc could be
> > pseudolinks to in-core quasi mount points. Don't get me wrong, I
> > believe you, I just lack understanding.
>
> Erm... First of all, _every_ inode we are working with is in-core one.
> Device inodes are interesting beasts - for some operations you want to
> deal with them as with normal on-disk inodes (chown, etc.), for some you
> are dealing with the device (e.g. you can open the device on r/o
> filesystem with O_WRITE, etc.). There is a lot of special-case code in
> fs/* just for dealing with those special cases. Moreover, when we are
> dealing with mount/umount we are playing interesting tricks with fake
> struct file just to initialize the sucker. Ditto for RAID, etc. Most of
> that stuff would go away if we would keep two in-core inodes instead of
> one - one of them being the inode from filesystem (bearing things like
> ownership, etc.) and another being purely internal. Different device
> inodes with the same major/minor would have different fs-related inodes
> and the same device-related one. Part of the inode methods belongs to the
> former, part - to the latter. Device-related inodes should live on a
> separate struct super, not mounted anywhere. Dynamic device
> creation/removal belongs there. Fs-related inodes (in-core inodes, that
> is) just refer to the device-related ones (linkage done in
> init_special_inode() for normal filesystems). BTW, devfs is going to have
> an interesting time implementing some analog of revoke() - it can be
> mounted many times and VFS code is not too happy with such things.
>
>
> Please read the FAQ at http://www.tux.org/lkml/
>
> ------------------------------
>
> From: Andrea Arcangeli <andrea@suse.de>
> Date: Fri, 8 Oct 1999 19:49:27 +0200 (CEST)
> Subject: Re: how to write get_block?
>
> On Fri, 8 Oct 1999, Alexander Viro wrote:
>
> >That's it. write() does lock the page before writing to it/allocating new
> >blocks/etc. _That_ protection should be enough to avoid several callers
of
> >write() messing with each other.
>
> Except the fact that two writers writing 100byte each one will produce a
> 100byte long file and not a 200byte long file as the user expected. And
> btw NFS needs to be atomic at the write() level, line 415 of rfc1094:
>
> file after the write has completed. The write operation is atomic.
> Data from this "WRITE" will not be mixed with data from another
> client's "WRITE".
>
> What I would like is to have a three level semaphore with three kind of
> locks:
>
> 1) read
> 2) write-serialized (allow-readers)
> 3) truncate
>
> Lots of readers can enter at the same time of write-serialized. But only
> one write-serialized event can enter the critical section at once.
>
> And the `truncate' locking instead enters only if nobody else is grabbing
> locks and forbids everybody else to enter.
>
> I think it's safe as write(2) only enlarges the i_size so any reader won't
> risk to read beyond the end of the inode.
>
> During truncate() instead everybody will block and so there won't be any
> race.
>
> With this design all reads can be parallel to writes. But only one
> write(2) can happen at once so there won't be any i_size race and NFS will
> be happy too.
>
> I really don't think it make sense to let write(2) to be SMP parallel as
> it would be unreliable and thus useless. So basically allowing more writes
> to enter the critical section looks an useless improvement and lose of
> robustness to me.
>
> Andrea
>
>
> Please read the FAQ at http://www.tux.org/lkml/
>
> ------------------------------
>
> From: Horst von Brand <vonbrand@inf.utfsm.cl>
> Date: Fri, 08 Oct 1999 13:41:37 -0400
> Subject: Re: devfs again, (was RE: USB device allocation)
>
> David Ford <david@kalifornia.com> said:
>
> [...]
>
> > One must also be cognizant of the fact that by using devfs, you will
> > always have the right major/minor etc even from release to release. No
> > fussing about a MAKEDEV script that didn't get updated.
>
> Exactly! It will _never_ happen that you've got devfsd-2.4.2 with your
> shiny new 2.5.3 kernel, that needs devfsd-2.5.0 at least.
> - --
> Dr. Horst H. von Brand mailto:vonbrand@inf.utfsm.cl
> Departamento de Informatica Fono: +56 32 654431
> Universidad Tecnica Federico Santa Maria +56 32 654239
> Casilla 110-V, Valparaiso, Chile Fax: +56 32 797513
>
> Please read the FAQ at http://www.tux.org/lkml/
>
> ------------------------------
>
> From: Dan Hollis <goemon@sasami.anime.net>
> Date: Fri, 8 Oct 1999 10:41:14 -0700 (PDT)
> Subject: Re: devfs again, (was RE: USB device allocation)
>
> On Fri, 8 Oct 1999, Horst von Brand wrote:
> > Not my point, I was saying that I must now _also_ take care of not
> > hijacking a name. But you don't have to mess with names if you don't use
> > devfs. What if I decide to set up a full chinese version of Linux, with
> > chinese device names? Now I can't even begin of thinking in using the
stock
> > kernel...
>
> Which chinese version of Linux uses chinese device names? AFAIK most
> (all?) distributions use the "standard" names, which is basically the same
> as if it had been kernel policy anyway. Change device names at your own
> peril -- many programs are hardcoded to fixed device names. (The kernel,
> and init come to mind).
>
> - -Dan
>
>
> Please read the FAQ at http://www.tux.org/lkml/
>
> ------------------------------
>
> From: Stephen Frost <sfrost@mail.snowman.net>
> Date: Fri, 8 Oct 1999 18:10:30 -0400 (EDT)
> Subject: Re: devfs again, (was RE: USB device allocation)
>
> On Thu, 7 Oct 1999, Steve Dodd wrote:
>
> > On Thu, Oct 07, 1999 at 03:00:44PM -0400, Horst von Brand wrote:
> >
> > > This is _horrible_. Suddenly there are files whose attributes aren't
fixed
> > > by chmod(1)/chown(1), but by a magic file.
> >
> > Couldn't devfs forward permission changes via chmod/chown to the user
space
> > daemon, which could update the database / magic file?
>
> You're now hacking around the flaw, not a nice way to do it.
>
> Stephen
>
>
> Please read the FAQ at http://www.tux.org/lkml/
>
> ------------------------------
>
> From: Matan Ziv-Av <matan@svgalib.org>
> Date: Fri, 8 Oct 1999 19:44:18 +0200 (IST)
> Subject: [patch] fixed mtrr support for intel P6
>
> Hi,
>
> I attach a patch that adds the ability to set (and read) the fixed
> mtrrs on an intel P6 cpu (PPro, PII, PII). The fixed mtrrs are the ones
> controling the accesses to memory in the low 1MB of physical memory.
> The patch is against 2.3.19, and it only changes the file
> arch/i386/kernel/mtrr.c.
>
> The patch, also changes the implementation of the file /proc/mtrr, so
> that it is recalculated every time it is read, rather than stored in
> memory. This means a bit more work every time the file is read (which
> should not be very often), but saves some unswappable kernel memory.
>
> I tested the patch on three systems with a Celeron CPU, where it works,
> and 2 with older cpus, where it has no affect (as it should). I did not
> test it on a non intel cpu that has mtrrs. I also not tested it on an
> SMP system.
>
>
----------------------------------------------------------------------------
----
>
> - --
> Matan Ziv-Av. matan@svgalib.org
>
>
>
>
>
> Please read the FAQ at http://www.tux.org/lkml/
>
> ------------------------------
>
> From: Stephen Frost <sfrost@mail.snowman.net>
> Date: Fri, 8 Oct 1999 18:26:23 -0400 (EDT)
> Subject: Re: PUBLIC CHALLENGE: (was RE: devfs again, (was RE: USB device
alloc ation) )
>
> On Thu, 7 Oct 1999, Matthew Dharm wrote:
>
> > On Thu, 7 Oct 1999, Stephen Frost wrote:
> >
> > > /dev can be cleaned up using rm(1). devfs at one point used tarballs
> > > to handle permissions, now it doesn't, it uses a configuration file,
which
> > > makes it even more strange and un-filesystem like. I don't use a
config file
> > > to specify my permissions on my / partition.
> >
> > I hate to point this out... but if the objection is to configuration
> > files, then what about /etc/fstab and the mount options that allow me to
> > mount CD-ROM drives and MS-DOS/FAT32 partitions as various users with
> > various permissions?
> >
> > The use of a config file to determine permissions/ownership is not
foreign
> > to the kernel or filesystems.
>
> But it is to files inside a filesystem..
>
> Stephen
>
>
> Please read the FAQ at http://www.tux.org/lkml/
>
> ------------------------------
>
> From: Dan Hollis <goemon@sasami.anime.net>
> Date: Fri, 8 Oct 1999 10:51:56 -0700 (PDT)
> Subject: Re: PUBLIC CHALLENGE: (was RE: devfs again, (was RE: USB device a
lloc ation) )
>
> On Fri, 8 Oct 1999, Horst von Brand wrote:
> > > And you are right: the size of /dev on a desktop or small server is
> > > not hard to deal with. With devfs it is easier. Some of the things
> > > that the current devfs patch change could (and IMHO should be)
> > > changed even without devfs (the sd{a,b,c,d,...} brain-damage comes
> > > to mind).
> > mount(8), particularly "mount -L label", "mout -U uuid"
>
> Tape drives. Generic devices. Complete braindamage.
>
> - -Dan
>
>
> Please read the FAQ at http://www.tux.org/lkml/
>
> ------------------------------
>
> From: John Kennedy <jk@csuchico.edu>
> Date: Fri, 8 Oct 1999 11:39:04 -0700
> Subject: Re: 2.2.13pre15 aic78xx probs
>
> - --IJpNTDwzlM2Ie8A6
> Content-Type: text/plain; charset=us-ascii
>
> On Fri, Oct 08, 1999 at 09:26:02AM -0400, Doug Ledford wrote:
> > Turn off the PROBE ALL LUNS option in the SCSI config then promptly file
a bug
> > report with the Yamaha CD-RW devision about the firmware in their
devices.
>
> Fair enough. (:
>
> Didn't change that between pre14 and pre15 though:
>
> [diff -u linux-2.2.13pre1[45]/.config]
> --- linux-2.2.13pre14/.config Mon Sep 27 20:31:25 1999
> +++ linux-2.2.13pre15/.config Wed Oct 6 05:35:27 1999
> @@ -207,6 +207,7 @@
> # CONFIG_SCSI_INIA100 is not set
> # CONFIG_SCSI_NCR53C406A is not set
> # CONFIG_SCSI_SYM53C416 is not set
> +# CONFIG_SCSI_SIM710 is not set
> # CONFIG_SCSI_NCR53C7xx is not set
> # CONFIG_SCSI_NCR53C8XX is not set
> # CONFIG_SCSI_SYM53C8XX is not set
>
> I do have it enabled though:
>
> [grep _LUN linux-2.2.13pre1[45]/.config]
> linux-2.2.13pre14/.config:CONFIG_SCSI_MULTI_LUN=y
> linux-2.2.13pre15/.config:CONFIG_SCSI_MULTI_LUN=y
>
> I don't see anything under drivers/scsi/aic7xxx* that looks different
> except for aic7xxx.o.
>
> - --IJpNTDwzlM2Ie8A6
> Content-Type: application/pgp-signature
>
> - -----BEGIN PGP SIGNATURE-----
> Version: PGPfreeware 5.0i for non-commercial use
> MessageID: obU81/SpDCwkvN1xJvWnvPm+XSBLJX0e
>
> iQA/AwUBN/46R2/ftxGdcmZ0EQJZ+QCfVX2ghCIuNwi2EZ0cgvt1MXt+xGcAni7w
> YqtcdGHaf5iNUhxRR7a2VQOW
> =84Ey
> - -----END PGP SIGNATURE-----
>
> - --IJpNTDwzlM2Ie8A6--
>
> Please read the FAQ at http://www.tux.org/lkml/
>
> ------------------------------
>
> From: Koushik Chakraborty <kchak@iitk.ac.in>
> Date: Fri, 8 Oct 1999 23:31:48 +0530 (IST)
> Subject: File-op
>
> Hi,
> There are a lot of function pointers associated with file_op (in strct
> file ) or say sock_op etc. I want to know where exactly in linux kernel
> code are these bound to specific functions (e.g, where f_op->read is
> assigned to the appropraite function say for a socket fd).
>
> Thanks,
> Koushik
>
>
> Please read the FAQ at http://www.tux.org/lkml/
>
> ------------------------------
>
> From: Shawn Leas <SLEAS@videoupdate.com>
> Date: Fri, 8 Oct 1999 13:32:41 -0500
> Subject: RE: PUBLIC CHALLENGE: (was RE: devfs again, (was RE: USB device a
lloc ation) )
>
> From: Horst von Brand [mailto:vonbrand@inf.utfsm.cl]
> Subject: Re: PUBLIC CHALLENGE: (was RE: devfs again, (was RE: USB device
> allocation))
>
> >even much earlier). AFAIU, glibc is also prepared for a larger dev_t. The
> >big problem is doing it, as it will break _everything_.
>
> Thanks for agruing my poitn that we should through away
> major/minor pairs.
>
> >> sda, sdb, and sdc, and you remove sdb... Whoops, sdc is sdb!!! Not
> >> with devfs, it addresses devices by hardware address when applicable,
> >> and provides symlinks to the oldstyle names like /dev/sdb.
> >You are just shifting one naming convention to another one, that is as
bad
> >or worse. No win there.
>
> Not really, the only "hardware path" to a device from userland
> is serially addressing driver/driver-node by major/minor pair,
> which serially address the devices. This is why sda and hda
> have the names they have.
>
> >> I'm not going to go into how difficult PCMCIA, USB, et all is w/out
> >> something as elegant as devfs.
>
> >OK, this is the only argument you've got left. If you won't go into it,
it
> >surely means that it isn't really that solid. Case closed.
>
> Big fat LIE.
>
> - -Shawn
>
> Please read the FAQ at http://www.tux.org/lkml/
>
> ------------------------------
>
> From: Horst von Brand <vonbrand@inf.utfsm.cl>
> Date: Fri, 08 Oct 1999 14:26:08 -0400
> Subject: Re: PUBLIC CHALLENGE: (was RE: devfs again, (was RE: USB device
alloc ation) )
>
> Jan Echternach <echter@informatik.uni-rostock.de> said:
>
> [...]
>
> > Don't be scared of that. Devfs means dynamic devices directory. And
> > chown/chmod never worked well in dynamic situations. You certainly
> > don't expect
> >
> > chgrp lp /var/spool/lp/* && chown u+rw /var/spool/lp/*
> >
> > to produce any permanent results.
>
> Very true. The files in the print spool aren't permanent, and shouldn't
> be. But what has that to do with the permissions on my quite permanent (I
> hope) hard disk, tape drive, modem, and so on?
>
> > You have to reconfigure (or even
> > recompile) the print service to get different permissions. Another
> > example: Permissions for new mail folders created by my MUA are
> > compiled into /opt/bin/mutt. Not even a configuration file.
>
> "New mail folders when created". You can change the permissions if you
want
> to, and the new permissions stay put, don't they? That's exactly what I
> need for devices!
>
> > If /dev is frequently cleaned up by a script and re-populated with
> > MAKEDEV whenever new hardware gets attached the situation is the same.
>
> Wrong approach. Check for _new_ devices, add them via MAKEDEV with default
> permissions; think a fev seconds (or agonize for several days) on the
> permissions they should have. Set permissions, and go on with life.
>
> > The configuration file for permissions/ownership would be MAKEDEV.
>
> It is, for _default_ values. Sure, you could update it each time. Or make
> it take default permissions from a configuration file. no big sweat.
>
> > It would be enough for devfs to remember permission/ownership changes
> > of a device file until it gets deleted to retain Unix-style behaviour.
>
> Great idea! That is just what the boring ext2 gives you.
>
> > And a reboot can mean deletion of all device files. I don't see
> > anything wrong with defining access/security policy for hardware
> > devices in a configuration file.
>
> I do. That way you can't get back the configuration you had when power
went
> down. It means throwing out (for no good reason, to boot) the whole idea
of
> "a device is a file, and is handled exactly like any other file" that is
> one of the cornerstones of Unix. I.e.,
chown(1)/chmod(1)/mv(1)/rm(1)/ln(1),
> also tar(1)/cpio(1) won't work as they should. Note the (1), those are
> down-to-earth, everyday Unix commands. And you propose to break them just
> like that.
>
> > The one change that you have to accept (if you decide to use devfs, or
> > any other method for dynamic device files) is that /dev won't be static
> > anymore.
>
> That isn't exactly a minor change. How would you feel if your files went
> "dynamic" and got a name depending on the phase of the moon, and even
might
> suddenly dissapear from under you? OK, I'd buy a dynamic system if I got
> something in return, What I see is just nebulous talk about managing
> hundreds of devices that just come and go. Handling hundreds of devices
> isn't an everyday task, so when I hit a system like that I'll either sit
> down all day and configure the devices, or write a script for that. After
> that, they'll sit there until it is time to add/delete/reconfigure one of
> them. Systems with hundreds of devices that come and go without human
> intervention are just figments of somebody's imagination. At least nobody
> with that exact, hard pressing problem, for which devfs is supposedly the
> magical bullet has spoken up here.
>
> Even in you assume that devfs does work, what do you do if suddenly
> /dev/mouse471 appears, followed by /dev/sd781; and then a bit later
> /dev/sd215 dissapears? No big deal, unless /dev/sd215 just happened to be
> your $HOME. In that case, no devfs will save you. The mouse and the extra
> disk won't be of any use anyway if nobody cares enough about integrating
> them into the system. devfs (or any naming system, for that matter) can't
> do that, as this is strictly policy. And if you want to do this to $HOME,
> use the automounter, it is quite capable of mounting devices on demand.
> - --
> Dr. Horst H. von Brand mailto:vonbrand@inf.utfsm.cl
> Departamento de Informatica Fono: +56 32 654431
> Universidad Tecnica Federico Santa Maria +56 32 654239
> Casilla 110-V, Valparaiso, Chile Fax: +56 32 797513
>
>
> Please read the FAQ at http://www.tux.org/lkml/
>
> ------------------------------
>
> From: Lorenzo Allegrucci <parsek@tin.it>
> Date: Fri, 8 Oct 1999 21:09:26 +0200
> Subject: kswapd priority
>
> In 2.0.x the kswapd priority was -12 but in 2.2.x now is 0, why?
> BTW, what are advantages (disadvantages?) on making kswapd, kmod, etc
> as a kernel thread rather than a trivial kernel procedure/function?
>
> - --
> Lorenzo
>
> Please read the FAQ at http://www.tux.org/lkml/
>
> ------------------------------
>
> From: Stephen Frost <sfrost@mail.snowman.net>
> Date: Fri, 8 Oct 1999 19:37:21 -0400 (EDT)
> Subject: Re: USB device allocation
>
> On 7 Oct 1999, david parsons wrote:
>
> > I certainly don't; /proc is fast enough even for the various
> > 386s I run Linux on, and if I don't want to use those cycles
> > I just won't mount /proc.
>
> And then discover that the latest version of ps doesn't
> work...
>
> Stephen
>
>
> Please read the FAQ at http://www.tux.org/lkml/
>
> ------------------------------
>
> From: Riley Williams <rhw@MemAlpha.CX>
> Date: Fri, 8 Oct 1999 18:51:19 +0100 (GMT)
> Subject: Larger dev_t field
>
> Hi Horst.
>
> > The work for enabling larger dev_t's has been done a long time
> > ago (2.1 something, or even much earlier). AFAIU, glibc is also
> > prepared for a larger dev_t. The big problem is doing it, as it
> > will break _everything_.
>
> Surely that depends how it's done.
>
> I made a proposal relating to this some time ago, and the only
> comments received back were to the effect that my proposal would
> indeed mean that little if anything would be broken, but as far as I
> can tell, it was otherwise ignored. Perhaps somebody can advise why?
>
> For reference, I proposed that we move to at least 32 bit dev2_t (or
> kdev_t or whatever one wishes to call them), split into three parts as
> follows:
>
> 1. Bits 0 to 7 of the value comprise the MINOR number of the
> node, identical to at the moment.
>
> 2. Bits 8 to 15 of the value comprise the MAJOR number of the
> node, identical to at the moment.
>
> 3. Bits 16 up of the value comprise the FAMILY number of the
> node, this being the new section.
>
> Having split the value up like this, the results can be displayed as
> triplets of the form (FAMILY,MAJOR,MINOR) to indicate what is what.
>
> The field I have labelled FAMILY can then be defined along the lines
> of the following for block devices:
>
> * FAMILY = 0 is defined as "Compatibility Nodes". These are
> handled by a special remapping module that takes the MAJOR
> and MINOR of the value and remaps them to the equivalent
> of whatever that maps to using the current (MAJOR,MINOR)
> number scheme.
>
> * FAMILY = 1 could be defined as "EIDE Devices", and would
> be mapped such that MAJOR selected the relevant device, &
> MINOR selected the partition thereon. This would allow up
> to 256 drives with up to 256 partitions on each of them.
>
> * FAMILY = 2 could be defined as "SCSI Devices", and would
> be mapped such that MAJOR and MINOR had exactly the same
> meaning as for "EIDE Devices" described above.
>
> * FAMILY = 3 could be defined as "PCMCIA Block Devices",
> and would be mapped similarly.
>
> * FAMILY = 4 could be defined as "USB Block Devices", and
> could be mapped such that MAJOR defined the relevant USB
> bus and MINOR defined the particular device thereon.
>
> A similar scheme could easily be defined for character devices, in
> which the definition of "FAMILY = 0" would be identical to that above.
> One possible definition would be:
>
> * FAMILY = 0 is defined as "Compatibility Nodes". These are
> handled by a special remapping module that takes the MAJOR
> and MINOR of the value and remaps them to the equivalent
> of whatever that maps to using the current (MAJOR,MINOR)
> number scheme.
>
> * FAMILY = 1 could be defined as "Miscellaneous Character
> Devices", with MAJOR defining the category therein, and
> MINOR the device within that category. Possibilities:
>
> (1,0,*) Software devices /dev/null
> (1,1,*) Virtual Terminals /dev/tty1
> (1,2,*) Serial Interfaces /dev/ttyS0
>
> * FAMILY = 2 could be defined as "PseudoTerminals" with
> MAJOR and MINOR being treated as a single 16-bit number
> that selected one of 65,536 available pseudoterminals.
> This is the mapping that the current /dev/tty[a-z][a-z]
> would be remapped to, although longer names would be
> required.
>
> * FAMILY = 3 could be defined as "PCMCIA Character Devices"
> and would be mapped appropriately.
>
> * FAMILY = 4 could be defined as "USB Character Devices",
> and would be mapped appropriately.
>
> Perhaps somebody can advise what is wrong with this idea? Nobody did
> last time I proposed it, but it appears to have otherwise been
> ignored.
>
> Best wishes from Riley.
>
> +----------------------------------------------------------------------+
> | There is something frustrating about the quality and speed of Linux |
> | development, ie., the quality is too high and the speed is too high, |
> | in other words, I can implement this XXXX feature, but I bet someone |
> | else has already done so and is just about to release their patch. |
> +----------------------------------------------------------------------+
>
>
> Please read the FAQ at http://www.tux.org/lkml/
>
> ------------------------------
>
> From: Josh Samuelson <jsamuels@willy.wsc.edu>
> Date: Fri, 8 Oct 1999 13:18:40 -0500 (CDT)
> Subject: (2.2.12) attempt to access beyond end of device
>
> I've noticed some posts in the last few days that relate to the the disk
> subsystem trying to access blocks beyond the limits of the device.
> I've seen the same problem on one of the machines I administrate. In my
> situation, syslogd logged the messages until the machine ground to a halt.
> The machine would respond to console changes but when a login was
attempted,
> login name name and password could be entered but an endless hang followed
> due to load/inactivity of disk subsystem? So, the kernel didn't panic;
> processes were still running. The machine has a DPT SmartRAID V adapter
> in it; it had no audible alarm which leads me to believe there was no
> hardware problem with the disk array. The machine was than chunked.
> Unfortunately the person that chunked the machine didn't know 'magic
sysrq
> keys' was built in. So no sync/mount-ro was attempted before the reboot.
> When the machine booted, the kernel panicked because of massive filesystem
> corruption on the root partition. When the fs was finally fixed via
> e2fsck, the lost+found dir had numerous unreferenced inode entries.
> That didn't concern me too much until I examined them; all of which
> are special char/block files that can't be unlinked!? 'unlink: Operation
> not permitted' My question is whether this is a 2.2.12 or driver issue
> that causes the 'attempt to access beyond end of device' kernel messages?
> The machine has the following hardware:
>
> Intel SC450NX MP server/mainboard
> 4 Intel 500MHz/512KB PIII Xeon CPUs
> 1GB memory
> 1 SmartRAID V PM3754U2 with 3 channels and 128MB ecc memory
> RAID-5 array composed from 6 IBM DNES-309170 9GB/10K disks aprox: 43GB
> array is split into 4 partitions (from fdisk):
>
> Command (m for help): p
>
> Disk /dev/sda: 255 heads, 63 sectors, 5575 cylinders
> Units = cylinders of 16065 * 512 bytes
>
> Device Boot Start End Blocks Id System
> /dev/sda1 * 1 2 16033+ 83 Linux
> /dev/sda2 3 19 136552+ 82 Linux swap
> /dev/sda3 20 150 1052257+ 83 Linux
> /dev/sda4 151 5575 43576312+ 83 Linux
>
>
> The kernel is the stock 2.2.12 kernel tree with driver patch from DPT.
> The kernel was built with RedHat 6.0 gcc:
> gcc version egcs-2.91.66 19990314/Linux (egcs-1.1.2 release)
>
> Driver info:
>
> #cat /proc/scsi/dpt/3
> Vendor: DPT Model: PM3754U2 Rev: 204C, scsi 3:
>
> DPT I2O Driver Version: 1.05/1.1:
>
> cmd_per_lun = 210, max_id = 15, max_lun = 7, max_channel = 2
> sg_tablesize = 39, irq = 19, OutstandingMsgs = 1
> maxfromiopmsgs = 16, maxtoiopmsgs = 210
>
> Devices:
> Channel = 0, Target = 0, Lun = 0
> Channel = 0, Target = 6, Lun = 0
>
> It comes to my attention that this driver is a revision behind from a
prior
> post. However, the newer driver possibly still has problems according to
> another post?
>
> I've contacted DPT and inquired if they had heard any problems with their
> kernel patch with the stock 2.2.12 kernel. No was the answer I got.
>
> If this is not a 2.2.12 issue, then is there anyone else out there that
> has had similar problems with their DPT SRV RAID arrays?
>
> syslog messages:
> Oct 4 09:52:55 linux kernel: attempt to access beyond end of device
> Oct 4 09:52:55 linux kernel: 08:04: rw=0, want=936743908, limit=43576312
> Oct 4 09:52:55 linux kernel: dev 08:04 blksize=1024 blocknr=936743907
sector=1873487814 size=1024 count=1
> Oct 4 09:52:55 linux kernel: attempt to access beyond end of device
> Oct 4 09:52:55 linux kernel: 08:04: rw=0, want=796095601, limit=43576312
> Oct 4 09:52:55 linux kernel: dev 08:04 blksize=1024 blocknr=796095600
sector=1592191200 size=1024 count=1
> .
> .
> .
> Oct 4 10:00:23 linux kernel: attempt to access beyond end of device
> Oct 4 10:00:23 linux kernel: 08:04: rw=0, want=936743908, limit=43576312
> Oct 4 10:00:23 linux kernel: dev 08:04 blksize=1024 blocknr=936743907
sector=1873487814 size=1024 count=1
> Oct 4 10:00:23 linux kernel: attempt to access beyond end of device
> Oct 4 10:00:23 linux kernel: 08:04: rw=1, want=936743908, limit=43576312
> Oct 4 10:00:23 linux kernel: dev 08:04 blksize=1024 blocknr=936743907
sector=1873487814 size=1024 count=1
> .
> .
> .
> Oct 4 10:05:28 linux kernel: EXT2-fs warning (device sd(8,4)):
ext2_free_blocks: bit already cleared for block 1394126
> Oct 4 10:07:37 linux last message repeated 134 times
> Oct 4 10:07:37 linux kernel: EXT2-fs warning (device sd(8,4)):
ext2_free_blocks: bit already cleared for block 104455
> Oct 4 10:07:37 linux last message repeated 27 times
> .
> .
> .
> Oct 4 10:12:31 linux kernel: EXT2-fs warning (device sd(8,4)):
ext2_free_blocks: bit already cleared for block 468518
> Oct 4 10:12:33 linux kernel: EXT2-fs warning (device sd(8,4)):
ext2_free_blocks: bit already cleared for block 197878
> Oct 4 10:16:03 linux kernel: attempt to access beyond end of device
> Oct 4 10:16:03 linux kernel: 08:04: rw=0, want=870990273, limit=43576312
> Oct 4 10:16:03 linux kernel: dev 08:04 blksize=1024 blocknr=870990272
sector=1741980544 size=1024 count=1
> Oct 4 10:16:03 linux kernel: EXT2-fs error (device sd(8,4)):
read_block_bitmap: Cannot read block bitmap - block_group = 56, block_bitmap
= 870990272
>
> syslog message entries ended and the machine was rebooted around 10:40.
>
>
> lost+found unlinkable inodes (424 entries):
>
> #ls -apln /lost+found
> total 325701634130
> drwxr-x--- 2 0 0 26624 Oct 8 12:47 ./
> drwxr-xr-x 16 0 0 1024 Oct 8 00:00 ../
> b--xr-Sr-x 1 26473 25975 106, 10 Mar 25 1995 #24658
> br-xrwSrwx 1 28263 24954 109, 111 May 9 20:07 #24660
> br-srwS-wT 1 25975 25199 101, 109 Feb 28 1996 #24664
> b--sr-Sr-x 1 12396 27749 116, 110 Dec 8 2000 #24684
> b--sr-s--t 1 29743 12602 108, 101 Mar 3 1996 #24685
> br-srwSr-T 1 14958 29811 119, 97 Mar 17 1995 #24699
> br-sr-s--- 1 28257 25449 105, 109 Dec 26 2026 #24715
> br-xrw-r-T 1 26739 12594 104, 108 Aug 15 1995 #24717
> br-xr-s--x 1 27491 25961 111, 99 Sep 1 2021 #24719
> .
> .
> .
> br-S--s-w- 1 28001 24909 47, 101 Oct 23 1998 #26620
> br-xrwSr-- 1 28704 29548 115, 119 Dec 4 2023 #411987
> br-srwS-wT 1 29287 26478 101, 112 Jul 19 1975 #411991
> br-xr-xrwx 1 29548 25441 32, 110 Aug 20 2021 #411992
> c--xrw-r-- 1 26223 26479 32, 32 Jan 14 2026 #411994
> c--xr-xrw- 1 27507 8265 65, 32 Jan 29 2029 #411996
> c--xr--r-- 1 25970 25970 101, 82 Oct 19 2021 #411997
> b--sr-s--x 1 29801 11886 116, 105 Jan 29 2029 #411999
> .
> .
> .
>
>
> Please read the FAQ at http://www.tux.org/lkml/
>
> ------------------------------
>
> From: Stephen Frost <sfrost@mail.snowman.net>
> Date: Fri, 8 Oct 1999 19:10:02 -0400 (EDT)
> Subject: Re: devfs again, (was RE: USB device allocation)
>
> On Thu, 7 Oct 1999, Dan Hollis wrote:
>
> > On Fri, 8 Oct 1999, Martin Dalecki wrote:
> > > Don't you just realize that all the twised symlinc blah blah
proposals
> > > about devfs you are doing here are a sure sign of a basically bad
design?
> >
> > Im a devfs advocate but I agree the symlink design is bad.
> >
> > Would an overmountable devfs address most of the arguments against it?
>
> Not sure... Could you elaborate on what you mean by 'overmountable'?
>
> Stephen
>
>
> Please read the FAQ at http://www.tux.org/lkml/
>
> ------------------------------
>
> From: Shawn Leas <SLEAS@videoupdate.com>
> Date: Fri, 8 Oct 1999 12:56:24 -0500
> Subject: RE: PUBLIC CHALLENGE: (was RE: devfs again, (was RE: USB device a
lloc ation) )
>
> From: Horst von Brand [mailto:vonbrand@inf.utfsm.cl]
> Subject: Re: PUBLIC CHALLENGE: (was RE: devfs again, (was RE: USB device
> a lloc ation) )
>
> >It impacts all drivers then. Case closed.
>
> Ok Mr Horst sir, whatever you say...
>
> Please read the FAQ at http://www.tux.org/lkml/
>
> ------------------------------
>
> From: Stephen Frost <sfrost@mail.snowman.net>
> Date: Fri, 8 Oct 1999 18:32:48 -0400 (EDT)
> Subject: Re: devfs again, (was RE: USB device allocation)
>
> On Thu, 7 Oct 1999, Matthew Dharm wrote:
>
> > > Wrong. Having devfs in the kernel has an impact on _all_ devices, if
they
> > > use it or not. Giving the option has even more impact here than just
> > > forcing it one way or the other.
> >
> > I'm sorry, but I fail to understand your reasoning behind this
statement.
> > Could you please clarify? How is a driver which presents a traditional
> > major/minor number interface affected by the presence of a devfs (which,
> > presumably, uses a different interface to the driver).
> >
> > > A driver is something quite different: If the source is in the kernel
or
> > > not has very minimal impact, a few lines outside of the driver itself.
> > > There is does make sense to apply kitchen-sink mentality, with core
kernel
> > > functionality is just does not.
> >
> > A driver is different from what? Please clarify. I'm having great
> > difficulty understanding how this paragraph applies to the one before
it,
> > and how it is supposed to refute danielt's statement. Where is the
> > 'kitchen-sink mentality' to which you refer?
>
> I think his point was, devfs isn't a driver, and he went on to
> describe what a driver is. Point being, we are less concerned about new
> drivers being added in since they don't tend to affect other drivers.
>
> Stephen
>
>
> Please read the FAQ at http://www.tux.org/lkml/
>
> ------------------------------
>
> From: Shawn Leas <SLEAS@videoupdate.com>
> Date: Fri, 8 Oct 1999 12:55:48 -0500
> Subject: RE: devfs again, (was RE: USB device allocation)
>
> From: Horst von Brand [mailto:vonbrand@inf.utfsm.cl]
> Subject: Re: devfs again, (was RE: USB device allocation)
>
> >> I don't think we want to complain that devfs is at fault for the fact
> that
> >> sudo access can be dangerous.
>
> >What I want to say is that your "solution" creates more problems than
there
> >were before. The Unix way (/dev is part of a real filesystem;
permissions,
> >ownership, names, links, ... all work the same as with regular files) is
a
> >time-tested design. Not flawless, but its flaws are known and workarounds
> >are in place. You propose to junk all that for a shiny, new way of doing
> >things that does break in many ways (see above). All for the tenuous
> >purpose of being able to address more devices (get a bigger dev_t, and be
> >done) or being able to fool around all day plugging/unplugging devices.
>
> I propose to junk nothing, as no one does. I do, however,
> see a bunch of problems stated thusly:
> - inability to summarize devices (and their interfaces)
> recognized by the kernel from userland unless extensive
> probing is done by a lock grabbing program.
> - Inflexible major/minor restrictions that are
> unsustainable unless increasing dev_t which has
> implications in and outside the kernel
> - Horendous userland hacks in order to be able to
> use hot plug devices. PCMCIA, USB
> - Lack of an extremely dynamic runtime device
> scheme, needed to support USB and PCMCIA to
> a lesser extent
> - Devices named serially such that if one from in
> the middle is removed, all subsequent devices must
> be addressed differently. As stated before, UUID
> solutions only work on FSes with UUIDs, or things
> that even USE an FS!!!
> - Others I can't even think of right now.
>
> And ONE, count 'em, ONE clean solution, or at least the cleanest one
> to date, and it based on solid foundation, whatever anyone has to
> say about it's implementation, which, is indeed the least intrusive
> I can think of!
>
> >Note that just devfs does _not_ solve the "more devices" problem, as long
> >as major/minor stay limited. It can't really solve the "unplug sda, now
sdy
> >is sdx" problem either (somehow devices _must_ be named, and this has to
be
> >done somehow fixed, you can't just lug around the whole history of /dev),
> >and it can't solve the "unplug sdc, plug in another sdc, and then sdd;
now
> >plug in the old sdc and have it be sdc again" problem. Any solution it
> >could offer for this is useless: I'd much prefer to be able to go and
look
>
> You are so completely wrong here, it's as if you've never heard of
> SYSV style device naming conventions. It's defacto standard. Suffice
> it to say that location based naming schemes are the only way to go.
> UUID is arbitrary, and, is therefore a HACK.
>
> >for /dev/disk-<some-serial-number> to check which <serial-number>s I've
> >used, and not having to remember that by my own because that particular
> >disk (out of the hundreds advocated by you) just so happens not to be on
> >line ATM. You want to unclutter /dev cluttering me.
>
> I don't get what you're saying here.
>
> >BTW, the "devices get renamed" problem _is_ solved, and has been for
quite
> >some time: You can mount by disk label or uuid, forget about the device
> name.
>
> Wrong, as explained above. What about raw (well, at least
> non-fs) volumes??? Please address even ONE of my points.
>
> - -Shawn
>
> Please read the FAQ at http://www.tux.org/lkml/
>
> ------------------------------
>
> From: Stephen Frost <sfrost@mail.snowman.net>
> Date: Fri, 8 Oct 1999 18:23:15 -0400 (EDT)
> Subject: RE: PUBLIC CHALLENGE: (was RE: devfs again, (was RE: USB device a
lloc ation) )
>
> On Thu, 7 Oct 1999, Shawn Leas wrote:
>
> > > You DO realize that you are lowering the chances of getting devfs
> > >into the mainstream kernel by using this kind of an attitude and
treating
> > >others in this fashion, don't you?
> >
> > It's technical merit will decide, or methinks maybe Linux isn't as good
as
> > I once thought.
>
> The idea is to convice others that your idea is a good once. Treating
> others disrepectfully is not a good way to convice other people you're
right.
>
> > > They aren't files in the sense that they are stored on non-volitile
> > >media. As in, in reality, they go away when you shut the machine down,
and
> > >come back when the machine boots up. If you boot off of a floppy an OS
> > that
> > >understands the root system, you won't see those files.
> >
> > They aren't files in terms of your definition, being "blocks of data
> > residing
> > on physical media, being presented in contiguous fashion via a named
node
> > called a file", but in the purest sense, they are as much a *special*
file
> > as anything.
>
> 'special' files are files that have special attributes, not that go
> away when the power goes off.
>
> > >> Misinformation! Misinformation! Misinformation! Misinformation!
> >
> > > /dev can be cleaned up using rm(1). devfs at one point used
> > tarballs
> > >to handle permissions, now it doesn't, it uses a configuration file,
which
> > >makes it even more strange and un-filesystem like. I don't use a
config
> > file
> > >to specify my permissions on my / partition.
> >
> > No it didn't. It lets drivers decide, and you can chown/chmod/ln etc to
your
> > heart's content, but persistence was handled by tar which worked
beautifully
> > via a standard FILESYSTEM INTERFACE.
>
> No, it was a hack. The permissions were not stored w/ the file. They
> were not stored on even the same filesystem that the file was.
>
> > >> So you like it. So do it that way. Don't be an ASSHOLE and say just
> > because
> > >> you don't like it that it CANT be in the kernel.
> > > The same could be said about many things that would be bad to have
> > in
> > >the kernel.
> >
> > The saga of device fs involves people who for no better reason than
> > emotional
> > stupidity reject a better idea, not technical fault. It seems you are
> > implying
> > the current devfs would be bad to have in the kernel. Cite your reasons.
>
> We've just been going over my reasons.
>
> > >> You can, with userland, just like devfs. You could have it monitor
for
> > new
> > >> devices, and either mount it somewhere and add it to /etc/fstab, or
have
> > >> user configurable actions to perform for certain classes of
> > devices!!!!!!!
> >
> > > So, what does devfs add then? If it doesn't add anything, then
> > there
> > >isn't much point in having it.
> >
> > I was talking about extensions for devfsd, where, I SHOULD have said
"when
> > devfsd gets awoken by a devfs namespace change, devfsd could..."
>
> Why does devfs have to be mounted then? Sounds like it could do what
> it wants without being mounted and trying to play like a filesystem, when
it
> actually isn't one..
>
> Stephen
>
>
> Please read the FAQ at http://www.tux.org/lkml/
>
> ------------------------------
>
> From: Shawn Leas <SLEAS@videoupdate.com>
> Date: Fri, 8 Oct 1999 12:59:23 -0500
> Subject: RE: PUBLIC CHALLENGE: (was RE: devfs again, (was RE: USB device a
lloc ation) )
>
> From: Horst von Brand [mailto:vonbrand@inf.utfsm.cl]
> Subject: Re: PUBLIC CHALLENGE: (was RE: devfs again, (was RE: USB device
> allocation) )
>
> >If I want to allow all users/some users to access the floppy drive, I
have
> >to recompile the kernel?? Or at least reboot? If you want that, you know
> >where you can find systems that can't be reconfigured in trivial ways
> >without rebooting.
>
> What the hell are you talking about??? This is pure ignorance.
>
> >>>> The use of a config file to determine permissions/ownership is not >
> >>>> foreign to the kernel or filesystems.
> >>>Name one use of configuration files for local permissions/ownership on
> >>>Unix/Linux.
> >> This is a straw man argument. You take an easy target, knock it down,
> >> and it really doesn't mean anything, but you claim victory. Shame.
> >You claimed the above, I ask where this is done, and now I'm fighting
> >strawmen set up by me?!
>
> No, I'm saying the argument (not made by me) was a weak one,
> and by winning that little battle, you do definitely freaking
> NOT win ANY argument.
>
> - -Shawn
>
> Please read the FAQ at http://www.tux.org/lkml/
>
> ------------------------------
>
> From: Horst von Brand <vonbrand@inf.utfsm.cl>
> Date: Fri, 08 Oct 1999 13:57:55 -0400
> Subject: Re: PUBLIC CHALLENGE: (was RE: devfs again, (was RE: USB device
alloc ation) )
>
> Riley Williams <rhw@memalpha.cx> said:
> > Hi Horst.
> > >> The use of a config file to determine permissions/ownership is
> > >> not foreign to the kernel or filesystems.
>
> > > Name one use of configuration files for local
> > > permissions/ownership on Unix/Linux.
>
> > 1. Start with /etc/passwd which determines ownership of the actual
> > user accounts not just on Linux but on every UNIX compatible
> > operating system I've seen. Add /etc/group and /etc/shadow (if
> > applicable) to that.
>
> That maps names (that you use to log in) to real Unix identity. No
> permissions here.
>
> > 2. Have a look at /etc/securetty which determines the ownership of
> > terminals that the superuser can log into.
>
> Nope, it lists terminals on which the superuser is allowed to log in. No
> permissions given. Taken away, yes. In a way.
>
> > 3. Have a look at /etc/hosts.{allow,deny,equiv} which determine
> > which hosts have permission to access your system.
>
> Non-local accesses here.
> - --
> Dr. Horst H. von Brand mailto:vonbrand@inf.utfsm.cl
> Departamento de Informatica Fono: +56 32 654431
> Universidad Tecnica Federico Santa Maria +56 32 654239
> Casilla 110-V, Valparaiso, Chile Fax: +56 32 797513
>
> Please read the FAQ at http://www.tux.org/lkml/
>
> ------------------------------
>
> From: Shawn Leas <SLEAS@videoupdate.com>
> Date: Fri, 8 Oct 1999 13:06:18 -0500
> Subject: RE: devfs again, (was RE: USB device allocation)
>
> From: Horst von Brand [mailto:vonbrand@inf.utfsm.cl]
> Subject: Re: devfs again, (was RE: USB device allocation)
>
> EVERY assertion you make is a complete falsehood,
> and you know it. Spreading FUD, no more. I just
> can't believe you're really that dumb.
>
> >Now you tell him that he can't find out what the name of a disk is if it
> >isn't on line.
>
> Big fat complete lie.
>
> >And explain carefully how to manage the symlink farm in
> >/devices, so /dev can stay squeaky clean.
>
> Big fat complete lie.
>
> >Give step by step instructions on
> >patching the kernel to change permissions on the modem, and how to build
> >and install the new kernel, and rebooting into it, so his kid sister
> >doesn't stay online all day (phone is charged by the minute here). Don't
>
> Big fat complete lie.
>
> >forget to mention that it might come handy having several kernels around
> >with different permissions on devices, just in case. Also, tell him how
to
> >clone a device for the case /dev/sdc is allowed for everybody (happens to
> >be the removable Zip disk), while /dev/sda isn't (the main drive).
>
> Big fat complete lie.
>
> >If/when he digests all this, prepare for the question about how to
> >recompile the kernel so his $HOME is closed to outsiders, and how to
> >reconfigure the kernel for some new user.
>
> Big fat complete lie.
>
> >> ME: "Hey, wouldn't you want to have to create a new device for every
USB
> >> mouse/keyboard/PCMCIA device you use every time you use it with no
> gaurantee
> >> you're going to get it right?"
>
> >Ever heard of MAKEDEV?
>
> MAKEDEV is a hack, with no gaurantee of being right from kernel to kernel.
>
> >All this is just changing one mess (/dev) for another mess of the very
same
> >size (symlink farm), only much worse.
>
> Big fat complete lie.
>
> - -Shawn
>
> Please read the FAQ at http://www.tux.org/lkml/
>
> ------------------------------
>
> From: Gerard Roudier <groudier@club-internet.fr>
> Date: Fri, 8 Oct 1999 21:14:36 +0200 (MET DST)
> Subject: Re: Potential SCSI system bottleneck.
>
> Using very fast HDs and the sym53c8xx driver, the command overhead
> (everything minus DATA transfer) can be lower than 70 micro-seconds for a
> 875, without disconnections and probably not more than 100 micro-seconds
> with un single diconnection per transfer.
> (Btw, the ncr53c8xx should not have a significantly higher command
> overhead with the 875, may be less than 20%)
>
> The benchmarks that have been used basically are measuring sequential
> access speed and given the read-ahead performed by the the kernel, actual
> IOs size are in average larger than 64 KB.
>
> Using your 2 drives on a single BUS, the bandwidth used is less than:
>
> 20 MB/sec = half of the BUS bandwidth (50%)
> 20 MB/64K = 312 tps.
>
> Even if the total command overhead of your drive is as high as 250
> micro-second (2.5 times the driver/HA pair capabilities), the total
> command overhead per second will be about:
> 312*250us = 78 ms.
> that represents less than 8% of the total BUS bandwidth.
>
> Result is that your benchmarks are not able to use more than 58% of a
> single BUS bandwidth. You cannot expect in this situation to get
> significant better performances by using 2 BUSes instead of 1 for your
> benchmarks.
> (With the ncr53c8xx driver load should be not more than 60% of the
> bandwidth)
>
> On the other hand, performing RAID using disks and/or disk areas that
> haven't exactly the same characteristics is very unlikely to give additive
> performances. The fastest transfer rate will synchronize with the slowest
> one, and latency due to additionnal disk revolutions for synchronisation
> (8.3 milli-second for a 7200 rpm driver) will also slow down the actual
> data transfer rate.
>
> In my opinion, you are wasting time by trying to get any relevant
> informations from your results. Results that are just a bit reversed
> compared to expectations donnot seem significant to me, given the load and
> different disks used for RAID. IMO, the minimal configuration that may
> give usable results should load a single BUS by at least 70% of its
> bandwidth and for the RAID benchmarks should apply to identical disks and
> using same areas of each disk.
>
> (Since I intentionnaly used higher number than reality should have been
> for the estimation of the BUS load, the actual BUS load for your
> benchmarks should have been not more than 50%).
>
> Gérard.
>
>
> On Fri, 8 Oct 1999, ishikawa wrote:
>
> > Here is a potential performance problem uncovered
> > by a set of benchmark tests.
> > Namely two SCSI adaptors don't speed up raid 0/1 perceptibly
> > in comparison to the performance of a single SCSI adaptor system.
> > (and under dual CPU system for that matter .)
> >
> > Let me explain. This is lengthy containing the benchmark result, etc.
> >
> > A certain Mr. Sagai did a comparison of disk system performance on
> > Linux using various combination of
> > IDE and SCSI disks, making RAID 0 and 1 combinations
> > using raid tools and tested the configuration on
> > single and dual CPU systems.
> > He published the benchmark results in a Japanese monthly magazine,
> > "Software Design" in two consecutive issues.
> > The came out in July and August this year.
> > The test was very exhaustive in terms of
> > the various configuration set up and I would like to
> > thank him for his time as a linux user at home.
> >
> > One conclusion in his magazine article based on the benchmark results
> > was that there was NO discernable speedup when
> > TWO (2) SCSI host adaptors that have one SCSI disk each were used
> > in setting up RAID disk in comparison to the performance
> > observed with only ONE (1) SCSI host adaptor with two SCSI disks on
> > the bus.
> >
> > I thought that the conclusion was rather COUNTER-INTUITIVE.
> > For the last 15 years or so, it was rather rule of a thumb to
> > add a SCSI host adapter and balance the load to
> > speed up the disk system throughput. I saw magazine articles where
> > people added scsi host adaptors for better performance.
> >
> > So I said to myself something was fishy here and
> > set out to find out what might be the cause of this
> > counter-intuitive result.
> >
> > Rereading the articles (the article ran in two issues. He did a very
> > throught testing and it must have been a lot of work.)
> > I thought I detected a possible weakness in the performance
> > measurement.
> >
> > He used Bonnie (and some other tests) to test the system throughput,
> > but in the case of Bonnie, he didn't specify
> > large enough temporary file size. Small test file size may mean
> > that the file buffers in memory can cushion the I/O requests and
> > may not excersize the disk very much.
> >
> > So I wrote him an e-mail, and mentioned my
> > surprise about the counter-intuitive result.
> > I suggested that the increasing of the test file size
> > may result in a very different Bonnie benchmark and
> > his tentative conclusion might have to be changed.
> > Mr. Sagai promptly wrote back and told me that
> > he himself was surprised and disappointed at the result and
> > promised he would run the test again using the larger file size
> > and ask the magazine to carry additional article reporting the
> > new test results. This was in August.
> >
> > One month later, he wrote back and told me the new article
> > would be forth-coming mis-October.
> > And more importantly, again there was NO discernable speedup (!).
> > Bonnie and iozone were used.
> > He was kind enough to let me use his preliminary results before
> > publication
> > to investigate, er.., rather ask the veterans of linux-scsi (and
> > linux-kernel)
> > to investigate the cause of the problem.
> >
> > I am reporting his results for your information and analysis in this
> > e-mail.
> >
> > - BTW, I don't know if Bonnie is a good performance measurement tool
> > today
> > although it certainly shows that striping makes the disk system
faster
> > on Linux
> > and at that level, it is useful.
> > (I already run this discussion by a friend of mine who found out about
> > the software striping speed gain, etc.. He doesn't have much to offer
> > about this counter-intuitive result, though.
> > BTW, this friend of mine found that software RAID using fast CPU
> > beats the hardware RAID under light conditions, and as a matter of
> > fact,
> > all the test configurations he threw at it! Obviously 400Mhz CPU can
> > do processing faster than sub-100 Mhz i960 and other CPUs on the
> > hardware RAID cards. )
> >
> > - Seriously, I recall vaguely that there was a discussion in linux-scsi?
> > about
> > less parallelism in SCSI subsystem (or whatever)
> > as there could be due to some serialization bottleneck or somethig.
> > If I recall correctly Linus himself jumped in the discussion and
> > mentioned
> > that was one reason why he did't like the current SCSI system.
> >
> > This reduced lack of parallelism (?) or something might be the cause
> > of the not-so-optimum result Mr. Sagai observed..
> >
> > Since the benchmark results were obtained for raid 0/1 in the case of
> > single and dual CPUs, I think that the chance of experiencing
> > a REAL performance bottleneck in the kernel is high.
> >
> > Maybe we have found a new performance challenge like
> > the ones that emerged after Mindcraft benchmark incident.
> > (Or we may find other explanations.)
> >
> > [BTW, Mr. Sagain himeself seems to think that
> > SMP ought to add performance boost at least
> > in certain configurations. Come to think of it why not.
> > However, Mr. Sagai mentioned a monitoring tool xosview showed
> > that CPU (?) seems to be
> > accessing the disk one at a time during testing even where there are
> > two adapters. I don't know if this was to be expected or not.
> > For me tthe surprise was that the addition of the SCSI adaptor to
balance
> > the load
> > ought to increase the performance a little bit but didn't seem to do so
> > by
> > large margin .]
> >
> >
> > So for your analysis, here is the gist of the revised short benchmark
> > article.
> >
> > ---------------------------------------------------
> > Here is Mr. Sagai's system configuration.
> >
> > Kernel: 2.2.10 + raid0134-19990724-2.2.10.gz patch
> > M/B: Abit BP6
> > MEMORY: 128MB SDRAM CL=2
> > SCSI: I/O Data SC-UPCI(Symbios 53C875) x 2
> > HDD: IBM DHEA 34330(Linux kernel, etc. is here)
> > IBM DCAS 34330UW(4.3GB)(RAID disk 1)
> > IBM DDRS 34560UW(4.5GB)(RAID disk2)
> > VIDEO: MGA G100 AGP 8MB
> > NETWORK: ELECOM Laneed LD-10/100 AN(DEC DC21140)
> >
> > (Right. He had to use similar but
> > different SCSI disks for RAID. The older model was sold out
> > when he tried to buy another one and thus he had to use the newer
> > available model for his testing. Remember he did the test in his spare
> > time.)
> >
> > His test method.
> >
> > He set up Software RAID using
> > two SCSI disks.
> >
> > He benchmarked the following configurations:
> >
> > RAID 0 (striping), and RAID 1 (mirroring.)
> >
> > for both single and dual CPU set up.
> >
> > So there are 4 combinations.
> >
> > He ran Bonnie (512MB test file size) and iozone
> > for measuring the performance.
> >
> > The results are attached.
> >
> > >From the results, he thinks that
> > two SCSI adaptors (and SMP) does NOT seem to
> > offer the perceptible performance gain. The same conclusion.
> >
> > One possibility he mentions was that the benchmark
> > test programs themselves are not quite
> > compatible with today's hardware resource setting and
> > multithreaded version of the benchmark programs probably
> > fare better.
> > (CI's comment: All I can think of is that the kernel ought to
> > better utlize the added bandwidth offered by two SCSI adapters.)
> >
> >
> > (1) BONNIE results
> >
> > 1-a. Standalone disk (no RAID. )
> >
> > (He must have used a Japanized version of Bonnie.
> > The header lines are presented in Japanese characters.
> > I translate them by hand below. So they may look slightly different from
> > the original Bonnie output. )
> >
> > -------sequentail write-------
> > --sequential read- -random-
> > -char- -block- -rewrite--
> > -char- -block- --seek--
> > Machine MB K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU
> > K/sec %CPU
> > DCAS 512 5474 70.4 7317 9.8 2876 7.2 5701
> > 68.4 7734 7.1 67.9 1.0
> > DDRS 512 6792 87.3 9825 12.5 4473 11.5 7413
> > 89.4 12715 11.0 94.3 1.3
> >
> >
> > (1-b) RAID 0 / singl CPU case.
> >
> > The case of two (2) SCSI adaptors (SC UPCI x2) and
> > the case of single SCSI adaptor (SC UPCI x 1) are presented.
> >
> > -------sequentail write-------
> > --sequential read- -random-
> > -char- -block- -rewrite--
> > -char- -block- --seek--
> > Machine MB K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU
> > K/sec %CPU
> > SC UPCIx2 512 7586 95.5 16702 18.8 4871 10.5 6533
> > 77.5 15604 14.0 104.4 0.9
> > SC UPCIx1 512 7547 95.2 17350 20.0 4914 10.7 6683
> > 79.5 15543 12.2 108.9 1.0
> >
> > (1-c) RAID 0 / dual CPU case.
> >
> > The case of two (2) SCSI adaptors (SC UPCI x2) and
> > the case of single SCSI adaptor (SC UPCI x 1) are presented.
> >
> >
> > -------sequentail write-------
> > --sequential read- -random-
> > -char- -block- -rewrite--
> > -char- -block- --seek--
> > Machine MB K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU
> > K/sec %CPU
> > SC UPCIx2 512 7502 96.0 16650 20.6 4915 12.4 6455
> > 77.5 15554 14.5 99.5 1.5
> > SC UCPIx1 512 7399 95.6 15918 21.9 5018 13.2 6612
> > 79.7 15491 15.3 101.9 1.6
> >
> > (1-c) RAID 1 / single CPU
> >
> > The case of two (2) SCSI adaptors (SC UPCI x2) and
> > the case of single SCSI adaptor (SC UPCI x 1) are presented.
> >
> >
> > -------sequentail write-------
> > --sequential read- -random-
> > -char- -block- -rewrite--
> > -char- -block- --seek--
> > Machine MB K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU
> > K/sec %CPU
> > SC UPCIx2 512 4851 62.2 6301 7.1 2506 5.6 5675
> > 68.4 6304 5.5 80.7 1.2
> > SC UPCIx1 512 4948 63.7 6539 7.5 2485 5.6 5699
> > 69.1 6299 5.6 80.6 1.1
> >
> > (1-d) RAID 1 / dual CPU
> >
> > The case of two (2) SCSI adaptors (SC UPCI x2) and
> > the case of single SCSI adaptor (SC UPCI x 1) are presented.
> >
> >
> > -------sequentail write-------
> > --sequential read- -random-
> > -char- -block- -rewrite--
> > -char- -block- --seek--
> > Machine MB K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU K/sec
%CPU
> > K/sec %CPU
> > SC UPCIx2 512 4753 62.8 6627 8.9 2513 6.9
> > 5457 66.9 6310 6.5 81.0 0.9
> > SC UPCIx1 512 4985 66.3 6639 9.5 2497 7.3
> > 5447 66.5 6263 6.9 80.5 1.5
> >
> > (The above was Bonnie results...)
> > ----
> > (Below is IOZONE test results.)
> >
> > 2. IOZONE test results.
> >
> > (2-a) Standalone Disk.
> >
> > 512MB file write / read throughput
> > DCAS 8.3 MB/s 7.2 MB/s
> > DDRS 9.8 MB/s 11.4 MB/s
> >
> > (2-b) RAID 0 / single CPU
> >
> > (Sorry, I forgot to ask.The two rows probably have the same meaning.
> > Above is for two adaptor cases.)
> > 512MB file write / read throughput
> > 17.3 MB/s 14.3 MB/s
> > 17.8 MB/s 14.4 MB/s
> >
> > (2-c) RAID 0 / dual CPU
> >
> > (Sorry, I forgot to ask.The two rows probably have the same meaning.
> > Above is for two adaptor cases.)
> >
> > 512MB file write / read throughput
> > 17.3 MB/s 14.4 MB/s
> > 16.5 MB/s 13.9 MB/s
> >
> > (2-d) RAID 1 / Single CPU
> >
> > (Sorry, I forgot to ask.The two rows probably have the same meaning.
> > Above is for two adaptor cases.)
> > 512MB file write / read throughput
> > 6.7 MB/s 5.9 MB/s
> > 6.9 MB/s 5.9 MB/s
> >
> > (2-e) RAID 1 / dual CPU
> >
> > (Sorry, I forgot to ask.The two rows probably have the same meaning.
> > Above is for two adaptor cases.)
> >
> > 512MB file write / read throughput
> > 6.3 MB/s 6.4 MB/s
> > 6.9 MB/s 5.9 MB/s
> >
> > (above is iozone benchmark results.)
> >
> >
> >
> > That is all.
> > I suspect there is an artificial serialization bottleneck somwhere
> > and this keeps the kernel to take advantage of the added bandwidth of
> > the two SCSI bus on separate controllers...
> > (of course, it is possible some other bottleneck is already is in
effect.
> > Maybe at this load level
> > there is indeed no difference.)
> >
> > Since I though there may be kernel issues I include
> > linux-kernel in this post (but I am not on it.).
> > Probably the follow-up should be
> > to linux-scsi only?
> >
> > Chiaki Ishikawa
> >
> > A happy linux user at home
> >
> >
> >
> >
> >
> > -
> > 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.tux.org/lkml/
> >
> >
>
>
> Please read the FAQ at http://www.tux.org/lkml/
>
> ------------------------------
>
> From: Alexander Viro <viro@math.psu.edu>
> Date: Fri, 8 Oct 1999 14:33:21 -0400 (EDT)
> Subject: Re: how to write get_block?
>
> On Fri, 8 Oct 1999, Manfred Spraul wrote:
>
> > I couldn't find it in the POSIX standart, but at least some UNIXes don't
> > allow it:
>
> Sure. We are kinda-sorta preventing it too. But there is a windows when
> both the shared mmap() and lockf() may pass (if mmap() comes first,
> overlaps the memory area that was the last mmap to the unlinked file
> and fcntl() happens before the file is finally removed).
>
> OK, folks, I'm going down - 18 hours of tube time have some unpleasant
> effects.
>
>
> Please read the FAQ at http://www.tux.org/lkml/
>
> ------------------------------
>
> From: Stephen Frost <sfrost@mail.snowman.net>
> Date: Fri, 8 Oct 1999 18:42:45 -0400 (EDT)
> Subject: RE: devfs again, (was RE: USB device allocation)
>
> On Thu, 7 Oct 1999, Shawn Leas wrote:
>
> > From: Steve Dodd [mailto:dirk@loth.demon.co.uk]
> > Subject: Re: devfs again, (was RE: USB device allocation)
> >
> > >Couldn't devfs forward permission changes via chmod/chown to the user
space
> > >daemon, which could update the database / magic file?
> >
> > This is not needed... Don't believe the hype. With, or
> > without devfsd, you can
> >
> > chmod
> > chown
> > ln -s
> > ls -l
> > mkfifo /tmp/hda && (cat /dev/hda > /tmp/hda &) && strings /tmp/hda >
> > /dev/null && echo "DUH"
> >
> > All you want.
>
> Until you reboot.
>
> Stephen
>
>
> Please read the FAQ at http://www.tux.org/lkml/
>
> ------------------------------
>
> From: Stephen Frost <sfrost@mail.snowman.net>
> Date: Fri, 8 Oct 1999 18:45:36 -0400 (EDT)
> Subject: Re: devfs again, (was RE: USB device allocation)
>
> On Fri, 8 Oct 1999, Martin Dalecki wrote:
>
> > Stephen Frost wrote:
> > >
> > > On Thu, 7 Oct 1999, Horst von Brand wrote:
> > >
> > > > This is _horrible_. Suddenly there are files whose attributes aren't
fixed
> > > > by chmod(1)/chown(1), but by a magic file.
> > > >
> > > > Again. The way Unix is designed, permanent information about files
resides
> > > > in the filesystem. Another basic Unix design premise is that devices
are
> > > > files. So their attributes reside in the filesystem. Anything else
breaks
> > > > much ("tar cf dev.tar /dev", ..., "tar xf dev.tar /dev" doesn't work
> > > > anymore (but it looks like it does!); can't dump/restore /dev; ...).
It
> > > > might also have _very_ serious security implications (what if the
magic
> > > > devfs.conf file goes missing, or is clobbered?)
> > >
> > > Agreed, this can be a problem, hence my thoughts on a set of
/dev
> > > files that reside on the filesystem pointing to /devices, which can be
> > > thought of as basically the same thing as major,minor pairs, w/ the
> > > exception that they are names (And as such much more scalable, and
often
> > > easier to understand). Unfortunately, I don't know enough about how
> > > devices work to know if something like this is even possible.
> > > I suppose you could take away /devices and change whatever you
have
> > > to to make major,minor pairs names instead... Then have a userspace
daemon
> > > that can do what it wants to the files, or they can be modified by
hand.
> > > Of course, this looses us the (debated) advantage of having /dev being
in
> > > memory instead of on disk.
> > > Then I ask you, how can a script find out specific information
> > > about what hardware exists on the system? Run through everything in
/dev?
> > > If /dev is fully populated, this could take a while... /proc gives us
> > > some data currently, though it's not in a very standard fashion, and
> > > currently would be hard for a script or program to parse out.
> > > Curious, what are your feelings on /proc, anyhow?
> >
> > Don't you just realize that all the twised symlinc blah blah proposals
> > about
> > devfs you are doing here are a sure sign of a basically bad design?
> > If you don't beleve then just try to explain this all to a fresh new
> > linux user.
>
> major,minor's aren't exactly all that great either... "Oh, you just
> use this number and that number, and you set them as attributes to the
file
> and it magically talks to this device..."
>
> Stephen
>
>
> Please read the FAQ at http://www.tux.org/lkml/
>
> ------------------------------
>
> End of linux-kernel-digest V1 #4582
> ***********************************
>
> To subscribe to linux-kernel-digest, send the command:
>
> subscribe linux-kernel-digest
>
> in the body of a message to "Majordomo@vger.rutgers.edu". If you want
> to subscribe something other than the account the mail is coming from,
> such as a local redistribution list, then append that address to the
> "subscribe" command; for example, to subscribe "local-linux-kernel":
>
> subscribe linux-kernel-digest local-linux-kernel@your.domain.net
>
> A non-digest (direct mail) version of this list is also available; to
> subscribe to that instead, replace all instances of "linux-kernel-digest"
> in the commands above with "linux-kernel".
>
-
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.tux.org/lkml/