I file di breve durata vengono scaricati sul disco?

9

Il mio programma crea molti piccoli file di breve durata. In genere vengono eliminati entro un secondo dalla creazione. I file si trovano in un file system ext4 supportato da un vero disco rigido. So che Linux scarica periodicamente ( pdflush) le pagine sporche su disco. Poiché i miei file sono di breve durata, molto probabilmente non vengono memorizzati nella cache pdflush. La mia domanda è: il mio programma causa molte scritture su disco? La mia preoccupazione è la vita del mio hard disk.

Poiché i file sono piccoli, supponiamo che la somma delle loro dimensioni sia inferiore di dirty_bytese dirty_background_bytes.

Ext4 ha il journal predefinito attivato, ovvero il journal dei metadati. Voglio anche sapere se i metadati oi dati sono scritti sul disco.

linux disk ext4

— Wu Yongzheng
fonte

> Il mio programma crea molti piccoli file di breve durata quanto costa "molto"? Stai eliminando questi file o riscrivendo i file? > Voglio anche sapere se i metadati oi dati sono scritti sul disco. Ritengo che sia stata ordinata la modalità metadati predefinita, il che significa che i metadati vengono impegnati prima che i dati vengano scritti sul disco. Naturalmente ci sono opzioni di mount che puoi aggiungere per cambiarlo. > La mia domanda è: il mio programma causa molte scritture su disco? questo è difficile rispondere a considerare le informazioni che hai fornito. Hai preso in considerazione l'utilizzo di strumenti come iotop e sysstat per monitorare l'IO del disco?

— AngryWombat,

ReiserFS è meglio per file di piccole dimensioni se in realtà vuoi che colpiscano il disco sempre tmpfs va bene se non ti interessa

— xenoterracide

Alcuni chiarimenti: (1). il file system ext4 non è montato con l' syncopzione. Puoi considerare un fedora, un debian o un ubuntu installati di default. Ne scegli uno. (2). Ogni file è di circa 60 KB. (3). Circa 1000 file vengono creati ed eliminati al secondo, ma non esistono più di 10 file in qualsiasi momento. In altre parole, il throughput I / O è grande ma lo spazio occupato è piccolo.

— Wu Yongzheng,

5

Un semplice esperimento con ext4:

Crea un'immagine da 100 MB ...

# dd if=/dev/zero of=image bs=1M count=100
100+0 records in
100+0 records out
104857600 bytes (105 MB) copied, 0.0533049 s, 2.0 GB/s

Trasformalo in un dispositivo loop ...

# losetup -f --show image
/dev/loop0

Crea filesystem e monta ...

# mkfs.ext4 /dev/loop0
# mount /dev/loop0 /mnt/tmp

Fai una specie di corsa con file di breve durata. (Cambia questo con qualsiasi metodo tu preferisca.)

for ((x=0; x<1000; x++))
do
    (echo short-lived-content-$x > /mnt/tmp/short-lived-file-$x
     sleep 1
     rm /mnt/tmp/short-lived-file-$x ) &
done

Smonta, sincronizza, sblocca.

# umount /mnt/tmp
# sync
# losetup -d /dev/loop0

Controlla il contenuto dell'immagine.

# strings image | grep short-lived-file | tail -n 3
short-lived-file-266
short-lived-file-895
short-lived-file-909
# strings image | grep short-lived-content | tail -n 3

Nel mio caso ha elencato tutti i nomi dei file, ma nessuno dei contenuti del file. Quindi solo i contenuti non sono stati scritti.

— frostschutz
fonte

Bel tentativo. Adesso sono convinto. Ho anche provato ext2 e ho ottenuto lo stesso risultato come te. Ho modificato il tuo carico di lavoro di I / O parallelo in uno sequenziale e ho ottenuto un file 999 di breve durata e un contenuto 8 di breve durata *. Qualcuno ha qualche spiegazione?

— Wu Yongzheng,

@msw: modificato nel caso in cui non fosse chiaro. Altrimenti, per favore, elabora.

— frostschutz,

È solo sciocco. I file esistono contemporaneamente, non c'era nulla da sovrascrivere e i file system non sovrascrivono il contenuto dei file cancellati poiché ciò danneggerebbe le prestazioni. Ma in ogni caso, usa nbde registra il traffico (o un metodo simile per tracciare tutte le scritture).

— frostschutz,

7

A meno che non si parli di un'unità a stato solido, un elevato numero di scritture su disco non sarà il fattore dominante nella longevità dell'unità.

Se vuoi davvero evitare le scritture su disco, cerca in tmpfs ,

— rifiuti solidi urbani
fonte

2

tmpfs è davvero adatto in questo caso, ma voglio ancora sapere, come una domanda generale sul sistema operativo, i dati sono scritti su disco (inutilmente)?

— Wu Yongzheng,

La tua domanda dovrebbe essere molto più specifica di quanto tu possa probabilmente formulare per ricevere una risposta definitiva. La cache del buffer media un complicato compromesso tra prestazioni e persistenza a cui non è possibile rispondere in astratto. Utilizzando gli strumenti elencati in @AngryWombat è possibile misurare le scritture effettive in base alla propria applicazione specifica, ma ci sono così tanti fattori che potrebbero farla variare da corsa a corsa.

— msw,

Bene, se pdflush arriva dopo che il file è stato eliminato. Scriverlo non sarebbe necessario.

— Wu Yongzheng,

1

Come regola generale, no, non saranno scritti. Questo perché la cache elimina le pagine sporche quando si verifica una delle due condizioni:

I dati sono scaduti dopo /proc/sys/vm/dirty_writeback_centisecs, il cui valore predefinito è 5 secondi.
Memoria insufficiente per la cache per contenere i dati, più delle dirty_ratiopagine sporche nella cache (impostazione predefinita al 20%).

Quindi su un sistema con molta memoria libera e poco traffico di scrittura oltre ai file di piccole dimensioni che vengono eliminati in meno di 5 secondi, i dati non verranno scaricati.

— psusi
fonte

0

Il fatto che i file di breve durata vengano scritti o meno sul disco dipende non solo dal comportamento predefinito della cache dei file del kernel, ma anche dai dettagli dell'implementazione del driver del file system e dalle opzioni di montaggio di detto file system. È possibile configurare il sistema in modo tale che tutto venga sempre immediatamente annotato sul disco (essenzialmente, comportamento simile a DOS).

Un file system, caratterizzato in modo evidente dal comportamento che ti interessa (il cosiddetto "allocazione ritardata") è XFS. Con esso puoi essere più o meno sicuro (dato che non ci sono opzioni di configurazione divertenti altrove) che i blocchi appartenenti a file cancellati verranno riutilizzati in memoria, senza accesso al disco intermedio. XFS potrebbe ancora voler aggiornare il suo journal dei metadati (che verrà scritto su disco piuttosto frequentemente; tuttavia, dato che il journal di XFS è solo metadata, è abbastanza piccolo da essere impostato su qualche altro dispositivo veloce, come la RAM con batteria trovata su molti controller RAID).

A causa di questo comportamento, non è raro trovare file completamente azzerati, ma altrimenti file dall'aspetto legittimo (dimensioni e altri metadati intatti) su un file system XFS dopo un'interruzione improvvisa dell'alimentazione. Tale è un costo per supportare operazioni di file "semi-temporanee" veloci.

Qualche teoria

In generale, una chiamata di sistema che accede a un file system termina, piuttosto rapidamente, nel metodo definito dal driver del file system (allegato a "struct inode_operations" e "struct file_operations" quando il driver VFS è registrato). Ciò che accade dopo ciò è lasciato esclusivamente alla discrezione dell'implementazione del file system. In genere, viene utilizzato qualcosa simile al seguente approccio (questo semplice esempio viene dal driver FAT di Linux):

if (IS_DIRSYNC(dir))
    (void)fat_sync_inode(dir);
else
    mark_inode_dirty(dir);

Se il file system è montato in modalità "sync", tutte le modifiche passano immediatamente al disco (tramite fat_sync_inode () in questo caso). Altrimenti, il blocco viene contrassegnato come "sporco" e rimane nella cache di memoria fino a quando non viene scaricato in qualche ragionevole occasione.

Pertanto, è impossibile prevedere il comportamento del sistema rispetto ai file transitori senza considerare le opzioni di montaggio del file system e ispezionare il codice sorgente della sua implementazione (questo, ovviamente, si applica principalmente a tutti i tipi di file system esotici che si trovano principalmente nello spazio incorporato) .

— oakad
fonte

Grazie per la tua risposta. Sembra che ext4 abbia anche ritardato l'allocazione. Significa che la mia risposta è NO? (date altre opzioni di configurazione divertenti altrove). Significa anche che la mia risposta è SÌ se si utilizza ext2?

— Wu Yongzheng,

Penserei che anche con ext2 sul kernel moderno la risposta sarà NO. Questo particolare problema è stato discusso molto e una breve occhiata al sorgente del kernel mostra che il driver ext2 si basa principalmente su operazioni del kernel "predefinite" per fare le sue cose (quindi, tutto è ritardato dalla cache dei blocchi). Suppongo che dovrei aggiornare la mia risposta per includere alcune informazioni extra.

— Oakad,

Il mio ext4 ovviamente non è montato con l' syncopzione. Non lo farei mai.

— Wu Yongzheng,

Quando si contrassegna un inode sporco, presumo che il file system sia responsabile per contrassegnare la pagina corrispondente sporca. Successivamente, quando l'inode viene eliminato, il file system pulisce la pagina sporca? In caso contrario, i dati verranno scaricati sul disco inutilmente.

— Wu Yongzheng,

2

I blocchi di dati non utilizzati vengono "rilasciati", quindi smettono di essere sporchi. Se hai scritto alcune cose da archiviare e poi le hai troncate prima di svuotare, la spazzatura oltre l'EOF scompare (una specie di). Con i metadati potrebbe non essere così semplice perché potrebbero esserci vari compromessi sull'integrità delle strutture di dati del file system. A proposito, non è ovvio dalla tua domanda che ti aspetti sempre di avere il pieno controllo della tua piattaforma - la maggior parte delle applicazioni di solito finisce su macchine di configurazione sconosciuta, lontano dallo sviluppatore.

— Oakad,