You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Chrisitan, Pavel, Sam and I spent 1.5hours yesterday to diagnose a tricky and somewhat
illusive issue with
the VOspace mount. We are using it to have our codes access the data on the VOspace
and read it in to
post-process. Everything worked fine until we hit a particular file (the 15th in a series of
approximately 25).
Initially we thought the file was corrupt. When testing, we were not able to do h5ls or cp
("Bad address") the
file from the linux server in our department. Sam had the same behaviour for this file on his
Mac laptop, however,
I was able to do h5ls on my Mac laptop (both through our respective CADC mounts). We
remounted on the linux
server once after deleting the cache which did not help immediately. Eventually after a lot of
testing and checking
we did another remount and then were able to copy the file in question, do h5ls and h5diff
(to a backup copy on our
system) and finally proceed with the post-processing of the file. At that time Sam was able
to see the file correctly
again, without changing his mount.
Admittedly this problem is maybe difficult to diagnose because I am not sure we can
reproduce the problem.
But we have alerted others and we will keep an eye on this and report additional instances
of this problem.
The text was updated successfully, but these errors were encountered:
The problem was in error catching. Bad Address basically means there is an uncaught exception. This was a server exception that was not been caught. The new cadc-utils library should remove this problem.
Chrisitan, Pavel, Sam and I spent 1.5hours yesterday to diagnose a tricky and somewhat
illusive issue with
the VOspace mount. We are using it to have our codes access the data on the VOspace
and read it in to
post-process. Everything worked fine until we hit a particular file (the 15th in a series of
approximately 25).
Initially we thought the file was corrupt. When testing, we were not able to do h5ls or cp
("Bad address") the
file from the linux server in our department. Sam had the same behaviour for this file on his
Mac laptop, however,
I was able to do h5ls on my Mac laptop (both through our respective CADC mounts). We
remounted on the linux
server once after deleting the cache which did not help immediately. Eventually after a lot of
testing and checking
we did another remount and then were able to copy the file in question, do h5ls and h5diff
(to a backup copy on our
system) and finally proceed with the post-processing of the file. At that time Sam was able
to see the file correctly
again, without changing his mount.
Admittedly this problem is maybe difficult to diagnose because I am not sure we can
reproduce the problem.
But we have alerted others and we will keep an eye on this and report additional instances
of this problem.
The text was updated successfully, but these errors were encountered: