On Wed, 2021-10-20 at 21:28 +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, > has reverted one useless commit and added some upstream commits. > > I will keep this patch set as simple as possible to review since > this is still one framework code. It works and still in developing > and need some feedbacks and suggestions for two corner cases below. > Ok, I think you're on a good start. It's a bit hard to review patchsets that rely on other out-of-tree patches. The ceph-fscrypt-content- experimental branch is _really_ experimental, and you start the series by reverting one of the patches in there. The goal here is for you to send a complete series that we'll want to merge, without all of the interim churn of reverting patches and changing the same code several times. I think what would be best here is for you to put together and send a complete patchset that is based on top of the ceph-client/wip-fscrypt-fnames branch. I've just rebased that branch onto the latest ceph-client/testing branch, but it has been fairly stable for the last few weeks, and any changes we make in there probably won't affect in the areas you're working as much. Feel free to cherry-pick any patches from my ceph-fscrypt-content- experimental branch that you think should part of the set. Also feel free to modify any of those patches. We don't want buggy patches partway through the merge of the series. Does that sound OK? > ==== > > This approach is based on the discussion from V1, 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(). > > I have removed the inline data related code since we are remove > this feature, more detail please see: > https://tracker.ceph.com/issues/52916 > > > Note: There still has two CORNER cases we need to deal with: > > 1), If a truncate request with the last block is sent to the MDS and > just before the MDS has acquired the xlock for FILE lock, if another > client has updated that last block content, we will over write the > last block with old data. > > For this case we could send the old encrypted last block data along > with the truncate request and in MDS side read it and then do compare > just before updating it, if the comparasion fails, then fail the > truncate and let the kclient retry it. > > 2), If another client has buffered the last block, we should flush > it first. I am still thinking how to do this ? Any idea is welcome. > > Thanks. > > > Xiubo Li (4): > ceph: add __ceph_get_caps helper support > ceph: add __ceph_sync_read helper support > ceph: return the real size readed when hit EOF > ceph: add truncate size handling support for fscrypt > > fs/ceph/caps.c | 28 ++++--- > fs/ceph/file.c | 41 ++++++---- > fs/ceph/inode.c | 210 ++++++++++++++++++++++++++++++++++++++++++------ > fs/ceph/super.h | 4 + > 4 files changed, 234 insertions(+), 49 deletions(-) > -- Jeff Layton <jlayton@xxxxxxxxxx>
