Skip site navigation (1)Skip section navigation (2)
Date:      Sat, 2 Jan 2010 01:01:16 +0100
From:      Pieter de Goeje <pieter@degoeje.nl>
To:        freebsd-arch@freebsd.org
Cc:        Poul-Henning Kamp <phk@phk.freebsd.dk>, freebsd-current@freebsd.org, Alexander Motin <mav@freebsd.org>, Thomas Backman <serenity@exscape.org>, Miroslav Lachman <000.fbsd@quip.cz>
Subject:   Re: File system blocks alignment
Message-ID:  <201001020101.16450.pieter@degoeje.nl>
In-Reply-To: <65036.1262386032@critter.freebsd.dk>
References:  <65036.1262386032@critter.freebsd.dk>

next in thread | previous in thread | raw e-mail | index | archive | help
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



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201001020101.16450.pieter>