Re: [PATCH 0/3] fs: Introduce FALLOC_FL_INSERT_RANGE for fallocate

From: Dave Chinner
Date: Mon Apr 07 2014 - 20:55:42 EST


On Mon, Mar 31, 2014 at 11:53:31PM +0900, Namjae Jeon wrote:
> From: Namjae Jeon <namjae.jeon@xxxxxxxxxxx>
>
> FALLOC_FL_INSERT_RANGE was mentioned as the opposite command of collapse
> range from discussion between Hugh Dickins and Dave Chinner.
>
> In continuation of the work of making the process of non linear editing of
> media files faster, we introduce here the new flag FALLOC_FL_INSERT_RANGE
> for fallocate.
>
> This flag will work opposite to the newly added FALLOC_FL_COLLAPSE_RANGE flag.
> As such, specifying FALLOC_FL_INSERT_RANGE flag will insert zeroed-out space
> in between the file within the range specified by offset and len. User can
> write new data in this space. e.g. ads.
> Like collapse range, currently we have the limitation that offset and len
> should be block size aligned for both XFS and Ext4.
>
> The semantics of the flag are :
> 1) It allocates new zeroed out on disk space of len bytes starting
> at offset byte without overwriting any existing data. All the data blocks
> from offset to EOF are shifted towards right to make space for inserting
> new blocks
> 2) It should be used exclusively. No other fallocate flag in combination.
> 3) Offset and length supplied to fallocate should be fs block size aligned
> in case of xfs and ext4.
> 4) Insert range does not work for the case when offset is overlapping/beyond
> i_size. If the user wants to allocate space at the end of file they are
> advised to use either ftruncate(2) or fallocate(2) with mode 0.
> 5) It increses the size of file by len bytes.
>
> Namjae Jeon (3):
> fs: Add FALLOC_FL_INSERT_RANGE flags for fallocate
> xfs: Add support FALLOC_FL_INSERT_RANGE for fallocate
> ext4: Add support FALLOC_FL_INSERT_RANGE for fallocate
> TODO : xfsprog: xfsio: Add support FALLOC_FL_INSERT_RANGE for fallocate
> TODO : xfstests: Add insert range testcase

Namjae, what's your proposed timeframe on getting the xfs_io and tes
cases sorted out? I'm just trying to plan ahead for the next couple
of months (i.e. the 3.16 merge cycle), so some indication of whether
I can expect this to be complete and ready for merge within that
timeframe would be helpful to me.

FWIW, it would be really nice if you could add support for fsx and
fsstress for this as well as adding corner case tests. :)

Cheers,

Dave.
--
Dave Chinner
david@xxxxxxxxxxxxx
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/