From owner-freebsd-arch@FreeBSD.ORG Sat Jan 2 00:01:29 2010 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 048FF106566B; Sat, 2 Jan 2010 00:01:29 +0000 (UTC) (envelope-from pieter@degoeje.nl) Received: from smtp.utwente.nl (smtp1.utsp.utwente.nl [130.89.2.8]) by mx1.freebsd.org (Postfix) with ESMTP id 7D7108FC15; Sat, 2 Jan 2010 00:01:27 +0000 (UTC) Received: from nox.student.utwente.nl (nox.student.utwente.nl [130.89.165.91]) by smtp.utwente.nl (8.12.10/SuSE Linux 0.7) with ESMTP id o0201GdU003251; Sat, 2 Jan 2010 01:01:16 +0100 From: Pieter de Goeje To: freebsd-arch@freebsd.org Date: Sat, 2 Jan 2010 01:01:16 +0100 User-Agent: KMail/1.9.10 References: <65036.1262386032@critter.freebsd.dk> In-Reply-To: <65036.1262386032@critter.freebsd.dk> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <201001020101.16450.pieter@degoeje.nl> X-UTwente-MailScanner-Information: Scanned by MailScanner. Contact icts.servicedesk@utwente.nl for more information. X-UTwente-MailScanner: Found to be clean X-UTwente-MailScanner-From: pieter@degoeje.nl X-Spam-Status: No Cc: Poul-Henning Kamp , freebsd-current@freebsd.org, Alexander Motin , Thomas Backman , Miroslav Lachman <000.fbsd@quip.cz> Subject: Re: File system blocks alignment X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 Jan 2010 00:01:29 -0000 On Friday 01 January 2010 23:47:12 Poul-Henning Kamp wrote: > In message <201001012153.44349.pieter@degoeje.nl>, Pieter de Goeje writes: > >That yielded some pretty spectacular results. [...] > > > >Performance for restore was abysmal in the unaligned case, easily being 10 > >times slower than aligned restore. Newfs was about 5 times as slow. > > That is what I expected, only I didn't expect a factor 14 in performance. I'm trying to think of reasons why it performs so poorly, because even in the "write covers two sectors partially" case a read-modify-write cycle shouldn't mess performance up so badly, considering the drive's huge 64MB cache. Maybe the firmware is just not that smart. > > I'm not surprised that newfs and restore take the biggest hits in that > test, those are the hard ones, seen from the disk drive, all the read > only work can be cached and "covered up" that way. > > Ideally, newfs/UFS should do a quick test to look for any obvious > boundaries, and DTRT, a nice little task for somebody :-) A search for the offset for which newfs (or a simpler test) runs fastest? Interesting idea :-) Technically, the drive's at fault here because it should've reported 4K sectors. Perhaps there should be some kind of quirks table :-S for disk drives and/or a sectorsize override knob. Or maybe simply selecting a large enough power-of-two boundary suffices. That could also be done by gpart instead of (or in addition to) newfs. > > Poul-Henning > > PS: The reason I asked for 3 iterations, was so we could calculate > a standard deviation (See: ministat(8)) in order to have a statistical > sound conclusion. With a factor 14 in time difference, I will for > once conceede it unnecessary :-) Noted :-) - Pieter