Hello,
I've done a prototype implementation of snapshot diff utility many months ago.
It was originally meant to analyze the differences between two snapshots which
are
inherited from the same subvolume/snapshot.
Moreover, the upstream LXC userland tools has been released with a dedicated
Make ino_resolve() shared so that we can call it at snapshot diff module.
Signed-off-by: Jie Liu jeff@oracle.com
---
btrfs-list.c |3 +--
btrfs-list.h | 22 ++
2 files changed, 23 insertions(+), 2 deletions(-)
create mode 100644 btrfs-list.h
diff --git
Maybe it's better to put those #defines to the source file of snapshot diff as
no other modules
need them.
Signed-off-by: Jie Liu jeff@oracle.com
---
diff-snapshot.h | 47 +++
1 files changed, 47 insertions(+), 0 deletions(-)
create mode
Now the source file is coming.
Signed-off-by: Jie Liu jeff@oracle.com
---
diff-snapshot.c | 1026 +++
1 files changed, 1026 insertions(+), 0 deletions(-)
create mode 100644 diff-snapshot.c
diff --git a/diff-snapshot.c b/diff-snapshot.c
Signed-off-by: Jie Liu jeff@oracle.com
---
Makefile |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/Makefile b/Makefile
index 969..f8b517d 100644
--- a/Makefile
+++ b/Makefile
@@ -4,7 +4,7 @@ CFLAGS = -g -O0
objects = ctree.o disk-io.o radix-tree.o
make this feature works as `btrfs subvolume diff-snapshot [options] src
dest`.
Signed-off-by: Jie Liu jeff@oracle.com
---
cmds-subvolume.c | 90 ++
1 files changed, 90 insertions(+), 0 deletions(-)
diff --git a/cmds-subvolume.c
Unfortunately I only have a screenshot.
Apparently the panic was in
btrfs_set_lock_blocking_rw
with a RIP in btrfs_cow_block
Screenshot here:
http://marc.merlins.org/tmp/btrfs_oops.jpg
Because the display looks a bit messed up, I can't tell if the ata error
happened before or after the oops.
On 08/07/2012 07:40 PM, Marc MERLIN wrote:
Unfortunately I only have a screenshot.
Apparently the panic was in
btrfs_set_lock_blocking_rw
with a RIP in btrfs_cow_block
Can you please resolve btrfs_cow_block+0x3b to a line number?
gdb btrfs.ko
(gdb) info line *btrfs_cow_block+0x3b
On Tue, Aug 07, 2012 at 08:14:23PM +0200, Arne Jansen wrote:
On 08/07/2012 07:40 PM, Marc MERLIN wrote:
Unfortunately I only have a screenshot.
Apparently the panic was in
btrfs_set_lock_blocking_rw
with a RIP in btrfs_cow_block
Can you please resolve btrfs_cow_block+0x3b to a line
Daniel Blueman reported a bug with fio+balance on a ramdisk setup.
Basically what happens is the balance relocates a tree block which will drop
the implicit refs for all of its children and adds a full backref. Once the
block is relocated we have to add the implicit refs back, so when we cow the
Josef Bacik jba...@fusionio.com writes:
This is in the IO path, let's try to avoid latencies by having our own slab.
Thanks,
What latencies does this avoid?
-Andi
--
a...@linux.intel.com -- Speaking for myself only
--
To unsubscribe from this list: send the line unsubscribe linux-btrfs in
On Tue, Aug 7, 2012 at 1:40 PM, Marc MERLIN m...@merlins.org wrote:
System rebooted ok.
I just want to be sure that you are aware that your hard drive is
currently killing itself. Those READ FPDMA QUEUED mean that your hard
disk is relocatting bad sectors and has problem reading those.
--
To
On Tue, Aug 07, 2012 at 10:38:28PM -0400, Jérôme Poulin wrote:
On Tue, Aug 7, 2012 at 1:40 PM, Marc MERLIN m...@merlins.org wrote:
System rebooted ok.
I just want to be sure that you are aware that your hard drive is
currently killing itself. Those READ FPDMA QUEUED mean that your hard
From: Chen Yang chenyang.f...@cn.fujitsu.com
This patch adds the function to check correspondence
between block group, chunk and device extent.
Signed-off-by: Cheng Yang chenyang.f...@cn.fujitsu.com
---
v1-v2: optimaze the checking process:
* Remove the checking traversal of block group
14 matches
Mail list logo
