Цитата:
Т.е. внешнее приложение (читай девайс) обращается с памятью задавая адрес для записи/чтения, для него (приложения), адресное пространство остается неизменным, а вот контроллер может переназначить наиболее занюханый участок памяти другому адресу, таким образом обеспечивая равномерное использование всей памяти.
|
ну во первых этой технике уже уйма лет и она отлично прижилась на классических жёстких дисках - когда время доступа к физическому блоку памяти начинает превышать определённый предел (на нжмд это как правило около 100мс) происходит переназначение (remap) блока из резервной части диска заместо "отмирающего", иногда это происходит "на лету" иногда в случае низкоуровневого форматирования (зависит от модели диска)
во вторых у этой техники есть существенные минусы:
1) для обеспечения полной сохранности данных необходимо считывать каждый блок в который планируется запись перед непосредственно операцией записи - это почти удваивает время линейной записи поэтому так обычно не делают
2) обычно делается так - блок записывается, а когда проходит команда его считать, в случае если время чтения превышает предел информация из него считывается и переписывается в ремапнутый блок ... но по понятным причинам информация может и не считаться вообще. Для классических нжмд это не большая проблема т.к. деградация отдельных блоков магнитных пластин линейна т.е. с большой степенью вероятности можно утверждать что если в прошлый раз блок считался за время меньше лимита, то скорее всего в следующий раз блок считается возможно и за бОльшее время но считается. А вот для SSD картина немного другая - деградация (если не ошибаюсь то кислотной ?) части накопителя скорее всего не линейна т.е. имеет два состояния - работает и не работает
Вообщем с SSD нельзя утверждать что если в прошлый раз считывание уложилось в определённые пределы времени то в следующий раз оно вообще произойдёт.
Таким образом контроллер должен хранить количество операций доступа ко всем блокам памяти SSD диска и при каждом обращении к ним обновлять эту информацию чтобы в случае когда определённые ячейки памяти будут подходить к пределу своего жизненного цикла можно было спокойно ремапать их на живые.
Накладные расходы на поддержание такой статистики мягко скажем огромны, предположим что блок памяти с которым оперирует контроллер у нас 512 байт (больше маловероятно т.к. тогда необходимо вводить логическое деление физических банков для файловых систем с аналогичным или меньшим размером кластера а меньшие значения и считать смысла нет - дальше поймёте почему) т.е. для диска в 4Гб у нас количество блоков памяти:
512*2*1024*1024*4 = 4294967296 блоков памяти. Каждому необходим счётчик до 100000 т.е. состоящий из 3 байт т.е. 4294967296*3 байт информации это 12884901888 байт т.е. почти 13Гб данных только на счётчик, не говоря уже о том что писать по три байта не очень удобно
Вообщем вариант ремапа по статистическим показателям тоже получается не возможен.
За сим я лично не очень понимаю как эта техника реализована в отдельно-взятых контроллерах.
Речь ессно о случаях когда не предполагается физические повреждения носителя.
Чисто теоретически диски SSD лишины проблем с фрагментацией данных точнее это для них не проблема т.к. фрагментация почти не заметна (накладные расходы на переход к не следующей ячейке сильно меньше классических нжмд) т.е. контроллер может постоянно в случайном порядке осуществлять запись в свободные сектора диска таким образом равномерно используя его ресурс. Но и этот способ - полная шляпа. Дело в том что такой подход возможен при наличии достаточного количества свободного места на диске, чем свободного места меньше - тем меньше блоков учавствуют в "рулетке" случайной записи, а учитывая что нынешний размер дисков ну никак не правоцирует пользователей на наличие огромного процента свободного места то на практике он не реализуем
Вообщем моё ИМХО таково - технология пока свежая и не шибко обкатанная (превед компании дэлл) за сим яб лично не стал доверять ей шибко важные файлы, хотя именно для ноутов и всяких мобилок она очень перспективна в ближайшее время (до 3х лет), а для обычных компутеров - в ближайшие лет пять ... но пока это будущее
п.с. ждём нормальных SSD с 4 битами на блок - в теории почти 4х кратный прирост скорости ... а в теории блок может держать 256 бит ... это будет уже костмас ... осталось до этого дожить
п.п.с
Цитата:
Опять же никто не отменял кэширования и прочие прибамбасы, поэтому просто переносить математические выкладки на реальный ресурс некорректно.
|
нисогласен ниразу
кэширование и прочие прибамбасы это удел софта - в нём может это как быть так и не быть - железо не должно настолько сильно зависить от софта чтоб для соответствия стандарту х86 мой несчастный калькулятор должен был бы уметь десяток видов кеширования и предварительной выборки чтоб не дай Бог случайно не записать что-нить на винт
математические выкладки - это как-раз та статья с таблицами, реальный ресурс я вам расчитал сразу в работе одного отдельно взятого РЕАЛЬНОГО приложения, ессно немного утрированно но вполне реально