Date: Thu, 25 Jan 2001 13:27:08 -0800 From: Alfred Perlstein <bright@wintelcom.net> To: Nathan Parrish <ndparrish@yahoo.com> Cc: mjacob@feral.com, Dan Nelson <dnelson@emsphone.com>, current@FreeBSD.ORG, current-users@netbsd.org Subject: Re: > 4GB with NFS? Message-ID: <20010125132708.X26076@fw.wintelcom.net> In-Reply-To: <20010125211443.22025.qmail@web10405.mail.yahoo.com>; from ndparrish@yahoo.com on Thu, Jan 25, 2001 at 01:14:43PM -0800 References: <20010125211443.22025.qmail@web10405.mail.yahoo.com>
next in thread | previous in thread | raw e-mail | index | archive | help
* Nathan Parrish <ndparrish@yahoo.com> [010125 13:19] wrote: > knowing NFS in general far better than *BSD in specific, I would guess the best > thing to do (if you suspect server/client communication anomaly) is to grab a > snoop/tcpdump of the failure. I'm trying to think of a clever way to cause the > failure immediately, so you're not tracing 4GB of writes... mebbe dd's > seek/skip? or just append to the existing 4GB file. > > also, what command are you using on the bsd's to write the 4GB file? I've > definitely seen issues with VLF-capable OS's failing to write past 2/4GB due to > VLF-incapable utilities. (on a related note, is there a need for > vlfread()/vlfwrite() in the BSD's, or is VLF support native in the read/write > calls? It has to do with the vm system casting values into 32bit variables, it's been a long time since I looked at this, if I can find it again I might be able to do something about it. To answer your question about VLF (which I had to guess at) assuming you mean Very Large Files: 1) yes some tools break on them, I don't have a list handy. 2) BSD has had native VLF support since 4.4-BSD. (off_t is 64bit) -- -Alfred Perlstein - [bright@wintelcom.net|alfred@freebsd.org] "I have the heart of a child; I keep it in a jar on my desk." To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20010125132708.X26076>