5 ms·

Why not use a local loop mount? You'd still have a filesystem in a single file. At least on Linux.

akira2501 12y ago
Storage overhead. The loopback device is still a block device, if you skip this step, you don't have to waste the block overhead when storing a file that's smaller than the block size. If you're going to store a large number of small-sized files, this fuse <-> sql bridge could be a win.
- shawnz 12y ago
  But this has block overhead too. Why not just use a smaller block size?
  - Dylan16807 12y ago
    It uses blocks but records get packed on disk. (I think; it's certainly capable of it.) More obvious is that the database as a whole is dynamically sized.
- justincormack 12y ago
  Some filesystems can compress in this case.
krylon 12y ago
I do not know if the library takes advantage of it, but using an ACID-compliant database as the backend, one could make use of transactions at the filesystem level.
- rakoo 12y ago
  Something that's lacking in the Linux world is an efficient way to determine "what file has changed since that time". Using SQLite db could be really helpful in this situation.
eighthave 12y ago
I'm the lead dev on Guardian Project's work on libsqlfs. Our interest in libsqlfs is as a backend to IOCipher, which is an Android framework that makes it dead simple for app developers to store files in an encrypted virtual disk. Using libsqlfs gives us a C API to a file system (it is a FUSE API), that means IOCipher can provide a per-app encrypted filesystem on unmodified Android systems without needing root access or really any special permission at all. https://guardianproject.info/code/iocipher/ https://guardianproject.info/code/iocipher/ libsqlfs could also be used as a cross-platform disk container, like OSX's .dmg files or TrueCrypt files. As long as SQLCipher is installed, then the libsqlfs container can be entirely encrypted, including metadata.

Storage overhead. The loopback device is still a block device, if you skip this step, you don't have to waste the block overhead when storing a file that's smaller than the block size. If you're going to store a large number of small-sized files, this fuse <-> sql bridge could be a win.

shawnz 12y ago
But this has block overhead too. Why not just use a smaller block size?
- Dylan16807 12y ago
  It uses blocks but records get packed on disk. (I think; it's certainly capable of it.) More obvious is that the database as a whole is dynamically sized.
justincormack 12y ago
Some filesystems can compress in this case.

krylon 12y ago

I do not know if the library takes advantage of it, but using an ACID-compliant database as the backend, one could make use of transactions at the filesystem level.

rakoo 12y ago
Something that's lacking in the Linux world is an efficient way to determine "what file has changed since that time". Using SQLite db could be really helpful in this situation.

eighthave 12y ago

I'm the lead dev on Guardian Project's work on libsqlfs. Our interest in libsqlfs is as a backend to IOCipher, which is an Android framework that makes it dead simple for app developers to store files in an encrypted virtual disk. Using libsqlfs gives us a C API to a file system (it is a FUSE API), that means IOCipher can provide a per-app encrypted filesystem on unmodified Android systems without needing root access or really any special permission at all. https://guardianproject.info/code/iocipher/ https://guardianproject.info/code/iocipher/ libsqlfs could also be used as a cross-platform disk container, like OSX's .dmg files or TrueCrypt files. As long as SQLCipher is installed, then the libsqlfs container can be entirely encrypted, including metadata.