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

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

 



On Fri, 18 Apr 2014, Dave Chinner wrote:

> Date: Fri, 18 Apr 2014 08:57:01 +1000
> From: Dave Chinner <david@xxxxxxxxxxxxx>
> To: "Michael Kerrisk (man-pages)" <mtk.manpages@xxxxxxxxx>
> Cc: Christoph Hellwig <hch@xxxxxxxxxxxxx>, Namjae Jeon <linkinjeon@xxxxxxxxx>,
>     linux-man@xxxxxxxxxxxxxxx, Theodore T'so <tytso@xxxxxxx>,
>     Linux-Fsdevel <linux-fsdevel@xxxxxxxxxxxxxxx>
> Subject: Re: [PATCH v5 10/10] manpage: update FALLOC_FL_COLLAPSE_RANGE flag in
>      fallocate
> 
> 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.

I'd like to point out that do_fallocate() in vfs uses ENODEV in the
case it is not regular file nor directory.

Also I thought of the EOPNOTSUP to be the right way to go. For
example we do not support it on non-extent based files in ext4 so we
return EOPNOTSUP.

The same is for the case that we do not support the particular
fallocate mode.

So I am not really sure about what's the right error to use.

Thanks!
-Lukas

> 
> 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.
> 
--
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