I have a backup app that writes megabytes to a USB flash drive. Before I start the verify operation, I call sync() to make sure I am reading from the device and not from the disk cache.

The funny thing I see happening is that even when a tiny amount of data was written, the time for sync is about 30 seconds, about a factor of 100 too long. The LED on the flash drive blinks the entire time, which I think means that it is really active this long.

There seems to be no way to do cache purging on a device or process basis. I see only a file basis (fsync) or the whole system (sync). This seems crippled. Also, sync can be called by a non-privileged process, opening the door for some dirty tricks (slowing a server down to a crawl).

I am using exf2 on the flash drive. Is that significant?

thanks

Flash memory drives are know to be slow, but30 secs does sound like a long time.

Are you reading files, or doing directory listings, or walk through directory trees before calling sync()? If so, that maybe the cause of this long sync() time.

Most (all?) unix/linux filesystems update the the access times for files and directories. This means when you are reading a file or a directory (like 'ls' does), this causes writing access times to the meta-data of the filesystem.

If this causes you long sync() times, you can can solve it by mounting the flash drive with de "noatime" mount option to disable this behaviour. Or use vfat.