Hi Chris,
this serie of patches updated the command "btrfs filesystem
df". I update this command because it is not so easy to get
the information about the disk usage from the command "fi df" and
"fi show".
This patch was the result of some discussions on the btrfs
mailing list. Many thanks to all the contributors.
From the man page (see 2nd patch):
[...]
The command btrfs filesystem df is used to query the
status of the chunks, how many space on the disk(s) are used by
the chunks, how many space are available in the chunks, and an
estimation of the free space of the filesystem.
[...]
$ ./btrfs filesystem df --help
usage: btrfs filesystem disk-usage [-k] <path> [<path>..]
Show space usage information for a mount point(s).
-k Set KB (1024 bytes) as unit
$ ./btrfs filesystem df /
Path: /
Summary:
Disk_size: 72.57GB
Disk_allocated: 25.10GB
Disk_unallocated: 47.48GB
Logical_size: 23.06GB
Used: 11.01GB
Free_(Estimated): 55.66GB (Max: 59.52GB, Min: 35.78GB)
Data_to_disk_ratio: 92 %
Details:
Chunk_type Mode Size_(disk) Size_(logical) Used
Data Single 21.01GB 21.01GB 10.34GB
System DUP 80.00MB 40.00MB 4.00KB
System Single 4.00MB 4.00MB 0.00
Metadata DUP 4.00GB 2.00GB 686.93MB
Metadata Single 8.00MB 8.00MB 0.00
Where:
Disk_size -> sum of sizes of teh disks
Disk_allocated -> sum of chunk sizes
Disk_unallocated -> Disk_size - Disk_allocated
Logical_size -> sum of logical area sizes
Used -> logical area used
Free_(Estimated) -> on the basis of allocated
chunk, an estrapolation of
the free space
Data_to_disk_ratio -> ration between the space occuped
by a chunk and the real space
available ( due to duplication
and/or RAID level)
Chunk_type -> kind of chunk
Mode -> allocation policy of a chunk
Size_(disk) -> area of disk(s) occuped by the
chunk (see it as raw space used)
Size_(logical) -> logical area size of the chunk
Used -> portion of the logical area
used by the filesystem
You can pull this change from
http://cassiopea.homelinux.net/git/btrfs-progs-unstable.git
branch
disk_free
Please pull.
BR
Goffredo Baroncelli
Changelog:
V0->V1 Change the name of command from disk-usage to df
V1->V2 Uses getopt(); replace "-" with "_";
change the behaviour
of the switches ''-s'' and
''-d''.
V2->V3 Removed the options ''-s'' and
''-d''; replaced Chunk-size
and Logical-size with Size_(disk) and Size_(logical).
Update the man page.
--
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
From: Goffredo Baroncelli <kreijack@inwind.it>
The command btrfs filesystem df is used to query the
status of the chunks, how many space on the disk(s) are used by
the chunks, how many space are available in the chunks, and an
estimation of the free space of the filesystem.
---
cmds-filesystem.c | 270 +++++++++++++++++++++++++++++++++++++++++++----------
1 file changed, 221 insertions(+), 49 deletions(-)
diff --git a/cmds-filesystem.c b/cmds-filesystem.c
index b1457de..2e2b4b6 100644
--- a/cmds-filesystem.c
+++ b/cmds-filesystem.c
@@ -22,6 +22,7 @@
#include <errno.h>
#include <uuid/uuid.h>
#include <ctype.h>
+#include <sys/vfs.h>
#include "kerncompat.h"
#include "ctree.h"
@@ -39,25 +40,55 @@ static const char * const filesystem_cmd_group_usage[] = {
NULL
};
-static const char * const cmd_df_usage[] = {
- "btrfs filesystem df <path>",
- "Show space usage information for a mount point",
- NULL
-};
+static u64 disk_size( char *path){
+ struct statfs sfs;
+
+ if( statfs(path, &sfs) < 0 )
+ return 0;
+ else
+ return sfs.f_bsize * sfs.f_blocks;
-static int cmd_df(int argc, char **argv)
+}
+
+static void print_string(char *s, int w)
+{
+ int i;
+
+ printf("%s", s);
+ for( i = strlen(s) ; i < w ; i++ )
+ putchar('' '');
+}
+
+#define DF_SHOW_SUMMARY (1<<1)
+#define DF_SHOW_DETAIL (1<<2)
+#define DF_HUMAN_UNIT (1<<3)
+
+static void pretty_sizes_r(u64 size, int w, int mode)
+{
+ if( mode & DF_HUMAN_UNIT ){
+ char *s = pretty_sizes(size);
+ printf("%*s", w, s);
+ free(s);
+ } else {
+ printf("%*llu", w, size/1024);
+
+ }
+}
+
+static int _cmd_disk_free(char *path, int mode)
{
struct btrfs_ioctl_space_args *sargs;
u64 count = 0, i;
int ret;
int fd;
- int e;
- char *path;
-
- if (check_argc_exact(argc, 2))
- usage(cmd_df_usage);
-
- path = argv[1];
+ int e, width;
+ u64 total_disk; /* filesystem size == sum of
+ disks sizes */
+ u64 total_chunks; /* sum of chunks sizes on disk(s) */
+ u64 total_used; /* logical space used */
+ u64 total_free; /* logical space un-used */
+ double K;
+
fd = open_file_or_dir(path);
if (fd < 0) {
@@ -103,56 +134,197 @@ static int cmd_df(int argc, char **argv)
return ret;
}
- for (i = 0; i < sargs->total_spaces; i++) {
- char description[80];
- char *total_bytes;
- char *used_bytes;
- int written = 0;
- u64 flags = sargs->spaces[i].flags;
+ total_disk = disk_size(path);
+ e = errno;
+ if( total_disk == 0 ){
+ fprintf(stderr, "ERROR: couldn''t get space info on
''%s'' - %s\n",
+ path, strerror(e));
+ close(fd);
+ free(sargs);
+ return 19;
+ }
+
+ total_chunks = total_used = total_free = 0;
- memset(description, 0, 80);
+ for (i = 0; i < sargs->total_spaces; i++) {
+ int ratio=1;
+ u64 allocated;
- if (flags & BTRFS_BLOCK_GROUP_DATA) {
- if (flags & BTRFS_BLOCK_GROUP_METADATA) {
- snprintf(description, 14, "%s",
- "Data+Metadata");
- written += 13;
- } else {
- snprintf(description, 5, "%s", "Data");
- written += 4;
- }
- } else if (flags & BTRFS_BLOCK_GROUP_SYSTEM) {
- snprintf(description, 7, "%s", "System");
- written += 6;
- } else if (flags & BTRFS_BLOCK_GROUP_METADATA) {
- snprintf(description, 9, "%s", "Metadata");
- written += 8;
- }
+ u64 flags = sargs->spaces[i].flags;
if (flags & BTRFS_BLOCK_GROUP_RAID0) {
- snprintf(description+written, 8, "%s", ", RAID0");
- written += 7;
+ ratio=1;
} else if (flags & BTRFS_BLOCK_GROUP_RAID1) {
- snprintf(description+written, 8, "%s", ", RAID1");
- written += 7;
+ ratio=2;
} else if (flags & BTRFS_BLOCK_GROUP_DUP) {
- snprintf(description+written, 6, "%s", ", DUP");
- written += 5;
+ ratio=2;
} else if (flags & BTRFS_BLOCK_GROUP_RAID10) {
- snprintf(description+written, 9, "%s", ", RAID10");
- written += 8;
+ ratio=2;
+ } else {
+ ratio=1;
}
- total_bytes = pretty_sizes(sargs->spaces[i].total_bytes);
- used_bytes = pretty_sizes(sargs->spaces[i].used_bytes);
- printf("%s: total=%s, used=%s\n", description, total_bytes,
- used_bytes);
+ allocated = sargs->spaces[i].total_bytes * ratio;
+
+ total_chunks += allocated;
+ total_used += sargs->spaces[i].used_bytes;
+ total_free += (sargs->spaces[i].total_bytes -
+ sargs->spaces[i].used_bytes);
+
+ }
+ K = ((double)total_used + (double)total_free) /
+ (double)total_chunks;
+
+ if( mode & DF_HUMAN_UNIT )
+ width = 12;
+ else
+ width = 18;
+
+ printf("Path: %s\n", path);
+ if( mode & DF_SHOW_SUMMARY ){
+ printf("Summary:\n");
+ printf(" Disk_size:\t\t");
+ pretty_sizes_r(total_disk, width, mode);
+ printf("\n Disk_allocated:\t");
+ pretty_sizes_r(total_chunks, width, mode);
+ printf("\n Disk_unallocated:\t");
+ pretty_sizes_r(total_disk-total_chunks, width, mode);
+ printf("\n Logical_size:\t\t");
+ pretty_sizes_r(total_used+total_free, width, mode);
+ printf("\n Used:\t\t\t");
+ pretty_sizes_r(total_used, width, mode);
+ printf("\n Free_(Estimated):\t");
+ pretty_sizes_r((u64)(K*total_disk-total_used), width, mode);
+ printf("\t(Max: ");
+ pretty_sizes_r(total_disk-total_chunks+total_free,
+ 0, mode );
+ printf(", Min: ");
+ pretty_sizes_r((total_disk-total_chunks)/2+total_free,
+ 0, mode );
+ printf(")\n Data_to_disk_ratio:\t%*.0f %%\n",
+ width-2, K*100);
+ }
+
+ if( ( mode & DF_SHOW_DETAIL ) && ( mode & DF_SHOW_SUMMARY ) )
+ printf("\n");
+
+ if( mode & DF_SHOW_DETAIL ){
+ /* Remember: the terminals have maximum 80 columns
+ do not believe to who says otherwise */
+ printf("Details:\n");
+ printf(" %-12s%-8s%*s%*s%*s\n",
+ "Chunk_type",
+ "Mode",
+ width, "Size_(disk)",
+ width+3, "Size_(logical)",
+ width-3, "Used"
+ );
+
+ for (i = 0; i < sargs->total_spaces; i++) {
+ char *description="";
+ int ratio=1;
+ char *r_mode;
+ u64 allocated;
+
+ u64 flags = sargs->spaces[i].flags;
+
+ if (flags & BTRFS_BLOCK_GROUP_DATA) {
+ if (flags & BTRFS_BLOCK_GROUP_METADATA){
+ description = "Data+M.data";
+ } else {
+ description = "Data";
+ }
+ } else if (flags & BTRFS_BLOCK_GROUP_SYSTEM) {
+ description = "System";
+ } else if (flags & BTRFS_BLOCK_GROUP_METADATA) {
+ description = "Metadata";
+ }
+
+ if (flags & BTRFS_BLOCK_GROUP_RAID0) {
+ r_mode = "RAID0";
+ ratio=1;
+ } else if (flags & BTRFS_BLOCK_GROUP_RAID1) {
+ r_mode = "RAID1";
+ ratio=2;
+ } else if (flags & BTRFS_BLOCK_GROUP_DUP) {
+ r_mode = "DUP";
+ ratio=2;
+ } else if (flags & BTRFS_BLOCK_GROUP_RAID10) {
+ r_mode = "RAID10";
+ ratio=2;
+ } else {
+ r_mode = "Single";
+ ratio=1;
+ }
+
+ allocated = sargs->spaces[i].total_bytes * ratio;
+
+ printf(" ");
+ print_string(description,12);
+ print_string(r_mode, 8);
+ pretty_sizes_r(allocated, width, mode);
+ pretty_sizes_r(sargs->spaces[i].total_bytes ,
+ width, mode);
+
+ pretty_sizes_r(sargs->spaces[i].used_bytes,
+ width, mode);
+ printf("\n");
+
+ }
}
free(sargs);
return 0;
}
+static const char * const cmd_disk_free_usage[] = {
+ "btrfs filesystem df [-k] <path> [<path>..]",
+ "Show space usage information for a mount point(s).",
+ "",
+ "-k\tSet KB (1024 bytes) as unit",
+ NULL
+};
+
+static int cmd_disk_free(int argc, char **argv)
+{
+
+ int flags=DF_SHOW_SUMMARY|DF_SHOW_DETAIL|DF_HUMAN_UNIT;
+ int i, more_than_one=0;
+
+ optind = 1;
+ while(1){
+ char c = getopt(argc, argv, "dsk");
+ if(c<0)
+ break;
+ switch(c){
+ case ''k'':
+ flags &= ~DF_HUMAN_UNIT;
+ break;
+ default:
+ usage(cmd_disk_free_usage);
+ }
+ }
+
+ if (check_argc_min(argc - optind, 1)){
+ usage(cmd_disk_free_usage);
+ return 21;
+ }
+
+ for(i=optind; i< argc ; i++){
+ int r;
+ if(more_than_one)
+ printf("\n");
+ r = _cmd_disk_free(argv[i], flags);
+ if( r ) return r;
+ more_than_one=1;
+
+ }
+
+ return 0;
+}
+
+
+
static int uuid_search(struct btrfs_fs_devices *fs_devices, char *search)
{
char uuidbuf[37];
@@ -529,7 +701,7 @@ static int cmd_label(int argc, char **argv)
const struct cmd_group filesystem_cmd_group = {
filesystem_cmd_group_usage, NULL, {
- { "df", cmd_df, cmd_df_usage, NULL, 0 },
+ { "df", cmd_disk_free, cmd_disk_free_usage, NULL, 0 },
{ "show", cmd_show, cmd_show_usage, NULL, 0 },
{ "sync", cmd_sync, cmd_sync_usage, NULL, 0 },
{ "defragment", cmd_defrag, cmd_defrag_usage, NULL, 0 },
--
1.7.10.4
--
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
From: Goffredo Baroncelli <kreijack@inwind.it> --- man/btrfs.8.in | 100 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 100 insertions(+) diff --git a/man/btrfs.8.in b/man/btrfs.8.in index 4b0a9f9..96c9239 100644 --- a/man/btrfs.8.in +++ b/man/btrfs.8.in @@ -27,6 +27,8 @@ btrfs \- control a btrfs filesystem .PP \fBbtrfs\fP \fBfilesystem label\fP\fI <dev> [newlabel]\fP .PP +\fBbtrfs\fP \fBfilesystem df\fP\fI [-k] \fIpath [path..]\fR\fP +.PP \fBbtrfs\fP \fBsubvolume find-new\fP\fI <subvolume> <last_gen>\fP .PP \fBbtrfs\fP \fBfilesystem balance\fP\fI <path> \fP @@ -214,6 +216,104 @@ NOTE: Currently there are the following limitations: - the filesystem should not have more than one device. .TP +\fBfilesystem df\fP [-k] \fIpath [path..]\fR + +Show space usage information for a mount point. + +\fIOptions\fP + +\fB-k\fP Set KB (1024 bytes) as unit + +\fIUsage information\fP + +.\" +.\" this section is extract from +.\" http://en.wikipedia.org/wiki/Btrfs#Chunk_and_device_trees +The disk(s) of a btrfs filesystem are divided into chunks of 256 MB or more. +Chunks may be mirrored or striped across multiple devices, depending by +the allocation policy. +The mirroring/striping arrangement is transparent to the rest of the +file system, which simply sees the single, logical address space that +chunks are mapped into. +Chunks are allocated on demand. In the default allocation policy +the data chunks are not duplicated and the metadata chunks +are duplicated. This default can be changed during the filesystem +creation, and in general the chunks allocation policy may change +during the filesystem life. + +Depending by the allocation policy a chunk may require a space on +the disk greater than the logical space that it provides. E.g. +a chunk DUPlicated or with a RAID1/RAID10 level +requires a space on the disk +two times greater than the logical space provided. +Different RAID levels +have a different ratio disk-usage / logical space offered. + +Normally the file contents are stored in the Data chunks; however +small files (which fit into a btree leaf) are stored in the +metadata chunks. So the computation of the \fIfree space\fP +and \fIused space\fP +is complex: depending by the file size different +allocation policies are used. + +The command \fBbtrfs filesystem df\fP is used to query the status +of the chunks, how many space on the disk(s) are used by the chunks, +how many space are available in the chunks, and an estimation of the free +space of the filesystem. +The output of the command \fBbtrfs filesystem df\fP shows: + +.RS +.IP \fBDisk\ size\fP +the total size of the disks which compose the filesystem. + +.IP \fBDisk\ allocated\fP\ or\ \fBSize_(disk)\fP +the size of the area of the disks used by the chunks. + +.IP \fBDisk\ unallocated\fP +the size of the area of the disks which is free (i.e. +the differences of the values above). + +.IP \fBLogical\ size\fP\ or\ \fBSize_(logical)\fP +the available logical space of chunk. + +.IP \fBUsed\fP +the portion of the logical space used by the file and metadata. + +.IP \fBFree\ (estimated)\fP +the estimated free space available. The evaluation +cannot be rigorous because it depends by the allocation policy (DUP,Single, +RAID1...) of the metadata and data chunks. If every chunks is stored as +"Single" the sum of the \fBfree (estimated)\fP space and the \fBused\fP +space is equal to the \fBdisk size\fP. +Otherwise if all the chunk are mirrored (raid1 or raid10) or duplicated +the sum of the \fBfree (estimated)\fP space and the \fBused\fP space is +half of the \fBdisk size\fP. Normally the \fBfree (estimated)\fP is between +these two limits. + +.IP \fBData\ to\ disk\ ratio\fP +the ratio betwen the \fBlogical size\fP and the \fBdisk allocated\fP. + +.IP \fBMode\fP +the kind of allocation policy used by the chunk (e.g. DUPlicated, +RAID1, RAID10, Single....) + +.IP \fBChunk\ type\fP +the kind of chunk (Data, Metdata, System...) + +.RE +.RS +\fINOTE\fP + +When a chunk is allocated, its disk-area is used and its allocation +policy is fixed. +A rebalance operation could rearrange the chunks, moving data in the chunks +and resizing the allocated chunks. This causes the change of all the values +discussed above, with the exception of the \fBused\fP and +\fBdisk size\fP values. + +.RE +.TP + \fBfilesystem show\fR [--all-devices|<uuid>|<label>]\fR Show the btrfs filesystem with some additional info. If no \fIUUID\fP or \fIlabel\fP is passed, \fBbtrfs\fR show info of all the btrfs filesystem. -- 1.7.10.4 -- 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
Am Donnerstag, 4. Oktober 2012 schrieb Goffredo Baroncelli:> Hi Chris, > > this serie of patches updated the command "btrfs filesystem > df". I update this command because it is not so easy to get > the information about the disk usage from the command "fi df" and "fi show". > This patch was the result of some discussions on the btrfs > mailing list. Many thanks to all the contributors. > > From the man page (see 2nd patch): > > [...] > The command btrfs filesystem df is used to query the > status of the chunks, how many space on the disk(s) are used by > the chunks, how many space are available in the chunks, and an > estimation of the free space of the filesystem. > [...] > > $ ./btrfs filesystem df --help > usage: btrfs filesystem disk-usage [-k] <path> [<path>..] > > Show space usage information for a mount point(s). > > -k Set KB (1024 bytes) as unit > > $ ./btrfs filesystem df / > Path: / > Summary: > Disk_size: 72.57GB > Disk_allocated: 25.10GB > Disk_unallocated: 47.48GB > Logical_size: 23.06GB > Used: 11.01GB > Free_(Estimated): 55.66GB (Max: 59.52GB, Min: 35.78GB) > Data_to_disk_ratio: 92 % > > Details: > Chunk_type Mode Size_(disk) Size_(logical) Used > Data Single 21.01GB 21.01GB 10.34GB > System DUP 80.00MB 40.00MB 4.00KB > System Single 4.00MB 4.00MB 0.00 > Metadata DUP 4.00GB 2.00GB 686.93MB > Metadata Single 8.00MB 8.00MB 0.00Works nicely here: merkaba:/home/[…]> ./btrfs fi df / Path: / Summary: Disk_size: 18.62GB Disk_allocated: 18.62GB Disk_unallocated: 0.00 Logical_size: 16.87GB Used: 12.46GB Free_(Estimated): 4.41GB (Max: 4.41GB, Min: 4.41GB) Data_to_disk_ratio: 91 % Details: Chunk_type Mode Size_(disk) Size_(logical) Used Data Single 15.10GB 15.10GB 11.78GB System DUP 16.00MB 8.00MB 4.00KB System Single 4.00MB 4.00MB 0.00 Metadata DUP 3.50GB 1.75GB 693.97MB Metadata Single 8.00MB 8.00MB 0.00 merkaba:/home/[…]> ./btrfs fi df /mnt/amazon Path: /mnt/amazon Summary: Disk_size: 465.76GB Disk_allocated: 465.76GB Disk_unallocated: 4.00KB Logical_size: 455.75GB Used: 368.83GB Free_(Estimated): 86.93GB (Max: 86.93GB, Min: 86.93GB) Data_to_disk_ratio: 98 % Details: Chunk_type Mode Size_(disk) Size_(logical) Used Data Single 445.73GB 445.73GB 368.24GB System DUP 16.00MB 8.00MB 64.00KB System Single 4.00MB 4.00MB 0.00 Metadata DUP 20.00GB 10.00GB 598.84MB Metadata Single 8.00MB 8.00MB 0.00 I wonder about free size estimation minimum and maximum are the same tough. Do you have a explaination for this? Otherwise: Tested-By: Martin Steigerwald <martin@lichtvoll.de> (as of commit c3f7fa95f3aa29972b79eed71ec063b6a3019017 from your repo.) The data to disk ratio on bigger disk is lower due to less duplicated meta data involved, I bet. I want to recreate / anyway with 16 KiB leaf and node size and then I think I will use single for metadata as its an SSD. The bigger one is external eSATA harddisk. I can test and post outputs of a few other disks including my oldest BTRFS filesystems on a ThinkPad T23 which are at least one, possible almost 2 years old. Is there are way to tell filesystem creation date? And a 2 TiB backup disk with three or for subvolumes and >10 snapshots of all of them together.> Where: > Disk_size -> sum of sizes of teh disks > Disk_allocated -> sum of chunk sizes > Disk_unallocated -> Disk_size - Disk_allocated > Logical_size -> sum of logical area sizes > Used -> logical area used > Free_(Estimated) -> on the basis of allocated > chunk, an estrapolation of > the free space > Data_to_disk_ratio -> ration between the space occuped > by a chunk and the real space > available ( due to duplication > and/or RAID level) > Chunk_type -> kind of chunk > Mode -> allocation policy of a chunk > Size_(disk) -> area of disk(s) occuped by the > chunk (see it as raw space used) > Size_(logical) -> logical area size of the chunk > Used -> portion of the logical area > used by the filesystem[…] -- Martin ''Helios'' Steigerwald - http://www.Lichtvoll.de GPG: 03B0 0D6C 0040 0710 4AFA B82F 991B EAAC A599 84C7 -- 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
Goffredo Baroncelli
2012-Oct-06 13:47 UTC
Re: [PATCH][BTRFS-PROGS][V3] btrfs filesystem df
On 10/06/2012 11:57 AM, Martin Steigerwald wrote:> Am Donnerstag, 4. Oktober 2012 schrieb Goffredo Baroncelli: >> Hi Chris, >> > > > Works nicely here: > > merkaba:/home/[…]> ./btrfs fi df / > Path: / > Summary: > Disk_size: 18.62GB > Disk_allocated: 18.62GB > Disk_unallocated: 0.00 > Logical_size: 16.87GB > Used: 12.46GB > Free_(Estimated): 4.41GB (Max: 4.41GB, Min: 4.41GB) > Data_to_disk_ratio: 91 % > > Details: > Chunk_type Mode Size_(disk) Size_(logical) Used > Data Single 15.10GB 15.10GB 11.78GB > System DUP 16.00MB 8.00MB 4.00KB > System Single 4.00MB 4.00MB 0.00 > Metadata DUP 3.50GB 1.75GB 693.97MB > Metadata Single 8.00MB 8.00MB 0.00 > > > merkaba:/home/[…]> ./btrfs fi df /mnt/amazon > Path: /mnt/amazon > Summary: > Disk_size: 465.76GB > Disk_allocated: 465.76GB > Disk_unallocated: 4.00KB > Logical_size: 455.75GB > Used: 368.83GB > Free_(Estimated): 86.93GB (Max: 86.93GB, Min: 86.93GB) > Data_to_disk_ratio: 98 % > > Details: > Chunk_type Mode Size_(disk) Size_(logical) Used > Data Single 445.73GB 445.73GB 368.24GB > System DUP 16.00MB 8.00MB 64.00KB > System Single 4.00MB 4.00MB 0.00 > Metadata DUP 20.00GB 10.00GB 598.84MB > Metadata Single 8.00MB 8.00MB 0.00 > > > I wonder about free size estimation minimum and maximum are the same tough. > > Do you have a explaination for this?Yes, the explanation is quite simple: the unallocated sector are zero; all the disks are mapped in the chunk. So the allocation policy is stabilised and fixed. The free space is the sum of the free space of the metadata and the free space of the data (445.73-368.24 + 10-0.598 = ~86GB). If some disk areas had un-allocated sectors, depending by the destination them would be DUPlicated or Single. This lead to have not *one* "free value" but a range. In your case there is no choice because there is no allocation area available anymore.> > Otherwise: > > Tested-By: Martin Steigerwald<martin@lichtvoll.de> > > (as of commit c3f7fa95f3aa29972b79eed71ec063b6a3019017 from your repo.) > > > The data to disk ratio on bigger disk is lower due to less duplicated meta > data involved, I bet. I want to recreate / anyway with 16 KiB leaf and node > size and then I think I will use single for metadata as its an SSD. The > bigger one is external eSATA harddisk. > > > I can test and post outputs of a few other disks including my oldest BTRFS > filesystems on a ThinkPad T23 which are at least one, possible almost 2 > years old. Is there are way to tell filesystem creation date? And a 2 TiB > backup disk with three or for subvolumes and>10 snapshots of all of them > together. > >> Where: >> Disk_size -> sum of sizes of teh disks >> Disk_allocated -> sum of chunk sizes >> Disk_unallocated -> Disk_size - Disk_allocated >> Logical_size -> sum of logical area sizes >> Used -> logical area used >> Free_(Estimated) -> on the basis of allocated >> chunk, an estrapolation of >> the free space >> Data_to_disk_ratio -> ration between the space occuped >> by a chunk and the real space >> available ( due to duplication >> and/or RAID level) >> Chunk_type -> kind of chunk >> Mode -> allocation policy of a chunk >> Size_(disk) -> area of disk(s) occuped by the >> chunk (see it as raw space used) >> Size_(logical) -> logical area size of the chunk >> Used -> portion of the logical area >> used by the filesystem > […]-- 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
Hi, I hope I''m not late to the bikeshedding party, I''ve tried to use the proposed version and here are my observations/wishes, and also issues, pointed out in the threads, that were not addressed: * I''d like to re-add the -s -d options in some way that I can choose which sections I''ll see; the previous output matches the ''details'' section and contains the valuable information for me More flexibility via options will satisfy more users, currently I have no choice than only ignore the summary section, not to say that this consumes half of my terminal UI details (that make human-parsing of the output more pleasant experience): * the ''Path'' should contain full path, not just the argument that was given (otherwise it''s useless) * I''m with Hugo that there should be space between numbers and units * show the byte units * the short form for metadata in --mixed filesystem current: Data+M.data proposed: Data+Meta * Chunk_type -> Type ? * Size_(logical) is misaligned with the numbers underneath * Used (in the summary) is in logical units, I needed to hand calculate the number to find this out -- any idea how to make it more clear? like Used_(logical) similar to size * revert the order of Min and Max in Free_(Estimated) * in code: function is still named cmd_disk_free * in code: although you''ve removed -s -d the getopt string still contains them (but this is not an objection because I want them back :) Also, I''ve noticed that you refuse to fix minor things in code that you''re not touching directly for ''df'', but this renders the (much needed!) updates to df as only half-finished (IMHO). It''s fine to add a separate patch to fix up the non-df things. Let''s fix it in one go :) thanks, david [Sample output for quick reference]> $ ./btrfs filesystem df / > Path: / > Summary: > Disk_size: 72.57GB > Disk_allocated: 25.10GB > Disk_unallocated: 47.48GB > Logical_size: 23.06GB > Used: 11.01GB > Free_(Estimated): 55.66GB (Max: 59.52GB, Min: 35.78GB) > Data_to_disk_ratio: 92 % > > Details: > Chunk_type Mode Size_(disk) Size_(logical) Used > Data Single 21.01GB 21.01GB 10.34GB > System DUP 80.00MB 40.00MB 4.00KB > System Single 4.00MB 4.00MB 0.00 > Metadata DUP 4.00GB 2.00GB 686.93MB > Metadata Single 8.00MB 8.00MB 0.00 > > Where: > Disk_size -> sum of sizes of teh disks > Disk_allocated -> sum of chunk sizes > Disk_unallocated -> Disk_size - Disk_allocated > Logical_size -> sum of logical area sizes > Used -> logical area used > Free_(Estimated) -> on the basis of allocated > chunk, an estrapolation of > the free space > Data_to_disk_ratio -> ration between the space occuped > by a chunk and the real space > available ( due to duplication > and/or RAID level) > Chunk_type -> kind of chunk > Mode -> allocation policy of a chunk > Size_(disk) -> area of disk(s) occuped by the > chunk (see it as raw space used) > Size_(logical) -> logical area size of the chunk > Used -> portion of the logical area > used by the filesystem-- 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
Goffredo Baroncelli
2012-Oct-09 18:07 UTC
Re: [PATCH][BTRFS-PROGS][V3] btrfs filesystem df
Hi David, On 10/09/2012 03:51 PM, David Sterba wrote:> Hi, > > I hope I''m not late to the bikeshedding party, I''ve tried to use the > proposed version and here are my observations/wishes, and also issues, > pointed out in the threads, that were not addressed: > > * I''d like to re-add the -s -d options in some way that I can choose > which sections I''ll see; the previous output matches the ''details'' > section and contains the valuable information for me > More flexibility via options will satisfy more users, currently I have > no choice than only ignore the summary section, not to say that this > consumes half of my terminalThere was several emails about this topic. At the end we find more logical to avoid the options. See the thread "[PATCH][BTRFS-PROGS][V3] btrfs filesystem df" for the reasons.> UI details (that make human-parsing of the output more pleasant experience): > > * the ''Path'' should contain full path, not just the argument that was > given (otherwise it''s useless)The reason to put the path in the output is to disambiguation of the sections when multiple paths are passed. It was not intended to identify the absolute path of an argument.> * I''m with Hugo that there should be space between numbers and unitsI already replayed to Hugo about that: this issue is note related to my patches. I used the function "pretty_sizes()", which was made at the beginning of the btrfs-progs. I don''t want to address your concerns (which are be valid) in this set of patches. Also because the question is not so simple: Bart suggested to used the the SI units (pow of ten) instead the IEC unit (pow of 2); or better we could let the user to select different unit....> * show the byte unitsAt the beginning it was so. But the space required was greater than 80 columns. Moreover the allocation space is in multiply of 4KiB, so showing the number in bytes doesn''t add any information. The documentation clearly stated that if -k is passed the units are KiB.> * the short form for metadata in --mixed filesystem > current: Data+M.data > proposed: Data+MetaI like your proposal, but at this point I don''t want to add another iteration on this topic until other people ack your proposal.> * Chunk_type -> Type ?There was another person who made the same proposal. However I don''t like it: what mean "type" alone ? We are showing the chunk information.> * Size_(logical) is misaligned with the numbers underneathIt is not an error. I did so because the constraint of 80 column when the unit is set to KiB. Otherwise I have to maintain two completely set of printf depending by the unit used. But I have to agree to the fact that it is not very pleasant to read.> * Used (in the summary) is in logical units, I needed to hand calculate > the number to find this out -- any idea how to make it more clear? > like Used_(logical) similar to sizeTo me it is natural to evaluate Used against its previous values. To me it is logical that the units are the same, but I am sure that it is a subjective matter; I am not against to change but I would like to see other people to support your suggestion.> * revert the order of Min and Max in Free_(Estimated)What this the reasons ? I don''t find Max..Min more (or less) reasonable than Min..Max. Again, I am not against your request but I would like to see other people support your suggestion.> * in code: function is still named cmd_disk_freeThis was already discussed. The reason behind that was that this function is not an update of the old one, but a new one. Then the diff program collapse the two changes (removing the old one and adding the new one). There is no reason to maintain the same name. Several commands also have a name different from "its cmd-line name". I maintained df as per Chris request; originally I wanted to call it disk-usage. I renamed the function disk_usage to disk_free as compromise. My opinion is that df should renamed disk-free....> * in code: although you''ve removed -s -d the getopt string still > contains them (but this is not an objection because I want them back :)This was definitely a my BUG :-)> Also, I''ve noticed that you refuse to fix minor things in code that > you''re not touching directly for ''df'', but this renders the (much > needed!) updates to df as only half-finished (IMHO).Frankly speaking it is a bit un-polite to declare our work (the my one and the the ones of the reviewers) to be "half finished". Moreover you raised a lot of requests with very few explanations. I can live with the fact that you don''t like my work, but if you want to improve the situation you should justify your requests for respect of other peoples. Pay attention that every loop requires time (which is not infinite) so at the end we should balance the needing of improvement (everything could be improved) with the needing of the patch.> It''s fine to add a > separate patch to fix up the non-df things. Let''s fix it in one go :)On the basis of my previous reply, I will try to address only the getopt() bug, and the alignment of the "Size_(logical)". Due to my time limits I will need some day to issue this new patch...> thanks, > david > > [Sample output for quick reference] >> $ ./btrfs filesystem df / >> Path: / >> Summary: >> Disk_size: 72.57GB >> Disk_allocated: 25.10GB >> Disk_unallocated: 47.48GB >> Logical_size: 23.06GB >> Used: 11.01GB >> Free_(Estimated): 55.66GB (Max: 59.52GB, Min: 35.78GB) >> Data_to_disk_ratio: 92 % >> >> Details: >> Chunk_type Mode Size_(disk) Size_(logical) Used >> Data Single 21.01GB 21.01GB 10.34GB >> System DUP 80.00MB 40.00MB 4.00KB >> System Single 4.00MB 4.00MB 0.00 >> Metadata DUP 4.00GB 2.00GB 686.93MB >> Metadata Single 8.00MB 8.00MB 0.00 >> >> Where: >> Disk_size -> sum of sizes of teh disks >> Disk_allocated -> sum of chunk sizes >> Disk_unallocated -> Disk_size - Disk_allocated >> Logical_size -> sum of logical area sizes >> Used -> logical area used >> Free_(Estimated) -> on the basis of allocated >> chunk, an estrapolation of >> the free space >> Data_to_disk_ratio -> ration between the space occuped >> by a chunk and the real space >> available ( due to duplication >> and/or RAID level) >> Chunk_type -> kind of chunk >> Mode -> allocation policy of a chunk >> Size_(disk) -> area of disk(s) occuped by the >> chunk (see it as raw space used) >> Size_(logical) -> logical area size of the chunk >> Used -> portion of the logical area >> used by the filesystem >-- 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
On Tue, Oct 09, 2012 at 08:07:51PM +0200, Goffredo Baroncelli wrote:> There was several emails about this topic. At the end we find more logical > to avoid the options. See the thread "[PATCH][BTRFS-PROGS][V3] btrfs > filesystem df" for the reasons.I had read all the threads before I responded to the latest version. Lack of the s/d options hurts usability and flexibility when poeple have various expectations and practices, that''s my concern. And we''ve seen different oppinions, we should listen to them.> >UI details (that make human-parsing of the output more pleasant experience): > > > >* the ''Path'' should contain full path, not just the argument that was > > given (otherwise it''s useless) > The reason to put the path in the output is to disambiguation of the > sections when multiple paths are passed. It was not intended to identify the > absolute path of an argument.Ok, I never used df with multiple paths, I can live with the path that''s passed on the commandline.> >* I''m with Hugo that there should be space between numbers and units > I already replayed to Hugo about that: this issue is note related to my > patches. I used the function "pretty_sizes()", which was made at the > beginning of the btrfs-progs. I don''t want to address your concerns (which > are be valid) in this set of patches.You''ve picked the taks to improve df output and now you''re stopping to do that for a reason I do not understand -- you''re always changing code that was there from the beginning. Is it some kind of monument we''re not allowed to touch?> Also because the question is not so simple: Bart suggested to used the the > SI units (pow of ten) instead the IEC unit (pow of 2); or better we could > let the user to select different unit....Yes exactly. Bart had a valid comment, we should listen to the users.> >* show the byte units > At the beginning it was so. But the space required was greater than 80 > columns. Moreover the allocation space is in multiply of 4KiB, so showing > the number in bytes doesn''t add any information. The documentation clearly > stated that if -k is passed the units are KiB.Keeping the line at most 80 sounds reasonable, but if the overflow is only because of 4x '' '' or units, we can try to squeeze the empty space between columns.> >* the short form for metadata in --mixed filesystem > > current: Data+M.data > > proposed: Data+Meta > I like your proposal, but at this point I don''t want to add another > iteration on this topic until other people ack your proposal.Fair enough.> >* Chunk_type -> Type ? > There was another person who made the same proposal. However I don''t like > it: what mean "type" alone ? We are showing the chunk information.And the person said "what does chunk mean to the user? it''s an internal detail." (IIRC). There''s also ''type'' for the raid profiles, ambiguity of the term ''type'' will lead us to confusion when we''ll talk to users. The term ''profile'' is AFAIK widely used in the context of RAIDs.> >* Size_(logical) is misaligned with the numbers underneath > It is not an error. I did so because the constraint of 80 column when the > unit is set to KiB. Otherwise I have to maintain two completely set of > printf depending by the unit used. > But I have to agree to the fact that it is not very pleasant to read.Let''s fix it.> >* Used (in the summary) is in logical units, I needed to hand calculate[snip]> I am not against to change but I would like to see other > people to support your suggestion. > > >* revert the order of Min and Max in Free_(Estimated)[snip]> What this the reasons ? I don''t find Max..Min more (or less) reasonable than > Min..Max. Again, I am not against your request but I would like to see other > people support your suggestion.Seems that the only way I can get possitive/negative feedback on those suggestions is after I send a patch that implements them.> >* in code: function is still named cmd_disk_free > This was already discussed. The reason behind that was that this function is > not an update of the old one, but a new one. Then the diff program collapse > the two changes (removing the old one and adding the new one). There is no > reason to maintain the same name. Several commands also have a name > different from "its cmd-line name".The function names match the command names 90% of the commands. The exceptions are cmd_rm_dev and cmd_inspect.> I maintained df as per Chris request; originally I wanted to call it > disk-usage. I renamed the function disk_usage to disk_free as compromise. My > opinion is that df should renamed disk-free....Too long to type, this is a frequent command and part of people''s habit, I''m completely with Chis here.> >Also, I''ve noticed that you refuse to fix minor things in code that > >you''re not touching directly for ''df'', but this renders the (much > >needed!) updates to df as only half-finished (IMHO). > > Frankly speaking it is a bit un-polite to declare our work (the my one and > the the ones of the reviewers) to be "half finished". Moreover you raised a > lot of requests with very few explanations.Do you really think it''s finished? I don''t want to be impolite, I don''t use insults or strong words. Dictionary defines ''half-finished'' as ''partially completed''. I try to explain the reasons and if I fail to, please ask again. I''m your yet another reviewer, not your enemy. The other reviewers may likewise feel offended by your lack of interest to include their proposals. I try to explain my reasons and this costs me time and energy in hope that the efforts will be worth for the project.> I can live with the fact that you don''t like my work, but if you want to > improve the situation you should justify your requests for respect of other > peoples.This is diverging from the process of proposing patchsets and doing the review rounds, I''m not taking any personal fights over code. The ''df'' is a highly visible command and I''m paying extra attention to that we end up with. I base my requests on my own experience, feeling, and on feedback from users on IRC or my colleagues. I respect users and developers, trying to find a reasonable middle ground. That''s not easy and very likely not resolved on the first attempt.> Pay attention that every loop requires time (which is not infinite) so at > the end we should balance the needing of improvement (everything could be > improved) with the needing of the patch.I''m well aware of peculiarities of pushing patches upstream. Sure, we''re all busy, I had to reschedule my spare time projects because I don''t want to miss the ''df'' changes. david -- 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
Goffredo Baroncelli
2012-Oct-10 17:26 UTC
Re: [PATCH][BTRFS-PROGS][V3] btrfs filesystem df
On 10/10/2012 12:15 AM, David Sterba wrote:> On Tue, Oct 09, 2012 at 08:07:51PM +0200, Goffredo Baroncelli wrote:[...]>>> * show the byte units >> At the beginning it was so. But the space required was greater than 80 >> columns. Moreover the allocation space is in multiply of 4KiB, so showing >> the number in bytes doesn''t add any information. The documentation clearly >> stated that if -k is passed the units are KiB. > > Keeping the line at most 80 sounds reasonable, but if the overflow is > only because of 4x '' '' or units, we can try to squeeze the empty space > between columns.There is no space: A 64 bit number requires 20 characters; $ python -c "print len(str(2<<64))" 20 The "Chunk_type" and Mode column require 12+8 = 20 characters. So 20 + [Chunk_type+Mode] 20 + [Size_(disk)] 20 + [Size_(logical)] 20 + [Used] 2 [spaces between the columns Size(disk) <-> Size_(logical> <-> Used] Requires more than 80 characters. This is the reason to switch to 1k unit. the "df" default is the same. [...]>>> * Chunk_type -> Type ? >> There was another person who made the same proposal. However I don''t like >> it: what mean "type" alone ? We are showing the chunk information. > > And the person said "what does chunk mean to the user? it''s an > internal detail." (IIRC). There''s also ''type'' for the raid profiles, > ambiguity of the term ''type'' will lead us to confusion when we''ll talk > to users. The term ''profile'' is AFAIK widely used in the context of > RAIDs.Sorry I cannot understand your conclusion... I am not sure if you are suggesting to replace ''Mode'' with ''Profile'' ? Anyway I like it. With another ACK I will update it. Regarding ''Chunk_type'', I am open to change it, but I veto ''Type''. Some suggestions: - Allocation_type - Block_type - Block - Allocation_mode - Area - Area_type - Area_mode> >>> * Size_(logical) is misaligned with the numbers underneath >> It is not an error. I did so because the constraint of 80 column when the >> unit is set to KiB. Otherwise I have to maintain two completely set of >> printf depending by the unit used. >> But I have to agree to the fact that it is not very pleasant to read. > > Let''s fix it.Fixed> >>> * Used (in the summary) is in logical units, I needed to hand calculate > [snip] >> I am not against to change but I would like to see other >> people to support your suggestion. >> >>> * revert the order of Min and Max in Free_(Estimated) > [snip] >> What this the reasons ? I don''t find Max..Min more (or less) reasonable than >> Min..Max. Again, I am not against your request but I would like to see other >> people support your suggestion. > > Seems that the only way I can get possitive/negative feedback on those > suggestions is after I send a patch that implements them.I cannot agree more :-)>[...]>> I maintained df as per Chris request; originally I wanted to call it >> disk-usage. I renamed the function disk_usage to disk_free as compromise. My >> opinion is that df should renamed disk-free.... > > Too long to type, this is a frequent command and part of people''s habit, > I''m completely with Chis here.Even I was not convinced, I did accept Chris''s suggestion... [...] -- 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