-
Notifications
You must be signed in to change notification settings - Fork 1.8k
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
zfs ubuntu build completely unstable. #605
Comments
Use the daily for now not the stable. Hopefully the stable will get an update soonish. |
I am using daily. and upgraded 1 hour ago. It is completely unstable. I cannot mount one volume at all. Here the system info: It doesn't work on 3.0.0-17-server too max@s0: max@s0: max@s0: max@s0: max@s0: |
I upgraded ubuntu to 12.04. |
I'm closing the issue since you now have it working under 12.04. |
…um_bytes mismatch (openzfs#605) Whenever we do a PutObject, we use a timeout of `PER_REQUEST_TIMEOUT` which is 2 seconds. The timeout is implemented via `tokio::time::timeout()`, which drops the Future if the timeout expires. See `object_access::retry()`. When this happens, we don't have visibility into the internal state of S3. In particular, we don't know if the PutObject was ignored, actually completed (e.g. we timed out just as it was sending a response to us), or if it will complete at some point of time in the future. The problem occurs when a later PutObject (e.g. due to reclaiming freed blocks) overwrites the same object with different data, and the first, timed-out PutObject is applied at a later time, overwriting the second PutObject's data. This looks like the second PutObject had no effect, but in fact it did take effect, but was later overwritten by the first, timed-out PutObject. If the overwritten data contains blocks from a different (consolidated) object, those blocks will be lost. To mitigate the problem, in this commit we disable object consolidation. In other words, when reclaiming freed space, a given object may be overwritten only with a subset of its original blocks, with no additional blocks added. This way, if a timed-out PutObject takes effect later, the reverted state of the object only contains additional blocks (which will be leaked, at least until the entire object is deleted).
zfs mount -a
took more than 10 min
not all volumes mounted.
delete operations for large files take ages.
The text was updated successfully, but these errors were encountered: