dm-crypt.saout.de archive mirror
 help / color / mirror / Atom feed
From: Milan Broz <mbroz@redhat.com>
To: mark <mark@aktivix.org>
Cc: dm-crypt@saout.de
Subject: Re: [dm-crypt] How to optimise encrypted filesystems on an SSD?
Date: Sat, 06 Feb 2010 10:26:43 +0100	[thread overview]
Message-ID: <4B6D35D3.3040607@redhat.com> (raw)
In-Reply-To: <4B6CAE3F.2060605@aktivix.org>

On 02/06/2010 12:48 AM, mark wrote:
> For a while I've been using LUKS/dm-crypt with LVM2 to secure hard
> drives in laptops and servers. Recently I've moved one of my filesystems
> onto a solid-state drive (Intel X25-M-G2 80GB with latest firmware).
> 
> There are some excellent instructions here
> http://thunk.org/tytso/blog/2009/02/20/aligning-filesystems-to-an-ssds-erase-block-size/

Beware - that page is completely obsolete regarding lvm2 now!
Recent version have much more better support for data  alignment
(with new kernels it should be automatic)

> on how to align ext4 and LVM to the erase block size of the SSD. However
> I've not been able to find a recipe for optimising an encrypted
> filesystem in the same way.
> 
> A typical usage case for me would be this, from following defaults for
> encrypted lvm on the Debian installer:
> 
> /dev/sda1 79GB crypt-luks
> /dev/mapper/sda1_crypt holds PV for LVM2
>      PV has a VG with two LVs, 4GB swap and the rest for ext4 /
> /dev/sda5 256MB ext2 /boot
> 
> Could anyone explain how I might go about aligning/optimising this, or
> point me to some instructions? Am I better putting lvm over luks or luks
> over lvm? Or something entirely different?

Just in short:
(cryptsetup will get support for automatic alignment according
to kernel exported device parameters soon, so all this will be automatic)

- the underlying device must be aligned
(if using partitions, be sure you have start of partition aligned,
better use "fdisk -u" to calculate in sectors.
If not sure, align to 1M or even 4M offset, this will always fit:-)
(fdisk from latest util-linux-ng should support automatic alignment)

- be sure that lvm2 PV metadata (data start) is always aligned
(see pvcreate --dataalignment parameter)
(latest lvm2 already have support for automatic data alignment
if kernel exports proper alignment data)

- for cryptetup/LUKS - use "--align-payload" parameter
(default is alignment to 4k boundary, not enough for SSD).
Note that parameter is in 512 bytes sectors!

e.g. you want to align to 4MB boundary ( = 8192 * 512 bytes), use

  cryptsetup luksFormat --align-payload=8192 ...

verify with cryptsetup luksDump (see Payload offset)

(I usually set lvm2 extent size to 4MB and aling LUKS the same,
so the LUKS header takes exactly one extent.)

- and finally, you should optimize FS above that device stack

(From the kernel point of view, there is no difference
if you put lvm2 over LUKS or vice versa - both should work the same.
Just configuration is different, I have some old slides describing
activation of volumes here http://mbroz.fedorapeople.org/talks/LinuxAlt2008-eng/ )

Milan

      reply	other threads:[~2010-02-06  9:26 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-02-05 23:48 [dm-crypt] How to optimise encrypted filesystems on an SSD? mark
2010-02-06  9:26 ` Milan Broz [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4B6D35D3.3040607@redhat.com \
    --to=mbroz@redhat.com \
    --cc=dm-crypt@saout.de \
    --cc=mark@aktivix.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).