All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Yan, Zheng" <ukernel@gmail.com>
To: Jeff Layton <jlayton@kernel.org>
Cc: Xiubo Li <xiubli@redhat.com>, Ilya Dryomov <idryomov@gmail.com>,
	Venky Shankar <vshankar@redhat.com>,
	ceph-devel <ceph-devel@vger.kernel.org>
Subject: Re: [PATCH] ceph: do not truncate pagecache if truncate size doesn't change
Date: Wed, 17 Nov 2021 10:47:49 +0800	[thread overview]
Message-ID: <CAAM7YAm6iovKdptjiZhgjm8kwrOeUyBYG3z82+Updrkrd-QMOA@mail.gmail.com> (raw)
In-Reply-To: <d37b49e0048ba3cf6763b83c82ad2fd8f8f36663.camel@kernel.org>

On Wed, Nov 17, 2021 at 4:13 AM Jeff Layton <jlayton@kernel.org> wrote:
>
> On Tue, 2021-11-16 at 17:20 +0800, xiubli@redhat.com wrote:
> > From: Xiubo Li <xiubli@redhat.com>
> >
> > In case truncating a file to a smaller sizeA, the sizeA will be kept
> > in truncate_size. And if truncate the file to a bigger sizeB, the
> > MDS will only increase the truncate_seq, but still using the sizeA as
> > the truncate_size.
> >
>
> Do you mean "kept in ci->i_truncate_size" ? If so, is this really the
> correct fix? I'll note this in the sources:
>
>         u32 i_truncate_seq;        /* last truncate to smaller size */
>         u64 i_truncate_size;       /*  and the size we last truncated down to */
>
> Maybe the MDS ought not bump the truncate_seq unless it was truncating
> to a smaller size? If not, then that comment seems wrong at least.
>

mds does not change truncate_{seq,size} when truncating file to bigger size

>
> > So when filling the inode it will truncate the pagecache by using
> > truncate_sizeA again, which makes no sense and will trim the inocent
> > pages.
> >
>
> Is there a reproducer for this? It would be nice to put something in
> xfstests for it if so.
>
> > Signed-off-by: Xiubo Li <xiubli@redhat.com>
> > ---
> >  fs/ceph/inode.c | 5 +++--
> >  1 file changed, 3 insertions(+), 2 deletions(-)
> >
> > diff --git a/fs/ceph/inode.c b/fs/ceph/inode.c
> > index 1b4ce453d397..b4f784684e64 100644
> > --- a/fs/ceph/inode.c
> > +++ b/fs/ceph/inode.c
> > @@ -738,10 +738,11 @@ int ceph_fill_file_size(struct inode *inode, int issued,
> >                        * don't hold those caps, then we need to check whether
> >                        * the file is either opened or mmaped
> >                        */
> > -                     if ((issued & (CEPH_CAP_FILE_CACHE|
> > +                     if (ci->i_truncate_size != truncate_size &&
> > +                         ((issued & (CEPH_CAP_FILE_CACHE|
> >                                      CEPH_CAP_FILE_BUFFER)) ||
> >                           mapping_mapped(inode->i_mapping) ||
> > -                         __ceph_is_file_opened(ci)) {
> > +                         __ceph_is_file_opened(ci))) {
> >                               ci->i_truncate_pending++;
> >                               queue_trunc = 1;
> >                       }
>
> --
> Jeff Layton <jlayton@kernel.org>

  parent reply	other threads:[~2021-11-17  2:48 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-11-16  9:20 [PATCH] ceph: do not truncate pagecache if truncate size doesn't change xiubli
2021-11-16 20:06 ` Jeff Layton
2021-11-17  1:21   ` Xiubo Li
2021-11-17 13:28     ` Jeff Layton
2021-11-17 13:40       ` Xiubo Li
2021-11-17 13:50         ` Jeff Layton
2021-11-17 15:06     ` Jeff Layton
2021-11-18  2:38       ` Xiubo Li
2021-11-18 12:19         ` Jeff Layton
2021-11-19  2:20           ` Xiubo Li
2021-11-17  2:47   ` Yan, Zheng [this message]
2021-11-17  4:19     ` Xiubo Li
2021-11-17 21:10 ` Jeff Layton
2021-11-18  4:46   ` Xiubo Li
2021-11-18  9:59     ` Xiubo Li
     [not found] ` <09babbaf077a76ace4793f2e6ae6127d2e7d6411.camel@kernel.org>
2021-11-19  4:29   ` Xiubo Li
2021-11-19  4:33     ` Xiubo Li
2021-11-19 11:59     ` Jeff Layton
2021-11-20  0:58       ` Xiubo Li
2021-11-22 19:10         ` Jeff Layton
2021-11-23  1:00           ` Xiubo Li
2021-11-23  8:06             ` Xiubo Li
2021-11-23  3:11           ` Xiubo Li

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CAAM7YAm6iovKdptjiZhgjm8kwrOeUyBYG3z82+Updrkrd-QMOA@mail.gmail.com \
    --to=ukernel@gmail.com \
    --cc=ceph-devel@vger.kernel.org \
    --cc=idryomov@gmail.com \
    --cc=jlayton@kernel.org \
    --cc=vshankar@redhat.com \
    --cc=xiubli@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.