Re: RO mount of ext4 filesystem causes writes

[Sean Greenslade <sean@seangreenslade.com>]

On Fri, Jun 23, 2023 at 12:46:11AM -0400, Theodore Ts'o wrote:
> On Fri, Jun 23, 2023 at 08:06:02AM +0700, Bagas Sanjaya wrote:
> > 
> > No reply so far from the culprit author (Ye Bin) nor from Ted. Can
> > you help in this case?
> 
> There's been no reply because I haven't been able to replicate it, and
> I didn't have the time do enough work to convince myself the report
> was bogus.  At this point, I have spent time trying to reproduce it,
> and I've had no luck.
> 
> So, unless you can give me a simple set of reproduction instructions,
> I'm going to have to treat this report is invalid.
> 
> Regards,
> 
> 						- Ted
> 
> Note: this test was done using kvm-xfstests which can be found
> https://github.com/tytso/xfstests-bld using the install-kconfig and
> the kbuild script that can also be found in this report.  So if you
> want to play along from home, feel free.  :-)
> 
> 
> root@kvm-xfstests:~# mkfs.ext4 /dev/vdc
> mke2fs 1.47.0 (5-Feb-2023)
> Discarding device blocks: done                            
> Creating filesystem with 1310720 4k blocks and 327680 inodes
> Filesystem UUID: fe434060-6731-4b40-a94a-3a8517df0660
> Superblock backups stored on blocks: 
>         32768, 98304, 163840, 229376, 294912, 819200, 884736
> 
> Allocating group tables: done                            
> Writing inode tables: done                            
> Creating journal (16384 blocks): done
> Writing superblocks and filesystem accounting information: done 
> 
> root@kvm-xfstests:~# md5sum /dev/vdc
> fd38f9f8476ad63a744d179846ee7e18  /dev/vdc
> root@kvm-xfstests:~# mount -o ro /dev/vdc /mnt
> [  472.893614] EXT4-fs (vdc): orphan cleanup on readonly fs
> [  472.894022] EXT4-fs (vdc): mounted filesystem fe434060-6731-4b40-a94a-3a8517df0660 ro with ordered data mode. Quota mode: none.
> root@kvm-xfstests:~# umount /mnt
> [  475.698053] EXT4-fs (vdc): unmounting filesystem fe434060-6731-4b40-a94a-3a8517df0660.
> root@kvm-xfstests:~# md5sum /dev/vdc
> fd38f9f8476ad63a744d179846ee7e18  /dev/vdc
> 
> Hmm.... OK, let's try it with LUKS, even though that *really*
> shouldn't make a difference.  The cryptsetup lukeFormat and mkfs.ext4
> steps are skipped here.  Also, note that I had to manually edit the
> .config file to enable CONFIG_DM_CRYPT, since I dm_crypt is used by
> xfstests, so my install-kconfig script doesn't enable CONFIG_DM_CRYPT.
> 
> 
> root@kvm-xfstests:~# uname -a
> Linux kvm-xfstests 6.4.0-rc6-xfstests-lockdep #200 SMP PREEMPT_DYNAMIC Fri Jun 23 00:33:39 EDT 2023 x86_64 GNU/Linux
> 
> root@kvm-xfstests:~# md5sum /dev/vdc
> 28b75cc094e1e2a62ac25a730fc1dfee  /dev/vdc
> root@kvm-xfstests:~# cryptsetup luksOpen /dev/vdc test
> Enter passphrase for /dev/vdc: 
> root@kvm-xfstests:~# mount -o ro /dev/mapper/test /mnt
> [  812.073771] EXT4-fs (dm-0): orphan cleanup on readonly fs
> [  812.074306] EXT4-fs (dm-0): mounted filesystem ac3f76f1-da0a-426e-85b2-08526afb2224 ro with ordered data mode. Quota mode: none.
> root@kvm-xfstests:~# umount /mnt
> [  814.383016] EXT4-fs (dm-0): unmounting filesystem ac3f76f1-da0a-426e-85b2-08526afb2224.
> root@kvm-xfstests:~# cryptsetup luksClose /dev/mapper/test
> [  830.001992] dm-0: detected capacity change from 10452992 to 0
> root@kvm-xfstests:~# md5sum /dev/vdc
> 28b75cc094e1e2a62ac25a730fc1dfee  /dev/vdc

Hi, Ted. Thanks for taking the time to look into this.

I perhaps should have been more explicit in my report. The issue is not
that the image is any different after the mount; indeed, the md5sums are
identical before and after on my machine as well. The issue is that
something is issuing writes to the backing image, which bumps the mtime
of the backing image. When handling the images with rsync, a difference
in mtime causes the whole image to need to be read.

See this flow:

$ stat image.block | grep Modify
Modify: 2023-06-22 23:00:15.211379972 -0700

# cryptsetup luksOpen image.block t2 && mount -o ro /dev/mapper/t2 /mnt/t2
# umount /mnt/t2 && cryptsetup luksClose t2

$ stat image.block | grep Modify
Modify: 2023-06-22 23:03:56.141139649 -0700


The regression is the mtime bumping behavior, which doesn't happen prior
to the eee00237 commit.

Thanks,

--Sean