Distributed Replicated Block Device (DRBD) development
 help / color / mirror / Atom feed
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 :

             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