Thread (13 messages) 13 messages, 8 authors, 2013-06-24

Re: [PATCH 0/3] ext4: introduce two new ioctls

From: Dave Chinner <david@fromorbit.com>
Date: 2013-06-24 08:08:44
Also in: linux-fsdevel, lkml

On Sun, Jun 23, 2013 at 11:12:35PM -0400, Theodore Ts'o wrote:
On Mon, Jun 24, 2013 at 12:44:59PM +1000, Dave Chinner wrote:
quoted
Hence, at minimum, this should be a fallocate() operation, not a ext4
specific ioctl as it is relatively trivial to implement on most
extent based filesystems.
The fallocate() uses a units of bytes for the offset and length; would
a FALLOC_FL_COLLAPSE_RANGE be guaranteed to work on any arbitrary
offset and length?  Or would it only work if the offset and length are
multiples of the file system blocksize?
There's nothing stopping us from restricting the offset/len to
specific alignments if the operation cannot be done on arbitrary
byte ranges. We do that for direct IO, and the sky hasn't fallen
yet.
The the EXT4_IOC_TRUNCATE_BLOCK_RANGE interface solves this problem by
using units of file system blocks (i.e., __u32 start_block), but that
raises another issue, which is it forces the user space program to
somehow figure out the file system block size, which seems a bit nasty.
Yeah, exactly. We can do that internally very easily, and EINVAL can
be returned when the alignment is bad just like we do for direct
IO...

But, well, I pine for a generic XFS_IOC_DIOINFO interface so the
filesystem can tell users about alignment restrictions....

Cheers,

Dave.
-- 
Dave Chinner
david@fromorbit.com
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help