From: Philipp Reisner <philipp.reisner@linbit.com>
To: drbd-dev@lists.linbit.com
Subject: [Drbd-dev] How Locking in GFS works...
Date: Mon, 4 Oct 2004 14:56:21 +0200 [thread overview]
Message-ID: <200410041456.21841.philipp.reisner@linbit.com> (raw)
Finally I found a Text describing usefully how the on disk
layout of GFS (actually openGFS) looks like and how the locking
works.
[I was not able to find anything about Sistina's ahm. RedHat's
GFS. ]
Find everything at http://opengfs.sourceforge.net/docs.php
The interesting part from the document on Locking:
2. Lock name
lm_lockname_t gl_name -- Unique "name" (but not a string!) for lock
The lockname structure has two components:
uint64 ln_number -- lock number
unsigned int ln_type -- type of protected entity
For most locks, the lock number is the block number (within the filesystem's
64-bit linear block space, which can span many storage devices) of the
protected entity, left shifted to be equivalent to a 512-byte sector.
Details are in src/fs/glock.c, ogfs_blk2lockname().
As an example, if we wanted to protect an inode at block 0x100, and we
are using 4-kByte blocks, the lock number would be 0x0800 (0x100 << 3).
I believe the block-to-sector conversion is for support of hardware-based
DMEP protocols, which address the DMEP storage space in terms of 512-byte
sectors. This could turn out to be problematic in *very large* 64-bit
filesystems, if they want to use the upper 3 bits of the 64-bit block
number.
There is a special lock for the disk-based superblock, defined in
src/fs/ogfs_ondisk.h. Note that this lock is not based on the block
number (the superblock is *not* stored in block 0):
OGFS_SB_LOCK (0) -- protects superblock read accesses from fs
upgrades
In addition to the block-based number assignments, OpenGFS uses some
special, non-disk lock numbers. They are defined in src/fs/ogfs_ondisk.h
(even though they don't show up on disk!):
[...]
This is intended as food for thought on how we should design our
support for shared disk file systems.
-Philipp
--
: Dipl-Ing Philipp Reisner Tel +43-1-8178292-50 :
: LINBIT Information Technologies GmbH Fax +43-1-8178292-82 :
: Schönbrunnerstr 244, 1120 Vienna, Austria http://www.linbit.com :
next reply other threads:[~2004-10-04 12:55 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-10-04 12:56 Philipp Reisner [this message]
2004-10-04 13:01 ` [Drbd-dev] How Locking in GFS works Lars Marowsky-Bree
2004-10-04 13:20 ` Lars Ellenberg
2004-10-04 13:41 ` Lars Marowsky-Bree
2004-10-04 13:26 ` Philipp Reisner
2004-10-04 13:49 ` Lars Marowsky-Bree
2004-10-04 14:09 ` Philipp Reisner
2004-10-04 14:17 ` Philipp Reisner
2004-10-04 15:12 ` Lars Ellenberg
2004-10-04 20:24 ` Lars Marowsky-Bree
2004-10-08 12:32 ` Philipp Reisner
2004-10-08 12:55 ` Lars Marowsky-Bree
2004-10-08 13:37 ` Philipp Reisner
2004-10-08 13:51 ` Lars Ellenberg
2004-10-11 7:12 ` Philipp Reisner
2004-10-11 10:09 ` Lars Ellenberg
2004-10-11 10:11 ` Lars Ellenberg
2004-10-11 12:28 ` Philipp Reisner
2004-10-11 12:41 ` Philipp Reisner
2004-10-05 19:37 ` Philipp Reisner
2004-10-05 19:39 ` Philipp Reisner
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=200410041456.21841.philipp.reisner@linbit.com \
--to=philipp.reisner@linbit.com \
--cc=drbd-dev@lists.linbit.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox