On 14.01.25 9:00, Pavel Tikhomirov wrote:
Should not we bring back the ploop_cluster_is_in_top_delta hunk too? As
this patch looks like a revert to "[RFC PATCH vz9 v6 23/62] dm-ploop:
make new allocations immediately visible in BAT".
Yes, it is kind of backing off the changes.
ploop_cluster_is_in_top_delta was completely removed, can not bring it
back at this point. But at the places it was removed a simplified check
is performed.
Here we have successful or failed bat update, a new allocation.
Either publish the update or revert allocataion in the bitmap.
So ploop_cluster_is_in_top_delta must always fail here.
May be Andrey can elaborate on this.
On 12/6/24 05:56, Alexander Atanasov wrote:
diff --git a/drivers/md/dm-ploop-map.c b/drivers/md/dm-ploop-map.c
index c88359677ea4..6e4d6f862135 100644
--- a/drivers/md/dm-ploop-map.c
+++ b/drivers/md/dm-ploop-map.c
@@ -817,9 +817,10 @@ static void
ploop_advance_local_after_bat_wb(struct ploop *ploop,
/* holes bit map requires bat_lock */
spin_lock_irqsave(&ploop->bat_lock, flags);
spin_lock(&md->md_lock);
+#ifdef PLOOP_DELAYWB
if (piwb->type == PIWB_TYPE_ALLOC)
goto skip_apply;
-
+#endif
for (; i < last; i++) {
if (piwb->type == PIWB_TYPE_DISCARD) {
ploop_piwb_discard_completed(ploop, success, i + off,
dst_clu[i]);
@@ -836,7 +837,9 @@ static void
ploop_advance_local_after_bat_wb(struct ploop *ploop,
ploop_hole_set_bit(i + off, ploop);
}
}
+#ifdef PLOOP_DELAYWB
skip_apply:
+#endif
WARN_ON_ONCE(!test_bit(MD_WRITEBACK, &md->status));
clear_bit(MD_WRITEBACK, &md->status);
--
Regards,
Alexander Atanasov
_______________________________________________
Devel mailing list
Devel@openvz.org
https://lists.openvz.org/mailman/listinfo/devel
