It is only a recent problem because the code was added (to Bacula Community at least) in November by rev bd0ea88fdd79dfdf4e013dcc9a7195425cd72723.
__Martin >>>>> On Sat, 19 Jan 2019 11:42:56 +0100, Kern Sibbald said: > > Oh. I just got back from "vacation", and haven't looked at this yet. What > you write sounds very plausible. However, I am wondering why this > problem (%d) shows up only now and not some time ago. > > Kern > > On 1/2/19 3:04 PM, Martin Simmons wrote: > > 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
