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
prev parent 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).