Bug 76381 - while writing LILO, ext3 complains
Summary: while writing LILO, ext3 complains
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: kernel (Show other bugs)
(Show other bugs)
Version: 7.3
Hardware: i686 Linux
Target Milestone: ---
Assignee: Stephen Tweedie
QA Contact: Brian Brock
Depends On:
TreeView+ depends on / blocked
Reported: 2002-10-21 06:15 UTC by Pavel Urban
Modified: 2007-04-18 16:47 UTC (History)
0 users

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2002-10-21 07:59:13 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

Description Pavel Urban 2002-10-21 06:15:57 UTC
From Bugzilla Helper:
User-Agent: Mozilla/4.0 (compatible; MSIE 5.5; Windows NT 5.0)

Description of problem:
When I try to write LILO into Linux partition, kernel says 'Unexpected dirty 
buffer encountered at do_get_write_access:597 
(03:06 blocknr 0)'. However, everything works after this. My platform is Dell 
Latitude, 20GB disk (Linux partition is somewhere around 12GB), stock RH kernel.

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
1.lilo -v

Actual Results:  Error (warning?) message, but everything works fine after this.

Expected Results:  No message.

Additional info:

I've found this message in ext3 journalling daemon sources. I think that ext3 
and LILO have some misunderstanding in this area...

Comment 1 Stephen Tweedie 2002-10-21 08:41:31 UTC
That warning occurs when some external program modifies a block that is under
ext3 control.  In this case it's probably because you're running LILO with the
boot sector one one of your partitions, rather than on the MBR of the disk.

There's just no way around it --- if you do this, LILO ends up modifying one of
the filesystem blocks which contains critical fs metadata (the superblock in
this case).  Of course, a journaling filesystem's correctness depends utterly on
it getting the write order on disk exactly correct, and finding buffers
unexpectedly dirty can indicate that that has gone wrong, which would be a
potentially-data-corrupting error.

So ext3 has the choice of warning about this or ignoring it.  Given the
potentially severe result of any ext3 bug which gets the write order wrong, it's
better to leave the warning present, but the side-effect is that this particular
LILO operation will result in a warning if you use it on an active, live filesystem.

Note You need to log in before you can comment on or make changes to this bug.