3 ms·
That would be amazing! To work though, you'd need some kind of interface to actually access the contents. I guess that's doable, but not ideal. Someone else p
by GordonS 7y ago
That would be amazing!
To work though, you'd need some kind of interface to actually access the contents. I guess that's doable, but not ideal.
Someone else posted libsqlfs, which is FUSE Sqlite file system, and should do the job...not exactly plug-and-play though, and presumably wouldn't work on Windows (maybe on WSL tho?)
- Fnoord 7y agoWSL1 is terrible for I/O (which I suppose this is). WSL2 should be adequate. Perhaps Dokan? Dokan has a FUSE wrapper [1] [1] https://dokan-dev.github.io https://dokan-dev.github.io
- majewsky 7y agoNot sure if /s :) With a FUSE filesystem, you're still incurring the syscall overhead that's causing this performance disparity in the first case, plus now the kernel has to context-switch into the FUSEing process. So what would be 2 context switches for each syscall (program -> kernel -> program) now is 3 or 4 context switches (program -> kernel -> FUSE -> (kernel ->) program). FUSE has some amazing usecases, but performance is none of them.
- GordonS 7y agoErm, no, no sarcasm, but in truth I know very little about FUSE, beyond it being an API for userland file systems. I'm also approaching this as primarily a Windows user - a lot of the overhead on Windows is access checks, so my thinking is these would be implemented as noops.