On Sat, Jul 07, 2018 at 10:59:46AM -0400, Theodore Y. Ts'o wrote: > On Fri, Jul 06, 2018 at 10:26:21PM -0700, Elliott Mitchell wrote: > > Package: e2fsprogs > > Version: 1.43.4-2 > > > > Based on behavior of `tune2fs` and `mount` it seems the MMP protection > > somehow detects what amounts to its "home" host is. Problem is there is > > no function to change whatever the actual parameter is, nor any mention > > of where it comes from. > > > > I've noticed a difference between two ext4 filesystems which have MMP > > protection turned on. On one doing `mount <mountpoint> -o remount,rw` is > > fast and the other it is slow. From this behavior I'm pretty sure the > > MMP feature records some parameter and uses that to mark what its > > "home" host is. Mounting read-write anywhere but the "home" host is > > slow. > > That's not how MMP works. If you cleanly unmount the file system from > hostA, and then mount (or remount read-write) on hostB there will be > no delay.
This then suggests this bug should be against linux-source-4.9 instead of e2fsprogs. A few command sequences and notes on how fast the command executes on the machine: mount / -o rw,remount => slow mount / -o ro,remount => fast mount / -o rw,remount => slow mount / -o ro,remount => fast By your explanation, the first ro,remount should set the sequence to 0 (or appropriate equivalent value). After which the second ro,remount *should* be fast, yet is not. The message "EXT4-fs warning (device rootdev): ext4_multi_mount_protect:324 MMP interval 42 higher than expected, please wait." appears in triplicate in `dmesg` for each of the rw,remount commands. Slightly differing sequence: tune2fs -f -E clear_mmp /dev/rootdev mount / -o rw,remount => fast mount / -o ro,remount => fast mount / -o rw,remount => slow mount / -o ro,remount => fast > So if the previous owner is dead, the remount read-write will be slow. > That's by defintion. It's how it works. The mmp_node_name and > mmp_device_name displayed by dumpe2fs: > > MMP_block: > mmp_magic: 0x4d4d50 > mmp_check_interval: 5 > mmp_sequence: 0xff4d4d50 > mmp_update_date: Sat Jul 7 10:50:26 2018 > mmp_update_time: 1530975026 > mmp_node_name: cwcc > ummp_device_name: loop0 > > is purely for debugging purposes. All of the MMP mechanism is done > via the mmp_sequence number. `dumpe2fs` 1.43.4-2 fails to produce that output. "MMP block number" and "MMP update interval" appear in the output, but none of the other values do. I'm very suspicious e2fsprogs still has some sort of issue lurking. Why does `tune2fs -f -E clear_mmp` clear the issue for 1 and only 1 rw mount? This being at least partially a kernel bug wouldn't surprise me at all. I'm not yet convinced there isn't an issue with e2fsprogs lurking though. -- (\___(\___(\______ --=> 8-) EHM <=-- ______/)___/)___/) \BS ( | [email protected] PGP 87145445 | ) / \_CS\ | _____ -O #include <stddisclaimer.h> O- _____ | / _/ 8A19\___\_|_/58D2 7E3D DDF4 7BA6 <-PGP-> 41D1 B375 37D0 8714\_|_/___/5445
