kernel .32, btrfs-vol -b, why is metadata=data
Hi everyone, I'm running kernel 2.6.32-0.65.rc8.git5.fc13.x86_64. And I ran btrfs-vol -b, however for 10G of data I still have 9G of metadata! How do I fix this ? [r...@matrix ~]# btrfs-vol -b / ioctl returns 0 You have mail in /var/spool/mail/root [r...@matrix ~]# btrfs-show failed to read /dev/sr0 Label: none uuid: 06b0d069-b1cb-48c4-b26f-c5088a2360d2 Total devices 1 FS bytes used 10.43GB devid1 size 25.72GB used 19.02GB path /dev/dm-1 Btrfs Btrfs v0.19 -- To unsubscribe from this list: send the line unsubscribe linux-btrfs in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Q: list btrfs snapshots/subvolumes
Heyho! I'm currently (once more) trying to experiment with btrfs, especially since the ENOSPC handling and delete snapshots/subvolumes make it look extremely appealing now. Some questions: * how do I list available snapshots/subvolumes? * assuming a disk has failed: just to be sure: btrfs-vol -r missing will remove the missing device. Not sure: will it also replicate the missing copies of my (raid1) data and metadata? Given that it takes ages (ok, just running a few minutes now ;-) to run on this system, I'd assume so. Or is a separate btrfs-vol -b necessary? * subvolume and snapshot is technically the same, except that a subvolume is created empty and a snapshot is a cow copy of an existing tree. Handling these two is the same once they're created? Ok, that's what I can think of right now. Eagerly waiting for set default subvolume to be mounted to be written... :-) I just did a few tests with a 4 x 450G raid 1 btrfs volume: adding some 5G of small files, remove a disk (didn't pull it out, but shut down the system first), remove failing disk, re-add a disk. So far it seems to work just fine. Just a curiosity: it seems to distribute all data between only two of the disks, the other two stay empty. Is that desired behaviour? Wouldn't it be more efficient to distribute data across all disks? (everything with 2.6.32-rc8. Filesystem was created with btrfs-tools 0.19.) cheers -- vbi ((( P.S.: since recovery after disk failure is a tense moment where I don't want to have to hunt around for the answer ...: --- a/btrfs-vol.c +++ b/btrfs-vol.c @@ -53,6 +53,8 @@ static void print_usage(void) fprintf(stderr, \t-a device add one device\n); fprintf(stderr, \t-b balance chunks across all devices\n); fprintf(stderr, \t-r device remove one device\n); + fprintf(stderr, \t use 'missing' as device name + to remove a failed device\n); exit(1); } ))) -- featured link: Debian Bookmark Collection - http://bookmarks.debian.net/ signature.asc Description: This is a digitally signed message part.
Re: [PATCH] Btrfs: change how we mount subvolumes
Hi,
When I made snapshot listing, I thought 'subvol' parameter
is not enough as G.Baroncelli wrote. I think nice feature too.
(I tried to expand subvol parameter feature, by iterating
dentry search(lookup_one_len) but I cannot treat dentries
correctly yet. :)
But, is 'subvol=name' not prohibited yet? When I specified
'subvol=name', mount command simply mounts filesystem root
without error.
Josef Bacik wrote:
This work is in preperation for being able to set a different root as the
default mounting root.
There is currently a problem with how we mount subvolumes. We cannot
currently
mount a subvolume of a subvolume, you can only mount subvolumes/snapshots of
the
default subvolume. So say you take a snapshot of the default subvolume and
call
it snap1, and then take a snapshot of snap1 and call it snap2, so now you have
/
/snap1
/snap1/snap2
as your available volumes. Currently you can only mount / and /snap1, you
cannot mount /snap1/snap2. To fix this problem instead of passing
subvol=name
you must pass in subvol=treeid, where treeid is the tree id that gets spit
out via the subvolume listing you get from the subvolume listing patches
(btrfsctl -l). This allows us to mount /, /snap1 and /snap1/snap2 as the root
volume.
In addition to the above, we also now read the default dir item in the tree
root
to get the root key that it points to. For now this just points at what has
always been the default subvolme, but later on I plan to change it to point at
whatever root you want to be the new default root, so you can just set the
default mount and not have to mount with -o subvol=treeid. I tested this
out
with the above scenario and it worked perfectly. Thanks,
Signed-off-by: Josef Bacik jo...@redhat.com
---
fs/btrfs/ctree.h |2 +-
fs/btrfs/export.c |4 +-
fs/btrfs/inode.c | 10 ++-
fs/btrfs/relocation.c |2 +-
fs/btrfs/super.c | 167 +++-
fs/btrfs/tree-log.c |2 +-
6 files changed, 133 insertions(+), 54 deletions(-)
diff --git a/fs/btrfs/ctree.h b/fs/btrfs/ctree.h
index 444b3e9..464f688 100644
--- a/fs/btrfs/ctree.h
+++ b/fs/btrfs/ctree.h
@@ -2318,7 +2318,7 @@ int btrfs_init_cachep(void);
void btrfs_destroy_cachep(void);
long btrfs_ioctl_trans_end(struct file *file);
struct inode *btrfs_iget(struct super_block *s, struct btrfs_key *location,
- struct btrfs_root *root);
+ struct btrfs_root *root, int *was_new);
int btrfs_commit_write(struct file *file, struct page *page,
unsigned from, unsigned to);
struct extent_map *btrfs_get_extent(struct inode *inode, struct page *page,
diff --git a/fs/btrfs/export.c b/fs/btrfs/export.c
index ba5c3fd..951ef09 100644
--- a/fs/btrfs/export.c
+++ b/fs/btrfs/export.c
@@ -95,7 +95,7 @@ static struct dentry *btrfs_get_dentry(struct super_block
*sb, u64 objectid,
btrfs_set_key_type(key, BTRFS_INODE_ITEM_KEY);
key.offset = 0;
- inode = btrfs_iget(sb, key, root);
+ inode = btrfs_iget(sb, key, root, NULL);
if (IS_ERR(inode)) {
err = PTR_ERR(inode);
goto fail;
@@ -223,7 +223,7 @@ static struct dentry *btrfs_get_parent(struct dentry
*child)
key.type = BTRFS_INODE_ITEM_KEY;
key.offset = 0;
- dentry = d_obtain_alias(btrfs_iget(root-fs_info-sb, key, root));
+ dentry = d_obtain_alias(btrfs_iget(root-fs_info-sb, key, root,
NULL));
if (!IS_ERR(dentry))
dentry-d_op = btrfs_dentry_operations;
return dentry;
diff --git a/fs/btrfs/inode.c b/fs/btrfs/inode.c
index b3ad168..b383e53 100644
--- a/fs/btrfs/inode.c
+++ b/fs/btrfs/inode.c
@@ -2131,7 +2131,7 @@ void btrfs_orphan_cleanup(struct btrfs_root *root)
found_key.objectid = found_key.offset;
found_key.type = BTRFS_INODE_ITEM_KEY;
found_key.offset = 0;
- inode = btrfs_iget(root-fs_info-sb, found_key, root);
+ inode = btrfs_iget(root-fs_info-sb, found_key, root, NULL);
if (IS_ERR(inode))
break;
@@ -3609,7 +3609,7 @@ static struct inode *btrfs_iget_locked(struct
super_block *s,
* Returns in *is_new if the inode was read from disk
*/
struct inode *btrfs_iget(struct super_block *s, struct btrfs_key *location,
- struct btrfs_root *root)
+ struct btrfs_root *root, int *new)
{
struct inode *inode;
@@ -3624,6 +3624,8 @@ struct inode *btrfs_iget(struct super_block *s, struct
btrfs_key *location,
inode_tree_add(inode);
unlock_new_inode(inode);
+ if (new)
+ *new = 1;
}
return inode;
@@ -3676,7 +3678,7 @@ struct inode *btrfs_lookup_dentry(struct inode *dir,
struct dentry *dentry)
return NULL;
if (location.type
[PATCH] Btrfs: fix comipler warning with tree_search
fix comipler warning with tree_search
Signed-off-by: Li Dongyang jerry87...@gmail.com
---
fs/btrfs/ordered-data.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/fs/btrfs/ordered-data.c b/fs/btrfs/ordered-data.c
index ab21c29..8877fa0 100644
--- a/fs/btrfs/ordered-data.c
+++ b/fs/btrfs/ordered-data.c
@@ -133,7 +133,7 @@ static inline struct rb_node *tree_search(struct
btrfs_ordered_inode_tree *tree,
u64 file_offset)
{
struct rb_root *root = tree-tree;
- struct rb_node *prev;
+ struct rb_node *prev = NULL;
struct rb_node *ret;
struct btrfs_ordered_extent *entry;
--
1.6.5.3
--
To unsubscribe from this list: send the line unsubscribe linux-btrfs in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] Btrfs: add ioctl to set the default mount subvol
Hi, Josef.
Thank you for your considering listing patch.
For now, snapshot listing starts with mounted directory,
but I thought listing by subvol id is needed, considering
'subvol' option (and now, your patch).
I made a 'subvol id' patch, but if you have another idea,
could you tell me?
Regards,
taruisi
Josef Bacik wrote:
This patch needs to go along with my previous patch. This lets us set the
default dir item's location to whatever root we want to use as our default
mounting subvol. With this we don't have to use mount -o subvol=tree id
anymore to mount a different subvol, we can just set the new one and it will
just magically work. I've just done some superficial testing on this, but it
works well enough. It breaks the snapshot listing thing so don't try and use
that with this patch, I will fix that later, I just want to run this by
everybody to make sure this is what we want. Thanks,
Signed-off-by: Josef Bacik jo...@redhat.com
---
fs/btrfs/ioctl.c | 64
++
fs/btrfs/ioctl.h |2 +
2 files changed, 66 insertions(+), 0 deletions(-)
diff --git a/fs/btrfs/ioctl.c b/fs/btrfs/ioctl.c
index c157eb7..9b747a9 100644
--- a/fs/btrfs/ioctl.c
+++ b/fs/btrfs/ioctl.c
@@ -1551,6 +1551,68 @@ out:
return ret;
}
+static long btrfs_ioctl_default_subvol(struct file *file, void __user *argp)
+{
+ struct inode *inode = fdentry(file)-d_inode;
+ struct btrfs_root *root = BTRFS_I(inode)-root;
+ struct btrfs_root *new_root;
+ struct btrfs_dir_item *di;
+ struct btrfs_trans_handle *trans;
+ struct btrfs_path *path;
+ struct btrfs_key location;
+ struct btrfs_disk_key disk_key;
+ u64 objectid = 0;
+ u64 dir_id;
+
+ if (copy_from_user(objectid, argp, sizeof(objectid)))
+ return -EFAULT;
+
+ if (!objectid)
+ objectid = root-root_key.objectid;
+
+ location.objectid = objectid;
+ location.type = BTRFS_ROOT_ITEM_KEY;
+ location.offset = (u64)-1;
+
+ new_root = btrfs_read_fs_root_no_name(root-fs_info, location);
+ if (IS_ERR(new_root))
+ return PTR_ERR(new_root);
+
+ if (btrfs_root_refs(new_root-root_item) == 0)
+ return -ENOENT;
+
+ path = btrfs_alloc_path();
+ if (!path)
+ return -ENOMEM;
+ path-leave_spinning = 1;
+
+ trans = btrfs_start_transaction(root, 1);
+ if (!trans) {
+ btrfs_free_path(path);
+ return -ENOMEM;
+ }
+
+ dir_id = btrfs_super_root_dir(root-fs_info-super_copy);
+ di = btrfs_lookup_dir_item(trans, root-fs_info-tree_root, path,
+dir_id, default, 7, 1);
+ if (!di) {
+ btrfs_free_path(path);
+ btrfs_end_transaction(trans, root);
+ printk(KERN_ERR Umm, you don't have the default dir item,
+this isn't going to work\n);
+ return -ENOENT;
+ }
+
+ btrfs_cpu_key_to_disk(disk_key, new_root-root_key);
+ btrfs_set_dir_item_key(path-nodes[0], di, disk_key);
+ btrfs_mark_buffer_dirty(path-nodes[0]);
+ btrfs_free_path(path);
+
+ btrfs_end_transaction(trans, root);
+
+ return 0;
+}
+
/*
* there are many ways the trans_start and trans_end ioctls can lead
* to deadlocks. They should only be used by applications that
@@ -1597,6 +1659,8 @@ long btrfs_ioctl(struct file *file, unsigned int
return btrfs_ioctl_snap_create(file, argp, 1);
case BTRFS_IOC_SNAP_DESTROY:
return btrfs_ioctl_snap_destroy(file, argp);
+ case BTRFS_IOC_DEFAULT_SUBVOL:
+ return btrfs_ioctl_default_subvol(file, argp);
case BTRFS_IOC_DEFRAG:
return btrfs_ioctl_defrag(file);
case BTRFS_IOC_RESIZE:
diff --git a/fs/btrfs/ioctl.h b/fs/btrfs/ioctl.h
index 18c554b..9e5074c 100644
--- a/fs/btrfs/ioctl.h
+++ b/fs/btrfs/ioctl.h
@@ -96,4 +96,6 @@ struct btrfs_ioctl_clone_range_args {
struct btrfs_ioctl_vol_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)
+
#endif
--
taruisi
--
To unsubscribe from this list: send the line unsubscribe linux-btrfs in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Q: list btrfs snapshots/subvolumes
Some questions: * how do I list available snapshots/subvolumes? As for this question, we will soon be able to list available snapshots/subvolumes with btrfsctl utility. But for now, we should count number of BTRFS_ROOT_ITEMs with btrfs-debug-tree or so. Regards, taruisi -- To unsubscribe from this list: send the line unsubscribe linux-btrfs in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
