---

Hejsa

Jeg har noget af verdens mest ustabile RAID sat op: partitioner på en
pata- og en sata-disk er parret i to raid-devices. De to partitioner
indeholder henholdsvis /boot og /home.

Men hvert andet øjeblik falder sata-partitionen ud af /home, mens /boot
som regel kører videre - og det til trods for at begge består af en
partitioner på de samme to diske (det er altså ikke sata-disken, der er
død... med mindre dårlige sektorer eller lignende på den ene partition
kan smadre det ene raid-device og lade det andet køre videre).

[root@Monster ~]# cat /proc/mdstat
Personalities : [raid1]
md1 : active raid1 sda5[1] hdb5[0]
2096384 blocks [2/2] [UU]

md0 : active raid1 sda6[2](F) hdb6[0]
117884864 blocks [2/1] [U_]

unused devices: <none>

I dag kan jeg så heller ikke hot-add'e disken igen:

[root@Monster ~]# mdadm /dev/md0 -a /dev/sda6
mdadm: hot add failed for /dev/sda6: Invalid argument

Men det kan måske forklares med følgende:

[root@Monster ~]# fdisk -l

Disk /dev/hda: 41.1 GB, 41174138880 bytes
255 heads, 63 sectors/track, 5005 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes

Device Boot Start End Blocks Id System
/dev/hda1 * 1 4972 39937558+ 7 HPFS/NTFS
/dev/hda2 4973 5005 265072+ 83 Linux

Disk /dev/hdb: 250.0 GB, 250059350016 bytes
255 heads, 63 sectors/track, 30401 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes

Device Boot Start End Blocks Id System
/dev/hdb1 * 1 4972 39937558+ 83 Linux
/dev/hdb2 4973 5005 265072+ 83 Linux
/dev/hdb3 5006 11085 48837600 c W95 FAT32 (LBA)
/dev/hdb4 11086 30401 155155770 85 Linux extended
/dev/hdb5 11086 11346 2096451 fd Linux raid autodetect
/dev/hdb6 11347 26022 117884938+ fd Linux raid autodetect

[her går fdisk i stå... den leder øjensynligt efter sata-disken, som af
uforklarlige grunde har forladt systemet i løbet af dagen]

Er grunden til, at md1 stadig ser ud til at virke, den, at der ikke
bliver skrevet noget på /boot, og at systemet derfor ikke opfatter, at
disken er væk?

Og så det gode spørgsmål: hvorfor er min sata-disk væk? Kan det være
en fysisk fejl på disken (den har ikke dårlige sektorer iflg.
badblocks)? Eller skal jeg kigge efter dårlige stik eller lignende?

Mig ikke finde ud... det træls...

--
Mvh.
/Thomas

---

On Fri, 20 May 2005 23:48:51 +0200, Thomas Lindgaard wrote:

> Og så det gode spørgsmål: hvorfor er min sata-disk væk?

Siger dmesg(8) ikke noget om hvad der er sket?

--
Stig

---

"Stig H. Jacobsen" wrote:
>
> On Fri, 20 May 2005 23:48:51 +0200, Thomas Lindgaard wrote:
>
> > Og så det gode spørgsmål: hvorfor er min sata-disk væk?
>
> Siger dmesg(8) ikke noget om hvad der er sket?

May 20 22:20:37 Monster kernel: nv_sata: Primary device removed
May 20 22:20:37 Monster kernel: nv_sata: Primary device added
May 20 22:20:37 Monster kernel: nv_sata: Primary device removed
May 20 22:21:07 Monster kernel: ata1: command 0xca timeout, stat 0x80 host_stat 0x1
May 20 22:21:07 Monster kernel: ata1: status=0x80 { Busy }
May 20 22:21:07 Monster kernel: SCSI error : <0 0 0 0> return code = 0x8000002
May 20 22:21:07 Monster kernel: sda: Current: sense key: Aborted Command
May 20 22:21:07 Monster kernel: Additional sense: Scsi parity error
May 20 22:21:07 Monster kernel: end_request: I/O error, dev sda, sector 240091276
May 20 22:21:07 Monster kernel: md: write_disk_sb failed for device sda6
May 20 22:21:07 Monster kernel: md: errors occurred during superblock update, repeating
May 20 22:21:07 Monster kernel: ATA: abnormal status 0x80 on port 0x9F7
May 20 22:21:07 Monster kernel: ATA: abnormal status 0x80 on port 0x9F7

