Richard Gooch <rgooch@ras.ucalgary.ca>:
> >
> OK, provided the prefetch will queue up a large number of requests
> before starting the I/O. If there was a way of controlling when the
> I/O actually starts (say by having a START flag), that would be ideal,
> I think.
>
The START flag is equivalent to the first actual read, whereupon the
elevator code will do the Right Thing.
> That opens up a nasty race: if the dentry is released before the
> pointer is harvested, you get a bogus pointer.
>
You simply increase the reference count of every dentry you visit, and
free it when the log is read.
> How's that? It won't matter if read(2) synchronises, because I'll be
> issuing the requests in device bnum order.
>
Of course it does, because the kernel needs to wait for the next read()
system call from your application, which it can only do after the first
one completes, which adds another delay which will slow you down,
especially with high-latency I/O protocols.
-- Matthias Urlichs | noris network AG | http://smurf.noris.de/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Tue May 15 2001 - 21:00:34 EST