Bug 128019 - unlock log file on gfs, multiple access to file
unlock log file on gfs, multiple access to file
Status: CLOSED CURRENTRELEASE
Product: Red Hat Cluster Suite
Classification: Red Hat
Component: gfs (Show other bugs)
3
i686 Linux
medium Severity medium
: ---
: ---
Assigned To: David Teigland
Cluster QE
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2004-07-16 09:46 EDT by Anton Nekhoroshikh
Modified: 2010-01-11 21:54 EST (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2004-08-19 00:07:29 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Anton Nekhoroshikh 2004-07-16 09:46:45 EDT
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6)
Gecko/20040113

Description of problem:
apache2 write request info in log file placed on gfs

after 10-20 requests i see in apache server-status state "Logging"
and on disk i cannot look in log file is blocked :(

after 5-10 minutes file unblocked and i don't see state "Logging" in
server-status page.

Looking in /proc/cluster/dlm_locks shows no waiting or converting locks.

This is the content of dlm_debug:

       0"
gfs01 send lu 387006c to 2
gfs01 lookup reply 387006c 0
gfs01 cv 5 387006c "       8               0"
gfs01 un 387006c ref 1 flg 4 nodeid 0/-1 "       8
gfs01 rq 3 3ac0045 "       8               0"
gfs01 send lu 3ac0045 to 2
gfs01 lookup reply 3ac0045 0
gfs01 cv 5 3ac0045 "       8               0"
gfs01 un 3ac0045 ref 1 flg 4 nodeid 0/-1 "       8
gfs01 rq 3 3550366 "       8               0"
gfs01 send lu 3550366 to 2
gfs01 lookup reply 3550366 0
gfs01 cv 5 3550366 "       8               0"
gfs01 un 3550366 ref 1 flg 4 nodeid 0/-1 "       8
gfs01 rq 3 392012c "       8               0"
gfs01 send lu 392012c to 2
gfs01 lookup reply 392012c 0
gfs01 cv 5 392012c "       8               0"
gfs01 un 392012c ref 1 flg 4 nodeid 0/-1 "       8
gfs01 rq 3 362029f "       8               0"
gfs01 send lu 362029f to 2
gfs01 lookup reply 362029f 0
gfs01 cv 5 362029f "       8               0"
gfs01 un 362029f ref 1 flg 4 nodeid 0/-1 "       8

Version-Release number of selected component (if applicable):


How reproducible:
Always

Steps to Reproduce:
1. start apache on gfs
2. make over 20 requests 

    

Additional info:
Comment 1 Anton Nekhoroshikh 2004-07-16 09:54:19 EDT
This is the content of lock_dlm_debug:

a01dd cur 5
qc 8,0 5,5 id 55a01dd sts -65538
lk 8,0 id 0 -1,3 8
qc 8,0 -1,3 id 56303db sts 0
lk 8,0 id 56303db 3,5 5c
qc 8,0 3,5 id 56303db sts 0
un 8,0 id 56303db cur 5
qc 8,0 5,5 id 56303db sts -65538
lk 8,0 id 0 -1,3 8
qc 8,0 -1,3 id 54300df sts 0
lk 8,0 id 54300df 3,5 5c
qc 8,0 3,5 id 54300df sts 0
un 8,0 id 54300df cur 5
qc 8,0 5,5 id 54300df sts -65538
lk 8,0 id 0 -1,3 8
qc 8,0 -1,3 id 594031b sts 0
lk 8,0 id 594031b 3,5 5c
qc 8,0 3,5 id 594031b sts 0
un 8,0 id 594031b cur 5
qc 8,0 5,5 id 594031b sts -65538
lk 8,0 id 0 -1,3 8
qc 8,0 -1,3 id 56c03a9 sts 0
lk 8,0 id 56c03a9 3,5 5c
qc 8,0 3,5 id 56c03a9 sts 0
un 8,0 id 56c03a9 cur 5
qc 8,0 5,5 id 56c03a9 sts -65538
lk 8,0 id 0 -1,3 8
qc 8,0 -1,3 id 58c0094 sts 0
lk 8,0 id 58c0094 3,5 5c
qc 8,0 3,5 id 58c0094 sts 0
un 8,0 id 58c0094 cur 5
qc 8,0 5,5 id 58c0094 sts -65538
lk 8,0 id 0 -1,3 8
qc 8,0 -1,3 id 566036d sts 0
lk 8,0 id 566036d 3,5 5c
qc 8,0 3,5 id 566036d sts 0
un 8,0 id 566036d cur 5
qc 8,0 5,5 id 566036d sts -65538
lk 8,0 id 0 -1,3 8
qc 8,0 -1,3 id 5420064 sts 0
lk 8,0 id 5420064 3,5 5c
qc 8,0 3,5 id 5420064 sts 0
un 8,0 id 5420064 cur 5
qc 8,0 5,5 id 5420064 sts -65538
lk 8,0 id 0 -1,3 8
qc 8,0 -1,3 id 5720133 sts 0
lk 8,0 id 5720133 3,5 5c
qc 8,0 3,5 id 5720133 sts 0
un 8,0 id 5720133 cur 5
qc 8,0 5,5 id 5720133 sts -65538
lk 8,0 id 0 -1,3 8
qc 8,0 -1,3 id 5510349 sts 0
lk 8,0 id 5510349 3,5 5c
qc 8,0 3,5 id 5510349 sts 0
un 8,0 id 5510349 cur 5
qc 8,0 5,5 id 5510349 sts -65538
lk 8,0 id 0 -1,3 8
qc 8,0 -1,3 id 5450083 sts 0
lk 8,0 id 5450083 3,5 5c
qc 8,0 3,5 id 5450083 sts 0
un 8,0 id 5450083 cur 5
qc 8,0 5,5 id 5450083 sts -65538
lk 8,0 id 0 -1,3 8
qc 8,0 -1,3 id 5580013 sts 0
lk 8,0 id 5580013 3,5 5c
qc 8,0 3,5 id 5580013 sts 0
un 8,0 id 5580013 cur 5
qc 8,0 5,5 id 5580013 sts -65538
lk 8,0 id 0 -1,3 8
qc 8,0 -1,3 id 57c00ee sts 0
lk 8,0 id 57c00ee 3,5 5c
qc 8,0 3,5 id 57c00ee sts 0
un 8,0 id 57c00ee cur 5
qc 8,0 5,5 id 57c00ee sts -65538
lk 8,0 id 0 -1,3 8
qc 8,0 -1,3 id 55902ad sts 0
.....
.....
Comment 2 David Teigland 2004-07-16 11:04:39 EDT
could you include which revision of cluster/gfs-kernel/src/dlm/lock.c
you're using by running "cvs log lock.c"
Comment 3 Anton Nekhoroshikh 2004-07-16 11:30:38 EDT
[root@c5 2.6.7]# cvs log lock_dlm.patch

RCS file: /cvs/cluster/cluster/gfs-kernel/patches/2.6.7/lock_dlm.patch,v
Working file: lock_dlm.patch
head: 1.3
branch:
locks: strict
access list:
symbolic names:
        gfs_kernel_2_6_7_1: 1.3
keyword substitution: kv
total revisions: 3;     selected revisions: 3
description:
----------------------------
revision 1.3
date: 2004/07/13 11:17:02;  author: teigland;  state: Exp;  lines:
+130 -101
update from src files
----------------------------
revision 1.2
date: 2004/07/09 03:37:56;  author: teigland;  state: Exp;  lines: +17 -18
pjc found spot where lock struct wasn't being freed
----------------------------
revision 1.1
date: 2004/06/24 08:53:26;  author: agk;  state: Exp;
Initial checkin.
=============================================================================
Comment 4 Anton Nekhoroshikh 2004-07-16 11:31:23 EDT
and with pacth:

--- lock.c.orig 2004-07-15 23:28:33.000000000 +0800
+++ lock.c      2004-07-15 23:30:36.000000000 +0800
@@ -311,6 +311,7 @@
 
 void do_dlm_unlock(dlm_lock_t *lp)
 {
+       unsigned int lkf = 0;
        int error;
 
        set_bit(LFL_DLM_UNLOCK, &lp->flags);
@@ -319,7 +320,10 @@
        log_debug("un %x,%"PRIx64" id %x cur %d", lp->lockname.ln_type,
                  lp->lockname.ln_number, lp->lksb.sb_lkid, lp->cur);
 
-       error = dlm_unlock(lp->dlm->gdlm_lsp, lp->lksb.sb_lkid, 0,
&lp->lksb,
+       if (lp->lvb)
+               lkf = DLM_LKF_VALBLK;
+
+       error = dlm_unlock(lp->dlm->gdlm_lsp, lp->lksb.sb_lkid, lkf,
&lp->lksb,
                            (void *) lp);
 
        DLM_ASSERT(!error, printk("%s: error=%d num=%x,%"PRIx64"\n",

Comment 5 David Teigland 2004-07-16 11:57:02 EDT
I've updated both dlm.patch and lock_dlm.patch with a number of fixes 
so please try again.

(We often make changes to the source files in the src/ directory
but don't to update the kernel patch in the patches/ directory, so if
you want the latest code, please use the src/ files.  We'll try to
update the patches often, too.)
Comment 6 Anton Nekhoroshikh 2004-07-16 14:59:37 EDT
Thanks, problem has disappeared.

Note You need to log in before you can comment on or make changes to this bug.