Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Input/Output Error at End of Device #119

Open
NickPublica opened this issue Jul 20, 2020 · 2 comments
Open

Input/Output Error at End of Device #119

NickPublica opened this issue Jul 20, 2020 · 2 comments

Comments

@NickPublica
Copy link

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"

@NickPublica
Copy link
Author

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.

@sclsj
Copy link

sclsj commented Jan 28, 2022

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants