Subject: Linux-Development Digest #853
From: Digestifier <Linux-Development-Request@senator-bedfellow.MIT.EDU>
To: Linux-Development@senator-bedfellow.MIT.EDU
Reply-To: Linux-Development@senator-bedfellow.MIT.EDU
Date:     Thu, 23 Jun 94 22:13:05 EDT

Linux-Development Digest #853, Volume #1         Thu, 23 Jun 94 22:13:05 EDT

Contents:
  Re: Major device number clash (iCS) (Nick Holloway)
  Maximizing disk/network performance (Jim Harkins)
  Re: Major device number clash (iCS) (Brandon S. Allbery)
  Re: SIGCHLD not sent or ignored? (Lee J. Silverman)
  Re: Setting TCP timeouts (Alan Cox)
  Re: Filesystem semantics protecting meta data ... and users data (Alan Cox)
  Re: Deadlock with unix domain sockets (Alan Cox)
  Re: Where has Stephen Tweedie gone?? (Alan Cox)
  Subnetting on byte boundaries
  Re: Hard disks limited to 16 heads? (Peter Herweijer)
  Xfree86 and WD cards (Marcin Krzysztof Porwit)
  Re: 'meta data' - the old fashioned way (Case Larsen)
  Re: cp truncate some dos files, why? (Rob Janssen)

----------------------------------------------------------------------------

From: Nick.Holloway@dcs.warwick.ac.uk (Nick Holloway)
Subject: Re: Major device number clash (iCS)
Date: Thu, 23 Jun 1994 16:52:44 GMT

In <2uauvn$svq@sun.cais.com> ericy@cais.cais.com (Eric Youngdale) writes:
>       It would seem that neither the iBCS2 nor the sound driver has 
> officially reserved major number 30.  Take a look in include/linux/major.h.
> I think that since we (iBCS2) got there first that we should get it, but 
> this is my own personal bias of course.  We should probably reserve the 
> major numbers for these packages in the include/linux/major.h so as to 
> prevent these sorts of problems.

This doesn't help where two add-on packages choose the same major number,
since <linux/major.h> (largely) has major numbers for device drivers
included in the distribution kernel.

This problem was supposed to be dealt with by Rick Miller's device list,
but I haven't heard of that for a while (May 4th 1993 was last revision).
Actually, rick@ee.uwm.edu is an unknown user.

Since I am the author of MAKEDEV, perhaps I should offer to take
over trying to allocate unique major numbers?  What do people think?
This would also help to ensure that I get the information about device
names and numbers.

BTW:  The latest MAKEDEV will be released mid July, after I have moved
to a new job, and settled the business of net-connectivity.  It will
allow the parsing of /proc/devices to determine the major device number.

--
Nick Holloway |  `O O'  | Apparently <Nick.Holloway@dcs.warwick.ac.uk>
[aka `Alfie'] | // ^ \\ |   formerly <alfie@dcs.warwick.ac.uk>

------------------------------

From: jharkins@netcom.com (Jim Harkins)
Subject: Maximizing disk/network performance
Date: Thu, 23 Jun 1994 16:35:06 GMT

I'm running an application for which I need maximum disk and ethernet
performance.  Right now I've got an Adaptec SCSI controller for the disk
and an Elite 16 for the network.  The system is a 50 Mhz 486 on an EISA 
bus.  The Linux kernel is 1.1.0, I got it off the Yggdrasil Summer 94
CD-Rom.

My question is, what combination of hardware and software will give me
the best performance?  The goal is to pump a 40 Megabyte file across
the network in under a minute.  What I really need is a SCSI card with
an ethernet port out the back, then I could just say 'TCP/IP this file
over to fred'.

I seem to recall seeing various reports on Ethernet card speeds.  I didn't
need them at the time so I didn't pay much attention :-(  Are these archived
anywhere?

jim

-- 
"I want to die peacefully in my sleep like my grandfather.  Not screaming
in terror like his passengers."

Jim Harkins                          jharkins@netcom.com 
San Diego, CA.


------------------------------

From: bsa@kf8nh.wariat.org (Brandon S. Allbery)
Subject: Re: Major device number clash (iCS)
Date: Thu, 23 Jun 1994 16:28:34 GMT

