Bonjour
j'ai un petit serveur sous mandriva LE 2005.
Sur celui ci j'ai une partition en fat32 partagée avec samba, elle est bien visible depuis des pc windows xp, j'arrive à écrire dessus et tout.
sauf que le transfert est bizard :(
Par exemple, une copie d'un fichier de 700mo va mettre 30s à démarrer et va ensuite s'interrompre 2 ou 3 fois pendant 20s
niveau utilisation cpu j'ai smbd (30%) et un pdflush qui apparait (8%)
sur le coups je ne sais pas trop quoi faire
# Threads ?
Posté par Adrien BUSTANY (site web personnel) . Évalué à 1.
Personnellement, j'ai abandonné samba pour rendezvous + ftp, mais c'est moins simple à mettre en oeuvre peut être.
# ram ?
Posté par IntraveineuZ . Évalué à 1.
[^] # Re: ram ?
Posté par ginie . Évalué à 1.
# fat32
Posté par Khâpin (site web personnel) . Évalué à 2.
Je ne suis pas expert en la matière, mais il ne me paraît pas impossible que l'ext2/3 consomme moins de ressources que le FAT32.
Juste mes 2 pences
[^] # Re: fat32
Posté par ginie . Évalué à 1.
question, c'est possible de le faire sans perte de données ?
[^] # Re: fat32
Posté par Khâpin (site web personnel) . Évalué à 2.
Il faut que tu crées une partition ext2/3/Reiserfs/commetuveux, et que tu transfères tes données...
# FAT32 + SMB = Grosse galère
Posté par Olivier (site web personnel) . Évalué à 1.
j'ai eu exactement le même problème sur une MDK 9.2 et un kernel 2.4. Ton problème est dû au fait que lorsque Samba recoit l'ordre d'écriture d'un fichier de 700Mo, il va commencer, pour une partition FAT32, à ecrire un fichier vide de 700Mo. Le fichier sera constitué uniquement de "0". Puis, samba va faire une 2nd écriture sur ce fichier "vide" de 700Mo, et écrire les données que le client samba va envoyer. Le temps de la première écriture n'est pas négligeable, et les fortes occupations CPU de "pdflush" sont les écritures sur le DD
2 informations intéressantes :
- Si la partition sur laquelle on écrit ce fichier de 700Mo N'est PAS une FAT32, ce phénomène n'apparaît pas.
- Si le client samba (ton Windows XP) N'est PAS un Windows, ce phénomène n'apparaît pas non plus. Donc si le client est un Linux, il n'y a pas de problème.
J'ai pas mal cherché des infos sur le web, et j'ai analysé (avec un sniffer de trames IP) les différences entre les connexions smb d'un Linux et d'un Windows : Il n'y a pas de solution ou de configuration de ton serveur SAMBA pour résoudre ce problème.
La seule solution est de reformater ta partition FAT32 en ext2/3 reiserfs, ou autre.
Par contre, si ton problème est d'accéder à ces fichiers une fois que tu auras rebooté ton Linux sous Windows (c'est la seul explication plausible au fait que tu ais cette partition FAT32), je te conseille de regarder du coté de http://uranus.it.swin.edu.au/~jn/linux/explore2fs.htm(...) ou http://uranus.it.swin.edu.au/~jn/linux/ext2ifs.htm(...) . Le 2nd est particulièrement intéressant, puisque c'est un driver NT/2K/XP qui permet d'accéder en LECTURE à tes partitions ext2/3.
[^] # Re: FAT32 + SMB = Grosse galère
Posté par ginie . Évalué à 1.
et sinon, ce serveur n'a pas de windows, il est juste sous linux ;)
[^] # Re: FAT32 + SMB = Grosse galère
Posté par Olivier (site web personnel) . Évalué à 1.
Tu ne remarqueras des problèmes de perforance que sur des GROS fichiers. Pour des petits fichiers, le mécanisme de cache disque pasquera la 1ère écriture de fichiers entièrement vide
et sinon, ce serveur n'a pas de windows, il est juste sous linux ;)
Quel est l'intérêt d'avoir des partitions FAT32 alors ? Passe les en ext2/3 ou autre type de partition Linux, tu auras moins de problèmes.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.