Bonjour!
Mon portable possède un lecteur de carte compact-flash. J'ai décidé d'en profiter pour réaliser sur une telle carte des sauvegardes quotidiennes et automatiques de mes données.
Du coup, je me demande quel système de fichier adopter pour la carte.
* Inutile que ce système de fichier soit lisible par autre chose que linux.
* Je pensais me tourner naturellement vers de l'ext4, mais j'ai peur que la journalisation soit à terme douloureuse pour la carte, et sans réel avantage.
Je suis preneur de tous conseils ou remarques.
Merci!
Forum général.cherche-logiciel Système de fichier pour carte compact-flash
4
août
2010
# besoin de plus de détails
Posté par bertrand . Évalué à 1.
Cela change beaucoup le problème : dans le premier cas, tu cherche seulement un système de fichier efficace et performant. Dans le second, tu dois trouver un système de fichier qui te garantit l'absence de possibilité de corruption d'un contenu déjà écrit.
Ensuite, il y a des SF spécialisé pour les supports type carte : du genre logFS.
[^] # Re: besoin de plus de détails
Posté par Sygne (site web personnel) . Évalué à 1.
Je ne cherche pas à archiver des données pour le long terme.
Le but est d'avoir un duplicata _à jour_ de mes données en cas de crash du disque dur, ou d'erreur de manipulation:
Une sauvegarde par jour, un nettoyage toutes les semaines environ des données vieilles de plus d'une semaine.
Plus que la journalisation, c'est le cycle d'écriture, d'effacement et de ré-écriture qui me fait peur pour la mémoire flash.
[^] # Re: besoin de plus de détails
Posté par NeoX . Évalué à 2.
rsync avec les bonnes options pour ne transferer que ce qui a changé depuis le rsync precedent
y a meme une option --delete pour effacer de la sauvegarde les fichiers qui ont été effacés dans le dossier d'origine
[^] # Re: besoin de plus de détails
Posté par Sygne (site web personnel) . Évalué à 2.
Adapter le système de fichier au matériel fait sens selon moi.
Par contre, pour le choix du logiciel de sauvegarde, j'avais pris en compte d'autres critères que les contraintes posées par la mémoire flash...
Je pensais ne pas le faire avec Rsync, car outre le duplicata de l'état actuel de mon répertoire, je veux aussi conserver l'état d'il y a quelques jours (environ une semaine).
Après lecture de ce comparatif des différents logiciels de sauvegardes pour les unix, j'en ai conclu que dar ou tar convenaient à mes besoins. Comme il est d'usage dans ces conditions, je me contente de ce qui est installé d'office, à savoir tar. Ça me semble être un très bon choix: simple, robuste, efficace, portable, durable.
Est-ce incompatible avec les contraintes d'une carte compact-flash?
[^] # Re: besoin de plus de détails
Posté par wismerhill . Évalué à 1.
Si tu ne veux pas faire ça manuellement, il y a rsnapshot qui fait exactement ça:
http://www.rsnapshot.org
Ça donne évidemment de meilleurs résultats si tu as beaucoup de petits fichiers que quelques très gros, car un gros fichier dont un octet a changé doit être dupliqué en entier.
Et sinon, concernant ext4 tu peux désactiver le journal, cf la FAQ officielle
https://ext4.wiki.kernel.org/index.php/Frequently_Asked_Ques(...)
(la dernière question)
[^] # Re: besoin de plus de détails
Posté par Sygne (site web personnel) . Évalué à 1.
À lire Luten ci-dessous, dans mon cas, le nombre de ré-écritures successives n'est pas problématique.
Du coup, je peux décoreller le choix du logiciel de sauvegarde des problématiques de la mémoire Flash.
Quant au lien sur la FAQ de ext4, il est parfait.
[^] # Re: besoin de plus de détails
Posté par Sygne (site web personnel) . Évalué à 1.
http://www.halfgaar.net/backing-up-unix
# Qui dit flash
Posté par TheBreton . Évalué à 0.
voici un long et complet point sur la situation dispo sur ton site préféré
https://linuxfr.org//2008/04/04/23938.html
Personnellement je te conseillerais UBIFS
[^] # Re: Qui dit flash
Posté par luten . Évalué à 3.
A voir sur le site UBIFS [1]:
Big red note
One thing people have to understand when dealing with UBIFS is that UBIFS is very different to any traditional file system - it does not work on top of block devices (like hard drives, MMC/SD cards, USB flash drives, SSDs, etc). UBIFS was designed to work on top of raw flash, which has nothing to do with block devices. This is why UBIFS does not work on MMC cards and the like - they look like block devices to the outside world because they implement FTL (Flash Translation Layer) support in hardware, which simply speaking emulates a block device on top of the built-in raw flash. Please, make sure you understand the differences between raw flash and, say, MMC flash before dealing with UBIFS. This section should help.
1: [http://www.linux-mtd.infradead.org/doc/ubifs.html#L_rednote]
[^] # Re: Qui dit flash
Posté par Sygne (site web personnel) . Évalué à 1.
Tu précises que cela concerne aussi les autres FFS, mais quels sont ces autres FFS: LogFS, JFFS2?
Est-ce dire que rien d'autre ext[3-4] n'a de sens?
[^] # Re: Qui dit flash
Posté par luten . Évalué à 2.
UBIFS et autres utilisent par exemple les flash NAND en direct pour avoir accès aux pages et blocs de la flash ainsi qu'aux zones de contrôle ( les spares area ) ce qui n'est pas possible au travers d'un contrôleur qui émule une disque et ne permet que les accès secteurs.
La gestion de l'usure des blocks est effectuée dans le contrôleur de la CF, c'est lui qui égalise cette usure ( "wear leveling" en anglais), dans un FFS c'est la couche FTL qui s'en occupe puisqu'il n'y a pas de contrôleur physique.
Au final, si le contrôleur de ta CF est suffisamment efficace, ce qui compte c'est le nombre total d'accès pas l'endroit ( au sens adresse logique donc secteur) où tu les fait. Le souci est donc que l'on est, dans ce cas, dépendant du travail effectué par le contrôleur de la carte, si le firmware est pourrit tu risques de cramer ta carte prématurément.
[^] # Re: Qui dit flash
Posté par Sygne (site web personnel) . Évalué à 1.
J'ai essayé de choisir une carte de bonne qualité en m'appuyant sur certains comparatifs. Elle est par ailleurs garantie 10 ans, j'imagine que le constructeur a pris soin de coder proprement son contrôleur afin d'éviter d'avoir trop de retours...
En lien avec les remarques de NeoX ci-dessus, j'hésite sur le sens de cette phrase: «ce qui compte c'est le nombre total d'accès pas l'endroit ( au sens adresse logique donc secteur) où tu les fait».
Est-ce le nombre total d'accès sur la carte qui compte (~366 par an dans mon cas), ou le nombre total d'accès par endroit (moins de 366 par an pour certains endroit si j'utilise un logiciel qui ne ré-écrit pas une donnée non modifiée par la nouvelle sauvegarde)?
[^] # Re: Qui dit flash
Posté par luten . Évalué à 1.
Une NAND SLC par exemple supporte 10 000 cycles d'effacements par blocks sachant que les écriture se font par page.
Par exemple pour une NAND SLC de 4Go (avec des blocks de 128k et des pages de 2k) tu peux faire en théorie au maximum:
4G/2k*10 000 = 20E9 écritures
En pratique le nombre est bien sur inférieur car il y aussi les écritures effectuées par le FS et les écritures dues au wear leveling, mais cela donne un ordre d'idée.
[^] # Re: Qui dit flash
Posté par Sygne (site web personnel) . Évalué à 1.
Je connais cette dépêche. Le problème, c'est qu'à l'heure de son écriture aucune solution ne semblait réellement efficace:
* JFFS2 est critiquable pour le temps nécessaire au montage (ma carte fait 8Go soit 8x3,3 secondes selon l'article).
* Les autres solutions étaient qualifiées de jeunes, soit au sens ou elles devaient encore faire leur preuve, soit au sens ou leur mode de développement paraissait encore incertain.
Avec le temps, j'imagine que les choses sont un peu tassées, et que certains par ici ont une expérience réelle à partager.
# Commentaire supprimé
Posté par Anonyme . Évalué à 2.
Ce commentaire a été supprimé par l’équipe de modération.
# Merci!
Posté par Sygne (site web personnel) . Évalué à 2.
Suivant vos bons conseils et mes mauvaises habitudes, j'ai pris la décision suivante:
* Système de fichier ext4
* Vraisemblablement avec journalisation, car je veux justement que mes données soient propres et accessibles vite fait bien fait (sans fsck complet) en cas de crash, bien que j'hésite encore un peu.
* Avec l'option noatime (qui implique l'option nodiratime), et qui évite plus d'écritures que l'option relatime.
* Les sauvegardes seront effectuées avec tar (tar saibien).
[^] # Re: Merci!
Posté par Phil Actaire . Évalué à 1.
Il reste cependant encore expérimental, ou alors c'est récent.
Concernant la journalisation, c'est une bonne idée puisque le surplus de place prise est raisonnable compte tenu des avantages fournis.
[^] # Re: Merci!
Posté par steph1978 . Évalué à 1.
En fait il embarque son propre contrôleur IDE, comme un disque dur branché sur ce même contrôleur d'une carte mère.
Donc il faut se rabattre sur des FS plus classiques comme les extN.
Pour ma part, je me sers d'un CF de 8GB comme DD système sur mon laptop. J'ai choisi ext2 (de mémoire) pour éviter la journalisation et donc des écritures supplémentaires, justement. A bien y réfléchir, je ne suis pas sûr que ce soit légitime.
Dans le doute, si/quand je referai mon système, je partirai sur du ext4.
Pour de la sauvegarde, ext4. oublie en tous cas des FS plus basiques comme fat32, car tu ne peux pas faire de lien et donc faire des snapshots en utilisant 'cp -lr'.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.