From owner-freebsd-fs Wed Oct 2 10:25:12 1996 Return-Path: owner-fs Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id KAA22479 for fs-outgoing; Wed, 2 Oct 1996 10:25:12 -0700 (PDT) Received: from minnow.render.com (render.demon.co.uk [158.152.30.118]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id KAA22455; Wed, 2 Oct 1996 10:24:33 -0700 (PDT) Received: from minnow.render.com (minnow.render.com [193.195.178.1]) by minnow.render.com (8.6.12/8.6.9) with SMTP id SAA23478; Wed, 2 Oct 1996 18:21:14 +0100 Date: Wed, 2 Oct 1996 18:21:13 +0100 (BST) From: Doug Rabson To: dyson@freebsd.org cc: Poul-Henning Kamp , heo@cslsun10.sogang.ac.kr, freebsd-hackers@freebsd.org, freebsd-fs@freebsd.org Subject: Re: vnode and cluster read-ahead In-Reply-To: <199610021520.KAA01060@dyson.iquest.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-fs@freebsd.org X-Loop: FreeBSD.org Precedence: bulk On Wed, 2 Oct 1996, John Dyson wrote: > > > > 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. 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 :-). -- Doug Rabson, Microsoft RenderMorphics Ltd. Mail: dfr@render.com Phone: +44 171 734 3761 FAX: +44 171 734 6426