FreeBSD 5.2.1
Uptime до данного случая где-то пол-года.
Грузиться, работает порядка 3-4 минут, такое ощущение пока идет ufs_fsck и валиться в ребут вот с таким мессаджом.
art=0 len=2 to=/usr
panic: ffs_allocg: map corrupted cpuid=0
syncing disks, buffers remaining
panic: bremfree: removing a buffer on a queue
cpuid=0
>FreeBSD 5.2.1
>Uptime до данного случая где-то пол-года.
>Грузиться, работает порядка 3-4 минут, такое ощущение пока идет ufs_fsck и валиться
>в ребут вот с таким мессаджом.
>art=0 len=2 to=/usr
>panic: ffs_allocg: map corrupted cpuid=0
>syncing disks, buffers remaining
>panic: bremfree: removing a buffer on a queue
>cpuid=0если дисковых сбоев нет, то тут что-то хитрое, мб RAM накернился?
>>FreeBSD 5.2.1
>>Uptime до данного случая где-то пол-года.
>>Грузиться, работает порядка 3-4 минут, такое ощущение пока идет ufs_fsck и валиться
>>в ребут вот с таким мессаджом.
>>art=0 len=2 to=/usr
>>panic: ffs_allocg: map corrupted cpuid=0
>>syncing disks, buffers remaining
>>panic: bremfree: removing a buffer on a queue
>>cpuid=0
>
>если дисковых сбоев нет, то тут что-то хитрое, мб RAM накернился?а если загрузиться с Frenzy и запустить несколько dd на разные дисковые
FS на чтение: dd if=FS of=/dev/null ?Как-то надо ж ситуацию разруливать, отсекать проблемы...
Или диск на другой машине попробовать...
смотрим /sys/ufs/ffs/ffs_alloc.c и видим:It is a panic if a request is made to find a block if none are
available.
>смотрим /sys/ufs/ffs/ffs_alloc.c и видим:
>
>It is a panic if a request is made to find a
>block if none are
>available.угу, это более конкретный подход, далее можно задаться вопросом - пАчему,
неохота смотреть sources, поэтому предположу - при разбивке неверная
геометрия и выходит за физические границы, другое предположение -
проблемы с диском, но тогда должны быть логи и предшествующие
дисковым сбоям, возможны еще варианты.