On Mon, Jan 18, 2016 at 12:38 PM, Gerd Hoffmann <kra...@redhat.com> wrote: > On Fr, 2016-01-15 at 21:08 +0300, Andrey Korolyov wrote: >> Just checked, Linux usb driver decided to lose a disk during a >> 'stress-test' over unpacking linux source instead of triggering an >> assertion in 2.5 (and to irreparably damage its ext4 as well), > > Ok, so behavior changed here from 2.2 -> 2.5. I don't see disk > corruption in my tests, but linux guest resets the usb-storage device > now and then. Seems to be able to resume operations though, there are > no disk errors in the logs.
Thanks for checking, I`ve seen a couple of bus resets as well and suddenly guest froze with 'fs remounted as ro' message splat over physical console. Of course I didn`t set any external kernel logging or pstore at a time and I could only assume that same timeouts was a general cause of a corruption itself (more likely some inflights was lucky enough to finish while others did not made it, but I don`t see a way to corrupt a superblock *that bad*). > >> NetBSD >> 7.0 reboot action hangs on USB_RESET and NetBSD 5.1 triggers second of >> mentioned asserts. Backend itself is a regular USB2-SATA adapter with >> Intel S3500 SSD, hence it should not trigger first timing-related >> assertion at all. > > ok. Had no trouble with freebsd, will go fetch netbsd images. What > arch is this? i386? x86_64? i386 7.0 for the reference, but I`m sure that this wouldn`t matter in any way. Just to mention - ancient 2.6, like 2.6.18, are actually doing things quite faster using same frontend+backend combination, may be due to lack of proper timeout checks... Actually there is a very small chance that the real performance regression was introduced during further development, so I instead believe in improper interaction of a newer guest EHCI driver and qemu frontend. Please let me know if any countable measurements like fio could be a matter of interest - I don`t think that many people are concerned about USB/USB2 frontend performance at all, since they are bringing in a ton of unwelcomed wakeups and the one thing which could be a matter of concern in that case is an emulated xHCI, IMHO. > > cheers, > Gerd >
