Re: [PATCH V3] Removing a subvolume with a simple "rm -rf"
On Sun, 2010-10-17 at 18:09 +0200, Goffredo Baroncelli wrote:
> Hi all,
>
> enclosed you can find a new version of the patch which permits to remove a
> volume via the rmdir(2) syscall by a non-root user. The goal of this patch
> is to permits to remove a subvolume with a simple "rm -rf" command.
>
> The rules for a subvolume removal are the same ones of a directory:
> - the user must have the write permission on the parent directory
> - the subvolume must be empty
>
> The mains differences between calling rmdir(2) on a subvolume and calling the
> BTRFS_IOC_SNAP_DESTROY ioctl are:
>
> - rmdir(2) requires the subvolume to be empty (the user has to empty the
> subvolume before removing it, like the rm -rf command does)
> - rmdir(2) is a synchronous operation (instead BTRFS_IOC_SNAP_DESTROY works
> in background)
>
> The previous statements have the following (nice) consequences:
>
> - the CAP_ADMIN capability is not mandatory anymore to remove a subvolume.
> BTRFS_IOC_SNAP_DESTROY requires CAP_ADMIN because the subvolume removal is
> performed in background so it would not be possible to return an error if
> the user has not the privilege of removing a file. This explain why this ioctl
> may be executed only by root.
>
> - When the rmdir(2) syscall returns, the space is really freed.
>
> The only advantage of the BTRFS_IOC_SNAP_DESTROY ioctl is its greater speed
> in removing a not empty subvolume.
>
> I simplify the code respect my previous post, removing a un-needed call to the
> function may_destroy_subvol(). Moreover I added a call to the d_invalidate()
> function, which was missed in my previous version.
>
> You can pull the code from the branch named "rmdir-subvolume" of the following
> repository:
>
> http://cassiopea.homelinux.net/git/btrfs-unstable.git
>
> As usual, comments are welcome
>
> Regards
> G.Baroncelli
>
>
> diff --git a/fs/btrfs/inode.c b/fs/btrfs/inode.c
> index f08427c..f732ddf 100644
> --- a/fs/btrfs/inode.c
> +++ b/fs/btrfs/inode.c
> @@ -2944,6 +2944,88 @@ int btrfs_unlink_subvol(struct btrfs_trans_handle
> *trans,
> return 0;
> }
>
> +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;
> +
> + err = d_invalidate(dentry);
> + if (err)
> + goto out;
> +
> + down_write(&root->fs_info->subvol_sem);
> +
> + /* remove this check because the directory is empty.
> + * 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;
> + }
Mmm ... sorry to be picky but can this really fail?
Won't you be left with a dentry invisible to the VFS but with an
existing subvol?
> + 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);
What happens if this fails?
Will the file system look corrupt after the reboot, or will the
transaction simply not have been flushed to the disk (ie. not committed
I guess), leaving it looking OK?
> +
> + 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);
Same Q?
> + }
> +
> + ret = btrfs_commit_transaction(trans, root);
> + BUG_ON(ret);
And again?
> + 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 *
Re: [PATCH V2] Removing a subvolume by an ordinary user
On Sun, 2010-10-17 at 17:53 +0200, Goffredo Baroncelli wrote: > On Tuesday, 12 October, 2010, Ian Kent wrote: > > On Mon, 2010-10-11 at 20:08 +0200, Goffredo Baroncelli wrote: > [...] > > > + ret = btrfs_unlink_subvol(trans, root, dir, > > > + dest->root_key.objectid, > > > + dentry->d_name.name, > > > + dentry->d_name.len); > > > + BUG_ON(ret); > > > > Is it really a good idea to add even more dead end BUG_ON() calls > > instead of handling errors when they happen? > > > > I agree with your comment, I copied these lines from the ioctl DESTROY_SUBVOL. > Unfortunately I don't have the know-how to handle an error at this level. So > I > can only leave the code as the original one. Right, sadly someone is going to have to go through and reconcile all these things at some point. I picked a function and started analyzing what would be needed (including dependent functions) to handle the error return instead of BUG_ON()ing and it's not trivial at all. Ian -- 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: FS consistency while snapshoting
On 18/10/10 13:47, Fabrício dos Anjos Silva wrote: > If there is any difference betweens kernel 2.6.21 and 2.6.35, > please point it out. btrfs wasn't merged into the mainline kernel until 2.6.29. http://lwn.net/Articles/314325/ -- Chris Samuel : http://www.csamuel.org/ : Melbourne, VIC -- 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
FS consistency while snapshoting
Hi, I want to use AWS EC2 EBS snapshot capability and while doing this, I want to make sure that Btrfs is consistent. I already know how to proceed when using XFS in the two scenarios that follow: 1) XFS on EBS Freeze XFS by using "xfs_freeze -f", then create EBS snapshot, then unfreeze XFS by using "xfs_freeze -u". 2) XFS on LVM XFS is automatically frozen/unfrozen when LVM snapshot is requested. What I don't know is how to proceed in the following scenarios: 3) Btrfs on EBS What commands need to be executed to freeze/unfreeze Btrfs when requesting EBS snapshot? 4) Btrfs on LVM Is Btrfs automatically frozen/unfrozen when requesting LVM snapshot? 5) LVM on EBS What command needs to be executed to freeze/unfreeze LVM? What about the FS on top of LVM? I know that scenario 5 is not Btrfs related, but I appreciate if someone could help me with that too. I also know that there is no need to use Btrfs on LVM, but the question remains. If there is any difference betweens kernel 2.6.21 and 2.6.35, please point it out. Thank you, Fabrício dos Anjos Silva LinkCom Soluções em T.I. -- 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: the idea for improving the performance of b-tree search
Hi Miao & Chris, On Wed, Oct 13, 2010 at 05:00:56PM +0800, Miao Xie wrote: > When I investigated the performance problem of file creation/deletion, I found > btrfs spends lots of time in the b-tree search, so I consider whether we can > use > the latest search result in the same transaction or not. > > My idea follows: > we can add mask or time stamp into b-tree's node and leaf, then we know > whether > the node/leaf is COWed by the other task. If not, we check if the node/leaf of > the latest search result contains the key that we want to search. By this way, > we can reuse the latest search result in the same transaction and reduce the > CPU > time spent in the b-tree search. Does this patch help a little for the tree search? http://marc.info/?l=linux-btrfs&m=127175532803943&w=2 It doesn't solve all the issues, but in my test, it does help. Thanks, Shaohua -- 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
[patch 1/4] Update pretty-printer for different multiple systems.
Make the pretty-printer for data sizes capable of printing in ISO
(powers of 10^3), binary (powers of 2^10) or raw (a simple byte
count).
We default to binary sizes, maintaining the original behaviour, but
print (e.g.) MiB to indicate that it's a power of 2^10.
Signed-off-by: Hugo Mills
---
btrfs-show.c |7 ---
btrfs_cmds.c | 13 -
mkfs.c |3 ++-
utils.c | 48 +---
utils.h |7 ++-
5 files changed, 53 insertions(+), 25 deletions(-)
Index: btrfs-progs-unstable/btrfs-show.c
===
--- btrfs-progs-unstable.orig/btrfs-show.c 2010-10-17 18:13:29.0
+0100
+++ btrfs-progs-unstable/btrfs-show.c 2010-10-17 19:00:34.0 +0100
@@ -69,7 +69,8 @@
else
printf("Label: none ");
- super_bytes_used = pretty_sizes(device->super_bytes_used);
+ super_bytes_used = pretty_sizes(device->super_bytes_used,
+
PRETTY_SIZE_BINARY);
total = device->total_devs;
printf(" uuid: %s\n\tTotal devices %llu FS bytes used %s\n", uuidbuf,
@@ -81,8 +82,8 @@
char *total_bytes;
char *bytes_used;
device = list_entry(cur, struct btrfs_device, dev_list);
- total_bytes = pretty_sizes(device->total_bytes);
- bytes_used = pretty_sizes(device->bytes_used);
+ total_bytes = pretty_sizes(device->total_bytes,
PRETTY_SIZE_BINARY);
+ bytes_used = pretty_sizes(device->bytes_used,
PRETTY_SIZE_BINARY);
printf("\tdevid %4llu size %s used %s path %s\n",
(unsigned long long)device->devid,
total_bytes, bytes_used, device->name);
Index: btrfs-progs-unstable/btrfs_cmds.c
===
--- btrfs-progs-unstable.orig/btrfs_cmds.c 2010-10-17 18:13:29.0
+0100
+++ btrfs-progs-unstable/btrfs_cmds.c 2010-10-17 19:00:39.0 +0100
@@ -634,7 +634,8 @@
else
printf("Label: none ");
- super_bytes_used = pretty_sizes(device->super_bytes_used);
+ super_bytes_used = pretty_sizes(device->super_bytes_used,
+
PRETTY_SIZE_BINARY);
total = device->total_devs;
printf(" uuid: %s\n\tTotal devices %llu FS bytes used %s\n", uuidbuf,
@@ -646,8 +647,8 @@
char *total_bytes;
char *bytes_used;
device = list_entry(cur, struct btrfs_device, dev_list);
- total_bytes = pretty_sizes(device->total_bytes);
- bytes_used = pretty_sizes(device->bytes_used);
+ total_bytes = pretty_sizes(device->total_bytes,
PRETTY_SIZE_BINARY);
+ bytes_used = pretty_sizes(device->bytes_used,
PRETTY_SIZE_BINARY);
printf("\tdevid %4llu size %s used %s path %s\n",
(unsigned long long)device->devid,
total_bytes, bytes_used, device->name);
@@ -913,8 +914,10 @@
written += 8;
}
- total_bytes = pretty_sizes(sargs->spaces[i].total_bytes);
- used_bytes = pretty_sizes(sargs->spaces[i].used_bytes);
+ total_bytes = pretty_sizes(sargs->spaces[i].total_bytes,
+
PRETTY_SIZE_BINARY);
+ used_bytes = pretty_sizes(sargs->spaces[i].used_bytes,
+
PRETTY_SIZE_BINARY);
printf("%s: total=%s, used=%s\n", description, total_bytes,
used_bytes);
}
Index: btrfs-progs-unstable/mkfs.c
===
--- btrfs-progs-unstable.orig/mkfs.c2010-10-17 18:13:29.0 +0100
+++ btrfs-progs-unstable/mkfs.c 2010-10-17 18:15:08.0 +0100
@@ -524,7 +524,8 @@
printf("fs created label %s on %s\n\tnodesize %u leafsize %u "
"sectorsize %u size %s\n",
label, first_file, nodesize, leafsize, sectorsize,
- pretty_sizes(btrfs_super_total_bytes(&root->fs_info->super_copy)));
+
pretty_sizes(btrfs_super_total_bytes(&root->fs_info->super_copy),
+ PRETTY_SIZE_BINARY));
printf("%s\n", BTRFS_BUILD_VERSION);
btrfs_commit_transaction(trans, root);
Index: btrfs-progs-unstable/utils.c
===
--- btrfs-progs-unstable.orig/utils.c 2010-10-17 18:13:29.0 +0100
+++ btrfs-progs-unstable/utils.c2010-10-17 18:44:13.0 +0100
@@ -966,30 +966,48 @@
return ret;
}
-static char *size_strs[] = { "", "KB", "MB", "GB", "TB",
+static char *
[patch 2/4] Add an option to show ISO, binary or raw bytes counts using df.
Change btrfs filesystem df to allow the user to control the scales
used for sizes in the output.
Signed-off-by: Hugo Mills
---
btrfs.c |5 +++--
btrfs_cmds.c | 37 -
2 files changed, 35 insertions(+), 7 deletions(-)
Index: btrfs-progs-unstable/btrfs.c
===
--- btrfs-progs-unstable.orig/btrfs.c 2010-10-17 18:43:57.0 +0100
+++ btrfs-progs-unstable/btrfs.c2010-10-17 18:47:36.0 +0100
@@ -87,9 +87,10 @@
"Show the info of a btrfs filesystem. If no or \n"
"is passed, info of all the btrfs filesystem are shown."
},
- { do_df_filesystem, 1,
- "filesystem df", "\n"
+ { do_df_filesystem, -1,
+ "filesystem df", "[-r|-b|-i] \n"
"Show space usage information for a mount point\n."
+ "-r, -b, -i for raw (bytes), binary or ISO sizes."
},
{ do_balance, 1,
"filesystem balance", "\n"
Index: btrfs-progs-unstable/btrfs_cmds.c
===
--- btrfs-progs-unstable.orig/btrfs_cmds.c 2010-10-17 18:43:57.0
+0100
+++ btrfs-progs-unstable/btrfs_cmds.c 2010-10-17 18:47:36.0 +0100
@@ -841,7 +841,36 @@
u64 count = 0, i;
int ret;
int fd;
- char *path = argv[1];
+ char *path;
+ int format = PRETTY_SIZE_BINARY;
+
+ optind = 1;
+ while(1) {
+ int c = getopt(nargs, argv, "rbi");
+ if (c < 0)
+ break;
+ switch(c) {
+ case 'r':
+ format = PRETTY_SIZE_RAW;
+ break;
+ case 'b':
+ format = PRETTY_SIZE_BINARY;
+ break;
+ case 'i':
+ format = PRETTY_SIZE_ISO;
+ break;
+ default:
+ fprintf(stderr, "Invalid arguments for df\n");
+ free(argv);
+ return 1;
+ }
+ }
+ if (nargs - optind != 1) {
+ fprintf(stderr, "No path given for df\n");
+ free(argv);
+ return 1;
+ }
+ path = argv[optind];
fd = open_file_or_dir(path);
if (fd < 0) {
@@ -914,10 +943,8 @@
written += 8;
}
- total_bytes = pretty_sizes(sargs->spaces[i].total_bytes,
-
PRETTY_SIZE_BINARY);
- used_bytes = pretty_sizes(sargs->spaces[i].used_bytes,
-
PRETTY_SIZE_BINARY);
+ total_bytes = pretty_sizes(sargs->spaces[i].total_bytes,
format);
+ used_bytes = pretty_sizes(sargs->spaces[i].used_bytes, format);
printf("%s: total=%s, used=%s\n", description, total_bytes,
used_bytes);
}
--
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
[patch 4/4] Add an option to show ISO, binary or raw bytes counts using btrfs-show.
Change btrfs-show to allow the user to control the scales used for
sizes in the output.
Signed-off-by: Hugo Mills
---
btrfs-show.c | 24 +---
1 file changed, 17 insertions(+), 7 deletions(-)
Index: btrfs-progs-unstable/btrfs-show.c
===
--- btrfs-progs-unstable.orig/btrfs-show.c 2010-10-17 19:00:34.0
+0100
+++ btrfs-progs-unstable/btrfs-show.c 2010-10-17 19:12:50.0 +0100
@@ -52,7 +52,7 @@
return 0;
}
-static void print_one_uuid(struct btrfs_fs_devices *fs_devices)
+static void print_one_uuid(struct btrfs_fs_devices *fs_devices, int format)
{
char uuidbuf[37];
struct list_head *cur;
@@ -69,8 +69,7 @@
else
printf("Label: none ");
- super_bytes_used = pretty_sizes(device->super_bytes_used,
-
PRETTY_SIZE_BINARY);
+ super_bytes_used = pretty_sizes(device->super_bytes_used, format);
total = device->total_devs;
printf(" uuid: %s\n\tTotal devices %llu FS bytes used %s\n", uuidbuf,
@@ -82,8 +81,8 @@
char *total_bytes;
char *bytes_used;
device = list_entry(cur, struct btrfs_device, dev_list);
- total_bytes = pretty_sizes(device->total_bytes,
PRETTY_SIZE_BINARY);
- bytes_used = pretty_sizes(device->bytes_used,
PRETTY_SIZE_BINARY);
+ total_bytes = pretty_sizes(device->total_bytes, format);
+ bytes_used = pretty_sizes(device->bytes_used, format);
printf("\tdevid %4llu size %s used %s path %s\n",
(unsigned long long)device->devid,
total_bytes, bytes_used, device->name);
@@ -99,7 +98,8 @@
static void print_usage(void)
{
- fprintf(stderr, "usage: btrfs-show [search label or device]\n");
+ fprintf(stderr, "usage: btrfs-show [-i|-b|-r] [search label or
device]\n");
+ fprintf(stderr, "Options:\n -i, -b, -r: Show sizes in ISO, binary or
raw form respectively.\n");
fprintf(stderr, "%s\n", BTRFS_BUILD_VERSION);
exit(1);
}
@@ -117,6 +117,7 @@
char *search = NULL;
int ret;
int option_index = 0;
+ int format = PRETTY_SIZE_BINARY;
while(1) {
int c;
@@ -125,6 +126,15 @@
if (c < 0)
break;
switch(c) {
+ case 'i':
+ format = PRETTY_SIZE_ISO;
+ break;
+ case 'b':
+ format = PRETTY_SIZE_BINARY;
+ break;
+ case 'r':
+ format = PRETTY_SIZE_RAW;
+ break;
default:
print_usage();
}
@@ -144,7 +154,7 @@
list);
if (search && uuid_search(fs_devices, search) == 0)
continue;
- print_one_uuid(fs_devices);
+ print_one_uuid(fs_devices, format);
}
printf("%s\n", BTRFS_BUILD_VERSION);
return 0;
--
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
[patch 3/4] Add an option to show ISO, binary or raw bytes counts using show.
Change btrfs filesystem show to allow the user to control the scales
used for sizes in the output.
Signed-off-by: Hugo Mills
---
btrfs.c |5 +++--
btrfs_cmds.c | 42 +++---
2 files changed, 38 insertions(+), 9 deletions(-)
Index: btrfs-progs-unstable/btrfs.c
===
--- btrfs-progs-unstable.orig/btrfs.c 2010-10-17 18:47:36.0 +0100
+++ btrfs-progs-unstable/btrfs.c2010-10-17 18:48:38.0 +0100
@@ -83,9 +83,10 @@
"will occupe all available space on the device."
},
{ do_show_filesystem, 999,
- "filesystem show", "[|]\n"
+ "filesystem show", "[-r|-b|-i] [|]\n"
"Show the info of a btrfs filesystem. If no or \n"
- "is passed, info of all the btrfs filesystem are shown."
+ "is passed, info of all the btrfs filesystem are shown.\n"
+ "-r, -b, -i for raw (bytes), binary or ISO sizes."
},
{ do_df_filesystem, -1,
"filesystem df", "[-r|-b|-i] \n"
Index: btrfs-progs-unstable/btrfs_cmds.c
===
--- btrfs-progs-unstable.orig/btrfs_cmds.c 2010-10-17 18:47:36.0
+0100
+++ btrfs-progs-unstable/btrfs_cmds.c 2010-10-17 18:48:38.0 +0100
@@ -617,7 +617,7 @@
return 0;
}
-static void print_one_uuid(struct btrfs_fs_devices *fs_devices)
+static void print_one_uuid(struct btrfs_fs_devices *fs_devices, int format)
{
char uuidbuf[37];
struct list_head *cur;
@@ -634,8 +634,7 @@
else
printf("Label: none ");
- super_bytes_used = pretty_sizes(device->super_bytes_used,
-
PRETTY_SIZE_BINARY);
+ super_bytes_used = pretty_sizes(device->super_bytes_used, format);
total = device->total_devs;
printf(" uuid: %s\n\tTotal devices %llu FS bytes used %s\n", uuidbuf,
@@ -647,8 +646,8 @@
char *total_bytes;
char *bytes_used;
device = list_entry(cur, struct btrfs_device, dev_list);
- total_bytes = pretty_sizes(device->total_bytes,
PRETTY_SIZE_BINARY);
- bytes_used = pretty_sizes(device->bytes_used,
PRETTY_SIZE_BINARY);
+ total_bytes = pretty_sizes(device->total_bytes, format);
+ bytes_used = pretty_sizes(device->bytes_used, format);
printf("\tdevid %4llu size %s used %s path %s\n",
(unsigned long long)device->devid,
total_bytes, bytes_used, device->name);
@@ -667,8 +666,37 @@
struct list_head *all_uuids;
struct btrfs_fs_devices *fs_devices;
struct list_head *cur_uuid;
- char *search = argv[1];
+ char *search;
int ret;
+ int format = PRETTY_SIZE_BINARY;
+
+ optind = 1;
+ while(1) {
+ int c = getopt(argc, argv, "rbi");
+ if (c < 0)
+ break;
+ switch(c) {
+ case 'r':
+ format = PRETTY_SIZE_RAW;
+ break;
+ case 'b':
+ format = PRETTY_SIZE_BINARY;
+ break;
+ case 'i':
+ format = PRETTY_SIZE_ISO;
+ break;
+ default:
+ fprintf(stderr, "Invalid arguments for show\n");
+ free(argv);
+ return 1;
+ }
+ }
+ if (argc - optind > 1) {
+ fprintf(stderr, "Too many arguments for show\n");
+ free(argv);
+ return 1;
+ }
+ search = argv[optind];
ret = btrfs_scan_one_dir("/dev", 0);
if (ret){
@@ -682,7 +710,7 @@
list);
if (search && uuid_search(fs_devices, search) == 0)
continue;
- print_one_uuid(fs_devices);
+ print_one_uuid(fs_devices, format);
}
printf("%s\n", BTRFS_BUILD_VERSION);
return 0;
--
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
[patch 0/4] Size reporting of btrfs tool
While playing around with resizing volumes recently, I realised that I didn't know whether btrfs fi show and btrfs fi df reported sizes in ISO (e.g. powers of 10^3) units, as they appear to from the labels they use, or in binary (powers of 2^10) units. Also, a mere three significant figures is somewhat less than I'm comfortable with if I'm about to resize the containing block device downwards. This patch series adds the ability to pick which scale is used for show and df, and labels the amounts properly (e.g. MB for ISO, MiB for binary units). Hugo. -- === Hugo Mills: h...@... carfax.org.uk | darksatanic.net | lug.org.uk === PGP key: 515C238D from wwwkeys.eu.pgp.net or http://www.carfax.org.uk --- emacs: Eighty Megabytes And Constantly Swapping. --- -- 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
Apologies
I'm sorry about those last mails of mine. Clearly, nobody actually uses "quilt mail" to send mails. Or at least has never documented clearly how they do it. I shall test some more and try again. Irritated and embarrassed, Hugo. -- === Hugo Mills: h...@... carfax.org.uk | darksatanic.net | lug.org.uk === PGP key: 515C238D from wwwkeys.eu.pgp.net or http://www.carfax.org.uk --- emacs: Eighty Megabytes And Constantly Swapping. --- signature.asc Description: Digital signature
Re: How can I recover data from little overwritten missing raid0 device?
It seem that another device doesn't detect as btrfs filesystem anymore.(I think because its header had been overwritten.) That device is not appear when I run "btrfs filesystem show". On Sun, Oct 17, 2010 at 11:04 PM, Goffredo Baroncelli wrote: > After a reboot you need to do > > # btrfs device scan > > in order to search all devices which may be involved in a multi devices setup > (like RAID). > > G.Baroncelli > > > > > On Sunday, 17 October, 2010, Chalet16 wrote: >> UPDATE: I'm currently able to see and read/write some file in degraded mode >> but there're many file i can't read with input/output error too. >> >> >> On Sun, Oct 17, 2010 at 9:57 PM, Chalet16 wrote: >> > I had set up btrfs with 2 devices by using command this command sequence. >> > "mkfs.btrfs -m raid1 /dev/sda1 >> > mount /dev/sda1 /mnt/data >> > btrfs-vol -a /dev/sdb1 /mnt/data >> > btrfs-vol -b /mnt/data" >> > >> > (I was think that it will do raid1 for both data and metadata but I > currently >> > realised that it will do raid1 for metadata but raid0 for data.) >> > >> > But I forgot that I have mount /dev/sdb1 with TrueCrypt. After I restarted > my >> > PC and try to mount both devices array again there was a message in dmesg > said >> > "chale...@server:~$ sudo mount /dev/sda1 /mnt/data >> > [ 2828.921406] device label btr2902 devid 1 transid 8829 > /dev/mapper/truecrypt1 >> > [ 2828.931780] btrfs: failed to read the system array on dm-1 >> > [ 2828.961330] btrfs: open_ctree failed" >> > >> > And when I ran btrfs-show it show that >> > "chale...@server:~$ sudo btrfs-show >> > failed to read /dev/sr0 >> > Label: btr2902 uuid: 5673597c-ff57-4a42-8fe3-ff793f476809 >> > Total devices 2 FS bytes used 706.75GB >> > devid 1 size 930.00GB used 717.26GB path /dev/sda1 >> > *** Some devices missing >> > Btrfs Btrfs v0.19" >> > And when I run btrfsck on missing device >> > "chale...@server:~$ sudo btrfsck /dev/sde1 >> > No valid Btrfs found on /dev/sde1" >> > >> > So I would like to ask for help to recover data from this btrfs raid > array. In >> > my opinion I think that TrueCrypt only overwrite a little location in > device >> > because I haven't done anything with TrueCrypt device after that. >> > >> > Thanks >> > Chalet16 >> > >> > >> > PS. I have recently known that TrueCrypt is in "Forbidden items" list in > Fedora >> > wiki, but this is not really related to TrueCrypt so please don't ban me > because >> > I had used TrueCrypt. >> > >> -- >> 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 >> > > > -- > gpg key@ keyserver.linux.it: Goffredo Baroncelli (ghigo) > Key fingerprint = 4769 7E51 5293 D36C 814E C054 BF04 F161 3DC5 0512 > -- 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
[PATCH V3] Removing a subvolume with a simple "rm -rf"
Hi all,
enclosed you can find a new version of the patch which permits to remove a
volume via the rmdir(2) syscall by a non-root user. The goal of this patch
is to permits to remove a subvolume with a simple "rm -rf" command.
The rules for a subvolume removal are the same ones of a directory:
- the user must have the write permission on the parent directory
- the subvolume must be empty
The mains differences between calling rmdir(2) on a subvolume and calling the
BTRFS_IOC_SNAP_DESTROY ioctl are:
- rmdir(2) requires the subvolume to be empty (the user has to empty the
subvolume before removing it, like the rm -rf command does)
- rmdir(2) is a synchronous operation (instead BTRFS_IOC_SNAP_DESTROY works
in background)
The previous statements have the following (nice) consequences:
- the CAP_ADMIN capability is not mandatory anymore to remove a subvolume.
BTRFS_IOC_SNAP_DESTROY requires CAP_ADMIN because the subvolume removal is
performed in background so it would not be possible to return an error if
the user has not the privilege of removing a file. This explain why this ioctl
may be executed only by root.
- When the rmdir(2) syscall returns, the space is really freed.
The only advantage of the BTRFS_IOC_SNAP_DESTROY ioctl is its greater speed
in removing a not empty subvolume.
I simplify the code respect my previous post, removing a un-needed call to the
function may_destroy_subvol(). Moreover I added a call to the d_invalidate()
function, which was missed in my previous version.
You can pull the code from the branch named "rmdir-subvolume" of the following
repository:
http://cassiopea.homelinux.net/git/btrfs-unstable.git
As usual, comments are welcome
Regards
G.Baroncelli
diff --git a/fs/btrfs/inode.c b/fs/btrfs/inode.c
index f08427c..f732ddf 100644
--- a/fs/btrfs/inode.c
+++ b/fs/btrfs/inode.c
@@ -2944,6 +2944,88 @@ int btrfs_unlink_subvol(struct btrfs_trans_handle *trans,
return 0;
}
+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;
+
+ err = d_invalidate(dentry);
+ if (err)
+ goto out;
+
+ down_write(&root->fs_info->subvol_sem);
+
+ /* remove this check because the directory is empty.
+* 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 +3034,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
Re: How can I recover data from little overwritten missing raid0 device?
After a reboot you need to do # btrfs device scan in order to search all devices which may be involved in a multi devices setup (like RAID). G.Baroncelli On Sunday, 17 October, 2010, Chalet16 wrote: > UPDATE: I'm currently able to see and read/write some file in degraded mode > but there're many file i can't read with input/output error too. > > > On Sun, Oct 17, 2010 at 9:57 PM, Chalet16 wrote: > > I had set up btrfs with 2 devices by using command this command sequence. > > "mkfs.btrfs -m raid1 /dev/sda1 > > mount /dev/sda1 /mnt/data > > btrfs-vol -a /dev/sdb1 /mnt/data > > btrfs-vol -b /mnt/data" > > > > (I was think that it will do raid1 for both data and metadata but I currently > > realised that it will do raid1 for metadata but raid0 for data.) > > > > But I forgot that I have mount /dev/sdb1 with TrueCrypt. After I restarted my > > PC and try to mount both devices array again there was a message in dmesg said > > "chale...@server:~$ sudo mount /dev/sda1 /mnt/data > > [ 2828.921406] device label btr2902 devid 1 transid 8829 /dev/mapper/truecrypt1 > > [ 2828.931780] btrfs: failed to read the system array on dm-1 > > [ 2828.961330] btrfs: open_ctree failed" > > > > And when I ran btrfs-show it show that > > "chale...@server:~$ sudo btrfs-show > > failed to read /dev/sr0 > > Label: btr2902 uuid: 5673597c-ff57-4a42-8fe3-ff793f476809 > >Total devices 2 FS bytes used 706.75GB > >devid1 size 930.00GB used 717.26GB path /dev/sda1 > >*** Some devices missing > > Btrfs Btrfs v0.19" > > And when I run btrfsck on missing device > > "chale...@server:~$ sudo btrfsck /dev/sde1 > > No valid Btrfs found on /dev/sde1" > > > > So I would like to ask for help to recover data from this btrfs raid array. In > > my opinion I think that TrueCrypt only overwrite a little location in device > > because I haven't done anything with TrueCrypt device after that. > > > > Thanks > > Chalet16 > > > > > > PS. I have recently known that TrueCrypt is in "Forbidden items" list in Fedora > > wiki, but this is not really related to TrueCrypt so please don't ban me because > > I had used TrueCrypt. > > > -- > 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 > -- gpg key@ keyserver.linux.it: Goffredo Baroncelli (ghigo) Key fingerprint = 4769 7E51 5293 D36C 814E C054 BF04 F161 3DC5 0512 -- 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: [PATCH V2] Removing a subvolume by an ordinary user
On Tuesday, 12 October, 2010, Ian Kent wrote: > On Mon, 2010-10-11 at 20:08 +0200, Goffredo Baroncelli wrote: [...] > > + ret = btrfs_unlink_subvol(trans, root, dir, > > + dest->root_key.objectid, > > + dentry->d_name.name, > > + dentry->d_name.len); > > + BUG_ON(ret); > > Is it really a good idea to add even more dead end BUG_ON() calls > instead of handling errors when they happen? > I agree with your comment, I copied these lines from the ioctl DESTROY_SUBVOL. Unfortunately I don't have the know-how to handle an error at this level. So I can only leave the code as the original one. [...] -- gpg key@ keyserver.linux.it: Goffredo Baroncelli (ghigo) Key fingerprint = 4769 7E51 5293 D36C 814E C054 BF04 F161 3DC5 0512 -- 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: How can I recover data from little overwritten missing raid0 device?
UPDATE: I'm currently able to see and read/write some file in degraded mode but there're many file i can't read with input/output error too. On Sun, Oct 17, 2010 at 9:57 PM, Chalet16 wrote: > I had set up btrfs with 2 devices by using command this command sequence. > "mkfs.btrfs -m raid1 /dev/sda1 > mount /dev/sda1 /mnt/data > btrfs-vol -a /dev/sdb1 /mnt/data > btrfs-vol -b /mnt/data" > > (I was think that it will do raid1 for both data and metadata but I currently > realised that it will do raid1 for metadata but raid0 for data.) > > But I forgot that I have mount /dev/sdb1 with TrueCrypt. After I restarted my > PC and try to mount both devices array again there was a message in dmesg said > "chale...@server:~$ sudo mount /dev/sda1 /mnt/data > [ 2828.921406] device label btr2902 devid 1 transid 8829 > /dev/mapper/truecrypt1 > [ 2828.931780] btrfs: failed to read the system array on dm-1 > [ 2828.961330] btrfs: open_ctree failed" > > And when I ran btrfs-show it show that > "chale...@server:~$ sudo btrfs-show > failed to read /dev/sr0 > Label: btr2902 uuid: 5673597c-ff57-4a42-8fe3-ff793f476809 > Total devices 2 FS bytes used 706.75GB > devid 1 size 930.00GB used 717.26GB path /dev/sda1 > *** Some devices missing > Btrfs Btrfs v0.19" > And when I run btrfsck on missing device > "chale...@server:~$ sudo btrfsck /dev/sde1 > No valid Btrfs found on /dev/sde1" > > So I would like to ask for help to recover data from this btrfs raid array. In > my opinion I think that TrueCrypt only overwrite a little location in device > because I haven't done anything with TrueCrypt device after that. > > Thanks > Chalet16 > > > PS. I have recently known that TrueCrypt is in "Forbidden items" list in > Fedora > wiki, but this is not really related to TrueCrypt so please don't ban me > because > I had used TrueCrypt. > -- 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
How can I recover data from little overwritten missing raid0 device?
I had set up btrfs with 2 devices by using command this command sequence. "mkfs.btrfs -m raid1 /dev/sda1 mount /dev/sda1 /mnt/data btrfs-vol -a /dev/sdb1 /mnt/data btrfs-vol -b /mnt/data" (I was think that it will do raid1 for both data and metadata but I currently realised that it will do raid1 for metadata but raid0 for data.) But I forgot that I have mount /dev/sdb1 with TrueCrypt. After I restarted my PC and try to mount both devices array again there was a message in dmesg said "chale...@server:~$ sudo mount /dev/sda1 /mnt/data [ 2828.921406] device label btr2902 devid 1 transid 8829 /dev/mapper/truecrypt1 [ 2828.931780] btrfs: failed to read the system array on dm-1 [ 2828.961330] btrfs: open_ctree failed" And when I ran btrfs-show it show that "chale...@server:~$ sudo btrfs-show failed to read /dev/sr0 Label: btr2902 uuid: 5673597c-ff57-4a42-8fe3-ff793f476809 Total devices 2 FS bytes used 706.75GB devid1 size 930.00GB used 717.26GB path /dev/sda1 *** Some devices missing Btrfs Btrfs v0.19" And when I run btrfsck on missing device "chale...@server:~$ sudo btrfsck /dev/sde1 No valid Btrfs found on /dev/sde1" So I would like to ask for help to recover data from this btrfs raid array. In my opinion I think that TrueCrypt only overwrite a little location in device because I haven't done anything with TrueCrypt device after that. Thanks Chalet16 PS. I have recently known that TrueCrypt is in "Forbidden items" list in Fedora wiki, but this is not really related to TrueCrypt so please don't ban me because I had used TrueCrypt. -- 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
dkms build problem
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi, I tried to follow this howto https://btrfs.wiki.kernel.org/index.php/Btrfs_source_repositories#Building_latest_btrfs_against_a_recent_kernel_with_DKMS from the btrfs wiki to build my own btrfs module using dkms on my gentoo running kernel version 2.6.35.7. But when trying to build the dkms module I have run into the following compile error; see my make.log below. If you have any suggestions on what I should try to fix this, i.e., other kernel version(s), patches to kernel/btrfs-unstable, other compiler version(s), and so on, I am willing to try out everything in order to help fix this. If this is a known error, and the decision is to not fix it, as btrfs compiles well within the regular kernel sources from kernel.org, then I would add a comment about that in the corresponding section of the btrfs wiki. Kind regards, Andreas Philipp make.log: DKMS make.log for btrfs-git for kernel 2.6.35.7 (x86_64) Sun Oct 17 16:35:28 CEST 2010 make: Entering directory `/usr/src/linux-2.6.35.7' LD /var/lib/dkms/btrfs/git/build/built-in.o CC [M] /var/lib/dkms/btrfs/git/build/super.o /var/lib/dkms/btrfs/git/build/super.c: In function ?btrfs_fill_super?: /var/lib/dkms/btrfs/git/build/super.c:448: warning: assignment from incompatible pointer type CC [M] /var/lib/dkms/btrfs/git/build/ctree.o CC [M] /var/lib/dkms/btrfs/git/build/extent-tree.o /var/lib/dkms/btrfs/git/build/extent-tree.c: In function ?btrfs_issue_discard?: /var/lib/dkms/btrfs/git/build/extent-tree.c:1699: error: ?DISCARD_FL_BARRIER? undeclared (first use in this function) /var/lib/dkms/btrfs/git/build/extent-tree.c:1699: error: (Each undeclared identifier is reported only once /var/lib/dkms/btrfs/git/build/extent-tree.c:1699: error: for each function it appears in.) make[1]: *** [/var/lib/dkms/btrfs/git/build/extent-tree.o] Error 1 make: *** [_module_/var/lib/dkms/btrfs/git/build] Error 2 make: Leaving directory `/usr/src/linux-2.6.35.7' -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBAgAGBQJMuwzFAAoJEJIcBJ3+Xkgims8P/1rX9HpYUyVBAD/wfzFaDqKH Jq9GnI1bW9hXJMoo2l9CtVt1rSvuTFiTkK4bxuBXyt1A4eoSZ8M4exVZsYLH1+ef +9BoJmXENnI4gDaga0N6wobjocBpvlBHYm+b2h6pP7AJFEKMXgrOra5khUc7wd3N /Izr3Cewb9CQIr040PDOMoZCEV0iQOoSQf4ECOE3qcizq8VUqeCIiBLcH3cwTpxW BD4AMCe/ArgirmhtPwHv2zn1RR6+vsen7oPT7tWLW86y7S4UeWGxJHRK1eTOaXlY givWYxcHX9UvVcvCoBVvrOz2d9B5ZQM+XgTe5DztTh58cZApt7SJe4Z3Icrq4dpb 7BMmXcUwPbWRbc0/LhiCtq7J88pcDthmrNIyoengIwCoBVJu0AxTkm3s+wDh8zTy 4okNEfvl0n5l97X19hp77qeaK+ObnENAqgY2VI/yoNPnM/TbCRGyHyF9l6O3O8i/ C3QDb4U7ECPtjG8mpk1yQARqJ2hReRNslfhrMAK4BL/6cCwYx9MdslfgfwDqt+5o VyB0E5g6+6SK7p3uuLpS92B4bDYT9Wt02YdXrbAFc5R61YUYGdSb+tr73L8a845f Ups/FAblLSZ5TSgrBF8fmY5AJqWQl4suXNZCl8wMzeMBT5jv8adjR5dBEEtDLeSC tHD1ignOphVos7+32ZRV =4doD -END PGP SIGNATURE- -- 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
Can't remove missing drive (kernel BUG)
I have an six-drive array I use for television recordings (4 2TB and 2 1.5TB). Yesterday, I had one of the 1.5TBs die on me, so I did a "mount -o degraded /dev/sdb /mnt/media" followed by a "btrfs-vol -r missing /mnt/media", but the latter command almost immediately generated a kernel BUG message, and then hung. This happened on both 2.6.34 and 2.6.35 kernels. The relevant dmesg output is below. I'm fine with recompiling the kernel, if there is a setting you'd like me to enable to get more information. Also, the array was fairly full (about 76%), so I don't know if that might be contributing. Thank you. device label Media devid 2 transid 160727 /dev/sdb btrfs: allowing degraded mounts warning devid 5 missing btrfs: relocating block group 15629440516096 flags 17 [ cut here ] kernel BUG at fs/btrfs/volumes.c:3037! invalid opcode: [#1] SMP last sysfs file: /sys/devices/pci:00/:00:01.0/:06:00.0/boot_vga CPU 1 Modules linked in: ipv6 xt_tcpudp iptable_filter ipt_addrtype xt_dscp xt_string xt_multiport xt_hashlimit xt_conntrack xt_DSCP xt_NFQUEUE xt_mark xt_connmark nf_conntrack ip_tables x_tables snd_pcm_oss snd_mixer_oss snd_seq_oss snd_seq_midi_event snd_seq snd_seq_device btrfs zlib_deflate crc32c libcrc32c ir_kbd_i2c cx88_dvb cx88_vp3054_i2c s5h1411 xc5000 s5h1409 tuner cx23885 firmware_class cx88_alsa arc4 ecb cx8800 cx8802 cx88xx cx2341x ath9k ath9k_common ftdi_sio ath9k_hw usbserial v4l2_common videodev videobuf_dvb dvb_core r8169 ath usblp i2c_i801 v4l2_compat_ioctl32 pcspkr mii firewire_ohci firewire_core evdev i2c_algo_bit mac80211 tveeprom videobuf_dma_sg cfg80211 videobuf_core rfkill btcx_risc snd_hda_codec_realtek led_class snd_hda_intel i2c_core button snd_hda_codec snd_hwdep snd_pcm snd_timer snd soundcore snd_page_alloc fuse reiserfs scsi_wait_scan uhci_hcd usb_storage ehci_hcd sr_mod cdrom sg sata_sil24 Pid: 9011, comm: flush-btrfs-2 Not tainted 2.6.35-gentoo-r8 #2 Burbank/KT829AV-ABA d4999t-2 RIP: 0010:[] [] 0xa02ce6fc RSP: 0018:88019d4f3930 EFLAGS: 00010246 RAX: 0030 RBX: 88019e4862c0 RCX: 0001 RDX: 8801ae7d99c0 RSI: 8801ab22ea00 RDI: RBP: 8801acde4800 R08: 88019d47b680 R09: 4000 R10: 8801a5b6cab0 R11: 8801ae7d99c0 R12: 88019d47b680 R13: 0002 R14: R15: 0006eda1a000 FS: () GS:88000168() knlGS: CS: 0010 DS: ES: CR0: 8005003b CR2: 7f4d55a0b000 CR3: 0001a3879000 CR4: 06e0 DR0: DR1: DR2: DR3: DR6: 0ff0 DR7: 0400 Process flush-btrfs-2 (pid: 9011, threadinfo 88019d4f2000, task 8801a38d9890) Stack: 00011000 0001 8801ae7d99c0 0001 <0> 88019e4862c0 88019d4f3c60 <0> 0006eda1a080 00010fff a02c7ec4 Call Trace: [] ? 0xa02c7ec4 [] ? 0xa02c8004 [] ? 0xa02c9fcb [] ? 0xa02cbf60 [] ? 0xa02c9fcb [] ? 0xa02cc3dd [] ? 0xa02cc5c8 [] ? 0xa02b4b89 [] ? 0x810b5356 [] ? 0x810b58bc [] ? 0x810b607b [] ? 0x810b621a [] ? 0x810b62d9 [] ? 0x81037a29 [] ? 0x810b6415 [] ? 0x810409f7 [] ? 0x81084f74 [] ? 0x81084fd7 [] ? 0x81084f74 [] ? 0x810406e1 [] ? 0x81002c54 [] ? 0x8104066c [] ? 0x81002c50 Code: c0 03 48 c1 e0 04 48 01 c2 48 8b 52 08 48 c1 ea 09 49 89 14 24 48 8b 54 24 10 83 7c 24 04 01 48 8b 34 10 75 0a 83 7e 64 00 75 04 <0f> 0b eb fe 48 85 f6 74 34 48 8b 46 70 48 85 c0 74 2b 49 89 44 RIP [] 0xa02ce6fc RSP ---[ end trace be039cec4b98333b ]--- btrfs: found 645 extents -- 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
