Re: Add invalidatepage_range address space operation

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



(I wonder if linux-mmc@xxxxxxxxxxxxxxx was supposed to be
linux-mm@xxxxxxxxx?  Our apologies to linux-mmc if so.)

On Sat, 18 Aug 2012, Theodore Ts'o wrote:
> On Fri, Jul 27, 2012 at 10:00:59AM +0200, Lukas Czerner wrote:
> > This set of patches are aimed to allow truncate_inode_pages_range() handle
> > ranges which are not aligned at the end of the page. Currently it will
> > hit BUG_ON() when the end of the range is not aligned. Punch hole feature
> > however can benefit from this ability saving file systems some work not
> > forcing them to implement their own invalidate code to handle unaligned
> > ranges.
> > 
> > In order for this to work we need however new address space operation
> > invalidatepage_range which should be able to handle page invalidation with
> > offset and length specified.
> > 
> > patch 01:	Implements the new invalidatepage_range address space
> > 		operation in the mm layer
> > patch 02 - 05:	Wire the new invalidatepage_range aop to the ext4, xfs and
> > 		ocfs2 file system (which are currently the only file
> > 		systems supporting punch hole) and implement this
> > 		functionality for jbd2 as well.

(tmpfs also supports punch hole, but has its own truncation routine,
and does not need to get involved in these changes.)

> > patch 06:	Change truncate_inode_pages_range() to handle unaligned
> > 		ranges.
> > patch 07 - 15:	Ext4 specific changes which take benefit from the
> > 		previous truncate_inode_pages_range() change. Not all
> > 		are realated specifically to this change, but all are
> > 		related to the punch hole feature.
> 
> What's the current status of this patch series?
> 
> I haven't seen much if any comment from the mm folks and the xfs/ocfs2
> folks.  I've incorporated the patches into the unstable portion of the
> ext4 tree so I can do some testing (some minor changes to the ext4
> patches were needed to rebase the patch series to the 3.6-rc1-based
> ext4 dev tree, but nothing major).  However, I don't want to include
> this into the ext4 tree for merging into linux-next unless we get
> general agreement from the maintainers of the other trees that are
> affected by this patch series.

Thanks for the reminder.  I'm happy with the general direction, if not
some of the details; though I see it as more of a vfs than an mm thing.

I'll comment briefly now on patch 06 (which is fine) and patch 01 (which
is not) and patch 07 (which is outside my scope, but worth a remark on).

I won't attempt to judge whether the ext4 and ocfs2 and xfs parts
are correct; but from the look of it, 02 03 04 05 are wrong like 01
(or you can say it's 06 which is wrong, though it looks good to me).

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


[Index of Archives]     [Linux Ext4 Filesystem]     [Union Filesystem]     [Filesystem Testing]     [Ceph Users]     [Ecryptfs]     [AutoFS]     [Kernel Newbies]     [Share Photos]     [Security]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux Cachefs]     [Reiser Filesystem]     [Linux RAID]     [Samba]     [Device Mapper]     [CEPH Development]
  Powered by Linux