22 Oct 15 10:12, you wrote to me: >> >> VS>> Хотя интересно, почему удаление-то тормозит при заполнении >> пула. >> VS>> Операции, которые делаются через CoW, понятно почему тормозят, >> а >> VS>> при удалении там тоже, что ли, что-то куда-то копируется? >> AK> метаинформация - разумеется, >> >> Тогда если log вынести на отдельное устройство, будет легче? В >> смысле, отдельный log device должен получиться поменьше и подешевле, >> чем 10% от многотерабайтного пула.
VD> Log (в смысле, ZIL) - он вообще write-only, как я понял из описания. VD> То есть если нет задачи гарантировать свежесть данных после внезапной VD> перезагрузки, то в качестве лога вполне успешно (и очень быстро) VD> работает /dev/null (ну, то есть, sync=disabled logbias=throughput).
Я уже написал в соседнем сообщении, что AFAIK если не предполагается синхронных операций, то log не нужен.
>> AK> плюс, там, насколько я помню, хитрая >> AK> древовидная структура, требующая перебалансировки каждый раз. >> >> Это хуже. Hо я надеюсь, это может делаться в фоне?
VD> Hе может: у диска головка одна (да даже если и несколько, то в VD> современных дисках они работают строго по очереди), так что все VD> операции происходят последовательно, и следующая не может начаться, VD> пока не закончилась предыдущая. Даже всякие якобы железные background VD> smartы на самом деле могут работать только в промежутках между VD> занятостью диска исполнением команд операционной системы.
Я имел в виду несколько другое. Если под "перебалансировкой" подразумевается какой-то housekeeping для собственных нужд файловой системы, надеюсь она не будет заниматься этим в моменты, когда с нее активно читают или пишут?
VD> То есть перебалансироваться без ожидания дисковых операций чтения VD> могут только те деревья, которые целиком сидят в кэше.
Пусть перебалансировка ожидает окончания чтения, а не наоборот?
