From owner-freebsd-questions@FreeBSD.ORG Tue Jun 5 10:47:12 2007 Return-Path: X-Original-To: freebsd-questions@freebsd.org Delivered-To: freebsd-questions@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 9249616A421 for ; Tue, 5 Jun 2007 10:47:12 +0000 (UTC) (envelope-from xfb52@dial.pipex.com) Received: from smtp-out4.blueyonder.co.uk (smtp-out4.blueyonder.co.uk [195.188.213.7]) by mx1.freebsd.org (Postfix) with ESMTP id 2D8EE13C44B for ; Tue, 5 Jun 2007 10:47:12 +0000 (UTC) (envelope-from xfb52@dial.pipex.com) Received: from [172.23.170.140] (helo=anti-virus02-07) by smtp-out4.blueyonder.co.uk with smtp (Exim 4.52) id 1HvWZC-0002dp-V3; Tue, 05 Jun 2007 11:47:11 +0100 Received: from [62.31.10.181] (helo=[192.168.23.2]) by asmtp-out4.blueyonder.co.uk with esmtp (Exim 4.52) id 1HvWZ7-00041Y-BF; Tue, 05 Jun 2007 11:47:05 +0100 Message-ID: <46653F29.9030800@dial.pipex.com> Date: Tue, 05 Jun 2007 11:47:05 +0100 From: Alex Zbyslaw User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-GB; rv:1.7.13) Gecko/20061205 X-Accept-Language: en MIME-Version: 1.0 To: Zbigniew Szalbot References: <4664392E.1030409@szalbot.homedns.org> In-Reply-To: <4664392E.1030409@szalbot.homedns.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-questions@freebsd.org Subject: Re: total system freeze - where to look for more information 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: Tue, 05 Jun 2007 10:47:12 -0000 Zbigniew Szalbot wrote: > It is possible that the freeze occured during dump operation which is > done to a network drive mounted via mount_smbfs option. One problem we've encountered with dumping to an SMBFS file system is virus checking on the Windows host causing all kinds of problems, but these (for us under 5.4) manifest as: timeouts (i.e dump stops, but it's piping to gzip so maybe that makes a difference). Inability to rename files. Operation times out and 30 seconds later the file *is* renamed. Haven't had an opportunity to try with NFS yet, but given that this is related to WIndows file system semantics, that probably wouldn't help. If your virus checker can be set to ignore the folder where you dump to, that might help. You could test by just turning any virus checker off for a while. Also, have you confirmed that you can create files at all on the samba share? I found dd to be the easiest test tool. e.g. dd if=/dev/zero of=/samba/file count=1000000 bs=64k and see if dd finishes correctly or not. Start with a small count and keep adding a 0 until bored :-) Also you can monitor file growth with say "clear; ls -lsak /samba; sleep 1" in your favourite shell loop. On a working samba folder I see smooth file growth, on a non-working it's obviously erratic until it times out. > In that case I will probably be much better of using another HD > physically connected to the box rather than shared network drive, > wouldn't I? Lack of free space could not have been the reason - the > network share can handle about 750GB of data so it must have been > temporary network error. Or just dump to a non-Windows machine :-) I have no problems using gzip/ssh to keep backups on a different host. NFS ought to be fine too. --Alex