B&fsn=3261 This changed the situation insofar as the NAS now reboots itself a few minutes after the connection errors happen, but else the situation is still the same.
After this happened for maybe 4-5 times, I found this forum thread and upgraded the firmware to 4.1.0 referenced at. The RAID resync automatically started over again at the beginning. After the reboot, the NAS complained that its file system was not clean and was in need to be checked. The kernel log of the NAS (iSCSI target) showed messages similar to: ABORT_TASK: Found referenced iSCSI task_tag: 1560281104 ABORT_TASK: Sending TMR_FUNCTION_COMPLETE for ref_tag: 1560281104 ABORT_TASK: Found referenced iSCSI task_tag: 234881040 ABORT_TASK: ref_tag: 234881040 already complete, skipping ABORT_TASK: Sending TMR_TASK_DOES_NOT_EXIST for ref_tag: 234881040 ABORT_TASK: Found referenced iSCSI task_tag: 268435472 ABORT_TASK: ref_tag: 268435472 already complete, skipping ABORT_TASK: Sending TMR_TASK_DOES_NOT_EXIST for ref_tag: 268435472 ABORT_TASK: Found referenced iSCSI task_tag: 218103824 iSCSI Login timeout on Network Portal 192.168.117.29:3260 I then rebooted the NAS using the web interface. I could login the NAS using SSH, and see that the RAID Resync process was still ongoing, and I could still write to the file system at /share/MD0_DATA. An iSCSI logout succeed, but a further iSCSI login did not succeed.
#Build iscsi device fromscratch Offline#
I then noticed that several times during the copy process (after one to eight hours, and hundreds of gigabytes up to a small number of terabytes copied), the host (iSCSI initiator) lost iSCSI connectivity with messages similar to: kernel: connection14:0: detected conn error (1021) iscsid: Kernel reported iSCSI connection 14:0 error (1021 - ISCSI_ERR_SCSI_EH_SESSION_RST: Session was dropped as a result of SCSI error recovery) state (3) kernel: session14: session recovery timed out after 120 secs kernel: sd 23:0:0:0: rejecting I/O to offline device kernel: sd 23:0:0:0: Device offlined - not ready after error recovery Sometimes there were messages such as iscsid: connect to 192.168.117.29:3260 failed (No route to host) in between the "iscsid: Kernel reported iSCSI connection error" and "kernel: session recovery timed out" messages. I then started to copy data on the freshly made iSCSI LUN, while the RAID was doing its initial "rebuild", using whatever speed the system gave me.
This week, I replaced the 2 TB disks with 4 TB disks (WD RED, WD40EFRX-68WT0N0), thereby completely reconfiguring the NAS from scratch in a RAID 6 configuration, still using 4.0.7 firmware. Those disks were configured in a RAID 5 configuration. At the time of installation, I had used 8 hard disks of 2 TB each (Hitachi Deskstar 7K3000, HDS723020BLA642) one of them failed in January 2013 and was replaced with a Seagate Constellation CS, ST2000NC001. The NAS has been running stable under low/moderate load since its installation in April 2011, using whaever firmware was available at the different times the latest was 4.0.7 which had not posed problems. No virtualization is involved, and the maximum available hard disk space is configured to be in one iSCSI LUN. My setup is quite simple: A qnap Turbo NAS TS-859U-RP+ box connected via iSCSI to a single RHEL 6 server. It appears I'm having a similar problem as described in this thread.
0 kommentar(er)
