Почему System.IO.Log SequenceNumbers имеют переменную длину?

Question

Я пытаюсь использовать функции System.IO.Log для построения системы восстанавливаемых транзакций. Я понимаю, что это должно быть реализовано поверх Common Log File System .

Обычный ARIES подход к ведению записи с опережением записи включает сохранение порядковых номеров записей журнала в местах, отличных от журнала (например, в заголовке страницы базы данных, измененной зарегистрированным действием).

Интересно, что в документации для CLFS говорится, что такие порядковые номера всегда являются 64-битными целыми числами .

Однако, как ни странно, оболочка .Net вокруг этих SequenceNumber s может быть сконструирована из byte[], но не из UInt64. Это значение также может быть прочитано как byte[], но не как UInt64. Проверка реализации SequenceNumber.GetBytes() показывает, что он может фактически возвращать массивы размером 8 или 16 байтов.

Это поднимает несколько вопросов:

1. Почему порядковые номера .Net отличаются по размеру от порядковых номеров CLFS?
2. Почему порядковые номера .Net имеют переменную длину?
3. Зачем вам нужно 128 бит для представления такого порядкового номера? Кажется, что вы должны усечь журнал задолго до использования 64-битного адресного пространства (16 exbibytes или около 10 ^ 19 байтов, больше, если вы обращаетесь к более длинным словам)?
4. Если порядковые номера журналов будут представлены как 128-битные целые, почему бы не предоставить способ сериализации / десериализации их в виде пар UInt64 с вместо довольно бессмысленного распределения кучи для недолговечных новых byte[] каждый раз, когда вам нужно написать / прочитать один? В качестве альтернативы, зачем вообще делать SequenceNumber типом значения?

Кажется странным компромиссным решением удвоить накладные расходы хранения порядковых номеров журналов, просто чтобы вы могли иметь необрезанный журнал длиннее миллиона терабайт, поэтому я чувствую, что здесь что-то упущено, или, может быть, несколько вещей. Я был бы очень признателен, если бы кто-то в курсе мог меня поправить.

Разъяснение

Я согласен с тем, что говорят Дэмиен и Андрас. Эти проблемы являются наиболее вероятным объяснением типа возвращаемого значения byte []. Но текущая реализация поверх CLFS имеет, при проверке разборки, пути кода, где она создает 64-битные LSN, и пути кода, где она создает 128-битные LSN. Зачем? И может ли клиент, использующий System.IO.Log поверх CLFS, безопасно хранить LSN в 64-битном поле фиксированной длины? 128-битное поле? Поле любой фиксированной длины?

По соседству бесполезно, если номера LSN могут быть произвольной длины, поскольку вам нужно поле LSN где-то в заголовке страницы для осуществления физиологического восстановления. Если поле имеет переменную длину, то есть существенное увеличение сложности, обращающееся к части страницы без заголовка. Если границы переменной длины не ограничены, вы даже не можете быть уверены, что у вас будет место на странице для расширения поля заголовка LSN, не проливая ни заголовок, ни содержимое страницы на новую страницу, ни одна из которых не является жизнеспособен в общем случае (поскольку точка, в которой вы могли бы обнаружить это условие, гораздо менее абстрактна, чем точка, в которой у вас была бы информация о том, как выполнить такое восстановление, если сохраняемая вами структура данных даже допускает что-то подобное).

Answer 1

Наиболее очевидная причина этого заключается в том, что UInt64 не совместим с CLS, тогда как сборка System.IO.Log явно помечена как CLSCompliant (true) (открыт в отражателе).

И поскольку Платформа определяет базовый тип как ULONGLONG, форсировать результат в Int64 небезопасно, поскольку половина результатов будет отрицательной, а пространство результатов будет окружено.

Поэтому лучшим решением, кроме изменения спецификации CLS для приема неподписанных целочисленных значений, было принятие результата байтового массива, что также дает дополнительное преимущество, как предполагает Дэмиен, в проверке на будущее в случае его расширения в будущей версии Windows возвращать больше битов.

Answer 2

Итак, ваша первая ссылка упоминает о двух реализациях интерфейса IRecordSequence, только одна из которых - основанная на CLFS. И, конечно, могут быть и другие будущие реализации. Так что, возможно, они знают о некоторых других системах, которые используют более длинные порядковые номера, и не хотят, чтобы люди писали код, который предполагает, что порядковые номера всегда 64-битные.

Answer 3

Моя личная интуиция вокруг LSN переменной длины состоит в том, что ни одно приложение не должно предполагать, что оно не может предсказать размер своего LSN (учитывая, что оно не изменило своего провайдера ). Что касается фактической причины, я подозреваю, что было бы бесполезно спекулировать, не связываясь с людьми, которые знают лучше меня.

Поскольку мы можем с уверенностью сказать что-либо о будущем, я думаю, можно с уверенностью сказать, что пользователи CLFS могут предполагать, что его номера LSN не будут изменяться по длине в течение разумного периода времени без большого оттока в его Win32 API. (Я говорю это как кто-то, кто работал над CLFS в течение нескольких лет.)

Я согласен с тем, что существует множество приложений, в которых технически было бы неэффективно поддерживать LSN переменной длины.