Unexpected SU+J inconsistency AGAIN -- please, don't shift topic to ZFS!

[Lev Serebryakov]

Hello, Don.
You wrote 9 марта 2013 г., 7:03:52:


>>     But anyway, torrent client is bad benchmark if we start to speak
>>   about some real experiments to decide what could be improved in
>>   FFS/GEOM stack, as it is not very repeatable.
DL> I seem to recall that you mentioning that the raid5 geom layer is doing
DL> a lot of caching, presumably to coalesce writes.  If this causes the
DL> responses to writes to be delayed too much, then the geom layer could
DL> end up starved for writes because the vfs.hirunningspace limit will be
DL> reached.  If this happens, you'll see threads waiting on wdrain.  You
DL> could also monitor vfs.runningbufspace to see how close it is getting to
DL> the limit.  If this is the problem, you might want to try cranking up
  Strangely  enough,  vfs.runningbufspace  is  always zero, even under
load. My geom_raid5 is configured to dealy writes up to 15 seconds...

DL> Something else to look at is what problems might the delayed write
DL> completion notifications from the drives cause in the raid5 layer
DL> itself.  Could that be preventing the raid5 layer from sending other I/O
DL> commands to the drives?   Between the time a write command has been sent
   Nope. It should not. I'm not sure for 100%, as I picked up these
sources from original author and sources are rather cryptic, but I
could not see any throttling in it.
DL> to a drive and the drive reports the completion of the write, what
DL> happens if something wants to touch that buffer?

DL> What size writes does the application typically do?  What is the UFS
  64K writes, 32K blocksize, 128K stripe size... Now I'm analyzing
traces from this device to understand exact write patterns.
DL> blocksize?  What is the raid5 stripe size?  With this access pattern,
DL> you may get poor results if the stripe size is much greater than the
DL> block and write sizes.

-- 
// Black Lion AKA Lev Serebryakov <lev at FreeBSD.org>