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 <[email protected]> > --- > 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 [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
