Description of problem: Due to a unfortunate copy and paste, calling fsyncPath() actually call lexists(). 492 def lexists(self, path): 493 return self._sendCommand("lexists", {"path": path}, self.timeout) 494 495 def fsyncPath(self, path): 496 return self._sendCommand("lexists", {"path": path}, self.timeout) The code was introduced in: commit ad4cf3d0e8c398d08f5cf60fe1a9582bb8befb8e Author: Saggi Mizrahi <ficoos> Date: Sun Jan 5 14:40:27 2014 +0200 python bindings Signed-off-by: Saggi Mizrahi <ficoos> Version-Release number of selected component (if applicable): Any How reproducible: Always Steps to Reproduce: 1. Run ioprocess with strace -f 2. Call IOProcessClient.fsyncPath("/path/to/file") Actual results: In strace output we can see that ioprocess call access() Expected results: ioprocess should open the file and call fsync().
But is anyone even calling it?
(In reply to Yaniv Kaul from comment #1) > But is anyone even calling it? In VDSM - lib/vdsm/storage/fileUtils.py: def fsyncPath(path): fd = os.open(path, os.O_RDONLY) try: os.fsync(fd) finally: os.close(fd) So this one doesn't (but using the same name? a bit confusing). And in lib/vdsm/storage/outOfProcess.py : def fsyncPath(self, path): self._iop.fsyncPath(path)
(In reply to Yaniv Kaul from comment #1) > But is anyone even calling it? $ git grep fsyncPath lib/vdsm/storage/fileUtils.py:def fsyncPath(path): I think this is leftover from the previous python based out-of-process implementation (remoteFileHandler), and no code is using it. lib/vdsm/storage/outOfProcess.py: def fsyncPath(self, path): lib/vdsm/storage/outOfProcess.py: self._iop.fsyncPath(path) This the wrapper calling IOProcessClient.fsyncPath lib/vdsm/storage/task.py: getProcPool().fileUtils.fsyncPath(origTaskDir) This call is used when saving task state to master file system. The task data is used during rollbacks. I'm not sure if this code actually works since we don't have any tests for it, but the safest solution would to fix iprocess to do what the original author intended.
Tal, this is a bad issue in storage infrastructure, and we have a trivial fix. Suggesting for 4.2.1.
ioprocess-1.0.0-1.fc27 has been submitted as an update to Fedora 27. https://bodhi.fedoraproject.org/updates/FEDORA-2018-fbe8141dd2
ioprocess-1.0.0-1.fc27 has been pushed to the Fedora 27 testing repository. If problems still persist, please make note of it in this bug report. See https://fedoraproject.org/wiki/QA:Updates_Testing for instructions on how to install test updates. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2018-fbe8141dd2
ioprocess-1.0.2-1.fc27 has been submitted as an update to Fedora 27. https://bodhi.fedoraproject.org/updates/FEDORA-2018-5fc2a37e8a
ioprocess-1.0.2-1.fc27 has been pushed to the Fedora 27 testing repository. If problems still persist, please make note of it in this bug report. See https://fedoraproject.org/wiki/QA:Updates_Testing for instructions on how to install test updates. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2018-5fc2a37e8a
Full tier1 automation ran using ioprocess-1.0.2-1.el7ev.x86_64, no errors or regressions occurred related to the new ioprocess. moving to verify.
This bugzilla is included in oVirt 4.2.1 release, published on Feb 12th 2018. Since the problem described in this bug report should be resolved in oVirt 4.2.1 release, it has been closed with a resolution of CURRENT RELEASE. If the solution does not work for you, please open a new bug report.
ioprocess-1.0.2-1.fc27 has been pushed to the Fedora 27 stable repository. If problems still persist, please make note of it in this bug report.