actions fichiers [conception]

Le
gpg
Bonjour,
(Je ne cherche pas a connaitre une implementation, mais juste d'avoir
votre avis sur l'idee)
context :
j'ai un systeme embarque type posix. et j'aimerai effectue des actions
de deplacement, et de copies. mn systeme de fichiers n'est pas
journalise, et mon systeme risque de rebooter suite a une alimentation
defaillante.
idee:
Imaginons que je veux copier un fichier toto vers un emplacement titi,
si le fichier est assez grand, je ne pourrai arreter la copie apres
l'avoir lancer vu que la commande de copie s'execute dans le context de
mon kernel, du coup je me trouve oblige de decouper le fichier en petits
morceaux, qq1 a une meilleure idee ?


Bonne journee.
Vidéos High-Tech et Jeu Vidéo
Téléchargements
Vos réponses
Gagnez chaque mois un abonnement Premium avec GNT : Inscrivez-vous !
Trier par : date / pertinence
Harpo
Le #985290
On Wed, 25 Apr 2007 05:38:30 +0200, gpg wrote:

Imaginons que je veux copier un fichier toto vers un emplacement titi,
si le fichier est assez grand, je ne pourrai arreter la copie apres
l'avoir lancer vu que la commande de copie s'execute dans le context de
mon kernel, du coup je me trouve oblige de decouper le fichier en petits
morceaux, qq1 a une meilleure idee ?


Je n'ai pas bien compris le problème.
Pourquoi vouloir arrêter la copie ? Autant ne pas la lancer.
Pourquoi exécuter une commande dans le contexte du kernel ? Pourquoi ne
pas utiliser cp ou dd ? Je ne comprends pas bien.

Bref, j'ai du manquer quelque chose, peut-être aussi fr.comp.os.unix
serait un meilleur forum.

--
SKILL (Simple Knowledge Inference Logic Language)
http://patrick.davalan.free.fr/skill-0/

Antoine Leca
Le #985128
En news:462ecdb5$0$17837$,
gpg va escriure:
j'ai un systeme embarque type posix. et j'aimerai effectue des actions
de deplacement, et de copies. mn systeme de fichiers n'est pas
journalise, et mon systeme risque de rebooter suite a une alimentation
defaillante.


J'ai du mal à saisir le problème en cas de copie. C'est toi qui maîtrise
l'information « le nouvel exemplaire (récemment copié) est disponible », non
?
Si oui, il n'y a pas de souci, il suffit de publier cette information
*après* s'être assuré que la copie s'est bien passée (sur le support
physique).
Si non, tu as trouvé un sujet à fouiller pour tes tests de résilience! Parce
qu'à mon avis, ton cas ci-dessus n'est que la pointe émergée d'un gros
iceberg! Pour mémoire, c'est la raison pure et simple d'un certain
utilitaire "fsck" ou autre "scandsk.exe", lancé à chaque démarrage...)

Pour le cas de déplacement, le sujet est beaucoup plus intéressant! Je
suppose que tu ne peux pas faire des déplacements « à la Posix » (link(2)
vers le nouvel emplacement, puis unlink(2) pour suppression du lien
initial), et que tu es obligé de procéder par copie+effacement,
éventuellement par petits morceaux si le « fichier » dépasse en taille la
moitié de ce qui est disponible.
Mon idée dans un cas semblable serait de mettre en place un mécanisme de
sémaphore : par exemple avec la création au début d'un fichier témoin, par
exemple machin.lock, qui signale aux autres processus que « Pas touche! un
processus est en train de déplacer un fichier » ; et au redémarrage, tu
regardes si le fichier témoin est présent, et si oui tu reprends le
processus avorté. À la fin, après avoir entièrement effacé l'original, tu
effaces le fichier témoin.


Antoine

Publicité
Poster une réponse
Anonyme