Modification of block device by R/O mount

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Dear list,

I'm a little bit puzzled by behavior of ext4 I've been seeing initially on aarch64 Linux 6.1 but can reproduce easily on my machine:

Linux reliant 6.5.0-28-generic #29-Ubuntu SMP PREEMPT_DYNAMIC Thu Mar 28 23:46:48 UTC 2024 x86_64 x86_64 x86_64 GNU/Linux

The behavior I'm seeing is that a R/O mount modifies a device mapper block device (or loopback device), which is unsettling. That change is not propagated back to the original source, but it is causing massive problems nevertheless. For example:

reliant [/tmp/ext4test]: dd if=/dev/null bs=1M seek=64 count=0 of=image.img
0+0 records in
0+0 records out
0 bytes copied, 2,2172e-05 s, 0,0 kB/s


reliant [/tmp/ext4test]: mkfs.ext4 image.img
mke2fs 1.47.0 (5-Feb-2023)
Discarding device blocks: done
Creating filesystem with 16384 4k blocks and 16384 inodes

Allocating group tables: done
Writing inode tables: done
Creating journal (1024 blocks): done
Writing superblocks and filesystem accounting information: done



reliant [/tmp/ext4test]: losetup --read-only --show -f image.img
/dev/loop28


reliant [/tmp/ext4test]: md5sum /dev/loop28 image.img
34d7cd8eb4abb1943aabe078b8fb3c74  /dev/loop28
34d7cd8eb4abb1943aabe078b8fb3c74  image.img


reliant [/tmp/ext4test]: mkdir mnt; mount -o ro /dev/loop28 mnt


reliant [/tmp/ext4test]: md5sum /dev/loop28 image.img
9145654c1e6a5855c1db239815a05198  /dev/loop28
34d7cd8eb4abb1943aabe078b8fb3c74  image.img


reliant [/tmp/ext4test]: cmp /dev/loop28 image.img
/dev/loop28 image.img differ: byte 61484, line 5


reliant [/tmp/ext4test]: umount mnt; losetup -d /dev/loop28


reliant [/tmp/ext4test]: md5sum image.img
34d7cd8eb4abb1943aabe078b8fb3c74  image.img


As you can see, the original image was never modified (MD5 34d7... remains the same) but /dev/loop28 changes once R/O mounted. This behavior is shocking to me and I've not observed this with other file systems (I tried btrfs) so this seems to be ext4-specific.

Is this expected behavior? Is there a way to mitigate it?

Thanks and best regards,
Johannes

--
"A PC without Windows is like a chocolate cake without mustard."





[Index of Archives]     [Reiser Filesystem Development]     [Ceph FS]     [Kernel Newbies]     [Security]     [Netfilter]     [Bugtraq]     [Linux FS]     [Yosemite National Park]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Samba]     [Device Mapper]     [Linux Media]

  Powered by Linux