Re: Una de discs durs

2021-03-04 Conversa Toni Mas Soler
Sembla que la cosa s'ha arreglat.
El problema radicava al cable d'alimentació. Amb la mateixa font, canviat de 
cable no han aparegut més errors.

Gràcies a tots per la vostra aportació. Tingueu present el cas per si en un 
futur us passa.

Toni Mas
GPG 3F42A21D84D7E950

Sent with ProtonMail Secure Email.

‐‐‐ Original Message ‐‐‐
En dissabte 27 de febrer de 2021 a les 13:56, Toni Mas Soler 
 va escriure:

> He permutat ports (per 2A vegada)
> He canviat el cable (per 3a vegada)
> I, novetat, he canviat el cable de corrent per un altre.
> 

> Si això no funciona, miraré aquestes eines de diagnòstic a veure si em diuen 
> algo mes.
> 

> Gràcies 
> 

> Sent from ProtonMail Mobile
> 

> Actiu dl, febr 22, 2021 a 12:27, Alex Muntada  va escriure:
> 

> > Hola Toni
> > 

> > > M'agradaria entendre el diagnòstic. Aquests valors que emfatitzes
> > > són (aprox) així des del primer dia. Podria ser que estiguéssin
> > > vinculats a la marca?
> > 

> > Tens raó, podria ben bé ser que no siguin significatius. De fet,
> > llegint la pàgina de la viquipèdia sobre l'SMART no marca aquests
> > paràmetres com a indicadors de problemes al disc per la diferent
> > implementació de cada fabricant:
> > 

> > https://en.wikipedia.org/wiki/S.M.A.R.T.#Known_ATA_S.M.A.R.T._attributes
> > 

> > Suposo que no estic acostumat a trobar-me valors WORST tan
> > propers als THRESH i que no siguin errors. De totes formes,
> > l'error del bus ATA té mala pinta, sobretot si se segueix
> > produint, perquè indica un problema físic (disc, cable,
> > controladora, memòria, etc.) no de programari.
> > 

> > T'anava a dir que pots mirar d'actualitzar el firmware del disc
> > per si es tracta d'un defecte de fabricació corregit en versions
> > més noves, però veig que no n'hi ha pel teu número de sèrie.
> > 

> > Potser val la pena provar a fer un diagnòstic del disc amb les
> > eines del fabricant, ja que veig que Seagate té el SeaTools
> > disponible per a linux:
> > 

> > https://www.seagate.com/es/es/support/downloads/seatools/
> > 

> > Salut i gràcies per demanar més detalls,
> > Alex
> > 

> > -- ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ Alex Muntada  ⢿⡄⠘⠷⠚⠋ Debian Developer 
> >  log.alexm.org ⠈⠳⣄

signature.asc
Description: OpenPGP digital signature


Re: Una de discs durs

2021-02-23 Conversa Josep Lladonosa
A la feina hem posat uns quants ssd i algun disc dur agafsts amb una brida
on es pot.

Això sí, discs durs sempre ben posats en horitzontal o vertical, que els
plats de dins giren i cap inclinació no és bona...

Un altre aspecte a tenir en compte és que el xassís metàl·lic del disc
hauria d'estar en contacte amb el de la caixa del PC però funcionaria igual
ja que el connector sata té el negatiu (tot i que no és ben bé el
mateix...).

El dt., 23 de febr. 2021, 9:20, Joan  va escriure:

> El Fri, 12 Feb 2021 09:49:35 +0100
> Joan  va escriure:
>
> > El Sun, 3 Jan 2021 09:29:35 +0100
> > Josep Lladonosa  va escriure:
> >
> > > Hola, Joan,
> > >
> > >
> > > Que no sigui cosa del cable SATA.
> > > A la feina hem tingut experiències similars i canviant-lo s'ha
> > > resolt.
> >
> >
> > Per cert, després de canviar el cable SATA ja no ha tornat a succeir
> > la "corrupció"... O sigui, dono per bona l'explicació que era el cable
> > SATA.
> >
> > I t'agraeixo molt, Josep, que apuntessis en aquesta direcció...
> >
> > Pd.: sembla mentida que el que pugui fallar sigui un element estàtic
> > com un cbale... O que aquest comenci a fallar "un bon dia"...
> >
>
>
> Doncs no era el cable. Ahir em va tornar a fallar el disc dur...
>
> Ara em repassaré els missatges que em vau enviar, donant-me línies
> d'investigació (quin pal, perquè aquest tema de hardware no el controlo
> gens!).
>
> De moment, com que l'ordinador, un slimbox, no te dos anys, els he
> enviat un missatge per veure si la garantia cobreix aquest tema (entenc
> que si, però ja vorem).
>
> Estava pensant, però, si comprar-me'n un altre, mentre resolc aquest
> tema, i uso el vell com a dipòsit per clonar/sincronitzar periòdicament
> el primer, en plan backup o, fins i tot, si és possible fer un RAID
> (tampoc sé si és bona idea usar un disc que es va corrompent com a
> segon element del raid). Ara, una cosa que veig és que l'slimbox permet
> collar un disc SATA, però no dos, malgrat tenir el connector de la
> placa base, el que no te és lloc per "cargolar-lo": es pot posar "sense
> collar"??
>
>
>
> >
> > >
> > > La fiabilitat dels discs durs és poca, sempre és recomanable tenir
> > > còpies de seguretat i fer-los treballar per parelles, en raid 1, per
> > > exemple.
> > >
> > > Cada fabricant indica la seva garantia.
> > > Per a mi, els pitjors, Seagate. Els millors, Hitachi (HGST que crec
> > > que és de Western Digital, ara, i que també està bé).
> > >
> > > Bon any,
> > > Josep
> > >
> > > El dg., 3 de gen. 2021, 9:01, Joan  va
> > > escriure:
> > > > El problema que tinc m'ha passat dugues vegades en dugues
> > > > setmanes, i tinc dubtes de si és un tema físic del disc (un disc
> > > > SATA de 4Tb) no massa vell, de potser un parell d'anys, o un
> > > > problema del soft que "desgabella" el disc
> > > >
> > > > És un disc secundari (el sistema el tinc en un SSD) a on guardo
> > > > videos, fotos, etc. Un dels meus sospitosos com a causa de tot
> > > > plegat podria ser l'amule.
> > > >
> > > > Bé, la qüestió és que quan arrenco el sistema la cosa va
> > > > malament, i queda en mode d'emergència, perquè detecta un error:
> > > >
> > > > de gen. 02 16:21:12 pc2019 systemd-fsck[502]: magatzem: Inode
> > > > 38666373 has an invalid extent node (blk 154697780, lblk 0) de
> > > > gen. 02 16:21:12 pc2019 systemd-fsck[502]: magatzem: UNEXPECTED
> > > > INCONSISTENCY; RUN fsck MANUALLY. de gen. 02 16:21:12 pc2019
> > > > systemd-fsck[502]: (i.e., without -a or -p options) de
> > > > gen. 02 16:21:12 pc2019 systemd-fsck[430]: fsck failed with exit
> > > > status 4. de gen. 02 16:21:12 pc2019 systemd-fsck[430]: Running
> > > > request emergency.target/start/replace de gen. 02 16:21:12 pc2019
> > > > systemd[1]: systemd-fsck@dev-disk-by
> > > > \x2duuid-eabfd9a3\x2d1b1f\x2d4144\x2da9d3\x2dd514566fa3fb.service:
> > > > Main process exited, code=exited, status=1/FAILURE de gen. 02
> > > > 16:21:12 pc2019 systemd[1]:
> > > > systemd-fsck@dev-disk-by
> > > > \x2duuid-eabfd9a3\x2d1b1f\x2d4144\x2da9d3\x2dd514566fa3fb.service:
> > > > Failed with result 'exit-code'. de gen. 02 16:21:12 pc2019
> > > > systemd[1]: Failed to start File System Check on
> > > > /dev/disk/by-uuid/eabfd9a3-1b1f-4144-a9d3-d514566fa3fb. de gen. 02
> > > > 16:21:12 pc2019 systemd[1]: Dependency failed for /media/magatzem.
> > > > de gen. 02 16:21:12 pc2019 systemd[1]: Dependency failed for Local
> > > > File Systems. de gen. 02 16:21:12 pc2019 systemd[1]:
> > > > local-fs.target: Job local-fs.target/start failed with result
> > > > 'dependency'. de gen. 02 16:21:12 pc2019 systemd[1]:
> > > > local-fs.target: Triggering OnFailure= dependencies. de gen. 02
> > > > 16:21:12 pc2019 systemd[1]: media-magatzem.mount: Job
> > > > media-magatzem.mount/start failed with result 'dependency'.
> > > >
> > > > I a mi em mostra aquesta pantalla:
> > > >
> > > >
> > > >
> https://upload.disroot.org/r/APnYtXLB#NArCJjbVYVzxd9Hui4K9xb9xhkHzk9i1vE++Qf8BQQA=
> > > >
> > > > Llavors jo per sol·lucionar-ho 

Re: Una de discs durs

2021-02-23 Conversa Joan
El Fri, 12 Feb 2021 09:49:35 +0100
Joan  va escriure:

