bneradt commented on code in PR #13608:
URL: https://github.com/apache/trafficserver/pull/13608#discussion_r3993266406
##########
src/iocore/cache/CacheDir.cc:
##########
@@ -683,21 +669,17 @@ Directory::remove(const CacheKey *key, StripeSM *stripe,
Dir *del)
int b = key->slice32(1) % this->buckets;
Dir *seg = this->get_segment(s);
Dir *e = nullptr, *p = nullptr;
-#ifdef LOOP_CHECK_MODE
- int loop_count = 0;
-#endif
CHECK_DIR(vol);
e = dir_bucket(b, seg);
if (dir_offset(e)) {
+ int loop_count = 0;
do {
-#ifdef LOOP_CHECK_MODE
- loop_count++;
- if (loop_count > DIR_LOOP_THRESHOLD) {
- if (this->bucket_loop_fix(dir_bucket(b, seg), s))
- return 0;
+ // Past the longest legitimate chain, so this is provably a cycle.
+ if (++loop_count > this->max_bucket_depth()) {
+ this->bucket_loop_fix(dir_bucket(b, seg), s);
Review Comment:
[P2] Mark the directory dirty when repairing a cycle
If `header->dirty` is 0 when this path runs, `bucket_loop_fix()` clears the
segment through `init_segment()`, but neither helper sets the dirty flag, and
this return bypasses `delete_entry()` (which normally sets it). The new
`overwrite(..., must_overwrite=true)` repair path has the same problem: after
resetting the segment it retries and returns 0 before `Lfill`.
`CacheSync::mainEvent()` skips directories whose dirty flag is clear, so
without a subsequent mutation the repair is never periodically persisted; an
already-persisted corrupt chain can return after a crash. Please mark
successful repairs dirty, preferably in the shared repair helper, and cover
these paths starting with `header->dirty = 0`.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
