From: Su Yue
Move "\n" at end of the sentence to print.
Fixes: 281eec7a9ddf ("btrfs-progs: check: repair inode nbytes in lowmem mode")
Signed-off-by: Su Yue
---
check/mode-lowmem.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/check/mode-lowmem.c b/check/mode-lowmem.c
ind
From: Su Yue
Previously, @err are assigned immediately after check but before
repair.
repair_extent_item()'s return value also confuses the caller. If
error has been repaired and returns 0, check_extent_item() will try
to continue check the nonexistent and cause false alerts.
Here make repair_ex
From: Su Yue
For files, lowmem repair will try to check nbytes and isize,
but isize check depends nbytes.
Once bytes has been repaired, then isize should be checked and
repaired.
So move nbytes check before isize check. Also set nbytes to
extent_size once repaired successfully.
Signed-off-by: S
From: Su Yue
Since repair will do CoW, the outer path may be invalid,
add an argument path to punch_extent_hole().
When punch_extent_hole() returns, path will still point to the item
before calling punch_extent_hole();
Signed-off-by: Su Yue
---
Changelog:
v2:
Remove varaiable @ret2.
Call bt
On 2018/11/28 12:04 PM, Qu Wenruo wrote:
On 2018/11/28 上午11:11, Su Yue wrote:
This patchset can be fetched from repo:
https://github.com/Damenly/btrfs-devel/commits/priority_aware_allocator.
Since patchset 'btrfs: Refactor find_free_extent()' does a nice work
to simplify find_free_extent().
I was having the same issue with kernels 4.19.2 and 4.19.4. I don’t appear to
have the issue with 4.20.0-0.rc1 on Fedora Server 29.
The issue is very easy to reproduce on my setup, not sure how much of it is
actually relevant, but here it is:
- 3 drive RAID5 created
- Some data moved to it
- Ex
I obviously can't be sure (due to obscure nature of this issue) but I
think I observed similar behavior. For me it usually kicked in during
scheduled de-fragmentation runs. I initially suspected it might have
something to do with running defrag on files which are still opened
for appending writes (
Hi all:
I'm wonding why we should recheck inode->i_size and
zero_user_segment the page's tail which crossed the EOF, I think it's
already zerofilled in function __do_readpage.
function end_bio_extent_readpage:
2597 readpage_ok:
2598 if (likely(uptodate)) {
2599
