forum.opennet.ru - "OpenNews: Патч для предотвращения исчезновения свободного ме..." (37)

форумы

помощь

поиск

регистрация

майллист

ВХОД

слежка

"OpenNews: Патч для предотвращения исчезновения свободного ме..."

Форумы Разговоры, обсуждение новостей (Public)
Вариант для распечатки		Архивированная нить - только для чтения! Пред. тема \| След. тема
Изначальное сообщение		[Проследить за развитием треда]

"OpenNews: Патч для предотвращения исчезновения свободного ме..."
Сообщение от opennews (ok) on 28-Окт-05, 13:53
Игорь Сысоев оформил в виде патча (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.dev/opennews/art.shtml?num=6327
Cообщить модератору \| Наверх \| ^

Оглавление

Патч для предотвращения исчезновения свободного места под Fr..., Moralez, 13:53 , 28-Окт-05, (1)
Патч для предотвращения исчезновения свободного места под Fr..., UserSU, 15:27 , 28-Окт-05, (2)

Патч для предотвращения исчезновения свободного места под Fr..., Maxim Chirkov, 15:40 , 28-Окт-05, (3)

Патч для предотвращения исчезновения свободного места под Fr..., Maxim, 17:30 , 29-Окт-05, (32)

Патч для предотвращения исчезновения свободного места под Fr..., Maxim Chirkov, 22:02 , 29-Окт-05, (35)

Патч для предотвращения исчезновения свободного места под Fr..., BatYa, 15:49 , 28-Окт-05, (4)
Патч для предотвращения исчезновения свободного места под Fr..., Nerian, 16:36 , 28-Окт-05, (5)

Патч для предотвращения исчезновения свободного места под Fr..., Maxim Chirkov, 16:44 , 28-Окт-05, (6)
Патч для предотвращения исчезновения свободного места под Fr..., andreyn, 17:14 , 28-Окт-05, (7)
Патч для предотвращения исчезновения свободного места под Fr..., _Nick_, 19:59 , 28-Окт-05, (10)

Патч для предотвращения исчезновения свободного места под Fr..., Torsmo, 20:58 , 28-Окт-05, (13)

Патч для предотвращения исчезновения свободного места под Fr..., _Nick_, 21:35 , 28-Окт-05, (14)
Патч для предотвращения исчезновения свободного места под Fr..., CrazyF, 12:54 , 29-Окт-05, (27)

Патч для предотвращения исчезновения свободного места под Fr..., kww, 11:49 , 29-Окт-05, (26)
Патч для предотвращения исчезновения свободного места под Fr..., butcher, 16:41 , 31-Окт-05, (39)

Патч для предотвращения исчезновения свободного места под Fr..., chip, 20:43 , 31-Окт-05, (40)

Патч для предотвращения исчезновения свободного места под Fr..., томми, 19:44 , 28-Окт-05, (8)
Патч для предотвращения исчезновения свободного места под Fr..., lexa, 20:32 , 28-Окт-05, (11)

Патч для предотвращения исчезновения свободного места под Fr..., Аноним, 20:40 , 28-Окт-05, (12)

Чего-то я не догоняю., Otto Katz Feldkurat, 21:47 , 28-Окт-05, (15)

Чего-то я не догоняю., Игорь Сысоев, 22:04 , 28-Окт-05, (16)

Чего-то я не догоняю., vip3r, 22:42 , 28-Окт-05, (18)
Чего-то я не догоняю., Free, 09:32 , 29-Окт-05, (23)

Чего-то я не догоняю., Игорь Сысоев, 11:18 , 29-Окт-05, (25)

Дык? Ядро загрузится?, Otto Katz Feldkurat, 22:27 , 28-Окт-05, (17)

Дык? Ядро загрузится?, Игорь Сысоев, 22:54 , 28-Окт-05, (19)

Уже. Подождем нагрузки., Otto Katz Feldkurat, 23:04 , 28-Окт-05, (20)

Уже. Подождем нагрузки., McLone, 13:59 , 29-Окт-05, (29)

taki veshaet?, Otto Katz Feldkurat, 14:19 , 29-Окт-05, (31)

taki veshaet?, si, 21:07 , 29-Окт-05, (34)

tmp_table_size - три часа на парУ и не берёт!, Otto Katz Feldkurat, 22:31 , 29-Окт-05, (38)

Патч для предотвращения исчезновения свободного места под Fr..., gvf, 23:40 , 28-Окт-05, (21)

Патч для предотвращения исчезновения свободного места под Fr..., Maxim Chirkov, 22:15 , 29-Окт-05, (37)

Патч для предотвращения исчезновения свободного места под Fr..., gvf, 23:43 , 28-Окт-05, (22)

Патч для предотвращения исчезновения свободного места под Fr..., Игорь Сысоев, 11:12 , 29-Окт-05, (24)

Патч для предотвращения исчезновения свободного места под Fr..., McLone, 14:00 , 29-Окт-05, (30)

Патч для предотвращения исчезновения свободного места под Fr..., аноним, 18:55 , 29-Окт-05, (33)

Сообщения по теме [Сортировка по времени, UBB]

1. "Патч для предотвращения исчезновения свободного места под Fr..."

Сообщение от Moralez (ok) on 28-Окт-05, 13:53

Бррр.... Вообще-то это фича SU... С трудом верится. :-\

Cообщить модератору | Наверх | ^

2. "Патч для предотвращения исчезновения свободного места под Fr..."

Сообщение от UserSU on 28-Окт-05, 15:27

Много где и на разных дисках использую SU и ни где еще не встречался с этой багой - не зашел бы на опеннет и не узнал бы ни когда...

Cообщить модератору | Наверх | ^

3. "Патч для предотвращения исчезновения свободного места под Fr..."

Сообщение от Maxim Chirkov (ok) on 28-Окт-05, 15:40

>Много где и на разных дисках использую SU и ни где еще
>не встречался с этой багой - не зашел бы на опеннет
>и не узнал бы ни когда...
На сервере на котором работает opennet.ru, кстати, softupdates именно по этой причине отключены.

Cообщить модератору | Наверх | ^

32. "Патч для предотвращения исчезновения свободного места под Fr..."

Сообщение от Maxim (??) on 29-Окт-05, 17:30

У меня такое было когда MySQL был сильно нагружен, загрузка процессора была долгое время 100%. Когда пересмотрел задачу и снизил число запросов - место перестало исчезать

Cообщить модератору | Наверх | ^

35. "Патч для предотвращения исчезновения свободного места под Fr..."

Сообщение от Maxim Chirkov (ok) on 29-Окт-05, 22:02

>У меня такое было когда MySQL был сильно нагружен, загрузка процессора была
>долгое время 100%. Когда пересмотрел задачу и снизил число запросов -
>место перестало исчезать
Речь идет о ситуации когда после того как руками создал файл и удалил его, число свободныех инод не увеличивается (после истечения metadelay и sync;sleep 1;sync;sleep 1;sync;sleep 1;sync). И так для каждого удаления, пока места или инод не останется.

Cообщить модератору | Наверх | ^

4. "Патч для предотвращения исчезновения свободного места под Fr..."

Сообщение от BatYa on 28-Окт-05, 15:49

>Много где и на разных дисках использую SU и ни где
>еще не встречался с этой багой - не зашел бы на
>опеннет и не узнал бы ни когда...
Сталкивался неоднократно на нескольких серверах. Вдруг начинает кончаться место. Чистишь диск - а места все меньше. А после перезагрузки -- десяток гигов свободных вылезает... Так что, UserSU, Вам повезло... Или сервера у Вас не особо напрягаются.

Cообщить модератору | Наверх | ^

5. "Патч для предотвращения исчезновения свободного места под Fr..."

Сообщение от Nerian on 28-Окт-05, 16:36

А я насколько помню  это происходила когда удалишь что то что в этот момент было октрыто на чтение. Тогда он как бы удалялся, но остовался до момента закрытия той программы которая открывает. А т.к. многие новички логи удаляют обычным rm а не через newsyslog/logrotate (например любят логи squid так удалять rm и всё), то место было зарезирвировано до окончания работы процесса. Сообственно перезагрузка помогала.
А что интересно так это по какому принципу разделы freebsd уходят в минуса? :) Тоесть бывало видел в /tmp свободно -10% ))