> El Sun, 3 Jan 2021 09:29:35 +0100
> Josep Lladonosa  va escriure:
> 
> > Hola, Joan,
> > 
> > 
> > Que no sigui cosa del cable SATA.
> > A la feina hem tingut experiències similars i canviant-lo s'ha
> > resolt.  
> 
> 
> Per cert, després de canviar el cable SATA ja no ha tornat a succeir
> la "corrupció"... O sigui, dono per bona l'explicació que era el cable
> SATA.
> 
> I t'agraeixo molt, Josep, que apuntessis en aquesta direcció...
> 
> Pd.: sembla mentida que el que pugui fallar sigui un element estàtic
> com un cbale... O que aquest comenci a fallar "un bon dia"...
> 


Doncs no era el cable. Ahir em va tornar a fallar el disc dur... 

Ara em repassaré els missatges que em vau enviar, donant-me línies
d'investigació (quin pal, perquè aquest tema de hardware no el controlo
gens!).

De moment, com que l'ordinador, un slimbox, no te dos anys, els he
enviat un missatge per veure si la garantia cobreix aquest tema (entenc
que si, però ja vorem).

Estava pensant, però, si comprar-me'n un altre, mentre resolc aquest
tema, i uso el vell com a dipòsit per clonar/sincronitzar periòdicament
el primer, en plan backup o, fins i tot, si és possible fer un RAID
(tampoc sé si és bona idea usar un disc que es va corrompent com a
segon element del raid). Ara, una cosa que veig és que l'slimbox permet
collar un disc SATA, però no dos, malgrat tenir el connector de la
placa base, el que no te és lloc per "cargolar-lo": es pot posar "sense
collar"??



> 
> > 
> > La fiabilitat dels discs durs és poca, sempre és recomanable tenir
> > còpies de seguretat i fer-los treballar per parelles, en raid 1, per
> > exemple.
> > 
> > Cada fabricant indica la seva garantia.
> > Per a mi, els pitjors, Seagate. Els millors, Hitachi (HGST que crec
> > que és de Western Digital, ara, i que també està bé).
> > 
> > Bon any,
> > Josep
> > 
> > El dg., 3 de gen. 2021, 9:01, Joan  va
> > escriure: 
> > > El problema que tinc m'ha passat dugues vegades en dugues
> > > setmanes, i tinc dubtes de si és un tema físic del disc (un disc
> > > SATA de 4Tb) no massa vell, de potser un parell d'anys, o un
> > > problema del soft que "desgabella" el disc
> > >
> > > És un disc secundari (el sistema el tinc en un SSD) a on guardo
> > > videos, fotos, etc. Un dels meus sospitosos com a causa de tot
> > > plegat podria ser l'amule.
> > >
> > > Bé, la qüestió és que quan arrenco el sistema la cosa va
> > > malament, i queda en mode d'emergència, perquè detecta un error:
> > >
> > > de gen. 02 16:21:12 pc2019 systemd-fsck[502]: magatzem: Inode
> > > 38666373 has an invalid extent node (blk 154697780, lblk 0) de
> > > gen. 02 16:21:12 pc2019 systemd-fsck[502]: magatzem: UNEXPECTED
> > > INCONSISTENCY; RUN fsck MANUALLY. de gen. 02 16:21:12 pc2019
> > > systemd-fsck[502]: (i.e., without -a or -p options) de
> > > gen. 02 16:21:12 pc2019 systemd-fsck[430]: fsck failed with exit
> > > status 4. de gen. 02 16:21:12 pc2019 systemd-fsck[430]: Running
> > > request emergency.target/start/replace de gen. 02 16:21:12 pc2019
> > > systemd[1]: systemd-fsck@dev-disk-by
> > > \x2duuid-eabfd9a3\x2d1b1f\x2d4144\x2da9d3\x2dd514566fa3fb.service:
> > > Main process exited, code=exited, status=1/FAILURE de gen. 02
> > > 16:21:12 pc2019 systemd[1]:
> > > systemd-fsck@dev-disk-by
> > > \x2duuid-eabfd9a3\x2d1b1f\x2d4144\x2da9d3\x2dd514566fa3fb.service:
> > > Failed with result 'exit-code'. de gen. 02 16:21:12 pc2019
> > > systemd[1]: Failed to start File System Check on
> > > /dev/disk/by-uuid/eabfd9a3-1b1f-4144-a9d3-d514566fa3fb. de gen. 02
> > > 16:21:12 pc2019 systemd[1]: Dependency failed for /media/magatzem.
> > > de gen. 02 16:21:12 pc2019 systemd[1]: Dependency failed for Local
> > > File Systems. de gen. 02 16:21:12 pc2019 systemd[1]:
> > > local-fs.target: Job local-fs.target/start failed with result
> > > 'dependency'. de gen. 02 16:21:12 pc2019 systemd[1]:
> > > local-fs.target: Triggering OnFailure= dependencies. de gen. 02
> > > 16:21:12 pc2019 systemd[1]: media-magatzem.mount: Job
> > > media-magatzem.mount/start failed with result 'dependency'.
> > >
> > > I a mi em mostra aquesta pantalla:
> > >
> > >
> > > https://upload.disroot.org/r/APnYtXLB#NArCJjbVYVzxd9Hui4K9xb9xhkHzk9i1vE++Qf8BQQA=
> > >
> > > Llavors jo per sol·lucionar-ho gaig un e2fsck -c /dev/sdb1
> > >
> > > Que em dona aquestes pantalles (les resumeixo, perquè bàsicament
> > > son 20 minuts de anar dient "yes" a tot el que em proposa, després
> > > de la revisió que dura unes 8 hores o més:
> > >
> > >
> > > https://upload.disroot.org/r/kRLsL2RX#bF9doWYguCMHAvj3APaJNb+GbUBq9zCX2mdrkLJhMAQ=
> > >
> > > https://upload.disroot.org/r/sYqhJfcy#Wv3pVBo0OuvfosT/i1LfCRx+6sTWwSkpWGDJIl4uTkI=
> > >
> > > https://upload.disroot.org/r/UTbxj19F#u5TA97h7ykB7KFj58OSPhgFLqwqFBSv00nHAQ8FoPpU=
> > >
> > > Llavors, les meves preguntes:
> > >
> > > 1) Us sembla que és un fallo de hard (el disc comença a fer el
> > > tonto, amb només 15 mesos), i ja em 

Re: Una de discs durs

2021-02-22 Conversa Alex Muntada
Hola Toni

> M'agradaria entendre el diagnòstic. Aquests valors que emfatitzes
> són (aprox) així des del primer dia. Podria ser que estiguéssin
> vinculats a la marca?

Tens raó, podria ben bé ser que no siguin significatius. De fet,
llegint la pàgina de la viquipèdia sobre l'SMART no marca aquests
paràmetres com a indicadors de problemes al disc per la diferent
implementació de cada fabricant:

https://en.wikipedia.org/wiki/S.M.A.R.T.#Known_ATA_S.M.A.R.T._attributes

Suposo que no estic acostumat a trobar-me valors WORST tan
propers als THRESH i que no siguin errors. De totes formes,
l'error del bus ATA té mala pinta, sobretot si se segueix
produint, perquè indica un problema físic (disc, cable,
controladora, memòria, etc.) no de programari.

T'anava a dir que pots mirar d'actualitzar el firmware del disc
per si es tracta d'un defecte de fabricació corregit en versions
més noves, però veig que no n'hi ha pel teu número de sèrie.

Potser val la pena provar a fer un diagnòstic del disc amb les
eines del fabricant, ja que veig que Seagate té el SeaTools
disponible per a linux:

https://www.seagate.com/es/es/support/downloads/seatools/

Salut i gràcies per demanar més detalls,
Alex

--
  ⢀⣴⠾⠻⢶⣦⠀
  ⣾⠁⢠⠒⠀⣿⡁   Alex Muntada 
  ⢿⡄⠘⠷⠚⠋   Debian Developer  log.alexm.org
  ⠈⠳⣄



signature.asc
Description: PGP signature


Re: Una de discs durs

2021-02-22 Conversa Josep Lladonosa
Volia recomanar la utilització de l'eina "mainline" (externa a Debian) que
permet instal·lar moltes versions de nucli, però ho he intentat i a la
Debian estable li faltarien biblioteques per actualitzar i caldria
instal·lar-la amb aquestes biblioteques actualitzades des de
testing/unstable així que ho he deixat córrer.
L'havia provada exitosament a l'Ubuntu (tant ella com la prèvia ukuu ara de
pagament de la qual en deriva com a lliure):

https://github.com/bkw777/mainline

SALUT!
Josep

On Mon, 22 Feb 2021 at 08:07, Narcis Garcia  wrote:

