Nicolas KOWALSKI wrote:
Les Mikesell <lesmikesell@xxxxxxxxx> writes:
'fsck -y' seems to fix it up, but it keeps happening. Is this likely
to be leftover cruft from the hardware issues or are there problems
in ext3/raid1/sata drivers? The way backuppc stores data with
millions of hardlinks in the archive it isn't really practical to
copy it off, reformat, and start over.
Maybe a memory problem:
http://thread.gmane.org/gmane.comp.file-systems.ext3.user/3457/focus=3459
Back to this problem again. I did a new mkfs.ext3 and ran more than a
week before hitting this again:
Mar 14 04:12:29 linbackup1 kernel: md3: rw=0, want=14439505280,
limit=1465143808
Mar 14 04:12:29 linbackup1 kernel: EXT3-fs error (device md3):
ext3_readdir: directory #34079247 contains a hole at offset 0
Mar 14 04:12:29 linbackup1 kernel: Aborting journal on device md3.
Mar 14 04:12:29 linbackup1 kernel: md3: rw=0, want=5260961472,
limit=1465143808
Mar 14 04:12:29 linbackup1 kernel: EXT3-fs error (device md3):
ext3_readdir: directory #34079247 contains a hole at offset 4096
I don't see any hardware related errors, and the rest of the filesystems
all seem fine, although this is the one that is busy.
Can this be related to being on a 3-member RAID1 that normally runs with
one device misssing? I've run a different one that way for a couple of
years on earlier kernels.
Will it hurt anything to mount the underlying partition of one of the
drives directly for a while instead of using the md device?
--
Les Mikesell
lesmikesell@xxxxxxxxx
_______________________________________________
CentOS mailing list
CentOS@xxxxxxxxxx
http://lists.centos.org/mailman/listinfo/centos
