I found that my stress test failed even in plain SCSI mode with just the
SEAGATE on the chain.
However, I *believe* it failed when I filled up the partition I was writing
to. Is there any reason that you know of that the ext2fs and/or the driver
code would fail when the partition filled up under heavy load?
This may have been my problem all along....
I am not sure though. I am going to slowly add new features over the next
few months, as I don't want to hurt a stable system. After I get good
uptime (a week or so) with a given set of features turned off, I will slowly
turn on feature by feature and see if the problem crops up.
This will take a while, and I will let you know if the problem hits again
and what parameter it happens on.
In the meantime, if you could let me know if there is some sort of
interaction the ext2fs and the driver when a partition fills up, that would
be great.
For more info on what I was doing, here's what my drives look like:
Filesystem 1024-blocks Used Available Capacity Mounted on
/dev/sda3 2029299 844477 1079914 44% /
/dev/sda1 49552 2446 44547 5% /boot
/dev/sda5 6358351 2598973 3694559 41% /home
I did a:
find / -ls
find / /boot -xdev -depth -print|cpio -oa > /tmp/foo.cpio
find /home -xdev -depth -print|cpio -oa > /home/foo.cpio
find / -ls
plus "normal" use on top of that, all at once.
I realized that / was very close to filling up at one point. Right around
that time, I got the crash.
Since the file /tmp/foo.cpio is gone from the fsck (it's inode has bad
blocks, and fsck removes it) I don't know /tmp/foo.cpio's actual size when
the crash happens, but I believe it had just filled up the partition.
Hopefully, this is the actual problem. I won't know until I begin to add
more features, and stress test again without filling the drive up. I need
to do that *slowly* over a period of weeks, as I need the system running to
work!
I hope this information is of help, and perhaps you will be able to
reproduce the problem!
(BTW, I was able to do with with kernel 2.2.2 and your latest symb driver)
--
Bradley M. Kuhn | bkuhn@ebb.org | http://www.ebb.org/bkuhn
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/