Re: SSD optimization on Debian (2014)

[Henrique de Moraes Holschuh]

On Thu, 10 Jul 2014, Jochen Spieker wrote:
> Henrique de Moraes Holschuh:
> > On Wed, 09 Jul 2014, Jochen Spieker wrote:
> >>>   * The "discard" options is not needed if your SSD has enough
> >>> overprovisioning (spare space) or you leave (unpartitioned) free
> >>> space on the SSD.
> >>> See http://www.spinics.net/lists/raid/msg40866.html
> >> 
> >> AFAIU, this discussion only relates to "online trim" (using the
> >> "discard" mount option). Running an occasional fstrim on your
> >> filesystems is almost free and, apart from RAID issues, I don't see any
> >> negative consequences. Am I missing something?
> > 
> > Yes.  Broken TRIM implementations, and with a recent kernel, broken QUEUED
> > TRIM implementations.
> 
> Are you referring to this?
> 
> http://forum.crucial.com/t5/Solid-State-Drives-SSD/M500-M5x0-QUEUED-TRIM-data-corruption-alert-mostly-for-Linux/td-p/151028

Yes.  But if you're a Crucial/Micron M500/M550 user, it is better to pay
attention to:
https://bugzilla.kernel.org/show_bug.cgi?id=71371

This sort of problem is nothing new.  Back when the non-queued version of
TRIM was introduced, people lost data as well to bad firmware.

Crucial/Micron is not the only ones which will get it wrong.  That reminds
me that we need a way to disable queued-trim without disabling NCQ entirely
in Linux, currently you have to patch the kernel to do that.

> I am a little surprised that I didn't read about that earlier. But then
> I don't have any Crucial SSDs.

And I escaped it only because I am sticking to 3.10.x. :-)

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140710154421.ga31...@khazad-dum.debian.net

Re: SSD optimization on Debian (2014)

[Jochen Spieker]

Henrique de Moraes Holschuh:
> On Wed, 09 Jul 2014, Jochen Spieker wrote:
>>>   * The "discard" options is not needed if your SSD has enough
>>> overprovisioning (spare space) or you leave (unpartitioned) free
>>> space on the SSD.
>>> See http://www.spinics.net/lists/raid/msg40866.html
>> 
>> AFAIU, this discussion only relates to "online trim" (using the
>> "discard" mount option). Running an occasional fstrim on your
>> filesystems is almost free and, apart from RAID issues, I don't see any
>> negative consequences. Am I missing something?
> 
> Yes.  Broken TRIM implementations, and with a recent kernel, broken QUEUED
> TRIM implementations.

Are you referring to this?

http://forum.crucial.com/t5/Solid-State-Drives-SSD/M500-M5x0-QUEUED-TRIM-data-corruption-alert-mostly-for-Linux/td-p/151028

I am a little surprised that I didn't read about that earlier. But then
I don't have any Crucial SSDs.

J.
-- 
I often blame my shortcomings on my upbringing.
[Agree]   [Disagree]
 


signature.asc
Description: Digital signature

Re: SSD optimization on Debian (2014)

[Jochen Spieker]

Bob Proulx:
> Jochen Spieker wrote:
> 
>> If you use TRIM (either using the discard mount option or using fstrim
>> regularly), your usable spare area is manufacturer spare area plus free
>> space on your filesystem. If you don't use TRIM (and don't keep
>> unpartitioned space), your spare area is only as large as what the
>> manufacturer intended it to be.
> 
> Agreed.  But it adds complexity.  It has to work bug free.  And
> performance is still quite good without it.

I was about to write a lengthy reply until I finally realized that we
don't have much to argue about. :)

J.
-- 
Americans have a better life.
[Agree]   [Disagree]
 


signature.asc
Description: Digital signature

Re: SSD optimization on Debian (2014)

[Bob Proulx]

