move_curseg_info->reset_curseg changes cursegs, however, new segment
entries are not set as dirty. As a result, flush_sit_entries will not
update entries in SIT, especially when an empty segment is selected
as the new curseg, its seg_entry->type is lost.
Signed-off-by: Sheng Yong
---
If curseg is an empty segment, it will not be checked. This patch
introduces fsck_chk_curseg_info() to check SIT/SSA type of cursegs
to avoid curseg corruption.
Signed-off-by: Sheng Yong
---
fsck/fsck.c | 34 ++
fsck/fsck.h | 1 +
fsck/main.c | 2 ++
3 files
eck over the patchset and see if anything else got dropped!
>
> Can you please repost when you have this sorted?
>
> I think the commit you've pointed to is in your xarray-20180601 branch, but I
> see two more recent xarray branches in your tree (xarray-20180608 and
> xarra
commit you've pointed to is in your xarray-20180601 branch, but I
see two more recent xarray branches in your tree (xarray-20180608 and
xarray-20180612).
Basically, I don't know what is stable and what's not, and what I should be
reviewing/testing.
Ping,
Jaegeuk, sometimes, we suffer data corruption caused by bit-transition of cache,
we troubleshoot for weeks or months, and finally, find that it is caused by
hardware. So for this case, maybe in-memory checksum can help to troubleshoot
more quickly.
Could you consider this?
Thanks,
On
On Tue, Jun 12, 2018 at 12:40:41PM +0200, David Sterba wrote:
> [ 9875.174796] kernel BUG at fs/inode.c:513!
What the ...
Somehow the fix for that got dropped. I spent most of last week chasing
that problem! This is the correct code:
On Mon, Jun 11, 2018 at 07:05:27AM -0700, Matthew Wilcox wrote:
> From: Matthew Wilcox
>
> The XArray is a replacement for the radix tree. For the moment it uses
> the same data structures, enabling a gradual replacement. This patch
> set implements the XArray and converts the page cache to
