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
_______________________________________________
[email protected] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
