SSD диски и вообще flash

Пишут, дескать 10-20 процентов от ноутбуков, проданных с SSD-дисками возвращаются 'because of technical failure' (для ноутов с обычными дисками 1-2%).

Удивительно это слышать, конечно, ибо по стораджу для цифровых камер мои ощущения строго обратные - штука если не абсолютно надежная, то очень надежная (плюс-минус износ контактов и физическое разрушение, конечно). Но задумался, благо обе мои фотокамеры умеют писать бэкапы, а SDHC стоят примерно столько же, сколько CF.

Comments

Так флешка в камере работает совсем не в том режиме, что в ноуте - если там своп идет регулярный, к примеру (или ntfs с неотключенной фиксацией времени последнего обращения к файлу).

Ну да, наверное.

Но с другой стороны, блоки же постоянно гуляют, именно чтобы не износилось одно место и время работы в годы было бы разумно ожидать, нет ?

Просто от фонаря прикидывая:
- блок пусть 256к (я не знаю сколько на самом деле), на 32-гиговый диск их соответственно 100 тысяч (10^5)
- каждый блок выдерживает пусть те же 10^5 записей. За счет ремэппинга, они будут размазаны равномерно по всем блокам.

ну пусть 10 tps sustained, это 10^6 в сутки. Должно лет на 30 хватать.

Да не факт, операций записи-то тоже набегает прилично: своп, временные файлы броузеров, запись времени обращения к файлам (а это ведь и всякие системные библиотеки, шрифты и т.п.), протоколы системных событий, логи антивирусов.

Ну у меня на сервере, который что-то таки делает (собственно, черный квадрат сейчас качает) ну типа 15 записей в секунду.

На домашней XP поставил Performance monitor, посчитаю средниее writes/sec за часок - напишу.

Но я не ошибся больше чем на порядок (ибо для ноутбучного диска сотня транзакций в секунду - много) и при этом умножил еще на 3 (24 часа в сутки а не 8)

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

Ну даже при довольно интенсивной работе в фотошопе - усредненное за несколько минут writes/sec около 30-35. И это блоки короткие, длинными блоками естественно меньше.

При наборе текста - около нуля

Ага, а вот я ткнул кнопку Send/Receive в аутлуке и получил в пике три сотни. При простом серфинге порядка 20-30. Ну и со свопом ведь работы никакой не шло, и фонового антивируса я не держу. Хотя средняя сотня наверное потолок, да.

В пике, да на быстром диске я и 3000 вижу. А sustained - откуда взяться столькому ?

Ты какой параметр мониторишь ? Я - PhysicalDisk\\Total Disk writes/sec
Файловая система - NTFS

В висте у меня это называется Physical Disk\\Disk Writes/sec\\Total.
В режиме побродить по вебу, регулярно позабирать почту Average вокруг десятки крутился.
Сборка проекта в VS утащила под 70, хотя это, конечно, нетипичная активность.

Ну да. Около десятки. 300 тысяч в рабочий день.

Мне в основной блог налили ссылку на даташит - 5000 полных перезаписей SSD-диска. Небогато...
http://blog.lexa.ru/2008/03/18/pishut_deskat__1020_procentov_ot.html#com...
(там и обсуждение)

Нда, как-то совсем скромненько.

Там же указали, что у диска на другой технологии - в 20 раз больше.

Ваш SATA диск при всем желании 100 IOPS сделать неспособен.

Почему это ?
Если все локально и не требует full stroke seek (да еще и часть на одной дорожке) - очень даже способен.

Типичные показания iostat на одном SATA 7200 при интенсивной записи - порядка 250-300.

Я просто говорю о том, что ни один SATA-диск физически не способен выдать что-то больше 70-90 IOPS. Если посмотреть какую-нибудь доку для рассчета дисковой подсистемы в тот же Exchenge, то вы увидите, что 300 IOPS не дает даже SCS/FC диск на 15000rpm.

Тут дело в кэше.

Да ладно, "не может".

Вот консумерские диски, где IOPS-ы в терминах IOmeter
http://www.storagereview.com/ST3750640NS.sr?page=0%2C4
Вполне себе 150 IOPS на вполне консумерском WD-шном 500-ке.

А вот другая метода, где считаются те же IO per second, но не специальным образом размазанные по диску, а в реальности (когда данные одного приложения лежат рядом)
http://www.storagereview.com/ST3750640NS.sr?page=0%2C3
740 этих самых IO у хитачевского 500-ка.

70-80 в секунду - это worst case scenario, когда за каждым данным делаем random seek и еще ждем полоборота. Но так в реальной жизни бывает очень не всегда, как правило доступ локален (может быть с несколькими точками локальности, если несколько приложений) и переупорядочение запросов в контроллере или в драйвере - очень спасает.

Потом, я PerfMon-у доверяю. Если он сказал что в пике было 3000 (на моем stripe из 5 SATA 10k rpm) - значит примерно так и было, моей картине мира оно не противоречит.

