[vdo-devel] can vdo fix corruption by itself?

[Łukasz Michalski]

On 24/11/2020 12.49, d tbsky wrote:
> Hi:
>    today I want to stop vdo service and I found that I can not stop
> it. the process "kvdo0:dedupeQ" is still running. so I reboot the
> server and the situation is the same.
> I notice that vdo is busy working out something. so I reboot again and
> umount the file system above vdo so maybe it can recover faster. I use
> 'iostat -xm 3' to check the io pattern, and found vdo is busy reading
> the disk but it seems write nothing. it had worked the way  for
> several hours. I wonder if it will recover eventually? I didn't see
> fsck-like tool for vdo, so I can only wait. the file system above vdo
> is working normally, but I am afraid about the situation.
> kernel message below:
>
> [root at backup-hq ~]# dmesg | grep vdo
> [   34.995729] kvdo: modprobe: loaded version 6.1.3.23
> [   35.023434] kvdo0:dmsetup: starting device 'vdo-backup'
> [   35.118060] kvdo0:dmsetup: underlying device, REQ_FLUSH: supported,
> REQ_FUA: supported
> [   35.127365] kvdo0:dmsetup: Using write policy async automatically.
> [   35.135039] kvdo0:dmsetup: zones: 1 logical, 1 physical, 1 hash;
> base threads: 5
> [   76.312024] kvdo0:journalQ: VDO commencing normal operation
> [   76.320426] uds: kvdo0:dedupeQ: loading or rebuilding index:
> dev=/dev/drbd1 offset=4096 size=192220721152
> [   76.320235] kvdo0:dmsetup: Setting UDS index target state to online
> [   76.343123] kvdo0:dmsetup: device 'vdo-backup' started
> [   76.355454] uds: kvdo0:dedupeQ: Using 4 indexing zones for concurrency.
> [   76.350729] kvdo0:dmsetup: resuming device 'vdo-backup'
> [   76.369187] kvdo0:dmsetup: device 'vdo-backup' resumed
> [   76.681311] kvdo0:packerQ: compression is enabled
> [   76.746243] uds: kvdo0:dedupeQ: verifyBufferedData got unexpected
> data: UDS Error: Corrupt saved component (1030)
> [  104.521929] uds: kvdo0:dedupeQ: loaded index from chapter 0 through
> chapter 10838
> [  105.326969] uds: kvdo0:dedupeQ: Replaying volume from chapter 25512
> through chapter 45991
> [  105.349210] uds: kvdo0:dedupeQ: unexpected index page map update,
> jumping from 10838 to 25512
>
On my installations stopping vdo service sometimes take 30 minutes or more.

I suspect your index is corrupted after unlcean shutdown. Check "vdo status".

Important lines are "Device mapper status", "Index status", "read-only recovery count", "recovery progress (%)"

Regards,
Łukasz