[ZFS] Faible débit lors de déplacements de fichiers

Bonjour à tous,

J’ai des gros problèmes de débit lors de déplacements de fichiers sur un fs ZFS en RAIDZ2. (serveur Promox 3.4-6, c’est à dire Debian 7/kernel 2.6.32)
Pour déplacer une trentaine de fichiers de moins de 100ko, il arrive parfois que ça mette plus de 3 minutes !
Ce n’est pas systématique mais par contre ça n’arrive toujours que lors de déplacements de fichier, jamais lors d’une copie.

La manipulation de déplacement de fichier se fait en NFS via nautilus. (et non en ssh car j’ai besoin de vérifier visuellement d’éventuel doublons)

Mon pool ZFS RAIDZ2 (2To) est sain :

root@host:~# zpool status
  pool: z2
 state: ONLINE
  scan: scrub repaired 0 in 1h31m with 0 errors on Mon Jun  6 16:32:59 2016
config:

    NAME                                       STATE     READ WRITE CKSUM
    z2                                         ONLINE       0     0     0
      raidz2-0                                 ONLINE       0     0     0
        ata-ST1000DM003-1ER162_W1R537V9-part1  ONLINE       0     0     0
        ata-ST1000DM003-1ER162_Z2Y45T97-part1  ONLINE       0     0     0
        ata-ST1000DM003-1ER162_Z4C3L8AZ-part1  ONLINE       0     0     0
        ata-ST1000DM003-1ER162_Z4Y2QUE3-part1  ONLINE       0     0     0

errors: No known data errors

La capacité disque disponible représente 35% (626Go) des 2To, mon serveur ne fait rien et j’ai plus de 6,5Go de RAM (sur 16Go) de libre.

Dernier test, réalisé ce matin : 1109 fichiers (< 500 ko chacun) à déplacer dans un répertoire de la même arborescence = 48 minutes !!!

Pour info, les temps d’accès en lecture sur ce pool sont tout à fait normaux : par ex, lecture d’une vidéo HD (1920x1080) MP4 sans aucune saccade.

Quelqu’un aurait-il une petite idée sur la cause éventuelle de cette rupture de débit, uniquement lorsque je déplace des fichiers, car je sèche depuis un certain temps là dessus ?

Merci d’avance pour votre aide,
Eric

Vous avez vous-même donné la réponse.
Je ne connais pas bien ‘nautilus’, mais je suppose qu’il est possible de mettre dans le presse papier les chemins des fichiers sélectionnés.

Vous dites ‘en NFS’, c’est-à-dire que vous faites des manipulations triviales ( un ‘mv’ en restant dans le même système de fichiers n’est qu’un renommage, une modification d’inodes, pas de déplacement du contenu ), triviales si on accède directement à la machine pour laquelle le système de fichiers et un vrai disque, pas un pseudo FS réseau (NFS).
Vous manipulez des métadonnées (les chemins) en passant par NFS. Ce protocole n’a pas été conçu pour cela (pour renommer 2 ou 3 fichiers, c’est bon, pour une centaine non.)

Ce n’est pas le volume des données qui joue, mais le nombre d’inodes manipulés et nombre total.

Pourquoi ne faites-vous pas :
ssh -X Machine nautilus
ouvrir un autre terminal et
ssh Machine
Dans ce terminal, vous lancez tmux ou screen et vous avez autant de terminaux distants que vous voulez.
Par exemple, un panneau pour lacer des commandes (file, identify …), un autre pour éditer un script qui lancera en local les manipulations, du genre

do_mv() {
  ....
}

/chemin/source  /chemin/destination
.....

et lorsque la liste est ok vous ajoutez la fonction do_mv et une insertion 'do_mv ’ en début de lignes sur tous les chemins.

Cordialement,
Regards,
Mit freundlichen Grüssen,
مع تحياتي الخالصة

F. Petitjean
« Celui qui, parti de rien, n’est arrivé nulle part n’a de merci à dire à personne !! »
Pierre Dac

