Erik said:
Anyone know why copying big (hundreds of Gb) files (to/from other machines
or from USB discs) stuffs W7 (64 bit) networking in such a way that other w7
machines can still access files but XP machines cannot, until it is
rebooted? The XP machines can ping the w7 machine, but cannot access any
files or the SQL server.
And why it seems to be impossible to set up a USB disc to allow copying of
these big (.tib backup files) on to it, just giving access permission errors
unless I set it to copy to a subdirectory rather than the main directory.
Then a strange error "The Semaphore Timeout Period Has Expired" prangs the
copying.
Should I just return to XP? It does all of the above without a whimper.
Erik Wilson.
Out of curiosity, have you tried reading the .tib files from end to end ?
What I'd do is:
1) Set up Performance Monitor (Start : perfmon.msc)
Add a performance counter from PhysicalDisc for disk read bytes/sec.
(You right click in the graph pane, to do an "Add Counter".)
Set the scale to 20000 (for recording read rates up to 200MB/sec)
http://digital.natinst.com/public.nsf/$CXIV/ATTACH-AEEE-7W6B49/$FILE/perfmon.JPG
2) Use a utility that will read the file for you. A utility like fciv
from Microsoft could do that. That is a program that computes a checksum,
but in this case, it'll be a means of doing a "read" of the file for
test purposes.
http://support.microsoft.com/kb/841290
In command prompt:
fciv C:\mydir\mybigtib.tib
Then, as it runs, watch the Performance Monitor. If the file is fragmented, you
might see the occasional dip in performance. But, if you see the read bytes/sec
drop to zero for a fifteen second period or longer, there could be a problem
with the hard drive itself.
The idea of doing this test, is to prove the "semaphore" error is not caused
by a non-responsive disk. You're proving the disk is readable, without
exceptionally long delays, between sectors.
If that sounds like too much work, you could also try HDTune and do a bad block
scan. But that's a less focused kind of test (it'll eventually test the
mybigtib.tib file, but it'll also cover parts of the disk you're not using).
And it doesn't provide quite the same level of feedback.
http://www.hdtune.com/files/hdtune_255.exe
*******
There is some evidence here, that a few people may have had some problem
with the file system or the disk. One person encountered problems with
doing a CHKDSK on the affected volume. That's why I'm suggesting a check
of the disk first.
http://social.technet.microsoft.com.../thread/c3fc9f5d-c073-4a9f-bb3d-b7bb8f893f78/
Note that, some of the problems with big disks now, are related to the
choice of 4KB internal sector size. Which can cause some funny looking
behavior, depending on alignment and size of requested transfer. That
just serves to complicate the things you see (you have a real problem,
plus the disk misbehaving due to sector size and alignment). I've seen
slowdowns on my newest disks, that I'm convinced are related to this
bad design choice. If you're going to change sector size, you should
have all the OSes patched to handle it properly, not screw around with
"emulation".
*******
I have noticed some strange behavior, even back in WinXP days. For example,
writing files larger than 100GB on an NTFS partition on my WinXP machine,
I can notice the CPU cycles used, gradually increasing as the operation proceeded.
When doing video capture (uncompressed data from WinTV card), whatever was
interfering with CPU usage got bad enough, I was actually dropping frames
during capture. So even WinXP is not fault-less, when it comes to design.
I have a feeling, some memory structure was "sloshing around", while that
transfer was taking place. I never got to the bottom of it. My workaround,
was to limit a single WinTV session, to no longer than one hour on my WinXP
machine. A two hour session, would capture around 136GB of data.
Paul
