Как вам такой вариант (по сути это вариант уже описаного, но значительно проще
в реализации):
Вместо удаления делать rename в каталог-отстойник, который периодически будет
вычищаться кроном.

On Tuesday, January 25, 2011 07:18:47 am Dmitry Dedukhin wrote:
> Есть третий вариант, который я уже описал ;)
>
> 25.01.2011 14:39, Valery Kholodkov пишет:
> > ----- Dmitry Dedukhin<dedukhin@mail.ru> wrote:
> >> Ну в общем-то да, если будет вспомогательный процесс только для удаления
> >> (не обслуживающий соединения), то разницы нет, будет ли он закрывать
> >> файл после удаления, или удалять натурально.
> >> Но как в таком случае отлавливать ошибки удаления?
> >
> > У этой задачи два решения:
> >
> > 1) Файл удаляется синхронно по отношению к запросу клиента, клиент,
> > соответственно, ждет, но гарантированно получает результат операции; 2)
> > Запрос на удаление помещается в очередь, клиенту отдается позитивный
> > ответ, а удаление выполняет другой процесс. Все ошибки записываются в
> > базу или отправляются по почте в какой-нибудь "отдел эксплуатации".
> >
> >> 25.01.2011 12:18, Igor Sysoev пишет:
> >>> On Tue, Jan 25, 2011 at 12:11:56PM +0300, Dmitry Dedukhin wrote:
> >>>> Ну я про реализацию DAV в nginx толкую :)
> >>>> Конечно, самый простой вариант, подсказанный Валерием - написать
> >>>> простенькое FCGI приложение, которое будет удалять файлы не блокируя
> >>>> воркер-процесс.
> >>>
> >>> Я про последовательность: открываем файл в другом процесс, закрываем
> >>> в воркере, удаляем в другом. Почему не просто: закрываем файл в
> >>> воркере, удаляем в другом ?
> >>>
> >>>> 25.01.2011 11:55, Igor Sysoev пишет:
> >>>>> On Mon, Jan 24, 2011 at 01:39:22PM +0300, Dmitry Dedukhin wrote:
> >>>>>> Перед удалением файла мы открываем его в другом (вспомогательном)
> >>>>>> процессе, затем удаляем в рабочем процессе - он остается открыт в
> >>>>>> вспомогательном процессе и физически удаления в рабочем процессе не
> >>>>>> происходит, т.е. блокировка минимальна.
> >>>>>> Затем мы закрываем файл в вспомогательном процессе - происходит
> >>>>>> физическое удаление, но блокировка вспомогательного процесса нам не
> >>>>>> важна, т.к. он не обслуживает соединения.
> >>>>>> Чисто теоретически, будет ли работать такая схема?
> >>>>>
> >>>>> По идее - да. А почему бы просто не закрывать файл и передавать
> >>>>> его имя в другой процесс для удаления ?
> >>>>>
> >>>>>> 24.01.2011 12:59, Igor Sysoev пишет:
> >>>>>>> On Mon, Jan 24, 2011 at 12:56:43PM +0300, Михаил Монашёв wrote:
> >>>>>>>> Здравствуйте, Дмитрий.
> >>>>>>>>
> >>>>>>>> в nginx есть aio. Но не знаю, работает ли оно с unlink.
> >>>>>>>
> >>>>>>> Нет, единственное решение - вынос этой операции с
> >>>>>>> специализированный трэд или процесс.
> >>>>>>>
> >>>>>>>> DD> Сейчас, DAV-модуль вызывает unlink и на больших файлах
> >>>>>>>> воркер-процесс DD> блокируется на ощутимое время.
> >>>>>>>> DD> Я не в теме, поэтому спрашиваю у сообщества, есть ли
> >>>>>>>> вообще в природе DD> неблокирующее удаление файлов под *nix?
> >>>>>>>>
> >>>>>>>>
> >>>>>>>> С уважением,
> >>>>>>>> Михаил Монашёв
> >>>>>>>> mailto:postmaster@softsearch.ru
> >>>>>>>> ICQ# 166233339
> >>>>>>>> http://michael.mindmix.ru/
> >>>>>>>> Без бэкапа по жизни.
> >>>>>>>>
> >>>>>>>>
> >>>>>>>> _______________________________________________
> >>>>>>>> nginx-ru mailing list
> >>>>>>>> nginx-ru@nginx.org
> >>>>>>>> http://nginx.org/mailman/listinfo/nginx-ru
> >>>>>>
> >>>>>> _______________________________________________
> >>>>>> nginx-ru mailing list
> >>>>>> nginx-ru@nginx.org
> >>>>>> http://nginx.org/mailman/listinfo/nginx-ru
> >>>>
> >>>> _______________________________________________
> >>>> nginx-ru mailing list
> >>>> nginx-ru@nginx.org
> >>>> http://nginx.org/mailman/listinfo/nginx-ru
> >>
> >> _______________________________________________
> >> nginx-ru mailing list
> >> nginx-ru@nginx.org
> >> http://nginx.org/mailman/listinfo/nginx-ru
>
> _______________________________________________
> nginx-ru mailing list
> nginx-ru@nginx.org
> http://nginx.org/mailman/listinfo/nginx-ru
_______________________________________________
nginx-ru mailing list
nginx-ru@nginx.org
http://nginx.org/mailman/listinfo/nginx-ru