C'è un modo per fare in modo che i filesystem ext utilizzino meno spazio per se stessi in Linux?

Ho un sacco di HDD esterni e interni che uso su un sistema Linux. Ho solo sistemi Linux, quindi usare un file system Linux avrebbe senso, giusto? Tuttavia, attualmente sto usando NTFS ovunque, perché mi dà lo spazio più utilizzabile dagli HDD.

Vorrei ora passare ai file system Linux, principalmente a causa delle autorizzazioni e della compatibilità (ad esempio, non riesco a ridimensionare la mia partizione NTFS crittografata LUKS sotto Linux, continua a dirmi di chkdsk sotto Windows).

Tuttavia, quando ho formattato quei dischi rigidi, ho provato un sacco di filesystem diversi e ogni filesystem Linux, anche ext2 che per quanto ne so non ha journaling, ha usato molto spazio per se stesso. Non ricordo valori esatti, ma sono stati oltre 100 GB che NTFS mi ha dato di più su un HDD da 2 TB, il che è molto.

Quindi la mia domanda è: c'è un modo per fare in modo che i filesystem ext utilizzino meno spazio per se stessi? Oppure c'è un altro filesystem (ho provato ext2, ext3, ext4, NTFS e vfat - nessuno di loro si è avvicinato nemmeno allo spazio utilizzabile che NTFS mi ha offerto) con un supporto Linux perfetto e un grande spazio utilizzabile?

Mi piacerebbe sapere come e perché i filesystem (specialmente ext2 che non ha journaling) usano molto più spazio di NTFS e non so dove altro chiedere. Preferirei di gran lunga un modo per usare ext4 senza journaling e qualsiasi altra cosa che utilizza così tanto spazio, se possibile.

— coriandoli
fonte

Hai visto questa discussione ?

— Jake Gould

Ho, e ha spiegato cosa consuma lo spazio extra ma la differenza tra NTFS ed ext è MOLTO più grande che tra reiserfs ed ext, e mi chiedo se c'è un modo per ridurlo. Ad esempio su un HDD da 1 TB sono in grado di utilizzare 989 GB con NTFS. ext4 mi darebbe circa 909 GB.

— coriandoli

Giusto. Domanda decente e anche la risposta è illuminante.

— Jake Gould

come si misura effettivamente lo spazio disponibile? questo è importante perché, a seconda di quali valori guardi, potresti vedere o meno l'effetto della prenotazione del 5%, ad esempio, come indicato nella domanda collegata

— eMBee,

Tieni presente che l'inserimento nel journal di file system come ext3 ed ext4 è una buona cosa. È abbastanza facile perdere energia su un disco esterno o scollegarlo accidentalmente se si tratta di una USB, quando ciò accade, spesso non è un grosso problema perché si cura da sé usando il journal quando si avvia il backup. Senza quella rete di sicurezza, le cose sarebbero molto peggio. Non è solo un caso di più è meglio.

— Joe,

Risposte:

Per impostazione predefinita, ext2 e i suoi successori riservano il 5% del filesystem per l'utilizzo da parte dell'utente root. Ciò riduce la frammentazione e rende meno probabile che l'amministratore o qualsiasi demone di proprietà di root rimanga senza spazio su cui lavorare.

Questi blocchi riservati impediscono ai programmi che non vengono eseguiti come root di riempire il disco. Il fatto che queste considerazioni giustifichino la perdita di capacità dipende da cosa viene utilizzato il filesystem.

L'importo del 5% è stato fissato negli anni '80, quando i dischi erano molto più piccoli, ma sono stati lasciati così come sono. Oggi l'1% è probabilmente sufficiente per la stabilità del sistema.

La prenotazione può essere modificata usando l' -mopzione del tune2fscomando:

tune2fs -m 0 /dev/sda1

Ciò imposterà la percentuale di blocchi riservati su 0% (0 blocchi).

Per ottenere il valore corrente (tra gli altri), utilizzare il comando:

tune2fs -l <device>

— harrymc
fonte

Ciò spiegherebbe perfettamente l'immensa differenza nello spazio utilizzabile (poiché il 5% di 2 TB è 100 GB). I dischi non verranno utilizzati per nulla come root o relativi ai file di sistema, quindi penso che sarebbe opportuno salvarlo per disabilitarlo. Ho una domanda però: come fanno i programmi di proprietà root a sapere che c'è più spazio libero rispetto ai programmi non root? L'esecuzione dfcome non-root vs. root non mostra alcuna differenza.

— coriandoli

@confetti: Perché il VFS non rifiuta i loro tentativi di scrivere sul disco con un errore (fino a quando il volume non è effettivamente pieno, ovviamente).

— Ignacio Vazquez-Abrams,

