On 11/1/21 6:27 PM, Jeff Layton wrote:
On Mon, 2021-11-01 at 10:04 +0800, xiubli@xxxxxxxxxx wrote:
From: Xiubo Li <xiubli@xxxxxxxxxx>
This patch series is based on the "fscrypt_size_handling" branch in
https://github.com/lxbsz/linux.git, which is based Jeff's
"ceph-fscrypt-content-experimental" branch in
https://git.kernel.org/pub/scm/linux/kernel/git/jlayton/linux.git
and added two upstream commits, which should be merged already.
These two upstream commits should be removed after Jeff rebase
his "ceph-fscrypt-content-experimental" branch to upstream code.
I don't think I was clear last time. I'd like for you to post the
_entire_ stack of patches that is based on top of
ceph-client/wip-fscrypt-fnames. wip-fscrypt-fnames is pretty stable at
this point, so I think it's a reasonable place for you to base your
work. That way you're not beginning with a revert.
Hi Jeff,
BTW, have test by disabling the CONFIG_FS_ENCRYPTION option for branch
ceph-client/wip-fscrypt-fnames ?
I have tried it today but the kernel will crash always with the
following script. I tried many times the terminal, which is running 'cat
/proc/kmsg' will always be stuck without any call trace about it.
# mkdir dir && echo "123" > dir/testfile
By enabling the CONFIG_FS_ENCRYPTION, I haven't countered any issue yet.
I am still debugging on it.
BRs
--Xiubo
Again, feel free to cherry-pick any of the patches in any of my other
branches for your series, but I'd like to see a complete series of
patches.
Thanks,
Jeff
====
This approach is based on the discussion from V1 and V2, which will
pass the encrypted last block contents to MDS along with the truncate
request.
This will send the encrypted last block contents to MDS along with
the truncate request when truncating to a smaller size and at the
same time new size does not align to BLOCK SIZE.
The MDS side patch is raised in PR
https://github.com/ceph/ceph/pull/43588, which is also based Jeff's
previous great work in PR https://github.com/ceph/ceph/pull/41284.
The MDS will use the filer.write_trunc(), which could update and
truncate the file in one shot, instead of filer.truncate().
This just assume kclient won't support the inline data feature, which
will be remove soon, more detail please see:
https://tracker.ceph.com/issues/52916
Changed in V4:
- Retry the truncate request by 20 times before fail it with -EAGAIN.
- Remove the "fill_last_block" label and move the code to else branch.
- Remove the #3 patch, which has already been sent out separately, in
V3 series.
- Improve some comments in the code.
Changed in V3:
- Fix possibly corrupting the file just before the MDS acquires the
xlock for FILE lock, another client has updated it.
- Flush the pagecache buffer before reading the last block for the
when filling the truncate request.
- Some other minore fixes.
Xiubo Li (4):
Revert "ceph: make client zero partial trailing block on truncate"
ceph: add __ceph_get_caps helper support
ceph: add __ceph_sync_read helper support
ceph: add truncate size handling support for fscrypt
fs/ceph/caps.c | 21 ++--
fs/ceph/file.c | 44 +++++---
fs/ceph/inode.c | 203 ++++++++++++++++++++++++++++++------
fs/ceph/super.h | 6 +-
include/linux/ceph/crypto.h | 28 +++++
5 files changed, 251 insertions(+), 51 deletions(-)
create mode 100644 include/linux/ceph/crypto.h
