Thanks for you tips, I would have a try as you said to disable the NOOP. I had make a XFS file system on the LUN at the Initiator side . Finally, I catch the sync_cache command was issued by XFS log infrastructure actually. When I replace the XFS with EXT2 that dmesg error don`t appear anymore during the iozone test. I think pings/Nops got no response because it still stay in TCP stack not received by the target rx-thread.
The Ping time out would lead to IO failure from upper layers? or it can recovery from re-connection and continue to transfer data so upper layers applicaction can not feel the underlying IO error? 2016-05-21 0:39 GMT+08:00 The Lee-Man <leeman.dun...@gmail.com>: > Hi: > > It seems like your backend is getting busy and not replying in time when > it gets very busy. You can disable the NOOP, or you can lengthen its > interval, I believe. > > If there is a bug, it would be in the kernel target subsystem. Have you > tried the target-devel @ vger kernel mailing list? > > > On Friday, May 13, 2016 at 9:52:46 AM UTC-7, Zhengyuan Liu wrote: >> >> Hi everyone: >> I create a target using fileio as the backend storage on ARM64 server. >> The initiator reported some errors showed bellow while perform iozone test. >> >> [178444.145679] connection14:0: ping timeout of 5 secs expired, recv >> timeout 5, last rx 4339462894, last ping 4339464146, now 4339465400 >> [178444.145706] connection14:0: detected conn error (1011) >> [178469.674313] connection14:0: detected conn error (1020) >> [178504.420979] connection14:0: ping timeout of 5 secs expired, recv >> timeout 5, last rx 4339477953, last ping 4339479204, now 4339480456 >> [178504.421001] connection14:0: detected conn error (1011) >> [178532.064262] connection14:0: detected conn error (1020) >> [178564.584087] connection14:0: ping timeout of 5 secs expired, recv >> timeout 5, last rx 4339492980, last ping 4339494232, now 4339495484 >> .............................. >> >> I try to trace the function call of target iscsi. Then, I found the >> receiving thread of target iscsi blocked at fd_execute_sync_cache -> >> vfs_fsync_range. Further, vfs_fsync_range may takes more than 10 seconds to >> return,while initiator Ping timeout would happened after 5 seconds. >> vfs_fsync_range was call with the form vfs_fsync_range(fd_dev->fd_file, 0, >> LLONG_MAX, 1) every times which means sync all device cache. >> So, is this a bug? >> How does Initiator send sync_cache scsi command? >> Does it need to sync all device cache at once? >> Any reply would be thankful. >> > -- You received this message because you are subscribed to the Google Groups "open-iscsi" group. To unsubscribe from this group and stop receiving emails from it, send an email to open-iscsi+unsubscr...@googlegroups.com. To post to this group, send email to email@example.com. Visit this group at https://groups.google.com/group/open-iscsi. For more options, visit https://groups.google.com/d/optout.