짧은 버전: 랙스페이스(xen) VM의 ext3 루트 파일 시스템은 부팅 시 중단된 로그를 감지하고 읽기 전용으로 마운트합니다. 내가 읽은 많은 기사에 설명된 대로 복구 환경에서 이 문제를 해결해 보았 tune2fs으나 e2fsck여전히 오류가 발생합니다.
고쳐 쓰다: 그래서 기반으로이 기사/etc/fstab해당 파일 시스템의 항목 에 "barrier=0"을 추가 하고 다음 부팅 시 읽기-쓰기로 정상적으로 마운트했습니다. 나는 이것이 반가상화라고 생각하지만 누군가 여기서 무슨 일이 일어나고 있는지 완전히 이해하고 설명할 수 있다면 기쁠 것입니다.
긴 버전:
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
구조 OS에서 다음을 시도했습니다.
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
/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
답변1
이 시점에서 이것이 가장 좋은 예라고 생각합니다.데비안 버그 637234. 이는 클라우드 VM이므로 하이퍼바이저 커널은 내 통제 범위를 벗어납니다. 해결책은 barrier=0in을 /etc/fstab루트 파일 시스템으로 사용하는 것입니다. 장기적인 솔루션은 1세대 Xen 기반 인스턴스가 아닌 차세대 랙 공간 클라우드 인스턴스로 상자를 재구축하는 것입니다.
답변2
/etc/fstab의 "barrier=0"은 너무 늦을 수 있습니다(파일 시스템이 나중에 부팅 단계에서 RW를 마운트할 때까지 작동하지 않습니다).
추가 커널 매개변수인 "barrier=off"는 더 빠르고 더 잘 작동해야 합니다.
시도 해봐. DomU가 pygrub에 의해 Dom0에서 부팅된 경우("일반적인" 방식) 이를 DomU의 grub-kernel-configuration-line에 넣을 수 있습니다.