Order of kernel autodetect

is supposed to work. It must happen very early, obviously, to ensure that auto-fsck works correctly. I'm guessing that it should be first, or close to first in the scripts. The general idea would be simply to run mdadm from a script to start the arrays, then? Thanks TJ - To unsubscribe from this list

via82xx driver: reporting dxs_support experience

on some of the troubles with this driver. I can provide more information if anyone wants it. Please CC me, I'm not on the list. TJ Motherboard: MSI K7T266 Pro2 lspci -nv: 00:00.0 Class 0600: 1106:3099 Subsystem: 1106: Flags: bus master, medium devsel, latency 0

Re: via82xx driver: reporting dxs_support experience

Mispost. This was destined for linux-kernel. Please delete if possible. Thanks. TJ - To unsubscribe from this list: send the line unsubscribe linux-raid in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html

Hard disk wierdness in raid array

also ran the drive that was slaved to it with another drive and that drive never caused any trouble. Thanks for any input, and feel free to ask for more info, or suggest testing, TJ Harrell - To unsubscribe from this list: send the line unsubscribe linux-raid in the body of a message to [EMAIL

Re: Raid-5 long write wait while reading

Bill Davidsen wrote: tj wrote: Thomas Jager wrote: Hi list. I run a file server on MD raid-5. If a client reads one big file and at the same time another client tries to write a file, the thread writing just sits in uninterruptible sleep until the reader has finished. Only very small

2 failed disks RAID 5 behavior bug?

5 array when more than one element is failed. PS: Please CC: me. :) Thank You! TJ Harrell [EMAIL PROTECTED] - To unsubscribe from this list: send the line unsubscribe linux-raid in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html