Linux Btrfs filesystem development
 help / color / mirror / Atom feed
From: Miao Xie <miaox@cn.fujitsu.com>
To: Linux Btrfs <linux-btrfs@vger.kernel.org>
Cc: Mark Fasheh <mfasheh@suse.de>
Subject: [PATCH 0/2] do not open the extend inode reference at the beginning
Date: Thu, 11 Apr 2013 18:32:36 +0800	[thread overview]
Message-ID: <51669144.20107@cn.fujitsu.com> (raw)

In most cases, we do not insert so many inode references, so it is
better that we don't set incompat flag -- EXTEND_IREF -- when we
make a fs. Otherwise we can not mount the fs on the old kernel
though there is no extend iref in fact.

And some users may not hope to inserting the extend inode reference
because of the incompatible problem. In this case, we introduce a
mount option named noextiref.

Note, if the extend inode reference function is enabled, we will
fail to mount a fs with this option because there might be some
extend irefs in the fs, we should not close this function.

This patchset is against:
[PATCH 1/2] Btrfs: fix unblocked autodefraggers when remount
[PATCH 2/2] Btrfs: use a lock to protect incompat/compat flag of the super block

Miao Xie (2):
  Btrfs: set the INCOMPAT_EXTENDED_IREF when the extended iref is inserted
  Btrfs: introduce noextiref mount option

 fs/btrfs/ctree.h      |  1 +
 fs/btrfs/disk-io.c    |  9 +++++++++
 fs/btrfs/inode-item.c | 20 ++++++++++----------
 fs/btrfs/super.c      | 41 ++++++++++++++++++++++++++++++++++++++++-
 4 files changed, 60 insertions(+), 11 deletions(-)

-- 
1.8.0.1

             reply	other threads:[~2013-04-11 10:32 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-04-11 10:32 Miao Xie [this message]
2013-04-11 10:33 ` [PATCH 1/2] Btrfs: set the INCOMPAT_EXTENDED_IREF when the extended iref is inserted Miao Xie
2013-04-11 10:35 ` [PATCH 2/2] Btrfs: introduce noextiref mount option Miao Xie
2013-04-11 14:29   ` Jan Schmidt
2013-04-12  4:13     ` Miao Xie
2013-04-12  7:02       ` Jan Schmidt
2013-04-15  2:58         ` Miao Xie
2013-04-15  5:25           ` Jan Schmidt
2013-04-15  5:36             ` Wang Shilong
2013-04-12 17:01   ` Eric Sandeen
2013-04-15 16:59     ` Mark Fasheh
2013-04-15 17:20     ` David Sterba
2013-04-25 11:27       ` Miao Xie

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=51669144.20107@cn.fujitsu.com \
    --to=miaox@cn.fujitsu.com \
    --cc=linux-btrfs@vger.kernel.org \
    --cc=mfasheh@suse.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox