Should unmount when not using the fs?

[naNEQ]

This isn't in any way a bug, rather than me asking a question about best practices on using littlefs.

The question is, should the filesystem be unmounted when not being used for long periods of times? This is in the context of protecting the file system from corruption in case of power failure.

Without knowing any of the implementation details, intuitively what I'm thinking is that it's better to have the fs unmounted rather than mounted when the power is cut unexpectedly. But does it really matter? Is perhaps having it mounted all the time the same in this regards?

Also, when we do software reboot, should we first unmount the fs or again it doesn't really matter?

[BenBE]

A quick glance at the source of lfs_unmount, lfs_rawunmount and lfs_deinit shows no write access being performed in these situations, thus any data not already sync'd to the backend device before (by calling lfs_file_sync or lfs_file_close) will be lost.

So to answer your question: While freeing the resources you don't need is a good practice, it's not strictly required with littlefs in regards to unmounting. Looking at the design documentation it even was created with fault tolerance in mind. Nonetheless, you will need to ensure proper sync/close calls for all files you work on to retain your changes.

[geky]

As @BenBE mentioned, the only benefit to unmounting is to reclaim RAM. This might be useful if your application needs to use the RAM to do some other processing, but it should be noted remounting comes with a relatively high read-cost. This is higher in littlefs than other filesystems (but cheaper than logging filesystems) because littlefs needs to reconstruct "global state". this ends up touching every metadata block in the filesystem.

I suspect the best design for most applications is to mount the filesystem during startup and just never call unmount, unless you are physically removing the disk for some reason.