Чи можна ефективно використовувати SSD без підтримки TRIM?

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

Основний міф щодо SSD такий: на системах без підтримки TRIM продуктивність SSD буде стрімко деградувати. Чому і як це відбувається зазвичай не повідомляється, без TRIM буде погано і крапка. У той же час більшість серверних конфігурацій дискової підсистеми TRIM не підтримують, або підтримують, але в дуже обмеженому обсязі. При цьому деяку дивина викликає те, що ні виробники заліза, ні виробники софта не поспішають з цієї "проблемою" що-небудь робити.

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

Спочатку згадаємо, як сприймають диск різні підсистеми ПК, які беруть участь в роботі з ним. Додатки та ОС взаємодіють з файлової системою, працюючи на рівні кластерів і таблиці файлів. Про те, що знаходиться нижче ОС не має жодного уявлення. Файлова система сприймає диск як деякий блоковий пристрій стандартного формату, також не сильно вникаючи в його внутрішню суть, віддаючи всі питання на відкуп драйверу контролера запам'ятовуючих пристроїв. Той, в свою чергу, сприймає диск як деякий LBA-пристрій, не знаючи його внутрішньої структури. Про те, як саме конфігурація LBA відповідає фізичної конфігурації пристрою знає тільки контролер диска, який в свою чергу не має ні найменшого уявлення про файлах, розділах, кластерах і т.п.

Фізично простір SSD ділиться на сторінки, які є мінімально адресуються ділянкою пам'яті, для того, щоб змінити осередок пам'яті, необхідно вважати сторінку, змінити в ній необхідні дані і записати її на колишнє місце. Тут виникає перша складність, на відміну від HDD, в SSD писати можна тільки в заздалегідь очищені осередки. При цьому технічно очистити окрему сторінку не можна, очищення піддаються тільки групи сторінок, що об'єднуються в блоки.

Розміри сторінок і блоків залежать від конфігурації пам'яті конкретного SSD, але, як типове, можна прийняти значення 4 КБ для сторінки і 512 КБ для блоку. А тепер уявімо, що ми відкрили файл і змінили в ньому 100 байт даних. Для HDD проблеми немає, він вважає потрібний сектор (512 байт), змінить дані і перезапише його. В реальності буде все трохи по-іншому, так як мінімально адресуються простором ФС є кластер, то HDD перезапише відповідну кількість секторів, але ніяких додаткових накладних витрат це не викличе.

А ось SSD не може взяти і просто так записати змінені дані. Для цього йому потрібно вважати кудись весь блок, очистити його і повернути всі дані назад. Тому замість зміни і записи 4 КБ даних SSD доведеться записати 512 КБ даних, що не найкращим чином позначиться на ресурсі осередків. Крім того, операція стирання осередків досить повільна, в порівнянні з записом в чисті осередки і саме необхідністю стирання перед записом пояснюється деградація продуктивності SSD.

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

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

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

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

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

Якщо розмір резервної області невеликий, а інтенсивність записи висока, то збирач сміття буде не встигати ефективно очищати блоки, і ми отримаємо деградацію продуктивності диска.

Зауважте, ми до сих пір ні словом не обмовилися про команду TRIM. Може бути це якась передова технологія, увімкнення якого допоможе різко змінити ситуацію? На жаль немає! Для чого тоді потрібен TRIM?

Знову саме час згадати, що файлова система не має не найменшого уявлення про фізичний розміщенні даних на носії, це прерогатива контролера диска. Тому видалення файлу в сучасних файлових системах фізично не відбувається, видаляється лише запис у таблиці файлів, після чого дане місце вважається вільним. При цьому самі дані будуть знаходиться на диску до тих пір, поки не будуть перезаписані. При цьому файлова система ніяк не повідомляє контролеру про таких даних, і він продовжує вважати ці осередки зайнятими. У SSD це призведе до ситуації аналогічної тому, коли диск повністю заповнений, хоча з точки зору ФС там багато вільного місця і вона буде намагатися писати туди.

В цьому випадку SSD буде повністю зчитувати блок в пам'ять, очищати його і заново записувати змінені дані.

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

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

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

Якщо ми розмістимо на SSD базу даних або віртуальний жорсткий диск і будемо активно працювати з ними, то ніякої TRIM нам не потрібен. Якщо на диску достатньо вільних осередків і ефективно працює збирач сміття - продуктивність буде підтримуватися на високому рівні. Падіння продуктивності відбудеться тільки тоді, коли кількість вільних осередків зменшиться і збирач сміття не встигатиме очищати їх в необхідних кількостях. Це може статися при використанні всього доступного простору диска і TRIM на це ніяк вплинути не може.

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

Тут саме час згадати про корпоративні серії SSD, які часто не блищать продуктивністю, але зате пропонують високу надійність і підтримують ефективну роботу навіть без підтримки TRIM. За рахунок чого це відбувається? За рахунок більшого розміру резервної області. Це дозволяє завжди мати достатній запас вільних осередків і благотворно позначається на ефективності роботи збирача сміття. Так як користувач не може безпосередньо писати в резервну область, то в ній можуть бути сторінки тільки трьох видів: вільні, зайняті і доступні до очищення. Зайнятих сторінок, які ФС вважає вільними, там бути не може.

Звичайні SSD мають розмір резервної області в 6-7% від ємності диска, цього розміру явно недостатньо для підтримки високої продуктивності, корпоративні диски мають набагато більший обсяг резервної області, що безпосередньо позначається на їх вартості. Це дозволяє їм зменшити знос кожної доступної користувачеві осередки і ефективно працювати в RAID-масивах без підтримки TRIM. Хоча якщо ви заповніть твердотільний накопичувач "під зав'язку", то ніякої TRIM вам не допоможе.

А що робити власникам звичайних або "корпоративних" бюджетних дисків? Відповідь проста - забезпечити диск достатньою кількістю вільних осередків. Найпростіший спосіб зробити це - розмітити не всю доступну ємність диска. Як показує практика - резерв в 20-25% ємності накопичувача дозволяє ефективно використовувати навіть повністю заповнений диск без підтримки команди TRIM.

Щоб переконатися в цьому, ми провели невеликий експеримент. Взяли старий SSD OCZ Agility 2 <OCZSSD2-2AGTE60G>, алгоритми прибиральника сміття якого в рази поступаються сучасним алгоритмам, повністю заповнили його на системі без підтримки TRIM, потім ще раз зробили те ж саме, тільки створивши "резервну область" в 25% ємності накопичувача.

Отже, диск очищений за допомогою команди Secure Erase фірмовою утилітою і все його осередки є вільними. Знімаємо показники швидкодії за допомогою AS SSD Benchmark.

синтетика:

Сценарії реального використання:

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

Після чого ми підключили його до виртуалке під керуванням Windows Server 2003 і повністю заповнили, потім видалили всі дані і повернули назад. Незважаючи на те, що Windows 8.1, в якій ми виробляємо виміри, є підтримка TRIM - це ні на що не впливає, так як примусово дану команду ніхто не посилав, а Windows 8.1 зробить це не раніше, ніж запише і видалить дані і то, тільки для цих сторінок.

Деградація продуктивності на обличчя:

Просідання продуктивності від 20 до 50% в синтетиці і 30-35% в сценаріях:

Тепер знову виконаємо Secure Erase і розмітили не всі простір диска, виділивши під резерв 25%:

Важливо! Перед тим як переразметіть твердотільний диск його слід повністю очистити від даних за допомогою фірмової утиліти для того, щоб в резервну область потрапили тільки вільні комірки. Якщо просто видалити розмітку і виконати її заново або змінити кордони розділів, то це не дасть бажаного ефекту.

Потім знову заповнимо диск в середовищі Windows Server 2003 і видалимо дані, після чого ще раз виконаємо тест:

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

Які висновки слід зробити з цього матеріалу? Незважаючи на те, що в свідомості багатьох TRIM є мало не панацеєю і обов'язковий до застосування, на продуктивність диска він не впливає. Це всього лише спосіб зробити роботу прибиральника сміття більш ефективною. На продуктивність диска впливає тільки те, яка кількість вільних осередків є в наявності і їх достатності для обслуговування поточних операцій записи.

За те, з якою швидкістю диск і як ефективно диск здатний очищати блоки, відповідає прибиральник сміття. Більш ефективний алгоритм прибиральника дозволяє використовувати менший розмір резервної області.

Також слід пам'ятати, що в більшості серверних сценаріїв команда TRIM просто не потрібно, тому якщо вибирати доводиться між RAID без TRIM або одиночний диск з TRIM, вибирати слід перше. Тим більше, що забезпечити високу продуктивність диска нескладно самостійно.

Використання одиночного диска з більш частим бекап також допустимо, але таке рішення приймається, як правило, з економічних міркувань.