У меня есть том в Windows Server 2016, который является целью роли дедупликации данных.
Он работает очень хорошо, коэффициент экономии ~ 60%, при этом многие файлы отображаются на диске как нулевые байты.
Том распределяется по SMB и отлично монтируется на клиентах Mac, Windows и Linux. Последние два могут использовать все файлы как обычно, но Mac - нет.
В любом файле, который выглядит как использующий нулевое дисковое пространство, Mac не знает, как их читать. Их нельзя открыть или прочитать, а копия в Finder производит Error code -36
.
На работающем клиенте копирование файла в новый, чтобы он не был дедуплицирован, позволяет Mac прочитать его, поскольку теперь он, похоже, использует дисковое пространство. Например, выполнение следующих действий в Ubuntu приведет к потере оптимизации файла: cp original_file.csv temp && mv temp original_file.csv
Это проблема, которую можно решить, или что-то не так с macOS или тем, как она реализует SMB?
Мне кажется, вы обнаружили двусмысленность в спецификации SMB. Кажется, что Finder видит файл с 0 байтами и решает, что к нему бесполезно обращаться, поскольку он пуст. Я мог легко представить себе, что делаю такой выбор при написании чего-либо в попытке «оптимизировать» код. Что-то не так с реализацией SMB в Finder? Возможно, но вам придется ОЧЕНЬ внимательно прочитать спецификации, чтобы определить это! Я бы сообщил о проблеме в Apple, так как не могу представить, что это не ошибка. Надеюсь, он попадет в список ошибок и скоро будет исправлен.
Кстати, зачем вам использовать сжатие, учитывая относительно низкие цены на хранилище сегодня?