proper newfs options for SSD disk
Wojciech Puchar
wojtek at wojtek.tensor.gdynia.pl
Sat May 26 14:01:56 UTC 2012
>> 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.
> 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.
isn't simpler to just turn cache off in firefox?
>
> Also, you're probably better off running a traditional lightweight
> window manager than something like KDE or Gnome.
Which is good recommendation on any kind of computer and disk type, not
just yours.
another recomendation - why you everywhere put DOS/MBR partitions?
it's just a mess and completely useless unless you run windoze on the same
disk.
when using whole device filesystem just clean head (dd if=/dev/zero
of=/dev/device bs=1m count=1) and then just do newfs
if now just bsdlabel -w device, bsdlabel -e device and possibly
bsdlabel -B device
it's that simple
More information about the freebsd-hackers
mailing list