Нейл Браун (Neil Brown), основной разработчик пакета mdadm и подсистемы для обеспечения работы программных RAID-массивов в Linux, опубликовал (http://neil.brown.name/blog/20120615073245) предупреждение о выявлении серьёзной ошибки в md/raid, которая может привести к обнулению важных мета-данных на дисках, входящих в программный RAID. Например, может быть очищена информация о массиве, о смещениях данных, размерах блоков и роли каждого диска в массиве. Всем пользователям рекомендуется первым делом сохранить на внешнем носителе вывод команды "mdadm -Evvvvs", для обеспечения возможности восстановления в случае проявления ошибки (для восстановления достаточно пересоздать массив через "mdadm --create" с теми же параметрами).Проблема присутствует в ядрах Linux с 3.4-rc1 по 3.4-rc4, с 3.3.1 по 3.3.3 и с 3.2.14 по 3.2.16. В ядра некоторых дистрибутивов также был портирован код, приводящий к ошибке: в SLES11-SP2 проблеме подвержены ядра 3.0.26-0.7 и 3.0.26-0.8, в Ubuntu - с 3.2.0-22.35 по 3.2.0-24.37. Ошибка проявляется только при перезагрузке, выключении или аварийном завершении работы. В процессе штатного функционирования проблема не всплывает. Ошибка возникает в ситуации, когда в процессе завершения работы массив находится в частично собранном и остановленном состоянии, что может возникнуть, например, при использовании команд "mdadm --incremental" или "mdadm -A". В частности, опасное стечение обстоятельств может наблюдаться в Ubuntu, когда в процессе завершения работы скрипт остановки RAID массива пересечётся с работой udev-скрипта, выполняющего "mdadm --incremental".
Для исключения проявления ошибки в процессе обновления подверженного проблеме ядра рекомендуется перед перезагрузкой убедиться в отсутствии частично собранных RAID-разделов. Например, рекомендуется перед перезапуском выполнить команды "mv /sbin/mdadm /sbin/mdadm.moved; /sbin/mdadm.moved --stop --scan", после чего загрузиться с новым ядром в одиночный режим и восстановить переименованный файл "mv /sbin/mdadm.moved /sbin/mdadm".
URL: http://neil.brown.name/blog/20120615073245
Новость: http://www.opennet.ru/opennews/art.shtml?num=34131
Афигеть мой конфиг, бегу...
Дебиана 6 с ядром из 3,2 бэкпортов (конкретно версия непонятно какая, Apt скрывает) касается?
[correctmode]
И как всегда ошибку нашёл сам разработчик, а не некий аноним, читающий исходники
> ночью. В очередной раз миф о том, что открытые исходники позволяют
> найти ошибки, развалился на глазах. С таким же успехом разработчик закрытой
> системы находит ошибки, без лишней лапши о чтении исходников всеми.[/correctmode]
Аноним читающий по ночам исходники - это миф выдуманный ниспровергателями мифа и не имеющий отношения к действительности.
Ошибки отлавливаются чаще всего разработчиками. Существенно то, что возможность стать разработчиком открыта для любого. И код читают не анонимы, а те, кто предполагает модифицировать код для некоторых своих потребностей либо для того, чтобы уяснить для себя особенности работы системы для всяческих отстраивания под те или иные нужды.
Далее - вероятности обнаружения. У изначального разработчика не забрасывающего поддержку написанного кода вероятность обнаружения ошибки выше. Особенно если ошибка проявляется в довольно редких условиях. Но это же не делает невероятным выявление ляпов кем-то другим.
> читающий по ночам исходникичитающий исходники после того как его софтрейд внезапно помер
FIXED
> Аноним читающий по ночам исходники - это миф выдуманный ниспровергателями мифаНе обращайте вминания, это было выступление пользователя Apple, который даже не сообразил, что обнаружение, диагностика, исправление и анонс -- это четыре разных вещи.
> Далее - вероятности обнаружения.
Around 3.0/3.1 people started reporting this bug being triggered at shutdown.
> Особенно если ошибка проявляется в довольно редких условиях.
Надо же, убунтушники приложили свои усилия к тому, чтобы эти условия были менее редкими...
> В очередной раз миф ... развалился на глазахХорошая оговорка. Миф может развалиться только один раз, а если он разваливается "в очередной раз", то, видимо, у разваливателей "мифа" кишка тонка
Почему "как всегда" и что за аноним?
О, ты много знаешь людей способных понять код драйверов для RAID?
Да в общем похрену какой код разбирать. Если задаться целью, то желаемое становится действительностью и этот случай не исключение. Некоторые требуемые навыки и опыт ни кто не отменял, впрочем они не зависят от контекста исследований. И да, в чем отличие кода поддержки RAID от простого и обычного кода всего остального?
"Простой и обычный код" звучит как "обычный стиральный порошок". Не бывает такого кода, разве что в лабораторных работах у студентов.
Это и должно так звучать. Код есть код и нечего его делить на код RAID, VM или еще какой.
> Код есть код и нечего его делить на код RAID, VM или еще какой.Что, серьёзно? А вот для народа в lkml, помнится, страшнее VM бывал разве что tty.c ;-)
Свой код тоже очень разный -- иной и через десять лет прозрачен, а иной не узнаёшь. Ваш-то есть где посмотреть?
> "Простой и обычный код" звучит как "обычный стиральный порошок".
> Не бывает такого кода, разве что в лабораторных работах у студентов.Вот не видели вы работ студентов. Там как раз код необычный (уж проще разбирать драйвер, чем некоторые их работы).
> О, ты много знаешь людей способных понять код драйверов для RAID?С учётом того, что начинал его Мигель -- думаю, достаточно много. Это всё-таки не VM...
> В очередной раз миф о том, что открытые исходники позволяют найти ошибки развалился на глазах.Откуда вы такой отборный маркетинговый буллшит берете? От того что сорц посмотрит не только разработчик но и еще 100500 человеков - хуже не станет. А вот лучше - может. И багтрекеры багами заполнены явно не только от разработчиков. Врядли бы разработчики наколотили столько багов :)
Да, только баги не от чтения исходников там, а от ой, мой рейд рассыпался при перезагрузке!
> Да, только баги не от чтения исходников там, а от ой, мой
> рейд рассыпался при перезагрузке!Баги багам рознь. Бывают и [PATCH] с хорошим внятным разбором полётов впридачу.
Разработчик нашёл ошибку. Вы из этого сделали вывод о том, что сообщество не может находить ошибки. Вам не кажется, что у вас проблемы с логикой?..Разработчик может найти ошибку, может её не найти. Кто-то из пользователей может найти ошибку, а может также её не найти. То есть возможны разные сценарии. Но вы, увидев реализацию одного из них, делаете вывод, что другой принципиально невозможен...
Во время чтения новости стало очень очень страшно!!!
я правильно понял, что если стоит gentoo-source-3.4.2-r1 то можно расслабиться?
Можно. Расслабляйся.
Unstable система? "Расслабься и получай удовольствие" ))
Если мое предположение верно, что "аппаратный RAID" является на самом деле програмным RAIDом, только с программой в ПЗУ, то выходит, что и аппаратные подвержены этой ерунде.И возможно, это и было причиной, по которой в течение года оба моих RAID-контроллера при включении компьютера вдруг забывали, что диски должны быть зазеркалированы и сбрасывали свои настройки.
Аппаратный рейд - это вообще несколько большее. Это самостоятельный контроллер, и там могут быть разнообразные плюшки, вплоть до дополнительного питания носителей в том случае, если и основной источник питания, и даже бесперебойники откажут - все равно кэш на диски будет записан, а носители корректно остановлены. Что же до сохранности данных - тут раз на раз не приходится. У нас, например, был чудный аппаратный контроллер, после пары лет работы в массиве которого ЖД можно было просто выкидывать на помойку - они все были усеяны бэдами и областями затрудненного чтения. Не стали разбираться, что с ним - просто выкинули. Так что всякое бывает - где-то mdadm навернется, а где-то и аппаратный рейд. Мораль? Делайте бэкапы всегда.
> Аппаратный рейд - это вообще несколько большее. Это самостоятельный контроллер, и там
> могут быть разнообразные плюшки, вплоть до дополнительного питания носителей в том
> случае, если и основной источник питания, и даже бесперебойники откажут -
> все равно кэш на диски будет записан, а носители корректно остановлены.Можно пример такого контроллера? Потому-что обычно батарейка для сохранности данных в кэше.
EMC CLARiiON. В SPE там обычно пара таких.
> Аппаратный рейд - это вообще несколько большее. Это самостоятельный контроллер..По сути обычный программно-аппаратный комплекс "от производителя" с соответствующими гарантиями. Ошибки могут быть и в программной и в аппаратной части. Тут больше вопрос доверия/гарантий и предоставляемых возможностей. Вот интересно как контроллер мог повлиять на развитие бед блоков на ЖД. Вменяемых объяснений не вижу.
> Вот интересно как контроллер мог повлиять на развитие бед блоков на ЖДпримерно аналогичным образом - http://forum.ixbt.com/topic.cgi?id=11:38813
причем это не такая большая редкость, во всяком случае на дешевых материнках, когда контроллер тянет за собой hdd.
Конечно в аппаратных RAID массивах есть софт, а как же иначе? Другое дело что софт для этих контроллеров пишут не энтузиасты, а отдельные группы людей. Ну и многолетняя отладка... В итоге всё очень надежно. Ну и цена соответсвующая ;)В ноунейм контролерах и линуксах такого нет, поэтому потери данных или как у вас, забывали про массивы и диски. Зато недорого или даже бесплатно ;)
Вы не поверите, но в линуксе рейд тоже пишут группы людей, и отлаживают много лет, и в результате все очень надежно.
И если подобные ошибки проскакивают и в линуксе - то они точно так же могут оказаться и в любом аппаратном рейде. Особенно, если там прошит урезанный линукс, что случается очень часто.
> Вы не поверите, но в линуксе рейд тоже пишут группы людей, и
> отлаживают много лет, и в результате все очень надежно.
> И если подобные ошибки проскакивают и в линуксе - то они точно
> так же могут оказаться и в любом аппаратном рейде. Особенно, если
> там прошит урезанный линукс, что случается очень часто.Зачем контроллеру RAID куча всякой х..ни, поддерживаемой линуксом и абсолютно бесполезной для такого рода задач? Приведите доказательства.
Потому что дешевле вкрутить линукс чем разрабатывать свою фирмварь - по крайней мере до определённых масштабов производства.
> Зачем контроллеру RAID куча всякой х..ни, поддерживаемой линуксом и абсолютно бесполезной
> для такого рода задач? Приведите доказательства.Ну например для реализации графической управлялки контроллером, с шахматами и поэтессами...
Не поверите в IBM 3560 торчит какой-то LSI SAS-RAID и там именно так и сделано. Для особо желающих можно загрузить CLI-утиль... И все это из фирмвары контроллера. Что у ней в потрохах - х.з. не ковырял, мне ни к чему...
> Другое дело что софт для этих контроллеров пишут не энтузиасты, а отдельные группы людей. Ну и многолетняя отладка... В итоге всё очень надежно.
> В ноунейм контролерах и линуксах такого нет, поэтому потери данных или как у вас, забывали про массивы и дискито-то я смотрю - в оффтопОС все так прям и используют программный рейд. все потому-что над кодом работают "отдельные группы людей" и "В итоге всё очень надежно"
Кстати, если-бы "забывание" дисков в mdadm было бы обычной ситуацией, как вы сейчас пытаетесь представить, об этом уже давно было бы известно, и это давно было бы пофикшено, а значит этого давно небыло бы.
> Другое дело что...формат данных на дисках пока не стандартизирован между различными поставщиками hardware RAID и можно вляпаться в поиски такого же контроллера, если не был куплен сразу дублёр.
> софт для этих контроллеров пишут не энтузиасты, а отдельные группы людей.
Звучит ну очень солидно для тех, кто никогда не создавал такие группы (и не пользовался аппаратными рейдами), угу.
Если в команде нет энтузиастов -- выходит очередной серенький продукт без искорки.
> Ну и многолетняя отладка... В итоге всё очень надежно. Ну и цена соответсвующая ;)
Цена формируется в основном маркетинговыми соображениями, а вовсе не чем-то разумным.
> В ноунейм контролерах и линуксах такого нет, поэтому потери данных или как
> у вас, забывали про массивы и диски. Зато недорого или даже бесплатно ;)Можно поинтересоваться Вашим стораджевым опытом? А то такое противопоставление смотрится довольно смешно, если хотя бы немного понимать tradeoff'ы аппаратного и чисто программного вариантов. В том числе затруднительность даже прокачать, не то что от'xor'ить, более десятка дисков на иных контроллерах.
У аппаратных рейдов есть замечательные плюсы, но это вовсе не повод ползать перед ними на коленках. Точно так же и с софтовыми.
PS: http://www.springerlink.com/content/5bqqcqhgcd5appg4/ ;-)
Миша, ты мой герой! )
Редко пользуемся убунтой на серверах (выбираем Debian и CentOS во имя стабильности), но даже там, где она используется, можно спокойно обновиться до 3.2.0-25. Ребутнуться пришлось, это да. Но не критично.
ну зашибись блин, токо сделал файл-сервер на убунте с RAID-1, даже запустить не успел, а тут такие печеньки... Правильно я понял, что достаточно будет откатиться на ядро 3.0 ?
> ну зашибись блин, токо сделал файл-сервер на убунте с RAID-1, даже запустить
> не успел, а тут такие печеньки... Правильно я понял, что достаточно
> будет откатиться на ядро 3.0 ?В процессе штатного функционирования проблема не всплывает.
> В процессе штатного функционирования проблема не всплывает.Только при выключении и перезагрузке, ага.
> Массив остановлен, и мы его берём и повреждаем. Молодца!Читать надобно внимательней.
"в частично собранном и остановленном состоянии"
В русском языке союзы "и" и "или" в большинстве контекстов имеют различное значение. В данном контексте они как раз не совпадают и речь идет о выполнении обоих условиях.
Надо постараться чтобы выполнить.
Из того же второго абзаца:
"
В частности, опасное стечение обстоятельств может наблюдаться в Ubuntu, когда в процессе завершения работы скрипт остановки RAID массива пересечётся с работой udev-скрипта, выполняющего "mdadm --incremental".
"Тут наверное как раз говорится про обычные штатные механизмы завершения работы. Так что не словоблудьте. И не начинайте рассказывать что настоящие сервера у настоящих админов никогда не выключаются
> Из того же второго абзаца:
> "
> В частности, опасное стечение обстоятельств может наблюдаться в Ubuntu, когда в процессе
> завершения работы скрипт остановки RAID массива пересечётся с работой udev-скрипта, выполняющего
> "mdadm --incremental".
> "
> Тут наверное как раз говорится про обычные штатные механизмы завершения работы. Так
> что не словоблудьте. И не начинайте рассказывать что настоящие сервера у
> настоящих админов никогда не выключаютсяНу, конечно. Такое тоже может быть. Админ не дождавшись загрузки сервера резко начал его глушить и умудряется попасть в славный промежуток времени когда массив еще не собран. Админы от общения с тупыми юзерами порой бывают очень нервными и могут порой совершать необдуманные действия. А чего только спьяну не вытворяют... Мне как-то рассказывали байку о том, как мужички спьяну решили проверить водяное охлаждение обдувая корпус строительным феном.
Но, я полагаю, что админ с трясущимися от раздражения руками - уже не совсем штатное явление. :-)
Кстати и выбор убунту в качестве файл-сервера повышенной надежности... Можно конечно... Всё можно, если вдумчиво и без нервных телодвижений. Я Вам такую ересь скажу (тихооонько), что изрядно зарядившись флегматизмом и с виндами можно что-то достаточно надежное делать, хотя зачастую и муторно от этого.
...короче, обновил ядро до 3.4, автор пишет, что оно не подвержено багу. Да и вообще, т.к. сервак еще не запущен, то и терять было пока нечего. Но новость, конечно, не из приятных.
мда. жесть конечно. хорошо что я не стал обновлять домашнюю файлопомойку до новой убунты, на моём 2.6.38 как я понял бага нет
Там уже пофикшеное ядро в новой Убунте, да и ещё постараться нужно, чтоб сломать.
Уверены что у вас вообще рэйд есть?
> Уверены что у вас вообще рэйд есть?root@rain87gw:~# cat /proc/mdstat
Personalities : [linear] [multipath] [raid0] [raid1] [raid6] [raid5] [raid4] [raid10]
md0 : active raid5 dm-2[0] dm-1[1] dm-0[2]
1953517952 blocks level 5, 64k chunk, algorithm 2 [3/3] [UUU]
unused devices: <none>странный вопрос, я даже не понял - это такой тонкий^W толстый троллинг?
> Ошибка возникает в ситуации, когда в процессе завершения работы массив находится в частично собранном и остановленном состоянии, что может возникнуть, например, при использовании команд "mdadm --incremental" или "mdadm -A". В частности, опасное стечение обстоятельств может наблюдаться в Ubuntu, когда в процессе завершения работы скрипт остановки RAID массива пересечётся с работой udev-скрипта, выполняющего "mdadm --incremental".Судя по всему, проблема специфична только для систем на базе upstart, т.е. Ubuntu и RHEL6 (с клонами).
В sysvinit, systemd и openrc эти операции не распараллеливаются.
> Судя по всему, проблема специфична только для систем на базе upstart, т.е.
> Ubuntu и RHEL6 (с клонами).Хотя нет, для RHEL тоже не специфична (они не стали бэкпортировать этот патч в свое ядро).
Остается только убунта.
>> Судя по всему, проблема специфична только для систем на базе upstart, т.е.
>> Ubuntu и RHEL6 (с клонами).
> Хотя нет, для RHEL тоже не специфична (они не стали бэкпортировать этот
> патч в свое ядро).
> Остается только убунта....а в ней обновление до 3.2.0-25 в репах. Остается SLES?
> ...а в ней обновление до 3.2.0-25 в репах. Остается SLES?SLES уже перевели на upstart?
часом не та ошибка, которая селектеловское облако клала?
Нет. Ту ещё не исправили.
печально
> печальноЭто Ваня. Рассматривайте его как генератор случайных чисел скрещенный с миллионом обезьян пишущий войну и мир (примерная схема-эквивалент, продуцирующая такой же бред на выходе).
>часом не та ошибка, которая селектеловское облако клала?Опередил :)
В очередной раз стало ясно, что использовать дистрибутивы с красноглазыми ядрами себе дороже, только RHEL/CentOS/EL!
Стремно на сервер ставить даже Debian/Ubuntu, но нет же, находятся "самородки", которые водружают туда Арч или даже Генту!Очень зря в SLE теперь не своя ветка, как раньше, а как у всех красноглазые большие номера ядер!
> Стремно на сервер ставить даже Debian/Ubuntu, но нет же, находятся "самородки", которые
> водружают туда Арч или даже Генту!Вы полагаете, что разницы между дебиан и убунту нет? Ну-ну...
Дебиан-то чем не угодил в данном случае?
:DСтрёмно на сервер ставить то, чем не умеешь управлять.
Вот почему у меня под арчем отваливаются только бинарный видеодрайвер NVIDIA и медиаплеер, да и то иногда и на десктопе, а? :)
> Ошибка
> проявляется только при перезагрузке, выключении или аварийном завершении работы. В процессе
> штатного функционирования проблема не всплывает. Ошибка возникает в ситуации, когда в
> процессе завершения работы массив находится в частично собранном и остановленном состоянии,И не ясно - ЧТО за народ поднял панику в комментах?
Дисковый массив все же более характерен для сервака.
Сервак предполагает все же что даже перезагрузку на нем выполняет не "марьиванна", а более-меннее админ. У более-менее админа, как бы предполагается, что сервак с серьезным содержимым сидит на бесперебойнике способном поддержать хотя бы корректное завершение работы.
Админ у которого сервак при недособранном массиве может экстренно вылететь - мудак, а не админ. Если не мудак, то такое может произойти при диковинном стечении обстоятельств - например, именно в описанной ситуации накрылся бесперебойник + сбойнуло питание.
Да прочти ты уже наконец:
"В частности, опасное стечение обстоятельств может наблюдаться в Ubuntu, когда в процессе завершения работы скрипт остановки RAID массива пересечётся с работой udev-скрипта, выполняющего "mdadm --incremental". "
Это штатное завершение работы, в котором тебе может повезти или не повезти (пересекутся два скрипта или нет)
не дописал, вдогонку - ведь при обычной физической перезагрузке, которую ты только и подразумеваешь ("сбойнул бесперебойник + пропало электричество", про которые ты писАл выше), скрипты завершения выполняться не будут. Это и есть корректное завершение работы, которое на самом деле не всегда корректно - как повезет
> А паника из-за того что RAID "зеркало" собирают как раз для повышения
> надёжности хранения данных, а не наоборот. Жаль что разработчики это не
> до конца понимают.Для повышения надежности хранения данных предпринимается КОМПЛЕКС мероприятий одним из которых может быть и использование массива. Те, кто этого не понимает оказываются наказанными по жизни и могут сколь угодно долго лепить отговорки о ненадежности железа, линей, винды и т.д.
Вы не совсем поняли. В оригинале говорится, что даже при корректном завершении работы может возникнуть описанное автором состояние, при котором и проявляется баг.
> Вы не совсем поняли. В оригинале говорится, что даже при корректном завершении
> работы может возникнуть описанное автором состояние, при котором и проявляется баг.Это Вы не совсем поняли. В оригинале говорится, что баг словили только убунтушники, из-за того что в ней при загрузке делается incremental assembly по udev rules 85-mdadm.rules, в результате чего и становилось возможным через этот баг повреждение метаданных, если перезагрузка происходила раньше, чем массив полностью собирался.
Да, в целом так. Кстати русский сабж довольно корректно и по существу описал ситуацию равно как и меры по предотвращению.
Беда в том, что использование некоторых конфигураций системы предполагает продуманного подхода и некоторых мероприятий по их администрированию и поддержанию. Даже существование средств построения таких конфигураций с визуальным дружественным интерфейсом понятным для школьников не обозначает освобождения от вдумчивого планирования таких конфигураций. Дисковые массивы в любом случае строить надобно весьма продуманно в сочетании с прочими мероприятиями. Ну а когда по ряду причин массивы стали все чаще выставлять на обычных настольных компах не шибко задумываясь о специфике работы с ними, то начали вылетать веселый последствия.
Да стоит посмотреть на панические комменты здесь. По их содержанию создается впечатление, что авторы просто раскопали рецепт создания массива, применили не шибко разбираясь в том, что это такое, а потом услышав о потенциальных проблемах не разобравшись в сути проблемы и опять же не желая разобраться в том, что они там себе понаустанавливали, готовы метнуться чего-то переустанавливать отменять и переделывать.
Ну и под шумок нашлись те, кто рад потроллить на тему превосходства винды или наоборот линей. Такое впечатление, что никто из них не слышал и не осознает того, что надежность системы редко совпадает с надежностью её частей, что система в целом может иметь и более высокую надежность и менее высокую.
>> Вы не совсем поняли. В оригинале говорится, что даже при корректном завершении
>> работы может возникнуть описанное автором состояние, при котором и проявляется баг.
> Это Вы не совсем поняли. В оригинале говорится, что баг словили только
> убунтушники, из-за того что в ней при загрузке делается incremental assembly
> по udev rules 85-mdadm.rules, в результате чего и становилось возможным через
> этот баг повреждение метаданных, если перезагрузка происходила раньше, чем массив полностью
> собирался.А где Вы в моем посте углядели отрицание того, "что баг словили только убунтушники". Отличный стиль вести дискуссию - выдумать аргумент оппонента и с пеной у рта его опровергать. К тому же писал я вовсе не Вам...
> А где Вы в моем посте углядели отрицание того, "что баг словили
> только убунтушники". Отличный стиль вести дискуссию - выдумать аргумент оппонента и
> с пеной у рта его опровергать. К тому же писал я
> вовсе не Вам...Так будьте бобры в следующий раз не говорить с недоговорками. Есть чёткое определение когда проявляется баг: остановка частично собранного активированного массива, и всё.
Не на эту ли ошибку напоролся в свое время Selectel?
У меня стоял kernel 3.3.3 на slackware 13.37 x86_64 и программный RAID0
Множество раз перезагружал/выключал, а так же сбои от света и т. д. - выжил.
Сейчас пересобрал новое ядро 3.4.3.
Всё работает так же.
Единственное, что, так это VirtualBox не собирал модули ядра, пришлось линк поставить на один include файл, видать место положение этого файла сменилось в новом ядре.
> У меня стоял kernel 3.3.3 на slackware 13.37 x86_64 и программный RAID0
> Множество раз перезагружал/выключал, а так же сбои от света и т. д. - выжил.Так если RAID0, целостность данных всё равно имеет весьма условное значение -- с учётом того, что винчестеры уж лет пятнадцать как пытаются стать расходниками. :(
Ну... Они, конечно, пытаются, но не то чтобы очень успешно. Во всяком случае я не вижу чтобы отказов было больше сейчас чем лет 10 назад. Скорее уж наоборот - тогда те же самсунги были "чудесны", да и эпичные проблемы с "дятлами" и фуджиками вспоминаются.
Да уж! Как вам только живётся в прошлом веке с деревянными игрушками, линуксоиды... ZFS так не тупит./thread
А как она тупит?
6мв/с?
Да уж лучше сабж с багом.
> А как она тупит?Бывает что и сильно. Но не так сильно как iZen :)
ну... любая технология работает в связке технология-человек.
но кто-то упорно утверждает, что:
— "этавон_панацея" в человеке не нуждается. тут так удобно, сухо и тепло.
Танцы на 20см гвоздях, стоя на голове, тоже могут приводить к повреждению мозга.
Что за opennet, если не дают слово без регистрации.
> Что за opennet, если не дают слово без регистрации.Надеюсь, Вы гостеприимны, но при этом не позволите у себя дома бесчинствовать. Насколько понимаю здешние правила -- примерно так же.
Теперь все стало понятно.
а с другой стороны, если знакомый достаточны близкий (зарегистрированный), то можно? :D