Comments 55
Детский сад какой-то.
Ждем похожих историй про интеловский оптан и прочие "технологии".
Эта статья не про Apple Fusion Drive, в начале об этом написано. Она про то, что множество людей сейчас несёт на восстановление данных жесткие диски из ноутбуков, которые им заменили в сервис-центрах. А восстанавливать оттуда нечего. И статья написана в попытке как-то повлиять на этот тренд.
Полгода назад реанимровал старый Мак 2009 года. Думал убрать CD-диск и поставить SSD, объединив в Fusion. Мастер, который делал отговорил, сказав, что во Fusion пропиертарный протокол объединения двух дисков. И чтобы я не выпендривался, а просто разметил два диска (HDD, SSD) как отдельные. «Целее будут», завершил он спич :)
Есть Мак 2010 года. Добавил в него SSD, не удаляя CD. Собрал Fusion, года 4 уже работает, правда после перехода на HS уже не хватает производительности когда запускаешь виртуалку в Parallels. В остальном все нормально.
«пропиертарный протокол» — это такой себе LVM в исполнении Apple.
Ничего там страшного нет.
Ничего там страшного нет.
С таким себе своеобразным thin provisioning, в котором все данные о размещении данных лежат именно на ссд.
Весь смысл статьи в одной ветке комментариев…
P.S. lll000lll за статью всё равно спасибо!
P.S. lll000lll за статью всё равно спасибо!
Да, вы правы. Возможно, я поступил не совсем верно, просто вариант с оформлением в таком виде представился лучшим.
Можно было в один-два абзаца всё уместить, но тогда это не соответствовало бы правилам Гиктаймс, а обратить внимание сообщества на возникшую ситуацию для уменьшения случаев потерь данных счёл важным.
Поэтому и разделил текст на две части, вся суть в начале статьи, под катом — детали.
Можно было в один-два абзаца всё уместить, но тогда это не соответствовало бы правилам Гиктаймс, а обратить внимание сообщества на возникшую ситуацию для уменьшения случаев потерь данных счёл важным.
Поэтому и разделил текст на две части, вся суть в начале статьи, под катом — детали.
Обычно 4 копии: 2 на hdd и 2 на ssd. Данные о размещении шифрованы, а ключ иногда меняется/теряется/повреждается.
У меня собствено было подтверждение данной истории Макбук Прошка 11го года. Вытащил привод, поставил ssd, объединил все в fusion.
Прошло 4 месяца и в один прекрасный вечер система не стартует, данных нет. Ладно, все важное в облаке, переставляю, делаю всю процедуру по объединению заново. Проходит какое-то время и снова система падает.
В итоге остановился на ssd для системы, папка пользователя на hdd. Год все стабильно.
Прошло 4 месяца и в один прекрасный вечер система не стартует, данных нет. Ладно, все важное в облаке, переставляю, делаю всю процедуру по объединению заново. Проходит какое-то время и снова система падает.
В итоге остановился на ssd для системы, папка пользователя на hdd. Год все стабильно.
За много лет работы в области восстановления данных, у меня лично сложилось мнение, что если есть какая-то возможность обойтись без объёдинения накопителей (не важно с помощью какой технологии, RAID какой-то, или что-то совсем проприетарное) лучше так и сделать. Чтобы накопители работали независимо.
И при эксплуатации в итоге надёжнее получается, и данные достать, если что, проще.
Я помимо прочего сисадминю немного, внутри компании, и раньше втыкал рэйды повсюду просто потому что мог — были контроллеры и корзины, ничего покупать не надо было. А в последние годы, не смотря на то, что есть из чего их собирать, есть кому следить за ними, и если что, данные можем восстановить — предпочитаю везде где можно без них обходится, и по большей части это удаётся. В итоге инфраструктура проще и надёжнее получается. И моё время экономится.
И при эксплуатации в итоге надёжнее получается, и данные достать, если что, проще.
Я помимо прочего сисадминю немного, внутри компании, и раньше втыкал рэйды повсюду просто потому что мог — были контроллеры и корзины, ничего покупать не надо было. А в последние годы, не смотря на то, что есть из чего их собирать, есть кому следить за ними, и если что, данные можем восстановить — предпочитаю везде где можно без них обходится, и по большей части это удаётся. В итоге инфраструктура проще и надёжнее получается. И моё время экономится.
А вот насчет RAID 1+ — это вы зря. Там избыточность, при деградации можно спокойно вытащить и заменить сломанный.
Ага, и в момент ребилда массив рассыпется из-за того, что обнаружится бэд, не хватит чётности для восстановления и прошивка не сможет корректно эту ситуацию обработать. Или в течении короткого времени несколько дисков выпадут. Или просто контроллер из строя выйдет. Регулярно с результатами подобных происшествий работаем.
И да, действительно можно спокойно вытащить. Но для того, чтобы такая возможность была, надо подобную ситуацию вовремя обнаружить. Для этого надо внимательно следить за состоянием массива и оперативно реагировать на любые неполадки. Регулярно проверять состояние hotspare дисков, если они есть и т.п.
В общем время на это на всё нужно, и на настройку и на наблюдение за состоянием. И резервного копирования всё равно это не отменяет. Если это основная рабочая обязанность — нет проблем. Но если и без этого задач хватает — хочется оптимизировать время затраты.
Я же не говорю, что рейды, это плохо. Во многих случаях они необходимы. Но считаю, что без необходимости к лишним усложнениям при хранении данных лучше не прибегать.
И да, действительно можно спокойно вытащить. Но для того, чтобы такая возможность была, надо подобную ситуацию вовремя обнаружить. Для этого надо внимательно следить за состоянием массива и оперативно реагировать на любые неполадки. Регулярно проверять состояние hotspare дисков, если они есть и т.п.
В общем время на это на всё нужно, и на настройку и на наблюдение за состоянием. И резервного копирования всё равно это не отменяет. Если это основная рабочая обязанность — нет проблем. Но если и без этого задач хватает — хочется оптимизировать время затраты.
Я же не говорю, что рейды, это плохо. Во многих случаях они необходимы. Но считаю, что без необходимости к лишним усложнениям при хранении данных лучше не прибегать.
> Ага, и в момент ребилда
Упадет метеорит на сервер, прилетят пришельцы и начнется зомби-апокалипсис.
> Для этого надо внимательно следить за состоянием массива и оперативно реагировать на любые неполадки.
Например тот же mdadm много чего умеет из коробки. А ведь есть еще куча всяких систем мониторинга.
> В общем время на это на всё нужно, и на настройку и на наблюдение за состоянием.
По-моему, лучше один раз потратить время на изучение/настройку, и иметь хоть какую-то избыточность и устойчивость к сбоям, чем не иметь их совсем. Конечно, бэкапы никто не отменял. Но подъем и разворачивание из бэкапов — процедура достаточно долгая, и не всегда уместная.
> Но считаю, что без необходимости к лишним усложнениям при хранении данных лучше не прибегать.
Ну да, нет смысла городить на десктопе массив из 10 дисков (на самом деле иногда есть).
Упадет метеорит на сервер, прилетят пришельцы и начнется зомби-апокалипсис.
> Для этого надо внимательно следить за состоянием массива и оперативно реагировать на любые неполадки.
Например тот же mdadm много чего умеет из коробки. А ведь есть еще куча всяких систем мониторинга.
> В общем время на это на всё нужно, и на настройку и на наблюдение за состоянием.
По-моему, лучше один раз потратить время на изучение/настройку, и иметь хоть какую-то избыточность и устойчивость к сбоям, чем не иметь их совсем. Конечно, бэкапы никто не отменял. Но подъем и разворачивание из бэкапов — процедура достаточно долгая, и не всегда уместная.
> Но считаю, что без необходимости к лишним усложнениям при хранении данных лучше не прибегать.
Ну да, нет смысла городить на десктопе массив из 10 дисков (на самом деле иногда есть).
>Ага, и в момент ребилда
Упадет метеорит на сервер, прилетят пришельцы и начнется зомби-апокалипсис.
Последствия ситуаций, когда из-за обнаружения бэдов в процессе ребилда массив разваливается, наблюдаем постоянно. Это не теоретические рассуждения, мы регулярно восстанавливаем данные после подобного.
Если не ошибаюсь, RAID 6 и всевозможные проприетарные аналоги, создавались в первую очередь по этой причине. Ёмкости дисков растут, количество секторов растёт, а средняя вероятность ошибки чтения для каждого конкретного сектора, как минимум, не уменьшается. На хабре даже статья или перевод были на тему того, что скоро и шестых рейдов хватать перестанет для надёжной страховки от одновременного возникновения бэдов на нескольких дисках массива.
Например тот же mdadm много чего умеет из коробки.
Так он для программных рейдов, нет?
А ведь есть еще куча всяких систем мониторинга.
Которые надо настроить и поддерживать. Если вы думаете, что можно настроить массив и системы мониторинга, а потом не проверять регулярно их корректную работу — вы потенциальный клиент компаний, восстанавливающих данные.
Конечно, бэкапы никто не отменял. Но подъем и разворачивание из бэкапов — процедура достаточно долгая, и не всегда уместная.
Да, полно ситуаций, когда рейд — лучший вариант. Но, например, если задача позволяет собрать два сервера подешевле, без массивов, и настроить репликацию данных, плюс бакапы, само собой, это может оказаться более удобной избыточностью.
> Это не теоретические рассуждения, мы регулярно восстанавливаем данные после подобного.
А можно примеры конфигураций, когда бэд на диске убивал raid? Сдается мне, избыточностью там и не пахло.
Ну и все более-менее современные диски умеют на уровне прошивки обрабатывать бэды, и писать гневные отчеты в смарт.
> скоро и шестых рейдов хватать перестанет для надёжной страховки от одновременного возникновения бэдов на нескольких дисках массива.
По-моему, это чушь какая-то. Извините. Начнем с вероятности возникновения бэдов одновременно на нескольких дисках в массиве. RAID 6 — это RAID 5 с доп. проверкой четности, и насколько помню допускает выход из строя 2 дисков из минимальных 4. И это если еще не копать во всякую экзотику, вроде 1+6.
> Так он для программных рейдов, нет?
Я лично перестал доверять аппаратным контроллерам после того, как наблюдал такую ситуацию — все диски в массиве ок, но внезапно вылетает контроллер и все превращается в тыкву, т.к. диски в живой массив на другом контроллере уже не собрать.
Вероятно есть более правильные контроллеры, которые хранят всю метадату на дисках (а не в своих внутренностях), но я за темой уже давно не слежу.
> Если вы думаете, что можно настроить массив и системы мониторинга, а потом не проверять регулярно их корректную работу
А зачем все это делать вручную? Есть же отличные средства автоматизации и тестирования.
> если задача позволяет
> подешевле
Ну тут конечно без вопросов. Задачи и бюджеты бывают разные.
А можно примеры конфигураций, когда бэд на диске убивал raid? Сдается мне, избыточностью там и не пахло.
Ну и все более-менее современные диски умеют на уровне прошивки обрабатывать бэды, и писать гневные отчеты в смарт.
> скоро и шестых рейдов хватать перестанет для надёжной страховки от одновременного возникновения бэдов на нескольких дисках массива.
По-моему, это чушь какая-то. Извините. Начнем с вероятности возникновения бэдов одновременно на нескольких дисках в массиве. RAID 6 — это RAID 5 с доп. проверкой четности, и насколько помню допускает выход из строя 2 дисков из минимальных 4. И это если еще не копать во всякую экзотику, вроде 1+6.
> Так он для программных рейдов, нет?
Я лично перестал доверять аппаратным контроллерам после того, как наблюдал такую ситуацию — все диски в массиве ок, но внезапно вылетает контроллер и все превращается в тыкву, т.к. диски в живой массив на другом контроллере уже не собрать.
Вероятно есть более правильные контроллеры, которые хранят всю метадату на дисках (а не в своих внутренностях), но я за темой уже давно не слежу.
> Если вы думаете, что можно настроить массив и системы мониторинга, а потом не проверять регулярно их корректную работу
А зачем все это делать вручную? Есть же отличные средства автоматизации и тестирования.
> если задача позволяет
> подешевле
Ну тут конечно без вопросов. Задачи и бюджеты бывают разные.
А можно примеры конфигураций, когда бэд на диске убивал raid? Сдается мне, избыточностью там и не пахло.
Верно. Я ведь и писал про обнаружение бэда в процессе ребилда. В такой момент избыточности нет. Например, после замены вышедшего из строя диска.
Ну и все более-менее современные диски умеют на уровне прошивки обрабатывать бэды, и писать гневные отчеты в смарт.
Ага, выполняется ремап и сектор заменяется на резервный. Но данных то в резервном секторе нет, а из заменённого сектора они не читаются. Таким образом, данные в секторе теряются, и контроллеру надо их откуда-то взять.
Я лично перестал доверять аппаратным контроллерам после того, как наблюдал такую ситуацию — все диски в массиве ок, но внезапно вылетает контроллер и все превращается в тыкву,
Так об этом и речь. И контроллер может физически остаться исправным — прошивки случается сбоят. Причём в тех ситуациях, ради обработки которых они и создавались. У программных решений свои проблемы.
А зачем все это делать вручную? Есть же отличные средства автоматизации и тестирования.
Корректную работу которых тоже надо регулярно проверять. Повторюсь, к нам регулярно обращаются люди, которые полностью положились на автоматические средства и устранились от ручного контроля за их работой.
Настроите автоматическую проверку автоматической проверки автоматической проверки — ок, но её работу тоже надо будет проверять.
> Таким образом, данные в секторе теряются, и контроллеру надо их откуда-то взять.
Так у нас raid же? Ну т.е. контроллер диска обнаруживает бэд, ремапит, а контроллер raid делает ресинк. Ситуацию когда бэд возникает одновременно на всех дисках в одном и том же месте и данные тупо пропадают я отношу к упомянутому ранее нападению пришельцев.
Если половина дисков в массиве вдруг резко осыпается — то это надо гнать админа ссаными тряпками, т.к. за много дней до этого момента смарт начинает орать.
> Повторюсь, к нам регулярно обращаются люди, которые полностью положились на автоматические средства и устранились от ручного контроля за их работой.
По моему личному мнению, это значит, что они что-то делают не так. Например, raid0 и настраивали мониторинг методом копипаста с SO.
> Настроите автоматическую проверку автоматической проверки автоматической проверки — ок, но её работу тоже надо будет проверять.
Это уже какая-то паранойя lvl80, даже я до такого не доходил)
Так у нас raid же? Ну т.е. контроллер диска обнаруживает бэд, ремапит, а контроллер raid делает ресинк. Ситуацию когда бэд возникает одновременно на всех дисках в одном и том же месте и данные тупо пропадают я отношу к упомянутому ранее нападению пришельцев.
Если половина дисков в массиве вдруг резко осыпается — то это надо гнать админа ссаными тряпками, т.к. за много дней до этого момента смарт начинает орать.
> Повторюсь, к нам регулярно обращаются люди, которые полностью положились на автоматические средства и устранились от ручного контроля за их работой.
По моему личному мнению, это значит, что они что-то делают не так. Например, raid0 и настраивали мониторинг методом копипаста с SO.
> Настроите автоматическую проверку автоматической проверки автоматической проверки — ок, но её работу тоже надо будет проверять.
Это уже какая-то паранойя lvl80, даже я до такого не доходил)
Ситуацию когда бэд возникает одновременно на всех дисках в одном и том же месте и данные тупо пропадают я отношу к упомянутому ранее нападению пришельцев.
В случае пятого — достаточно возникновения на двух. Что касается пришельцев — см. статьи, ссылки на которые дал, там оценивается вероятность подобного события.
По моему личному мнению, это значит, что они что-то делают не так. Например, raid0 и настраивали мониторинг методом копипаста с SO.
Возможно. Но узнают они о том, что что-то делают не так, уже после потери данных. Поэтому и нужны регулярные проверки в «ручном» режиме, распаковки резервных копий и проверки их корректности и т.п.
Это уже какая-то паранойя lvl80, даже я до такого не доходил)
Повторюсь. Речь не о теоретически-параноидальных рассуждениях, а о наблюдаемой практике. Есть автоматика, за корректной работой которой никто не наблюдает — значит есть потенциальный клиент на восстановление данных.
> о наблюдаемой практике
Ну т.е. нечто обратное survivorship bias. У вас же нет статистики о том сколько дисков/массивов успешно работают годами?
Ну т.е. нечто обратное survivorship bias. У вас же нет статистики о том сколько дисков/массивов успешно работают годами?
Нет. Но постоянно общаемся с людьми, которые настроили автоматическое резервное копирование, и обнаружили что оно давно должным образом не выполняется только после выхода хранища из строя.
Т.е. кто-то как-то, извиняюсь, через одно место что-то настроил не так, и виноват raid, я правильно понял?
Какая разница кто виноват? И люди ошибаются и техника сбоит.
И человек может быть уверен, что всё настроил безупречно, допустив при этом ошибку. И оборудование, которое по заявлением производителя должно предотвращать сбои, само их вызывает.
Цель не выяснить кто виноват, а предотвратить потерю данных, верно? Или я уже потерял нить обсуждения?
И человек может быть уверен, что всё настроил безупречно, допустив при этом ошибку. И оборудование, которое по заявлением производителя должно предотвращать сбои, само их вызывает.
Цель не выяснить кто виноват, а предотвратить потерю данных, верно? Или я уже потерял нить обсуждения?
Ну как-бы стоит начать с того, что raid — это не замена бэкапа.
Если админ забивает на корректность выполнения процедур бэкапа/восстановления — то я уже говорил что с ним следует делать.
И второе — в описанном случае raid вообще ну никак не при делах. Если у них там навернулись винты, и не настроен бэкап — то тут уже ничего не поможет (на самом деле можно немного повысить шансы успешного восстановления данных, если развернуть raid соотв. класса :)).
Если админ забивает на корректность выполнения процедур бэкапа/восстановления — то я уже говорил что с ним следует делать.
И второе — в описанном случае raid вообще ну никак не при делах. Если у них там навернулись винты, и не настроен бэкап — то тут уже ничего не поможет (на самом деле можно немного повысить шансы успешного восстановления данных, если развернуть raid соотв. класса :)).
По-моему, это чушь какая-то. Извините. Начнем с вероятности возникновения бэдов одновременно на нескольких дисках в массиве.
Если посчитаете вероятность, там не так уж и мало окажется. Секторов очень много на современных дисках, и их количество растёт дальше, а стабильность чтения наоборот падает. К сожалению, сейчас не могу найти статью с хабра, в которой приводились расчёты.
Да, с тем, что шестых совсем скоро перестанет хватать — ещё можно поспорить, у меня это тоже сомнения вызвало, возможно имеет смысл самому посчитать. Но вот для массивов с одним блоком чётности или зеркал — это уже так. Там вероятность одновременного возникновения бэдов вполне себе ощутимая. Маленькая, но рельная. Я так понимаю примерно как в лотерею выиграть, цифры не помню уже.
> Если посчитаете вероятность, там не так уж и мало окажется.
Одновременно. На половине дисков массива. Да еще и так, чтобы повредить одни и те же данные. И при этом чтобы мониторинг не поднял тревогу, когда начали появляться первые бэды на одном из дисков? Верится с трудом.
> Вот, к примеру, ещё аж 2009 года:
> geektimes.com/post/78311
1. Там про 5, 2. Там как раз таки рекомендуют 6.
И, кстати, можете немного раскрыть мысль на тему «перестанет хватать»?
Одновременно. На половине дисков массива. Да еще и так, чтобы повредить одни и те же данные. И при этом чтобы мониторинг не поднял тревогу, когда начали появляться первые бэды на одном из дисков? Верится с трудом.
> Вот, к примеру, ещё аж 2009 года:
> geektimes.com/post/78311
1. Там про 5, 2. Там как раз таки рекомендуют 6.
И, кстати, можете немного раскрыть мысль на тему «перестанет хватать»?
> И, кстати, можете немного раскрыть мысль на тему «перестанет хватать»?
Я к тому, что немного непонятно. Надежность у 6 очень неплохая, а если скомбинировать с другими типами — то можно еще чуть повысить.
Про другие типы, да, там надежность меньше. Но это таки лучше чем голые диски as-is.
Я к тому, что немного непонятно. Надежность у 6 очень неплохая, а если скомбинировать с другими типами — то можно еще чуть повысить.
Про другие типы, да, там надежность меньше. Но это таки лучше чем голые диски as-is.
Ну статья же начала 2010 года :(
С тех пор и отдельные диски надежнее стали, и всякие навороченные СХД подоспели. Ну и автор какие-то странные предположения и выводы делает, на мой взгляд (там в комментах эта тема раскрыта).
С тех пор и отдельные диски надежнее стали, и всякие навороченные СХД подоспели. Ну и автор какие-то странные предположения и выводы делает, на мой взгляд (там в комментах эта тема раскрыта).
Диски стали заметно менее надёжными. Откуда предположение об обратном? Математика с 2010 года не изменилась, вероятности считаются также.
> Диски стали заметно менее надёжными. Откуда предположение об обратном?
А откуда у вас предположение об обратном? :)
Мое основано на совершенствовании техпроцессов и физики/материалов. А ваше?
Ну и не говоря уже об совершенствовании в программной части контроллеров и софта.
И по поводу математики/вообще расчетов — вы комменты читали?
А откуда у вас предположение об обратном? :)
Мое основано на совершенствовании техпроцессов и физики/материалов. А ваше?
Ну и не говоря уже об совершенствовании в программной части контроллеров и софта.
И по поводу математики/вообще расчетов — вы комменты читали?
Вы мои каменты не читаете. У меня не предположение об обратном, а твёрдая уверенность, основанная на практике, как у человека, работающего в индустрии восстановления данных.
Материалы/техпроцессы совершенствуются в первую очередь в сторону увеличения плотности хранения информации. Падающая надёжность компенсируется увеличением количества запасных треков/страниц.
По поводу математики какой-либо конкретики в комментах не видел, укажите пожалуйста, если пропустил.
Материалы/техпроцессы совершенствуются в первую очередь в сторону увеличения плотности хранения информации. Падающая надёжность компенсируется увеличением количества запасных треков/страниц.
По поводу математики какой-либо конкретики в комментах не видел, укажите пожалуйста, если пропустил.
Уменьшение нагрева, улучшение материалов блинов/покрытия, другие принципы записи/чтения, не?
По поводу остального.
URE 10^14 — это одна ошибка чтения на ~12TB.
Сейчас же URE, как показывает легкий гуглинг, уже порядка 10^15, т.е. одна ошибка чтения на ~114ТB.
И это статистические значения, а не гарантированные. И это без учета, например, зеркалирования в массиве.
Вот тут у меня основные претензии к автору.
По поводу остального.
URE 10^14 — это одна ошибка чтения на ~12TB.
Сейчас же URE, как показывает легкий гуглинг, уже порядка 10^15, т.е. одна ошибка чтения на ~114ТB.
И это статистические значения, а не гарантированные. И это без учета, например, зеркалирования в массиве.
Вот тут у меня основные претензии к автору.
Не понял при чём тут зеркалирование. Автор как раз и вычисляет вероятность сбоя в работе массива на основе значений URE.
> When a drive fails in a 7 drive, 2 TB SATA disk RAID 5, you’ll have 6 remaining 2 TB drives. As the RAID controller is reconstructing the data it is very likely it will see an URE.
Вот при этом. У него в расчете raid5. В случае, например, простейшего raid1 (или даже raid6) все будет интереснее.
Сейчас еще перечитал, и вот с этим тоже как-то не очень:
1. «Which means that once every 200,000,000 sectors, the disk will not be able to read a sector.» — читаем же блоками, а не секторами. Тут правильнее оперировать BER (которое _не менее_ (а не ровно и гарантированно) 1 на 10^14-10^15 bits для HDD и, похоже, до 10^18 в enterprize мире). Т.е. дальше все расчеты начинают напоминать гадание, т.к. BER _точно_ не известно, а есть _не менее_ (как и пишут в датащите).
2. Автор исходит из предположения, что вот у нас упал один диск в массиве, мы поставили свежий, и при ребилде начинается _полное_ чтение всех дисков в массиве, что не верно. Плюс к этому, даже в таком случае, насколько я помню вышку, вероятности наступления независимых событий (на 6 независимых дисках) нужно считать иначе (с учетом как минимум времени и количества прочитанного с каждого диска).
Вот при этом. У него в расчете raid5. В случае, например, простейшего raid1 (или даже raid6) все будет интереснее.
Сейчас еще перечитал, и вот с этим тоже как-то не очень:
1. «Which means that once every 200,000,000 sectors, the disk will not be able to read a sector.» — читаем же блоками, а не секторами. Тут правильнее оперировать BER (которое _не менее_ (а не ровно и гарантированно) 1 на 10^14-10^15 bits для HDD и, похоже, до 10^18 в enterprize мире). Т.е. дальше все расчеты начинают напоминать гадание, т.к. BER _точно_ не известно, а есть _не менее_ (как и пишут в датащите).
2. Автор исходит из предположения, что вот у нас упал один диск в массиве, мы поставили свежий, и при ребилде начинается _полное_ чтение всех дисков в массиве, что не верно. Плюс к этому, даже в таком случае, насколько я помню вышку, вероятности наступления независимых событий (на 6 независимых дисках) нужно считать иначе (с учетом как минимум времени и количества прочитанного с каждого диска).
Ну и я еще забыл про некоторую избыточность данных на современных ФС.
Вот вы лично когда последний раз ловили URE? Я вот где-то лет так примерно 8 назад, емнип на 120 или 320Г ноутбучном винте.
И еще хочется добавить про вашу практику — вот это как раз и есть та статистика. Миллионы работают нормально, а случайные единицы ловят проблемы.
Вот вы лично когда последний раз ловили URE? Я вот где-то лет так примерно 8 назад, емнип на 120 или 320Г ноутбучном винте.
И еще хочется добавить про вашу практику — вот это как раз и есть та статистика. Миллионы работают нормально, а случайные единицы ловят проблемы.
А программная часть эволиционирует в сторонну удешевления разработки.
Диск наполненный, постоянно утекающим, гелием надёжнее?!
Cтатью, на которую хотел сослаться, не нашел, но оказалось, что есть и другие на ту же тему. Вот, к примеру, ещё аж 2009 года:
geektimes.com/post/78311
geektimes.com/post/78311
Всю статью можно уместить в:
"Что делать, чтобы сохранить данные
- Резервное копирование."
Забавляют инструкции для техники apple:
- Копируйте
- Замените
Невероятно сложная последовательность действий, спасибо)
Sign up to leave a comment.
Apple Fusion Drive, сохранение данных при замене жесткого диска