The File Filesystem (2021)

This is really neat, but when I saw the headline I got excited that it was something I have been looking for / considering writing, and I figure the comments here would be a good place to ask if something like this exists:

Is there a FUSE filesystem that runs in-memory (like tmpfs) while mounted, and then when dismounted it serializes to a single file on disk? The closest I can find are FUSE drivers that mount archive files, but then you don't get things like symlinks.

does it have to be fuse? cant you mount a disk image with loopback

But will the disk image be fully stored in memory? No.. not with loopback. Either that, or it won't be mutable in memory with commit on unmount.

Not purely in-memory, but something like https://github.com/jrwwallis/qcow2fuse maybe? It's clunky compared to OSX's DMGs, but if you squint it achieves similar ends.

Otherwise you could achieve this with a tmpfs wrapped to serialize to a tarball (preserving symlinks) when unmounted.

Wouldn't a disk image have a fixed size? It could be a pain to resize.

I can't think of anything _exactly_ like that, but I think you can get close by just copying some type of image file to /tmp and then moving it to disk when you're done after unmounting.

qcow2 is auto-expanding

Closest I found: https://github.com/guardianproject/libsqlfs

> The libsqlfs library implements a POSIX style file system on top of an SQLite database. It allows applications to have access to a full read/write file system in a single file, complete with its own file hierarchy and name space. This is useful for applications which needs structured storage, such as embedding documents within documents, or management of configuration data or preferences. Libsqlfs can be used as an shared library, or it can be built as a FUSE (Linux File System in User Space) module to allow a libsqlfs database to be accessed via OS level file system interfaces by normal applications.

Oh nice, I didn't even know that existed. I've been using qemu-nbd and parted by hand and it gets cumbersome, so this might help a lot. Thanks!

/tmp isn't stored in memory; it's usually a normal on-disk filesystem that's cleared regularly. You want /dev/shm instead, which is a purely in-memory filesystem on normal Linux systems.

> /tmp isn't stored in memory

It is if your system uses tmpfs for /tmp

https://en.wikipedia.org/wiki/Tmpfs

The point they were trying to make is that it doesn't have to be, and it isn't in several of the Linux systems I've used over the years. Assuming that it is is a bad idea.

Put the disk image inside a ramdisk and it's in memory. Write a script for saving to physical disk when dismounting, and you're done.

/dev/shm always is though

Why does it have to be in memory?

I’m sure you’re already aware of this, but there are all kinds of very real scenarios that could lead to corrupted data if you’re only flushing the buffer upon unmounting.

Sounds like you’ve got an interesting problem you’re trying to solve though.

But not trivially loop-mountable. I guess it's possible, though. https://unix.stackexchange.com/questions/268460/how-to-mount...