The last two days my dmesg buffer has be filled with "invalidate: busy
buffer" messages. I tried rebooting (and forcing a fsck), but after about
12 hours they came back.
I'm running 2.4.17 on a dual P3, Intel 440BX chipset. Both filesystems
are raid mirrored, ext3, ordered-data mode. One mirrored pair is on a
Adaptec AHA-2940U2/W controller (actually, this is running in degraded
mode, damn defective IBM UltraStar failed on me). The other mirrored pair
is on two Intel PIIX4 IDE controllers.
Since one of the raid pairs is down to a single drive, I've been backing
it up to the other mirrored pair nightly using dump 0.4b22 and, more
recently, dump 0.4b26.
Any thoughts what's causing this? Am I at risk for data loss?
-Ryan Mack
Ryan Mack wrote:
>
> The last two days my dmesg buffer has be filled with "invalidate: busy
> buffer" messages. I tried rebooting (and forcing a fsck), but after about
> 12 hours they came back.
>
> I'm running 2.4.17 on a dual P3, Intel 440BX chipset. Both filesystems
> are raid mirrored, ext3, ordered-data mode. One mirrored pair is on a
> Adaptec AHA-2940U2/W controller (actually, this is running in degraded
> mode, damn defective IBM UltraStar failed on me). The other mirrored pair
> is on two Intel PIIX4 IDE controllers.
>
> Since one of the raid pairs is down to a single drive, I've been backing
> it up to the other mirrored pair nightly using dump 0.4b22 and, more
> recently, dump 0.4b26.
This is due to some userspace application calling
ioctl(BLKFLSBUF); The kernel calls invalidate_buffers()
against a live device so it can of course sometimes
encounter a locked buffer, and it spits this message.
> Any thoughts what's causing this? Am I at risk for data loss?
No, there's no risk. I think the invalidate_buffers()
call should only be made within the ioctl if the device's
usage count is one, but various kernel luminaries didn't
like the idea, for reasons which I failed to understand :)
-