Hi,
在 2025/06/30 9:59, Xiao Ni 写道:
After reading other patches, I want to check if I understand right.
The first write sets the bitmap bit. The second write which hits the
same block (one sector, 512 bits) will call llbitmap_infect_dirty_bits
to set all other bits. Then the third write doesn't need to set bitmap
bits. If I'm right, the comments above should say only the first two
writes have additional overhead?
Yes, for the same bit, it's twice; For different bit in the same block,
it's third, by infect all bits in the block in the second.
For Reload action, if the bitmap bit is
NeedSync, the changed status will be x. It can't trigger resync/recovery.
This is not expected, see llbitmap_state_machine(), if old or new state
is need_sync, it will trigger a resync.
c = llbitmap_read(llbitmap, start);
if (c == BitNeedSync)
need_resync = true;
-> for RELOAD case, need_resync is still set.
state = state_machine[c][action];
if (state == BitNone)
continue
if (state == BitNeedSync)
need_resync = true;
For example:
cat /sys/block/md127/md/llbitmap/bits
unwritten 3480
clean 2
dirty 0
need sync 510
It doesn't do resync after aseembling the array. Does it need to modify
the changed status from x to NeedSync?
Can you explain in detail how to reporduce this? Aseembling in my VM is
fine.
Thanks,
Kuai
