HDTenEightyP/NetNews huggingface dataset:
From: mjr@hussar.dco.dec.com (Marcus J. "will do TCP/IP for food" Ranum)
Subject: Re: How to know if file is on NFS filesystem?
Keywords: NFS
Organization: Digital Equipment Corporation, Washington ULTRIX Resource Center
Date: Wed, 8 Apr 1992 18:32:55 GMT

gus@progress.COM (Gus Bjorklund) writes:
>So far the only thing I have come up with is to read /etc/mtab (using
>getmntent ()) but this is fairly ugly because I have to look for
>a partial match with the pathname of the file and there may be more than one.
>This works on Sun but is not very portable.
>DEC tells us that there is no way on Ultrix.

	I'm surprised DEC told you there's no way. I do it and I work
for DEC. :)   Matching partial names is gookey in the extreme. Use the
mounted-on-device. I don't see why my approach (which is faster than
gooking through names is anyhow) won't work on Suns, too.

mjr.

--------------------------------------------------------------------------
#include	<sys/types.h>
#include	<sys/stat.h>
#include	<sys/param.h>
#include	<sys/mount.h>
#include	<sys/fs_types.h>


/*
what this does is cache away all the filesystem devices that are NOT
local ULTRIX filesystems.
this way we can quickly look and see if we're looking at something
that's NFS-mounted.
*/

static	dev_t	nfsdevs[NMOUNT];
static	int	highwat = 0;

/* snarf the mounted-on inodes of all NFS devices */
nfs_setup()
{
	struct	fs_data	mountbuf;
	struct	stat	sbuf;
	int		erd;
	int		loc = 0;
	int		x;

	while((erd = getmountent(&loc,&mountbuf,1)) == 1) {
		if(mountbuf.fd_fstype == GT_ULTRIX)
			continue;

		if(stat(mountbuf.fd_path,&sbuf)) {
			perror(mountbuf.fd_path);
			continue;
		}
		nfsdevs[highwat++] = sbuf.st_dev;
	}
	return(0);
}


nfs_mounted(path)
char	*path;
{
	struct	stat	sbuf;
	int		x;

	if(stat(path,&sbuf))
		return(-1);
	for(x = 0; x < highwat; x++)
		if(nfsdevs[x] == sbuf.st_dev)
			return(0);
	return(1);
}
-- 
	This is an OPEN .signature. You can license it directly from the
author. The fact that it is seen across the world on USENET makes it a
De Facto STANDARD, too. Anyone who doesn't use this .signature is clearly
trying to lock you in to a proprietary .sig! 	- notebooks of a heretic
From: abe@mace.cc.purdue.edu (Vic Abell)
Newsgroups: comp.unix.internals
Subject: Re: How to know if file is on NFS filesystem?
Keywords: NFS
Date: 10 Apr 92 19:56:05 GMT

Some systems indicate that a file is remotely (NFS) mounted by setting the
high order bit of st_dev in the stat(2) buffer.

AIX 3.2 even has lines in <sys/stat.h> that read:

/*
 * st_dev bit definitions
 */
#define SDEV_REMOTE     0x80000000      /* remote `device' if on        */

DYNIX 3.0.12, NeXTStep 2.1 and SunOS 4.1 do the same with slight variations
on how they use the remaining bits of st_dev.
From: root@candle.uucp (Bruce Momjian)
Newsgroups: comp.unix.internals
Subject: Re: Unix kernal diagram
Date: 10 Apr 92 15:43:09 GMT
Organization: a consultant's basement

kevinc@sequent.com writes:
: In article <1992Apr7.043550.7500@candle.uucp> root@candle.uucp (Bruce Momjian) writes:
: >suggestions or corrections, I would be glad to include them.  It is 57
:  ^^^^^^^^^^^^^^^^^^^
: 
:     Spell KERNEL right :-)
 
Thanks for the correction.  I did have it spelled KERNEL, but then saw
it spelled KERNAL, and said, "Oh, I have been spelling it wrong all this
time.  Better correct it."

-- 
Bruce Momjian           | 830 Blythe Avenue               | home: (215)853-3000
root%candle.uucp@ls.com | Drexel Hill, Pennsylvania 19026 | work: (215)353-9879
From: guy@Auspex.COM (Guy Harris)
Newsgroups: comp.unix.internals
Subject: Re: How to know if file is on NFS filesystem?
Keywords: NFS
Date: 13 Apr 92 21:40:11 GMT
Organization: Auspex Systems, Santa Clara

>We do it too, and yet another way:
>
>SunOS and ConvexOS:          f_type == MOUNT_NFS

SVR4:

	#include <sys/types.h>
	#include <sys/statvfs.h>

	...

	struct statvfs buf;

	if (statfvs(pathname, &buf) < 0)
		complain and die;

which *MIGHT* put "nfs" in the "f_basetype" field if the file system is
NFS-mounted, although they indicate that if it's *RFS*-mounted, it gives
the file system type of the file as it's mounted on the *SERVER*, not
"rfs"....

Another possibility seems to be to use "sysfs()":

	#include <sys/fstyp.h>
	#include <sys/fsid.h>

	int fs_index;
	char fs_type[FSTYPSZ];

	/*
	 * Get "file-system type index".
	 */
	fstype = sysfs(GETFSIND, pathname);
	if (fstype == -1)
		complain and die;

	/*
	 * Convert that to a file system type identifier.
	 */
	if (sysfs(GETFSTYP, fs_index, fs_type) < 0)
		complain and die;

which I presume would put "nfs" in there for an NFS file system.

I'd be inclined not to directly use the type index; I don't know that
there's any guarantee that those indices will be the same for all time
for any given file system type.
Newsgroups: comp.unix.internals
From: boyd@prl.dec.com (Boyd Roberts)
Subject: Re: Accessing the PROCess table (how?)
Organization: Digital Equipment Corporation - Paris Research Laboratory
Date: Wed, 15 Apr 92 20:12:58 GMT

In article <1992Apr14.160552.12365@gateway.novell.com>, terry@ithaca.Eng.Sandy.Novell.COM (Terry Lambert) writes:
> 1)	Open /unix, /vmunix, or /fred, whatever your kernel is named.
> 2)	Using /usr/include/a.out.h as a template, look up the symbol you want to access;
> 	in your case, the process table.  This is probably "proc", but your mileage may
> 	vary with your kernel.

Wrong.  man nlist(3).

> 3)	Open /dev/kmem and lseek to the location in the data area.
> 4)	Traverse the list, reading.
> 5)	Decode the fields according to /usr/include/sys/proc.h.

Using the data returned by nlist(3) mung the address offsets into some
useful value then lseek and read from /dev/kmem.  Munging is probably
necessary and will be machine dependent (eg. on a VAX you usually clear
the 0x80000000 bit from the address to get the lseek offset).