L’option de dedup est-elle activé sur le pool ?
Quel est la quantité de RAM dans le cas ou le dedup est activé ?

Utilisé un montage NFS pour gérer le déplacement de fichiers (en grand nombre) n’est clairement pas l’idéale néanmoins cela me parait assez long tout de même pour du traitement simple.

J’utilise du FreeNAS avec du ZFS et je n’ai jamais fais face à de tel ralentissent même si j’avoue que mon stockage est relativement bien équipé :stuck_out_tongue:

Merci littlejohn75 pour votre réponse.

A vous lire, je me rends compte que j’aurais dû être plus explicite.
Quand j’ai dit “j’ai besoin de vérifier visuellement d’éventuel doublons” c’était pour faire simple mais en fait, ce sont des utilisateurs (sans droit, ni connaissance informatique particulière) qui doivent visualiser le contenu des fichiers (images) à déplacer.
Le soucis c’est qu’il y a quelques Go d’images (!) à trier et que plusieurs utilisateurs peuvent manœuvrer en même temps ! (donc malheureusement impossible d’utiliser mv et encore moins de passer par un script)

C’est pour cette raison qu’on utilise Nautilus car quand celui-ci risque d’écraser un fichier, il affiche une petite vignette des fichiers source et destination : les utilisateurs n’ont plus qu’à vérifier que c’est bien (ou pas) la même image et agissent en conséquence. (clic sur “Ignorer” ou “Remplacer”)
Pour ce cas précis, c’est simple, rapide et efficace.

Par contre, dans vos explications une chose attire mon attention :

Est-ce que gérer des chemins + noms de fichiers assez longs (compris entre 100 et 150 caractères) avec NFS peut provoquer de tels ralentissements ?
Auriez-vous plus d’infos à ce sujet svp ?

Merci Clochette pour ta réponse.

Non, l’option de déduplication des données n’est pas activée. (pour être honnête, je ne la connaissais même pas…)

Je vais donc jeter un œil dessus mais si je l’active dorénavant, elle s’appliquera que sur les nouveaux fichiers copiés sur le pool, mes précédents doublons seront toujours présents et donc à trier, non ?

Je demande à voir la sortie de

df -mT  /chemin/vers/fichier/source_ou_dest

avant (source) et après (dest), car comme Saint Thomas je ne crois que ce que je vois. La sortie sur un seul des 1109 fichiers est suffisante.
Pendant qu’on y est, vous lancez (sur le serveur et sur le poste client)

/usr/sbin/nfsstat

avant et après l’opération de déplacement des fichiers.
Vous fermez nautilus, démontez le système de fichiers NFS

sudo umount -l /pt/montage

Vous stockez dans des fichiers les sorties de /usr/sbin/nfsstat (à chaque fois).
Retour au point de départ. Remontage NFS, lancement nautilus, et constatez l’évolution des paramètres associés aux méta-données ( getattr setattr getfh ) ou au verrouillage ( lock*).

Je suis désolé, mais 48 minutes pour 1109 fichiers cela 2,6 secondes par fichier. Donc, vous avez trouvé une méthode de travail qui induit un comportement pathologique du système.

Sur les postes des utilisateurs il y a bien un serveur X (avec nautilus d’installé). Je vous conseille à nouveau de renverser l’ordre des choses et de ne pas passer par un montage NFS, de lancer les commandes sur le serveur sur lequel les disques sont attachés (quel sorte d’attachement au fait ? SATA, SAS, SCSSI ? ), lesquelles commandes peuvent se résumer à

nautilus &

Vous allez peut-être me dire que vos utilisateurs sont incapables de taper la moindre commande, dans ce cas c’est à vous de créer un lanceur qui s’intègre avec leur environnement.
Il faudrait voir aussi ce que fait exactement nautilus, mais en procédant directement sur le serveur (sans NFS), vous verrez bien si le problème vient de NFS ou de ZFS.

