[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Внятная HOWTO по ext3



Hello!

> Я же говорю: "насколько тупой скрипт бэкапа", а не "насколько тупая
> программа"...  Скрипту бэкапа вполне достаточно знать про возможность не
> трогать atime, поскольку по смыслу его операция не является доступом к
> файлу, она является _созданием его резервной копии_.
>
>  AP> А использование последнего времени доступа предполагает, что
>  AP> программа запущена на однопользовательской машине,
>
> Это неверно.  Чистить ~/tmp (нифига не включаемую в бэкап, поскольку она
> tmp по смыслу) по atime - самое оно.  "Мужик, ты вот тут парочку типа
> временных файлов месяц не смотрел _никакой_ программой - они тебе точно
> нужны?"  Или наоборот, "мужик, тут у тебя в tmp файл не менялся два
> месяца, а смотрелся вчера - может, он таки тебе нужен, и мы его положим
> куда-нибудь, где он бэкапиться будет?"

Помилуйте, но откуда в /tmp такой мусор?

$ uptime
 18:04:15 up 247 days

$ ls /tmp/|wc -l
33

Что там чистить-то? 

Ну, на ноуте/десктопе малость поболее может быть мусора, но эти машинки обычно 
пару раз в месяц да перезагружают, а некоторые пользователи даже чаще, так 
что само чистится. А писать серверный софт с устраиванием свалки из временных 
файлов я уже зарекся. Видел немало софта, который эту свалку таки устраивает, 
например, если вы используете php-based soft, то atime вам нужен. Впрочем, 
то, что хранит mutt, вроде как раз не относится к временным файлам.

>
>  AP> что собственно противоречит идеологии линукса, как я ее понимаю.
>
> Могу только порекомендовать подумать над идеей расширить свое понимание
> идеологии линукса...  У тебя это вроде бы неплохо получалось...

При наличии аргументов, чтоб было над чем думать. Пока что вижу только 
проблемы с криво написанным софтом, который устраивает свалку и приходится с 
этим как-то бороться. Кто создал файл, тот и должен его удалить, если не 
удалил - значит, нужный процесс помер преждевременно и надо еще разобраться, 
что случилось.


Best regards, Alexey.


Reply to: