On 8 Sep 2016, at 20:35, Stefan Fritsch <[email protected]<mailto:[email protected]>> wrote: […] On Wed, 7 Sep 2016, Igor Boehm wrote: virtio0 at pci0 dev 3 function 0 "Qumranet Virtio Network" rev 0x00 vio0 at virtio0: address 52:54:a2:01:85:cd virtio0: msix shared virtio1 at pci0 dev 4 function 0 "Qumranet Virtio SCSI" rev 0x00 vioscsi0 at virtio1: qsize 128 scsibus2 at vioscsi0: 255 targets sd0 at scsibus2 targ 0 lun 0: <QEMU, QEMU HARDDISK, 2.5+> SCSI3 0/direct fixed sd0: 390625MB, 512 bytes/sector, 800000000 sectors, thin virtio1: msix shared virtio2 at pci0 dev 5 function 0 "Qumranet Virtio Memory" rev 0x00 viomb0 at virtio2 virtio2: apic 0 int 10
I know there have been reports about problems with virtio-scsi (openbsd driver vioscsi(4)) in the past. I could not reproduce these problems and thought they were maybe caused by very old qemu versions. But maybe there are also bugs in openbsd's vioscsi driver. How much control do you have over the VM? Can you change the disk type to virtio-block (openbsd driver vioblk(4))? That driver in openbsd is much better tested and works reliably (in my experience). I will try to reproduce the issue doing the same as you did. If I can't, I may get back to you for access to the VM. Thanks a lot for getting back to me. In the meantime I got in touch with support staff at Hetzner asking if they are aware of any issues with OpenBSD on their vServer products. They have responded swiftly and changed the hard disk virtualisation from VirtIO-SCSI to VirtIO-Block and asked me to retry. After the change to VirtIO-Block there are no more corruption issues whatsoever! After the fact, knowing what to search for on the internet I stumbled across your website [1] where you mention the following: - ``The virtio-scsi drivers in OpenBSD are (as of 5.6) not quite ready yet, don't use them. The choice between virtio-block and virtio-scsi is done in the qemu configuration.’’ So to summarise, the problem was *not* a race condition as I wrongly guessed initially, but a file system corruption (as pointed out correctly by Ted and Theo) caused by using vioscsi(4) over vioblk(4). The reason I maybe ran into the issue and you did not might be because I chose one of the beefier vServer options with a few CPUs, loads of RAM, and very fast SSDs. But that is just a wild guess so is probably wrong. Although things are working fine now my offer still stands. If you want to access to such a machine to debug/work on vioscsi(4) let me know and I will happily rent one for you for the duration of debugging/development. But we can probably best take that one offline if you are interested… Thanks everyone for bearing with me and helping me out! It is much appreciated! [1] http://www.sfritsch.de/openbsd-virtualization.html
