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 ze_lionix (site web personnel) . Évalué à 2.
Fuse : j'en Use et Abuse !
[^] # Re: quelques pistes
Posté par mururoa69 . Évalué à 1.
[^] # Re: quelques pistes
Posté par mururoa69 . É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 ninis666 . Évalué à 2.
Solution rapide : pour passer outre cette limitation, tu peux "spliter" les fichiers volumineux avec la commande 'split' à la source :
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 :
A tester !
[^] # Re: split
Posté par mururoa69 . É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 ecid . É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 mururoa69 . É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 ecid . É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.