spectras (./3966) :
De mon post, précisément celui que tu cites :

spectras (./3934) :
Si tu réalisais cette tâche dans un thread, soit tu obtiendrais une base de données corrompue, soit tu devrais implémenter toi-même un mécanisme de copy-on-write manuel.

Eh bien oui, mais je cite ton message qui cite lui-même celui de Brunni. Et ton message montre que tu n'as pas du tout compris ce que Brunni voulait dire (Brunni, je t'en pris, si je me trompe, tu peux le dire). Et ma réponse à ton post que je cite, c'est pour essayer de t'expliquer ce que tu n'as pas compris. J'ai visiblement échoué, mais ce n'est pas grave.

RHJPP (./3960) :
Ha oui, doubler voir plus le trafic vers le disque parce que tu as été incapable de voir qu'une sauvegarde était déjà en cours, et par conséquent compromettre les performances de ton serveur ne te dérange pas ?

Pourquoi les deux sauvegardes devraient être sur le même support ? On peut tout à fait en faire une sur un support local et l'autre sur un NAS, pour ne donner que cet exemple.

Tu réponds sur ce dont je ne parlais pas ? Intéressant, mais hors sujet. Je parlais uniquement du cas où tu souhaites lancer une nouvelle sauvegarde sur un support alors que la sauvegarde précédente vers le même support a échoué. Tu vas me dire que tu ne fais jamais deux fois tes sauvegardes sur le même support ? Que vient faire la possibilité d'utiliser plusieurs supports là-dedans ?

RHJPP (./3960) :
Ce paragraphe ne se limite pas à une phrase. Ha ho tiens, la phrase suivante elle disait quoi en fait ?

— La suivante parle des problèmes à essayer de faire plusieurs sauvegardes sur le même fichier. Il me semblait inutile d'y répondre à partir du moment où j'avais précisé qu'on ne fait jamais ça.

Bah, relis ? La phrase suivante dit qu'on peut vouloir faire la sauvegarde dans un fichier temporaire pour ne pas compromettre la dernière sauvegarde valide. Autrement dit, pour par exemple ne pas perdre ses sauvegardes si une coupure d'électricité se produit pendant la sauvegarde.

spectras (./3966) :
— et comme tu vas refaire la même : celle d'après suppose que les sauvegardes sont faites à intervalle régulier. Je ne vois pas non plus d'où sort une telle supposition.

Tu n'as qu'à ajouter le mot moyen après intervalle si tu veux.

— et sur la dernière phrase du paragraphe, qui dit «il est peu probable qu'il y ait un fichier par sauvegarde car la taille occupée sur le disque serait un peu trop énorme », j'ai juste une réponse : bienvenue dans la vraie vie. T'as une idée de la capacité d'une bande ?

Bah oui, tu trouves ça extraordinaire ? Même avec une bande, faire une sauvegarde toutes les minutes des 10 Go de base comme le suggérait Kevin, c'est trop gros. Et je peux ajouter que même si ça pouvait se faire, ce ne serait que tu gâchis de place et il ne me semble pas que ce soit le but lorsqu'on fait des sauvegardes.

Du coup, dire que tu peux t'en passer et implémenter la copie toi-même...

Si encore j'avais dit ça... Je n'ai pas encore donné mon avis sur la question. Je n'intervenais que parce que tu répondais à côté de la plaque, ou que tu faisais exprès de ne pas comprendre dans ./3934. J'aurais dû savoir que tu ne le supporterais pas et m'abstenir, désolé.


Bon, sinon, avec tout ça, j'ai enfin décidé si j'aimais bien fork ou pas. Et bien je suis partagé. D'un côté fork c'est pratique si tu as besoin de faire exactement tout ce qu'il fait, mais pas s'il fait des choses en trop... En fait, je trouve que fork n'est pas assez pur comme fonction. Par exemple, pour faire une sauvegarde de la base, fork, c'est pratique puisque tout le processus est copié, on n'a pas à le faire. Mais aussi, pourquoi le processus de sauvegarde aurait-il besoin de tout ce que contenait le processus principal ? Je vais me retrouver avec des copies multiples de choses dont je n'aurai jamais besoin... Par exemple, imaginons que mon processus principal réserve 5 Go de mémoire pour son fonctionnement et que la base à sauvegarder ne fasse pas plus de 10 Mo. Que va-t-il se passer au moment du fork pour la sauvegarde ? Bon peut-être que la base va être recopiée lorsque le processus principal va modifier sa version, et ça c'est cool parce que c'est ce que je veux. Mais que va-t-il maintenant se passer lorsque le processus principal va tout naturellement utiliser la mémoire qu'il a réservée ? La mémoire va être copiée, mais ce n'est pas du tout ce que je voulais ! Et les performances du serveur pendant la copie de ces 5 Go vont sans doute être réduites ! Bon, ce phénomène ne se produit souvent qu'à une petite échelle, mais il me semblerait plus correct de ne cloner que ce dont on a réellement besoin. fork fait trop de choses et il devrait être décomposé.