[clug] Ubuntu encrypted file systems

Daniel Pittman daniel at rimspace.net
Fri Aug 21 19:29:21 MDT 2009

Kevin Pulo <kev at pulo.com.au> writes:
> On Fri, Aug 21, 2009 at 07:33:28PM +1000, Daniel Pittman wrote:
>> For what it is worth, a LVM and LUKS based dmcrypt stack, on software RAID1,
>> has insignificant extra latency for me: performance is about the same as
>> sitting directly on the RAID1, in almost all cases.
> Is it still the case that DM doesn't pass barriers through, even in
> simple cases, and thus preventing effective use of write caching?

Yes, and so, respectively.  Yes, it is my understanding that Device Mapper
does not pass through barriers.  No, that doesn't prevent effective use of
write caching, but rather presents it in *SOME* situations.

For example, this being a laptop I have a fine, battery backed set of disk
cache, allowing me to be quite comfortable that barriers are vastly less
relevant to the whole show.[1]

Likewise, my server has a UPS, so doesn't depend on barriers to ensure data
integrity to disk the same way a machine that *doesn't* have a reliable write
cache does.

> On a LUKS setup I have for backups, I have write-caching disabled despite
> using ext3 -o barrier=1, because the reliability is more important than
> speed.  But that was a while ago now, are recent kernels any better?

No.  Um, if you care[2], write-cache disabled is still hugely faster on most
consumer and business grade equipment.  You really need to get right up into
the high end before barriers stop being a net loss.


[1]  ...and disks that don't like about flushing, which also matters.

[2]  For most practical purposes, you don't.  Worst case data losses are very
     contained, and good backups make up for a lot of sins.

✣ Daniel Pittman            ✉ daniel at rimspace.net            ☎ +61 401 155 707
               ♽ made with 100 percent post-consumer electrons
   Looking for work?  Love Perl?  In Melbourne, Australia?  We are hiring.

More information about the linux mailing list