From owner-freebsd-hackers@FreeBSD.ORG Fri May 25 22:58:58 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 22500106564A for ; Fri, 25 May 2012 22:58:57 +0000 (UTC) (envelope-from peter@rulingia.com) Received: from vps.rulingia.com (host-122-100-2-194.octopus.com.au [122.100.2.194]) by mx1.freebsd.org (Postfix) with ESMTP id 6D62B8FC08 for ; Fri, 25 May 2012 22:58:56 +0000 (UTC) Received: from server.rulingia.com (c220-239-254-65.belrs5.nsw.optusnet.com.au [220.239.254.65]) by vps.rulingia.com (8.14.5/8.14.5) with ESMTP id q4PMwlV2086146 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sat, 26 May 2012 08:58:49 +1000 (EST) (envelope-from peter@rulingia.com) X-Bogosity: Ham, spamicity=0.000000 Received: from server.rulingia.com (localhost.rulingia.com [127.0.0.1]) by server.rulingia.com (8.14.5/8.14.5) with ESMTP id q4PMwfjG085074 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 26 May 2012 08:58:41 +1000 (EST) (envelope-from peter@server.rulingia.com) Received: (from peter@localhost) by server.rulingia.com (8.14.5/8.14.5/Submit) id q4PMwdN9085073; Sat, 26 May 2012 08:58:39 +1000 (EST) (envelope-from peter) Date: Sat, 26 May 2012 08:58:39 +1000 From: Peter Jeremy To: Wojciech Puchar Message-ID: <20120525225839.GA7347@server.rulingia.com> References: <4fb7dfd6.736a980a.186d.ffff902f@mx.google.com> <20120519180901.GA1264@tiny> <20120525183006.GA1259@tiny> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="VS++wcV0S1rZb1Fb" Content-Disposition: inline In-Reply-To: X-PGP-Key: http://www.rulingia.com/keys/peter.pgp User-Agent: Mutt/1.5.21 (2010-09-15) 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: Fri, 25 May 2012 22:58:58 -0000 --VS++wcV0S1rZb1Fb Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On 2012-May-25 22:46:10 +0200, Wojciech Puchar 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=20 >to partitions) and geli encrypted home on 4GB SSD (whole device). if=20 >sometimes 4GB would be too little for /home then you would manually move= =20 >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= =20 >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. --=20 Peter Jeremy --VS++wcV0S1rZb1Fb Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iEYEARECAAYFAk/ADp8ACgkQ/opHv/APuIcsWACgjf/aT+PpUcNvlPlLlq8KPFnT Cn4AoLF9+5NQQiz1pOIHtAkIYim6RlgV =J635 -----END PGP SIGNATURE----- --VS++wcV0S1rZb1Fb--