> Per a provar diferent versió del nucli Linux, jo a Debian Stable ho faig
> alternant entre els respositoris «backports» i «stable»:
>
> (Exemple amb Debian Buster):
>
> # Per a instal·lar Linux 5.10
> $ sudo apt -t buster-backports install linux-image-amd64
>
> # Per a instal·lar l'actual Linux 4.19
> $ sudo apt install linux-image-amd64=4.19+105+deb10u9
>
> (i aleshores triar nucli al gestor d'arrencada)
>
>
> Narcis Garcia
>
> __
> I'm using this dedicated address because personal addresses aren't
> masked enough at this mail public archive. Public archive administrator
> should fix this against automated addresses collectors.
> El 22/2/21 a les 1:51, Toni Mas Soler ha escrit:
> > Hola Àlex. Gràcies per al resposta. I sí. Està en garantia durant tot
> aquest any.
> >
> > M'agradaria entendre el diagnòstic. Aquests valors que emfatitzes són
> (aprox) així des del primer dia. Podria ser que estiguéssin vinculats a la
> marca? A més, durant el l'estiu passat no van comportar cap problema.
> >
> > Josep. Per canvi de nucli valdria un canvi de versió?
> >
> >
> >
> > Toni Mas
> > GPG 3F42A21D84D7E950
> >
> > Sent with ProtonMail Secure Email.
> >
> > ‐‐‐ Original Message ‐‐‐
> > En diumenge 21 de febrer de 2021 a les 18:21, Alex Muntada <
> al...@debian.org> va escriure:
> >
> >> Hola Toni
> >>
> >
> >>> 60 Vendor Specific SMART Attributes with Thresholds:
> >>> 61 ID# ATTRIBUTE_NAME  FLAG VALUE WORST THRESH TYPE
> UPDATED  WHEN_FAILED RAW_VALUE
> >>> 62   1 Raw_Read_Error_Rate 0x000f   080   064   044Pre-fail
> Always   -   97510545
> >>
> >
> >> ...
> >>
> >
> >>> 66   7 Seek_Error_Rate 0x000f   090   060   045Pre-fail
> Always   -   946331866
> >>
> >
> >> Veient aquests valors i després d'haver comprovat els cables,
> >> jo canviaria el disc per un de nou.
> >>
> >
> >>> 67   9 Power_On_Hours  0x0032   089   089   000Old_age
> Always   -   9819 (198 153 0)
> >>
> >
> >> ...
> >>
> >
> >>> 69  12 Power_Cycle_Count   0x0032   100   100   020Old_age
> Always   -   26
> >>
> >
> >> No sembla pas que sigui un disc gaire vell. Pot ser que encara
> >> estigui en garantia? Veig que els ironwolf en tenen 3 anys.
> >>
> >
> >> Salut,
> >> Alex
> >>
> >
> >>
> --
> >>
> >
> >> ⢀⣴⠾⠻⢶⣦⠀
> >> ⣾⠁⢠⠒⠀⣿⡁ Alex Muntada al...@debian.org
> >> ⢿⡄⠘⠷⠚⠋ Debian Developer  log.alexm.org
> >> ⠈⠳⣄
> >
>
>

-- 
--
Salutacions...Josep
--


Re: Una de discs durs

2021-02-21 Conversa Narcis Garcia
Per a provar diferent versió del nucli Linux, jo a Debian Stable ho faig
alternant entre els respositoris «backports» i «stable»:

(Exemple amb Debian Buster):

# Per a instal·lar Linux 5.10
$ sudo apt -t buster-backports install linux-image-amd64

# Per a instal·lar l'actual Linux 4.19
$ sudo apt install linux-image-amd64=4.19+105+deb10u9

(i aleshores triar nucli al gestor d'arrencada)


Narcis Garcia

__
I'm using this dedicated address because personal addresses aren't
masked enough at this mail public archive. Public archive administrator
should fix this against automated addresses collectors.
El 22/2/21 a les 1:51, Toni Mas Soler ha escrit:
> Hola Àlex. Gràcies per al resposta. I sí. Està en garantia durant tot aquest 
> any.
> 
> M'agradaria entendre el diagnòstic. Aquests valors que emfatitzes són (aprox) 
> així des del primer dia. Podria ser que estiguéssin vinculats a la marca? A 
> més, durant el l'estiu passat no van comportar cap problema.
> 
> Josep. Per canvi de nucli valdria un canvi de versió? 
> 
> 
> 
> Toni Mas
> GPG 3F42A21D84D7E950
> 
> Sent with ProtonMail Secure Email.
> 
> ‐‐‐ Original Message ‐‐‐
> En diumenge 21 de febrer de 2021 a les 18:21, Alex Muntada  
> va escriure:
> 
>> Hola Toni
>>
> 
>>> 60 Vendor Specific SMART Attributes with Thresholds:
>>> 61 ID# ATTRIBUTE_NAME  FLAG VALUE WORST THRESH TYPE  
>>> UPDATED  WHEN_FAILED RAW_VALUE
>>> 62   1 Raw_Read_Error_Rate 0x000f   080   064   044    Pre-fail  Always 
>>>   -   97510545
>>
> 
>> ...
>>
> 
>>> 66   7 Seek_Error_Rate 0x000f   090   060   045    Pre-fail  Always 
>>>   -   946331866
>>
> 
>> Veient aquests valors i després d'haver comprovat els cables,
>> jo canviaria el disc per un de nou.
>>
> 
>>> 67   9 Power_On_Hours  0x0032   089   089   000    Old_age   Always 
>>>   -   9819 (198 153 0)
>>
> 
>> ...
>>
> 
>>> 69  12 Power_Cycle_Count   0x0032   100   100   020    Old_age   Always 
>>>   -   26
>>
> 
>> No sembla pas que sigui un disc gaire vell. Pot ser que encara
>> estigui en garantia? Veig que els ironwolf en tenen 3 anys.
>>
> 
>> Salut,
>> Alex
>>
> 
>> --
>>
> 
>> ⢀⣴⠾⠻⢶⣦⠀
>> ⣾⠁⢠⠒⠀⣿⡁ Alex Muntada al...@debian.org
>> ⢿⡄⠘⠷⠚⠋ Debian Developer  log.alexm.org
>> ⠈⠳⣄
> 



Re: Una de discs durs

2021-02-21 Conversa Toni Mas Soler
Hola Àlex. Gràcies per al resposta. I sí. Està en garantia durant tot aquest 
any.

M'agradaria entendre el diagnòstic. Aquests valors que emfatitzes són (aprox) 
així des del primer dia. Podria ser que estiguéssin vinculats a la marca? A 
més, durant el l'estiu passat no van comportar cap problema.

Josep. Per canvi de nucli valdria un canvi de versió? 



Toni Mas
GPG 3F42A21D84D7E950

Sent with ProtonMail Secure Email.

‐‐‐ Original Message ‐‐‐
En diumenge 21 de febrer de 2021 a les 18:21, Alex Muntada  
va escriure:

> Hola Toni
> 

> > 60 Vendor Specific SMART Attributes with Thresholds:
> > 61 ID# ATTRIBUTE_NAME  FLAG VALUE WORST THRESH TYPE  
> > UPDATED  WHEN_FAILED RAW_VALUE
> > 62   1 Raw_Read_Error_Rate 0x000f   080   064   044    Pre-fail  Always 
> >   -   97510545
> 

> ...
> 

> > 66   7 Seek_Error_Rate 0x000f   090   060   045    Pre-fail  Always 
> >   -   946331866
> 

> Veient aquests valors i després d'haver comprovat els cables,
> jo canviaria el disc per un de nou.
> 

> > 67   9 Power_On_Hours  0x0032   089   089   000    Old_age   Always 
> >   -   9819 (198 153 0)
> 

> ...
> 

> > 69  12 Power_Cycle_Count   0x0032   100   100   020    Old_age   Always 
> >   -   26
> 

> No sembla pas que sigui un disc gaire vell. Pot ser que encara
> estigui en garantia? Veig que els ironwolf en tenen 3 anys.
> 

> Salut,
> Alex
> 

> --
> 

> ⢀⣴⠾⠻⢶⣦⠀
> ⣾⠁⢠⠒⠀⣿⡁ Alex Muntada al...@debian.org
> ⢿⡄⠘⠷⠚⠋ Debian Developer  log.alexm.org
> ⠈⠳⣄



signature.asc
Description: OpenPGP digital signature


Re: Una de discs durs

2021-02-21 Conversa Josep Lladonosa
On Sun, 21 Feb 2021 at 10:18, Toni Mas Soler 
wrote:

> Hola. A veure si algú m'aporta la llum.
> Molt sovint em trobo amb aquest problema:
>
> [539698.662250] ata2.00: exception Emask 0x10 SAct 0x0 SErr 0x195
> action 0xe frozen
> [539698.662369] ata2: SError: { PHYRdyChg CommWake Dispar LinkSeq
> TrStaTrns }
> [539698.662466] ata2.00: failed command: READ DMA EXT
> [539698.662542] ata2.00: cmd 25/00:00:00:88:b1/00:01:0a:01:00/e0 tag 0 dma
> 131072 in
>  res 40/00:01:e0:4f:c2/00:00:00:00:00/00 Emask
> 0x14 (ATA bus error)
> [539698.662747] ata2.00: status: { DRDY }
> [539698.662808] ata2: hard resetting link
> [539698.662811] ata2: nv: skipping hardreset on occupied port
> [539699.534259] ata2: SATA link up 3.0 Gbps (SStatus 123 SControl 300)
> [539699.557332] ata2.00: configured for UDMA/133
> [539699.557365] sd 1:0:0:0: [sdb] tag#0 FAILED Result: hostbyte=DID_OK
> driverbyte=DRIVER_SENSE
> [539699.557370] sd 1:0:0:0: [sdb] tag#0 Sense Key : Illegal Request
> [current]
> [539699.557376] sd 1:0:0:0: [sdb] tag#0 Add. Sense: Unaligned write command
> [539699.557383] sd 1:0:0:0: [sdb] tag#0 CDB: Read(16) 88 00 00 00 00 01 0a
> b1 88 00 00 00 01 00 00 00
> [539699.557387] print_req_error: I/O error, dev sdb, sector 4474374144
> [539699.557529] ata2: EH complete
>
> Tinc 2 discos muntats amb RAID1 amb mdadm.
> El cas és que m'ha començat a aparèixer des que l'altre disc va haver-hi
> una falla general (suposadament tampoc culpa del disc ja que canviat el
> cable SATA l'altre disc va tornar a funcionar com sempre).
>
> Després del canvi de cable he provat de permutar i substituir cables i
> permutar ports i no hi ha manera que desapareguin els missatges (més
> freqüents com més feina se li exigeix al dsic).
>
> Teniu alguna idea (abans de canviar el disc)?
>
> Informació del SMART:
>   1
>   2 smartctl 6.6 2017-11-05 r4594 [x86_64-linux-4.19.0-13-amd64] (local
> build)
>   3 Copyright (C) 2002-17, Bruce Allen, Christian Franke,
> www.smartmontools.org
>   4
>   5 === START OF INFORMATION SECTION ===
>   6 Model Family: Seagate IronWolf
>   7 Device Model: ST3000VN007-2AH16M
>   8 Serial Number:ZDH7AQZ6
>   9 LU WWN Device Id: 5 000c50 0b69174f5
> 10 Firmware Version: SC60
> 11 User Capacity:3.000.592.982.016 bytes [3,00 TB]
> 12 Sector Sizes: 512 bytes logical, 4096 bytes physical
> 13 Rotation Rate:5980 rpm
> 14 Form Factor:  3.5 inches
> 15 Device is:In smartctl database [for details use: -P show]
> 16 ATA Version is:   ACS-3 T13/2161-D revision 5
> 17 SATA Version is:  SATA 3.1, 6.0 Gb/s (current: 3.0 Gb/s)
> 18 Local Time is:Thu Jan 28 10:00:01 2021 CET
> 19 SMART support is: Available - device has SMART capability.
> 20 SMART support is: Enabled
> 21
> 22 === START OF READ SMART DATA SECTION ===
> 23 SMART overall-health self-assessment test result: PASSED
> 24
> 25 General SMART Values:
> 26 Offline data collection status:  (0x00) Offline data collection activity
> 27 was never started.
> 28 Auto Offline Data Collection:
> Disabled.
> 29 Self-test execution status:  (   0) The previous self-test routine
> completed
> 30 without error or no self-test
> has ever
> 31 been run.
> 32 Total time to complete Offline
> 33 data collection:(  591) seconds.
> 34 Offline data collection
> 35 capabilities:(0x73) SMART execute Offline immediate.
> 36 Auto Offline data collection
> on/off support.
> 37 Suspend Offline collection upon
> new
> 38 command.
> 39 No Offline surface scan
> supported.
> 40 Self-test supported.
> 41 Conveyance Self-test supported.
> 42 Selective Self-test supported.
> 43 SMART capabilities:(0x0003) Saves SMART data before entering
> 44 power-saving mode.
> 45 Supports SMART auto save timer.
> 46 Error logging capability:(0x01) Error logging supported.
> 47 General Purpose Logging
> supported.
> 48 Short self-test routine
> 49 recommended polling time:(   1) minutes.
> 50 Extended self-test routine
> 51 recommended polling time:( 502) minutes.
> 52 Conveyance self-test routine
> 53 recommended polling time:(   2) minutes.
> 54 SCT capabilities:  (0x50bd) SCT Status supported.
> 55 SCT Error Recovery Control
> supported.
> 56 SCT Feature Control supported.
> 57 SCT 

Re: Una de discs durs

2021-02-21 Conversa Alex Muntada
Hola Toni

> 60 Vendor Specific SMART Attributes with Thresholds:
> 61 ID# ATTRIBUTE_NAME  FLAG VALUE WORST THRESH TYPE  UPDATED  
> WHEN_FAILED RAW_VALUE
> 62   1 Raw_Read_Error_Rate 0x000f   080   064   044    Pre-fail  Always   
>     -   97510545
...
> 66   7 Seek_Error_Rate 0x000f   090   060   045    Pre-fail  Always   
>     -   946331866

Veient aquests valors i després d'haver comprovat els cables,
jo canviaria el disc per un de nou.

> 67   9 Power_On_Hours  0x0032   089   089   000    Old_age   Always   
>     -   9819 (198 153 0)
...
> 69  12 Power_Cycle_Count   0x0032   100   100   020    Old_age   Always   
>     -   26

No sembla pas que sigui un disc gaire vell. Pot ser que encara
estigui en garantia? Veig que els ironwolf en tenen 3 anys.

Salut,
Alex

--
  ⢀⣴⠾⠻⢶⣦⠀
  ⣾⠁⢠⠒⠀⣿⡁   Alex Muntada 
  ⢿⡄⠘⠷⠚⠋   Debian Developer  log.alexm.org
  ⠈⠳⣄



signature.asc
Description: PGP signature


Re: Una de discs durs

2021-02-21 Conversa Toni Mas Soler
Hola. A veure si algú m'aporta la llum.
Molt sovint em trobo amb aquest problema:

[539698.662250] ata2.00: exception Emask 0x10 SAct 0x0 SErr 0x195 action 
0xe frozen
[539698.662369] ata2: SError: { PHYRdyChg CommWake Dispar LinkSeq TrStaTrns }
[539698.662466] ata2.00: failed command: READ DMA EXT
[539698.662542] ata2.00: cmd 25/00:00:00:88:b1/00:01:0a:01:00/e0 tag 0 dma 
131072 in
 res 40/00:01:e0:4f:c2/00:00:00:00:00/00 Emask 0x14 
(ATA bus error)
[539698.662747] ata2.00: status: { DRDY }
[539698.662808] ata2: hard resetting link
[539698.662811] ata2: nv: skipping hardreset on occupied port
[539699.534259] ata2: SATA link up 3.0 Gbps (SStatus 123 SControl 300)
[539699.557332] ata2.00: configured for UDMA/133
[539699.557365] sd 1:0:0:0: [sdb] tag#0 FAILED Result: hostbyte=DID_OK 
driverbyte=DRIVER_SENSE
[539699.557370] sd 1:0:0:0: [sdb] tag#0 Sense Key : Illegal Request [current]
[539699.557376] sd 1:0:0:0: [sdb] tag#0 Add. Sense: Unaligned write command
[539699.557383] sd 1:0:0:0: [sdb] tag#0 CDB: Read(16) 88 00 00 00 00 01 0a b1 
88 00 00 00 01 00 00 00
[539699.557387] print_req_error: I/O error, dev sdb, sector 4474374144
[539699.557529] ata2: EH complete

Tinc 2 discos muntats amb RAID1 amb mdadm.
El cas és que m'ha començat a aparèixer des que l'altre disc va haver-hi una 
falla general (suposadament tampoc culpa del disc ja que canviat el cable SATA 
l'altre disc va tornar a funcionar com sempre).

Després del canvi de cable he provat de permutar i substituir cables i permutar 
ports i no hi ha manera que desapareguin els missatges (més freqüents com més 
feina se li exigeix al dsic).

Teniu alguna idea (abans de canviar el disc)?

Informació del SMART:
  1
  2 smartctl 6.6 2017-11-05 r4594 [x86_64-linux-4.19.0-13-amd64] (local build)
  3 Copyright (C) 2002-17, Bruce Allen, Christian Franke, www.smartmontools.org
  4
  5 === START OF INFORMATION SECTION ===
  6 Model Family: Seagate IronWolf
  7 Device Model: ST3000VN007-2AH16M
  8 Serial Number:    ZDH7AQZ6
  9 LU WWN Device Id: 5 000c50 0b69174f5
10 Firmware Version: SC60
11 User Capacity:    3.000.592.982.016 bytes [3,00 TB]
12 Sector Sizes: 512 bytes logical, 4096 bytes physical
13 Rotation Rate:    5980 rpm
14 Form Factor:  3.5 inches
15 Device is:    In smartctl database [for details use: -P show]
16 ATA Version is:   ACS-3 T13/2161-D revision 5
17 SATA Version is:  SATA 3.1, 6.0 Gb/s (current: 3.0 Gb/s)
18 Local Time is:    Thu Jan 28 10:00:01 2021 CET
19 SMART support is: Available - device has SMART capability.
20 SMART support is: Enabled
21
22 === START OF READ SMART DATA SECTION ===
23 SMART overall-health self-assessment test result: PASSED
24
25 General SMART Values:
26 Offline data collection status:  (0x00) Offline data collection activity
27 was never started.
28 Auto Offline Data Collection: 
Disabled.
29 Self-test execution status:  (   0) The previous self-test routine 
completed
30 without error or no self-test has 
ever
31 been run.
32 Total time to complete Offline
33 data collection:    (  591) seconds.
34 Offline data collection
35 capabilities:    (0x73) SMART execute Offline immediate.
36 Auto Offline data collection on/off 
support.
37 Suspend Offline collection upon new
38 command.
39 No Offline surface scan supported.
40 Self-test supported.
41 Conveyance Self-test supported.
42 Selective Self-test supported.
43 SMART capabilities:    (0x0003) Saves SMART data before entering
44 power-saving mode.
45 Supports SMART auto save timer.
46 Error logging capability:    (0x01) Error logging supported.
47 General Purpose Logging supported.
48 Short self-test routine
49 recommended polling time:    (   1) minutes.
50 Extended self-test routine
51 recommended polling time:    ( 502) minutes.
52 Conveyance self-test routine
53 recommended polling time:    (   2) minutes.
54 SCT capabilities:  (0x50bd) SCT Status supported.
55 SCT Error Recovery Control supported.
56 SCT Feature Control supported.
57 SCT Data Table supported.
58
59 SMART Attributes Data Structure revision number: 10
60 Vendor Specific SMART Attributes with Thresholds:
61 ID# ATTRIBUTE_NAME  FLAG VALUE WORST THRESH TYPE  UPDATED  
WHEN_FAILED RAW_VALUE
62   1 

Re: Una de discs durs

2021-02-12 Conversa Josep Lladonosa
On Fri, 12 Feb 2021 at 09:49, Joan  wrote:

> El Sun, 3 Jan 2021 09:29:35 +0100
> Josep Lladonosa  va escriure:
>
> > Hola, Joan,
> >
> >
> > Que no sigui cosa del cable SATA.
> > A la feina hem tingut experiències similars i canviant-lo s'ha resolt.
>
>
> Per cert, després de canviar el cable SATA ja no ha tornat a succeir la
> "corrupció"... O sigui, dono per bona l'explicació que era el cable
> SATA.
>
> I t'agraeixo molt, Josep, que apuntessis en aquesta direcció...
>
> Pd.: sembla mentida que el que pugui fallar sigui un element estàtic
> com un cbale... O que aquest comenci a fallar "un bon dia"...
>

Bé, els cables en si no acostumen a fallar si no hi ha una interrupció en
el coure.
Per diverses experiències el que puc dir és que són els connectors entre
cable i altres elements (placa base, disc dur) que fallen. El plàstic es
degrada per la calor... i molt més en cas de pujades de temperatura i
refredaments. Tot això afecta a la interconnexió del coure del connector
del mateix cable i l'altre element on resta connectat. Si l'ambient on es
troba la màquina és "brut", també hi pot haver tema de brutícia (greix,
pols) entre coures...

També s'aplica als ventiladors, per exemple.

És llei de vida dels materials: metall i plàstic no són flors i violes. ;-)


>
>
> >
> > La fiabilitat dels discs durs és poca, sempre és recomanable tenir
> > còpies de seguretat i fer-los treballar per parelles, en raid 1, per
> > exemple.
> >
> > Cada fabricant indica la seva garantia.
> > Per a mi, els pitjors, Seagate. Els millors, Hitachi (HGST que crec
> > que és de Western Digital, ara, i que també està bé).
> >
> > Bon any,
> > Josep
> >
> > El dg., 3 de gen. 2021, 9:01, Joan  va escriure:
> >
> > > El problema que tinc m'ha passat dugues vegades en dugues setmanes,
> > > i tinc dubtes de si és un tema físic del disc (un disc SATA de 4Tb)
> > > no massa vell, de potser un parell d'anys, o un problema del soft
> > > que "desgabella" el disc
> > >
> > > És un disc secundari (el sistema el tinc en un SSD) a on guardo
> > > videos, fotos, etc. Un dels meus sospitosos com a causa de tot
> > > plegat podria ser l'amule.
> > >
> > > Bé, la qüestió és que quan arrenco el sistema la cosa va malament, i
> > > queda en mode d'emergència, perquè detecta un error:
> > >
> > > de gen. 02 16:21:12 pc2019 systemd-fsck[502]: magatzem: Inode
> > > 38666373 has an invalid extent node (blk 154697780, lblk 0) de gen.
> > > 02 16:21:12 pc2019 systemd-fsck[502]: magatzem: UNEXPECTED
> > > INCONSISTENCY; RUN fsck MANUALLY. de gen. 02 16:21:12 pc2019
> > > systemd-fsck[502]: (i.e., without -a or -p options) de gen.
> > > 02 16:21:12 pc2019 systemd-fsck[430]: fsck failed with exit status
> > > 4. de gen. 02 16:21:12 pc2019 systemd-fsck[430]: Running request
> > > emergency.target/start/replace de gen. 02 16:21:12 pc2019
> > > systemd[1]: systemd-fsck@dev-disk-by
> > > \x2duuid-eabfd9a3\x2d1b1f\x2d4144\x2da9d3\x2dd514566fa3fb.service:
> > > Main process exited, code=exited, status=1/FAILURE de gen. 02
> > > 16:21:12 pc2019 systemd[1]:
> > > systemd-fsck@dev-disk-by
> > > \x2duuid-eabfd9a3\x2d1b1f\x2d4144\x2da9d3\x2dd514566fa3fb.service:
> > > Failed with result 'exit-code'. de gen. 02 16:21:12 pc2019
> > > systemd[1]: Failed to start File System Check on
> > > /dev/disk/by-uuid/eabfd9a3-1b1f-4144-a9d3-d514566fa3fb. de gen. 02
> > > 16:21:12 pc2019 systemd[1]: Dependency failed for /media/magatzem.
> > > de gen. 02 16:21:12 pc2019 systemd[1]: Dependency failed for Local
> > > File Systems. de gen. 02 16:21:12 pc2019 systemd[1]:
> > > local-fs.target: Job local-fs.target/start failed with result
> > > 'dependency'. de gen. 02 16:21:12 pc2019 systemd[1]:
> > > local-fs.target: Triggering OnFailure= dependencies. de gen. 02
> > > 16:21:12 pc2019 systemd[1]: media-magatzem.mount: Job
> > > media-magatzem.mount/start failed with result 'dependency'.
> > >
> > > I a mi em mostra aquesta pantalla:
> > >
> > >
> > >
> https://upload.disroot.org/r/APnYtXLB#NArCJjbVYVzxd9Hui4K9xb9xhkHzk9i1vE++Qf8BQQA=
> > >
> > > Llavors jo per sol·lucionar-ho gaig un e2fsck -c /dev/sdb1
> > >
> > > Que em dona aquestes pantalles (les resumeixo, perquè bàsicament
> > > son 20 minuts de anar dient "yes" a tot el que em proposa, després
> > > de la revisió que dura unes 8 hores o més:
> > >
> > >
> > >
> https://upload.disroot.org/r/kRLsL2RX#bF9doWYguCMHAvj3APaJNb+GbUBq9zCX2mdrkLJhMAQ=
> > >
> > >
> https://upload.disroot.org/r/sYqhJfcy#Wv3pVBo0OuvfosT/i1LfCRx+6sTWwSkpWGDJIl4uTkI=
> > >
> > >
> https://upload.disroot.org/r/UTbxj19F#u5TA97h7ykB7KFj58OSPhgFLqwqFBSv00nHAQ8FoPpU=
> > >
> > > Llavors, les meves preguntes:
> > >
> > > 1) Us sembla que és un fallo de hard (el disc comença a fer el
> > > tonto, amb només 15 mesos), i ja em puc espabilar a comprar-ne un
> > > altra i fer-li un clonezilla?
> > >
> > > 2) Podria ser un problema originat pel software? (en aquest sentit
> > > no sé si actualitzar la meva Debian Testing, que no actualitzo en
> > > general de 

Re: Una de discs durs

2021-02-12 Conversa Joan
El Sun, 3 Jan 2021 09:29:35 +0100
Josep Lladonosa  va escriure:

> Hola, Joan,
> 
> 
> Que no sigui cosa del cable SATA.
> A la feina hem tingut experiències similars i canviant-lo s'ha resolt.


Per cert, després de canviar el cable SATA ja no ha tornat a succeir la
"corrupció"... O sigui, dono per bona l'explicació que era el cable
SATA.

I t'agraeixo molt, Josep, que apuntessis en aquesta direcció...

Pd.: sembla mentida que el que pugui fallar sigui un element estàtic
com un cbale... O que aquest comenci a fallar "un bon dia"...


> 
> La fiabilitat dels discs durs és poca, sempre és recomanable tenir
> còpies de seguretat i fer-los treballar per parelles, en raid 1, per
> exemple.
> 
> Cada fabricant indica la seva garantia.
> Per a mi, els pitjors, Seagate. Els millors, Hitachi (HGST que crec
> que és de Western Digital, ara, i que també està bé).
> 
> Bon any,
> Josep
> 
> El dg., 3 de gen. 2021, 9:01, Joan  va escriure:
> 
> > El problema que tinc m'ha passat dugues vegades en dugues setmanes,
> > i tinc dubtes de si és un tema físic del disc (un disc SATA de 4Tb)
> > no massa vell, de potser un parell d'anys, o un problema del soft
> > que "desgabella" el disc
> >
> > És un disc secundari (el sistema el tinc en un SSD) a on guardo
> > videos, fotos, etc. Un dels meus sospitosos com a causa de tot
> > plegat podria ser l'amule.
> >
> > Bé, la qüestió és que quan arrenco el sistema la cosa va malament, i
> > queda en mode d'emergència, perquè detecta un error:
> >
> > de gen. 02 16:21:12 pc2019 systemd-fsck[502]: magatzem: Inode
> > 38666373 has an invalid extent node (blk 154697780, lblk 0) de gen.
> > 02 16:21:12 pc2019 systemd-fsck[502]: magatzem: UNEXPECTED
> > INCONSISTENCY; RUN fsck MANUALLY. de gen. 02 16:21:12 pc2019
> > systemd-fsck[502]: (i.e., without -a or -p options) de gen.
> > 02 16:21:12 pc2019 systemd-fsck[430]: fsck failed with exit status
> > 4. de gen. 02 16:21:12 pc2019 systemd-fsck[430]: Running request
> > emergency.target/start/replace de gen. 02 16:21:12 pc2019
> > systemd[1]: systemd-fsck@dev-disk-by
> > \x2duuid-eabfd9a3\x2d1b1f\x2d4144\x2da9d3\x2dd514566fa3fb.service:
> > Main process exited, code=exited, status=1/FAILURE de gen. 02
> > 16:21:12 pc2019 systemd[1]:
> > systemd-fsck@dev-disk-by
> > \x2duuid-eabfd9a3\x2d1b1f\x2d4144\x2da9d3\x2dd514566fa3fb.service:
> > Failed with result 'exit-code'. de gen. 02 16:21:12 pc2019
> > systemd[1]: Failed to start File System Check on
> > /dev/disk/by-uuid/eabfd9a3-1b1f-4144-a9d3-d514566fa3fb. de gen. 02
> > 16:21:12 pc2019 systemd[1]: Dependency failed for /media/magatzem.
> > de gen. 02 16:21:12 pc2019 systemd[1]: Dependency failed for Local
> > File Systems. de gen. 02 16:21:12 pc2019 systemd[1]:
> > local-fs.target: Job local-fs.target/start failed with result
> > 'dependency'. de gen. 02 16:21:12 pc2019 systemd[1]:
> > local-fs.target: Triggering OnFailure= dependencies. de gen. 02
> > 16:21:12 pc2019 systemd[1]: media-magatzem.mount: Job
> > media-magatzem.mount/start failed with result 'dependency'.
> >
> > I a mi em mostra aquesta pantalla:
> >
> >
> > https://upload.disroot.org/r/APnYtXLB#NArCJjbVYVzxd9Hui4K9xb9xhkHzk9i1vE++Qf8BQQA=
> >
> > Llavors jo per sol·lucionar-ho gaig un e2fsck -c /dev/sdb1
> >
> > Que em dona aquestes pantalles (les resumeixo, perquè bàsicament
> > son 20 minuts de anar dient "yes" a tot el que em proposa, després
> > de la revisió que dura unes 8 hores o més:
> >
> >
> > https://upload.disroot.org/r/kRLsL2RX#bF9doWYguCMHAvj3APaJNb+GbUBq9zCX2mdrkLJhMAQ=
> >
> > https://upload.disroot.org/r/sYqhJfcy#Wv3pVBo0OuvfosT/i1LfCRx+6sTWwSkpWGDJIl4uTkI=
> >
> > https://upload.disroot.org/r/UTbxj19F#u5TA97h7ykB7KFj58OSPhgFLqwqFBSv00nHAQ8FoPpU=
> >
> > Llavors, les meves preguntes:
> >
> > 1) Us sembla que és un fallo de hard (el disc comença a fer el
> > tonto, amb només 15 mesos), i ja em puc espabilar a comprar-ne un
> > altra i fer-li un clonezilla?
> >
> > 2) Podria ser un problema originat pel software? (en aquest sentit
> > no sé si actualitzar la meva Debian Testing, que no actualitzo en
> > general de cop, sinó a bocinets).
> >
> > 3) No sé si al disc secundari és fa un fsck (o com es digui). Allò
> > que es fa al primari cada nosequantes arrencades. Diria que no, i
> > que és una opció configurable al fstab. El meu fstab és aquest:
> >
> > UUID=... /   ext4errors=remount-ro 0   1
> > # /home was on /dev/sdb6 during installation
> > UUID=... /home   ext4defaults0   2
> > # swap was on /dev/sdb5 during installation
> > UUID=...swapsw  0   0
> > # Segon disc dur 4Tb
> > UUID=e... /media/magatzem   ext4defaults0
> > 2
> >
> > (de fet, ara que hi penso, no sé si es fa el fsck a la partició
> > /home, tampoc). Diria que això te a veure amb el darrer nombre de
> > la columna, però ara he vist que systemd s'ho munta diferent i
> > només distingeix el valor zero (o buit), i la resta:
> >
> > 

Re: Una de discs durs

2021-01-03 Conversa Narcis Garcia
Em sumo a la primera mesura de provar un altre cable S.ATA
I aleshores, fer una comprovació completa de disc, però no amb el
sistema instal·lat sinó amb una Debian Stable en sessió «Live».



Narcis Garcia

__
I'm using this dedicated address because personal addresses aren't
masked enough at this mail public archive. Public archive administrator
should fix this against automated addresses collectors.
El 3/1/21 a les 9:29, Josep Lladonosa ha escrit:
> Hola, Joan,
> 
> 
> Que no sigui cosa del cable SATA.
> A la feina hem tingut experiències similars i canviant-lo s'ha resolt.
> 
> La fiabilitat dels discs durs és poca, sempre és recomanable tenir
> còpies de seguretat i fer-los treballar per parelles, en raid 1, per
> exemple.
> 
> Cada fabricant indica la seva garantia.
> Per a mi, els pitjors, Seagate. Els millors, Hitachi (HGST que crec que
> és de Western Digital, ara, i que també està bé).
> 
> Bon any,
> Josep
> 
> El dg., 3 de gen. 2021, 9:01, Joan  > va escriure:
> 
> El problema que tinc m'ha passat dugues vegades en dugues setmanes, i
> tinc dubtes de si és un tema físic del disc (un disc SATA de 4Tb) no
> massa vell, de potser un parell d'anys, o un problema del soft que
> "desgabella" el disc
> 
> És un disc secundari (el sistema el tinc en un SSD) a on guardo videos,
> fotos, etc. Un dels meus sospitosos com a causa de tot plegat podria
> ser l'amule.
> 
> Bé, la qüestió és que quan arrenco el sistema la cosa va malament, i
> queda en mode d'emergència, perquè detecta un error:
> 
> de gen. 02 16:21:12 pc2019 systemd-fsck[502]: magatzem: Inode 38666373
> has an invalid extent node (blk 154697780, lblk 0) de gen. 02 16:21:12
> pc2019 systemd-fsck[502]: magatzem: UNEXPECTED INCONSISTENCY; RUN fsck
> MANUALLY. de gen. 02 16:21:12 pc2019 systemd-fsck[502]:         (i.e.,
> without -a or -p options) de gen. 02 16:21:12 pc2019 systemd-fsck[430]:
> fsck failed with exit status 4. de gen. 02 16:21:12 pc2019
> systemd-fsck[430]: Running request emergency.target/start/replace de
> gen. 02 16:21:12 pc2019 systemd[1]:
> 
> systemd-fsck@dev-disk-by\x2duuid-eabfd9a3\x2d1b1f\x2d4144\x2da9d3\x2dd514566fa3fb.service:
> Main process exited, code=exited, status=1/FAILURE de gen. 02 16:21:12
> pc2019 systemd[1]:
> 
> systemd-fsck@dev-disk-by\x2duuid-eabfd9a3\x2d1b1f\x2d4144\x2da9d3\x2dd514566fa3fb.service:
> Failed with result 'exit-code'. de gen. 02 16:21:12 pc2019 systemd[1]:
> Failed to start File System Check on
> /dev/disk/by-uuid/eabfd9a3-1b1f-4144-a9d3-d514566fa3fb. de gen. 02
> 16:21:12 pc2019 systemd[1]: Dependency failed for /media/magatzem. de
> gen. 02 16:21:12 pc2019 systemd[1]: Dependency failed for Local File
> Systems. de gen. 02 16:21:12 pc2019 systemd[1]: local-fs.target: Job
> local-fs.target/start failed with result 'dependency'. de gen. 02
> 16:21:12 pc2019 systemd[1]: local-fs.target: Triggering OnFailure=
> dependencies. de gen. 02 16:21:12 pc2019 systemd[1]:
> media-magatzem.mount: Job media-magatzem.mount/start failed with result
> 'dependency'.
> 
> I a mi em mostra aquesta pantalla:
> 
> 
> https://upload.disroot.org/r/APnYtXLB#NArCJjbVYVzxd9Hui4K9xb9xhkHzk9i1vE++Qf8BQQA=
> 
> 
> 
> Llavors jo per sol·lucionar-ho gaig un e2fsck -c /dev/sdb1
> 
> Que em dona aquestes pantalles (les resumeixo, perquè bàsicament son 20
> minuts de anar dient "yes" a tot el que em proposa, després de la
> revisió que dura unes 8 hores o més:
> 
> 
> https://upload.disroot.org/r/kRLsL2RX#bF9doWYguCMHAvj3APaJNb+GbUBq9zCX2mdrkLJhMAQ=
> 
> 
> 
> https://upload.disroot.org/r/sYqhJfcy#Wv3pVBo0OuvfosT/i1LfCRx+6sTWwSkpWGDJIl4uTkI=
> 
> 
> 
> https://upload.disroot.org/r/UTbxj19F#u5TA97h7ykB7KFj58OSPhgFLqwqFBSv00nHAQ8FoPpU=
> 
> 
> 
> Llavors, les meves preguntes:
> 
> 1) Us sembla que és un fallo de hard (el disc comença a fer el tonto,
> amb només 15 mesos), i ja em puc espabilar a comprar-ne un altra i
> fer-li un clonezilla?
> 
> 2) Podria ser un problema originat pel software? (en aquest sentit no
> sé si actualitzar la meva Debian Testing, que no actualitzo en general
> de cop, sinó a bocinets).
> 
> 3) No sé si al disc secundari és fa un fsck (o com es digui). Allò que
> es fa al primari cada nosequantes arrencades. Diria que no, i que és
> una opció configurable al fstab. El meu fstab és aquest:
> 
> UUID=... /               ext4    errors=remount-ro 0       1
> # /home was on /dev/sdb6 during installation
> 

