wdrain vs. fuse/ggate (was: Re: mount vdi)

[Kostik Belousov]

On Tue, Jul 26, 2011 at 11:35:44PM +0200, Juergen Lock wrote:
> On Wed, Jul 27, 2011 at 12:22:34AM +0300, Kostik Belousov wrote:
> > 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 <bu7cher at 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.
> 
> Alright, so how to fix the deadlocks then? :)

In general, you cannot, without rearchitecturing the buffer deadlock
avoidance code.

md(4) is in similar situation, but there the i/o does not leave kernel.
You can look for VV_MD and similar hacks spreaded in sys/.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 196 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-hackers/attachments/20110726/6068a7b3/attachment.pgp