mirror of
https://github.com/seaweedfs/seaweedfs.git
synced 2026-11-03 18:47:41 +01:00
Chris LuandClaude Opus 5.5
8461ae2fe9
* filer.sync: a chunk the live source entry dropped is gone whatever its mtime says sourceDroppedChunk refused to judge a 404'd chunk when the live source entry carried an older mtime than the replayed version, treating that as a rollback. Timestamp-preserving writers (cp -p, rsync -a, tar extracts) produce exactly that order on every rewrite, so the vacuumed chunk sat in the retry loop for the full missingSourceChunkGrace before being written off. Whether the live entry still lists the chunk is independent of mtime order. * filer.sync: treat a rewritten source entry as moved on regardless of its mtime sourceVersion only compared chunk sets when the live entry was at least as new as the replayed one, so a live entry stamped with an older mtime but holding different chunks was never recognized as the current version. The sink then fetched the replayed chunks, hit 404 on each vacuumed one, and the same mtime guard in onReplicateChunkError kept the event from being skipped. Whether the source rewrote the file is a chunk-set question, not an mtime one; the live version is synced in its place as before. * filer.sync: apply a substituted live snapshot even under a newer destination mtime After sourceVersion swapped in the live entry, UpdateEntry re-ran chooseUpdateAction on it and a destination whose mtime was above the live entry's read as a late update, so the current source content was never written. The live snapshot is the source's current state, not a replay, so mtime order says nothing about it; repair from it unless the destination already holds it. * filer.sync: a live entry committed before the replay does not supersede it Dropping the mtime guard let any chunk-set difference read as a rewrite, including a live lookup that lags the event: a peer filer's event reaches subscribers before the local store applies it, so the lookup can still return the version the replay replaces. sourceVersion then synced that older version over the destination and consumed the event. The meta-log commit stamps order the two versions where mtime cannot, so a live entry committed before the replay proves nothing. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> * filer.sync: check commit order before the mtime supersession A lagging live entry can carry a newer mtime than the replay, as when the replayed version was stamped back to an older time, so sourceSupersedes took it as newer and the older version was synced in place of the replay. Rule out a live entry committed before the replay first. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> --------- Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com>