From patchwork Tue Aug 4 05:52:00 2015 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Qu Wenruo X-Patchwork-Id: 6934081 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.29.136]) by patchwork2.web.kernel.org (Postfix) with ESMTP id 1BDB4C05AC for ; Tue, 4 Aug 2015 05:54:14 +0000 (UTC) Received: from mail.kernel.org (localhost [127.0.0.1]) by mail.kernel.org (Postfix) with ESMTP id 33CFE205F7 for ; Tue, 4 Aug 2015 05:54:13 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 4BD80205D1 for ; Tue, 4 Aug 2015 05:54:12 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1750709AbbHDFyI (ORCPT ); Tue, 4 Aug 2015 01:54:08 -0400 Received: from cn.fujitsu.com ([59.151.112.132]:62333 "EHLO heian.cn.fujitsu.com" rhost-flags-OK-FAIL-OK-FAIL) by vger.kernel.org with ESMTP id S1750795AbbHDFyH (ORCPT ); Tue, 4 Aug 2015 01:54:07 -0400 X-IronPort-AV: E=Sophos;i="5.15,520,1432569600"; d="scan'208";a="99232666" Received: from unknown (HELO edo.cn.fujitsu.com) ([10.167.33.5]) by heian.cn.fujitsu.com with ESMTP; 04 Aug 2015 13:57:32 +0800 Received: from G08CNEXCHPEKD01.g08.fujitsu.local (localhost.localdomain [127.0.0.1]) by edo.cn.fujitsu.com (8.14.3/8.13.1) with ESMTP id t745q8E9009154; Tue, 4 Aug 2015 13:52:08 +0800 Received: from localhost.localdomain (10.167.226.33) by G08CNEXCHPEKD01.g08.fujitsu.local (10.167.33.89) with Microsoft SMTP Server (TLS) id 14.3.181.6; Tue, 4 Aug 2015 13:54:01 +0800 From: Qu Wenruo To: CC: Subject: [PATCH] btrfs-progs: Doc: Add extra notes for qgroup Date: Tue, 4 Aug 2015 13:52:00 +0800 Message-ID: <1438667520-29521-1-git-send-email-quwenruo@cn.fujitsu.com> X-Mailer: git-send-email 2.5.0 MIME-Version: 1.0 X-Originating-IP: [10.167.226.33] Sender: linux-btrfs-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-btrfs@vger.kernel.org X-Spam-Status: No, score=-7.0 required=5.0 tests=BAYES_00, RCVD_IN_DNSWL_HI, RP_MATCHES_RCVD, 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 Add extra explaination on btrfs qgroup on the following two things: 1) Need sync to show accurate qgroup numbers 2) Cow may cause extra quota usage Although btrfs qgroup is still buggy, especially for limit behavior, but some strange behavior is not really a bug. Just add these explaination for end users if they really want to try it. Signed-off-by: Qu Wenruo --- Documentation/btrfs-qgroup.asciidoc | 40 +++++++++++++++++++++++++++++++++++++ 1 file changed, 40 insertions(+) diff --git a/Documentation/btrfs-qgroup.asciidoc b/Documentation/btrfs-qgroup.asciidoc index 57cf012..f2fc514 100644 --- a/Documentation/btrfs-qgroup.asciidoc +++ b/Documentation/btrfs-qgroup.asciidoc @@ -127,6 +127,46 @@ If no prefix is given, use ascending order by default. + If multiple s is given, use comma to separate. +EXTRA NOTES +----------- +1. Need sync before *btrfs qgroup show* command ++ +Sync is needed to output correct numbers, especially after kernel v4.2. + +2. Copy-on-write(CoW) may cause extra space usage ++ +Cow will cause extra space usage, compared to overwrite filesystem, like ext4 +or xfs. ++ +Here is a example, for a file with 12K contents: ++ +-------------------------------------- +File1: +0 4K 8K 12K +|<-------Extent A------>| +-------------------------------------- ++ +It takes 12K space. ++ +But after a rewrite of the 4K in the middle: + ++ +-------------------------------------- +File1: +0 4K 8K 12K +|<-------Extent A------>| + |<--B-->| +-------------------------------------- ++ +New extent B will record the new data, although the original extent A still +exists, until none part of it is referred. + +So in this case, it will take 12 + 4 = 16K, other than 12K as a traditional +filesystem. ++ +The overhead can be reduced by either using *nodatacow* mount option to disable +possible COW or defrag. + +But it won't completely remove the extra space usage when snapshot/subvolume is +involved. + EXIT STATUS ----------- *btrfs qgroup* returns a zero exit status if it succeeds. Non zero is