On 09/08/2019 12:46, Daegyu Han wrote:
Thank you for the clarification.
I have one more question.
I've seen some web page by redhat and it says that gfs2 has a poor
filesystem performance (i.e. throughput) compared to xfs or ext4.
[image: image.png]
In a high performance hardware environment (nvme over fabric, infiniband
(56G)), I ran a FIO benchmark, expecting GFS2 to be comparable to local
filesystems (ext4, xfs).
Unexpectedly, however, GFS2 showed 25% lower IOPS or throughput than ext4,
as the web page results.
Does GFS2 perform worse than EXT4 or XFS even on high-performance network +
storage?
gfs2 has performance overheads that ext4 and xfs don't encounter due to
the extra work it has to do to keep the fs consistent across the
cluster, such as the extra cache invalidation we've discussed, journal
flushing and updates to structures relating to quotas and statfs. Even
in a single-node configuration, extra codepaths are still active (but
gfs2 isn't meant to be used as a single-node fs, so fio is not a good
demonstration of its strengths). It's also worth noting that gfs2 is not
extent-based so you may see performance differences relating to that. We
are continually working to minimise the overheads, of course.
The size of the performance difference is highly dependent on the
workload and access pattern. (Clustered) applications looking to get the
best performance out of gfs2 will have each node processing its own
working set - preferably in its own subdirectory - which will minimise
the overheads.
Cheers,
Andy
Thank you,
Daegyu
ᐧ
2019년 8월 9일 (금) 오후 8:26, Andrew Price <anpr...@redhat.com>님이 작성:
On 09/08/2019 12:01, Daegyu Han wrote:
Thank you for your reply.
If what I understand is correct,
In a gfs2 file system shared by clients A and B, if A creates /foo/a.txt,
does B re-read the filesystem metadata area on storage to keep the data
consistent?
Yes, that's correct, although 'clients' is inaccurate as there is no
'server'. Through the locking mechanism, B would know to re-read block
allocation states and the contents of the /foo directory, so a path
lookup on B would then find a.txt.
After all, what makes gfs2 different from local filesystems like ext4,
because of lock_dlm?
Exactly.
In general, if we mount an ext4 file system on two different clients and
update the file system on each client, we know that the file system state
is not reflected in each other.
Yes.
Cheers,
Andy
Thank you,
Daegyu
ᐧ
2019년 8월 9일 (금) 오후 7:50, Andrew Price <anpr...@redhat.com>님이 작성:
Hi Daegyu,
On 09/08/2019 09:10, 한대규 wrote:
Hi, I'm Daegyu from Sungkyunkwan University.
I'm curious how GFS2's filesystem metadata is shared between nodes.
The key thing to know about gfs2 is that it is a shared storage
filesystem where each node mounts the same storage device. It is
different from a distributed filesystem where each node has storage
devices that only it accesses.
In detail, I wonder how the metadata in the memory of the node mounting
GFS2
looks the consistent filesystem to other nodes.
gfs2 uses dlm for locking of filesystem metadata among the nodes. The
transfer of locks between nodes allows gfs2 to decide when its in-memory
caches are invalid and require re-reading from the storage.
In addition, what role does corosync play in gfs2?
gfs2 doesn't communicate with corosync directly but it operates on top
of a high-availability cluster. corosync provides synchronization and
coherency for the cluster. If a node stops responding, corosync will
notice and trigger actions (fencing) to make sure that node is put back
into a safe and consistent state. This is important in gfs2 to prevent
"misbehaving" nodes from corrupting the filesystem.
Hope this helps.
Cheers,
Andy