KS wrote:
> I have read some stuff on pros and cons for /tmp on tmpfs. One case case
> be a powerloss (just a desktop without UPS) or kernel panic and I loose
> files that I might have on /tmp temporarily.

Isn't the default to purge /tmp on reboot normally anyway?

  man rcS

   TMPTIME
  On boot the files in /tmp will be deleted if their  modification
  time,  file status time and access time are all at least TMPTIME
  days ago.  A value of 0 means that files are removed  regardless
  of  age.   If  you  don't want the system to clean /tmp then set
  TMPTIME to a negative value (e.g., -1) or to the word infinite.

And I believe the default is 0.  I am not setting it and my /tmp is
always purged on reboot.  If you want more persistent storage then
saving the file in /var/tmp is better.  The contents there are
preserved across a reboot.

Since /tmp is purged on a reboot that isn't a negative for it being a
tmpfs which being in ram is also purged on reboot.

The usual problem with /tmp being a tmpfs is file system size.  When
it is real storage on disk you can do video editing of large files
there within the size of the file system.  But a tmpfs is usually much
smaller and not large enough for that.  The size problem was often
discussed here a year or so ago when tmpfs became popular for /tmp.

> Rather /var might be of more concern as stuff gets written to logs
> constantly and more frequently than /tmp (I suppose).

But maybe I am not understanding what you are suggesting.

Bob


signature.asc
Description: Digital signature

Re: SSD optimization on Debian (2014)

[Bob Proulx]

Jochen Spieker wrote:
> Bob Proulx:
> > The referenced thread has much good information concerning trim (aka
> > the discard option) and I recommend reading through the entire thread.
> > You are fine with trim enabled.  In some cases using trim may help.
> > In some cases using trim may hurt.  I haven't enabled it on my main
> > laptop.  I am using a high quality SSD that has a signfican't amount
> > of internal over-provisioning.
> 
> What's "significant"?

I would say the Intel 320 series is significant.  I happen to know a
few of the folks that that worked on it and they were rather proud of
that drive when it released.  Those are the ones with the non-power of
two sizes such as 120G, 240G, 600G and so forth.  Of course memory is
actually in a binary power of two.  Plus there is additional space
too.  All of the extra space not advertised to the consumer is
available as over-provisioning.  I have one of the 600G drives and it
has been a great performer for me.  And so that is what I mean when I
say a high quality drive.  It was so much faster than the spinning
hard drive that I replaced that I simply stopped there.

> Wait a minute … yes, that's the article I am thinking of:
> http://www.anandtech.com/show/6489/playing-with-op

The Intel S3700 you referenced in the Anandtech review has 264G of
capacity internally but only advertises 186G of it to the consumer.
The remaining 78G is internally available for over-provisioning.  I
would say that is quite significant.  It looks like it was the
reference system in the benchmarks above.

It does look like the cheaper OCZ and Samsung drives benefited from
the free space.  I guess that knocks them down out of the high quality
drive and into the mid quality section.  (shrug)

> If you use TRIM (either using the discard mount option or using fstrim
> regularly), your usable spare area is manufacturer spare area plus free
> space on your filesystem. If you don't use TRIM (and don't keep
> unpartitioned space), your spare area is only as large as what the
> manufacturer intended it to be.

Agreed.  But it adds complexity.  It has to work bug free.  And
performance is still quite good without it.

Bob


signature.asc
Description: Digital signature

Re: SSD optimization on Debian (2014)

[Jochen Spieker]

Jörg-Volker Peetz:
> 
> The first call of fstrim after a reboot indeed normally seems to discard all
> free space of a filesystem.

It should discard all blocks that were not previously discarded. From
the manpage:

| fstrim will report the same potential discard bytes each  time,
| but only sectors which had been written to between the discards
| would actually be discarded by the  storage  device.   Further,
| the kernel block layer reserves the right to adjust the discard
| ranges to fit raid stripe geometry, non-trim capable devices in
| a  LVM  setup, etc.  These reductions would not be reflected in
| fstrim_range.len (the --length option).

