> Do you have barriers on and does iscsi pass them through to the target, and does the target propagate them to the disk itself?
Regardless of the barriers, it doesn't explain this:
$ sudo mount -o barrier=1,inode64 /dev/mapper/vg_xfs2-lvxfs1 /xfs1
$ sudo umount /xfs1
$ sudo xfs_logprint /dev/mapper/vg_xfs2-lvxfs1
xfs_logprint:
xfs_logprint: /dev/mapper/vg_xfs2-lvxfs1 contains a mounted and
writable filesystem
data device: 0xfd01
log device: 0xfd01 daddr: 83882016 length: 81912
It also happens in kernel 3.4.3-1.fc17. There are no other machines
which access the iSCSI target.
Right after boot, I can mount and umount it all that I want, and it
will work normally, i.e., say "Mounting Filesystem / Ending clean
mount" in dmesg, xfs_logprint NOT saying "... contains a mounted and
writable filesystem".
As crazy as that sounds, I've just found out what triggers the
situation. The weird behavior only manifests itself after this:
$ sudo service mysqld start
>From then on, it behaves as described earlier. Not that mysqld has
anything to do with XFS. It's just the plain package from Fedora, with
everything in the default place on the root filesystem, which is ext4.
As I've just found out, the behavior even returns to normal when I
shut down mysqld. So for now, my workaround is shutting down mysqld
myself before rebooting.
I'll try and see if this is easily reproducible inside a clean F17
install inside a KVM guest.
_______________________________________________
xfs mailing list
xfs@xxxxxxxxxxx
http://oss.sgi.com/mailman/listinfo/xfs
