Re: [RFC] Removing a subvolume by an ordinary user
Hi all,
enclosed you can find a patch which permits to remove a volume via the
rmdir(2) syscall by an ordinary user.
The rules for a subvolume removal are the same ones of a directory:
- the user shall have the write permission on the parent directory
- the subvolume shall be empty
Comments are welcome
Reagrds
G.Baroncelli
NB: this is code is not fully tested, handle with care.
diff --git a/fs/btrfs/inode.c b/fs/btrfs/inode.c
index f08427c..47d11d8 100644
--- a/fs/btrfs/inode.c
+++ b/fs/btrfs/inode.c
@@ -2944,6 +2944,86 @@ int btrfs_unlink_subvol(struct btrfs_trans_handle *trans,
return 0;
}
+int may_destroy_subvol(struct btrfs_root *root);
+static noinline int btrfs_snap_destroy(struct inode *dir,
+ struct dentry *dentry)
+
+{
+
+ struct inode *inode;
+ struct btrfs_root *root = BTRFS_I(dir)-root;
+ struct btrfs_root *dest = NULL;
+ struct btrfs_trans_handle *trans;
+
+ int ret;
+ int err = 0;
+
+
+ if (IS_ERR(dentry)) {
+ err = PTR_ERR(dentry);
+ goto out;
+ }
+
+ if (!dentry-d_inode) {
+ err = -ENOENT;
+ goto out;
+ }
+
+ inode = dentry-d_inode;
+ if (inode-i_ino != BTRFS_FIRST_FREE_OBJECTID) {
+ err = -EINVAL;
+ goto out;
+ }
+
+ dest = BTRFS_I(inode)-root;
+
+ down_write(root-fs_info-subvol_sem);
+
+ err = may_destroy_subvol(dest);
+ if (err)
+ goto out_up_write;
+
+ trans = btrfs_start_transaction(root, 0);
+ if (IS_ERR(trans)) {
+ err = PTR_ERR(trans);
+ goto out_up_write;
+ }
+ trans-block_rsv = root-fs_info-global_block_rsv;
+
+ ret = btrfs_unlink_subvol(trans, root, dir,
+ dest-root_key.objectid,
+ dentry-d_name.name,
+ dentry-d_name.len);
+ BUG_ON(ret);
+
+ btrfs_record_root_in_trans(trans, dest);
+
+ memset(dest-root_item.drop_progress, 0,
+ sizeof(dest-root_item.drop_progress));
+ dest-root_item.drop_level = 0;
+ btrfs_set_root_refs(dest-root_item, 0);
+
+ if (!xchg(dest-orphan_item_inserted, 1)) {
+ ret = btrfs_insert_orphan_item(trans,
+ root-fs_info-tree_root,
+ dest-root_key.objectid);
+ BUG_ON(ret);
+ }
+
+ ret = btrfs_commit_transaction(trans, root);
+ BUG_ON(ret);
+ inode-i_flags |= S_DEAD;
+out_up_write:
+ up_write(root-fs_info-subvol_sem);
+ if (!err) {
+ shrink_dcache_sb(root-fs_info-sb);
+ btrfs_invalidate_inodes(dest);
+ /*d_delete(dentry);*/
+ }
+out:
+ return err;
+}
+
static int btrfs_rmdir(struct inode *dir, struct dentry *dentry)
{
struct inode *inode = dentry-d_inode;
@@ -2952,10 +3032,12 @@ static int btrfs_rmdir(struct inode *dir, struct dentry
*dentry)
struct btrfs_trans_handle *trans;
unsigned long nr = 0;
- if (inode-i_size BTRFS_EMPTY_DIR_SIZE ||
- inode-i_ino == BTRFS_FIRST_FREE_OBJECTID)
+ if (inode-i_size BTRFS_EMPTY_DIR_SIZE)
return -ENOTEMPTY;
+ if (inode-i_ino == BTRFS_FIRST_FREE_OBJECTID)
+ return btrfs_snap_destroy(dir, dentry);
+
trans = __unlink_start_trans(dir, dentry);
if (IS_ERR(trans))
return PTR_ERR(trans);
@@ -4242,7 +4324,6 @@ static int btrfs_real_readdir(struct file *filp, void
*dirent,
over = filldir(dirent, name_ptr, name_len,
found_key.offset, location.objectid,
d_type);
-
skip:
if (name_ptr != tmp_name)
kfree(name_ptr);
diff --git a/fs/btrfs/ioctl.c b/fs/btrfs/ioctl.c
index 9254b3d..a7b242e 100644
--- a/fs/btrfs/ioctl.c
+++ b/fs/btrfs/ioctl.c
@@ -855,7 +855,7 @@ out:
/*
* helper to check if the subvolume references other subvolumes
*/
-static noinline int may_destroy_subvol(struct btrfs_root *root)
+int may_destroy_subvol(struct btrfs_root *root)
{
struct btrfs_path *path;
struct btrfs_key key;
--
gpg key@ keyserver.linux.it: Goffredo Baroncelli (ghigo) kreijackATinwind.it
Key fingerprint = 4769 7E51 5293 D36C 814E C054 BF04 F161 3DC5 0512
signature.asc
Description: This is a digitally signed message part.
Question of stability
Hi all I've been on this list for a year or so, and I have been following progress for some more. Are there any chances of btrfs stabilizing, as in terms of usability in production? If so, how far are we from this? Also, what about the RAID-[56] parts, they were announced more than a year ago, but still I can't see anything in the open. Vennlige hilsener / Best regards roy -- Roy Sigurd Karlsbakk (+47) 97542685 r...@karlsbakk.net http://blogg.karlsbakk.net/ -- I all pedagogikk er det essensielt at pensum presenteres intelligibelt. Det er et elementært imperativ for alle pedagoger å unngå eksessiv anvendelse av idiomer med fremmed opprinnelse. I de fleste tilfeller eksisterer adekvate og relevante synonymer på norsk. -- 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: Question of stability
On Sat, Sep 18, 2010 at 11:37 PM, Roy Sigurd Karlsbakk r...@karlsbakk.net wrote: Hi all I've been on this list for a year or so, and I have been following progress for some more. Are there any chances of btrfs stabilizing, as in terms of usability in production? If so, how far are we from this? Hi, I am using btrfs as my root filesystem on my Debian squeeze machine for a few month now and so far I haven't experienced any problems. It seems quite stable for me. I am not using raid functions, but am also very interested in the progress in raid5/6. Regards, Hendrik -- 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: Question of stability
- Original Message - On Sat, Sep 18, 2010 at 11:37 PM, Roy Sigurd Karlsbakk r...@karlsbakk.net wrote: Hi all I've been on this list for a year or so, and I have been following progress for some more. Are there any chances of btrfs stabilizing, as in terms of usability in production? If so, how far are we from this? Hi, I am using btrfs as my root filesystem on my Debian squeeze machine for a few month now and so far I haven't experienced any problems. It seems quite stable for me. I am not using raid functions, but am also very interested in the progress in raid5/6. I was more interested in large setups than a general install. Question remains, when is btrfs supposed to be stable, as in usable for large server setups? Vennlige hilsener / Best regards roy -- Roy Sigurd Karlsbakk (+47) 97542685 r...@karlsbakk.net http://blogg.karlsbakk.net/ -- I all pedagogikk er det essensielt at pensum presenteres intelligibelt. Det er et elementært imperativ for alle pedagoger å unngå eksessiv anvendelse av idiomer med fremmed opprinnelse. I de fleste tilfeller eksisterer adekvate og relevante synonymer på norsk. -- 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: Question of stability
On Sep 18, 2010, at 6:55 PM, Roy Sigurd Karlsbakk r...@karlsbakk.net wrote: - Original Message - On Sat, Sep 18, 2010 at 11:37 PM, Roy Sigurd Karlsbakk r...@karlsbakk.net wrote: Hi all I've been on this list for a year or so, and I have been following progress for some more. Are there any chances of btrfs stabilizing, as in terms of usability in production? If so, how far are we from this? Hi, I am using btrfs as my root filesystem on my Debian squeeze machine for a few month now and so far I haven't experienced any problems. It seems quite stable for me. I am not using raid functions, but am also very interested in the progress in raid5/6. I was more interested in large setups than a general install. Question remains, when is btrfs supposed to be stable, as in usable for large server setups? Stable is a pretty subjective term; many don't even think ext4 is stable. I've used it on my personal machine since .30-31-ish without problems, and on a server w/raid 1 for about a year (btrfs + lxc is niiice, for VMs) also free of problems. However, if you've been on the list you know that some do encounter seemingly catastrophic problems, though the list is helpful in recovering data. So, it's really going to depends on your workload and integrity needs. I remeber someone recently using it for continuous build servers successfully -- 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: Question of stability
Stable is a pretty subjective term; many don't even think ext4 is stable. I've used it on my personal machine since .30-31-ish without problems, and on a server w/raid 1 for about a year (btrfs + lxc is niiice, for VMs) also free of problems. However, if you've been on the list you know that some do encounter seemingly catastrophic problems, though the list is helpful in recovering data. So, it's really going to depends on your workload and integrity needs. I remeber someone recently using it for continuous build servers successfully The term stable may be subjective at times, but for btrfs to be stable, it needs a working filesystem, with offline or online fsck abilities, and allowing for what's in the idea of btrfs, that is, checksumming everything, allowing snapshots and rollbacks et cetera. If btrfs is only stable as in ext4, well, why not just use ext4? The whole reason for btrfs to exist is to bring something new into the Linux world, and if those features aren't stable, then btrfs isn't. It's as simple as that. Would you buy a Subaru (or something) 4wd with a 2wd working? Vennlige hilsener / Best regards roy -- Roy Sigurd Karlsbakk (+47) 97542685 r...@karlsbakk.net http://blogg.karlsbakk.net/ -- I all pedagogikk er det essensielt at pensum presenteres intelligibelt. Det er et elementært imperativ for alle pedagoger å unngå eksessiv anvendelse av idiomer med fremmed opprinnelse. I de fleste tilfeller eksisterer adekvate og relevante synonymer på norsk. -- 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: Question of stability
On Sat, Sep 18, 2010 at 9:00 PM, Roy Sigurd Karlsbakk r...@karlsbakk.net wrote: Stable is a pretty subjective term; many don't even think ext4 is stable. I've used it on my personal machine since .30-31-ish without problems, and on a server w/raid 1 for about a year (btrfs + lxc is niiice, for VMs) also free of problems. However, if you've been on the list you know that some do encounter seemingly catastrophic problems, though the list is helpful in recovering data. So, it's really going to depends on your workload and integrity needs. I remeber someone recently using it for continuous build servers successfully The term stable may be subjective at times, but for btrfs to be stable, it needs a working filesystem, with offline or online fsck abilities, and allowing for what's in the idea of btrfs, that is, checksumming everything, allowing snapshots and rollbacks et cetera. If btrfs is only stable as in ext4, well, why not just use ext4? The whole reason for btrfs to exist is to bring something new into the Linux world, and if those features aren't stable, then btrfs isn't. It's as simple as that. Would you buy a Subaru (or something) 4wd with a 2wd working? whoa, relax; that's a terrible analogy ;-) ) the term stability is _always_ subjective ) fsck has nothing to do with the filesystem itself, and does not contribute to it's operational stability ) checksums work fine ) snapshots work fine ) rollbacks are an implementation detail using snapshots; has nothing to do w/filesystem, afiak ) ehm, i suppose you would use btrfs over ext4 because you need it's features? beats me; you decide :-) ) have proper backup/failover options and it won't matter which you choose ) i'm sure that's not a reason ;-) ) btrfs has several pending/potential features/patches/branches floating around such as raid5/6, hot data awareness, etc. -- these unimplemented features (likely) do not detract from the stability of what's implemented now i apologize for the terseness, but i'm not sure what you're after exactly -- you said you have been on the list for a year, and thus should already have a pretty good idea of the current state, and what you can/cannot do? this (vague and _subjective_) question pops up from time to time, along with questions about raid5/6, etc., and they pretty much receive the same response i gave you: ) not everything possible/interesting is planned ) not everything planned is implemented ) some people run into big problems ) the majority likely does not ) use at your own risk ) many, including myself and the previous responder, are currently using it for a wide range of capacities, successfully, and collectively believe the minds responsible for btrfs must be rather competent folk, because for the most part... things are pretty quiet around here :-) C Anthony -- 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
