Impossibile scrivere sul disco ma il disco non è pieno

Sto usando Ubuntu 12.04 e non riesco a scrivere su alcun file, nemmeno come root, né faccio altre operazioni che richiedono la scrittura. Nemmeno un processo che deve essere scritto può fallire. dfdice che ho un sacco di spazio:

Filesystem      Size  Used Avail Use% Mounted on
/dev/xvda1       30G   14G   15G  48% /
udev            984M  4.0K  984M   1% /dev
tmpfs           399M  668K  399M   1% /run
none            5.0M     0  5.0M   0% /run/lock
none            997M     0  997M   0% /run/shm

Tutti i risultati che trovo per "impossibile scrivere su disco" riguardano dischi legittimi completi. Non so nemmeno da dove iniziare qui. Il problema è apparso dal nulla questa mattina.

L'ultima voce di registro di PHP è:

non riuscito: spazio libero sul dispositivo (28)

Vim dice:

Impossibile aprire (file) per la scrittura

Altre applicazioni danno errori simili.

Dopo aver eliminato ~ 1 GB solo per essere sicuri, il problema rimane. Ho anche riavviato.

df -i dice

Filesystem      Inodes   IUsed  IFree IUse% Mounted on
/dev/xvda1     1966080 1966080      0  100% /
udev            251890     378 251512    1% /dev
tmpfs           255153     296 254857    1% /run
none            255153       4 255149    1% /run/lock
none            255153       1 255152    1% /run/shm

hard-drive filesystems diskmanagement

— felwithe
fonte

Pubblica l'output di "df -i".

— SEE

@EEAA modificato in. Hai ragione, df -i dice 100%. Cosa significa questo? Perché sarebbe diverso?

— Felwithe

IIRC, troppi file in una singola directory avranno sintomi simili se non identici. Ciò che è "troppi" varierà tra i file system.

— Salterio,

Risposte:

Sei fuori dagli inode. È probabile che tu abbia una directory da qualche parte con molti file molto piccoli.

— EEAA
fonte

Volevo solo aggiungere che non sapevo nemmeno che rm potesse fallire. Questa è stata un'educazione.

— Felwithe

@Felwithe, posso immaginare che find . -name sess\* -exec rm {} +avrebbe funzionato.

— Carsten S,

@felwithe Quello che gli altri hanno suggerito. rm probabilmente ha funzionato bene, ma la shell ha espanso il *glob in troppi dati e ha funzionato prima ancora che arrivasse al punto di invocare rm.

— un CVn il

@CarstenS: o find . -name sess\* -deleteche trovo più facile da ricordare, ed è generalmente più efficiente.

— Salterio,

@Kaslai il limite non c'è RAM, ma il limite di sistema ARG_MAX. Sfortunatamente lo standard POSIX non specifica esattamente come vengono misurati gli argomenti della riga di comando rispetto a ARG_MAX. Alcune implementazioni non hanno limiti e quindi non definiscono ARG_MAX, ma questa non è un'opzione popolare in quanto impedisce la compilazione di troppi programmi.

— James Youngman,

Apparentemente, l'OP ha una risposta per il loro problema particolare. Tuttavia, per completezza, i sintomi dell'OP possono verificarsi anche se il filesystem è stato rimontato in sola lettura. Questo mi è successo usando una macchina virtuale Linux la cui memoria era su un sistema a dischi cluster che presentava rari guasti intermittenti. Occasionalmente, i guasti causerebbero il rimontaggio dei filesystem in sola lettura. Il sintomo esterno alla fine osservabile era che vari servizi non rispondevano quando la RAM si riempiva (con scritture del disco non lavabili).

All'epoca l'unica soluzione era riavviare il sistema (perdendo qualsiasi registro non scritto che esistesse). Tentativi di rimontaggio RW non riusciti. (Sfortunatamente, non ricordo i messaggi di errore restituiti durante il tentativo di questi rimontaggi.)

Quindi, ..., non il problema del PO, ma qualcun altro che arriva su questa pagina può beneficiare di queste informazioni.

— Eric Towers
fonte

No in realtà; quando il filesystem è stato rimontato in sola lettura, viene visualizzato un errore che indica che il file system è di sola lettura, non esaurito.

— psusi,

@psusi: non l'ho fatto. Ho avuto vari errori, incluso "filesystem full". Se questo è cambiato negli ultimi due o tre anni, sarebbe una buona cosa.

— Eric Towers,

Ho provato a spostare un file in un file system ZFS di sola lettura su Linux proprio l'altro giorno. L'errore diceva chiaramente "file system di sola lettura".

— un CVn il

No; è stato così per oltre 30 anni. Una scrittura in sola lettura fs restituisce -EROFS; una scrittura su un fs completo restituisce -ENOSPC.

— psusi,

@psusi: Vedo che vivi nell'universo fantasy in cui i programmatori fanno sempre la cosa giusta invece di inventare i propri messaggi di errore. Non mi sembra di vivere lì.

— Eric Towers,