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:[] []
>> ftrace_raw_event_block_bio_complete+0x73/0xf0
> ...
>> [] bio_endio+0x80/0x90
>> [] btrfs_end_bio+0xf6/0x190 [btrfs]
>> [] b
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
Signed-off-by: Anand Jain
---
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 cmd_subvol_show(int argc
On Fri, 19 Apr 2013 17:38:29 +0800, Anand Jain wrote:
> Signed-off-by: Anand Jain
> ---
> 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/cm
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
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 hig
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 thin
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:[] []
> > ftrace_raw_event_block_bio_complete+0x73/0xf0
> ...
> > [] bio_endio+0x80/0x90
> > [] btrfs_end_bio+0xf6/0x190 [btrfs]
> > [] bio_endio+0x3d/0
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 ca
Signed-off-by: Stefan Behrens
---
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
--- a/fs/btrfs/ctree.h
+++ b/fs/btrfs/c
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 UU
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 too
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 subvolum
This commit adds support to print UUID tree elements to print-tree.c.
Signed-off-by: Stefan Behrens
---
fs/btrfs/print-tree.c | 73 +++
1 file changed, 73 insertions(+)
diff --git a/fs/btrfs/print-tree.c b/fs/btrfs/print-tree.c
index dc0024f..6e20
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 s
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.
Signed-off-by:
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 too
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 be
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()
find_eb_for_
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
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()
> __btrfs_search_delay
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] ",
+ "btrfs resto
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
btrfs_read_and_process_send_stream() recently changed its prototype;
this gets it building again. 0 means "do not honor the "
which was the previous default, before
2bfac02 Btrfs-progs: btrfs-receive optionally honors the end-cmd
Signed-off-by: Eric Sandeen
---
I . . . guess 0 is sane for this
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:
Signed-
26 matches
Mail list logo
