>
Hi Dan
> Well, that's a nice message! Not often do you see something so straight
> forward. I'll try the PCI bridge support.
I am systemadministrator and we will introduce linux to serve small Oracle8
applications. After running three weeks on errors (six weeks ago all was ok for three
weeks then disaster started) I
get kind of nervous...
> As to the filesystem corruption, can you tell if the duplicated blocks are on
> a single disk or striped across disk boundaries or on different disks completely?
They remain on one stripe. I can reproduce them and they always appear at the same
inode (2052). Checking the stripe before writing gives nothing out. Writing the first
time on it (creating
database files) - ok. Writing importing data into tablespaces after that - ok. Writing
index files - crash. Testing the same on the other stripe infects anything.
> I have seen (under 2.0.36) a condition that I can't explain, but someone has
>suggested that it may be due to both CPU's trying to scan the SCSI bus at the same
>time, thus resulting in continual
> bus resets. I'm no expert, but maybe something similar is happening - I warn you
>that I may be completely wrong.
No, you aren't wrong. I had timeouts on the scsi bus but fixed that with something
(something I don't remember...). The timeouts didn't remain since I have changed two
disks.
But the filesystem corruption still remains with one cpu. Today we set up the
benchmark test again, we were running three weeks ago and the bastard... oops, sorry,
the machine... works correct
for hours! Anything happened except that it imports the data with high speed using two
cpus again.
Sometimes I think I don't know even anything... very mysterious behaviour, because
probability of not writing to the inode 2052 with the benchmark files is very, very,
very, small.
Sorry for the long message, Dietmar
-
Linux SMP list: FIRST see FAQ at http://www.irisa.fr/prive/mentre/smp-faq/
To Unsubscribe: send "unsubscribe linux-smp" to [EMAIL PROTECTED]
