Bug 76381

Summary: while writing LILO, ext3 complains
Product: [Retired] Red Hat Linux Reporter: Pavel Urban <fc-bugzilla>
Component: kernelAssignee: Stephen Tweedie <sct>
Status: CLOSED NOTABUG QA Contact: Brian Brock <bbrock>
Severity: low Docs Contact:
Priority: medium    
Version: 7.3   
Target Milestone: ---   
Target Release: ---   
Hardware: i686   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2002-10-21 07:59:13 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

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:
Always

Steps to Reproduce:
1.lilo -v
2.
3.
	

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.