> >>> If you can bear with slower operation, keeping issuing sync repeatedly > >>> (ie. something like while true; do sync; sleep 1; done) and see how > >>> the behavior changes might shed some light on what's going on too. > >> I wouldn't expect it to have any diagnostic value, really. The sync > >> command > >> locks up just like every other disk I/O when the event occurs. > > > > I tried this and it doesn't seem to have made a difference. Neither > does > > using noop as the scheduler. > > Hmm... yeah, I was mostly thinking about ext3 for this and the next > suggestion, which often has large latency when flushing its journal to > disk. I suppose the next stop is trying another filesystem? Well, I thought of that, of course. With over 6T of data, that means taking the array down (mostly) for more than 3 days. 'Not a propect I cherish, especially since it measn most of the data will then only exost on the backup system, and over a period of 3 days there are a lot of opportunities to lose the backup system , especially since it is JBOD. Indeed, the last time I re-formatted the RAID array, the backup system did fail. The motherboard shorted and took the power supply with it. Fortunately, I was able to recover the backup system and only lost a few files. -- To unsubscribe from this list: send the line "unsubscribe linux-ide" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
