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

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

Alle drevsenheder er formateret med ext4 filsystem ; RAID 1 udføres ved hjælp af mdadm .

  1. Bærbar computer med 1 SSHD (ikke at forveksle med HDD).

  2. Bærbar computer med 3 drev: 2 x harddiske til forbrugere i RAID 1 og 1 x SSD.

  3. Server med 5 drev: 4 x harddiske til virksomheder i to gange RAID 1 og 1 x SSD.

Jeg har systemet på disse SSDer, og jeg ville aldrig defragmentere en SSD.

Spørgsmålet handler om HHDer og en SSHD.

Jeg fandt en gammel PDF , der beskriver et par flere funktioner til e4defrag .

  1. Hvorfor skal filsystemet monteres i henhold til denne fejlmeddelelse, når man prøver at defragmentere et ikke-monteret filsystem? Jeg vil forstå, hvorfor det er:

    Filesystem is not mounted 
  2. Jeg vil gerne have implementeret ledig defragmentering af plads. AFAIK det er nu under gennemgang. Er det muligt for mig at f.eks. kompilere e4defrag fra kilden med disse muligheder tilgængelige eller alligevel?

    e4defrag -f /deviceOrDirectory 
  3. Jeg ville kan også lide at bruge relevant datafunktion:

    e4defrag -r /deviceOrDirectory 

Jeg har mange relevante grunde til at tro, at fragmenteringen på disse maskiner er langsommere læsehastighed, eksempel:

  1. Hentet fra serveren med RAID 1 HDDer:

    [2556/30987]/raid1a/bitcoind/blocks/rev00820.dat: 100% extents: 16 -> 1 [ OK ] 
  2. Taget fra den bærbare computer med RAID 1 HDDer:

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

Som du kan se, var defragmenteringen ikke engang i stand til at sætte 31 blokke-filen i 1 stykke. Selvfølgelig kan du argumentere for, at det er en filmfil, så det betyder ikke noget. Sandt nok, men kun i dette tilfælde.

Den kommando, jeg bruger til at starte defragmenteringen:

  1. På serveren:

    sudo e4defrag -v /dev/md1 
  2. På den bærbare computer:

    sudo e4defrag -v /raid1/ 

Det gør det ser ikke ud til at være noget, uanset om jeg påberåber mig kommandoen ved hjælp af enhedsnavnet eller et bibliotek.

Kan du pege mig i den rigtige retning?

Kommentarer

  • Du har måleresultater, der peger på defragmentering som kilde til langsom adgang? Hvis ja, hvilke? I de fleste tilfælde behøver du ikke ' ikke at foretage manuel defragmentering på ext4-filsystemer, så længe der ' er nok ledig plads for tildelingsalgoritmen til automatisk at defragmentere den under normal drift.
  • @dirkt Der er endnu ikke foretaget nogen målinger. Jeg argumenterer ikke ' om det er eller ikke er effektivt at defragmentere ext4 filsystem. Spørgsmålene er klare: Sådan gør du e4defrag -r og e4defrag -f.

Svar

e4defrag skal filsystemet monteres, fordi det beder kernens filsystemdriver om at udføre defragmentering, det gør ikke t gør det selv.

Med hensyn til defragmentering af ledig plads og relevant fildefragmentering blev plasterne aldrig afsluttet; den sidste omtale på den relevante adresseliste dateres tilbage til 2014 :

e4defrag er i e2fsprogs, og koden bliver stadig vedligeholdt og forbedret. Dmitry Monakhov har især tilføjet en masse “torturprøver” og fundet en række race-forhold i den underliggende kernekode. Han sendte for nylig også en kodefaktor for kernekoden, som forbedrede den betydeligt og (formindskede størrelsen på ext4 med 550 linier kode).

Når det er sagt, har der ikke været nogen reel funktionsudvikling for e4defrag i nogen tid. Der har været en del diskussion om, hvad kernen APIer kan være til at understøtte denne funktion, men der har aldrig været et endeligt API-forslag, endsige en implementering.

Så jeg tvivler på, at der er noget, der er værd at teste i øjeblikket.

Kommentarer

  • Er der nogen oplysninger om den nuværende (2020) bedste defragmenteringspraksis på ext4 – eller en anbefaling om ikke at bruge noget eksisterende værktøj på grund af upålidelighed? Min e4defrag --version siger e4defrag 1.45.5 (07-Jan-2020).
  • Situationen har ikke ændret sig meget.Der var en tråd ikke længe efter, at jeg skrev ovenstående svar, som inkluderer et resumé af relevansen af e4defrag på tiden. Det er stadig en fuldt understøttet del af Ext4, men det kan ikke bruges i alle tilfælde (filsystemer med bigalloc kan ikke defragreres, datajournalering er uforenelig med defragging, og DAX-inoder og krypterede filer kan ikke flyttes). li>
  • Tak, Stephen. Betyder det, at kommandoen er sikker på en måde, at den redder inden en muligvis skadelig handling, så jeg kan bruge den uden risiko for mine data? (Grundlæggende fjernede jeg netop 750000 filer og spekulerede på, om disken nu kunne fragmenteres (det antager jeg, at den er), og om jeg skulle rense den eller lade den være.)
  • Som enhver filsystemhandling er det potentielt farligt, så brug det kun, hvis du har sikkerhedskopier (eller dataene er engangsbrug). Kommandoen er dog sikker, så vidt udviklerne ved det; hvis det støder på situationer, kan det ikke håndtere det stopper sikkert.
  • Skål. Der er stadig 3 TB data på disken, ingen sikkerhedskopi. Venter til jeg har en dag, hvor jeg føler mig dristig nok til at prøve 🙂

Skriv et svar

Din e-mailadresse vil ikke blive publiceret. Krævede felter er markeret med *