All of lore.kernel.org
 help / color / mirror / Atom feed
From: Hugo Mills <hugo@carfax.org.uk>
To: "Holger Hoffstätte" <holger@applied-asynchrony.com>
Cc: Wang Shilong <wangshilong1991@gmail.com>,
	linux-btrfs <linux-btrfs@vger.kernel.org>,
	David Sterba <dsterba@suse.cz>
Subject: Re: [PATCH] btrfs-progs: du: fix to skip not btrfs dir/file
Date: Wed, 6 Jul 2016 15:56:33 +0000	[thread overview]
Message-ID: <20160706155633.GN10223@carfax.org.uk> (raw)
In-Reply-To: <577D26E9.50607@applied-asynchrony.com>

[-- Attachment #1: Type: text/plain, Size: 4315 bytes --]

On Wed, Jul 06, 2016 at 05:42:33PM +0200, Holger Hoffstätte wrote:
> On 07/06/16 17:20, Hugo Mills wrote:
> > On Thu, Jul 07, 2016 at 12:16:01AM +0900, Wang Shilong wrote:
> >> On Wed, Jul 6, 2016 at 10:35 PM, Holger Hoffstätte
> >> <holger@applied-asynchrony.com> wrote:
> >>> On 07/06/16 14:25, Wang Shilong wrote:
> >>>> 'btrfs file du' is a very useful tool to watch my system
> >>>> file usage with snapshot aware.
> >>>>
> >>>> when trying to run following commands:
> >>>> [root@localhost btrfs-progs]# btrfs file du /
> >>>>      Total   Exclusive  Set shared  Filename
> >>>> ERROR: Failed to lookup root id - Inappropriate ioctl for device
> >>>> ERROR: cannot check space of '/': Unknown error -1
> >>>>
> >>>> and My Filesystem looks like this:
> >>>> [root@localhost btrfs-progs]# df -Th
> >>>> Filesystem     Type      Size  Used Avail Use% Mounted on
> >>>> devtmpfs       devtmpfs   16G     0   16G   0% /dev
> >>>> tmpfs          tmpfs      16G  368K   16G   1% /dev/shm
> >>>> tmpfs          tmpfs      16G  1.4M   16G   1% /run
> >>>> tmpfs          tmpfs      16G     0   16G   0% /sys/fs/cgroup
> >>>> /dev/sda3      btrfs      60G   19G   40G  33% /
> >>>> tmpfs          tmpfs      16G  332K   16G   1% /tmp
> >>>> /dev/sdc       btrfs     2.8T  166G  1.7T   9% /data
> >>>> /dev/sda2      xfs       2.0G  452M  1.6G  23% /boot
> >>>> /dev/sda1      vfat      1.9G   11M  1.9G   1% /boot/efi
> >>>> tmpfs          tmpfs     3.2G   24K  3.2G   1% /run/user/1000
> >>>>
> >>>> So I installed Btrfs as my root partition, but boot partition
> >>>> can be other fs.
> >>>>
> >>>> We can Let btrfs tool aware of this is not a btrfs file or
> >>>> directory and skip those files, so that someone like me
> >>>> could just run 'btrfs file du /' to scan all btrfs filesystems.
> >>>>
> >>>> After patch, it will look like:
> >>>>    Total   Exclusive  Set shared  Filename
> >>>> skipping not btrfs dir/file: boot
> >>>> skipping not btrfs dir/file: dev
> >>>> skipping not btrfs dir/file: proc
> >>>> skipping not btrfs dir/file: run
> >>>> skipping not btrfs dir/file: sys
> >>>>      0.00B       0.00B           -  //root/.bash_logout
> >>>>      0.00B       0.00B           -  //root/.bash_profile
> >>>>      0.00B       0.00B           -  //root/.bashrc
> >>>>      0.00B       0.00B           -  //root/.cshrc
> >>>>      0.00B       0.00B           -  //root/.tcshrc
> >>>>
> >>>> This works for me to analysis system usage and analysis
> >>>> performaces.
> >>>
> >>> This is great, but can we please skip the "skipping .." messages?
> >>> Maybe it's just me but I really don't see the value of printing them
> >>> when they don't contribute to the result.
> >>> They also mess up the display. :)
> >>
> >> I don't have a taste whether it needed or not, because it is somehow
> >> useful to let users know some files/directories skipped....
> 
> When you run "find /path -type d" you don't get messages for all the
> things you just didn't want to find either.

   No, but you do get messages about unreadable directories from find.

   Your example above would be "You asked for X and <thing> isn't an
X". That's not what these messages are about -- what we're seeing here
is "I tried to do what you asked to <thing>, but couldn't".

   Hugo.

> >    At the absolute minimum, I think that these messages should go to
> > stderr (like du does when it deosn't have permissions), and should go
> > away with -q. They're still irritating, but at least you can get rid
> > of them easily.
> 
> If anything this should require a --verbose, not the other way
> around. Maybe instead of breaking the output just indicate the
> special status via "-- --" values, or default to 0.00?
> Still, we're explicitly only interested in btrfs stuff and not
> anything else, so printing non-information can only yield noise.
> 
> This is very much orthogonal to not printing anything after an
> otherwise successful command execution.
> 
> -h
> 
> 




-- 
Hugo Mills             | "There's a Martian war machine outside -- they want
hugo@... carfax.org.uk | to talk to you about a cure for the common cold."
http://carfax.org.uk/  |
PGP: E2AB1DE4          |                           Stephen Franklin, Babylon 5

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

  reply	other threads:[~2016-07-06 16:32 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-07-06 12:25 [PATCH] btrfs-progs: du: fix to skip not btrfs dir/file Wang Shilong
2016-07-06 13:35 ` Holger Hoffstätte
2016-07-06 15:16   ` Wang Shilong
2016-07-06 15:20     ` Hugo Mills
2016-07-06 15:42       ` Holger Hoffstätte
2016-07-06 15:56         ` Hugo Mills [this message]
2016-07-11 10:20         ` David Sterba
2016-07-07  2:43   ` Eric Sandeen

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=20160706155633.GN10223@carfax.org.uk \
    --to=hugo@carfax.org.uk \
    --cc=dsterba@suse.cz \
    --cc=holger@applied-asynchrony.com \
    --cc=linux-btrfs@vger.kernel.org \
    --cc=wangshilong1991@gmail.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.