File system blocks alignment

[Pieter de Goeje]

On Friday 01 January 2010 23:47:12 Poul-Henning Kamp wrote:
> In message <201001012153.44349.pieter at 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