Re: [HS] erreurs BTRFS [gravité(?)]

[Pierre L.]

Ha ok... merci pour ces précisions...
J'avais toujours cru comprendre que les données ne risquaient
"absolument" rien.

Bon en même temps, si un fichier se trouve dans un coin du disque
flingué, il y a de fortes chances que ce fichier soit à jeter à la
corbeille :s

(désolé pour le croisage de mails...)


Le 11/07/2017 à 00:27, Pascal Hambourg a écrit :
> Le 10/07/2017 à 12:36, Pierre L. a écrit :
>>
>> Petit outil sympa à utiliser en bootant sur une clé usb live par
>> exemple :
>>   badblocks -nvs /dev/sdb
>>
>> Attention tout de même à cette commande, il existe des variantes
>> "destructrices" de données... :s
>> -wvs détruira les données !!!
>> -nvs sera en lecture seule ;)
>
> Non, -n effectue une vérification en lecture-écriture, mais non
> destructrice. C'est beaucoup plus long qu'en lecture seule, et plus
> risqué aussi : si la réécriture se passe mal, les données d'origine
> peuvent être perdues.
>
> Pour la vérification en lecture seule c'est sans -n ni -w.
>




signature.asc
Description: OpenPGP digital signature

Re: [HS] erreurs BTRFS [gravité(?)]

[Pierre L.]

> https://superuser.com/questions/693003/badblocks-vs-smart-extended-self-test
> dont réponse 4 : « The S.M.A.R.T. short and long tests only perform
> (localized) reads of the sectors; it's also non-destructive to the data.
Exact, mais badblocks -nvs est non destructeur aussi ;)
-wvs lui est destructeur !
>   1 To mais ça va prendre des plombes quand même. Au moins, avec le
> test smartctl, je peux continuer à utiliser mon système.
A mon avis en 1 journée c'est fait ;)

Sinon cool la dentiste alors ?? :p

Merci pour les infos :)



signature.asc
Description: OpenPGP digital signature

Re: [HS] erreurs BTRFS [gravité(?)]

[Pascal Hambourg]

Le 10/07/2017 à 12:36, Pierre L. a écrit :


Petit outil sympa à utiliser en bootant sur une clé usb live par exemple :
  badblocks -nvs /dev/sdb

Attention tout de même à cette commande, il existe des variantes
"destructrices" de données... :s
-wvs détruira les données !!!
-nvs sera en lecture seule ;)


Non, -n effectue une vérification en lecture-écriture, mais non 
destructrice. C'est beaucoup plus long qu'en lecture seule, et plus 
risqué aussi : si la réécriture se passe mal, les données d'origine 
peuvent être perdues.


Pour la vérification en lecture seule c'est sans -n ni -w.

Re: [HS] erreurs BTRFS [gravité(?)]

[Alexandre Hoïde]

On Mon, Jul 10, 2017 at 10:42:15PM +0200, Pierre L. wrote:
> 
> >> smartctl ne fait-il pas que lire les infos de SMART inscrites dans la
> >> cervelle du disque dur ?
> >   C'est ce que j'ai lu également, en effet… mais tant qu'à filer la
> > métaphore, je parlerais plutôt de neurones du disque dur ?! ;p
> Quoi de mieux que de demander à ton dentiste si c'est un trou dans la
> dent qui fait mal de temps en temps, ou une autre infection quelconque
> de la gencive ? Mais pour cela, il va bien falloir qu'il jette un oeil
> avec son outil favori, pour être sûr, et ainsi éliminer les hypothèses
> une à une ;)

  Hé hé! Je hais les dentistes, sauf la mienne, qui est fort sympathique
et très belle. Mais au fait, je cite mes sources :
https://superuser.com/questions/693003/badblocks-vs-smart-extended-self-test
dont réponse 4 : « The S.M.A.R.T. short and long tests only perform
(localized) reads of the sectors; it's also non-destructive to the data.
The read data is only transferred to the on-board controller, not to the
host PC. The SATA interface is essentially idle during the test, and the
HDD activity light on the PC should not turn on.

badblocks -vws is requesting a write sector then read & verify
operation. Each write and read adds a disk revolution per operation plus
time for data transfers over the SATA interface plus host PC processing.
The HDD activity light should be on most of the time ».

  Ça sonne plus pro que nos métaphores ^^

> Fichiers corrompus... irrécupérables... sauvegardés dans l'état
> (corrompus)... , et on s'en aperçoit quand on tente de les ré-ouvrir 6
> mois plus tard depuis notre sauvegarde, que notre système favori nous
> insulte car il n'arrive pas à lire le contenu de ce fichier :s
> Bon, certes généralement ce fameux système nous hurle dessus au moment
> de la lecture lors de la sauvegarde... des histoires de I/O sur le disque...
> 
> >   Oui tu as raison. Disons que, si j'étais convaincu que c'est un
> > problème de secteur défectueux, je serais plus motivé.
> C'est vrai que si c'est un 8To, ca peut mettre un certain temps :'((
> Courage!

  1 To mais ça va prendre des plombes quand même. Au moins, avec le
test smartctl, je peux continuer à utiliser mon système.

