Hi,

SSD requires filesystems (ext{3,4}, swap,...) to be mounted with the
"discard" option to send TRIM command to the underlying drive.

It should be possible to add this option to the fstab during install.

Cheers

Laurent Bigonville

Em 19-10-2012 19:51, Laurent Bigonville escreveu:

[...]

https://lists.debian.org/debian-boot/2012/03/msg00184.html

Miguel Figueiredo <elmig@debianpt.org> (20/10/2012):
 - some experimenter had frequent lockups with this option enabled;
 - documentation seems to say it's experimental;
 - it probably should be auto-detected/auto-enabled when appropriate.

I don't think we're going to add this even as an option for wheezy,
sorry.

Mraw,
KiBi.

Hi.  Instead of adding discard as a mount option in fstab, perhaps it
is better to add a cron job calling fstrim regularly?

In
<URL: http://people.skolelinux.org/pere/blog/How_to_fix_a_Thinkpad_X230_with_a_broken_180_GB_SSD_disk.html >
I described a deb ssd-setup I created to set up a machine with SSD,
and it take care of all the setup I believe make sense.  The source is
available from collab-maint.  To quote from the blog post:

  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.

Perhaps a similar approach is good for Debian proper too?  Ie instead
of changing d-i all over the place, add a deb to set up ssd parameters
and install it automatically if a disk with
/sys/block/*/queue/rotational is set to zero (0).

Hey all,

Petter Reinholdtsen [2013-08-12 13:04 +0200]:

Colin King did some rather extensive benchmarks, and we found that on
desktops/servers this is indeed the preferrable default.
https://blueprints.launchpad.net/ubuntu/+spec/core-1311-ssd-trimming
(I also have the detailled spreadsheets and percentage numbers if
anyone is interested)

That's "allow-discards" for the record. It's off by default as the
cryptsetup authors consider it a potential information leak. I. e. on
the physical drive you can map the "used/free" blocks and from their
patterns infer the file system type and from their ratio infer how
full the file system is. IMHO that's a very small price to pay for
keeping your SSD usable in the first place (and yes, I consider
reducing write performance from 250 MB/s to 5 MBs/ "useless", each
bigger I/O operation completely hangs the computer). If you are
worried about that kind of data leak, you would use a
hardware-encrypted hard drive anyway, and no cryptsetup.

That's orthogonal to discard/fstrim, but should be done anyway. That's
http://bugs.debian.org/717313 .

Agreed (good installer default on rotational drives, too!)

I just filed http://bugs.debian.org/732054 with a proposed cron job,
review/comments appreciated!

Thanks,

Martin

[Martin Pitt]

If that is the case, the crypttab(5) manual page is wrong in the
cryptsetup version 2:1.4.3-4 package.

<URL: http://bugs.debian.org/648868 > agree with you, while
<URL: http://wilmer.gaa.st/blog/archives/72-Debian,-dmcrypt-and-SSD-TRIMming.html >
agree with the manual page.  Not quite sure who to believe. :)

Petter Reinholdtsen [2013-12-13 13:45 +0100]:

Ah, I only tried with a non-system partition with "cryptsetup
luksOpen", where it is indeed --allow-discards. (I don't use crypttab
myself). I found "allow-discards" in
http://blog.christophersmart.com/2013/06/05/trim-on-lvm-on-luks-on-ssd/
but I guess I'd rather trust the manpage. Easy enough for someone to
try out who actually uses crypttab :-)

Thanks for pointing out!

Martin

[Martin Pitt]

I checked the scripts in the package using "less $(grep -l discard
$(dpkg -L cryptsetup) )", and it is definitely "discards", not
"allow-discards" in /etc/crypttab for Wheezy.