mds: add truncate size handling support for fscrypt #43588
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
|
jenkins test make check |
jtlayton
reviewed
Oct 20, 2021
lxbsz
commented
Oct 28, 2021
3 tasks
|
@kotreshhr Could help review the Thanks. |
lxbsz
commented
Nov 16, 2021
lxbsz
force-pushed
the
fsize_support
branch
2 times, most recently
from
424debf
to
34eafd9
Compare
|
Have removed the |
lxbsz
commented
Nov 24, 2021
lxbsz
force-pushed
the
fsize_support
branch
2 times, most recently
from
ca2c6cf
to
d818cdc
Compare
|
Cleaned up patches and added more comments, and also split the big patch into several small ones. Since Jeff and I have passed all the xfstests tool related tests in kclient with this PR, I have dropped the Draft flag. |
|
Rebased it to the upstream and only changed the commit |
|
jenkins test make check |
|
This pull request can no longer be automatically merged: a rebase is needed and changes have to be manually resolved |
Signed-off-by: Jeff Layton <jlayton@redhat.com>
A flag isn't sufficient as we can't reasonably use an xattr to store the context. Switch the fscrypt fields to two vectors of opaque bytes, one governed by AUTH caps and the other by FILE. Also remove the special handling for encryption.ctx xattr, since we won't be using that going forward anyway. Signed-off-by: Jeff Layton <jlayton@redhat.com>
Add fscrypt_auth and fscrypt_file attributes to the inode_t encoding. Signed-off-by: Jeff Layton <jlayton@redhat.com>
Signed-off-by: Jeff Layton <jlayton@redhat.com>
...and update those fields when the appropriate caps are acquired/released/flushed. Signed-off-by: Jeff Layton <jlayton@redhat.com>
...and update the fscrypt_file field on setattr changes for size. Signed-off-by: Jeff Layton <jlayton@redhat.com>
Signed-off-by: Jeff Layton <jlayton@redhat.com>
Add new mask bits for those fields and update them if a setattr request comes in with them. Signed-off-by: Jeff Layton <jlayton@redhat.com>
We don't really expect the userland client to use these (at least not initially) but plumb in new vxattrs for fetching and setting these fields. The new vxattr just fetches whatever is in the in-core inode, and setting it issues a setattr under the hood. Also, ensure that we update these fields on cap updates and client requests. Signed-off-by: Jeff Layton <jlayton@redhat.com>
Create a file and set both fscrypt_auth and fscrypt_file on it. Verify that they are set, remount and verify it again. Signed-off-by: Jeff Layton <jlayton@redhat.com>
Signed-off-by: Jeff Layton <jlayton@redhat.com>
Encryption is currently only supported on files/directories with layouts where stripe_count=1. Forbid changing layouts when encryption is involved. Signed-off-by: Luis Henriques <lhenriques@suse.de>
The clients will trust and need fscrypt_file field to truncate the pagecaches and update the i_size. Signed-off-by: Xiubo Li <xiubli@redhat.com>
The maximum size of the last block without the header along with a truncate request when the fscrypt is enabled. Default value is 4KB. Signed-off-by: Xiubo Li <xiubli@redhat.com>
Signed-off-by: Xiubo Li <xiubli@redhat.com>
Signed-off-by: Xiubo Li <xiubli@redhat.com>
For now the userland clients hasn't support the fscrypt yet, they will be only allowed to read the encrypted files. Signed-off-by: Xiubo Li <xiubli@redhat.com>
The kclient will only send truncate requests with the modified and encrypted last block contents when new size is smaller and is not aligned to CEPH_FSCRYPT_BLOCK_SIZE, which is 4KB for now. Or if the Fx caps is issued and the new size is larger the kclient will buffer the truncating. Or it will send truncate requests wihtout the last block filled. When the fscrypt is enabled and when truncating with a smaller size, both the old size and new size in the truncate request will always be rounded up to CEPH_FSCRYPT_BLOCK_SIZE, which is 4K for now, in kclient. For example if truncating a file size from 3KB to 2KB, the MDS will always get old_size == new_size == 4KB. So we need to check whether there has last block data passed together with the truncate request to make sure whether truncating to a smaller size. The kclinet will send it's 'change_attr' along with the truncate req, and the MDS will compare it with the one in CInode just after the MDS successfully xlockes the CInode's filelock, if they are different that means it's possibly some clients have update the file or have dirty caps just before MDS xlockes the CInode's filelock. We will let the kclient retry it by returning a -EAGAIN errno. Then the MDS will write the last block to OSD and then truncate the size as normal. Currently the last block contents will be journaled together with the project inode only and it will be cleared after the truncate being finished, and won't make it persistent together with the CInode:inode_t in the metadata pool. Signed-off-by: Xiubo Li <xiubli@redhat.com>
|
The conflicts are in the commit |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
This PR is to support the size handling(truncate size) feature for file cryption, and this is based on Jeff's #41284 PR.
In the kclient side, only when truncating smaller size and the new size is not aligned to
CEPH_FSCRYPT_BLOCK_SIZEwill the truncate request pass the encrypted last block contents to MDS. And the MDS will help update the last block when truncating the file size.More detail please see the commit comments.
Checklist
Show available Jenkins commands
jenkins retest this pleasejenkins test classic perfjenkins test crimson perfjenkins test signedjenkins test make checkjenkins test make check arm64jenkins test submodulesjenkins test dashboardjenkins test dashboard cephadmjenkins test apijenkins test docsjenkins render docsjenkins test ceph-volume alljenkins test ceph-volume tox