Фрагментац?я файлово? системи

Матер?ал з В?к?пед?? ? в?льно? енциклопед??.
Перейти до нав?гац?? Перейти до пошуку
Рисунок 1. В?зуал?зац?я фрагментац??, а пот?м дефрагментац??

Фрагмента?ц?я фа?йлово? систе?ми ( стар?ння файлово? системи ) ? це неспроможн?сть файлово? системи розм?стити пов'язан? дан? посл?довно  (неперервно); явище притаманне файловим системам , що дозволяють пряму модиф?кац?ю даних. ? особливим випадком фрагментац?? даних.

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

?сну? багато алгоритм?в ? правил дефрагментац??.

Причини та особливост? [ ред. | ред. код ]

Коли файлова система вперше ?н?ц?ал?зована на диску (деякий розд?л форматований , використовуючи цю файлову систему), цей розд?л м?стить лише к?лька невеликих внутр?шн?х структур, або, ?ншими словами, ? неперервним блоком в?льного простору (з точки зору файлово? системи). [1] Це означа?, що алгоритм розпод?лу даних може розм?стити новостворен? файли будь-де на диску. Протягом деякого часу п?сля створення файли у файлов?й систем? можуть розм?щуватися майже оптимально. Коли встановлю?ться операц?йна система та програми , або розпаковуються ?нш? арх?ви , посл?довне розм?щення файл?в означа?, що пов'язан? файли, найб?льш ?мов?рно, будуть розм?щен? близько один б?ля одного.

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

Потр?бно зазначити, що сказане ? спрощеним поданням досить складно? теми. Метод, який буде тут пояснено, був загальноприйнятим при розпод?л? файл?в на диску та ?нших нос?ях з дов?льним доступом до пам'ят? протягом б?льш н?ж 30 рок?в. Деяк? операц?йн? системи не просто розпод?ляють файли один за одним, ?нш? використовують р?зн? методи, щоб запоб?гти фрагментац??, але загалом рано чи п?зно через наявн? причини з плином часу буде виникати фрагментац?я на будь-як?й систем?, на як?й файли регулярно видаляються чи зм?нюються у розм?р?.

Приклад, принципи та чинники фрагментац?? [ ред. | ред. код ]

Розглянемо наступний сценар?й, як показано на рисунку 2.

Рисунок 2. Спрощений приклад того, як в?дбува?ться фрагментац?я в?льного простору та фрагментац?я файл?в.

Новий диск м?стить 5 збережених файл?в A, B, C, D та E, ? кожен файл займа? 10 блок?в пам'ят? (тут розм?р блоку неважливий). Оск?льки в?льний прост?р ? неперервним, файли розм?щуються один за одним (Приклад (1)).

Якщо видалити файл B, утворю?ться друга область з 10 блок?в в?льного простору. Файлова система може дефрагментувати диск одразу п?сля видалення, що призведе до сильного зменшення продуктивност? в непередбачуван? моменти, але в загальному, там просто залиша?ться порожн? м?сце, яке познача?ться доступним для подальшого використання, ? заповню?ться за потреби [2] (Приклад (2)).

Тепер, коли новий файл потребу? 7 блок?в пам'ят?, в?н може бути розм?щений на м?сц? колишнього файлу B, ? ще залишиться 3 порожн? блоки п?сля нього (Приклад (3)). Якщо дода?ться новий файл G, який потребу? лише 3 блоки пам'ят?, в?н може зайняти м?сце п?сля F ? перед C (Приклад (4)).

Згодом, якщо потр?бно зб?льшити файл F, оск?льки прост?р п?сля нього вже зайнято, ?сну? три можливих вар?анти: (1) додати новий блок в ?ншому м?сц? та зазначити, що F ма? другу частину; (2) перем?стити файли, як? заважають розширенню, в ?нше м?сце так, щоб F залишився неперервним; або (3) перем?стити сам файл F, щоб в?н залишився неперервним, але б?льшого розм?ру. Другий вар?ант швидше за все ? непрактичним через негативний вплив на продуктивн?сть, так само як ? трет?й у випадку дуже великого файлу. Д?йсно, трет?й вар?ант ? неможливим, коли на диску нема? неперервно? област? в?льно? пам'ят? достатньо велико?, щоб розм?стити новий файл. Отже, загальноприйнято створювати нову частину в ?ншому м?сц? ? прив'язувати ?? як продовження попереднього файлу (Приклад (5)).

Дан?, додан? до к?нця файлу F, будуть частиною його продовження. Але якщо ? так багато даних, що ?х не можна пом?стити п?сля цього продовження , тод? буде створена ?нша частина ? так дал?. Зрештою, файлова система буде мати порожн? сегменти в багатьох м?сцях, ? деяк? файли можуть бути розд?лен? на багато частин. Час доступу до цих файл?в (або вс?х файл?в) може сильно зб?льшитися.

П?дбиваючи п?дсумок, можна навести чинники, як?, як правило, спричиняють фрагментац?ю або сприяють ?й:

  • мало в?льного м?сця;
  • часте видалення, зменшення чи розширення файл?в;
  • надм?рне використання фрагментованих файл?в.

?сторична дов?дка щодо фрагментац?? [ ред. | ред. код ]

Деяк? ранн? файлов? системи не могли фрагментувати файли. Одним з таких приклад?в була файлова система  Acorn DFS , яка використовувалася на  BBC Micro . Через неспроможн?сть розд?ляти файли на частини деколи з'являлися пов?домлення помилки ≪can't extend≫ (≪не можна розширити≫)  ? користувач часто не м?г зберегти файл, нав?ть якщо на диску було достатньо в?льного простору.

DFS використовувала дуже просту структуру диска, ? файли на ньому можна було знайти лише за ?хньою довжиною ? сектором початку. Це означало, що вс? файли повинн? були складатися з неперервних блок?в ? фрагментац?я не була можливою. За прикладом вище, спроба розширити файл F на кроц? 5 не вдалася б на так?й систем? з пов?домленням про помилку розширення. Не зважаючи на те, ск?льки сумарно в?льно? пам'ят? доступно на диску, цей файл розширити було неможливо.

Стандарти обробки помилок на той час були дуже прим?тивними ?, в будь-якому раз?, програми, як? ледве вм?щалися в обмежен?й пам'ят? BBC Micro, р?дко коли могли соб? дозволити марнувати цю пам'ять на спроби елегантно? обробки помилок. Зам?сть цього користувач був би перем?щений назад у командний рядок з пов?домленням про помилку розширення, ? вс? дан?, як? потр?бно було доповнити до файлу, були би втрачен?. Розчарування було б б?льшим, якщо б користувач заздалег?дь перев?рив би в?льне м?сце на диску ? його було б достатньо. Нав?ть якщо може бути достатньо в?льного простору на диску, той факт, що його не було там де потр?бно, не можна було побачити без детального анал?зу чисел з дискового каталогу. На додаток до цього, майже вс? без винятку користувач? DFS використовували касети для збер?гання файл?в, на яких не виникала ця помилка. Перех?д на дискети був досить дорогим, але в?н зв?льнив користувач?в в?д ненад?йност? ? вкрай низько? швидкост? роботи касетних систем, де оновлення може без попередження привести до втрати даних з ?х останн?х зм?н. [3] [4]

Вплив на продуктивн?сть [ ред. | ред. код ]

Цей розд?л потребу? доповнення .

Фрагментац?я файлово? системи, за прогнозами, стане б?льш проблематичною на нов?ших комп'ютерах через зб?льшення р?зниц? м?ж швидк?стю посл?довного доступу ? затримкою обертання (? меншого часу пошуку продовження) на жорстких дисках споживчого класу, [5]  на яких зазвичай ? встановлюють файлов? системи. Через це фрагментац?я ? це важлива проблема в досл?дженнях та дизайн? сучасних файлових систем. Стримування фрагментац?? залежить не т?льки в?д внутр?шнього формату файлово? системи на диску, але також значною м?рою в?д ?? реал?зац??. [6]

У простих тестах продуктивност? файлово? системи фактор фрагментац?? часто опуска?ться через справжн? так зване ≪стар?ння≫ файлово? системи, яке складно змоделювати. Швидше за все, для простоти пор?вняння б?льш?сть тест?в продуктивност? файлово? системи часто виконують на порожн?х (або мало користованих) файлових системах, ? не дивно, що результати можуть сильно в?др?знятися в залежност? в?д характеру ?? використання в реальному житт?. [7]

Фрагментац?я файлово? системи ма? значно менший вплив на продуктивн?сть твердот?лих накопичувач?в (SSD) через те, що на них нема? часу механ?чного пошуку, як на нос?ях обертання, хоча додатков? непосл?довн? операц?? вводу/виводу впливають на продуктивн?сть системи, ? багато арх?тектур файлових систем споживають додатков? внутр?шн? ресурси, коли накопичувач фрагментований.

Типи фрагментац?? [ ред. | ред. код ]

Фрагментац?я файлово? системи може з'являтися на к?лькох р?внях:

  • фрагментац?я окремих файл?в ? ?хн?х метаданих ;
  • фрагментац?я в?льного простору, яка ускладню? неперервне розм?щення нових файл?в;
  • пог?ршення знаходження посилань м?ж окремими, але пов'язаними файлами.

Фрагментац?я файл?в [ ред. | ред. код ]

Фрагментац?я окремих файл?в виника?, коли ц?лий файл розд?ля?ться на багато частин (?х називають продовженнями у в?дпов?дних файлових системах). Файлов? системи для жорстких диск?в намагаються збер?гати файли неперервно, але це не завжди можливо без значно? втрати продуктивност?. Знаряддя (утил?ти) для перев?рки файлово? системи та ?? дефрагментац?? зазвичай в?дпов?дають користувачу про фрагментац?ю файл?в у статистиц? ≪в?дсотка фрагментац??≫ й, ?нод?, карти файлово? системи.

Фрагментац?я в?льного простору [ ред. | ред. код ]

Фрагментац?я в?льного (невид?леного) простору виника?, коли ? к?лька невикористаних областей файлово? системи, де можуть бути записан? файли або метадан?. Небажан? в?льн? област? зазвичай утворюються п?д час видалення або зменшення файл?в, але файлова система також може навмисно вставляти порожн? фрагменти (≪бульбашки≫) для того, щоб полегшити розширення сус?дн?х файл?в (див. запоб?гання фрагментац?? нижче).

Розс?ювання файл?в [ ред. | ред. код ]

Сегментац?я файл?в, яку також називають фрагментац??ю пов'язаних файл?в або фрагментац??ю р?вня програми, ? ускладнення пошуку посилань на нос?? м?ж пов'язаними файлами. На в?дм?ну в?д двох попередн?х тип?в фрагментац??, розс?ювання файл?в ? це менш ч?тке поняття, оск?льки воно сильно залежить в?д характеру доступу до файл?в конкретно? програми. Це також робить об'?ктивне ? нав?ть приблизне оц?нювання дуже складним. Проте, можливо, це найважлив?ший тип фрагментац??, оск?льки, як показали досл?дження, найчаст?ше використовуван? файли, як правило, малого розм?ру, пор?вняно з доступною пропускною здатн?стю диска. [8]

Для запоб?гання фрагментац?? пов'язаних файл?в ? покращення пошуку за посиланням (у цьому випадку близьк?сть файл?в) потр?бно робити припущення й експерименти щодо повед?нки програм на окремо взят?й файлов?й систем?. Досить часто припускають, що виправдано тримати мал? файли в одному каталоз? разом ? розм?стити ?х у природний для файлово? системи спос?б. У той час, як це припущення часто справджу?ться, воно не завжди ма? м?сце. Наприклад, програма може зчитувати к?лька р?зних файл?в, можливо в р?зних каталогах, в тому ж порядку, в якому вони були записан?. Отже, файлова система, яка просто запису? вс? файли посл?довно, може працювати швидше для дано? програми.

Методи пом'якшення фрагментац?? [ ред. | ред. код ]

Маючи к?лька метод?в позбуття фрагментац??, зазвичай, вид?ляють дв? категор??: прим?тивн? та методи зворотно? сили. Але через складн?сть передбачення характеру доступу до файл?в ц? алгоритми часто мають евристичну природу ? можуть пог?ршувати продуктивн?сть при неспод?ваних навантаженнях.

Запоб?гання фрагментац?? [ ред. | ред. код ]

Прим?тивн? методи намагаються тримати фрагментац?ю на м?н?мум? п?д час запису даних на диск. Найпрост?ше ? додавати дан? до ?снуючих фрагмент?в, де це можливо, зам?сть вид?лення нових блок?в для нових фрагмент?в.

Б?льш?сть сучасних операц?йних систем намагаються наперед вид?лити б?льш? шматки або шматки з р?зних фрагмент?в в?льного простору ? продовження файл?в, як? часто доповнюються. Це переважно запоб?га? фрагментац??, коли к?лька файл?в одночасно доповнюються, таким чином запоб?гаючи ?х сильному переплетенню. [6]

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

BitTorrent  та ?нш?  peer-to-peer програми сп?льного використання файл?в  обмежують фрагментац?ю, наперед вид?ляючи пам'ять п?д ц?лий файл, коли почина?ться його  завантаження . [9]

В?дносно новим методом ? в?дкладене вид?лення пам'ят? у  XFS , HFS+ [10] and ZFS ; такий же метод назива?ться allocate-on-flush  на reiser4 ?  ext4 . Коли викону?ться запис, резервуються блоки файлово? системи, але сам? файли ще не записуються. П?зн?ше, коли файлова система змушена збер?гати зм?ни як насл?док тиску пам'ят? чи проведення транзакц??, розпод?лювач матиме б?льше ?нформац?? про характеристики файл?в. Б?льш?сть файлових систем, як? використовують цей п?дх?д, намагаються неперервно записати файли в одн?й папц?. Вважаючи, що читання з одно? папки ? загальновживаним, пошук посилань покращу?ться. [11] Reiser4 також пропону? розм?щувати файли у папц? в?дпов?дно до  хеш-таблиц?  папки, так що коли отриму?ться доступ до файл?в, у природному для файлово? системи порядку (як записано у  readdir ), вони завжди зчитуються посл?довно. [12]

Дефрагментац?я [ ред. | ред. код ]

Дефрагментац??ю ? метод зворотно? д??, що намага?ться зменшити фрагментац?ю, або негативн? ефекти в?д фрагментац??, п?сля того, як вона вже виникла. Багато файлових/операц?йних систем надають ?нструменти для дефрагментац??, як? намагаються перевпорядкувати фрагменти файл?в, ? деколи зменшити ?х розс?ян?сть (тобто покращити ?хню сум?жн?сть) збер?гаючи або мал? файли в  папках чи дерев? каталог?в, або нав?ть посл?довност? файл?в близько один б?ля одного на диску.

Приклади ≪автодефрагментац??≫ серед файлових систем [ ред. | ред. код ]

Цей розд?л потребу? доповнення .

Файлова система HFS Plus пост?йно дефрагменту? файли менш? 20 MiB  ? розд?лен? на 8 або б?льше фрагмент?в, коли файл в?дкрива?ться. [13]

Застар?ла на сьогодн? файлова система Commodore Amiga Smart File System (SFS) дефрагментувала себе, коли використовувалася. Процес дефрагментац?? ма? практично незалежн? кроки (кр?м м?сця, над яким в?н працю?), тому в?н може бути митт?во зупинений чи початий. Протягом дефрагментац?? ц?л?сн?сть даних не порушу?ться як для звичайних так ? для метаданих .

Див. також [ ред. | ред. код ]

Прим?тки [ ред. | ред. код ]

  1. ↑ Деяк? файлов? системи, так? як NTFS або ext2 +, можуть п?д час ?н?ц?ал?зац?? вид?ляти довг? порожн? рег?они для спец?альних потреб.
  2. ↑ The practice of leaving the space occupied by deleted files largely undisturbed is why undelete programs were able to work; they simply recovered the file whose name had been deleted from the directory, but whose contents were still on disk.
  3. ↑ http://www.8bs.com/hints/083.txt - Description of the can't extend error
  4. ↑ http://8bs.com/mag/1to4/basegd1.txt - Possible data loss caused by the can't extend error
  5. ↑ Dr. Mark H. Kryder (3 кв?тня 2006). Future Storage Technologies: A Look Beyond the Horizon (PDF) . Storage Networking World conference . Seagate Technology . Арх?в ориг?налу ( PDF ) за 17 липня 2006 . Процитовано 14 грудня 2006 .
  6. ↑ а б L. W. McVoy, S. R. Kleiman (Winter 1991). Extent-like Performance from a UNIX File System . Proceedings of USENIX winter '91. Dallas, Texas: Sun Microsystems, Inc. с. pages 33?43. Арх?в ориг?налу ( PostScript ) за 21 лютого 2007 . Процитовано 14 грудня 2006 . {{ cite conference }} : |pages= ма? зайвий текст ( дов?дка )
  7. ↑ Keith Arnold Smith (January 2001). Workload-Specific File System Benchmarks (PDF) . Harvard University . Арх?в ориг?налу ( PDF ) за 17 листопада 2004 . Процитовано 14 грудня 2006 .
  8. ↑ John R. Douceur, William J. Bolosky (June 1999). A Large-Scale Study of File-System Contents. ACM SIGMETRICS Performance Evaluation Review . Microsoft Research . 27 (1): 59?70. doi : 10.1145/301453.301480 .
  9. ↑ Jeff Layton (29 березня 2009). From ext3 to ext4: An Interview with Theodore Ts'o . Linux Magazine . Арх?в ориг?налу за 27 травня 2015 . Процитовано 27 травня 2015 .
  10. ↑ Amit Singh (May 2004). Fragmentation in HFS Plus Volumes . Mac OS X Internals . Арх?в ориг?налу за 18 листопада 2012 . Процитовано 27 травня 2015 .
  11. ↑ Adam Sweeney, Doug Doucette, Wei Hu, Curtis Anderson, Mike Nishimoto, Geoff Peck (January 1996). Scalability in the XFS File System (PDF) . Proceedings of the USENIX 1996 Annual Technical Conference . San Diego, California: Silicon Graphics . Арх?в ориг?налу ( PDF ) за 18 березня 2007 . Процитовано 14 грудня 2006 .
  12. ↑ Hans Reiser (6 лютого 2006). The Reiser4 Filesystem . A lecture given by the author, Hans Reiser . Арх?в ориг?налу ( Google Video ) за 19 травня 2011 . Процитовано 14 грудня 2006 .
  13. ↑ Amit Singh (19 червня 2006). The HFS Plus File System. Mac OS X Internals: A Systems Approach . Addison Wesley . ISBN   0-321-27854-2 .
Отримано з https://uk.wikipedia.org/w/index.php?title=Фрагментац?я_файлово?_системи&oldid=41408422