1. 11 Mar, 2010 1 commit
    • Benjamin Marzinski's avatar
      GFS2: Allow the number of committed revokes to temporarily be negative · 2e95e3f6
      Benjamin Marzinski authored
      GFS2 tracks the number of revokes and unrevokes that are part of committed
      transactions via sd_log_commited_revoke. It is possible for one process to add
      revokes during its transaction, while another process unrevokes them during its
      transaction. If the second process finishes its transaction first,
      sd_log_commited_revoke will be decremented by the number of unrevokes that the
      second process did, without first being incremented by the number of revokes
      the first process did. This is fine, since all started transactions must be
      completed before the journal can be flushed.  However, sd_log_commited_revoke
      is an unsigned integer, and log_refund() causes an assertion failure if it
      would go negative at the end of a transaction.  This patch makes
      sd_log_commited_revoke a signed integer and allows it to go negative.
      __gfs2_log_flush() still checks that it mataches the actual number of revokes.
      Signed-off-by: default avatarBenjamin Marzinski <bmarzins@redhat.com>
      Signed-off-by: default avatarSteven Whitehouse <swhiteho@redhat.com>
  2. 03 Dec, 2009 1 commit
    • Steven Whitehouse's avatar
      GFS2: Tag all metadata with jid · 0ab7d13f
      Steven Whitehouse authored
      There are two spare field in the header common to all GFS2
      metadata. One is just the right size to fit a journal id
      in it, and this patch updates the journal code so that each
      time a metadata block is modified, we tag it with the journal
      id of the node which is performing the modification.
      The reason for this is that it should make it much easier to
      debug issues which arise if we can tell which node was the
      last to modify a particular metadata block.
      Since the field is updated before the block is written into
      the journal, each journal should only contain metadata which
      is tagged with its own journal id. The one exception to this
      is the journal header block, which might have a different node's
      id in it, if that journal was recovered by another node in the
      Thus each journal will contain a record of which nodes recovered
      it, via the journal header.
      The other field in the metadata header could potentially be
      used to hold information about what kind of operation was
      performed, but for the time being we just zero it on each
      transaction so that if we use it for that in future, we'll
      know that the information (where it exists) is reliable.
      I did consider using the other field to hold the journal
      sequence number, however since in GFS2's journaling we write
      the modified data into the journal and not the original
      data, this gives no information as to what action caused the
      modification, so I think we can probably come up with a better
      use for those 64 bits in the future.
      Signed-off-by: default avatarSteven Whitehouse <swhiteho@redhat.com>
  3. 12 Jun, 2009 1 commit
    • Steven Whitehouse's avatar
      GFS2: Add tracepoints · 63997775
      Steven Whitehouse authored
      This patch adds the ability to trace various aspects of the GFS2
      filesystem. The trace points are divided into three groups,
      glocks, logging and bmap. These points have been chosen because
      they allow inspection of the major internal functions of GFS2
      and they are also generic enough that they are unlikely to need
      any major changes as the filesystem evolves.
      Signed-off-by: default avatarSteven Whitehouse <swhiteho@redhat.com>
  4. 11 Jun, 2009 1 commit
  5. 11 May, 2009 1 commit
  6. 24 Mar, 2009 1 commit
    • Steven Whitehouse's avatar
      GFS2: Merge lock_dlm module into GFS2 · f057f6cd
      Steven Whitehouse authored
      This is the big patch that I've been working on for some time
      now. There are many reasons for wanting to make this change
      such as:
       o Reducing overhead by eliminating duplicated fields between structures
       o Simplifcation of the code (reduces the code size by a fair bit)
       o The locking interface is now the DLM interface itself as proposed
         some time ago.
       o Fewer lookups of glocks when processing replies from the DLM
       o Fewer memory allocations/deallocations for each glock
       o Scope to do further optimisations in the future (but this patch is
         more than big enough for now!)
      Please note that (a) this patch relates to the lock_dlm module and
      not the DLM itself, that is still a separate module; and (b) that
      we retain the ability to build GFS2 as a standalone single node
      filesystem with out requiring the DLM.
      This patch needs a lot of testing, hence my keeping it I restarted
      my -git tree after the last merge window. That way, this has the maximum
      exposure before its merged. This is (modulo a few minor bug fixes) the
      same patch that I've been posting on and off the the last three months
      and its passed a number of different tests so far.
      Signed-off-by: default avatarSteven Whitehouse <swhiteho@redhat.com>
  7. 26 Sep, 2008 1 commit
    • Steven Whitehouse's avatar
      GFS2: Support for I/O barriers · 254db57f
      Steven Whitehouse authored
      This patch adds barrier support to GFS2. There is not a lot of change
      really... we just add the barrier flag when we write journal header
      blocks. If the underlying device refuses to support them, we fall back
      to the previous way of doing things (wait for the I/O and hope) since
      there is nothing else we can do. There is no user configuration,
      barriers will always be on unless the device refuses to support them.
      This seems a reasonable solution to me since this is a correctness
      Signed-off-by: default avatarSteven Whitehouse <swhiteho@redhat.com>
  8. 27 Jun, 2008 1 commit
  9. 18 Apr, 2008 1 commit
  10. 31 Mar, 2008 1 commit
    • Bob Peterson's avatar
      [GFS2] Only do lo_incore_commit once · d0109bfa
      Bob Peterson authored
      This patch is performance related.  When we're doing a log flush,
      I noticed we were calling buf_lo_incore_commit twice: once for
      data bufs and once for metadata bufs.  Since this is the same
      function and does the same thing in both cases, there should be
      no reason to call it twice.  Since we only need to call it once,
      we can also make it faster by removing it from the generic "lops"
      code and making it a stand-along static function.
      Signed-off-by: default avatarBob Peterson <rpeterso@redhat.com>
      Signed-off-by: default avatarSteven Whitehouse <swhiteho@redhat.com>
  11. 25 Jan, 2008 11 commits
  12. 10 Oct, 2007 8 commits
  13. 09 Jul, 2007 5 commits
    • Steven Whitehouse's avatar
      [GFS2] Small fixes to logging code · a0a24741
      Steven Whitehouse authored
      This reverts part of an earlier patch which tried to reclaim
      gfs2_bufdata structures too early and resulted in a "use after free"
      case (this bit from me). Also a change to not write out log headers
      unless we really need to (in the case of flushing nothing we don't need
      a header) from Bob.
      Signed-off-by: default avatarSteven Whitehouse <swhiteho@redhat.com>
      Signed-off-by: default avatarBob Peterson <rpeterso@redhat.com>
    • Robert Peterson's avatar
      [GFS2] assertion failure after writing to journaled file, umount · 2332c443
      Robert Peterson authored
      This patch passes all my nasty tests that were causing the code to
      fail under one circumstance or another.  Here is a complete summary
      of all changes from today's git tree, in order of appearance:
      1. There are now separate variables for metadata buffer accounting.
      2. Variable sd_log_num_hdrs is no longer needed, since the header
         accounting is taken care of by the reserve/refund sequence.
      3. Fixed a tiny grammatical problem in a comment.
      4. Added a new function "calc_reserved" to calculate the reserved
         log space.  This isn't entirely necessary, but it has two benefits:
         First, it simplifies the gfs2_log_refund function greatly.
         Second, it allows for easier debugging because I could sprinkle the
         code with calls to this function to make sure the accounting is
         proper (by adding asserts and printks) at strategic point of the code.
      5. In log_pull_tail there apparently was a kludge to fix up the
         accounting based on a "pull" parameter.  The buffer accounting is
         now done properly, so the kludge was removed.
      6. File sync operations were making a call to gfs2_log_flush that
         writes another journal header.  Since that header was unplanned
         for (reserved) by the reserve/refund sequence, the free space had
         to be decremented so that when log_pull_tail gets called, the free
         space is be adjusted properly.  (Did I hear you call that a kludge?
         well, maybe, but a lot more justifiable than the one I removed).
      7. In the gfs2_log_shutdown code, it optionally syncs the log by
         specifying the PULL parameter to log_write_header.  I'm not sure
         this is necessary anymore.  It just seems to me there could be
         cases where shutdown is called while there are outstanding log
      8. In the (data)buf_lo_before_commit functions, I changed some offset
         values from being calculated on the fly to being constants.	That
         simplified some code and we might as well let the compiler do the
         calculation once rather than redoing those cycles at run time.
      9. This version has my rewritten databuf_lo_add function.
         This version is much more like its predecessor, buf_lo_add, which
         makes it easier to understand.  Again, this might not be necessary,
         but it seems as if this one works as well as the previous one,
         maybe even better, so I decided to leave it in.
      10. In databuf_lo_before_commit, a previous data corruption problem
         was caused by going off the end of the buffer.  The proper solution
         is to have the proper limit in place, rather than stopping earlier.
         (Thus my previous attempt to fix it is wrong).
         If you don't wrap the buffer, you're stopping too early and that
         causes more log buffer accounting problems.
      11. In lops.h there are two new (previously mentioned) constants for
         figuring out the data offset for the journal buffers.
      12. There are also two new functions, buf_limit and databuf_limit to
         calculate how many entries will fit in the buffer.
      13. In function gfs2_meta_wipe, it needs to distinguish between pinned
         metadata buffers and journaled data buffers for proper journal buffer
         accounting.	It can't use the JDATA gfs2_inode flag because it's
         sometimes passed the "real" inode and sometimes the "metadata
         inode" and the inode flags will be random bits in a metadata
         gfs2_inode.	It needs to base its decision on which was passed in.
      Signed-off-by: default avatarBob Peterson <rpeterso@redhat.com>
      Signed-off-by: default avatarSteven Whitehouse <swhiteho@redhat.com>
    • Robert Peterson's avatar
      [GFS2] Journaled file write/unstuff bug · 8fb68595
      Robert Peterson authored
      This patch is for bugzilla bug 283162, which uncovered a number of
      bugs pertaining to writing to files that have the journaled bit on.
      These bugs happen most often when writing to the meta_fs because
      the files are always journaled.  So operations like gfs2_grow were
      particularly vulnerable, although many of the problems could be
      recreated with normal files after setting the journaled bit on.
      The problems fixed are:
      -GFS2 wasn't ever writing unstuffed journaled data blocks to their
       in-place location on disk. Now it does.
      -If you unmounted too quickly after doing IO to a journaled file,
       GFS2 was crashing because you would discard a buffer whose bufdata
       was still on the active items list.  GFS2 now deals with this
      -GFS2 was losing track of the bufdata for journaled data blocks,
       and it wasn't getting freed, causing an error when you tried to
       unmount the module.  GFS2 now frees all the bufdata structures.
      -There was a memory corruption occurring because GFS2 wrote
       twice as many log entries for journaled buffers.
      -It was occasionally trying to write journal headers in buffers
       that weren't currently mapped.
      Signed-off-by: default avatarBob Peterson <rpeterso@redhat.com>
      Signed-off-by: default avatarBenjamin Marzinski <bmarzins@redhat.com>
      Signed-off-by: default avatarSteven Whitehouse <swhiteho@redhat.com>
    • Benjamin Marzinski's avatar
      [GFS2] fix jdata issues · ddf4b426
      Benjamin Marzinski authored
      This is a patch for the first three issues of RHBZ #238162
      The first issue is that when you allocate a new page for a file, it will not
      start off uptodate. This makes sense, since you haven't written anything to that
      part of the file yet.  Unfortunately, gfs2_pin() checks to make sure that the
      buffers are uptodate.  The solution to this is to mark the buffers uptodate in
      gfs2_commit_write(), after they have been zeroed out and have the data written
      into them.  I'm pretty confident with this fix, although it's not completely
      obvious that there is no problem with marking the buffers uptodate here.
      The second issue is simply that you can try to pin a data buffer that is already
      on the incore log, and thus, already pinned. This patch checks to see if this
      buffer is already on the log, and exits databuf_lo_add() if it is, just like
      buf_lo_add() does.
      The third issue is that gfs2_log_flush() doesn't do it's block accounting
      correctly.  Both metadata and journaled data are logged, but gfs2_log_flush()
      only compares the number of metadata blocks with the number of blocks to commit
      to the ondisk journal.  This patch also counts the journaled data blocks.
      Signed-off-by: default avatarBenjamin Marzinski <bmarzins@redhat.com>
      Signed-off-by: default avatarSteven Whitehouse <swhiteho@redhat.com>
    • Steven Whitehouse's avatar
      [GFS2] Make the log reserved blocks depend on block size · 89918647
      Steven Whitehouse authored
      The number of blocks which we reserve in the log at the start of each
      transaction needs to depends upon the block size since the overhead is
      related to the number of "pointers" which can be fitted into a single
      This relates to Red Hat bz #240435
      Signed-off-by: default avatarSteven Whitehouse <swhiteho@redhat.com>
  14. 30 Nov, 2006 3 commits
    • Ryusuke Konishi's avatar
      [GFS2] fs/gfs2/log.c:log_bmap() fix printk format warning · aed3255f
      Ryusuke Konishi authored
      Fix a printk format warning in fs/gfs2/log.c:
      fs/gfs2/log.c:322: warning: format '%llu' expects type 'long long unsigned int', but argument 3 has type 'sector_t'
      Signed-off-by: default avatarRyusuke Konishi <ryusuke@osrg.net>
      Signed-off-by: default avatarSteven Whitehouse <swhiteho@redhat.com>
    • Steven Whitehouse's avatar
      [GFS2] Move gfs2_meta_syncfs() into log.c · a25311c8
      Steven Whitehouse authored
      By moving gfs2_meta_syncfs() into log.c, gfs2_ail1_start()
      can be made static.
      Signed-off-by: default avatarSteven Whitehouse <swhiteho@redhat.com>
    • Steven Whitehouse's avatar
      [GFS2] Fix journal flush problem · b004157a
      Steven Whitehouse authored
      This fixes a bug which resulted in poor performance due to flushing
      the journal too often. The code path in question was via the inode_go_sync()
      function in glops.c. The solution is not to flush the journal immediately
      when inodes are ejected from memory, but batch up the work for glockd to
      deal with later on. This means that glocks may now live on beyond the end of
      the lifetime of their inodes (but not very much longer in the normal case).
      Also fixed in this patch is a bug (which was hidden by the bug mentioned above) in
      calculation of the number of free journal blocks.
      The gfs2_logd process has been altered to be more responsive to the journal
      filling up. We now wake it up when the number of uncommitted journal blocks
      has reached the threshold level rather than trying to flush directly at the
      end of each transaction. This again means doing fewer, but larger, log
      flushes in general.
      Signed-off-by: default avatarSteven Whitehouse <swhiteho@redhat.com>
  15. 20 Oct, 2006 1 commit
  16. 12 Oct, 2006 1 commit
  17. 03 Oct, 2006 1 commit