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>