Re: fc transport creates second set of targets for devices in an "md"

Michael Reed
2006-06-09T18:22:04Z

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