La réponse est là, mais peut être mal présentée. Je me permets donc d'y apporter ma petite contribution.
Sous l'OS au pinguoin, les entrees sorties, quelque soit le type de périphérique de blocs (DD ATAPI/DD USB...), se fait de facon bufferisée. A savoir que l'OS garde en memoire les zones modifiées et/ou accédées, et les écrit/lit effectivement quant ca lui chante. Tout ceci est rendu possible, par le fait que sous unix, les périphériques sont explicitement montés, et donc l'OS sait pertinement qu'un disque est dispo ou pas, et que l'ecriture/lecture sur le média peut donc attendre LE moment opportun.
Or, ss Windows, les médias ne sont pas montés explicitement. L'OS automounte le média, et ne peut donc pas dans certains cas se prémunir d'une déconnection brutale du média (hop tu débranches le cable usb[1]). La seule solution consiste a faire des entrees/sorties non bufferisées, cad que la lecture/ecriture se fait sans aucun intermédiaire.
Application a ton cas:
- Ss windows, tu copies ton fichier sur le DD usb. Le transfert usb se fait immediatement. lA copie prend le temps exact imposé par la vitesse du canal (11Mbit/s pour l'usb 1.1).
- SS linux, tu copies ton fichier surle DD usb. L'OS, s'il dispose de suffisament de RAM alloue des pages de type "cache", y copie le fichier. Tout cela se fait biensur extremement vite. Qd l'OS juge opportun d'ecrire le contenu de ses pages "cache" (besoin urgent de RAM pour autre chose, umount du média, ...), il vide ses buffers sur le média réel, mais ceci se passe en background, probablement bien après que tu ait copié le fichier via l'explorer KDE. L'explorer KDE te montre en fait le temps de mise en cache dans la plupart des cas.
[1] Ss unix, la deconnexion d'un média sans un umount préalable rend le filesystem potentiellement inconsistent, car l'OS avait peut etre des buffers importants à y écrire. En gros, l'arrachage de cable c'est toujours aussi mauvais ss n'importe quel OS :)) pas de miracle.
[^] # Re: Explications ?!?§!
Posté par Edouard Gomez . En réponse au journal Explications ?!?§!. Évalué à 4.
Sous l'OS au pinguoin, les entrees sorties, quelque soit le type de périphérique de blocs (DD ATAPI/DD USB...), se fait de facon bufferisée. A savoir que l'OS garde en memoire les zones modifiées et/ou accédées, et les écrit/lit effectivement quant ca lui chante. Tout ceci est rendu possible, par le fait que sous unix, les périphériques sont explicitement montés, et donc l'OS sait pertinement qu'un disque est dispo ou pas, et que l'ecriture/lecture sur le média peut donc attendre LE moment opportun.
Or, ss Windows, les médias ne sont pas montés explicitement. L'OS automounte le média, et ne peut donc pas dans certains cas se prémunir d'une déconnection brutale du média (hop tu débranches le cable usb[1]). La seule solution consiste a faire des entrees/sorties non bufferisées, cad que la lecture/ecriture se fait sans aucun intermédiaire.
Application a ton cas:
- Ss windows, tu copies ton fichier sur le DD usb. Le transfert usb se fait immediatement. lA copie prend le temps exact imposé par la vitesse du canal (11Mbit/s pour l'usb 1.1).
- SS linux, tu copies ton fichier surle DD usb. L'OS, s'il dispose de suffisament de RAM alloue des pages de type "cache", y copie le fichier. Tout cela se fait biensur extremement vite. Qd l'OS juge opportun d'ecrire le contenu de ses pages "cache" (besoin urgent de RAM pour autre chose, umount du média, ...), il vide ses buffers sur le média réel, mais ceci se passe en background, probablement bien après que tu ait copié le fichier via l'explorer KDE. L'explorer KDE te montre en fait le temps de mise en cache dans la plupart des cas.
[1] Ss unix, la deconnexion d'un média sans un umount préalable rend le filesystem potentiellement inconsistent, car l'OS avait peut etre des buffers importants à y écrire. En gros, l'arrachage de cable c'est toujours aussi mauvais ss n'importe quel OS :)) pas de miracle.