Skip to content

Use of fallocate in restore to prevent extreme fragmentation of (large) files #2675

@mschmc

Description

@mschmc

Output of restic version

restic 0.9.6 (v0.9.6-148-gc03bc88b) compiled with go1.13.5 on linux/amd64
(Beta-Version needed because of problem to restore 'large files' in release-version.

What should restic do differently? Which functionality do you think we should add?

fallocate a file before restoring it's contents. At least optionally

What are you trying to do?

Get files with the least possible fragmentation and contiguously allocated space.

AFAIU: The current version creates the file as sparse and then restores the content "chunk by chunk" in essentially random order.
The resulting file is thus a) extremely fragmented and b) discontiguous.

For e.g.:
Yesterday i restored a 1.4TB VM-Image-File (Ploop with Ext4 inside).
Just mounting that restored-file needed 7 Minutes.
Then i rewrote said file: rsync -avP --preallocate restored-file new-file
Mounting that rewritten file now only takes 4 seconds as layout of the rewritten is "optimal".

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions