Hello,
On 07/31/2013 01:39 PM, Tomasz Chmielewski wrote:
> On Wed, 31 Jul 2013 13:13:37 +0800
> Wang Shilong wrote:
>
>>> # git pull origin master
>>
>> Oops, i am sorry, here should:
>>
>> git pull origin qgroup
>>
>> would you please try it again
>
> Excellent, it works:
>
> # btrfs qgroup s
On Wed, 31 Jul 2013 13:13:37 +0800
Wang Shilong wrote:
> > # git pull origin master
>
> Oops, i am sorry, here should:
>
> git pull origin qgroup
>
> would you please try it again
Excellent, it works:
# btrfs qgroup show -p /mnt/lxc2
0/260 154273873920 154273873920 ---
0/261 181260288 181260
On 07/31/2013 12:36 PM, Tomasz Chmielewski wrote:
> On Wed, 31 Jul 2013 12:19:36 +0800
> Wang Shilong wrote:
>
>> I have tried it and it works, you can do like the following to try it.
>>
>> #git clone http://github.com/miaoxie/btrfs-progs.git
>>
>> #cd btrfs-progs
>>
>> #git pull origin master
>
On Wed, 31 Jul 2013 12:19:36 +0800
Wang Shilong wrote:
> I have tried it and it works, you can do like the following to try it.
>
> #git clone http://github.com/miaoxie/btrfs-progs.git
>
> #cd btrfs-progs
>
> #git pull origin master
>
> #make && make install
Hmm:
# git clone http://github.c
On 07/31/2013 11:46 AM, Tomasz Chmielewski wrote:
> On Tue, 30 Jul 2013 21:06:32 +0800
> Wang Shilong wrote:
>
>> I have implemented the above function, but they haven't gone into
>> upstream Btrfs-progs.
>>
>> You can try this:
>>
>> http://github.com/miaoxie/btrfs-progs.git qgroup
>>
>> Ma
On Tue, 30 Jul 2013 21:06:32 +0800
Wang Shilong wrote:
> I have implemented the above function, but they haven't gone into
> upstream Btrfs-progs.
>
> You can try this:
>
> http://github.com/miaoxie/btrfs-progs.git qgroup
>
> Maybe i need rebase the patch-set later, But you can try it fi
Several users reported this crash of NULL pointer or general protection,
the story is that we add a rbtree for speedup ulist iteration, and we
use krealloc() to address ulist growth, and krealloc() use memcpy to copy
old data to new memory area, so it's OK for an array as it doesn't use
pointers wh
On tue, 30 Jul 2013 12:09:55 +0100, Filipe David Borba Manana wrote:
> Also remove unused path in extent-tree.c:finish_current_insert().
>
> Signed-off-by: Filipe David Borba Manana
> ---
>
> V2: added 1 more path alloc check and removed unnecessary path
> allocation in extent-tree.c:fi
On tue, 30 Jul 2013 12:08:17 +0100, Filipe David Borba Manana wrote:
> After reading all device items from the chunk tree, don't
> exit the loop and then navigate down the tree again to find
> the chunk items. Instead just read all device items and
> chunk items with a single tree search. This
On tue, 30 Jul 2013 12:03:04 +0100, Filipe David Borba Manana wrote:
> After reading all device items from the chunk tree, don't
> exit the loop and then navigate down the tree again to find
> the chunk items. Instead just read all device items and
> chunk items with a single tree search. This
Signed-off-by: Filipe David Borba Manana
---
fs/btrfs/disk-io.c |4
1 file changed, 4 insertions(+)
diff --git a/fs/btrfs/disk-io.c b/fs/btrfs/disk-io.c
index 254cdc8..b71e882 100644
--- a/fs/btrfs/disk-io.c
+++ b/fs/btrfs/disk-io.c
@@ -1148,6 +1148,10 @@ struct extent_buffer *read_tre
On Wed, Jul 31, 2013 at 12:00 AM, Zach Brown wrote:
>> diff --git a/fs/btrfs/backref.c b/fs/btrfs/backref.c
>> index 8bc5e8c..1ba87c5 100644
>> --- a/fs/btrfs/backref.c
>> +++ b/fs/btrfs/backref.c
>> @@ -935,6 +935,8 @@ again:
>> }
>> ret
Signed-off-by: Filipe David Borba Manana
---
V2: Ensure extent buffer is freed on error.
fs/btrfs/backref.c |4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/fs/btrfs/backref.c b/fs/btrfs/backref.c
index 8bc5e8c..980e85a 100644
--- a/fs/btrfs/backref.c
+++ b/fs/btrfs/ba
> diff --git a/fs/btrfs/backref.c b/fs/btrfs/backref.c
> index 8bc5e8c..1ba87c5 100644
> --- a/fs/btrfs/backref.c
> +++ b/fs/btrfs/backref.c
> @@ -935,6 +935,8 @@ again:
> }
> ret = find_extent_in_eb(eb, bytenr,
>
Josef Bacik dixit:
>So stripe_len shouldn't be 0, if it is you have bigger problems :).
☺
>Is this a corrupt fs or something? If there was some sort of
I don’t think so, I can access and use that filesystem under 3.2
just fine (it’s what I created it under, too, so it’s possible
that it’s indee
On Tue, 2013-07-30 at 16:40 -0400, Josef Bacik wrote:
> So stripe_len shouldn't be 0, if it is you have bigger problems :). Is this a
> corrupt fs or something? If there was some sort of corruption that occured
> then
> I suppose stripe_len could be 0 and we'd need to catch that somewhere higher
On Tue, Jul 30, 2013 at 07:02:29PM +, Thorsten Glaser wrote:
> Josef Bacik dixit:
>
> >Can you gdb btrfs.ko and do
> >
> >list *(__btrfs_map_block+0x11c)
>
> Not easily (the kernel image is from a .deb package),
> and even in a compile tree gdb just says:
> No symbol table is loaded. Use the
Previously we only added blocks to the list to have their backrefs checked if
the level of the block is right above the one we are searching for. This is
because we want to make sure we don't add the entire path up to the root to the
lists to make sure we process things one at a time. This assume
If our item isn't big enough to have an actual inline item when we have skinny
metadata enabled just return 1 in find_inline_backref so we can move on to the
next item. This probably wasn't causing a problem since we check the values of
ptr and end properly, but just in case this will keep us from
Josef Bacik dixit:
>Can you gdb btrfs.ko and do
>
>list *(__btrfs_map_block+0x11c)
Not easily (the kernel image is from a .deb package),
and even in a compile tree gdb just says:
No symbol table is loaded. Use the "file" command.
With a bit of cheating and a cross-compiler, this is:
(gdb) list
Signed-off-by: Filipe David Borba Manana
---
fs/btrfs/backref.c |2 ++
1 file changed, 2 insertions(+)
diff --git a/fs/btrfs/backref.c b/fs/btrfs/backref.c
index 8bc5e8c..1ba87c5 100644
--- a/fs/btrfs/backref.c
+++ b/fs/btrfs/backref.c
@@ -935,6 +935,8 @@ again:
On Tue, Jul 30, 2013 at 11:48:10AM +0800, Jeff Liu wrote:
> On 07/30/2013 02:55 AM, Josef Bacik wrote:
>
> > So df in btrfs is tricky at best, and relying on it for accurate
> > information is
> > not great, but it's the best way to verify this test. To get around btrfs
> > being
> > inconsiste
If we bail out when the stripe alloc fails, we need to undo the
earlier allocation of raid_map.
Signed-off-by: Dave Jones
diff --git a/fs/btrfs/volumes.c b/fs/btrfs/volumes.c
index 78b8717..6a0f52f 100644
--- a/fs/btrfs/volumes.c
+++ b/fs/btrfs/volumes.c
@@ -4671,6 +4671,7 @@ static int __btrfs_
On Tue, 2013-07-30 at 13:13 -0400, Josef Bacik wrote:
> I've looked at all the places we do divides in this function and it
> doesn't look like we're doing this anywhere but I could be blind,
do_div seems a likely suspect...
/*
* stripe_nr counts the total number of stripes we ha
On Tue, Jul 30, 2013 at 11:07:30AM +0200, Geert Uytterhoeven wrote:
> On Tue, 30 Jul 2013, Thorsten Glaser wrote:
> > NEW problem: btrfs doesn’t work at all. I had to reboot my
> > buildd into 3.2 using echo s/u/s/o >/proc/sysrq-trigger as
> > the attempt to mount it left the system hanging there.
Geert Uytterhoeven dixit:
> 0: 222e ff74 movel %fp@(-140),%d1
> 4: 2a2e ff5c movel %fp@(-164),%d5
> 8: 2c2e ff60 movel %fp@(-160),%d6
> c: 4c45 1402 < divul %d5,%d2,%d1 >
> 10: 2d40 ff64 movel %d0,%fp@(-156)
> 14: 2d41 ff68 movel %d1,%fp@(-152)
>
On Tue, Jul 30, 2013 at 06:11:39PM +0300, Alex Lyakas wrote:
> Hi Josef,
>
> On Tue, Apr 23, 2013 at 9:20 PM, Josef Bacik wrote:
> > We kept leaking extent buffers when mounting a broken file system and it
> > turns
> > out it's because not everybody uses read_tree_block properly. You need to
Hi Josef,
On Tue, Apr 23, 2013 at 9:20 PM, Josef Bacik wrote:
> We kept leaking extent buffers when mounting a broken file system and it turns
> out it's because not everybody uses read_tree_block properly. You need to
> check
> and make sure the extent_buffer is uptodate before you use it. Th
Hello,
> Unrecoverable?
> I know i cant mount and have access but my data are still there intact
> ( as i was using them till the reboot) i shouldn't be able to
> extract/recover them to another disc? With any magic command without
> mounting?
> Any other solutions?
As We Know chunk Tree really p
Hello,
> On Sun, 28 Jul 2013 15:36:41 +0800
> Wang Shilong wrote:
>
>> Btrfs group assign requires parent's level > children's level, For
>> your example below, you can do like:
>>
>> btrfs qgroup create 1/1
>> btrfs qgroup assign 1177 1/1
>> btrfs qgroup assign 1178 1/1
>
> Cool, thanks
On Sun, 28 Jul 2013 15:36:41 +0800
Wang Shilong wrote:
> Btrfs group assign requires parent's level > children's level, For
> your example below, you can do like:
>
> btrfs qgroup create 1/1
> btrfs qgroup assign 1177 1/1
> btrfs qgroup assign 1178 1/1
Cool, thanks.
And is it possible (i
Also remove unused path in extent-tree.c:finish_current_insert().
Signed-off-by: Filipe David Borba Manana
---
V2: added 1 more path alloc check and removed unnecessary path
allocation in extent-tree.c:finish_current_insert().
V3: added missing path alloc checks to dir-item.c, file-item.c
After reading all device items from the chunk tree, don't
exit the loop and then navigate down the tree again to find
the chunk items. Instead just read all device items and
chunk items with a single tree search. This is possible
because all device items are found before any chunk item in
the chunk
After reading all device items from the chunk tree, don't
exit the loop and then navigate down the tree again to find
the chunk items. Instead just read all device items and
chunk items with a single tree search. This is possible
because all device items are found before any chunk item in
the chunk
On Mon, July 29, 2013 at 17:32 (+0200), BJ Quinn wrote:
> Thanks for the response! Not sure I want to roll a custom kernel on this
> particular system. Any idea on when it might make it to 3.10 stable or
> 3.11? Or should I just revert back to 3.9?
I missed that it's in fact in 3.11 and if I g
On Tue, 30 Jul 2013, Thorsten Glaser wrote:
> NEW problem: btrfs doesn’t work at all. I had to reboot my
> buildd into 3.2 using echo s/u/s/o >/proc/sysrq-trigger as
> the attempt to mount it left the system hanging there.
> [0.00] Linux version 3.10-1-m68k (debian-ker...@lists.debian.org)
Thanks for posting that patch, Josef.
On Mon, Jul 15, 2013 at 6:59 PM, Josef Bacik wrote:
>
> Alex pointed out a problem and fix that exists in the drop one snapshot at
> a
> time patch. If we decide we need to exit for whatever reason (umount for
> example) we will just exit the snapshot droppi
37 matches
Mail list logo
