fallocate fail on btrfs

fallocate fail on btrfs

[G. Richard Bellamy]

When I try to run fallocate with "--keep-size" on my btrfs partitions,
it's failing, and I'm at a loss as to why. This was working in prior
versions.

Any suggestions on how to attack this problem? I'm betting I'm missing
something simple here, and have just gone down the rabbit hole...

BTW, I've confirmed that the line that fails is fallocate.c:368 [2],
with "open" always returning -1.

[1]
2014-08-26 21:58:28
root@eanna i /var/lib/libvirt/images # fallocate -n -l 10 test.test
fallocate: cannot open test.test: No such file or directory
zsh: exit 1     fallocate -n -l 10 test.test
2014-08-26 21:58:41
root@eanna i /var/lib/libvirt/images # fallocate -l 10 test.test
2014-08-26 21:58:52
root@eanna i /var/lib/libvirt/images # ls -alh
total 4.0K
drwxr-xr-x 1 root root  18 Aug 26 21:58 .
drwxr-xr-x 1 root root 100 Aug 26 17:39 ..
-rw-r--r-- 1 root root  10 Aug 26 21:58 test.test
2014-08-26 21:58:54
root@eanna i /var/lib/libvirt/images # umask
022
2014-08-26 21:59:03
root@eanna i /var/lib/libvirt/images # umask 000
2014-08-26 21:59:08
root@eanna i /var/lib/libvirt/images # rm test.test
removed ‘test.test’
2014-08-26 21:59:15
root@eanna i /var/lib/libvirt/images # fallocate -n -l 10 test.test
fallocate: cannot open test.test: No such file or directory
zsh: exit 1     fallocate -n -l 10 test.test
2014-08-26 21:59:19
root@eanna i /var/lib/libvirt/images # ls -alh
total 0
drwxr-xr-x 1 root root   0 Aug 26 21:59 .
drwxr-xr-x 1 root root 100 Aug 26 17:39 ..
2014-08-26 21:59:23
root@eanna i /var/lib/libvirt/images #

[2] fd = open(filename, O_RDWR | (!dig && !mode ? O_CREAT : 0), 0644);

Re: fallocate fail on btrfs

[Duncan]

G. Richard Bellamy posted on Tue, 26 Aug 2014 22:05:01 -0700 as excerpted:

> When I try to run fallocate with "--keep-size" on my btrfs partitions,
> it's failing, and I'm at a loss as to why. This was working in prior
> versions.
> 
> Any suggestions on how to attack this problem? I'm betting I'm missing
> something simple here, and have just gone down the rabbit hole...
> 
> BTW, I've confirmed that the line that fails is fallocate.c:368 [2],
> with "open" always returning -1.

One "something simple" you're missing (either that or I am) is any 
reference to which version you're running.  You say it was working in 
prior versions, but /which/ prior versions, and /which/ version doesn't 
work now?

-- 
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

Re: fallocate fail on btrfs

[G. Richard Bellamy]

Good questions, should have included that info in the OP.

The current versions I can get, but I'm frankly terrified to try to
roll back to prior versions to "test" this, since back in that land be
monsters with deadlocks preventing degraded volumes from being fixed
and other challenges I wasn't qualified to fix - and it was over three
months ago that I tried fallocate last. I run Arch and aggressively
update, so I can infer what those version were, and will do so, though
I know that is of limited efficacy in helping you help me...

Best-guess Prior (2014-06-30):
------------------------------------------------
linux-lts 3.10.45-1
btrfs-progs 3.14.2-2
linux 3.15.2-1
util-linux 2.24.2-1

Current (2014-08-27 10:28:07):
-----------
rbellamy@eanna i ~ % pacman -Q linux-lts btrfs-progs-git linux util-linux
linux-lts 3.14.17-1
btrfs-progs-git 3.16_108_d34cbe7-1
linux 3.16.1-1
util-linux 2.25-3

On Tue, Aug 26, 2014 at 11:39 PM, Duncan <1i5t5.duncan@cox.net> wrote:
> G. Richard Bellamy posted on Tue, 26 Aug 2014 22:05:01 -0700 as excerpted:
>
>> When I try to run fallocate with "--keep-size" on my btrfs partitions,
>> it's failing, and I'm at a loss as to why. This was working in prior
>> versions.
>>
>> Any suggestions on how to attack this problem? I'm betting I'm missing
>> something simple here, and have just gone down the rabbit hole...
>>
>> BTW, I've confirmed that the line that fails is fallocate.c:368 [2],
>> with "open" always returning -1.
>
> One "something simple" you're missing (either that or I am) is any
> reference to which version you're running.  You say it was working in
> prior versions, but /which/ prior versions, and /which/ version doesn't
> work now?
>
> --
> 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
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: fallocate fail on btrfs

[G. Richard Bellamy]

Also, here's the strace of the fallocate call:
http://sprunge.us/QXFN

