ext3 sistemas de arquivos raiz se tornam somente leitura com diário abortado mesmo depois de reparos

Question

Versão resumida: sistema de arquivos raiz ext3 no rackspace (xen) A VM detecta o diário interrompido na inicialização e monta somente leitura. Eu tentei consertar isso de um ambiente de resgate com tune2fs e e2fsck como prescrito em muitos artigos que li, mas o erro continua a acontecer.

UPDATE : Então, com base em este artigo I adicionou "barrier = 0" à entrada /etc/fstab para este sistema de arquivos e montou r / w fine na próxima inicialização. Eu sou levado a acreditar que isso é uma coisa de paravirtualização, mas adoraria se alguém entendesse o que está acontecendo aqui e pudesse explicar.

Versão longa:

Rackspace VM acabou de ser atualizado do Ubuntu 11.10 para 12.04.2

dmesg output com o erro:

[   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

Em um sistema operacional de resgate, eu tentei:

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

Eu também executei e2fsck -p , e2fsck -f e tune2fs -e continue . Aqui está a saída de 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

Também usei algumas linhas de /var/log/syslog no modo de recuperação com algumas informações adicionais de erro:

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

    

Answer 1

Neste ponto, estou pensando que isso é muito provavelmente uma instância do Debian Bug 637234 . Como esta é uma VM na nuvem, o kernel do hypervisor está fora do meu controle. A solução alternativa é usar barrier=0 em /etc/fstab para o sistema de arquivos raiz. A correção a longo prazo é reconstruir a caixa como uma instância de nuvem de rackspace de última geração em vez de uma instância baseada em Xen de primeira geração.

    

Answer 2

"barrier = 0" em / etc / fstab é provavelmente muito tarde (e só entra em jogo depois que os sistemas de arquivos são montados em RW em um estágio de inicialização posterior).

"barreira = off", pois o parâmetro-kernel adicional deve funcionar mais cedo e melhor.

Experimente. Se o seu DomU está sendo iniciado pelo pygrub do Dom0 (que é a maneira "usual"), você pode colocar isso na sua linha de configuração do kernel do kernel em seu DomU.