Hi Steven, Il 29-08-2017 11:45 Steven Whitehouse ha scritto:
Yes, there is some additional overhead due to the clustering. You can however usually organise things so that the overheads are minimised as you mentioned above by being careful about the workload. No. You want to use the default data=ordered for the most part. It is less a question of data loss and more a question of whether in case of a power outage it is possible for a file being written to, to land up with incorrect content. That can happen in the data=writeback case (where block allocation has succeeded, but the new data has not yet been written to disk) but not in the data=ordered case.
I think there is a misunderstanding: I am not speaking about filesystem mount options (data=ordered vs data=writeback), rather on the QEMU virtual disk caching mode: on Red Hat documentation, it is suggested to set QEMU vdisk in cache=none mode. However, cache=writeback has some significant performance advantages in a number of situations. As, since at least 5 years, QEMU with cache=writeback supports barrier passing and so it is safe to use, I wondered why Red Hat officially suggest to avoid it on GFS2. I suspect it is related to the performance degradation due to cache coherence between the two hosts, but I would like to be certain in not related to inherently unsafe operation on GFS2.
Yes, it works well. The size limit was based on fsck time, rather than any reliability issues. It will work reliably at much larger sizes, but it will take longer and use more memory.
Great. Any advice on how much time is needed for full fsck on a 8+ TB volume?
I hope that answers a few more of your questions, Steve.
Absolutely great info. Thank you very much Steve. -- Danti Gionatan Supporto Tecnico Assyoma S.r.l. - www.assyoma.it email: g.danti@xxxxxxxxxx - info@xxxxxxxxxx GPG public key ID: FF5F32A8 -- Linux-cluster mailing list Linux-cluster@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/linux-cluster
