Pour la nowel je vais (me faire) offir un SSD à mon mac mini 2009.
Il ira à la place de l'ancien DD et l'ancien ira dans un caddy à la
place du graveur qui est mort depuis belle lurette.
Le budget est de maxi 100 euros.
Lequel pouvez-vous me conseiller ?
La star du moment semble être le Vertex 3 ; qu'en pensez vous ?
60 Go me semble un strict minimum pour ce que j'ai à y mettre.
(Je vous demanderais plus tard quoi mettre dessus, système, applis...)
Par ailleurs, petite note à propos de Time Machine : j'ai exclu d'office pas mal de caches
ok pour pas mal de ces suggestions ; ce qui me fait penser à un truc : est-ce que Time machine sauve le contenu de la corbeille ? ce serait un peu idiot, mais bon.... et si oui, comment empecher ça ??? -- Philippe Manet en fait, c'est manet avant @
patpro ~ patrick proniewski <patpro@boleskine.patpro.net> wrote:
Par ailleurs, petite note à propos de Time Machine : j'ai exclu d'office
pas mal de caches
ok pour pas mal de ces suggestions ; ce qui me fait penser à un truc :
est-ce que Time machine sauve le contenu de la corbeille ? ce serait un
peu idiot, mais bon....
et si oui, comment empecher ça ???
--
Philippe Manet
en fait, c'est manet avant @
Par ailleurs, petite note à propos de Time Machine : j'ai exclu d'office pas mal de caches
ok pour pas mal de ces suggestions ; ce qui me fait penser à un truc : est-ce que Time machine sauve le contenu de la corbeille ? ce serait un peu idiot, mais bon.... et si oui, comment empecher ça ??? -- Philippe Manet en fait, c'est manet avant @
yapu
patpro ~ patrick proniewski wrote:
j'ai toujours été plus FileMaker que 4D. Et si je me fie à la rumeur (de l'époque), je me suis épargné des cheveux blancs.
je suis effectivement passé avec bonheur de 4D à FMP.
Mais je pense que FMP aussi tape directement dans le disque, et que toutes les bases de données le font, sinon je ne vois pas comment ils pourraient gérer des tables de dizaines de GO. A ma connaissance, la seule chose qui monte en RAM, c'est les index (et les données traitées, évidemment). -- Philippe Manet en fait, c'est manet avant @
patpro ~ patrick proniewski <patpro@boleskine.patpro.net> wrote:
j'ai toujours été plus FileMaker que 4D. Et si je me fie à la rumeur (de
l'époque), je me suis épargné des cheveux blancs.
je suis effectivement passé avec bonheur de 4D à FMP.
Mais je pense que FMP aussi tape directement dans le disque, et que
toutes les bases de données le font, sinon je ne vois pas comment ils
pourraient gérer des tables de dizaines de GO.
A ma connaissance, la seule chose qui monte en RAM, c'est les index (et
les données traitées, évidemment).
--
Philippe Manet
en fait, c'est manet avant @
j'ai toujours été plus FileMaker que 4D. Et si je me fie à la rumeur (de l'époque), je me suis épargné des cheveux blancs.
je suis effectivement passé avec bonheur de 4D à FMP.
Mais je pense que FMP aussi tape directement dans le disque, et que toutes les bases de données le font, sinon je ne vois pas comment ils pourraient gérer des tables de dizaines de GO. A ma connaissance, la seule chose qui monte en RAM, c'est les index (et les données traitées, évidemment). -- Philippe Manet en fait, c'est manet avant @
yapu
pehache wrote:
OK, mais l'optimisation en question ce sont des algos déjà connus et utilisés dans de nombreux contextes (pour gérer cache CPU versus RAM, RAM physique versus swap, cache disque, etc...)
quand j'avais lu sur la question (il y a fort longtemps), le problème n'était pas les algo, mais leur parametrage ! Et le bon parametrage dépendait de tas de choses à la fois, qui vont de l'usage fait par l'utilisateur aux divers temps de latence et d'écriture des médias en questions, sans compter les réactions des autres caches présents dans le système et dont l'usage peut salement interférer.
Alors faire des caches, c'est certainement possible, mais les optimiser, je crois comme Patrick que c'est un boulot de spécialiste.
-- Philippe Manet en fait, c'est manet avant @
pehache <pehache.7@gmail.com> wrote:
OK, mais l'optimisation en question ce sont des algos déjà connus et
utilisés dans de nombreux contextes (pour gérer cache CPU versus RAM,
RAM physique versus swap, cache disque, etc...)
quand j'avais lu sur la question (il y a fort longtemps), le problème
n'était pas les algo, mais leur parametrage !
Et le bon parametrage dépendait de tas de choses à la fois, qui vont de
l'usage fait par l'utilisateur aux divers temps de latence et d'écriture
des médias en questions, sans compter les réactions des autres caches
présents dans le système et dont l'usage peut salement interférer.
Alors faire des caches, c'est certainement possible, mais les optimiser,
je crois comme Patrick que c'est un boulot de spécialiste.
OK, mais l'optimisation en question ce sont des algos déjà connus et utilisés dans de nombreux contextes (pour gérer cache CPU versus RAM, RAM physique versus swap, cache disque, etc...)
quand j'avais lu sur la question (il y a fort longtemps), le problème n'était pas les algo, mais leur parametrage ! Et le bon parametrage dépendait de tas de choses à la fois, qui vont de l'usage fait par l'utilisateur aux divers temps de latence et d'écriture des médias en questions, sans compter les réactions des autres caches présents dans le système et dont l'usage peut salement interférer.
Alors faire des caches, c'est certainement possible, mais les optimiser, je crois comme Patrick que c'est un boulot de spécialiste.
-- Philippe Manet en fait, c'est manet avant @
yapu
patpro ~ patrick proniewski wrote:
Cela dit, je l'ai fait, y'a longtemps, avec mon 7100 :).
à l'époque, le RAM disk était sauvé et récupéré lors du démarrage, ce qui était particulièrement interessant. Sous OSX, ça a disparu, la taille était limitée à 500 MO, et finalement je crois que c'est depuis Tiger que le script que j'utilisais ne fonctionne plus.
-- Philippe Manet en fait, c'est manet avant @
patpro ~ patrick proniewski <patpro@boleskine.patpro.net> wrote:
Cela dit, je l'ai fait, y'a longtemps, avec mon 7100 :).
à l'époque, le RAM disk était sauvé et récupéré lors du démarrage, ce
qui était particulièrement interessant.
Sous OSX, ça a disparu, la taille était limitée à 500 MO, et finalement
je crois que c'est depuis Tiger que le script que j'utilisais ne
fonctionne plus.
Cela dit, je l'ai fait, y'a longtemps, avec mon 7100 :).
à l'époque, le RAM disk était sauvé et récupéré lors du démarrage, ce qui était particulièrement interessant. Sous OSX, ça a disparu, la taille était limitée à 500 MO, et finalement je crois que c'est depuis Tiger que le script que j'utilisais ne fonctionne plus.
-- Philippe Manet en fait, c'est manet avant @
yapu
pehache wrote:
> 2- le prix de 12 go de ram sur les machines qui reste, serait bien plus > profitablement investit dans un SSD. Pour la majorité des utilisateurs, > 4 Go sont à peine utilisés, et doubler à 8 ne leur apporte strictement > aucun gain. >
Ce n'est pas tout à fait vrai : la RAM sert aussi de cache disque, donc elle est utilisé même si on a peu d'applis ouvertes.
d'abord, il faut dire de quoi on parle comme machine :
sur un G5, avec 6 Go, c'est franchement trop meme avec une utilisation très lourde et un uptime de 60 jours ; mais 4 Go c'était parfois limite.
En revanche, il me semble qu'un Intel a besoin de plus de RAM (avec 4 Go en 2 jours d'utilisation amateur j'ai déjà frolé la limite). Et je crois qu'en 64 bits c'est pire. -- Philippe Manet en fait, c'est manet avant @
pehache <pehache.7@gmail.com> wrote:
> 2- le prix de 12 go de ram sur les machines qui reste, serait bien plus
> profitablement investit dans un SSD. Pour la majorité des utilisateurs,
> 4 Go sont à peine utilisés, et doubler à 8 ne leur apporte strictement
> aucun gain.
>
Ce n'est pas tout à fait vrai : la RAM sert aussi de cache disque, donc
elle est utilisé même si on a peu d'applis ouvertes.
d'abord, il faut dire de quoi on parle comme machine :
sur un G5, avec 6 Go, c'est franchement trop meme avec une utilisation
très lourde et un uptime de 60 jours ; mais 4 Go c'était parfois limite.
En revanche, il me semble qu'un Intel a besoin de plus de RAM (avec 4 Go
en 2 jours d'utilisation amateur j'ai déjà frolé la limite).
Et je crois qu'en 64 bits c'est pire.
--
Philippe Manet
en fait, c'est manet avant @
> 2- le prix de 12 go de ram sur les machines qui reste, serait bien plus > profitablement investit dans un SSD. Pour la majorité des utilisateurs, > 4 Go sont à peine utilisés, et doubler à 8 ne leur apporte strictement > aucun gain. >
Ce n'est pas tout à fait vrai : la RAM sert aussi de cache disque, donc elle est utilisé même si on a peu d'applis ouvertes.
d'abord, il faut dire de quoi on parle comme machine :
sur un G5, avec 6 Go, c'est franchement trop meme avec une utilisation très lourde et un uptime de 60 jours ; mais 4 Go c'était parfois limite.
En revanche, il me semble qu'un Intel a besoin de plus de RAM (avec 4 Go en 2 jours d'utilisation amateur j'ai déjà frolé la limite). Et je crois qu'en 64 bits c'est pire. -- Philippe Manet en fait, c'est manet avant @
pehache
Le 05/12/11 17:53, patpro ~ patrick proniewski a écrit :
Il faudrait que je vérifie au niveau du Momentus XT, mais il n'est pas idiot de supposer que par défaut il écrit sur le cache SSD, pour flusher ensuite en background sur le disque. De la sorte, l'utilisateur ne ressent pas de latence.
Ca paraitrait logique. A ceci près quand même que cette stratégie condui(rai)t à une utilisation intensive du SSD en écriture.
-- pehache
Le 05/12/11 17:53, patpro ~ patrick proniewski a écrit :
Il faudrait que je vérifie au niveau du Momentus XT, mais il n'est pas
idiot de supposer que par défaut il écrit sur le cache SSD, pour flusher
ensuite en background sur le disque. De la sorte, l'utilisateur ne
ressent pas de latence.
Ca paraitrait logique. A ceci près quand même que cette stratégie
condui(rai)t à une utilisation intensive du SSD en écriture.
Le 05/12/11 17:53, patpro ~ patrick proniewski a écrit :
Il faudrait que je vérifie au niveau du Momentus XT, mais il n'est pas idiot de supposer que par défaut il écrit sur le cache SSD, pour flusher ensuite en background sur le disque. De la sorte, l'utilisateur ne ressent pas de latence.
Ca paraitrait logique. A ceci près quand même que cette stratégie condui(rai)t à une utilisation intensive du SSD en écriture.
-- pehache
sebastienmarty
Philippe Manet wrote:
Mais je pense que FMP aussi tape directement dans le disque, et que toutes les bases de données le font, sinon je ne vois pas comment ils pourraient gérer des tables de dizaines de GO.
Quel problème cela pourrait-il poser ?
-- [SbM] <http://sebastienmarty.free.fr> - <http://tradintosh.free.fr> <http://sbm.ordinotheque.free.fr> - <http://palmiciel.free.fr> "If the French were really intelligent, they'd speak English" (W. Sheed)
Philippe Manet <yapu@invivo.edu> wrote:
Mais je pense que FMP aussi tape directement dans le disque, et que
toutes les bases de données le font, sinon je ne vois pas comment ils
pourraient gérer des tables de dizaines de GO.
Quel problème cela pourrait-il poser ?
--
[SbM]
<http://sebastienmarty.free.fr> - <http://tradintosh.free.fr>
<http://sbm.ordinotheque.free.fr> - <http://palmiciel.free.fr>
"If the French were really intelligent, they'd speak English" (W. Sheed)
Mais je pense que FMP aussi tape directement dans le disque, et que toutes les bases de données le font, sinon je ne vois pas comment ils pourraient gérer des tables de dizaines de GO.
Quel problème cela pourrait-il poser ?
-- [SbM] <http://sebastienmarty.free.fr> - <http://tradintosh.free.fr> <http://sbm.ordinotheque.free.fr> - <http://palmiciel.free.fr> "If the French were really intelligent, they'd speak English" (W. Sheed)
sebastienmarty
Philippe Manet wrote:
Sous OSX, [...] la taille était limitée à 500 MO
Plus maintenant, en tout cas.
-- [SbM] <http://sebastienmarty.free.fr> - <http://tradintosh.free.fr> <http://sbm.ordinotheque.free.fr> - <http://palmiciel.free.fr> "If the French were really intelligent, they'd speak English" (W. Sheed)
Philippe Manet <yapu@invivo.edu> wrote:
Sous OSX, [...] la taille était limitée à 500 MO
Plus maintenant, en tout cas.
--
[SbM]
<http://sebastienmarty.free.fr> - <http://tradintosh.free.fr>
<http://sbm.ordinotheque.free.fr> - <http://palmiciel.free.fr>
"If the French were really intelligent, they'd speak English" (W. Sheed)
-- [SbM] <http://sebastienmarty.free.fr> - <http://tradintosh.free.fr> <http://sbm.ordinotheque.free.fr> - <http://palmiciel.free.fr> "If the French were really intelligent, they'd speak English" (W. Sheed)
patpro ~ patrick proniewski
In article , pehache wrote:
Le 05/12/11 17:53, patpro ~ patrick proniewski a écrit :
> > Il faudrait que je vérifie au niveau du Momentus XT, mais il n'est pas > idiot de supposer que par défaut il écrit sur le cache SSD, pour flusher > ensuite en background sur le disque. De la sorte, l'utilisateur ne > ressent pas de latence.
Ca paraitrait logique. A ceci près quand même que cette stratégie condui(rai)t à une utilisation intensive du SSD en écriture.
J'ai bien fait d'être prudent, en réalité le cache en écriture c'est pas encore pour tout de suite, mais c'est prévu dans une mise à jour du firmware. Cela dit, comme c'est de la mémoire flash SLC, sa durée de vie est supérieure à la mémoire flash des disques grand public de deux ordres de grandeur, donc il n'y a pas d'inquiétude à avoir.
Quoi qu'il en soit, si à mon sens ce disque se base sur le principe le plus rentable (ie. un gros volume à plateaux avec un cache flash et une gestion de ce cache au niveau firmware), on est quand même assez loin d'un résultat intéressant. En terme de performance il est encore comparé à d'autres disques à plateaux. Je suis incapable de dire si ce qui lui manque le plus c'est un controleur performant ou si c'est du volume de mémoire flash.
patpro
-- A vendre : KVM IP 16 ports APC http://patpro.net/blog/index.php/2008/01/12/133
In article <9k56o4FehpU2@mid.individual.net>,
pehache <pehache.7@gmail.com> wrote:
Le 05/12/11 17:53, patpro ~ patrick proniewski a écrit :
>
> Il faudrait que je vérifie au niveau du Momentus XT, mais il n'est pas
> idiot de supposer que par défaut il écrit sur le cache SSD, pour flusher
> ensuite en background sur le disque. De la sorte, l'utilisateur ne
> ressent pas de latence.
Ca paraitrait logique. A ceci près quand même que cette stratégie
condui(rai)t à une utilisation intensive du SSD en écriture.
J'ai bien fait d'être prudent, en réalité le cache en écriture c'est pas
encore pour tout de suite, mais c'est prévu dans une mise à jour du
firmware. Cela dit, comme c'est de la mémoire flash SLC, sa durée de vie
est supérieure à la mémoire flash des disques grand public de deux
ordres de grandeur, donc il n'y a pas d'inquiétude à avoir.
Quoi qu'il en soit, si à mon sens ce disque se base sur le principe le
plus rentable (ie. un gros volume à plateaux avec un cache flash et une
gestion de ce cache au niveau firmware), on est quand même assez loin
d'un résultat intéressant. En terme de performance il est encore comparé
à d'autres disques à plateaux.
Je suis incapable de dire si ce qui lui manque le plus c'est un
controleur performant ou si c'est du volume de mémoire flash.
patpro
--
A vendre : KVM IP 16 ports APC
http://patpro.net/blog/index.php/2008/01/12/133
Le 05/12/11 17:53, patpro ~ patrick proniewski a écrit :
> > Il faudrait que je vérifie au niveau du Momentus XT, mais il n'est pas > idiot de supposer que par défaut il écrit sur le cache SSD, pour flusher > ensuite en background sur le disque. De la sorte, l'utilisateur ne > ressent pas de latence.
Ca paraitrait logique. A ceci près quand même que cette stratégie condui(rai)t à une utilisation intensive du SSD en écriture.
J'ai bien fait d'être prudent, en réalité le cache en écriture c'est pas encore pour tout de suite, mais c'est prévu dans une mise à jour du firmware. Cela dit, comme c'est de la mémoire flash SLC, sa durée de vie est supérieure à la mémoire flash des disques grand public de deux ordres de grandeur, donc il n'y a pas d'inquiétude à avoir.
Quoi qu'il en soit, si à mon sens ce disque se base sur le principe le plus rentable (ie. un gros volume à plateaux avec un cache flash et une gestion de ce cache au niveau firmware), on est quand même assez loin d'un résultat intéressant. En terme de performance il est encore comparé à d'autres disques à plateaux. Je suis incapable de dire si ce qui lui manque le plus c'est un controleur performant ou si c'est du volume de mémoire flash.
patpro
-- A vendre : KVM IP 16 ports APC http://patpro.net/blog/index.php/2008/01/12/133
patpro ~ patrick proniewski
In article <1kbtrhk.10zn0qoeuti6mN%, (Philippe Manet) wrote:
patpro ~ patrick proniewski wrote:
> Par ailleurs, petite note à propos de Time Machine : j'ai exclu d'office > pas mal de caches
ok pour pas mal de ces suggestions ; ce qui me fait penser à un truc : est-ce que Time machine sauve le contenu de la corbeille ? ce serait un peu idiot, mais bon.... et si oui, comment empecher ça ???
il semble que ce n'est pas backupé.
patpro
-- A vendre : KVM IP 16 ports APC http://patpro.net/blog/index.php/2008/01/12/133
In article <1kbtrhk.10zn0qoeuti6mN%yapu@invivo.edu>,
yapu@invivo.edu (Philippe Manet) wrote:
patpro ~ patrick proniewski <patpro@boleskine.patpro.net> wrote:
> Par ailleurs, petite note à propos de Time Machine : j'ai exclu d'office
> pas mal de caches
ok pour pas mal de ces suggestions ; ce qui me fait penser à un truc :
est-ce que Time machine sauve le contenu de la corbeille ? ce serait un
peu idiot, mais bon....
et si oui, comment empecher ça ???
il semble que ce n'est pas backupé.
patpro
--
A vendre : KVM IP 16 ports APC
http://patpro.net/blog/index.php/2008/01/12/133
In article <1kbtrhk.10zn0qoeuti6mN%, (Philippe Manet) wrote:
patpro ~ patrick proniewski wrote:
> Par ailleurs, petite note à propos de Time Machine : j'ai exclu d'office > pas mal de caches
ok pour pas mal de ces suggestions ; ce qui me fait penser à un truc : est-ce que Time machine sauve le contenu de la corbeille ? ce serait un peu idiot, mais bon.... et si oui, comment empecher ça ???
il semble que ce n'est pas backupé.
patpro
-- A vendre : KVM IP 16 ports APC http://patpro.net/blog/index.php/2008/01/12/133
