At Fri, 19 Mar 2021 08:24:18 -0700, Brian Buhrow <buhrow%nfbcal.org@localhost> wrote: Subject: Re: trouble running FreeBSD with Xen-4.11 (including weird performance issues) > > hello. Although I'm not running NetBSD-9.99.xx as a dom0, I > wonder if this problem has anything to do with the maxphys limitations > in NetBSD being limited to 64k, but FreeBSD having a different maxphys > limitation in its xbd driver? A check of my system shows the > max_request_size set to 40960 bytes on FreeBSD-12.2. I remember a > similar mismatch problem exists between NetBSD-current and NetBSD-9, > the former having a maximum transfer length of 64k and the latter > having a maximum transfer length of 32k, leading to all sorts of > corruption issues. FreeBSD exports the relevant values to sysctl > read-only variables, so it's easy to check what they are on your > system. The source code for the block front end driver in FreeBSD > suggests these values are negotiated between the bak and front end > drivers, but I don't know how that negotiation works. Based on the > previously mentioned NetBSD bug between NetBSD-9 and NetBSD-current, > however, I'd venture to say the NetBSD drivers don't engage in this > negotiation process, what ever it is. Ah, I didn't know yet about the negotiation, nor about the problems between NetBSD-9 and NetBSD-current. Is the latter issue documented in an PR anywhere? I'd love to test it and see if it looks similar to the FreeBSD domU symptoms I'm seeing. My upgrade of Xen (and the dom0) didn't seem to cause any problems for a domU that is running NetBSD-5.2_STABLE. Here are the values I think you have referenced. Here xbd0 is the remade ISO (that's in a file on the dom0) which I'm able to boot from and which runs reliably; while xbd1 is a test LVM partition, the one on which I showed the failed newfs+fsck: dev.xbd.1.xenstore_peer_path: /local/domain/0/backend/vbd/134/832 dev.xbd.1.xenbus_peer_domid: 0 dev.xbd.1.xenbus_connection_state: Connected dev.xbd.1.xenbus_dev_type: vbd dev.xbd.1.xenstore_path: device/vbd/832 dev.xbd.1.features: flush dev.xbd.1.ring_pages: 1 dev.xbd.1.max_request_size: 65536 dev.xbd.1.max_request_segments: 17 dev.xbd.1.max_requests: 32 dev.xbd.1.%parent: xenbusb_front0 dev.xbd.1.%pnpinfo: dev.xbd.1.%location: dev.xbd.1.%driver: xbd dev.xbd.1.%desc: Virtual Block Device dev.xbd.0.xenstore_peer_path: /local/domain/0/backend/vbd/134/768 dev.xbd.0.xenbus_peer_domid: 0 dev.xbd.0.xenbus_connection_state: Connected dev.xbd.0.xenbus_dev_type: vbd dev.xbd.0.xenstore_path: device/vbd/768 dev.xbd.0.features: flush dev.xbd.0.ring_pages: 1 dev.xbd.0.max_request_size: 65536 dev.xbd.0.max_request_segments: 17 dev.xbd.0.max_requests: 32 dev.xbd.0.%parent: xenbusb_front0 dev.xbd.0.%pnpinfo: dev.xbd.0.%location: dev.xbd.0.%driver: xbd dev.xbd.0.%desc: Virtual Block Device > I'm guessing the other difference between your systems that work and > those that don't is that you're now running the FreeBSD guests in pvh > mode instead of hvm mode, since NetBSD didn't support guests in pvh > mode until very recently. By switching to pvh mode, you've now > introduced all these issues with the xbd driver, which weren't there > before because qemu was sitting between the two hosts pretending to be > a disk controller/disk. No, I don't think HVM vs PV is an issue -- the original production system that was corrupted by the upgrade was a full-on "traditional" HVM install. We tried PVH to get rid of QEMU and any other layers of emulation that might have caused problems, but nothing changed. -- Greg A. Woods <gwoods%acm.org@localhost> Kelowna, BC +1 250 762-7675 RoboHack <woods%robohack.ca@localhost> Planix, Inc. <woods%planix.com@localhost> Avoncote Farms <woods%avoncote.ca@localhost>
Attachment:
pgpgGO4tH7eDr.pgp
Description: OpenPGP Digital Signature