Committed.
-sam
On Mar 21, 2007, at 8:39 AM, Phil Carns wrote:
Hi Sam,
That seems reasonable to me...
-Phil
Sam Lang wrote:
Hi Phil,
In the special remove case, could we make the error checking even
tighter? Something like:
if(resp_p->status == -PVFS_ENOENT && index == 1)
return 0;
Hi Sam,
That seems reasonable to me...
-Phil
Sam Lang wrote:
Hi Phil,
In the special remove case, could we make the error checking even
tighter? Something like:
if(resp_p->status == -PVFS_ENOENT && index == 1)
return 0;
if(resp_p->status != 0)
return resp_p->status;
Other than
Hi Phil,
In the special remove case, could we make the error checking even
tighter? Something like:
if(resp_p->status == -PVFS_ENOENT && index == 1)
return 0;
if(resp_p->status != 0)
return resp_p->status;
Other than that this patch looks good.
-sam
On Mar 20, 2007, at 9:
I have attached a patch that implements the proposed bug fixes. With
this applies, the encoder does not bother to encode or decode any
trailing data for error responses. We haven't seen any ill effects,
although a minor adjustment was needed to the sys-rename.sm state
machine which modifying
I have done some more work on this, but unfortunately I don't have a
patch that I can share yet (it might be faster for you guys to just make
the change if you want it; I can point out one little gotcha that I
found in sys-rename.sm but the rest is simple).
As far as I can tell after a good bi
Did we reach any sort of consensus on this idea?
Rob
Phil Carns wrote:
We've run into a couple of scenarios lately where a broken metadata file
can cause the server to crash. The latest one looks like this:
--
- a metadata file exists, but the db entry for its datafile handle
On Thu, Oct 19, 2006 at 05:57:02PM -0500, Sam Lang wrote:
> This means if a bunch of jobs all do a create of the same
> file (stupid sure, but possible), all the ones that got EEXISTS back
> have to do a lookup. We could potentially optimize this by sticking
> the handle into the error respo
It doesn't actually exist right now, but the counter example I can
come up with has to do with file open, where the O_CREAT flag is set
but O_EXCL is not. If a parallel job tries to create a file (call
PVFS_sys_create), and it already exists, it gets back an EEXISTS
error, and then has t
Sounds like formalizing this would be a good idea. Is there even one
counter-example that we can think of or that exists today?
Rob
Pete Wyckoff wrote:
[EMAIL PROTECTED] wrote on Thu, 19 Oct 2006 16:34 +0200:
We've plugged some similar bugs before by just fixing the specific case
(being more
[EMAIL PROTECTED] wrote on Thu, 19 Oct 2006 16:34 +0200:
> We've plugged some similar bugs before by just fixing the specific case
> (being more careful about cleaning up masks, pointers, sizes, etc. after
> an error), and the same could easily be done here. Should there be a
> more general sol
We've run into a couple of scenarios lately where a broken metadata file
can cause the server to crash. The latest one looks like this:
--
- a metadata file exists, but the db entry for its datafile handles (the
"dh" key is missing for some reason
- a client requests a getatt
11 matches
Mail list logo
