" (Vladimir A. Butenko)" wrote:
>
> On Fri, 19 Sep 2003 14:47:47 +0400
> <CGatePro@mx.ru> (Dmitry S. Rzhavin) wrote:
>
> > Хорошо, решение 'в лоб'.
> > каждый mbox получает свой counter, записываемый в начало файла. При каждой
> > операции с файлом ++counter (в смысле, сначала увеличиваем, потом
> > работаем).
> > Операция с mbox защищена всеми имеющимися на данный момент механизмами (Вы
> > указывали, что у Вас есть механизмы защиты mbox от различных повреждений).
> > Далее.
> > каждый mbox получает файл mbox.index, в котором лежит некоторый индекс по
> > заголовкам (+- другие поля, наиболее часто запрашиваемые). Каждый index
> > имеет counter, который нормально совпадает с counter mbox.
> > При любых изменениях mbox соответственно изменяется index, причем
> > counter++
> > (в смысле, что counter изменяется только после успешной записи в index).
> > Все запросы по выборке почты обслуживаются из индекса, если это возможно
> > (собсна, что должно принести выгоду).
>
> Такие counter's уже и так есть - называются "dateTimeModified", атрибут
> такой у файла. Вот только когда он на диск попадает - вопрос сложный,
> особенно при NFS. И в каком порядке. А с счетчиками тоже не так просто. Вот,
> стали Вы писать индекс. Одним куском. Вначале - счетчик пошел, потом данные,
> потом система благополучно упала. В результате имеете свой счетчик плюс
> старые данные (частично).
угу, поэтому писать надо отдельно, после остальных изменений.
> Можно, конечно, в два обращения писать - сначала
> все данные, потом счетчик обновлять. Это долго. Можно "по умному" - писать в
> конце данных тот же счетчик. При чтении не совпало - значит, файл побитый.
тогда читать счетчик непонятно где, или писать только файл целиком (чтобы счетчик всегда был в самом конце файла). Дорого.
> Ну и так далее. Это я просто навскидку Вам показываю, что у предложенного
> вами решения есть:
> а) проблемы.
> б) альтернативы
> в) проблемы у альтренатив.
>
> То есть - думать надо.
Безусловно, на готовый алгоритм без недостатков оно и не претендует. Я надеюсь, что это будет обдумано, и отвергнуто по результатам рассмотрения (или, мб, доведено до ума и реализовано :) Получено Fri Sep 19 11:24:33 2003
Этот архив был сгенерирован hypermail 2.1.8 : Tue 21 Feb 2006 - 03:14:31 MSK