Re: the un-vacuumable table

On Mon, Jul 7, 2008 at 12:33 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> "Andrew Hammond" <andrew(dot)george(dot)hammond(at)gmail(dot)com> writes:
>>> On Thu, Jul 3, 2008 at 3:47 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>>>> Have you looked into the machine's kernel log to see if there is any
>>>> evidence of low-level distress (hardware or filesystem level)?
>
>> Jun 19 03:06:14 db1 kernel: mpt1: attempting to abort req
>> 0xffffffff929b9f88:6812 function 0
>> Jun 19 03:06:14 db1 kernel: (da1:mpt1:0:0:0): WRITE(16). CDB: 8a 0 0 0
>> 0 1 6c 99 9 c0 0 0 0 20 0 0
>> Jun 19 03:06:14 db1 kernel: (da1:mpt1:0:0:0): CAM Status: SCSI Status Error
>> Jun 19 03:06:14 db1 kernel: (da1:mpt1:0:0:0): SCSI Status: Check Condition
>> Jun 19 03:06:14 db1 kernel: (da1:mpt1:0:0:0): UNIT ATTENTION asc:29,0
>> Jun 19 03:06:14 db1 kernel: (da1:mpt1:0:0:0): Power on, reset, or bus
>> device reset occurred
>> [etc]
>
>> I think this is a smoking gun.
>
> Yeah, sure looks like one. Time to replace that disk drive?

Well, that's an Apple XRaid device on the other side of an LSI
FiberChannel HBA. I'll see if it has any error messages in it's logs.

> Also, I suggest filing a bug with your kernel distributor --- ENOSPC was
> a totally misleading error code here. Seems like EIO would be more
> appropriate. They'll probably want to see the kernel log.

It's FreeBSD 6.2 (yes, I know it's EoL). I'll submit a bug including this email.