From owner-freebsd-fs@FreeBSD.ORG Wed Jan 7 12:54:52 2009 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CF569106566B for ; Wed, 7 Jan 2009 12:54:52 +0000 (UTC) (envelope-from kgysmits@gmail.com) Received: from mail-fx0-f11.google.com (mail-fx0-f11.google.com [209.85.220.11]) by mx1.freebsd.org (Postfix) with ESMTP id 35DED8FC17 for ; Wed, 7 Jan 2009 12:54:52 +0000 (UTC) (envelope-from kgysmits@gmail.com) Received: by fxm4 with SMTP id 4so1537629fxm.19 for ; Wed, 07 Jan 2009 04:54:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:in-reply-to:mime-version:content-type:references; bh=ZuSRrQYdjrmwTE5ydkKPJCBPi7Hyy8nd5MeL8UBSsn4=; b=aXDDVsX61P1kbgzWsw0fyadQNOlfg84q/jSWf+k1zQ7S6DOfPFPbCyZtGcN9GnaWRI v7c+lBCll7eI6kd2p8IhApAE0xgJglAAj0ZiFlDbE3nbgc/7+LCTnoUaLsswf+6ZxaeJ 8xO1RznI2KyzizguDg8+vqD5DhbHgI8r+4KXM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:references; b=s5EVIaArqrmeK/igJMkxeIMNiaByI9nWS6sWr92Swc8Oo6OoWrkNAQh7FCkdhIu+L5 iyvXAOyxeRcwh0JmQY26LVzw4qDUDdw3sqzzaGI3v9HPbM/pXxnDWfFpa08PO5yTq60L vhzs8DB1xSh+TUZ2ScSA3gohgfC2yhMU72Z9Y= Received: by 10.223.104.68 with SMTP id n4mr16415813fao.4.1231332891155; Wed, 07 Jan 2009 04:54:51 -0800 (PST) Received: by 10.223.108.136 with HTTP; Wed, 7 Jan 2009 04:54:50 -0800 (PST) Message-ID: Date: Wed, 7 Jan 2009 13:54:50 +0100 From: "Koen Smits" To: "Andrew Snow" In-Reply-To: <4962A1D6.4040508@modulus.org> MIME-Version: 1.0 References: <4962A1D6.4040508@modulus.org> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-fs@freebsd.org Subject: Re: FreeBSD, SSD's and partition alignment X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Jan 2009 12:54:53 -0000 On Tue, Jan 6, 2009 at 01:12, Andrew Snow wrote: > I'd like to discuss this subject a bit if anyone's interested. >> - partition alignment seems to be a real problem with some of today's >> flash >> and RAID media. I think people need to know one could easily increase >> performance (and media wear!) as no one knows this problem exists. >> > > Thanks for your interesting post! > > In my humble opinion, FreeBSD should not worry about this problem for the > following reasons: > > 1. Performance for random write I/O still sucks even when the sector > boundary is correct. Doing something like untarring src or ports causes > many small write I/Os, and it is simply a shortcoming of early generation > flash controller technology that they erase and rewrite in large blocks. > > 2. This problem will go away when flash controller technology improves. > Intel SSDs have already demonstrated they can have great performance *and* > a small erase block size, mitigating the issue completely. This technology > will trickle down to the cheaper flash SSDs over time. > > > - Andrew > Sorry for the late reply. I've been busy. I agree with point 1, if the controller is able to 'save up' small writes and write this sequentially without making a mess out of it, this is preferred. We will never completely remove the 'virtual layers' between the OS and the storage medium itself and that is fine. point 2 however, i disagree. It's time we dump the whole track/cylinder/head thing. Even back in 1984 this was already outdated, lets just throw it overboard! Let's assume that from FreeBSD 8 and onward, we just use GPT and a partition offset of 1MB by default. Everybody would benefit, and no-one would really have any problems with it, right? We would all benefit in my opinion. Note that even the Intel X25-M series seem to slow down in random write speed when the complete disk is filled and there are no cells left that the controller knows are free. Most benchmarks out there are run on an empty Intel SSD. When you rerun that test several times, it'll slowly settle on a much lower random write speed.