Представлены (http://www.kernel.org/) очередные корректирующие релизы ядра Linux: 3.0.49 (https://lkml.org/lkml/2012/10/28/97) (31 исправление (http://www.kernel.org/pub/linux/kernel/v3.0/ChangeLog-3.0.49)), 3.4.16 (https://lkml.org/lkml/2012/10/28/101) (42 исправления (http://www.kernel.org/pub/linux/kernel/v3.0/ChangeLog-3.4.16)) и 3.6.4 (https://lkml.org/lkml/2012/10/28/99) (85 исправлений (http://www.kernel.org/pub/linux/kernel/v3.0/ChangeLog-3.6.4)). Как обычно, в анонсе выхода новых версий подчеркивается обязательность проведения обновления.
Из подсистем, в которых устранены ошибки можно отметить: mac80211, vlan, sparc64, drm/i915, Xen, cgroup, ext4. Достаточно большая порция исправлений касается подсистемы USB и сетевого стека (IPv4, IPv6). В новый выпусках также устранена уязвимость (http://permalink.gmane.org/gmane.comp.security.oss.general/8562) (CVE-2012-0957), позволяющая получить доступ к части содержимого стека ядра через манипуляции с вызовом uname() с опцией UNAME26.
В указанных выпусках не исправлена недавно выявленная проблема (http://www.opennet.me/opennews/art.shtml?num=35164) с повреждением данных в разделе ext4. Более детальное изучение причин возникновения ошибки показало (https://plus.google.com/u/0/117091380454742934025/posts/f5a1...), что проблема проявляется значительно реже чем предполагалось и разработчикам так и не удалось полностью повторить все условия её возникновения. Пока все гипотезы возможных причин возникновения потери данных у пользователей носят только умозрительных характер и не подтверждены на практике, так как проблема скорее всего вызвана ошибками в нескольких подсистемах и проявляется при сочетании эффекта гонки при крахе ядра, использовании специфичных опций размонтирования и только на определённом типе оборудования. В настоящее время подготовлено два теоретически решающих проблему патча, но пока их эффективность не подтверждена они удержаны от включения в состав основного ядра Linux.
URL: https://lkml.org/lkml/2012/10/28/99
Новость: http://www.opennet.me/opennews/art.shtml?num=35192
Ну, у кого там ext4 дох, убивал соседского кота и объявлял себя покемоном? Ваш звездный час - вы можете выйти и воспроизвести проблему. А то как вопить - все горазды. А как воспроизводить - все в кусты :)
У тех кто добавлял крайне нерекомендуемые параметры в опции монтирования. Короче у ССЗБ.
как бы не оказалось, что не в опциях дело, а как несколько лет назад всплыли проблемы с контроллером сетевых карт: началась шумиха, а потом выяснилось, что костыль встроен в виндовые дрова, а нигде про ошибку и словом не проронились
> как бы не оказалось, что не в опциях делоТеодор провел полное расследование и в чем дело - дотошно установил. Но это не отменяет того что для того чтобы на это нарваться - надо сделать вообще фиг знает что.
>> как бы не оказалось, что не в опциях дело
> Теодор провел полное расследование и в чем дело - дотошно установил. Но
> это не отменяет того что для того чтобы на это нарваться
> - надо сделать вообще фиг знает что.Дурак изобретательный - к коим относится процентов 60 здешних завсегдатаев - найдет способ даже Супер-Пупер-Богус-ФС заломать ручонками шалавливыми за часок так, что ни один водолаз не восстановит.
> Ну, у кого там ext4 дох, убивал соседского кота и объявлял себя
> покемоном? Ваш звездный час - вы можете выйти и воспроизвести проблему.
> А то как вопить - все горазды. А как воспроизводить -
> все в кусты :)Когда вас уволят без выходного пособия, за потерю всех документов фирмы, вот тогда и посмеемся, и скажем что вы ССЗБ, и прочее прочее.
А если вы считаете что беда не может к вам придти на 100%, то вы просто идиот.
Бэкапы не делай
@
Будь ССЗБ
Бэкапы не нужны т.к. у меня ничего никогда не ломалось. Бэкапы придумали производители дисков чтобы выжать еще бабок. Делая бэкапы - вы покупаете яхту какому-нибудь хрену из WD или Seagate. Будьте благоразумны - не делайте бэкапов, никогда.
За бэкапы вообще наказывать надо.
Че наказывать? Сразу расстреливать на месте
Не знаю, смогу ли я дальше жить, не высказав все вам, моим суровым боевым друзьям. Простите меня. Вчера я сделал бекап.
Расстрелять!
о, одмины локалхоста закукарекали :)
> о, одмины локалхоста закукарекали :)Или некто [довольно успешно] троллит и потому забыл воткнуть тег "сарказм" для недотеп :)
Ну, если только делать бекапы на те же самые WD и Seagate, то да. Но это же абсурд! Только на ленту! Только tar!
> Бэкапы не нужны...Конечно! Никому не нужны бэкапы, всем нужны restore!
> Делая бэкапы - вы покупаете яхту какому-нибудь хрену из WD или Seagate.
А не делая - вы сначала покупаете машины и квартиры владельцам контор по восстановлению данных, а потом все равно платите за яхты разным хренам из WD и Seagate!
Толстый, такой толстый..
> Когда вас уволят без выходного пособия, за потерю всех документов фирмы, вот
> тогда и посмеемся, и скажем что вы ССЗБ, и прочее прочее.Проблема в том что это может случиться с примерно такой же вероятностью как то что прилетит метеорит и зашибет вас. Ну если вас зашибло метеоритом - то и документы вам ни к чему. Да и выходное пособие - тоже.
>> Когда вас уволят без выходного пособия, за потерю всех документов фирмы, вот
>> тогда и посмеемся, и скажем что вы ССЗБ, и прочее прочее.
> Проблема в том что это может случиться с примерно такой же вероятностью
> как то что прилетит метеорит и зашибет вас. Ну если вас
> зашибло метеоритом - то и документы вам ни к чему. Да
> и выходное пособие - тоже.Ошибаешься, чувачок. Одмины ВТЦ, что в США, тоже так думали. А прилетела пара самолетиков - и трындец. Причем - ЧСХ - первое предупреждение у них было гораздо раньше. Взрыв в цокольном этаже и пожар, уничтоживший серверную и ленты с бэкапами, которые хранились _там_же_. Два раза подряд, в одну воронку, в течение жизни одного поколения.
Так что твой пример - НЕ КАНАЕТ.
У меня лично был случай. Горел офис. Выгорело ВСЕ, кроме бэкапов лично моих, которые ЛИЧНО Я накануне пожара записал и унес домой. В сейфик. Смекаешь?
Я вот чему удивляюсь: NTFS уже хреновых 20 лет, а с ней ни разу таких массовых проблем не было. Что самое удивительное, так это то, что ее за эти 20 лет по фичастости никто обогнать не может!
Толсто.
Ну вообще то он прав, NTFS весьма продуманная система, особенно для своего времени. Другое дело что они с фрагментацией намудрили. И немалая часть взможностей практически не использовалась (версии файлов, ссылки), подозреваю из за тебований тянуть совместимость с древним софтом. Есть места где венду можо и нужно ругать, но NTFS все таки на твердую 3+.
При этом именно нтфс приходится чаще всего восстанавливать.
При этом с помощью тестдиск и фоторек.
Что характерно, ни разу в моей (и не маленькой) практике не было такой необходимости с ext2-4. Фсчк хватало.
Нда. С уфс данные вытаскивал, с xfs, с лвм, hfs+. Ещё вагон и маленькая тележка. Постоянно с нтфс. А вот с extX не было.
> А вот с extX не было.Ну я несколько раз вытаскивал. По причине бэдов на диске, в которых файловая система не виновата. Fsck обычно все чинит до вполне моунтабельного состояния ;)
>> А вот с extX не было.
> Ну я несколько раз вытаскивал. По причине бэдов на диске, в которых
> файловая система не виновата. Fsck обычно все чинит до вполне моунтабельного
> состояния ;)Мне нравится слово "обычно". :)))))))))))
Если вспомнить соотношение linux/windows установок (1 к 99), то вполне логично, чтоПри этом именно нтфс приходится чаще всего восстанавливать
Ау! Есть кто?
Я только свою статистику привожу.
И в кругу моих знакомых/работы линуха больше 50% (включая и контролеры домена, и файлопомойки, и субд оракл, и мои личные компы, и компы друзей).
Остальные 50% приходятся на винду, соляру, мак.И постоянно траблы только с нтфс.
>Муйло, я в IT поболе, чем ты на свете живешь. И активная жизнь - это ДЕСЯТКИ машин и серверов ежедневно, 7 дней в неделю на протяжении более, чем 20 лет. Смекаешь?конечно смекаю.
особенно что помимо вашей низкой квалификации (да что там низкой! нулевой!) вы ещё и просто не воспитанный тип.
чё уж тут не смекнуть то.
> Ну вообще то он прав, NTFS весьма продуманная система, особенно для своего времени.Да, для середины-конца девяностых - ничо так, даже получше ряда иных экспонатов того времени. Проблема только в том что ща на дворе 2012 а ничего нового в MS не посчитали нужным разрабатывать.
>> Ну вообще то он прав, NTFS весьма продуманная система, особенно для своего времени.
> Да, для середины-конца девяностых - ничо так, даже получше ряда иных экспонатов
> того времени. Проблема только в том что ща на дворе 2012
> а ничего нового в MS не посчитали нужным разрабатывать.Она РАБОТАЕТ. От нее, тащемта, больше ничего не требуется. И ее - вот сейчас, в 12м году - весьма непросто ухитриться вот так вот изломать.
> Она РАБОТАЕТ. От нее, тащемта, больше ничего не требуется. И ее -
> вот сейчас, в 12м году - весьма непросто ухитриться вот так
> вот изломать.Да ладно? Разворачивайте архив с кучей мелких файлов, и в это время выключите питание. Жестко. Веселые карусельки вам обеспечены. Нет, конечно, ничего фатального - но потерянные ноды скорее всего будут. И журнал не поможет.
Для особых извращенцев - менять режим сжатия подкаталогов с кучей мелочи, и в это время вырубить питание. Вот тут уже вплоть до потери данных (того, что обрабатывалось).
Еще можно менять права на кучу мелочи с подкаталогами, и в этот момент вырубить питание. Некорректные security record'ы обеспечены.
>[оверквотинг удален]
>> вот сейчас, в 12м году - весьма непросто ухитриться вот так
>> вот изломать.
> Да ладно? Разворачивайте архив с кучей мелких файлов, и в это время
> выключите питание. Жестко. Веселые карусельки вам обеспечены. Нет, конечно, ничего фатального
> - но потерянные ноды скорее всего будут. И журнал не поможет.
> Для особых извращенцев - менять режим сжатия подкаталогов с кучей мелочи, и
> в это время вырубить питание. Вот тут уже вплоть до потери
> данных (того, что обрабатывалось).
> Еще можно менять права на кучу мелочи с подкаталогами, и в этот
> момент вырубить питание. Некорректные security record'ы обеспечены.А что, УПСы. еще не изобрели?
> А что, УПСы. еще не изобрели?Тут шла речь о том, как быстро и просто покалечить NTFS, а не о УПС'ах. ext'ы в таких случаях как правило восстанавливаются с журнала без каких-либо граблей.
то то в новости пишут что журнал гробит FS.
или вы забыли еще как delayed alloc убивал файловую систему если был reset или power lost?
для отстающих и врунов можно новость и повторить:
>проблема проявляется значительно реже чем предполагалось и разработчикам так и не удалось полностью повторить все условия её возникновения. Пока все гипотезы возможных причин возникновения потери данных у пользователей носят только умозрительный характер и не подтверждены на практикеа вы кто из них? просто тупой или брехло?
Эмм, "по фичастости" - может расскажете, а то мужики то и не в курсе
> Я вот чему удивляюсь: NTFS уже хреновых 20 лет, а с ней ни разу таких массовых проблем не было.Мы не злопамятные, но злые и память у нас хорошая. Поэтому про то как дамп при падении в синий скрин сносил всю файловую систему если диск более 2Тб - мы еще не забыли. И вот это было весьма воспроизводимой проблемой. Как винчи стали достигать терабайтных значений - MS тут же и завалило багрепортами.
>> Я вот чему удивляюсь: NTFS уже хреновых 20 лет, а с ней ни разу таких массовых проблем не было.
> Мы не злопамятные, но злые и память у нас хорошая. Поэтому про
> то как дамп при падении в синий скрин сносил всю файловую
> систему если диск более 2Тб - мы еще не забыли. И
> вот это было весьма воспроизводимой проблемой. Как винчи стали достигать терабайтных
> значений - MS тут же и завалило багрепортами.Скажи мне, о чудо, НАХ диски такого размера? Когда throutput максимален при максимизации шпинделей и равном с ним количеством лунов?
> Скажи мне, о чудо, НАХ диски такого размера? Когда throutput максимален при
> максимизации шпинделей и равном с ним количеством лунов?Чичиго?
>> Скажи мне, о чудо, НАХ диски такого размера? Когда throutput максимален при
>> максимизации шпинделей и равном с ним количеством лунов?
> Чичиго?Того. Ты уверен, что ты айтишнег?
>>> Скажи мне, о чудо, НАХ диски такого размера? Когда throutput максимален при
>>> максимизации шпинделей и равном с ним количеством лунов?
>> Чичиго?
> Того. Ты уверен, что ты айтишнег?Я - атишнег. И нихрена не понял почему нельзя максимизнать шпиндели равные лунам но при жтом каждый > 2 TB? Они вообщето дешевле доширака ныне ...
> Того. Ты уверен, что ты айтишнег?Уверен. Как ты эти шпиндели собрался агрегировать? Софтово? Извини, тот же dedicated контроллер массива сделает это лучше, и throughput будет бОльшим.
Ну и да: открываю секрет для безграмотных: командный цикл достаточно длинный. Поэтому отсылка команд одному LUN'у будет куда легче отсылки команд сотне LUN'ов. Плюс чередование данных на шине. Если шина общая - на throughput это повлияет прямым и непосредственным образом.
> Скажи мне, о чудо, НАХ диски такого размера?«что? автопоезда? не, не слышал: у меня в мой запор всё помещается, нах эти автопоезда нужны? ламеры криворукие, не смогли в запор запихать!»
>> Я вот чему удивляюсь: NTFS уже хреновых 20 лет, а с ней ни разу таких массовых проблем не было.
> Мы не злопамятные, но злые и память у нас хорошая. Поэтому про
> то как дамп при падении в синий скрин сносил всю файловую
> систему если диск более 2Тб - мы еще не забыли. И
> вот это было весьма воспроизводимой проблемой. Как винчи стали достигать терабайтных
> значений - MS тут же и завалило багрепортами.Могу вспомнить другой случай. Как RHEL 3 после выключения питалова без шатдауна посредством fsck мило сгребал в мусор весь 80 Гб диск. Причем _четыре_раза_подряд_. Не бета-версия. Вполне себе продакшен. Было это.... дай бог памяти, недавно совсем. Году этак в 7м или 8м.
пруф будет?
> пруф будет?Ага, сейчас фотографии достану тех времен. Думаешь, у меня не было других забот, кроме как делать пруф на десятки лет вперед для таких вот, как ты?
Как говорят на ЛОРе - слив защитан :)
На мой взгляд самая большая кака в нтфс - MFT. Точнее малая избыточность хранения.
> Я вот чему удивляюсь: NTFS уже хреновых 20 лет, а с ней
> ни разу таких массовых проблем не было.(улыбается). guest login. право на запись и запуск одного батника из пары строк. прощай, дорогая ntfs. настолько, что вытащить что-то оттуда становится ой, как проблематично. как минимум до xpsp1 или sp2, дальше не проверял.
подчёркиваю, GUEST login.
то, что ты о чём-то не знаешь, не значит, что этого нет. это всего лишь значит, что у m$ нет публичного багтрекера.
да-да-да
Помним помним, после скачка света
NTldr not found
Самая стабильная система, ага...
"Я не верю в существование ковра" (С)
стабильность@надежность
>проявляется при сочетании эффекта гонки при крахе ядра, использовании специфичных опций размонтирования и только на определённом типе оборудованияи только на посыпавшемся диске да.
>проявляется при сочетании эффекта гонки при крахе ядра, использовании специфичных опций размонтирования и только на определённом типе оборудования...так если залезть на шкаф, и вот так извернуться...
> ...так если залезть на шкаф, и вот так извернуться......на велосипеде, в ластах, маске для ныряния и лыжными палками... возникает вопрос: как вы в таком виде туда взгромоздились и вообще нахрена, собственно?!
>...на велосипеде, в ластах, маске для ныряния и лыжными палками... возникает вопрос: как вы в таком виде туда взгромоздились и вообще нахрена, собственно?!"Те, кто выжил в катаклизме, пребывают в пессимизме.
Их вчера в стеклянной призме к нам в больницу привезли..."
> 3.0.49, 3.4.16, и 3.6.4Прочитал как 2.0.49, 2.4.16 и 2.6.4.
>> 3.0.49, 3.4.16, и 3.6.4
> Прочитал как 2.0.49, 2.4.16 и 2.6.4.Поздравляю с разморозкой криогенной камеры.
Кто ни будь собирал 3.6.4? Никто не заметил изменений в сборке?
Что-то у меня он уж слишком долго собирает, причём стадию компиляции уже прошёл, делает что-то "objcopy" причём так дооолго, ну почему?!
У меня ядро на SSD диске, да и проц 8ядер AMD FX.. Будто в скрипт тупо "sleep"-ов напихали..
Проц на 1-2% загружен, скорость чтения/записи 1% .. ну как, блин, так можно..Поставил перед сборкой time -p .. посмотрим как завершит..
> Проц на 1-2% загружен, скорость чтения/записи 1% .. ну как, блин, так можно..А у вас trim на SSD включен? Так, в порядке бреда, одна из гипотез.
Хмм, не был включен, спаисбо, включил..
Но говоря о сборке, я на прошлой неделе собирал 3.6.3 на этой же машине ~6-7 минут заняла сборка.
А сейчас:
real 2288.17
user 4203.75
sys 306.12
---
где ~6-7 минут с полностью загруженным процем, и где ~40 минут, make ковырялся над файлами после сборки..Что ж.. попробую теперь со включённым discard/TRIM
Исправили !