From patchwork Thu Jan 10 12:46:43 2013 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Miao Xie X-Patchwork-Id: 1960051 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 BA31B3FC85 for ; Thu, 10 Jan 2013 12:46:11 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754479Ab3AJMqI (ORCPT ); Thu, 10 Jan 2013 07:46:08 -0500 Received: from cn.fujitsu.com ([222.73.24.84]:54594 "EHLO song.cn.fujitsu.com" rhost-flags-OK-FAIL-OK-OK) by vger.kernel.org with ESMTP id S1753785Ab3AJMqH (ORCPT ); Thu, 10 Jan 2013 07:46:07 -0500 X-IronPort-AV: E=Sophos;i="4.84,444,1355068800"; d="scan'208";a="6560129" Received: from unknown (HELO tang.cn.fujitsu.com) ([10.167.250.3]) by song.cn.fujitsu.com with ESMTP; 10 Jan 2013 20:44:03 +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 r0ACk5DP022071 for ; Thu, 10 Jan 2013 20:46:05 +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 2013011020453065-838658 ; Thu, 10 Jan 2013 20:45:30 +0800 Message-ID: <50EEB833.4040708@cn.fujitsu.com> Date: Thu, 10 Jan 2013 20:46:43 +0800 From: Miao Xie Reply-To: miaox@cn.fujitsu.com User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: Linux Btrfs Subject: [PATCH 04/11] Btrfs: add a comment for fs_info->max_inline X-MIMETrack: Itemize by SMTP Server on mailserver/fnst(Release 8.5.3|September 15, 2011) at 2013/01/10 20:45:30, Serialize by Router on mailserver/fnst(Release 8.5.3|September 15, 2011) at 2013/01/10 20:45:30, Serialize complete at 2013/01/10 20:45:30 Sender: linux-btrfs-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-btrfs@vger.kernel.org We need not add anything to protect fs_info->max_inline, but we need a comment to explain why we don't add a lock to protect it. Signed-off-by: Miao Xie --- 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;