Hilfe, Platten crash (ide-scsi, lvm, reiserfs)

stl · 22. Juni 2006

Hi

ich glaub ich stehe hier kurz vor einem GAU im video Verzeichnis. Es ist natürlich kein RAID und Backups von ca. 500GB gibt es auch nicht. Es fing damit an, daß der Scan nach Aufnahmen merkwürdigerweise sehr sehr lang dauerte. In syslog kam ich dann auf folgende Meldung:

Code

Jun 22 05:17:56 farpoint kernel: scsi0: ERROR on channel 0, id 15, lun 0, CDB: Read (10) 00 03 94 d2 e0 00 00 08 00
Jun 22 05:17:56 farpoint kernel: Current sd08:40: sense key Medium Error
Jun 22 05:17:56 farpoint kernel: Additional sense indicates Unrecovered read error
Jun 22 05:17:56 farpoint kernel:  I/O error: dev 08:40, sector 60084960
Jun 22 05:17:56 farpoint kernel: lvm(58,1):vs-13070: reiserfs_read_inode2: i/o failure occurred trying to find stat data of [265 266 0x0 SD]
Jun 22 05:17:56 farpoint kernel: sym53c895-0-<15,*>: FAST-40 WIDE SCSI 80.0 MB/s (25.0 ns, offset 14)

Soweit sieht das ja noch nicht so schlimm aus. Aber jetzt noch mal zu meiner Umgebung: 2 IDE Platten bilden über IDE-SCSI Adapter und über LVM mit reiserfs das Video-Verzeichnis (/data/video).

Code

/dev/vg01/lv02       535937048 499186252  36750796  94% /data

Die SCSI devices sind /dev/sde und /dev/sdb. /dev/sdb ist logisch am Ende, da sie erst später hinzugefügt wurde. Was nun das ganze aber wohl zur Katastrophe machen wird ist die Tatsache, daß die Volume-Gruppe vg01 nicht mehr gefunden wird sondern nur noch vg00 wo sich die Homeverzeichnisse befinden. Ein

Code

vgcfgrestore -l -l -n vg01 -v -f /etc/lvmconf/vg01.conf  /dev/sde

gibt keine Fehlermeldung aus sondern nur:

Code

farpoint:~ # vgcfgrestore -l -l -n vg01 -v -f /etc/lvmconf/vg01.conf  /dev/sde
vgcfgrestore -- locking logical volume manager
vgcfgrestore -- restoring volume group "vg01" from "/etc/lvmconf/vg01.conf"
vgcfgrestore -- checking existence of "/etc/lvmconf/vg01.conf"
vgcfgrestore -- reading volume group data for "vg01" from "/etc/lvmconf/vg01.conf"
vgcfgrestore -- reading physical volume data for "vg01" from "/etc/lvmconf/vg01.conf"
vgcfgrestore -- reading logical volume data for "vg01" from "/etc/lvmconf/vg01.conf"
vgcfgrestore -- checking volume group consistency of "vg01"
vgcfgrestore -- checking volume group consistency of "vg01"
--- Volume group ---
VG Name               vg01
VG Access             read/write
VG Status             NOT available/resizable
VG #                  1
MAX LV                255
Cur LV                1
Open LV               0
MAX LV Size           1.00 TB
Max PV                255
Cur PV                2
Act PV                2
VG Size               558.78 GB
PE Size               32.00 MB
Total PE              17881
Alloc PE / Size       16356 / 511.12 GB
Free  PE / Size       1525 / 47.66 GB
VG UUID               QOShhy-bTvW-sBL6-z9L8-aEgS-q9rt-Kd8lMw


--- Logical volume ---
LV Name                /dev/vg01/lv02
VG Name                vg01
LV Write Access        read/write
LV Status              available
LV #                   1
# open                 0
LV Size                511.12 GB
Current LE             16356
Allocated LE           16356
Allocation             next free
Read ahead sectors     120
Block device           58:1




--- Physical volume ---
PV Name               /dev/sde
VG Name               vg01
PV Size               279.40 GB / NOT usable 55.67 MB [LVM: 158.00 KB]
PV#                   1
PV Status             available
Allocatable           yes (but full)
Cur LV                1
PE Size (KByte)       32768
Total PE              8939
Free PE               0
Allocated PE          8939
PV UUID               IheqIs-8lN7-GoSh-YTvX-LJdk-gtib-xSH6uY


--- Physical volume ---
PV Name               /dev/sdb
VG Name               vg01
PV Size               279.48 GB / NOT usable 44.82 MB [LVM: 158.00 KB]
PV#                   2
PV Status             available
Allocatable           yes
Cur LV                1
PE Size (KByte)       32768
Total PE              8942
Free PE               1525
Allocated PE          7417
PV UUID               ptD8W7-aPU9-G7kU-TLtw-8g71-orH0-KwzYdm
vgcfgrestore -- unlocking logical volume manager

Alles anzeigen

Wenn ich mir die ersten Sektoren mit dd anschaue, sieht das auch nicht sehr ermutigend aus:

Code

farpoint:/etc/lvmconf # dd if=/dev/sde bs=512 count=9|od -ax
9+0 records in
9+0 records out
0000000 nul nul nul nul nul nul nul nul nul nul nul nul nul nul nul nul
        0000 0000 0000 0000 0000 0000 0000 0000
*
0010000   Q   O   S   h   h   y   b   T   v   W   s   B   L   6   z   9
        4f51 6853 7968 5462 5776 4273 364c 397a
0010020   L   8   a   E   g   S   q   9   r   t   K   d   8   l   M   w
        384c 4561 5367 3971 7472 644b 6c38 774d
0010040 nul nul nul nul nul nul nul nul nul nul nul nul nul nul nul nul
        0000 0000 0000 0000 0000 0000 0000 0000
*
0010200 soh nul nul nul etx nul nul nul eot nul nul nul del nul nul nul
        0001 0000 0003 0000 0004 0000 00ff 0000
0010220 soh nul nul nul nul nul nul nul del nul nul nul stx nul nul nul
        0001 0000 0000 0000 00ff 0000 0002 0000
0010240 stx nul nul nul nul nul nul nul nul nul nul nul nul nul soh nul
        0002 0000 0000 0000 0000 0000 0000 0001
0010260   Y   E nul nul   d   ? nul nul nul nul nul nul nul nul nul nul
        45d9 0000 3fe4 0000 0000 0000 0000 0000
0010300 nul nul nul nul nul nul nul nul nul nul nul nul nul nul nul nul
        0000 0000 0000 0000 0000 0000 0000 0000
*
0011000

Alles anzeigen

Die Frage die sich mir stellt ist: Reboot oder noch weiterlaufen lassen und versuchen noch was auf externe Platten (noch kaufen) zu retten. Die möglichen Effekte sind:
Reboot - vg01 ist komplett hinüber
laufen lassen - der Fehler ist nach einiger Zeit (bis ich mir die ext. Platten besorgt habe) so schlimm geworden wie nach einem reboot :-(( .
Ich glaub die zweite möglich bietet die größer Wahrscheinlichkeit noch etwas zu retten. Na mal sehn wie sich das entwickelt.

Stefan Lucke

Nachtrag: ein pvscan liefert:

Code

farpoint:/etc/lvmconf # pvscan
pvscan -- reading all physical volumes (this may take a while...)
pvscan -- ACTIVE   PV "/dev/sda3" of VG "vg00" [15.02 GB / 2.32 GB free]
pvscan -- ACTIVE   PV "/dev/sdb"   is associated to an unknown VG (run vgscan)
pvscan -- inactive PV "/dev/sdc"  is in no VG  [111.82 GB]
pvscan -- inactive PV "/dev/sdd"  is in no VG  [114.50 GB]
pvscan -- total: 4 [520.82 GB] / in use: 2 [294.51 GB] / in no VG: 2 [226.31 GB]

PeterD · 22. Juni 2006

Zwar keine hilfe für dich, aber LVM ist für mich ohne RAID1,5,6 ein absolutes nogo.

Wird zwar einem LVM hier bei jedem problem mit mehreren /videoX verzeichnissen unter die nase gerieben, dein problem ist aber mal ein beispiel warum ich als simple konfiguration immer noch mehrere /videoX verzeichnisse LVM vorziehe.

Bei problemem einer platte im LVM ist meist alles futsch. Zumindestens endet das in ziemlichen restaurationsproblemen.
Mit mehreren /videoX verzeichnissen beschränken sich die probleme auf eine platte. Bei geschicktem umkopieren (jede aufnahme immer KOMPLETT auf einer platte) ist so nur ein teil der aufnahmen betroffen.
Da video nicht wirklich lebenswichtig ist, ist dieser teilverlust (meist) zu verschmerzen.

gruss Peter

P.S.
Sind das nun IDE oder SCSI platten ?
Wenn IDE wozu dann der krampf mit IDE-SCSI ?
Das musste ja irgendwann schiefgehen.
Oder ist das hardware ?

Ist auf dem LVM noch was anderes drauf ?
Wenn nicht einfach finger weg vom aufnahmeknopf und eventuell read only setzten damit VDR die finger von den daten nimmt.
Das sollte mögliche weitere logische zerstörung gering halten.

Wenn die platte aber einen weg hat wirds darurch nur schlimmer.
Eventuell mal S.M.A.R.T befragen wie der physische plattenstatus ist ?

knebb · 22. Juni 2006

So ganz blicke ich bei Deiner Konfig jetzt auch nicht durch.

Du hast vier Platten als PV genutzt, richtig? Du hast diese vier Platten auf zwei VGs verteilt, richtig? In welcher Reihenfolge?

Eine der Platten ist jetzt abgeraucht, richtig? Bist Du Dir sicher? Du hast noch nicht neu gebootet. Es kann durchaus vorkommen, daß Platten wegen Hitzeproblemen temporär den Geist aufgeben und später wieder funktionieren. Das BS behält aber dann den Fehlerstatus. Ein einfacher Reboot behebt das Problem.

Mehr Daten verlieren kannst Du durch den Reboot auch nicht. Die Platte ist jetzt eh' weg. ansonsten der alte Kühlschranktip, um die Platte temporär wieder zum Leben zu erwecken und die Daten runterzuziehen.

Man kann LVM auch eine andere Partition unterjubeln, so daß man die LVs wieder aktivieren kann und die Daten vom ersten Teil wiederherstellt. Bin ich jetzt aber im Moment überfragt.

[EDIT] Ach ja, PeterD nimmt mir die Worte aus dem Mund. Ich rede (schreibe) hier immer in Zusammenhang mit LVM, daß eine Verwendung ohne RAID absolut hochriskant ist. Aber naja, ist ja jeder selbst verantwortlich.[/EDIT]
Grüße

Christian

stl · 22. Juni 2006

Zitat

Originally posted by knebb
So ganz blicke ich bei Deiner Konfig jetzt auch nicht durch.

kann vorkommen

Zitat

Du hast vier Platten als PV genutzt, richtig?

Es sind leider 5, obwohl pvscan nur 4 liefert, /dev/sde fehlt.

Zitat

Du hast diese vier Platten auf zwei VGs verteilt, richtig?
In welcher Reihenfolge?

Von den 5 Platten sind 2 x 120GB nicht in einer VG (/dev/sdc & /dev/sdd). /dev/sda ist eine normale SCSI Platte (16GB), partitioniert und /dev/sda3 ist in VG00. In VG01 sind 2 x 300GB /dev/sde (erste Platte dieser VG) und /dev/sdb (zweite Platte mit 1525 free PEs).

Zitat

Eine der Platten ist jetzt abgeraucht, richtig? Bist Du Dir sicher? Du hast noch nicht neu gebootet.

(a) Noch nicht richtig, (b) nein, (c) ja, ich habe noch nicht neu gebootet.

Habe noch den Hinweis gefunden, mal sehen was sich daraus machen läßt: http://linux.msede.com/lvm_mlist/archive/2002/01/0336.html .

Ich sehe das ganze im Moment eher sportlich. Wenn die Videosachen weg sein sollten, dann sind sie halt weg. Mann war halt mit dabei und hat wieder was gelernt.

Wie gesagt/geschrieben: es hat mit einem tatsächlichen Lesefehler angefangen. Und aus irgendeinem Grund sind nun die ersten 8 Sektoren (4K) von /dev/sde mit Nullen überschrieben, sodaß pvscan sie nicht mehr als PV erkennt.

dd scheint beim Lesen auch mit bs=512 count=1 immer 4k (8 Sektoren) zulesen. Zumindest war mit skip=60084960 bis 60084967 nichts zu holen. Wird aber sg_dd verwendet mit if=/dev/sg5 (das ist /dev/sde) produzieren nur 60084960 bis 60084963 Lesefehler .

Richtig spannend wirds ja erst, wenn ich auf diesem System _ohne_ device-mapper den PE mit dem Lesefehler verbiegen möchte.

stl · 23. Juni 2006

Nachdem ich also vor dem Abgrund stand, bin ich nun einen Schritt weiter. Was ich so gefunden und gelesen machte mir eigentlich Hoffung und ich habe es mir erspart sogennante wichtige Videos auf ein externes Laufwerk zu retten. Wie zu erwarten war kam die VG (vg01) nach einem Reboot nicht online. Auch Tricks wie erneutes Anlegen, pvcreate mit manueller Manipulation der UUID auf die orginal UUID, konnte vgcfgrestore mit den vorhergenannten Parametern nicht dazu bringen irgendetwas zu restoren :-(( . Ein paar Stunden Schlaf später und einem Blick in die Sourcen von vgcfgrestore gab es einen AHA-Effekt. Die Optionen -l, -ll, -l -l wirken so wie die Option -t (_Test_). Nun also ein

Code

vgcfgrestore -n vg01 -f /etc/lvmconf/vg01.conf  /dev/sde

und das Ganze sah schon viel besser aus :-)) . Anschließend noch ein

Code

vgscan
vgchange -ay vg01
mount /dev/vg01/lv02 /data

und die Video sind wieder zugreifbar :-))) . Mal sehen wie ich die Sache mit dem Lesefehler noch behoben kriege. Bis dann.

Stefan Lucke

PeterD · 23. Juni 2006

Zitat

Original von stl
Nachdem ich also vor dem Abgrund stand, bin ich nun einen Schritt weiter.

Mal genau logisch überlegen wo du dann JETZT bist

AAAHHHHHHHHHHHHHHHHHhhhhhhhhhhhhh . . . . KLONK !

McMorning · 23. Juni 2006

PeterD

Ich find's klasse, wenn Leute einen Witz reißen (stl) und Leute den Spruch für voll nehmen.

Grüße,
McMorning

stl · 23. Juni 2006

PeterD:
Vielleicht habe ich mit der Anschlußweise mißverständlich ausgedrückt. Es sind IDE Platten, die über einen Hardware-Adapter an den SCSI-Bus angeschlossen sind.
http://www.acard-germany.de/produkte_aec7726h.html
Der zugehöhrige Ausschnitt aus /proc/scsi/scsi:

Code

Host: scsi0 Channel: 00 Id: 00 Lun: 00
  Vendor: FUJITSU  Model: MAJ3182MP        Rev: 0115
  Type:   Direct-Access                    ANSI SCSI revision: 04
Host: scsi0 Channel: 00 Id: 01 Lun: 00
  Vendor: ARCHIVE  Model: Python 28388-XXX Rev: 5ACB
  Type:   Sequential-Access                ANSI SCSI revision: 02
Host: scsi0 Channel: 00 Id: 12 Lun: 00
  Vendor: ATA      Model: Maxtor   7L300R0 Rev: BAJ4
  Type:   Direct-Access                    ANSI SCSI revision: 03
Host: scsi0 Channel: 00 Id: 13 Lun: 00
  Vendor: ATA      Model: SAMSUNG SV1204H  Rev: RK10
  Type:   Direct-Access                    ANSI SCSI revision: 03
Host: scsi0 Channel: 00 Id: 14 Lun: 00
  Vendor: ATA      Model: Maxtor   4G120J6 Rev: GAK8
  Type:   Direct-Access                    ANSI SCSI revision: 03
Host: scsi0 Channel: 00 Id: 15 Lun: 00
  Vendor: ATA      Model: Maxtor   5A300J0 Rev: RAMB
  Type:   Direct-Access                    ANSI SCSI revision: 03

Alles anzeigen

Der nächtste Schritt (nach dem Abgrund ist vor dem Abgrund): Ich habe also so ungefähr den betroffenen LV-Extend gefunden und dieses Kommando ausgeführt:

Code

pvmove -i -vv /dev/sde:915 /dev/sdb

Gottseidank gibt pvmove mit der Doppel-v-Option auch direkt die Sektornummern aus. Im vorhergehenden Testmodus bei der Verwendung der Option -t gab es natürlich keine Fehlermeldung, aber hier:

Code

pvmove -- checking name of source physical volume "/dev/sde"
pvmove -- locking logical volume manager
pvmove -- reading data of source physical volume from "/dev/sde"
pvmove -- checking volume group existence
pvmove -- reading data of volume group "vg01" from lvmtab
pvmove -- checking volume group consistency of "vg01"
pvmove -- searching for source physical volume "/dev/sde" in volume group "vg01"
pvmove -- building list of possible destination physical volumes
pvmove -- checking destination physical volume names in command line
pvmove -- checking volume group activity
pvmove -- moving physical extents in inactive volume group "vg01"
pvmove -- WARNING: if you lose power during the move you may need
        to restore your LVM metadata from backup!
pvmove -- do you want to continue? [y/n] y
pvmove -- starting to move extents away from physical volume "/dev/sde"
pvmove -- checking for enough free physical extents in "vg01"
lv: /dev/vg01/lv02[1]  old_dev: 08:64  new_dev: 08:16  old_pe_sector: 60031352  new_pe_sector: 486146424
pvmove -- opening output physical volume "/dev/sdb"
pvmove -- llseeking input physical volume "/dev/sde"
pvmove -- llseeking output physical volume "/dev/sdb"
pvmove -- /dev/sde [PE 915 [lv02 [LE 915]]] -> /dev/sdb [PE 7417] [1/1]
pvmove -- locking physical extent 915 of "/dev/sde" in kernel
pvmove -- about to read input physical volume "/dev/sde" and to write output physical volume "/dev/sdb"
pvmove -- ERROR "Input/output error" reading sector 60084744 from "/dev/sde"
pvmove -- ERROR "Input/output error" reading sector 60084745 from "/dev/sde"
pvmove -- ERROR "Input/output error" reading sector 60084746 from "/dev/sde"
pvmove -- ERROR "Input/output error" reading sector 60084747 from "/dev/sde"
pvmove -- ERROR "Input/output error" reading sector 60084748 from "/dev/sde"
-- sip --
pvmove -- ERROR "Input/output error" reading sector 60084998 from "/dev/sde"
pvmove -- ERROR "Input/output error" reading sector 60084999 from "/dev/sde"
pvmove -- remapping physical extent in VGDA of kernel
pvmove -- unlocking physical extent
pvmove -- changing source "/dev/sde" in VGDA of kernel
pvmove -- changing destination "/dev/sdb" in VGDA of kernel
-- snip --

Alles anzeigen

Was sagt mir das ? Insgesamt konnten also sage und schreibe 256 Sektoren nicht gelesen werden. Das merkwürdige daran ist nur, daß in /var/log/messages nur 2 ! Fehlermeldungen protokolliert wurden. Zu dem Sektor 60084744 und dem alten Bekannten 60084960. Also kam zunächst mal eine Leseübung mit sg_dd, gesteuert über ein kleines Script. Diese Meldungen sahen doch schon viel besser aus:

Code

farpoint:~ # ./fix_bad_lvm
error start  = 60031352
dest base    = 486146424
error offest = 53392
read start   = 60084744
write start  = 486199816
---------------------
reading from: /dev/sg5
writing to  : /dev/null
records to copy : 256
copy from 60084744 to 486199816 with: sg_dd bpt=1 bs=512 count=1 if=/dev/sg5 skip=60084744 of=/dev/null seek=486199816
1+0 records in
1+0 records out
copy from 60084745 to 486199817 with: sg_dd bpt=1 bs=512 count=1 if=/dev/sg5 skip=60084745 of=/dev/null seek=486199817
1+0 records in
1+0 records out
-- snip --
copy from 60084959 to 486200031 with: sg_dd bpt=1 bs=512 count=1 if=/dev/sg5 skip=60084959 of=/dev/null seek=486200031
1+0 records in
1+0 records out
copy from 60084960 to 486200032 with: sg_dd bpt=1 bs=512 count=1 if=/dev/sg5 skip=60084960 of=/dev/null seek=486200032
reading: scsi status: Check Condition
Current, Sense key: Medium Error
[valid=0] Info fld=0x0, Additional sense: Unrecovered read error
Raw sense data (in hex):
  70 00 03 00 00 00 00 08 00 00 00 00 11 00 00 00
