Qu'est-ce qui pourrait expliquer cette étrange gestion de fichiers clairsemés de / dans tmpfs?

Sur ma ext4partition de système de fichiers, je peux exécuter le code suivant:

fs="/mnt/ext4"

#create sparse 100M file on ${fs}
dd if=/dev/zero \
   of=${fs}/sparse100M conv=sparse seek=$((100*2*1024-1)) count=1 2> /dev/null

#show its actual used size before
echo "Before:"
ls ${fs}/sparse100M -s

#setting the sparse file up as loopback and run md5sum on loopback
losetup /dev/loop0 ${fs}/sparse100M 
md5sum /dev/loop0

#show its actual used size afterwards
echo "After:"
ls ${fs}/sparse100M -s

#release loopback and remove file
losetup -d /dev/loop0
rm ${fs}/sparse100M

qui donne

Before:
0 sparse100M
2f282b84e7e608d5852449ed940bfc51  /dev/loop0
After:
0 sparse100M

Faire la même chose sur tmpfs qu'avec:

fs="/tmp"

les rendements

Before:
0 /tmp/sparse100M
2f282b84e7e608d5852449ed940bfc51  /dev/loop0
After:
102400 /tmp/sparse100M

ce qui signifie essentiellement que quelque chose que je m'attendais à lire simplement les données, a fait "exploser le fichier" comme un ballon "?

Je m'attends à ce que cela soit dû à une prise en charge moins parfaite du fichier clairsemé dans le tmpfssystème de fichiers, et en particulier à cause de l'ioctl FIEMAP manquant, mais je ne sais pas ce qui cause ce comportement? Peux tu me dire?

Tout d'abord, vous n'êtes pas seul à vous interroger sur ce genre de problèmes.

Cela ne se limite pas à, tmpfsmais a été une préoccupation citée avec NFSv4 .

Si une application lit des "trous" dans un fichier clairsemé, le système de fichiers convertit les blocs vides en "vrais" blocs remplis de zéros et les renvoie à l'application.

Lorsque md5sumtente d'analyser un fichier, il choisit explicitement de le faire dans un ordre séquentiel , ce qui a beaucoup de sens en fonction de ce que md5sum tente de faire.

Comme il y a fondamentalement des "trous" dans le fichier, cette lecture séquentielle va (dans certaines situations) entraîner une copie lors d'une opération d'écriture pour remplir le fichier. Cela entre alors dans un problème plus profond quant à savoir si ou non fallocate()implémenté dans le système de fichiers prend en charge FALLOC_FL_PUNCH_HOLE.

Heureusement, non seulement cela prend en tmpfscharge mais il existe un mécanisme pour "creuser" les trous.

En utilisant l'utilitaire CLI, fallocatenous pouvons réussir à détecter et refaire ces trous.

Selon man 1 fallocate:

-d, --dig-holes
      Detect and dig holes.  This makes the file sparse in-place, without
      using extra disk space.  The minimum size of the hole depends on
      filesystem I/O  block size (usually 4096 bytes).  Also, when using
      this option, --keep-size is implied.  If no range is specified by
      --offset and --length, then the entire file is analyzed for holes.

      You can think of this option as doing a "cp --sparse" and then
      renaming the destination file to the original, without the need for
      extra disk space.

      See --punch-hole for a list of supported filesystems.

fallocatefonctionne au niveau du fichier et lorsque vous exécutez md5sum sur un périphérique de bloc (demandant des lectures séquentielles), vous trébuchez sur l'écart exact entre la façon dont le fallocate()syscall doit fonctionner. Nous pouvons le voir en action:

En action, en utilisant votre exemple, nous voyons ce qui suit:

$ fs=$(mktemp -d)
$ echo ${fs}
/tmp/tmp.ONTGAS8L06
$ dd if=/dev/zero of=${fs}/sparse100M conv=sparse seek=$((100*2*1024-1)) count=1 2>/dev/null
$ echo "Before:" "$(ls ${fs}/sparse100M -s)"
Before: 0 /tmp/tmp.ONTGAS8L06/sparse100M
$ sudo losetup /dev/loop0 ${fs}/sparse100M
$ sudo md5sum /dev/loop0
2f282b84e7e608d5852449ed940bfc51  /dev/loop0
$ echo "After:" "$(ls ${fs}/sparse100M -s)"
After: 102400 /tmp/tmp.ONTGAS8L06/sparse100M
$ fallocate -d ${fs}/sparse100M
$ echo "After:" "$(ls ${fs}/sparse100M -s)"
After: 0 /tmp/tmp.ONTGAS8L06/sparse100M

Maintenant ... cela répond à votre question de base. Ma devise générale est "devenir bizarre" alors j'ai creusé plus loin ...

$ fs=$(mktemp -d)
$ echo ${fs}
/tmp/tmp.ZcAxvW32GY
$ dd if=/dev/zero of=${fs}/sparse100M conv=sparse seek=$((100*2*1024-1)) count=1 2>/dev/null
$ echo "Before:" "$(ls ${fs}/sparse100M -s)"
Before: 0 /tmp/tmp.ZcAxvW32GY/sparse100M
$ sudo losetup /dev/loop0 ${fs}/sparse100M
$ echo "After:" "$(ls ${fs}/sparse100M -s)"
After: 1036 /tmp/tmp.ZcAxvW32GY/sparse100M
$ sudo md5sum ${fs}/sparse100M
2f282b84e7e608d5852449ed940bfc51  /tmp/tmp.ZcAxvW32GY/sparse100M
$ echo "After:" "$(ls ${fs}/sparse100M -s)"
After: 1036 /tmp/tmp.ZcAxvW32GY/sparse100M
$ fallocate -d ${fs}/sparse100M
$ echo "After:" "$(ls ${fs}/sparse100M -s)"
After: 520 /tmp/tmp.ZcAxvW32GY/sparse100M
$ sudo md5sum ${fs}/sparse100M
2f282b84e7e608d5852449ed940bfc51  /tmp/tmp.ZcAxvW32GY/sparse100M
$ echo "After:" "$(ls ${fs}/sparse100M -s)"
After: 520 /tmp/tmp.ZcAxvW32GY/sparse100M
$ fallocate -d ${fs}/sparse100M
$ echo "After:" "$(ls ${fs}/sparse100M -s)"
After: 516 /tmp/tmp.ZcAxvW32GY/sparse100M
$ fallocate -d ${fs}/sparse100M
$ sudo md5sum ${fs}/sparse100M
2f282b84e7e608d5852449ed940bfc51  /tmp/tmp.ZcAxvW32GY/sparse100M
$ echo "After:" "$(ls ${fs}/sparse100M -s)"
After: 512 /tmp/tmp.ZcAxvW32GY/sparse100M
$ fallocate -d ${fs}/sparse100M
$ echo "After:" "$(ls ${fs}/sparse100M -s)"
After: 0 /tmp/tmp.ZcAxvW32GY/sparse100M
$ sudo md5sum ${fs}/sparse100M
2f282b84e7e608d5852449ed940bfc51  /tmp/tmp.ZcAxvW32GY/sparse100M
$ echo "After:" "$(ls ${fs}/sparse100M -s)"
After: 0 /tmp/tmp.ZcAxvW32GY/sparse100M

Vous voyez que le simple fait d' effectuer les losetupmodifications modifie la taille du fichier clairsemé. Cela devient donc une combinaison intéressante de l'endroit où tmpfsle mécanisme HOLE_PUNCH fallocateet les périphériques de bloc se croisent.