Cordialement,
Regards,
Mit freundlichen Grüssen,
مع تحياتي الخالصة

F. Petitjean
« On ne perd pas son temps en aiguisant ses outils. »
Proverbe français

« Moi, lorsque je n’ai rien à dire, je veux qu’on le sache. » (R. Devos)

Alors…

###df -mT

  • Depuis le serveur avant déplacement :
root@srv:~# df -mT /z2/shares/photos/Photos\ à\ trier/Photos\ 3/Versailles 2012 - JPG/DSC_108255-web.jpg
Filesystem Type 1M-blocks    Used Available Use% Mounted on
z2         zfs    1812368 1171630    640739  65% /z2
  • Depuis le serveur après environ 2s pour déplacer (via nautilus) un répertoire de 564 fichiers (< 204 Ko chacun) :
root@srv:~# df -mT /z2/shares/photos/Photos/Ile-de-France/v/Versailles 2012 - JPG/DSC_108255-web.jpg
Filesystem Type 1M-blocks    Used Available Use% Mounted on
z2         zfs    1812368 1171630    640739  65% /z2

###mfsstat

  • Depuis le serveur avant déplacement :
root@srv:~# nfsstat
Server rpc stats:
calls      badcalls   badclnt    badauth    xdrcall
4061254    0          0          0          0       

Server nfs v4:
null         compound     
65        0% 4061190  99% 

Server nfs v4 operations:
op0-unused   op1-unused   op2-future   access       close        commit       
0         0% 0         0% 0         0% 479138    4% 280921    2% 1236      0% 
create       delegpurge   delegreturn  getattr      getfh        link         
11402     0% 0         0% 0         0% 3524078  35% 377862    3% 0         0% 
lock         lockt        locku        lookup       lookup_root  nverify      
6         0% 0         0% 6         0% 140141    1% 0         0% 0         0% 
open         openattr     open_conf    open_dgrd    putfh        putpubfh     
313101    3% 0         0% 159       0% 115       0% 4021819  40% 0         0% 
putrootfh    read         readdir      readlink     remove       rename       
78        0% 137626    1% 183508    1% 2473      0% 61301     0% 6506      0% 
renew        restorefh    savefh       secinfo      setattr      setcltid     
45620     0% 0         0% 6506      0% 0         0% 184735    1% 54        0% 
setcltidconf verify       write        rellockowner bc_ctl       bind_conn    
54        0% 0         0% 241390    2% 6         0% 0         0% 0         0% 
exchange_id  create_ses   destroy_ses  free_stateid getdirdeleg  getdevinfo   
0         0% 0         0% 0         0% 0         0% 0         0% 0         0% 
getdevlist   layoutcommit layoutget    layoutreturn secinfononam sequence     
0         0% 0         0% 0         0% 0         0% 0         0% 0         0% 
set_ssv      test_stateid want_deleg   destroy_clid reclaim_comp 
0         0% 0         0% 0         0% 0         0% 0         0% 

Client rpc stats:
calls      retrans    authrefrsh
0          0          0
  • Depuis le serveur après environ 11 minutes pour déplacer (via nautilus) 153 fichiers (< 190Ko chacun) : (!)
root@srv:~# nfsstat
Server rpc stats:
calls      badcalls   badclnt    badauth    xdrcall
4096045    0          0          0          0       

Server nfs v4:
null         compound     
65        0% 4095981  99% 

