Цитата Teror:
|
а это правда что сбои на ssd чаще всего "виновата служебная область"? либо сама прошивка контролера слетает »
|
Очень упрощённо и большей частью неверно. Слетает не сама прошивка, а FTL - Flash Translation Layer, таблица, сопоставляющая адреса LBA физическим адресам в NAND. А прошивка при невозможности считать FTL переходит в аварийное состояние, диск не работает.
Проблема хранения FTL действительно сложна и интересна. Хоть её размер относительно невелик, порядка десятков мегабайт, но туда действительно много пишется, читается и сбой FTL = безвовзвратная потеря даных. То есть, данные никуда не деваются, но найти их не представляется возможным. При выравнивании износа, уборке мусора, FTL тоже должна обновляться, так как меняется физическое расположение данных в NAND. В ход идут разные ухищрения, вроде журналов, циклического перемещения служебной области по мере записи и т.п. В общем, утверждать про какую-то фиксированную "служебную область", износ в которой вызывает сбой FTL, я бы не стал. Ещё, для снижения нагрузки эта таблица мапится в DRAM память, либо на самом диске, либо в DMA хоста в случае безбуферников, но тут возникает проблема, что делать в случае сбоев, например, питания. И там тоже идут в ход ухищрения, вроде конденсаторов, обеспечивающих работу контроллера в случае пропажи питания, на миллисекунды, чтобы успеть дописать.
Всё очень сложно, неудивительно, что сбои не редкость и они вовсе не обязательно связаны с износом какой-то "служебной области". Тем более, что после попытки перепрошивки сбойного диска тот часто продолжает работать как ни в чём ни бывало. Будь фиксированная служебная область у таких экземпляров ушатана в ноль, восстановить работоспособность не получалось бы.
Усугубляет и то, что имплементации этого всего разные в разных контроллерах, алгоритмы работы и их реализации - где и как хранится FTL, как обеспечивается защита от сбоев - представляют собой коммерческую тайну, потому подробной инфы в открытом доступе просто нет.
