e
вместе с сектором читать
Size: a a a
2020 December 24
ВН
Зачем? Храни в начале блока
Выравниванию пизда
ВН
В таком случае
e
Выравниванию пизда
+
e
nvme все, что видел, умели
ВН
Как сделано в цефе: при отложенной записи 4кб потом происходит чтение, вливание в больший блок и пересчет
ВН
При записи целого "блоба" сохраняется чексумма на целый блобчик
e
надо посмотреть как в zfs сделано
ВН
Блобчик может быть 16кб скажем
ВН
А, или там в итоге блок чексумм тоже понизили до 4кб, да
AT
нет, там куда хитрее
Из документации микрона
>Micron NAND Flash memory devices use cyclic and Hamming linear codes.
>All Hamming codes can detect three errors and one correct one.
>Micron NAND Flash memory devices use cyclic and Hamming linear codes.
>All Hamming codes can detect three errors and one correct one.
ВН
nvme все, что видел, умели
Да ладно
ВН
Из документации микрона
>Micron NAND Flash memory devices use cyclic and Hamming linear codes.
>All Hamming codes can detect three errors and one correct one.
>Micron NAND Flash memory devices use cyclic and Hamming linear codes.
>All Hamming codes can detect three errors and one correct one.
Суслик
ВН
Суслик это видимо CRC
ВН
надо посмотреть как в zfs сделано
Уу, там наверняка изъебисто все
Ну на самом деле самое простое - да, хранить чексуммы на каждые 4кб
Ну на самом деле самое простое - да, хранить чексуммы на каждые 4кб
ВН
Ну жор памяти, да. Ну хотите паранойю миритесь с жором
ВН
Я ж говорю, там все обмазано
VO
надо посмотреть как в zfs сделано
У zfs нет проблемы 'записали в середину'
ВН
У zfs нет проблемы 'записали в середину'
Но все равно есть проблема как проверять, если одна чексумма на 0-128кб, вторая на блок в середине 64-68кб, а читаем мы диапазон 60-72кб