Open codewithmichael opened 9 years ago
Removed the ready
label.
When
I mispoke. It is considered "active" because it's in RAM storage instead of on-disk.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.
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.
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.
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)
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
).
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.
Idea: At present, we could probably most easily verify the save state by checking if
Didn't have my coffee yet. This would just as easily match an image-backed active file system./mnt/wren/04-save
is mounted and its device begins with /dev/loop
.
Well, I guess we could go the long way:
$MOUNT_SAVE
is mounted using testIsMounted()
getExistingSaveImagePath()
and testImageLooped()
$MOUNT_SAVE
(via /proc/mounts
)
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.
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.
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.
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.
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.