> 6)	Some information may not be available, since many things in the kernel can
> 	be swapped out, and a reference to /dev/kmem may not be sufficient to
> 	fault them in.  In particular, the user struct may be unavailable (this is not true
> 	of SunOS, which does not swap or relocate it's user structs).
> 

Only the currently running process' (ie. your proc table snooper) u-area
will be mapped by /dev/kmem.  You will have to use /dev/mem and/or /dev/swap
(or /dev/drum or whatever it's called to find u-areas).  Reads on /dev/kmem
will certainly _not_ `fault them in'.


Boyd Roberts			boyd@prl.dec.com

``When the going gets wierd, the weird turn pro...''
Xref: sparky comp.unix.internals:1086 comp.sys.sun.misc:1824
From: jim@cs.strath.ac.uk (Jim Reid)
Newsgroups: comp.unix.internals,comp.sys.sun.misc
Subject: Re: SYNCHRONIZING THE 'DATE' ON A NETWOK
Date: 9 Apr 92 08:39:15 GMT
Organization: Computer Science Dept., Strathclyde Univ., Glasgow, Scotland.
In-reply-to: ely@tlsups01.uucp's message of 8 Apr 92 10:38:17 GMT

In article <1992Apr8.102223@tlsups01.uucp> ely@tlsups01.uucp (Ely Cohen) writes:

  I'm facing a problem synchronizing the time on all workstations on a network.

  I would like to find a way that all the workstations will update their local 
  date automaticly (once a day) from one remote workstation. I'll be
  thankful if someone could come up with a good solution or refer me to an
  existing one.

Suns come with a utility - rdate - which does that. However, this is
not really satisfactory. rdate will "jump" the time of day clock
forwards (or backwards!) by large amounts. The clocks on your
workstations could drift by a few seconds or more in between your
daily (or whatever) invocations of rdate.

The best solution is to use the Network Time Protocol (NTP) which can
keep all your machines synchronised to within hundredths of a second
of each other. If you have access to a reliable external time source
- for instance a radio clock - the systems can be closely synchronised
to UTC.

Various implementations of NTP are available for anonymous FTP from
louie.udel.edu (128.175.1.3) in /pub/ntp.

		Jim
Newsgroups: comp.unix.internals
From: jsmith@cibecue.az05.bull.com (Joe Smith)
Subject: Memory Map
Organization: Bull HN Information Systems, Inc., Phoenix Product Division
Date: Wed, 15 Apr 92 20:44:00 GMT

I am running a Bull DPX2 Model 150 system (486-33 Zenith EISA) under SCO
Open Desktop v3.2.2 and am having problems using crash to analyze a process
abort.  Is there a header file somewhere that shows the memory map of the
kernel?  So far I have not had any luck in finding it in the plethora of
header files for all the devices.
Newsgroups: comp.unix.internals
From: terry@ithaca.Eng.Sandy.Novell.COM (Terry Lambert)
Subject: Re: Accessing the PROCess table (how?)
Organization: Novell NPD -- Sandy, UT
Date: Tue, 14 Apr 1992 16:05:52 GMT

In article <1992Apr14.010355.25779@Princeton.EDU>, bmrosen@screen.Princeton.EDU (Brian M. Rosen) writes:
|> 
|> 	Could someone please tell me how to access the information stored in
|> the PROCess table.  I can't seem to find any reference to it in the MAN pages.
|> Thanks a lot.
|> 							Brian
|> -- 
|> -------------------------------------------------------------------------------
|> |   Brian Rosen           |       "The human spirit is a hard thing to kill." |
|> |   Princeton University  |                "Even with a chainsaw."            |
|> |   No stress at all.     |                            -Tha Addams Family     |

1)	Open /unix, /vmunix, or /fred, whatever your kernel is named.
2)	Using /usr/include/a.out.h as a template, look up the symbol you want to access;
	in your case, the process table.  This is probably "proc", but your mileage may
	vary with your kernel.
3)	Open /dev/kmem and lseek to the location in the data area.
4)	Traverse the list, reading.
5)	Decode the fields according to /usr/include/sys/proc.h.
6)	Some information may not be available, since many things in the kernel can
	be swapped out, and a reference to /dev/kmem may not be sufficient to
	fault them in.  In particular, the user struct may be unavailable (this is not true
	of SunOS, which does not swap or relocate it's user structs).


						Hope this helps; happy hacking

						Terry Lambert
						terry_lambert@gateway.novell.com
						terry@icarus.weber.edu
Newsgroups: comp.unix.internals
From: gus@progress.COM (Gus Bjorklund)
Subject: How to know if file is on NFS filesystem?
Keywords: NFS
Organization: Progress Software Corp.
Date: Wed, 8 Apr 1992 16:24:38 GMT

Is there a way to find out of a file is on a filesystem that is NFS mounted
(or some other remote filesystem)? I need to know if my transaction log files
and/or database files are not on the local filesystem.

So far the only thing I have come up with is to read /etc/mtab (using
getmntent ()) but this is fairly ugly because I have to look for
a partial match with the pathname of the file and there may be more than one.
This works on Sun but is not very portable.
DEC tells us that there is no way on Ultrix.

Digging through the kernel tables is not a viable option because it may break
when the os is updated and it isnt likely to port easily anyway.

--
Gus Bjorklund                     UUCP:     ...mit-eddie!progress!gus
Progress Software Corp.           Internet: gus@progress.com
14 Oak Park
Bedford, MA  01730
Newsgroups: comp.unix.internals
From: jp@ipac.caltech.edu (John Pipkins)
Subject: Re: Accessing the PROCess table (how?)
Reply-To: jp@ipac.caltech.edu
Organization: Infrared Processing and Analysis Center (JPL/NASA)
Date: Thu, 16 Apr 1992 17:19:00 GMT

In article <1992Apr14.160552.12365@gateway.novell.com>, terry@ithaca.Eng.Sandy.Novell.COM (Terry Lambert) writes:
|> 1)	Open /unix, /vmunix, or /fred, whatever your kernel is named.
|> 2)	Using /usr/include/a.out.h as a template, look up the symbol you want to access;
|> 	in your case, the process table.  This is probably "proc", but your mileage may
|> 	vary with your kernel.

You might want to look for a routine with "_nlist" in it.  This will locate
values in the kernel without having to do all that a.out stuff.  It's called
"kvm_nlist" on Suns.

|> 3)	Open /dev/kmem and lseek to the location in the data area.
|> 4)	Traverse the list, reading.
|> 5)	Decode the fields according to /usr/include/sys/proc.h.
|> 6)	Some information may not be available, since many things in the kernel can
|> 	be swapped out, and a reference to /dev/kmem may not be sufficient to
|> 	fault them in.  In particular, the user struct may be unavailable (this is not true
|> 	of SunOS, which does not swap or relocate it's user structs).
|> 
|> 
|> 						Hope this helps; happy hacking
|> 
|> 						Terry Lambert
|> 						terry_lambert@gateway.novell.com
|> 						terry@icarus.weber.edu
Xref: sparky comp.unix.internals:1065 comp.unix.sysv386:8230
From: terryl@sail.LABS.TEK.COM
Newsgroups: comp.unix.internals,comp.unix.sysv386
Subject: Re: swap space
Date: 6 Apr 92 19:04:34 GMT
Followup-To: comp.unix.internals
Organization: Tektronix, Inc., Beaverton,  OR.

In article <kti7s1INNioa@early-bird.think.com> barmar@think.com (Barry Margolin) writes:
>In article <1992Mar31.213816.13925@comp.vuw.ac.nz> duncan@comp.vuw.ac.nz (Duncan McEwan) writes:
>>How many "modern" Unixes are there that swap to/from the text file.  I
>>understood most BSD derived systems demand paged from the executable but
>>then still wrote text pages to the swap device when a process got swapped
>>out (presumably because its more efficient to do I/O to the swap device
>>that through the file system?).
>
>Someone correct me if I'm wrong, but I think 4.2bsd did that.  I don't
>think it's any more efficient to do I/O to swap or files, but it may
>simplify handling of modified text pages.  If the system doesn't mark text
>pages read-only, and a text page is modified, it should be paged out to the
>swap area rather than the original executable.


     Your memory is correct, Barry. Under 4.2 BSD, in the routine pagein()
(at least that's what *I* remember the routine name was; whatever the name,
it was the routine that did the majority of the pagein code...), somewhere
around the middle of the routine, there was an explicit comment that said
something (vewwy, vewwy paraphrased...) "Mark pte modified so pages get
written out to the swap area"; note that there were NO TESTS to see what kind
of page it was (Text, Data, or Stack); the ONLY test was for if this is the
first pagein of the page. Therefore, even text pages get written to the swap
area (if need be).

     I always interpreted this as an implicit assumption that it is mucho,
mucho easier to calculate a disk address in the swap area than it is from
a real-live executable, given just a virtual address....

__________________________________________________________
Terry Laskodi		"There's a permanent crease
     of			 in your right and wrong."
Tektronix		Sly and the Family Stone, "Stand!"
__________________________________________________________
Xref: sparky comp.unix.internals:1135 comp.unix.sysv386:8749
From: larry@news.rn.com (Larry Snyder)
Newsgroups: comp.unix.internals,comp.unix.sysv386
Subject: Re: swap space
Date: 16 Apr 92 21:17:41 GMT
Organization: The Gator Public Access Unix Site (219)289-0777

ihno@generics.ka.sub.org (Ihno Krumreich) writes:

>>At least on Interactive you must have at least as much swap as memory.

>Not only for Interactive, but for every SVR4 flavour running on intel.

this just got me thinking -- we rarely swap here -- and it would be
nice if we could put the swap partition on the outer tracks of the
drive (where it is the slowest) -- is this possible (it should be)?

we are running SVR4 3.0

-- 
Larry Snyder                                    internet: larry@gator.rn.com
keeper of the Gator                                 uucp: uunet!trauma!larry
From: obelix@konech.UUCP (Franz Furch)
Newsgroups: comp.unix.internals
Subject: X11 Server for Interactive UNIX Vers. 3.0
Date: 8 Apr 92 09:50:52 GMT
Organization: Kontron Elektronik GmbH Eching, Germany

Hello X gurus,

I need information about the changes to the X11 server interface in Interactive
UNIX from Version 2.2 to Version 3.0. I'm in charge of an X11 server which is 
build in accordance to "The 386/ix X11 Smart Board Interface Specification 
Version 1.2" dated January 1989 and have to port this server to Interactive 
UNIX 3.0 but SunSoft Germany isn't able to give me any information about the 
changes or new versions of the Interface Specification manual.

This is very urgent please !!!
Thanks a lot.

Franz Furch (alias obelix )

Email: ...!mcvax!unido!konech!obelix
From: paul@prcrs.prc.com (Paul Hite)
Newsgroups: comp.unix.internals
Subject: Re: help with kernel routine names
Date: 6 Apr 92 23:38:03 GMT
Organization: PRC Realty Systems, McLean, VA

In article <1992Mar10.113623.19422@unilabs.uucp>, chare@unilabs.uucp (Chris Hare) writes:
> 
> I am not a kernel guru.
Well, neither am I really.  But the guru's have been silent on this question
and the article will expire from my site in a couple of days.  I can shed a
little light on some of this.  My source is "UNIX System Activity Package"
which is chapter 9 in the AT&T manual "UNIX System V Administrator Guide
DEC Processors" which was published in April 1984 (select code 307-101) and
which pertains to System V Release 2.0.

> 	bread
> 	bwrite
> 	lread		logical buffers (disk or tape blocks) read?
> 	lwrite		logical buffers (disk or tape blocks) written ?
> 	phread
> 	phwrite
The b's measure i/o between the buffer cache and the block devices.
The l's measure i/o to the block devices; some will be satified by
the cache; the rest wind up as b's.
The ph's measure i/o to/from the raw devices.

> 	swapin		logical blocks swapped in
> 	swapout		logical blocks swapped out
No.  These are counters incremented with each request for i/o to a
swap device.

> 	bswapin		actual blocks swapped in
> 	bswapout	actual blocks swapped in

Mostly.  swapin and bswapin also reflect initial loading of a program
if it was still on the swap device.

> 	outch		This represents the number of characters which have
> 			been written out.
by the tty subsystem.

> 	runque		number of processes placed on run queue
> 	runocc		number of processes -now- on queue
> 	swpque		number of processes placed on swap queue
> 	swpocc		number of processes -now- on queue
No. Each second system sees if anything is in the run queue.  If so
runocc is incremented and the length of the run queue is added runque.
A swpque and swpocc are similiar but they are swapped processes that are
ready to run.

(end of info paraphrased from source)

The trouble is that these are counters that are maintained by the kernel.
It takes code to do all of this and code can be broken.  Some vendors have
retrofitted this stuff onto kernels that didn't have them before.  The
programmer who did the work might have used your interpretation rather than
the intrepration in my source.

Some things seems to defy a unamimous interpretation.  When this stuff gets
ported to a BSD kernel, it's clear to all of us what syscall should do.
But what about readch?  Is this still just read(2), or does readv(2) count?

I treat these numbers as indicative rather than definitive.  

Paul Hite   PRC Realty Systems  McLean,Va   paul@prcrs.prc.com    (703) 556-2243
    "We are trying to bring up an Air Traffic Control display on an X window 
      terminal and there seems to be some problems." -- from comp.windows.x
From: mike@bohra.cpg.oz.au (Mike Crooks)
Newsgroups: comp.unix.internals
Subject: Re: How to know if file is on NFS filesystem?
Keywords: NFS
Date: 10 Apr 92 09:36:49 GMT
Organization: Computer Power Software

dhesi@cirrus.com (Rahul Dhesi) writes:

>1.   Do a statfs system call and look at the f_files and f_ffree fields.
>If either is -1, the file lies on a non-local filesystem such as NFS.

There's actually a field in the structure returned by statfs() which holds the
file system type.  The trouble is there is no standard usage - for example:

 HP UX (800 series):        f_fsid[1] == MOUNT_NFS

 Risc/Ultrix:               fd_req.fstype == GT_NFS

 AIX:                       f_fsid.val[1] == MNT_NFS

Worse still, some boxes don't define the types, and on others (SCO Unix) you
must call a runtime translation routine.

Anyone know of plans to put statfs() or it's equivalent into Posix or XPG ?
-- 
Mike Crooks                                               Phone:  +61-3-8230222
Computer Power Group, (Software Division)                 Fax:    +61-3-8220089
19 Cato Street, East Hawthorn,                     Email:  mike@bohra.cpg.oz.au
Victoria, Australia, 3123.
From: PJS100T@ODUVM.BITNET (Pam Skillman)
Newsgroups: comp.unix.internals
Subject: Which pipe got SIGPIPE w/o checking each??
Date: 14 Apr 92 20:52:52 GMT
Organization: Old Dominion University

HI, I had posted this to comp.unix.programmer and it was suggested that I
post here to see if anyone has any ideas.

I have lots of forked processes running concurrently and I would like to have
a signal handler to catch SIGPIPE.  Without having to "test" each one after
the SIGPIPE arrives, is there a way of telling which one it was??  Each of
the processes will be running some sort of tool so I don't want to attempt
to write to each as I don't want what I send to be interpreted by the tools.
Is there any way around this??  Are there any error indicators set that could
be examined??  Thanks in advance.
----
 PJ  Skillman
 PJS100T@ODUVM.BITNET       //       Old Dominion University
 PJS100T@ODUVM.CC.ODU.EDU   //       Norfolk, Virginia
Xref: sparky comp.unix.internals:1061 comp.unix.sysv386:8210
Newsgroups: comp.unix.internals,comp.unix.sysv386
Subject: Re: swap space
From: andyb@wndrsvr.la.ca.us (Andy Brager)
Date: Mon, 6 Apr 1992 03:56:20 GMT
Organization: Wonder Server - Public Access for SoCal

pavlov@niktow.canisius.edu (Greg Pavlov) writes:

>In article <1992Mar31.031148.8128@cbnews.cb.att.com>, eao@cbnews.cb.att.com (eric.a.olson) writes:
>> 
>> 	I've seen a lot of talk about swap space around here, and
>>     I've gotten the general idea that it's good to have about 1.5 times
>>     as much swap space as main memory.  

>   Our "rule of thumb" ratio, based on failures in the past, is 3:1 .  The 
>   "standard" recommendation that I see is usually 2:1 .

Ok, I've heard various claims like this.  I would love to know the
reasoning behind it.  No doubt I'll be flamed for not already knowing
the answer to my question, but what the hell.  You only burn once :)

Why would you need more swap space then memory?   I believe I've
been told "so you can do a system dump".  What?  To floppy?  I
have 32M of memory.  I'm supposed to dump 96M to floppy?  Someone
pass me a clue please?  Thanks!

Andy
-- 
		DO NOT BUY TOUCHE COMPUTERS -email for details
Letters: andyb@wndrsvr.la.ca.us
Large Packages (2K+): cerritos.edu!swc!wndrsvr!andyb
-I don't know but I been told; two sides to every story - Joe Walsh
Newsgroups: comp.unix.internals