-- 
 ___
| $ post_tenebras ↲ | waouh!
| GNU\ /|\
|  -- * --  | o
| $ who ↲/ \|_-- ~_|
| Alexandre Hoïde   |  _/| |
 ---

Re: [HS] erreurs BTRFS [gravité(?)]

[Pierre L.]

>> smartctl ne fait-il pas que lire les infos de SMART inscrites dans la
>> cervelle du disque dur ?
>   C'est ce que j'ai lu également, en effet… mais tant qu'à filer la
> métaphore, je parlerais plutôt de neurones du disque dur ?! ;p
Quoi de mieux que de demander à ton dentiste si c'est un trou dans la
dent qui fait mal de temps en temps, ou une autre infection quelconque
de la gencive ? Mais pour cela, il va bien falloir qu'il jette un oeil
avec son outil favori, pour être sûr, et ainsi éliminer les hypothèses
une à une ;)

Fichiers corrompus... irrécupérables... sauvegardés dans l'état
(corrompus)... , et on s'en aperçoit quand on tente de les ré-ouvrir 6
mois plus tard depuis notre sauvegarde, que notre système favori nous
insulte car il n'arrive pas à lire le contenu de ce fichier :s
Bon, certes généralement ce fameux système nous hurle dessus au moment
de la lecture lors de la sauvegarde... des histoires de I/O sur le disque...

>   Oui tu as raison. Disons que, si j'étais convaincu que c'est un
> problème de secteur défectueux, je serais plus motivé.
C'est vrai que si c'est un 8To, ca peut mettre un certain temps :'((
Courage!



signature.asc
Description: OpenPGP digital signature

Re: [HS] erreurs BTRFS [gravité(?)]

[Alexandre Hoïde]

On Mon, Jul 10, 2017 at 04:00:35PM +0200, Pierre L. wrote:
> smartctl ne fait-il pas que lire les infos de SMART inscrites dans la
> cervelle du disque dur ?

  C'est ce que j'ai lu également, en effet… mais tant qu'à filer la
métaphore, je parlerais plutôt de neurones du disque dur ?! ;p

