Oh yeah that’s where I was getting at, but I didn’t have time to write that out earlier. I agree that OP probably pulled out the usb stick before buffers were flushed. I imagine that direct I/O would mitigate this problem a lot because presumably whatever buffers still exist (there would some hardware buffers and I think Linux kernel I/O buffers) will be minimal compared to the potentially large amount of dirty pages one might accumulate using normal cached writes. So I imagine those buffers would be empty very shortly (less than one second maybe?) after dd finishes, whereas I’ve seen regular dd finish tens of seconds before my usb stick stopped blinking it’s LED. Still if you wait for that long the result will be the same.
I don’t think oflags=direct has any influence on the result. Apparently that’s about disabling the page cache in the kernel, which can avoid a situation in which the system slows down due to buildup yet-to-write pages.
Oh yeah that’s where I was getting at, but I didn’t have time to write that out earlier. I agree that OP probably pulled out the usb stick before buffers were flushed. I imagine that direct I/O would mitigate this problem a lot because presumably whatever buffers still exist (there would some hardware buffers and I think Linux kernel I/O buffers) will be minimal compared to the potentially large amount of dirty pages one might accumulate using normal cached writes. So I imagine those buffers would be empty very shortly (less than one second maybe?) after dd finishes, whereas I’ve seen regular dd finish tens of seconds before my usb stick stopped blinking it’s LED. Still if you wait for that long the result will be the same.