Perché un NAS segnala spazio libero ma rifiuta nuovi file di grandi dimensioni?
Un NAS può mostrare capacità libera, ma rifiutare un file di grandi dimensioni quando la quota della destinazione, i metadati, il limite dei file o lo spazio allocabile scrivibile sono esauriti.
Il pannello di controllo può riportare lo spazio disponibile dell’intero pool, mentre la condivisione appartiene a un dataset più piccolo, a un volume thin, a una quota utente, a un filesystem riservato o a un profilo dei metadati quasi esaurito. Un caricamento di grandi dimensioni può inoltre richiedere spazio temporaneo, una seconda copia o una dimensione del singolo file che il filesystem di destinazione non è in grado di rappresentare. Inizia dal percorso esatto che genera l’errore e dal relativo codice, invece di presumere che il valore principale dello spazio libero descriva l’operazione.
Identifica il filesystem e il limite effettivamente utilizzati dalla condivisione
Risolvi la condivisione SMB o dell’applicazione nel relativo percorso host, punto di montaggio, dataset, sottovolume, volume thin e pool sottostante. Registra i blocchi liberi, gli inode disponibili, l’identità dell’utente e la dimensione del file rifiutato.
GNU spiega che df segnala il filesystem montato associato a un percorso, non ogni pool, quota, snapshot o limite a livello di applicazione presente sopra o sotto di esso.
Se la condivisione scrive su una partizione di sistema o su un dataset montato più piccolo, lo spazio libero dell’intero pool è irrilevante. Correggi il percorso o il punto di montaggio prima di eliminare dati dal livello di archiviazione sbagliato.
Controlla le quote utente, di gruppo, del dataset e della condivisione
Confronta la vista dello spazio libero dell’amministratore con la quota applicata all’utente SMB, al gruppo, al dataset, al progetto o alla cartella condivisa effettivi. Esegui il test con lo stesso account che riceve l’errore.
Oracle documenta che le quote e le riserve ZFS possono limitare un singolo dataset anche quando rimane spazio inutilizzato nel pool oppure riservare la capacità disponibile a un altro dataset.
Non rimuovere globalmente le quote. Aumenta solo il limite dimostratosi insufficiente oppure sposta il file in un dataset la cui politica di capacità sia adatta al carico di lavoro.
Confronta lo spazio dati con i metadati e lo spazio di lavoro per l’allocazione
Controlla i contatori relativi a dati, metadati, allocazione di sistema, gruppi di blocchi e riserve specifiche del filesystem. La creazione di un file di grandi dimensioni può richiedere aggiornamenti dei metadati e spazio di lavoro per la copia su scrittura, oltre ai byte del contenuto.
La documentazione di Btrfs osserva che può restituire ENOSPC nonostante lo spazio libero visibile quando non è possibile soddisfare i requisiti di allocazione e copia su scrittura.
Se i metadati sono limitati, usa gli strumenti diagnostici supportati dal filesystem e interventi di ripristino mirati. Non riempire lo spazio rimanente con un altro file di test di grandi dimensioni e non avviare un bilanciamento non filtrato senza aver misurato lo spazio di lavoro disponibile.
Controlla gli inode e i limiti dei record dei file
Registra gli inode o i record dei file disponibili e conta i file di piccole dimensioni nelle cache, negli archivi di posta, nelle miniature, nei pacchetti estratti e nelle directory delle applicazioni. Una grande capacità in byte non garantisce che sia possibile allocare un’altra voce di directory o un altro record di metadati.
La panoramica dei filesystem di Red Hat spiega che XFS alloca dinamicamente gli inode e che le implementazioni dei filesystem hanno limiti distinti per inode e record dei file.
Se gli inode sono esauriti, rimuovi o archivia una cache verificata con un numero elevato di file tramite l’applicazione che la gestisce. Eliminare un singolo file di grandi dimensioni non risolverà una carenza di record dei file.
Verifica la dimensione massima dei file e il formato della destinazione
Identifica il filesystem di destinazione e confronta la dimensione massima di un singolo file con quella del caricamento tentato. Includi i dischi rimovibili usati per la preparazione, le destinazioni di backup USB e le cartelle temporanee delle applicazioni.
La panoramica di Microsoft su NTFS mostra che la dimensione massima dei file dipende dalla progettazione del filesystem e dai parametri di allocazione; pertanto, lo spazio libero complessivo non supera il limite del formato per un singolo file.
Se l’errore si verifica vicino a una soglia costante, come 4 GB, controlla ogni filesystem intermedio e ogni percorso di caricamento. La formattazione distrugge i dati, quindi trasferisci prima i file verificati altrove prima di modificare il formato della destinazione.
Misura i requisiti temporanei, sparsi e di preallocazione
Verifica se il programma di caricamento scrive un file temporaneo, prealloca l’intera destinazione, conserva la versione precedente fino alla ridenominazione oppure estrae un archivio in file aggiuntivi. Registra l’allocazione di picco anziché solo la dimensione finale del file.
La chiamata di sistema fallocate riserva spazio su disco affinché le scritture successive non falliscano per mancanza di capacità; ciò significa che un’applicazione può rifiutare un file di grandi dimensioni prima di trasferirne tutti i dati.
Scegli una directory temporanea nel pool dati previsto oppure disabilita la preallocazione solo quando l’applicazione lo supporta in sicurezza. Mantieni spazio sufficiente per l’originale, la copia temporanea, i metadati e gli snapshot durante la sostituzione.
Riproduci l’errore esatto con un file controllato
Crea file di test inferiori e superiori alla dimensione che causa l’errore usando lo stesso utente, protocollo, percorso e applicazione. Acquisisci l’errore del client e il log del server senza riprovare ripetutamente con il file di produzione.
La guida di ZimaSpace per individuare l’uso imprevisto dello spazio NAS fornisce il metodo complementare per confrontare le cartelle visibili con l’allocazione effettiva del filesystem.
Il problema è risolto quando il limite dimostratosi responsabile — quota, metadati, inode, formato o spazio temporaneo — è stato corretto e un file più grande della precedente soglia di errore viene scritto, chiuso, riaperto e verificato correttamente. Interrompi le scritture se il filesystem diventa di sola lettura o segnala errori di corruzione o hardware.
Prodotti consigliati
Supporto e consigli
Altro da leggere
Plex può condividere una GPU con un altro container Docker?
Plex e un altro container possono spesso accedere alla stessa GPU, ma è necessario testare il supporto dei driver, la mappatura dei dispositivi, il...
Come capire se un errore di Plex proviene dal client o dal server
Riproduci lo stesso elemento su un altro client, confronta il percorso della sessione, quindi raccogli le prove dal server solo dopo che l’ambito ti...
Come configurare la cache di Plex e l’archiviazione temporanea per la transcodifica
Proteggi lo stato persistente di Plex collocando i file temporanei di transcodifica su un’unità locale adatta, quindi verifica la pulizia, lo spazio libero e...
