cluster-devel.redhat.com archive mirror
 help / color / mirror / Atom feed
From: Robert Peterson <rpeterso@redhat.com>
To: cluster-devel.redhat.com
Subject: [Cluster-devel] [PATCH] GFS2: kernel changes to support new gfs2_grow command (Try 3)
Date: Tue, 08 May 2007 09:17:44 -0500	[thread overview]
Message-ID: <46408688.7060507@redhat.com> (raw)
In-Reply-To: <463BAA28.7000407@redhat.com>

Robert Peterson wrote:
> David Teigland wrote:
>> On Wed, May 02, 2007 at 08:57:08PM -0500, Robert Peterson wrote:
>>> @@ -978,18 +1038,25 @@ int gfs2_inplace_reserve_i(struct gfs2_inode *ip, 
>>
>>> -    error = gfs2_rindex_hold(sdp, &al->al_ri_gh);
>>> +    /* We need to hold the rindex unless the inode we're using is
>>> +       the rindex itself, in which case it's already held. */
>>> +    if (ip != GFS2_I(sdp->sd_rindex))
>>> +        error = gfs2_rindex_hold(sdp, &al->al_ri_gh);
>>> +    else if (!sdp->sd_rgrps) /* We may not have the rindex read in, 
>>> so: */
>>> +        error = gfs2_check_rindex_version(sdp);
>>> +
>>
>> I don't see why we need this change, the original looks correct.
> 
> If we're updating through the meta_fs, the rindex file will already be
> glocked and held through its inode.
> 
>> So there are the two distinct parts to the fs-grow procedure.  The first
>> is writing to the rindex and statfs files -- this is what was missing in
>> gfs2, and I'm ignoring that part for now.
>>
>> The second part is gfs detecting that a grow took place and updating its
>> list of rg's.  I don't think this part needs any changing at all, it
>> should work the same way it always has -- this is what I'm focussing on.
> 
> I'll re-test test the original code path to make sure that this part of
> the fix is still really necessary.
> 
> Regards,
> 
> Bob Peterson
> Red Hat Cluster Suite
> 
Hi Dave,

Well, I retested this code path and found that this code is still 
necessary  (unless I should somehow be doing this a different way).
Without the code, the gfs2_rindex_hold tries to add a holder,
but there's already a holder due to the meta_fs.  Under the right 
conditions, you get:

original: gfs2_prepare_write+0x49/0x237 [gfs2]
new: gfs2_rindex_hold+0x2b/0x52a [gfs2]
------------[ cut here ]------------
kernel BUG at fs/gfs2/glock.c:1057!
invalid opcode: 0000 [#1]
SMP 
Modules linked in: lock_dlm gfs2 dlm configfs sd_mod sg qla2xxx
CPU:    0
EIP:    0060:[<e02a2fd3>]    Not tainted VLI
EFLAGS: 00010282   (2.6.21 #2)
EIP is at gfs2_glock_nq+0xff/0x1a6 [gfs2]
eax: 00000020   ebx: c3070b54   ecx: 00000046   edx: 00000046
esi: c3070c2c   edi: d5147b1c   ebp: d5147b1c   esp: d18f7bf0
ds: 007b   es: 007b   fs: 00d8  gs: 0033  ss: 0068
Process gfs2_grow (pid: 5762, ti=d18f6000 task=df6e9ab0 task.ti=d18f6000)
Stack: e02b8e4e 00000002 00000001 c8ba1000 00000000 c8ba1000 00000000 c8ba1000 
       c307099c e02b33f0 c3070c2c 00000000 d5147b1c c3070c98 def5eeb8 d521d108 
       00001000 c3070c2c d18f7c6c c307099c d18f7cbc e029a2c1 d18f7c6c 00000000 
Call Trace:
 [<e02b33f0>] gfs2_rindex_hold+0x34/0x52a [gfs2]
 [<e029a2c1>] gfs2_block_map+0x39f/0x3ab [gfs2]
 [<c04078a5>] __sched_text_start+0x715/0x7c4
 [<e029a335>] gfs2_extent_map+0x68/0x9c [gfs2]
 [<e02b3e08>] gfs2_inplace_reserve_i+0x7b/0x418 [gfs2]
 [<e029a4fb>] gfs2_write_alloc_required+0x192/0x1ce [gfs2]
 [<e02aad58>] gfs2_prepare_write+0x12d/0x237 [gfs2]
 [<e02aac2b>] gfs2_prepare_write+0x0/0x237 [gfs2]
 [<c0138422>] generic_file_buffered_write+0x25b/0x60f
 [<c016857e>] __mark_inode_dirty+0xdd/0x15c
 [<c011dbb6>] current_fs_time+0x41/0x46
 [<c0138cbd>] __generic_file_aio_write_nolock+0x4e7/0x560
 [<c013afef>] get_page_from_freelist+0x24f/0x2cf
 [<c0138d8b>] generic_file_aio_write+0x55/0xb3
 [<c01514cd>] do_sync_write+0xc7/0x10a
 [<e02a3293>] gfs2_holder_uninit+0xb/0x1b [gfs2]
 [<c01296cd>] autoremove_wake_function+0x0/0x35
 [<e02a3293>] gfs2_holder_uninit+0xb/0x1b [gfs2]
 [<e02ac3d8>] gfs2_llseek+0x76/0x9a [gfs2]
 [<c0151406>] do_sync_write+0x0/0x10a
 [<c0151c30>] vfs_write+0x8a/0x10c
 [<c015219f>] sys_write+0x41/0x67
 [<c01030d8>] sysenter_past_esp+0x5d/0x81
 [<c0400000>] svc_defer+0x6b/0x126
 =======================

Regards,

Bob Peterson
Red Hat Cluster Suite



  parent reply	other threads:[~2007-05-08 14:17 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-05-03  1:57 [Cluster-devel] [PATCH] GFS2: kernel changes to support new gfs2_grow command (Try 3) Robert Peterson
2007-05-04 16:47 ` David Teigland
2007-05-04 21:35   ` Robert Peterson
2007-05-04 22:16     ` David Teigland
2007-05-04 19:37 ` David Teigland
2007-05-04 21:37   ` Robert Peterson
2007-05-08 14:56   ` Robert Peterson
2007-05-04 20:23 ` David Teigland
2007-05-04 21:48   ` Robert Peterson
2007-05-04 22:04     ` David Teigland
2007-05-08 14:17     ` Robert Peterson [this message]
2007-05-08 14:24       ` Steven Whitehouse
  -- strict thread matches above, loose matches on Subject: below --
2007-05-08 20:42 David Teigland
2007-05-08 20:43 David Teigland

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=46408688.7060507@redhat.com \
    --to=rpeterso@redhat.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;
as well as URLs for NNTP newsgroup(s).