Download Station Consommateur D'espace-Disque

[NY152]

Bonjour,

Lorsque qu'on ajoute un téléchargement à Download Station, celui-ci met ce dernier dans le répertoire @download, jusque là ça va ; Bien que je trouve ce procédé bête car

1) cela plantera si la destination est trop petite (peut arriver si vous avez @donload dans un volume1 vide et la destination dans un volume2 plein), le téléchargement serait en échec alors qu'il a bien été téléchargé completement.

2) cette méthode augmente la fragmentation (même si elle est minime sous Linux elle existe)

3) Cette copie superflue du cache vers la destination fatigue les disques inutilement

Mais admettons, cela ne justifie pas que Download Station garde une copie en cache dans @download une fois les fichiers dans la destination voulue. C'est là qu'est le problème. Si l'on veut garder des fichier en partage, on doit supprimer chaque torrent et les ré-injecter en spécifiant le répertoire précédemment utilisé qu'il vérifie et là plus de copie en cache.

Absolument pas pratique n'est ce pas ?

Y a t-il une solution pour palier cela ?

D'avance, merci

[CoolRaoul]

Lorsque qu'on ajoute un téléchargement à Download Station, celui-ci met ce dernier dans le répertoire @download, jusque là ça va ; Bien que je trouve ce procédé bête car

1) cela plantera si la destination est trop petite (peut arriver si vous avez @donload dans un volume1 vide et la destination dans un volume2 plein), le téléchargement serait en échec alors qu'il a bien été téléchargé completement.

Chez moi le dossier "@download" est créé sur le *mème* volume que celui ou est situé le dossier spécifié comme destination de téléchargement dans downloadstation. (j'ai les cibles de téléchargement volume2 et c'est également la qu'est le dossier "@download")

Je suis très étonné que cela soit différent chez toi.

2) cette méthode augmente la fragmentation (même si elle est minime sous Linux elle existe)

Faudrait nous expliquer quelle peut être la différénce, en terme de fragmentation entre télécharger dans un dossier puis faire un "move" (ou un link) ou télécharger directement dans le dossier cible.

3) Cette copie superflue du cache vers la destination fatigue les disques inutilement

M'étonnerait fort que cela soit fait sous forme de copie, à partir du moment ou reste dans le meme volume je pense que les devs de downloadstations se sont contentés d'un hard link et donc aucune "fatigue" inutile.

**EDIT**

Je m'apercois que tes points 2 et 3 (et donc mes remarques portant sur ces derniers) n'ont plus lieu d'être du moment que tu constates in fine le même comportement que moi pour le point 1.

Modifié le 15 octobre 2012 par CoolRaoul

[NY152]

Tu ne fais que contredire que des détails finalement ^^

1) Oui je n'ai qu'un répertoire @download dans volume1, rien dans volume2

2) oui la fragmentation augmente avec ce genre de copie (qui je le répète reste minime mais bon). Les données serait déplacées y en aurait pas (si même volume évidement sinon ça fragmentera quand même puisqu'il y a ré-écriture des données sur un autre volume)

3) Oui une copie fatigue les disques. Et contrairement à ce que tu pense, comme il s'agit d'une copie, les données copiées sur un même disque fatigue plus vite le disque concerné puisque le disque fait la lecture, déplace des têtes, écrit repart sur les données source, efface ce qui a été déplacé et on repart jusqu'à ce que cela soit terminé. Si les volumes source et destination sont différents la fatigue est moindre la source lit et reste sur la source, idem pour la destination. Là où je suis d'accord avec toi, si c'était un déplacement, il n'y aurait pas de problème mais ce n'est pas le cas.

Le vrai soucis (et la question qui se pose) est que ce dossier @download DEVRAIT être purgé quand les données sont stockées à l'endroit que l'on a choisit.

Modifié le 15 octobre 2012 par NY152

[Kramlech]

Le vrai soucis (et la question qui se pose) est que ce dossier @download DEVRAIT être purgé quand les données sont stockées à l'endroit que l'on a choisit.

Les données restent dans @download tant qu'elle sont partagées au niveau de download station.

Cela ne me parait pas idiot d'avoir d'un coté le fichier mis en partage, et de l'autre le fichier que l'on va peut être déplacer, renommer, etc ...

C'est du moins un choix de fonctionnement qui se justifie ....

[chickenbox]

Bonjour,

Pour ma part, j'ai mis @download sur un disque externe (avec les enregistrements de ma videosurveillance). De ce fait, je limite les écritures intempestives sur les disques. Une fois le fichier complet, si je veux le garder en seed, je fais un lien vers la destination.

Et voilà, pas de perte de place, pas d'écriture inutile sur les disques.

A+

[CoolRaoul]

Tu ne fais que contredire que des détails finalement ^^

1) Oui je n'ai qu'un répertoire @download dans volume1, rien dans volume2

Ah zut de zut, c'est exact, @download semble être créé sur le volume ou downloadstation est installé en fait.

Comme il me semblait bien avoir vu un @download sur mon volume2 et qu'en plus, j'étais tellement persuadé que les devs Syno ne pouvaient pas être assez stupides pour pratiquer comme il semble logique (utiliser des hardlinks sur le meme volume) que j'ai même pas pris le temps de vérifier.

Je reconnais que vu comme ça, cette implémentation est assez c**

2) oui la fragmentation augmente avec ce genre de copie (qui je le répète reste minime mais bon). Les données serait déplacées y en aurait pas (si même volume évidement sinon ça fragmentera quand même puisqu'il y a ré-écriture des données sur un autre volume)

Par contre pour la fragmentation, ca se discute: quant on crée un fichier sur un volume pour ensuite le copier sur un autre volume il est bien clair que cela ne créée pas de fragmentation *supplémentaire* sur le volume cible par rapport au cas ou on télécharge directement sur la cible.

Quant au volume source, comme le fichier est alloué d'un seul tenant (puisque on connais sa taille des le départ, (et c'est déja d'ailleurs le cas pour le fichier source au début du téléchargement), la fragmentation induite peut être limitée dans ce contexte.

3) Oui une copie fatigue les disques. Et contrairement à ce que tu pense, comme il s'agit d'une copie, les données copiées sur un même disque fatigue plus vite le disque concerné puisque le disque fait la lecture, déplace des têtes, écrit repart sur les données source, efface ce qui a été déplacé et on repart jusqu'à ce que cela soit terminé. Si les volumes source et destination sont différents la fatigue est moindre la source lit et reste sur la source, idem pour la destination. Là où je suis d'accord avec toi, si c'était un déplacement, il n'y aurait pas de problème mais ce n'est pas le cas.

Ta description de la copie : lecture->ecriture->effacement des données et en partie erronée (pourquoi diable irait-on *effacer* les données?) et aussi un peu simplifiée (ne pas oublier que les données avant d'être effectivement écrites sur les disques sont mises en cache et que l'algo de flush de ce dernier utilise des techniques de réorganisations de I/O pour limiter les mouvements de têtes.

Pour ma part, j'ai mis @download sur un disque externe.

Par curiosité: tu a fais comment?

Modifié le 15 octobre 2012 par CoolRaoul

[chickenbox]

@coolraoul : mount - bind => je me suis inspiré de ce topic à l'époque

[NY152]

pour le 3) l'effacement de données, effectivement, je me suis emmêlé ^^

Pour la fragmentation, elle existe sous Linux mais n’excédera pas 3% ; Ça c'est dans le cas d'un ordinateur personnel dont les données bougent peu et que celui ci dispose d'assez d'espace. Il a été remarqué d'un disque en ext3 ou ext4 dont l'espace libre était inférieur à 15%, la fragmentation pouvait devenir affolante si les données bouge régulièrement. De mémoire, il n'y a pas d'outil permettant de défragmenter ; La solution à l’arrache permettant de le faire étant de déplacer les données sur un autre support et de les replacer à l'endroit initiale ; L'algo du système de fichier se démerdant pour tout ranger.