Martin,
I think you are right. I repeated my first query, requesting just the lstat
field and the fields are not joined.
In fact, I think I may have introduced this error myself, because the lines
for the original query were originally printed 'wrapped', and I cleaned
them up in a text editor to put each query result on one line by
backspacing at the start of each wrapped line.
bacula=> SELECT lstat FROM file WHERE filename = 'A6A87E2D36FAE06E-Mike
W11-00-00.mrimg';
lstat
-----------------------------------------------------------------------
P0j TaAhK IHw B Pu Pw A MQ2A6aB BAA BiGwPA BmNcn/ BmB6gd BnQLI1 A A C
P0j TaAhK IHw B Pu Pw A MQ2A6aB BAA BiGwPA BmB6ge BmB6gd BmB6ge A A C
P0j TaAhK IHw B Pu Pw A MQ2A6aB BAA BiGwPA BnQXpa BmB6gd BnQLI1 A A C
Regards,
Robert Gerber
402-237-8692
r...@craeon.net
On Fri, Dec 13, 2024 at 6:02 AM Rob Gerber <r...@craeon.net> wrote:
> 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
