OCz Vertex 2 probably has an eraseblock size of 512kiB, so 2048 sector (1MB) alignment works Same with Kingston SSDNow V-series

Pregap only needs 32 sectors; boot only needs about 16MB Make sure LUKS partition is aligned to 2048 sectors (1MB) on both sides! Leave about 40MB at the end. Might as well

Here's a layout for MBR:

p      start        end       size  type
p          0         31         32  0x00 # Pregap
1         32      34815      34784  0x83 # Boot
2      34816  107380735  107345920  0x44 # LUKS
3  107380736  107463887      83152  0x00 # SSD-padding

Here's a layout for GPT: Note the presence of EFIboot (32MB FAT32 /boot filesystem) and BIOSboot (where the GRUB2 stage1.5 code resides). Once again, make sure the LUKS partition is aligned to 2048 sectors (1MB) on both sides!

Ended up using Windows 7 installer to create the necessary GPT stuff; apparently the boot settings manager in the system configuration rom does not set it up correctly.

EFI system partition requires more than 16MB: windows defaults to 100MB, and 32MB barely holds grub + 1 kernel build.

----start  ------end  -----size  -----type  ----name
        0          0          1       pmbr      ----
        1         33         33        GPT      ----
       34      67583      67550        efi   EFIboot
    67584  107462655  107395072       LUKS      LUKS
107462656  107463854       1199       boot  BIOSboot
107463855  107463887         33        GPT      ----

OCZ Vertex 4 256GB
part     start        end       size  type        name        uuid
  p          0          1          1  PMBR
  g          1         33         32  GPT
  1        128     262143     262016  EF00  EFI System  C12A7328-F81F-11D2-BA4B-00A0C93EC93B
  2     262144  500117503  499855360  FFFF        LUKS  72636e45-7079-6574-6453-746f72616765
  3         34        127         94  EF02   BIOS boot  21686148-6449-6E6F-744E-656564454649
  4  500117504  500118158        655  FFFF      Unused  72636553-7465-654B-794F-664465617468
  g  500118159  500118191         33  GPT
# Create the encrypted store
# aes-xts-plain and aes-cbc-essiv:sha256 are equivalent, since they both mask the watermarking attacks present in aes-cbc-plain; aes-xts-essiv:sha256 is unnecessary.
# aes-xts-plain is good for up to 2^32 512-byte sectors, or 2 terabytes. Use aes-xts-plain64 for devices larger than 2TB.
cryptsetup luksFormat -v -s 512 -c aes-xts-plain64 -h sha512 --align-payload 2048 /dev/sda2
cryptsetup luksOpen /dev/sda2 mapajani

# Obfuscate all empty space on the backing store
badblocks -b1024 -c1024 -vvwt 0x00 /dev/mapper/mapajani # Or random or whatever; just need to write every sector of the raw dev

# Carve up the encrypted store using LVM
lvm pvcreate --verbose --metadatasize 1000k /dev/mapper/mapajani
lvm pvs -oname,vg_mda_size,pe_start --units s # Make sure 'pe_start' is a multiple of 2048 (1MB)
lvm vgcreate --verbose mapajani /dev/mapper/mapajani
lvm pvs -oname,vg_mda_size,pe_start --units s # Output changes; make sure 'pe_start' is a multiple of 2048 (1MB)
lvm lvcreate --verbose --extents 12079 --name root mapajani
lvm lvcreate --verbose --extents 1024 --name swap mapajani

# If using MBR:
mke2fs -vvt ext2 -L mapajani-boot /dev/sda1
# If using GPT:
mkdosfs -vvF32 -n mapajani-boot /dev/sda1

# Make root and swap:
mke2fs -vvt ext4 -E lazy_itable_init=1 -L mapajani-root /dev/mapper/mapajani-root
mkswap -f -L mapajani-swap /dev/mapper/mapajani-swap

When reconstituting an existing image, do something like this:

mkdir -p /media/dst
mount -t ext4 -orelatime /dev/mapper/mapajani-root /media/dst
# Copy critical stuff first
( cd /media/src/root; rsync --archive --hard-links --progress --sparse --stats --verbose +boot bin boot etc lib lib32 lib64 sbin /media/dst/ )
# Copy core stuff next
( cd /media/src/root; rsync --archive --hard-links --progress --sparse --stats --verbose dev root usr var /media/dst/ )
# Copy all the rest
( cd /media/src/root; rsync --archive --hard-links --progress --sparse --stats --verbose ./ /media/dst/ )

# Mount stuff to prepare for chroot
# For MBR:
mount -t ext2 -orelatime /dev/sda1 /media/dst/boot
# For GPT:
mount -t vfat -orelatime /dev/sda1 /media/dst/boot
# Prepare for chroot
mount -t devtmpfs devtmpfs /media/dst/dev
mount -t devpts devpts /media/dst/dev/pts
mount -t proc procfs /media/dst/proc
mount -t sysfs sysfs /media/dst/sysfs

# Chroot:
chroot /media/dst bash

# Install boot
rsync --archive --hard-links --progress --sparse --stats --verbose /+boot/ /boot/

# Install grub
grub-install /dev/sda

Make sure to update grub boot to include the new LUKS UUID so it can be autoloaded by initrd

Here are some timings for a brand new OCz Agility 3 SSD, which claims 525MB/sec read, 475MB/sec write via SATA3 on a Dell Latitude E6410 with a Core i7 M640 @ 2.80MHz running Gentoo Linux 3.0.6:

0x44: 170MB/sec read 12% CPU, 235MB/sec write 5% CPU
none: 250MB/sec read 5% CPU, 235MB/sec write 5% CPU

cryptsetup luksFormat -v -s 256 -c aes-cbc-essiv:sha256 -h sha1 --align-payload 2048 /dev/sdb
0x44: 115MB/sec read 41% CPU, 77MB/sec write 53% CPU
none: 170MB/sec read 55% CPU, 77MB/sec write 53% CPU

cryptsetup luksFormat -v -s 256 -c aes-xts-plain -h sha1 --align-payload 2048 /dev/sdb
0x44: 87MB/sec read 59% CPU, 77MB/sec write 54% CPU
none: 127MB/sec read 68% CPU, 77MB/sec write 53% CPU

cryptsetup luksFormat -v -s 256 -c aes-xts-essiv:sha256 -h sha1 --align-payload 2048 /dev/sdb
0x44: 84MB/sec read 60% CPU, 77MB/sec write 58% CPU
none: 106MB/sec read 70% CPU, 77MB/sec write 58% CPU