Nicolas KOWALSKI wrote: > Les Mikesell <lesmikesell at gmail.com> 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 at gmail.com