In article <2uauvn$svq@sun.cais.com>, ericy@cais.cais.com (Eric Youngdale) says:
+---------------
| In article <2u6p3g$18nh@serra.unipi.it>,
| Romano Giannetti <romano@pimac2.iet.unipi.it> wrote:
| >Only to point out to all around here that iBCS2 and the PC sound
| >driver (for reference: pcsndrv-0.6 ibcs-940526) use the same major
| 
|       It would seem that neither the iBCS2 nor the sound driver has 
| officially reserved major number 30.  Take a look in include/linux/major.h.
| I think that since we (iBCS2) got there first that we should get it, but 
+------------->8

Last time I checked, Linux only supported 32 major device numbers... and we're
about to run into the limit.  I hit this problem also, and took the same
solution (change iBCS) because (a) it was more convenient and (b) PCSNDRV was
already in my kernel :-)

++Brandon
-- 
Brandon S. Allbery         kf8nh@kf8nh.ampr.org          bsa@kf8nh.wariat.org
Friends don't let friends load Windows NT.              Linux iBCS2 emulation

------------------------------

From: lee@netspace.cis.brown.edu (Lee J. Silverman)
Subject: Re: SIGCHLD not sent or ignored?
Date: 23 Jun 1994 20:32:33 GMT


        I discovered the error.  By default, Linux follows the SysV
signal standards.  The first SIGCHLD was being caught by the parent,
but every subsequent signal was lost because the signal handler needed
to be reset.  Adding another call to signal after the wait3() call in
the signal handler did the trick.

        Mail me for details if you're interested.

Lee

--
Lee Silverman, Brown class of '94, Brown GeoPhysics ScM '95
Email to: Lee_Silverman@brown.edu
Phish-Net Archivist: phish-archives@phish.net
"Nonsense - you only say it's impossible because nobody's ever done it."

------------------------------

From: iiitac@uk.ac.swan.pyr (Alan Cox)
Subject: Re: Setting TCP timeouts
Date: Thu, 23 Jun 1994 12:57:49 GMT

In article <perin.33.0013610E@mail.med.cornell.edu> perin@mail.med.cornell.edu (Lewis Perin) writes:
>The man page for getsockopt/setsockopt in the Linux version I use (kernel 
>1.1.0, Yggdrasil Summer '94) lists options for TCP timeouts: SO_RCVTIMEO and 
>SO_SNDTIMEO, both advertised as valid at the socket level (SOL_SOCKET.)  gcc 
>unfortunately has never heard of them; they aren't to be found in 

Linux doesn't implement these extremely weird BSDisms (I've only ever met
two programs that use them so it definitely doesn't justify the kernel bloat
in either Linux or BSD). You can do the same things with select() and non
blocking I/O.

Alan


------------------------------

Crossposted-To: comp.benchmarks,comp.sys.sun.admin,comp.security.unix
From: iiitac@uk.ac.swan.pyr (Alan Cox)
Subject: Re: Filesystem semantics protecting meta data ... and users data
Date: Thu, 23 Jun 1994 12:59:41 GMT

In article <2u9u2e$8e8@unpc.queernet.org> rogerk@unpc.queernet.org (Roger B.A. Klorese) writes:
>In article <idletimeCrM8v4.Ex9@netcom.com>,
>Totally Lost <idletime@netcom.com> wrote:
>>With metadata sync writes the meta data always points to trash until the
>>async write data block is flushed. This is a long window.
>
>...unless you use a file system like VxFS, which supports block-clearing
>before metadata update.
>
>>With any meta data sync write filesystem the window is open nearly the
>>entire time the file is being written - this is not a matter of badly-timed.
>
>...Unless clears are done synchronously as well.

I beg to differ. If each block has a timestamp you know whether it is pre or
post inode update. This avoids the need to clear synchronously.

Alan

------------------------------

From: iiitac@uk.ac.swan.pyr (Alan Cox)
Subject: Re: Deadlock with unix domain sockets
Date: Thu, 23 Jun 1994 13:03:40 GMT

In article <2uadn6$m7s@zeus.fasttax.com> phil@zeus.fasttax.com (Phil Howard) writes:
>Does this mean that the kernel is not organized where all I/O goes through
>a master point of some sort where things like O_NDELAY can be done in a way
>where it is in effect for all devices?  No, I have not studied the Linux
>kernel long enough yet to get the big picture on how it is organized.  I
>probably should soon since I have an idea would want to try in the kernel
>as a device driver.

