Re: [PATCH 00/23] md/llbitmap: md/md-llbitmap: introduce a new lockless bitmap

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi,

在 2025/06/30 11:25, Xiao Ni 写道:
On Mon, Jun 30, 2025 at 10:34 AM Yu Kuai <yukuai1@xxxxxxxxxxxxxxx> wrote:

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 different bits in the same block, test_and_set_bit(bit,
pctl->dirty) should be true too, right? So it infects other bits when
second write hits the same block too.

The dirty will be cleared after bitmap_unplug.

[946761.035079] llbitmap_set_page_dirty:390 page[0] offset 2024, block 3
[946761.035430] llbitmap_state_machine:646 delay raid456 initial recovery
[946761.035802] llbitmap_state_machine:652 bit 1001 state from 0 to 3
[946761.036498] llbitmap_set_page_dirty:390 page[0] offset 2025, block 3
[946761.036856] llbitmap_set_page_dirty:403 call llbitmap_infect_dirty_bits

As the debug logs show, different bits in the same block, the second
write (offset 2025) infects other bits.


   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 bitmap bit is BitNeedSync,
state_machine[BitNeedSync][BitmapActionReload] returns BitNone, so if
(state == BitNone) is true, it can't set MD_RECOVERY_NEEDED and it
can't start sync after assembling the array.

You missed what I said above that llbitmap_read() will trigger resync as
well.

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.

I added many debug logs, so the sync request runs slowly. The test I do:
mdadm -CR /dev/md0 -l5 -n3 /dev/loop[0-2] --bitmap=lockless -x 1 /dev/loop3
dd if=/dev/zero of=/dev/md0 bs=1M count=1 seek=500 oflag=direct
mdadm --stop /dev/md0 (the sync thread finishes the region that two
bitmap bits represent, so you can see llbitmap/bits has 510 bits (need
sync))
mdadm -As

I don't quite understand, in my case, mdadm -As works fine.

Regards
Xiao

Thanks,
Kuai




.






[Index of Archives]     [Linux RAID Wiki]     [ATA RAID]     [Linux SCSI Target Infrastructure]     [Linux Block]     [Linux IDE]     [Linux SCSI]     [Linux Hams]     [Device Mapper]     [Device Mapper Cryptographics]     [Kernel]     [Linux Admin]     [Linux Net]     [GFS]     [RPM]     [git]     [Yosemite Forum]


  Powered by Linux