Ext3 users - Jun 2003 - Regarding hashing, ext3, and kjournald

I've tried to find my answer to this question but I
have not (yet).  Any assistance or expert knowledge is
greatly appreciated!

PROBLEM: mounting an ext3 volume 'read only' results
in a different md5sum hash value for the volume than
when the same volume is *not* mounted

SCENARIO: 
- when I hash unmounted /dev/hda5 using 'md5sum
/dev/hda5' I get value XXX.

- when I hash mounted /dev/hda5 using 'md5sum
/dev/hda5' I get value 'YYY'.


MISC:
- no matter how I mount the volume read only I get the
same result - differing hash values!
<example1> mount /dev/hda5 -o ro /mnt/poop 
<example2> mount /dev/hda5 -o ro -t ext2 /mnt/poop

- From my testing I'm thinking 'kjournald' has
something to do with it?  

- I've used both live operating systems as well as
bootable CD distros, all with same result;
----- when the volume is *not* mounted I get one value
----- when the volume is mounted read only the value
is  *different*, no matter what options I pass to
mount

- Upon reboot if I hash again the original value is
returned, I.E., I hash again using md5sum the
unmounted volume and it's equal to the previous
unmounted hash value.


Can someone enlighten me to *why* this is happening?

Is it because the journal is being read?  

Why the different value when mounted READ ONLY?

And then further, why the original nonmounted value
upon reboot?


(Using many test platforms, all x86, RHL 8, RHL 9,
Linux BBC 2.1, etc.)


Can I 'remove' kjournald from my test platform?  Will
this thoroughly screw me for viewing ext3 volumes
mounted read only?


Thank anyone and everyone for any hints, knowledge,
pointers they can share!

lt

__________________________________
Do you Yahoo!?
Yahoo! Calendar - Free online calendar with sync to Outlook(TM).
http://calendar.yahoo.com

Hi,

On Thu, 2003-06-12 at 22:04, Linux Tard wrote:
> I've tried to find my answer to this question but I
> have not (yet).  Any assistance or expert knowledge is
> greatly appreciated!
> 
> PROBLEM: mounting an ext3 volume 'read only' results
> in a different md5sum hash value for the volume than
> when the same volume is *not* mounted
The patch below seems to fix this for me.  It simply skips journal
superblock updates when the superblock is already marked fully-recovered
and nothing more has been written to the journal since then.

That allows jbd to keep updating its internal transaction sequence state
to maintain monotonically increasing transaction numbers on disk,
without those updates leaking to disk on a readonly volume.

I've been testing this lightly with LVM snapshots (which warn you if you
try to write to the snapshot), and the patch does cure stray unexpected
writes on readonly mounts there.

Cheers,
 Stephen