Choix du système de fichiers pour GNU / Linux sur une carte SD

J'ai un système basé sur ARM intégré fonctionnant sur une carte SD. C'est actuellement Debian GNU / Linux utilisant ext3 comme système de fichiers. Alors que je suis sur le point de réinstaller le système, j'ai commencé à me poser des questions sur le passage à un système de fichiers plus convivial pour Flash. 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 ext4 pour mieux s'adapter aux disques SSD; dois-je interpréter cela comme exécutant ext4 devrait être très bien? À quoi dois-je penser en particulier dans ce cas?

Je suppose que l'utilisation du système est importante. Mais pour des raisons de généralité, imaginez qu'il fera des trucs de bureau standard (même s'il s'agit en fait d'un petit système basé sur ARM).

Merci pour toutes les réponses.

Edit: Wikipedia me dit (dans une déclaration de «citation nécessaire») que les cartes mémoire flash amovibles et les lecteurs flash USB ont des contrôleurs intégrés pour effectuer le nivellement de l'usure et la correction des erreurs, donc l'utilisation d'un système de fichiers flash spécifique n'ajoute aucun avantage . Ainsi, je penche pour rester avec un système de fichiers ext.

Excellent article sur les systèmes de fichiers flash .

Une question importante lorsque l'on parle de systèmes de fichiers flash est la suivante: Qu'est-ce que le nivellement d'usure? Article Wikipédia . Fondamentalement, sur les disques flash, vous pouvez écrire un nombre limité de fois jusqu'à ce que le bloc se détériore. Après cela, le système de fichiers (s'il n'y a pas de gestion intégrée du niveau d'usure sur le matériel, comme c'est généralement le cas pour les SSD) doit marquer ce bloc comme invalide et éviter de l'utiliser à nouveau.

Les systèmes de fichiers typiques (par exemple ReiserFS, NTFS, ext3 et ainsi de suite) sont conçus pour les disques durs, qui n'ont pas de telles limitations.

JFFS2

Comprend une protection et une protection élégante contre le nivellement.

YAFFS2

• Une seule chose qui fait la différence: des temps de montage courts, après un démontage réussi.
• 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ème.

UBIFS

• Plus mature que LogFS
• Prise en charge de la mise en cache d'écriture
• Sur l'évolutivité: article . Sur de grands disques, de meilleures performances qu'avec JFFS2

ext4

Si aucun pilote ou carte (par exemple les disques SSD ne possède de niveau d'usure interne, au moins généralement) ne gère le niveau d'usure, alors 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 gros systèmes de fichiers, phase de développement mature, performances adéquates et pas de gros inconvénients.

J'étais confronté au même problème et j'ai également fait des recherches. Finalement, j'ai décidé d'aller avec ext2.

Il semble que certaines cartes SDHC implémentent leur propre niveau d'usure au niveau de la couche matérielle. Si vous pouvez mettre la main sur des cartes SDHC dotées d'une fonction anti-usure.

Les systèmes de fichiers qui fournissent un niveau d'usure peuvent interférer avec le niveau d'usure du niveau Flash, de sorte qu'il peut être mauvais pour le flash de les utiliser (l'article IBM cité ci-dessus explique comment JFFS le fait, il est donc clair que cela ne fonctionnera pas avec flash WL). J'ai décidé que je n'avais pas besoin de la journalisation d'ext3 car je n'y stockais pas de données critiques et je sauvegardais régulièrement 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 suffisamment de RAM, vous devez le faire (mais assurez-vous de faire pivoter ou de supprimer vos journaux régulièrement)

CONSEIL: Montez vos cartes SD ext 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 et d'une partition en lecture-écriture (ou d'une clé USB qui peut ê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 s'use.

Et puis il y a les unionfs. Si je comprends bien, il "empile" différents systèmes de fichiers (c'est-à-dire un ro fs au-dessus d'un rw fs). S'il y a un accès en lecture, unionfs recherche dans la pile jusqu'à ce qu'il atteigne le FS contenant le fichier que nous recherchons. Lors de l'écriture, unionfs recherche le premier FS inscriptible sur la pile et l'utilise.

J'ai également 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 conseils pour l'utilisation des disques SSD: http://danweinreb.org/blog/using-solid-state-disks-on-linux http://www.zdnet.com/blog/perlow/geek-sheet-a- tweakers-guide-to-solid-state-drives-ssds-and-linux / 9190

La sélection (et le dimensionnement) du système de fichiers correct est plus importante que toute autre chose, non seulement pour la sécurité mais pour des tonnes d'autres raisons que les gens ne reconnaissent généralement pas. Sans système de fichiers, tout le traitement serait nul.

Réponse très bien mise par Olli, et l'OP est très daté, 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 administrateur, mais je me suis inscrit et je vais visiter plus.

Les choses ont beaucoup changé depuis 2011, mais même à l'époque, j'ai formaté des cartes USB FAT et utilisé des clés USB pour transporter des fichiers 4Gb +. La raison é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é quelque chose de plus grand qu'un CD ISO, ils étaient principalement pour des scripts SQL et des différences quotidiennes de déjà Instantanés de base de données chiffrés pressés à mort par 7-Zip.

Ces jours-ci, je porte n'importe quel SD plus rapidement que tous ceux que je connais. J'ai une clé USB dans certaines machines de production chez mon employeur pour une sauvegarde automatisée toutes les heures, formatée en FAT. Je les garde tous les jours cependant et - vous l'avez deviné - sauvegardez-les religieusement à la main (ils sont des éléments de construction ITAR sécurisés hors ligne). Le SSD a nivelé une partie du terrain de jeu, mais je ne leur fais toujours pas autant confiance que le HD normal, et le SD est pire qu'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 à y écrire de manière aléatoire (NTFS, Corbeille) est une mauvaise nouvelle pour une SD. De plus, le démontage aide beaucoup, aucun système d'exploitation n'essaiera d'accéder au stockage non monté, donc tout système de fichiers fera aussi longtemps que la SD comprend un script pour se démonter (l'un des fichiers standard sur chaque SD sur le mien).

La lecture d'une SD est encore lente aujourd'hui, donc je recommanderais quelque chose comme un vidage de disque (dd) pour récupérer l'image entière lors de la mise en miroir au lieu d'un fichier fichier par fichier. dd vous permet également de savoir quand quelque chose ne va pas, afin que votre gestionnaire de fichiers ne soit pas kaboom.

Bien sûr, si votre objectif principal est de prolonger la durée de vie de certains penny stock, vous vous occupez de votre entreprise dans le mauvais sens. Je fais ce que je ne fais pas pour prolonger la durée de vie d'un SD mais pour l'empêcher de mal tourner quand je ne regarde pas, et il y a la différence.

J'évite ext4 ou toute journalisation FS sur SD parce que je m'en fiche quand ils vont mal leur écrire, mais ça fait mal quand un jour ou deux plus tard je ne peux pas les lire!

En réponse à la recommandation d'utiliser fat (32?): J'ai fait des tests de performances et j'ai découvert que fat32 a un temps très prévisible pour écrire un fichier (2 Go ont besoin de deux fois 1 Go + décalage, 3 Go ont besoin de temps d'arborescence de 1 Go + décalage). Les performances d'ext4 sont légèrement meilleures que d'ext3. Ext3 et ext4 sont parfois rapides mais nécessitent parfois du temps supplémentaire pour écrire les fichiers journaux sur le disque (pas de comportement de temps d'écriture linéaire). Tous les tests ont été effectués avec fsync () pour s'assurer que le fichier est vraiment écrit sur le disque. J'ai effectué quelques tests avec sync (). Ils entraînent de très mauvaises performances d'écriture. Je suis donc retourné à fsync (). J'ai vérifié si fsync () est suffisant. Par conséquent, j'ai alimenté l'appareil sans arrêt du système ou retiré la carte SD sans démonter. En aucun cas, les fichiers écrits ou la structure du répertoire n'ont été endommagés.

Cordialement, Thomas

si vous voulez une carte sd sans perte, je suggère d'utiliser BTRFScar:

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és
• Diffs (envoyer / recevoir)
• Quotat
• syndicat
• Auto-guérison (avec des périodes de validation par défaut à 30 secondes)

pour plus d'explications et de comparaison, se référer à ce pdf

pour de nouvelles comparaisons se référer à ce site