Date: Wed, 2 Oct 1996 10:20:48 -0500 (EST) From: John Dyson <dyson@dyson.iquest.net> To: phk@critter.tfs.com (Poul-Henning Kamp) Cc: dyson@freebsd.org, heo@cslsun10.sogang.ac.kr, freebsd-hackers@freebsd.org, freebsd-fs@freebsd.org Subject: Re: vnode and cluster read-ahead Message-ID: <199610021520.KAA01060@dyson.iquest.net> In-Reply-To: <3531.844268244@critter.tfs.com> from "Poul-Henning Kamp" at Oct 2, 96 04:57:24 pm
next in thread | previous in thread | raw e-mail | index | archive | help
>
> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199610021520.KAA01060>