> Rah, une bonne vieille analyse physique pendant la nuit (ou plutot
> pendant que tu n'utilises pas ton ordi... que tu dors... si ca arrive ;p )
> je pense que c'est nettement plus fiable que les données SMART ?
> Ou sinon si tu connais UltimateBootCD, avec quelques bons outils pour
> vérifier la surface de ton disque, selon la marque...
> Mais oui, ca prend du temps !
> Ceci dit, ca prend aussi du temps de tout réinstaller tout beau tout
> propre, sur un beau disque tout neuf parce que l'ancien était déglingué...

  Oui tu as raison. Disons que, si j'étais convaincu que c'est un
problème de secteur défectueux, je serais plus motivé. En outre, au
risque de me répéter, il ne s'agit pas du disque sur lequel se trouve la
partition racine (logée, elle, sur un SSD). Donc, pas de réinstallation
à redouter… uniquement des années de données personnelles sur la
partition /home…

  … mais nn, je les ai sauvegardées ! Paresseux mais pas téméraire.

  \o/

-- 
 ___
| $ post_tenebras ↲ | waouh!
| GNU\ /|\
|  -- * --  | o
| $ who ↲/ \|_-- ~_|
| Alexandre Hoïde   |  _/| |
 ---

Re: [HS] erreurs BTRFS [gravité(?)]

[Alexandre Hoïde]

On Mon, Jul 10, 2017 at 02:55:23PM +0200, maderios wrote:
> >C'est juste que ça prend quand même un peu de temps pour copier, et
> > que je suis un gros paresseux ^^ (et que, accessoirement, mes plages de
> > disponibilité sont très courtes) J'essaierai ça quand le
> > « smartctl -t long » que je viens de lancer sera terminé.
> >   Je vous tiens au jus !
> > 
> En tant que grand fainéant, j'utilise MC (midnight-commander) pour copier
> (entre autres). Cela évite bien des erreurs et on gagne un temps fou.
> 


  Bin… faudrait faire un concours fainéant+MC contre paresseux+rsync.
Que le plus tire-au-flanc l'emporte ! ;-)

  Ceci dit, je décide de reporter le transfert sur ext4 à plus tard. Je
préfère éviter de multiplier les changements, ce qui réduirait à néant
l'espoir -- que je nourris encore -- de comprendre la cause du problème.

  Je vais d'abord enquêter sur les options de mise en veille des disques
dur et, le cas échéant, essayer de les modifier pour voir si ma
suspicion actuelle se vérifie.

-- 
 ___
| $ post_tenebras ↲ | waouh!
| GNU\ /|\
|  -- * --  | o
| $ who ↲/ \|_-- ~_|
| Alexandre Hoïde   |  _/| |
 ---

Re: [HS] erreurs BTRFS [gravité(?)]

[Pierre L.]

smartctl ne fait-il pas que lire les infos de SMART inscrites dans la
cervelle du disque dur ?

Rah, une bonne vieille analyse physique pendant la nuit (ou plutot
pendant que tu n'utilises pas ton ordi... que tu dors... si ca arrive ;p )
je pense que c'est nettement plus fiable que les données SMART ?
Ou sinon si tu connais UltimateBootCD, avec quelques bons outils pour
vérifier la surface de ton disque, selon la marque...
Mais oui, ca prend du temps !
Ceci dit, ca prend aussi du temps de tout réinstaller tout beau tout
propre, sur un beau disque tout neuf parce que l'ancien était déglingué...

Bon courage ;)



Le 10/07/2017 à 13:23, Alexandre Hoïde a écrit :
>   le test smartctl également. Encore que… mais la durée
> d'un test badblocks me pose problème.



signature.asc
Description: OpenPGP digital signature

Re: [HS] erreurs BTRFS [gravité(?)]

[maderios]

On 07/10/2017 02:48 PM, Alexandre Hoïde wrote:

On Mon, Jul 10, 2017 at 02:37:22PM +0200, maderios wrote:

On 07/09/2017 07:02 PM, Alexandre Hoïde wrote:

On Sun, Jul 09, 2017 at 04:47:21PM +0200, maderios wrote:

On 07/09/2017 01:47 PM, Alexandre Hoïde wrote:


 Je suppose qu'il faudra que j'en passe par le SAV Lenovo… en espérant
que les messages d'erreur du noyau leur suffiront.



Salut
Je ne connais pas toute l'histoire et donc, je me trompe peut-être.
Avant d'envisager le SAV, pourquoi ne pas formater avec un système de
fichier éprouvé comme ext4 et réinstaller? BTRFS est encore bien jeune donc
question fiabilité, ce n'est pas le top...



Salut Madeiros, merci pour ta suggestion.

Les premiers messages (…ata4.00…), avant ceux qui mentionnent BTRFS,
me suggèrent (peut-être à tort) que ce qui déclenche le problème est à
un plus bas niveau que celui du système de fichier… mais, en l'absence
de certitude, ton idée se défent ! J'vais p'têtre lui faire ça, à ma
partoche.



Même pas besoin de réinstaller sur la nouvelle partition, il suffit d'y
copier la sauvegarde, d'éditer le fstab, de  changer les uuid, de faire un
update-grub, de rebooter et de croiser les doigts...


   Re et merci encore pour ton aide Maderios,

   Oui, cette partie ne me pose pas de problème, d'autant moins qu'il
ne s'agit pas de la partition racine, mais de la partition /home.

   C'est juste que ça prend quand même un peu de temps pour copier, et
que je suis un gros paresseux ^^ (et que, accessoirement, mes plages de
disponibilité sont très courtes) J'essaierai ça quand le
« smartctl -t long » que je viens de lancer sera terminé.
  
  Je vous tiens au jus !


En tant que grand fainéant, j'utilise MC (midnight-commander) pour 
copier (entre autres). Cela évite bien des erreurs et on gagne un temps fou.


--
Maderios

Re: [HS] erreurs BTRFS [gravité(?)]

[Alexandre Hoïde]

On Mon, Jul 10, 2017 at 02:37:22PM +0200, maderios wrote:
> On 07/09/2017 07:02 PM, Alexandre Hoïde wrote:
> > On Sun, Jul 09, 2017 at 04:47:21PM +0200, maderios wrote:
> > > On 07/09/2017 01:47 PM, Alexandre Hoïde wrote:
> > > 
> > > > Je suppose qu'il faudra que j'en passe par le SAV Lenovo… en 
> > > > espérant
> > > > que les messages d'erreur du noyau leur suffiront.
> > > > 
> > > 
> > > Salut
> > > Je ne connais pas toute l'histoire et donc, je me trompe peut-être.
> > > Avant d'envisager le SAV, pourquoi ne pas formater avec un système de
> > > fichier éprouvé comme ext4 et réinstaller? BTRFS est encore bien jeune 
> > > donc
> > > question fiabilité, ce n'est pas le top...
> > > 
> > 
> >Salut Madeiros, merci pour ta suggestion.
> > 
> >Les premiers messages (…ata4.00…), avant ceux qui mentionnent BTRFS,
> > me suggèrent (peut-être à tort) que ce qui déclenche le problème est à
> > un plus bas niveau que celui du système de fichier… mais, en l'absence
> > de certitude, ton idée se défent ! J'vais p'têtre lui faire ça, à ma
> > partoche.
> > 
> 
> Même pas besoin de réinstaller sur la nouvelle partition, il suffit d'y
> copier la sauvegarde, d'éditer le fstab, de  changer les uuid, de faire un
> update-grub, de rebooter et de croiser les doigts...

  Re et merci encore pour ton aide Maderios,

  Oui, cette partie ne me pose pas de problème, d'autant moins qu'il
ne s'agit pas de la partition racine, mais de la partition /home.

  C'est juste que ça prend quand même un peu de temps pour copier, et
que je suis un gros paresseux ^^ (et que, accessoirement, mes plages de
disponibilité sont très courtes) J'essaierai ça quand le
« smartctl -t long » que je viens de lancer sera terminé.
 
 Je vous tiens au jus !

-- 
 ___
| $ post_tenebras ↲ | waouh!
| GNU\ /|\
|  -- * --  | o
| $ who ↲/ \|_-- ~_|
| Alexandre Hoïde   |  _/| |
 ---

Re: [HS] erreurs BTRFS [gravité(?)]

[maderios]

On 07/09/2017 07:02 PM, Alexandre Hoïde wrote:

On Sun, Jul 09, 2017 at 04:47:21PM +0200, maderios wrote:

On 07/09/2017 01:47 PM, Alexandre Hoïde wrote:


Je suppose qu'il faudra que j'en passe par le SAV Lenovo… en espérant
que les messages d'erreur du noyau leur suffiront.



Salut
Je ne connais pas toute l'histoire et donc, je me trompe peut-être.
Avant d'envisager le SAV, pourquoi ne pas formater avec un système de
fichier éprouvé comme ext4 et réinstaller? BTRFS est encore bien jeune donc
question fiabilité, ce n'est pas le top...



   Salut Madeiros, merci pour ta suggestion.

   Les premiers messages (…ata4.00…), avant ceux qui mentionnent BTRFS,
me suggèrent (peut-être à tort) que ce qui déclenche le problème est à
un plus bas niveau que celui du système de fichier… mais, en l'absence
de certitude, ton idée se défent ! J'vais p'têtre lui faire ça, à ma
partoche.



Même pas besoin de réinstaller sur la nouvelle partition, il suffit d'y 
copier la sauvegarde, d'éditer le fstab, de  changer les uuid, de faire 
un update-grub, de rebooter et de croiser les doigts...


--
Maderios

Re: [HS] erreurs BTRFS [gravité(?)]

[Alexandre Hoïde]

On Mon, Jul 10, 2017 at 12:59:10PM +0200, Thierry Bugier Pineau wrote:
> Bonjour,
> 
> Pour compléter, vu que je suis dans ce sujet pour changer les disques de ma 
> grappe RAID, il est aussi possible de lire les informations de santé du 
> disque dur avec smartmontools
> 
> Smartctl -a /dev/sda
> 
> Sait on jamais
> 

  Salut Thierry et merci à toi également.

  J'avais déjà fait un « # smartctl -t long /dev/sda » après le premier
incident, qui n'avait pas révélé de problème. Faudra que j'en refasse
un, pour être sûr, en effet.

  Meilleures salutations,

-- 
 ___
| $ post_tenebras ↲ | waouh!
| GNU\ /|\
|  -- * --  | o
| $ who ↲/ \|_-- ~_|
| Alexandre Hoïde   |  _/| |
 ---

Re: [HS] erreurs BTRFS [gravité(?)]

[Alexandre Hoïde]

On Mon, Jul 10, 2017 at 12:36:18PM +0200, Pierre L. wrote:
> Salut,
> as-tu déjà tenté une petite analyse des clusters de ton disque dur ?
> Histoire de voir s'il n'y en a pas quelques uns défectueux ?
> (peut-être suis-je total hors-sujet avec cette proposition, si on
> déchiffre la chinoiserie des logs...! ne me tirez pas les oreilles !)
> 
> Petit outil sympa à utiliser en bootant sur une clé usb live par exemple :
>  badblocks -nvs /dev/sdb
> 
> Attention tout de même à cette commande, il existe des variantes
> "destructrices" de données... :s
> -wvs détruira les données !!!
> -nvs sera en lecture seule ;)
> /dev/sdb sera ton disque dur, trouvé avec la commande fdisk -l
> 
> En espérant que ca puisse filer un petit coup de main ;)

  Salut Pierre et merci pour ton message.

  Parce que, il me semble que si c'était un problème de « cluster », le
