Kořenové souborové systémy Ext3 budou s přerušeným deníkem pouze pro čtení i po opravách?

Krátká verze:kořenový souborový systém ext3 na rackspace (xen) VM detekuje přerušený žurnál při spouštění a připojuje pouze pro čtení. Pokusil jsem se to opravit ze záchranného prostředí pomocí tune2fs a e2fsck jak je předepsáno v mnoha článcích, které jsem četl, ale k chybě dochází i nadále.

AKTUALIZACE :Takže na základě tohoto článku jsem přidal „barrier=0“ do /etc/fstab záznam pro tento souborový systém a při příštím spuštění se dobře připojil r/w. Domnívám se, že jde o paravirtualizaci, ale byl bych rád, kdyby někdo plně chápal, co se zde děje, a mohl to vysvětlit.

Dlouhá verze:

Rackspace VM právě upgradován z Ubuntu 11.10 na 12.04.2

výstup dmesg s chybou:

[   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

V záchranném OS jsem zkusil:

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

Také jsem spustil e2fsck -p , e2fsck -f a tune2fs -e continue . Zde je výstup 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

Také jsem grepoval některé řádky z /var/log/syslog v záchranném režimu s dalšími informacemi o chybě:

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

Přijatá odpověď:

V tuto chvíli si myslím, že se velmi pravděpodobně jedná o instanci chyby Debianu 637234. Jelikož se jedná o cloudový VM, jádro hypervizoru je mimo moji kontrolu. Řešením je použití barrier=0 v /etc/fstab pro kořenový souborový systém. Dlouhodobou opravou je přestavět box na cloudovou instanci rackspace nové generace namísto instance založené na Xenu první generace.

Související:Debian – pevné disky se roztočí procesy/aplikacemi, které jednoduše získají seznam disků? Jak zabránit?