LINUX.ORG.RU

История изменений

Исправление firkax, (текущая версия) :

Мы составляем просто список последних записей, индивидуальный у каждого диска и ничего не знающий про массив. Этого полностью достаточно, чтобы пересинхронизировать блоки, который могут отличаться. Можно было хранить ещё и серийные номера этих записей (чтобы их тоже сравнивать и не синхронизировать то что одинаковое, впрочем там уже придётся учитывать flush-ы по дискам, но думаю это легко достигается принятием последнего вроде бы синхронизированного гигабайта тоже грязным), но видимо посчитали что и битов достаточно. Ведь задачи свести пересинхронизацию к минимуму не стояло, стояла задача только избежать полного переписывания всего диска.

Другой вопрос что эффективно отслеживать «latest transaction sequence number» после которого были гарантированные flush’ы на всех дисках массива не так сложно. Сильно подозреваю - они это и делают.

Думаю да, там же поле events есть. Только, повторю, flush-ы на всех дисках не важны, нужно знать про конкретный.

Сопоставление состояния разных дисков нужно только в момент вставки диска в массив, на что там можно и потратить время.

Исправление firkax, :

Мы составляем просто список последних записей, индивидуальный у каждого диска и ничего не знающий про массив. Этого полностью достаточно, чтобы пересинхронизировать блоки, который могут отличаться. Можно было хранить ещё и серийные номера этих записей (чтобы их тоже сравнивать и не синхронизировать то что одинаковое, впрочем там уже придётся учитывать flush-ы по дискам, но думаю это легко достигается принятием последнего вроде бы синхронизированного гигабайта тоже грязным), но видимо посчитали что и битов достаточно. Ведь задачи свести пересинхронизацию к минимуму не стояло, стояла задача только избежать полного переписывания всего диска.

Другой вопрос что эффективно отслеживать «latest transaction sequence number» после которого были гарантированные flush’ы на всех дисках массива не так сложно. Сильно подозреваю - они это и делают.

Сопоставление состояния разных дисков нужно только в момент вставки диска в массив, на что там можно и потратить время.

Думаю да, там же поле events есть. Только, повторю, flush-ы на всех дисках не важны, нужно знать про конкретный.

Исправление firkax, :

Мы составляем просто список последних записей, индивидуальный у каждого диска и ничего не знающий про массив. Этого полностью достаточно, чтобы пересинхронизировать блоки, который могут отличаться. Можно было хранить ещё и серийные номера этих записей (чтобы их тоже сравнивать и не синхронизировать то что одинаковое, впрочем там уже придётся учитывать flush-ы по дискам, но думаю это легко достигается принятием последнего вроде бы синхронизированного гигабайта тоже грязным), но видимо посчитали что и битов достаточно. Ведь задачи свести пересинхронизацию к минимуму не стояло, стояла задача только избежать полного переписывания всего диска.

Другой вопрос что эффективно отслеживать «latest transaction sequence number» после которого были гарантированные flush’ы на всех дисках массива не так сложно. Сильно подозреваю - они это и делают.

Думаю да, там же поле events есть. Только, повторю, flush-ы на всех дисках не важны, нужно знать про конкретный.

Исправление firkax, :

Мы составляем просто список последних записей, индивидуальный у каждого диска и ничего не знающий про массив. Этого полностью достаточно, чтобы пересинхронизировать блоки, который могут отличаться. Можно было хранить ещё и серийные номера этих записей (чтобы их тоже сравнивать и не синхронизировать то что одинаковое, впрочем там уже придётся учитывать flush-ы по дискам, но думаю это легко достигается принятием последнего вроде бы синхронизированного гигабайта тоже грязным), но видимо посчитали что и битов достаточно. Ведь задачи свести пересинхронизацию к минимуму не стояло, стояла задача только избежать полного переписывания всего диска.

Другой вопрос что эффективно отслеживать «latest transaction sequence number» после которого были гарантированные flush’ы на всех дисках массива не так сложно. Сильно подозреваю - они это и делают.

Думаю да, там же поле events есть.

Исходная версия firkax, :

Мы составляем просто список последних записей, индивидуальный у каждого диска и ничего не знающий про массив. Этого полностью достаточно, чтобы пересинхронизировать блоки, который могут отличаться. Можно было хранить ещё и серийные номера этих записей (чтобы их тоже сравнивать и не синхронизировать то что одинаковое, впрочем там уже придётся учитывать flush-ы по дискам, но думаю это легко достигается принятием последнего вроде бы синхронизированного гигабайта тоже грязным), но видимо посчитали что и битов достаточно. Ведь задачи свести пересинхронизацию к минимуму не стояло, стояла задача только избежать полного переписывания всего диска.