AFAICT, fstrim actually currently reports the number of bytes that were
really discarded and not like the manpage suggests the number of
theoretically discarded blocks. At least it reports zero bytes for
consecutive runs.

What the manpage doesn't explain is how fstrim knows which blocks were
previously discarded. Maybe this information gets lost during a reboot
although I would assume that it is stored in the filesystem. I just
cannot be bothered to reboot now to test this.

J.
-- 
When I am doing sex I wonder if my emotions can be detected by alien
civilisations.
[Agree]   [Disagree]
 


signature.asc
Description: Digital signature

Re: SSD optimization on Debian (2014)

[Henrique de Moraes Holschuh]

On Wed, 09 Jul 2014, Jochen Spieker wrote:
> >   * The "discard" options is not needed if your SSD has enough
> > overprovisioning (spare space) or you leave (unpartitioned) free
> > space on the SSD.
> > See http://www.spinics.net/lists/raid/msg40866.html
> 
> AFAIU, this discussion only relates to "online trim" (using the
> "discard" mount option). Running an occasional fstrim on your
> filesystems is almost free and, apart from RAID issues, I don't see any
> negative consequences. Am I missing something?

Yes.  Broken TRIM implementations, and with a recent kernel, broken QUEUED
TRIM implementations.

In both cases, you get filesystem corruption and data loss.

> What's "significant"? I remember seeing graphs on anandtech.com about

It depends on the load.  It needs overprovisioning for:

1. write performance  (large-block writes)
2. garbage collection (defrag erase blocks)
3. spare flash for sector remapping
4. error correction information

Both (1) and (2) are heavily dependent on what you're doing to the SSD, how
fast you're doing it (i.e. whether it has time to do some garbage collection
or not), and how good the SSD firmware is.

As you wrote, one can "extra overprovision" any non-crap SSD by leaving
untouched space (typically by never partitioning some of the SSD in the
first place).

Also, the less spare space a SSD has available, the more aggressively it
will have to garbage collect.

> If you use TRIM (either using the discard mount option or using fstrim
> regularly), your usable spare area is manufacturer spare area plus free
> space on your filesystem. If you don't use TRIM (and don't keep
> unpartitioned space), your spare area is only as large as what the
> manufacturer intended it to be.

Correct.

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/2014071249.ga28...@khazad-dum.debian.net

Re: SSD optimization on Debian (2014)

[Jörg-Volker Peetz]

The first call of fstrim after a reboot indeed normally seems to discard all
free space of a filesystem.
-- 
Regards,
jvp.



-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/lpjm4p$jrh$1...@ger.gmane.org

Re: SSD optimization on Debian (2014)

[Jochen Spieker]

Bob Proulx:
> 
> The wiki does say this:
> 
>   * The "discard" options is not needed if your SSD has enough
> overprovisioning (spare space) or you leave (unpartitioned) free
> space on the SSD.
> See http://www.spinics.net/lists/raid/msg40866.html

AFAIU, this discussion only relates to "online trim" (using the
"discard" mount option). Running an occasional fstrim on your
filesystems is almost free and, apart from RAID issues, I don't see any
negative consequences. Am I missing something?

> The referenced thread has much good information concerning trim (aka
> the discard option) and I recommend reading through the entire thread.
> You are fine with trim enabled.  In some cases using trim may help.
> In some cases using trim may hurt.  I haven't enabled it on my main
> laptop.  I am using a high quality SSD that has a signfican't amount
> of internal over-provisioning.

What's "significant"? I remember seeing graphs on anandtech.com about
drive performance with respect to the amount of unused space on SSDs. I
think the result was that you see significant perfromance gains when you
set aside 10-20% of space *in addition to the manufacturer's spare
area*.

Wait a minute … yes, that's the article I am thinking of:

http://www.anandtech.com/show/6489/playing-with-op

Note the logarithmic scale. Obviously, the results are highly
hardware-dependent, but I don't think things have changed very much
since Q4 2012.

If you use TRIM (either using the discard mount option or using fstrim
regularly), your usable spare area is manufacturer spare area plus free
space on your filesystem. If you don't use TRIM (and don't keep
unpartitioned space), your spare area is only as large as what the
manufacturer intended it to be.

J.
-- 
If I was a supermodel I would give all my cocaine to the socially
excluded.
[Agree]   [Disagree]
 


signature.asc
Description: Digital signature

Re: SSD optimization on Debian (2014)

[KS]

On 08/07/14 09:43 PM, KS wrote:
> On 08/07/14 09:37 PM, KS wrote:
>>
>> Over the last couple of days I have tried to run the trim command a few
>> times and it seems to trim lots of bytes. 1) is that normal? 2) does
>> that matter if I forget it, and 3) is it better to run a cron
>> daily/hourly to do that for me *if needed*?
>>

Actually, Bob's original link
http://www.spinics.net/lists/raid/msg40866.html does shed more light on
the TRIM feature. After reading it, I think I can safely ignore it
unless a partition becomes too full. Plus the OS will eventually ask the
file system to overwrite the blocks/portions when needed.

KS


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/53bca7c9.5050...@fastmail.fm

Re: SSD optimization on Debian (2014)

[KS]

On 08/07/14 09:37 PM, KS wrote:
> 
> Over the last couple of days I have tried to run the trim command a few
> times and it seems to trim lots of bytes. 1) is that normal? 2) does
> that matter if I forget it, and 3) is it better to run a cron
> daily/hourly to do that for me *if needed*?
> 
Oops, forgot the gave example:
first two commands were run first time yesterday, other two were first
after about 6hrs (first thing in morning)

$> time sudo fstrim -v /var
/var: 4278566912 bytes were trimmed

real0m51.600s
user0m0.004s
sys 0m0.304s
$> time sudo fstrim -v /home
/home: 49507049472 bytes were trimmed

real0m31.243s
user0m0.000s
sys 0m0.168s
$> time sudo fstrim -v /home
[sudo] password for k2:
/home: 0 bytes were trimmed

real0m6.047s
user0m0.028s
sys 0m0.000s
$> time sudo fstrim -v /var
/var: 0 bytes were trimmed

real0m0.010s
user0m0.004s
sys 0m0.000s



-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/53bc9e29.8090...@fastmail.fm

Re: SSD optimization on Debian (2014)

[KS]

On 08/07/14 05:18 AM, Jörg-Volker Peetz wrote:
> KS wrote on 07/06/2014 17:29:
> 
>> What I want to know at this point is:
>> Is there anything else that is recommended?
>> The section on RAMDISK options on tmpfs, does that help?
> 
> 
> If you are going with /tmp on tmpfs and are using a graphical desktop (X), I
> recommend to set something like (sh syntax)
> 
> export XDG_CACHE_HOME=/tmp/.cache-$USER
> 

I have read some stuff on pros and cons for /tmp on tmpfs. One case case
be a powerloss (just a desktop without UPS) or kernel panic and I loose
files that I might have on /tmp temporarily. Rather /var might be of
more concern as stuff gets written to logs constantly and more
frequently than /tmp (I suppose).

Over the last couple of days I have tried to run the trim command a few
times and it seems to trim lots of bytes. 1) is that normal? 2) does
that matter if I forget it, and 3) is it better to run a cron
daily/hourly to do that for me *if needed*?

Thanks to all. The thread kind of confirmed my suspicions that the
articles were too old and the SSD tech has improved over the last few years.

KS


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/53bc9cd4.20...@fastmail.fm

Re: SSD optimization on Debian (2014)

[Henrique de Moraes Holschuh]

