Unix & Linux Stack Exchange is a question and answer site for users of Linux, FreeBSD and other Un*x-like operating systems. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I store documents on btrfs partition built upon sparse dm-crypt device located on ext4 main partition on physical harddrive.

When kernel panics (and this happens on daily basis on my ASUS P53E with 3.6 kernel :-( ) I loose recently modified files (always the files' contents got replaced with zeros).

One way of preventing damage to files it is to disable the write cache.

For this I would need to disable write caching for the btrfs partition, the dm-crypt device that backs the partition, and for the sparse file where dm-crypt device lives.

  1. How can I check the cache-write status for the drives?
  2. How can I disable it?

I use Mint 13 Maya with 3.6.8 mainline kernel.

share|improve this question
up vote 2 down vote accepted

I'm not sure the disk drives write cache is going to fix the issue for you as it sounds like you are using a loop device. So there is still the page cache/file in between your Btrfs filesystem and the actual disk. The same type of issue exists for journaling filesystems detailed here for loop-AES. So when data is synced to your loop device, it may not be on real disk yet just in a cache waiting to be re ordered and written out.

ext4 doesn't support the sync mount option ext2/3 did to disable caching. due to the layers in between I'm not sure even that would get you an effective recovery. I don't know enough about the internals unfortunately, at least more data would make it to disc.

In the same way you might be able to limit the issue by tuning the page cache so the system writes out to disk more often. The linux page cache reports it's values in /proc/meminfo under

"Dirty" - for pages that are currently dirty
"Writeback" - for dirty pages that are being written out to disk.

There are files in /proc/sys/vm/ that report status and control the flush threads that write data back to disk.

You could put a small value (greater than 8096 or 2 pages) in /proc/sys/vm/dirty_background_bytes to make the background pdflush process run more actively or /proc/sys/vm/dirty_bytes to make a process trigger flush more actively (For a performance penalty, or at least more disk writes overall).

I think it's unlikely the hardware write cache is where your main issue lies. If you were only going direct to the device via dm-crypt then I'd look there first. In any case IDE and SATA write caches can be disabled with hdparm -W0 /dev/xdx.

Also as your using a, technically, experimental file system in a more edge case way than most you might have better luck with a more mature fs where people have stumbled into the issues already. If you need Btrfs, the best bet would be to do the encryption to a physical partition.

share|improve this answer

So far I have found a way of setting write-cache behavior for physical partition (/dev/sda6 in my case):

sudo hdparm -W /dev/sda6 for inspecting the write behavior and sudo hdparm -W0 /dev/sda6 for disabling the write-cache.

But it is an overkill in my situation; I want only to disable write-cache for the file backing the dm-crypt, not the entire partition.

share|improve this answer
Sorry.. had the answer window open for too long to see this before my post. I'm not aware of a system way you can do this. You can provide an O_DIRECT option when opening a file so it should be possible for the loop driver to open the file that way. Whether or not that includes modifying source code is another question =) Maybe loop already does that and the issue does lies somewhere else... – Matt Dec 7 '12 at 16:43
@mindthemonkey The hdparm trick described above did solve the issue once, but I'm my (involuntary :-( ) tests are still inconclusive. I moved the documents out of the sparse file into physical, encrypted with dm-crypt partition. I hope it will improve the robustness of the storage. – Adam Ryczkowski Dec 8 '12 at 20:37

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

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