On Thu, Jan 14, 2010 at 5:27 PM, Roland Dreier <rdreier@xxxxxxxxx> wrote:
> My fallocate man page says:
>
> Because allocation is done in block size chunks, fallocate() may
> allocate a larger range than that which was specified.
>
> so the btrfs behavior seems OK to me.
>
> You say this is a regression. What btrfs version behaved differently?
Err. My wording may not be very precise.
I see this as the regression from every other filesystem, to the
extent that rsync --preallocate will give you directory tree full of
corrupted files.
Also, your man page also says something else:
If FALLOC_FL_KEEP_SIZE flag is not specified in mode, the
default behavior is almost same as when this flag is specified. The
only difference is that on
success, the file size will be changed if offset + len is
greater than the file size. This default behavior closely
resembles the behavior of the
posix_fallocate(3) library function, and is intended as a
method of optimally implementing that function.
See, here nothing says to which value file size will be changed. Also,
posix_fallocate man page (which is actually a shortcut to
fallocate(fd, 0, ...)) says:
If the size of the file is less than offset+len, then the file
is increased to this size; otherwise the file size is left unchanged.
Nowhere there it is said that size is ceil()'d to a blocksize.
Moreover, I never saw an app that does fallocate() and then
ftruncate() - every single app out there assumes that posix_fallocate
(and fallocate, fwiw), while may allocate more space, will set the
file size to something different than offset+len.
--
This message represents the official view of the voices in my head
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