On Tue, 08 Jul 2014, Rick Thomas wrote:
> On Jul 8, 2014, at 6:50 AM, Henrique de Moraes Holschuh 
> wrote:
> > On Tue, 08 Jul 2014, Rick Thomas wrote:
> >> On Jul 7, 2014, at 2:05 PM, Bob Proulx  wrote:
>  Using today's Debian you do not normally need to bother with
>  alignment as all partitions will be automatically aligned at 1 MiB
>  boundaries by most of the tools anyway.
> >>> 
> >>> Agreed.  No need to worry about it with a default Wheezy or later
> >>> installation.  All handled automatically.
> >> 
> >> This is true for i386 and amd64, but for (at least) powerpc (I don’t
> >> know about mips, arm* etc) the megabyte boundary alignment fixes
> >> haven’t found it into the installer’s partition modules yet.
> > 
> > And this one has been known for a while, hasn't it?   I couldn't find a
> > bug about it in the BTS, though.
> 
> I investigated this a while back (early May?) but couldn’t figure out what
> package to write the bug against.  Do you have a suggestion?  If so, I’ll
> write it up.

Try package debian-installer.  If there's a component package involved, it
can be reassigned.

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140708210657.ga31...@khazad-dum.debian.net

Re: SSD optimization on Debian (2014)

[Rick Thomas]

On Jul 8, 2014, at 6:50 AM, Henrique de Moraes Holschuh  wrote:

> On Tue, 08 Jul 2014, Rick Thomas wrote:
>> On Jul 7, 2014, at 2:05 PM, Bob Proulx  wrote:
 Using today's Debian you do not normally need to bother with alignment
 as all partitions will be automatically aligned at 1 MiB boundaries by
 most of the tools anyway.
>>> 
>>> Agreed.  No need to worry about it with a default Wheezy or later
>>> installation.  All handled automatically.
>> 
>> This is true for i386 and amd64, but for (at least) powerpc (I don’t know
>> about mips, arm* etc) the megabyte boundary alignment fixes haven’t found
>> it into the installer’s partition modules yet.
> 
> And this one has been known for a while, hasn't it?   I couldn't find a bug
> about it in the BTS, though.

I investigated this a while back (early May?) but couldn’t figure out what 
package to write the bug against.  Do you have a suggestion?  If so, I’ll write 
it up.

Rick



--
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/8662d9ae-7618-4ee4-8d1f-12bf235af...@pobox.com

Re: SSD optimization on Debian (2014)

[Bob Proulx]

Rick Thomas wrote:
> Bob Proulx wrote:
> >> Using today's Debian you do not normally need to bother with alignment
> >> as all partitions will be automatically aligned at 1 MiB boundaries by
> >> most of the tools anyway.
> > 
> > Agreed.  No need to worry about it with a default Wheezy or later
> > installation.  All handled automatically.
> 
> This is true for i386 and amd64, but for (at least) powerpc (I don’t
> know about mips, arm* etc) the megabyte boundary alignment fixes
> haven’t found it into the installer’s partition modules yet.
> 
> For PowerPC. you *do* have to be careful and partition manually if
> you are using SSD or “advanced format” hard disks.

Ah...  I had not known about the bug on PowerPC.  Good to know.

Thanks!
Bob


signature.asc
Description: Digital signature

Re: SSD optimization on Debian (2014)

[Henrique de Moraes Holschuh]

On Tue, 08 Jul 2014, Rick Thomas wrote:
> On Jul 7, 2014, at 2:05 PM, Bob Proulx  wrote:
> >> Using today's Debian you do not normally need to bother with alignment
> >> as all partitions will be automatically aligned at 1 MiB boundaries by
> >> most of the tools anyway.
> > 
> > Agreed.  No need to worry about it with a default Wheezy or later
> > installation.  All handled automatically.
> 
> This is true for i386 and amd64, but for (at least) powerpc (I don’t know
> about mips, arm* etc) the megabyte boundary alignment fixes haven’t found
> it into the installer’s partition modules yet.

And this one has been known for a while, hasn't it?   I couldn't find a bug
about it in the BTS, though.

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140708135011.gb13...@khazad-dum.debian.net

