8 июля 2009 в 16:32

Проблемы с ext4 в ubuntu jaunty

Коротко о главном — ext4 в ubuntu jaunty нестабильна. При определённых обстоятельствах, в которые включается относительно малый объём свободного места — несколько Гб, при попытке удаления больших файлов или большого количества файлов, происходит зависание системы. Глухое зависание, что называется «под ресет». Есть соответствующий баг-репорт. Но это лечимо.

Я, как наверное и многие из собравшихся тут давненько облизывался и ходил вокруг да около новой версии файловой системы ext — ext4. Одна из главных причин, которая меня толкала на переход на ext4 была подвисания при удалении больших файлов с разделов на ext3. Долгое время я сидел на kubuntu 8.04, но всё же решил обновиться. В ходе обновления повидал немало чудес и приключений. Дабы решить некоторые проблемы переставил ряд обновлений, несколько версий kde (4.2, 4.2.9, 4.3, с последующим откатом к kde3), в итоге у меня образовался приличных размеров архив в /var/cache/apt/archives. Размеры — под два гигабайта, файлов несколько сотен.

Так вот, чем дальше разрасталась эта директория, тем чаще я стал встречаться с пренеприятным глюком — глухим зависанием при попытках массовой установки/обновления пакетов. Можете себе представить, во что превращается система при обновлении с одной версии kde до другой во время которого система зависает.

Дальше — больше. Попытка выполнить sudo apt-get clean, чтобы очистить кэш со 100% гарантией приводила к немедленному зависанию. Более того, и ручное удаление этих файлов тоже кончалось зависанием.

После гугления был обнаружен этот баг-репорт, из которого следует, что на данный момент проблеме подвержены все машины на базе ubuntu jaunty с ядром установленным по умолчанию (на данный момент это 2.6.28-13-generic).

Лекарство есть. С сегодняшнего дня их даже два:
  1. Как следует из вышеупомянутого баг-репорта исправление уже отправлено в proposed и уже компилируется. Всё что нужно, это включить jaunty-proposed обновления и ждать обновки. Неизвестно, правда поможет ли это, т.к. нужно ещё получить подтверждения, что это работает. UPDATE: Как оказалось, данный метод не работает. Пришедшее обновление не устранило проблемы.
  2. Второй вариант заключается в том, чтобы вручную поставить новое ядро, из ветки 2.6.29, например отсюда. Бонусом этого метода является то, что ряд графических чипов заработают заметно лучше.
Вывод тут примерно такой: ядро, используемое в Jaunty получилось несколько проблемным. Это и проблемы с картами intel, и проблемы с ext4. Пользоваться ext4 без установки соответствующих обновлений опасно. Поэтому, настоятельно рекомендуется включать proposed обновления либо подождать с использованием ext4, либо обновить ядро.
Игорь Тарасов @TiGR
карма
107,3
рейтинг 0,0
Похожие публикации
Самое читаемое Администрирование

