Now, does the 'disk'-cache also exist on a (4- or 8-GB) USB stick? Incidentally, what about a solid state drive?
No. No. The flash memory in these devices is so much faster than rotating platters with R/W head actuators that a cache is not cost effective.
But the lack of a "cache" on these devices does not mean that there is no local buffering.
There would still be memory to buffer the sector data between the USB or SATA interface and the flash memory.
if /bin/sync would be necessary on Linux to absolutely guarantee that no data loss occurs should a power failure occur shortly after the OS has reported the write operation to be complete?
sync is always required to ensure that the OS has properly flushed all of its buffers to the device.
write() completion (depending on the synchronization specified) may only indicate the user or file data has been transferred to the system buffer or that the write operation has actually completed. But besides the data in the file, there would be filesystem metadata that also has to be maintained (sector allocation tables, directory entries for file length, modification time etc.).
sync alone is not sufficient to guarantee that all written data has actually been written by the peripheral. A related syscall to
syncfs, which implies that these are only for the filesystem level, and not at the device level. There are device-level synchronization operations as well as filesystem-level synch operations.
eject operations should perform these final synchronization confirmations before the device is released.
if /bin/mount -o sync ... would 'effectively' disable such a on-board cache (if it at all exists)?
No, this "synchronization" at the mount level should not affect any device level optimization. If the peripheral's cache is capable of being disabled, I would expect it to be done by an
mount would not likely know about.
and finally, how the answers to all of the above would fare if the OS were Windows instead of Linux?
No significant difference.