From owner-freebsd-questions@FreeBSD.ORG Mon Apr 26 11:25:49 2004 Return-Path: Delivered-To: freebsd-questions@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8267016A4CF for ; Mon, 26 Apr 2004 11:25:49 -0700 (PDT) Received: from mail.seekingfire.com (coyote.seekingfire.com [24.72.10.212]) by mx1.FreeBSD.org (Postfix) with ESMTP id 23D5643D46 for ; Mon, 26 Apr 2004 11:25:49 -0700 (PDT) (envelope-from tillman@seekingfire.com) Received: by mail.seekingfire.com (Postfix, from userid 500) id 246E858A; Mon, 26 Apr 2004 12:25:48 -0600 (CST) Date: Mon, 26 Apr 2004 12:25:47 -0600 From: Tillman Hodgson To: FreeBSD-Questions Message-ID: <20040426182547.GF92049@seekingfire.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Habeas-SWE-1: winter into spring X-Habeas-SWE-2: brightly anticipated X-Habeas-SWE-3: like Habeas SWE (tm) X-Habeas-SWE-4: Copyright 2002 Habeas (tm) X-Habeas-SWE-5: Sender Warranted Email (SWE) (tm). The sender of this X-Habeas-SWE-6: email in exchange for a license for this Habeas X-Habeas-SWE-7: warrant mark warrants that this is a Habeas Compliant X-Habeas-SWE-8: Message (HCM) and not spam. Please report use of this X-Habeas-SWE-9: mark in spam to . X-GPG-Key-ID: 828AFC7B X-GPG-Fingerprint: 5584 14BA C9EB 1524 0E68 F543 0F0A 7FBC 828A FC7B X-GPG-Key: http://www.seekingfire.com/gpg_key.asc X-Urban-Legend: There is lots of hidden information in headers User-Agent: Mutt/1.5.6i Subject: NFS occassionally gives "permission" denied in the middle of a large transfer X-BeenThere: freebsd-questions@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: User questions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Apr 2004 18:25:49 -0000 Howdy folks, I run a -STABLE (Apr 15 at the moment) NFS file server named Athena on generic Intel hardware. It has a large number of disks, primarily SCSI though 2 are IDE, and has a variety of Vinum mirrors from which it exports filesystems. I also have a cariety of clients that mount exports from that server. They're a mix of -STABLE (on x86), -CURRENT (on x86 and saprc64), and NetBSD (sgimips and pmax platforms). I run a weekly cron job on all boxes to to backup to a central NFS-exported filesystem on Athena (/exports/backups, usually mounted as /nfs/backups). I typically use a script like this (example is from the host Caliban, which runs -CURRENT on sparc64): [root@caliban ~]# cat /usr/local/etc/periodic/weekly/110.backup #!/bin/sh ### Backup important directories to Athena ### (To restore do a 'gzcat file.dump.gz | restore -i -f -') mount /nfs/backups dump 0Lf - / | gzip > /nfs/backups/caliban/weekly/root.dump.gz dump 0Lf - /var | gzip > /nfs/backups/caliban/weekly/var.dump.gz dump 0Lf - /usr | gzip > /nfs/backups/caliban/weekly/usr.dump.gz umount /nfs/backups However, this has been failing sporadically with messages like: DUMP: 50.71% done, finished in 1:03 DUMP: 53.06% done, finished in 1:01 DUMP: 54.72% done, finished in 1:02 gzip: stdout: Permission denied DUMP: Broken pipe DUMP: The ENTIRE dump is aborted. I've confirmed that the scripts work correctly when run by hand (and most of the time when run from cron), that I'm not running out of disk space, and that I'm not running out of network I/O (Athena is Gigabit on the switch, all the other machines are 100Mbit). There shouldn't be any concurrent access (nothing else uses this filesystem, and each host gets it's own diretory tree) so locking shouldn't be an issue. The odd part is how it's sporadic, and when it does occur it's typically pretty far into what had been, until that point, a successful dump. Is this a known issue? Are there any workarounds for it? Am I doing something blindingly-obviously-wrong? ;-) - Tillman -- If enlightenment is not where you are standing, where will you look? - Zen saying