From owner-freebsd-fs  Wed Oct  2 08:21:05 1996
Return-Path: owner-fs
Received: (from root@localhost)
          by freefall.freebsd.org (8.7.5/8.7.3) id IAA14913
          for fs-outgoing; Wed, 2 Oct 1996 08:21:05 -0700 (PDT)
Received: from dyson.iquest.net (dyson.iquest.net [198.70.144.127])
          by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id IAA14904;
          Wed, 2 Oct 1996 08:21:00 -0700 (PDT)
Received: (from root@localhost) by dyson.iquest.net (8.7.5/8.6.9) id KAA01060; Wed, 2 Oct 1996 10:20:48 -0500 (EST)
From: John Dyson <dyson@dyson.iquest.net>
Message-Id: <199610021520.KAA01060@dyson.iquest.net>
Subject: Re: vnode and cluster read-ahead
To: phk@critter.tfs.com (Poul-Henning Kamp)
Date: Wed, 2 Oct 1996 10:20:48 -0500 (EST)
Cc: dyson@freebsd.org, heo@cslsun10.sogang.ac.kr, freebsd-hackers@freebsd.org,
        freebsd-fs@freebsd.org
In-Reply-To: <3531.844268244@critter.tfs.com> from "Poul-Henning Kamp" at Oct 2, 96 04:57:24 pm
Reply-To: dyson@freebsd.org
X-Mailer: ELM [version 2.4 PL24 ME8]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: owner-fs@freebsd.org
X-Loop: FreeBSD.org
Precedence: bulk

> 
> In message <199610021439.JAA00980@dyson.iquest.net>, John Dyson writes:
> 
> >> As a process A reads a file F *sequentially* the fields(v_maxra, v_ralen, et
> >c) of the vnode of F increases. As a result read-ahead of next cluster happens
> >.
> >> But when a process B opens F and reads it the values of the fields are 
> >> changed. So the process A's read-ahead is disturbed whenever process B is 
> >> rescheduled.
> >> 
> >> I think the fields for read-ahead must be in struct file rather than vnode.
> >> There exists one vnode for a file but a file may be open serveral times. 
> >> 
> >That is closer to correct.  I am not sure that the struct file is correct
> >either, but I think that you are on the right track.
> 
> No, I don't agree.  Process B will most likely find all it needs in the
                                          ^^^^^^
> buffercache, and thus will not need read-ahead at all.
> 

I agree with the term "likely", but it is possible that two processes
are not reading the entire file sequentially.  Also, it is possible that
the file size is much bigger than main memory, thereby busting the cache.
Read-ahead is then the only performance improvement to be had.  Nowadays,
I think that drives actually have segmented read-ahead caches also.  We
don't though.

John