Предполагая, что рекомендации по свободному пространству для ZEVO не будут отличаться от рекомендаций для других современных реализаций ZFS…
Вопрос
Пожалуйста, какой процент или объем свободного места рекомендуется для жестких дисков следующих размеров?
- 640 ГБ
- 2 ТБ
мысли
Стандартный ответ для современных реализаций ZFS может быть «заполнен не более чем на 96 процентов». Однако, если применить это к (скажем) однодисковому набору данных 640 ГБ, где некоторые из наиболее часто используемых файлов (по VirtualBox) имеют размер более 15 ГБ каждый, то я предполагаю, что блоки для этих файлов будут субоптимально распределены по пластинам около 26 ГБ бесплатно.
Я читал, что в большинстве случаев фрагментация и дефрагментация не должны беспокоить ZFS. Тем не менее, мне нравится мысленная картина большинства фрагментов большого .vdi в достаточно близкой близости друг к другу. (Особенности ZFS делают это желание близости слишком старомодным?)
Примечание: может возникнуть вопрос о том, как оптимизировать производительность (для массивных файлов в наборе данных с относительно небольшим свободным пространством) после того, как порог «сломан». Если это произойдет, я буду держать его отдельно.
Фон
В прошлом на StoreJet Transcend объемом 640 ГБ (код продукта 0x2329) я, вероятно, вышел за пределы рекомендуемого порога. В настоящее время самый большой файл составляет около 17 ГБ -
- и я сомневаюсь, что любой .vdi или другой файл на этом диске вырастет за пределы 40 ГБ. (Не обращайте внимания на фиолетовые массы, те пучки файлов группа 8 Мб.)
Без HFS Plus: пороговые значения в двадцать, десять и пять процентов, которые я связываю с файловой системой Mobile Time Machine, не должны применяться.
В настоящее время я использую ZEVO Community Edition 1.1.1 с Mountain Lion, OS X 10.8.2, но я бы хотел, чтобы ответы не были слишком специфичными для версии.
Список литературы, хронологический порядок
Распределение блоков ZFS (блог Джеффа Бонвика) (2006-11-04)
Космические карты (блог Джеффа Бонвика) (2007-09-13)
Удвоение производительности Exchange (странно! Vous avez dit Bizarre?) (2010-03-11)
… Таким образом, чтобы решить эту проблему, то, что пошло в выпуске программного обеспечения 2010/Q1, является многократным. Самое главное: мы увеличили порог, при котором мы переключились с «первой посадки» (быстро) на «наилучшую посылку» (плотная упаковка) с 70% до 96%. При использовании дисков TB каждая пластина занимает не менее 5 ГБ, а 4% по-прежнему занимают 200 МБ свободного места, и перед этим не нужно делать ничего радикального. Это дало нам самый большой взрыв. Во-вторых, вместо того, чтобы пытаться повторно использовать одни и те же первичные плиты до тех пор, пока они не потерпели неудачу в распределении, мы решили прекратить предоставлять первичной плите эту льготную угрозу, как только наибольшее выделение, которое могло быть удовлетворено плитой, уменьшилось до 128K (
metaslab_df_alloc_threshold
). В этот момент мы были готовы перейти на другую плиту, на которой было больше свободного места. Мы также решили уменьшить SMO бонус. Раньше плита, которая была на 50% пустой, была предпочтительнее плит, которые никогда не использовались. Чтобы увеличить агрегацию записи, мы снизили порог до 33% пустых. Это означает, что рабочая нагрузка произвольной записи теперь распространяется на большее количество блоков, где на каждой из них будет больше свободного места, что приведет к большему объему записи. Наконец, мы также увидели, что загрузка плиты способствовала снижению производительности, и реализовали механизм предварительной выборки плиты, чтобы сократить время простоя, связанное с этой операцией.Совокупность всех этих изменений приводит к 50% улучшению OLTP и 70% снижению изменчивости от запуска к запуску…
Улучшения OLTP в Sun Storage 7000 2010.Q1 (профили производительности) (2010-03-11)
Alasdair on Everything »ZFS работает очень медленно, когда использование свободного диска превышает 80% (2010-07-18), где комментарии включают в себя:
... OpenSolaris изменил это в версии 11146 onnv ...
[CFT] Улучшен код метаслаба ZFS (увеличена скорость записи) (2010-08-22)