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 ?
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
Harpo
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.
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.
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.
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
En news:462ecdb5$0$17837$426a74cc@news.free.fr,
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.
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.