Re: Una de discs durs

2021-01-03 Conversa Eloi

El 3/1/21 a les 11:59, Eloi ha escrit:

Responc entre línies i tallant part del missatge.

El 3/1/21 a les 9:01, Joan ha escrit:

[...]

Llavors, les meves preguntes:

1) Us sembla que és un fallo de hard (el disc comença a fer el tonto,
amb només 15 mesos), i ja em puc espabilar a comprar-ne un altra i
fer-li un clonezilla?


Una forma de determinar si és problema de maquinari seria fent servir 
badblocks, no per marcar els sectors defectuosos sinó simplement per 
saber si n'hi ha. En el teu cas, com que el disc és molt gran, 
necessitaries passar un paràmetre addicional. Pots provar això:


badblocks -b 4096 -e 1 -s -v /dev/

En detall: -b 4096 perquè el disc és gran (sense ell es nega a 
funcionar), -e 1 per parar al primer error que trobi, -s per tenir 
alguna cosa a mirar mentre va fent i -v perquè xerri una mica més.


Això sí, trigarà ESTONA (per a un disc de 4TB podria arribar a les 24 
hores) i mentrestant el disc hauria d'estar desmuntat.
Per cert, una puntualització important: el fet que trobi errors no vol 
dir necessàriament que estiguin al disc físic, doncs com bé s'ha 
comentat també podria ser problema del connector. Per filar més prim, si 
els errors passen sempre als mateixos sectors m'inclinaria a pensar en 
un problema propi del disc, però si passen a sectors diferents de forma 
aparentment aleatòria seria senyal que el problema està en la comunicació.




Re: Una de discs durs

2021-01-03 Conversa Eloi

Responc entre línies i tallant part del missatge.

El 3/1/21 a les 9:01, Joan ha escrit:

[...]

Llavors, les meves preguntes:

1) Us sembla que és un fallo de hard (el disc comença a fer el tonto,
amb només 15 mesos), i ja em puc espabilar a comprar-ne un altra i
fer-li un clonezilla?


Una forma de determinar si és problema de maquinari seria fent servir 
badblocks, no per marcar els sectors defectuosos sinó simplement per 
saber si n'hi ha. En el teu cas, com que el disc és molt gran, 
necessitaries passar un paràmetre addicional. Pots provar això:


badblocks -b 4096 -e 1 -s -v /dev/

En detall: -b 4096 perquè el disc és gran (sense ell es nega a 
funcionar), -e 1 per parar al primer error que trobi, -s per tenir 
alguna cosa a mirar mentre va fent i -v perquè xerri una mica més.


Això sí, trigarà ESTONA (per a un disc de 4TB podria arribar a les 24 
hores) i mentrestant el disc hauria d'estar desmuntat.



2) Podria ser un problema originat pel software? (en aquest sentit no
sé si actualitzar la meva Debian Testing, que no actualitzo en general
de cop, sinó a bocinets).


