On Thu, Aug 14, 2003 at 09:10:26PM +0200, Sebastian Boeck wrote:
> Hallo,
>
> seit gestern beobachte ich gewisse Ungrereimtheiten, die ich mir
> nicht ganz erklären kann. Es fing an mit:
>
> kernel: da0 at ahc0 bus 0 target 1 lun 0
> kernel: da0: <IBM DNES-309170W SAH0> Fixed Direct Access SCSI-3 device
> kernel: da0: 80.000MB/s transfers (40.000MHz, offset 30, 16bit), Tagged
> Queueing Enabled
> kernel: da0: 8748MB (17916240 512 byte sectors: 255H 63S/T 1115C)
> kernel: Mounting root from ufs:/dev/da0s1a
> ...
> kernel: (da0:ahc0:0:1:0): READ(16). CDB: 88 0 ff dc e2 7 a5 87 82 3f 0 0
> 0 20 0 0
> kernel: (da0:ahc0:0:1:0): CAM Status: SCSI Status Error
> kernel: (da0:ahc0:0:1:0): SCSI Status: Check Condition
> kernel: (da0:ahc0:0:1:0): ILLEGAL REQUEST asc:20,0
> kernel: (da0:ahc0:0:1:0): Invalid command operation code: Command byte 0
> is invalid
> kernel: (da0:ahc0:0:1:0): Unretryable error
> kernel: (da0:ahc0:0:1:0): READ(16). CDB: 88 0 ff dd e2 1b a5 87 86 47 0
> 0 0 20 0 0
> kernel: (da0:ahc0:0:1:0): CAM Status: SCSI Status Error
> kernel: (da0:ahc0:0:1:0): SCSI Status: Check Condition
>
> Die Zeilen ab dem 2. READ(16) wiederholen sich dann unzählige male.
Ist klar - die Platte kann keinen read(16).
Demnächst sag gleich dabei, daß du eine 5.x benutzt.
read(16) wird verwended, wenn man Sektornummern >2^32 ansprechen will.
Da die Platte aber kleiner als 2TByte ist braucht die diesen Befehl
auch nicht.
Kurzum - das system versucht auf einen Block jenseits der Plattengröße
zuzugreifen.
> Nach einem Neustart mußte ich ein manuelles fsck durchführen:
>
> fsck: /dev/da0s1g: UNREF FILE I=188901 OWNER=pgsql MODE=100600
> fsck: /dev/da0s1g: SIZE=6 MTIME=Aug 13 07:42 2003 (CLEARED)
> fsck: /dev/da0s1g: Reclaimed: 0 directories, 3 files, 2 fragments
> fsck: /dev/da0s1g: 10114 files, 1522737 used, 647867 free (10243 frags,
> 79703 blocks, 0.5% fragmentation)
> fsck: /dev/da0s1e: Reclaimed: 0 directories, 30 files, 131 fragments
> fsck: /dev/da0s1e: 133 files, 27146 used, 99562 free (58 frags, 12438
> blocks, 0.0% fragmentation)
> fsck: /dev/da0s1f: UNKNOWN FILE TYPE I=2752
> fsck: /dev/da0s1f: UNEXPECTED SOFT UPDATE INCONSISTENCY; RUN fsck
> MANUALLY.kernel: handle_workitem_freeblocks: block count
>
> Danach "lief" wieder alles normal, zumindes soweit ich es beurteilen konnte.
>
> Gerade eben tauchte dann folgendes auf:
>
> kernel: handle_workitem_freeblocks: block count
> kernel: handle_workitem_freeblocks: block count
> kernel: free inode /home/48972 had -765908 blocks
> kernel: free inode /home/48973 had -745316 blocks
> kernel: handle_workitem_freeblocks: block count
> last message repeated 3 times
> kernel: free inode /home/48961 had -745316 blocks
> kernel: free inode /home/48962 had -749536 blocks
> kernel: handle_workitem_freeblocks: block count
> last message repeated 2 times
> kernel: free inode /home/48960 had -765908 blocks
> kernel: free inode /home/48964 had -765908 blocks
> kernel: free inode /home/48965 had -745316 blocks
> kernel: free inode /home/48968 had -765908 blocks
> kernel: free inode /home/48969 had -745316 blocks
Ich würde sagen du hast ein Hardwareproblem mit RAM, CPU, Netzteil
oder sonstigem, was so Daten verfälschen kann.
Bei 5.x ist es aber auch durchaus denkbar, daß du auch einen schlechten
Versionsstand erwischt hast.
> Seit dem gibt df nur noch unrealistische Werte aus:
>
> Filesystem 1K-blocks Used Avail Capacity Mounted on
> /dev/da0s1a 253678 83182 150202 36% /
> devfs 1 1 0 100% /dev
> /dev/da0s1g 4341212 -88540 4082456 -2% /home
> /dev/da0s1e 253678 54294 179090 23% /tmp
> /dev/da0s1f 2971278 2257758 475818 83% /usr
> /dev/da0s1d 253678 37722 195662 16% /var
> fdescfs 1 1 0 100% /dev/fd
Yepp - das Filesystem ist deutlich erkennbar inkostent.
> Kann mir einer erklären, was das zu bedeuten hat?
> Geht meine Hardware gerade kaputt? Die Festplatte
> sollte es eigentlich nicht sein, oder?
Ich bin mir recht sicher, daß die Platte unschuldig ist.
-- B.Walter BWCT http://www.bwct.de ticso(at)bwct.de info(at)bwct.de To Unsubscribe: send mail to majordomo.FreeBSD.org with "unsubscribe de-bsd-questions" in the body of the messageReceived on Thu 14 Aug 2003 - 22:20:36 CEST