Am 18.04.24 um 13:10 schrieb Dominik Csapak: > On 4/18/24 12:35, Fiona Ebner wrote: >> Am 18.04.24 um 11:27 schrieb Dominik Csapak: >>> ok after a bit of thinking and discussing off-list >>> the plan to go forward from my side is this: >>> >>> (please tell if there is something obviously wrong with it or you'd >>> strongly prefer something differently) >>> >>> extract on demand vs on upload: >>> i'd go with extract on demand because managing the extraction of the >>> tarball + subdir etc is not really a win in my book, since we have to >>> have most safeguards anyway and we have the same >>> issue of where to store/map it etc. also it's not convenient for users >>> that have already >>> a bunch of ovas and want to store them in a central place, now they'd >>> have to extract >>> them just for us (and importing should be as small a hassle as it can >>> be) >>> >> >> The upside is that it would avoid all the extra cleanup handling and be >> more efficient for users that want to import from a single OVA multiple >> times. But you are right, the downside is also very big. >> >> I'm thinking now, is there no way to expose a file in an OVA/tar without >> actually extracting it? I.e. something like >> >>> root@pve8a1 ~ # cat B >>> secret >>> root@pve8a1 ~ # tar cf arch.tar A B dir >>> root@pve8a1 ~ # losetup --offset 1536 --sizelimit 512 --read-only >>> --show -f arch.tar >>> /dev/loop0 >>> root@pve8a1 ~ # cat /dev/loop0 >>> secret >> >> but that doesn't seem to work with sizelimit < 512. Not claiming losetup >> is a good mechanism for that, just to illustrate the idea. > > > AFAIU that only works for uncompressed tars and ova can by definition > be compressed, so that won't work reliably >
Okay, I didn't know that. Then it's not going to be nice and easy of course. > there is archivemount[0], which can fuse mount archives > > i tested that, and it's *very* slow for randomly accessing the files inside > (i guess because it must seek much further back to get the compression > state correct) > Yes, makes sense. > i tested a qemu-img convert from such a file and it took >10 minutes > for a file that would normally be extracted + converted in under a minute > > 0: https://github.com/cybernoid/archivemount > _______________________________________________ pve-devel mailing list pve-devel@lists.proxmox.com https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel