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.
# FAT32 + SMB = Grosse galère
Posté par Olivier (site web personnel) . En réponse au message Problème de transfert de fichiers windows/linux. É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.