public inbox for fstests@vger.kernel.org
 help / color / mirror / Atom feed
From: David Sterba <dsterba@suse.cz>
To: dsterba@suse.cz, Qu Wenruo <quwenruo@cn.fujitsu.com>,
	Liu Bo <bo.li.liu@oracle.com>,
	fstests@vger.kernel.org, linux-btrfs@vger.kernel.org
Subject: Re: [PATCH] fstests: introduce btrfs-map-logical
Date: Wed, 12 Apr 2017 14:52:23 +0200	[thread overview]
Message-ID: <20170412125222.GI4781@twin.jikos.cz> (raw)
In-Reply-To: <20170412123201.GG4781@twin.jikos.cz>

On Wed, Apr 12, 2017 at 02:32:02PM +0200, David Sterba wrote:
> On Wed, Apr 12, 2017 at 09:35:00AM +0800, Qu Wenruo wrote:
> > 
> > 
> > At 04/12/2017 09:27 AM, Liu Bo wrote:
> > > A typical use case of 'btrfs-map-logical' is to translate btrfs logical
> > > address to physical address on each disk.
> > 
> > Could we avoid usage of btrfs-map-logical here?
> 
> Agreed.
> 
> > I understand that we need to do corruption so that we can test if the 
> > repair works, but I'm not sure if the output format will change, or if 
> > the program will get replace by "btrfs inspect-internal" group.
> 
> In the long-term it will be repleaced, but there's no ETA.

Possibly, if fstests maintainer agrees, we can add btrfs-map-logical to
fstests. It's small and uses headers from libbtrfs, so this would become
a new dependency but I believe is still bearable.

I'm not sure if we should export all debuging functionality in 'btrfs'
as this is typically something that a user will never want, not even in
the emergency environments. There's an overlap in the information to be
exported but I'd be more inclined to satisfy user needs than testsuite
needs. So an independent tool would give us more freedom on both sides.

  reply	other threads:[~2017-04-12 12:52 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-04-12  1:27 [PATCH] fstests: introduce btrfs-map-logical Liu Bo
2017-04-12  1:35 ` Qu Wenruo
2017-04-12 12:32   ` David Sterba
2017-04-12 12:52     ` David Sterba [this message]
2017-04-13  0:42       ` Qu Wenruo
2017-04-13  3:40       ` Eryu Guan

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=20170412125222.GI4781@twin.jikos.cz \
    --to=dsterba@suse.cz \
    --cc=bo.li.liu@oracle.com \
    --cc=fstests@vger.kernel.org \
    --cc=linux-btrfs@vger.kernel.org \
    --cc=quwenruo@cn.fujitsu.com \
    /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