test BTRFS me l'aurait signalé et que si c'était un problème de
« secteur », le test smartctl également. Encore que… mais la durée
d'un test badblocks me pose problème. J'ai besoin de mon ordi quoi ! ^^
Je garde la suggestion en réserve, ainsi que celle de Maderios, si
les hypothèses plus faciles à tester ne donnent rien. À ce stade, j'ai
l'impression que la température élevée n'était qu'une coïncidence et
qu'il pourrait s'agir d'un problème lié à une sortie de veille.

  Merci encore et meilleures salutations.


PS J'en profite pour « s/défent/défend/g » :
On Sun, Jul 09, 2017 at 07:02:01PM +0200, Alexandre Hoïde wrote:
> […] ton idée se défent ! […]

Aah, ça faid du bien !

-- 
 ___
| $ post_tenebras ↲ | waouh!
| GNU\ /|\
|  -- * --  | o
| $ who ↲/ \|_-- ~_|
| Alexandre Hoïde   |  _/| |
 ---

Re: [HS] erreurs BTRFS [gravité(?)]

[Thierry Bugier Pineau]

Bonjour,

Pour compléter, vu que je suis dans ce sujet pour changer les disques de ma 
grappe RAID, il est aussi possible de lire les informations de santé du disque 
dur avec smartmontools

Smartctl -a /dev/sda

Sait on jamais

