[
https://issues.apache.org/jira/browse/IGNITE-29175?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Nikita Amelchev updated IGNITE-29175:
-------------------------------------
Description:
Partition files of a compressed cache group are sparse: each page keeps only
its compressed bytes,
the rest of the page is a hole.
When such a group is restored from a snapshot, every partition goes through two
passes:
- the file is copied as a dense file, so the holes turn into zeros on disk;
- the copy is read again page by page, and a hole is punched after each page
with a separate fallocate call.
On a store with many partitions this makes the restore much slower than
creating the same snapshot.
The copy can write only the compressed bytes of each page instead: the file
system leaves the rest
of the page unallocated, and the second pass is not needed.
was:
Partition files of a compressed cache group are sparse: each page keeps only
its compressed bytes,
the rest of the page is a hole.
When such a group is restored from a snapshot, every partition goes through two
passes:
- the file is copied as a dense file, so the holes turn into zeros on disk;
- the copy is read again page by page, and a hole is punched after each page
with a separate
fallocate call.
On a store with many partitions this makes the restore much slower than
creating the same snapshot.
The copy can write only the compressed bytes of each page instead: the file
system leaves the rest
of the page unallocated, and the second pass is not needed.
> Copy compressed snapshot partitions sparsely on restore instead of punching
> holes
> ---------------------------------------------------------------------------------
>
> Key: IGNITE-29175
> URL: https://issues.apache.org/jira/browse/IGNITE-29175
> Project: Ignite
> Issue Type: Improvement
> Reporter: Nikita Amelchev
> Assignee: Nikita Amelchev
> Priority: Major
>
> Partition files of a compressed cache group are sparse: each page keeps only
> its compressed bytes,
> the rest of the page is a hole.
>
> When such a group is restored from a snapshot, every partition goes through
> two passes:
> - the file is copied as a dense file, so the holes turn into zeros on disk;
> - the copy is read again page by page, and a hole is punched after each page
> with a separate fallocate call.
> On a store with many partitions this makes the restore much slower than
> creating the same snapshot.
>
> The copy can write only the compressed bytes of each page instead: the file
> system leaves the rest
> of the page unallocated, and the second pass is not needed.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
