From owner-freebsd-hackers@FreeBSD.ORG Sat May 26 14:01:56 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 94121106566C for ; Sat, 26 May 2012 14:01:56 +0000 (UTC) (envelope-from wojtek@wojtek.tensor.gdynia.pl) Received: from wojtek.tensor.gdynia.pl (wojtek.tensor.gdynia.pl [89.206.35.99]) by mx1.freebsd.org (Postfix) with ESMTP id EEEFF8FC0C for ; Sat, 26 May 2012 14:01:54 +0000 (UTC) Received: from wojtek.tensor.gdynia.pl (localhost [127.0.0.1]) by wojtek.tensor.gdynia.pl (8.14.5/8.14.5) with ESMTP id q4QE1t4o070320; Sat, 26 May 2012 16:01:55 +0200 (CEST) (envelope-from wojtek@wojtek.tensor.gdynia.pl) Received: from localhost (wojtek@localhost) by wojtek.tensor.gdynia.pl (8.14.5/8.14.5/Submit) with ESMTP id q4QE1se4070317; Sat, 26 May 2012 16:01:55 +0200 (CEST) (envelope-from wojtek@wojtek.tensor.gdynia.pl) Date: Sat, 26 May 2012 16:01:54 +0200 (CEST) From: Wojciech Puchar To: Peter Jeremy In-Reply-To: <20120525225839.GA7347@server.rulingia.com> Message-ID: References: <4fb7dfd6.736a980a.186d.ffff902f@mx.google.com> <20120519180901.GA1264@tiny> <20120525183006.GA1259@tiny> <20120525225839.GA7347@server.rulingia.com> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.2.7 (wojtek.tensor.gdynia.pl [127.0.0.1]); Sat, 26 May 2012 16:01:55 +0200 (CEST) Cc: freebsd-hackers@freebsd.org, Matthias Apitz , rozhuk.im@gmail.com Subject: Re: proper newfs options for SSD disk X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 May 2012 14:01:56 -0000 >> 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@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@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