advanced sparse file support about borg HOT 9 OPEN

Just to keep a vague idea:

If the different layers in borg would communicate a bit more (like the compression method being flexibly given by upper layers and the decompression result being able to tell whether its result is data that needs to be written to disk or just a sparse hole that needs to be "seeked"), the adv. sparse file support could maybe be just a special kind of "compression/decompression".

sparse compression would just store: 2 type bytes for "sparse", 8 bytes length of hole
sparse decompression would result in: hole=True, hole length
other decompression would result in: hole=False, data

instead of a hole=X value, it could be also an entry in a more generally useful meta dict, see #765.

from borg.

Advanced sparse file support would also save some time for archive creation as it does not have to read all these zeros in the sparse wholes (simple sparse file support just reads them all).

from borg.

The less involved feature, not having to chunk-HMAC hole contents is handled in #1354

from borg.

@milkey-mouse bs just told me you have started on this. maybe first evaluate how much changes this needs - if it is a bigger change, it might be not applicable to 1.1-maint (and also might conflict with 1.2 goals).

from borg.

I wrote some C code to list holes in files here which could implement #1354. I can think of a backwards-compatible way of implementing it on the borg side by using the method described in #1354, but putting a list of hole locations in the chunk metadata (#934).

from borg.

considering that the new "fixed" chunker is much simpler than the "buzhash" chunker, it might be easy to add sparse file support there.

as the fixed chunker is better suited for block devices and raw disk files, that would be exactly the place where sparse support is most needed.

from borg.

I'll try to solve this for the fixed-blocksize chunker...

from borg.

Looks like this bounty is too low / too big in scope.

To have a more incremental approach, I created a new issue / new bounty with a more narrow scope:

#5565

So, guess that one will be solved soon and later we can continue with this bounty (after way more backing is added to this bounty).

from borg.

there was some more progress in #5620, limited to chunker and hasher. compression and storage not affected yet.

from borg.