Свежие комментарии

Где-то полгода назад брал на вторичке почти одновременно 850 pro 256GB за 100$ и PM863 480GB за 90+$. Недавно PM863а 240GB обошелся в 50+$, но вот его бы не советовал. Проверенный факт - TRIM работает значительно быстрее, про кэш пишут что не пропадёт при аварийном завершении, есть хорошая документация. Не уверен, что современная 860 серия лучше 850, а 863а лучше 863.

Media wearout indicator должен начинаться с 100, сейчас там 90. Ну то есть еще 40 лет простоит, так что ли?

Вот кстати iostat -x, на сервере с аптаймом 4 года без копеек:
$ iostat -x
extended device statistics
device r/s w/s kr/s kw/s qlen svc_t %b
ada0 0.1 9.6 4.7 318.5 0 11.3 0
ada1 0.1 9.6 4.7 318.5 0 11.4 0
ada2 0.1 9.6 4.2 318.5 0 11.5 0

320 килобайт/сек, верно? Это гигабайт в час. Откуда что берется.....

Чему то верить нужно :-). Или проверять если возможно. Например uptime и iostat -Ixd.

При нынешней цене на овес - зачем брать на вторичке?

UPD: я, правда, тут купил два. Но с известной историей и у знакомого.

Ну может они и были, не вопрос, вопрос в том — где их вообще брать. «на вторичке» — ну вот я посмотрел очевидную вторичку, нету.
А такое точно надо брать с возможностью вернуть (т.е. не на Е-бее из Китая).

240MB тоже были.

Но если брать серверные, то наверное не с хз какой историей.

А что с ssd может случится? Смотрим смарт и вперёд. Лучше наверно почти всем, кроме цены :-).

SM863 - 0 предложения на Avito
PM863 - 2 предложения, за 45 и 39 тысяч рублей.

У меня везде ZFS :-)

А что такое 863 серия и лучше ли она 860 EVO чем-то?

Сегодня нужно было подойти к линейке. Попробовал заодно освежить память по поводу primarycache=metadata. Пул из четырёх дисков (страйп из двух зеркал). Взял файл с recordsize=128k.
dd if=/data/test/test_32g_128k of=/dev/zero bs=128k
34359738368 bytes transferred in 180.599959 secs (190253301 bytes/sec)
Префетч не работает, получаем прогнозируемую скорость для единичной очереди.
Чтение этого файла по сети эксплорером 300+MB/s, gstat показывает, что суммарная очередь на чтение иногда доходит до 8.
Создал файл с recordsize=1M.
dd if=/data/test/test_32g_1M of=/dev/zero bs=128k
34359738368 bytes transferred in 1284.648935 secs (26746403 bytes/sec)
Хорошо видно, как резко падает скорость, если читаем данные мимо арка и блоками меньше чем размер recordsize.
dd if=/data/test/test_32g_1M of=/dev/zero bs=1M
34359738368 bytes transferred in 162.679963 secs (211210636 bytes/sec)
Так ближе к норме.
Чтение эксплорером 130+MB/s, gstat показывает суммарное чтение с дисков около 180MB/s.
Эксплорер опять "химичит", но это уже не спасает.

Я сам в шоке и не понимаю. Это сервер. Который я апдейчу раз в пол-года. Это не экспериментальная машина, где я могу пересобрать мир 3 раза в сутки. Там живёт, ну, система. Даже home dirs живут на RAID. Зеркало FreeBSD'шного SVN'а живёт на RAID. Всё живёт на RAID.

Ага, про 250 я уже увидел, как раз в каталоги полез сразу как коммент написал.

Посмотрел на системно-FreeBSD'шные диски.

Системный диск в сервере. 750 EVO 120GB. Total_LBAs_Written=320388418901. Везде пишут, что это сектора. Это тогдп 149 терабайт. Я не понимаю — КАК? И это в 5 раз превышает гарантийный ресурс. Но оно ещё жалуется, что, да, скоро кончится:

177 Wear_Leveling_Count 0x0013 001 001 000 Pre-fail Always - 1412

Пишут, что тут raw value — это перезаписи, а просто значения — проценты здоровья, осталось 1%. Кстати, 1412 перезаписей — это должно быть 120*1412/1024 = 165 терабайт. Ну, плюс-минус сходится с LBA_Written. Но всё равно остаются вопросы что происходит с системным ZFS'ом у FreeBSD.

А вот 850 EVO 250GB который был недогруженным L2ARC'ом, болтался без дела, и вообще не помню как я его покупал, и сейчас — системный диск у новой тестовой машинки (и страшно не любит TRIM, чуть не вешая систему от них):

177 Wear_Leveling_Count 0x0013 086 086 000 Pre-fail Always - 296
241 Total_LBAs_Written 0x0032 099 099 000 Old_age Always - 61392263871

Вроде как и жив ещё, но записано 28.59TB. Что как-то мало соответствует 296 перезаписям (втрое меньше). Но, повторю, TRIM пришлось запретить или на buildworld система колом вставала. И это косвенно подтверждается комментариями в ядре Линукса.

А вот десктопный 850 PRO, 512.

B1 _98 _98 __0 000000000025 Wear Leveling Count
F1 _99 _99 __0 000A099D2413 Total LBAs Written

Это у нас 37 перезаписей (18.5TB?) и 43110966291 LBAs = ~20TB, похоже.

И, кажется, пора в магазин. За чем-нибудь на 120GB. А то сервер в любой момент без системного диска остаться может.

vfs.zfs.arc_meta_limit определяет максимальный размер метаданных в арке. К сожалению "за нас решили" какой порядок вытеснения записей в арке и он всё таки умудряется вытеснять метаданные даже если их меньше лимита. Но можно закомментировать "ненужное". Я оставил вытеснение метаданных только в случае превышения лимита и при сигнале системы, что мало памяти.