From: Arno Wagner <arno@wagner.name>
To: dm-crypt@saout.de
Subject: Re: [dm-crypt] (More) Questions about LUKS / LVM
Date: Tue, 20 Sep 2011 19:41:29 +0200 [thread overview]
Message-ID: <20110920174129.GA25723@tansi.org> (raw)
In-Reply-To: <4E78AF92.9040309@alexanderkoch.net>
On Tue, Sep 20, 2011 at 05:21:54PM +0200, Alexander Koch wrote:
> Am 20.09.2011 13:47, schrieb Arno Wagner:
> > With an SSD, things are a bit different. Due to the large
> > internal sector size, the header can be in a sector that
> > also has data that gets rewritten in it. As sectors are
> > always written completely, the header then is at risk whenever
> > that data gets rewritten.
>
> Did I get that right: by using the TRIM-support available with kernel
> 3.1 I risk loosing my LUKS headers at regular use??
>
> No chance to align the payload (data) in such a way that it starts at a
> new sector, which then can be TRIMed without loosing the header?
No connection with TRIM support. It is just that if the real
block size is larger than the block size you are using,
the SSD will rewrite/reloacte other data on writes smaller
that the real sector size.
What would need ot be done is to
1. Align LUKS header (partition start) to a real sector
boundary.
2. Align the start of the filesystem area in that
partition to a real sector boundary.
Both are only possible to do realiably when you know the
sector size. All of my 3 SSDs claim 512 byte sectors,
which is almost certainly a lie.
Incidentally, you get a similar problem with 4k sector
drives claiming to be 512B sector drives.
A not quiote certain approach to deal with this is to
align the partition start on a 1MB boundary and the
data area within the LUKS container as well.
All that said, catastrophic disk failure (from some reports
even more likely for SSDs than normal disks) is still the
main risk to data in LUKS containers, after user error.
Arno
--
Arno Wagner, Dr. sc. techn., Dipl. Inform., CISSP -- Email: arno@wagner.name
GnuPG: ID: 1E25338F FP: 0C30 5782 9D93 F785 E79C 0296 797F 6B50 1E25 338F
----
Cuddly UI's are the manifestation of wishful thinking. -- Dylan Evans
If it's in the news, don't worry about it. The very definition of
"news" is "something that hardly ever happens." -- Bruce Schneier
next prev parent reply other threads:[~2011-09-20 17:41 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-09-20 10:36 [dm-crypt] (More) Questions about LUKS / LVM Robbie Smith
2011-09-20 10:52 ` Quentin Lefebvre
2011-09-20 11:47 ` Arno Wagner
2011-09-20 13:13 ` Milan Broz
2011-09-20 14:14 ` Arno Wagner
2011-09-20 14:52 ` Milan Broz
2011-10-03 6:17 ` Luca Berra
2011-10-03 10:55 ` Arno Wagner
2011-09-20 15:21 ` Alexander Koch
2011-09-20 16:12 ` Milan Broz
2011-09-20 17:41 ` Arno Wagner [this message]
2011-09-20 18:06 ` Karl O. Pinc
2011-09-20 18:19 ` Milan Broz
2011-09-21 10:22 ` Arno Wagner
2011-09-21 16:14 ` Dragan Milivojevic
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=20110920174129.GA25723@tansi.org \
--to=arno@wagner.name \
--cc=dm-crypt@saout.de \
/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.