--
Kasper Dupont -- der bruger for meget tid på usenet.
Note to self: Don't try to allocate 256000 pages
with GFP_KERNEL on x86.

---

Kasper Dupont <kasperd@daimi.au.dk> writes:

> May 20 22:21:07 Monster kernel: ata1: command 0xca timeout, stat 0x80 host_stat 0x1
> May 20 22:21:07 Monster kernel: ata1: status=0x80 { Busy }
> May 20 22:21:07 Monster kernel: SCSI error : <0 0 0 0> return code = 0x8000002
> May 20 22:21:07 Monster kernel: sda: Current: sense key: Aborted Command
> May 20 22:21:07 Monster kernel: Additional sense: Scsi parity error
> May 20 22:21:07 Monster kernel: end_request: I/O error, dev sda, sector 240091276
> May 20 22:21:07 Monster kernel: md: write_disk_sb failed for device sda6

Måske skulle du prøve at se om sda6 er ved at gå i smadder?

Har dette system nogensinde fungeret som ønsket, eller er det kommet
til senere?
--
Thorbjørn Ravn Andersen
http://www.unixsnedkeren.dk - Unix, Java, Web, Netværk, Århus

---

On Sat, 21 May 2005 07:50:28 +0200, Thorbjoern Ravn Andersen wrote:

> Måske skulle du prøve at se om sda6 er ved at gå i smadder?

Det var det, jeg var bange for, men det ser ikke ud til at være
tilfældet - ingen dårlige sektorer og disken er kun godt et halvt år
gammel...

> Har dette system nogensinde fungeret som ønsket, eller er det kommet
> til senere?

Det har fungeret fint tidligere.

Jeg har muligvis lokaliseret fejlen. Det viser sig, at der er noget der
trykker på sata-stikket inde i maskinen, så jeg tror simpelthen, at det
bliver trykket skævt og dermed mister forbindelsen til disken. I aftes
trykkede jeg stikkene på plads, og i dag er disken igen på sin pind.

[root@Monster ~]# mdadm /dev/md0 -a /dev/sda6
mdadm: hot added /dev/sda6

md0 : active raid1 sda6[2] hdb6[0]
117884864 blocks [2/1] [U_]
[>....................] recovery = 1.9% (2332864/117884864) finish=49.7min speed=38670K/sec

Det er vist bare et spørgsmål om gaffa...

--
Mvh.
/Thomas

---

Den Sat, 21 May 2005 09:23:51 +0200 skrev Thomas Lindgaard:
> On Sat, 21 May 2005 07:50:28 +0200, Thorbjoern Ravn Andersen wrote:
>
>> Måske skulle du prøve at se om sda6 er ved at gå i smadder?
>
> Det var det, jeg var bange for, men det ser ikke ud til at være
> tilfældet - ingen dårlige sektorer og disken er kun godt et halvt år
> gammel...

Sektorerne er ikke særligt relevante her, det er mere en defekt
kommunikationschip på disken der kunne overvejes. Eller for den sags
skyld sata-controlleren, hvis det er den eneste disk.

> Jeg har muligvis lokaliseret fejlen. Det viser sig, at der er noget der
> trykker på sata-stikket inde i maskinen, så jeg tror simpelthen, at det
> bliver trykket skævt og dermed mister forbindelsen til disken. I aftes
> trykkede jeg stikkene på plads, og i dag er disken igen på sin pind.

Jeg skulle lige til at foreslå løse kabler...

Mvh
Kent
--
Hard work may pay off in the long run, but lazyness pays off right now.

---

Thomas Lindgaard wrote:
>
> On Sat, 21 May 2005 07:50:28 +0200, Thorbjoern Ravn Andersen wrote:
>
> > Måske skulle du prøve at se om sda6 er ved at gå i smadder?
>
> Det var det, jeg var bange for, men det ser ikke ud til at være
> tilfældet - ingen dårlige sektorer og disken er kun godt et halvt år
> gammel...

Nej, jeg kan heller ikke se noget, der tyder på
dårlige sektorer. Det ligner mere et problem på
vejen fra driveren til elektronikken på disken.

>
> I aftes
> trykkede jeg stikkene på plads, og i dag er disken igen på sin pind.

Det var ikke længe, den blev der:

May 21 10:41:43 Monster kernel: md: md0: sync done.
May 21 10:41:43 Monster kernel: RAID1 conf printout:
May 21 10:41:43 Monster kernel: --- wd:2 rd:2
May 21 10:41:43 Monster kernel: disk 0, wo:0, o:1, dev:hdb6
May 21 10:41:43 Monster kernel: disk 1, wo:0, o:1, dev:sda6
May 21 10:44:38 Monster ntpd[4300]: time reset -2.875482 s
May 21 10:45:01 Monster crond(pam_unix)[9357]: session opened for user root by (uid=0)
May 21 10:45:01 Monster crond(pam_unix)[9357]: session closed for user root
May 21 10:46:57 Monster kernel: nv_sata: Primary device removed
May 21 10:46:57 Monster kernel: nv_sata: Primary device added
May 21 10:46:57 Monster kernel: nv_sata: Primary device removed
May 21 10:47:27 Monster kernel: ata1: command 0xca timeout, stat 0x80 host_stat 0x1
May 21 10:47:27 Monster kernel: ata1: status=0x80 { Busy }
May 21 10:47:27 Monster kernel: SCSI error : <0 0 0 0> return code = 0x8000002
May 21 10:47:27 Monster kernel: sda: Current: sense key: Aborted Command
May 21 10:47:27 Monster kernel: Additional sense: Scsi parity error
May 21 10:47:27 Monster kernel: end_request: I/O error, dev sda, sector 240091276
May 21 10:47:27 Monster kernel: ATA: abnormal status 0x80 on port 0x9F7
May 21 10:47:27 Monster last message repeated 2 times
May 21 10:47:27 Monster kernel: md: write_disk_sb failed for device sda6

Hmmm:
[root@Monster ~]# dmesg|sort|uniq -c
1 imary device removed
1272 nv_sata: Primary device added
2545 nv_sata: Primary device removed
[root@Monster ~]#

--
Kasper Dupont -- der bruger for meget tid på usenet.
Note to self: Don't try to allocate 256000 pages
with GFP_KERNEL on x86.

---

Thomas Lindgaard wrote:
> Hejsa
>
> Jeg har noget af verdens mest ustabile RAID sat op: partitioner på en
> pata- og en sata-disk er parret i to raid-devices. De to partitioner
> indeholder henholdsvis /boot og /home.
>
> Men hvert andet øjeblik falder sata-partitionen ud af /home, mens /boot
> som regel kører videre -

....

>
> Er grunden til, at md1 stadig ser ud til at virke, den, at der ikke
> bliver skrevet noget på /boot, og at systemet derfor ikke opfatter, at
> disken er væk?
>

Ja, det er helt normalt.

Prøv evt.

touch /boot/asdf
sync

og se, om den ikke markerer /boot som dårlig også.

Man kan manuelt markere en partition som dårlig
vha.

mdadm /dev/mdx -f /dev/sdax

så behøver man ikke touch&sync. Specielt praktisk på
swap partitioner, som ikke er i brug.

Mogens

--
Mogens Kjær, Dataarkæolog
Email: mk@datamuseum.dk
Homepage: http://www.datamuseum.dk

---

Thomas Lindgaard wrote:
>
> Er grunden til, at md1 stadig ser ud til at virke, den, at der ikke
> bliver skrevet noget på /boot, og at systemet derfor ikke opfatter, at
> disken er væk?

Næh, for md1 er din swap partition. Din /boot ligger på hda2.

--
Kasper Dupont -- der bruger for meget tid på usenet.
Note to self: Don't try to allocate 256000 pages
with GFP_KERNEL on x86.

---

On Sat, 21 May 2005 23:28:22 +0200, Kasper Dupont wrote:

>> Er grunden til, at md1 stadig ser ud til at virke, den, at der ikke
>> bliver skrevet noget på /boot, og at systemet derfor ikke opfatter, at
>> disken er væk?
>
> Næh, for md1 er din swap partition. Din /boot ligger på hda2.

Nå ja :) - men bortset fra det, så gælder det vel stadig at så længe
der ikke bliver brugt swap (skrevet til md1), så "opdager" maskinen ikke,
at den ene disk er gået i udu?

