darkness

Client (ordeith):

• Fedora Core 5 x86-64
• Kernel 2.6.17-1.2157_FC5
• VMwareWorkstation-5.5.1-19175, with update 101 (from that weird .cz site) applied
• XP SP2 (32-bit), up to date, running in VMware

Server (verin):

• Fedora Core 5 i386 (though running on an Intel P4 with EM64T)
• Kernel 2.6.17-1.2157_FC5smp
• samba-3.0.23a-1.fc5.1.codefu.1 (patch to fix Samba bug #4003, I believe)

Client is an nForce 4 chipset using forcedeth for its NIC talking to the server. Server is an Intel 1000MT or something like that. These two NICs are crossed over to each other, and bridged to other NICs that go to my 10/100 switch. Spanning tree causes client to send all of its traffic through the server under normal circumstances. All this bridging trickery is to give me gigabit speed between the only two machines on my network that support gigabit (the client and the server in this entry), but to allow things to continue to work if I pull that cable and temporarily connect it to another PC that supports gigabit (like my laptop). VMware had no problem doing bridged networking to lanbr0. (Or is it host networking? If bridged networking works, that’s what I’m using. I’m pretty sure it’s bridged.)

Problem: I start Soulseek. I start downloading, say, two files at reasonable speeds (30-150KB/s each). These files are being downloaded to my Z: drive, which is on my Samba server. Within 5 minutes I begin getting errors like the following:

Event Type: Information
Event Source:   Application Popup
Event Category: None
Event ID:   26
Date:       8/13/2006
Time:       2:02:24 AM
User:       N/A
Computer:   ORDEITH
Description:
Application popup: Windows - Delayed Write Failed : Windows was unable
to save all the data for the file
\Device\WinDfs\Z:000000000000e6dd\verin\darkness\01-destro-is-part-of-cobra.mp3.
The data has been lost. This error may be caused by a failure of your
computer hardware or network connection. Please try to save this file
elsewhere.


Event Type:     Warning
Event Source:   Mup
Event Category: None
Event ID:       50
Date:           8/13/2006
Time:           2:02:24 AM
User:           N/A
Computer:       ORDEITH
Description:
The description for Event ID ( 50 ) in Source ( Mup ) cannot be
found. The local computer may not have the necessary registry
information or message DLL files to display messages from a remote
computer. You may be able to use the /AUXSOURCE= flag to retrieve this
description; see Help and Support for details. The following
information is part of the event: \Device\WinDfs\Z:000000000000e6dd,
\Device\WinDfs\Z:000000 .. ~01-destro.

Data:
0000: 00040004 00500002 00000000 80040032
0010: 00000000 c000020c 00000000 00000000
0020: 00000000 00000000 c000020c

These are from the event log; the first sign that something has gone wrong is a “Delayed Write Error” pop-up bubble from the system tray, red “Failed” downloads in Soulseek, and after a few seconds it tells me I’m working offline because the server has gone away.

Steps I tried to correct this:

• Disabling SMB signing. I also took a log level 10 log from Samba and didn’t immediately see anything that suggested Samba was the cause of my problems.
• Disabling write caching on the drive: I don’t even think I was able to do this under VMware.
• Setting SystemPages to 0xFFFFFFFF.
• Setting the disk TimeOutValue to 60.
• Manually setting the duplex and speed on the vmxnet NIC. (This was some insane suggestion I read somewhere. I was getting desperate.)
• Stopping cpuspeed: Windows thought I had a 1GHz CPU, which is only the case when the system is unloaded (CPU is 2GHz max).

None of these fixed my problem. I can’t use Soulseek in XP/VMware; I may be able to live with that thanks to Wine. However, what does this mean for using my drives to, say, store documents? I’ve got sensitive things, like my Palm password DB, going to the Z: drive.

Update (2006-08-22): This problem has gone away. I did a bunch of tests over the course of a couple of days (sometime takes forever as Soulseek decides to rescan my entire collection). Restarting Samba had no effect, playing with all kinds of registry entries (thank goodness for VMware snapshots) didn’t help though I think I did get “offline files” disabled for that share more or less. Weirder still, I could have Soulseek download to a different directory on the same share and it worked fine. I copied the entire contents from the non-working (“Delayed Write Error”) directory to the new directory, and the new directory worked fine. As near as I can tell, the last thing that fixed it was renaming the old directory to something goofy, testing downloads to it (which worked), then renaming it back to its original name. After I renamed it back I no longer had any problems, even with a fresh install of VMware on a VMware snapshot in good working order (i.e., no chance that I left registry tweaks lying around). Go figure.

Moral of the story: try renaming the directory, then naming it back, maybe with some access from Soulseek in between.