On Wed, Aug 27, 2014 at 10:39 AM, G. Richard Bellamy
<rbellamy@pteradigm.com> wrote:
> Good questions, should have included that info in the OP.
>
> The current versions I can get, but I'm frankly terrified to try to
> roll back to prior versions to "test" this, since back in that land be
> monsters with deadlocks preventing degraded volumes from being fixed
> and other challenges I wasn't qualified to fix - and it was over three
> months ago that I tried fallocate last. I run Arch and aggressively
> update, so I can infer what those version were, and will do so, though
> I know that is of limited efficacy in helping you help me...
>
> Best-guess Prior (2014-06-30):
> ------------------------------------------------
> linux-lts 3.10.45-1
> btrfs-progs 3.14.2-2
> linux 3.15.2-1
> util-linux 2.24.2-1
>
> Current (2014-08-27 10:28:07):
> -----------
> rbellamy@eanna i ~ % pacman -Q linux-lts btrfs-progs-git linux util-linux
> linux-lts 3.14.17-1
> btrfs-progs-git 3.16_108_d34cbe7-1
> linux 3.16.1-1
> util-linux 2.25-3
>
> On Tue, Aug 26, 2014 at 11:39 PM, Duncan <1i5t5.duncan@cox.net> wrote:
>> G. Richard Bellamy posted on Tue, 26 Aug 2014 22:05:01 -0700 as excerpted:
>>
>>> When I try to run fallocate with "--keep-size" on my btrfs partitions,
>>> it's failing, and I'm at a loss as to why. This was working in prior
>>> versions.
>>>
>>> Any suggestions on how to attack this problem? I'm betting I'm missing
>>> something simple here, and have just gone down the rabbit hole...
>>>
>>> BTW, I've confirmed that the line that fails is fallocate.c:368 [2],
>>> with "open" always returning -1.
>>
>> One "something simple" you're missing (either that or I am) is any
>> reference to which version you're running.  You say it was working in
>> prior versions, but /which/ prior versions, and /which/ version doesn't
>> work now?
>>
>> --
>> 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
>>
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
>> the body of a message to majordomo@vger.kernel.org
>> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: fallocate fail on btrfs

[G. Richard Bellamy]

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

On Wed, Aug 27, 2014 at 3:39 PM, G. Richard Bellamy
<rbellamy@pteradigm.com> wrote:
> Also, here's the strace of the fallocate call:
> http://sprunge.us/QXFN
>
> On Wed, Aug 27, 2014 at 10:39 AM, G. Richard Bellamy
> <rbellamy@pteradigm.com> wrote:
>> Good questions, should have included that info in the OP.
>>
>> The current versions I can get, but I'm frankly terrified to try to
>> roll back to prior versions to "test" this, since back in that land be
>> monsters with deadlocks preventing degraded volumes from being fixed
>> and other challenges I wasn't qualified to fix - and it was over three
>> months ago that I tried fallocate last. I run Arch and aggressively
>> update, so I can infer what those version were, and will do so, though
>> I know that is of limited efficacy in helping you help me...
>>
>> Best-guess Prior (2014-06-30):
>> ------------------------------------------------
>> linux-lts 3.10.45-1
>> btrfs-progs 3.14.2-2
>> linux 3.15.2-1
>> util-linux 2.24.2-1
>>
>> Current (2014-08-27 10:28:07):
>> -----------
>> rbellamy@eanna i ~ % pacman -Q linux-lts btrfs-progs-git linux util-linux
>> linux-lts 3.14.17-1
>> btrfs-progs-git 3.16_108_d34cbe7-1
>> linux 3.16.1-1
>> util-linux 2.25-3
>>
>> On Tue, Aug 26, 2014 at 11:39 PM, Duncan <1i5t5.duncan@cox.net> wrote:
>>> G. Richard Bellamy posted on Tue, 26 Aug 2014 22:05:01 -0700 as excerpted:
>>>
>>>> When I try to run fallocate with "--keep-size" on my btrfs partitions,
>>>> it's failing, and I'm at a loss as to why. This was working in prior
>>>> versions.
>>>>
>>>> Any suggestions on how to attack this problem? I'm betting I'm missing
>>>> something simple here, and have just gone down the rabbit hole...
>>>>
>>>> BTW, I've confirmed that the line that fails is fallocate.c:368 [2],
>>>> with "open" always returning -1.
>>>
>>> One "something simple" you're missing (either that or I am) is any
>>> reference to which version you're running.  You say it was working in
>>> prior versions, but /which/ prior versions, and /which/ version doesn't
>>> work now?
>>>
>>> --
>>> 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
>>>
>>> --
>>> To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
>>> the body of a message to majordomo@vger.kernel.org
>>> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: fallocate fail on btrfs

[G. Richard Bellamy]

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)

2. If the file DOES exist, the "fallocate" command used by the
fallocate utility isn't setting the length of the file, even though it
thinks it is.
https://git.kernel.org/cgit/utils/util-linux/util-linux.git/tree/sys-utils/fallocate.c#n113
CODE: error = fallocate(fd, mode, offset, length);
STRACE: fallocate(3, 01, 0, 1024000) = 0

2014-08-27 15:49:45
root@eanna i ~ # ls -alh test.test
-rw------- 1 root root 0 Aug 27 15:46 test.test

Is this a bug, known weirdness that I can correct with a
scrub/check/whatever, or....

Regards,
Richard

