Hi, Miriami wrote: > 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.
I remeber that filesystems in general have been declared dead about twenty years ago. (But who needs filesystems or databases in times of AI ?) > 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. What's not written in C will be rotten in foreseeable time. Grumpy sarcasm aside: > 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. Note that the sparse file behavior depends on the hosting filesystem, which contains your large sparse file, not on the filesystem inside that file. The ext4 inside the file will do what it does with an arbitrary storage device of the given nominal size (i.e. the size of the file in "ls -l", not in "du"). > I need to fuse a virtual > filesystem for the poor Debian on that device, > with backing storage on the NTFS partition > visible for Windows. > [...] > 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. So you will have to test the sparse file behavior of NTFS with an ext4 inside the sparse NTFS file. > that > commercial software frequently performs > full-disk scan 'for the sake of user security'. I wonder what it will say about a large file with obscure content ... Have a nice day :) Thomas
