Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 25 Dec 2009 11:45:20 +0000
From:      "Poul-Henning Kamp" <phk@phk.freebsd.dk>
To:        Thomas Backman <serenity@exscape.org>
Cc:        Alexander Motin <mav@freebsd.org>, FreeBSD-Current <freebsd-current@freebsd.org>, freebsd-arch@freebsd.org
Subject:   Re: File system blocks alignment 
Message-ID:  <27416.1261741520@critter.freebsd.dk>
In-Reply-To: Your message of "Fri, 25 Dec 2009 12:22:08 %2B0100." <469FFFC8-514B-41B9-AEEC-E4B7AB6CB886@exscape.org> 

next in thread | previous in thread | raw e-mail | index | archive | help
In message <469FFFC8-514B-41B9-AEEC-E4B7AB6CB886@exscape.org>, Thomas Backman w
rites:
>On Dec 25, 2009, at 11:58 AM, Alexander Motin wrote:

>They don't expose this to the OS, though (not by default, anyway), but =
>chop it up into 8 512-byte sectors for compatibility reasons.
>Just thought I'd point that out - I'm not even sure if you can get them =
>to *not* do the compatibility thing and expose 4k-sized sectors.

While that is true, it is worth noting that the same Windows-compat
idioty is what doomed the world to RAID5 instead of RAID3.

The recent article in Queue Magazine shows how deeply ingrained the
512byte mindset has become: The author goes to great lengths to
praise RAID6 and higher for their ability to have multiple bit ECC
without ever recognizing (author not knowing ?) that RAID3 has had
this ability from day one.

UFS runs incredibly well on 4k blocks, and we should exploit that
to the fullest extent, and if we really want to jerk chains, we should
push RAID3 in 4+2 and 8+3 configs aggressively, it performs great,
both under read and write, and Windows cannot do it.

Poul-Henning

PS: Merry X-mas everybody!

-- 
Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20
phk@FreeBSD.ORG         | TCP/IP since RFC 956
FreeBSD committer       | BSD since 4.3-tahoe    
Never attribute to malice what can adequately be explained by incompetence.



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