I've had an issue with one of my pi cameras skipping frames on complex input (a fast 4 channel scope on a big display), when using a big (128gig) USB3 stick mounted over /, and therefore also being where the media goes. Troubleshooting this is somewhat complex as it's hard to get inside the (not all open source) code to figure out who does what and when. There's even code on the camera module that's free running doing mjpegs at whatever frame rate it decides that can bog down regardless of the response time of the pi stuff, for example.
Well, it turns out that even though a big USB stick on a pi is actually faster than any SD card for most things I've measured, it has the occasional latency issue - a bad one. Admittedly, this is worst case, as in 4 very quickly changing traces "full FOV", trying to be compressed in realtime and written down, evidently with little to no buffering..the net result being frame skipping - sometimes one, but more often 1-3 SECONDS of just plain lost video.
This mattered hugely to our data aq, as this isn't the only realtime data source, and we wanted to be able to go N seconds into a run and see the scope, the grid, hear the audio, look at the numbers for the various other things we're acquiring and so on - and by the nature of this beast, there's no timestamp inside the video stream (or the audio) and we have to depend on them staying in sync once started that way - we have a "clapboard" led signal that shows up in all the streams just after they are started so we can sync the begin times.
After trying a new, faster Pi, and a newer camera (going from version 1.3 to 2) and it not getting any better, in desperation we mounted a "real" SSD (only a Samsung 840 evo, and yes, I know about those issues) over the /www/html/media directory to take the videos.
Problem solved. I haven't tested to full frame rates again; I'd cut down the frame rate thinking that was part of the issue but that had zero effect...but this seems like the real deal. We were losing 3-30 seconds worth of a 5-6 minute run and now...none at all.
I am guessing that the USB drive "went off on some demented errand of its own" to load level for awhile, and I kind of doubt it matters what brand, they all do something like that and have a cpu in them just for that: http://www.bunniestudios.com/blog/?p=3554 There could be a difference in manufacturer's code for this and how well they interleave that with data demands, dunno. Both were samsung in this case...
This is somewhat related to the post about adding a big drive to a Pi, in this case, yet another one. The new one won't fit inside the EMI tight box, but I might make a new box if that starts to matter.