Things like O_NDELAY are driver level semantics as in BSD and I assume SYS5
To start with some drivers interpret O_NDELAY in different ways and it can have
meaning at open time too (eg tty drivers).

The problem is however much of what you describe. Linux lacks a sensible lower
level socket layer(*). The socket semantics are currently in each protocol and
once 1.1.21->x are stable the support code for fixing this then the fixes 
themselves go into the real kernel. Only when that is done is it worth sorting
out AF_UNIX properly to handle SOCK_DGRAM etc.

Alan

(*) Unlike drivers socket semantics are almost totally common.


------------------------------

From: iiitac@uk.ac.swan.pyr (Alan Cox)
Subject: Re: Where has Stephen Tweedie gone??
Date: Thu, 23 Jun 1994 13:19:29 GMT

In article <RSANDERS.94Jun23000310@hrothgar.mindspring.com> rsanders@mindspring.com (Robert Sanders) writes:
>enhancements to Linux's VFS, among other things, so it's likely to be
>a big project; I'm sure Remy would appreciate some help.  As for when
>4.4BSD will be available for anon. ftp, nobody seems to want to make
>it available because of the guaranteed ftp storm.  FreeBSD will

src.doc.ic.ac.uk:/packages/unix/4.4bsd-lite/......

ALan


------------------------------

From:  <dennyfox@maroon.tc.umn.edu>
Subject: Subnetting on byte boundaries
Date: Tue, 21 Jun 1994 17:48:56 GMT

In paragraph 4.1 of the NET-2 HOWTO, there is a statement that subnetting 
is supported on bytes boundaries only, "at this time". Does anyone know 
when this restriction may be lifted? I'm in the process of designing a new 
network topology for our company, and this might make a difference for me.
Thanks...


Denny Fox         email dennyfox@maroon.tc.umn.edu

------------------------------

From: pieterh@sci.kun.nl (Peter Herweijer)
Subject: Re: Hard disks limited to 16 heads?
Date: Thu, 23 Jun 1994 13:32:17 GMT

bcr@k9.via.term.none (Bill C. Riemers) writes:

 >Actually, I've yet to see a harddrive with 32 heads.  I don't think
 >they make them...  Normally when someone claims they have 32 heads,
 >its because that is what thier BIOS said, but thier BIOS is wrong.

Pfff... I've never seen an IDE drive with 16 heads either.  But that's
beside the point.  Claiming that "the BIOS is wrong" is kicking in the 
proverbial open door... the BIOS is _always_ "wrong" these days.  There
is no connection anymore between logical and physical disk geometry.

That's why LBA makes so much sense.

 >If anyone comes across a real drive that has more than 16 heads, I'm
 >sure there would be more trouble convincing Linus to remove this
 >restriction.

The physical number of heads doesn't matter.  And Linus has nothing to
do with this restriction.

 >    >This is a limitation of the BIOS.
 >
 >Only some BIOS's have this limitation.  With my BIOS it autoscans 
 >32 heads with my 1725MB harddrive.

You didn't quote the context, but I was probably not talking about
heads anymore, but about cylinders.

 >                       [...]  However, since this I know this
 >is wrong, I select USER_CONFIG and type in the parameters listed on
 >a sticker on the side of my harddrive.

