Jag har följande enheter med Linux Mint 18.1 på bärbara datorer och GNU / Linux Debian 9 på servern.

(Alla är 64-bitars och med Cinnamon-skrivbord.)

Alla enheter är formaterade med ext4-filsystem ; RAID 1 görs med mdadm .

  1. Bärbar dator med 1 SSHD (får inte förväxlas med hårddisk).

  2. Bärbar dator med tre enheter: 2 x hårddiskar för konsumenter i RAID 1 och 1 x SSD.

  3. Server med 5 enheter: 4 x hårddiskar för företag i två gånger RAID 1 och 1 x SSD.

Jag har systemet på dessa SSD-enheter och jag skulle aldrig defragmentera en SSD.

Frågan handlar om HHD och en SSHD.

Jag hittade en gammal PDF som beskriver några fler funktioner till e4defrag .

  1. Varför måste filsystemet monteras enligt detta felmeddelande när man försöker defragmentera ett omonterat filsystem? Jag vill förstå varför det är: 

    Filesystem is not mounted

  2. Jag skulle vilja ha implementerat ledigt rymddefragmentering. AFAIK det är nu under granskning. Är det möjligt för mig att t.ex. kompilera e4defrag från källan med dessa alternativ tillgängliga eller hur som helst? 

    e4defrag -f /deviceOrDirectory

  3. Jag skulle gillar också att använda relevant datafunktion: 

    e4defrag -r /deviceOrDirectory

Jag har många relevanta skäl att tro att fragmenteringen på dessa maskiner saktar ner läshastigheten, exempel:

  1. Hämtad från servern med RAID 1 HDD: er: 

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

  2. Hämtad från den bärbara datorn med RAID 1 hårddiskar: 

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

Som du kan se kunde defragmenteringen inte ens lägga 31 blockfilen i ett stycke. Naturligtvis kan du hävda att det är en filmfil, så det spelar ingen roll. Det är sant, men bara i det här fallet.

Kommandot jag använder för att starta defragmenteringen:

  1. På servern: 

    sudo e4defrag -v /dev/md1

  2. På den bärbara datorn: 

    sudo e4defrag -v /raid1/

Det gör verkar inte ha någon roll, oavsett om jag åberopar kommandot med enhetsnamn eller en katalog.

Kan du peka mig i rätt riktning?

Kommentarer

  • Har du mätresultat som pekar på defragmentering som källa till långsam åtkomst? Om ja, vilka? I de flesta fall behöver du ' inte behöver göra manuell defragmentering på ext4-filsystem så länge det finns ' tillräckligt med ledigt utrymme för att tilldelningsalgoritmen automatiskt ska defragmentera den under normal drift.
  • @dirkt Inga mätningar har hittills gjorts. Jag argumenterar inte ' om det är eller inte är effektivt att defragmentera ext4 filsystem. Frågorna är tydliga: Hur man gör e4defrag -r och e4defrag -f.

Svar

e4defrag behöver filsystemet monteras eftersom det ber kärnans filsystemdrivrutin att utföra defragmenteringen, det gör det inte t gör det själv.

Vad gäller defragmentering av ledigt utrymme och relevant fildefragmentering slutfördes inte korrigeringsfilerna; det sista omnämnandet på relevant e-postlista går tillbaka till 2014 :

e4defrag finns i e2fsprogs, och koden håller fortfarande på att underhållas och förbättras. Dmitry Monakhov har särskilt lagt till en hel del ”torturtester” och hittat ett antal rasförhållanden i den underliggande kärnkoden. Han skickade nyligen också en kodrefaktor för kärnkoden som förbättrade den avsevärt och (krympte storleken på ext4 med 550 rader kod).

Med detta sagt har det inte skett någon verklig funktionsutveckling för e4defrag på ganska lång tid. Det har diskuterats om vad kärn-API: er kan stödja den här funktionen, men det har aldrig funnits ett slutfört API-förslag, än mindre en implementering.

Så jag tvivlar på att det finns något som är värt att testa just nu.

Kommentarer

  • Finns det någon information om den aktuella (2020) bästa defragmenteringen på ext4 – eller en rekommendation att inte använda något befintligt verktyg på grund av opålitlighet? Min e4defrag --version säger e4defrag 1.45.5 (07-Jan-2020).
  • Situationen har inte förändrats mycket.Det fanns en tråd inte länge efter att jag skrev ovanstående svar, som innehåller en sammanfattning av relevansen av e4defrag vid tiden. Det är fortfarande en fullständigt stödd del av Ext4, men det kan inte användas i alla fall (filsystem med bigalloc kan inte defragreras, datadagbok är oförenligt med defragging och DAX-inoder och krypterade filer kan inte flyttas). li>
  • Tack, Stephen. Betyder det att kommandot är säkert i en mening att det kommer att räddas före en eventuellt skadlig åtgärd så att jag kan använda det utan risk för mina uppgifter? (I grund och botten tog jag bort 750000 filer och undrade om skivan nu kunde splittras (jag antar att den är) och om jag ska rengöra den eller lämna den.)
  • Som alla filsystemsfunktioner är det potentiellt farligt, så använd det bara om du har säkerhetskopior (eller om data är disponibla). Kommandot är dock säkert så långt dess utvecklare känner till; om det stöter på situationer kan det inte hantera det stannar säkert.
  • Skål. Det finns fortfarande 3 TB data på disken, ingen säkerhetskopia. Ska vänta tills jag har en dag där jag känner mig vågad att prova 🙂

Lämna ett svar

Din e-postadress kommer inte publiceras. Obligatoriska fält är märkta *