On 11/30/2018 09:05 AM, Anand Jain wrote:
On 11/29/2018 10:31 PM, David Sterba wrote:
On Wed, Nov 28, 2018 at 04:47:27PM +0800, Anand Jain wrote:
2. scrub_workers_refcnt must eventually be converted to refcount_t type
ok. Added in v2 patch set.
No such thing is in v2 and this would
v3: Drops the patch [1]from this set.
[1]
btrfs: scrub: maintain the unlock order in scrub thread
Fixes the circular locking dependency warning as in patch 1/2,
and patch 2/2 adds lockdep_assert_held() to scrub_workers_get().
Anand Jain (2):
btrfs: scrub: fix circular locking
Circular locking dependency check reports warning[1], that's because
the btrfs_scrub_dev() calls the stack #0 below with, the
fs_info::scrub_lock held. The test case leading to this warning..
mkfs.btrfs -fq /dev/sdb && mount /dev/sdb /btrfs
btrfs scrub start -B /btrfs
In fact we have
scrub_workers_refcnt is protected by scrub_lock, add lockdep_assert_held()
function in scrub_workers_get().
Signed-off-by: Anand Jain
Suggested-by: Nikolay Borisov
---
v3: none
v2: born
fs/btrfs/scrub.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/fs/btrfs/scrub.c b/fs/btrfs/scrub.c
On 11/29/2018 10:31 PM, David Sterba wrote:
On Wed, Nov 28, 2018 at 04:47:27PM +0800, Anand Jain wrote:
2. scrub_workers_refcnt must eventually be converted to refcount_t type
ok. Added in v2 patch set.
No such thing is in v2 and this would actually get rid of the need to
hold
On 11/29/2018 06:36 PM, Filipe Manana wrote:
On Thu, Nov 29, 2018 at 9:27 AM Anand Jain wrote:
The device_list_mutex and scrub_lock creates a nested locks in
btrfs_scrub_dev().
During lock the order is device_list_mutex and then scrub_lock, and during
unlock, the order is
On Wed, Nov 28, 2018 at 06:51:59PM +0200, Nikolay Borisov wrote:
> > Got me curious if we could get rid of the size parameter, it's 2x
> > PAGE_SIZE and could be something else in one case but it's not obvious
> > if it really happens.
> >
> > Another thing I noticed is lack of proper error
On 29.11.18 г. 18:43 ч., Jean Fobe wrote:
> Hi all,
> I've been studying LZ4 and other compression algorithms on the
> kernel, and seen other projects such as zram and ubifs using the
> crypto api. Is there a technical reason for not using the crypto api
> for compression (and possibly for
Hi all,
I've been studying LZ4 and other compression algorithms on the
kernel, and seen other projects such as zram and ubifs using the
crypto api. Is there a technical reason for not using the crypto api
for compression (and possibly for encryption) in btrfs?
I did not find any
extent_readpages processes all pages in the readlist in batches of 16,
this is implemented by a single for loop but thanks to an if condition
the loop does 2 things based on whether we've filled the batch or not.
Additionally due to the structure of the code there is an additional
check which
On Mon, Nov 26, 2018 at 04:53:11PM +, Filipe Manana wrote:
> On Fri, Nov 16, 2018 at 11:09 AM wrote:
> >
> > From: Filipe Manana
> >
> > Commit d7396f07358a ("Btrfs: optimize key searches in btrfs_search_slot"),
> > dated from August 2013, introduced an optimization to search for keys in a
>
On Wed, Nov 28, 2018 at 04:47:27PM +0800, Anand Jain wrote:
> > 2. scrub_workers_refcnt must eventually be converted to refcount_t type
>
> ok. Added in v2 patch set.
No such thing is in v2 and this would actually get rid of the need to
hold scrub_lock in scrub_workers_put. Which in turn can
Hi,
I've encountered mostly reproducable ENOSPC problem with send/receive.
The target is empty, newly created btrfs on regular HDD.
Reproduced twice with Arch Linux 4.19.4 kernel and once with the system
booted from arch install ISO
Current Release: 2018.11.01
Included Kernel: 4.18.16
The
On Thu, Nov 29, 2018 at 9:27 AM Anand Jain wrote:
>
> The device_list_mutex and scrub_lock creates a nested locks in
> btrfs_scrub_dev().
>
> During lock the order is device_list_mutex and then scrub_lock, and during
> unlock, the order is device_list_mutex and then scrub_lock.
> Fix this to the
On Thu, Nov 29, 2018 at 9:32 AM Lu Fengqi wrote:
>
> The btrfs/001 with inode_cache mount option will encounter the following
> warning:
"The test case btrfs/001 ..."
>
> WARNING: CPU: 1 PID: 23700 at fs/btrfs/inode.c:956
> cow_file_range.isra.19+0x32b/0x430 [btrfs]
> CPU: 1 PID: 23700 Comm:
The btrfs/001 with inode_cache mount option will encounter the following
warning:
WARNING: CPU: 1 PID: 23700 at fs/btrfs/inode.c:956
cow_file_range.isra.19+0x32b/0x430 [btrfs]
CPU: 1 PID: 23700 Comm: btrfs Kdump: loaded Tainted: GW O
4.20.0-rc4-custom+ #30
Hardware name: QEMU
Circular locking dependency check reports warning[1], that's because
the btrfs_scrub_dev() calls the stack #0 below with, the
fs_info::scrub_lock held. The test case leading to this warning..
mkfs.btrfs -fq /dev/sdb && mount /dev/sdb /btrfs
btrfs scrub start -B /btrfs
In fact we have
The device_list_mutex and scrub_lock creates a nested locks in
btrfs_scrub_dev().
During lock the order is device_list_mutex and then scrub_lock, and during
unlock, the order is device_list_mutex and then scrub_lock.
Fix this to the lock order of scrub_lock and then device_list_mutex.
Idea was to fix the circular locking dependency warning as in patch 2/3,
and in the process also fixes the other identified cleanups patches 1/3,3/3
and they aren't dependent on 2ttch /3.
Anand Jain (3):
btrfs: scrub: maintain the unlock order in scrub thread
btrfs: scrub: fix circular
scrub_workers_refcnt is protected by scrub_lock, add lockdep_assert_held()
function in scrub_workers_get().
Signed-off-by: Anand Jain
Suggested-by: Nikolay Borisov
---
v2: born
fs/btrfs/scrub.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/fs/btrfs/scrub.c b/fs/btrfs/scrub.c
index
20 matches
Mail list logo