Cообщить модератору | Наверх | ^

6. "Патч для предотвращения исчезновения свободного места под Fr..."

Сообщение от Maxim Chirkov (ok) on 28-Окт-05, 16:44

>А я насколько помню  это происходила когда удалишь что то что
>в этот момент было октрыто на чтение.
Нет, проблема не имеет к этому отношения. Это реальная утечка инод в никуда.
На opennet, проявлялось раз в месяца два в момент ночных переиндексаций поисковых баз, когда создавались, копировались и удалялись файлы размеров мегабайт по 500. В один прекрасный момент, после такой переиндексации, место переставало освобождаться после любого удаления файла.
Поищите в архиве форума, там подобные проблемы не раз описывались.

Cообщить модератору | Наверх | ^

7. "Патч для предотвращения исчезновения свободного места под Fr..."

Сообщение от andreyn (??) on 28-Окт-05, 17:14

>это происходила когда удалишь что то что в этот момент было октрыто на чтение. >Тогда он как бы удалялся, но остовался до момента закрытия той программы > то
>.........
>место было зарезирвировано до окончания работы процесса. Сообственно >перезагрузка помогала.которая открывает.
То, что вы говорите, это совершенно нормальное поведение любого *NIX-а. При удалении открытого файла, удаляется только запись в каталоге. Реальное освобождение inode происходит, когда обнуляется счётчик числа открытий файла.

Cообщить модератору | Наверх | ^

10. "Патч для предотвращения исчезновения свободного места под Fr..."

Сообщение от _Nick_ (??) on 28-Окт-05, 19:59

> А что интересно так это по какому принципу разделы freebsd уходят в
> минуса? :) Тоесть бывало видел в /tmp свободно -10% ))
вот расстраивает не сколько обсасывание надуманых проблем кривых ядер,  как ламерство среди юниксоидов вообще.
В UFS при создании резервируется место (точно не помню сколько именно, может как раз эти 10%) "для рута". Остальное место считается полным размером ФС. Итого df показывает 100% занятости ФС при рельной занятости 90%. И никто кроме рута тогда не может писать на этот раздел. (Кривой костыль a-la quota. Кстати, в ext2/3 линоховых тоже такое убожество есть).
А вот когда рутовый squid продолжает писать логи далее "100"% - то команда df выдаст и -1% и -10% свободно. Хоть в Линухе такого ужаса нет. Просто 0 своб. места и все.

Cообщить модератору | Наверх | ^

13. "Патч для предотвращения исчезновения свободного места под Fr..."

Сообщение от Torsmo on 28-Окт-05, 20:58

Рутовый сквид? Да вам не `кривыми костылями' и `убожествими' разбрасываться, вам в детский сад надо :))

Cообщить модератору | Наверх | ^

14. "Патч для предотвращения исчезновения свободного места под Fr..."

Сообщение от _Nick_ (??) on 28-Окт-05, 21:35

>Рутовый сквид? Да вам не `кривыми костылями' и `убожествими' разбрасываться, вам в
>детский сад надо :))
да. забыл. давно дело было. кажись внатуре от 'squid'а был

Cообщить модератору | Наверх | ^

27. "Патч для предотвращения исчезновения свободного места под Fr..."

Сообщение от CrazyF on 29-Окт-05, 12:54

>Рутовый сквид? Да вам не `кривыми костылями' и `убожествими' разбрасываться, вам в детский сад надо :))
Согласен, воинствующий ламериз, присущий данному индивиду, просто поражает. Что ни слово, так прямо БОЖЕСТВЕННОЕ ОТКРОВЕНИЕ и ИСТИНА В ПОСЛЕДНЕЙ ИНСТАНЦИИ.

Cообщить модератору | Наверх | ^

26. "Патч для предотвращения исчезновения свободного места под Fr..."

Сообщение от kww on 29-Окт-05, 11:49

а вообще-то _Nick_ прав про ламерство,
есть еще такая штука, как tunefs, которй пользовались в 4.x Free для включения софтапдейта (это в 5.х включено по умолчанию), так вот если внимательно прочитать nam tunefs, то там есть описание ключика -m
RTFM всем кто спрашивает про свободное место...

Cообщить модератору | Наверх | ^

39. "Патч для предотвращения исчезновения свободного места под Fr..."

Сообщение от butcher (ok) on 31-Окт-05, 16:41

>В UFS при создании резервируется место (точно не помню сколько именно, может
>как раз эти 10%) "для рута". Остальное место считается полным размером
>ФС. Итого df показывает 100% занятости ФС при рельной занятости 90%.
>И никто кроме рута тогда не может писать на этот раздел.
>(Кривой костыль a-la quota. Кстати, в ext2/3 линоховых тоже такое убожество
>есть).
Для справки. Это место резервируется не для root'а, а для служебных нужд файловой системы. Файловая система при наличии этого свободного места более оптимально распределяет свободные блоки, в результате чего сводится к минимуму фрагментация файлов. Установка этого параметра менее 5% отключает алгоритм оптимизации, в результате чего вы полусаете больший процен фрагментации => снижение скорости.

Cообщить модератору | Наверх | ^

40. "Патч для предотвращения исчезновения свободного места под Fr..."

Сообщение от chip (ok) on 31-Окт-05, 20:43

>А что интересно так это по какому принципу разделы freebsd уходят в
>минуса? :) Тоесть бывало видел в /tmp свободно -10% ))
man tunefs /-m

Cообщить модератору | Наверх | ^

8. "Патч для предотвращения исчезновения свободного места под Fr..."

Сообщение от томми on 28-Окт-05, 19:44

Было такое. было. сам я не понимал что это от sostupdates

Cообщить модератору | Наверх | ^

11. "Патч для предотвращения исчезновения свободного места под Fr..."

Сообщение от lexa (??) on 28-Окт-05, 20:32

Сейчас начнут красноглазые...
Страшно в первый раз было когда увидел -9%
Потом su выключил. и все в шоколаде. досадно думаю в 6 исправят.
Это не баг, а не совсем верно реализованая фича

Cообщить модератору | Наверх | ^

12. "Патч для предотвращения исчезновения свободного места под Fr..."

Сообщение от Аноним on 28-Окт-05, 20:40

Люди, всегда читал что на опеннете на порядок меньше тупых плстов, не разубеждайте меня pls. Почему минус - все есть в доках.
Что касается темы треда - то надеюсь что пач действительно работает и данная проблемма наконец уйдет из фришки.

Cообщить модератору | Наверх | ^

15. "Чего-то я не догоняю."

Сообщение от Otto Katz Feldkurat on 28-Окт-05, 21:47

В куду этот патч?
> В 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 тоже.

Cообщить модератору | Наверх | ^

16. "Чего-то я не догоняю."

Сообщение от Игорь Сысоев on 28-Окт-05, 22:04

4.11-RELEASE-p13 - это RELENG_4_11, а 4.11-STABLE - это RELENG_4.
В RELENG_4_11 исправления нет. С точки зрения security team это несерьёзная ошибка. Вот мифическая дыра в HTT - это совсем другое дело.

Cообщить модератору | Наверх | ^

18. "Чего-то я не догоняю."

Сообщение от vip3r on 28-Окт-05, 22:42

Последнее время все чаще сталкиваюсь с мыслью, что в core есть таки фанаты Solaris: такая вот накатка на релиз лишь патчей связанных с безопасностью, но не обычными багами; написали pkill, pgrep...

Cообщить модератору | Наверх | ^

23. "Чего-то я не догоняю."

Сообщение от Free (??) on 29-Окт-05, 09:32

Чего-то не понял. Написано, что патч для ранних версий, и что для FreeBSD 4.11-STABLE, FreeBSD 5.4-STABLE и FreeBSD 6.0-BETA исправления сделаны в августе.
А теперь написано, что надо таки патчить 4.11. Ничего не понял...

Cообщить модератору | Наверх | ^

25. "Чего-то я не догоняю."

Сообщение от Игорь Сысоев on 29-Окт-05, 11:18

4.11-RELEASE с security update'ами - это не FreeBSD 4.11-STABLE.
В 4.11-RELEASE-p13 и 5.4-RELEASE-p8 ошибка осталась.
В будущей 6.0-RELEASE её не будет.

Cообщить модератору | Наверх | ^

17. "Дык? Ядро загрузится?"

Сообщение от Otto Katz Feldkurat on 28-Окт-05, 22:27

А то ломает ехать на площадку, если что.
4.11-RELEASE-p13 - патчить можно?

Cообщить модератору | Наверх | ^

19. "Дык? Ядро загрузится?"

Сообщение от Игорь Сысоев on 28-Окт-05, 22:54

Не можно, а нужно.

Cообщить модератору | Наверх | ^

20. "Уже. Подождем нагрузки."

Сообщение от Otto Katz Feldkurat on 28-Окт-05, 23:04

Ляжет/не ляжет.
Был флейм насчет адаптековских рейдов - винили их в том, что mySQL из-за них вешает систему на большой нагрузке. Но похоже дело именно в softupdates.

Cообщить модератору | Наверх | ^

