Duplicati: use-block-cache does not work as expected; high SSD wear

[BrettDikeman]

Environment info

• Duplicati version: 2.0.4.5_beta_2018-11-28
• Operating system: OS X 10.12.3

Description

Enabling use-block-cache is expected, based on documentation, to not cause backup archives to be written to disk at any stage - compiling the archive, encrypting it, compressing it, etc before it is passed off to the storage backend. This is especially not expected in dry-run mode (I didn't expect dry-run mode to do anything beyond scanning to determine what files would be backed up, to be honest.)

At least in dry-run mode, this is not the case. If the drive is an SSD, this will cause extremely accelerated wear as Duplicati will write the entire backup to the SSD via temp files.

If this is not what use-block-cache is supposed to do: please update the documentation to clearly explain what the option does, and implement a feature whereby temporary files are not generated during a backup.

Steps to reproduce

1. Start a job with use-block-cache and dry-run mode enabled

Screenshots

Note write activity heavily mirroring read activity.

[ts678]

FYI here is a post I just did on what I think --use-block-cache does. Maybe someone will confirm or refute.

[BrettDikeman]

Correction: this is a bug in the web UI when utilizing the command line option.

When running a command line, certain options are ignored or not parsed correctly. When I edited my backup job and ran it from the main page, it ran as expected: the exclusion lists I specified were applied correctly and the block cache was used.

I'd been baffled as to why everything was taking so long and while my file count had exploded, and it finally dawned on me what was going on.

Should I close this and open a different bug, or edit the subject and bug report text?

[Pectojin]

As I'm reading this issue it's a combined feature request and possibly renaming request.
Would a solution be:

• Updating the documentation (#34)
• Renaming use-block-cache to use-block-table-cache
• Creating a use-volume-cache that stores the entire volume in memory when creating volumes to be uploaded

In the case that it is a solution, it may make sense to open a new issue for the feature request so it's more clear what implementation is desired.