Comment 63 for bug 1569925
Revision history for this message
| Rafael David Tinoco (rafaeldtinoco) wrote | #63 |
© 2004
Canonical Ltd.
•
Terms of use
•
Data privacy
•
Contact Launchpad Support
•
Blog
•
Careers
•
System status
•
f33e652
(Get the code!)
Hello Matt,
Good to read your feedback. When you have multipath AND iscsi, the error propagation timeout can be given by one or both, that is why I explained both. This issue is not an iscsi or multipath problem, it is a systemd problem related to the fact that the network is removed before the disks are unmounted. Good to know you don't have containers, that is something that could hold the disk superblock reference as well (even not having containers, filesystems mounted by _netdev can hold reference by different mount namespaces started by systemd itself, not the case here).
Could you do me a favor. Are you reproducing this issue in a constant basis ? If you are, could you please reduce your replacement_timeout to 0 and see if you can reproduce it again ? Please be aware that, after changing replacement_timeout = 0 in iscsid.conf, you will have to change the parameter for the disks already discovered:
## example
Change iscsid.conf AND:
$ sudo iscsiadm -m node
192.168.48.1:3260,1 iqn.2017.
192.168.48.1:3260,1 iqn.2017.
$ sudo iscsiadm -m node -o show | grep node.session.
node.session.
node.session.
$ sudo iscsiadm -m node -o update -n node.session.
$ sudo iscsiadm -m node -o show | grep node.session.
node.session.
node.session.
This will cause the I/O errors to be propagated right away - when systemd disconnects the interface - and cause the later umount - done by other systemd service - to succeed without waiting for pagecache timeout + iscsi timeout (20 for you). Hopefully the "0" will be fast enough to make systemd to continue all the times.
Could you please let me know if it mitigates the issue ? If it does, I'll work in the actual fix. This will just confirm hypothesis and help in diagnose (and serve as a workaround if anyone cares).
Thank you
-Rafael