[EN] ssd alignment tools optimizing scheduler

[michaa7]

As I want my new SSD (samsung 840EVO 120 GB) to live as long as possible I read devils article (Thanks for writing it).
Then reading other, newer postings it seems the article is somewhat outdated. So here my questions:

alignment:
Is gparted able to do it right now or do I still need to make all those calculations by hand like described by devil?

optimizing:
that's part of the proposals from the article:

none /tmp tmpfs defaults,noatime,mode=1777 0 0
none /var/tmp tmpfs defaults,noatime 0 0
none /var/log tmpfs defaults,noatime 0 0
none /var/spool tmpfs defaults,noatime 0 0
none /run/shm tmpfs defaults,noatime 0 0

I am not sure I want live without logs, so would it be reasonable to keep /var on a spining disk (I have seperate /var since ever)? For /tmp and the rest (for which I don't know what they are for) I may imagine that I don't need them after reboot, so they may go to nirwana.


Outsource the browser cache to /run/shm:
the article's explanations are still right except for the directory, because I should use "/run/user/nnnn/<one-subfolder-per-browser> ?

scheduler:
How/where would I specify which scheduler to use? I wouldn have thought that a scheduler has much influence for the live time of a ssd, but reding dibl's statement

AFAIK, the deadline scheduler remains the most efficient choice for a SSD, for typical use cases.

I think I better ask what to do in this field?

[absolut]

with regard to SSD optimizations, there is a debian wiki:
https://wiki.debian.org/SSDOptimization

Since wheezy all tools should automatically align filesystems and partitions to the 4096 byte page size. This is one of the most important optimization aspects.

[melmarker]

michaa7:
i don't think turning off the logs is a good idea - and putting the logs to a spinnig drive too. as the ssd is built in to be used The noatime thing may be a good idea, eventually writing changes back every 30s may be a good idea, if one have a ups. Turn on trim is a good idea.

With normal use you wouldn't be able to destroy the ssd in 5 or 6 years. To do so you had to write approx 30G - 30G data on a daily base - which is impossible if the drive act as a system drive. - Nobody can assure you, that normal usage has anything to do with the life time of the drive. But the ssd will be totally outdated in two years, the warranty is 3 years - so what? Nobody uses this or similar models long term, so nobody will know.

Last: gpared take care of the alignment - so no vodoo needed anymore.

EDIT: The partitioning scheme in the debian wiki seems to be a good starting point - also i think its worth to think about thin provisioned LVM (not for / )

[michaa7]

Thanks to both of you.

...
Last: gpared take care of the alignment - so no vodoo needed anymore.

That's the most important info for the moment as this means I can start tomorrow (I am thinking about using this xorg.iso you mentioned once as I don't use/like the big DEs. Is there something not too outdated or do you expect to publish soon a rc for the next release?).

... i think its worth to think about thin provisioned LVM (not for / )

I don't understand.

re /home :
currently I have a seperate /home partition. I assume keeping it this way would slow down the start of programs. I would like to keep all my data on spinning disk and oly have the settings on ssd. But this would mean I have to link each and each new user directory from one to the other. Is there an other way?

night

[melmarker]

hm - mount bind could be the solution  - ok, same shit, but works great with a well defined structure

(und da hätte ich was im frühen Beta-Status, was Du testen könntest)

[michaa7]

...
(und da hätte ich was im frühen Beta-Status, was Du testen könntest)

If you have in mind a xorg_BETA.ISO, installing it, will I most likely have a working system or do you expect an error report from an user who's diplomatic skills don't flourish all the time ?

In other words, the absolute nonquestion: How long until the next release (and, BTW, I don't understand the release requirement that all flavours have to be release ready at one time, but that's an other question)?


EDIT:
OTOH, http://test.siduction.org/iso/paintitblack/lxqt/amd64_2014-08-01_21-44/ will be fine, too, is it worse than the one from may (I don't remember to ever having read about it's existence; I found it by browsing test.siduction.org, the existing xorg.iso from 2014.01. is too old, I guess)?

[melmarker]

not for the release yet - but a script that  can mount and mount bind things at login time via lightdm - and i really don't know if this is a good idea (the same functionality that microsoft and netware have years ago)

about the release strategy - releasing more often with not so big changes would be a good idea - but we need few things fixed until we reach that goal:
a) a more polished release process
b) some changes in pyfll
c) some changes in our building environment
d) more manpower to do the tests

d) is still a problem, but a-c are nearly addressed.

[michaa7]

...
about the release strategy - releasing more often with not so big changes would be a good idea ...

That's not what I am refering to.

I mean, lxqt is ready $now (but not KDE/gnome, whatever), push it out, xorg.iso is usuabel $now, push it out *without* the other flavours, KDE is ready $now, but none of the other flavours, push out KDE $now ... I think you got the idea. A DE-ISO is ready when *it* is ready, not when others are.

I am now going to install using http://test.siduction.org/iso/paintitblack/lxqt/amd64_2014-08-01_21-44/ except you are telling me this version is somehow worse than the one published in May.



Thanks.

[dibl]

Turn on trim is a good idea.

In the time since that article was written, the guidance on this point has changed.  It is better not to use realtime trim with the "discard" mount option, but rather run fstrim periodically -- a cron job can do that for you.

[melmarker]

@dibl: thanks for the link - really cool. To be true, the discard in the fstab sucks a lot, if one have to delete "small" things like kernel sources and so on.

@micha - and lxqt isn't ready, it is still not even in a pre-release state but has evolved a lot. At this time lxqt is nothing what is near unstable. Sorry. But this is true for all our isos. At least we will release a cinnamon-dev.

[michaa7]

@dibl: thanks for the link - really cool. To be true, the discard in the fstab sucks a lot, if one have to delete "small" things like kernel sources and so on.

Thanks dibl

@micha - and lxqt isn't ready, ...

Now that I've d/l_ed it, the one from August ...

BTW, lxqt from May works fine (ISO booted from USB-stick), so what's the problem? Or which is the most recent ISO you recommend for install (with a gparted version which does alignment right)?

[melmarker]

the lxqt problem is a littel bit difficult - there should be a release ( 0.8 ) a month ago, so we started packaging lxqt for debian. Right now there is no release and imho lxqt will not reach this stable. For us that means, that we are stucked too, because i will not release a unstable lxqt with packages that are not even RC1 - but it is usable right now, i think i will make a overhaul to the most recent git checkout this weekend.

[dibl]

After I posted above, I noticed that he updated his blog on 14 AUG with a nice cron script that will automatically detect filesystems that support trim, and run fstrim for you.  Very handy on a rig like my desktop with 2 hard drives and 2 SSDs.

[melmarker]

@dibl: i think we should integrate this into siduction - make sense. (Fortunally i'm not in charge to change manual, wiki and so on)

[dibl]

@dibl: i think we should integrate this into siduction - make sense.

I agree -- I will be happy to help in any way I can.   




EDIT:  I could update that 2012 article with all applicable changes and give it to devil again, if that sounds useful.