Server nfs v4 operations:
op0-unused   op1-unused   op2-future   access       close        commit       
0         0% 0         0% 0         0% 482882    4% 281149    2% 1236      0% 
create       delegpurge   delegreturn  getattr      getfh        link         
11402     0% 0         0% 0         0% 3554427  35% 378826    3% 0         0% 
lock         lockt        locku        lookup       lookup_root  nverify      
6         0% 0         0% 6         0% 141074    1% 0         0% 0         0% 
open         openattr     open_conf    open_dgrd    putfh        putpubfh     
313902    3% 0         0% 159       0% 115       0% 4056802  40% 0         0% 
putrootfh    read         readdir      readlink     remove       rename       
78        0% 138175    1% 186421    1% 2473      0% 61301     0% 6707      0% 
renew        restorefh    savefh       secinfo      setattr      setcltid     
45629     0% 0         0% 6707      0% 0         0% 184742    1% 54        0% 
setcltidconf verify       write        rellockowner bc_ctl       bind_conn    
54        0% 0         0% 241397    2% 6         0% 0         0% 0         0% 
exchange_id  create_ses   destroy_ses  free_stateid getdirdeleg  getdevinfo   
0         0% 0         0% 0         0% 0         0% 0         0% 0         0% 
getdevlist   layoutcommit layoutget    layoutreturn secinfononam sequence     
0         0% 0         0% 0         0% 0         0% 0         0% 0         0% 
set_ssv      test_stateid want_deleg   destroy_clid reclaim_comp 
0         0% 0         0% 0         0% 0         0% 0         0% 

Client rpc stats:
calls      retrans    authrefrsh
0          0          0

Je n’ai pas encore fait le test du démontage du fs, etc… car pour l’instant, je n’arrive pas à interpréter les 2 nfssstat (au niveau des getattr, setattr et putfh) : je ne sais pas à quoi ça correspond exactement et j’aimerai comprendre avant de poursuivre bêtement les tests…

Sinon :

J’ai fait mieux lors de ces tests : 11 minutes pour 153 fichiers = 4,3s/fichier :stuck_out_tongue_winking_eye:

Par contre j’ai remarqué une chose : je suis resté pendant ces 11 minutes de transfert scotché devant le switch reliant la workstation au serveur, et les leds des ports utilisés n’ont clignoté uniquement lorsque je voyais la liste des fichiers à déplacer se vider petit à petit dans nautilus.

Ça indiquerait donc qu’il n’y a pas eu besoin de 11 minutes de flux réseau pour transférer mes 153 malheureux fichiers, mais seulement la quantité nécessaire.
Le ralentissement viendrait donc d’ailleurs…

J’avoue ne pas comprendre votre conseil (désolé) : si je n’utilise pas de montage NFS, qu’est-ce que je peux utiliser d’autre (sachant que tout ce qui est commande mv ou script n’est pas envisageable) ? Un montage Samba ?

Sinon pour info, mon pool ZFS RAIDZ2 est une association de 4 HD identiques de 1To chacun, montés en SATA. (le système est sur un SSD)

Je ne comprend rien à votre configuration. Comment accédez-vous au serveur Promox ? (même question pour vos utilisateurs ).

Ce que j’essayais de vous expliquer, c’est que passer par un système de fichiers de type réseau pour faire de simples manipulations sur les méta-données (ici l’emplacement des photos dans des répertoires du même système de fichiers) est on ne peut plus contre productif.

Avez-vous remarqué que l’utilisation du FS /z2 ne change pas. Ce n’est pas un transfert de fichiers. C’est un renommage. Donc cela doit prendre quelque chose comme un centième de secondes

fp2x@halc9:~$ time mv catalina.tar.gz Eric75.tar.gz

real    0m0.006s
user    0m0.001s
sys     0m0.005s
fp2x@halc9:~$ time mv  Eric75.tar.gz catalina.tar.gz

real    0m0.006s
user    0m0.001s
sys     0m0.005s
fp2x@halc9:~$ less /proc/cpuinfo
fp2x@halc9:~$ fgrep lock /proc/cpuinfo
clock           : 1000.000000MHz
clock           : 1000.000000MHz
clock           : 1000.000000MHz
clock           : 1000.000000MHz
fp2x@halc9:~$

La taille des photos n’a pratiquement aucune influence (dans une opération mv).

C’est le gros intérêt des interfaces graphiques. Je suis obligé de vous demander comment vous procédez. Dans ces 11 minutes, est-ce qu’il n’y aurait pas 10 minutes et 58 secondes de déplacement de souris, vérification visuelle et clic ?