It's not "wrong" in the sense that you have to specify exactly what
the sticker on your drive says, because you don't.

 >                       [...]  This makes Linux and DOS 
 >happy.  (Although Lilo doesn't seem to like it!!!)  And yes, the
 >correct parameters for me are 16 heads, and double the # of cylinders
 >from what is auto-detected.

Yes.  The autodetect automagically halves the number of cylinders and
doubles the number of heads so that the BIOS/DOS interface can grok the
drive.  When talking to the drive, the BIOS no doubt uses the original
geometry.  Linux doesn't access the drive through the BIOS and therefore
cannot work with this remapping feature.

Nor does it need to, since it doesn't share the BIOS limits.

 >    >There is a standard called "enhanced IDE" that should solve those
 >    >problems.
 >
 >   Yes.  No bullshit, no physical and logical geometry hassles, just
 >   Linear Block Addressing (LBA).
 >
 >No I believe enhanced IDE still only allows 16 heads.

*sigh* that's quite beside the point of LBA.

 >But more than 1024 cylinders are allowed.

Big deal.  You don't need EIDE for that---IDE also allows more than
1024 cylinders.  Did you read my post or what?

 - Peter Herweijer
   pieterh@sci.kun.nl

------------------------------

Crossposted-To: comp.os.linux.admin,comp.os.linux.help
From: mkporwit@tucson.Princeton.EDU (Marcin Krzysztof Porwit)
Subject: Xfree86 and WD cards
Date: Wed, 22 Jun 1994 20:46:27 GMT

Hi,

I have just looked at the WWW site at UNC to check if XFree v3.0
supports my WD90C33 card, but the info they have there only refers to
Xfree v2.1. Does anyone know if X now works with this graphics card,
or if there is a patch out for it, or do I have to buy another
graphics card?
--
In search of the eternal buzz... (and more caffeine)

Marcin K. Porwit '96                    68 Spelman Hall
mkporwit@phoenix.princeton.edu          mkporwit@pucc.bitnet
www page = http://www.princeton.edu/~mkporwit
GCS/GS;d--;p+;c+++(++++);l++;u++;e+;m+(-);
s++/s+;!n@;h(+);f+;!g;w+(++);t+;r+(+++);y+(*)


------------------------------

From: clarsen@intruder.lbl.gov (Case Larsen)
Crossposted-To: comp.benchmarks,comp.sys.sun.admin
Subject: Re: 'meta data' - the old fashioned way
Date: 23 Jun 1994 06:50:35 GMT

In article <peterd.772211411@pjd.dev.cdx.mot.com>,

>It sounds an awful lot like a log-structured filesystem to me. There's
>been a lot of work on this lately - see, for instance, Sprite. (which
>is available - source and binaries - on a CDROM from Walnut Creek)
>
>If anyone's really interested in adding such a filesystem to Linux,
>I'm sure an afternoon at a good university library would turn up a few
>candidates besides Sprite, including maybe one or two ones that run on
>real Unix. The exercise of finding the source and porting it to Linux
>is left to the reader...

I would think that the Sprite filesystem is a good candidate since
at least a reference implementation is available for a nominal cost 
(price of the CD) and I get these kind of numbers on Sprite (Decstation
5000 w/ 128MB ram with some unknown disk drive) and a couple of other 
machines.  LFS on this platform is getting to be at least within a factor 
of 3 of the best I can do with widely available and tested code.  I would
also think that LFS isn't tuned as well as the Sun filesystem so these 
numbers are lower bounds.

DS5000, Sprite 1.117, unknown drive
8192 byte/files:100 files:304.761905 files/second:0.328125 seconds
8192 byte/files:500 files:102.728721 files/second:4.867188 seconds
8192 byte/files:1500 files:71.910112 files/second:20.859375 seconds
8192 byte/files:2000 files:38.554217 files/second:51.875000 seconds
8192 byte/files:4000 files:21.869127 files/second:182.906250 seconds

vs. SparcServer 1000 128MB, Solaris 2.3 Presto, with ST31200N
8192 byte/files:100 files:371.351012 files/second:0.269287 seconds
8192 byte/files:500 files:265.959710 files/second:1.879984 seconds
8192 byte/files:1500 files:99.809603 files/second:15.028614 seconds
8192 byte/files:2000 files:100.119588 files/second:19.976111 seconds
8192 byte/files:4000 files:62.578623 files/second:63.919591 seconds

vs. 486DX2/66, Linux 1.1.17, ST11200
8192 byte/files:100 files:369.665268 files/second:0.270515 seconds
8192 byte/files:500 files:126.773498 files/second:3.944042 seconds
8192 byte/files:1500 files:71.998705 files/second:20.833708 seconds
8192 byte/files:2000 files:60.053802 files/second:33.303470 seconds
8192 byte/files:4000 files:39.126569 files/second:102.232321 seconds

Just for fun, a try at the maximum on today's hardware (totally ignores
safety or the cost of I/O).  Still disappointing because you get between
1.2 and 5.5MB/sec throughput on these sized files.  Main memory bandwidth
is 40MB/sec.:

