From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from lists.gentoo.org (pigeon.gentoo.org [208.92.234.80]) by finch.gentoo.org (Postfix) with ESMTP id 812E1138010 for ; Sun, 26 Aug 2012 14:24:03 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 908CFE06B7; Sun, 26 Aug 2012 14:23:22 +0000 (UTC) Received: from mail-ee0-f53.google.com (mail-ee0-f53.google.com [74.125.83.53]) by pigeon.gentoo.org (Postfix) with ESMTP id 28ED7E067D for ; Sun, 26 Aug 2012 14:21:42 +0000 (UTC) Received: by eekb47 with SMTP id b47so588334eek.40 for ; Sun, 26 Aug 2012 07:21:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=from:to:cc:subject:date:message-id:user-agent:in-reply-to :references:mime-version:content-transfer-encoding:content-type; bh=nCtmufg4u4kcH03UHc2CjUmoNdDLXiX5Wpxo7TL48U4=; b=J/mtD5mzJ1hFXvRVK1t+r2daz2N+sb27eDo7bKLFMuUzDNY5zMgNq88ekh0trPkJly ruBpDm8E/jTp0bhpJxCongefp4HpAVOn05yhKVI0yRJ0Be0JywGgXf9E+FlOBz3Wzn38 HJKYXeIzKpeDXGE30k1+JiNbMpbhNlKD3/nIwkE7Sf2Dwu+KZi5byTHaQRkmVqAbdlrv jo7y0siNcYcKFxpUe2IqI4R/Xyw2SkmHuFwTLEaQ301L8ZH1BdNGFH3wRY9bsJcYW4IM p73Xi1bQMUo13hjgfI1p0Rt3OOIHXiQeSlScy7l1XBPEfFhM/oXm+SgNXO/pYbaQL6Qn ueuQ== Received: by 10.14.221.197 with SMTP id r45mr11740125eep.41.1345990902104; Sun, 26 Aug 2012 07:21:42 -0700 (PDT) Received: from energy.localnet (p4FC61288.dip0.t-ipconnect.de. [79.198.18.136]) by mx.google.com with ESMTPS id c6sm44629291eep.7.2012.08.26.07.21.39 (version=TLSv1/SSLv3 cipher=OTHER); Sun, 26 Aug 2012 07:21:40 -0700 (PDT) From: Volker Armin Hemmann To: gentoo-user@lists.gentoo.org Cc: Alex Schuster Subject: Re: [gentoo-user] SSD performance tweaking Date: Sun, 26 Aug 2012 16:21:31 +0200 Message-ID: <1423183.AyWZLp8OMG@energy> User-Agent: KMail/4.9 (Linux/3.4.9; KDE/4.9.0; x86_64; ; ) In-Reply-To: <503A1B44.1050701@wonkology.org> References: <1726832.5OjJhh9kq3@energy> <503A1B44.1050701@wonkology.org> Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-user@lists.gentoo.org Reply-to: gentoo-user@lists.gentoo.org MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-Archives-Salt: 228d14be-644b-41df-9e15-06e639df20a7 X-Archives-Hash: c2aac69ff768233e74bebc3baf552b1e Am Sonntag, 26. August 2012, 14:49:08 schrieb Alex Schuster: > Volker Armin Hemmann writes: > > Am Sonntag, 26. August 2012, 13:41:09 schrieb Alex Schuster: > >> Frank Steinmetzger writes: > >>> Unless the filesystem knows this and starts bigger files at those 512 k > >>> boundaries (so really only one erase cycle is needed for files <=512 k), > >>> isn't this fairly superfluous? > >> > >> Yes, I think it is. When you search for SSD alignment, you read about > >> this alignment all the time, even on the German Wikipedia, and many > >> resources say that this can have a big impact on performance. But I > >> could not find a real explanation at all. > >> > >> Besides that, it's not so easy to do the alignment, at least when using > >> LVM. I read that LVM adds 192K header information, so even if you align > >> the partition start to an erasable block size of 512K, the actual > >> content is not aligned. See [*] for information how to overcome this. > >> That is, if you believe the alignment to erasable blocks is important, > >> personally I do not know what to think now. It wouldn't hurt, so why not > >> apply it, but it seems like snake oil to me now. > >> > >> Wonko > >> > >> http://tytso.livejournal.com/2009/02/20/ > > > > because erasing is slow. You can not overwrite data on a ssd. you have to > > erase first, then reprogramm. Also, erasing shortens lifetime. > > Yes, I know that. But why exactly does it help to align a partition to > the erasable block size? I don't get it. Why isn't it sufficient to > align to the usual 4K block size, so that a block never spans over two > erasable blocks? well, for one, there are lots of ssd which have 8k pages. Not 4k. -- #163933