Pull to refresh
86
0.1
Артемий @Sap_ru

User

Send message
Не правда ваша. В Raid0+1 у вас осталось три диска из них два — хранят одинаковые данные. Какова вероятность потерять весь массив? Вероятность выше чем в RAID5, т.к. потеря диска с уникальными данными однозначно приводит к потере массива. Плюс, вероятность потери дублирующихся данных.
Это я к тому, что нельзя вот так однозначно утверждать :)
имеется в виду ёмкость одного диска.
Не просто и не только контрольная сумма! Там Циклическая контрольная сумма с коррекцией ошибок! да старых добрый винтах в пределах сектора гарантировалось исправление одиночных ошибок и обнаружение сдвоенных! На современных будет уместно считать, что исправляются все двойные ошибки и обнаруживаются все тройные и четверные!
С таким подходом нужно не RAID пользоваться, в иконы по стенам вешать и святой водой запасаться.
Ещё раз — Вы это с чего взяли? Почитайте определение BSR по вашей же ссылке. Это вероятность ошибочного чтения бита головкой. Дальше идёт могучая коррекция ошибок. Вероятность некорректируемой или необнаружимой ошибки будет неизмеримо меньше. Вам нужно чтобы в пределах одного сектора произошли множественные ошибки. При этом вероятность одной ошибки ~10^14. Вероятность двух ошибок подряд ~10^28. При этом такая ошибка будет однозначно скорректирована. даже если произойдёт некорректируемая ошибка, то она с большой вероятностью будет обнаружена, т.к. алгоритмы коррекции позволяют определять больше ошибок, чем корректировать. Произойдёт повторное чтение данных. Короче говоря, нужно, чтобы при множественных повторных чтениях возникали некорректируемые ошибки, либо, чтобы чтобы произошла намного (на десятки порядков!) менее вероятная необнаружимая ошибка. Сдаётся мне, что вероятность такого события приближается к вероятности пролёта заряженной частицы через кристалл процессора.
С фигли? С чего это у них совпала контрольная сумма? Какова вероятность такого совпадения? Куда делись алгоритмы коррекции множественных ошибок? Одиночный бит вообще никаким образом не может повредиться данные где бы ни произошла ошибка. И два бита тоже. А теперь посчитайте вероятность одновременного отказа трёх битов в одном секторе. Да ещё чтобы это было воспроизводимо при повторном чтении.
«Это вероятность сбоя, из расчета некоего объема прочитанных головками диска бит»
Вы чувствуете разницу между «считанными головками» и «выданную жёстким диском»?
Практически все нормальные контроллеры умеют работать с RAID на скорости чтения, т.е. время ребилда будет равно таковому для RAID1. Нормальные контроллеры — это те, которые не нагружают ЦП.
Куда делась многоуровневая коррекция данных?!
Более того, она будет парирована коррекцией ошибок.
От подобных вещей не спасёт никакой RAID — только резервные копии.
На самом деле меньше. Вы не учитываете множественных отказов. Но не на много.
После потери одного диска у RAID10 остаётся три диска, а у RAID5 — два. Где вероятность отказа больше?
Опять же, какова вероятность сдохнуть 2-ум винтам за время восстановления RAID?
Посчитайте вероятность.
Можете просто прикинуть из соображений здравого смысла какая вероятность больше — отказа одного диска из 4-х или одного диска из 3-х?
RAID10 не более надёжен, чем RAID5.
Что-то как-то весьма хрень.
Массив RAID1 объёмом 1TB тоже будет восстанавливаться часов 5-10. Это раза в четыре меньше чем RAID5. Если же применяется «честный» контроллер RAID5 с восстановлением «на лету», то он по производительности практически не будет отличаться от RAID1. Более того, он ещё и имеет все шансы обогнать RAID1. Да, он денег стоит. Но тут уж или восстанавливаться двое суток или денежку платить.
По надёжности тоже как-то не понятно. Честный RAID5 быстрее чем один диск на линейный операциях при более высокой надёжности. RAID1 — надёжнее, но медленнее чем RAID5. RAID0 — быстрее но намного менее надёжен, чем RAID5. RAID10 — быстрее, но всё ещё менее надёжен, чем RAID5. Отсюда получаем, что RAID5 — хороший компромис между надёжности и быстродействием. А рассказы о том, что на время восстановления он, о ужас! теряет в надёжности можно отнести к любому RAID с небольшим количеством дисков. И почему-то не рассматривается вариант RAID5+1, который даёт полное счастье. Однако, есть мнение, что в большинстве случаем более оптимальным будет хранение бэкапов на отдельном массиве.
Короче говоря, а какой смысл-то? Всем сидеть на RAID10 и пожертвовать надёжностью?
Люди, они порочны по своей сути. Например есть у меня коллега. Его отец владеет небольшим заводиком, который выпускает всякую мелочь — рамы и т.п.
Нам, как наверное и любой конторе, приходит масса спама по всем каналам — от горы писем по e-mail каждому, до регулярных навязчивых звонков с предложением купить/рекламировать/консультировать. Конечно же это очень раздражает и отвлекает и каждый уже много раз высказался о том, как ненавидит всех этих спамеров.
И вот, однажды, приходит этот товарищ и начинает упорно искать базу телефонов разных фирм. начинаем спрашивать зачем.
— Ну, мы с отцом будем их обзванивать и предлагать свои услуги. А то у нас такой товар классный, а никто не знает!
— Так это же спам! Ты же сам тут орёшь и материшься в трубку, когда тебе звонят с предложениями купить слона!?
— Нет нет! Это не спам! У нас правда классная продукция. это ж не какое-то говно. Кто-то навеняка подобное ищет и не может найти! Вот, мы на той неделе сто двадцать фирм обзвонили и нашли двух заказчиков. Они такие довольные теперь!
И переубедить не возможно. Такая логика встречается на каждом углу — все спамеры и говно впаривают, а мы белые и пушистые, потому, как у нас продукция всем нужная, просто никто о ней не знает, но очень хочет узнать.
Нужен там, где нужна портативность при высоком ресурсе. Принтеры с тонером — большие. Принтеры с чернилами или большие или нужно часто менять картридж. А здесь сам принтер очень небольшой, а весь ресурс вынесен в одноразовую бумагу. Например подойдёт для печати всякого рода пропусков и фотографий на документы в «полевых» условиях.
Ну, так просто не нарушат. Зачем портить репутацию. Если и будут нарушать, то долго и подпольно.
Ну, молодцы Oracle. Наверняка заранее определили на какие обязательства могут пойти, но всячески старались этого избежать. В принципе вполне вменяемая политика — зачем лишние обязательства по спорному (для Oracle) продукту. А как только ситуация стала угрожать репутации компании сразу всё это достали и обнародовали. Очень вменяемая и грамотная политика. И сообщество тоже молодцы успели вовремя поднять достаточную шумиху, чтобы надавить на Oracle. Скорее всего и без этих обещаний ничего с страшного для MySQL не было бы, но так спокойнее.

Information

Rating
3,497-th
Location
США
Date of birth
Registered
Activity