From: Milan Broz <mbroz@redhat.com>
To: Bryan Kadzban <cryptsetup@kdzbn.homelinux.net>
Cc: Peter Smith <peter.smith3882100@gmail.com>,
dm-crypt@saout.de,
Christoph Anton Mitterer
<christoph.anton.mitterer@physik.uni-muenchen.de>
Subject: Re: [dm-crypt] SSD dm-crypt partition alignment
Date: Wed, 25 Aug 2010 18:21:06 +0200 [thread overview]
Message-ID: <4C7542F2.9090109@redhat.com> (raw)
In-Reply-To: <4C753CA9.50908@kdzbn.homelinux.net>
Seems some confusion here, in short:
Data alignment:
- default cryptsetup <= 1.1.3 (LUKS data offset) alignment is 4k
- cryptsetup 1.1.3 understand topology info provided by kernel,
if storage (SSD) announces proper values, it is properly aligned
(kernel with topology ioctl support required)
- devel version (next cryptsetup, change in svn already) will use default alignment
to 1MiB (if 1 MiB is multiple of topology alignment, it remains 1MiB; otherwise
it is aligned according to topology info - useful for nonstandard RAID devices)
Aligning to 1MiB is now trend in storage technology and it is safe default
for most of these configs (I'll describe reasons in release notes).
If you want align LUKS even in old version or use explicit value
add to luksFormat --align-payload=2048
(in 512B sectors - here aligns to 1MiB boundary)
(in most cases it cause encrypted data offset to start on sector 4096)
All basic storage tools should now align to optimal values by default
(like fdisk/lvm2/cryptsetup/mdadm etc) - in recent versions.
So the whole storage stack should not suffer from possible misalignment.
TRIM:
(nothing to do with alignment above, this is also kernel-only thing)
- device-mapper in 2.6.36 have support for TRIM/discard except dm-crypt target.
dm-crypt ignores it, later we probably add some optional support,
but default will be always ignore trim/discard for security reasons.
Milan
next prev parent reply other threads:[~2010-08-25 16:21 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-08-18 14:38 [dm-crypt] SSD dm-crypt partition alignment Peter Smith
2010-08-21 14:19 ` Christoph Anton Mitterer
2010-08-22 13:31 ` Peter Smith
[not found] ` <AANLkTimLhoZmAo=Un04u+GE+j0TUtgSHpOa+4hKht+=3@mail.gmail.com>
2010-08-25 10:05 ` Christoph Anton Mitterer
2010-08-25 15:54 ` Bryan Kadzban
2010-08-25 16:21 ` Milan Broz [this message]
2010-08-25 17:25 ` Christoph Anton Mitterer
2010-08-25 17:17 ` Christoph Anton Mitterer
2010-09-01 21:02 ` Peter Smith
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=4C7542F2.9090109@redhat.com \
--to=mbroz@redhat.com \
--cc=christoph.anton.mitterer@physik.uni-muenchen.de \
--cc=cryptsetup@kdzbn.homelinux.net \
--cc=dm-crypt@saout.de \
--cc=peter.smith3882100@gmail.com \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.