On 04/18/2014 12:57 AM, Dave Chinner wrote: > 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. Hmmm -- you and Lukasz seem to differ on this point. > 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? ] Interesting idea. CC me and linux-api on the patch, if you do one. >> I'd appreciate review on my revised patch, below. > > Looks fine to me. Thanks, Michael -- Michael Kerrisk Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/ Linux/UNIX System Programming Training: http://man7.org/training/ -- 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