El mal (si és que es tracta d'un error de programari, que seria estrany) 
ja està fet, a més si com dius el problema el tens en un disc secundari 
en principi actualitzar hauria de ser més o menys neutre. Potser l'única 
excepció seria si tens muntat /home allà i a l'arrencar de nou algun 
programa actualitzat comenci una migració de dades que compliqui encara 
més el tema.


Però vaja, per la meva experiència la causa més comuna d'errades 
massives de disc seria una apagada intempestiva, com quan se'n va la 
llum o desendolles el disc, si és extern, mentre encara treballa. Les 
errades físiques de disc solen ser més puntuals, a menys que el disc ja 
portés temps amb problemes.



3) No sé si al disc secundari és fa un fsck (o com es digui). Allò que
es fa al primari cada nosequantes arrencades. Diria que no, i que és
una opció configurable al fstab. El meu fstab és aquest:

UUID=... /   ext4errors=remount-ro 0   1
# /home was on /dev/sdb6 during installation
UUID=... /home   ext4defaults0   2
# swap was on /dev/sdb5 during installation
UUID=...swapsw  0   0
# Segon disc dur 4Tb
UUID=e... /media/magatzem   ext4defaults0   2

(de fet, ara que hi penso, no sé si es fa el fsck a la partició /home,
tampoc). Diria que això te a veure amb el darrer nombre de la columna,
però ara he vist que systemd s'ho munta diferent i només distingeix el
valor zero (o buit), i la resta:

https://unix.stackexchange.com/a/248578

I per tant ja no sé quan ni com es fan el txequejos.


El que determina el 1 o el 2 de l'última columna de fstab és en quin 
moment de l'arrencada cridar el fsck. Generalment es posa un 1 al 
sistema arrel (aleshores fsck s'executa des del ramdisk de l'init) i un 
2 per a la resta (fent servir, aquest cop, el fsck del sistema arrel). 
La idea era evitar que un fsck sobre un disc amb problemes fos el 
responsable de comprovar-lo.


El fet de determinar, per a sistemes ext*, si passar efectivament o no 
un fsck ve determinat per dues condicions: primer, si el sistema s'ha 
desmuntat incorrectament, queda un indicador al disc i quan el detecta 
fa la comprovació. Si no és el cas, el sistema de fitxers registra tant 
els dies que han passat com els cops que s'ha muntat des de l'últim 
fsck, i quan algun d'aquests dos valors supera un límit configurable 
aleshores fa la comprovació.


Per mirar tant quan fa que s'ha passat un fsck com la programació dels 
límits pots fer servir la comanda següent:


dumpe2fs -h /dev/XXX

Per exemple, entre altres línies treu:

Mount count:  10
Maximum mount count:  25
Last checked: Sun Oct 18 10:11:18 2020
Check interval:   7776000 (3 months)
Next check after: Sat Jan 16 09:11:18 2021

En aquest cas, he muntat el disc 10 vegades des de l'última comprovació, 
que es va fer el 18 d'octubre passat, i està programat perquè faci la 
següent comprovació després de muntar el disc 25 cops (o sigui, d'aquí 
15 muntades més) o al cap de 3 mesos (el 16 de gener), el que succeeixi 
abans.


Per ajustar els valors dels marges pots fer servir tune2fs, passant -c i 
un número de recompte de muntatges (25) o -i i un marge de temps en dies 
(90).


Tingues present, però, que un valor 0 al fstab per a les comprovacions 
pot fer i farà que aquests límits no s'apliquin de forma automàtica sinó 
quan facis tu manualment un fsck, motiu pel qual a vegades llançant-lo 
manualment (sense -f) no fa res i a vegades ho fa tot: els criteris per 
decidir-ho són els mateixos.



4) Un colega em va comentar que ell força un test SMART via script, no
sé si a l'arrencar... No sé si això és una bona opció... Teniu algun
suggeriment al respecte, per vetllar per la bona salut dels discs
(assumint que si el disc comença a fallar per la seva obsolescència
programada, no hi ha res a fer).


El 

Re: Una de discs durs

2021-01-03 Conversa Joan
Merci Josep,

Un amic m'ha comentat que ell també va sol·lucionar un problema
semblant canviant el cable. Així que provaré això primer...

-- 
Joan Cervan i Andreu
http://personal.calbasi.net

"El meu paper no és transformar el món ni l'home sinó, potser, el de
ser útil, des del meu lloc, als pocs valors sense els quals un món no
val la pena viure'l" A. Camus

i pels que teniu fe:
"Déu no és la Veritat, la Veritat és Déu"
Gandhi


El Sun, 3 Jan 2021 09:29:35 +0100
Josep Lladonosa  va escriure:

