Спрайтом я называю данные собранные одним большим куском в NVRAM оптимизированным для записи на диски.
Одно дело фрагментированность вызванная процессом дедупликации.
Другое дело фрагментированность данных внутри страйпа.

Другими словами я усомнился в том, что данные внутри страйпа 100% random.
Как работает алгоритм собирания данных в страйп?

> Мне кажется, что вы здесь подменили понятие случайных данных собранных в страйп на блочную фрагментированность от процесса дедупликации.

Несколько раз прочел, но смысла так и не уловил. Перформулируйте, и пропробуйте еще раз.

Я бы хотел еще раз, специально, обратит ваще внимание, что влияние фрагментации на 100% random workload по меньшей мере не доказано.
С точки зрения теории и логики, разницы между рандомным чтением рандомно расположенных данных и рандомным чтением секвентально расположенных ланных нет никакой. В обоих случаях это чтение 100% random. рандом на рандом не дает “рандом в квадрате”, он по прежнему остается 100% рандомным.

Секвентальное же чтение это довольно специфические задачи, типа традиционного бэкапа. На этих задачах фрагментация действительно будет ухудшать показатели sequental read, но в случае NetApp задачи бэкапа обычно решаются иными путями, не требующими лить секвентальный дамп с дисков.

??сходя из поста можно сказать, что проблема решается исключительно кешем на чтение и реалокацией (которая по умолчанию выключена).

Мне кажется, что вы здесь подменили понятие случайных данных собранных в страйп на блочную фрагментированность от процесса дедупликации. ?? тут встаёт вопрос есть ли разница между тем и другим?

Вопрос сводится к тому, как работает алгоритм сбора “случайных” данных в страйп. Другими словами: насколько дынные внутри страйпа фрагментированны и является ли длинна такого фрагмента, в страйпе, постоянной, если там не 100%-й рандум?

Если алгоритм совсем тупой, то скорее всего оба понятия одно и тоже. Похоже вы к этому и клоните: производительность не падает от случайного чтения случайно разбросанных данных.

Но если алгоритм умный и понимает, что случайные блоки относятся к одной логической цепочке, то не такие уж и фрагментированные данные получаются в нашем страйпе, а следовательно выше изложенные понятия не следует мешать в кучу. Продолжая эту логику, я бы заключил, что дедупликация всё-таки сильно фрагментирует данные, в то время как они расположены не случайно, а более или менее последовательно. Соответственно должна быть деградация производительности от фрагментации вызванной дедупликацией.

Как известно падения производительности от дедупликации всё-таки нет, но мы так до конца и не понимаем почему. Было бы неплохо закрыть эту дыру.