<rdf:RDF
    xmlns:s='http://snipsnap.org/rdf/snip-schema#'
    xmlns:rdf='http://www.w3.org/1999/02/22-rdf-syntax-ns#'
    xml:base='http://blog.derjohn.de/rdf'>
    <s:Snip rdf:about='http://blog.derjohn.de/rdf#start/2007-06-22/1'
         s:name='start/2007-06-22/1'
         s:cUser='derjohn'
         s:oUser=''
         s:mUser='derjohn'>
        <s:content>1 vmware-loop (and vmware-mount) really sucks! {anchor:vmware-loop (and vmware-mount) really sucks!}&#xD;&#xA;Several times I tried to mount a .vmdk file on a linux host directly in order to run some backups. But the box crashed to hard, that I had to reset-finger it. I found a {link:small vmdk-mount hack|http://www.cse.unsw.edu.au/~matthewc/vmdk-loop/} from a australian coder, who told me, what the architecutral problem with both of those utils is (his own as well as the one from vmware)&#xD;&#xA;&#xD;&#xA;{code}&#xD;&#xA;matthewc&gt; when the system is low on memory, the Linux kernel instructs nbd to write out all its dirty buffers&#xD;&#xA;matthewc&gt; but in order to do that, nbd needs to talk to the userspace process&#xD;&#xA;derjohn&gt; hm, that sounds like the problem vmware-loop itself has ...&#xD;&#xA;matthewc&gt; and you get this recursive wait situation where the userspace process is blocked waiting on a memory allocation, but nbd needs to talk to it to make memory&#xD;&#xA;{code}&#xD;&#xA;&#xD;&#xA;It&apos;s time to port that or something similar to FuSE.&#xD;&#xA;&#xD;&#xA;UPDATE: I asked kernel-people of the Linux-VServer project about nbd and add here an excerpt of the chat, that might be interesting,too:&#xD;&#xA;&#xD;&#xA;{code}&#xD;&#xA;&lt;Bertl&gt; derjohn: the main question is &apos;used for what?&apos; I assume buffers and caches :)&#xD;&#xA;&lt;Bertl&gt; derjohn: I also assume that it requires kernel memory (which is not pageable anyways)&#xD;&#xA;&lt;bonbons&gt; derjohn: I played with nbd, but until now I got not so good results, with XFS on to of it (either crashed or BUG() and processes ending in D state)&#xD;&#xA;&lt;bonbons&gt; but I wonder why nbd needs the client process to keep hanging around, it could do as is done be kernel for nfs or smb mounts, have the network connection live completely in kernel space&#xD;&#xA;&lt;derjohn&gt; well, doesnt sound like a good idea to rely on nbd ;)&#xD;&#xA;&lt;bonbons&gt; derjohn, I file a bug for that on kernel bugzilla some time ago: http://bugzilla.kernel.org/show_bug.cgi?id=7364&#xD;&#xA;{code}&#xD;&#xA;&#xD;&#xA;&#xD;&#xA;</s:content>
        <s:mTime>2007-07-03 20:11:49.0</s:mTime>
        <s:cTime>2007-06-22 14:51:52.0</s:cTime>
        <s:comments
             rdf:type='http://www.w3.org/1999/02/22-rdf-syntax-ns#Bag'/>
        <s:snipLinks>
            <rdf:Bag>
                <rdf:li rdf:resource='http://blog.derjohn.de/rdf#start/2007-06-22/1/'/>
                <rdf:li rdf:resource='#snipsnap-search'/>
                <rdf:li rdf:resource='http://blog.derjohn.de/rdf#start/2006-09-27/'/>
                <rdf:li rdf:resource='http://blog.derjohn.de/rdf#start/2006-11-10/1:3'/>
                <rdf:li rdf:resource='http://blog.derjohn.de/rdf#barabaka/Effexor-er.html'/>
                <rdf:li rdf:resource='#derjohn'/>
                <rdf:li rdf:resource='#snipsnap-index'/>
                <rdf:li rdf:resource='http://blog.derjohn.de/rdf#start/2007-06-27/1'/>
            </rdf:Bag>
        </s:snipLinks>
        <s:attachments
             rdf:type='http://www.w3.org/1999/02/22-rdf-syntax-ns#Bag'/>
    </s:Snip>
</rdf:RDF>