> Hola, Joan,
> 
> 
> Que no sigui cosa del cable SATA.
> A la feina hem tingut experiències similars i canviant-lo s'ha resolt.
> 
> La fiabilitat dels discs durs és poca, sempre és recomanable tenir
> còpies de seguretat i fer-los treballar per parelles, en raid 1, per
> exemple.
> 
> Cada fabricant indica la seva garantia.
> Per a mi, els pitjors, Seagate. Els millors, Hitachi (HGST que crec
> que és de Western Digital, ara, i que també està bé).
> 
> Bon any,
> Josep
> 
> El dg., 3 de gen. 2021, 9:01, Joan  va escriure:
> 
> > El problema que tinc m'ha passat dugues vegades en dugues setmanes,
> > i tinc dubtes de si és un tema físic del disc (un disc SATA de 4Tb)
> > no massa vell, de potser un parell d'anys, o un problema del soft
> > que "desgabella" el disc
> >
> > És un disc secundari (el sistema el tinc en un SSD) a on guardo
> > videos, fotos, etc. Un dels meus sospitosos com a causa de tot
> > plegat podria ser l'amule.
> >
> > Bé, la qüestió és que quan arrenco el sistema la cosa va malament, i
> > queda en mode d'emergència, perquè detecta un error:
> >
> > de gen. 02 16:21:12 pc2019 systemd-fsck[502]: magatzem: Inode
> > 38666373 has an invalid extent node (blk 154697780, lblk 0) de gen.
> > 02 16:21:12 pc2019 systemd-fsck[502]: magatzem: UNEXPECTED
> > INCONSISTENCY; RUN fsck MANUALLY. de gen. 02 16:21:12 pc2019
> > systemd-fsck[502]: (i.e., without -a or -p options) de gen.
> > 02 16:21:12 pc2019 systemd-fsck[430]: fsck failed with exit status
> > 4. de gen. 02 16:21:12 pc2019 systemd-fsck[430]: Running request
> > emergency.target/start/replace de gen. 02 16:21:12 pc2019
> > systemd[1]: systemd-fsck@dev-disk-by
> > \x2duuid-eabfd9a3\x2d1b1f\x2d4144\x2da9d3\x2dd514566fa3fb.service:
> > Main process exited, code=exited, status=1/FAILURE de gen. 02
> > 16:21:12 pc2019 systemd[1]:
> > systemd-fsck@dev-disk-by
> > \x2duuid-eabfd9a3\x2d1b1f\x2d4144\x2da9d3\x2dd514566fa3fb.service:
> > Failed with result 'exit-code'. de gen. 02 16:21:12 pc2019
> > systemd[1]: Failed to start File System Check on
> > /dev/disk/by-uuid/eabfd9a3-1b1f-4144-a9d3-d514566fa3fb. de gen. 02
> > 16:21:12 pc2019 systemd[1]: Dependency failed for /media/magatzem.
> > de gen. 02 16:21:12 pc2019 systemd[1]: Dependency failed for Local
> > File Systems. de gen. 02 16:21:12 pc2019 systemd[1]:
> > local-fs.target: Job local-fs.target/start failed with result
> > 'dependency'. de gen. 02 16:21:12 pc2019 systemd[1]:
> > local-fs.target: Triggering OnFailure= dependencies. de gen. 02
> > 16:21:12 pc2019 systemd[1]: media-magatzem.mount: Job
> > media-magatzem.mount/start failed with result 'dependency'.
> >
> > I a mi em mostra aquesta pantalla:
> >
> >
> > https://upload.disroot.org/r/APnYtXLB#NArCJjbVYVzxd9Hui4K9xb9xhkHzk9i1vE++Qf8BQQA=
> >
> > Llavors jo per sol·lucionar-ho gaig un e2fsck -c /dev/sdb1
> >
> > Que em dona aquestes pantalles (les resumeixo, perquè bàsicament
> > son 20 minuts de anar dient "yes" a tot el que em proposa, després
> > de la revisió que dura unes 8 hores o més:
> >
> >
> > https://upload.disroot.org/r/kRLsL2RX#bF9doWYguCMHAvj3APaJNb+GbUBq9zCX2mdrkLJhMAQ=
> >
> > https://upload.disroot.org/r/sYqhJfcy#Wv3pVBo0OuvfosT/i1LfCRx+6sTWwSkpWGDJIl4uTkI=
> >
> > https://upload.disroot.org/r/UTbxj19F#u5TA97h7ykB7KFj58OSPhgFLqwqFBSv00nHAQ8FoPpU=
> >
> > Llavors, les meves preguntes:
> >
> > 1) Us sembla que és un fallo de hard (el disc comença a fer el
> > tonto, amb només 15 mesos), i ja em puc espabilar a comprar-ne un
> > altra i fer-li un clonezilla?
> >
> > 2) Podria ser un problema originat pel software? (en aquest sentit
> > no sé si actualitzar la meva Debian Testing, que no actualitzo en
> > general de cop, sinó a bocinets).
> >
> > 3) No sé si al disc secundari és fa un fsck (o com es digui). Allò
> > que es fa al primari cada nosequantes arrencades. Diria que no, i
> > que és una opció configurable al fstab. El meu fstab és aquest:
> >
> > UUID=... /   ext4errors=remount-ro 0   1
> > # /home was on /dev/sdb6 during installation
> > UUID=... /home   ext4defaults0   2
> > # swap was on /dev/sdb5 during installation
> > UUID=...swapsw  0   0
> > # Segon disc dur 4Tb
> > UUID=e... /media/magatzem   ext4defaults0
> > 2
> >
> > (de fet, ara que hi penso, no sé si es fa el fsck a la partició
> > /home, tampoc). Diria que això te a veure amb el darrer nombre de
> > la columna, però ara he vist que systemd s'ho munta 

Re: Una de discs durs

2021-01-03 Conversa Josep Lladonosa
Hola, Joan,


Que no sigui cosa del cable SATA.
A la feina hem tingut experiències similars i canviant-lo s'ha resolt.

La fiabilitat dels discs durs és poca, sempre és recomanable tenir còpies
de seguretat i fer-los treballar per parelles, en raid 1, per exemple.

Cada fabricant indica la seva garantia.
Per a mi, els pitjors, Seagate. Els millors, Hitachi (HGST que crec que és
de Western Digital, ara, i que també està bé).

Bon any,
Josep

El dg., 3 de gen. 2021, 9:01, Joan  va escriure:

> El problema que tinc m'ha passat dugues vegades en dugues setmanes, i
> tinc dubtes de si és un tema físic del disc (un disc SATA de 4Tb) no
> massa vell, de potser un parell d'anys, o un problema del soft que
> "desgabella" el disc
>
> És un disc secundari (el sistema el tinc en un SSD) a on guardo videos,
> fotos, etc. Un dels meus sospitosos com a causa de tot plegat podria
> ser l'amule.
>
> Bé, la qüestió és que quan arrenco el sistema la cosa va malament, i
> queda en mode d'emergència, perquè detecta un error:
>
> de gen. 02 16:21:12 pc2019 systemd-fsck[502]: magatzem: Inode 38666373
> has an invalid extent node (blk 154697780, lblk 0) de gen. 02 16:21:12
> pc2019 systemd-fsck[502]: magatzem: UNEXPECTED INCONSISTENCY; RUN fsck
> MANUALLY. de gen. 02 16:21:12 pc2019 systemd-fsck[502]: (i.e.,
> without -a or -p options) de gen. 02 16:21:12 pc2019 systemd-fsck[430]:
> fsck failed with exit status 4. de gen. 02 16:21:12 pc2019
> systemd-fsck[430]: Running request emergency.target/start/replace de
> gen. 02 16:21:12 pc2019 systemd[1]:
> systemd-fsck@dev-disk-by
> \x2duuid-eabfd9a3\x2d1b1f\x2d4144\x2da9d3\x2dd514566fa3fb.service:
> Main process exited, code=exited, status=1/FAILURE de gen. 02 16:21:12
> pc2019 systemd[1]:
> systemd-fsck@dev-disk-by
> \x2duuid-eabfd9a3\x2d1b1f\x2d4144\x2da9d3\x2dd514566fa3fb.service:
> Failed with result 'exit-code'. de gen. 02 16:21:12 pc2019 systemd[1]:
> Failed to start File System Check on
> /dev/disk/by-uuid/eabfd9a3-1b1f-4144-a9d3-d514566fa3fb. de gen. 02
> 16:21:12 pc2019 systemd[1]: Dependency failed for /media/magatzem. de
> gen. 02 16:21:12 pc2019 systemd[1]: Dependency failed for Local File
> Systems. de gen. 02 16:21:12 pc2019 systemd[1]: local-fs.target: Job
> local-fs.target/start failed with result 'dependency'. de gen. 02
> 16:21:12 pc2019 systemd[1]: local-fs.target: Triggering OnFailure=
> dependencies. de gen. 02 16:21:12 pc2019 systemd[1]:
> media-magatzem.mount: Job media-magatzem.mount/start failed with result
> 'dependency'.
>
> I a mi em mostra aquesta pantalla:
>
>
> https://upload.disroot.org/r/APnYtXLB#NArCJjbVYVzxd9Hui4K9xb9xhkHzk9i1vE++Qf8BQQA=
>
> Llavors jo per sol·lucionar-ho gaig un e2fsck -c /dev/sdb1
>
> Que em dona aquestes pantalles (les resumeixo, perquè bàsicament son 20
> minuts de anar dient "yes" a tot el que em proposa, després de la
> revisió que dura unes 8 hores o més:
>
>
> https://upload.disroot.org/r/kRLsL2RX#bF9doWYguCMHAvj3APaJNb+GbUBq9zCX2mdrkLJhMAQ=
>
> https://upload.disroot.org/r/sYqhJfcy#Wv3pVBo0OuvfosT/i1LfCRx+6sTWwSkpWGDJIl4uTkI=
>
> https://upload.disroot.org/r/UTbxj19F#u5TA97h7ykB7KFj58OSPhgFLqwqFBSv00nHAQ8FoPpU=
>
> Llavors, les meves preguntes:
>
> 1) Us sembla que és un fallo de hard (el disc comença a fer el tonto,
> amb només 15 mesos), i ja em puc espabilar a comprar-ne un altra i
> fer-li un clonezilla?
>
> 2) Podria ser un problema originat pel software? (en aquest sentit no
> sé si actualitzar la meva Debian Testing, que no actualitzo en general
> de cop, sinó a bocinets).
>
> 3) No sé si al disc secundari és fa un fsck (o com es digui). Allò que
> es fa al primari cada nosequantes arrencades. Diria que no, i que és
> una opció configurable al fstab. El meu fstab és aquest:
>
> UUID=... /   ext4errors=remount-ro 0   1
> # /home was on /dev/sdb6 during installation
> UUID=... /home   ext4defaults0   2
> # swap was on /dev/sdb5 during installation
> UUID=...swapsw  0   0
> # Segon disc dur 4Tb
> UUID=e... /media/magatzem   ext4defaults0   2
>
> (de fet, ara que hi penso, no sé si es fa el fsck a la partició /home,
> tampoc). Diria que això te a veure amb el darrer nombre de la columna,
> però ara he vist que systemd s'ho munta diferent i només distingeix el
> valor zero (o buit), i la resta:
>
> https://unix.stackexchange.com/a/248578
>
> I per tant ja no sé quan ni com es fan el txequejos.
>
> 4) Un colega em va comentar que ell força un test SMART via script, no
> sé si a l'arrencar... No sé si això és una bona opció... Teniu algun
> suggeriment al respecte, per vetllar per la bona salut dels discs
> (assumint que si el disc comença a fallar per la seva obsolescència
> programada, no hi ha res a fer).
>
> 5) Per cert, sabeu quina garantia tenen, els discos durs? I, en cas de
> comprar-ne un de nou, si n'hi ha que donin més fiabilitat?
>
> Fins ara!
>
> --
> Joan Cervan i Andreu
> http://personal.calbasi.net
>
>