On 11/07/2018 08:15 PM, Nikolay Borisov wrote:
On 7.11.18 г. 13:43 ч., Anand Jain wrote:
We recast the replace return status
BTRFS_IOCTL_DEV_REPLACE_RESULT_SCRUB_INPROGRESS to 0, to indicate no
error.
And since BTRFS_IOCTL_DEV_REPLACE_RESULT_NO_ERROR should also return 0,
which is also decl
On 8.11.18 г. 4:15 ч., YueHaibing wrote:
> Fixes gcc '-Wunused-but-set-variable' warning:
>
> fs/btrfs/compression.c: In function 'end_compressed_bio_write':
> fs/btrfs/compression.c:232:25: warning:
> variable 'tree' set but not used [-Wunused-but-set-variable]
>
> It not used any more after
On 8.11.18 г. 4:14 ч., YueHaibing wrote:
> Fixes gcc '-Wunused-but-set-variable' warning:
>
> fs/btrfs/extent_io.c: In function 'end_extent_writepage':
> fs/btrfs/extent_io.c:2406:25: warning:
> variable 'tree' set but not used [-Wunused-but-set-variable]
>
> It not used any more after
> comm
Before this patch, qgroup code trace the whole subtree of file and reloc
trees unconditionally.
This makes qgroup numbers consistent, but it could cause tons of
unnecessary extent trace, which cause a lot of overhead.
However for subtree swap of balance, since both subtree contains the
same conte
Relocation code will drop btrfs_root::reloc_root as soon as
merge_reloc_root() finishes.
However later qgroup code will need to access btrfs_root::reloc_root
after merge_reloc_root() for delayed subtree rescan.
So alter the timming of resetting btrfs_root:::reloc_root, make it
happens after trans
This patchset can be fetched from github:
https://github.com/adam900710/linux/tree/qgroup_delayed_subtree_rebased
Which is based on v4.20-rc1.
This patch address the heavy load subtree scan, but delaying it until
we're going to modify the swapped tree block.
The overall workflow is:
1) Record t
Since it's replaced by new delayed subtree swap code, remove the
original code.
The cleanup is small since most of its core function is still used by
delayed subtree swap trace.
Signed-off-by: Qu Wenruo
---
fs/btrfs/qgroup.c | 94 ---
fs/btrfs/qgroup.
Refactor btrfs_qgroup_trace_subtree_swap() into
qgroup_trace_subtree_swap(), which only needs two extent buffer and some
other bool to control the behavior.
Also, allow depending functions to accept parameter @exec_post to
determine whether we need to trigger backref walk.
This provides the basis
Commit fb235dc06fac ("btrfs: qgroup: Move half of the qgroup accounting
time out of commit trans") makes btrfs_qgroup_extent_record::old_roots
populated at insert time.
It's OK for most cases as btrfs_qgroup_extent_record is inserted at
delayed ref head insert time, which has a less restrict lock
To allow delayed subtree swap rescan, btrfs needs to record per-root
info about which tree blocks get swapped.
So this patch introduces per-root btrfs_qgroup_swapped_blocks structure,
which records which tree blocks get swapped.
The designed workflow will be:
1) Record the subtree root block get
Fixes gcc '-Wunused-but-set-variable' warning:
fs/btrfs/compression.c: In function 'end_compressed_bio_write':
fs/btrfs/compression.c:232:25: warning:
variable 'tree' set but not used [-Wunused-but-set-variable]
It not used any more after
commit 2922040236f9 ("btrfs: Remove extent_io_ops::writep
Fixes gcc '-Wunused-but-set-variable' warning:
fs/btrfs/extent_io.c: In function 'end_extent_writepage':
fs/btrfs/extent_io.c:2406:25: warning:
variable 'tree' set but not used [-Wunused-but-set-variable]
It not used any more after
commit 2922040236f9 ("btrfs: Remove extent_io_ops::writepage_end
On Mon, Nov 05, 2018 at 11:14:17AM +, fdman...@kernel.org wrote:
> From: Filipe Manana
>
> We currently allow cloning a range from a file which includes the last
> block of the file even if the file's size is not aligned to the block
> size. This is fine and useful when the destination file h
On Wed, Oct 31, 2018 at 10:06:08AM -0700, Omar Sandoval wrote:
> From: Omar Sandoval
>
> There's a race between close_ctree() and cleaner_kthread().
> close_ctree() sets btrfs_fs_closing(), and the cleaner stops when it
> sees it set, but this is racy; the cleaner might have already checked
> the
On Wed, Nov 07, 2018 at 05:07:00PM +0200, Nikolay Borisov wrote:
>
>
> On 7.11.18 г. 16:49 ч., David Sterba wrote:
> > On Tue, Nov 06, 2018 at 10:54:51AM +0100, David Sterba wrote:
> >> On Thu, Sep 27, 2018 at 11:17:32AM -0700, Omar Sandoval wrote:
> >>> From: Omar Sandoval
> >>> This series imp
On 7.11.18 г. 16:49 ч., David Sterba wrote:
> On Tue, Nov 06, 2018 at 10:54:51AM +0100, David Sterba wrote:
>> On Thu, Sep 27, 2018 at 11:17:32AM -0700, Omar Sandoval wrote:
>>> From: Omar Sandoval
>>> This series implements swap file support for Btrfs.
>>>
>>> Changes from v8 [1]:
>>>
>>> - Fi
On Tue, Nov 06, 2018 at 10:54:51AM +0100, David Sterba wrote:
> On Thu, Sep 27, 2018 at 11:17:32AM -0700, Omar Sandoval wrote:
> > From: Omar Sandoval
> > This series implements swap file support for Btrfs.
> >
> > Changes from v8 [1]:
> >
> > - Fixed a bug in btrfs_swap_activate() which would c
On 7.11.18 г. 13:43 ч., Anand Jain wrote:
> At the time of forced unmount we place the running replace to
> BTRFS_IOCTL_DEV_REPLACE_STATE_SUSPENDED state, so when the system comes
> back and suppose the target device is missing, then let the replace
> state continue to be in BTRFS_IOCTL_DEV_REPL
On 7.11.18 г. 14:25 ч., Nikolay Borisov wrote:
>
>
> On 7.11.18 г. 13:43 ч., Anand Jain wrote:
>> In btrfs_dev_replace_cancel() we should check if the
>> btrfs_scrub_cancel() is successful. If the btrfs_scrub_cancel() fails, return
>> BTRFS_IOCTL_DEV_REPLACE_RESULT_NOT_STARTED so that user can
On 7.11.18 г. 13:43 ч., Anand Jain wrote:
> In btrfs_dev_replace_cancel() we should check if the
> btrfs_scrub_cancel() is successful. If the btrfs_scrub_cancel() fails, return
> BTRFS_IOCTL_DEV_REPLACE_RESULT_NOT_STARTED so that user can try to
> cancel the replace again.
>
> Signed-off-by: An
On 7.11.18 г. 13:43 ч., Anand Jain wrote:
> + /* scrub for replace must not be running in suspended state */
> + if (btrfs_scrub_cancel(fs_info) != -ENOTCONN)
> + ASSERT(0);
ASSERT(btrfs_scrub_cancel(fs_info) == -ENOTCONN)
On 7.11.18 г. 13:43 ч., Anand Jain wrote:
> - WARN_ON(ret);
> + if (ret != -ECANCELED)
> + WARN_ON(ret);
WARN_ON(ret && ret != -ECANCELED)
On 7.11.18 г. 13:43 ч., Anand Jain wrote:
> We recast the replace return status
> BTRFS_IOCTL_DEV_REPLACE_RESULT_SCRUB_INPROGRESS to 0, to indicate no
> error.
> And since BTRFS_IOCTL_DEV_REPLACE_RESULT_NO_ERROR should also return 0,
> which is also declared as 0, so we just return. Instead add
On 7.11.18 г. 13:43 ч., Anand Jain wrote:
> There isn't any other consumer other than in its own file dev-replace.c.
>
> Signed-off-by: Anand Jain
Reviewed-by: Nikolay Borisov
> ---
> fs/btrfs/dev-replace.c | 2 +-
> fs/btrfs/dev-replace.h | 3 ---
> 2 files changed, 1 insertion(+), 4 dele
As of now only user requested replace cancel can cancel the replace-scrub
so no need to log error for it.
Signed-off-by: Anand Jain
---
fs/btrfs/dev-replace.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/fs/btrfs/dev-replace.c b/fs/btrfs/dev-replace.c
index c14c41b70287.
When we successfully cancel the replace its scrub returns -ECANCELED,
which then passed to btrfs_dev_replace_finishing(), it cleans up based
on the scrub returned status and propagates the same -ECANCELED back
the parent function. So skip the -ECANCELED error to log the WARN.
Signed-off-by: Anand
When the replace state is placed in the suspended state,
btrfs_scrub_cancel() should fail with -ENOTCONN as there is no
scrub running, as a safety catch check if btrfs_scrub_cancel()
returns -ENOTCONN and assert if it doesn't.
Signed-off-by: Anand Jain
---
fs/btrfs/dev-replace.c | 4 +++-
1 file
Replace-start and replace-cancel threads can race to create a messy
situation leading to UAF. We use the scrub code to write
the blocks on the replace target. So if we haven't have set the
replace-scrub-running yet, without this patch we just ignore the error
and free the target device. When this h
In btrfs_dev_replace_cancel() we should check if the
btrfs_scrub_cancel() is successful. If the btrfs_scrub_cancel() fails, return
BTRFS_IOCTL_DEV_REPLACE_RESULT_NOT_STARTED so that user can try to
cancel the replace again.
Signed-off-by: Anand Jain
---
fs/btrfs/dev-replace.c | 22 +-
At the time of forced unmount we place the running replace to
BTRFS_IOCTL_DEV_REPLACE_STATE_SUSPENDED state, so when the system comes
back and suppose the target device is missing, then let the replace
state continue to be in BTRFS_IOCTL_DEV_REPLACE_STATE_SUSPENDED state
instead of BTRFS_IOCTL_DEV_
There isn't any other consumer other than in its own file dev-replace.c.
Signed-off-by: Anand Jain
---
fs/btrfs/dev-replace.c | 2 +-
fs/btrfs/dev-replace.h | 3 ---
2 files changed, 1 insertion(+), 4 deletions(-)
diff --git a/fs/btrfs/dev-replace.c b/fs/btrfs/dev-replace.c
index 2aa48aecc52b..
We recast the replace return status
BTRFS_IOCTL_DEV_REPLACE_RESULT_SCRUB_INPROGRESS to 0, to indicate no
error.
And since BTRFS_IOCTL_DEV_REPLACE_RESULT_NO_ERROR should also return 0,
which is also declared as 0, so we just return. Instead add it to the if
statement so that there is enough clarity
replace cancel thread can race with the replace start thread and if
fs_info::scrubs_running is not yet set the btrfs_scrub_cancel() will fail
to stop the scrub thread, so the scrub thread continue with the scrub for
replace which then shall try to write to the target device and which is
already fre
In a secnario where balance and replace co-exists as below,
start balance; pause balance; start replace; reboot
and when system restarts balance restarts first and the
replace restart will fail as EXCL OP lock is already held by
the balance. If so place the replace state back to
BTRFS_IOCTL_DEV_R
On Tue, Nov 06, 2018 at 07:43:04PM +, Nick Terrell wrote:
> > On Nov 6, 2018, at 6:48 AM, Daniel Kiper wrote:
> > On Wed, Oct 31, 2018 at 10:56:16AM -0700, Nick Terrell wrote:
> >> Import zstd-1.3.6 from upstream [1]. Only the files need for decompression
> >> are imported. Additionally makes
On 2018/11/7 下午5:09, Su Yanjun wrote:
>
>
> On 10/24/2018 8:29 AM, Qu Wenruo wrote:
>>
>> On 2018/10/23 下午5:41, Su Yue wrote:
>>> From: Su Yanjun
>>>
>>> The reason for revert is that according to the existing situation, the
>>> probability of problem in the extent tree is higher than in the
On 10/24/2018 8:29 AM, Qu Wenruo wrote:
On 2018/10/23 下午5:41, Su Yue wrote:
From: Su Yanjun
The reason for revert is that according to the existing situation, the
probability of problem in the extent tree is higher than in the fs Tree.
So this feature should be removed.
The same problem
37 matches
Mail list logo