From owner-freebsd-questions@FreeBSD.ORG Sun Jun 26 11:37:06 2005 Return-Path: X-Original-To: freebsd-questions@freebsd.org 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 1C5BB16A41C for ; Sun, 26 Jun 2005 11:37:06 +0000 (GMT) (envelope-from freebsd@meijome.net) Received: from sigma.octantis.com.au (sigma.octantis.com.au [207.44.188.23]) by mx1.FreeBSD.org (Postfix) with ESMTP id BDECE43D53 for ; Sun, 26 Jun 2005 11:37:05 +0000 (GMT) (envelope-from freebsd@meijome.net) Received: (qmail 13272 invoked from network); 26 Jun 2005 21:37:05 +1000 Received: from unknown (HELO ?192.168.13.3?) (202.59.110.3) by sigma.octantis.com.au with (DHE-RSA-AES256-SHA encrypted) SMTP; 26 Jun 2005 21:37:04 +1000 Message-ID: <42BE9359.8000401@meijome.net> Date: Sun, 26 Jun 2005 21:36:57 +1000 From: Norberto Meijome User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: freebsd-questions@freebsd.org References: <42BE3798.1020200@meijome.net> <20050626052603.GB9894@dan.emsphone.com> <42BE442C.9090502@meijome.net> <42BE4F33.6040101@meijome.net> <20050626070220.GA51206@dan.emsphone.com> In-Reply-To: <20050626070220.GA51206@dan.emsphone.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: 4 GB file limit? (WAS gzip from ports vs gzip from system) 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: Sun, 26 Jun 2005 11:37:06 -0000 to recap: dump | gzip > nfs_share_on_w2k_NAS_running_ServicesForUnix This works fine until the size of the file created on the nfs_share is just under 4 GB (originally thought 2 GB problem) Client : FBSD 4.11, cvsuped April 15th 05, world + kernel. Server : Win2K-Storage server, SP4, Microsoft Windows Services for UNIX 3.5 [8.0.1969.1] more below Dan Nelson wrote: >>Norberto Meijome wrote: >> >> DUMP: 66.60% done, finished in 1:32 >> >>gzip: stdout: File too large >> DUMP: Broken pipe >> DUMP: The ENTIRE dump is aborted. > > > That looks like whatever filesystem gzip was writing to couldn't handle > files over 2gb. You mentioned writing to a remote filesystem using > amd, but it defaults to NFSv3. Were you maybe writing to a FAT fs on > the remote end? You can also see whether amd actually mounted the > remote fs with NFSv2 by uncommenting the "/var/log/all.log" line in > /etc/syslog.con, touching /var/log/all.log, and restarting syslog. > Then have amd remount the remote system and check the log. > Hmm. ok, as suspected gzip v1.3.5 from ports fails as the other one. And the filesize it died on is 4,294,950,912 bytes . Just under 4 GB - 16K less than 4 GB. (back to system gzip of course :) ) The native FS on the NAS is NTFS, which doesnt have this kind of limitation , as per the following article from MS(may wrap) http://www.microsoft.com/resources/documentation/Windows/XP/all/reskit/en-us/Default.asp?url=/resources/documentation/Windows/XP/all/reskit/en-us/prkc_fil_tdrn.asp I just checked from the server itself with dd from SFU, can create a 5 GB file with no probs. dd if=/dev/zero of=/dev/fs/E/temp/test1 bs=4096 count=1310720 So i've stopped amd, bounced box clean, mounted the share via NFS3 mount_nfs -3 edsac:/diablo_backs/ /mnt/test1/ still running this next pass... any ideas what is breaking...and why? thanks!! Beto