Jeg har følgende enheter med Linux Mint 18.1 på bærbare datamaskiner og GNU / Linux Debian 9 på serveren.

(Alle er 64-biters og med Cinnamon-skrivebord.)

Alle drivenheter er formatert med ext4 filsystem ; RAID 1 er gjort ved å bruke mdadm .

  1. Bærbar PC med 1 SSHD (ikke å forveksle med HDD).

  2. Bærbar PC med 3 stasjoner: 2 x harddisker for forbrukere i RAID 1 og 1 x SSD.

  3. Server med 5 stasjoner: 4 x Enterprise HDD-er på to ganger RAID 1 og 1 x SSD.

Jeg har systemet på disse SSD-ene, og jeg vil aldri defragmentere en SSD.

Spørsmålet handler om HHD-er og en SSHD.

Jeg fant en gammel PDF som skisserer noen flere funksjoner til e4defrag .

  1. Hvorfor må filsystemet monteres i henhold til denne feilmeldingen når du prøver å defragmentere et umontert filsystem? Jeg vil forstå hvorfor det er: 

    Filesystem is not mounted

  2. Jeg vil gjerne ha implementert ledig defragmentering av plass. AFAIK det er nå under vurdering. Er det mulig for meg å f.eks. kompilere e4defrag fra kilden med disse alternativene tilgjengelige eller likevel? 

    e4defrag -f /deviceOrDirectory

  3. Jeg vil liker også å bruke relevant datafunksjon: 

    e4defrag -r /deviceOrDirectory

Jeg har mange relevante grunner til å tro at fragmenteringen på disse maskinene bremser lesehastigheten, eksempel:

  1. Tatt fra serveren med RAID 1 HDD-er: 

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

  2. Tatt fra den bærbare datamaskinen med RAID 1 HDD-er: 

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

Som du ser, var defragmenteringen ikke en gang i stand til å sette 31 blokker-filen i ett stykke. Selvfølgelig kan du hevde at det er en filmfil, så det spiller ingen rolle. Det er sant, men bare i dette tilfellet.

Kommandoen jeg bruker for å starte defragmenteringen:

  1. På serveren: 

    sudo e4defrag -v /dev/md1

  2. På den bærbare datamaskinen: 

    sudo e4defrag -v /raid1/

Det gjør virker ikke som om jeg påkaller kommandoen ved hjelp av enhetsnavnet eller en katalog.

Kan du peke meg i riktig retning?

Kommentarer

  • Du har måleresultater som peker på defragmentering som kilden til langsom tilgang? Hvis ja, hvilke? I de fleste tilfeller trenger du ikke ' å gjøre manuell defragmentering på ext4-filsystemer, så lenge det ' er nok ledig plass for at tildelingsalgoritmen automatisk skal defragmentere den under normal drift.
  • @dirkt Ingen målinger har blitt tatt så langt. Jeg argumenterer ikke ' om det er eller ikke er effektivt å defragmentere ext4 filsystem. Spørsmålene er klare: Hvordan gjør du e4defrag -r og e4defrag -f.

Svar

e4defrag trenger at filsystemet monteres fordi det ber kjernens filsystemdriver om å utføre defragmentering, det gjør det ikke t gjør det selv.

Når det gjelder ledig plassdefragmentering og relevant fildefragmentering, ble lappene aldri fullført. siste omtale på den aktuelle adresselisten dateres tilbake til 2014 :

e4defrag er i e2fsprogs, og koden blir fortsatt vedlikeholdt og forbedret. Spesielt har Dmitry Monakhov lagt til mange «torturtester», og funnet en rekke raseforhold i den underliggende kjernekoden. Han sendte nylig også en kodefaktor av kjernekoden som forbedret den betydelig (og krympet størrelsen på ext4 med 550 kodelinjer).

Når det er sagt, har det ikke vært noen reell funksjonsutvikling for e4defrag på ganske lang tid. Det har vært noen diskusjoner om hva kjernen APIer kan være for å støtte denne funksjonen, men det har aldri vært et ferdig API-forslag, enn si en implementering.

Så jeg tviler på at det er noe som er verdt å teste for øyeblikket.

Kommentarer

  • Er det noen informasjon om gjeldende (2020) beste defragmentering på ext4 – eller en anbefaling om ikke å bruke eksisterende verktøy på grunn av upålitelighet? Min e4defrag --version sier e4defrag 1.45.5 (07-Jan-2020).
  • Situasjonen har ikke endret seg mye.Det var en tråd ikke lenge etter at jeg skrev ovennevnte svar, som inkluderer et sammendrag av relevansen av e4defrag kl. tiden. Det er fremdeles en fullt støttet del av Ext4, men det er ikke brukbart i alle tilfeller (filsystemer med bigalloc kan ikke defragreres, datajournalering er uforenlig med defragging, og DAX-inoder og krypterte filer kan ikke flyttes). li>
  • Takk, Stephen. Betyr det at kommandoen er trygg i en forstand at den vil redde før en mulig skadelig handling, slik at jeg kan bruke den uten risiko for dataene mine? (I utgangspunktet fjernet jeg bare 750000 filer og lurte på om disken nå kunne fragmenteres (jeg antar at den er det) og om jeg skulle rense den eller la den være.)
  • Som enhver filsystemoperasjon er det potensielt farlig, så bruk den bare hvis du har sikkerhetskopier (eller dataene er disponible). Kommandoen er imidlertid sikker så vidt utviklerne er klar over; hvis den møter situasjoner, kan den ikke håndtere den, stopper trygt.
  • Skål. Det er fortsatt 3 TB data på disken, ingen sikkerhetskopi. Vil vente til jeg har en dag der jeg føler meg dristig nok til å prøve 🙂

Legg igjen en kommentar

Din e-postadresse vil ikke bli publisert. Obligatoriske felt er merket med *