Gcc 13.3 reports:
In file included from image/main.c:41:
./image/metadump.h:47:1: warning: ‘extern’ is not at beginning of declaration [-Wold-style-declaration]
47 | const extern struct dump_version *current_version;
| ^~~~~
Signed-off-by: David Sterba <dsterba@suse.com>
The remaining part of restore functionality starting from
restore_metadump() has been factored out. Same incremental set of
changes so the diff is not clean.
Signed-off-by: David Sterba <dsterba@suse.com>
The functionality of create and restore is all in main.c, split the
create functionality first. This is not the cleaniest diff to do it, the
functions are entangled and the final result is from several compile and
edit cycles.
Signed-off-by: David Sterba <dsterba@suse.com>
When we sync the kernel we're going to pull in the fs.h dependency,
which defines BLOCK_SIZE/BLOCK_MASK. Avoid this conflict by renaming
the image definitions with the IMAGE_ prefix.
Signed-off-by: Josef Bacik <josef@toxicpanda.com>
Signed-off-by: David Sterba <dsterba@suse.com>
The original dump format only contains a magic member to verify the
format, this means if we want to introduce new on-disk format or change
certain size limit, we can only introduce new magic as version.
Introduce the framework to allow multiple magic numbers to co-exist for
further extensions.
Introduce the following members for each dump version.
- max_pending_size
The threshold size of a cluster. It's not a hard limit but a soft
one. One cluster can go larger than max_pending_size for one item, but
next item would go to the next cluster.
- magic_cpu
The magic number in CPU byte order.
- extra_sb_flags
If the super block of this restore needs extra super block flags like
BTRFS_SUPER_FLAG_METADUMP_V2.
For incoming data dump feature, we don't need any extra super block
flags.
This change also implies that all image dumps will use the same magic
for all clusters. No mixing is allowed, as we will use the first cluster
to determine the dump version.
Signed-off-by: Qu Wenruo <wqu@suse.com>
Signed-off-by: David Sterba <dsterba@suse.com>
