Есть сетевая папка, в которую разные программы сохраняют свои логи. Размер папки ограничен. Нужно сделать программу, которая будет удалять старые файлы, так чтобы общий размер папки не превышал 80% от лимита.
Здравствуйте, abibok, Вы писали:
A>Есть сетевая папка, в которую разные программы сохраняют свои логи. Размер папки ограничен. Нужно сделать программу, которая будет удалять старые файлы, так чтобы общий размер папки не превышал 80% от лимита.
Считываем список файлов (имена, mtime, размер), сортируем по убыванию mtime (свежие вверх), идём циклом по всему списку, сначала суммируя размеры до тех пор, пока не доберёмся до разрёшенного макимума, а с этого момента и до конца списка — удаляем файлы.
Здравствуйте, abibok, Вы писали:
A>Есть сетевая папка, в которую разные программы сохраняют свои логи. Размер папки ограничен. Нужно сделать программу, которая будет удалять старые файлы, так чтобы общий размер папки не превышал 80% от лимита.
D>Считываем список файлов (имена, mtime, размер), сортируем по убыванию mtime (свежие вверх), идём циклом по всему списку, сначала суммируя размеры до тех пор, пока не доберёмся до разрёшенного макимума, а с этого момента и до конца списка — удаляем файлы.
Папка большая, файлов и сабфолдеров много, реагировать надо быстро.
Здравствуйте, abibok, Вы писали:
D>>Считываем список файлов (имена, mtime, размер), сортируем по убыванию mtime (свежие вверх), идём циклом по всему списку, сначала суммируя размеры до тех пор, пока не доберёмся до разрёшенного макимума, а с этого момента и до конца списка — удаляем файлы.
A>Папка большая, файлов и сабфолдеров много, реагировать надо быстро.
Ну, есть ещё вариант "по щучьему велению, по моему хотению — а ну быстро удалитесь старые файлы!" Но что-то подсказывает, что никаким иным способом, кроме как чтением с диска, список хранящихся на этом диске файлов получить не удастся. Веры не хватает. Возможно, можно придумать какие-то трюки во избежание загрузки всего списка в память и сортировки, но с ходу ничего достаточно надёжного и универсального в голову не приходит.
Здравствуйте, abibok, Вы писали:
A>Есть сетевая папка, в которую разные программы сохраняют свои логи. Размер папки ограничен. Нужно сделать программу, которая будет удалять старые файлы, так чтобы общий размер папки не превышал 80% от лимита.
A>Папка большая, файлов и сабфолдеров много, реагировать надо быстро.
while (true)
{
var files = Directory.EnumerateAllFiles(); //98% времени
DeleteOldFiles(files); //2% времени
}
Энумирация всегда будет жрать львиную долю проце... времени. Многопоточностью это не исправить.
Если энумирация — единственный способ узнать о появлении новых файлов, то задача не решаема.
Под Windows можно взглянуть на ReadDirectoryChanges() и FindFirstChangeNotification(), а дальше всё тривиально: вставляем файлы в сортированный список, одновременно увеличивая сумму, если сумма зашлкалила, то проходимся по списку и удаляем файлы.
Всё сказанное выше — личное мнение, если не указано обратное.
Как и во всех моих вопросах на интервью, подразумевается, что собеседующий:
1) Не идиот.
2) Изначально воспринимает вас как опытного специалиста.
3) Не стремится сбить вас с толку стрессовой ситуацией, а желает увидеть как вы умеете применять ваши программистские навыки.
4) Кодинг и законченное/идеально правильное решение не интересны. Куда интереснее ход мыслей, задаваемые вопросы и системный подход.
5) Умение найти недостатки в собственном или чужом решении — большой плюс.
Здравствуйте, abibok, Вы писали:
A>Есть сетевая папка, в которую разные программы сохраняют свои логи. Размер папки ограничен. Нужно сделать программу, которая будет удалять старые файлы, так чтобы общий размер папки не превышал 80% от лимита.
QFileSystemWatcher
A>4) Кодинг и законченное/идеально правильное решение не интересны. Куда интереснее ход мыслей, задаваемые вопросы и системный подход.
В общем подход такой, нужно просто помнить несколько библиотек уровня фреймворка и предназначение нескольких тысяч классов, которые решают некие задачи. Никаких велосипедописательств, пусть даже это существенно быстрее. В крайнем случае искать решение по фреймворкам. Я заметил, что мозгу без разницы сколько запомнить, главное правильно структурировать информацию.
A>3) Не стремится сбить вас с толку стрессовой ситуацией, а желает увидеть как вы умеете применять ваши программистские навыки.
Чувствую, что со временем любая задача превратится в рутину. Жаль нельзя мгновенно обучаться.
A>Есть сетевая папка, в которую разные программы сохраняют свои логи. Размер папки ограничен. Нужно сделать программу, которая будет удалять старые файлы, так чтобы общий размер папки не превышал 80% от лимита.
Ты хочеш изобрести logrotate для windows ?
D>>>Считываем список файлов (имена, mtime, размер), сортируем по убыванию mtime (свежие вверх), идём циклом по всему списку, сначала суммируя размеры до тех пор, пока не доберёмся до разрёшенного макимума, а с этого момента и до конца списка — удаляем файлы. A>>Папка большая, файлов и сабфолдеров много, реагировать надо быстро. D>Ну, есть ещё вариант "по щучьему велению, по моему хотению — а ну быстро удалитесь старые файлы!" Но что-то подсказывает, что никаким иным способом, кроме как чтением с диска, список хранящихся на этом диске файлов получить не удастся. Веры не хватает. Возможно, можно придумать какие-то трюки во избежание загрузки всего списка в память и сортировки, но с ходу ничего достаточно надёжного и универсального в голову не приходит.
Он хочет услышеть в ответ что надо переенумеровать содержимое директории и подписать на нотификейшены для каждого файла. Дальше асинхронно сумировать изменения размера и быстро реагировать.
Венда вот такая — без велосипеда ни шагу, даже на собеседование.
ЗЫ: Да кстати, правильный ответ на тот вопрос заключается в том, что предлагаемая архитектура концептуальна неверна (и как следствие, придумавшего её архитектора собеседователя надо гнать в шею). Логи должны бережно отдаваться специально обученому серверу, где специально обученый демон будет их нежно и надежно складировать, выдавая назад квитанцию "складировано" и удаляя лишнее/старое. Ни о какой "шаре", где с логами могут сотворить непотребность другие логи и залетные пользователи, да и сама шара может зависнуть в локе как какая нибудь nfs в случае сетевых проблем, и речи быть не может.
Здравствуйте, dimgel, Вы писали:
D>>>Считываем список файлов (имена, mtime, размер), сортируем по убыванию mtime (свежие вверх), идём циклом по всему списку, сначала суммируя размеры до тех пор, пока не доберёмся до разрёшенного макимума, а с этого момента и до конца списка — удаляем файлы.
A>>Папка большая, файлов и сабфолдеров много, реагировать надо быстро.
D>Ну, есть ещё вариант "по щучьему велению, по моему хотению — а ну быстро удалитесь старые файлы!" Но что-то подсказывает, что никаким иным способом, кроме как чтением с диска, список хранящихся на этом диске файлов получить не удастся. Веры не хватает. Возможно, можно придумать какие-то трюки во избежание загрузки всего списка в память и сортировки, но с ходу ничего достаточно надёжного и универсального в голову не приходит.
heap (min-heap по mtime) достаточно надежный и универсальный для хранения части списка файлов которые удалять не надо. Надо лишь добиться чтого, чтобы суммарный размер всех файлов в heap был не больше этого самого оговоренного лимита. Тут возникает несколько интересных вопросов которые надо отдельно обсуждать: (1) насколько важно высвободить именно столько места, сколько запросили (ничего если мы ошибемся на один файл (ошибка=макс размеру файла) ? как избавиться от ошибки?); как сделать наоборот — кучу с файлами которые мы хотим удалить (чтобы не удалить толькочто появившиеся файлы).
Здравствуйте, abibok, Вы писали:
A>Есть сетевая папка, в которую разные программы сохраняют свои логи.
есть мнение, что суммировать размер файлов -- неправильно. размер файла != место на диске. особенно если файл -- директория. можно ошибиться и потому нужно смотреть сколько реально занимает файл или папка со всеми файлами. это системно-зависимо, но по другому никак. да и файлы могут иметь аттрибут сжатия.
если файловая система у вас та за которую я думаю -- так она на уровне фс может индексировать файлы по разным атрибутам. индексируем по времени создания и тогда етгь будет отдавать файлы от старых, двигаясь к все более новым.
так же полезно выделять логи имеющие нехарактерно большой размер. допустим, средний размер лога за день — 1 метр. и тут мы видим, что за такое-то число у нас лог на целый гектар. dos атака или кто-то логгирует еггор в бесконечном цикле? надо ж разобраться. а если мы сотрем лог, то получим бесты.
нотификация о создании новых файлов -- она ж документированно глючит. нотификация может служить сигналом для енумерации, но если наш демон будет запоминать только нотифицрованные файлы -- это же течь ресурсов гарантированная.
вы говорите, что реагировать надо быстро. это как? насколько быстро и кому это надо? в принципе несложно наваять фейковую фс чисто на прикладном уровне и тогда мы непосредственно будем обрабатывать все запросы за создание, изменение и удаление файлов, что автоматически решает проблему синхронизации -- чтобы наш демон не удалял открытые на запись файлы. к тому же такое решение позволит предотвратить ситуацию, когда один-единственный файл вдруг внезапно превысит размер допустимой квоты. обрабатывая запись мы или возвратим ошибку, или же (если файл текстовой) на лету подчищаем наиболее старое содержимое этого файла. то есть в принципе можно сделать так, чтобы for(;) write(); удовлетворял ваши требования и в папке было 20% свободного места, хотя при таком подходе эти самые притянутые за уши 80% можно смело довести до 99%
americans fought a war for a freedom. another one to end slavery. so, what do some of them choose to do with their freedom? become slaves.
Здравствуйте, abibok, Вы писали:
A>Есть сетевая папка, в которую разные программы сохраняют свои логи. Размер папки ограничен. Нужно сделать программу, которая будет удалять старые файлы, так чтобы общий размер папки не превышал 80% от лимита.
Операционная система не указана.
Файловая система не указана.
Способ доступа к сетевому ресурсы (файловая система\сеть) не указан.
Крайние случаи, вроде блокировок и их устранения — не оговорены.
Здравствуйте, abibok, Вы писали:
D>>Считываем список файлов (имена, mtime, размер), сортируем по убыванию mtime (свежие вверх), идём циклом по всему списку, сначала суммируя размеры до тех пор, пока не доберёмся до разрёшенного макимума, а с этого момента и до конца списка — удаляем файлы. A>Папка большая, файлов и сабфолдеров много, реагировать надо быстро.
Добавлять нечеткие требования походу решения задачи это очень в стиле agile
Здравствуйте, abibok, Вы писали:
A>Есть сетевая папка, в которую разные программы сохраняют свои логи. Размер папки ограничен. Нужно сделать программу, которая будет удалять старые файлы, так чтобы общий размер папки не превышал 80% от лимита.
Задача алгоритмическая? Если да то скорее всего подразумевается использование алгоритма LRU
Здравствуйте, eskimo82, Вы писали:
E>Он хочет услышеть в ответ что надо переенумеровать содержимое директории и подписать на нотификейшены для каждого файла. Дальше асинхронно сумировать изменения размера и быстро реагировать. E>Венда вот такая — без велосипеда ни шагу, даже на собеседование.
Ну я не сказал бы, что это велосипед, та же IDEA и на лялихе все каталоги текущего проекта слушает. Но я, увы, не догадался: ни разу не встречал такую потребность на практике, поэтому отталкиваться не от чего было.
E>ЗЫ: Да кстати, правильный ответ на тот вопрос заключается в том, что предлагаемая архитектура концептуальна неверна (и как следствие, придумавшего её архитектора собеседователя надо гнать в шею). Логи должны бережно отдаваться специально обученому серверу, где специально обученый демон будет их нежно и надежно складировать, выдавая назад квитанцию "складировано" и удаляя лишнее/старое.
Да, тут согласен. Активный сервер на любой задаче даст 100 очков вперёд по возможностям пассивному.
Здравствуйте, abibok, Вы писали:
A>Есть сетевая папка, в которую разные программы сохраняют свои логи. Размер папки ограничен. Нужно сделать программу, которая будет удалять старые файлы, так чтобы общий размер папки не превышал 80% от лимита.
Софткор —
по таймеру запускаешь рассчет объема папки, если близок к лимиту — сортируешь файлы по дате, удаляешь старые
Хардкор — держишь в памяти очередь файлов и суммарный размер. Вешаешься на системное событие создания файла. Если размер файла выводит суммарный размер за лимит — удаляешь из очереди файлы пока не останемся в пределах лимита
Странная задача, и требования сильно и сильно расплывчатые.
Самое простое-тупое решение сконфигурить — Rolling Log Files. Если конфиг логов и их уборка расположены в разных местах, то каким образом при указании другого пути я смогу узнать что надо переконфигурить еще и подчищалку.
Если уж уборка логов так жизненно необходима, то не указаны характеристики логов: относительные объемы, важность и так далее. Почему нельзя например раз в 5 дней архивировать логи которые старше 5-10 дней.
По поводу окружения уже сказали. И скорее всего результатом такого решения будет г-но, да еще и никому не нужное.
Входных данных очень мало
D>>>>Считываем список файлов (имена, mtime, размер), сортируем по убыванию mtime (свежие вверх), идём циклом по всему списку, сначала суммируя размеры до тех пор, пока не доберёмся до разрёшенного макимума, а с этого момента и до конца списка — удаляем файлы. A>>>Папка большая, файлов и сабфолдеров много, реагировать надо быстро. D>>Ну, есть ещё вариант "по щучьему велению, по моему хотению — а ну быстро удалитесь старые файлы!" Но что-то подсказывает, что никаким иным способом, кроме как чтением с диска, список хранящихся на этом диске файлов получить не удастся. Веры не хватает. Возможно, можно придумать какие-то трюки во избежание загрузки всего списка в память и сортировки, но с ходу ничего достаточно надёжного и универсального в голову не приходит.
E>Он хочет услышеть в ответ что надо переенумеровать содержимое директории и подписать на нотификейшены для каждого файла. Дальше асинхронно сумировать изменения размера и быстро реагировать.
E>Венда вот такая — без велосипеда ни шагу, даже на собеседование.
E>ЗЫ: Да кстати, правильный ответ на тот вопрос заключается в том, что предлагаемая архитектура концептуальна неверна (и как следствие, придумавшего её архитектора собеседователя надо гнать в шею). Логи должны бережно отдаваться специально обученому серверу, где специально обученый демон будет их нежно и надежно складировать, выдавая назад квитанцию "складировано" и удаляя лишнее/старое. Ни о какой "шаре", где с логами могут сотворить непотребность другие логи и залетные пользователи, да и сама шара может зависнуть в локе как какая нибудь nfs в случае сетевых проблем, и речи быть не может.
Если венда, то можно подписать нотификешн на всю папку. Алгортм по сути — стейт машина.
Возможно, можно придумать какие-то трюки во избежание загрузки всего списка в память и сортировки, но с ходу ничего достаточно надёжного и универсального в голову не приходит.
