Replace LVM with Btrfs

[codewithmichael]

Addressed Issues:

• 8 - Move to /opt/wren

• 10 - Investigate ZFS and Btrfs

• 22 - Incorrect active data capacity at startup

• 23 - Cron job to increase active data capacity

This pull request addresses issue #10 (Investigate ZFS and Btrfs) by fully replacing LVM with Btrfs and reintegrating snapshot functionality into Wren.

With these changes, Wren now boots using a Btrfs subvolume to store in-memory active save data. All supporting scripts have been updated to accommodate the change, maintaining their existing functionality with the exception of snapshots being re-enabled in save.sh.

All references to LVM functionality have been removed from the code base and the watershed and lvm2 package dependencies have been removed. However, LVM-related platform variables have been maintained with DEPRECATED headers in the platform.conf file to (temporarily) continue support of booting custom save instances based on version 0.1.x.

Documentation has been updated to reflect the change.

Notes:

• While making the changes I noticed that that boot script (initramfs-script) incorrectly uses the getFileSize function to determine the size of the save file in order to calculate required active storage capacity. This doesn't take into account the sparse nature of save files and should be updated. I will file a separate issue on the matter. For the time being, I have maintained the existing functionality.
• To avoid changing the public API in any way, I have neither added or removed any functionality with the exception of re-enabling snapshot capability during the save process. However, the switch to Btrfs for active data storage allows for some additional features. Notably, active save size can easily be decreased via a command like: sudo btrfs filesystem resize -1G /mnt/wren/xx-volumes/active. This, of course, does not handle shrinking the backing (sparse) image.
• As there have been no public API changes, the Wren GUI project continues to act as a functional interface for this version of Wren. (not since moving to /opt/wren)
• Platform LVM values have been retained in a deprecated state in platform.conf to avoid making it impossible to boot custom save images. Existing images should be rebuilt, but it is necessary to maintain these values for at least one release cycle to allow conversion of existing saves.

Update Instructions:

• Use wrender to build new initrd.img-* and platform-* images and replace the existing images on the boot device in /boot/images/ (common mount path: /mnt/wren/00-device/boot/images/).
  • Custom save images should also be rebuilt and replaced.
• Copy conf/platform.conf to the boot device's /boot/conf/ directory, replacing the existing platform.conf instance.
• Reboot.

[codewithmichael]

Update instructions should be included in README.md.

[codewithmichael]

There are some interesting differences with Btrfs. I'm using Wren GUI to monitor active space usage and changes.

• It's very noticeable that Btrfs only creates COW B-tree checkpoints (and thereby updates the file system's meta data and the user's insight into potential disk usage) every 30 seconds.
  • Performing a manual sync call forces a checkpoint write, so we should do that in save.sh after creating the snapshot or before starting the copy.
  • Since we're working in memory, I don't know of a reason we can't perform this more regularly — perhaps every five seconds(?). There's a mount option to change it; commit=X, where X is the number of seconds between checkpoints. Since we're often dealing with a small memory buffer, this would probably make things easier on the average user.
• There are additional mount options that may be useful to us given Wren's in-memory nature:
  • nobarrier - disregards checking for device barriers - since we're not using more than one storage device (an image file in this case) this could provide a performance improvement
  • notreelog - disables B-tree history logging - it wouldn't be a good idea if we were using Btrfs for the save file, as tree logging prevents inconsistent data after a power failure and allows for file system recovery, but in case of power failure our unsaved active data would be gone anyway.
• Btrfs alots/uses a bit more in-filesystem storage for its COW functionality (upwards of 200 MB on a new 1 GB instance) than was the case with ext3 journaling. However, this space is not excluded from the reported file system size, so while active save may register as 1GB and may only be using 14 MB it will still report less than 800 MB free. This is not a problem in and of itself, but it may confuse users. If we go forward as is it should be well documented.

[codewithmichael]

I updated the mount options for the active Btrfs volume. New options are as follows:

commit=5,notreelog,nobarrier,flushoncommit

These are in addition to the default options rw,noatime,loop.

flushoncommit ensures all dirty file data is flushed to disk (or memory in this case) when a transaction is committed and should be the default on modern kernels, but it doesn't hurt to manually specify it to be safe.

[codewithmichael]

A sync is now performed after taking the snapshot just to ensure the B-tree and associated metadata are up to date before copying to disk. This should automatically happen when the snapshot is created, but (as previously mentioned) it's a comprehensive measure to ensure the user can see how much space is actually used.

