From: Milan Broz <mbroz@redhat.com>
To: Alexander Koch <mail@alexanderkoch.net>
Cc: dm-crypt@saout.de
Subject: Re: [dm-crypt] (More) Questions about LUKS / LVM
Date: Tue, 20 Sep 2011 18:12:30 +0200 [thread overview]
Message-ID: <4E78BB6E.20509@redhat.com> (raw)
In-Reply-To: <4E78AF92.9040309@alexanderkoch.net>
On 09/20/2011 05:21 PM, 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. TRIM can be enabled only for data area.
LUKS header is mapped separately from data area. I will never enable
TRIM when manipulating with LUKS metadata area of disk in cryptsetup.
(But you cannot say what is going inside of disk itself during keyslot write.)
> 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?
Not to sector, but to trimmed block size (256/512k usually).
It should be aligned this way. If someone misalign that by mistake,
maybe drive internally need to reallocate some pages but it should never
see TRIM command for this area from kernel.
Milan
next prev parent reply other threads:[~2011-09-20 16:12 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 [this message]
2011-09-20 17:41 ` Arno Wagner
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=4E78BB6E.20509@redhat.com \
--to=mbroz@redhat.com \
--cc=dm-crypt@saout.de \
--cc=mail@alexanderkoch.net \
/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.