One more consideration for whether to store the files inside the database or not is how much space gets wasted due to the block size. Files stored in the filesystem get their size rounded up to the block size of the device. For Linux this tends to be around 512 bytes (blockdev --getbsz /dev/...). Files stored in the database as streams are probably* stored using "big string blocks". Depending on how large the streams are, the total space consumed (used+unused) may be higher when stored in a database. ^REPAIR will show you the organization of a data block. 

*This assumes that the streams are large enough to be stored as big string blocks - if the streams are small and are stored in the data block, then there will probably be little wasted space per block as multiple streams can be packed into a single data block.

Yes, if you have only 16KB buffers configured and both 8KB and 16KB databases, then the 16KB buffers will be used to hold 8KB blocks - one 8KB block stored in one 16KB buffer using only 1/2 the space...

If you allocate both 8KB and 16KB buffers then (for better or worse) you get to control the buffer allocation between the 8KB and 16KB databases. 

I'm just suggesting that this is an alternative to standing up a 2nd server to handle streams stored in a database with a different block size.

I'm not sure what you mean by this. On an IRIS instance configured with global buffers of different sizes, the different sized buffers are organized into sperate pools. Each database is assigned to a pool based on what is the smallest size available that can handle that database. If a system is configured with 8KB and 32KB buffers, the 32KB buffers could be assigned to handle 16KB database or 32KB databases but never 8KB databases.

This is a restriction in the Community Edition and it is what is meant by

All InterSystems IRIS functionality is included except the following:

You can create mappings and activate configurations which contain mappings if that is useful for some purpose (eg. building a configuration for someone else) however all mappings which do not involve a system database are ignored.

uname -n is generally documented as returning a network host name but systems can be configured with multiple networks and it is not defined exactly what uname -n means at that point. 

The methods above, the $SYSTEM variable,  ##class(%SYS.System).GetNodeName(1) and  $System.INetInfo.LocalHostName() all return the network host name which will match uname -n if there is only one network host name on the system. $SYSTEM.InetInfo has additional methods which can be used if there is more than one host name associated with a given system.

Note that the $SYSTEM variable is loaded at system startup and can be overridden with a fixed name as part of the Cache' configuration so on some systems it may differ than what the other methods will return.