Hi,
While originally debugging some tree mod log thing, I'm seeing space info
warnings along the way, running cmason/master (f46dbe3de). I just drop them off,
haven't looked into it any deeper than "most likely not tree mod log related".
-Jan
<6>[ 1131.563658] device label quota devid 1 transid
From: Anand Jain
Signed-off-by: Anand Jain
---
btrfs-list.c | 11 +++
btrfs-list.h |2 ++
2 files changed, 13 insertions(+), 0 deletions(-)
diff --git a/btrfs-list.c b/btrfs-list.c
index 9cfdb35..462e049 100644
--- a/btrfs-list.c
+++ b/btrfs-list.c
@@ -1181,6 +1181,17 @@ void btr
From: Anand Jain
Signed-off-by: Anand Jain
---
btrfs-list.c |6 ++
btrfs-list.h |1 +
2 files changed, 7 insertions(+), 0 deletions(-)
diff --git a/btrfs-list.c b/btrfs-list.c
index 462e049..369500d 100644
--- a/btrfs-list.c
+++ b/btrfs-list.c
@@ -1144,6 +1144,11 @@ static int filt
From: Anand Jain
btrfs su list -a /btrfs/sv1
ID 256 gen 6 top level 5 path /sv1
ID 258 gen 6 top level 5 path /ss1
Signed-off-by: Anand Jain
---
cmds-subvolume.c | 15 +--
1 files changed, 13 insertions(+), 2 deletions(-)
diff --git a/cmds-subvolume.c b/cmds-subvolume.c
index a3
From: Anand Jain
btrfs su list -s /btrfs
ID 258 gen 6 cgen 6 top level 5 otime 2012-10-18 17:01:56 uuid
f648cdda-4efa-6f45-bd6b-041a8ae1538e path ss1
ID 260 gen 8 cgen 8 top level 5 otime 2012-10-18 17:02:20 uuid
ea8fdf85-8d3f-8946-b3af-ede510cdcf19 path ss2
ID 261 gen 9 cgen 9 top level 5 otim
From: Anand Jain
This set of patch will make
btrfs su list -s
to list only snapshot(s) of the given subvol.
before:
btrfs su list -s /btrfs/sv1
btrfs su list -s /btrfs
ID 258 gen 6 cgen 6 top level 5 otime 2012-10-18 17:01:56 uuid
f648cdda-4efa-6f45-bd6b-041a8ae1538e path ss1
ID 260 gen 8 cge
On 10/19/2012 01:13 PM, Jan Schmidt wrote:
> On Thu, October 18, 2012 at 09:32 (+0200), Liu Bo wrote:
>> Key MOD_LOG_KEY_REMOVE_WHILE_MOVING means that we're doing memmove inside
>> an extent buffer node, and the node's number of items remains unchanged,
>> so we don't need to increment node's numb
On Thu, October 18, 2012 at 09:32 (+0200), Liu Bo wrote:
> Key MOD_LOG_KEY_REMOVE_WHILE_MOVING means that we're doing memmove inside
> an extent buffer node, and the node's number of items remains unchanged,
> so we don't need to increment node's number of items during rewinding,
> otherwise we may
On Thu, Oct 18, 2012 at 9:28 PM, Chris Mason wrote:
>
> Usually when btrfs is slow to mount, or slow right after a mount it is
> because we're regenerating the free space cache. This is slow enough
> that you should be able to see the free space cache threads active even
> after the initial boot
On Thu, Oct 18, 2012 at 05:29:50AM -0600, Marguerite Su wrote:
> Hi, all,
>
> I ran into a situation that no useful information can be found over
> the internet...
>
> I'm using 3.6.2 + btrfs git compiled using dkms, and I have a 300GB
> btrfs /home and 50GB btrfs /:
Usually when btrfs is slow t
From: Wang Shilong
btrfs snapshot list command will stop by the deleted subvolumes.
The problem may happen by two ways:
1. a subvolume deletion is not commited, that is ROOT_BACKREF has been deleted,
but ROOT_ITEM still exists. The command will fail to fill the path of
the deleted subvolum
Hi, all,
I ran into a situation that no useful information can be found over
the internet...
I'm using 3.6.2 + btrfs git compiled using dkms, and I have a 300GB
btrfs /home and 50GB btrfs /:
Disk /dev/sda: 1000.2 GB, 1000204886016 bytes
255 heads, 63 sectors/track, 121601 cylinders, total 195352
Hi Miao,
On Thu, Oct 18, 2012 at 4:00 AM, Miao Xie wrote:
> On Wed, 17 Oct 2012 18:06:52 +0200, Alex Lyakas wrote:
>> -static int __list_subvol_fill_paths(int fd, struct root_lookup *root_lookup)
>> +static int __list_subvol_fill_paths(int fd, struct root_lookup *root_lookup,
>> + struct roo
On 10/18/2012 04:18 PM, Miao Xie wrote:
> When we find a bitmap free space entry, we may check the previous extent
> entry covers the offset or not. But if we find this entry is also a bitmap
> entry, we will continue to check the previous entry of the current one by
> a while loop. It is unnecessa
When we find a bitmap free space entry, we may check the previous extent
entry covers the offset or not. But if we find this entry is also a bitmap
entry, we will continue to check the previous entry of the current one by
a while loop. It is unnecessary because it is impossible that the extent
entr
When we find a bitmap free space entry, we may check the previous extent
entry covers the offset or not. But if we find this entry is also a bitmap
entry, we will continue to check the previous entry of the current one by
a while loop. It is unnecessary because it is impossible that the extent
entr
On 10/18/2012 03:42 PM, Jan Schmidt wrote:
> On Thu, October 18, 2012 at 09:36 (+0200), Liu Bo wrote:
>> On 10/18/2012 03:31 PM, Jan Schmidt wrote:
>>> On Thu, October 18, 2012 at 09:10 (+0200), Liu Bo wrote:
Parents must be same after going through ref_for_same_block.
>>>
>>> Well. We could k
On Thu, October 18, 2012 at 09:36 (+0200), Liu Bo wrote:
> On 10/18/2012 03:31 PM, Jan Schmidt wrote:
>> On Thu, October 18, 2012 at 09:10 (+0200), Liu Bo wrote:
>>> Parents must be same after going through ref_for_same_block.
>>
>> Well. We could kill that for the moment. However, ref_for_same_blo
On 10/18/2012 03:31 PM, Jan Schmidt wrote:
> On Thu, October 18, 2012 at 09:10 (+0200), Liu Bo wrote:
>> Parents must be same after going through ref_for_same_block.
>
> Well. We could kill that for the moment. However, ref_for_same_block wasn't
> meant to check for the parent. We should do ...
>
Key MOD_LOG_KEY_REMOVE_WHILE_MOVING means that we're doing memmove inside
an extent buffer node, and the node's number of items remains unchanged,
so we don't need to increment node's number of items during rewinding,
otherwise we may get an node larger than leafsize and cause general protection
er
On Thu, October 18, 2012 at 09:10 (+0200), Liu Bo wrote:
> Parents must be same after going through ref_for_same_block.
Well. We could kill that for the moment. However, ref_for_same_block wasn't
meant to check for the parent. We should do ...
--- a/fs/btrfs/backref.c
+++ b/fs/btrfs/backref.c
@@
Parents must be same after going through ref_for_same_block.
Signed-off-by: Liu Bo
---
fs/btrfs/backref.c |6 --
1 files changed, 0 insertions(+), 6 deletions(-)
diff --git a/fs/btrfs/backref.c b/fs/btrfs/backref.c
index f318793..9aaa38e6 100644
--- a/fs/btrfs/backref.c
+++ b/fs/btrfs/b
22 matches
Mail list logo
