linux-btrfs.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* [RFC] btrfs-progs: btrfs-corrupt-block refactor
@ 2017-01-20  2:50 Qu Wenruo
  2017-01-25 20:49 ` Lakshmipathi.G
  0 siblings, 1 reply; 2+ messages in thread
From: Qu Wenruo @ 2017-01-20  2:50 UTC (permalink / raw)
  To: btrfs

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



^ permalink raw reply	[flat|nested] 2+ messages in thread

* Re: [RFC] btrfs-progs: btrfs-corrupt-block refactor
  2017-01-20  2:50 [RFC] btrfs-progs: btrfs-corrupt-block refactor Qu Wenruo
@ 2017-01-25 20:49 ` Lakshmipathi.G
  0 siblings, 0 replies; 2+ messages in thread
From: Lakshmipathi.G @ 2017-01-25 20:49 UTC (permalink / raw)
  To: Qu Wenruo; +Cc: btrfs

Hi Qu,

I think it will be a good idea to have corruption log. It should take
--log or --verbose

btrfs-corrupt-block --log=/path/to/logfile

it should record original state of target object before the
corruption. For ex: when we try to corrupt nlink field of
/data/file.txt Log should have entries like:

--
Found /data/file.txt with inode:257
Found field:nlink value:1
Corruption done.
--

This will make debugging easier if debug-tree shows same output before
and after the corruption. We can check the logs figure-out whether
corruption exactly happened on specific object/field or not.


>    "data" options are:
>      "--bytenr BYTENR"
>         Mandatory, logical address
>      "--length LENGTH"
>         Optional, default to sectorsize of the fs
>      "--mirror"
>         Optional, default to all mirror
>
--mirror  option  Is this referring to file-data alone?. If so,
including an option to target meta-data from specific mirror will be
helpful.

For example:
Setup: RAID-1 with 3 drives (both data/meta-data mirrored)
Corrupt an inode from drive-2.
Running Btrfs-check figures out drive-1,drive-3 are valid entries and
updates/fixes drive-2 entries.

Something like that possible or i miss understood something?


Cheers.
Lakshmipathi.G

^ permalink raw reply	[flat|nested] 2+ messages in thread

end of thread, other threads:[~2017-01-25 20:50 UTC | newest]

Thread overview: 2+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2017-01-20  2:50 [RFC] btrfs-progs: btrfs-corrupt-block refactor Qu Wenruo
2017-01-25 20:49 ` Lakshmipathi.G

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).