[JF:20102] [Draft] Linux 2.6.34 gfs2-glocks.txt
Seiji Kaneko
skaneko ＠ a2.mbn.or.jp
2012年 7月 13日 (金) 23:37:01 JST
かねこです。題記のもののドラフトを出します。
これは投げるのは初めてかもしれない。
------>8------------>8------------>8------------>8------------>8
=========================================================
これは、
Linux-2.6.34/Documentation/filesystems/gfs2-glocks.txt の和訳です。
翻訳団体： JF プロジェクト < http://www.linux.or.jp/JF/ >
更新日 ： 2012/07/06
翻訳者 ： Seiji Kaneko < skaneko at a2 dot mbn dot or dot jp >
=========================================================
# Glock internal locking rules
# ------------------------------
Glock 内部ロックルール
----------------------
#This documents the basic principles of the glock state machine
#internals. Each glock (struct gfs2_glock in fs/gfs2/incore.h)
#has two main (internal) locks:
この文書は、glock ステートマシンの内部処理の基本的方針を記載したものです。
各 glock (fs/gfs2/incore.h の gfs2_glock 構造体) は二つのメイン (内部) ロ
ックを持っています。
# 1. A spinlock (gl_spin) which protects the internal state such
# as gl_state, gl_target and the list of holders (gl_holders)
# 2. A non-blocking bit lock, GLF_LOCK, which is used to prevent other
# threads from making calls to the DLM, etc. at the same time. If a
# thread takes this lock, it must then call run_queue (usually via the
# workqueue) when it releases it in order to ensure any pending tasks
# are completed.
1. gl_spin スピンロック。このロックは gl_state、gl_target、ロック保持者の
リスト gl_holders などの保護に用いられます。
2. GLF_LOCK ノンブロッキングビットロック。このロックは、DLM などの呼び出し
が他のスレッドから同時に起きないように排他を行うために用います。スレッド
がこのロックを取得する場合、ロック開放時には引き続き run_queue を (通常は
workqueue 経由で) 呼び出して、仕掛かり中のタスクの完了を確認しなければな
りません。
#The gl_holders list contains all the queued lock requests (not
#just the holders) associated with the glock. If there are any
#held locks, then they will be contiguous entries at the head
#of the list. Locks are granted in strictly the order that they
#are queued, except for those marked LM_FLAG_PRIORITY which are
#used only during recovery, and even then only for journal locks.
gl_holder リストには、単にロックの保持者だけではなく、glock に関連した、キ
ューに積まれた全てのロックリクエストが格納されます。保持されているロックが
ある場合、リストの先頭から順に連続エントリとして格納されます。ロックは例外
をのぞき、厳格にキューに積まれた順に与えられます。その例外とは、リカバリ時
にのみ用いる LM_FLAGS_PRIORITY フラグのついたリクエストで、さらに対象とす
るのはジャーナルロックのみです。
#There are three lock states that users of the glock layer can request,
#namely shared (SH), deferred (DF) and exclusive (EX). Those translate
#to the following DLM lock modes:
glock レイヤの利用者が要求可能なロック状態は三つあります。共有 (SH:Shared)、
遅延ロック (DF:Deferred)、排他 (EX:Exclusive) です。
これらは DLM ロック状態に以下のように反映されます。
#Glock mode | DLM lock mode
#------------------------------
# UN | IV/NL Unlocked (no DLM lock associated with glock) or NL
# SH | PR (Protected read)
# DF | CW (Concurrent write)
# EX | EX (Exclusive)
Glock モード | DLM ロックモード
------------------------------
UN | IV/NL ロックなし (glock に関連した DLM ロックなし) または NL
SH | PR (保護された読み出し)
DF | CW (並行ライト)
EX | EX (排他)
#Thus DF is basically a shared mode which is incompatible with the "normal"
#shared lock mode, SH. In GFS2 the DF mode is used exclusively for direct I/O
#operations. The glocks are basically a lock plus some routines which deal
#with cache management. The following rules apply for the cache:
このように、基本的には DF は「通常の」共有ロックである SH とは非互換の共有
モードという位置づけです。GFS2 では、DF モードは直接 I/O (Direct I/O) での
み用いられています。この glock は基本的には、ロックにキャッシュ管理を行う
処理を加えたものです。キャッシュには以下の規則が適用されます。
#Glock mode | Cache data | Cache Metadata | Dirty Data | Dirty Metadata
#--------------------------------------------------------------------------
# UN | No | No | No | No
# SH | Yes | Yes | No | No
# DF | No | Yes | No | No
# EX | Yes | Yes | Yes | Yes
Glock モード | Cacheデータ | Cacheメタデータ| ダーティデータ | ダーティメタデータ
#---------------------------------------------------------------------------------
# UN | いいえ | いいえ | いいえ | いいえ
# SH | はい | はい | いいえ | いいえ
# DF | いいえ | はい | いいえ | いいえ
# EX | はい | はい | はい | はい
#These rules are implemented using the various glock operations which
#are defined for each type of glock. Not all types of glocks use
#all the modes. Only inode glocks use the DF mode for example.
これらの規則は、各 glock 種毎に定義されている様々な glock 操作を用いて実装
されています。様々なタイプの glock には、これらの全モードを持っていないも
のもあります。例えば inode glock のみが DF モードを用います。
#Table of glock operations and per type constants:
glock 操作と、タイプ毎の定数の一覧を示します。
#Field | Purpose
#----------------------------------------------------------------------------
#go_xmote_th | Called before remote state change (e.g. to sync dirty data)
#go_xmote_bh | Called after remote state change (e.g. to refill cache)
#go_inval | Called if remote state change requires invalidating the cache
#go_demote_ok | Returns boolean value of whether its ok to demote a glock
# | (e.g. checks timeout, and that there is no cached data)
#go_lock | Called for the first local holder of a lock
#go_unlock | Called on the final local unlock of a lock
#go_dump | Called to print content of object for debugfs file, or on
# | error to dump glock to the log.
#go_type | The type of the glock, LM_TYPE_.....
#go_min_hold_time | The minimum hold time
フィールド | 目的
----------------------------------------------------------------------------
go_xmote_th | リモートの状態変更の前に呼ばれます (例: ダーティデータの sync など)
go_xmote_bh | リモートの状態変更の後に呼ばれます (例: キャッシュの再読み込みなど)
go_inval | リモートの状態変化により、キャッシュを無効化する必要がある場合に呼
ばれます
go_demote_ok | glock の開放が可能であるかどうかを論理値で返します
| (例: タイムアウトをチェックし、キャッシュデータがないことを確認)
go_lock | ローカルでのロックの最初の (そのマシンで他に誰もロックを持っていない)
| 取得時に呼ばれます
go_unlock | ローカルでのロックの最後の開放時に呼ばれます
go_dump | debugfs ファイル向けのオブジェクトの内容の表示や、エラ
| ー時にログに glock 値をダンプする際に呼ばれます。
go_type | glock の種別。LM_TYPE_.....
go_min_hold_time | 最小のホールド時間
#The minimum hold time for each lock is the time after a remote lock
#grant for which we ignore remote demote requests. This is in order to
#prevent a situation where locks are being bounced around the cluster
#from node to node with none of the nodes making any progress. This
#tends to show up most with shared mmaped files which are being written
#to by multiple nodes. By delaying the demotion in response to a
#remote callback, that gives the userspace program time to make
#some progress before the pages are unmapped.
各ロックの最小ホールド時間とは、リモートのロックの取得許可後、リモートから
の開放要求を無視する時間です。これは、ロックがクラスタ内でノード間でのピン
ポンを繰り返し、操作が進まなくなる状況を避けるためのものです。このような競
合状況は、複数のノードから書き込まれる共有 mmap ファイルで起こりがちです。
リモートからのコールバックによるロックの解放応答を遅らせることで、ユーザ空
間のプログラムにページがアンマップされる前に操作を少しでも進ませる余裕を与
えます。
#There is a plan to try and remove the go_lock and go_unlock callbacks
#if possible, in order to try and speed up the fast path though the locking.
#Also, eventually we hope to make the glock "EX" mode locally shared
#such that any local locking will be done with the i_mutex as required
#rather than via the glock.
go_lock と go_unlock コールバックを、可能な限り削減しようという計画がありま
す。これはロック関連で高速パスの速度を改善することが目的です。また、将来は
glock "EX" モードをローカルで共有して、ローカルでのロックを glock 経由では
なく i_mutex で行おうという希望的計画もあります。
#Locking rules for glock operations:
glock 操作のロック保持ルール
#Operation | GLF_LOCK bit lock held | gl_spin spinlock held
#-----------------------------------------------------------------
#go_xmote_th | Yes | No
#go_xmote_bh | Yes | No
#go_inval | Yes | No
#go_demote_ok | Sometimes | Yes
#go_lock | Yes | No
#go_unlock | Yes | No
#go_dump | Sometimes | Yes
操作 | GLF_LOCK ビットの保持 | gl_spin スピンロック保持
-----------------------------------------------------------------
go_xmote_th | 必要 | いいえ
go_xmote_bh | 必要 | いいえ
go_inval | 必要 | いいえ
go_demote_ok | 場合による | 必要
go_lock | 必要 | いいえ
go_unlock | 必要 | いいえ
go_dump | 場合による | 必要
#N.B. Operations must not drop either the bit lock or the spinlock
#if its held on entry. go_dump and do_demote_ok must never block.
#Note that go_dump will only be called if the glock's state
#indicates that it is caching uptodate data.
注記:操作時には、開始時点で持っていたビットロックやスピンロックを途中で解
放してはいけません。go_dump や do_demote_ok はブロックしてはいけません。
go_dump は、glock の状態から最新のデータをキャッシュしていると分かっている
場合にのみ呼ばれることに注意してください。
#Glock locking order within GFS2:
GFS2 内の glock ロック順序を以下に示します。
# 1. i_mutex (if required)
# 2. Rename glock (for rename only)
# 3. Inode glock(s)
# (Parents before children, inodes at "same level" with same parent in
# lock number order)
# 4. Rgrp glock(s) (for (de)allocation operations)
# 5. Transaction glock (via gfs2_trans_begin) for non-read operations
# 6. Page lock (always last, very important!)
1. i_mutex (必要な場合)
2. rename glock (リネームの場合のみ)
3. Inode glock
(親を子よりも先にロック、次に同じ親で同じ階層にある inode というロック順で)
4. Rgrp glock (割り当てと開放処理で)
5. 読み出しを行わない操作について、Transaction glock (gfs2_trans_begin 経由で)
6. ページロック (常に最後で。ここ重要!)
#There are two glocks per inode. One deals with access to the inode
#itself (locking order as above), and the other, known as the iopen
#glock is used in conjunction with the i_nlink field in the inode to
#determine the lifetime of the inode in question. Locking of inodes
#is on a per-inode basis. Locking of rgrps is on a per rgrp basis.
inode 毎に二つの glock があります。一方は inode 自体へのアクセスを扱い (ロ
ック順は上記のとおり)、他方 (iopen glock) は、inode の i_nlink フィールド
と組み合わせて、対象となる inode の寿命を判断するのに使います。inode のロ
ックは、inode 毎に行います。rgrp へのロックも rgrp 毎に行います。
------>8------------>8------------>8------------>8------------>8
--
Seiji Kaneko
JF メーリングリストの案内