Thank you! I haven't noticed that I could allocate some space for an ext4 image, as though the image in fact do not occupy that much physical space.
I would test about this and I think this would work - just a feeling. About qcow - yes, qcow occured to me. When creating an VM, qcow format could be used to provide a virtual disk which dynamically grows. However, I didn't dig into researching about it. Now I think again and changed my mind - I think qcow might work as well - but I would firstly try the ext4 image solution, which sounds simpler. About the projects I've found - I searched with three terms on GitHub - 'sqlite', 'fs' and 'fuse'. It is surprisingly large number of projects come up with the same idea of using SQLite as a backing file system storage. This probably has something to do with how the SQLite developers have put an article in the documentation, about their research that with certain sector size, SQLite perform better than file systems for large number of tiny files - that article should title something like 'SQLite is Faster Than Filesystem'. However, those projects I've found are *all* abandoned and without maintaince. The relatively most mature one of them is written in Rust, with a 700+ lines of pull request about upgrading the Rust library used by the project and updating the API calls to meet the new library version. This is a good pull request to my view, but there is no respond from neither the maintainer nor other users for like several months. Out of maintaince, I guess. As a result, I decide that I would go and try with ext4. I would firstly put some files in and see how much the image grows physically. I guess it won't overgrow - ext4 doesn't store files for extra copies, right? I guess the sparse file mechanism would work fine. About the motivation of why am I looking for such a fuse filesystem - it is for a device that I don't regularly use, where there is dual-boot installed, one Windows and one Debian, and Windows occupies most of the disk space in its NTFS partition, so I need to fuse a virtual filesystem for the poor Debian on that device, with backing storage on the NTFS partition visible for Windows. The awful part is that, I need to run a commercial software on the Windows system of that device, and that commercial software frequently performs full-disk scan 'for the sake of user security'. Due to this, I come up with the idea of only leaving *one* file visible to the Windows system - that disk-scanning software - so that there would be less trouble. In fact, that device is primarily for the use of that commercial software, other I won't install Windows, but simply use a VM when I have to. Besides the fuse filesystem backing storage, I also keep the Windows environment clean - no any other software installed - otherwise, the more files visible to that disk-scanning, the worse it would be. Firstly it would get lagged, and secondly it might try to 'protect the user's security' and try to fight with my files which it feels suspicious. I think a better solution might be setting up a dedicated device for that disk-scanning software. I'm still thinking about this, and I would probably need to further clean up the room for space for an extra device. Or maybe I would try reverse enginnering that commercial software and mock its disk scanning function. But this would probably get done really slowly, and I would need to keep up with the update. If that software guard itself hard enough and secure itself by loading dynamic machine instructions from network from its server, the reverse engineering might become impossible. Anyway, I would try ext4 sparse file and it would probably work, I guess. But eventually I think I would get a new hardware to ease the efforts. Thank you! I haven't thought about the sparse thing and that seems to be able to do the thing I want to. Miriami
