---

Jeg har et software raid 1 på en debain server. Det har den fantastiske
egenskab at raidet er degraded efter hver reboot. Den ene disk meldes som
failed, men kan umiddelbart bare tilføjes igen, og så virker alt indtil
næste reboot. Nogen ideer til en løsning så der ikke skal rebuildes efter
hver reboot? Lige for klarheds skyld, så fejler disken intet.

--
/peter

The best things in life are postage paid, batteries included,
guaranteed forever and tax-free.

---

On Sun, 18 Dec 2005 02:13:23 +0100, Peter Kiil wrote:

> Jeg har et software raid 1 på en debain server. Det har den fantastiske
> egenskab at raidet er degraded efter hver reboot.

Hvordan ser /proc/mdstat ud efter boot? (før du tilføjer)

Hvad siger dmesg(8)/konsollen om den fejlede disk under boot?

Jeg kan ikke lige huske om /etc/raidtab bruges ved boot, men er
den som den skal være?

--
Stig

---

Stig H. Jacobsen - stighj-at-googles-mail@nospam.invalid on 18/12/05 3:21
wrote:

> On Sun, 18 Dec 2005 02:13:23 +0100, Peter Kiil wrote:
>
>> Jeg har et software raid 1 på en debain server. Det har den fantastiske
>> egenskab at raidet er degraded efter hver reboot.
>
> Hvordan ser /proc/mdstat ud efter boot? (før du tilføjer)

Personalities : [raid1]
md1 : active raid1 sdb1[0] sdd1[1]
71681920 blocks [2/2] [UU]

md0 : active raid1 sda1[0]
17089408 blocks [2/1] [U_]

unused devices: <none>

> Hvad siger dmesg(8)/konsollen om den fejlede disk under boot?

Jeg ved ikke helt hvad jeg skal kigge efter:

SCSI subsystem initialized
ACPI: PCI interrupt 0000:02:0a.0[A] -> GSI 29 (level, low) -> IRQ 177
sym0: <1010-66> rev 0x1 at pci 0000:02:0a.0 irq 177
sym0: using 64 bit DMA addressing
sym0: Symbios NVRAM, ID 7, Fast-80, LVD, parity checking
sym0: open drain IRQ line driver, using on-chip SRAM
sym0: using LOAD/STORE-based firmware.
sym0: handling phase mismatch from SCRIPTS.
sym0: SCAN AT BOOT disabled for targets 2 5 6 8 9 10 11 12 13 14 15.
sym0: SCSI BUS has been reset.
scsi0 : sym-2.1.18j
Using anticipatory io scheduler
Vendor: SEAGATE Model: ST318452LC Rev: 8501
Type: Direct-Access ANSI SCSI revision: 03
sym0:0:0: tagged command queuing enabled, command queue depth 16.
scsi(0:0:0:0): Beginning Domain Validation
sym0:0: wide asynchronous.
sym0:0: FAST-80 WIDE SCSI 160.0 MB/s DT (12.5 ns, offset 62)
scsi(0:0:0:0): Ending Domain Validation
Vendor: SEAGATE Model: ST373207LC Rev: 7807
Type: Direct-Access ANSI SCSI revision: 03
sym0:1:0: tagged command queuing enabled, command queue depth 16.
scsi(0:0:1:0): Beginning Domain Validation
sym0:1: wide asynchronous.
sym0:1: FAST-80 WIDE SCSI 160.0 MB/s DT (12.5 ns, offset 62)
scsi(0:0:1:0): Ending Domain Validation
Vendor: SEAGATE Model: ST318452LC Rev: 8501
Type: Direct-Access ANSI SCSI revision: 03
sym0:3:0: tagged command queuing enabled, command queue depth 16.
scsi(0:0:3:0): Beginning Domain Validation
sym0:3: wide asynchronous.
sym0:3: FAST-80 WIDE SCSI 160.0 MB/s DT (12.5 ns, offset 62)
scsi(0:0:3:0): Ending Domain Validation
Vendor: SEAGATE Model: ST373207LC Rev: 7807
Type: Direct-Access ANSI SCSI revision: 03
sym0:4:0: tagged command queuing enabled, command queue depth 16.
scsi(0:0:4:0): Beginning Domain Validation
sym0:4: wide asynchronous.
sym0:4: FAST-80 WIDE SCSI 160.0 MB/s DT (12.5 ns, offset 62)
scsi(0:0:4:0): Ending Domain Validation
SCSI device sda: 35843670 512-byte hdwr sectors (18352 MB)
SCSI device sda: drive cache: write back
/dev/scsi/host0/bus0/target0/lun0: p1 p2 < p5 >
Attached scsi disk sda at scsi0, channel 0, id 0, lun 0
SCSI device sdb: 143374744 512-byte hdwr sectors (73408 MB)
SCSI device sdb: drive cache: write through
/dev/scsi/host0/bus0/target1/lun0: p1
Attached scsi disk sdb at scsi0, channel 0, id 1, lun 0
SCSI device sdc: 35843670 512-byte hdwr sectors (18352 MB)
SCSI device sdc: drive cache: write back
/dev/scsi/host0/bus0/target3/lun0: p1
Attached scsi disk sdc at scsi0, channel 0, id 3, lun 0
SCSI device sdd: 143374744 512-byte hdwr sectors (73408 MB)
SCSI device sdd: drive cache: write through
/dev/scsi/host0/bus0/target4/lun0: p1
Attached scsi disk sdd at scsi0, channel 0, id 4, lun 0
md: md driver 0.90.0 MAX_MD_DEVS=256, MD_SB_DISKS=27
md: raid1 personality registered as nr 3
Generic RTC Driver v1.07
Uniform Multi-Platform E-IDE driver Revision: 7.00alpha2
ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx
hdc: SR244W, ATAPI CD/DVD-ROM drive
ide1 at 0x170-0x177,0x376 on irq 15
hdc: ATAPI 24X CD-ROM drive, 128kB Cache
Uniform CD-ROM driver Revision: 3.20
e100: Intel(R) PRO/100 Network Driver, 3.0.18
e100: Copyright(c) 1999-2004 Intel Corporation
ACPI: PCI interrupt 0000:00:05.0[A] -> GSI 30 (level, low) -> IRQ 169
e100: eth0: e100_probe: addr 0xfc101000, irq 169, MAC addr 00:30:05:1F:55:8A
usbcore: registered new driver usbfs
usbcore: registered new driver hub
ohci_hcd: 2004 Feb 02 USB 1.1 'Open' Host Controller (OHCI) Driver (PCI)
ohci_hcd: block sizes: ed 64 td 64
ACPI: PCI interrupt 0000:00:0f.2[A] -> GSI 11 (level, low) -> IRQ 11
ohci_hcd 0000:00:0f.2: ServerWorks OSB4/CSB5 OHCI USB Controller
ohci_hcd 0000:00:0f.2: irq 11, pci mem f8852000
ohci_hcd 0000:00:0f.2: new USB bus registered, assigned bus number 1
hub 1-0:1.0: USB hub found
hub 1-0:1.0: 4 ports detected
Linux agpgart interface v0.100 (c) Dave Jones
SvrWks CSB5: IDE controller at PCI slot 0000:00:0f.1
SvrWks CSB5: chipset revision 147
SvrWks CSB5: not 100% native mode: will probe irqs later
SvrWks CSB5: simplex device: DMA forced
ide0: BM-DMA at 0x1800-0x1807, BIOS settings: hda:pio, hdb:pio
SvrWks CSB5: port 0x0170 already claimed by ide1
md: md0 stopped.
md: bind<sda1>
raid1: raid set md0 active with 1 out of 2 mirrors
kjournald starting. Commit interval 5 seconds
EXT3-fs: mounted filesystem with ordered data mode.
Adding 831464k swap on /dev/sda5. Priority:-1 extents:1
EXT3 FS on md0, internal journal
Capability LSM initialized
md: md1 stopped.
md: bind<sdd1>
md: bind<sdb1>
raid1: raid set md1 active with 2 out of 2 mirrors
kjournald starting. Commit interval 5 seconds
EXT3 FS on md1, internal journal
EXT3-fs: mounted filesystem with ordered data mode.
e100: eth0: e100_watchdog: link up, 100Mbps, full-duplex
NET: Registered protocol family 10
Disabled Privacy Extensions on device c031e0c0(lo)
IPv6 over IPv4 tunneling driver
eth0: no IPv6 routers present

> Jeg kan ikke lige huske om /etc/raidtab bruges ved boot, men er
> den som den skal være?

Jeg har ikke nogen fil ved det navn. Er det ikke mdadm.conf der kigges
efter?

--
/peter

The best things in life are postage paid, batteries included,
guaranteed forever and tax-free.

---

Peter Kiil wrote:
>
> Stig H. Jacobsen - stighj-at-googles-mail@nospam.invalid on 18/12/05 3:21
> wrote:
>
> > Hvad siger dmesg(8)/konsollen om den fejlede disk under boot?
>
> Jeg ved ikke helt hvad jeg skal kigge efter:
>
> SCSI subsystem initialized
[...]
> eth0: no IPv6 routers present

Den log ser ikke komplet ud. Står der virkelig ikke
mere i loggen? Hvilken kerne version bruger du?

>
> > Jeg kan ikke lige huske om /etc/raidtab bruges ved boot, men er
> > den som den skal være?
>
> Jeg har ikke nogen fil ved det navn. Er det ikke mdadm.conf der kigges
> efter?

/etc/raidtab er egentlig noget forældet noget. Det
"nye" princip med metadata lagt på de enkelte
devices og autodetektering er bedre, og der er
ikke brug for nogen konfigurationsfil.

Så det er næppe i /etc du skal kigge efter
forklaringen. Er du 100% sikker på, at det er det
rigtige device du har tilføjet til raidet? (Jeg
har selv oplevet sære fejl, da jeg kom til at
skrive "hdg 1" i stedet for "hdg1", da der skulle
tilføjes et device til et raid).

Kernen finder tilsyneladende alle fire diske og
partitionerne derpå. Jeg undrer mig godt nok lidt
over at sda har flere partitioner end sdc. Er
sda1 og sdc1 lige store? Og har du overskydende
upartitioneret plads på sdc?

At dømme udfra outputtet tror jeg der er tale om
en 2.6 kerne, den er desværre ikke ligeså
snakkesalig som en 2.4 kerne, når det drejer sig
om detektering af raids. Er der nogen som kender
en kerne parameter som får den til at sige lidt
mere?

--
Kasper Dupont
Note to self: Don't try to allocate
256000 pages with GFP_KERNEL on x86.

---

Hej,

Kasper Dupont <kasperd@daimi.au.dk> writes:
> "nye" princip med metadata lagt på de enkelte
> devices og autodetektering er bedre, og der er
> ikke brug for nogen konfigurationsfil.
>
> Så det er næppe i /etc du skal kigge efter
> forklaringen.

Måske alligevel - check lige /etc/mdadm/mdadm.conf. Jeg synes at kunne
huske at init.d-scriptet til mdadm-raid læser konfigurationen fra
mdadm.conf - hvis filen findes.


/Claus A

---

Claus Alboege wrote:
>
> Hej,
>
> Kasper Dupont <kasperd@daimi.au.dk> writes:
> > "nye" princip med metadata lagt på de enkelte
> > devices og autodetektering er bedre, og der er
> > ikke brug for nogen konfigurationsfil.
> >
> > Så det er næppe i /etc du skal kigge efter
> > forklaringen.
>
> Måske alligevel - check lige /etc/mdadm/mdadm.conf. Jeg synes at kunne
> huske at init.d-scriptet til mdadm-raid læser konfigurationen fra
> mdadm.conf - hvis filen findes.

Det sker jo først på et senere tidspunkt under
opstarten. Problemet ligger jo allerede inden
den mounter root filsystemet.

--
Kasper Dupont
Note to self: Don't try to allocate
256000 pages with GFP_KERNEL on x86.

---

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

> Claus Alboege wrote:
>> Kasper Dupont <kasperd@daimi.au.dk> writes:
>> > "nye" princip med metadata lagt på de enkelte
>> > devices og autodetektering er bedre, og der er
>> > ikke brug for nogen konfigurationsfil.
>> >
>> > Så det er næppe i /etc du skal kigge efter
>> > forklaringen.
>>
>> Måske alligevel - check lige /etc/mdadm/mdadm.conf. Jeg synes at kunne
>> huske at init.d-scriptet til mdadm-raid læser konfigurationen fra
>> mdadm.conf - hvis filen findes.
>
> Det sker jo først på et senere tidspunkt under
> opstarten. Problemet ligger jo allerede inden
> den mounter root filsystemet.

Uh ja, det var egentlig også initrd-imaget jeg tænkte på. Der er vist en
fil deri, som angiver options til mdadm.

Peter kan du evt. prøve at mounte dit initrd-image (såfremt, du benytter
dig af initrd).

% sudo mkdir /tmp/initrd
% sudo mount -t cramfs -o loop /boot/initrd.img-`uname -r` /tmp/initrd
% cat /tmp/initrd/script
% sudo umount /tmp/initrd

(Hvis du ikke har sat sudo op, kan du bare udføre ovenstående som root)

Send outputtet fra 'cat' hertil.


/Claus A

---

Peter Kiil wrote:
> Jeg har et software raid 1 på en debain server. Det har den fantastiske
> egenskab at raidet er degraded efter hver reboot. Den ene disk meldes som
> failed, men kan umiddelbart bare tilføjes igen, og så virker alt indtil
> næste reboot. Nogen ideer til en løsning så der ikke skal rebuildes efter
> hver reboot? Lige for klarheds skyld, så fejler disken intet.

Mit RAID1 på en Sarge maskine har en enkelt gang lavet noget
tilsvarende. Jeg gætter på at der er nogle generelle fejl i dit IDE
system, der gør at disken under specielle forhold (lige efter boot) ser
defekt ud for md-systemet.
Det kunne for eksempel skyldes dårlige/for lange kabler. Har du checket
om ikke der er nogle DMA-fejl i dmesg eller syslog?

Peter

---

Peter Mogensen - apm-at-mutex-dot-dk@nospam.no on 18/12/05 11:52 wrote:

>> Jeg har et software raid 1 på en debain server. Det har den fantastiske
>> egenskab at raidet er degraded efter hver reboot. Den ene disk meldes som
>> failed, men kan umiddelbart bare tilføjes igen, og så virker alt indtil
>> næste reboot. Nogen ideer til en løsning så der ikke skal rebuildes efter
>> hver reboot? Lige for klarheds skyld, så fejler disken intet.
>
> Mit RAID1 på en Sarge maskine har en enkelt gang lavet noget
> tilsvarende. Jeg gætter på at der er nogle generelle fejl i dit IDE
> system, der gør at disken under specielle forhold (lige efter boot) ser
> defekt ud for md-systemet.
> Det kunne for eksempel skyldes dårlige/for lange kabler. Har du checket
> om ikke der er nogle DMA-fejl i dmesg eller syslog?

Jeg skylder måske at fortælle at det drejer sig om 2 SCSI diske i en Fujitsi
Siemens P250 server, monteret i skuffer. Kabler er max. 40 cm. lange.
Kabelfejl burde vel også være til stede altid, og ikke kun under reboot?

--
/peter

The best things in life are postage paid, batteries included,
guaranteed forever and tax-free.

---

On Sun, 18 Dec 2005 18:36:26 +0100, Peter Kiil wrote:

>
> Jeg skylder måske at fortælle at det drejer sig om 2 SCSI diske i en
> Fujitsi Siemens P250 server, monteret i skuffer. Kabler er max. 40 cm.
> lange. Kabelfejl burde vel også være til stede altid, og ikke kun under
> reboot?
Når det nu er scsi, kunne det også være et termineringsproblem?
--
Hilsen/Regards
Michael Rasmussen
http://keyserver.veridis.com:11371/pks/lookup?op=get&search=0xE3E80917

---

Michael Rasmussen - mir@miras.org on 18/12/05 18:42 wrote:

>> Jeg skylder måske at fortælle at det drejer sig om 2 SCSI diske i en
>> Fujitsi Siemens P250 server, monteret i skuffer. Kabler er max. 40 cm.
>> lange. Kabelfejl burde vel også være til stede altid, og ikke kun under
>> reboot?
> Når det nu er scsi, kunne det også være et termineringsproblem?

Jeg tvivler på det, da serveren er udstyret med et fabriksleveret disk
system. Hotplug skufferne er forbundet direkte til motherboardet, og bruger
den onboard scsi-controller.
--
/peter

The best things in life are postage paid, batteries included,
guaranteed forever and tax-free.

---

Peter Kiil wrote:
>
> Jeg har et software raid 1 på en debain server. Det har den fantastiske
> egenskab at raidet er degraded efter hver reboot. Den ene disk meldes som
> failed, men kan umiddelbart bare tilføjes igen, og så virker alt indtil
> næste reboot. Nogen ideer til en løsning så der ikke skal rebuildes efter
> hver reboot? Lige for klarheds skyld, så fejler disken intet.

Jeg havde samme problem på en Fedora Core 1. I mit
tilfælde var årsagen, at jeg havde glemt at sætte
den rigtige partitionstype. Som regel vil den
foretrukne type være Linux Raid Autodetect (type
fd). Du kan bruge "fdisk -l" for at se, hvad typen
er sat til.

--
Kasper Dupont
Note to self: Don't try to allocate
256000 pages with GFP_KERNEL on x86.

---

Kasper Dupont - kasperd@daimi.au.dk on 18/12/05 14:09 wrote:

> Jeg havde samme problem på en Fedora Core 1. I mit
> tilfælde var årsagen, at jeg havde glemt at sætte
> den rigtige partitionstype. Som regel vil den
> foretrukne type være Linux Raid Autodetect (type
> fd). Du kan bruge "fdisk -l" for at se, hvad typen
> er sat til.

Begge diske har den rigtige type:

/dev/sda1 1 16689 17089520 fd Linux raid autodetect
/dev/sdc1 1 16689 17089520 fd Linux raid autodetect

--
/peter

The best things in life are postage paid, batteries included,
guaranteed forever and tax-free.