non. un logiciel de chiffrement chiffre. une fois que tu as chiffre c'est a toi d'effacer l'original. sous unix (netbsd) j'utilise srm (secure rm) avec la methode presentee par gutmann dans son papier.
Question idiote : tu as bien vérifié que srm fonctionnait ? Parce que sur les file systems journalisés, l'échec est garanti. -- http://arboi.da.ru FAQNOPI de fr.comp.securite http://faqnopi.da.ru/
gilbertf@netbsd-fr.org writes:
non. un logiciel de chiffrement chiffre. une fois
que tu as chiffre c'est a toi d'effacer l'original.
sous unix (netbsd) j'utilise srm (secure rm) avec
la methode presentee par gutmann dans son papier.
Question idiote : tu as bien vérifié que srm fonctionnait ?
Parce que sur les file systems journalisés, l'échec est garanti.
--
arboi@alussinan.org http://arboi.da.ru
FAQNOPI de fr.comp.securite http://faqnopi.da.ru/
non. un logiciel de chiffrement chiffre. une fois que tu as chiffre c'est a toi d'effacer l'original. sous unix (netbsd) j'utilise srm (secure rm) avec la methode presentee par gutmann dans son papier.
Question idiote : tu as bien vérifié que srm fonctionnait ? Parce que sur les file systems journalisés, l'échec est garanti. -- http://arboi.da.ru FAQNOPI de fr.comp.securite http://faqnopi.da.ru/
gilbertf
Michel Arboi wrote:
Question idiote : tu as bien verifie que srm fonctionnait ? Parce que sur les file systems journalises, l'echec est garanti.
je vais pas entrer dans les details techniques mais un fs n'a pas besoin d'etre journalise pour etre fiable. la journalisation ne sert qu'a une chose: faire un fsck rapide apres un plantage ou une coupure de courant. quand on concoit un fs correctement on n'a pas besoin de le journaliser pour qu'il soit fiable. tu as des fs comme le ffs/ufs qui sont utilises depuis plus de 10 ans sous net, et plus de 20 ans globalement et ils sont pas journalises et ya jamais eu de merdes. on a meme un systeme qui permet de combiner des operations sur les meta-donnees en memoire (soft update ca s'appelle). bref les systemes journalises c'est vraiment pas mon probleme et si quelqu'un veut les utiliser (et donc accepter des axiomes de conception errones) a lui d'assumer les merdes qui iront avec.
le choix de la journalisation est techniquement une erreur et on trouve ce choix systematiquement chez des developpeurs qui au lieu de corriger les problemes a la source tentent de regler leurs problemes de fiabilite de fs apres-coup en rajoutant un journal.
c'est comme les gens qui reguliement viennent nous demander "hee pourquoi c'est dix fois plus rapide le disque sous linux par rapport a bsd ?" et qui sont surpris d'apprendre que linux par defaut monte ses disques en async donc en cas de coupure de jus ou plantage ca peut avoir de tres mauvaises consequences (meta-donnees corrompues en particulier) alors que sous bsd les disques sont pas montes async et qu'on inscrit les meta-donnees sur le disque immediatement (ou avec un leger decalage si on passe par les soft updates qui font se realiser les modifs des meta-donnees en ram en cas de burst puis une ecriture des meta donnees dans les 1 a 2 secondes qui suivent). c'est plus rapide en async c'est clair, et c'est aussi ce qu'il y a de plus dangereux pour ses donnees.
donc pour repondre a ta question: les fs journalises c'est le probleme des gens qui sont assez ignares pour les utiliser quand on a des fs developpes correctement qui sont dispo depuis des annees et qui font tout pareil que le journalise sans solution bancale et foireuse.
Michel Arboi <TMPwop6h@passoire.afraid.org> wrote:
Question idiote : tu as bien verifie que srm fonctionnait ?
Parce que sur les file systems journalises, l'echec est garanti.
je vais pas entrer dans les details techniques
mais un fs n'a pas besoin d'etre journalise
pour etre fiable. la journalisation ne sert qu'a
une chose: faire un fsck rapide apres un plantage
ou une coupure de courant. quand on concoit un fs
correctement on n'a pas besoin de le journaliser
pour qu'il soit fiable. tu as des fs comme le ffs/ufs
qui sont utilises depuis plus de 10 ans sous net,
et plus de 20 ans globalement et ils sont pas
journalises et ya jamais eu de merdes. on a meme
un systeme qui permet de combiner des operations
sur les meta-donnees en memoire (soft update ca
s'appelle). bref les systemes journalises c'est
vraiment pas mon probleme et si quelqu'un veut les
utiliser (et donc accepter des axiomes de conception
errones) a lui d'assumer les merdes qui iront
avec.
le choix de la journalisation est techniquement
une erreur et on trouve ce choix systematiquement
chez des developpeurs qui au lieu de corriger les
problemes a la source tentent de regler leurs
problemes de fiabilite de fs apres-coup en rajoutant
un journal.
c'est comme les gens qui reguliement viennent
nous demander "hee pourquoi c'est dix fois plus
rapide le disque sous linux par rapport a bsd ?"
et qui sont surpris d'apprendre que linux par
defaut monte ses disques en async donc en cas
de coupure de jus ou plantage ca peut avoir
de tres mauvaises consequences (meta-donnees
corrompues en particulier) alors que sous bsd
les disques sont pas montes async et qu'on inscrit
les meta-donnees sur le disque immediatement
(ou avec un leger decalage si on passe par
les soft updates qui font se realiser les modifs
des meta-donnees en ram en cas de burst puis
une ecriture des meta donnees dans les 1 a 2
secondes qui suivent). c'est plus rapide en
async c'est clair, et c'est aussi ce qu'il
y a de plus dangereux pour ses donnees.
donc pour repondre a ta question: les fs
journalises c'est le probleme des gens qui
sont assez ignares pour les utiliser quand
on a des fs developpes correctement qui sont
dispo depuis des annees et qui font tout
pareil que le journalise sans solution
bancale et foireuse.
Question idiote : tu as bien verifie que srm fonctionnait ? Parce que sur les file systems journalises, l'echec est garanti.
je vais pas entrer dans les details techniques mais un fs n'a pas besoin d'etre journalise pour etre fiable. la journalisation ne sert qu'a une chose: faire un fsck rapide apres un plantage ou une coupure de courant. quand on concoit un fs correctement on n'a pas besoin de le journaliser pour qu'il soit fiable. tu as des fs comme le ffs/ufs qui sont utilises depuis plus de 10 ans sous net, et plus de 20 ans globalement et ils sont pas journalises et ya jamais eu de merdes. on a meme un systeme qui permet de combiner des operations sur les meta-donnees en memoire (soft update ca s'appelle). bref les systemes journalises c'est vraiment pas mon probleme et si quelqu'un veut les utiliser (et donc accepter des axiomes de conception errones) a lui d'assumer les merdes qui iront avec.
le choix de la journalisation est techniquement une erreur et on trouve ce choix systematiquement chez des developpeurs qui au lieu de corriger les problemes a la source tentent de regler leurs problemes de fiabilite de fs apres-coup en rajoutant un journal.
c'est comme les gens qui reguliement viennent nous demander "hee pourquoi c'est dix fois plus rapide le disque sous linux par rapport a bsd ?" et qui sont surpris d'apprendre que linux par defaut monte ses disques en async donc en cas de coupure de jus ou plantage ca peut avoir de tres mauvaises consequences (meta-donnees corrompues en particulier) alors que sous bsd les disques sont pas montes async et qu'on inscrit les meta-donnees sur le disque immediatement (ou avec un leger decalage si on passe par les soft updates qui font se realiser les modifs des meta-donnees en ram en cas de burst puis une ecriture des meta donnees dans les 1 a 2 secondes qui suivent). c'est plus rapide en async c'est clair, et c'est aussi ce qu'il y a de plus dangereux pour ses donnees.
donc pour repondre a ta question: les fs journalises c'est le probleme des gens qui sont assez ignares pour les utiliser quand on a des fs developpes correctement qui sont dispo depuis des annees et qui font tout pareil que le journalise sans solution bancale et foireuse.
Michel Arboi
writes:
donc pour repondre a ta question: les fs journalises c'est le probleme des gens qui sont assez ignares pour les utiliser
Ça ne répond pas à ma question.
-- http://arboi.da.ru FAQNOPI de fr.comp.securite http://faqnopi.da.ru/
gilbertf@netbsd-fr.org writes:
donc pour repondre a ta question: les fs
journalises c'est le probleme des gens qui
sont assez ignares pour les utiliser
Ça ne répond pas à ma question.
--
arboi@alussinan.org http://arboi.da.ru
FAQNOPI de fr.comp.securite http://faqnopi.da.ru/
donc pour repondre a ta question: les fs journalises c'est le probleme des gens qui sont assez ignares pour les utiliser
Ça ne répond pas à ma question.
-- http://arboi.da.ru FAQNOPI de fr.comp.securite http://faqnopi.da.ru/
Fabrice..Bacchella
On 11 Feb 2004 16:33:35 GMT, wrote:
je vais pas entrer dans les details techniques mais un fs n'a pas besoin d'etre journalise pour etre fiable. la journalisation ne sert qu'a
le choix de la journalisation est techniquement une erreur et on trouve ce choix systematiquement
Les avantages d'un système de fichiers journalisés sous un peu plus complexe que ça. Si la majorité des éditeurs du marché (IBM, Sun, Irix, Apple) proposent une journalisation, ce n'est pas pour rien. Sauf Apple, tous ont quelques années d'expérience Unix et connaissent parfaitement UFS. Ce n'est donc pas parce qu'ils s'appuyaient sur système de fichiers défaillant (ext3 & NTFS pour nommer ceux auxquels je suppose que vous pensez) qu'ils ont développé des fonctions de journalisations. Idem pour VxFS, un système de fichiers vendu indépendamment du système d'exploitation par Veritas. Dans le cas au moins de Solaris, un UFS journalisé apporte un réel gain en performance.
Je ne suis pas en train de critiquer le principe des soft update utilisé par xBSD, je dis juste qu'il ne s'agit peut-être pas de la seul bonne solution.
c'est comme les gens qui reguliement viennent nous demander "hee pourquoi c'est dix fois plus rapide le disque sous linux par rapport a bsd ?" et qui sont surpris d'apprendre que linux par defaut monte ses disques en async donc en cas de coupure de jus ou plantage ca peut avoir de tres mauvaises consequences (meta-donnees corrompues en particulier) alors que sous bsd les disques sont pas montes async et qu'on inscrit les meta-donnees sur le disque immediatement (ou avec un leger decalage si on passe par les soft updates qui font se realiser les modifs des meta-donnees en ram en cas de burst puis une ecriture des meta donnees dans les 1 a 2 secondes qui suivent). c'est plus rapide en async c'est clair, et c'est aussi ce qu'il y a de plus dangereux pour ses donnees.
Là, je suis d'accord. Quand on a les performances d'un système de fichiers en RAM, il ne faut pas être surpris si on en a la fiabilité. Solaris a longtemp proposé un option non documenté pour activater un montage asynchrone d'une partition d'UFS, cette option a aujourd'hui disparue.
FU2 fr.comp.os.unix, on est très loin de la crypto là. --- http://fba.homeip.net
On 11 Feb 2004 16:33:35 GMT, gilbertf@netbsd-fr.org wrote:
je vais pas entrer dans les details techniques
mais un fs n'a pas besoin d'etre journalise
pour etre fiable. la journalisation ne sert qu'a
le choix de la journalisation est techniquement
une erreur et on trouve ce choix systematiquement
Les avantages d'un système de fichiers journalisés sous un peu plus
complexe que ça. Si la majorité des éditeurs du marché (IBM, Sun,
Irix, Apple) proposent une journalisation, ce n'est pas pour rien.
Sauf Apple, tous ont quelques années d'expérience Unix et connaissent
parfaitement UFS. Ce n'est donc pas parce qu'ils s'appuyaient sur
système de fichiers défaillant (ext3 & NTFS pour nommer ceux auxquels
je suppose que vous pensez) qu'ils ont développé des fonctions de
journalisations. Idem pour VxFS, un système de fichiers vendu
indépendamment du système d'exploitation par Veritas. Dans le cas au
moins de Solaris, un UFS journalisé apporte un réel gain en
performance.
Je ne suis pas en train de critiquer le principe des soft update
utilisé par xBSD, je dis juste qu'il ne s'agit peut-être pas de la
seul bonne solution.
c'est comme les gens qui reguliement viennent
nous demander "hee pourquoi c'est dix fois plus
rapide le disque sous linux par rapport a bsd ?"
et qui sont surpris d'apprendre que linux par
defaut monte ses disques en async donc en cas
de coupure de jus ou plantage ca peut avoir
de tres mauvaises consequences (meta-donnees
corrompues en particulier) alors que sous bsd
les disques sont pas montes async et qu'on inscrit
les meta-donnees sur le disque immediatement
(ou avec un leger decalage si on passe par
les soft updates qui font se realiser les modifs
des meta-donnees en ram en cas de burst puis
une ecriture des meta donnees dans les 1 a 2
secondes qui suivent). c'est plus rapide en
async c'est clair, et c'est aussi ce qu'il
y a de plus dangereux pour ses donnees.
Là, je suis d'accord. Quand on a les performances d'un système de
fichiers en RAM, il ne faut pas être surpris si on en a la fiabilité.
Solaris a longtemp proposé un option non documenté pour activater un
montage asynchrone d'une partition d'UFS, cette option a aujourd'hui
disparue.
FU2 fr.comp.os.unix, on est très loin de la crypto là.
---
http://fba.homeip.net
je vais pas entrer dans les details techniques mais un fs n'a pas besoin d'etre journalise pour etre fiable. la journalisation ne sert qu'a
le choix de la journalisation est techniquement une erreur et on trouve ce choix systematiquement
Les avantages d'un système de fichiers journalisés sous un peu plus complexe que ça. Si la majorité des éditeurs du marché (IBM, Sun, Irix, Apple) proposent une journalisation, ce n'est pas pour rien. Sauf Apple, tous ont quelques années d'expérience Unix et connaissent parfaitement UFS. Ce n'est donc pas parce qu'ils s'appuyaient sur système de fichiers défaillant (ext3 & NTFS pour nommer ceux auxquels je suppose que vous pensez) qu'ils ont développé des fonctions de journalisations. Idem pour VxFS, un système de fichiers vendu indépendamment du système d'exploitation par Veritas. Dans le cas au moins de Solaris, un UFS journalisé apporte un réel gain en performance.
Je ne suis pas en train de critiquer le principe des soft update utilisé par xBSD, je dis juste qu'il ne s'agit peut-être pas de la seul bonne solution.
c'est comme les gens qui reguliement viennent nous demander "hee pourquoi c'est dix fois plus rapide le disque sous linux par rapport a bsd ?" et qui sont surpris d'apprendre que linux par defaut monte ses disques en async donc en cas de coupure de jus ou plantage ca peut avoir de tres mauvaises consequences (meta-donnees corrompues en particulier) alors que sous bsd les disques sont pas montes async et qu'on inscrit les meta-donnees sur le disque immediatement (ou avec un leger decalage si on passe par les soft updates qui font se realiser les modifs des meta-donnees en ram en cas de burst puis une ecriture des meta donnees dans les 1 a 2 secondes qui suivent). c'est plus rapide en async c'est clair, et c'est aussi ce qu'il y a de plus dangereux pour ses donnees.
Là, je suis d'accord. Quand on a les performances d'un système de fichiers en RAM, il ne faut pas être surpris si on en a la fiabilité. Solaris a longtemp proposé un option non documenté pour activater un montage asynchrone d'une partition d'UFS, cette option a aujourd'hui disparue.
FU2 fr.comp.os.unix, on est très loin de la crypto là. --- http://fba.homeip.net
gilbertf
Michel Arboi wrote:
ca ne repond pas a ma question.
groumph
parce que j'ai tout fait pour ne pas y repondre ;)
Michel Arboi <TMPwop6h@passoire.afraid.org> wrote:
ca ne repond pas a ma question.
groumph
parce que j'ai tout fait pour ne pas y
repondre ;)
parce que j'ai tout fait pour ne pas y repondre ;)
gilbertf
Fabrice..Bacchella wrote:
Les avantages d'un systeme de fichiers journalises sous un peu plus complexe que ca. Si la majorite des editeurs du marche (IBM, Sun, Irix, Apple) proposent une journalisation, ce n'est pas pour rien.
ca depend. parfois ils le font pour une raison technique justifiee (un serveur comportant des ensembles de disques et plusieurs To de donnees dont il souhaitent que les donnees soit disponibles immediatement apres un redemarrage de la machine pour une quelconque raison) et plus souvent ils integrent un systeme de journalisation car le concurrent le fait et qu'il faut l'avoir sinon le client va suivre la hype du moment et leur demander "pourquoi vous avez pas la fonction machin dont parle votre concurrent ?". generalement ce phenomene se traduit par un changement dans le nom. par exemple mandrake et redhat dont les numeros de "versions" gonflaient mais en meme temps.. ou encore Sony qui etait a la version 4.3 de son ATRAC et qui decide de repasser a ATRAC3 (a ne pas confondre avec ATRAC 3 souligne Sony) pour que les clients se disent "ya un 3 comme dans mp3 donc ca doit etre pareil!").
Solaris a longtemp propose un option non documente pour activater un montage asynchrone d'une partition d'UFS, cette option a aujourd'hui disparue.
la seule fois ou j'ai active l'async c'etait pour avoir des perfs sur un serveur nfs et ca tournait super bien jusqu'a ce que je perde 15 go :) je me suis jure de plus mettre mes donnees en async depuis ;)
Les avantages d'un systeme de fichiers journalises sous un peu plus
complexe que ca. Si la majorite des editeurs du marche (IBM, Sun,
Irix, Apple) proposent une journalisation, ce n'est pas pour rien.
ca depend. parfois ils le font pour une raison
technique justifiee (un serveur comportant des
ensembles de disques et plusieurs To de donnees
dont il souhaitent que les donnees soit disponibles
immediatement apres un redemarrage de la machine
pour une quelconque raison) et plus souvent ils
integrent un systeme de journalisation car le
concurrent le fait et qu'il faut l'avoir sinon
le client va suivre la hype du moment et leur
demander "pourquoi vous avez pas la fonction machin
dont parle votre concurrent ?". generalement ce
phenomene se traduit par un changement dans le
nom. par exemple mandrake et redhat dont les
numeros de "versions" gonflaient mais en meme
temps.. ou encore Sony qui etait a la version 4.3
de son ATRAC et qui decide de repasser a ATRAC3
(a ne pas confondre avec ATRAC 3 souligne Sony)
pour que les clients se disent "ya un 3 comme
dans mp3 donc ca doit etre pareil!").
Solaris a longtemp propose un option non documente pour activater un
montage asynchrone d'une partition d'UFS, cette option a aujourd'hui
disparue.
la seule fois ou j'ai active l'async c'etait
pour avoir des perfs sur un serveur nfs et
ca tournait super bien jusqu'a ce que je perde
15 go :) je me suis jure de plus mettre mes
donnees en async depuis ;)
Les avantages d'un systeme de fichiers journalises sous un peu plus complexe que ca. Si la majorite des editeurs du marche (IBM, Sun, Irix, Apple) proposent une journalisation, ce n'est pas pour rien.
ca depend. parfois ils le font pour une raison technique justifiee (un serveur comportant des ensembles de disques et plusieurs To de donnees dont il souhaitent que les donnees soit disponibles immediatement apres un redemarrage de la machine pour une quelconque raison) et plus souvent ils integrent un systeme de journalisation car le concurrent le fait et qu'il faut l'avoir sinon le client va suivre la hype du moment et leur demander "pourquoi vous avez pas la fonction machin dont parle votre concurrent ?". generalement ce phenomene se traduit par un changement dans le nom. par exemple mandrake et redhat dont les numeros de "versions" gonflaient mais en meme temps.. ou encore Sony qui etait a la version 4.3 de son ATRAC et qui decide de repasser a ATRAC3 (a ne pas confondre avec ATRAC 3 souligne Sony) pour que les clients se disent "ya un 3 comme dans mp3 donc ca doit etre pareil!").
Solaris a longtemp propose un option non documente pour activater un montage asynchrone d'une partition d'UFS, cette option a aujourd'hui disparue.
la seule fois ou j'ai active l'async c'etait pour avoir des perfs sur un serveur nfs et ca tournait super bien jusqu'a ce que je perde 15 go :) je me suis jure de plus mettre mes donnees en async depuis ;)
