|
| 1.2, UserSU (?), 15:27, 28/10/2005 [ответить] [﹢﹢﹢] [ · · · ]
| +/– | |
Много где и на разных дисках использую SU и ни где еще не встречался с этой багой - не зашел бы на опеннет и не узнал бы ни когда... | | |
| |
| 2.3, Maxim Chirkov (ok), 15:40, 28/10/2005 [^] [^^] [^^^] [ответить]
| +/– |
 >Много где и на разных дисках использую SU и ни где еще
>не встречался с этой багой - не зашел бы на опеннет
>и не узнал бы ни когда...
На сервере на котором работает opennet.ru, кстати, softupdates именно по этой причине отключены.
| | |
| |
| 3.32, Maxim (??), 17:30, 29/10/2005 [^] [^^] [^^^] [ответить]
| +/– | |
У меня такое было когда MySQL был сильно нагружен, загрузка процессора была долгое время 100%. Когда пересмотрел задачу и снизил число запросов - место перестало исчезать | | |
| |
| 4.35, Maxim Chirkov (ok), 22:02, 29/10/2005 [^] [^^] [^^^] [ответить]
| +/– |
>У меня такое было когда MySQL был сильно нагружен, загрузка процессора была
>долгое время 100%. Когда пересмотрел задачу и снизил число запросов -
>место перестало исчезать
Речь идет о ситуации когда после того как руками создал файл и удалил его, число свободныех инод не увеличивается (после истечения metadelay и sync;sleep 1;sync;sleep 1;sync;sleep 1;sync). И так для каждого удаления, пока места или инод не останется.
| | |
|
|
|
| 1.4, BatYa (?), 15:49, 28/10/2005 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
>Много где и на разных дисках использую SU и ни где
>еще не встречался с этой багой - не зашел бы на
>опеннет и не узнал бы ни когда...
Сталкивался неоднократно на нескольких серверах. Вдруг начинает кончаться место. Чистишь диск - а места все меньше. А после перезагрузки -- десяток гигов свободных вылезает... Так что, UserSU, Вам повезло... Или сервера у Вас не особо напрягаются. | | |
| 1.5, Nerian (?), 16:36, 28/10/2005 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
 А я насколько помню это происходила когда удалишь что то что в этот момент было октрыто на чтение. Тогда он как бы удалялся, но остовался до момента закрытия той программы которая открывает. А т.к. многие новички логи удаляют обычным rm а не через newsyslog/logrotate (например любят логи squid так удалять rm и всё), то место было зарезирвировано до окончания работы процесса. Сообственно перезагрузка помогала.
А что интересно так это по какому принципу разделы freebsd уходят в минуса? :) Тоесть бывало видел в /tmp свободно -10% )) | | |
| |
| 2.6, Maxim Chirkov (ok), 16:44, 28/10/2005 [^] [^^] [^^^] [ответить]
| +/– |
>А я насколько помню это происходила когда удалишь что то что
>в этот момент было октрыто на чтение.
Нет, проблема не имеет к этому отношения. Это реальная утечка инод в никуда.
На opennet, проявлялось раз в месяца два в момент ночных переиндексаций поисковых баз, когда создавались, копировались и удалялись файлы размеров мегабайт по 500. В один прекрасный момент, после такой переиндексации, место переставало освобождаться после любого удаления файла.
Поищите в архиве форума, там подобные проблемы не раз описывались.
| | |
| 2.7, andreyn (??), 17:14, 28/10/2005 [^] [^^] [^^^] [ответить]
| +/– |
>это происходила когда удалишь что то что в этот момент было октрыто на чтение. >Тогда он как бы удалялся, но остовался до момента закрытия той программы > то
>.........
>место было зарезирвировано до окончания работы процесса. Сообственно >перезагрузка помогала.которая открывает.
То, что вы говорите, это совершенно нормальное поведение любого *NIX-а. При удалении открытого файла, удаляется только запись в каталоге. Реальное освобождение inode происходит, когда обнуляется счётчик числа открытий файла.
| | |
| 2.10, _Nick_ (??), 19:59, 28/10/2005 [^] [^^] [^^^] [ответить]
| +/– |
> А что интересно так это по какому принципу разделы freebsd уходят в
> минуса? :) Тоесть бывало видел в /tmp свободно -10% ))
вот расстраивает не сколько обсасывание надуманых проблем кривых ядер, как ламерство среди юниксоидов вообще.
В UFS при создании резервируется место (точно не помню сколько именно, может как раз эти 10%) "для рута". Остальное место считается полным размером ФС. Итого df показывает 100% занятости ФС при рельной занятости 90%. И никто кроме рута тогда не может писать на этот раздел. (Кривой костыль a-la quota. Кстати, в ext2/3 линоховых тоже такое убожество есть).
А вот когда рутовый squid продолжает писать логи далее "100"% - то команда df выдаст и -1% и -10% свободно. Хоть в Линухе такого ужаса нет. Просто 0 своб. места и все. | | |
| |
| 3.13, Torsmo (?), 20:58, 28/10/2005 [^] [^^] [^^^] [ответить]
| +/– | |
Рутовый сквид? Да вам не 'кривыми костылями' и 'убожествими' разбрасываться, вам в детский сад надо :)) | | |
| |
| 4.14, _Nick_ (??), 21:35, 28/10/2005 [^] [^^] [^^^] [ответить]
| +/– |
>Рутовый сквид? Да вам не 'кривыми костылями' и 'убожествими' разбрасываться, вам в
>детский сад надо :))
да. забыл. давно дело было. кажись внатуре от 'squid'а был | | |
| 4.27, CrazyF (?), 12:54, 29/10/2005 [^] [^^] [^^^] [ответить]
| +/– | |
>Рутовый сквид? Да вам не 'кривыми костылями' и 'убожествими' разбрасываться, вам в детский сад надо :))
Согласен, воинствующий ламериз, присущий данному индивиду, просто поражает. Что ни слово, так прямо БОЖЕСТВЕННОЕ ОТКРОВЕНИЕ и ИСТИНА В ПОСЛЕДНЕЙ ИНСТАНЦИИ. | | |
|
| 3.26, kww (?), 11:49, 29/10/2005 [^] [^^] [^^^] [ответить]
| +/– |
 а вообще-то _Nick_ прав про ламерство,
есть еще такая штука, как tunefs, которй пользовались в 4.x Free для включения софтапдейта (это в 5.х включено по умолчанию), так вот если внимательно прочитать nam tunefs, то там есть описание ключика -m
RTFM всем кто спрашивает про свободное место... | | |
| 3.39, butcher (ok), 16:41, 31/10/2005 [^] [^^] [^^^] [ответить]
| +/– |
>В UFS при создании резервируется место (точно не помню сколько именно, может
>как раз эти 10%) "для рута". Остальное место считается полным размером
>ФС. Итого df показывает 100% занятости ФС при рельной занятости 90%.
>И никто кроме рута тогда не может писать на этот раздел.
>(Кривой костыль a-la quota. Кстати, в ext2/3 линоховых тоже такое убожество
>есть).
Для справки. Это место резервируется не для root'а, а для служебных нужд файловой системы. Файловая система при наличии этого свободного места более оптимально распределяет свободные блоки, в результате чего сводится к минимуму фрагментация файлов. Установка этого параметра менее 5% отключает алгоритм оптимизации, в результате чего вы полусаете больший процен фрагментации => снижение скорости. | | |
|
| 2.40, chip (ok), 20:43, 31/10/2005 [^] [^^] [^^^] [ответить]
| +/– |
 >А что интересно так это по какому принципу разделы freebsd уходят в
>минуса? :) Тоесть бывало видел в /tmp свободно -10% ))
man tunefs /-m
| | |
|
| 1.11, lexa (??), 20:32, 28/10/2005 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
 Сейчас начнут красноглазые...
Страшно в первый раз было когда увидел -9%
Потом su выключил. и все в шоколаде. досадно думаю в 6 исправят.
Это не баг, а не совсем верно реализованая фича | | |
| |
| 2.12, Аноним (12), 20:40, 28/10/2005 [^] [^^] [^^^] [ответить]
| +/– |
 Люди, всегда читал что на опеннете на порядок меньше тупых плстов, не разубеждайте меня pls. Почему минус - все есть в доках.
