Stacks appear in the archive window's right sidebar. To see them, click the stacks icon in the toolbar or choose ➤ ➤ .
To see the details of a stack, expand the stack in the sidebar or choose from its action menu. The action menu also has commands to verify the stack, delete it, and perform other maintenance.
The top of the pane shows the stack name, its type, and the details of its location, which will vary depending on its type. You can also edit its display name.
Just below the stack's type is a quick check of the container's readiness. If the stack container is immediately accessible, this will say "Ready". If the container is not mounted, not online, not reachable, or its authentication is invalid, the appropriate message will be displayed here.
Below the stack details are various settings that temper how often the stack gets updated. The threshold settings can delay or defer updating slices in a stack to avoid excessive data transfer.
Stacks are designed to be stored on remote services. Accessing those services can come at a cost. The "cost" can be as simple as time, as remote data transfer is often orders of magnitude slower then local hard disk access. But the cost is often actual money; cloud storage services may charge for data transfer (amount uploaded or downloaded) as well as the amount of data stored.
Stacks already minimize this by compressing all data and constructing absolute minimal change sets. But the amount of data transferred can be further reduced by limiting, or delaying, how often a stack slice get replaced as the archive changes.
That's where the threshold settings come into play. Each setting limits, or delays, when a slice gets copied. This results in a stack that isn't always completely up-to-date with the contents of the archive, but is intended to strike a balance between concurrency and frugal use of resources.
If there are no consequential costs associated with the transfer and storage of data in your stack container, you can ignore these settings.
Note that the threshold settings apply only to the automated cascade action.
The delay time period puts off uploading newly captured layers until they are at least this old.
In a typical configuration, QRecall captures items many times a day, often hourly. This results in a dozen or more layers every day, each capturing a small number of changes. Within a few days, these will get merged into a single "day" layer containing the aggregate set of changes that day.
Without the delay setting, the cascade action will first upload all of the individual layers captured that day, only to replace them again with the merged "day" layer a few days later.
Advantage: avoids initial copy of small layers
Disadvantage: recent changes don't get immediately added to the stack
The hold settings is the complement of the delay settings. Instead of delaying the upload of new layers, it delays the replacement of new layers.
A hold period sets the minimum amount of time that must elapse before a newly uploaded layer is replaced.
In a typical rolling merge, where hourly layers get merged into day, then week, then month layers, a 3 month hold would allow all of those hourly layers to get uploaded immediately, but then not replaced until they had been merged several times into a much more compact month layer.
Advantage: reduces transfers by skipping small, intermediate, merges
Disadvantage: stack occupies more space for a longer period of time
Use the hold setting when data transfer is more expensive than data storage.
Instead of using a time interval, the update setting considers the amount of data the replacement would save.
The update setting can be one of:
The always setting turns this threshold off and allows a slice to be replaced for any other reason.
A setting of saves at least … will only replace the slice if the replacement is expected to be some percentage smaller than the slice it's replacing in the stack.
The never setting blocks the replacement of all slices, indefinitely. (The cascade action will still copy new slices and replace incomplete slices.)
Advantage: considers the actual cost of replacing each slice
Disadvantage: slices may occupy more space than required, indefinitely