Sparse-файл NFSv4.2: одинаковые нули при чтении не означают одинаковое выделение места
Фотография конкретного исполнения не приложена.
Большой файл может содержать области без выделенных backing blocks. При чтении они выглядят как нули, но занимают место иначе, чем записанный массив нулевых байтов. Для резервирования и передачи виртуальных дисков это существенное различие.
RFC 7862 добавляет READ_PLUS для представления holes без передачи длинного повторяющегося содержимого, SEEK для поиска областей и DEALLOCATE для освобождения заданного диапазона. После hole punch чтение незаписанной области возвращает нули. Следовательно, это операция изменения файла, а не безвредный запрос статистики.
Сохранение sparse-структуры зависит от поддержки сервера, клиента и инструмента копирования. Одинаковый хеш логического содержимого не доказывает одинаковый физический расход. И наоборот, освобождение blocks не является универсальным подтверждением безопасного физического стирания предыдущих данных на накопителе.
В приёмке сравнивают логический размер, полезное содержимое и показатели выделения после согласованного копирования. Проверяют большие holes и границы диапазонов. Для политики удаления используют отдельные требования. Поддержка NFSv4.2 сама по себе не доказывает, что используемый путь действительно сохраняет sparse-структуру или выполняет sanitization носителя.
Основание — Numbered RFC8881 NFSv4.1, RFC7862 NFSv4.2, RFC8276 xattrs and RFC9289 RPC-with-TLS; applicability scoped per task, разделы RFC7862 6 Sparse Files; DEALLOCATE; READ_PLUS; SEEK. Сохранён текст публичной справочной публикации; конкретная реализация может поддерживать только часть возможностей. Основание — указанные номерные RFC NFS/RPC. Возможности NFSv4.1, NFSv4.2 и дополнительных расширений разделены; их фактическая поддержка сервером и клиентом не подтверждалась. Монтирование, чтение рабочих файлов, запись и восстановление состояния не выполнялись.