tune2fs -l <device>dovrebbe dare questo valore tra gli altri. L'importo del 5% è stato fissato negli anni '80, quando i dischi erano molto più piccoli, ma sono stati lasciati così come sono. Oggi l'1% è probabilmente sufficiente per la stabilità del sistema.

— harrymc,

XFS riserva il più piccolo del 5% o 8192 blocchi (32 MiB), quindi la quantità riservata è generalmente minuscola rispetto alla dimensione del filesystem.

— Michael Hampton,

Grazie mille a tutti per le spiegazioni. Questo mi ha aiutato a capire molto. Prima il mio disco si riempiva completamente fino all'ultimo byte, eppure il mio sistema non si è guastato completamente, ora capisco perché.

— confetti,

se i dati che intendi archiviare sono comprimibili, btrfs montato con compress=zstd(o compress-force=zstd) probbalmente userebbe molto meno spazio su disco rispetto a ext *

questo renderà btrfs comprimere in modo trasparente i tuoi dati prima di scriverli su disco e decomprimerlo in modo trasparente durante la lettura. inoltre, ext4 pre-alloca tutti gli inode durante la creazione del filesystem, btrfs li crea in base alle esigenze, immagino che potrebbe risparmiare anche un po 'di spazio.

— hanshenrik
fonte

Ti dispiace aggiungere ulteriori informazioni a questa risposta? (Come funziona, cosa fa, forse un riferimento, ...)

— confetti

@confetti piace questo? patchwork.kernel.org/patch/9817875

— hanshenrik il

Mi piace davvero questa idea, ma sarebbe più utile avere maggiori informazioni su come ciò influirebbe sulla velocità e sulle prestazioni.

— confetti

@confetti, dal momento che stai usando un disco rigido, probabilmente migliorerà le prestazioni. Le CPU sono molto più veloci dei dischi rigidi che la parte lenta dell'accesso al disco sta ottenendo i dati dentro e fuori dal disco; il tempo impiegato per comprimere o decomprimere non sarà evidente.

— Segna il

D'altra parte, la maggior parte dei tipi di file di grandi dimensioni al giorno d'oggi (ad esempio immagini, audio, video, anche i formati di documenti di testo più ricchi) tendono ad essere già compressi e generalmente non beneficiano di una compressione aggiuntiva. Almeno non del semplice tipo generico eseguito a livello di filesystem.

— Ilmari Karonen,

Un altro punto di cui non si è ancora parlato è il numero di inode prenotati sul file system.

Per impostazione predefinita, mkfs crea un numero di inode che dovrebbe consentire di inserire molti file molto piccoli nel tuo file system. Se sai che i file saranno molto grandi e inserirai solo un piccolo numero di file nell'FS, puoi ridurre il numero di inode.

Stai attento! Questo numero (rispettivamente il rapporto tra spazio e numero di inode) può essere impostato solo al momento della creazione del file system. Anche quando si estende l'FS, il rapporto rimane lo stesso.

— glglgl
fonte

In alternativa, se sai che memorizzerai molti file molto piccoli, puoi aumentare il numero di inode e ridurre la dimensione del blocco in modo da non sprecare tanto spazio. (Ogni file deve consumare un minimo di un blocco, anche se è 1 byte. Usa ls -ls per confrontare le dimensioni con ciò che viene usato sul disco.)

— Perkins

@Perkins Hai ragione, ma penso che questo valga solo per file MOLTO piccoli: la dimensione del blocco predefinita è 4kiB (IIRC), quella minima è 1 kiB. Quindi non c'è molto da vincere, tranne per il fatto che il tuo disco è davvero pieno di quei file. Tuttavia, potrei immergermi in questo domani.

— glglgl

o in alternativa usa btrfs, che crea inode secondo necessità. mentre gli inode ext4 sono allocati al momento della creazione del filesystem e non possono essere ridimensionati dopo la creazione, con un limite massimo di 4 miliardi, gli inode di btrfs sono creati dinamicamente in base alle necessità e il limite rigido è 2 ^ 64, circa 18,4 quintilioni, che è circa 4,6 miliardi volte superiore al limite massimo di un ext4 massimo: p

— hanshenrik il

Mi ricorda di aver installato una bobina Usenet. ext4 memorizzerà piccoli (il limite è da qualche parte da 60-160 byte a seconda di molte cose) all'interno dell'inode stesso.

— signor spuratic

@hanshenrik Nota che hai la stessa limitazione di dimensione del blocco su btrfs (con un paio di modi extra per aggirare il problema), quindi devi ancora sapere che tipo di file (grande o piccolo o entrambi) stai per archiviare e ottimizza il tuo filesystem di conseguenza se vuoi spremere la massima quantità di memoria da esso. La disponibilità della compressione automatica aiuta parecchio se stai archiviando dati soffici.

— Perkins,