On Thu, 9 May 2024 at 18:27, Phil Stracchino <ph...@caerllewys.net> wrote:
> On 5/9/24 12:10, Marcin Haba wrote: > > In this algorithm it does not matter if hardlinks exist or not because > > examined are all file records. It is because to know if hardlink is used > > or not for a file, Bacula has to decode Bacula LStat string for this > > file from the File table. And for many files it takes time. > > No, no — wrong problem, I think. It does not appear to be examining the > file LSTATs that's taking the time here. Once the query actually > completes, that part goes very quickly. What is taking so long is the > query that builds the file list. It performs extremely poorly. > Hello Phil, OK. I was thinking about step after, where files are selected and restore is starting. For 263 files this slowness can not be too visible. For restoring a larger set of files, it is. For the building file list, there is used .bvfs_update command that builds Bvfs cache in the following way: .bvfs_update jobid=XXX,YYY,ZZZ where XXX, YYY and ZZZ are jobids that are needed for list files for restore. This building Bvfs cache can be done independently on BAT. One from practice is to run it after a backup job in Runscript. This way the Bvfs cache is already built before the restore process is started. Best regards, Marcin Haba (gani) -- "Greater love hath no man than this, that a man lay down his life for his friends." Jesus Christ "Większej miłości nikt nie ma nad tę, jak gdy kto życie swoje kładzie za przyjaciół swoich." Jezus Chrystus
_______________________________________________ Bacula-devel mailing list Bacula-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bacula-devel