Le 10 juillet 2017 12:36:18 GMT+02:00, "Pierre L."  a 
écrit :
>Salut,
>as-tu déjà tenté une petite analyse des clusters de ton disque dur ?
>Histoire de voir s'il n'y en a pas quelques uns défectueux ?
>(peut-être suis-je total hors-sujet avec cette proposition, si on
>déchiffre la chinoiserie des logs...! ne me tirez pas les oreilles !)
>
>Petit outil sympa à utiliser en bootant sur une clé usb live par
>exemple :
> badblocks -nvs /dev/sdb
>
>Attention tout de même à cette commande, il existe des variantes
>"destructrices" de données... :s
>-wvs détruira les données !!!
>-nvs sera en lecture seule ;)
>/dev/sdb sera ton disque dur, trouvé avec la commande fdisk -l
>
>En espérant que ca puisse filer un petit coup de main ;)

-- 
Envoyé de mon appareil Android avec Courriel K-9 Mail. Veuillez excuser ma 
brièveté.

Re: [HS] erreurs BTRFS [gravité(?)]

[Pierre L.]

Salut,
as-tu déjà tenté une petite analyse des clusters de ton disque dur ?
Histoire de voir s'il n'y en a pas quelques uns défectueux ?
(peut-être suis-je total hors-sujet avec cette proposition, si on
déchiffre la chinoiserie des logs...! ne me tirez pas les oreilles !)

Petit outil sympa à utiliser en bootant sur une clé usb live par exemple :
 badblocks -nvs /dev/sdb

Attention tout de même à cette commande, il existe des variantes
"destructrices" de données... :s
-wvs détruira les données !!!
-nvs sera en lecture seule ;)
/dev/sdb sera ton disque dur, trouvé avec la commande fdisk -l

En espérant que ca puisse filer un petit coup de main ;)



signature.asc
Description: OpenPGP digital signature

Re: [HS] erreurs BTRFS [gravité(?)]

[Alexandre Hoïde]

On Sun, Jul 09, 2017 at 04:47:21PM +0200, maderios wrote:
> On 07/09/2017 01:47 PM, Alexandre Hoïde wrote:
> 
> >Je suppose qu'il faudra que j'en passe par le SAV Lenovo… en espérant
> > que les messages d'erreur du noyau leur suffiront.
> > 
> 
> Salut
> Je ne connais pas toute l'histoire et donc, je me trompe peut-être.
> Avant d'envisager le SAV, pourquoi ne pas formater avec un système de
> fichier éprouvé comme ext4 et réinstaller? BTRFS est encore bien jeune donc
> question fiabilité, ce n'est pas le top...
> 

  Salut Madeiros, merci pour ta suggestion.

  Les premiers messages (…ata4.00…), avant ceux qui mentionnent BTRFS,
me suggèrent (peut-être à tort) que ce qui déclenche le problème est à
un plus bas niveau que celui du système de fichier… mais, en l'absence
de certitude, ton idée se défent ! J'vais p'têtre lui faire ça, à ma
partoche.

  Meilleures salutations,

-- 
 ___
| $ post_tenebras ↲ | waouh!
| GNU\ /|\
|  -- * --  | o
| $ who ↲/ \|_-- ~_|
| Alexandre Hoïde   |  _/| |
 ---

Re: [HS] erreurs BTRFS [gravité(?)]

[maderios]

On 07/09/2017 01:47 PM, Alexandre Hoïde wrote:


   Je suppose qu'il faudra que j'en passe par le SAV Lenovo… en espérant
que les messages d'erreur du noyau leur suffiront.



Salut
Je ne connais pas toute l'histoire et donc, je me trompe peut-être.
Avant d'envisager le SAV, pourquoi ne pas formater avec un système de 
fichier éprouvé comme ext4 et réinstaller? BTRFS est encore bien jeune 
donc question fiabilité, ce n'est pas le top...


--
Maderios

Re: [HS] erreurs BTRFS [gravité(?)]

[Alexandre Hoïde]

On Tue, Jun 27, 2017 at 12:49:06PM +0200, Alexandre Hoïde wrote:
>   Les premières erreurs sont :
> «
> jun 22 15:11:51 lenlap kernel: ata4.00: exception Emask 0x0 SAct 0x3f000 SErr 
> 0x5 action 0x6 frozen
> jun 22 15:11:51 lenlap kernel: ata4: SError: { PHYRdyChg CommWake }
> jun 22 15:11:51 lenlap kernel: ata4.00: failed command: WRITE FPDMA QUEUED
> jun 22 15:11:51 lenlap kernel: ata4.00: cmd 
> 61/00:60:c8:82:8c/02:00:10:00:00/40 tag 12 ncq dma 262144 out
> […] »
> 
>   Suivies par des dizaines de :
> «
> Jun 22 15:12:02 lenlap kernel: [ 4159.268019] BTRFS error (device sda4): bdev 
> /dev/sda4 errs: wr 1, rd 0, flush 0, corrupt 0, gen 0
> »

  Rebelote : 8 juillet, même enchaînement d'erreurs, sans conséquences
