Thread (4 messages) flat view 4 messages, 2 authors, 2016-06-15

Re: checkout-index: unable to create file foo (File exists)

From: Pete Wyckoff <hidden>
Date: 2016-06-15 22:55:12

brian@interlinx.bc.ca wrote on Mon, 05 Nov 2012 10:25 -0500:
On 12-11-04 05:10 PM, Pete Wyckoff wrote:
quoted
Which network filesystem and OS are you using?
The filesystem is Lustre.  So not only is it networked, it is
distributed where the namespace and data store are handled by different
nodes, to it's not at all as atomic as NFS-on-(say-)ext4.  Given that,
it's entirely possible to imagine a scenario where a namespace (MDT in
the Lustre nomenclature) operation could get interrupted after the
namespace entry has been created but before the open(2) completes.  So
the question here is who's responsibility is it to handle that situation?
That's all in the filesystem.  Hopefully it doesn't really work
like that because the fs is incosistent at this point.

ERESTARTSYS handling is done entirely in the kernel, not in glibc
and not git.  A possible in-kernel fix is not to handle any
signals (except KILL) when waiting for the open mechanics to
finish.
quoted
The third option is
that there is a bug in the filesystem client.
Yep.  But before we can go on to determining a bug, the proper/expected
behavior needs to be determined.  I guess that's taking this a bit OT
for this list though.  I'm not really sure where else to go to determine
this though.  :-(
You could toss this to lustre support.  Or try first to come up
with a reduced testcase with lots of opens and SIGALRMs racing
against each other.  Maybe xfstests or some other suite might
also tickle the bug.

I don't think it is feasible to try to handle this error
condition in applications.

		-- Pete
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help