[prev in list] [next in list] [prev in thread] [next in thread] 

List:       linux-btrfs
Subject:    Re: [PATCH][RFC] btrfs-progs: add 'du' command
From:       David Sterba <dsterba () suse ! cz>
Date:       2015-04-29 17:19:18
Message-ID: 20150429171918.GC4996 () twin ! jikos ! cz
[Download RAW message or body]

On Thu, Apr 23, 2015 at 02:12:06PM -0700, Mark Fasheh wrote:
> This patch adds a 'du' subcommand to btrfs. 'btrfs fi du' will
> calculate disk usage of the target files using fiemap. For individual
> files, it will report a count of total bytes, and exclusive (not
> shared) bytes. We also calculate a 'set shared' value which is
> described below.

The functionality is useful, I personally like it and have seen people
on irc to ask about this.

The question is whether we want to add this to a btrfs command or to the
'du' utility itself. AFAICS it's not built around FIEMAP, so I guess
this would be an intrusive change.

> Following this paragraph is a very simple example. I started with a
> clean btrfs fs in which i copied vmlinuz from /boot. I then made a
> snapshot of the fs root in 'snap1'. After the snapshot, I made a 2nd
> copy of vmlinuz into the main fs to give us some not-shared data. The
> output below shows a sum of all the space, and a 'set shared' with len
> exactly equal to that of the single shared file.
> 
> # btrfs fi du .
> total	exclusive	set shared	filename
> 4362240	0			./vmlinuz-4.0.0-rc7
> 4362240	0			./snap1/vmlinuz-4.0.0-rc7
> 4362240	0			./snap1
> 4362240	4362240			./vmlinuz-4.0.0-rc7.copy
> 13086720	4362240	4362240	.

I guess the next thing people will want to see is the compressed size.

> A git tree of the patches can be found here:
> 
> https://github.com/markfasheh/btrfs-progs-patches/tree/du

The file interval_tree.h seems missing and build fails.
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
[prev in list] [next in list] [prev in thread] [next in thread]