> Про объём уже писал, на современных хардах (лет много уже) ECC может
> добавлять приличный объём к данным.

Раньше был еще более приличным - в процентном соотношении. В частности 4K сектора вместо 512 насколько я помню делали как раз чтобы улучшить соотношение данные-FEC. На более длинном блоке соотношения могут быть более удачные в плане корректирующей способности VS какой это процент от данных займет. Ну как, сектора должны быть более-менее независимо декодабельны - иначе на запись сектора придется ворочать всю группу а это сложно и хреново. А на 512 байтах - даже небольшая добавка становится заметным % от этого, при умеренной корректирующей способности.

> Более того, в современных HDD минимум два уровня избыточности. Одно - как
> раз таки линейное кодирование записи, которое можно назвать FEC.
> торое ныне - привычное уже многосекторное (обычно трековое) кодирование через
> интерливер, очень похожее на то, что применялось и применяется на оптических дисках.

Идеи interleaving известны давно. Но они хорошо работают в основном от нечитаемости длинного сегмента (типа царапины на оптическом диске). Где этот сегмент превысил бы корректирующие возможности "наивного" 1-уровневого варианта, так размазал проблему на эн субблоков, масштаб проблемы небольшой для каждого субблока и вложенный FEC справляется.

А если траблы вместо этого больше напоминают "осыпон по всей площади" - ну, упс, deinterleave от этого уже сильно меньше поможет и соотношения уже не такие прикольные.

> На RAID-адаптированных, да и не только, бывает плюсом к линейному FEC ещё
> вторичный посекторный код.

RAID адаптированные - в основном так принципиально - отличаются фирмварью, чтобы не уходить надолго в себя "хоть там что", что считается контроллером за отказ девайса и ведет к залету на ребилд райда. Более обычный девайс предпочтет долбиться в нечитаемый сектор намного дольше. И если посмтреть что при этом случается - линух через секунд 15 мучений таймаутит это, пытается reset, retry операции и проч. В зависимости как сложатся пятна на солнце - это может выпасть в крайне неудачное взаимодействие. Которое надолго вклинит IO приведет к считанию девайса выпавшим. В любом случае система потребует мануального внимания и это уже булшит.

> На черепичках бывает ещё многоуровневый интерлив. Поэтому "левак" вы скорее всего
> получите уже в платформе, нежели с диска.

HDD и правда грузят левак скорее как исключение чем правило. А вот SSD, даже энтерпрайзные, прикалываются только в путь. И в каком QLC - сыпется по всей площади, ну и какой особый профит от деинтерлива ожидается? Если много утекло, что так UNC, что сяк, как ни крути. И вопрос сводится в основном к тому какой % площади готовы пожертвовать на FEC в результате.