Quote:
|
Originally Posted by blue68f100
This is good info. Maybe we can get to the root of the problem and find a fix.
One thing I have read is that you DO NOT want to fail a drive in the middle of a rebuild. You can proably get away with it, if its the same drive. Copying files during a rebuild will really slow in down.
09/24/2006 22:42:01 35 D SYS | Memory allocation for i-node cache: 90% of free RAM This is good having that much free.
09/24/2006 22:42:02 35 D L01 | File System Check : Failed to allocate 174884354 bytes for rcd_lncntp!!!
This is proably the source for all the problem. Does not have enough ram (or some space) to alocate 175mb.
But you only have 128meg due to high density, Yes???
If 256m you should have 192 meg after the 64 meg for OS.
Looking at the log in detail. The def block size based on disk size is to large. The snap re-sizes the block size on the fly.
RAID5InitializeCache: allocated cache of 65526KB This is only 64M were is the other OS? I think there is a debug setting for this.
I see several places where it compairs files. The concludes the files are not there or not the correct size.
Now i'm wondering if we can reset the inode size to correct the problem. Or this was due to copying files during the rebuild????
|
You are thinking along the same lines as me here. Its either that or finding a way to get the unit to take more memory (this chipset should support 512MB, but only has one slot, which is the problem). I agree that changing a few of the default settings may help/correct. If so, then we would have a much faster and more reliable RAID array. If not correctable, we (meaning you software types) should be able to determine the exact cuttoff for the 4000 and drive size to prevent this. Maybe 300GB drives instead of 320's for example. But the real answer I think is on the track you are on here Dave.