On Tue, Nov 28, 2017 at 07:04:54AM -0600, Ashlie Martinez wrote: > No biggie, part of the reason this was so hard for me to wrap my head > around is I don't have a physical machine that I can reproduce this on > (and I never got around to getting a GCE instance to test on). Not > being able to poke around a reproducing system makes it a little bit > harder for me to reason about :) This does reproduce easily using kvm-xfstests[1]; using gce-xfstests was not necessary. That's actually how I debugged it, since kvm starts up in under 5 seconds, while starting up a cloud VM takes a bit longer. So if you want a quick edit/compile/debug cycle, or if you attach a debugger to the running kernel, using kvm-xfstests is the right tool to use. 99% of the command syntax and test appliance implementation is the same between kvm-xfstests and gce-xfstests. [1] https://github.com/tytso/xfstests-bld/blob/master/Documentation/kvm-quickstart.md I've been trying to promote the use of kvm-xfstests for researchers who are interested in doing file system work. So if you can help promote {kvm,gce}-xfstests amongst your fellow students and professors, that would be great! You can run the reproducer automatically via "kvm-xfstests -c 4k generic/456". But you can also run "kvm-xfstests shell", and then run the following commands; kvm-xfstests# export FSTESTSET=generic/456 kvm-xfstests# ./runtests.sh You can then edit the test script to add debugging commands; it can be found in /root/xfstests/tests/generic/456 and then rerun the tests using the "./runtests.sh" script. Sorry, the only editor available is /bin/ed. If you want to use some other editor, and are willing to build your own test-appliance VM image instead of just downloading the rebuilt test applinace image, you can add it to the xfstests-packages file in the kvm-xfstests/test-appliance directory, and generate your own test appliance. See [2] for more details. [2] https://github.com/tytso/xfstests-bld/blob/master/Documentation/building-rootfs.md This is actually how I figured out what was happening; I added commands such as "debugfs -R 'stat <11>'" so I could see was going on with the file system before the _flakey_drop_and_remount statement, and then varied the number of operations in the fsx operations to replay list. Regards, - Ted
