LINUX.ORG.RU
ФорумAdmin

Чудеса с временем модификации

 , ,


0

1

У меня в /etc/cron.weekly есть скрипт очистки старых билдов

find /storage/builds -type d -links 2 -mtime +365 | xargs rm -rf

Билды там лежат лежат разные, с разной структурой каталогов, поэтому я ищу последний каталог в дереве чтобы не удалить лишнего. -links 2 это магия, выдающая как раз последние каталоги в дереве.

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

Cтруктура примерно следующая

storage
 └─builds
    └─someproject      
       └─100500             Sep 24  2019
          └─client          Sep 29  2020
          │  └─client.rpm   Sep 24  2019
          └─server          Sep 29  2020
             └─server.rpm   Sep 24  2019

Билд случился больше года назад, а потом кто-то изменил время модификации каталогам client и server. Причём время изменено только у каталогов попадающих в выдачу find и сделано это в течении недели после того как им исполнился год. Поэтому главный подозреваемый - сам запускающийся раз в неделю скрипт очистки, который почему-то вместо удаления обновил время модификации. C -ctime ситуация та же. Случай не единичный, таких довольно много.

Как и почему такое может произойти? У меня только версия бага в файловой системе.

есть скрипт очистки старых билдов
очистки
кто-то изменил время модификации каталогам

А вы чего-то другого ожидали?

ЗЫ В случаях, подобных вашему, я не полагаюсь на дату файлов, добавляю дату в имя. В течении года дата может поменяться по разным причинам.
Только если будете так делать и дату записывать в понятном человеку виде то используйте маску типа YYYY-MM-DD и т.п., что бы сравнивать было легко.

anc ★★★★★ ()
Последнее исправление: anc (всего исправлений: 1)
Ответ на: комментарий от anc

А вы чего-то другого ожидали?

В принципе, да. Я ждал что rm -rf удалит каталог, а если почему-то не сможет - оставит как было.

В течении года дата может поменяться по разным причинам

Сама по себе, взять и поменяться? Эти каталоги доступны в основном по http, писать туда в принципе некому.

pinus_nigra ()
Ответ на: комментарий от pinus_nigra

Подобные темы были. Надо хранить инфу в выхлопе ls и хитро мержить его при поступлении новых файлов. Либо натравить на это дело git, только давать ему не сами файлы, а хеши от них.

anonymous ()
Ответ на: комментарий от pinus_nigra

Сама по себе, взять и поменяться? Эти каталоги доступны в основном по http, писать туда в принципе некому.

Простой пример, решили перенести в другое место, забыли ключики и привет, дата изменена. Или в месте хранения дата не верна, пусть даже это разовый момент, вы можете дать нижнюю голову на отсечение что у вас в месте хранения 24/7/365/... будет верная дата ? Или даже так: Вы уверены что она прямо сейчас верная? Это на боевом сервере вы куда быстрее обнаружите сбой времени, а на хранилище...
Или

Эти каталоги доступны в основном по http, писать туда в принципе некому.

Это сегодня. Но это не означает, что и через 10 лет условия останутся такими же. Вариантов много.

Старое доброе: Если что-то может произойти, оно обязательно произойдет в самый неподходящий момент.
Так зачем допускать возможность ошибки если можно не допускать?

ЗЫ Или ещё вариант. Который, как может показаться, совсем не за уши притянут. Подключили новое хранилище, время настроить забыли, перелили на него со старого, настроили синхронизацию времени и успокоились. Запустилась очистка старых бэкапов и удалила все старые. И пусть даже вы это заметили, вам оно надо повторно прыгать, когда вместо прыжков можно было попивать смузи и курить бамбук?

ЗЫЫ Что ещё плохого варианте «полагаться на дату», это вероятность получения не консистентного бэкапа. Когда и место будет отжирать и какого-то файлика не будет хватать.

anc ★★★★★ ()
Последнее исправление: anc (всего исправлений: 1)
Ответ на: комментарий от anc

Это всё я проверил. И даже написал скриптик, который собрал статистику. Таких случаев - больше двух тысяч и ВЕЗДЕ дата переведена в течении недели после года хранения и ТОЛЬКО у последних в дереве каталогов (но не у их содержимого). И ни одного случая, где бы эти условия не выполнялись.
Поэтому рассказы про то как что-то где-то случайно сбилось - таки да, за уши. Всё больше склоняюсь к мысли какого-то хитрого бага на комбинации mdraid и ext4. Так-то, выходить с I/O error при проблемах с дисками в рейде rm имеет право, но зачем стулья ломать..

pinus_nigra ()
Ответ на: комментарий от pinus_nigra

Это всё я проверил.

Сегодня. Вы обратили внимание, что у меня перечислены варианты не только для «сегодняшнего дня»?
Повторюсь. «Так зачем допускать возможность ошибки если можно не допускать?»

ЗЫ Ещё абсолютно глупый пример, однако возможный. Понадобилось вам зачем-то развернуть старую копию, смотрим что есть под боком, что бы байтики не гонять, и находим нужную. :)

ЗЫЫ Собстно появление вашей темы в топике только подтверждает, что полагаться на дату файла не лучший вариант.

anc ★★★★★ ()
Последнее исправление: anc (всего исправлений: 2)
Ответ на: комментарий от anc

Повторюсь.

Ни к чему. Я уже понял, что стриггерил особый сорт тараканов, имеющих слабость к обсуждению конкретной темы :). Будем считать, что её мы обсудили. Но вообще мой вопрос не про совсем то, как именно неким индусам надо было организовавать хранение несколько лет назад. Я им ваше мнение всё равно передать не смогу.

pinus_nigra ()
Ответ на: комментарий от pinus_nigra

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

Minona ★★ ()
Ответ на: комментарий от pinus_nigra

еще вариант:
в каталогах client|server кроме rpm-ок есть еще какой-то каталог.
вот он и удаляется, а файлы остаются.

кстати, если у тебя в каталогах 100500 есть только 2 каталога client и server
то с -links 4 он показывает как раз каталоги 100500.
может логичнее их удалять?

Minona ★★ ()