29. "Уже. Подождем нагрузки."

Сообщение от McLone on 29-Окт-05, 13:59

da net, taki veshaet, i ne tol'ko mysql. U menya i postgre veshal.

Cообщить модератору | Наверх | ^

31. "taki veshaet?"

Сообщение от Otto Katz Feldkurat on 29-Окт-05, 14:19

Посмотрим. Условия в которых оно вешается, примерно известны.
Когда в заросе есть JOIN mySQL пишет временную таблицу строго на диск.
Заставить mySQL не писать JOIN в /tmp не сумел.
Сильно похоже на потерю нодов софтапдейтом.
Если за следующую неделю сервис снова висанёт, значит софтапдейтс не при чем.

Cообщить модератору | Наверх | ^

34. "taki veshaet?"

Сообщение от si on 29-Окт-05, 21:07

по пробуйте покрутить tmp_table_size

Cообщить модератору | Наверх | ^

38. "tmp_table_size - три часа на парУ и не берёт!"

Сообщение от Otto Katz Feldkurat on 29-Окт-05, 22:31

если включть query_cache_type=1, то до тех пор, пока не исчерпается query_cache_size=xxx повторные запросы (те, что уже попали в кэш) не создают временных файлов. Но в первый раз на любой запрос временный файл на диске все равно создается!

Cообщить модератору | Наверх | ^

21. "Патч для предотвращения исчезновения свободного места под Fr..."

Сообщение от gvf on 28-Окт-05, 23:40

правы ораторы - Nerian и andreyn, если предварительно обнулить файл и лишь потом стереть - потери места не наблюдается.
Вывод: перед удалением echo > file и телемаркет.
Хотя решение проблемы напрямую, все же радует.

Cообщить модератору | Наверх | ^

37. "Патч для предотвращения исчезновения свободного места под Fr..."

Сообщение от Maxim Chirkov (ok) on 29-Окт-05, 22:15

>правы ораторы - Nerian и andreyn, если предварительно обнулить файл и лишь
>потом стереть - потери места не наблюдается.
Наблюдается. Вы не о той потере места говорите. Не путайте тривиальное незакрытие файла после unlink'а, которое сразу видно в fstat, и проблему softupdates, для которой и выпущен данный патч и которая странным и трудноповторимым образом проявлялась, раз в полгода, на серверах интенсивно оперирующих большими файлами.

Cообщить модератору | Наверх | ^

22. "Патч для предотвращения исчезновения свободного места под Fr..."

Сообщение от gvf on 28-Окт-05, 23:43

да, еще в добавок:
нет нужды перегружать систему, достаточно убить процесс держащий откртыми эти файлы...
я надеюсь ни у кого нет ядра открывшего
файл на 5 Гб :)))

Cообщить модератору | Наверх | ^

24. "Патч для предотвращения исчезновения свободного места под Fr..."

Сообщение от Игорь Сысоев on 29-Окт-05, 11:12

Исправленная ошибка не имеет никакого отношения к удалённым открытым файлам. Никакого.

Cообщить модератору | Наверх | ^

30. "Патч для предотвращения исчезновения свободного места под Fr..."

Сообщение от McLone on 29-Окт-05, 14:00

obidno, pravda? Nu hot' by kto-to v .diff'chik glianul.. eto zh text, tam vse napisano... Eh, novorusskie adminy, negramotnye...

Cообщить модератору | Наверх | ^

33. "Патч для предотвращения исчезновения свободного места под Fr..."

Сообщение от аноним on 29-Окт-05, 18:55

А тем временем в RELENG_6_0 прошёл не хилый такой MFC связанный с ffs и vfs:
http://docs.freebsd.org/cgi/getmsg.cgi?fetch=1114104+0+current/cvs-src#content

Cообщить модератору | Наверх | ^

Удалить

Индекс форумов | Темы | Пред. тема | След. тема

Партнёры:

Хостинг:

Закладки на сайте
Проследить за страницей

Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру

1. "Патч для предотвращения исчезновения свободного места под Fr..."
Сообщение от Moralez (ok) on 28-Окт-05, 13:53
Бррр.... Вообще-то это фича SU... С трудом верится. :-\
Cообщить модератору \| Наверх \| ^

