From patchwork Fri Dec 5 12:19:28 2014 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: "Austin S. Hemmelgarn" X-Patchwork-Id: 5443491 Return-Path: X-Original-To: patchwork-linux-btrfs@patchwork.kernel.org Delivered-To: patchwork-parsemail@patchwork2.web.kernel.org Received: from mail.kernel.org (mail.kernel.org [198.145.19.201]) by patchwork2.web.kernel.org (Postfix) with ESMTP id 78A75BEEA8 for ; Fri, 5 Dec 2014 12:19:48 +0000 (UTC) Received: from mail.kernel.org (localhost [127.0.0.1]) by mail.kernel.org (Postfix) with ESMTP id 60F332024D for ; Fri, 5 Dec 2014 12:19:47 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id D6632201EC for ; Fri, 5 Dec 2014 12:19:45 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752043AbaLEMTd (ORCPT ); Fri, 5 Dec 2014 07:19:33 -0500 Received: from mail-ig0-f177.google.com ([209.85.213.177]:56785 "EHLO mail-ig0-f177.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750857AbaLEMTd (ORCPT ); Fri, 5 Dec 2014 07:19:33 -0500 Received: by mail-ig0-f177.google.com with SMTP id z20so595239igj.10 for ; Fri, 05 Dec 2014 04:19:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:disposition-notification-to:date:from:user-agent :mime-version:to:cc:subject:references:in-reply-to:openpgp :content-type; bh=yOQRgTUlZZs+eRuESeIAVUytq+6qSE7bHKo1rSSlL2w=; b=GzLacGGyoBg/GwG/iCjVL2lnEgt8ktwAFIUtw48fCKCv4XT5mSSmlVf3ZifF0FIrMX B+JktxtFpgaVkNGg7FWKeO2ISI9N/CYzmkwk8N/k58MdU3F4GT21umpnLjI3Eik30oA/ JIPw8mWnDNJ7yYJ8T+lKqVcGEd5pxWkLGJinAK1JZFDjc5obUMdqZ8iOE4AY16Y6oQh6 E1DT3KYZ2vKfA6vjJUgErwVeBKseFYh3rzrQkHsMV0xvLUkMe45Q89fg6bdosENznU+u oRW5cTWFeWzHcxVfFk3r46KzA7pVxdC4+9tEcG2hu9BOrIaf8BiDOcZO80GWbdDQtY/1 2a9g== X-Received: by 10.50.28.49 with SMTP id y17mr2090009igg.3.1417781972075; Fri, 05 Dec 2014 04:19:32 -0800 (PST) Received: from [191.9.213.7] (rrcs-70-62-41-24.central.biz.rr.com. [70.62.41.24]) by mx.google.com with ESMTPSA id f4sm753028igg.7.2014.12.05.04.19.29 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 05 Dec 2014 04:19:30 -0800 (PST) Message-ID: <5481A2D0.2050203@gmail.com> Date: Fri, 05 Dec 2014 07:19:28 -0500 From: Austin S Hemmelgarn User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: Satoru Takeuchi CC: linux-btrfs Subject: Re: Recent issues with btrfs fi df References: <5480704F.6000302@gmail.com> <548161FE.3030301@jp.fujitsu.com> In-Reply-To: <548161FE.3030301@jp.fujitsu.com> OpenPGP: id=85D2EC0F Sender: linux-btrfs-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-btrfs@vger.kernel.org X-Spam-Status: No, score=-6.8 required=5.0 tests=BAYES_00, DKIM_ADSP_CUSTOM_MED, DKIM_SIGNED, FREEMAIL_FROM, RCVD_IN_DNSWL_HI, T_DKIM_INVALID, T_RP_MATCHES_RCVD, T_TVD_MIME_EPI,UNPARSEABLE_RELAY autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on mail.kernel.org X-Virus-Scanned: ClamAV using ClamSMTP 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 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. > 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. diff -rU3 linux-3.16.3-gentoo/include/uapi/linux/vt.h /usr/src/linux-3.16.3-gentoo/include/uapi/linux/vt.h --- linux-3.16.3-gentoo/include/uapi/linux/vt.h 2014-10-01 14:20:45.855383160 -0400 +++ /usr/src/linux-3.16.3-gentoo/include/uapi/linux/vt.h 2014-08-03 18:25:02.000000000 -0400 @@ -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) */