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
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
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
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,
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
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
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:
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
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
On Jul 7, 2014, at 2:05 PM, Bob Proulx b...@proulx.com 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
KS wrote on 07/06/2014 17:29:
snip
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?
snip
If you are going with /tmp on tmpfs and are using a graphical desktop (X), I
recommend to set something like (sh
On Tue, 08 Jul 2014, Rick Thomas wrote:
On Jul 7, 2014, at 2:05 PM, Bob Proulx b...@proulx.com 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
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.
On Jul 8, 2014, at 6:50 AM, Henrique de Moraes Holschuh h...@debian.org wrote:
On Tue, 08 Jul 2014, Rick Thomas wrote:
On Jul 7, 2014, at 2:05 PM, Bob Proulx b...@proulx.com wrote:
Using today's Debian you do not normally need to bother with alignment
as all partitions will be automatically
On Tue, 08 Jul 2014, Rick Thomas wrote:
On Jul 8, 2014, at 6:50 AM, Henrique de Moraes Holschuh h...@debian.org
wrote:
On Tue, 08 Jul 2014, Rick Thomas wrote:
On Jul 7, 2014, at 2:05 PM, Bob Proulx b...@proulx.com wrote:
Using today's Debian you do not normally need to bother with
On 08/07/14 05:18 AM, Jörg-Volker Peetz wrote:
KS wrote on 07/06/2014 17:29:
snip
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?
snip
If you are going with /tmp on tmpfs and are using a graphical
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,
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
KS wrote:
I have done the following for optimization (ref:
https://wiki.debian.org/SSDOptimization?action=showredirect=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
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].
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.
The partition map is below:
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
sda 8:00 223.6G 0 disk
├─sda1
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
22 matches
Mail list logo