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-man" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
