@Quber Ну это если честно бред, потому что все это на уровне реализации в коде прекрасно делается. Опиши пример задачи напиши, где у меня возникнут проблемы в предложенном мной варианте, а я опишу тебе описание где проблем с выборкой фотографий не возникнет.
P.S. Может пропустил, но не вижу зачем автор вообще это делает.
Раньше использовал safe-upgrade и обновлял только имеющиеся пакеты, но с опытом перестал бояться делать и full-upgrade и dist-upgrade. В целом стараюсь не использовать Ubuntu на серверах, сейчас перевожу все системы на Debian (из очень много, около 300 и все они в большей степени разношерстные). По моему опыту он показал себя с намного лучшей стороны не только как более стабильный дистриб.
Да, и еще. Не бойтесь собирать пакеты с исходников с применением checkinstall. Это намного лучше чем подключать сторонний не официальный репозитарий, хотя порой кажется это простым и быстрым средством решить проблему. Именно из-за самодельных (самосборных) пакетов из стороннего репозитария (dotdeb), по всей видимости не оттестированных как полагается, я как то положил на несколько часов один из важных и нагруженных ресурсов из-за бага в пакете mysql-server.
Ну и совет из основного поста - тестируйте обновление на тестовом сервере с тем же набором софта и похожим окружением. К сожалению, у вас такой возможности может и не быть.
Да, и читайте перед важным обновлением список рассылки. И на офф. сайте обычно выкладывают новости если обновление может что то поломать или же требуется внести какие то подготовительные операции к обновлению.
@L3n1n Не совсем так "анализирует все файлы внутри папки в поисках именно вашего.....читает БД файл с базой файлов внутри папки".
Данные со списком файлов хранятся в dentry-методанных каталога. Что бы получить доступ к конкретным физическим данным берется имя файла из dentry-методанных, сводятся с inode-методанными файла, где уже содержится информация о физическом местоположении файла на жестком диске. Нету никакого БД-файла со списком папок и осуществление доступа к файлу не приводит к анализу всех файлов внутри. Всего лишь сканируется грубо говоря двоичный файл в котором ссылки на иноды файлов. А это не ресурсоемкий процесс. Таким он станет лишь если начать использовать объединения и маски в именах утилит типо rm, ls и тд, потому что они распаковывают маску в список имен.
Был случай - мне передали веб сервер, на котором бывший администратор из-за недосмотра в конфиге nginx умудрился писать весь кеш в один каталог и не очищать его. Это привело к тому что этот каталог забился 1 ТБ файлов размер который был +-1кб. Сперва удаление этих файлов вызвало проблемы, но когда разобрался оказалось что все просто.
Автору же совет - создавать файлы по принципу ./year/month/day/prefix_md5sum[::2]
md5sum[::2] - каждый 2ой символ md5sum файла. prefix можно убрать.
В дальнейшем это позволит очень модульно и удобно выстроить бэкап данных, манипулировать с ним и тд, нежели путь к файлам будет строиться по объединениям начальных md5sum имен, как советуют выше. Хотя, я не исключаю это как вариант. У каждого свой взгляд на удобство и потребности.
Коль /var/ не tmpfs то предполагаю что причина в PRTG, он и очищает. Тут уже помочь не могу, почитайте официальную документацию по созданию своих сенсоров и их работе, скорее всего там есть ответ на ваш вопрос
Что за бред? Конкретно по этому вопросу какая файловая система не имеет значения (если только не настроены снапшоты), тут удаление файлов, а не потеря при аварийном прерывании. А если речь идет о ведении журнала - ext3 наиболее безопасная файловая система с максимальным уровнем журналирования, в отличии от не журналируемой ext2.
