Mon moteur de recherche en texte intégral stocke les données indexées sur le serveur NFS. En raison de la fréquence des lectures/écritures, je souhaite préallouer un espace disque continu important pour chaque fichier de table et j'ai donc recours à posix_fallocate. Sur un volume NFS, ma petite démonstration a échoué avec "EOPNOTSUPP" en réponse à posix_fallocate. Est-ce que le protocole/spécification NFS inclut le scénario posix_fallocate ?
Réponse
Trop de publicités?
Anon
Points
13
NFS 4.2 (et probablement les versions ultérieures) de NFS puede supporte fallocate sous Linux ( http://wiki.linux-nfs.org/wiki/index.php/Fallocate ) mais :
- Votre client et votre serveur doivent utiliser NFS 4.2 ou une version ultérieure.
- Un serveur NFS 4.2+ ne DOIT pas implémenter fallocate - c'est optionnel ( https://sourceware.org/ml/libc-alpha/2015-05/msg00062.html ).
Vous ne pouvez jamais savoir si un logiciel glibc posix_fallocate sera réel ou émulé sans vérifier manuellement à l'avance si un appel natif de la plate-forme sera réel ou émulé. fallocate a échoué ou n'était pas supporté (et si vous avez fait l'appel natif, pourquoi avez-vous eu besoin de la variante posix ?) De plus, les différentes plates-formes ont un appel syscall différent (ou complètement absent) pour l'appel natif de fallocate donc si la portabilité sur des plates-formes non-Linux est une préoccupation, vous devrez écrire le code natif approprié. fallocate pour chaque plateforme. Si vous devez faire de la pré-allocation même si ce qui est en dessous de vous n'a pas d'appel supporté pour cela, vous devrez revenir à le faire à la main (par exemple, via de belles écritures ou des hacks comme la fonction posix_fallocate ...).
Note : Lorsqu'il est possible de procéder à une véritable pré-affectation (par exemple, par le biais de fallocate ), il peut être DRAMATIQUEMENT plus rapide que les écritures complètes, car le système de fichiers peut s'en charger en définissant simplement les métadonnées appropriées.
