Теперь я столкнулся с этой проблемой с 3 разными поставщиками хранилищ, использующими 3 разных адаптера CNA (хотя и все FCoE), поэтому я почти уверен, что эта проблема не изолирована от конкретного поставщика хранилища (см. На HP 3PAR, EMC VNX и HDS. G1000 ().
Когда мы добавляем тонкий проверенный LUN к хосту (подключен через FCoE, установлен MPIO) и быстро форматируем LUN (NTFS), для завершения форматирования требуется до 30 минут. Я нашел другие темы, в которых упоминается эта проблема, но пока я еще не нашел решения / объяснения. Пока что нам просто пришлось с этим жить, но, должен сказать, это довольно раздражает. Кажется, это не связано с размером LUN - 100 ГБ или 2 ТБ, для БЫСТРОГО форматирования диска все равно требуется 20-30 минут! Это больше похоже на формат SLOW в моей книге.
Кто-нибудь еще видит это / есть объяснение? Я видел это до сих пор на Windows Server 2012 (R2) - не тестировался на 2008 (R2).
Я наконец нашел время, чтобы разобраться в этой проблеме - и мои первоначальные подозрения оказались верными: это связано с TRIM / UNMAP, который по умолчанию включен в Server 2012 (R2).
Я попытался подключить к хосту новый SAN LUN емкостью 2 ТБ и выдал команду:
Набор поведения fsutil DisableDeleteNotify 1
Я не уверен, что оставлять TRIM отключенным - хорошая идея, поэтому сейчас я включу его снова, после того как я отформатировал все свои LUNS.
Установлено поведение fsutil DisableDeleteNotify 0
Немного подумав: я помню один сценарий, в котором нам пришлось полностью отключить TRIM и на физической машине: сервер консолидации журналов. Несжатые журналы были перемещены на этот компьютер (с подключенным LUN SAN с тонким предоставлением). Затем журналы были сжаты. Производительность на диске была ужасной во время сжатия - пока мы не отключили TRIM.
Кажется, что-то не так во взаимодействии между Windows Server и SAN. Понятно, что Windows знает, что SAN vol поддерживает обрезку (потому что мы не видим этой проблемы в нашей старой SAN, которая НЕ поддерживает обрезку).
У меня возникла аналогичная проблема с логическими томами с тонкой подготовкой и файловой системой XFS.
По сути, проблема была связана с тем, как XFS распределяет свои метаданные: он записывает одни метаданные, затем ищет вперед, затем выделяет другие метаданные и так далее. Поскольку каждое выделение метаданных запускает базовый тонкий том для выделения другой группы блоков данных, процесс становится довольно медленным.
Я думаю, ваш сценарий очень похож на этот, даже если вы используете NTFS.