linux-btrfs.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Qu Wenruo <quwenruo@cn.fujitsu.com>
To: btrfs <linux-btrfs@vger.kernel.org>
Subject: [RFC] btrfs-progs: btrfs-corrupt-block refactor
Date: Fri, 20 Jan 2017 10:50:10 +0800	[thread overview]
Message-ID: <2987570c-aeb2-e497-ee9f-c32b8a0fb3ff@cn.fujitsu.com> (raw)

This is the RFC proposal for refactor btrfs-corrupt-block.

Just as Lakshmipathi and xfstests guys commented in btrfs ML, we need 
btrfs-corrupt-block to either craft a test case, or for later RAID56 
corruption test case.

However the current situation of btrfs-corrupt-block has several 
problems, and those problems prevents us from using it:

1) Bad arranged options
    Quite a lot of combination makes no sense.
    And quite a lot of function covers each other.

    This is quite frustrating when someone want to use it.

2) No documentation

3) No longer default installed/compiled
    This is OK if such tool is only used to corrupt things.

    But if the long term objective is to provide a tool to modify the fs
    offline at will, that's not a good idea.


So here I want to refactor the current btrfs-corrupt-block to archive 
the following objective:

1) Logical layer divided parameters  <<MAIN PART>>
    The current idea is like:

    btrfs-corrupt-block <dest> <options>
    <dest> is one of
      "item" "data" "leaf" "node" (with more to come)

    "item"/"leaf"/"node" common options are:
      "--nocow":
         Don't do CoW, but overwrite (default)
      "--cow":
         Do normal tree block CoW
      "--pattern DATA"
         The pattern to fill, default to 0xcd


    "item" options are:
      "--root NUMBER|ROOTID":
         Mandatory
      "--key (OBJID,TYPE,OFFSET)":
         Mandatory
      "--field FIELD"
         Optional, default to corrupt all fields of the item
      "--delete"
         Optional, if specified, the item will be deleted.
         Conflicts with "--field"


    "leaf" options are:
      "--bytenr BYTENR" or "--key" with "--root"
         Mandatory to locate the leaf
      "--field FIELD"
         Optional, default to corrupt all fields of the leaf header
         With --key, can also be used to corrupt certain item field
      NOTE: No delete is provided. Please use "node" "--delete" to
            delete a leaf.
            Or use "--filed ALL" with "--pattern 0x00" to wipe the
            leaf header.

    "node" options are:
      "--bytenr BYTENR" or "--key" "--root" and "--level"
         Mandatory to locate the node
      "--field FIELD"
         Optional, default to corrupt all fields of the node header
         With --key, can also be used to corrupt certain nodeptr filed
      "--delete"
         Optional, Only works with "--key" "--root" "--level".
         Delete the nodeptr.

    "data" options are:
      "--bytenr BYTENR"
         Mandatory, logical address
      "--length LENGTH"
         Optional, default to sectorsize of the fs
      "--mirror"
         Optional, default to all mirror

     May add "raid56" destination for raid56 tests later.

2) Better documentation
    Both asciidoc doc and better help string

3) Better error string
    At least the same level we do in other btrfs commands

Any advice and idea are welcomed.

Thanks,
Qu



             reply	other threads:[~2017-01-20  2:50 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-01-20  2:50 Qu Wenruo [this message]
2017-01-25 20:49 ` [RFC] btrfs-progs: btrfs-corrupt-block refactor Lakshmipathi.G

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=2987570c-aeb2-e497-ee9f-c32b8a0fb3ff@cn.fujitsu.com \
    --to=quwenruo@cn.fujitsu.com \
    --cc=linux-btrfs@vger.kernel.org \
    /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;
as well as URLs for NNTP newsgroup(s).