[dm-crypt] (More) Questions about LUKS / LVM
arno at wagner.name
Tue Sep 20 19:41:29 CEST 2011
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
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 Wagner, Dr. sc. techn., Dipl. Inform., CISSP -- Email: arno at 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
More information about the dm-crypt