Message lors d'une mise =C3=A0 jour (postgresql-common) :
Warning: The following devices contain databases and have write
caching enabled: /dev/hda
This could destroy the integrity of your databases in the event of power
failure. Consider disabling the write cache with "hdparm -W 0 <device>".
Message lors d'une mise à jour (postgresql-common) :
Warning: The following devices contain databases and have write caching enabled: /dev/hda This could destroy the integrity of your databases in the event of power failure. Consider disabling the write cache with "hdparm -W 0 <device>".
Message lors d'une mise à jour (postgresql-common) :
Warning: The following devices contain databases and have write
caching enabled: /dev/hda
This could destroy the integrity of your databases in the event of power
failure. Consider disabling the write cache with "hdparm -W 0 <device>".
Message lors d'une mise à jour (postgresql-common) :
Warning: The following devices contain databases and have write caching enabled: /dev/hda This could destroy the integrity of your databases in the event of power failure. Consider disabling the write cache with "hdparm -W 0 <device>".
Warning: The following devices contain databases and have write caching enabled: /dev/hda This could destroy the integrity of your databases in the event of power failure. Consider disabling the write cache with "hdparm -W 0 <device>".
Qu'en pensez-vous ?
Que tu devrais faire comme il dit.
Mais attention à la perte de performance en écriture qui peut résulter de la désactivation du cache d'écriture.
En gros, ton disque dur seble avoir l'écriture différé active. Du coup, même quand l'OS pense que c'est écrit, il se peut que les données ne soient que sur le cache ram du disque dur.
Du coup, en cas de coupure de courant, ben les données s'envolent.
Bof. Le même problème existe de toute façon au niveau supérieur avec les données en attente d'écriture dans le cache de l'OS.
-- Lisez la FAQ de la liste avant de poser une question : http://wiki.debian.net/?DebianFrench Vous pouvez aussi ajouter le mot ``spam'' dans vos champs "From" et "Reply-To:"
To UNSUBSCRIBE, email to with a subject of "unsubscribe". Trouble? Contact
Salut,
François TOURDE a écrit :
Warning: The following devices contain databases and have write
caching enabled: /dev/hda
This could destroy the integrity of your databases in the event of power
failure. Consider disabling the write cache with "hdparm -W 0 <device>".
Qu'en pensez-vous ?
Que tu devrais faire comme il dit.
Mais attention à la perte de performance en écriture qui peut résulter
de la désactivation du cache d'écriture.
En gros, ton disque dur seble avoir l'écriture différé active. Du
coup, même quand l'OS pense que c'est écrit, il se peut que les
données ne soient que sur le cache ram du disque dur.
Du coup, en cas de coupure de courant, ben les données
s'envolent.
Bof. Le même problème existe de toute façon au niveau supérieur avec les
données en attente d'écriture dans le cache de l'OS.
--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.net/?DebianFrench
Vous pouvez aussi ajouter le mot ``spam'' dans vos champs "From" et
"Reply-To:"
To UNSUBSCRIBE, email to debian-user-french-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Warning: The following devices contain databases and have write caching enabled: /dev/hda This could destroy the integrity of your databases in the event of power failure. Consider disabling the write cache with "hdparm -W 0 <device>".
Qu'en pensez-vous ?
Que tu devrais faire comme il dit.
Mais attention à la perte de performance en écriture qui peut résulter de la désactivation du cache d'écriture.
En gros, ton disque dur seble avoir l'écriture différé active. Du coup, même quand l'OS pense que c'est écrit, il se peut que les données ne soient que sur le cache ram du disque dur.
Du coup, en cas de coupure de courant, ben les données s'envolent.
Bof. Le même problème existe de toute façon au niveau supérieur avec les données en attente d'écriture dans le cache de l'OS.
-- Lisez la FAQ de la liste avant de poser une question : http://wiki.debian.net/?DebianFrench Vous pouvez aussi ajouter le mot ``spam'' dans vos champs "From" et "Reply-To:"
To UNSUBSCRIBE, email to with a subject of "unsubscribe". Trouble? Contact
Steve
Le dimanche 1 octobre 2006 19:50, Vanuxem Grégory a écrit :
Le dimanche 01 octobre 2006 à 19:32 +0200, Pascal Hambourg a écrit : > Salut, > > François TOURDE a écrit : > >>Warning: The following devices contain databases and have write > >>caching enabled: /dev/hda > >>This could destroy the integrity of your databases in the event of > >> power failure. Consider disabling the write cache with "hdparm -W 0 > >> <device>". > >> > >>Qu'en pensez-vous ? > > > > Que tu devrais faire comme il dit. > > Mais attention à la perte de performance en écriture qui peut rés ulter > de la désactivation du cache d'écriture. > > > En gros, ton disque dur seble avoir l'écriture différé active. Du > > coup, même quand l'OS pense que c'est écrit, il se peut que les > > données ne soient que sur le cache ram du disque dur. > > > > Du coup, en cas de coupure de courant, ben les données > > s'envolent. > > Bof. Le même problème existe de toute façon au niveau supérieur avec les > données en attente d'écriture dans le cache de l'OS.
Bien que je sois entièrement d'accord avec la perte de performance qui pourrait en résulter, je pense qu'un SGBD doit jouer avec fsync et consort. C'est _vraiment_ leur boulot de s'assurer de l'intégrité des données.
Moralité, je fais quoi ? Je laisse activé en espérant que postgresql fait correctement son boulot (mais alors pourquoi le warning ? un aveu de faiblesse ?) Ou je désactive avec perte de performance (à quantifier encore...) ? Je serai plutôt pour laisser activé, d'autant plus que je n'ai pas des données imperdables (ça se dit ?).
Merci
Greg
-- s°
Le dimanche 1 octobre 2006 19:50, Vanuxem Grégory a écrit :
Le dimanche 01 octobre 2006 à 19:32 +0200, Pascal Hambourg a écrit :
> Salut,
>
> François TOURDE a écrit :
> >>Warning: The following devices contain databases and have write
> >>caching enabled: /dev/hda
> >>This could destroy the integrity of your databases in the event of
> >> power failure. Consider disabling the write cache with "hdparm -W 0
> >> <device>".
> >>
> >>Qu'en pensez-vous ?
> >
> > Que tu devrais faire comme il dit.
>
> Mais attention à la perte de performance en écriture qui peut rés ulter
> de la désactivation du cache d'écriture.
>
> > En gros, ton disque dur seble avoir l'écriture différé active. Du
> > coup, même quand l'OS pense que c'est écrit, il se peut que les
> > données ne soient que sur le cache ram du disque dur.
> >
> > Du coup, en cas de coupure de courant, ben les données
> > s'envolent.
>
> Bof. Le même problème existe de toute façon au niveau supérieur avec les
> données en attente d'écriture dans le cache de l'OS.
Bien que je sois entièrement d'accord avec la perte de performance qui
pourrait en résulter, je pense qu'un SGBD doit jouer avec fsync et
consort. C'est _vraiment_ leur boulot de s'assurer de l'intégrité des
données.
Moralité, je fais quoi ? Je laisse activé en espérant que postgresql fait
correctement son boulot (mais alors pourquoi le warning ? un aveu de
faiblesse ?) Ou je désactive avec perte de performance (à quantifier
encore...) ? Je serai plutôt pour laisser activé, d'autant plus que je n'ai
pas des données imperdables (ça se dit ?).
Le dimanche 1 octobre 2006 19:50, Vanuxem Grégory a écrit :
Le dimanche 01 octobre 2006 à 19:32 +0200, Pascal Hambourg a écrit : > Salut, > > François TOURDE a écrit : > >>Warning: The following devices contain databases and have write > >>caching enabled: /dev/hda > >>This could destroy the integrity of your databases in the event of > >> power failure. Consider disabling the write cache with "hdparm -W 0 > >> <device>". > >> > >>Qu'en pensez-vous ? > > > > Que tu devrais faire comme il dit. > > Mais attention à la perte de performance en écriture qui peut rés ulter > de la désactivation du cache d'écriture. > > > En gros, ton disque dur seble avoir l'écriture différé active. Du > > coup, même quand l'OS pense que c'est écrit, il se peut que les > > données ne soient que sur le cache ram du disque dur. > > > > Du coup, en cas de coupure de courant, ben les données > > s'envolent. > > Bof. Le même problème existe de toute façon au niveau supérieur avec les > données en attente d'écriture dans le cache de l'OS.
Bien que je sois entièrement d'accord avec la perte de performance qui pourrait en résulter, je pense qu'un SGBD doit jouer avec fsync et consort. C'est _vraiment_ leur boulot de s'assurer de l'intégrité des données.
Moralité, je fais quoi ? Je laisse activé en espérant que postgresql fait correctement son boulot (mais alors pourquoi le warning ? un aveu de faiblesse ?) Ou je désactive avec perte de performance (à quantifier encore...) ? Je serai plutôt pour laisser activé, d'autant plus que je n'ai pas des données imperdables (ça se dit ?).
Merci
Greg
-- s°
Vanuxem Grégory
Le dimanche 01 octobre 2006 à 19:32 +0200, Pascal Hambourg a écrit :
Salut,
François TOURDE a écrit : >> >>Warning: The following devices contain databases and have write >>caching enabled: /dev/hda >>This could destroy the integrity of your databases in the event of power >>failure. Consider disabling the write cache with "hdparm -W 0 <device>". >> >>Qu'en pensez-vous ? > > Que tu devrais faire comme il dit.
Mais attention à la perte de performance en écriture qui peut résulter de la désactivation du cache d'écriture.
> En gros, ton disque dur seble avoir l'écriture différé active. Du > coup, même quand l'OS pense que c'est écrit, il se peut que les > données ne soient que sur le cache ram du disque dur. > > Du coup, en cas de coupure de courant, ben les données > s'envolent.
Bof. Le même problème existe de toute façon au niveau supérieur avec les données en attente d'écriture dans le cache de l'OS.
Bien que je sois entièrement d'accord avec la perte de performance qui pourrait en résulter, je pense qu'un SGBD doit jouer avec fsync et consort. C'est _vraiment_ leur boulot de s'assurer de l'intégrité des données.
Greg
-- Lisez la FAQ de la liste avant de poser une question : http://wiki.debian.net/?DebianFrench Vous pouvez aussi ajouter le mot ``spam'' dans vos champs "From" et "Reply-To:"
To UNSUBSCRIBE, email to with a subject of "unsubscribe". Trouble? Contact
Le dimanche 01 octobre 2006 à 19:32 +0200, Pascal Hambourg a écrit :
Salut,
François TOURDE a écrit :
>>
>>Warning: The following devices contain databases and have write
>>caching enabled: /dev/hda
>>This could destroy the integrity of your databases in the event of power
>>failure. Consider disabling the write cache with "hdparm -W 0 <device>".
>>
>>Qu'en pensez-vous ?
>
> Que tu devrais faire comme il dit.
Mais attention à la perte de performance en écriture qui peut résulter
de la désactivation du cache d'écriture.
> En gros, ton disque dur seble avoir l'écriture différé active. Du
> coup, même quand l'OS pense que c'est écrit, il se peut que les
> données ne soient que sur le cache ram du disque dur.
>
> Du coup, en cas de coupure de courant, ben les données
> s'envolent.
Bof. Le même problème existe de toute façon au niveau supérieur avec les
données en attente d'écriture dans le cache de l'OS.
Bien que je sois entièrement d'accord avec la perte de performance qui
pourrait en résulter, je pense qu'un SGBD doit jouer avec fsync et
consort. C'est _vraiment_ leur boulot de s'assurer de l'intégrité des
données.
Greg
--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.net/?DebianFrench
Vous pouvez aussi ajouter le mot ``spam'' dans vos champs "From" et
"Reply-To:"
To UNSUBSCRIBE, email to debian-user-french-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Le dimanche 01 octobre 2006 à 19:32 +0200, Pascal Hambourg a écrit :
Salut,
François TOURDE a écrit : >> >>Warning: The following devices contain databases and have write >>caching enabled: /dev/hda >>This could destroy the integrity of your databases in the event of power >>failure. Consider disabling the write cache with "hdparm -W 0 <device>". >> >>Qu'en pensez-vous ? > > Que tu devrais faire comme il dit.
Mais attention à la perte de performance en écriture qui peut résulter de la désactivation du cache d'écriture.
> En gros, ton disque dur seble avoir l'écriture différé active. Du > coup, même quand l'OS pense que c'est écrit, il se peut que les > données ne soient que sur le cache ram du disque dur. > > Du coup, en cas de coupure de courant, ben les données > s'envolent.
Bof. Le même problème existe de toute façon au niveau supérieur avec les données en attente d'écriture dans le cache de l'OS.
Bien que je sois entièrement d'accord avec la perte de performance qui pourrait en résulter, je pense qu'un SGBD doit jouer avec fsync et consort. C'est _vraiment_ leur boulot de s'assurer de l'intégrité des données.
Greg
-- Lisez la FAQ de la liste avant de poser une question : http://wiki.debian.net/?DebianFrench Vous pouvez aussi ajouter le mot ``spam'' dans vos champs "From" et "Reply-To:"
To UNSUBSCRIBE, email to with a subject of "unsubscribe". Trouble? Contact
Pascal Hambourg
Vanuxem Grégory a écrit :
En gros, ton disque dur seble avoir l'écriture différé active. Du coup, même quand l'OS pense que c'est écrit, il se peut que les données ne soient que sur le cache ram du disque dur.
Du coup, en cas de coupure de courant, ben les données s'envolent.
Bof. Le même problème existe de toute façon au niveau supérieur avec les données en attente d'écriture dans le cache de l'OS.
Bien que je sois entièrement d'accord avec la perte de performance qui pourrait en résulter, je pense qu'un SGBD doit jouer avec fsync et consort. C'est _vraiment_ leur boulot de s'assurer de l'intégrité des données.
Je ne dis pas le contraire. Mais je dis que ni l'OS ni le SGBD ne peuvent rien faire en cas de coupure intempestive de l'alimentation. Si l'interruption se produit au milieu d'une écriture "atomique" pour le SGBD (mais pas pour l'OS ou le disque), les données encore en RAM système en attente d'écriture ne sont pas écrites. Alors que les données dans le cache d'écriture du disque ont une chance d'être enregistrées.
Les seuls cas que je vois où il y a vraiment un intérêt pour l'OS ou l'application de s'assurer de l'écriture effective, c'est pour la gestion de l'alimentation (extinction ou mise en veille [1]) et l'extraction d'un support amovible.
[1] J'ai eu connaissance d'un bug affectant Windows avec certains disques récents ayant un gros cache : à la commande d'extinction, Windows n'attendait pas assez longtemps que les données en cache soient effectivement enregistrées sur le disque avant de couper l'alimentation.
-- Lisez la FAQ de la liste avant de poser une question : http://wiki.debian.net/?DebianFrench Vous pouvez aussi ajouter le mot ``spam'' dans vos champs "From" et "Reply-To:"
To UNSUBSCRIBE, email to with a subject of "unsubscribe". Trouble? Contact
Vanuxem Grégory a écrit :
En gros, ton disque dur seble avoir l'écriture différé active. Du
coup, même quand l'OS pense que c'est écrit, il se peut que les
données ne soient que sur le cache ram du disque dur.
Du coup, en cas de coupure de courant, ben les données
s'envolent.
Bof. Le même problème existe de toute façon au niveau supérieur avec les
données en attente d'écriture dans le cache de l'OS.
Bien que je sois entièrement d'accord avec la perte de performance qui
pourrait en résulter, je pense qu'un SGBD doit jouer avec fsync et
consort. C'est _vraiment_ leur boulot de s'assurer de l'intégrité des
données.
Je ne dis pas le contraire. Mais je dis que ni l'OS ni le SGBD ne
peuvent rien faire en cas de coupure intempestive de l'alimentation. Si
l'interruption se produit au milieu d'une écriture "atomique" pour le
SGBD (mais pas pour l'OS ou le disque), les données encore en RAM
système en attente d'écriture ne sont pas écrites. Alors que les données
dans le cache d'écriture du disque ont une chance d'être enregistrées.
Les seuls cas que je vois où il y a vraiment un intérêt pour l'OS ou
l'application de s'assurer de l'écriture effective, c'est pour la
gestion de l'alimentation (extinction ou mise en veille [1]) et
l'extraction d'un support amovible.
[1] J'ai eu connaissance d'un bug affectant Windows avec certains
disques récents ayant un gros cache : à la commande d'extinction,
Windows n'attendait pas assez longtemps que les données en cache soient
effectivement enregistrées sur le disque avant de couper l'alimentation.
--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.net/?DebianFrench
Vous pouvez aussi ajouter le mot ``spam'' dans vos champs "From" et
"Reply-To:"
To UNSUBSCRIBE, email to debian-user-french-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
En gros, ton disque dur seble avoir l'écriture différé active. Du coup, même quand l'OS pense que c'est écrit, il se peut que les données ne soient que sur le cache ram du disque dur.
Du coup, en cas de coupure de courant, ben les données s'envolent.
Bof. Le même problème existe de toute façon au niveau supérieur avec les données en attente d'écriture dans le cache de l'OS.
Bien que je sois entièrement d'accord avec la perte de performance qui pourrait en résulter, je pense qu'un SGBD doit jouer avec fsync et consort. C'est _vraiment_ leur boulot de s'assurer de l'intégrité des données.
Je ne dis pas le contraire. Mais je dis que ni l'OS ni le SGBD ne peuvent rien faire en cas de coupure intempestive de l'alimentation. Si l'interruption se produit au milieu d'une écriture "atomique" pour le SGBD (mais pas pour l'OS ou le disque), les données encore en RAM système en attente d'écriture ne sont pas écrites. Alors que les données dans le cache d'écriture du disque ont une chance d'être enregistrées.
Les seuls cas que je vois où il y a vraiment un intérêt pour l'OS ou l'application de s'assurer de l'écriture effective, c'est pour la gestion de l'alimentation (extinction ou mise en veille [1]) et l'extraction d'un support amovible.
[1] J'ai eu connaissance d'un bug affectant Windows avec certains disques récents ayant un gros cache : à la commande d'extinction, Windows n'attendait pas assez longtemps que les données en cache soient effectivement enregistrées sur le disque avant de couper l'alimentation.
-- Lisez la FAQ de la liste avant de poser une question : http://wiki.debian.net/?DebianFrench Vous pouvez aussi ajouter le mot ``spam'' dans vos champs "From" et "Reply-To:"
To UNSUBSCRIBE, email to with a subject of "unsubscribe". Trouble? Contact
On Sun, Oct 01, 2006 at 09:53:19PM +0200, François TOURDE wrote:
- Soit c'est important (et PostgreSQL le pense) et dans ce cas le fs te permet de forcer l'écriture
Que se passe-t-il si la coupure de courant arrive à mi-chemin au milieu d'une écriture? Les SGBDs arrivent à se conserver l'homogénéité?
Y.
-- Lisez la FAQ de la liste avant de poser une question : http://wiki.debian.net/?DebianFrench Vous pouvez aussi ajouter le mot ``spam'' dans vos champs "From" et "Reply-To:"
To UNSUBSCRIBE, email to with a subject of "unsubscribe". Trouble? Contact
On Sun, Oct 01, 2006 at 09:53:19PM +0200, François TOURDE wrote:
- Soit c'est important (et PostgreSQL le pense) et dans ce cas le fs
te permet de forcer l'écriture
Que se passe-t-il si la coupure de courant arrive à
mi-chemin au milieu d'une écriture? Les SGBDs arrivent à se
conserver l'homogénéité?
Y.
--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.net/?DebianFrench
Vous pouvez aussi ajouter le mot ``spam'' dans vos champs "From" et
"Reply-To:"
To UNSUBSCRIBE, email to debian-user-french-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
On Sun, Oct 01, 2006 at 09:53:19PM +0200, François TOURDE wrote:
- Soit c'est important (et PostgreSQL le pense) et dans ce cas le fs te permet de forcer l'écriture
Que se passe-t-il si la coupure de courant arrive à mi-chemin au milieu d'une écriture? Les SGBDs arrivent à se conserver l'homogénéité?
Y.
-- Lisez la FAQ de la liste avant de poser une question : http://wiki.debian.net/?DebianFrench Vous pouvez aussi ajouter le mot ``spam'' dans vos champs "From" et "Reply-To:"
To UNSUBSCRIBE, email to with a subject of "unsubscribe". Trouble? Contact
