Disk Usage Report (Disque Usage Rapport) Prends Bcp De Ressources (Et De Temps).[Resolu]

[oliviervdb]

Hello,

J'ai une question concernant cet utilitaire de rapport.

J'ai lancer un rapport complet (y compris l'option "fichier en double" (je me souviens plus du terme utilisé par Syno, mais vous comprendrait si vous aller dans cet utilitaire). Syno prévient d'ailleurs que ca peut prendre du temps d'activer cette option. Et effectivement... sur mon DS41j (8 To de fichiers divers (4 + 2To en Raid 5) .. soit a mon avis a la grosse louche, 1 ou 2 millions de fichiers), ca fait 15j (quinze) que le rapport tourne...

Je commence a me demander si c'est normal?

surtout que ca prends bcp de ressources au Syno. et rends les requets en tt genres bcp plus lente.

Est ce que qqun a deja fait tourner ce genre de report sur son Syno? sur combien de fichier? Combien de temps pour le rapport?

J'ai fais un test sur un autre Syno (DS111 avec qq milliers de fichiers), ca a pris environ 1h.

J'ai un peu chercher sur le net, et je ne trouve pas trop d'info sur le temps nécessaire p/r aux nombre de fichiers / DS?

Si vous avez des info je suis preneurs.

Merci.

Modifié le 16 février 2014 par oliviervdb

[CoolRaoul]

Si ça fait 15 jours que ça tourne on peut conclure que tu n'as pas fait la dernière mise à jour firmware sortie cette semaine.

D’après les releases notes des correctifs concernent le module de génération des rapports ("Improved the stability of generating Disk Usage Reports")

Peut-être cela vaut-il le coup de faire l'upgrade.

Sinon, si ça ne résout pas ton problème, ben, RDV dans 15 jours pour faire le point

Modifié le 21 avril 2013 par CoolRaoul

[oliviervdb]

Certe.. j'avais vu l'info sur le site pour la mise a jour. Mais comme tu dis, comme ca fait 15j qu'il troune, je l'avait lancé bien avant la MaJ. Donc je vais encore laisse run peu (1 semaine... si ma patience tient le coup...) et je verrai. Parce qu'en faite je pense bien que la "task" synoreport n'est pas planté. Je crois juste que c'est long... vu le nombres de fichiers et la faible "puissance" du DS411j.

Est ce que qqun sait ce qu'il fait vraiment pour comparer les fichiers identique?

Car avec mon test sur un autre syno, j'avais 2 fichier identique, sauf qu'il n'avait pas le meme nom. Et le syno l'a repérer. J'ai donc pu en bazarder 1. Donc comment le systeme fait pour determiner quel fichier est identique a un autre (visiblement, ce n'est pas rien que sur le nom).

J'imagine que c'est une caratéristique de Linux (et Ext 3 et 4) qui est exploitée.

Merci d'avance.

[CoolRaoul]

Est ce que qqun sait ce qu'il fait vraiment pour comparer les fichiers identique?

Car avec mon test sur un autre syno, j'avais 2 fichier identique, sauf qu'il n'avait pas le meme nom. Et le syno l'a repérer. J'ai donc pu en bazarder 1. Donc comment le systeme fait pour determiner quel fichier est identique a un autre (visiblement, ce n'est pas rien que sur le nom).

Ce n'est *surtout pas* sur le nom, sinon ça ne serait pas très utile.

Perso si je devait le faire, se serait, après avoir établi la liste de l'ensemble des fichiers sous forme de liste triée par taille, via un simple "cmp" appliqué uniquement aux fichiers de même longueur.

Le simple test préalable d'identité de taille étant suffisant à limiter la quantité des comparaison effectives.

Le seul risque pouvant faire vraiment exploser ce genre d'algorithme est le cas ou on est en présence d'un grand nombre de fichiers de taille *strictement identique* et dont les N premiers blocs (avec une valeur importante de "N") le sont aussi (le "cmp" ne coûte pas cher si les premiers octets des deux fichiers sont différents)

J'imagine que c'est une caratéristique de Linux (et Ext 3 et 4) qui est exploitée.

Je ne pense pas, je ne vois pas trop laquelle d'ailleurs..

Modifié le 21 avril 2013 par CoolRaoul

[ikeke]

15 jours ce n'est pas normal. En voyant ton message tout à l'heure, j'en ai lancé un complet, c'est déjà fini. Cela a pris environ 30 mns pour un peu plus de 3 To de données.

La mise à jour à jour pourrait donc être une bonne idée. Certes le 411j n'est pas forcément super puissant mais 15j c'est très long.

[oliviervdb]

Mise a jour apres.... 3 semaines de run...

J'ai quand meme été faire un tour du coté du dossier au le rapport sera placé. Il y a deja une partie. Entre autre le "FileOwner" avec le nombre et la taille de chaque volume.

Si on tiens compte des disk USB de back-up (et je pense qu'il le fait vu que ca fait un moment que mon disk USB de back-up est en activité), il y a quand meme 27 To de data pour + de 5 millions de fichiers. Donc ca m'étonne pas qu'il prends du temps... mais quand meme 3 semaines....

Il y aurait pas moyen de voir si le syno ne "tourne pas en boucle" sur qqch? PAr exemple en regardant si un fichier temp continue a augmenter de taille, ou si ca date change régulierement? Dans le dossier de destination, on dirait bien que DSM ne place que les fichier .csv "fini". Donc je vois pas le fichier "journal" en cours de travail. QQun sait où il se situe sur le Syno? ou comment le trouver?

Merci.

[CoolRaoul]

D'apres ce que j'ai pu constater (avec lsof et strace), synoreport, apres la phase de parcours du file system, se retrouve à boucler sur un fichier de travail temporaire dont il a supprimé le lien dans le file system:

Il s'agit du fichier marqué "deleted" ci dessous

fserv> lsof -c synoreport | awk '($4 ~ /^[0-9]/)'
synorepor 6293 root    0u   CHR    1,3      0t0   24635 /dev/null
synorepor 6293 root    1u   CHR    1,3      0t0   24635 /dev/null
synorepor 6293 root    2u   CHR    1,3      0t0   24635 /dev/null
synorepor 6293 root    3ur  REG  253,0 18392064 6424990 /volume2/var/log/synoreport/stat.db.6293
synorepor 6293 root    4w   REG   0,11      626 7415597 /tmp/synoreport_data.6293
synorepor 6293 root    5w   REG  253,0        0 6424993 /volume2/var/log/synoreport/duplicates/tmp.2013-04-27_08-46-22/csv/duplicate_file.csv
synorepor 6293 root    6u   REG  253,0 80307200      48 /volume2/etilqs_tdzkb0vceNc08zK (deleted)

Et avec "strace" on peut constater qu'il est en train de ne plus faire que des seek, lectures et écritures dans ce dernier (file number 6):

fserv> strace -p 6293 2>&1 | head
Process 6293 attached - interrupt to quit
_llseek(6, 66807808, [66807808], SEEK_SET) = 0
write(6, "0000ch_1.1_Fixed/Installation Da"..., 1024) = 1024
_llseek(6, 1900544, [1900544], SEEK_SET) = 0
read(6, "0000_Complete_1.0/gamedata/sound"..., 1024) = 1024
_llseek(6, 23865344, [23865344], SEEK_SET) = 0
read(6, "0000009/gamedata/sounds/characters"..., 1024) = 1024
_llseek(6, 28204032, [28204032], SEEK_SET) = 0
read(6, "0000UP_1_0_9/gamedata/sounds/cha"..., 1024) = 1024
_llseek(6, 50930688, [50930688], SEEK_SET) = 0

C'est dans cette phase qu'il boucle pendant des plombes.

Je soupçonne un mauvais algorithme... (j'aimerai bien voir les sources, mais je pense que synoreport n'est pas open source)

[oliviervdb]

Merci CoolRaoul,

Quand tu dis "boucle pendant des plombes" ca veut dire longtemps, mais pas indéfiniment? Je veux bien etre patient... mais j'ai qd meme envie d'avoir un résultat qd meme un jour.

Merci.

[CoolRaoul]

Quand tu dis "boucle pendant des plombes" ca veut dire longtemps, mais pas indéfiniment? Je veux bien etre patient... mais j'ai qd meme envie d'avoir un résultat qd meme un jour.

Je dois t'avouer ne pas avoir eu la patience d'attendre.

J'avais lancé un test un matin de la semaine dernière.

Le soir le process synoreport était toujours la.

Je l'ai tué.

Faudrait ouvrir un dossier chez Syno, mais le probleme est que quand ça les arrange ils considèrent la présence des commandes optware (comme ici "strace" et "lsof)" comme source de problème car non partie intégrante de DSM et que je n'ai que ça comme moyen d'investigation.

Expérience vécue:

[oliviervdb]

Bon apres 5 (cinq !!) semaines, j'ai du couper le syno (travaux prévu sur le reseau electrique dans ma rue)... mais c'était tjs pas fini...

Donc j'ai pu installer la new version du 4.2. Mais du coup je n'arrive plus a creer un rapport.

Quand je clique sur "creer", il y a rien qui se passe. juste un "error on the page" en bas de mon browser (IE sur le PC du boulot).

Donc impossible de relancer la creation d'un nouveau rapport :-(

Bug connu? J'ai un 411j.

Sur mon DS111, la pas de probleme.

Merci d'avance.

[oliviervdb]

Bon apres 5 (cinq !!) semaines, j'ai du couper le syno (travaux prévu sur le reseau electrique dans ma rue)... mais c'était tjs pas fini...

Donc j'ai pu installer la new version du 4.2. Mais du coup je n'arrive plus a creer un rapport.

Quand je clique sur "creer", il y a rien qui se passe. juste un "error on the page" en bas de mon browser (IE sur le PC du boulot).

Donc impossible de relancer la creation d'un nouveau rapport :-(

Bug connu? J'ai un 411j.

Sur mon DS111, la pas de probleme.

Merci d'avance.

correction. A partir de mon PC sous IE8 ca ne fonctionne pas non plus sur mon DS111. Demain j'essaye sur un PC avec FireFox.

[oliviervdb]

Je confirme, c'est IE8 qui fonctionne pas. Avec FireFox ca fonctionne tres bien. Qd j'aurai plus de temps je reessaye une full report, avec rechrhce de fichier doublon... esperons que ca ne prenne pas 6 semaines... ;-)

[oliviervdb]

Oups j'avais oublié ce post. C'était bien IE8 qui n'était pass compatible pour l'acces au menu. Et un bug de DSM 4.1 (je crois a l'époque). Maintenant tt fonctionne tres bien y compris la recherche de doublons. Et on en gagne de la place a le faire... monstreux quand on utilise son NAS pour backuper les syno de la famille (via le net d'ailleur et ce fonctionne tres bien)....

Je passe le post en [Resolu]

Modifié le 21 décembre 2013 par oliviervdb