Xref: utzoo comp.unix.questions:16122 comp.unix.wizards:17960 comp.databases:3497
Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!wuarchive!wugate!uunet!zephyr.ens.tek.com!tektronix!sequent!jjb
From: jjb@sequent.UUCP (Jeff Berkowitz)
Newsgroups: comp.unix.questions,comp.unix.wizards,comp.databases
Subject: Re: [fl]seek mechanism
Summary: L_XTND slower than L_SET, L_INCR on some systems
Keywords: file seeks on large files
Message-ID: <21186@sequent.UUCP>
Date: 3 Sep 89 01:53:46 GMT
References: <1631@unccvax.UUCP> <19382@mimsy.UUCP>
Reply-To: jjb@sequent.UUCP (Jeff Berkowitz)
Organization: Sequent Computer Systems, Inc
Lines: 29

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