- Mitglied seit
- 25 Dez 2008
- Beiträge
- 15
- Punkte für Reaktionen
- 0
- Punkte
- 0
Guten Morgen Forum,
bei mir tritt folgendes schwerwiegendes Problem auf.
An der FB hängt ein externes USB-RAID1 mit Ext3 als Dateisystem.
Das RAID macht nach einer Weile selbständig ein Spin-Down. So soll es ja auch sein. Will ich dann auf die Platte zugreifen will passiert folgendes:
WD Data Lifeguard Diagnostics bescheinigen der Platte einen tadellosen Zustand.
Ich vermute nun, das die Platte zu lange braucht um einen Spin-Up zu machen und dadurch ein Timeout in Form des "I/O error" hervorgerufen wird. Warum dann das System einfriert ist mir allerdings unklar.
Nun ein paar Fragen dazu:
Einen sonnigen Tag
Robert
Nachtrag [2009-01-08 11:10]:
Ich habe soeben versucht das ganze mal am Linux-PC zu reproduzieren - erfolglos.
Das System wartet wie gewünscht bis die Platte wieder hochgefahren hat.
Nachtrag [2009-01-08 14:06]:
Nachdem ich nun die HDD mit ext2 formatiert habe, kann zumindest ausgeschlossen werden, daß es am ext3 liegt:
Mir ist bis jetzt nicht klar ob das Problem generell bei Dateisystem zu suchen ist.
Nachtrag [2009-01-08 15:20]:
Nun ist die HDD mit NTFS formattiert. Und folgendes passiert:
Aber das System friert nicht mehr ein und ein 2ter Aufruf bringt dann:
Hat jemand eine Idee was da nun genau los ist?
Sind die Dateisystemtreiber so unterschiedlich implementiert?
bei mir tritt folgendes schwerwiegendes Problem auf.
An der FB hängt ein externes USB-RAID1 mit Ext3 als Dateisystem.
Das RAID macht nach einer Weile selbständig ein Spin-Down. So soll es ja auch sein. Will ich dann auf die Platte zugreifen will passiert folgendes:
Code:
/var/mod/root # cd /var/media/NEW_LINK/
/var/media/ftp/uStor01 # ls
: sense key=0x2
ASC=0x4 ASCQ=0x2
end_request: I/O error, dev sda, sector 1296302159
EXT3-fs error (device sda1): ext3_get_inode_loc:
- System friert ein
- Reboot
WD Data Lifeguard Diagnostics bescheinigen der Platte einen tadellosen Zustand.
Ich vermute nun, das die Platte zu lange braucht um einen Spin-Up zu machen und dadurch ein Timeout in Form des "I/O error" hervorgerufen wird. Warum dann das System einfriert ist mir allerdings unklar.
Nun ein paar Fragen dazu:
- Hatte schon jemand ein vergleichbares Problem? (laut SuFU anscheinend nicht)
- Kann man die "Timeouts" hochsetzen?
- Ist mit Ext2, ReiserFS oder NTFS ein identisches Verhalten zu erwarten?
Einen sonnigen Tag
Robert
Nachtrag [2009-01-08 11:10]:
Ich habe soeben versucht das ganze mal am Linux-PC zu reproduzieren - erfolglos.
Das System wartet wie gewünscht bis die Platte wieder hochgefahren hat.
Nachtrag [2009-01-08 14:06]:
Nachdem ich nun die HDD mit ext2 formatiert habe, kann zumindest ausgeschlossen werden, daß es am ext3 liegt:
Code:
/var/media/ftp/uStor01 # ls
: sense key=0x2
ASC=0x4 ASCQ=0x2
end_request: I/O error, dev sda, sector 1749286991
Nachtrag [2009-01-08 15:20]:
Nun ist die HDD mit NTFS formattiert. Und folgendes passiert:
Code:
/var/media/ftp/uStor01 # ls
: sense key=0x2
ASC=0x4 ASCQ=0x2
end_request: I/O error, dev sda, sector 6291583
Buffer I/O error on device sda1, logical block 786440
: sense key=0x2
ASC=0x4 ASCQ=0x2
end_request: I/O error, dev sda, sector 6291583
Buffer I/O error on device sda1, logical block 786440
ls: ./home: Input/output error
: sense key=0x2
ASC=0x4 ASCQ=0x2
end_request: I/O error, dev sda, sector 6291575
Buffer I/O error on device sda1, logical block 786439
: sense key=0x2
ASC=0x4 ASCQ=0x2
end_request: I/O error, dev sda, sector 6291575
Buffer I/O error on device sda1, logical block 786439
Code:
/var/media/ftp/uStor01 # ls
System Volume Information pool
home test
Sind die Dateisystemtreiber so unterschiedlich implementiert?
Zuletzt bearbeitet: