Re: [PATCH v5 10/10] manpage: update FALLOC_FL_COLLAPSE_RANGE flag in fallocate

[Dave Chinner <david-FqsqvQoI3Ljby3iVrkZq2A@public.gmane.org>]

On Thu, Apr 17, 2014 at 03:40:05PM +0200, Michael Kerrisk (man-pages) wrote:
> On 04/16/2014 08:05 AM, Christoph Hellwig wrote:
> > Michael, can you apply this now that we merged FALLOC_FL_COLLAPSE_RANGE
> > into the kernel tree?
> 
> I've applied Namjae Jeon's patch (thanks Namjae!), and done a lot of
> tweaking to generate the patch below.
> 
> Along the way I noticed that there is an inconsistency between XFS
> and JFS that should be fixed (and so have added Dave and Ted to CC,
> as well as linux-fsdevel@). 
> 
> If 'fd' does not refer to a regular file, then XFS fails with the 
> error EINVAL (fs/xfs/xfs_file.c::xfs_file_fallocate()), but ext4 
> fails with the error EOPNOTSUP
> (fs/ext4/extents::ext4_collapse_range()). I suspect that EINVAL
> is the right error for this case.

I think EINVAL is correct here - we support the syscall, just the
type of file we are being asked to operate on is invalid.

FWIW, the reason this check is in the filesystems is that there is
no theoretical reason why we can't do things like preallocation for
directories (e.g. to reduce fragmentation as they grow). It's just
not implemented by any filesystem yet.

[ Hmmmm -  I just had a great idea - removing entire directory
contents via punching blocks. No more "remove one dirent at a time"
for rm -rf, just punch the directory from start to end and there
goes millions of directory entries in a single syscall and a handful
of transactions.  FALLOC_FL_DIR_PUNCH, anyone? ]

> I'd appreciate review on my revised patch, below.

Looks fine to me.

Cheers,

Dave.
-- 
Dave Chinner
david-FqsqvQoI3Ljby3iVrkZq2A@public.gmane.org
--
To unsubscribe from this list: send the line "unsubscribe linux-man" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html