From owner-freebsd-hackers  Thu Oct  3 08:36:08 1996
Return-Path: owner-hackers
Received: (from root@localhost)
          by freefall.freebsd.org (8.7.5/8.7.3) id IAA03291
          for hackers-outgoing; Thu, 3 Oct 1996 08:36:08 -0700 (PDT)
Received: from ccs.sogang.ac.kr (ccs.sogang.ac.kr [163.239.1.1])
          by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id IAA03278;
          Thu, 3 Oct 1996 08:36:03 -0700 (PDT)
Received: from cslsun10.sogang.ac.kr by ccs.sogang.ac.kr (8.8.0/Sogang) id AAA04190; Fri, 4 Oct 1996 00:31:37 +0900 (KST)
Received: from localhost by cslsun10.sogang.ac.kr (4.1/SMI-4.1)
	id AA06595; Fri, 4 Oct 96 00:34:41 KST
Date: Fri, 4 Oct 1996 00:34:40 +0900 (KST)
From: Heo Sung-Gwan <heo@cslsun10.sogang.ac.kr>
X-Sender: heo@cslsun10
To: freebsd-hackers@FreeBSD.ORG
Cc: freebsd-fs@FreeBSD.ORG
Subject: Re: vnode and cluster read-ahead
Message-Id: <Pine.SUN.3.93.961004003010.6582A-100000@cslsun10>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-hackers@FreeBSD.ORG
X-Loop: FreeBSD.org
Precedence: bulk


John Dyson writes:
>> 
>> You could maintain a number of 'pending readahead' structures indexed by
>> vnode and block number.  Each call to cluster_read would check for a
>> pending readahead by hashing.  For efficiency, keep a pointer to the last
>> readahead structure used by cluster_read in the vnode in place of the
>> existing in-vnode readahead data.  Should be no slower than the current
>> system for single process reads and it saves 4 bytes per vnode :-).
> 
>Pretty cool idea.  I am remembering now that this deficiency in our read
>ahead code is well known.  This might be something really good for 2.3 or
>3.1 :-).  (Unless someone else wants to implement it -- hint hint :-)).
>

I suggest a new idea. The fields for read-ahead(maxra, lenra, etc) are
in file structure or other structure(e.g. Doug Rabson's readahead structure)
that is pointed by a new field in file structure. And vnode has a new field 
to contain the point to the file structure. This vnode field is filled every 
read system call with the point to the file structure at vn_read() 
in kern/vfs_vnops.c Then it is possible that the file structure is accessed
through vnode in cluster_read. 

Because the system calls are nonpreemptive the point to the file structure 
in the vnode is not changed until the current read system call is finished.  

This method removes the hashing using vnode and block number.

Is it really possible?

--
Heo Sung-Gwan
Dept. of Computer Science, Sogang University, Seoul, Korea.
E-mail: heo@cslsun10.sogang.ac.kr