181403648/4220336128 ( 4.3%) @6.0x, remaining 11:30 RBU 99.1% UBU 84.6%
209125376/4220336128 ( 5.0%) @6.0x, remaining 10:52 RBU 100.0% UBU 80.8%
232062976/4220336128 ( 5.5%) @5.0x, remaining 10:53 RBU 100.0% UBU 73.1%
241631232/4220336128 ( 5.7%) @2.1x, remaining 11:15 RBU 98.9% UBU 30.8%
256933888/4220336128 ( 6.1%) @3.3x, remaining 11:18 RBU 100.0% UBU 19.2%
This incident here looks quite strange:
1882193920/4220336128 (44.6%) @3.7x, remaining 8:10 RBU 100.0% UBU 26.9%
1883176960/4220336128 (44.6%) @0.2x, remaining 8:13 RBU 100.0% UBU 100.0%
1883176960/4220336128 (44.6%) @0.0x, remaining 8:17 RBU 100.0% UBU 100.0%
1886191616/4220336128 (44.7%) @0.7x, remaining 8:21 RBU 100.0% UBU 15.4%
Drive buffer is reported as full, but there is no
substantial data transfer for a short time.
This usually happens when recording crosses the velocity zone boundary.
Though it's too early if one trusts write performance descriptor [in one
previous posts it was at 112640*2K=230686720]...
Oops! I'm apparently off by factor of 10 here. Velocity zone change has
taken place much earlier and at the point where performance dropped from
6x to 3.?x instead of increasing to advertised 8x. I must have failed to
believe/accept that zone change can be at such low address... So it's
not "too early," but "indeed quite strange." A.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
