Date: Wed, 2 Oct 1996 18:21:13 +0100 (BST) From: Doug Rabson <dfr@render.com> To: dyson@freebsd.org Cc: Poul-Henning Kamp <phk@critter.tfs.com>, heo@cslsun10.sogang.ac.kr, freebsd-hackers@freebsd.org, freebsd-fs@freebsd.org Subject: Re: vnode and cluster read-ahead Message-ID: <Pine.BSF.3.95.961002181522.10204N-100000@minnow.render.com> In-Reply-To: <199610021520.KAA01060@dyson.iquest.net>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.3.95.961002181522.10204N-100000>