Hello. On a server running 2.4.25, I have the two following errors in the kernel logfile: Unexpected dirty buffer encountered at do_get_write_access:618 (08:11 blocknr 920707) Unexpected dirty buffer encountered at do_get_write_access:618 (08:11 blocknr 920707) Should I worry about them (disk failure, filesystem damage) ? Thanks. As an addition what does the pair '08:11' means ? Is this the major/minor of the hard disk partition where the filesystem is located ? -- Nicolas
Nicolas.Kowalski at imag.fr wrote:> Hello. > > On a server running 2.4.25, I have the two following errors in the > kernel logfile: > > Unexpected dirty buffer encountered at do_get_write_access:618 (08:11 blocknr 920707) > Unexpected dirty buffer encountered at do_get_write_access:618 (08:11 blocknr 920707) >It's probably a driver problem.> > Should I worry about them (disk failure, filesystem damage) ?It's possible, depending on which driver is having trouble. Did you run fsck?> > Thanks. > > > As an addition what does the pair '08:11' means ? Is this the > major/minor of the hard disk partition where the filesystem is located ?Yes, check /proc/partitions. Mike
Mike Fedyk <mfedyk at matchmail.com> writes:> Nicolas Kowalski wrote: >> Mike Fedyk <mfedyk at matchmail.com> writes: >> >>>Nicolas Kowalski wrote: >>> >>>>I will try to reproduce these errors on a non-production server now. >>> >>>Beautiful. >>> >>>It might be good if you put a stack_dump() call just after the >>>printk() call in the ext3 source. >> I apologize, (I am not familiar with kernel debugging), but when >> compiling the kernel with this call inserted after the printk in the >> sources, it fails with an resolved symbol error. ... >> fs/fs.o: In function `__jbd_unexpected_dirty_buffer': >> fs/fs.o(.text+0x3ab8a): undefined reference to `stack_dump' >> ... >> I must be missing an option, but which one ? > > Oh crap. It's called dump_stack().Ok. I had another similar error this morning: Unexpected dirty buffer encountered at do_get_write_access:618 (08:11 blocknr 920701) dba1fddc dba1fe04 c017565e c03054a0 c0305483 c030373b 0000026a c03fc5e0 000e0c7d d1072580 dba1fe4c c016f76b c030373b 0000026a d34f1d80 d1072580 df4c1e94 d34f1d80 c01701dd 00000000 00000000 00000003 df4c1e00 d3615430 Call Trace: [<c017565e>] [<c016f76b>] [<c01701dd>] [<c016fc10>] [<c0167c88>] [<c0167c4e>] [<c0167e21>] [<c0167c74>] [<c012f67a>] [<c012fb14>] [<c01657e2>] [<c013c807>] [<c0108be3>] ksymoops gives me: Trace; c017565e <__jbd_unexpected_dirty_buffer+3a/74> Trace; c016f76b <do_get_write_access+10f/570> Trace; c01701dd <journal_dirty_metadata+15d/188> Trace; c016fc10 <journal_get_write_access+44/68> Trace; c0167c88 <do_journal_get_write_access+14/58> Trace; c0167c4e <walk_page_buffers+52/78> Trace; c0167e21 <ext3_prepare_write+155/208> Trace; c0167c74 <do_journal_get_write_access+0/58> Trace; c012f67a <do_generic_file_write+226/408> Trace; c012fb14 <generic_file_write+f4/10c> Trace; c01657e2 <ext3_file_write+1e/9c> Trace; c013c807 <sys_write+93/108> Trace; c0108be3 <system_call+33/38> Does this help ? -- Nicolas