[Lustre-devel] proposal on implementing a new readahead in clio

Alexey Lyashkov alexey.lyashkov at clusterstor.com
Sun Jan 24 01:18:46 PST 2010

On Sun, 2010-01-24 at 09:01 +0800, jay wrote:
> Alexey Lyashkov wrote:
> > We have an idea to spawn a per file readahead thread for each process,
> > and this thread can be used to issue the readahead RPC async.
> >   
> > I correctly understand: you suggest a spawn one new thread per open
> > file?
> > so if client have 10 processes, and each process is open 100 files, you
> > need spawn 1000 new threads?
> >   
> No, per process readahead, or some system readahead thread pool, this is 
> because most of those threads are sleeping, and it consumes little time 
> to issue readahead requests. The idea behind the scheme is to issue 
> readahead rpcs async.
first case is same as i say (i think) - 10 processes reading from own
files, so will be spawn 1000 new threads.
in second case you will be lost readahead requests on hardloaded client.

> BTW, I'm not going to implement what you mentioned in linux, because I 
> don't think this is a good idea, as what I said in design doc. However, 
> we HAVE to have an async thread pool to implement readahead for windows. 
> Windows doesn't have an interface of issuing async read request, lack of 
> a mechanism to have page lock or similar things - what a pity!
hm.. looks i don't understand problem. Currently linux client is using
->readpage() to generate OST_READ RPC and sending via ptlrpcd-io.
Why isn't generate this RPC directly for Windows? Or you mean about
update asynchronous update VM cache ?

Alexey Lyashkov <alexey.lyashkov at clusterstor.com>

More information about the lustre-devel mailing list