On 01/10/2019 03:48 AM, Filipe Manana wrote:
On Wed, Jan 9, 2019 at 6:27 PM David Sterba wrote:
On Thu, Dec 13, 2018 at 09:17:25PM +, fdman...@kernel.org wrote:
- if (list_empty(&fs_devices->resized_devices))
- return;
-
- mutex_lock(&fs_devices->device_list_mutex);
On 9.01.19 г. 20:26 ч., David Sterba wrote:
> On Thu, Dec 13, 2018 at 09:17:25PM +, fdman...@kernel.org wrote:
>> -if (list_empty(&fs_devices->resized_devices))
>> -return;
>> -
>> -mutex_lock(&fs_devices->device_list_mutex);
>> mutex_lock(&fs_info->chunk_mutex);
>>
On 01/10/2019 02:14 PM, Qu Wenruo wrote:
btrfs/16[123] are all seed device related test cases, make them into
'seed' group.
Signed-off-by: Qu Wenruo
Reviewed-by: Anand Jain
---
tests/btrfs/group | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/tests/btrfs/gro
btrfs/16[123] are all seed device related test cases, make them into
'seed' group.
Signed-off-by: Qu Wenruo
---
tests/btrfs/group | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/tests/btrfs/group b/tests/btrfs/group
index b78ed37fd9f1..04c0254aa4bf 100644
--- a/tests/bt
Commit fb235dc06fac ("btrfs: qgroup: Move half of the qgroup accounting
time out of commit trans") could cause ABBA deadlock between backref
lookup with write lock hold (subvolume deletion) and other read/write
operations.
It's going to be fixed by "btrfs: qgroup: Don't trigger backref walk at
del
Gentle ping.
Although this is just a dirty fix, it would be much better to avoid seed
device users yelling at me.
Thanks,
Qu
On 2019/1/8 下午2:08, Qu Wenruo wrote:
> [BUG]
> Linux v5.0-rc1 will fail fstests/btrfs/163 with the following kernel
> message:
>
> BTRFS error (device dm-6): dev extent
if, before the first balance run, many blocks were filled only in
parts, a behavior like this can be happen, because btrfs aggregate the
used space in a new block.
a second full balance run, should solve this.
you didn't need to move data away. btrfs only need a few GB of
unalloceted space for bal
On 1/9/19 11:03 AM, Nikolay Borisov wrote:
On 9.01.19 г. 11:16 ч., Florian Stecker wrote:
Provide output of echo w > /proc/sysrq-trigger when the hang occurs
otherwise it's hard to figure what's going on.
Here's one, again in gajim. This time, fdatasync() took "only" 2 seconds:
[42481.
On Wed, Jan 9, 2019 at 6:27 PM David Sterba wrote:
>
> On Thu, Dec 13, 2018 at 09:17:25PM +, fdman...@kernel.org wrote:
> > - if (list_empty(&fs_devices->resized_devices))
> > - return;
> > -
> > - mutex_lock(&fs_devices->device_list_mutex);
> > mutex_lock(&fs_info->c
On Thu, Dec 13, 2018 at 09:17:25PM +, fdman...@kernel.org wrote:
> - if (list_empty(&fs_devices->resized_devices))
> - return;
> -
> - mutex_lock(&fs_devices->device_list_mutex);
> mutex_lock(&fs_info->chunk_mutex);
> list_for_each_entry_safe(curr, next, &fs_devi
Just a short answer.
I didn't use the replace command.
I added the new drive to the pool / array, and checked that it was
registered.
Following that I removed the 1TB drive with "btrfs device delete ".
As far as I know this should avoid the need to resize the new drive.
"btrfs fi us" shows a
This reverts commit e73e81b6d0114d4a303205a952ab2e87c44bd279.
This patch causes a few problems:
- adds latency to btrfs_finish_ordered_io
- as btrfs_finish_ordered_io is used for free space cache, generating
more work from btrfs_btree_balance_dirty_nodelay could end up in the
same workque, ef
On 09/01/2019 15:43, Nikolay Borisov wrote:
> If we run out of memory during delalloc filling in compress case btrfs
> is going to BUG_ON. This is unnecessary since the higher levels code
> (btrfs_run_delalloc_range and its callers) gracefully handle error
> condtions and error out the page being s
If we run out of memory during delalloc filling in compress case btrfs
is going to BUG_ON. This is unnecessary since the higher levels code
(btrfs_run_delalloc_range and its callers) gracefully handle error
condtions and error out the page being submittede. Let's be a model
kernel citizen and no pa
On Tue, Jan 08, 2019 at 04:53:46PM +0200, Nikolay Borisov wrote:
> We can never have extents marked as EXTENT_MAP_DELALLOC since this
> value is only ever used by btrfs_get_extent_fiemap. In this case the
> extent map is created by btrfs_get_extent_fiemap and is never really
> published, this flag
On Tue, Jan 8, 2019 at 9:43 PM Paul Jones wrote:
>
> > -Original Message-
> > From: linux-btrfs-ow...@vger.kernel.org > ow...@vger.kernel.org> On Behalf Of Tomasz Chmielewski
> > Sent: Saturday, 5 January 2019 12:25 AM
> > To: Btrfs BTRFS
> > Subject: dedicated metadata drives?
> >
> > A
Jojo writes:
>
> Within scheduler there were some changes according to device queueing.
> Kernels after 4.16 and before 4.19.8 were problematic, as we recognized
> here.
> This seemed to be a regression on the "kyber" scheduler, as recognized here:
> [root@pc7 sysctl.d]# cat /sys/block/sdc
Am 09.01.19 um 11:54 schrieb Scott E. Blomquist:
>
> Hi All,
>
> I have a system that has been hanging/wedging frequently. It seems to
> be load dependent but have not been able to isolate the problem. The
> only option once the hang happens is to reboot via
> /proc/sysreq_trigger
>
> btrfs fi
Hi All,
I have a system that has been hanging/wedging frequently. It seems to
be load dependent but have not been able to isolate the problem. The
only option once the hang happens is to reboot via
/proc/sysreq_trigger
In dmesg I see this...
[Tue Jan 8 16:03:40 2019] perf: interrupt too
David Sterba 於 2019-01-04 23:59 寫到:
On Thu, Dec 13, 2018 at 04:38:48PM +0800, ethanlien wrote:
Chris Mason 於 2018-12-12 22:47 寫到:
> On 28 May 2018, at 1:48, Ethan Lien wrote:
>
> It took me a while to trigger, but this actually deadlocks ;) More
> below.
>
>> [Problem description and how we fix
On 9.01.19 г. 11:16 ч., Florian Stecker wrote:
>>
>> Provide output of echo w > /proc/sysrq-trigger when the hang occurs
>> otherwise it's hard to figure what's going on.
>>
>
> Here's one, again in gajim. This time, fdatasync() took "only" 2 seconds:
>
> [42481.243491] sysrq: SysRq : Show Blo
>
> Provide output of echo w > /proc/sysrq-trigger when the hang occurs
> otherwise it's hard to figure what's going on.
>
Here's one, again in gajim. This time, fdatasync() took "only" 2 seconds:
[42481.243491] sysrq: SysRq : Show Blocked State
[42481.243494] taskPC st
22 matches
Mail list logo