Si c’est 11 minutes à attendre que la liste dans la fenêtre nautilus se mette à jour, je dirais “mauvais outil, changer d’outil”, ou mauvaise utilisation des outils.

Pour confirmer que vous ne transférez que des données graphiques de rafraîchissement d’affichage X11, vous pouvez tenter de mettre temporairement nautilus en icône :slight_smile: Vous pouvez aussi surveiller les volumes tranfèrés sur la liaison avec un truc du genre

watch '/sbin/ifconfig bond1 | fgrep packets'

et pas uniquement à regarder les lumières clignoter :smile:

Comme je ne connais pas votre procédure (pour arriver à des performances aussi catastrophiques) et que je ne connais pas ‘nautilus’ (Pour administrer les Linux je n’utilise que ssh en mode texte (*)) j’ai bien du mal à vous conseiller davantage.

A mon avis, si vous tenez à faire un montage sur les postes clients, la solution NFS actuelle est préférable à un montage CIFS/samba. (Plus Unix, moins de problèmes de droits ).

Est-ce que la connexion au serveur est du type ‘bureau à distance’ ? Plus précisément, RDP ou XDMCP ou VNC ?

La solution que je vous conseillait (ssh -X serveur nautilus )
avait l’avantage de restreindre au maximum les transferts graphiques.

Bon courage.

Notes
(*) Je souffre d’une maladie de la rétine et le mode texte d’une console SSH est beaucoup mieux lissé et lisible après grossissement que toutes les fioritures graphiques.

Cordialement,
Regards,
Mit freundlichen Grüssen,
مع تحياتي الخالصة

F. Petitjean
« L’arbre tombe toujours du côté où il penche. »
Proverbe français
Concierge qui roule, ne s’arrête qu’au bas de l’escalier.
Les proverbes philosophiques du Professeur Choron

Ooops désolé, je pensais avoir été clair dans mes explications.

###Serveur

partition système = SSD
partition ZFS RAIDZ2 2To = 4 x HD 1To (SATA)
Réseau Gigabit

sur lequel est installé :

  • Promox 3.4 (qui fait normalement tourner 2 VM, mais elles sont arrêtées le temps de résoudre le pb)
  • zfs (natif avec Promox)
  • nfs-kernel-serveur + nfs-common
  • ntp

###Workstations

