Apple c'est des salauds de capitalistes qui kiffent le logiciel privateur et qui n'ont rien inventé depuis que Steve Wozniak est parti. N'empeche, des fois ils font des trucs intéressants, le dernier en date c'est le "fusion drive" presenté en fanfare lors de la dernière keynote (qui n'a malheureusement pas été annoncée sur LinuxFR, désolé pour ceux qui ont raté ce grand moment). Fusion drive c'est un truc un peu magique et révolutionnaire qui prend un petit SSD, genre 128Go, un grand disque dur genre 1To , et qui fusionne les deux en un gros disque de 1.1To. Ensuite le systeme s'occupe de mettre sur le SSDs les blocs les plus souvent accedés et de mettre sur le HD les autres blocs. ça n'est pas un cache puisque qu'un bloc sur le SSD n'est pas dupliqué sur le HD. On trouve plus d'informations dans le lien ci dessous , où on apprend que c'est très facile à mettre en place sur de vieux macs, et que ça n'est pas limité aux filesystem HFS+.
http://jollyjinx.tumblr.com/post/34638496292/fusion-drive-on-older-macs-yes-since-apple-has
http://jollyjinx.tumblr.com/post/34700977027/fusion-drive-loose-ends-as-hinted-in-my-last
J'aimerais bien pouvoir faire la même chose, et aussi simplement, sous linux.
# c'est en cours
Posté par Nicolas Boulay (site web personnel) . Évalué à 5.
Il y a des trucs en cours sur le sujet (bcache ?).
Pour l'instant, il est possible de mettre le journal d'un système de fichier dans une partition séparée. On peut donc la mettre dans un SSD, cela sera plus rapide qu'avec le disque seule.
"La première sécurité est la liberté"
[^] # Re: c'est en cours
Posté par GG (site web personnel) . Évalué à 5. Dernière modification le 31 octobre 2012 à 17:06.
Si c'est un journal, il sera souvent écrit, réécrit.
Perso, je placerai ailleurs les journaux, pas sur du SSD bien au contraire.
Pourquoi un journal ralentirait les accès?
Le système (sauf les logs) et les applications (sauf les logs) sur la SSD, oui, c'est pas mal.
On peut déjà le faire, ça se configure dans le /etc/fstab.
Bonne soirée
G
Pourquoi bloquer la publicité et les traqueurs : https://greboca.com/Pourquoi-bloquer-la-publicite-et-les-traqueurs.html
[^] # Re: c'est en cours
Posté par Nicolas Boulay (site web personnel) . Évalué à 2.
Si on perd le journal on s'en fout un peu. L'écriture du journal se fait toujours avant les données, donc cela permet un gain de temps de l'écrire sur un ssd d'abord. Il existe des NAS en raid soft linux qui utilise un SSD pour les metadata et aller plus vite.
"La première sécurité est la liberté"
# Pertinent
Posté par Pierre Tramonson . Évalué à 4.
Je pertinente ce journal qui est (pour une fois dans tes journaux) en lien avec Linux.
# Crash
Posté par Zenitram (site web personnel) . Évalué à 10. Dernière modification le 31 octobre 2012 à 17:10.
Cool, si le SSD meurt (et le SSD mourra plus tôt vu qu'il se tape tout ce qui est le plus souvent utilisé), tu perds tout (contenu du HDD compris, car il manque une partie de l'ensemble).
Bonne idée? Pas si sûr que ça… Je préfère de loin le SSD en cache seulement, question de sécurité. Vaut mieux savoir à quoi on joue quand on fait ça, ça peut être utile à certains, mais il faut être conscient que ce gain de 10% de volume augmente pas mal le risque de défaillance.
[^] # Re: Crash
Posté par tuxicoman (site web personnel) . Évalué à 6.
De toute façon, si tu n'as pas de sauvegarde de ton disque ailleurs, t'es déjà mal barré puisque le HDD meurs tôt ou tard aussi.
[^] # Re: Crash
Posté par galactikboulay . Évalué à 10.
Certes il faut faire des backups quoiqu'il arrive, mais statistiquement, avec une dépendance sur 2 disques, le crash va arriver beaucoup plus vite.
[^] # Re: Crash
Posté par vincent LECOQ (site web personnel) . Évalué à 9.
non, tu ne perdra pas tout, juste ce que tu utilise sle plus souvent ! c'est moins inquiétant non ?
ok ----> []
# C'est tout à fait faisable
Posté par arapaho . Évalué à 10.
J'aimerais bien pouvoir faire la même chose, et aussi simplement, sous linux.
Disons que tu pourrais essayer cela: https://bbs.archlinux.org/viewtopic.php?id=113529
LVMTS
[^] # Re: C'est tout à fait faisable
Posté par Tobu . Évalué à 0.
Un autre petit nouveau: TIER (bon c'est sur sourceforge).
C'est un module noyau (qui se branche dans device-mapper), il s'installe facilement mais faites vos backups.
# je suis contre
Posté par Anonyme . Évalué à 3.
par exemple pour une video, peut importe la vitesse d'acces elle sera lu de manière séquentielle, les mp3 pareil, un peu inutile a placer sur SSD
il y a des choses a mettre sur SSD et d'autre sur le disque dur. Genre pour linux tu mets le system complet sur ssd, il te reste 120Go pour ton home, tu attache la partition de 1To a la corbeille, comme cela ce qui n'est pas utilisé est sur le disque dur, et ce que tu utilise est sur le ssd.
Blague a part, j'ai mis /usr sur SSD est c'est vraiment pas mal.
[^] # Re: je suis contre
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 10.
Moi je me contente de / sur SSD et /home sur disque dur. Mon système démarre vite, mes logiciels se lancent vite, et mes documents les plus gros, à savoir des flims, se chargent à une vitesse suffisante pour les lire, une vitesse supérieure n'apportant rien de plus.
[^] # Re: je suis contre
Posté par Nicolas Boulay (site web personnel) . Évalué à 8.
J'ai juste /home/moi/Documents/ qui est sur un HD. Cela permet d'avoir tous les "/home/moi/.*" sur SSD.
"La première sécurité est la liberté"
[^] # Re: je suis contre
Posté par palkeo (site web personnel) . Évalué à 5.
Moi j'ai /home/moi/Musiques, /home/moi/Films… qui sont des liens symboliques vers /mnt/documents/ (là ou est monté le disque dur). Le reste est sur le SSD.
Sachant qu'en plus le disque dur s'éteint automatiquement quand il n'est pas utilisé pendant quelques minutes, je bénéficie même d'un silence absolu de mon PC quand je ne lis pas de musique. Et ça c'est cool (et sur batterie, ça fait tenir mon pc plus longtemps).
Mais bon, avoir les blocs les plus utilisés sur le SSD, ou un cache automatique dessus, je pense que ça peut intéresser beaucoup de monde quand même.
[^] # Re: je suis contre
Posté par hugoL . Évalué à 1.
C'est aussi la solution que j'aimerai adopter.
Pour un portable il faut soit 2 baies 2,5'' ce qui n'est pas très courant et réservé a des poids lourds (a noter les portables clevo/ldlc sans OS en 15"). Soit une baie normale et un port msata pour mettre un ssd. Et la, en 2012 c'est la croix et la bannière. Ou bien on trouve des ultraportables avec un ssd moisi de 24G soudé, ou bien des constructeurs qui sont censé proposer l'option msata mais dans la réalité c'est mission impossible…
Par exemple les portables qui figure sur cette liste. J'en ai trouvé aucun en Europe qui supporte le msata…
Donc j'aimerai bien savoir la configuration que tu as.
[^] # Re: je suis contre
Posté par palkeo (site web personnel) . Évalué à 2.
Perso, j'ai un Clevo 15''. Je n'ai pas de port msata, et qu'une seule baie pour mettre un disque dur.
L'astuce, qui fonctionne avec à peu près tous les PC portables, c'est qu'ils ont un lecteur CD.
Et dans mon cas, je n'utilise jamais de CD, donc j'ai pu acheter sur Ebay une baie qui vient remplacer le lecteur CD et peut contenir un second disque dur.
[^] # Re: je suis contre
Posté par Prodejeu . Évalué à 2.
J'ai fais ça récemment aussi et j'en suis plutôt content.
le 1er gain c'est le temps de démarrage.
Ensuite les applis démarrent plus vite.
# Fiabilité du bousin
Posté par Olivier Borowski (site web personnel) . Évalué à 6.
Personnellement je serais plus rassuré avec des données redondantes et que le SSD reste un simple cache.
Là, que va t il se passer si un des disques n'est pas branché ? s'il tombe en panne ? …
Chez apple ils peuvent se le permettre vu que tout marche bien tant qu'on garde une configuration standard (ex : bootcamp). Mais comme les linuxiens ont tendance à sortir des clous, je crois pas trop en un tel système.
[^] # Re: Fiabilité du bousin
Posté par palkeo (site web personnel) . Évalué à -1.
Le problème avec cette méthode c'est que tu as un débit en écriture limité par la vitesse du disque le plus lent.
Et puis bon, si on suit ton raisonnement, le RAID 0 ne sert à rien puisque si un disque tombe en panne on perd tout.
[^] # Re: Fiabilité du bousin
Posté par Zenitram (site web personnel) . Évalué à 4.
On fait du RAID 0 en connaissance de cause (du risque) généralement. Ici, il faut bien faire attention d'être conscient que le risque est identique au RAID 0, voir supérieur (un disque est plus utilisé que l'autre)
# Révolutionnaire.... ?
Posté par galactikboulay . Évalué à 10.
Ce genre de fonctionnalité ça s'appelle du automated disk tiering, et ça existe depuis un moment.
Mais bon, c'est Apple, donc c'est forcément révolutionnaire…
Oups, je crois que j'ai sauté dedans à pieds joints ;)
[^] # Re: Révolutionnaire.... ?
Posté par Atem18 (site web personnel) . Évalué à 2.
En effet, j'ai été rechercher cette technologie, et d'après ce que j'en ais compris, Apple n'a fait que reprendre cette technologie et lui donner un "nom qui sonne bien". Mais bon, c'est pas la première fois qu'ils font ça, on commence à être habitués…
[^] # Re: Révolutionnaire.... ?
Posté par tuxicoman (site web personnel) . Évalué à 6.
Peut être que ce qui est révolutionnaire c'est de le rendre accessible à la masse.
[^] # Re: Révolutionnaire.... ?
Posté par Grunt . Évalué à 9.
Oui, avant il fallait configurer sa machine, chose impossible pour la masse (il est impossible, et dangereux, que la masse comprenne ce qu'elle utilise).
Apple le rend accessible au bon peuple ignorant et vivant à crédit, contre une poignée de brouzoufs.
THIS IS JUST A PLACEHOLDER. YOU SHOULD NEVER SEE THIS STRING.
[^] # Re: Révolutionnaire.... ?
Posté par liberforce (site web personnel) . Évalué à 10.
Vouloir utiliser sa machine simplement sans être informaticien n'est pas un délit que je sache… J'imagine qu'il y a 10 ans des gars ont dû dire "quoi, les gens veulent utiliser Linux sans recompiler leur kernel ? Au bûcher !"
[^] # Re: Révolutionnaire.... ?
Posté par ZeroHeure . Évalué à 5.
C'était il y a plus de 10 ans mais tu ne crois pas si bien dire. Recompiler son kernel c'était normal.
Linux a du se fendre d'une interview et dire qu'il utilisait Redhat sur sa machine de bureau pour ne plus avoir à recompiler le kernel, vu que Redhat fournissait des mises à jour régulières et un kernel très bien foutu. C'était vers la fin du 20e siècle je crois.
"La liberté est à l'homme ce que les ailes sont à l'oiseau" Jean-Pierre Rosnay
[^] # Re: Révolutionnaire.... ?
Posté par kowalsky . Évalué à 10.
Il est cool ce Linux, c'est pas un BSD qui donnerait des interviews…
[^] # Re: Révolutionnaire.... ?
Posté par 2PetitsVerres . Évalué à 10. Dernière modification le 31 octobre 2012 à 18:23.
Ouais enfin avec un câble avec une pince crocodile aux deux bouts, je peux rendre n'importe quoi ou presque accessible à la masse.
Tous les nombres premiers sont impairs, sauf un. Tous les nombres premiers sont impairs, sauf deux.
[^] # Re: Révolutionnaire.... ?
Posté par Kaane . Évalué à 5.
Apple n'a fait que reprendre cette technologie et lui donner un "nom qui sonne bien"
Euh non. Ils n'ont fait que reprendre le nom aussi…
http://www.fusionio.com/products/
(Ah au fait la tehcno marche du feu de dieu, mais pas sur le HFS+ implémenté par défaut sur mac - le commit/sync super retardé d'apple bouffe les perfs. Sinon sous Linux ca fait huit ans que je m'en sers (bon OK c'était pas vraiment une offre grand public (Et bon sang arrétez de marcher dans les trolls Apple de NedFlanders - ça l'encourage ( N.B : le stage de désintoxication du LISP a échoué, encore…))))
[^] # Re: Révolutionnaire.... ?
Posté par Spack . Évalué à 2.
[^] # Re: Révolutionnaire.... ?
Posté par Prodejeu . Évalué à 2.
Avec les 2 pieds ça porte bonheur quand même ?
[^] # Re: Révolutionnaire.... ?
Posté par reno . Évalué à 1.
Ca existe depuis un certain sur des gros serveurs de fichier ok, mais sur des poste clients?
[^] # Re: Révolutionnaire.... ?
Posté par galactikboulay . Évalué à 8.
Appliquer un concept connu (et encore, ici, c'est un cas de figure particulier assez simple) sur du matériel grand public et l'enrober d'une interface, c'est intéressant, certes. Qualifier ça de révolutionnaire ou d'innovant, faut pas pousser non plus.
[^] # Re: Révolutionnaire.... ?
Posté par oinkoink_daotter . Évalué à 6.
Tu as perdu ton âme d'enfant :-(
# "hot data tracking" dans le noyau 3.8
Posté par AP . Évalué à 10. Dernière modification le 31 octobre 2012 à 17:39.
Les développeurs de btrfs travaillent à l'implémentation dans le noyau d'une méthode générique (comprendre : applicable à tout type de système de fichiers, pas seulement btrfs) pour le suivi des fichiers les plus fréquemment accédés… une finalité possible étant de faire migrer ces derniers vers les supports de stockage présentant la latence la plus faible (comme le font déjà ZFS ou bcache). Cette nouveauté pourrait voir le jour dans le noyau 3.8.
Pour plus d'infos, utilisez "hot data tracking" comme mots clés dans votre moteur de recherche favori.
# On avait déjà tmpfs
Posté par Megaton . Évalué à 2.
tmpfs a pas mal de potentiel dans le genre, c'est moins cher, c'est rapide.
Il faut juste contourner le problème de la volatilité des données, mais ça demande tout de même un peu de savoir faire et de pratique.
[^] # Re: On avait déjà tmpfs
Posté par Marotte ⛧ . Évalué à 3.
Perso je mets presque systématiquement /var/lock et /var/run en tmpfs, l'espace occupé, chez moi, est toujours négligeable par rapport à la RAM dispo.
Je me demande dans quels cas ces répertoires pourraient saturer la RAM ?
[^] # Re: On avait déjà tmpfs
Posté par claudex . Évalué à 5.
Je me pose la question inverse. Est-ce que ça apporte quelque chose de les mettre en RAM ? Il ne me semble pas que les accès disque sur ces répertoires soient important.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.