I've attached two patches. The first tries to fix a basic bug where
the client-core doesn't cleanup if it receives SIGHUP unless --
standalone is provided. This means that event if the parent process
forwards the SIGHUP, the client-core process just exits (doesn't let
operations complete
Could you break down what the app is doing at a little bit higher level
in this time frame? (ie, how many writes is it posting, how many reads
is it posting, which are concurrent, when it calls wait for each).
From what I can tell, it looks like there are 30 total isys_io's
posted; the first
Looks good to me.
The only minor thing I see is that there are a couple of gossip_err()
calls in there that need to be updated so they don't use the "PVFS2
server:" prefix on the messages.
While you are messing with that stuff, would it be possible to add a
"starting" message to pvfs2-client
On Apr 15, 2008, at 3:55 PM, Phil Carns wrote:
Looks good to me.
The only minor thing I see is that there are a couple of
gossip_err() calls in there that need to be updated so they don't
use the "PVFS2 server:" prefix on the messages.
While you are messing with that stuff, would it be po
The app does a sequential write, using a maximum of NUMBUF (currently
16) buffers for async writes, posts them one at a time with
pvfs2_aio_flush, and then checks the buffer before re-using it with
pvfs2_aio_check.
Then it does 'rewindfile', and immediately starts the read.. So if the
file is
