Re: Problem identified: WAPL/RAIDframe performance problems

[David Holland <dholland-tech%netbsd.org@localhost>]

On Sat, Dec 01, 2012 at 07:07:36PM -0500, Mouse wrote:
 > >> Neither.  The sector size claimed to the host should equal both the
 > >> sector size on the media and the granularity of the interface.
 > > As a consumer of block devices, I don't care about either of these
 > > things.  What I care about is the largest size "sector" that will (in
                                       ^^^^^^^
 > > the ordinary course of things anyway) be written atomically.
 > 
 > Then those are 512-byte-sector drives as far as you're concerned; you
 > can ignore the 4K reality.  At least, absent bugs in the drives, but
 > that's always a valid caveat.

No; because I can do 4K atomic writes, I want to know about that.
(Quite apart from any performance issues.)

Physical realities pretty much guarantee that the largest atomic write
is not going to cause a RMW cycle... at least on items that are
actually block-based. 

RAIDs where you have to RMW a whole stripe or something but it isn't
atomic might be a somewhat different story. I'm not sure how one would
build a journaling FS on one of those without having it suck. (I
guess by stuffing the journal into NVRAM.)

 > > I don't care about the block granularity of the interface.
 > 
 > Don't you pretty much have to care about it, since that's the unit in
 > which data addresses are presented to its interface?  Or is that
 > something you believe should be hidden by...something else?

That is something only the device driver should have to be aware of.

(There's an implicit assumption here that block devices should be
addressed with byte offsets, as they are from userland, even though
this typically wastes a dozen or so bits; the minor overhead is far
preferable to the confusion that arises when you have multiple size
units floating around, and the consequences of just one bug that mixes
block offsets measured in different block sizes can be catastrophic.)

 > (It's not clear to me exactly what the `you' that doesn't care
 > about interface granularity includes - hardware driver authors?
 > filesystem authors?  midlayer (eg scsipi) authors?)

I'm speaking from a filesystem point of view; but, more specifically,
I'm talking about the abstraction we call a "block device", whith sits
above stuff like scsipi.

-- 
David A. Holland
dholland%netbsd.org@localhost