Чому не потрібен TRIM в серверах

1. розміри секторів
2. Write amplification (посилення записи)
3. Copy on write
4. Де взяти чисті блоки?
5. TRIM
6. Background garbage collection (фонова прибирання сміття)
7. TRIM і реальність
8. висновок

Для початку варто розібратися з тим, як працює SSD, що таке прибирання сміття, як працює TRIM і головне - чому він не потрібен в серверах.
SSD відрізняється від HDD не тільки обмеженим ресурсом осередків. Є ще безліч архітектурних особливостей.

розміри секторів

Стандартний розмір сектора для більшості блокових пристроїв (жорстких дисків і систем зберігання даних) дорівнює 512 байт (на деяких SAS / SCSI дисках можливі 520/528 байт для додаткового контролю цілісності даних). Останні кілька індустрія намагається перейти на сектори 4096 байт (4 КІБ), т.зв. Advanced Format. Просувається процес повільно, все поки що зупинилося на 512e, тобто дисках з 4K-секторами всередині, але з емуляцією 512 байт секторів для хоста. На дисках 512e можуть виникати проблеми з продуктивністю: при необхідності записати блок даних розміром менше 4 КІБ контролера диска доводиться зчитувати сектор, міняти в ньому дані і тільки потім записувати назад. Для SSD ситуація із записом невеликих блоків ще складніше:

Контролер SSD як і раніше змушений прикидатися блоковим пристроєм з 512 байт сектором. Але всередині все складніше: осередки об'єднані в сторінки розміром, як правило, 4-8 КІБ, тобто це мінімально доступний для читання або запису обсяг. Записати дані в осередок / сторінку просто так не можна, для цього потрібно попередньо виконати операцію стирання, а стерти можна тільки цілий блок, що складається з декількох десятків (наприклад, 64 або 128, в залежності від архітектури SSD) сторінок, тобто мінімально доступний для стирання блок може виявитися розміром, наприклад, в 512 КІБ.

Write amplification (посилення записи)

Даний термін означає співвідношення між обсягом даних, який фактично доводиться записувати на флеш-пам'ять, і обсягом, який пише хост. Припустимо, що у нас є блок 512 КІБ з даними і потрібно поміняти невеликий фрагмент. Для модифікації сектора в 512 байт контролера SSD доводиться робити кілька операцій (ситуація нагадує write penalty для RAID-5/6):

• прочитати весь блок в буфер
• модифікувати вміст буфера
• стерти весь блок
• записати новий вміст буфера

Тобто для розміру транзакції в 512 байт на SSD з розміром блоку сторінок в 512 КІБ отримуємо write amplification = 1024 рази. Це не найкращим чином позначається а) на продуктивності і б) ресурсі, який як і раніше становить кілька тисяч циклів перезапису для MLC SSD.

Copy on write

Проблема посилення записи має просте рішення: потрібно намагатися записувати дані в уже попередньо стерті блоки. На допомогу приходить класичний алгоритм copy-on-write, різновиди якого використовуються для оптимізації запису в RAID-DP у Netapp або в ZFS (тільки шаром вище - на рівні файлової системи).

Суть алгоритм copy-on-write полягає в запису в "вигідні" ділянки носія, тобто в разі SSD - на чисті (стерті) блоки. У наведеному нижче прикладі модифікується вміст сторінки "B". Замість читання / стирання / запису всього великого блоку досить лише прочитати вміст сторінки, модифікувати її та записати в інше місце. При цьому необхідно поміняти покажчик, щоб ті ж LBA вказували на нове фізичне місце розміщення даних.

Як додатковий засіб боротьби з write amplification більшість сучасних контролерів SSD використовують стиснення даних.

Де взяти чисті блоки?

На новому SSD все блоки є чистими і готовими до запису. Далі є резервна область, яка насправді, використовується завжди, так як крім оптимізації записи необхідно забезпечити ще й рівномірність зносу осередків SSD.

TRIM

Як бути, якщо після безперервного запису чистих блоків вже не залишилося? Для можна якимось чином дізнатися, де на SSD знаходяться призначені для користувача дані, а де розміщені невалидность дані, що залишилися після видалення файлів. Власне, цим і займається TRIM. SSD, як і будь-яке інше блоковий пристрій, нічого не знає, про те, які саме дані на ньому зберігаються. ОС може взаємодіяти як з шаром файлової системи, так і з блоковим пристроєм, тобто після видалення файлу ОС передає на SSD разом з командою TRIM (або UNMAP для SCSI) список LBA, за якими знаходилися видалені дані. SSD отримує в розпорядження блоки з невалидность даними, і ці блоки можна в подальшому використовувати для запису.

Background garbage collection (фонова прибирання сміття)

Другий очевидний спосіб виявлення невалидность даних - повторні запити на запис від хоста по тим же LBA. Для хоста це виглядає, як перезапис одних і тих же секторів, але SSD весь час намагається писати в різні блоки. У вищенаведеної ілюстрації роботи copy-on-write актуальні дані містяться в новій сторінці "B '", після чого в вихідної сторінці залишаються невалидность дані.

Області з невалидность даними можуть бути сильно фрагментовані, тобто містити осередки з потрібними даними. Залишається останній крок - дефрагментировать ці області, отримавши набір цілих вільних блоків і виконати їх стирання.

Власне, за все це і відповідає прибирання сміття. "Правильні" SSD, розраховані на інтенсивну запис, мають достатній over-provisiong (резервну область) в якості "простору для маневру" і ефективний контролер з достатнім об'ємом кеша (зрозуміло, захищеного конденсаторами) для розміщення метаданих і буферизації читання / запису. Якщо контролер не встигає швидко підготувати місце для швидкого запису, то це неминуче відіб'ється на продуктивності, буде періодичний зростання затримок в кілька разів відносно середнього значення, як на даній картинці з www.storagereview.com :

TRIM і реальність

Для роботи TRIM крім виконання безлічі умов (підтримка з боку ОС і файлової системи) необхідно розібратися з іншими верствами абстракції, наприклад, RAID. Перерахувати адреси прийшли на з TRIM на контролер від хоста і розкидати їх по окремим дискам теоретично можливо, але ніхто (ні LSI , ні Adaptec by PMC ) Не поспішає з реалізацією. Причина проста - за межами домашніх систем або робочих станцій така проста річ, як видалення файлу зустрічається вкрай рідко. У серверах, як правило, зустрічаються абсолютно інші навантаження, до яких TRIM не може мати ніякого відношення:

• Віртуалізація. На фізичному диску або томі RAID-контролера лежить одна файлова система (VMFS / NTFS / XFS), а на ній - віртуальний диск у вигляді файлу (який нікуди не віддаляється і навіть не змінюється в розмірі, якщо диск не тонкі), а всередині віртуального диска - інша ФС. Як, від кого і кому передавати TRIM в такій ситуації - абсолютно незрозуміло.
• Надання блочного доступу. Це додає кілька рівнів абстракції. Тому-> Розділ (або ФС + файл) -> Таргет-> Файлова система
• Файловий доступ. В організаціях, як правило, ніхто не видаляє регулярно велика кількість файлів. Такий сценарій зустрічається хіба що при зберіганні тимчасового медіа-контенту, наприклад, при рендеринге або перекодуванні відео, а SSD тут зовсім не потрібні. Файл-сервер зазвичай використовується для довготривалого зберігання інформації.
• Бази даних. Файл, який, знову-таки не видаляється, а лише модифікується і росте.

висновок

Використовуйте сумісні з вашим контролером SSD, вибирайте їх з урахуванням очікуваної навантаження на запис і не хвилюйтеся про TRIM.