mirror of
https://github.com/seaweedfs/seaweedfs.git
synced 2026-08-16 04:06:44 +00:00
Chris LuandGitHub
2a513e71a4
The existing multi-disk EC integration test asserts on shard counts. Counting cannot tell a healthy volume from one a repair reassembled out of the wrong inputs — both have fourteen shards. This drives the real shell commands (ec.encode, ec.balance, ec.rebuild) against a live three-node, four-disk cluster and reads the stored bytes back after every step, so a rebuild that produced fourteen plausible-but-wrong shards fails here. An 8 KB random payload is stored, then encoded, balanced, damaged (two shard files removed and the servers restarted so the master relearns the reduced set from disk), and rebuilt. The rebuild output matches the shape of the support case that motivated this — "rebuildOneEcVolume", "missing shard N.0", "copied N.1 from ..." — and the payload is verified identical after each of upload, encode, balance, shard loss, and rebuild. Two ordering facts the test pins, both of which cost real debugging time: ec.rebuild is driven by the master's topology, not disk truth, so shards must be relearned (via restart) before a repair can target the right set; and the shell lock is dropped when the restart disconnects the master, so it has to be retaken before the rebuild.