Forum Linux.général [Urgent] Problème avec rsync : file too large

Posté par  .
Étiquettes : aucune
2
23
août
2012

Salut,

Pour sauvegarder toutes mes données avant de partir en vacance j'essaye de faire du rsync d'un nas (Thecus) vers un autre nas (Netgear).
Des deux coté, l'OS est un linux (2.6.31 et 2.6.33) et le filsystem destination est un ext4.
Mon soucis concerne les gros fichiers, videos ou isos.
J'ai des erreurs rsync comme celle là :

rsync: send_files failed to open "/raid0/data/Nas/backup/PC Mururoa/Jeux/StarCraft II/Campaigns/Liberty.SC2Campaign/base.SC2Assets": Value too large for defined data type (75)

La limite semble être 2 GB.
Tout ce qui dépasse 2 GB donne un "Value too large".
La commande : (il y a des redondances je sais) rsync --progress --delete -ravlpogtDH /raid0/data/Nas/ 192.168.0.12:/backup/Thecus/

Ca semble être un problème rsync car si j'essaye de transférer un fichier de 10 GB en montant la source et la destination avec un partage samba ça marche !

Comment résoudre le problème ?

Edit :

Bon ça a l'air lié à la version 32 bits de rsync et/ou de l'OS. Quelque part il y a une structure 32 bits signé et paf ça coince quand on dépasse 2 GB.
Rien dans les faq/bugs/doc sur le site de rsync.
Trop bizarre quand même, on a toujours pu transférer des fichiers de plus de 2 GB entre des linux 32 bits …
Je vais faire la liste des fichiers > 2 GB avec find et ensuite transfert avec scp.
Je reste preneur d'une solution rsync.

  • # quelques pistes

    Posté par  (site web personnel) . Évalué à 2.

    • est que le rsync marche dans l'autre sens ?
    • quelle est l'espace sur /tmp ?
    • question version de rsync ( < 2.6.7 il y a des soucis avec les gros fichiers ) ?

    Fuse : j'en Use et Abuse !

    • [^] # Re: quelques pistes

      Posté par  . Évalué à 1.

      • sur /tmp j'ai 256 MB (tmpfs)
      • version 3.0.7 et 3.0.9. Protocol version 30 pour les deux.
      • je vais tester dans l'autre sens

      • [^] # Re: quelques pistes

        Posté par  . Évalué à 0.

        Dans l'autre sens ça coince 'connection refused'.
        C'est pas la faute du tmp. J'ai essayé avec --temp-dir vers un répertoire avec des centaines de gigas dispos et pas mieux.

  • # split

    Posté par  . Évalué à 2.

    Solution rapide : pour passer outre cette limitation, tu peux "spliter" les fichiers volumineux avec la commande 'split' à la source : 

    bash$ split -b $((512 * 1024 * 1024)) "/raid0/data/Nas/backup/PC Mururoa/Jeux/StarCraft II/Campaigns/Liberty.SC2Campaign/base.SC2Assets"  mon_fichier

    Avec la commande précédente, tu va découper ton gros fichier en d'autres de 512Mo préfixés par "mon_fichier" dans le répertoire courant. Pour les reconstruire, un simple cat devrait suffire : 

    bash$ cat mon_fichier.* > base.SC2Assets

    A tester !

    • [^] # Re: split

      Posté par  . Évalué à 0.

      C'est un workaround mais il y a plus de 15 fichiers.
      Pour l'instant la 'solution' c'est des copy à travers des montages samba mais c'est bien moins propre que rsync.

  • # stat

    Posté par  . Évalué à 0.

    Hello,

    Les 2 sont en 64bits? Il y a d'autres messages sur le net avec le même genre d'erreur, et la commande stat serait impliquée (stat EOVERFLOW)

    • [^] # Re: stat

      Posté par  . Évalué à 0.

      Les deux sont en 32 bits avec les options : 64-bit files, 64-bit inums, 32-bit timestamps, 64-bit long ints.
      Google n'est pas trop mon ami sur ce coup là.

      • [^] # Re: stat

        Posté par  . Évalué à 0.

        J'ai fait un tour rapide des sources, et le seul endroit où se trouve message d'erreur "send_files […]" et dans sender.c. Le message errno associé "Value too large […]" est fixé lors de la fonction do_open (appelée dans sender.c et définie dans syscall.c) et qui ne fait pratiquement que retourner le résultat de la fonction open.
        Il semble donc que le rsync utilisé ne soit pas capable de gérer des fichiers larges. Est-ce que rsync a été compilé avec les options suivantes:

        -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.