Re: Recent issues with btrfs fi df

Austin S Hemmelgarn <ahferroin7@xxxxxxxxx> · Fri, 05 Dec 2014 07:35:04 -0500

On 2014-12-05 07:19, Austin S Hemmelgarn wrote:
On 2014-12-05 02:42, Satoru Takeuchi wrote:
Hi Austin,

(2014/12/04 23:31), Austin S Hemmelgarn wrote:
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,

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.
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.
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
   - 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
   - .config
I've attached a gzipped copy.
   - Any possible trigger to cause this problem
There aren't any that I know of.
   - Btrfs specific operations, for example weekly btrfs scrub
I run scrub weekly, and balance and fstrim as needed.
   - 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.

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

Attachment:
smime.p7s

Description: S/MIME Cryptographic Signature