Комментарии (27)

  • НЛО прилетело и опубликовало эту надпись здесь
    • 0
      Согласен, исправил. Просто привык к английской терминологии.
      • 0
        Бонусом этого метода является то, что ряд графических чипов заработают заметно лучше.

        Если есть возможность, предоставьте список чипов!
        • +1
          На nvidia в glxgears наблюдается прирост в ~20%. С ati там тоже есть какие-то улучшения. Но это как бы просто в результате того, что устанавливая ядро 2.6.29, мы ставим сразу и все прочие улучшения, которые вошли в это ядро, а в плане графической системы там есть заметные подвижки по сравнению с 2.6.28.

          В 2.6.30 дела обстоят ещё лучше, но там большие заморочки с nvidia, модуль ядра просто так не пересоберётся, там надо шаманить. С 2.6.30 надо подождать выхода karmic.
  • 0
    спасибо, не зря сомнения терзали
  • 0
    Ничего себе «лекарство». Которое вроде как есть, но его вроде бы и нет.
    • 0
      Ну второй-то способ по крайней мере вполне стабильно работает.
  • 0
    А я уже винт собрался менять. А тут такое. Спасибо автор!!!
  • 0
    ссылка на deb-файлы это конечно здорово
    но было бы это оформленно репозиторием все — цены бы совету не было бы
    а так, придется каждый раз вспоминать откуда ставил и проверять ручками обновления
    • 0
      Официальных репозитариев как бы для этого дела нет. А если говорить об обновлениях, то разве они тут важны? Поставил — и забыл :)
  • 0
    Предлагаю тем, кто опробовал второй способ, отписаться о результатах. Это позволит остальным сделать правильный выбор: обновлять — не обновлять.
    • 0
      В том баг-репорте уже с десяток людей отписались — работает. Сам подтверждаю.
  • 0
    А меня вот замучал баг на Kubuntu Jaunty с полными зависонами X-ов на трёх компах, не знаю даже в какую сторону копать чтобы его вылечить ;(
    Проявляется только со включенным копозингом (Compositing enabled): работает всё нормально, вдруг весь интерфейс замирает и не реагирует ни на клаву ни на мышку, хотя курсор мышки по экрану двигается и Numlock на клаве тоже работает.
    Если в первые несколько секунд зависона успеть прибить X или перезапустить или успеть переключиться в консоль — система остаётся живой, а если не успел — перестаёт и на клаву реагировать. В логах /var/log/* ничего не пишет, в домашней папке тоже не нашлось.
    Сначала грешил на Intel когда ловил его на ноуте с интегрёной видео Intel (на KDE 4.2 из оф. репозиториев), но потом после нескольких апдейтов он стал проявляться и на Nvidia (с дровами из репозитория) на двух компах, после обновления до KDE 3.x тоже не исчез а наоборот — стал чаще вылазить.

    Куда рыть чтобы найти причину — не знаю, чтобы баг открытый найти или новый открыть — тоже недостаточно информации, нужно найти хотя бы виновный пакет или какие-либо записи в логах.

    Если кто-нибудь сталкивался с такой проблемой — сообщите плиз, может совместно найдём жучка ;)
    • 0
      Хотя я с этим не сталкивался, но с ходу нашёлся вот этот баг:

      https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-ati/+bug/384275
      • 0
        Ну у меня не ATI а NVidia и Intel, а также зависает не только в плейере а просто в обычной работе.
        Даже просто гружу пустую сессию KDE4 и в System Settings зайти не успеваю — уже интерфейс вешается, а иногда — часами нормально работает.
        Поэтому этот баг не совсем в тему.
        • 0
          https://launchpad.net/+search?field.text=lockup+OR+freeze+kde4+intel&field.actions.search=Search

          Там много похожих сообщений, уж не знаю, какой именно лучше вам подходит.
  • 0
    Не сильно в тему, но я все про свое…
    Как там ext4 лучше заточена под работу на ssd?
    Кто копал в эту сторону?
    • НЛО прилетело и опубликовало эту надпись здесь
  • НЛО прилетело и опубликовало эту надпись здесь
    • +1
      Нет, не в курсе. Но вот данная проблема — она исключительно убунтовская. Т.к. в .29 проблемы уже нет, она есть только в 28х ядрах. Т.е. они там бэкпортили поддержку ext4, но как-то коряво получилось, т.е, это проблема появлялась и в основных ядрах, но её очень давно и успешно исправили… А бэкпорт в убунте так и получился недофикшеным.

      ext4 бэкпортили, бэкпортили, да не выбэкпортили. :)
      • НЛО прилетело и опубликовало эту надпись здесь
        • +1
          Да в убунте вообще из рук вон плохо с тем, чтобы фиксить баги. Посмотрите баг репорт по ссылке, там же просто никто не собирается его фиксить. Его пофиксили в karmic, а в jaunty и не собираются. И так уже неоднократно сталкивался что баги, порой простейшие, которых нет в том же debian никто не фиксит годами.
          • НЛО прилетело и опубликовало эту надпись здесь
  • 0
    ext4 на голую систему ставили или ext3 до ext4 обновляли??
    • 0
      Лично я — обновлял. Но насколько могу судить по сообщениям из того баг-репорта, люди и на чистую ставили.
  • НЛО прилетело и опубликовало эту надпись здесь
    • НЛО прилетело и опубликовало эту надпись здесь

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