From 33e376755b8a928610032a1cef024dcdd980aee3 Mon Sep 17 00:00:00 2001
From: chandan chan...@linux.vnet.ibm.com
Date: Tue, 16 Jul 2013 12:28:56 +0530
Subject: [PATCH] btrfs_read_block_groups: Use enums to index
btrfs_space_info-block_groups.
The current code uses integer literals to index
Josef,
Thanks for your help so far. I am continuing on your recommendations:
08:55 josef knoppix: ok i pushed to for-knoppix
08:55 josef pull and build
08:55 josef and then run ./btrfsck --init-csum-tree /dev/whatever
08:55 josef it will clear your csum tree and re-populate it
08:55 josef once
This shows exactly how btrfs processes the delayed refs onto disks,
which is very helpful on understanding delayed ref mechanism and
debugging related bugs.
Signed-off-by: Liu Bo bo.li@oracle.com
---
fs/btrfs/delayed-ref.c |6 ++--
fs/btrfs/extent-tree.c |6
On Mon, Jul 15, 2013 at 12:56:29AM -0400, George Amvrosiadis wrote:
I'm trying to run the varmail personality in filebench, on a 50GB btrfs
filesystem. I am also starting the scrubber at the same time. I have
applied the latest patches for 3.8.13 (hoping to fix log tree issues).
There's a
Hi,
I have found (probably) a bug in btrfs check. I have a file system
with errors (potentially a broken disk, although smartctl and
badblocks didn't reveal any errors I keep getting file system
corruptions). When I try to repair it using btrfs check /dev/sdb1,
the tool aborts after a while:
On Tue, 16 Jul 2013 13:37:45 +0200, David Sterba wrote:
On Mon, Jul 15, 2013 at 12:56:29AM -0400, George Amvrosiadis wrote:
I'm trying to run the varmail personality in filebench, on a 50GB btrfs
filesystem. I am also starting the scrubber at the same time. I have
applied the latest patches
This is confusing, sometimes the key type is printed in hex (without
a leading 0x which makes things even more complicated), sometimes
in decimal...
Change it to be in decimal everywhere.
Signed-off-by: Stefan Behrens sbehr...@giantdisaster.de
---
fs/btrfs/print-tree.c | 4 ++--
1 file changed,
On Mon, Jul 15, 2013 at 7:43 PM, Josef Bacik jba...@fusionio.com wrote:
We aren't setting path-locks[level] when we resume a snapshot deletion which
means we won't unlock the buffer when we free the path. This causes deadlocks
if we happen to re-allocate the block before we've evicted the
FYI, updating to 3.10 seems to have solved the problem (after some
rigorous testing, I haven't been able to trigger the BUG again).
item 0 key (18446744073709551606 80 6597246976)
Is (objectid = -10 = BTRFS_EXTENT_CSUM_OBJECTID, type = 0x80 =
BTRFS_EXTENT_CSUM_KEY)
unable to update root
On Tue, Jul 16, 2013 at 03:38:33PM +0200, Stefan Behrens wrote:
This is confusing, sometimes the key type is printed in hex (without
a leading 0x which makes things even more complicated), sometimes
in decimal...
Change it to be in decimal everywhere.
This seems particularly reasonable to me
This is a nice overview
https://btrfs.wiki.kernel.org/index.php/Data_Structures but does not
show how things work. Would be helpful if there was a presentation
that shows what happens when for example you copy a file to understand
the use of each tree better?
I don't understand what went wrong in
On Mon, 15 Jul 2013 13:55:51 -0700, Zach Brown wrote:
I'd get rid of all this code by only copying each input argument on to
the stack as it's needed and by getting rid of the writable output
struct fields. (more on this later)
As I said, I'd get rid of the output fields. Like the other
Since the new chunk recovery patches are merged,
what about merging this patch to add chunk corruption function? :)
Qu
于 2013年06月07日 10:25, Qu Wenruo 写道:
Add chunk corrupt function to btrfs-corrupt-block.
This funtion can be used to delete or corrupt a given chunk or the whole
chunk tree.
Strings being grep-able is important. Thanks Stefan and Eric
for the comments.
Hopefully we shall have some better ways to handle long strings.
OR
shorter error message and still communicate the
intended message is another choice but challenging. :-)
I have dropped this patch for
14 matches
Mail list logo