SparcServer 1000... tmpfs (memory based filesystem)
8192 byte/files:100 files:664.730086 files/second:0.150437 seconds
8192 byte/files:500 files:514.266789 files/second:0.972258 seconds
8192 byte/files:1500 files:297.959987 files/second:5.034233 seconds
8192 byte/files:2000 files:247.540162 files/second:8.079497 seconds
8192 byte/files:4000 files:149.011654 files/second:26.843538 seconds

                                                        -Case Larsen
                                                         CTLarsen@lbl.gov

------------------------------

From: rob@pe1chl.ampr.org (Rob Janssen)
Subject: Re: cp truncate some dos files, why?
Reply-To: pe1chl@rabo.nl
Date: Wed, 22 Jun 1994 17:43:01 GMT

In <x5x1kukh1u48066yn@shore.net> bjb@shore.net (Beverly J. Brown) writes:

>In article <Crorz6.1DA@pe1chl.ampr.org>, Rob Janssen wrote:
>> In <uiB1kukh1CZG066yn@shore.net> bjb@shore.net (Beverly J. Brown) writes:
>> 
>> >In article <1994Jun17.170538.27707@rosevax.rosemount.com>, Grant Edwards wrote:
>> >> Romano Giannetti (romano@pimac2.iet.unipi.it) wrote:
>> >> 
>> >>   [file being truncated when cp'ed]
>> >> 
>> >> 
>> >> Since PC-DOS (and MS-DOS) were "derived" from CP/M, and many of the
>> >> early PC-DOS applications were ports of CP/M applications, the
>> >> convention of using a ctrl-Z as an EOF marker persisted, even though
>> >> PC-DOS (at least in 2.0 and later) keeps track of how long files are
>> >> and will return EOF when you try to read past the last "real" data
>> >> byte in the last block.
>> >> 
>> 
>> 
>> >Linux shoud NOT rely on CTRL-Z. It should do the right thing as DOS has 
>> >since, as you pointed out, version 2.0.
>> 
>> This behaviour is caused by "conv=auto".  You won't believe how many DOS
>> editors, even fairly recent ones, still append a ^Z at the end of the
>> file :-(

>I thought the text/binary modes referred to the CR/LF translation rather 
>than CTRL-Z.

They refer to both...

>It shouldn't truncate at CTRL-Z even for text files unless it 
>is the last character in the file.

Try to read a text file with an embedded CTRL-Z from a DOS program.
You will be surprised to find how many programs will stop at the first
CTRL-Z in the file!
This in fact even includes COPY.  When you copy a file to a device, COPY
assumes it is a text file, so:

        copy filename prn:

loses when the file has CTRL-Z embedded in it, e.g. when it is a file
containing graphical data you want to be printed.  COPY has the switch /B
to force handling of the file in binary (= don't touch anything) mode.
Of course, copying disk-to-disk under DOS never needs any translation,
so COPY cleverly assumes the binary mode when it is copying disk-to-disk,
and most people do not even know about the above.


At any rate, only deleting CTRL-Z at the end of the file would only cause
this particular problem to be partly solved, and the CR/LF translation
would still be going on.  I.e. the file corruption by conv=auto becomes
even more subtle...

My recommendation: don't use conversion in the filesystem, do it using
a tool when you know you need it.

Rob
-- 
=========================================================================
| Rob Janssen                | AMPRnet:   rob@pe1chl.ampr.org           |
| e-mail: pe1chl@rabo.nl     | AX.25 BBS: PE1CHL@PI8UTR.#UTR.NLD.EU     |
=========================================================================

------------------------------


** FOR YOUR REFERENCE **

The service address, to which questions about the list itself and requests
to be added to or deleted from it should be directed, is:

    Internet: Linux-Development-Request@NEWS-DIGESTS.MIT.EDU

You can send mail to the entire list (and comp.os.linux.development) via:

    Internet: Linux-Development@NEWS-DIGESTS.MIT.EDU

Linux may be obtained via one of these FTP sites:
    nic.funet.fi				pub/OS/Linux
    tsx-11.mit.edu				pub/linux
    sunsite.unc.edu				pub/Linux

End of Linux-Development Digest
******************************
