1 files changed, 42 insertions, 0 deletions
diff --git a/results/classifier/zero-shot/108/files/2117 b/results/classifier/zero-shot/108/files/2117
new file mode 100644
index 000000000..14d4657b6
--- /dev/null
+++ b/results/classifier/zero-shot/108/files/2117
@@ -0,0 +1,42 @@
+files: 0.923
+graphic: 0.775
+device: 0.763
+other: 0.643
+performance: 0.631
+semantic: 0.557
+PID: 0.548
+debug: 0.418
+permissions: 0.364
+boot: 0.360
+vnc: 0.351
+socket: 0.344
+network: 0.201
+KVM: 0.025
+
+Unraid, Ubuntu, 9P/virtio and memory issues
+Description of problem:
+I am running an Ubuntu VM on Unraid - which is using Qemu. I am exposing my shares through "9p Mode" to the VM.
+
+The logs shows:
+-fsdev local,security_model=passthrough,id=fsdev-fs0,path=/mnt/user/backup \
+-device '{"driver":"virtio-9p-pci","id":"fs0","fsdev":"fsdev-fs0","mount_tag":"backup","bus":"pci.1","addr":"0x0"}' \
+
+Inside Ubuntu, I mount the exposed shares like this:
+
+sudo mount -t 9p -o trans=virtio "backup" /media/share/backup
+
+I have a script that uses rsync to sync the files from these mounted shares onto an internal disk drive. 
+
+The issues that I am facing, is that rsync sometimes reports "cannot allocate memory":
+
+rsync: [sender] readdir("/media/share/backup/myfolder"): Cannot allocate memory (12)
+ 
+There are "ten thousands" of files in that folder hierarchy, but there are plenty of memory available on the VM (many GBs), so that is no issue. The next time I run the job, it might go through as normal. But I would like to get rid of these issues.
+
+The question is: Is there some kind of memory allocation/limit to the virtio/9p as well? If yes - is there some way to increase it to avoid these errors?
+Steps to reproduce:
+1. Mount as shown
+2. Run rsync on folder with lots of files
+3. See error
+Additional information:
+N/A