>Ahh, the md driver does indeed do something like this. The md driver
>will clear the lock bit without ever waking up anybody that waits on it,
>as far as I can tell.
>I will consider this an md bug until you tell me that you aren't
>actually using raid at all, at which point I'll go back to scratching my
>head.
Ok, we might be on to something here.
I *do* use md, quite heavily, I suppose.
Filesystem 1024-blocks Used Available Capacity Mounted on
/dev/sda1 32171 10719 19791 35% /
/dev/md0 193041 14 183058 0% /tmp
/dev/sda5 382384 99769 262867 28% /usr
/dev/sda6 382384 109895 252741 30% /var
/dev/sda7 3218871 1134096 2052011 36% /var/lib/news
/dev/md1 7789735 3323872 4383882 43% /news
/dev/md0 raid0,4k,0,d143a62f /dev/sda2 /dev/sdb1 /dev/sdc1
/dev/md1 raid0,1024k,0,64861e07 /dev/sdb3 /dev/sdc3
Three disks, 4GB each. Using md across all three on md0 and md1 on
two of them.
I had programs like e2fsck and innd hanging, most likely on partition
/dev/md1 (2 disks).
The problem is, why, did a
dd if=/dev/sda of=/dev/null bs=256k
hang? I repeated this experiment, and while the first process
was *still* hanging, the second process managed to read *past* the
spot where the first process halted, *a lot* further into the
partition it hung as well. Once the block becomes unlocked, the
first process doesn't wake up anymore. The second process merrily
reads across this "once locked" buffer and meets his defeat later.
/dev/sda is shared in the /dev/md0 partition.
During the hang, there was negligible activity on /tmp (and therefore
/dev/md0) though. So it seems a bit odd that md even comes into play,
considering the fact that we are reading from /dev/sda directly.
--
Sincerely, srb@cuci.nl
Stephen R. van den Berg (AKA BuGless).
He did a quarter of the work in *half* the time!