Les fichiers de courte durée sont-ils vidés sur le disque?

Mon programme crée de nombreux petits fichiers de courte durée. Ils sont généralement supprimés dans la seconde qui suit leur création. Les fichiers sont dans un système de fichiers ext4 soutenu par un vrai disque dur. Je sais que Linux vide périodiquement ( pdflush) les pages sales du disque. Étant donné que mes fichiers sont de courte durée, ils ne sont probablement pas mis en cache par pdflush. Ma question est, mon programme provoque-t-il beaucoup d'écritures sur disque? Ma préoccupation est la vie de mon disque dur.

Étant donné que les fichiers sont petits, supposons que la somme de leur taille est inférieure à dirty_byteset dirty_background_bytes.

Ext4 a le journal par défaut activé, c'est-à-dire le journal des métadonnées. Je veux également savoir si les métadonnées ou les données sont écrites sur le disque.

Une expérience simple avec ext4:

Créer une image de 100 Mo ...

# 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

Faites-en un appareil en boucle ...

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

Faire un système de fichiers et monter ...

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

Faites une sorte de course avec des fichiers de courte durée. (Changez ceci pour n'importe quelle méthode que vous préférez.)

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

Montez, synchronisez, déverrouillez.

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

Vérifiez le contenu de l'image.

# 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

Dans mon cas, il a répertorié tous les noms de fichiers, mais aucun du contenu du fichier. Donc, seul le contenu n'a pas été écrit.

À moins que vous ne parliez d'un disque SSD, un nombre élevé d'écritures sur disque ne sera pas le facteur dominant de la longévité du disque.

Si vous voulez vraiment éviter les écritures sur disque, regardez dans tmpfs ,

En règle générale, non, ils ne seront pas écrits. En effet, le cache vide les pages sales lorsqu'une des deux conditions est remplie:

1. Les données sont vieillies après /proc/sys/vm/dirty_writeback_centisecs, ce qui par défaut est de 5 secondes.

2. Il y a trop peu de mémoire pour le cache pour contenir les données, plus que dirty_ratiodes pages sales dans le cache (par défaut à 20%).

Donc, sur un système avec beaucoup de mémoire libre et peu de trafic d'écriture en dehors de vos petits fichiers supprimés en moins de 5 secondes, les données ne seront pas vidées.

Que les fichiers de courte durée soient écrits sur le disque ou non dépend non seulement du comportement par défaut du cache de fichiers du noyau, mais également des détails de l'implémentation du pilote du système de fichiers et des options de montage dudit système de fichiers. Il est possible de configurer le système de telle manière que tout soit toujours immédiatement écrit sur le disque (essentiellement, un comportement de type DOS).

Un système de fichiers, mettant en évidence le comportement qui vous intéresse (appelé "allocation retardée") est XFS. Avec cela, vous pouvez être plus ou moins sûr (étant donné aucune option de configuration amusante ailleurs) que les blocs appartenant aux fichiers juste supprimés seront réutilisés en mémoire, sans accès intermédiaire au disque. XFS peut toujours vouloir mettre à jour son journal de métadonnées (qui sera écrit sur le disque assez fréquemment; pourtant, étant donné que le journal de XFS est uniquement des métadonnées, il est assez petit pour être défini sur un autre appareil rapide, comme la RAM sauvegardée par batterie trouvée sur de nombreux contrôleurs RAID).

En raison de ce comportement, il n'est pas rare de trouver des fichiers complètement remis à zéro, mais sinon légitimes (taille et autres métadonnées intactes) sur un système de fichiers XFS après une coupure de courant soudaine. C'est un coût de prise en charge des opérations de fichiers "semi-temporaires" rapides.

Un peu de théorie

En général, un appel système accédant à un système de fichiers se termine, assez rapidement, par la méthode définie par le pilote du système de fichiers (attachée à "struct inode_operations" et "struct file_operations" lorsque le pilote VFS est enregistré). Ce qui se passe ensuite est laissé à la seule discrétion de l'implémentation du système de fichiers. En règle générale, quelque chose ressemblant à l'approche suivante est utilisé (cet exemple simple provient du pilote Linux FAT):

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

Si le système de fichiers est monté en mode "sync", toutes les modifications vont immédiatement sur le disque (via fat_sync_inode () dans ce cas). Sinon, le bloc est marqué comme "sale" et reste dans le cache mémoire jusqu'à ce qu'il soit vidé à une occasion raisonnable.

Ainsi, il est impossible de prédire le comportement du système en ce qui concerne les fichiers transitoires sans prendre en compte les options de montage du système de fichiers et inspecter le code source de son implémentation (cela, bien sûr, s'applique principalement à toutes sortes de systèmes de fichiers exotiques principalement trouvés dans l'espace embarqué) .