opensubscriber
   Find in this group all groups
 
Unknown more information…

f : freebsd-hackers@freebsd.org 26 May 2012 • 6:58AM -0400

Re: proper newfs options for SSD disk
by Peter Jeremy

REPLY TO AUTHOR
 
REPLY TO GROUP




On 2012-May-25 22:46:10 +0200, Wojciech Puchar <wojtek@wojt...> wrote:
>> Should I split /dev/ada1 into two separate partitions, one for real
>> /usr/local and one for my HOME and only crypt this with geli(8)?
>
>i would make / on 16GB SSD (including /usr, /usr/local, don't divide
>to partitions) and geli encrypted home on 4GB SSD (whole device). if
>sometimes 4GB would be too little for /home then you would manually move
>things that don't need encryption somewhere else.

This may be a worthwhile suggestion.

>Why? Your laptop have most probably slow CPU and it will make everything
>too slow if you make everything encrypted.

I'd suggest some experiments - create a largish RAMdisk with and without
GELI and see how the performance compares (this will be a lot faster than
converting your SSD as well as saving a full-SSD erase/write cycle).

As for the overall SSD write rate, some time ago, I worked through
minimising the write activity on the SSD in my laptop (I wrote a tool
that monitors write transfers via devstat(3) and it would be possible
to track down the actual modified files via kqueue(2) if necessary).
I'm now down to about two chunks of about 13 transfers each per hour
(due to entopy saving and ntp.drift updating).  The changes were:
1) Mount the SSD filesystems as noatime
2) Turn off all local syslogging (syslog is directed to another
   system when my laptop is at home, lost otherwise).
3) Change maillog rotation to size instead of daily
4) Run save-entropy once per hour instead of roughly every 11 minutes.
   [Note that */11 means 0,11,22,33,44,55 not every 11 minute]
5) Patch the save-entropy script to reduce the write load when
   it's run (see PR bin/134225).
6) Use a swap-back /tmp

As for applications - firefox generates quite a heavy write load
during normal use.  Moving the cache to /tmp will help but I don't
think there's any complete solution.

Also, you're probably better off running a traditional lightweight
window manager than something like KDE or Gnome.

--
Peter Jeremy

Bookmark with:

Delicious   Digg   reddit   Facebook   StumbleUpon

Related Messages

opensubscriber is not affiliated with the authors of this message nor responsible for its content.