Re: fallocate fail on btrfs

[Duncan <1i5t5.duncan@cox.net>]

Holger Hoffstätte posted on Wed, 27 Aug 2014 23:33:55 +0000 as excerpted:

> On Wed, 27 Aug 2014 15:58:49 -0700, G. Richard Bellamy wrote:
> 
>> [..snip..]
> 
> I can use fallocate on btrfs as you tried in your first post, with or
> without --keep-size, and it does the right things without errors.
> Running kernel 3.14+ (patched btrfs), util-linux-2.24.2 on Gentoo.
> 
>> There are two things going wrong here.
>> 
>> 1. The "open" command fallocate is using isn't passing along the
>> O_CREAT flag properly.
>> https://git.kernel.org/cgit/utils/util-linux/util-linux.git/tree/sys-
>> utils/fallocate.c#n368

>> CODE: fd = open(filename, O_RDWR | (!dig && !mode ? O_CREAT : 0),
>> 0644);
>> STRACE: open("test.test", O_RDWR) = -1 ENOENT (No such file or
>> directory)
> 
> When you have fallocate.c open in cgit, go to its log and you will find
> a recent commit:
> 
> https://git.kernel.org/cgit/utils/util-linux/util-linux.git/commit/sys-
> utils/fallocate.c?id=575718a04aa0c053875041dc387e360f2dcaa70d
> 
> aka: "fallocate: use O_CREAT only for the default behavior"

>From the getopt_long processing switch/case while earlier in the file, 
lines 319-321:

		case 'n':
			mode |= FALLOC_FL_KEEP_SIZE;
			break;


So mode is set to FALLOC_FL_KEEP_SIZE, the !mode test fails, and O_CREAT 
isn't passed.

Basically, you can't pass --keep-size/-n on a non-existent file; the file 
doesn't exist so there's nothing to keep the size of and the fallocate 
fails.  Based on the commit, that's deliberate.

So the no-existing-file behavior would seem to be NOTABUG.


As for the existing-file case...

>> And the strace of fallocate execution against a zero-length file I
>> created with touch: http://sprunge.us/BRML
>> 
>> You can see in the strace that fallocate thinks it worked (= 0),
>> but here's the file post-execution:
>> 2014-08-27 15:49:45 root@eanna i ~ # ls -alh test.test
>> -rw------- 1 root root 0 Aug 27 15:46 test.test

>From the fallocate manpage:
-n, --keep-size
	Do  not  modify  the  apparent length of the file.  This may
	effectively allocate blocks past EOF, which can be removed with a
	truncate.

Seems to me that's exactly what you're seeing -- allocation BEYOND EOF.  
Try this:

touch test.test
ls -lsh test.test
fallocate -n -l 1024000 test.test
ls -lsh test.test

As described in the ls manpage, -s/--size displays the ALLOCATED size (as 
opposed to the actual file size), and that *DOES* show the expected 
ALLOCATED size change with util-linux-2.25 (and kernel 3.16) for me here, 
tho the file size itself remains zero, as the fallocate manpage suggests 
should indeed be the case if --keep-size was used.

So it looks to me like it's working as it should.

> Seems to me you need to downgrade util-linux and/or complain to the
> util-linux folks. In fact downgrade util-linux first (cfdisk in 2.25
> eats partitions) and try fallocate again on whatever kernel you have
> running, just to rule out btrfs.

On the eats partitions bit, gentoo bug:

https://bugs.gentoo.org/show_bug.cgi?id=520838

Util-linux list thread on gmane, not much there but admitting the issue 
and saying they plan a 2.25.1 ASAP:

http://thread.gmane.org/gmane.linux.utilities.util-linux-ng/9765


As a result, 2.25, which was in ~arch on gentoo, got hard-masked.  Tho 
I've standardized on gpt partitions and use gdisk (cgdisk) instead, so I 
unmasked it again locally and kept it installed.


-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman