8.0.3 RELEASE coming soon

[gcooper]

I guest for compatibility/reliability reasons Asynchronous IO is enabled by default now....

I did it because it was the path of least resistance, but yes.. previously the setting was explicitly off, which was in fact a bug with how port options were specified in freenas-common.

Is Synchronous IO used if AIO is disabled?

Yes(-ish). The code path that finally calls aio_read/aio_write is incredibly obfuscated, but bottom line is that the stub always returns -1/sets errno to ENOSYS if WITH_AIO != 1 (either because OS support is missing as determined by configure, or the person that compiled samba didn't explicitly request AIO support via --with-aio).

From my understanding Synchronous communications is virtually always more complex but also have much higher throughput than Asynchronous.

Depends on how things are programmed, but synchronous I/O is usually simpler with a 1:1 [PID:socket]. With threads the converse is usually true. Samba's worker jobs use processes, not threads.

I didn't look to see what Samba uses for processing sockets (e.g. kqueue*, poll, select, etc).

With previous 8.0.3 I was getting slightly faster writes than read, but now it's much slower writes w/ AIO enabled.

Please qualify "previous 8.0.3" -- do you mean BETA1, RC1, RELEASE, RELEASE-p1? Also, it might depend on what storage chipset you're using, etc... but yes.. having less RAM will most certainly make CIFS perform slower in 8.0.3 compared to versions prior to 8.0.3 if AIO operations queue up and things oversaturate.

 

[Simon00]

My previous was 8.0.3-RELEASE, and am using 8.0.3-RELEASE-p1 now. It's on one of the cheap NVIDIA chipset eMachines w/ DVD-RW removed w/ 2 new 2TB HDD in ZFS mirror (512KB sector) and booting off of a SD memory card. FreeNAS-7-RELEASE had issues w/ this the NVIDIA SATA controllers, newer FreeNAS-7 had fixed it though, but I figured might as well upgrade to FreeNAS-8-RELEASE. I find the WebUI upgrades to be very problematic, so I just export the volume and swap SD cards and re-import the volume.

With AIO enabled, disk write speeds are like a seesaw and not continuous. Thus hard drive is accessed/written to in a way that is much "noisier" than before more, head movements it seems.

Even my old Netgear ReadyNAS (with 256MB RAM) I use to have, writes continuously, albeit slowly...

 

[Simon00]

Just an update...

After doing some tests with large and small files which had hashes computed beforehand, having AIO disabled was much better in my case. I was concerned with possible corruption, and only after stress testing it and verifying the files thoroughly before I decided, though...

My read/write speeds are now just as fast as before... Can't wait for the next upgrade...

 

[gcooper]

Please note the following disclaimer if you're wondering why CIFS performance isn't good on reasonably fast hardware with 8.0.3 with multiple concurrent transfers with AIO on:

Code:

       aio read size (S)

           If Samba has been built with asynchronous I/O support and this
           integer parameter is set to non-zero value, Samba will read from
           file asynchronously when size of request is bigger than this value.
           Note that it happens only for non-chained and non-chaining reads
           and when not using write cache.

           Current implementation of asynchronous I/O in Samba 3.0 does
           support only up to 10 outstanding asynchronous requests, read and
           write combined.

           Related command: write cache size

           Related command: aio write size

           Default: aio read size = 0

           Example: aio read size = 16384 # Use asynchronous I/O for reads
           bigger than 16KB request size

Discovered after banging my head against the wall for a few weeks trying to figure out a performance issue. I'm going to see about turning off AIO by default and having someone note this caveat in the docs.

 

[gcooper]

Please note the following disclaimer if you're wondering why CIFS performance isn't good on reasonably fast hardware with 8.0.3 with multiple concurrent transfers with AIO on:

...

Discovered after banging my head against the wall for a few weeks trying to figure out a performance issue. I'm going to see about turning off AIO by default and having someone note this caveat in the docs.

And then things performed better when using memory backed disks in Windows... it looked like the performance was client limited. LOL.