Les Mikesell wrote:
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
Ross S. W. Walker wrote:
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:
directo
Nicolas KOWALSKI wrote:
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.
Well, I also found this one:
http://thread.gmane.org/gmane.linux.raid/6455/focus=6908
Is your ma
Les Mikesell <[EMAIL PROTECTED]> writes:
> 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.
Well, I also found this one:
http://thread.gmane.org/gmane.linux.raid/6455/focu
Les Mikesell wrote:
> Nicolas KOWALSKI wrote:
> > Les Mikesell <[EMAIL PROTECTED]> 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
Nicolas KOWALSKI wrote:
Les Mikesell <[EMAIL PROTECTED]> 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 ar
On Mon, 2008-02-25 at 18:11 -0600, Les Mikesell wrote:
> William L. Maltby wrote:
> >
> >>
> > If you use cpio, it can handle the hard links intelligently, IIRC. That
> > may make this more feasible. Plus you can specify such things as depth
> > to the find command feeding cpio so that even direc
Les Mikesell <[EMAIL PROTECTED]> 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 real
William L. Maltby wrote:
'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
On Mon, 2008-02-25 at 14:04 -0600, Les Mikesell wrote:
> I recently set up a new system to run backuppc on centOS 5 with the
> archive stored on a raid1 of 750 gig SATA drives created with 3 members
> with one specified as "missing". Once a week I add the 3rd partition,
> let it sync, then remo
I recently set up a new system to run backuppc on centOS 5 with the
archive stored on a raid1 of 750 gig SATA drives created with 3 members
with one specified as "missing". Once a week I add the 3rd partition,
let it sync, then remove it. I've had a similar system working for a
long time usin
11 matches
Mail list logo