2. "Патч для предотвращения исчезновения свободного места под Fr..."
Сообщение от UserSU on 28-Окт-05, 15:27
Много где и на разных дисках использую SU и ни где еще не встречался с этой багой - не зашел бы на опеннет и не узнал бы ни когда...
Cообщить модератору \| Наверх \| ^


	3. "Патч для предотвращения исчезновения свободного места под Fr..."
	Сообщение от Maxim Chirkov (ok) on 28-Окт-05, 15:40
	>Много где и на разных дисках использую SU и ни где еще >не встречался с этой багой - не зашел бы на опеннет >и не узнал бы ни когда... На сервере на котором работает opennet.ru, кстати, softupdates именно по этой причине отключены.
	Cообщить модератору \| Наверх \| ^


	32. "Патч для предотвращения исчезновения свободного места под Fr..."
	Сообщение от Maxim (??) on 29-Окт-05, 17:30
	У меня такое было когда MySQL был сильно нагружен, загрузка процессора была долгое время 100%. Когда пересмотрел задачу и снизил число запросов - место перестало исчезать
	Cообщить модератору \| Наверх \| ^


	35. "Патч для предотвращения исчезновения свободного места под Fr..."
	Сообщение от Maxim Chirkov (ok) on 29-Окт-05, 22:02
	>У меня такое было когда MySQL был сильно нагружен, загрузка процессора была >долгое время 100%. Когда пересмотрел задачу и снизил число запросов - >место перестало исчезать Речь идет о ситуации когда после того как руками создал файл и удалил его, число свободныех инод не увеличивается (после истечения metadelay и sync;sleep 1;sync;sleep 1;sync;sleep 1;sync). И так для каждого удаления, пока места или инод не останется.
	Cообщить модератору \| Наверх \| ^

4. "Патч для предотвращения исчезновения свободного места под Fr..."
Сообщение от BatYa on 28-Окт-05, 15:49
>Много где и на разных дисках использую SU и ни где >еще не встречался с этой багой - не зашел бы на >опеннет и не узнал бы ни когда... Сталкивался неоднократно на нескольких серверах. Вдруг начинает кончаться место. Чистишь диск - а места все меньше. А после перезагрузки -- десяток гигов свободных вылезает... Так что, UserSU, Вам повезло... Или сервера у Вас не особо напрягаются.
Cообщить модератору \| Наверх \| ^

5. "Патч для предотвращения исчезновения свободного места под Fr..."
Сообщение от Nerian on 28-Окт-05, 16:36
А я насколько помню это происходила когда удалишь что то что в этот момент было октрыто на чтение. Тогда он как бы удалялся, но остовался до момента закрытия той программы которая открывает. А т.к. многие новички логи удаляют обычным rm а не через newsyslog/logrotate (например любят логи squid так удалять rm и всё), то место было зарезирвировано до окончания работы процесса. Сообственно перезагрузка помогала. А что интересно так это по какому принципу разделы freebsd уходят в минуса? :) Тоесть бывало видел в /tmp свободно -10% ))
Cообщить модератору \| Наверх \| ^


	6. "Патч для предотвращения исчезновения свободного места под Fr..."
	Сообщение от Maxim Chirkov (ok) on 28-Окт-05, 16:44
	>А я насколько помню это происходила когда удалишь что то что >в этот момент было октрыто на чтение. Нет, проблема не имеет к этому отношения. Это реальная утечка инод в никуда. На opennet, проявлялось раз в месяца два в момент ночных переиндексаций поисковых баз, когда создавались, копировались и удалялись файлы размеров мегабайт по 500. В один прекрасный момент, после такой переиндексации, место переставало освобождаться после любого удаления файла. Поищите в архиве форума, там подобные проблемы не раз описывались.
	Cообщить модератору \| Наверх \| ^


	7. "Патч для предотвращения исчезновения свободного места под Fr..."
	Сообщение от andreyn (??) on 28-Окт-05, 17:14
	>это происходила когда удалишь что то что в этот момент было октрыто на чтение. >Тогда он как бы удалялся, но остовался до момента закрытия той программы > то >......... >место было зарезирвировано до окончания работы процесса. Сообственно >перезагрузка помогала.которая открывает. То, что вы говорите, это совершенно нормальное поведение любого *NIX-а. При удалении открытого файла, удаляется только запись в каталоге. Реальное освобождение inode происходит, когда обнуляется счётчик числа открытий файла.
	Cообщить модератору \| Наверх \| ^


	10. "Патч для предотвращения исчезновения свободного места под Fr..."
	Сообщение от _Nick_ (??) on 28-Окт-05, 19:59
	> А что интересно так это по какому принципу разделы freebsd уходят в > минуса? :) Тоесть бывало видел в /tmp свободно -10% )) вот расстраивает не сколько обсасывание надуманых проблем кривых ядер, как ламерство среди юниксоидов вообще. В UFS при создании резервируется место (точно не помню сколько именно, может как раз эти 10%) "для рута". Остальное место считается полным размером ФС. Итого df показывает 100% занятости ФС при рельной занятости 90%. И никто кроме рута тогда не может писать на этот раздел. (Кривой костыль a-la quota. Кстати, в ext2/3 линоховых тоже такое убожество есть). А вот когда рутовый squid продолжает писать логи далее "100"% - то команда df выдаст и -1% и -10% свободно. Хоть в Линухе такого ужаса нет. Просто 0 своб. места и все.
	Cообщить модератору \| Наверх \| ^


	13. "Патч для предотвращения исчезновения свободного места под Fr..."
	Сообщение от Torsmo on 28-Окт-05, 20:58
	Рутовый сквид? Да вам не `кривыми костылями' и `убожествими' разбрасываться, вам в детский сад надо :))
	Cообщить модератору \| Наверх \| ^


	14. "Патч для предотвращения исчезновения свободного места под Fr..."
	Сообщение от _Nick_ (??) on 28-Окт-05, 21:35
	>Рутовый сквид? Да вам не `кривыми костылями' и `убожествими' разбрасываться, вам в >детский сад надо :)) да. забыл. давно дело было. кажись внатуре от 'squid'а был
	Cообщить модератору \| Наверх \| ^


	27. "Патч для предотвращения исчезновения свободного места под Fr..."
	Сообщение от CrazyF on 29-Окт-05, 12:54
	>Рутовый сквид? Да вам не `кривыми костылями' и `убожествими' разбрасываться, вам в детский сад надо :)) Согласен, воинствующий ламериз, присущий данному индивиду, просто поражает. Что ни слово, так прямо БОЖЕСТВЕННОЕ ОТКРОВЕНИЕ и ИСТИНА В ПОСЛЕДНЕЙ ИНСТАНЦИИ.
	Cообщить модератору \| Наверх \| ^


	26. "Патч для предотвращения исчезновения свободного места под Fr..."
	Сообщение от kww on 29-Окт-05, 11:49
	а вообще-то _Nick_ прав про ламерство, есть еще такая штука, как tunefs, которй пользовались в 4.x Free для включения софтапдейта (это в 5.х включено по умолчанию), так вот если внимательно прочитать nam tunefs, то там есть описание ключика -m RTFM всем кто спрашивает про свободное место...
	Cообщить модератору \| Наверх \| ^


	39. "Патч для предотвращения исчезновения свободного места под Fr..."
	Сообщение от butcher (ok) on 31-Окт-05, 16:41
	>В UFS при создании резервируется место (точно не помню сколько именно, может >как раз эти 10%) "для рута". Остальное место считается полным размером >ФС. Итого df показывает 100% занятости ФС при рельной занятости 90%. >И никто кроме рута тогда не может писать на этот раздел. >(Кривой костыль a-la quota. Кстати, в ext2/3 линоховых тоже такое убожество >есть). Для справки. Это место резервируется не для root'а, а для служебных нужд файловой системы. Файловая система при наличии этого свободного места более оптимально распределяет свободные блоки, в результате чего сводится к минимуму фрагментация файлов. Установка этого параметра менее 5% отключает алгоритм оптимизации, в результате чего вы полусаете больший процен фрагментации => снижение скорости.
	Cообщить модератору \| Наверх \| ^


	40. "Патч для предотвращения исчезновения свободного места под Fr..."
	Сообщение от chip (ok) on 31-Окт-05, 20:43
	>А что интересно так это по какому принципу разделы freebsd уходят в >минуса? :) Тоесть бывало видел в /tmp свободно -10% )) man tunefs /-m
	Cообщить модератору \| Наверх \| ^

8. "Патч для предотвращения исчезновения свободного места под Fr..."
Сообщение от томми on 28-Окт-05, 19:44
Было такое. было. сам я не понимал что это от sostupdates
Cообщить модератору \| Наверх \| ^

