On Mon, Jan 17, 2005 at 07:35:01PM +0100, Matthias Drochner wrote:
> while we are here: While I had the bounds check at the beginning
> of genfs_getpages instrumented to track down the prefetch thing,
> I noticed that the read-ahead code frequently issues reads behind
> EOF. This causes a pointless recursion through the fs back to
> genfs_getpages which should be avoided.
> As I see it there is no check whether
> raoffset = startoffset + totalbytes
> is not already at/past EOF from the beginning, nor whether
> raoffset + N*rasize
> hits EOF eventually.
> 
> I've tried the appended patch successfully. It would certainly
> make sense to clip the ra requests instead if skipping.
> Where does the magic "16" come from?


the read-ahead code in genfs_getpages is hopelessly primitive
and should really be redesigned instead of just being tweaked forever.
I didn't spend much time on it back when I wrote it, and it really shows.

the idea was that we make up to two recursive calls to VOP_GETPAGES(),
resulting in two 64k disk i/o requests if the file is contiguous.
the magic 16 limit was because 16 4k pages == 64k bytes, and we didn't
have any ports that used a smaller page size than that.

the change you propose is fine, as far as it goes.

-Chuck