Здравствуйте, eskimo82, Вы писали:

	Скрытый текст
	D>>>>Считываем список файлов (имена, mtime, размер), сортируем по убыванию mtime (свежие вверх), идём циклом по всему списку, сначала суммируя размеры до тех пор, пока не доберёмся до разрёшенного макимума, а с этого момента и до конца списка — удаляем файлы. A>>>Папка большая, файлов и сабфолдеров много, реагировать надо быстро. D>>Ну, есть ещё вариант "по щучьему велению, по моему хотению — а ну быстро удалитесь старые файлы!" Но что-то подсказывает, что никаким иным способом, кроме как чтением с диска, список хранящихся на этом диске файлов получить не удастся. Веры не хватает. Возможно, можно придумать какие-то трюки во избежание загрузки всего списка в память и сортировки, но с ходу ничего достаточно надёжного и универсального в голову не приходит. E>Он хочет услышеть в ответ что надо переенумеровать содержимое директории и подписать на нотификейшены для каждого файла. Дальше асинхронно сумировать изменения размера и быстро реагировать. E>Венда вот такая — без велосипеда ни шагу, даже на собеседование. E>ЗЫ: Да кстати, правильный ответ на тот вопрос заключается в том, что предлагаемая архитектура концептуальна неверна (и как следствие, придумавшего её архитектора собеседователя надо гнать в шею). Логи должны бережно отдаваться специально обученому серверу, где специально обученый демон будет их нежно и надежно складировать, выдавая назад квитанцию "складировано" и удаляя лишнее/старое. Ни о какой "шаре", где с логами могут сотворить непотребность другие логи и залетные пользователи, да и сама шара может зависнуть в локе как какая нибудь nfs в случае сетевых проблем, и речи быть не может.

Если венда, то можно подписать нотификешн на всю папку. Алгортм по сути — стейт машина.

Здравствуйте, eskimo82, Вы писали:

	Скрытый текст
	D>>>>Считываем список файлов (имена, mtime, размер), сортируем по убыванию mtime (свежие вверх), идём циклом по всему списку, сначала суммируя размеры до тех пор, пока не доберёмся до разрёшенного макимума, а с этого момента и до конца списка — удаляем файлы. A>>>Папка большая, файлов и сабфолдеров много, реагировать надо быстро. D>>Ну, есть ещё вариант "по щучьему велению, по моему хотению — а ну быстро удалитесь старые файлы!" Но что-то подсказывает, что никаким иным способом, кроме как чтением с диска, список хранящихся на этом диске файлов получить не удастся. Веры не хватает. Возможно, можно придумать какие-то трюки во избежание загрузки всего списка в память и сортировки, но с ходу ничего достаточно надёжного и универсального в голову не приходит. E>Он хочет услышеть в ответ что надо переенумеровать содержимое директории и подписать на нотификейшены для каждого файла. Дальше асинхронно сумировать изменения размера и быстро реагировать. E>Венда вот такая — без велосипеда ни шагу, даже на собеседование. E>ЗЫ: Да кстати, правильный ответ на тот вопрос заключается в том, что предлагаемая архитектура концептуальна неверна (и как следствие, придумавшего её архитектора собеседователя надо гнать в шею). Логи должны бережно отдаваться специально обученому серверу, где специально обученый демон будет их нежно и надежно складировать, выдавая назад квитанцию "складировано" и удаляя лишнее/старое. Ни о какой "шаре", где с логами могут сотворить непотребность другие логи и залетные пользователи, да и сама шара может зависнуть в локе как какая нибудь nfs в случае сетевых проблем, и речи быть не может.

Если венда, то можно подписать нотификешн на всю папку. Алгортм по сути — стейт машина.

Тех сложностей, что вы описали — не нужны.