Dmitry
1863Гб
Nikolay
Я где-то затупил походу
Mikhail
Заказал два таких: 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
Mikhail
обновленная прошивка вроде доступна
Mikhail
Не могу найти офиц pdf с деталями от intel
Mikhail
но ошибку вроде видели на всех дисках. беда в том что на этом сильно погорели, когда в один прекрасный день все ceph-ы сказали БУ. Там были и по терабайту и по 4
ivdok
> We recommend that you update to the latest firmware before the drive reaches 1,700 cumulative idle power-on hours. Я помню, как HPE жарили за 32,768 часов MTBF, а тут рекорд
Nikolay
обновленная прошивка вроде доступна
баг на xcv10100 у меня 10120 Отлегло от сердца :)
tmf
per dataset такого нет сейчас
а per zvol? а в zfs2 планируется тротлить по dataset/zvol?
Mikhail
баг на xcv10100 у меня 10120 Отлегло от сердца :)
я могу ошибаться, но баг всё же железный, не в прошивке. В прошивке они сначала отключали сборщик мусора, который дедлочил, а потом вроде сделали какое-то ограничение. Я правда понимаю что во всех SSD есть свои костыли связанные с сборкой мусора, от этого никуда не убежишь. Но с другой стороны, диски уже обкатанные, везде используются, может быть даже не плохо на них подсесть )
ivdok
В который раз убеждаюсь, что сосунг - топ за свои деньги
George
а per zvol? а в zfs2 планируется тротлить по dataset/zvol?
сейчас не видел активных проектов по троттлингу. Года 4 назад был PR, но заглох
tmf
сейчас не видел активных проектов по троттлингу. Года 4 назад был PR, но заглох
да, старые реквесты тоже видел, вроде там свелось всё к возможности реализации только через cgroups-v2, а пока что его не так много
Vladislav
https://habr.com/ru/post/523054/
ivdok
https://habr.com/ru/post/523054/
Лютый баян. https://hackaday.com/2013/08/02/sprite_tm-ohm2013-talk-hacking-hard-drive-controller-chips/
ivdok
Начиная с http://spritesmods.com/?art=hddhack&page=2
Vladislav
в заголовке написан чей перевод
ivdok
в заголовке написан чей перевод
Ресь не про авторство, а про баян. Все, то хотел - много лет как перевели и прочитали
Roman
Привет. Может у кого есть опыт для следующей ситуации: Имеется 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 с цепхом?
Roman
Количество файлов будет расти
Ivan
кмк сжатие мп3 - бесполезное занятие
Roman
А что и зачем хотите крутить то?
Просто раздавать файло через nginx
George
В курсе
Гуд. Если файлы сильно мелкие будут (4-8кб), то raidz накладные расходы по месту большие даст, тоже учтите
George
А так, если вам хватает перформанса с gzip сжатием и дедупликацией на raidz, то не думаю что стоит что-то трогать)
Ivan
мне кажется на сколь-нибудь вменяемом наплыве посетителей всё встанет
George
Захочется побыстрее - lz4 без дедупликации на миррорах, + special vdev
George
Статику можно кешировать нгинксом ещё спереди без проблем
Ivan
Если озу не жалеть, то с прогретым арк всё ок
это если все будут за примерно одним и тем же заходить. в таких вещах не стоит полагаться на кэш. он должен помогать, но так же ресурсов должно хватать на тот случай, если кэш справляться не будет.
Roman
ОЗУ не жалко и если нужно будет - докупим. Плюсом идут ссд в кэш, пока 600 Гб. По нагрузке - сейчас на него сливается с 5 серваков по нфс непрерывно файлики в несколько потоков с каждого, никаких затупов на запись и отдачу
Roman
кмк сжатие мп3 - бесполезное занятие
Сжатие сжимает 0 в recordsize, вроде как
George
Если чисто для этого - стоит включить lz4
George
Он сильно дешевле по процу, нули жмёт также эффективно
George
И умеет рано выходить на несжимаемых данных
Ivan
И умеет рано выходить на несжимаемых данных
А как это определяется ? Допустим recordsize 1m, половина несжимаемые данные, остальное 0, то нули подожмутся в итоге или нет ?
Roman
Пока включил lz4, нагрузка чуть упала. Через пару Тб гляну на уровень сжатия
Алексей
кмк сжатие мп3 - бесполезное занятие
Полезное, будет обрезать остаток блока
Алексей
Но гзип согласен лишний
Олег
В deb дистрибах какой iSCSI таргет используете? Что менее геморойно и наиболее быстро?
Alexandr
tgt
Олег
tgt
У него вроде со скоростью все плохо?
Alexandr
какраз нооборот
Олег
scst думал собрать поверх zfs
Ivan
юху ! в sid завезли 0.8.5
Nikolay
sid ?
Ivan
в дебиане есть stable/testing/sid/experimental репы
Fedor
Читаю тут, читаю..
Fedor
Fedor
Что думаете на данный счёт?
Fedor
https://www.reddit.com/r/zfs/comments/ayqw1r/zfs_heavy_write_amplification_due_to_free_space/?utm_source=amp&utm_medium=&utm_content=comments_view_all
Олег
ovios никто не пробовал-слышал?
George
Всё так, в общем то
Алексей
Это печально
George
Для синхронной записи, конечно же
George
Ну потому по дефолту там и latency)
Fedor
Понял :) если не летенси, хорошо б весь пул перезалить?)
Fedor
Вообще вопрос в том, что амплификейшн действительно очень большой у меня
Fedor
Копаю вот
George
Понял :) если не летенси, хорошо б весь пул перезалить?)
Ну если нормально места держали свободного, то хватит переключить на латенси, если менять хочется
Fedor
Места 50%
Fedor
И чтение хотелось бы вернуть
Fedor
Кстати, префетч на зволах по этой же причине может работать неэффективно?
Fedor
Потому что было записано не через летенси
Fedor
Линейно читал звол, префетч вообще не шелохнулся процентно
George
Кстати, префетч на зволах по этой же причине может работать неэффективно?
Со зволами отдельная песня обычно, на память не скажу даже
Fedor
Понял.