Файловые системы ext3 root идут только для чтения с прерванным журналом даже после ремонта

Краткая версия: корневая файловая система ext3 на rackspace (xen). VM обнаруживает прерванный журнал при загрузке и монтирует только для чтения. Я попытался восстановить это из среды спасения с помощью tune2fs и e2fsck как это предписано во многих прочитанных статьях, но ошибка продолжает происходить.

UPDATE : поэтому на основе этой статьи я добавил «барьер = 0» в запись /etc/fstab для этой файловой системы, и она смонтировала r / w fine при следующей загрузке. Я убежден, что это паравиртуализация, но она понравится, если кто-то полностью поймет, что здесь происходит и может объяснить.

Длинная версия:

Rackspace VM только что обновлен от Ubuntu 11.10 до 12.04.2

dmesg с ошибкой:

 [ 14.701446] blkfront: barrier: empty write xvda op failed [ 14.701452] blkfront: xvda: barrier or flush: disabled [ 14.701460] end_request: I/O error, dev xvda, sector 28175816 [ 14.701473] end_request: I/O error, dev xvda, sector 28175816 [ 14.701487] Aborting journal on device xvda1. [ 14.704186] EXT3-fs (xvda1): error: ext3_journal_start_sb: Detected aborted journal [ 14.704199] EXT3-fs (xvda1): error: remounting filesystem read-only [ 14.940734] init: dmesg main process (763) terminated with status 7 [ 18.425994] init: mongodb main process (769) terminated with status 1 [ 21.940032] eth1: no IPv6 routers present [ 23.612044] eth0: no IPv6 routers present [ 27.147759] [UFW BLOCK] IN=eth0 OUT= MAC=40:40:73:00:ea:12:c4:71:fe:f1:e1:3f:08:00 SRC=98.143.36.192 DST=50.56.240.11 LEN=40 TOS=0x00 PREC=0x00 TTL=242 ID=37934 DF PROTO=TCP SPT=30269 DPT=8123 WINDOW=512 RES=0x00 SYN URGP=0 [ 31.025920] [UFW BLOCK] IN=eth0 OUT= MAC=40:40:73:00:ea:12:c4:71:fe:f1:e1:3f:08:00 SRC=116.6.60.9 DST=50.56.240.11 LEN=40 TOS=0x00 PREC=0x00 TTL=101 ID=256 PROTO=TCP SPT=6000 DPT=1433 WINDOW=16384 RES=0x00 SYN URGP=0 [ 493.974612] EXT3-fs (xvda1): error: ext3_remount: Abort forced by user [ 505.887555] EXT3-fs (xvda1): error: ext3_remount: Abort forced by user 

В спасательной ОС я пробовал:

 tune2sf -O ^has_journal /dev/xdbb1 #Device is xvdb1 in rescue, but xvdba1 in real OS e2fsck -f /dev/xvdb1 tune2sf -j /dev/xvdb1 

Я также запускаю e2fsck -p , e2fsck -f и tune2fs -e continue . Вот результат tune2fs -l .

 tune2fs 1.41.14 (22-Dec-2010) Filesystem volume name: <none> Last mounted on: <not available> Filesystem UUID: 68910771-4026-4588-a62a-54eb992f4c6e Filesystem magic number: 0xEF53 Filesystem revision #: 1 (dynamic) Filesystem features: has_journal ext_attr resize_inode dir_index filetype sparse_super large_file Filesystem flags: signed_directory_hash Default mount options: (none) Filesystem state: clean Errors behavior: Continue Filesystem OS type: Linux Inode count: 1245184 Block count: 4980480 Reserved block count: 199219 Free blocks: 2550830 Free inodes: 1025001 First block: 0 Block size: 4096 Fragment size: 4096 Reserved GDT blocks: 606 Blocks per group: 32768 Fragments per group: 32768 Inodes per group: 8192 Inode blocks per group: 512 Filesystem created: Thu Oct 20 21:34:53 2011 Last mount time: Mon Apr 8 23:01:13 2013 Last write time: Mon Apr 8 23:08:09 2013 Mount count: 0 Maximum mount count: 29 Last checked: Mon Apr 8 23:04:49 2013 Check interval: 15552000 (6 months) Next check after: Sat Oct 5 23:04:49 2013 Reserved blocks uid: 0 (user root) Reserved blocks gid: 0 (group root) First inode: 11 Inode size: 256 Required extra isize: 28 Desired extra isize: 28 Journal inode: 8 Default directory hash: half_md4 Directory Hash Seed: 1e07317a-6301-41d9-8885-0e3e837f2a38 Journal backup: inode blocks 

