Re: [PATCH][BTRFS-PROGS][V2] btrfs filesystem df
On Wed, Oct 03, 2012 at 09:38:29PM +0200, Goffredo Baroncelli wrote: > the output of the program ends with the "Metadata Single". What you > called "Help text" is a short description in the email. Ah, I see. I still find it useful, would be good to include it in help text or under a separate option. david -- 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] Btrfs progs: quota groups support
On 29.09.2012 23:48, Diego Calleja wrote: > On Viernes, 10 de agosto de 2012 15:51:07 Jan Schmidt escribió: >> From: Arne Jansen >> >> Signed-off-by: Jan Schmidt >> Signed-off-by: Arne Jansen >> --- >> This is the rebased version of Arne's qgroup patch set. He's the >> original author, which is why I'm sending with his author tag. > > A small suggestion, it would be nice to have a man page update. I thought Goffredo had already compiled a man page, with his patch [PATCH 6/7] qgroup/quota info for man page If it hasn't been merged it might be time to do so. -Arne > -- > 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 -- 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: tree root
On Wed, Oct 03, 2012 at 06:35:00PM +0200, Øystein Sættem Middelthun wrote: > Well block 14102764707840 seems great, but generation doesn't match, > have=109268, want=109269 > > Because the filesystem was last in use with a pre 3.2-kernel I am unable to > use mount -o recovery, but restore seems to work when I specify the previous > tree-root. My problem is however that the btrfs is so large I have nowhere > to temporarily put all the files. I am currently running kernel 3.5. Does > mount have an option to manually tell it to use the tree root at block > 14102764707840? It's not possible to supply the tree_root via mount option, but it should be possible to modify the superblock to point the tree_root to the one you've found, in a similar way that the -o recovery does that, but this hasn't been done before and "minor" details may make it complicated (like getting the transaction number in sync, as the tree_root has latest-1). david -- 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] btrfs ulist use rbtree instead
From: Rock
---
fs/btrfs/backref.c | 10 ++--
fs/btrfs/qgroup.c | 16 +++---
fs/btrfs/send.c|2 +-
fs/btrfs/ulist.c | 154 +---
fs/btrfs/ulist.h | 45 ---
5 files changed, 161 insertions(+), 66 deletions(-)
diff --git a/fs/btrfs/backref.c b/fs/btrfs/backref.c
index ff6475f..a5bebc8 100644
--- a/fs/btrfs/backref.c
+++ b/fs/btrfs/backref.c
@@ -360,7 +360,7 @@ static int __resolve_indirect_refs(struct btrfs_fs_info
*fs_info,
}
/* we put the first parent into the ref at hand */
- ULIST_ITER_INIT(&uiter);
+ ULIST_ITER_INIT(parents, &uiter);
node = ulist_next(parents, &uiter);
ref->parent = node ? node->val : 0;
ref->inode_list =
@@ -955,7 +955,7 @@ static void free_leaf_list(struct ulist *blocks)
struct extent_inode_elem *eie_next;
struct ulist_iterator uiter;
- ULIST_ITER_INIT(&uiter);
+ ULIST_ITER_INIT(blocks, &uiter);
while ((node = ulist_next(blocks, &uiter))) {
if (!node->aux)
continue;
@@ -1038,7 +1038,7 @@ int btrfs_find_all_roots(struct btrfs_trans_handle *trans,
return -ENOMEM;
}
- ULIST_ITER_INIT(&uiter);
+ ULIST_ITER_INIT(tmp, &uiter);
while (1) {
ret = find_parent_nodes(trans, fs_info, bytenr,
time_seq, tmp, *roots, NULL);
@@ -1395,13 +1395,13 @@ int iterate_extent_inodes(struct btrfs_fs_info *fs_info,
if (ret)
goto out;
- ULIST_ITER_INIT(&ref_uiter);
+ ULIST_ITER_INIT(refs, &ref_uiter);
while (!ret && (ref_node = ulist_next(refs, &ref_uiter))) {
ret = btrfs_find_all_roots(trans, fs_info, ref_node->val,
tree_mod_seq_elem.seq, &roots);
if (ret)
break;
- ULIST_ITER_INIT(&root_uiter);
+ ULIST_ITER_INIT(roots, &root_uiter);
while (!ret && (root_node = ulist_next(roots, &root_uiter))) {
pr_debug("root %llu references leaf %llu, data list "
"%#lx\n", root_node->val, ref_node->val,
diff --git a/fs/btrfs/qgroup.c b/fs/btrfs/qgroup.c
index b650155..a0aad87 100644
--- a/fs/btrfs/qgroup.c
+++ b/fs/btrfs/qgroup.c
@@ -1133,7 +1133,7 @@ int btrfs_qgroup_account_ref(struct btrfs_trans_handle
*trans,
seq = fs_info->qgroup_seq;
fs_info->qgroup_seq += roots->nnodes + 1; /* max refcnt */
- ULIST_ITER_INIT(&uiter);
+ ULIST_ITER_INIT(roots, &uiter);
while ((unode = ulist_next(roots, &uiter))) {
struct ulist_node *tmp_unode;
struct ulist_iterator tmp_uiter;
@@ -1146,7 +1146,7 @@ int btrfs_qgroup_account_ref(struct btrfs_trans_handle
*trans,
ulist_reinit(tmp);
/* XXX id not needed */
ulist_add(tmp, qg->qgroupid, (unsigned long)qg, GFP_ATOMIC);
- ULIST_ITER_INIT(&tmp_uiter);
+ ULIST_ITER_INIT(tmp, &tmp_uiter);
while ((tmp_unode = ulist_next(tmp, &tmp_uiter))) {
struct btrfs_qgroup_list *glist;
@@ -1169,7 +1169,7 @@ int btrfs_qgroup_account_ref(struct btrfs_trans_handle
*trans,
*/
ulist_reinit(tmp);
ulist_add(tmp, qgroup->qgroupid, (unsigned long)qgroup, GFP_ATOMIC);
- ULIST_ITER_INIT(&uiter);
+ ULIST_ITER_INIT(tmp, &uiter);
while ((unode = ulist_next(tmp, &uiter))) {
struct btrfs_qgroup *qg;
struct btrfs_qgroup_list *glist;
@@ -1197,7 +1197,7 @@ int btrfs_qgroup_account_ref(struct btrfs_trans_handle
*trans,
/*
* step 3: walk again from old refs
*/
- ULIST_ITER_INIT(&uiter);
+ ULIST_ITER_INIT(roots, &uiter);
while ((unode = ulist_next(roots, &uiter))) {
struct btrfs_qgroup *qg;
struct ulist_node *tmp_unode;
@@ -1209,7 +1209,7 @@ int btrfs_qgroup_account_ref(struct btrfs_trans_handle
*trans,
ulist_reinit(tmp);
ulist_add(tmp, qg->qgroupid, (unsigned long)qg, GFP_ATOMIC);
- ULIST_ITER_INIT(&tmp_uiter);
+ ULIST_ITER_INIT(tmp, &tmp_uiter);
while ((tmp_unode = ulist_next(tmp, &tmp_uiter))) {
struct btrfs_qgroup_list *glist;
@@ -1470,7 +1470,7 @@ int btrfs_qgroup_reserve(struct btrfs_root *root, u64
num_bytes)
*/
ulist = ulist_alloc(GFP_ATOMIC);
ulist_add(ulist, qgroup->qgroupid, (unsigned long)qgroup, GFP_ATOMIC);
- ULIST_ITER_INIT(&uiter);
+ ULIST_ITER_INIT(ulist, &uiter);
while ((unode = ulist_next(ulist, &uiter))) {
struct btrfs_qgroup *qg;
struct btrfs_qgroup_list *g
Re: [PATCH] btrfs ulist use rbtree instead
> @@ -207,16 +266,23 @@ EXPORT_SYMBOL(ulist_add); > * end is reached. No guarantee is made with respect to the order in which > * the elements are returned. They might neither be returned in order of > * addition nor in ascending order. > - * It is allowed to call ulist_add during an enumeration. Newly added items > - * are guaranteed to show up in the running enumeration. > */ > struct ulist_node *ulist_next(struct ulist *ulist, struct ulist_iterator > *uiter) Quick observation: If there's code relying on the behaviour stated in the removed part of the comment, it will break. Have you verified this is not the case? david -- 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] btrfs ulist use rbtree instead
On 04.10.2012 11:26, David Sterba wrote: >> @@ -207,16 +266,23 @@ EXPORT_SYMBOL(ulist_add); >> * end is reached. No guarantee is made with respect to the order in which >> * the elements are returned. They might neither be returned in order of >> * addition nor in ascending order. >> - * It is allowed to call ulist_add during an enumeration. Newly added items >> - * are guaranteed to show up in the running enumeration. >> */ >> struct ulist_node *ulist_next(struct ulist *ulist, struct ulist_iterator >> *uiter) > > Quick observation: > > If there's code relying on the behaviour stated in the removed part of > the comment, it will break. Have you verified this is not the case? It's a good thing to use rb-trees when the small inline cache is exhausted, but of course it should keep the semantics. We heavily rely on the removed part. It should be possible to keep the semantics if the elements are also kept in a linked list. As it inflates the size of struct ulist_node even more, it might make sense to use a smaller struct for the inline cache to keep the footprint low. Also, a commit message might be good that explains the motivation for the change. Have you done any measurements? Thanks for working on this. -Arne > > > david > -- > 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 -- 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] Btrfs-progs: add parent uuid for snapshots
From: Anand Jain
Signed-off-by: Anand Jain
---
btrfs-list.c | 32 +++-
btrfs-list.h |1 +
cmds-subvolume.c |6 +-
3 files changed, 33 insertions(+), 6 deletions(-)
diff --git a/btrfs-list.c b/btrfs-list.c
index b1c9714..9d5a11f 100644
--- a/btrfs-list.c
+++ b/btrfs-list.c
@@ -80,6 +80,7 @@ struct root_info {
time_t otime;
u8 uuid[BTRFS_UUID_SIZE];
+ u8 puuid[BTRFS_UUID_SIZE];
/* path from the subvol we live in to this root, including the
* root's name. This is null until we do the extra lookup ioctl.
@@ -128,6 +129,11 @@ struct {
.need_print = 0,
},
{
+ .name = "puuid",
+ .column_name= "PUUID",
+ .need_print = 0,
+ },
+ {
.name = "uuid",
.column_name= "UUID",
.need_print = 0,
@@ -435,7 +441,7 @@ static struct root_info *root_tree_search(struct
root_lookup *root_tree,
static int update_root(struct root_lookup *root_lookup,
u64 root_id, u64 ref_tree, u64 root_offset, u64 flags,
u64 dir_id, char *name, int name_len, u64 ogen, u64 gen,
- time_t ot, void *uuid)
+ time_t ot, void *uuid, void *puuid)
{
struct root_info *ri;
@@ -472,6 +478,8 @@ static int update_root(struct root_lookup *root_lookup,
ri->otime = ot;
if (uuid)
memcpy(&ri->uuid, uuid, BTRFS_UUID_SIZE);
+ if (puuid)
+ memcpy(&ri->uuid, uuid, BTRFS_UUID_SIZE);
return 0;
}
@@ -489,17 +497,18 @@ static int update_root(struct root_lookup *root_lookup,
* gen: the current generation of the root
* ot: the original time(create time) of the root
* uuid: uuid of the root
+ * puuid: uuid of the root parent if any
*/
static int add_root(struct root_lookup *root_lookup,
u64 root_id, u64 ref_tree, u64 root_offset, u64 flags,
u64 dir_id, char *name, int name_len, u64 ogen, u64 gen,
- time_t ot, void *uuid)
+ time_t ot, void *uuid, void *puuid)
{
struct root_info *ri;
int ret;
ret = update_root(root_lookup, root_id, ref_tree, root_offset, flags,
- dir_id, name, name_len, ogen, gen, ot, uuid);
+ dir_id, name, name_len, ogen, gen, ot, uuid, puuid);
if (!ret)
return 0;
@@ -540,6 +549,9 @@ static int add_root(struct root_lookup *root_lookup,
if (uuid)
memcpy(&ri->uuid, uuid, BTRFS_UUID_SIZE);
+ if (puuid)
+ memcpy(&ri->puuid, puuid, BTRFS_UUID_SIZE);
+
ret = root_tree_insert(root_lookup, ri);
if (ret) {
printf("failed to insert tree %llu\n", (unsigned long
long)root_id);
@@ -1022,6 +1034,7 @@ static int __list_subvol_search(int fd, struct
root_lookup *root_lookup)
int i;
time_t t;
u8 uuid[BTRFS_UUID_SIZE];
+ u8 puuid[BTRFS_UUID_SIZE];
root_lookup_init(root_lookup);
memset(&args, 0, sizeof(args));
@@ -1075,7 +1088,7 @@ static int __list_subvol_search(int fd, struct
root_lookup *root_lookup)
add_root(root_lookup, sh->objectid, sh->offset,
0, 0, dir_id, name, name_len, 0, 0, 0,
-NULL);
+NULL, NULL);
} else if (sh->type == BTRFS_ROOT_ITEM_KEY) {
ri = (struct btrfs_root_item *)(args.buf + off);
gen = btrfs_root_generation(ri);
@@ -1085,15 +1098,17 @@ static int __list_subvol_search(int fd, struct
root_lookup *root_lookup)
t = ri->otime.sec;
ogen = btrfs_root_otransid(ri);
memcpy(uuid, ri->uuid, BTRFS_UUID_SIZE);
+ memcpy(puuid, ri->parent_uuid,
BTRFS_UUID_SIZE);
} else {
t = 0;
ogen = 0;
memset(uuid, 0, BTRFS_UUID_SIZE);
+ memset(puuid, 0, BTRFS_UUID_SIZE);
}
add_root(root_lookup, sh->objectid, 0,
sh->offset, flags, 0, NULL, 0, ogen,
-gen, t, uuid);
+gen, t, uuid, puuid);
}
off += sh->len;
@@ -1361,6 +1376,13 @@ static void print_subvolume_column(struct root_info
*subv,
uuid_unparse(subv->uu
Re: [PATCH] Btrfs-progs: add parent uuid for snapshots
2012/10/4 Anand jain :
> From: Anand Jain
>
> Signed-off-by: Anand Jain
> ---
> btrfs-list.c | 32 +++-
> btrfs-list.h |1 +
> cmds-subvolume.c |6 +-
> 3 files changed, 33 insertions(+), 6 deletions(-)
>
> diff --git a/btrfs-list.c b/btrfs-list.c
> index b1c9714..9d5a11f 100644
> --- a/btrfs-list.c
> +++ b/btrfs-list.c
> @@ -80,6 +80,7 @@ struct root_info {
> time_t otime;
>
> u8 uuid[BTRFS_UUID_SIZE];
> + u8 puuid[BTRFS_UUID_SIZE];
>
> /* path from the subvol we live in to this root, including the
> * root's name. This is null until we do the extra lookup ioctl.
> @@ -128,6 +129,11 @@ struct {
> .need_print = 0,
> },
> {
> + .name = "puuid",
> + .column_name= "PUUID",
> + .need_print = 0,
> + },
> + {
> .name = "uuid",
> .column_name= "UUID",
> .need_print = 0,
> @@ -435,7 +441,7 @@ static struct root_info *root_tree_search(struct
> root_lookup *root_tree,
> static int update_root(struct root_lookup *root_lookup,
>u64 root_id, u64 ref_tree, u64 root_offset, u64 flags,
>u64 dir_id, char *name, int name_len, u64 ogen, u64
> gen,
> - time_t ot, void *uuid)
> + time_t ot, void *uuid, void *puuid)
> {
> struct root_info *ri;
>
> @@ -472,6 +478,8 @@ static int update_root(struct root_lookup *root_lookup,
> ri->otime = ot;
> if (uuid)
> memcpy(&ri->uuid, uuid, BTRFS_UUID_SIZE);
> + if (puuid)
> + memcpy(&ri->uuid, uuid, BTRFS_UUID_SIZE);
I think here is "&ri->puuid"
>
> return 0;
> }
> @@ -489,17 +497,18 @@ static int update_root(struct root_lookup *root_lookup,
> * gen: the current generation of the root
> * ot: the original time(create time) of the root
> * uuid: uuid of the root
> + * puuid: uuid of the root parent if any
> */
> static int add_root(struct root_lookup *root_lookup,
> u64 root_id, u64 ref_tree, u64 root_offset, u64 flags,
> u64 dir_id, char *name, int name_len, u64 ogen, u64 gen,
> - time_t ot, void *uuid)
> + time_t ot, void *uuid, void *puuid)
> {
> struct root_info *ri;
> int ret;
>
> ret = update_root(root_lookup, root_id, ref_tree, root_offset, flags,
> - dir_id, name, name_len, ogen, gen, ot, uuid);
> + dir_id, name, name_len, ogen, gen, ot, uuid, puuid);
> if (!ret)
> return 0;
>
> @@ -540,6 +549,9 @@ static int add_root(struct root_lookup *root_lookup,
> if (uuid)
> memcpy(&ri->uuid, uuid, BTRFS_UUID_SIZE);
>
> + if (puuid)
> + memcpy(&ri->puuid, puuid, BTRFS_UUID_SIZE);
> +
> ret = root_tree_insert(root_lookup, ri);
> if (ret) {
> printf("failed to insert tree %llu\n", (unsigned long
> long)root_id);
> @@ -1022,6 +1034,7 @@ static int __list_subvol_search(int fd, struct
> root_lookup *root_lookup)
> int i;
> time_t t;
> u8 uuid[BTRFS_UUID_SIZE];
> + u8 puuid[BTRFS_UUID_SIZE];
>
> root_lookup_init(root_lookup);
> memset(&args, 0, sizeof(args));
> @@ -1075,7 +1088,7 @@ static int __list_subvol_search(int fd, struct
> root_lookup *root_lookup)
>
> add_root(root_lookup, sh->objectid,
> sh->offset,
> 0, 0, dir_id, name, name_len, 0, 0,
> 0,
> -NULL);
> +NULL, NULL);
> } else if (sh->type == BTRFS_ROOT_ITEM_KEY) {
> ri = (struct btrfs_root_item *)(args.buf +
> off);
> gen = btrfs_root_generation(ri);
> @@ -1085,15 +1098,17 @@ static int __list_subvol_search(int fd, struct
> root_lookup *root_lookup)
> t = ri->otime.sec;
> ogen = btrfs_root_otransid(ri);
> memcpy(uuid, ri->uuid,
> BTRFS_UUID_SIZE);
> + memcpy(puuid, ri->parent_uuid,
> BTRFS_UUID_SIZE);
> } else {
> t = 0;
> ogen = 0;
> memset(uuid, 0, BTRFS_UUID_SIZE);
> + memset(puuid, 0, BTRFS_UUID_SIZE);
> }
>
> add_root(root_lookup, sh->objectid, 0,
> sh->offset, flags, 0, NULL, 0, ogen,
> -
Re: [PATCH 2/2 v3] Btrfs: snapshot-aware defrag
On 10/03/2012 10:02 PM, Chris Mason wrote: > On Tue, Sep 25, 2012 at 07:07:53PM -0600, Liu Bo wrote: >> On 09/26/2012 01:39 AM, Mitch Harder wrote: >>> On Mon, Sep 17, 2012 at 4:58 AM, Liu Bo wrote: This comes from one of btrfs's project ideas, As we defragment files, we break any sharing from other snapshots. The balancing code will preserve the sharing, and defrag needs to grow this as well. Now we're able to fill the blank with this patch, in which we make full use of backref walking stuff. Here is the basic idea, o set the writeback ranges started by defragment with flag EXTENT_DEFRAG o at endio, after we finish updating fs tree, we use backref walking to find all parents of the ranges and re-link them with the new COWed file layout by adding corresponding backrefs. Originally patch by Li Zefan Signed-off-by: Liu Bo >>> >>> I'm hitting the WARN_ON in record_extent_backrefs() indicating a >>> problem with the return value from iterate_inodes_from_logical(). > > Me too. It triggers reliably with mount -o autodefrag, and then crashes > a in the next function ;) > > -chris > Good news, I'm starting hitting the crash (a NULL pointer crash) ;) thanks, liubo -- 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] btrfs ulist use rbtree instead
Detailed explanations for the patch: When the small inline cache is exhausted, created a new rbtree, and the new rbtree uses original spaces the inline nodes placed for saving memory. By using the rbtree can gain a better performance when nnodes gets larger. Sorry for I doest't did much more measurements, but the average lookup time increases slower then the original linear policy when nnodes goes larger. For this is my first patch I submitted, I'm too excited to find something I can hack the kernel, however I didn't consider the whole thing. I will continue to dive into the btrfs implementation, and work harder. :-) - Rock On 2012-10-4, at 下午5:44, Arne Jansen wrote: > On 04.10.2012 11:26, David Sterba wrote: >>> @@ -207,16 +266,23 @@ EXPORT_SYMBOL(ulist_add); >>> * end is reached. No guarantee is made with respect to the order in which >>> * the elements are returned. They might neither be returned in order of >>> * addition nor in ascending order. >>> - * It is allowed to call ulist_add during an enumeration. Newly added items >>> - * are guaranteed to show up in the running enumeration. >>> */ >>> struct ulist_node *ulist_next(struct ulist *ulist, struct ulist_iterator >>> *uiter) >> >> Quick observation: >> >> If there's code relying on the behaviour stated in the removed part of >> the comment, it will break. Have you verified this is not the case? > > It's a good thing to use rb-trees when the small inline cache is exhausted, > but of course it should keep the semantics. We heavily rely on the removed > part. > It should be possible to keep the semantics if the elements are also kept > in a linked list. As it inflates the size of struct ulist_node even more, > it might make sense to use a smaller struct for the inline cache to keep > the footprint low. > > Also, a commit message might be good that explains the motivation for the > change. Have you done any measurements? > > Thanks for working on this. > > -Arne > >> >> >> david >> -- >> 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 > > -- > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ -- 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
Will RAID have issues with disks that spin down?
Hi. I know that several hardware RAID solutions have issues with disks that spin down when idle; the time to spin back up -- usually on the order of five seconds -- causes unhappy timeouts, etc. I was wondering if that would be an issue with RAID a-la btrfs? Thanks, -Ken -- 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: Will RAID have issues with disks that spin down?
On Thu, Oct 04, 2012 at 10:36:43AM -0400, Ken D'Ambrosio wrote: > Hi. I know that several hardware RAID solutions have issues with > disks that spin down when idle; the time to spin back up -- usually > on the order of five seconds -- causes unhappy timeouts, etc. I was > wondering if that would be an issue with RAID a-la btrfs? I have (some of(*)) the disks in my 8-drive RAID-1 btrfs array set to spin down after 10 minutes of no use. I've not had a problem with it so far. So I'd say it's not an issue from my limited testing. Hugo. (*) Damn you, Samsung! -- === Hugo Mills: hugo@... carfax.org.uk | darksatanic.net | lug.org.uk === PGP key: 515C238D from wwwkeys.eu.pgp.net or http://www.carfax.org.uk --- Great oxymorons of the world, no. 3: Military Intelligence --- signature.asc Description: Digital signature
Re: btrfs send/receive review by vfs folks
Hi Jan,
as I promised, here is some code for you to look at.
First I will describe the approach in general.
# Get rid of the pipe. Instead, user-space passes a buffer and kernel
fills the specified user-space buffer with commands.
# When the buffer is full, kernel stops generating commands and
returns a checkpoint to the user-space.
# User-space does whatever it wants with the returned buffer, and then
calls the kernel again, with a buffer and a checkpoint that was
returned by the kernel from previous SEND ioctl().
# Kernel re-arms itself to the specified checkpoint, and fills the
specified buffer with commands, attaches a new checkpoint and so on.
# Eventually kernel signals to the user that there are no more commands.
I realize this is a big change, and a new IOCTL has to be introduced
in order not to break current user-kernel protocol.
The pros as I see them:
# One data-copy is avoided (no pipe). For WRITE commands two
data-copies are avoided (no read_buf needed)
# ERESTARTSYS issue disappears. If needed, ioctl is restarted, but
there is no problem with that, it will simply refill the buffer from
the same checkpoint.
Cons:
# Instead of one ioctl(), many ioctls() are issued to finish the send.
# Big code change
Checkpoint details:
# Checkpoint is supported both on full-send and diff-send.
# Kernel cannot produce a checkpoint between any two commands. This is
because kernel handles a context like sctx->cur_ino,
sctx->new_refs/deleted_refs etc. (Part of the context becomes part of
the checkpoint, but new_refs/deleted_refs are not). To address this:
kernel remembers how many commands it issued since the latest
checkpoint, and after re-arming to it, it can skip the required number
of commands.
# WRITE command can be broken, if the WRITE does not fit in the user
buffer. After re-arming, the required part of the WRITE is properly
skipped.
# non-WRITE commands cannot be broken
# To user-space, a checkpoint is a blob. However, currently user-space
sees it as well, for easier debugging.
# Checkpoint is envisioned to be able to be persisted on-disk by
user-space, sent over network etc, that's why it is "packed" and in
little endian. With proper user-space support in the future, user will
be able to resume broken full-sends or diff-sends.
Testing:
# I am comparing byte-to-byte the stream that the new code produces vs
original send-stream (for now I introduced a new IOCTL for
send-with-checkpoint). WRITE commands are checked byte-byte based on
offset/length. This is because original code and new code break WRITEs
in different places. Still, all WRITE data is compared.
# I have an option to force the kernel to produce only one command
each time (i.e., pretend that user buffer is really small and can
accommodate only one command). In this way I test re-arming to each
possible point in the send-stream. Then do byte-to-byte comparison
with original stream. This mode is, of course, for testing only.
Code:
# Below is code based on Chris's send-recv branch.
# The code below uses the original send ioctl, and is, therefore,
incompatible with the old pipe-based user-space.
# The code below as-is was not run, it is only to demonstrate the
concept and implementation. I performed my testing on a different
branch that supports both IOCTLs, and is based on a different Chris's
branch (but has latest send-recv code).
Thanks for taking time reading up to here (hopefully). I appreciate
any comments on the code.
Alex.
diff --git a/fs/btrfs/ctree.c b/fs/btrfs/ctree.c
old mode 100644
new mode 100755
index fcc8c21..4e1049a
--- a/fs/btrfs/ctree.c
+++ b/fs/btrfs/ctree.c
@@ -5165,6 +5165,135 @@ static int tree_compare_item(struct btrfs_root
*left_root,
#define ADVANCE 1
#define ADVANCE_ONLY_NEXT -1
+static /*const*/ struct btrfs_key s_key_tree_end_reached = {
+ .objectid = (u64)-1,
+ .type = (u8)-1,
+ .offset = (u64)-1
+};
+
+/*
+ * Generate a tree comparison checkpoint, suitable for being sent over network,
+ * written to disk etc.
+ * Returns the same 'cp' pointer that was passed.
+ */
+struct btrfs_compare_trees_checkpoint*
+btrfs_compare_trees_gen_checkpoint(struct btrfs_compare_trees_checkpoint *cp,
+struct btrfs_key
*left_key, int left_end_reached,
+struct btrfs_key
*right_key, int right_end_reached)
+{
+ if (left_end_reached) {
+ cp->left_key__objectid =
cpu_to_le64(s_key_tree_end_reached.objectid);
+ cp->left_key__type = s_key_tree_end_reached.type;
+ cp->left_key__offset =
cpu_to_le64(s_key_tree_end_reached.offset);
+ } else {
+ cp->left_key__objectid = cpu_to_le64(left_key->objectid);
+ cp->left_key__type = left_key->type;
+ cp->left_key__offset = cpu_to_le64(left_key->offset);
+ }
+
+ if (right_end_reached) {
+ cp->right_key__objectid =
cpu_to_le64
[PATCH][BTRFS-PROGS][V3] btrfs filesystem df
Hi Chris, this serie of patches updated the command "btrfs filesystem df". I update this command because it is not so easy to get the information about the disk usage from the command "fi df" and "fi show". This patch was the result of some discussions on the btrfs mailing list. Many thanks to all the contributors. >From the man page (see 2nd patch): [...] The command btrfs filesystem df is used to query the status of the chunks, how many space on the disk(s) are used by the chunks, how many space are available in the chunks, and an estimation of the free space of the filesystem. [...] $ ./btrfs filesystem df --help usage: btrfs filesystem disk-usage [-k] [..] Show space usage information for a mount point(s). -k Set KB (1024 bytes) as unit $ ./btrfs filesystem df / Path: / Summary: Disk_size: 72.57GB Disk_allocated:25.10GB Disk_unallocated: 47.48GB Logical_size: 23.06GB Used: 11.01GB Free_(Estimated): 55.66GB(Max: 59.52GB, Min: 35.78GB) Data_to_disk_ratio: 92 % Details: Chunk_type Mode Size_(disk) Size_(logical) Used DataSingle 21.01GB 21.01GB 10.34GB System DUP 80.00MB 40.00MB 4.00KB System Single4.00MB 4.00MB0.00 MetadataDUP 4.00GB 2.00GB686.93MB MetadataSingle8.00MB 8.00MB0.00 Where: Disk_size -> sum of sizes of teh disks Disk_allocated -> sum of chunk sizes Disk_unallocated-> Disk_size - Disk_allocated Logical_size-> sum of logical area sizes Used-> logical area used Free_(Estimated)-> on the basis of allocated chunk, an estrapolation of the free space Data_to_disk_ratio -> ration between the space occuped by a chunk and the real space available ( due to duplication and/or RAID level) Chunk_type -> kind of chunk Mode-> allocation policy of a chunk Size_(disk) -> area of disk(s) occuped by the chunk (see it as raw space used) Size_(logical) -> logical area size of the chunk Used-> portion of the logical area used by the filesystem You can pull this change from http://cassiopea.homelinux.net/git/btrfs-progs-unstable.git branch disk_free Please pull. BR Goffredo Baroncelli Changelog: V0->V1 Change the name of command from disk-usage to df V1->V2 Uses getopt(); replace "-" with "_"; change the behaviour of the switches '-s' and '-d'. V2->V3 Removed the options '-s' and '-d'; replaced Chunk-size and Logical-size with Size_(disk) and Size_(logical). Update the man page. -- 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/2] Update btrfs filesystem df command
From: Goffredo Baroncelli
The command btrfs filesystem df is used to query the
status of the chunks, how many space on the disk(s) are used by
the chunks, how many space are available in the chunks, and an
estimation of the free space of the filesystem.
---
cmds-filesystem.c | 270 +++--
1 file changed, 221 insertions(+), 49 deletions(-)
diff --git a/cmds-filesystem.c b/cmds-filesystem.c
index b1457de..2e2b4b6 100644
--- a/cmds-filesystem.c
+++ b/cmds-filesystem.c
@@ -22,6 +22,7 @@
#include
#include
#include
+#include
#include "kerncompat.h"
#include "ctree.h"
@@ -39,25 +40,55 @@ static const char * const filesystem_cmd_group_usage[] = {
NULL
};
-static const char * const cmd_df_usage[] = {
- "btrfs filesystem df ",
- "Show space usage information for a mount point",
- NULL
-};
+static u64 disk_size( char *path){
+ struct statfs sfs;
+
+ if( statfs(path, &sfs) < 0 )
+ return 0;
+ else
+ return sfs.f_bsize * sfs.f_blocks;
-static int cmd_df(int argc, char **argv)
+}
+
+static void print_string(char *s, int w)
+{
+ int i;
+
+ printf("%s", s);
+ for( i = strlen(s) ; i < w ; i++ )
+ putchar(' ');
+}
+
+#define DF_SHOW_SUMMARY(1<<1)
+#define DF_SHOW_DETAIL (1<<2)
+#define DF_HUMAN_UNIT (1<<3)
+
+static void pretty_sizes_r(u64 size, int w, int mode)
+{
+ if( mode & DF_HUMAN_UNIT ){
+ char *s = pretty_sizes(size);
+ printf("%*s", w, s);
+ free(s);
+ } else {
+ printf("%*llu", w, size/1024);
+
+ }
+}
+
+static int _cmd_disk_free(char *path, int mode)
{
struct btrfs_ioctl_space_args *sargs;
u64 count = 0, i;
int ret;
int fd;
- int e;
- char *path;
-
- if (check_argc_exact(argc, 2))
- usage(cmd_df_usage);
-
- path = argv[1];
+ int e, width;
+ u64 total_disk;/* filesystem size == sum of
+ disks sizes */
+ u64 total_chunks; /* sum of chunks sizes on disk(s) */
+ u64 total_used;/* logical space used */
+ u64 total_free;/* logical space un-used */
+ double K;
+
fd = open_file_or_dir(path);
if (fd < 0) {
@@ -103,56 +134,197 @@ static int cmd_df(int argc, char **argv)
return ret;
}
- for (i = 0; i < sargs->total_spaces; i++) {
- char description[80];
- char *total_bytes;
- char *used_bytes;
- int written = 0;
- u64 flags = sargs->spaces[i].flags;
+ total_disk = disk_size(path);
+ e = errno;
+ if( total_disk == 0 ){
+ fprintf(stderr, "ERROR: couldn't get space info on '%s' - %s\n",
+ path, strerror(e));
+ close(fd);
+ free(sargs);
+ return 19;
+ }
+
+ total_chunks = total_used = total_free = 0;
- memset(description, 0, 80);
+ for (i = 0; i < sargs->total_spaces; i++) {
+ int ratio=1;
+ u64 allocated;
- if (flags & BTRFS_BLOCK_GROUP_DATA) {
- if (flags & BTRFS_BLOCK_GROUP_METADATA) {
- snprintf(description, 14, "%s",
-"Data+Metadata");
- written += 13;
- } else {
- snprintf(description, 5, "%s", "Data");
- written += 4;
- }
- } else if (flags & BTRFS_BLOCK_GROUP_SYSTEM) {
- snprintf(description, 7, "%s", "System");
- written += 6;
- } else if (flags & BTRFS_BLOCK_GROUP_METADATA) {
- snprintf(description, 9, "%s", "Metadata");
- written += 8;
- }
+ u64 flags = sargs->spaces[i].flags;
if (flags & BTRFS_BLOCK_GROUP_RAID0) {
- snprintf(description+written, 8, "%s", ", RAID0");
- written += 7;
+ ratio=1;
} else if (flags & BTRFS_BLOCK_GROUP_RAID1) {
- snprintf(description+written, 8, "%s", ", RAID1");
- written += 7;
+ ratio=2;
} else if (flags & BTRFS_BLOCK_GROUP_DUP) {
- snprintf(description+written, 6, "%s", ", DUP");
- written += 5;
+ ratio=2;
} else if (flags & BTRFS_BLOCK_GROUP_RAID10) {
- snprintf(description+written, 9, "%s", ", RAID10");
- written += 8;
[PATCH 2/2] Update help page
From: Goffredo Baroncelli --- man/btrfs.8.in | 100 1 file changed, 100 insertions(+) diff --git a/man/btrfs.8.in b/man/btrfs.8.in index 4b0a9f9..96c9239 100644 --- a/man/btrfs.8.in +++ b/man/btrfs.8.in @@ -27,6 +27,8 @@ btrfs \- control a btrfs filesystem .PP \fBbtrfs\fP \fBfilesystem label\fP\fI [newlabel]\fP .PP +\fBbtrfs\fP \fBfilesystem df\fP\fI [-k] \fIpath [path..]\fR\fP +.PP \fBbtrfs\fP \fBsubvolume find-new\fP\fI \fP .PP \fBbtrfs\fP \fBfilesystem balance\fP\fI \fP @@ -214,6 +216,104 @@ NOTE: Currently there are the following limitations: - the filesystem should not have more than one device. .TP +\fBfilesystem df\fP [-k] \fIpath [path..]\fR + +Show space usage information for a mount point. + +\fIOptions\fP + +\fB-k\fP Set KB (1024 bytes) as unit + +\fIUsage information\fP + +.\" +.\" this section is extract from +.\"http://en.wikipedia.org/wiki/Btrfs#Chunk_and_device_trees +The disk(s) of a btrfs filesystem are divided into chunks of 256 MB or more. +Chunks may be mirrored or striped across multiple devices, depending by +the allocation policy. +The mirroring/striping arrangement is transparent to the rest of the +file system, which simply sees the single, logical address space that +chunks are mapped into. +Chunks are allocated on demand. In the default allocation policy +the data chunks are not duplicated and the metadata chunks +are duplicated. This default can be changed during the filesystem +creation, and in general the chunks allocation policy may change +during the filesystem life. + +Depending by the allocation policy a chunk may require a space on +the disk greater than the logical space that it provides. E.g. +a chunk DUPlicated or with a RAID1/RAID10 level +requires a space on the disk +two times greater than the logical space provided. +Different RAID levels +have a different ratio disk-usage / logical space offered. + +Normally the file contents are stored in the Data chunks; however +small files (which fit into a btree leaf) are stored in the +metadata chunks. So the computation of the \fIfree space\fP +and \fIused space\fP +is complex: depending by the file size different +allocation policies are used. + +The command \fBbtrfs filesystem df\fP is used to query the status +of the chunks, how many space on the disk(s) are used by the chunks, +how many space are available in the chunks, and an estimation of the free +space of the filesystem. +The output of the command \fBbtrfs filesystem df\fP shows: + +.RS +.IP \fBDisk\ size\fP +the total size of the disks which compose the filesystem. + +.IP \fBDisk\ allocated\fP\ or\ \fBSize_(disk)\fP +the size of the area of the disks used by the chunks. + +.IP \fBDisk\ unallocated\fP +the size of the area of the disks which is free (i.e. +the differences of the values above). + +.IP \fBLogical\ size\fP\ or\ \fBSize_(logical)\fP +the available logical space of chunk. + +.IP \fBUsed\fP +the portion of the logical space used by the file and metadata. + +.IP \fBFree\ (estimated)\fP +the estimated free space available. The evaluation +cannot be rigorous because it depends by the allocation policy (DUP,Single, +RAID1...) of the metadata and data chunks. If every chunks is stored as +"Single" the sum of the \fBfree (estimated)\fP space and the \fBused\fP +space is equal to the \fBdisk size\fP. +Otherwise if all the chunk are mirrored (raid1 or raid10) or duplicated +the sum of the \fBfree (estimated)\fP space and the \fBused\fP space is +half of the \fBdisk size\fP. Normally the \fBfree (estimated)\fP is between +these two limits. + +.IP \fBData\ to\ disk\ ratio\fP +the ratio betwen the \fBlogical size\fP and the \fBdisk allocated\fP. + +.IP \fBMode\fP +the kind of allocation policy used by the chunk (e.g. DUPlicated, +RAID1, RAID10, Single) + +.IP \fBChunk\ type\fP +the kind of chunk (Data, Metdata, System...) + +.RE +.RS +\fINOTE\fP + +When a chunk is allocated, its disk-area is used and its allocation +policy is fixed. +A rebalance operation could rearrange the chunks, moving data in the chunks +and resizing the allocated chunks. This causes the change of all the values +discussed above, with the exception of the \fBused\fP and +\fBdisk size\fP values. + +.RE +.TP + \fBfilesystem show\fR [--all-devices||]\fR Show the btrfs filesystem with some additional info. If no \fIUUID\fP or \fIlabel\fP is passed, \fBbtrfs\fR show info of all the btrfs filesystem. -- 1.7.10.4 -- 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 2/2 v3] Btrfs: snapshot-aware defrag
On Thu, Oct 4, 2012 at 9:22 AM, Liu Bo wrote: > On 10/03/2012 10:02 PM, Chris Mason wrote: >> On Tue, Sep 25, 2012 at 07:07:53PM -0600, Liu Bo wrote: >>> On 09/26/2012 01:39 AM, Mitch Harder wrote: On Mon, Sep 17, 2012 at 4:58 AM, Liu Bo wrote: > This comes from one of btrfs's project ideas, > As we defragment files, we break any sharing from other snapshots. > The balancing code will preserve the sharing, and defrag needs to grow > this > as well. > > Now we're able to fill the blank with this patch, in which we make full > use of > backref walking stuff. > > Here is the basic idea, > o set the writeback ranges started by defragment with flag EXTENT_DEFRAG > o at endio, after we finish updating fs tree, we use backref walking to > find >all parents of the ranges and re-link them with the new COWed file > layout by >adding corresponding backrefs. > > Originally patch by Li Zefan > Signed-off-by: Liu Bo I'm hitting the WARN_ON in record_extent_backrefs() indicating a problem with the return value from iterate_inodes_from_logical(). >> >> Me too. It triggers reliably with mount -o autodefrag, and then crashes >> a in the next function ;) >> >> -chris >> > > Good news, I'm starting hitting the crash (a NULL pointer crash) ;) > > thanks, > liubo I'm also starting to hit this crash while balancing a test partition. I guess this isn't surprising since both autodefrag and balancing make use of relocation. -- 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] Btrfs-progs: Update btrfs man page for -P option
From: Anand Jain Signed-off-by: Anand Jain --- man/btrfs.8.in |2 ++ 1 files changed, 2 insertions(+), 0 deletions(-) diff --git a/man/btrfs.8.in b/man/btrfs.8.in index 29f93cf..71af35c 100644 --- a/man/btrfs.8.in +++ b/man/btrfs.8.in @@ -132,6 +132,8 @@ and top level. The parent's ID may be used at mount time via the \fB-u\fP print the uuid of subvolumes (and snapshots). +\fB-P\fP print parent uuid of snapshots. + \fB-p\fP print parent ID. \fB-g [+|-]value\fP -- 1.7.1 -- 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] Btrfs-progs: Corrections and additions to the btrfs man page
From: Anand Jain Signed-off-by: Anand Jain --- man/btrfs.8.in | 10 -- 1 files changed, 8 insertions(+), 2 deletions(-) diff --git a/man/btrfs.8.in b/man/btrfs.8.in index 6d6c70a..71af35c 100644 --- a/man/btrfs.8.in +++ b/man/btrfs.8.in @@ -126,9 +126,15 @@ and top level. The parent's ID may be used at mount time via the \fB-a\fP print all the subvolumes in the filesystem. -\fB-r\fP only readonly subvolumes in the filesystem wille be listed. +\fB-r\fP only readonly subvolumes in the filesystem will be listed. -\fB-s\fP only snapshot subvolumes in the filesystem will be listed. +\fB-s\fP only snapshot subvolumes in the filesystem will be listed. + +\fB-u\fP print the uuid of subvolumes (and snapshots). + +\fB-P\fP print parent uuid of snapshots. + +\fB-p\fP print parent ID. \fB-g [+|-]value\fP list subvolumes in the filesystem that its generation is -- 1.7.1 -- 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 V2] Btrfs-progs: add parent uuid for snapshots
From: Anand Jain
Reviewed-by: Dong Robin
Signed-off-by: Anand Jain
---
btrfs-list.c | 32 +++-
btrfs-list.h |1 +
cmds-subvolume.c |6 +-
3 files changed, 33 insertions(+), 6 deletions(-)
diff --git a/btrfs-list.c b/btrfs-list.c
index b1c9714..2b7d79e 100644
--- a/btrfs-list.c
+++ b/btrfs-list.c
@@ -80,6 +80,7 @@ struct root_info {
time_t otime;
u8 uuid[BTRFS_UUID_SIZE];
+ u8 puuid[BTRFS_UUID_SIZE];
/* path from the subvol we live in to this root, including the
* root's name. This is null until we do the extra lookup ioctl.
@@ -128,6 +129,11 @@ struct {
.need_print = 0,
},
{
+ .name = "puuid",
+ .column_name= "PUUID",
+ .need_print = 0,
+ },
+ {
.name = "uuid",
.column_name= "UUID",
.need_print = 0,
@@ -435,7 +441,7 @@ static struct root_info *root_tree_search(struct
root_lookup *root_tree,
static int update_root(struct root_lookup *root_lookup,
u64 root_id, u64 ref_tree, u64 root_offset, u64 flags,
u64 dir_id, char *name, int name_len, u64 ogen, u64 gen,
- time_t ot, void *uuid)
+ time_t ot, void *uuid, void *puuid)
{
struct root_info *ri;
@@ -472,6 +478,8 @@ static int update_root(struct root_lookup *root_lookup,
ri->otime = ot;
if (uuid)
memcpy(&ri->uuid, uuid, BTRFS_UUID_SIZE);
+ if (puuid)
+ memcpy(&ri->puuid, puuid, BTRFS_UUID_SIZE);
return 0;
}
@@ -489,17 +497,18 @@ static int update_root(struct root_lookup *root_lookup,
* gen: the current generation of the root
* ot: the original time(create time) of the root
* uuid: uuid of the root
+ * puuid: uuid of the root parent if any
*/
static int add_root(struct root_lookup *root_lookup,
u64 root_id, u64 ref_tree, u64 root_offset, u64 flags,
u64 dir_id, char *name, int name_len, u64 ogen, u64 gen,
- time_t ot, void *uuid)
+ time_t ot, void *uuid, void *puuid)
{
struct root_info *ri;
int ret;
ret = update_root(root_lookup, root_id, ref_tree, root_offset, flags,
- dir_id, name, name_len, ogen, gen, ot, uuid);
+ dir_id, name, name_len, ogen, gen, ot, uuid, puuid);
if (!ret)
return 0;
@@ -540,6 +549,9 @@ static int add_root(struct root_lookup *root_lookup,
if (uuid)
memcpy(&ri->uuid, uuid, BTRFS_UUID_SIZE);
+ if (puuid)
+ memcpy(&ri->puuid, puuid, BTRFS_UUID_SIZE);
+
ret = root_tree_insert(root_lookup, ri);
if (ret) {
printf("failed to insert tree %llu\n", (unsigned long
long)root_id);
@@ -1022,6 +1034,7 @@ static int __list_subvol_search(int fd, struct
root_lookup *root_lookup)
int i;
time_t t;
u8 uuid[BTRFS_UUID_SIZE];
+ u8 puuid[BTRFS_UUID_SIZE];
root_lookup_init(root_lookup);
memset(&args, 0, sizeof(args));
@@ -1075,7 +1088,7 @@ static int __list_subvol_search(int fd, struct
root_lookup *root_lookup)
add_root(root_lookup, sh->objectid, sh->offset,
0, 0, dir_id, name, name_len, 0, 0, 0,
-NULL);
+NULL, NULL);
} else if (sh->type == BTRFS_ROOT_ITEM_KEY) {
ri = (struct btrfs_root_item *)(args.buf + off);
gen = btrfs_root_generation(ri);
@@ -1085,15 +1098,17 @@ static int __list_subvol_search(int fd, struct
root_lookup *root_lookup)
t = ri->otime.sec;
ogen = btrfs_root_otransid(ri);
memcpy(uuid, ri->uuid, BTRFS_UUID_SIZE);
+ memcpy(puuid, ri->parent_uuid,
BTRFS_UUID_SIZE);
} else {
t = 0;
ogen = 0;
memset(uuid, 0, BTRFS_UUID_SIZE);
+ memset(puuid, 0, BTRFS_UUID_SIZE);
}
add_root(root_lookup, sh->objectid, 0,
sh->offset, flags, 0, NULL, 0, ogen,
-gen, t, uuid);
+gen, t, uuid, puuid);
}
off += sh->len;
@@ -1361,6 +1376,13 @@ static void print_subvolume_column(struct root_info
*subv,
Re: [PATCH] Btrfs-progs: add parent uuid for snapshots
Dong, + if (puuid) + memcpy(&ri->uuid, uuid, BTRFS_UUID_SIZE); I think here is "&ri->puuid" Sorry my mistake. Thanks for the review. -Anand -- 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: btrfs causing reboots and kernel oops on SL 6 (RHEL 6)
On Sat, Jun 4, 2011 at 11:33 AM, Joel Pearson wrote: > Hi, > > I'm using SL 6 (RHEL 6) and I've been playing around with running > PostgreSQL on btrfs. Snapshotting works ok, but the computer keeps > rebooting without warning (can be 5 mins or 1.5 hours), finally I > actually managed to get a Kernel Crash instead of just a reboot. > > I took a picture of the screen: > http://imageshack.us/photo/my-images/716/img0143y.jpg/ > > The important bits are: > > IP: [] btrfs_print_leaf +0x31/0x820 [btrfs] > PGD 0 > Oops: [#1] SMP > last sysfs file: /sys/devices/virtual/block/dm-3/dm/name > > The crashes aren't predictable either. Like it doesn't always happen > when I do a snapshot or anything like that. > > Is this a known problem, that is fixed in a later kernel or something like > that? Which kernel is this? If it's the default SL/RHEL 2.6.32 kernel, then you should try upgrade first. http://elrepo.org/tiki/kernel-ml is a good choice. It's highly unlikely that anyone would be willing to look at bugs on that "archaic" (in btrfs world) kernel. -- Fajar -- 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: btrfs causing reboots and kernel oops on SL 6 (RHEL 6)
On 5 October 2012 13:29, Fajar A. Nugraha wrote: > > On Sat, Jun 4, 2011 at 11:33 AM, Joel Pearson > wrote: > > Hi, > > > > I'm using SL 6 (RHEL 6) and I've been playing around with running > > PostgreSQL on btrfs. Snapshotting works ok, but the computer keeps > > rebooting without warning (can be 5 mins or 1.5 hours), finally I > > actually managed to get a Kernel Crash instead of just a reboot. > > > > I took a picture of the screen: > > http://imageshack.us/photo/my-images/716/img0143y.jpg/ > > > > The important bits are: > > > > IP: [] btrfs_print_leaf +0x31/0x820 [btrfs] > > PGD 0 > > Oops: [#1] SMP > > last sysfs file: /sys/devices/virtual/block/dm-3/dm/name > > > > The crashes aren't predictable either. Like it doesn't always happen > > when I do a snapshot or anything like that. > > > > Is this a known problem, that is fixed in a later kernel or something like > > that? > > > Which kernel is this? > > If it's the default SL/RHEL 2.6.32 kernel, then you should try upgrade > first. http://elrepo.org/tiki/kernel-ml is a good choice. Yes it was the stock kernel, I didn't know you could get recent kernels on RHEL 6, that's good to know. > > It's highly unlikely that anyone would be willing to look at bugs on > that "archaic" (in btrfs world) kernel. Yep fair enough. We moved to ZFS in the end, which was able to do the same things we needed btrfs to do. > > -- > Fajar Cheers, -Joel -- 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
