Hello
On my HP Compaq dc5800 with Ubuntu 13.04 and their 3.8.0-19-lowlatency
kernel, I've got quite some kernel traces in the syslog. You can find
them below or at http://pastebin.com/bLXPBX67 (to avoid line breaks…).
These kernel traces all begin with:
WARNING: at fs/btrfs/free-space-cache.c:92
Thanks Stefan.
::
About the issue you mentioned, that you need to change the kernel and
the user mode at the same time:
You can keep it compatible. Just do not delete the old kernel interface.
The user mode program could try the new interface first, and if it
fails, fall back to the old inte
If you want to make this give you more
specific errors then adjust the errno's we send back and make the userspace util
translate those to their appropriate error. Thanks,
Thats the approach #1 as listed before in this mail thread,
let me give a try.
Anand
--
To unsubscribe from this lis
On Mon, Apr 29, 2013 at 9:20 PM, Stephen Weinberg wrote:
> I ran into a panic while running find -xdev | xargs brtfs fi defrag '{}'. I
> don't remember the exact command because the history was not saved. I also
> started and stopped it a few times however.
>
> The kernel logs were on a different
I ran into a panic while running find -xdev | xargs brtfs fi defrag
'{}'. I don't remember the exact command because the history was not
saved. I also started and stopped it a few times however.
The kernel logs were on a different filesystem. Here is the
kern.log:http://fpaste.org/9383/3672919
On Sat, Apr 27, 2013 at 10:50:43AM +0800, Liu Bo wrote:
> > @@ -3486,14 +3486,14 @@ int close_ctree(struct btrfs_root *root)
> >percpu_counter_sum(&fs_info->delalloc_bytes));
> > }
> >
> > - free_root_pointers(fs_info, 1);
> > -
> > btrfs_free_block_gr
We can just look up the extent_buffers for the range and free stuff that way.
This makes the cleanup a bit cleaner and we can make sure to evict the
extent_buffers pretty quickly by marking them as stale. Thanks,
Signed-off-by: Josef Bacik
---
V1->V2: fix infinite loop if we can't find our eb.
On Fri, Apr 19, 2013 at 09:41:02AM -0600, Stefan Behrens wrote:
> Mapping UUIDs to subvolume IDs is an operation with a high effort
> today. Today, the algorithm even has quadratic effort (based on the
> number of existing subvolumes), which means, that it takes minutes
> to send/receive a single s
On Fri, Apr 26, 2013 at 03:41:15AM -0600, Anand Jain wrote:
> adds a parameter in the ioctl arg struct to carry the error string
>
I don't like this approach, we are API'ifying strings coming back from the
kernel.
> Signed-off-by: Anand Jain
> ---
> fs/btrfs/ioctl.c | 42
From: Henrik Nordvik
Code checked for raid 5 flag in two else-if branches, so code would never be
reached. Probably a copy-paste bug.
Signed-off-by: Henrik Nordvik
---
fs/btrfs/disk-io.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/fs/btrfs/disk-io.c b/fs/btrfs/disk-io.
On Mon, 29 Apr 2013 17:12:20 +0200, David Sterba wrote:
> On Fri, Apr 19, 2013 at 05:41:06PM +0200, Stefan Behrens wrote:
[...]
>> +up(&fs_info->uuid_scan_sem);
>
> Does lockdep need to be instructed that a semaphore is released in a
> different thread it's been taken? Not sure if this wasn't
On Fri, Apr 19, 2013 at 05:41:06PM +0200, Stefan Behrens wrote:
> When the UUID tree is initially created, a task is spawned that
> walks through the root tree. For each found subvolume root_item,
> the uuid and received_uuid entries in the UUID tree are added.
> This is such a quick operation so t
On Fri, Apr 19, 2013 at 05:41:05PM +0200, Stefan Behrens wrote:
> --- a/fs/btrfs/ioctl.c
> +++ b/fs/btrfs/ioctl.c
> @@ -57,6 +57,8 @@
> #include "send.h"
> #include "dev-replace.h"
>
> +static char empty_uuid[BTRFS_UUID_SIZE] = {0};
+ const
> @@ -567,9 +573,10 @@ static int create_snapshot(st
On Fri, Apr 19, 2013 at 05:41:04PM +0200, Stefan Behrens wrote:
> @@ -2830,6 +2857,15 @@ retry_root_backup:
> return ret;
> }
>
> + if (need_to_create_uuid_tree) {
> + ret = btrfs_create_uuid_tree(fs_info, tree_root);
> + if (ret) {
> +
On Fri, Apr 19, 2013 at 05:41:03PM +0200, Stefan Behrens wrote:
> --- a/fs/btrfs/print-tree.c
> +++ b/fs/btrfs/print-tree.c
> +static void print_uuid_item(struct extent_buffer *l,
> + struct btrfs_uuid_item *ptr,
> + u64 item_size)
> +{
> + do {
>
If you try to mount -o loop a restored file system it will panic if the file
ends up being smaller than the original disk. This is because we go to try and
get a block for a super that may be past the EOF which makes __getblk return
NULL for a buffer head when we aren't expecting it to. Fix this
The variable was named 'data' in btrfs_reserve_extent and that's the
only function that actually uses it to let btrfs_get_alloc_profile know
what profile we want. Then it's passed down as u64 flags.
Signed-off-by: David Sterba
---
fs/btrfs/ctree.h |2 +-
fs/btrfs/extent-tree.c | 37 +
Signed-off-by: David Sterba
---
fs/btrfs/extent_io.c | 48 +---
fs/btrfs/extent_io.h | 28 +++-
fs/btrfs/inode.c |5 +++--
3 files changed, 43 insertions(+), 38 deletions(-)
diff --git a/fs/btrfs/extent_io.c b/fs/btr
After commit a65917156e34594 ("Btrfs: stop using highmem for
extent_buffers") we don't need to call kmap_atomic anymore and can
reduce the move_pages helper to a simple memmove.
There's only one caller of memcpy_extent_buffer, we can use the
memmove_ variant here.
Signed-off-by: David Sterba
---
On Mon, Apr 29, 2013 at 04:32:26AM -0600, Jan Schmidt wrote:
> Hi Josef,
>
> tried your btrfs-image tool (which didn't work for me but that's not that
> important).
>
> # ~/btrfs-image /dev/sdt1 /var/tmp/janosch.btrfsimage
> # mount -o loop /var/tmp/janosch.btrfsimage /mnt/test
> mount: you must
Hi Josef,
tried your btrfs-image tool (which didn't work for me but that's not that
important).
# ~/btrfs-image /dev/sdt1 /var/tmp/janosch.btrfsimage
# mount -o loop /var/tmp/janosch.btrfsimage /mnt/test
mount: you must specify the filesystem type
Doesn't mount, okay. Use -r:
# ~/btrfs-image -r
Since send-utils.o needs it and send-utils.o is part of the exported
libbtrfs functionality.
Signed-off-by: Stefan Behrens
---
Makefile | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/Makefile b/Makefile
index 98aa87e..589c60d 100644
--- a/Makefile
+++ b/Makefile
@@ -11,7 +
22 matches
Mail list logo
