5) Un Live USB "BartPE" ou "WinXPE" comme celui-ci :
Ce qu'il faut faire ==> Sous le "Windows XP" installé sur le Disque de l'ASUS EEE :
1) Formatter la Clé USB ou la Carte SDHC avec l'utilitaire "Hp Format USB" d'après l'écran qui suit :
Pour les rendre "Bootable".
2) Transformer la Clé USB ou la Carte SDHC en "Disque Fixe" au lieu de "Amovible" grace au MicroDriver Hitachi" téléchargé plus haut. Pour ce, il suffit de faire la mise à jour à partir du Gestionnaire de Périphérique. Voir le premier lien pour plus de détail.
Ce qu'il faut faire ==> Sous le live USB "BartPE" ou "Windows XPE" :
1) "Booter" avec un Live USB "BartPE" ou "WinXPE" (plus facile à utiliser).
2) Rendre visible tous les Fichiers Système et Cachés par "Outils", "Options des Dossiers", "Affichage"
3) Copier tous les Fichiers et Répertoires sur la Clé USB ou la Carte SSD, sauf "System Volume Information"
Pourquoi on n'a pas fait ça sous "Windows XP" ==> Parce que celui-ci empêche de copier certains Fichiers, en particulier, ceux de la Base de Registre.
4) "Rebooter" la Machine et appuyer sur <F2> pour donner la Priorité du "Boot" à votre Clé USB ou la Carte SDHC.
5) Tester et donnez-moi votre Avis.
Pour des Raisons de rapidité, je vous conseille les Clés "Corsair Flash Voyager GT" (j'ai bien dit "GT") ou "OCZ Rally2 Turbo (j'ai bien dit "Turbo"). Ce sont les Clés les plus Rapides du Marché.
Cette méthode à l'avantage par rapport à celle utilisant le Clonage par "WinHex", de ne pas être tributaire de la taille du Disque Fixe installé sur l'ASUS EEE PC. En effet, la Méthode par Clonage fixe la taille de la Partition à celle de la Source du clonage. En effet, par ma méthode, vous pouvez avoir la Partition Destinataire de la taille que vous voulez.
Pour ceux qui ont déjà crée une Image ".Tib" (True Image), je vous ferais un Tuto pour vous montrer comment on peut créer une Clé USB ou Carte SDHC "Bootable" avec "True Image 11 Fr" et en utilisant les "Images .Tib".
c'est un peu compliqué pour moi. je voudrais faire un essai avec un lecteur de SD card branché sur le port USB et pouvoir changer la carte SD (différentes capacités) et pourvoir utiliser ce disque sur 2 machines alternativement.
16 go parce que c'est une capacité confortable pour installer windows et nos applis pour un usage typique.
Mais est-ce vraiment une bonne idée? On l'a vu avec les compact flash. Trop d'écritures sur un flash drive tue celui-ci en quelques mois ou semaines. C'est pour ça qu'on ne recommande pas d'y installer un fichier d'échange et qu'on désactive le système de restauration de windows.
Il faut réduire au minimum les cycles d'écritures pour préserver la durée de vie du support.
Je suppose qu'il en est de même pour tous les supports flash.
16 go parce que c'est une capacité confortable pour installer windows et nos applis pour un usage typique.
Mais est-ce vraiment une bonne idée? On l'a vu avec les compact flash. Trop d'écritures sur un flash drive tue celui-ci en quelques mois ou semaines. C'est pour ça qu'on ne recommande pas d'y installer un fichier d'échange et qu'on désactive le système de restauration de windows.
Il faut réduire au minimum les cycles d'écritures pour préserver la durée de vie du support.
Je suppose qu'il en est de même pour tous les supports flash.
shenron666 30/04/2007, 20h26 histoire d'avoir un aperçu plus compréhensible de la durée de vie d'une carte CF je vous propose un petit calcul
les meilleures cartes CF sont de type SLC et leur durée de vie est estimée par leur constructeur à 100 000 cycles d'effacement / écriture (les cartes autres que SLC sont à proscrire, vitesse exécrable et/ou durée de vie de quelques 1000 cycles seulement, comme les clefs usb noname)
histoire d'avoir une marge d'erreur, on va dire qu'on a 10 000 cycles d'effacement / écriture sur notre carte (oui je sais c'est une grosse marge )
puisque le disque est utilisé comme disque système, on va dire qu'on écrit 1 Go par heure ça vous parait peut-etre beaucoup mais ça va vite en fait
- bon bref, 1Go par heure ça nous fait 24 x 365 = 8760 Go par an - on a une capacité de 8 Go -> 8760 / 8 = 1095 remplissages de carte - on a une durée de vie de 10 000 cycles -> 10 000 / 1095 = 9 ans
c'est déjà pas mal je trouve
Citation de katie :
est-ce que c'est valable aussi sur un pc normal?
Bien sûr, mais utilisable uniquement sur le PC où il a été installé, à cause du "ChipSet" !!! Alors que sur "ASUS Eee PC 701", il sera utilisable sur tous les "ASUS Eee PC 701" du Monde, car même "Chipset" !!! Certainement aussi sur les "ASUS Eee PC 900" !!!
tu comptes en volume de données. mais n'est ce pas le nombre d'écritures qu'il fat prendre en compte? Il me semble qu'il y a un certain nombre de cellules sur une carte. Quand une cellule est usée ou presque, la carte bascule les données d'une cellule vers une autre neuve ou peu sollicitée. Il y a un système se durveillance de l'état de la carte qui gère ça, me semble-t-il?
il serait bon en plus de la théorie, d'avoir des benchmarks sur les cycles d'effacement/écriture. mesurer les perfs ça aide mais le retour des utilisateur est essentiel pour mesurer la longévité de telles cartes en usage normal (write once read several times), système (write several, read serveral), ou intensif.
merci pour le lien Tourane.
Sinon, pour le file system, il semblerait que JFS (JFS 2) soit bien adapté au fonctionnement des mémoires flash.
The super-expensive SSDs use fast standard RAM, which can stand zillions (a technical term) of read/write cycles before it fails.
Flash memory, on the other hand, is generally rated to endure at least 100,000 erase cycles - needed to change the data in a given memory cell - before failing. Different kinds of Flash memory may have considerably different durability - I've seen one million erase cycle figures for some Flash cards.
100,000 erase cycles may add up to 300,000 or more "I/O cycles" in marketing-speak, depending on the mix of read to write operations used to test the memory.
The durability of the memory is spread right over the entire capacity of the card by the use of "logical sectors". A logical sector is whatever part of the actual physical memory to which the card controller chooses to send a sector's worth of data. Flash devices do clever load-spreading to make sure that no chunk of the storage gets used more heavily than any other part.
Now, a hundred thousand write operations sounds like a lot, but it's not for a system scratch drive. The hard drive with the swap file on it in a normal Windows box generally takes a serious read/write hammering - especially if it's the only hard drive in the system, so data's being requested from or sent to other parts of the disk even as the swap file does its thing.
There's no OS RAM cache for a swap file - the swap file's what you use when you're out of RAM; caching it is like sticking a wind turbine out of the window of a plane and expecting to gain something - so all of the I/O operation enthusiasm is delivered straight to the storage device. Which can find itself having to serve a couple of dozen I/O operations per second, easily.
Subject a device that can only survive 300,000 operations to a 24 operation per second load, and you ought to be able to kill it well inside four hours. Ten times the durability? Well, goody for you. Now your drive might last a day and a half!
Hard drives are far better at this sort of thing, and non-Flash SSDs are better again, because it's practically impossible to "thrash" a device with a seek speed down in the nanoseconds.
So that's what you can't use Flash RAM SSDs for. Given that sensibly priced CompactFlash cards have too little capacity to make them very useful for swap file purposes anyway, though, this is not too big a deal. You're only going to use them as a system device when you're running an operating system that doesn't need a crocktillion (another technical term) megabytes of space just to install itself.
Les disques SSD à base de mémoire flash sont affligés d'un défaut important puisqu'ils ne supportent qu'un nombre restreint de cycles d'écritures (typiquement de l'ordre de 100000). Pour faire face à ce problème la technique du "wear levelling" a été développée. Elle consiste schématiquement à enregistrer le nombre d'écritures pour chaque bloc mémoire et à répartir ensuite intelligemment les nouvelles données à écrire de façon à minimiser l'usure de chaque bloc. Des graphiques présentant l'évolution de l'usure d'un disque SSD avec et sans wear levelling sont disponibles sur cette page. Ce algorithme est implémenté par les constructeurs de disques SSD dans des microcontrôleurs faisant le lien entre la mémoire flash et l'interface sata. C'est certes transparent pour l'utilisateur mais cela signifie que les systèmes de fichiers traditionnels, avec toutes leurs limitations et tout leur code complexe dédié à la minimisation des temps d'accès par le bras de lecture, vont continuer à être utilisé.
Il est donc bien plus efficace de créer des systèmes de fichiers spécialement dédiés aux disques SSD et dialoguant directement avec la puce de mémoire flash sans passer par le microcontrôleur de wear levelling. Cet algorithme est ainsi implémenté directement dans le système de fichiers optimisé pour les SSD.
Tout d'abord, pourquoi la durée de vie est-elle limitée ?
Nous avons vu dans la page précédente que la mémoire flash utilisait une grille flottante placée dans un oxyde. Un des problèmes vient de l'oxyde en question, qui peut emprisonner des électrons durant les processus d'écriture. Et ces électrons piégés viendront perturber les écritures ultérieures en étant déplacé par l'effet tunnel.
Ensuite, l'oxydation de la grille flottante modifie les propriétés isolantes de celle-ci. Plus la grille sera oxydée et plus l'écriture deviendra aléatoire. Cette oxydation intervient à cause du stress des composants induits par l'effet tunnel (on utilise des tensions élevées pour programmer une cellule). Après un certain nombre de cycle, la grille sera tellement oxydée que la différence entre les états binaires sera impossible à lire. On considérera alors la cellule comme défectueuse.
Celle limite varie en fonction du type de pce : une flash NAND SLC est considérée comme capable de supporter environ 100.000 écritures. Une MLC est nettement moins endurantes : environ 10.000 cycles.
Avant de parler des technique qui permettent de limiter cette usure, parlons de ce qui existe au niveau interne.
Tout d'abord, il existe ce que les constructeurs appellent un "Erase Pool". Ce sont des blocs qui sont en réserve et prévus pour corriger les problèmes de blocs défectueux. Il y a en général entre 2 et 3% de la capacité totale disponible en "Erase Pool".
L'autre fonction, c'est une détection interne des blocs défectueux : on a vu que les pages disposaient de 64 octet de gestion. Ces 64 octets servent pour la correction ECC et pour la gestion des blocs défectueux. Si un bloc effectue des erreurs détectées par le code ECC, il est indiqué comme défectueux et les données qu'il contenait sont déplacées vers un bloc vide (généralement un des blocs de l'Erase Pool).
La première technique est d'utiliser un système de fichier adapté.
Code :
Les derniers modèles de SSD et de cartes ont un système évolué : le contrôleur gère dynamiquement l'usure des blocs. Dès qu'un bloc atteint un niveau d'usure prédéfini, les données sont déplacées sur un bloc très peu usé. ...
Avec cette technique, les constructeurs assurent que SSDs ont une durée de vie au moins équivalente à celle d'un disque dur.
Est-ce que c'est vrai avec les compact flash 266x et plus ? est-ce qu'il faut un adaptateur IDE très récent?
Last time I ran a CF card as a writable Linux disk, I used Kingstons and JFFS2 over blockmtd. Basically, I just don't trust that a CF/SD/USB/whatever memory card is going to contain sufficient wear-levelling technology, if any. Wear-levelling requires a state-aware controller in hardware, which adds cost to the device, and that cost is unnecessary for 99.9% of users, who will use the device for a digital camera, once-a-week file transfers, etc. They aren't designed for consistent FS-hammering cases. Even with "noatime", any normal *nix system is going to be ticking away on /var/log, continually updating inodes and hammering that portion of the device. Such activity could even result in 100 IOps on *one* cell, which is 360000 IOs per hour.
That said, I got pissed off by the feature regressions of block2mtd (couldn't get it to work for multiple partitions) so I reverted to XFS, mounted read-only with remote logging for that firewall machine.
A real SSD will include proper wear-levelling, because it is designed for the use-case of a standard HDD. CF cards are not.
(oui je sais c'est une grosse marge 
)