Игорь Сысоев оформил в виде патча (http://www.sysoev.ru/freebsd/softupdates.html) исправление неприятной и существующей непонятно сколько времени ошибки в FreeBSD softupdates, проявляющейся в том, что в один прекрасный момент свободное дисковое пространство начинало катастрофически уменьшаться пока не доходило до нуля. Помогала только перезагрузка.
В FreeBSD 4.11-STABLE, FreeBSD 5.4-STABLE и FreeBSD 6.0-BETA исправление ошибки появилось в конце августа.URL: http://www.sysoev.ru/freebsd/softupdates.html
Новость: http://www.opennet.me/opennews/art.shtml?num=6327
Бррр.... Вообще-то это фича SU... С трудом верится. :-\
Много где и на разных дисках использую SU и ни где еще не встречался с этой багой - не зашел бы на опеннет и не узнал бы ни когда...
>Много где и на разных дисках использую SU и ни где еще
>не встречался с этой багой - не зашел бы на опеннет
>и не узнал бы ни когда...На сервере на котором работает opennet.ru, кстати, softupdates именно по этой причине отключены.
У меня такое было когда MySQL был сильно нагружен, загрузка процессора была долгое время 100%. Когда пересмотрел задачу и снизил число запросов - место перестало исчезать
>У меня такое было когда MySQL был сильно нагружен, загрузка процессора была
>долгое время 100%. Когда пересмотрел задачу и снизил число запросов -
>место перестало исчезатьРечь идет о ситуации когда после того как руками создал файл и удалил его, число свободныех инод не увеличивается (после истечения metadelay и sync;sleep 1;sync;sleep 1;sync;sleep 1;sync). И так для каждого удаления, пока места или инод не останется.
>Много где и на разных дисках использую SU и ни где
>еще не встречался с этой багой - не зашел бы на
>опеннет и не узнал бы ни когда...Сталкивался неоднократно на нескольких серверах. Вдруг начинает кончаться место. Чистишь диск - а места все меньше. А после перезагрузки -- десяток гигов свободных вылезает... Так что, UserSU, Вам повезло... Или сервера у Вас не особо напрягаются.
А я насколько помню это происходила когда удалишь что то что в этот момент было октрыто на чтение. Тогда он как бы удалялся, но остовался до момента закрытия той программы которая открывает. А т.к. многие новички логи удаляют обычным rm а не через newsyslog/logrotate (например любят логи squid так удалять rm и всё), то место было зарезирвировано до окончания работы процесса. Сообственно перезагрузка помогала.А что интересно так это по какому принципу разделы freebsd уходят в минуса? :) Тоесть бывало видел в /tmp свободно -10% ))
>А я насколько помню это происходила когда удалишь что то что
>в этот момент было октрыто на чтение.Нет, проблема не имеет к этому отношения. Это реальная утечка инод в никуда.
На opennet, проявлялось раз в месяца два в момент ночных переиндексаций поисковых баз, когда создавались, копировались и удалялись файлы размеров мегабайт по 500. В один прекрасный момент, после такой переиндексации, место переставало освобождаться после любого удаления файла.
Поищите в архиве форума, там подобные проблемы не раз описывались.
>это происходила когда удалишь что то что в этот момент было октрыто на чтение. >Тогда он как бы удалялся, но остовался до момента закрытия той программы > то
>.........
>место было зарезирвировано до окончания работы процесса. Сообственно >перезагрузка помогала.которая открывает.
То, что вы говорите, это совершенно нормальное поведение любого *NIX-а. При удалении открытого файла, удаляется только запись в каталоге. Реальное освобождение inode происходит, когда обнуляется счётчик числа открытий файла.
> А что интересно так это по какому принципу разделы freebsd уходят в
> минуса? :) Тоесть бывало видел в /tmp свободно -10% ))вот расстраивает не сколько обсасывание надуманых проблем кривых ядер, как ламерство среди юниксоидов вообще.
В UFS при создании резервируется место (точно не помню сколько именно, может как раз эти 10%) "для рута". Остальное место считается полным размером ФС. Итого df показывает 100% занятости ФС при рельной занятости 90%. И никто кроме рута тогда не может писать на этот раздел. (Кривой костыль a-la quota. Кстати, в ext2/3 линоховых тоже такое убожество есть).
А вот когда рутовый squid продолжает писать логи далее "100"% - то команда df выдаст и -1% и -10% свободно. Хоть в Линухе такого ужаса нет. Просто 0 своб. места и все.
Рутовый сквид? Да вам не `кривыми костылями' и `убожествими' разбрасываться, вам в детский сад надо :))
>Рутовый сквид? Да вам не `кривыми костылями' и `убожествими' разбрасываться, вам в
>детский сад надо :))да. забыл. давно дело было. кажись внатуре от 'squid'а был
>Рутовый сквид? Да вам не `кривыми костылями' и `убожествими' разбрасываться, вам в детский сад надо :))Согласен, воинствующий ламериз, присущий данному индивиду, просто поражает. Что ни слово, так прямо БОЖЕСТВЕННОЕ ОТКРОВЕНИЕ и ИСТИНА В ПОСЛЕДНЕЙ ИНСТАНЦИИ.
а вообще-то _Nick_ прав про ламерство,
есть еще такая штука, как tunefs, которй пользовались в 4.x Free для включения софтапдейта (это в 5.х включено по умолчанию), так вот если внимательно прочитать nam tunefs, то там есть описание ключика -m
RTFM всем кто спрашивает про свободное место...
>В UFS при создании резервируется место (точно не помню сколько именно, может
>как раз эти 10%) "для рута". Остальное место считается полным размером
>ФС. Итого df показывает 100% занятости ФС при рельной занятости 90%.
>И никто кроме рута тогда не может писать на этот раздел.
>(Кривой костыль a-la quota. Кстати, в ext2/3 линоховых тоже такое убожество
>есть).Для справки. Это место резервируется не для root'а, а для служебных нужд файловой системы. Файловая система при наличии этого свободного места более оптимально распределяет свободные блоки, в результате чего сводится к минимуму фрагментация файлов. Установка этого параметра менее 5% отключает алгоритм оптимизации, в результате чего вы полусаете больший процен фрагментации => снижение скорости.
>А что интересно так это по какому принципу разделы freebsd уходят в
>минуса? :) Тоесть бывало видел в /tmp свободно -10% ))man tunefs /-m
Было такое. было. сам я не понимал что это от sostupdates
Сейчас начнут красноглазые...
Страшно в первый раз было когда увидел -9%
Потом su выключил. и все в шоколаде. досадно думаю в 6 исправят.
Это не баг, а не совсем верно реализованая фича
Люди, всегда читал что на опеннете на порядок меньше тупых плстов, не разубеждайте меня pls. Почему минус - все есть в доках.Что касается темы треда - то надеюсь что пач действительно работает и данная проблемма наконец уйдет из фришки.
В куду этот патч?> В FreeBSD 4.11-STABLE, FreeBSD 5.4-STABLE
> и FreeBSD 6.0-BETA исправление ошибки
> появилось в конце августа.Накатываю src-all, все хорошо 4.11 RELEASE-p13.
Смотрю файлы, которые предполагается патчить, и не нахожу в
"src/sys/ufs/ffs/ffs_softdep.c"
следов кода из патча.В релизе проблема исправлена другим кодом, без привлечения этого патча? Или что? На freebsd.org ничего не нашел, в Google тоже.
4.11-RELEASE-p13 - это RELENG_4_11, а 4.11-STABLE - это RELENG_4.
В RELENG_4_11 исправления нет. С точки зрения security team это несерьёзная ошибка. Вот мифическая дыра в HTT - это совсем другое дело.
Последнее время все чаще сталкиваюсь с мыслью, что в core есть таки фанаты Solaris: такая вот накатка на релиз лишь патчей связанных с безопасностью, но не обычными багами; написали pkill, pgrep...
Чего-то не понял. Написано, что патч для ранних версий, и что для FreeBSD 4.11-STABLE, FreeBSD 5.4-STABLE и FreeBSD 6.0-BETA исправления сделаны в августе.А теперь написано, что надо таки патчить 4.11. Ничего не понял...
4.11-RELEASE с security update'ами - это не FreeBSD 4.11-STABLE.
В 4.11-RELEASE-p13 и 5.4-RELEASE-p8 ошибка осталась.
В будущей 6.0-RELEASE её не будет.
А то ломает ехать на площадку, если что.4.11-RELEASE-p13 - патчить можно?
Не можно, а нужно.
Ляжет/не ляжет.Был флейм насчет адаптековских рейдов - винили их в том, что mySQL из-за них вешает систему на большой нагрузке. Но похоже дело именно в softupdates.
da net, taki veshaet, i ne tol'ko mysql. U menya i postgre veshal.
Посмотрим. Условия в которых оно вешается, примерно известны.
Когда в заросе есть JOIN mySQL пишет временную таблицу строго на диск.
Заставить mySQL не писать JOIN в /tmp не сумел.
Сильно похоже на потерю нодов софтапдейтом.
Если за следующую неделю сервис снова висанёт, значит софтапдейтс не при чем.
по пробуйте покрутить tmp_table_size
если включть query_cache_type=1, то до тех пор, пока не исчерпается query_cache_size=xxx повторные запросы (те, что уже попали в кэш) не создают временных файлов. Но в первый раз на любой запрос временный файл на диске все равно создается!
правы ораторы - Nerian и andreyn, если предварительно обнулить файл и лишь потом стереть - потери места не наблюдается.
Вывод: перед удалением echo > file и телемаркет.
Хотя решение проблемы напрямую, все же радует.
>правы ораторы - Nerian и andreyn, если предварительно обнулить файл и лишь
>потом стереть - потери места не наблюдается.Наблюдается. Вы не о той потере места говорите. Не путайте тривиальное незакрытие файла после unlink'а, которое сразу видно в fstat, и проблему softupdates, для которой и выпущен данный патч и которая странным и трудноповторимым образом проявлялась, раз в полгода, на серверах интенсивно оперирующих большими файлами.
да, еще в добавок:
нет нужды перегружать систему, достаточно убить процесс держащий откртыми эти файлы...
я надеюсь ни у кого нет ядра открывшего
файл на 5 Гб :)))
Исправленная ошибка не имеет никакого отношения к удалённым открытым файлам. Никакого.
obidno, pravda? Nu hot' by kto-to v .diff'chik glianul.. eto zh text, tam vse napisano... Eh, novorusskie adminy, negramotnye...
А тем временем в RELENG_6_0 прошёл не хилый такой MFC связанный с ffs и vfs:
http://docs.freebsd.org/cgi/getmsg.cgi?fetch=1114104+0+curre...