Messages in this thread |  | | | From | "TOTALPC" <> | | Subject | unsuscribe | | Date | Fri, 8 Oct 1999 23:02:28 -0300 |
| |
----- Original Message ----- From: <owner-linux-kernel-digest@vger.rutgers.edu> To: <linux-kernel-digest@vger.rutgers.edu> Sent: Friday, October 08, 1999 6:00 PM Subject: linux-kernel-digest V1 #4582
> > 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/
|  |