--
Mvh.
/Thomas

---

Thomas Lindgaard wrote:
>
> Nå ja :) - men bortset fra det, så gælder det vel stadig at så længe
> der ikke bliver brugt swap (skrevet til md1), så "opdager" maskinen ikke,
> at den ene disk er gået i udu?

Ja, det er rigtig nok. Den kan i teorien opdage det
ved en læsning. Det kræver bare, at der læses så
meget fra swap, at den begyndet at bruge begge diske.
En enkelt side i ny og næ bliver sikkert altid læst
fra den første disk, så opdager man jo ikke, at den
anden er stået af.

Vi ses.

--
Kasper Dupont -- der bruger for meget tid på usenet.
Note to self: Don't try to allocate 256000 pages
with GFP_KERNEL on x86.

---

Fri, 20 May 2005 23:48:51 +0200 brugte Thomas Lindgaard 68 linier på at
fortælle dette til dk.edb.system.unix:

>[root@Monster ~]# cat /proc/mdstat
>Personalities : [raid1]
>md1 : active raid1 sda5[1] hdb5[0]
> 2096384 blocks [2/2] [UU]
>
>md0 : active raid1 sda6[2](F) hdb6[0]
> 117884864 blocks [2/1] [U_]

Sad lige oglurede lidt på det her efter at have kigget i min egen
/proc/mdstat...

Hvad betyder de to U'er? Jeg kan næsten regne ud at de repræsenterer
diskene i arrayet, men i den nederste af ovenstående undrer jeg mig så over
at den bytter rundt på dem. Først skriver den (som jeg opfatter det) at
disk sda6 er failed, men at hdb6 er OK - og i næste linie at det er disk 2
i arrayet der er offline!?

--
Lars Rander ** Pil ikke ved min adresse ** :(){ :&:& };:
http://rander.dk (temporarily down!)

Medborgere med lave lønninger er erfaringsmæssigt mere udsat for forkølelser end
vellønnede. Det bedste middel mod snue er derfor lønforhøjelse. (Steve Mitchell)

---

Rander wrote:
>
> Fri, 20 May 2005 23:48:51 +0200 brugte Thomas Lindgaard 68 linier på at
> fortælle dette til dk.edb.system.unix:
>
> >[root@Monster ~]# cat /proc/mdstat
> >Personalities : [raid1]
> >md1 : active raid1 sda5[1] hdb5[0]
> > 2096384 blocks [2/2] [UU]
> >
> >md0 : active raid1 sda6[2](F) hdb6[0]
> > 117884864 blocks [2/1] [U_]
>
> Sad lige oglurede lidt på det her efter at have kigget i min egen
> /proc/mdstat...
>
> Hvad betyder de to U'er?

Jeg tror U'et står for up. Så de to U'er betyder
at begge diske virker.

> Jeg kan næsten regne ud at de repræsenterer
> diskene i arrayet, men i den nederste af ovenstående undrer jeg mig så over
> at den bytter rundt på dem.

Egentlig er det ikke i den anden linie, men
derimod i den første linie, der er byttet rundt.

> Først skriver den (som jeg opfatter det) at
> disk sda6 er failed, men at hdb6 er OK

Ja, det er korrekt. (F'et står godt nok for
faulty, ikke at det gør nogen forskel).

Hvad man også kan læse ud af den linie er, at
hdb6 er disk 0 i raidet, og sda6 er disk 2 i
raidet. Måske har sda6 været disk 1 i raidet
indtil den fejlede hvorefter den blev
omnummereret til at være disk 2. Havde der
været en spare ville den have fået nummer 1
efter en resynkronisering.

> - og i næste linie at det er disk 2
> i arrayet der er offline!?

Det er korrekt.

I øvrigt går raid1 ikke så meget op i det med
nummerering af diskene. Ved opstart tror jeg
bare de forskellige mirrors bliver nummereret i
den rækkefølge partitionerne er blevet detekteret.

Med raid5 og raid6 er det derimod vigtigt at
holde fuldstændigt styr på rækkefølgen.

--
Kasper Dupont -- der bruger for meget tid på usenet.
Note to self: Don't try to allocate 256000 pages
with GFP_KERNEL on x86.