Re: SSD optimization on Debian (2014)

[Jörg-Volker Peetz]

KS wrote on 07/06/2014 17:29:

> What I want to know at this point is:
> Is there anything else that is recommended?
> The section on RAMDISK options on tmpfs, does that help?


If you are going with /tmp on tmpfs and are using a graphical desktop (X), I
recommend to set something like (sh syntax)

export XDG_CACHE_HOME=/tmp/.cache-$USER

-- 
Regards,
jvp



-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/lpgd1j$h1a$1...@ger.gmane.org

Re: SSD optimization on Debian (2014)

[Rick Thomas]

On Jul 7, 2014, at 2:05 PM, Bob Proulx  wrote:

>> Using today's Debian you do not normally need to bother with alignment
>> as all partitions will be automatically aligned at 1 MiB boundaries by
>> most of the tools anyway.
> 
> Agreed.  No need to worry about it with a default Wheezy or later
> installation.  All handled automatically.

This is true for i386 and amd64, but for (at least) powerpc (I don’t know about 
mips, arm* etc) the megabyte boundary alignment fixes haven’t found it into the 
installer’s partition modules yet.

For PowerPC. you *do* have to be careful and partition manually if you are 
using SSD or “advanced format” hard disks.

Rick 

--
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/5813b712-5e4e-4dc7-8f03-a5aa93a66...@pobox.com

Re: SSD optimization on Debian (2014)

[Jochen Spieker]

Bob Proulx:
>
> I am using a high quality SSD that has a signfican't amount
   ^^^
> of internal over-provisioning.

That's the funniest typo I have seen in a long time! :)

J.
-- 
I can tell a Whopper[tm] from a BigMac[tm] and Coke[tm] from Pepsi[tm].
[Agree]   [Disagree]
 


signature.asc
Description: Digital signature

Re: SSD optimization on Debian (2014)

[Bob Proulx]

KS wrote:
> I have done the following for optimization (ref:
> https://wiki.debian.org/SSDOptimization?action=show&redirect=SSDoptimization):

I wanted to say that I think that page needs an update for Wheezy.  At
one time there were many things needed for SSDs.  The biggest being
alignment to 4k Advanced Format partitions.  But if installing Wheezy
Stable then I think the entirety of that page can be ignored.

> 1) Kernel: Linux localhost 3.14-1-amd64 #1 SMP Debian 3.14.9-1
> (2014-06-30) x86_64 GNU/Linux

Good to go.  But so is the default 3.2 Wheezy kernel too.  Either is
fine.  My main laptop is still running the 2.6.32 Squeeze kernel on an
SSD.

> 2) Updated the firmware for the Intel 530  240GB disk

Sure.

> 3) I have not gone into partition alignment for two reasons: 1) the
> article on debian wiki refers to is from a long time ago, 2) blockdev
> doesn't indicate misalignment (see below):
> $> sudo blockdev --getalignoff /dev/sda1
> 0
> $> sudo blockdev --getalignoff /dev/sda2
> 0
> $> sudo blockdev --getalignoff /dev/sda5
> 0

If you installed Wheezy then the default installer would do the Right
Thing with respect to partitions by default.  There isn't a need to do
anything.  (Now if you were to go back and try to install Woody or
Sarge or Lenny or ... that would not be true.  But Wheezy is fine.)

> 4) For mounting file systems, I have added discard in /etc/fstab and
> also enabled issue_discards in lvm.conf

Sure.  I personally have not gone to this trouble.

The wiki does say this:

  * The "discard" options is not needed if your SSD has enough
overprovisioning (spare space) or you leave (unpartitioned) free
space on the SSD.
See http://www.spinics.net/lists/raid/msg40866.html

The referenced thread has much good information concerning trim (aka
the discard option) and I recommend reading through the entire thread.
You are fine with trim enabled.  In some cases using trim may help.
In some cases using trim may hurt.  I haven't enabled it on my main
laptop.  I am using a high quality SSD that has a signfican't amount
of internal over-provisioning.

