Note, assuming our theory on the circumstances of the race is correct above (that it is 'read' or mount of that device), I was unable to reproduce with a loop device, which I thought would have caused a similar issue:
1. truncate --size 100m /tmp/my.img
2. mkfs -F -t ext3 /tmp/my.img
3. LODEV=$(sudo losetup --show --find /tmp/my.img)
4. sudo python -c 'import time, sys; print sys.argv[1]; fp=open(sys.argv[1]); time.sleep(30); fp.close();' /dev/loop1 &
# inside the 30 seconds that that will have an open RO file handle, do step 5
5. sudo fsck.ext3 -f /dev/loop1 # '-f' forces fsck even if not marked dirty
or
sudo fsck.ext3 /dev/loop1
Other things I've found:
* using 'open(sys.argv[1],"rw")' does not change anything, fsck will still continue.
* changing step 4 to 'mount -o ro /dev/loop1 /mnt' *will* cause fsck.ext3 to complain that the filesystem is mounted and print a similar error message.
So, I'm suspecting that it is indeed the OVF code's mount -o,ro that is causing this problem.
I'm not sure how to resolve it, other than limiting the mounts checked to FS of iso9660 only.
Note, assuming our theory on the circumstances of the race is correct above (that it is 'read' or mount of that device), I was unable to reproduce with a loop device, which I thought would have caused a similar issue:
1. truncate --size 100m /tmp/my.img sys.argv[ 1]); time.sleep(30); fp.close();' /dev/loop1 &
2. mkfs -F -t ext3 /tmp/my.img
3. LODEV=$(sudo losetup --show --find /tmp/my.img)
4. sudo python -c 'import time, sys; print sys.argv[1]; fp=open(
# inside the 30 seconds that that will have an open RO file handle, do step 5
5. sudo fsck.ext3 -f /dev/loop1 # '-f' forces fsck even if not marked dirty
or
sudo fsck.ext3 /dev/loop1
Other things I've found: argv[1] ,"rw")' does not change anything, fsck will still continue.
* using 'open(sys.
* changing step 4 to 'mount -o ro /dev/loop1 /mnt' *will* cause fsck.ext3 to complain that the filesystem is mounted and print a similar error message.
So, I'm suspecting that it is indeed the OVF code's mount -o,ro that is causing this problem.
I'm not sure how to resolve it, other than limiting the mounts checked to FS of iso9660 only.