Today I switched to
my
new laptop. I've previously written about the problems I had with
my new Thinkpad X230, which was delivered with an
180
GB Intel SSD disk with Lenovo firmware that did not handle
sustained writes. My hardware supplier have been very forthcoming in
trying to find a solution, and after first trying with another
identical 180 GB disks they decided to send me a 256 GB Samsung SSD
disk instead to fix it once and for all. The Samsung disk survived
the installation of Debian with encrypted disks (filling the disk with
random data during installation killed the first two), and I thus
decided to trust it with my data. I have installed it as a Debian Edu
Wheezy roaming workstation hooked up with my Debian Edu Squeeze main
server at home using Kerberos and LDAP, and will use it as my work
station from now on.
As this is a solid state disk with no moving parts, I believe the
Debian Wheezy default installation need to be tuned a bit to increase
performance and increase life time of the disk. The Linux kernel and
user space applications do not yet adjust automatically to such
environment. To make it easier for my self, I created a draft Debian
package ssd-setup to handle this tuning. The
source
for the ssd-setup package is available from collab-maint, and it
is set up to adjust the setup of the machine by just installing the
package. If there is any non-SSD disk in the machine, the package
will refuse to install, as I did not try to write any logic to sort
file systems in SSD and non-SSD file systems.
I consider the package a draft, as I am a bit unsure how to best
set up Debian Wheezy with an SSD. It is adjusted to my use case,
where I set up the machine with one large encrypted partition (in
addition to /boot), put LVM on top of this and set up partitions on
top of this again. See the README file in the package source for the
references I used to pick the settings. At the moment these
parameters are tuned:
- Set up cryptsetup to pass TRIM commands to the physical disk
(adding discard to /etc/crypttab)
- Set up LVM to pass on TRIM commands to the underlying device (in
this case a cryptsetup partition) by changing issue_discards from
0 to 1 in /etc/lvm/lvm.conf.
- Set relatime as a file system option for ext3 and ext4 file
systems.
- Tell swap to use TRIM commands by adding 'discard' to
/etc/fstab.
- Change I/O scheduler from cfq to deadline using a udev rule.
- Run fstrim on every ext3 and ext4 file system every night (from
cron.daily).
- Adjust sysctl values vm.swappiness to 1 and vm.vfs_cache_pressure
to 50 to reduce the kernel eagerness to swap out processes.
During installation, I cancelled the part where the installer fill
the disk with random data, as this would kill the SSD performance for
little gain. My goal with the encrypted file system is to ensure
those stealing my laptop end up with a brick and not a working
computer. I have no hope in keeping the really resourceful people
from getting the data on the disk (see
XKCD #538 for an explanation why).
Thus I concluded that adding the discard option to crypttab is the
right thing to do.
I considered using the noop I/O scheduler, as several recommended
it for SSD, but others recommended deadline and a benchmark I found
indicated that deadline might be better for interactive use.
I also considered using the 'discard' file system option for ext3
and ext4, but read that it would give a performance hit ever time a
file is removed, and thought it best to that that slowdown once a day
instead of during my work.
My package do not set up tmpfs on /var/run, /var/lock and /tmp, as
this is already done by Debian Edu.
I have not yet started on the user space tuning. I expect
iceweasel need some tuning, and perhaps other applications too, but
have not yet had time to investigate those parts.
The package should work on Ubuntu too, but I have not yet tested it
there.
As for the answer to the question in the title of this blog post,
as far as I know, the only solution I know about is to replace the
disk. It might be possible to flash it with Intel firmware instead of
the Lenovo firmware. But I have not tried and did not want to do so
without approval from Lenovo as I wanted to keep the warranty on the
disk until a solution was found and they wanted the broken disks
back.
