Everyone,
Thank you very much for all the help with this interesting problem and for
your advice.
Arno,
that query very quickly returned 443123 lines. Looking through them, some
were longer than others.
I wanted to count total entries for lstat, and they number around 2
million. So your query accounted for many of the entries.
bacula=> SELECT COUNT(lstat) AS lstat_count FROM file;
lstat_count
-------------
2090871
(1 row)
The lstat output is 34MB. I uploaded it to google drive in case it will be
useful to you, though I understand that without context from jobids or
something it will be of limited use to investigate further.
https://drive.google.com/file/d/1eM2w78jxlLeJGqnKNuE6Y2hY1AYhWYEa/view?usp=sharing
I happened to read your email when I briefly woke up, so I'm going to bed
again now.
Thank you all again for all the help!
Regards,
Robert Gerber
402-237-8692
r...@craeon.net
On Fri, Dec 13, 2024 at 3:24 AM Arno Lehmann via Bacula-users <
bacula-users@lists.sourceforge.net> wrote:
> Hi all,
>
> Am 13.12.2024 um 06:28 schrieb Marcin Haba:
> ...
> > Your notice about too long mtime is fully right. It is because the
> > lstat string is broken. Two lstat values are joined together and it
> > causes this wrong result. If we split them, then the decoded values
> > are more realistic and the number of single values is correct in
> > lstat:
>
> I wonder how we can end up with such lstat data. There must be a reason,
> and I'm quite sure I have never seen such a situation (which doesn't
> prove anything). The fact that the encoded time stamps are out of bounds
> for most current libc implementations, but the time stamp comparison
> obviously worked, just incorrectly, will at least avoid problems due to
> files not being backed up.
>
> Can you check if similar situations exist using a catalog query such as
>
> select jobid,length(lstat),lstat from file where length(lstat)>59;
>
> so we can see if this is a problem happening more often? It's going to
> be a long running query as it'll cause a full table scan, I think... at
> least here I have it running for a few minutes now.
>
> Sanity checking I tried here:
>
> $ date -d @6952011706864740382
> date: time ‘6952011706864740382’ is out of range
>
> One thing that might be interesting could be to see if you can identify
> files the two concatenated lstats actually belong to. Perhaps we can
> find a non-obvious pattern.
>
> Cheers,
>
> Arno
>
> --
> Arno Lehmann
>
> IT-Service Lehmann
> Sandstr. 6, 49080 Osnabrück
>
>
>
> _______________________________________________
> Bacula-users mailing list
> Bacula-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bacula-users
>
_______________________________________________
Bacula-users mailing list
Bacula-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bacula-users
