From: Goffredo Baroncelli <kreijack@inwind.it>
To: Chris Mason <clm@fb.com>, linux-btrfs <linux-btrfs@vger.kernel.org>
Cc: David Sterba <dsterba@suse.cz>
Subject: Re: New btrfs sub command: btrfs inspect physical-find
Date: Fri, 15 Jul 2016 18:22:05 +0200 [thread overview]
Message-ID: <de79e38e-7d1f-f08a-0b70-c2fb299b5200@inwind.it> (raw)
In-Reply-To: <16994642-2a2f-55fa-c683-7153977f4577@fb.com>
On 2016-07-14 23:45, Chris Mason wrote:
>
>
> On 07/12/2016 05:40 PM, Goffredo Baroncelli wrote:
>> Hi All,
>>
>> the enclosed patch adds a new btrfs sub command: "btrfs inspect
>> physical-find". The aim of this new command is to show the physical
>> placement on the disk of a file. Currently it handles all the
>> profiles (single, dup, raid1/10/5/6). I develop this command in
>> order to show some bug in btrfs RAID5 profile (see next email).
>
> I've done this manually from time to time, and love the idea of
> having a helper for it. Can I talk you into adding a way to save the
> contents of the block without having to use dd? btrfs-map-logical
> does this now, but not via the search ioctl and not by filename.
>
> say:
>
> btrfs inspect physical-find -c <copy number> -o <output file> <filename> offset
I prefer to add another command to do that (like btrfs insp physical-dump). And I will add as constraint like
offset % blocksize == 0
this in order to avoid handling data spread different stripes/chunks.
However <copy number> has different meaning:
single/raid0 -> means nothing
raid1/raid10 -> means the copy #
raid5/raid6 -> could mean the parity: i.e.
-1 -> first parity (raid5/raid6)
-2 -> 2nd parity (raid6 only)
> Looks like you've open coded btrfs_map_logical() below, getting
> output from the search ioctl. Dave might want that in a more
> centralized place.
I will give a look
> Also, please turn:
>
> for(;;) if (foo) { statements }
>
> Into
>
> for(;;) { if (foo) { statements } }
>
> I find that much less error prone.
Ok
>
> -chris
>
BR
G.Baroncelli
--
gpg @keyserver.linux.it: Goffredo Baroncelli <kreijackATinwind.it>
Key fingerprint BBF5 1610 0B64 DAC6 5F7D 17B2 0EDA 9B37 8B82 E0B5
next prev parent reply other threads:[~2016-07-15 16:22 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-07-12 21:40 New btrfs sub command: btrfs inspect physical-find Goffredo Baroncelli
2016-07-14 21:45 ` Chris Mason
2016-07-15 16:22 ` Goffredo Baroncelli [this message]
2016-07-14 23:05 ` Liu Bo
2016-07-15 0:40 ` Liu Bo
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=de79e38e-7d1f-f08a-0b70-c2fb299b5200@inwind.it \
--to=kreijack@inwind.it \
--cc=clm@fb.com \
--cc=dsterba@suse.cz \
--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).