On 12/10/21 6:09 PM, Chanchal Mathew wrote:
Thank you for the explanation!
Wouldn’t we expect zero pending modification or no unwritten data when a device is cleanly unmounted? Or do you mean, a successful ‘umount’ run on the device doesn’t guarantee there are no pending changes?
The devices I’m testing on are image files with same amount of data. One with lower log number is quicker to mount.
$ sudo xfs_logprint -t /dev/mapper/loop0p1
…
log tail: 451 head: 451 state: <CLEAN>
Whereas, the one with higher log number, such as the one below, is about 4-5 times slower running xlog_find_tail().
$ sudo xfs_logprint -t /dev/mapper/loop0p1
…
log tail: 17658 head: 17658 state: <CLEAN>
What is the geometry of these filesystems (xfs_info) and how much delay are we talking
about here, in wall clock time?
-Eric
The images are of same size, and have same amount of data as well (as verified by df and df -i once mounted)
The only way I can work around this delay for an instance started from an image file with higher log number is, to reset it to 0 with xfs_repair.
Chanchal
