[fl]seek mechanism

[Jeff Berkowitz]

In reference to the question about lseek (..., L_SET), Chris Torek writes:
>
>This question is basically meaningless, because the kernel
>code for lseek---minus error checks, and with names expanded---is:
>
>	switch (whence) {
>	case 0: fp->f_offset = offset; break;
>	case 1: fp->f_offset += offset; break;
>	case 2: fp->f_offset = fp->f_inode->i_file_size - offset; break;
>	}
>	return;

This is true for 4.3BSD, but slightly misleading for systems that include
NFS.  The difference is only in the L_XTND code ("case 2:" in the example).
The reference to the file size - "fp->f_inode->i_file_size" - requires a
VOP_GETATTR() call into the underlying virtual file system code on systems
which include NFS.

If the underlying file type is ufs (local disk), the VOP_GETATTR call
will be reasonably inexpensive (although it will cost a bit more than
the two pointer references in the example).

If the underlying file is being served from another machine, though, the
VOP_GETATTR() call may require an RPC to the file server.  This will cost
much more than L_SET or L_INCR.  (Caching by the NFS implementation may
eliminate some of the RPC calls, but can't eliminate all of them).
-- 
Jeff Berkowitz N6QOM			uunet!sequent!jjb
Sequent Computer Systems		Custom Systems Group