Добро пожаловать, Гость. Пожалуйста авторизуйтесь здесь.
FGHIGate на GaNJa NeTWoRK ST@Ti0N - Просмотр сообщения в эхоконференции RU.UNIX.BSD
Введите FGHI ссылку:


Присутствуют сообщения из эхоконференции RU.UNIX.BSD с датами от 18 Jan 11 22:51:00 до 16 Sep 24 17:28:15, всего сообщений: 10763
Ответить на сообщение К списку сообщений Предыдущее сообщение Следующее сообщение
= Сообщение: 3619 из 10763 ===================================== RU.UNIX.BSD =
От   : Valentin Davydov                 2:5020/400         22 Oct 15 10:12:14
Кому : Victor Sudakov                                      22 Oct 15 10:12:14
Тема : Re: Страшные тормоза zfs
FGHI : area://RU.UNIX.BSD?msgid=<1187502841@ddt.demos.su>+8c3ad5f4
На   : area://RU.UNIX.BSD?msgid=2:5005/49+5625ddfe
= Кодировка сообщения определена как: CP866 ==================================
Ответ: area://RU.UNIX.BSD?msgid=2:5005/49+56289b60
==============================================================================
From: Valentin Davydov <sp@m.davydov.spb.su>

>   From: Victor Sudakov <Victor.Sudakov@f49.n5005.z2.fidonet.org>
>   Date: Tue, 20 Oct 2015 11:58:06 +0300
>
> VS>> Хотя интересно, почему удаление-то тормозит при заполнении пула.
> VS>> Операции, которые делаются через CoW, понятно почему тормозят, а
> VS>> при удалении там тоже, что ли, что-то куда-то копируется?
> AK> метаинформация - разумеется,
>
>Тогда если log вынести на отдельное устройство, будет легче? В смысле,
>отдельный log device должен получиться поменьше и подешевле, чем 10% от
>многотерабайтного пула.

Log (в смысле, ZIL) - он вообще write-only, как я понял из описания.
То есть если нет задачи гарантировать свежесть данных после внезапной
перезагрузки, то в качестве лога вполне успешно (и очень быстро)
работает /dev/null (ну, то есть, sync=disabled logbias=throughput).

> AK> плюс, там, насколько я помню, хитрая
> AK> древовидная структура, требующая перебалансировки каждый раз.
>
>Это хуже. Hо я надеюсь, это может делаться в фоне?

Hе может: у диска головка одна (да даже если и несколько, то в современных
дисках они работают строго по очереди), так что все операции происходят
последовательно, и следующая не может начаться, пока не закончилась
предыдущая. Даже всякие якобы железные background smartы на самом деле
могут работать только в промежутках между занятостью диска исполнением
команд операционной системы.

То есть перебалансироваться без ожидания дисковых операций чтения могут
только те деревья, которые целиком сидят в кэше.

Вал. Двв.
--- ifmail v.2.15dev5.4
* Origin: Demos online service (2:5020/400)

К главной странице гейта
Powered by NoSFeRaTU`s FGHIGate
Открытие страницы: 0.101624 секунды