Добавить PATCH_CLODE.txt

PATCH_CLODE.txt

@@ -0,0 +1,177 @@
+https://claude.ai/chat/f688c411-b11e-4455-918b-fde5e6577430
+
+Diagnosed replication snapshot duplication caused by version listing failures
+Diagnosed replication snapshot duplication caused by version listing failures
+
+Отличная зацепка — снапшот chunk_9XG1J8T0/nomad/ha-zah@zrepl_20260724_054520_000 реально существует (0B allocated, 195M refer — то есть данные там есть), но планировщик каждый цикл продолжает считать, что на приёмнике версий нет вообще. Значит проблема не в наличии данных, а в том, что ListFilesystemVersions (то, чем сверяется планировщик) их почему-то не видит. Погружусь в код листинга снапшотов на ресивере.
+
+Ran 3 commands, viewed 3 files
+Ran 3 commands, viewed 3 files
+
+Кажется, нашёл настоящий баг — и это очень похоже на правду. Проверю до конца, как формируется список receiverFS/IsPlaceholder, которым пользуется планировщик (не тот же код, что читает placeholder при самом receive).
+
+Viewed 5 files, ran 4 commands
+Viewed 5 files, ran 4 commands
+
+Нашёл настоящую причину, и она серьёзнее, чем казалось — это баг именно от моего патча, а не от zrepl самого по себе. Дело в сопоставлении списков sender/receiver в планировщике.
+
+Проверяю, есть ли envconst.String для строкового значения
+Проверяю, есть ли envconst.String для строкового значения
+Вот и реальный баг — и он от патча
+
+Планировщик (replication_logic.go:302-306) сопоставляет sender и receiver filesystem'ы строковым сравнением путей:
+
+go
+for _, rfs := range rfss {
+    if rfs.Path == fs.Path {   // fs.Path — путь СЕНДЕРА, напр. "hdd_9XG1J9J1/nomad/ha-zah"
+        receiverFS = rfs
+    }
+}
+
+А rfs.Path формируется в Receiver.ListFilesystems (endpoint.go:695) как a.TrimPrefix(root) — локальный путь chunk_9XG1J8T0/nomad/ha-zah минус root_fs = nomad/ha-zah.
+
+До патча это совпадало с sender-путём один-в-один (root_fs + sender_path → обрезаем root_fs → получаем обратно sender_path). А теперь, когда MapToLocal откусывает ещё и hdd_9XG1J9J1, обратная обрезка даёts nomad/ha-zah — а сендер сообщает hdd_9XG1J9J1/nomad/ha-zah. Строки не совпадают → receiverFS всегда nil → планировщик каждый раз считает, что на приёмнике версий нет → пытается full receive → ловит "destination exists". Именно поэтому цикл повторяется бесконечно.
+
+Чиню — добавляю обратное восстановление отрезанного префикса именно в отчёт ListFilesystems, чтобы сопоставление путей снова работало:
+
+Architected shared helper function to consolidate prefix-handling logic
+Architected shared helper function to consolidate prefix-handling logic
+
+Есть всё нужное. Переписываю патч целиком на литеральный строковый префикс — это устраняет и проблему с расчётом пути, и делает обратное сопоставление в ListFilesystems возможным:
+
+Reconciled edge case behavior and prepared filesystem prefix restoration
+Reconciled edge case behavior and prepared filesystem prefix restoration
+Смотрю текущее состояние MapToLocal перед переработкой
+Переключаю strip с "N компонентов" на литеральный строковый префикс, чтобы его можно было симметрично восстановить в ListFilesystems для сопоставления путей с sender'ом
+endpoint.go
++35
+-18
+
+Reconciled edge case behavior and prepared filesystem prefix restoration.
+
+Done
+
+Теперь патчу ListFilesystems, чтобы при формировании отчётного пути (используемого для сверки с sender) обрезанный префикс восстанавливался обратно:
+
+Восстанавливаю отрезанный sender-префикс в пути, который ListFilesystems возвращает планировщику — иначе receiver Path не совпадает с sender Path и планировщик считает receiver пустым на каждом цикле
+Восстанавливаю отрезанный sender-префикс в пути, который ListFilesystems возвращает планировщику — иначе receiver Path не совпадает с sender Path и планировщик считает receiver пустым на каждом цикле
+
+Проверяю синтаксис и то, что старая переменная ZREPL_STRIP_SENDER_PREFIX_COMPS больше нигде не используется:
+
+Проверяю синтаксис и итоговое использование переменных окружения
+Проверяю синтаксис и итоговое использование переменных окружения
+
+Синтаксис чистый, старой переменной нигде не осталось. Собираю (насколько позволяет toolchain в песочнице):
+
+Ran 2 commands
+Ran 2 commands
+
+Отлично, всё корректно, включая граничный случай равных путей. Патч готов. Итог:
+
+Что было не так
+
+Планировщик сопоставляет filesystem'ы sender'а и receiver'а строковым равенством путей (replication_logic.go:303: rfs.Path == fs.Path). До патча receiver.Path (локальный путь минус root_fs) всегда совпадал с sender.Path один в один. Мой первый патч ломал этот инвариант: обрезав ещё и hdd_9XG1J9J1 при записи, но не восстанавливая его при отчёте — receiver стал сообщать "nomad/ha-zah", а sender — "hdd_9XG1J9J1/nomad/ha-zah". Строки никогда не совпадали → receiverFS всегда nil → планировщик каждый цикл считал, что на приёмнике ничего нет → пытался полный recv в уже занятый датасет → ошибка. Бесконечный цикл был не багом zrepl, а прямым следствием несимметричности моего же патча.
+
+Что изменилось
+Заменил обрезку "N компонентов" на обрезку литерального строкового префикса — это делает операцию обратимой.
+В MapToLocal префикс отрезается при вычислении локального пути хранения.
+В ListFilesystems тот же префикс приклеивается обратно к пути, который сообщается планировщику — так путь снова совпадает с тем, что говорит sender, и сопоставление работает.
+Как применить
+
+Пересоберите бинарник, затем поменяйте имя переменной в systemd-юните (старое ZREPL_STRIP_SENDER_PREFIX_COMPS=1 → новое, с явным значением префикса):
+
+ini
+Environment=ZREPL_STRIP_SENDER_PREFIX=hdd_9XG1J9J1
+bash
+systemctl daemon-reload
+systemctl restart zrepl_rcv
+
+Датасеты, скорее всего, снова придётся снести (zfs destroy -r chunk_9XG1J8T0/nomad) и дать реплицироваться с нуля, раз в прошлый раз всё было в неконсистентном состоянии из-за бага. После рестарта проверьте:
+
+bash
+journalctl -u zrepl_rcv -n 100 --no-pager | grep -iE "conflict|receive failed|error"
+
+Ключевой признак, что теперь всё работает правильно: строка "conflict automatically resolved" с пустым sorted receiver versions должна появиться только один раз (при первой инициализации датасета), а не повторяться на каждом цикле после успешного приёма.
+
+а где патч?
+
+Показываю итоговый diff патча
+Показываю итоговый diff патча
+
+дай исправленные функции
+
+Показываю итоговый код исправленных функций целиком
+Показываю итоговый код исправленных функций целиком
+
+Вот три исправленные функции целиком (файл internal/endpoint/endpoint.go):
+
+1. Новая вспомогательная функция (строки 638–654):
+
+go
+// senderPrefixDatasetPath returns the configured literal sender-side prefix
+// (e.g. "hdd_9XG1J9J1") to strip from incoming filesystem paths, or nil if
+// ZREPL_STRIP_SENDER_PREFIX is unset/empty. Using a literal string (rather
+// than a component count) lets us losslessly reconstruct the sender's
+// original path later in ListFilesystems, which is required for the
+// sender/receiver filesystem-matching in the replication planner to work.
+func senderPrefixDatasetPath() *zfs.DatasetPath {
+	s := envconst.String("ZREPL_STRIP_SENDER_PREFIX", "")
+	if s == "" {
+		return nil
+	}
+	dp, err := zfs.NewDatasetPath(s)
+	if err != nil || dp.Length() == 0 {
+		return nil
+	}
+	return dp
+}
+
+2. MapToLocal (строки 656–672):
+
+go
+func (f subroot) MapToLocal(fs string) (*zfs.DatasetPath, error) {
+	p, err := zfs.NewDatasetPath(fs)
+	if err != nil {
+		return nil, err
+	}
+	if p.Length() == 0 {
+		return nil, errors.Errorf("cannot map empty filesystem")
+	}
+	// PATCH: strip a configured literal prefix (e.g. the source zpool name)
+	// from the *sender's* path before appending it under root_fs.
+	if prefix := senderPrefixDatasetPath(); prefix != nil && p.HasPrefix(prefix) {
+		p.TrimPrefix(prefix)
+	}
+	c := f.localRoot.Copy()
+	c.Extend(p)
+	return c, nil
+}
+
+3. Кусок ListFilesystems, где формируется Path (строки 712–734, остальная часть функции без изменений):
+
+go
+		a.TrimPrefix(root)
+
+		// PATCH: re-prepend the literal sender prefix that MapToLocal strips,
+		// so that the Path we report here matches what the sender reports
+		// for the same filesystem (see replication_logic.go's Path-based
+		// sender/receiver matching). Without this, the planner can never
+		// find a matching receiverFS and will treat every cycle as if the
+		// filesystem doesn't exist yet on the receiver.
+		reportPath := a.ToString()
+		if prefix := senderPrefixDatasetPath(); prefix != nil {
+			if reportPath == "" {
+				reportPath = prefix.ToString()
+			} else {
+				reportPath = prefix.ToString() + "/" + reportPath
+			}
+		}
+
+		fs := &pdu.Filesystem{
+			Path:          reportPath,
+			IsPlaceholder: ph.IsPlaceholder,
+			ResumeToken:   token,
+		}
+		fss = append(fss, fs)
+
+Больше в файле ничего не менялось — MapToLocal вызывается ещё и из Receive/ListFilesystemVersions/DestroySnapshots, но там аргументом всегда приходит исходный путь сендера (req.Filesystem), так что дополнительных правок там не требуется.