On Tue, 25 Feb 2014 15:23:35 -0800 (PST) Hugh Dickins <hu...@google.com> wrote:
> On Tue, 25 Feb 2014, Dave Chinner wrote: > > On Tue, Feb 25, 2014 at 02:16:01PM +1100, Stephen Rothwell wrote: > > > On Mon, 24 Feb 2014 11:57:10 +1100 Dave Chinner <da...@fromorbit.com> > > > wrote: > > > > > > > > > Namjae Jeon (10): > > > > > fs: Add new flag(FALLOC_FL_COLLAPSE_RANGE) for fallocate > > > > > xfs: Add support FALLOC_FL_COLLAPSE_RANGE for fallocate > > > > > > > > I've pushed these to the following branch: > > > > > > > > git://oss.sgi.com/xfs/xfs.git xfs-collapse-range > > > > > > > > And so they'll be in tomorrow's linux-next tree. > > > > > > > > > ext4: Add support FALLOC_FL_COLLAPSE_RANGE for fallocate > > > > > > > > I've left this one alone for the ext4 guys to sort out. > > > > > > So presumably that xfs tree branch is now completely stable and so Ted > > > could just merge that branch into the ext4 tree as well and put the ext4 > > > part on top of that in his tree. > > > > Well, for some definition of stable. Right now it's just a topic > > branch that is merged into the for-next branch, so in theory it is > > still just a set of pending changes in a branch in a repo that has > > been pushed to linux-next for testing. > > > > That said, I don't see that branch changing unless we find bugs in > > the code or a problem with the API needs fixing, at which point I > > would add more commits to it and rebase the for-next branch that you > > are pulling into the linux-next tree. > > > > Realistically, I'm waiting for Lukas to repost his other pending > > fallocate changes (the zero range changes) so I can pull the VFS and > > XFS bits of that into the XFS tree and I can test them together > > before I'll call the xfs-collapse-range stable and ready to be > > merged into some other tree... > > ... > > Emphasis on "might": I expect it's impossible, given your current > approach, but something to be on guard against is unmap_mapping_range() > failing to find and unmap a pte, because the page is mapped at the > "wrong" place in the vma, resulting in BUG_ON(page_mapped(page)) > in __delete_from_page_cache(). It should be well tested with non-linear mappings please. It *should* be OK, but... > > ... > > FALLOC_FL_COLLAPSE_RANGE: I'm a little sad at the name COLLAPSE, > but probably seven months too late to object. It surprises me that > you're doing all this work to deflate a part of the file, without > the obvious complementary work to inflate it - presumably all those > advertisers whose ads you're cutting out, will come back to us soon > to ask for inflation, so that they have somewhere to reinsert them ;) Yes, I was wondering that. Why not simply "move these blocks from here to there". -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
