From: Hugh Dickins <hughd@google.com>
To: Lukas Czerner <lczerner@redhat.com>
Cc: Christoph Hellwig <hch@infradead.org>,
Andrew Morton <akpm@linux-foundation.org>,
Theodore Ts'o <tytso@mit.edu>, Dave Chinner <dchinner@redhat.com>,
linux-ext4@vger.kernel.org, linux-fsdevel@vger.kernel.org,
achender@linux.vnet.ibm.com
Subject: Re: [PATCH 06/12 v2] mm: teach truncate_inode_pages_range() to hadnle non page aligned ranges
Date: Wed, 18 Jul 2012 12:36:39 -0700 (PDT) [thread overview]
Message-ID: <alpine.LSU.2.00.1207181154410.2160@eggly.anvils> (raw)
In-Reply-To: <alpine.LFD.2.00.1207180945390.2291@dhcp-1-248.brq.redhat.com>
On Wed, 18 Jul 2012, Lukas Czerner wrote:
> On Tue, 17 Jul 2012, Lukas Czerner wrote:
> >
> > My bad, it definitely is not safe without the end offset argument in
> > invalidatepage() aops ..sigh..
>
> So what about having new aop invalidatepage_range and using that in
> the truncate_inode_pages_range(). We can still BUG_ON if the file
> system register invalidatepage, but not invalidatepage_range,
> when the range to truncate is not page aligned at the end.
I had some trouble parsing what you wrote, and have slightly adjusted
it (mainly adding a comma) to fit my understanding: shout at me if I'm
misrepresenting you!
Yes, I think that's what has to be done. It's irritating to have two
methods doing the same job, but not nearly so irritating as having to
change core and all filesystems at the same time. Then at some future
date there can be a cleanup to remove the old invalidatepage method.
>
> I am sure more file system than just ext4 can take advantage of
> this. Currently only ext4, xfs and ocfs2 support punch hole and I
> think that all of them can use truncate_inode_pages_range() which
> handles unaligned ranges.
I expect that they can, but I'm far from sure of it: each filesystem
will have its own needs and difficulties, which might delay them from
a quick switchover to invalidatepage_range.
>
> Currently ext4 has it's own overcomplicated method of freeing and
> zeroing unaligned ranges.
You're best placed to judge if its overcomplicated, I've not looked.
> Xfs seems just truncate the whole file and
I doubt that can be the case: how would it ever pass testing with
the hole-punching fsx if so? But it is the case that xfs unmaps
all the pages from hole onwards, in the exceptional case where the
punched file is currently mmap'ed into userspace; and that is wrong,
and will get fixed, but it's not a huge big deal meanwhile. (But it
does suggest that hole-punching is more difficult to get completely
right than people think at first.)
> there seems to be a bug in ocfs2 where we can hit BUG_ON when the
> cluster size < page size.
>
> What do you reckon ?
I agree that you need invalidatepage_range for truncate_inode_page_range
to drop its end alignment restriction. But now that we have to add a
method, I think it would be more convincing justification to have two
filesystems converted to make use of it, than just the one ext4.
Hugh
next prev parent reply other threads:[~2012-07-18 19:36 UTC|newest]
Thread overview: 31+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-07-13 13:19 [PATCH 01/12 v2] Revert "ext4: remove no longer used functions in inode.c" Lukas Czerner
2012-07-13 13:19 ` [PATCH 02/12 v2] Revert "ext4: fix fsx truncate failure" Lukas Czerner
2012-07-13 17:42 ` Theodore Ts'o
2012-07-14 7:45 ` Christoph Hellwig
2012-07-16 7:35 ` Lukáš Czerner
2012-07-16 21:41 ` Hugh Dickins
2012-07-17 7:53 ` Lukáš Czerner
2012-07-18 19:34 ` Eric Sandeen
2012-07-19 6:45 ` Lukáš Czerner
2012-07-13 13:19 ` [PATCH 03/12 v2] shmem: pass LLONG_MAX to shmem_truncate_range Lukas Czerner
2012-07-18 19:54 ` Eric Sandeen
2012-07-19 6:40 ` Lukáš Czerner
2012-07-13 13:19 ` [PATCH 04/12 v2] xfs: pass LLONG_MAX to truncate_inode_pages_range Lukas Czerner
2012-07-15 23:11 ` Dave Chinner
2012-07-16 7:13 ` Lukáš Czerner
2012-07-16 11:52 ` Lukáš Czerner
2012-07-13 13:19 ` [PATCH 05/12 v2] mm: " Lukas Czerner
2012-07-13 13:19 ` [PATCH 06/12 v2] mm: teach truncate_inode_pages_range() to hadnle non page aligned ranges Lukas Czerner
2012-07-17 8:28 ` Hugh Dickins
2012-07-17 11:57 ` Lukáš Czerner
2012-07-17 12:16 ` Lukáš Czerner
2012-07-18 8:18 ` Lukáš Czerner
2012-07-18 19:36 ` Hugh Dickins [this message]
2012-07-19 7:15 ` Lukáš Czerner
2012-07-19 23:07 ` Dave Chinner
2012-07-13 13:19 ` [PATCH 07/12 v2] ext4: use ext4_zero_partial_blocks in punch_hole Lukas Czerner
2012-07-13 13:19 ` [PATCH 08/12 v2] ext4: remove unused discard_partial_page_buffers Lukas Czerner
2012-07-13 13:19 ` [PATCH 09/12 v2] ext4: remove unused code from ext4_remove_blocks() Lukas Czerner
2012-07-13 13:19 ` [PATCH 10/12 v2] ext4: update ext4_ext_remove_space trace point Lukas Czerner
2012-07-13 13:19 ` [PATCH 11/12 v2] ext4: make punch hole code path work with bigalloc Lukas Czerner
2012-07-13 13:19 ` [PATCH 12/12 v2] ext4: Allow punch hole with bigalloc enabled Lukas Czerner
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=alpine.LSU.2.00.1207181154410.2160@eggly.anvils \
--to=hughd@google.com \
--cc=achender@linux.vnet.ibm.com \
--cc=akpm@linux-foundation.org \
--cc=dchinner@redhat.com \
--cc=hch@infradead.org \
--cc=lczerner@redhat.com \
--cc=linux-ext4@vger.kernel.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=tytso@mit.edu \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox