I'm desperately trying to get decent file sharing between my Sam440 (OS4.1) and my Windows XP Pro SP3 box, before I can seriously use OS4.1, and things are not going very well:
Writing files from the Amiga to Windows box using SMBFS is incredibly slow (reading is fine), so I am trying Samba v2.2.5 instead. My Windows box can *read* files fine from the Amiga using Samba, however...
Windows is unable to *write* files to the Amiga, if they are 4096 bytes or larger! In those cases Windows reports "The request could not be performed because an I/O device error. (1117)". Checking the Samba logs, I see something like this:
I have tried fiddling with all the smb.conf settings I could find (especially using the 'secret' web interface that runs on port 901 of the Amiga), but nothing seems to make any difference. I have also tried different filing systems (SFS/00, SFS/02 & FFS) without luck. Can anyone suggest anything?
~Yes I am a Kiwi, No, I did not appear as an extra in 'Lord of the Rings'~ 1x AmigaOne X5000 2.0GHz 2gM RadeonR9280X AOS4.x 3x AmigaOne X1000 1.8GHz 2gM RadeonHD7970 AOS4.x
sorry about that, it was pointed out on EAB I believe that many people found the resources on that page invaluable guess it was a specific thing...
all hope rests on Mikey_Cs shoulders now? :D
~Yes I am a Kiwi, No, I did not appear as an extra in 'Lord of the Rings'~ 1x AmigaOne X5000 2.0GHz 2gM RadeonR9280X AOS4.x 3x AmigaOne X1000 1.8GHz 2gM RadeonHD7970 AOS4.x
It's not a DMA issue is it? I suppose you'd probably see it in other areas too if it were, but maybe try disabling DMA on your drives and see if that helps - SAMBA is gonna put pressure on the network and the drive at exactly the same time, so it would be the best conditions for getting DMA errors...
@Daedalus Copying to the RAM disk using Samba has the same problem, and the RAM disk should not have DMA issues just because the harddisk has DMA enabled.
Hmmm... Try lowering your MTU, maybe the network is corrupting something because SMB is sending packets that are too big. I con't remember exactly where the setting is, but there's a Microsoft KnowledgeBase article about it. It involves editing your registry anyway. Your router (if you're using one) should also have this setting somewhere in the advanced settings. IIRC Samba has this setting in its config file, and it may be accessible through the SWAT system, but failing that, Roadshow should have the setting somewhere too. I've solved a lot of problems with networks by lowering this value - some of which involved shared drives, file transfers over a certain size etc. Using a value of 1400 should be safe and not degrade performance noticeably.
@Daedalus Tried changing Windows MTU with a registry hack (I assume it worked), but it didn't help Samba. I can't see any MTU setting for Roadshow. Not yet tried MTU setting on router.
@madmonkey Sounds like you are using AsyncWB. Remove it from the WbStartup folder, then reboot, and you should now be able to copy files using Workbench reliably.
Thx for that but removing AsyncWb makes no difference. It was looking promising but after successfully copying 1.3G of a 1.4G file, the copy failed with object in use
NB I'm using DirectoryOpus to move the files as Workbench hangs navigating folders on the PC.
@madmonkey Ah, I should have said that ASyncWB only causes problems for Workbench file operations. Note that "AutoUpdateWB" may also cause problems with WB.
Perhaps I also have the same problem as you, but I would not know because the write speed has prevented me from testing SMBFS heavily.