Thanks for the time and thoughts. All of them are appreciated
@Spyder, sort of. I am currently sending gcode (x3g) files over WiFi to a FlashAir SD card in one of my printers. The printer has lousy firmware compatibility with OctoPrint's needs for working with a printer's SD card and for monitoring SD card prints. I'd like to improve my experience, which means either a) changing my firmware and possibly the board running the printer, or b) finding an effective way to save files directly to the OctoPi install via WebDAV or NFS and taking the performance hit to print via USB while both network and webcam I/O are also on the same USB bus (which could be a major hit, since my print speeds often get up around 100mm/s, depending on materials and the model).
@b-morgan, I did dig up the RPi NFS info last night, and I think that's most likely what I'll end up with for now, though NFS server would be better than NFS client, unless I were to set up a NAS mount point for each OctoPi/printer combo and push my gcode from S3D to the NAS and then have OctoPrint watch that combo's share. It seems like a bit of overkill to me, though, to add a middle man, except for the potential advantage of not worrying about SD card corruption on the RPi. Since the RPis are all on a UPS, though, I'm not super concerned about corruption due to power failures. Either way, yes, the watched folder as a mount point should be the "right" way to do it.
@loclhst, If you have a FlashAir W-03 or W-04 with firmware 3.x or above installed, you can set WEBDAV=2 in your CONFIG file to turn on WebDAV, which I've done. The FlashAir isn't SMB compatible, IIRC, so you'd either have to get a MicroSD<->SD card adapter and put a FlashAir on the RPi instead of the printer, or you'd have to use a printer that is SMB enabled (basically using MachineKit on a BBB, which I'm not sure OctoPrint supports). If you just want to avoid WebDAV on the FlashAir, you could use a post-processing script to POST the file to the card, though I'm not sure how that'd be better. I do already have my RPis set up via ethernet, with wifi disabled, since it is about 2 feet to the nearest gigabit switch You're right, though, it does reduce CPU load because you don't have to worry about all of the WPA and wifi link management stuff that eats CPU in the background.
@OutsourcedGuru, it's more a question of overhead with SMB vs NFS on both the RPi side and the OS X side. Because NFS natively uses POSIX file permissions, as do both Linux and OS X, it seems to me that NFS should be a lot more resource efficient, as it isn't doing a bunch of remapping of users, groups, and permissions. NFS also far predates SMB, so, while both are considered mature, my thought is that resource bottlenecks have likely been ironed out a bit better over time (I remember times in the past where both NFS and SMB were resource hogs, but it's worth looking at some data if we're trying to be REALLY efficient). AFS, on the other hand, is a NIGHTMARE to use on anything that isn't OS X, due to a wide variety of bugs, quirks, and oddities in implementations not done by Apple.
I just bought another printer of the same model as my primary and plan to experiment with different firmware and possibly a different board in it, to see if I can get better data to OctoPrint. If I succeed, I'll then upgrade my primary printer similarly and may actually abandon this whole exercise.
In an ideal world, OctoPrint would be getting much better and more robust information from the firmware on my printer, and thus would have progress data, full file listings, and could really be focused on features like monitoring, manual control, cam/timelapse, and statistics. USB is really not the most efficient way to drive a printer, so I really want to get the best of both worlds: WiFi push of gcode to the printer, OctoPrint launching and monitoring SD card prints, webcams, and stats, and my desktop free for part design and slicing at all times.