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