Averelll avait écrit le 18.01.2010 :
> Michel Doucet a écrit :
>> Bonjour/soir, le Mon, 18 Jan 2010 18:38:26 +0100, *Averelll* a caressé son
>> clavier pour nous dire dans le message suivant:
>>
>>>> Je préfère une Dacia qui marche qu'une Porsche bling-bling qui doit
>>>> aller en révision tous les 15 jours ...
>>>>
>>> tellement imbu de votre petite personne que vous passez votre temps à
>>> vouloir imposer votre choix en proférant mensonges et contrevérités.
>>
>> Préférer ne veut pas dire imposer.
>
> C'est pourquoi depuis des années vous ne cessez de troller les groupes
> windows avec mépris et suffisance.
>
> > Imposer c'est ce que MS$ fait avec ces
>> softs troués installés sans le consentement des consommateurs au mépris des
>> lois européennes.
>>
> et c'est reparti avec vos obsessions. Vous êtes un grand malade.
Linux n'est pas le préféré, et il n'arrive pas à s'imposer
Tirer en leçon, Monsieur le Trôleur Obsessionnel
L'étrange chimie qui agite votre cerveau créée des effets propres à
votre personne, vous faisant croire à l'universalité de vos propos, qui
sont, je dois le dire, juste délirants
Avec la lumière du jour, il est préférable d'ouvrir grand les fenêtres
et de vous laisser pénétrer par la lumière salvatrice et réparatrice,
qui dissipera les ombres qui se cachent derrière vous
Le pingouin qui hante vos rêves doit vous quitter au chant du coq,
quitte à le retrouver dès la nuit tombée
Ces quelques heures de répits seront indiscutablement profitables à
tous les deux, et ils vous remercieront chaleureusement
--
P4nd1-P4nd4 vous salue, et annonce que le petit ourson possède
désormais son blog
p4nd1-p4nd4.over-blog.com
Le Wed, 20 Jan 2010 09:56:32 +0100 P4nd1-P4nd4 a écrit :
Yliur vient de nous annoncer : >> Jamais une sauvegarde t'apportera la même sécurité qu'un RAID 1 >> Ca ne travaille pas du tout au même niveau. >> >> Ton disque de backup : Ça fait deux heures que tu développes. Pan, >> ton disque pète. Tu as perdu tes deux heures de boulot. Point >> Barre. > > Sans compter l'interruption de service (sur un serveur). Bon > évidemment peut-être qu'avec des serveurs Windows on n'est pas à ça > près ?
Heuu, les backuops sous Windows utilisent des snapshots...
Je n'ai pas compris la réponse. Si ton disque tout seul claque sur ton serveur, le service qu'il fournit est interrompu. Ça n'a rien à voir avec le problème des sauvegardes : avoir deux disques en miroir te permet dans ce cas de garder le serveur sur pied lorsqu'un disque meurt. Mais si tu me dis que de toutes façons les serveurs sont arrêtés un p eu tous les jours pour maintenance, je comprends qu'on s'en fiche de l'interruption de service dans le cas d'un disque qui lâche...
Le Wed, 20 Jan 2010 09:56:32 +0100
P4nd1-P4nd4 <P4nd1-P4nd4@.net> a écrit :
Yliur vient de nous annoncer :
>> Jamais une sauvegarde t'apportera la même sécurité qu'un RAID 1
>> Ca ne travaille pas du tout au même niveau.
>>
>> Ton disque de backup : Ça fait deux heures que tu développes. Pan,
>> ton disque pète. Tu as perdu tes deux heures de boulot. Point
>> Barre.
>
> Sans compter l'interruption de service (sur un serveur). Bon
> évidemment peut-être qu'avec des serveurs Windows on n'est pas à ça
> près ?
Heuu, les backuops sous Windows utilisent des snapshots...
Je n'ai pas compris la réponse. Si ton disque tout seul claque sur ton
serveur, le service qu'il fournit est interrompu. Ça n'a rien à voir
avec le problème des sauvegardes : avoir deux disques en miroir te
permet dans ce cas de garder le serveur sur pied lorsqu'un disque
meurt.
Mais si tu me dis que de toutes façons les serveurs sont arrêtés un p eu
tous les jours pour maintenance, je comprends qu'on s'en fiche de
l'interruption de service dans le cas d'un disque qui lâche...
Le Wed, 20 Jan 2010 09:56:32 +0100 P4nd1-P4nd4 a écrit :
Yliur vient de nous annoncer : >> Jamais une sauvegarde t'apportera la même sécurité qu'un RAID 1 >> Ca ne travaille pas du tout au même niveau. >> >> Ton disque de backup : Ça fait deux heures que tu développes. Pan, >> ton disque pète. Tu as perdu tes deux heures de boulot. Point >> Barre. > > Sans compter l'interruption de service (sur un serveur). Bon > évidemment peut-être qu'avec des serveurs Windows on n'est pas à ça > près ?
Heuu, les backuops sous Windows utilisent des snapshots...
Je n'ai pas compris la réponse. Si ton disque tout seul claque sur ton serveur, le service qu'il fournit est interrompu. Ça n'a rien à voir avec le problème des sauvegardes : avoir deux disques en miroir te permet dans ce cas de garder le serveur sur pied lorsqu'un disque meurt. Mais si tu me dis que de toutes façons les serveurs sont arrêtés un p eu tous les jours pour maintenance, je comprends qu'on s'en fiche de l'interruption de service dans le cas d'un disque qui lâche...
Nicolas George
Michel Talon, dans le message <hj6hea$2i4a$, a écrit :
Fragmenter c'est en théorie toujours couteux en temps
Pas tout à fait : c'est coûteux quand il y a un temps d'accès important par rapport au temps de lecture séquentielle, en particulier quand il y a un mouvement mécanique. Fragmenter sur un SSD, on s'en contrefout.
Michel Talon, dans le message <hj6hea$2i4a$1@asmodee.lpthe.jussieu.fr>,
a écrit :
Fragmenter c'est en théorie toujours couteux en temps
Pas tout à fait : c'est coûteux quand il y a un temps d'accès important par
rapport au temps de lecture séquentielle, en particulier quand il y a un
mouvement mécanique. Fragmenter sur un SSD, on s'en contrefout.
Michel Talon, dans le message <hj6hea$2i4a$, a écrit :
Fragmenter c'est en théorie toujours couteux en temps
Pas tout à fait : c'est coûteux quand il y a un temps d'accès important par rapport au temps de lecture séquentielle, en particulier quand il y a un mouvement mécanique. Fragmenter sur un SSD, on s'en contrefout.
Nicolas George
debug this fifo , dans le message <hj6d2n$39g$, a écrit :
<foo> omg, j'ai un fichier PAGEFILE.SYS de 6100 Mo dans C: <bar> ça sert à rien, efface !
ls -lh /proc/kcore
debug this fifo , dans le message <hj6d2n$39g$1@speranza.aioe.org>, a
écrit :
<foo> omg, j'ai un fichier PAGEFILE.SYS de 6100 Mo dans C:
<bar> ça sert à rien, efface !
debug this fifo , dans le message <hj6d2n$39g$, a écrit :
<foo> omg, j'ai un fichier PAGEFILE.SYS de 6100 Mo dans C: <bar> ça sert à rien, efface !
ls -lh /proc/kcore
debug this fifo
P4nd1-P4nd4 wrote:
La fiabilité contre un dommage mécanique est sans doute meilleur sur un RAID 1, mais ce sentiment est juste une hallucination, car il n'offre aucune sécurité contre l'effacement ou la mise à jour accidentelle de données
le raid n'est pas prevu pour les problemes de chaise.
(Je rajouterai aussi sous Linux contre la corruption maladive du système de fichier pourri)
de quel systeme de fichier tu parles, là ? ntfs-3g ?
Utilise un seul dique, mets le second dans un boitier USB et utilise le pour faire des sauvegardes full et incrémentales
"dique", ça s'écrit "dick".
P4nd1-P4nd4 wrote:
La fiabilité contre un dommage mécanique est sans doute meilleur sur un
RAID 1, mais ce sentiment est juste une hallucination, car il n'offre
aucune sécurité contre l'effacement ou la mise à jour accidentelle de
données
le raid n'est pas prevu pour les problemes de chaise.
(Je rajouterai aussi sous Linux contre la corruption maladive du système
de fichier pourri)
de quel systeme de fichier tu parles, là ? ntfs-3g ?
Utilise un seul dique, mets le second dans un boitier USB et utilise le
pour faire des sauvegardes full et incrémentales
La fiabilité contre un dommage mécanique est sans doute meilleur sur un RAID 1, mais ce sentiment est juste une hallucination, car il n'offre aucune sécurité contre l'effacement ou la mise à jour accidentelle de données
le raid n'est pas prevu pour les problemes de chaise.
(Je rajouterai aussi sous Linux contre la corruption maladive du système de fichier pourri)
de quel systeme de fichier tu parles, là ? ntfs-3g ?
Utilise un seul dique, mets le second dans un boitier USB et utilise le pour faire des sauvegardes full et incrémentales
"dique", ça s'écrit "dick".
JKB
Le 20-01-2010, ? propos de Re: Lettre à Monsieur Doucet, Nicolas George ?crivait dans fr.comp.os.linux.debats :
debug this fifo , dans le message <hj6d2n$39g$, a écrit :
<foo> omg, j'ai un fichier PAGEFILE.SYS de 6100 Mo dans C: <bar> ça sert à rien, efface !
ls -lh /proc/kcore
cauchy:[/proc] > ls -lh /proc/kcore -r-------- 1 root root 128T janv. 20 10:46 /proc/kcore cauchy:[/proc] > uname -a Linux cauchy 2.6.32 #1 SMP PREEMPT Fri Dec 4 17:16:15 CET 2009 x86_64 GNU/Linux
Réponse particulièrement bugguée pour une machine avec 12 Go de mémoire...
JKB
-- Le cerveau, c'est un véritable scandale écologique. Il représente 2% de notre masse corporelle, mais disperse à lui seul 25% de l'énergie que nous consommons tous les jours.
Le 20-01-2010, ? propos de
Re: Lettre à Monsieur Doucet,
Nicolas George ?crivait dans fr.comp.os.linux.debats :
debug this fifo , dans le message <hj6d2n$39g$1@speranza.aioe.org>, a
écrit :
<foo> omg, j'ai un fichier PAGEFILE.SYS de 6100 Mo dans C:
<bar> ça sert à rien, efface !
ls -lh /proc/kcore
cauchy:[/proc] > ls -lh /proc/kcore
-r-------- 1 root root 128T janv. 20 10:46 /proc/kcore
cauchy:[/proc] > uname -a
Linux cauchy 2.6.32 #1 SMP PREEMPT Fri Dec 4 17:16:15 CET 2009 x86_64 GNU/Linux
Réponse particulièrement bugguée pour une machine avec 12 Go de
mémoire...
JKB
--
Le cerveau, c'est un véritable scandale écologique. Il représente 2% de notre
masse corporelle, mais disperse à lui seul 25% de l'énergie que nous
consommons tous les jours.
Le 20-01-2010, ? propos de Re: Lettre à Monsieur Doucet, Nicolas George ?crivait dans fr.comp.os.linux.debats :
debug this fifo , dans le message <hj6d2n$39g$, a écrit :
<foo> omg, j'ai un fichier PAGEFILE.SYS de 6100 Mo dans C: <bar> ça sert à rien, efface !
ls -lh /proc/kcore
cauchy:[/proc] > ls -lh /proc/kcore -r-------- 1 root root 128T janv. 20 10:46 /proc/kcore cauchy:[/proc] > uname -a Linux cauchy 2.6.32 #1 SMP PREEMPT Fri Dec 4 17:16:15 CET 2009 x86_64 GNU/Linux
Réponse particulièrement bugguée pour une machine avec 12 Go de mémoire...
JKB
-- Le cerveau, c'est un véritable scandale écologique. Il représente 2% de notre masse corporelle, mais disperse à lui seul 25% de l'énergie que nous consommons tous les jours.
remy
Nicolas George a écrit :
Michel Talon, dans le message <hj6hea$2i4a$, a écrit :
Fragmenter c'est en théorie toujours couteux en temps
Pas tout à fait : c'est coûteux quand il y a un temps d'accès imp ortant par rapport au temps de lecture séquentielle, en particulier quand il y a un mouvement mécanique. Fragmenter sur un SSD, on s'en contrefout.
sauf pour l'écriture na :-)
-- http://remyaumeunier.chez-alice.fr/
Nicolas George a écrit :
Michel Talon, dans le message <hj6hea$2i4a$1@asmodee.lpthe.jussieu.fr>,
a écrit :
Fragmenter c'est en théorie toujours couteux en temps
Pas tout à fait : c'est coûteux quand il y a un temps d'accès imp ortant par
rapport au temps de lecture séquentielle, en particulier quand il y a un
mouvement mécanique. Fragmenter sur un SSD, on s'en contrefout.
Michel Talon, dans le message <hj6hea$2i4a$, a écrit :
Fragmenter c'est en théorie toujours couteux en temps
Pas tout à fait : c'est coûteux quand il y a un temps d'accès imp ortant par rapport au temps de lecture séquentielle, en particulier quand il y a un mouvement mécanique. Fragmenter sur un SSD, on s'en contrefout.
sauf pour l'écriture na :-)
-- http://remyaumeunier.chez-alice.fr/
talon
Yliur wrote:
Hum... Quand tu parles de "système FAT", tu veux dire "la gestion de la FAT par Windows", c'est ça ? J'imagine qu'on peut gérer de différentes manières un système en FAT (l'emplacement des fichiers notamment).
Par FAT j'entends le système de fichiers original de Microsoft, celui qui utilise une "file access table". Le noubveau, ntfs est beaucoup plus performant, mais on dit que son comportement vis à vis de la fragmentation n'est pas encore formidable.
Es-tu sûr que Windows "essaye de loger des fichiers non fragmentés le plus possible" ? Il me semble que quand tu as un disque pas tellement
A ma connaissance, si tu écris un fichier de 2M, puis un de 3M puis un de 1.5M il te les met à la file, si ensuite tu effaces celui de 3M, un trou se forme. Si maintenant tu veux écrire 4M il te les met à la suite, mais si c'est 2M il le met dans le trou, laissant un trou de 1M. petit à petit le disque se remplit de trous de plus en plus petits, dans lesquels on ne peut plus rien loger sans fragmenter.
plein il est rapidement fragmenté, alors qu'il devrait rester de la place pour un fichier d'un peu n'importe quelle taille. Et il me semble que dans Defrag tu te retrouves vite avec des bouts un peu partout, même peu de temps après une défragmentation et avec un disque pas trop rempli.
C'est normal puisqu'il reste moins de place libre qu'au départ, et en plus il y a des fichiers non "délocalisables" par defrag, donc les possiblités de loger des gros fichiers de façon contigue sont rapidement épuisées. Les créateurs du système de fichier de Unix (UFS) étaient très conscients de ces problèmes et ils ont imaginé un système acceptant la fragmentation dès le début, mais avec des mesures pour en limiter les effets. Par exemple le fait de décomposer les fichiers en blocs de taille fixe, et en ne créant que des trous de taille multiple de celle du bloc. Ca évite la formation d'une poussière de trous minuscules. Ils ont aussi inventé les "groupes de cylindre" de façon à essayer de localiser proches les uns des autres les blocs de fichiers qui sont logiquement proches (dans le même directory) de façon à minimiser les mouvements de têtes, et beaucoup d'autres optimisations que je ne connais pas. Le résultat est qu'on obtient un débit en entrées sorties inférieur au débit théorique maximal pour des accès contigus, mais qui ne tombent pas dans la catastrophe d'un système complètement fragmenté et inutilisable. Toutes ces stratégies étaient parfaitement connues il y a très longtemps, je crois qu'on en parle dans le livre de Knuth, bien avant la fondation de Microsoft, les fabricants de mainframes y avaient été confrontés. Ce qui est ahurissant et est un témoignage à la merdicité phénoménale de Microsoft, c'est qu'ils n'ont tenu aucun compte de l'état de l'art et sont tombés dans le panneau le plus grossier.
--
Michel TALON
Yliur <yliur@free.fr> wrote:
Hum... Quand tu parles de "système FAT", tu veux dire "la gestion de
la FAT par Windows", c'est ça ? J'imagine qu'on peut gérer de
différentes manières un système en FAT (l'emplacement des fichiers
notamment).
Par FAT j'entends le système de fichiers original de Microsoft, celui qui
utilise une "file access table". Le noubveau, ntfs est beaucoup plus
performant, mais on dit que son comportement vis à vis de la
fragmentation n'est pas encore formidable.
Es-tu sûr que Windows "essaye de loger des fichiers non fragmentés le
plus possible" ? Il me semble que quand tu as un disque pas tellement
A ma connaissance, si tu écris un fichier de 2M, puis un de 3M puis un
de 1.5M il te les met à la file, si ensuite tu effaces celui de 3M, un
trou se forme. Si maintenant tu veux écrire 4M il te les met à la suite,
mais si c'est 2M il le met dans le trou, laissant un trou de 1M. petit à
petit le disque se remplit de trous de plus en plus petits, dans
lesquels on ne peut plus rien loger sans fragmenter.
plein il est rapidement fragmenté, alors qu'il devrait rester de la
place pour un fichier d'un peu n'importe quelle taille. Et il me
semble que dans Defrag tu te retrouves vite avec des bouts un peu
partout, même peu de temps après une défragmentation et avec un
disque pas trop rempli.
C'est normal puisqu'il reste moins de place libre qu'au départ, et en
plus il y a des fichiers non "délocalisables" par defrag, donc les
possiblités de loger des gros fichiers de façon contigue sont rapidement
épuisées. Les créateurs du système de fichier de Unix (UFS) étaient très
conscients de ces problèmes et ils ont imaginé un système acceptant la
fragmentation dès le début, mais avec des mesures pour en limiter les
effets. Par exemple le fait de décomposer les fichiers en blocs de
taille fixe, et en ne créant que des trous de taille multiple de celle
du bloc. Ca évite la formation d'une poussière de trous minuscules.
Ils ont aussi inventé les "groupes de cylindre" de façon à essayer de
localiser proches les uns des autres les blocs de fichiers qui sont
logiquement proches (dans le même directory) de façon à minimiser les
mouvements de têtes, et beaucoup d'autres optimisations que je ne
connais pas. Le résultat est qu'on obtient un débit en entrées sorties
inférieur au débit théorique maximal pour des accès contigus, mais qui
ne tombent pas dans la catastrophe d'un système complètement fragmenté
et inutilisable. Toutes ces stratégies étaient parfaitement connues il y
a très longtemps, je crois qu'on en parle dans le livre de Knuth, bien
avant la fondation de Microsoft, les fabricants de mainframes y avaient
été confrontés. Ce qui est ahurissant et est un témoignage à la
merdicité phénoménale de Microsoft, c'est qu'ils n'ont tenu aucun compte
de l'état de l'art et sont tombés dans le panneau le plus grossier.
Hum... Quand tu parles de "système FAT", tu veux dire "la gestion de la FAT par Windows", c'est ça ? J'imagine qu'on peut gérer de différentes manières un système en FAT (l'emplacement des fichiers notamment).
Par FAT j'entends le système de fichiers original de Microsoft, celui qui utilise une "file access table". Le noubveau, ntfs est beaucoup plus performant, mais on dit que son comportement vis à vis de la fragmentation n'est pas encore formidable.
Es-tu sûr que Windows "essaye de loger des fichiers non fragmentés le plus possible" ? Il me semble que quand tu as un disque pas tellement
A ma connaissance, si tu écris un fichier de 2M, puis un de 3M puis un de 1.5M il te les met à la file, si ensuite tu effaces celui de 3M, un trou se forme. Si maintenant tu veux écrire 4M il te les met à la suite, mais si c'est 2M il le met dans le trou, laissant un trou de 1M. petit à petit le disque se remplit de trous de plus en plus petits, dans lesquels on ne peut plus rien loger sans fragmenter.
plein il est rapidement fragmenté, alors qu'il devrait rester de la place pour un fichier d'un peu n'importe quelle taille. Et il me semble que dans Defrag tu te retrouves vite avec des bouts un peu partout, même peu de temps après une défragmentation et avec un disque pas trop rempli.
C'est normal puisqu'il reste moins de place libre qu'au départ, et en plus il y a des fichiers non "délocalisables" par defrag, donc les possiblités de loger des gros fichiers de façon contigue sont rapidement épuisées. Les créateurs du système de fichier de Unix (UFS) étaient très conscients de ces problèmes et ils ont imaginé un système acceptant la fragmentation dès le début, mais avec des mesures pour en limiter les effets. Par exemple le fait de décomposer les fichiers en blocs de taille fixe, et en ne créant que des trous de taille multiple de celle du bloc. Ca évite la formation d'une poussière de trous minuscules. Ils ont aussi inventé les "groupes de cylindre" de façon à essayer de localiser proches les uns des autres les blocs de fichiers qui sont logiquement proches (dans le même directory) de façon à minimiser les mouvements de têtes, et beaucoup d'autres optimisations que je ne connais pas. Le résultat est qu'on obtient un débit en entrées sorties inférieur au débit théorique maximal pour des accès contigus, mais qui ne tombent pas dans la catastrophe d'un système complètement fragmenté et inutilisable. Toutes ces stratégies étaient parfaitement connues il y a très longtemps, je crois qu'on en parle dans le livre de Knuth, bien avant la fondation de Microsoft, les fabricants de mainframes y avaient été confrontés. Ce qui est ahurissant et est un témoignage à la merdicité phénoménale de Microsoft, c'est qu'ils n'ont tenu aucun compte de l'état de l'art et sont tombés dans le panneau le plus grossier.
--
Michel TALON
talon
Nicolas George <nicolas$ wrote:
Michel Talon, dans le message <hj6hea$2i4a$, a écrit : > Fragmenter c'est en théorie toujours couteux en temps
Pas tout à fait : c'est coûteux quand il y a un temps d'accès important par rapport au temps de lecture séquentielle, en particulier quand il y a un mouvement mécanique. Fragmenter sur un SSD, on s'en contrefout.
Absolument, d'ailleurs les principes d'un système de fichiers sur SSD sont radicalement différents, ici ce qu'il faut au contraire favoriser, c'est d'écrire le plus uniformément partout, et surtout d'éviter à tout prix d'écrire répétitivement au même endroit, ce qui bouzille le disque. Ce qui fait que les fichiers à base de log continu sont ici plus favorables (style LFS).
--
Michel TALON
Nicolas George <nicolas$george@salle-s.org> wrote:
Michel Talon, dans le message <hj6hea$2i4a$1@asmodee.lpthe.jussieu.fr>,
a écrit :
> Fragmenter c'est en théorie toujours couteux en temps
Pas tout à fait : c'est coûteux quand il y a un temps d'accès important par
rapport au temps de lecture séquentielle, en particulier quand il y a un
mouvement mécanique. Fragmenter sur un SSD, on s'en contrefout.
Absolument, d'ailleurs les principes d'un système de fichiers sur SSD
sont radicalement différents, ici ce qu'il faut au contraire favoriser,
c'est d'écrire le plus uniformément partout, et surtout d'éviter à tout
prix d'écrire répétitivement au même endroit, ce qui bouzille le disque.
Ce qui fait que les fichiers à base de log continu sont ici plus
favorables (style LFS).
Michel Talon, dans le message <hj6hea$2i4a$, a écrit : > Fragmenter c'est en théorie toujours couteux en temps
Pas tout à fait : c'est coûteux quand il y a un temps d'accès important par rapport au temps de lecture séquentielle, en particulier quand il y a un mouvement mécanique. Fragmenter sur un SSD, on s'en contrefout.
Absolument, d'ailleurs les principes d'un système de fichiers sur SSD sont radicalement différents, ici ce qu'il faut au contraire favoriser, c'est d'écrire le plus uniformément partout, et surtout d'éviter à tout prix d'écrire répétitivement au même endroit, ce qui bouzille le disque. Ce qui fait que les fichiers à base de log continu sont ici plus favorables (style LFS).
--
Michel TALON
remy
Michel Talon a écrit :
Nicolas George <nicolas$ wrote:
Michel Talon, dans le message <hj6hea$2i4a$ , a écrit :
Fragmenter c'est en théorie toujours couteux en temps
Pas tout à fait : c'est coûteux quand il y a un temps d'accès im portant par rapport au temps de lecture séquentielle, en particulier quand il y a un mouvement mécanique. Fragmenter sur un SSD, on s'en contrefout.
Absolument, d'ailleurs les principes d'un système de fichiers sur SSD sont radicalement différents, ici ce qu'il faut au contraire favorise r, c'est d'écrire le plus uniformément partout, et surtout d'éviter à tout prix d'écrire répétitivement au même endroit, ce qui bouzille l e disque. Ce qui fait que les fichiers à base de log continu sont ici plus favorables (style LFS).
certainement pas, on ne peut pas modifier un octet tout seul sur une flash, en gros je lis un bloc, la taille varie en fonction des tailles voir données constructeur, je mets le bloc en ram, je modifie la donnée et on réécrit tout le bloc
donc en lecture effectivement l'on sent fout mais en écriture pas du tout dit différemment cette différence est une pure vue de l'esprit
donc en général l'on a une zone donnée qui change swap ram -flash et une zone donnée qui ne change pas ou très peu
remy
-- http://remyaumeunier.chez-alice.fr/
Michel Talon a écrit :
Nicolas George <nicolas$george@salle-s.org> wrote:
Michel Talon, dans le message <hj6hea$2i4a$1@asmodee.lpthe.jussieu.fr> ,
a écrit :
Fragmenter c'est en théorie toujours couteux en temps
Pas tout à fait : c'est coûteux quand il y a un temps d'accès im portant par
rapport au temps de lecture séquentielle, en particulier quand il y a un
mouvement mécanique. Fragmenter sur un SSD, on s'en contrefout.
Absolument, d'ailleurs les principes d'un système de fichiers sur SSD
sont radicalement différents, ici ce qu'il faut au contraire favorise r,
c'est d'écrire le plus uniformément partout, et surtout d'éviter à tout
prix d'écrire répétitivement au même endroit, ce qui bouzille l e disque.
Ce qui fait que les fichiers à base de log continu sont ici plus
favorables (style LFS).
certainement pas, on ne peut pas modifier un octet tout seul sur une
flash, en gros je lis un bloc, la taille varie en fonction des tailles
voir données constructeur, je mets le bloc en ram, je modifie la
donnée et on réécrit tout le
bloc
donc en lecture effectivement l'on sent fout mais en écriture pas du
tout dit différemment cette différence est une pure vue de l'esprit
donc en général l'on a une zone donnée qui change swap ram -flash
et une zone donnée qui ne change pas ou très peu
Michel Talon, dans le message <hj6hea$2i4a$ , a écrit :
Fragmenter c'est en théorie toujours couteux en temps
Pas tout à fait : c'est coûteux quand il y a un temps d'accès im portant par rapport au temps de lecture séquentielle, en particulier quand il y a un mouvement mécanique. Fragmenter sur un SSD, on s'en contrefout.
Absolument, d'ailleurs les principes d'un système de fichiers sur SSD sont radicalement différents, ici ce qu'il faut au contraire favorise r, c'est d'écrire le plus uniformément partout, et surtout d'éviter à tout prix d'écrire répétitivement au même endroit, ce qui bouzille l e disque. Ce qui fait que les fichiers à base de log continu sont ici plus favorables (style LFS).
certainement pas, on ne peut pas modifier un octet tout seul sur une flash, en gros je lis un bloc, la taille varie en fonction des tailles voir données constructeur, je mets le bloc en ram, je modifie la donnée et on réécrit tout le bloc
donc en lecture effectivement l'on sent fout mais en écriture pas du tout dit différemment cette différence est une pure vue de l'esprit
donc en général l'on a une zone donnée qui change swap ram -flash et une zone donnée qui ne change pas ou très peu
remy
-- http://remyaumeunier.chez-alice.fr/
yjml
In article <4b56569e$0$28677$, NiKo writes:
dans les technos mécaniques qu'on utilise aujourd'hui, c'est le déplacement des têtes qui est le plus couteux en temps.
Combien de têtes sur un disque dur ?
Je serais curieux que tu développes ton point de vue ...
L'intérêt est bien entendu de diminuer les temps d'accès et donc d'aligner les «fragments» (je met des guillemets, parce qu'en effet ce n'est pas de la fragmentation mais de l'entrelacement)
-- All truth passes through three stages : First, it is ridiculed Second, it is violently opposed Third, it is accepted as being self-evident Schopenhauer
In article <4b56569e$0$28677$426a74cc@news.free.fr>,
NiKo <NiKo@nomail.svp> writes:
dans les technos mécaniques
qu'on utilise aujourd'hui, c'est le déplacement des têtes qui est le
plus couteux en temps.
Combien de têtes sur un disque dur ?
Je serais curieux que tu développes ton point de vue ...
L'intérêt est bien entendu de diminuer les temps d'accès et donc
d'aligner les «fragments» (je met des guillemets, parce qu'en effet ce
n'est pas de la fragmentation mais de l'entrelacement)
--
All truth passes through three stages :
First, it is ridiculed
Second, it is violently opposed
Third, it is accepted as being self-evident
Schopenhauer
dans les technos mécaniques qu'on utilise aujourd'hui, c'est le déplacement des têtes qui est le plus couteux en temps.
Combien de têtes sur un disque dur ?
Je serais curieux que tu développes ton point de vue ...
L'intérêt est bien entendu de diminuer les temps d'accès et donc d'aligner les «fragments» (je met des guillemets, parce qu'en effet ce n'est pas de la fragmentation mais de l'entrelacement)
-- All truth passes through three stages : First, it is ridiculed Second, it is violently opposed Third, it is accepted as being self-evident Schopenhauer
