xfs
[Top] [All Lists]

TAKE 803625 - xfs_growfs QA failure and possible pagebuf problem

To: ananth@xxxxxxxxxxxxxxxxxxxx
Subject: TAKE 803625 - xfs_growfs QA failure and possible pagebuf problem
From: pv@xxxxxxxxxxxxxxxxxxxxxx (lord@xxxxxxx)
Date: Wed, 11 Oct 2000 15:40:05 -0700 (PDT)
Cc: linux-xfs@xxxxxxxxxxx
Reply-to: sgi.bugs.xfs@xxxxxxxxxxxxxxxxx
Sender: owner-linux-xfs@xxxxxxxxxxx
 Submitter : ajag                     *Status : closed                      
 Assigned Engineer : ananth           *Fixed By : lord                      
*Fixed By Domain : sgi.com            *Closed Date : 10/11/00               
 Priority : 2                         *Modified Date : 10/11/00             
*Modified User : lord                 *Modified User Domain : sgi.com       
*Fix Description :
From: steve lord <lord@xxxxxxx> (TAKE)
Date: Oct 11 2000 03:40:05PM
[pvnews version: 1.71]
----------------------------

In updating the secondary superblocks in growfs we ended up requesting
a buffer which overlapped with a previously written agf block. The
pagebuf module bounces this request. This is a difference in behavior
from irix, but we may as well ask for a buffer of the correct size
here and just update the secondary superblock.

Date:  Wed Oct 11 15:32:07 PDT 2000
Workarea:  jen.americas.sgi.com:/src/lord/xfs-linux.2.4

The following file(s) were checked into:
  bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs


Modid:  2.4.x-xfs:slinx:76090a
linux/fs/xfs/xfs_fsops.c - 1.60
        - When updating super blocks in growfs ask for a superblock sized
          buffer rather than an fs block size buffer. This prevents us from
          overlapping with other buffers previously written.
Description :
The growfs QA test creates a 16Mb filesystem with one allocation group and
sucessively grows its size to 17, 33, 35 and 48 megabyte (3 ags) with four 
calls to
xfs_growfs. The first growfs appears to succeed, however, subsequents calls fail
on a call to xfs_read_buf (line 336 xfs_fsops.c) while writing out the redundant
superblocks for the filesystem. The call sequence looks like:
 
xfs_growfs_data_private
  xfs_read_buf (function)
    xfs_buf_read (macro)
      pagebuf_get (function call at line 747 page_buf.c)

.....


==========================
ADDITIONAL INFORMATION (ADD)
From: lord@xxxxxxx (BugWorks)
Date: Oct 03 2000 11:22:27AM
==========================

It looks like the pagebuf written out for the first superblock
update has not been written yet - it should get unlocked at the
end of the write to disk. If you turn on pagebuf tracing,
and call BUG() where the EBUSY error is happening the pbtrace
will tell you who did what with the buffer.

<Prev in Thread] Current Thread [Next in Thread>
  • TAKE 803625 - xfs_growfs QA failure and possible pagebuf problem, lord@xxxxxxx <=