From owner-freebsd-questions@FreeBSD.ORG Fri Aug 10 08:02:45 2007 Return-Path: Delivered-To: freebsd-questions@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5182D16A41A for ; Fri, 10 Aug 2007 08:02:45 +0000 (UTC) (envelope-from nvass@teledomenet.gr) Received: from smtp.teledomenet.gr (smtp.teledomenet.gr [213.142.128.2]) by mx1.freebsd.org (Postfix) with ESMTP id 084E013C46B for ; Fri, 10 Aug 2007 08:02:44 +0000 (UTC) (envelope-from nvass@teledomenet.gr) Received: from iris (unknown [192.168.1.71]) by smtp.teledomenet.gr (Postfix) with ESMTP id 00EC3143AAA; Fri, 10 Aug 2007 11:02:43 +0300 (EEST) From: Nikos Vassiliadis To: Bram Schoenmakers Date: Fri, 10 Aug 2007 11:03:06 +0300 User-Agent: KMail/1.9.1 References: <200708091025.43912.bramschoenmakers@xs4all.nl> <46BB2730.8090702@dial.pipex.com> <200708091851.14649.bramschoenmakers@xs4all.nl> In-Reply-To: <200708091851.14649.bramschoenmakers@xs4all.nl> X-NCC-RegID: gr.telehouse MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200708101103.07024.nvass@teledomenet.gr> Cc: freebsd-questions@freebsd.org, Alex Zbyslaw Subject: Re: Problem with dump over SSH: Operation timed out X-BeenThere: freebsd-questions@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: User questions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Aug 2007 08:02:45 -0000 On Thursday 09 August 2007 19:51, Bram Schoenmakers wrote: > Op donderdag 09 augustus 2007, schreef Alex Zbyslaw: > > Hello, > > > Bram Schoenmakers wrote: > > ># /sbin/dump -0uan -L -h 0 -f - / | /usr/bin/bzip2 | /usr/bin/ssh > > >backup@office.example.com \ > > > dd of=/backup/webserver/root.0.bz2 > > > > bzip2 is darned slow and not always much better than gzip -9. It > > might be that ssh is just timing out in some way (I've seen that but > > not with ethernet dumps specifically). Can you try the test using > > gzip -9 instead of bzip? If that works, then look for ssh options > > that affect timeouts, keepalives etc. In particular, > > ServerAliveInterval 60 in a .ssh/config stopped xterm windows dying on > > me to certain hosts. YMMV :-( > > > > If you have the disk space then you could try without any compression > > at all; or try doing the compression remotely: > > > > /sbin/dump -0 -a -C 64 -L -h 0 -f - / | \ > > /usr/local/bin/ssh backup@office.example.com > > \ > > "gzip -9 > /backup/webserver/root.0.gz" > > > > Otherwise: > > > > Nikos Vassiliadis wrote: > > >1) Can you dump the file locally? > > > > > >2) Is scp working? > > > > If you can write (and compress if short of disk space) the dump > > locally and try an scp to your remote host as Nikos is suggesting, > > that will narrow down the problem a bit. Any other large file will > > do: doesn't have to be a dump. > > As I wrote in my initial mail: > > ====== > * Downloading the very same big file over SCP causes problems too, below > some SCP debug output. The connection drops quickly after it gained a > reasonable download speed. This really looks like a broken PMTU discovery. Is this still the case? After the firewall changes you did? Things may be different now. But, if a router in the path is filtering all ICMP traffic then the problem will remain. Try this on both hosts: sysctl net.inet.tcp.path_mtu_discovery=0 sysctl net.inet.tcp.mssdflt=1000 (just to be safe, the default on 4.x is 1400, which can be big on 6.x is just 512) Please, just use scp to do your testing. When you rule out the possibility of a problematic network, you will add the (gzip|bzip2) & dump parts. Nikos