From patchwork Tue Jan 29 10:05:05 2013 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Miao Xie X-Patchwork-Id: 2060761 Return-Path: X-Original-To: patchwork-linux-btrfs@patchwork.kernel.org Delivered-To: patchwork-process-083081@patchwork1.kernel.org Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by patchwork1.kernel.org (Postfix) with ESMTP id CAAF33FDD1 for ; Tue, 29 Jan 2013 10:04:30 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751675Ab3A2KE2 (ORCPT ); Tue, 29 Jan 2013 05:04:28 -0500 Received: from cn.fujitsu.com ([222.73.24.84]:58919 "EHLO song.cn.fujitsu.com" rhost-flags-OK-FAIL-OK-OK) by vger.kernel.org with ESMTP id S1751518Ab3A2KE0 (ORCPT ); Tue, 29 Jan 2013 05:04:26 -0500 X-IronPort-AV: E=Sophos;i="4.84,559,1355068800"; d="scan'208";a="6660390" Received: from unknown (HELO tang.cn.fujitsu.com) ([10.167.250.3]) by song.cn.fujitsu.com with ESMTP; 29 Jan 2013 18:02:15 +0800 Received: from fnstmail02.fnst.cn.fujitsu.com (tang.cn.fujitsu.com [127.0.0.1]) by tang.cn.fujitsu.com (8.14.3/8.13.1) with ESMTP id r0TA4OY2020348 for ; Tue, 29 Jan 2013 18:04:24 +0800 Received: from [10.167.225.199] ([10.167.225.199]) by fnstmail02.fnst.cn.fujitsu.com (Lotus Domino Release 8.5.3) with ESMTP id 2013012918031972-136991 ; Tue, 29 Jan 2013 18:03:19 +0800 Message-ID: <51079ED1.1020609@cn.fujitsu.com> Date: Tue, 29 Jan 2013 18:05:05 +0800 From: Miao Xie Reply-To: miaox@cn.fujitsu.com User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130110 Thunderbird/17.0.2 MIME-Version: 1.0 To: Linux Btrfs Subject: [PATCH V2 04/10] Btrfs: add a comment for fs_info->max_inline References: <51079D72.7000301@cn.fujitsu.com> In-Reply-To: <51079D72.7000301@cn.fujitsu.com> X-MIMETrack: Itemize by SMTP Server on mailserver/fnst(Release 8.5.3|September 15, 2011) at 2013/01/29 18:03:19, Serialize by Router on mailserver/fnst(Release 8.5.3|September 15, 2011) at 2013/01/29 18:03:19, Serialize complete at 2013/01/29 18:03:19 Sender: linux-btrfs-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-btrfs@vger.kernel.org Though ->max_inline is a 64bit variant, and may be accessed by multi-task, but it is just suggestive number, so we needn't add anything to protect fs_info->max_inline, just add a comment to explain wny we don't use a lock to protect it. Signed-off-by: Miao Xie --- Changelog v1 -> v2: - modify the changelog and make it more clear. --- fs/btrfs/ctree.h | 6 ++++++ 1 file changed, 6 insertions(+) diff --git a/fs/btrfs/ctree.h b/fs/btrfs/ctree.h index 745e7ad..3e672916 100644 --- a/fs/btrfs/ctree.h +++ b/fs/btrfs/ctree.h @@ -1288,6 +1288,12 @@ struct btrfs_fs_info { atomic64_t last_trans_log_full_commit; unsigned long mount_opt; unsigned long compress_type:4; + /* + * It is a suggestive number, the read side is safe even it gets a + * wrong number because we will write out the data into a regular + * extent. The write side(mount/remount) is under ->s_umount lock, + * so it is also safe. + */ u64 max_inline; u64 alloc_start; struct btrfs_transaction *running_transaction;