AFAICS, there is no evidence of uint32_t overflow here (the problem was just caused by %d treating the 32 bits as signed rather than unsigned).
The catalog seems to store the low 32 bits of the disk volume size in EndBlock and the high 32 bits in EndFile. __Martin >>>>> On Tue, 1 Jan 2019 02:13:09 +0100, Kern Sibbald said: > > Well the EndBlock should be the last Bacula block number that is > written. The default > block size for disk is 32K if I remember right so EndBlock *should* > overflow when > the byte size of the Volume is greater than 2 billion times 32K. > > I believe the EndBlock is never used in the Media record, except perhaps > for Cloud volumes, so most likely it has been incorrectly set. > > Best regards, > Kern > > On 12/31/18 9:56 PM, Phil Stracchino wrote: > > On 12/31/18 2:41 PM, Kern Sibbald wrote: > >> Thanks to Martin for the fix and to Phil for confirming it. I have > >> patched Bacula and pushed it to the repo. > >> > >> For the moment, EndBlock is 32 bits, maybe someone can explain why it > >> should overflow -- that seems like > >> a *very* big volume, but maybe it is time to make it 64 bits, but that > >> requires a DB change. > >> The next release, probably in the Spring, will require a DB upgrade so > >> if a 64 bit EndBlock > >> is really needed it will be a good time to do it. > > > > I was pretty surprised that it was overflowing too. The actual disk > > volume starts overflowing EndBlock at about 32GB file size. The same > > size file has no issues in 9.2.x. > > > > Could some change in 9.4.x have unexpectedly affected what Bacula thinks > > the block size of a disk volume is? > > > > > > > > _______________________________________________ > Bacula-devel mailing list > Bacula-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/bacula-devel > _______________________________________________ Bacula-devel mailing list Bacula-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bacula-devel
