[Hipparchia]

Bonsoir,
C'est peut être un détail mais quelqu'un pourrait-il m'expliquer la théorie du comportement de mon espace disque sur le NAS ?
> Il n'a plus que 300 Mo de disponible.
> Je coupe/colle 65Go de données d'un des dossiers (via un lecteur réseau monté sur mon Win7), vers un disque dur interne à mon PC (externe au NAS donc).
> Aucun espace disque libéré. Je vérifie quand même dans le file station, et dans mon dossier monté, au cas où : aucune trace. Je reboot le NAS : pas de changement.
> Aucune trace dans la corbeille Windows. Pas de corbeille activée sur le NAS.
> Je supprime un fichier depuis le lecteur monté : pas de changement de quota (POURTANT me semble t-il, cela a déjà fonctionné).
> Je supprime un fichier directement depuis le file station : quota libéré immédiatement.

Il y a un cache que je loupe, une option particulière à décocher ?
Un paramètre qui aurait changé sans que je m'en aperçoive ?

Edit : et merde, mauvais forum

[Zuglok]

Tu peux peut être essayer de te connecter en SSH à ton nas et de faire un "df -h" pour l'espace disque ou un "du -h -d 1" pour la taille des dossiers, histoire de vérifier si physiquement les choses sont encore là ou pas ?

J'ai eu besoin une fois ou 2 d'effacer des fichiers à la main en ssh car il avaient des caractères bizarres qui rendaient ineffectifs les actions sur ces fichiers par le partage samba, et le file station :/

[Tête de Cornet]

Tiens j'ai un peu le même problème, j'ai un serveur samba sur debian, j'ai monté un lecteur réseau sur mon windows 8 et quand j'efface des trucs à partir de windows, c'est pas compté comme étant disponible puisque j'ai toujours le message d'erreur comme quoi le disque est plein alors que c'est bien supprimé sur le serveur, je comprend pas . Si je supprime directement sur la debian ça pose pas de problème par contre, je suppose que y a un genre de catalogue qui est pas mis à jour quand j'efface à partir de windows mais je sais pas comment faire pour forcer la mise à jour

[Hipparchia]

Citation :

DS> df -h
Filesystem Size Used Available Use% Mounted on
/dev/md0 2.3G 464.2M 1.8G 20% /
/tmp 494.9M 756.0K 494.2M 0% /tmp
/dev/mapper/vol1-origin
5.4T 5.4T 3.6G 100% /volume1

Ca correspond à ce que je vois en tout cas.

