LINUX.ORG.RU

Серьезный баг в ext4

 , , ,


1

2

http://www.phoronix.com/scan.php?page=news_item&px=MTIxNDQ

Для !Ъ:

Баг появился в 3.6.2, позже бэкпортирован в 3.5 и 3.4. Суть в том, что можно потерять кучу данных, произведя несколько перезагрузок подряд с минимальным перерывом.

Ted Ts'o:

I think I've found the problem. I believe the commit at fault is commit 14b4ed22a6 (upstream commit eeecef0af5e):

jbd2: don't write superblock when if its empty

which first appeared in v3.6.2.

The reason why the problem happens rarely is that the effect of the buggy commit is that if the journal's starting block is zero, we fail to truncate the journal when we unmount the file system. This can happen if we mount and then unmount the file system fairly quickly, before the log has a chance to wrap. After the first time this has happened, it's not a disaster, since when we replay the journal, we'll just replay some extra transactions. But if this happens twice, the oldest valid transaction will still not have gotten updated, but some of the newer transactions from the last mount session will have gotten written by the very latest transacitons, and when we then try to do the extra transaction replays, the metadata blocks can end up getting very scrambled indeed.

*Sigh*. My apologies for not catching this when I reviewed this patch. I believe the following patch should fix the bug; once it's reviewed by other ext4 developers, I'll push this to Linus ASAP.

- Ted

Тут же, Ted:

Well, the problem won't show up if the journal has wrapped. So it will only show up if the system has been rebooted twice in fairly quick succession. A full conventional distro install probably wouldn't have triggered a bug... although someone who habitually reboots their laptop instead of using suspend/resume or hiberbate, or someone who is trying to bisect the kernel looking for some other bug could easily trip over this --- which I guess is how you got hit by it.

★★★★★

Ну и где твои патчи?

CYB3R ★★★★★ ()
Ответ на: комментарий от beastie

а тут смеялись над человеком

Ну это ж типичный такой подход: у меня всё работает — значит ты тупой, криворукий злобный буратина.

fang ()

Ушел со стабильной ext4 на нестабильную btrfs. В итоге нашил баги в ext4.

Black_Roland ★★★★ ()
Ответ на: комментарий от Black_Roland

Ждем обратно. ☺
// Мир праху btrfs после твоего ухода

f1xmAn ★★★★★ ()

Всем срочно прописываю даунгрейд до 3.2!

f1xmAn ★★★★★ ()

Блин, я на два компа воткнул ext4 как раз. И со свежими ядрами. Надеюсь, нигде не воспроизвёдется баг, прежде чем апдейты приплывут.

geekless ★★ ()
Ответ на: комментарий от geekless

Я на ноутбук поставил бубно вендро 3.6.2 там ext4, пока ничего не пропало, перезагружается ноутбук не чаще четырех часов.

Суть в том, что можно потерять кучу данных, произведя несколько перезагрузок подряд с минимальным перерывом.

не эксперементировать не буду не просите.

В виртуалке можно.

bhfq ★★★★★ ()
Последнее исправление: bhfq (всего исправлений: 1)
Ответ на: комментарий от bhfq
Эксплойт позволяет создать своеобразную «флэшку смерти». Если вставить её в разъём USB на компьютере Windows, то она автоматически монтируется и компрометирует файловую систему, эксплуатируя уязвимость в ntfs.sys.

Файловая система NTFS чрезвычайно сложная и в значительной мере неисследованная, так что в драйвере ntfs.sys можно найти много интересных багов. Матеуш Юржик опубликовал результаты эксперимента с повышением привилегий в 64-битной системе Windows 7.

Компанией Microsoft уязвимость не классифицируется как критическая, потому что эксплойт требует физического доступа к компьютеру. Тем не менее, подобные инструменты можно эффективно использовать на «общественных» компьютерах в школах, университетах, гостиницах и т.д. Из-за невысокого статуса уязвимости Microsoft не выпустит срочный апдейт, да и вообще может отложить закрытие этой уязвимости в долгий ящик.

«Это пять!»

geekless ★★ ()

Баг появился в 3.6.2, позже бэкпортирован в 3.5 и 3.4

А еще говорят, что линукс недружелюбен к пользователю — вон даже баги бэкпортируют.

Мне пофиг, у меня ведро 3.2

buddhist ★★★★★ ()
Ответ на: комментарий от bhfq

При проверке диска с 500 000 файлов например explorer выжирает всю память и встаёт раком, баг известен с ХP , в семёрке присутствует. Всем все пох.

ilovewindows ★★★★ ()
Ответ на: комментарий от bhfq

Хочу проверить на федоре 17 тут как раз 3.6.2 ведро и ext4 в виртуалке.

А тут systemd ругается http://i.imgur.com/0EGvM.png и висит уже минуты 5

Загрузился

bhfq ★★★★★ ()
Последнее исправление: bhfq (всего исправлений: 1)

В 3.6.3 присутсвует или уже починили?
P.S. пошел делать бэкапы от греха подальше

xorik ★★★★★ ()
Ответ на: комментарий от ilovewindows

При проверке диска с 500 000 файлов например explorer выжирает всю память и встаёт раком, баг известен с ХP , в семёрке присутствует. Всем все пох.

Что значит проверка диска? Проверка чем и на что?

Kroz ★★★★★ ()
Ответ на: комментарий от bhfq

Семь раз перезагружал быстро, не ломается фс :(

bhfq ★★★★★ ()

Баг появился в 3.6.2, позже бэкпортирован в 3.5 и 3.4.

Плач бетатестеров ITT.

aidaho ★★★★★ ()
Ответ на: комментарий от Kroz

В свойствах диска, диалог вызывается из проводника, галку снять «исправлять ошибки автоматически» . Есть в интернете описание ошибки.

ilovewindows ★★★★ ()
Ответ на: комментарий от geekless

Но это неправда.

Эксплойт позволяет создать своеобразную «флэшку смерти». Если вставить её в разъём USB на компьютере Windows, то она автоматически монтируется и компрометирует файловую систему, эксплуатируя уязвимость в ntfs.sys.

На самом деле ничего автоматически не происходит, необходимо запустить эксплоит, который использует наличие специально сформированной файловой системы. Причем положить сам эксплоит на такую флешку невозможно.

http://j00ru.vexillium.org/?p=1272 — оригинал. Очевидно, неправильное понимание возникло из фразы во вступлении:

In addition, it was certainly tempting to be able to simply insert a USB stick, have it automatically mounted by the operating system and immediately compromise it by triggering a vulnerability in ntfs.sys.

То есть они приступили к исследованию, мечтая найти подобную уязвимость, но так как ксакепы английского языка не знают, то они поняли, как будто это относится к найденной.

anonymfus ★★★★ ()
Ответ на: комментарий от bhfq

Failed to start Wait for Plymouth ... to Quit

Даже Если не Брать в Расчет Дебильную Повальную Капитализацию, переведите мне ЭТО кто-нибудь!

leave ★★★★★ ()
Ответ на: комментарий от aidaho

Плач бетатестеров ITT.

Где ты плач увидел?

xorik ★★★★★ ()
Ответ на: комментарий от leave

Это такой жуткий сервис. Он постоянно фейлится. И без него всё в принципе работает. Но даже если его вывести в disabled, он всё равно при загрузке будет стартовать. Видимо, вызывается самим Plymouth'ом.

carasin ★★★★★ ()
Ответ на: комментарий от ilovewindows

Есть ещё такой баг

Проверка диска на ошибки ntfs-раздела идет в чуть ли не в десятки раз медленней, чем chkdsk буква_диска: /F из командной строки.

Programmist11180 ★★★ ()
Ответ на: комментарий от carasin

Странно, у меня никогда не фейлится. Подозреваю, что при использовании блоба неправильно определяется разрешение (его надо указать в grub2), отсюда фейл.

ArtKun ★★★★★ ()

the problem won't show up if the journal has wrapped

что значит wrapped?

teod0r ★★★★★ ()

В 3.6.5-pf залил патч от Теда. Надеюсь, поможет.

post-factum ★★★★★ ()

Пока пользователи других дистрибутивов качают ядра, плачут и восстанавливают данные, пользователи Debian просто работают.

wintrolls ☆☆ ()
Ответ на: комментарий от wintrolls

Пока пользователи других дистрибутивов качают ядра, плачут и восстанавливают данные, пользователи Debian просто работают.

Как они могут работать? Они же в криокамерах?!

mironov_ivan ★★★★★ ()
Последнее исправление: mironov_ivan (всего исправлений: 1)

> Серьезный баг в ext4

это баг в головах кураторов ядра. после того, как они сломали в 3.5 систему сборки и никто не заметил (или старательно отмодерировали), отношение к линуксовым ядерщикам опустилось ниже плинтуса (а на уровень плинтуса оно опустилось ещё раньше, когда затеяли перестройку с ARM, после чего релизы(!) тупо перестали собираться под нужные платформы, т.к. стабильный апи — нонсенс, а адаптировать под изменения код в мейнстриме(!) ядра никто не хочет).

arsi ★★★★★ ()
Ответ на: комментарий от mironov_ivan

Как они могут работать? Они же в криокамерах?!

У нас трубопроводы в криокамеры проложены. Можно прямо там работать. И летом не жарко.

https://admin.fedoraproject.org/pkgdb/apps/search/f2fs-tools

http://packages.qa.debian.org/f/f2fs-tools/news/20121007T130005Z.html

i-rinat ★★★★★ ()
Ответ на: комментарий от bhfq

Дабы поддержать беседу скажу, что есть баг с ресайзом ntfs диска на менее 50% размера (не дает поресайзить), даже если брать не системный диск.

goingUp ★★★★★ ()
Ответ на: комментарий от bhfq

Достаточно несколько раз подряд смонтировать/отмонтировать, перезагружаться не обязательно.

После этого журнал ломается.

Xenius ★★★★★ ()

Хорошо, что в Slackware ядро 3.2. Патрик как знал!

Xenius ★★★★★ ()
Ответ на: комментарий от post-factum

Откель есть пошла вообще нумерация версий pf? Она с версией ядра не связана?

feofil ()
Ответ на: комментарий от f1xmAn

Сижу на btrfs на / и /home. Всё огонь, брат жив, зависимости нет.

ekzotech ★★★★ ()
Ответ на: комментарий от f1xmAn

Волосы шелковистые.

В целом, после установки btrfs, жизнь стала налаживаться, на меня обращают внимание девушки, я стал чувствовать себя увереннее.

ekzotech ★★★★ ()

сколько твердил, что ext4 кака...всё бестолку

megabaks ★★★★ ()
Ответ на: комментарий от megabaks

сколько твердил, что ext4 кака...всё бестолку

Полный список как в студию пожалуйста.

Не флейма ради, но я смотрел код reiserfs (третьей). Он, кхм, жутковат. Фактически, код — это единственное полное описание дискового формата. И оно вводит в заблуждение.

Комментарии к коду местами не соответствуют коду. Старые названия понятий перемешаны с новыми. Например, для одной части ключа есть два названия — тип и уникальность. Означают одно и то же. И оба используются в коде. Есть дефайны, которые нигде не используются. Например, JOURNAL_TRANS_HALF. Фактически, это жёсткий хардкод 4096-байтного блока. Но выясняется, что теперь этот дефайн не используется и хардкода уже нет. А это просто оставили потомкам, чтобы не скучно было.

Обратная совместимость с 3.5 это вообще феерично. Я создаю ФС в формате 3.6, но в процессе работы на ней образуются ключи версии 3.5. Я понимаю необходимость конвертировать ключи 3.5 в 3.6, но обратно-то зачем?

Форматирование кода вроде бы притянуто к формальному стандарту linux, но как-то странно, потому как присутствует куча уровней вложенности. Есть места, где ради того, чтобы влезть в 80 колонок, код, занимающий 2-3 строчки, растягивается до 16. Его трудно читать. И при этом всё равно код вылазит за эти 80 колонок! Нафига тогда вообще было разбивать на столько строк? Комментарии могут и за 150 колонок выйти. Всё равно скроллить надо будет.

Видел когда-нибудь убер-функции на полторы тысячи строк? Они там есть!

i-rinat ★★★★★ ()

я так понимаю, 3.6.0 обновлять пока не стоит? :)

Harald ★★★★★ ()
Ответ на: комментарий от i-rinat

список?
обнуление файлов
тормоза
убивается на раз
сабж
...
а рейзер - мне код не важен, мне важно как он работает
а с этой задачей он справляется отлично

megabaks ★★★★ ()
Ответ на: комментарий от megabaks

Это такая недофс, для которой xattr привинчен гвоздями? Или ты про какой то новый рейзер?

vasily_pupkin ★★★★★ ()
Ответ на: комментарий от megabaks

список?

Я имел в виду список ФС, которые ты считаешь каками. Потому как глюк не в ext4, а в jbd2. Есть как минимум ещё одна ФС в ядре, которая использует jbd2.

а рейзер - мне код не важен, мне важно как он работает

Мой опыт таков: никогда не было проблем ни с ext3, ни с ext4, ни с jfs. А с reiserfs были локи (ядро 3.2.6). Но я же не кричу, что, мол, reiserfs — бяка. Там всё ещё есть проблемы, как и в остальных. Но в отличие от ext4, в коде reiserfs мало кто копается. И не в последнюю очередь из-за тяжести восприятия кода.

i-rinat ★★★★★ ()

Когда-то давным давно я находил вполне пристойные спецификации на ext2, описывающие структуру файловой системы и форматы всех элементов. Есть ли такое для Ext3 и Ext4?

alman ★★★ ()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.