I had problems with this OST a few weeks ago. It's journal became slow and eventually we experienced an OST failure and file corruption. <div>I've since taken the entire FS offline and e2fsck'd every OST and the MDT. I found a few bad inode count errors but nothing really serious looking like when we lost data.</div>
<div><br></div><div>Now the same OST is acting up again. I'm seeing CPU soft lockups and messages like this in the lustre debug logs.:</div><div>=========</div><div><div>00010000:00000400:5:1264089753.654698:0:11495:0:(ldlm_lib.c:541:target_handle_reconnect()) scratch-OST000e: 31dd4e5b-99c7-677d-5301-e1ba53c1e56b reconnecting</div>
<div>00010000:00000400:5:1264089753.654708:0:11495:0:(ldlm_lib.c:835:target_handle_connect()) scratch-OST000e: refuse reconnection from <a href="mailto:31dd4e5b-99c7-677d-5301-e1ba53c1e56b@10.2.1.121">31dd4e5b-99c7-677d-5301-e1ba53c1e56b@10.2.1.121</a>@o2ib2 to 0</div>
<div>xffff810304230c00; still busy with 4 active RPCs</div><div>00010000:00020000:5:1264089753.654715:0:11495:0:(ldlm_lib.c:1863:target_send_reply_msg()) @@@ processing error (-16)  req@ffff810229675c00 x1324238487685594/t0 o8->31dd4e5b-99c7-677d-5301-e</div>
<div>1ba53c1e56b@NET_0x500020a020179_UUID:0/0 lens 368/264 e 0 to 0 dl 1264089853 ref 1 fl Interpret:/0/0 rc -16/0</div><div>=========</div><div><br></div><div>=========</div><div>[root@oss-0-0 ~]# dumpe2fs -h /dev/dsk/ost24 | grep state</div>
<div><div>dumpe2fs 1.41.6.sun1 (30-May-2009)</div><div>Filesystem state:         clean</div><div>=========</div><div><br></div><div>=========</div><div><div>[root@oss-0-0 ~]# e2fsck -n /dev/dsk/ost24  | tee /state/partition1/e2fsck-n_ost24_`date '+%m.%d.%y-%H:%M:%S'`.log</div>
<div>e2fsck 1.41.6.sun1 (30-May-2009)</div><div>device /dev/sdy mounted by lustre per /proc/fs/lustre/obdfilter/scratch-OST000e/mntdev</div><div>Warning!  /dev/dsk/ost24 is mounted.</div><div>Warning: skipping journal recovery because doing a read-only filesystem check.</div>
<div>scratch-OSTffff: clean, 3219531/183009280 files, 60844652/732023488 blocks</div><div>=========</div><div><br></div><div>I ran that again and it produced a ton of errors. Could it be because the OST is active? (Log attached)</div>
<div><br></div><div>Then I ran it again and it e2fsck reported that the OST was clean.</div><div><br></div><div>Another odd note: tune2fs is reporting the wrong lustre UUID for the OST. It should be scratch-OST000e</div><div>
<br></div><div>=========</div><div><div><div>[root@oss-0-0 ~]# tunefs.lustre --dryrun /dev/dsk/ost24 | grep Target | uniq</div><div>Target:     scratch-OST000e</div></div><div>=========</div><div><br></div><div>I don't see any errors on the storage systems.</div>
<div><br></div><div>Any ideas?</div><div>Thanks</div><div>Erik Froese</div></div></div></div></div>