Posso esaurire lo spazio su disco creando un numero molto elevato di file vuoti?

È noto che i file di testo vuoti hanno zero byte:

Tuttavia, ognuno di essi contiene metadati , che secondo la mia ricerca, sono memorizzati in inode e usano lo spazio .

Detto questo, mi sembra logico che sia possibile riempire un disco semplicemente creando file di testo vuoti. È corretto? In tal caso, quanti file di testo vuoti avrei bisogno di riempire un disco di, diciamo, 1 GB?

Per eseguire alcuni controlli, eseguo df -ima a quanto pare mostra la% di inode in uso (?) Anziché quanto pesano.

Filesystem             Inodes  IUsed    IFree IUse% Mounted on
udev                   947470    556   946914    1% /dev
tmpfs                  952593    805   951788    1% /run
/dev/sda2            28786688 667980 28118708    3% /
tmpfs                  952593     25   952568    1% /dev/shm
tmpfs                  952593      5   952588    1% /run/lock
tmpfs                  952593     16   952577    1% /sys/fs/cgroup
/dev/sda1                   0      0        0     - /boot/efi
tmpfs                  952593     25   952568    1% /run/user/1000
/home/lucho/.Private 28786688 667980 28118708    3% /home/lucho

Questo output suggerisce 28786688inode complessivi, dopodiché /dev/sda2verrà restituito il prossimo tentativo di creare un file nel filesystem di root (dispositivo ) ENOSPC("Nessuno spazio sul dispositivo").

Spiegazione: sul progetto originale del filesystem * nix, il numero massimo di inode è impostato al momento della creazione del filesystem. Lo spazio dedicato è assegnato per loro. È possibile esaurire gli inode prima di esaurire lo spazio per i dati o viceversa. Il file system Linux predefinito più comune ext4presenta ancora questa limitazione. Per informazioni sulle dimensioni degli inode su ext4, consultare la manpage per mkfs.ext4.

Linux supporta altri filesystem senza questa limitazione. Attivato btrfs, lo spazio viene allocato in modo dinamico. "La struttura dell'inode è relativamente piccola e non conterrà dati di file incorporati o dati di attributi estesi." (ext3 / 4 alloca dello spazio all'interno degli inode per gli attributi estesi ). Naturalmente è ancora possibile esaurire lo spazio su disco creando troppe voci di metadati / directory.

Pensandoci, tmpfs è un altro esempio di allocazione dinamica degli inode. È difficile sapere cosa df -isignificherebbe in pratica il numero massimo di inode riportati da questi filesystem. Non darei alcun significato al valore mostrato.

"XFS alloca anche gli inode in modo dinamico. Così fa JFS. Così ha fatto / fa reiserfs. Così fa F2FS. I filesystem Unix tradizionali allocano staticamente gli inode al momento di mkfs, e così fanno anche i moderni FS come ext4 che tracciano la loro eredità, ma oggi l'eccezione, non la regola.

"A proposito, XFS ti consente di impostare un limite sulla percentuale massima di spazio utilizzato dagli inode, in modo da poter esaurire gli inode prima di arrivare al punto in cui non puoi aggiungere a file esistenti. (L'impostazione predefinita è 25% per FS inferiore a 1 TB, 5% per file system fino a 50 TB, 1% per dimensioni superiori a quelle.) Comunque, questo utilizzo dello spazio sui metadati (inode e mappe di estensione) si rifletterà nei normali df -h"- Peter Cordes in un commento a questa risposta

La creazione di file vuoti implica l'utilizzo di quanto segue:

• inode, uno per file;
• voci di directory aggiuntive, anche una per file, ma aggregate.

Il numero di inode disponibili viene spesso determinato quando viene creato un file system e non può essere modificato (alcuni file system come Btrfs o XFS allocano gli inode in modo dinamico). Questo è ciò che viene misurato da df -i. Quando si esauriscono gli inode, non è possibile creare nuovi file o directory, anche se si dispone di spazio su disco.

Anche le voci della directory occupano spazio, dallo spazio disponibile sul disco. Puoi vederlo osservando la dimensione di una directory: è sempre un multiplo della dimensione del blocco e quando una directory contiene molti file, la sua dimensione aumenta. Se si esaurisce lo spazio su disco, potrebbe non essere possibile creare nuovi file o directory in una directory che è “piena” ( ovvero , dove l'aggiunta di un nuovo file comporterebbe l'allocazione di un nuovo blocco), anche se si hanno inode disponibili.

Quindi sì, è possibile esaurire lo spazio su disco usando solo file vuoti.

Argomento logico puro:

Un nome file è costituito da una quantità diversa da zero di byte. Anche con la massima compressione teorica in un ipotetico file system progettato per consentire la quantità massima assoluta di nomi di file, ogni nome di file consumerà comunque almeno un bit da qualche parte sul disco fisico. Probabilmente di più, ma "1 bit per file" è il minimo banale.

Calcola la quantità di bit che possono adattarsi ai tuoi piatti e che è un numero massimo teorico di file (vuoti o non vuoti) che puoi memorizzare su di esso.

Quindi la risposta è sì. Alla fine, rimarrai senza spazio, indipendentemente dallo spazio di archiviazione che stai utilizzando, se continui ad aggiungere file vuoti. Ovviamente ti esaurirai molto prima del massimo calcolato in questo modo, ma finirai.

Semplicemente no ma puoi esaurire gli inode su Linux che sarà lo stesso dello spazio esaurito.

puoi provare qualcosa del genere nella tua shell n=0; while :; do touch $n; let n=n+1; done

Assicurati solo di eseguirlo nella macchina virtuale o sarai fuori dagli inode molto velocemente.

Non è possibile riempire il disco creando file vuoti: il disco avrà ancora molto spazio per i nuovi file. Ma sì, puoi esaurire la fornitura limitata di inode gratuiti del filesystem - a quel punto non puoi creare nuovi file (anche se il tuo disco - per quanto riguarda lo spazio utilizzato - è praticamente vuoto). È solo l'elenco degli inode del filesystem che è stato usato, non il disco ... quindi il filesystem è pieno, mentre il disco è praticamente vuoto. La tabella di inode utilizza lo spazio sul disco, ma la tabella non cresce quando si aggiungono file, proprio come un foglio di carta non cresce quando si scrive sulle sue righe.

(una risposta in un commento di Baard Kopperud)