On Thu, Apr 18, 2013 at 10:57:54PM -0700, Tejun Heo wrote:
No wonder this thing crashes. Chris, can't the original bio carry
bbio in bi_private and let end_bio_extent_readpage() free the bbio
instead of abusing bi_bdev like this?
BTW, I think it's a bit too late to fix this properly from
On 04/19/2013 02:17 PM, Tejun Heo wrote:
On Thu, Apr 18, 2013 at 10:57:54PM -0700, Tejun Heo wrote:
No wonder this thing crashes. Chris, can't the original bio carry
bbio in bi_private and let end_bio_extent_readpage() free the bbio
instead of abusing bi_bdev like this?
BTW, I think it's a
On Fri, April 19, 2013 at 07:57 (+0200), Tejun Heo wrote:
(cc'ing btrfs people)
On Fri, Apr 19, 2013 at 11:33:20AM +0800, Wanlong Gao wrote:
RIP: 0010:[812484d3] [812484d3]
ftrace_raw_event_block_bio_complete+0x73/0xf0
...
[811b6c10] bio_endio+0x80/0x90
Another reproducer is reporting the same effect. as below.
mkfs.btrfs /dev/dm-2 /dev/dm-4 -f -m raid1 -d raid1
x=0 0 3 0; echo scsi remove-single-device $x /proc/scsi/scsi
mount -o degraded /dev/dm-2 /btrfs
btrfs fi show
Label: none uuid: 8ae8e37e-9f04-4a90-9c85-0c75a7622405
Am Dienstag, 16. April 2013 schrieb Martin Steigerwald:
On Saturday 13 April 2013 17:48:31 Martin Steigerwald wrote:
Hi!
Please answer soon whether it would be a good idea to replay a backup
right now as I am leaving to Berlin tomorrow for a week without my
backup drive with me. Well,
Signed-off-by: Anand Jain anand.j...@oracle.com
---
cmds-subvolume.c | 12
1 file changed, 8 insertions(+), 4 deletions(-)
diff --git a/cmds-subvolume.c b/cmds-subvolume.c
index 74e2130..e3b8032 100644
--- a/cmds-subvolume.c
+++ b/cmds-subvolume.c
@@ -800,16 +800,18 @@ static int
On Fri, 19 Apr 2013 17:38:29 +0800, Anand Jain wrote:
Signed-off-by: Anand Jain anand.j...@oracle.com
---
cmds-subvolume.c | 12
1 file changed, 8 insertions(+), 4 deletions(-)
diff --git a/cmds-subvolume.c b/cmds-subvolume.c
index 74e2130..e3b8032 100644
---
On Fri, Apr 19, 2013 at 11:15:30AM +0200, Martin Steigerwald wrote:
Am Dienstag, 16. April 2013 schrieb Martin Steigerwald:
On Saturday 13 April 2013 17:48:31 Martin Steigerwald wrote:
Hi!
Please answer soon whether it would be a good idea to replay a backup
right now as I am
Quoting Tejun Heo (2013-04-19 01:57:54)
Ewweehh
No wonder this thing crashes. Chris, can't the original bio carry
bbio in bi_private and let end_bio_extent_readpage() free the bbio
instead of abusing bi_bdev like this?
Yes, we can definitely carry bbio up higher
On Thu, Apr 18 2013, Tejun Heo wrote:
On Thu, Apr 18, 2013 at 10:57:54PM -0700, Tejun Heo wrote:
No wonder this thing crashes. Chris, can't the original bio carry
bbio in bi_private and let end_bio_extent_readpage() free the bbio
instead of abusing bi_bdev like this?
BTW, I think it's a
On Thu, Apr 18 2013, Tejun Heo wrote:
(cc'ing btrfs people)
On Fri, Apr 19, 2013 at 11:33:20AM +0800, Wanlong Gao wrote:
RIP: 0010:[812484d3] [812484d3]
ftrace_raw_event_block_bio_complete+0x73/0xf0
...
[811b6c10] bio_endio+0x80/0x90
[a0790d26]
Quoting Jens Axboe (2013-04-19 09:32:50)
No wonder this thing crashes. Chris, can't the original bio carry
bbio in bi_private and let end_bio_extent_readpage() free the bbio
instead of abusing bi_bdev like this?
Ugh, wtf.
Chris, time for a swim in the bay :-)
Yeah, I can't really
Signed-off-by: Stefan Behrens sbehr...@giantdisaster.de
---
fs/btrfs/ctree.h | 5 ++---
fs/btrfs/disk-io.c | 2 +-
fs/btrfs/root-tree.c | 7 +++
3 files changed, 6 insertions(+), 8 deletions(-)
diff --git a/fs/btrfs/ctree.h b/fs/btrfs/ctree.h
index 412c306..84be717 100644
---
It is a rare exception that a new tree is created, like the qgroups
tree. So far these new trees have an all-zero UUID in their root
items. All trees that mkfs.btrfs has created get an UUID during the
first mount when btrfs_read_root_item() rewrites the root_item to
the v2 structure style. These
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 subvolume if 10,000 subvolumes exist. But
even linear effort would be
When a new subvolume or snapshot is created, a new UUID item is added
to the UUID tree. Such items are removed when the subvolume is deleted.
The ioctl to set the received subvolume UUID is also touched and will
now also add this received UUID into the UUID tree together with the
ID of the
This commit adds support to print UUID tree elements to print-tree.c.
Signed-off-by: Stefan Behrens sbehr...@giantdisaster.de
---
fs/btrfs/print-tree.c | 73 +++
1 file changed, 73 insertions(+)
diff --git a/fs/btrfs/print-tree.c
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 that in case somebody wants
to unmount the filesystem while the task is
This tree is not created by mkfs.btrfs. Therefore when a filesystem
is mounted writable and the UUID tree does not exist, this tree is
created if required. The tree is also added to the fs_info structure
and initialized, but this commit does not yet read or write UUID tree
elements.
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 subvolume if 10,000 subvolumes exist. But
even linear effort would be
On 02/25/2013 10:25 PM, Suman C wrote:
Thanks for the sparse file idea, I am actually using that solution
already. I am not sure if its the best way, however.
(Sorry to respond to such an old thread.)
Hi Suman,
I think zvol-like functionality would be very nice for btrfs to have. It
would
Big patch, but all it does is add statics to functions which
are in fact static, then remove the associated dead-code fallout.
removed functions:
btrfs_iref_to_path()
__btrfs_lookup_delayed_deletion_item()
__btrfs_search_delayed_insertion_item()
__btrfs_search_delayed_deletion_item()
Am Freitag, 19. April 2013 schrieb Liu Bo:
On Fri, Apr 19, 2013 at 11:15:30AM +0200, Martin Steigerwald wrote:
Am Dienstag, 16. April 2013 schrieb Martin Steigerwald:
On Saturday 13 April 2013 17:48:31 Martin Steigerwald wrote:
Hi!
Please answer soon whether it would be a good
Hello Eric,
Big patch, but all it does is add statics to functions which
are in fact static, then remove the associated dead-code fallout.
removed functions:
btrfs_iref_to_path()
__btrfs_lookup_delayed_deletion_item()
__btrfs_search_delayed_insertion_item()
The following is a minor patch to cmds-restore.c
diff --git a/cmds-restore.c b/cmds-restore.c
index c75e187..273c813 100644
--- a/cmds-restore.c
+++ b/cmds-restore.c
@@ -917,14 +917,16 @@ out:
}
const char * const cmd_restore_usage[] = {
- btrfs restore [options] device,
+ btrfs
On Fri, Apr 19, 2013 at 03:15:30AM -0600, Martin Steigerwald wrote:
Am Dienstag, 16. April 2013 schrieb Martin Steigerwald:
On Saturday 13 April 2013 17:48:31 Martin Steigerwald wrote:
Hi!
Please answer soon whether it would be a good idea to replay a backup
right now as I am
btrfs_read_and_process_send_stream() recently changed its prototype;
this gets it building again. 0 means do not honor the end cmd
which was the previous default, before
2bfac02 Btrfs-progs: btrfs-receive optionally honors the end-cmd
Signed-off-by: Eric Sandeen sand...@redhat.com
---
I . . .
On 4/19/13 7:11 PM, Jon Nelson wrote:
The following is a minor patch to cmds-restore.c
Hi Jon - just a note -
When sending a patch like this, it's best to follow the standard
patch format, which closely mimics the kernel patch submission
guidelines:
Subject: [PATCH] btrfs-progs: descriptive
28 matches
Mail list logo
