Свежие комментарии

если пентаксист не страдает, он не пентаксист, как бывший пневод (*ist D.... K-5) говорю %)
не знаю как щас, а во времена К7 d-li90 еще и заряжалась столько, что невольно задашься вопросом "а не проще ручку с АА использовать?"
но вообще скорее всего на базе соневской зарядки мелочь должна бы быть...

Хотя чем оно лучше Imax B6 я не понял. Особенно 5-амперная.

Ну прелесть же: http://d112tss1dzpest.cloudfront.net/wp-content/blogs.dir/26/files/2015/...

Ох уж эта половина тока, да :-(
У меня тоже самое с микрозарядкой (см. выше про объём) для AA.

Надо смотреть, как долго работает. Я бы оптимистично предположил, что разряжает, заряжает и разряжает и сравнивает сколько залилось туда, а сколько — обратно. Но это оптимистичное предположение!

Ясно. Хотя казалось бы именно в таком девайсе ожидаешь, ну оно выглядит основательно как та же Маха какая или Опус.

Вот обзор A10-го: http://mysku.ru/blog/china-stores/37393.html

(в чем отличие от A5 не разбирался, думаю что в зарядных-разрядных токах, раз A10 - 10-амперник)

Ну вот, не побоюсь этого слова ZKE EBC-A05 (есть еще A-модели и B-модели, пока не разбирался еще в чем отличие).

Хотя вот Udoli, по твоей ссылке, - если там "восстановить емкость" - может то что надо (а если и нет, то зарядник на две кроватки я давно хотел)

Покажи девайс!

А вообще, у меня вот другая «беда» — я же езжу так что почти каждую ночь сколько-то электричества есть, но мне нужен минимальный объём всего. И вот штатная зарядка для пентаксовских батарей — она ничего особенного по параметрам, а размером с две пачки сигарет. НУ КУДА СТОЛЬКО?! А других — нет! Для кэнона я находил маленькие зарядки, а для D-LI90 не нашёл.

меня терзают смутные сомнения, что те многие просто купят ЕЩЕ несколько аккумов при подозрении на, а по результатам выезда выкинут задохликов в первую попавшуюся мусорку.

плюс не исключаю что ситуация "две недели без подзарядки с обильными съемками" и правда может быть сильно редкой.

Если объём считывания из l2arc-диска не изменяется (или даже увеличивается от раза к разу), а скорость скачет, то гипотеза верна. А если известна причина, то можно поискать решение :-). На счёт медленного чтения у меня пока больше сомнений.

А какая разница на пустом или заполненном? Важно только на повторяющейся картинке увидеть объём считанных данных с l2arc-диска при тестовом прогоне, сравнить с общим прочитанным объёмом и посмотреть на динамику изменения при следующих прогонах.

Странная - не странная, но она мне тоже пришла в голову :-). Только думаю не 10%, а наверно побольше и наверно эта цифра всё таки постепенно уменьшается. Если картинка ещё повторяется, то стоит ещё добавить между прогонами iostat -Ix и показать значения для l2arc-диска. Думаю по объёму прочитанных данных с него, может всё и прояснится :-).

Посмотрел сегодня arc.c. Далее только комментарии:
...
* At this point, we have a level 1 cache miss. Try again in
* L2ARC if possible.
...
* Read from the L2ARC if the following are true:
* 1. The L2ARC vdev was previously cached.
* 2. This buffer still has L2ARC metadata.
* 3. This buffer isn't currently writing to the L2ARC.
* 4. The L2ARC entry wasn't evicted, which may
* also have invalidated the vdev.
* 5. This isn't prefetch and l2arc_noprefetch is set.
Твои настройки не запрещают ни один из пунктов.
...
Начиная с 5775 строки, как мне кажется, самый важный комментарий для твоего случая. Желательно его прочитатать полностью. Приведу только, что меня заинтересовало:
...
* Read requests are satisfied from the following sources, in order:
*
* 1) ARC
* 2) vdev cache of L2ARC devices
* 3) L2ARC devices
* 4) vdev cache of disks
* 5) disks
*
* Some L2ARC device types exhibit extremely slow write performance.
* To accommodate for this there are some significant differences between
* the L2ARC and traditional cache design:
*
* 1. There is no eviction path from the ARC to the L2ARC. Evictions from
* the ARC behave as usual, freeing buffers and placing headers on ghost
* lists. The ARC does not send buffers to the L2ARC during eviction as
* this would add inflated write latencies for all ARC memory pressure.
*
* 2. The L2ARC attempts to cache data from the ARC before it is evicted.
* It does this by periodically scanning buffers from the eviction-end of
* the MFU and MRU ARC lists, copying them to the L2ARC devices if they are
* not already there. It scans until a headroom of buffers is satisfied,
* which itself is a buffer for ARC eviction. If a compressible buffer is
* found during scanning and selected for writing to an L2ARC device, we
* temporarily boost scanning headroom during the next scan cycle to make
* sure we adapt to compression effects (which might significantly reduce
* the data volume we write to L2ARC). The thread that does this is
* l2arc_feed_thread(), illustrated below; example sizes are included to
* provide a better sense of ratio than this diagram:
...
* 3. If an ARC buffer is copied to the L2ARC but then hit instead of
* evicted, then the L2ARC has cached a buffer much sooner than it probably
* needed to, potentially wasting L2ARC device bandwidth and storage. It is
* safe to say that this is an uncommon case, since buffers at the end of
* the ARC lists have moved there due to inactivity.
*
* 4. If the ARC evicts faster than the L2ARC can maintain a headroom,
* then the L2ARC simply misses copying some buffers. This serves as a
* pressure valve to prevent heavy read workloads from both stalling the ARC
* with waits and clogging the L2ARC with writes. This also helps prevent
* the potential for the L2ARC to churn if it attempts to cache content too
* quickly, such as during backups of the entire pool.
*
* 5. After system boot and before the ARC has filled main memory, there are
* no evictions from the ARC and so the tails of the ARC_mfu and ARC_mru
* lists can remain mostly static. Instead of searching from tail of these
* lists as pictured, the l2arc_feed_thread() will search from the list heads
* for eligible buffers, greatly increasing its chance of finding them.
*
* The L2ARC device write speed is also boosted during this time so that
* the L2ARC warms up faster. Since there have been no ARC evictions yet,
* there are no L2ARC reads, and no fear of degrading read performance
* through increased writes.
*
* 6. Writes to the L2ARC devices are grouped and sent in-sequence, so that
* the vdev queue can aggregate them into larger and fewer writes. Each
* device is written to in a rotor fashion, sweeping writes through
* available space then repeating.
*
* 7. The L2ARC does not store dirty content. It never needs to flush
* write buffers back to disk based storage.
*
* 8. If an ARC buffer is written (and dirtied) which also exists in the
* L2ARC, the now stale L2ARC buffer is immediately dropped.
...
Осталось выработать гипотезу и придумать как её проверить :-).