|
ru.unix
- RU.UNIX ----------------------------------------------------------------------
From : Vladimir Bormotov 2:5020/400 04 Jul 2002 23:53:40
To : Oleg Derevenetz
Subject : Re: Partitioning
--------------------------------------------------------------------------------
Hi, Oleg!
>>>>> "OD" == Oleg Derevenetz <Oleg.Derevenetz@p4.f3.n5025.z2.fidonet.org>
>>>>> writes:
SO>> Лет 15 пользую следующую схему чистки /tmp: Раз в сутки трем файлы,
SO>> которые изменялись более трех суток назад, далее смотрим свободное
SO>> место в /tmp, если оно меньше X% (зависит от размера /tmp и
SO>> выполняемых машиной задач), то трем самые старые самые большие файлы,
SO>> пока места станет не менее X%. За все время ни разу не пожалел,
SO>> причем на моем персональном компе /tmp по совместительсву еще и
SO>> $downloaddir. :)
SO>> Кстати, в RedHat похожая схема "из коробки".
OD> "Очень умно". В /tmp могут быть различные управляющие сокеты, которые
OD> используются раз в месяц,
- Он пацак, а я чатланин
- а как в чем разница-то?
- ты что, зеленую точку от оранжевой отличить не можешь?
OD> а то и реже, но тереть их крайне нежелательно.
сокет на файловой системе отличается от файла невооруженным глазом.
В смысле, вооруженным простым ls -F
не говоря уже про то, что у сокета размер будет нулевой, и описаный
алгоритм его не тронет (места от вытирания файла нулевого размера больше
не станет. только освободится inode)
OD> Хранить большие файлы в /tmp вообще не нужно, для этого есть /var/tmp,
OD> а в /tmp должны лежать всякие fifo и сокеты, которые должны тереться
OD> только при загрузке.
поправочка - которые ДОЛЖHЫ ТЕРЕТЬСЯ ТЕМИ, КТО ИЗ СОДАЕТ.
Если автор какого-нибудь уродского GAIM не научился при запуске проверить,
вот этот сокет от живой второй копии себя-же, или от умершего, и утереть
мертвого, то это проблема именно gaim, а не меня, который объединил все
/tmp в одно место.
--
Bor.
--- ifmail v.2.15dev5
* Origin: BorHomeLand (2:5020/400)
Вернуться к списку тем, сортированных по: возрастание даты уменьшение даты тема автор
|