Я также grepped некоторые строки из /var/log/syslog находясь в режиме спасения, с дополнительной информацией об ошибке:

 Apr 8 19:47:06 dev kernel: [26504959.895754] blkfront: barrier: empty write xvda op failed Apr 8 19:47:06 dev kernel: [26504959.895763] blkfront: xvda: barrier or flush: disabled Apr 8 20:19:33 dev kernel: [ 0.000000] Command line: root=/dev/xvda1 console=hvc0 ro quiet splash Apr 8 20:19:33 dev kernel: [ 0.000000] Kernel command line: root=/dev/xvda1 console=hvc0 ro quiet splash Apr 8 20:19:33 dev kernel: [ 0.240303] blkfront: xvda: barrier: enabled Apr 8 20:19:33 dev kernel: [ 0.249960] xvda: xvda1 Apr 8 20:19:33 dev kernel: [ 0.250356] xvda: detected capacity change from 0 to 20401094656 Apr 8 20:19:33 dev kernel: [ 5.684101] EXT3-fs (xvda1): mounted filesystem with ordered data mode Apr 8 20:19:33 dev kernel: [ 140.547468] blkfront: barrier: empty write xvda op failed Apr 8 20:19:33 dev kernel: [ 140.547477] blkfront: xvda: barrier or flush: disabled Apr 8 20:19:33 dev kernel: [ 140.709985] EXT3-fs (xvda1): using internal journal Apr 8 21:18:12 dev kernel: [ 0.000000] Command line: root=/dev/xvda1 console=hvc0 ro quiet splash Apr 8 21:18:12 dev kernel: [ 0.000000] Kernel command line: root=/dev/xvda1 console=hvc0 ro quiet splash Apr 8 21:18:12 dev kernel: [ 1.439023] blkfront: xvda: barrier: enabled Apr 8 21:18:12 dev kernel: [ 1.454307] xvda: xvda1 Apr 8 21:18:12 dev kernel: [ 6.799014] EXT3-fs (xvda1): recovery required on readonly filesystem Apr 8 21:18:12 dev kernel: [ 6.799020] EXT3-fs (xvda1): write access will be enabled during recovery Apr 8 21:18:12 dev kernel: [ 6.839498] blkfront: barrier: empty write xvda op failed Apr 8 21:18:12 dev kernel: [ 6.839505] blkfront: xvda: barrier or flush: disabled Apr 8 21:18:12 dev kernel: [ 6.854814] EXT3-fs (xvda1): warning: ext3_clear_journal_err: Filesystem error recorded from previous mount: IO failure Apr 8 21:18:12 dev kernel: [ 6.854820] EXT3-fs (xvda1): warning: ext3_clear_journal_err: Marking fs in need of filesystem check. Apr 8 21:18:12 dev kernel: [ 6.855247] EXT3-fs (xvda1): recovery complete Apr 8 21:18:12 dev kernel: [ 6.855902] EXT3-fs (xvda1): mounted filesystem with ordered data mode Apr 8 21:18:12 dev kernel: [ 143.505890] EXT3-fs (xvda1): using internal journal 

2 Solutions collect form web for “Файловые системы ext3 root идут только для чтения с прерванным журналом даже после ремонта”

На данный момент я думаю, что это, скорее всего, экземпляр Debian Bug 637234 . Поскольку это облачная виртуальная машина, ядро ​​гипервизора находится вне моего контроля. Обходной путь использует barrier=0 в /etc/fstab для корневой файловой системы. Долгосрочное исправление заключается в том, чтобы перестроить ящик как экземпляр облачного пространства ragspace следующего поколения вместо экземпляра на основе Xen первого поколения.

«барьер = 0» в / etc / fstab поддерживается слишком поздно (и просто вступает в игру после того, как файловые системы подключаются к RW на более поздней стадии загрузки).

«барьер = выключен» в качестве дополнительного ядра. Параметр должен работать раньше и лучше.

Попробуй. Если ваш DomU запускается pygrub из Dom0 (который является «обычным» способом), вы можете поместить это в свою строку конфигурации grub-kernel в своем DomU.

  • Как я могу запускать скрипты на виртуальной машине, когда я вставляю CD или DVD в хост?
  • Пропуск PCI без VT-d
  • Xen: графический вывод на domU после промежуточной перегрузки GPU
  • Консоль отсоединения / уничтожения xm на сервере узла
  • Использовать dd для резервного копирования образа диска в контейнере OpenVZ
  • избегать локального адреса ссылки IPv6 на интерфейсе
  • Интерфейс часов не найден
  • Ошибка Debian 6.0 и Xen PyGrub
  • Как установить CUDA на Linux Mint с уже установленным Xen?
  • бенчмаркинг ftp в 3-х методах виртуализации
  • Что такое hvc0? (отображается в списке «кто»)
  • Interesting Posts

    Если ssh разрешает имена хостов из config при использовании режима ProxyCommand и netcat

    Перезагрузка smb.conf Samba4 без перезапуска службы

    Добавить в конце строки, используя sed

    Почему tmux запускается медленнее и медленнее с течением времени?

    Просмотр информационных страниц в браузере

    Установить модуль ядра

    Сортировка файлов по наивысшему числу в имени файла

    Скрытие данных в файловых системах

    Почему не удается удалить пользователя в Raspbian?

    Тихая статистика для проверки наличия файла

    Когда Samba работал в manjoro linux, демону не удалось запустить: Samba обнаружила неправильно сконфигурированную «роль сервера» и вышла.

    Проблемы с корневой файловой системой только для чтения

    Система управления документами для Linux

    Почему способность определять функции в переменной окружающей среды не является угрозой безопасности сама по себе?

    Разбор XML с использованием xmllint и настройка вывода

    Linux и Unix - лучшая ОС в мире.