UNIX-WIZARDS Digest V2#055
Unix-Wizards-Request at BRL.ARPA
Unix-Wizards-Request at BRL.ARPA
Sat Jan 25 20:34:31 AEST 1986
UNIX-WIZARDS Digest Sat, 25 Jan 1986 V2#055
Today's Topics:
flock-fsync problems
Adding a Fujitsu 2361 (Eagle-2) disk to VAX 750 under 4.2Bsd
Non-Internet domain sockets
re: Process control query (4.2 BSD)
Need Driver for HP Laserjet
DEC DMF32 sync port driver wanted
pdp C compiler needed under 4.2
need acutab for scholar modem
Re: Database software for UNIX systems
Increasing 4.2BSD Data Segment Size
More RFS bugs
-----------------------------------------------------------------
From: Robin Cutshaw <robin%itcatl.uucp at BRL.ARPA>
Subject: flock-fsync problems
Date: 23 Jan 86 16:42:53 GMT
To: unix-wizards at BRL-SEM.ARPA
The problem:
open-file
loop
flock file exclusive
write special value to location unique to this process only
fsync
flock file unlock
delay
flock file exclusive
read value from unique location
flock file unlock
endloop
given several processes running the above algorithm and that no process
writes over the unique location allocated to any other process, the
value read is not always the value previously written (when it is wrong
it is the value written on the pass previous to this one).
The question:
Does the flock-fsync mechanism work for multiple processes accessing
the same file? Is their a better/easier/more reliable mechanism to
do this?
-robin (uucp: ..!gatech!itcatl!robin)
-----------------------------
From: Andrew Findlay <andyf%brueer.uucp at BRL.ARPA>
Subject: Adding a Fujitsu 2361 (Eagle-2) disk to VAX 750 under 4.2Bsd
Date: 23 Jan 86 11:02:46 GMT
Keywords: VAX 750 disk Eagle Fujitsu 2361 Emulex SC7002
To: unix-wizards at BRL-SEM.ARPA
Adding an Eagle-2 (Fujitsu 2361) to a 4.2Bsd system
===================================================
I have just put an Eagle-2 onto a VAX 750 under 4.2Bsd.
This article describes how it was done so you need not repeat
my mistakes. The software preparation and debugging took
about 40 man-hours, but with the information presented here
it should be possible in less than 8.
The initial configuration was: 2MB, TU80, RA80 on UDA50, DMF-32
The expanded configuration is: 5MB, TU80, RA80 on UDA50, 2*DMF-32
Eagle-2 on SC7002
The Fujitsu 2361 Eagle-2 is an expanded version of the well
known 2351A Eagle. It has an unformatted capacity of 689MB
against the Eagle's 474MB.
The first thing to note is that the disk transfer rate has
gone up from 1.859 MB/s to 2.458 MB/s. This means that the
Emulex SC7000 is not fast enough to handle the new drive. You
will need an SC7002, which is just a faster version of the
SC7000.
Another hardware point is that the Eagle-2 is in a bigger box
than the Eagle - 770mm long rather than 700mm. In our case this
means that it sticks out at the front of the cabinet.
Since the Eagle-2 was designed after the 4.2Bsd release, it
does not appear in /etc/disktab or in the hp.c drivers. You
will need to put it in. A quick-and-dirty workaround is to set
up the SC7002 to treat the disk as an old-style Eagle - you
lose storage capacity, but get up and running very easily. I
have not tried this.
Setting up the SC7002
=====================
Set up for an 'expanded RM02' emulation with 64 sectors/track.
This is code 30 on SW1-4. The hp.c drivers use 'RM02' as a flag
indicating that the disk type should be determined by asking
for the number of tracks, cylinders, and sectors. You need at
least revision F of PROM 994.
Preparing the drivers
=====================
(1) Use diskpart(8) to generate entries for /etc/disktab and
for the hp.c drivers. Put the result in files for use later.
Call the disk 'eagle2'.
The parameters are as follows:
Type: winchester
Sector size: 512
# Sectors/track: 64
# Tracks/cylinder: 20
# Cylinders: 842
Revs per minute: 3600
You should end up with a 'c' partition of 1077760 blocks.
(2) Install the 'eagle2' entry in /etc/disktab
(3) Put entries into your configuration file in /sys/conf,
something like this:
controller mba0 at nexus ?
disk hp0 at mba0 drive 0
This assumes the SC7002 will be the only massbus device - if
you already have massbus devices, the 0's above will change.
The SC7002 actually emulates a massbus controller AND up to
eight massbus disks on one board. (It can split a physical
drive into two logical devices)
(4) Before modifying the system source code, generate a
system from the new config file to check all is ok. If
the controller is installed at this stage, the system
should note the existence of an
'RM02 with 64 sectors/track?'
but should not try to use the device.
(5) Go into /sys/vaxmba to modify the main hp driver.
First take a copy of hp.c for safety, then make changes to hp.c
as follows:
Add the eagle2_sizes entry generated in stage (1) - put it after
eagle_sizes. It should look like this:
}, eagle2_sizes[8] = {
15884, 0, /* A=cyl 0 thru 12 */
66880, 13, /* B=cyl 13 thru 65 */
1077760, 0, /* C=cyl 0 thru 841 */
15884, 294, /* D=cyl 294 thru 306 */
307200, 307, /* E=cyl 307 thru 546 */
377408, 547, /* F=cyl 547 thru 841 */
701248, 294, /* G=cyl 294 thru 841 */
291346, 66, /* H=cyl 66 thru 293 */
Add two lines to hptypes[], just before the final 0:
#define HPDT_EAGLE2 15
-1,
These go just after the line that says 'beware, actually
capricorn or eagle'
Add TWO lines to the hpst[] array, as follows:
{ 64, 20, 64*20, 842, eagle2_sizes, 7, 8 }, /* DUMMY (place holder) */
{ 64, 20, 64*20, 842, eagle2_sizes, 7, 8 }, /* EAGLE-2 */
The dummy line is needed because hptypes[] has a dummy element
14, representing the RM02, whereas hpst[] does not. This one
held me up for a couple of days - the system panics when trying
to reference the disk if you miss the dummy entry.
In the section headed 'EMULEX SC750 or SC780', add code to
recognise the disk at boot time. Put it after the bit that
recognises an eagle:
if (ntracks == 20 && nsectors == 64) {
type = HPDT_EAGLE2;
printf("hp%d: eagle-II\n", mi->mi_unit);
goto done;
}
(6) Re-generate the system with the modified driver.
(7) Use /dev/MAKEDEV to make device entries for hp0
(8) Go into /sys/stand to modify the stand-alone hp driver.
In hp.c add a line to the end of hptypes[], so it looks like this:
.
.
.
MBDT_RM02, /* actually something else */
-1, /* 9300 */
-1, /* Eagle-II */
0
};
In hpmaptype.c add a line to describe the eagle2 and its disk
partitions. Be particularly careful if you did not use diskpart
in stage (1).
short eagle_off[8] = { 0, 17, 0, 391, 408, 728, 391, 87 };
short eagle2_off[8] = { 0, 13, 0, 294, 307, 547, 294, 66 };
Now add two lines in hpst[] so it looks like this:
.
.
.
#define HPDT_9300 13
32, 19, 32*19, 815, rm05_off, /* Ampex 9300 */
#define HPDT_EAGLE2 14
64, 20, 64*20, 842, eagle2_off, /* Fuji Eagle-II */
};
Now add the code to recognise the eagle2:
if (ntracks == 48) {
newtype = HPDT_EAGLE; /* 48 sector Eagle */
goto done;
}
if (ntracks == 64) {
newtype = HPDT_EAGLE2; /* 64 sector Eagle */
goto done;
}
printf("RM02 with %d sectors/track?\n", ntracks);
done:
(9) Reconstruct the standalone utilities with make, and copy
what you need into the root filesystem. This will
probably be:
format
copy
boot
drtest
On a 780, these should go onto the console floppy (?)
(10) Dump the ENTIRE system onto tape and then get the hardware
installed!
(11) The Emulex formatter does not seem to get the bad block
info in the right place for the hp driver, so use the
newly generated version of format(8) to sort that out (in
standalone mode of course). It is then worth using drtest(8)
to check that all the bad blocks have been found.
(12) When you boot up the new system, the lines:
mba0 at tr4
hp0 at mba0 drive 0
hp0: Eagle-II
(or something very similar) should appear on the console.
(13) You should now have a working 540MB disk. Create
filesystems with newfs(8) and put it to work.
To get the best possible performance out of the
filesystems, the rotational delay parameter needs to be
set appropriately with tunefs. I used Don Speck's test
program and found 8ms to be good, so the command is:
tunefs -d 8 /dev/hp0h
Remember to do this for each filesystem after creating it.
Perhaps surprisingly, I can find no significant difference
in performance between a filesystem on an RA80 and one on
an Eagle-2. These tests were done with a load factor of
about 1.4 - one active user with a cpu-bound process:
% time dd if=<big file on RA80> of=/dev/null bs=1024 count=1024
1024+0 records in
1024+0 records out
0.4u 4.8s 0:09 57% 13+9k 129+2io 2pf+0w
% time dd if=<big file on Eagle-II> of=/dev/null bs=1024 count=1024
1024+0 records in
1024+0 records out
0.3u 5.0s 0:09 59% 13+9k 263+2io 2pf+0w
Good luck, and please let me know if I have missed out anything
vital....
Andrew Findlay
... ukc!reading!brueer!andyf
... andyf at uk.ac.bru.ee
--
------------------------------------------------------------
UUCP: ...ukc!reading!brueer!andyf
JANET: andyf%brueer at uk.ac.reading
ARPANET, CSNET: andyf%brueer at ucl-cs.arpa
------------------------------------------------------------
-----------------------------
From: Nathaniel Mishkin <mishkin%apollo.uucp at BRL.ARPA>
Subject: Non-Internet domain sockets
Date: 23 Jan 86 19:53:05 GMT
To: unix-wizards at BRL-SEM.ARPA
I've been attempting to understand how the Berkeley socket mechanism
is intended to be used with non-Internet domain sockets, but it seems
like the naming issue has not been addressed generally. The framework
(e.g. the "sockaddr" struct type) is obviously designed to be
domain-independent, but in practice it seems hard to write
domain-independent programs. For example, the various network programs
(like "telnet") seem to be mightily tied to Internet-style addressing.
My understanding is that 4.3BSD supports XNS -- does this mean that some
of the Internet dependencies have somehow been excised? If so, how?
-- Nat Mishkin
Apollo Computer Inc.
{uw-beaver, wangins, yale}!apollo!mishkin
-----------------------------
From: Brett Galloway <brett%wjvax.uucp at BRL.ARPA>
Subject: re: Process control query (4.2 BSD)
Date: 24 Jan 86 00:15:38 GMT
Keywords: 4.2, BSD, process control
To: unix-wizards at BRL-SEM.ARPA
Last week I posted a query to the net about communicating the success or
failure of an execve() from inside a fork() to the parent process. I got
several responses (thank you). I finally decided to create a pipe between
the child and the parent. If the child's execve() fails, it writes
write(fd,&errno,sizeof(errno))
down the pipe and _exit()'s. If the child's execve() succeeds, the pipe gets
closed automatically, because I explicitly mark the close on exec flag for
the pipe in the parent). Meanwhile, the parent sits on the other end of
the pipe. If it sees EOF (read(fd,&errno_save,sizeof(int) == 0)), it
knows the execve() succeeded. Otherwise, it gets the error code
returned by exeve().
Apparently, the only way for the parent to detect the difference between the
child's execve() failing or succeeding and exiting very quickly is by
using a scheme as above, which explicitly communicates the success/failure of
the execve() from the child to the parent.
-------------
Brett Galloway
{pesnta,twg,ios,qubix,turtlevax,tymix,vecpyr,certes,isi}!wjvax!brett
-----------------------------
From: "Edward M. Rynes Esq." <rynes%cwruecmp.uucp at BRL.ARPA>
Subject: Need Driver for HP Laserjet
Date: 23 Jan 86 18:20:11 GMT
To: unix-wizards at BRL-SEM.ARPA
We will be receiving an HP Laserjet (Plus??) for a free two week
trial run to see if we actualy want to spend money to keep it.
However, as far as I know, we are not getting any software to
drive it. I therefor need a driver that can handle CAT (troff),
dvi (prefered), and/or ditroff output. I also need a ditroff to
dvi filter so I can use ditroff with our Imagen. Many thanks to
everyone who read this far, and endless blessings on all who reply.
As Usual,
Ed Rynes
--
______________________________________________________________________________
Ed Rynes | "Fixed on the front of her
Facilities Manager | Fassbinder face was the kind of a
Dept. of Computer Eng. and Science | smile that only a rather dull child
Case Western Reserve University | could have drawn while attempting
...!decvax!cwruecmp!rynes | a graveyard at night!"
rynes at case.csnet | Roger Waters
______________________________________________________________________________
-----------------------------
From: "George R. Boyce" <george%cornell.uucp at BRL.ARPA>
Subject: DEC DMF32 sync port driver wanted
Date: 23 Jan 86 19:40:57 GMT
To: unix-wizards at BRL-SEM.ARPA
I'ld like to have a DMF32 driver which has support for the
synchronous port which is on that board. If anyone has something
close which needs to be finished or modified, I'ld be glad to
take a stab at it. Thanks.
George Boyce, Cornell Computer Services, george at cornell
-----------------------------
From: Art Hays <hays at BRL-TGR.ARPA>
Subject: pdp C compiler needed under 4.2
Date: 25 Jan 86 00:20:20 GMT
To: unix-wizards at BRL-SEM.ARPA
I would like to be able to generate binaries for a pdp11 V7 system from
4.2 on a VAX. Has anyone put up a pdp11 C compiler (with as, ld, etc) on 4.2
using 'compat' or whatever?
Art Hays, Nat Inst of Health
(301) 496-7143
hays at brl
decvax!brl-bmd!hays
-----------------------------
From: Martin Nicholson <marty%decuac.uucp at BRL.ARPA>
Subject: need acutab for scholar modem
Date: 24 Jan 86 21:23:49 GMT
Keywords: acutab
To: unix-wizards at BRL-SEM.ARPA
I am looking for an acutab for a "scholar modem" (2400 baud).
This is to get it useful for tip. Please answer me by email
directly. Any info/pointers would be greatly appreciated.
thanks,
Marty Nicholson
UUCP: decvax!decuac!marty
VOICE: (301) 731-4100
USMAIL: Digital Equipment Corporation
8301 Professional Place
Landover, MD 20785
-----------------------------
From: mo%wgivax.uucp at BRL.ARPA
Subject: Re: Database software for UNIX systems
Date: 23 Jan 86 13:11:40 GMT
To: unix-wizards at BRL-SEM.ARPA
Look into ORACLE and SIR. Both have problems (ORACLE did not support
4.2 as of July, 1985 and SIR did not support multiple users except
if everyone is interfacing through screens -- no simultaneous batch
or ad hoc queries -- as of August, 1985).
Informix and Unify just won't cut it for large applications, and Ingres
(commercial or not) has a lot of bugs in their UNIX version (the current
UNIX 4.2 port was not even able to complete the turorial outlined in the
manuals without severely crashing). Ingres also requires mods to the
kernel, which some (including myself) feel is a bad way to implement
locking.
These comments stem from an in depth evaluation of these software systems
in July, 1985, including on-hands with SIR, INGRES, and INFORMIX. ORACLE
did not have a version available for 4.2 at the time, and UNIFY was just
too limiting.
Our final decision was to keep what we had -- a Britton Lee Database Machine,
the only valid solution to large database applications (500+ Mb) in the UNIX
environment today (-: in my opinion, of course :-). We have since bought a
second IDM.
BTW: Britton Lee just announced a new "deskside" database machine for around
$40,000 with disk, making it competitive with software systems.
Some addresses you might find useful:
Britton Lee, Inc SIR, Inc ORACLE
14600 Winchester Blvd 5215 Old Orchard Rd
Los Gatos, CA 95030 Skokie, IL 60077 Menlo Park, CA
(408) 378-7000 (312) 470-9770 (415) 854-7350
-----------------------------
From: Ed Mehlschau <em%dscvax2.uucp at BRL.ARPA>
Subject: Increasing 4.2BSD Data Segment Size
Date: 22 Jan 86 03:18:44 GMT
To: unix-wizards at BRL-SEM.ARPA
Anyone ever bump MAXDSIZ in the 4.2BSD kernel? What is
the relationship between MAXDSIZ and NDMAP & DMMAX? More
specifically, how much should NDMAP and DMMAX be increased
for a given increase in MAXDSIZ?
Many thanks,
Ed Mehlschau
ucbvax!ucsbcsl!dscvax2!em
-----------------------------
From: Todd Brunhoff <toddb%tekcrl.uucp at BRL.ARPA>
Subject: More RFS bugs
Date: 23 Jan 86 22:36:10 GMT
To: unix-wizards at BRL-SEM.ARPA
Wayne Power writes:
>1. RFS doesn't seem to care about x bits or file type.
>
> % /remote_host/etc/passwd
>
> ...tries to run the password file as a shell script, even though its mode
> 644. Even more off the wall...
>
> % /remote_host/etc
>
> ...does the same thing.
>
Yep. A bug. Basically, the shell is starting up the interpreter, but
that is probably because it thinks it is the right mode. The bug is
probably in the server in s_access() in serversyscall.c.
>2. Intentional circumfornication like...
>
> % cd /host1/host2
>
> ...hangs the server on 'host1'.
>
RFS is designed not to allow hopping hosts like this example.
It should just fail, but instead causes the server on 'host1' to hang. I
think it is because the server is hung in syscall() in
/usr/sys/machine/trap.c doing the system call over and over. I think
the fix for this is in remote/rmt_general.c around line 147:
/*
* finally, if the user has turned off remote access for himself,
* then just return.
*/
p = u.u_procp;
if (p->p_flag & SNOREMOTE)
return(FALSE); <<<< this should be TRUE?
u.u_error = 0;
>3. If a remote host goes down, it seems that every process that chdir'ed to
> or opened a file on that machine's file system must die before it can be
> unmounted. This gets in the way of a machine crashing and coming back
> without disrupting the rest of the participating machines.
This was listed in the bugs at the end of the installation doc.
Whenever a connection goes down, there may be processes still up
``using'' that connection. However, if there are no open files or
remote chdir(2)'s, the kernel could just as well restart the connection
without waiting for those processes to die. The fix would probably go
in the kernel routine rmt_getconnection(). If there are indeed no open
files or chdir's, then before returning the open socket, just test for
so->so_state & SS_CANTSENDMORE
If set, then clean up the connection and start a new one. If there are
open files or current directories, then things get more complicated.
You could traverse the file table, finding any descriptors pointing to
the dead host and assign them to some "invalid" entry in remote_info[].
This way, the file descriptors will fail gracefully. Another
possibility is just to ignore the old remote file descriptors and fix
the server to handle it. The directories are not quite so bad... the
user would just suddenly find himself in ``/'' when the connection is
restarted.
----------
Another problem related to #1 above is that sometimes real live binary
files on a remote host fail in the kernel execve(), and so the shell
starts to interpret the file, and you get many occurences of:
gobbledygook: not found
Well, the interpretation of the file is the same problem as above, but
the real binary file failing on the execve() is another. The way it
works is that the client kernel sends a request to the server; the server
opens the binary, reads the a.out header, and sends it back to the client,
and then waits for one of two things: 1) a request for the entire binary
to be sent or 2) a "forget it" message saying that the client doesn't
want the binary. For whatever reason, the server is not getting
the "forget it" message, and hence all the file descriptors get
used up, and then NOTHING will exec (and then the shell starts interpreting
binaries).
This problem has only shown up with ATT's ksh (korn shell).
Thank you all for the great feedback, and special thanks to Terry Laskodi
(here at TEKLABS) for many great ideas for the design of RFS. Many hours
he listened to me babble on about the design making great suggestions.
Again, I cannot spend any time on RFS, but I will repost bug reports sent
to me with comments attached about suggested fixes. Naturally, I would
also like to see the fixes if any of you have the time.
Todd Brunhoff
{decvax,ucbvax}!tektronix!crl!toddb
toddb%crl at tektronix.csnet
-----------------------------
End of UNIX-WIZARDS Digest
**************************
More information about the Comp.unix.wizards
mailing list