4 GB file limit? (WAS gzip from ports vs gzip from system)

Norberto Meijome freebsd at meijome.net
Sun Jun 26 11:37:06 GMT 2005

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)


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?


More information about the freebsd-questions mailing list