We can re-use the dynamic debugging descriptor to make use of the dynamic
debugging mechanism but still use our own printk interface.
Defining the DEBUG macro works as it did before. When it's defined,
all of the messages default to print. We can also enable all debug
messages at boot or module-
On 8/31/16 10:02 PM, Fennec Fox wrote:
> Linux Titanium 4.7.2-1-MANJARO #1 SMP PREEMPT Sun Aug 21 15:04:37 UTC
> 2016 x86_64 GNU/Linux
> btrfs-progs v4.7
>
> Data, single: total=30.01GiB, used=18.95GiB
> System, single: total=4.00MiB, used=16.00KiB
> Metadata, single: total=1.01GiB, used=422.17MiB
Linux Titanium 4.7.2-1-MANJARO #1 SMP PREEMPT Sun Aug 21 15:04:37 UTC
2016 x86_64 GNU/Linux
btrfs-progs v4.7
Data, single: total=30.01GiB, used=18.95GiB
System, single: total=4.00MiB, used=16.00KiB
Metadata, single: total=1.01GiB, used=422.17MiB
GlobalReserve, single: total=144.00MiB, used=0.00B
At 09/01/2016 08:54 AM, Liu Bo wrote:
On Thu, Sep 01, 2016 at 08:32:00AM +0800, Qu Wenruo wrote:
At 09/01/2016 07:43 AM, Liu Bo wrote:
Qgroup function may overwrite the saved error 'err' with 0
in case quota is not enabled, and this ends up with a
endless loop in balance because we keep goi
On Thu, Sep 01, 2016 at 08:32:00AM +0800, Qu Wenruo wrote:
>
>
> At 09/01/2016 07:43 AM, Liu Bo wrote:
> > Qgroup function may overwrite the saved error 'err' with 0
> > in case quota is not enabled, and this ends up with a
> > endless loop in balance because we keep going back to balance
> > the
At 09/01/2016 07:43 AM, Liu Bo wrote:
Qgroup function may overwrite the saved error 'err' with 0
in case quota is not enabled, and this ends up with a
endless loop in balance because we keep going back to balance
the same block group.
In which case?
If join_trans() fails, we won't go through
Qgroup function may overwrite the saved error 'err' with 0
in case quota is not enabled, and this ends up with a
endless loop in balance because we keep going back to balance
the same block group.
It really should use 'ret' instead.
Signed-off-by: Liu Bo
---
fs/btrfs/relocation.c | 8 +---
On Wed, Aug 31, 2016 at 5:03 PM, Jeff Mahoney wrote:
> On 8/31/16 6:58 PM, Chris Murphy wrote:
> Does Ronan's call trace showing
>> /fs/btrfs/qgroup.c:2667
>>> btrfs_qgroup_free_meta implicate qgroups as a possible source of his
>>> problem? That trace would only happen if quotas were enabled, r
ro,degraded has mounted it nicely and my rsync of the more useful data
is progressing at the speed of WiFi.
There are repeated read errors from one drive still but the rsync
hasn't bailed yet, which I think means there isn't any overlapping
errors in any of the files it has touched thus far. Am I
On 8/31/16 6:58 PM, Chris Murphy wrote:
> On Wed, Aug 31, 2016 at 4:47 PM, Jeff Mahoney wrote:
>> On 8/31/16 5:48 PM, Chris Murphy wrote:
>>> OK it looks like with -w flag I can get a reliable indication of
>>> whether quota is enabled or not:
>>>
>>> [root@f24s ~]# btrfs quota enable /mnt/0
>>> [
On Wed, Aug 31, 2016 at 4:47 PM, Jeff Mahoney wrote:
> On 8/31/16 5:48 PM, Chris Murphy wrote:
>> OK it looks like with -w flag I can get a reliable indication of
>> whether quota is enabled or not:
>>
>> [root@f24s ~]# btrfs quota enable /mnt/0
>> [root@f24s ~]# btrfs quota rescan -w /mnt/0
>> qu
On 8/31/16 5:48 PM, Chris Murphy wrote:
> OK it looks like with -w flag I can get a reliable indication of
> whether quota is enabled or not:
>
> [root@f24s ~]# btrfs quota enable /mnt/0
> [root@f24s ~]# btrfs quota rescan -w /mnt/0
> quota rescan started
> [root@f24s ~]# btrfs quota disable /mnt/
On 8/31/16 3:08 PM, David Sterba wrote:
> On Wed, Aug 31, 2016 at 10:13:49AM -0500, Eric Sandeen wrote:
>> A /sys/kernel/debug/btrfs/test file was added nearly
>> two and a half years ago, but it serves no purpose;
>
> It does. Introduced in 1bae30982bc86ab66d61ccb6e22792593b45d44d says
> somethin
On 8/31/16 2:08 PM, David Sterba wrote:
> On Wed, Aug 31, 2016 at 10:13:49AM -0500, Eric Sandeen wrote:
>> A /sys/kernel/debug/btrfs/test file was added nearly
>> two and a half years ago, but it serves no purpose;
>
> It does. Introduced in 1bae30982bc86ab66d61ccb6e22792593b45d44d says
> somethin
This is still happening with btrfs-progs 4.7.1 and there is zero
information in the long result what to do about the problem, and
whether it's sane to try have --repair fix it, let alone what the
original cause of the problem was.
--
Chris Murphy
--
To unsubscribe from this list: send the line
btrfs provides a helpful demonstration of how to export
a global variable via debugfs; however, it is unique among
other debugfs files in that it is world-writable, which causes
some concern to people who are not familiar with its purpose.
Fix it so that it is only user-writable.
Signed-off-by: E
OK it looks like with -w flag I can get a reliable indication of
whether quota is enabled or not:
[root@f24s ~]# btrfs quota enable /mnt/0
[root@f24s ~]# btrfs quota rescan -w /mnt/0
quota rescan started
[root@f24s ~]# btrfs quota disable /mnt/0
[root@f24s ~]# btrfs quota rescan -w /mnt/0
ERROR: q
On Wed, Aug 31, 2016 at 2:49 PM, Ronan Arraes Jardim Chagas
wrote:
> Hi guys!
>
> And the problem happened again. This time, I was only using Mozilla
> Firefox. I could get the very first message after the error. I hope it
> brings more information:
>
> [28039.672199] [ cut here ]-
Hi guys!
And the problem happened again. This time, I was only using Mozilla
Firefox. I could get the very first message after the error. I hope it
brings more information:
[28039.672199] [ cut here ]
[28039.672253] WARNING: CPU: 3 PID: 31800 at ../fs/btrfs/qgroup.c:2667
b
On Wed, Aug 31, 2016 at 10:13:49AM -0500, Eric Sandeen wrote:
> A /sys/kernel/debug/btrfs/test file was added nearly
> two and a half years ago, but it serves no purpose;
It does. Introduced in 1bae30982bc86ab66d61ccb6e22792593b45d44d says
something about helping developers to easily export inform
On 08/31/2016 07:46 AM, Wang Xiaoguang wrote:
If can_overcommit() in btrfs_calc_reclaim_metadata_size() returns true,
btrfs_async_reclaim_metadata_space() will not reclaim metadata space, just
return directly and also forget to wake up process which are waiting for
their tickets, so these process
A /sys/kernel/debug/btrfs/test file was added nearly
two and a half years ago, but it serves no purpose;
it stores and returns a value, but nothing in the btrfs
code uses this value in any way. There are no other btrfs
files in this debugfs dir.
This was brought to my attention because it is worl
If can_overcommit() in btrfs_calc_reclaim_metadata_size() returns true,
btrfs_async_reclaim_metadata_space() will not reclaim metadata space, just
return directly and also forget to wake up process which are waiting for
their tickets, so these processes will wait endlessly.
Fstests case generic/17
23 matches
Mail list logo