sur lesquelles est installé :

  • jessie (à jour)
  • serveur X
  • Openbox
  • nfs-common (lecteurs réseaux nfsv4 monté sur /mnt/… :
user1@workstation:~$ cat /etc/fstab | grep photos
IP_du_serveur:/photos	/mnt/photos  nfs _netdev,soft,noauto,user,nodev,noexec  0   0
  • Nautilus (ou autre gestionnaire de fichiers comme nemo ou caja) qui pointe vers le point de montage en /mnt/… :
user1@workstation:~$ mount | grep photos
IP_du_serveur://photos on /mnt/photos type nfs4 (rw,nosuid,nodev,noexec,relatime,vers=4.0,rsize=1048576,wsize=1048576,namlen=255,soft,proto=tcp,timeo=600,retrans=2,sec=sys,clientaddr=IP_de_la_workstation,local_lock=none,addr=IP_du_serveur)

###Infra

Serveur <— cat6 (< 5mètres) —> switch DLink <— cat6 (< 15 mètres) —> Workstation

J’espère que mes explications sont un peu plus claires pour vous maintenant.

Non, non, du tout. (sinon le test ne serait pas valable)

En fait, pour chacun des tests réalisés, le serveur ne fait rien d’autre que le déplacement de fichiers, la workstation ne fait rien que d’attendre que la manip soit terminée, le switch n’est solicité par aucune autre machine.

Je pense aussi.

  • Changer d’outil : même résultat avec nemo ou caja.
  • Mauvaise utilisation des outils : je pense pas, je dirais plutôt outil inadéquat comme vous le disiez… mais quoi utiliser d’autre hors CLI ou script ? (ce n’est pas moi qui impose cette restriction)

J’ai déplacé 63 fichiers (< 193 Ko chacun) :

root@workstation:~# vnstat -i eth0 -l
Monitoring eth0...    (press CTRL-C to stop)

     rx:        0 kbit/s     0 p/s          tx:        0 kbit/s     0 p/s^C


 eth0  /  traffic statistics

                           rx         |       tx
--------------------------------------+------------------
  bytes                      856 KiB  |         705 KiB
--------------------------------------+------------------
          max             995 kbit/s  |      712 kbit/s
      average           38,46 kbit/s  |    31,70 kbit/s
          min               0 kbit/s  |        0 kbit/s
--------------------------------------+------------------
  packets                       3145  |            2754
--------------------------------------+------------------
          max                415 p/s  |         322 p/s
      average                 17 p/s  |          15 p/s
          min                  0 p/s  |           0 p/s
--------------------------------------+------------------
  time                  2,97 minutes

On voit donc bien ici que ce n’est pas un engorgement réseau…

La connexion au serveur se fait simplement via un lecteur réseau (/etc/fstab indiqué plus haut) monté sur /mnt/…

Je comprends bien votre conseil, mais ça obligerait à installer nautilus (ou autre gestionnaire graphique de fichiers) et donc un serveur X… ce qui n’est pas recommandé sur un serveur.

Je suppose que vous voulez dire Proxmox VE 3.4 de la société autrichienne Proxmox Server Solutions GmbH
Vous avez donc une solution propriétaire (éventuellement coûteuse) qui ne fonctionne pas avec les performances qu’on pourrait attendre (système sur SSD, RAM confortable, attachement SATA).
En passant, j’espère que vous n’avez pas mis le swap sur le SSD. (mais on sait aussi que le swap n’est pas utilisé)

En tout cas, merci pour la description détaillée. Je ne pense pas que l’effort déployé pour cacher certaines informations comme les adresses IP soit justifié (le répertoire exporté est vraisemblablement /z2/shares/photos et non pas /photos
Nous constatons que c’est le protocole NFSv4 qui a été automatiquement sélectionné, avec des paramètres rsize et wsize de 1Mo ce qui semble très correct, sur des interfaces Gigabits.
Pouvez-vous vérifier qu’on a bien du gigabit Full Duplex pour tout le monde ?

Pas un problème de débit, c’est sûr, peut-être un problème de latence ?
Je vois deux causes possibles de latence excessive dans votre configuration

  • Latence due au fonctionnement interne de nautilus qui induirait des demandes excessives sur X11 (exclus en gigabit) ou sur NFS (via le montage ) ouverture/fermeture de fichiers, ou requêtes associées aux identifications (utilisateurs, groupes et même hôtes ), verrouillage …

  • Latence due à des lenteurs DNS

Vous allez me dire : je n’utilise pas la résolution DNS pour faire le montage NFS puisque je mets des adresses IPv4. Cela est un peu plus compliqué.

Peut on avoir le retour des commandes suivantes sur le Prxmox et sur les stations

cat  /etc/idmapd.conf
hostname --fqdn
getent hosts  IP_server
getent hosts  IP_station
getent passwd  _1010_

1010 est l’identifiant numérique d’un utilisateur.

Sur le serveur

cat /etc/exports

Le paramètre le plus intéressant est Domain dans /etc/idmapd.conf qui est propre à NFSv4 et qui est souvent mal renseigné.

Pour illustrer ce que je disais dans mes messages précédents sur l’intérêt de scripter, surtout si on a des Go à renommer j’ai passé une bonne partie de la matinée à mettre au point un script
Utilisation

fp2x@drhpcmsa:/tmp$ l toilelibre/ SPAM/
toilelibre/:
total 0

SPAM/:
total 0
fp2x@drhpcmsa:/tmp$ time ./do_mv.sh
pas de fichier XXlc9_10.png dans /tmp/اختك
répertoire /tmp/pas_la n existe pas

real    0m0.008s
user    0m0.000s
sys     0m0.000s
fp2x@drhpcmsa:/tmp$ l toilelibre/ SPAM/
toilelibre/:
total 4684
 620 -rw-r--r-- 1 fp2x fp2x  633187 mai   26 10:25 halc9_10.png
1012 -rw-r--r-- 1 fp2x fp2x 1035230 mai   26 10:22 halc9_led.png
1616 -rw-r--r-- 1 fp2x fp2x 1651210 mai   26 10:18 boot10_blur.png
 436 -rw-r--r-- 1 fp2x fp2x  445626 mai   26 10:14 pseries_0.png
 676 -rw-r--r-- 1 fp2x fp2x  690458 mai   26 10:12 pseries_1.png
 324 -rw-r--r-- 1 fp2x fp2x  330476 mai   26 10:09 yaboot_tab.png

SPAM/:
total 16
16 -rw-r--r-- 1 fp2x fp2x 15178 juin   6 09:54 SPAm_06_juin_2016.png
fp2x@drhpcmsa:/tmp$ q

renommer une dizaine de fichiers (les déplacer de répertoire) est quasiment instantanné, ne consomme pratiquement pas de ressources.

Comme j’ai vu que vous étiez adepte d’une méthode (à mon avis idiote) très Windowsienne de nommage des répertoires (comme Photos\ à\ trier/Photos\ 3/ ) j’ai fait exprès d’utiliser un répertoire nommé اختك/ ce qui signifie ‘ta soeur’ en arabe.
Si vous fautes sur le serveur (dans le bon répertoire)

mv "Photos à trier"  'اختك'

vous rendrez service à vos utilisateurs, qui auront beaucoup moins de mal à repérer ce fameux répertoire (c’est celui qui est écrit en arabe ! )

Le script (à adapter :slight_smile: )

#!/bin/bash

# do_mv.sh

LOGFILE="/tmp/$0.log"

run() {
    $* >> $LOGFILE
    echo " " >> $LOGFILE
}

pre() {
  df -mT "$SRCDIR"
}

post() {
  df -mT "$SRCDIR"
}

SRCDIR="/tmp/اختك"
# ACTION="echo"    # mettre "" pour réaliser renommage
ACTION=""

do_mv() {
   local src
   while read fname destdir
   do
      if [ -d "${destdir}" ]
      then
         :
      else
          echo "répertoire ${destdir} n existe pas"
          continue
      fi
      src="${SRCDIR}/${fname}"
      if [ -f "${src}" ]
      then
         :
      else
         echo "pas de fichier ${fname} dans ${SRCDIR}"
         continue
      fi
      $ACTION mv "${src}" "${destdir}/";
   done <<'EOF'
SPAm_06_juin_2016.png  /tmp/SPAM
halc9_10.png   /tmp/toilelibre
XXlc9_10.png   /tmp/toilelibre
halc9_led.png   /tmp/toilelibre
halc9_led.png   /tmp/pas_la
boot10_blur.png   /tmp/toilelibre
pseries_0.png   /tmp/toilelibre
pseries_1.png   /tmp/toilelibre
yaboot_tab.png  /tmp/toilelibre
EOF
}

run pre

do_mv

run post

Cordialement,
Regards,
Mit freundlichen Grüssen,
ﻢﻋ ﺖﺤﻳﺎﺘﻳ ﺎﻠﺧﺎﻠﺻﺓ

F. Petitjean
Ingénieur civil du Génie Maritime.
Bureau Veritas
Département Recherche, le département de l’excellence technique.

Fier d’être depuis 40 ans au service de Bureau Veritas, branche Marine & Offshore.

« Un ordinateur c’est comme un frigo : on le branche et ça marche. »
Laurent Serano Directeur informatique, réunion Délégués du Personnel 2010

Hé bien c’est à priori le cas !!!

J’ai testé avec gThumb (3.4 = backports version) et j’obtiens enfin des débits plausibles de manipulation de fichiers via un serveur X.

Avec exactement la même config et les mêmes conditions de test, excepté que nautilus est remplacé par gThumb, voici les stats :

root@srv:~# vnstat -i vmbr0 -l
Monitoring vmbr0...    (press CTRL-C to stop)

   rx:       20 kbit/s    13 p/s          tx:       16 kbit/s    11 p/s


 vmbr0  /  traffic statistics

                           rx         |       tx
--------------------------------------+------------------
  bytes                   261.47 MiB  |      243.36 MiB
--------------------------------------+------------------
          max          464.77 Mbit/s  |   433.84 Mbit/s
      average            6.32 Mbit/s  |     5.88 Mbit/s
          min               0 kbit/s  |        0 kbit/s
--------------------------------------+------------------
  packets                     255817  |           94808
--------------------------------------+------------------
          max              47155 p/s  |        2940 p/s
      average                754 p/s  |         279 p/s
          min                  1 p/s  |           1 p/s
--------------------------------------+------------------
  time                  5.54 minutes

pour déplacer 1697 fichiers (256 Mo au total) ce qui fait 0.2s par fichier ! Ouf…

(mais je suis parfaitement conscient que ça serait quasi immédiat par un mv en ssh sur le serveur, sauf que…)

Ça serait donc nautilus et Cie qui ne sauraient pas gérer correctement un “vulgaire” déplacement de fichiers…

Bref, j’ai résolu mon pb mais je ne sais pas exactement d’où ça vient… c’est dommage.

En tout cas, merci à tous les deux pour votre aide ! :slight_smile:

A+
Eric

Heu…

C’est donc, sauf erreur de ma part, une solution libre et gratuite. (le support, non obligatoire, est lui payant par contre.)

Ben… en fait, j’ai pas trop eu le choix : je ne pouvais pas la mettre sur le pool ZFS et je n’avais plus de bus SATA de libre sur la CM.
Mais pour l’instant, je ne swape pas. (uptime = 314 days)

Pour les IP, on est jamais trop prudent.
Quant au répertoire exporté, j’ai juste fait un copié/collé du résultat de la commande.

Je ne suis adepte de rien du tout !
J’ai quitté le monde Micro$oft depuis plus de 10 ans maintenant, mais c’est pas pour autant que tout le monde a fait de même.

Dans une entreprise, il y a ce que l’on devrait faire dans le meilleur des mondes… et la réalité !

J’ai des supérieurs et/ou chefs de services qui (m’)imposent des pratiques/méthodes de travail/conventions de nommage ou autre et… OS (et donc mauvaises habitudes et prises de têtes) que je suis tenu malgré tout de respecter.
(même si ce n’est pas sans avoir essayé par tous les moyens de faire changer/évoluer les mentalités.)

Je suis parfaitement conscient que ce n’est pas l’idéal d’utiliser des espaces/MAJUSCULES-minuscules/caractères accentués dans des chemins et noms de fichiers (surtout que ces derniers sont souvent à rallonge !) mais… c’est comme ça et je ne peux malheureusement pas faire autrement.

Sinon, un grand merci littlejohn75 d’avoir pris de votre temps pour établir ce script ! :slight_smile:
Je vais étudier ça très attentivement !!!

En voilà une bonne nouvelle.

Vous avez aussi une visionneuse d’images Xfimage livrée avec le paquet xfe , mais je ne sais pas s’il y a la fonctionnalité ‘batch file operations’ :weary:

Content pour vous.


F. Petitjean
Ingénieur civil du Génie Maritime.
Bureau Veritas
Département Recherche, le département de l’excellence technique.

Fier d’être depuis 40 ans au service de Bureau Veritas, branche Marine & Offshore.

En 2009 nous avons réduit notre endettement qui n’est plus que de 1,5 fois le cash flow
Franck Piedelièvre le 29 janvier 2010. Les voeux du Président.