Comments 75
UFO just landed and posted this here
Эх, ещё бы то же самое, но с привязкой к конкретным моделям.
Google не хочет судиться с производителями накопителей
Это научное исследование, а не рыночный обзор или sales guide.
Что не мешало в отчете гугла по надежности винчестеров указать производителей. И это было очень полезно!
Ни разу не видел в таких исследованиях указаний производителей. Это принцип… В «отчете гугла по надежности винчестеров» — тоже. Вы что-то с кем-то путаете.
Точно. Хоть у гугла и был такой отчет, но без производителей. А с производителями это от Backblaze. Они не постеснялись — и молодцы. Нечего производителям мешать публиковать реальные сведения!
*Ни разу не видел в таких исследованиях указаний производителей. Это принцип…*
По ссылке ниже подобное же исследование с названиями производителей и даже конкретных моделей.
https://habrahabr.ru/post/209894/
По ссылке ниже подобное же исследование с названиями производителей и даже конкретных моделей.
https://habrahabr.ru/post/209894/
Это не научное исследование, это -так, sales guide. Тем, собственно, одно от другого и отличается. Очень жаль, что в последнее врем многие путают первое и второе.
Пусть так. Но та же самая статистика. Что еще нужно?
Sales guide? Серьезно? Ребята используют сотни, а иногда и тысячи дисков одной модели. У них есть на чем строить статистику.
Абсолютно серьезно. Науку интересует жесткий диск как таковой, и его поведение, а не «что вам купить из того, что есть на рынке». С точки зрения науки отчет, в котором «вендор А», «Вендор Б» и «Вендор Ц» совершенно нормален и правилен, это только вас интересует «а кто там за ними скрывается», ученому это не важно, да и не должно быть важно, по большому счету. Его не разница между вендорами интересует, выяснение этого может только помешать ответить на главные вопросы исследования.
Что не мешало в отчете гугла по надежности винчестеров указать производителей.
Это требует разрешения производителя, причем независимо от автора исследования и в случае даже добровольной передачи на исследования. Скорее всего лицензионное соглашение.
Я знаю что многие очевидные вещи сейчас запрещены т.н. копирастами. Но это не должно считаться нормальным.
Поэтому пока еще не запретили обсуждать такое некорректное поведение, ущемляющее права человека, надо информировать население. Глядишь и созреет критическая масса (я про глобальное население, а не конкретной страны).
Запрет на публикацию тестов и т.п. это просто ужас. Производители и поставщики так хотят назад в век паровых машин, мануфактур и гильдий!
Поэтому пока еще не запретили обсуждать такое некорректное поведение, ущемляющее права человека, надо информировать население. Глядишь и созреет критическая масса (я про глобальное население, а не конкретной страны).
Запрет на публикацию тестов и т.п. это просто ужас. Производители и поставщики так хотят назад в век паровых машин, мануфактур и гильдий!
Запрет на публикацию тестов и т.п. это просто ужас
Это у вас как вышло? Нельзя называть производителя, как правило, а результаты тестов с именами производителей А, Б и В можно. А так можно выложить практически информацию.
Кроме того, поставьте себя на место производителя. Кто-то купил партию дисков, а они оказались бракованными. Статью запускают, оказывается — брак единичной партии. А репутация потеряна… У Google ведь выборка тоже не самая строгая. Закупалось партиями, могло не повести с конкретной партией. А потом обиженная компания потребует компенсации стоимостью в утерянную прибыль (здесь она считается попроще, чем виртуальные расчеты в авторском праве), причем сразу. Потому никто не заинтересован в таком. Ответственность слишком большая.
Если производитель позволяет себе выдать бракованную партию, то его репутация и должна быть потеряна.
В принципе объективные и независимые тесты не выгодны производителям — им выгоден маркетинговый буллшит.
И ситуация, когда нет реальной возможности публиковать результаты таких тестов совершенно не нормальна — интересы потребителей должны бы быть в приоритете, иначе получается то, что мы имеем: мир одноразовых вещей.
В принципе объективные и независимые тесты не выгодны производителям — им выгоден маркетинговый буллшит.
И ситуация, когда нет реальной возможности публиковать результаты таких тестов совершенно не нормальна — интересы потребителей должны бы быть в приоритете, иначе получается то, что мы имеем: мир одноразовых вещей.
Если производитель позволяет себе выдать бракованную партию, то его репутация и должна быть потеряна.
А если не вина завода, а инженер из ОТК обиделся и решил "наказать" компанию и не сообщать о браке? Или было неправильное хранение или транспортировка, когда изготовитель вообще не при делах?
И ситуация, когда нет реальной возможности публиковать результаты таких тестов совершенно не нормальна
Она есть. Нужно убедить компанию в беспристрастном и взвешенном анализе.
> А если не вина завода, а инженер из ОТК обиделся и решил «наказать» компанию и не сообщать о браке?
Вероятно, это и есть проблема компании? И такие ситуации точно также должны вредить её репутации?
> Она есть. Нужно убедить компанию в беспристрастном и взвешенном анализе.
Если бы… Убедить-то надо в том, что публикация выгодна компании. Компании не нужна никакая взвешенность и беспристрастность — наоборот, она сильно повредит, заведомо пойдя в разрез с результатами работы отдела маркетинга.
Компаний которые делают качественные вещи, как и тех, что описывают результаты своей работы объективно, пренебрежимо мало.
Вероятно, это и есть проблема компании? И такие ситуации точно также должны вредить её репутации?
> Она есть. Нужно убедить компанию в беспристрастном и взвешенном анализе.
Если бы… Убедить-то надо в том, что публикация выгодна компании. Компании не нужна никакая взвешенность и беспристрастность — наоборот, она сильно повредит, заведомо пойдя в разрез с результатами работы отдела маркетинга.
Компаний которые делают качественные вещи, как и тех, что описывают результаты своей работы объективно, пренебрежимо мало.
> А если не вина завода, а инженер из ОТК обиделся и решил «наказать» компанию и не сообщать о браке?
Вероятно, это и есть проблема компании? И такие ситуации точно также должны вредить её репутации?
В идеальном мире нет, на практике виноват будет не мистер Икс, а компания Игрек.
Компании не нужна никакая взвешенность и беспристрастность — наоборот, она сильно повредит, заведомо пойдя в разрез с результатами работы отдела маркетинга.
Компаний которые делают качественные вещи, как и тех, что описывают результаты своей работы объективно, пренебрежимо мало.
Зависит от репутации просящего. Тесты в RWTH проводили Ауди, Форд, Панасоник, Варта, Сименс (это те, про которые рассказывали у нас на факультете). Те же Форд с Панасоником одними своими объемами на "пренебрежимо мало" не тянет.
> В идеальном мире нет, на практике виноват будет не мистер Икс, а компания Игрек.
И совершенно правильно. Если компания допускает возможность обхода/фальсификации проверки качества одним сотрудником, то процесс проверки не выдерживает критики, и это вина именно компании, и проблема построения её бизнес процессов. И, естественно, репутация такой компании должна падать.
> Тесты в RWTH проводили Ауди, Форд, Панасоник, Варта, Сименс
Вы про заказные исследования на заданную тему с закономерными выводами? Какое отношение это имеет к рассматриваемой проблеме вообще?
Я-то речь вёл про независимые исследования без инициативы компании, и тем более прямого/косвенного финансирования.
Например такие, на которых пропалились те же VW, с подделкой данных экологичности дизелей. Хотя выявившим настолько серьёзные проблемы опубликоваться и защититься просто — слишком большой резонанс.
Кстати, VW финансировали исследования доказывающие экологичность дизелей, а не только покопались в ЭБУ, чтобы пройти тесты.
А вот если проблема не настолько серьёзна, отбиться от юристов крупной компании после публикации любых не угодных её данных может оказаться большой проблемой.
P.S. Ситуация в принципе не нормальна, когда надо какое-то разрешение спрашивать для подобных исследований и публикации их результатов.
И совершенно правильно. Если компания допускает возможность обхода/фальсификации проверки качества одним сотрудником, то процесс проверки не выдерживает критики, и это вина именно компании, и проблема построения её бизнес процессов. И, естественно, репутация такой компании должна падать.
> Тесты в RWTH проводили Ауди, Форд, Панасоник, Варта, Сименс
Вы про заказные исследования на заданную тему с закономерными выводами? Какое отношение это имеет к рассматриваемой проблеме вообще?
Я-то речь вёл про независимые исследования без инициативы компании, и тем более прямого/косвенного финансирования.
Например такие, на которых пропалились те же VW, с подделкой данных экологичности дизелей. Хотя выявившим настолько серьёзные проблемы опубликоваться и защититься просто — слишком большой резонанс.
Кстати, VW финансировали исследования доказывающие экологичность дизелей, а не только покопались в ЭБУ, чтобы пройти тесты.
А вот если проблема не настолько серьёзна, отбиться от юристов крупной компании после публикации любых не угодных её данных может оказаться большой проблемой.
P.S. Ситуация в принципе не нормальна, когда надо какое-то разрешение спрашивать для подобных исследований и публикации их результатов.
Если компания допускает возможность обхода/фальсификации проверки качества одним сотрудником, то процесс проверки не выдерживает критики, и это вина именно компании, и проблема построения её бизнес процессов
Вроде же нормальный подход, когда один человек несет ответственность, а не коллектив.
> Тесты в RWTH проводили Ауди, Форд, Панасоник, Варта, Сименс
Вы про заказные исследования на заданную тему с закономерными выводами? Какое отношение это имеет к рассматриваемой проблеме вообще?
Я-то речь вёл про независимые исследования без инициативы компании, и тем более прямого/косвенного финансирования.
Это были сравнительные независимые тесты. Эти компании разрешили озвучить результаты про себя независимо от их показателей.
> А если не вина завода, а инженер из ОТК обиделся и решил «наказать» компанию и не сообщать о браке?
> Вроде же нормальный подход, когда один человек несет ответственность, а не коллектив.
При чём тут ответственность? Вы прочитайте, внимательно, что я писал выше — если один человек может пропустить бракованную партию, то виновата безусловно компания. Она неправильно организовала процесс. В итоге пострадает её репутация, и это вполне закономерно.
А кого там в компании за это накажут, и кто реально виноват в этой ситуации, потребителю этого брака совершенно не важно.
Важно, что сначала брак допустили, а потом ещё и отгрузили. Естественно, что доверие к такому поставщику и должно упасть, что вы в этом ведите не нормального, и не справедливого?
> Это были сравнительные независимые тесты. Эти компании разрешили озвучить результаты про себя независимо от их показателей.
Можно ссылки на исследования, и заодно, кто был инициатором, и кто финансировал эти исследования?
> Вроде же нормальный подход, когда один человек несет ответственность, а не коллектив.
При чём тут ответственность? Вы прочитайте, внимательно, что я писал выше — если один человек может пропустить бракованную партию, то виновата безусловно компания. Она неправильно организовала процесс. В итоге пострадает её репутация, и это вполне закономерно.
А кого там в компании за это накажут, и кто реально виноват в этой ситуации, потребителю этого брака совершенно не важно.
Важно, что сначала брак допустили, а потом ещё и отгрузили. Естественно, что доверие к такому поставщику и должно упасть, что вы в этом ведите не нормального, и не справедливого?
> Это были сравнительные независимые тесты. Эти компании разрешили озвучить результаты про себя независимо от их показателей.
Можно ссылки на исследования, и заодно, кто был инициатором, и кто финансировал эти исследования?
> Вроде же нормальный подход, когда один человек несет ответственность, а не коллектив.
При чём тут ответственность? Вы прочитайте, внимательно, что я писал выше — если один человек может пропустить бракованную партию, то виновата безусловно компания.
Угу. Гораздо лучше, когда не только виноватого не найдешь, а еще и коллегиальное решение.
Такое впечатление, что вы с производством не сталкивались да и должность ваша никакой ответственности не заставляет на себя брать. Я описал ситуацию крайнюю, возможны еще ошибки.
Можно ссылки на исследования, и заодно, кто был инициатором, и кто финансировал эти исследования?
Вот один из примеров, первый запрос в Гугле (сложная работа, сделал для вас), финансирование от земли Северный Рейн-Вестфалия:
ссылка
> Угу. Гораздо лучше, когда не только виноватого не найдешь, а еще и коллегиальное решение.
Какое коллегиальное решение? Какие поиски виноватого? Есть методики проверки. Данные проверок фиксируются. Если какой-то работник может это легко обойти, что-то не так — это явная единая точка отказа.
Чтобы что-то гуглить, надо хотя бы приблизительно понимать, о какого рода исследованиях вы говорите, иначе можно угугуиться, а достаточной информации вы по этому случаю не предоставили.
С материалом по вашей ссылке я, к сожалению, ознакомиться не смог — немецкого я не знаю, а результаты автоматического перевода данного текста не читаемы, англоязычной версии тоже не видать.
Какое коллегиальное решение? Какие поиски виноватого? Есть методики проверки. Данные проверок фиксируются. Если какой-то работник может это легко обойти, что-то не так — это явная единая точка отказа.
Чтобы что-то гуглить, надо хотя бы приблизительно понимать, о какого рода исследованиях вы говорите, иначе можно угугуиться, а достаточной информации вы по этому случаю не предоставили.
С материалом по вашей ссылке я, к сожалению, ознакомиться не смог — немецкого я не знаю, а результаты автоматического перевода данного текста не читаемы, англоязычной версии тоже не видать.
По статистике, у 30-80% SSD-накопителей появляется хотя бы один новый плохой блок в течение первых четырёх лет эксплуатации
По сравнению со всем спектром значений (0-100%), указанные цифры — это вершина точности!
А если серьёзно и если я что-то не понимаю в процентах… как понимать эти цифры?
Понимать очень просто: не забывайте про бэкапы.
> не забывайте про бэкапы.
… и про то, что бэкапы — не панацея, а всего лишь снижение вероятности потери, ибо в бэкапе ошибка может появиться точно так же, как и в основной копии…
Поэтому ZFS (https://ru.wikipedia.org/wiki/ZFS), построенная на предположении, что *все* носители ненадёжны, в режиме zraid — наше всё!
… и про то, что бэкапы — не панацея, а всего лишь снижение вероятности потери, ибо в бэкапе ошибка может появиться точно так же, как и в основной копии…
Поэтому ZFS (https://ru.wikipedia.org/wiki/ZFS), построенная на предположении, что *все* носители ненадёжны, в режиме zraid — наше всё!
Или ее конкурента btrfs (https://ru.wikipedia.org/wiki/Btrfs), там так же реализовано CoW (copy-on-write).
UFO just landed and posted this here
Да, я знаю про проблемы, я даже лично жаловался где-то в комментариях полгода назад. Я думаю, это зависит от «новизны» ядра, т.к. FS пока новая. К примеру, на данный момент у меня kernel-4.2.0-30, и проблем я больше давно не испытываю.
Статус можно посмотреть тут: https://btrfs.wiki.kernel.org/index.php/Main_Page#Stability_status
Статус можно посмотреть тут: https://btrfs.wiki.kernel.org/index.php/Main_Page#Stability_status
В отличии чего? От ZFS или от ZoL? Это очень важное замечание, ведь ZFS недоступна на линуксе.
P.S. Большинство проблем с btrfs было производными от контейнеров — когда создается тысячи снэпшотов. Сходу не могу придумать юзкейз для такого, если не использовать контейнеры.
P.P.S. Не умаляю багов btrfs, они есть. Но и в ZoL они присутствуют. И по опыту я доверяю первому больше, чем второму, так в продакшне ZoL — редчайшая редкость, а btrfs — нет.
ZoL будет доступен без бубна только с Ubuntu 16.04
P.S. Большинство проблем с btrfs было производными от контейнеров — когда создается тысячи снэпшотов. Сходу не могу придумать юзкейз для такого, если не использовать контейнеры.
P.P.S. Не умаляю багов btrfs, они есть. Но и в ZoL они присутствуют. И по опыту я доверяю первому больше, чем второму, так в продакшне ZoL — редчайшая редкость, а btrfs — нет.
ZoL будет доступен без бубна только с Ubuntu 16.04
UFO just landed and posted this here
Я понял так: у 20% в течение первых 4 месяцев не обнаружено ни одного плохого блока, как минимум у 30% процентов был обнаружен минимум 1 плохой блок в тот же период.
Я думаю, привязка к конкретному производителю или типу памяти.
Здесь больше смысла в сравнении порядка цифр. Бедблоки появляются на порядок чаще, чем сбои микросхем.
Интересно было бы глянуть статистику, отличается ли оно для TLC, или особых отличий от MLC нет?
Все же сейчас пытаются их продвинуть как самые недорогие, не хотелось бы падения срока службы даже без учета циклов записи.
Все же сейчас пытаются их продвинуть как самые недорогие, не хотелось бы падения срока службы даже без учета циклов записи.
>> https://www.usenix.org/sites/default/files/fast16_full_proceedings.pdf
Да это же просто кладезь полезной информации! Спасибо.
Да это же просто кладезь полезной информации! Спасибо.
что на надёжность накопителей влияет возраст, а не интенсивность использования.
Да ладно? По моему это очевидно.
Да ладно? По моему это очевидно.
Имеется ввиду, что куча перезаписываний не настолько влияет на работоспособность по сравнению со свежим "из упаковки", как календарный износ. Что, в общем, неплохо, легче планировать замену.
Позволю себе не согласиться с тем, что куча перезаписываний не «настолько» влияет на работоспособность. Во-первых, хотелось бы уточнить какой процент интенсивности имелся ввиду в слове «настолько»? Во-вторых, с практической точки зрения, на наших серверах ни один SSD не прожил более полугода при интенсивных циклах чтение/запись.
Так это же замечательно! Вам должны были обменять диск по гарантии. Планируйте замены и у вас всегда будет новый диск без затрат с вашей стороны ;)
Не будет — т.к. в условиях гарантии прописан не только срок в годах/месяцах работы, но и максимально допустимые объемы записи — в виде кол-ва циклов или ТБ записанных данных.
Странные у вас диски, однако.
За полгода 17 ТБ, ни один диск не меняли.
Более долгую статистику лень поднимать.
P.S. Хотя это не честная статистика. Четыре диска, raid 10.
root@NDA:~# vmstat -D | awk '/written sectors/ {print $1 * 512 / 1000 / 1000 / 1000}'
16955.4
root@NDA:~# uptime | awk '{print $3" "$4}'
186 days,
За полгода 17 ТБ, ни один диск не меняли.
Более долгую статистику лень поднимать.
P.S. Хотя это не честная статистика. Четыре диска, raid 10.
Какие диски странные? Почему у меня?
Я же не писал никаких конкретных объемов записи или конкретных моделей. Это вообще общая практика всех производителей SSD ограничивать объем записи и отказывать в гарантийной замене при превышении прописанных объемов/нагрузки по записи.
Что до конкретики, то 17 ТБ за полгода да еще не на одиночный диск, а целый массив — это совсем немного по меркам современных серверов и SSD. Для серверных вариантов дисков обычно нагрузка до 50-100 ГБ записи/сутки (на одиночный диск) покрывается гарантией. Потому и не меняли — до исчерпания ресурса скорее всего еще далеко.
У меня на скромном домашнем сервере/раб. станции только для личного использования (+ научные расчеты в на свободных процессорных ресурсах) на единственный диск 13 ТБ записи за последние 4 месяца. Правда объем смотрю не по мониторингу файловой системы ОС, а по данным контроллера самого диска (в SMART) — данные от ОС получаются заниженные, т.к. на SSD имеется такой эффект как Write amplification приводящий к тому, что по факту на флэш пишется существенно больше чем ОС отсылает для записи в контроллер диска. Из-за известного несоответствия логических блоков которыми идет запись на уровне ОС (сектор/кластер объемами 0.5-16 кб) и физической записью(стиранием) флэш памяти которая возможна только минимальными блоками по 256-1024 кб.
Я же не писал никаких конкретных объемов записи или конкретных моделей. Это вообще общая практика всех производителей SSD ограничивать объем записи и отказывать в гарантийной замене при превышении прописанных объемов/нагрузки по записи.
Что до конкретики, то 17 ТБ за полгода да еще не на одиночный диск, а целый массив — это совсем немного по меркам современных серверов и SSD. Для серверных вариантов дисков обычно нагрузка до 50-100 ГБ записи/сутки (на одиночный диск) покрывается гарантией. Потому и не меняли — до исчерпания ресурса скорее всего еще далеко.
У меня на скромном домашнем сервере/раб. станции только для личного использования (+ научные расчеты в на свободных процессорных ресурсах) на единственный диск 13 ТБ записи за последние 4 месяца. Правда объем смотрю не по мониторингу файловой системы ОС, а по данным контроллера самого диска (в SMART) — данные от ОС получаются заниженные, т.к. на SSD имеется такой эффект как Write amplification приводящий к тому, что по факту на флэш пишется существенно больше чем ОС отсылает для записи в контроллер диска. Из-за известного несоответствия логических блоков которыми идет запись на уровне ОС (сектор/кластер объемами 0.5-16 кб) и физической записью(стиранием) флэш памяти которая возможна только минимальными блоками по 256-1024 кб.
Глянул другой сервер. 636 гб/сутки(делим пополам, т.к. raid 10) при объеме диска в 279GiB (300GB) Но там аптайм всего 134 дня, поэтому не приводил как пример — меньше, чем указанные выше "выходят из строя за полгода".
И это по "существенно заниженным данным" (с)
Я веду к тому, что утверждение "ни один SSD не прожил более полугода" — голословно без пруфов.
И это по "существенно заниженным данным" (с)
Я веду к тому, что утверждение "ни один SSD не прожил более полугода" — голословно без пруфов.
Ну с этим вопросом к Patttern который про полгода и писал, а не я. Только какой пруф? Ну приведет он свою собственную статистику со своих серверов. Которую можно будет лишь принять (или не принимать) на веру/слово, т.к. какие там сервера и что они именно они у них в организации делают мы не знаем и проверить не можем.
А что действительно интенсивной записью SSD можно и всего за несколько месяцев убить я не сомневаюсь, проверялось неоднократно. Если задаться такой целью то и за неделю-другую убить можно(но это уже специально — типа зацикленного теста на линейную запись, в реальных задачах таких жестких вариантов не встречается). Для того производители SSD и страхуются прописывая объем записи в условиях гарантии в отличии от производителей HDD, которым этот параметр безразличен.
P.S.
Вот по 636 Гб/сутки по мониторингу ОС это уже довольно серьезные объемы записи для сервера. Диски из этого массива вполне рискуют не дожить до конца гарантии и получить отказ в бесплатной их замене по причине превышения допустимой нагрузки.
А что действительно интенсивной записью SSD можно и всего за несколько месяцев убить я не сомневаюсь, проверялось неоднократно. Если задаться такой целью то и за неделю-другую убить можно(но это уже специально — типа зацикленного теста на линейную запись, в реальных задачах таких жестких вариантов не встречается). Для того производители SSD и страхуются прописывая объем записи в условиях гарантии в отличии от производителей HDD, которым этот параметр безразличен.
P.S.
Вот по 636 Гб/сутки по мониторингу ОС это уже довольно серьезные объемы записи для сервера. Диски из этого массива вполне рискуют не дожить до конца гарантии и получить отказ в бесплатной их замене по причине превышения допустимой нагрузки.
Позволю себе не согласиться с тем, что куча перезаписываний не «настолько» влияет на работоспособность.
Это статистика Google, не мои слова и не мои исследования. У вас есть сопоставимая по размерам база данных?
Там в табличке (последняя строчка в 1й) есть объем записи в эквиваленте среднего кол-ва циклов полной перезаписи. Ни в одном из обобщенных классов средний показатель даже до 1000 циклов не доходит — потому и "не влияет"
Хотя на самом деле влияет, но еще так слабо что статистической значимости не имеет и выводы из этого делать не позволяет.
Хотя на самом деле влияет, но еще так слабо что статистической значимости не имеет и выводы из этого делать не позволяет.
Она не влияет только потому что конкретно у гугла количество этих циклов до смешного (по меркам серверов) низкое — тут же в статье табличка с основными данными есть — среднее кол-во циклов перезаписи даже до 1000 ни в одном классе не дотягивает. Что существенно меньше самых слабых в этом смысле MLC (3000 циклов).
Естественно в таких условиях зависимость надежности от кол-ва циклов записи еще не прослеживается. Единственное непонятно — а нафига гугл вообще более дорогие SLC накопители массово закупал, если исходя из интенсировностей использования им вполне достаточно MLC?
Естественно в таких условиях зависимость надежности от кол-ва циклов записи еще не прослеживается. Единственное непонятно — а нафига гугл вообще более дорогие SLC накопители массово закупал, если исходя из интенсировностей использования им вполне достаточно MLC?
С чего это вдруг становится очевидно? То все мозги промыли циклами записи, и вдруг время работы откуда-то появилось.
А ещё была статья о том, как SSD плохо лежат на полке, без подачи питания.
Для меня всегда был очевиден этот факт, как и то, что SSD плохо лежат без питания. Предлогам вам окунутся в мир мелкой электроники, это поможет смотреть на все вещи под другим углом.
Ещё была статья от LSI про это.
Одно дело — потеря данных на полке с течением времени. Ячейка же не деградирует через 2 года, я надеюсь? Перезаписали, и в путь. А тут деградация. Необратимая. Мне кажется, это не одно и тоже.
Да, совершенно разные процессы. В одном случае физическая деградация, в другом просто постепенное "утекание" заряда из управляющего электрода транзистора, который и сохраняет данные. И восстанавливается на исходном уровне после каждой перезаписи. Одно пропорционально кол-ву циклов перезаписи, 2е времени хранения без подачи питания.
Правда они коррелируют — чем выше физ. износ (количество уже произведенных циклов перезаписи), тем быстрее начинает "утекать" заряд.
Т.е. новый в плане "пробега" диск может довольно долго "лежать на полке" с данными в полной сохранности. А вот поношенный, приближающийся к концу ресурса по записи может уже через несколько месяцев без питания начинать терять записанные данные.
Поэтому взять старый(точнее изношенный) SSD и использовать его для бекапа — будет очень плохой идеей. Хотя такой вариант на 1й взгляд напрашивается — дескать при продолжении активной эксплуатации он скоро накроется ввиду исчерпания ресурса, а вот как офлайн-накопитель с очень редкой перезаписью еще послужит.
Правда они коррелируют — чем выше физ. износ (количество уже произведенных циклов перезаписи), тем быстрее начинает "утекать" заряд.
Т.е. новый в плане "пробега" диск может довольно долго "лежать на полке" с данными в полной сохранности. А вот поношенный, приближающийся к концу ресурса по записи может уже через несколько месяцев без питания начинать терять записанные данные.
Поэтому взять старый(точнее изношенный) SSD и использовать его для бекапа — будет очень плохой идеей. Хотя такой вариант на 1й взгляд напрашивается — дескать при продолжении активной эксплуатации он скоро накроется ввиду исчерпания ресурса, а вот как офлайн-накопитель с очень редкой перезаписью еще послужит.
Работаю в отрасли. Результаты весьма удивительны, надо признать: техпроцесс 50 нм, один и тот же вендор, а процент сбойных драйвов MLC-A и SLC-B отличаются в два с половиной раза не в пользу SLC. А еще в сравнении SLC-A и SLC-B — первый 34 нм, второй 50 нм — первый довольно неожиданно выигрывает.
Пожалуй, посмотрим на таблички повнимательнее на работе.
И это самое. Анатолий, вы бы убрали тэг UBER, ей-ей :)
Пожалуй, посмотрим на таблички повнимательнее на работе.
И это самое. Анатолий, вы бы убрали тэг UBER, ей-ей :)
Расскажите пожалуйста, есть ли разница в надежности MLC и TLC.
Зачем убирать? Теперь мы знаем как расшифровывается UBER :)
Ну у каждого производителя бывают более или менее удачные продукты… Тем более, что может быть разница в выходе качественных кристаллов на оборудовании с более грубым техпроцессом, к примеру — для 34нм оборудование явно современее и точнее, возможно, рассчитано и на более тонкие процессы. Или вообще разные фабрики с разной культурой производства, если делаются чипы не своими силами.
Было бы намного интереснее узнать анализ физики отказа/деградации/усталости/ошибки при чтении SSD и сравнение актуальной статистики с моделями, которые использовались, чтобы предсказать надежность этих ссдшек.
Да, об этом тоже написано. Видимо, гадание на кофейной гуще надежнее )
Much academic work and also tests during the procurement
phase in industry rely on accelerated life tests to
derive projections for device reliability in the field. We
are interested in how well predictions from such tests reflect
field experience.
Analyzing results from tests performed during the procurement
phase at Google, following common methods
for test acceleration, we find that field RBER rates
are significantly higher than the projected rates. For example,
for model eMLC-A the median RBER for drives
in the field (which on average reached 600 PE cycles at
the end of data collection) is 1e-05, while under test the
RBER rates for this PE cycle range were almost an order
of magnitude lower and didn’t reach comparable rates
until more than 4,000 PE cycles. This indicates that it
might be very difficult to accurately predict RBER in the
field based on RBER estimates from lab tests.
Неожиданным оказалось, что на надёжность накопителей влияет возраст, а не интенсивность использования.
Это как сказать, вот коэффициент ранговой корреляции Спирмена из статьи.
Видно, что в первую очередь ошибки встречаются на тех дисках, на которых ошибки встречались ранее (корреляция 0,8 из 1), во вторую — на "старичках" и "затертых" (корреляция 0,4 из 1). Учитывая, что в энтерпрайзе количество PE является функцией от возраста диска, нет ничего удивительного в том, что PE и возраст влияют на надежность одинаково.
Что значит "неисправимых"? На HDD может выйти из строя головка или механика и весь диск непригоден для работы. А появление нескольких bad block всего-лишь уменьшает доступную емкость, а для чтения может быть скомпенсировано избыточным кодированием.
Это у них терминология такая:
Uncorrectable error: A read operation encounters more
corrupted bits than the ECC can correct.
Final read error: A read operation experiences an error,
and even after retries the error persists.
Final write error: A write operation experiences an error
that persists even after retries.
Sign up to leave a comment.
Надёжность SSD в реальном мире: опыт Google