Ext3 users - Nov 2003 - Ext3 filesystem modified while mounted read-only

I noticed that ext3 filesystems are modified if mounted read-only:

# mke2fs -j /dev/hdb1

[...]

# md5sum /dev/hdb1 > MD5SUM
# mount -t ext3 -o ro /dev/hdb1 /mnt/test1
# umount /mnt/test1
# md5sum -c MD5SUM 
md5sum: MD5 check failed for '/dev/hdb1'

On examination of a block-for-block copy of 'before' and 'after'
images
with od and diff, I believe that the changes are the transaction number
in the journal being increased. I have also noticed that the filesystem
is not modified if mounted read-only via a loopback device.

Can anyone explain why it is necessary to increment transaction numbers
in a read-only mount? Or why this does not happen when a loopback device
is used? 

Thanks
Graham
-- 
If you have any trouble sounding condescending, find a Unix user to show you 
how it's done.
        -- Scott Adams

I believe this was discussed a while backon the list.  I would
dig through the archives.

Steve

Graham Bleach wrote:
>I noticed that ext3 filesystems are modified if mounted read-only:
>
># mke2fs -j /dev/hdb1
>
>[...]
>
># md5sum /dev/hdb1 > MD5SUM
># mount -t ext3 -o ro /dev/hdb1 /mnt/test1
># umount /mnt/test1
># md5sum -c MD5SUM 
>md5sum: MD5 check failed for '/dev/hdb1'
>
>On examination of a block-for-block copy of 'before' and
'after' images
>with od and diff, I believe that the changes are the transaction number
>in the journal being increased. I have also noticed that the filesystem
>is not modified if mounted read-only via a loopback device.
>
>Can anyone explain why it is necessary to increment transaction numbers
>in a read-only mount? Or why this does not happen when a loopback device
>is used? 
>
>Thanks
>Graham
>  
>

Hi,

On Mon, 2003-11-03 at 16:48, Graham Bleach wrote:
> I noticed that ext3 filesystems are modified if mounted read-only:
> 
> # mke2fs -j /dev/hdb1
> 
> [...]
> 
> # md5sum /dev/hdb1 > MD5SUM
> # mount -t ext3 -o ro /dev/hdb1 /mnt/test1
> # umount /mnt/test1
> # md5sum -c MD5SUM 
> md5sum: MD5 check failed for '/dev/hdb1'
Yep, it's an unusual case deep in the journal logic that is causing
this.  I think there's a simple fix, but I'm nervous about it because it
adds a conditional to the journal updates, and the consequences of
failing to complete a necessary update the journal superblock are
catastrophic on recovery.

Proposed patch is attached: does this help for you?  I've been trying it
out on LVM snapshots here.

Cheers,
 Stephen