[Résolu] Comment j'ai gagné 70GB sur mon disque de 1To (7%) !

Zakhar · Le 15/12/2010, à 00:51

Si ça vous intéresse... et si ça n'a pas déjà été fait, je vous fait un post (ou un sujet sur le Wiki) !

Remarquez qu'au prix du Giga actuel ça ne fait guère plus de 3€ de gain ... mais ça ma permis de prendre le temps de lire l'excellent sujet punaisé sur ce forum des "Autres matériels" concernant les WD, et éviter un achat non Linux-friendly, en perdant potentiellement bien plus d'argent (et de temps). Merci donc encore aux gens qui font vivre ce forum.

C'est encore un truc lié au fait que Linux soit à l'origine bien plus fait pour des serveurs que pour des Desktop, comme le changement de scheduler du kernel qui ferait des miracles (encore que je n'aie rien vu de flagrant sur ma Karmic avec ça).

Dernière modification par Zakhar (Le 19/12/2010, à 15:37)

Brunod · Le 15/12/2010, à 10:25

Tu veux te faire prier
Et bien on te prie
BD

Zakhar · Le 15/12/2010, à 20:52

Non, c'est juste que les experts du forums qui sont là tous les jours connaissent bien l'existence (ou pas) de ce genre de sujet et auraient pu dire : oui, ça a déjà été traité là...

Je vais donc faire plutôt une rubrique optimisation Ext (2/3/4) dans le wiki.

Il n'y a rien de sorcier dans ce que j'ai fait, j'ai juste lu le man de mkfs.ext4 et de tune2fs ainsi que pas mal d'articles de référence sur le Web pour tâcher de comprendre les différents paramètres du file system, ceux qui sont utiles et ceux qui le sont moins. Tout cela dépend bien sûr des cas d'usage.

Le plus gros du gain est connu : par défaut un formatage Ext 2/3/4 réserve 5% d'espace à root... ce qui est superbement inutile sur une partition que l'on destine à des sauvegardes faites par l'utilisateur.

Cet espace réservé peut même être récupéré sans reformater de façon très simple (1 commande).
Je vais éviter de la commande donner ici sans explications détaillées (je ferai ça quand j'aurai un peu + de temps, ce W.E.) car mal exécutée, ça peut perturber un système si on est proche de la saturation de la partition système.

Mais si on comprend ce qu'on fait et pourquoi on le fait, il n'y a pas de problème à récupérer cet espace.

Dernière modification par Zakhar (Le 15/12/2010, à 20:53)

Zakhar · Le 19/12/2010, à 12:54

Je te le fais en MP (pour éviter qu'une commande indiqué publiquement soit mal utilisée) puisque ça n'intéresse visiblement personne de récupérer de l'espace sur ses disques.

lool_lauris · Le 19/12/2010, à 13:14

Salut,

Ben si, vas-y ... dis-nous ce que tu as fait !
Il a raison Brunod, il semble bien que tu aimes te faire prier !

Bye,
lool

Autiwa · Le 19/12/2010, à 13:16

@lool_lauris +1

michel_04 · Le 19/12/2010, à 13:37

Autiwa a écrit :

@lool_lauris +1

lost+found +1

xtriade · Le 19/12/2010, à 14:43

bonjour,

si cela vous intéresse : l'article estici

la commande à manipuler avec extreme précaution : tune2fs -m 1

Dernière modification par xtriade (Le 19/12/2010, à 14:49)

kyncani · Le 19/12/2010, à 14:52

- Pour une partition de données : booter sur livecd et sudo tune2fs -m 0 /dev/sdXY
- Pour une partition système : laisser tel quel

Petit exemple de décompte : un disque de 1 téraoctet équivalent à 0.9 tébioctets (http://fr.wikipedia.org/wiki/Octet) + 5% réservés à root -> reste 860 gibioctets libres environ.

Zakhar · Le 19/12/2010, à 15:36

Ah voila... je savais bien que ça existait sur la doc.

Bon eh bien c'est juste bien caché et pas vraiment mis en évidence. Quelqu'un peut réorganiser ?

Par contre l'histoire de la défragmentation j'y crois pas vraiment. Il faudra qu'on me démontre qu'un algorithme qui réserve de la place permet de moins fragmenter. Tout au plus je veux bien croire que l'apparition de la fragmentation est retardée au moment où cet espace est utilisé... mais donc s'il est disponible c'est tout pareil.

Bref -m 0 est à mon avis tout à fait sûr dans la mesure où il ne s'agit pas de la partition système (ou /var ).

Il existe également d'autres options intéressantes, mais contrairement au -m 0 (ou -m 1 si on accorde foi aux légendes urbaines) qui est faisable "à la volée" ne sont faisable qu'au moment du formatage.

Par exemple, pour une partition qui ne va contenir que des gros fichiers genre vidéo, on peut formater en :

ATTENTION : cette commande formate !

sudo mkfs.ext4 /dev/sdX -m 0 -T largefile4

Les types de file system disponibles sont décrits dans le fichier

/etc/mke2fs.conf

largefile4 : correspond à 1 inode tous les 4MB de données disque. Tout à fait suffisant pour un disque contenant des fichiers video.

Et donc, comme la doc existe, je marque [résolu].

Pour le détail des 7% voici mes tests sur une partition de 500GB (fait 2 fois, le disque étant un 1TB)

La commande est mkfs.ext4 /dev/sdc1 (dans mon cas) plus les options indiquées (première ligne : formatage par défaut, sans options)

Options                                                Utilisable            Occupé   % occupé
                                                  492 256 313 344    25 212 788 736   5,12%
-m 0                                              492 256 313 344       207 527 936   0,04%
-m 0 -T largefile4                                500 041 867 264       207 527 936   0,04%
-m 0 -T largefile4 -O ^resize_inode               500 041 867 264       134 238 208   0,03%
-m 0 -T largefile4 -O ^resize_inode -J size=32    500 041 867 264        33 574 912   0,01%

Le dernier formatage est le seul qui laisse un espace disponible de 500 008 292 352, symboliquement le seul supérieur à la barrière des 500 millions d'octets.
Le formatage standard (sans options) laisse 467 043 524 608 d'octets, soit un écart de 6,59% entre le truc standard et l'optimisation pour stockage de gros fichiers.

Mes autres options :
-O ^resize_inode : demande de ne pas réserver d'espace pour redimensionner la table de inode. En effet, le man indique que celle-ci peu grossir jusqu'à 1024 fois son espace d'origine. Inconvénient de cette option : si on arrive à épuiser les inodes, il faut sauvegarder et reformater.
ATTENTION : bien sûr, si vous prévoyez de redimensionner un jour cette partition, n'utilisez pas cette option car resize2fs ne pourra alors pas opérer sur votre partition (voir le commentaire dans ce patch de resize2fs : http://lists.openwall.net/linux-ext4/2008/06/17/3)
Dans mon cas c'est même beaucoup trop d'inodes en réserve voici :

Inode count:              119264
Free inodes:              118118

J'ai 1134 fichiers/répertoires soit une moyenne de 440MB par fichier. Il y a encore largement de quoi voir venir en inodes comme vous constatez !

-J size=32 : par défaut le journal fait 128MB. Là on le réduit au quart de cette valeur. Les fichiers sur ce disque étant assez "statiques" et changeant peu c'est aussi plus que largement suffisant.

Dernière modification par Zakhar (Le 08/10/2011, à 10:14)

cep · Le 19/12/2010, à 15:38

kyncani a écrit :

- Pour une partition de données : booter sur livecd et sudo tune2fs -m 0 /dev/sdXY
- Pour une partition système : laisser tel quel
Petit exemple de décompte : un disque de 1 téraoctet équivalent à 0.9 tébioctets (http://fr.wikipedia.org/wiki/Octet) + 5% réservés à root -> reste 860 gibioctets libres environ.

Salut,

Même pour une partition de données il est tout de même préférable de laisser un petit quelque chose en réservé, au minimum 0.5 pour éviter la saturation par un user. Inutile de passer par le stade live cd.

Sur un fs système, suivant la taille du fs on peut aussi réduire ce pourcentage, éventuellement en en laissant un peu plus.

Enfin si on veut modifier le comportement par défaut de mkfs.extx sur certains points il faut configurer /etc/mke2fs.conf

Zakhar · Le 19/12/2010, à 16:16

cep a écrit :

Inutile de passer par le stade live cd.

Je confirme. le tune2fs -m 0 fonctionne même filesystem monté !

cep a écrit :

Même pour une partition de données il est tout de même préférable de laisser un petit quelque chose en réservé, au minimum 0.5 pour éviter la saturation par un user.

Peux-tu développer ? On parle évidemment de partitions de données, c'est à dire ou en principe seul le "user" va mettre des données. Le système n'est pas sensé y toucher. Donc réserver X% aura juste pour effet de "saturer" à (100 - X)% au lieu de saturer à 100%, mais je ne vois pas en quel sens ça "évite" la saturation.
Fais-je une erreur de raisonnement ou est-ce encore une légende urbaine ?

cep a écrit :

Sur un fs système, suivant la taille du fs on peut aussi réduire ce pourcentage, éventuellement en en laissant un peu plus.

Absolument ! N'oublions pas que le truc date de l'époque de ext2. Or le système écrit en gros des fichiers texte (logs, syslog, etc...)
5% était certainement une mesure intéressante à l'époque où on avait des disques qui étaient de taille d'un DVD... mais désormais c'est absolument démesuré si on regarde la taille des disques actuels.
Ma partition système fait 25GB (sur 2TB !..) et j'ai vu large, elle n'est même pas à 30%
5% de ce tout petit espace (par rapport au disque dans son ensemble) ça fait 1,25GB. C'est totalement démesuré pour stocker des logs !..
Je vais cependant le laisser ainsi car "récupérer" 1,25GB sur un disque de 2TB est assez dérisoire. De plus, sur la partition système, cet espace n'est pas "perdu", il est juste "réservé", puisque précisément "root" peut écrire dessus au besoin.
Conclusion : sur la partition où / est monté, on peut laisser les choses en l'état (sauf si on a mélangé / avec des données utilisateur, mais là c'est mal !..)

cep a écrit :

Enfin si on veut modifier le comportement par défaut de mkfs.extx sur certains points il faut configurer /etc/mke2fs.conf

Oui, tout à fait. Et on peut regarder comment sont déclarer les "Types" de FS par défaut comme "largefile" ou "largefile4"

Dernière modification par Zakhar (Le 19/12/2010, à 16:17)

cep · Le 19/12/2010, à 17:26

Zakhar a écrit :

cep a écrit :
Même pour une partition de données il est tout de même préférable de laisser un petit quelque chose en réservé, au minimum 0.5 pour éviter la saturation par un user.
Peux-tu développer ? On parle évidemment de partitions de données, c'est à dire ou en principe seul le "user" va mettre des données. Le système n'est pas sensé y toucher. Donc réserver X% aura juste pour effet de "saturer" à (100 - X)% au lieu de saturer à 100%, mais je ne vois pas en quel sens ça "évite" la saturation.
Fais-je une erreur de raisonnement ou est-ce encore une légende urbaine ?

légende urbaine ? tiens-donc

D'abord entre 100 - x et 100 il y a tout de même un écart de x. Non ? donc pas de saturation, il suffira de modifier x pour intervenir sur le fs suivant l'usage et la destination du fs.
Mais, aussi, si tu es près de saturer totalement ton fs le bloc_allocator aura du mal à trouver des zones contigues suffisantes, d'où pertes de performances et, par exemple sur ext4, il sera difficile de faire jouer certaines features, optimisations, défragmentations
https://ext4.wiki.kernel.org/index.php/Ext4_Howto#
Et, si par défaut les blocs réservés sont attribués à root, rien n'empĉhe de les auttribuer à un autre user en positionnant le reserved blocks uid et/ou reserved blocks gid

Zakhar · Le 20/12/2010, à 02:37

cep a écrit :

D'abord entre 100 - x et 100 il y a tout de même un écart de x. Non ? donc pas de saturation, il suffira de modifier x pour intervenir sur le fs suivant l'usage et la destination du fs.

"... suivant l'usage du fs", je suis d'accord. Si c'est un fs utilisé par des daemons sytem par exemple. Mais je parle d'un disque de données. C'est juste "psychologique" d'avoir une "réserve". Au pire ça te dit "disque plein", tu peux libérer la "réserve" et jouer encore un peu, mais si tu n'as pas d'autre place ça sera juste plein un peu plus tard. Donc chose inutile à mon sens !

cep a écrit :

Mais, aussi, si tu es près de saturer totalement ton fs le bloc_allocator aura du mal à trouver des zones contigues suffisantes, d'où pertes de performances et, par exemple sur ext4, il sera difficile de faire jouer certaines features, optimisations, défragmentations

Je ne suis toujours pas convaincu, tu n'expliques pas en quoi on a plus de mal à trouver des zones contigues sur un disque plein où on a réservé 5% et sur un disque sans réservation plein à 95%. C'est juste une question d'algorithme. D'ailleurs la page que tu as lié indique que le "online defragmentor" est en cours de mise au point. A mon sens, réserver ou pas, ça ne change rien.
D'ailleurs tu les réserves où les 5% : au début, à la fin, un peu partout ? Eh bien tu peux faire exactement pareil sans réserver en laissant des trous au bon endroit dans l'allocateur. Mais à la fin, quand ton disque sera saturé, la fragmentation sera la même que tu aies réservé ou pas.

Pour moi c'est donc toujours une légende urbaine (sauf évidemment sur / où ça peut s'avérer très utile).

Dernière modification par Zakhar (Le 20/12/2010, à 02:44)

cep · Le 20/12/2010, à 08:59

Zakhar a écrit :

Pour moi c'est donc toujours une légende urbaine (sauf évidemment sur / où ça peut s'avérer très utile).

Libre à toi d'écrire tes propres légendes.

Là je n'ai pas le temps de reprendre les sources de mke2fs et de revoir les features incompatibles si le ratio de % réservé n'est pas bon, mais je le ferai peut-être dans quelques temps.

Zakhar · Le 20/12/2010, à 20:09

On apprend toujours !

N'hésite pas à revenir sur ce post pour ces précisions car il est vrai qu'en réfléchissant j'ai du mal à imaginer un algorithme qui bénéficie d'une telle réservation, mais sans doute qu'il y a des briques du raisonnement qui m'échappent.

Linuxpat · Le 12/12/2018, à 10:25

Bonjour à tous,
Je souhaite optimiser l'espace réservé au système de fichier de l'EXT4 sur un 4To réservé uniquement à du stockage de données, tel que photos, vidéo, musiques et documents perso, donc la sécurité y est quand même importante.

En Ntfs j'ai vu (sauf erreur de ma part) que linux ne traitait pas ou mal la totalité des fonctionnalités tel que la récupération des erreurs de fichiers, la corbeille, la défragmentation, gestion des droits des fichiers etc...

En EXT4, le problème est la taille statique réservée au système de fichier et vu qu'il est prévu pour toutes sortes de configurations comme des bases de données, les réglages par défauts ne sont trop "espacesorvore" pour mon cas.

Dans mon cas sur ce 4To vierge la format EXT4 par défaut occupe 58.53Go d'espace réservé. en Ntfs seulement 180mo !!!.
Sur un autre disque du même modèle ne contenant que des vidéos, donc que des gros fichiers, qui est rempli à 78%
et donc seulement 11034 inodes utilisés sur les 231383040 créés.

Mais difficile de prévoir à l'avance qu'est ce je mettrais sur ces disques, une sauvegarde peut créer très vite pas mal de petits fichiers, les vignettes des photos ou les meta données xml par exemple, sont de petites tailles et sont aussi nombreuses que les photos.

Bref au lieu de jouer uniquement sur le nombre d'inodes, et prendre le risque de se retrouver coincé plus tard, j'ai fait un test avec un formatage avec:
blocksize = 2048 au lieu 4096ko par défaut (la taille réservée et divisée par 2) logique
il reste le inode_size = 128 au lieu de 256ko (utilisé en ext3) pas testé encore, compatibilité ? risque ?
enfin le inode_ratio = ? qu'il ne faudrait pas trop descendre, mais un peu quand même.

Dans le mke2fs.conf, il y a plusieurs configuration possible. Est-ce qu'il y a une risque de formater un gros disque avec un réglage "small" par exemple
blocksize = 1024
inode_size = 128
inode_ratio = 4096

Est-ce certain logiciel peuvent ne plus reconnaître la partition formatée ainsi ? ou créer des erreurs d'écritures ?

Donc voilà j'aimerais avoir vos avis et notamment celui de Zakhar et savoir si depuis ses réglages, que je trouve un peu trop risqué pour moi, s'il a rencontré des difficultés.

Par avance merci pour vos lumières éclairées

Zakhar · Le 15/12/2018, à 00:38

Bonjour @Linuxpat, si tu suis bien ce que j'ai indiqué au post #10, tu es très loin du compte avec 58Go !

Par simple règle de 3, comme j'ai montré le formatage d'une partition de 500Go, tu devrais arriver avec les mêmes réglages que moi à 33 x 8 = 264 Mo de réservé avec l'option la plus conservatrice.

Sans rien changer au formatage standard qui te permet de stocker un myriade de petits fichiers, mais simplement en retirant les 5% réservés à "root", tu devrais arriver à 1,6Go de réservés.

Au prix de la surface disque, 1.6Go sur un disque de 4T c'est pas trop un problème.

Donc fais bien ce qui est indiqué, et en passant simplement la commande pour retirer les blocs réservés à root, tu devrais voir un mieux significatif.

Cela se fait avec l'option "-m0" si tu formates en ligne de commande. Si tu as déjà formaté et mis des données, tu peux toujours faire un tune2fs sans rien casser pour retirer les blocs réservés. Regarde le "man" de tune2fs, et il faut bien sûr que la partition soit démontée dans quand tu la "tune".

Linuxpat · Le 15/12/2018, à 20:34

Bonjour Zakhar, J'ai bien lu et relu ton post mais je dois passer à coté de quelque chose...
Par exemple ça correspond à quoi ton "33x8" ?
Je dois me mélanger les pinceaux entre les blocs, secteurs et i-tête2noeuds

Chez moi en essayant avec seulement avec l'option "-m0"

pat@traque ~ $ sudo mkfs.ext4 /dev/sde7 -m 0
mke2fs 1.42.13 (17-May-2015)
/dev/sde7 contient un système ext4, NOUS ALLONS DEVOIR TUER VOTRE CHIEN...
...
En train de créer un système de fichiers avec 925527296 4k blocs et 231383040 i-noeuds.
UUID de système de fichiers=bla bla bla...
Superblocs de secours stockés sur les blocs : 
	32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632, 2654208, 
	4096000, 7962624, 11239424, 20480000, 23887872, 71663616, 78675968, 
	102400000, 214990848, 512000000, 550731776, 644972544
...                     
Création du journal (32768 blocs) : complété
TADA!!!... ah non ça c'est chez Windows...

Gparted m'indique encore une occupation de 55.47Go au lieu des 58.53Go par rapport au formatage par défaut.

Par contre je ne retombe pas sur les mêmes valeurs avec:

pat@chon ~ $ df -h /dev/sde7
Sys. de fichiers Taille Utilisé Dispo Uti% Monté sur
/dev/sde7          3,4T     70M  3,4T   1% /mnt/N300.4T.2

Et pour info

pat@pouffes ~ $ df -i -h /dev/sde7
Sys. de fichiers Inœuds IUtil. ILibre IUti% Monté sur
/dev/sde7          221M     11   221M    1% /mnt/N300.4T.2

Y a quelque chose qui ne colle pas 70Mo occupé ou 221Mo ??? Pas tout compris...

Curieusement en NTFS Gparted et "df" donne le même résultat ?
174,77Mio pour Gparted

pat@crêpes ~ $ df -h /dev/sde7
Sys. de fichiers Taille Utilisé Dispo Uti% Monté sur
/dev/sde7          3,5T    175M  3,5T   1% /mnt/N300.4T.2

et forcement pas de Inoeuds, tu vois je suis un peu...

Avec l'option:

pat@pon ~ $ sudo mkfs.ext4 /dev/sde7 -m 0 -T largefile4

Gparted m'indique plus que 657.44Mo d'occupé
et "df" toujours 70Mo ??? (il doit faire grêve sur un rond point...)

df -h /dev/sde7
Sys. de fichiers Taille Utilisé Dispo Uti% Monté sur
/dev/sde7          3,5T     70M  3,5T   1% /mnt/N300.4T.2

pat@plusd'idées ~ $ df -i -h /dev/sde7
Sys. de fichiers Inœuds IUtil. ILibre IUti% Monté sur
/dev/sde7          883K     11   883K    1% /mnt/N300.4T.2

Alors ou ai-je loupé le virage ? Mes disques sont hantés ou sponsorisé par Micro$oft
Bon ne tirez pas trop vite sur l'ambulance, si j'ai fais ou dis des TUUUUUT, "je suis Linux" que depuis 1 an...
merci d'avance pour votre patience...
@+

Zakhar · Le 16/12/2018, à 12:46

Visiblement le df avec -i te donne le compte des inodes.

Donc ça occupe 70Mo, et tu as 221M inodes disponibles... de quoi voir venir en nombres de fichiers.

A mon avis c'est GParted qui est farfelu. Toujours de fier plutôt à la bonne vieille ligne de commande !..

Si tu veux en avoir le coeur net, le mieux est dumpe2fs

Exemple :

df -h /dev/sdb5
Sys. de fichiers Taille Utilisé Dispo Uti% Monté sur
/dev/sdb5          806G    629G  178G  78% /mnt/Cold

Que l'on peut vérifier :

sudo dumpe2fs -h /dev/sdb5
dumpe2fs 1.42.13 (17-May-2015)
Filesystem volume name:   Data
Last mounted on:          /mnt/Cold
(...)
Inode count:              206240
Block count:              211159936
Reserved block count:     0
Free blocks:              50463758
Free inodes:              42335
First block:              0
Block size:               4096
(...)
Lifetime writes:          17 TB
Reserved blocks uid:      0 (user root)
Reserved blocks gid:      0 (group root)
(...)
Taille du journal :         32M
Longueur du journal :      8192

Tu peux faire le calcul de l'espace total en multipliant la taille d'un "block" par le nombre de blocks: 211159936 x 4096, on est bien autour des 800Go
Pour les libres pareil : 50463758 x 4096, on est un peu sous les 200G

On vérifie également qu'on a bien 0 blocs réservés (Reserved block count: 0), puisque cette partition sert à mettre des données, et n'est pas une partition système.

dumpe2fs donne aussi une information amusante, le "lifetime write" (enfin depuis que la partition a été formatée).
Donc cette partition que je montre qui fait 800Go a déjà écrit 17To, on l'a donc écrite un peu plus de 20 fois.
On constate que même si c'était un SSD, on est loin d'avoir épuisé le nombre possible d'écritures.

Quand au 33 x 8, c'est une multiplication... était-ce bien sorcier ?
Ca correspond à une "règle de trois"... mais c'est vrai que la "règle de trois" est le summum des mathématiques et demande bac + 18... désolé !
(En fait la simple proportion entre mon disque et le tien qui est un facteur 8, il suffit donc de multiplier par 8 les chiffres que je donne...)

Dernière modification par Zakhar (Le 16/12/2018, à 12:53)

Linuxpat · Le 17/12/2018, à 14:11

Merci pour tes explications c'est beaucoup plus clair.

Ceci dis pour un débutant ce n'est pas très encourageant de poser des questions sur un forum si la moquerie voire la condescendance est au rendez vous.
Ce n'est pas la premier fois que je le constate sur ce forum. Je croyais le monde Linux plus "OPEN" que ça !!!

Quand on découvre un sujet, la compréhension n'est pas toujours au rendez-vous. Je ne suis pas dans ta tête.
Maintenant que je j'ai percuter d’où venais les "33" de ta règle de trois, c'est une évidence pour moi aussi.
Le reste était peut-être inutile.
Merci de ta compréhension.
Cordialement.

Zakhar · Le 17/12/2018, à 19:22

Il n'y a pas de mal à ignorer, on est tous passés par là avant de savoir. Par contre certains persistent, mais ça ne semble pas être ton cas.

Bravo donc et bienvenue dans le monde du libre.

Ubuntu-fr

Navigation

Liens de recherche

Annonce

#1 Le 15/12/2010, à 00:51

[Résolu] Comment j'ai gagné 70GB sur mon disque de 1To (7%) !

#2 Le 15/12/2010, à 10:25

Re : [Résolu] Comment j'ai gagné 70GB sur mon disque de 1To (7%) !

#3 Le 15/12/2010, à 20:52

Re : [Résolu] Comment j'ai gagné 70GB sur mon disque de 1To (7%) !

#4 Le 19/12/2010, à 12:54

Re : [Résolu] Comment j'ai gagné 70GB sur mon disque de 1To (7%) !

#5 Le 19/12/2010, à 13:14

Re : [Résolu] Comment j'ai gagné 70GB sur mon disque de 1To (7%) !

#6 Le 19/12/2010, à 13:16

Re : [Résolu] Comment j'ai gagné 70GB sur mon disque de 1To (7%) !

#7 Le 19/12/2010, à 13:37

Re : [Résolu] Comment j'ai gagné 70GB sur mon disque de 1To (7%) !

#8 Le 19/12/2010, à 14:43

Re : [Résolu] Comment j'ai gagné 70GB sur mon disque de 1To (7%) !

#9 Le 19/12/2010, à 14:52

Re : [Résolu] Comment j'ai gagné 70GB sur mon disque de 1To (7%) !

#10 Le 19/12/2010, à 15:36

Re : [Résolu] Comment j'ai gagné 70GB sur mon disque de 1To (7%) !

#11 Le 19/12/2010, à 15:38

Re : [Résolu] Comment j'ai gagné 70GB sur mon disque de 1To (7%) !

#12 Le 19/12/2010, à 16:16

Re : [Résolu] Comment j'ai gagné 70GB sur mon disque de 1To (7%) !

#13 Le 19/12/2010, à 17:26

Re : [Résolu] Comment j'ai gagné 70GB sur mon disque de 1To (7%) !

#14 Le 20/12/2010, à 02:37

Re : [Résolu] Comment j'ai gagné 70GB sur mon disque de 1To (7%) !

#15 Le 20/12/2010, à 08:59

Re : [Résolu] Comment j'ai gagné 70GB sur mon disque de 1To (7%) !

#16 Le 20/12/2010, à 20:09

Re : [Résolu] Comment j'ai gagné 70GB sur mon disque de 1To (7%) !

#17 Le 12/12/2018, à 10:25

Re : [Résolu] Comment j'ai gagné 70GB sur mon disque de 1To (7%) !

#18 Le 15/12/2018, à 00:38

Re : [Résolu] Comment j'ai gagné 70GB sur mon disque de 1To (7%) !

#19 Le 15/12/2018, à 20:34

Re : [Résolu] Comment j'ai gagné 70GB sur mon disque de 1To (7%) !

#20 Le 16/12/2018, à 12:46

Re : [Résolu] Comment j'ai gagné 70GB sur mon disque de 1To (7%) !

#21 Le 17/12/2018, à 14:11

Re : [Résolu] Comment j'ai gagné 70GB sur mon disque de 1To (7%) !

#22 Le 17/12/2018, à 19:22

Re : [Résolu] Comment j'ai gagné 70GB sur mon disque de 1To (7%) !

Pied de page des forums