All of lore.kernel.org
 help / color / mirror / Atom feed
From: Namjae Jeon <namjae.jeon@samsung.com>
To: "'Lukáš Czerner'" <lczerner@redhat.com>
Cc: 'linux-ext4' <linux-ext4@vger.kernel.org>
Subject: RE: [PATCH 3/5] ext4: No need to truncate pagecache twice in collapse range
Date: Fri, 18 Apr 2014 14:31:35 +0900	[thread overview]
Message-ID: <002101cf5ac7$76d97bf0$648c73d0$@samsung.com> (raw)
In-Reply-To: <alpine.LFD.2.00.1404171004250.2143@localhost.localdomain>

> On Thu, 17 Apr 2014, Namjae Jeon wrote:
> 
> > Date: Thu, 17 Apr 2014 09:41:45 +0900
> > From: Namjae Jeon <namjae.jeon@samsung.com>
> > To: Lukáš Czerner <lczerner@redhat.com>
> > Cc: linux-ext4 <linux-ext4@vger.kernel.org>
> > Subject: RE: [PATCH 3/5] ext4: No need to truncate pagecache twice in collapse
> >      range
> >
> > >
> > > We're already calling truncate_pagecache_range() before we attempt to
> > > do any actual job so there is not need to truncate pagecache once more
> > > using truncate_setsize() after we're finished.
> > >
> > > Remove truncate_setsize() and replace it just with i_size_write() note
> > > that we're holding appropriate locks.
> > >
> > > Signed-off-by: Lukas Czerner <lczerner@redhat.com>
> >
> > Hi Lukas.
> >
> > I added this code by getting rewiew from Hugh.
> > Plz see the disscusion beween Hugh and Dave.
> >
> > Hugh: But your case is different: collapse is much closer to truncation,
> >  and if you do not unmap the private COW'ed pages, then pages left
> >  behind beyond the EOF will break the spec that requires SIGBUS when
> >  touching there, and pages within EOF will be confusingly derived
> >  from file data now belonging to another offset or none (move these
> >  pages within the user address space? no, I don't think anon_vmas
> >  would allow that, and there may be no right place to move them).
> >
> > Dave: See above - we never leave pages beyond the new EOF because setting
> >  the new EOF is a truncate operation that calls
> >  truncate_setsize(inode, newsize).
> >
> > Hugh: Right, thanks, I now see the truncate_setsize() in the xfs case -
> >  though not in the ext4 case, which looks as if it's just doing an
> >  i_size_write() afterwards.
> >
> > Dave: So that's a bug in the ext4 code ;)
> >
> > truncate_setsize is not needed in case Hugh pointed out ?
> >
> > Thanks!
> 
> That is true, we need to make sure that the page cache is coherent
> with what's on disk. But we've already done that before releasing
> the blocks. As I mention in the comment we're doing
> truncate_pagecache_range() before removing any space. That's exactly
> how it's supposed to be used. See comment in
> truncate_pagecache_range().
> 
> However as I noticed we do not actually need to use
> truncate_pagecache_range(), but rather truncate_pagecache() so I can
> change that in my patch.
Hi Lukas.

Will you change that in your patch ?
Actually, I am waiting for this one..
Thanks.
> 
> Does that make sense to everyone ?
> 
> Thanks!
> -Lukas

--
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

  reply	other threads:[~2014-04-18  5:31 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <002d01cf59d4$c9a07a30$5ce16e90$@samsung.com>
2014-04-17  0:41 ` [PATCH 3/5] ext4: No need to truncate pagecache twice in collapse range Namjae Jeon
2014-04-17  8:07   ` Lukáš Czerner
2014-04-18  5:31     ` Namjae Jeon [this message]
2014-04-18  8:56       ` Lukáš Czerner
2014-04-16 18:32 [PATCH 1/5] ext4: Use filemap_write_and_wait_range() correctly " Lukas Czerner
2014-04-16 18:33 ` [PATCH 3/5] ext4: No need to truncate pagecache twice " Lukas Czerner
2014-04-18 14:49   ` Theodore Ts'o

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='002101cf5ac7$76d97bf0$648c73d0$@samsung.com' \
    --to=namjae.jeon@samsung.com \
    --cc=lczerner@redhat.com \
    --cc=linux-ext4@vger.kernel.org \
    /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.