[Cluster-devel] How do the nodes that are mounting GFS2 see the latest version of file system?

[Bob Peterson]

Hi Daegyu,

----- Original Message -----
> How can B's file system data structure be kept up to date?

GFS2 uses cluster-wide locking called "glocks" to synchronize metadata.

For example, when A wants to update a file F1 in a gfs2 file system,
it first acquires the glock for F1's inode. The glock gets
permission to use F1 using locks in DLM, the Distributed Lock Manager.

If node B has the glock for F1 already locked, it requests the glock be
released. The request to release the glock causes node B to write
everything it has in memory related to F1 before the glock is released.
Then B's in-core inode for F1 is invalidated and needs to be re-read
the next time it needs to see it.

After B releases the glock, then A is granted the lock by DLM.
When it acquires the glock, it must re-read the metadata needed for F1
(either because it was never read in, or because it was invalidated from
the last time it released the glock).

In this way, the metadata is kept synchronized as the glocks are passed
around the cluster.

> Is B rereading the superblock every time like the mount process? How do B

In GFS2, the file system superblock only tells the file system where
to start looking for things and it is only read when the file system
is mounted. It is never updated, except by gfs2-utils when it is offline,
like gfs2_edit, fsck.gfs2, mkfs.gfs2, etc.

Each node has its own unique memory with regard to the file system's
metadata. And that metadata is kept in sync by using the glocks as
described above.

> machine know that the disk's file system has been updated?
> I would like to know a detailed explanation.

It's all coordinated through glocks, which correspond to DLM locks.

Regards,

Bob Peterson
Red Hat File Systems