proper newfs options for SSD disk

[Chris Rees]

On 26 May 2012 15:01, Wojciech Puchar <wojtek at wojtek.tensor.gdynia.pl> wrote:
>>> 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).
>
>
> right. DO TESTs.
>
> mdconfig -a -t swap -s512m -u 0
> dd if=/dev/zero of=/dev/md0 bs=128k count=4k
> dd if=/dev/md0 of=/dev/null bs=128k count=4k
>
> geli init -s 2048 /dev/md0
> geli attach /dev/md0
> dd if=/dev/md0.eli of=/dev/null bs=128k count=4k (*)
> dd if=/dev/zero of=/dev/md0.eli bs=128k count=4k (*)
> geli detach /dev/md0
> mdconfig -d -u 0
>
>
> but from my experience intel atom have very low geli performance, esp. older
> models. and your laptop is atom based IMHO.
>
> result from commands marked with * on my atom based machine:
> [root at bk ~/NOBACKUP]# dd if=/dev/md0.eli of=/dev/null bs=128k count=4k
> 4095+1 records in
> 4095+1 records out
> 536868864 bytes transferred in 25.030418 secs (21448658 bytes/sec)
> [root at bk ~/NOBACKUP]# dd if=/dev/zero of=/dev/md0.eli bs=128k count=4k
> dd: /dev/md0.eli: short write on character device
> dd: /dev/md0.eli: end of device
> 4096+0 records in
> 4095+1 records out
> 536868864 bytes transferred in 26.050000 secs (20609169 bytes/sec)
>
>
> as you can see results are awful, in spite it is
> CPU: Intel(R) Atom(TM) CPU D525   @ 1.80GHz (1827.08-MHz K8-class CPU)
>
> And i actually do use geli on it, but as the only thing it does is regularly
> running rsync to backup several other servers, it isn't a problem it can put
> heavy CPU load.
>
>
>> 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
>
>
> forgot about this. But this is good for ANY type of storage.
> I run noatime everywhere and don't have problems.
>
>
>> 2) Turn off all local syslogging (syslog is directed to another
>>  system when my laptop is at home, lost otherwise).
>
>
> of course, or use /tmp/ for syslog. syslog is useful even on private
> computer.
>
>
>> 3) Change maillog rotation to size instead of daily
>
>
> i - by default, and everywhere - turn off most things from default
> /etc/crontab including rotation.
>
> and if you have syslog turned off or changed as i recommended you don't have
> maillog file produced at all so no need to rotate.
>
> i recommend turning log rotation off at all everywhere, then turn it on
> willingly based on actual needs.
>
>
>> 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
>
> use tmpfs and don't fear to add /var/tmp to it.

I would fear to add /var/tmp-- /var/tmp should persist across reboots.

Chris