Чаму не патрэбен 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 паказвалі на новае фізічнае месца размяшчэння дадзеных.

Пры гэтым неабходна памяняць паказальнік, каб тыя ж 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 :

com :

TRIM і рэальнасць

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

  • Віртуалізацыя. На фізічным дыску або томе RAID-кантролера ляжыць адна файлавая сістэма (VMFS / NTFS / XFS), а на ёй - віртуальны дыск у выглядзе файла (які нікуды не выдаляецца і нават не змяняецца ў памеры, калі дыск не тонкі), а ўнутры віртуальнага дыска - іншая ФС. Як, ад каго і каму перадаваць TRIM ў такой сітуацыі - зусім незразумела.
  • Прадастаўленне блокавага доступу. Гэта дадае некалькі узроўняў абстракцыі. Том-> Раздзел (або ФС + файл) -> Таргет-> Файлавая сістэма
  • Файлавы доступ. У арганізацыях, як правіла, ніхто не выдаляе рэгулярна вялікая колькасць файлаў. Такі сцэнар сустракаецца хіба што пры захоўванні часовага медыя-кантэнту, напрыклад, пры рэндэрынгу або перакадаванні відэа, а SSD тут зусім не патрэбныя. Файл-сервер звычайна выкарыстоўваецца для доўгачасовага захоўвання інфармацыі.
  • Базы дадзеных. Файл, які, зноў-такі не выдаляецца, а толькі мадыфікуецца і расце.

заключэнне

Выкарыстоўвайце сумяшчальныя з вашым кантролерам SSD, выбірайце іх з улікам чаканай нагрузкі на запіс і не хвалюйцеся аб TRIM.

Дзе ўзяць чыстыя блокі?