Mon volume s'appelle de manière originale /volume1/
Donc voici le résultat de la commande "du -h -d 1 /volume1/" (ça a pris 5 bonnes minutes à cause des 5+To bien chargés

Citation :

DS> du -h -d 1 /volume1/
29.8M /volume1/@eaDir
65.5G /volume1/photo
8.0G /volume1/Saves
4.0K /volume1/NetBackup
521.6G /volume1/Anims
[...] 'dossiers web impossible à ouvrir'
31.9M /volume1/web
88.8G /volume1/Tutos
1.4T /volume1/Séries
5.4M /volume1/homes
4.0K /volume1/@quarantine
4.0K /volume1/@tmp
2.8G /volume1/video
2.8T /volume1/Films
338.6M /volume1/@database
12.0K /volume1/@spool
[...] 'dossiers @appstore du audiostation impossibleà ouvrir'
237.0M /volume1/@appstore
96.1G /volume1/Téléchargements
300.2G /volume1/@Download
129.4G /volume1/music
5.4T /volume1/

Donc il faut vider ce volume "@Download", qui visiblement sert de cache un peu merdique pour DiskStation et Photostation sur les Synology.
J'en ai profité pour renommer les dossier avec accents.

Sur mon terminal en SSH j'étais visiblement sur le dossier "music", un coup de "cd .." deux fois et j'ai vu tous les dossiers cachés (je ne vois pas les dossiers @ depuis l'interface web) :

Citation :

DS> ls
@appstore @quarantine Anims Series aquota.user video
@database @spool Films Telechargements homes web
@Download @stream.cgi.core NetBackup Tutos music
@eaDir @tmp Saves aquota.group photo

Si je fais un "ls" dans "@Download" c'est quoi le chiffre / nom de la dernière colonne ?

Citation :

[...]
drwxrwxrwx 2 root root 4096 Feb 1 15:35 96
drwxrwxrwx 2 root root 4096 Feb 1 15:36 97
drwxrwxrwx 2 root root 4096 Feb 1 15:36 98
drwxrwxrwx 2 root root 4096 Feb 1 15:36 99
drwxrwxrwx 2 root root 4096 Jan 13 11:24 torrents

Je ne vois pas la taille des fichiers avec la commande j'ai l'impression. J'ai raté quelque chose ?

Et sinon pour finir, une fois dans le dossier "@Download", je peux faire un "rm -rf *". C'est bon, je ne risque rien ?

[Hipparchia]

Bon, je gagne petit à petit de l'espace disque (300 Go étaient occupés par le contenu du cache @Download).
Merci pour votre aide

[Zuglok]

Content que tu aies pu régler ton pb

Pour répondre à ta question, le "chiffre" de la dernière colonne c'est des noms de dossiers, tu peux vérifier ça en regardant leur attributs "chmod" : drwxrwxrwx soit dossier en 777.

Sinon, pour ceux que ça intéresse, voici comment monter tout son nas sur un seul lecteur réseau, chose qui n'est pas permise de base :

1 : Se connecter en SSH sur son NAS via putty
2 : créer un dossier sur /volume1, par exemple share : mkdir /volume1/share
3 : créer un script de démarrage qui va monter /volume1 sur /volume1/share :
vi /usr/syno/etc.defaults/rc.d/s99mount.sh

Citation :

#!/bin/sh
mount --bind /volume1 /volume1/share

Rebooter pour que ce soit effectif, ou lancer la commande à la main pour tester.

Maintenant en montant \\nomdunas\share sur un lecteur réseau, l'intégralité de volume1 sera visible, dossiers cachés y compris.
J'ai aussi remarqué qu'il est possible par ce biais de faire des déplacements de données instantanés de dossiers à dossiers (films vers séries par exemple) alors qu'en passant par les partages samba classiques, cela lance des copies en passant par un cache local sur le PC...

A noter : il faut refaire ce script à chaque maj du système.

[Hipparchia]

J'ai branché un DD USB sur le NAS, j'ai téléchargé environ 250 go de données (depuis download station j'ai demandé que mon volume USB soit par défaut)... et bien pareil ça a encrassé le dossier @Download.
Tout ce que j'ai téléchargé sur l'externe, est passé par le cache du syno, qui ne se vide pas tout seul... Etrange.

[Hipparchia]

Citation :

Publié par Zuglok

Sinon, pour ceux que ça intéresse, voici comment monter tout son nas sur un seul lecteur réseau, chose qui n'est pas permise de base :

1 : Se connecter en SSH sur son NAS via putty
2 : créer un dossier sur /volume1, par exemple share : mkdir /volume1/share
3 : créer un script de démarrage qui va monter /volume1 sur /volume1/share :
vi /usr/syno/etc.defaults/rc.d/s99mount.sh

Rebooter pour que ce soit effectif, ou lancer la commande à la main pour tester.

Maintenant en montant \\nomdunas\share sur un lecteur réseau, l'intégralité de volume1 sera visible, dossiers cachés y compris.
J'ai aussi remarqué qu'il est possible par ce biais de faire des déplacements de données instantanés de dossiers à dossiers (films vers séries par exemple) alors qu'en passant par les partages samba classiques, cela lance des copies en passant par un cache local sur le PC...

A noter : il faut refaire ce script à chaque maj du système.

Ca marche nickel (maintenant je peux classer plein de fichiers d'un dossier à l'autre, c'est quasi immédiat).
Par contre quand je veux lire un fichier vidéo par exemple, depuis ce partage, c'est leeeeent (genre 15 secondes avant de s'ouvrir, impossible de naviguer dans le fichier etc). Si je reviens sur un partage smb classique, pas de soucis.
du coup j'utilise les deux partages, un pour classer, l'autre pour consulter

[Zuglok]

Je n'ai pas ce soucis avec vlc et un ds412+ sous dsm 4.2 :/

[Hipparchia]

Hum, j'ai l'impression que c'est parce que j'ai lancé une recherche depuis windows dans le partage share juste avant.
Je viens de re-tester aujourd'hui, ça fonctionne bien

[Hipparchia]

Le dossier @Download est en fait le dossier qui duplique les fichiers que tu as téléchargé.
Par exemple tu as un dossier "Téléchargement" où vont tes DL de Download Station, et bien Synology va te copier un double dans @Download. Pourquoi ?
Pour te permettre de déplacer ton fichier et qu'il soit toujours en seed.
(genre ton dossier film / anim etc).
Mais c'est complètement con non ? Au lieu de gérer ça avec des liens ou je ne sais pas, proposer une option pour réattribuer le bon chemin ils dupliquent.
On pourrait très bien imaginer que le @Download centralise tous les fichiers à partager, et que les autres fichiers dans les dossiers de classement ne soient que des liens, mais non, ils doublent.
Je trouve ça vraiment bizarre comme procédé

[Shachi]

Citation :

Publié par Hipparchia

Le dossier @Download est en fait le dossier qui duplique les fichiers que tu as téléchargé.
Par exemple tu as un dossier "Téléchargement" où vont tes DL de Download Station, et bien Synology va te copier un double dans @Download. Pourquoi ?
Pour te permettre de déplacer ton fichier et qu'il soit toujours en seed.
(genre ton dossier film / anim etc).
Mais c'est complètement con non ? Au lieu de gérer ça avec des liens ou je ne sais pas, proposer une option pour réattribuer le bon chemin ils dupliquent.
On pourrait très bien imaginer que le @Download centralise tous les fichiers à partager, et que les autres fichiers dans les dossiers de classement ne soient que des liens, mais non, ils doublent.
Je trouve ça vraiment bizarre comme procédé

Salut,

Je fais comment pour voir ce dossier et le vider ?
Quand je regarde dans file station de mon Synology, la somme des dossiers fait 1.8To et pourtant il m'indique que j'ai rempli 2.6To ?

Merci d'avance

[Benjiorka]

Bonjour
J'ai un NAS qnap plein de films, mais il me manque beaucoup de giga....
J'ai écris à qnap pour savoir comment faire et ils m'ont dis de taper cette commande:
"du -hx --max-depth=1 /share/MD0_DATA/ "
Je débute avec PUTTY mais j'ai réussi à me connecter et j'ai eu ca comme résultat...

Quelqu'un pourrait il me dire comment nettoyer et récupérer les giga qu'il me manque...
Si possible de manière simple!!!

Merci 1000x