I've just observed another case of corruption similar to what I reported
a while back with .viminfo files getting corrupted (in that case, by
somehow being clobbered by a shared library fragment from what I could
tell).
This time, however, it was much more sinister, although probably the
same failure mode. I have just seen a file in a CVS repository resiting
on GlusterFS be replaced - by another file in the same directory in the
same CVS repository! One of my header files somehow got replaced by the
Makefile in the same directory. Reviewing "cvs log" indicates that the
entire file on the CVS side was clobbered by the Makefile - there is no
indication (e.g. from cvs log) that it was accidentally copied over and
committed in.
I'm sure I don't have to stress just how mind bogglingly dangerous (as
in data corruption/loss dangerous) this is.
Observed with 2.0.9, the volume is AFR.
Not sure if it is in any way relevant to this particular bug report, but
whenever I do cvs update on the glfs-backed repository, I get this sort
of thing in the glfs log:
[2010-01-15 18:05:11] E [posix.c:3156:do_xattrop] home-store: getxattr
failed on /cvs/Project/C/#cvs.lock while doing xattrop: No such file or
directory
Gordan
