Path: utzoo!mnetor!uunet!unisoft!carl
From: carl@unisoft.UUCP (Carl Smith)
Newsgroups: comp.unix.aux
Subject: Re: Mac II Ethernet Boards (really:  A/UX NFS misconceptions)
Message-ID: <926@unisoft.UUCP>
Date: 27 Apr 88 21:22:42 GMT
References: <20445@pyramid.pyramid.com> <4476@hoptoad.uucp>
Lines: 72

--------
	A recent article from John Gilmore contained:

> There are a few bugs remaining in A/UX NFS, but nothing serious.  Try a
> "df -i" from a Sun that has mounted a Mac's disk; you get gibberish.
> Also, doing "ls -s" produces numbers that were shifted the wrong way to
> convert their units; on A/UX, "ls -s" output is in 512 byte blocks.  On
> BSD, all such output is in Kbytes.  Doing "ls -ls" from my Sun to the
> Mac's root directory produces entries like:

>  156 -rw-r--r--  1 bin        317633 Dec 18 18:09 newunix

> where the size seems to be in "2K" units.  "du" has the same problem,
> which seems to be in the implementation of "stat" in the A/UX NFS server.
> -- 
> John Gilmore  {sun,pacbell,uunet,pyramid,ihnp4}!hoptoad!gnu      gnu@toad.com

	There's a lot of confusion here.  A/UX is doing ``the right thing.''
If you want an explanation, read on.
	The ``df -i'' problem is one Sun introduced.  The current NFS protocol
specification (version 2) does not allow a method of passing information about
the number of free and used files across the wire.  We see garbage whether the
server is an A/UX machine, a Sun, or a VAX.
	As for the ``ls -s'' problem, this is caused by either a bug in the
BSD ls program, or in the BSD kernel (whichever you choose to blame).  Quoting
from the NFS protocol specification description of the fattr (file attribute)
structure:

	blocksize is the size in bytes of a block of the file; ...; blocks is
	the number of blocks the file takes up on disk

It seems clear that the intent here is for server implementations to specify
both the native block size and the number of such blocks.  If one were to
write a program that printed out stat structure entries, the result (again
for ``newunix'') would be:


	st_dev:		0xffffff1d
	st_ino:		5430
	st_mode:	0100644
	st_nlink:	1
	st_uid:		3
	st_gid:		3
	st_size:	401186
	st_atime:	Tue Mar 29 00:42:36 1988	(575628156)
	st_mtime:	Thu Sep 17 23:31:52 1987	(558945112)
	st_ctime:	Thu Sep 17 23:31:52 1987	(558945112)
	st_blksize:	1024
	st_blocks:	392

Notice that the file size closely matches the product of the st_blksize and
st_blocks fields.  Unfortunately, the BSD ls program assumes that the units
used in the st_blocks field is 512 bytes.  In it you'll find code that looks
like

		<stat file, stb == stat buffer>
		fp->fblks = stb.st_blocks;

to get the number of blocks in the file, and

	(void) sprintf(sizebuf, "%4ld ", kbytes(dbtob(p->fblks)));

to print it.  Dbtob() converts from DEV_BSIZE (512-byte) blocks to bytes;
kbytes() converts to 1024-byte blocks.  Nowhere does ls take advantage of
the st_blksize field.
	One might argue that the st_blksize field is to be used strictly as
a hint at the optimal transfer size.  If that is the case, it is the kernel,
not ls that should be fixed.  Someone must be responsible for converting from
the interpretations in the NFS fattr structure into native data structures
rather than simply copying the values.

			Carl