I tried using a mounted file system on a single device. Same test, disable / wait / enable. There was no activity on the file system following the mount until after the enable. duck /root# ls /sdj1 5:0:13:0: rejecting I/O to dead device Buffer I/O error on device sdj1, logical block 516 Buffer I/O error on device sdj1, logical block 517 Buffer I/O error on device sdj1, logical block 518 Buffer I/O error on device sdj1, logical block 519 EXT3-fs error (device sdj1): ext3_readdir: directory #2 contains a hole at offset 0 Aborting journal on device sdj1. 5:0:13:0: rejecting I/O to dead device Buffer I/O error on device sdj1, logical block 0 lost page write due to I/O error on sdj1 ext3_abort called. EXT3-fs error (device sdj1): ext3_journal_start_sb: Detected aborted journal Remounting file system read-only It would be really nice if the file system wouldn't be rendered dead and require manual intervention following the scenario of kicking a cable and plugging it back in after the dev_loss_tmo expires. I think I'm leaning toward wishing that the kernel could do a better job of reconnecting devices following these little "accidents". Mike Michael Reed wrote: > > Michael Reed wrote: >> James Smart wrote: >>> The data that would be most interesting is a recursive listing of the >>> device via the /sys/devices tree. This would show the host, rports, >>> targets, and sdevs. Getting a copy of this both before, when missing, >>> and after they are reconnected. The additional contents to look at >>> is : contents of /sys/class/fc_remote_ports. >> I'll capture data and post later today. >> > > Attached. ls_no_md.tar.bz2 and ls_with_md.tar.bz2 > > I noticed that more than just the devices associated with the > md were reassigned in the ls_with_md.tar output. > > Mike - : send the line "unsubscribe linux-scsi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
