> You havn't said what types of disks. I've had IDE disks fail that > take down the entire system. I've had IDE disks fail but the system > remains up and happy. I've had SCSI disks fail that have made the > SCSI cards *very* unhappy (and had the system die shortly after). > None of these things can be solved by RAIDframe -- if the underlying > device drivers can't "deal" in the face of lossage, RAIDframe can't > do anything about that...
The system is a SuperServer 5013C-T, with two hot swappable sata drives. > You also havn't given any indication as to the nature of the crash, > or what the panic message was (if any). (e.g. was it a null-pointer > dereference, or a corrupted filesystem or something that went wrong > in the network stack?) I came in the morning, I got no response from the system. I eventually had to hit the init button. I did not lose a lot of work, only an hour or two. The old web server worked, creating a new on was not high priority. > I've never seen that behaviour... I find it hard to believe that > you'd be able to queue up 2 days worth of writes without a) any reads > being done or b) not noticing that the filesystem was completely > unresponsive when a write of associated meta-data never returned... > (on the first write of meta-data that didn't return, pretty much all > IO to that filesystem should grind to a halt. Sorry.. I'm not buying > the "it queued up things for two days"... ) The system was almost completely idle. The only changes I made was editing a few small files (httpd.conf and friends) I doubt sure that there was less then a megabyte of changes I made. I also assumed that the write went to the one operating disk and a failed failure recovery caused the problem.
