2005-06-27 05:27:56 +02:00
|
|
|
#ifndef CSUM_FILE_H
|
|
|
|
#define CSUM_FILE_H
|
|
|
|
|
2018-08-15 19:54:05 +02:00
|
|
|
#include "hash.h"
|
|
|
|
|
2007-10-30 22:06:21 +01:00
|
|
|
struct progress;
|
|
|
|
|
2005-06-27 05:27:56 +02:00
|
|
|
/* A SHA1-protected file */
|
2018-02-01 03:18:46 +01:00
|
|
|
struct hashfile {
|
2007-11-05 04:54:50 +01:00
|
|
|
int fd;
|
2011-02-03 02:29:01 +01:00
|
|
|
int check_fd;
|
2007-11-05 04:54:50 +01:00
|
|
|
unsigned int offset;
|
2018-02-01 03:18:47 +01:00
|
|
|
git_hash_ctx ctx;
|
2007-11-05 04:15:41 +01:00
|
|
|
off_t total;
|
2007-10-30 22:06:21 +01:00
|
|
|
struct progress *tp;
|
2007-11-05 04:54:50 +01:00
|
|
|
const char *name;
|
compute a CRC32 for each object as stored in a pack
The most important optimization for performance when repacking is the
ability to reuse data from a previous pack as is and bypass any delta
or even SHA1 computation by simply copying the raw data from one pack
to another directly.
The problem with this is that any data corruption within a copied object
would go unnoticed and the new (repacked) pack would be self-consistent
with its own checksum despite containing a corrupted object. This is a
real issue that already happened at least once in the past.
In some attempt to prevent this, we validate the copied data by inflating
it and making sure no error is signaled by zlib. But this is still not
perfect as a significant portion of a pack content is made of object
headers and references to delta base objects which are not deflated and
therefore not validated when repacking actually making the pack data reuse
still not as safe as it could be.
Of course a full SHA1 validation could be performed, but that implies
full data inflating and delta replaying which is extremely costly, which
cost the data reuse optimization was designed to avoid in the first place.
So the best solution to this is simply to store a CRC32 of the raw pack
data for each object in the pack index. This way any object in a pack can
be validated before being copied as is in another pack, including header
and any other non deflated data.
Why CRC32 instead of a faster checksum like Adler32? Quoting Wikipedia:
Jonathan Stone discovered in 2001 that Adler-32 has a weakness for very
short messages. He wrote "Briefly, the problem is that, for very short
packets, Adler32 is guaranteed to give poor coverage of the available
bits. Don't take my word for it, ask Mark Adler. :-)" The problem is
that sum A does not wrap for short messages. The maximum value of A for
a 128-byte message is 32640, which is below the value 65521 used by the
modulo operation. An extended explanation can be found in RFC 3309,
which mandates the use of CRC32 instead of Adler-32 for SCTP, the
Stream Control Transmission Protocol.
In the context of a GIT pack, we have lots of small objects, especially
deltas, which are likely to be quite small and in a size range for which
Adler32 is dimed not to be sufficient. Another advantage of CRC32 is the
possibility for recovery from certain types of small corruptions like
single bit errors which are the most probable type of corruptions.
OK what this patch does is to compute the CRC32 of each object written to
a pack within pack-objects. It is not written to the index yet and it is
obviously not validated when reusing pack data yet either.
Signed-off-by: Nicolas Pitre <nico@cam.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-04-09 07:06:31 +02:00
|
|
|
int do_crc;
|
|
|
|
uint32_t crc32;
|
2005-06-27 05:27:56 +02:00
|
|
|
unsigned char buffer[8192];
|
|
|
|
};
|
|
|
|
|
2011-11-18 01:26:54 +01:00
|
|
|
/* Checkpoint */
|
2018-02-01 03:18:46 +01:00
|
|
|
struct hashfile_checkpoint {
|
2011-11-18 01:26:54 +01:00
|
|
|
off_t offset;
|
2018-02-01 03:18:47 +01:00
|
|
|
git_hash_ctx ctx;
|
2011-11-18 01:26:54 +01:00
|
|
|
};
|
|
|
|
|
2019-04-29 10:28:14 +02:00
|
|
|
void hashfile_checkpoint(struct hashfile *, struct hashfile_checkpoint *);
|
|
|
|
int hashfile_truncate(struct hashfile *, struct hashfile_checkpoint *);
|
2011-11-18 01:26:54 +01:00
|
|
|
|
2018-04-02 22:34:14 +02:00
|
|
|
/* finalize_hashfile flags */
|
2018-04-02 22:34:15 +02:00
|
|
|
#define CSUM_CLOSE 1
|
|
|
|
#define CSUM_FSYNC 2
|
|
|
|
#define CSUM_HASH_IN_STREAM 4
|
2008-05-30 17:42:16 +02:00
|
|
|
|
2019-04-29 10:28:14 +02:00
|
|
|
struct hashfile *hashfd(int fd, const char *name);
|
|
|
|
struct hashfile *hashfd_check(const char *name);
|
|
|
|
struct hashfile *hashfd_throughput(int fd, const char *name, struct progress *tp);
|
|
|
|
int finalize_hashfile(struct hashfile *, unsigned char *, unsigned int);
|
|
|
|
void hashwrite(struct hashfile *, const void *, unsigned int);
|
|
|
|
void hashflush(struct hashfile *f);
|
|
|
|
void crc32_begin(struct hashfile *);
|
|
|
|
uint32_t crc32_end(struct hashfile *);
|
2005-06-27 05:27:56 +02:00
|
|
|
|
2019-12-18 12:25:42 +01:00
|
|
|
/*
|
|
|
|
* Returns the total number of bytes fed to the hashfile so far (including ones
|
|
|
|
* that have not been written out to the descriptor yet).
|
|
|
|
*/
|
|
|
|
static inline off_t hashfile_total(struct hashfile *f)
|
|
|
|
{
|
|
|
|
return f->total + f->offset;
|
|
|
|
}
|
|
|
|
|
2018-02-01 03:18:46 +01:00
|
|
|
static inline void hashwrite_u8(struct hashfile *f, uint8_t data)
|
2014-11-27 06:24:01 +01:00
|
|
|
{
|
2018-02-01 03:18:46 +01:00
|
|
|
hashwrite(f, &data, sizeof(data));
|
2014-11-27 06:24:01 +01:00
|
|
|
}
|
|
|
|
|
2018-02-01 03:18:46 +01:00
|
|
|
static inline void hashwrite_be32(struct hashfile *f, uint32_t data)
|
2014-11-27 06:24:01 +01:00
|
|
|
{
|
|
|
|
data = htonl(data);
|
2018-02-01 03:18:46 +01:00
|
|
|
hashwrite(f, &data, sizeof(data));
|
2014-11-27 06:24:01 +01:00
|
|
|
}
|
|
|
|
|
2020-11-12 13:20:19 +01:00
|
|
|
static inline size_t hashwrite_be64(struct hashfile *f, uint64_t data)
|
|
|
|
{
|
|
|
|
data = htonll(data);
|
|
|
|
hashwrite(f, &data, sizeof(data));
|
|
|
|
return sizeof(data);
|
|
|
|
}
|
|
|
|
|
2005-06-27 05:27:56 +02:00
|
|
|
#endif
|