Store read-only flag into metadata file for DiskS3 #17227
Merged
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
I hereby agree to the terms of the CLA available at: https://yandex.ru/legal/cla/?lang=en
Changelog category (leave one):
Changelog entry (a user-readable short description of the changes that goes to CHANGELOG.md):
Fixed possible not-working mutations for parts stored on S3 disk.
Detailed description / Documentation draft:
When we perform local backup of a data part (e.g. doing mutations, cloning) it does the following things with each file of the part:
Marking file as read-only in DiskS3 just sets FS read-only flag for metadata file.
When we create hard-link from that file it modifies metadata file incrementing number of references. This is actually file modification operation and it breaks, because metadata file was marked as read-only right before:
https://gist.github.com/Jokser/d282052507b4592dca78b9c61d1295ca
We shouldn't mark file as read-only on FS in that case, instead we should store read-only inside metadata file and check it if we trying to re-write this file.