Le 16 août 05 à 13:09, Bruno Bonfils a écrit :
non, il "suffit" de mettre en attente toutes les opérations d'écriture
au niveau du noyau. Par exemple, sous Linux/SGI/autres, il y a XFS,
qui
vient avec un outil xfs_freeze. Il suffit d'essayer, tu montes une
partition XFS, des données, tu fais un freeze, tu peux lire, mais une
opération en écriture sera bloquée (en attente d'IO en fait, si ma
mémoire est bonne) et non pas annulé, tant que tu n'a pas unfreeze ton
FS. Ce qui permet donc de faire un dump cohérent (au niveau FS en tout
cas, bien entendu au niveau application, à ce niveau, on ne peut rien
garantir). C'est pourquoi il est toujours déconseillé de stopper les
daemons. Par contre, sur une partition genre /export/home, je ne vois
aucun problème.
Cool, comment perdre 1h de boulot en un rien de temps, même avec tout
les sync de la terre. Ça maintient la cohérence entre les méta
données & les données ce truc là ? Faut pas que ça s'enfile au
hasard, sinon, c'est quand même un file system incohérent. fssnap ne
bloque rien, mais crée un environnement stable, avec conservation de
l'état au moment du snap. Ça prends un temps nul à faire mais ça
occupe d'autant plus de place qu'il y a d'activité durant le snap, vu
que ça conserve les anciennes données.
C'est vraiment gênant d'avoir un état plus ou moins stable d'un file
system ? Tout dépend des applications qui tournent. Avec un apache,
au pire, les derniers logs sont pas à jour. C'est surtout les bases
de données qui craignent.
_______________________________________________
Solaris_fr liste de diffusion en français pour Solaris, sur toutes architectures
[email protected]
http://x86.sun.com/mailman/listinfo/solaris_fr
