4

When my system boots, as it probes the external, USB-attached hard drive, I get the message Assuming drive cache: write through in the dmesg output, tagged with the device name of the external drive.

Since I use this drive to store backups, I'd really prefer the system to not make any assumptions about the drive's characteristics. I'm willing to trade write performance for secure knowledge that when something has been written to a file system on the drive in question, it really has been committed to permanent storage and isn't sitting in a cache somewhere (preferably not even on the drive itself, since a power failure will cause both the computer and the drive to lose power immediately).

A possibly complicating factor is that the drive holds a single partition, which is LUKS encrypted. The file system only exists within that LUKS container, like so:

+- physical drive ------------------------+
|                                         |
|  +- partition -----------------------+  |
|  |                                   |  |
|  |  +- LUKS encryption -----------+  |  |
|  |  |                             |  |  |
|  |  |  +- file system ---------+  |  |  |
|  |  |  |                       |  |  |  |
|  |  |  |      actual data      |  |  |  |
|  |  |  |                       |  |  |  |
|  |  |  +-----------------------+  |  |  |
|  |  |                             |  |  |
|  |  +-----------------------------+  |  |
|  |                                   |  |
|  +-----------------------------------+  |
|                                         |
+-----------------------------------------+

Hence my question: How can I make sure that all writes are committed to physical storage before being reported back to the userspace application as completed?

3

There are two constituent parts here: the disk write cache, and the filesystem cache.

The disk write cache can be disabled using hdparm -W 0 [device]. You can disable filesystem write caching by mounting/remounting it with the sync option. Note that these changes will greatly degrade performance.

  • I think I'll give this a try and see how much it does affect performance. Like I said, I'm willing to trade write performance for knowledge that writes have been committed. – a CVn Apr 21 '13 at 11:19
  • 1
    @MichaelKjörling If you find this degrades write performance too much, consider keeping the filesystem cache, but lowering its flush times. For example, with Linux extended filesystems, you can use the commit option to force the buffers to be flushed at a certain interval. Doing such a thing with the hard disk itself is more complicated. – Chris Down Apr 21 '13 at 11:22
  • @ChrisDown fwiw there are also quite a few sysctl's for adjusting pdflush intervals (by percentages, by oldest dirty page's age, by total size of dirty pages, etc). That gives you something to throttle without going into anything OS specific (I also, since it's strictly about I/O think pdflush sits lower in the stack than filesystems do, so it may still be catching and queuing I/O even if your throttle commit). – Bratchley May 23 '13 at 20:03
  • Damn it, I missed my five minute window. I meant "anything FS specific" my muscle memory kicked in though. – Bratchley May 23 '13 at 20:15

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.