[linux-cifs-client] Problems with bitkeeper source

[James Roper]

I'm not very familiar with bitkeeper.  I cloned the linux-2.5cifs 
repositry 2 days ago, I've since merged a 6 month old patch onto it that 
I made, I then committed it, found some problems, fixed them, and tried 
to commit again.  The problem is, I keep getting an error saying max 
pending logs exceeded, commit aborted.  I want to make some 
improvements, but before I do so, I want to pull the changesets down 
that have been made in the past few days.  Any ideas?

Anyway, I'm wondering what people thought about how to improve 
asynchronous read routines.  The two bottle necks at the moment are the 
fact that no more than 32 pages are ever requested at once, and the 
maximum cifs buffer size.  The cifs buffer size actually isn't too much 
of a problem, it means we have to do a bit more processing to prepare 
the requests to be received, and incurs more overhead on the network as 
there are more smb headers being transmitted per KB requested.  But the 
maximum readahead pages could seriously impede high latency to bandwidth 
ratio networks, because it means we can only read 128KB per round trip 
cycle.  So on a gigabit network, with a round trip time of 50 
milliseconds (there's a few router hops on the corporate intranet to the 
file server), we could only get a maximum theoretical download speed of 
2.2 MB/s, even though a gigabit network should be able to download at 
speeds closer to 100MB/s.  I think the best way forward is to experiment 
with increasing that readahead limit to, say 128 pages, ie 512KB.  Even 
better might be a proc entry to control it, that way different people 
can test it on different systems.  I could try and increase the cifs 
buffer size but maybe it's an idea to wait for the write behind 
increased buffer size to mature, then use that code or similar code.  
Any ideas?

James

-- 
James Roper
u3205097 at alumni.anu.edu.au
Phone: +61 2 9524 3380      Mobile: +61 438 406 331