Re: [Bacula-users] Win32 FD / Write error sending N bytes to Storage daemon
2011-06-13 02:24:09
I forgot to mention that during my debugging, I did have "Heartbeat
Interval" set to 10 on the Client, Storage, and Director resources.
The same error still occurred... Very odd.
On 06/10/2011 07:02 PM, Blake Dunlap wrote:
$20 you have the other bacula comm channel failing due
to timeout of the state on a forwarding device. Dropping spool
sizes is only increasing the frequency of communication across
that path. You will likely see this problem solved completely by
setting a short duration keepalive in your bacula configs.
-Blake
On Fri, Jun 10, 2011 at 20:48, Mike Seda
<maseda AT stanford DOT edu>
wrote:
I just encountered a similar error in RHEL 6 using 5.0.3 (on
the server
and client) with Data Spooling enabled:
10-Jun 02:06 srv084 JobId 43: Error: bsock.c:393 Write error
sending
65536 bytes to Storage daemon:srv010.nowhere.us:9103:
ERR=Broken pipe
10-Jun 02:06 srv084 JobId 43: Fatal error: backup.c:1024
Network send
error to SD. ERR=Broken pipe
The way that I made it go away was to decrease "Maximum Spool
Size" from
200G to 2G. I also received the same error at 100G and 50G. I
ended up
just disabling data spooling completely on this box since
small spool
sizes almost defeat the point of spooling at all.
I've also been seeing some sporadic tape drive errors
recently, too. So
that may be part of the problem. I will be running the
vendor-suggested
diags on the library (Dell TL4000 with 2 x LTO-4 FC drives) in
the next
couple of days.
Plus, this is a temporary SD instance that I will eventually
migrate to
new hardware and add large/fast SAN disk to for spooling. This
should
explain the reason for the small spool size settings... This
box only
has a 2 x 300 GB drive SAS 10K RAID 1.
It'd be nice to see if anyone else has received this error on
a similar
HW/SW configuration.
Mike
On 06/07/2011 09:48 AM, Yann Cézard wrote:
> Le 07/06/2011 18:10, Josh Fisher a écrit :
>> Another problem I see with Windows 7 clients is
too aggressive power
>> management turning off the Ethernet interface
even though it is in use
>> by bacula-fd. Apparently there is some Windows
system call that a
>> service (daemon) must make to tell Windows not to
do power management
>> while it is busy. I don't know what versions of
Windows do that, other
>> than 7 and Vista, but it is a potential problem.
> There is no power management on our servers :-D
>
> I just ran some tests this afternoon, I create a new
bacula server
> with lenny / bacula 2.4.4, and downgrade the client
to 2.4.4, to
> be sure that all was fine with the same fileset, etc.
> The test was OK, no problem, the job ran fine.
> Than I tested again with our production server
(5.0.3) and
> the 2.4.4 client => network error, failed job
> I upgraded the test bacula server to squeeze / bacula
5.0.2,
> and still the 2.4.4 fd on the client => No
problem !
>
> So it seems that the problem is clearly in "network
hardware" on the
> server side.
>
> We will do some more tests on the network side
(change
> switch port, change wire, see if no firmware update
is available...),
> but now I really doubt that the problem is in bacula,
nor it can be
> resolved in it.
>
> The strange thing is that the problems are only
observed with win32
> clients. Perhaps the Windows (2003) TCP/IP stack is
less fault tolerant than
> the linux one in some very special case ?
>
> Regards,
>
|
------------------------------------------------------------------------------
EditLive Enterprise is the world's most technically advanced content
authoring tool. Experience the power of Track Changes, Inline Image
Editing and ensure content is compliant with Accessibility Checking.
http://p.sf.net/sfu/ephox-dev2dev _______________________________________________
Bacula-users mailing list
Bacula-users AT lists.sourceforge DOT net
https://lists.sourceforge.net/lists/listinfo/bacula-users
|
|
|