apparentes après redémarrage du système (bien que je n'aie pas encore
exécuté de test smartctl). Température extérieure, sur le moment, 32°C,
température processeur (« tlp-stat | grep temp ») 34°C -- qui m'a laissé
perplexe, étant donné qu'actuellement la température externe est de 28°C
et le processeur donné à 53°C… mais je ne me rappelle pas si je venais
de le sortir de veille).

  Défaillance matérielle, bug du micrologiciel, incompatibilité ou bug
avec le noyau… mystère !

  Je suppose qu'il faudra que j'en passe par le SAV Lenovo… en espérant
que les messages d'erreur du noyau leur suffiront.

  Je joins le nouveau log, pour référence.

PS ce message me sert de suivi. À moins que ces logs ne vous parlent et
que vous soyez désireux de me les traduire, vous prenez pas la tête ;-)

-- 
 ___
| $ post_tenebras ↲ | waouh!
| GNU\ /|\
|  -- * --  | o
| $ who ↲/ \|_-- ~_|
| Alexandre Hoïde   |  _/| |
 ---
-- Logs begin at Wed 2017-06-14 17:58:54 CEST, end at Sun 2017-07-09 13:05:20 
CEST. --
jui 08 13:59:29 lenlap kernel: ata4.00: exception Emask 0x0 SAct 0xc0 SErr 
0x5 action 0x6 frozen
jui 08 13:59:29 lenlap kernel: ata4: SError: { PHYRdyChg CommWake }
jui 08 13:59:29 lenlap kernel: ata4.00: failed command: WRITE FPDMA QUEUED
jui 08 13:59:29 lenlap kernel: ata4.00: cmd 61/18:30:70:57:86/00:00:10:00:00/40 
tag 6 ncq dma 12288 out
res 40/00:80:00:00:00/00:00:00:00:00/40 
Emask 0x4 (timeout)
jui 08 13:59:29 lenlap kernel: ata4.00: status: { DRDY }
jui 08 13:59:29 lenlap kernel: ata4.00: failed command: WRITE FPDMA QUEUED
jui 08 13:59:29 lenlap kernel: ata4.00: cmd 61/08:38:a8:cd:93/00:00:09:00:00/40 
tag 7 ncq dma 4096 out
res 40/00:00:00:00:00/00:00:00:00:00/40 
Emask 0x4 (timeout)
jui 08 13:59:29 lenlap kernel: ata4.00: status: { DRDY }
jui 08 13:59:39 lenlap kernel: ata4: COMRESET failed (errno=-16)
jui 08 13:59:49 lenlap kernel: ata4: COMRESET failed (errno=-16)
jui 08 14:00:24 lenlap kernel: ata4: COMRESET failed (errno=-16)
jui 08 14:00:29 lenlap kernel: ata4: COMRESET failed (errno=-16)
jui 08 14:00:29 lenlap kernel: ata4: reset failed, giving up
jui 08 14:00:29 lenlap kernel: blk_update_request: I/O error, dev sda, sector 
160681384
jui 08 14:00:29 lenlap kernel: BTRFS error (device sda4): bdev /dev/sda4 errs: 
wr 1, rd 0, flush 0, corrupt 0, gen 0
jui 08 14:00:29 lenlap kernel: blk_update_request: I/O error, dev sda, sector 
277239664
jui 08 14:00:29 lenlap kernel: BTRFS error (device sda4): bdev /dev/sda4 errs: 
wr 2, rd 0, flush 0, corrupt 0, gen 0
jui 08 14:00:29 lenlap kernel: blk_update_request: I/O error, dev sda, sector 
277338032
jui 08 14:00:29 lenlap kernel: BTRFS error (device sda4): bdev /dev/sda4 errs: 
wr 3, rd 0, flush 0, corrupt 0, gen 0
jui 08 14:00:29 lenlap kernel: blk_update_request: I/O error, dev sda, sector 
277354120
jui 08 14:00:29 lenlap kernel: BTRFS error (device sda4): bdev /dev/sda4 errs: 
wr 4, rd 0, flush 0, corrupt 0, gen 0
jui 08 14:00:29 lenlap kernel: blk_update_request: I/O error, dev sda, sector 
276799584
jui 08 14:00:29 lenlap kernel: BTRFS error (device sda4): bdev /dev/sda4 errs: 
wr 5, rd 0, flush 0, corrupt 0, gen 0
jui 08 14:00:29 lenlap kernel: blk_update_request: I/O error, dev sda, sector 
277170896
jui 08 14:00:29 lenlap kernel: BTRFS error (device sda4): bdev /dev/sda4 errs: 
wr 6, rd 0, flush 0, corrupt 0, gen 0
jui 08 14:00:29 lenlap kernel: blk_update_request: I/O error, dev sda, sector 
277173920
jui 08 14:00:29 lenlap kernel: BTRFS error (device sda4): bdev /dev/sda4 errs: 
wr 7, rd 0, flush 0, corrupt 0, gen 0
jui 08 14:00:29 lenlap kernel: blk_update_request: I/O error, dev sda, sector 
277198496
jui 08 14:00:29 lenlap kernel: BTRFS error (device sda4): bdev /dev/sda4 errs: 
wr 8, rd 0, flush 0, corrupt 0, gen 0
jui 08 14:00:29 lenlap kernel: blk_update_request: I/O error, dev sda, sector 
277210136
jui 08 14:00:29 lenlap kernel: BTRFS error (device sda4): bdev /dev/sda4 errs: 
wr 9, rd 0, flush 0, corrupt 0, gen 0
jui 08 14:00:29 lenlap kernel: blk_update_request: I/O error, dev sda, sector 
277225192
jui 08 14:00:29 lenlap kernel: BTRFS error (device sda4): bdev /dev/sda4 errs: 

