[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20130624031235.GA6991@thunk.org>
Date: Sun, 23 Jun 2013 23:12:35 -0400
From: Theodore Ts'o <tytso@....edu>
To: Dave Chinner <david@...morbit.com>
Cc: Eric Sandeen <esandeen@...hat.com>,
Andreas Dilger <adilger@...ger.ca>,
Namjae Jeon <linkinjeon@...il.com>,
"adilger.kernel@...ger.ca" <adilger.kernel@...ger.ca>,
"linux-fsdevel@...r.kernel.org" <linux-fsdevel@...r.kernel.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"linux-ext4@...r.kernel.org" <linux-ext4@...r.kernel.org>,
"a.sangwan@...sung.com" <a.sangwan@...sung.com>,
Namjae Jeon <namjae.jeon@...sung.com>
Subject: Re: [PATCH 0/3] ext4: introduce two new ioctls
On Mon, Jun 24, 2013 at 12:44:59PM +1000, Dave Chinner wrote:
>
> 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?
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.
- Ted
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists