[PATCH] add -u to show subvol uuid
From: Anand Jain
Applications would need to know the uuid to manage the configurations
associated with the subvol and snapshots
Signed-off-by: Anand Jain
---
btrfs-list.c | 148 ++
cmds-subvolume.c | 14 +++--
2 files changed, 124 insertions(+), 38 deletions(-)
diff --git a/btrfs-list.c b/btrfs-list.c
index 6e83b31..d6b22a1 100644
--- a/btrfs-list.c
+++ b/btrfs-list.c
@@ -34,6 +34,7 @@
#include "ctree.h"
#include "transaction.h"
#include "utils.h"
+#include
/* we store all the roots we find in an rbtree so that we can
* search for them later.
@@ -63,6 +64,8 @@ struct root_info {
/* creation time of this root in sec*/
time_t otime;
+ u8 uuid[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.
*/
@@ -188,7 +191,7 @@ static struct root_info *tree_search(struct rb_root *root,
u64 root_id)
*/
static int add_root(struct root_lookup *root_lookup,
u64 root_id, u64 ref_tree, u64 dir_id, char *name,
- int name_len, u64 *gen, time_t ot)
+ int name_len, u64 *gen, time_t ot, void *uuid)
{
struct root_info *ri;
struct rb_node *ret;
@@ -210,6 +213,11 @@ static int add_root(struct root_lookup *root_lookup,
ri->gen = *gen;
ri->otime = ot;
+ if (uuid)
+ memcpy(&ri->uuid, uuid, BTRFS_UUID_SIZE);
+ else
+ memset(&ri->uuid, 0, BTRFS_UUID_SIZE);
+
ret = tree_insert(&root_lookup->root, root_id, ref_tree, gen,
&ri->rb_node);
if (ret) {
@@ -220,7 +228,7 @@ static int add_root(struct root_lookup *root_lookup,
}
static int update_root(struct root_lookup *root_lookup, u64 root_id, u64 gen,
- time_t ot)
+ time_t ot, void *uuid)
{
struct root_info *ri;
@@ -231,6 +239,11 @@ static int update_root(struct root_lookup *root_lookup,
u64 root_id, u64 gen,
}
ri->gen = gen;
ri->otime = ot;
+ if (uuid)
+ memcpy(&ri->uuid, uuid, BTRFS_UUID_SIZE);
+ else
+ memset(&ri->uuid, 0, BTRFS_UUID_SIZE);
+
return 0;
}
@@ -665,6 +678,7 @@ static int __list_subvol_search(int fd, struct root_lookup
*root_lookup)
int i;
int get_gen = 0;
time_t t;
+ u8 uuid[BTRFS_UUID_SIZE];
root_lookup_init(root_lookup);
memset(&args, 0, sizeof(args));
@@ -718,16 +732,20 @@ again:
dir_id = btrfs_stack_root_ref_dirid(ref);
add_root(root_lookup, sh->objectid, sh->offset,
-dir_id, name, name_len, NULL, 0);
+dir_id, name, name_len, NULL, 0, NULL);
} else if (get_gen && sh->type == BTRFS_ROOT_ITEM_KEY) {
ri = (struct btrfs_root_item *)(args.buf + off);
gen = btrfs_root_generation(ri);
- if(ri->generation == ri->generation_v2)
+ if(ri->generation == ri->generation_v2) {
t = ri->otime.sec;
- else
+ memcpy(uuid, ri->uuid, BTRFS_UUID_SIZE);
+ } else {
t = 0;
+ memset(uuid, 0, BTRFS_UUID_SIZE);
+ }
- update_root(root_lookup, sh->objectid, gen, t);
+ update_root(root_lookup, sh->objectid, gen, t,
+ uuid);
}
off += sh->len;
@@ -818,19 +836,24 @@ static int __list_snapshot_search(int fd, struct
root_lookup *root_lookup)
for (i = 0; i < sk->nr_items; i++) {
struct btrfs_root_item *item;
time_t t;
+ u8 uuid[BTRFS_UUID_SIZE];
+
sh = (struct btrfs_ioctl_search_header *)(args.buf +
off);
off += sizeof(*sh);
if (sh->type == BTRFS_ROOT_ITEM_KEY && sh->offset) {
item = (struct btrfs_root_item *)(args.buf +
off);
- if(item->generation == item->generation_v2)
+ if(item->generation == item->generation_v2) {
t = item->otime.sec;
- else
+ memcpy(uuid, item->uuid,
BTRFS_UUID_SIZE);
+ } else {
[PATCH] get uuid of subvol and snapshot
From: Anand Jain This patch is on top the patch-set titled 'Include otime in the snapshot list' sent by me before. To show the uuid of the subvol and snapshots. btrfs su list -u /btrfs1 ID 256 gen 6 top level 5 uuid 4b7188e4-7d48-f247-b956-1a260b721e1d path sv1 ID 259 gen 6 top level 5 uuid 3cf8931a-de31-5545-8ede-435d25fe3c3f path sv1/.snapshot/ss1 Anand Jain (1): add -u to show subvol uuid btrfs-list.c | 148 ++ cmds-subvolume.c | 14 +++-- 2 files changed, 124 insertions(+), 38 deletions(-) -- 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 RFC] Btrfs: fix deadlock between sys_sync and freeze
From: Liu Bo
I found this while testing xfstests 068, the story is
t1t2
sys_syncthaw_super
iterate_supers
down_read(sb->s_umount) down_write(sb->s_umount)
--->wait for t1
sync_fs (with wait mode)
start_transaction
sb_start_intwrite > wait for t2 to set
s_writers.frozen to SB_UNFROZEN
In this patch, I add an helper sb_start_intwrite_trylock() and use it before we
start_transaction in sync_fs() with wait mode so that we won't hit the deadlock.
Signed-off-by: Liu Bo
---
fs/btrfs/super.c | 15 +++
include/linux/fs.h |5 +
2 files changed, 20 insertions(+), 0 deletions(-)
diff --git a/fs/btrfs/super.c b/fs/btrfs/super.c
index f2eb24c..1e04b41 100644
--- a/fs/btrfs/super.c
+++ b/fs/btrfs/super.c
@@ -847,6 +847,21 @@ int btrfs_sync_fs(struct super_block *sb, int wait)
return 0;
}
+ /*
+* sys_sync can cause an ABBA deadlock with freeze/thaw
+* o freeze_super() grabs s_umount lock and set sb to SB_FREEZE_FS.
+* o thaw_super() grabs s_umount lock and set sb to SB_UNFROZEN.
+* o iterate_supers() grabs s_umount lock, and sync fs, during which
+*we need to do sb_start_intwrite() in starting a
+*new transaction.
+* so iterate_supers() will wait for thaw_super() to reset sb's frozen
+* state, while thaw_super() will wait for iterate_supers() to drop the
+* s_umount lock. This is an ABBA deadlock.
+*/
+ if (!sb_start_intwrite_trylock(sb))
+ return 0;
+ sb_end_intwrite(sb);
+
btrfs_wait_ordered_extents(root, 0, 0);
trans = btrfs_start_transaction(root, 0);
diff --git a/include/linux/fs.h b/include/linux/fs.h
index aa11047..8a3efd0 100644
--- a/include/linux/fs.h
+++ b/include/linux/fs.h
@@ -1700,6 +1700,11 @@ static inline void sb_start_intwrite(struct super_block
*sb)
__sb_start_write(sb, SB_FREEZE_FS, true);
}
+static inline int sb_start_intwrite_trylock(struct super_block *sb)
+{
+ return __sb_start_write(sb, SB_FREEZE_FS, false);
+}
+
extern bool inode_owner_or_capable(const struct inode *inode);
--
1.7.7.6
--
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: remove redundant value set to path->reada in ctree.c/btrfs_alloc_path
btrfs_init_path has init the path to 0s.
No need to set ->reada 0 after path init.
Signed-off-by: Wang Sheng-Hui
---
ctree.c |5 ++---
1 files changed, 2 insertions(+), 3 deletions(-)
diff --git a/ctree.c b/ctree.c
index 2d86b1e..a04e0da 100644
--- a/ctree.c
+++ b/ctree.c
@@ -43,10 +43,9 @@ struct btrfs_path *btrfs_alloc_path(void)
{
struct btrfs_path *path;
path = kmalloc(sizeof(struct btrfs_path), GFP_NOFS);
- if (path) {
+ if (path)
btrfs_init_path(path);
- path->reada = 0;
- }
+
return path;
}
-- 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: remove redundant value set to path->reada in ctree.c/btrfs_alloc_path
btrfs_init_path has init the path to 0s.
No need to set ->reada 0 after path init.
Signed-off-by: Wang Sheng-Hui
---
ctree.c |5 ++---
1 files changed, 2 insertions(+), 3 deletions(-)
diff --git a/ctree.c b/ctree.c
index 2d86b1e..a04e0da 100644
--- a/ctree.c
+++ b/ctree.c
@@ -43,10 +43,9 @@ struct btrfs_path *btrfs_alloc_path(void)
{
struct btrfs_path *path;
path = kmalloc(sizeof(struct btrfs_path), GFP_NOFS);
- if (path) {
+ if (path)
btrfs_init_path(path);
- path->reada = 0;
- }
+
return path;
}
--
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
Re: [GIT PULL] Update LZO compression
On Tue, Aug 14, 2012 at 01:44:02AM +0200, Markus F.X.J. Oberhumer wrote: > Hi all, > > as suggested on the mailing list I have converted the updated LZO > code into git, so please pull my "lzo-update" branch from > > git://github.com/markus-oberhumer/linux.git lzo-update > > You can browse the branch at > > https://github.com/markus-oberhumer/linux/compare/lzo-update Looks ok to me from a quick look. Since kernel lzo is security relevant, I assume the new version has been fuzz tested? I couldn't tell from the github view, but I assume you follow standard coding style. -Andi -- 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
[GIT PULL] Update LZO compression
Hi all, as suggested on the mailing list I have converted the updated LZO code into git, so please pull my "lzo-update" branch from git://github.com/markus-oberhumer/linux.git lzo-update You can browse the branch at https://github.com/markus-oberhumer/linux/compare/lzo-update I'd ask some official kernel maintainer for review and to push this into linux-next so that it will hopefully land in the 3.7 release. Share and enjoy, Markus Signed-off-by: Markus F.X.J. Oberhumer On 2012-07-16 20:30, Markus F.X.J. Oberhumer wrote: > Hi all, > > I finally have prepared a small package that updates the LZO version > in the Linux kernel. Please get it from: > > http://www.oberhumer.com/opensource/lzo/download/Testing/linux-kernel-lzo-20120716.tar.gz > > As stated in the README this version is significantly faster (typically more > than 2 times faster!) than the current version, has been thoroughly tested on > x86_64/i386/powerpc platforms and is intended to get included into the > official Linux 3.6 or 3.7 release. > > I encourage all compression users to test and benchmark this new version, > and I also would ask some official LZO maintainer to convert the updated > source files into a GIT commit and possibly push it to Linus or linux-next. > > Share and enjoy, > Markus > > Signed-off-by: Markus F.X.J. Oberhumer" -- Markus Oberhumer, , http://www.oberhumer.com/ -- 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: update last trans if we don't update the inode
There is a completely impossible situation to hit where you can preallocate
a file, fsync it, write into the preallocated region, have the transaction
commit twice and then fsync and then immediately lose power and lose all of
the contents of the write. This patch fixes this just so I feel better
about the situation and because it is lightweight, we just update the
last_trans when we finish an ordered IO and we don't update the inode
itself. This way we are completely safe and I feel better. Thanks,
Signed-off-by: Josef Bacik
---
fs/btrfs/inode.c |2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/fs/btrfs/inode.c b/fs/btrfs/inode.c
index d331d96..a391cba 100644
--- a/fs/btrfs/inode.c
+++ b/fs/btrfs/inode.c
@@ -1947,6 +1947,8 @@ static int btrfs_finish_ordered_io(struct
btrfs_ordered_extent *ordered_extent)
btrfs_abort_transaction(trans, root, ret);
goto out_unlock;
}
+ } else {
+ btrfs_set_inode_last_trans(trans, inode);
}
ret = 0;
out_unlock:
--
1.7.7.6
--
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
Defragmenting directories, compression
Hello, I've run "btrfs fi defrag /nix", a directory with only three subdirectories. One of them, "/nix/store" has lots of contents. I expected the operation to last very short, because I thought it was not recursive. But for what I see in btrfs_root_defrag, it looks like it's recursive. And it takes long. Additionally, defragmenting on a directory ignores the '-clzo' kind of compression settings. And I wonder... as it works recursively, will it *uncompress* all that big amount of data I have there in lots of files? All that data has been filled with a "compress=lzo" mount option from long ago. Additionally, 'btrfs fi defrag ' seems to require root permisions, while 'btrfs fi defrag ' does not, only file ownership (or writing permision). Is this on purpose? Regards, Lluís. -- 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: [josef-btrfs:extent-history 20/20] fs/btrfs/delayed-ref.h:125:21: error: field 'trace' has incomplete type
On Fri, Aug 10, 2012 at 02:20:47AM -0600, Fengguang Wu wrote: > Hi Josef, > > FYI, kernel build failed on > > tree: git://git.kernel.org/pub/scm/linux/kernel/git/josef/btrfs-next.git > extent-history > head: 7759db1867be3d642b2411455902ed22dd6d1381 > commit: 7759db1867be3d642b2411455902ed22dd6d1381 [20/20] Btrfs: extent > history debugging patch > config: i386-randconfig-k662 (attached as .config) > This is just a debug patch that's just up so other people can use it in the future. But looks like we just need a CONFIG_STACKTRACE check so I've added that and hopefully that fixed it. Thanks, Josef -- 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: make filesystem read-only when submitting barrier fails
On Sat, 11 Aug 2012 10:36:17 +0800, Liu Bo wrote:
> On 08/10/2012 09:38 PM, Stefan Behrens wrote:
[...]
>> +flags = space.flags;
>> +/*
>> + * return
>> + * 0: if dup, single or RAID0 is configured for
>> + *any of metadata, system or data, else
>> + * 1: if RAID5 is configured, or if RAID1 or
>> + *RAID10 is configured and only two mirrors
>> + *are used, else
>> + * 2: if RAID6 is configured, else
>> + * num_mirrors - 1: if RAID1 or RAID10 is
>> + * configured and more than
>> + * 2 mirrors are used.
>> + */
>> +if (num_tolerated_disk_barrier_failures > 0 &&
>> +((flags & (BTRFS_BLOCK_GROUP_DUP |
>> + BTRFS_BLOCK_GROUP_RAID0)) ||
>> + ((flags & BTRFS_BLOCK_GROUP_PROFILE_MASK)
>> + == 0)))
>
> Good work.
>
> We already have __get_block_group_index(), for dup, single, raid0 we can do
> the same thing like
> this:
> __get_block_group_index(flags) > 1
>
> the only problem is to make the function public :)
Thanks for your comments Liu Bo. And good luck with Oracle (please
correct me if I misinterpreted your updated email address).
That's correct that "__get_block_group_index() > 1" would be a little
bit shorter way to evaluate the RAID flags. But the rest of the btrfs
code (except for btrfs_can_relocate()) also explicitly evaluates the
flags instead of using the array index that __get_block_group_index()
returns. It is just following the convention.
>> +num_tolerated_disk_barrier_failures = 0;
>> +else if (num_tolerated_disk_barrier_failures > 1
>> + &&
>> + (flags & (BTRFS_BLOCK_GROUP_RAID1 |
>> + BTRFS_BLOCK_GROUP_RAID10)))
>> +num_tolerated_disk_barrier_failures = 1;
>> +}
[...]
>> @@ -2807,6 +2812,26 @@ int btrfs_balance(struct btrfs_balance_control *bctl,
>> }
>> }
>>
>> +if (bctl->sys.flags & BTRFS_BALANCE_ARGS_CONVERT) {
>> +int num_tolerated_disk_barrier_failures;
>> +u64 target = bctl->sys.target;
>> +
>> +num_tolerated_disk_barrier_failures =
>> +btrfs_calc_num_tolerated_disk_barrier_failures(fs_info);
>> +if (num_tolerated_disk_barrier_failures > 0 &&
>> +(target &
>> + (BTRFS_BLOCK_GROUP_DUP | BTRFS_BLOCK_GROUP_RAID0 |
>> + BTRFS_AVAIL_ALLOC_BIT_SINGLE)))
>
> ditto.
Same as before + this time the code is working on the balance conversion
parameters where SINGLE is encoded in a different way.
--
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
Testing new send/receive: "ERROR: could not resolve root_id for"
Hello, i wanted to test the new send/receive feature and i can't manage to send a snapshot to a file. I always get the error "ERROR: could not resolve root_id for". I'm using kernel 3.6-rc1 and the latest btrfs progs from git. This is what i'm doing: mount -o subvolid=0,discard,compress=lzo /dev/sda4 /mnt/ROOT_BTRFS [root@robert-laptop mnt]# /home/robert/ArchLinux/btrfs-progs/btrfs subvolume list ROOT_BTRFS/ ID 256 top level 5 path btrfs_root <--- my rootfs subvolume ID 265 top level 5 path btrfs_root-11082012-0023 <--- a "normal" snapshot" ID 268 top level 5 path root_send <--- a read only snapshot i try to use with send [root@robert-laptop ~]# cd /mnt/ROOT_BTRFS/ [root@robert-laptop ROOT_BTRFS]# /home/robert/ArchLinux/btrfs-progs/btrfs send root_send > outROOT At subvol root_send ERROR: could not resolve root_id for /mnt/ROOT_BTRFS/root_send Am i somehow misunderstanding how the send/receive feature should work? My idea is to send the "root_send" snapshot to a file and then replay that file later on a backup btrfs partition. Once i've done that i can just send incremental differences to the backup partition. Is that how "send/receive" is supposed to work? If you need further information just tell me. Thanks in advance, Robert PS: Please respond to my email address as i'm not subscribed to the list. -- 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: fix gcc warnings for 32bit compiles
Signed-off-by: Jan Schmidt
---
fs/btrfs/backref.c | 25 +
fs/btrfs/file-item.c |2 +-
fs/btrfs/qgroup.c| 32
fs/btrfs/send.c |4 ++--
4 files changed, 32 insertions(+), 31 deletions(-)
diff --git a/fs/btrfs/backref.c b/fs/btrfs/backref.c
index 6655ca6..e600857 100644
--- a/fs/btrfs/backref.c
+++ b/fs/btrfs/backref.c
@@ -231,7 +231,7 @@ static int add_all_parents(struct btrfs_root *root, struct
btrfs_path *path,
}
if (!ret) {
ret = ulist_add(parents, eb->start,
- (u64)eie, GFP_NOFS);
+ (uintptr_t)eie, GFP_NOFS);
if (ret < 0)
break;
if (!extent_item_pos) {
@@ -363,8 +363,8 @@ static int __resolve_indirect_refs(struct btrfs_fs_info
*fs_info,
ULIST_ITER_INIT(&uiter);
node = ulist_next(parents, &uiter);
ref->parent = node ? node->val : 0;
- ref->inode_list =
- node ? (struct extent_inode_elem *)node->aux : 0;
+ ref->inode_list = node ?
+ (struct extent_inode_elem *)(uintptr_t)node->aux : 0;
/* additional parents require new refs being added here */
while ((node = ulist_next(parents, &uiter))) {
@@ -375,8 +375,8 @@ static int __resolve_indirect_refs(struct btrfs_fs_info
*fs_info,
}
memcpy(new_ref, ref, sizeof(*ref));
new_ref->parent = node->val;
- new_ref->inode_list =
- (struct extent_inode_elem *)node->aux;
+ new_ref->inode_list = (struct extent_inode_elem *)
+ (uintptr_t)node->aux;
list_add(&new_ref->list, &ref->list);
}
ulist_reinit(parents);
@@ -914,7 +914,7 @@ again:
free_extent_buffer(eb);
}
ret = ulist_add_merge(refs, ref->parent,
- (u64)ref->inode_list,
+ (uintptr_t)ref->inode_list,
(u64 *)&eie, GFP_NOFS);
if (!ret && extent_item_pos) {
/*
@@ -959,7 +959,7 @@ static void free_leaf_list(struct ulist *blocks)
while ((node = ulist_next(blocks, &uiter))) {
if (!node->aux)
continue;
- eie = (struct extent_inode_elem *)node->aux;
+ eie = (struct extent_inode_elem *)(uintptr_t)node->aux;
for (; eie; eie = eie_next) {
eie_next = eie->next;
kfree(eie);
@@ -1405,11 +1405,12 @@ int iterate_extent_inodes(struct btrfs_fs_info *fs_info,
while (!ret && (root_node = ulist_next(roots, &root_uiter))) {
pr_debug("root %llu references leaf %llu, data list "
"%#llx\n", root_node->val, ref_node->val,
-ref_node->aux);
- ret = iterate_leaf_refs(
- (struct extent_inode_elem *)ref_node->aux,
- root_node->val, extent_item_objectid,
- iterate, ctx);
+(long long)ref_node->aux);
+ ret = iterate_leaf_refs((struct extent_inode_elem *)
+ (uintptr_t)ref_node->aux,
+ root_node->val,
+ extent_item_objectid,
+ iterate, ctx);
}
ulist_free(roots);
roots = NULL;
diff --git a/fs/btrfs/file-item.c b/fs/btrfs/file-item.c
index 857d93c..54f0335 100644
--- a/fs/btrfs/file-item.c
+++ b/fs/btrfs/file-item.c
@@ -25,7 +25,7 @@
#include "transaction.h"
#include "print-tree.h"
-#define __MAX_CSUM_ITEMS(r, size) BTRFS_LEAF_DATA_SIZE(r) - \
+#define __MAX_CSUM_ITEMS(r, size) ((unsigned long)(((BTRFS_LEAF_DATA_SIZE(r) -
\
sizeof(struct btrfs_item) * 2) / \
size) - 1))
diff --git a/fs/btrfs/qgroup.c b/fs/btrfs/qgroup.c
index 1bc33c1..90619cc 100644
--- a/fs/btrfs/qgroup.c
+++ b/fs/btrfs/qgroup.c
@@ -1145,12 +1145,12 @@ int btrfs_qgroup_account_ref(struct btrfs_trans_handle
*trans,
ulist_reinit(tmp);
/* XXX id not needed */
- ulist_add(tmp,
