On 21.02.19 19:31, Yılmaz Bilgili via Bacula-users wrote:
> # service bacula-sd status
> ● bacula-sd.service - LSB: Start Bacula Storage daemon at boot time
> Loaded: loaded (/etc/init.d/bacula-sd; generated; vendor preset:
> enabled)
> Active: active (exited) since Thu 2019-02-21 10:17:45 +
On 21.02.19 01:09, Jose Alberto wrote:
> The Pool A where only Linux or Unix are stored. arrives cap 6TB to be
> FULL, this seems fine. But the Pool B where only WindowsServers is saved
> only gets to 2TB to get FULL what I see is not normal.
Maybe your Windows systems don't deliver the data fast
Hello List,
At the beginning everything was OK. I updated the system two days ago.
Packages below updated.
postfix:amd64 (3.1.8-0+deb9u1, 3.1.9-0+deb9u2), gnupg-agent:amd64
(2.1.18-8~deb9u3, 2.1.18-8~deb9u4), libxapian30:amd64 (1.4.3-2+deb9u2,
1.4.3-2+deb9u3), libsystemd0:amd64 (232-25+deb9u
On 2/21/19 6:35 AM, Josh Fisher wrote:
> I think I get it now. You are "advising" the OS to read ahead and cache
> several files before actually opening the first file. This allows the OS
> to work on caching some of the next files while bacula-fd is
> concurrently processing the current file. I
On 2/20/2019 11:19 AM, jes...@krogh.cc wrote:
Note that posix_fadvise() only affects caching and read-ahead at the OS
level. While the use of posix_fadvise() may indeed improve i/o
performance for particular use cases, it is not parallelism and does not
cause multiple user-space threads to be e
