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


_______________________________________________
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Reply via email to