[codewithmichael]

So I experimented a bit with compression (mount option: compress=X). zlib provides the best compression, but it's slower than lzo, which I think is the better default.

I think this would be a great feature to add, as it leaves more available RAM for either extending the save size or just for general usage. However, it does create an issue with reporting, as df and du typically measure the actual disk usage, and monitoring applications like Wren GUI may incorrectly report the actual size of the file as they relate to the purpose of saving.

To get around that, the following command appears to provide the actual file sizes (in bytes), or at least a close approximation so long as both filesystems are using a 4K block size:

du -xa -B1 -d0 /mnt/wren/04-save | cut -f1

If we get Wren GUI updated with that command before releasing a Btrfs distro things should work out ok without confusing anyone.

Side Note: It's probably best to move the active volume mount options into platform.conf. That would allow users to disable compression or set/unset any other preferred Btrfs mount options without needing to perform a custom image build.

[codewithmichael]

I updated the Wren GUI project with some alternate wording on the labels and added an extra section to display "Uncompressed active data (if saved to disk)". That should suffice for now. If we go forward with Btrfs I'll release that as a follow up (since there are no other pending issues on Wren GUI at the moment).

[codewithmichael]

I added Btrfs compression (lzo) and moved the active volume mount options into platform.conf.

[codewithmichael]

Rebased for v0.1.2.

[codewithmichael]

This PR is already changing almost every file and requires testing every system, so I'm going to go ahead and add in issue #8 (Move to /opt/wren), as it only requires changing default_prefix=/etc to default_prefix=/opt in wrender (thanks to PR #19).

So noted in the PR's "Addressed Issues".

[codewithmichael]

In a fairly sweeping change to accommodate #8 (Move to /opt/wren), I've reorganized most of the source tree and updated setlist to copy installed package files into a more standard hierarchical tree — i.e. bin for executables, lib for libraries, and etc for configuration files. I left the tools directory separate, as those utilities aren't truly part of Wren as much as they're just quick ways to accomplish non-wren tasks.

[codewithmichael]

I updated initramfs-script to use getDiskUsage instead of getFileSize when determining the size of the save file. This addresses issue #22 (Incorrect active data capacity at startup).

To accomplish this, I also updated initramfs-hooks to copy_exec du in place of stat, since getDiskUsage uses du and there were no other references to stat or getFileSize in initramfs-script.

Note: save.sh already correctly used getDiskUsage to determine calculation sizes.

[codewithmichael]

I removed increase-save-size.sh script and made the active volume increase native to the wren control script. I added additional functionality to allow a specified number of bytes to increase by, to check whether the increase is necessary, and to determine if there is enough free memory to safely expand. There is a --force override option for when the action is not considered "safe".

Examples - Check:

user@computer:~$ sudo wren +active --check
Necessary:  No
Safe:       Yes

user@computer:~$ sudo wren +active --check -v
Resize Tolerance:     512.0M (536870912)
Active Free:          780.2M (818167808)
Memory Free:            2.5G (2778513408)
Memory Unallocated:     1.8G (1960345600)
Requested Increase:     1.0G (1073741824)
Necessary:                No
Safe:                    Yes

Example - Increase by 512MB:

user@computer:~$ sudo wren +active $((1024*1024*512)) -v
Resize Tolerance:     512.0M (536870912)
Active Free:            1.2G (1354698752)
Memory Free:            2.4G (2645508096)
Memory Unallocated:     1.2G (1290809344)
Requested Increase:   512.0M (536870912)
Necessary:                No
Safe:                    Yes
Increasing active storage capacity

[codewithmichael]

I added a crontab (/copy/config/cron/increase-active-capacity --> /etc/cron.d/increase-active-capacity) to check the active volume size and available memory every 30 seconds and increase the active capacity when "necessary" and "safe".

Technically, two entries were created to run once per minute. The second one is prefixed with a sleep 30 command to delay it.

This change addresses issue #23 (Cron job to increase active data capacity).

[codewithmichael]

All important issues seem to have been addressed and everything has tested well so far. I think this is ready to go.

[codewithmichael]

Merged into release-0.2.0 branch for testing.

[codewithmichael]

I'm thinking the wren control script should also have basic memory and usage stats in the status command like it does for the +active one. Since this has been merged, though, I'll open a new pull request based on the release-0.2.0 branch.