Re: [Bacula-users] Error running bacula-sd 9.2.2 on a Zyxel NSA310 [SOLVED]
On 3/4/2019 10:11 AM, Josh Fisher wrote: ... The fix should be either compiling Bacula with the correct headers or else file a bug report with Zyxel. Or to use plain accept() and call fcntl() with CLOEXEC. As I understand it, there can be a race condition if you fire off your pre-(post-?)job script from a separate thread, that's the only difference between that and accept4(). Whatever problem is being avoided by using accept4() on linux 2.6.32+, is presumably still alive and well on every other supported platform? Dima ___ Bacula-users mailing list Bacula-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bacula-users
Re: [Bacula-users] Error running bacula-sd 9.2.2 on a Zyxel NSA310 [SOLVED]
On 3/4/2019 10:00 AM, Martin Simmons wrote:
I think the problem is that accept4 might be defined in libc, but not
implemented in the kernel. Hence it will be detected by configure but will
fail at run time.
The code could be improved by calling accept if accept4 fails at run time,
i.e. something like
Yes, it is defined in sys/socket.h header but is not actually
implemented by Zyxel's firmware. However, Bacula does not need to be
fixed, because Bacula's code uses accept4() in an absolutely correct
manner. This is either a Zyxel firmware bug or whoever compiled (or
corss-compiled?) Bacula for the platform used the wrong headers. So, I
disagree with a Bacula workaround. The fix should be either compiling
Bacula with the correct headers or else file a bug report with Zyxel.
#ifdef HAVE_ACCEPT4
fd = accept4(sockfd, addr, addrlen, SOCK_CLOEXEC);
if (fd >= 0 || errno != ENOSYS) {
return fd;
}
/* fallback to using accept upon ENOSYS */
#endif /* HAVE_ACCEPT4 */
fd = accept(sockfd, addr, addrlen);
__Martin
On Fri, 1 Mar 2019 17:14:02 +0100, Kern Sibbald said:
Were you careful to run a ./configure ... on the machine you then did
the make on? If Bacula picked up an old Linux created
/src/config.h file that could explain the accept4 error.
In any case, I would make sure that your /src/config.h file does
not contain a line that reads:
#define HAVE_ACCEPT4 1
If it does, then comment that line out (// at the beginning of the line
or simply deleting the line).
Then the build should work.
On 3/1/19 3:14 PM, Andrea Venturoli wrote:
On 3/1/19 12:34 PM, Kern Sibbald wrote:
At this point, my best assessment is that there is a bug in the Zyxel
libraries.
Just to clarify who's NOT to blame: to compile on a Zyxel NAS I had to
install several third party packages (FFP to begin with); so the
problem might lie in those third party, additional, unofficial packages.
bye & Thanks
av.
___
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
___
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
[Bacula-users] Fielock during backup with Bacula
In a Linux server (Centos 7), would the volumes need to be un-mounted to back them up with Bacula? I am looking for a solution that would allow me to back up while the server is working without disturbing any activities that may be ongoing. We run web applications, databases, cron jobs, etc in our server. Thank you. ___ Bacula-users mailing list Bacula-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bacula-users
Re: [Bacula-users] Bacula release 9.4.2 dpkg packet
Debian packages for Bacula 9.4.2 are available since few weeks already. Best regards Davide On Mon, 4 Mar 2019 at 08:43, Petar Kozic wrote: > Hi folks, > can we expect dpkg packets for Debian like OS ? > > Thank you. > > ___ > 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
Re: [Bacula-users] Error running bacula-sd 9.2.2 on a Zyxel NSA310 [SOLVED]
I think the problem is that accept4 might be defined in libc, but not
implemented in the kernel. Hence it will be detected by configure but will
fail at run time.
The code could be improved by calling accept if accept4 fails at run time,
i.e. something like
#ifdef HAVE_ACCEPT4
fd = accept4(sockfd, addr, addrlen, SOCK_CLOEXEC);
if (fd >= 0 || errno != ENOSYS) {
return fd;
}
/* fallback to using accept upon ENOSYS */
#endif /* HAVE_ACCEPT4 */
fd = accept(sockfd, addr, addrlen);
__Martin
> On Fri, 1 Mar 2019 17:14:02 +0100, Kern Sibbald said:
>
> Were you careful to run a ./configure ... on the machine you then did
> the make on? If Bacula picked up an old Linux created
> /src/config.h file that could explain the accept4 error.
>
> In any case, I would make sure that your /src/config.h file does
> not contain a line that reads:
>
> #define HAVE_ACCEPT4 1
>
> If it does, then comment that line out (// at the beginning of the line
> or simply deleting the line).
>
> Then the build should work.
>
> On 3/1/19 3:14 PM, Andrea Venturoli wrote:
> > On 3/1/19 12:34 PM, Kern Sibbald wrote:
> >
> >> At this point, my best assessment is that there is a bug in the Zyxel
> >> libraries.
> >
> > Just to clarify who's NOT to blame: to compile on a Zyxel NAS I had to
> > install several third party packages (FFP to begin with); so the
> > problem might lie in those third party, additional, unofficial packages.
> >
> > bye & Thanks
> > av.
> >
> >
> > ___
> > 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
>
___
Bacula-users mailing list
Bacula-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bacula-users
Re: [Bacula-users] Bacula release 9.4.2 dpkg packet
Thank you very much ! On March 4, 2019 at 1:50:48 PM, Jose Alberto (j.se...@gmail.com) wrote: Bacula 9.4.2 Debian 9. But, you put repository stretch-backport https://packages.debian.org/stretch-backports/bacula-server On Mon, Mar 4, 2019 at 3:42 AM Petar Kozic wrote: > Hi folks, > can we expect dpkg packets for Debian like OS ? > > Thank you. > > ___ > Bacula-users mailing list > Bacula-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/bacula-users > -- # # Sistema Operativo: Debian # #Caracas, Venezuela # # ___ Bacula-users mailing list Bacula-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bacula-users
Re: [Bacula-users] Windows backup much slower than Linux backup
On 3/3/2019 12:52 PM, Peter Milesson wrote: Hi folks, I did some testing during the weekend. * When backing up a huge file (> 10GB), the Windows transfer rate is comparable to the Linux transfer rate (32 Mb/s). Yes. This is why I suspect the problem lies in NTFS, not in network transfer. I also suspect that it lies in directory traversal and/or in opening a file for reading. The actual reading of an already open file and network send seem to be fine, as shown by the normal speeds seen with large files. My first thought is that Windows' complex ACLs, due to inheritance, maintaining audit metadata, and maintaining "short names" for each file and directory, make directory traversal and file opening quite slow, as compared to, for example, ext4. This is evidenced by the inclusion of robocopy in (most?) Windows versions. Robocopy is a CLI utility for copying larger numbers of files much more quickly than Windows Explorer. Robocopy is multi-threaded when using the /MT flag, and when running robocopy in multi-threaded mode it is dramatically faster at copying small files. This speed up is almost certainly due to concurrent ACL checks and directory traversal, rather than buffering, read-ahead, or anything to do with actual data transfer. For this reason, I believe that the only way to dramatically improve backup speeds in Windows is to multi-thread bacula-fd. Granted, that is not an easy fix. * Setting the file daemon buffer to 32k on the Windows server seemed to help, but not very much. I saw a decent improvement with older Windows clients (Windows 7). It might not apply to server versions or Windows 10. * The Windows backup transfer rate is still a lot slower than expected (22 Mb/s) for a full backup of 270 GB (298000 files), whereas the Linux backup is 35 Mb/s for a full backup of 783 GB (461500 files). The next thing I'm going to try is moving all overhead off of the Windows server. It will take a while to move things around, as I need to get a new server for this. Best regards, Peter On 01.03.2019 17:27, Peter Milesson wrote: Hi Josh, With the current settings, last access updates where disabled for Windows, and neither ATIME nor NOATIME for the Linux server. So in the current setup, the Linux server was at a disadvantage. I changed the network buffer to 32k on the Windows server, and I'll be wiser tomorrow, if it helped. Thanks for the advice. Best regards, Peter Dne 01.03.2019 v 16:40 Josh Fisher napsal(a): I also attribute this to Windows inefficiencies, particularly in NTFS handling of small files.However, I am not sure that those inefficiencies explain a greater than 50% performance hit. Two quick changes come to mind that may help. 1. Change MaximumNetworkBufferSize to 32k in bacula-fd.conf. Windows has been known to dislike the default 64k network buffer size. 2. Set the DWORD value NtfsDisableLastAccessUpdate in HKLM/system/CurrentControlSet/Control/FileSystem to nonzero to prevent a write to the disk each time a file is accessed. It is the NTFS equivalent of the NOATIME option used in ext4 and other Linux filesystems. For Windows file servers holding lots and lots of small files, those last access updates add up to quite a lot of disk activity. Generally, last access time is not needed or all that useful. In particular, if NOATIME is being used on the Linux client and NtfsDisableLastAccessUpdate = 0 on the Windows client, then you are not comparing apples to apples. On 3/1/2019 6:48 AM, Kern Sibbald wrote: Hello, I have noticed similar things. I have always attributed the slower speed on Windows due to the fact that Microsoft hired the best students from the best schools but most of them knew nothing about programming and programming history (in particular Unix), thus these geniuses re-invented the OS wheel in designing and building a monolithic operating system that took about 10 times as much code as it took Unix (and subsequently Linux). To me it is not surprising that Windows had more bugs than Linux (despite huge advances, it probably still has more bugs). In any case, programming Windows for a Linux programmer is a nightmare -- 10 times harder to do almost anything, because there are far more OS calls; they all have different arguments; many of which are not well or not at all document, ... So, I have just attributed this to being normal Windows inefficiencies. Of course, the above is sort of a gut feeling. Perhaps someone can do some real performance testing and figure out what is really going on. Best regards, Kern On 2/28/19 8:22 PM, Peter Milesson wrote: Hi folks, I'm backing up 2 servers with Bacula, one with Windows 2016, the other one with CentOS. The hardware is described below. The Windows server is much more powerful than the Linux server in all respects, and should theoretically deliver data to the Bacula server at a much higher rate. But in reality, the
Re: [Bacula-users] Bacula release 9.4.2 dpkg packet
Bacula 9.4.2 Debian 9. But, you put repository stretch-backport https://packages.debian.org/stretch-backports/bacula-server On Mon, Mar 4, 2019 at 3:42 AM Petar Kozic wrote: > Hi folks, > can we expect dpkg packets for Debian like OS ? > > Thank you. > > ___ > Bacula-users mailing list > Bacula-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/bacula-users > -- # # Sistema Operativo: Debian # #Caracas, Venezuela # # ___ Bacula-users mailing list Bacula-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bacula-users
Re: [Bacula-users] [Bacula-devel] Bacula release 9.4.2
abort() is not portable -- it behaves differently on different systems.
A segfault is portable, so we use have used it for 20 years now, and it
works fine. Use abort() at your own risk.
On 3/4/19 8:35 AM, Gary R. Schmidt wrote:
> On 2019-03-01 23:00, Kern Sibbald wrote:
>> Hello,
>>
>> I am quite surprised that the static function did not take precedence.
>> In any case, I have changed the subroutine name to be bround(), and will
>> push it to the git rep this evening.
>>
>> Thanks for pointing this out,
>> Kern
>>
> I agree, it's strange that the "static" didn't hide it, but the G++
> developers often do strange things.
>
> Anyway, as threatened, here are my results building with the Solaris
> Developer Studio C++ compiler:
>
> Using Developer Studio 12.6.
>
> Firstly, the code compiles much more quietly than previously, the
> recent clean-up has certainly improved things.
>
> And the problem with "round()" did not happen...
>
> Sections are divided by lines of ='s.
>
> ==
> This warning is repeated for every file that includes src/config.h.
>
> Compiling attr.c
> /src/bacula/bacula-9.4.2/libtool --tag=CXX --mode=compile
> /opt/developerstudio12.6/bin/CC -c -I. -I.. -g -O -m64 attr.c
> libtool: compile: /opt/developerstudio12.6/bin/CC -c -I. -I.. -g -O
> -m64 attr.c -KPIC -DPIC -o .libs/attr.o
> "../config.h", line 1266: Warning (Anachronism): Attempt to redefine
> __restrict__ without using #undef.
> 1 Warning(s) detected.
>
> Examining the source, it is for a very old version of the Solaris C++
> compiler, I would suggest changing lines 1255-1266 in
> autoconf/config.h.in:
>
> $ diff -c original-bacula-9.4.2/autoconf/config.h.in
> bacula-9.4.2/autoconf/config.h.in
> *** original-bacula-9.4.2/autoconf/config.h.in Mon Mar 4 18:06:07 2019
> --- bacula-9.4.2/autoconf/config.h.in Mon Mar 4 18:11:18 2019
> ***
> *** 1255,1266
> nothing if this is not supported. Do not define if restrict is
> supported directly. */
> #undef restrict
> ! /* Work around a bug in Sun C++: it does not support _Restrict or
> __restrict__, even though the corresponding Sun C compiler ends
> up with
> "#define restrict _Restrict" or "#define restrict __restrict__"
> in the
> previous line. Perhaps some future version of Sun C++ will work
> with
> restrict; if so, hopefully it defines __RESTRICT like Sun C
> does. */
> ! #if defined __SUNPRO_CC && !defined __RESTRICT
> # define _Restrict
> # define __restrict__
> #endif
> --- 1255,1266
> nothing if this is not supported. Do not define if restrict is
> supported directly. */
> #undef restrict
> ! /* Work around a bug in old Sun C++: it does not support _Restrict or
> __restrict__, even though the corresponding Sun C compiler ends
> up with
> "#define restrict _Restrict" or "#define restrict __restrict__"
> in the
> previous line. Perhaps some future version of Sun C++ will work
> with
> restrict; if so, hopefully it defines __RESTRICT like Sun C
> does. */
> ! #if defined __SUNPRO_CC && __SUNPRO_CC < 0x5150
> # define _Restrict
> # define __restrict__
> #endif
>
> This behaviour probably changed in Sun C++ several versions ago, but
> the noise generated prior to the recent clean-up masked it.
>
> ==
>
> After applying the above change, things get a lot quieter!
>
> Subsequent warnings fall into two basic groups.
>
> ==
>
> Group 1:
>
> "../baconfig.h", line 64: Warning: Likely null pointer dereference
> (*(((char *)0)[0])): bRC_BXATTR BXATTR::serialize_xattr_stream
>
> This looks like old C code used to cause a segmentation violation when
> something has gone wrong.
> I wonder why "abort()" was/is not used?
>
> What happens if you replace the assignments like "tjcr[0] = 0;" with
> "abort();"
> The code compiles, but does it still do what is expected?? (Yes, I am
> sure that it does, and some of the lines are even documented with
> "generate segmentation violation" but just because I'm paranoid it
> doesn't mean they aren't out to get me!)
>
> There are three files affected:
> src/baconfig.h
> src/lib/lockmgr.c
> src/lib/message.c
>
> $ diff -c -r original-bacula-9.4.2/src/baconfig.h
> bacula-9.4.2/src/baconfig.h
> *** original-bacula-9.4.2/src/baconfig.h Tue Feb 5 03:47:31 2019
> --- bacula-9.4.2/src/baconfig.h Mon Mar 4 17:15:58 2019
> ***
> *** 61,67
> char *tjcr = NULL; \
> Emsg1(M_ERROR, 0, _("Failed ASSERT: %s\n"), #x); \
> Pmsg1(000, _("Failed ASSERT: %s\n"), #x); \
> ! tjcr[0] = 0; }
>
> #define ASSERT2(x,y) if (!(x)) { \
> set_assert_msg(__FILE__, __LINE__, y); \
> --- 61,67
> char *tjcr = NULL; \
> Emsg1(M_ERROR, 0, _("Failed ASSERT: %s\n"), #x); \
> Pmsg1(000, _("Failed ASSERT:
Re: [Bacula-users] Persistent device name for autochanger
Sorry if I have not followed this whole thread, but the command you want to do is: lsscsi -g The control device names are listed in the last column. The control device name is needed by mtx to actuate the autochanger. The control device name is also needed for some of the tape alert commands. When reading/writing the volumes the normal names in the second to last column are used. By the way, here I use the device names defined in /dev/tape/by-id/. Here mine look like: lrwxrwxrwx 1 root root 9 Feb 6 09:24 scsi-3500143801403cf21 -> ../../sg1 lrwxrwxrwx 1 root root 9 Feb 6 09:24 scsi-3500143801403cf22 -> ../../st0 lrwxrwxrwx 1 root root 10 Feb 6 09:24 scsi-3500143801403cf22-nst -> ../../nst0 I am pretty sure they are defined there by default -- my system is Ubuntu 18.04, but I am not 100% sure about it. Best regards, Kern On 3/3/19 3:37 PM, William Muriithi wrote: > Hi guys, > > On Centos 7 system and had a working tape storage system. Then I restarted > and the whole thing stopped working. > > I have just noticed that the autochanger changed from /dev/sg2 to /dev/sg3. > My initial thought was to use the device UUID, but this device don't seem to > use UUID. > > I thought I could use the alternate name that I pulled from lsscsi command, > but it looks like either the device driver or the script only want to use the > device with sg prefix on the name > > [root@eng-backup01 ~]# mtx -f /dev/sch0 status > /dev/sch0 is not an sg device, or old sg driver > [root@eng-backup01 ~]# > > So, how do you guys solve this problem so that it don't fall apart on every > restart? > > [root@eng-backup01 ~]# lsscsi -l > [0:2:0:0]diskDELL PERC H710P 3.13 /dev/sda > state=running queue_depth=256 scsi_level=6 type=0 device_blocked=0 > timeout=90 > [0:2:1:0]diskDELL PERC H710P 3.13 /dev/sdb > state=running queue_depth=256 scsi_level=6 type=0 device_blocked=0 > timeout=90 > [1:0:0:0]tapeIBM ULTRIUM-HH7 J4D1 /dev/st0 > state=running queue_depth=256 scsi_level=7 type=1 device_blocked=0 > timeout=900 > [1:0:0:1]mediumx QUANTUM UHDL 0094 /dev/sch0 > state=running queue_depth=256 scsi_level=3 type=8 device_blocked=0 timeout=0 > [root@eng-backup01 ~]# > > > Regards, > William > > ___ > 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
