linux-btrfs.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Duncan <1i5t5.duncan@cox.net>
To: linux-btrfs@vger.kernel.org
Subject: Re: btrfs fi show
Date: Sat, 16 Nov 2013 22:36:04 +0000 (UTC)	[thread overview]
Message-ID: <pan$bc3ea$b72d6510$8665f627$6082e213@cox.net> (raw)
In-Reply-To: 74A706D5-8983-43D3-A21A-5C577E4ED695@colorremedies.com

Chris Murphy posted on Sat, 16 Nov 2013 14:50:00 -0700 as excerpted:

> On Nov 16, 2013, at 1:33 PM, Duncan <1i5t5.duncan@cox.net> wrote:

>> 1) If you run a generic btrfs filesystem show (without options or
>> path), you *WILL* likely get the same base filesystem listed multiple
>> times, as the default lookup appears to get the info from at least two
>> different places, one appearing right away that only appears to include
>> currently mounted filesystems, then a pause, then a more complete
>> listing that includes currently unmounted btrfs volumes as well.
> 
> Thanks for the explanation. I'm still considering it a bug though.
> Duplicates of the same UUID should be filtered out.

Reasonable point, and I /guess/ (not being a coder) it shouldn't take 
much to do that directly in the btrfs filesystem show code itself.

> In my case, there's no pause. Two identical listings are instantly
> produced for one btrfs volume.

Probably because you just have that one volume, and it's mounted.

I have something like eleven separate btrfs filesystems, mostly two-
component-device raid1 mode btrfs, with some of them being primary 
backups of others and thus not mounted by default, and others being stuff 
like /boot and my packages tree, that are only mounted when I'm doing 
updates.

The mounted ones show up instantly (with dups in at least some cases), 
but then it pauses, presumably because it's scanning and then parsing 
devices and matching up components for each unmounted filesystem before 
displaying it.  But if you had no such unmounted btrfs and/or if they 
were only single device (I'm not sure which bit triggers the pause), 
you'll probably not see the pause I see here.

>> 3) If you use -d, you'll get a different list, based on devices in /dev
>> so it includes unmounted filesystems (and thus the pause), but at least
>> here, this list is BOTH comprehensive AND avoids dups!
> 
> This does show me a single instance of the singular volume I have.

=:^)

If they don't decide to do the filtering, perhaps the current -d can 
become the default.

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman


  reply	other threads:[~2013-11-16 22:36 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-11-16 14:58 btrfs fi show Gene Czarcinski
2013-11-16 16:04 ` Chris Murphy
2013-11-16 20:33   ` Duncan
2013-11-16 21:50     ` Chris Murphy
2013-11-16 22:36       ` Duncan [this message]
2013-11-18  2:17 ` Anand Jain
2013-11-18 19:32   ` Chris Mason

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='pan$bc3ea$b72d6510$8665f627$6082e213@cox.net' \
    --to=1i5t5.duncan@cox.net \
    --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).