Choix de système de fichiers pour GNU / Linux sur une carte SD
Je suis un système ARM intégré fonctionnant sur une carte SD. Actuellement, Debian GNU/Linux utilise ext3 comme système de fichiers. Alors que je suis sur le point de réinstaller le système, j'ai commencé à me demander si je devais passer à un système de fichiers plus convivial. J'ai entendu parler de JFFS2, YAFFS2 et LogFS, et ils semblent tous adaptés au travail. Lequel recommanderiez-vous? De plus, j'ai entendu dire qu'il y avait eu beaucoup d'améliorations d'ext4 pour mieux convenir aux disques SSD; Dois-je interpréter cela comme exécuter ext4 devrait être parfait? À quoi dois-je penser particulièrement dans ce cas?
Je suppose que l'utilisation du système est importante. Mais pour des raisons de généralité, imaginez que cela fonctionne avec les outils de bureau standard (même s’il s’agit d’un petit système basé sur ARM).
Merci pour toutes les réponses.
Modifier: Wikipedia me dit (dans une déclaration "citation nécessaire") que Les cartes mémoire flash amovibles et les clés USB ont des contrôleurs intégrés pour effectuer le nivellement d'usure et la correction des erreurs. L'utilisation d'un système de fichiers flash spécifique n'apporte donc aucun avantage . Ainsi, je penche pour rester avec un système de fichiers ext.
Excellent article sur les systèmes de fichiers flash .
La question importante à propos des systèmes de fichiers flash est la suivante: Qu'est-ce que l'usure de nivellement? Article Wikipedia . Fondamentalement, sur les disques flash, vous pouvez écrire un nombre limité de fois jusqu'à ce que le blocage devienne mauvais. Après cela, le système de fichiers (s'il n'y a pas de gestion intégrée du nivellement d'usure sur le matériel, comme dans le cas des disques SSD, doit généralement l'être) doit marquer ce bloc comme non valide et éviter de l'utiliser plus.
Les systèmes de fichiers typiques (par exemple ReiserFS, NTFS, ext3, etc.) sont conçus pour les disques durs, qui ne sont pas soumis à de telles limitations.
JFFS2
Comprend la compression et la protection élégante de mise à niveau.
YAFFS2
- Une seule chose qui fait la différence: des temps de montage courts, après avoir réussi umount.
- Implémente la propriété write once: une fois les données écrites dans un bloc, il n'est pas nécessaire de les réécrire. Ceci est important car il réduit l'usure.
LogFS
- Pas très mature, mais déjà inclus dans l'arborescence du noyau Linux.
- Prend en charge des systèmes de fichiers plus volumineux que JFFS2/YAFFS2 sans problèmes.
UBIFS
- Plus mature que LogFS
- Support de mise en cache en écriture
- Evolutivité: article . Sur les gros disques, meilleures performances qu'avec JFFS2
ext4
Si aucun pilote ou carte (par exemple, les disques SSD ne possèdent un nivellement d'usure interne, du moins généralement), l'ext4 n'est pas la meilleure idée, car il n'est pas destiné à une utilisation flash brute.
Lequel est le meilleur?
Bien sûr, cela dépend de l'utilisation et du support. D'après ce que j'ai lu sur Internet, je recommanderais UBIFS. Bon support pour les systèmes de fichiers volumineux, phase de développement mature, performances adéquates et pas de gros inconvénients.
Je faisais face au même problème et j'ai également effectué des recherches. Finalement, j'ai décidé d'y aller avec ext2.
Il semble que certaines cartes SDHC implémentent leur propre nivellement d'usure au niveau de la couche matérielle. Si vous pouvez vous procurer des cartes SDHC dotées d’une protection anti-usure.
Les systèmes de fichiers qui fournissent un nivellement d'usure peuvent interférer avec le nivellement d'usure de Flash. Il est donc difficile pour le flash de les utiliser (l'article d'IBM cité ci-dessus explique comment JFFS le fait, donc il est clair que cela ne fonctionnera pas.) avec niveau de flash WL). J'ai décidé de ne pas avoir besoin de la journalisation d'ext3 car je ne stocke pas de données critiques sur celle-ci et je sauvegarde habituellement de toute façon (cron).
J'ai également monté/tmp et/var en tant que tmpfs pour accélérer les choses. Si vous avez assez de RAM, vous devriez le faire (mais assurez-vous de faire pivoter ou de supprimer vos journaux régulièrement)
ASTUCE: montez vos cartes SD externes avec l'option "noatime"
Je ne sais pas si cela correspond au profil de votre système, mais qu'en est-il de l'utilisation d'un système de fichiers en lecture seule avec une partition en lecture-écriture (ou une clé USB pouvant être remplacée facilement)? De cette façon, vous aurez un disque rapide pour votre système d'exploitation et pourrez facilement remplacer votre stockage rw lorsqu'il sera épuisé.
Et puis il y a unionfs. Si j'ai bien compris, cela "empile" différents systèmes de fichiers (c'est-à-dire un disque au-dessus d'un disque). S'il y a un accès en lecture, unionfs cherche dans la pile jusqu'à ce qu'il atteigne le FS contenant le fichier recherché. Lors de l'écriture, unionfs recherche le premier FS en écriture sur la pile et l'utilise.
J'ai aussi trouvé ces articles qui peuvent être intéressants: http://www.linux-mag.com/id/7357/http://www.linux-mag.com/id/7345/
Et deux articles avec des astuces pour utiliser les disques SSD: http://danweinreb.org/blog/using-solid-state-disks-on-linuxhttp://www.zdnet.com/blog/perlow/geek-sheet-a-tweakers-guide-to-solid-state-drives-ssds-and-linux/9190
Sélectionner (et dimensionner) le bon système de fichiers est plus important que toute autre chose, pas seulement pour la sécurité, mais pour des tas d'autres raisons que les gens ne reconnaissent généralement pas. Sans système de fichiers, tout le traitement irait à null.
Olli a très bien répondu, et le PO est très ancien, mais les systèmes de fichiers sont ma bête noire, je ne pouvais pas rester à l'écart. superuser.com n'est pas quelque chose que j'ai visité auparavant, je ne suis pas un administrateur, mais je me suis inscrit et je vais en visiter davantage.
Les choses ont beaucoup changé depuis 2011, mais même à l'époque, j'avais formaté les cartes USB en FAT et utilisé des clés USB pour transporter des fichiers de 4 Go +. La raison en était bien sûr la compatibilité et non la sécurité (tant pour S en SD, mais j’utilise des mots de passe sur mes 7z), et je n’ai jamais vraiment porté quoi que ce soit plus gros qu’un CD ISO, c’est surtout pour les scripts SQL instantanés de base de données cryptés pressés à mort par 7-Zip.
De nos jours, je porte n'importe quel SD plus rapidement que quiconque que je connaisse. J'ai chez mon employeur une clé USB dans certaines machines de production pour la sauvegarde automatisée toutes les heures, au format FAT. Je garde un œil sur eux tous les jours et, vous l'avez deviné, sauvegardez-les religieusement à la main (ce sont des éléments ITAR sécurisés hors ligne). SSD a nivelé une partie du terrain de jeu mais je ne leur fais toujours pas confiance autant que la HD normale, et SD est pire que l’optique. Ils vont mal en un instant et la perte est totale.
Tout système de fichiers qui invite le système d'exploitation hôte à écrire de manière aléatoire sur celui-ci (NTFS, Corbeille) constitue une mauvaise nouvelle pour un SD. En outre, son démontage aide beaucoup, aucun système d'exploitation n'essaie d'accéder à un stockage non monté, donc tout système de fichiers le fera aussi longtemps que le SD inclut un script pour annuler la suppression lui-même (l'un des fichiers standard sur chaque SD sur le mien).
La lecture d'une carte SD étant encore lente aujourd'hui, je recommanderais donc quelque chose comme une copie de disque (dd) pour capturer l'image entière lors de la mise en miroir plutôt que fichier par fichier. dd vous a également laissé savoir quand il y a quelque chose qui ne va pas, afin que votre gestionnaire de fichiers n'ira pas kaboom.
Bien entendu, si votre objectif principal est de prolonger la durée de vie d’un penny-stock, vous vous occupez mal de votre entreprise. Je fais ce que je ne fais pas pour prolonger la vie d'un SD mais pour l'empêcher de mal tourner quand je ne regarde pas, et il y a une différence.
J'évite ext4 ou toute journalisation FS en SD parce que cela ne me dérange pas qu'ils écrivent mal, mais ça me fait mal quand un jour ou deux plus tard, je ne peux pas les lire!
si vous voulez une carte SD sans perte, je suggère d'utiliser BTRFS parce que:
BTRFS est un nouveau système de fichiers par rapport à EXT créé à l'origine par Oracle en 2007.
Il apporte de nouvelles fonctionnalités aux systèmes de fichiers traditionnels:
- Clonage/instantané
- Diffs (envoyer/recevoir)
- Quotat
- Syndicat
- Auto-guérison (avec des périodes de validation par défaut de 30 secondes)
pour une explication supplémentaire et une comparaison, reportez-vous à this pdf
pour les nouvelles comparaisons, consultez ce site
En réponse à la recommandation d’utiliser fat (32?): J’ai fait quelques tests de performances et découvert que fat32 a un temps très prévisible pour écrire un fichier (2 Go nécessitent deux fois plus de 1 Go + offset, 3 Go nécessitent des temps d’arbre de 1 Go + offset). Les performances de ext4 sont légèrement meilleures que celles de ext3. Ext3 et ext4 sont parfois rapides mais nécessitent parfois un peu plus de temps pour écrire les fichiers journaux sur le disque (pas de comportement en temps d'écriture linéaire). Tous les tests ont été effectués avec fsync () pour vérifier que le fichier est réellement écrit sur le disque. J'ai effectué des tests avec sync (). Ils entraînent de très mauvaises performances en écriture. Je suis donc retourné à fsync (). J'ai vérifié si fsync () était suffisant. Par conséquent, j’ai alimenté l’appareil sans arrêter le système ou retiré la carte SD sans le démonter. En aucun cas les fichiers écrits ou la structure de répertoires n'ont été endommagés. Nous avons donc décidé d'utiliser ext4 et uniquement fsync ().
Cordialement, Thomas