Заказал два таких: https://www.dns-shop.ru/product/b0bf621ab9833330/960-gb-ssd-nakopitel-intel-d3-s4510-series-ssdsc2kb960g801/

уверен что вы в курсе, но на всякий случай https://support.microsoft.com/en-us/help/4499612/intel-ssd-drives-unresponsive-after-1700-idle-hours

но ошибку вроде видели на всех дисках. беда в том что на этом сильно погорели, когда в один прекрасный день все ceph-ы сказали БУ. Там были и по терабайту и по 4

но ошибку вроде видели на всех дисках. беда в том что на этом сильно погорели, когда в один прекрасный день все ceph-ы сказали БУ. Там были и по терабайту и по 4

обновленная прошивка вроде доступна

per dataset такого нет сейчас

баг на xcv10100 у меня 10120 Отлегло от сердца :)

я могу ошибаться, но баг всё же железный, не в прошивке. В прошивке они сначала отключали сборщик мусора, который дедлочил, а потом вроде сделали какое-то ограничение. Я правда понимаю что во всех SSD есть свои костыли связанные с сборкой мусора, от этого никуда не убежишь. Но с другой стороны, диски уже обкатанные, везде используются, может быть даже не плохо на них подсесть )

В той же статье написано что "This is a hardware issue" но так же что некоторые модели это не затрагивает - Known hardware that is not affected: Hardware based on the Intel SSD D3-S4510 and Intel SSD D3-S4610 series drives in the 240 GB, 480 GB, and 960 GB capacities.

а per zvol? а в zfs2 планируется тротлить по dataset/zvol?

сейчас не видел активных проектов по троттлингу. Года 4 назад был PR, но заглох

https://habr.com/ru/post/523054/

в заголовке написан чей перевод

Привет. Может у кого есть опыт для следующей ситуации: Имеется raidz2 на 12х8Тб хдд. Используется для хранения аудио в мп3. Файлы мелкие, 70% < 64 Кб. Сейчас их там уже ~400 000 000 (примерно на 3.5 Тб) и это я ещё не распаковал 15 Тб архивов таких же. Разбиты по директориям случайным образом, от 100 до 20 000 000 (это, что я точно видел), всего директорий 52600 Сжатие gzip включено (показывает 1.8), recordsize поставил 64, дедупликация (1.15), на всякий случай кэши на ссд (суммарно на 600 Гб) Вопрос - насколько всё плохо, что ещё можно "подкрутить" (жалоб на производительность нет, всё отлично) или может это всё разобрать и перейти на S3 с цепхом?

Привет. Может у кого есть опыт для следующей ситуации: Имеется raidz2 на 12х8Тб хдд. Используется для хранения аудио в мп3. Файлы мелкие, 70% < 64 Кб. Сейчас их там уже ~400 000 000 (примерно на 3.5 Тб) и это я ещё не распаковал 15 Тб архивов таких же. Разбиты по директориям случайным образом, от 100 до 20 000 000 (это, что я точно видел), всего директорий 52600 Сжатие gzip включено (показывает 1.8), recordsize поставил 64, дедупликация (1.15), на всякий случай кэши на ссд (суммарно на 600 Гб) Вопрос - насколько всё плохо, что ещё можно "подкрутить" (жалоб на производительность нет, всё отлично) или может это всё разобрать и перейти на S3 с цепхом?

А что и зачем хотите крутить то?

Вы же знаете про требования дедупликации в зфс к озу?

В курсе

мне кажется на сколь-нибудь вменяемом наплыве посетителей всё встанет

Если озу не жалеть, то с прогретым арк всё ок

Привет. Может у кого есть опыт для следующей ситуации: Имеется raidz2 на 12х8Тб хдд. Используется для хранения аудио в мп3. Файлы мелкие, 70% < 64 Кб. Сейчас их там уже ~400 000 000 (примерно на 3.5 Тб) и это я ещё не распаковал 15 Тб архивов таких же. Разбиты по директориям случайным образом, от 100 до 20 000 000 (это, что я точно видел), всего директорий 52600 Сжатие gzip включено (показывает 1.8), recordsize поставил 64, дедупликация (1.15), на всякий случай кэши на ссд (суммарно на 600 Гб) Вопрос - насколько всё плохо, что ещё можно "подкрутить" (жалоб на производительность нет, всё отлично) или может это всё разобрать и перейти на S3 с цепхом?

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

ОЗУ не жалко и если нужно будет - докупим. Плюсом идут ссд в кэш, пока 600 Гб. По нагрузке - сейчас на него сливается с 5 серваков по нфс непрерывно файлики в несколько потоков с каждого, никаких затупов на запись и отдачу

кмк сжатие мп3 - бесполезное занятие

Сжатие сжимает 0 в recordsize, вроде как

И умеет рано выходить на несжимаемых данных

А как это определяется ? Допустим recordsize 1m, половина несжимаемые данные, остальное 0, то нули подожмутся в итоге или нет ?

А как это определяется ? Допустим recordsize 1m, половина несжимаемые данные, остальное 0, то нули подожмутся в итоге или нет ?

кмк сжатие мп3 - бесполезное занятие

tgt

Понял :) если не летенси, хорошо б весь пул перезалить?)

Кстати, префетч на зволах по этой же причине может работать неэффективно?