From owner-freebsd-hackers@FreeBSD.ORG Sat May 26 14:31:48 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 887351065674 for ; Sat, 26 May 2012 14:31:48 +0000 (UTC) (envelope-from utisoft@gmail.com) Received: from mail-bk0-f54.google.com (mail-bk0-f54.google.com [209.85.214.54]) by mx1.freebsd.org (Postfix) with ESMTP id 0984D8FC08 for ; Sat, 26 May 2012 14:31:47 +0000 (UTC) Received: by bkvi18 with SMTP id i18so1792401bkv.13 for ; Sat, 26 May 2012 07:31:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type :content-transfer-encoding; bh=ezsRJpfoUfh/oCsuBFCC57dafPsA9UaKCe3UiVOgkus=; b=OG4lbPe7mKGlzyZMddFD8z04xQvT+u9i+JRzk6EwlXh0zhKUlwBZ4KWU87n7AInMqn bqRefdigrdq0TuAlVbAq3lRYTsMeIIe9TLP1tHojSEEbLsuRTnZT5i5fILdNI3VJHLpy ORkYa7bL8kEWnL7R2pckBr8M8tK2MP1Jh/PFPOw62pj1TLPO9erUjti9Za6fNF05o1FN UKdzr/h8SCoKzGBryjVRZmB7+RlvCRs3RSN0gs4FGxmbhEoSva4Yc6fzhzP7WTKKjfPL TRu2hhQm+cdM+9+WI/okmbbei5rt607704pH1kCsuCi5/U6QKi6Pk98SktyglhQpbsbj jHZQ== Received: by 10.204.153.15 with SMTP id i15mr1026885bkw.74.1338042706832; Sat, 26 May 2012 07:31:46 -0700 (PDT) MIME-Version: 1.0 Sender: utisoft@gmail.com Received: by 10.204.171.138 with HTTP; Sat, 26 May 2012 07:31:16 -0700 (PDT) In-Reply-To: References: <4fb7dfd6.736a980a.186d.ffff902f@mx.google.com> <20120519180901.GA1264@tiny> <20120525183006.GA1259@tiny> <20120525225839.GA7347@server.rulingia.com> From: Chris Rees Date: Sat, 26 May 2012 15:31:16 +0100 X-Google-Sender-Auth: JwQ5Rvb7rYQUbgslHwP_DqoqHWM Message-ID: To: Wojciech Puchar Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable 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:31:48 -0000 On 26 May 2012 15:01, Wojciech Puchar wrot= e: >>> Why? Your laptop have most probably slow CPU and it will make everythin= g >>> 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 tha= n >> 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=3D/dev/zero of=3D/dev/md0 bs=3D128k count=3D4k > dd if=3D/dev/md0 of=3D/dev/null bs=3D128k count=3D4k > > geli init -s 2048 /dev/md0 > geli attach /dev/md0 > dd if=3D/dev/md0.eli of=3D/dev/null bs=3D128k count=3D4k (*) > dd if=3D/dev/zero of=3D/dev/md0.eli bs=3D128k count=3D4k (*) > geli detach /dev/md0 > mdconfig -d -u 0 > > > but from my experience intel atom have very low geli performance, esp. ol= der > models. and your laptop is atom based IMHO. > > result from commands marked with * on my atom based machine: > [root@bk ~/NOBACKUP]# dd if=3D/dev/md0.eli of=3D/dev/null bs=3D128k count= =3D4k > 4095+1 records in > 4095+1 records out > 536868864 bytes transferred in 25.030418 secs (21448658 bytes/sec) > [root@bk ~/NOBACKUP]# dd if=3D/dev/zero of=3D/dev/md0.eli bs=3D128k count= =3D4k > 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 =A0 @ 1.80GHz (1827.08-MHz K8-class CPU) > > And i actually do use geli on it, but as the only thing it does is regula= rly > 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). =A0The 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 >> =A0system 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 h= ave > 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. >> =A0[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 >> =A0it'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