11. "Патч для предотвращения исчезновения свободного места под Fr..."
Сообщение от lexa (??) on 28-Окт-05, 20:32
Сейчас начнут красноглазые... Страшно в первый раз было когда увидел -9% Потом su выключил. и все в шоколаде. досадно думаю в 6 исправят. Это не баг, а не совсем верно реализованая фича
Cообщить модератору \| Наверх \| ^


	12. "Патч для предотвращения исчезновения свободного места под Fr..."
	Сообщение от Аноним on 28-Окт-05, 20:40
	Люди, всегда читал что на опеннете на порядок меньше тупых плстов, не разубеждайте меня pls. Почему минус - все есть в доках. Что касается темы треда - то надеюсь что пач действительно работает и данная проблемма наконец уйдет из фришки.
	Cообщить модератору \| Наверх \| ^

15. "Чего-то я не догоняю."
Сообщение от Otto Katz Feldkurat on 28-Окт-05, 21:47
В куду этот патч? > В 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 тоже.
Cообщить модератору \| Наверх \| ^


	16. "Чего-то я не догоняю."
	Сообщение от Игорь Сысоев on 28-Окт-05, 22:04
	4.11-RELEASE-p13 - это RELENG_4_11, а 4.11-STABLE - это RELENG_4. В RELENG_4_11 исправления нет. С точки зрения security team это несерьёзная ошибка. Вот мифическая дыра в HTT - это совсем другое дело.
	Cообщить модератору \| Наверх \| ^


	18. "Чего-то я не догоняю."
	Сообщение от vip3r on 28-Окт-05, 22:42
	Последнее время все чаще сталкиваюсь с мыслью, что в core есть таки фанаты Solaris: такая вот накатка на релиз лишь патчей связанных с безопасностью, но не обычными багами; написали pkill, pgrep...
	Cообщить модератору \| Наверх \| ^


	23. "Чего-то я не догоняю."
	Сообщение от Free (??) on 29-Окт-05, 09:32
	Чего-то не понял. Написано, что патч для ранних версий, и что для FreeBSD 4.11-STABLE, FreeBSD 5.4-STABLE и FreeBSD 6.0-BETA исправления сделаны в августе. А теперь написано, что надо таки патчить 4.11. Ничего не понял...
	Cообщить модератору \| Наверх \| ^


	25. "Чего-то я не догоняю."
	Сообщение от Игорь Сысоев on 29-Окт-05, 11:18
	4.11-RELEASE с security update'ами - это не FreeBSD 4.11-STABLE. В 4.11-RELEASE-p13 и 5.4-RELEASE-p8 ошибка осталась. В будущей 6.0-RELEASE её не будет.
	Cообщить модератору \| Наверх \| ^

17. "Дык? Ядро загрузится?"
Сообщение от Otto Katz Feldkurat on 28-Окт-05, 22:27
А то ломает ехать на площадку, если что. 4.11-RELEASE-p13 - патчить можно?
Cообщить модератору \| Наверх \| ^


	19. "Дык? Ядро загрузится?"
	Сообщение от Игорь Сысоев on 28-Окт-05, 22:54
	Не можно, а нужно.
	Cообщить модератору \| Наверх \| ^

20. "Уже. Подождем нагрузки."
Сообщение от Otto Katz Feldkurat on 28-Окт-05, 23:04
Ляжет/не ляжет. Был флейм насчет адаптековских рейдов - винили их в том, что mySQL из-за них вешает систему на большой нагрузке. Но похоже дело именно в softupdates.
Cообщить модератору \| Наверх \| ^


	29. "Уже. Подождем нагрузки."
	Сообщение от McLone on 29-Окт-05, 13:59
	da net, taki veshaet, i ne tol'ko mysql. U menya i postgre veshal.
	Cообщить модератору \| Наверх \| ^


	31. "taki veshaet?"
	Сообщение от Otto Katz Feldkurat on 29-Окт-05, 14:19
	Посмотрим. Условия в которых оно вешается, примерно известны. Когда в заросе есть JOIN mySQL пишет временную таблицу строго на диск. Заставить mySQL не писать JOIN в /tmp не сумел. Сильно похоже на потерю нодов софтапдейтом. Если за следующую неделю сервис снова висанёт, значит софтапдейтс не при чем.
	Cообщить модератору \| Наверх \| ^


	34. "taki veshaet?"
	Сообщение от si on 29-Окт-05, 21:07
	по пробуйте покрутить tmp_table_size
	Cообщить модератору \| Наверх \| ^