Do USB memory sticks have controller and disk-cache on-board?

4

I'm well aware that the spinning-platter type of hard-disks have an on-board controller and an onboard disk-cache.

Now, does the 'disk'-cache also exist on a (4- or 8-GB) USB stick? Incidentally, what about a solid state drive?

(My guess is that because a solid state drive is slower than the RAM of the computer it's attached to, having an on-board disk-cache on a solid state would make sense. But because a USB stick is much smaller both in byte-capacity and physical dimensions relative to a solid state drive, the former may not have an on-board disk-cache.)

Context: I'm trying to find out:

  1. 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?

  2. if /bin/mount -o sync ... would 'effectively' disable such a on-board cache (if it at all exists)?

  3. and finally, how the answers to all of the above would fare if the OS were Windows instead of Linux?

Harry

Posted 2013-09-16T20:31:56.647

Reputation: 647

An USB stick has no real RAM you could use. It has a Flash Transition Layer (FTL), which does (amongst other things) the wear leveling for you. Otoh, it hardens the secure erase. So no hardwae cache. – ott-- – 2013-09-16T20:52:07.270

Answers

2

Yes, USB flash drives do have a controller and some cache onboard. There is no other way to match devices that operate at different speeds. There is no other way to do things like wear-leveling and pipelining.

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?

Yes, but that has nothing to do with the cache in the device. That has to do with the software cache implemented by the OS.

if /bin/mount -o sync ... would 'effectively' disable such a on-board cache (if it at all exists)?

No, it would disable the OS cache. You can't disable the on-board cache or the device would stop working. Where would it hold data that had been read from flash until the OS was ready for it? Where would it hold data the OS had written until the flash write was complete?

and finally, how the answers to all of the above would fare if the OS were Windows instead of Linux?

Same answer. Just like hard drives, other devices that act like hard drives have onboard controllers and caches.

David Schwartz

Posted 2013-09-16T20:31:56.647

Reputation: 58 310

"Where would it hold data ... until the OS is ready for it?" But logically speaking, isn't the whole point of a synchronous operation that no intermediary holds anything? That's why I said "'effectively' disable" and not actually disable. – Harry – 2013-09-17T01:12:06.867

3

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.
A 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.).

But sync alone is not sufficient to guarantee that all written data has actually been written by the peripheral. A related syscall to sync is 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. Unmount or 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 ioctl() that 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.

sawdust

Posted 2013-09-16T20:31:56.647

Reputation: 14 697

"sync is always required to ensure that the OS has properly flushed all of its buffers to the device." But I've heard that certain HDDs that come with write-caching may carry out the actual write at a time of their choosing. As a result, the OS may think the write is complete after the sync but the actual write may still be pending. Is this true? – Harry – 2013-09-16T21:16:29.737

1True, the linux man page for sync(2) warns of this. There are device-level synchronization operations as well as filesystem-level synch operations. Unmount or eject operations should perform these final synchronization confirmations before the device is released. – sawdust – 2013-09-16T21:27:07.073

1@Harry Yes, it's true. – David Schwartz – 2013-09-17T02:20:26.650