Option to disable active data file system

[codewithmichael]

• Addresses issue #27 (Add option to disable active Btrfs)

This commit adds a boot option, BOOT_NO_ACTIVE_FS, to disable Btrfs as the active data storage file system, falling back to storing data directly in the running system's tmpfs mount.

[codewithmichael]

Removed the ready label.

When wren usage is called, the store section still displays an active value even when $is_active_fs is 0 (zero/false); e.g. when the BOOT_NO_ACTIVE_FS option is used. An alternate value such as tmpfs or simply none would be more appropriate. I mispoke. It is considered "active" because it's in RAM storage instead of on-disk.

Additionally, the USAGE_ACTIVE_* values are correctly blanked out in wren usage (though the code could probably be formatted better to avoid duplication), but they are still being calculated higher up in setUsageStats() for no reason. Also, while the USAGE_ACTIVE_* values are blanked out, it looks like they could possibly still be run though the human readable parsing below the blanking section.

[codewithmichael]

On second thought, perhaps the USAGE_ACTIVE_USED value shouldn't be blanked out at all, as it can be used to determine how much memory is dedicated to active file storage.

[codewithmichael]

We could add the mount type in parentheses at the end of the store line in wren status to inform the user of file system capabilities — e.g.:

store: active (btrfs)
store: active (tmpfs)
store: save (ext2)

[codewithmichael]

Alternately, we could add storefs and storesize line items to wren status which would still show the file system but would also take filesystem compression into consideration (via du -bd0).

[codewithmichael]

BUG: When BOOT_SAVE_TO_RAM is false but there is no save image, the actual store state is active, not save, because there's no way to store to a non-existent save image. wren status should show store: active and display the active line in wren usage instead of the save line.

This isn't technically a bug in the new code, but it all overlaps and stems from the same root cause. Instead of just checking boot options, active status needs to be determined by the actual state of the filesystem.

[codewithmichael]

Idea: At present, we could probably most easily verify the save state by checking if /mnt/wren/04-save is mounted and its device begins with /dev/loop. Didn't have my coffee yet. This would just as easily match an image-backed active file system.

[codewithmichael]

Well, I guess we could go the long way:

• Check if $MOUNT_SAVE is mounted using testIsMounted()
  • If no = tmpfs active store
  • If yes:
  • Check if save file is looped using getExistingSaveImagePath() and testImageLooped()
    • If no = not save store (active for current purposes)
    • If yes:
    • Check if save image device loop is mounted at $MOUNT_SAVE (via /proc/mounts)
      • If no = not save store (active for our purposes)
      • if yes = save store

We can (and probably should) go through a similar verification process for active status by checking if the active image exists and is looped, if the expected volume and subvolume exist, and if the subvolume is bind mounted to $MOUNT_SAVE — or more simply we could probably just verify that last bit.

But there isn't currently another concept in the system besides "save" and "active" stores. If someone were to fake the active store by mounting something else at $MOUNT_SAVE (1) they would be subverting wren and should expect unknown side effects and (2) the only thing that would break would potentially be the free store/ram estimations in wren usage.

It's probably best to leave a third "unknown" or "custom" store type for another day/releas. Otherwise this ticket's going to balloon to unforeseeable proportions.

[codewithmichael]

I added 3 new functions to platform-env to more globally accommodate the new functionality:

• testIsCurrentActiveImage()
• testIsActiveImageSave()
• testIsActiveImageActiveVolume()

The latter 2 are now used in wren (control script) to determine whether a save or active file system are in use. Boot parameters are no longer directly used in any way to determine these states.

[codewithmichael]

Almost ready. I noticed that wren usage still shows the "unallocated" column when there in no active file system. Since all memory is shared at that point, the column will always return the "free" value and, therefore, serves no purpose.

[codewithmichael]

I added a basic comment where it's calculated, but it would severely clash with #31 if we tried to remove it from the table in this ticket, since #31 totally reformats the table.

I'll post a separate PR to remove the column when there's no active file system once they have been merged.