> 6) Added vm.swappiness as kernel option in /etc/sysctl.d/local.conf

There is a lot of FUD concerning swappiness.  I wish there were more
objective data to remove the emotional decision making concerning it.
But the best tuning is different depending upon the workload.
Therefore there isn't any one single canonical correct answer.  But I
think most people use the wrong one.  For my laptop I never have
enough ram and therefore I like more swappiness.

The best tuned answer for you depends upon how much ram you have
available.  I think this article describes it fairly well.

  
http://www.linuxvox.com/2009/10/what-is-the-linux-kernel-parameter-vm-swappiness/

Linux-Fan wrote:
> KS wrote:
> > What I want to know at this point is:
> > Is there anything else that is recommended?
> 
> Nothing that I am aware of.

I agree with Linux-Fan's response.  I don't know of anything more that
is needed.  And actually you didn't need to do as much as you have
done.

> > The section on RAMDISK options on tmpfs, does that help?
> 
> As long as your /tmp does not normally exceed your RAM size it might be
> a good idea. Still, it is not really SSD specific: It will of course
> save a few writes, but as long as /tmp is always smaller than your RAM,
> there are obviously not that many writes anyway.

The choice of tmpfs for /tmp or not is somewhat contentious since it
depends upon your use model.  It isn't good for very large (many gigs
exceeding ram size) scratch work areas.  But it is nice for random
small systems.  It is really a personal choice.

As to tuning it specifically for an SSD I wouldn't bother.  I don't
see a need to hold off commits to an SSD for 10 minutes for example.
There isn't any disk to consume power spinning up.  I think that is
really more appropriate for a spinning hard drive than for an SSD.  I
would rather let the file system buffer cache handle that layer.

As with all things actual benchmarks would be best.  But unfortunately
those are few and far between.

> > Lastly, the partition alignment discussion on
> > http://tytso.livejournal.com/2009/02/20/ is from 2009 - is it relevant
> > today?
> 
> Using today's Debian you do not normally need to bother with alignment
> as all partitions will be automatically aligned at 1 MiB boundaries by
> most of the tools anyway.

Agreed.  No need to worry about it with a default Wheezy or later
installation.  All handled automatically.

> > Are any of the above "modifications" really necessary?
> 
> None of the modifications is "necessary". You can simply replace a HDD
> with a SSD without having to worry much. Still, a ramdisk for /tmp could
> be useful (also in HDD environments).

Agreed.  With the current Wheezy Stable or later there isn't really
any need to do anything special.

Bob


signature.asc
Description: Digital signature

Re: SSD optimization on Debian (2014)

[Linux-Fan]

On 07/06/2014 05:29 PM, KS wrote:
> Hi all,
> 
> I wanted to upgrade my system to amd64 and used that opportunity to
> install 2 240GB (1GB = 1000MB etc. unfortunately) SSDs on my rig.

[...]

> What I want to know at this point is:
> Is there anything else that is recommended?

Nothing that I am aware of.

> The section on RAMDISK options on tmpfs, does that help?

As long as your /tmp does not normally exceed your RAM size it might be
a good idea. Still, it is not really SSD specific: It will of course
save a few writes, but as long as /tmp is always smaller than your RAM,
there are obviously not that many writes anyway.

> Lastly, the partition alignment discussion on
> http://tytso.livejournal.com/2009/02/20/ is from 2009 - is it relevant
> today?

Using today's Debian you do not normally need to bother with alignment
as all partitions will be automatically aligned at 1 MiB boundaries by
most of the tools anyway.

> Are any of the above "modifications" really necessary?

None of the modifications is "necessary". You can simply replace a HDD
with a SSD without having to worry much. Still, a ramdisk for /tmp could
be useful (also in HDD environments).

HTH
Linux-Fan




signature.asc
Description: OpenPGP digital signature