[Format recovered--see http://www.lemis.com/email/email-format.html]
Überlange Zeilen
On Monday, 18 August 2003 at 15:52:26 +0200, Oskar Eyb wrote:
>> moooment, jetzt bin ich leicht verwirrt:
>> ich verstehe nicht, warum die stripesets (tmp, data2), die auch auf ad0 liegen,
>> wo fsck die fehler meldet, augenscheinlich FUNKTIONIEREN.
>
> Nun habe ich kurzerhand ad0s1a mit newfs formatieren lassen,
Warum denn das? Das ist so gut wie nie notwendig.
> dies,
Was?
> und nun auch fsck machen keine Fehler.
Ohne nähere Angaben ist diese Aussage bedeutungslos.
> Nun blicke ich langsam wieder durch.
Ich nicht.
> Da das rootfs auf ad4s1a liegt musste ich am loader-prompt die
> Stelle angeben
>
> boot: ad(4,a)/kernel
>
> Jetzt kommen auch keine "invalid systemcall" - etc - errors am
> sh-promt. Vermutlich wurde zuvor von der defekten ad0s1a
> gebootet. Das dies in der Vergangenheit funktionierte und auf einmal
> nichtmehr wird dann wohl doch am neuen world oder so gelegen haben.
>
> die aktuellen vinum-Ausgaben über die serielle console lauten:
> P alcajail.p0 C State: flaky Subdisks: 1 Size: 5120 MB
> P alcajail.p1 C State: flaky Subdisks: 1 Size: 5120 MB
> P alcausr.p0 C State: flaky Subdisks: 1 Size: 17 GB
> P alcausr.p1 C State: flaky Subdisks: 1 Size: 17 GB
> P alcadata1.p0 C State: flaky Subdisks: 1 Size: 49 GB
> P alcadata1.p1 C State: flaky Subdisks: 1 Size: 49 GB
> S alcajail.p0.s0 State: reborn PO: 0 B Size: 5120 MB
> S alcajail.p1.s0 State: reborn PO: 0 B Size: 5120 MB
> S alcausr.p0.s0 State: reborn PO: 0 B Size: 17 GB
> S alcausr.p1.s0 State: reborn PO: 0 B Size: 17 GB
> S alcadata1.p0.s0 State: reborn PO: 0 B Size: 49 GB
> S alcadata1.p1.s0 State: reborn PO: 0 B Size: 49 GB
>
> /dev/vinum/alcausr: CANNOT READ: BLK 16
> /dev/vinum/alcausr: UNEXPECTED INCONSISTENCY; RUN fsck MANUALLY.
> /dev/vinum/alcajail: CANNOT READ: BLK 16
> /dev/vinum/alcajail: UNEXPECTED INCONSISTENCY; RUN fsck MANUALLY.
> /dev/vinum/alcadata1: CANNOT READ: BLK 16
> /dev/vinum/alcadata1: UNEXPECTED INCONSISTENCY; RUN fsck MANUALLY.
> /dev/vinum/alcatmp: FILESYSTEM CLEAN; SKIPPING CHECKS
> /dev/vinum/alcatmp: clean, 1011859 free (51 frags, 126476 blocks, 0.0% fragmentation)
> /dev/vinum/alcavar: BAD SUPER BLOCK: MAGIC NUMBER WRONG
In Anbetracht der Zustände der Plexe ist das kaum verwunderlich.
> Wie ist nun den flaky / reborn-Stats beizukommen?
Hängt vom großen Bild ab, das ich nicht sehe.
http://www.vinumvm.org/vinum/how-to-debug.html,
Greg
-- When replying to this message, please copy the original recipients. If you don't, I may ignore the reply or reply to the original recipients. For more information, see http://www.lemis.com/questions.html See complete headers for address and phone numbers
To Unsubscribe: send mail to majordomo.FreeBSD.org
with "unsubscribe de-bsd-questions" in the body of the message
Received on Tue 19 Aug 2003 - 05:08:58 CEST