Что касается темы треда - то надеюсь что пач действительно работает и данная проблемма наконец уйдет из фришки. | | |
|
| 1.15, Otto Katz Feldkurat (?), 21:47, 28/10/2005 [ответить] [﹢﹢﹢] [ · · · ]
| +/– | |
В куду этот патч?
> В 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 тоже.
| | |
| |
| 2.16, Игорь Сысоев (?), 22:04, 28/10/2005 [^] [^^] [^^^] [ответить]
| +/– |
4.11-RELEASE-p13 - это RELENG_4_11, а 4.11-STABLE - это RELENG_4.
В RELENG_4_11 исправления нет. С точки зрения security team это несерьёзная ошибка. Вот мифическая дыра в HTT - это совсем другое дело. | | |
| |
| 3.18, vip3r (?), 22:42, 28/10/2005 [^] [^^] [^^^] [ответить]
| +/– |
 Последнее время все чаще сталкиваюсь с мыслью, что в core есть таки фанаты Solaris: такая вот накатка на релиз лишь патчей связанных с безопасностью, но не обычными багами; написали pkill, pgrep... | | |
| 3.23, Free (??), 09:32, 29/10/2005 [^] [^^] [^^^] [ответить]
| +/– | |
Чего-то не понял. Написано, что патч для ранних версий, и что для FreeBSD 4.11-STABLE, FreeBSD 5.4-STABLE и FreeBSD 6.0-BETA исправления сделаны в августе.
А теперь написано, что надо таки патчить 4.11. Ничего не понял... | | |
| |
| 4.25, Игорь Сысоев (?), 11:18, 29/10/2005 [^] [^^] [^^^] [ответить]
| +/– |
4.11-RELEASE с security update'ами - это не FreeBSD 4.11-STABLE.
В 4.11-RELEASE-p13 и 5.4-RELEASE-p8 ошибка осталась.
В будущей 6.0-RELEASE её не будет. | | |
|
|
|
| 1.20, Otto Katz Feldkurat (?), 23:04, 28/10/2005 [ответить] [﹢﹢﹢] [ · · · ]
| +/– | |
Ляжет/не ляжет.
Был флейм насчет адаптековских рейдов - винили их в том, что mySQL из-за них вешает систему на большой нагрузке. Но похоже дело именно в softupdates. | | |
| |
| 2.29, McLone (?), 13:59, 29/10/2005 [^] [^^] [^^^] [ответить]
| +/– | |
da net, taki veshaet, i ne tol'ko mysql. U menya i postgre veshal. | | |
| |
| 3.31, Otto Katz Feldkurat (?), 14:19, 29/10/2005 [^] [^^] [^^^] [ответить]
| +/– |
Посмотрим. Условия в которых оно вешается, примерно известны.
Когда в заросе есть JOIN mySQL пишет временную таблицу строго на диск.
Заставить mySQL не писать JOIN в /tmp не сумел.
Сильно похоже на потерю нодов софтапдейтом.
Если за следующую неделю сервис снова висанёт, значит софтапдейтс не при чем. | | |
| |
| |
| 5.38, Otto Katz Feldkurat (?), 22:31, 29/10/2005 [^] [^^] [^^^] [ответить]
| +/– | |
если включть query_cache_type=1, то до тех пор, пока не исчерпается query_cache_size=xxx повторные запросы (те, что уже попали в кэш) не создают временных файлов. Но в первый раз на любой запрос временный файл на диске все равно создается! | | |
|
|
|
|
| 1.21, gvf (?), 23:40, 28/10/2005 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
правы ораторы - Nerian и andreyn, если предварительно обнулить файл и лишь потом стереть - потери места не наблюдается.
Вывод: перед удалением echo > file и телемаркет.
Хотя решение проблемы напрямую, все же радует. | | |
| |
| 2.37, Maxim Chirkov (ok), 22:15, 29/10/2005 [^] [^^] [^^^] [ответить]
| +/– |
>правы ораторы - Nerian и andreyn, если предварительно обнулить файл и лишь
>потом стереть - потери места не наблюдается.
Наблюдается. Вы не о той потере места говорите. Не путайте тривиальное незакрытие файла после unlink'а, которое сразу видно в fstat, и проблему softupdates, для которой и выпущен данный патч и которая странным и трудноповторимым образом проявлялась, раз в полгода, на серверах интенсивно оперирующих большими файлами.
| | |
|
| 1.22, gvf (?), 23:43, 28/10/2005 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
да, еще в добавок:
нет нужды перегружать систему, достаточно убить процесс держащий откртыми эти файлы...
я надеюсь ни у кого нет ядра открывшего
файл на 5 Гб :)))
| | |
| |
| |
| 3.30, McLone (?), 14:00, 29/10/2005 [^] [^^] [^^^] [ответить]
| +/– | |
obidno, pravda? Nu hot' by kto-to v .diff'chik glianul.. eto zh text, tam vse napisano... Eh, novorusskie adminy, negramotnye... | | |
|
|
|
