On 11/21/2012 05:22 PM, David Teigland wrote:
On Wed, Nov 21, 2012 at 05:15:55PM +0100, sysadmin@albasoft.com wrote:
On this specific host it was running directly on ext4. I'll change it to nfs and report.
Aren't you using multiple hosts to run shared vm images? If not, then using sanlock is pointless.
Yes, I am using multiple hosts and sharings vm. But this was the nfs server host, so I thought there was no point in nfs mounting a local path.
That path is on ext4 filesystem on top of LVM2 logical volume on top of a md raid1 device. Does that say something to you?
ext4 or md are probably the cause of the problems; sanlock will not work properly with either.
I'm running another set of 3 hosts with exactly the same arrangement (ext4, lvm, md raid) for months, and I get no error. The only log from sanlock I get is
Nov 17 18:01:50 storage02 kernel: EXT4-fs (dm-1): Unaligned AIO/DIO on inode 1569995 by sanlock; performance will be poor.
but no "check_our_lease corrupt"
On Wed, Nov 21, 2012 at 05:36:12PM +0100, sysadmin@albasoft.com wrote:
Yes, I am using multiple hosts and sharings vm. But this was the nfs server host, so I thought there was no point in nfs mounting a local path.
I wouldn't rely on sanlock working properly when accessed both locally and remotely.
I'm running another set of 3 hosts with exactly the same arrangement (ext4, lvm, md raid) for months, and I get no error.
The problem isn't errors per se, it's the unpredictable nature of concurrent, atomic reads and writes to lease sectors. This is also why I'd not put mirroring or other software raid under the lease storage.
Nov 17 18:01:50 storage02 kernel: EXT4-fs (dm-1): Unaligned AIO/DIO on inode 1569995 by sanlock; performance will be poor.
You can ignore this, we're doing it intentionally, we don't care about performance.
but no "check_our_lease corrupt"
I don't know why this happened, but I'd wager it's related to mixing local and remote i/o to the leases.
sanlock-devel@lists.fedorahosted.org