ОК, пускай в терминах иометер IOPSов сотни, тогда почему рассчетный показатель IOPS при проектировании RAID-подсистемы по рекомендациям вендоров даже для SCSI/15K НЕ ПРЕВЫШАЕТ 300IOPS?

вы сами свой винт тестировали свой диск с помощью IOMeter? Попробуйте, очень удивитесь. И про кэш не забываем, не забываем... 740 IOPS это вообще маразм.

<i>740 IOPS это вообще маразм</i>

Надо начинать с определений. Что, по вашему, эти самые IO ? Любые ? Или только с full-stroke seek, а прочие за мясо не считаем ? А если любые, то что вы привязались к реальным измерениям на реальных нагрузках ? Данные по шине бегают, почему бы им 740 транзакций в секунду то не сделать, если все локально ?

Кстати о кэше.

Вот берем и 128-килобайтными блоками фигачим линейную запись.
Мегабайт 80 в секунду мы получим влегкую (на внешних дорожках).

Это ~640 IOPS-ов

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

Нет, ну зачем же так (:
Вы сэмулируйте хоть что-то похожее на реальность - сделайте 2-3 worker в IOmeter и проведите описываемый вами тест. Тут то все и станет на свои места.

Нагрузка в системах, использующих RAID, имеет еще более OLTP-ишную нагрузку, там все еще грустнее. Поэтому если вы будете иметь высоконагруженную систему, пускай web-сервер с тербованием в 5000IOPS и в этот сервер впихнете 5000/640 = 7,8125 что-то типа 8 винтов для данных - сервер загнется в первые же "треть секунды".

В таком случае вы будете ориентироваться как раз на то, что SATA-диск это в реальности 70IOPS, особенно это становится прозрачным, если посмотреть на его время доступа (:

Веб сервер с 5000 IOPS моего производства отлично работает уже 8-й год, называется Rambler's TOP100. Дисков там скорее всего два (сам я там не работаю 7-й год :), хватило бы и одного.

А время random-доступа - это оценка снизу. Да, такая оценка имеет место.

OLTP, кстати, тоже не обязана создавать большую нагрузку именно по random access, можно же и log structured писать.

ремэппинг? SSD умеют делать сами ремэпинг? Это где-то декларировано? Я понимаю, что вроде бы очевидно, но ни разу не замечал в спецификациях.

Более того, у, например mtron (где-то видел слова, что один из самых-самых производителей на сегодня - не суть), в спецификациях написан "срок службы"
MSD-SATA1025
7 years @ 50GB write per day
А еще настораживает сноска - (Sequential Write, 32GB Mtron SSD, : 5,000 cycles)

(выделено мной)

remapping называется wear leveling и я так понимаю, что используется сейчас везде.

А со сноской - это, по моему пониманию, страховка вот от чего
- если мы пишем по одному байту, это в любом случае перезапись целого блока (я не знаю какого они размера, ну допустим 256к хотя скорее меньше, килобайт 4-16). Соответственно, эти "50 Gb per day" надо считать не в байтах, а в перезаписанных блоках.

Но 5000 циклов - это гадски мало, я ожидал в 20-200 раз больше.

Вы чего-то не понимаете... флешка перезаписывается ОЧЕНЬ редко, а обращение к SSD может быть сотни раз в секунду (обычный 2.5" SSD это порядка 800 IOPS на запись и 10000 на чтение).

Вот и дохнут... и еще: http://ivs.livejournal.com/538941.html

Ну как это "редко" ?

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

Сдыхает железка не от "полных перезаписей", а когда наступает критическое число перезаписей одного элемента-блока-сектора-группы.ячеек.памяти (как угодно) и его уже нечем "заремапить". Поэтому если флешку вы пишете строго линейно, то постоянная запись в своп, который лежит в одном месте SSD-диска как раз его и убивает.

А wear leveling ?

У меня нет никакой конкретной информации по этой технологии на конкретном оборудовании, при том я уверен, что для SSD она не используется.

Вот у меня USB-флеш и CF - в них есть эта технология? Кто бы знал... сомневаюсь, что аппаратно совместимая с IDE флешка CF имеет эту фичу.

В флэшках для фотокамер оно обязательно есть. Иначе, с учетом FAT32, они бы сыпались на записи-удалении первого десятка тысяч файлов.

Это контроллер делает, тот самый, который из IDE делает флэшовые стирания-записи блоков.

Cогласен, похоже на правду.

5000 циклов, это у Multi Level Cell (MLC). У дисков с SLC флешем, они обещают >140 лет при 50GB/day (в циклах уже не приводят данных) - какраз эти "в 20 раз больше" и получаются. Но пока, увы, не 200.

Мы как-то давно это просчитывали эти чертовы циклы (тогда флешки мало циклов держали), в итоге отказались в embedded решении от записи логов во флешку совсем, даже с учетом, что там умная файловая система на флеш ориентированная (кажется, jffs, тоеперь jffs2, и и есть еще какая-то, можно выбрать при жалении). Текущая ситуация ощутимо лучше, но пока еще немного напрягает, чтоб в "просто компьютер" ставить :)

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

Add new comment