On Wed, Aug 27, 2014 at 3:51 PM, G. Richard Bellamy
<rbellamy@pteradigm.com> wrote:
> 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
>
> On Wed, Aug 27, 2014 at 3:39 PM, G. Richard Bellamy
> <rbellamy@pteradigm.com> wrote:
>> Also, here's the strace of the fallocate call:
>> http://sprunge.us/QXFN
>>
>> On Wed, Aug 27, 2014 at 10:39 AM, G. Richard Bellamy
>> <rbellamy@pteradigm.com> wrote:
>>> Good questions, should have included that info in the OP.
>>>
>>> The current versions I can get, but I'm frankly terrified to try to
>>> roll back to prior versions to "test" this, since back in that land be
>>> monsters with deadlocks preventing degraded volumes from being fixed
>>> and other challenges I wasn't qualified to fix - and it was over three
>>> months ago that I tried fallocate last. I run Arch and aggressively
>>> update, so I can infer what those version were, and will do so, though
>>> I know that is of limited efficacy in helping you help me...
>>>
>>> Best-guess Prior (2014-06-30):
>>> ------------------------------------------------
>>> linux-lts 3.10.45-1
>>> btrfs-progs 3.14.2-2
>>> linux 3.15.2-1
>>> util-linux 2.24.2-1
>>>
>>> Current (2014-08-27 10:28:07):
>>> -----------
>>> rbellamy@eanna i ~ % pacman -Q linux-lts btrfs-progs-git linux util-linux
>>> linux-lts 3.14.17-1
>>> btrfs-progs-git 3.16_108_d34cbe7-1
>>> linux 3.16.1-1
>>> util-linux 2.25-3
>>>
>>> On Tue, Aug 26, 2014 at 11:39 PM, Duncan <1i5t5.duncan@cox.net> wrote:
>>>> G. Richard Bellamy posted on Tue, 26 Aug 2014 22:05:01 -0700 as excerpted:
>>>>
>>>>> When I try to run fallocate with "--keep-size" on my btrfs partitions,
>>>>> it's failing, and I'm at a loss as to why. This was working in prior
>>>>> versions.
>>>>>
>>>>> Any suggestions on how to attack this problem? I'm betting I'm missing
>>>>> something simple here, and have just gone down the rabbit hole...
>>>>>
>>>>> BTW, I've confirmed that the line that fails is fallocate.c:368 [2],
>>>>> with "open" always returning -1.
>>>>
>>>> One "something simple" you're missing (either that or I am) is any
>>>> reference to which version you're running.  You say it was working in
>>>> prior versions, but /which/ prior versions, and /which/ version doesn't
>>>> work now?
>>>>
>>>> --
>>>> 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
>>>>
>>>> --
>>>> To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
>>>> the body of a message to majordomo@vger.kernel.org
>>>> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: fallocate fail on btrfs

[Holger Hoffstätte]

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"

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.

-h

Re: fallocate fail on btrfs

[Duncan]

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

Re: fallocate fail on btrfs

[G. Richard Bellamy]

On Thu, Aug 28, 2014 at 2:12 AM, Duncan <1i5t5.duncan@cox.net> wrote:
> 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.

The incantation I was using is from a bug report comment:
https://bugzilla.redhat.com/show_bug.cgi?id=689127#c24

And yeah, I misread the !mode test, so the code is behaving as designed.

My biggest crime, and wow what a doozy, is that I didn't read the
frickin comment in the code. YOU KNOW, the one where it explains the
new O_CREAT behavior? Those are hours I'm never going to get back, and
it's because I, once again, wasn't paying attention.

Now, whether you can pass --keep-size/-n on a non-existent file, you
could in the past.

>
>
> 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.

School is in again... and my goodness I learned a lot in this go-around.

>
>> 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.

I now use gdisk (cgdisk) when working with partitions - but in fact,
did get bit by it recently.

Duncan & Holger - I owe you both a beer!

-rb

Re: fallocate fail on btrfs

[Duncan]

G. Richard Bellamy posted on Thu, 28 Aug 2014 07:48:04 -0700 as excerpted:

> School is in again... and my goodness I learned a lot in this go-around.

Don't worry, I did too. =:^)  I consider myself an admin (as I believe 
everyone should who administrates their own systems, it's a big 
responsibility!) not a coder, and tho I can and do read/modify/create an 
occasional patch, I don't claim to do C/C++ code either.  So I rarely 
actually look at sources.

But I'm finding more sources make sense when I do, and Holger's post 
along with your straces was enough to get me digging in to see what's 
actually going on here, and that was quite enlightening on its own.  
Besides looking at code and actually finding I could make sense of it, I 
now understand a bit more of the dynamics of file size vs allocated 
size.  I had no idea it was possible to fallocate beyond EOF like that, 
and simply reading the manpage wouldn't have gotten the point across 
NEARLY as well as actually seeing the change in ls -s, contrasted with 
the file size itself staying the same, as it did here.  That's some 
potentially rather useful information I have safely tucked under my belt 
for future interpretation of "strange" filesize results, now, and it's 
all due to your posts along with Holger's reply, stimulating my own 
investigation. =:^)

-- 
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