Ik heb de volgende apparaten met Linux Mint 18.1 op laptops en GNU / Linux Debian 9 op de server.

(Alle zijn 64-bit en met Cinnamon-desktop.)

Alle drive-apparaten zijn geformatteerd met ext4 bestandssysteem ; RAID 1 wordt uitgevoerd met mdadm .

  1. Laptop met 1 SSHD (niet te verwarren met HDD).

  2. Laptop met 3 schijven: 2 x HDDs voor consumenten in RAID 1 en 1 x SSD.

  3. Server met 5 schijven: 4 x enterprise HDDs in twee keer RAID 1 en 1 x SSD.

Ik heb het systeem op die SSDs en ik zou nooit een SSD defragmenteren.

De vraag gaat over HHDs en een SSHD.

Ik vond een oude pdf met nog een paar functies voor e4defrag .

  1. Waarom moet het bestandssysteem worden gemount, zoals aangegeven in dit foutbericht wanneer ik een niet-gekoppeld bestandssysteem probeer te defragmenteren? Ik wil begrijpen waarom dat is: 

    Filesystem is not mounted

  2. Ik zou graag defragmentatie van vrije ruimte hebben geïmplementeerd. AFAIK wordt nu herzien. Is het voor mij mogelijk om b.v. compileer e4defrag uit de bron met deze opties beschikbaar of hoe dan ook? 

    e4defrag -f /deviceOrDirectory

  3. Ik zou gebruik ook graag de relevante gegevensfunctie: 

    e4defrag -r /deviceOrDirectory

Ik heb veel relevante redenen om aan te nemen dat de fragmentatie op deze machines langzamer gaat de leessnelheid, voorbeeld:

  1. Genomen van de server met RAID 1 harde schijven: 

    [2556/30987]/raid1a/bitcoind/blocks/rev00820.dat: 100% extents: 16 -> 1 [ OK ]

  2. Van de laptop gehaald met RAID 1 harde schijven: 

    [29405/50810]/raid1/movies/SGA-HEVC/S04E01 - Adrift.mp4: 100% extents: 31 -> 6 [ OK ]

Zoals je kunt zien, was de defragmentatie niet eens in staat om het bestand met 31 blokken in één stuk te stoppen. Je zou natuurlijk kunnen zeggen dat het een filmbestand is, dus het maakt niet uit. Dat is waar, maar alleen in dit geval.

Het commando dat ik gebruik om de defragmentatie te starten:

  1. Op de server: 

    sudo e4defrag -v /dev/md1

  2. Op de laptop: 

    sudo e4defrag -v /raid1/

lijkt niet uit te maken, of ik het commando nu gebruik met de apparaatnaam of een directory.

Kun je me in de goede richting wijzen?

Opmerkingen

  • Heeft u meetresultaten die erop wijzen dat defragmentatie de bron van langzame toegang is? Zo ja, welke? In de meeste gevallen hoeft u ‘ geen handmatige defragmentatie uit te voeren op ext4-bestandssystemen, zolang er ‘ s voldoende vrije ruimte is zodat het toewijzingsalgoritme het automatisch defragmenteert tijdens normaal gebruik.
  • @dirkt Er zijn tot nu toe geen metingen uitgevoerd. Ik ‘ argumenteer niet of het wel of niet effectief is om het ext4 bestandssysteem te defragmenteren. De vragen zijn duidelijk: Hoe te doen e4defrag -r en e4defrag -f.

Antwoord

e4defrag vereist dat het bestandssysteem wordt aangekoppeld omdat het de bestandssysteemdriver van de kernel vraagt om de defragmentatie uit te voeren. doe het niet zelf.

Wat betreft defragmentatie van vrije ruimte en relevante defragmentatie van bestanden, de patches zijn nooit voltooid; de laatste vermelding op de relevante mailinglijst dateert uit 2014 :

De e4defrag bevindt zich in e2fsprogs, en de code wordt nog steeds onderhouden en verbeterd. Dmitry Monakhov heeft in het bijzonder veel “marteltesten” toegevoegd, en een aantal race-omstandigheden gevonden in de onderliggende kernelcode. Hij stuurde onlangs ook een coderefactor van de kernelcode die deze aanzienlijk verbeterde en (de grootte van ext4 met 550 regels code verkleinde).

Dat gezegd hebbende, is er geen echte feature-ontwikkeling geweest voor e4defrag al geruime tijd. Er is enige discussie geweest over wat de kernel-APIs zouden kunnen zijn om deze functie te ondersteunen, maar er is nog nooit een definitief API-voorstel geweest, laat staan een implementatie.

Dus ik betwijfel of er momenteel iets is dat het waard is om te testen.

Reacties

  • Is er informatie over de huidige (2020) beste defragmentatie op ext4 – of een aanbeveling om geen bestaande tool te gebruiken vanwege onbetrouwbaarheid? Mijn e4defrag --version zegt e4defrag 1.45.5 (07-Jan-2020).
  • De situatie is niet veel veranderd.Er was een thread niet lang nadat ik het bovenstaande antwoord had geschreven, waaronder een samenvatting van de relevantie van e4defrag op de tijd. Het is nog steeds een volledig ondersteund onderdeel van Ext4, maar het is niet in alle gevallen bruikbaar (bestandssystemen met bigalloc kunnen niet worden gedefragmenteerd, data-journaling is niet compatibel met defragmentatie en DAX-inodes en gecodeerde bestanden kunnen niet worden verplaatst).
  • Bedankt, Stephen. Betekent dit dat het commando in zekere zin veilig is dat het wordt gered vóór een mogelijk schadelijke actie, zodat ik het kan gebruiken zonder risico voor mijn gegevens? (In feite heb ik zojuist 750000 bestanden verwijderd en vroeg me af of de schijf nu gefragmenteerd kon zijn (ik neem aan dat dit het geval is) en of ik hem moet opschonen of laten staan.)
  • Zoals elke bewerking van het bestandssysteem, is het potentieel gevaarlijk, gebruik het dus alleen als u back-ups heeft (of als de gegevens wegwerpbaar zijn). Het commando is echter veilig voor zover de ontwikkelaars weten; als het situaties tegenkomt, kan het niet omgaan met het veilig stoppen.
  • Proost. Er is nog steeds 3 TB aan gegevens op de schijf, geen back-up. Zal wachten tot ik een dag heb waarop ik me durf genoeg voel om het te proberen 🙂

Geef een reactie

Het e-mailadres wordt niet gepubliceerd. Vereiste velden zijn gemarkeerd met *