>>> I don't know yet what is causing the lock-up. A quick look at your logs >>> suggest that it could be related to the barrier handling. Maybe trying to >>> handle a barrier during a reshape is prone to races of some sort - I wouldn't >>> be very surprised by that. >> >> Just note that during the second lockup no reshape or resync was going >> on. The array state was stable, I was just writing to it. >> >>> >>> I'll have a look at the code and see what I can find. >> >> Thanks a lot. If it was only a risk when I was growing/reshaping the >> array, and covered by the backup file, it would just be an >> inconvenience. But since it can seemingly happen at any time it's a >> problem. >> > > The lockup just happened again. I wasn't doing any > growing/reshaping/anything like that. Just copying some data into the > partition that lives on md0. dmesg_3.txt has been uploaded alongside > the other files at http://www.hartmanipulation.com/raid/. The trace > looks pretty similar to me. > The lockup just happened for the fourth time, less than an hour after I rebooted to clear the previous lockup from last night. All I did was boot the system, start the RAID, and start copying some files onto it. The problem seems to be getting worse - up until now I got at least a full day of fairly heavy usage out of the system before it happened. dmesg_4.txt has been uploaded alongside the other files. Let me know if there's any other system information that would be useful. Mike -- To unsubscribe from this list: send the line "unsubscribe linux-raid" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
