Колись я вже писав про те, що LSI крім контролерів SAS випускає мікросхеми для сучасних жорстких дисків і SSD, так само я писав про те, що флеш-пам'ять вимагає більш складного підходу до операцій введення-висновку. У чому полягає ця складність, і яку саме проблему вирішують наші чіпи я і хочу розповісти в цій статті. Мова піде про Write amplification. Зрозуміло, професіонали і так знайомі з WA, тому стаття розрахована швидше на початківців.
Сучасні мікросхеми флеш-пам'яті влаштовані так, що для досягнення підвищеної швидкодії, в них необхідно читати, писати і прати дані великими блоками. Причому блок запису за розмірами не менше блоку читання, а блок стирання - завжди більше, ніж блок запису. Це викликає необхідність об'єднувати комірки пам'яті в ієрархічну структуру, зазвичай: блоки - сектори - сторінки.
Коли у нас на руках незаймано-чистий новий SSD, ніяких проблем немає. Всі його комірки заповнені нулями і готові до прийому наших даних. Тому перший запис на SSD взагалі не становить жодних проблем. Зазвичай дані записуються блоками по 4-8 КБ, і це відбувається дійсно швидко.
А тепер припустимо, нам потрібно поміняти пару байт (для драматизму можна навіть вважати, що один єдиний біт, хоча в житті це буває рідко) в вже записаному файлі. На відміну від традиційних жорстких дисків, флеш-пам'ять не дозволяє просто так взяти і перезаписати блок даних, його для початку треба стерти. А оскільки блок стирання за розмірами сильно великого блоку запису, то ця операція буде дуже неефективною. Спасибі, Wikipedia, за наочну ілюстрацію:
Для цього нам потрібно кудись рахувати вміст всього блоку стирання, потім модифікувати в ньому дані, потім стерти блок і записати в нього дані заново. Це і призводить до появи такого негативного явища, як посилення запису. Фактично, на диск записується куди більше даних, ніж реально «хотів» записати комп'ютер.
Дуже проста формула дозволяє розрахувати коефіцієнт посилення запису.
Коефіцієнт Посилення Запису = Дані, записані на флеш-пам "ять/Дані, надіслані на запис вузлом
Дане явище було відомо з моменту появи перших мікросхем з NAND пам'яттю, але термін Write Amplification був введений в обіг в 2008 році компаніями Intel і SiliconeSystems.
Посилення запису має два яскраво виражених недоліки. Перший з них - це падіння швидкості, оскільки читання-стирання-запис великих блоків явно не такий ефективний, як прямий запис, але цей недолік просто обходиться.
Контролер флеш-пам'яті бере на себе роботу з трансляції логічних адрес, якими оперує комп'ютер у фізичні адреси даних на носії, в нашому випадку SSD, це називається Logical Block Addressing (знайома багатьом абревіатура LBA).
Сучасні контролери оптимізують операцію перезапису наступним чином: Якщо йому потрібно змінити якийсь з блоків файлу, то замість повного перезапису з читанням, стиранням і записом, контролер SSD зберігає модифікований блок в іншому місці, яке було заздалегідь стерто, позначає старий блок «доступним, але не готовим» і змінює інформацію в метаданих, які він використовує для LBA.
На першому етапі, це здається розумною ідеєю, але по мірі заповнення диска, у нас стає все більше блоків в «неправильному» стані, тобто позначених як вільні, але не стертих. Тому сучасні жорсткі диски використовують різні алгоритми складання сміття, які стирають такі блоки і повертають їх у списки «доступних і готових». Зрозуміло, чим менше на диску вільного місця, тим інтенсивніше доводиться використовувати ці алгоритми, що в свою чергу обумовлює залежність ефективності роботи SSD від заповнення.
Другий недолік Write Amplification полягає в прискоренні зносу SSD. Всі ми знаємо, що комірки пам'яті мають межу за кількістю допустимих операцій перезапису. У SLC дисків він вищий, у MLC нижче, але він є. Для боротьби з цим використовується надлишковість даних і їх перевірка за допомогою різних контрольних сум (я вже писав про LDPC в минулій статті), але надмірність вільного місця мікросхем пам'яті - ресурс обмежений, і посилення запису сприяє більш швидкому його вичерпанню.
Які ж фактори і як впливають на Write Amplification?
Збирання сміття
Те, що від ефективності роботи алгоритмів GC залежатиме знос комірок SSD, - незаперечно. Збирання сміття на SSD дисках може відбуватися як фоново, так і явно.
У разі явного (foreground) складання сміття, очищення та оптимізація звільнених блоків відбувається при записі нових. У разі фонового збирання контролер використовує періоди простою для оптимізації вільного місця і очищення блоків.
Фонове очищення дозволяє прискорити роботу за рахунок того, що блоки звільняються до того часу, коли вони вже необхідні, але це призводить до того, що часто контролеру доводиться оптимізувати реально непотрібні дані, які ймовірно взагалі можуть бути в майбутньому видалені.
Наявність і переваг і недоліків призводить до того, що розробники намагаються комбінувати ці методи, домагаючись кращої продуктивності. Наприклад, у SSD від OCZ фоновий складальник сміття очищає невелику кількість блоків і зупиняється, що дозволяє мінімізувати кількість зайвих операцій, проте надаючи диску оперативний доступ до вільних блоків.
Тим не менш, найбільш перспективним напрямком зараз є складання сміття одночасно з операціями запису, ініційованими хостом. Це дозволяє добиватися високої продуктивності в оточеннях з великою кількістю операцій запису, коли SSD не простоюють. У числі контролерів, що володіють такою можливістю і контролери SandForce від LSI.
З цікавої екзотики, варто відзначити спроби деяких виробників, в першу чергу Samsung, розробити систему складання сміття, яка б використовувала в роботі інформацію файлової системи, розміщеної на диску. Це дозволило б контролеру ефективно використовувати інформацію про нещодавно видалені файли і нерозподілений простір. На думку розробників, такий підхід дозволив ефективно працювати в тих системах, які не підтримують команду TRIM. Контролери з цією можливістю вимагали щоб диск був обов'язково розмічений в NTFS і містив MBR. Ця технологія була дуже ненадійною, і часто призводила до втрат даних, особливо при використанні інших файлових систем. Ще одним напрямком, в якому рухаються розробники SSD - Application Hinting. Найпростіше пояснити це на прикладі баз даних. Дані в СУБД також розміщуються в сторінках для спрощеного їх пошуку. Тому, в СУБД також є поняття сміття, або Dirty Page. Якби СУБД могла відсилати заздалегідь списки «брудних» сторінок на твердотільні пристрої, це значно допомогло б у процесі складання сміття. Є приклади оптимізації і для інших програм.
# кінець першої частини #