summary refs log tree commit diff stats
path: root/results/classifier/108/permissions/1254940
diff options
context:
space:
mode:
Diffstat (limited to 'results/classifier/108/permissions/1254940')
-rw-r--r--results/classifier/108/permissions/1254940111
1 files changed, 111 insertions, 0 deletions
diff --git a/results/classifier/108/permissions/1254940 b/results/classifier/108/permissions/1254940
new file mode 100644
index 000000000..707e47a4c
--- /dev/null
+++ b/results/classifier/108/permissions/1254940
@@ -0,0 +1,111 @@
+permissions: 0.963
+graphic: 0.962
+other: 0.953
+performance: 0.948
+device: 0.945
+debug: 0.941
+socket: 0.940
+semantic: 0.940
+PID: 0.933
+boot: 0.918
+files: 0.914
+network: 0.897
+KVM: 0.824
+vnc: 0.777
+
+qemu-KVM guest OS occurs many ext3-fs errors after multiple forced shutdown 
+
+Hi:
+I met some filesysterm errors in a sles guest on KVM. My system environment is:
+HOST: 
+   suse 10, the kernel version is 2.6.32.43 
+   Qemu-KVM 1.2 
+   Libvirt 1.0
+guest OS: 
+   suse 10, the kernel version is 2.6.32.43
+VMs use a qcow2 disk. 
+
+Description of problem:
+I have 20+ VMs with qcow2 disk, these VMs have been forced to shut down by
+"virsh destroy" many times during and after VM installation.
+When these vm reboot,dmesg show a ext3-fs mount error occurred on /usr/local
+partion /dev/vda3:
+    EXT3-fs warning: mounting fs with errors, running e2fsck is recommendedand
+when I wrote into partion /dev/vda3,some errors occurred in dmesg:
+1.error (device vda3): ext3_free_blocks: Freeing blocks not in datazone - block
+= 1869619311, count = 1error (device vda3): ext3_free_blocks_sb: bit already
+cleared for block 2178152error (device vda3): ext3_readdir: bad entry in
+directory #1083501: 
+2.[347470.661893] attempt to access beyond end of device[347470.661896] vda3:
+rw=0, want=6870892952, limit=41945715[347470.661897] EXT3-fs error (device
+vda3): ext3_free_branches: Read failure, inode=1083508, block=858861618
+3.EXT3-fs error (device vda3): ext3_new_block: block(4295028581) >= blocks
+count(-1) - block_group = 1, es == ffff88021b6c7400
+
+I suspect this fs-error is caused by multiple forced shutdown, but I can't
+reproduce this bug now.
+
+Could anyone has an idea or suggestion to help me? 
+
+Thanks in Advance
+Regards
+Ben 
+
+Reproducible: Always
+
+Steps to Reproduce:
+I can't reproduce this bug now.
+
+
+additional:
+1.multiple forced shutdown during and after the vm installing
+2.vm with qcow2 disk
+3.different vm dmesg different errors in above error list(1/2/3)
+
+On Tue, Nov 26, 2013 at 01:59:41AM -0000, benjamin_zb wrote:
+> I met some filesysterm errors in a sles guest on KVM. My system environment is:
+> HOST:
+>    suse 10, the kernel version is 2.6.32.43
+>    Qemu-KVM 1.2
+>    Libvirt 1.0
+> guest OS:
+>    suse 10, the kernel version is 2.6.32.43
+> VMs use a qcow2 disk.
+> 
+> Description of problem:
+> I have 20+ VMs with qcow2 disk, these VMs have been forced to shut down by
+> "virsh destroy" many times during and after VM installation.
+> When these vm reboot,dmesg show a ext3-fs mount error occurred on /usr/local
+> partion /dev/vda3:
+>     EXT3-fs warning: mounting fs with errors, running e2fsck is recommendedand
+> when I wrote into partion /dev/vda3,some errors occurred in dmesg:
+> 1.error (device vda3): ext3_free_blocks: Freeing blocks not in datazone - block
+> = 1869619311, count = 1error (device vda3): ext3_free_blocks_sb: bit already
+> cleared for block 2178152error (device vda3): ext3_readdir: bad entry in
+> directory #1083501:
+> 2.[347470.661893] attempt to access beyond end of device[347470.661896] vda3:
+> rw=0, want=6870892952, limit=41945715[347470.661897] EXT3-fs error (device
+> vda3): ext3_free_branches: Read failure, inode=1083508, block=858861618
+> 3.EXT3-fs error (device vda3): ext3_new_block: block(4295028581) >= blocks
+> count(-1) - block_group = 1, es == ffff88021b6c7400
+> 
+> I suspect this fs-error is caused by multiple forced shutdown, but I can't
+> reproduce this bug now.
+> 
+> Could anyone has an idea or suggestion to help me?
+
+What are the mount options for this ext3 file system?
+
+In particular, make sure the barrier=1 option is set.
+
+From linux/Documentation/filesystems/ext3.txt:
+
+  Write barriers enforce proper on-disk ordering of journal commits,
+  making volatile disk write caches safe to use, at some performance
+  penalty.
+
+Stefan
+
+
+[Expired for QEMU because there has been no activity for 60 days.]
+