Hi,
What testing have these builds gone through? I was thinking about using
one of these to get around LU-274, but I was under the impression that
these weren't as thoroughly tested as the proper releases are.
This build system is fantastic, BTW.
Thanks,
Chris
On 6/1/11 4:53 PM, Cliff White
Hello,
We have a user who is trying to post-process HDF files in R. Her script
goes through a number (~2500) of files in a directory, opening and
reading the contents. This usually goes fine, but occasionally the
script dies with:
HDF5-DIAG: Error detected in HDF5 (1.9.4) thread
, Christopher Walker
cwal...@fas.harvard.edu wrote:
Hello,
We have a user who is trying to post-process HDF files in R. Her script
goes through a number (~2500) of files in a directory, opening and
reading the contents. This usually goes fine, but occasionally the
script dies with:
HDF5
the lfsck.c accordingly.
Then you can compile against 1.6.6.
在 2010-11-13，上午11:20， Christopher Walker 写道：
Thanks again for this patch. I just have one quick question about this
-- 1.41.12.2.ora1 seems to require lustre_user.h from 1.8.x -- is OK to
use a version of lfsck compiled against 1.8.x
out;
}
break;
在 2010-11-12，上午10:53， Christopher Walker 写道：
Thanks very much for your reply. I've tried remaking the mdsdb and all
of the ostdb's, but I still get the same error -- it checks the first 34
osts without a problem, but can't find the ostdb file
*/
+ost_idx = ost_hdr-ost_index;
+
strcpy(lfsck_uuid[ost_hdr-ost_index].uuid,ost_hdr-ost_uuid.uuid);
+ /* skip this round */
+ goto out;
}
break;
在 2010-11-12，上午10:53， Christopher Walker 写道：
Thanks very much for your
,
Chris
On 11/10/10 12:10 AM, Wang Yibin wrote:
The error message indicates that the UUID of OST #35 does not match between
the live filesystem and the ostdb file.
Is this ostdb obsolete?
在 2010-11-9，下午11:45， Christopher Walker 写道：
For reasons that I can't recall, our OSTs are not in consecutive
For reasons that I can't recall, our OSTs are not in consecutive order
-- we have 35 OSTs, which are numbered consecutively from
-0021
and then there's one last OST at
002a
When I try to run lfsck on this array, it works fine for the first 34
OSTs, but it can't seem to find the last OST
We recently had a hardware failure on one of our OSTs, which has caused
some major problems for our 1.6.6-based array.
We're now getting the error:
Serious error: objid 517386 already exists; is this filesystem corrupt?
on one of our OSTs. If I mount this OST as ldiskfs and look in O/0/d*,
While running e2fsck on some OSTs that went down with a system crash,
we're getting a bunch (~50) of messages like:
Inode 196837991 has a extra size (144) which is invalid
These don't get fixed with a e2fsck -fy -- any idea what this means and
how I can get rid of them?
Thanks very much,
Hello,
We're migrating our MDT/MGS and have hit a snag. I've tarred all files
on the MDT and moved them to the new MDT, untarred them, and set their
extended attributes. When I try to mount the MDT, however, I get the
following:
[EMAIL PROTECTED] ~]# mount -t lustre /dev/sdb1
Hello,
Occasionally when we put a client, typically a head node, under very
heavy load, it freezes all operations on the Lustre mount and requires a
hard reboot before the mount is usable again. The symptoms look similar
to the statahead problem observed by others, but I was under the
12 matches
Mail list logo
