Sinu fragmentatsiooninumber näeb kohutav välja. Mõõtsin, mida see tegelikult maksab.

TL;DR. Rediacc’i rdc machine query --storage-health raporteerib fragmentatsiooninäitaja hoidla kohta. Ühel tootmismasinal märgib see GitLabi ligikaudu 19 650 laiendiga gigabaidi kohta. Instinkt ütleb defragmenteerida. Mõõtsin selle asemel.

• Hoidla, mis oli naabrist 16x rohkem fragmenteeritud, luges 149 MB/s võrreldes 143 MB/s järjestikusel lugemisel ja oli kiirem juhuslikel 4K lugemistel (719 vs 957 mikrosekundit).
• Seade on välkmälu. Fragmentatsioon kahjustab ketaspõhiseid kettaid otsingusaja kaudu. SSD-l pole selleks peaaegu ühtegi mehhanismi.
• btrfs filesystem defragment käivitamine siin jagaks lahku umbes 250 GB reflingitud harke ja hetktõmmiseid basseiniga, kus on 4,4 GB vabalt. See on tegelik risk, ja võrdlusmõõtmine ütleb, et sellega kaalumiseks pole kasu.

Salvestuse-terviseraport vastab ühele küsimusele: kuhu mu ketas läheb. See näitab iga hoidla suurust, kui palju andmeid see jagab oma hargedega, ja fragmentatsiooninäitajat. See viimane number võib tunduda hirmutav. Masinal, mida käitan, raporteerib GitLabi hoidlakujutis 268 771 laiendiga üle 14,6 GB. See on umbes 19 650 laiendiga gigabaidi kohta, ja tööriist märgib selle “kõrgeks”.

Järgnev refleks on automaatne. Kõrge fragmentatsioon, seega defragmenteeri. Olen selle refleksi kirjutanud shellisskriptidesse ketaspõhiste kettaste jaoks viisteist aastat. Enne kui lisasin Rediaccile defragmenteerimise nupu, tahtsin teada, mida number tegelikult maksab riistvaral, mida käitame. Seega mõõtsin seda elava masina peal.

Mida number tegelikult loeb

Rediacc’i hoidla on üks LUKS-pildifail, mis elab btrfs-basseinis. Fragmentatsiooninäitaja pärineb filefrag käivitamisest sellel pildifailil. See loeb krüpteeritud konteineri laiendeid, mitte faile, mida su rakendus selle sees loeb.

See on oluline, kuna andmete virnastamise tõttu. Alt üles: füüsiline SSD, seejärel hosti ext4 juurvälkmälustik, seejärel tsükliga toetatud basseenifail, seejärel loop0, seejärel btrfs-bassein, seejärel LUKS-kujutis, seejärel seadmekaardistaja krüptoseade, seejärel sisemine ext4, mida su konteinerid näevad. btrfs on copy-on-write. Iga juhuslik kirjutamine hoidla sees kirjutab kujutisesse uue laiendi. Andmebaasid ja konteinerite ülekattekihid kirjutavad juhuslikult terve päeva, seega akumuleerib kujutis laiendeid disaini järgi.

Mahus olevad failid on teine lugu. Kontrollisin GitLabi hoidlat: selle gitaly binaarfail on 10 laiendis, git pack-fail 17-s. Sisemine välkmälustik ei ole fragmenteeritud. 19 650-per-gigabait näitaja kirjeldab copy-on-write konteinerit, mis on täpselt see, mida sa ootaksid, ja ei ütle midagi selle kohta, kas lugemised on aeglased.

Võrdlusmõõtmine

Valisin kaks hoidlat fragmentatsiooniskaala vastasotstest ja lugesin neist otse-IO-ga, mis möödub leheküljevahemlust ja sunnib füüsilist lugemist.

16-kordne fragmentatsioonierinevus ei toonud kaasa läbilaskevõime karistust. Rohkem fragmenteeritud fail oli marginaalselt kiirem. Seejärel muster, mis tegelikult inimesi muretsema paneb: väikesed juhuslikud lugemised, andmebaasiliikluse kuju:

Taas on rohkem fragmenteeritud fail kiirem. Väike vahe jälgib faili suurust ja tagaala vahemällu salvestamist, mitte laiendi paigutust. Välkmälul on juhuslik lugemine üks otsimine ja üks lugemine sõltumata sellest, kus ümbritsevad laiendid asuvad. Liikuvat pead pole.

Läbilaskevõime on absoluutses mõttes tagasihoidlik, umbes 145 MB/s ja 1 000 IOPS, kuna seade on virtualiseeritud ketas jagatud hostil ja andmetee on sügav. Selle lae seab virtualiseerimine ja krüptokihid, btrfs-ist ülal ja all. Kujutise defragmentimine ei suuda seda tõsta.

Üks asi, mida fragmentatsioon tõesti maksab

Ausus nõuab ka teist poolt. Fragmentatsioonil on siin täpselt üks mõõdetav kulu, ja see ei ole lugemiskiirus. See on aeg laiendite kaardi loetlemiseks:

• filefrag GitLabis (268 771 laiendit): 3,19 s
• filefrag Stack Overflow demos (152 364 laiendit): 0,74 s

Toimingud, mis käivad läbi iga laiendi, maksavad selle eest. See hõlmab salvestuse-tervise skannimist ennast, varukoopia sünkroniseerimist ja delta tööriistu. See on sekundeid, skaleerib ligikaudu laiendite arvuga, ja puudutab taustajobisid, mitte su rakendust. Kui laiendi-läbimise aeg kunagi tõeliseks pudelikaelaks muutub, on see kitsas probleem kitsaste lahendustega. See ei ole põhjus elus andmete ümberkirjutamiseks.

Miks Rediacc ei tarni defragmenteerimiskäsku

btrfs filesystem defragment ei ole säilitanud reflinke alates umbes kerneli versioonist 3.9. Käsiraamatuleht ütleb seda selgelt: defragmentimine murdab copy-on-write andmete reflingid ja võib põhjustada ruumikasutuse märkimisväärse suurenemise. Faili pidevalt ümberkirjutamine kopeerib iga jagatud laiendi privaatseks.

Sellel masinal on peaaegu kõik jagatud. Harked jagavad vanema andmeid reflingite kaudu, ja varukoopia taimer lisab lugemiseks mõeldud hetktõmmiseid, mis samuti jagavad. Bassein on 99% täis, 4,4 GB vabalt. GitLab on 97% jagatud, seega defragmentimine prooviks kopeerida ligikaudu 14 GB 4,4 GB peale ja ebaõnnestuks pooleli. Stack Overflow demo on 137 GB 26 MB unikaalse andmega, seega defragmentimine prooviks materialiseerida 137 GB, mida füüsiliselt ei eksisteeri. Kõigis hoidlates kokku on umbes 250 GB reflingitud. Defragmenteerimispass on ruumipomm, mitte häälestus.

Isegi kui see mahuks, ei kestaks see. Need kujutised re-fragmenteeruvad minutite jooksul sama juhuslik-kirjutamise töökoormuse all. Sa jagaksid oma harked lahku, lühidalt, lugemiskiiruse eest, mida võrdlusmõõtmine ütleb, et sul juba on.

Mida lugeda fragmentatsiooni asemel

Veerg, mis väärib samas raportis su tähelepanu, on divergents. See on hoidla kujutisest unikaalse osa protsent, mis on ainulaadne sellele hoidlale, mitte jagatud harkide ja hetktõmmistega. Värske hark on lähedal 0%, kuna see jagab peaaegu kõike. Hoidla, millesse on pärast hargimist palju kirjutatud, tõuseb 100% poole.

Divergents vastab küsimusele, millele fragmentatsioon ei suuda vastata: kui palju reaalset, tagasinõutavat ketast see hoidla maksab. Kui bassein on tihe, on madala divergentsiga hoidla halb puhastamise sihtmärk, kuna selle baidid on jagatud ja selle kustutamine vabastab vähe. Baidid elavad seal, kus divergents on kõrge.

Kokkuvõte

Fragmentatsiooninumber on reaalne, ja copy-on-write kujutisel juhuslike kirjutustega näeb see alati kõrge välja. Välkmälul on see informatiivne. Mõõtsin 16-kordset vahet ja ei leidnud lugemiskaristust, kiiremat juhuslikku profiili rohkem fragmenteeritud failil, ja ühe väikese kulu taustaskaneerimise ajas. Tööriist, mis “parandaks” numbri, jagaks selle asemel lahku veerand terabaiti harke basseini, millel pole nende jaoks ruumi.

Seega Rediacc raporteerib fragmentatsiooni ja selgitab seda, ja ei paku nuppu selle põhjal tegutsemiseks. Aus insenerlik vastus oli mõõta eeldus, mitte automatiseerida refleks.