Re: [HS] erreurs BTRFS [gravité(?)]

[Christophe Moille]

Le mercredi 28 juin 2017 à 09:16:45 (+0200), Daniel Caillibaud a écrit :
> Le 27/06/17 à 12:49, Alexandre Hoïde  a écrit :
> 
> En tout cas, vu que tous les checks ultérieurs montrent qu'il n'y a pas de 
> pbs je
> m'inquiéterait pas trop, sinon vérifier la température cpu / disque par 
> rapport à la
> température ambiante, tu as peu être un refroidissement un peu faible par 
> fortes chaleurs,
> mais sur un portable tu peux pas vraiment ajouter de ventilos.
> 
> Si le portable est très récent, ça doit pas être de la poussière, peut-être 
> simplement une
> miniaturisation qui pénalise un peu le refroidissement, je crains que tu ne 
> puisse pas y faire
> grand chose (sinon vérifier que y'a rien qui gène devant les sorties d'air).
> 

J'ai eu un autre retour d'expérience pour un portable qui chauffait
beaucoup alors qu'il n'y avait pas de poussière pour géner le flux
d'air. 
En changeant la pate thermique du processeur, il a été gagné plus de 10
degrés sur la température du proc. En l'occurrence, ça devrait permettre
également de gagner du refroidissement sur le reste de la machine.

-- 
Anti­méthodologie
de
projet
:
«
On
passe
son
temps
à
dire
ce
que
l’on
fait
mais

nous
n’avons
plus
le
temps
de
faire
ce
que
l’on
dit
!


signature.asc
Description: Digital signature

Re: [HS] erreurs BTRFS [gravité(?)]

[Daniel Caillibaud]

Le 27/06/17 à 12:49, Alexandre Hoïde  a écrit :
AH>   Je ne comprends pas ce qui c'est passé et je ne sais pas si cela
AH> devrait m'inquiéter. Si quelqu'un y voit plus clair que moi, dans cette
AH> série d'erreurs [sans conséquences apparentes] je serais preneur. 

Je suis pas expert, mais c'est pas forcément le disque ou le filesystem, ça 
peut être le
contrôleur disque qui a eu chaud et s'est mis à déconner.

En tout cas, vu que tous les checks ultérieurs montrent qu'il n'y a pas de pbs 
je
m'inquiéterait pas trop, sinon vérifier la température cpu / disque par rapport 
à la
température ambiante, tu as peu être un refroidissement un peu faible par 
fortes chaleurs,
mais sur un portable tu peux pas vraiment ajouter de ventilos.

Si le portable est très récent, ça doit pas être de la poussière, peut-être 
simplement une
miniaturisation qui pénalise un peu le refroidissement, je crains que tu ne 
puisse pas y faire
grand chose (sinon vérifier que y'a rien qui gène devant les sorties d'air).

-- 
Daniel

Un chien vaut mieux que deux kilos de rats

[HS] erreurs BTRFS [gravité(?)]

[Alexandre Hoïde]

  Bonjour à tous.
  
  Le 22 juin, il faisait près de 35°C chez moi, et j'ai eu plusieurs
messages d'erreur BTRFS sur la partition « home » (en /dev/sda4, voir
ci-dessous). Dans le même temps, thunderbird n'arrivait plus à lister
les messages dans les dossiers de mes comptes IMAP. J'ai éteint l'ordi
et ne l'ai rallumé qu'un jour plus tard, à une température externe moins
élevée : depuis, il n'y a plus eu aucun problème ni message d'erreur.

  « btrfs check /dev/sda4 » (partition démontée) ne donne aucune
erreur et « smartctl -t long /dev/sda » (durée environ 3h) non plus.

  Les premières erreurs sont :
«
jun 22 15:11:51 lenlap kernel: ata4.00: exception Emask 0x0 SAct 0x3f000 SErr 
0x5 action 0x6 frozen
jun 22 15:11:51 lenlap kernel: ata4: SError: { PHYRdyChg CommWake }
jun 22 15:11:51 lenlap kernel: ata4.00: failed command: WRITE FPDMA QUEUED
jun 22 15:11:51 lenlap kernel: ata4.00: cmd 61/00:60:c8:82:8c/02:00:10:00:00/40 
tag 12 ncq dma 262144 out
[…] »

  Suivies par des dizaines de :
«
Jun 22 15:12:02 lenlap kernel: [ 4159.268019] BTRFS error (device sda4): bdev 
/dev/sda4 errs: wr 1, rd 0, flush 0, corrupt 0, gen 0
»

  Je ne comprends pas ce qui c'est passé et je ne sais pas si cela
