# uname -a Linux FILEt1 2.6.34.7-0.7-desktop #1 SMP PREEMPT 2010-12-13 11:13:53 +0100 x86_64 x86_64 x86_64 GNU/Linux
# modinfo ocfs2 filename: /lib/modules/2.6.34.7-0.7-desktop/kernel/fs/ocfs2/ocfs2.ko license: GPL author: Oracle version: 1.5.0 description: OCFS2 1.5.0 srcversion: B13569B35F99D43FA80D129 depends: jbd2,ocfs2_stackglue,quota_tree,ocfs2_nodemanager vermagic: 2.6.34.7-0.7-desktop SMP preempt mod_unload modversions # mkfs.ocfs2 --version mkfs.ocfs2 1.4.3 On 12-08-24 5:44 PM, "Sunil Mushran" <sunil.mush...@gmail.com> wrote: > What is the version of the kernel, ocfs2 and ocfs2 tools? > > uname -a > modinfo ocfs2 > mkfs.ocfs2 --version > > On Fri, Aug 24, 2012 at 1:09 PM, Rory Kilkenny <rory.kilke...@ticoon.com> > wrote: >> We have an HP P2000 G3 Storage array, fiber connected. The storage array has >> a RAID5 array broken into 2 physical OCFS2 volumes (A & B). >> >> A & B are both mounted and formatted as NTFS. >> >> One of the volumes is NFS mounted. >> >> Every couple of months or so we start getting tons of errors on the NFS >> mounted volume: >> >> >>> Aug 24 09:48:13 FILEt2 kernel: [2234285.848940] >>> (ocfs2_wq,13844,7):ocfs2_block_check_validate:443 ERROR: CRC32 failed: >>> stored: 0, computed 1467126086. Applying ECC. >>> Aug 24 09:48:13 FILEt2 kernel: [2234285.849252] >>> (ocfs2_wq,13844,7):ocfs2_block_check_validate:457 ERROR: Fixed CRC32 failed: >>> stored: 0, computed 3828104806 >>> Aug 24 09:48:13 FILEt2 kernel: [2234285.849256] >>> (ocfs2_wq,13844,7):ocfs2_validate_extent_block:903 ERROR: Checksum failed >>> for extent block 1169089 >>> Aug 24 09:48:13 FILEt2 kernel: [2234285.849261] >>> (ocfs2_wq,13844,7):__ocfs2_find_path:1861 ERROR: status = -5 >>> Aug 24 09:48:13 FILEt2 kernel: [2234285.849264] >>> (ocfs2_wq,13844,7):ocfs2_find_leaf:1958 ERROR: status = -5 >>> Aug 24 09:48:13 FILEt2 kernel: [2234285.849267] >>> (ocfs2_wq,13844,7):ocfs2_find_new_last_ext_blk:6655 ERROR: status = -5 >>> Aug 24 09:48:13 FILEt2 kernel: [2234285.849270] >>> (ocfs2_wq,13844,7):ocfs2_do_truncate:6900 ERROR: status = -5 >>> Aug 24 09:48:13 FILEt2 kernel: [2234285.849274] >>> (ocfs2_wq,13844,7):ocfs2_commit_truncate:7556 ERROR: status = -5 >>> Aug 24 09:48:13 FILEt2 kernel: [2234285.849280] >>> (ocfs2_wq,13844,7):ocfs2_truncate_for_delete:593 ERROR: status = -5 >>> Aug 24 09:48:13 FILEt2 kernel: [2234285.849284] >>> (ocfs2_wq,13844,7):ocfs2_wipe_inode:769 ERROR: status = -5 >>> Aug 24 09:48:13 FILEt2 kernel: [2234285.849287] >>> (ocfs2_wq,13844,7):ocfs2_delete_inode:1067 ERROR: status = -5 >>> >> >> If we pull all the data off, destroy the volume, rebuilt it, and copy our >> data back, all works fine; for a while. >> >> This issue does not happen on the non NFS mounted volume. I am currently >> assuming the issue is with NFS and how we have it configured (which to the >> best of my knowledge is default). >> >> Has anyone had a similar experience and be able to share some insight and >> knowledge on any tricks with NFS and OCFS2 volumes? >> >> Thanks in advance. >> >> >> >> _______________________________________________ >> Ocfs2-users mailing list >> Ocfs2-users@oss.oracle.com >> https://oss.oracle.com/mailman/listinfo/ocfs2-users > >
_______________________________________________ Ocfs2-users mailing list Ocfs2-users@oss.oracle.com https://oss.oracle.com/mailman/listinfo/ocfs2-users