plus...: Driver_status=0x28 (DRIVER_SENSE,SUGGEST_ABORT)
sg_read failed, skip=60084960
Some error occurred,  remaining block count=1
0+0 records in
0+0 records out
copy from 60084961 to 486200033 with: sg_dd bpt=1 bs=512 count=1 if=/dev/sg5 skip=60084961 of=/dev/null seek=486200033
reading: scsi status: Check Condition
Current, Sense key: Medium Error
[valid=0] Info fld=0x0, Additional sense: Unrecovered read error
Raw sense data (in hex):
  70 00 03 00 00 00 00 08 00 00 00 00 11 00 00 00
plus...: Driver_status=0x28 (DRIVER_SENSE,SUGGEST_ABORT)
sg_read failed, skip=60084961
Some error occurred,  remaining block count=1
0+0 records in
0+0 records out
copy from 60084962 to 486200034 with: sg_dd bpt=1 bs=512 count=1 if=/dev/sg5 skip=60084962 of=/dev/null seek=486200034
reading: scsi status: Check Condition
Current, Sense key: Medium Error
[valid=0] Info fld=0x0, Additional sense: Unrecovered read error
Raw sense data (in hex):
  70 00 03 00 00 00 00 08 00 00 00 00 11 00 00 00
plus...: Driver_status=0x28 (DRIVER_SENSE,SUGGEST_ABORT)
sg_read failed, skip=60084962
Some error occurred,  remaining block count=1
0+0 records in
0+0 records out
copy from 60084963 to 486200035 with: sg_dd bpt=1 bs=512 count=1 if=/dev/sg5 skip=60084963 of=/dev/null seek=486200035
1+0 records in
1+0 records out
-- snip --
copy from 60084999 to 486200071 with: sg_dd bpt=1 bs=512 count=1 if=/dev/sg5 skip=60084999 of=/dev/null seek=486200071
1+0 records in
1+0 records out

Alles anzeigen

Also nur noch drei defekte Sektoren. Wenn ich hier schon soviele Protokollausschnitte reinhänge, kommt es auf das kleine Script nun auch nicht an:

Bash

#!/bin/bash


in_device=/dev/sg5
#out_device=/dev/sdb
out_device=/dev/null


src_base=60031352
error_start=60084744
error_end=60084999


dest_base=486146424


error_offset=$[error_start-src_base]


read_start=$[src_base+error_offset]


write_start=$[dest_base+error_offset]


i=${read_start}
j=${write_start}


echo "error start  = $src_base"
echo "dest base    = $dest_base"
echo "error offest = $error_offset"
echo "read start   = $i"
echo "write start  = $j"


echo "---------------------"
echo "reading from: ${in_device}"
echo "writing to  : ${out_device}"
echo "records to copy : $[error_end-error_start+1]"




while [ $i -le ${error_end} ]
do
        echo -n "copy from $i to $j with: "


        echo "sg_dd bpt=1 bs=512 count=1 if=${in_device} skip=$i of=${out_device} seek=$j"
#       sg_dd bpt=1 bs=512 count=1 if=${in_device} skip=$i of=${out_device} seek=$j


        i=$[i+1]
        j=$[j+1]
done

Alles anzeigen

Nun ja. Das Videoverzeichnis ist immer noch zugreifbar, find meldet bei zwei Verzeichnissen Fehler wie vor der Verschiebeaktion. Ich denke das wars und muß mir nun schnellstens Ersatz für die eine 300GB Platte besorgen. Wenn jetzt noch jemand einen bösen Fehler in dem Script entdeckt, dann ...

hsteinhaus · 26. Juni 2006

Hi stl,

bei Bad Sectors (und danach siehts aus) solltest Du schnellstmöglich mit dd_rescue retten, was zu retten ist. Danach auf den erstellten Images die Daten retten, nicht auf der gerade sterbenden Originalplatte! Die BS werden in machen Fällen ganz schnell mehr...

Viele Grüße,
Holger

stl · 27. Juni 2006

Was ist da der Unterschied dd_rescue vs. sg_dd ? Sprich wie geht dd_rescue vor?
Die betreffende Platte ist übrigens auch eine MAXTOR wie bei Dir (hier eine 5A300J0). Hab mir mittlerweile eine WD 32000SB besorgt.

Hilfe, Platten crash (ide-scsi, lvm, reiserfs)

Jetzt mitmachen!

Teilen

Benutzer online in diesem Thema