On Tue, Jul 26, 2011 at 08:03:35PM +0200, Juergen Lock wrote: > On Mon, Jul 25, 2011 at 06:31:36PM -0500, Brandon Gooch wrote: > > 2011/7/25 Andrey V. Elsukov <bu7c...@yandex.ru>: > > > On 25.07.2011 10:18, Joe Sciulli wrote: > > >> Is it possible to mount virtualbox vdi file on the FreeBSD host? This > > >> appears to be doable on > > >> windows and linux hosts, which basically is done in two steps: 1. find > > >> offset in the image. 2. > > >> mount the image with that offset. > > >> > > >> I'm trying to do the same thing on FreeBSD, and found the undocumented > > >> and deprecated command > > >> still works: > > >> > > >> VBoxManage internalcommands dumphdinfo freebsd_home.vdi > > >> > > >> I got the following for the virtual disk image holding the /home (no > > >> root hence no MBR) disk for > > >> a FreeBSD guest: > > >> > > >> Header: offBlocks=4096 offData=28672 > > >> > > >> Then attempt to mount it: > > >> > > >> mdconfig -a -t vnode -f /tmp/freebsd_home_56.vdi -u 0 mount /dev/md0 > > >> /tmp/aaa/ mount -t cd9660 > > >> /dev/md0 /tmp/aaa/ > > >> > > >> unfortunately both the above two mount commands failed with "Invalid > > >> argument". I tried > > >> skip=28672 to no avail as well. Anything did I do wrong? > > > > > > I have not any Vbox images with fixed size, but i tried this: > > > # mdconfig -f 10G_GPT_UFS.vdi > > > # gnop create -v -o 41472 /dev/md0 > > > > > > where 41472 is offData value. After that md0.nop was tasted and reports > > > about invalid GPT. > > > So, i think if your image is fixed size disk yout can try this method and > > > mount UFS (not cd9660). > > > > > > -- > > > WBR, Andrey V. Elsukov > > > > There was a CFT sent out a while back about a fuse module for mounting > > vdi images: > > > > http://lists.freebsd.org/pipermail/freebsd-emulation/2010-September/007964.html > > > > Not sure about the state of this now though... > > Yeah sorry I never got back to this after getting reports that > writes are stuck in wdrain... [1] I guess what happens is the > vdfuse process wants to write many(?) more blocks than the number > that got queued by the original fuse request and/or too many writes > get queued up at once before the vdfuse process gets to handle them > (trying to increase runningbufspace even more), and thus there is > deadlock. :( So my question for -hackers is, does anyone have a > clever idea how to fix this? Should the fuse requests for this be > exempted from the wdrain bookkeeping so that only the actual writes > by the vdfuse process get counted, and if yes, how would I best > accomplish this? > > Thanx! :) > Juergen
Excluding any buffers from runningbufspace is absolutely wrong. You will get another deadlock due to excessive pressure on the buffer space.
pgp5nwm9HUjrN.pgp
Description: PGP signature
