richard@aiai.ed.ac.uk (Richard Tobin) (07/17/90)
I'm writing an NFS server (so that I can mount Minix disks on a Sparcstation) and I've got a few naive questions: (1) What is the meaning of the "count" argument to readdir? Is it the total size of the filenames, entry structures and readdirres structure? I can't find an interpretation that is consistent with what the Sun NFS server returns. (2) The blocksize component of a fattr is described as "the size in bytes of a block of the file". However, du(1) seems to assume the blocksize is 512 bytes regardless. The blocksize I give shows up as the st_blksize returned by stat(2), which is described as the "optimal blocksize for file system i/o ops". Which is right? (3) What is meant to happen if the read returns fewer than "count" bytes? The client kernel doesn't seem to ask for more. Is this right? Thanks, Richard -- Richard Tobin, JANET: R.Tobin@uk.ac.ed AI Applications Institute, ARPA: R.Tobin%uk.ac.ed@nsfnet-relay.ac.uk Edinburgh University. UUCP: ...!ukc!ed.ac.uk!R.Tobin
guy@auspex.auspex.com (Guy Harris) (07/19/90)
>(1) What is the meaning of the "count" argument to readdir? Is it the >total size of the filenames, entry structures and readdirres >structure? I can't find an interpretation that is consistent with >what the Sun NFS server returns. This is a bit of a messy issue, since the client and server don't necessarily think a directory entry takes up the same number of bytes (or bits, or whatever). The SunOS client code (or, at least, the NFSSRC 4.0 client code) sends over the size of the buffer into which the directory entries sent over from the server are to be XDR'ed. Unfortunately, the server has no idea how the client is going to XDR things; the best it can do is guess. I think it's best thought of as a "do not exceed" amount, as in "don't send more than that many bytes of data over the wire". It doesn't include the return status of the request, but should include, for each entry returned: 1) the "there is a next entry" flag (the "xdr_bool" at the front of the entry); 2) the "file number" (inumber in UNIX, for example); 3) the file name; 4) the offset of the next entry. This basically assumes nothing gets bigger when it's XDR'ed on the client. I don't know that all servers are careful not to exceed that value. We are, as of our 1.1 release, but the NFSSRC 4.0 code isn't quite that careful; I think it can scribble on memory past the size of the buffer the server code allocates. This may be reflected in the behavior of some versions of the SunOS server.... You are, of course, permitted to return *fewer* than that many bytes. Beware, by the way, of being given a "readdir" where: 1) your interpretation of the cookie tells you to start reading in the middle of a directory entry; 2) a naive interpretation of the count would tell you to hand back part of a directory entry; or 3) the count isn't even big enough to hold *one* entry. >(2) The blocksize component of a fattr is described as "the size in bytes >of a block of the file". However, du(1) seems to assume the blocksize >is 512 bytes regardless. The blocksize I give shows up as the st_blksize >returned by stat(2), which is described as the "optimal blocksize for >file system i/o ops". Which is right? Another favorite source of confusion.... There are really (at least) two "block sizes" you can associate with a file. One - which an NFS server should return in the "blocksize" component of a "fattr" - is the size recommended for doing I/O operations on the file, i.e. the "optimal blocksize for file system i/o ops". The other is the units of the "blocks" component of an "fattr". It would be a Very Good Idea if every NFS server in the known universe treat this as 512 bytes if at all possible. If it's the sector size of your disk, wonderful, use those units - even if the allocation quantum of your file system is larger. If the allocation quantum is, say, 2 sectors, then return twice the number of allocation quanta used by the file. Even if it's *not* the sector size of your disk, try to use it anyway. If the sector size of your disk is 1024 bytes, return twice the number of sectors the file takes up. The two sizes are *completely unrelated*. >(3) What is meant to happen if the read returns fewer than "count" >bytes? The client kernel doesn't seem to ask for more. Is this right? It's acceptable, I guess. If you have a reasonably UNIXish file system, or one that can be made to look reasonably UNIXish (i.e., one where the file can be thought of as an array of bytes, even if the underlying OS's I/O abstractions don't work in those terms) you shouldn't return fewer than "count" bytes unless you hit the end of the file. Otherwise, you probably have to probably have some hard work to do in order to make your server acceptable to a UNIX client, especially given that said client is almost certainly *not* going to map single UNIX "read()" calls into single NFS read requests. I suspect you fall into the former category. :-)