From owner-linux-xfs@oss.sgi.com Sat Apr  1 04:42:44 2000
Received:  by oss.sgi.com id <S305260AbQDAMmZ>;
	Sat, 1 Apr 2000 04:42:25 -0800
Received: from Cantor.suse.de ([194.112.123.193]:46861 "HELO Cantor.suse.de")
	by oss.sgi.com with SMTP id <S305239AbQDAMmO>;
	Sat, 1 Apr 2000 04:42:14 -0800
Received: from Hermes.suse.de (Hermes.suse.de [194.112.123.136])
	by Cantor.suse.de (Postfix) with ESMTP
	id 861651E20A; Sat,  1 Apr 2000 14:42:11 +0200 (MEST)
Received: from gruyere.muc.suse.de (gruyere.muc.suse.de [10.23.1.2])
	by Hermes.suse.de (Postfix) with ESMTP
	id 23B9410A028; Sat,  1 Apr 2000 14:42:07 +0200 (MEST)
Received: by gruyere.muc.suse.de (Postfix, from userid 14446)
	id 8A1C32F36B; Sat,  1 Apr 2000 14:42:05 +0200 (MEST)
Date:   Sat, 1 Apr 2000 14:42:05 +0200
From:   "Andi Kleen" <ak@suse.de>
To:     Steve Lord <lord@sgi.com>
Cc:     Bernd Markgraf <markgraf@prinz-atm.CS.Uni-Magdeburg.De>,
        linux-xfs@oss.sgi.com
Subject: Re: copying to xfs causes cp to go to sleep
Message-ID: <20000401144205.A31235@gruyere.muc.suse.de>
References: <200003312005.OAA10765@jen.americas.sgi.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 1.0i
In-Reply-To: <200003312005.OAA10765@jen.americas.sgi.com>; from lord@sgi.com on Fri, Mar 31, 2000 at 02:05:23PM -0600
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing

On Fri, Mar 31, 2000 at 02:05:23PM -0600, Steve Lord wrote:
> > hi,
> > 
> > first the good news: compiles out of the box...
> > now the bad news: i've got a 1gb partition with xfs and my homedir
> > (something just under 1gb data). so first test is to copy the homedir to
> > the xfs filesystem... works great until the filesystem is about halfway
> > full. then nothing else happens. the cp is still in the process list but
> > sleeping and never woke up until i killed it (i waited roughly 5h) 
> > btw. as long as the cp was running kswapd was eating quite a bit of cpu
> > time, but hey... didn't crash so far ;-)
> > 
> > the snapshot i used was the tarball from the ftp-server and a following
> > cvs update (done today 2p.m. gmt)
> > 
> > anyone any ideas?
> > 
> >   bernd
> > 
> 
> How many files are we talking about here? I regularly copy kernel trees
> into XFS. Is it possible that if you multiply the number of files you
> have in your directory by 64K you get close to filling the 1Gbyte?
> There is a bug where preallocation of space does not get pruned down
> until unmount time, and the is another bug (an infinite loop) in the
> out of space case.

I see the same problem (cp hanging) when I copy a tree with all rfcs
(suse/doc2/rfc.rpm on a suse CD) onto a XFS partition.
> 
> Alternatively:
> 
> Did you compile with CONFIG_PAGE_BUF_META turned on? You could try running
> without it - all the hard hangs I have seen have had this enabled.
> 
> Also, do you have 1 cpu or more in your box?
> 
> If you have SMP hardware you could turn on the nmi_watchdog (see 
> Documentation/nmi_watchdog.txt) and run ksymoops on the output if
> you get any.

nmi_watchdog should normally on by default in 2.3 ATM. 
He probably has a UP machine. 


> If this is a really hard hang I suspect the kdb debugger will not
> help diagnose the problem.

It just oopsed in the rfc cp with a NULL pointer dereference in sys_open.
Should be reproducable (it is here at least) 



-Andi


From owner-linux-xfs@oss.sgi.com Sat Apr  1 05:59:44 2000
Received:  by oss.sgi.com id <S305263AbQDAN7f>;
	Sat, 1 Apr 2000 05:59:35 -0800
Received: from csmd2.CS.Uni-Magdeburg.De ([141.44.22.2]:44760 "EHLO
        csmd2.cs.uni-magdeburg.de") by oss.sgi.com with ESMTP
	id <S305239AbQDAN72>; Sat, 1 Apr 2000 05:59:28 -0800
Received: from knecht.cs.uni-magdeburg.de (markgraf@knecht [141.44.21.3])
	by csmd2.cs.uni-magdeburg.de (8.9.3/8.9.3) with ESMTP id PAA12994;
	Sat, 1 Apr 2000 15:59:26 +0200 (MET DST)
Received: from localhost (markgraf@localhost)
	by knecht.cs.uni-magdeburg.de (8.8.8+Sun/8.8.8) with SMTP id PAA21382;
	Sat, 1 Apr 2000 15:58:27 +0200 (MET DST)
X-Authentication-Warning: knecht.cs.uni-magdeburg.de: markgraf owned process doing -bs
Date:   Sat, 1 Apr 2000 15:58:27 +0200 (MET DST)
From:   Bernd Markgraf <markgraf@mail.CS.Uni-Magdeburg.De>
X-Sender: markgraf@knecht
To:     Andi Kleen <ak@suse.de>
cc:     linux-xfs@oss.sgi.com
Subject: Re: copying to xfs causes cp to go to sleep
In-Reply-To: <20000401144205.A31235@gruyere.muc.suse.de>
Message-ID: <Pine.GSO.3.95.1000401155316.21271C-100000@knecht>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing

hi again,

> > How many files are we talking about here? I regularly copy kernel trees
roughly 8000 files we're talking about. size some bytes to 400MB.

> > into XFS. Is it possible that if you multiply the number of files you
> > have in your directory by 64K you get close to filling the 1Gbyte?
nope... i should be able to copy like 16000 file to that partition, so i'm
nowhere near this limit.

> > Did you compile with CONFIG_PAGE_BUF_META turned on? You could try running
> > without it - all the hard hangs I have seen have had this enabled.
nope, # CONFIG_PAGE_BUF_META is not set
 
> > Also, do you have 1 cpu or more in your box?
just one 266mhz pII
 
> It just oopsed in the rfc cp with a NULL pointer dereference in sys_open.
> Should be reproducable (it is here at least) 
just building a kernel with kdb-support and check this out...


  berny
--
Death is happy, death is cool       
Death can be a useful tool         
Use a gun or use a knife          
Death can really change your life    
_________________________________________________________________________
Bernd Markgraf		                  Otto-von-Guericke-Universitaet
markgraf@mail.cs.uni-magdeburg.de         Magdeburg
http://www.cs.uni-magdeburg.de/~markgraf  Germany


From owner-linux-xfs@oss.sgi.com Sat Apr  1 06:18:55 2000
Received:  by oss.sgi.com id <S305265AbQDAOSp>;
	Sat, 1 Apr 2000 06:18:45 -0800
Received: from pneumatic-tube.sgi.com ([204.94.214.22]:49431 "EHLO
        pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP
	id <S305239AbQDAOSj>; Sat, 1 Apr 2000 06:18:39 -0800
Received: from ledzep.cray.com (ledzep.cray.com [137.38.226.97]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id GAA04855
	for <linux-xfs@oss.sgi.com>; Sat, 1 Apr 2000 06:22:21 -0800 (PST)
	mail_from (lord@sgi.com)
Received: from ironwood-e185.americas.sgi.com (ironwood.cray.com [128.162.185.212]) by ledzep.cray.com (SGI-SGI-8.9.3/craymail-smart-nospam1.0) with ESMTP id IAA18234; Sat, 1 Apr 2000 08:17:21 -0600 (CST)
Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.184.86]) by ironwood-e185.americas.sgi.com (8.8.4/SGI-ironwood-e1.4) with ESMTP id IAA27972; Sat, 1 Apr 2000 08:17:14 -0600 (CST)
From:   Steve Lord <lord@sgi.com>
Received: from jen.americas.sgi.com by jen.americas.sgi.com (8.9.3/SGI-client.1.6) via ESMTP id IAA14794; Sat, 1 Apr 2000 08:17:10 -0600
Message-Id: <200004011417.IAA14794@jen.americas.sgi.com>
To:     Bernd Markgraf <markgraf@prinz-atm.CS.Uni-Magdeburg.De>
cc:     Andi Kleen <ak@suse.de>, linux-xfs@oss.sgi.com
Subject: Re: copying to xfs causes cp to go to sleep 
In-reply-to: Your message of "Sat, 01 Apr 2000 15:58:27 +0200
Date:   Sat, 01 Apr 2000 08:17:10 -0600
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing


OK for the cp blowing up try this patch against revision 1.40 of
xfs_iops.c (which should be the latest in the CVS tree). A failure
in create was returning 0 to the calling code.

I suspect the cp will still hang - I am working on the out of space
code path (which I still think could be triggered here), yet another
change will be required to deal with that one.

Steve

*** /usr/tmp/TmpDir.14774-0/linux/fs/xfs/linux/xfs_iops.c_1.40  Sat Apr  1 08:11:32 2000
--- linux/fs/xfs/linux/xfs_iops.c       Sat Apr  1 07:27:43 2000
***************
*** 114,120 ****
                VOP_MKDIR(dvp, (char *)dentry->d_name.name, &va, &vp,
                        &cred, error);
        } else {
!               error = -EINVAL;
        }
  
        if (!error) {
--- 114,120 ----
                VOP_MKDIR(dvp, (char *)dentry->d_name.name, &va, &vp,
                        &cred, error);
        } else {
!               error = EINVAL;
        }
  
        if (!error) {
***************
*** 128,134 ****
                }
                d_instantiate(dentry, ip);
        }
!       return 0;
  }
  
  
--- 128,134 ----
                }
                d_instantiate(dentry, ip);
        }
!       return -error;
  }
  
  
***************
*** 498,504 ****
          vp = LINVFS_GET_VP(ip);
        VOP_ACCESS(vp, mode, &cred, error);
  
!       return error ? -error : 0;
  }
  
  /* Brute force approach for now - copy data into linux inode
--- 498,504 ----
          vp = LINVFS_GET_VP(ip);
        VOP_ACCESS(vp, mode, &cred, error);
  
!       return -error;
  }
  
  /* Brute force approach for now - copy data into linux inode
***************
*** 517,535 ****
          va.va_mask = AT_STAT;
          VOP_GETATTR(vp, &va, 0, &cred, error);
  
!         inode->i_mode = VTTOIF(va.va_type) | va.va_mode;
!         inode->i_nlink = va.va_nlink;
!         inode->i_uid = va.va_uid;
!         inode->i_gid = va.va_gid;
!         inode->i_rdev = va.va_rdev;
!         inode->i_size = va.va_size;
!         inode->i_blocks = va.va_nblocks >> (PAGE_SHIFT - 9);
!         inode->i_blksize = PAGE_SIZE;
!         inode->i_atime = va.va_atime.tv_sec;
!         inode->i_mtime = va.va_mtime.tv_sec;
!         inode->i_ctime = va.va_ctime.tv_sec;
  
!         return 0;
  }
  
  int
--- 517,537 ----
          va.va_mask = AT_STAT;
          VOP_GETATTR(vp, &va, 0, &cred, error);
  
!       if (!error) {
!               inode->i_mode = VTTOIF(va.va_type) | va.va_mode;
!               inode->i_nlink = va.va_nlink;
!               inode->i_uid = va.va_uid;
!               inode->i_gid = va.va_gid;
!               inode->i_rdev = va.va_rdev;
!               inode->i_size = va.va_size;
!               inode->i_blocks = va.va_nblocks >> (PAGE_SHIFT - 9);
!               inode->i_blksize = PAGE_SIZE;
!               inode->i_atime = va.va_atime.tv_sec;
!               inode->i_mtime = va.va_mtime.tv_sec;
!               inode->i_ctime = va.va_ctime.tv_sec;
!       }
  
!         return -error;
  }
  
  int



From owner-linux-xfs@oss.sgi.com Sat Apr  1 06:51:15 2000
Received:  by oss.sgi.com id <S305264AbQDAOvG>;
	Sat, 1 Apr 2000 06:51:06 -0800
Received: from rising.starnet.gov.sg ([203.116.82.211]:49281 "EHLO
        rising.starnet.gov.sg") by oss.sgi.com with ESMTP
	id <S305239AbQDAOum>; Sat, 1 Apr 2000 06:50:42 -0800
Received: from starnet.gov.sg (dyn1-166cable.bp1.singa.pore.net [202.169.229.166])
	by rising.starnet.gov.sg (8.9.1/8.9.1) with ESMTP id WAA15273
	for <linux-xfs@oss.sgi.com>; Sat, 1 Apr 2000 22:50:38 +0800 (SGT)
Message-ID: <38E60CA8.1510A72D@starnet.gov.sg>
Date:   Sat, 01 Apr 2000 22:50:16 +0800
From:   Tan Pong Heng <pongheng@starnet.gov.sg>
X-Mailer: Mozilla 4.7 [en] (X11; I; Linux 2.3.99-pre2 i686)
X-Accept-Language: en
MIME-Version: 1.0
To:     linux-xfs@oss.sgi.com
Subject: XFS as Root partition
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing

Hi, I am new to the list. I have just install the linux-XFS and created
a 4GB partition
for XFS. I have some problems that I would like to report.
(BTW - my system is a BP6 with dual celeron 366, 128MB RAM, a 20GB
Maxtor on
  the ATA66 channel.)
1) My first try was to include all options for XFS - which include the
META option.
     This cause a hard hang on one of the CPU. After reading one of the
recent message,
     I turned that off and was able to copy my 4GB / to the XFS - which
originally
    hanged.
2) While the second try seems to work properly - I was not able to boot
the system
    with the XFS root partition. The boot process hanged before init
run. (/boot is
    a small ext2.) Is this a known problem? And, is there a work around?

Other than these, XFS seems to ork - but than again, I did not try out
enough yet -
haven't decided on how best to load it beside using it as /....


From owner-linux-xfs@oss.sgi.com Sat Apr  1 07:04:45 2000
Received:  by oss.sgi.com id <S305266AbQDAPEf>;
	Sat, 1 Apr 2000 07:04:35 -0800
Received: from pneumatic-tube.sgi.com ([204.94.214.22]:29208 "EHLO
        pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP
	id <S305239AbQDAPES>; Sat, 1 Apr 2000 07:04:18 -0800
Received: from ledzep.cray.com (ledzep.cray.com [137.38.226.97]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id HAA08159
	for <linux-xfs@oss.sgi.com>; Sat, 1 Apr 2000 07:08:00 -0800 (PST)
	mail_from (mostek@sgi.com)
Received: from ironwood-e185.americas.sgi.com (ironwood.cray.com [128.162.185.212]) by ledzep.cray.com (SGI-SGI-8.9.3/craymail-smart-nospam1.0) with ESMTP id JAA52652; Sat, 1 Apr 2000 09:03:01 -0600 (CST)
Received: from fsgi344.americas.sgi.com (fsgi344.americas.sgi.com [128.162.184.15]) by ironwood-e185.americas.sgi.com (8.8.4/SGI-ironwood-e1.4) with ESMTP id JAA28600; Sat, 1 Apr 2000 09:02:54 -0600 (CST)
From:   Jim Mostek <mostek@sgi.com>
Received: by fsgi344.americas.sgi.com (980427.SGI.8.8.8/SGI-client.1.6) id JAA30143; Sat, 1 Apr 2000 09:03:00 -0600 (CST)
Message-Id: <200004011503.JAA30143@fsgi344.americas.sgi.com>
Subject: Re: XFS as Root partition
To:     pongheng@starnet.gov.sg (Tan Pong Heng)
Date:   Sat, 1 Apr 2000 09:02:59 -0600 (CST)
Cc:     linux-xfs@oss.sgi.com
In-Reply-To: <38E60CA8.1510A72D@starnet.gov.sg> from "Tan Pong Heng" at Apr 01, 2000 10:50:16 PM
X-Mailer: ELM [version 2.5 PL2]
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing


Congratulations!

You are the first one to try to actually run at all with XFS as the root
partitition. I'm guessing that you set-up the root and
then tried to reboot with a different kernel pointing at
the XFS root. Right? 
See our work items list in oss.sgi.com/project/xfs/todos.html  

Have you tried XFS as /usr? This would be a good first step.

Thanks,

Jim

>
>Hi, I am new to the list. I have just install the linux-XFS and created
>a 4GB partition
>for XFS. I have some problems that I would like to report.
>(BTW - my system is a BP6 with dual celeron 366, 128MB RAM, a 20GB
>Maxtor on
>  the ATA66 channel.)
>1) My first try was to include all options for XFS - which include the
>META option.
>     This cause a hard hang on one of the CPU. After reading one of the
>recent message,
>     I turned that off and was able to copy my 4GB / to the XFS - which
>originally
>    hanged.
>2) While the second try seems to work properly - I was not able to boot
>the system
>    with the XFS root partition. The boot process hanged before init
>run. (/boot is
>    a small ext2.) Is this a known problem? And, is there a work around?
>
>Other than these, XFS seems to ork - but than again, I did not try out
>enough yet -
>haven't decided on how best to load it beside using it as /....
>


From owner-linux-xfs@oss.sgi.com Sat Apr  1 07:07:45 2000
Received:  by oss.sgi.com id <S305267AbQDAPHf>;
	Sat, 1 Apr 2000 07:07:35 -0800
Received: from pneumatic-tube.sgi.com ([204.94.214.22]:29720 "EHLO
        pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP
	id <S305239AbQDAPHT>; Sat, 1 Apr 2000 07:07:19 -0800
Received: from ledzep.cray.com (ledzep.cray.com [137.38.226.97]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id HAA03555
	for <linux-xfs@oss.sgi.com>; Sat, 1 Apr 2000 07:11:01 -0800 (PST)
	mail_from (lord@sgi.com)
Received: from ironwood-e185.americas.sgi.com (ironwood.cray.com [128.162.185.212]) by ledzep.cray.com (SGI-SGI-8.9.3/craymail-smart-nospam1.0) with ESMTP id JAA59060; Sat, 1 Apr 2000 09:06:02 -0600 (CST)
Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.184.86]) by ironwood-e185.americas.sgi.com (8.8.4/SGI-ironwood-e1.4) with ESMTP id JAA28648; Sat, 1 Apr 2000 09:05:55 -0600 (CST)
From:   Steve Lord <lord@sgi.com>
Received: from jen.americas.sgi.com by jen.americas.sgi.com (8.9.3/SGI-client.1.6) via ESMTP id JAA15687; Sat, 1 Apr 2000 09:05:50 -0600
Message-Id: <200004011505.JAA15687@jen.americas.sgi.com>
To:     Tan Pong Heng <pongheng@starnet.gov.sg>
cc:     linux-xfs@oss.sgi.com
Subject: Re: XFS as Root partition 
In-reply-to: Your message of "Sat, 01 Apr 2000 22:50:16 +0800
Date:   Sat, 01 Apr 2000 09:05:50 -0600
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing


Hi,

Root partition support is not there yet, and XFS is not really stable
enough to be a root (or /usr) filesystem yet.

Thanks for trying though!

Steve Lord

> Hi, I am new to the list. I have just install the linux-XFS and created
> a 4GB partition
> for XFS. I have some problems that I would like to report.
> (BTW - my system is a BP6 with dual celeron 366, 128MB RAM, a 20GB
> Maxtor on
>   the ATA66 channel.)
> 1) My first try was to include all options for XFS - which include the
> META option.
>      This cause a hard hang on one of the CPU. After reading one of the
> recent message,
>      I turned that off and was able to copy my 4GB / to the XFS - which
> originally
>     hanged.
> 2) While the second try seems to work properly - I was not able to boot
> the system
>     with the XFS root partition. The boot process hanged before init
> run. (/boot is
>     a small ext2.) Is this a known problem? And, is there a work around?
> 
> Other than these, XFS seems to ork - but than again, I did not try out
> enough yet -
> haven't decided on how best to load it beside using it as /....

From owner-linux-xfs@oss.sgi.com Sat Apr  1 07:25:25 2000
Received:  by oss.sgi.com id <S305268AbQDAPZQ>;
	Sat, 1 Apr 2000 07:25:16 -0800
Received: from timbuk-fddi.cray.com ([128.162.8.102]:51371 "EHLO
        timbuk.cray.com") by oss.sgi.com with ESMTP id <S305239AbQDAPZH>;
	Sat, 1 Apr 2000 07:25:07 -0800
Received: from clink.americas.sgi.com (clink.cray.com [128.162.84.70]) by timbuk.cray.com (8.8.8/CRI-gate-news-1.3) with ESMTP id JAA15393; Sat, 1 Apr 2000 09:25:04 -0600 (CST)
Received: (from lord@localhost) by clink.americas.sgi.com (980427.SGI.8.8.8/CRI-news-1.3) id JAA90448; Sat, 1 Apr 2000 09:25:06 -0600 (CST)
Date:   Sat, 1 Apr 2000 09:25:06 -0600 (CST)
From:   Steve Lord <lord@sgi.com>
Message-Id: <200004011525.JAA90448@clink.americas.sgi.com>
To:     slinx-xfs@engr.sgi.com, linux-xfs@oss.sgi.com
Subject: TAKE - fix xfs ENOSPC handling and a create bug
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing

Should make XFS behave when the disk gets full. Also fix a
brown paper bag bug in create.

Modid:  2.3.99pre2-xfs:slinx:56258a
Date:  Sat Apr  1 07:24:04 PST 2000
Workarea:  clink.americas.sgi.com:/data/clink/io/lord/slinx-xfs-2.3.99pre2

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

linux/fs/page_buf.c - 1.76
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/linux/fs/page_buf.c.diff?r1=text&tr1=1.76&r2=text&tr2=1.75&f=h
	- Detect error return from space allocation call and return to
	  caller.

linux/fs/xfs/linux/xfs_iops.c - 1.41
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/linux/fs/xfs/linux/xfs_iops.c.diff?r1=text&tr1=1.41&r2=text&tr2=1.40&f=h
	- Fix create failure path to actually return an error, also
	  check for error in revalidate call for a shutdown filesystem.

linux/fs/xfs/linux/xfs_lrw.c - 1.30
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/linux/fs/xfs/linux/xfs_lrw.c.diff?r1=text&tr1=1.30&r2=text&tr2=1.29&f=h
	- On ENOSPC return from bmap call attempt different heuristics to
	  make some space appear, and then return the error.


From owner-linux-xfs@oss.sgi.com Sat Apr  1 09:10:56 2000
Received:  by oss.sgi.com id <S305166AbQDARKq>;
	Sat, 1 Apr 2000 09:10:46 -0800
Received: from timbuk-fddi.cray.com ([128.162.8.102]:22957 "EHLO
        timbuk.cray.com") by oss.sgi.com with ESMTP id <S305164AbQDARK2>;
	Sat, 1 Apr 2000 09:10:28 -0800
Received: from clink.americas.sgi.com (clink.cray.com [128.162.84.70]) by timbuk.cray.com (8.8.8/CRI-gate-news-1.3) with ESMTP id LAA16008 for <linux-xfs@oss.sgi.com>; Sat, 1 Apr 2000 11:10:25 -0600 (CST)
Received: (from lord@localhost) by clink.americas.sgi.com (980427.SGI.8.8.8/CRI-news-1.3) id LAA43229 for linux-xfs@oss.sgi.com; Sat, 1 Apr 2000 11:10:26 -0600 (CST)
Date:   Sat, 1 Apr 2000 11:10:26 -0600 (CST)
From:   Steve Lord <lord@sgi.com>
Message-Id: <200004011710.LAA43229@clink.americas.sgi.com>
To:     linux-xfs@oss.sgi.com
Subject: TAKE - fix stat system call block count info
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing

Modid:  2.3.99pre2-xfs:slinx:56259a
Date:  Sat Apr  1 09:09:55 PST 2000
Workarea:  clink.americas.sgi.com:/data/clink/io/lord/slinx-xfs-2.3.99pre2

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

linux/fs/xfs/linux/xfs_iops.c - 1.42
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/linux/fs/xfs/linux/xfs_iops.c.diff?r1=text&tr1=1.42&r2=text&tr2=1.41&f=h
	- Fix stat output to report correct block count (also fixes ls -s)


From owner-linux-xfs@oss.sgi.com Sat Apr  1 09:39:36 2000
Received:  by oss.sgi.com id <S305272AbQDARj1>;
	Sat, 1 Apr 2000 09:39:27 -0800
Received: from Cantor.suse.de ([194.112.123.193]:1032 "HELO Cantor.suse.de")
	by oss.sgi.com with SMTP id <S305164AbQDARjR>;
	Sat, 1 Apr 2000 09:39:17 -0800
Received: from Hermes.suse.de (Hermes.suse.de [194.112.123.136])
	by Cantor.suse.de (Postfix) with ESMTP
	id CE7F91E130; Sat,  1 Apr 2000 19:39:15 +0200 (MEST)
Received: from gruyere.muc.suse.de (gruyere.muc.suse.de [10.23.1.2])
	by Hermes.suse.de (Postfix) with ESMTP
	id 3EFC110A038; Sat,  1 Apr 2000 19:39:15 +0200 (MEST)
Received: by gruyere.muc.suse.de (Postfix, from userid 14446)
	id 87BFA2F36B; Sat,  1 Apr 2000 19:39:14 +0200 (MEST)
Date:   Sat, 1 Apr 2000 19:39:14 +0200
From:   "Andi Kleen" <ak@suse.de>
To:     Steve Lord <lord@sgi.com>
Cc:     Bernd Markgraf <markgraf@prinz-atm.CS.Uni-Magdeburg.De>,
        Andi Kleen <ak@suse.de>, linux-xfs@oss.sgi.com
Subject: Re: copying to xfs causes cp to go to sleep
Message-ID: <20000401193914.A425@gruyere.muc.suse.de>
References: <200004011417.IAA14794@jen.americas.sgi.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 1.0i
In-Reply-To: <200004011417.IAA14794@jen.americas.sgi.com>; from lord@sgi.com on Sat, Apr 01, 2000 at 08:17:10AM -0600
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing

On Sat, Apr 01, 2000 at 08:17:10AM -0600, Steve Lord wrote:
> 
> OK for the cp blowing up try this patch against revision 1.40 of
> xfs_iops.c (which should be the latest in the CVS tree). A failure
> in create was returning 0 to the calling code.
> 
> I suspect the cp will still hang - I am working on the out of space
> code path (which I still think could be triggered here), yet another
> change will be required to deal with that one.

Thanks, that patch makes the rfc copy work.

With the newly updated version the kswapd CPU waste seems to be also
gone.

-Andi


From owner-linux-xfs@oss.sgi.com Sat Apr  1 09:50:37 2000
Received:  by oss.sgi.com id <S305274AbQDARu1>;
	Sat, 1 Apr 2000 09:50:27 -0800
Received: from ribbit.CS.Berkeley.EDU ([128.32.131.152]:60809 "EHLO
        ribbit.CS.Berkeley.EDU") by oss.sgi.com with ESMTP
	id <S305164AbQDARuO>; Sat, 1 Apr 2000 09:50:14 -0800
Received: from localhost (kmacy@localhost)
	by ribbit.CS.Berkeley.EDU (8.9.3/8.9.3) with ESMTP id JAA03125;
	Sat, 1 Apr 2000 09:46:19 -0800 (PST)
X-Authentication-Warning: ribbit.CS.Berkeley.EDU: kmacy owned process doing -bs
Date:   Sat, 1 Apr 2000 09:46:19 -0800 (PST)
From:   Kip Macy <kmacy@CS.Berkeley.EDU>
To:     Steve Lord <lord@sgi.com>
cc:     Tan Pong Heng <pongheng@starnet.gov.sg>, linux-xfs@oss.sgi.com
Subject: Re: XFS as Root partition 
In-Reply-To: <200004011505.JAA15687@jen.americas.sgi.com>
Message-ID: <Pine.SOL.4.10.10004010944200.3098-100000@ribbit.CS.Berkeley.EDU>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing

This may not apply to you, but in addition to the problems with XFS as /, there
are know problems with 2.3.x kernels on Abit motherboards with Maxtor drives.
Have you tried running a 2.3.x kernel prior to this without XFS in it?

				-Kip




------------------------------------------------------------------------
Kip Macy                               kmacy@cs.berkeley.edu
University of California, Berkeley     
------------------------------------------------------------------------


On Sat, 1 Apr 2000, Steve Lord wrote:

> 
> Hi,
> 
> Root partition support is not there yet, and XFS is not really stable
> enough to be a root (or /usr) filesystem yet.
> 
> Thanks for trying though!
> 
> Steve Lord
> 
> > Hi, I am new to the list. I have just install the linux-XFS and created
> > a 4GB partition
> > for XFS. I have some problems that I would like to report.
> > (BTW - my system is a BP6 with dual celeron 366, 128MB RAM, a 20GB
> > Maxtor on
> >   the ATA66 channel.)
> > 1) My first try was to include all options for XFS - which include the
> > META option.
> >      This cause a hard hang on one of the CPU. After reading one of the
> > recent message,
> >      I turned that off and was able to copy my 4GB / to the XFS - which
> > originally
> >     hanged.
> > 2) While the second try seems to work properly - I was not able to boot
> > the system
> >     with the XFS root partition. The boot process hanged before init
> > run. (/boot is
> >     a small ext2.) Is this a known problem? And, is there a work around?
> > 
> > Other than these, XFS seems to ork - but than again, I did not try out
> > enough yet -
> > haven't decided on how best to load it beside using it as /....
> 


From owner-linux-xfs@oss.sgi.com Sat Apr  1 12:25:29 2000
Received:  by oss.sgi.com id <S305275AbQDAUZU>;
	Sat, 1 Apr 2000 12:25:20 -0800
Received: from D7B053.DIALUP.CORNELL.EDU ([128.253.157.53]:34567 "EHLO truth")
	by oss.sgi.com with ESMTP id <S305164AbQDAUZC>;
	Sat, 1 Apr 2000 12:25:02 -0800
Received: from limhk by truth with local (Exim 3.12 #1 (Debian))
	id 12bUS4-0001tL-00
	for <linux-xfs@oss.sgi.com>; Sat, 01 Apr 2000 15:25:00 -0500
Date:   Sat, 1 Apr 2000 15:25:00 -0500
From:   Hway Kiong Lim <limhk@limhk.dyn.cheapnet.net>
To:     linux-xfs@oss.sgi.com
Subject: Missing Files
Message-ID: <20000401152500.A7268@limhk.dyn.cheapnet.net>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
User-Agent: Mutt/1.0i
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing

Hi,

	Using the following test.sh script :

#!/bin/sh

counter=1000
while [ $counter -le 2000 ]
do

  echo "File number $counter" >> file$counter
  counter=$(( $counter + 1))
done

I try to create 1000 (1001 to be precise) files in an xfs mounted directory. 
This is waht happens:

beauty:/mnt/test# sh /tmp/test.sh
beauty:/mnt/test# ls | wc
    995     995    8955
beauty:/mnt/test# rm *
beauty:/mnt/test# ls
file1144  file1291  file1438  file1585  file1732  file1879
beauty:/mnt/test# ls

Furthermore, these files are those that are missing from the original list.
Any idea what is happening here? 

By the way, the version I am running is checkout of the CVS source around
1130 US EST.

Thanks for bring XFS to Linux
Hway Kiong

PS: Compiling XFS into the kernal makes it too large to boot :(

From owner-linux-xfs@oss.sgi.com Sat Apr  1 12:49:29 2000
Received:  by oss.sgi.com id <S305277AbQDAUtT>;
	Sat, 1 Apr 2000 12:49:19 -0800
Received: from ribbit.CS.Berkeley.EDU ([128.32.131.152]:62091 "EHLO
        ribbit.CS.Berkeley.EDU") by oss.sgi.com with ESMTP
	id <S305164AbQDAUtE>; Sat, 1 Apr 2000 12:49:04 -0800
Received: from localhost (kmacy@localhost)
	by ribbit.CS.Berkeley.EDU (8.9.3/8.9.3) with ESMTP id MAA03722;
	Sat, 1 Apr 2000 12:48:51 -0800 (PST)
X-Authentication-Warning: ribbit.CS.Berkeley.EDU: kmacy owned process doing -bs
Date:   Sat, 1 Apr 2000 12:48:51 -0800 (PST)
From:   Kip Macy <kmacy@CS.Berkeley.EDU>
To:     Hway Kiong Lim <limhk@limhk.dyn.cheapnet.net>
cc:     linux-xfs@oss.sgi.com
Subject: too large to boot was Re: Missing Files
In-Reply-To: <20000401152500.A7268@limhk.dyn.cheapnet.net>
Message-ID: <Pine.SOL.4.10.10004011247420.3098-100000@ribbit.CS.Berkeley.EDU>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing


> PS: Compiling XFS into the kernal makes it too large to boot :(
> 

try 
> gmake bzlilo

it uses bzip instead of gzip for compressing the kernel image


From owner-linux-xfs@oss.sgi.com Sat Apr  1 14:02:09 2000
Received:  by oss.sgi.com id <S305276AbQDAWCA>;
	Sat, 1 Apr 2000 14:02:00 -0800
Received: from deliverator.sgi.com ([204.94.214.10]:8727 "EHLO
        deliverator.sgi.com") by oss.sgi.com with ESMTP id <S305164AbQDAWBm>;
	Sat, 1 Apr 2000 14:01:42 -0800
Received: from ledzep.cray.com (ledzep.cray.com [137.38.226.97]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id NAA20642
	for <linux-xfs@oss.sgi.com>; Sat, 1 Apr 2000 13:57:00 -0800 (PST)
	mail_from (jtk@sgi.com)
Received: from ironwood-e185.americas.sgi.com (ironwood.cray.com [128.162.185.212]) by ledzep.cray.com (SGI-SGI-8.9.3/craymail-smart-nospam1.0) with ESMTP id PAA77750; Sat, 1 Apr 2000 15:59:08 -0600 (CST)
Received: from tiki.americas.sgi.com (tiki.americas.sgi.com [128.162.195.11]) by ironwood-e185.americas.sgi.com (8.8.4/SGI-ironwood-e1.4) with ESMTP id PAA04605; Sat, 1 Apr 2000 15:59:01 -0600 (CST)
From:   Ted Kline <jtk@sgi.com>
Received: by tiki.americas.sgi.com (980427.SGI.8.8.8/SGI-client.1.6) id PAA62435; Sat, 1 Apr 2000 15:59:07 -0600 (CST)
Message-Id: <200004012159.PAA62435@tiki.americas.sgi.com>
Subject: Re: Missing Files
To:     limhk@limhk.dyn.cheapnet.net (Hway Kiong Lim)
Date:   Sat, 1 Apr 2000 15:59:06 -0600 (CST)
Cc:     linux-xfs@oss.sgi.com
In-Reply-To: <20000401152500.A7268@limhk.dyn.cheapnet.net> from "Hway Kiong Lim" at Apr 01, 2000 03:25:00 PM
X-Mailer: ELM [version 2.5 PL2]
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing

> 
> Hi,
> 
> 	Using the following test.sh script :
> 
> #!/bin/sh
> 
> counter=1000
> while [ $counter -le 2000 ]
> do
> 
>   echo "File number $counter" >> file$counter
>   counter=$(( $counter + 1))
> done
> 
> I try to create 1000 (1001 to be precise) files in an xfs mounted directory. 
> This is waht happens:
> 
> beauty:/mnt/test# sh /tmp/test.sh
> beauty:/mnt/test# ls | wc
>     995     995    8955
> beauty:/mnt/test# rm *
> beauty:/mnt/test# ls
> file1144  file1291  file1438  file1585  file1732  file1879
> beauty:/mnt/test# ls
> 

This looks very much like a bug we found in glibc in the getdents syscall
interface routine having to do with d_off values in the dirent structure
using bit 2^31, and getdents64 not using lseek64..  Originally it showed
up when running a 2.3 kernel as a client to an NFS server exporting
an XFS filesystem.  I was thinking we'd defaulted to dir2 format, and
that should've kept us from seeing this problem, looks like more
digging is required..

> Furthermore, these files are those that are missing from the original list.
> Any idea what is happening here? 
> 
> By the way, the version I am running is checkout of the CVS source around
> 1130 US EST.
> 
> Thanks for bring XFS to Linux
> Hway Kiong
> 
> PS: Compiling XFS into the kernal makes it too large to boot :(
> 

	-Ted Kline

From owner-linux-xfs@oss.sgi.com Sat Apr  1 16:12:00 2000
Received:  by oss.sgi.com id <S305171AbQDBALu>;
	Sat, 1 Apr 2000 16:11:50 -0800
Received: from rising.starnet.gov.sg ([203.116.82.211]:62340 "EHLO
        rising.starnet.gov.sg") by oss.sgi.com with ESMTP
	id <S305164AbQDBALf>; Sat, 1 Apr 2000 16:11:35 -0800
Received: from aries (dyn1-166cable.bp1.singa.pore.net [202.169.229.166])
	by rising.starnet.gov.sg (8.9.1/8.9.1) with SMTP id IAA18779;
	Sun, 2 Apr 2000 08:08:14 +0800 (SGT)
Message-ID: <002701bf9c37$7eb5ef10$a6e5a9ca@aries>
From:   "Tan Pong Heng" <pongheng@starnet.gov.sg>
To:     "Kip Macy" <kmacy@CS.Berkeley.EDU>, "Steve Lord" <lord@sgi.com>
Cc:     <linux-xfs@oss.sgi.com>
References: <Pine.SOL.4.10.10004010944200.3098-100000@ribbit.CS.Berkeley.EDU>
Subject: Re: XFS as Root partition 
Date:   Sun, 2 Apr 2000 08:07:53 +0800
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.00.2919.6700
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing

The problem that I have reported should not be Abit specific. Abit does
has a lot of problems in stability - but not in the reported way. Most of
the problem seems to be either random hang (which I seldom encounter)
or hamless error messages on lost sync in SMP (the hardware will retry
and succeed). Both of the reported problems are reproducible.

The last kernel that I used extensively was 2.3.51...

If there is anything else that I noticed about XFS was it's size. Compared
to the last kernel that I used, the inclusion of XFS has increase the kernel
size by
200K after bzip compression - from 600K+ to 800K+ - a sizable increase...

----- Original Message -----
From: "Kip Macy" <kmacy@CS.Berkeley.EDU>
To: "Steve Lord" <lord@sgi.com>
Cc: "Tan Pong Heng" <pongheng@starnet.gov.sg>; <linux-xfs@oss.sgi.com>
Sent: Sunday, April 02, 2000 1:46 AM
Subject: Re: XFS as Root partition


> This may not apply to you, but in addition to the problems with XFS as /,
there
> are know problems with 2.3.x kernels on Abit motherboards with Maxtor
drives.
> Have you tried running a 2.3.x kernel prior to this without XFS in it?
>
> -Kip
>
>
>
>
> ------------------------------------------------------------------------
> Kip Macy                               kmacy@cs.berkeley.edu
> University of California, Berkeley
> ------------------------------------------------------------------------
>
>
> On Sat, 1 Apr 2000, Steve Lord wrote:
>
> >
> > Hi,
> >
> > Root partition support is not there yet, and XFS is not really stable
> > enough to be a root (or /usr) filesystem yet.
> >
> > Thanks for trying though!
> >
> > Steve Lord
> >
> > > Hi, I am new to the list. I have just install the linux-XFS and
created
> > > a 4GB partition
> > > for XFS. I have some problems that I would like to report.
> > > (BTW - my system is a BP6 with dual celeron 366, 128MB RAM, a 20GB
> > > Maxtor on
> > >   the ATA66 channel.)
> > > 1) My first try was to include all options for XFS - which include the
> > > META option.
> > >      This cause a hard hang on one of the CPU. After reading one of
the
> > > recent message,
> > >      I turned that off and was able to copy my 4GB / to the XFS -
which
> > > originally
> > >     hanged.
> > > 2) While the second try seems to work properly - I was not able to
boot
> > > the system
> > >     with the XFS root partition. The boot process hanged before init
> > > run. (/boot is
> > >     a small ext2.) Is this a known problem? And, is there a work
around?
> > >
> > > Other than these, XFS seems to ork - but than again, I did not try out
> > > enough yet -
> > > haven't decided on how best to load it beside using it as /....
> >
>


From owner-linux-xfs@oss.sgi.com Sat Apr  1 16:18:11 2000
Received:  by oss.sgi.com id <S305174AbQDBASA>;
	Sat, 1 Apr 2000 16:18:00 -0800
Received: from rising.starnet.gov.sg ([203.116.82.211]:64644 "EHLO
        rising.starnet.gov.sg") by oss.sgi.com with ESMTP
	id <S305164AbQDBARx>; Sat, 1 Apr 2000 16:17:53 -0800
Received: from aries (dyn1-166cable.bp1.singa.pore.net [202.169.229.166])
	by rising.starnet.gov.sg (8.9.1/8.9.1) with SMTP id IAA18830;
	Sun, 2 Apr 2000 08:14:38 +0800 (SGT)
Message-ID: <004301bf9c38$62536f40$a6e5a9ca@aries>
From:   "Tan Pong Heng" <pongheng@starnet.gov.sg>
To:     "Jim Mostek" <mostek@sgi.com>
Cc:     <linux-xfs@oss.sgi.com>
References: <200004011503.JAA30143@fsgi344.americas.sgi.com>
Subject: Re: XFS as Root partition
Date:   Sun, 2 Apr 2000 08:14:16 +0800
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.00.2919.6700
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing

Well, it seems to be a reasonable thing to do at first - I could switch
between the old and new setting easy during boot time by either a boot
time parameter or lilo choice. The rest would require editing fstab to
switch...

I did noticed another thing though - there is a xfs process running after
booting - and that is the cause of xfs can not be run as /. Since that
process
may not be started in time for init to be loaded.....

I will try to work out a scheme to test out xfs properly later...

----- Original Message -----
From: "Jim Mostek" <mostek@sgi.com>
To: "Tan Pong Heng" <pongheng@starnet.gov.sg>
Cc: <linux-xfs@oss.sgi.com>
Sent: Saturday, April 01, 2000 11:02 PM
Subject: Re: XFS as Root partition


>
> Congratulations!
>
> You are the first one to try to actually run at all with XFS as the root
> partitition. I'm guessing that you set-up the root and
> then tried to reboot with a different kernel pointing at
> the XFS root. Right?
> See our work items list in oss.sgi.com/project/xfs/todos.html
>
> Have you tried XFS as /usr? This would be a good first step.
>
> Thanks,
>
> Jim
>
> >
> >Hi, I am new to the list. I have just install the linux-XFS and created
> >a 4GB partition
> >for XFS. I have some problems that I would like to report.
> >(BTW - my system is a BP6 with dual celeron 366, 128MB RAM, a 20GB
> >Maxtor on
> >  the ATA66 channel.)
> >1) My first try was to include all options for XFS - which include the
> >META option.
> >     This cause a hard hang on one of the CPU. After reading one of the
> >recent message,
> >     I turned that off and was able to copy my 4GB / to the XFS - which
> >originally
> >    hanged.
> >2) While the second try seems to work properly - I was not able to boot
> >the system
> >    with the XFS root partition. The boot process hanged before init
> >run. (/boot is
> >    a small ext2.) Is this a known problem? And, is there a work around?
> >
> >Other than these, XFS seems to ork - but than again, I did not try out
> >enough yet -
> >haven't decided on how best to load it beside using it as /....
> >
>


From owner-linux-xfs@oss.sgi.com Sat Apr  1 18:25:41 2000
Received:  by oss.sgi.com id <S305179AbQDBCZb>;
	Sat, 1 Apr 2000 18:25:31 -0800
Received: from rising.starnet.gov.sg ([203.116.82.211]:39045 "EHLO
        rising.starnet.gov.sg") by oss.sgi.com with ESMTP
	id <S305164AbQDBCZR>; Sat, 1 Apr 2000 18:25:17 -0800
Received: from starnet.gov.sg (dyn1-166cable.bp1.singa.pore.net [202.169.229.166])
	by rising.starnet.gov.sg (8.9.1/8.9.1) with ESMTP id KAA19558
	for <linux-xfs@oss.sgi.com>; Sun, 2 Apr 2000 10:25:14 +0800 (SGT)
Message-ID: <38E6AF73.7ABF49D6@starnet.gov.sg>
Date:   Sun, 02 Apr 2000 10:24:51 +0800
From:   Tan Pong Heng <pongheng@starnet.gov.sg>
X-Mailer: Mozilla 4.7 [en] (X11; I; Linux 2.3.99-pre2 i686)
X-Accept-Language: en
MIME-Version: 1.0
To:     linux-xfs@oss.sgi.com
Subject: RE: XFS as Root
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing

OK, I tried the alternative - I now have XFS as /usr instead.
Everything seems to be fine. It seems that the only problem with
using XFS as root is to get the right process going before init start.
(Or so I am guessing....)

There is one catch though - I am not having /usr/src/linux on this
partition yet - as that is on my home directory for CVS update
at the moment - that would be /home.

Anything specific that you would like me to test?


From owner-linux-xfs@oss.sgi.com Sun Apr  2 01:11:42 2000
Received:  by oss.sgi.com id <S305193AbQDBJLc>;
	Sun, 2 Apr 2000 01:11:32 -0800
Received: from dte.vsnl.net.in ([202.54.8.4]:12172 "EHLO dte.vsnl.net.in")
	by oss.sgi.com with ESMTP id <S305164AbQDBJLM>;
	Sun, 2 Apr 2000 01:11:12 -0800
Received: from higher (IDENT:root@ppp77-206.pppcal.vsnl.net.in [202.54.77.206])
	by dte.vsnl.net.in (8.9.1/8.9.1) with SMTP id OAA12971;
	Sun, 2 Apr 2000 14:39:23 -0500 (GMT)
From:   Abhas Abhinav <abhas@deeproot.net>
Reply-To: abhas@deeproot.net
To:     "Tan Pong Heng" <pongheng@starnet.gov.sg>
Subject: Re: XFS as Root partition
Date:   Sun, 2 Apr 2000 14:41:26 +0530
X-Mailer: KMail [version 1.0.28]
Content-Type: text/plain
References: <200004011503.JAA30143@fsgi344.americas.sgi.com> <004301bf9c38$62536f40$a6e5a9ca@aries>
In-Reply-To: <004301bf9c38$62536f40$a6e5a9ca@aries>
Cc:     linux-xfs@oss.sgi.com
MIME-Version: 1.0
Message-Id: <00040214440000.01266@higher>
Content-Transfer-Encoding: 8bit
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing


> I did noticed another thing though - there is a xfs process running after
> booting - and that is the cause of xfs can not be run as /. Since that
> process
> may not be started in time for init to be loaded.....

That is probably the X Font Server (xfs) that ships with RedHat 6.1/GNOME and
is needed for rendering fonts for X.... 

Abhas.

From owner-linux-xfs@oss.sgi.com Sun Apr  2 07:27:05 2000
Received:  by oss.sgi.com id <S305198AbQDBO0z>;
	Sun, 2 Apr 2000 07:26:55 -0700
Received: from noose.gt.owl.de ([62.52.19.4]:16647 "HELO noose.gt.owl.de")
	by oss.sgi.com with SMTP id <S305164AbQDBO0k>;
	Sun, 2 Apr 2000 07:26:40 -0700
Received: by noose.gt.owl.de (Postfix, from userid 10)
	id C4B767DD; Sun,  2 Apr 2000 16:26:24 +0200 (CEST)
Received: by paradigm.rfc822.org (Postfix, from userid 1000)
	id 887A58FC3; Sun,  2 Apr 2000 16:15:57 +0200 (CEST)
Date:   Sun, 2 Apr 2000 16:15:57 +0200
From:   Florian Lohoff <flo@rfc822.org>
To:     Kip Macy <kmacy@CS.Berkeley.EDU>
Cc:     Hway Kiong Lim <limhk@limhk.dyn.cheapnet.net>,
        linux-xfs@oss.sgi.com
Subject: Re: too large to boot was Re: Missing Files
Message-ID: <20000402161557.A11056@paradigm.rfc822.org>
References: <20000401152500.A7268@limhk.dyn.cheapnet.net> <Pine.SOL.4.10.10004011247420.3098-100000@ribbit.CS.Berkeley.EDU>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 0.95.3i
In-Reply-To: <Pine.SOL.4.10.10004011247420.3098-100000@ribbit.CS.Berkeley.EDU>; from Kip Macy on Sat, Apr 01, 2000 at 12:48:51PM -0800
Organization: rfc822 - pure communication
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing

On Sat, Apr 01, 2000 at 12:48:51PM -0800, Kip Macy wrote:
> > PS: Compiling XFS into the kernal makes it too large to boot :(
> > gmake bzlilo
> 
> it uses bzip instead of gzip for compressing the kernel image

*Boep* Wrong - It uses the same compression algorythm. It stands
for "Big" -> Big zImage. Only the load address changes afaik.

Flo
-- 
Florian Lohoff		flo@rfc822.org		      	+49-5241-470566
"Technology is a constant battle between manufacturers producing bigger and
more idiot-proof systems and nature producing bigger and better idiots."


From owner-linux-xfs@oss.sgi.com Sun Apr  2 11:53:06 2000
Received:  by oss.sgi.com id <S305202AbQDBSw4>;
	Sun, 2 Apr 2000 11:52:56 -0700
Received: from [195.43.220.10] ([195.43.220.10]:35082 "HELO
        mtc-linux1.modular-telecom.se") by oss.sgi.com with SMTP
	id <S305194AbQDBSwq>; Sun, 2 Apr 2000 11:52:46 -0700
Received: (qmail 7444 invoked from network); 2 Apr 2000 18:50:18 -0000
Received: from goofy.air2.net (HELO air2.net) (@195.43.220.5)
  by mtc-linux1.air2.net with SMTP; 2 Apr 2000 18:50:18 -0000
Message-ID: <38E796DC.BB84F640@air2.net>
Date:   Sun, 02 Apr 2000 20:52:12 +0200
From:   Fredrik =?iso-8859-1?Q?Win=E4s?= <fredrik@air2.net>
Organization: Air2Net
X-Mailer: Mozilla 4.7 [en] (WinNT; I)
X-Accept-Language: sv,en
MIME-Version: 1.0
To:     linux-xfs@oss.sgi.com
Subject: XFS Error
Content-Type: multipart/mixed;
 boundary="------------F5AB455E832AE4A4F4DFC289"
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing

This is a multi-part message in MIME format.
--------------F5AB455E832AE4A4F4DFC289
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Hi


I'm running XFS with Linux 2.3.99-pre2 and i got some problems when 
i tried to copy a big file (300Mb) to an XFS disc (150MB), instead of 
stoping the copy proccess and telling me that the disc was full, 
it printed out 

 --- SNIP ---

Apr  2 21:39:57 snoop kernel: xfOR 28
Apr  2 21:39:57 snoop kernel: xfs_iomap_write returnOR 28
Apr  2 21:39:57 snoop kernel: xfs_iomap_write returning ERROR 28
Apr  2 21:39:57 snoop last message repeated 105 times

 --- END SNIP ---

 about 200/sec ... 




System info:
Dist:	Debian (potato) x86
CPU:	2x PII 266MHz
Mem:	128MB Non-ECC
HDD:	IBM 18GB SCSI
--------------F5AB455E832AE4A4F4DFC289
Content-Type: text/x-vcard; charset=us-ascii;
 name="fredrik.vcf"
Content-Transfer-Encoding: 7bit
Content-Description: Card for Fredrik Winäs
Content-Disposition: attachment;
 filename="fredrik.vcf"

begin:vcard 
n:Winäs;Fredrik
tel;cell:+46 704 936354
tel;work:+46 31 704 30 00
x-mozilla-html:FALSE
url:http://www.air2.net
org:Air2Net AB
adr:;;Första Långgatan 20;Göteborg;;;Sweden
version:2.1
email;internet:fredrik@ait2.net
title:Tech admin
fn:Fredrik Winäs
end:vcard

--------------F5AB455E832AE4A4F4DFC289--


From owner-linux-xfs@oss.sgi.com Sun Apr  2 12:56:47 2000
Received:  by oss.sgi.com id <S305194AbQDBT4h>;
	Sun, 2 Apr 2000 12:56:37 -0700
Received: from ribbit.CS.Berkeley.EDU ([128.32.131.152]:38555 "EHLO
        ribbit.CS.Berkeley.EDU") by oss.sgi.com with ESMTP
	id <S305164AbQDBT4c>; Sun, 2 Apr 2000 12:56:32 -0700
Received: from localhost (kmacy@localhost)
	by ribbit.CS.Berkeley.EDU (8.9.3/8.9.3) with ESMTP id MAA14151
	for <linux-xfs@oss.sgi.com>; Sun, 2 Apr 2000 12:56:32 -0700 (PDT)
X-Authentication-Warning: ribbit.CS.Berkeley.EDU: kmacy owned process doing -bs
Date:   Sun, 2 Apr 2000 12:56:32 -0700 (PDT)
From:   Kip Macy <kmacy@CS.Berkeley.EDU>
To:     linux-xfs@oss.sgi.com
Subject: write ordering on IDE drives
Message-ID: <Pine.SOL.4.10.10004021245210.12562-100000@ribbit.CS.Berkeley.EDU>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing





The "xFS Project Architecture" design document has the following to say
about the requirements made on disk driver by XFS:

Disk drivers are the same as in traditional and current IRIX systems, 
except for ordering constraints needed by the log and volume managers 
and rate guarantees. In particular, it must be possible for the volume 
manager to be certain that a write request has actually been completed, 
not merely cached for later writing. It should also be possible for the 
volume manager to specify that a given write not be reordered - that all
blocks passed to the driver before this block will be written before 
this block is written, and all blocks passed to the driver after this 
block will be written after this block. (If non-ordered writes are not 
available on a particular driver, the volume manager can synthesize 
this behavior by waiting for completion, but this is much less efficient.)


I assume the following still holds true. To my knowledge only IBM's IDE 
drives support those semantics. Does this mean that all log-writes on 
non-IBM IDE drives are synchronous? How does the volume manager know 
whether or not the disk driver supports this behaviour?

Thanks.


					-Kip




------------------------------------------------------------------------
Kip Macy                               kmacy@cs.berkeley.edu
University of California, Berkeley     
------------------------------------------------------------------------



From owner-linux-xfs@oss.sgi.com Sun Apr  2 13:30:57 2000
Received:  by oss.sgi.com id <S305194AbQDBUar>;
	Sun, 2 Apr 2000 13:30:47 -0700
Received: from [195.43.220.10] ([195.43.220.10]:44810 "HELO
        mtc-linux1.modular-telecom.se") by oss.sgi.com with SMTP
	id <S305164AbQDBUab>; Sun, 2 Apr 2000 13:30:31 -0700
Received: (qmail 7648 invoked from network); 2 Apr 2000 20:28:01 -0000
Received: from goofy.air2.net (HELO air2.net) (@195.43.220.5)
  by mtc-linux1.air2.net with SMTP; 2 Apr 2000 20:28:01 -0000
Message-ID: <38E7ADA7.5B0A77DC@air2.net>
Date:   Sun, 02 Apr 2000 22:29:27 +0200
From:   Fredrik =?iso-8859-1?Q?Win=E4s?= <fredrik@air2.net>
Organization: Air2Net
X-Mailer: Mozilla 4.7 [en] (WinNT; I)
X-Accept-Language: sv,en
MIME-Version: 1.0
To:     linux-xfs@oss.sgi.com
Subject: XFS bug ?
Content-Type: multipart/mixed;
 boundary="------------080A2ACBE90EDF62204E358B"
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing

This is a multi-part message in MIME format.
--------------080A2ACBE90EDF62204E358B
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Hi


I was testing XFS on my system and this error occured:

i was running this .. 

tty1 -> "time dd if=/dev/zero of=bigfile1 count=1000000 bs=1024"
tty2 -> "time dd if=/dev/zero of=bigfile2 count=1000000 bs=1024"
tty3 -> "time dd if=/dev/zero of=bigfile3 count=1000000 bs=1024"
tty4 -> "time dd if=/dev/zero of=bigfile4 count=1000000 bs=1024"

while standing in a 5GB XFS disc (/dev/sdb9)

and the i got this in return ...

 --- SNIP ---

NMI Watchdog detected LOCKUP on CPU1, registers:
CPU:    1
EIP     0010:[<c02bdf57>]
EFLAGS: 00000002
eax:  00000000  ebx:  c776904c  ecx:  c2757460  edx:  00000286
esi:  00000000  edi:  c2757460  ebp:  00000286  esp:  c753db34
ds 0018  es:  0018  ss:  0018
Process dd (pid: 773,stackpage=c753d000)
Stack   00000001 c7766ea0 c014591c c5f6b700 c753db68 c2757460 00000010
00000000
        c014006a 00000001 c7766ea0 00000000 00000001 c7769040 c014006a
c2757460
        00000286 c27574b8 c2757460 00000286 c2757460 c2757498 c27574b4
00000000
Call Trace: 
        [<c014591c>]  [<c014006a>]  [<c014006a>]  [<c0140cd0>] 
[<c019ebb1>]  [<c01c9d25>]  [<c01c9c3d>]
        [<c01c7b42>]  [<c01d922f>]  [<c01d9256>]  [<c01d9271>] 
[<c010c331>]  [<c01d8a30>]  [<c01d408f>]  [<c01d8aa4>]
        [<c01d679a>]  [<c010a430>]  [<c01437f2>]  [<c0143ce5>] 
[<c010c664>]  [<c01d7b39>]  [<c01d88f9>]  [<c01d5015>]
        [<c01498fc>]  [<c010a370>]
Code: 75 f9 e9 38 79 e8 ff f6 03 01 f3 90 75 f9 e9 8a 7b e8 ff e8
console shuts up ...

 --- END SNIP ---

Then the computer was dead ... even the electronic CPU switch locked up
:)



System info:

Kernel:		2.3.99-pre2  patched with
03312000linux-2.3.99-pre2-linux-2.3-xfs.patch
Dist:		Debian GNU Linux (Potato)
CPU:		2x Intel PII 266MHz
Mem:		1x 128MB non-ECC
HDD:		/dev/sda = IBM DNES-318350W	(18GB UW 7200rpm)
		/dev/sdb = IBM DDRS-39130D	(9GB  UW 7200rpm)
--------------080A2ACBE90EDF62204E358B
Content-Type: text/x-vcard; charset=us-ascii;
 name="fredrik.vcf"
Content-Transfer-Encoding: 7bit
Content-Description: Card for Fredrik Winäs
Content-Disposition: attachment;
 filename="fredrik.vcf"

begin:vcard 
n:Winäs;Fredrik
tel;cell:+46 704 936354
tel;work:+46 31 704 30 00
x-mozilla-html:FALSE
url:http://www.air2.net
org:Air2Net AB
adr:;;Första Långgatan 20;Göteborg;;;Sweden
version:2.1
email;internet:fredrik@ait2.net
title:Tech admin
fn:Fredrik Winäs
end:vcard

--------------080A2ACBE90EDF62204E358B--


From owner-linux-xfs@oss.sgi.com Mon Apr  3 04:34:42 2000
Received:  by oss.sgi.com id <S305208AbQDCLeW>;
	Mon, 3 Apr 2000 04:34:22 -0700
Received: from rising.starnet.gov.sg ([203.116.82.211]:64667 "EHLO
        rising.starnet.gov.sg") by oss.sgi.com with ESMTP
	id <S305194AbQDCLd5>; Mon, 3 Apr 2000 04:33:57 -0700
Received: from starnet.gov.sg (dyn1-166cable.bp1.singa.pore.net [202.169.229.166])
	by rising.starnet.gov.sg (8.9.1/8.9.1) with ESMTP id TAA17795
	for <linux-xfs@oss.sgi.com>; Mon, 3 Apr 2000 19:33:53 +0800 (SGT)
Message-ID: <38E8818A.3DCD7F30@starnet.gov.sg>
Date:   Mon, 03 Apr 2000 19:33:30 +0800
From:   Tan Pong Heng <pongheng@starnet.gov.sg>
X-Mailer: Mozilla 4.7 [en] (X11; I; Linux 2.3.99-pre2 i686)
X-Accept-Language: en
MIME-Version: 1.0
To:     linux-xfs@oss.sgi.com
Subject: XFS as Root filesystem
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing

Hi, I did some more testings with using XFS as root filesystem. By
inserting some printk
into the kernel, I was able to ascertain that the kernel hanged at the
last stage of
the booting process. It seem to not able to exec the init command. But,
it does not
seem to have failed to do so, but rather hang there trying.

I am not sure how else to debug further, any suggestion?


From owner-linux-xfs@oss.sgi.com Mon Apr  3 05:56:52 2000
Received:  by oss.sgi.com id <S305210AbQDCM4l>;
	Mon, 3 Apr 2000 05:56:41 -0700
Received: from [195.43.220.10] ([195.43.220.10]:57611 "HELO
        mtc-linux1.modular-telecom.se") by oss.sgi.com with SMTP
	id <S305194AbQDCM4U>; Mon, 3 Apr 2000 05:56:20 -0700
Received: (qmail 11159 invoked from network); 3 Apr 2000 12:53:49 -0000
Received: from goofy.air2.net (HELO air2.net) (@195.43.220.5)
  by mtc-linux1.air2.net with SMTP; 3 Apr 2000 12:53:49 -0000
Message-ID: <38E894BA.9294519D@air2.net>
Date:   Mon, 03 Apr 2000 14:55:22 +0200
From:   Fredrik =?iso-8859-1?Q?Win=E4s?= <fredrik@air2.net>
Organization: Air2Net
X-Mailer: Mozilla 4.7 [en] (WinNT; I)
X-Accept-Language: sv,en
MIME-Version: 1.0
To:     linux-xfs@oss.sgi.com
CC:     jerry.lundstrom@citat.se
Subject: XFS bug ?
Content-Type: multipart/mixed;
 boundary="------------9FC2384A195933B9917B09A8"
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing

This is a multi-part message in MIME format.
--------------9FC2384A195933B9917B09A8
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Hi

CPU LOCKUP bug ?

 --- SNIP ---

snoop:/mnt# cd xfs2
snoop:/mnt/xfs2# dir
bigfile1  bigfile2  bigfile3  bigfile4
snoop:/mnt/xfs2# rm bigfile*
NMI Watchdog detected LOCKUP on CPU1, registers:
CPU:    1
EIP:    0010:[<c029fac6>]
EFLAGS: 00000002
eax: 00000200   ebx: c76b5cb8   ecx: c1695c60   edx: c76b5c60
esi: c76b5cb8   edi: c76b5c60   ebp: 00000286   esp: c1695bd8
ds: 0018   es: 0018   ss: 0018
Process rm (pid: 1062, stackpage=c1695000)
Stack: 00000246 00000286 c76b5d20 c76b5c60 c0144496 c76b5c60 00000246
00000286
       c76b5d20 c76b5c60 00000000 00000200 00000400 00000000 00000000
c76b5c60
       c0143dfd c01438a0 00000000 c76b5c60 00000000 c76b5c60 c160dc14
c76b5c60
Call Trace: [<c0144496>] [<c0143dfd>] [<c01438a0>] [<c01c8cae>]
[<c014330d>] [<c018da8d>] [<c01b74c1>]
       [<c01b6d8c>] [<c01a9fc1>] [<c01a8f4e>] [<c01b669d>] [<c01a4914>]
[<c01bd69d>] [<c01ccfc1>] [<c01ca0f9>]
       [<c015ea2e>] [<c015cbc6>] [<c01c55a4>] [<c01c5c77>] [<c0112b94>]
[<c010c331>] [<c010c664>] [<c010c6be>]
       [<c010a430>] [<c0154947>] [<c01545d0>] [<c0156089>] [<c0156167>]
[<c0156247>] [<c010a370>]
Code: f6 03 01 f3 90 75 f9 e9 4f 28 ea ff f6 03 01 f3 90 75 f9 e9
console shuts up ...
Segmentation fault
snoop:/mnt/xfs2#

 --- END SNIP ---




System info:

Kernel:         2.3.99-pre2  patched with
03312000linux-2.3.99-pre2-linux-2.3-xfs.patch
Dist:           Debian GNU Linux (Potato)
CPU:            2x Intel PII 266MHz
Mem:            1x 128MB non-ECC
HDD:            /dev/sda = IBM DNES-318350W     (18GB UW 7200rpm)
                /dev/sdb = IBM DDRS-39130D      (9GB  UW 7200rpm)
--------------9FC2384A195933B9917B09A8
Content-Type: text/plain; charset=us-ascii;
 name="errorlog"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline;
 filename="errorlog"

snoop:/mnt# cd xfs2
snoop:/mnt/xfs2# dir
bigfile1  bigfile2  bigfile3  bigfile4
snoop:/mnt/xfs2# rm bigfile*
NMI Watchdog detected LOCKUP on CPU1, registers:
CPU:    1
EIP:    0010:[<c029fac6>]
EFLAGS: 00000002
eax: 00000200   ebx: c76b5cb8   ecx: c1695c60   edx: c76b5c60
esi: c76b5cb8   edi: c76b5c60   ebp: 00000286   esp: c1695bd8
ds: 0018   es: 0018   ss: 0018
Process rm (pid: 1062, stackpage=c1695000)
Stack: 00000246 00000286 c76b5d20 c76b5c60 c0144496 c76b5c60 00000246 00000286
       c76b5d20 c76b5c60 00000000 00000200 00000400 00000000 00000000 c76b5c60
       c0143dfd c01438a0 00000000 c76b5c60 00000000 c76b5c60 c160dc14 c76b5c60
Call Trace: [<c0144496>] [<c0143dfd>] [<c01438a0>] [<c01c8cae>] [<c014330d>] [<c018da8d>] [<c01b74c1>]
       [<c01b6d8c>] [<c01a9fc1>] [<c01a8f4e>] [<c01b669d>] [<c01a4914>] [<c01bd69d>] [<c01ccfc1>] [<c01ca0f9>]
       [<c015ea2e>] [<c015cbc6>] [<c01c55a4>] [<c01c5c77>] [<c0112b94>] [<c010c331>] [<c010c664>] [<c010c6be>]
       [<c010a430>] [<c0154947>] [<c01545d0>] [<c0156089>] [<c0156167>] [<c0156247>] [<c010a370>]
Code: f6 03 01 f3 90 75 f9 e9 4f 28 ea ff f6 03 01 f3 90 75 f9 e9
console shuts up ...
Segmentation fault
snoop:/mnt/xfs2#
snoop:/mnt/xfs2#

--------------9FC2384A195933B9917B09A8
Content-Type: text/x-vcard; charset=us-ascii;
 name="fredrik.vcf"
Content-Transfer-Encoding: 7bit
Content-Description: Card for Fredrik Winäs
Content-Disposition: attachment;
 filename="fredrik.vcf"

begin:vcard 
n:Winäs;Fredrik
tel;cell:+46 704 936354
tel;work:+46 31 704 30 00
x-mozilla-html:FALSE
url:http://www.air2.net
org:Air2Net AB
adr:;;Första Långgatan 20;Göteborg;;;Sweden
version:2.1
email;internet:fredrik@ait2.net
title:Tech admin
fn:Fredrik Winäs
end:vcard

--------------9FC2384A195933B9917B09A8--


From owner-linux-xfs@oss.sgi.com Mon Apr  3 06:20:22 2000
Received:  by oss.sgi.com id <S305211AbQDCNUM>;
	Mon, 3 Apr 2000 06:20:12 -0700
Received: from deliverator.sgi.com ([204.94.214.10]:46657 "EHLO
        deliverator.sgi.com") by oss.sgi.com with ESMTP id <S305194AbQDCNTq>;
	Mon, 3 Apr 2000 06:19:46 -0700
Received: from ledzep.cray.com (ledzep.cray.com [137.38.226.97]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id GAA09295
	for <linux-xfs@oss.sgi.com>; Mon, 3 Apr 2000 06:15:02 -0700 (PDT)
	mail_from (mostek@sgi.com)
Received: from ironwood-e185.americas.sgi.com (ironwood.cray.com [128.162.185.212]) by ledzep.cray.com (SGI-SGI-8.9.3/craymail-smart-nospam1.0) with ESMTP id IAA79951; Mon, 3 Apr 2000 08:17:12 -0500 (CDT)
Received: from fsgi344.americas.sgi.com (fsgi344.americas.sgi.com [128.162.184.15]) by ironwood-e185.americas.sgi.com (8.8.4/SGI-ironwood-e1.4) with ESMTP id IAA05765; Mon, 3 Apr 2000 08:17:03 -0500 (CDT)
From:   Jim Mostek <mostek@sgi.com>
Received: by fsgi344.americas.sgi.com (980427.SGI.8.8.8/SGI-client.1.6) id IAA33404; Mon, 3 Apr 2000 08:17:09 -0500 (CDT)
Message-Id: <200004031317.IAA33404@fsgi344.americas.sgi.com>
Subject: Re: Source code for Linux XFS now available!
To:     cw@f00f.org (Chris Wedgwood)
Date:   Mon, 3 Apr 2000 08:17:08 -0500 (CDT)
Cc:     linux-xfs@oss.sgi.com
In-Reply-To: <20000402204843.A2130@metastasis.f00f.org> from "Chris Wedgwood" at Apr 02, 2000 08:48:43 PM
X-Mailer: ELM [version 2.5 PL2]
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing


There are a few files outside the modules we have that are affected.
There are few modules that comprise XFS: xfs, pagebuf, and pagebuf_locking,
avl. The last 3 are really just one module (from my perspective) that
other file systems could use, too.

Anyway the files outside XFS don't have lots of changes, but are there.
We haven't had the time to separate all the XFS changes or to try to
get these changes into the default kernel. That will come later.

A few of the files affected are: linux/mm/filemap.c, linux/include/linux/fs.h,
linux/init/main.c, and linux/include/linux/mm.h.

Jim

>
>> A complete linux 2.3.99pre2 tree including the XFS filesystem is
>> available for cvs checkout.
>
>How much code outside the xfs code has been affected? I ask this
>because for those of us on slow links it would be desirable to
>decouple this code from the kernel and build as a module.
>
>
>
>-cw
>


From owner-linux-xfs@oss.sgi.com Mon Apr  3 06:39:52 2000
Received:  by oss.sgi.com id <S305212AbQDCNjc>;
	Mon, 3 Apr 2000 06:39:32 -0700
Received: from deliverator.sgi.com ([204.94.214.10]:35396 "EHLO
        deliverator.sgi.com") by oss.sgi.com with ESMTP id <S305194AbQDCNjQ>;
	Mon, 3 Apr 2000 06:39:16 -0700
Received: from ledzep.cray.com (ledzep.cray.com [137.38.226.97]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id GAA10751
	for <linux-xfs@oss.sgi.com>; Mon, 3 Apr 2000 06:34:35 -0700 (PDT)
	mail_from (lord@sgi.com)
Received: from ironwood-e185.americas.sgi.com (ironwood.cray.com [128.162.185.212]) by ledzep.cray.com (SGI-SGI-8.9.3/craymail-smart-nospam1.0) with ESMTP id IAA89358; Mon, 3 Apr 2000 08:36:44 -0500 (CDT)
Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.184.86]) by ironwood-e185.americas.sgi.com (8.8.4/SGI-ironwood-e1.4) with ESMTP id IAA06549; Mon, 3 Apr 2000 08:36:36 -0500 (CDT)
From:   Steve Lord <lord@sgi.com>
Received: from jen.americas.sgi.com by jen.americas.sgi.com (8.9.3/SGI-client.1.6) via ESMTP id IAA31485; Mon, 3 Apr 2000 08:36:13 -0500
Message-Id: <200004031336.IAA31485@jen.americas.sgi.com>
X-Mailer: exmh version 2.0.3
To:     Fredrik =?iso-8859-1?Q?Win=E4s?= <fredrik@air2.net>
cc:     linux-xfs@oss.sgi.com
Subject: Re: XFS Error 
In-reply-to: Your message of "Sun, 02 Apr 2000 20:52:12 +0200
Content-Transfer-Encoding: quoted-printable
Date:   Mon, 03 Apr 2000 08:36:12 -0500
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing


> =

> Hi
> =

> =

> I'm running XFS with Linux 2.3.99-pre2 and i got some problems when =

> i tried to copy a big file (300Mb) to an XFS disc (150MB), instead of =

> stoping the copy proccess and telling me that the disc was full, =

> it printed out =

> =


This should be fixed in the latest version of the cvs code. New code was
written for the read/write path in Linux, someone forgot to check for
ENOSPC!

Steve Lord


From owner-linux-xfs@oss.sgi.com Mon Apr  3 06:49:42 2000
Received:  by oss.sgi.com id <S305214AbQDCNtc>;
	Mon, 3 Apr 2000 06:49:32 -0700
Received: from deliverator.sgi.com ([204.94.214.10]:59462 "EHLO
        deliverator.sgi.com") by oss.sgi.com with ESMTP id <S305194AbQDCNtE>;
	Mon, 3 Apr 2000 06:49:04 -0700
Received: from ledzep.cray.com (ledzep.cray.com [137.38.226.97]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id GAA11536
	for <linux-xfs@oss.sgi.com>; Mon, 3 Apr 2000 06:44:22 -0700 (PDT)
	mail_from (lord@sgi.com)
Received: from ironwood-e185.americas.sgi.com (ironwood.cray.com [128.162.185.212]) by ledzep.cray.com (SGI-SGI-8.9.3/craymail-smart-nospam1.0) with ESMTP id IAA34439; Mon, 3 Apr 2000 08:46:31 -0500 (CDT)
Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.184.86]) by ironwood-e185.americas.sgi.com (8.8.4/SGI-ironwood-e1.4) with ESMTP id IAA06953; Mon, 3 Apr 2000 08:46:24 -0500 (CDT)
From:   Steve Lord <lord@sgi.com>
Received: from jen.americas.sgi.com by jen.americas.sgi.com (8.9.3/SGI-client.1.6) via ESMTP id IAA31527; Mon, 3 Apr 2000 08:46:00 -0500
Message-Id: <200004031346.IAA31527@jen.americas.sgi.com>
X-Mailer: exmh version 2.0.3
To:     Ted Kline <jtk@sgi.com>
cc:     limhk@limhk.dyn.cheapnet.net (Hway Kiong Lim),
        linux-xfs@oss.sgi.com
Subject: Re: Missing Files 
In-reply-to: Your message of "Sat, 01 Apr 2000 15:59:06 CST
Date:   Mon, 03 Apr 2000 08:46:00 -0500
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing

> > 
> > Hi,
> > 
> > 	Using the following test.sh script :
> > 
> > #!/bin/sh
> > 
> > counter=1000
> > while [ $counter -le 2000 ]
> > do
> > 
> >   echo "File number $counter" >> file$counter
> >   counter=$(( $counter + 1))
> > done
> > 
> > I try to create 1000 (1001 to be precise) files in an xfs mounted directory
. 
> > This is waht happens:
> > 
> > beauty:/mnt/test# sh /tmp/test.sh
> > beauty:/mnt/test# ls | wc
> >     995     995    8955
> > beauty:/mnt/test# rm *
> > beauty:/mnt/test# ls
> > file1144  file1291  file1438  file1585  file1732  file1879
> > beauty:/mnt/test# ls
> > 
> 
> This looks very much like a bug we found in glibc in the getdents syscall
> interface routine having to do with d_off values in the dirent structure
> using bit 2^31, and getdents64 not using lseek64..  Originally it showed
> up when running a 2.3 kernel as a client to an NFS server exporting
> an XFS filesystem.  I was thinking we'd defaulted to dir2 format, and
> that should've kept us from seeing this problem, looks like more
> digging is required..
> 


Ted, this is caused by something in the dir 2 handling of the d_off field
in the dirent structure. We are indeed hitting the scenario where the
glibc getdents code does a seek backwards. The d_off field is supposed to
be the offset of the following directory entry. However, running strace
on an ls on a large directory shows that it seeks to a specific offset,
but the next getdents call comes out starting with the record after the
one we are dealing with - hence we skip one. These offsets are not real
offsets of course.

I modified the script to this:

#!/bin/sh

counter=0
while [ $counter -le 2000 ]
do

  echo "File number $counter" >> long-named-file$counter
  counter=$(( $counter + 1))
done

Here is a snapshot of strace output:

{d_ino=2743392, d_off=6638, d_reclen=32, d_name="long-named-file1644"}
{d_ino=2743393, d_off=6642, d_reclen=32, d_name="long-named-file1645"}
{d_ino=2743394, d_off=6646, d_reclen=32, d_name="long-named-file1646"}
{d_ino=2743395, d_off=6650, d_reclen=32, d_name="long-named-file1647"}
{d_ino=2743396, d_off=6654, d_reclen=32, d_name="long-named-file1648"}
{d_ino=2743397, d_off=6662, d_reclen=32, d_name="long-named-file1649"}
{d_ino=2743398, d_off=6666, d_reclen=32, d_name="long-named-file1650"}
{d_ino=2743399, d_off=6670, d_reclen=32, d_name="long-named-file1651"}
{d_ino=2743400, d_off=6674, d_reclen=32, d_name="long-named-file1652"}
.... and so on
{d_ino=2744476, d_off=6882, d_reclen=32, d_name="long-named-file1704"}
{d_ino=2744477, d_off=6882, d_reclen=32, d_name="long-named-file1705"}}, 
54241) = 54220
lseek(4, 6646, SEEK_SET)                = 6646
brk(0x806f000)                          = 0x806f000
brk(0x807b000)                          = 0x807b000
brk(0x8092000)                          = 0x8092000
mmap(NULL, 188416, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 
0x4010b000
mremap(0x4010b000, 188416, 372736, MREMAP_MAYMOVE) = 0x4010b000
getdents(4, {
{d_ino=2743396, d_off=6654, d_reclen=32, d_name="long-named-file1648"}
{d_ino=2743397, d_off=6662, d_reclen=32, d_name="long-named-file1649"}

So we should have seeked to the record for file 1647, but it went
missing.

I suspect some of my other changes fixed the original script - maybe
ls started using larger buffers? Or maybe my ls/libc is different from the
one which hit the original problem.

we also have reports of ls going into an infinite loop over NFS which
could be related to this.

Steve






From owner-linux-xfs@oss.sgi.com Mon Apr  3 07:03:13 2000
Received:  by oss.sgi.com id <S305177AbQDCODC>;
	Mon, 3 Apr 2000 07:03:02 -0700
Received: from deliverator.sgi.com ([204.94.214.10]:33354 "EHLO
        deliverator.sgi.com") by oss.sgi.com with ESMTP id <S305176AbQDCOCk>;
	Mon, 3 Apr 2000 07:02:40 -0700
Received: from ledzep.cray.com (ledzep.cray.com [137.38.226.97]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id GAA12893
	for <linux-xfs@oss.sgi.com>; Mon, 3 Apr 2000 06:57:58 -0700 (PDT)
	mail_from (lord@sgi.com)
Received: from ironwood-e185.americas.sgi.com (ironwood.cray.com [128.162.185.212]) by ledzep.cray.com (SGI-SGI-8.9.3/craymail-smart-nospam1.0) with ESMTP id JAA86634; Mon, 3 Apr 2000 09:00:07 -0500 (CDT)
Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.184.86]) by ironwood-e185.americas.sgi.com (8.8.4/SGI-ironwood-e1.4) with ESMTP id IAA07454; Mon, 3 Apr 2000 08:59:59 -0500 (CDT)
From:   Steve Lord <lord@sgi.com>
Received: from jen.americas.sgi.com by jen.americas.sgi.com (8.9.3/SGI-client.1.6) via ESMTP id IAA31585; Mon, 3 Apr 2000 08:59:35 -0500
Message-Id: <200004031359.IAA31585@jen.americas.sgi.com>
X-Mailer: exmh version 2.0.3
To:     Tan Pong Heng <pongheng@starnet.gov.sg>
cc:     linux-xfs@oss.sgi.com
Subject: Re: XFS as Root filesystem 
In-reply-to: Your message of "Mon, 03 Apr 2000 19:33:30 +0800
Date:   Mon, 03 Apr 2000 08:59:35 -0500
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing

> Hi, I did some more testings with using XFS as root filesystem. By
> inserting some printk
> into the kernel, I was able to ascertain that the kernel hanged at the
> last stage of
> the booting process. It seem to not able to exec the init command. But,
> it does not
> seem to have failed to do so, but rather hang there trying.
> 
> I am not sure how else to debug further, any suggestion?


The root filesystem is mounted by mount_root in fs/super.c there is a loop
which walks through calling read_super for different filesystem types.
This is probably the place to add printks. 

Steve



From owner-linux-xfs@oss.sgi.com Mon Apr  3 07:24:42 2000
Received:  by oss.sgi.com id <S305177AbQDCOYd>;
	Mon, 3 Apr 2000 07:24:33 -0700
Received: from deliverator.sgi.com ([204.94.214.10]:31567 "EHLO
        deliverator.sgi.com") by oss.sgi.com with ESMTP id <S305176AbQDCOYI>;
	Mon, 3 Apr 2000 07:24:08 -0700
Received: from ledzep.cray.com (ledzep.cray.com [137.38.226.97]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id HAA14759
	for <linux-xfs@oss.sgi.com>; Mon, 3 Apr 2000 07:19:27 -0700 (PDT)
	mail_from (lord@sgi.com)
Received: from ironwood-e185.americas.sgi.com (ironwood.cray.com [128.162.185.212]) by ledzep.cray.com (SGI-SGI-8.9.3/craymail-smart-nospam1.0) with ESMTP id JAA96303; Mon, 3 Apr 2000 09:22:52 -0500 (CDT)
Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.184.86]) by ironwood-e185.americas.sgi.com (8.8.4/SGI-ironwood-e1.4) with ESMTP id JAA08368; Mon, 3 Apr 2000 09:22:43 -0500 (CDT)
From:   Steve Lord <lord@sgi.com>
Received: from jen.americas.sgi.com by jen.americas.sgi.com (8.9.3/SGI-client.1.6) via ESMTP id JAA31636; Mon, 3 Apr 2000 09:22:19 -0500
Message-Id: <200004031422.JAA31636@jen.americas.sgi.com>
X-Mailer: exmh version 2.0.3
To:     Kip Macy <kmacy@CS.Berkeley.EDU>
cc:     linux-xfs@oss.sgi.com
Subject: Re: write ordering on IDE drives 
In-reply-to: Your message of "Sun, 02 Apr 2000 12:56:32 PDT
Date:   Mon, 03 Apr 2000 09:22:19 -0500
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing


> 
> The "xFS Project Architecture" design document has the following to say
> about the requirements made on disk driver by XFS:
> 
> Disk drivers are the same as in traditional and current IRIX systems, 
> except for ordering constraints needed by the log and volume managers 
> and rate guarantees. In particular, it must be possible for the volume 
> manager to be certain that a write request has actually been completed, 
> not merely cached for later writing. It should also be possible for the 
> volume manager to specify that a given write not be reordered - that all
> blocks passed to the driver before this block will be written before 
> this block is written, and all blocks passed to the driver after this 
> block will be written after this block. (If non-ordered writes are not 
> available on a particular driver, the volume manager can synthesize 
> this behavior by waiting for completion, but this is much less efficient.)
> 
> 
> I assume the following still holds true. To my knowledge only IBM's IDE 
> drives support those semantics. Does this mean that all log-writes on 
> non-IBM IDE drives are synchronous? How does the volume manager know 
> whether or not the disk driver supports this behaviour?
> 
> Thanks.
> 
> 
> 					-Kip
> 

All ordering guarantees are handled by XFS itself nowadays - it does not
queue buffers down to the driver layer until it is OK for the I/O to complete.
The one remaining aspect of this is probably GRIO handling where more
explicit control over I/O requests is required.
 
The issue this is talking about now boils down to the fact that XFS wants the
I/O completion for a log or meta-data write to really mean that the data is
going to survive the machine going down. This is used as an indication that we
can start writing the metadata (in the case of a log write completion) or reuse
log space (in the case of metadata I/O completion). 

So drive write caching can be an issue, what happens to write cached data at

1) power off
2) scsi bus reset (and the ide equivalent).

Generally this is controllable externally, I do not know if manufacturers
default drive write caching to off or not - I know IBM does for scsi drives.
I believe this will be an issue for other filesystems with logging such as
ext3 and Reiserfs.

Long term it would be nice to have a driver interface which accepts a flag
with an I/O request which indicates if it is cachable or not. There is some
I/O in XFS (user data) where write caching would be an acceptable thing to
do, and we have talked about being able to take advantage of it.

Steve Lord

p.s. we do have some synchronous transactions where the log write gets forced
out to disk at transaction commit time, in most cases this does not happen
though, XFS can (and does) do less than one disk I/O per transaction in the
best case. Another long term goal would be to restructure these transactions
to avoid the requirement that they be synchronous.



From owner-linux-xfs@oss.sgi.com Mon Apr  3 08:53:11 2000
Received:  by oss.sgi.com id <S305196AbQDCPww>;
	Mon, 3 Apr 2000 08:52:52 -0700
Received: from pneumatic-tube.sgi.com ([204.94.214.22]:27500 "EHLO
        pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP
	id <S305176AbQDCPwr>; Mon, 3 Apr 2000 08:52:47 -0700
Received: from ledzep.cray.com (ledzep.cray.com [137.38.226.97]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id IAA03067
	for <linux-xfs@oss.sgi.com>; Mon, 3 Apr 2000 08:56:31 -0700 (PDT)
	mail_from (mostek@sgi.com)
Received: from ironwood-e185.americas.sgi.com (ironwood.cray.com [128.162.185.212]) by ledzep.cray.com (SGI-SGI-8.9.3/craymail-smart-nospam1.0) with ESMTP id KAA32842; Mon, 3 Apr 2000 10:51:30 -0500 (CDT)
Received: from fsgi344.americas.sgi.com (fsgi344.americas.sgi.com [128.162.184.15]) by ironwood-e185.americas.sgi.com (8.8.4/SGI-ironwood-e1.4) with ESMTP id KAA13158; Mon, 3 Apr 2000 10:51:22 -0500 (CDT)
From:   Jim Mostek <mostek@sgi.com>
Received: by fsgi344.americas.sgi.com (980427.SGI.8.8.8/SGI-client.1.6) id KAA34171; Mon, 3 Apr 2000 10:51:28 -0500 (CDT)
Message-Id: <200004031551.KAA34171@fsgi344.americas.sgi.com>
Subject: Re: XFS as Root
To:     pongheng@starnet.gov.sg (Tan Pong Heng)
Date:   Mon, 3 Apr 2000 10:51:28 -0500 (CDT)
Cc:     linux-xfs@oss.sgi.com
In-Reply-To: <38E6AF73.7ABF49D6@starnet.gov.sg> from "Tan Pong Heng" at Apr 02, 2000 10:24:51 AM
X-Mailer: ELM [version 2.5 PL2]
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing


You are pushing XFS more than we have internally. We have more development
yet to do. We don't feel comfortable enough with XFS to use it as /usr or
any other normal file system, yet. During our testing, we normally
mkfs a fresh copy, beat on it, fix, ...

Thanks,

Jim

>
>OK, I tried the alternative - I now have XFS as /usr instead.
>Everything seems to be fine. It seems that the only problem with
>using XFS as root is to get the right process going before init start.
>(Or so I am guessing....)
>
>There is one catch though - I am not having /usr/src/linux on this
>partition yet - as that is on my home directory for CVS update
>at the moment - that would be /home.
>
>Anything specific that you would like me to test?
>


From owner-linux-xfs@oss.sgi.com Mon Apr  3 09:45:43 2000
Received:  by oss.sgi.com id <S305176AbQDCQpd>;
	Mon, 3 Apr 2000 09:45:33 -0700
Received: from cranston-ip-1-133.dynamic.ziplink.net ([209.206.4.133]:47877
        "EHLO gilgamesh.uruk") by oss.sgi.com with ESMTP id <S305168AbQDCQpR>;
	Mon, 3 Apr 2000 09:45:17 -0700
Received: from localhost (really [127.0.0.1]) by as220.org
	via smail with esmtp
	id <m12c9yU-0002GGC@gilgamesh.uruk> (Debian Smail3.2.0.102)
	for <linux-xfs@oss.sgi.com>; Mon, 3 Apr 2000 12:45:14 -0400 (EDT) 
Date:   Mon, 3 Apr 2000 12:45:14 -0400 (EDT)
From:   Jim Bray <jb@as220.org>
X-Sender: jb@gilgamesh.uruk
To:     linux-xfs@oss.sgi.com
Subject: SGI linux from CVS crashes on boot
Message-ID: <Pine.LNX.4.10.10004031240050.272-100000@gilgamesh.uruk>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing


  According to the EIP, it is crashing in page_fault. EIP=c010af30,
page_fault=c010af28. The sequence is

VFS: Mounted root (ext2 filesystem) readonly
Freeing unused kernel memory: 148k freed
General Protection Fault: 0000
EIP=etcetc.

k6 box, debian/unstable system. Crash happens with or without xfs
configured in.

-Jim	http://as220.org/jb


From owner-linux-xfs@oss.sgi.com Mon Apr  3 09:49:32 2000
Received:  by oss.sgi.com id <S305177AbQDCQtN>;
	Mon, 3 Apr 2000 09:49:13 -0700
Received: from Cantor.suse.de ([194.112.123.193]:18702 "HELO Cantor.suse.de")
	by oss.sgi.com with SMTP id <S305168AbQDCQtF>;
	Mon, 3 Apr 2000 09:49:05 -0700
Received: from Hermes.suse.de (Hermes.suse.de [194.112.123.136])
	by Cantor.suse.de (Postfix) with ESMTP
	id 3F4CE1E1C6; Mon,  3 Apr 2000 18:49:02 +0200 (MEST)
Received: from gruyere.muc.suse.de (gruyere.muc.suse.de [10.23.1.2])
	by Hermes.suse.de (Postfix) with ESMTP
	id 306EE10A026; Mon,  3 Apr 2000 18:48:56 +0200 (MEST)
Received: by gruyere.muc.suse.de (Postfix, from userid 14446)
	id 0A1712F36F; Mon,  3 Apr 2000 18:48:47 +0200 (MEST)
Date:   Mon, 3 Apr 2000 18:48:47 +0200
From:   "Andi Kleen" <ak@suse.de>
To:     Jim Bray <jb@as220.org>
Cc:     linux-xfs@oss.sgi.com, lord@sgi.com
Subject: Re: SGI linux from CVS crashes on boot
Message-ID: <20000403184847.A27381@gruyere.muc.suse.de>
References: <Pine.LNX.4.10.10004031240050.272-100000@gilgamesh.uruk>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 1.0i
In-Reply-To: <Pine.LNX.4.10.10004031240050.272-100000@gilgamesh.uruk>; from jb@as220.org on Mon, Apr 03, 2000 at 12:45:14PM -0400
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing

On Mon, Apr 03, 2000 at 12:45:14PM -0400, Jim Bray wrote:
> 
>   According to the EIP, it is crashing in page_fault. EIP=c010af30,
> page_fault=c010af28. The sequence is
> 
> VFS: Mounted root (ext2 filesystem) readonly
> Freeing unused kernel memory: 148k freed
> General Protection Fault: 0000
> EIP=etcetc.
> 
> k6 box, debian/unstable system. Crash happens with or without xfs

It is KDB's fault. It uses Intel specific MSRs directly. They don't
exist on the K6 and it tells you that with a GPF. 

Apply the following patch. Steve, it seems the KDB patch didn't make it 
into the CVS tree yet.


-Andi

--- arch/i386/kernel/entry.S-o	Thu Mar 16 23:51:14 2000
+++ arch/i386/kernel/entry.S	Fri Mar 17 21:47:47 2000
@@ -432,6 +432,7 @@
 	jmp error_code
 
 ENTRY(page_fault)
+#if 0
 	pushl %ecx
 	pushl %edx
 	pushl %eax
@@ -442,6 +443,7 @@
 	popl  %eax
 	popl  %edx
 	popl  %ecx
+#endif
 	pushl $ SYMBOL_NAME(do_page_fault)
 	jmp error_code
 
--- arch/i386/kdb/kdbasupport.c-o	Thu Mar 16 23:51:14 2000
+++ arch/i386/kdb/kdbasupport.c	Fri Mar 17 20:59:27 2000
@@ -37,6 +37,40 @@
 unsigned long smp_kdb_wait;
 #endif
 
+enum cpu { IntelP5, IntelP6, AmdK6, Unknown } kdba_msrtype; 
+
+/* The normal kernel does the same, but be independent. */ 
+static void 
+checkcpu(void) 
+{ 
+	union { 
+		char str[12]; 
+		__u32 reg[3];  
+	} v; 
+	int eax,ebx,ecx,edx; 
+	__asm__("cpuid" 
+		: "=a" (eax), "=b" (v.reg[0]) , "=c" (v.reg[1]), "=d" (v.reg[2])
+		: "a" (0)); 
+	__asm__("cpuid"
+		: "=a" (eax), "=b" (ebx), "=c" (ecx), "=d" (edx)
+		: "a" (1)); 
+
+	kdba_msrtype = Unknown; 
+	if (!strcmp(v.str, "GenuineIntel")) {
+		switch ((ebx >> 4) & 0xF) { 
+		case 5:
+			kdba_msrtype = IntelP5;
+			break;
+		case 6:
+			kdba_msrtype = IntelP6;
+			break;
+		}			
+	} else if (!strcmp(v.str, "AuthenticAMD") && (((ebx >> 4) & 0xF) == 6)) {
+		kdba_msrtype = AmdK6; 
+	}
+} 
+
+
 void
 kdba_installdbreg(kdb_bp_t *bp)
 {
@@ -708,6 +742,11 @@
 {
 	u32  lv, hv;
 
+	/* Does the P5 have this? */ 
+	if (kdba_msrtype != IntelP6) { 
+		return;
+	}
+
 	rdmsr(DEBUGCTLMSR, lv, hv);
 	lv |= 0x1;	/* Set LBR enable */
 	wrmsr(DEBUGCTLMSR, lv, hv);
@@ -734,6 +773,11 @@
 	u32  bflv, bfhv;
 	u32  btlv, bthv;
 
+	if (kdba_msrtype != IntelP6) { 
+		kdb_printf("Last branch information not supported on this CPU.\n");
+		return;
+	}
+
 	rdmsr(LASTBRANCHFROMIP, bflv, bfhv);
 	rdmsr(LASTBRANCHTOIP, btlv, bthv);
 	kdb_printf("Last Branch IP, from: 0x%x  to 0x%x\n",
@@ -1087,6 +1131,7 @@
 void
 kdba_init(void)
 {
+	checkcpu(); 
 	kdba_enablelbr();
 
 	return;

From owner-linux-xfs@oss.sgi.com Mon Apr  3 10:46:23 2000
Received:  by oss.sgi.com id <S305210AbQDCRqE>;
	Mon, 3 Apr 2000 10:46:04 -0700
Received: from mail.turbolinux.com ([38.170.88.25]:56336 "EHLO
        mail.turbolinux.com") by oss.sgi.com with ESMTP id <S305168AbQDCRpr>;
	Mon, 3 Apr 2000 10:45:47 -0700
Received: from localhost (yakker@localhost)
	by mail.turbolinux.com (8.9.3/8.9.3) with ESMTP id KAA01616;
	Mon, 3 Apr 2000 10:45:25 -0700
Date:   Mon, 3 Apr 2000 10:45:25 -0700 (PDT)
From:   "Matt D. Robinson" <yakker@turbolinux.com>
To:     James Simmons <jsimmons@acsu.buffalo.edu>
cc:     Jim Mostek <mostek@sgi.com>, linux-xfs@oss.sgi.com,
        Christoph Hellwig <chhellwig@gmx.net>
Subject: Re: Source code for Linux XFS now available!
In-Reply-To: <Pine.LNX.4.10.10004012208240.1020-100000@maxwell.futurevision.com>
Message-ID: <Pine.LNX.4.21.0004031036280.30276-100000@mail.turbolinux.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing

On Sat, 1 Apr 2000, James Simmons wrote:
|>Okay. Well I move this to the XFS mailing list. I will have many questions
|>:)

The archive for the Linux-XFS mailing list is available at:

	http://oss.sgi.com/cgi-bin/archive/linux-xfs/

The link was broken, but it is now fixed.  Jim, you may want to re-advertise
this on lkml, as a few people were asking for it (and one reported it as
broken).

--Matt


From owner-linux-xfs@oss.sgi.com Mon Apr  3 10:55:53 2000
Received:  by oss.sgi.com id <S305211AbQDCRzd>;
	Mon, 3 Apr 2000 10:55:33 -0700
Received: from cranston-ip-1-56.dynamic.ziplink.net ([209.206.4.56]:2564 "EHLO
        gilgamesh.uruk") by oss.sgi.com with ESMTP id <S305168AbQDCRzU>;
	Mon, 3 Apr 2000 10:55:20 -0700
Received: from localhost (really [127.0.0.1]) by as220.org
	via smail with esmtp
	id <m12cB4B-0002GZC@gilgamesh.uruk> (Debian Smail3.2.0.102)
	for <linux-xfs@oss.sgi.com>; Mon, 3 Apr 2000 13:55:11 -0400 (EDT) 
Date:   Mon, 3 Apr 2000 13:55:10 -0400 (EDT)
From:   Jim Bray <jb@as220.org>
X-Sender: jb@gilgamesh.uruk
cc:     linux-xfs@oss.sgi.com, lord@sgi.com
Subject: Re: SGI linux from CVS crashes on boot
In-Reply-To: <20000403184847.A27381@gruyere.muc.suse.de>
Message-ID: <Pine.LNX.4.10.10004031353380.1278-100000@gilgamesh.uruk>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
To:     unlisted-recipients:; (no To-header on input)
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing

On Mon, 3 Apr 2000, Andi Kleen wrote:

> It is KDB's fault. It uses Intel specific MSRs directly. They don't
> exist on the K6 and it tells you that with a GPF. 
> 
> Apply the following patch. Steve, it seems the KDB patch didn't make it 
> into the CVS tree yet.

  Works. Recompiling with xfs support.



From owner-linux-xfs@oss.sgi.com Mon Apr  3 11:28:53 2000
Received:  by oss.sgi.com id <S305212AbQDCS2o>;
	Mon, 3 Apr 2000 11:28:44 -0700
Received: from deliverator.sgi.com ([204.94.214.10]:46372 "EHLO
        deliverator.sgi.com") by oss.sgi.com with ESMTP id <S305168AbQDCS2S>;
	Mon, 3 Apr 2000 11:28:18 -0700
Received: from relay1.corp.sgi.com (spindle.corp.sgi.com [198.29.75.13]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id LAA20101
	for <linux-xfs@oss.sgi.com>; Mon, 3 Apr 2000 11:23:36 -0700 (PDT)
	mail_from (trev@sgi.com)
Received: from cromlech.corp.sgi.com (cromlech.corp.sgi.com [150.166.181.83]) by relay1.corp.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) via ESMTP id LAA77821; Mon, 3 Apr 2000 11:28:13 -0700 (PDT)
Received: from sgi.com (localhost [127.0.0.1]) by cromlech.corp.sgi.com (980427.SGI.8.8.8/980728.SGI.AUTOCF) via ESMTP id LAA38899; Mon, 3 Apr 2000 11:26:39 -0700 (PDT)
Message-ID: <38E8E25F.F3343F46@sgi.com>
Date:   Mon, 03 Apr 2000 11:26:39 -0700
From:   Trevor Hurst <trev@sgi.com>
Organization: SGI
X-Mailer: Mozilla 4.7C-SGI [en] (X11; I; IRIX 6.5 IP32)
X-Accept-Language: en
MIME-Version: 1.0
To:     "Matt D. Robinson" <yakker@turbolinux.com>
CC:     James Simmons <jsimmons@acsu.buffalo.edu>,
        Jim Mostek <mostek@sgi.com>, linux-xfs@oss.sgi.com,
        Christoph Hellwig <chhellwig@gmx.net>
Subject: Re: Source code for Linux XFS now available!
References: <Pine.LNX.4.21.0004031036280.30276-100000@mail.turbolinux.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing

"Matt D. Robinson" wrote:
> 
> On Sat, 1 Apr 2000, James Simmons wrote:
> |>Okay. Well I move this to the XFS mailing list. I will have many questions
> |>:)
> 
> The archive for the Linux-XFS mailing list is available at:
> 
>         http://oss.sgi.com/cgi-bin/archive/linux-xfs/
> 
> The link was broken, but it is now fixed.  Jim, you may want to re-advertise
> this on lkml, as a few people were asking for it (and one reported it as
> broken).
> 
> --Matt

 I will be setting up MHonArc for this list as the current
scheme is hideous and it will be much easier to read through
the threads instead of a flat file. Comments?

 Cheers,

 -= Trev :o)

-- 
Trevor Hurst
Systems Administrator                      _ 
Server Operations/Corp. IS       ___  __ _(_)
Silicon Graphics                / __|/ _` | |	
Office Ph: 650.933.6144         \__ \ (_| | |
e-mail: trev@sgi.com            |___/\__, |_|
pager: trev_p@pager.sgi.com          |___/   

--
Linux is like living in a teepee.
No Windows, no Gates, Apache in house. -- Usenet

From owner-linux-xfs@oss.sgi.com Mon Apr  3 12:34:55 2000
Received:  by oss.sgi.com id <S305217AbQDCTeo>;
	Mon, 3 Apr 2000 12:34:44 -0700
Received: from [195.43.220.10] ([195.43.220.10]:62988 "HELO
        mtc-linux1.modular-telecom.se") by oss.sgi.com with SMTP
	id <S305168AbQDCTef>; Mon, 3 Apr 2000 12:34:35 -0700
Received: (qmail 13717 invoked from network); 3 Apr 2000 19:31:59 -0000
Received: from goofy.air2.net (HELO air2.net) (@195.43.220.5)
  by mtc-linux1.air2.net with SMTP; 3 Apr 2000 19:31:59 -0000
Message-ID: <38E8F210.A0A3D92A@air2.net>
Date:   Mon, 03 Apr 2000 21:33:36 +0200
From:   Fredrik =?iso-8859-1?Q?Win=E4s?= <fredrik@air2.net>
Organization: Air2Net
X-Mailer: Mozilla 4.7 [en] (WinNT; I)
X-Accept-Language: sv,en
MIME-Version: 1.0
To:     Linux XFS mailinglista <linux-xfs@oss.sgi.com>
Subject: XFS architecture ?
Content-Type: multipart/mixed;
 boundary="------------6B9FDDEDA377D2D6CDAB6E5D"
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing

This is a multi-part message in MIME format.
--------------6B9FDDEDA377D2D6CDAB6E5D
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Hi

What is the difference between 

	( ) MIPS
	(X) Native
	( ) Multi

?



Thanks
--------------6B9FDDEDA377D2D6CDAB6E5D
Content-Type: text/x-vcard; charset=us-ascii;
 name="fredrik.vcf"
Content-Transfer-Encoding: 7bit
Content-Description: Card for Fredrik Winäs
Content-Disposition: attachment;
 filename="fredrik.vcf"

begin:vcard 
n:Winäs;Fredrik
tel;cell:+46 704 936354
tel;work:+46 31 704 30 00
x-mozilla-html:FALSE
url:http://www.air2.net
org:Air2Net AB
adr:;;Första Långgatan 20;Göteborg;;;Sweden
version:2.1
email;internet:fredrik@ait2.net
title:Tech admin
fn:Fredrik Winäs
end:vcard

--------------6B9FDDEDA377D2D6CDAB6E5D--


From owner-linux-xfs@oss.sgi.com Mon Apr  3 12:45:55 2000
Received:  by oss.sgi.com id <S305216AbQDCTpp>;
	Mon, 3 Apr 2000 12:45:45 -0700
Received: from deliverator.sgi.com ([204.94.214.10]:35898 "EHLO
        deliverator.sgi.com") by oss.sgi.com with ESMTP id <S305168AbQDCTpd>;
	Mon, 3 Apr 2000 12:45:33 -0700
Received: from ledzep.cray.com (ledzep.cray.com [137.38.226.97]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id MAA00602
	for <linux-xfs@oss.sgi.com>; Mon, 3 Apr 2000 12:40:50 -0700 (PDT)
	mail_from (lord@sgi.com)
Received: from ironwood-e185.americas.sgi.com (ironwood.cray.com [128.162.185.212]) by ledzep.cray.com (SGI-SGI-8.9.3/craymail-smart-nospam1.0) with ESMTP id OAA56322; Mon, 3 Apr 2000 14:42:59 -0500 (CDT)
Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.184.86]) by ironwood-e185.americas.sgi.com (8.8.4/SGI-ironwood-e1.4) with ESMTP id OAA24258; Mon, 3 Apr 2000 14:42:51 -0500 (CDT)
From:   Steve Lord <lord@sgi.com>
Received: from jen.americas.sgi.com by jen.americas.sgi.com (8.9.3/SGI-client.1.6) via ESMTP id OAA03993; Mon, 3 Apr 2000 14:42:25 -0500
Message-Id: <200004031942.OAA03993@jen.americas.sgi.com>
X-Mailer: exmh version 2.0.3
To:     Fredrik =?iso-8859-1?Q?Win=E4s?= <fredrik@air2.net>
cc:     Linux XFS mailinglista <linux-xfs@oss.sgi.com>
Subject: Re: XFS architecture ? 
In-reply-to: Your message of "Mon, 03 Apr 2000 21:33:36 +0200
Content-Transfer-Encoding: quoted-printable
Date:   Mon, 03 Apr 2000 14:42:25 -0500
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing


> =

> Hi
> =

> What is the difference between =

> =

> 	( ) MIPS
> 	(X) Native
> 	( ) Multi
> =

> ?
> =

> =

> =

> Thanks


Currently the on disk format used by XFS on Linux is not compatible with =
that
used on Irix. Work is in progress to add the byte swapping work to suppor=
t the
Irix format. So:

MIPS format is the Irix on disk format
Native is whatever format the local cpu supports (no byte swapping)
Multi is support for runtime switchable support

The current thinking is the get the MIPs format working on Intel boxes an=
d
measure the overhead. If it is low enough then all the other formats go a=
way
and we stick with the single format. If the overhead is significant we pr=
obably
support multiple formats, but I doubt that multi (run time detection and
switching) will be a viable option.

Steve Lord





From owner-linux-xfs@oss.sgi.com Mon Apr  3 12:49:15 2000
Received:  by oss.sgi.com id <S305218AbQDCTtF>;
	Mon, 3 Apr 2000 12:49:05 -0700
Received: from cranston-ip-1-239.dynamic.ziplink.net ([209.206.4.239]:6148
        "EHLO gilgamesh.uruk") by oss.sgi.com with ESMTP id <S305168AbQDCTtD>;
	Mon, 3 Apr 2000 12:49:03 -0700
Received: from localhost (really [127.0.0.1]) by as220.org
	via smail with esmtp
	id <m12cCqE-0002GZC@gilgamesh.uruk> (Debian Smail3.2.0.102)
	for <linux-xfs@oss.sgi.com>; Mon, 3 Apr 2000 15:48:54 -0400 (EDT) 
Date:   Mon, 3 Apr 2000 15:48:52 -0400 (EDT)
From:   Jim Bray <jb@as220.org>
X-Sender: jb@gilgamesh.uruk
To:     linux-xfs@oss.sgi.com
Subject: mkfs
Message-ID: <Pine.LNX.4.10.10004031526060.508-100000@gilgamesh.uruk>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing


  mkfs crashes with sigsegv:

Starting program: /src/kernels/sgi/cmd/xfs/mkfs/mkfs_xfs /dev/hda11

Breakpoint 7, uuid_create (uuid=0xbffff924, status=0xbffff7e4)
    at xfs_uuid.c:167
167	in xfs_uuid.c
(gdb) bt
#0  uuid_create (uuid=0xbffff924, status=0xbffff7e4) at xfs_uuid.c:167
#1  0x804b1f1 in main ()
#2  0x8081175 in __libc_start_main ()
(gdb) cont
Continuing.

Breakpoint 6, get_eaddr (junk=0x80c509a "ys") at xfs_uuid.c:232
232	in xfs_uuid.c
(gdb) bt
#0  get_eaddr (junk=0x80c509a "ys") at xfs_uuid.c:232
#1  0x806b721 in uuid_create (uuid=0xbffff924, status=0xbffff7e4)
    at xfs_uuid.c:185
(gdb) cont
*******************************************************
***Notice that we seem to have lost some stack frames**
*******************************************************
Continuing.

Program received signal SIGSEGV, Segmentation fault.
0x0 in ?? ()
(gdb) 


Jim	http://as220.org/jb
 
            "			"
	     \   ____/|        / 
	      \  \ o.O|      /
	       \  =(_)=    /
		\   U    /       
		 \  |  / 
		  \ #/
	
              ACK! PHTHPHTH!
	   "I am not a crook!"


From owner-linux-xfs@oss.sgi.com Mon Apr  3 12:50:45 2000
Received:  by oss.sgi.com id <S305219AbQDCTug>;
	Mon, 3 Apr 2000 12:50:36 -0700
Received: from deliverator.sgi.com ([204.94.214.10]:64571 "EHLO
        deliverator.sgi.com") by oss.sgi.com with ESMTP id <S305168AbQDCTu3>;
	Mon, 3 Apr 2000 12:50:29 -0700
Received: from ledzep.cray.com (ledzep.cray.com [137.38.226.97]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id MAA01363
	for <linux-xfs@oss.sgi.com>; Mon, 3 Apr 2000 12:45:47 -0700 (PDT)
	mail_from (mostek@sgi.com)
Received: from ironwood-e185.americas.sgi.com (ironwood.cray.com [128.162.185.212]) by ledzep.cray.com (SGI-SGI-8.9.3/craymail-smart-nospam1.0) with ESMTP id OAA80072; Mon, 3 Apr 2000 14:47:56 -0500 (CDT)
Received: from fsgi344.americas.sgi.com (fsgi344.americas.sgi.com [128.162.184.15]) by ironwood-e185.americas.sgi.com (8.8.4/SGI-ironwood-e1.4) with ESMTP id OAA24466; Mon, 3 Apr 2000 14:47:48 -0500 (CDT)
From:   Jim Mostek <mostek@sgi.com>
Received: by fsgi344.americas.sgi.com (980427.SGI.8.8.8/SGI-client.1.6) id OAA30522; Mon, 3 Apr 2000 14:47:54 -0500 (CDT)
Message-Id: <200004031947.OAA30522@fsgi344.americas.sgi.com>
Subject: Re: XFS architecture ?
To:     fredrik@air2.net (Fredrik =?iso-8859-1?Q?Win=E4s?=)
Date:   Mon, 3 Apr 2000 14:47:53 -0500 (CDT)
Cc:     linux-xfs@oss.sgi.com (Linux XFS mailinglista)
In-Reply-To: <38E8F210.A0A3D92A@air2.net> from "Fredrik =?iso-8859-1?Q?Win=E4s?=" at Apr 03, 2000 09:33:36 PM
X-Mailer: ELM [version 2.5 PL2]
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing


This has to do with the on disk format.
All IRIX XFS implementations are MIPS Big Endian.
The current pre-alpha Linux XFS implementation is IA32 Little Endian.

We have an effort underway to allow the Linux implementation to
run with different on disk formats (i.e. machine architectures):
MIPS or Native (IA32, ...) or ...

Multi means that the system can read/write multiple formats. The same machine
could have different file systems each with different formats.

This work is in development.

The first step is to give the code the ability to read multiple formats.
The second step is to see what the overhead is of always having
MIPS big endian format. I hope this is the last step. If so,
these selections will go away.

If the overhead is too much, we will need to have Native and Multi so
that we can have multiple endian on disk formats.

Jim


>Hi
>
>What is the difference between 
>
>	( ) MIPS
>	(X) Native
>	( ) Multi
>
>?
>
>
>
>Thanks

From owner-linux-xfs@oss.sgi.com Mon Apr  3 12:52:45 2000
Received:  by oss.sgi.com id <S305220AbQDCTw0>;
	Mon, 3 Apr 2000 12:52:26 -0700
Received: from timbuk-fddi.cray.com ([128.162.8.102]:2944 "EHLO
        timbuk.cray.com") by oss.sgi.com with ESMTP id <S305168AbQDCTwR>;
	Mon, 3 Apr 2000 12:52:17 -0700
Received: from clink.americas.sgi.com (clink.cray.com [128.162.84.70]) by timbuk.cray.com (8.8.8/CRI-gate-news-1.3) with ESMTP id OAA12621 for <linux-xfs@oss.sgi.com>; Mon, 3 Apr 2000 14:52:14 -0500 (CDT)
Received: (from lord@localhost) by clink.americas.sgi.com (980427.SGI.8.8.8/CRI-news-1.3) id OAA71814 for linux-xfs@oss.sgi.com; Mon, 3 Apr 2000 14:52:15 -0500 (CDT)
Date:   Mon, 3 Apr 2000 14:52:15 -0500 (CDT)
From:   Steve Lord <lord@sgi.com>
Message-Id: <200004031952.OAA71814@clink.americas.sgi.com>
To:     linux-xfs@oss.sgi.com
Subject: TAKE - Assorted filesystem interface fixes
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing

This should:

1. fix FIFO and symlink problems in XFS
2. Stop XFS from holding more space in a file than it needs after
   last close.

Note that for those of you in CVS land, there is a lag before this
is available - CVS is updated about once a day.

Steve

Modid:  2.3.99pre2-xfs:slinx:56508a
Date:  Mon Apr  3 12:49:58 PDT 2000
Workarea:  clink.americas.sgi.com:/data/clink/io/lord/slinx-xfs-2.3.99pre2

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

linux/fs/xfs/linux/xfs_file.c - 1.23
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/linux/fs/xfs/linux/xfs_file.c.diff?r1=text&tr1=1.23&r2=text&tr2=1.22&f=h
	- Implement a release method for XFS - this will prune back
	  space allocated beyond end of file.

linux/fs/xfs/linux/xfs_iops.c - 1.43
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/linux/fs/xfs/linux/xfs_iops.c.diff?r1=text&tr1=1.43&r2=text&tr2=1.42&f=h
	- Ensure we clean up the dcache on a readlink error.

linux/fs/xfs/linux/xfs_super.c - 1.60
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/linux/fs/xfs/linux/xfs_super.c.diff?r1=text&tr1=1.60&r2=text&tr2=1.59&f=h
	- Call init_special_inode for all special inode types, not
	  jsut devices.

linux/fs/xfs/pseudo-inc/sys/vnode.h - 1.16
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/linux/fs/xfs/pseudo-inc/sys/vnode.h.diff?r1=text&tr1=1.16&r2=text&tr2=1.15&f=h
	- Add a release vnode op

linux/fs/xfs/xfs_vnodeops.c - 1.448
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/linux/fs/xfs/xfs_vnodeops.c.diff?r1=text&tr1=1.448&r2=text&tr2=1.447&f=h
	- Implement the release vnode op to call xfs_inactive_free_eofblocks()
	  ensure that we keep a reference count on the vnode returned
	  when we make a symbolic link.

linux/fs/xfs/xfsidbg.c - 1.124
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/linux/fs/xfs/xfsidbg.c.diff?r1=text&tr1=1.124&r2=text&tr2=1.123&f=h
	- Add vnode command to dump some basics of the vnode
	  structure.


From owner-linux-xfs@oss.sgi.com Mon Apr  3 13:04:15 2000
Received:  by oss.sgi.com id <S305176AbQDCUD4>;
	Mon, 3 Apr 2000 13:03:56 -0700
Received: from ns.hanse.com ([212.209.57.34]:2828 "EHLO ns.hanse.com")
	by oss.sgi.com with ESMTP id <S305168AbQDCUDj>;
	Mon, 3 Apr 2000 13:03:39 -0700
Received: from hanse.com (voyager.stesmi.com [212.209.57.67])
	by ns.hanse.com (8.9.3/8.8.7) with ESMTP id WAA14661
	for <linux-xfs@oss.sgi.com>; Mon, 3 Apr 2000 22:03:24 +0200
Message-ID: <38E8F90B.44E33FEE@hanse.com>
Date:   Mon, 03 Apr 2000 22:03:23 +0200
From:   Stefan Smietanowski <stefan@hanse.com>
Organization: Hanse Communication
X-Mailer: Mozilla 4.7 [en] (Win98; U)
X-Accept-Language: en
MIME-Version: 1.0
CC:     Linux XFS mailinglist <linux-xfs@oss.sgi.com>
Subject: Re: XFS architecture ?
References: <200004031947.OAA30522@fsgi344.americas.sgi.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
To:     unlisted-recipients:; (no To-header on input)
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing

Greetings.

> This has to do with the on disk format.
> All IRIX XFS implementations are MIPS Big Endian.
> The current pre-alpha Linux XFS implementation is IA32 Little Endian.
> 
> We have an effort underway to allow the Linux implementation to
> run with different on disk formats (i.e. machine architectures):
> MIPS or Native (IA32, ...) or ...
> 
> Multi means that the system can read/write multiple formats. The same machine
> could have different file systems each with different formats.

Linux had that before, with Big Endian machines having a Big Endian
ext2, but that was dropped before 2.0.0 if I recall correctly, and now
all linux machines use a little endian ext2 system. I can't remember the
extra overhead needed to switch endianness though ...

If it comes to using different formats based on the native endianness,
will the IRIX XFS be extended also to support this feature?

If it doesn't, that would mean that I cannot take my linux XFS partition
and move it to the IRIX machine, which imho is one point with running a
native XFS system on Linux.

// Stefan

--
Stefan Smietanowski
Head Unix Administrator, Hanse Communication
e-mail  : stefan@hanse.com

From owner-linux-xfs@oss.sgi.com Mon Apr  3 13:04:55 2000
Received:  by oss.sgi.com id <S305196AbQDCUEq>;
	Mon, 3 Apr 2000 13:04:46 -0700
Received: from deliverator.sgi.com ([204.94.214.10]:3649 "EHLO
        deliverator.sgi.com") by oss.sgi.com with ESMTP id <S305168AbQDCUEg>;
	Mon, 3 Apr 2000 13:04:36 -0700
Received: from ledzep.cray.com (ledzep.cray.com [137.38.226.97]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id MAA03858
	for <linux-xfs@oss.sgi.com>; Mon, 3 Apr 2000 12:59:54 -0700 (PDT)
	mail_from (cattelan@thebarn.com)
Received: from ironwood-e185.americas.sgi.com (ironwood.cray.com [128.162.185.212]) by ledzep.cray.com (SGI-SGI-8.9.3/craymail-smart-nospam1.0) with ESMTP id PAA99477; Mon, 3 Apr 2000 15:02:03 -0500 (CDT)
Received: from gibble.americas.sgi.com (root@gibble.americas.sgi.com [128.162.195.80]) by ironwood-e185.americas.sgi.com (8.8.4/SGI-ironwood-e1.4) with ESMTP id PAA25063; Mon, 3 Apr 2000 15:01:55 -0500 (CDT)
Received: from thebarn.com by gibble.americas.sgi.com (8.9.3/SGI-client.1.6) via ESMTP id PAA03655; Mon, 3 Apr 2000 15:02:02 -0500
Message-ID: <38E8F8BA.ACC283ED@thebarn.com>
Date:   Mon, 03 Apr 2000 15:02:02 -0500
From:   Russell Cattelan <cattelan@thebarn.com>
X-Mailer: Mozilla 4.72 [en] (X11; I; Linux 2.2.14-15mdksmp i686)
X-Accept-Language: en
MIME-Version: 1.0
To:     Jim Bray <jb@as220.org>
CC:     linux-xfs@oss.sgi.com
Subject: Re: mkfs
References: <Pine.LNX.4.10.10004031526060.508-100000@gilgamesh.uruk>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing

Jim Bray wrote:

What are you running.
which os  more specifically what version of libc?

You could also try the statically linked version of mkfs that is on the
ftp site.


>   mkfs crashes with sigsegv:
>
> Starting program: /src/kernels/sgi/cmd/xfs/mkfs/mkfs_xfs /dev/hda11
>
> Breakpoint 7, uuid_create (uuid=0xbffff924, status=0xbffff7e4)
>     at xfs_uuid.c:167
> 167     in xfs_uuid.c
> (gdb) bt
> #0  uuid_create (uuid=0xbffff924, status=0xbffff7e4) at xfs_uuid.c:167
> #1  0x804b1f1 in main ()
> #2  0x8081175 in __libc_start_main ()
> (gdb) cont
> Continuing.
>
> Breakpoint 6, get_eaddr (junk=0x80c509a "ys") at xfs_uuid.c:232
> 232     in xfs_uuid.c
> (gdb) bt
> #0  get_eaddr (junk=0x80c509a "ys") at xfs_uuid.c:232
> #1  0x806b721 in uuid_create (uuid=0xbffff924, status=0xbffff7e4)
>     at xfs_uuid.c:185
> (gdb) cont
> *******************************************************
> ***Notice that we seem to have lost some stack frames**
> *******************************************************
> Continuing.
>
> Program received signal SIGSEGV, Segmentation fault.
> 0x0 in ?? ()
> (gdb)
>
> Jim     http://as220.org/jb
>
>             "                   "
>              \   ____/|        /
>               \  \ o.O|      /
>                \  =(_)=    /
>                 \   U    /
>                  \  |  /
>                   \ #/
>
>               ACK! PHTHPHTH!
>            "I am not a crook!"


From owner-linux-xfs@oss.sgi.com Mon Apr  3 13:26:56 2000
Received:  by oss.sgi.com id <S305177AbQDCU0p>;
	Mon, 3 Apr 2000 13:26:45 -0700
Received: from deliverator.sgi.com ([204.94.214.10]:12873 "EHLO
        deliverator.sgi.com") by oss.sgi.com with ESMTP id <S305168AbQDCU0j>;
	Mon, 3 Apr 2000 13:26:39 -0700
Received: from ledzep.cray.com (ledzep.cray.com [137.38.226.97]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id NAA08174
	for <linux-xfs@oss.sgi.com>; Mon, 3 Apr 2000 13:21:57 -0700 (PDT)
	mail_from (cattelan@thebarn.com)
Received: from ironwood-e185.americas.sgi.com (ironwood.cray.com [128.162.185.212]) by ledzep.cray.com (SGI-SGI-8.9.3/craymail-smart-nospam1.0) with ESMTP id PAA44386 for <linux-xfs@oss.sgi.com>; Mon, 3 Apr 2000 15:24:06 -0500 (CDT)
Received: from gibble.americas.sgi.com (root@gibble.americas.sgi.com [128.162.195.80]) by ironwood-e185.americas.sgi.com (8.8.4/SGI-ironwood-e1.4) with ESMTP id PAA26229 for <linux-xfs@oss.sgi.com>; Mon, 3 Apr 2000 15:23:59 -0500 (CDT)
Received: from thebarn.com by gibble.americas.sgi.com (8.9.3/SGI-client.1.6) via ESMTP id PAA03687; Mon, 3 Apr 2000 15:24:06 -0500
Message-ID: <38E8FDE5.EF33C62B@thebarn.com>
Date:   Mon, 03 Apr 2000 15:24:05 -0500
From:   Russell Cattelan <cattelan@thebarn.com>
X-Mailer: Mozilla 4.72 [en] (X11; I; Linux 2.2.14-15mdksmp i686)
X-Accept-Language: en
MIME-Version: 1.0
To:     linux-xfs@oss.sgi.com
Subject: xfs list archive
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing

I indexed the  linux-xfs list via mhonarc


This was a quick setup, so any suggestions on cleaning it up
send me some mail.

http://oss.sgi.com/projects/linux-xfs/indexed/threads.html


From owner-linux-xfs@oss.sgi.com Mon Apr  3 14:06:56 2000
Received:  by oss.sgi.com id <S305176AbQDCVGq>;
	Mon, 3 Apr 2000 14:06:46 -0700
Received: from deliverator.sgi.com ([204.94.214.10]:55890 "EHLO
        deliverator.sgi.com") by oss.sgi.com with ESMTP id <S305168AbQDCVGk>;
	Mon, 3 Apr 2000 14:06:40 -0700
Received: from ledzep.cray.com (ledzep.cray.com [137.38.226.97]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id OAA12750
	for <linux-xfs@oss.sgi.com>; Mon, 3 Apr 2000 14:01:57 -0700 (PDT)
	mail_from (cattelan@thebarn.com)
Received: from ironwood-e185.americas.sgi.com (ironwood.cray.com [128.162.185.212]) by ledzep.cray.com (SGI-SGI-8.9.3/craymail-smart-nospam1.0) with ESMTP id QAA28442; Mon, 3 Apr 2000 16:05:23 -0500 (CDT)
Received: from gibble.americas.sgi.com (root@gibble.americas.sgi.com [128.162.195.80]) by ironwood-e185.americas.sgi.com (8.8.4/SGI-ironwood-e1.4) with ESMTP id QAA28718; Mon, 3 Apr 2000 16:05:14 -0500 (CDT)
Received: from thebarn.com by gibble.americas.sgi.com (8.9.3/SGI-client.1.6) via ESMTP id QAA03752; Mon, 3 Apr 2000 16:05:21 -0500
Message-ID: <38E90791.200AD17F@thebarn.com>
Date:   Mon, 03 Apr 2000 16:05:21 -0500
From:   Russell Cattelan <cattelan@thebarn.com>
X-Mailer: Mozilla 4.72 [en] (X11; I; Linux 2.2.14-15mdksmp i686)
X-Accept-Language: en
MIME-Version: 1.0
To:     Christoph Hellwig <chhellwig@gmx.net>
CC:     linux-kernel@vger.rutgers.edu, linux-xfs@oss.sgi.com
Subject: Re: Source code for Linux XFS now available!
References: <Pine.LNX.4.10.10004010841490.4727-100000@maxwell.futurevision.com> <200004011416.IAA31320@fsgi344.americas.sgi.com> <20000401171800.A3460@sb.t-online.de>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing

Christoph Hellwig wrote:

Neither the patch file nor the snapshot will be generated on a regular basis.
The CVS stuff will be needed to keep up with the current state of the tree.

I'm not sure why you would want to read the patch file any ways, it's quite
large.

> On Sat, Apr 01, 2000 at 08:16:15AM -0600, Jim Mostek wrote:
> > >> and expensive 56k or 64k lines. I can download reiserfs, ext3, jfs and linlogfs either as patch or
> > >> as tarball of the new files, why can't you do this, too?
> > >
> > >Please do :(
> >
> > Russell placed a smaller source patch in:
> > ftp://oss.sgi.com/projects/xfs/ftpdir/03312000linux-2.3.99pre2-linux-2.3-xfs.patch.gz
>
> Ok, I've downloaded it. BTW: the patch has all the CVS dirs included, so it is not very well
> readable. Could you please remove this in the next version?
>
> >


From owner-linux-xfs@oss.sgi.com Mon Apr  3 14:48:05 2000
Received:  by oss.sgi.com id <S305176AbQDCVrq>;
	Mon, 3 Apr 2000 14:47:46 -0700
Received: from pneumatic-tube.sgi.com ([204.94.214.22]:5154 "EHLO
        pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP
	id <S305168AbQDCVrW>; Mon, 3 Apr 2000 14:47:22 -0700
Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via SMTP id OAA09914
	for <linux-xfs@oss.sgi.com>; Mon, 3 Apr 2000 14:51:04 -0700 (PDT)
	mail_from (kenmcd@melbourne.sgi.com)
Received: from rattle.melbourne.sgi.com (rattle.melbourne.sgi.com [134.14.55.145]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id HAA12323; Tue, 4 Apr 2000 07:45:26 +1000
Received: from localhost (kenmcd@localhost) by rattle.melbourne.sgi.com (980427.SGI.8.8.8/980728.SGI.AUTOCF) via ESMTP id HAA04178; Tue, 4 Apr 2000 07:45:24 +1000 (EST)
Date:   Tue, 4 Apr 2000 07:45:23 +1000
From:   Ken McDonell <kenmcd@melbourne.sgi.com>
To:     Stefan Smietanowski <stefan@hanse.com>
cc:     Linux XFS mailinglist <linux-xfs@oss.sgi.com>
Subject: Re: XFS architecture ?
In-Reply-To: <38E8F90B.44E33FEE@hanse.com>
Message-ID: <Pine.SGI.4.10.10004040735500.3397-100000@rattle.melbourne.sgi.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing

On Mon, 3 Apr 2000, Stefan Smietanowski wrote:
> ...
> 
> Linux had that before, with Big Endian machines having a Big Endian
> ext2, but that was dropped before 2.0.0 if I recall correctly, and now
> all linux machines use a little endian ext2 system. I can't remember the
> extra overhead needed to switch endianness though ...
> 
> If it comes to using different formats based on the native endianness,
> will the IRIX XFS be extended also to support this feature?
> 
> If it doesn't, that would mean that I cannot take my linux XFS partition
> and move it to the IRIX machine, which imho is one point with running a
> native XFS system on Linux.

Rest assured.  Our IRIX heritage and the very migration strategy you
describe mandate that XFS on Linux _will_ support the IRIX MIPS on-disk
format.

The issue we still have to resolve (and this is the initial objective of the
endian work) is,

(a) will the XFS on-disk format be the IRIX MIPS format everywhere
    (the every XFS is big endian model), or
(b) will the Linux version of XFS support both a little endian on-disk
    format (what you see today with the released code on Intel
    platforms), _and_ the IRIX MIPS on-disk format

Note that most of the source code changes and effort go into moving
from the status today to (a).  If we end up with (b) this is a
relatively small additional development effort.

The way this work is being done, there may also be another option

(c) make the on-disk format the same as the in memory format ... this
    is the "convert nothing" model for those who care about nanocycles
    and don't care about media interoperability or clustered
    filesystems


From owner-linux-xfs@oss.sgi.com Mon Apr  3 14:53:05 2000
Received:  by oss.sgi.com id <S305176AbQDCVwq>;
	Mon, 3 Apr 2000 14:52:46 -0700
Received: from deliverator.sgi.com ([204.94.214.10]:14689 "EHLO
        deliverator.sgi.com") by oss.sgi.com with ESMTP id <S305168AbQDCVwa>;
	Mon, 3 Apr 2000 14:52:30 -0700
Received: from ledzep.cray.com (ledzep.cray.com [137.38.226.97]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id OAA19077
	for <linux-xfs@oss.sgi.com>; Mon, 3 Apr 2000 14:47:48 -0700 (PDT)
	mail_from (cattelan@thebarn.com)
Received: from ironwood-e185.americas.sgi.com (ironwood.cray.com [128.162.185.212]) by ledzep.cray.com (SGI-SGI-8.9.3/craymail-smart-nospam1.0) with ESMTP id QAA31862; Mon, 3 Apr 2000 16:51:13 -0500 (CDT)
Received: from gibble.americas.sgi.com (root@gibble.americas.sgi.com [128.162.195.80]) by ironwood-e185.americas.sgi.com (8.8.4/SGI-ironwood-e1.4) with ESMTP id QAA00517; Mon, 3 Apr 2000 16:51:05 -0500 (CDT)
Received: from thebarn.com by gibble.americas.sgi.com (8.9.3/SGI-client.1.6) via ESMTP id QAA03917; Mon, 3 Apr 2000 16:51:12 -0500
Message-ID: <38E9124F.44470CF5@thebarn.com>
Date:   Mon, 03 Apr 2000 16:51:11 -0500
From:   Russell Cattelan <cattelan@thebarn.com>
X-Mailer: Mozilla 4.72 [en] (X11; I; Linux 2.2.14-15mdksmp i686)
X-Accept-Language: en
MIME-Version: 1.0
To:     Jim Bray <jb@as220.org>
CC:     linux-xfs@oss.sgi.com
Subject: Re: mkfs
References: <Pine.LNX.4.10.10004031720290.363-100000@gilgamesh.uruk>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing

Jim Bray wrote:

> On Mon, 3 Apr 2000, Russell Cattelan wrote:
>
> > Jim Bray wrote:
> >
> > What are you running.
> > which os  more specifically what version of libc?
>
> debian/unstable GNU/Linux on a k6-2.
>
> libc.so.6 => libc-2.1.3.so

If you statically link the binary does it still crash?
If so, send me a copy of the binary.

>
>
> Jim     http://as220.org/jb
>
>             "                   "
>              \   ____/|        /
>               \  \ o.O|      /
>                \  =(_)=    /
>                 \   U    /
>                  \  |  /
>                   \ #/
>
>               ACK! PHTHPHTH!
>            "I am not a crook!"


From owner-linux-xfs@oss.sgi.com Mon Apr  3 14:59:16 2000
Received:  by oss.sgi.com id <S305176AbQDCV7H>;
	Mon, 3 Apr 2000 14:59:07 -0700
Received: from Cantor.suse.de ([194.112.123.193]:59664 "HELO Cantor.suse.de")
	by oss.sgi.com with SMTP id <S305168AbQDCV6t>;
	Mon, 3 Apr 2000 14:58:49 -0700
Received: from Hermes.suse.de (Hermes.suse.de [194.112.123.136])
	by Cantor.suse.de (Postfix) with ESMTP
	id 451AA1E208; Mon,  3 Apr 2000 23:58:46 +0200 (MEST)
Received: from gruyere.muc.suse.de (gruyere.muc.suse.de [10.23.1.2])
	by Hermes.suse.de (Postfix) with ESMTP
	id EC12910A030; Mon,  3 Apr 2000 23:58:44 +0200 (MEST)
Received: by gruyere.muc.suse.de (Postfix, from userid 14446)
	id CBAE72F36B; Mon,  3 Apr 2000 23:58:42 +0200 (MEST)
Date:   Mon, 3 Apr 2000 23:58:42 +0200
From:   "Andi Kleen" <ak@suse.de>
To:     Ken McDonell <kenmcd@melbourne.sgi.com>
Cc:     Stefan Smietanowski <stefan@hanse.com>,
        Linux XFS mailinglist <linux-xfs@oss.sgi.com>
Subject: Re: XFS architecture ?
Message-ID: <20000403235842.A30564@gruyere.muc.suse.de>
References: <38E8F90B.44E33FEE@hanse.com> <Pine.SGI.4.10.10004040735500.3397-100000@rattle.melbourne.sgi.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 1.0i
In-Reply-To: <Pine.SGI.4.10.10004040735500.3397-100000@rattle.melbourne.sgi.com>; from kenmcd@melbourne.sgi.com on Tue, Apr 04, 2000 at 07:45:23AM +1000
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing

On Tue, Apr 04, 2000 at 07:45:23AM +1000, Ken McDonell wrote:
> (b) will the Linux version of XFS support both a little endian on-disk
>     format (what you see today with the released code on Intel
>     platforms), _and_ the IRIX MIPS on-disk format

Switching endians is very cheap on modern CPUs (ppro+ have a special
instruction, ultrasparc/ia64/et.al. have special bits in the store
instructions to store both endians). What is expensive is checking
whether you need to switch (or rather, it is not that expensive at runtime,
but bloats the code/binary a lot because a lot of routines will be duplicated)

Big-Endian XFS everywhere probably makes sense.  TCP/IP has proven that it 
is possible :-) 

-Andi


From owner-linux-xfs@oss.sgi.com Mon Apr  3 15:35:57 2000
Received:  by oss.sgi.com id <S305196AbQDCWfr>;
	Mon, 3 Apr 2000 15:35:47 -0700
Received: from cranston-ip-1-1.dynamic.ziplink.net ([209.206.4.1]:25604 "EHLO
        gilgamesh.uruk") by oss.sgi.com with ESMTP id <S305168AbQDCWff>;
	Mon, 3 Apr 2000 15:35:35 -0700
Received: from localhost (really [127.0.0.1]) by as220.org
	via smail with esmtp
	id <m12cFRT-0002GdC@gilgamesh.uruk> (Debian Smail3.2.0.102)
	for <linux-xfs@oss.sgi.com>; Mon, 3 Apr 2000 18:35:31 -0400 (EDT) 
Date:   Mon, 3 Apr 2000 18:35:30 -0400 (EDT)
From:   Jim Bray <jb@as220.org>
X-Sender: jb@gilgamesh.uruk
To:     Russell Cattelan <cattelan@thebarn.com>
cc:     linux-xfs@oss.sgi.com
Subject: Re: mkfs
In-Reply-To: <38E9124F.44470CF5@thebarn.com>
Message-ID: <Pine.LNX.4.10.10004031833550.585-100000@gilgamesh.uruk>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing

On Mon, 3 Apr 2000, Russell Cattelan wrote:

> If you statically link the binary does it still crash?

  It seems to statically link by default, so yes.

> If so, send me a copy of the binary.

  Will send under separate cover.

Jim	http://as220.org/jb


From owner-linux-xfs@oss.sgi.com Mon Apr  3 15:58:07 2000
Received:  by oss.sgi.com id <S305176AbQDCW55>;
	Mon, 3 Apr 2000 15:57:57 -0700
Received: from rising.starnet.gov.sg ([203.116.82.211]:60323 "EHLO
        rising.starnet.gov.sg") by oss.sgi.com with ESMTP
	id <S305168AbQDCW5f>; Mon, 3 Apr 2000 15:57:35 -0700
Received: from aries (dyn1-166cable.bp1.singa.pore.net [202.169.229.166])
	by rising.starnet.gov.sg (8.9.1/8.9.1) with SMTP id GAA04548;
	Tue, 4 Apr 2000 06:57:29 +0800 (SGT)
Message-ID: <004c01bf9dbf$f0448540$a6e5a9ca@aries>
From:   "Tan Pong Heng" <pongheng@starnet.gov.sg>
To:     "Jim Mostek" <mostek@sgi.com>
Cc:     <linux-xfs@oss.sgi.com>
References: <200004031551.KAA34171@fsgi344.americas.sgi.com>
Subject: Re: XFS as Root
Date:   Tue, 4 Apr 2000 06:57:07 +0800
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.00.2919.6700
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing

Well, I did mind testing it harder - since I have spare hard disk spaces -
so
all the testing partitions are duplicated anyway. If the testing seems to
work,
I will still back up any changes to the important data to the original
partition
for a while before I stop doing that. The fact that using XFS as /usr seems
to
work - that is to say I could boot the machine up, do a gdm login, lauch
netscape
and send a e-mail should have gone thru quite some of the XFS logic path....
I would really like to move my home directory there too. But, the easiest
way
to do it is to move the whole root fs - which does not work. If you could
tell
me what need to be done to get this to work, I will try it. It is a test
machine
anyway...

----- Original Message -----
From: "Jim Mostek" <mostek@sgi.com>
To: "Tan Pong Heng" <pongheng@starnet.gov.sg>
Cc: <linux-xfs@oss.sgi.com>
Sent: Monday, April 03, 2000 11:51 PM
Subject: Re: XFS as Root


>
> You are pushing XFS more than we have internally. We have more development
> yet to do. We don't feel comfortable enough with XFS to use it as /usr or
> any other normal file system, yet. During our testing, we normally
> mkfs a fresh copy, beat on it, fix, ...
>
> Thanks,
>
> Jim
>
> >
> >OK, I tried the alternative - I now have XFS as /usr instead.
> >Everything seems to be fine. It seems that the only problem with
> >using XFS as root is to get the right process going before init start.
> >(Or so I am guessing....)
> >
> >There is one catch though - I am not having /usr/src/linux on this
> >partition yet - as that is on my home directory for CVS update
> >at the moment - that would be /home.
> >
> >Anything specific that you would like me to test?
> >
>


From owner-linux-xfs@oss.sgi.com Mon Apr  3 16:01:17 2000
Received:  by oss.sgi.com id <S305176AbQDCXBH>;
	Mon, 3 Apr 2000 16:01:07 -0700
Received: from rising.starnet.gov.sg ([203.116.82.211]:62627 "EHLO
        rising.starnet.gov.sg") by oss.sgi.com with ESMTP
	id <S305168AbQDCXAu>; Mon, 3 Apr 2000 16:00:50 -0700
Received: from aries (dyn1-166cable.bp1.singa.pore.net [202.169.229.166])
	by rising.starnet.gov.sg (8.9.1/8.9.1) with SMTP id HAA04583;
	Tue, 4 Apr 2000 07:00:45 +0800 (SGT)
Message-ID: <005601bf9dc0$64d9a4d0$a6e5a9ca@aries>
From:   "Tan Pong Heng" <pongheng@starnet.gov.sg>
To:     "Steve Lord" <lord@sgi.com>
Cc:     <linux-xfs@oss.sgi.com>
References: <200004031359.IAA31585@jen.americas.sgi.com>
Subject: Re: XFS as Root filesystem 
Date:   Tue, 4 Apr 2000 07:00:23 +0800
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.00.2919.6700
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing

Already done that, that is why I am certain that the hang occur after the
successful
mount. The last place I checked was in main.c which was trying to do
"exec(init...)"
it never reach the printk after all the possible init path. (Or, it may be
taking too long
for me to notice...)

----- Original Message -----
From: "Steve Lord" <lord@sgi.com>
To: "Tan Pong Heng" <pongheng@starnet.gov.sg>
Cc: <linux-xfs@oss.sgi.com>
Sent: Monday, April 03, 2000 9:59 PM
Subject: Re: XFS as Root filesystem


> > Hi, I did some more testings with using XFS as root filesystem. By
> > inserting some printk
> > into the kernel, I was able to ascertain that the kernel hanged at the
> > last stage of
> > the booting process. It seem to not able to exec the init command. But,
> > it does not
> > seem to have failed to do so, but rather hang there trying.
> >
> > I am not sure how else to debug further, any suggestion?
>
>
> The root filesystem is mounted by mount_root in fs/super.c there is a loop
> which walks through calling read_super for different filesystem types.
> This is probably the place to add printks.
>
> Steve
>
>


From owner-linux-xfs@oss.sgi.com Mon Apr  3 16:08:27 2000
Received:  by oss.sgi.com id <S305176AbQDCXIR>;
	Mon, 3 Apr 2000 16:08:17 -0700
Received: from pneumatic-tube.sgi.com ([204.94.214.22]:14123 "EHLO
        pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP
	id <S305168AbQDCXII>; Mon, 3 Apr 2000 16:08:08 -0700
Received: from ledzep.cray.com (ledzep.cray.com [137.38.226.97]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id QAA09875
	for <linux-xfs@oss.sgi.com>; Mon, 3 Apr 2000 16:11:52 -0700 (PDT)
	mail_from (mostek@sgi.com)
Received: from ironwood-e185.americas.sgi.com (ironwood.cray.com [128.162.185.212]) by ledzep.cray.com (SGI-SGI-8.9.3/craymail-smart-nospam1.0) with ESMTP id SAA40374; Mon, 3 Apr 2000 18:06:47 -0500 (CDT)
Received: from fsgi344.americas.sgi.com (fsgi344.americas.sgi.com [128.162.184.15]) by ironwood-e185.americas.sgi.com (8.8.4/SGI-ironwood-e1.4) with ESMTP id SAA02787; Mon, 3 Apr 2000 18:06:38 -0500 (CDT)
From:   Jim Mostek <mostek@sgi.com>
Received: by fsgi344.americas.sgi.com (980427.SGI.8.8.8/SGI-client.1.6) id SAA34634; Mon, 3 Apr 2000 18:06:44 -0500 (CDT)
Message-Id: <200004032306.SAA34634@fsgi344.americas.sgi.com>
Subject: Re: XFS architecture ?
To:     kenmcd@melbourne.sgi.com (Ken McDonell)
Date:   Mon, 3 Apr 2000 18:06:44 -0500 (CDT)
Cc:     stefan@hanse.com (Stefan Smietanowski),
        linux-xfs@oss.sgi.com (Linux XFS mailinglist)
In-Reply-To: <Pine.SGI.4.10.10004040735500.3397-100000@rattle.melbourne.sgi.com> from "Ken McDonell" at Apr 04, 2000 07:45:23 AM
X-Mailer: ELM [version 2.5 PL2]
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing


Let me strongly disagree with:

>If we end up with (b) this is a
>relatively small additional development effort.

The biggest part would come in all the support/testing/...  on the
different architecture combinations.  If the on-disk format and log format
are all fixed, it greatly simplifies things.

Longer term, with CXFS servers moving between architectures ...

IMHO,

Jim

>
>On Mon, 3 Apr 2000, Stefan Smietanowski wrote:
>> ...
>> 
>> Linux had that before, with Big Endian machines having a Big Endian
>> ext2, but that was dropped before 2.0.0 if I recall correctly, and now
>> all linux machines use a little endian ext2 system. I can't remember the
>> extra overhead needed to switch endianness though ...
>> 
>> If it comes to using different formats based on the native endianness,
>> will the IRIX XFS be extended also to support this feature?
>> 
>> If it doesn't, that would mean that I cannot take my linux XFS partition
>> and move it to the IRIX machine, which imho is one point with running a
>> native XFS system on Linux.
>
>Rest assured.  Our IRIX heritage and the very migration strategy you
>describe mandate that XFS on Linux _will_ support the IRIX MIPS on-disk
>format.
>
>The issue we still have to resolve (and this is the initial objective of the
>endian work) is,
>
>(a) will the XFS on-disk format be the IRIX MIPS format everywhere
>    (the every XFS is big endian model), or
>(b) will the Linux version of XFS support both a little endian on-disk
>    format (what you see today with the released code on Intel
>    platforms), _and_ the IRIX MIPS on-disk format
>
>Note that most of the source code changes and effort go into moving
>from the status today to (a).  If we end up with (b) this is a
>relatively small additional development effort.
>
>The way this work is being done, there may also be another option
>
>(c) make the on-disk format the same as the in memory format ... this
>    is the "convert nothing" model for those who care about nanocycles
>    and don't care about media interoperability or clustered
>    filesystems
>


From owner-linux-xfs@oss.sgi.com Mon Apr  3 16:34:57 2000
Received:  by oss.sgi.com id <S305176AbQDCXeh>;
	Mon, 3 Apr 2000 16:34:37 -0700
Received: from ribbit.CS.Berkeley.EDU ([128.32.131.152]:63673 "EHLO
        ribbit.CS.Berkeley.EDU") by oss.sgi.com with ESMTP
	id <S305168AbQDCXeX>; Mon, 3 Apr 2000 16:34:23 -0700
Received: from localhost (kmacy@localhost)
	by ribbit.CS.Berkeley.EDU (8.9.3/8.9.3) with ESMTP id QAA01994
	for <linux-xfs@oss.sgi.com>; Mon, 3 Apr 2000 16:34:22 -0700 (PDT)
X-Authentication-Warning: ribbit.CS.Berkeley.EDU: kmacy owned process doing -bs
Date:   Mon, 3 Apr 2000 16:34:21 -0700 (PDT)
From:   Kip Macy <kmacy@CS.Berkeley.EDU>
To:     linux-xfs@oss.sgi.com
Subject: Oops on sparse files
Message-ID: <Pine.SOL.4.10.10004031629070.1314-100000@ribbit.CS.Berkeley.EDU>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing

when I type 
> dd if=/dev/zero of=bigfile seek=1024 count=100
I get unable to handle kernel NULL pointer dereference at initial address
0000000c 
printing eip:
c01434dc
*pde=00000000
Entering kdb(0xc22fe000) on processor 0 Panic: Oops
due to panic @0xc01434dc

Then I type:
[0]kdb> bt
with the following response:

pagebuf_get
xfs_zero_last_block
xfs_zero_eof
xfs_igrow_stand
xfs_setattr
linvfs_notify_change
notify_change
do_truncate
sys_ftruncate


This is 100% reproducible.


					-Kip



------------------------------------------------------------------------
Kip Macy                               kmacy@cs.berkeley.edu
University of California, Berkeley     
------------------------------------------------------------------------



From owner-linux-xfs@oss.sgi.com Mon Apr  3 17:03:00 2000
Received:  by oss.sgi.com id <S305176AbQDDACu>;
	Mon, 3 Apr 2000 17:02:50 -0700
Received: from pneumatic-tube.sgi.com ([204.94.214.22]:59956 "EHLO
        pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP
	id <S305168AbQDDACm>; Mon, 3 Apr 2000 17:02:42 -0700
Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via SMTP id RAA00502
	for <linux-xfs@oss.sgi.com>; Mon, 3 Apr 2000 17:06:25 -0700 (PDT)
	mail_from (kenmcd@melbourne.sgi.com)
Received: from rattle.melbourne.sgi.com (rattle.melbourne.sgi.com [134.14.55.145]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id KAA13140; Tue, 4 Apr 2000 10:01:23 +1000
Received: from localhost (kenmcd@localhost) by rattle.melbourne.sgi.com (980427.SGI.8.8.8/980728.SGI.AUTOCF) via ESMTP id KAA04574; Tue, 4 Apr 2000 10:01:20 +1000 (EST)
Date:   Tue, 4 Apr 2000 10:01:20 +1000
From:   Ken McDonell <kenmcd@melbourne.sgi.com>
To:     Jim Mostek <mostek@sgi.com>
cc:     Stefan Smietanowski <stefan@hanse.com>,
        Linux XFS mailinglist <linux-xfs@oss.sgi.com>
Subject: Re: XFS architecture ?
In-Reply-To: <200004032306.SAA34634@fsgi344.americas.sgi.com>
Message-ID: <Pine.SGI.4.10.10004040955050.4328-100000@rattle.melbourne.sgi.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing

On Mon, 3 Apr 2000, Jim Mostek wrote:
> 
> Let me strongly disagree with:
> 
> >If we end up with (b) this is a
> >relatively small additional development effort.
> 
> The biggest part would come in all the support/testing/...  on the
> different architecture combinations.  If the on-disk format and log format
> are all fixed, it greatly simplifies things.

Let me strongly disagree.

OK, Jim and I are in a deadly disagree-disagree embrace now ... 8^)>

Well not really ... I said "small additional _development_ effort".

I should have stressed that beyond the development effort there is:

- code obfuscation and complexity (we need to change internal interfaces
  to push down the "architecture" from the mount structure into places
  it has not been needed before)
- run-time overhead
- testing complexity
- additional support and debugging pain
- log recovery (an unsolved problem)

Jim and I are in a deadly agree-agree embrace on the proposition that
big endian everywhere is the preferred position provided any
performance penalties are acceptably low.


From owner-linux-xfs@oss.sgi.com Mon Apr  3 17:07:29 2000
Received:  by oss.sgi.com id <S305176AbQDDAHU>;
	Mon, 3 Apr 2000 17:07:20 -0700
Received: from pneumatic-tube.sgi.com ([204.94.214.22]:43573 "EHLO
        pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP
	id <S305168AbQDDAHG>; Mon, 3 Apr 2000 17:07:06 -0700
Received: from ledzep.cray.com (ledzep.cray.com [137.38.226.97]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id RAA00670
	for <linux-xfs@oss.sgi.com>; Mon, 3 Apr 2000 17:10:50 -0700 (PDT)
	mail_from (cattelan@thebarn.com)
Received: from ironwood-e185.americas.sgi.com (ironwood.cray.com [128.162.185.212]) by ledzep.cray.com (SGI-SGI-8.9.3/craymail-smart-nospam1.0) with ESMTP id TAA94137; Mon, 3 Apr 2000 19:05:49 -0500 (CDT)
Received: from gibble.americas.sgi.com (root@gibble.americas.sgi.com [128.162.195.80]) by ironwood-e185.americas.sgi.com (8.8.4/SGI-ironwood-e1.4) with ESMTP id TAA03964; Mon, 3 Apr 2000 19:05:41 -0500 (CDT)
Received: from thebarn.com by gibble.americas.sgi.com (8.9.3/SGI-client.1.6) via ESMTP id TAA05133; Mon, 3 Apr 2000 19:05:48 -0500
Message-ID: <38E931DB.FA3631C4@thebarn.com>
Date:   Mon, 03 Apr 2000 19:05:47 -0500
From:   Russell Cattelan <cattelan@thebarn.com>
X-Mailer: Mozilla 4.72 [en] (X11; I; Linux 2.2.14-15mdksmp i686)
X-Accept-Language: en
MIME-Version: 1.0
To:     Kip Macy <kmacy@CS.Berkeley.EDU>
CC:     linux-xfs@oss.sgi.com
Subject: Re: Oops on sparse files
References: <Pine.SOL.4.10.10004031629070.1314-100000@ribbit.CS.Berkeley.EDU>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing

Kip Macy wrote:

> when I type
> > dd if=/dev/zero of=bigfile seek=1024 count=100
> I get unable to handle kernel NULL pointer dereference at initial address
> 0000000c
> printing eip:
> c01434dc
> *pde=00000000
> Entering kdb(0xc22fe000) on processor 0 Panic: Oops
> due to panic @0xc01434dc
>
> Then I type:
> [0]kdb> bt
> with the following response:
>

This area is know to have problems.

When pushing  the end of a file out by seeking out past the current EOF,
XFS creats a hole between the old EOF and the new page that covers
the new EOF, it then needs to zero out the parts of the page
that contain the new EOF.

ie                                         last bock of file in FS units.
this case 4k
|some file data | < hole > |00000... EOF <garbage>|

I'll see if I can track down the exact

>
> pagebuf_get
> xfs_zero_last_block
> xfs_zero_eof
> xfs_igrow_stand
> xfs_setattr
> linvfs_notify_change
> notify_change
> do_truncate
> sys_ftruncate
>
> This is 100% reproducible.
>
>                                         -Kip
>
> ------------------------------------------------------------------------
> Kip Macy                               kmacy@cs.berkeley.edu
> University of California, Berkeley
> ------------------------------------------------------------------------


From owner-linux-xfs@oss.sgi.com Mon Apr  3 17:39:00 2000
Received:  by oss.sgi.com id <S305176AbQDDAiu>;
	Mon, 3 Apr 2000 17:38:50 -0700
Received: from deliverator.sgi.com ([204.94.214.10]:5137 "EHLO
        deliverator.sgi.com") by oss.sgi.com with ESMTP id <S305168AbQDDAiY>;
	Mon, 3 Apr 2000 17:38:24 -0700
Received: from ledzep.cray.com (ledzep.cray.com [137.38.226.97]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id RAA08580
	for <linux-xfs@oss.sgi.com>; Mon, 3 Apr 2000 17:33:42 -0700 (PDT)
	mail_from (cattelan@thebarn.com)
From:   cattelan@thebarn.com
Received: from ironwood-e185.americas.sgi.com (ironwood.cray.com [128.162.185.212]) by ledzep.cray.com (SGI-SGI-8.9.3/craymail-smart-nospam1.0) with ESMTP id TAA05063; Mon, 3 Apr 2000 19:35:52 -0500 (CDT)
Received: from gibble.americas.sgi.com (root@gibble.americas.sgi.com [128.162.195.80]) by ironwood-e185.americas.sgi.com (8.8.4/SGI-ironwood-e1.4) with ESMTP id TAA04350; Mon, 3 Apr 2000 19:35:45 -0500 (CDT)
Received: from gibble.americas.sgi.com by gibble.americas.sgi.com (8.9.3/SGI-client.1.6) via ESMTP id TAA05298; Mon, 3 Apr 2000 19:35:52 -0500
Date:   Mon, 03 Apr 2000 19:35:50 -0500
Message-ID: <14569.14566.772170.68040W@gibble.americas.sgi.com>
To:     jb@as220.org
Cc:     linux-xfs@oss.sgi.com
Subject: Re: mkfs
In-Reply-To: In your message of "Mon, 3 Apr 2000 18:35:30 -0400 (EDT)"
	<Pine.LNX.4.10.10004031833550.585-100000@gilgamesh.uruk>
References: <38E9124F.44470CF5@thebarn.com>
	<Pine.LNX.4.10.10004031833550.585-100000@gilgamesh.uruk>
User-Agent: Wanderlust/1.0.3 (Notorious) tm/7.108 XEmacs/21.1 (Bryce Canyon)
Mime-Version: 1.0 (generated by tm-edit 7.108)
Content-Type: text/plain; charset=US-ASCII
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing

One more question...
what version of gcc are you using?



From owner-linux-xfs@oss.sgi.com Mon Apr  3 18:09:49 2000
Received:  by oss.sgi.com id <S305176AbQDDBJk>;
	Mon, 3 Apr 2000 18:09:40 -0700
Received: from deliverator.sgi.com ([204.94.214.10]:60950 "EHLO
        deliverator.sgi.com") by oss.sgi.com with ESMTP id <S305168AbQDDBJQ>;
	Mon, 3 Apr 2000 18:09:16 -0700
Received: from ledzep.cray.com (ledzep.cray.com [137.38.226.97]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id SAA11454
	for <linux-xfs@oss.sgi.com>; Mon, 3 Apr 2000 18:04:34 -0700 (PDT)
	mail_from (lord@sgi.com)
Received: from ironwood-e185.americas.sgi.com (ironwood.cray.com [128.162.185.212]) by ledzep.cray.com (SGI-SGI-8.9.3/craymail-smart-nospam1.0) with ESMTP id UAA96298; Mon, 3 Apr 2000 20:06:43 -0500 (CDT)
Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.184.86]) by ironwood-e185.americas.sgi.com (8.8.4/SGI-ironwood-e1.4) with ESMTP id UAA05151; Mon, 3 Apr 2000 20:06:35 -0500 (CDT)
From:   Steve Lord <lord@sgi.com>
Received: from jen.americas.sgi.com by jen.americas.sgi.com (8.9.3/SGI-client.1.6) via ESMTP id UAA07079; Mon, 3 Apr 2000 20:06:07 -0500
Message-Id: <200004040106.UAA07079@jen.americas.sgi.com>
To:     jb@as220.org, linux-xfs@oss.sgi.com
Subject: Re: mkfs 
In-reply-to: Your message of "Mon, 03 Apr 2000 19:35:50 CDT
Date:   Mon, 03 Apr 2000 20:06:07 -0500
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing

> One more question...
> what version of gcc are you using?
> 

I could throw one more suggestion in here, do a make clean in the
commands tree (cmd/xfs) and build them from scratch. If you have
built once, done a cvs update to get new code and then rebuilt
there could be problems, the command tree does not have any dependency
checking built in. If you have not done this then ignore the
suggestion.

Steve



From owner-linux-xfs@oss.sgi.com Mon Apr  3 18:19:40 2000
Received:  by oss.sgi.com id <S305176AbQDDBTa>;
	Mon, 3 Apr 2000 18:19:30 -0700
Received: from mailrelay.acsu.buffalo.edu ([128.205.7.101]:51886 "HELO
        mailrelay.acsu.buffalo.edu") by oss.sgi.com with SMTP
	id <S305168AbQDDBTK>; Mon, 3 Apr 2000 18:19:10 -0700
Received: (qmail 10151 invoked from network); 4 Apr 2000 01:19:06 -0000
Received: from ubppp-245-010.ppp-net.buffalo.edu (128.205.245.10)
  by mailrelay with SMTP; 4 Apr 2000 01:19:06 -0000
Date:   Mon, 3 Apr 2000 21:20:17 -0400 (EDT)
From:   James Simmons <jsimmons@acsu.buffalo.edu>
X-Sender: jsimmons@maxwell.futurevision.com
To:     Andi Kleen <ak@suse.de>
cc:     Ken McDonell <kenmcd@melbourne.sgi.com>,
        Stefan Smietanowski <stefan@hanse.com>,
        Linux XFS mailinglist <linux-xfs@oss.sgi.com>
Subject: Re: XFS architecture ?
In-Reply-To: <20000403235842.A30564@gruyere.muc.suse.de>
Message-ID: <Pine.LNX.4.10.10004032118380.834-100000@maxwell.futurevision.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing


On Mon, 3 Apr 2000, Andi Kleen wrote:

> On Tue, Apr 04, 2000 at 07:45:23AM +1000, Ken McDonell wrote:
> > (b) will the Linux version of XFS support both a little endian on-disk
> >     format (what you see today with the released code on Intel
> >     platforms), _and_ the IRIX MIPS on-disk format
> 
> Switching endians is very cheap on modern CPUs (ppro+ have a special
> instruction, ultrasparc/ia64/et.al. have special bits in the store
> instructions to store both endians). What is expensive is checking
> whether you need to switch (or rather, it is not that expensive at runtime,
> but bloats the code/binary a lot because a lot of routines will be duplicated)
> 
> Big-Endian XFS everywhere probably makes sense.  TCP/IP has proven that it 
> is possible :-) 

I agree. Keep it big endian. The world (except intel) uses big endian.

"Look it's a text editor, no it's a OS, no it's Emacs"
James Simmons                                           ____/| 
fbdev/gfx developer                                     \ o.O| 
http://www.linux-fbdev.org                               =(_)= 
http://linuxgfx.sourceforge.net                            U


From owner-linux-xfs@oss.sgi.com Mon Apr  3 18:28:20 2000
Received:  by oss.sgi.com id <S305176AbQDDB2B>;
	Mon, 3 Apr 2000 18:28:01 -0700
Received: from mailrelay.acsu.buffalo.edu ([128.205.7.101]:62126 "HELO
        mailrelay.acsu.buffalo.edu") by oss.sgi.com with SMTP
	id <S305168AbQDDB1x>; Mon, 3 Apr 2000 18:27:53 -0700
Received: (qmail 10506 invoked from network); 4 Apr 2000 01:27:49 -0000
Received: from ubppp-245-010.ppp-net.buffalo.edu (128.205.245.10)
  by mailrelay with SMTP; 4 Apr 2000 01:27:49 -0000
Date:   Mon, 3 Apr 2000 21:29:00 -0400 (EDT)
From:   James Simmons <jsimmons@acsu.buffalo.edu>
X-Sender: jsimmons@maxwell.futurevision.com
To:     Linux XFS Mailing List <linux-xfs@oss.sgi.com>
Subject: questions
Message-ID: <Pine.LNX.4.10.10004032126440.943-100000@maxwell.futurevision.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing


What is CXFS ?

Where can I find some documentation on B+ trees?

"Look it's a text editor, no it's a OS, no it's Emacs"
James Simmons                                           ____/| 
fbdev/gfx developer                                     \ o.O| 
http://www.linux-fbdev.org                               =(_)= 
http://linuxgfx.sourceforge.net                            U


From owner-linux-xfs@oss.sgi.com Mon Apr  3 19:30:50 2000
Received:  by oss.sgi.com id <S305176AbQDDCal>;
	Mon, 3 Apr 2000 19:30:41 -0700
Received: from cranston-ip-2-190.dynamic.ziplink.net ([209.206.5.190]:6404
        "EHLO gilgamesh.uruk") by oss.sgi.com with ESMTP id <S305168AbQDDCa2>;
	Mon, 3 Apr 2000 19:30:28 -0700
Received: from localhost (really [127.0.0.1]) by as220.org
	via smail with esmtp
	id <m12cJ6m-0002GdC@gilgamesh.uruk> (Debian Smail3.2.0.102)
	for <linux-xfs@oss.sgi.com>; Mon, 3 Apr 2000 22:30:24 -0400 (EDT) 
Date:   Mon, 3 Apr 2000 22:30:23 -0400 (EDT)
From:   Jim Bray <jb@as220.org>
X-Sender: jb@gilgamesh.uruk
To:     Steve Lord <lord@sgi.com>
cc:     linux-xfs@oss.sgi.com
Subject: Re: mkfs 
In-Reply-To: <200004040106.UAA07079@jen.americas.sgi.com>
Message-ID: <Pine.LNX.4.10.10004032227520.387-100000@gilgamesh.uruk>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing

On Mon, 3 Apr 2000, Steve Lord wrote:

> > One more question...
> > what version of gcc are you using?

2.95.2

> > 
> 
> I could throw one more suggestion in here, do a make clean in the
> commands tree (cmd/xfs) and build them from scratch.

  I did a make clean in cmd/xfs before, but since it seems to be including
things from ../sim (and playing odd games with _KERNEL), I'll go do a
fresh update and remake the whole thing from scratch.

Jim	http://as220.org/jb



From owner-linux-xfs@oss.sgi.com Mon Apr  3 19:40:20 2000
Received:  by oss.sgi.com id <S305176AbQDDCkB>;
	Mon, 3 Apr 2000 19:40:01 -0700
Received: from deliverator.sgi.com ([204.94.214.10]:52259 "EHLO
        deliverator.sgi.com") by oss.sgi.com with ESMTP id <S305168AbQDDCjt>;
	Mon, 3 Apr 2000 19:39:49 -0700
Received: from ledzep.cray.com (ledzep.cray.com [137.38.226.97]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id TAA17982
	for <linux-xfs@oss.sgi.com>; Mon, 3 Apr 2000 19:35:07 -0700 (PDT)
	mail_from (lord@sgi.com)
Received: from ironwood-e185.americas.sgi.com (ironwood.cray.com [128.162.185.212]) by ledzep.cray.com (SGI-SGI-8.9.3/craymail-smart-nospam1.0) with ESMTP id VAA95356; Mon, 3 Apr 2000 21:38:32 -0500 (CDT)
Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.184.86]) by ironwood-e185.americas.sgi.com (8.8.4/SGI-ironwood-e1.4) with ESMTP id VAA06949; Mon, 3 Apr 2000 21:38:24 -0500 (CDT)
From:   Steve Lord <lord@sgi.com>
Received: from jen.americas.sgi.com by jen.americas.sgi.com (8.9.3/SGI-client.1.6) via ESMTP id VAA07607; Mon, 3 Apr 2000 21:37:55 -0500
Message-Id: <200004040237.VAA07607@jen.americas.sgi.com>
To:     James Simmons <jsimmons@acsu.buffalo.edu>
cc:     Linux XFS Mailing List <linux-xfs@oss.sgi.com>
Subject: Re: questions 
In-reply-to: Your message of "Mon, 03 Apr 2000 21:29:00 EDT
Date:   Mon, 03 Apr 2000 21:37:55 -0500
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing

> 
> What is CXFS ?

CXFS is a cluster version of XFS - using fiber channel disks, multiple
machines can have direct access to the filesystem. User data is transferred
direct between the disk and buffer cache / user memory on each host,
meta-data changes are performed on a designated server node. Data
coherency is managed between machines via a token passing protocol.
CXFS supports server failover and relocation - should the server crash
a client node takes over as the server - all the other clients are
redirected to the new server, you can also administratively move the
server. All of which can be done without stopping processes using the
filesystem.

It is currently only available for Irix, it is planned to port it to
Linux, but it is not clear if it will be open source or not. SGI's
external website seems not to say much about it...

> 
> Where can I find some documentation on B+ trees?

Good question - I tend to just use the code, but someone must
have a reference.

Steve

> 
> "Look it's a text editor, no it's a OS, no it's Emacs"
> James Simmons                                           ____/| 
> fbdev/gfx developer                                     \ o.O| 
> http://www.linux-fbdev.org                               =(_)= 
> http://linuxgfx.sourceforge.net                            U

From owner-linux-xfs@oss.sgi.com Mon Apr  3 19:43:20 2000
Received:  by oss.sgi.com id <S305176AbQDDCnA>;
	Mon, 3 Apr 2000 19:43:00 -0700
Received: from timbuk-fddi.cray.com ([128.162.8.102]:17810 "EHLO
        timbuk.cray.com") by oss.sgi.com with ESMTP id <S305168AbQDDCmr>;
	Mon, 3 Apr 2000 19:42:47 -0700
Received: from clink.americas.sgi.com (clink.cray.com [128.162.84.70]) by timbuk.cray.com (8.8.8/CRI-gate-news-1.3) with ESMTP id VAA18868; Mon, 3 Apr 2000 21:42:43 -0500 (CDT)
Received: (from lord@localhost) by clink.americas.sgi.com (980427.SGI.8.8.8/CRI-news-1.3) id VAA86083; Mon, 3 Apr 2000 21:42:44 -0500 (CDT)
Date:   Mon, 3 Apr 2000 21:42:44 -0500 (CDT)
From:   Steve Lord <lord@sgi.com>
Message-Id: <200004040242.VAA86083@clink.americas.sgi.com>
To:     linux-xfs@oss.sgi.com
Cc:     kmacy@cs.berkeley.edu
Subject: TAKE - fix xfs_zero_eof bug with sparse files
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing

xfs_zero_eof got reimplemnted with a nwe callign interface,
but a couple of old calls remain. Fix it so that evryone
speaks the same lingo. Thanks to Kip Macy for reporting
this.

Modid:  2.3.99pre2-xfs:slinx:56556a
Date:  Mon Apr  3 19:40:50 PDT 2000
Workarea:  clink.americas.sgi.com:/data/clink/io/lord/slinx-xfs-2.3.99pre2

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

linux/fs/xfs/linux/xfs_lrw.c - 1.31
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/linux/fs/xfs/linux/xfs_lrw.c.diff?r1=text&tr1=1.31&r2=text&tr2=1.30&f=h
	- Change xfs_zero_eof to take a vnode rather than an inode
	  so that all the callers pass it the same thing!


From owner-linux-xfs@oss.sgi.com Mon Apr  3 20:24:40 2000
Received:  by oss.sgi.com id <S305176AbQDDDYV>;
	Mon, 3 Apr 2000 20:24:21 -0700
Received: from hamming.resophonic.com ([216.25.148.18]:36873 "EHLO
        hamming.resophonic.com") by oss.sgi.com with ESMTP
	id <S305168AbQDDDXy>; Mon, 3 Apr 2000 20:23:54 -0700
Received: (from ph0n1c@localhost)
	by hamming.resophonic.com (8.10.0/8.9.3) id e343Ngu04183;
	Mon, 3 Apr 2000 23:23:42 -0400
Date:   Mon, 3 Apr 2000 23:23:42 -0400
Message-Id: <200004040323.e343Ngu04183@hamming.resophonic.com>
From:   ph0n1c <ph0n1c@resophonic.com>
To:     linux-xfs@oss.sgi.com
In-reply-to: <200004040237.VAA07607@jen.americas.sgi.com> (message from Steve
	Lord on Mon, 03 Apr 2000 21:37:55 -0500)
Subject: B+-trees
References:  <200004040237.VAA07607@jen.americas.sgi.com>
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing

> > Where can I find some documentation on B+ trees?
> 
> Good question - I tend to just use the code, but someone must
> have a reference.
> 

Here's a definition...

http://hissa.nist.gov/~black/CRCDict/HTML/bplustree.html

For further reading I'd probably start (and end?) with Knuth's "The
Art of Computer Programming".  Good textbooks on Algorithms should
have some discussion.

-Troy

From owner-linux-xfs@oss.sgi.com Mon Apr  3 20:29:40 2000
Received:  by oss.sgi.com id <S305196AbQDDD3V>;
	Mon, 3 Apr 2000 20:29:21 -0700
Received: from cranston-ip-1-231.dynamic.ziplink.net ([209.206.4.231]:20996
        "EHLO gilgamesh.uruk") by oss.sgi.com with ESMTP id <S305168AbQDDD3C>;
	Mon, 3 Apr 2000 20:29:02 -0700
Received: from localhost (really [127.0.0.1]) by as220.org
	via smail with esmtp
	id <m12cK1N-0002GZC@gilgamesh.uruk> (Debian Smail3.2.0.102)
	for <linux-xfs@oss.sgi.com>; Mon, 3 Apr 2000 23:28:53 -0400 (EDT) 
Date:   Mon, 3 Apr 2000 23:28:53 -0400 (EDT)
From:   Jim Bray <jb@as220.org>
X-Sender: jb@gilgamesh.uruk
To:     Russell Cattelan <cattelan@thebarn.com>, Steve Lord <lord@sgi.com>
cc:     linux-xfs@oss.sgi.com
Subject: Re: several messages
In-Reply-To: <200004040106.UAA07079@jen.americas.sgi.com>
Message-ID: <Pine.LNX.4.10.10004032248100.387-100000@gilgamesh.uruk>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing

On Mon, 3 Apr 2000, Russell Cattelan wrote:

> remake mkfs and send me the new binary.

  May not be necessary: at least I'm getting something sensible now:

program received signal SIGSEGV, Segmentation fault.
0x8049d5e in main (argc=2, argv=0xbffffc74) at xfs_mkfs.c:1195
1195			if (logfile && *logfile) {
(gdb) x logfile
0x1:	Cannot access memory at address 0x1.

  logfile is a stack variable, and looks like it is getting used before
set. added an '=(char*)0' after the declaration, and we get past that
crash, and on to the other one, which looks the same... yeah, it looks
like this is still blowing the stack somehow in uuid_create. This is
actually in kernel code which is wired with ifdefs so it can be shared
with the utilities (....?); also, it seems pretty clear that the
#ifdef _KERNEL version of uuid_create is being used instead of the user
version, which at first glance might seem more apropos.

  Anyways, I'll send Russell a fresh binary. BTW, in case my static libc
had gotten blown (I don't use it much), I recompiled without -static and
got the same crash.

Jim	http://as220.org/jb


From owner-linux-xfs@oss.sgi.com Mon Apr  3 21:17:41 2000
Received:  by oss.sgi.com id <S305210AbQDDERX>;
	Mon, 3 Apr 2000 21:17:23 -0700
Received: from cranston-ip-1-231.dynamic.ziplink.net ([209.206.4.231]:2053
        "EHLO gilgamesh.uruk") by oss.sgi.com with ESMTP id <S305168AbQDDEQ4>;
	Mon, 3 Apr 2000 21:16:56 -0700
Received: from localhost (really [127.0.0.1]) by as220.org
	via smail with esmtp
	id <m12cKlo-0002GZC@gilgamesh.uruk> (Debian Smail3.2.0.102)
	for <linux-xfs@oss.sgi.com>; Tue, 4 Apr 2000 00:16:52 -0400 (EDT) 
Date:   Tue, 4 Apr 2000 00:16:52 -0400 (EDT)
From:   Jim Bray <jb@as220.org>
X-Sender: jb@gilgamesh.uruk
To:     Russell Cattelan <cattelan@thebarn.com>, Steve Lord <lord@sgi.com>
cc:     linux-xfs@oss.sgi.com
Subject: mkfs and xfs working
In-Reply-To: <Pine.LNX.4.10.10004032248100.387-100000@gilgamesh.uruk>
Message-ID: <Pine.LNX.4.10.10004040014300.12566-100000@gilgamesh.uruk>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing


  A new cvs update and total rebuild has got this working. I made an xfs
fs, mounted it, copied my mp3s (about .3 gb) to it and am playing them. So
far so good. Maybe I'll copy mozilla over and build it. That should be a
good workout.

 Jim	http://as220.org/jb
 
            "			"
	     \   ____/|        / 
	      \  \ o.O|      /
	       \  =(_)=    /
		\   U    /       
		 \  |  / 
		  \ #/
	
              ACK! PHTHPHTH!
	   "I am not a crook!"


From owner-linux-xfs@oss.sgi.com Mon Apr  3 21:31:41 2000
Received:  by oss.sgi.com id <S305211AbQDDEbW>;
	Mon, 3 Apr 2000 21:31:22 -0700
Received: from cranston-ip-1-108.dynamic.ziplink.net ([209.206.4.108]:2564
        "EHLO gilgamesh.uruk") by oss.sgi.com with ESMTP id <S305168AbQDDEbN>;
	Mon, 3 Apr 2000 21:31:13 -0700
Received: from localhost (really [127.0.0.1]) by as220.org
	via smail with esmtp
	id <m12cKzd-0002GZC@gilgamesh.uruk> (Debian Smail3.2.0.102)
	for <linux-xfs@oss.sgi.com>; Tue, 4 Apr 2000 00:31:09 -0400 (EDT) 
Date:   Tue, 4 Apr 2000 00:31:09 -0400 (EDT)
From:   Jim Bray <jb@as220.org>
X-Sender: jb@gilgamesh.uruk
To:     linux-xfs@oss.sgi.com
Subject: Re: xfs working
In-Reply-To: <Pine.LNX.4.10.10004040014300.12566-100000@gilgamesh.uruk>
Message-ID: <Pine.LNX.4.10.10004040024280.12566-100000@gilgamesh.uruk>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing

On Tue, 4 Apr 2000, Jim Bray wrote:

  Tried to rm something on /xfs and when that hung tried to ls it. Now I
have an rm and an ls in uninterruptible sleep on waitchan 'down'....
had to reboot... so stil not perfect, but at least it didn't wipe root on
me... I really should do a backup soon...

Jim	http://as220.org/jb
 
            "			"
	     \   ____/|        / 
	      \  \ o.O|      /
	       \  =(_)=    /
		\   U    /       
		 \  |  / 
		  \ #/
	
              ACK! PHTHPHTH!
	   "I am not a crook!"


From owner-linux-xfs@oss.sgi.com Mon Apr  3 21:59:12 2000
Received:  by oss.sgi.com id <S305212AbQDDE7C>;
	Mon, 3 Apr 2000 21:59:02 -0700
Received: from ribbit.CS.Berkeley.EDU ([128.32.131.152]:11457 "EHLO
        ribbit.CS.Berkeley.EDU") by oss.sgi.com with ESMTP
	id <S305168AbQDDE6h>; Mon, 3 Apr 2000 21:58:37 -0700
Received: from localhost (kmacy@localhost)
	by ribbit.CS.Berkeley.EDU (8.9.3/8.9.3) with ESMTP id VAA06806;
	Mon, 3 Apr 2000 21:58:32 -0700 (PDT)
X-Authentication-Warning: ribbit.CS.Berkeley.EDU: kmacy owned process doing -bs
Date:   Mon, 3 Apr 2000 21:58:32 -0700 (PDT)
From:   Kip Macy <kmacy@CS.Berkeley.EDU>
To:     Steve Lord <lord@sgi.com>
cc:     linux-xfs@oss.sgi.com
Subject: Re: TAKE - fix xfs_zero_eof bug with sparse files
In-Reply-To: <200004040242.VAA86083@clink.americas.sgi.com>
Message-ID: <Pine.SOL.4.10.10004032156430.6457-100000@ribbit.CS.Berkeley.EDU>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing

That was fast. I wish all my bugs got fixed this quickly.

				-Kip
------------------------------------------------------------------------
Kip Macy                               kmacy@cs.berkeley.edu
University of California, Berkeley     
------------------------------------------------------------------------


On Mon, 3 Apr 2000, Steve Lord wrote:

> xfs_zero_eof got reimplemnted with a nwe callign interface,
> but a couple of old calls remain. Fix it so that evryone
> speaks the same lingo. Thanks to Kip Macy for reporting
> this.
> 
> Modid:  2.3.99pre2-xfs:slinx:56556a
> Date:  Mon Apr  3 19:40:50 PDT 2000
> Workarea:  clink.americas.sgi.com:/data/clink/io/lord/slinx-xfs-2.3.99pre2
> 
> The following file(s) were checked into:
>   bonnie.engr.sgi.com:/isms/slinx/2.3.99pre2-xfs
> 
> linux/fs/xfs/linux/xfs_lrw.c - 1.31
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/> linux/fs/xfs/linux/xfs_lrw.c.diff?r1=text&tr1=1.31&r2=text&tr2=1.30&f=h
> 	- Change xfs_zero_eof to take a vnode rather than an inode
> 	  so that all the callers pass it the same thing!
> 


From owner-linux-xfs@oss.sgi.com Mon Apr  3 22:01:02 2000
Received:  by oss.sgi.com id <S305216AbQDDFAm>;
	Mon, 3 Apr 2000 22:00:42 -0700
Received: from lips.borg.umn.edu ([160.94.232.50]:4 "EHLO lips.borg.umn.edu")
	by oss.sgi.com with ESMTP id <S305168AbQDDFAX>;
	Mon, 3 Apr 2000 22:00:23 -0700
Received: from thebarn.com (dhp.lcse.umn.edu [160.94.231.41])
	by lips.borg.umn.edu (8.10.0/8.10.0) with ESMTP id e3450K399532;
	Tue, 4 Apr 2000 00:00:21 -0500 (CDT)
Message-ID: <38E976E3.BC866FD2@thebarn.com>
Date:   Tue, 04 Apr 2000 00:00:19 -0500
From:   Russell Cattelan <cattelan@thebarn.com>
X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 4.0-STABLE i386)
X-Accept-Language: en
MIME-Version: 1.0
To:     Jim Bray <jb@as220.org>
CC:     linux-xfs@oss.sgi.com
Subject: Re: xfs working
References: <Pine.LNX.4.10.10004040024280.12566-100000@gilgamesh.uruk>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing

Jim Bray wrote:

> On Tue, 4 Apr 2000, Jim Bray wrote:
>
>   Tried to rm something on /xfs and when that hung tried to ls it. Now I
> have an rm and an ls in uninterruptible sleep on waitchan 'down'....
> had to reboot... so stil not perfect, but at least it didn't wipe root on
> me... I really should do a backup soon...

We do have a ways to go.
Thing are not fully implemented yet.


>
>
> Jim     http://as220.org/jb
>
>             "                   "
>              \   ____/|        /
>               \  \ o.O|      /
>                \  =(_)=    /
>                 \   U    /
>                  \  |  /
>                   \ #/
>
>               ACK! PHTHPHTH!
>            "I am not a crook!"

--
Russell Cattelan
cattelan@thebarn.com




From owner-linux-xfs@oss.sgi.com Tue Apr  4 08:14:21 2000
Received:  by oss.sgi.com id <S305196AbQDDPOL>;
	Tue, 4 Apr 2000 08:14:11 -0700
Received: from ribbit.CS.Berkeley.EDU ([128.32.131.152]:42187 "EHLO
        ribbit.CS.Berkeley.EDU") by oss.sgi.com with ESMTP
	id <S305176AbQDDPOA>; Tue, 4 Apr 2000 08:14:00 -0700
Received: from localhost (kmacy@localhost)
	by ribbit.CS.Berkeley.EDU (8.9.3/8.9.3) with ESMTP id IAA08534;
	Tue, 4 Apr 2000 08:14:00 -0700 (PDT)
X-Authentication-Warning: ribbit.CS.Berkeley.EDU: kmacy owned process doing -bs
Date:   Tue, 4 Apr 2000 08:14:00 -0700 (PDT)
From:   Kip Macy <kmacy@CS.Berkeley.EDU>
To:     Steve Lord <lord@sgi.com>
cc:     linux-xfs@oss.sgi.com
Subject: CVS mirroring was Re: TAKE - fix xfs_zero_eof bug with sparse files
In-Reply-To: <200004040242.VAA86083@clink.americas.sgi.com>
Message-ID: <Pine.SOL.4.10.10004040810290.8513-100000@ribbit.CS.Berkeley.EDU>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing

When does the external CVS end up getting updated? The fix you mentioned below
is, as far as I can tell, still not visible. Thanks.


				-Kip

------------------------------------------------------------------------
Kip Macy                               kmacy@cs.berkeley.edu
University of California, Berkeley     
------------------------------------------------------------------------


On Mon, 3 Apr 2000, Steve Lord wrote:

> xfs_zero_eof got reimplemnted with a nwe callign interface,
> but a couple of old calls remain. Fix it so that evryone
> speaks the same lingo. Thanks to Kip Macy for reporting
> this.
> 
> Modid:  2.3.99pre2-xfs:slinx:56556a
> Date:  Mon Apr  3 19:40:50 PDT 2000
> Workarea:  clink.americas.sgi.com:/data/clink/io/lord/slinx-xfs-2.3.99pre2
> 
> The following file(s) were checked into:
>   bonnie.engr.sgi.com:/isms/slinx/2.3.99pre2-xfs
> 
> linux/fs/xfs/linux/xfs_lrw.c - 1.31
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/> linux/fs/xfs/linux/xfs_lrw.c.diff?r1=text&tr1=1.31&r2=text&tr2=1.30&f=h
> 	- Change xfs_zero_eof to take a vnode rather than an inode
> 	  so that all the callers pass it the same thing!
> 


From owner-linux-xfs@oss.sgi.com Tue Apr  4 08:15:22 2000
Received:  by oss.sgi.com id <S305210AbQDDPPM>;
	Tue, 4 Apr 2000 08:15:12 -0700
Received: from pneumatic-tube.sgi.com ([204.94.214.22]:20324 "EHLO
        pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP
	id <S305176AbQDDPPF>; Tue, 4 Apr 2000 08:15:05 -0700
Received: from ledzep.cray.com (ledzep.cray.com [137.38.226.97]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id IAA05548
	for <linux-xfs@oss.sgi.com>; Tue, 4 Apr 2000 08:18:49 -0700 (PDT)
	mail_from (mostek@sgi.com)
Received: from ironwood-e185.americas.sgi.com (ironwood.cray.com [128.162.185.212]) by ledzep.cray.com (SGI-SGI-8.9.3/craymail-smart-nospam1.0) with ESMTP id KAA04802; Tue, 4 Apr 2000 10:13:46 -0500 (CDT)
Received: from fsgi344.americas.sgi.com (fsgi344.americas.sgi.com [128.162.184.15]) by ironwood-e185.americas.sgi.com (8.8.4/SGI-ironwood-e1.4) with ESMTP id KAA01829; Tue, 4 Apr 2000 10:13:39 -0500 (CDT)
From:   Jim Mostek <mostek@sgi.com>
Received: by fsgi344.americas.sgi.com (980427.SGI.8.8.8/SGI-client.1.6) id KAA36957; Tue, 4 Apr 2000 10:13:45 -0500 (CDT)
Message-Id: <200004041513.KAA36957@fsgi344.americas.sgi.com>
Subject: Re: Correctness
To:     slinx-xfs@engr.sgi.com, linux-xfs@oss.sgi.com
Date:   Tue, 4 Apr 2000 10:13:44 -0500 (CDT)
In-Reply-To: <38E3F457.EC1DA237@sgi.com> from "Rajagopal Ananthanarayanan" at Mar 30, 2000 04:41:59 PM
X-Mailer: ELM [version 2.5 PL2]
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing


There are several main features yet to do in the XFS port:

	1.) delayed allocate (Jim/Ananth)
	2.) Direct I/O (I think Steve is picking this one up)
	3.) complete the switch over to pagebufs (Russell)
	4.) Fix lower interface so that we don't need buffer_heads in
		all cases. (Chait)
	5.) eliminate "corruption" (Russell, others?)
		i. Steve has reported corruption with pagebuf metadata.
			3 should solve that
		ii. locking is a problem that we know can lead doio into
			corruption.

			scenario

			one thread does a large write converting a hole
			the pagebuf_bmap returns NEW
			this thread will zero out part of the last page
				covering the hole (which it isn't writing)
			
			another thread page_faults on the range containing
			the last page, writes it, ...

			later the first thread zeros out what the page_fault did.

			This can be fixed by grabbing the I/O lock in the
			page_fault path, but this resurects the bug from hell.
			...

		iii. is there other corruption?
	6.) syssgi()/fcntls() ... (Ted)
	7.) user commands/dump/restore/   Ken's team
	8.) LFS/Volume managers (Linuxcare)

	I'm probably missing a few, but these seem to be the highest priority
for now. (The above are not in any particular priority order. They just
popped into my head this way. My head tends to operate in a rather random fashion).

I think we need to stop thinking about performance until we have the above
completed. On the other hand, we need to keep fixing bugs/problems that
the "community" reports.

IMHO,

Jim

From owner-linux-xfs@oss.sgi.com Tue Apr  4 08:18:21 2000
Received:  by oss.sgi.com id <S305210AbQDDPSM>;
	Tue, 4 Apr 2000 08:18:12 -0700
Received: from pneumatic-tube.sgi.com ([204.94.214.22]:62308 "EHLO
        pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP
	id <S305176AbQDDPRw>; Tue, 4 Apr 2000 08:17:52 -0700
Received: from ledzep.cray.com (ledzep.cray.com [137.38.226.97]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id IAA09639
	for <linux-xfs@oss.sgi.com>; Tue, 4 Apr 2000 08:21:37 -0700 (PDT)
	mail_from (lord@sgi.com)
Received: from ironwood-e185.americas.sgi.com (ironwood.cray.com [128.162.185.212]) by ledzep.cray.com (SGI-SGI-8.9.3/craymail-smart-nospam1.0) with ESMTP id KAA72584; Tue, 4 Apr 2000 10:16:34 -0500 (CDT)
Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.184.86]) by ironwood-e185.americas.sgi.com (8.8.4/SGI-ironwood-e1.4) with ESMTP id KAA01984; Tue, 4 Apr 2000 10:16:26 -0500 (CDT)
Received: from jen.americas.sgi.com by jen.americas.sgi.com (8.9.3/SGI-client.1.6) via ESMTP id KAA08054; Tue, 4 Apr 2000 10:16:32 -0500
Message-Id: <200004041516.KAA08054@jen.americas.sgi.com>
X-Mailer: exmh version 2.1.1 10/15/1999
To:     Kip Macy <kmacy@CS.Berkeley.EDU>
cc:     Steve Lord <lord@sgi.com>, linux-xfs@oss.sgi.com
Subject: Re: CVS mirroring was Re: TAKE - fix xfs_zero_eof bug with sparse 
 files
In-Reply-To: Message from Kip Macy <kmacy@CS.Berkeley.EDU> 
   of "Tue, 04 Apr 2000 08:14:00 PDT." <Pine.SOL.4.10.10004040810290.8513-100000@ribbit.CS.Berkeley.EDU> 
Date:   Tue, 04 Apr 2000 10:16:31 -0500
From:   Steve Lord <lord@sgi.com>
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing

> When does the external CVS end up getting updated? The fix you mentioned belo
w
> is, as far as I can tell, still not visible. Thanks.
> 
> 
> 				-Kip
> 
> ------------------------------------------------------------------------
> Kip Macy                               kmacy@cs.berkeley.edu
> University of California, Berkeley     
> ------------------------------------------------------------------------
> 

CVS mirroring is supposed to be happening automatically a couple of times
a day - I am not sure it has really become automatic yet, we may still
be functioning on manual updates. In theory it should have happened last
night about midnight CST.

Steve



From owner-linux-xfs@oss.sgi.com Tue Apr  4 08:35:43 2000
Received:  by oss.sgi.com id <S305196AbQDDPfe>;
	Tue, 4 Apr 2000 08:35:34 -0700
Received: from lips.borg.umn.edu ([160.94.232.50]:23045 "EHLO
        lips.borg.umn.edu") by oss.sgi.com with ESMTP id <S305176AbQDDPfO>;
	Tue, 4 Apr 2000 08:35:14 -0700
Received: from thebarn.com (dhp.lcse.umn.edu [160.94.231.41])
	by lips.borg.umn.edu (8.10.0/8.10.0) with ESMTP id e34FYo302424;
	Tue, 4 Apr 2000 10:34:50 -0500 (CDT)
Message-ID: <38EA0B99.8388C856@thebarn.com>
Date:   Tue, 04 Apr 2000 10:34:49 -0500
From:   Russell Cattelan <cattelan@thebarn.com>
X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 4.0-STABLE i386)
X-Accept-Language: en
MIME-Version: 1.0
To:     Kip Macy <kmacy@CS.Berkeley.EDU>
CC:     Steve Lord <lord@sgi.com>, linux-xfs@oss.sgi.com
Subject: Re: CVS mirroring was Re: TAKE - fix xfs_zero_eof bug with sparse files
References: <Pine.SOL.4.10.10004040810290.8513-100000@ribbit.CS.Berkeley.EDU>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing

Kip Macy wrote:

> When does the external CVS end up getting updated? The fix you mentioned below
> is, as far as I can tell, still not visible. Thanks.

I had a bug in one of my scripts... forgot the ./ in the cronjob.

Check to see if it is there now.



From owner-linux-xfs@oss.sgi.com Tue Apr  4 09:04:14 2000
Received:  by oss.sgi.com id <S305196AbQDDQDy>;
	Tue, 4 Apr 2000 09:03:54 -0700
Received: from ribbit.CS.Berkeley.EDU ([128.32.131.152]:37324 "EHLO
        ribbit.CS.Berkeley.EDU") by oss.sgi.com with ESMTP
	id <S305176AbQDDQDr>; Tue, 4 Apr 2000 09:03:47 -0700
Received: from localhost (kmacy@localhost)
	by ribbit.CS.Berkeley.EDU (8.9.3/8.9.3) with ESMTP id JAA08879;
	Tue, 4 Apr 2000 09:03:46 -0700 (PDT)
X-Authentication-Warning: ribbit.CS.Berkeley.EDU: kmacy owned process doing -bs
Date:   Tue, 4 Apr 2000 09:03:45 -0700 (PDT)
From:   Kip Macy <kmacy@CS.Berkeley.EDU>
To:     Russell Cattelan <cattelan@thebarn.com>
cc:     Steve Lord <lord@sgi.com>, linux-xfs@oss.sgi.com
Subject: Re: CVS mirroring was Re: TAKE - fix xfs_zero_eof bug with sparse
 files
In-Reply-To: <38EA0B99.8388C856@thebarn.com>
Message-ID: <Pine.SOL.4.10.10004040859000.8513-100000@ribbit.CS.Berkeley.EDU>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing


I went into linux/fs/xfs/linux/ and did a cvs update, the time stamp on
xfs_lrw.c is still from yesterday.

Looking more closely xfs_zero_eof still takes an inode.

				-Kip


------------------------------------------------------------------------
Kip Macy                               kmacy@cs.berkeley.edu
University of California, Berkeley     
------------------------------------------------------------------------


On Tue, 4 Apr 2000, Russell Cattelan wrote:

> Kip Macy wrote:
> 
> > When does the external CVS end up getting updated? The fix you mentioned below
> > is, as far as I can tell, still not visible. Thanks.
> 
> I had a bug in one of my scripts... forgot the ./ in the cronjob.
> 
> Check to see if it is there now.
> 
> 



From owner-linux-xfs@oss.sgi.com Tue Apr  4 09:17:14 2000
Received:  by oss.sgi.com id <S305196AbQDDQQy>;
	Tue, 4 Apr 2000 09:16:54 -0700
Received: from ribbit.CS.Berkeley.EDU ([128.32.131.152]:51148 "EHLO
        ribbit.CS.Berkeley.EDU") by oss.sgi.com with ESMTP
	id <S305176AbQDDQQa>; Tue, 4 Apr 2000 09:16:30 -0700
Received: from localhost (kmacy@localhost)
	by ribbit.CS.Berkeley.EDU (8.9.3/8.9.3) with ESMTP id JAA08920;
	Tue, 4 Apr 2000 09:16:29 -0700 (PDT)
X-Authentication-Warning: ribbit.CS.Berkeley.EDU: kmacy owned process doing -bs
Date:   Tue, 4 Apr 2000 09:16:29 -0700 (PDT)
From:   Kip Macy <kmacy@CS.Berkeley.EDU>
To:     Russell Cattelan <cattelan@thebarn.com>
cc:     Steve Lord <lord@sgi.com>, linux-xfs@oss.sgi.com
Subject: Re: CVS mirroring was Re: TAKE - fix xfs_zero_eof bug with sparse
 files
In-Reply-To: <Pine.SOL.4.10.10004040859000.8513-100000@ribbit.CS.Berkeley.EDU>
Message-ID: <Pine.SOL.4.10.10004040915570.8513-100000@ribbit.CS.Berkeley.EDU>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing



Never mind, the new files are there now. Thanks.

				-Kip


From owner-linux-xfs@oss.sgi.com Tue Apr  4 09:23:45 2000
Received:  by oss.sgi.com id <S305196AbQDDQXe>;
	Tue, 4 Apr 2000 09:23:34 -0700
Received: from rf-mail1.echostar.com ([205.172.144.40]:65287 "EHLO
        rf-exch2.echostar.com") by oss.sgi.com with ESMTP
	id <S305176AbQDDQXQ>; Tue, 4 Apr 2000 09:23:16 -0700
Received: from echostar.com (linux10.echostar.com [172.20.50.110]) by rf-exch2.echostar.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21)
	id 2HDTSFMW; Tue, 4 Apr 2000 10:23:07 -0600
Message-ID: <38EA16E8.6580598@echostar.com>
Date:   Tue, 04 Apr 2000 10:23:04 -0600
From:   "Ian S. Nelson" <ian.nelson@echostar.com>
Reply-To: ian.nelson@echostar.com
Organization: Echostar
X-Mailer: Mozilla 4.51 [en] (X11; I; Linux 2.2.5-15 i686)
X-Accept-Language: en
MIME-Version: 1.0
To:     "linux-xfs@oss.sgi.com" <linux-xfs@oss.sgi.com>
Subject: How can I build a loopback filesystem?
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing


Okay, I'm stupid.  I've been trying to build an XFS loopback filesystem
to do some playing with, any hints?

I did it like I do it for all the others, I dd a blank file of about
100M then I try to build a filesystem in it.  the xfs mkfs utility
doesn't want to detect the size and I haven't been able to get the size
parameters to work.

Thanks,
Ian Nelson


From owner-linux-xfs@oss.sgi.com Tue Apr  4 09:38:34 2000
Received:  by oss.sgi.com id <S305196AbQDDQiZ>;
	Tue, 4 Apr 2000 09:38:25 -0700
Received: from deliverator.sgi.com ([204.94.214.10]:44840 "EHLO
        deliverator.sgi.com") by oss.sgi.com with ESMTP id <S305176AbQDDQh6>;
	Tue, 4 Apr 2000 09:37:58 -0700
Received: from ledzep.cray.com (ledzep.cray.com [137.38.226.97]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id JAA20008
	for <linux-xfs@oss.sgi.com>; Tue, 4 Apr 2000 09:33:15 -0700 (PDT)
	mail_from (mostek@sgi.com)
Received: from ironwood-e185.americas.sgi.com (ironwood.cray.com [128.162.185.212]) by ledzep.cray.com (SGI-SGI-8.9.3/craymail-smart-nospam1.0) with ESMTP id LAA51827; Tue, 4 Apr 2000 11:35:24 -0500 (CDT)
Received: from fsgi344.americas.sgi.com (fsgi344.americas.sgi.com [128.162.184.15]) by ironwood-e185.americas.sgi.com (8.8.4/SGI-ironwood-e1.4) with ESMTP id LAA06609; Tue, 4 Apr 2000 11:35:15 -0500 (CDT)
From:   Jim Mostek <mostek@sgi.com>
Received: by fsgi344.americas.sgi.com (980427.SGI.8.8.8/SGI-client.1.6) id LAA08085; Tue, 4 Apr 2000 11:35:21 -0500 (CDT)
Message-Id: <200004041635.LAA08085@fsgi344.americas.sgi.com>
Subject: Re: Correctness
To:     kmacy@CS.Berkeley.EDU (Kip Macy)
Date:   Tue, 4 Apr 2000 11:35:21 -0500 (CDT)
Cc:     linux-xfs@oss.sgi.com
In-Reply-To: <Pine.SOL.4.10.10004040836080.8513-100000@ribbit.CS.Berkeley.EDU> from "Kip Macy" at Apr 04, 2000 08:49:40 AM
X-Mailer: ELM [version 2.5 PL2]
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing


We currently has a bunch of problems with type conflicts between
XFS and Linux. Also, there are problems getting big files ( > 2^32 ) to
work correctly. This is being address. Internally, we call this the LFS
work since it requires having the LFS patch (which I think is now all ther
in 2.3.99pre2).

The Volume management work is separate from the LFS (Large File Support) work.

Have you tried running McVoy's lmbench?
How did it crash?

Thanks,

Jim

>
>> 	8.) LFS/Volume managers (Linuxcare)
>What are you referring to with LFS? Aren't you just going to use Linux's LVM or
>are the two one and the same?
>
>
>> I think we need to stop thinking about performance until we have the above
>> completed. On the other hand, we need to keep fixing bugs/problems that
>> the "community" reports.
>
>There is certainly no point in focusing on performance until the bugs are fixed.
>You can't really focus on performance when benchmarks (McVoy's lmbench 
>specifically) crash the system.
>
>
>
>			-Kip
>


From owner-linux-xfs@oss.sgi.com Tue Apr  4 09:43:34 2000
Received:  by oss.sgi.com id <S305210AbQDDQnO>;
	Tue, 4 Apr 2000 09:43:14 -0700
Received: from deliverator.sgi.com ([204.94.214.10]:40234 "EHLO
        deliverator.sgi.com") by oss.sgi.com with ESMTP id <S305176AbQDDQnA>;
	Tue, 4 Apr 2000 09:43:00 -0700
Received: from ledzep.cray.com (ledzep.cray.com [137.38.226.97]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id JAA20774
	for <linux-xfs@oss.sgi.com>; Tue, 4 Apr 2000 09:38:16 -0700 (PDT)
	mail_from (lord@sgi.com)
Received: from ironwood-e185.americas.sgi.com (ironwood.cray.com [128.162.185.212]) by ledzep.cray.com (SGI-SGI-8.9.3/craymail-smart-nospam1.0) with ESMTP id LAA34730; Tue, 4 Apr 2000 11:40:26 -0500 (CDT)
Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.184.86]) by ironwood-e185.americas.sgi.com (8.8.4/SGI-ironwood-e1.4) with ESMTP id LAA06795; Tue, 4 Apr 2000 11:40:17 -0500 (CDT)
Received: from jen.americas.sgi.com by jen.americas.sgi.com (8.9.3/SGI-client.1.6) via ESMTP id LAA31373; Tue, 4 Apr 2000 11:40:22 -0500
Message-Id: <200004041640.LAA31373@jen.americas.sgi.com>
X-Mailer: exmh version 2.1.1 10/15/1999
To:     ian.nelson@echostar.com
cc:     "linux-xfs@oss.sgi.com" <linux-xfs@oss.sgi.com>
Subject: Re: How can I build a loopback filesystem? 
In-Reply-To: Message from "Ian S. Nelson" <ian.nelson@echostar.com> 
   of "Tue, 04 Apr 2000 10:23:04 MDT." <38EA16E8.6580598@echostar.com> 
Date:   Tue, 04 Apr 2000 11:40:21 -0500
From:   Steve Lord <lord@sgi.com>
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing

> 
> Okay, I'm stupid.  I've been trying to build an XFS loopback filesystem
> to do some playing with, any hints?
> 
> I did it like I do it for all the others, I dd a blank file of about
> 100M then I try to build a filesystem in it.  the xfs mkfs utility
> doesn't want to detect the size and I haven't been able to get the size
> parameters to work.
> 
> Thanks,
> Ian Nelson


Try something like this:

 mkfs_xfs -d file=1,name=/tmp/fred,size=100m

The options on mkfs are somewhat arcane!

Steve



From owner-linux-xfs@oss.sgi.com Tue Apr  4 09:47:05 2000
Received:  by oss.sgi.com id <S305211AbQDDQqp>;
	Tue, 4 Apr 2000 09:46:45 -0700
Received: from s052.widexs.nl ([212.204.200.1]:30216 "EHLO s052.widexs.nl")
	by oss.sgi.com with ESMTP id <S305176AbQDDQqg>;
	Tue, 4 Apr 2000 09:46:36 -0700
Received: from localhost (caps@localhost)
	by s052.widexs.nl (8.9.3/8.9.3) with ESMTP id SAA06039
	for <linux-xfs@oss.sgi.com>; Tue, 4 Apr 2000 18:45:39 +0200
Date:   Tue, 4 Apr 2000 18:45:39 +0200 (MEST)
From:   "Mathieu Kooiman (ggInternet)" <caps@s052.widexs.nl>
Reply-To: mathieu@ggInter.net
To:     linux-xfs@oss.sgi.com
Subject: Unsupported fs, to many mounted filesystems or bad superblock
Message-ID: <Pine.LNX.4.10.10004041840590.5471-100000@s052.widexs.nl>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing

Hi,

I recently installed Linux 2.3.99-pre2 with 
SGI partitions and XFS filesystem, for I have  an (older)
SGI Indy IP22 with IRIX 5.2 or something like it..

Now, compile all went great BUT, I can't seem to mount those partitions,
it gives me the error as described in the Subject.

when I do insmod xfs it show this:
Entered xfs_do_init()
Exited xfs_do_init()

ERhmz, any ideas?

Mathieu Kooiman
ggInternet Webdesign
http://www.ggInter.net




From owner-linux-xfs@oss.sgi.com Tue Apr  4 10:23:55 2000
Received:  by oss.sgi.com id <S305196AbQDDRXo>;
	Tue, 4 Apr 2000 10:23:44 -0700
Received: from lips.borg.umn.edu ([160.94.232.50]:39685 "EHLO
        lips.borg.umn.edu") by oss.sgi.com with ESMTP id <S305176AbQDDRXh>;
	Tue, 4 Apr 2000 10:23:37 -0700
Received: from thebarn.com (dhp.lcse.umn.edu [160.94.231.41])
	by lips.borg.umn.edu (8.10.0/8.10.0) with ESMTP id e34HGL302980;
	Tue, 4 Apr 2000 12:16:21 -0500 (CDT)
Message-ID: <38EA2364.1915BC9@thebarn.com>
Date:   Tue, 04 Apr 2000 12:16:20 -0500
From:   Russell Cattelan <cattelan@thebarn.com>
X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 4.0-STABLE i386)
X-Accept-Language: en
MIME-Version: 1.0
To:     mathieu@ggInter.net
CC:     linux-xfs@oss.sgi.com
Subject: Re: Unsupported fs, to many mounted filesystems or bad superblock
References: <Pine.LNX.4.10.10004041840590.5471-100000@s052.widexs.nl>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing

"Mathieu Kooiman (ggInternet)" wrote:

> Hi,
>
> I recently installed Linux 2.3.99-pre2 with
> SGI partitions and XFS filesystem, for I have  an (older)
> SGI Indy IP22 with IRIX 5.2 or something like it..
>
> Now, compile all went great BUT, I can't seem to mount those partitions,
> it gives me the error as described in the Subject.
>
> when I do insmod xfs it show this:
> Entered xfs_do_init()
> Exited xfs_do_init()

I'm not sure I understand what you are trying to do.
you have an indy that you put linux on or you have
some disks from an Indy you put on an x86 box?

If the later case the old irix XFS partitions will not
work just yet, not until the endian work is done.

If you are running on indy... well this again is a first.
Theoretically it may work... but well I'm going to guess
we have some type size mismatches.

>
>
> ERhmz, any ideas?
>
> Mathieu Kooiman
> ggInternet Webdesign
> http://www.ggInter.net

--
Russell Cattelan
cattelan@thebarn.com




From owner-linux-xfs@oss.sgi.com Tue Apr  4 11:00:36 2000
Received:  by oss.sgi.com id <S305176AbQDDSA0>;
	Tue, 4 Apr 2000 11:00:26 -0700
Received: from ribbit.CS.Berkeley.EDU ([128.32.131.152]:16846 "EHLO
        ribbit.CS.Berkeley.EDU") by oss.sgi.com with ESMTP
	id <S305166AbQDDSAE>; Tue, 4 Apr 2000 11:00:04 -0700
Received: from localhost (kmacy@localhost)
	by ribbit.CS.Berkeley.EDU (8.9.3/8.9.3) with ESMTP id LAA09623;
	Tue, 4 Apr 2000 11:00:02 -0700 (PDT)
X-Authentication-Warning: ribbit.CS.Berkeley.EDU: kmacy owned process doing -bs
Date:   Tue, 4 Apr 2000 11:00:01 -0700 (PDT)
From:   Kip Macy <kmacy@CS.Berkeley.EDU>
To:     Jim Mostek <mostek@sgi.com>
cc:     linux-xfs@oss.sgi.com
Subject: Re: Correctness
In-Reply-To: <200004041635.LAA08085@fsgi344.americas.sgi.com>
Message-ID: <Pine.SOL.4.10.10004041056190.8513-100000@ribbit.CS.Berkeley.EDU>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing


> 
> We currently has a bunch of problems with type conflicts between
> XFS and Linux. Also, there are problems getting big files ( > 2^32 ) to
> work correctly. This is being address. Internally, we call this the LFS
> work since it requires having the LFS patch (which I think is now all ther
> in 2.3.99pre2).
> 
> The Volume management work is separate from the LFS (Large File Support) work.

I did not realize it stood for Large File Support, when I see LFS I think
Log-structured File System, which gave me cause for pause.

> 

> Have you tried running McVoy's lmbench?
Yes.

> How did it crash?
The system locks up and does not respond even to Ctrl-Alt-Del when running the
file system latency portion.

I will narrow it down to a specific operation.

				-Kip


From owner-linux-xfs@oss.sgi.com Tue Apr  4 11:24:38 2000
Received:  by oss.sgi.com id <S305176AbQDDSY2>;
	Tue, 4 Apr 2000 11:24:28 -0700
Received: from deliverator.sgi.com ([204.94.214.10]:48715 "EHLO
        deliverator.sgi.com") by oss.sgi.com with ESMTP id <S305166AbQDDSYH>;
	Tue, 4 Apr 2000 11:24:07 -0700
Received: from ledzep.cray.com (ledzep.cray.com [137.38.226.97]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id LAA05116
	for <linux-xfs@oss.sgi.com>; Tue, 4 Apr 2000 11:19:25 -0700 (PDT)
	mail_from (lord@sgi.com)
Received: from ironwood-e185.americas.sgi.com (ironwood.cray.com [128.162.185.212]) by ledzep.cray.com (SGI-SGI-8.9.3/craymail-smart-nospam1.0) with ESMTP id NAA83040; Tue, 4 Apr 2000 13:22:49 -0500 (CDT)
Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.184.86]) by ironwood-e185.americas.sgi.com (8.8.4/SGI-ironwood-e1.4) with ESMTP id NAA11518; Tue, 4 Apr 2000 13:22:41 -0500 (CDT)
Received: from jen.americas.sgi.com by jen.americas.sgi.com (8.9.3/SGI-client.1.6) via ESMTP id NAA24479; Tue, 4 Apr 2000 13:22:45 -0500
Message-Id: <200004041822.NAA24479@jen.americas.sgi.com>
X-Mailer: exmh version 2.1.1 10/15/1999
To:     Kip Macy <kmacy@CS.Berkeley.EDU>
cc:     Jim Mostek <mostek@sgi.com>, linux-xfs@oss.sgi.com
Subject: Re: Correctness 
In-Reply-To: Message from Kip Macy <kmacy@CS.Berkeley.EDU> 
   of "Tue, 04 Apr 2000 11:00:01 PDT." <Pine.SOL.4.10.10004041056190.8513-100000@ribbit.CS.Berkeley.EDU> 
Date:   Tue, 04 Apr 2000 13:22:45 -0500
From:   Steve Lord <lord@sgi.com>
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing


> 
> > Have you tried running McVoy's lmbench?
> Yes.
> 
> > How did it crash?
> The system locks up and does not respond even to Ctrl-Alt-Del when running th
e
> file system latency portion.
> 
> I will narrow it down to a specific operation.
> 
> 				-Kip


Hmm, I just ran lmbench to completion can you tell us more about your system,

Are you running SMP or not? What type of disk drive are you using (IDE/SCSI)?
Did you use CONFIG_PAGE_BUF_META in your build of XFS.

I am running on a 2 cpu box using a scsi disk and with CONFIG_PAGE_BUF_META
turned on.

Steve




From owner-linux-xfs@oss.sgi.com Tue Apr  4 11:46:28 2000
Received:  by oss.sgi.com id <S305166AbQDDSqT>;
	Tue, 4 Apr 2000 11:46:19 -0700
Received: from timbuk-fddi.cray.com ([128.162.8.102]:53687 "EHLO
        timbuk.cray.com") by oss.sgi.com with ESMTP id <S305176AbQDDSqP>;
	Tue, 4 Apr 2000 11:46:15 -0700
Received: from clink.americas.sgi.com (clink.cray.com [128.162.84.70]) by timbuk.cray.com (8.8.8/CRI-gate-news-1.3) with ESMTP id NAA02680 for <linux-xfs@oss.sgi.com>; Tue, 4 Apr 2000 13:46:04 -0500 (CDT)
Received: (from lord@localhost) by clink.americas.sgi.com (980427.SGI.8.8.8/CRI-news-1.3) id NAA20681 for linux-xfs@oss.sgi.com; Tue, 4 Apr 2000 13:46:06 -0500 (CDT)
Date:   Tue, 4 Apr 2000 13:46:06 -0500 (CDT)
From:   Steve Lord <lord@sgi.com>
Message-Id: <200004041846.NAA20681@clink.americas.sgi.com>
To:     linux-xfs@oss.sgi.com
Subject: TAKE - reimplement pagebuf_inval and change all its callers
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing

pagebuf_inval was doing nasty things to get rid of pages, and was not 
very efficient about it. This changes it to use truncate_inode_pages
instead. truncate_inode_pages does not allow you to specify an end
point for removing pages, which is OK because all the calls from XFS
specify EOF anyway. So, we change all the calls out of XFS because
they were calculating an end offset which made things more efficient
on Irix, but does not on Linux.


Modid:  2.3.99pre2-xfs:slinx:56595a
Date:  Tue Apr  4 11:31:55 PDT 2000
Workarea:  clink.americas.sgi.com:/data/clink/io/lord/slinx-xfs-2.3.99pre2

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

cmd/xfs/sim/src/vnode.c - 1.52
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/cmd/xfs/sim/src/vnode.c.diff?r1=text&tr1=1.52&r2=text&tr2=1.51&f=h
	- Remove bogus vop call - they cannot be made at this point.

linux/fs/page_buf.c - 1.77
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/linux/fs/page_buf.c.diff?r1=text&tr1=1.77&r2=text&tr2=1.76&f=h
	- Reimplement pagebuf_inval to use the more efficient truncate_inode_pages
	  which also does not set the referenced bit on pages.

linux/fs/xfs/linux/xfs_fs_subr.c - 1.18
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/linux/fs/xfs/linux/xfs_fs_subr.c.diff?r1=text&tr1=1.18&r2=text&tr2=1.17&f=h
	- Change fs_toss/flush/flushinval functions to not take a range
	  as we don't have support for this on linux - plus the end
	  range was almost always EOF.

linux/fs/xfs/linux/xfs_lrw.c - 1.32
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/linux/fs/xfs/linux/xfs_lrw.c.diff?r1=text&tr1=1.32&r2=text&tr2=1.31&f=h
	- Fix VOP_FLUSH_PAGES for interface change.

linux/fs/xfs/linux/xfs_vnode.c - 1.22
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/linux/fs/xfs/linux/xfs_vnode.c.diff?r1=text&tr1=1.22&r2=text&tr2=1.21&f=h
	- Remove bogus vop call - they cannot be made at this point.

linux/fs/xfs/pseudo-inc/sys/fs_subr.h - 1.7
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/linux/fs/xfs/pseudo-inc/sys/fs_subr.h.diff?r1=text&tr1=1.7&r2=text&tr2=1.6&f=h
	- Change fs_toss/flush/flushinval functions to not take a range
	  as we don't have support for this on linux - plus the end
	  range was almost always EOF.

linux/fs/xfs/pseudo-inc/sys/vnode.h - 1.17
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/linux/fs/xfs/pseudo-inc/sys/vnode.h.diff?r1=text&tr1=1.17&r2=text&tr2=1.16&f=h
	- Change VOP_FLUSH_PAGES VOP_FLUSHINVAL_PAGES and VOP_TOSS_PAGES to
	  not take an end offset.

linux/fs/xfs/xfs_bmap.c - 1.246
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/linux/fs/xfs/xfs_bmap.c.diff?r1=text&tr1=1.246&r2=text&tr2=1.245&f=h
linux/fs/xfs/xfs_dfrag.c - 1.15
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/linux/fs/xfs/xfs_dfrag.c.diff?r1=text&tr1=1.15&r2=text&tr2=1.14&f=h
linux/fs/xfs/xfs_inode.c - 1.278
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/linux/fs/xfs/xfs_inode.c.diff?r1=text&tr1=1.278&r2=text&tr2=1.277&f=h
linux/fs/xfs/xfs_rw.c - 1.311
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/linux/fs/xfs/xfs_rw.c.diff?r1=text&tr1=1.311&r2=text&tr2=1.310&f=h
linux/fs/xfs/xfs_vfsops.c - 1.262
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/linux/fs/xfs/xfs_vfsops.c.diff?r1=text&tr1=1.262&r2=text&tr2=1.261&f=h
linux/fs/xfs/xfs_vnodeops.c - 1.449
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/linux/fs/xfs/xfs_vnodeops.c.diff?r1=text&tr1=1.449&r2=text&tr2=1.448&f=h
	- Change calls to VOP_FLUSH_PAGES VOP_FLUSHINVAL_PAGES and VOP_TOSS_PAGES to
	  not take an end offset.

linux/include/linux/page_buf.h - 1.42
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/linux/include/linux/page_buf.h.diff?r1=text&tr1=1.42&r2=text&tr2=1.41&f=h
	- Change prototypes for toss/flush and inval to not take an end offset


From owner-linux-xfs@oss.sgi.com Tue Apr  4 11:53:58 2000
Received:  by oss.sgi.com id <S305210AbQDDSxs>;
	Tue, 4 Apr 2000 11:53:48 -0700
Received: from deliverator.sgi.com ([204.94.214.10]:63574 "EHLO
        deliverator.sgi.com") by oss.sgi.com with ESMTP id <S305166AbQDDSxo>;
	Tue, 4 Apr 2000 11:53:44 -0700
Received: from madurai.engr.sgi.com (madurai.engr.sgi.com [163.154.5.75]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id LAA08981
	for <linux-xfs@oss.sgi.com>; Tue, 4 Apr 2000 11:49:02 -0700 (PDT)
	mail_from (ananth@sgi.com)
Received: from sgi.com (mango.engr.sgi.com [163.154.5.76]) by madurai.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) via ESMTP id LAA12370 for <linux-xfs@oss.sgi.com>; Tue, 4 Apr 2000 11:50:18 -0700 (PDT)
Message-ID: <38EA3985.E6F5BE00@sgi.com>
Date:   Tue, 04 Apr 2000 11:50:45 -0700
From:   Rajagopal Ananthanarayanan <ananth@sgi.com>
X-Mailer: Mozilla 4.6 [en] (X11; I; Linux 2.2.10-1SGI_11smp i686)
X-Accept-Language: en
MIME-Version: 1.0
To:     linux-xfs@oss.sgi.com
Subject: Re: Correctness
References: <200004041822.NAA24479@jen.americas.sgi.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing

Steve Lord wrote:
> 
> >
> > > Have you tried running McVoy's lmbench?
> > Yes.
> >
> > > How did it crash?
> > The system locks up and does not respond even to Ctrl-Alt-Del when running th
> e
> > file system latency portion.
> >
> > I will narrow it down to a specific operation.
> >
> >                               -Kip
> 
> Hmm, I just ran lmbench to completion can you tell us more about your system,
> 
> Are you running SMP or not? What type of disk drive are you using (IDE/SCSI)?
> Did you use CONFIG_PAGE_BUF_META in your build of XFS.
> 
> I am running on a 2 cpu box using a scsi disk and with CONFIG_PAGE_BUF_META
> turned on.

I too have run lmbench earlier this week, with no PAGE_BUF_META,
and things ran fine. Kip, do you have kdb on? If so, try breaking
in with either "Pause/Break" key on a real console or <cntrl>-a  on
the serial console. If that doesn't work, you can also give it an NMI
if your system supports it ... NMI is usually a separate button similar
to reset.


ananth.

--------------------------------------------------------------------------
Rajagopal Ananthanarayanan ("ananth")
Member Technical Staff, SGI.
--------------------------------------------------------------------------

From owner-linux-xfs@oss.sgi.com Tue Apr  4 13:05:27 2000
Received:  by oss.sgi.com id <S305167AbQDDUFR>;
	Tue, 4 Apr 2000 13:05:17 -0700
Received: from ribbit.CS.Berkeley.EDU ([128.32.131.152]:62415 "EHLO
        ribbit.CS.Berkeley.EDU") by oss.sgi.com with ESMTP
	id <S305166AbQDDUFC>; Tue, 4 Apr 2000 13:05:02 -0700
Received: from localhost (kmacy@localhost)
	by ribbit.CS.Berkeley.EDU (8.9.3/8.9.3) with ESMTP id NAA10075;
	Tue, 4 Apr 2000 13:04:59 -0700 (PDT)
X-Authentication-Warning: ribbit.CS.Berkeley.EDU: kmacy owned process doing -bs
Date:   Tue, 4 Apr 2000 13:04:59 -0700 (PDT)
From:   Kip Macy <kmacy@CS.Berkeley.EDU>
To:     Steve Lord <lord@sgi.com>
cc:     Jim Mostek <mostek@sgi.com>, linux-xfs@oss.sgi.com
Subject: Re: Correctness 
In-Reply-To: <200004041822.NAA24479@jen.americas.sgi.com>
Message-ID: <Pine.SOL.4.10.10004041300100.8513-100000@ribbit.CS.Berkeley.EDU>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing

> Hmm, I just ran lmbench to completion can you tell us more about your system,

Just to make sure - you did set it up to run in your XFS partition didn't you?
It defaults to running in /usr/tmp which you probably do not have set up as XFS.

> 
> Are you running SMP or not? What type of disk drive are you using (IDE/SCSI)?
> Did you use CONFIG_PAGE_BUF_META in your build of XFS.

I am running uniprocessor with an IDE drive with all XFS related options turned
on in the build.

> 
> I am running on a 2 cpu box using a scsi disk and with CONFIG_PAGE_BUF_META
> turned on.


					-Kip


From owner-linux-xfs@oss.sgi.com Tue Apr  4 13:26:47 2000
Received:  by oss.sgi.com id <S305167AbQDDU0i>;
	Tue, 4 Apr 2000 13:26:38 -0700
Received: from ribbit.CS.Berkeley.EDU ([128.32.131.152]:23248 "EHLO
        ribbit.CS.Berkeley.EDU") by oss.sgi.com with ESMTP
	id <S305166AbQDDU0g>; Tue, 4 Apr 2000 13:26:36 -0700
Received: from localhost (kmacy@localhost)
	by ribbit.CS.Berkeley.EDU (8.9.3/8.9.3) with ESMTP id NAA10267;
	Tue, 4 Apr 2000 13:26:34 -0700 (PDT)
X-Authentication-Warning: ribbit.CS.Berkeley.EDU: kmacy owned process doing -bs
Date:   Tue, 4 Apr 2000 13:26:34 -0700 (PDT)
From:   Kip Macy <kmacy@CS.Berkeley.EDU>
To:     Rajagopal Ananthanarayanan <ananth@sgi.com>
cc:     linux-xfs@oss.sgi.com
Subject: Re: Correctness
In-Reply-To: <38EA3985.E6F5BE00@sgi.com>
Message-ID: <Pine.SOL.4.10.10004041324350.8513-100000@ribbit.CS.Berkeley.EDU>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing

It may be a machine/kernel problem - when I run gdb on fs_lat, even without an
XFS partition mounted, the system hangs.

				-Kip

------------------------------------------------------------------------
Kip Macy                               kmacy@cs.berkeley.edu
University of California, Berkeley     
------------------------------------------------------------------------


On Tue, 4 Apr 2000, Rajagopal Ananthanarayanan wrote:

> Steve Lord wrote:
> > 
> > >
> > > > Have you tried running McVoy's lmbench?
> > > Yes.
> > >
> > > > How did it crash?
> > > The system locks up and does not respond even to Ctrl-Alt-Del when running th
> > e
> > > file system latency portion.
> > >
> > > I will narrow it down to a specific operation.
> > >
> > >                               -Kip
> > 
> > Hmm, I just ran lmbench to completion can you tell us more about your system,
> > 
> > Are you running SMP or not? What type of disk drive are you using (IDE/SCSI)?
> > Did you use CONFIG_PAGE_BUF_META in your build of XFS.
> > 
> > I am running on a 2 cpu box using a scsi disk and with CONFIG_PAGE_BUF_META
> > turned on.
> 
> I too have run lmbench earlier this week, with no PAGE_BUF_META,
> and things ran fine. Kip, do you have kdb on? If so, try breaking
> in with either "Pause/Break" key on a real console or <cntrl>-a  on
> the serial console. If that doesn't work, you can also give it an NMI
> if your system supports it ... NMI is usually a separate button similar
> to reset.
> 
> 
> ananth.
> 
> --------------------------------------------------------------------------
> Rajagopal Ananthanarayanan ("ananth")
> Member Technical Staff, SGI.
> --------------------------------------------------------------------------
> 


From owner-linux-xfs@oss.sgi.com Tue Apr  4 15:19:48 2000
Received:  by oss.sgi.com id <S305167AbQDDWTj>;
	Tue, 4 Apr 2000 15:19:39 -0700
Received: from pneumatic-tube.sgi.com ([204.94.214.22]:42538 "EHLO
        pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP
	id <S305166AbQDDWT0>; Tue, 4 Apr 2000 15:19:26 -0700
Received: from ledzep.cray.com (ledzep.cray.com [137.38.226.97]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id PAA08476
	for <linux-xfs@oss.sgi.com>; Tue, 4 Apr 2000 15:23:11 -0700 (PDT)
	mail_from (lord@sgi.com)
Received: from ironwood-e185.americas.sgi.com (ironwood.cray.com [128.162.185.212]) by ledzep.cray.com (SGI-SGI-8.9.3/craymail-smart-nospam1.0) with ESMTP id RAA18677; Tue, 4 Apr 2000 17:18:09 -0500 (CDT)
Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.184.86]) by ironwood-e185.americas.sgi.com (8.8.4/SGI-ironwood-e1.4) with ESMTP id RAA23075; Tue, 4 Apr 2000 17:18:02 -0500 (CDT)
Received: from jen.americas.sgi.com by jen.americas.sgi.com (8.9.3/SGI-client.1.6) via ESMTP id RAA14379; Tue, 4 Apr 2000 17:18:04 -0500
Message-Id: <200004042218.RAA14379@jen.americas.sgi.com>
X-Mailer: exmh version 2.1.1 10/15/1999
To:     Kip Macy <kmacy@CS.Berkeley.EDU>
cc:     Steve Lord <lord@sgi.com>, Jim Mostek <mostek@sgi.com>,
        linux-xfs@oss.sgi.com
Subject: Re: Correctness 
In-Reply-To: Message from Kip Macy <kmacy@CS.Berkeley.EDU> 
   of "Tue, 04 Apr 2000 13:04:59 PDT." <Pine.SOL.4.10.10004041300100.8513-100000@ribbit.CS.Berkeley.EDU> 
Date:   Tue, 04 Apr 2000 17:18:04 -0500
From:   Steve Lord <lord@sgi.com>
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing

> > Hmm, I just ran lmbench to completion can you tell us more about your syste
m,
> 
> Just to make sure - you did set it up to run in your XFS partition didn't you
?
> It defaults to running in /usr/tmp which you probably do not have set up as X
FS.

Yes I did, I was very careful about that, looks like our configurations are a
little different, that could have something to do with it. Try turning off 
pagebuf meta data.



>> It may be a machine/kernel problem - when I run gdb on fs_lat, even
>> without an XFS partition mounted, the system hangs.
>>
>>                                 -Kip

Hmm, kdb and gdb do not like each other I think, so if you have kdb
turned on in the kernel gdb (or strace) both seem to interact with it.


Steve



From owner-linux-xfs@oss.sgi.com Tue Apr  4 17:01:37 2000
Received:  by oss.sgi.com id <S305166AbQDEABU>;
	Tue, 4 Apr 2000 17:01:20 -0700
Received: from timbuk-fddi.cray.com ([128.162.8.102]:50631 "EHLO
        timbuk.cray.com") by oss.sgi.com with ESMTP id <S305167AbQDEABA>;
	Tue, 4 Apr 2000 17:01:00 -0700
Received: from clink.americas.sgi.com (clink.cray.com [128.162.84.70]) by timbuk.cray.com (8.8.8/CRI-gate-news-1.3) with ESMTP id TAA08478; Tue, 4 Apr 2000 19:00:56 -0500 (CDT)
Received: (from mostek@localhost) by clink.americas.sgi.com (980427.SGI.8.8.8/CRI-news-1.3) id TAA23481; Tue, 4 Apr 2000 19:00:57 -0500 (CDT)
Date:   Tue, 4 Apr 2000 19:00:57 -0500 (CDT)
From:   Jim Mostek <mostek@sgi.com>
Message-Id: <200004050000.TAA23481@clink.americas.sgi.com>
To:     linux-xfs@oss.sgi.com, slinx-xfs@oss.sgi.com
Subject: TAKE - add linvfs_open to directory inode operations.
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing

Modid:  2.3.99pre2-xfs:slinx:56852a
Date:  Tue Apr  4 17:00:14 PDT 2000
Workarea:  clink.americas.sgi.com:/data/clink/io/mostek/slinx-xfs

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

linux/fs/xfs/linux/xfs_file.c - 1.24
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/linux/fs/xfs/linux/xfs_file.c.diff?r1=text&tr1=1.24&r2=text&tr2=1.23&f=h
	- Add the open file operation for directories. This gets
	  the read going early for readdir/getdents for directories
	  that are big enough to have components in a separate block.


From owner-linux-xfs@oss.sgi.com Tue Apr  4 17:55:10 2000
Received:  by oss.sgi.com id <S305167AbQDEAzA>;
	Tue, 4 Apr 2000 17:55:00 -0700
Received: from ribbit.CS.Berkeley.EDU ([128.32.131.152]:35541 "EHLO
        ribbit.CS.Berkeley.EDU") by oss.sgi.com with ESMTP
	id <S305166AbQDEAyl>; Tue, 4 Apr 2000 17:54:41 -0700
Received: from localhost (kmacy@localhost)
	by ribbit.CS.Berkeley.EDU (8.9.3/8.9.3) with ESMTP id RAA11726;
	Tue, 4 Apr 2000 17:54:40 -0700 (PDT)
X-Authentication-Warning: ribbit.CS.Berkeley.EDU: kmacy owned process doing -bs
Date:   Tue, 4 Apr 2000 17:54:40 -0700 (PDT)
From:   Kip Macy <kmacy@CS.Berkeley.EDU>
To:     Steve Lord <lord@sgi.com>
cc:     Jim Mostek <mostek@sgi.com>, linux-xfs@oss.sgi.com
Subject: Re: Correctness 
In-Reply-To: <200004042218.RAA14379@jen.americas.sgi.com>
Message-ID: <Pine.SOL.4.10.10004041747380.11314-100000@ribbit.CS.Berkeley.EDU>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing

> > Just to make sure - you did set it up to run in your XFS partition didn't you
> ?
> > It defaults to running in /usr/tmp which you probably do not have set up as X
> FS.
> 
> Yes I did, I was very careful about that, looks like our configurations are a
> little different, that could have something to do with it. Try turning off 
> pagebuf meta data.

That fixed the problem.

I am open to turning it back on again and helping to track down the problem if
someone can give me a suggestion on how to go about it.


				-Kip



From owner-linux-xfs@oss.sgi.com Tue Apr  4 20:48:07 2000
Received:  by oss.sgi.com id <S305167AbQDEDrr>;
	Tue, 4 Apr 2000 20:47:47 -0700
Received: from deliverator.sgi.com ([204.94.214.10]:61523 "EHLO
        deliverator.sgi.com") by oss.sgi.com with ESMTP id <S305166AbQDEDrN>;
	Tue, 4 Apr 2000 20:47:13 -0700
Received: from ledzep.cray.com (ledzep.cray.com [137.38.226.97]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id UAA05608
	for <linux-xfs@oss.sgi.com>; Tue, 4 Apr 2000 20:42:31 -0700 (PDT)
	mail_from (mostek@sgi.com)
Received: from ironwood-e185.americas.sgi.com (ironwood.cray.com [128.162.185.212]) by ledzep.cray.com (SGI-SGI-8.9.3/craymail-smart-nospam1.0) with ESMTP id WAA96594; Tue, 4 Apr 2000 22:44:42 -0500 (CDT)
Received: from fsgi344.americas.sgi.com (fsgi344.americas.sgi.com [128.162.184.15]) by ironwood-e185.americas.sgi.com (8.8.4/SGI-ironwood-e1.4) with ESMTP id WAA02711; Tue, 4 Apr 2000 22:44:33 -0500 (CDT)
From:   Jim Mostek <mostek@sgi.com>
Received: by fsgi344.americas.sgi.com (980427.SGI.8.8.8/SGI-client.1.6) id WAA38138; Tue, 4 Apr 2000 22:44:39 -0500 (CDT)
Message-Id: <200004050344.WAA38138@fsgi344.americas.sgi.com>
Subject: Re: Correctness
To:     kmacy@CS.Berkeley.EDU (Kip Macy)
Date:   Tue, 4 Apr 2000 22:44:38 -0500 (CDT)
Cc:     linux-xfs@oss.sgi.com
In-Reply-To: <Pine.SOL.4.10.10004041747380.11314-100000@ribbit.CS.Berkeley.EDU> from "Kip Macy" at Apr 04, 2000 05:54:40 PM
X-Mailer: ELM [version 2.5 PL2]
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing


Configure just kdb on (I use about 15000 symbols).
Don't configure gdb.

Configure xfs, pagebuf, pagebuf locking, avl as modules.

build/boot/load/...

make sure ctl A or break gets you the

kdb> prompt at the console.

Make sure you can type:

ps

and 

btp <pid>

to kdb. try btp 1 to see init's stack.

Then, run the test and when things are hung, type ctl A or break
and do the above to see what the stacks are.

If you can't get kdb's prompt, ... we will need to figure something else
out like setting a break point at some common location that we hit
regularly like xfs_sync or ... but not too often.

When things appear hung, you can hopefully still get the breakpoint to
kick in when the clock goes off (assuming those aren't disabled, too).

Jim

>
>> > Just to make sure - you did set it up to run in your XFS partition didn't you
>> ?
>> > It defaults to running in /usr/tmp which you probably do not have set up as X
>> FS.
>> 
>> Yes I did, I was very careful about that, looks like our configurations are a
>> little different, that could have something to do with it. Try turning off 
>> pagebuf meta data.
>
>That fixed the problem.
>
>I am open to turning it back on again and helping to track down the problem if
>someone can give me a suggestion on how to go about it.
>
>
>				-Kip
>
>


From owner-linux-xfs@oss.sgi.com Wed Apr  5 05:22:49 2000
Received:  by oss.sgi.com id <S305167AbQDEMW3>;
	Wed, 5 Apr 2000 05:22:29 -0700
Received: from akira.ep-ag.com ([194.120.231.250]:13396 "EHLO akira.ep-ka.de")
	by oss.sgi.com with ESMTP id <S305166AbQDEMWJ>;
	Wed, 5 Apr 2000 05:22:09 -0700
Received: from ep-ag.com (sol10.ep-ka.de [194.120.231.11])
	by akira.ep-ka.de (8.9.1/8.9.3) with ESMTP id OAA09675;
	Wed, 5 Apr 2000 14:22:04 +0200
Received: from ep-ag.com (stb@crusher.ep-ka.de [194.120.231.18])
	by ep-ag.com (8.9.3/8.9.3) with ESMTP id OAA17794;
	Wed, 5 Apr 2000 14:22:03 +0200 (MET DST)
Message-ID: <38EB2FEA.E22A0E8B@ep-ag.com>
Date:   Wed, 05 Apr 2000 14:22:02 +0200
From:   Klaus Strebel <stb@ep-ag.com>
Organization: EIGNER+PARTNER AG
X-Mailer: Mozilla 4.72 [en] (X11; I; Linux 2.2.14 i686)
X-Accept-Language: en
MIME-Version: 1.0
To:     Tan Pong Heng <pongheng@starnet.gov.sg>
CC:     linux-xfs@oss.sgi.com
Subject: Re: XFS as Root filesystem
References: <200004031359.IAA31585@jen.americas.sgi.com> <005601bf9dc0$64d9a4d0$a6e5a9ca@aries>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing

Tan Pong Heng wrote:
> 
> Already done that, that is why I am certain that the hang occur after the
> successful
> mount. The last place I checked was in main.c which was trying to do
> "exec(init...)"
> it never reach the printk after all the possible init path. (Or, it may be
> taking too long
> for me to notice...)
Hi all,

the issue might be, that xfs has big problems, being mounted ro on boot.
This is the same behaviour as on IRIX (i have a Origin 200 with IRIX 6.4
on dksc(0,1,0) and IRIX 6.5 on dksc(0,2,0)). When i halt and reboot from
the other OS's root, ex. 6.5, mounting ro of the 6.4 filesystems (esp.
the root) on boot failes, due to dirty filesystem (on XFS impossible
;-). So the filesystems must 1. be mounted rw, umounted, and then
mounted ro (what i wanted). Behaps, it helps, if you ensure, that lilo
isn't booting with to ro-flag. Btw. ext3fs has the same problem. I think
Steve Tweedie solved it in ext2-0.0.2d (didn't he, had no time to test).

Bye
Klaus
-- 
Klaus Strebel
stb@ep-ag.com
EIGNER + PARTNER AG   - The Engineering Warehouse Company -
<http://www.ep-ag.com>
-----------------------------------------------------------------------

From owner-linux-xfs@oss.sgi.com Wed Apr  5 05:30:59 2000
Received:  by oss.sgi.com id <S305171AbQDEMat>;
	Wed, 5 Apr 2000 05:30:49 -0700
Received: from rising.starnet.gov.sg ([203.116.82.211]:25041 "EHLO
        rising.starnet.gov.sg") by oss.sgi.com with ESMTP
	id <S305166AbQDEMaa>; Wed, 5 Apr 2000 05:30:30 -0700
Received: from aries (dyn1-166cable.bp1.singa.pore.net [202.169.229.166])
	by rising.starnet.gov.sg (8.9.1/8.9.1) with SMTP id UAA21549;
	Wed, 5 Apr 2000 20:30:20 +0800 (SGT)
Message-ID: <000701bf9efa$a7ebe310$a6e5a9ca@aries>
From:   "Tan Pong Heng" <pongheng@starnet.gov.sg>
To:     "Klaus Strebel" <stb@ep-ag.com>
Cc:     <linux-xfs@oss.sgi.com>
References: <200004031359.IAA31585@jen.americas.sgi.com> <005601bf9dc0$64d9a4d0$a6e5a9ca@aries> <38EB2FEA.E22A0E8B@ep-ag.com>
Subject: Re: XFS as Root filesystem
Date:   Wed, 5 Apr 2000 20:29:57 +0800
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.00.2919.6700
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing

I sync with the latest CVS this morning and the boot process when further.
It definitely does not like to mount read-only. As it can not be remounted
as read-write at the moment. This will break the boot process in big way.
Anyway, I read tried with the root mounted read-write and it when further
and still hang somewhere after the building of window manager session.
(I am using Mandrake 7 as the base.) I could kill the hang process and
continue.
But, the system finally came into the login processes. But, the gdm could
not
start - and will retry forever. As such, I could not get a usable system.
The system did try to start the X server and it did tried to change the
video
mode but could not complete. Are all the various inode type supported on
XFS?
That could be the reason. Since with XFS as root filesystem, there will be
need
to create all kind of inodes for devices, pipe, fifo, sockets, etc on it.
Some of
these may not be supported or does not work correctly....

I will investigate further when I have the time...

----- Original Message -----
From: "Klaus Strebel" <stb@ep-ag.com>
To: "Tan Pong Heng" <pongheng@starnet.gov.sg>
Cc: <linux-xfs@oss.sgi.com>
Sent: Wednesday, April 05, 2000 8:22 PM
Subject: Re: XFS as Root filesystem


> Tan Pong Heng wrote:
> >
> > Already done that, that is why I am certain that the hang occur after
the
> > successful
> > mount. The last place I checked was in main.c which was trying to do
> > "exec(init...)"
> > it never reach the printk after all the possible init path. (Or, it may
be
> > taking too long
> > for me to notice...)
> Hi all,
>
> the issue might be, that xfs has big problems, being mounted ro on boot.
> This is the same behaviour as on IRIX (i have a Origin 200 with IRIX 6.4
> on dksc(0,1,0) and IRIX 6.5 on dksc(0,2,0)). When i halt and reboot from
> the other OS's root, ex. 6.5, mounting ro of the 6.4 filesystems (esp.
> the root) on boot failes, due to dirty filesystem (on XFS impossible
> ;-). So the filesystems must 1. be mounted rw, umounted, and then
> mounted ro (what i wanted). Behaps, it helps, if you ensure, that lilo
> isn't booting with to ro-flag. Btw. ext3fs has the same problem. I think
> Steve Tweedie solved it in ext2-0.0.2d (didn't he, had no time to test).
>
> Bye
> Klaus
> --
> Klaus Strebel
> stb@ep-ag.com
> EIGNER + PARTNER AG   - The Engineering Warehouse Company -
> <http://www.ep-ag.com>
> -----------------------------------------------------------------------
>


From owner-linux-xfs@oss.sgi.com Wed Apr  5 05:50:49 2000
Received:  by oss.sgi.com id <S305176AbQDEMu3>;
	Wed, 5 Apr 2000 05:50:29 -0700
Received: from deliverator.sgi.com ([204.94.214.10]:37407 "EHLO
        deliverator.sgi.com") by oss.sgi.com with ESMTP id <S305166AbQDEMt6>;
	Wed, 5 Apr 2000 05:49:58 -0700
Received: from ledzep.cray.com (ledzep.cray.com [137.38.226.97]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id FAA12831
	for <linux-xfs@oss.sgi.com>; Wed, 5 Apr 2000 05:45:16 -0700 (PDT)
	mail_from (mostek@sgi.com)
Received: from ironwood-e185.americas.sgi.com (ironwood.cray.com [128.162.185.212]) by ledzep.cray.com (SGI-SGI-8.9.3/craymail-smart-nospam1.0) with ESMTP id HAA85018; Wed, 5 Apr 2000 07:48:24 -0500 (CDT)
Received: from fsgi344.americas.sgi.com (fsgi344.americas.sgi.com [128.162.184.15]) by ironwood-e185.americas.sgi.com (8.8.4/SGI-ironwood-e1.4) with ESMTP id HAA19943; Wed, 5 Apr 2000 07:48:16 -0500 (CDT)
From:   Jim Mostek <mostek@sgi.com>
Received: by fsgi344.americas.sgi.com (980427.SGI.8.8.8/SGI-client.1.6) id HAA38406; Wed, 5 Apr 2000 07:48:22 -0500 (CDT)
Message-Id: <200004051248.HAA38406@fsgi344.americas.sgi.com>
Subject: Re: XFS as Root filesystem
To:     stb@ep-ag.com (Klaus Strebel)
Date:   Wed, 5 Apr 2000 07:48:21 -0500 (CDT)
Cc:     linux-xfs@oss.sgi.com
In-Reply-To: <38EB2FEA.E22A0E8B@ep-ag.com> from "Klaus Strebel" at Apr 05, 2000 02:22:02 PM
X-Mailer: ELM [version 2.5 PL2]
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing


	.
	.
	.
>the other OS's root, ex. 6.5, mounting ro of the 6.4 filesystems (esp.
>the root) on boot failes, due to dirty filesystem (on XFS impossible
>;-). So the filesystems must 1. be mounted rw, umounted, and then
>mounted ro (what i wanted). Behaps, it helps, if you ensure, that lilo
	.
	.
	.

It would be pretty simple to have a new flag that let recovery run for
a read-only mount. Recovery checks to see if the head/tail are == and then
allows the read-only mount.

If you look at the code, the XFS_MOUNT_NORECOVERY flag is set
to skip recovery. But, we must already have a consistent file system when
this flag is used.  This is not what we should use for a read-only mount
of root. We need a separate flag. xlog_recovery would then do recovery
even on read-only mounts. Anyone have time to do this? I'll add this to
the mount as root work item.

Jim

>
>Tan Pong Heng wrote:
>> 
>> Already done that, that is why I am certain that the hang occur after the
>> successful
>> mount. The last place I checked was in main.c which was trying to do
>> "exec(init...)"
>> it never reach the printk after all the possible init path. (Or, it may be
>> taking too long
>> for me to notice...)
>Hi all,
>
>the issue might be, that xfs has big problems, being mounted ro on boot.
>This is the same behaviour as on IRIX (i have a Origin 200 with IRIX 6.4
>on dksc(0,1,0) and IRIX 6.5 on dksc(0,2,0)). When i halt and reboot from
>the other OS's root, ex. 6.5, mounting ro of the 6.4 filesystems (esp.
>the root) on boot failes, due to dirty filesystem (on XFS impossible
>;-). So the filesystems must 1. be mounted rw, umounted, and then
>mounted ro (what i wanted). Behaps, it helps, if you ensure, that lilo
>isn't booting with to ro-flag. Btw. ext3fs has the same problem. I think
>Steve Tweedie solved it in ext2-0.0.2d (didn't he, had no time to test).
>
>Bye
>Klaus
>-- 
>Klaus Strebel
>stb@ep-ag.com
>EIGNER + PARTNER AG   - The Engineering Warehouse Company -
><http://www.ep-ag.com>
>-----------------------------------------------------------------------
>


From owner-linux-xfs@oss.sgi.com Wed Apr  5 06:32:09 2000
Received:  by oss.sgi.com id <S305179AbQDENbu>;
	Wed, 5 Apr 2000 06:31:50 -0700
Received: from dukat.scot.redhat.com ([195.89.149.246]:24585 "EHLO
        dukat.scot.redhat.com") by oss.sgi.com with ESMTP
	id <S305166AbQDENbS>; Wed, 5 Apr 2000 06:31:18 -0700
Received: (from sct@localhost)
	by dukat.scot.redhat.com (8.9.3/8.9.3) id OAA09587;
	Wed, 5 Apr 2000 14:30:51 +0100
Date:   Wed, 5 Apr 2000 14:30:50 +0100
From:   "Stephen C. Tweedie" <sct@redhat.com>
To:     Klaus Strebel <stb@ep-ag.com>
Cc:     Tan Pong Heng <pongheng@starnet.gov.sg>, linux-xfs@oss.sgi.com
Subject: Re: XFS as Root filesystem
Message-ID: <20000405143050.I9399@redhat.com>
References: <200004031359.IAA31585@jen.americas.sgi.com> <005601bf9dc0$64d9a4d0$a6e5a9ca@aries> <38EB2FEA.E22A0E8B@ep-ag.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 1.0.1i
In-Reply-To: <38EB2FEA.E22A0E8B@ep-ag.com>; from stb@ep-ag.com on Wed, Apr 05, 2000 at 02:22:02PM +0200
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing

Hi,

On Wed, Apr 05, 2000 at 02:22:02PM +0200, Klaus Strebel wrote:
> 
> the issue might be, that xfs has big problems, being mounted ro on boot.
> This is the same behaviour as on IRIX (i have a Origin 200 with IRIX 6.4
> on dksc(0,1,0) and IRIX 6.5 on dksc(0,2,0)). When i halt and reboot from
> the other OS's root, ex. 6.5, mounting ro of the 6.4 filesystems (esp.
> the root) on boot failes, due to dirty filesystem (on XFS impossible
> ;-). So the filesystems must 1. be mounted rw, umounted, and then
> mounted ro (what i wanted). Behaps, it helps, if you ensure, that lilo
> isn't booting with to ro-flag. Btw. ext3fs has the same problem. I think
> Steve Tweedie solved it in ext2-0.0.2d (didn't he, had no time to test).

All journaling filesystems need recovery.  It _can_ be possible to
build the appropriate recovery bits in memory if you have a readonly
boot, but most filesystems I'm aware of would want write access for
recovery after an unclean mount.

ext3 doesn't really "solve" this, but it does step around it: if you
mount a filesystem which needs recovery as readonly, then it will 
warn you that it is enabling write access to the device temporarily
and will perform the recovery.  The filesystem retains full ROFS
protection, but the device does get written to.  Ext3 does a device
check to make sure that the block device is writable before it 
attempts to do this, and if it is not, it will abort the mount
entirely: you can't mount ext3 on readonly media if recovery is 
needed.

--Stephen

From owner-linux-xfs@oss.sgi.com Wed Apr  5 07:42:39 2000
Received:  by oss.sgi.com id <S305167AbQDEOma>;
	Wed, 5 Apr 2000 07:42:30 -0700
Received: from pneumatic-tube.sgi.com ([204.94.214.22]:21855 "EHLO
        pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP
	id <S305166AbQDEOmO>; Wed, 5 Apr 2000 07:42:14 -0700
Received: from ledzep.cray.com (ledzep.cray.com [137.38.226.97]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id HAA02014
	for <linux-xfs@oss.sgi.com>; Wed, 5 Apr 2000 07:45:58 -0700 (PDT)
	mail_from (lord@sgi.com)
Received: from ironwood-e185.americas.sgi.com (ironwood.cray.com [128.162.185.212]) by ledzep.cray.com (SGI-SGI-8.9.3/craymail-smart-nospam1.0) with ESMTP id JAA28938; Wed, 5 Apr 2000 09:40:56 -0500 (CDT)
Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.184.86]) by ironwood-e185.americas.sgi.com (8.8.4/SGI-ironwood-e1.4) with ESMTP id JAA27972; Wed, 5 Apr 2000 09:40:47 -0500 (CDT)
Received: from jen.americas.sgi.com by jen.americas.sgi.com (8.9.3/SGI-client.1.6) via ESMTP id JAA25697; Wed, 5 Apr 2000 09:40:43 -0500
Message-Id: <200004051440.JAA25697@jen.americas.sgi.com>
X-Mailer: exmh version 2.1.1 10/15/1999
To:     "Stephen C. Tweedie" <sct@redhat.com>
cc:     Klaus Strebel <stb@ep-ag.com>,
        Tan Pong Heng <pongheng@starnet.gov.sg>,
        linux-xfs@oss.sgi.com
Subject: Re: XFS as Root filesystem 
In-Reply-To: Message from "Stephen C. Tweedie" <sct@redhat.com> 
   of "Wed, 05 Apr 2000 14:30:50 BST." <20000405143050.I9399@redhat.com> 
Date:   Wed, 05 Apr 2000 09:40:37 -0500
From:   Steve Lord <lord@sgi.com>
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing

> Hi,
> 
> On Wed, Apr 05, 2000 at 02:22:02PM +0200, Klaus Strebel wrote:
> > 
> > the issue might be, that xfs has big problems, being mounted ro on boot.
> > This is the same behaviour as on IRIX (i have a Origin 200 with IRIX 6.4
> > on dksc(0,1,0) and IRIX 6.5 on dksc(0,2,0)). When i halt and reboot from
> > the other OS's root, ex. 6.5, mounting ro of the 6.4 filesystems (esp.
> > the root) on boot failes, due to dirty filesystem (on XFS impossible
> > ;-). So the filesystems must 1. be mounted rw, umounted, and then
> > mounted ro (what i wanted). Behaps, it helps, if you ensure, that lilo
> > isn't booting with to ro-flag. Btw. ext3fs has the same problem. I think
> > Steve Tweedie solved it in ext2-0.0.2d (didn't he, had no time to test).
> 
> All journaling filesystems need recovery.  It _can_ be possible to
> build the appropriate recovery bits in memory if you have a readonly
> boot, but most filesystems I'm aware of would want write access for
> recovery after an unclean mount.
> 
> ext3 doesn't really "solve" this, but it does step around it: if you
> mount a filesystem which needs recovery as readonly, then it will 
> warn you that it is enabling write access to the device temporarily
> and will perform the recovery.  The filesystem retains full ROFS
> protection, but the device does get written to.  Ext3 does a device
> check to make sure that the block device is writable before it 
> attempts to do this, and if it is not, it will abort the mount
> entirely: you can't mount ext3 on readonly media if recovery is 
> needed.
> 
> --Stephen

Just to report on where XFS is in all of this, it will fail a read only
mount request if it determines recovery needs to be run. We do have
a norecovery mount option - but this is really for internal use only,
I would not recommend using it.

Stephen's idea looks interesting, I will dig into it for XFS.

Steve (really Stephen, but that gets confusing on Linux related topics!)

------------------------------------------------------------------------------
Steve Lord                                      voice: +1-651-683-5291
Silicon Graphics Inc
655F Lone Oak Drive                             email: lord@sgi.com
Eagan, MN, 55121, USA
------------------------------------------------------------------------------




From owner-linux-xfs@oss.sgi.com Wed Apr  5 08:53:00 2000
Received:  by oss.sgi.com id <S305167AbQDEPwk>;
	Wed, 5 Apr 2000 08:52:40 -0700
Received: from deliverator.sgi.com ([204.94.214.10]:22603 "EHLO
        deliverator.sgi.com") by oss.sgi.com with ESMTP id <S305166AbQDEPwX>;
	Wed, 5 Apr 2000 08:52:23 -0700
Received: from ledzep.cray.com (ledzep.cray.com [137.38.226.97]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id IAA03579
	for <linux-xfs@oss.sgi.com>; Wed, 5 Apr 2000 08:47:40 -0700 (PDT)
	mail_from (lord@sgi.com)
Received: from ironwood-e185.americas.sgi.com (ironwood.cray.com [128.162.185.212]) by ledzep.cray.com (SGI-SGI-8.9.3/craymail-smart-nospam1.0) with ESMTP id KAA43025; Wed, 5 Apr 2000 10:49:50 -0500 (CDT)
Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.184.86]) by ironwood-e185.americas.sgi.com (8.8.4/SGI-ironwood-e1.4) with ESMTP id KAA02093; Wed, 5 Apr 2000 10:49:41 -0500 (CDT)
Received: from jen.americas.sgi.com by jen.americas.sgi.com (8.9.3/SGI-client.1.6) via ESMTP id KAA28139; Wed, 5 Apr 2000 10:49:37 -0500
Message-Id: <200004051549.KAA28139@jen.americas.sgi.com>
X-Mailer: exmh version 2.1.1 10/15/1999
To:     "Tan Pong Heng" <pongheng@starnet.gov.sg>
cc:     "Klaus Strebel" <stb@ep-ag.com>, linux-xfs@oss.sgi.com
Subject: Re: XFS as Root filesystem 
In-Reply-To: Message from "Tan Pong Heng" <pongheng@starnet.gov.sg> 
   of "Wed, 05 Apr 2000 20:29:57 +0800." <000701bf9efa$a7ebe310$a6e5a9ca@aries>
Date:   Wed, 05 Apr 2000 10:49:36 -0500
From:   Steve Lord <lord@sgi.com>
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing

> I sync with the latest CVS this morning and the boot process when further.
> It definitely does not like to mount read-only. As it can not be remounted
> as read-write at the moment. This will break the boot process in big way.
> Anyway, I read tried with the root mounted read-write and it when further
> and still hang somewhere after the building of window manager session.
> (I am using Mandrake 7 as the base.) I could kill the hang process and
> continue.
> But, the system finally came into the login processes. But, the gdm could
> not
> start - and will retry forever. As such, I could not get a usable system.
> The system did try to start the X server and it did tried to change the
> video
> mode but could not complete. Are all the various inode type supported on
> XFS?
> That could be the reason. Since with XFS as root filesystem, there will be
> need
> to create all kind of inodes for devices, pipe, fifo, sockets, etc on it.
> Some of
> these may not be supported or does not work correctly....
> 
> I will investigate further when I have the time...
> 


In theory devices/fifos etc should work - but I am not surprised if we have
problems. We need to narrow down exactly what is not working. If you set
your default run level to something which does not run X (level 3 on redhat,
so I suspect mandrake is the same) and then do a startx and capture the
output in a file it might tell us something.

Thanks

   Steve






From owner-linux-xfs@oss.sgi.com Wed Apr  5 10:17:50 2000
Received:  by oss.sgi.com id <S305171AbQDERRl>;
	Wed, 5 Apr 2000 10:17:41 -0700
Received: from deliverator.sgi.com ([204.94.214.10]:55655 "EHLO
        deliverator.sgi.com") by oss.sgi.com with ESMTP id <S305166AbQDERRX>;
	Wed, 5 Apr 2000 10:17:23 -0700
Received: from ledzep.cray.com (ledzep.cray.com [137.38.226.97]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id KAA16665
	for <linux-xfs@oss.sgi.com>; Wed, 5 Apr 2000 10:12:40 -0700 (PDT)
	mail_from (n8994@sgi.com)
Received: from ironwood-e185.americas.sgi.com (ironwood.cray.com [128.162.185.212]) by ledzep.cray.com (SGI-SGI-8.9.3/craymail-smart-nospam1.0) with ESMTP id MAA61779 for <linux-xfs@oss.sgi.com>; Wed, 5 Apr 2000 12:16:06 -0500 (CDT)
Received: from nt8.americas.sgi.com (nt8.americas.sgi.com [128.162.195.8]) by ironwood-e185.americas.sgi.com (8.8.4/SGI-ironwood-e1.4) with ESMTP id MAA06909 for <linux-xfs@oss.sgi.com>; Wed, 5 Apr 2000 12:15:58 -0500 (CDT)
From:   Russell Cattelan <n8994@sgi.com>
Received: by nt8.americas.sgi.com (980427.SGI.8.8.8/SGI-client.1.6) id MAA47906; Wed, 5 Apr 2000 12:16:04 -0500 (CDT)
Message-Id: <200004051716.MAA47906@nt8.americas.sgi.com>
Date:   Wed, 5 Apr 2000 12:16:04 -0500 (CDT)
To:     linux-xfs@oss.sgi.com
Subject: TAKE - 
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing

Modid:  2.3.99pre2-xfs:slinx:56911a
Date:  Wed Apr  5 10:12:59 PDT 2000
Workarea:  nt8.americas.sgi.com:/data/clink/io/cattelan/x2.3-99-xfs

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

linux/fs/xfs/xfs_buf.h - 1.46
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/linux/fs/xfs/xfs_buf.h.diff?r1=text&tr1=1.46&r2=text&tr2=1.45&f=h
	- implement xfs_set_target in pagebuf.

linux/fs/xfs/xfs_log_recover.c - 1.169
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/linux/fs/xfs/xfs_log_recover.c.diff?r1=text&tr1=1.169&r2=text&tr2=1.168&f=h
	- Defined XFS_BUF_SET_TARGET macro for pagebuf metadata. Fixes external
	  logs (and probably other non-data devices) when using pagebuf
	  metadata.
	  Moved log footer checking code to run earlier in the log recovery
	  process.  Fixes the "xfs_find_verify_log_record: need to backup"
	  message when mounting external logs.


From owner-linux-xfs@oss.sgi.com Wed Apr  5 10:18:20 2000
Received:  by oss.sgi.com id <S305166AbQDERSB>;
	Wed, 5 Apr 2000 10:18:01 -0700
Received: from apollo-hhw0374.multiweb.net ([195.114.245.122]:8452 "EHLO
        caps.mine.nu") by oss.sgi.com with ESMTP id <S305167AbQDERRp>;
	Wed, 5 Apr 2000 10:17:45 -0700
Received: from localhost (caps@localhost)
	by caps.mine.nu (8.8.7/8.8.7) with ESMTP id TAA00745
	for <linux-xfs@oss.sgi.com>; Thu, 6 Apr 2000 19:16:35 -0100
Date:   Thu, 6 Apr 2000 19:16:35 -0100 (GMT+1)
From:   Mathieu <caps@caps.mine.nu>
To:     linux-xfs@oss.sgi.com
Subject: Linux + XFS
Message-ID: <Pine.LNX.4.04.10004061909120.648-100000@caps.mine.nu>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing

Hi,

I tried using XFS using the following configuration:
* Celeron 366Mhz, 32mb, IDE base controller,
  AHA1542 SCSI controller (ISA)
* Quantum HD with XFS (IRIX 5.2) 
* RedHat 6.0

I ripped the Quantum HD out of an Indy and I need to mount it
for some reasons. I downloaded the 2.3.99-pre2 kernel with XFS.
The kernel recognizes the SGI partition (sda1 sda2 sda3 sda4)
BUT I'm unable to mount any of the partitions.

The HD came out of an 
SGI Indy IP22
100 Mhz MIPS - 96mb
IRIX 5.2 

(The blue box thingy:-))

Any ideas why I can't mount it?

--=--=--=--=--=--=--=--
Mathieu Kooiman
ggInternet Webdesign
http://www.ggInter.net
--=--=--=--=--=--=--=--




From owner-linux-xfs@oss.sgi.com Wed Apr  5 10:23:20 2000
Received:  by oss.sgi.com id <S305167AbQDERXB>;
	Wed, 5 Apr 2000 10:23:01 -0700
Received: from deliverator.sgi.com ([204.94.214.10]:50793 "EHLO
        deliverator.sgi.com") by oss.sgi.com with ESMTP id <S305166AbQDERWv>;
	Wed, 5 Apr 2000 10:22:51 -0700
Received: from ledzep.cray.com (ledzep.cray.com [137.38.226.97]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id KAA17643
	for <linux-xfs@oss.sgi.com>; Wed, 5 Apr 2000 10:18:09 -0700 (PDT)
	mail_from (lord@sgi.com)
Received: from ironwood-e185.americas.sgi.com (ironwood.cray.com [128.162.185.212]) by ledzep.cray.com (SGI-SGI-8.9.3/craymail-smart-nospam1.0) with ESMTP id MAA34721; Wed, 5 Apr 2000 12:21:34 -0500 (CDT)
Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.184.86]) by ironwood-e185.americas.sgi.com (8.8.4/SGI-ironwood-e1.4) with ESMTP id MAA07155; Wed, 5 Apr 2000 12:21:26 -0500 (CDT)
Received: from jen.americas.sgi.com by jen.americas.sgi.com (8.9.3/SGI-client.1.6) via ESMTP id MAA30384; Wed, 5 Apr 2000 12:21:21 -0500
Message-Id: <200004051721.MAA30384@jen.americas.sgi.com>
X-Mailer: exmh version 2.1.1 10/15/1999
To:     Mathieu <caps@caps.mine.nu>
cc:     linux-xfs@oss.sgi.com
Subject: Re: Linux + XFS 
In-Reply-To: Message from Mathieu <caps@caps.mine.nu> 
   of "Thu, 06 Apr 2000 19:16:35 -0100." <Pine.LNX.4.04.10004061909120.648-100000@caps.mine.nu> 
Date:   Wed, 05 Apr 2000 12:21:20 -0500
From:   Steve Lord <lord@sgi.com>
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing


The short answer here is that the work to make the on disk formats the
same between Linux and  Irix is not done yet. The data is in the same
place, but it is still little endian on i386 Linux. The only way to use
it so far is to make filesystems on Linux.

Steve

> Hi,
> 
> I tried using XFS using the following configuration:
> * Celeron 366Mhz, 32mb, IDE base controller,
>   AHA1542 SCSI controller (ISA)
> * Quantum HD with XFS (IRIX 5.2) 
> * RedHat 6.0
> 
> I ripped the Quantum HD out of an Indy and I need to mount it
> for some reasons. I downloaded the 2.3.99-pre2 kernel with XFS.
> The kernel recognizes the SGI partition (sda1 sda2 sda3 sda4)
> BUT I'm unable to mount any of the partitions.
> 
> The HD came out of an 
> SGI Indy IP22
> 100 Mhz MIPS - 96mb
> IRIX 5.2 
> 
> (The blue box thingy:-))
> 
> Any ideas why I can't mount it?
> 
> --=--=--=--=--=--=--=--
> Mathieu Kooiman
> ggInternet Webdesign
> http://www.ggInter.net
> --=--=--=--=--=--=--=--
> 
> 



From owner-linux-xfs@oss.sgi.com Wed Apr  5 10:27:20 2000
Received:  by oss.sgi.com id <S305171AbQDER1B>;
	Wed, 5 Apr 2000 10:27:01 -0700
Received: from s052.widexs.nl ([212.204.200.1]:41732 "EHLO s052.widexs.nl")
	by oss.sgi.com with ESMTP id <S305166AbQDER0x>;
	Wed, 5 Apr 2000 10:26:53 -0700
Received: from localhost (caps@localhost)
	by s052.widexs.nl (8.9.3/8.9.3) with ESMTP id TAA11094;
	Wed, 5 Apr 2000 19:25:42 +0200
Date:   Wed, 5 Apr 2000 19:25:41 +0200 (MEST)
From:   "Mathieu Kooiman (ggInternet)" <caps@s052.widexs.nl>
Reply-To: mathieu@ggInter.net
To:     Steve Lord <lord@sgi.com>
cc:     Mathieu <caps@caps.mine.nu>, linux-xfs@oss.sgi.com
Subject: Re: Linux + XFS 
In-Reply-To: <200004051721.MAA30384@jen.americas.sgi.com>
Message-ID: <Pine.LNX.4.10.10004051924330.10812-100000@s052.widexs.nl>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing

Ahah, IC..

Is there or will there be any work on this?
I'd even like to try some stuff myself but I guess
that'd take a long long time

CaPS



From owner-linux-xfs@oss.sgi.com Wed Apr  5 10:40:21 2000
Received:  by oss.sgi.com id <S305167AbQDERkB>;
	Wed, 5 Apr 2000 10:40:01 -0700
Received: from pneumatic-tube.sgi.com ([204.94.214.22]:43891 "EHLO
        pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP
	id <S305166AbQDERjk>; Wed, 5 Apr 2000 10:39:40 -0700
Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via SMTP id KAA05710
	for <linux-xfs@oss.sgi.com>; Wed, 5 Apr 2000 10:43:24 -0700 (PDT)
	mail_from (kenmcd@melbourne.sgi.com)
Received: from rattle.melbourne.sgi.com (rattle.melbourne.sgi.com [134.14.55.145]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id DAA27002; Thu, 6 Apr 2000 03:38:20 +1000
Received: from localhost (kenmcd@localhost) by rattle.melbourne.sgi.com (980427.SGI.8.8.8/980728.SGI.AUTOCF) via ESMTP id DAA27256; Thu, 6 Apr 2000 03:38:20 +1000 (EST)
Date:   Thu, 6 Apr 2000 03:38:19 +1000
From:   Ken McDonell <kenmcd@melbourne.sgi.com>
To:     mathieu@ggInter.net
cc:     linux-xfs@oss.sgi.com
Subject: Re: Linux + XFS 
In-Reply-To: <Pine.LNX.4.10.10004051924330.10812-100000@s052.widexs.nl>
Message-ID: <Pine.SGI.4.10.10004060335540.24207-100000@rattle.melbourne.sgi.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing

On Wed, 5 Apr 2000, Mathieu Kooiman (ggInternet) wrote:
> Ahah, IC..
> 
> Is there or will there be any work on this?

We are going at it as hard as we can.  It _will_ be supported.

> I'd even like to try some stuff myself but I guess
> that'd take a long long time

Yep, it is a lot of work, and hard to scope in terms of time
required ... but several people are working on this internally
within SGI.


From owner-linux-xfs@oss.sgi.com Wed Apr  5 10:59:50 2000
Received:  by oss.sgi.com id <S305167AbQDER7b>;
	Wed, 5 Apr 2000 10:59:31 -0700
Received: from deliverator.sgi.com ([204.94.214.10]:55667 "EHLO
        deliverator.sgi.com") by oss.sgi.com with ESMTP id <S305166AbQDER72>;
	Wed, 5 Apr 2000 10:59:28 -0700
Received: from ledzep.cray.com (ledzep.cray.com [137.38.226.97]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id KAA22513
	for <linux-xfs@oss.sgi.com>; Wed, 5 Apr 2000 10:54:45 -0700 (PDT)
	mail_from (cattelan@thebarn.com)
Received: from ironwood-e185.americas.sgi.com (ironwood.cray.com [128.162.185.212]) by ledzep.cray.com (SGI-SGI-8.9.3/craymail-smart-nospam1.0) with ESMTP id MAA69774; Wed, 5 Apr 2000 12:58:10 -0500 (CDT)
Received: from gibble.americas.sgi.com (root@gibble.americas.sgi.com [128.162.195.80]) by ironwood-e185.americas.sgi.com (8.8.4/SGI-ironwood-e1.4) with ESMTP id MAA09341; Wed, 5 Apr 2000 12:58:02 -0500 (CDT)
Received: from thebarn.com by gibble.americas.sgi.com (8.9.3/SGI-client.1.6) via ESMTP id MAA24074; Wed, 5 Apr 2000 12:58:08 -0500
Message-ID: <38EB7EB0.86AED95B@thebarn.com>
Date:   Wed, 05 Apr 2000 12:58:08 -0500
From:   Russell Cattelan <cattelan@thebarn.com>
X-Mailer: Mozilla 4.72 [en] (X11; I; Linux 2.2.14-15mdksmp i686)
X-Accept-Language: en
MIME-Version: 1.0
To:     Mathieu <caps@caps.mine.nu>
CC:     linux-xfs@oss.sgi.com
Subject: Re: Linux + XFS
References: <Pine.LNX.4.04.10004061909120.648-100000@caps.mine.nu>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing

Short answer;
Intel little endian
mips big endian.
XFS supports architecture native format only.
XFS on intel != XFS on mips

Long answer:
Read the list archive.
http://oss.sgi.com/projects/linux-xfs/indexed/threads.html

Mathieu wrote:

> Hi,
>
> I tried using XFS using the following configuration:
> * Celeron 366Mhz, 32mb, IDE base controller,
>   AHA1542 SCSI controller (ISA)
> * Quantum HD with XFS (IRIX 5.2)
> * RedHat 6.0
>
> I ripped the Quantum HD out of an Indy and I need to mount it
> for some reasons. I downloaded the 2.3.99-pre2 kernel with XFS.
> The kernel recognizes the SGI partition (sda1 sda2 sda3 sda4)
> BUT I'm unable to mount any of the partitions.
>
> The HD came out of an
> SGI Indy IP22
> 100 Mhz MIPS - 96mb
> IRIX 5.2
>
> (The blue box thingy:-))
>
> Any ideas why I can't mount it?
>
> --=--=--=--=--=--=--=--
> Mathieu Kooiman
> ggInternet Webdesign
> http://www.ggInter.net
> --=--=--=--=--=--=--=--


From owner-linux-xfs@oss.sgi.com Wed Apr  5 12:11:51 2000
Received:  by oss.sgi.com id <S305167AbQDETLl>;
	Wed, 5 Apr 2000 12:11:41 -0700
Received: from client-141-151-129-90.bellatlantic.net ([141.151.129.90]:62220
        "EHLO router.spinnakernet.com") by oss.sgi.com with ESMTP
	id <S305166AbQDETL0>; Wed, 5 Apr 2000 12:11:26 -0700
Received: from athabasca.spinnakernet.com (IDENT:root@athabasca.spinnakernet.com [10.1.1.129])
	by router.spinnakernet.com (8.9.3/8.8.7) with ESMTP id PAA06819
	for <linux-xfs@oss.sgi.com>; Wed, 5 Apr 2000 15:11:25 -0400
Received: from spinnakernet.com (IDENT:lws@localhost.localdomain [127.0.0.1])
	by athabasca.spinnakernet.com (8.9.3/8.8.7) with ESMTP id PAA01398
	for <linux-xfs@oss.sgi.com>; Wed, 5 Apr 2000 15:11:44 -0400
Message-ID: <38EB8FEF.9CB411C@spinnakernet.com>
Date:   Wed, 05 Apr 2000 15:11:44 -0400
From:   Lyle Seaman <lws@spinnakernet.com>
Organization: Hah.
X-Mailer: Mozilla 4.61 [en] (X11; U; Linux 2.2.12-20 i686)
X-Accept-Language: en
MIME-Version: 1.0
To:     linux-xfs@oss.sgi.com
Subject: Re: XFS as Root filesystem
References: <200004051440.JAA25697@jen.americas.sgi.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing

>
> > ext3 doesn't really "solve" this, but it does step around it: if you
> > mount a filesystem which needs recovery as readonly, then it will
> > warn you that it is enabling write access to the device temporarily
> > and will perform the recovery.  The filesystem retains full ROFS
> > protection, but the device does get written to.  Ext3 does a device
> > check to make sure that the block device is writable before it
> > attempts to do this, and if it is not, it will abort the mount
> > entirely: you can't mount ext3 on readonly media if recovery is
> > needed.
> >
> > --Stephen
>
> Just to report on where XFS is in all of this, it will fail a read only
> mount request if it determines recovery needs to be run. We do have
> a norecovery mount option - but this is really for internal use only,
> I would not recommend using it.
>

How does a readonly filesystem become inconsistent?
(esp: "how does ext3 on readonly media" become inconsistent?)

The obvious answer is "well, it *wasn't* readonly when it
became inconsistent".

If that's the case, then why do you care?  Naively, I wouldn't
think this is a big deal.  Why am I wrong?





From owner-linux-xfs@oss.sgi.com Wed Apr  5 12:25:12 2000
Received:  by oss.sgi.com id <S305167AbQDETZC>;
	Wed, 5 Apr 2000 12:25:02 -0700
Received: from pneumatic-tube.sgi.com ([204.94.214.22]:58633 "EHLO
        pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP
	id <S305166AbQDETYs>; Wed, 5 Apr 2000 12:24:48 -0700
Received: from ledzep.cray.com (ledzep.cray.com [137.38.226.97]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id MAA05539
	for <linux-xfs@oss.sgi.com>; Wed, 5 Apr 2000 12:28:33 -0700 (PDT)
	mail_from (lord@sgi.com)
Received: from ironwood-e185.americas.sgi.com (ironwood.cray.com [128.162.185.212]) by ledzep.cray.com (SGI-SGI-8.9.3/craymail-smart-nospam1.0) with ESMTP id OAA43757; Wed, 5 Apr 2000 14:23:29 -0500 (CDT)
Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.184.86]) by ironwood-e185.americas.sgi.com (8.8.4/SGI-ironwood-e1.4) with ESMTP id OAA14676; Wed, 5 Apr 2000 14:23:22 -0500 (CDT)
Received: from jen.americas.sgi.com by jen.americas.sgi.com (8.9.3/SGI-client.1.6) via ESMTP id OAA05490; Wed, 5 Apr 2000 14:23:16 -0500
Message-Id: <200004051923.OAA05490@jen.americas.sgi.com>
X-Mailer: exmh version 2.1.1 10/15/1999
To:     Lyle Seaman <lws@spinnakernet.com>
cc:     linux-xfs@oss.sgi.com
Subject: Re: XFS as Root filesystem 
In-Reply-To: Message from Lyle Seaman <lws@spinnakernet.com> 
   of "Wed, 05 Apr 2000 15:11:44 EDT." <38EB8FEF.9CB411C@spinnakernet.com> 
Date:   Wed, 05 Apr 2000 14:23:15 -0500
From:   Steve Lord <lord@sgi.com>
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing

> >
> > > ext3 doesn't really "solve" this, but it does step around it: if you
> > > mount a filesystem which needs recovery as readonly, then it will
> > > warn you that it is enabling write access to the device temporarily
> > > and will perform the recovery.  The filesystem retains full ROFS
> > > protection, but the device does get written to.  Ext3 does a device
> > > check to make sure that the block device is writable before it
> > > attempts to do this, and if it is not, it will abort the mount
> > > entirely: you can't mount ext3 on readonly media if recovery is
> > > needed.
> > >
> > > --Stephen
> >
> > Just to report on where XFS is in all of this, it will fail a read only
> > mount request if it determines recovery needs to be run. We do have
> > a norecovery mount option - but this is really for internal use only,
> > I would not recommend using it.
> >
> 
> How does a readonly filesystem become inconsistent?
> (esp: "how does ext3 on readonly media" become inconsistent?)
> 
> The obvious answer is "well, it *wasn't* readonly when it
> became inconsistent".
> 
> If that's the case, then why do you care?  Naively, I wouldn't
> think this is a big deal.  Why am I wrong?
> 


Should XFS (or another logging filesystem) detect that it needs to reply
the log then you really do not know what state the disk is in. XFS first 
writes meta-data to the log, and when it knows this is on disk it allows
the actual on disk meta-data to be written to. The writes to the log are
in the form of transactional changes to the disk structure (e.g. remove
a block from the free space structures and put it in a file, or initialize
an inode and put it in a directory). Say the log write went to disk and
we started doing the meta-data writes, we managed to put the entry in the
directory, but we did not update the inode with the correct information.

If you crash at this point and do not run recovery then you end up with
a directory entry pointing off into la la land - so read only behavior can
be broken.

To complete the picture, recovery consists of reading the log and replaying
it blindly into the meta-data (well semi-blindly, there are complications).


Steve




From owner-linux-xfs@oss.sgi.com Wed Apr  5 12:30:11 2000
Received:  by oss.sgi.com id <S305167AbQDET3w>;
	Wed, 5 Apr 2000 12:29:52 -0700
Received: from pneumatic-tube.sgi.com ([204.94.214.22]:25354 "EHLO
        pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP
	id <S305166AbQDET3j>; Wed, 5 Apr 2000 12:29:39 -0700
Received: from ledzep.cray.com (ledzep.cray.com [137.38.226.97]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id MAA05322
	for <linux-xfs@oss.sgi.com>; Wed, 5 Apr 2000 12:33:25 -0700 (PDT)
	mail_from (mostek@sgi.com)
Received: from ironwood-e185.americas.sgi.com (ironwood.cray.com [128.162.185.212]) by ledzep.cray.com (SGI-SGI-8.9.3/craymail-smart-nospam1.0) with ESMTP id OAA52976; Wed, 5 Apr 2000 14:28:22 -0500 (CDT)
Received: from fsgi344.americas.sgi.com (fsgi344.americas.sgi.com [128.162.184.15]) by ironwood-e185.americas.sgi.com (8.8.4/SGI-ironwood-e1.4) with ESMTP id OAA14969; Wed, 5 Apr 2000 14:28:14 -0500 (CDT)
From:   Jim Mostek <mostek@sgi.com>
Received: by fsgi344.americas.sgi.com (980427.SGI.8.8.8/SGI-client.1.6) id OAA19011; Wed, 5 Apr 2000 14:28:20 -0500 (CDT)
Message-Id: <200004051928.OAA19011@fsgi344.americas.sgi.com>
Subject: Re: XFS as Root filesystem
To:     lws@spinnakernet.com (Lyle Seaman)
Date:   Wed, 5 Apr 2000 14:28:19 -0500 (CDT)
Cc:     linux-xfs@oss.sgi.com
In-Reply-To: <38EB8FEF.9CB411C@spinnakernet.com> from "Lyle Seaman" at Apr 05, 2000 03:11:44 PM
X-Mailer: ELM [version 2.5 PL2]
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing


Hey Lyle, long time no read your typed words! Good to see your around.

Anyway, you are right that the way the file system gets into a state where
it needs to have recovery run is that it was mounted read/write (i.e. not
read-only).

Linux mounts the root, read-only, when it is coming up.
If XFS is the root file system (which was read-write) and the system crashed,
we need to run recovery before it can be mounted read-only.

As I said in an earlier mail, we should just be able to set a new flag on
the mount that says this is a special root mount and that we should run
recovery.

In xlog_recover() in xfs_log.c, we see:

                /*
                 * disallow recovery on read-only mounts.  note -- mount
                 * checks for ENOSPC and turns it into an intelligent
                 * error message.
                 */
                if (readonly)
                        return ENOSPC;


We could have a new flag passed to xlog_recover to override this and
allow recovery.

Jim

>
>>
>> > ext3 doesn't really "solve" this, but it does step around it: if you
>> > mount a filesystem which needs recovery as readonly, then it will
>> > warn you that it is enabling write access to the device temporarily
>> > and will perform the recovery.  The filesystem retains full ROFS
>> > protection, but the device does get written to.  Ext3 does a device
>> > check to make sure that the block device is writable before it
>> > attempts to do this, and if it is not, it will abort the mount
>> > entirely: you can't mount ext3 on readonly media if recovery is
>> > needed.
>> >
>> > --Stephen
>>
>> Just to report on where XFS is in all of this, it will fail a read only
>> mount request if it determines recovery needs to be run. We do have
>> a norecovery mount option - but this is really for internal use only,
>> I would not recommend using it.
>>
>
>How does a readonly filesystem become inconsistent?
>(esp: "how does ext3 on readonly media" become inconsistent?)
>
>The obvious answer is "well, it *wasn't* readonly when it
>became inconsistent".
>
>If that's the case, then why do you care?  Naively, I wouldn't
>think this is a big deal.  Why am I wrong?
>
>
>
>


From owner-linux-xfs@oss.sgi.com Wed Apr  5 14:49:52 2000
Received:  by oss.sgi.com id <S305167AbQDEVtd>;
	Wed, 5 Apr 2000 14:49:33 -0700
Received: from rising.starnet.gov.sg ([203.116.82.211]:15065 "EHLO
        rising.starnet.gov.sg") by oss.sgi.com with ESMTP
	id <S305166AbQDEVtM>; Wed, 5 Apr 2000 14:49:12 -0700
Received: from starnet.gov.sg (dyn1-166cable.bp1.singa.pore.net [202.169.229.166])
	by rising.starnet.gov.sg (8.9.1/8.9.1) with ESMTP id FAA28567;
	Thu, 6 Apr 2000 05:48:58 +0800 (SGT)
Message-ID: <38EBB4B3.5C4397C1@starnet.gov.sg>
Date:   Thu, 06 Apr 2000 05:48:35 +0800
From:   Tan Pong Heng <pongheng@starnet.gov.sg>
X-Mailer: Mozilla 4.7 [en] (X11; I; Linux 2.3.99-pre2 i686)
X-Accept-Language: en
MIME-Version: 1.0
To:     Steve Lord <lord@sgi.com>
CC:     Klaus Strebel <stb@ep-ag.com>, linux-xfs@oss.sgi.com
Subject: Re: XFS as Root filesystem
References: <200004051549.KAA28139@jen.americas.sgi.com>
Content-Type: multipart/mixed;
 boundary="------------6898AF0A7CF82E50682B5C59"
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing

This is a multi-part message in MIME format.
--------------6898AF0A7CF82E50682B5C59
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Steve Lord wrote:

> > I sync with the latest CVS this morning and the boot process when further.
> > It definitely does not like to mount read-only. As it can not be remounted
> > as read-write at the moment. This will break the boot process in big way.
> > Anyway, I read tried with the root mounted read-write and it when further
> > and still hang somewhere after the building of window manager session.
> > (I am using Mandrake 7 as the base.) I could kill the hang process and
> > continue.
> > But, the system finally came into the login processes. But, the gdm could
> > not
> > start - and will retry forever. As such, I could not get a usable system.
> > The system did try to start the X server and it did tried to change the
> > video
> > mode but could not complete. Are all the various inode type supported on
> > XFS?
> > That could be the reason. Since with XFS as root filesystem, there will be
> > need
> > to create all kind of inodes for devices, pipe, fifo, sockets, etc on it.
> > Some of
> > these may not be supported or does not work correctly....
> >
> > I will investigate further when I have the time...
> >
>
> In theory devices/fifos etc should work - but I am not surprised if we have
> problems. We need to narrow down exactly what is not working. If you set
> your default run level to something which does not run X (level 3 on redhat,
> so I suspect mandrake is the same) and then do a startx and capture the
> output in a file it might tell us something.
>
> Thanks
>
>    Steve

I suspect the problem is related to the handling of sockets. The reasons being:

1) When I rsync the root filesystem to xfs - I received some error messages
about
    some files - when I checked these are sockets.
2) When gdm startup, it will start a X server and when try to contact it
through
    the socket in /tmp/.X11-unix/X0
3) The attached messages from /var/log/messages from the failed XFS partition
     indicate that syslogd is having problem with sockets too (or so
I assumed....)

I have also attached the dmesg from /var/log for your reference - both are from

the XFS partition and show the partial boot process...

--------------6898AF0A7CF82E50682B5C59
Content-Type: text/plain; charset=us-ascii;
 name="messages"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline;
 filename="messages"

Apr  5 20:18:40 dyn1-166cable syslogd 1.3-3: restart.
Apr  5 20:18:40 dyn1-166cable syslogd: select: Bad file descriptor
Apr  5 20:19:11 dyn1-166cable last message repeated 1153654 times
Apr  5 20:20:12 dyn1-166cable last message repeated 2310719 times

--------------6898AF0A7CF82E50682B5C59
Content-Type: text/plain; charset=us-ascii;
 name="dmesg"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline;
 filename="dmesg"

>Processors: 2
mapped APIC to ffffe000 (fee00000)
mapped IOAPIC to ffffd000 (fec00000)
Initializing CPU#0
Detected 456512500 Hz processor.
ide_setup: hdd=ide-scsi
Console: colour VGA+ 80x25
Calibrating delay loop... 910.95 BogoMIPS
Memory: 125496k/131008k available (1751k kernel code, 5124k reserved, 121k data, 168k init, 0k highmem)
Buffer-cache hash table entries: 4096 (order: 2, 16384 bytes)
Page-cache hash table entries: 32768 (order: 5, 131072 bytes)
VFS: Diskquotas version dquot_6.4.0 initialized
Checking 386/387 coupling... OK, FPU using exception 16 error reporting.
Checking 'hlt' instruction... OK.
POSIX conformance testing by UNIFIX
mtrr: v1.36 (20000221) Richard Gooch (rgooch@atnf.csiro.au)
CPU0: Intel Celeron (Mendocino) stepping 05
per-CPU timeslice cutoff: 357.24 usecs.
Getting VERSION: 40011
Getting VERSION: 40011
Getting LVT0: 700
Getting LVT1: 400
enabled ExtINT on CPU#0
ESR value before enabling vector: 00000000
ESR value after enabling vector: 00000000
CPU present map: 3
Booting processor 1 eip 2000
Setting warm reset code and vector.
1.
2.
3.
Asserting INIT.
Deasserting INIT.
#startup loops: 2.
Sending STARTUP #1.
After apic_write.
Startup point 1.
Waiting for send to finish...
+Sending STARTUP #2.
After apic_write.
Startup point 1.
Waiting for send to finish...
+After Startup.
Before Callout 1.
After Callout 1.
Initializing CPU#1
CPU#1 (phys ID: 1) waiting for CALLOUT
CALLIN, before setup_local_APIC().
masked ExtINT on CPU#1
ESR value before enabling vector: 00000000
ESR value after enabling vector: 00000000
Calibrating delay loop... 910.95 BogoMIPS
Stack at about c7febfbc
OK.
CPU1: Intel Celeron (Mendocino) stepping 05
CPU has booted.
Before bogomips.
Total of 2 processors activated (1821.90 BogoMIPS).
Before bogocount - setting activated=1.
Boot done.
ENABLING IO-APIC IRQs
...changing IO-APIC physical APIC ID to 2 ... ok.
init IO_APIC IRQs
 IO-APIC (apicid-pin) 2-0, 2-5, 2-9, 2-10, 2-11, 2-20, 2-21, 2-22, 2-23 not connected.
..TIMER: vector=81 pin1=2 pin2=0
activating NMI Watchdog ... done.
number of MP IRQ sources: 16.
number of IO-APIC #2 registers: 24.
testing the IO APIC.......................

IO APIC #2......
.... register #00: 02000000
.......    : physical APIC id: 02
.... register #01: 00170011
.......     : max redirection entries: 0017
.......     : IO APIC version: 0011
.... register #02: 00000000
.......     : arbitration: 00
.... IRQ redirection table:
 NR Log Phy Mask Trig IRR Pol Stat Dest Deli Vect:   
 00 000 00  1    0    0   0   0    0    0    00
 01 0FF 0F  0    0    0   0   0    1    1    59
 02 0FF 0F  0    0    0   0   0    1    1    51
 03 0FF 0F  0    0    0   0   0    1    1    61
 04 0FF 0F  0    0    0   0   0    1    1    69
 05 000 00  1    0    0   0   0    0    0    00
 06 0FF 0F  0    0    0   0   0    1    1    71
 07 0FF 0F  0    0    0   0   0    1    1    79
 08 0FF 0F  0    0    0   0   0    1    1    81
 09 000 00  1    0    0   0   0    0    0    00
 0a 000 00  1    0    0   0   0    0    0    00
 0b 000 00  1    0    0   0   0    0    0    00
 0c 0FF 0F  0    0    0   0   0    1    1    89
 0d 000 00  1    0    0   0   0    0    0    00
 0e 0FF 0F  0    0    0   0   0    1    1    91
 0f 0FF 0F  0    0    0   0   0    1    1    99
 10 0FF 0F  1    1    0   1   0    1    1    A1
 11 0FF 0F  1    1    0   1   0    1    1    A9
 12 0FF 0F  1    1    0   1   0    1    1    B1
 13 0FF 0F  1    1    0   1   0    1    1    B9
 14 000 00  1    0    0   0   0    0    0    00
 15 000 00  1    0    0   0   0    0    0    00
 16 000 00  1    0    0   0   0    0    0    00
 17 000 00  1    0    0   0   0    0    0    00
IRQ to pin mappings:
IRQ0 -> 2
IRQ1 -> 1
IRQ3 -> 3
IRQ4 -> 4
IRQ5 -> 17
IRQ6 -> 6
IRQ7 -> 7
IRQ8 -> 8
IRQ9 -> 16
IRQ10 -> 19
IRQ11 -> 18
IRQ12 -> 12
IRQ13 -> 13
IRQ14 -> 14
IRQ15 -> 15
.................................... done.
calibrating APIC timer ... 
..... CPU clock speed is 456.5161 MHz.
..... host bus clock speed is 83.0027 MHz.
cpu: 0, clocks: 830027, slice: 276675
CPU0<C0:830016,C:553328,D:13,S:276675,C:830027>
cpu: 1, clocks: 830027, slice: 276675
CPU1<C0:830016,C:276656,D:10,S:276675,C:830027>
checking TSC synchronization across CPUs: passed.
Setting commenced=1, go go go
mtrr: your CPUs had inconsistent fixed MTRR settings
mtrr: probably your BIOS does not setup all CPUs
PCI: PCI BIOS revision 2.10 entry at 0xfb6d0
PCI: Using configuration type 1
PCI: Probing PCI hardware
PCI: Interrupt Routing Table found at 0xc00fd8f0 [router type 8086/7000]
Limiting direct PCI/PCI transfers.
isapnp: Scanning for Pnp cards...
isapnp: No Plug & Play device found
Linux NET4.0 for Linux 2.3
Based upon Swansea University Computer Society NET3.039
NET4: Unix domain sockets 1.0/SMP for Linux NET4.0.
NET4: Linux TCP/IP 1.0 for NET4.0
IP Protocols: ICMP, UDP, TCP, IGMP
IP: routing cache hash table of 256 buckets, 4Kbytes
TCP: Hash tables configured (established 4096 bind 5461)
Initializing RT netlink socket
Starting kswapd v1.6
Serial driver version 4.92 (2000-1-27) with MANY_PORTS SHARE_IRQ SERIAL_PCI ISAPNP enabled
ttyS00 at 0x03f8 (irq = 4) is a 16550A
ttyS01 at 0x02f8 (irq = 3) is a 16550A
pty: 256 Unix98 ptys configured
Uniform Multi-Platform E-IDE driver Revision: 6.30
ide: Assuming 40MHz system bus speed for PIO modes; override with idebus=xx
PIIX4: IDE controller on PCI bus 00 dev 39
PIIX4: not 100% native mode: will probe irqs later
    ide0: BM-DMA at 0xf000-0xf007, BIOS settings: hda:pio, hdb:pio
    ide1: BM-DMA at 0xf008-0xf00f, BIOS settings: hdc:DMA, hdd:pio
HPT366: onboard version of chipset, pin1=1 pin2=2
HPT366: IDE controller on PCI bus 00 dev 98
HPT366: not 100% native mode: will probe irqs later
    ide2: BM-DMA at 0xd800-0xd807, BIOS settings: hde:DMA, hdf:pio
HPT366: IDE controller on PCI bus 00 dev 99
HPT366: not 100% native mode: will probe irqs later
    ide3: BM-DMA at 0xe400-0xe407, BIOS settings: hdg:DMA, hdh:pio
hdc: Pioneer DVD-ROM ATAPIModel DVD-103S 011, ATAPI CDROM drive
hdd: CREATIVE CD-RW RW4224E, ATAPI CDROM drive
hde: QUANTUM FIREBALL CR13.0A, ATA DISK drive
hdg: Maxtor 52049U4, ATA DISK drive
ide1 at 0x170-0x177,0x376 on irq 15
ide2 at 0xd000-0xd007,0xd402 on irq 11
ide3 at 0xdc00-0xdc07,0xe002 on irq 11
hde: QUANTUM FIREBALL CR13.0A, 12416MB w/418kB Cache, CHS=25228/16/63, UDMA(66)
hdg: Maxtor 52049U4, 19541MB w/2048kB Cache, CHS=39703/16/63, UDMA(66)
hdc: ATAPI DVD-ROM drive, 512kB Cache, UDMA(33)
Uniform CD-ROM driver Revision: 3.07
Partition check:
 hde: [PTBL] [1582/255/63] hde1 hde2 hde3 < hde5 hde6 hde7 hde8 > hde4
 hdg: [PTBL] [2491/255/63] hdg1 hdg2 < hdg5 hdg6 hdg7 hdg8 >
Floppy drive(s): fd0 is 1.44M
FDC 0 is a post-1991 82077
Real Time Clock Driver v1.10b
3c59x.c:v0.99H+lk1.0 Feb 9, 2000 The Linux Kernel Team http://cesdis.gsfc.nasa.gov/linux/drivers/vortex.html
eth0: 3Com 3c900 Boomerang 10baseT at 0xcc00,  00:60:08:a9:e0:82, IRQ 10
  8K word-wide RAM 3:5 Rx:Tx split, autoselect/10baseT interface.
  Enabling bus-master transmits and whole-frame receives.
Entering init_xfs_fs
Exiting  init_xfs_fs
Invalid session number or type of track
Invalid session number
XFS Mode = NATIVE, arch=1
Start mounting filesystem: ide3(34,7)
Ending clean XFS mount for filesystem: ide3(34,7)
VFS: Mounted root (xfs filesystem).
Freeing unused kernel memory: 168k freed
Adding Swap: 112416k swap-space (priority -1)
Adding Swap: 136512k swap-space (priority -2)
XFS:  Hoser!!!  Somebody called remountfs()
Creative EMU10K1 PCI Audio Driver, version 0.5 , 09:26:59 Apr  2 2000
emu10k1: emu10k1 rev 7 found at IO 0xc400, IRQ 5
hdd: driver not present
hdd: driver not present

--------------6898AF0A7CF82E50682B5C59--


From owner-linux-xfs@oss.sgi.com Wed Apr  5 14:57:23 2000
Received:  by oss.sgi.com id <S305167AbQDEV5D>;
	Wed, 5 Apr 2000 14:57:03 -0700
Received: from deliverator.sgi.com ([204.94.214.10]:39491 "EHLO
        deliverator.sgi.com") by oss.sgi.com with ESMTP id <S305166AbQDEV5C>;
	Wed, 5 Apr 2000 14:57:02 -0700
Received: from info.engr.sgi.com (info.engr.sgi.com [192.26.80.216]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id OAA24429; Wed, 5 Apr 2000 14:52:20 -0700 (PDT)
	mail_from (nobody@info.engr.sgi.com)
Received: (from nobody@localhost) by info.engr.sgi.com (980427.SGI.8.8.8/980728.SGI.AUTOCF) id OAA38230; Wed, 5 Apr 2000 14:56:59 -0700 (PDT)
Date:   Wed, 5 Apr 2000 14:56:59 -0700 (PDT)
Message-Id: <200004052156.OAA38230@info.engr.sgi.com>
X-Pv-Incident: 787178 
webPV:  sgigate.sgi.com 
webExec: webpvsubmit,PvProjectIncident 
Reply-To: sgi.bugs.xfs@fido.engr.sgi.com
From:   pv@fddi-odin.corp.sgi.com (mostek@sgi.com)
Subject: BUG 787178 - update times not correctly handled in write
To:     mostek@sgi.com
Cc:     linux-xfs@oss.sgi.com
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing

View Incident: http://co-op.engr.sgi.com/BugWorks/code/bwxquery.cgi?search=Search&wlong=1&view_type=Bug&wi=787178

Submitter : mostek                    Submitter Domain : sgi.com            
Assigned Engineer : mostek            Assigned Domain : sgi.com             
Assigned Group : xfs-linux            Category : software                   
Customer Reported : F                 Priority : 2                          
Project : xfs-linux                   Status : open                         
Description :
When doing a kernel build on XFS on 2.3.99-pre2, I can see that
the output file's date is not correct.

Here is the command running:

make EXTRAVERSION=-xfs bzImage > bz1.out 2>&1


Here is the output of ls -ltr in the same directory:

[root@carlos linux]# ls -ltr
total 204
drwxr-xr-x  13 mostek   wheel         130 Apr  5 16:11 arch/
-r--r--r--   1 mostek   wheel       17133 Apr  5 16:11 Makefile
-r--r--r--   1 mostek   wheel        8056 Apr  5 16:11 Rules.make
-rwxr-xr-x   1 root     root          359 Apr  5 16:42 mall*
-rw-r--r--   1 root     root         1057 Apr  5 16:42 mc.out
-rw-r--r--   1 root     root        59300 Apr  5 16:43 md.out
drwxr-xr-x  31 mostek   wheel        4096 Apr  5 16:43 drivers/
-rw-r--r--   1 root     root        63199 Apr  5 16:44 bz1.out
drwxr-xr-x   6 mostek   wheel        4096 Apr  5 16:44 scripts/
drwxr-xr-x  21 mostek   wheel        4096 Apr  5 16:44 include/
drwxr-xr-x   2 mostek   wheel          64 Apr  5 16:44 init/
drwxr-xr-x   2 mostek   wheel        4096 Apr  5 16:45 kernel/
drwxr-xr-x   2 mostek   wheel        4096 Apr  5 16:47 mm/
drwxr-xr-x  37 mostek   wheel        4096 Apr  5 16:48 fs/
drwxr-xr-x  26 mostek   wheel        4096 Apr  5 16:49 net/
drwxr-xr-x   2 mostek   wheel        4096 Apr  5 16:49 ipc/
drwxr-xr-x   2 mostek   wheel        4096 Apr  5 16:49 lib/
drwxr-xr-x   3 mostek   wheel        4096 Apr  5 16:49 kdb/

From owner-linux-xfs@oss.sgi.com Wed Apr  5 15:12:13 2000
Received:  by oss.sgi.com id <S305167AbQDEWLx>;
	Wed, 5 Apr 2000 15:11:53 -0700
Received: from deliverator.sgi.com ([204.94.214.10]:45895 "EHLO
        deliverator.sgi.com") by oss.sgi.com with ESMTP id <S305166AbQDEWLT>;
	Wed, 5 Apr 2000 15:11:19 -0700
Received: from ledzep.cray.com (ledzep.cray.com [137.38.226.97]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id PAA26457
	for <linux-xfs@oss.sgi.com>; Wed, 5 Apr 2000 15:06:37 -0700 (PDT)
	mail_from (mostek@sgi.com)
Received: from ironwood-e185.americas.sgi.com (ironwood.cray.com [128.162.185.212]) by ledzep.cray.com (SGI-SGI-8.9.3/craymail-smart-nospam1.0) with ESMTP id RAA21228 for <linux-xfs@oss.sgi.com>; Wed, 5 Apr 2000 17:08:48 -0500 (CDT)
Received: from fsgi344.americas.sgi.com (fsgi344.americas.sgi.com [128.162.184.15]) by ironwood-e185.americas.sgi.com (8.8.4/SGI-ironwood-e1.4) with ESMTP id RAA24440 for <linux-xfs@oss.sgi.com>; Wed, 5 Apr 2000 17:08:40 -0500 (CDT)
From:   Jim Mostek <mostek@sgi.com>
Received: by fsgi344.americas.sgi.com (980427.SGI.8.8.8/SGI-client.1.6) id RAA37668; Wed, 5 Apr 2000 17:08:45 -0500 (CDT)
Message-Id: <200004052208.RAA37668@fsgi344.americas.sgi.com>
Subject: problem reports ...
To:     linux-xfs@oss.sgi.com
Date:   Wed, 5 Apr 2000 17:08:45 -0500 (CDT)
X-Mailer: ELM [version 2.5 PL2]
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing



For now, we are going to start using SGI's internal BugWorks to keep track
of problems. I have created a mail alias to linux-xfs@oss.sgi.com
so that people can see the bugs as they come in and are updated.

For those of you who have access, use:

http://co-op.engr.sgi.com/BugWorks/code/bwxsubmit.cgi

and enter group & project xfs-linux

Then enter at least the required fields.

Thanks,

Jim

From owner-linux-xfs@oss.sgi.com Wed Apr  5 19:47:56 2000
Received:  by oss.sgi.com id <S305167AbQDFCrp>;
	Wed, 5 Apr 2000 19:47:45 -0700
Received: from deliverator.sgi.com ([204.94.214.10]:48950 "EHLO
        deliverator.sgi.com") by oss.sgi.com with ESMTP id <S305166AbQDFCrV>;
	Wed, 5 Apr 2000 19:47:21 -0700
Received: from ledzep.cray.com (ledzep.cray.com [137.38.226.97]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id TAA16700
	for <linux-xfs@oss.sgi.com>; Wed, 5 Apr 2000 19:42:38 -0700 (PDT)
	mail_from (lord@sgi.com)
Received: from ironwood-e185.americas.sgi.com (ironwood.cray.com [128.162.185.212]) by ledzep.cray.com (SGI-SGI-8.9.3/craymail-smart-nospam1.0) with ESMTP id VAA09763; Wed, 5 Apr 2000 21:46:03 -0500 (CDT)
Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.184.86]) by ironwood-e185.americas.sgi.com (8.8.4/SGI-ironwood-e1.4) with ESMTP id VAA01022; Wed, 5 Apr 2000 21:45:55 -0500 (CDT)
From:   Steve Lord <lord@sgi.com>
Received: from jen.americas.sgi.com by jen.americas.sgi.com (8.9.3/SGI-client.1.6) via ESMTP id VAA10372; Wed, 5 Apr 2000 21:45:46 -0500
Message-Id: <200004060245.VAA10372@jen.americas.sgi.com>
To:     Tan Pong Heng <pongheng@starnet.gov.sg>
cc:     Klaus Strebel <stb@ep-ag.com>, linux-xfs@oss.sgi.com
Subject: Re: XFS as Root filesystem 
In-reply-to: Your message of "Thu, 06 Apr 2000 05:48:35 +0800
Date:   Wed, 05 Apr 2000 21:45:45 -0500
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing

> >
> > In theory devices/fifos etc should work - but I am not surprised if we have
> > problems. We need to narrow down exactly what is not working. If you set
> > your default run level to something which does not run X (level 3 on redhat
,
> > so I suspect mandrake is the same) and then do a startx and capture the
> > output in a file it might tell us something.
> >
> > Thanks
> >
> >    Steve
> 
> I suspect the problem is related to the handling of sockets. The reasons bein
g:
> 
> 1) When I rsync the root filesystem to xfs - I received some error messages
> about
>     some files - when I checked these are sockets.
> 2) When gdm startup, it will start a X server and when try to contact it
> through
>     the socket in /tmp/.X11-unix/X0
> 3) The attached messages from /var/log/messages from the failed XFS partition
>      indicate that syslogd is having problem with sockets too (or so
> I assumed....)
> 

OK, named pipies and sockets were working at one point, they
are currently broken - it will not let you create them, someone
seems to have changed mknod and forgot about anything but block and char
devices...

I have a fix which turns them back on, I will clean it up and send it
out tomorrow.

Steve


From owner-linux-xfs@oss.sgi.com Thu Apr  6 05:38:19 2000
Received:  by oss.sgi.com id <S305166AbQDFMh7>;
	Thu, 6 Apr 2000 05:37:59 -0700
Received: from timbuk-fddi.cray.com ([128.162.8.102]:46792 "EHLO
        timbuk.cray.com") by oss.sgi.com with ESMTP id <S305164AbQDFMh5>;
	Thu, 6 Apr 2000 05:37:57 -0700
Received: from clink.americas.sgi.com (clink.cray.com [128.162.84.70]) by timbuk.cray.com (8.8.8/CRI-gate-news-1.3) with ESMTP id HAA00116 for <linux-xfs@oss.sgi.com>; Thu, 6 Apr 2000 07:37:52 -0500 (CDT)
Received: (from lord@localhost) by clink.americas.sgi.com (980427.SGI.8.8.8/CRI-news-1.3) id HAA47048 for linux-xfs@oss.sgi.com; Thu, 6 Apr 2000 07:37:54 -0500 (CDT)
Date:   Thu, 6 Apr 2000 07:37:54 -0500 (CDT)
From:   Steve Lord <lord@sgi.com>
Message-Id: <200004061237.HAA47048@clink.americas.sgi.com>
To:     linux-xfs@oss.sgi.com
Subject: TAKE - turn named pipes back on
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing

Modid:  2.3.99pre2-xfs:slinx:56996a
Date:  Thu Apr  6 05:37:04 PDT 2000
Workarea:  clink.americas.sgi.com:/data/clink/io/lord/xfs-linux

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

linux/fs/xfs/linux/xfs_iops.c - 1.44
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/linux/fs/xfs/linux/xfs_iops.c.diff?r1=text&tr1=1.44&r2=text&tr2=1.43&f=h
	- Allow mknod to function for devices other than block and char

linux/fs/xfs/linux/xfs_random.c - 1.30
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/linux/fs/xfs/linux/xfs_random.c.diff?r1=text&tr1=1.30&r2=text&tr2=1.29&f=h
	- Remove spec_vp

linux/fs/xfs/pseudo-inc/sys/vnode.h - 1.18
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/linux/fs/xfs/pseudo-inc/sys/vnode.h.diff?r1=text&tr1=1.18&r2=text&tr2=1.17&f=h
	- Extend definition of ISVDEV

linux/fs/xfs/xfs_mount.c - 1.216
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/linux/fs/xfs/xfs_mount.c.diff?r1=text&tr1=1.216&r2=text&tr2=1.215&f=h
linux/fs/xfs/xfs_vfsops.c - 1.263
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/linux/fs/xfs/xfs_vfsops.c.diff?r1=text&tr1=1.263&r2=text&tr2=1.262&f=h
	- Remove unused include

linux/fs/xfs/xfs_vnodeops.c - 1.450
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/linux/fs/xfs/xfs_vnodeops.c.diff?r1=text&tr1=1.450&r2=text&tr2=1.449&f=h
	- Remove calls to spec_vp they do nothing


From owner-linux-xfs@oss.sgi.com Thu Apr  6 06:48:23 2000
Received:  by oss.sgi.com id <S305167AbQDFNsN>;
	Thu, 6 Apr 2000 06:48:13 -0700
Received: from pneumatic-tube.sgi.com ([204.94.214.22]:37457 "EHLO
        pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP
	id <S305164AbQDFNrt>; Thu, 6 Apr 2000 06:47:49 -0700
Received: from ledzep.cray.com (ledzep.cray.com [137.38.226.97]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id GAA03234
	for <linux-xfs@oss.sgi.com>; Thu, 6 Apr 2000 06:51:36 -0700 (PDT)
	mail_from (mostek@sgi.com)
Received: from ironwood-e185.americas.sgi.com (ironwood.cray.com [128.162.185.212]) by ledzep.cray.com (SGI-SGI-8.9.3/craymail-smart-nospam1.0) with ESMTP id IAA64261 for <linux-xfs@oss.sgi.com>; Thu, 6 Apr 2000 08:46:33 -0500 (CDT)
Received: from fsgi344.americas.sgi.com (fsgi344.americas.sgi.com [128.162.184.15]) by ironwood-e185.americas.sgi.com (8.8.4/SGI-ironwood-e1.4) with ESMTP id IAA16948; Thu, 6 Apr 2000 08:46:25 -0500 (CDT)
From:   Jim Mostek <mostek@sgi.com>
Received: by fsgi344.americas.sgi.com (980427.SGI.8.8.8/SGI-client.1.6) id IAA37824; Thu, 6 Apr 2000 08:46:31 -0500 (CDT)
Message-Id: <200004061346.IAA37824@fsgi344.americas.sgi.com>
Subject: Re: XFS allocation tools
To:     cwf@sgi.com (Charles Fumuso)
Date:   Thu, 6 Apr 2000 08:46:31 -0500 (CDT)
Cc:     linux-xfs@oss.sgi.com
In-Reply-To: <200004042106.QAA26193@milo.americas.sgi.com> from "Charles Fumuso" at Apr 04, 2000 04:06:27 PM
X-Mailer: ELM [version 2.5 PL2]
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing


This looks great!

I see that the new code is already in the linux port tree.
We should add support for other Linux volume managers.

Jim

>
>As part of some allocation improvements, I've written
>some tools to display where the XFS allocations occur.
>
>Please take a look at these commands and let me know 
>what you think.
>
>Thanks,
>-Charles
>
>The first is an addition to xfs_bmap(1).  A new '-v' flag will
>display allocation group information.
> 
>% xfs_bmap -v /tst/d2/T1
>/tst/d2/T1:
> EXT: FILE-OFFSET           BLOCK-RANGE        AG AG-OFFSET          TOTAL  FLG
>   0: [0..2090287]:         4180768..6271055    2 64..2090351      2090288
>   1: [2090288..4180575]:   6271120..8361407    3 64..2090351      2090288
>   2: [4180576..6270863]:   8361472..10451759   4 64..2090351      2090288
>   3: [6270864..8361151]:   10451824..12542111  5 64..2090351      2090288
>   4: [8361152..10451439]:  12542176..14632463  6 64..2090351      2090288
>   5: [10451440..10485759]: 2090448..2124767    1 96..34415          34320
>
>Just in case it isn't obvious, the "AG" field is the AG number and 
>"AG-OFFSET" field is the filesystem block range within the given AG.
>
>The FLG field is to mark files that do not lie on stripe boundaries.
>For example...
>
>% xfs_bmap -v /tst/T1
>/tst/T1:
> EXT: FILE-OFFSET      BLOCK-RANGE      AG AG-OFFSET        TOTAL  FLG
>   0: [0..63]:         160..223          0 160..223            64 0011
> FLG Values:
>    01000 Doesn't begin on stripe unit
>    00100 Doesn't end   on stripe unit
>    00010 Doesn't begin on stripe width
>    00001 Doesn't end   on stripe width
>
>
>The other tool is a new command to display where the AG's fall
>relative to the XVM volume elements.  I'm not sure this is something
>we want in the field just yet.  It may give the customer more
>questions then answers currently.  What do you think?
>
>The following is the output for a concat subvolume...
>
>% xfs_info /tst
>Device:         /hw/vol/local/tsttmp
>Mountpnt:       /tst
>Volume:         vol/tsttmp
>    subvol/tsttmp/data                                 33445528
>        concat/concat12                                33445528
>            concat/concat10                             8388608
>                slice/tsts0                             2097152
>                    AG   0        0..2090351
>                    AG   1  2090352..2097151
>                slice/tsts1                             2097152
>                    AG   1  2097152..4180703
>                    AG   2  4180704..4194303
>                slice/tsts2                             2097152
>                    AG   2  4194304..6271055
>                    AG   3  6271056..6291455
>                slice/tsts3                             2097152
>                    AG   3  6291456..8361407
>                    AG   4  8361408..8388607
>            concat/concat11                            25056920
>                slice/tsts4                             4194304
>                    AG   4  8388608..10451759
>                    AG   5 10451760..12542111
>                    AG   6 12542112..12582911
>                slice/tsts5                             4194304
>                    AG   6 12582912..14632463
>                    AG   7 14632464..16722815
>                    AG   8 16722816..16777215
>                slice/tsts6                             4194304
>                    AG   8 16777216..18813167
>                    AG   9 18813168..20903519
>                    AG  10 20903520..20971519
>                slice/tsts7                             4194304
>                    AG  10 20971520..22993871
>                    AG  11 22993872..25084223
>                    AG  12 25084224..25165823
>                slice/tsts8                             4194304
>                    AG  12 25165824..27174575
>                    AG  13 27174576..29264927
>                    AG  14 29264928..29360127
>                slice/tsts9                             4085400
>                    AG  14 29360128..31355279
>                    AG  15 31355280..33445527
>
>Just like with xfs_bmap, all values are given in 512 byte blocks.
>The output shows the AG block spans and on which slice(s) the AG
>exists.
>
>No effort is done to break out each stripe so the output might
>look like the following:
>
>% xfs_info /xvm/stripe0
>Device:         /dev/cxvm/stripe0
>Mountpnt:       /xvm/stripe0
>Volume:         vol/stripe0
>    subvol/stripe0/data                                 8885376
>        stripe/stripe1                                  8885376
>            AG   0       0..1110911
>            AG   1 1110912..2221823
>            AG   2 2221824..3332735
>            AG   3 3332736..4443647
>            AG   4 4443648..5554559
>            AG   5 5554560..6665471
>            AG   6 6665472..7776383
>            AG   7 7776384..8885375
>
>
>For non XVM volumes, Each AG and it's block span is printed:
>
>% xfs_info /           
>Device:         /dev/root
>Mountpnt:       /
>    AG   0       0..1077791
>    AG   1 1077792..2155583
>    AG   2 2155584..3233375
>    AG   3 3233376..4311167
>    AG   4 4311168..5388959
>    AG   5 5388960..6466751
>    AG   6 6466752..7544543
>    AG   7 7544544..8622295
>


From owner-linux-xfs@oss.sgi.com Thu Apr  6 08:20:24 2000
Received:  by oss.sgi.com id <S305167AbQDFPUP>;
	Thu, 6 Apr 2000 08:20:15 -0700
Received: from dukat.scot.redhat.com ([195.89.149.246]:59660 "EHLO
        dukat.scot.redhat.com") by oss.sgi.com with ESMTP
	id <S305164AbQDFPUE>; Thu, 6 Apr 2000 08:20:04 -0700
Received: (from sct@localhost)
	by dukat.scot.redhat.com (8.9.3/8.9.3) id QAA14751;
	Thu, 6 Apr 2000 16:18:36 +0100
Date:   Thu, 6 Apr 2000 16:18:35 +0100
From:   "Stephen C. Tweedie" <sct@redhat.com>
To:     Jim Mostek <mostek@sgi.com>
Cc:     Klaus Strebel <stb@ep-ag.com>, linux-xfs@oss.sgi.com,
        Stephen Tweedie <sct@redhat.com>
Subject: Re: XFS as Root filesystem
Message-ID: <20000406161835.A14727@redhat.com>
References: <38EB2FEA.E22A0E8B@ep-ag.com> <200004051248.HAA38406@fsgi344.americas.sgi.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 1.0.1i
In-Reply-To: <200004051248.HAA38406@fsgi344.americas.sgi.com>; from mostek@sgi.com on Wed, Apr 05, 2000 at 07:48:21AM -0500
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing

Hi,

On Wed, Apr 05, 2000 at 07:48:21AM -0500, Jim Mostek wrote:
> 
> If you look at the code, the XFS_MOUNT_NORECOVERY flag is set
> to skip recovery. But, we must already have a consistent file system when
> this flag is used.  This is not what we should use for a read-only mount
> of root. We need a separate flag. xlog_recovery would then do recovery
> even on read-only mounts. Anyone have time to do this? I'll add this to
> the mount as root work item.

Don't forget that readonly support also requires the ability to 
remount the filesystem between ro and rw, and the ability to suspend
atime updates while the filesystem is readonly.

--Stephen

From owner-linux-xfs@oss.sgi.com Thu Apr  6 08:22:34 2000
Received:  by oss.sgi.com id <S305171AbQDFPWY>;
	Thu, 6 Apr 2000 08:22:24 -0700
Received: from dukat.scot.redhat.com ([195.89.149.246]:61196 "EHLO
        dukat.scot.redhat.com") by oss.sgi.com with ESMTP
	id <S305164AbQDFPWO>; Thu, 6 Apr 2000 08:22:14 -0700
Received: (from sct@localhost)
	by dukat.scot.redhat.com (8.9.3/8.9.3) id QAA14771;
	Thu, 6 Apr 2000 16:21:44 +0100
Date:   Thu, 6 Apr 2000 16:21:44 +0100
From:   "Stephen C. Tweedie" <sct@redhat.com>
To:     Lyle Seaman <lws@spinnakernet.com>
Cc:     linux-xfs@oss.sgi.com, Stephen Tweedie <sct@redhat.com>
Subject: Re: XFS as Root filesystem
Message-ID: <20000406162144.B14727@redhat.com>
References: <200004051440.JAA25697@jen.americas.sgi.com> <38EB8FEF.9CB411C@spinnakernet.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 1.0.1i
In-Reply-To: <38EB8FEF.9CB411C@spinnakernet.com>; from lws@spinnakernet.com on Wed, Apr 05, 2000 at 03:11:44PM -0400
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing

Hi,

On Wed, Apr 05, 2000 at 03:11:44PM -0400, Lyle Seaman wrote:
> 
> How does a readonly filesystem become inconsistent?
> (esp: "how does ext3 on readonly media" become inconsistent?)
> 
> The obvious answer is "well, it *wasn't* readonly when it
> became inconsistent".
> 
> If that's the case, then why do you care?  Naively, I wouldn't
> think this is a big deal.  Why am I wrong?

Because (a) existing Linux installations expect to mount the
root filesystem readonly until basic consistency checking has
been done; and (b) after a cold reboot, the filesystem will 
need recovery before it can be mounted.

In practice there is no problem mounting the root filesystem
read-write if you have journaling, with one important exception:
if you detect actual errors on the fs such that a constency 
check is required, mounting the fs read-write is dangerous.
(Ext2/ext3 mark an error flag in the superblock if they detect
dangerous inconsistencies in the fs so that a subsequent fsck
will be forced.  I don't know if xfs does this or not.)

--Stephen

From owner-linux-xfs@oss.sgi.com Thu Apr  6 08:24:34 2000
Received:  by oss.sgi.com id <S305167AbQDFPYY>;
	Thu, 6 Apr 2000 08:24:24 -0700
Received: from dukat.scot.redhat.com ([195.89.149.246]:63244 "EHLO
        dukat.scot.redhat.com") by oss.sgi.com with ESMTP
	id <S305164AbQDFPYW>; Thu, 6 Apr 2000 08:24:22 -0700
Received: (from sct@localhost)
	by dukat.scot.redhat.com (8.9.3/8.9.3) id QAA14797;
	Thu, 6 Apr 2000 16:22:54 +0100
Date:   Thu, 6 Apr 2000 16:22:54 +0100
From:   "Stephen C. Tweedie" <sct@redhat.com>
To:     Jim Mostek <mostek@sgi.com>
Cc:     Lyle Seaman <lws@spinnakernet.com>, linux-xfs@oss.sgi.com,
        Stephen Tweedie <sct@redhat.com>
Subject: Re: XFS as Root filesystem
Message-ID: <20000406162254.C14727@redhat.com>
References: <38EB8FEF.9CB411C@spinnakernet.com> <200004051928.OAA19011@fsgi344.americas.sgi.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 1.0.1i
In-Reply-To: <200004051928.OAA19011@fsgi344.americas.sgi.com>; from mostek@sgi.com on Wed, Apr 05, 2000 at 02:28:19PM -0500
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing

Hi,

On Wed, Apr 05, 2000 at 02:28:19PM -0500, Jim Mostek wrote:
> 
> Linux mounts the root, read-only, when it is coming up.

It doesn't have to.  That's a boot-time option.  On systems
where I'm running ext3 as the root filesystem, I tend to mount
root read-write.

--Stephen

From owner-linux-xfs@oss.sgi.com Thu Apr  6 08:49:24 2000
Received:  by oss.sgi.com id <S305167AbQDFPtO>;
	Thu, 6 Apr 2000 08:49:14 -0700
Received: from client-141-151-129-90.bellatlantic.net ([141.151.129.90]:7438
        "EHLO router.spinnakernet.com") by oss.sgi.com with ESMTP
	id <S305164AbQDFPtG>; Thu, 6 Apr 2000 08:49:06 -0700
Received: from athabasca.spinnakernet.com (IDENT:root@athabasca.spinnakernet.com [10.1.1.129])
	by router.spinnakernet.com (8.9.3/8.8.7) with ESMTP id LAA13695
	for <linux-xfs@oss.sgi.com>; Thu, 6 Apr 2000 11:49:01 -0400
Received: from spinnakernet.com (IDENT:lws@localhost.localdomain [127.0.0.1])
	by athabasca.spinnakernet.com (8.9.3/8.8.7) with ESMTP id LAA03168
	for <linux-xfs@oss.sgi.com>; Thu, 6 Apr 2000 11:49:20 -0400
Message-ID: <38ECB200.9FCC2917@spinnakernet.com>
Date:   Thu, 06 Apr 2000 11:49:20 -0400
From:   Lyle Seaman <lws@spinnakernet.com>
Organization: Hah.
X-Mailer: Mozilla 4.61 [en] (X11; U; Linux 2.2.12-20 i686)
X-Accept-Language: en
MIME-Version: 1.0
To:     linux-xfs@oss.sgi.com
Subject: Re: XFS as Root filesystem
References: <200004051440.JAA25697@jen.americas.sgi.com> <38EB8FEF.9CB411C@spinnakernet.com> <20000406162144.B14727@redhat.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing

>
> > If that's the case, then why do you care?  Naively, I wouldn't
> > think this is a big deal.  Why am I wrong?
>
> Because (a) existing Linux installations expect to mount the
> root filesystem readonly until basic consistency checking has
> been done; and (b) after a cold reboot, the filesystem will
> need recovery before it can be mounted.

Ahhh.  Now I see.
The root fs  is *always* cycling back and forth
between read-write and read-only.    So after
nearly every crash, the root filesystem will be both
unstable (ie, potentially inconsistent) *and* RO.
Interesting.





From owner-linux-xfs@oss.sgi.com Thu Apr  6 08:55:35 2000
Received:  by oss.sgi.com id <S305164AbQDFPz0>;
	Thu, 6 Apr 2000 08:55:26 -0700
Received: from deliverator.sgi.com ([204.94.214.10]:59911 "EHLO
        deliverator.sgi.com") by oss.sgi.com with ESMTP id <S305167AbQDFPzO>;
	Thu, 6 Apr 2000 08:55:14 -0700
Received: from ledzep.cray.com (ledzep.cray.com [137.38.226.97]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id IAA00800
	for <linux-xfs@oss.sgi.com>; Thu, 6 Apr 2000 08:50:31 -0700 (PDT)
	mail_from (lord@sgi.com)
Received: from ironwood-e185.americas.sgi.com (ironwood.cray.com [128.162.185.212]) by ledzep.cray.com (SGI-SGI-8.9.3/craymail-smart-nospam1.0) with ESMTP id KAA56591; Thu, 6 Apr 2000 10:52:41 -0500 (CDT)
Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.184.86]) by ironwood-e185.americas.sgi.com (8.8.4/SGI-ironwood-e1.4) with ESMTP id KAA25490; Thu, 6 Apr 2000 10:52:33 -0500 (CDT)
Received: from jen.americas.sgi.com by jen.americas.sgi.com (8.9.3/SGI-client.1.6) via ESMTP id KAA20840; Thu, 6 Apr 2000 10:52:18 -0500
Message-Id: <200004061552.KAA20840@jen.americas.sgi.com>
X-Mailer: exmh version 2.1.1 10/15/1999
To:     "Stephen C. Tweedie" <sct@redhat.com>
cc:     Jim Mostek <mostek@sgi.com>, Klaus Strebel <stb@ep-ag.com>,
        linux-xfs@oss.sgi.com
Subject: Re: XFS as Root filesystem 
In-Reply-To: Message from "Stephen C. Tweedie" <sct@redhat.com> 
   of "Thu, 06 Apr 2000 16:18:35 BST." <20000406161835.A14727@redhat.com> 
Date:   Thu, 06 Apr 2000 10:52:18 -0500
From:   Steve Lord <lord@sgi.com>
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing

> Hi,
> 
> On Wed, Apr 05, 2000 at 07:48:21AM -0500, Jim Mostek wrote:
> > 
> > If you look at the code, the XFS_MOUNT_NORECOVERY flag is set
> > to skip recovery. But, we must already have a consistent file system when
> > this flag is used.  This is not what we should use for a read-only mount
> > of root. We need a separate flag. xlog_recovery would then do recovery
> > even on read-only mounts. Anyone have time to do this? I'll add this to
> > the mount as root work item.
> 
> Don't forget that readonly support also requires the ability to 
> remount the filesystem between ro and rw, and the ability to suspend
> atime updates while the filesystem is readonly.
> 
> --Stephen

XFS already has read only support - we just need to allow recovery in read only
mode, and the Linux remount code in XFS seems broken, so getting from
read only to read-write is broken I think.

Steve



From owner-linux-xfs@oss.sgi.com Thu Apr  6 09:08:55 2000
Received:  by oss.sgi.com id <S305167AbQDFQIp>;
	Thu, 6 Apr 2000 09:08:45 -0700
Received: from deliverator.sgi.com ([204.94.214.10]:45841 "EHLO
        deliverator.sgi.com") by oss.sgi.com with ESMTP id <S305164AbQDFQI2>;
	Thu, 6 Apr 2000 09:08:28 -0700
Received: from ledzep.cray.com (ledzep.cray.com [137.38.226.97]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id JAA05876
	for <linux-xfs@oss.sgi.com>; Thu, 6 Apr 2000 09:03:45 -0700 (PDT)
	mail_from (cattelan@thebarn.com)
Received: from ironwood-e185.americas.sgi.com (ironwood.cray.com [128.162.185.212]) by ledzep.cray.com (SGI-SGI-8.9.3/craymail-smart-nospam1.0) with ESMTP id LAA00910; Thu, 6 Apr 2000 11:05:55 -0500 (CDT)
Received: from gibble.americas.sgi.com (root@gibble.americas.sgi.com [128.162.195.80]) by ironwood-e185.americas.sgi.com (8.8.4/SGI-ironwood-e1.4) with ESMTP id LAA26322; Thu, 6 Apr 2000 11:05:47 -0500 (CDT)
Received: from thebarn.com by gibble.americas.sgi.com (8.9.3/SGI-client.1.6) via ESMTP id LAA00809; Thu, 6 Apr 2000 11:05:53 -0500
Message-ID: <38ECB5E1.E6CFEC35@thebarn.com>
Date:   Thu, 06 Apr 2000 11:05:53 -0500
From:   Russell Cattelan <cattelan@thebarn.com>
X-Mailer: Mozilla 4.72 [en] (X11; I; Linux 2.2.14-15mdksmp i686)
X-Accept-Language: en
MIME-Version: 1.0
To:     "Stephen C. Tweedie" <sct@redhat.com>
CC:     Lyle Seaman <lws@spinnakernet.com>, linux-xfs@oss.sgi.com
Subject: Re: XFS as Root filesystem
References: <200004051440.JAA25697@jen.americas.sgi.com> <38EB8FEF.9CB411C@spinnakernet.com> <20000406162144.B14727@redhat.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing

"Stephen C. Tweedie" wrote:

> Hi,
>
> On Wed, Apr 05, 2000 at 03:11:44PM -0400, Lyle Seaman wrote:
> >
> > How does a readonly filesystem become inconsistent?
> > (esp: "how does ext3 on readonly media" become inconsistent?)
> >
> > The obvious answer is "well, it *wasn't* readonly when it
> > became inconsistent".
> >
> > If that's the case, then why do you care?  Naively, I wouldn't
> > think this is a big deal.  Why am I wrong?
>
> Because (a) existing Linux installations expect to mount the
> root filesystem readonly until basic consistency checking has
> been done; and (b) after a cold reboot, the filesystem will
> need recovery before it can be mounted.
>
> In practice there is no problem mounting the root filesystem
> read-write if you have journaling, with one important exception:
> if you detect actual errors on the fs such that a constency
> check is required, mounting the fs read-write is dangerous.
> (Ext2/ext3 mark an error flag in the superblock if they detect
> dangerous inconsistencies in the fs so that a subsequent fsck
> will be forced.  I don't know if xfs does this or not.)
>

XFS doesn't actually try to detect file system inconstancies at mount
time.
(this would defeat quick recovery)
If it can successfully replay the the log and complete all outstanding
meta
 data requests it assumes the file system is clean, if not it simply
won't
mount.

If at any time a live XFS file system detects and error XFS will
immediately halt
all IO to the device. It is then up to the administrator to do manual
checks and
or repairs.

-Russell



From owner-linux-xfs@oss.sgi.com Thu Apr  6 09:24:35 2000
Received:  by oss.sgi.com id <S305167AbQDFQYZ>;
	Thu, 6 Apr 2000 09:24:25 -0700
Received: from dukat.scot.redhat.com ([195.89.149.246]:10509 "EHLO
        dukat.scot.redhat.com") by oss.sgi.com with ESMTP
	id <S305164AbQDFQYL>; Thu, 6 Apr 2000 09:24:11 -0700
Received: (from sct@localhost)
	by dukat.scot.redhat.com (8.9.3/8.9.3) id RAA14985;
	Thu, 6 Apr 2000 17:23:50 +0100
Date:   Thu, 6 Apr 2000 17:23:50 +0100
From:   "Stephen C. Tweedie" <sct@redhat.com>
To:     Russell Cattelan <cattelan@thebarn.com>
Cc:     "Stephen C. Tweedie" <sct@redhat.com>,
        Lyle Seaman <lws@spinnakernet.com>, linux-xfs@oss.sgi.com
Subject: Re: XFS as Root filesystem
Message-ID: <20000406172350.F13180@redhat.com>
References: <200004051440.JAA25697@jen.americas.sgi.com> <38EB8FEF.9CB411C@spinnakernet.com> <20000406162144.B14727@redhat.com> <38ECB5E1.E6CFEC35@thebarn.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 1.0.1i
In-Reply-To: <38ECB5E1.E6CFEC35@thebarn.com>; from cattelan@thebarn.com on Thu, Apr 06, 2000 at 11:05:53AM -0500
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing

Hi,

On Thu, Apr 06, 2000 at 11:05:53AM -0500, Russell Cattelan wrote:
> 
> XFS doesn't actually try to detect file system inconstancies at mount
> time.
> (this would defeat quick recovery)

Neither does ext3.  What the filesystem can do is to detect 
inconsistencies at run time (eg. clearing a bit in an allocation
bitmap but finding it already clear, or finding illegal block mappings
in a file --- that sort of thing), and record in the superblock that 
Bad Things have happened and a full consistency check is needed on 
reboot.  Only data corruption errors can lead to this.

> If at any time a live XFS file system detects and error XFS will
> immediately halt
> all IO to the device. It is then up to the administrator to do manual
> checks and
> or repairs.

Right, ext3 does too (in fact it gives you a per-fs option either to 
suspend IO on error, or to do an immediate panic).  In either case, 
though, it marks the presence of the error in the superblock so that
after a reboot, the system knows that forced fsck is required.

--Stephen

From owner-linux-xfs@oss.sgi.com Thu Apr  6 15:50:17 2000
Received:  by oss.sgi.com id <S305176AbQDFWuH>;
	Thu, 6 Apr 2000 15:50:07 -0700
Received: from rising.starnet.gov.sg ([203.116.82.211]:65268 "EHLO
        rising.starnet.gov.sg") by oss.sgi.com with ESMTP
	id <S305167AbQDFWtn>; Thu, 6 Apr 2000 15:49:43 -0700
Received: from starnet.gov.sg (dyn1-166cable.bp1.singa.pore.net [202.169.229.166])
	by rising.starnet.gov.sg (8.9.1/8.9.1) with ESMTP id GAA27075;
	Fri, 7 Apr 2000 06:49:15 +0800 (SGT)
Message-ID: <38ED1454.BD43635C@starnet.gov.sg>
Date:   Fri, 07 Apr 2000 06:48:52 +0800
From:   Tan Pong Heng <pongheng@starnet.gov.sg>
X-Mailer: Mozilla 4.7 [en] (X11; I; Linux 2.3.99-pre2 i686)
X-Accept-Language: en
MIME-Version: 1.0
To:     Russell Cattelan <cattelan@thebarn.com>
CC:     "Stephen C. Tweedie" <sct@redhat.com>,
        Lyle Seaman <lws@spinnakernet.com>, linux-xfs@oss.sgi.com
Subject: Re: XFS as Root filesystem
References: <200004051440.JAA25697@jen.americas.sgi.com> <38EB8FEF.9CB411C@spinnakernet.com> <20000406162144.B14727@redhat.com> <38ECB5E1.E6CFEC35@thebarn.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing

Russell Cattelan wrote:

> "Stephen C. Tweedie" wrote:
>
> > Hi,
> >
> > On Wed, Apr 05, 2000 at 03:11:44PM -0400, Lyle Seaman wrote:
> > >
> > > How does a readonly filesystem become inconsistent?
> > > (esp: "how does ext3 on readonly media" become inconsistent?)
> > >
> > > The obvious answer is "well, it *wasn't* readonly when it
> > > became inconsistent".
> > >
> > > If that's the case, then why do you care?  Naively, I wouldn't
> > > think this is a big deal.  Why am I wrong?
> >
> > Because (a) existing Linux installations expect to mount the
> > root filesystem readonly until basic consistency checking has
> > been done; and (b) after a cold reboot, the filesystem will
> > need recovery before it can be mounted.
> >
> > In practice there is no problem mounting the root filesystem
> > read-write if you have journaling, with one important exception:
> > if you detect actual errors on the fs such that a constency
> > check is required, mounting the fs read-write is dangerous.
> > (Ext2/ext3 mark an error flag in the superblock if they detect
> > dangerous inconsistencies in the fs so that a subsequent fsck
> > will be forced.  I don't know if xfs does this or not.)
> >
>
> XFS doesn't actually try to detect file system inconstancies at mount
> time.
> (this would defeat quick recovery)
> If it can successfully replay the the log and complete all outstanding
> meta
>  data requests it assumes the file system is clean, if not it simply
> won't
> mount.
>
> If at any time a live XFS file system detects and error XFS will
> immediately halt
> all IO to the device. It is then up to the administrator to do manual
> checks and
> or repairs.
>
> -Russell

Linux mount root fs read-only during boot so that it could do a fsck
during
the boot up process to make it consistance automatically (well, as far as

possible that is.) I believe mounting XFS read-write has the same effect.

But, it would be good to define under what condition/situation would a
XFS fs be in-consistance and under that condition, is it possible to fsck

it if it is mounted read-write or read-only.


From owner-linux-xfs@oss.sgi.com Thu Apr  6 17:46:31 2000
Received:  by oss.sgi.com id <S305177AbQDGAqV>;
	Thu, 6 Apr 2000 17:46:21 -0700
Received: from rising.starnet.gov.sg ([203.116.82.211]:1783 "EHLO
        rising.starnet.gov.sg") by oss.sgi.com with ESMTP
	id <S305167AbQDGAqR>; Thu, 6 Apr 2000 17:46:17 -0700
Received: from aries (generic-82-167.starnet.gov.sg [203.116.82.167])
	by rising.starnet.gov.sg (8.9.1/8.9.1) with SMTP id IAA29067
	for <linux-xfs@oss.sgi.com>; Fri, 7 Apr 2000 08:46:14 +0800 (SGT)
Message-ID: <000e01bfa02b$44621620$a75274cb@aries>
From:   "Tan Pong Heng" <pongheng@starnet.gov.sg>
To:     <linux-xfs@oss.sgi.com>
Subject: XFS as Root Filesystem
Date:   Fri, 7 Apr 2000 08:50:27 +0800
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_000B_01BFA06E.5240AC00"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.00.2919.6700
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing

This is a multi-part message in MIME format.

------=_NextPart_000_000B_01BFA06E.5240AC00
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

I updated to the latest CVS this morning and could now boot with XFS as =
the root
filesystem (mounted read-write - of course.) I will re-copy the root =
filesystem again
when I have the time and do a full kernel re-compile on it later. I will =
send in the
dmsg, messages and etc when that is done. Also, please consider =
implementing
the remount function sometime - it seems that both the boot up and =
shutdown
process do it a lot. (Well, not that it matter much for a journal =
filesystem...)


------=_NextPart_000_000B_01BFA06E.5240AC00
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META content=3D"text/html; charset=3Diso-8859-1" =
http-equiv=3DContent-Type>
<META content=3D"MSHTML 5.00.2920.0" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT face=3DArial size=3D2>I updated to the latest CVS this =
morning and could=20
now boot with XFS as the root</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>filesystem (mounted read-write - of =
course.) I will=20
re-copy the root filesystem again</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>when I have the time and do a full =
kernel=20
re-compile on it later. I will send in the</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>dmsg, messages and etc when that is =
done. Also,=20
please consider implementing</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>the remount function sometime - it =
seems that both=20
the boot up and shutdown</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>process do it a lot. (Well, not that it =
matter much=20
for a journal filesystem...)</FONT></DIV>
<DIV>&nbsp;</DIV></BODY></HTML>

------=_NextPart_000_000B_01BFA06E.5240AC00--


From owner-linux-xfs@oss.sgi.com Fri Apr  7 04:28:54 2000
Received:  by oss.sgi.com id <S305155AbQDGL2p>;
	Fri, 7 Apr 2000 04:28:45 -0700
Received: from rising.starnet.gov.sg ([203.116.82.211]:46214 "EHLO
        rising.starnet.gov.sg") by oss.sgi.com with ESMTP
	id <S305154AbQDGL21>; Fri, 7 Apr 2000 04:28:27 -0700
Received: from starnet.gov.sg (dyn1-166cable.bp1.singa.pore.net [202.169.229.166])
	by rising.starnet.gov.sg (8.9.1/8.9.1) with ESMTP id TAA16525
	for <linux-xfs@oss.sgi.com>; Fri, 7 Apr 2000 19:28:22 +0800 (SGT)
Message-ID: <38EDC640.8070102@starnet.gov.sg>
Date:   Fri, 07 Apr 2000 19:28:00 +0800
From:   Tan Pong Heng <pongheng@starnet.gov.sg>
User-Agent: Mozilla/5.0 (X11; N; Linux 2.3.99-pre2 i686; en-US; m14) Netscape6/6.0b1
X-Accept-Language: en
MIME-Version: 1.0
To:     linux-xfs@oss.sgi.com
Subject: XFS as Root Filesystem
Content-Type: multipart/mixed;
 boundary="------------030606030808050702060904"
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing

This is a multi-part message in MIME format.
--------------030606030808050702060904
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

Hi, I have completed another round of testing with XFS as my root 
filesystem.
Attached is the dmesg output of my current system. I have also successfully
recompiled the kernel with make mrproper; cp .config; make oldconfig; 
make dep;
make bzImage modules.
It seems that XFS is very usable on linux now. I did notice a slight 
performance
degragation on this setup though....

--------------030606030808050702060904
Content-Type: text/plain;
 name="dmesg"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline;
 filename="dmesg"

Processors: 2
mapped APIC to ffffe000 (fee00000)
mapped IOAPIC to ffffd000 (fec00000)
Initializing CPU#0
Detected 456511335 Hz processor.
ide_setup: hdd=ide-scsi
Console: colour VGA+ 80x25
Calibrating delay loop... 910.95 BogoMIPS
Memory: 125496k/131008k available (1751k kernel code, 5124k reserved, 121k data, 168k init, 0k highmem)
Buffer-cache hash table entries: 4096 (order: 2, 16384 bytes)
Page-cache hash table entries: 32768 (order: 5, 131072 bytes)
VFS: Diskquotas version dquot_6.4.0 initialized
Checking 386/387 coupling... OK, FPU using exception 16 error reporting.
Checking 'hlt' instruction... OK.
POSIX conformance testing by UNIFIX
mtrr: v1.36 (20000221) Richard Gooch (rgooch@atnf.csiro.au)
CPU0: Intel Celeron (Mendocino) stepping 05
per-CPU timeslice cutoff: 357.24 usecs.
Getting VERSION: 40011
Getting VERSION: 40011
Getting LVT0: 700
Getting LVT1: 400
enabled ExtINT on CPU#0
ESR value before enabling vector: 00000000
ESR value after enabling vector: 00000000
CPU present map: 3
Booting processor 1 eip 2000
Setting warm reset code and vector.
1.
2.
3.
Asserting INIT.
Deasserting INIT.
#startup loops: 2.
Sending STARTUP #1.
After apic_write.
Startup point 1.
Waiting for send to finish...
+Sending STARTUP #2.
After apic_write.
Startup point 1.
Waiting for send to finish...
+After Startup.
Before Callout 1.
After Callout 1.
Initializing CPU#1
CPU#1 (phys ID: 1) waiting for CALLOUT
CALLIN, before setup_local_APIC().
masked ExtINT on CPU#1
ESR value before enabling vector: 00000000
ESR value after enabling vector: 00000000
Calibrating delay loop... 910.95 BogoMIPS
Stack at about c7febfbc
OK.
CPU1: Intel Celeron (Mendocino) stepping 05
CPU has booted.
Before bogomips.
Total of 2 processors activated (1821.90 BogoMIPS).
Before bogocount - setting activated=1.
Boot done.
ENABLING IO-APIC IRQs
...changing IO-APIC physical APIC ID to 2 ... ok.
init IO_APIC IRQs
 IO-APIC (apicid-pin) 2-0, 2-5, 2-9, 2-10, 2-11, 2-20, 2-21, 2-22, 2-23 not connected.
..TIMER: vector=81 pin1=2 pin2=0
activating NMI Watchdog ... done.
number of MP IRQ sources: 16.
number of IO-APIC #2 registers: 24.
testing the IO APIC.......................

IO APIC #2......
.... register #00: 02000000
.......    : physical APIC id: 02
.... register #01: 00170011
.......     : max redirection entries: 0017
.......     : IO APIC version: 0011
.... register #02: 00000000
.......     : arbitration: 00
.... IRQ redirection table:
 NR Log Phy Mask Trig IRR Pol Stat Dest Deli Vect:   
 00 000 00  1    0    0   0   0    0    0    00
 01 0FF 0F  0    0    0   0   0    1    1    59
 02 0FF 0F  0    0    0   0   0    1    1    51
 03 0FF 0F  0    0    0   0   0    1    1    61
 04 0FF 0F  0    0    0   0   0    1    1    69
 05 000 00  1    0    0   0   0    0    0    00
 06 0FF 0F  0    0    0   0   0    1    1    71
 07 0FF 0F  0    0    0   0   0    1    1    79
 08 0FF 0F  0    0    0   0   0    1    1    81
 09 000 00  1    0    0   0   0    0    0    00
 0a 000 00  1    0    0   0   0    0    0    00
 0b 000 00  1    0    0   0   0    0    0    00
 0c 0FF 0F  0    0    0   0   0    1    1    89
 0d 000 00  1    0    0   0   0    0    0    00
 0e 0FF 0F  0    0    0   0   0    1    1    91
 0f 0FF 0F  0    0    0   0   0    1    1    99
 10 0FF 0F  1    1    0   1   0    1    1    A1
 11 0FF 0F  1    1    0   1   0    1    1    A9
 12 0FF 0F  1    1    0   1   0    1    1    B1
 13 0FF 0F  1    1    0   1   0    1    1    B9
 14 000 00  1    0    0   0   0    0    0    00
 15 000 00  1    0    0   0   0    0    0    00
 16 000 00  1    0    0   0   0    0    0    00
 17 000 00  1    0    0   0   0    0    0    00
IRQ to pin mappings:
IRQ0 -> 2
IRQ1 -> 1
IRQ3 -> 3
IRQ4 -> 4
IRQ5 -> 17
IRQ6 -> 6
IRQ7 -> 7
IRQ8 -> 8
IRQ9 -> 16
IRQ10 -> 19
IRQ11 -> 18
IRQ12 -> 12
IRQ13 -> 13
IRQ14 -> 14
IRQ15 -> 15
.................................... done.
calibrating APIC timer ... 
..... CPU clock speed is 456.5621 MHz.
..... host bus clock speed is 83.0112 MHz.
cpu: 0, clocks: 830112, slice: 276704
CPU0<C0:830112,C:553408,D:0,S:276704,C:830112>
cpu: 1, clocks: 830112, slice: 276704
CPU1<C0:830112,C:276704,D:0,S:276704,C:830112>
checking TSC synchronization across CPUs: passed.
Setting commenced=1, go go go
mtrr: your CPUs had inconsistent fixed MTRR settings
mtrr: probably your BIOS does not setup all CPUs
PCI: PCI BIOS revision 2.10 entry at 0xfb6d0
PCI: Using configuration type 1
PCI: Probing PCI hardware
PCI: Interrupt Routing Table found at 0xc00fd8f0 [router type 8086/7000]
Limiting direct PCI/PCI transfers.
isapnp: Scanning for Pnp cards...
isapnp: No Plug & Play device found
Linux NET4.0 for Linux 2.3
Based upon Swansea University Computer Society NET3.039
NET4: Unix domain sockets 1.0/SMP for Linux NET4.0.
NET4: Linux TCP/IP 1.0 for NET4.0
IP Protocols: ICMP, UDP, TCP, IGMP
IP: routing cache hash table of 256 buckets, 4Kbytes
TCP: Hash tables configured (established 4096 bind 5461)
Initializing RT netlink socket
Starting kswapd v1.6
Serial driver version 4.92 (2000-1-27) with MANY_PORTS SHARE_IRQ SERIAL_PCI ISAPNP enabled
ttyS00 at 0x03f8 (irq = 4) is a 16550A
ttyS01 at 0x02f8 (irq = 3) is a 16550A
pty: 256 Unix98 ptys configured
Uniform Multi-Platform E-IDE driver Revision: 6.30
ide: Assuming 40MHz system bus speed for PIO modes; override with idebus=xx
PIIX4: IDE controller on PCI bus 00 dev 39
PIIX4: not 100% native mode: will probe irqs later
    ide0: BM-DMA at 0xf000-0xf007, BIOS settings: hda:pio, hdb:pio
    ide1: BM-DMA at 0xf008-0xf00f, BIOS settings: hdc:DMA, hdd:pio
HPT366: onboard version of chipset, pin1=1 pin2=2
HPT366: IDE controller on PCI bus 00 dev 98
HPT366: not 100% native mode: will probe irqs later
    ide2: BM-DMA at 0xd800-0xd807, BIOS settings: hde:DMA, hdf:pio
HPT366: IDE controller on PCI bus 00 dev 99
HPT366: not 100% native mode: will probe irqs later
    ide3: BM-DMA at 0xe400-0xe407, BIOS settings: hdg:DMA, hdh:pio
hdc: Pioneer DVD-ROM ATAPIModel DVD-103S 011, ATAPI CDROM drive
hdd: CREATIVE CD-RW RW4224E, ATAPI CDROM drive
hde: QUANTUM FIREBALL CR13.0A, ATA DISK drive
hdg: Maxtor 52049U4, ATA DISK drive
ide1 at 0x170-0x177,0x376 on irq 15
ide2 at 0xd000-0xd007,0xd402 on irq 11
ide3 at 0xdc00-0xdc07,0xe002 on irq 11
hde: QUANTUM FIREBALL CR13.0A, 12416MB w/418kB Cache, CHS=25228/16/63, UDMA(66)
hdg: Maxtor 52049U4, 19541MB w/2048kB Cache, CHS=39703/16/63, UDMA(66)
hdc: ATAPI DVD-ROM drive, 512kB Cache, UDMA(33)
Uniform CD-ROM driver Revision: 3.07
Partition check:
 hde: [PTBL] [1582/255/63] hde1 hde2 hde3 < hde5 hde6 hde7 hde8 > hde4
 hdg: [PTBL] [2491/255/63] hdg1 hdg2 < hdg5 hdg6 hdg7 hdg8 >
Floppy drive(s): fd0 is 1.44M
FDC 0 is a post-1991 82077
Real Time Clock Driver v1.10b
3c59x.c:v0.99H+lk1.0 Feb 9, 2000 The Linux Kernel Team http://cesdis.gsfc.nasa.gov/linux/drivers/vortex.html
eth0: 3Com 3c900 Boomerang 10baseT at 0xcc00,  00:60:08:a9:e0:82, IRQ 10
  8K word-wide RAM 3:5 Rx:Tx split, autoselect/10baseT interface.
  Enabling bus-master transmits and whole-frame receives.
Entering init_xfs_fs
Exiting  init_xfs_fs
Invalid session number or type of track
Invalid session number
XFS Mode = NATIVE, arch=1
Start mounting filesystem: ide3(34,7)
Ending clean XFS mount for filesystem: ide3(34,7)
VFS: Mounted root (xfs filesystem).
Freeing unused kernel memory: 168k freed
Adding Swap: 112416k swap-space (priority -1)
Adding Swap: 136512k swap-space (priority -2)
XFS:  Hoser!!!  Somebody called remountfs()
Creative EMU10K1 PCI Audio Driver, version 0.5 , 07:05:00 Apr  7 2000
emu10k1: emu10k1 rev 7 found at IO 0xc400, IRQ 5
hdd: driver not present
hdd: driver not present

--------------030606030808050702060904--


From owner-linux-xfs@oss.sgi.com Fri Apr  7 06:32:45 2000
Received:  by oss.sgi.com id <S305157AbQDGNcZ>;
	Fri, 7 Apr 2000 06:32:25 -0700
Received: from pneumatic-tube.sgi.com ([204.94.214.22]:21581 "EHLO
        pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP
	id <S305154AbQDGNcE>; Fri, 7 Apr 2000 06:32:04 -0700
Received: from ledzep.cray.com (ledzep.cray.com [137.38.226.97]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id GAA04407
	for <linux-xfs@oss.sgi.com>; Fri, 7 Apr 2000 06:35:52 -0700 (PDT)
	mail_from (mostek@sgi.com)
Received: from ironwood-e185.americas.sgi.com (ironwood.cray.com [128.162.185.212]) by ledzep.cray.com (SGI-SGI-8.9.3/craymail-smart-nospam1.0) with ESMTP id IAA69529 for <linux-xfs@oss.sgi.com>; Fri, 7 Apr 2000 08:30:47 -0500 (CDT)
Received: from fsgi344.americas.sgi.com (fsgi344.americas.sgi.com [128.162.184.15]) by ironwood-e185.americas.sgi.com (8.8.4/SGI-ironwood-e1.4) with ESMTP id IAA08005 for <linux-xfs@oss.sgi.com>; Fri, 7 Apr 2000 08:30:40 -0500 (CDT)
Received: by fsgi344.americas.sgi.com (980427.SGI.8.8.8/SGI-client.1.6) id IAA40461; Fri, 7 Apr 2000 08:30:46 -0500 (CDT)
Received: from ledzep.cray.com (ledzep.americas.sgi.com [137.38.226.97]) by tulip-e185.americas.sgi.com (8.8.8/SGI-server-1.4) with ESMTP id XAA3492376; Thu, 6 Apr 2000 23:07:40 -0500 (CDT)
Received: from nodin.corp.sgi.com (nodin.corp.sgi.com [192.26.51.193]) by ledzep.cray.com (SGI-SGI-8.9.3/craymail-smart-nospam1.0) with ESMTP id XAA31294; Thu, 6 Apr 2000 23:07:40 -0500 (CDT)
Received: from cthulhu.engr.sgi.com (cthulhu.engr.sgi.com [192.26.80.2]) by nodin.corp.sgi.com (980427.SGI.8.8.8/980728.SGI.AUTOCF) via ESMTP id VAA52660; Thu, 6 Apr 2000 21:07:39 -0700 (PDT)
Received: (from majordomo-owner@localhost)
	by cthulhu.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF)
	id VAA87511
	for slinx-xfs-list;
	Thu, 6 Apr 2000 21:07:35 -0700 (PDT)
	mail_from (owner-slinx-xfs@relay.engr.sgi.com)
Received: from sgi.com (sgi.engr.sgi.com [192.26.80.37])
	by cthulhu.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF)
	via ESMTP id VAA90859
	for <slinx-xfs@cthulhu.engr.sgi.com>;
	Thu, 6 Apr 2000 21:07:34 -0700 (PDT)
	mail_from (phil@linuxcare.com)
Received: from moiraine.off.net (ip143.ottawa7.dialup.canada.psi.net [154.5.69.143]) 
	by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam:
       SGI does not authorize the use of its proprietary
       systems or networks for unsolicited or bulk email
       from the Internet.) 
	via ESMTP id VAA01237
	for <slinx-xfs@cthulhu.engr.sgi.com>; Thu, 6 Apr 2000 21:07:32 -0700 (PDT)
	mail_from (phil@linuxcare.com)
Received: (from phil@localhost)
	by moiraine.off.net (8.9.3/8.9.3) id XAA12692
	for slinx-xfs@cthulhu.engr.sgi.com; Thu, 6 Apr 2000 23:39:19 -0400
Date:   Thu, 6 Apr 2000 23:39:19 -0400
From:   Phil Schwan <phil@linuxcare.com>
To:     slinx-xfs@cthulhu.engr.sgi.com
Subject: 64 bit status report
Message-ID: <20000406233919.I11090@linuxcare.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 0.95.4us
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing

Since we're on the topic of status reports, I'll try to tell you where
I'm at with the big filesystem stuff.

In terms of big files, there are no problems, as long as you're
running a suitably new glibc.  I've created sparse files larger than 4
TB (if the very nice Purolator man brings me a magical giant disk
array, I'll test non-sparse files too) without any apparent ill
effects.

[root@caesar xfs]# ls -l /mnt/xfs/test
-rwxr-xr--    1 root     root     5344754401280 Apr  6 19:15 /mnt/xfs/test
[root@caesar xfs]# 

Now, as far as 64 bit inode numbers go, the story is somewhat
different (as expected).  Unfortunately, glibc unconditionally defines
__ino64_t to be unsigned long, despite any LARGEFILE64_SOURCE or
whatever.

As an alternative to dealing with the political mess that wedging 
a 64 bit ino_t into glibc and the kernel, Steve pondered some ideas
about doing all of the 64 bit work internal to XFS.  Unfortunately,
one of the big things that I think it would break is NFS, which
(currently) relies on an inode being a unique file identifier.

As someone who would rather see 64 bit ino_ts, even if it takes a long
time and a bunch of fighting, I've sent off some emails to the glibc
folks, just to see if they've even been considering this.  Hopefully
I'll hear back from them shortly, and see where to go from there.

Thoughts?

-Phil


From owner-linux-xfs@oss.sgi.com Fri Apr  7 07:22:45 2000
Received:  by oss.sgi.com id <S305154AbQDGOWg>;
	Fri, 7 Apr 2000 07:22:36 -0700
Received: from pneumatic-tube.sgi.com ([204.94.214.22]:14929 "EHLO
        pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP
	id <S305158AbQDGOWM>; Fri, 7 Apr 2000 07:22:12 -0700
Received: from ledzep.cray.com (ledzep.cray.com [137.38.226.97]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id HAA00594
	for <linux-xfs@oss.sgi.com>; Fri, 7 Apr 2000 07:26:00 -0700 (PDT)
	mail_from (mostek@sgi.com)
Received: from ironwood-e185.americas.sgi.com (ironwood.cray.com [128.162.185.212]) by ledzep.cray.com (SGI-SGI-8.9.3/craymail-smart-nospam1.0) with ESMTP id JAA71161; Fri, 7 Apr 2000 09:20:54 -0500 (CDT)
Received: from fsgi344.americas.sgi.com (fsgi344.americas.sgi.com [128.162.184.15]) by ironwood-e185.americas.sgi.com (8.8.4/SGI-ironwood-e1.4) with ESMTP id JAA10091; Fri, 7 Apr 2000 09:20:47 -0500 (CDT)
From:   Jim Mostek <mostek@sgi.com>
Received: by fsgi344.americas.sgi.com (980427.SGI.8.8.8/SGI-client.1.6) id JAA43049; Fri, 7 Apr 2000 09:20:53 -0500 (CDT)
Message-Id: <200004071420.JAA43049@fsgi344.americas.sgi.com>
Subject: Re: 64 bit status report
To:     phil@linuxcare.com (Phil Schwan)
Date:   Fri, 7 Apr 2000 09:20:52 -0500 (CDT)
Cc:     linux-xfs@oss.sgi.com
In-Reply-To: <20000406233919.I11090@linuxcare.com> from "Phil Schwan" at Apr 06, 2000 11:39:19 PM
X-Mailer: ELM [version 2.5 PL2]
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing


My initial thought is lets get all ino_t's in linux to move to 64 bit.
This will take time, but we should do it since file systems will get this
big.

For XFS, this isn't a problem 'till we hit file systems around 4Tbs or so.
But, it does become a problem.

In the shorter term, (while Linux is moving to 64 bit ino_ts), we could
use some index'ing scheme with a hash tabel lookup or ... to map from
internal 64 bit ino_t's to 32 bit values. This would limit XFS to
2^32 inodes. But we could live with this more easily than being limited
to 4tb file systems. Do you want a crack at fixing this?

The inode is a mask of 3 values, ag #, block #, index in cluster.
It is a sparse value in that it is nearly impossible for all block #'s to
exist.  Assuming that one is writing data to files.  If we keep track of
the block #'s that are inodes, we could change this to ag #, block index
#, index in cluster. This could let us shrink the middle field "block index #"
substantially. This would limit the number of inodes per AG. We then need
a way to keep track of which block each AG index actually refers to. But,
this would be much less storage than a hash table or index for all inode
numbers.

Thinking out loud,

Jim

>
>Since we're on the topic of status reports, I'll try to tell you where
>I'm at with the big filesystem stuff.
>
>In terms of big files, there are no problems, as long as you're
>running a suitably new glibc.  I've created sparse files larger than 4
>TB (if the very nice Purolator man brings me a magical giant disk
>array, I'll test non-sparse files too) without any apparent ill
>effects.
>
>[root@caesar xfs]# ls -l /mnt/xfs/test
>-rwxr-xr--    1 root     root     5344754401280 Apr  6 19:15 /mnt/xfs/test
>[root@caesar xfs]# 
>
>Now, as far as 64 bit inode numbers go, the story is somewhat
>different (as expected).  Unfortunately, glibc unconditionally defines
>__ino64_t to be unsigned long, despite any LARGEFILE64_SOURCE or
>whatever.
>
>As an alternative to dealing with the political mess that wedging 
>a 64 bit ino_t into glibc and the kernel, Steve pondered some ideas
>about doing all of the 64 bit work internal to XFS.  Unfortunately,
>one of the big things that I think it would break is NFS, which
>(currently) relies on an inode being a unique file identifier.
>
>As someone who would rather see 64 bit ino_ts, even if it takes a long
>time and a bunch of fighting, I've sent off some emails to the glibc
>folks, just to see if they've even been considering this.  Hopefully
>I'll hear back from them shortly, and see where to go from there.
>
>Thoughts?
>
>-Phil
>


From owner-linux-xfs@oss.sgi.com Fri Apr  7 07:42:15 2000
Received:  by oss.sgi.com id <S305160AbQDGOmF>;
	Fri, 7 Apr 2000 07:42:05 -0700
Received: from smtp2.libero.it ([193.70.192.52]:51350 "EHLO smtp2.libero.it")
	by oss.sgi.com with ESMTP id <S305158AbQDGOly>;
	Fri, 7 Apr 2000 07:41:54 -0700
Received: from contact01 (151.20.10.222) by smtp2.libero.it; 7 Apr 2000 16:41:51 +0200
Message-ID: <000d01bfa09f$f715d2b0$0201a8c0@contactum.com>
From:   "calze" <info@it-socks.com>
To:     <Undisclosed-Recipient:;>
Subject: Italian socks
Date:   Fri, 7 Apr 2000 16:44:58 +0200
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_0008_01BFA0B0.9C494900"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.00.2314.1300
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing

This is a multi-part message in MIME format.

------=_NextPart_000_0008_01BFA0B0.9C494900
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

We would like to know if you are interested in distributing our items in =
your Country, or if you want to contact us for a prospective cooperation =
in the field of PRIVATE LABELS.
NEMAR IS AN ITALIAN FIRM SITUATED IN CALCINATELLO DI CALCINATO NEAR =
BRESCIA IN THE NORTH OF ITALY THAT PRODUCES GOOD QUALITY BABY, CHILD, =
MAN AND WOMAN SOCKS. IT ALSO PRODUCES SOCKS WITH CHARACTERS (CARTOON, =
ETC.) FOR PRIVATE LABELS. ACCORDING TO A SAMPLE YOU GIVE US, WE CAN MAKE =
EXACTLY THE SAME FOR YOU.
 You can visit our web site at the address:=20
http://www.nemarsocks.com
There you will find all you need to know about our firm and our =
products.=20
We would also like to underline that our products are oko-tex certified =
and that we already work for big Companies and department stores in =
Europe.=20
Please do not hesitate to reply us and to give us details about the =
articles you are interested in. Please specify in your request:
1. Material (wool, cotton, acrylic, etc.)
2. Model and sizes (for baby, child, man woman)
3. Thinness/needles
Please reply urgently
Looking forward to receiving your reply.=20
Yours sincerely.=20

------=_NextPart_000_0008_01BFA0B0.9C494900
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META content=3D"text/html; charset=3Diso-8859-1" =
http-equiv=3DContent-Type>
<META content=3D"MSHTML 5.00.2314.1000" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#c0c0c0>
<DIV><FONT size=3D2>
<DIV><FONT size=3D2>We would like to know if you are interested in =
distributing=20
our items in your Country, or if you want to contact us for a =
prospective=20
cooperation in the field of PRIVATE LABELS.<BR>NEMAR IS AN ITALIAN FIRM =
SITUATED=20
IN CALCINATELLO DI CALCINATO NEAR BRESCIA IN THE NORTH OF ITALY THAT =
PRODUCES=20
GOOD QUALITY BABY, CHILD, MAN AND WOMAN SOCKS. IT ALSO PRODUCES SOCKS =
WITH=20
CHARACTERS (CARTOON, ETC.) FOR PRIVATE LABELS. ACCORDING TO A SAMPLE YOU =
GIVE=20
US, WE CAN MAKE EXACTLY THE SAME FOR YOU.<BR>&nbsp;You can visit our web =
site at=20
the address: <BR><A=20
href=3D"http://www.nemarsocks.com">http://www.nemarsocks.com</A><BR>There=
 you will=20
find all you need to know about our firm and our products. <BR>We would =
also=20
like to underline that our products are oko-tex certified and that we =
already=20
work for big Companies and department stores in Europe. <BR>Please do =
not=20
hesitate to reply us and to give us details about the articles you are=20
interested in. Please specify in your request:<BR>1. Material (wool, =
cotton,=20
acrylic, etc.)<BR>2. Model and sizes (for baby, child, man woman)<BR>3.=20
Thinness/needles<BR>Please reply urgently<BR>Looking forward to =
receiving your=20
reply. <BR>Yours sincerely. </FONT></DIV></FONT></DIV></BODY></HTML>

------=_NextPart_000_0008_01BFA0B0.9C494900--


From owner-linux-xfs@oss.sgi.com Fri Apr  7 08:39:05 2000
Received:  by oss.sgi.com id <S305156AbQDGPi4>;
	Fri, 7 Apr 2000 08:38:56 -0700
Received: from deliverator.sgi.com ([204.94.214.10]:32122 "EHLO
        deliverator.sgi.com") by oss.sgi.com with ESMTP id <S305159AbQDGPib>;
	Fri, 7 Apr 2000 08:38:31 -0700
Received: from ledzep.cray.com (ledzep.cray.com [137.38.226.97]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id IAA14861
	for <linux-xfs@oss.sgi.com>; Fri, 7 Apr 2000 08:33:49 -0700 (PDT)
	mail_from (lord@sgi.com)
Received: from ironwood-e185.americas.sgi.com (ironwood.cray.com [128.162.185.212]) by ledzep.cray.com (SGI-SGI-8.9.3/craymail-smart-nospam1.0) with ESMTP id KAA18612; Fri, 7 Apr 2000 10:35:57 -0500 (CDT)
Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.184.86]) by ironwood-e185.americas.sgi.com (8.8.4/SGI-ironwood-e1.4) with ESMTP id KAA13998; Fri, 7 Apr 2000 10:35:50 -0500 (CDT)
From:   Steve Lord <lord@sgi.com>
Received: from jen.americas.sgi.com by jen.americas.sgi.com (8.9.3/SGI-client.1.6) via ESMTP id KAA30160; Fri, 7 Apr 2000 10:35:26 -0500
Message-Id: <200004071535.KAA30160@jen.americas.sgi.com>
To:     Jim Mostek <mostek@sgi.com>
cc:     phil@linuxcare.com (Phil Schwan), linux-xfs@oss.sgi.com
Subject: Re: 64 bit status report 
In-reply-to: Your message of "Fri, 07 Apr 2000 09:20:52 CDT
Date:   Fri, 07 Apr 2000 10:35:26 -0500
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing

> 
> My initial thought is lets get all ino_t's in linux to move to 64 bit.
> This will take time, but we should do it since file systems will get this
> big.
> 
> For XFS, this isn't a problem 'till we hit file systems around 4Tbs or so.
> But, it does become a problem.
> 


It is 2Tbytes where this will fall over, and it is not the only
thing, block numbers are passed around in 4 bytes signed values.
At 512 byte block size this also falls over at 2 Tbytes.

Steve


From owner-linux-xfs@oss.sgi.com Fri Apr  7 09:27:35 2000
Received:  by oss.sgi.com id <S305161AbQDGQ1Q>;
	Fri, 7 Apr 2000 09:27:16 -0700
Received: from deliverator.sgi.com ([204.94.214.10]:25102 "EHLO
        deliverator.sgi.com") by oss.sgi.com with ESMTP id <S305159AbQDGQ0w>;
	Fri, 7 Apr 2000 09:26:52 -0700
Received: from ledzep.cray.com (ledzep.cray.com [137.38.226.97]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id JAA22286
	for <linux-xfs@oss.sgi.com>; Fri, 7 Apr 2000 09:22:09 -0700 (PDT)
	mail_from (cattelan@thebarn.com)
Received: from ironwood-e185.americas.sgi.com (ironwood.cray.com [128.162.185.212]) by ledzep.cray.com (SGI-SGI-8.9.3/craymail-smart-nospam1.0) with ESMTP id LAA43010; Fri, 7 Apr 2000 11:24:18 -0500 (CDT)
Received: from gibble.americas.sgi.com (root@gibble.americas.sgi.com [128.162.195.80]) by ironwood-e185.americas.sgi.com (8.8.4/SGI-ironwood-e1.4) with ESMTP id LAA16641; Fri, 7 Apr 2000 11:24:11 -0500 (CDT)
Received: from thebarn.com by gibble.americas.sgi.com (8.9.3/SGI-client.1.6) via ESMTP id LAA15007; Fri, 7 Apr 2000 11:24:18 -0500
Message-ID: <38EE0BB1.6A83CD06@thebarn.com>
Date:   Fri, 07 Apr 2000 11:24:17 -0500
From:   Russell Cattelan <cattelan@thebarn.com>
X-Mailer: Mozilla 4.72 [en] (X11; I; Linux 2.2.14-15mdksmp i686)
X-Accept-Language: en
MIME-Version: 1.0
To:     Phil Schwan <phil@linuxcare.com>
CC:     linux-xfs@oss.sgi.com
Subject: Re: 64 bit status report
References: <20000406233919.I11090@linuxcare.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing

Phil Schwan wrote:

> Since we're on the topic of status reports, I'll try to tell you where
> I'm at with the big filesystem stuff.
>
> In terms of big files, there are no problems, as long as you're
> running a suitably new glibc.  I've created sparse files larger than 4
> TB (if the very nice Purolator man brings me a magical giant disk
> array, I'll test non-sparse files too) without any apparent ill
> effects.
>
> [root@caesar xfs]# ls -l /mnt/xfs/test
> -rwxr-xr--    1 root     root     5344754401280 Apr  6 19:15 /mnt/xfs/test
> [root@caesar xfs]#
>
> Now, as far as 64 bit inode numbers go, the story is somewhat
> different (as expected).  Unfortunately, glibc unconditionally defines
> __ino64_t to be unsigned long, despite any LARGEFILE64_SOURCE or
> whatever.
>
> As an alternative to dealing with the political mess that wedging
> a 64 bit ino_t into glibc and the kernel, Steve pondered some ideas
> about doing all of the 64 bit work internal to XFS.  Unfortunately,
> one of the big things that I think it would break is NFS, which
> (currently) relies on an inode being a unique file identifier.
>
> As someone who would rather see 64 bit ino_ts, even if it takes a long
> time and a bunch of fighting, I've sent off some emails to the glibc
> folks, just to see if they've even been considering this.  Hopefully
> I'll hear back from them shortly, and see where to go from there.
>
> Thoughts?
>

I think we may have to attack on several fronts.
Simplistic case:
since most people are not going to put XFS
up a  2TB (well not to next year when Seagate introduces their 1TB drives :-)

make XFS work in the current environment to the best we can.
i.e. no crashes, correct error messages when things  do fail to fit in a
container.
Probably add a check in mkfs to warn people about upgrading glibc if
the size of the file system they are trying to make is over 2TB.


Long term we should start the process of modifying glibc and all the
shell/file/bin utils
that may be affected by type changes., and NFS?... ugghh that doesn't sound
like fun.
This was not an easy process on IRIX  I suspect it will be a lot work for
linux also;
mostly in terms of providing compatibility and transition interfaces.

-Russell






From owner-linux-xfs@oss.sgi.com Fri Apr  7 11:53:17 2000
Received:  by oss.sgi.com id <S305162AbQDGSw5>;
	Fri, 7 Apr 2000 11:52:57 -0700
Received: from deliverator.sgi.com ([204.94.214.10]:29759 "EHLO
        deliverator.sgi.com") by oss.sgi.com with ESMTP id <S305159AbQDGSw1>;
	Fri, 7 Apr 2000 11:52:27 -0700
Received: from ledzep.cray.com (ledzep.cray.com [137.38.226.97]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id LAA13039
	for <linux-xfs@oss.sgi.com>; Fri, 7 Apr 2000 11:47:45 -0700 (PDT)
	mail_from (mostek@sgi.com)
Received: from ironwood-e185.americas.sgi.com (ironwood.cray.com [128.162.185.212]) by ledzep.cray.com (SGI-SGI-8.9.3/craymail-smart-nospam1.0) with ESMTP id NAA40131 for <linux-xfs@oss.sgi.com>; Fri, 7 Apr 2000 13:51:11 -0500 (CDT)
Received: from fsgi344.americas.sgi.com (fsgi344.americas.sgi.com [128.162.184.15]) by ironwood-e185.americas.sgi.com (8.8.4/SGI-ironwood-e1.4) with ESMTP id NAA02621; Fri, 7 Apr 2000 13:51:04 -0500 (CDT)
From:   Jim Mostek <mostek@sgi.com>
Received: by fsgi344.americas.sgi.com (980427.SGI.8.8.8/SGI-client.1.6) id NAA43783; Fri, 7 Apr 2000 13:51:09 -0500 (CDT)
Message-Id: <200004071851.NAA43783@fsgi344.americas.sgi.com>
Subject: page buf meta data and FS corruption
To:     lord@sgi.com
Date:   Fri, 7 Apr 2000 13:51:09 -0500 (CDT)
Cc:     linux-xfs@oss.sgi.com
X-Mailer: ELM [version 2.5 PL2]
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing



I was running with page buf meta data turned on and XFSDEBUG and DEBUG.

I did lots of stuff on an XFS file system including building the
kernel: make clean, make dep, ...

Then, I noticed with top that 113MB or the 128MB of memory were in use.
I did an unmount and this went down to 30MBs. I'm guessing that we had
lots in cache.

After the unmount, I did a mount and was going to run some performance
numbers. The first file create resulted in the following ASSERT:

linux/fs/xfs/xfs_inode.c:xfs_ialloc()

	ASSERT(ip->i_d.di_nblocks == 0);

The newly allocated inode file has some blocks?

You mentioned that there is a known problem where we don't fully release
page bufs when unmounting. Could this be related? Should I open a PV for this?

Thanks,

Jim



From owner-linux-xfs@oss.sgi.com Fri Apr  7 12:38:47 2000
Received:  by oss.sgi.com id <S305163AbQDGTih>;
	Fri, 7 Apr 2000 12:38:37 -0700
Received: from deliverator.sgi.com ([204.94.214.10]:21585 "EHLO
        deliverator.sgi.com") by oss.sgi.com with ESMTP id <S305159AbQDGTiX>;
	Fri, 7 Apr 2000 12:38:23 -0700
Received: from info.engr.sgi.com (info.engr.sgi.com [192.26.80.216]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id MAA21721; Fri, 7 Apr 2000 12:33:41 -0700 (PDT)
	mail_from (nobody@info.engr.sgi.com)
Received: (from nobody@localhost) by info.engr.sgi.com (980427.SGI.8.8.8/980728.SGI.AUTOCF) id MAA66432; Fri, 7 Apr 2000 12:38:20 -0700 (PDT)
Date:   Fri, 7 Apr 2000 12:38:20 -0700 (PDT)
Message-Id: <200004071938.MAA66432@info.engr.sgi.com>
X-Pv-Incident: 787427 
webPV:  sgigate.sgi.com 
webExec: webpvsubmit,PvProjectIncident 
Reply-To: sgi.bugs.xfs@fido.engr.sgi.com
From:   pv@fddi-odin.corp.sgi.com (mostek@sgi.com)
Subject: BUG 787427 - file system corrupts with page buf meta data on after unmount/mount
To:     cattelan@cthulhu.engr.sgi.com
Cc:     linux-xfs@oss.sgi.com
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing

View Incident: http://co-op.engr.sgi.com/BugWorks/code/bwxquery.cgi?search=Search&wlong=1&view_type=Bug&wi=787427

Submitter : mostek                    Submitter Domain : sgi.com            
Assigned Engineer : cattelan          Assigned Domain : engr                
Assigned Group : xfs-linux            Category : software                   
Customer Reported : F                 Priority : 1                          
Project : xfs-linux                   Status : open                         
Description :
I did a complete kernel build with page buf meta data on.
Then, I did unmount and mount and when trying to use
that file system again, it was corrupt. Here is the output from
xfs_repair -n:

[root@carlos /root]# xfs_repair -n /dev/hda1
Phase 1 - find and verify superblock...
Phase 2 - using internal log
        - scan filesystem freespace and inode maps...
would zero unused portion of secondary superblock 0 sector
would zero unused portion of secondary superblock 1 sector
would zero unused portion of secondary superblock 2 sector
would zero unused portion of secondary superblock 3 sector
would zero unused portion of secondary superblock 4 sector
would zero unused portion of secondary superblock 5 sector
would zero unused portion of secondary superblock 6 sector
would zero unused portion of secondary superblock 7 sector
        - found root inode chunk
Phase 3 - for each AG...
        - scan (but don't clear) agi unlinked lists...
        - process known inodes and perform inode discovery...
        - agno = 0
imap claims in-use inode 441017 is free, would correct imap
        - agno = 1
        - agno = 2
        - agno = 3
        - agno = 4
        - agno = 5
        - agno = 6
        - agno = 7
        - process newly discovered inodes...
Phase 4 - check for duplicate blocks...
        - setting up duplicate extent list...
        - check for inodes claiming duplicate blocks...
        - agno = 0
        - agno = 1
        - agno = 2
        - agno = 3
        - agno = 4
        - agno = 5
        - agno = 6
        - agno = 7
No modify flag set, skipping phase 5
Phase 6 - check inode connectivity...
        - traversing filesystem starting at / ... 
        - traversal finished ... 
        - traversing all unattached subtrees ... 
        - traversals finished ... 
        - moving disconnected inodes to lost+found ... 
disconnected inode 441017, would move to lost+found
Phase 7 - verify link counts...
No modify flag set, skipping filesystem flush and exiting.
[root@carlos /root]# xfs_repair -n /dev/hda1
[root@carlos /root]# xfs_db /dev/hda1
xfs_db: mode = NATIVE, sim mode = NATIVE, arch = 1, magic = 0x58465342
xfs_db: inode 441017
xfs_db: p
core.magic = 0x494e
core.mode = 0100600
core.version = 1
core.format = 2 (extents)
core.nlinkv1 = 1
core.uid = 0
core.gid = 0
core.atime.sec = Thu Apr  6 22:32:15 2000
core.atime.nsec = 050000000
core.mtime.sec = Thu Apr  6 22:32:15 2000
core.mtime.nsec = 050000000
core.ctime.sec = Thu Apr  6 22:32:15 2000
core.ctime.nsec = 050000000
core.size = 0
core.nblocks = 16
core.extsize = 0
core.nextents = 1
core.naextents = 0
core.forkoff = 0
core.aformat = 2 (extents)
core.dmevmask = 0
core.dmstate = 0
core.newrtbm = 0
core.prealloc = 0
core.realtime = 0
core.gen = 0
next_unlinked = null
u.bmx[0] = [startoff,startblock,blockcount,extentflag] 0:[0,170100,16,0]
xfs_db: quit

We can see this inode has blocks and should have been freed.

Steve claims that this corruption is due to unmount not flushing
out all the dirty buffers. I suspec that this inode was really freed
before.

Here is a mail exchange between Steve and I on this issue:

> 
> 
> I was running with page buf meta data turned on and XFSDEBUG and DEBUG.
> 
> I did lots of stuff on an XFS file system including building the
> kernel: make clean, make dep, ...
> 
> Then, I noticed with top that 113MB or the 128MB of memory were in use.
> I did an unmount and this went down to 30MBs. I'm guessing that we had
> lots in cache.
> 
> After the unmount, I did a mount and was going to run some performance
> numbers. The first file create resulted in the following ASSERT:
> 
> linux/fs/xfs/xfs_inode.c:xfs_ialloc()
> 
>       ASSERT(ip->i_d.di_nblocks == 0);
> 
> The newly allocated inode file has some blocks?
> 
> You mentioned that there is a known problem where we don't fully release
> page bufs when unmounting. Could this be related? Should I open a PV for this
?
> 
> Thanks,
> 
> Jim
> 


Yep, unmount is where it happens - if you cat /proc/slabinfo after an
unmount there are sometimes things left behind in xfs structures.

Russell was going to look into this one.

From owner-linux-xfs@oss.sgi.com Fri Apr  7 14:15:38 2000
Received:  by oss.sgi.com id <S305165AbQDGVPT>;
	Fri, 7 Apr 2000 14:15:19 -0700
Received: from pneumatic-tube.sgi.com ([204.94.214.22]:15623 "EHLO
        pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP
	id <S305159AbQDGVPI>; Fri, 7 Apr 2000 14:15:08 -0700
Received: from ledzep.cray.com (ledzep.cray.com [137.38.226.97]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id OAA03866
	for <linux-xfs@oss.sgi.com>; Fri, 7 Apr 2000 14:18:56 -0700 (PDT)
	mail_from (mostek@sgi.com)
Received: from ironwood-e185.americas.sgi.com (ironwood.cray.com [128.162.185.212]) by ledzep.cray.com (SGI-SGI-8.9.3/craymail-smart-nospam1.0) with ESMTP id QAA84628 for <linux-xfs@oss.sgi.com>; Fri, 7 Apr 2000 16:13:51 -0500 (CDT)
Received: from fsgi344.americas.sgi.com (fsgi344.americas.sgi.com [128.162.184.15]) by ironwood-e185.americas.sgi.com (8.8.4/SGI-ironwood-e1.4) with ESMTP id QAA12631 for <linux-xfs@oss.sgi.com>; Fri, 7 Apr 2000 16:13:39 -0500 (CDT)
From:   Jim Mostek <mostek@sgi.com>
Received: by fsgi344.americas.sgi.com (980427.SGI.8.8.8/SGI-client.1.6) id QAA42880; Fri, 7 Apr 2000 16:13:40 -0500 (CDT)
Message-Id: <200004072113.QAA42880@fsgi344.americas.sgi.com>
Date:   Fri, 7 Apr 2000 16:13:40 -0500 (CDT)
To:     linux-xfs@oss.sgi.com
Subject: TAKE - Add delay alloc and more locking and some bug fixes.
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing

This take adds delay alloc/convert into xfs, but not fully yet into
page_buf.

Also, locking is added for page fault code so that page_faults
don't corrupt read/writes. This helps with doio, but there is still
more corruption when competing threads on the same file hit
NEW allocations that cover some exiting allocations (that cover both
holes and existing allocations). Will try to tackle this next week.

Reads now work faster than before, but I suspect some operations have
slowed down. Performance work to come later after we get rid of
corruption.

Modid:  2.3.99pre2-xfs:slinx:57237a
Date:  Fri Apr  7 14:10:54 PDT 2000
Workarea:  fsgi344:/data/clink/io/mostek/slinx-xfs

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

linux/fs/page_buf.c - 1.78
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/linux/fs/page_buf.c.diff?r1=text&tr1=1.78&r2=text&tr2=1.77&f=h
	- Remove the flag arg from _pagebuf_set_blocks_mp (not used).
	  Correctly determine the end of mapping/io before zero'ing extra
	  disk space. This is still not done.
	  Add the start of the delay alloc work by always asking for
	  PBF_DIRECT (which is what is running today). To get delay_alloc
	  extents back, set delay_alloc.
	  A Steve Lord bug fix. start at block 0 in prepare write not
	  block = page->index << (PAGE_CACHE_SHIFT - bbits);

linux/fs/xfs/linux/xfs_iops.c - 1.45
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/linux/fs/xfs/linux/xfs_iops.c.diff?r1=text&tr1=1.45&r2=text&tr2=1.44&f=h
	- Remove linvfs_get_block(), not used.
	  Have linvfs_pb_bmap just pass through flags.
	  Get I/O lock in read/write full page and linvfs_file_read.
	  This is done by having new routines in linvfs call pagebuf.
	  The xfs_read lock is removed in xfs_read and now obtained
	  in the linvfs layer routines at a lower level.
	  Add delay alloc iomap routine and convert routine. These are not
	  used, yet, but will be turned on soon when pagebuf is ready.

linux/fs/xfs/linux/xfs_lrw.c - 1.33
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/linux/fs/xfs/linux/xfs_lrw.c.diff?r1=text&tr1=1.33&r2=text&tr2=1.32&f=h
	- Add delay alloc iomap routine and convert routine. These are not
	  used, yet, but will be turned on soon when pagebuf is ready.


From owner-linux-xfs@oss.sgi.com Fri Apr  7 14:52:28 2000
Received:  by oss.sgi.com id <S305167AbQDGVwJ>;
	Fri, 7 Apr 2000 14:52:09 -0700
Received: from 01-019.044.popsite.net ([216.126.163.19]:64004 "EHLO
        gilgamesh.uruk") by oss.sgi.com with ESMTP id <S305159AbQDGVvo>;
	Fri, 7 Apr 2000 14:51:44 -0700
Received: from localhost [127.0.0.1] 
	by gilgamesh.uruk with esmtp (Exim 3.12 #1 (Debian))
	id 12dgfA-0002GP-00; Fri, 07 Apr 2000 17:51:36 -0400
Date:   Fri, 7 Apr 2000 17:51:36 -0400 (EDT)
From:   Jim Bray <jb@as220.org>
X-Sender: jb@gilgamesh.uruk
To:     linux-xfs@oss.sgi.com
Subject: Still Missing bfd.h for kdb
Message-ID: <Pine.LNX.4.10.10004071746120.8696-100000@gilgamesh.uruk>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing


  Anyone know if kdb is going to get GPL'd at some point?

  Could someone who has bfd.h mail it to me so I can see if it might be
done without? 

make[2]: Entering directory `/src/kernels/sgi/linux/kdb'
gcc -D__KERNEL__ -I/src/kernels/linux/include -Wall -Wstrict-prototypes
-O2 -fomit-frame-pointer -pipe  -mpreferred-stack-boundary=2 -DCPU=586
-march=k6 -fno-strict-aliasing    -c -o kdbmain.o kdbmain.c
In file included from kdbmain.c:36:
/src/kernels/linux/include/linux/kdbprivate.h:26: bfd.h: No such file or
directory

  I haven't tried XFS recently, but the kernel seems to be stable enough
other than that.

Jim	http://as220.org/jb


From owner-linux-xfs@oss.sgi.com Fri Apr  7 15:01:08 2000
Received:  by oss.sgi.com id <S305169AbQDGWA7>;
	Fri, 7 Apr 2000 15:00:59 -0700
Received: from deliverator.sgi.com ([204.94.214.10]:10501 "EHLO
        deliverator.sgi.com") by oss.sgi.com with ESMTP id <S305159AbQDGWAo>;
	Fri, 7 Apr 2000 15:00:44 -0700
Received: from madurai.engr.sgi.com (madurai.engr.sgi.com [163.154.5.75]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id OAA12907
	for <linux-xfs@oss.sgi.com>; Fri, 7 Apr 2000 14:56:02 -0700 (PDT)
	mail_from (ananth@sgi.com)
Received: from sgi.com (mango.engr.sgi.com [163.154.5.76]) by madurai.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) via ESMTP id OAA19407; Fri, 7 Apr 2000 14:58:26 -0700 (PDT)
Message-ID: <38EE5A1F.76A879A@sgi.com>
Date:   Fri, 07 Apr 2000 14:58:55 -0700
From:   Rajagopal Ananthanarayanan <ananth@sgi.com>
X-Mailer: Mozilla 4.6 [en] (X11; I; Linux 2.2.10-1SGI_11smp i686)
X-Accept-Language: en
MIME-Version: 1.0
To:     Jim Bray <jb@as220.org>
CC:     linux-xfs@oss.sgi.com
Subject: Re: Still Missing bfd.h for kdb
References: <Pine.LNX.4.10.10004071746120.8696-100000@gilgamesh.uruk>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing

Jim Bray wrote:
> 
>   Anyone know if kdb is going to get GPL'd at some point?
> 
>   Could someone who has bfd.h mail it to me so I can see if it might be
> done without?
> 
> make[2]: Entering directory `/src/kernels/sgi/linux/kdb'
> gcc -D__KERNEL__ -I/src/kernels/linux/include -Wall -Wstrict-prototypes
> -O2 -fomit-frame-pointer -pipe  -mpreferred-stack-boundary=2 -DCPU=586
> -march=k6 -fno-strict-aliasing    -c -o kdbmain.o kdbmain.c
> In file included from kdbmain.c:36:
> /src/kernels/linux/include/linux/kdbprivate.h:26: bfd.h: No such file or
> directory
> 
>   I haven't tried XFS recently, but the kernel seems to be stable enough
> other than that.


Hmm. kdb is open-sourced. Check out

http://oss.sgi.com/projects/kdb

There is a bfd.h for download if you need it.

ananth.

-- 
--------------------------------------------------------------------------
Rajagopal Ananthanarayanan ("ananth")
Member Technical Staff, SGI.
--------------------------------------------------------------------------

From owner-linux-xfs@oss.sgi.com Fri Apr  7 15:02:59 2000
Received:  by oss.sgi.com id <S305170AbQDGWCj>;
	Fri, 7 Apr 2000 15:02:39 -0700
Received: from deliverator.sgi.com ([204.94.214.10]:42501 "EHLO
        deliverator.sgi.com") by oss.sgi.com with ESMTP id <S305159AbQDGWCd>;
	Fri, 7 Apr 2000 15:02:33 -0700
Received: from ledzep.cray.com (ledzep.cray.com [137.38.226.97]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id OAA13185
	for <linux-xfs@oss.sgi.com>; Fri, 7 Apr 2000 14:57:50 -0700 (PDT)
	mail_from (lord@sgi.com)
Received: from ironwood-e185.americas.sgi.com (ironwood.cray.com [128.162.185.212]) by ledzep.cray.com (SGI-SGI-8.9.3/craymail-smart-nospam1.0) with ESMTP id RAA35045; Fri, 7 Apr 2000 17:00:00 -0500 (CDT)
Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.184.86]) by ironwood-e185.americas.sgi.com (8.8.4/SGI-ironwood-e1.4) with ESMTP id QAA17641; Fri, 7 Apr 2000 16:59:53 -0500 (CDT)
From:   Steve Lord <lord@sgi.com>
Received: from jen.americas.sgi.com by jen.americas.sgi.com (8.9.3/SGI-client.1.6) via ESMTP id QAA10643; Fri, 7 Apr 2000 16:59:25 -0500
Message-Id: <200004072159.QAA10643@jen.americas.sgi.com>
To:     Jim Bray <jb@as220.org>
cc:     linux-xfs@oss.sgi.com
Subject: Re: Still Missing bfd.h for kdb 
In-reply-to: Your message of "Fri, 07 Apr 2000 17:51:36 EDT
Date:   Fri, 07 Apr 2000 16:59:25 -0500
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing

> 
>   Anyone know if kdb is going to get GPL'd at some point?
> 
>   Could someone who has bfd.h mail it to me so I can see if it might be
> done without? 
> 
> make[2]: Entering directory `/src/kernels/sgi/linux/kdb'
> gcc -D__KERNEL__ -I/src/kernels/linux/include -Wall -Wstrict-prototypes
> -O2 -fomit-frame-pointer -pipe  -mpreferred-stack-boundary=2 -DCPU=586
> -march=k6 -fno-strict-aliasing    -c -o kdbmain.o kdbmain.c
> In file included from kdbmain.c:36:
> /src/kernels/linux/include/linux/kdbprivate.h:26: bfd.h: No such file or
> directory
> 
>   I haven't tried XFS recently, but the kernel seems to be stable enough
> other than that.
> 
> Jim	http://as220.org/jb


It looks like bdf.h comes from binutils, I am using binutils-2.9.5.0.22-6
which does contain it.


According to this page kdb is GPL, the code does not seem to say
that though.

http://oss.sgi.com/projects/kdb/license.html

Steve


From owner-linux-xfs@oss.sgi.com Fri Apr  7 17:57:20 2000
Received:  by oss.sgi.com id <S305171AbQDHA5L>;
	Fri, 7 Apr 2000 17:57:11 -0700
Received: from 01-035.044.popsite.net ([216.126.163.35]:6404 "EHLO
        gilgamesh.uruk") by oss.sgi.com with ESMTP id <S305159AbQDHA4x>;
	Fri, 7 Apr 2000 17:56:53 -0700
Received: from localhost [127.0.0.1] 
	by gilgamesh.uruk with esmtp (Exim 3.12 #1 (Debian))
	id 12djYA-00007K-00; Fri, 07 Apr 2000 20:56:34 -0400
Date:   Fri, 7 Apr 2000 20:56:33 -0400 (EDT)
From:   Jim Bray <jb@as220.org>
X-Sender: jb@gilgamesh.uruk
To:     Rajagopal Ananthanarayanan <ananth@sgi.com>,
        Steve Lord <lord@sgi.com>
cc:     linux-xfs@oss.sgi.com
Subject: Re: several messages
In-Reply-To: <200004072159.QAA10643@jen.americas.sgi.com>
Message-ID: <Pine.LNX.4.10.10004072020130.228-100000@gilgamesh.uruk>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing

On Fri, 7 Apr 2000, Rajagopal Ananthanarayanan wrote:

> 
> Hmm. kdb is open-sourced.

On Fri, 7 Apr 2000, Steve Lord wrote:

> According to this page kdb is GPL, the code does not seem to say
> that though.

  Right. The code just says:

 * Copyright (C) 1999 Silicon Graphics, Inc.
...
 * See the file LIA-COPYRIGHT for additional information.

  I think for it to be GPL, that has to be explicit in the code, as with
the xfs code:


* Copyright (c) 2000 Silicon Graphics, Inc.  All Rights Reserved.
 * 
 * This program is free software; you can redistribute it and/or modify it
 * under the terms of version 2 of the GNU General Public License as
 * published by the Free Software Foundation.

  So it appears that kdb is still proprietary code.

On Fri, 7 Apr 2000, Rajagopal Ananthanarayanan wrote:

> 
> There is a bfd.h for download if you need it.

  Thanks. I'm more interested at present in getting SGI Linux to build on
my Debian/unstable system without tweakage.

On Fri, 7 Apr 2000, Steve Lord wrote:

> It looks like bdf.h comes from binutils, I am using binutils-2.9.5.0.22-6
> which does contain it.

 Ahh, the right clue. Should have done this earlier:
> 
> gilgamesh:~[1]dpkg -S bfd
...
binutils: /usr/lib/libbfd-2.9.5.0.31.so
...
but no bfd.h.

  The problem is that there is a binutils-dev, in the Extra section of
Debian, that I hadn't needed till now and didn't know about. Something is
broken with debian/unstable (happens less often than you'd think), so I
can't get the package at present, but it will almost certainly give me
bfd.h.

  Debian seems as a rule to separate out the .h files and so forth and put
them in a separate <package>-devel. You might want to note the need for
binutils-dev in appropriate READMEs, maybe in the configuration help for
CONFIG_KDB. I suspect most Debian users won't have binutils-devel
installed; some will figure it out on their own, and maybe others like me
will assume it is some SGI-specific .h file that for some reason didn't
make it into the tree.

  The case could be made that #including bfd.h is a bad idea unless it is
unavoidable. I don't know if this is a hard and fast rule, but I poked
thru the kernel code to confirm my impression that things generally only
#include <linux/ or asm/>, thus keeping the kernel source self-contained.
Looking thru kdbprivate.h, which is where <bfd.h> comes in, the only
obvious use of a bfd-thing is:

typedef struct _kdb_bp {
        bfd_vma         bp_addr;        /* Address breakpoint is present
at */
        kdb_machinst_t  bp_inst;        /* Replaced instruction */

  If bfd_vma turns out to be a fancy way to say char *, I'd toss it.
Doesn't look like it comes into play in the code much:
gilgamesh:/src/sgi/linux/kdb[1]grep bfd *.c
<sound of one hand clapping>

Jim	http://as220.org/jb


From owner-linux-xfs@oss.sgi.com Fri Apr  7 20:40:32 2000
Received:  by oss.sgi.com id <S305172AbQDHDkN>;
	Fri, 7 Apr 2000 20:40:13 -0700
Received: from 01-027.044.popsite.net ([216.126.163.27]:22532 "EHLO
        gilgamesh.uruk") by oss.sgi.com with ESMTP id <S305159AbQDHDjk>;
	Fri, 7 Apr 2000 20:39:40 -0700
Received: from localhost [127.0.0.1] 
	by gilgamesh.uruk with esmtp (Exim 3.12 #1 (Debian))
	id 12dm5w-00034k-00; Fri, 07 Apr 2000 23:39:36 -0400
Date:   Fri, 7 Apr 2000 23:39:31 -0400 (EDT)
From:   Jim Bray <jb@as220.org>
X-Sender: jb@gilgamesh.uruk
To:     linux-xfs@oss.sgi.com
Subject: Maybe use caddr_t instead of bfd_vma?
In-Reply-To: <Pine.LNX.4.10.10004072020130.228-100000@gilgamesh.uruk>
Message-ID: <Pine.LNX.4.10.10004072231300.8141-100000@gilgamesh.uruk>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing

On Fri, 7 Apr 2000, Jim Bray wrote:

  It looks like on ia32, the sole purpose of bfd.h might be to tell us
that bfd_vma is a u_long. If it is doing what it at first glance appears
to be doing, perhaps our venerable old friend caddr_t could be #included
from <linux/types.h> instead. This pulls in an arch-determined definition
from <asm/types.h>, so it should be portable enough.

...no, it is used for a bit more in 
/src/sgi/linux/arch/i386/kdb
but could probably still be done without. The other things being used are
all things that the kernel must also have strong ideas about:

bfd_target_elf_flavour;
bfd_arch_i386;
bfd_mach_i386_i386;

Jim	http://as220.org/jb


From owner-linux-xfs@oss.sgi.com Fri Apr  7 21:08:32 2000
Received:  by oss.sgi.com id <S305173AbQDHEIN>;
	Fri, 7 Apr 2000 21:08:13 -0700
Received: from as220.org ([155.212.110.53]:1551 "EHLO as220.org")
	by oss.sgi.com with ESMTP id <S305159AbQDHEHx>;
	Fri, 7 Apr 2000 21:07:53 -0700
Received: from localhost (jb@localhost [127.0.0.1])
	by as220.org (8.9.3/8.9.3/Debian/GNU) with ESMTP id HAA05028;
	Sat, 8 Apr 2000 07:06:58 -0500
Date:   Sat, 8 Apr 2000 07:06:58 -0500 (EST)
From:   Jim Bray <jb@as220.org>
To:     Jim Mostek <mostek@sgi.com>,
        Russell Cattelan <cattelan@thebarn.com>
cc:     linux-xfs@oss.sgi.com
Subject: thanks; more bad stuff 'bout bfd.h
In-Reply-To: <38EE5C5A.21F36E90@thebarn.com>
Message-ID: <Pine.LNX.4.21.0004080656590.4965-100000@as220.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing


Hi Jim and Russell,

  Thanks for trying to send bfd.h to me. God God, the thing is more than
100 K! If I had any idea, I wouldn't have asked. I just found it; my
procmail script on as220 doesn't forward anything >100k to my ISP address.

  I just have a Bad Feeling about a piece of in-kernel code pulling some
whonkin' huge machine-generated file from /usr/include in. If I am correct
in assuming that the rest of the kernel doesn't do this, then this might
(rightfully, IMHO) make acceptance of kdb unlikely.

Jim	     http://as220.org/jb
			[Advertisement]

		       "Y2K:
		   Bringing The Past
		   Into The Future
		   	Today"



From owner-linux-xfs@oss.sgi.com Sun Apr  9 03:08:38 2000
Received:  by oss.sgi.com id <S305155AbQDIKI2>;
	Sun, 9 Apr 2000 03:08:28 -0700
Received: from file.phys.tohoku.ac.jp ([130.34.117.125]:57067 "HELO
        file.phys.tohoku.ac.jp") by oss.sgi.com with SMTP
	id <S305154AbQDIKIH>; Sun, 9 Apr 2000 03:08:07 -0700
Received: (qmail 10138 invoked by uid 239); 9 Apr 2000 10:08:02 -0000
Message-ID: <20000409100802.10137.qmail@file.phys.tohoku.ac.jp>
Date:   Sun, 09 Apr 2000 19:08:02 +0900
From:   suzukis@file.phys.tohoku.ac.jp
To:     linux-xfs@oss.sgi.com
Subject: 486 and Linux-2.3.99pre2+XFS
Mime-Version: 1.0
Content-type: text/plain; charset=ISO-2022-JP
X-Mailer: addmail [version 2.0.12]
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing

# For first, I must apologize,
# this is NOT related to the XFS implementation itself,
# this is related to the kernel source publisized by SGI.
# However, I wish, it's not completely-meaningless for
# linux-xfs subscribers who failed to run on 486 PC.

Hello,

There's anybody who makes Linux-XFS kernel (by SGI)
running on 486 PC? Yet I've not succeed to do it.
Even if the kernel can run on 586 (and later) PCs,
it fails on 486. Of course, I choose 386 + math emulation
in kernel configuration. I receive following message.

My environments are almost from RedHat Linux 6.2.

gcc		:egcs-2.91.66 19990314/Linux (egcs-1.1.2 release)
binutils	:binutils-2.9.5.0.22

---------------------------------------------------------------------
zone(0): 4096 pages.
zone(1): 12360 pages.
zone(2): 0 pages.
Initializing CPU#0
Console: colour VGA 80x25
Calibrating delay loop... 33.10 BogoMIPS
Memory: 62076k/65824k available (1336k kernel code, 3360k reserved, 94k data, 192k init, 0k highmem)
Checking if this processor honours the WP bit even in supervisor mode... invalid operand: 0000
CPU:	0
EIP:	0010:[<c010b200>]
EFLAGS:	00010206
eax: 00101001	ebx: 00000530	ecx: 000001d9	edx: 00001000
esi: 00000100	edi: 00000014	ebp: 00000001	esp: c0267f98
Process swapper (pid: 0, stackpage=c0267000)
Stack: 00101001 00001000 00000063 c0290003 c026bf1a c0260010 00010206 c026c11f
       00000000 00092000 c0105000 00001ff0 0000f27c 00131560 00000002 00004048
       00000002 00004048 00000348 c02689a5 00000000 c0267ff8 c01f3da0 00000000
Call Trace: [<c0105000>][<c01f3da0>][<c010018d>]
Code 0f 32 03 e0 fe 0f 30 58 5a 59 68 c0 0f 11 cc0 e9 9c fe ff ff
Kernel Panic: Attempted to kill the idle task!
In idle task - not syncing
---------------------------------------------------------------------
The error seems to be related to the SGI's modification of
"page_fault" entry in arch/i386/kernel/entry.S.

diff -x CVS -Nur linux-2.3.99pre2/arch/i386/kernel/entry.S linux-sgi/arch/i386/kernel/entry.S
--- linux-2.3.99pre2/arch/i386/kernel/entry.S   Sun Apr  2 16:26:51 2000
+++ linux-sgi/arch/i386/kernel/entry.S  Sat Mar 25 09:41:33 2000
@@ -410,6 +432,16 @@
        jmp error_code
 
 ENTRY(page_fault)
+       pushl %ecx
+       pushl %edx
+       pushl %eax
+       movl  $473,%ecx
+       rdmsr
+       andl  $0xfffffffe,%eax
+       wrmsr
+       popl  %eax
+       popl  %edx
+       popl  %ecx
        pushl $ SYMBOL_NAME(do_page_fault)
        jmp error_code

When I remove above additional instructions, the WP bit
checking succeed. What the above instructions are to do,
and what feature requests them, and it's possible to port
on 386/486 PCs?

suzuki

From owner-linux-xfs@oss.sgi.com Sun Apr  9 05:04:59 2000
Received:  by oss.sgi.com id <S305156AbQDIMEk>;
	Sun, 9 Apr 2000 05:04:40 -0700
Received: from Cantor.suse.de ([194.112.123.193]:50693 "HELO Cantor.suse.de")
	by oss.sgi.com with SMTP id <S305154AbQDIMEN>;
	Sun, 9 Apr 2000 05:04:13 -0700
Received: from Hermes.suse.de (Hermes.suse.de [194.112.123.136])
	by Cantor.suse.de (Postfix) with ESMTP
	id C754D1E140; Sun,  9 Apr 2000 14:04:11 +0200 (MEST)
Received: from gruyere.muc.suse.de (gruyere.muc.suse.de [10.23.1.2])
	by Hermes.suse.de (Postfix) with ESMTP
	id 92B3610A026; Sun,  9 Apr 2000 14:03:55 +0200 (MEST)
Received: by gruyere.muc.suse.de (Postfix, from userid 14446)
	id 3576E2F36B; Sun,  9 Apr 2000 14:03:54 +0200 (MEST)
Date:   Sun, 9 Apr 2000 14:03:54 +0200
From:   "Andi Kleen" <ak@suse.de>
To:     suzukis@file.phys.tohoku.ac.jp
Cc:     linux-xfs@oss.sgi.com
Subject: Re: 486 and Linux-2.3.99pre2+XFS
Message-ID: <20000409140354.A29535@gruyere.muc.suse.de>
References: <20000409100802.10137.qmail@file.phys.tohoku.ac.jp>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 1.0i
In-Reply-To: <20000409100802.10137.qmail@file.phys.tohoku.ac.jp>; from suzukis@file.phys.tohoku.ac.jp on Sun, Apr 09, 2000 at 07:08:02PM +0900
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing

On Sun, Apr 09, 2000 at 07:08:02PM +0900, suzukis@file.phys.tohoku.ac.jp wrote:
> # For first, I must apologize,
> # this is NOT related to the XFS implementation itself,
> # this is related to the kernel source publisized by SGI.
> # However, I wish, it's not completely-meaningless for
> # linux-xfs subscribers who failed to run on 486 PC.
> 
> Hello,
> 
> There's anybody who makes Linux-XFS kernel (by SGI)
> running on 486 PC? Yet I've not succeed to do it.
> Even if the kernel can run on 586 (and later) PCs,
> it fails on 486. Of course, I choose 386 + math emulation
> in kernel configuration. I receive following message.

This is a KDB bug. It uses Pentium specific MSRs without checking that it
really runs on a Pentium. Try turning off CONFIG_KDB or apply the following
patch: 

-Andi

--- linux/arch/i386/kdb/kdbasupport.c-k6kdb	Sat Mar 25 01:41:33 2000
+++ linux/arch/i386/kdb/kdbasupport.c	Mon Apr  3 20:50:59 2000
@@ -37,6 +37,41 @@
 unsigned long smp_kdb_wait;
 #endif
 
+enum cpu { IntelP5, IntelP6, AmdK6, Unknown } kdba_msrtype; 
+
+/* The normal kernel does the same, but be independent. */ 
+static void 
+kdba_checkcpu(void) 
+{ 
+	union { 
+		char str[12]; 
+		__u32 reg[3];  
+	} v; 
+	int eax,ebx,ecx,edx; 
+	__asm__("cpuid" 
+		: "=a" (eax), "=b" (v.reg[0]) , "=c" (v.reg[1]), "=d" (v.reg[2])
+		: "a" (0)); 
+	__asm__("cpuid"
+		: "=a" (eax), "=b" (ebx), "=c" (ecx), "=d" (edx)
+		: "a" (1)); 
+
+	kdba_msrtype = Unknown; 
+	if (!strcmp(v.str, "GenuineIntel")) {
+		switch ((ebx >> 4) & 0xF) { 
+		case 5:
+			kdba_msrtype = IntelP5;
+			break;
+		case 6:
+			kdba_msrtype = IntelP6;
+			break;
+		}			
+	} else if (!strcmp(v.str, "AuthenticAMD") && (((ebx >> 4) & 0xF) == 6)) {
+		kdba_msrtype = AmdK6; 
+	}
+} 
+
+
+
 void
 kdba_installdbreg(kdb_bp_t *bp)
 {
@@ -708,6 +743,11 @@
 {
 	u32  lv, hv;
 
+	if (kdba_msrtype != IntelP6) { 
+		kdb_printf("Last branch information not supported on this CPU.\n");
+		return;
+	}
+
 	rdmsr(DEBUGCTLMSR, lv, hv);
 	lv |= 0x1;	/* Set LBR enable */
 	wrmsr(DEBUGCTLMSR, lv, hv);
@@ -734,6 +774,11 @@
 	u32  bflv, bfhv;
 	u32  btlv, bthv;
 
+	if (kdba_msrtype != IntelP6) { 
+		kdb_printf("Last branch information not supported on this CPU.\n");
+		return;
+	}
+
 	rdmsr(LASTBRANCHFROMIP, bflv, bfhv);
 	rdmsr(LASTBRANCHTOIP, btlv, bthv);
 	kdb_printf("Last Branch IP, from: 0x%x  to 0x%x\n",
@@ -1087,6 +1132,7 @@
 void
 kdba_init(void)
 {
+	kdba_checkcpu(); 
 	kdba_enablelbr();
 
 	return;
--- linux/arch/i386/kernel/entry.S-k6kdb	Sat Mar 25 01:41:33 2000
+++ linux/arch/i386/kernel/entry.S	Mon Apr  3 20:52:24 2000
@@ -432,16 +432,6 @@
 	jmp error_code
 
 ENTRY(page_fault)
-	pushl %ecx
-	pushl %edx
-	pushl %eax
-	movl  $473,%ecx
-	rdmsr
-	andl  $0xfffffffe,%eax
-	wrmsr
-	popl  %eax
-	popl  %edx
-	popl  %ecx
 	pushl $ SYMBOL_NAME(do_page_fault)
 	jmp error_code
 

From owner-linux-xfs@oss.sgi.com Sun Apr  9 05:11:30 2000
Received:  by oss.sgi.com id <S305157AbQDIMLK>;
	Sun, 9 Apr 2000 05:11:10 -0700
Received: from file.phys.tohoku.ac.jp ([130.34.117.125]:1772 "HELO
        file.phys.tohoku.ac.jp") by oss.sgi.com with SMTP
	id <S305154AbQDIMLD>; Sun, 9 Apr 2000 05:11:03 -0700
Received: (qmail 10407 invoked by uid 239); 9 Apr 2000 12:11:00 -0000
Message-ID: <20000409121100.10406.qmail@file.phys.tohoku.ac.jp>
Date:   Sun, 09 Apr 2000 21:11:00 +0900
From:   suzukis@file.phys.tohoku.ac.jp
To:     linux-xfs@oss.sgi.com
Cc:     ak@suse.de
In-reply-to: "Andi Kleen" 's message of Sun, 9 Apr 2000 14:03:54 +0200<20000409140354.A29535@gruyere.muc.suse.de>
Subject: Re: 486 and Linux-2.3.99pre2+XFS
Mime-Version: 1.0
Content-type: text/plain; charset=US-ASCII
X-Mailer: addmail [version 2.0.12]
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing

Dear Mr. Andi,

>>Even if the kernel can run on 586 (and later) PCs,
>>it fails on 486. Of course, I choose 386 + math emulation
>>in kernel configuration. I receive following message.
>
>This is a KDB bug.
>It uses Pentium specific MSRs without checking that it
>really runs on a Pentium.

Much Thanks!

>Try turning off CONFIG_KDB or apply the following patch: 

OK, I will use your patch - I wish your patch will be
applied in CVS tree of SGI soon.
However, turning off CONFIG_KDB could not save me,
because the part was always compiled (there's no
"ifdef - endif" conditional scissor in page_fault
entry modification).

suzuki

From owner-linux-xfs@oss.sgi.com Sun Apr  9 05:30:50 2000
Received:  by oss.sgi.com id <S305159AbQDIMak>;
	Sun, 9 Apr 2000 05:30:40 -0700
Received: from Cantor.suse.de ([194.112.123.193]:48646 "HELO Cantor.suse.de")
	by oss.sgi.com with SMTP id <S305154AbQDIMaN>;
	Sun, 9 Apr 2000 05:30:13 -0700
Received: from Hermes.suse.de (Hermes.suse.de [194.112.123.136])
	by Cantor.suse.de (Postfix) with ESMTP
	id A23621E13D; Sun,  9 Apr 2000 14:30:11 +0200 (MEST)
Received: from gruyere.muc.suse.de (gruyere.muc.suse.de [10.23.1.2])
	by Hermes.suse.de (Postfix) with ESMTP
	id 37A1D10A026; Sun,  9 Apr 2000 14:29:56 +0200 (MEST)
Received: by gruyere.muc.suse.de (Postfix, from userid 14446)
	id A37B42F36B; Sun,  9 Apr 2000 14:29:55 +0200 (MEST)
Date:   Sun, 9 Apr 2000 14:29:55 +0200
From:   "Andi Kleen" <ak@suse.de>
To:     suzukis@file.phys.tohoku.ac.jp
Cc:     linux-xfs@oss.sgi.com, ak@suse.de
Subject: Re: 486 and Linux-2.3.99pre2+XFS
Message-ID: <20000409142955.A29727@gruyere.muc.suse.de>
References: <20000409140354.A29535@gruyere.muc.suse.de> <20000409121100.10406.qmail@file.phys.tohoku.ac.jp>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 1.0i
In-Reply-To: <20000409121100.10406.qmail@file.phys.tohoku.ac.jp>; from suzukis@file.phys.tohoku.ac.jp on Sun, Apr 09, 2000 at 09:11:00PM +0900
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing

On Sun, Apr 09, 2000 at 09:11:00PM +0900, suzukis@file.phys.tohoku.ac.jp wrote:
> >Try turning off CONFIG_KDB or apply the following patch: 
> 
> OK, I will use your patch - I wish your patch will be
> applied in CVS tree of SGI soon.

I hope so too (I need it for my AMDs) 

> However, turning off CONFIG_KDB could not save me,
> because the part was always compiled (there's no
> "ifdef - endif" conditional scissor in page_fault
> entry modification).

Good point. The patch should work though.
The page_fault entry change obviously was a quick hack that was not 
fully thought out..

-Andi

From owner-linux-xfs@oss.sgi.com Sun Apr  9 06:52:21 2000
Received:  by oss.sgi.com id <S305161AbQDINwK>;
	Sun, 9 Apr 2000 06:52:10 -0700
Received: from deliverator.sgi.com ([204.94.214.10]:20241 "EHLO
        deliverator.sgi.com") by oss.sgi.com with ESMTP id <S305154AbQDINvs>;
	Sun, 9 Apr 2000 06:51:48 -0700
Received: from ledzep.cray.com (ledzep.cray.com [137.38.226.97]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id GAA12111
	for <linux-xfs@oss.sgi.com>; Sun, 9 Apr 2000 06:47:05 -0700 (PDT)
	mail_from (lord@sgi.com)
Received: from ironwood-e185.americas.sgi.com (ironwood.cray.com [128.162.185.212]) by ledzep.cray.com (SGI-SGI-8.9.3/craymail-smart-nospam1.0) with ESMTP id IAA26359; Sun, 9 Apr 2000 08:49:13 -0500 (CDT)
Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.184.86]) by ironwood-e185.americas.sgi.com (8.8.4/SGI-ironwood-e1.4) with ESMTP id IAA14583; Sun, 9 Apr 2000 08:49:07 -0500 (CDT)
From:   Steve Lord <lord@sgi.com>
Received: from jen.americas.sgi.com by jen.americas.sgi.com (8.9.3/SGI-client.1.6) via ESMTP id IAA18054; Sun, 9 Apr 2000 08:48:24 -0500
Message-Id: <200004091348.IAA18054@jen.americas.sgi.com>
To:     "Andi Kleen" <ak@suse.de>
cc:     suzukis@file.phys.tohoku.ac.jp, linux-xfs@oss.sgi.com
Subject: Re: 486 and Linux-2.3.99pre2+XFS 
In-reply-to: Your message of "Sun, 09 Apr 2000 14:29:55 +0200
Date:   Sun, 09 Apr 2000 08:48:24 -0500
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing

> On Sun, Apr 09, 2000 at 09:11:00PM +0900, suzukis@file.phys.tohoku.ac.jp wrot
e:
> > >Try turning off CONFIG_KDB or apply the following patch: 
> > 
> > OK, I will use your patch - I wish your patch will be
> > applied in CVS tree of SGI soon.
> 
> I hope so too (I need it for my AMDs) 
> 
> > However, turning off CONFIG_KDB could not save me,
> > because the part was always compiled (there's no
> > "ifdef - endif" conditional scissor in page_fault
> > entry modification).
> 
> Good point. The patch should work though.
> The page_fault entry change obviously was a quick hack that was not 
> fully thought out..
> 
> -Andi


Hi, sorry for not getting back to you on this sooner, I tried out the
pacth, and I think there is a problem with the code which determines
the cpu id, it fails to recognize a P3 Katmai, the bootup code reports

CPU0: Intel Pentium III (Katmai) stepping 03
CPU1: Intel Pentium III (Katmai) stepping 03

But the cpuid code in kdb ends up giving me type 3 (unknown). Maybe
it would be better to directly reference the cpuinfo_x86 setup at
boot time.

Steve


From owner-linux-xfs@oss.sgi.com Sun Apr  9 17:38:37 2000
Received:  by oss.sgi.com id <S305156AbQDJAi1>;
	Sun, 9 Apr 2000 17:38:27 -0700
Received: from deliverator.sgi.com ([204.94.214.10]:31310 "EHLO
        deliverator.sgi.com") by oss.sgi.com with ESMTP id <S305154AbQDJAiO>;
	Sun, 9 Apr 2000 17:38:14 -0700
Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via SMTP id RAA12475
	for <linux-xfs@oss.sgi.com>; Sun, 9 Apr 2000 17:33:28 -0700 (PDT)
	mail_from (dxm@snort.melbourne.sgi.com)
Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.55.149]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id KAA25234 for <@larry.melbourne.sgi.com:linux-xfs@oss.sgi.com>; Mon, 10 Apr 2000 10:36:53 +1000
Received: (from dxm@localhost) by snort.melbourne.sgi.com (980427.SGI.8.8.8/980728.SGI.AUTOCF) id KAA83453 for linux-xfs@oss.sgi.com; Mon, 10 Apr 2000 10:36:53 +1000 (EST)
Date:   Mon, 10 Apr 2000 10:36:53 +1000 (EST)
From:   dxm@snort.melbourne.sgi.com (Daniel Moore)
Message-Id: <200004100036.KAA83453@snort.melbourne.sgi.com>
To:     linux-xfs@oss.sgi.com
Subject: TAKE - dir2 architecture mods
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing

  - dir2 block, leaf, and nodes
  - fix sf
  - fix xfs_db
  - fix xfsidbg

Actual btree code not converted yet (xfs_da_btree + ?), but data
stored within is.

Modid:  2.3.99pre2-xfs:slinx:57286a
Date:  Sun Apr  9 17:13:19 PDT 2000
Workarea:  snort:/build1/people/dxm/isms/slinx-xfs

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

cmd/xfs/db/check.c - 1.46
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/cmd/xfs/db/check.c.diff?r1=text&tr1=1.46&r2=text&tr2=1.45&f=h
cmd/xfs/db/dir2.c - 1.5
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/cmd/xfs/db/dir2.c.diff?r1=text&tr1=1.5&r2=text&tr2=1.4&f=h
linux/fs/xfs/xfs_da_btree.c - 1.103
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/linux/fs/xfs/xfs_da_btree.c.diff?r1=text&tr1=1.103&r2=text&tr2=1.102&f=h
linux/fs/xfs/xfs_dir2.c - 1.16
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/linux/fs/xfs/xfs_dir2.c.diff?r1=text&tr1=1.16&r2=text&tr2=1.15&f=h
linux/fs/xfs/xfs_dir2_block.c - 1.9
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/linux/fs/xfs/xfs_dir2_block.c.diff?r1=text&tr1=1.9&r2=text&tr2=1.8&f=h
linux/fs/xfs/xfs_dir2_block.h - 1.5
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/linux/fs/xfs/xfs_dir2_block.h.diff?r1=text&tr1=1.5&r2=text&tr2=1.4&f=h
linux/fs/xfs/xfs_dir2_data.c - 1.9
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/linux/fs/xfs/xfs_dir2_data.c.diff?r1=text&tr1=1.9&r2=text&tr2=1.8&f=h
linux/fs/xfs/xfs_dir2_data.h - 1.5
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/linux/fs/xfs/xfs_dir2_data.h.diff?r1=text&tr1=1.5&r2=text&tr2=1.4&f=h
linux/fs/xfs/xfs_dir2_leaf.c - 1.10
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/linux/fs/xfs/xfs_dir2_leaf.c.diff?r1=text&tr1=1.10&r2=text&tr2=1.9&f=h
linux/fs/xfs/xfs_dir2_leaf.h - 1.5
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/linux/fs/xfs/xfs_dir2_leaf.h.diff?r1=text&tr1=1.5&r2=text&tr2=1.4&f=h
linux/fs/xfs/xfs_dir2_node.c - 1.10
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/linux/fs/xfs/xfs_dir2_node.c.diff?r1=text&tr1=1.10&r2=text&tr2=1.9&f=h
linux/fs/xfs/xfs_dir2_sf.c - 1.14
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/linux/fs/xfs/xfs_dir2_sf.c.diff?r1=text&tr1=1.14&r2=text&tr2=1.13&f=h
linux/fs/xfs/xfs_dir2_sf.h - 1.9
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/linux/fs/xfs/xfs_dir2_sf.h.diff?r1=text&tr1=1.9&r2=text&tr2=1.8&f=h
linux/fs/xfs/xfs_macros.c - 1.34
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/linux/fs/xfs/xfs_macros.c.diff?r1=text&tr1=1.34&r2=text&tr2=1.33&f=h
linux/fs/xfs/xfs_rw.c - 1.312
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/linux/fs/xfs/xfs_rw.c.diff?r1=text&tr1=1.312&r2=text&tr2=1.311&f=h
linux/fs/xfs/xfsidbg.c - 1.126
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/linux/fs/xfs/xfsidbg.c.diff?r1=text&tr1=1.126&r2=text&tr2=1.125&f=h

From owner-linux-xfs@oss.sgi.com Sun Apr  9 19:13:58 2000
Received:  by oss.sgi.com id <S305157AbQDJCNt>;
	Sun, 9 Apr 2000 19:13:49 -0700
Received: from deliverator.sgi.com ([204.94.214.10]:40792 "EHLO
        deliverator.sgi.com") by oss.sgi.com with ESMTP id <S305154AbQDJCNa>;
	Sun, 9 Apr 2000 19:13:30 -0700
Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via SMTP id TAA17412
	for <linux-xfs@oss.sgi.com>; Sun, 9 Apr 2000 19:08:46 -0700 (PDT)
	mail_from (dxm@clouds.melbourne.sgi.com)
Received: from clouds.melbourne.sgi.com (clouds.melbourne.sgi.com [134.14.55.166]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id MAA25809 for <@larry.melbourne.sgi.com:linux-xfs@oss.sgi.com>; Mon, 10 Apr 2000 12:10:56 +1000
Received: from localhost (dxm@localhost) by clouds.melbourne.sgi.com (980427.SGI.8.8.8/980728.SGI.AUTOCF) via SMTP id MAA56073 for <linux-xfs@oss.sgi.com>; Mon, 10 Apr 2000 12:10:56 +1000 (EST)
Message-Id: <200004100210.MAA56073@clouds.melbourne.sgi.com>
X-Mailer: exmh version 2.0.2 2/24/98
To:     linux-xfs@oss.sgi.com
Subject: TAKE - dir2 architecture fixes
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date:   Mon, 10 Apr 2000 12:10:56 +1000
From:   Daniel Moore <dxm@clouds.melbourne.sgi.com>
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing


fix fallout from dir2 architecture mod.

Modid:  2.3.99pre2-xfs:slinx:57287a
Date:  Sun Apr  9 19:05:17 PDT 2000
Workarea:  snort:/build1/people/dxm/isms/slinx-xfs

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

cmd/xfs/repair/attr_repair.c - 1.13
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/cmd/xfs/repair/attr_repair.c.diff?r1=text&tr1=1.13&r2=text&tr2=1.12&f=h
cmd/xfs/repair/dinode.c - 1.73
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/cmd/xfs/repair/dinode.c.diff?r1=text&tr1=1.73&r2=text&tr2=1.72&f=h
cmd/xfs/repair/dir.c - 1.52
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/cmd/xfs/repair/dir.c.diff?r1=text&tr1=1.52&r2=text&tr2=1.51&f=h
cmd/xfs/repair/dir2.c - 1.8
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/cmd/xfs/repair/dir2.c.diff?r1=text&tr1=1.8&r2=text&tr2=1.7&f=h
cmd/xfs/repair/phase4.c - 1.43
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/cmd/xfs/repair/phase4.c.diff?r1=text&tr1=1.43&r2=text&tr2=1.42&f=h
cmd/xfs/repair/phase6.c - 1.51
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/cmd/xfs/repair/phase6.c.diff?r1=text&tr1=1.51&r2=text&tr2=1.50&f=h




From owner-linux-xfs@oss.sgi.com Mon Apr 10 10:27:34 2000
Received:  by oss.sgi.com id <S305159AbQDJR1Y>;
	Mon, 10 Apr 2000 10:27:24 -0700
Received: from deliverator.sgi.com ([204.94.214.10]:31587 "EHLO
        deliverator.sgi.com") by oss.sgi.com with ESMTP id <S305154AbQDJR1O>;
	Mon, 10 Apr 2000 10:27:14 -0700
Received: from ledzep.cray.com (ledzep.cray.com [137.38.226.97]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id KAA24526
	for <linux-xfs@oss.sgi.com>; Mon, 10 Apr 2000 10:22:30 -0700 (PDT)
	mail_from (mostek@sgi.com)
Received: from ironwood-e185.americas.sgi.com (ironwood.cray.com [128.162.185.212]) by ledzep.cray.com (SGI-SGI-8.9.3/craymail-smart-nospam1.0) with ESMTP id MAA39236; Mon, 10 Apr 2000 12:25:55 -0500 (CDT)
Received: from fsgi344.americas.sgi.com (fsgi344.americas.sgi.com [128.162.184.15]) by ironwood-e185.americas.sgi.com (8.8.4/SGI-ironwood-e1.4) with ESMTP id MAA04287; Mon, 10 Apr 2000 12:25:48 -0500 (CDT)
From:   Jim Mostek <mostek@sgi.com>
Received: by fsgi344.americas.sgi.com (980427.SGI.8.8.8/SGI-client.1.6) id MAA44423; Mon, 10 Apr 2000 12:25:54 -0500 (CDT)
Message-Id: <200004101725.MAA44423@fsgi344.americas.sgi.com>
Subject: XFS magazine article in JOLT
To:     shepardl@engr.sgi.com
Date:   Mon, 10 Apr 2000 12:25:54 -0500 (CDT)
Cc:     steven@sgi.com, linux-xfs@oss.sgi.com
X-Mailer: ELM [version 2.5 PL2]
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing


Laura, 

	Here is the editor for the Journal of Linux Technology (JOLT).
The magazine with an XFS article was released on Thursday last week.
They are Fedex'ing 4 copies to me. You might want to contact Meghan, meghan@oreilly.com,
to get more copies.

>Meghan Keeffe, Managing Editor
>O'Reilly & Associates, Inc.
>101 Morris St. Sebastopol, CA 95472
>ph 707.829.0515 fx 707.829.0104
>


FYI,

Jim


From owner-linux-xfs@oss.sgi.com Mon Apr 10 11:54:54 2000
Received:  by oss.sgi.com id <S305157AbQDJSyp>;
	Mon, 10 Apr 2000 11:54:45 -0700
Received: from rf-mail1.echostar.com ([205.172.144.40]:4882 "EHLO
        rf-exch2.echostar.com") by oss.sgi.com with ESMTP
	id <S305154AbQDJSy2>; Mon, 10 Apr 2000 11:54:28 -0700
Received: from echostar.com (linux10.echostar.com [172.20.50.110]) by rf-exch2.echostar.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21)
	id 2NM7NCF0; Mon, 10 Apr 2000 12:54:21 -0600
Message-ID: <38F2235C.2722C81A@echostar.com>
Date:   Mon, 10 Apr 2000 12:54:20 -0600
From:   "Ian S. Nelson" <ian.nelson@echostar.com>
Reply-To: ian.nelson@echostar.com
Organization: Echostar
X-Mailer: Mozilla 4.51 [en] (X11; I; Linux 2.2.5-15 i686)
X-Accept-Language: en
MIME-Version: 1.0
To:     "linux-xfs@oss.sgi.com" <linux-xfs@oss.sgi.com>
Subject: 2.4 Kernel integration plans?
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing

What are the plans for integration of XFS into the kernel.  Is this
something that has been discussed or is it on hold until XFS stablizes
some more?

I've been hammering on it and I'm very impressed with it so far.  I'm
going to ramp up my battery of abuse a little more to see how it hangs
but it's been doing well.


thanks,
Ian Nelson


From owner-linux-xfs@oss.sgi.com Mon Apr 10 12:14:54 2000
Received:  by oss.sgi.com id <S305157AbQDJTOp>;
	Mon, 10 Apr 2000 12:14:45 -0700
Received: from pneumatic-tube.sgi.com ([204.94.214.22]:27152 "EHLO
        pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP
	id <S305154AbQDJTO0>; Mon, 10 Apr 2000 12:14:26 -0700
Received: from ledzep.cray.com (ledzep.cray.com [137.38.226.97]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id MAA09305
	for <linux-xfs@oss.sgi.com>; Mon, 10 Apr 2000 12:18:17 -0700 (PDT)
	mail_from (mostek@sgi.com)
Received: from ironwood-e185.americas.sgi.com (ironwood.cray.com [128.162.185.212]) by ledzep.cray.com (SGI-SGI-8.9.3/craymail-smart-nospam1.0) with ESMTP id OAA60252; Mon, 10 Apr 2000 14:13:08 -0500 (CDT)
Received: from fsgi344.americas.sgi.com (fsgi344.americas.sgi.com [128.162.184.15]) by ironwood-e185.americas.sgi.com (8.8.4/SGI-ironwood-e1.4) with ESMTP id OAA14248; Mon, 10 Apr 2000 14:13:00 -0500 (CDT)
From:   Jim Mostek <mostek@sgi.com>
Received: by fsgi344.americas.sgi.com (980427.SGI.8.8.8/SGI-client.1.6) id OAA47810; Mon, 10 Apr 2000 14:13:06 -0500 (CDT)
Message-Id: <200004101913.OAA47810@fsgi344.americas.sgi.com>
Subject: Re: 2.4 Kernel integration plans?
To:     ian.nelson@echostar.com
Date:   Mon, 10 Apr 2000 14:13:06 -0500 (CDT)
Cc:     linux-xfs@oss.sgi.com (linux-xfs@oss.sgi.com)
In-Reply-To: <38F2235C.2722C81A@echostar.com> from "Ian S. Nelson" at Apr 10, 2000 12:54:20 PM
X-Mailer: ELM [version 2.5 PL2]
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing


XFS->Linux is still in development. We have some major code yet to do including:

	del alloc on write
	direct I/O (skip the page cache when reading/writing files)
	possibly eliminate some of the vnode/vfs or rework.
	performance work
	make XFS work on root
	etc.

See the whole list on http://oss.sgi.com/projects/xfs/todos.html.

Some of this work is XFS specific. Some of the work is outside the file
system, e.g. pagebuf.

At the same time, we have asked the JFS and ReiserFS people
to start looking at pagebuf which is a new file system independent
layer that enables some functionality:
	eliminates file system calls per page (to map pages to disk block)
	delay allocate (so we can put-off allocation or skip completely)
	...

This code is not yet done, but we are getting closer. It would be ideal
if other FS' help us move this along.

The steps to get XFS into the default kernel are:

	1.) Finish the initial XFS port (this summer)
	2.) Get pagebuf accepted
	3.) Get XFs accepted.

We are planning a beta XFS release this summer (northern hemisphere)

Jim


>
>What are the plans for integration of XFS into the kernel.  Is this
>something that has been discussed or is it on hold until XFS stablizes
>some more?
>
>I've been hammering on it and I'm very impressed with it so far.  I'm
>going to ramp up my battery of abuse a little more to see how it hangs
>but it's been doing well.
>
>
>thanks,
>Ian Nelson
>


From owner-linux-xfs@oss.sgi.com Mon Apr 10 19:22:29 2000
Received:  by oss.sgi.com id <S305154AbQDKCWU>;
	Mon, 10 Apr 2000 19:22:20 -0700
Received: from pneumatic-tube.sgi.com ([204.94.214.22]:16182 "EHLO
        pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP
	id <S305157AbQDKCWL>; Mon, 10 Apr 2000 19:22:11 -0700
Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via SMTP id TAA04302
	for <linux-xfs@oss.sgi.com>; Mon, 10 Apr 2000 19:25:55 -0700 (PDT)
	mail_from (dxm@snort.melbourne.sgi.com)
Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.55.149]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id MAA03371 for <@larry.melbourne.sgi.com:linux-xfs@oss.sgi.com>; Tue, 11 Apr 2000 12:20:45 +1000
Received: (from dxm@localhost) by snort.melbourne.sgi.com (980427.SGI.8.8.8/980728.SGI.AUTOCF) id MAA86195 for linux-xfs@oss.sgi.com; Tue, 11 Apr 2000 12:20:45 +1000 (EST)
Date:   Tue, 11 Apr 2000 12:20:45 +1000 (EST)
From:   dxm@snort.melbourne.sgi.com (Daniel Moore)
Message-Id: <200004110220.MAA86195@snort.melbourne.sgi.com>
To:     linux-xfs@oss.sgi.com
Subject: TAKE - architecture mods - dir2 btree
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing

finish up dir2 mods

   - convert btree headers, leaves
   - update xfs_db
   - fix xfs_db bugs

note: this will almost certainly break
MIPS attribute btrees - todo.

Modid:  2.3.99pre2-xfs:slinx:57465a
Date:  Mon Apr 10 19:19:21 PDT 2000
Workarea:  snort:/build1/people/dxm/isms/slinx-xfs

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

cmd/xfs/db/dir2.c - 1.6
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/cmd/xfs/db/dir2.c.diff?r1=text&tr1=1.6&r2=text&tr2=1.5&f=h
linux/fs/xfs/xfs_da_btree.c - 1.105
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/linux/fs/xfs/xfs_da_btree.c.diff?r1=text&tr1=1.105&r2=text&tr2=1.104&f=h
linux/fs/xfs/xfs_dir2_block.c - 1.10
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/linux/fs/xfs/xfs_dir2_block.c.diff?r1=text&tr1=1.10&r2=text&tr2=1.9&f=h
linux/fs/xfs/xfs_dir2_leaf.c - 1.11
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/linux/fs/xfs/xfs_dir2_leaf.c.diff?r1=text&tr1=1.11&r2=text&tr2=1.10&f=h
linux/fs/xfs/xfs_dir2_node.c - 1.11
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/linux/fs/xfs/xfs_dir2_node.c.diff?r1=text&tr1=1.11&r2=text&tr2=1.10&f=h
linux/fs/xfs/xfsidbg.c - 1.127
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/linux/fs/xfs/xfsidbg.c.diff?r1=text&tr1=1.127&r2=text&tr2=1.126&f=h

From owner-linux-xfs@oss.sgi.com Mon Apr 10 20:37:49 2000
Received:  by oss.sgi.com id <S305161AbQDKDhl>;
	Mon, 10 Apr 2000 20:37:41 -0700
Received: from ts002d37.mon-cn.concentric.net ([206.173.244.97]:49168 "EHLO
        moiraine.off.net") by oss.sgi.com with ESMTP id <S305157AbQDKDhY>;
	Mon, 10 Apr 2000 20:37:24 -0700
Received: (from phil@localhost)
	by moiraine.off.net (8.9.3/8.9.3) id AAA04037;
	Tue, 11 Apr 2000 00:12:38 -0400
Date:   Tue, 11 Apr 2000 00:12:38 -0400
From:   Phil Schwan <phil@linuxcare.com>
To:     Steve Lord <lord@sgi.com>
Cc:     linux-xfs@oss.sgi.com
Subject: Re: XFS as Root filesystem
Message-ID: <20000411001238.I611@linuxcare.com>
References: <sct@redhat.com> <200004061552.KAA20840@jen.americas.sgi.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 0.95.4us
In-Reply-To: <200004061552.KAA20840@jen.americas.sgi.com>; from Steve Lord on Thu, Apr 06, 2000 at 10:52:18AM -0500
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing

On Apr 06, Steve Lord wrote:
> XFS already has read only support - we just need to allow recovery in read only
> mode, and the Linux remount code in XFS seems broken, so getting from
> read only to read-write is broken I think.

Indeed, since we only print ``Hoser!'', I've been spending the last
couple of days trying to make remount work.

My first simple attack involved basically just flipping the
appropriate bits in the superblock and vfsp flags... this didn't
_entirely_ work (which didn't surprise me at all).  There was clearly
more to do, especially in the case where one remounts from read-write
to read-only ("touch /mnt/xfs/foo" would say "Read-only filesystem",
yet continue to make the file.  Eep.)

Since there were a few places in the VFSOPS_MOUNT code path that
differed if (flags & MS_REMOUNT), I gathered that I should really be
using that, like a regular mount.  This has triggered a bunch of bugs
that I'm slowing tracking down one-by-one, including the odd null
pointer dereference in the xfs_write_super code.

In somewhat-related news, I have a patch for doing recovery in
read-only mode that I will test tomorrow.  If it works on both
internal and external logs, I'll send it along for review.

-Phil

From owner-linux-xfs@oss.sgi.com Mon Apr 10 20:53:59 2000
Received:  by oss.sgi.com id <S305165AbQDKDxu>;
	Mon, 10 Apr 2000 20:53:50 -0700
Received: from deliverator.sgi.com ([204.94.214.10]:1656 "EHLO
        deliverator.sgi.com") by oss.sgi.com with ESMTP id <S305157AbQDKDx3>;
	Mon, 10 Apr 2000 20:53:29 -0700
Received: from ledzep.cray.com (ledzep.cray.com [137.38.226.97]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id UAA02926
	for <linux-xfs@oss.sgi.com>; Mon, 10 Apr 2000 20:48:46 -0700 (PDT)
	mail_from (mostek@sgi.com)
Received: from ironwood-e185.americas.sgi.com (ironwood.cray.com [128.162.185.212]) by ledzep.cray.com (SGI-SGI-8.9.3/craymail-smart-nospam1.0) with ESMTP id WAA12162; Mon, 10 Apr 2000 22:52:12 -0500 (CDT)
Received: from fsgi344.americas.sgi.com (fsgi344.americas.sgi.com [128.162.184.15]) by ironwood-e185.americas.sgi.com (8.8.4/SGI-ironwood-e1.4) with ESMTP id WAA00430; Mon, 10 Apr 2000 22:52:05 -0500 (CDT)
From:   Jim Mostek <mostek@sgi.com>
Received: by fsgi344.americas.sgi.com (980427.SGI.8.8.8/SGI-client.1.6) id WAA50137; Mon, 10 Apr 2000 22:52:10 -0500 (CDT)
Message-Id: <200004110352.WAA50137@fsgi344.americas.sgi.com>
Subject: a few bugs fixed, but ...
To:     lord@sgi.com, ananth@engr.sgi.com
Date:   Mon, 10 Apr 2000 22:52:10 -0500 (CDT)
Cc:     linux-xfs@oss.sgi.com
X-Mailer: ELM [version 2.5 PL2]
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing


I wanted to send a note that I have a few bug fixes coming
(so people can avoid working on the same stuff I've fixed).

I have a fix for the times updates not being correct on read/write.
We are basically overwriting the times in the Linux inode with older
times from the XFS inode in revalidate. The fix I have is to update
the xfs times at the start of write and at the end of read (just
like Linux generic*).

I have a few fixes (not fully tested) that eliminate a bunch
of file system corruption when multiple processes are hitting
the same file. ext2 dies pretty quickly running doio with multiple
threads. XFS is getting better, but there is still corruption.

The delay alloc code is getting closer, too. I have a locking fix.
Ananth has actually run with del alloc and conversion. But, there
is lots more to do.

I'll check in all these changes in the next couple of days.

FYI,

Jim

From owner-linux-xfs@oss.sgi.com Mon Apr 10 21:30:30 2000
Received:  by oss.sgi.com id <S305166AbQDKEaU>;
	Mon, 10 Apr 2000 21:30:20 -0700
Received: from deliverator.sgi.com ([204.94.214.10]:1660 "EHLO
        deliverator.sgi.com") by oss.sgi.com with ESMTP id <S305157AbQDKEaB>;
	Mon, 10 Apr 2000 21:30:01 -0700
Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via SMTP id VAA05063
	for <linux-xfs@oss.sgi.com>; Mon, 10 Apr 2000 21:25:16 -0700 (PDT)
	mail_from (ivanr@melbourne.sgi.com)
From:   ivanr@melbourne.sgi.com
Received: from omen.melbourne.sgi.com (omen.melbourne.sgi.com [134.14.55.139]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id OAA04070 for <@larry.melbourne.sgi.com:linux-xfs@oss.sgi.com>; Tue, 11 Apr 2000 14:27:26 +1000
Received: from localhost (ivanr@localhost) by omen.melbourne.sgi.com (980427.SGI.8.8.8/980728.SGI.AUTOCF) via ESMTP id OAA23118 for <linux-xfs@oss.sgi.com>; Tue, 11 Apr 2000 14:27:23 +1000 (EST)
Date:   Tue, 11 Apr 2000 14:27:23 +1000
To:     linux-xfs@oss.sgi.com
Subject: page_buf_locking module use count bug
Message-ID: <Pine.SGI.4.21.0004111420030.19097-100000@omen.melbourne.sgi.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing


For whoever knows about this code:

Got into a situation where the use count for the page_buf_locking
module was greater than zero, even though the xfs module had been
unloaded, and therefore I am unable to unload the module.  A quick
look around, found this:

xfs_super.c:
  void
  linvfs_release_inode(struct inode *inode)
  {
        if (inode) {
                pagebuf_lock_disable(inode);
                truncate_inode_pages(&inode->i_data, 0L);
                iput(inode);
        }
  }

however, pagebuf_lock_disable() in page_buf_locking.c can return with
-EBUSY without decrementing the use count.

The call to pagebuf_lock_disable() should probably be in a loop
checking the return value, but I wasn't sure whether this would be
safe...


Ivan

-- 
Ivan Rayner
ivanr@melbourne.sgi.com


From owner-linux-xfs@oss.sgi.com Mon Apr 10 23:43:32 2000
Received:  by oss.sgi.com id <S305167AbQDKGnV>;
	Mon, 10 Apr 2000 23:43:21 -0700
Received: from deliverator.sgi.com ([204.94.214.10]:18447 "EHLO
        deliverator.sgi.com") by oss.sgi.com with ESMTP id <S305157AbQDKGm7>;
	Mon, 10 Apr 2000 23:42:59 -0700
Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via SMTP id XAA12817
	for <linux-xfs@oss.sgi.com>; Mon, 10 Apr 2000 23:38:14 -0700 (PDT)
	mail_from (dxm@snort.melbourne.sgi.com)
Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.55.149]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id QAA04834 for <@larry.melbourne.sgi.com:linux-xfs@oss.sgi.com>; Tue, 11 Apr 2000 16:40:25 +1000
Received: (from dxm@localhost) by snort.melbourne.sgi.com (980427.SGI.8.8.8/980728.SGI.AUTOCF) id QAA60565 for linux-xfs@oss.sgi.com; Tue, 11 Apr 2000 16:40:24 +1000 (EST)
Date:   Tue, 11 Apr 2000 16:40:24 +1000 (EST)
From:   dxm@snort.melbourne.sgi.com (Daniel Moore)
Message-Id: <200004110640.QAA60565@snort.melbourne.sgi.com>
To:     linux-xfs@oss.sgi.com
Subject: TAKE - fix dir 1 SF
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing

fix dir 1 shortform. Problems were actually in 
xfs_arch.h. Nasty stuff.

MIPS dir 1 non-shortform broken -TODO

Modid:  2.3.99pre2-xfs:slinx:57468a
Date:  Mon Apr 10 23:39:10 PDT 2000
Workarea:  snort:/build1/people/dxm/isms/slinx-xfs

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

linux/fs/xfs/xfs_arch.h - 1.18
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/linux/fs/xfs/xfs_arch.h.diff?r1=text&tr1=1.18&r2=text&tr2=1.17&f=h
	- fix XFS_BIG_FILESYSTEMS checking
	  fix 32 bit inode handling
	  check endian defines
	  check XFS_BIG_FILESYSTEMS define

linux/fs/xfs/xfs_dir_leaf.h - 1.26
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/linux/fs/xfs/xfs_dir_leaf.h.diff?r1=text&tr1=1.26&r2=text&tr2=1.25&f=h
	- bracket reference


From owner-linux-xfs@oss.sgi.com Tue Apr 11 00:33:02 2000
Received:  by oss.sgi.com id <S305169AbQDKHcw>;
	Tue, 11 Apr 2000 00:32:52 -0700
Received: from deliverator.sgi.com ([204.94.214.10]:24340 "EHLO
        deliverator.sgi.com") by oss.sgi.com with ESMTP id <S305157AbQDKHc3>;
	Tue, 11 Apr 2000 00:32:29 -0700
Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via SMTP id AAA15602
	for <linux-xfs@oss.sgi.com>; Tue, 11 Apr 2000 00:27:45 -0700 (PDT)
	mail_from (dxm@snort.melbourne.sgi.com)
Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.55.149]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id RAA05129 for <@larry.melbourne.sgi.com:linux-xfs@oss.sgi.com>; Tue, 11 Apr 2000 17:31:10 +1000
Received: (from dxm@localhost) by snort.melbourne.sgi.com (980427.SGI.8.8.8/980728.SGI.AUTOCF) id RAA83423 for linux-xfs@oss.sgi.com; Tue, 11 Apr 2000 17:31:08 +1000 (EST)
Date:   Tue, 11 Apr 2000 17:31:08 +1000 (EST)
From:   dxm@snort.melbourne.sgi.com (Daniel Moore)
Message-Id: <200004110731.RAA83423@snort.melbourne.sgi.com>
To:     linux-xfs@oss.sgi.com
Subject: TAKE - fix endian checks
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing

fix broken build.

there are of course two different and conflicting
ways of determining machine endianness.

- sim is now unbroken
- xfsidbg is now broken
- other endian checks are probably broken

Modid:  2.3.99pre2-xfs:slinx:57470a
Date:  Tue Apr 11 00:29:09 PDT 2000
Workarea:  snort:/build1/people/dxm/isms/slinx-xfs

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

linux/fs/xfs/xfs_arch.h - 1.19
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/linux/fs/xfs/xfs_arch.h.diff?r1=text&tr1=1.19&r2=text&tr2=1.18&f=h

From owner-linux-xfs@oss.sgi.com Tue Apr 11 00:42:52 2000
Received:  by oss.sgi.com id <S305170AbQDKHmm>;
	Tue, 11 Apr 2000 00:42:42 -0700
Received: from pneumatic-tube.sgi.com ([204.94.214.22]:30021 "EHLO
        pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP
	id <S305157AbQDKHmY>; Tue, 11 Apr 2000 00:42:24 -0700
Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via SMTP id AAA03657
	for <linux-xfs@oss.sgi.com>; Tue, 11 Apr 2000 00:46:14 -0700 (PDT)
	mail_from (dxm@snort.melbourne.sgi.com)
Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.55.149]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id RAA05178 for <@larry.melbourne.sgi.com:linux-xfs@oss.sgi.com>; Tue, 11 Apr 2000 17:41:04 +1000
Received: (from dxm@localhost) by snort.melbourne.sgi.com (980427.SGI.8.8.8/980728.SGI.AUTOCF) id RAA08479 for linux-xfs@oss.sgi.com; Tue, 11 Apr 2000 17:41:04 +1000 (EST)
Date:   Tue, 11 Apr 2000 17:41:04 +1000 (EST)
From:   dxm@snort.melbourne.sgi.com (Daniel Moore)
Message-Id: <200004110741.RAA08479@snort.melbourne.sgi.com>
To:     linux-xfs@oss.sgi.com
Subject: TAKE - fix endian checks
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing

Modid:  2.3.99pre2-xfs:slinx:57471a
Date:  Tue Apr 11 00:40:35 PDT 2000
Workarea:  snort:/build1/people/dxm/isms/slinx-xfs

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

linux/fs/xfs/xfs_log.c - 1.210
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/linux/fs/xfs/xfs_log.c.diff?r1=text&tr1=1.210&r2=text&tr2=1.209&f=h
linux/fs/xfs/xfs_log.h - 1.45
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/linux/fs/xfs/xfs_log.h.diff?r1=text&tr1=1.45&r2=text&tr2=1.44&f=h
	- fix endian check


From owner-linux-xfs@oss.sgi.com Tue Apr 11 02:29:23 2000
Received:  by oss.sgi.com id <S305157AbQDKJ3N>;
	Tue, 11 Apr 2000 02:29:13 -0700
Received: from Cantor.suse.de ([194.112.123.193]:18702 "HELO Cantor.suse.de")
	by oss.sgi.com with SMTP id <S305154AbQDKJ3J>;
	Tue, 11 Apr 2000 02:29:09 -0700
Received: from Hermes.suse.de (Hermes.suse.de [194.112.123.136])
	by Cantor.suse.de (Postfix) with ESMTP
	id 93EF91E125; Tue, 11 Apr 2000 11:29:06 +0200 (MEST)
Received: from gruyere.muc.suse.de (gruyere.muc.suse.de [10.23.1.2])
	by Hermes.suse.de (Postfix) with ESMTP
	id 93E2010A026; Tue, 11 Apr 2000 11:28:50 +0200 (MEST)
Received: by gruyere.muc.suse.de (Postfix, from userid 14446)
	id CF00B2F36B; Tue, 11 Apr 2000 11:28:49 +0200 (MEST)
Date:   Tue, 11 Apr 2000 11:28:49 +0200
From:   "Andi Kleen" <ak@suse.de>
To:     Jim Mostek <mostek@sgi.com>
Cc:     linux-xfs@oss.sgi.com
Subject: Re: a few bugs fixed, but ...
Message-ID: <20000411112849.B24519@gruyere.muc.suse.de>
References: <200004110352.WAA50137@fsgi344.americas.sgi.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 1.0i
In-Reply-To: <200004110352.WAA50137@fsgi344.americas.sgi.com>; from mostek@sgi.com on Mon, Apr 10, 2000 at 10:52:10PM -0500
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing

On Mon, Apr 10, 2000 at 10:52:10PM -0500, Jim Mostek wrote:
> I have a few fixes (not fully tested) that eliminate a bunch
> of file system corruption when multiple processes are hitting
> the same file. ext2 dies pretty quickly running doio with multiple
> threads. XFS is getting better, but there is still corruption.

Could you expand a bit on the ext2 problems. Does it crash ? 

-Andi

From owner-linux-xfs@oss.sgi.com Tue Apr 11 06:48:00 2000
Received:  by oss.sgi.com id <S305157AbQDKNrv>;
	Tue, 11 Apr 2000 06:47:51 -0700
Received: from pneumatic-tube.sgi.com ([204.94.214.22]:20565 "EHLO
        pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP
	id <S305154AbQDKNrb>; Tue, 11 Apr 2000 06:47:31 -0700
Received: from ledzep.cray.com (ledzep.cray.com [137.38.226.97]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id GAA00449
	for <linux-xfs@oss.sgi.com>; Tue, 11 Apr 2000 06:51:23 -0700 (PDT)
	mail_from (lord@sgi.com)
Received: from ironwood-e185.americas.sgi.com (ironwood.cray.com [128.162.185.212]) by ledzep.cray.com (SGI-SGI-8.9.3/craymail-smart-nospam1.0) with ESMTP id IAA33623; Tue, 11 Apr 2000 08:46:13 -0500 (CDT)
Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.184.86]) by ironwood-e185.americas.sgi.com (8.8.4/SGI-ironwood-e1.4) with ESMTP id IAA18154; Tue, 11 Apr 2000 08:46:06 -0500 (CDT)
Received: from jen.americas.sgi.com by jen.americas.sgi.com (8.9.3/SGI-client.1.6) via ESMTP id IAA25793; Tue, 11 Apr 2000 08:45:03 -0500
Message-Id: <200004111345.IAA25793@jen.americas.sgi.com>
X-Mailer: exmh version 2.1.1 10/15/1999
To:     "Andi Kleen" <ak@suse.de>
cc:     Jim Mostek <mostek@sgi.com>, linux-xfs@oss.sgi.com
Subject: Re: a few bugs fixed, but ... 
In-Reply-To: Message from "Andi Kleen" <ak@suse.de> 
   of "Tue, 11 Apr 2000 11:28:49 +0200." <20000411112849.B24519@gruyere.muc.suse.de> 
Date:   Tue, 11 Apr 2000 08:44:57 -0500
From:   Steve Lord <lord@sgi.com>
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing

> On Mon, Apr 10, 2000 at 10:52:10PM -0500, Jim Mostek wrote:
> > I have a few fixes (not fully tested) that eliminate a bunch
> > of file system corruption when multiple processes are hitting
> > the same file. ext2 dies pretty quickly running doio with multiple
> > threads. XFS is getting better, but there is still corruption.
> 
> Could you expand a bit on the ext2 problems. Does it crash ? 
> 
> -Andi

doio is an internal SGI (originally Cray) test for verifying read/write
correctness. In this mode it has a 50 Mbyte file which four processes
are walking through doing non-overlapping, but sequential write operations
(via the write system call and via mmapped write).

What appears to happen usually is two threads are doing writes which are
next to each other in the file, the page which they share gets corrupted,
either the start of one write gets zeroed out, or the end of the other
write gets old data over the top of it.

The bug may perhaps be related to the handling of BH_New.

I think we should maybe look into getting doio out into the community.

Steve



From owner-linux-xfs@oss.sgi.com Tue Apr 11 07:56:43 2000
Received:  by oss.sgi.com id <S305161AbQDKO4d>;
	Tue, 11 Apr 2000 07:56:33 -0700
Received: from deliverator.sgi.com ([204.94.214.10]:40012 "EHLO
        deliverator.sgi.com") by oss.sgi.com with ESMTP id <S305154AbQDKO4N>;
	Tue, 11 Apr 2000 07:56:13 -0700
Received: from info.engr.sgi.com (info.engr.sgi.com [192.26.80.216]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id HAA14463; Tue, 11 Apr 2000 07:51:30 -0700 (PDT)
	mail_from (nobody@info.engr.sgi.com)
Received: (from nobody@localhost) by info.engr.sgi.com (980427.SGI.8.8.8/980728.SGI.AUTOCF) id HAA18774; Tue, 11 Apr 2000 07:56:10 -0700 (PDT)
Date:   Tue, 11 Apr 2000 07:56:10 -0700 (PDT)
Message-Id: <200004111456.HAA18774@info.engr.sgi.com>
X-Pv-Incident: 787669 
webPV:  sgigate.sgi.com 
webExec: webpvsubmit,PvProjectIncident 
Reply-To: sgi.bugs.xfs@fido.engr.sgi.com
From:   pv@fddi-odin.corp.sgi.com (mostek@sgi.com)
Subject: BUG 787669 - page_buf_locking could not be rmmod'ed
To:     ananth@cthulhu.engr.sgi.com
Cc:     linux-xfs@oss.sgi.com
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing

View Incident: http://co-op.engr.sgi.com/BugWorks/code/bwxquery.cgi?search=Search&wlong=1&view_type=Bug&wi=787669

Submitter : mostek                    Submitter Domain : sgi.com            
Assigned Engineer : ananth            Assigned Domain : engr                
Assigned Group : xfs-linux            Category : software                   
Customer Reported : F                 Priority : 2                          
Project : xfs-linux                   Status : open                         
Description :
Got into a situation where the use count for the page_buf_locking
module was greater than zero, even though the xfs module had been
unloaded, and therefore I am unable to unload the module.  A quick
look around, found this:

xfs_super.c:
  void
  linvfs_release_inode(struct inode *inode)
  {
        if (inode) {
                pagebuf_lock_disable(inode);
                truncate_inode_pages(&inode->i_data, 0L);
                iput(inode);
        }
  }

however, pagebuf_lock_disable() in page_buf_locking.c can return with
-EBUSY without decrementing the use count.

The call to pagebuf_lock_disable() should probably be in a loop
checking the return value, but I wasn't sure whether this would be
safe...


Ivan

-- 
Ivan Rayner
ivanr@melbourne.sgi.com

From owner-linux-xfs@oss.sgi.com Tue Apr 11 07:56:52 2000
Received:  by oss.sgi.com id <S305154AbQDKO4d>;
	Tue, 11 Apr 2000 07:56:33 -0700
Received: from timbuk-fddi.cray.com ([128.162.8.102]:4244 "EHLO
        timbuk.cray.com") by oss.sgi.com with ESMTP id <S305157AbQDKO4a>;
	Tue, 11 Apr 2000 07:56:30 -0700
Received: from clink.americas.sgi.com (clink.cray.com [128.162.84.70]) by timbuk.cray.com (8.8.8/CRI-gate-news-1.3) with ESMTP id JAA25215 for <linux-xfs@oss.sgi.com>; Tue, 11 Apr 2000 09:56:25 -0500 (CDT)
Received: (from lord@localhost) by clink.americas.sgi.com (980427.SGI.8.8.8/CRI-news-1.3) id JAA84737 for linux-xfs@oss.sgi.com; Tue, 11 Apr 2000 09:56:26 -0500 (CDT)
Date:   Tue, 11 Apr 2000 09:56:26 -0500 (CDT)
From:   Steve Lord <lord@sgi.com>
Message-Id: <200004111456.JAA84737@clink.americas.sgi.com>
To:     linux-xfs@oss.sgi.com
Subject: TAKE - fix xfsidbg build problems
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing

There are still wierd things going on with the definition of fsid_t,
but at least things build again now.

Modid:  2.3.99pre2-xfs:slinx:57476a
Date:  Tue Apr 11 07:55:29 PDT 2000
Workarea:  clink.americas.sgi.com:/data/clink/io/lord/xfs-linux

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

linux/fs/xfs/linux/xfs_linux.h - 1.22
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/linux/fs/xfs/linux/xfs_linux.h.diff?r1=text&tr1=1.22&r2=text&tr2=1.21&f=h
	- Remove unneeded kdb definitions - these were out of date anyway.

linux/fs/xfs/xfsidbg.c - 1.128
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/linux/fs/xfs/xfsidbg.c.diff?r1=text&tr1=1.128&r2=text&tr2=1.127&f=h
	- Fix build problems


From owner-linux-xfs@oss.sgi.com Tue Apr 11 07:59:53 2000
Received:  by oss.sgi.com id <S305157AbQDKO7d>;
	Tue, 11 Apr 2000 07:59:33 -0700
Received: from deliverator.sgi.com ([204.94.214.10]:18253 "EHLO
        deliverator.sgi.com") by oss.sgi.com with ESMTP id <S305154AbQDKO73>;
	Tue, 11 Apr 2000 07:59:29 -0700
Received: from ledzep.cray.com (ledzep.cray.com [137.38.226.97]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id HAA14822
	for <linux-xfs@oss.sgi.com>; Tue, 11 Apr 2000 07:54:45 -0700 (PDT)
	mail_from (mostek@sgi.com)
Received: from ironwood-e185.americas.sgi.com (ironwood.cray.com [128.162.185.212]) by ledzep.cray.com (SGI-SGI-8.9.3/craymail-smart-nospam1.0) with ESMTP id JAA43611; Tue, 11 Apr 2000 09:56:52 -0500 (CDT)
Received: from fsgi344.americas.sgi.com (fsgi344.americas.sgi.com [128.162.184.15]) by ironwood-e185.americas.sgi.com (8.8.4/SGI-ironwood-e1.4) with ESMTP id JAA22729; Tue, 11 Apr 2000 09:56:45 -0500 (CDT)
From:   Jim Mostek <mostek@sgi.com>
Received: by fsgi344.americas.sgi.com (980427.SGI.8.8.8/SGI-client.1.6) id JAA47942; Tue, 11 Apr 2000 09:56:51 -0500 (CDT)
Message-Id: <200004111456.JAA47942@fsgi344.americas.sgi.com>
Subject: Re: page_buf_locking module use count bug
To:     ivanr@melbourne.sgi.com
Date:   Tue, 11 Apr 2000 09:56:50 -0500 (CDT)
Cc:     linux-xfs@oss.sgi.com
In-Reply-To: <Pine.SGI.4.21.0004111420030.19097-100000@omen.melbourne.sgi.com> from "ivanr@melbourne.sgi.com" at Apr 11, 2000 02:27:23 PM
X-Mailer: ELM [version 2.5 PL2]
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing


I have opened PV 787669 for this and assigned it to Ananth.
If anyone else is interested, feel free to grab it.

Jim

>
>
>For whoever knows about this code:
>
>Got into a situation where the use count for the page_buf_locking
>module was greater than zero, even though the xfs module had been
>unloaded, and therefore I am unable to unload the module.  A quick
>look around, found this:
>
>xfs_super.c:
>  void
>  linvfs_release_inode(struct inode *inode)
>  {
>        if (inode) {
>                pagebuf_lock_disable(inode);
>                truncate_inode_pages(&inode->i_data, 0L);
>                iput(inode);
>        }
>  }
>
>however, pagebuf_lock_disable() in page_buf_locking.c can return with
>-EBUSY without decrementing the use count.
>
>The call to pagebuf_lock_disable() should probably be in a loop
>checking the return value, but I wasn't sure whether this would be
>safe...
>
>
>Ivan
>
>-- 
>Ivan Rayner
>ivanr@melbourne.sgi.com
>


From owner-linux-xfs@oss.sgi.com Tue Apr 11 08:01:23 2000
Received:  by oss.sgi.com id <S305165AbQDKPBH>;
	Tue, 11 Apr 2000 08:01:07 -0700
Received: from pneumatic-tube.sgi.com ([204.94.214.22]:40794 "EHLO
        pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP
	id <S305154AbQDKPBB>; Tue, 11 Apr 2000 08:01:01 -0700
Received: from info.engr.sgi.com (info.engr.sgi.com [192.26.80.216]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id IAA07738; Tue, 11 Apr 2000 08:04:53 -0700 (PDT)
	mail_from (nobody@info.engr.sgi.com)
Received: (from nobody@localhost) by info.engr.sgi.com (980427.SGI.8.8.8/980728.SGI.AUTOCF) id IAA57215; Tue, 11 Apr 2000 08:00:57 -0700 (PDT)
Date:   Tue, 11 Apr 2000 08:00:57 -0700 (PDT)
Message-Id: <200004111500.IAA57215@info.engr.sgi.com>
X-Pv-Incident: 787669 
webPV:  jen.cray.com 
webExec: webpvupdate,pvincident 
Reply-To: sgi.bugs.xfs@fido.engr.sgi.com
From:   pv@fddi-odin.corp.sgi.com (lord@sgi.com)
Subject: ADD 787669 - page_buf_locking could not be rmmod'ed
To:     ananth@cthulhu.engr.sgi.com
Cc:     linux-xfs@oss.sgi.com
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing

View Incident: http://co-op.engr.sgi.com/BugWorks/code/bwxquery.cgi?search=Search&wlong=1&view_type=Bug&wi=787669

 Status : open                         Priority : 2                         
 Assigned Engineer : ananth            Submitter : mostek                   
*Modified User : lord                 *Modified User Domain : sgi.com       
*Description :
Got into a situation where the use count for the page_buf_locking
module was greater than zero, even though the xfs module had been
unloaded, and therefore I am unable to unload the module.  A quick
look around, found this:

xfs_super.c:
  void
  linvfs_release_inode(struct inode *inode)
  {
        if (inode) {

.....


==========================
ADDITIONAL INFORMATION (ADD)
From: lord@sgi.com (BugWorks)
Date: Apr 11 2000 08:00:57AM
==========================

I think this is actually a side effect of BUG 787427 where there
are page_bufs left around after unmount. This is the reason for
the EBUSY - and any form of looping is not going to fix it, we
need to get the buffers out of memory duing unmount.

From owner-linux-xfs@oss.sgi.com Tue Apr 11 08:42:54 2000
Received:  by oss.sgi.com id <S305157AbQDKPmo>;
	Tue, 11 Apr 2000 08:42:44 -0700
Received: from deliverator.sgi.com ([204.94.214.10]:37210 "EHLO
        deliverator.sgi.com") by oss.sgi.com with ESMTP id <S305154AbQDKPm2>;
	Tue, 11 Apr 2000 08:42:28 -0700
Received: from info.engr.sgi.com (info.engr.sgi.com [192.26.80.216]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id IAA19786; Tue, 11 Apr 2000 08:37:45 -0700 (PDT)
	mail_from (nobody@info.engr.sgi.com)
Received: (from nobody@localhost) by info.engr.sgi.com (980427.SGI.8.8.8/980728.SGI.AUTOCF) id IAA01327; Tue, 11 Apr 2000 08:42:24 -0700 (PDT)
Date:   Tue, 11 Apr 2000 08:42:24 -0700 (PDT)
Message-Id: <200004111542.IAA01327@info.engr.sgi.com>
X-Pv-Incident: 787427 
webPV:  sgigate.sgi.com 
webExec: webpvupdate,pvincident 
Reply-To: sgi.bugs.xfs@fido.engr.sgi.com
From:   pv@fddi-odin.corp.sgi.com (mostek@sgi.com)
Subject: REASSIGN 787427 - file system corrupts with page buf meta data on after unmount/mount
To:     lord@sgi.com
Cc:     linux-xfs@oss.sgi.com
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing

View Incident: http://co-op.engr.sgi.com/BugWorks/code/bwxquery.cgi?search=Search&wlong=1&view_type=Bug&wi=787427

 Status : open                         Priority : 1                         
*Assigned Engineer : lord             *Assigned Domain : sgi.com            
 Submitter : mostek                    Project : xfs-linux                  
 Assigned Group : xfs-linux            Opened Date : 04/07/00               
*Modified User : mostek               *Modified User Domain : sgi.com       
*Description :
I did a complete kernel build with page buf meta data on.
Then, I did unmount and mount and when trying to use
that file system again, it was corrupt. Here is the output from
xfs_repair -n:

[root@carlos /root]# xfs_repair -n /dev/hda1
Phase 1 - find and verify superblock...
Phase 2 - using internal log
        - scan filesystem freespace and inode maps...
would zero unused portion of secondary superblock 0 sector

.....


==========================
ADDITIONAL INFORMATION (REASSIGN)
From: mostek@sgi.com (BugWorks)
Date: Apr 11 2000 08:42:24AM
==========================

Steve wants this one.

From owner-linux-xfs@oss.sgi.com Tue Apr 11 11:24:14 2000
Received:  by oss.sgi.com id <S305161AbQDKSYF>;
	Tue, 11 Apr 2000 11:24:05 -0700
Received: from vader.inow.com ([207.5.52.10]:37127 "EHLO vader.inow.com")
	by oss.sgi.com with ESMTP id <S305154AbQDKSXx>;
	Tue, 11 Apr 2000 11:23:53 -0700
Received: from opensourcegroup.com (56.pool03.iqci.net [207.168.169.56])
	by vader.inow.com (8.9.3/8.9.3) with ESMTP id LAA03250
	for <linux-xfs@oss.sgi.com>; Tue, 11 Apr 2000 11:23:52 -0700
Message-ID: <38F36DC2.29E6EAF7@opensourcegroup.com>
Date:   Tue, 11 Apr 2000 11:24:02 -0700
From:   Rob Aagaard <rob@opensourcegroup.com>
Organization: Open Source Group
X-Mailer: Mozilla 4.72 [en] (X11; U; Linux 2.3.99-pre2 i686)
X-Accept-Language: en
MIME-Version: 1.0
To:     linux-xfs@oss.sgi.com
Subject: Two questions.
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing

First off, is it possible for anyone outside of SGI to get write access
to the CVS tree? (I'm not suggesting that I be given write access to the
CVS tree, I know just enough about the kernel to really break stuff
fast.)

Secondly, how much i386 specific code is in XFS, I'm very interested in
getting it ported to Alpha/PPC (the two alternative archs I have at
home) and am wondering when would be an appropriate time to begin
porting.


But the main reason I sent this message is to thank all of you down at
SGI, I am looking forward to having XFS on Linux, and I have it
currently in my system, and a 7G partiton dedicated to it. It made it
all the way through a kernel compile, but locked up my rm process when I
was nuking the kernel source. I am however, pleasantly supprised that
this thing compiles consistantly, and was amazed when it actually worked
(mostly). Thank you again for all of your efforts, and to a job well
done.

	- Rob Aagaard

From owner-linux-xfs@oss.sgi.com Tue Apr 11 11:32:04 2000
Received:  by oss.sgi.com id <S305161AbQDKSbp>;
	Tue, 11 Apr 2000 11:31:45 -0700
Received: from timbuk-fddi.cray.com ([128.162.8.102]:63137 "EHLO
        timbuk.cray.com") by oss.sgi.com with ESMTP id <S305154AbQDKSbk>;
	Tue, 11 Apr 2000 11:31:40 -0700
Received: from clink.americas.sgi.com (clink.cray.com [128.162.84.70]) by timbuk.cray.com (8.8.8/CRI-gate-news-1.3) with ESMTP id NAA00525 for <linux-xfs@oss.sgi.com>; Tue, 11 Apr 2000 13:31:36 -0500 (CDT)
Received: (from mostek@localhost) by clink.americas.sgi.com (980427.SGI.8.8.8/CRI-news-1.3) id NAA60674 for linux-xfs@oss.sgi.com; Tue, 11 Apr 2000 13:31:38 -0500 (CDT)
Date:   Tue, 11 Apr 2000 13:31:38 -0500 (CDT)
From:   Jim Mostek <mostek@sgi.com>
Message-Id: <200004111831.NAA60674@clink.americas.sgi.com>
To:     linux-xfs@oss.sgi.com
Subject: TAKE - remove debug() from xfs_error.c (so xfs.o can load as module again)
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing

Modid:  2.3.99pre2-xfs:slinx:57492a
Date:  Tue Apr 11 11:31:05 PDT 2000
Workarea:  clink.americas.sgi.com:/data/clink/io/mostek/slinx-xfs

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

linux/fs/xfs/xfs_error.c - 1.26
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/linux/fs/xfs/xfs_error.c.diff?r1=text&tr1=1.26&r2=text&tr2=1.25&f=h
	- Change debug() to BUG() for Linux since debug() was recently removed.
	  This now allows xfs.o to load as a module.


From owner-linux-xfs@oss.sgi.com Tue Apr 11 11:37:45 2000
Received:  by oss.sgi.com id <S305165AbQDKShf>;
	Tue, 11 Apr 2000 11:37:35 -0700
Received: from rf-mail1.echostar.com ([205.172.144.40]:61970 "EHLO
        rf-exch2.echostar.com") by oss.sgi.com with ESMTP
	id <S305154AbQDKShR>; Tue, 11 Apr 2000 11:37:17 -0700
Received: from echostar.com (linux10.echostar.com [172.20.50.110]) by rf-exch2.echostar.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21)
	id 2NM7N531; Tue, 11 Apr 2000 12:37:11 -0600
Message-ID: <38F370DE.6B35A30@echostar.com>
Date:   Tue, 11 Apr 2000 12:37:18 -0600
From:   "Ian S. Nelson" <ian.nelson@echostar.com>
Reply-To: ian.nelson@echostar.com
Organization: Echostar
X-Mailer: Mozilla 4.51 [en] (X11; I; Linux 2.2.5-15 i686)
X-Accept-Language: en
MIME-Version: 1.0
To:     "linux-xfs@oss.sgi.com" <linux-xfs@oss.sgi.com>
Subject: Bug submission?
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing

How do I submit bugs?

I've been hammering on XFS and it works great until I export it and
start hammering on it over NFS. It pretty regularly causes a kernel
panic or some distortion of data.   Files aren't read properly, can't
remove directories, things like that.  I suspect this may not be a
"supported configuration"  yet but I was doing concurrent kernel
compiles to stress it out and I wanted to do a few more, only CPU cycles
were starting to be the limiting factor (thus NFS and another CPU seemed
to make sense)  It seems like something is getting confused, perhaps NFS
takes a short cut through the VFS layer that XFS doesn't know about or
something like that.

pagebuf_get(..) is where the panic occurs, "kernel can't handle
NULL pointer exception"

I looked at the pagebuf_get source and the first thing that jumped out
to me was that the comment says ip can can be NULL but it's never
checked to see if it's NULL, it's just dereferenced.  So that kind of
looks like a bug,  I'm not familiar enough with the code to tell what
the proper fix is though.   Just returning probably isn't the best
solution.
I put some printk statments  (if (ip==NULL) printk(...); ) in to try and
pin down where it was but they never wrote anything out, it just drops
into kdb.


Ian Nelson
ian.nelson@echostar.com


From owner-linux-xfs@oss.sgi.com Tue Apr 11 11:40:24 2000
Received:  by oss.sgi.com id <S305166AbQDKSkP>;
	Tue, 11 Apr 2000 11:40:15 -0700
Received: from pneumatic-tube.sgi.com ([204.94.214.22]:29561 "EHLO
        pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP
	id <S305154AbQDKSkC>; Tue, 11 Apr 2000 11:40:02 -0700
Received: from ledzep.cray.com (ledzep.cray.com [137.38.226.97]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id LAA09345
	for <linux-xfs@oss.sgi.com>; Tue, 11 Apr 2000 11:43:16 -0700 (PDT)
	mail_from (cattelan@thebarn.com)
From:   cattelan@thebarn.com
Received: from ironwood-e185.americas.sgi.com (ironwood.cray.com [128.162.185.212]) by ledzep.cray.com (SGI-SGI-8.9.3/craymail-smart-nospam1.0) with ESMTP id NAA85921; Tue, 11 Apr 2000 13:38:06 -0500 (CDT)
Received: from gibble.americas.sgi.com (root@gibble.americas.sgi.com [128.162.195.80]) by ironwood-e185.americas.sgi.com (8.8.4/SGI-ironwood-e1.4) with ESMTP id NAA04822; Tue, 11 Apr 2000 13:38:00 -0500 (CDT)
Received: from gibble.americas.sgi.com by gibble.americas.sgi.com (8.9.3/SGI-client.1.6) via ESMTP id NAA26970; Tue, 11 Apr 2000 13:38:06 -0500
Date:   Tue, 11 Apr 2000 13:38:03 -0500
Message-ID: <14579.28939.436209.15438P@gibble.americas.sgi.com>
To:     rob@opensourcegroup.com
Cc:     linux-xfs@oss.sgi.com
Subject: Re: Two questions.
In-Reply-To: In your message of "Tue, 11 Apr 2000 11:24:02 -0700"
	<38F36DC2.29E6EAF7@opensourcegroup.com>
References: <38F36DC2.29E6EAF7@opensourcegroup.com>
User-Agent: Wanderlust/1.0.3 (Notorious) tm/7.108 XEmacs/21.1 (Bryce Canyon)
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing

At Tue, 11 Apr 2000 11:24:02 -0700,
Rob Aagaard <rob@opensourcegroup.com> wrote:
> 
> 
> First off, is it possible for anyone outside of SGI to get write access
> to the CVS tree? (I'm not suggesting that I be given write access to the
> CVS tree, I know just enough about the kernel to really break stuff
> fast.)
For the moment source code control is being done via SGI internal
tools. (p tools) The cvs tree is a copy of the internal rcs files from
the p_tools tree. So to answer your question: nobody has write
access to the tree, not even internally.

> 
> Secondly, how much i386 specific code is in XFS, I'm very interested in
> getting it ported to Alpha/PPC (the two alternative archs I have at
> home) and am wondering when would be an appropriate time to begin
> porting.

Most of your problems are going to arise from differences in types.
specifically unsigned long  and __kernel_addr_t 
there are bound to be others.


Dave Miller already managed to get the kernel side compiled on
an Ultra sparc, most of those changes should map to an alpha.


> 
> 
> But the main reason I sent this message is to thank all of you down at
> SGI, I am looking forward to having XFS on Linux, and I have it
> currently in my system, and a 7G partiton dedicated to it. It made it
> all the way through a kernel compile, but locked up my rm process when I
> was nuking the kernel source.i
Yup... we are looking into that one right now.

 I am however, pleasantly supprised that
> this thing compiles consistantly, and was amazed when it actually worked
> (mostly). Thank you again for all of your efforts, and to a job well
> done.
> 
> 	- Rob Aagaard

From owner-linux-xfs@oss.sgi.com Tue Apr 11 12:00:24 2000
Received:  by oss.sgi.com id <S305161AbQDKTAP>;
	Tue, 11 Apr 2000 12:00:15 -0700
Received: from pneumatic-tube.sgi.com ([204.94.214.22]:42108 "EHLO
        pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP
	id <S305154AbQDKS77>; Tue, 11 Apr 2000 11:59:59 -0700
Received: from ledzep.cray.com (ledzep.cray.com [137.38.226.97]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id MAA06828
	for <linux-xfs@oss.sgi.com>; Tue, 11 Apr 2000 12:03:13 -0700 (PDT)
	mail_from (cattelan@thebarn.com)
From:   cattelan@thebarn.com
Received: from ironwood-e185.americas.sgi.com (ironwood.cray.com [128.162.185.212]) by ledzep.cray.com (SGI-SGI-8.9.3/craymail-smart-nospam1.0) with ESMTP id NAA39501; Tue, 11 Apr 2000 13:58:03 -0500 (CDT)
Received: from gibble.americas.sgi.com (root@gibble.americas.sgi.com [128.162.195.80]) by ironwood-e185.americas.sgi.com (8.8.4/SGI-ironwood-e1.4) with ESMTP id NAA06446; Tue, 11 Apr 2000 13:57:56 -0500 (CDT)
Received: from gibble.americas.sgi.com by gibble.americas.sgi.com (8.9.3/SGI-client.1.6) via ESMTP id NAA26990; Tue, 11 Apr 2000 13:58:02 -0500
Date:   Tue, 11 Apr 2000 13:58:01 -0500
Message-ID: <14579.30137.543740.87172K@gibble.americas.sgi.com>
To:     ian.nelson@echostar.com
Cc:     linux-xfs@oss.sgi.com
Subject: Re: Bug submission?
In-Reply-To: In your message of "Tue, 11 Apr 2000 12:37:18 -0600"
	<38F370DE.6B35A30@echostar.com>
References: <38F370DE.6B35A30@echostar.com>
User-Agent: Wanderlust/1.0.3 (Notorious) tm/7.108 XEmacs/21.1 (Bryce Canyon)
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing

At Tue, 11 Apr 2000 12:37:18 -0600,
Ian S. Nelson <ian.nelson@echostar.com> wrote:
> 
> 
> How do I submit bugs?
just send it to the list at the moment.

> I've been hammering on XFS and it works great until I export it and
> start hammering on it over NFS. It pretty regularly causes a kernel
> panic or some distortion of data.   Files aren't read properly, can't
> remove directories, things like that.  I suspect this may not be a
> "supported configuration"  yet but I was doing concurrent kernel
> compiles to stress it out and I wanted to do a few more, only CPU cycles
> were starting to be the limiting factor (thus NFS and another CPU seemed
> to make sense)  It seems like something is getting confused, perhaps NFS
> takes a short cut through the VFS layer that XFS doesn't know about or
> something like that.
> 
> pagebuf_get(..) is where the panic occurs, "kernel can't handle
> NULL pointer exception"
> 
> I looked at the pagebuf_get source and the first thing that jumped out
> to me was that the comment says ip can can be NULL but it's never
> checked to see if it's NULL, it's just dereferenced.  So that kind of
> looks like a bug,  I'm not familiar enough with the code to tell what
> the proper fix is though.   Just returning probably isn't the best
> solution.
> I put some printk statments  (if (ip==NULL) printk(...); ) in to try and
> pin down where it was but they never wrote anything out, it just drops
> into kdb.
> 
Send the back trace.
I'm probably chasing the same bug right now.

Where was this comment about ip possibly being null.




From owner-linux-xfs@oss.sgi.com Tue Apr 11 12:21:24 2000
Received:  by oss.sgi.com id <S305161AbQDKTVP>;
	Tue, 11 Apr 2000 12:21:15 -0700
Received: from rf-mail1.echostar.com ([205.172.144.40]:17681 "EHLO
        rf-exch2.echostar.com") by oss.sgi.com with ESMTP
	id <S305154AbQDKTU6>; Tue, 11 Apr 2000 12:20:58 -0700
Received: from echostar.com (linux10.echostar.com [172.20.50.110]) by rf-exch2.echostar.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21)
	id 2NM7N6XN; Tue, 11 Apr 2000 13:20:52 -0600
Message-ID: <38F37B1B.90646CEB@echostar.com>
Date:   Tue, 11 Apr 2000 13:20:59 -0600
From:   "Ian S. Nelson" <ian.nelson@echostar.com>
Reply-To: ian.nelson@echostar.com
Organization: Echostar
X-Mailer: Mozilla 4.51 [en] (X11; I; Linux 2.2.5-15 i686)
X-Accept-Language: en
MIME-Version: 1.0
To:     "linux-xfs@oss.sgi.com" <linux-xfs@oss.sgi.com>
Subject: Re: Bug submission?
References: <38F370DE.6B35A30@echostar.com> <14579.30137.543740.87172K@gibble.americas.sgi.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing

cattelan@thebarn.com wrote:

> At Tue, 11 Apr 2000 12:37:18 -0600,
> Ian S. Nelson <ian.nelson@echostar.com> wrote:
> >
> >
> > How do I submit bugs?
> just send it to the list at the moment.
>
> > I've been hammering on XFS and it works great until I export it and
> > start hammering on it over NFS. It pretty regularly causes a kernel
> > panic or some distortion of data.   Files aren't read properly, can't
> > remove directories, things like that.  I suspect this may not be a
> > "supported configuration"  yet but I was doing concurrent kernel
> > compiles to stress it out and I wanted to do a few more, only CPU cycles
> > were starting to be the limiting factor (thus NFS and another CPU seemed
> > to make sense)  It seems like something is getting confused, perhaps NFS
> > takes a short cut through the VFS layer that XFS doesn't know about or
> > something like that.
> >
> > pagebuf_get(..) is where the panic occurs, "kernel can't handle
> > NULL pointer exception"
> >
> > I looked at the pagebuf_get source and the first thing that jumped out
> > to me was that the comment says ip can can be NULL but it's never
> > checked to see if it's NULL, it's just dereferenced.  So that kind of
> > looks like a bug,  I'm not familiar enough with the code to tell what
> > the proper fix is though.   Just returning probably isn't the best
> > solution.
> > I put some printk statments  (if (ip==NULL) printk(...); ) in to try and
> > pin down where it was but they never wrote anything out, it just drops
> > into kdb.
> >
> Send the back trace.
> I'm probably chasing the same bug right now.
>
> Where was this comment about ip possibly being null.

Line 775 of fs/page_buf.c

I did an update this morning so it should be pretty close to the newest
code,
if not the newest.

page_buf_t *pagebuf_get( /* allocate a buffer            */
           struct inode * ip,  /* inode for buffer (or NULL)   */     
<----
That sounds like NULL is at least antisipated, if not an acceptable
argument.

[... here are the first few lines of the  function...]
{
 page_buf_registration_t *reg;
 int rval;
 page_buf_t *pb;

 /* Enforce alignment of pagebufs on sector boundaries */
 if ((ioff & (ip->i_sb->s_blocksize - 1))
||                                              
<-------------------this
should cause a kernel exception if NULL is passed in.
     (isize & (ip->i_sb->s_blocksize - 1))) {

  printk("Bad alignment of pagebuf offset %Ld size %d\n",
      ioff, isize);

  BUG();
      return
NULL;
<------------------- It looks like just bailing is Okay, so maybe we
just
need to check if ip is NULL also.
 }





I'll recreate the backtrace,   I don't have all the hex numbers from it
but
the function calls were
pagebuf_Get
xfs_zero_last_block
xfs_zero_eof
xfs_write
linvfs_write
nsfd_write

and that's all I recorded, it had another layer or two down to
"kernel_thread"  but I didn't think they were important since the NFS
code
and code outside it seem to work with other filesystems.

All I did to create it initially was untar a kernel onto an NFS mounted
XFS partition.  It would go about 1/3 of the way and die, I never
counted the
number of files but it looked pretty consistent.


Ian Nelson

From owner-linux-xfs@oss.sgi.com Tue Apr 11 12:31:05 2000
Received:  by oss.sgi.com id <S305165AbQDKTaz>;
	Tue, 11 Apr 2000 12:30:55 -0700
Received: from pneumatic-tube.sgi.com ([204.94.214.22]:35455 "EHLO
        pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP
	id <S305154AbQDKTah>; Tue, 11 Apr 2000 12:30:37 -0700
Received: from ledzep.cray.com (ledzep.cray.com [137.38.226.97]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id MAA08519
	for <linux-xfs@oss.sgi.com>; Tue, 11 Apr 2000 12:34:29 -0700 (PDT)
	mail_from (lord@sgi.com)
Received: from ironwood-e185.americas.sgi.com (ironwood.cray.com [128.162.185.212]) by ledzep.cray.com (SGI-SGI-8.9.3/craymail-smart-nospam1.0) with ESMTP id OAA57674; Tue, 11 Apr 2000 14:29:19 -0500 (CDT)
Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.184.86]) by ironwood-e185.americas.sgi.com (8.8.4/SGI-ironwood-e1.4) with ESMTP id OAA08594; Tue, 11 Apr 2000 14:29:12 -0500 (CDT)
Received: from jen.americas.sgi.com by jen.americas.sgi.com (8.9.3/SGI-client.1.6) via ESMTP id OAA31956; Tue, 11 Apr 2000 14:28:06 -0500
Message-Id: <200004111928.OAA31956@jen.americas.sgi.com>
X-Mailer: exmh version 2.1.1 10/15/1999
To:     ian.nelson@echostar.com
cc:     "linux-xfs@oss.sgi.com" <linux-xfs@oss.sgi.com>
Subject: Re: Bug submission? 
In-Reply-To: Message from "Ian S. Nelson" <ian.nelson@echostar.com> 
   of "Tue, 11 Apr 2000 13:20:59 MDT." <38F37B1B.90646CEB@echostar.com> 
Date:   Tue, 11 Apr 2000 14:28:06 -0500
From:   Steve Lord <lord@sgi.com>
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing



I think the bug here is going to be a long way away from this code - there
always should be an inode passed into pagebuf_get - the comment is wrong.
The inode here is coming from the vnode passed in, where it should also
always be set - I bet NFS is using a way into the filesystem to reference
an inode which XFS is not setting things up properly, that is where to look.


Steve

> 
> 
> 
> I'll recreate the backtrace,   I don't have all the hex numbers from it
> but
> the function calls were
> pagebuf_Get
> xfs_zero_last_block
> xfs_zero_eof
> xfs_write
> linvfs_write
> nsfd_write
> 
> and that's all I recorded, it had another layer or two down to
> "kernel_thread"  but I didn't think they were important since the NFS
> code
> and code outside it seem to work with other filesystems.
> 
> All I did to create it initially was untar a kernel onto an NFS mounted
> XFS partition.  It would go about 1/3 of the way and die, I never
> counted the
> number of files but it looked pretty consistent.
> 
> 
> Ian Nelson



From owner-linux-xfs@oss.sgi.com Tue Apr 11 12:55:55 2000
Received:  by oss.sgi.com id <S305166AbQDKTzq>;
	Tue, 11 Apr 2000 12:55:46 -0700
Received: from Cantor.suse.de ([194.112.123.193]:60433 "HELO Cantor.suse.de")
	by oss.sgi.com with SMTP id <S305167AbQDKTzU>;
	Tue, 11 Apr 2000 12:55:20 -0700
Received: from Hermes.suse.de (Hermes.suse.de [194.112.123.136])
	by Cantor.suse.de (Postfix) with ESMTP
	id 9769A1E1C2; Tue, 11 Apr 2000 21:55:18 +0200 (MEST)
Received: from gruyere.muc.suse.de (gruyere.muc.suse.de [10.23.1.2])
	by Hermes.suse.de (Postfix) with ESMTP
	id 5F70D10A026; Tue, 11 Apr 2000 21:54:54 +0200 (MEST)
Received: by gruyere.muc.suse.de (Postfix, from userid 14446)
	id 7FF312F36B; Tue, 11 Apr 2000 21:54:52 +0200 (MEST)
Date:   Tue, 11 Apr 2000 21:54:52 +0200
From:   "Andi Kleen" <ak@suse.de>
To:     Steve Lord <lord@sgi.com>
Cc:     ian.nelson@echostar.com,
        "linux-xfs@oss.sgi.com" <linux-xfs@oss.sgi.com>
Subject: Re: Bug submission?
Message-ID: <20000411215452.A706@gruyere.muc.suse.de>
References: <ian.nelson@echostar.com> <200004111928.OAA31956@jen.americas.sgi.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 1.0i
In-Reply-To: <200004111928.OAA31956@jen.americas.sgi.com>; from lord@sgi.com on Tue, Apr 11, 2000 at 02:28:06PM -0500
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing

On Tue, Apr 11, 2000 at 02:28:06PM -0500, Steve Lord wrote:
> 
> 
> I think the bug here is going to be a long way away from this code - there
> always should be an inode passed into pagebuf_get - the comment is wrong.
> The inode here is coming from the vnode passed in, where it should also
> always be set - I bet NFS is using a way into the filesystem to reference
> an inode which XFS is not setting things up properly, that is where to look.

fs/nfsfh/nfsfh.c does a lot of dirty things with the VFS, especially
with inodes.  Especially iget()/read_inode() must handle the case of
doing iget for an already deleted file.


-Andi


From owner-linux-xfs@oss.sgi.com Tue Apr 11 13:03:06 2000
Received:  by oss.sgi.com id <S305169AbQDKUCz>;
	Tue, 11 Apr 2000 13:02:55 -0700
Received: from timbuk-fddi.cray.com ([128.162.8.102]:63142 "EHLO
        timbuk.cray.com") by oss.sgi.com with ESMTP id <S305167AbQDKUCo>;
	Tue, 11 Apr 2000 13:02:44 -0700
Received: from clink.americas.sgi.com (clink.cray.com [128.162.84.70]) by timbuk.cray.com (8.8.8/CRI-gate-news-1.3) with ESMTP id PAA02677 for <linux-xfs@oss.sgi.com>; Tue, 11 Apr 2000 15:02:37 -0500 (CDT)
Received: (from mostek@localhost) by clink.americas.sgi.com (980427.SGI.8.8.8/CRI-news-1.3) id PAA72550 for linux-xfs@oss.sgi.com; Tue, 11 Apr 2000 15:02:38 -0500 (CDT)
Date:   Tue, 11 Apr 2000 15:02:38 -0500 (CDT)
From:   Jim Mostek <mostek@sgi.com>
Message-Id: <200004112002.PAA72550@clink.americas.sgi.com>
To:     linux-xfs@oss.sgi.com
Subject: TAKE 787178 - fix time updates, eliminate lots of corruptions.
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing

doio now runs on a fairly empty file system even up to 5 threads.
There are still problems here, but this take fixes several.

Time updates now appear correctly. There is a problem because
xfs "revalidates" by overwriting the Linux inode times with the
XFS inode times. But, the I/O path doesn't update the XFS inode
times. This take adds the setting of the XFS inode times in read/write
and mmap.

Modid:  2.3.99pre2-xfs:slinx:57499a
Date:  Tue Apr 11 13:00:14 PDT 2000
Workarea:  clink.americas.sgi.com:/data/clink/io/mostek/slinx-xfs

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

linux/fs/xfs/linux/xfs_file.c - 1.25
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/linux/fs/xfs/linux/xfs_file.c.diff?r1=text&tr1=1.25&r2=text&tr2=1.24&f=h
	- Add a new wrapper and update the atime when mmap'ing a file.
	  This should be removed if we ever stop using the xfs times
	  in revalidate.

linux/fs/xfs/linux/xfs_iops.c - 1.46
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/linux/fs/xfs/linux/xfs_iops.c.diff?r1=text&tr1=1.46&r2=text&tr2=1.45&f=h
	- Use lock_page instead of LockPage. UnlockPage does a wakeup
	  but LockPage doesn't check to see if set.

linux/fs/xfs/linux/xfs_lrw.c - 1.34
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/linux/fs/xfs/linux/xfs_lrw.c.diff?r1=text&tr1=1.34&r2=text&tr2=1.33&f=h
	- Update times at the start of write and at the end of read
	  since we overwrite the linux inode times in revalidate. If
	  we ever stop this, these calls to xfs_ichgtime should be deleted.
	  In the convert path, drop the lock unless we get into xfs_iomap_convert().
	  In the direct case, shring the allocation request to the size of a hole
	  if we find a hole. This eliminates the case where we incorrectly
	  mark PBMF_NEW when we convert a hole + allocated space into a larger
	  allocated space.

linux/kernel/ksyms.c - 1.38
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/linux/kernel/ksyms.c.diff?r1=text&tr1=1.38&r2=text&tr2=1.37&f=h
	- export lock_page for XFS so it can find it as a module.


From owner-linux-xfs@oss.sgi.com Tue Apr 11 13:17:55 2000
Received:  by oss.sgi.com id <S305170AbQDKURq>;
	Tue, 11 Apr 2000 13:17:46 -0700
Received: from deliverator.sgi.com ([204.94.214.10]:20524 "EHLO
        deliverator.sgi.com") by oss.sgi.com with ESMTP id <S305167AbQDKURd>;
	Tue, 11 Apr 2000 13:17:33 -0700
Received: from ledzep.cray.com (ledzep.cray.com [137.38.226.97]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id NAA26575
	for <linux-xfs@oss.sgi.com>; Tue, 11 Apr 2000 13:12:50 -0700 (PDT)
	mail_from (lord@sgi.com)
Received: from ironwood-e185.americas.sgi.com (ironwood.cray.com [128.162.185.212]) by ledzep.cray.com (SGI-SGI-8.9.3/craymail-smart-nospam1.0) with ESMTP id PAA71443; Tue, 11 Apr 2000 15:14:59 -0500 (CDT)
Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.184.86]) by ironwood-e185.americas.sgi.com (8.8.4/SGI-ironwood-e1.4) with ESMTP id PAA10713; Tue, 11 Apr 2000 15:14:52 -0500 (CDT)
Received: from jen.americas.sgi.com by jen.americas.sgi.com (8.9.3/SGI-client.1.6) via ESMTP id PAA32048; Tue, 11 Apr 2000 15:13:47 -0500
Message-Id: <200004112013.PAA32048@jen.americas.sgi.com>
X-Mailer: exmh version 2.1.1 10/15/1999
To:     "Andi Kleen" <ak@suse.de>
cc:     "linux-xfs@oss.sgi.com" <linux-xfs@oss.sgi.com>
Subject: Re: Bug submission? 
In-Reply-To: Message from "Andi Kleen" <ak@suse.de> 
   of "Tue, 11 Apr 2000 21:54:52 +0200." <20000411215452.A706@gruyere.muc.suse.de> 
Date:   Tue, 11 Apr 2000 15:13:46 -0500
From:   Steve Lord <lord@sgi.com>
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing


> fs/nfsfh/nfsfh.c does a lot of dirty things with the VFS, especially
> with inodes.  Especially iget()/read_inode() must handle the case of
> doing iget for an already deleted file.
> 
> 
> -Andi

You mean fs/nfsd/nfsfh.c of course,

Yes I think this will trip us up - our read_inode implementation needs work,
specifically xfs_get_vnode () needs to do an xfs_iget rather than assuming
the inode is already present in XFS'es internal hash table. Paying special
attention to the reference count code of course.... 

Steve




From owner-linux-xfs@oss.sgi.com Tue Apr 11 13:37:55 2000
Received:  by oss.sgi.com id <S305171AbQDKUhq>;
	Tue, 11 Apr 2000 13:37:46 -0700
Received: from rf-mail1.echostar.com ([205.172.144.40]:30987 "EHLO
        rf-exch2.echostar.com") by oss.sgi.com with ESMTP
	id <S305167AbQDKUhf>; Tue, 11 Apr 2000 13:37:35 -0700
Received: from echostar.com (linux10.echostar.com [172.20.50.110]) by rf-exch2.echostar.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21)
	id 2NM7N9GN; Tue, 11 Apr 2000 14:37:29 -0600
Message-ID: <38F38D10.8B026550@echostar.com>
Date:   Tue, 11 Apr 2000 14:37:36 -0600
From:   "Ian S. Nelson" <ian.nelson@echostar.com>
Reply-To: ian.nelson@echostar.com
Organization: Echostar
X-Mailer: Mozilla 4.51 [en] (X11; I; Linux 2.2.5-15 i686)
X-Accept-Language: en
MIME-Version: 1.0
To:     "linux-xfs@oss.sgi.com" <linux-xfs@oss.sgi.com>
Subject: Re: Bug submission?
References: <ian.nelson@echostar.com> <200004111928.OAA31956@jen.americas.sgi.com> <20000411215452.A706@gruyere.muc.suse.de>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing

Andi Kleen wrote:

> On Tue, Apr 11, 2000 at 02:28:06PM -0500, Steve Lord wrote:
> >
> >
> > I think the bug here is going to be a long way away from this code - there
> > always should be an inode passed into pagebuf_get - the comment is wrong.
> > The inode here is coming from the vnode passed in, where it should also
> > always be set - I bet NFS is using a way into the filesystem to reference
> > an inode which XFS is not setting things up properly, that is where to look.
>
> fs/nfsfh/nfsfh.c does a lot of dirty things with the VFS, especially
> with inodes.  Especially iget()/read_inode() must handle the case of
> doing iget for an already deleted file.
>
> -Andi

Figures, I never liked NFS anyways..  Maybe it will work better with coda.

I'll recreate the traceback here shortly and send it to the list.

Ian Nelson



From owner-linux-xfs@oss.sgi.com Wed Apr 12 00:33:50 2000
Received:  by oss.sgi.com id <S305166AbQDLHdl>;
	Wed, 12 Apr 2000 00:33:41 -0700
Received: from ribbit.CS.Berkeley.EDU ([128.32.131.152]:65497 "EHLO
        ribbit.CS.Berkeley.EDU") by oss.sgi.com with ESMTP
	id <S305161AbQDLHdc>; Wed, 12 Apr 2000 00:33:32 -0700
Received: from localhost (kmacy@localhost)
	by ribbit.CS.Berkeley.EDU (8.9.3/8.9.3) with ESMTP id AAA17672
	for <linux-xfs@oss.sgi.com>; Wed, 12 Apr 2000 00:33:38 -0700 (PDT)
X-Authentication-Warning: ribbit.CS.Berkeley.EDU: kmacy owned process doing -bs
Date:   Wed, 12 Apr 2000 00:33:38 -0700 (PDT)
From:   Kip Macy <kmacy@CS.Berkeley.EDU>
To:     linux-xfs@oss.sgi.com
Subject: files disappearing?
Message-ID: <Pine.SOL.4.10.10004120025170.17488-100000@ribbit.CS.Berkeley.EDU>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing

When I do a cvs checkout of the source tree in an ext2fs partition and cd to 
linux-2.3-xfs/linux 
> ls -lR | grep .c | wc
   5510   44454  337781
> ls -lR | grep .h | wc
  4114   34458  256249

When I do a cvs checkout of the source tree in an xfs partition and cd to
linux-2.3-xfs/linux
> ls -lR | grep .h | wc
not only do I get fewer files but I also get stuff like the following

ls: ./net/core/ Intel I810/I810 DC100/I810e sup: No such file or directory
ls: ./net/core/_I810
      bool '  VIA chipset support' CONFIG_AGP_VIA
      bool '  AMD Ironga: No such file or directory
ls: ./net/core/IG_AGP_AMD
      bool '  Generic SiS support' CONFIG_AGP_SIS
      boo: No such file or directory
ls: ./net/core/port' CONFIG_AGP_ALI
   fi
fi
endmenu
: No such file or directory









------------------------------------------------------------------------
Kip Macy                               kmacy@cs.berkeley.edu
University of California, Berkeley     
------------------------------------------------------------------------



From owner-linux-xfs@oss.sgi.com Wed Apr 12 04:02:22 2000
Received:  by oss.sgi.com id <S305167AbQDLLCC>;
	Wed, 12 Apr 2000 04:02:02 -0700
Received: from file.phys.tohoku.ac.jp ([130.34.117.125]:60925 "HELO
        file.phys.tohoku.ac.jp") by oss.sgi.com with SMTP
	id <S305161AbQDLLBg>; Wed, 12 Apr 2000 04:01:36 -0700
Received: (qmail 29305 invoked by uid 239); 12 Apr 2000 11:01:29 -0000
Message-ID: <20000412110129.29304.qmail@file.phys.tohoku.ac.jp>
Date:   Wed, 12 Apr 2000 20:01:29 +0900
From:   suzukis@file.phys.tohoku.ac.jp
To:     linux-xfs@oss.sgi.com
Cc:     kmacy@CS.Berkeley.EDU
In-reply-to: Kip Macy 's message of Wed, 12 Apr 2000 00:33:38 -0700 (PDT)<Pine.SOL.4.10.10004120025170.17488-100000@ribbit.CS.Berkeley.EDU>
Subject: Re: files disappearing?
Mime-Version: 1.0
Content-type: text/plain; charset=US-ASCII
X-Mailer: addmail [version 2.0.12]
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing

Dear Mr. Kip,

>When I do a cvs checkout of the source tree in an xfs partition and cd to
>linux-2.3-xfs/linux
>
>>ls -lR | grep .h | wc
>
>not only do I get fewer files but I also get stuff like the following
> 
>ls: ./net/core/ Intel I810/I810 DC100/I810e sup: No such file or directory

I've ever experienced similar trouble.
In my case, I downloaded GRUB (the greatest GNU boot loader)
source tree via CVS onto XFS partition.
Just after finishing checkout, the result of "ls -l" told as
if grub were a FILE, not a directory. After a minute, it became
a directory, but executing find told several inconsistency error
(similar to that you reported).

However, at present I could not repeat the trouble (still
I'm using same kernel), so still I wonder what caused the trouble.
486 (100MHz) is too slow to operate XFS? 64MB memory is too small?
The load average was too heavy? Yet I don't know....
If you could repeat the trouble, please let me know the specs
of your testing environment, and how to repeat the trouble -
if possible.

suzuki

From owner-linux-xfs@oss.sgi.com Wed Apr 12 07:13:16 2000
Received:  by oss.sgi.com id <S305166AbQDLOM4>;
	Wed, 12 Apr 2000 07:12:56 -0700
Received: from pneumatic-tube.sgi.com ([204.94.214.22]:8520 "EHLO
        pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP
	id <S305161AbQDLOMf>; Wed, 12 Apr 2000 07:12:35 -0700
Received: from ledzep.cray.com (ledzep.cray.com [137.38.226.97]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id HAA08067
	for <linux-xfs@oss.sgi.com>; Wed, 12 Apr 2000 07:16:28 -0700 (PDT)
	mail_from (lord@sgi.com)
Received: from ironwood-e185.americas.sgi.com (ironwood.cray.com [128.162.185.212]) by ledzep.cray.com (SGI-SGI-8.9.3/craymail-smart-nospam1.0) with ESMTP id JAA62424; Wed, 12 Apr 2000 09:11:17 -0500 (CDT)
Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.184.86]) by ironwood-e185.americas.sgi.com (8.8.4/SGI-ironwood-e1.4) with ESMTP id JAA10454; Wed, 12 Apr 2000 09:11:09 -0500 (CDT)
Received: from jen.americas.sgi.com by jen.americas.sgi.com (8.9.3/SGI-client.1.6) via ESMTP id JAA04768; Wed, 12 Apr 2000 09:11:15 -0500
Message-Id: <200004121411.JAA04768@jen.americas.sgi.com>
X-Mailer: exmh version 2.1.1 10/15/1999
To:     Kip Macy <kmacy@CS.Berkeley.EDU>
cc:     linux-xfs@oss.sgi.com
Subject: Re: files disappearing? 
In-Reply-To: Message from Kip Macy <kmacy@CS.Berkeley.EDU> 
   of "Wed, 12 Apr 2000 00:33:38 PDT." <Pine.SOL.4.10.10004120025170.17488-100000@ribbit.CS.Berkeley.EDU> 
Date:   Wed, 12 Apr 2000 09:11:15 -0500
From:   Steve Lord <lord@sgi.com>
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing

> When I do a cvs checkout of the source tree in an ext2fs partition and cd to 
> linux-2.3-xfs/linux 
> > ls -lR | grep .c | wc
>    5510   44454  337781
> > ls -lR | grep .h | wc
>   4114   34458  256249
> 
> When I do a cvs checkout of the source tree in an xfs partition and cd to
> linux-2.3-xfs/linux
> > ls -lR | grep .h | wc
> not only do I get fewer files but I also get stuff like the following
> 
> ls: ./net/core/ Intel I810/I810 DC100/I810e sup: No such file or directory
> ls: ./net/core/_I810
>       bool '  VIA chipset support' CONFIG_AGP_VIA
>       bool '  AMD Ironga: No such file or directory
> ls: ./net/core/IG_AGP_AMD
>       bool '  Generic SiS support' CONFIG_AGP_SIS
>       boo: No such file or directory
> ls: ./net/core/port' CONFIG_AGP_ALI
>    fi
> fi
> endmenu
> : No such file or directory
> 
> 
> 

There is a problem in the directory code and the way it interacts with the
glibc getdents code - glibc uses a different size dirent structure from that
returned by the kernel, which results in occasions when there are entries
returned by the kernel which will not fit in the user's buffer. In this case
glibc does an lseek backwards to reobtain these entries. The handling of
this lseek call appears to result in an entry getting skipped.

This should show up in directories with a fairly large number of entries
and an average name length of 12 or more characters (I think). 

While this sounds simple to fix it does not appear to be, the lseek offsets
returned by xfs are not real offsets, they attempt to represent a location
into a b+ tree of directory blocks. I have a simple workaround which seems
to make getdents work - but it may confuse other parts of the system.

Try making this change to linux/fs/xfs/xfs_dir2_leaf.c and see what happens:

*** /usr/tmp/TmpDir.3736-0/linux/fs/xfs/xfs_dir2_leaf.c_1.11    Wed Apr 12 
07:43:52 2000
--- linux/fs/xfs/xfs_dir2_leaf.c        Wed Apr 12 08:44:46 2000
***************
*** 1164,1170 ****
                dep = (xfs_dir2_data_entry_t *)ptr;
                p.namelen = dep->namelen;
                length = XFS_DIR2_DATA_ENTSIZE(p.namelen);
!               p.cook = XFS_DIR2_BYTE_TO_DATAPTR(mp, curoff + length);
  #if XFS_BIG_FILESYSTEMS
                p.ino = INT_GET(dep->inumber, ARCH_UNKNOWN) + mp->m_inoadd;
  #else
--- 1164,1170 ----
                dep = (xfs_dir2_data_entry_t *)ptr;
                p.namelen = dep->namelen;
                length = XFS_DIR2_DATA_ENTSIZE(p.namelen);
!               p.cook = XFS_DIR2_BYTE_TO_DATAPTR(mp, curoff);
  #if XFS_BIG_FILESYSTEMS
                p.ino = INT_GET(dep->inumber, ARCH_UNKNOWN) + mp->m_inoadd;
  #else


-----------------------------------

I should stress that this is an incorrect fix in that, according to the code,
it is making the d_off field in the getdents structure point at this entry
in the directory, not the next one as it should.

Hopefully we can come up with a correct fix soon.

Steve



From owner-linux-xfs@oss.sgi.com Wed Apr 12 09:18:36 2000
Received:  by oss.sgi.com id <S305162AbQDLQSR>;
	Wed, 12 Apr 2000 09:18:17 -0700
Received: from ribbit.CS.Berkeley.EDU ([128.32.131.152]:7142 "EHLO
        ribbit.CS.Berkeley.EDU") by oss.sgi.com with ESMTP
	id <S305161AbQDLQRs>; Wed, 12 Apr 2000 09:17:48 -0700
Received: from localhost (kmacy@localhost)
	by ribbit.CS.Berkeley.EDU (8.9.3/8.9.3) with ESMTP id JAA23402;
	Wed, 12 Apr 2000 09:17:45 -0700 (PDT)
X-Authentication-Warning: ribbit.CS.Berkeley.EDU: kmacy owned process doing -bs
Date:   Wed, 12 Apr 2000 09:17:45 -0700 (PDT)
From:   Kip Macy <kmacy@CS.Berkeley.EDU>
To:     Steve Lord <lord@sgi.com>
cc:     linux-xfs@oss.sgi.com
Subject: Re: files disappearing? 
In-Reply-To: <200004121411.JAA04768@jen.americas.sgi.com>
Message-ID: <Pine.SOL.4.10.10004120915240.23320-100000@ribbit.CS.Berkeley.EDU>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing

> This should show up in directories with a fairly large number of entries
> and an average name length of 12 or more characters (I think). 
> 
The only file that actually mattered for my build (as far as getting the
compile to run to completion) was linux/include/config/page/buf/meta.h. An ls
indicates that the only other file in that directory is locking.h.



From owner-linux-xfs@oss.sgi.com Wed Apr 12 09:22:36 2000
Received:  by oss.sgi.com id <S305169AbQDLQWR>;
	Wed, 12 Apr 2000 09:22:17 -0700
Received: from ribbit.CS.Berkeley.EDU ([128.32.131.152]:15334 "EHLO
        ribbit.CS.Berkeley.EDU") by oss.sgi.com with ESMTP
	id <S305161AbQDLQWN>; Wed, 12 Apr 2000 09:22:13 -0700
Received: from localhost (kmacy@localhost)
	by ribbit.CS.Berkeley.EDU (8.9.3/8.9.3) with ESMTP id JAA23422;
	Wed, 12 Apr 2000 09:22:15 -0700 (PDT)
X-Authentication-Warning: ribbit.CS.Berkeley.EDU: kmacy owned process doing -bs
Date:   Wed, 12 Apr 2000 09:22:15 -0700 (PDT)
From:   Kip Macy <kmacy@CS.Berkeley.EDU>
To:     suzukis@file.phys.tohoku.ac.jp
cc:     linux-xfs@oss.sgi.com
Subject: Re: files disappearing?
In-Reply-To: <20000412110129.29304.qmail@file.phys.tohoku.ac.jp>
Message-ID: <Pine.SOL.4.10.10004120918120.23320-100000@ribbit.CS.Berkeley.EDU>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing

> However, at present I could not repeat the trouble (still
> I'm using same kernel), so still I wonder what caused the trouble.
> 486 (100MHz) is too slow to operate XFS? 64MB memory is too small?
> The load average was too heavy? Yet I don't know....
> If you could repeat the trouble, please let me know the specs
> of your testing environment, and how to repeat the trouble -
> if possible.
> 
I am running on a PIII-500 with 256MB of RAM on an IBM SCSI drive.
The problem appears to be consistently reproducible.

					-Kip


From owner-linux-xfs@oss.sgi.com Wed Apr 12 10:58:57 2000
Received:  by oss.sgi.com id <S305170AbQDLR6i>;
	Wed, 12 Apr 2000 10:58:38 -0700
Received: from deliverator.sgi.com ([204.94.214.10]:52748 "EHLO
        deliverator.sgi.com") by oss.sgi.com with ESMTP id <S305163AbQDLR6d>;
	Wed, 12 Apr 2000 10:58:33 -0700
Received: from ledzep.cray.com (ledzep.cray.com [137.38.226.97]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id KAA13670
	for <linux-xfs@oss.sgi.com>; Wed, 12 Apr 2000 10:53:49 -0700 (PDT)
	mail_from (lord@sgi.com)
Received: from ironwood-e185.americas.sgi.com (ironwood.cray.com [128.162.185.212]) by ledzep.cray.com (SGI-SGI-8.9.3/craymail-smart-nospam1.0) with ESMTP id MAA61679; Wed, 12 Apr 2000 12:55:59 -0500 (CDT)
Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.184.86]) by ironwood-e185.americas.sgi.com (8.8.4/SGI-ironwood-e1.4) with ESMTP id MAA22798; Wed, 12 Apr 2000 12:55:51 -0500 (CDT)
Received: from jen.americas.sgi.com by jen.americas.sgi.com (8.9.3/SGI-client.1.6) via ESMTP id MAA05236; Wed, 12 Apr 2000 12:55:56 -0500
Message-Id: <200004121755.MAA05236@jen.americas.sgi.com>
X-Mailer: exmh version 2.1.1 10/15/1999
To:     Kip Macy <kmacy@CS.Berkeley.EDU>
cc:     Steve Lord <lord@sgi.com>, linux-xfs@oss.sgi.com
Subject: Re: files disappearing? 
In-Reply-To: Message from Kip Macy <kmacy@CS.Berkeley.EDU> 
   of "Wed, 12 Apr 2000 09:17:45 PDT." <Pine.SOL.4.10.10004120915240.23320-100000@ribbit.CS.Berkeley.EDU> 
Date:   Wed, 12 Apr 2000 12:55:56 -0500
From:   Steve Lord <lord@sgi.com>
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing

> > This should show up in directories with a fairly large number of entries
> > and an average name length of 12 or more characters (I think). 
> > 
> The only file that actually mattered for my build (as far as getting the
> compile to run to completion) was linux/include/config/page/buf/meta.h. An ls
> indicates that the only other file in that directory is locking.h.
> 

Do you mean the file was missing for real, or some command sequences
were not finding it? Did you try a make from scratch with the modified
code?

The creation of this file itself could be influenced by the directory bug (this
is speculation to a certain extent, I have not traced through the split include
code.

Unfortunately I am currently being dragged in other directions by management,
I have to go work on a different project for a while, so my XFS on Linux time
will be limited. Hopefully someone else can pick this one up soon.

Steve



From owner-linux-xfs@oss.sgi.com Wed Apr 12 13:13:28 2000
Received:  by oss.sgi.com id <S305172AbQDLUNS>;
	Wed, 12 Apr 2000 13:13:18 -0700
Received: from ribbit.CS.Berkeley.EDU ([128.32.131.152]:43503 "EHLO
        ribbit.CS.Berkeley.EDU") by oss.sgi.com with ESMTP
	id <S305171AbQDLUNL>; Wed, 12 Apr 2000 13:13:11 -0700
Received: from localhost (kmacy@localhost)
	by ribbit.CS.Berkeley.EDU (8.9.3/8.9.3) with ESMTP id NAA25470;
	Wed, 12 Apr 2000 13:13:11 -0700 (PDT)
X-Authentication-Warning: ribbit.CS.Berkeley.EDU: kmacy owned process doing -bs
Date:   Wed, 12 Apr 2000 13:13:10 -0700 (PDT)
From:   Kip Macy <kmacy@CS.Berkeley.EDU>
To:     Steve Lord <lord@sgi.com>
cc:     linux-xfs@oss.sgi.com
Subject: Re: files disappearing? 
In-Reply-To: <200004121755.MAA05236@jen.americas.sgi.com>
Message-ID: <Pine.SOL.4.10.10004121308300.25353-100000@ribbit.CS.Berkeley.EDU>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing



------------------------------------------------------------------------
On Wed, 12 Apr 2000, Steve Lord wrote:

> > > This should show up in directories with a fairly large number of entries
> > > and an average name length of 12 or more characters (I think). 
> > > 
> > The only file that actually mattered for my build (as far as getting the
> > compile to run to completion) was linux/include/config/page/buf/meta.h. An ls
> > indicates that the only other file in that directory is locking.h.
> > 
> 
> Do you mean the file was missing for real - 
The file was missing for real. When I went to the directory it was not there.
I discovered its absence because make was failing - I got the build to complete
by copying it from my other source tree.
> Did you try a make from scratch with the modified code?
Yes, after copying the file as mentioned above.
 
> The creation of this file itself could be influenced by the directory bug (this
> is speculation to a certain extent, I have not traced through the split include
> code.
> 
> Unfortunately I am currently being dragged in other directions by management,
> I have to go work on a different project for a while, so my XFS on Linux time
> will be limited. Hopefully someone else can pick this one up soon.
> 
> Steve
> 
> 
Such is the way of things.

I would follow through myself, but I don't feel that comfortable with the code.


			-Kip



From owner-linux-xfs@oss.sgi.com Wed Apr 12 16:19:42 2000
Received:  by oss.sgi.com id <S305155AbQDLXTc>;
	Wed, 12 Apr 2000 16:19:32 -0700
Received: from pneumatic-tube.sgi.com ([204.94.214.22]:21768 "EHLO
        pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP
	id <S305161AbQDLXTM>; Wed, 12 Apr 2000 16:19:12 -0700
Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via SMTP id QAA09576
	for <linux-xfs@oss.sgi.com>; Wed, 12 Apr 2000 16:23:04 -0700 (PDT)
	mail_from (dxm@clouds.melbourne.sgi.com)
Received: from clouds.melbourne.sgi.com (clouds.melbourne.sgi.com [134.14.55.166]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id JAA18521; Thu, 13 Apr 2000 09:17:50 +1000
Received: from localhost (dxm@localhost) by clouds.melbourne.sgi.com (980427.SGI.8.8.8/980728.SGI.AUTOCF) via SMTP id JAA64410; Thu, 13 Apr 2000 09:17:48 +1000 (EST)
Message-Id: <200004122317.JAA64410@clouds.melbourne.sgi.com>
X-Mailer: exmh version 2.0.2 2/24/98
To:     lord@sgi.com
Cc:     linux-xfs@oss.sgi.com
Subject: Re: Beta contents/date 
In-reply-to: Your message of "Wed, 12 Apr 2000 14:17:18 EST."
             <200004121917.OAA05379@jen.americas.sgi.com> 
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date:   Thu, 13 Apr 2000 09:17:48 +1000
From:   Daniel Moore <dxm@clouds.melbourne.sgi.com>
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing


Steve Lord <lord@sgi.com> writes:

 =>  o V1 directories will probably break all over the place when used on
 =>    Linux - this becomes an issue if we can mount Irix volumes on Linux
 =>    as most of these will still be V1.

I'm in the middle of the architecture work for V1 directories. Could
you fill me in on what issues there are with then on Linux?

Ta...
-----------------------------------------------------
 Daniel Moore                  dxm@sgi.com
 R&D Software Engineer         Phone: +61-3-98348209
 SGI Performance Tools Group   Fax:   +61-3-98132378
-----------------------------------------------------


From owner-linux-xfs@oss.sgi.com Wed Apr 12 16:48:03 2000
Received:  by oss.sgi.com id <S305161AbQDLXrx>;
	Wed, 12 Apr 2000 16:47:53 -0700
Received: from deliverator.sgi.com ([204.94.214.10]:30055 "EHLO
        deliverator.sgi.com") by oss.sgi.com with ESMTP id <S305173AbQDLXrl>;
	Wed, 12 Apr 2000 16:47:41 -0700
Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via SMTP id QAA27798
	for <linux-xfs@oss.sgi.com>; Wed, 12 Apr 2000 16:42:56 -0700 (PDT)
	mail_from (dxm@clouds.melbourne.sgi.com)
Received: from clouds.melbourne.sgi.com (clouds.melbourne.sgi.com [134.14.55.166]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id JAA18728 for <@larry.melbourne.sgi.com:linux-xfs@oss.sgi.com>; Thu, 13 Apr 2000 09:45:07 +1000
Received: from localhost (dxm@localhost) by clouds.melbourne.sgi.com (980427.SGI.8.8.8/980728.SGI.AUTOCF) via SMTP id JAA66038 for <linux-xfs@oss.sgi.com>; Thu, 13 Apr 2000 09:45:06 +1000 (EST)
Message-Id: <200004122345.JAA66038@clouds.melbourne.sgi.com>
X-Mailer: exmh version 2.0.2 2/24/98
To:     linux-xfs@oss.sgi.com
Subject: flush on sync
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date:   Thu, 13 Apr 2000 09:45:06 +1000
From:   Daniel Moore <dxm@clouds.melbourne.sgi.com>
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing


Anyone noticed that 'sync' doesn't?

Just recently I've noticed that 'sync' doesn't flush out changes
I've made to xfs partitions and that I need to unmount to get
the changes out to disk.

I'm running t-o-t with some localised dir1 changes, loading
xfs, page_buf_locking, page_buf and avl as modules.

I'm pretty sure it only started yesterday.


-----------------------------------------------------
 Daniel Moore                  dxm@sgi.com
 R&D Software Engineer         Phone: +61-3-98348209
 SGI Performance Tools Group   Fax:   +61-3-98132378
-----------------------------------------------------


From owner-linux-xfs@oss.sgi.com Wed Apr 12 18:49:13 2000
Received:  by oss.sgi.com id <S305166AbQDMBtE>;
	Wed, 12 Apr 2000 18:49:04 -0700
Received: from pneumatic-tube.sgi.com ([204.94.214.22]:11793 "EHLO
        pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP
	id <S305162AbQDMBsq>; Wed, 12 Apr 2000 18:48:46 -0700
Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via SMTP id SAA09965
	for <linux-xfs@oss.sgi.com>; Wed, 12 Apr 2000 18:52:38 -0700 (PDT)
	mail_from (dxm@snort.melbourne.sgi.com)
Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.55.149]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id LAA19737 for <@larry.melbourne.sgi.com:linux-xfs@oss.sgi.com>; Thu, 13 Apr 2000 11:47:25 +1000
Received: (from dxm@localhost) by snort.melbourne.sgi.com (980427.SGI.8.8.8/980728.SGI.AUTOCF) id LAA04189 for linux-xfs@oss.sgi.com; Thu, 13 Apr 2000 11:47:22 +1000 (EST)
Date:   Thu, 13 Apr 2000 11:47:22 +1000 (EST)
From:   dxm@snort.melbourne.sgi.com (Daniel Moore)
Message-Id: <200004130147.LAA04189@snort.melbourne.sgi.com>
To:     linux-xfs@oss.sgi.com
Subject: TAKE - architecture mods - dir 1 leaf/node
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing

Modid:  2.3.99pre2-xfs:slinx:57832a
Date:  Wed Apr 12 18:46:58 PDT 2000
Workarea:  snort:/build1/people/dxm/isms/slinx-xfs

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

cmd/xfs/db/dir.c - 1.22
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/cmd/xfs/db/dir.c.diff?r1=text&tr1=1.22&r2=text&tr2=1.21&f=h
linux/fs/xfs/xfs_da_btree.c - 1.106
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/linux/fs/xfs/xfs_da_btree.c.diff?r1=text&tr1=1.106&r2=text&tr2=1.105&f=h
linux/fs/xfs/xfs_dir.c - 1.123
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/linux/fs/xfs/xfs_dir.c.diff?r1=text&tr1=1.123&r2=text&tr2=1.122&f=h
linux/fs/xfs/xfs_dir_leaf.c - 1.82
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/linux/fs/xfs/xfs_dir_leaf.c.diff?r1=text&tr1=1.82&r2=text&tr2=1.81&f=h
linux/fs/xfs/xfsidbg.c - 1.129
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/linux/fs/xfs/xfsidbg.c.diff?r1=text&tr1=1.129&r2=text&tr2=1.128&f=h

From owner-linux-xfs@oss.sgi.com Wed Apr 12 21:29:44 2000
Received:  by oss.sgi.com id <S305169AbQDME3f>;
	Wed, 12 Apr 2000 21:29:35 -0700
Received: from deliverator.sgi.com ([204.94.214.10]:29208 "EHLO
        deliverator.sgi.com") by oss.sgi.com with ESMTP id <S305166AbQDME3T>;
	Wed, 12 Apr 2000 21:29:19 -0700
Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via SMTP id VAA20158
	for <linux-xfs@oss.sgi.com>; Wed, 12 Apr 2000 21:24:35 -0700 (PDT)
	mail_from (dxm@snort.melbourne.sgi.com)
Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.55.149]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id OAA20770 for <@larry.melbourne.sgi.com:linux-xfs@oss.sgi.com>; Thu, 13 Apr 2000 14:28:01 +1000
Received: (from dxm@localhost) by snort.melbourne.sgi.com (980427.SGI.8.8.8/980728.SGI.AUTOCF) id OAA78146 for linux-xfs@oss.sgi.com; Thu, 13 Apr 2000 14:27:59 +1000 (EST)
Date:   Thu, 13 Apr 2000 14:27:59 +1000 (EST)
From:   dxm@snort.melbourne.sgi.com (Daniel Moore)
Message-Id: <200004130427.OAA78146@snort.melbourne.sgi.com>
To:     linux-xfs@oss.sgi.com
Subject: TAKE - xfsidbg dir1 architecture bugfix
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing

Modid:  2.3.99pre2-xfs:slinx:57833a
Date:  Wed Apr 12 21:27:37 PDT 2000
Workarea:  snort:/build1/people/dxm/isms/slinx-xfs

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

linux/fs/xfs/xfsidbg.c - 1.130
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/linux/fs/xfs/xfsidbg.c.diff?r1=text&tr1=1.130&r2=text&tr2=1.129&f=h
	- dir1 architecture bugfix


From owner-linux-xfs@oss.sgi.com Wed Apr 12 22:33:34 2000
Received:  by oss.sgi.com id <S305169AbQDMFdZ>;
	Wed, 12 Apr 2000 22:33:25 -0700
Received: from pneumatic-tube.sgi.com ([204.94.214.22]:53529 "EHLO
        pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP
	id <S305166AbQDMFdG>; Wed, 12 Apr 2000 22:33:06 -0700
Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via SMTP id WAA00742
	for <linux-xfs@oss.sgi.com>; Wed, 12 Apr 2000 22:36:59 -0700 (PDT)
	mail_from (dxm@snort.melbourne.sgi.com)
Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.55.149]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id PAA21210 for <@larry.melbourne.sgi.com:linux-xfs@oss.sgi.com>; Thu, 13 Apr 2000 15:31:47 +1000
Received: (from dxm@localhost) by snort.melbourne.sgi.com (980427.SGI.8.8.8/980728.SGI.AUTOCF) id PAA70407 for linux-xfs@oss.sgi.com; Thu, 13 Apr 2000 15:31:45 +1000 (EST)
Date:   Thu, 13 Apr 2000 15:31:45 +1000 (EST)
From:   dxm@snort.melbourne.sgi.com (Daniel Moore)
Message-Id: <200004130531.PAA70407@snort.melbourne.sgi.com>
To:     linux-xfs@oss.sgi.com
Subject: TAKE - xfsidbg dir2 architecture bugfixes
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing

Modid:  2.3.99pre2-xfs:slinx:57836a
Date:  Wed Apr 12 22:31:29 PDT 2000
Workarea:  snort:/build1/people/dxm/isms/slinx-xfs

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

linux/fs/xfs/xfsidbg.c - 1.131
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/linux/fs/xfs/xfsidbg.c.diff?r1=text&tr1=1.131&r2=text&tr2=1.130&f=h

From owner-linux-xfs@oss.sgi.com Thu Apr 13 00:31:25 2000
Received:  by oss.sgi.com id <S305166AbQDMHbP>;
	Thu, 13 Apr 2000 00:31:15 -0700
Received: from deliverator.sgi.com ([204.94.214.10]:7979 "EHLO
        deliverator.sgi.com") by oss.sgi.com with ESMTP id <S305169AbQDMHau>;
	Thu, 13 Apr 2000 00:30:50 -0700
Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via SMTP id AAA00322
	for <linux-xfs@oss.sgi.com>; Thu, 13 Apr 2000 00:26:04 -0700 (PDT)
	mail_from (nathans@snort.melbourne.sgi.com)
Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.55.149]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id RAA21952 for <@larry.melbourne.sgi.com:linux-xfs@oss.sgi.com>; Thu, 13 Apr 2000 17:28:13 +1000
Received: (from nathans@localhost) by snort.melbourne.sgi.com (980427.SGI.8.8.8/980728.SGI.AUTOCF) id RAA21796 for linux-xfs@oss.sgi.com; Thu, 13 Apr 2000 17:28:10 +1000 (EST)
Date:   Thu, 13 Apr 2000 17:28:10 +1000 (EST)
From:   nathans@snort.melbourne.sgi.com (Nathan Scott)
Message-Id: <200004130728.RAA21796@snort.melbourne.sgi.com>
To:     linux-xfs@oss.sgi.com
Subject: TAKE - btree header architecture work
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing

This makes the xfs_btree_sblock_t, xfs_alloc_block_t, xfs_inobt_block_t,
xfs_btree_lblock_t, xfs_btree_block_t, xfs_btree_hdr_t, xfs_bmdr_block_t,
and xfs_bmbt_block_t structures independent of the on-disk architecture.


Modid:  2.3.99pre2-xfs:slinx:57839a
Date:  Thu Apr 13 00:24:52 PDT 2000
Workarea:  snort:/build4/nathans/2.3.99pre2-xfs

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

cmd/xfs/db/bmap.c - 1.25
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/cmd/xfs/db/bmap.c.diff?r1=text&tr1=1.25&r2=text&tr2=1.24&f=h
cmd/xfs/db/bmapbt.c - 1.14
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/cmd/xfs/db/bmapbt.c.diff?r1=text&tr1=1.14&r2=text&tr2=1.13&f=h
cmd/xfs/db/bmroot.c - 1.19
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/cmd/xfs/db/bmroot.c.diff?r1=text&tr1=1.19&r2=text&tr2=1.18&f=h
cmd/xfs/db/bnobt.c - 1.14
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/cmd/xfs/db/bnobt.c.diff?r1=text&tr1=1.14&r2=text&tr2=1.13&f=h
cmd/xfs/db/check.c - 1.47
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/cmd/xfs/db/check.c.diff?r1=text&tr1=1.47&r2=text&tr2=1.46&f=h
cmd/xfs/db/cntbt.c - 1.13
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/cmd/xfs/db/cntbt.c.diff?r1=text&tr1=1.13&r2=text&tr2=1.12&f=h
cmd/xfs/db/frag.c - 1.12
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/cmd/xfs/db/frag.c.diff?r1=text&tr1=1.12&r2=text&tr2=1.11&f=h
cmd/xfs/db/freesp.c - 1.12
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/cmd/xfs/db/freesp.c.diff?r1=text&tr1=1.12&r2=text&tr2=1.11&f=h
cmd/xfs/db/inobt.c - 1.13
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/cmd/xfs/db/inobt.c.diff?r1=text&tr1=1.13&r2=text&tr2=1.12&f=h
	- architecture independence for btree header data structures.

cmd/xfs/mangle/agf.c - 1.2
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/cmd/xfs/mangle/agf.c.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h
cmd/xfs/mangle/inodes.c - 1.4
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/cmd/xfs/mangle/inodes.c.diff?r1=text&tr1=1.4&r2=text&tr2=1.3&f=h
cmd/xfs/mangle/xfs_mangle.h - 1.5
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/cmd/xfs/mangle/xfs_mangle.h.diff?r1=text&tr1=1.5&r2=text&tr2=1.4&f=h
	- add support for mangling the agi and agf btree header data structures.

cmd/xfs/mkfs/xfs_mkfs.c - 1.157
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/cmd/xfs/mkfs/xfs_mkfs.c.diff?r1=text&tr1=1.157&r2=text&tr2=1.156&f=h
linux/fs/xfs/xfs_alloc.c - 1.129
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/linux/fs/xfs/xfs_alloc.c.diff?r1=text&tr1=1.129&r2=text&tr2=1.128&f=h
linux/fs/xfs/xfs_alloc_btree.c - 1.58
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/linux/fs/xfs/xfs_alloc_btree.c.diff?r1=text&tr1=1.58&r2=text&tr2=1.57&f=h
linux/fs/xfs/xfs_bmap.c - 1.247
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/linux/fs/xfs/xfs_bmap.c.diff?r1=text&tr1=1.247&r2=text&tr2=1.246&f=h
linux/fs/xfs/xfs_bmap_btree.c - 1.107
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/linux/fs/xfs/xfs_bmap_btree.c.diff?r1=text&tr1=1.107&r2=text&tr2=1.106&f=h
linux/fs/xfs/xfs_bmap_btree.h - 1.45
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/linux/fs/xfs/xfs_bmap_btree.h.diff?r1=text&tr1=1.45&r2=text&tr2=1.44&f=h
linux/fs/xfs/xfs_btree.c - 1.80
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/linux/fs/xfs/xfs_btree.c.diff?r1=text&tr1=1.80&r2=text&tr2=1.79&f=h
linux/fs/xfs/xfs_fsops.c - 1.49
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/linux/fs/xfs/xfs_fsops.c.diff?r1=text&tr1=1.49&r2=text&tr2=1.48&f=h
linux/fs/xfs/xfs_ialloc_btree.c - 1.52
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/linux/fs/xfs/xfs_ialloc_btree.c.diff?r1=text&tr1=1.52&r2=text&tr2=1.51&f=h
linux/fs/xfs/xfs_ialloc_btree.h - 1.16
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/linux/fs/xfs/xfs_ialloc_btree.h.diff?r1=text&tr1=1.16&r2=text&tr2=1.15&f=h
linux/fs/xfs/xfsidbg.c - 1.132
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/linux/fs/xfs/xfsidbg.c.diff?r1=text&tr1=1.132&r2=text&tr2=1.131&f=h
	- architecture independence for btree header data structures.


From owner-linux-xfs@oss.sgi.com Thu Apr 13 07:01:39 2000
Received:  by oss.sgi.com id <S305169AbQDMOBU>;
	Thu, 13 Apr 2000 07:01:20 -0700
Received: from deliverator.sgi.com ([204.94.214.10]:14423 "EHLO
        deliverator.sgi.com") by oss.sgi.com with ESMTP id <S305166AbQDMOBB>;
	Thu, 13 Apr 2000 07:01:01 -0700
Received: from ledzep.cray.com (ledzep.cray.com [137.38.226.97]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id GAA23592
	for <linux-xfs@oss.sgi.com>; Thu, 13 Apr 2000 06:56:17 -0700 (PDT)
	mail_from (lord@sgi.com)
Received: from ironwood-e185.americas.sgi.com (ironwood.cray.com [128.162.185.212]) by ledzep.cray.com (SGI-SGI-8.9.3/craymail-smart-nospam1.0) with ESMTP id IAA30053; Thu, 13 Apr 2000 08:59:34 -0500 (CDT)
Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.184.86]) by ironwood-e185.americas.sgi.com (8.8.4/SGI-ironwood-e1.4) with ESMTP id IAA14982; Thu, 13 Apr 2000 08:59:26 -0500 (CDT)
Received: from jen.americas.sgi.com by jen.americas.sgi.com (8.9.3/SGI-client.1.6) via ESMTP id IAA06354; Thu, 13 Apr 2000 08:59:22 -0500
Message-Id: <200004131359.IAA06354@jen.americas.sgi.com>
X-Mailer: exmh version 2.1.1 10/15/1999
To:     Daniel Moore <dxm@clouds.melbourne.sgi.com>
cc:     lord@sgi.com, linux-xfs@oss.sgi.com
Subject: Re: Beta contents/date 
In-Reply-To: Message from Daniel Moore <dxm@clouds.melbourne.sgi.com> 
   of "Thu, 13 Apr 2000 09:17:48 +1000." <200004122317.JAA64410@clouds.melbourne.sgi.com> 
Date:   Thu, 13 Apr 2000 08:59:22 -0500
From:   Steve Lord <lord@sgi.com>
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing

> 
> Steve Lord <lord@sgi.com> writes:
> 
>  =>  o V1 directories will probably break all over the place when used on
>  =>    Linux - this becomes an issue if we can mount Irix volumes on Linux
>  =>    as most of these will still be V1.
> 
> I'm in the middle of the architecture work for V1 directories. Could
> you fill me in on what issues there are with then on Linux?
> 
> Ta...
> -----------------------------------------------------
>  Daniel Moore                  dxm@sgi.com
>  R&D Software Engineer         Phone: +61-3-98348209
>  SGI Performance Tools Group   Fax:   +61-3-98132378
> -----------------------------------------------------

The directory offset information returned in V1 is a 64 bit value made up
of two halves. If only 32 bits are saved used by user space then there could
be issues with the glibc getdents implementation. getdents is converting from
a kernel structure to a user space structure, it uses a heuristic to determine
how much to prune the users request back so that the data returned from
the kernel will still fit in the user's buffer. This heuristic appears to
fail regularly - at which point the glibc getdents code seeks backwards in
the file. 

The seek will reset the file offset back again - and we will possibly repeat
or skip entries - an infinite loop is possible.

There may be other consequences too.

Steve



From owner-linux-xfs@oss.sgi.com Thu Apr 13 08:15:31 2000
Received:  by oss.sgi.com id <S305169AbQDMPPV>;
	Thu, 13 Apr 2000 08:15:21 -0700
Received: from [216.208.98.2] ([216.208.98.2]:5882 "EHLO moiraine.off.net")
	by oss.sgi.com with ESMTP id <S305166AbQDMPO6>;
	Thu, 13 Apr 2000 08:14:58 -0700
Received: (from phil@localhost)
	by moiraine.off.net (8.9.3/8.9.3) id MAA03522
	for linux-xfs@oss.sgi.com; Thu, 13 Apr 2000 12:06:07 -0400
Date:   Thu, 13 Apr 2000 12:06:07 -0400
From:   Phil Schwan <phil@linuxcare.com>
To:     linux-xfs@oss.sgi.com
Subject: Re: XFS as Root filesystem
Message-ID: <20000413120607.A1665@linuxcare.com>
References: <sct@redhat.com> <200004061552.KAA20840@jen.americas.sgi.com> <20000411001238.I611@linuxcare.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 0.95.4us
In-Reply-To: <20000411001238.I611@linuxcare.com>; from Phil Schwan on Tue, Apr 11, 2000 at 12:12:38AM -0400
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing

On Apr 11, Phil Schwan wrote:
> In somewhat-related news, I have a patch for doing recovery in
> read-only mode that I will test tomorrow.  If it works on both
> internal and external logs, I'll send it along for review.

This appears to do the Right Thing.  I flip off the machine in the
middle of a large write, mount it read-only, and it happily plays the
log back (as far as I can tell).  Since I'm still dealing with the
helpdesk to get my internal network access fixed, I'm not sure if
there are "real" log replay tests available.

RCS file: /cvs/linux-2.3-xfs/linux/fs/xfs/xfs_log_recover.c,v
retrieving revision 1.170
diff -u -r1.170 xfs_log_recover.c
--- xfs_log_recover.c   2000/04/06 01:26:24     1.170
+++ xfs_log_recover.c   2000/04/13 14:58:00
@@ -3334,6 +3335,7 @@
 {
        daddr_t head_blk, tail_blk;
        int     error;
+       xfs_mount_t *mp;
 
        if (error = xlog_find_tail(log, &head_blk, &tail_blk, readonly))
                return error;
@@ -3343,13 +3345,24 @@
                head_blk = HEAD_BLK;
                tail_blk = TAIL_BLK;
 #endif
-               /*
+
+               /* There used to be a comment here:
+                *
                 * disallow recovery on read-only mounts.  note -- mount
                 * checks for ENOSPC and turns it into an intelligent
                 * error message.
-                */
-               if (readonly)
-                       return ENOSPC;
+                *
+                * ...but this is no longer true.  Now, unless you specify
+                * NORECOVERY (in which case this function would never be
+                * called), it enables read-write access long enough to do
+                * recovery.
+                */
+               if (readonly) {
+                       cmn_err(CE_WARN, "XFS: temporarily enabling read/write access for log recovery.\n");
+                       mp = log->l_mp;
+                       XFS_MTOVFS(mp)->vfs_flag &= ~VFS_RDONLY;
+               }
+
 #ifdef _KERNEL
 #if defined(DEBUG) && defined(XFS_LOUD_RECOVERY)
                cmn_err(CE_NOTE,
@@ -3365,6 +3378,8 @@
 #endif
                error = xlog_do_recover(log, head_blk, tail_blk);
                log->l_flags |= XLOG_RECOVERY_NEEDED;
+               if (readonly)
+                       XFS_MTOVFS(mp)->vfs_flag |= VFS_RDONLY;
        }
        return error;
 }      /* xlog_recover */

Let me know if you notice trouble--this seems deceptively simple.

-Phil

From owner-linux-xfs@oss.sgi.com Thu Apr 13 08:30:31 2000
Received:  by oss.sgi.com id <S305169AbQDMPaV>;
	Thu, 13 Apr 2000 08:30:21 -0700
Received: from pneumatic-tube.sgi.com ([204.94.214.22]:59962 "EHLO
        pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP
	id <S305166AbQDMP3x>; Thu, 13 Apr 2000 08:29:53 -0700
Received: from ledzep.cray.com (ledzep.cray.com [137.38.226.97]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id IAA03819
	for <linux-xfs@oss.sgi.com>; Thu, 13 Apr 2000 08:33:47 -0700 (PDT)
	mail_from (lord@sgi.com)
Received: from ironwood-e185.americas.sgi.com (ironwood.cray.com [128.162.185.212]) by ledzep.cray.com (SGI-SGI-8.9.3/craymail-smart-nospam1.0) with ESMTP id KAA39143; Thu, 13 Apr 2000 10:28:35 -0500 (CDT)
Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.184.86]) by ironwood-e185.americas.sgi.com (8.8.4/SGI-ironwood-e1.4) with ESMTP id KAA19894; Thu, 13 Apr 2000 10:28:27 -0500 (CDT)
Received: from jen.americas.sgi.com by jen.americas.sgi.com (8.9.3/SGI-client.1.6) via ESMTP id KAA07085; Thu, 13 Apr 2000 10:28:23 -0500
Message-Id: <200004131528.KAA07085@jen.americas.sgi.com>
X-Mailer: exmh version 2.1.1 10/15/1999
To:     Phil Schwan <phil@linuxcare.com>
cc:     linux-xfs@oss.sgi.com
Subject: Re: XFS as Root filesystem 
In-Reply-To: Message from Phil Schwan <phil@linuxcare.com> 
   of "Thu, 13 Apr 2000 12:06:07 EDT." <20000413120607.A1665@linuxcare.com> 
Date:   Thu, 13 Apr 2000 10:28:23 -0500
From:   Steve Lord <lord@sgi.com>
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing


This in itself looks reasonable, but Stephen Tweedie mentioned detecting
read only devices and refusing to do the recovery - and that there was
code which did this in the latest ext3 cut.

Not sure if this is worth following up on with XFS, since XFS refuses
to fit on a floppy, it means XFS on an LS120 (or some other media) or
someone burned a filesystem needing recovery onto a cdrom. If there is
a simple test we can make for read only media then it is probably worth
adding, if it is complex then probably not.

Steve

> On Apr 11, Phil Schwan wrote:
> > In somewhat-related news, I have a patch for doing recovery in
> > read-only mode that I will test tomorrow.  If it works on both
> > internal and external logs, I'll send it along for review.
> 
> This appears to do the Right Thing.  I flip off the machine in the
> middle of a large write, mount it read-only, and it happily plays the
> log back (as far as I can tell).  Since I'm still dealing with the
> helpdesk to get my internal network access fixed, I'm not sure if
> there are "real" log replay tests available.
> 
> RCS file: /cvs/linux-2.3-xfs/linux/fs/xfs/xfs_log_recover.c,v
> retrieving revision 1.170
> diff -u -r1.170 xfs_log_recover.c
> --- xfs_log_recover.c   2000/04/06 01:26:24     1.170
> +++ xfs_log_recover.c   2000/04/13 14:58:00
> @@ -3334,6 +3335,7 @@
>  {
>         daddr_t head_blk, tail_blk;
>         int     error;
> +       xfs_mount_t *mp;
>  
>         if (error = xlog_find_tail(log, &head_blk, &tail_blk, readonly))
>                 return error;
> @@ -3343,13 +3345,24 @@
>                 head_blk = HEAD_BLK;
>                 tail_blk = TAIL_BLK;
>  #endif
> -               /*
> +
> +               /* There used to be a comment here:
> +                *
>                  * disallow recovery on read-only mounts.  note -- mount
>                  * checks for ENOSPC and turns it into an intelligent
>                  * error message.
> -                */
> -               if (readonly)
> -                       return ENOSPC;
> +                *
> +                * ...but this is no longer true.  Now, unless you specify
> +                * NORECOVERY (in which case this function would never be
> +                * called), it enables read-write access long enough to do
> +                * recovery.
> +                */
> +               if (readonly) {
> +                       cmn_err(CE_WARN, "XFS: temporarily enabling read/writ
e access for log recovery.\n");
> +                       mp = log->l_mp;
> +                       XFS_MTOVFS(mp)->vfs_flag &= ~VFS_RDONLY;
> +               }
> +
>  #ifdef _KERNEL
>  #if defined(DEBUG) && defined(XFS_LOUD_RECOVERY)
>                 cmn_err(CE_NOTE,
> @@ -3365,6 +3378,8 @@
>  #endif
>                 error = xlog_do_recover(log, head_blk, tail_blk);
>                 log->l_flags |= XLOG_RECOVERY_NEEDED;
> +               if (readonly)
> +                       XFS_MTOVFS(mp)->vfs_flag |= VFS_RDONLY;
>         }
>         return error;
>  }      /* xlog_recover */
> 
> Let me know if you notice trouble--this seems deceptively simple.
> 
> -Phil



From owner-linux-xfs@oss.sgi.com Thu Apr 13 09:02:01 2000
Received:  by oss.sgi.com id <S305169AbQDMQBl>;
	Thu, 13 Apr 2000 09:01:41 -0700
Received: from pneumatic-tube.sgi.com ([204.94.214.22]:53310 "EHLO
        pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP
	id <S305166AbQDMQBO>; Thu, 13 Apr 2000 09:01:14 -0700
Received: from ledzep.cray.com (ledzep.cray.com [137.38.226.97]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id JAA05938
	for <linux-xfs@oss.sgi.com>; Thu, 13 Apr 2000 09:05:08 -0700 (PDT)
	mail_from (lord@sgi.com)
Received: from ironwood-e185.americas.sgi.com (ironwood.cray.com [128.162.185.212]) by ledzep.cray.com (SGI-SGI-8.9.3/craymail-smart-nospam1.0) with ESMTP id KAA72947; Thu, 13 Apr 2000 10:59:52 -0500 (CDT)
Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.184.86]) by ironwood-e185.americas.sgi.com (8.8.4/SGI-ironwood-e1.4) with ESMTP id KAA21898; Thu, 13 Apr 2000 10:59:45 -0500 (CDT)
Received: from jen.americas.sgi.com by jen.americas.sgi.com (8.9.3/SGI-client.1.6) via ESMTP id KAA07144; Thu, 13 Apr 2000 10:59:40 -0500
Message-Id: <200004131559.KAA07144@jen.americas.sgi.com>
X-Mailer: exmh version 2.1.1 10/15/1999
To:     Daniel Moore <dxm@clouds.melbourne.sgi.com>
cc:     linux-xfs@oss.sgi.com
Subject: Re: flush on sync 
In-Reply-To: Message from Daniel Moore <dxm@clouds.melbourne.sgi.com> 
   of "Thu, 13 Apr 2000 09:45:06 +1000." <200004122345.JAA66038@clouds.melbourne.sgi.com> 
Date:   Thu, 13 Apr 2000 10:59:40 -0500
From:   Steve Lord <lord@sgi.com>
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing

> 
> Anyone noticed that 'sync' doesn't?
> 
> Just recently I've noticed that 'sync' doesn't flush out changes
> I've made to xfs partitions and that I need to unmount to get
> the changes out to disk.
> 
> I'm running t-o-t with some localised dir1 changes, loading
> xfs, page_buf_locking, page_buf and avl as modules.
> 
> I'm pretty sure it only started yesterday.
> 

Pagebuf meta-data on or off?

We are fudging sync through the write_super method:

void
linvfs_write_super(
        struct super_block *sb)
{
        vfs_t           *vfsp = LINVFS_GET_VFS(sb);
        int             error;
#if !CONFIG_PAGE_BUF_META
        extern void bflush_bufs(dev_t);
#endif


        VFS_SYNC(vfsp, SYNC_FSDATA|SYNC_BDFLUSH|SYNC_NOWAIT|SYNC_ATTR,
                sys_cred, error);

#if !CONFIG_PAGE_BUF_META
        bflush_bufs(vfsp->vfs_dev);/* Pretend a bdflush is going off for XFS
                                        specific buffers from xfs_fs_bio.c */
#endif

        sb->s_dirt = 1;  /*  Keep the syncs coming.  */
}

The VFS_SYNC call gets into XFS sync, and would flush dirty data - except that
the test it uses to determine if something is dirty does not work on linux
because we are 

	a) looking at the wrong state (the vnode) and

	b) Linux does not keep track of dirty data at this level.

However, higher up in the sync code there is a call to sync_buffers() which
should find dirty file data.

What is it you do not think is getting synced?

Steve



From owner-linux-xfs@oss.sgi.com Thu Apr 13 09:21:02 2000
Received:  by oss.sgi.com id <S305169AbQDMQUm>;
	Thu, 13 Apr 2000 09:20:42 -0700
Received: from pneumatic-tube.sgi.com ([204.94.214.22]:62016 "EHLO
        pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP
	id <S305166AbQDMQUS>; Thu, 13 Apr 2000 09:20:18 -0700
Received: from ledzep.cray.com (ledzep.cray.com [137.38.226.97]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id JAA06693
	for <linux-xfs@oss.sgi.com>; Thu, 13 Apr 2000 09:24:13 -0700 (PDT)
	mail_from (mostek@sgi.com)
Received: from ironwood-e185.americas.sgi.com (ironwood.cray.com [128.162.185.212]) by ledzep.cray.com (SGI-SGI-8.9.3/craymail-smart-nospam1.0) with ESMTP id LAA42195 for <linux-xfs@oss.sgi.com>; Thu, 13 Apr 2000 11:19:02 -0500 (CDT)
Received: from fsgi344.americas.sgi.com (fsgi344.americas.sgi.com [128.162.184.15]) by ironwood-e185.americas.sgi.com (8.8.4/SGI-ironwood-e1.4) with ESMTP id LAA23378; Thu, 13 Apr 2000 11:18:54 -0500 (CDT)
From:   Jim Mostek <mostek@sgi.com>
Received: by fsgi344.americas.sgi.com (980427.SGI.8.8.8/SGI-client.1.6) id LAA55955; Thu, 13 Apr 2000 11:19:00 -0500 (CDT)
Message-Id: <200004131619.LAA55955@fsgi344.americas.sgi.com>
Subject: Re: XFS as Root filesystem
To:     lord@sgi.com (Steve Lord)
Date:   Thu, 13 Apr 2000 11:19:00 -0500 (CDT)
Cc:     linux-xfs@oss.sgi.com
In-Reply-To: <200004131528.KAA07085@jen.americas.sgi.com> from "Steve Lord" at Apr 13, 2000 10:28:23 AM
X-Mailer: ELM [version 2.5 PL2]
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing


I would like to see XFS mount as root before we worry about handling a
read-only device. Also, we need to see how XFS handles "file system
SHUTDOWN" after the read-only mount. In this case, xfs_repair should be
run on the file system (instead of fsck) and then mounted. This is the way
Linux does things, right?

Once we have root working, let's see what happens on read-only device.

If XFS burned on a read-only device, recovery should say nothing to do
and not try to write it. Right?

Jim

>
>
>This in itself looks reasonable, but Stephen Tweedie mentioned detecting
>read only devices and refusing to do the recovery - and that there was
>code which did this in the latest ext3 cut.
>
>Not sure if this is worth following up on with XFS, since XFS refuses
>to fit on a floppy, it means XFS on an LS120 (or some other media) or
>someone burned a filesystem needing recovery onto a cdrom. If there is
>a simple test we can make for read only media then it is probably worth
>adding, if it is complex then probably not.
>
>Steve
>
>> On Apr 11, Phil Schwan wrote:
>> > In somewhat-related news, I have a patch for doing recovery in
>> > read-only mode that I will test tomorrow.  If it works on both
>> > internal and external logs, I'll send it along for review.
>> 
>> This appears to do the Right Thing.  I flip off the machine in the
>> middle of a large write, mount it read-only, and it happily plays the
>> log back (as far as I can tell).  Since I'm still dealing with the
>> helpdesk to get my internal network access fixed, I'm not sure if
>> there are "real" log replay tests available.
>> 
>> RCS file: /cvs/linux-2.3-xfs/linux/fs/xfs/xfs_log_recover.c,v
>> retrieving revision 1.170
>> diff -u -r1.170 xfs_log_recover.c
>> --- xfs_log_recover.c   2000/04/06 01:26:24     1.170
>> +++ xfs_log_recover.c   2000/04/13 14:58:00
>> @@ -3334,6 +3335,7 @@
>>  {
>>         daddr_t head_blk, tail_blk;
>>         int     error;
>> +       xfs_mount_t *mp;
>>  
>>         if (error = xlog_find_tail(log, &head_blk, &tail_blk, readonly))
>>                 return error;
>> @@ -3343,13 +3345,24 @@
>>                 head_blk = HEAD_BLK;
>>                 tail_blk = TAIL_BLK;
>>  #endif
>> -               /*
>> +
>> +               /* There used to be a comment here:
>> +                *
>>                  * disallow recovery on read-only mounts.  note -- mount
>>                  * checks for ENOSPC and turns it into an intelligent
>>                  * error message.
>> -                */
>> -               if (readonly)
>> -                       return ENOSPC;
>> +                *
>> +                * ...but this is no longer true.  Now, unless you specify
>> +                * NORECOVERY (in which case this function would never be
>> +                * called), it enables read-write access long enough to do
>> +                * recovery.
>> +                */
>> +               if (readonly) {
>> +                       cmn_err(CE_WARN, "XFS: temporarily enabling read/writ
>e access for log recovery.\n");
>> +                       mp = log->l_mp;
>> +                       XFS_MTOVFS(mp)->vfs_flag &= ~VFS_RDONLY;
>> +               }
>> +
>>  #ifdef _KERNEL
>>  #if defined(DEBUG) && defined(XFS_LOUD_RECOVERY)
>>                 cmn_err(CE_NOTE,
>> @@ -3365,6 +3378,8 @@
>>  #endif
>>                 error = xlog_do_recover(log, head_blk, tail_blk);
>>                 log->l_flags |= XLOG_RECOVERY_NEEDED;
>> +               if (readonly)
>> +                       XFS_MTOVFS(mp)->vfs_flag |= VFS_RDONLY;
>>         }
>>         return error;
>>  }      /* xlog_recover */
>> 
>> Let me know if you notice trouble--this seems deceptively simple.
>> 
>> -Phil
>
>


From owner-linux-xfs@oss.sgi.com Thu Apr 13 09:31:02 2000
Received:  by oss.sgi.com id <S305169AbQDMQam>;
	Thu, 13 Apr 2000 09:30:42 -0700
Received: from [216.208.98.2] ([216.208.98.2]:61435 "EHLO moiraine.off.net")
	by oss.sgi.com with ESMTP id <S305166AbQDMQaU>;
	Thu, 13 Apr 2000 09:30:20 -0700
Received: (from phil@localhost)
	by moiraine.off.net (8.9.3/8.9.3) id NAA03971;
	Thu, 13 Apr 2000 13:21:19 -0400
Date:   Thu, 13 Apr 2000 13:21:19 -0400
From:   Phil Schwan <phil@linuxcare.com>
To:     Jim Mostek <mostek@sgi.com>
Cc:     linux-xfs@oss.sgi.com
Subject: Re: XFS as Root filesystem
Message-ID: <20000413132119.B1665@linuxcare.com>
References: <200004131528.KAA07085@jen.americas.sgi.com> <200004131619.LAA55955@fsgi344.americas.sgi.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 0.95.4us
In-Reply-To: <200004131619.LAA55955@fsgi344.americas.sgi.com>; from Jim Mostek on Thu, Apr 13, 2000 at 11:19:00AM -0500
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing

On Apr 13, Jim Mostek wrote:
> I would like to see XFS mount as root before we worry about handling a
> read-only device.

I'm still working on that :)

> Also, we need to see how XFS handles "file system
> SHUTDOWN" after the read-only mount. In this case, xfs_repair should be
> run on the file system (instead of fsck) and then mounted. This is the way
> Linux does things, right?

Yes.  If for whatever reason the log replay fails (or any other
inconsistency, really), the FS is shutdown and should be fscked.

> If XFS burned on a read-only device, recovery should say nothing to do
> and not try to write it. Right?

Correct--As long as it's burned with a consistent filesystem (ie, log
head == log tail), it will never trigger that code.

-Phil

-- 
Phil Schwan, Captain Popetastic, Linuxcare Canada

From owner-linux-xfs@oss.sgi.com Thu Apr 13 10:26:22 2000
Received:  by oss.sgi.com id <S305169AbQDMR0N>;
	Thu, 13 Apr 2000 10:26:13 -0700
Received: from [216.208.98.2] ([216.208.98.2]:1263 "EHLO moiraine.off.net")
	by oss.sgi.com with ESMTP id <S305166AbQDMRZu>;
	Thu, 13 Apr 2000 10:25:50 -0700
Received: (from phil@localhost)
	by moiraine.off.net (8.9.3/8.9.3) id OAA04370;
	Thu, 13 Apr 2000 14:16:57 -0400
Date:   Thu, 13 Apr 2000 14:16:57 -0400
From:   Phil Schwan <phil@linuxcare.com>
To:     Steve Lord <lord@sgi.com>
Cc:     linux-xfs@oss.sgi.com
Subject: Re: XFS as Root filesystem
Message-ID: <20000413141657.C1665@linuxcare.com>
References: <phil@linuxcare.com> <200004131528.KAA07085@jen.americas.sgi.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 0.95.4us
In-Reply-To: <200004131528.KAA07085@jen.americas.sgi.com>; from Steve Lord on Thu, Apr 13, 2000 at 10:28:23AM -0500
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing

On Apr 13, Steve Lord wrote:
> This in itself looks reasonable, but Stephen Tweedie mentioned detecting
> read only devices and refusing to do the recovery - and that there was
> code which did this in the latest ext3 cut.
> 
> Not sure if this is worth following up on with XFS, since XFS refuses
> to fit on a floppy, it means XFS on an LS120 (or some other media) or
> someone burned a filesystem needing recovery onto a cdrom. If there is
> a simple test we can make for read only media then it is probably worth
> adding, if it is complex then probably not.

Here we go, try this out for size.

By the way, Russell, what's the best way to #include linux/fs.h here?
I'm still fuzzy on how the new arch-specific #includes work for
includes that aren't needed by every source file.

Index: xfs_log_recover.c
===================================================================
RCS file: /cvs/linux-2.3-xfs/linux/fs/xfs/xfs_log_recover.c,v
retrieving revision 1.170
diff -u -r1.170 xfs_log_recover.c
--- xfs_log_recover.c	2000/04/06 01:26:24	1.170
+++ xfs_log_recover.c	2000/04/13 17:23:17
@@ -44,6 +44,7 @@
 #include <sys/sysmacros.h>
 #include "xfs_buf.h"
 #include <linux/xfs_sema.h>
+#include <linux/fs.h>
 #include <sys/vnode.h>
 #include <sys/debug.h>
 #include <sys/cmn_err.h>
@@ -3334,6 +3336,7 @@
 {
 	daddr_t head_blk, tail_blk;
 	int	error;
+	xfs_mount_t *mp;
 
 	if (error = xlog_find_tail(log, &head_blk, &tail_blk, readonly))
 		return error;
@@ -3343,13 +3346,30 @@
 		head_blk = HEAD_BLK;
 		tail_blk = TAIL_BLK;
 #endif
-		/*
+
+		/* There used to be a comment here:
+		 *
 		 * disallow recovery on read-only mounts.  note -- mount
 		 * checks for ENOSPC and turns it into an intelligent
 		 * error message.
-		 */
-		if (readonly)
-			return ENOSPC;
+		 *
+		 * ...but this is no longer true.  Now, unless you specify
+		 * NORECOVERY (in which case this function would never be
+		 * called), it enables read-write access long enough to do
+		 * recovery.
+		 */
+		if (readonly) {
+			printk(KERN_ERR "XFS: WARNING: recovery required on readonly filesystem.\n");
+			mp = log->l_mp;
+			if (is_read_only(mp->m_dev) ||
+			    is_read_only(mp->m_logdev)) {
+				printk(KERN_ERR "XFS: write access unavailable, cannot proceed.\n");
+				return -EROFS;
+			}
+			printk(KERN_ERR "XFS: write access will be enabled during recovery.\n");
+			XFS_MTOVFS(mp)->vfs_flag &= ~VFS_RDONLY;
+		}
+
 #ifdef _KERNEL
 #if defined(DEBUG) && defined(XFS_LOUD_RECOVERY)
 		cmn_err(CE_NOTE,
@@ -3365,6 +3385,8 @@
 #endif
 		error = xlog_do_recover(log, head_blk, tail_blk);
 		log->l_flags |= XLOG_RECOVERY_NEEDED;
+		if (readonly)
+			XFS_MTOVFS(mp)->vfs_flag |= VFS_RDONLY;
 	}
 	return error;
 }	/* xlog_recover */

I have internal access now, thanks to the terrific helpdesk people.
All rejoice.

-- 
Phil Schwan, Captain Popetastic, Linuxcare Canada

From owner-linux-xfs@oss.sgi.com Thu Apr 13 10:34:44 2000
Received:  by oss.sgi.com id <S305169AbQDMRef>;
	Thu, 13 Apr 2000 10:34:35 -0700
Received: from deliverator.sgi.com ([204.94.214.10]:59409 "EHLO
        deliverator.sgi.com") by oss.sgi.com with ESMTP id <S305166AbQDMReS>;
	Thu, 13 Apr 2000 10:34:18 -0700
Received: from ledzep.cray.com (ledzep.cray.com [137.38.226.97]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id KAA19368
	for <linux-xfs@oss.sgi.com>; Thu, 13 Apr 2000 10:29:34 -0700 (PDT)
	mail_from (cattelan@thebarn.com)
From:   cattelan@thebarn.com
Received: from ironwood-e185.americas.sgi.com (ironwood.cray.com [128.162.185.212]) by ledzep.cray.com (SGI-SGI-8.9.3/craymail-smart-nospam1.0) with ESMTP id MAA43810 for <linux-xfs@oss.sgi.com>; Thu, 13 Apr 2000 12:33:02 -0500 (CDT)
Received: from gibble.americas.sgi.com (root@gibble.americas.sgi.com [128.162.195.80]) by ironwood-e185.americas.sgi.com (8.8.4/SGI-ironwood-e1.4) with ESMTP id MAA27458; Thu, 13 Apr 2000 12:32:53 -0500 (CDT)
Received: from gibble.americas.sgi.com by gibble.americas.sgi.com (8.9.3/SGI-client.1.6) via ESMTP id MAA13412; Thu, 13 Apr 2000 12:32:59 -0500
Date:   Thu, 13 Apr 2000 12:32:57 -0500
Message-ID: <14582.1225.56960.43586R@gibble.americas.sgi.com>
To:     mostek@sgi.com
Cc:     lord@sgi.com, linux-xfs@oss.sgi.com
Subject: Re: XFS as Root filesystem
In-Reply-To: In your message of "Thu, 13 Apr 2000 11:19:00 -0500 (CDT)"
	<200004131619.LAA55955@fsgi344.americas.sgi.com>
References: <200004131528.KAA07085@jen.americas.sgi.com>
	<200004131619.LAA55955@fsgi344.americas.sgi.com>
User-Agent: Wanderlust/1.0.3 (Notorious) tm/7.108 XEmacs/21.1 (Bryce Canyon)
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing

At Thu, 13 Apr 2000 11:19:00 -0500 (CDT),
Jim Mostek <mostek@sgi.com> wrote:
> 
> 
> 
> I would like to see XFS mount as root before we worry about handling a
> read-only device. Also, we need to see how XFS handles "file system
> SHUTDOWN" after the read-only mount. In this case, xfs_repair should be
> run on the file system (instead of fsck) and then mounted. This is the way
> Linux does things, right?
> 
> Once we have root working, let's see what happens on read-only device.
> 
> If XFS burned on a read-only device, recovery should say nothing to do
> and not try to write it. Right?
Just as a FYI 
CD-ROMS require a fixed size block.
the only XFS file system that would work on a CD-ROM would
be 512 byte based.

Or if XFS used all 2k blocks.


> 
> Jim
> 
> >
> >
> >This in itself looks reasonable, but Stephen Tweedie mentioned detecting
> >read only devices and refusing to do the recovery - and that there was
> >code which did this in the latest ext3 cut.
> >
> >Not sure if this is worth following up on with XFS, since XFS refuses
> >to fit on a floppy, it means XFS on an LS120 (or some other media) or
> >someone burned a filesystem needing recovery onto a cdrom. If there is
> >a simple test we can make for read only media then it is probably worth
> >adding, if it is complex then probably not.
> >
> >Steve
> >
> >> On Apr 11, Phil Schwan wrote:
> >> > In somewhat-related news, I have a patch for doing recovery in
> >> > read-only mode that I will test tomorrow.  If it works on both
> >> > internal and external logs, I'll send it along for review.
> >> 
> >> This appears to do the Right Thing.  I flip off the machine in the
> >> middle of a large write, mount it read-only, and it happily plays the
> >> log back (as far as I can tell).  Since I'm still dealing with the
> >> helpdesk to get my internal network access fixed, I'm not sure if
> >> there are "real" log replay tests available.
> >> 
> >> RCS file: /cvs/linux-2.3-xfs/linux/fs/xfs/xfs_log_recover.c,v
> >> retrieving revision 1.170
> >> diff -u -r1.170 xfs_log_recover.c
> >> --- xfs_log_recover.c   2000/04/06 01:26:24     1.170
> >> +++ xfs_log_recover.c   2000/04/13 14:58:00
> >> @@ -3334,6 +3335,7 @@
> >>  {
> >>         daddr_t head_blk, tail_blk;
> >>         int     error;
> >> +       xfs_mount_t *mp;
> >>  
> >>         if (error = xlog_find_tail(log, &head_blk, &tail_blk, readonly))
> >>                 return error;
> >> @@ -3343,13 +3345,24 @@
> >>                 head_blk = HEAD_BLK;
> >>                 tail_blk = TAIL_BLK;
> >>  #endif
> >> -               /*
> >> +
> >> +               /* There used to be a comment here:
> >> +                *
> >>                  * disallow recovery on read-only mounts.  note -- mount
> >>                  * checks for ENOSPC and turns it into an intelligent
> >>                  * error message.
> >> -                */
> >> -               if (readonly)
> >> -                       return ENOSPC;
> >> +                *
> >> +                * ...but this is no longer true.  Now, unless you specify
> >> +                * NORECOVERY (in which case this function would never be
> >> +                * called), it enables read-write access long enough to do
> >> +                * recovery.
> >> +                */
> >> +               if (readonly) {
> >> +                       cmn_err(CE_WARN, "XFS: temporarily enabling read/writ
> >e access for log recovery.\n");
> >> +                       mp = log->l_mp;
> >> +                       XFS_MTOVFS(mp)->vfs_flag &= ~VFS_RDONLY;
> >> +               }
> >> +
> >>  #ifdef _KERNEL
> >>  #if defined(DEBUG) && defined(XFS_LOUD_RECOVERY)
> >>                 cmn_err(CE_NOTE,
> >> @@ -3365,6 +3378,8 @@
> >>  #endif
> >>                 error = xlog_do_recover(log, head_blk, tail_blk);
> >>                 log->l_flags |= XLOG_RECOVERY_NEEDED;
> >> +               if (readonly)
> >> +                       XFS_MTOVFS(mp)->vfs_flag |= VFS_RDONLY;
> >>         }
> >>         return error;
> >>  }      /* xlog_recover */
> >> 
> >> Let me know if you notice trouble--this seems deceptively simple.
> >> 
> >> -Phil
> >
> >

From owner-linux-xfs@oss.sgi.com Thu Apr 13 10:50:34 2000
Received:  by oss.sgi.com id <S305166AbQDMRuZ>;
	Thu, 13 Apr 2000 10:50:25 -0700
Received: from deliverator.sgi.com ([204.94.214.10]:21014 "EHLO
        deliverator.sgi.com") by oss.sgi.com with ESMTP id <S305159AbQDMRuM>;
	Thu, 13 Apr 2000 10:50:12 -0700
Received: from ledzep.cray.com (ledzep.cray.com [137.38.226.97]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id KAA21698
	for <linux-xfs@oss.sgi.com>; Thu, 13 Apr 2000 10:45:28 -0700 (PDT)
	mail_from (cattelan@thebarn.com)
From:   cattelan@thebarn.com
Received: from ironwood-e185.americas.sgi.com (ironwood.cray.com [128.162.185.212]) by ledzep.cray.com (SGI-SGI-8.9.3/craymail-smart-nospam1.0) with ESMTP id MAA09036; Thu, 13 Apr 2000 12:48:55 -0500 (CDT)
Received: from gibble.americas.sgi.com (root@gibble.americas.sgi.com [128.162.195.80]) by ironwood-e185.americas.sgi.com (8.8.4/SGI-ironwood-e1.4) with ESMTP id MAA28064; Thu, 13 Apr 2000 12:48:47 -0500 (CDT)
Received: from gibble.americas.sgi.com by gibble.americas.sgi.com (8.9.3/SGI-client.1.6) via ESMTP id MAA13421; Thu, 13 Apr 2000 12:48:53 -0500
Date:   Thu, 13 Apr 2000 12:48:51 -0500
Message-ID: <14582.2179.583864.62523H@gibble.americas.sgi.com>
To:     phil@linuxcare.com
Cc:     lord@sgi.com, linux-xfs@oss.sgi.com
Subject: Re: XFS as Root filesystem
In-Reply-To: In your message of "Thu, 13 Apr 2000 14:16:57 -0400"
	<20000413141657.C1665@linuxcare.com>
References: <phil@linuxcare.com>
	<200004131528.KAA07085@jen.americas.sgi.com>
	<20000413141657.C1665@linuxcare.com>
User-Agent: Wanderlust/1.0.3 (Notorious) tm/7.108 XEmacs/21.1 (Bryce Canyon)
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing

At Thu, 13 Apr 2000 14:16:57 -0400,
Phil Schwan <phil@linuxcare.com> wrote:
> 
> 
> On Apr 13, Steve Lord wrote:
> > This in itself looks reasonable, but Stephen Tweedie mentioned detecting
> > read only devices and refusing to do the recovery - and that there was
> > code which did this in the latest ext3 cut.
> > 
> > Not sure if this is worth following up on with XFS, since XFS refuses
> > to fit on a floppy, it means XFS on an LS120 (or some other media) or
> > someone burned a filesystem needing recovery onto a cdrom. If there is
> > a simple test we can make for read only media then it is probably worth
> > adding, if it is complex then probably not.
> 
> Here we go, try this out for size.
> 
> By the way, Russell, what's the best way to #include linux/fs.h here?
> I'm still fuzzy on how the new arch-specific #includes work for
> includes that aren't needed by every source file.
First it would be best not to include linux/fs.h in any file
not in the fs/xfs/linux directory. It will cause headaches.

If fact that linux/xfs_sema.h shouldn't be there either.

Second... xfs includes files needed by a particular xfs_*.c
file can be included directly.

If the file is general enough say types.h it can go
in xfs_os_defs.h; I doesn't really hurt if some
*.c files include some header files they don't need.
As long as it doesn't create conflicts.

if you really really need to include fs.h put it
in xfs_os_defs.h  with an
#ifdef NEED_FS_H wrapper.
then define it in what ever file that it is needed.

A better thing to do would be to move any code
that uses linux specific "stuff" into a file in
fs/xfs/linux/ 
Then just insert a function call from wherever.
You may need to make this a macro that calls
X for kernel and nothing for user land.


Remember lib sim compiles in user land and 
typically breaks when  kernel land 
includes are used.




> 
> Index: xfs_log_recover.c
> ===================================================================
> RCS file: /cvs/linux-2.3-xfs/linux/fs/xfs/xfs_log_recover.c,v
> retrieving revision 1.170
> diff -u -r1.170 xfs_log_recover.c
> --- xfs_log_recover.c	2000/04/06 01:26:24	1.170
> +++ xfs_log_recover.c	2000/04/13 17:23:17
> @@ -44,6 +44,7 @@
>  #include <sys/sysmacros.h>
>  #include "xfs_buf.h"
>  #include <linux/xfs_sema.h>
> +#include <linux/fs.h>
>  #include <sys/vnode.h>
>  #include <sys/debug.h>
>  #include <sys/cmn_err.h>
> @@ -3334,6 +3336,7 @@
>  {
>  	daddr_t head_blk, tail_blk;
>  	int	error;
> +	xfs_mount_t *mp;
>  
>  	if (error = xlog_find_tail(log, &head_blk, &tail_blk, readonly))
>  		return error;
> @@ -3343,13 +3346,30 @@
>  		head_blk = HEAD_BLK;
>  		tail_blk = TAIL_BLK;
>  #endif
> -		/*
> +
> +		/* There used to be a comment here:
> +		 *
>  		 * disallow recovery on read-only mounts.  note -- mount
>  		 * checks for ENOSPC and turns it into an intelligent
>  		 * error message.
> -		 */
> -		if (readonly)
> -			return ENOSPC;
> +		 *
> +		 * ...but this is no longer true.  Now, unless you specify
> +		 * NORECOVERY (in which case this function would never be
> +		 * called), it enables read-write access long enough to do
> +		 * recovery.
> +		 */
> +		if (readonly) {
> +			printk(KERN_ERR "XFS: WARNING: recovery required on readonly filesystem.\n");
> +			mp = log->l_mp;
> +			if (is_read_only(mp->m_dev) ||
> +			    is_read_only(mp->m_logdev)) {
> +				printk(KERN_ERR "XFS: write access unavailable, cannot proceed.\n");
> +				return -EROFS;
> +			}
> +			printk(KERN_ERR "XFS: write access will be enabled during recovery.\n");
> +			XFS_MTOVFS(mp)->vfs_flag &= ~VFS_RDONLY;
> +		}
> +
>  #ifdef _KERNEL
>  #if defined(DEBUG) && defined(XFS_LOUD_RECOVERY)
>  		cmn_err(CE_NOTE,
> @@ -3365,6 +3385,8 @@
>  #endif
>  		error = xlog_do_recover(log, head_blk, tail_blk);
>  		log->l_flags |= XLOG_RECOVERY_NEEDED;
> +		if (readonly)
> +			XFS_MTOVFS(mp)->vfs_flag |= VFS_RDONLY;
>  	}
>  	return error;
>  }	/* xlog_recover */
> 
> I have internal access now, thanks to the terrific helpdesk people.
> All rejoice.
> 
> -- 
> Phil Schwan, Captain Popetastic, Linuxcare Canada

From owner-linux-xfs@oss.sgi.com Thu Apr 13 11:04:05 2000
Received:  by oss.sgi.com id <S305166AbQDMSDq>;
	Thu, 13 Apr 2000 11:03:46 -0700
Received: from [216.208.98.2] ([216.208.98.2]:55536 "EHLO moiraine.off.net")
	by oss.sgi.com with ESMTP id <S305159AbQDMSDj>;
	Thu, 13 Apr 2000 11:03:39 -0700
Received: (from phil@localhost)
	by moiraine.off.net (8.9.3/8.9.3) id OAA04533;
	Thu, 13 Apr 2000 14:54:36 -0400
Date:   Thu, 13 Apr 2000 14:54:36 -0400
From:   Phil Schwan <phil@linuxcare.com>
To:     cattelan@thebarn.com
Cc:     linux-xfs@oss.sgi.com
Subject: Re: XFS as Root filesystem
Message-ID: <20000413145436.D1665@linuxcare.com>
References: <phil@linuxcare.com> <200004131528.KAA07085@jen.americas.sgi.com> <20000413141657.C1665@linuxcare.com> <14582.2179.583864.62523H@gibble.americas.sgi.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 0.95.4us
In-Reply-To: <14582.2179.583864.62523H@gibble.americas.sgi.com>; from cattelan@thebarn.com on Thu, Apr 13, 2000 at 12:48:51PM -0500
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing

On Apr 13, cattelan@thebarn.com wrote:
> First it would be best not to include linux/fs.h in any file
> not in the fs/xfs/linux directory. It will cause headaches.
> 
> If fact that linux/xfs_sema.h shouldn't be there either.
> 
> If the file is general enough say types.h it can go
> in xfs_os_defs.h; I doesn't really hurt if some
> *.c files include some header files they don't need.
> As long as it doesn't create conflicts.
> 
> if you really really need to include fs.h put it
> in xfs_os_defs.h  with an
> #ifdef NEED_FS_H wrapper.
> then define it in what ever file that it is needed.

If I were to change this:

#include <xfs_os_defs.h>

#ifdef SIM
#define _KERNEL 1
#define __KERNEL__ 1
#endif

#include <linux/xfs_sema.h>

to this:

#define NEED_XFS_SEMA_H
#include <xfs_os_defs.h>

#ifdef SIM
#define _KERNEL 1
#define __KERNEL__ 1
#endif

it wouldn't do the Right Thing in the SIM case, would it?

-Phil

-- 
Phil Schwan, Captain Popetastic, Linuxcare Canada

From owner-linux-xfs@oss.sgi.com Thu Apr 13 11:17:25 2000
Received:  by oss.sgi.com id <S305166AbQDMSRG>;
	Thu, 13 Apr 2000 11:17:06 -0700
Received: from deliverator.sgi.com ([204.94.214.10]:9246 "EHLO
        deliverator.sgi.com") by oss.sgi.com with ESMTP id <S305159AbQDMSQr>;
	Thu, 13 Apr 2000 11:16:47 -0700
Received: from ledzep.cray.com (ledzep.cray.com [137.38.226.97]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id LAA25512
	for <linux-xfs@oss.sgi.com>; Thu, 13 Apr 2000 11:12:04 -0700 (PDT)
	mail_from (lord@sgi.com)
Received: from ironwood-e185.americas.sgi.com (ironwood.cray.com [128.162.185.212]) by ledzep.cray.com (SGI-SGI-8.9.3/craymail-smart-nospam1.0) with ESMTP id NAA84154; Thu, 13 Apr 2000 13:15:30 -0500 (CDT)
Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.184.86]) by ironwood-e185.americas.sgi.com (8.8.4/SGI-ironwood-e1.4) with ESMTP id NAA29660; Thu, 13 Apr 2000 13:15:22 -0500 (CDT)
Received: from jen.americas.sgi.com by jen.americas.sgi.com (8.9.3/SGI-client.1.6) via ESMTP id NAA07305; Thu, 13 Apr 2000 13:15:17 -0500
Message-Id: <200004131815.NAA07305@jen.americas.sgi.com>
X-Mailer: exmh version 2.1.1 10/15/1999
To:     cattelan@thebarn.com, linux-xfs@oss.sgi.com
Subject: Re: XFS as Root filesystem 
In-Reply-To: Message from Phil Schwan <phil@linuxcare.com> 
   of "Thu, 13 Apr 2000 14:54:36 EDT." <20000413145436.D1665@linuxcare.com> 
Date:   Thu, 13 Apr 2000 13:15:16 -0500
From:   Steve Lord <lord@sgi.com>
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing

> On Apr 13, cattelan@thebarn.com wrote:
> > First it would be best not to include linux/fs.h in any file
> > not in the fs/xfs/linux directory. It will cause headaches.
> > 
> > If fact that linux/xfs_sema.h shouldn't be there either.
> > 
> > If the file is general enough say types.h it can go
> > in xfs_os_defs.h; I doesn't really hurt if some
> > *.c files include some header files they don't need.
> > As long as it doesn't create conflicts.
> > 


Have you run cscope recently:

Files #including this file: xfs_sema.h

  File                      Line
1 fs/xfs/xfsquotasstubs.c    84 #include <linux/xfs_sema.h>
2 fs/xfs/xfs_bmap.c          40 #include <linux/xfs_sema.h>
3 fs/xfs/xfs_buf.h           48 #include <linux/xfs_sema.h>
4 fs/xfs/xfs_buf.h          289 #include <linux/xfs_sema.h>
5 fs/xfs/xfs_log_print.c     51 #include <linux/xfs_sema.h>
7 fs/xfs/xfs_grio.c          41 #include <linux/xfs_sema.h>
8 fs/xfs/xfs_mount.c         51 #include <linux/xfs_sema.h>
9 xfs/linux/xfs_vnode.c      47 #include <linux/xfs_sema.h>
1 pseudo-inc/sys/sema_priva  50 #include <linux/xfs_sema.h>
2 pseudo-inc/ksys/behavior. 150 #include <linux/xfs_sema.h>
3 fs/xfs/xfs_dfrag.c         39 #include <linux/xfs_sema.h>
4 xfs/linux/xfs_random.c    155 #include <linux/xfs_sema.h>
5 fs/xfs/xfs_iocore.c        62 #include <linux/xfs_sema.h>
6 fs/xfs/xfs_vfsops.c        70 #include <linux/xfs_sema.h>
7 pseudo-inc/sys/vfs.h       75 #include <linux/xfs_sema.h>
8 pseudo-inc/ksys/kqueue.h   57 #include <linux/xfs_sema.h>
9 xfs/linux/xfs_fs_bio.c     47 #include <linux/xfs_sema.h>
1 fs/xfs/xfs_itable.c        41 #include <linux/xfs_sema.h>
2 fs/xfs/xfs_log_recover.c   46 #include <linux/xfs_sema.h>
3 fs/xfs/xfs_vnodeops.c      73 #include <linux/xfs_sema.h>
4 pseudo-inc/sys/vnode.h     68 #include <linux/xfs_sema.h>
5 fs/xfs/xfs_rw.c            54 #include <linux/xfs_sema.h>
6 pseudo-inc/sys/buf.h       63 #include <linux/xfs_sema.h>
7 fs/xfs/xfs_log.c           64 #include <linux/xfs_sema.h>
8 xfs/linux/xfs_uuid.c       73 #include <linux/xfs_sema.h>
9 fs/xfs/xfs_fsops.c         41 #include <linux/xfs_sema.h>
1 fs/xfs/xfs_macros.c        43 #include <linux/xfs_sema.h>

And:

Files #including this file: linux/fs.h
4 fs/xfs/xfs_vfsops.c        41 #include <linux/fs.h>

And pseudo-inc/sys/capability.h (included by a number of files) includes

#include <linux/capability.h>
#include <linux/sched.h>

and linux/capability.h includes fs.h


Changing one occurrence is not going to make a difference at the moment.

Steve



From owner-linux-xfs@oss.sgi.com Thu Apr 13 11:28:56 2000
Received:  by oss.sgi.com id <S305166AbQDMS2q>;
	Thu, 13 Apr 2000 11:28:46 -0700
Received: from deliverator.sgi.com ([204.94.214.10]:4129 "EHLO
        deliverator.sgi.com") by oss.sgi.com with ESMTP id <S305159AbQDMS2b>;
	Thu, 13 Apr 2000 11:28:31 -0700
Received: from ledzep.cray.com (ledzep.cray.com [137.38.226.97]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id LAA26999
	for <linux-xfs@oss.sgi.com>; Thu, 13 Apr 2000 11:23:47 -0700 (PDT)
	mail_from (cattelan@thebarn.com)
From:   cattelan@thebarn.com
Received: from ironwood-e185.americas.sgi.com (ironwood.cray.com [128.162.185.212]) by ledzep.cray.com (SGI-SGI-8.9.3/craymail-smart-nospam1.0) with ESMTP id NAA70469 for <linux-xfs@oss.sgi.com>; Thu, 13 Apr 2000 13:27:13 -0500 (CDT)
Received: from gibble.americas.sgi.com (root@gibble.americas.sgi.com [128.162.195.80]) by ironwood-e185.americas.sgi.com (8.8.4/SGI-ironwood-e1.4) with ESMTP id NAA00483; Thu, 13 Apr 2000 13:27:04 -0500 (CDT)
Received: from gibble.americas.sgi.com by gibble.americas.sgi.com (8.9.3/SGI-client.1.6) via ESMTP id NAA13471; Thu, 13 Apr 2000 13:27:11 -0500
Date:   Thu, 13 Apr 2000 13:27:07 -0500
Message-ID: <14582.4475.827772.89277X@gibble.americas.sgi.com>
To:     lord@sgi.com
Cc:     linux-xfs@oss.sgi.com
Subject: Re: XFS as Root filesystem 
In-Reply-To: In your message of "Thu, 13 Apr 2000 13:15:16 -0500"
	<200004131815.NAA07305@jen.americas.sgi.com>
References: <phil@linuxcare.com>
	<20000413145436.D1665@linuxcare.com>
	<200004131815.NAA07305@jen.americas.sgi.com>
User-Agent: Wanderlust/1.0.3 (Notorious) tm/7.108 XEmacs/21.1 (Bryce Canyon)
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing

At Thu, 13 Apr 2000 13:15:16 -0500,
Steve Lord <lord@sgi.com> wrote:
> 
> 
> > On Apr 13, cattelan@thebarn.com wrote:
> > > First it would be best not to include linux/fs.h in any file
> > > not in the fs/xfs/linux directory. It will cause headaches.
> > > 
> > > If fact that linux/xfs_sema.h shouldn't be there either.
> > > 
> > > If the file is general enough say types.h it can go
> > > in xfs_os_defs.h; I doesn't really hurt if some
> > > *.c files include some header files they don't need.
> > > As long as it doesn't create conflicts.
> > > 

Yes I know... it's on my list of things to fix.
not that high a priority right now.

It's not a huge deal right right but as long a
Phil is asking about things; lets try and keep
things clean rather than create more stuff we
have to go back and fix up.

> 
> 
> Have you run cscope recently:
> 
> Files #including this file: xfs_sema.h
> 
>   File                      Line
> 1 fs/xfs/xfsquotasstubs.c    84 #include <linux/xfs_sema.h>
> 2 fs/xfs/xfs_bmap.c          40 #include <linux/xfs_sema.h>
> 3 fs/xfs/xfs_buf.h           48 #include <linux/xfs_sema.h>
> 4 fs/xfs/xfs_buf.h          289 #include <linux/xfs_sema.h>
> 5 fs/xfs/xfs_log_print.c     51 #include <linux/xfs_sema.h>
> 7 fs/xfs/xfs_grio.c          41 #include <linux/xfs_sema.h>
> 8 fs/xfs/xfs_mount.c         51 #include <linux/xfs_sema.h>
> 9 xfs/linux/xfs_vnode.c      47 #include <linux/xfs_sema.h>
> 1 pseudo-inc/sys/sema_priva  50 #include <linux/xfs_sema.h>
> 2 pseudo-inc/ksys/behavior. 150 #include <linux/xfs_sema.h>
> 3 fs/xfs/xfs_dfrag.c         39 #include <linux/xfs_sema.h>
> 4 xfs/linux/xfs_random.c    155 #include <linux/xfs_sema.h>
> 5 fs/xfs/xfs_iocore.c        62 #include <linux/xfs_sema.h>
> 6 fs/xfs/xfs_vfsops.c        70 #include <linux/xfs_sema.h>
> 7 pseudo-inc/sys/vfs.h       75 #include <linux/xfs_sema.h>
> 8 pseudo-inc/ksys/kqueue.h   57 #include <linux/xfs_sema.h>
> 9 xfs/linux/xfs_fs_bio.c     47 #include <linux/xfs_sema.h>
> 1 fs/xfs/xfs_itable.c        41 #include <linux/xfs_sema.h>
> 2 fs/xfs/xfs_log_recover.c   46 #include <linux/xfs_sema.h>
> 3 fs/xfs/xfs_vnodeops.c      73 #include <linux/xfs_sema.h>
> 4 pseudo-inc/sys/vnode.h     68 #include <linux/xfs_sema.h>
> 5 fs/xfs/xfs_rw.c            54 #include <linux/xfs_sema.h>
> 6 pseudo-inc/sys/buf.h       63 #include <linux/xfs_sema.h>
> 7 fs/xfs/xfs_log.c           64 #include <linux/xfs_sema.h>
> 8 xfs/linux/xfs_uuid.c       73 #include <linux/xfs_sema.h>
> 9 fs/xfs/xfs_fsops.c         41 #include <linux/xfs_sema.h>
> 1 fs/xfs/xfs_macros.c        43 #include <linux/xfs_sema.h>
> 
> And:
> 
> Files #including this file: linux/fs.h
> 4 fs/xfs/xfs_vfsops.c        41 #include <linux/fs.h>
> 
> And pseudo-inc/sys/capability.h (included by a number of files) includes
> 
> #include <linux/capability.h>
> #include <linux/sched.h>
> 
> and linux/capability.h includes fs.h
> 
> 
> Changing one occurrence is not going to make a difference at the moment.
> 
> Steve

From owner-linux-xfs@oss.sgi.com Thu Apr 13 11:35:06 2000
Received:  by oss.sgi.com id <S305166AbQDMSe4>;
	Thu, 13 Apr 2000 11:34:56 -0700
Received: from pneumatic-tube.sgi.com ([204.94.214.22]:37199 "EHLO
        pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP
	id <S305159AbQDMSei>; Thu, 13 Apr 2000 11:34:38 -0700
Received: from ledzep.cray.com (ledzep.cray.com [137.38.226.97]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id LAA04534
	for <linux-xfs@oss.sgi.com>; Thu, 13 Apr 2000 11:38:32 -0700 (PDT)
	mail_from (cattelan@thebarn.com)
From:   cattelan@thebarn.com
Received: from ironwood-e185.americas.sgi.com (ironwood.cray.com [128.162.185.212]) by ledzep.cray.com (SGI-SGI-8.9.3/craymail-smart-nospam1.0) with ESMTP id NAA86251; Thu, 13 Apr 2000 13:33:20 -0500 (CDT)
Received: from gibble.americas.sgi.com (root@gibble.americas.sgi.com [128.162.195.80]) by ironwood-e185.americas.sgi.com (8.8.4/SGI-ironwood-e1.4) with ESMTP id NAA00799; Thu, 13 Apr 2000 13:33:12 -0500 (CDT)
Received: from gibble.americas.sgi.com by gibble.americas.sgi.com (8.9.3/SGI-client.1.6) via ESMTP id NAA13498; Thu, 13 Apr 2000 13:33:19 -0500
Date:   Thu, 13 Apr 2000 13:33:17 -0500
Message-ID: <14582.4845.421234.35683M@gibble.americas.sgi.com>
To:     phil@linuxcare.com
Cc:     linux-xfs@oss.sgi.com
Subject: Re: XFS as Root filesystem
In-Reply-To: In your message of "Thu, 13 Apr 2000 14:54:36 -0400"
	<20000413145436.D1665@linuxcare.com>
References: <phil@linuxcare.com>
	<200004131528.KAA07085@jen.americas.sgi.com>
	<20000413141657.C1665@linuxcare.com>
	<14582.2179.583864.62523H@gibble.americas.sgi.com>
	<20000413145436.D1665@linuxcare.com>
User-Agent: Wanderlust/1.0.3 (Notorious) tm/7.108 XEmacs/21.1 (Bryce Canyon)
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing

At Thu, 13 Apr 2000 14:54:36 -0400,
Phil Schwan <phil@linuxcare.com> wrote:
> 
> 
> On Apr 13, cattelan@thebarn.com wrote:
> > First it would be best not to include linux/fs.h in any file
> > not in the fs/xfs/linux directory. It will cause headaches.
> > 
> > If fact that linux/xfs_sema.h shouldn't be there either.
> > 
> > If the file is general enough say types.h it can go
> > in xfs_os_defs.h; I doesn't really hurt if some
> > *.c files include some header files they don't need.
> > As long as it doesn't create conflicts.
> > 
> > if you really really need to include fs.h put it
> > in xfs_os_defs.h  with an
> > #ifdef NEED_FS_H wrapper.
> > then define it in what ever file that it is needed.
> 
> If I were to change this:
> 
> #include <xfs_os_defs.h>
> 
> #ifdef SIM
> #define _KERNEL 1
> #define __KERNEL__ 1
> #endif
> 
> #include <linux/xfs_sema.h>
> 
> to this:
> 
> #define NEED_XFS_SEMA_H
> #include <xfs_os_defs.h>
> 
> #ifdef SIM
> #define _KERNEL 1
> #define __KERNEL__ 1
> #endif
> 
> it wouldn't do the Right Thing in the SIM case, would it?
> 
The first thing xfs_os_defs.h will need is
#ifdef SIM
#define _KERNEL 1
#define __KERNEL__ 1
#endif

in the xfs_sema.h case we may not need to wrap it with the
ifdef... since it may not cause compile problems.

linux/fs.h can cause problem if includede in the wrong files.


The goal here is put as much common or problem header files in 
one spot such that they can be controlled with ifdef switches.

There is a lot work that needs to be done in this area, but
it is cleanliness issues and not functionality issues, the 
functionality is taking presidence. 


-Me

From owner-linux-xfs@oss.sgi.com Thu Apr 13 14:11:02 2000
Received:  by oss.sgi.com id <S305166AbQDMVKm>;
	Thu, 13 Apr 2000 14:10:42 -0700
Received: from deliverator.sgi.com ([204.94.214.10]:63561 "EHLO
        deliverator.sgi.com") by oss.sgi.com with ESMTP id <S305159AbQDMVKY>;
	Thu, 13 Apr 2000 14:10:24 -0700
Received: from ledzep.cray.com (ledzep.cray.com [137.38.226.97]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id OAA16672
	for <linux-xfs@oss.sgi.com>; Thu, 13 Apr 2000 14:05:36 -0700 (PDT)
	mail_from (jtk@sgi.com)
Received: from ironwood-e185.americas.sgi.com (ironwood.cray.com [128.162.185.212]) by ledzep.cray.com (SGI-SGI-8.9.3/craymail-smart-nospam1.0) with ESMTP id QAA83542; Thu, 13 Apr 2000 16:07:46 -0500 (CDT)
Received: from tiki.americas.sgi.com (tiki.americas.sgi.com [128.162.195.11]) by ironwood-e185.americas.sgi.com (8.8.4/SGI-ironwood-e1.4) with ESMTP id QAA09817; Thu, 13 Apr 2000 16:07:39 -0500 (CDT)
From:   Ted Kline <jtk@sgi.com>
Received: by tiki.americas.sgi.com (980427.SGI.8.8.8/SGI-client.1.6) id QAA21776; Thu, 13 Apr 2000 16:07:45 -0500 (CDT)
Message-Id: <200004132107.QAA21776@tiki.americas.sgi.com>
Date:   Thu, 13 Apr 2000 16:07:45 -0500 (CDT)
To:     slinx-xfs@engr.sgi.com, linux-xfs@oss.sgi.com
Subject: TAKE - More XFS ioctl interfaces.
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing


Implement path_to_fshandle(), fd_to_handle(), path_to_handle(),
open_by_handle(), readlink_by_handle(), bulkstat() &
bulkstat_single() as XFS ioctl interfaces.

NOTE! User level commands using the previous ioctl numbers will
      need to be rebuilt, in particular xfs_bmap.

Implement a rudimentary "*by_handle*" user-level library for
use by the cmd/xfs complex.

Port over the xfs_bstat bulkstat test/verification program.


Modid:  2.3.99pre2-xfs:slinx:57940a
Date:  Thu Apr 13 14:02:31 PDT 2000
Workarea:  tiki.americas.sgi.com:/data/clink/io/jtk/work-linux2.3-99

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

cmd/xfs/Makefile - 1.7
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/cmd/xfs/Makefile.diff?r1=text&tr1=1.7&r2=text&tr2=1.6&f=h
	- Add "handle" & "bstat" subdirectories.

cmd/xfs/mkfile/xfs_mkfile.c - 1.3
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/cmd/xfs/mkfile/xfs_mkfile.c.diff?r1=text&tr1=1.3&r2=text&tr2=1.2&f=h
	- Type changes, use loff_t instead of off64_t to keep
	  away from kernel includes.

linux/fs/xfs/linux/xfs_file.c - 1.26
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/linux/fs/xfs/linux/xfs_file.c.diff?r1=text&tr1=1.26&r2=text&tr2=1.25&f=h
	- Add linvfs_ioctl(), a layer routine that invokes
	  VOP_IOCTL.

linux/fs/xfs/linux/xfs_ioctl.c - 1.4
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/linux/fs/xfs/linux/xfs_ioctl.c.diff?r1=text&tr1=1.4&r2=text&tr2=1.3&f=h
	- Implement path_to_fshandle(), fd_to_handle(), path_to_handle(),
	  open_by_handle(), readlink_by_handle(), bulkstat() &
	  bulkstat_single() ioctl routines.

linux/fs/xfs/pseudo-inc/sys/vnode.h - 1.19
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/linux/fs/xfs/pseudo-inc/sys/vnode.h.diff?r1=text&tr1=1.19&r2=text&tr2=1.18&f=h
	- Add VOP_IOCTL.

linux/fs/xfs/xfs_buf.h - 1.47
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/linux/fs/xfs/xfs_buf.h.diff?r1=text&tr1=1.47&r2=text&tr2=1.46&f=h
	- Quiet compiler warning about pdflush.

linux/fs/xfs/xfs_icrash.c - 1.15
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/linux/fs/xfs/xfs_icrash.c.diff?r1=text&tr1=1.15&r2=text&tr2=1.14&f=h
	- Remove xfs_fid2 reference.

linux/fs/xfs/xfs_iget.c - 1.114
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/linux/fs/xfs/xfs_iget.c.diff?r1=text&tr1=1.114&r2=text&tr2=1.113&f=h
	- Fill in v_nodeid on an xfs_iget.

linux/fs/xfs/xfs_inode.h - 1.133
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/linux/fs/xfs/xfs_inode.h.diff?r1=text&tr1=1.133&r2=text&tr2=1.132&f=h
	- Move all the "fid" definitions out of here into xfs_fs.h.

linux/fs/xfs/xfs_itable.c - 1.82
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/linux/fs/xfs/xfs_itable.c.diff?r1=text&tr1=1.82&r2=text&tr2=1.81&f=h
	- Remove "STATIC" from xfs_bulkstat_single() & xfs_bulkstat_one().

linux/fs/xfs/xfs_itable.h - 1.29
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/linux/fs/xfs/xfs_itable.h.diff?r1=text&tr1=1.29&r2=text&tr2=1.28&f=h
	- Move all of the "bulkstat" interface definitions out
	  of here into xfs_fs.h.

linux/fs/xfs/xfs_vnodeops.c - 1.451
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/linux/fs/xfs/xfs_vnodeops.c.diff?r1=text&tr1=1.451&r2=text&tr2=1.450&f=h
	- Add xfs_ioctl() to the vnodeops vector.

linux/include/linux/xfs_fs.h - 1.4
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/linux/include/linux/xfs_fs.h.diff?r1=text&tr1=1.4&r2=text&tr2=1.3&f=h
	- Completely change all structure interface definitions
	  to "unambivalent" typing.
	  Move in "fid" and "bulkstat" interface structures.
	  Correct some overlapping IOC numbering.

linux/kdb/modules/kdbm_pb.c - 1.13
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/linux/kdb/modules/kdbm_pb.c.diff?r1=text&tr1=1.13&r2=text&tr2=1.12&f=h
	- Expand the 'inode' kdb display.

linux/kdb/modules/kdbm_vm.c - 1.3
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/linux/kdb/modules/kdbm_vm.c.diff?r1=text&tr1=1.3&r2=text&tr2=1.2&f=h
	- Expand the 'filp' kdb display, add a 'dentry' kdb command.

linux/kernel/ksyms.c - 1.39
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/linux/kernel/ksyms.c.diff?r1=text&tr1=1.39&r2=text&tr2=1.38&f=h
	- Export 'file_move' & 'put_unused_fd' for usage
	  by the "*by_handle*" routines.

cmd/xfs/bstat/Makefile - 1.1
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/cmd/xfs/bstat/Makefile.diff?r1=text&tr1=1.1&r2=text&tr2=1.0&f=h
cmd/xfs/bstat/jdm.c - 1.1
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/cmd/xfs/bstat/jdm.c.diff?r1=text&tr1=1.1&r2=text&tr2=1.0&f=h
cmd/xfs/bstat/jdm.h - 1.1
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/cmd/xfs/bstat/jdm.h.diff?r1=text&tr1=1.1&r2=text&tr2=1.0&f=h
cmd/xfs/bstat/xfs_bstat.c - 1.1
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/cmd/xfs/bstat/xfs_bstat.c.diff?r1=text&tr1=1.1&r2=text&tr2=1.0&f=h
	- Port over the "bulkstat" test/verification command.

cmd/xfs/handle/Makefile - 1.1
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/cmd/xfs/handle/Makefile.diff?r1=text&tr1=1.1&r2=text&tr2=1.0&f=h
cmd/xfs/handle/handle.c - 1.1
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/cmd/xfs/handle/handle.c.diff?r1=text&tr1=1.1&r2=text&tr2=1.0&f=h
	- Port over/re-work the "*by_handle*" user interface library.


From owner-linux-xfs@oss.sgi.com Thu Apr 13 16:32:24 2000
Received:  by oss.sgi.com id <S305166AbQDMXcE>;
	Thu, 13 Apr 2000 16:32:04 -0700
Received: from deliverator.sgi.com ([204.94.214.10]:45675 "EHLO
        deliverator.sgi.com") by oss.sgi.com with ESMTP id <S305159AbQDMXbe>;
	Thu, 13 Apr 2000 16:31:34 -0700
Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via SMTP id QAA03838
	for <linux-xfs@oss.sgi.com>; Thu, 13 Apr 2000 16:26:49 -0700 (PDT)
	mail_from (dxm@snort.melbourne.sgi.com)
Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.55.149]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id JAA27051 for <@larry.melbourne.sgi.com:linux-xfs@oss.sgi.com>; Fri, 14 Apr 2000 09:30:16 +1000
Received: (from dxm@localhost) by snort.melbourne.sgi.com (980427.SGI.8.8.8/980728.SGI.AUTOCF) id JAA22592 for linux-xfs@oss.sgi.com; Fri, 14 Apr 2000 09:30:14 +1000 (EST)
Date:   Fri, 14 Apr 2000 09:30:14 +1000 (EST)
From:   dxm@snort.melbourne.sgi.com (Daniel Moore)
Message-Id: <200004132330.JAA22592@snort.melbourne.sgi.com>
To:     linux-xfs@oss.sgi.com
Subject: TAKE - debug output changes for mangle
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing

forgotten checkin

Modid:  2.3.99pre2-xfs:slinx:57966a
Date:  Thu Apr 13 16:29:46 PDT 2000
Workarea:  snort:/build1/people/dxm/isms/slinx-xfs

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

cmd/xfs/mangle/inodes.c - 1.5
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/cmd/xfs/mangle/inodes.c.diff?r1=text&tr1=1.5&r2=text&tr2=1.4&f=h
	- debug output changes


From owner-linux-xfs@oss.sgi.com Thu Apr 13 16:33:54 2000
Received:  by oss.sgi.com id <S305169AbQDMXde>;
	Thu, 13 Apr 2000 16:33:34 -0700
Received: from pneumatic-tube.sgi.com ([204.94.214.22]:16496 "EHLO
        pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP
	id <S305159AbQDMXd0>; Thu, 13 Apr 2000 16:33:26 -0700
Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via SMTP id QAA04937
	for <linux-xfs@oss.sgi.com>; Thu, 13 Apr 2000 16:37:19 -0700 (PDT)
	mail_from (dxm@snort.melbourne.sgi.com)
Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.55.149]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id JAA27057 for <@larry.melbourne.sgi.com:linux-xfs@oss.sgi.com>; Fri, 14 Apr 2000 09:32:07 +1000
Received: (from dxm@localhost) by snort.melbourne.sgi.com (980427.SGI.8.8.8/980728.SGI.AUTOCF) id JAA80623 for linux-xfs@oss.sgi.com; Fri, 14 Apr 2000 09:32:07 +1000 (EST)
Date:   Fri, 14 Apr 2000 09:32:07 +1000 (EST)
From:   dxm@snort.melbourne.sgi.com (Daniel Moore)
Message-Id: <200004132332.JAA80623@snort.melbourne.sgi.com>
To:     linux-xfs@oss.sgi.com
Subject: TAKE - as above
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing

more forgotten changes

Modid:  2.3.99pre2-xfs:slinx:57967a
Date:  Thu Apr 13 16:31:49 PDT 2000
Workarea:  snort:/build1/people/dxm/isms/slinx-xfs

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

cmd/xfs/mangle/sf.c - 1.4
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/cmd/xfs/mangle/sf.c.diff?r1=text&tr1=1.4&r2=text&tr2=1.3&f=h
cmd/xfs/mangle/sf.h - 1.3
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/cmd/xfs/mangle/sf.h.diff?r1=text&tr1=1.3&r2=text&tr2=1.2&f=h
	- debug output changes


From owner-linux-xfs@oss.sgi.com Thu Apr 13 21:37:35 2000
Received:  by oss.sgi.com id <S305170AbQDNEhQ>;
	Thu, 13 Apr 2000 21:37:16 -0700
Received: from deliverator.sgi.com ([204.94.214.10]:16926 "EHLO
        deliverator.sgi.com") by oss.sgi.com with ESMTP id <S305159AbQDNEgw>;
	Thu, 13 Apr 2000 21:36:52 -0700
Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via SMTP id VAA26088
	for <linux-xfs@oss.sgi.com>; Thu, 13 Apr 2000 21:32:06 -0700 (PDT)
	mail_from (dxm@snort.melbourne.sgi.com)
Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.55.149]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id OAA29128 for <@larry.melbourne.sgi.com:linux-xfs@oss.sgi.com>; Fri, 14 Apr 2000 14:34:18 +1000
Received: (from dxm@localhost) by snort.melbourne.sgi.com (980427.SGI.8.8.8/980728.SGI.AUTOCF) id OAA59651 for linux-xfs@oss.sgi.com; Fri, 14 Apr 2000 14:34:13 +1000 (EST)
Date:   Fri, 14 Apr 2000 14:34:13 +1000 (EST)
From:   dxm@snort.melbourne.sgi.com (Daniel Moore)
Message-Id: <200004140434.OAA59651@snort.melbourne.sgi.com>
To:     linux-xfs@oss.sgi.com
Subject: TAKE - teeny arch bug
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing

Modid:  2.3.99pre2-xfs:slinx:57977a
Date:  Thu Apr 13 21:33:55 PDT 2000
Workarea:  snort:/build1/people/dxm/isms/slinx-xfs

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

linux/fs/xfs/xfsidbg.c - 1.133
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/linux/fs/xfs/xfsidbg.c.diff?r1=text&tr1=1.133&r2=text&tr2=1.132&f=h
	- teeny bug


From owner-linux-xfs@oss.sgi.com Fri Apr 14 01:04:16 2000
Received:  by oss.sgi.com id <S305172AbQDNIEH>;
	Fri, 14 Apr 2000 01:04:07 -0700
Received: from plutonium.uunet.be ([194.7.15.87]:56844 "EHLO
        plutonium.uunet.be") by oss.sgi.com with ESMTP id <S305159AbQDNIDs>;
	Fri, 14 Apr 2000 01:03:48 -0700
Received: from gate.vum.be (firewall.vum.be [194.7.240.162])
	by plutonium.uunet.be (8.9.1/8.9.3) with SMTP id KAA02455
	for <linux-xfs@oss.sgi.com>; Fri, 14 Apr 2000 10:03:43 +0200 (CEST)
Received: from pcgx14500003.vum.be (pcgx14500003 [83.105.1.4]) by vum.be with ESMTP (8.7.6/8.7.3) id KAA23675 for <linux-xfs@oss.sgi.com>; Fri, 14 Apr 2000 10:03:48 +0200 (METDST)
Received: from pcgx14500003.vum.be (IDENT:kris@localhost.localdomain [127.0.0.1])
	by pcgx14500003.vum.be (8.9.3/8.8.7) with SMTP id KAA06463
	for <linux-xfs@oss.sgi.com>; Fri, 14 Apr 2000 10:03:13 +0200
From:   kris <gast6@vum.be>
Organization: vum
To:     linux-xfs@oss.sgi.com
Subject: cvs tree problems
Date:   Fri, 14 Apr 2000 10:01:41 +0200
X-Mailer: KMail [version 1.0.28]
Content-Type: text/plain
MIME-Version: 1.0
Message-Id: <00041410031200.03427@pcgx14500003.vum.be>
Content-Transfer-Encoding: 8bit
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing

I got problems updating ...
following error occurs : 

cvs server: Updating linux-2.3-xfs/cmd/xfs/bstat
cvs server: failed to create lock directory in repository `/cvs/linux-2.3-xfs/cmd/xfs/bstat': Permission denied
cvs server: failed to obtain dir lock in repository `/cvs/linux-2.3-xfs/cmd/xfs/bstat'
cvs [server aborted]: read lock failed - giving up

                                      

From owner-linux-xfs@oss.sgi.com Fri Apr 14 04:49:07 2000
Received:  by oss.sgi.com id <S305174AbQDNLs5>;
	Fri, 14 Apr 2000 04:48:57 -0700
Received: from expanse.dds.nl ([194.109.10.118]:16915 "EHLO expanse.dds.nl")
	by oss.sgi.com with ESMTP id <S305159AbQDNLsr>;
	Fri, 14 Apr 2000 04:48:47 -0700
Received: (from ookhoi@localhost)
	by expanse.dds.nl (8.9.3/8.9.3) id NAA11610;
	Fri, 14 Apr 2000 13:48:26 +0200
Date:   Fri, 14 Apr 2000 13:48:26 +0200
From:   Ookhoi <ookhoi@dds.nl>
To:     linux-xfs@oss.sgi.com, reiserfs@devlinux.com
Subject: XFS, ReiserFS or ext3?
Message-ID: <20000414134826.V28226@ookhoi.dds.nl>
Reply-To: ookhoi@dds.nl
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 1.0pre2i
X-Uptime: 9:30am  up 13 days, 21:18, 33 users,  load average: 0.63, 1.91, 4.24
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing

Hi!

We now have several journaling file systems, like XFS, ReiserFS and
ext3 (and more I believe, but I would like to concentrate on these
three). 
I have played with ext3 a few weeks ago, which was oke (easy to install
and if I unplugged the machine, it was up and running (fine) in no time
just the way sysadmins like it. :-)

Now it seemes to me that ReiserFS has a larger developer base and aims
a bit higher than ext3. Is that true? If not, what is the difference
between ext3 and ReiserFS?
ReiserFS seemes to be a good choice for spool directories because it
can handle a _huge_ amount of files (and dirs) in a dir efficiently.

And there is XFS. What is the advantage or disadvantage of XFS compared
to ext3 and/or ReiserFS? It seemes to me that XFS is a bit less stable
than the others at this moment. Is that true? XFS exists for some time
now. Is that an advantage above ReiserFS because it had more time to
develop itself to what is is now, or is ReiserFS 'better' because it
doesn't have to carry its history and doesn't have to be backwards
compatible?

Please enlighten me. :-)

		Ookhoi

From owner-linux-xfs@oss.sgi.com Fri Apr 14 07:06:18 2000
Received:  by oss.sgi.com id <S305174AbQDNOGJ>;
	Fri, 14 Apr 2000 07:06:09 -0700
Received: from deliverator.sgi.com ([204.94.214.10]:1893 "EHLO
        deliverator.sgi.com") by oss.sgi.com with ESMTP id <S305159AbQDNOFu>;
	Fri, 14 Apr 2000 07:05:50 -0700
Received: from ledzep.cray.com (ledzep.cray.com [137.38.226.97]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id HAA27794
	for <linux-xfs@oss.sgi.com>; Fri, 14 Apr 2000 07:01:06 -0700 (PDT)
	mail_from (mostek@sgi.com)
Received: from ironwood-e185.americas.sgi.com (ironwood.cray.com [128.162.185.212]) by ledzep.cray.com (SGI-SGI-8.9.3/craymail-smart-nospam1.0) with ESMTP id JAA94386; Fri, 14 Apr 2000 09:03:16 -0500 (CDT)
Received: from fsgi344.americas.sgi.com (fsgi344.americas.sgi.com [128.162.184.15]) by ironwood-e185.americas.sgi.com (8.8.4/SGI-ironwood-e1.4) with ESMTP id JAA23968; Fri, 14 Apr 2000 09:03:09 -0500 (CDT)
From:   Jim Mostek <mostek@sgi.com>
Received: by fsgi344.americas.sgi.com (980427.SGI.8.8.8/SGI-client.1.6) id JAA57968; Fri, 14 Apr 2000 09:03:15 -0500 (CDT)
Message-Id: <200004141403.JAA57968@fsgi344.americas.sgi.com>
Subject: Re: XFS, ReiserFS or ext3?
To:     ookhoi@dds.nl
Date:   Fri, 14 Apr 2000 09:03:14 -0500 (CDT)
Cc:     linux-xfs@oss.sgi.com, reiserfs@devlinux.com
In-Reply-To: <20000414134826.V28226@ookhoi.dds.nl> from "Ookhoi" at Apr 14, 2000 01:48:26 PM
X-Mailer: ELM [version 2.5 PL2]
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing


I haven't played with ReiserFS but from what I've read/heard, my guess
is that it will do small files really well. XFS' directories can
also handle many entries, but ReiserFS with its packing and data in the
inode can handle small files better. But, I don't know how ReiserFS will
do when many processes are hitting the same directory on a multi-CPU
system. XFS has had lots of work done in this area since we have many
customer running old sendmail which does all its file work in the same
directory.

For information on XFS, see http://oss.sgi.com/projects/xfs.
The main design goals of XFS are very large storage, scalability, and
journaling. XFS is much more than just a file system with journaling.
If you are running with several processors and/or pushing lots of large
files/data around, I suspect that XFS will be the best.

In the short term, XFS is still in pre-beta form and beta won't be for a
couple of months, yet. The current schedule has a production quality version of
XFS available later this summer (northern hemisphere).

XFS will have additional capabilities that the other file system you
mentioned don't have such as Direct I/O and extended attributes. At least
I haven't heard that others are adding these.

Longer term, it appears that the Linux community will have a rich set
of file systems available. These can be downloaded and analyzed.
I suspect that there will be some matrix mapping applications/environments
to file systems to show which file system(s) to use for each.

Jim

>
>Hi!
>
>We now have several journaling file systems, like XFS, ReiserFS and
>ext3 (and more I believe, but I would like to concentrate on these
>three). 
>I have played with ext3 a few weeks ago, which was oke (easy to install
>and if I unplugged the machine, it was up and running (fine) in no time
>just the way sysadmins like it. :-)
>
>Now it seemes to me that ReiserFS has a larger developer base and aims
>a bit higher than ext3. Is that true? If not, what is the difference
>between ext3 and ReiserFS?
>ReiserFS seemes to be a good choice for spool directories because it
>can handle a _huge_ amount of files (and dirs) in a dir efficiently.
>
>And there is XFS. What is the advantage or disadvantage of XFS compared
>to ext3 and/or ReiserFS? It seemes to me that XFS is a bit less stable
>than the others at this moment. Is that true? XFS exists for some time
>now. Is that an advantage above ReiserFS because it had more time to
>develop itself to what is is now, or is ReiserFS 'better' because it
>doesn't have to carry its history and doesn't have to be backwards
>compatible?
>
>Please enlighten me. :-)
>
>		Ookhoi
>


From owner-linux-xfs@oss.sgi.com Fri Apr 14 07:25:19 2000
Received:  by oss.sgi.com id <S305175AbQDNOZI>;
	Fri, 14 Apr 2000 07:25:08 -0700
Received: from deliverator.sgi.com ([204.94.214.10]:26216 "EHLO
        deliverator.sgi.com") by oss.sgi.com with ESMTP id <S305159AbQDNOZE>;
	Fri, 14 Apr 2000 07:25:04 -0700
Received: from ledzep.cray.com (ledzep.cray.com [137.38.226.97]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id HAA29477
	for <linux-xfs@oss.sgi.com>; Fri, 14 Apr 2000 07:20:20 -0700 (PDT)
	mail_from (lord@sgi.com)
Received: from ironwood-e185.americas.sgi.com (ironwood.cray.com [128.162.185.212]) by ledzep.cray.com (SGI-SGI-8.9.3/craymail-smart-nospam1.0) with ESMTP id JAA14989; Fri, 14 Apr 2000 09:22:31 -0500 (CDT)
Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.184.86]) by ironwood-e185.americas.sgi.com (8.8.4/SGI-ironwood-e1.4) with ESMTP id JAA25138; Fri, 14 Apr 2000 09:22:23 -0500 (CDT)
Received: from jen.americas.sgi.com by jen.americas.sgi.com (8.9.3/SGI-client.1.6) via ESMTP id JAA29185; Fri, 14 Apr 2000 09:22:09 -0500
Message-Id: <200004141422.JAA29185@jen.americas.sgi.com>
X-Mailer: exmh version 2.1.1 10/15/1999
To:     Kip Macy <kmacy@CS.Berkeley.EDU>
cc:     Steve Lord <lord@sgi.com>, linux-xfs@oss.sgi.com
Subject: Re: files disappearing? 
In-Reply-To: Message from Kip Macy <kmacy@CS.Berkeley.EDU> 
   of "Wed, 12 Apr 2000 09:17:45 PDT." <Pine.SOL.4.10.10004120915240.23320-100000@ribbit.CS.Berkeley.EDU> 
Date:   Fri, 14 Apr 2000 09:22:09 -0500
From:   Steve Lord <lord@sgi.com>
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing

> > This should show up in directories with a fairly large number of entries
> > and an average name length of 12 or more characters (I think). 
> > 
> The only file that actually mattered for my build (as far as getting the
> compile to run to completion) was linux/include/config/page/buf/meta.h. An ls
> indicates that the only other file in that directory is locking.h.
> 

Another thought that occurred was that when you copied the tree over from
ext2 to xfs this file never came out of ext2. Running strace on the copy
of the files and looking for this one in the output would also be useful.

There is always the possibility that the problem lies on the ext2 end of
things ;-)

Steve



From owner-linux-xfs@oss.sgi.com Fri Apr 14 07:28:18 2000
Received:  by oss.sgi.com id <S305176AbQDNO17>;
	Fri, 14 Apr 2000 07:27:59 -0700
Received: from fw.suse.com ([216.88.157.2]:26365 "HELO suse.com")
	by oss.sgi.com with SMTP id <S305159AbQDNO1s>;
	Fri, 14 Apr 2000 07:27:48 -0700
Received: (qmail 17015 invoked by uid 539); 14 Apr 2000 14:27:48 -0000
Received: from localhost (sendmail-bs@127.0.0.1)
  by localhost with SMTP; 14 Apr 2000 14:27:48 -0000
Date:   Fri, 14 Apr 2000 07:27:48 -0700 (PDT)
From:   Chris Mason <mason@suse.com>
To:     Jim Mostek <mostek@sgi.com>
cc:     ookhoi@dds.nl, linux-xfs@oss.sgi.com, reiserfs@devlinux.com
Subject: Re: (reiserfs) Re: XFS, ReiserFS or ext3?
In-Reply-To: <200004141403.JAA57968@fsgi344.americas.sgi.com>
Message-ID: <Pine.LNX.4.10.10004140711500.32689-100000@home.suse.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing



On Fri, 14 Apr 2000, Jim Mostek wrote:

> 
> I haven't played with ReiserFS but from what I've read/heard, my guess
> is that it will do small files really well. XFS' directories can
> also handle many entries, but ReiserFS with its packing and data in the
> inode can handle small files better. But, I don't know how ReiserFS will
> do when many processes are hitting the same directory on a multi-CPU
> system. XFS has had lots of work done in this area since we have many
> customer running old sendmail which does all its file work in the same
> directory.
> 

This is mostly true.  We are working on better threading of the reiserfs 
tree structures, to increase our SMP speeds, and adding support for
dedicated log devices (I think XFS has this already) to help speed up
metadata and fsync() intensive applications.

[...]
 
> Longer term, it appears that the Linux community will have a rich set
> of file systems available. These can be downloaded and analyzed.
> I suspect that there will be some matrix mapping applications/environments
> to file systems to show which file system(s) to use for each.
> 

Very true.  Also, as the various journaled filesystems are merged into the
kernel, the underlying I/O drivers will probably be tuned to help support
them.  I'm sure SGI and IBM both will add a great deal of value to linux
there.

-chris


From owner-linux-xfs@oss.sgi.com Fri Apr 14 07:59:19 2000
Received:  by oss.sgi.com id <S305166AbQDNO7J>;
	Fri, 14 Apr 2000 07:59:09 -0700
Received: from expanse.dds.nl ([194.109.10.118]:59140 "EHLO expanse.dds.nl")
	by oss.sgi.com with ESMTP id <S305159AbQDNO6w>;
	Fri, 14 Apr 2000 07:58:52 -0700
Received: (from ookhoi@localhost)
	by expanse.dds.nl (8.9.3/8.9.3) id QAA02615;
	Fri, 14 Apr 2000 16:58:33 +0200
Date:   Fri, 14 Apr 2000 16:58:32 +0200
From:   Ookhoi <ookhoi@dds.nl>
To:     Jim Mostek <mostek@sgi.com>
Cc:     linux-xfs@oss.sgi.com, reiserfs@devlinux.com
Subject: Re: XFS, ReiserFS or ext3?
Message-ID: <20000414165832.Z28226@ookhoi.dds.nl>
Reply-To: ookhoi@dds.nl
References: <20000414134826.V28226@ookhoi.dds.nl> <200004141403.JAA57968@fsgi344.americas.sgi.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 1.0pre2i
In-Reply-To: <200004141403.JAA57968@fsgi344.americas.sgi.com>
X-Uptime: 9:30am  up 13 days, 21:18, 33 users,  load average: 0.63, 1.91, 4.24
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing

Hi Jim Mostek,

Thanx a lot for your reaction!

> I haven't played with ReiserFS but from what I've read/heard, my guess
> is that it will do small files really well. XFS' directories can
> also handle many entries, but ReiserFS with its packing and data in the
> inode can handle small files better. But, I don't know how ReiserFS will
> do when many processes are hitting the same directory on a multi-CPU
> system. XFS has had lots of work done in this area since we have many
> customer running old sendmail which does all its file work in the same
> directory.
> 
> For information on XFS, see http://oss.sgi.com/projects/xfs.
> The main design goals of XFS are very large storage, scalability, 

Like with the LVM and MD stuff? I believe these thing are integrated
into XFS, right? But with Linux and ReiserFS you can also use LVM and
MD (does ReiserFS work with Linux sw raid now?)?

> and journaling. 

I believe (again :-) that ext3 journals everything, while ReiserFS
journals meta-data. Is this true? And what kind of journaling does XFS
do? What is the (dis)advantage of the different types of journaling?
And why is there a difference? Do you use ext3 for /usr, ReiserFS for
/var and XFS for /home, for example? (do they have a certain target for
which they aim?). And why don't you mention ext3 at all? Are ReiserFS
or XFS a better choice?

> XFS is much more than just a file system with journaling.
> If you are running with several processors and/or pushing lots of large
> files/data around, I suspect that XFS will be the best.
>
> In the short term, XFS is still in pre-beta form and beta won't be for a
> couple of months, yet. The current schedule has a production quality version of
> XFS available later this summer (northern hemisphere).
 
What is northern hemisphere? I've seen it before on the list..
And what does pre-beta mean? For example, a pre-beta Linux kernel
doesn't scare me. The same for unstable Debian. Does pre-beta mean that
it eats my files? That is it hard to install? That there are no
userspace tools? (I believe you have to patch the existing tools?).
That it changes a lot, and thing will break in the near future? I
really would like to play with a jfs, but think I need to concentrate
on one jfs only, because of time..

> XFS will have additional capabilities that the other file system you
> mentioned don't have such as Direct I/O and extended attributes. At least
> I haven't heard that others are adding these.
> 
> Longer term, it appears that the Linux community will have a rich set
> of file systems available. These can be downloaded and analyzed.
> I suspect that there will be some matrix mapping applications/environments
> to file systems to show which file system(s) to use for each.

Yes, that's why I ask. :-)  Is it a problem if you have both ReiserFS
and XFS in the kernel? For example, al the www stuff (with the small
files) on ReiserFS, and the streaming video stuff on XFS?
Btw, ReiserFS can put small (pieces of) files together in one block,
right? Does that mean that you can have block sizes (frag size) of 8k
without the loss of space, but with the read/write speedup for larger
files? (I'm aware that that feature also causes a performance penalty)

And while I'm asking: how well do ReiserFS and XFS fit into the current
2.3.99 kernel, and thus in 2.4? I believe ext3 aims at 2.2 for the
moment?

I hope my questions and the answers are what others also want to know..

		Ookhoi (who likes the current fs development a lot!)


> >We now have several journaling file systems, like XFS, ReiserFS and
> >ext3 (and more I believe, but I would like to concentrate on these
> >three). 
> >I have played with ext3 a few weeks ago, which was oke (easy to install
> >and if I unplugged the machine, it was up and running (fine) in no time
> >just the way sysadmins like it. :-)
> >
> >Now it seemes to me that ReiserFS has a larger developer base and aims
> >a bit higher than ext3. Is that true? If not, what is the difference
> >between ext3 and ReiserFS?
> >ReiserFS seemes to be a good choice for spool directories because it
> >can handle a _huge_ amount of files (and dirs) in a dir efficiently.
> >
> >And there is XFS. What is the advantage or disadvantage of XFS compared
> >to ext3 and/or ReiserFS? It seemes to me that XFS is a bit less stable
> >than the others at this moment. Is that true? XFS exists for some time
> >now. Is that an advantage above ReiserFS because it had more time to
> >develop itself to what is is now, or is ReiserFS 'better' because it
> >doesn't have to carry its history and doesn't have to be backwards
> >compatible?
> >
> >Please enlighten me. :-)
> >
> >		Ookhoi

From owner-linux-xfs@oss.sgi.com Fri Apr 14 08:52:19 2000
Received:  by oss.sgi.com id <S305159AbQDNPwK>;
	Fri, 14 Apr 2000 08:52:10 -0700
Received: from ns.mtu.ru ([195.34.32.10]:2489 "HELO mtu.ru") by oss.sgi.com
	with SMTP id <S305157AbQDNPwA>; Fri, 14 Apr 2000 08:52:00 -0700
Received: from reiser.to (ppp106-108.dialup.mtu-net.ru [212.188.106.108])
	by mtu.ru (Postfix) with ESMTP
	id 5322E7855E; Fri, 14 Apr 2000 19:51:51 +0400 (MSD)
	(envelope-from hans@reiser.to)
Message-ID: <38F7D238.CB9179BF@reiser.to>
Date:   Fri, 14 Apr 2000 19:21:44 -0700
From:   Hans Reiser <hans@reiser.to>
Organization: Namesys
X-Mailer: Mozilla 4.72 [en] (X11; I; Linux 2.2.14 i686)
X-Accept-Language: en, ru
MIME-Version: 1.0
To:     Jim Mostek <mostek@sgi.com>
Cc:     ookhoi@dds.nl, linux-xfs@oss.sgi.com, reiserfs@devlinux.com
Subject: Re: (reiserfs) Re: XFS, ReiserFS or ext3?
References: <200004141403.JAA57968@fsgi344.americas.sgi.com>
Content-Type: text/plain; charset=koi8-r
Content-Transfer-Encoding: 7bit
X-Recipient: mostek@sgi.com
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing

Jim Mostek wrote:
> 
> I haven't played with ReiserFS but from what I've read/heard, my guess
> is that it will do small files really well. XFS' directories can
> also handle many entries, but ReiserFS with its packing and data in the
> inode can handle small files better. But, I don't know how ReiserFS will
> do when many processes are hitting the same directory on a multi-CPU
> system. XFS has had lots of work done in this area since we have many
> customer running old sendmail which does all its file work in the same
> directory.

We are having a friendly respectful little race to see whether XFS can port
faster than we can tune.  The XFS guys are extremely skilled programmers, but
they have a large code base, and Network Appliance hired many of the writers of
that code.  I think that ReiserFS's core tree technology is ahead of XFS, and we
are working on a complete rewrite which will deploy new next generation tree
technology (we are leaving our B* trees behind for something much more
powerful), meaning we hope to see the gap widen a bit while they focus on
porting rather than rewriting.  We just had a two day seminar on the new
algorithms, so I am a bit jazzed about them.:)  That said, I would be very
surprised if there were no areas where XFS was better than ReiserFS when XFS
comes out, the XFS guys are good....

It may amuse you to know that both sides have tried to convince the other team
to quit and join their effort, and this is an indication of our mutual respect.


> XFS will have additional capabilities that the other file system you
> mentioned don't have such as Direct I/O and extended attributes.

If by extended attributes you mean variable allocation of stat data, we are
doing that, but it is not shipping yet.  We are also doing I/O scheduler work
that is still very raw but may be usable by summer.  I would hope that there is
code the XFS team puts into VFS that we can use and vice-versa.

> At least
> I haven't heard that others are adding these.
> 
> Longer term, it appears that the Linux community will have a rich set
> of file systems available. These can be downloaded and analyzed.
> I suspect that there will be some matrix mapping applications/environments
> to file systems to show which file system(s) to use for each.
> 
> Jim
> 
> >
> >Hi!
> >
> >We now have several journaling file systems, like XFS, ReiserFS and
> >ext3 (and more I believe, but I would like to concentrate on these
> >three).
> >I have played with ext3 a few weeks ago, which was oke (easy to install
> >and if I unplugged the machine, it was up and running (fine) in no time
> >just the way sysadmins like it. :-)
> >
> >Now it seemes to me that ReiserFS has a larger developer base and aims
> >a bit higher than ext3. Is that true? If not, what is the difference
> >between ext3 and ReiserFS?
> >ReiserFS seemes to be a good choice for spool directories because it
> >can handle a _huge_ amount of files (and dirs) in a dir efficiently.
> >
> >And there is XFS. What is the advantage or disadvantage of XFS compared
> >to ext3 and/or ReiserFS? It seemes to me that XFS is a bit less stable
> >than the others at this moment. Is that true? XFS exists for some time
> >now. Is that an advantage above ReiserFS because it had more time to
> >develop itself to what is is now, or is ReiserFS 'better' because it
> >doesn't have to carry its history and doesn't have to be backwards
> >compatible?
> >
> >Please enlighten me. :-)
> >
> >               Ookhoi
> >

From owner-linux-xfs@oss.sgi.com Fri Apr 14 10:45:41 2000
Received:  by oss.sgi.com id <S305159AbQDNRpW>;
	Fri, 14 Apr 2000 10:45:22 -0700
Received: from deliverator.sgi.com ([204.94.214.10]:43040 "EHLO
        deliverator.sgi.com") by oss.sgi.com with ESMTP id <S305157AbQDNRow>;
	Fri, 14 Apr 2000 10:44:52 -0700
Received: from ledzep.cray.com (ledzep.cray.com [137.38.226.97]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id KAA23478
	for <linux-xfs@oss.sgi.com>; Fri, 14 Apr 2000 10:40:07 -0700 (PDT)
	mail_from (cattelan@thebarn.com)
From:   cattelan@thebarn.com
Received: from ironwood-e185.americas.sgi.com (ironwood.cray.com [128.162.185.212]) by ledzep.cray.com (SGI-SGI-8.9.3/craymail-smart-nospam1.0) with ESMTP id MAA83151; Fri, 14 Apr 2000 12:43:35 -0500 (CDT)
Received: from gibble.americas.sgi.com (root@gibble.americas.sgi.com [128.162.195.80]) by ironwood-e185.americas.sgi.com (8.8.4/SGI-ironwood-e1.4) with ESMTP id MAA07806; Fri, 14 Apr 2000 12:43:27 -0500 (CDT)
Received: from gibble.americas.sgi.com by gibble.americas.sgi.com (8.9.3/SGI-client.1.6) via ESMTP id MAA22971; Fri, 14 Apr 2000 12:43:33 -0500
Date:   Fri, 14 Apr 2000 12:43:30 -0500
Message-ID: <14583.22722.385423.85072F@gibble.americas.sgi.com>
To:     gast6@vum.be
Cc:     linux-xfs@oss.sgi.com
Subject: Re: cvs tree problems
In-Reply-To: In your message of "Fri, 14 Apr 2000 10:01:41 +0200"
	<00041410031200.03427@pcgx14500003.vum.be>
References: <00041410031200.03427@pcgx14500003.vum.be>
User-Agent: Wanderlust/1.0.3 (Notorious) tm/7.108 XEmacs/21.1 (Bryce Canyon)
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing

At Fri, 14 Apr 2000 10:01:41 +0200,
kris <gast6@vum.be> wrote:
> 
> 
> I got problems updating ...
> following error occurs : 
> 
> cvs server: Updating linux-2.3-xfs/cmd/xfs/bstat
> cvs server: failed to create lock directory in repository `/cvs/linux-2.3-xfs/cmd/xfs/bstat': Permission denied
> cvs server: failed to obtain dir lock in repository `/cvs/linux-2.3-xfs/cmd/xfs/bstat'
> cvs [server aborted]: read lock failed - giving up

Ok small problem with the fix-perms script not having correct access. 

Fixed.


From owner-linux-xfs@oss.sgi.com Fri Apr 14 13:03:33 2000
Received:  by oss.sgi.com id <S305159AbQDNUDX>;
	Fri, 14 Apr 2000 13:03:23 -0700
Received: from ribbit.CS.Berkeley.EDU ([128.32.131.152]:48576 "EHLO
        ribbit.CS.Berkeley.EDU") by oss.sgi.com with ESMTP
	id <S305157AbQDNUC7>; Fri, 14 Apr 2000 13:02:59 -0700
Received: from localhost (kmacy@localhost)
	by ribbit.CS.Berkeley.EDU (8.9.3/8.9.3) with ESMTP id NAA14089
	for <linux-xfs@oss.sgi.com>; Fri, 14 Apr 2000 13:03:05 -0700 (PDT)
X-Authentication-Warning: ribbit.CS.Berkeley.EDU: kmacy owned process doing -bs
Date:   Fri, 14 Apr 2000 13:03:05 -0700 (PDT)
From:   Kip Macy <kmacy@CS.Berkeley.EDU>
To:     linux-xfs@oss.sgi.com
Subject: problems in xfs_icrash.c
Message-ID: <Pine.SOL.4.10.10004141302300.13996-100000@ribbit.CS.Berkeley.EDU>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing


make[2]: Entering directory `/usr/src/SGI/linux-2.3-xfs/linux/fs/xfs'
gcc -D__KERNEL__ -I/usr/src/SGI/linux-2.3-xfs/linux/include -D__SMP__ -Wall
-Wstrict-prototypes -O2 -pipe   -DCPU=686 -march=i686 -fno-strict-aliasing  -g3
-Wno-unused  -Wno-unknown-pragmas -Wno-parentheses -Wno-uninitialized -I./linux
-I./pseudo-inc -I. -D_KERNEL -funsigned-char   -DEXPORT_SYMTAB -c xfs_icrash.c
xfs_icrash.c:128: parse error before `xfs_fid_t'
xfs_icrash.c:128: warning: no semicolon at end of struct or union
xfs_icrash.c:129: warning: type defaults to `int' in declaration of
`xfs_icrash39'
xfs_icrash.c:129: warning: data definition has no type or storage class
xfs_icrash.c:130: parse error before `*'
xfs_icrash.c:130: warning: type defaults to `int' in declaration of
`xfs_icrash40'
xfs_icrash.c:130: warning: data definition has no type or storage class
xfs_icrash.c:131: parse error before `*'
xfs_icrash.c:131: warning: type defaults to `int' in declaration of
`xfs_icrash41'
xfs_icrash.c:131: warning: data definition has no type or storage class
xfs_icrash.c:148: parse error before `}'
xfs_icrash.c:148: warning: type defaults to `int' in declaration of
`xfs_icrash_t'
xfs_icrash.c:148: warning: data definition has no type or storage class
xfs_icrash.c:150: parse error before `*'
xfs_icrash.c:150: warning: type defaults to `int' in declaration of
`xfs_icrash_struct'
xfs_icrash.c:150: warning: data definition has no type or storage class
make[2]: *** [xfs_icrash.o] Error 1


------------------------------------------------------------------------
Kip Macy                               kmacy@cs.berkeley.edu
University of California, Berkeley     
------------------------------------------------------------------------



From owner-linux-xfs@oss.sgi.com Fri Apr 14 13:07:23 2000
Received:  by oss.sgi.com id <S305161AbQDNUHE>;
	Fri, 14 Apr 2000 13:07:04 -0700
Received: from ribbit.CS.Berkeley.EDU ([128.32.131.152]:61632 "EHLO
        ribbit.CS.Berkeley.EDU") by oss.sgi.com with ESMTP
	id <S305157AbQDNUG5>; Fri, 14 Apr 2000 13:06:57 -0700
Received: from localhost (kmacy@localhost)
	by ribbit.CS.Berkeley.EDU (8.9.3/8.9.3) with ESMTP id NAA14150
	for <linux-xfs@oss.sgi.com>; Fri, 14 Apr 2000 13:07:01 -0700 (PDT)
X-Authentication-Warning: ribbit.CS.Berkeley.EDU: kmacy owned process doing -bs
Date:   Fri, 14 Apr 2000 13:07:01 -0700 (PDT)
From:   Kip Macy <kmacy@CS.Berkeley.EDU>
To:     linux-xfs@oss.sgi.com
Subject: Never mind was Re: problems in xfs_icrash.c
In-Reply-To: <Pine.SOL.4.10.10004141302300.13996-100000@ribbit.CS.Berkeley.EDU>
Message-ID: <Pine.SOL.4.10.10004141306340.13996-100000@ribbit.CS.Berkeley.EDU>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing

Sorry, I did not update a header.

------------------------------------------------------------------------
Kip Macy                               kmacy@cs.berkeley.edu
University of California, Berkeley     
------------------------------------------------------------------------


On Fri, 14 Apr 2000, Kip Macy wrote:

> 
> make[2]: Entering directory `/usr/src/SGI/linux-2.3-xfs/linux/fs/xfs'
> gcc -D__KERNEL__ -I/usr/src/SGI/linux-2.3-xfs/linux/include -D__SMP__ -Wall
> -Wstrict-prototypes -O2 -pipe   -DCPU=686 -march=i686 -fno-strict-aliasing  -g3
> -Wno-unused  -Wno-unknown-pragmas -Wno-parentheses -Wno-uninitialized -I./linux
> -I./pseudo-inc -I. -D_KERNEL -funsigned-char   -DEXPORT_SYMTAB -c xfs_icrash.c
> xfs_icrash.c:128: parse error before `xfs_fid_t'
> xfs_icrash.c:128: warning: no semicolon at end of struct or union
> xfs_icrash.c:129: warning: type defaults to `int' in declaration of
> `xfs_icrash39'
> xfs_icrash.c:129: warning: data definition has no type or storage class
> xfs_icrash.c:130: parse error before `*'
> xfs_icrash.c:130: warning: type defaults to `int' in declaration of
> `xfs_icrash40'
> xfs_icrash.c:130: warning: data definition has no type or storage class
> xfs_icrash.c:131: parse error before `*'
> xfs_icrash.c:131: warning: type defaults to `int' in declaration of
> `xfs_icrash41'
> xfs_icrash.c:131: warning: data definition has no type or storage class
> xfs_icrash.c:148: parse error before `}'
> xfs_icrash.c:148: warning: type defaults to `int' in declaration of
> `xfs_icrash_t'
> xfs_icrash.c:148: warning: data definition has no type or storage class
> xfs_icrash.c:150: parse error before `*'
> xfs_icrash.c:150: warning: type defaults to `int' in declaration of
> `xfs_icrash_struct'
> xfs_icrash.c:150: warning: data definition has no type or storage class
> make[2]: *** [xfs_icrash.o] Error 1
> 
> 
> ------------------------------------------------------------------------
> Kip Macy                               kmacy@cs.berkeley.edu
> University of California, Berkeley     
> ------------------------------------------------------------------------
> 
> 


From owner-linux-xfs@oss.sgi.com Fri Apr 14 13:45:54 2000
Received:  by oss.sgi.com id <S305161AbQDNUpe>;
	Fri, 14 Apr 2000 13:45:34 -0700
Received: from [216.208.98.2] ([216.208.98.2]:24568 "EHLO moiraine.off.net")
	by oss.sgi.com with ESMTP id <S305159AbQDNUpH>;
	Fri, 14 Apr 2000 13:45:07 -0700
Received: (from phil@localhost)
	by moiraine.off.net (8.9.3/8.9.3) id RAA07807
	for linux-xfs@oss.sgi.com; Fri, 14 Apr 2000 17:36:01 -0400
Date:   Fri, 14 Apr 2000 17:36:01 -0400
From:   Phil Schwan <phil@linuxcare.com>
To:     linux-xfs@oss.sgi.com
Subject: TAKE - fix mkfs crash
Message-ID: <20000414173601.F1665@linuxcare.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 0.95.4us
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing

I've misplaced the name of the person that reported this bug, but we
weren't correctly initializing logname.

The new linux ptools doesn't support p_bugpost, so I'm doing this by
hand.  Hmm.

Modid:  2.3.99pre2-xfs:slinx:58031a

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

cmd/xfs/mkfs/xfs_mkfs.c - 1.157
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/cmd/xfs/mkfs/xfs_mkfs.c.diff?r1=text&tr1=1.157&r2=text&tr2=1.156&f=h
        - Initialize logfile to NULL

From owner-linux-xfs@oss.sgi.com Fri Apr 14 13:48:33 2000
Received:  by oss.sgi.com id <S305166AbQDNUsY>;
	Fri, 14 Apr 2000 13:48:24 -0700
Received: from [216.208.98.2] ([216.208.98.2]:29944 "EHLO moiraine.off.net")
	by oss.sgi.com with ESMTP id <S305159AbQDNUsH>;
	Fri, 14 Apr 2000 13:48:07 -0700
Received: (from phil@localhost)
	by moiraine.off.net (8.9.3/8.9.3) id RAA07822
	for linux-xfs@oss.sgi.com; Fri, 14 Apr 2000 17:39:01 -0400
Date:   Fri, 14 Apr 2000 17:39:01 -0400
From:   Phil Schwan <phil@linuxcare.com>
To:     linux-xfs@oss.sgi.com
Subject: TAKE - fix xfs_repair with separate log devices
Message-ID: <20000414173901.G1665@linuxcare.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 0.95.4us
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing

sim_init() was unconditionally setting simargs->logname to NULL.  This
broke external log filesystems.

Modid:  2.3.99pre2-xfs:slinx:58032a

The following file(s) were checked into:
  bonnie.engr.sgi.com:/isms/slinx/2.3.99pre2-xfs
  
cmd/xfs/repair/init.c - 1.9
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/cmd/xfs/repair/init.c.diff?r1=text&tr1=1.9&r2=text&tr2=1.8&f=h
        - sim_init() was unconditionally setting simargs->logname to
	NULL.  This broke external log filesystems.

From owner-linux-xfs@oss.sgi.com Fri Apr 14 13:56:33 2000
Received:  by oss.sgi.com id <S305161AbQDNU4X>;
	Fri, 14 Apr 2000 13:56:23 -0700
Received: from [216.208.98.2] ([216.208.98.2]:46584 "EHLO moiraine.off.net")
	by oss.sgi.com with ESMTP id <S305159AbQDNU4O>;
	Fri, 14 Apr 2000 13:56:14 -0700
Received: (from phil@localhost)
	by moiraine.off.net (8.9.3/8.9.3) id RAA07845
	for linux-xfs@oss.sgi.com; Fri, 14 Apr 2000 17:47:09 -0400
Date:   Fri, 14 Apr 2000 17:47:09 -0400
From:   Phil Schwan <phil@linuxcare.com>
To:     linux-xfs@oss.sgi.com
Subject: TAKE - small #ifdef fix for ino64
Message-ID: <20000414174709.H1665@linuxcare.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 0.95.4us
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing

XFS_BIG was only used here, and XFS_BIG_FILESYSTEMS makes more sense
for an ino64 check anyways.

Modid:  2.3.99pre2-xfs:slinx:58033a

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

linux/fs/xfs/linux/xfs_mount_opt.c
        - s/XFS_BIG/XFS_BIG_FILESYSTEMS/

From owner-linux-xfs@oss.sgi.com Fri Apr 14 14:59:44 2000
Received:  by oss.sgi.com id <S305159AbQDNV7e>;
	Fri, 14 Apr 2000 14:59:34 -0700
Received: from [216.208.98.2] ([216.208.98.2]:1021 "EHLO moiraine.off.net")
	by oss.sgi.com with ESMTP id <S305161AbQDNV7Y>;
	Fri, 14 Apr 2000 14:59:24 -0700
Received: (from phil@localhost)
	by moiraine.off.net (8.9.3/8.9.3) id SAA07992
	for linux-xfs@oss.sgi.com; Fri, 14 Apr 2000 18:50:19 -0400
Date:   Fri, 14 Apr 2000 18:50:19 -0400
From:   Phil Schwan <phil@linuxcare.com>
To:     linux-xfs@oss.sgi.com
Subject: TAKE - fix external log bug; add remount code; add recovery to ROFS mode
Message-ID: <20000414185019.I1665@linuxcare.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 0.95.4us
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing

This fixes a bug in external log replay; it would find an invalid log
but continue on and eventually panic.

Here is some initial remount code that appears to work but definitely
does not do all of the right things, including syncing.  I'm testing
some code related to flushing all of the data before actually
completing the remount.

The code that replays logs on readonly mounts seems to work; feedback
or good ways to verify would be appreciated.

Modid:  2.3.99pre2-xfs:slinx:58037a

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

linux/fs/xfs/linux/xfs_super.c - 1.60
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/linux/fs/xfs/linux/xfs_super.c.diff?r1=text&tr1=1.60&r2=text&tr2=1.59&f=h
	- added first cut at remount code

linux/fs/xfs/xfs_log_recover.c -  1.170
	- check return code of xlog_test_footer() and bail on error
	- added code to replay log in readonly situations

linux/fs/xfs/xfs_os_defs.h - 1.3
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/linux/fs/xfs/xfs_os_defs.h.diff?r1=text&tr1=1.3&r2=text&tr2=1.2&f=h
	- added NEED_FS_H #ifdef

From owner-linux-xfs@oss.sgi.com Fri Apr 14 15:23:44 2000
Received:  by oss.sgi.com id <S305161AbQDNWXe>;
	Fri, 14 Apr 2000 15:23:34 -0700
Received: from pneumatic-tube.sgi.com ([204.94.214.22]:22107 "EHLO
        pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP
	id <S305159AbQDNWXX>; Fri, 14 Apr 2000 15:23:23 -0700
Received: from ledzep.cray.com (ledzep.cray.com [137.38.226.97]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id PAA05787
	for <linux-xfs@oss.sgi.com>; Fri, 14 Apr 2000 15:27:19 -0700 (PDT)
	mail_from (n8994@sgi.com)
Received: from ironwood-e185.americas.sgi.com (ironwood.cray.com [128.162.185.212]) by ledzep.cray.com (SGI-SGI-8.9.3/craymail-smart-nospam1.0) with ESMTP id RAA87751 for <linux-xfs@oss.sgi.com>; Fri, 14 Apr 2000 17:22:07 -0500 (CDT)
Received: from nt8.americas.sgi.com (nt8.americas.sgi.com [128.162.195.8]) by ironwood-e185.americas.sgi.com (8.8.4/SGI-ironwood-e1.4) with ESMTP id RAA21550 for <linux-xfs@oss.sgi.com>; Fri, 14 Apr 2000 17:21:59 -0500 (CDT)
From:   Russell Cattelan <n8994@sgi.com>
Received: by nt8.americas.sgi.com (980427.SGI.8.8.8/SGI-client.1.6) id RAA12637; Fri, 14 Apr 2000 17:22:05 -0500 (CDT)
Message-Id: <200004142222.RAA12637@nt8.americas.sgi.com>
Date:   Fri, 14 Apr 2000 17:22:05 -0500 (CDT)
To:     linux-xfs@oss.sgi.com
Subject: TAKE - 
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing

Modid:  2.3.99pre2-xfs:slinx:58044a
Date:  Fri Apr 14 15:20:11 PDT 2000
Workarea:  nt8.americas.sgi.com:/data/clink/io/cattelan/x2.3-99-xfs

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

linux/fs/page_buf.c - 1.79
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/linux/fs/page_buf.c.diff?r1=text&tr1=1.79&r2=text&tr2=1.78&f=h
	- When re-queuing page_buf on DELWRI list drop the hold count.
	  The seems to eliminate un released pagebufs as unmount time.

linux/fs/page_buf_locking.c - 1.22
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/linux/fs/page_buf_locking.c.diff?r1=text&tr1=1.22&r2=text&tr2=1.21&f=h
	- If pagebuf has outstanding I/O; push on the task_queue to
	  speed it up a bit.


From owner-linux-xfs@oss.sgi.com Sat Apr 15 16:14:05 2000
Received:  by oss.sgi.com id <S305165AbQDOXNp>;
	Sat, 15 Apr 2000 16:13:45 -0700
Received: from ribbit.CS.Berkeley.EDU ([128.32.131.152]:16362 "EHLO
        ribbit.CS.Berkeley.EDU") by oss.sgi.com with ESMTP
	id <S305163AbQDOXNQ>; Sat, 15 Apr 2000 16:13:16 -0700
Received: from localhost (kmacy@localhost)
	by ribbit.CS.Berkeley.EDU (8.9.3/8.9.3) with ESMTP id QAA21812
	for <linux-xfs@oss.sgi.com>; Sat, 15 Apr 2000 16:13:23 -0700 (PDT)
X-Authentication-Warning: ribbit.CS.Berkeley.EDU: kmacy owned process doing -bs
Date:   Sat, 15 Apr 2000 16:13:23 -0700 (PDT)
From:   Kip Macy <kmacy@CS.Berkeley.EDU>
To:     linux-xfs@oss.sgi.com
Subject: cvs checkout fails in an xfs filesystem
Message-ID: <Pine.SOL.4.10.10004151526140.21370-100000@ribbit.CS.Berkeley.EDU>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing

I have just had 
> cvs -z3 checkout linux-2.3-xfs
fail twice with the following error:


U linux-2.3-xfs/linux/drivers/video/aty128fb.c
cvs [checkout aborted]: writing linux-2.3-xfs/linux/drivers/video/atyfb.c: No
such file or directory



------------------------------------------------------------------------
Kip Macy                               kmacy@cs.berkeley.edu
University of California, Berkeley     
------------------------------------------------------------------------




From owner-linux-xfs@oss.sgi.com Sat Apr 15 16:16:44 2000
Received:  by oss.sgi.com id <S305169AbQDOXQf>;
	Sat, 15 Apr 2000 16:16:35 -0700
Received: from ribbit.CS.Berkeley.EDU ([128.32.131.152]:19178 "EHLO
        ribbit.CS.Berkeley.EDU") by oss.sgi.com with ESMTP
	id <S305163AbQDOXQT>; Sat, 15 Apr 2000 16:16:19 -0700
Received: from localhost (kmacy@localhost)
	by ribbit.CS.Berkeley.EDU (8.9.3/8.9.3) with ESMTP id QAA21841
	for <linux-xfs@oss.sgi.com>; Sat, 15 Apr 2000 16:16:26 -0700 (PDT)
X-Authentication-Warning: ribbit.CS.Berkeley.EDU: kmacy owned process doing -bs
Date:   Sat, 15 Apr 2000 16:16:26 -0700 (PDT)
From:   Kip Macy <kmacy@CS.Berkeley.EDU>
To:     linux-xfs@oss.sgi.com
Subject: neg that was Re: cvs checkout fails in an xfs filesystem
In-Reply-To: <Pine.SOL.4.10.10004151526140.21370-100000@ribbit.CS.Berkeley.EDU>
Message-ID: <Pine.SOL.4.10.10004151615550.21808-100000@ribbit.CS.Berkeley.EDU>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing

The problem was unrelated to xfs.

------------------------------------------------------------------------
Kip Macy                               kmacy@cs.berkeley.edu
University of California, Berkeley     
------------------------------------------------------------------------


On Sat, 15 Apr 2000, Kip Macy wrote:

> I have just had 
> > cvs -z3 checkout linux-2.3-xfs
> fail twice with the following error:
> 
> 
> U linux-2.3-xfs/linux/drivers/video/aty128fb.c
> cvs [checkout aborted]: writing linux-2.3-xfs/linux/drivers/video/atyfb.c: No
> such file or directory
> 
> 
> 
> ------------------------------------------------------------------------
> Kip Macy                               kmacy@cs.berkeley.edu
> University of California, Berkeley     
> ------------------------------------------------------------------------
> 
> 
> 


From owner-linux-xfs@oss.sgi.com Sun Apr 16 12:31:44 2000
Received:  by oss.sgi.com id <S305165AbQDPTbf>;
	Sun, 16 Apr 2000 12:31:35 -0700
Received: from timbuk-fddi.cray.com ([128.162.8.102]:24705 "EHLO
        timbuk.cray.com") by oss.sgi.com with ESMTP id <S305163AbQDPTbP>;
	Sun, 16 Apr 2000 12:31:15 -0700
Received: from clink.americas.sgi.com (clink.cray.com [128.162.84.70]) by timbuk.cray.com (8.8.8/CRI-gate-news-1.3) with ESMTP id OAA00015 for <linux-xfs@oss.sgi.com>; Sun, 16 Apr 2000 14:31:12 -0500 (CDT)
Received: (from lord@localhost) by clink.americas.sgi.com (980427.SGI.8.8.8/CRI-news-1.3) id OAA41047 for linux-xfs@oss.sgi.com; Sun, 16 Apr 2000 14:31:13 -0500 (CDT)
Date:   Sun, 16 Apr 2000 14:31:13 -0500 (CDT)
From:   Steve Lord <lord@sgi.com>
Message-Id: <200004161931.OAA41047@clink.americas.sgi.com>
To:     linux-xfs@oss.sgi.com
Subject: TAKE - Initial direct read support
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing

This allows you to open a file with O_DIRECT and have reads bypass
the buffer cache (note that O_DIRECT is only visible from kernel headers
at the moment, so some header file futzing is needed to get to it).

This is a very basic implementation which makes no attempt
at synchronization with the buffer cache, it just moves what is on the disk
to user memory directly. User buffer addresses and file offsets should be
sector aligned (512 byte) - not all the checks for this are in place yet.

We could do the cache synchronization part of this by flushing buffers, or
finding them and copying from them to user memory when needed.

Modid:  2.3.99pre2-xfs:slinx:58069a
Date:  Sun Apr 16 12:25:12 PDT 2000
Workarea:  clink.americas.sgi.com:/data/clink/io/lord/xfs-linux

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

linux/fs/page_buf.c - 1.80
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/linux/fs/page_buf.c.diff?r1=text&tr1=1.80&r2=text&tr2=1.79&f=h
	- Add support for O_DIRECT on reads - this is a basic implementation,
	  not attempt at cache coherency yet - i.e. if there are dirty buffers
	  the read will miss them.

linux/fs/page_buf_locking.c - 1.23
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/linux/fs/page_buf_locking.c.diff?r1=text&tr1=1.23&r2=text&tr2=1.22&f=h
	- Remove debug printf


From owner-linux-xfs@oss.sgi.com Mon Apr 17 14:11:58 2000
Received:  by oss.sgi.com id <S305163AbQDQVLs>;
	Mon, 17 Apr 2000 14:11:48 -0700
Received: from ribbit.CS.Berkeley.EDU ([128.32.131.152]:48299 "EHLO
        ribbit.CS.Berkeley.EDU") by oss.sgi.com with ESMTP
	id <S305161AbQDQVLV>; Mon, 17 Apr 2000 14:11:21 -0700
Received: from localhost (kmacy@localhost)
	by ribbit.CS.Berkeley.EDU (8.9.3/8.9.3) with ESMTP id OAA04445
	for <linux-xfs@oss.sgi.com>; Mon, 17 Apr 2000 14:11:15 -0700 (PDT)
X-Authentication-Warning: ribbit.CS.Berkeley.EDU: kmacy owned process doing -bs
Date:   Mon, 17 Apr 2000 14:11:15 -0700 (PDT)
From:   Kip Macy <kmacy@CS.Berkeley.EDU>
To:     linux-xfs@oss.sgi.com
Subject: latest xfs source does not build
Message-ID: <Pine.SOL.4.10.10004171408240.3568-100000@ribbit.CS.Berkeley.EDU>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing


make -C xfs modules
make[2]: Entering directory `/usr/src/SGI/checkout2/linux-2.3-xfs/linux/fs/xfs'
gcc -D__KERNEL__ -I/usr/src/SGI/checkout2/linux-2.3-xfs/linux/include -Wall -Wst
rict-prototypes -O2 -pipe   -DCPU=686 -march=i686 -fno-strict-aliasing -DMODULE 
-DMODVERSIONS -include /usr/src/SGI/checkout2/linux-2.3-xfs/linux/include/linux/
modversions.h -g3 -Wno-unused  -Wno-unknown-pragmas -Wno-parentheses -Wno-uninit
ialized -I./linux -I./pseudo-inc -I. -D_KERNEL -funsigned-char   -DEXPORT_SYMTAB
 -c xfs_log_recover.c
In file included from xfs_buf.h:47,
                 from xfs_log_recover.c:46:
pseudo-inc/sys/buf.h:331: conflicting types for `bread'
/usr/src/SGI/checkout2/linux-2.3-xfs/linux/include/linux/fs.h:1046: previous dec
laration of `bread'
pseudo-inc/sys/buf.h:339: conflicting types for `brelse'
/usr/src/SGI/checkout2/linux-2.3-xfs/linux/include/linux/fs.h:1034: previous dec
laration of `brelse'


------------------------------------------------------------------------
Kip Macy                               kmacy@cs.berkeley.edu
University of California, Berkeley     
------------------------------------------------------------------------



From owner-linux-xfs@oss.sgi.com Mon Apr 17 14:28:37 2000
Received:  by oss.sgi.com id <S305173AbQDQV22>;
	Mon, 17 Apr 2000 14:28:28 -0700
Received: from deliverator.sgi.com ([204.94.214.10]:9047 "EHLO
        deliverator.sgi.com") by oss.sgi.com with ESMTP id <S305170AbQDQV2O>;
	Mon, 17 Apr 2000 14:28:14 -0700
Received: from madurai.engr.sgi.com (madurai.engr.sgi.com [163.154.5.75]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id OAA25129
	for <linux-xfs@oss.sgi.com>; Mon, 17 Apr 2000 14:23:30 -0700 (PDT)
	mail_from (ananth@sgi.com)
Received: from sgi.com (mango.engr.sgi.com [163.154.5.76]) by madurai.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) via ESMTP id OAA31409; Mon, 17 Apr 2000 14:24:30 -0700 (PDT)
Message-ID: <38FB812C.EAD536B7@sgi.com>
Date:   Mon, 17 Apr 2000 14:25:00 -0700
From:   Rajagopal Ananthanarayanan <ananth@sgi.com>
X-Mailer: Mozilla 4.6 [en] (X11; I; Linux 2.2.10-1SGI_11smp i686)
X-Accept-Language: en
MIME-Version: 1.0
To:     Kip Macy <kmacy@CS.Berkeley.EDU>
CC:     linux-xfs@oss.sgi.com
Subject: Re: latest xfs source does not build
References: <Pine.SOL.4.10.10004171408240.3568-100000@ribbit.CS.Berkeley.EDU>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing

Kip Macy wrote:
> 
> make -C xfs modules
> make[2]: Entering directory `/usr/src/SGI/checkout2/linux-2.3-xfs/linux/fs/xfs'
> gcc -D__KERNEL__ -I/usr/src/SGI/checkout2/linux-2.3-xfs/linux/include -Wall -Wst
> rict-prototypes -O2 -pipe   -DCPU=686 -march=i686 -fno-strict-aliasing -DMODULE
> -DMODVERSIONS -include /usr/src/SGI/checkout2/linux-2.3-xfs/linux/include/linux/
> modversions.h -g3 -Wno-unused  -Wno-unknown-pragmas -Wno-parentheses -Wno-uninit
> ialized -I./linux -I./pseudo-inc -I. -D_KERNEL -funsigned-char   -DEXPORT_SYMTAB
>  -c xfs_log_recover.c
> In file included from xfs_buf.h:47,
>                  from xfs_log_recover.c:46:
> pseudo-inc/sys/buf.h:331: conflicting types for `bread'
> /usr/src/SGI/checkout2/linux-2.3-xfs/linux/include/linux/fs.h:1046: previous dec
> laration of `bread'
> pseudo-inc/sys/buf.h:339: conflicting types for `brelse'
> /usr/src/SGI/checkout2/linux-2.3-xfs/linux/include/linux/fs.h:1034: previous dec
> laration of `brelse'


One workaround for this problem (until its fixed properly)
is to turn ON CONFIG_PAGE_BUF_META ...


--------------------------------------------------------------------------
Rajagopal Ananthanarayanan ("ananth")
Member Technical Staff, SGI.
--------------------------------------------------------------------------

From owner-linux-xfs@oss.sgi.com Mon Apr 17 15:07:28 2000
Received:  by oss.sgi.com id <S305161AbQDQWHS>;
	Mon, 17 Apr 2000 15:07:18 -0700
Received: from pneumatic-tube.sgi.com ([204.94.214.22]:29053 "EHLO
        pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP
	id <S305167AbQDQWG5>; Mon, 17 Apr 2000 15:06:57 -0700
Received: from ledzep.cray.com (ledzep.cray.com [137.38.226.97]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id PAA09765
	for <linux-xfs@oss.sgi.com>; Mon, 17 Apr 2000 15:10:56 -0700 (PDT)
	mail_from (cattelan@thebarn.com)
From:   cattelan@thebarn.com
Received: from ironwood-e185.americas.sgi.com (ironwood.cray.com [128.162.185.212]) by ledzep.cray.com (SGI-SGI-8.9.3/craymail-smart-nospam1.0) with ESMTP id RAA06496; Mon, 17 Apr 2000 17:05:40 -0500 (CDT)
Received: from gibble.americas.sgi.com (root@gibble.americas.sgi.com [128.162.195.80]) by ironwood-e185.americas.sgi.com (8.8.4/SGI-ironwood-e1.4) with ESMTP id RAA18424; Mon, 17 Apr 2000 17:05:32 -0500 (CDT)
Received: from gibble.americas.sgi.com by gibble.americas.sgi.com (8.9.3/SGI-client.1.6) via ESMTP id RAA22425; Mon, 17 Apr 2000 17:05:39 -0500
Date:   Mon, 17 Apr 2000 17:05:36 -0500
Message-ID: <14587.35504.996144.26996Q@gibble.americas.sgi.com>
To:     ananth@sgi.com
Cc:     kmacy@CS.Berkeley.EDU, linux-xfs@oss.sgi.com
Subject: Re: latest xfs source does not build
In-Reply-To: In your message of "Mon, 17 Apr 2000 14:25:00 -0700"
	<38FB812C.EAD536B7@sgi.com>
References: <Pine.SOL.4.10.10004171408240.3568-100000@ribbit.CS.Berkeley.EDU>
	<38FB812C.EAD536B7@sgi.com>
User-Agent: Wanderlust/1.0.3 (Notorious) tm/7.108 XEmacs/21.1 (Bryce Canyon)
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing

At Mon, 17 Apr 2000 14:25:00 -0700,
Rajagopal Ananthanarayanan <ananth@sgi.com> wrote:
> 
> 
> Kip Macy wrote:
> > 
> > make -C xfs modules
> > make[2]: Entering directory `/usr/src/SGI/checkout2/linux-2.3-xfs/linux/fs/xfs'
> > gcc -D__KERNEL__ -I/usr/src/SGI/checkout2/linux-2.3-xfs/linux/include -Wall -Wst
> > rict-prototypes -O2 -pipe   -DCPU=686 -march=i686 -fno-strict-aliasing -DMODULE
> > -DMODVERSIONS -include /usr/src/SGI/checkout2/linux-2.3-xfs/linux/include/linux/
> > modversions.h -g3 -Wno-unused  -Wno-unknown-pragmas -Wno-parentheses -Wno-uninit
> > ialized -I./linux -I./pseudo-inc -I. -D_KERNEL -funsigned-char   -DEXPORT_SYMTAB
> >  -c xfs_log_recover.c
> > In file included from xfs_buf.h:47,
> >                  from xfs_log_recover.c:46:
> > pseudo-inc/sys/buf.h:331: conflicting types for `bread'
> > /usr/src/SGI/checkout2/linux-2.3-xfs/linux/include/linux/fs.h:1046: previous dec
> > laration of `bread'
> > pseudo-inc/sys/buf.h:339: conflicting types for `brelse'
> > /usr/src/SGI/checkout2/linux-2.3-xfs/linux/include/linux/fs.h:1034: previous dec
> > laration of `brelse'
> 
> 
> One workaround for this problem (until its fixed properly)
> is to turn ON CONFIG_PAGE_BUF_META ...
Actually CONFIG_PAGE_BUF_META is the correct thing to do anyways.
We swatshed a couple more bugs in the pagebuf meta data path.

Support for buf_t metat data will be removed at some point.

I think I know where the problem started... I'll fix it.

> 
> 
> --------------------------------------------------------------------------
> Rajagopal Ananthanarayanan ("ananth")
> Member Technical Staff, SGI.
> --------------------------------------------------------------------------

From owner-linux-xfs@oss.sgi.com Mon Apr 17 16:29:18 2000
Received:  by oss.sgi.com id <S305169AbQDQX3J>;
	Mon, 17 Apr 2000 16:29:09 -0700
Received: from dukat.scot.redhat.com ([195.89.149.246]:3084 "EHLO
        dukat.scot.redhat.com") by oss.sgi.com with ESMTP
	id <S305167AbQDQX2n>; Mon, 17 Apr 2000 16:28:43 -0700
Received: (from sct@localhost)
	by dukat.scot.redhat.com (8.9.3/8.9.3) id AAA05310;
	Tue, 18 Apr 2000 00:27:52 +0100
Date:   Tue, 18 Apr 2000 00:27:52 +0100
From:   "Stephen C. Tweedie" <sct@redhat.com>
To:     Steve Lord <lord@sgi.com>
Cc:     Phil Schwan <phil@linuxcare.com>, linux-xfs@oss.sgi.com
Subject: Re: XFS as Root filesystem
Message-ID: <20000418002752.F3916@redhat.com>
References: <phil@linuxcare.com> <200004131528.KAA07085@jen.americas.sgi.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 1.0.1i
In-Reply-To: <200004131528.KAA07085@jen.americas.sgi.com>; from lord@sgi.com on Thu, Apr 13, 2000 at 10:28:23AM -0500
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing

Hi,

On Thu, Apr 13, 2000 at 10:28:23AM -0500, Steve Lord wrote:
> 
> This in itself looks reasonable, but Stephen Tweedie mentioned detecting
> read only devices and refusing to do the recovery - and that there was
> code which did this in the latest ext3 cut.

It's trivial: just a

			if (is_read_only(sb->s_dev)) {
				printk(KERN_ERR "EXT3-fs: write access unavailable, cannot proceed.\n");
				return -EROFS;
			}

before attempting the recovery.  That does the readonly check on the
underlying media rather than on the current filesystem state.

--Stephen

From owner-linux-xfs@oss.sgi.com Mon Apr 17 17:29:03 2000
Received:  by oss.sgi.com id <S305170AbQDRA2o>;
	Mon, 17 Apr 2000 17:28:44 -0700
Received: from [216.208.98.2] ([216.208.98.2]:62204 "EHLO moiraine.off.net")
	by oss.sgi.com with ESMTP id <S305167AbQDRA22>;
	Mon, 17 Apr 2000 17:28:28 -0700
Received: (from phil@localhost)
	by moiraine.off.net (8.9.3/8.9.3) id VAA04043
	for linux-xfs@oss.sgi.com; Mon, 17 Apr 2000 21:36:28 -0400
Date:   Mon, 17 Apr 2000 21:36:28 -0400
From:   Phil Schwan <phil@linuxcare.com>
To:     linux-xfs@oss.sgi.com
Subject: TAKE - sync data before remounting
Message-ID: <20000417213628.C649@linuxcare.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 0.95.4us
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing

Adds small fix to remount, to sync data before allowing the FS to
become read-only.

Modid:  2.3.99pre2-xfs:slinx:58149a
Date:  Mon Apr 17 17:27:46 PDT 2000

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

linux/fs/xfs/linux/xfs_super.c - 1.61
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/linux/fs/xfs/linux/xfs_super.c.diff?r1=text&tr1=1.61&r2=text&tr2=1.60&f=h
	- Adds a call to PVFS_SYNC before allowing FS to become read-only

From owner-linux-xfs@oss.sgi.com Mon Apr 17 17:31:33 2000
Received:  by oss.sgi.com id <S305171AbQDRAbO>;
	Mon, 17 Apr 2000 17:31:14 -0700
Received: from [216.208.98.2] ([216.208.98.2]:8701 "EHLO moiraine.off.net")
	by oss.sgi.com with ESMTP id <S305167AbQDRAbE>;
	Mon, 17 Apr 2000 17:31:04 -0700
Received: (from phil@localhost)
	by moiraine.off.net (8.9.3/8.9.3) id VAA04060
	for linux-xfs@oss.sgi.com; Mon, 17 Apr 2000 21:39:06 -0400
Date:   Mon, 17 Apr 2000 21:39:06 -0400
From:   Phil Schwan <phil@linuxcare.com>
To:     linux-xfs@oss.sgi.com
Subject: Re: XFS as Root filesystem
Message-ID: <20000417213906.D649@linuxcare.com>
References: <200004031359.IAA31585@jen.americas.sgi.com> <005601bf9dc0$64d9a4d0$a6e5a9ca@aries> <38EB2FEA.E22A0E8B@ep-ag.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 0.95.4us
In-Reply-To: <38EB2FEA.E22A0E8B@ep-ag.com>; from Klaus Strebel on Wed, Apr 05, 2000 at 02:22:02PM +0200
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing

Ok, with the latest tree, I can mount XFS as my root filesystem and
play around merrily.  Remounting seems to work, as well as log replay
while mounted read-only.  Kindly let me know if trouble remains.

-Phil

-- 
Phil Schwan, Captain Popetastic, Linuxcare Canada

From owner-linux-xfs@oss.sgi.com Mon Apr 17 18:02:04 2000
Received:  by oss.sgi.com id <S305172AbQDRBBz>;
	Mon, 17 Apr 2000 18:01:55 -0700
Received: from vader.inow.com ([207.5.52.10]:40966 "EHLO vader.inow.com")
	by oss.sgi.com with ESMTP id <S305167AbQDRBBk>;
	Mon, 17 Apr 2000 18:01:40 -0700
Received: from opensourcegroup.com (56.pool03.iqci.net [207.168.169.56])
	by vader.inow.com (8.9.3/8.9.3) with ESMTP id SAA13057
	for <linux-xfs@oss.sgi.com>; Mon, 17 Apr 2000 18:01:39 -0700
Message-ID: <38FBB407.1F9B6C90@opensourcegroup.com>
Date:   Mon, 17 Apr 2000 18:01:59 -0700
From:   Rob Aagaard <rob@opensourcegroup.com>
Organization: Open Source Group
X-Mailer: Mozilla 4.72 [en] (X11; U; Linux 2.3.99-pre2 i686)
X-Accept-Language: en
MIME-Version: 1.0
To:     linux-xfs@oss.sgi.com
Subject: Simple XFS read?
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing

How complicated would it be to have a simple XFS reading program?

Would this be an involved process? or something trivial?

The reason I am asking is because of programs like grub and milo,
bootloaders
that actually read the filesystem to find the kernel (instead of
building a block map like lilo), and they would need updating before XFS
could take over as the primary filesystem for linux. ( A big goal, but
if the current XFS is of pre-beta quality, I can't wait for the actual
release )

Thanks,
	Rob

(Flames may be sent directly, I like having one really good mailing list
out there)

From owner-linux-xfs@oss.sgi.com Mon Apr 17 18:27:24 2000
Received:  by oss.sgi.com id <S305174AbQDRB1E>;
	Mon, 17 Apr 2000 18:27:04 -0700
Received: from deliverator.sgi.com ([204.94.214.10]:8215 "EHLO
        deliverator.sgi.com") by oss.sgi.com with ESMTP id <S305167AbQDRB0j>;
	Mon, 17 Apr 2000 18:26:39 -0700
Received: from ledzep.cray.com (ledzep.cray.com [137.38.226.97]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id SAA23631
	for <linux-xfs@oss.sgi.com>; Mon, 17 Apr 2000 18:21:54 -0700 (PDT)
	mail_from (lord@sgi.com)
Received: from ironwood-e185.americas.sgi.com (ironwood.cray.com [128.162.185.212]) by ledzep.cray.com (SGI-SGI-8.9.3/craymail-smart-nospam1.0) with ESMTP id UAA28125; Mon, 17 Apr 2000 20:24:06 -0500 (CDT)
Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.184.86]) by ironwood-e185.americas.sgi.com (8.8.4/SGI-ironwood-e1.4) with ESMTP id UAA26191; Mon, 17 Apr 2000 20:23:58 -0500 (CDT)
From:   Steve Lord <lord@sgi.com>
Received: from jen.americas.sgi.com by jen.americas.sgi.com (8.9.3/SGI-client.1.6) via ESMTP id TAA02654; Mon, 17 Apr 2000 19:24:03 -0500
Message-Id: <200004180024.TAA02654@jen.americas.sgi.com>
To:     Rob Aagaard <rob@opensourcegroup.com>
cc:     linux-xfs@oss.sgi.com
Subject: Re: Simple XFS read? 
In-reply-to: Your message of "Mon, 17 Apr 2000 18:01:59 PDT
Date:   Mon, 17 Apr 2000 19:24:03 -0500
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing

> How complicated would it be to have a simple XFS reading program?
> 
> Would this be an involved process? or something trivial?
> 
> The reason I am asking is because of programs like grub and milo,
> bootloaders
> that actually read the filesystem to find the kernel (instead of
> building a block map like lilo), and they would need updating before XFS
> could take over as the primary filesystem for linux. ( A big goal, but
> if the current XFS is of pre-beta quality, I can't wait for the actual
> release )
> 
> Thanks,
> 	Rob
> 
> (Flames may be sent directly, I like having one really good mailing list
> out there)


If you mean actually do the mapping from a path name to an inode and
then get the file blocks without kernel support, then the amount of code
involved is somewhat large - given the potential meta-data structures
you might have to read to traverse a directory and then read in extents
to figure out where the disk blocks are.

There is also the issue of dealling witha filesystem which needs recovery
running on it - the meta-data may not be consistent until that happens.

However, ignoring the latter problem, take a look at the libsim library
in cmd/xfs/sim/src - this is the XFS code built in user space for use
by commands. There is still not enough code here - none of the
user space tools do path name traversal, so the lookup code is not compiled
in user space, although it would be possible to add this.

However, given an inode number xfs_iget() gets you an inode, and xfs_bmapi
retuns a mapping of file offsets to disk block numbers.

xfs_logprint in cmd/xfs/logprint is probably the simplest user space
command which opens a filesystem from user space - it would give
you the infrastructure to make the calls to open the filesystem.



Good Luck!

Steve

p.s. the xfs_bmap command contains an example of how to get the disk
block locations for file data out of the kernel - I suspect this is
what lilo would have to use.


From owner-linux-xfs@oss.sgi.com Mon Apr 17 18:43:55 2000
Received:  by oss.sgi.com id <S305163AbQDRBno>;
	Mon, 17 Apr 2000 18:43:44 -0700
Received: from deliverator.sgi.com ([204.94.214.10]:50459 "EHLO
        deliverator.sgi.com") by oss.sgi.com with ESMTP id <S305161AbQDRBnX>;
	Mon, 17 Apr 2000 18:43:23 -0700
Received: from ledzep.cray.com (ledzep.cray.com [137.38.226.97]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id SAA26025
	for <linux-xfs@oss.sgi.com>; Mon, 17 Apr 2000 18:38:38 -0700 (PDT)
	mail_from (mostek@sgi.com)
Received: from ironwood-e185.americas.sgi.com (ironwood.cray.com [128.162.185.212]) by ledzep.cray.com (SGI-SGI-8.9.3/craymail-smart-nospam1.0) with ESMTP id UAA63588; Mon, 17 Apr 2000 20:40:50 -0500 (CDT)
Received: from fsgi344.americas.sgi.com (fsgi344.americas.sgi.com [128.162.184.15]) by ironwood-e185.americas.sgi.com (8.8.4/SGI-ironwood-e1.4) with ESMTP id UAA26571; Mon, 17 Apr 2000 20:40:42 -0500 (CDT)
From:   Jim Mostek <mostek@sgi.com>
Received: by fsgi344.americas.sgi.com (980427.SGI.8.8.8/SGI-client.1.6) id UAA63575; Mon, 17 Apr 2000 20:40:48 -0500 (CDT)
Message-Id: <200004180140.UAA63575@fsgi344.americas.sgi.com>
Subject: Re: Simple XFS read?
To:     lord@sgi.com (Steve Lord)
Date:   Mon, 17 Apr 2000 20:40:48 -0500 (CDT)
Cc:     rob@opensourcegroup.com (Rob Aagaard), linux-xfs@oss.sgi.com
In-Reply-To: <200004180024.TAA02654@jen.americas.sgi.com> from "Steve Lord" at Apr 17, 2000 07:24:03 PM
X-Mailer: ELM [version 2.5 PL2]
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing


You can also use the xfs_db command.
With this command you can walk the path ...

Do a help.

For example,

sb 0
p

prints the super block and you can see the root inode
number, usually 128.

inode 128
p

shows the inode and its contents. If the inode has all
the components, you will see these listed with their inode
#s and can then do

inode <new num>
p


Until you get there.

So, you could build a simple perl script that would use
xfs_db ...

xfs_db -r <dev>

If the log is dirty, problems. you could mount/unmout first
to make sure recovery ran and cleaned it up.

Enjoy,

Jim

If the inode/directory is in btree blocks, walking this
tree and find/printing all the blocks is left as an exercise
to the reader.

>
>> How complicated would it be to have a simple XFS reading program?
>> 
>> Would this be an involved process? or something trivial?
>> 
>> The reason I am asking is because of programs like grub and milo,
>> bootloaders
>> that actually read the filesystem to find the kernel (instead of
>> building a block map like lilo), and they would need updating before XFS
>> could take over as the primary filesystem for linux. ( A big goal, but
>> if the current XFS is of pre-beta quality, I can't wait for the actual
>> release )
>> 
>> Thanks,
>> 	Rob
>> 
>> (Flames may be sent directly, I like having one really good mailing list
>> out there)
>
>
>If you mean actually do the mapping from a path name to an inode and
>then get the file blocks without kernel support, then the amount of code
>involved is somewhat large - given the potential meta-data structures
>you might have to read to traverse a directory and then read in extents
>to figure out where the disk blocks are.
>
>There is also the issue of dealling witha filesystem which needs recovery
>running on it - the meta-data may not be consistent until that happens.
>
>However, ignoring the latter problem, take a look at the libsim library
>in cmd/xfs/sim/src - this is the XFS code built in user space for use
>by commands. There is still not enough code here - none of the
>user space tools do path name traversal, so the lookup code is not compiled
>in user space, although it would be possible to add this.
>
>However, given an inode number xfs_iget() gets you an inode, and xfs_bmapi
>retuns a mapping of file offsets to disk block numbers.
>
>xfs_logprint in cmd/xfs/logprint is probably the simplest user space
>command which opens a filesystem from user space - it would give
>you the infrastructure to make the calls to open the filesystem.
>
>
>
>Good Luck!
>
>Steve
>
>p.s. the xfs_bmap command contains an example of how to get the disk
>block locations for file data out of the kernel - I suspect this is
>what lilo would have to use.
>


From owner-linux-xfs@oss.sgi.com Mon Apr 17 18:47:04 2000
Received:  by oss.sgi.com id <S305167AbQDRBqy>;
	Mon, 17 Apr 2000 18:46:54 -0700
Received: from deliverator.sgi.com ([204.94.214.10]:27420 "EHLO
        deliverator.sgi.com") by oss.sgi.com with ESMTP id <S305161AbQDRBqi>;
	Mon, 17 Apr 2000 18:46:38 -0700
Received: from ledzep.cray.com (ledzep.cray.com [137.38.226.97]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id SAA26331
	for <linux-xfs@oss.sgi.com>; Mon, 17 Apr 2000 18:41:53 -0700 (PDT)
	mail_from (lord@sgi.com)
Received: from ironwood-e185.americas.sgi.com (ironwood.cray.com [128.162.185.212]) by ledzep.cray.com (SGI-SGI-8.9.3/craymail-smart-nospam1.0) with ESMTP id UAA64437; Mon, 17 Apr 2000 20:44:06 -0500 (CDT)
Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.184.86]) by ironwood-e185.americas.sgi.com (8.8.4/SGI-ironwood-e1.4) with ESMTP id UAA26663; Mon, 17 Apr 2000 20:43:58 -0500 (CDT)
From:   Steve Lord <lord@sgi.com>
Received: from jen.americas.sgi.com by jen.americas.sgi.com (8.9.3/SGI-client.1.6) via ESMTP id TAA02688; Mon, 17 Apr 2000 19:44:02 -0500
Message-Id: <200004180044.TAA02688@jen.americas.sgi.com>
To:     Jim Mostek <mostek@sgi.com>
cc:     rob@opensourcegroup.com (Rob Aagaard), linux-xfs@oss.sgi.com
Subject: Re: Simple XFS read? 
In-reply-to: Your message of "Mon, 17 Apr 2000 20:40:48 CDT
Date:   Mon, 17 Apr 2000 19:44:02 -0500
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing



Jim,

Grub is a bootloader (I think) so far as I know, it is running before
the kernel - it needs to be self contained, sort of like sash on Irix.

Steve

> 
> You can also use the xfs_db command.
> With this command you can walk the path ...
> 
> Do a help.
> 
> For example,
> 
> sb 0
> p
> 
> prints the super block and you can see the root inode
> number, usually 128.
> 
> inode 128
> p
> 
> shows the inode and its contents. If the inode has all
> the components, you will see these listed with their inode
> #s and can then do
> 
> inode <new num>
> p
> 
> 
> Until you get there.
> 
> So, you could build a simple perl script that would use
> xfs_db ...
> 
> xfs_db -r <dev>
> 
> If the log is dirty, problems. you could mount/unmout first
> to make sure recovery ran and cleaned it up.
> 
> Enjoy,
> 
> Jim
> 

From owner-linux-xfs@oss.sgi.com Tue Apr 18 00:09:23 2000
Received:  by oss.sgi.com id <S305179AbQDRHJE>;
	Tue, 18 Apr 2000 00:09:04 -0700
Received: from www.npw.net ([195.212.73.17]:16658 "EHLO mail.npw.net")
	by oss.sgi.com with ESMTP id <S305161AbQDRHIe>;
	Tue, 18 Apr 2000 00:08:34 -0700
Received: from npw.net (pec-104-19.tnt5.s2.uunet.de [149.225.104.19])
	by mail.npw.net (8.9.3/8.9.3) with ESMTP id KAA29268;
	Tue, 18 Apr 2000 10:06:42 +0200
Message-ID: <38FC24ED.DE067E84@npw.net>
Date:   Tue, 18 Apr 2000 11:03:41 +0200
From:   Philipp Baer <ph_baer@npw.net>
X-Mailer: Mozilla 4.72 [en] (X11; I; Linux 2.3.99-pre5 i586)
X-Accept-Language: en
MIME-Version: 1.0
To:     cattelan@thebarn.com
CC:     linux-xfs@oss.sgi.com
Subject: Re: latest xfs source does not build / crash when mounting floppy (auto)
References: <Pine.SOL.4.10.10004171408240.3568-100000@ribbit.CS.Berkeley.EDU>
		<38FB812C.EAD536B7@sgi.com> <14587.35504.996144.26996Q@gibble.americas.sgi.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing

cattelan@thebarn.com wrote:
> 
> At Mon, 17 Apr 2000 14:25:00 -0700,
> Rajagopal Ananthanarayanan <ananth@sgi.com> wrote:
> >
> >
> > Kip Macy wrote:
> > >
> > > make -C xfs modules
> > > make[2]: Entering directory `/usr/src/SGI/checkout2/linux-2.3-xfs/linux/fs/xfs'
> > > gcc -D__KERNEL__ -I/usr/src/SGI/checkout2/linux-2.3-xfs/linux/include -Wall -Wst
> > > rict-prototypes -O2 -pipe   -DCPU=686 -march=i686 -fno-strict-aliasing -DMODULE
> > > -DMODVERSIONS -include /usr/src/SGI/checkout2/linux-2.3-xfs/linux/include/linux/
> > > modversions.h -g3 -Wno-unused  -Wno-unknown-pragmas -Wno-parentheses -Wno-uninit
> > > ialized -I./linux -I./pseudo-inc -I. -D_KERNEL -funsigned-char   -DEXPORT_SYMTAB
> > >  -c xfs_log_recover.c
> > > In file included from xfs_buf.h:47,
> > >                  from xfs_log_recover.c:46:
> > > pseudo-inc/sys/buf.h:331: conflicting types for `bread'
> > > /usr/src/SGI/checkout2/linux-2.3-xfs/linux/include/linux/fs.h:1046: previous dec
> > > laration of `bread'
> > > pseudo-inc/sys/buf.h:339: conflicting types for `brelse'
> > > /usr/src/SGI/checkout2/linux-2.3-xfs/linux/include/linux/fs.h:1034: previous dec
> > > laration of `brelse'
> >
> >
> > One workaround for this problem (until its fixed properly)
> > is to turn ON CONFIG_PAGE_BUF_META ...
> Actually CONFIG_PAGE_BUF_META is the correct thing to do anyways.
> We swatshed a couple more bugs in the pagebuf meta data path.
> 
> Support for buf_t metat data will be removed at some point.
> 
> I think I know where the problem started... I'll fix it.

Hi, I'm new to this mailinglist. I just started watching the
activities of this project, because it is really very annoying
to wait for an fsck to finish...!!! <g>

Yesterday, I checked out the current source-tree. After extracting
the XFS changes from linux-2.3-xfs and applying it to the
linux-2.3.99pre5 tree (and fixing some incompatibilities), I faced
the same problem mentioned above.


I think, this line caused the error:

--- xfs_os_defs.h ---
#ifdef NEED_FS_H
# include <linux/fs.h>
#endif
--- xfs_os_defs.h ---

When I undefine NEED_FS_H, the sources compile without any problems.
(bread() and brelse() are declared differently in fs.h (buffer_head))


As you can see in the subject line, there might be another (more or
less) critical problem: When I try to mount my floppy - the xfs-drivers
are compiled into the kernel - my system is halted (fstab: filesystem: 
auto).
I'll have to do this one more time to get the errormessage, but has
anybody seen this problem before?


So long,
ciao, phb <ph_baer@npw.net>

Btw.:  Is anybody interested in the 2.3.99pre5-XFS-Patch? I am no
kernel-
  hacker/good programmer! I even don't know, if everything works, but it
  compiles... ;-)))


From owner-linux-xfs@oss.sgi.com Tue Apr 18 07:20:35 2000
Received:  by oss.sgi.com id <S305181AbQDROU0>;
	Tue, 18 Apr 2000 07:20:26 -0700
Received: from nic-31-c26-223.mn.mediaone.net ([24.31.26.223]:27654 "EHLO
        lupo.thebarn.com") by oss.sgi.com with ESMTP id <S305161AbQDROUH>;
	Tue, 18 Apr 2000 07:20:07 -0700
Received: from thebarn.com (localhost [127.0.0.1])
	by lupo.thebarn.com (8.9.3/8.9.1) with ESMTP id JAA10530;
	Tue, 18 Apr 2000 09:19:45 -0500 (CDT)
Message-ID: <38FC6F00.81868428@thebarn.com>
Date:   Tue, 18 Apr 2000 09:19:45 -0500
From:   Russell Cattelan <cattelan@thebarn.com>
X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 4.0-STABLE i386)
X-Accept-Language: en
MIME-Version: 1.0
To:     Philipp Baer <ph_baer@npw.net>
CC:     linux-xfs@oss.sgi.com
Subject: Re: latest xfs source does not build / crash when mounting floppy (auto)
References: <Pine.SOL.4.10.10004171408240.3568-100000@ribbit.CS.Berkeley.EDU>
			<38FB812C.EAD536B7@sgi.com> <14587.35504.996144.26996Q@gibble.americas.sgi.com> <38FC24ED.DE067E84@npw.net>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing

Philipp Baer wrote:

>

Correct.
Last night I was trying out the different builds trying find
out exactly why linux/fs.h got included in this file.
I could come with any case where it needed it.

Just go ahead and removed the NEED_FS_H line
I'll check this change in later today.

>
> I think, this line caused the error:
>
> --- xfs_os_defs.h ---
> #ifdef NEED_FS_H
> # include <linux/fs.h>
> #endif
> --- xfs_os_defs.h ---
>
> When I undefine NEED_FS_H, the sources compile without any problems.
> (bread() and brelse() are declared differently in fs.h (buffer_head))
>
> As you can see in the subject line, there might be another (more or
> less) critical problem: When I try to mount my floppy - the xfs-drivers
> are compiled into the kernel - my system is halted (fstab: filesystem:
> auto).
> I'll have to do this one more time to get the errormessage, but has
> anybody seen this problem before?
>
> So long,
> ciao, phb <ph_baer@npw.net>
>
> Btw.:  Is anybody interested in the 2.3.99pre5-XFS-Patch? I am no
> kernel-
>   hacker/good programmer! I even don't know, if everything works, but it
>   compiles... ;-)))

--
Russell Cattelan
cattelan@thebarn.com




From owner-linux-xfs@oss.sgi.com Tue Apr 18 07:56:45 2000
Received:  by oss.sgi.com id <S305182AbQDRO4g>;
	Tue, 18 Apr 2000 07:56:36 -0700
Received: from [216.208.98.2] ([216.208.98.2]:45305 "EHLO moiraine.off.net")
	by oss.sgi.com with ESMTP id <S305161AbQDRO4W>;
	Tue, 18 Apr 2000 07:56:22 -0700
Received: (from phil@localhost)
	by moiraine.off.net (8.9.3/8.9.3) id MAA05286;
	Tue, 18 Apr 2000 12:03:43 -0400
Date:   Tue, 18 Apr 2000 12:03:43 -0400
From:   Phil Schwan <phil@linuxcare.com>
To:     Russell Cattelan <cattelan@thebarn.com>
Cc:     Philipp Baer <ph_baer@npw.net>, linux-xfs@oss.sgi.com
Subject: Re: latest xfs source does not build / crash when mounting floppy (auto)
Message-ID: <20000418120343.F649@linuxcare.com>
References: <Pine.SOL.4.10.10004171408240.3568-100000@ribbit.CS.Berkeley.EDU> <38FB812C.EAD536B7@sgi.com> <14587.35504.996144.26996Q@gibble.americas.sgi.com> <38FC24ED.DE067E84@npw.net> <38FC6F00.81868428@thebarn.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 0.95.4us
In-Reply-To: <38FC6F00.81868428@thebarn.com>; from Russell Cattelan on Tue, Apr 18, 2000 at 09:19:45AM -0500
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing

On Apr 18, Russell Cattelan wrote:
> Last night I was trying out the different builds trying find
> out exactly why linux/fs.h got included in this file.
> I could come with any case where it needed it.
> 
> Just go ahead and removed the NEED_FS_H line
> I'll check this change in later today.

We exchanged email about this last week--linux/fs.h contains the
prototype for is_read_only(), used in xlog_recover in the read-only
case.

I wasn't aware that the non-pagebuf case was still being maintained,
after Jim said that everyone should be using pagebuf.  Sorry about
that.

-Phil

From owner-linux-xfs@oss.sgi.com Tue Apr 18 09:10:37 2000
Received:  by oss.sgi.com id <S305184AbQDRQKR>;
	Tue, 18 Apr 2000 09:10:17 -0700
Received: from timbuk-fddi.cray.com ([128.162.8.102]:41704 "EHLO
        timbuk.cray.com") by oss.sgi.com with ESMTP id <S305161AbQDRQKJ>;
	Tue, 18 Apr 2000 09:10:09 -0700
Received: from clink.americas.sgi.com (clink.cray.com [128.162.84.70]) by timbuk.cray.com (8.8.8/CRI-gate-news-1.3) with ESMTP id LAA09001 for <linux-xfs@oss.sgi.com>; Tue, 18 Apr 2000 11:10:02 -0500 (CDT)
Received: (from lord@localhost) by clink.americas.sgi.com (980427.SGI.8.8.8/CRI-news-1.3) id LAA79745 for linux-xfs@oss.sgi.com; Tue, 18 Apr 2000 11:10:03 -0500 (CDT)
Date:   Tue, 18 Apr 2000 11:10:03 -0500 (CDT)
From:   Steve Lord <lord@sgi.com>
Message-Id: <200004181610.LAA79745@clink.americas.sgi.com>
To:     linux-xfs@oss.sgi.com
Subject: TAKE - backport kswapd changes from later kernels 
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing

Modid:  2.3.99pre2-xfs:slinx:58410a
Date:  Tue Apr 18 09:09:35 PDT 2000
Workarea:  clink.americas.sgi.com:/data/clink/io/lord/xfs-linux

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

linux/mm/vmscan.c - 1.24
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/linux/mm/vmscan.c.diff?r1=text&tr1=1.24&r2=text&tr2=1.23&f=h
	- Backport changes to kswapd into the xfs tree - this appeared to be having
	  bad interactions with XFS (memory corruption). I was able to do much more
	  with XFS after this change. [ The basic problem in kswapd was that it
	  ran for its complete timeslice even when there was nothing to do. ]


From owner-linux-xfs@oss.sgi.com Tue Apr 18 09:27:07 2000
Received:  by oss.sgi.com id <S305185AbQDRQ06>;
	Tue, 18 Apr 2000 09:26:58 -0700
Received: from pneumatic-tube.sgi.com ([204.94.214.22]:45387 "EHLO
        pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP
	id <S305161AbQDRQ0e>; Tue, 18 Apr 2000 09:26:34 -0700
Received: from ledzep.cray.com (ledzep.cray.com [137.38.226.97]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id JAA06859
	for <linux-xfs@oss.sgi.com>; Tue, 18 Apr 2000 09:30:34 -0700 (PDT)
	mail_from (cattelan@thebarn.com)
From:   cattelan@thebarn.com
Received: from ironwood-e185.americas.sgi.com (ironwood.cray.com [128.162.185.212]) by ledzep.cray.com (SGI-SGI-8.9.3/craymail-smart-nospam1.0) with ESMTP id LAA32167; Tue, 18 Apr 2000 11:25:17 -0500 (CDT)
Received: from gibble.americas.sgi.com (root@gibble.americas.sgi.com [128.162.195.80]) by ironwood-e185.americas.sgi.com (8.8.4/SGI-ironwood-e1.4) with ESMTP id LAA12671; Tue, 18 Apr 2000 11:25:10 -0500 (CDT)
Received: from gibble.americas.sgi.com by gibble.americas.sgi.com (8.9.3/SGI-client.1.6) via ESMTP id LAA02927; Tue, 18 Apr 2000 11:25:16 -0500
Date:   Tue, 18 Apr 2000 11:25:14 -0500
Message-ID: <14588.35946.9296.45539U@gibble.americas.sgi.com>
To:     phil@linuxcare.com
Cc:     ph_baer@npw.net, linux-xfs@oss.sgi.com
Subject: Re: latest xfs source does not build / crash when mounting floppy (auto)
In-Reply-To: In your message of "Tue, 18 Apr 2000 12:03:43 -0400"
	<20000418120343.F649@linuxcare.com>
References: <Pine.SOL.4.10.10004171408240.3568-100000@ribbit.CS.Berkeley.EDU>
	<38FB812C.EAD536B7@sgi.com>
	<14587.35504.996144.26996Q@gibble.americas.sgi.com>
	<38FC24ED.DE067E84@npw.net>
	<38FC6F00.81868428@thebarn.com>
	<20000418120343.F649@linuxcare.com>
User-Agent: Wanderlust/1.0.3 (Notorious) tm/7.108 XEmacs/21.1 (Bryce Canyon)
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing

At Tue, 18 Apr 2000 12:03:43 -0400,
Phil Schwan <phil@linuxcare.com> wrote:
> 
> 
> On Apr 18, Russell Cattelan wrote:
> > Last night I was trying out the different builds trying find
> > out exactly why linux/fs.h got included in this file.
> > I could come with any case where it needed it.
> > 
> > Just go ahead and removed the NEED_FS_H line
> > I'll check this change in later today.
> 
> We exchanged email about this last week--linux/fs.h contains the
> prototype for is_read_only(), used in xlog_recover in the read-only
> case.
That's what is was for... I couldn't remember wich function proto was
needed.

libsim needs to compile with the but_t macros, so even though we are
very close to using pagebuf meta data, the buf_t case need to compile.

I know this is a pain... the first month of porting was noting but
compiler errors.

I think I know to fix this... I'll give it a shot and let you know


> 
> I wasn't aware that the non-pagebuf case was still being maintained,
> after Jim said that everyone should be using pagebuf.  Sorry about
> that.
> 
> -Phil

From owner-linux-xfs@oss.sgi.com Tue Apr 18 09:30:38 2000
Received:  by oss.sgi.com id <S305186AbQDRQaS>;
	Tue, 18 Apr 2000 09:30:18 -0700
Received: from pneumatic-tube.sgi.com ([204.94.214.22]:6732 "EHLO
        pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP
	id <S305161AbQDRQaI>; Tue, 18 Apr 2000 09:30:08 -0700
Received: from ledzep.cray.com (ledzep.cray.com [137.38.226.97]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id JAA08969
	for <linux-xfs@oss.sgi.com>; Tue, 18 Apr 2000 09:34:08 -0700 (PDT)
	mail_from (cattelan@thebarn.com)
From:   cattelan@thebarn.com
Received: from ironwood-e185.americas.sgi.com (ironwood.cray.com [128.162.185.212]) by ledzep.cray.com (SGI-SGI-8.9.3/craymail-smart-nospam1.0) with ESMTP id LAA04118 for <linux-xfs@oss.sgi.com>; Tue, 18 Apr 2000 11:28:52 -0500 (CDT)
Received: from gibble.americas.sgi.com (root@gibble.americas.sgi.com [128.162.195.80]) by ironwood-e185.americas.sgi.com (8.8.4/SGI-ironwood-e1.4) with ESMTP id LAA12878; Tue, 18 Apr 2000 11:28:43 -0500 (CDT)
Received: from gibble.americas.sgi.com by gibble.americas.sgi.com (8.9.3/SGI-client.1.6) via ESMTP id LAA02932; Tue, 18 Apr 2000 11:28:49 -0500
Date:   Tue, 18 Apr 2000 11:28:46 -0500
Message-ID: <14588.36158.760804.99827N@gibble.americas.sgi.com>
To:     lord@sgi.com
Cc:     linux-xfs@oss.sgi.com
Subject: Re: TAKE - backport kswapd changes from later kernels 
In-Reply-To: In your message of "Tue, 18 Apr 2000 11:10:03 -0500 (CDT)"
	<200004181610.LAA79745@clink.americas.sgi.com>
References: <200004181610.LAA79745@clink.americas.sgi.com>
User-Agent: Wanderlust/1.0.3 (Notorious) tm/7.108 XEmacs/21.1 (Bryce Canyon)
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing


What to do you think... time to move the tree to pre5?
At Tue, 18 Apr 2000 11:10:03 -0500 (CDT),
Steve Lord <lord@sgi.com> wrote:
> 
> 
> Modid:  2.3.99pre2-xfs:slinx:58410a
> Date:  Tue Apr 18 09:09:35 PDT 2000
> Workarea:  clink.americas.sgi.com:/data/clink/io/lord/xfs-linux
> 
> The following file(s) were checked into:
>   bonnie.engr.sgi.com:/isms/slinx/2.3.99pre2-xfs
> 
> linux/mm/vmscan.c - 1.24
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/> linux/mm/vmscan.c.diff?r1=text&tr1=1.24&r2=text&tr2=1.23&f=h
> 	- Backport changes to kswapd into the xfs tree - this appeared to be having
> 	  bad interactions with XFS (memory corruption). I was able to do much more
> 	  with XFS after this change. [ The basic problem in kswapd was that it
> 	  ran for its complete timeslice even when there was nothing to do. ]

From owner-linux-xfs@oss.sgi.com Tue Apr 18 10:54:57 2000
Received:  by oss.sgi.com id <S305187AbQDRRys>;
	Tue, 18 Apr 2000 10:54:48 -0700
Received: from deliverator.sgi.com ([204.94.214.10]:45408 "EHLO
        deliverator.sgi.com") by oss.sgi.com with ESMTP id <S305161AbQDRRyX>;
	Tue, 18 Apr 2000 10:54:23 -0700
Received: from ledzep.cray.com (ledzep.cray.com [137.38.226.97]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id KAA00745
	for <linux-xfs@oss.sgi.com>; Tue, 18 Apr 2000 10:49:33 -0700 (PDT)
	mail_from (lord@sgi.com)
Received: from ironwood-e185.americas.sgi.com (ironwood.cray.com [128.162.185.212]) by ledzep.cray.com (SGI-SGI-8.9.3/craymail-smart-nospam1.0) with ESMTP id MAA77167 for <linux-xfs@oss.sgi.com>; Tue, 18 Apr 2000 12:51:46 -0500 (CDT)
Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.184.86]) by ironwood-e185.americas.sgi.com (8.8.4/SGI-ironwood-e1.4) with ESMTP id MAA17193 for <linux-xfs@oss.sgi.com>; Tue, 18 Apr 2000 12:51:38 -0500 (CDT)
Received: from jen.americas.sgi.com by jen.americas.sgi.com (8.9.3/SGI-client.1.6) via ESMTP id MAA04682; Tue, 18 Apr 2000 12:51:43 -0500
Message-Id: <200004181751.MAA04682@jen.americas.sgi.com>
X-Mailer: exmh version 2.1.1 10/15/1999
To:     linux-xfs@oss.sgi.com
Subject: cscope opensourced (fwd)
Date:   Tue, 18 Apr 2000 12:51:42 -0500
From:   Steve Lord <lord@sgi.com>
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing


This is what we use internally for wading around the source code - for 
those of you who have asked about this go check out cscope.

Steve

------- Forwarded Message

http://cscope.sourceforge.net/

There is also a gui front end Cbrowser also available, see the link at
the bottom of the page.

Simon.


------- End of Forwarded Message




From owner-linux-xfs@oss.sgi.com Tue Apr 18 12:34:09 2000
Received:  by oss.sgi.com id <S305190AbQDRTd6>;
	Tue, 18 Apr 2000 12:33:58 -0700
Received: from [199.33.128.3] ([199.33.128.3]:34246 "HELO convert rfc822-to-8bit
        pioushqmailweb.pios.com") by oss.sgi.com with SMTP
	id <S305188AbQDRTdw>; Tue, 18 Apr 2000 12:33:52 -0700
Received: FROM pioushqmailbh.pios.com BY pioushqmailweb.pios.com ; Tue Apr 18 15:33:50 2000 -0400
Received: by pioushqmailbh.pios.com with Internet Mail Service (5.5.2650.21)
	id <23XM0DX3>; Tue, 18 Apr 2000 15:33:55 -0400
Message-ID: <264AE344EFFDD311AF040000F8662F4A59FDCE@pioushqntmail2.pios.com>
From:   "Vanco, Donald" <VANCOD@PIOS.com>
To:     "'linux-xfs@oss.sgi.com'" <linux-xfs@oss.sgi.com>
Subject: Greets & stupid newbie question
Date:   Tue, 18 Apr 2000 15:33:47 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 8BIT
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing

Hi all -
	I just signed on after attending an SGI event here in Cleveland,
Ohio (USA).  I've just compiled my 2.3.99 kernel and have pulled the files
for XFS - is there a how-to yet? ;)

	Newbie pointers appreciated, I'm combing the tarballs and the
archives as we speak...

Regards -
Don
³³³³³³³³³³³³³³³³³³³³³³³³³³³³³³³³³³³³³³³³³³³
Donald R. Vanco RHCE    Voice: 440-498-6793
Consulting Services       FAX: 440-498-5317
Pioneer-Standard, Inc.  pager: 888-773-0845
³³³³³³³³³³³³³³³³³³³³³³³³³³³³³³³³³³³³³³³³³³³ 

From owner-linux-xfs@oss.sgi.com Tue Apr 18 13:19:49 2000
Received:  by oss.sgi.com id <S305191AbQDRUTj>;
	Tue, 18 Apr 2000 13:19:39 -0700
Received: from deliverator.sgi.com ([204.94.214.10]:16393 "EHLO
        deliverator.sgi.com") by oss.sgi.com with ESMTP id <S305192AbQDRUJm>;
	Tue, 18 Apr 2000 13:09:42 -0700
Received: from ledzep.cray.com (ledzep.cray.com [137.38.226.97]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id NAA19023
	for <linux-xfs@oss.sgi.com>; Tue, 18 Apr 2000 13:04:57 -0700 (PDT)
	mail_from (lord@sgi.com)
Received: from ironwood-e185.americas.sgi.com (ironwood.cray.com [128.162.185.212]) by ledzep.cray.com (SGI-SGI-8.9.3/craymail-smart-nospam1.0) with ESMTP id PAA67975; Tue, 18 Apr 2000 15:08:24 -0500 (CDT)
Received: from pinky.americas.sgi.com (pinky.americas.sgi.com [128.162.184.21]) by ironwood-e185.americas.sgi.com (8.8.4/SGI-ironwood-e1.4) with ESMTP id PAA24381; Tue, 18 Apr 2000 15:08:17 -0500 (CDT)
From:   Steve Lord <lord@sgi.com>
Received: from pinky.americas.sgi.com by pinky.americas.sgi.com (980427.SGI.8.8.8/SGI-client.1.6) via ESMTP id PAA98131; Tue, 18 Apr 2000 15:08:19 -0500 (CDT)
Message-Id: <200004182008.PAA98131@pinky.americas.sgi.com>
To:     "Vanco, Donald" <VANCOD@PIOS.com>
cc:     "'linux-xfs@oss.sgi.com'" <linux-xfs@oss.sgi.com>
Subject: Re: Greets & stupid newbie question 
In-reply-to: Your message of "Tue, 18 Apr 2000 15:33:47 EDT
Date:   Tue, 18 Apr 2000 15:08:19 -0500
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing

> Hi all -
> 	I just signed on after attending an SGI event here in Cleveland,
> Ohio (USA).  I've just compiled my 2.3.99 kernel and have pulled the files
> for XFS - is there a how-to yet? ;)
> 
> 	Newbie pointers appreciated, I'm combing the tarballs and the
> archives as we speak...
> 
> Regards -
> Don
> 3333333333333333333333333333333333333333333
> Donald R. Vanco RHCE    Voice: 440-498-6793
> Consulting Services       FAX: 440-498-5317
> Pioneer-Standard, Inc.  pager: 888-773-0845
> 3333333333333333333333333333333333333333333 

OK, the tar archives are somewhat out of date - the cvs tree has the
one true code base. But you should be able to do a cvs update on top
of the tar archive.

There are several config options you need to set to get XFS into
the kernel. All options are at the bottom of the filesystems page
in xconfig, you need to turn on XFS - probably as a module,
plus the three page buf options (which we should merge). I
would also select Use PAGEBUF for metadata I/O, and select Native
for the filesystem architecture.

Once you have built your kernel you need to build the xfs commands.
Go into cmd/xfs and type make. You can also do a make install from
this location if you are on the machine where you want the commands.

To make a filesystem you need mkfs_xfs (or mkfs.xfs as it gets installed
as). This has lots of nasty options for various filesystem paramters, but

mkfs.xfs -f /dev/xxx -l size=16000b

is what I use normally, the "-l size=16000b" specifies a log of
16000 blocks which is bigger than the default.

If you have the kernel up and running and all the modules in the
right place then you should be able to mount the filesystem at
this point. (If you used modules then you will need to either load
them by hand via modprobe, or build in the kernel module loader).

Steve


From owner-linux-xfs@oss.sgi.com Tue Apr 18 13:58:39 2000
Received:  by oss.sgi.com id <S305192AbQDRU63>;
	Tue, 18 Apr 2000 13:58:29 -0700
Received: from pneumatic-tube.sgi.com ([204.94.214.22]:45673 "EHLO
        pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP
	id <S305188AbQDRU6T>; Tue, 18 Apr 2000 13:58:19 -0700
Received: from ledzep.cray.com (ledzep.cray.com [137.38.226.97]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id OAA06705
	for <linux-xfs@oss.sgi.com>; Tue, 18 Apr 2000 14:02:19 -0700 (PDT)
	mail_from (jtk@sgi.com)
Received: from ironwood-e185.americas.sgi.com (ironwood.cray.com [128.162.185.212]) by ledzep.cray.com (SGI-SGI-8.9.3/craymail-smart-nospam1.0) with ESMTP id PAA87634; Tue, 18 Apr 2000 15:57:02 -0500 (CDT)
Received: from tiki.americas.sgi.com (tiki.americas.sgi.com [128.162.195.11]) by ironwood-e185.americas.sgi.com (8.8.4/SGI-ironwood-e1.4) with ESMTP id PAA26906; Tue, 18 Apr 2000 15:56:54 -0500 (CDT)
From:   Ted Kline <jtk@sgi.com>
Received: by tiki.americas.sgi.com (980427.SGI.8.8.8/SGI-client.1.6) id PAA07187; Tue, 18 Apr 2000 15:57:00 -0500 (CDT)
Message-Id: <200004182057.PAA07187@tiki.americas.sgi.com>
Date:   Tue, 18 Apr 2000 15:57:00 -0500 (CDT)
To:     slinx-xfs@engr.sgi.com, linux-xfs@oss.sgi.com
Subject: TAKE - Fix XFS getdents "d_off" shuffling.
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing


All of the XFS getdents() routines were "shuffling" the d_off
field, as is normally done on vnodes-based implementations.
On Linux, the filldir() 'put' routine does the d_off shuffling,
so things were being double-shuffled.


Modid:  2.3.99pre2-xfs:slinx:58446a
Date:  Tue Apr 18 13:53:43 PDT 2000
Workarea:  tiki.americas.sgi.com:/data/clink/io/jtk/work-linux2.3-99

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

linux/fs/xfs/linux/xfs_to_linux.h - 1.12
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/linux/fs/xfs/linux/xfs_to_linux.h.diff?r1=text&tr1=1.12&r2=text&tr2=1.11&f=h
linux/fs/xfs/pseudo-inc/sys/uio.h - 1.8
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/linux/fs/xfs/pseudo-inc/sys/uio.h.diff?r1=text&tr1=1.8&r2=text&tr2=1.7&f=h
	- Change local XFS ia32_* to linux_*.

linux/fs/xfs/xfs_dir.c - 1.124
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/linux/fs/xfs/xfs_dir.c.diff?r1=text&tr1=1.124&r2=text&tr2=1.123&f=h
	- Change XFS getdents routines to not "shuffle" the d_off
	  field, as filldir() will do so for us.

linux/fs/xfs/xfs_dir2.c - 1.17
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/linux/fs/xfs/xfs_dir2.c.diff?r1=text&tr1=1.17&r2=text&tr2=1.16&f=h
	- Change local XFS ia32_* to linux_*.

linux/fs/xfs/xfs_dir2_block.c - 1.11
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/linux/fs/xfs/xfs_dir2_block.c.diff?r1=text&tr1=1.11&r2=text&tr2=1.10&f=h
linux/fs/xfs/xfs_dir2_leaf.c - 1.12
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/linux/fs/xfs/xfs_dir2_leaf.c.diff?r1=text&tr1=1.12&r2=text&tr2=1.11&f=h
linux/fs/xfs/xfs_dir2_sf.c - 1.15
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/linux/fs/xfs/xfs_dir2_sf.c.diff?r1=text&tr1=1.15&r2=text&tr2=1.14&f=h
	- Change XFS getdents routines to not "shuffle" the d_off
	  field, as filldir() will do so for us.

linux/fs/xfs/xfs_dir_leaf.c - 1.83
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/linux/fs/xfs/xfs_dir_leaf.c.diff?r1=text&tr1=1.83&r2=text&tr2=1.82&f=h
	- Change XFS getdents routines to not "shuffle" the d_off
	  field, as filldir() will do so for us.
	  Change local XFS ia32_* to linux_*.

linux/fs/xfs/xfs_dir_leaf.h - 1.27
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/linux/fs/xfs/xfs_dir_leaf.h.diff?r1=text&tr1=1.27&r2=text&tr2=1.26&f=h
	- Change "#ifdef __linux_" to "__BYTE_ORDER == __LITTLE_ENDIAN
	  for the v1 directory 'cookie' definition.


From owner-linux-xfs@oss.sgi.com Tue Apr 18 15:32:29 2000
Received:  by oss.sgi.com id <S305195AbQDRWcU>;
	Tue, 18 Apr 2000 15:32:20 -0700
Received: from Cantor.suse.de ([194.112.123.193]:54282 "HELO Cantor.suse.de")
	by oss.sgi.com with SMTP id <S305188AbQDRWb6>;
	Tue, 18 Apr 2000 15:31:58 -0700
Received: from Hermes.suse.de (Hermes.suse.de [194.112.123.136])
	by Cantor.suse.de (Postfix) with ESMTP
	id 5FEB51E24A; Wed, 19 Apr 2000 00:31:56 +0200 (MEST)
Received: from gruyere.muc.suse.de (gruyere.muc.suse.de [10.23.1.2])
	by Hermes.suse.de (Postfix) with ESMTP
	id 6776410A028; Wed, 19 Apr 2000 00:31:35 +0200 (MEST)
Received: by gruyere.muc.suse.de (Postfix, from userid 14446)
	id E5D9C2F36B; Wed, 19 Apr 2000 00:31:33 +0200 (MEST)
Date:   Wed, 19 Apr 2000 00:31:33 +0200
From:   "Andi Kleen" <ak@suse.de>
To:     Ted Kline <jtk@sgi.com>
Cc:     slinx-xfs@engr.sgi.com, linux-xfs@oss.sgi.com
Subject: Re: TAKE - Fix XFS getdents "d_off" shuffling.
Message-ID: <20000419003133.A12954@gruyere.muc.suse.de>
References: <200004182057.PAA07187@tiki.americas.sgi.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 1.0i
In-Reply-To: <200004182057.PAA07187@tiki.americas.sgi.com>; from jtk@sgi.com on Tue, Apr 18, 2000 at 03:57:00PM -0500
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing

On Tue, Apr 18, 2000 at 03:57:00PM -0500, Ted Kline wrote:
> 
> All of the XFS getdents() routines were "shuffling" the d_off
> field, as is normally done on vnodes-based implementations.
> On Linux, the filldir() 'put' routine does the d_off shuffling,
> so things were being double-shuffled.

Cool. While you're on it, could you fix getdents to check signals 
or alternatively return fewer entries (try Ctrl-C a find on XFS
on the kernel tree) 


-Andi


From owner-linux-xfs@oss.sgi.com Tue Apr 18 15:32:59 2000
Received:  by oss.sgi.com id <S305197AbQDRWck>;
	Tue, 18 Apr 2000 15:32:40 -0700
Received: from deliverator.sgi.com ([204.94.214.10]:21556 "EHLO
        deliverator.sgi.com") by oss.sgi.com with ESMTP id <S305188AbQDRWca>;
	Tue, 18 Apr 2000 15:32:30 -0700
Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via SMTP id PAA08213
	for <linux-xfs@oss.sgi.com>; Tue, 18 Apr 2000 15:27:44 -0700 (PDT)
	mail_from (dxm@snort.melbourne.sgi.com)
Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.55.149]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id IAA01877 for <@larry.melbourne.sgi.com:linux-xfs@oss.sgi.com>; Wed, 19 Apr 2000 08:31:10 +1000
Received: (from dxm@localhost) by snort.melbourne.sgi.com (980427.SGI.8.8.8/980728.SGI.AUTOCF) id IAA57076 for linux-xfs@oss.sgi.com; Wed, 19 Apr 2000 08:31:08 +1000 (EST)
Date:   Wed, 19 Apr 2000 08:31:08 +1000 (EST)
From:   dxm@snort.melbourne.sgi.com (Daniel Moore)
Message-Id: <200004182231.IAA57076@snort.melbourne.sgi.com>
To:     linux-xfs@oss.sgi.com
Subject: TAKE - endian fix
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing

Thanks Ted...

Modid:  2.3.99pre2-xfs:slinx:58462a
Date:  Tue Apr 18 15:30:20 PDT 2000
Workarea:  snort:/build1/people/dxm/isms/slinx-xfs

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

linux/fs/xfs/xfs_arch.h - 1.20
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/linux/fs/xfs/xfs_arch.h.diff?r1=text&tr1=1.20&r2=text&tr2=1.19&f=h
	- fix endian check


From owner-linux-xfs@oss.sgi.com Tue Apr 18 17:27:22 2000
Received:  by oss.sgi.com id <S305186AbQDSA1D>;
	Tue, 18 Apr 2000 17:27:03 -0700
Received: from pneumatic-tube.sgi.com ([204.94.214.22]:47485 "EHLO
        pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP
	id <S305185AbQDSA1A>; Tue, 18 Apr 2000 17:27:00 -0700
Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via SMTP id RAA04362
	for <linux-xfs@oss.sgi.com>; Tue, 18 Apr 2000 17:30:59 -0700 (PDT)
	mail_from (dxm@snort.melbourne.sgi.com)
Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.55.149]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id KAA02625 for <@larry.melbourne.sgi.com:linux-xfs@oss.sgi.com>; Wed, 19 Apr 2000 10:25:38 +1000
Received: (from dxm@localhost) by snort.melbourne.sgi.com (980427.SGI.8.8.8/980728.SGI.AUTOCF) id KAA41305 for linux-xfs@oss.sgi.com; Wed, 19 Apr 2000 10:25:37 +1000 (EST)
Date:   Wed, 19 Apr 2000 10:25:37 +1000 (EST)
From:   dxm@snort.melbourne.sgi.com (Daniel Moore)
Message-Id: <200004190025.KAA41305@snort.melbourne.sgi.com>
To:     linux-xfs@oss.sgi.com
Subject: TAKE - arch mods - bnobt + cntbt conversion
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing

   - AGF bugfixes
      - AGFL not yet mangled, not converted
      - watch out for A=B=C with auto converter
   - finish up bno and cnt btrees - convert data part of blocks
   - test making filesystem with many holes

Modid:  2.3.99pre2-xfs:slinx:58469a
Date:  Tue Apr 18 17:22:42 PDT 2000
Workarea:  snort:/build1/people/dxm/isms/slinx-xfs

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

cmd/xfs/db/check.c - 1.48
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/cmd/xfs/db/check.c.diff?r1=text&tr1=1.48&r2=text&tr2=1.47&f=h
cmd/xfs/db/freesp.c - 1.13
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/cmd/xfs/db/freesp.c.diff?r1=text&tr1=1.13&r2=text&tr2=1.12&f=h
cmd/xfs/mangle/agf.c - 1.3
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/cmd/xfs/mangle/agf.c.diff?r1=text&tr1=1.3&r2=text&tr2=1.2&f=h
cmd/xfs/mangle/inodes.c - 1.6
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/cmd/xfs/mangle/inodes.c.diff?r1=text&tr1=1.6&r2=text&tr2=1.5&f=h
cmd/xfs/mangle/xfs_mangle.c - 1.5
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/cmd/xfs/mangle/xfs_mangle.c.diff?r1=text&tr1=1.5&r2=text&tr2=1.4&f=h
cmd/xfs/mangle/xfs_mangle.h - 1.6
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/cmd/xfs/mangle/xfs_mangle.h.diff?r1=text&tr1=1.6&r2=text&tr2=1.5&f=h
linux/fs/xfs/xfs_alloc.c - 1.130
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/linux/fs/xfs/xfs_alloc.c.diff?r1=text&tr1=1.130&r2=text&tr2=1.129&f=h
linux/fs/xfs/xfs_alloc_btree.c - 1.59
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/linux/fs/xfs/xfs_alloc_btree.c.diff?r1=text&tr1=1.59&r2=text&tr2=1.58&f=h
linux/fs/xfs/xfs_bmap.c - 1.248
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/linux/fs/xfs/xfs_bmap.c.diff?r1=text&tr1=1.248&r2=text&tr2=1.247&f=h
linux/fs/xfs/xfs_btree.c - 1.81
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/linux/fs/xfs/xfs_btree.c.diff?r1=text&tr1=1.81&r2=text&tr2=1.80&f=h
linux/fs/xfs/xfs_fsops.c - 1.50
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/linux/fs/xfs/xfs_fsops.c.diff?r1=text&tr1=1.50&r2=text&tr2=1.49&f=h
linux/fs/xfs/xfs_ialloc_btree.c - 1.53
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/linux/fs/xfs/xfs_ialloc_btree.c.diff?r1=text&tr1=1.53&r2=text&tr2=1.52&f=h
linux/fs/xfs/xfsidbg.c - 1.134
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/linux/fs/xfs/xfsidbg.c.diff?r1=text&tr1=1.134&r2=text&tr2=1.133&f=h

From owner-linux-xfs@oss.sgi.com Tue Apr 18 18:06:42 2000
Received:  by oss.sgi.com id <S305182AbQDSBGd>;
	Tue, 18 Apr 2000 18:06:33 -0700
Received: from deliverator.sgi.com ([204.94.214.10]:8277 "EHLO
        deliverator.sgi.com") by oss.sgi.com with ESMTP id <S305181AbQDSBG2>;
	Tue, 18 Apr 2000 18:06:28 -0700
Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via SMTP id SAA24640
	for <linux-xfs@oss.sgi.com>; Tue, 18 Apr 2000 18:01:42 -0700 (PDT)
	mail_from (dxm@snort.melbourne.sgi.com)
Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.55.149]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id LAA02879 for <@larry.melbourne.sgi.com:linux-xfs@oss.sgi.com>; Wed, 19 Apr 2000 11:05:09 +1000
Received: (from dxm@localhost) by snort.melbourne.sgi.com (980427.SGI.8.8.8/980728.SGI.AUTOCF) id LAA54138 for linux-xfs@oss.sgi.com; Wed, 19 Apr 2000 11:05:09 +1000 (EST)
Date:   Wed, 19 Apr 2000 11:05:09 +1000 (EST)
From:   dxm@snort.melbourne.sgi.com (Daniel Moore)
Message-Id: <200004190105.LAA54138@snort.melbourne.sgi.com>
To:     linux-xfs@oss.sgi.com
Subject: TAKE - arch mods - AGFL
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing

 - arch convert AGFLs

Modid:  2.3.99pre2-xfs:slinx:58479a
Date:  Tue Apr 18 18:04:49 PDT 2000
Workarea:  snort:/build1/people/dxm/isms/slinx-xfs

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

cmd/xfs/mangle/agf.c - 1.4
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/cmd/xfs/mangle/agf.c.diff?r1=text&tr1=1.4&r2=text&tr2=1.3&f=h
cmd/xfs/mangle/xfs_mangle.c - 1.6
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/cmd/xfs/mangle/xfs_mangle.c.diff?r1=text&tr1=1.6&r2=text&tr2=1.5&f=h
cmd/xfs/mangle/xfs_mangle.h - 1.7
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/cmd/xfs/mangle/xfs_mangle.h.diff?r1=text&tr1=1.7&r2=text&tr2=1.6&f=h
linux/fs/xfs/xfs_alloc.c - 1.131
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/linux/fs/xfs/xfs_alloc.c.diff?r1=text&tr1=1.131&r2=text&tr2=1.130&f=h

From owner-linux-xfs@oss.sgi.com Tue Apr 18 21:55:44 2000
Received:  by oss.sgi.com id <S305179AbQDSEzf>;
	Tue, 18 Apr 2000 21:55:35 -0700
Received: from timbuk-fddi.cray.com ([128.162.8.102]:35720 "EHLO
        timbuk.cray.com") by oss.sgi.com with ESMTP id <S305184AbQDSEzN>;
	Tue, 18 Apr 2000 21:55:13 -0700
Received: from clink.americas.sgi.com (clink.cray.com [128.162.84.70]) by timbuk.cray.com (8.8.8/CRI-gate-news-1.3) with ESMTP id XAA21080 for <linux-xfs@oss.sgi.com>; Tue, 18 Apr 2000 23:55:10 -0500 (CDT)
Received: (from n8994@localhost) by clink.americas.sgi.com (980427.SGI.8.8.8/CRI-news-1.3) id XAA59613 for linux-xfs@oss.sgi.com; Tue, 18 Apr 2000 23:55:11 -0500 (CDT)
Date:   Tue, 18 Apr 2000 23:55:11 -0500 (CDT)
From:   Russell Cattelan <n8994@sgi.com>
Message-Id: <200004190455.XAA59613@clink.americas.sgi.com>
To:     linux-xfs@oss.sgi.com
Subject: TAKE - 
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing

Modid:  2.3.99pre2-xfs:slinx:58501a
Date:  Tue Apr 18 21:54:48 PDT 2000
Workarea:  clink.americas.sgi.com:/data/clink/io/cattelan/x2.3-99-xfs

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

linux/fs/xfs/linux/xfs_lrw.c - 1.35
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/linux/fs/xfs/linux/xfs_lrw.c.diff?r1=text&tr1=1.35&r2=text&tr2=1.34&f=h
	- new function xfs_is_read_only 

linux/fs/xfs/linux/xfs_lrw.h - 1.9
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/linux/fs/xfs/linux/xfs_lrw.h.diff?r1=text&tr1=1.9&r2=text&tr2=1.8&f=h
	- proto  xfs_is_read_only

linux/fs/xfs/xfs_log_recover.c - 1.173
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/linux/fs/xfs/xfs_log_recover.c.diff?r1=text&tr1=1.173&r2=text&tr2=1.172&f=h
	- moved linux specific is_read_only to border file -> xfs_lrw.c


From owner-linux-xfs@oss.sgi.com Tue Apr 18 22:34:24 2000
Received:  by oss.sgi.com id <S305182AbQDSFeO>;
	Tue, 18 Apr 2000 22:34:14 -0700
Received: from deliverator.sgi.com ([204.94.214.10]:42105 "EHLO
        deliverator.sgi.com") by oss.sgi.com with ESMTP id <S305179AbQDSFd5>;
	Tue, 18 Apr 2000 22:33:57 -0700
Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via SMTP id WAA13528
	for <linux-xfs@oss.sgi.com>; Tue, 18 Apr 2000 22:29:10 -0700 (PDT)
	mail_from (dxm@snort.melbourne.sgi.com)
Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.55.149]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id PAA04551 for <@larry.melbourne.sgi.com:linux-xfs@oss.sgi.com>; Wed, 19 Apr 2000 15:32:36 +1000
Received: (from dxm@localhost) by snort.melbourne.sgi.com (980427.SGI.8.8.8/980728.SGI.AUTOCF) id PAA88004 for linux-xfs@oss.sgi.com; Wed, 19 Apr 2000 15:32:36 +1000 (EST)
Date:   Wed, 19 Apr 2000 15:32:36 +1000 (EST)
From:   dxm@snort.melbourne.sgi.com (Daniel Moore)
Message-Id: <200004190532.PAA88004@snort.melbourne.sgi.com>
To:     linux-xfs@oss.sgi.com
Subject: TAKE - arch mods - finish inobt
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing

architecture convert the rest of the inobt.

that's three out of four btrees done... 
only the bmap btree to go.

Modid:  2.3.99pre2-xfs:slinx:58504a
Date:  Tue Apr 18 22:31:25 PDT 2000
Workarea:  snort:/build1/people/dxm/isms/slinx-xfs

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

linux/fs/xfs/xfs_arch.h - 1.21
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/linux/fs/xfs/xfs_arch.h.diff?r1=text&tr1=1.21&r2=text&tr2=1.20&f=h
linux/fs/xfs/xfs_btree.c - 1.82
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/linux/fs/xfs/xfs_btree.c.diff?r1=text&tr1=1.82&r2=text&tr2=1.81&f=h
linux/fs/xfs/xfs_ialloc.c - 1.132
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/linux/fs/xfs/xfs_ialloc.c.diff?r1=text&tr1=1.132&r2=text&tr2=1.131&f=h
linux/fs/xfs/xfs_ialloc_btree.c - 1.54
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/linux/fs/xfs/xfs_ialloc_btree.c.diff?r1=text&tr1=1.54&r2=text&tr2=1.53&f=h
linux/fs/xfs/xfs_ialloc_btree.h - 1.17
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/linux/fs/xfs/xfs_ialloc_btree.h.diff?r1=text&tr1=1.17&r2=text&tr2=1.16&f=h
linux/fs/xfs/xfs_itable.c - 1.83
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/linux/fs/xfs/xfs_itable.c.diff?r1=text&tr1=1.83&r2=text&tr2=1.82&f=h
linux/fs/xfs/xfs_macros.c - 1.35
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/linux/fs/xfs/xfs_macros.c.diff?r1=text&tr1=1.35&r2=text&tr2=1.34&f=h
linux/fs/xfs/xfsidbg.c - 1.135
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/linux/fs/xfs/xfsidbg.c.diff?r1=text&tr1=1.135&r2=text&tr2=1.134&f=h

From owner-linux-xfs@oss.sgi.com Wed Apr 19 05:08:01 2000
Received:  by oss.sgi.com id <S305167AbQDSMHv>;
	Wed, 19 Apr 2000 05:07:51 -0700
Received: from csmd2.CS.Uni-Magdeburg.De ([141.44.22.2]:722 "EHLO
        csmd2.cs.uni-magdeburg.de") by oss.sgi.com with ESMTP
	id <S305163AbQDSMHd>; Wed, 19 Apr 2000 05:07:33 -0700
Received: from knecht.cs.uni-magdeburg.de (markgraf@knecht [141.44.21.3])
	by csmd2.cs.uni-magdeburg.de (8.9.3/8.9.3) with ESMTP id OAA16973
	for <linux-xfs@oss.sgi.com>; Wed, 19 Apr 2000 14:07:29 +0200 (MET DST)
Received: from localhost (markgraf@localhost)
	by knecht.cs.uni-magdeburg.de (8.8.8+Sun/8.8.8) with SMTP id OAA07730
	for <linux-xfs@oss.sgi.com>; Wed, 19 Apr 2000 14:06:34 +0200 (MET DST)
X-Authentication-Warning: knecht.cs.uni-magdeburg.de: markgraf owned process doing -bs
Date:   Wed, 19 Apr 2000 14:06:34 +0200 (MET DST)
From:   Bernd Markgraf <markgraf@mail.CS.Uni-Magdeburg.De>
X-Sender: markgraf@knecht
To:     linux-xfs@oss.sgi.com
Subject: oops on xfs mount
Message-ID: <Pine.GSO.3.95.1000419134531.7417A-100000@knecht>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing

hi,

i just got a new toy - 400gb hardware raid. so for the fun of testing it i
made a partition of rougly 90gb and created an xfs on this partition which
work nicely and much faster than mke2fs ;-)
tho only problem is i cannot mount it. trying to do so just gives an ugly
oops:

Unable to handle kernel NULL pointer dereference at virtual address 00000000
*pde = 00000000
Oops: 0002
CPU: 0
EIP: 0010:[<c88d6442>]
EFLAGS: 00010246
eax: 00000000  ebx: 00035c00  ecx: 0000d700  edx: c024d05c
esi: 00000000  edi: 00000000  ebp: 00000001  esp: c2d75a84
ds: 0018  es: 0018  ss: 0018
Process mount (pid: 184, stackpage = c2d75000)
Stack: 000005eb c8779000 c9779344 c88af5d5 00035c00 00000000 000005eb c88e31ec
       c88bd340 c0799700 00000811 00000000 c612ee69 c0779000 00000001 00000000
       0000000a ffffffff 00000000 00000002 00001000 c889e2cc c028d4c0 c077917c
Call Trace: [<c88af5d5>] [<c88e31ec>] [<c88bd340>] [<c889e2cc>] [<c88de83e>]
     [<c88de83d>] [<c88bd893>] [<c88c5a24>] [<c88c5c59>] [<c88e9640>]
     [<c88e9640>] [<c88c5d37>] [<c88e9640>] [<c88c5d14>] [<c88d6897>]
     [<c88e9640>] [<c0135628>] [<c0206a47>] [<c0142a6e>] [<c0137564>]
     [<c88e3768>] [<c013aa48>] [<c0135628>] [<c0135c54>] [<c88e3768>]
     [<c88e3768>] [<c88e3768>] [<c0136145>] [<c88e23f0>] [<c01361e6>]
     [<c0109650>]
Code: f3 ab f6 c3 02 74 02 66 ab f6 c3 01 74 01 aa 89 f0 5b 5e 5f
Segmentation fault.

this happened using the latest sources from the cvs tree.

do we have a limit for the filesystem size?

bernd
--
Death is happy, death is cool       
Death can be a useful tool         
Use a gun or use a knife          
Death can really change your life    
_________________________________________________________________________
Bernd Markgraf		                  Otto-von-Guericke-Universitaet
markgraf@mail.cs.uni-magdeburg.de         Magdeburg
http://www.cs.uni-magdeburg.de/~markgraf  Germany


From owner-linux-xfs@oss.sgi.com Wed Apr 19 06:36:03 2000
Received:  by oss.sgi.com id <S305169AbQDSNfy>;
	Wed, 19 Apr 2000 06:35:54 -0700
Received: from pneumatic-tube.sgi.com ([204.94.214.22]:2860 "EHLO
        pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP
	id <S305163AbQDSNfd>; Wed, 19 Apr 2000 06:35:33 -0700
Received: from ledzep.cray.com (ledzep.cray.com [137.38.226.97]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id GAA08276
	for <linux-xfs@oss.sgi.com>; Wed, 19 Apr 2000 06:39:34 -0700 (PDT)
	mail_from (lord@sgi.com)
Received: from ironwood-e185.americas.sgi.com (ironwood.cray.com [128.162.185.212]) by ledzep.cray.com (SGI-SGI-8.9.3/craymail-smart-nospam1.0) with ESMTP id IAA35363; Wed, 19 Apr 2000 08:34:16 -0500 (CDT)
Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.184.86]) by ironwood-e185.americas.sgi.com (8.8.4/SGI-ironwood-e1.4) with ESMTP id IAA21656; Wed, 19 Apr 2000 08:34:08 -0500 (CDT)
Received: from jen.americas.sgi.com by jen.americas.sgi.com (8.9.3/SGI-client.1.6) via ESMTP id IAA08106; Wed, 19 Apr 2000 08:34:04 -0500
Message-Id: <200004191334.IAA08106@jen.americas.sgi.com>
X-Mailer: exmh version 2.1.1 10/15/1999
To:     Bernd Markgraf <markgraf@prinz-atm.CS.Uni-Magdeburg.De>
cc:     linux-xfs@oss.sgi.com
Subject: Re: oops on xfs mount 
In-Reply-To: Message from Bernd Markgraf <markgraf@prinz-atm.CS.Uni-Magdeburg.De> 
   of "Wed, 19 Apr 2000 14:06:34 +0200." <Pine.GSO.3.95.1000419134531.7417A-100000@knecht> 
Date:   Wed, 19 Apr 2000 08:34:03 -0500
From:   Steve Lord <lord@sgi.com>
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing

> hi,
> 
> i just got a new toy - 400gb hardware raid. so for the fun of testing it i
> made a partition of rougly 90gb and created an xfs on this partition which
> work nicely and much faster than mke2fs ;-)
> tho only problem is i cannot mount it. trying to do so just gives an ugly
> oops:
> 
> Unable to handle kernel NULL pointer dereference at virtual address 00000000
> *pde = 00000000
> Oops: 0002
> CPU: 0
> EIP: 0010:[<c88d6442>]
> EFLAGS: 00010246
> eax: 00000000  ebx: 00035c00  ecx: 0000d700  edx: c024d05c
> esi: 00000000  edi: 00000000  ebp: 00000001  esp: c2d75a84
> ds: 0018  es: 0018  ss: 0018
> Process mount (pid: 184, stackpage = c2d75000)
> Stack: 000005eb c8779000 c9779344 c88af5d5 00035c00 00000000 000005eb c88e31e
c
>        c88bd340 c0799700 00000811 00000000 c612ee69 c0779000 00000001 0000000
0
>        0000000a ffffffff 00000000 00000002 00001000 c889e2cc c028d4c0 c077917
c
> Call Trace: [<c88af5d5>] [<c88e31ec>] [<c88bd340>] [<c889e2cc>] [<c88de83e>]
>      [<c88de83d>] [<c88bd893>] [<c88c5a24>] [<c88c5c59>] [<c88e9640>]
>      [<c88e9640>] [<c88c5d37>] [<c88e9640>] [<c88c5d14>] [<c88d6897>]
>      [<c88e9640>] [<c0135628>] [<c0206a47>] [<c0142a6e>] [<c0137564>]
>      [<c88e3768>] [<c013aa48>] [<c0135628>] [<c0135c54>] [<c88e3768>]
>      [<c88e3768>] [<c88e3768>] [<c0136145>] [<c88e23f0>] [<c01361e6>]
>      [<c0109650>]
> Code: f3 ab f6 c3 02 74 02 66 ab f6 c3 01 74 01 aa 89 f0 5b 5e 5f
> Segmentation fault.
> 
> this happened using the latest sources from the cvs tree.
> 
> do we have a limit for the filesystem size?
> 
> bernd
> --
> Death is happy, death is cool       
> Death can be a useful tool         
> Use a gun or use a knife          
> Death can really change your life    
> _________________________________________________________________________
> Bernd Markgraf		                  Otto-von-Guericke-Universitae
t
> markgraf@mail.cs.uni-magdeburg.de         Magdeburg
> http://www.cs.uni-magdeburg.de/~markgraf  Germany


Hmm, any chance of at least a ksymoops conversion of that stack, or
can you build kdb into the kernel and get a real stack back trace out of
it?

There should not be a limitation in size - at least not that 400 Gbytes
is capable of hitting. We will trip up at 2 Tbytes on linux due to
inode numbers getting bigger than 32 bit.

Thanks

   Steve




From owner-linux-xfs@oss.sgi.com Wed Apr 19 10:19:12 2000
Received:  by oss.sgi.com id <S305170AbQDSRTD>;
	Wed, 19 Apr 2000 10:19:03 -0700
Received: from pneumatic-tube.sgi.com ([204.94.214.22]:5704 "EHLO
        pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP
	id <S305163AbQDSRSr>; Wed, 19 Apr 2000 10:18:47 -0700
Received: from ledzep.cray.com (ledzep.cray.com [137.38.226.97]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id KAA02976
	for <linux-xfs@oss.sgi.com>; Wed, 19 Apr 2000 10:22:48 -0700 (PDT)
	mail_from (n8994@sgi.com)
Received: from ironwood-e185.americas.sgi.com (ironwood.cray.com [128.162.185.212]) by ledzep.cray.com (SGI-SGI-8.9.3/craymail-smart-nospam1.0) with ESMTP id MAA76969 for <linux-xfs@oss.sgi.com>; Wed, 19 Apr 2000 12:17:31 -0500 (CDT)
Received: from nt8.americas.sgi.com (nt8.americas.sgi.com [128.162.195.8]) by ironwood-e185.americas.sgi.com (8.8.4/SGI-ironwood-e1.4) with ESMTP id MAA04024 for <linux-xfs@oss.sgi.com>; Wed, 19 Apr 2000 12:17:23 -0500 (CDT)
From:   Russell Cattelan <n8994@sgi.com>
Received: by nt8.americas.sgi.com (980427.SGI.8.8.8/SGI-client.1.6) id MAA33152; Wed, 19 Apr 2000 12:17:29 -0500 (CDT)
Message-Id: <200004191717.MAA33152@nt8.americas.sgi.com>
Date:   Wed, 19 Apr 2000 12:17:29 -0500 (CDT)
To:     linux-xfs@oss.sgi.com
Subject: TAKE - Added prototype
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing

Modid:  2.3.99pre2-xfs:slinx:58519a
Date:  Wed Apr 19 10:17:09 PDT 2000
Workarea:  nt8.americas.sgi.com:/data/clink/io/cattelan/x2.3-99-xfs

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

linux/fs/xfs/xfs_log_recover.c - 1.174
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/linux/fs/xfs/xfs_log_recover.c.diff?r1=text&tr1=1.174&r2=text&tr2=1.173&f=h
	- Added prototype for xfs_is_read_only.. ya it's a hack but...


From owner-linux-xfs@oss.sgi.com Wed Apr 19 16:27:25 2000
Received:  by oss.sgi.com id <S305172AbQDSX1Q>;
	Wed, 19 Apr 2000 16:27:16 -0700
Received: from deliverator.sgi.com ([204.94.214.10]:873 "EHLO
        deliverator.sgi.com") by oss.sgi.com with ESMTP id <S305163AbQDSX1A>;
	Wed, 19 Apr 2000 16:27:00 -0700
Received: from ledzep.cray.com (ledzep.cray.com [137.38.226.97]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id QAA25990
	for <linux-xfs@oss.sgi.com>; Wed, 19 Apr 2000 16:22:15 -0700 (PDT)
	mail_from (n8994@sgi.com)
Received: from ironwood-e185.americas.sgi.com (ironwood.cray.com [128.162.185.212]) by ledzep.cray.com (SGI-SGI-8.9.3/craymail-smart-nospam1.0) with ESMTP id SAA80942 for <linux-xfs@oss.sgi.com>; Wed, 19 Apr 2000 18:24:28 -0500 (CDT)
Received: from nt8.americas.sgi.com (nt8.americas.sgi.com [128.162.195.8]) by ironwood-e185.americas.sgi.com (8.8.4/SGI-ironwood-e1.4) with ESMTP id SAA19801 for <linux-xfs@oss.sgi.com>; Wed, 19 Apr 2000 18:24:21 -0500 (CDT)
From:   Russell Cattelan <n8994@sgi.com>
Received: by nt8.americas.sgi.com (980427.SGI.8.8.8/SGI-client.1.6) id SAA34627; Wed, 19 Apr 2000 18:24:27 -0500 (CDT)
Message-Id: <200004192324.SAA34627@nt8.americas.sgi.com>
Date:   Wed, 19 Apr 2000 18:24:27 -0500 (CDT)
To:     linux-xfs@oss.sgi.com
Subject: TAKE - Compile fixes, memory allocation improvements.
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing

Modid:  2.3.99pre2-xfs:slinx:58584a
Date:  Wed Apr 19 16:23:45 PDT 2000
Workarea:  nt8.americas.sgi.com:/data/clink/io/cattelan/x2.3-99-xfs

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

cmd/xfs/db/check.c - 1.49
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/cmd/xfs/db/check.c.diff?r1=text&tr1=1.49&r2=text&tr2=1.48&f=h
cmd/xfs/db/frag.c - 1.13
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/cmd/xfs/db/frag.c.diff?r1=text&tr1=1.13&r2=text&tr2=1.12&f=h
cmd/xfs/repair/incore.h - 1.31
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/cmd/xfs/repair/incore.h.diff?r1=text&tr1=1.31&r2=text&tr2=1.30&f=h
	- Added missing flag_arch to appropiate macros.

linux/fs/xfs/linux/xfs_random.c - 1.31
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/linux/fs/xfs/linux/xfs_random.c.diff?r1=text&tr1=1.31&r2=text&tr2=1.30&f=h
	- kmem_alloc now call vmalloc for sizes over 128k 
	  This doesn't solve all the large memory cases but 
	  it is a start.
	  note: kmem_realloc could be rewritten to be more efficient.

linux/fs/xfs/pseudo-inc/sys/kmem.h - 1.6
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/linux/fs/xfs/pseudo-inc/sys/kmem.h.diff?r1=text&tr1=1.6&r2=text&tr2=1.5&f=h
	- changed prototype for kmem_alloc... add oldsize.

linux/fs/xfs/pseudo-inc/sys/types.h - 1.15
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/linux/fs/xfs/pseudo-inc/sys/types.h.diff?r1=text&tr1=1.15&r2=text&tr2=1.14&f=h
	- removed typdefs of linux_caddr_t linux_daddr_t and linux_inod_t 

linux/fs/xfs/xfs_buf.h - 1.48
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/linux/fs/xfs/xfs_buf.h.diff?r1=text&tr1=1.48&r2=text&tr2=1.47&f=h
	- removed incorrect call to pagebuf_relse in xfs_buf_undelay.

linux/fs/xfs/xfs_fsops.c - 1.51
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/linux/fs/xfs/xfs_fsops.c.diff?r1=text&tr1=1.51&r2=text&tr2=1.50&f=h
linux/fs/xfs/xfs_inode.c - 1.280
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/linux/fs/xfs/xfs_inode.c.diff?r1=text&tr1=1.280&r2=text&tr2=1.279&f=h
linux/fs/xfs/xfs_log_recover.c - 1.175
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/linux/fs/xfs/xfs_log_recover.c.diff?r1=text&tr1=1.175&r2=text&tr2=1.174&f=h
linux/fs/xfs/xfs_mount.c - 1.217
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/linux/fs/xfs/xfs_mount.c.diff?r1=text&tr1=1.217&r2=text&tr2=1.216&f=h
linux/fs/xfs/xfs_os_defs.h - 1.5
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/linux/fs/xfs/xfs_os_defs.h.diff?r1=text&tr1=1.5&r2=text&tr2=1.4&f=h
	- Changed kmem_realloc to include oldsize.


From owner-linux-xfs@oss.sgi.com Wed Apr 19 16:49:45 2000
Received:  by oss.sgi.com id <S305174AbQDSXt0>;
	Wed, 19 Apr 2000 16:49:26 -0700
Received: from deliverator.sgi.com ([204.94.214.10]:30575 "EHLO
        deliverator.sgi.com") by oss.sgi.com with ESMTP id <S305163AbQDSXtQ>;
	Wed, 19 Apr 2000 16:49:16 -0700
Received: from ledzep.cray.com (ledzep.cray.com [137.38.226.97]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id QAA28127
	for <linux-xfs@oss.sgi.com>; Wed, 19 Apr 2000 16:44:30 -0700 (PDT)
	mail_from (cattelan@thebarn.com)
From:   cattelan@thebarn.com
Received: from ironwood-e185.americas.sgi.com (ironwood.cray.com [128.162.185.212]) by ledzep.cray.com (SGI-SGI-8.9.3/craymail-smart-nospam1.0) with ESMTP id SAA89980 for <linux-xfs@oss.sgi.com>; Wed, 19 Apr 2000 18:46:44 -0500 (CDT)
Received: from gibble.americas.sgi.com (root@gibble.americas.sgi.com [128.162.195.80]) by ironwood-e185.americas.sgi.com (8.8.4/SGI-ironwood-e1.4) with ESMTP id SAA20286; Wed, 19 Apr 2000 18:46:34 -0500 (CDT)
Received: from gibble.americas.sgi.com by gibble.americas.sgi.com (8.9.3/SGI-client.1.6) via ESMTP id SAA30673; Wed, 19 Apr 2000 18:46:41 -0500
Date:   Wed, 19 Apr 2000 18:46:39 -0500
Message-ID: <14590.17759.41450.64144V@gibble.americas.sgi.com>
To:     lord@sgi.com
cc:     linux-xfs@oss.sgi.com
Subject: Hmmm out of memory error	
User-Agent: Wanderlust/1.0.3 (Notorious) tm/7.108 XEmacs/21.1 (Bryce Canyon)
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing

FYI


cmn_err level 1 Filesystem "ide0(3,1)": xfs_log_write: reservation ran out. Need to up reservation
Corruption of in-memory data detected.  Shutting down filesystem: ide0(3,1)
Please umount the filesystem, and rectify the problem(s)

Haven't looked into it yet.
Will tomorrow...

From owner-linux-xfs@oss.sgi.com Thu Apr 20 14:27:50 2000
Received:  by oss.sgi.com id <S305182AbQDSXuQ>;
	Wed, 19 Apr 2000 16:50:16 -0700
Received: (from localhost user: 'cattelan', uid#10098) by oss.sgi.com
	id <S305178AbQDSXtx>; Wed, 19 Apr 2000 16:49:53 -0700
From:   Russell Cattelan <cattelan@oss.sgi.com>
To:     linux-xfs@oss.sgi.com
Message-Id: <20000419234954Z305178-392+193@oss.sgi.com>
Date:   Wed, 19 Apr 2000 16:49:53 -0700
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing

bulk_mailer test

From owner-linux-xfs@oss.sgi.com Thu Apr 20 14:43:22 2000
Received:  by oss.sgi.com id <S305176AbQDTB16>;
	Wed, 19 Apr 2000 18:27:58 -0700
Received: from deliverator.sgi.com ([204.94.214.10]:24073 "EHLO
        deliverator.sgi.com") by oss.sgi.com with ESMTP id <S305175AbQDTB1v>;
	Wed, 19 Apr 2000 18:27:51 -0700
Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via SMTP id SAA06118
	for <linux-xfs@oss.sgi.com>; Wed, 19 Apr 2000 18:23:03 -0700 (PDT)
	mail_from (dxm@snort.melbourne.sgi.com)
Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.55.149]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id LAA11103 for <@larry.melbourne.sgi.com:linux-xfs@oss.sgi.com>; Thu, 20 Apr 2000 11:25:15 +1000
Received: (from dxm@localhost) by snort.melbourne.sgi.com (980427.SGI.8.8.8/980728.SGI.AUTOCF) id LAA93143 for linux-xfs@oss.sgi.com; Thu, 20 Apr 2000 11:25:14 +1000 (EST)
Date:   Thu, 20 Apr 2000 11:25:14 +1000 (EST)
From:   dxm@snort.melbourne.sgi.com (Daniel Moore)
Message-Id: <200004200125.LAA93143@snort.melbourne.sgi.com>
To:     linux-xfs@oss.sgi.com
Subject: TAKE - minor arch changes
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing

Use arch varaible where it's defined instead of ARCH_UNKNOWN.
Should be zero effect, but it looked messy.

Modid:  2.3.99pre2-xfs:slinx:58601a
Date:  Wed Apr 19 18:23:39 PDT 2000
Workarea:  snort:/build1/people/dxm/isms/slinx-xfs

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

linux/fs/xfs/xfs_ialloc.c - 1.133
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/linux/fs/xfs/xfs_ialloc.c.diff?r1=text&tr1=1.133&r2=text&tr2=1.132&f=h
linux/fs/xfs/xfs_ialloc_btree.c - 1.55
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/linux/fs/xfs/xfs_ialloc_btree.c.diff?r1=text&tr1=1.55&r2=text&tr2=1.54&f=h

From owner-linux-xfs@oss.sgi.com Thu Apr 20 14:43:22 2000
Received:  by oss.sgi.com id <S305175AbQDTBxT>;
	Wed, 19 Apr 2000 18:53:19 -0700
Received: from deliverator.sgi.com ([204.94.214.10]:47116 "EHLO
        deliverator.sgi.com") by oss.sgi.com with ESMTP id <S305163AbQDTBwy>;
	Wed, 19 Apr 2000 18:52:54 -0700
Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via SMTP id SAA07858
	for <linux-xfs@oss.sgi.com>; Wed, 19 Apr 2000 18:48:08 -0700 (PDT)
	mail_from (dxm@clouds.melbourne.sgi.com)
Received: from clouds.melbourne.sgi.com (clouds.melbourne.sgi.com [134.14.55.166]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id LAA11271; Thu, 20 Apr 2000 11:51:36 +1000
Received: from localhost (dxm@localhost) by clouds.melbourne.sgi.com (980427.SGI.8.8.8/980728.SGI.AUTOCF) via SMTP id LAA98428; Thu, 20 Apr 2000 11:51:35 +1000 (EST)
Message-Id: <200004200151.LAA98428@clouds.melbourne.sgi.com>
X-Mailer: exmh version 2.0.2 2/24/98
To:     Russell Cattelan <n8994@sgi.com>
cc:     linux-xfs@oss.sgi.com
Subject: Re: TAKE - Compile fixes, memory allocation improvements. 
In-reply-to: Your message of "Wed, 19 Apr 2000 18:24:27 EST."
             <200004192324.SAA34627@nt8.americas.sgi.com> 
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date:   Thu, 20 Apr 2000 11:51:35 +1000
From:   Daniel Moore <dxm@clouds.melbourne.sgi.com>
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing


Russell Cattelan writes:

 => linux/fs/xfs/xfs_fsops.c - 1.51
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/ => linux/fs/xfs/xfs_fsops.c.diff?r1=text&tr1=1.51&r2=text&tr2=1.50&f=h
 => linux/fs/xfs/xfs_inode.c - 1.280
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/ => linux/fs/xfs/xfs_inode.c.diff?r1=text&tr1=1.280&r2=text&tr2=1.279&f=h
 => linux/fs/xfs/xfs_log_recover.c - 1.175
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/ => linux/fs/xfs/xfs_log_recover.c.diff?r1=text&tr1=1.175&r2=text&tr2=1.174&f=h
 => linux/fs/xfs/xfs_mount.c - 1.217
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/ => linux/fs/xfs/xfs_mount.c.diff?r1=text&tr1=1.217&r2=text&tr2=1.216&f=h
 => linux/fs/xfs/xfs_os_defs.h - 1.5
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/ => linux/fs/xfs/xfs_os_defs.h.diff?r1=text&tr1=1.5&r2=text&tr2=1.4&f=h
 => 	- Changed kmem_realloc to include oldsize.

This change breaks sim. 

Adding the extra parameter to the definition in sim.random.c
and removing the SIM conditional define from xfs_os_defs.h fixes
the problem.

I haven't made the change because I'm not sure that's what you
want to do.

-----------------------------------------------------
 Daniel Moore                  dxm@sgi.com
 R&D Software Engineer         Phone: +61-3-98348209
 SGI Performance Tools Group   Fax:   +61-3-98132378
-----------------------------------------------------


From owner-linux-xfs@oss.sgi.com Thu Apr 20 14:43:22 2000
Received:  by oss.sgi.com id <S305178AbQDTCxU>;
	Wed, 19 Apr 2000 19:53:20 -0700
Received: from deliverator.sgi.com ([204.94.214.10]:57878 "EHLO
        deliverator.sgi.com") by oss.sgi.com with ESMTP id <S305163AbQDTCwz>;
	Wed, 19 Apr 2000 19:52:55 -0700
Received: from ledzep.cray.com (ledzep.cray.com [137.38.226.97]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id TAA11709
	for <linux-xfs@oss.sgi.com>; Wed, 19 Apr 2000 19:48:10 -0700 (PDT)
	mail_from (lord@sgi.com)
Received: from ironwood-e185.americas.sgi.com (ironwood.cray.com [128.162.185.212]) by ledzep.cray.com (SGI-SGI-8.9.3/craymail-smart-nospam1.0) with ESMTP id VAA30740; Wed, 19 Apr 2000 21:51:34 -0500 (CDT)
Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.184.86]) by ironwood-e185.americas.sgi.com (8.8.4/SGI-ironwood-e1.4) with ESMTP id VAA23935; Wed, 19 Apr 2000 21:51:26 -0500 (CDT)
From:   Steve Lord <lord@sgi.com>
Received: from jen.americas.sgi.com by jen.americas.sgi.com (8.9.3/SGI-client.1.6) via ESMTP id VAA03629; Wed, 19 Apr 2000 21:51:17 -0500
Message-Id: <200004200251.VAA03629@jen.americas.sgi.com>
To:     Daniel Moore <dxm@clouds.melbourne.sgi.com>
cc:     Russell Cattelan <n8994@sgi.com>, linux-xfs@oss.sgi.com
Subject: Re: TAKE - Compile fixes, memory allocation improvements. 
In-reply-to: Your message of "Thu, 20 Apr 2000 11:51:35 +1000
Date:   Wed, 19 Apr 2000 21:51:17 -0500
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing

> 
> Russell Cattelan writes:
> 
>  => linux/fs/xfs/xfs_fsops.c - 1.51
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/>  => linux/fs/xfs/xfs_fsops.c.diff?r1=text&tr1=1.51&r2=text&tr2=1.50&f=h
>  => linux/fs/xfs/xfs_inode.c - 1.280
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/>  => linux/fs/xfs/xfs_inode.c.diff?r1=text&tr1=1.280&r2=text&tr2=1.279&f=h
>  => linux/fs/xfs/xfs_log_recover.c - 1.175
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/>  => linux/fs/xfs/xfs_log_recover.c.diff?r1=text&tr1=1.175&r2=text&tr2=1.174&f=h
>  => linux/fs/xfs/xfs_mount.c - 1.217
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/>  => linux/fs/xfs/xfs_mount.c.diff?r1=text&tr1=1.217&r2=text&tr2=1.216&f=h
>  => linux/fs/xfs/xfs_os_defs.h - 1.5
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/>  => linux/fs/xfs/xfs_os_defs.h.diff?r1=text&tr1=1.5&r2=text&tr2=1.4&f=h
>  => 	- Changed kmem_realloc to include oldsize.
> 
> This change breaks sim. 
> 
> Adding the extra parameter to the definition in sim.random.c
> and removing the SIM conditional define from xfs_os_defs.h fixes
> the problem.
> 
> I haven't made the change because I'm not sure that's what you
> want to do.
> 
> -----------------------------------------------------
>  Daniel Moore                  dxm@sgi.com
>  R&D Software Engineer         Phone: +61-3-98348209
>  SGI Performance Tools Group   Fax:   +61-3-98132378
> -----------------------------------------------------


If there are no other calls in user space which do not get confused by this
then go ahead and check in what you described. The kernel needs the extra
parameter to make some realloc cases work. Seems better to keep the same
api in both places than to ifdef header files.

Lets keep broken tree time to a minimum.

Steve


From owner-linux-xfs@oss.sgi.com Thu Apr 20 14:43:22 2000
Received:  by oss.sgi.com id <S305179AbQDTDAa>;
	Wed, 19 Apr 2000 20:00:30 -0700
Received: from pneumatic-tube.sgi.com ([204.94.214.22]:8454 "EHLO
        pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP
	id <S305163AbQDTDAV>; Wed, 19 Apr 2000 20:00:21 -0700
Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via SMTP id UAA03375
	for <linux-xfs@oss.sgi.com>; Wed, 19 Apr 2000 20:04:21 -0700 (PDT)
	mail_from (dxm@snort.melbourne.sgi.com)
Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.55.149]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id MAA11804 for <@larry.melbourne.sgi.com:linux-xfs@oss.sgi.com>; Thu, 20 Apr 2000 12:59:02 +1000
Received: (from dxm@localhost) by snort.melbourne.sgi.com (980427.SGI.8.8.8/980728.SGI.AUTOCF) id MAA41070 for linux-xfs@oss.sgi.com; Thu, 20 Apr 2000 12:59:01 +1000 (EST)
Date:   Thu, 20 Apr 2000 12:59:01 +1000 (EST)
From:   dxm@snort.melbourne.sgi.com (Daniel Moore)
Message-Id: <200004200259.MAA41070@snort.melbourne.sgi.com>
To:     linux-xfs@oss.sgi.com
Subject: TAKE - fix sim breakage
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing

Add extra parameter to realloc in sim.

XFS_kmem_realloc seems pretty redundant now.

Modid:  2.3.99pre2-xfs:slinx:58606a
Date:  Wed Apr 19 19:58:09 PDT 2000
Workarea:  snort:/build1/people/dxm/isms/slinx-xfs-tot

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

cmd/xfs/sim/src/sim.random.c - 1.104
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/cmd/xfs/sim/src/sim.random.c.diff?r1=text&tr1=1.104&r2=text&tr2=1.103&f=h
linux/fs/xfs/xfs_os_defs.h - 1.6
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/linux/fs/xfs/xfs_os_defs.h.diff?r1=text&tr1=1.6&r2=text&tr2=1.5&f=h

From owner-linux-xfs@oss.sgi.com Thu Apr 20 14:43:23 2000
Received:  by oss.sgi.com id <S305183AbQDTDsL>;
	Wed, 19 Apr 2000 20:48:11 -0700
Received: from deliverator.sgi.com ([204.94.214.10]:17949 "EHLO
        deliverator.sgi.com") by oss.sgi.com with ESMTP id <S305163AbQDTDrx>;
	Wed, 19 Apr 2000 20:47:53 -0700
Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via SMTP id UAA15057
	for <linux-xfs@oss.sgi.com>; Wed, 19 Apr 2000 20:43:06 -0700 (PDT)
	mail_from (dxm@snort.melbourne.sgi.com)
Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.55.149]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id NAA12083 for <@larry.melbourne.sgi.com:linux-xfs@oss.sgi.com>; Thu, 20 Apr 2000 13:45:18 +1000
Received: (from dxm@localhost) by snort.melbourne.sgi.com (980427.SGI.8.8.8/980728.SGI.AUTOCF) id NAA18857 for linux-xfs@oss.sgi.com; Thu, 20 Apr 2000 13:45:18 +1000 (EST)
Date:   Thu, 20 Apr 2000 13:45:18 +1000 (EST)
From:   dxm@snort.melbourne.sgi.com (Daniel Moore)
Message-Id: <200004200345.NAA18857@snort.melbourne.sgi.com>
To:     linux-xfs@oss.sgi.com
Subject: TAKE - finish mkfs endian conversion
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing

- mkfs can now make a complete, mountable MIPS fs
  (ymmv with proto files though)

- INT_SET wasn't returning new value if used in-place
  this caused INT_MOD to return incorrect values

fix was to make INT_SET use INT_GET to fetch the new 
value. This is not ideal, but will hopefully get optomized
out most of the time - more investigation needed.

Modid:  2.3.99pre2-xfs:slinx:58607a
Date:  Wed Apr 19 20:42:13 PDT 2000
Workarea:  snort:/build1/people/dxm/isms/slinx-xfs

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

cmd/xfs/mkfs/xfs_mkfs.c - 1.159
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/cmd/xfs/mkfs/xfs_mkfs.c.diff?r1=text&tr1=1.159&r2=text&tr2=1.158&f=h
	- finish (?) endian conversion

linux/fs/xfs/xfs_arch.h - 1.22
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/linux/fs/xfs/xfs_arch.h.diff?r1=text&tr1=1.22&r2=text&tr2=1.21&f=h
	- fix INT_SET to return new value - needed for INT_MOD


From owner-linux-xfs@oss.sgi.com Thu Apr 20 14:43:23 2000
Received:  by oss.sgi.com id <S305163AbQDTEEl>;
	Wed, 19 Apr 2000 21:04:41 -0700
Received: from deliverator.sgi.com ([204.94.214.10]:18719 "EHLO
        deliverator.sgi.com") by oss.sgi.com with ESMTP id <S305184AbQDTEE3>;
	Wed, 19 Apr 2000 21:04:29 -0700
Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via SMTP id UAA16098
	for <linux-xfs@oss.sgi.com>; Wed, 19 Apr 2000 20:59:42 -0700 (PDT)
	mail_from (dxm@snort.melbourne.sgi.com)
Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.55.149]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id OAA12184 for <@larry.melbourne.sgi.com:linux-xfs@oss.sgi.com>; Thu, 20 Apr 2000 14:03:09 +1000
Received: (from dxm@localhost) by snort.melbourne.sgi.com (980427.SGI.8.8.8/980728.SGI.AUTOCF) id OAA17558 for linux-xfs@oss.sgi.com; Thu, 20 Apr 2000 14:03:08 +1000 (EST)
Date:   Thu, 20 Apr 2000 14:03:08 +1000 (EST)
From:   dxm@snort.melbourne.sgi.com (Daniel Moore)
Message-Id: <200004200403.OAA17558@snort.melbourne.sgi.com>
To:     linux-xfs@oss.sgi.com
Subject: TAKE - forgotten arch tidy
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing

Modid:  2.3.99pre2-xfs:slinx:58612a
Date:  Wed Apr 19 21:02:52 PDT 2000
Workarea:  snort:/build1/people/dxm/isms/slinx-xfs

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

linux/fs/xfs/xfs_ialloc_btree.c - 1.56
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/linux/fs/xfs/xfs_ialloc_btree.c.diff?r1=text&tr1=1.56&r2=text&tr2=1.55&f=h
	- forgotten arch tidy


From owner-linux-xfs@oss.sgi.com Thu Apr 20 14:43:23 2000
Received:  by oss.sgi.com id <S305185AbQDTFVV>;
	Wed, 19 Apr 2000 22:21:21 -0700
Received: from pneumatic-tube.sgi.com ([204.94.214.22]:7178 "EHLO
        pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP
	id <S305184AbQDTFVM>; Wed, 19 Apr 2000 22:21:12 -0700
Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via SMTP id WAA01183
	for <linux-xfs@oss.sgi.com>; Wed, 19 Apr 2000 22:25:12 -0700 (PDT)
	mail_from (dxm@clouds.melbourne.sgi.com)
Received: from clouds.melbourne.sgi.com (clouds.melbourne.sgi.com [134.14.55.166]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id PAA12563 for <@larry.melbourne.sgi.com:linux-xfs@oss.sgi.com>; Thu, 20 Apr 2000 15:19:53 +1000
Received: from localhost (dxm@localhost) by clouds.melbourne.sgi.com (980427.SGI.8.8.8/980728.SGI.AUTOCF) via SMTP id PAA99061 for <linux-xfs@oss.sgi.com>; Thu, 20 Apr 2000 15:19:52 +1000 (EST)
Message-Id: <200004200519.PAA99061@clouds.melbourne.sgi.com>
X-Mailer: exmh version 2.0.2 2/24/98
To:     linux-xfs@oss.sgi.com
Subject: NULL dereference on mount
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date:   Thu, 20 Apr 2000 15:19:52 +1000
From:   Daniel Moore <dxm@clouds.melbourne.sgi.com>
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing


I've just been trying to track down a problem I've started
experiencing recently. I've finally worked out whats going on,
and I think it's a known problem, but here's the symptoms just 
in-case anyone gets tripped up by it.

I should say that I've turned off my swap space because I needed
the partition so I could make a bigger xfs partition. That's probably
part of the problem.

On remounting (a clean) FS, system panics thru NULL pointer dereference
in xlog_bread or occasionally other places in xfs_log_recover.c

To cut a long story short, kmalloc fails a large allocation in
pagebuf (pagebuf_get_no_daddr and maybe others) and returns NULL.
xlog_get_bp returns NULL. xfs_bread coughs up a lung.

I think the reason I'm tripping it is because I'm getting large
meta data writes in the log (130k) and the whole block is being
allocated during the search for the ends of the log.

Anyway, there it is. Anyone have any thoughts?

-----------------------------------------------------
 Daniel Moore                  dxm@sgi.com
 R&D Software Engineer         Phone: +61-3-98348209
 SGI Performance Tools Group   Fax:   +61-3-98132378
-----------------------------------------------------


From owner-linux-xfs@oss.sgi.com Thu Apr 20 14:43:23 2000
Received:  by oss.sgi.com id <S305155AbQDTHOm>;
	Thu, 20 Apr 2000 00:14:42 -0700
Received: from lips.borg.umn.edu ([160.94.232.50]:30734 "EHLO
        lips.borg.umn.edu") by oss.sgi.com with ESMTP id <S305154AbQDTHOT>;
	Thu, 20 Apr 2000 00:14:19 -0700
Received: from thebarn.com (nic-31-c26-223.mn.mediaone.net [24.31.26.223])
	by lips.borg.umn.edu (8.10.0/8.10.0) with ESMTP id e3K7EGD24193;
	Thu, 20 Apr 2000 02:14:16 -0500 (CDT)
Message-ID: <38FEAE45.F6D83F4A@thebarn.com>
Date:   Thu, 20 Apr 2000 02:14:14 -0500
From:   Russell Cattelan <cattelan@thebarn.com>
Organization: Moo Solutions
X-Mailer: Mozilla 4.72 [en] (X11; U; FreeBSD 5.0-CURRENT i386)
X-Accept-Language: en
MIME-Version: 1.0
To:     Daniel Moore <dxm@clouds.melbourne.sgi.com>
CC:     linux-xfs@oss.sgi.com
Subject: Re: NULL dereference on mount
References: <200004200519.PAA99061@clouds.melbourne.sgi.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing

Daniel Moore wrote:

> I've just been trying to track down a problem I've started
> experiencing recently. I've finally worked out whats going on,
> and I think it's a known problem, but here's the symptoms just
> in-case anyone gets tripped up by it.
>
> I should say that I've turned off my swap space because I needed
> the partition so I could make a bigger xfs partition. That's probably
> part of the problem.
>
> On remounting (a clean) FS, system panics thru NULL pointer dereference
> in xlog_bread or occasionally other places in xfs_log_recover.c
>
> To cut a long story short, kmalloc fails a large allocation in
> pagebuf (pagebuf_get_no_daddr and maybe others) and returns NULL.
> xlog_get_bp returns NULL. xfs_bread coughs up a lung.
>
> I think the reason I'm tripping it is because I'm getting large
> meta data writes in the log (130k) and the whole block is being
> allocated during the search for the ends of the log.
>
> Anyway, there it is. Anyone have any thoughts?

Yup, I've been looking into this.
What are you doing to blow the 128k  cache?

A "clean" file-system shouldn't be in reovery code, you must
have crashed the system at some point.

kmalloc failures are a know problem...

>
>
> -----------------------------------------------------
>  Daniel Moore                  dxm@sgi.com
>  R&D Software Engineer         Phone: +61-3-98348209
>  SGI Performance Tools Group   Fax:   +61-3-98132378
> -----------------------------------------------------


From owner-linux-xfs@oss.sgi.com Thu Apr 20 14:43:23 2000
Received:  by oss.sgi.com id <S305156AbQDTIYn>;
	Thu, 20 Apr 2000 01:24:43 -0700
Received: from csmd2.CS.Uni-Magdeburg.De ([141.44.22.2]:31417 "EHLO
        csmd2.cs.uni-magdeburg.de") by oss.sgi.com with ESMTP
	id <S305154AbQDTIYZ>; Thu, 20 Apr 2000 01:24:25 -0700
Received: from knecht.cs.uni-magdeburg.de (markgraf@knecht [141.44.21.3])
	by csmd2.cs.uni-magdeburg.de (8.9.3/8.9.3) with ESMTP id KAA03229;
	Thu, 20 Apr 2000 10:24:22 +0200 (MET DST)
Received: from localhost (markgraf@localhost)
	by knecht.cs.uni-magdeburg.de (8.8.8+Sun/8.8.8) with SMTP id KAA19522;
	Thu, 20 Apr 2000 10:23:27 +0200 (MET DST)
X-Authentication-Warning: knecht.cs.uni-magdeburg.de: markgraf owned process doing -bs
Date:   Thu, 20 Apr 2000 10:23:27 +0200 (MET DST)
From:   Bernd Markgraf <markgraf@mail.CS.Uni-Magdeburg.De>
X-Sender: markgraf@knecht
To:     Russell Cattelan <cattelan@thebarn.com>
cc:     linux-xfs@oss.sgi.com
Subject: Re: NULL dereference on mount
In-Reply-To: <38FEAE45.F6D83F4A@thebarn.com>
Message-ID: <Pine.GSO.3.95.1000420102122.19517A-100000@knecht>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing

hi,

as i wrote before i also experienced this problem.

> Yup, I've been looking into this.
> What are you doing to blow the 128k  cache?
i just tried a ~90gb large xfs ;-) (my box has 128mb ram and 512mb swap -
this should be plenty...) 
 
> A "clean" file-system shouldn't be in reovery code, you must
> have crashed the system at some point.
i already sent a oops trace i got trying to mount the fresh 90gb
xfs-partition.
 
  bernd
--
Death is happy, death is cool       
Death can be a useful tool         
Use a gun or use a knife          
Death can really change your life    
_________________________________________________________________________
Bernd Markgraf		                  Otto-von-Guericke-Universitaet
markgraf@mail.cs.uni-magdeburg.de         Magdeburg
http://www.cs.uni-magdeburg.de/~markgraf  Germany


From owner-linux-xfs@oss.sgi.com Thu Apr 20 14:43:23 2000
Received:  by oss.sgi.com id <S305159AbQDTNqi>;
	Thu, 20 Apr 2000 06:46:38 -0700
Received: from pneumatic-tube.sgi.com ([204.94.214.22]:38938 "EHLO
        pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP
	id <S305157AbQDTNqS>; Thu, 20 Apr 2000 06:46:18 -0700
Received: from ledzep.cray.com (ledzep.cray.com [137.38.226.97]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id GAA04496
	for <linux-xfs@oss.sgi.com>; Thu, 20 Apr 2000 06:50:20 -0700 (PDT)
	mail_from (lord@sgi.com)
Received: from ironwood-e185.americas.sgi.com (ironwood.cray.com [128.162.185.212]) by ledzep.cray.com (SGI-SGI-8.9.3/craymail-smart-nospam1.0) with ESMTP id IAA86190; Thu, 20 Apr 2000 08:45:00 -0500 (CDT)
Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.184.86]) by ironwood-e185.americas.sgi.com (8.8.4/SGI-ironwood-e1.4) with ESMTP id IAA09544; Thu, 20 Apr 2000 08:44:53 -0500 (CDT)
Received: from jen.americas.sgi.com by jen.americas.sgi.com (8.9.3/SGI-client.1.6) via ESMTP id IAA06134; Thu, 20 Apr 2000 08:44:39 -0500
Message-Id: <200004201344.IAA06134@jen.americas.sgi.com>
X-Mailer: exmh version 2.1.1 10/15/1999
To:     Bernd Markgraf <markgraf@prinz-atm.CS.Uni-Magdeburg.De>
cc:     Russell Cattelan <cattelan@thebarn.com>, linux-xfs@oss.sgi.com
Subject: Re: NULL dereference on mount 
In-Reply-To: Message from Bernd Markgraf <markgraf@prinz-atm.CS.Uni-Magdeburg.De> 
   of "Thu, 20 Apr 2000 10:23:27 +0200." <Pine.GSO.3.95.1000420102122.19517A-100000@knecht> 
Date:   Thu, 20 Apr 2000 08:44:39 -0500
From:   Steve Lord <lord@sgi.com>
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing

> hi,
> 
> as i wrote before i also experienced this problem.
> 
> > Yup, I've been looking into this.
> > What are you doing to blow the 128k  cache?
> i just tried a ~90gb large xfs ;-) (my box has 128mb ram and 512mb swap -
> this should be plenty...) 

yes it should be plenty, could you run mkfs again on your disk and
send me the output - I want to see how it sizes things, that should
give us some clues. Also cat /proc/slabinfo and /proc/meminfo before and
after the mkfs and send that too.
 
Generally a clean mount should not have large memory requirements so this
is puzzling - unless the failure is not actually an out of memory thing
but some other issue.

Thanks

   Steve

>  
> > A "clean" file-system shouldn't be in reovery code, you must
> > have crashed the system at some point.
> i already sent a oops trace i got trying to mount the fresh 90gb
> xfs-partition.

Any chance of at least the ksymoops output from this? The raw numbers
do not do any good without symbol table info attachecd to them.

>  
>   bernd


From owner-linux-xfs@oss.sgi.com Thu Apr 20 14:43:24 2000
Received:  by oss.sgi.com id <S305158AbQDTN47>;
	Thu, 20 Apr 2000 06:56:59 -0700
Received: from pneumatic-tube.sgi.com ([204.94.214.22]:12315 "EHLO
        pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP
	id <S305157AbQDTN4j>; Thu, 20 Apr 2000 06:56:39 -0700
Received: from ledzep.cray.com (ledzep.cray.com [137.38.226.97]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id HAA08249
	for <linux-xfs@oss.sgi.com>; Thu, 20 Apr 2000 07:00:41 -0700 (PDT)
	mail_from (lord@sgi.com)
Received: from ironwood-e185.americas.sgi.com (ironwood.cray.com [128.162.185.212]) by ledzep.cray.com (SGI-SGI-8.9.3/craymail-smart-nospam1.0) with ESMTP id IAA11282; Thu, 20 Apr 2000 08:55:21 -0500 (CDT)
Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.184.86]) by ironwood-e185.americas.sgi.com (8.8.4/SGI-ironwood-e1.4) with ESMTP id IAA10064; Thu, 20 Apr 2000 08:55:13 -0500 (CDT)
Received: from jen.americas.sgi.com by jen.americas.sgi.com (8.9.3/SGI-client.1.6) via ESMTP id IAA07754; Thu, 20 Apr 2000 08:55:00 -0500
Message-Id: <200004201355.IAA07754@jen.americas.sgi.com>
X-Mailer: exmh version 2.1.1 10/15/1999
To:     Bernd Markgraf <markgraf@prinz-atm.CS.Uni-Magdeburg.De>
cc:     linux-xfs@oss.sgi.com
Subject: Re: NULL dereference on mount 
In-Reply-To: Message from Bernd Markgraf <markgraf@prinz-atm.CS.Uni-Magdeburg.De> 
   of "Thu, 20 Apr 2000 10:23:27 +0200." <Pine.GSO.3.95.1000420102122.19517A-100000@knecht> 
Date:   Thu, 20 Apr 2000 08:54:59 -0500
From:   Steve Lord <lord@sgi.com>
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing

> hi,
> 
> as i wrote before i also experienced this problem.
> 
> > Yup, I've been looking into this.
> > What are you doing to blow the 128k  cache?
> i just tried a ~90gb large xfs ;-) (my box has 128mb ram and 512mb swap -
> this should be plenty...) 
>  
> > A "clean" file-system shouldn't be in reovery code, you must
> > have crashed the system at some point.
> i already sent a oops trace i got trying to mount the fresh 90gb
> xfs-partition.
>  

Another thing to try would be to mount the filesystem on a clean boot - i.e.
mkfs, reboot, then mount. I just want to isolate things as much as possible
here - I suspect this will still fail.

Steve





From owner-linux-xfs@oss.sgi.com Thu Apr 20 14:43:24 2000
Received:  by oss.sgi.com id <S305160AbQDTStL>;
	Thu, 20 Apr 2000 11:49:11 -0700
Received: from deliverator.sgi.com ([204.94.214.10]:65086 "EHLO
        deliverator.sgi.com") by oss.sgi.com with ESMTP id <S305157AbQDTSsv>;
	Thu, 20 Apr 2000 11:48:51 -0700
Received: from ledzep.cray.com (ledzep.cray.com [137.38.226.97]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id LAA27813
	for <linux-xfs@oss.sgi.com>; Thu, 20 Apr 2000 11:44:06 -0700 (PDT)
	mail_from (n8994@sgi.com)
Received: from ironwood-e185.americas.sgi.com (ironwood.cray.com [128.162.185.212]) by ledzep.cray.com (SGI-SGI-8.9.3/craymail-smart-nospam1.0) with ESMTP id NAA45606 for <linux-xfs@oss.sgi.com>; Thu, 20 Apr 2000 13:47:34 -0500 (CDT)
Received: from nt8.americas.sgi.com (nt8.americas.sgi.com [128.162.195.8]) by ironwood-e185.americas.sgi.com (8.8.4/SGI-ironwood-e1.4) with ESMTP id NAA25661 for <linux-xfs@oss.sgi.com>; Thu, 20 Apr 2000 13:47:26 -0500 (CDT)
From:   Russell Cattelan <n8994@sgi.com>
Received: by nt8.americas.sgi.com (980427.SGI.8.8.8/SGI-client.1.6) id NAA38028; Thu, 20 Apr 2000 13:47:32 -0500 (CDT)
Message-Id: <200004201847.NAA38028@nt8.americas.sgi.com>
Date:   Thu, 20 Apr 2000 13:47:32 -0500 (CDT)
To:     linux-xfs@oss.sgi.com
Subject: TAKE - small bug fix in kmem_realloc
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing

Modid:  2.3.99pre2-xfs:slinx:58656a
Date:  Thu Apr 20 11:47:06 PDT 2000
Workarea:  nt8.americas.sgi.com:/data/clink/io/cattelan/x2.3-99-xfs

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

linux/fs/xfs/linux/xfs_random.c - 1.32
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/linux/fs/xfs/linux/xfs_random.c.diff?r1=text&tr1=1.32&r2=text&tr2=1.31&f=h
	- kmem_realloc may be called to SHRINK alloced space.
	  check to see if newsize is less that oldsize; memcpy the lesser of
	  the two.


From owner-linux-xfs@oss.sgi.com Thu Apr 20 14:43:24 2000
Received:  by oss.sgi.com id <S305164AbQDTVlw>;
	Thu, 20 Apr 2000 14:41:52 -0700
Received:  by oss.sgi.com id <S305157AbQDTVll>;
	Thu, 20 Apr 2000 14:41:41 -0700
From:   root <root@oss.sgi.com>
To:     linux-xfs@oss.sgi.com
Message-Id: <20000420214141Z305157-390+379@oss.sgi.com>
Date:   Thu, 20 Apr 2000 14:41:41 -0700
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing

bukl_mailer test

From root@oss.sgi.com Thu Apr 20 14:47:12 2000
Received:  by oss.sgi.com id <S305156AbQDTVq7>;
	Thu, 20 Apr 2000 14:46:59 -0700
From:   root <root@oss.sgi.com>
To:     x-outgoing@oss.sgi.com
Message-Id: <20000420214709Z305156-392+204@oss.sgi.com>
Date:   Thu, 20 Apr 2000 14:46:59 -0700
Return-Path: <root@oss.sgi.com>
X-Orcpt: rfc822;x-outgoing@oss.sgi.com

bukl_mailer test

From root@oss.sgi.com Thu Apr 20 14:50:12 2000
Received:  by oss.sgi.com id <S305162AbQDTVt6>;
	Thu, 20 Apr 2000 14:49:58 -0700
From:   root <root@oss.sgi.com>
To:     x-outgoing@oss.sgi.com
Message-Id: <20000420215010Z305162-392+207@oss.sgi.com>
Date:   Thu, 20 Apr 2000 14:49:58 -0700
Return-Path: <root@oss.sgi.com>
X-Orcpt: rfc822;x-outgoing@oss.sgi.com

bukl_mailer test

From owner-linux-xfs@oss.sgi.com Tue Apr 25 11:01:38 2000
Received:  by oss.sgi.com id <S305178AbQDTV5W>;
	Thu, 20 Apr 2000 14:57:22 -0700
Received: from pneumatic-tube.sgi.com ([204.94.214.22]:41300 "EHLO
        pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP
	id <S305158AbQDTV5L>; Thu, 20 Apr 2000 14:57:11 -0700
Received: from ledzep.cray.com (ledzep.cray.com [137.38.226.97]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id PAA05714
	for <linux-xfs@oss.sgi.com>; Thu, 20 Apr 2000 15:01:14 -0700 (PDT)
	mail_from (cattelan@sgi.com)
Received: from ironwood-e185.americas.sgi.com (ironwood.cray.com [128.162.185.212]) by ledzep.cray.com (SGI-SGI-8.9.3/craymail-smart-nospam1.0) with ESMTP id QAA35205 for <linux-xfs@oss.sgi.com>; Thu, 20 Apr 2000 16:55:54 -0500 (CDT)
Received: from gibble.americas.sgi.com (root@gibble.americas.sgi.com [128.162.195.80]) by ironwood-e185.americas.sgi.com (8.8.4/SGI-ironwood-e1.4) with ESMTP id QAA04535 for <linux-xfs@oss.sgi.com>; Thu, 20 Apr 2000 16:55:47 -0500 (CDT)
From:   cattelan@sgi.com
Received: by gibble.americas.sgi.com (8.9.3/SGI-client.1.6) id QAA08942; Thu, 20 Apr 2000 16:55:53 -0500
Message-Id: <200004202155.QAA08942@gibble.americas.sgi.com>
Date:   Thu, 20 Apr 2000 16:55:53 -0500
To:     linux-xfs@oss.sgi.com
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing

bukl_mailer test

From owner-linux-xfs@oss.sgi.com Tue Apr 25 11:01:38 2000
Received:  by oss.sgi.com id <S305157AbQDUPrc>;
	Fri, 21 Apr 2000 08:47:32 -0700
Received: from csmd2.CS.Uni-Magdeburg.De ([141.44.22.2]:38368 "EHLO
        csmd2.cs.uni-magdeburg.de") by oss.sgi.com with ESMTP
	id <S305155AbQDUPrG>; Fri, 21 Apr 2000 08:47:06 -0700
Received: from knecht.cs.uni-magdeburg.de (markgraf@knecht [141.44.21.3])
	by csmd2.cs.uni-magdeburg.de (8.9.3/8.9.3) with ESMTP id RAA04623;
	Fri, 21 Apr 2000 17:47:04 +0200 (MET DST)
Received: from localhost (markgraf@localhost)
	by knecht.cs.uni-magdeburg.de (8.8.8+Sun/8.8.8) with SMTP id RAA05322;
	Fri, 21 Apr 2000 17:46:09 +0200 (MET DST)
X-Authentication-Warning: knecht.cs.uni-magdeburg.de: markgraf owned process doing -bs
Date:   Fri, 21 Apr 2000 17:46:09 +0200 (MET DST)
From:   Bernd Markgraf <markgraf@mail.CS.Uni-Magdeburg.De>
X-Sender: markgraf@knecht
To:     Steve Lord <lord@sgi.com>
cc:     linux-xfs@oss.sgi.com
Subject: Re: NULL dereference on mount 
In-Reply-To: <200004201355.IAA07754@jen.americas.sgi.com>
Message-ID: <Pine.GSO.3.95.1000421174434.5319A-100000@knecht>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing

hi,

i just grabbed the latest sources from cvs and boom it worked. so however
changed the code during the last 2 days fixed the oops on mount. i just
tested xfs on a 330gb partition and it worked nicely.

happy easter,
  bernd

--
Death is happy, death is cool       
Death can be a useful tool         
Use a gun or use a knife          
Death can really change your life    
_________________________________________________________________________
Bernd Markgraf		                  Otto-von-Guericke-Universitaet
markgraf@mail.cs.uni-magdeburg.de         Magdeburg
http://www.cs.uni-magdeburg.de/~markgraf  Germany


From owner-linux-xfs@oss.sgi.com Tue Apr 25 11:01:38 2000
Received:  by oss.sgi.com id <S305159AbQDUQtd>;
	Fri, 21 Apr 2000 09:49:33 -0700
Received: from web6009.mail.yahoo.com ([128.11.23.82]:33806 "HELO
        web6009.mail.yahoo.com") by oss.sgi.com with SMTP
	id <S305155AbQDUQtV>; Fri, 21 Apr 2000 09:49:21 -0700
Received: (qmail 15587 invoked by uid 60001); 21 Apr 2000 16:49:20 -0000
Message-ID: <20000421164920.15586.qmail@web6009.mail.yahoo.com>
Received: from [144.254.211.46] by web6009.mail.yahoo.com; Fri, 21 Apr 2000 09:49:20 PDT
Date:   Fri, 21 Apr 2000 09:49:20 -0700 (PDT)
From:   Dan Koren <dankoren@yahoo.com>
Subject: Re: NULL dereference on mount 
To:     Bernd Markgraf <markgraf@prinz-atm.cs.uni-magdeburg.de>,
        Steve Lord <lord@sgi.com>
Cc:     linux-xfs@oss.sgi.com
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing



--- Bernd Markgraf
<markgraf@prinz-atm.cs.uni-magdeburg.de> wrote:
> hi,
> 
> i just grabbed the latest sources from cvs and boom
> it worked. so however changed the code during the
> last 2 days fixed the oops on mount. i just
> tested xfs on a 330gb partition and it worked
                  ^^^^^
> nicely.
> 
> happy easter,
>   bernd

Where did you manage to find a 330gb partition?
Inside an Easter egg? I'd like to get one too! :)


dk

__________________________________________________
Do You Yahoo!?
Send online invitations with Yahoo! Invites.
http://invites.yahoo.com

From owner-linux-xfs@oss.sgi.com Tue Apr 25 11:01:38 2000
Received:  by oss.sgi.com id <S305166AbQDURcB>;
	Fri, 21 Apr 2000 10:32:01 -0700
Received: from deliverator.sgi.com ([204.94.214.10]:24346 "EHLO
        deliverator.sgi.com") by oss.sgi.com with ESMTP id <S305155AbQDURbw>;
	Fri, 21 Apr 2000 10:31:52 -0700
Received: from ledzep.cray.com (ledzep.cray.com [137.38.226.97]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id KAA09938
	for <linux-xfs@oss.sgi.com>; Fri, 21 Apr 2000 10:27:06 -0700 (PDT)
	mail_from (cattelan@thebarn.com)
From:   cattelan@thebarn.com
Received: from ironwood-e185.americas.sgi.com (ironwood.cray.com [128.162.185.212]) by ledzep.cray.com (SGI-SGI-8.9.3/craymail-smart-nospam1.0) with ESMTP id MAA09515; Fri, 21 Apr 2000 12:30:35 -0500 (CDT)
Received: from gibble.americas.sgi.com (root@gibble.americas.sgi.com [128.162.195.80]) by ironwood-e185.americas.sgi.com (8.8.4/SGI-ironwood-e1.4) with ESMTP id MAA02754; Fri, 21 Apr 2000 12:30:27 -0500 (CDT)
Received: from gibble.americas.sgi.com by gibble.americas.sgi.com (8.9.3/SGI-client.1.6) via ESMTP id MAA10753; Fri, 21 Apr 2000 12:30:33 -0500
Date:   Fri, 21 Apr 2000 12:30:31 -0500
Message-ID: <14592.36919.669073.29443F@gibble.americas.sgi.com>
To:     markgraf@prinz-atm.CS.Uni-Magdeburg.De
Cc:     lord@sgi.com, linux-xfs@oss.sgi.com
Subject: Re: NULL dereference on mount 
In-Reply-To: In your message of "Fri, 21 Apr 2000 17:46:09 +0200 (MET DST)"
	<Pine.GSO.3.95.1000421174434.5319A-100000@knecht>
References: <200004201355.IAA07754@jen.americas.sgi.com>
	<Pine.GSO.3.95.1000421174434.5319A-100000@knecht>
User-Agent: Wanderlust/1.0.3 (Notorious) tm/7.108 XEmacs/21.1 (Bryce Canyon)
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing

At Fri, 21 Apr 2000 17:46:09 +0200 (MET DST),
Bernd Markgraf <markgraf@prinz-atm.CS.Uni-Magdeburg.De> wrote:

Well since you never sent in a kbd back trace we are not really
sure where your problem occured. We think it might have something
to do with kmem_realloc stomping on memory it shouldn't have.


> 
> 
> hi,
> 
> i just grabbed the latest sources from cvs and boom it worked. so however
> changed the code during the last 2 days fixed the oops on mount. i just
> tested xfs on a 330gb partition and it worked nicely.
> 
> happy easter,
>   bernd
> 
> --
> Death is happy, death is cool       
> Death can be a useful tool         
> Use a gun or use a knife          
> Death can really change your life    
> _________________________________________________________________________
> Bernd Markgraf		                  Otto-von-Guericke-Universitaet
> markgraf@mail.cs.uni-magdeburg.de         Magdeburg
> http://www.cs.uni-magdeburg.de/~markgraf  Germany

From owner-linux-xfs@oss.sgi.com Tue Apr 25 11:01:38 2000
Received:  by oss.sgi.com id <S305172AbQDUULW>;
	Fri, 21 Apr 2000 13:11:22 -0700
Received: from pneumatic-tube.sgi.com ([204.94.214.22]:33060 "EHLO
        pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP
	id <S305155AbQDUULD>; Fri, 21 Apr 2000 13:11:03 -0700
Received: from ledzep.cray.com (ledzep.cray.com [137.38.226.97]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id NAA02737
	for <linux-xfs@oss.sgi.com>; Fri, 21 Apr 2000 13:15:07 -0700 (PDT)
	mail_from (n8994@sgi.com)
Received: from ironwood-e185.americas.sgi.com (ironwood.cray.com [128.162.185.212]) by ledzep.cray.com (SGI-SGI-8.9.3/craymail-smart-nospam1.0) with ESMTP id PAA21827 for <linux-xfs@oss.sgi.com>; Fri, 21 Apr 2000 15:09:46 -0500 (CDT)
Received: from nt8.americas.sgi.com (nt8.americas.sgi.com [128.162.195.8]) by ironwood-e185.americas.sgi.com (8.8.4/SGI-ironwood-e1.4) with ESMTP id PAA08586 for <linux-xfs@oss.sgi.com>; Fri, 21 Apr 2000 15:09:39 -0500 (CDT)
From:   Russell Cattelan <n8994@sgi.com>
Received: by nt8.americas.sgi.com (980427.SGI.8.8.8/SGI-client.1.6) id PAA42206; Fri, 21 Apr 2000 15:09:45 -0500 (CDT)
Message-Id: <200004212009.PAA42206@nt8.americas.sgi.com>
Date:   Fri, 21 Apr 2000 15:09:45 -0500 (CDT)
To:     linux-xfs@oss.sgi.com
Subject: TAKE - Put back what once was
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing

Modid:  2.3.99pre2-xfs:slinx:59334a
Date:  Fri Apr 21 13:09:12 PDT 2000
Workarea:  nt8.americas.sgi.com:/data/clink/io/cattelan/x2.3-99-xfs

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

linux/fs/xfs/xfs_buf.h - 1.49
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/linux/fs/xfs/xfs_buf.h.diff?r1=text&tr1=1.49&r2=text&tr2=1.48&f=h
	- Put back pagebuf_rele in xfs_undelay.... this IS needed to correctly 
	  decrement the pb_hold count.
	  Added temporary debugging printk if pb_hold count is less than 2.
	  hopefully this will point to the case of a pagebuf being free'ed 
	  to soon.


From owner-linux-xfs@oss.sgi.com Tue Apr 25 11:01:38 2000
Received:  by oss.sgi.com id <S305180AbQDUXDX>;
	Fri, 21 Apr 2000 16:03:23 -0700
Received: from deliverator.sgi.com ([204.94.214.10]:26217 "EHLO
        deliverator.sgi.com") by oss.sgi.com with ESMTP id <S305179AbQDUXDF>;
	Fri, 21 Apr 2000 16:03:05 -0700
Received: from ledzep.cray.com (ledzep.cray.com [137.38.226.97]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id PAA13634
	for <linux-xfs@oss.sgi.com>; Fri, 21 Apr 2000 15:58:19 -0700 (PDT)
	mail_from (n8994@sgi.com)
Received: from ironwood-e185.americas.sgi.com (ironwood.cray.com [128.162.185.212]) by ledzep.cray.com (SGI-SGI-8.9.3/craymail-smart-nospam1.0) with ESMTP id SAA32865 for <linux-xfs@oss.sgi.com>; Fri, 21 Apr 2000 18:01:48 -0500 (CDT)
Received: from nt8.americas.sgi.com (nt8.americas.sgi.com [128.162.195.8]) by ironwood-e185.americas.sgi.com (8.8.4/SGI-ironwood-e1.4) with ESMTP id SAA13501 for <linux-xfs@oss.sgi.com>; Fri, 21 Apr 2000 18:01:40 -0500 (CDT)
From:   Russell Cattelan <n8994@sgi.com>
Received: by nt8.americas.sgi.com (980427.SGI.8.8.8/SGI-client.1.6) id SAA01487; Fri, 21 Apr 2000 18:01:46 -0500 (CDT)
Message-Id: <200004212301.SAA01487@nt8.americas.sgi.com>
Date:   Fri, 21 Apr 2000 18:01:46 -0500 (CDT)
To:     linux-xfs@oss.sgi.com
Subject: TAKE - 
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing

Modid:  2.3.99pre2-xfs:slinx:59354a
Date:  Fri Apr 21 16:01:08 PDT 2000
Workarea:  nt8.americas.sgi.com:/data/clink/io/cattelan/x2.3-99-xfs

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

linux/fs/xfs/linux/xfs_random.c - 1.33
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/linux/fs/xfs/linux/xfs_random.c.diff?r1=text&tr1=1.33&r2=text&tr2=1.32&f=h
	- add a simple implentation for delay()

linux/fs/xfs/xfs_buf_item.c - 1.99
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/linux/fs/xfs/xfs_buf_item.c.diff?r1=text&tr1=1.99&r2=text&tr2=1.98&f=h
	- added a pagebuf_hold()... seems to fix the low hold count while
	  tail pushing.


From owner-linux-xfs@oss.sgi.com Tue Apr 25 11:01:39 2000
Received:  by oss.sgi.com id <S305181AbQDVDgy>;
	Fri, 21 Apr 2000 20:36:54 -0700
Received: from pneumatic-tube.sgi.com ([204.94.214.22]:64059 "EHLO
        pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP
	id <S305179AbQDVDgb>; Fri, 21 Apr 2000 20:36:31 -0700
Received: from ledzep.cray.com (ledzep.cray.com [137.38.226.97]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id UAA00944
	for <linux-xfs@oss.sgi.com>; Fri, 21 Apr 2000 20:40:35 -0700 (PDT)
	mail_from (jtk@sgi.com)
Received: from ironwood-e185.americas.sgi.com (ironwood.cray.com [128.162.185.212]) by ledzep.cray.com (SGI-SGI-8.9.3/craymail-smart-nospam1.0) with ESMTP id WAA05326; Fri, 21 Apr 2000 22:35:13 -0500 (CDT)
Received: from tiki.americas.sgi.com (tiki.americas.sgi.com [128.162.195.11]) by ironwood-e185.americas.sgi.com (8.8.4/SGI-ironwood-e1.4) with ESMTP id WAA17307; Fri, 21 Apr 2000 22:35:06 -0500 (CDT)
From:   Ted Kline <jtk@sgi.com>
Received: by tiki.americas.sgi.com (980427.SGI.8.8.8/SGI-client.1.6) id WAA19562; Fri, 21 Apr 2000 22:35:12 -0500 (CDT)
Message-Id: <200004220335.WAA19562@tiki.americas.sgi.com>
Date:   Fri, 21 Apr 2000 22:35:12 -0500 (CDT)
To:     slinx-xfs@engr.sgi.com, linux-xfs@oss.sgi.com
Subject: TAKE - Implement vnode tracing.
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing

Implement an optional (via config) vnode tracing functionality..

Run your favorite form of make config/oldconfig/xconfig and select
"CONFIG_XFS_VNODE_TRACING" under XFS in the filesystem section.

i.e.:

>> 
>> [1]kdb> vnode 0xc2b58008
>> vnode: 0xc2b58008 v_count 2 type VDIR
>>    v_inode 0xc27b7700 v_bh->bh_first 0xc275c268 pobj 0xc275c250
>>    ops xfs_vnodeops
>>    v_trace 0xc3fa0920

From owner-linux-xfs@oss.sgi.com Tue Apr 25 11:01:40 2000
Received:  by oss.sgi.com id <S305179AbQDVD5E>;
	Fri, 21 Apr 2000 20:57:04 -0700
Received: from pneumatic-tube.sgi.com ([204.94.214.22]:21308 "EHLO
        pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP
	id <S305184AbQDVD4n>; Fri, 21 Apr 2000 20:56:43 -0700
Received: from ledzep.cray.com (ledzep.cray.com [137.38.226.97]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id VAA06814
	for <linux-xfs@oss.sgi.com>; Fri, 21 Apr 2000 21:00:46 -0700 (PDT)
	mail_from (jtk@sgi.com)
Received: from ironwood-e185.americas.sgi.com (ironwood.cray.com [128.162.185.212]) by ledzep.cray.com (SGI-SGI-8.9.3/craymail-smart-nospam1.0) with ESMTP id WAA60831; Fri, 21 Apr 2000 22:55:25 -0500 (CDT)
Received: from tiki.americas.sgi.com (tiki.americas.sgi.com [128.162.195.11]) by ironwood-e185.americas.sgi.com (8.8.4/SGI-ironwood-e1.4) with ESMTP id WAA17429; Fri, 21 Apr 2000 22:55:17 -0500 (CDT)
From:   Ted Kline <jtk@sgi.com>
Received: by tiki.americas.sgi.com (980427.SGI.8.8.8/SGI-client.1.6) id WAA19802; Fri, 21 Apr 2000 22:55:24 -0500 (CDT)
Message-Id: <200004220355.WAA19802@tiki.americas.sgi.com>
Subject: repost TAKE - Implement vnode tracing.
To:     slinx-xfs@engr.sgi.com, linux-xfs@oss.sgi.com
Date:   Fri, 21 Apr 2000 22:55:22 -0500 (CDT)
X-Mailer: ELM [version 2.5 PL2]
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing


Bummer, sendmail ate the major portion of my take msg...

	-Ted

Date: Fri, 21 Apr 2000 22:35:12 -0500 (CDT)
To: slinx-xfs@cthulhu.engr.sgi.com, linux-xfs@oss.sgi.com
Subject: TAKE - Implement vnode tracing.
Sender: owner-slinx-xfs@cthulhu.engr.sgi.com
Precedence: bulk

Implement an optional (via config) vnode tracing functionality..

Run your favorite form of make config/oldconfig/xconfig and select
"CONFIG_XFS_VNODE_TRACING" under XFS in the filesystem section.

i.e.:

   
   [1]kdb> vnode 0xc2b58008
   vnode: 0xc2b58008 v_count 2 type VDIR
      v_inode 0xc27b7700 v_bh->bh_first 0xc275c268 pobj 0xc275c250
      ops xfs_vnodeops
      v_trace 0xc3fa0920

 -later-

   [0]kdb> vntrace 0xc2b58008
   vntrace vp 0xc2b58008
   hold @xfs_vfsops.c:1396 v_count 1 => 2  ra = linvfs_read_super+0x1c4
     cpu = 1 pid = 1350 flag = 0x4100000 <VROOT VSHARE > 
   entry to xfs_getattr v_count = 2  ra = linvfs_read_super+0x1ff
     cpu = 1 pid = 1350 flag = 0x4100000 <VROOT VSHARE > 
   entry to xfs_getattr v_count = 2  ra = linvfs_revalidate+0x3a
     cpu = 1 pid = 1350 flag = 0x4100000 <VROOT VSHARE > 
   rele @xfs_super.c:351 v_count 2 => 1  ra = iput+0x38
     cpu = 1 pid = 1354 flag = 0x4100000 <VROOT VSHARE > 
   free @xfs_vfsops.c:1259  ra = fs_dounmount+0x90
     cpu = 1 pid = 1354 flag = 0x4100000 <VROOT VSHARE > 
   entry to xfs_inactive v_count = 0  ra = vn_rele+0x13d
     cpu = 1 pid = 1354 flag = 0x4100002 <VINACT VROOT VSHARE > 

   [0]kdb> 


linux/fs/Config.in
	- Add config tag for Vnode Tracing - CONFIG_XFS_VNODE_TRACING.

linux/fs/xfs/Makefile
linux/fs/xfs/linux/Makefile
	- Close a large hole in the header dependency chain.

linux/fs/xfs/linux/xfs_random.c
	- Correct #ifdef and fill out the ktrace() routines.

linux/fs/xfs/linux/xfs_vnode.c
	- Allocate/free the v_trace buffer, fill out the vn_trace_*()
	  routines.

linux/fs/xfs/pseudo-inc/sys/ktrace.h
	- Fill in missing pieces for the ktrace() routines.

linux/fs/xfs/pseudo-inc/sys/vnode.h
	- Correct #ifdef'ing for vnode tracing and fill in missing
	  pieces.

linux/fs/xfs/xfsidbg.c
	- Add some NULL deref protection to the kdb_vnode cmd.
	  Implement the kdb_vntrace cmd.

linux/include/asm-i386/kdbprivate.h
	- Bump the max # of kdb commands from 100 to 125.

- End of mod 2.3.99pre2-xfs:slinx:59377a




From owner-linux-xfs@oss.sgi.com Tue Apr 25 11:01:40 2000
Received:  by oss.sgi.com id <S305188AbQDVJbI>;
	Sat, 22 Apr 2000 02:31:08 -0700
Received: from mail.spaceisp.com ([208.131.6.15]:27660 "EHLO mail.spaceisp.com")
	by oss.sgi.com with ESMTP id <S305185AbQDVJat>;
	Sat, 22 Apr 2000 02:30:49 -0700
Received: from dialupusr-145.newyork.ny.spaceisp.com (208.131.6.145)
	by mail.spaceisp.com (8.9.3/8.9.3) with =?ISO-8859-1?Q?SMTP=9C?= id BAA18015;
	Sat, 22 Apr 2000 01:50:37 -0700
Date:   Sat, 22 Apr 2000 01:50:37 -0700
Message-Id: <200004220850.BAA18015@mail.spaceisp.com>
From:   Awesome Fax Biz <sweetmon@pplmail.com>
Reply-To: Awesome Fax Biz <sweetmon@pplmail.com>
To:     Awesome Fax Biz <sweetmon@pplmail.com>
Subject: Huge Monthly Residuals With Your Fax???
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing

Small Town Entrepreneur Discovers Amazing, New Way to Earn Money at
Home!

FREE REPORT Reveals....

How You can Earn $2,240/Wk...$8,960/Mo...  Sending Fax-Ads to Business
Offices in Your Area.. From your Home Fax Machine!

More Info, Click here:  http://3498247705/~real_fax_biz/index.html

NEW:  We are looking for Affiliates who want to make money!!!

More Info, Click here:  http://3498247705/~real_fax_biz/index.html

==========================================================

Subscribe to our Biz. Op. E-Zine and learn How To Make Money on the
Internet: Reply with subject line 'Subscribe Me'

To Be Removed, reply with 'Remove' in the Subject.


From owner-linux-xfs@oss.sgi.com Tue Apr 25 11:01:40 2000
Received:  by oss.sgi.com id <S305197AbQDYBrL>;
	Mon, 24 Apr 2000 18:47:11 -0700
Received: from mail.spaceisp.com ([208.131.6.15]:2055 "EHLO mail.spaceisp.com")
	by oss.sgi.com with ESMTP id <S305191AbQDYBrH>;
	Mon, 24 Apr 2000 18:47:07 -0700
Received: from dialupusr-145.newyork.ny.spaceisp.com (208.131.6.145)
	by mail.spaceisp.com (8.9.3/8.9.3) with =?ISO-8859-1?Q?SMTP=9C?= id SAA26175
	for <linux-xfs@oss.sgi.com>; Mon, 24 Apr 2000 18:08:10 -0700
From:   merchant@chargeemnow.com
To:     linux-xfs@oss.sgi.com
Subject: ADV:CREDIT CARD PROCESSING
Date:   Mon, 24 Apr 2000 19:55:18
Message-Id: <267.755681.873730@unknown>
Reply-To: merchant@chargeemnow.com
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing


*********************************************************
To be removed from from further mailings respond to 
this message with "remove" in the subject line.
*********************************************************

Dear Friend,

Discover how you can accept credit cards directly
from your website, telephone or fax for your products 
and services and never need to purchase or lease
expensive credit card equipment or pay a large monthly 
fee for online ordering capabilities or real time processing
transactions.

**Brand New** Merchant Credit Card acceptance program 
allows you to accept Visa, MasterCard, Amex and Discover 
any TIME,any WHERE through phone, fax or internet without 
the need to purchase or lease expensive credit card equipment. 
This brand new program will allow you to accept credit cards 
in 24-48 hours after submitting your application.

You simply pick up your telephone, dial a special toll free
800# 24 hrs a day 7 days a week, input a passcode and the
credit card # and receive an immediate authorization over 
the phone. Or if you prefer you can get your credit cards 
approved directly through your website. Within 2 days the 
money is deposited into your bank account. This is an exciting 
program for all businesses. Before you spend any money on 
a credit card merchant program LOOK at this new program! 

We have a 95%  approval rate for most business types 
regardless of past credit history!


If you have an interest in learning more about a Merchant Account 
for yourself or your business please email your Name, PHONE NUMBER (Don't forget your area code) and best time to call to:

mailto:order@chargeemnow.com
 
A representative will return your call within 24hrs.

Or feel free to call us on our 24 hour voicemail at:

1-800-288-7363

P.S. Ask about our Shoppingcart solutions and Agent opportunities!

This offer only applies to U.S. Residents only and some Canadians
with valid U.S. Social Security #'s.




IBS/PBS a registered ISO
for NBR
7657 Winnetka Ave
Canoga Park Ca. 91306

From owner-linux-xfs@oss.sgi.com Tue Apr 25 11:01:41 2000
Received:  by oss.sgi.com id <S305198AbQDYCjw>;
	Mon, 24 Apr 2000 19:39:52 -0700
Received: from [134.6.67.21] ([134.6.67.21]:4612 "EHLO mcoexc03.mlm.maxtor.com")
	by oss.sgi.com with ESMTP id <S305191AbQDYCjk>;
	Mon, 24 Apr 2000 19:39:40 -0700
Received: by mcoexc03.mlm.maxtor.com with Internet Mail Service (5.5.2650.21)
	id <JP7D34QW>; Mon, 24 Apr 2000 20:40:28 -0600
Message-ID: <09D1E9BD9C30D311919200A0C9DD5C2C016226F3@mcaexc01.msj.maxtor.com>
From:   "Macy, Kip" <Kip_Macy@Maxtor.com>
To:     "'linux-xfs@oss.sgi.com'" <linux-xfs@oss.sgi.com>
Subject: assertion failure in xfs_vnode.c:890
Date:   Mon, 24 Apr 2000 20:40:26 -0600
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01BFAE5F.9D1BC152"
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01BFAE5F.9D1BC152
Content-Type: text/plain;
	charset="iso-8859-1"

The following just occurred when trying to mount an XFS partition over NFS
(on the local 
machine). This is the most recent source.

XFS assertion failed:vp->v_count > 0, file: xfs_vnode.c:890
...
kernel BUG at xfs_debug.c:86!
due to panic@0xc01e2ef9

kdb> bt

assfail
vn_rele
linvfs_put_inode
iput
nfsd_iget
find_fh_dentry
fh_verify
nfsd_statfs
nfsd_proc_statfs
nfsd_dispatch
svc_process
nfsd
kernel_thread

------_=_NextPart_001_01BFAE5F.9D1BC152
Content-Type: text/html;
	charset="iso-8859-1"

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
<META NAME="Generator" CONTENT="MS Exchange Server version 5.5.2650.12">
<TITLE>assertion failure in xfs_vnode.c:890</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=2>The following just occurred when trying to mount an XFS partition over NFS (on the local </FONT>
<BR><FONT SIZE=2>machine). This is the most recent source.</FONT>
</P>

<P><FONT SIZE=2>XFS assertion failed:vp-&gt;v_count &gt; 0, file: xfs_vnode.c:890</FONT>
<BR><FONT SIZE=2>...</FONT>
<BR><FONT SIZE=2>kernel BUG at xfs_debug.c:86!</FONT>
<BR><FONT SIZE=2>due to panic@0xc01e2ef9</FONT>
</P>

<P><FONT SIZE=2>kdb&gt; bt</FONT>
</P>

<P><FONT SIZE=2>assfail</FONT>
<BR><FONT SIZE=2>vn_rele</FONT>
<BR><FONT SIZE=2>linvfs_put_inode</FONT>
<BR><FONT SIZE=2>iput</FONT>
<BR><FONT SIZE=2>nfsd_iget</FONT>
<BR><FONT SIZE=2>find_fh_dentry</FONT>
<BR><FONT SIZE=2>fh_verify</FONT>
<BR><FONT SIZE=2>nfsd_statfs</FONT>
<BR><FONT SIZE=2>nfsd_proc_statfs</FONT>
<BR><FONT SIZE=2>nfsd_dispatch</FONT>
<BR><FONT SIZE=2>svc_process</FONT>
<BR><FONT SIZE=2>nfsd</FONT>
<BR><FONT SIZE=2>kernel_thread</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01BFAE5F.9D1BC152--

From owner-linux-xfs@oss.sgi.com Tue Apr 25 11:01:41 2000
Received:  by oss.sgi.com id <S305199AbQDYCvw>;
	Mon, 24 Apr 2000 19:51:52 -0700
Received: from [134.6.67.21] ([134.6.67.21]:35333 "EHLO
        mcoexc03.mlm.maxtor.com") by oss.sgi.com with ESMTP
	id <S305191AbQDYCve>; Mon, 24 Apr 2000 19:51:34 -0700
Received: by mcoexc03.mlm.maxtor.com with Internet Mail Service (5.5.2650.21)
	id <JP7D344M>; Mon, 24 Apr 2000 20:52:20 -0600
Message-ID: <09D1E9BD9C30D311919200A0C9DD5C2C016226F5@mcaexc01.msj.maxtor.com>
From:   "Macy, Kip" <Kip_Macy@Maxtor.com>
To:     "'linux-xfs@oss.sgi.com'" <linux-xfs@oss.sgi.com>
Subject: RE: assertion failure in xfs_vnode.c:890
Date:   Mon, 24 Apr 2000 20:52:18 -0600
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01BFAE61.45A21898"
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01BFAE61.45A21898
Content-Type: text/plain;
	charset="iso-8859-1"

I can now trigger this bug consistently by doing a cvs checkout in an nfs
mounted
xfs filesystem. The backtrace is almost the same except nfsd_statfs is
replaced by nfsd_create and
nfsd_proc_statfs is replaced by nfsd_proc_mkdir. 

-----Original Message-----
From: Macy, Kip [mailto:Kip_Macy@maxtor.com]
Sent: Monday, April 24, 2000 7:40 PM
To: 'linux-xfs@oss.sgi.com'
Subject: assertion failure in xfs_vnode.c:890



The following just occurred when trying to mount an XFS partition over NFS
(on the local 
machine). This is the most recent source. 

XFS assertion failed:vp->v_count > 0, file: xfs_vnode.c:890 
... 
kernel BUG at xfs_debug.c:86! 
due to panic@0xc01e2ef9 

kdb> bt 

assfail 
vn_rele 
linvfs_put_inode 
iput 
nfsd_iget 
find_fh_dentry 
fh_verify 
nfsd_statfs 
nfsd_proc_statfs 
nfsd_dispatch 
svc_process 
nfsd 
kernel_thread 


------_=_NextPart_001_01BFAE61.45A21898
Content-Type: text/html;
	charset="iso-8859-1"

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
<TITLE>assertion failure in xfs_vnode.c:890</TITLE>

<META content="MSHTML 5.00.2314.1000" name=GENERATOR></HEAD>
<BODY>
<DIV><FONT color=#0000ff face=Arial size=2>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN class=873024702-25042000>I can 
now trigger this bug consistently by doing a cvs checkout in an nfs 
mounted</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN class=873024702-25042000>xfs 
filesystem. The backtrace&nbsp;is almost the same</SPAN></FONT><FONT 
color=#0000ff face=Arial size=2><SPAN class=873024702-25042000> 
except&nbsp;</SPAN></FONT><FONT color=#0000ff face=Arial size=2><SPAN 
class=873024702-25042000>nfsd_statfs is replaced by nfsd_create 
and</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN 
class=873024702-25042000>nfsd_proc_statfs is replaced by 
nfsd_proc_mkdir.&nbsp;</SPAN></FONT></DIV></FONT></DIV>
<BLOCKQUOTE style="MARGIN-RIGHT: 0px">
  <DIV class=OutlookMessageHeader><FONT face="Times New Roman" 
  size=2>-----Original Message-----<BR><B>From:</B> Macy, Kip 
  [mailto:Kip_Macy@maxtor.com]<BR><B>Sent:</B> Monday, April 24, 2000 7:40 
  PM<BR><B>To:</B> 'linux-xfs@oss.sgi.com'<BR><B>Subject:</B> assertion failure 
  in xfs_vnode.c:890<BR><BR></DIV></FONT>
  <P><FONT size=2>The following just occurred when trying to mount an XFS 
  partition over NFS (on the local </FONT><BR><FONT size=2>machine). This is the 
  most recent source.</FONT> </P>
  <P><FONT size=2>XFS assertion failed:vp-&gt;v_count &gt; 0, file: 
  xfs_vnode.c:890</FONT> <BR><FONT size=2>...</FONT> <BR><FONT size=2>kernel BUG 
  at xfs_debug.c:86!</FONT> <BR><FONT size=2>due to panic@0xc01e2ef9</FONT> </P>
  <P><FONT size=2>kdb&gt; bt</FONT> </P>
  <P><FONT size=2>assfail</FONT> <BR><FONT size=2>vn_rele</FONT> <BR><FONT 
  size=2>linvfs_put_inode</FONT> <BR><FONT size=2>iput</FONT> <BR><FONT 
  size=2>nfsd_iget</FONT> <BR><FONT size=2>find_fh_dentry</FONT> <BR><FONT 
  size=2>fh_verify</FONT> <BR><FONT size=2>nfsd_statfs</FONT> <BR><FONT 
  size=2>nfsd_proc_statfs</FONT> <BR><FONT size=2>nfsd_dispatch</FONT> <BR><FONT 
  size=2>svc_process</FONT> <BR><FONT size=2>nfsd</FONT> <BR><FONT 
  size=2>kernel_thread</FONT> </P></BLOCKQUOTE></BODY></HTML>

------_=_NextPart_001_01BFAE61.45A21898--

From owner-linux-xfs@oss.sgi.com Tue Apr 25 11:01:41 2000
Received:  by oss.sgi.com id <S305191AbQDYGcf>;
	Mon, 24 Apr 2000 23:32:35 -0700
Received: from nic-31-c26-223.mn.mediaone.net ([24.31.26.223]:61701 "EHLO
        lupo.thebarn.com") by oss.sgi.com with ESMTP id <S305184AbQDYGcR>;
	Mon, 24 Apr 2000 23:32:17 -0700
Received: from thebarn.com (localhost [127.0.0.1])
	by lupo.thebarn.com (8.9.3/8.9.1) with ESMTP id BAA38840;
	Tue, 25 Apr 2000 01:31:46 -0500 (CDT)
Message-ID: <39053BD1.7363024B@thebarn.com>
Date:   Tue, 25 Apr 2000 01:31:46 -0500
From:   Russell Cattelan <cattelan@thebarn.com>
X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 4.0-STABLE i386)
X-Accept-Language: en
MIME-Version: 1.0
To:     "Macy, Kip" <Kip_Macy@Maxtor.com>
CC:     "'linux-xfs@oss.sgi.com'" <linux-xfs@oss.sgi.com>
Subject: Re: assertion failure in xfs_vnode.c:890
References: <09D1E9BD9C30D311919200A0C9DD5C2C016226F3@mcaexc01.msj.maxtor.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing

"Macy, Kip" wrote:

>
>
> The following just occurred when trying to mount an XFS partition over
> NFS (on the local
> machine). This is the most recent source.
>
> XFS assertion failed:vp->v_count > 0, file: xfs_vnode.c:890

Yup this is know problem.
The problem occurs when ever the linux inode reference count gets
bumped,
iget does not  communicate down to the xfs vnode if the count it already
1 or greater
that the count has been incremented
iput  on the other hand will always communicate down  to decrement the
count thus giving us a v_count of 0 when it should be at least one.

We are currently talking about how to fix this problem; which involves
trying to merge the linux inode and the xfs vnode... which should prove
to be a lot of work. :-(

> ...
> kernel BUG at xfs_debug.c:86!
> due to panic@0xc01e2ef9
>
> kdb> bt
>
> assfail
> vn_rele
> linvfs_put_inode
> iput
> nfsd_iget
> find_fh_dentry
> fh_verify
> nfsd_statfs
> nfsd_proc_statfs
> nfsd_dispatch
> svc_process
> nfsd
> kernel_thread

--
Russell Cattelan
cattelan@thebarn.com




From owner-linux-xfs@oss.sgi.com Tue Apr 25 11:01:41 2000
Received:  by oss.sgi.com id <S305209AbQDYQbb>;
	Tue, 25 Apr 2000 09:31:31 -0700
Received: from pneumatic-tube.sgi.com ([204.94.214.22]:30985 "EHLO
        pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP
	id <S305204AbQDYQbU>; Tue, 25 Apr 2000 09:31:20 -0700
Received: from ledzep.cray.com (ledzep.cray.com [137.38.226.97]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id JAA06730
	for <linux-xfs@oss.sgi.com>; Tue, 25 Apr 2000 09:35:27 -0700 (PDT)
	mail_from (lord@sgi.com)
Received: from ironwood-e185.americas.sgi.com (ironwood.cray.com [128.162.185.212]) by ledzep.cray.com (SGI-SGI-8.9.3/craymail-smart-nospam1.0) with ESMTP id LAA45908; Tue, 25 Apr 2000 11:30:02 -0500 (CDT)
Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.184.86]) by ironwood-e185.americas.sgi.com (8.8.4/SGI-ironwood-e1.4) with ESMTP id LAA08030; Tue, 25 Apr 2000 11:29:53 -0500 (CDT)
Received: from jen.americas.sgi.com by jen.americas.sgi.com (8.9.3/SGI-client.1.6) via ESMTP id LAA25488; Tue, 25 Apr 2000 11:28:50 -0500
Message-Id: <200004251628.LAA25488@jen.americas.sgi.com>
X-Mailer: exmh version 2.1.1 10/15/1999
To:     roy@karlsbakk.net
cc:     linux-kernel@vger.rutgers.edu, linux-xfs@oss.sgi.com
Subject: Re: xfs and kernel size
Date:   Tue, 25 Apr 2000 11:28:49 -0500
From:   Steve Lord <lord@sgi.com>
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing


I just happened to see your post on Linux kernel - you should probably
ask on linux-xfs@oss.sgi.com which is the mailing list for XFS. The
volume on the kernel list is a bit much to always catch mailings
like yours.

Anyway, if you downloaded a patch file you probably have out of date
code, the best way to get uptodate code is to use the cvs repository.
If you were attempting to use the patch and using XFS as a root filesystem
you will have problems - including a panic during boot which looked similar
to what you reported, these are fixed in the cvs version.

see: http://oss.sgi.com/projects/xfs/cvs_download.html

for instructions on how to download the repository.

As for kernel size, we do have people who have built xfs into their
kernel and run that way sucessfully, it maybe that you have a lot of
other code compiled into your kernel. I personally always use modules,
although I just did build and boot a kernel with XFS build in.

> ls -l vmlinux
-rwxr-xr-x    1 lord     network   5279892 Apr 25 10:37 vmlinux*

> size vmlinux
   text    data     bss     dec     hex filename
2083734  640497  568064 3292295  323c87 vmlinux


Steve

>> Yesterday, I downloaded the latest version of xfs (a patch to
>> 2.3.99-pre2) and compiled it with xfs statically linked in. After a
>> reboot, I got as long as "Checking if this processor honours the WP
>> bit even in supervisor mode..." and ... panic Found I had been a
>> little too quick when I checked the size of /usr/src/linux/vmlinux -
>> 3.8MB... A little wc told me the xfs filesystem consisted of no less
>> than 110.000 lines of code.

>> Anyone got an idea of how to get this stuff compiled in? It's probably
>> possible doing it in a modular fashion, but how if I want to use xfs
>> on / ?

>> Please CC: to me as I'm not on the list

>> Roy