VU> хм обратно, с таким никогда не сталкивался, возможно это какая-то VU> особенность FBSD. скорее, старых версий zfs, возможно, что-то и исправлено сейчас, раз у тебя, чудесным образом, тоже решилась проблема.
VU> Да. Я лет десять назад на эту тему колл делал. Объяснение было VU> что это фича а не баг. Чтобы удалить файл, надо произвести а, ну да, COW же-ж.
очччень интересно, как эту проблему решили. Полагаю, довольно некрасивым способом.
VU> ничего удалить. Точно также оно не должно было работать с играми VU> с резервированием. zfs set будет записывать в датасет, что на VU> переполненном пуле (было раньше) фатально. так у нас пул-то не переполнен - резерв не дал. Переполнен dataset, да и хрен с ним. Убираем резерв (не с него, а с другого, который держали именно для резерва, и, поскольку он пустой, место там есть) - и у нас еще целых пол-часа на то, чтобы как-то выкрутиться, пока и этот резерв не сожран ;-) "и хрен вы меня потом найдете!"
AK>> ты хочешь сказать, у нас и резервы не работают? VU> Я хочу сказать что если всё работает как в опениндиане, резервами можно не хм... это место у нас одно и то же. Или даже у опенинди оно более старое, за счет более древного среза с первоисточника.
VU> пользоваться. Если какая-то программа завалила мусором диск, надо удалить VU> мусор, как мы это делаем на UFS. надо бы еще потестировать, не упадет ли производительность обращений к не-мусору до околонулевой, как оно и было у нас раньше. Если это происходило из-за неоптимального размещения блоков - то даже после освобождения места решить проблему можно только с помощью cp && rm (близкая проблема аналогичного происхождения, не так давно вроде-бы-исправленная, решалась только так. Что уже через жопу отлеглось на диски, так через жопу и оставалось, логичненько)
я до сих пор не придумал, как устроить подобный тест в безопасном месте.
> Alex
--- ifmail v.2.15dev5.4 * Origin: Demos online service (2:5020/400)
