-
Notifications
You must be signed in to change notification settings - Fork 41
Remove workaround for old Linux kernel CIFS bug #50
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
base: bitcoin-fork
Are you sure you want to change the base?
Remove workaround for old Linux kernel CIFS bug #50
Conversation
This reverts commit d42e63d.
Concept ACK, thanks for taking care of this - I'm all for minimizing the differences with upstream! |
Ping @NicolasDorier; is this still relevant to you? have you run into this issue recently? Can you test this PR on your current setup? FWIW i've synced the entire testnet4 chain to a CIFS share with the patch reverted, no problems. |
Is this related to torvalds/linux@6e70c26? |
That does look like it, thanks. The first release that made it into seems to be 4.17.0, released on June, 3rd 2018. $ git tag --contains 6e70c267e68d77679534dcf4aaf84e66f2cf1425|head -1
v4.17 So it's been fixed for a loong time. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nice!
I recommend taking a look at the Env
implementation in Chromium: they have retries with exponential back-off on syscalls. Implementing this helped me when I deployed LevelDB on a mobile app that runs on devices with faulty storage media.
ACK 53df05c I think this was a bug in the kernel, and filesystems which don't support
There is still a "supported" version of the kernel that lacks this patch, the 4.4 CIP SLTS kernel which will be maintained by the CIP project until 2027, although I'm not sure whether supporting CIP kernels is in-scope for Bitcoin Core, if it is, it would probably be best to submit a backport patch to the CIP mailing list. |
A long time ago (bitcoin/bitcoin#10000) we added a workaround for a Linux kernel issue where calling
fsync
on a directory would instantly and reliably fail for CIFS mounts. In 2018 i ported this forward to the new leveldb tree (d42e63d) without checking if it would still be necessary. Nearly a decade later it's time to reevaluate this.This is an ugly workaround (always intended to be temporary) as the code isn't written specifically: If directory sync fails on a correctly working filesystem it ignores this as well, potentially ignoring a real problem. Although checking for errno==EINVAL partially mitigates this, it would be preferable to get rid of it. See also google#1262 .
So just today i did some experiment to check:
and ran this on a CIFS share:
At least at first glance (some more testing might or might not be warranted), the original problem doesn't appear to exist anymore.
Versions:
This reverts commit d42e63d.