On Thu, Dec 5, 2024 at 7:42 PM Ming-Hung Tsai <mtsai@xxxxxxxxxx> wrote: > > This bug affects cache resizing in v2 metadata and could lead to data > loss if the fast device is shrunk during the first-time resume. For > example: > > 1. create a cache metadata consists of 32768 blocks, with a dirty block > assigned to the second bitmap block. cache_restore v1.0 is required. > > cat <<EOF >> cmeta.xml > <superblock uuid="" block_size="64" nr_cache_blocks="32768" \ > policy="smq" hint_width="4"> > <mappings> > <mapping cache_block="32767" origin_block="0" dirty="true"/> > </mappings> > </superblock> > EOF > dmsetup create cmeta --table "0 8192 linear /dev/sdc 0" > cache_restore -i cmeta.xml -o /dev/mapper/cmeta --metadata-version=2 > > 2. bring up the cache while attempt to discard all the blocks belonging > to the second bitmap block (block# 32576 to 32767). The last command > is expected to fail, but it actually succeeds. > > dmsetup create cdata --table "0 2084864 linear /dev/sdc 8192" > dmsetup create corig --table "0 65536 linear /dev/sdc 2105344" > dmsetup create cache --table "0 65536 cache /dev/mapper/cmeta \ > /dev/mapper/cdata /dev/mapper/corig 64 2 metadata2 writeback smq \ > 2 migration_threshold 0" > In addition to the reproducer described above, the patch can be verified using the "array_cursor/skip" tests in dm-unit: dm-unit run /pdata/array_cursor/skip/ --kernel-dir <KERNEL_DIR>
