df is a very loaded question in btrfs. This gives us a way to get the per-space
usage information so we can tell exactly what is in use where. This will help
us figure out ENOSPC problems, and help users better understand where their disk
space is going.
Signed-off-by: Josef Bacik <josef@redhat.com>
---
fs/btrfs/ioctl.c | 46 ++++++++++++++++++++++++++++++++++++++++++++++
fs/btrfs/ioctl.h | 15 ++++++++++++++-
2 files changed, 60 insertions(+), 1 deletions(-)
diff --git a/fs/btrfs/ioctl.c b/fs/btrfs/ioctl.c
index 9070b86..0b710d5 100644
--- a/fs/btrfs/ioctl.c
+++ b/fs/btrfs/ioctl.c
@@ -1623,6 +1623,50 @@ static long btrfs_ioctl_default_subvol(struct file *file,
void __user *argp)
return 0;
}
+long btrfs_ioctl_space_info(struct btrfs_root *root, void __user *arg)
+{
+ struct btrfs_ioctl_space_args space_args;
+ struct btrfs_ioctl_space_info space;
+ struct btrfs_ioctl_space_info *dest;
+ struct btrfs_space_info *info;
+ int ret = 0;
+
+ if (copy_from_user(&space_args,
+ (struct btrfs_ioctl_space_args __user *)arg,
+ sizeof(space_args)))
+ return -EFAULT;
+
+ space_args.total_spaces = 0;
+ dest = (struct btrfs_ioctl_space_info *)
+ (arg + sizeof(struct btrfs_ioctl_space_args));
+
+ rcu_read_lock();
+ list_for_each_entry_rcu(info, &root->fs_info->space_info, list) {
+ if (!space_args.space_slots) {
+ space_args.total_spaces++;
+ continue;
+ }
+ if (space_args.total_spaces >= space_args.space_slots)
+ break;
+ printk("Saving space %llu\n", space_args.total_spaces);
+ space.flags = info->flags;
+ space.total_bytes = info->total_bytes;
+ space.used_bytes = info->bytes_used;
+ if (copy_to_user(dest, &space, sizeof(space))) {
+ ret = -EFAULT;
+ break;
+ }
+ dest++;
+ space_args.total_spaces++;
+ }
+ rcu_read_unlock();
+
+ if (copy_to_user(arg, &space_args, sizeof(space_args)))
+ ret = -EFAULT;
+
+ return ret;
+}
+
/*
* there are many ways the trans_start and trans_end ioctls can lead
* to deadlocks. They should only be used by applications that
@@ -1691,6 +1735,8 @@ long btrfs_ioctl(struct file *file, unsigned int
return btrfs_ioctl_trans_end(file);
case BTRFS_IOC_SNAP_LISTING:
return btrfs_ioctl_snap_listing(file, argp);
+ case BTRFS_IOC_SPACE_INFO:
+ return btrfs_ioctl_space_info(root, argp);
case BTRFS_IOC_SYNC:
btrfs_sync_fs(file->f_dentry->d_sb, 1);
return 0;
diff --git a/fs/btrfs/ioctl.h b/fs/btrfs/ioctl.h
index 9e5074c..850e0ee 100644
--- a/fs/btrfs/ioctl.h
+++ b/fs/btrfs/ioctl.h
@@ -54,6 +54,18 @@ struct btrfs_ioctl_subvol_leaf {
struct btrfs_ioctl_subvol_items items[];
};
+struct btrfs_ioctl_space_info {
+ u32 flags;
+ u64 total_bytes;
+ u64 used_bytes;
+};
+
+struct btrfs_ioctl_space_args {
+ u64 space_slots;
+ u64 total_spaces;
+ struct btrfs_ioctl_space_info spaces[0];
+};
+
#define BTRFS_SUBVOL_LEAF_SIZE_MIN sizeof(struct btrfs_ioctl_subvol_leaf) + \
sizeof(struct btrfs_ioctl_subvol_items)
@@ -97,5 +109,6 @@ struct btrfs_ioctl_clone_range_args {
#define BTRFS_IOC_SNAP_LISTING _IOWR(BTRFS_IOCTL_MAGIC, 16, \
struct btrfs_ioctl_subvol_args)
#define BTRFS_IOC_DEFAULT_SUBVOL _IOW(BTRFS_IOCTL_MAGIC, 17, u64)
-
+#define BTRFS_IOC_SPACE_INFO _IOWR(BTRFS_IOCTL_MAGIC, 18, \
+ struct btrfs_ioctl_space_args)
#endif
--
1.5.4.3
--
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, Jan 12, 2010 at 03:25:13PM -0500, Josef Bacik wrote:> df is a very loaded question in btrfs. This gives us a way to get the per-space > usage information so we can tell exactly what is in use where. This will help > us figure out ENOSPC problems, and help users better understand where their disk > space is going. >Sorry, here''s one without my debugging printk still sitting there. Thanks, Josef --- fs/btrfs/ioctl.c | 45 +++++++++++++++++++++++++++++++++++++++++++++ fs/btrfs/ioctl.h | 15 ++++++++++++++- 2 files changed, 59 insertions(+), 1 deletions(-) diff --git a/fs/btrfs/ioctl.c b/fs/btrfs/ioctl.c index 9070b86..7405e42 100644 --- a/fs/btrfs/ioctl.c +++ b/fs/btrfs/ioctl.c @@ -1623,6 +1623,49 @@ static long btrfs_ioctl_default_subvol(struct file *file, void __user *argp) return 0; } +long btrfs_ioctl_space_info(struct btrfs_root *root, void __user *arg) +{ + struct btrfs_ioctl_space_args space_args; + struct btrfs_ioctl_space_info space; + struct btrfs_ioctl_space_info *dest; + struct btrfs_space_info *info; + int ret = 0; + + if (copy_from_user(&space_args, + (struct btrfs_ioctl_space_args __user *)arg, + sizeof(space_args))) + return -EFAULT; + + space_args.total_spaces = 0; + dest = (struct btrfs_ioctl_space_info *) + (arg + sizeof(struct btrfs_ioctl_space_args)); + + rcu_read_lock(); + list_for_each_entry_rcu(info, &root->fs_info->space_info, list) { + if (!space_args.space_slots) { + space_args.total_spaces++; + continue; + } + if (space_args.total_spaces >= space_args.space_slots) + break; + space.flags = info->flags; + space.total_bytes = info->total_bytes; + space.used_bytes = info->bytes_used; + if (copy_to_user(dest, &space, sizeof(space))) { + ret = -EFAULT; + break; + } + dest++; + space_args.total_spaces++; + } + rcu_read_unlock(); + + if (copy_to_user(arg, &space_args, sizeof(space_args))) + ret = -EFAULT; + + return ret; +} + /* * there are many ways the trans_start and trans_end ioctls can lead * to deadlocks. They should only be used by applications that @@ -1691,6 +1734,8 @@ long btrfs_ioctl(struct file *file, unsigned int return btrfs_ioctl_trans_end(file); case BTRFS_IOC_SNAP_LISTING: return btrfs_ioctl_snap_listing(file, argp); + case BTRFS_IOC_SPACE_INFO: + return btrfs_ioctl_space_info(root, argp); case BTRFS_IOC_SYNC: btrfs_sync_fs(file->f_dentry->d_sb, 1); return 0; diff --git a/fs/btrfs/ioctl.h b/fs/btrfs/ioctl.h index 9e5074c..850e0ee 100644 --- a/fs/btrfs/ioctl.h +++ b/fs/btrfs/ioctl.h @@ -54,6 +54,18 @@ struct btrfs_ioctl_subvol_leaf { struct btrfs_ioctl_subvol_items items[]; }; +struct btrfs_ioctl_space_info { + u32 flags; + u64 total_bytes; + u64 used_bytes; +}; + +struct btrfs_ioctl_space_args { + u64 space_slots; + u64 total_spaces; + struct btrfs_ioctl_space_info spaces[0]; +}; + #define BTRFS_SUBVOL_LEAF_SIZE_MIN sizeof(struct btrfs_ioctl_subvol_leaf) + \ sizeof(struct btrfs_ioctl_subvol_items) @@ -97,5 +109,6 @@ struct btrfs_ioctl_clone_range_args { #define BTRFS_IOC_SNAP_LISTING _IOWR(BTRFS_IOCTL_MAGIC, 16, \ struct btrfs_ioctl_subvol_args) #define BTRFS_IOC_DEFAULT_SUBVOL _IOW(BTRFS_IOCTL_MAGIC, 17, u64) - +#define BTRFS_IOC_SPACE_INFO _IOWR(BTRFS_IOCTL_MAGIC, 18, \ + struct btrfs_ioctl_space_args) #endif -- 1.5.4.3 -- 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, Jan 12, 2010 at 03:25:13PM -0500, Josef Bacik wrote:> df is a very loaded question in btrfs. This gives us a way to get the per-space > usage information so we can tell exactly what is in use where. This will help > us figure out ENOSPC problems, and help users better understand where their disk > space is going.Just as discussed before I think it''s a really bad idea. We always had df reporting inconsistencies due to the way metadata is managed, and btrfs isn''t special in that way. so, NACK -- 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 Wed, Jan 13, 2010 at 05:25:03AM -0500, Christoph Hellwig wrote:> On Tue, Jan 12, 2010 at 03:25:13PM -0500, Josef Bacik wrote: > > df is a very loaded question in btrfs. This gives us a way to get the per-space > > usage information so we can tell exactly what is in use where. This will help > > us figure out ENOSPC problems, and help users better understand where their disk > > space is going. > > Just as discussed before I think it''s a really bad idea. We always had > df reporting inconsistencies due to the way metadata is managed, and > btrfs isn''t special in that way. > > so, NACKRight, this isn''t changing how DF works, it just lets me get a better insight into the fs if I need it. It''s very helpful to me to see how the fs is broken up and whats in use for debugging ENOSPC things, as well as being nice to have something to show users how their volume is being used. Think of it more as a debugging thing than a replacement for df :). Thanks, Josef -- 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 Wed, Jan 13, 2010 at 05:25:03AM -0500, Christoph Hellwig wrote:> On Tue, Jan 12, 2010 at 03:25:13PM -0500, Josef Bacik wrote: > > df is a very loaded question in btrfs. This gives us a way to get the per-space > > usage information so we can tell exactly what is in use where. This will help > > us figure out ENOSPC problems, and help users better understand where their disk > > space is going. > > Just as discussed before I think it''s a really bad idea. We always had > df reporting inconsistencies due to the way metadata is managed, and > btrfs isn''t special in that way.This is more than just df being inaccurate, it''s a way to find out how much space is used by each of the raid modes. We''ve had a ton of feature requests for this, and it really helps identify drives that have a ton of free space tied up for data vs metadata. -chris -- 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, Jan 12, 2010 at 03:25:13PM -0500, Josef Bacik wrote:> df is a very loaded question in btrfs. This gives us a way to get the per-space > usage information so we can tell exactly what is in use where. This will help > us figure out ENOSPC problems, and help users better understand where their disk > space is going. > > diff --git a/fs/btrfs/ioctl.h b/fs/btrfs/ioctl.h > index 9e5074c..850e0ee 100644 > --- a/fs/btrfs/ioctl.h > +++ b/fs/btrfs/ioctl.h > @@ -54,6 +54,18 @@ struct btrfs_ioctl_subvol_leaf { > struct btrfs_ioctl_subvol_items items[]; > }; > > +struct btrfs_ioctl_space_info { > + u32 flags; > + u64 total_bytes; > + u64 used_bytes; > +};Could you please bump that u32 to a u64? -chris -- 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 Wed, Jan 13, 2010 at 09:31:00AM -0500, Chris Mason wrote:> On Tue, Jan 12, 2010 at 03:25:13PM -0500, Josef Bacik wrote: > > df is a very loaded question in btrfs. This gives us a way to get the per-space > > usage information so we can tell exactly what is in use where. This will help > > us figure out ENOSPC problems, and help users better understand where their disk > > space is going. > > > > diff --git a/fs/btrfs/ioctl.h b/fs/btrfs/ioctl.h > > index 9e5074c..850e0ee 100644 > > --- a/fs/btrfs/ioctl.h > > +++ b/fs/btrfs/ioctl.h > > @@ -54,6 +54,18 @@ struct btrfs_ioctl_subvol_leaf { > > struct btrfs_ioctl_subvol_items items[]; > > }; > > > > +struct btrfs_ioctl_space_info { > > + u32 flags; > > + u64 total_bytes; > > + u64 used_bytes; > > +}; > > Could you please bump that u32 to a u64? >Here you are, sorry about that. Thanks, Josef From 6c486aea6268c2e214ba3c73cb2bb1422335c84b Mon Sep 17 00:00:00 2001 From: Josef Bacik <josef@redhat.com> Date: Wed, 13 Jan 2010 13:02:59 -0500 Subject: [PATCH] Btrfs: add a "df" ioctl for btrfs df is a very loaded question in btrfs. This gives us a way to get the per-space usage information so we can tell exactly what is in use where. This will help us figure out ENOSPC problems, and help users better understand where their disk space is going. Signed-off-by: Josef Bacik <josef@redhat.com> --- fs/btrfs/ioctl.c | 45 +++++++++++++++++++++++++++++++++++++++++++++ fs/btrfs/ioctl.h | 15 ++++++++++++++- 2 files changed, 59 insertions(+), 1 deletions(-) diff --git a/fs/btrfs/ioctl.c b/fs/btrfs/ioctl.c index 9070b86..7405e42 100644 --- a/fs/btrfs/ioctl.c +++ b/fs/btrfs/ioctl.c @@ -1623,6 +1623,49 @@ static long btrfs_ioctl_default_subvol(struct file *file, void __user *argp) return 0; } +long btrfs_ioctl_space_info(struct btrfs_root *root, void __user *arg) +{ + struct btrfs_ioctl_space_args space_args; + struct btrfs_ioctl_space_info space; + struct btrfs_ioctl_space_info *dest; + struct btrfs_space_info *info; + int ret = 0; + + if (copy_from_user(&space_args, + (struct btrfs_ioctl_space_args __user *)arg, + sizeof(space_args))) + return -EFAULT; + + space_args.total_spaces = 0; + dest = (struct btrfs_ioctl_space_info *) + (arg + sizeof(struct btrfs_ioctl_space_args)); + + rcu_read_lock(); + list_for_each_entry_rcu(info, &root->fs_info->space_info, list) { + if (!space_args.space_slots) { + space_args.total_spaces++; + continue; + } + if (space_args.total_spaces >= space_args.space_slots) + break; + space.flags = info->flags; + space.total_bytes = info->total_bytes; + space.used_bytes = info->bytes_used; + if (copy_to_user(dest, &space, sizeof(space))) { + ret = -EFAULT; + break; + } + dest++; + space_args.total_spaces++; + } + rcu_read_unlock(); + + if (copy_to_user(arg, &space_args, sizeof(space_args))) + ret = -EFAULT; + + return ret; +} + /* * there are many ways the trans_start and trans_end ioctls can lead * to deadlocks. They should only be used by applications that @@ -1691,6 +1734,8 @@ long btrfs_ioctl(struct file *file, unsigned int return btrfs_ioctl_trans_end(file); case BTRFS_IOC_SNAP_LISTING: return btrfs_ioctl_snap_listing(file, argp); + case BTRFS_IOC_SPACE_INFO: + return btrfs_ioctl_space_info(root, argp); case BTRFS_IOC_SYNC: btrfs_sync_fs(file->f_dentry->d_sb, 1); return 0; diff --git a/fs/btrfs/ioctl.h b/fs/btrfs/ioctl.h index 9e5074c..d5a8e7a 100644 --- a/fs/btrfs/ioctl.h +++ b/fs/btrfs/ioctl.h @@ -54,6 +54,18 @@ struct btrfs_ioctl_subvol_leaf { struct btrfs_ioctl_subvol_items items[]; }; +struct btrfs_ioctl_space_info { + u64 flags; + u64 total_bytes; + u64 used_bytes; +}; + +struct btrfs_ioctl_space_args { + u64 space_slots; + u64 total_spaces; + struct btrfs_ioctl_space_info spaces[0]; +}; + #define BTRFS_SUBVOL_LEAF_SIZE_MIN sizeof(struct btrfs_ioctl_subvol_leaf) + \ sizeof(struct btrfs_ioctl_subvol_items) @@ -97,5 +109,6 @@ struct btrfs_ioctl_clone_range_args { #define BTRFS_IOC_SNAP_LISTING _IOWR(BTRFS_IOCTL_MAGIC, 16, \ struct btrfs_ioctl_subvol_args) #define BTRFS_IOC_DEFAULT_SUBVOL _IOW(BTRFS_IOCTL_MAGIC, 17, u64) - +#define BTRFS_IOC_SPACE_INFO _IOWR(BTRFS_IOCTL_MAGIC, 18, \ + struct btrfs_ioctl_space_args) #endif -- 1.5.4.3 -- 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 Wed, Jan 13, 2010 at 09:29:23AM -0500, Chris Mason wrote:> This is more than just df being inaccurate, it''s a way to find out how > much space is used by each of the raid modes. We''ve had a ton of > feature requests for this, and it really helps identify drives that have > a ton of free space tied up for data vs metadata.Which again is not a fs specific feature. Much better to add a statfs revision to the core that does this for everone. That would also have the nice side effect that we could actually make it statvfs and could get rid of the braindamage in glibc''s current statvfs wrapper. -- 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 Wed, Jan 13, 2010 at 04:46:20PM -0500, Christoph Hellwig wrote:> On Wed, Jan 13, 2010 at 09:29:23AM -0500, Chris Mason wrote: > > This is more than just df being inaccurate, it''s a way to find out how > > much space is used by each of the raid modes. We''ve had a ton of > > feature requests for this, and it really helps identify drives that have > > a ton of free space tied up for data vs metadata. > > Which again is not a fs specific feature. Much better to add a statfs > revision to the core that does this for everone.Is anyone else splitting metadata and raid levels up like btrfs is? As far as I know we''re the only snowflake in the kernel working like this. I''m not against a generic revision, but I think btrfs needs to send out significantly more data than the others.> That would also > have the nice side effect that we could actually make it statvfs and > could get rid of the braindamage in glibc''s current statvfs wrapper. >-chris -- 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