Recent issues with btrfs fi df
Subsystems (2)
I've recently noticed on some of my systems, that btrfs fi df doesn't consistently show all of the chunk types. I'll occasionally not see the GlobalReserve, or even anything but System, although the behavior seems to be consistent for a given filesystem. I'm using btrfs-progs 3.17.1 and kernel 3.17.4 with grsecurity patches (although with much of the grsec stuff disabled) on all such systems. I'd be happy to provide kernel .config or other information for debugging on request.
A message that is not in the archive (sent off-list or not yet received): [email protected]
Quoted 8 lines · Satoru Takeuchi
Hi Austin,
Quoted 4 lines · Austin S Hemmelgarn
I've recently noticed on some of my systems, that btrfs fi df doesn't consistently show all of the chunk types. I'll occasionally not see the GlobalReserve, or even anything but System,
Quoted 8 lines
For one Btrfs file system, "how inconsistent" is the same even if time passes? In other word,
a) Once "GlobalReserve" becomes to be not shown, it keep as is after tha, or
b) Oneday "GlobalReserver" disappeared. Howevert it appear again at the next day or so.
In general, once it changes the first time, things don't seem to change again afterwards.
Quoted 8 lines
Quoted 2 lines
although the behavior seems to be consistent for
a given filesystem.Did you confirm the following things for your Btrfs file system?
a) btrfs scrub finishes without any problem, and
b) dmesg doesn't show any suspicious message.
Scrub and dmesg both look fine, I've also run btrfsck in no-op mode and that doesn't report any errors either.
Quoted 8 lines
Quoted 4 lines
I'm using btrfs-progs 3.17.1 and kernel 3.17.4
with grsecurity patches (although with much of the grsec stuff disabled) on all such systems. I'd be happy to provide kernel .config or other information for debugging on request.Could you tell me the following information, if possible?
- mkfs options and mount options
In both cases that I currently have access to, I created the fs with:
mkfs.btrfs -O extref,skinny-metadata,no-holes -F <device-name> and the mount option strings for the devices in question are:
noatime,space_cache,ssd,autodefrag
for /
and:
noatime,sync,nosuid,nodev,noexec,compress=zlib,ssd,space_cache,autodefrag for /boot
Quoted 1 line
- The output of btrfs fi df
For /, I get:
Data, single: total=43.00GiB, used=40.76GiB
System, DUP: total=32.00MiB, used=16.00KiB
Metadata, DUP: total=1.50GiB, used=1.05GiB
For /boot, I get:
System, single: total=32.00MiB, used=4.00KiB
Quoted 1 line
- .config
I've attached a gzipped copy.
Quoted 1 line
- Any possible trigger to cause this problem
There aren't any that I know of.
Quoted 1 line
- Btrfs specific operations, for example weekly btrfs scrub
I run scrub weekly, and balance and fstrim as needed.
Quoted 2 lines
- Do you have any system which works fine and uses a kernel without grsecurity patches?
Yes, although said system has exclusively multi-device filesystems, while the affected one is all single device filesystems.
Quoted 6 lines
In addition, running one of your system with
- upstream kernel without grsecurity, and
- btrfs file system with which btrfs fi df works correctly,
I've got a recovery environment built using buildroot that is based on the same kernel version without grsec patches, I'll reboot into that and see what it says.
Quoted 4 lines
can help to distinguish whether the problem comes from upstream kernel (of course it includes btrfs) or grsecurity. I'm not sure about grsecurity. however, I have encountered many problems caused by security modules.
I do have one other local kernel patch that I use, I've attached that as well, although it should have no effect whatsoever on the fs code.
usr/src/linux-3.16.3-gentoo/include/uapi/linux/vt.h renamed from include/uapi/linux/vt.h +2 -2
@@ -7,8 +7,8 @@* resizing). */ #define MIN_NR_CONSOLES 1/* must be at least 1 */ -#define MAX_NR_CONSOLES 63/* serial lines start at 64 */ -#define MAX_NR_USER_CONSOLES 63/* must be root to allocate above this */ +#define MAX_NR_CONSOLES 15/* serial lines start at 64 */ +#define MAX_NR_USER_CONSOLES 15/* must be root to allocate above this */ /* Note: the ioctl VT_GETSTATE does not work for consoles 16 and higher (since it returns a short) */
Quoted 63 lines · Austin S Hemmelgarn
Quoted 8 lines · Satoru Takeuchi
Hi Austin,
Quoted 4 lines · Austin S Hemmelgarn
I've recently noticed on some of my systems, that btrfs fi df doesn't consistently show all of the chunk types. I'll occasionally not see the GlobalReserve, or even anything but System,
Quoted 8 lines
For one Btrfs file system, "how inconsistent" is the same even if time passes? In other word,
a) Once "GlobalReserve" becomes to be not shown, it keep as is after tha, or
b) Oneday "GlobalReserver" disappeared. Howevert it appear again at the next day or so.In general, once it changes the first time, things don't seem to change again afterwards.
Quoted 8 lines
Quoted 2 lines
although the behavior seems to be consistent for
a given filesystem.Did you confirm the following things for your Btrfs file system?
a) btrfs scrub finishes without any problem, and
b) dmesg doesn't show any suspicious message.Scrub and dmesg both look fine, I've also run btrfsck in no-op mode and that doesn't report any errors either.
Quoted 8 lines
Quoted 4 lines
I'm using btrfs-progs 3.17.1 and kernel 3.17.4
with grsecurity patches (although with much of the grsec stuff disabled) on all such systems. I'd be happy to provide kernel .config or other information for debugging on request.Could you tell me the following information, if possible?
- mkfs options and mount options
In both cases that I currently have access to, I created the fs with:
mkfs.btrfs -O extref,skinny-metadata,no-holes -F <device-name> and the mount option strings for the devices in question are:
noatime,space_cache,ssd,autodefrag
for /
and:
noatime,sync,nosuid,nodev,noexec,compress=zlib,ssd,space_cache,autodefrag for /bootQuoted 1 line
- The output of btrfs fi df
For /, I get:
Data, single: total=43.00GiB, used=40.76GiB System, DUP: total=32.00MiB, used=16.00KiB Metadata, DUP: total=1.50GiB, used=1.05GiB For /boot, I get: System, single: total=32.00MiB, used=4.00KiBQuoted 1 line
- .config
I've attached a gzipped copy.
Quoted 1 line
- Any possible trigger to cause this problem
There aren't any that I know of.
Quoted 1 line
- Btrfs specific operations, for example weekly btrfs scrub
I run scrub weekly, and balance and fstrim as needed.
Quoted 2 lines
- Do you have any system which works fine and uses a kernel without grsecurity patches?
Yes, although said system has exclusively multi-device filesystems, while the affected one is all single device filesystems.
Quoted 1 line
Quoted 8 lines
Quoted 5 lines
In addition, running one of your system with
- upstream kernel without grsecurity, and
- btrfs file system with which btrfs fi df works correctly,I've got a recovery environment built using buildroot that is based on the same kernel version without grsec patches, I'll reboot into that and see what it says.
OK, so it definitely appears to be a kernel issue, as btrfs fi df reports everything correctly when used from the recovery environment, both with the copy of btrfs-progs in the recovery environment, and the copy from the root filesystem of the affected system. I'm going to try to bisect down to what option in my kernel config is actually causing this, although it may be next week before I can actually do so.
Quoted 8 lines
Quoted 4 lines
can help to distinguish whether the problem comes from upstream kernel (of course it includes btrfs) or grsecurity. I'm not sure about grsecurity. however, I have encountered many problems caused by security modules.
I do have one other local kernel patch that I use, I've attached that as well, although it should have no effect whatsoever on the fs code.