échec de Fallocate: opération non prise en charge

10

Lors de l'exécution,

fallocate -l 10G /path/to/file

Je reçois l'erreur suivante:

fallocate: file: fallocate failed: Operation not supported

La création du fichier à l'aide de dd (if = / dev / zero ou if = / dev / urandom) fonctionne, mais si j'essaie de créer de gros fichiers, des dizaines de Go en taille, cela prend plusieurs heures.

Exécuter Ubuntu 14.04. En utilisant une partition ext4, la spécification d'un type de fichier ne semble pas modifier le résultat.

Fonctionne très bien sur mes machines CentOS6, mais pas Ubuntu.

— John J Johnson
source

quel système de fichiers utilisez-vous?

— g_p

Mettez-nous également à jour le type de fichier que vous créez.

— vembutech

Avec ext4, le type de fichier ne semble pas avoir d'importance. Que je crée un fichier vierge, un .txt, un .img, je reçois la même erreur.

— John J Johnson

11

Si les fichiers épars vous conviennent (par exemple, vous voulez créer une image afin de la remplir avec un système de fichiers), ils sont créés en un rien de temps

100 Go prennent 3 millisecondes:

# time dd if=/dev/zero of=tmptst.dat bs=1G seek=100 count=0
0+0 records in
0+0 records out
0 bytes (0 B) copied, 0,00037726 s, 0,0 kB/s

real    0m0.003s
user    0m0.000s
sys 0m0.002s

Le fichier résultant:

# ls -lh tmptst.dat
-rw-r--r-- 1 root root 100G 2015-01-22 16:39 tmptst.dat

Sa taille réelle en ce moment: 0 octets

# ls -lsh tmptst.dat
0 -rw-r--r-- 1 root root 100G 2015-01-22 16:39 tmptst.dat

— murxo
source

Cela concernait la création d'un conteneur dm-crypt / LUKS, fonctionnant sous l'hypothèse que la création d'un conteneur à l'aide de / dev / urandom serait plus sécurisée que la création d'un conteneur avec / dev / zero et son remplissage progressif avec des données. J'ai appris depuis que l'utilisation de Fallocate n'aurait pas résolu mon problème, car la vitesse lente était simplement une limitation de la vitesse de fonctionnement du pRNG de / dev / urandom, mais je n'ai toujours aucune idée pourquoi Fallocate lui-même refuse de fonctionner. Vive la réponse cependant, acceptée comme j'imagine après tout ce temps, c'est la meilleure réponse que j'aurai haha.

— John J Johnson

Je me demande si fallocate ne peut pas se replier pour faire la même chose? Cela aurait du sens pour moi.

— unfa

3

Si vous ne vous souciez pas du contenu, mais avez simplement besoin de données,

Tout d'abord,

dd if=/dev/urandom of=tmp.txt bs=1M count=1

Cela créera,

-rw-r--r-- 1 root root 1.0M Oct 17 00:30 tmp1.txt.

Ensuite, si vous souhaitez créer un fichier 10M, utilisez le fichier généré ci-dessus pour l'ajouter à plusieurs reprises,

for i in {1..10}; do dd if=tmp.txt of=tmp1.txt bs=1M oflag=append conv=notrunc; done;

— user1234
source

2

J'ai également rencontré ce problème.

Un lien symbolique dans le chemin du répertoire semble être le problème. essayez la même commande sur / tmp et cela devrait fonctionner.

J'ai pu contourner le problème en ajoutant un «-x» à la commande fallocate. Cela a forcé le «mode posix», et cela devrait prendre plus de temps.

Même si le système de fichiers était ext4, le lien symbolique provoquait l'erreur «non pris en charge sur ce système de fichiers». En fait, si je suis allé directement au nom du répertoire (sans aucun lien symbolique), l'appel à fallocate () a fonctionné.

A1: ne pas avoir de liens symboliques n'importe où dans le nom de chemin complet du fichier que vous créez.

A2: utilisez le '-x', même si cela prend plus de temps.

b \ 375

— Brett Bolen alias Wing Ed Lizard
source