SEO

Hello All,

Out of pressure of time, I had to post a new topic, rather than
research through these threads, as I am assuming this issue has come up
before.

We have an hp-ux box, and on a windows server, running windows 2003
sp1, we have Windows services for unix 3.5 installed, and have
successfully mounted unix filesystems to that server. The problem is
that when a file is created on one of these unix shares, it takes a
long time for it to show up in windows. Im talking 20-30seconds. We are
trying to use this to process files, and 20-30 secs is way too long, we
are optimally looking for 0 seconds...

For example

On my hp box i have

/winshare

and on my windows 2003 server I have that /winshare folder mapped to
/unixshare

So if i copy file testfile1.txt to /winshare on my hpux box , then goto
\\windosnfsserver\unixshare

and look for that new file, it takes about 30 seconds, sometimes more.

Any one know of any way to increase this performance??

any help would be greatly appreciated!!

One theory I have is that, our HP ux box is not running NIS, and is
also running Samba as well as nfs server and client... and it is a
trusted system, so I am wondering if this factors into the equation...

thesoulcrusher <TheSoulCrusher@gmail.com> wrote:
> So if i copy file testfile1.txt to /winshare on my hpux box , then goto
> \\windosnfsserver\unixshare

> and look for that new file, it takes about 30 seconds, sometimes more.

Go to there how? IN an MS-DOS command prompt, or via a GUI? Perhaps
the "integration" between the unix services under Windows and the
"regular" file viewing windows isn't all that tight, and it is waiting
for a timeout?

One _possible_ way to test that hypothesis would be to create two
files, five seconds apart and see if they "appear" on the Windows box
at the same time.

> Any one know of any way to increase this performance??

Run HP-UX or Linux on the server?-)

The other thing to do to get an idea of what is going on is to take a
tcpdump trace of teh traffic between the two systems and see the
actual NFS traffic - make the trace verbose and with a "snaplen" of
1500 bytes to see everything to make sure you get a full set of NFS
headers. It may require wireshark instead to reassemble the NFS
request stream if things aren't starting nicely on TCP segment
boundaries (not a problem if the mount is UDP rather than TCP).

The idea would be to see if the NFS create reply comes-back "right
away" or not. I'm guessing it does, or the HP-UX client would remain
blocked, but best to cross the i's and dot the t's.

A final test would be to run a program on the Windows sytem which
tries to open the file (perhaps you've already done this) and see if
it can open the file programatically - that may be able to happen
before some GUI update timer.

> any help would be greatly appreciated!!

> One theory I have is that, our HP ux box is not running NIS, and is
> also running Samba as well as nfs server and client... and it is a
> trusted system, so I am wondering if this factors into the equation...

Unlikely. My initial suspicion would be "loose" integration of the
unix file services with the rest of windows.

Now, if the UX box is running Samba, you could just use that instead
of NFS. Or perhaps you can reverse the sense of things - have Windows
be an NFS client of the UX system acting as the NFS server.

rick jones
--
firebug n, the idiot who tosses a lit cigarette out his car window
these opinions are mine, all mine; HP might not want them anyway...
feel free to post, OR email to rick.jones2 in hp.com but NOT BOTH...