Q1: What parameters are manipulated with each of these create data set share type options?
That's deliberately hidden as an implementation detail, since we reserve the right to change it as experience and best practices dictate. If you're really motivated to find out, the source code is generally available. :)
Q2: Is it possible to switch the data set parameters in order to change a CIFS/Windows type data set into an Apple type data set? How? What parameters need to be changed?
Not currently, no. This is a creation-time attribute.
Q3: In the web browser, storage tab, pop-up window from edit ZFS data set; how is that value for shared type determined? Does the GUI dynamically read various parameters and make a best guess?
Not sure I understand this question.
Q4: Is it best to make sure that the various parameters are set to the correct profile prior to upgrading, or, does the upgrade process examine and change any of these parameters?
Kind of the opposite - it's best to make sure that the various parameters are set correctly *after* upgrading, since upgrades tends to preserve the old preferences (because that's just how upgrades work) and you need to check after the upgrade to see if you've carried an old option forward.
the format of the ._ file is exactly as the Mac’s CIFS client expects it when accessing the same filesystem via a CIFS server (Samba), thus you can have parallel access from Macs to the same dataset via AFP and CIFS without the risk of loosing data (resources or metadata).
While that is technically true, what is not being said here is the fact that smbd, netatalk and nfsd are all separate user-land services and do not implement things like locking semantics the same way, so if you run multiple share types from a single dataset, it's not clear that one will not go behind the back of another. Let's say that NFS flock()s a file a client is working on, but Samba comes along and says "I will use Windows oplocks, because that is how Windows rolls!", you could have a locked file changed out from under you (a lock type can be advisory, it doesn't necessarily have to prevent other things from ignoring the advice and opening things read/write).
This could be potentially changed some day if we implemented a single distributed lock manager on FreeNAS and had all of the various sharing services coordinate their operations through it, but that is a pipe dream for the future. We just don't have enough engineering resources available to make all of the relevant changes that would be necessary (and maintain those changes indefinitely in projects like samba and netatalk), so for now the rule is "one dataset, one sharing type".
