Re: [Bacula-users] 800, 000+ orphaned paths entries cannot be pruned when using bvfs

[Kern Sibbald]

Hello Radek, The code has been there since 2011.  I now have a patch that makes the error message very clear. Yes, I am aware how bvfs works and why the cache is there.  I was just surprised that the existence of the cache would disable a dbcheck function. As far as I can see, this is not a temporary situation. Note, in the community version some of the bvfs functions may not be implemented or may only be implemented simply because the catalog database schemas between the Enterprise version and the community version are different simply because I did not have the time to backport those changes because the backport would be very tricky.  I will remove these database differences in the next major release, and then the Community will have access to all these bvfs functions.   I haven't confirmed it, but from what I can see, the error message is to avoid having a search cache that is out of date with the actual state of the path table -- so the solution is to clear the path cache table, and the new message explains exactly how to do it. Best regards, Kern On 1/26/19 8:01 AM, Radosław Korzeniewski wrote: Hello Kern, pt., 25 sty 2019 o 17:06 Kern Sibbald <k...@sibbald.com> napisał(a): Hello, I find the error message very cryptic, and I really don't like just giving up, so I have asked the author of that particular code to supply a fix. From what I understand here bvfs is using a special cache tables (pathvisibility, pathhierarchy) for fast job files browsing. These cache tables have a references to 'path' and job tables but these references aren't guarded by a database constraints, so I call it a soft references (I assume it is for faster update and search).  bacula=# \d pathvisibility Table "public.pathvisibility"  Column |  Type   | Modifiers --------+---------+-----------  pathid | integer | not null  jobid  | integer | not null  size   | bigint  | default 0  files  | integer | default 0 Indexes:     "pathvisibility_pkey" PRIMARY KEY, btree (jobid, pathid)     "pathvisibility_jobid" btree (jobid) bacula=# \d pathhierarchy  Table "public.pathhierarchy"  Column  |  Type   | Modifiers ---------+---------+-----------  pathid  | integer | not null  ppathid | integer | not null Indexes:     "pathhierarchy_pkey" PRIMARY KEY, btree (pathid)     "pathhierarchy_ppathid" btree (ppathid) The dbcheck utility has no code to deal with bvfs cache tables, so when it finds these soft references it actually raise an error. I can imagine that this is a temporary solution. best regards   Best regards, Kern On 1/23/19 11:03 AM, Radosław Korzeniewski wrote: Hello, wt., 22 sty 2019 o 14:39 Stefan Muenkner <stefan.muenk...@uni-saarland.de> napisał(a): (...) Searching for hascache in the rest of the source I found that hascache in the job table seems to be only reset in ".bvfs_clear_cache". Great! >> .... >>       9) Check for orphaned Path records >> .... >> Select function number: 9 >> Pruning orphaned Path entries isn't possible when using BVFS. >> .... So, it seems the message above should be more descriptive and user friendly and points to bvfs_clear_cache command.  best regards -- Radosław Korzeniewski rados...@korzeniewski.net -- Radosław Korzeniewski rados...@korzeniewski.net

_______________________________________________
Bacula-users mailing list
Bacula-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bacula-users