Bug 1536261
Summary: | IOProcess.fsyncPath does not fsync anything | ||
---|---|---|---|
Product: | [oVirt] ovirt-distribution | Reporter: | Nir Soffer <nsoffer> |
Component: | ioprocess | Assignee: | Nir Soffer <nsoffer> |
ioprocess sub component: | General | QA Contact: | Lilach Zitnitski <lzitnits> |
Status: | CLOSED ERRATA | Docs Contact: | |
Severity: | high | ||
Priority: | unspecified | CC: | ratamir, tnisan |
Version: | 4.2.1 | Flags: | rule-engine:
ovirt-4.2?
tnisan: planning_ack? tnisan: devel_ack+ rule-engine: testing_ack+ |
Target Milestone: | ovirt-4.2.1 | ||
Target Release: | --- | ||
Hardware: | Unspecified | ||
OS: | Unspecified | ||
Whiteboard: | |||
Fixed In Version: | ioprocess-1.0.2-1.fc27 | Doc Type: | If docs needed, set a value |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2018-02-22 10:01:45 UTC | Type: | Bug |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | Storage | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: |
Description
Nir Soffer
2018-01-19 01:20:11 UTC
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. |