You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Been using it for 3 years now flawlessly with virtual drives connected 24/7. I've only recently hit an issue now that the 1TB drives have filled up. Once writes happen with approximately 2.5GB of free space left, my servers physical drives start trashing for half a minute before the the LUN locks up. From this point, logging out with iscsictl returns an input/output error for that specific LUN and a hard power cycle seems to be the only way to fix it. Other LUNs seem fine and function as normal as long as they don't run out of space. To my knowledge, drive reads work as usual even when full but writes triggers this behaviour.
The server is running Ubuntu 18.04 with tgt for serving up the virtual drives which are 1TB images. The client computer is an iMac on 10.12.6 connected via a thunderbolt 2 to 10gbe card via fibre(probably irrelevant but the more information the better right?). Will test later on with smaller images to see if i can reproduce this at the "end of drive"
The text was updated successfully, but these errors were encountered:
Upon doing more testing, this doesn't appear to be related to filling up a drive as previously thought. Made a smaller 6GB image and filled it up without issue.
Cloning the problematic 1TB volume to a blank one with Disk Utility also causes this issue with the clone(cloning succeeds but using the cloned data causes the problem). AFAIK, this does a file-level clone instead of a block level clone but I could be wrong. It appears that there could be some problematic files that causes the IO error on the iSCSI level due to the combination of files + filesystem.
Also tried copying the problematic directory to a blank image via Finder which also causes the issue when written to.
Once a lockup happens, iscsictl logout also returns IO errors and the OS is unable to even complete a shutdown as it's stuck waiting on iSCSI. One needs to literally yank the power cord(or just hold down the power button) to reboot.
I encountered the same problem. I suspect it might be related to unstable network. I'm using macbook pro 2017 and macOS High Sierra.
Symptom: during time machine backups it would froze randomly, and after it froze I cannot disconnect the target (I/O error). Due to this problem I was not even able to complete my first / initial TM backup. Unloading the kext always timeout and therefore causes kernel panic. The only way is to force restart the macbook.
Been using it for 3 years now flawlessly with virtual drives connected 24/7. I've only recently hit an issue now that the 1TB drives have filled up. Once writes happen with approximately 2.5GB of free space left, my servers physical drives start trashing for half a minute before the the LUN locks up. From this point, logging out with iscsictl returns an input/output error for that specific LUN and a hard power cycle seems to be the only way to fix it. Other LUNs seem fine and function as normal as long as they don't run out of space. To my knowledge, drive reads work as usual even when full but writes triggers this behaviour.
The server is running Ubuntu 18.04 with tgt for serving up the virtual drives which are 1TB images. The client computer is an iMac on 10.12.6 connected via a thunderbolt 2 to 10gbe card via fibre(probably irrelevant but the more information the better right?). Will test later on with smaller images to see if i can reproduce this at the "end of drive"
The text was updated successfully, but these errors were encountered: