@Daedalus

Darn, I was hoping my backups would start going faster when the redundant copy to my Samba server kicks off every day.

_________________
This posting, in it's entirety, is the opinion and/or statement of the author and does not reflect the views and/or position of this site.

@olsen

for some reason the new smbfs doesn't work on my X1000 when connecting to my OpenMediaVault NAS

With previous 1.74 i can mount shares just fine but when i do the same (using smbmounter V1.4) with 1.102 all the system seems locked and workbench suddenly stops responding to my mouse clicks.

it's just when using BackUP 1.91, opening the icon from workbench reads files just fine.

_________________
Cuida tus piedras gordas.

A1200/030 32Mb
A4000D
A1-X1000.

@Ami603

Hmmm, that seems strange. So it's working fine with Workbench but not with BackUp? I've found that BackUp is very slow when browsing network shares due to using an ASL hook checking each file date. If you try to open the share in another requester (e.g. Multiview) does it also freeze? It's working fine here on my 4.1FE machine too - both Workbench and BackUp are able to read the network drives, although BackUp is slow to list the contents of a drawer.

Just a thought - what is your global stack set to? You might be running out of stack in some circumstances which can freeze Workbench. You can set it in the DOS prefs, mine's set to 64KB.

_________________
RobTheNerd.com | InstallerGen | SMBMounter | Atoms-X

@Daedalus

Looks like it might have a bug somewhere. I just tried it and it's not working right for me. When I copy from another computer, file copy worked fine. Trying to copy a file to another computer results in a hung process somewhere (Workbench eventually locks up). When I go look at the file on the server, it's exactly 16644 bytes in size, every time.

I thought it might be a transfer size issue so I tried the MAXTRANSMIT=16384 on the command line. The results in every file not being readable somehow (says it is in use), yet other computers can copy it just fine.

Tried it with the UTF8 option, without MAXTRANSMIT, and it does the same as before trying MAXTRANSMIT.

It doesn't matter how I copy it, whether it is through Workbench windows, or if I use a program, like MRE's ClassAction file manager. Same thing happens (stops at 16644 bytes and a hung process somewhere).

@olsen

If it helps, the server side of this is CentOS 6.7 with Samba version 3.6.23-25.el6_7 on an old Dell workstation. Other computers can read and write to the same shares on the server at the same time.

Here's an example commandline:
Quote:

run >nil: samba:smbfs >nil: DST=`getenv SMBFSDST` domain=DWOLFMAN user=dan server=SERVER password=xxx volume=R client=AMIGAONE service="//SERVER/downloads"

Note the SMBFSDST gets set in the script before this and the other three smbfs commands get run, adjusted to 0 or 60 according to DST.

Back to 1.74, and it's working fine copying both directions.

Last edited by DWolfman on 14-Apr-2016 at 01:36 AM.

_________________
This posting, in it's entirety, is the opinion and/or statement of the author and does not reflect the views and/or position of this site.

@olsen

Oh, and the Samba server has had it's config tweaked a lot to improve performance on the network. These tweaks never changed anything on how smbfs worked under the older versions (always limited to about 6-7 MB/s max copying to the Amiga, about 500 KB/s from it), though it was necessary to get 70+ MB/s on the gigabit connections for all the other computers. I specifically limited it to a maximum of NT1 for the protocol, so it won't try any of the newer stuff (like smb2) on any of the computers just so it stays compatibile.

_________________
This posting, in it's entirety, is the opinion and/or statement of the author and does not reflect the views and/or position of this site.

@DWolfman

Ugh, need to try this again. Should have used MAXTRANSMIT instead of MAXTRANSFER. Odd that it didn't error out.

Fixed the original post, as it does the same thing with MAXTRANSMIT as MAXTRANSFER. Just says "object in use" whenever I try to copy to or from the server shares.

Last edited by DWolfman on 14-Apr-2016 at 01:37 AM.

_________________
This posting, in it's entirety, is the opinion and/or statement of the author and does not reflect the views and/or position of this site.

@DWolfman

Quote:

DWolfman wrote: @olsen Just curious (since I can't check this while at work), did this also fix the speed issues SMBFS had when transferring data to another computer?

No, this was strictly a "figure out what this SMB client actually sends and receives, and if possible fix it" release.

What I found in the code which send and receives file data does suggest that there is room for improvement in terms of throughput/performance. The SMB file sharing protocol has at least two different sets of commands for writing and reading file data (the MorphOS smbfs version uses a third set; I suspect there may be a fourth set, and maybe this very minute a Microsoft engineer could be hard at work creating a fifth set).

The first and original set of write/read commands have some management overhead data attached to the payload. The second set separated that management overhead data from the payload, in an effort to improve throughput.

The smbfs code attempts to "optimize" the use of the write commands, that is, it tries to minimize the number of packets it sends to the server with the file data. To this end it prefers the older write command.

In my tests I found that smbfs almost never ever uses the newer write command (the one with lower overhead) when talking to a Windows system. It works better on Samba systems, but not always.

My idea is that just maybe removing the clever code which prefers the old write command over the new command would have a positive impact on performance.

@Ami603

Quote:

Ami603 wrote: @olsen for some reason the new smbfs doesn't work on my X1000 when connecting to my OpenMediaVault NAS With previous 1.74 i can mount shares just fine but when i do the same (using smbmounter V1.4) with 1.102 all the system seems locked and workbench suddenly stops responding to my mouse clicks. it's just when using BackUP 1.91, opening the icon from workbench reads files just fine.

Please increase the amount of stack space available to smbfs. I verified that the 68k version on AmigaOS 3.x needs at least 15000 bytes of stack space, and 20000 bytes appear to be a safe value.

The OS4 version may require significantly more stack space. I could not test this myself at the time of release. Try 40000 bytes and if things go awry, use more.

@DWolfman

Quote:

DWolfman wrote: @Daedalus Looks like it might have a bug somewhere. I just tried it and it's not working right for me. When I copy from another computer, file copy worked fine. Trying to copy a file to another computer results in a hung process somewhere (Workbench eventually locks up). When I go look at the file on the server, it's exactly 16644 bytes in size, every time. I thought it might be a transfer size issue so I tried the MAXTRANSMIT=16384 on the command line. The results in every file not being readable somehow (says it is in use), yet other computers can copy it just fine.

Careful with the MAXTRANSMIT option, please. I added it so that one could change this parameter without having to recompile the command, but that's just for testing, not for normal use.

The file server and the client tell each other how the large a single message transmitted over the network may become. In days of old a file server might tell you that it could use 4356 bytes or even 16644 bytes (that's what the official documentation says), and a "modern" file server would typically claim to handle up to 65535 bytes (there's a sort of reserved bit in the length field which would allow up to 131071 bytes. Anyway, this value is what the MAXTRANSMIT override can be used to limit.

But it seems that this has little, if any impact, because most SMB file system clients seem to ignore that value altogether and just assume that 65536 bytes will be OK.

In so many words, don't use the MAXTRANSMIT option. I'll have to remove it in the next update.

Quote:

Tried it with the UTF8 option, without MAXTRANSMIT, and it does the same as before trying MAXTRANSMIT.

The UTF8 switch changes how file names are encoded and decoded and should have no impact on file system performance.

Quote:

It doesn't matter how I copy it, whether it is through Workbench windows, or if I use a program, like MRE's ClassAction file manager. Same thing happens (stops at 16644 bytes and a hung process somewhere).

I have a hunch that the smbfs client might be crashing/hanging due to lack of stack space.

@DWolfman

Quote:

DWolfman wrote: @DWolfman Fixed the original post, as it does the same thing with MAXTRANSMIT as MAXTRANSFER. Just says "object in use" whenever I try to copy to or from the server shares.

Ouch. "Object in use" is likely not close enough to the original error as reported by the file server.

The smbfs code is based upon a Linux SMB file system, which mapped the SMB file sharing error codes (there are 76 of these, some of which are very specific) to Unix error codes (32 of these are used).

The Unix error codes are mapped to AmigaDOS error codes, which generally are not as specific as the Unix errors, if they match at all. For example, there is an SMB file system error code which tells you in no uncertain terms that you do not have the proper access rights for a file or directory (ERRnoaccess). This gets translated into a Unix error code (EACCES) which comes out as AmigaDOS error "object in use" (ERROR_OBJECT_NOT_FOUND), because there is no AmigaDOS error code which fits the purpose better.

It gets worse. Certain distinct error codes in the SMB file system get mapped to the same Unix error code, and some distinct Unix error codes get mapped to the same AmigaDOS error code. For example, the Unix error code EIO, which is a catch-all for errors which did not fit anything else, may, depending upon the respective context, come out as several different AmigaDOS error codes, among which is (unsurprisingly) ERROR_OBJECT_NOT_FOUND.

If you've managed to hold onto your sanity so far, you might understand why I reluctantly wrote a gigantic SMB message decoder which breaks down exactly what the file server and client send to each other, just so that I could make better sense of what was going on/wrong/round the bend.

This decoder is not built into the smbfs 1.102 version which is currently available for download. Looks like I'll have to make another release with a debug version, so that we can get to the bottom of this.

Last edited by olsen on 14-Apr-2016 at 11:55 AM.
Last edited by olsen on 14-Apr-2016 at 10:38 AM.

@Daedalus

How can you compare slow 10Mbit ethernet on a dead slow 16bit cpu driven PCMCIA (aka ISA bus) and 20+ year old CPU with something that runs Windows 7 and most likely has at least 100Mbit DMA driven ethernet on at least a 32bit PCI bus?! Even if there was excellent speed improvements, you would barely notice!

_________________
B5D6A1D019D5D45BCC56F4782AC220D8B3E2A6CC

@kolla

Quote:

kolla wrote: @Daedalus How can you compare slow 10Mbit ethernet on a dead slow 16bit cpu driven PCMCIA (aka ISA bus) and 20+ year old CPU with something that runs Windows 7 and most likely has at least 100Mbit DMA driven ethernet on at least a 32bit PCI bus?! Even if there was excellent speed improvements, you would barely notice!

With the kind of odd write command implementation in smbfs I expect that you'd be more likely to spot the difference on a high latency/low bandwidth 10 MBit/s Ethernet link than on something much nicer. There just isn't enough spare bandwidth around to waste it like smbfs does

@olsen

Quote:

olsen wrote: I have a hunch that the smbfs client might be crashing/hanging due to lack of stack space.

I'm honestly not sure what the stack size is currently set to for that script. I'll check it and post again later. At work now so can't easily test it just yet.

And I only tried the MAXTRANSMIT setting. Since things got worse with it, I removed it from my script.

Last edited by DWolfman on 14-Apr-2016 at 02:30 PM.

_________________
This posting, in it's entirety, is the opinion and/or statement of the author and does not reflect the views and/or position of this site.

It's very good to see SMBFS makes progress. I sincerely thank everyone involved and hope that someone will pick up AROS SMBFS port to update it as well.

Got a chance to check the stack size. If it is the stack, it looks like 64K isn't enough, as that's what it is getting right now.

_________________
This posting, in it's entirety, is the opinion and/or statement of the author and does not reflect the views and/or position of this site.

@kolla

Couple of things. First off, it was a 100Mbit, 32-bit PCI NIC in my A1200 which, while still not particularly fast compared to a modern PC, is far faster than a PCMCIA NIC.

Second, maybe I didn't make it clear enough in the post, but both of my copying tests were carried out from Workbench on the Amiga. The write test took 3:32 to copy a file from the Amiga's HD to the Windows 7 share using Workbench to drag & drop, a speed of about 18KB/s. The read test took 0:20 to copy a file from the Windows 7 share to the Amiga's HD also using Workbench to drag & drop, which is a far more respectable 195KB/s. Both tests were over the exact same infrastructure and executed from the Amiga via SMBFS - the only difference was the direction of the data.

_________________
RobTheNerd.com | InstallerGen | SMBMounter | Atoms-X

mysteriously doubled posting... deleted.

Last edited by paolone on 15-Apr-2016 at 11:15 AM.

@olsen

Well, I don't think it's the stack size. Increased it to 128K, and it still does the same (crashes at 16644 bytes). Seems odd it happens there, as you mentioned it is a value that is part of the protocol.

I was accessing through AmiVNC, but now the Workbench is locked up. I'll need to have someone at home reboot it for me again.

Next time I'm opening the Reboot window (and leaving it to click on) BEFORE I try testing it. It is at least not completely locked up, as I can still change the focused window with mouseclicks and move the existing windows around.

Last edited by DWolfman on 14-Apr-2016 at 03:01 PM.

_________________
This posting, in it's entirety, is the opinion and/or statement of the author and does not reflect the views and/or position of this site.

Now here's some interesting info.

Seems if you can send a break signal to the SMBFS task that is "hung" it will then eventually exit normally and the Workbench comes back.

I also was able to use SysMon to watch the stack usage. With Tasks tab set to autorefresh, I saw that it stuck with 9% of the 128K stack in use, even while it was hung.

Seems the issue is not the stack, but something else.

_________________
This posting, in it's entirety, is the opinion and/or statement of the author and does not reflect the views and/or position of this site.

@olsen

Awesome work so far, thank you very much for the development

@pvanni


You've got PM