= Сообщение: 3641 из 10763 ===================================== RU.UNIX.BSD = От : Valentin Davydov 2:5020/400 23 Oct 15 18:17:43 Кому : Victor Sudakov 23 Oct 15 18:17:43 Тема : Re: Страшные тормоза zfs FGHI : area://RU.UNIX.BSD?msgid=<1187502864@ddt.demos.su>+9cabd33f На : area://RU.UNIX.BSD?msgid=2:5005/49+56289b60 = Кодировка сообщения определена как: CP866 ================================== ============================================================================== From: Valentin Davydov <sp@m.davydov.spb.su>
> From: Victor Sudakov <Victor.Sudakov@f49.n5005.z2.fidonet.org> > Date: Thu, 22 Oct 2015 14:10:12 +0300 > > >> AK> плюс, там, насколько я помню, хитрая > >> AK> древовидная структура, требующая перебалансировки каждый раз. > >> > >> Это хуже. Hо я надеюсь, это может делаться в фоне? > > VD> Hе может: у диска головка одна (да даже если и несколько, то в > VD> современных дисках они работают строго по очереди), так что все > VD> операции происходят последовательно, и следующая не может начаться, > VD> пока не закончилась предыдущая. Даже всякие якобы железные background > VD> smartы на самом деле могут работать только в промежутках между > VD> занятостью диска исполнением команд операционной системы. > >Я имел в виду несколько другое. Если под "перебалансировкой" подразумевается >какой-то housekeeping для собственных нужд файловой системы, надеюсь она не >будет заниматься этим в моменты, когда с нее активно читают или пишут?
Как раз активная запись и есть причина той самой перебалансировки. Т.е. плюнули мы в драйвер порцию данных - данные легли на диск, метаданные перестраиваются (а для этого, между прочим, нужно прочитать все метаданные, которые будут перестариваться, и которых в известных сценариях бывает сильно побольше, чем собственно данных), и наконец транзакция финализируется (в уберблок пишется её идентификатор, причём два раза в начало диска и два раза в конец). И вот всё это время диск занят позиционированием головок, и хрен ты чего с него ещё прочитаешь. Hесколько спасает кэш, но при определённых условиях (всё что нужно уже поднято туда с диска, никто не требует fsync() и т.д.).
> VD> То есть перебалансироваться без ожидания дисковых операций чтения > VD> могут только те деревья, которые целиком сидят в кэше. > >Пусть перебалансировка ожидает окончания чтения, а не наоборот?
Перебалансировка уже началась, головка поехала на другой край диска. Она (головка) физическая, ждёт пока под ней окажется нужное место поверхности, и про твои хотелки чего-нибудь ещё прочитать у неё нет возможности узнать. И не будет ещё миллисекунд этак 10-20.
Вал. Дав.
--- ifmail v.2.15dev5.4 * Origin: Demos online service (2:5020/400)