devrait m'inquiéter. Si quelqu'un y voit plus clair que moi, dans cette
série d'erreurs [sans conséquences apparentes] je serais preneur. 
(Le portable n'a que quelques semaines.  Accessoirement, le sda est le
disque secondaire, le primaire étant un ssd pcie-nvme)

  Au cas où, je joins à ce message :
* la sortie de « journalctl --system --since "2017-06-22" --until "2017-06-23" 
-p 3 »
  (expurgée) ;
* la sortie de « smartctl -a /dev/sda »
* la sortie de « btrfs check /dev/sda4 »

  Merci d'avance pour vos éventuels éclairages,

-- 
 ___
| $ post_tenebras ↲ | waouh!
| GNU\ /|\
|  -- * --  | o
| $ who ↲/ \|_-- ~_|
| Alexandre Hoïde   |  _/| |
 ---
-- Logs begin at Wed 2017-06-14 13:05:31 CEST, end at Sun 2017-06-25 21:54:03 
CEST. --
jun 22 15:11:51 lenlap kernel: ata4.00: exception Emask 0x0 SAct 0x3f000 SErr 
0x5 action 0x6 frozen
jun 22 15:11:51 lenlap kernel: ata4: SError: { PHYRdyChg CommWake }
jun 22 15:11:51 lenlap kernel: ata4.00: failed command: WRITE FPDMA QUEUED
jun 22 15:11:51 lenlap kernel: ata4.00: cmd 61/00:60:c8:82:8c/02:00:10:00:00/40 
tag 12 ncq dma 262144 out
res 40/00:00:00:00:00/00:00:00:00:00/00 
Emask 0x4 (timeout)
jun 22 15:11:51 lenlap kernel: ata4.00: status: { DRDY }
jun 22 15:11:51 lenlap kernel: ata4.00: failed command: WRITE FPDMA QUEUED
jun 22 15:11:51 lenlap kernel: ata4.00: cmd 61/00:68:c8:c9:8c/02:00:10:00:00/40 
tag 13 ncq dma 262144 out
res 40/00:00:00:00:00/00:00:00:00:00/00 
Emask 0x4 (timeout)
jun 22 15:11:51 lenlap kernel: ata4.00: status: { DRDY }
jun 22 15:11:51 lenlap kernel: ata4.00: failed command: WRITE FPDMA QUEUED
jun 22 15:11:51 lenlap kernel: ata4.00: cmd 61/00:70:c8:d1:8c/02:00:10:00:00/40 
tag 14 ncq dma 262144 out
res 40/00:00:00:00:00/00:00:00:00:00/40 
Emask 0x4 (timeout)
jun 22 15:11:51 lenlap kernel: ata4.00: status: { DRDY }
jun 22 15:11:51 lenlap kernel: ata4.00: failed command: WRITE FPDMA QUEUED
jun 22 15:11:51 lenlap kernel: ata4.00: cmd 61/00:78:40:b3:8d/02:00:10:00:00/40 
tag 15 ncq dma 262144 out
res 40/00:00:00:00:00/00:00:00:00:00/00 
Emask 0x4 (timeout)
jun 22 15:11:51 lenlap kernel: ata4.00: status: { DRDY }
jun 22 15:11:51 lenlap kernel: ata4.00: failed command: WRITE FPDMA QUEUED
jun 22 15:11:51 lenlap kernel: ata4.00: cmd 61/00:80:98:0b:8e/02:00:10:00:00/40 
tag 16 ncq dma 262144 out
res 40/00:00:00:00:00/00:00:00:00:00/40 
Emask 0x4 (timeout)
jun 22 15:11:51 lenlap kernel: ata4.00: status: { DRDY }
jun 22 15:11:51 lenlap kernel: ata4.00: failed command: WRITE FPDMA QUEUED
jun 22 15:11:51 lenlap kernel: ata4.00: cmd 61/00:88:28:10:8e/02:00:10:00:00/40 
tag 17 ncq dma 262144 out
res 40/00:00:06:4f:c2/00:00:00:00:00/00 
Emask 0x4 (timeout)
jun 22 15:11:51 lenlap kernel: ata4.00: status: { DRDY }
jun 22 15:12:02 lenlap kernel: blk_update_request: I/O error, dev sda, sector 
277643976
jun 22 15:12:02 lenlap kernel: BTRFS error (device sda4): bdev /dev/sda4 errs: 
wr 1, rd 0, flush 0, corrupt 0, gen 0
jun 22 15:12:02 lenlap kernel: blk_update_request: I/O error, dev sda, sector 
277662152
jun 22 15:12:02 lenlap kernel: BTRFS error (device sda4): bdev /dev/sda4 errs: 
wr 2, rd 0, flush 0, corrupt 0, gen 0
jun 22 15:12:02 lenlap kernel: blk_update_request: I/O error, dev sda, sector 
277664200
jun 22 15:12:02 lenlap kernel: BTRFS error (device sda4): bdev /dev/sda4 errs: 
wr 3, rd 0, flush 0, corrupt 0, gen 0
jun 22 15:12:02 lenlap kernel: blk_update_request: I/O error, dev sda, sector 
277721920
jun 22 15:12:02 lenlap kernel: BTRFS error (device