Many buffer cache implementation have a delay before writing starts. From an overall performance sense, that makes great sense: files are often modified again, read again, or deleted, right after writing. Waiting 10 or 30 seconds has a good chance to eliminate useless work, or delay necessary work to a time when the system is more quiet. And if the application cares, it can always force the write to happen sooner.
Actually, I'm quite surprised that FreeBSD finished the write just as the cp command finished. It could be that this is specific to the FAT file system. But I would not characterize FreeBSD's cache mechanism is general as "write through"; that would lead to ridiculously bad performance. To begin with, on a disk that rotates at 7200 rpm, you on average have to wait 40ms for a write, leading to only about 240 writes per second, and with normal IO sizes, this would be laughably slow.
Actually, I'm quite surprised that FreeBSD finished the write just as the cp command finished. It could be that this is specific to the FAT file system. But I would not characterize FreeBSD's cache mechanism is general as "write through"; that would lead to ridiculously bad performance. To begin with, on a disk that rotates at 7200 rpm, you on average have to wait 40ms for a write, leading to only about 240 writes per second, and with normal IO sizes, this would be laughably slow.