km@emory.uucp (Ken Mandelberg) (04/22/88)
The latest MacWeek says that the Apple MacII ethernet boards
are being recalled, and plans for shipments of new boards are
indefinite.
This seems to put a pretty big crimp in plans to use NFS
under AUX.
--
Ken Mandelberg | {decvax,sun!sunatl,gatech}!emory!km UUCP
Emory University | km@emory BITNET
Dept of Math and CS | km@emory.ARPA ARPA,CSNET
Atlanta, GA 30322 | Phone: (404) 727-7963sas@pyrps5 (Scott Schoenthal) (04/22/88)
In article <2865@emory.uucp> km@emory.uucp (Ken Mandelberg) writes: >The latest MacWeek says that the Apple MacII ethernet boards >are being recalled, and plans for shipments of new boards are >indefinite. Does anyone know of a reason for this? >This seems to put a pretty big crimp in plans to use NFS >under AUX. Although somewhat slow and modulo a protocol bug which was fixed, Apple's NFS under A/UX did seem to work at the Sun Connectathon in January. sas ---- Scott Schoenthal sas@pyrps5.pyramid.com Pyramid Technology Corp.
honey@umix.cc.umich.edu (Peter Honeyman) (04/24/88)
that might explain some mysterious crashes we've been having on ethernet of late. it's only when we bang on it, like two minutes of beat-the-shit-out-of-macnfs testing. on the other hand, the kinetics card never fails. peter
gnu@hoptoad.uucp (John Gilmore) (04/24/88)
> Does anyone know of a reason for this? [Mac-II ether board recall] The boards/drivers (not sure which) drop packets that are sent close together, e.g. 6 packets containing 8K of NFS data; that might be a good reason to recall them. We own a Mac-II Ethernet board though, and haven't received any recall notice. > Although somewhat slow and modulo a protocol bug which was fixed, Apple's > NFS under A/UX did seem to work at the Sun Connectathon in January. 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 /* No comment */
carl@unisoft.UUCP (Carl Smith) (04/28/88)
-------- 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