From owner-linux-xfs@oss.sgi.com Wed Nov  1 07:02:21 2000
Received:  by oss.sgi.com id <S553954AbQKAPCL>;
	Wed, 1 Nov 2000 07:02:11 -0800
Received: from deliverator.sgi.com ([204.94.214.10]:61523 "EHLO
        deliverator.sgi.com") by oss.sgi.com with ESMTP id <S553943AbQKAPCB>;
	Wed, 1 Nov 2000 07:02:01 -0800
Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id GAA19742
	for <linux-xfs@oss.sgi.com>; Wed, 1 Nov 2000 06:54:11 -0800 (PST)
	mail_from (lord@jen.americas.sgi.com)
Received: from thistle-e185.americas.sgi.com (thistle-e185.americas.sgi.com [128.162.185.204]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id JAA6924575; Wed, 1 Nov 2000 09:00:43 -0600 (CST)
Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.184.86]) by thistle-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id JAA19464; Wed, 1 Nov 2000 09:00:42 -0600 (CST)
Received: from jen.americas.sgi.com (lord@localhost)
	by jen.americas.sgi.com (8.9.3/8.9.3) with ESMTP id IAA08404;
	Wed, 1 Nov 2000 08:57:05 -0600
Message-Id: <200011011457.IAA08404@jen.americas.sgi.com>
X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4
To:     "yxy_oversea" <yxy_oversea@hotmail.com>
cc:     linux-xfs@oss.sgi.com
Subject: Re: fseeko64() suspended 
In-Reply-To: Message from "yxy_oversea" <yxy_oversea@hotmail.com> 
   of "Wed, 01 Nov 2000 14:43:13 +0800." <OE437hx27kBnccYTjr80000016f@hotmail.com> 
Content-Transfer-Encoding: 8bit
Date:   Wed, 01 Nov 2000 08:57:05 -0600
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,

Hmmm, this really looks like something in the program is touching the
whole 2 Gbytes of data in there. Can you send us the source code of
your program and how you build it (or at least a test case which
has the same results). Could you also run strace on the program and
send the output. Finally could you run xfs_bmap -v on the output file
and send us the output of that too.

Thanks

  Steve Lord


> Dear friends:
>    Thanks every much for your kindness, my questions were gradually solved here.
>  
>    Now I can use fseeko64() now, but in fact it takes very long time 
> for a fseeko64() call as if the call is suspended. During the call,
> kswapd use CPU madly, statistics as follows:
> 
>  2:30pm  up  3:17,  4 users,  load average: 0.23, 0.05, 0.02
> 45 processes: 41 sleeping, 4 running, 0 zombie, 0 stopped
> CPU states:  1.9% user, 98.0% system,  0.0% nice,  0.0% idle
> Mem:   126104K av,  123992K used,    2112K free,       0K shrd,    6780K buff
> Swap:   56188K av,       0K used,   56188K free                   98704K cached
> 
>   PID USER     PRI  NI  SIZE  RSS SHARE STAT  LIB %CPU %MEM   TIME COMMAND
>     3 root      17   0     0    0     0 RW      0 90.0  0.0   3:12 kswapd
>  2112 root       9   0   428  428   304 R       0  6.7  0.3   0:00 a.out
>  2113 root      12   0   872  872   684 R       0  3.8  0.6   0:00 top
>     1 root       8   0   476  476   404 S       0  0.0  0.3   0:05 init
>     2 root       9   0     0    0     0 SW      0  0.0  0.0   0:00 kapmd
>     4 root       9   0     0    0     0 SW      0  0.0  0.0   0:00 kflushd
>     5 root       9   0     0    0     0 SW      0  0.0  0.0   0:03 kupdate
>     6 root      -1 -20     0    0     0 SW<     0  0.0  0.0   0:00 mdrecoveryd
>    19 root       9   0   548  548   452 S       0  0.0  0.4   0:00 devfsd
>  1028 root       9   0     0    0     0 SW      0  0.0  0.0   0:00 pagebuf_daemon
>  1029 root       9   0     0    0     0 SW      0  0.0  0.0   0:00 page_daemon
>  1291 bin        9   0   496  496   404 S       0  0.0  0.3   0:00 portmap
>  1291 bin        9   0   496  496   404 S       0  0.0  0.3   0:00 portmap
>  1314 root       9   0   560  560   472 S       0  0.0  0.4   0:00 rpc.statd
>  1328 root       9   0   480  480   412 S       0  0.0  0.3   0:00 apmd
>  1384 root       9   0   552  552   452 S       0  0.0  0.4   0:00 syslogd
>  1393 root       9   0  1080 1080   388 S       0  0.0  0.8   0:00 klogd
>  1407 nobody     9   0   628  628   520 S       0  0.0  0.4   0:00 identd
> 
>     a.out is my test program, which opens a big file(4.7G) on xfs filesystem
> by using fopen64(); and then use fseeko64() to locate to 2.1G. The statistics 
> is got when the program executing fseeko64(), it took more than 2 minutes. After
> 2 minutes, the call return successfully.
> 
>    My questions are:
>       why it took so many time for a seek call? I'v never met it on ext2 or xfs
> on IRIX.
>        why kswapd ate all my CPU resource and memory resource when I call fseeko64()?
> 
>        My destination is to use big files in my program, open/read/seek, very simple
> needs, but how can I do this?
> 
>       Thanks a lot!
>                                     yangxy.
 


From owner-linux-xfs@oss.sgi.com Wed Nov  1 13:03:43 2000
Received:  by oss.sgi.com id <S553682AbQKAVDY>;
	Wed, 1 Nov 2000 13:03:24 -0800
Received: from guinan.digitalrom.com ([208.29.19.5]:31493 "EHLO
        guinan.digitalrom.com") by oss.sgi.com with ESMTP
	id <S553660AbQKAVC7>; Wed, 1 Nov 2000 13:02:59 -0800
Received: from trekmaster ([208.29.19.69]) by guinan.digitalrom.com
          (Post.Office MTA v3.5 release 215 ID# 35-53703U100L2S100V35)
          with SMTP id com for <linux-xfs@oss.sgi.com>;
          Wed, 1 Nov 2000 15:01:57 -0600
From:   pswartz@digitalrom.com (Patrick Swartz)
To:     <linux-xfs@oss.sgi.com>
Subject: CVS Download Instructions
Date:   Wed, 1 Nov 2000 15:06:06 -0600
Message-ID: <OLEAJMNOEMOMMNEIMMINGEGACBAA.pswartz@digitalrom.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Importance: Normal
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing

I am new to the work of SGI and the XFS project. I am excited to see SGI's
XFS become mainstream in the Linux world.

My question is now that I have downloaded the latest from the cvs tree what
do I do now?  The instruction page says "...follow the build process,
according to the file README.build in the top level directory."  After much
searching, I can't find any README.build file.

I am currently running 2.4.0-test9 on my system with all of the current
binutils, util-linux, modutils, gcc, etc.  The base system started out as a
RH7.0 with all of RH bug fixes applied.

Thanks for all your help,

Patrick Swartz


From owner-linux-xfs@oss.sgi.com Wed Nov  1 13:42:13 2000
Received:  by oss.sgi.com id <S553687AbQKAVmE>;
	Wed, 1 Nov 2000 13:42:04 -0800
Received: from deliverator.sgi.com ([204.94.214.10]:64107 "EHLO
        deliverator.sgi.com") by oss.sgi.com with ESMTP id <S553669AbQKAVll>;
	Wed, 1 Nov 2000 13:41:41 -0800
Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id NAA02849
	for <linux-xfs@oss.sgi.com>; Wed, 1 Nov 2000 13:33:51 -0800 (PST)
	mail_from (lord@jen.americas.sgi.com)
Received: from thistle-e185.americas.sgi.com (thistle-e185.americas.sgi.com [128.162.185.204]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id PAA7478449 for <linux-xfs@oss.sgi.com>; Wed, 1 Nov 2000 15:40:24 -0600 (CST)
Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.184.86]) by thistle-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id PAA18843 for <linux-xfs@oss.sgi.com>; Wed, 1 Nov 2000 15:40:24 -0600 (CST)
Received: (from lord@localhost)
	by jen.americas.sgi.com (8.9.3/8.9.3) id PAA01316
	for linux-xfs@oss.sgi.com; Wed, 1 Nov 2000 15:36:45 -0600
Date:   Wed, 1 Nov 2000 15:36:45 -0600
From:   Steve Lord <lord@sgi.com>
Message-Id: <200011012136.PAA01316@jen.americas.sgi.com>
Subject: TAKE - Move XFS linux tree to 2.4.0-test10
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

Ugrade to 2.4.0-test10

Date:  Wed Nov  1 13:35:42 PST 2000
Workarea:  jen.americas.sgi.com:/src/lord/xfs-linux-test10

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


Modid:  2.4.x-xfs:slinx:77320a
linux/drivers/ide/osb4.c - 1.1
linux/drivers/ide/slc90e66.c - 1.1
linux/drivers/net/isa-skeleton.c - 1.1
linux/drivers/zorro/Config.in - 1.1
linux/drivers/zorro/gen-devlist.c - 1.1
linux/drivers/zorro/zorro.ids - 1.1
linux/include/asm-generic/pgtable.h - 1.1
linux/include/asm-ia64/acpikcfg.h - 1.1
linux/include/asm-ia64/module.h - 1.1
linux/include/asm-ia64/parport.h - 1.1
linux/include/linux/divert.h - 1.1
linux/arch/ia64/lib/idiv64.S - 1.1
linux/arch/ia64/lib/idiv32.S - 1.1
linux/include/linux/zorro_ids.h - 1.1
linux/Documentation/usb/bluetooth.txt - 1.1
linux/mm/oom_kill.c - 1.1
linux/net/core/dv.c - 1.1
linux/scripts/tkparse.c - 1.7
linux/scripts/Menuconfig - 1.9
linux/scripts/Configure - 1.10
linux/net/x25/af_x25.c - 1.15
linux/net/unix/sysctl_net_unix.c - 1.5
linux/net/unix/af_unix.c - 1.23
linux/net/sunrpc/svcsock.c - 1.11
linux/net/sunrpc/auth_null.c - 1.4
linux/net/sunrpc/auth.c - 1.6
linux/net/socket.c - 1.19
linux/net/rose/af_rose.c - 1.16
linux/net/packet/af_packet.c - 1.18
linux/net/netsyms.c - 1.28
linux/net/netrom/af_netrom.c - 1.15
linux/net/netlink/netlink_dev.c - 1.8
linux/net/netlink/af_netlink.c - 1.10
linux/net/lapb/lapb_iface.c - 1.5
linux/net/irda/irmod.c - 1.15
linux/net/irda/af_irda.c - 1.15
linux/net/ipx/af_ipx.c - 1.14
linux/net/ipv6/udp.c - 1.17
linux/net/ipv6/tcp_ipv6.c - 1.19
linux/net/ipv6/sit.c - 1.12
linux/net/ipv6/raw.c - 1.14
linux/net/ipv6/protocol.c - 1.6
linux/net/ipv6/af_inet6.c - 1.15
linux/net/ipv4/utils.c - 1.4
linux/net/ipv4/udp.c - 1.18
linux/net/ipv4/tcp_timer.c - 1.15
linux/net/ipv4/tcp_output.c - 1.15
linux/net/ipv4/tcp_ipv4.c - 1.28
linux/net/ipv4/tcp.c - 1.21
linux/net/ipv4/sysctl_net_ipv4.c - 1.10
linux/net/ipv4/route.c - 1.20
linux/net/ipv4/raw.c - 1.14
linux/net/ipv4/protocol.c - 1.6
linux/net/ipv4/ipip.c - 1.13
linux/net/ipv4/ip_sockglue.c - 1.11
linux/net/ipv4/ip_output.c - 1.19
linux/net/ipv4/ip_nat_dumb.c - 1.4
linux/net/ipv4/ip_input.c - 1.10
linux/net/ipv4/ip_gre.c - 1.13
linux/net/ipv4/ip_forward.c - 1.6
linux/net/ipv4/arp.c - 1.14
linux/net/ipv4/af_inet.c - 1.21
linux/net/core/sysctl_net_core.c - 1.4
linux/net/core/dev_mcast.c - 1.8
linux/net/core/dev.c - 1.28
linux/net/core/Makefile - 1.4
linux/net/bridge/br.c - 1.18
linux/net/ax25/ax25_ds_in.c - 1.3
linux/net/ax25/af_ax25.c - 1.16
linux/net/ax25/Config.in - 1.5
linux/net/appletalk/ddp.c - 1.14
linux/net/Makefile - 1.12
linux/net/Config.in - 1.15
linux/net/802/tr.c - 1.10
linux/net/802/psnap.c - 1.6
linux/net/802/p8022.c - 1.6
linux/net/802/llc_macinit.c - 1.4
linux/mm/vmscan.c - 1.38
linux/mm/vmalloc.c - 1.23
linux/mm/swapfile.c - 1.25
linux/mm/swap.c - 1.5
linux/mm/page_alloc.c - 1.31
linux/mm/mremap.c - 1.17
linux/mm/mprotect.c - 1.11
linux/mm/mmap.c - 1.27
linux/mm/mlock.c - 1.11
linux/mm/memory.c - 1.38
linux/mm/filemap.c - 1.57
linux/mm/Makefile - 1.6
linux/kernel/time.c - 1.6
linux/kernel/sysctl.c - 1.32
linux/kernel/sys.c - 1.18
linux/kernel/signal.c - 1.16
linux/kernel/sched.c - 1.27
linux/kernel/printk.c - 1.10
linux/kernel/panic.c - 1.13
linux/kernel/module.c - 1.17
linux/kernel/ksyms.c - 1.65
linux/ipc/sem.c - 1.13
linux/init/main.c - 1.44
linux/include/net/x25.h - 1.7
linux/include/net/tcp.h - 1.19
linux/include/net/sock.h - 1.18
linux/include/net/rose.h - 1.5
linux/include/net/netrom.h - 1.5
linux/include/net/ipx.h - 1.4
linux/include/net/ax25.h - 1.5
linux/include/linux/zorro.h - 1.5
linux/include/linux/wrapper.h - 1.7
linux/include/linux/vt_kern.h - 1.3
linux/include/linux/sysctl.h - 1.29
linux/include/linux/swap.h - 1.21
linux/include/linux/sunrpc/auth.h - 1.5
linux/include/linux/sockios.h - 1.4
linux/include/linux/sched.h - 1.31
linux/include/linux/pagemap.h - 1.19
linux/include/linux/netlink.h - 1.3
linux/include/linux/netdevice.h - 1.18
linux/include/linux/module.h - 1.16
linux/include/linux/mm.h - 1.39
linux/include/linux/linkage.h - 1.7
linux/include/linux/init.h - 1.10
linux/include/linux/in.h - 1.4
linux/include/linux/if_ether.h - 1.7
linux/include/linux/fs.h - 1.67
linux/include/linux/elf.h - 1.9
linux/include/linux/console_struct.h - 1.3
linux/include/linux/console.h - 1.6
linux/include/linux/coda_linux.h - 1.9
linux/include/linux/byteorder/swabb.h - 1.3
linux/include/linux/byteorder/swab.h - 1.4
linux/include/linux/byteorder/pdp_endian.h - 1.4
linux/include/linux/byteorder/little_endian.h - 1.4
linux/include/linux/byteorder/big_endian.h - 1.4
linux/include/asm-sparc64/string.h - 1.6
linux/include/asm-sparc64/spitfire.h - 1.3
linux/include/asm-sparc64/resource.h - 1.8
linux/include/asm-sparc64/posix_types.h - 1.5
linux/include/asm-sparc64/pgtable.h - 1.16
linux/include/asm-sparc64/param.h - 1.3
linux/include/asm-sparc64/fcntl.h - 1.8
linux/include/asm-sparc64/envctrl.h - 1.3
linux/include/asm-sparc64/audioio.h - 1.8
linux/include/asm-sparc64/atomic.h - 1.6
linux/include/asm-sparc/smp.h - 1.8
linux/include/asm-sparc/resource.h - 1.9
linux/include/asm-sparc/pgtable.h - 1.16
linux/include/asm-sparc/param.h - 1.3
linux/include/asm-sparc/page.h - 1.13
linux/include/asm-sparc/fcntl.h - 1.8
linux/include/asm-sparc/audioio.h - 1.9
linux/include/asm-ppc/pgtable.h - 1.22
linux/include/asm-ppc/init.h - 1.7
linux/include/asm-ppc/byteorder.h - 1.4
linux/include/asm-mips/processor.h - 1.11
linux/include/asm-mips/pgtable.h - 1.11
linux/include/asm-m68k/pgtable.h - 1.11
linux/include/asm-i386/user.h - 1.5
linux/include/asm-i386/ptrace.h - 1.7
linux/include/asm-i386/processor.h - 1.18
linux/include/asm-i386/pgtable.h - 1.21
linux/include/asm-i386/param.h - 1.3
linux/include/asm-i386/page.h - 1.14
linux/include/asm-i386/floppy.h - 1.4
linux/include/asm-i386/elf.h - 1.5
linux/include/asm-i386/cache.h - 1.6
linux/include/asm-i386/bugs.h - 1.12
linux/include/asm-arm/pgtable.h - 1.15
linux/include/asm-arm/current.h - 1.5
linux/include/asm-arm/byteorder.h - 1.3
linux/include/asm-alpha/unaligned.h - 1.3
linux/include/asm-alpha/system.h - 1.13
linux/include/asm-alpha/string.h - 1.5
linux/include/asm-alpha/pgtable.h - 1.22
linux/include/asm-alpha/fcntl.h - 1.8
linux/include/asm-alpha/compiler.h - 1.5
linux/include/asm-alpha/byteorder.h - 1.3
linux/fs/vfat/namei.c - 1.16
linux/fs/umsdos/inode.c - 1.15
linux/fs/super.c - 1.39
linux/fs/proc/base.c - 1.20
linux/fs/proc/array.c - 1.24
linux/fs/pipe.c - 1.19
linux/fs/open.c - 1.27
linux/fs/ntfs/fs.c - 1.20
linux/fs/nls/nls_base.c - 1.7
linux/fs/nfsd/vfs.c - 1.29
linux/fs/nfsd/nfsfh.c - 1.22
linux/fs/nfsd/nfscache.c - 1.7
linux/fs/nfsd/nfs3xdr.c - 1.15
linux/fs/nfs/write.c - 1.20
linux/fs/nfs/read.c - 1.17
linux/fs/nfs/nfs3xdr.c - 1.5
linux/fs/nfs/nfs2xdr.c - 1.7
linux/fs/nfs/file.c - 1.16
linux/fs/nfs/dir.c - 1.22
linux/fs/minix/namei.c - 1.14
linux/fs/minix/bitmap.c - 1.9
linux/fs/locks.c - 1.12
linux/fs/lockd/svclock.c - 1.9
linux/fs/lockd/mon.c - 1.7
linux/fs/lockd/clntproc.c - 1.10
linux/fs/lockd/clntlock.c - 1.7
linux/fs/isofs/rock.c - 1.8
linux/fs/inode.c - 1.32
linux/fs/hfs/trans.c - 1.3
linux/fs/fat/cvf.c - 1.5
linux/fs/ext2/namei.c - 1.17
linux/fs/exec.c - 1.32
linux/fs/coda/psdev.c - 1.13
linux/fs/coda/inode.c - 1.10
linux/fs/coda/dir.c - 1.17
linux/fs/buffer.c - 1.45
linux/fs/binfmt_elf.c - 1.22
linux/fs/attr.c - 1.9
linux/drivers/zorro/zorro.c - 1.7
linux/drivers/zorro/Makefile - 1.5
linux/drivers/video/virgefb.c - 1.9
linux/drivers/video/vgacon.c - 1.12
linux/drivers/video/vesafb.c - 1.12
linux/drivers/video/retz3fb.c - 1.8
linux/drivers/video/q40fb.c - 1.7
linux/drivers/video/promcon.c - 1.6
linux/drivers/video/offb.c - 1.15
linux/drivers/video/newport_con.c - 1.7
linux/drivers/video/mdacon.c - 1.6
linux/drivers/video/macfb.c - 1.8
linux/drivers/video/fbmem.c - 1.31
linux/drivers/video/fbcon.c - 1.16
linux/drivers/video/dummycon.c - 1.7
linux/drivers/video/dnfb.c - 1.9
linux/drivers/video/cyberfb.c - 1.9
linux/drivers/video/controlfb.c - 1.12
linux/drivers/video/clgenfb.c - 1.14
linux/drivers/usb/usb.c - 1.40
linux/drivers/usb/hub.c - 1.30
linux/drivers/usb/audio.c - 1.25
linux/drivers/usb/Makefile - 1.34
linux/drivers/usb/Config.in - 1.36
linux/drivers/sound/waveartist.c - 1.11
linux/drivers/sound/sound_core.c - 1.14
linux/drivers/sound/sonicvibes.c - 1.25
linux/drivers/sound/msnd_pinnacle.c - 1.12
linux/drivers/sound/es1371.c - 1.26
linux/drivers/sound/es1370.c - 1.24
linux/drivers/sgi/char/sgiserial.c - 1.8
linux/drivers/scsi/wd7000.c - 1.8
linux/drivers/scsi/sr.c - 1.21
linux/drivers/scsi/sg.c - 1.16
linux/drivers/scsi/scsi.c - 1.32
linux/drivers/scsi/imm.c - 1.7
linux/drivers/scsi/ide-scsi.c - 1.14
linux/drivers/scsi/hosts.c - 1.22
linux/drivers/scsi/gvp11.c - 1.8
linux/drivers/scsi/fastlane.c - 1.6
linux/drivers/scsi/esp.c - 1.14
linux/drivers/scsi/eata.c - 1.13
linux/drivers/scsi/cyberstormII.c - 1.6
linux/drivers/scsi/cyberstorm.c - 1.6
linux/drivers/scsi/blz2060.c - 1.6
linux/drivers/scsi/blz1230.c - 1.6
linux/drivers/scsi/amiga7xx.c - 1.6
linux/drivers/scsi/aic7xxx.c - 1.19
linux/drivers/scsi/aha152x.c - 1.14
linux/drivers/scsi/a2091.c - 1.9
linux/drivers/sbus/char/zs.c - 1.13
linux/drivers/sbus/char/vfc_dev.c - 1.9
linux/drivers/sbus/char/sunkbd.c - 1.14
linux/drivers/sbus/char/su.c - 1.11
linux/drivers/sbus/char/sab82532.c - 1.12
linux/drivers/sbus/char/envctrl.c - 1.9
linux/drivers/sbus/char/bpp.c - 1.13
linux/drivers/sbus/char/Makefile - 1.6
linux/drivers/sbus/audio/dbri.h - 1.4
linux/drivers/sbus/audio/dbri.c - 1.9
linux/drivers/sbus/audio/cs4215.h - 1.4
linux/drivers/sbus/audio/audio.c - 1.11
linux/drivers/sbus/audio/Makefile - 1.3
linux/drivers/sbus/Makefile - 1.3
linux/drivers/pci/quirks.c - 1.17
linux/drivers/pci/pci.c - 1.30
linux/drivers/net/wd.c - 1.8
linux/drivers/net/wavelan.p.h - 1.9
linux/drivers/net/wavelan.c - 1.17
linux/drivers/net/tlan.h - 1.10
linux/drivers/net/tlan.c - 1.16
linux/drivers/net/sunqe.c - 1.14
linux/drivers/net/sunlance.c - 1.19
linux/drivers/net/sunhme.c - 1.20
linux/drivers/net/sunbmac.c - 1.14
linux/drivers/net/smc-ultra32.c - 1.9
linux/drivers/net/smc-ultra.c - 1.10
linux/drivers/net/skeleton.c - 1.8
linux/drivers/net/sgiseeq.c - 1.8
linux/drivers/net/seeq8005.c - 1.9
linux/drivers/net/rcpci45.c - 1.13
linux/drivers/net/rclanmtl.h - 1.3
linux/drivers/net/rclanmtl.c - 1.4
linux/drivers/net/pcnet32.c - 1.18
linux/drivers/net/ni52.c - 1.9
linux/drivers/net/ni5010.c - 1.8
linux/drivers/net/ne3210.c - 1.8
linux/drivers/net/ne2.c - 1.9
linux/drivers/net/ne.c - 1.10
linux/drivers/net/lne390.c - 1.9
linux/drivers/net/hydra.c - 1.9
linux/drivers/net/hplance.c - 1.6
linux/drivers/net/hp100.c - 1.14
linux/drivers/net/hp.c - 1.7
linux/drivers/net/hp-plus.c - 1.8
linux/drivers/net/hamradio/scc.c - 1.12
linux/drivers/net/hamradio/bpqether.c - 1.13
linux/drivers/net/hamradio/baycom_epp.c - 1.12
linux/drivers/net/hamradio/Makefile - 1.6
linux/drivers/net/fmv18x.c - 1.8
linux/drivers/net/eth16i.c - 1.11
linux/drivers/net/es3210.c - 1.9
linux/drivers/net/eepro100.c - 1.23
linux/drivers/net/eepro.c - 1.14
linux/drivers/net/e2100.c - 1.8
linux/drivers/net/depca.c - 1.10
linux/drivers/net/daynaport.c - 1.6
linux/drivers/net/cs89x0.c - 1.13
linux/drivers/net/at1700.c - 1.8
linux/drivers/net/ariadne2.c - 1.8
linux/drivers/net/ariadne.c - 1.10
linux/drivers/net/apne.c - 1.6
linux/drivers/net/acenic.c - 1.19
linux/drivers/net/ac3200.c - 1.10
linux/drivers/net/a2065.c - 1.10
linux/drivers/net/Space.c - 1.26
linux/drivers/net/Config.in - 1.31
linux/drivers/net/8390.h - 1.6
linux/drivers/net/82596.c - 1.12
linux/drivers/net/3c59x.c - 1.20
linux/drivers/net/3c527.c - 1.13
linux/drivers/net/3c515.c - 1.13
linux/drivers/net/3c509.c - 1.16
linux/drivers/net/3c507.c - 1.14
linux/drivers/net/3c505.c - 1.14
linux/drivers/net/3c503.c - 1.11
linux/drivers/net/3c501.c - 1.9
linux/drivers/macintosh/macserial.c - 1.15
linux/drivers/isdn/sc/init.c - 1.4
linux/drivers/isdn/sc/debug.c - 1.3
linux/drivers/isdn/isdn_common.c - 1.15
linux/drivers/char/vt.c - 1.15
linux/drivers/char/vc_screen.c - 1.10
linux/drivers/char/tty_io.c - 1.24
linux/drivers/char/tpqic02.c - 1.9
linux/drivers/char/sysrq.c - 1.11
linux/drivers/char/synclink.c - 1.10
linux/drivers/char/stallion.c - 1.12
linux/drivers/char/specialix.c - 1.8
linux/drivers/char/softdog.c - 1.9
linux/drivers/char/serial167.c - 1.6
linux/drivers/char/serial.c - 1.34
linux/drivers/char/selection.c - 1.4
linux/drivers/char/rtc.c - 1.17
linux/drivers/char/rocket.c - 1.9
linux/drivers/char/riscom8.c - 1.6
linux/drivers/char/random.c - 1.11
linux/drivers/char/qpmouse.c - 1.8
linux/drivers/char/pc_keyb.c - 1.19
linux/drivers/char/pc110pad.c - 1.9
linux/drivers/char/misc.c - 1.20
linux/drivers/char/mem.c - 1.27
linux/drivers/char/lp.c - 1.17
linux/drivers/char/keyboard.c - 1.20
linux/drivers/char/istallion.c - 1.12
linux/drivers/char/ftape/zftape/zftape-write.c - 1.3
linux/drivers/char/ftape/zftape/zftape-vtbl.c - 1.3
linux/drivers/char/ftape/zftape/zftape-rw.c - 1.3
linux/drivers/char/ftape/zftape/zftape-read.c - 1.3
linux/drivers/char/ftape/zftape/zftape-ctl.c - 1.3
linux/drivers/char/ftape/zftape/zftape-buffers.c - 1.3
linux/drivers/char/ftape/lowlevel/ftape-write.c - 1.3
linux/drivers/char/ftape/lowlevel/ftape-tracing.c - 1.3
linux/drivers/char/ftape/lowlevel/ftape-rw.c - 1.4
linux/drivers/char/ftape/lowlevel/ftape-io.c - 1.4
linux/drivers/char/ftape/lowlevel/ftape-format.c - 1.3
linux/drivers/char/ftape/lowlevel/ftape-bsm.c - 1.4
linux/drivers/char/ftape/lowlevel/fdc-isr.c - 1.3
linux/drivers/char/ftape/lowlevel/fdc-io.c - 1.4
linux/drivers/char/esp.c - 1.6
linux/drivers/char/epca.c - 1.10
linux/drivers/char/dtlk.c - 1.10
linux/drivers/char/dsp56k.c - 1.11
linux/drivers/char/cyclades.c - 1.14
linux/drivers/char/console.c - 1.18
linux/drivers/char/acquirewdt.c - 1.9
linux/drivers/cdrom/sbpcd.c - 1.9
linux/drivers/cdrom/cdrom.c - 1.25
linux/drivers/block/xd.c - 1.17
linux/drivers/block/rd.c - 1.24
linux/drivers/block/paride/pt.c - 1.9
linux/drivers/block/paride/pg.c - 1.9
linux/drivers/block/paride/Makefile - 1.4
linux/drivers/block/nbd.c - 1.16
linux/drivers/block/loop.c - 1.25
linux/drivers/block/ll_rw_blk.c - 1.49
linux/drivers/block/floppy.c - 1.22
linux/drivers/block/acsi_slm.c - 1.7
linux/drivers/Makefile - 1.19
linux/arch/sparc64/solaris/socksys.c - 1.11
linux/arch/sparc64/mm/init.c - 1.19
linux/arch/sparc64/kernel/sys_sparc32.c - 1.28
linux/arch/sparc64/kernel/starfire.c - 1.7
linux/arch/sparc64/kernel/sparc64_ksyms.c - 1.22
linux/arch/sparc64/kernel/smp.c - 1.19
linux/arch/sparc64/kernel/setup.c - 1.14
linux/arch/sparc64/kernel/ioctl32.c - 1.25
linux/arch/sparc64/defconfig - 1.31
linux/arch/sparc64/config.in - 1.32
linux/arch/sparc/mm/sun4c.c - 1.21
linux/arch/sparc/mm/srmmu.c - 1.19
linux/arch/sparc/mm/init.c - 1.20
linux/arch/sparc/mm/fault.c - 1.12
linux/arch/sparc/kernel/sun4m_smp.c - 1.14
linux/arch/sparc/kernel/sun4d_smp.c - 1.14
linux/arch/sparc/kernel/sparc-stub.c - 1.7
linux/arch/sparc/kernel/smp.c - 1.11
linux/arch/sparc/kernel/setup.c - 1.15
linux/arch/sparc/kernel/process.c - 1.17
linux/arch/sparc/kernel/ioport.c - 1.16
linux/arch/sparc/kernel/ebus.c - 1.7
linux/arch/sparc/config.in - 1.23
linux/arch/ppc/mm/init.c - 1.28
linux/arch/ppc/kernel/smp.c - 1.21
linux/arch/ppc/kernel/prep_setup.c - 1.14
linux/arch/ppc/kernel/apus_setup.c - 1.13
linux/arch/ppc/config.in - 1.30
linux/arch/ppc/amiga/config.c - 1.8
linux/arch/ppc/8xx_io/uart.c - 1.9
linux/arch/mips/sgi/kernel/indy_timer.c - 1.8
linux/arch/mips/mm/init.c - 1.11
linux/arch/mips/kernel/time.c - 1.9
linux/arch/m68k/q40/config.c - 1.6
linux/arch/m68k/mm/init.c - 1.11
linux/arch/m68k/mac/debug.c - 1.6
linux/arch/m68k/mac/config.c - 1.6
linux/arch/m68k/kernel/setup.c - 1.8
linux/arch/m68k/config.in - 1.18
linux/arch/m68k/atari/debug.c - 1.5
linux/arch/m68k/amiga/config.c - 1.5
linux/arch/m68k/amiga/chipram.c - 1.7
linux/arch/m68k/amiga/amiga_ksyms.c - 1.4
linux/arch/i386/mm/ioremap.c - 1.8
linux/arch/i386/mm/init.c - 1.25
linux/arch/i386/mm/fault.c - 1.13
linux/arch/i386/kernel/traps.c - 1.30
linux/arch/i386/kernel/time.c - 1.14
linux/arch/i386/kernel/smp.c - 1.29
linux/arch/i386/kernel/setup.c - 1.38
linux/arch/i386/kernel/ptrace.c - 1.12
linux/arch/i386/kernel/mtrr.c - 1.21
linux/arch/i386/kernel/entry.S - 1.29
linux/arch/i386/kernel/apm.c - 1.27
linux/arch/i386/defconfig - 1.47
linux/arch/i386/config.in - 1.49
linux/arch/i386/boot/setup.S - 1.16
linux/arch/i386/Makefile - 1.18
linux/arch/arm/mm/mm-armv.c - 1.18
linux/arch/arm/mm/init.c - 1.19
linux/arch/arm/config.in - 1.22
linux/arch/alpha/mm/init.c - 1.15
linux/arch/alpha/mm/fault.c - 1.11
linux/arch/alpha/lib/Makefile - 1.7
linux/arch/alpha/kernel/sys_takara.c - 1.8
linux/arch/alpha/kernel/sys_sx164.c - 1.9
linux/arch/alpha/kernel/sys_sio.c - 1.12
linux/arch/alpha/kernel/sys_sable.c - 1.7
linux/arch/alpha/kernel/sys_rx164.c - 1.8
linux/arch/alpha/kernel/sys_ruffian.c - 1.9
linux/arch/alpha/kernel/sys_rawhide.c - 1.9
linux/arch/alpha/kernel/sys_noritake.c - 1.9
linux/arch/alpha/kernel/sys_mikasa.c - 1.10
linux/arch/alpha/kernel/sys_miata.c - 1.9
linux/arch/alpha/kernel/sys_eb64p.c - 1.8
linux/arch/alpha/kernel/sys_dp264.c - 1.12
linux/arch/alpha/kernel/sys_cabriolet.c - 1.10
linux/arch/alpha/kernel/sys_alcor.c - 1.8
linux/arch/alpha/kernel/setup.c - 1.16
linux/arch/alpha/kernel/core_cia.c - 1.15
linux/arch/alpha/defconfig - 1.14
linux/arch/alpha/config.in - 1.25
linux/README - 1.8
linux/Makefile - 1.71
linux/MAINTAINERS - 1.48
linux/Documentation/networking/z8530drv.txt - 1.4
linux/Documentation/exception.txt - 1.4
linux/Documentation/IO-mapping.txt - 1.4
linux/Documentation/Configure.help - 1.64
linux/Documentation/Changes - 1.26
linux/CREDITS - 1.44
linux/net/decnet/af_decnet.c - 1.17
linux/include/linux/ide.h - 1.25
linux/fs/hpfs/buffer.c - 1.5
linux/drivers/usb/printer.c - 1.29
linux/drivers/usb/acm.c - 1.32
linux/drivers/i2o/i2o_scsi.c - 1.10
linux/drivers/i2o/i2o_core.c - 1.22
linux/drivers/tc/zs.c - 1.5
linux/drivers/net/jazzsonic.c - 1.4
linux/drivers/net/declance.c - 1.7
linux/drivers/char/dz.c - 1.8
linux/arch/mips/sgi/kernel/promcon.c - 1.4
linux/arch/mips/dec/time.c - 1.5
linux/arch/mips/dec/promcon.c - 1.3
linux/arch/mips/baget/vacserial.c - 1.8
linux/drivers/net/arlan.c - 1.10
linux/drivers/char/ppdev.c - 1.20
linux/drivers/block/cpqarray.c - 1.17
linux/drivers/parport/parport_mfc3.c - 1.6
linux/drivers/parport/Makefile - 1.4
linux/drivers/net/ppp_generic.c - 1.17
linux/drivers/char/sx.c - 1.13
linux/drivers/char/q40_keyb.c - 1.4
linux/drivers/char/generic_serial.c - 1.8
linux/include/linux/isapnp.h - 1.9
linux/fs/partitions/check.c - 1.19
linux/fs/partitions/atari.c - 1.5
linux/drivers/scsi/oktagon_esp.c - 1.4
linux/drivers/pnp/isapnp.c - 1.17
linux/arch/i386/kernel/i8259.c - 1.19
linux/Documentation/isapnp.txt - 1.4
linux/drivers/char/ip2main.c - 1.9
linux/drivers/char/ip2/i2ellis.c - 1.3
linux/drivers/atm/nicstar.c - 1.9
linux/arch/i386/kernel/semaphore.c - 1.13
linux/net/atm/svc.c - 1.8
linux/net/atm/pvc.c - 1.7
linux/arch/arm/kernel/semaphore.c - 1.7
linux/drivers/block/DAC960.c - 1.21
linux/arch/sparc64/kernel/semaphore.c - 1.4
linux/arch/sparc64/kernel/pci.c - 1.13
linux/arch/sparc/kernel/semaphore.c - 1.3
linux/arch/sh/mm/ioremap.c - 1.5
linux/arch/sh/mm/init.c - 1.11
linux/arch/sh/mm/fault.c - 1.12
linux/arch/sh/kernel/time.c - 1.12
linux/arch/sh/kernel/setup.c - 1.9
linux/arch/sh/kernel/semaphore.c - 1.4
linux/arch/sh/kernel/entry.S - 1.14
linux/include/asm-sh/pgtable.h - 1.13
linux/include/pcmcia/version.h - 1.7
linux/drivers/pcmcia/cs_internal.h - 1.10
linux/drivers/pcmcia/cs.c - 1.22
linux/drivers/pcmcia/cistpl.c - 1.10
linux/drivers/pcmcia/bulkmem.c - 1.11
linux/arch/m68k/kernel/semaphore.c - 1.3
linux/drivers/net/pcmcia/pcnet_cs.c - 1.11
linux/drivers/net/pcmcia/3c589_cs.c - 1.12
linux/drivers/sound/nm256_audio.c - 1.9
linux/drivers/net/wan/cosa.c - 1.15
linux/drivers/net/tokenring/ibmtr.c - 1.10
linux/include/linux/pci_ids.h - 1.27
linux/drivers/net/wan/sdlamain.c - 1.4
linux/drivers/scsi/sim710.c - 1.6
linux/drivers/net/pcmcia/xirc2ps_cs.c - 1.10
linux/drivers/net/pcmcia/3c574_cs.c - 1.10
linux/drivers/net/pcmcia/fmvj18x_cs.c - 1.7
linux/Documentation/vm/locking - 1.5
linux/mm/highmem.c - 1.16
linux/mm/bootmem.c - 1.12
linux/include/linux/bootmem.h - 1.7
linux/include/asm-i386/pgtable-3level.h - 1.5
linux/include/asm-i386/pgtable-2level.h - 1.6
linux/fs/bfs/inode.c - 1.11
linux/fs/bfs/file.c - 1.13
linux/fs/bfs/dir.c - 1.11
linux/drivers/usb/dc2xx.c - 1.12
linux/drivers/net/sis900.h - 1.5
linux/drivers/pci/gen-devlist.c - 1.6
linux/drivers/pci/pci.ids - 1.23
linux/include/asm-i386/pgalloc.h - 1.7
linux/include/asm-alpha/pgalloc.h - 1.7
linux/mm/numa.c - 1.6
linux/include/linux/mmzone.h - 1.12
linux/drivers/sound/trident.h - 1.9
linux/drivers/sound/trident.c - 1.16
linux/drivers/net/aironet4500_core.c - 1.9
linux/drivers/net/aironet4500_card.c - 1.7
linux/kernel/timer.c - 1.11
linux/drivers/scsi/scsi_merge.c - 1.22
linux/drivers/pcmcia/yenta.c - 1.20
linux/arch/i386/kernel/acpi.c - 1.19
linux/include/asm-sparc64/pgalloc.h - 1.7
linux/fs/cramfs/inode.c - 1.11
linux/drivers/usb/scanner.c - 1.15
linux/include/asm-sparc/pgalloc.h - 1.8
linux/drivers/usb/usbmouse.c - 1.7
linux/drivers/telephony/ixj.c - 1.8
linux/net/ipv4/inetpeer.c - 1.4
linux/drivers/net/tokenring/smctr.c - 1.7
linux/drivers/usb/devio.c - 1.11
linux/drivers/ieee1394/raw1394.c - 1.7
linux/drivers/ieee1394/Config.in - 1.4
linux/drivers/char/mxser.c - 1.4
linux/drivers/ieee1394/aic5800.c - 1.4
linux/fs/autofs4/expire.c - 1.7
linux/drivers/zorro/names.c - 1.2
linux/fs/autofs4/root.c - 1.10
linux/drivers/usb/usb-uhci.c - 1.15
linux/drivers/usb/usb-ohci.h - 1.7
linux/drivers/usb/usb-ohci.c - 1.15
linux/drivers/usb/scanner.h - 1.9
linux/drivers/sound/ac97_codec.c - 1.14
linux/drivers/net/irda/nsc-ircc.c - 1.8
linux/drivers/char/vme_scc.c - 1.3
linux/arch/ia64/kernel/head.S - 1.5
linux/arch/ia64/kernel/semaphore.c - 1.5
linux/arch/ia64/kernel/fw-emu.c - 1.4
linux/arch/ia64/kernel/entry.S - 1.9
linux/arch/ia64/kernel/efi.c - 1.8
linux/arch/ia64/kernel/acpi.c - 1.6
linux/arch/ia64/kernel/Makefile - 1.7
linux/arch/ia64/ia32/sys_ia32.c - 1.9
linux/arch/ia64/ia32/ia32_support.c - 1.3
linux/arch/ia64/ia32/ia32_signal.c - 1.6
linux/arch/ia64/ia32/binfmt_elf32.c - 1.7
linux/arch/ia64/ia32/Makefile - 1.5
linux/arch/ia64/hp/hpsim_console.c - 1.2
linux/arch/ia64/dig/iosapic.c - 1.6
linux/arch/ia64/config.in - 1.13
linux/arch/ia64/boot/bootloader.c - 1.3
linux/arch/ia64/Makefile - 1.6
linux/Documentation/pm.txt - 1.3
linux/Documentation/ia64/README - 1.3
linux/arch/ia64/kernel/irq.c - 1.8
linux/arch/ia64/tools/Makefile - 1.5
linux/arch/ia64/kernel/setup.c - 1.6
linux/arch/ia64/kernel/signal.c - 1.6
linux/arch/ia64/kernel/smp.c - 1.6
linux/arch/ia64/kernel/sys_ia64.c - 1.4
linux/arch/ia64/kernel/time.c - 1.7
linux/arch/ia64/kernel/traps.c - 1.7
linux/arch/ia64/kernel/unaligned.c - 1.5
linux/arch/ia64/kernel/unwind.c - 1.4
linux/arch/ia64/lib/Makefile - 1.5
linux/arch/ia64/kernel/ivt.S - 1.7
linux/arch/ia64/kernel/sal.c - 1.4
linux/arch/ia64/kernel/ptrace.c - 1.5
linux/arch/ia64/kernel/process.c - 1.6
linux/arch/ia64/kernel/perfmon.c - 1.4
linux/arch/ia64/kernel/mca.c - 1.4
linux/arch/ia64/mm/init.c - 1.6
linux/arch/ia64/kernel/mca_asm.S - 1.4
linux/arch/ia64/kernel/pal.S - 1.4
linux/arch/ia64/kernel/pci-dma.c - 1.6
linux/drivers/sound/via82cxxx_audio.c - 1.9
linux/include/asm-ia64/io.h - 1.4
linux/include/asm-ia64/ia32.h - 1.6
linux/include/asm-ia64/hardirq.h - 1.7
linux/include/asm-ia64/fcntl.h - 1.5
linux/include/asm-ia64/efi.h - 1.4
linux/include/asm-ia64/delay.h - 1.2
linux/include/asm-ia64/bitops.h - 1.4
linux/include/asm-ia64/atomic.h - 1.4
linux/include/asm-ia64/acpi-ext.h - 1.3
linux/include/asm-ia64/siginfo.h - 1.7
linux/include/asm-ia64/smp.h - 1.6
linux/include/asm-ia64/sal.h - 1.4
linux/include/asm-ia64/processor.h - 1.6
linux/include/asm-ia64/pgtable.h - 1.9
linux/include/asm-ia64/pgalloc.h - 1.4
linux/include/asm-ia64/pci.h - 1.6
linux/include/asm-ia64/param.h - 1.3
linux/include/asm-ia64/pal.h - 1.6
linux/include/asm-ia64/page.h - 1.7
linux/include/asm-ia64/offsets.h - 1.7
linux/include/asm-ia64/ptrace_offsets.h - 1.5
linux/include/linux/auto_fs4.h - 1.2
linux/include/asm-ia64/ptrace.h - 1.5
linux/include/asm-ia64/mmu_context.h - 1.4
linux/include/asm-ia64/spinlock.h - 1.5
linux/include/asm-ia64/semaphore.h - 1.4
linux/include/asm-ia64/unistd.h - 1.8
linux/include/asm-ia64/uaccess.h - 1.4
linux/include/asm-ia64/unwind.h - 1.3
linux/include/asm-ia64/unaligned.h - 1.2
linux/include/asm-ia64/system.h - 1.5
linux/include/asm-ia64/string.h - 1.3
linux/drivers/video/sun3fb.c - 1.3
linux/drivers/net/8139too.c - 1.12
linux/arch/i386/kernel/microcode.c - 1.7
linux/drivers/usb/plusb.c - 1.6
linux/fs/devfs/util.c - 1.4
linux/fs/devfs/base.c - 1.11
linux/drivers/isdn/hysdn/boardergo.c - 1.3
linux/drivers/net/skfp/skfddi.c - 1.7
linux/net/bridge/br_private_stp.h - 1.2
linux/net/bridge/br_ioctl.c - 1.3
linux/net/bridge/br_if.c - 1.4
linux/Documentation/networking/8139too.txt - 1.7
linux/drivers/net/tulip/tulip_core.c - 1.12
linux/drivers/char/wdt977.c - 1.5
linux/drivers/char/wdt285.c - 1.6
linux/include/asm-mips64/init.h - 1.3
linux/include/asm-mips64/pgtable.h - 1.5
linux/arch/mips64/mm/init.c - 1.5
linux/drivers/atm/fore200e.c - 1.7
linux/arch/mips64/sgi-ip27/ip27-timer.c - 1.6
linux/arch/mips64/sgi-ip27/ip27-rtc.c - 1.4
linux/arch/mips64/sgi-ip27/ip27-memory.c - 1.6
linux/arch/mips64/sgi-ip22/ip22-timer.c - 1.4
linux/drivers/usb/wacom.c - 1.7
linux/drivers/usb/rio500.c - 1.5
linux/drivers/usb/pegasus.c - 1.11
linux/include/asm-sh/pgalloc.h - 1.2
linux/include/asm-sh/pgalloc-2level.h - 1.2
linux/drivers/char/sh-sci.c - 1.8
linux/Documentation/zorro.txt - 1.2
linux/net/econet/af_econet.c - 1.6
linux/include/linux/usb.h - 1.10
linux/include/asm-ia64/hw_irq.h - 1.3
linux/drivers/usb/serial/whiteheat.h - 1.4
linux/drivers/usb/serial/usb-serial.h - 1.10
linux/arch/ia64/kernel/irq_ia64.c - 1.5
linux/drivers/ide/via82cxxx.c - 1.10
linux/drivers/ide/ide.c - 1.14
linux/drivers/ide/ide-tape.c - 1.7
linux/drivers/ide/ide-proc.c - 1.5
linux/drivers/ide/ide-pci.c - 1.8
linux/drivers/ide/ide-features.c - 1.7
linux/drivers/ide/ide-disk.c - 1.9
linux/drivers/ide/buddha.c - 1.4
linux/drivers/ide/alim15x3.c - 1.6
linux/drivers/ide/Makefile - 1.6
linux/drivers/ide/Config.in - 1.9
linux/drivers/scsi/sym53c8xx_comm.h - 1.6
linux/net/ipv4/netfilter/ip_nat_standalone.c - 1.8
linux/drivers/net/pcmcia/xircom_tulip_cb.c - 1.7
linux/drivers/isdn/avmb1/capifs.c - 1.5
linux/drivers/usb/mdc800.c - 1.5
linux/arch/i386/kernel/pci-irq.c - 1.6
linux/drivers/usb/serial/whiteheat_fw.h - 1.2
linux/drivers/usb/serial/keyspan_pda.c - 1.7
linux/drivers/usb/serial/ftdi_sio.c - 1.8
linux/drivers/usb/serial/usbserial.c - 1.8
linux/drivers/usb/serial/whiteheat.c - 1.7
linux/drivers/usb/serial/visor.c - 1.7
linux/arch/ia64/kernel/smpboot.c - 1.2
linux/arch/ia64/kernel/minstate.h - 1.3
linux/drivers/usb/serial/omninet.c - 1.6
linux/drivers/usb/serial/digi_acceleport.c - 1.5
linux/drivers/net/pppox.c - 1.4
linux/drivers/net/pppoe.c - 1.6
linux/arch/ppc/8260_io/uart.c - 1.5
linux/drivers/char/rio/rio_linux.c - 1.5
linux/arch/s390/config.in - 1.4
linux/drivers/s390/char/hwc_con.c - 1.2
linux/drivers/s390/char/con3215.c - 1.3
linux/drivers/s390/Config.in - 1.3
linux/include/asm-s390/pgtable.h - 1.4
linux/Documentation/s390/cds.txt - 1.3
linux/arch/s390/kernel/semaphore.c - 1.2
linux/arch/s390/mm/init.c - 1.3
linux/arch/mips64/kernel/smp.c - 1.4
linux/drivers/video/sisfb.c - 1.5
linux/drivers/char/joystick/serio.c - 1.2
linux/Documentation/DocBook/via-audio.tmpl - 1.2
linux/drivers/char/joystick/ns558.c - 1.3
linux/drivers/char/joystick/gameport.c - 1.2
linux/drivers/char/i810_rng.c - 1.3
linux/drivers/usb/storage/usb.h - 1.4
linux/drivers/usb/storage/usb.c - 1.4
linux/drivers/usb/storage/transport.h - 1.4
linux/drivers/usb/storage/transport.c - 1.4
linux/drivers/usb/storage/scsiglue.c - 1.4
linux/drivers/char/sbc60xxwdt.c - 1.3
linux/arch/alpha/kernel/sys_wildfire.c - 1.2
linux/drivers/usb/serial/keyspan.c - 1.3
linux/include/asm-i386/i387.h - 1.2
linux/drivers/usb/bluetooth.c - 1.3
linux/arch/i386/kernel/i387.c - 1.2
linux/arch/ia64/kernel/ia64_ksyms.c - 1.3
linux/drivers/acorn/char/defkeymap-acorn.c - 1.3
linux/arch/ia64/kernel/palinfo.c - 1.3
linux/arch/ia64/kernel/unwind_i.h - 1.2
linux/arch/ia64/lib/io.c - 1.2
linux/fs/nls/nls_big5.c - 1.2
linux/fs/nls/nls_euc-jp.c - 1.2
linux/fs/nls/nls_euc-kr.c - 1.2
linux/fs/nls/nls_gb2312.c - 1.2
linux/fs/nls/nls_sjis.c - 1.2
linux/arch/mips/orion/promcon.c - 1.2
linux/drivers/net/tun.c - 1.3
linux/kernel/user.c - 1.2
linux/Documentation/cachetlb.txt - 1.2
linux/drivers/usb/storage/sddr09.c - 1.2
linux/drivers/usb/storage/freecom.c - 1.3
linux/drivers/net/natsemi.c - 1.2
linux/drivers/media/video/tea6300.c - 1.2
linux/drivers/media/video/tda9875.c - 1.2
linux/drivers/media/video/tda985x.c - 1.2
linux/drivers/media/video/tda8425.c - 1.2
linux/drivers/media/video/tda7432.c - 1.2
linux/drivers/input/input.c - 1.2
linux/drivers/char/serial_21285.c - 1.2
linux/Documentation/kbuild/makefiles.txt - 1.2
linux/arch/i386/kernel/bluesmoke.c - 1.3
linux/drivers/block/cciss.c - 1.2
linux/drivers/char/serial_amba.c - 1.2
linux/drivers/md/md.c - 1.2
linux/drivers/usb/net1080.c - 1.2


From owner-linux-xfs@oss.sgi.com Wed Nov  1 13:44:14 2000
Received:  by oss.sgi.com id <S553694AbQKAVnx>;
	Wed, 1 Nov 2000 13:43:53 -0800
Received: from deliverator.sgi.com ([204.94.214.10]:58988 "EHLO
        deliverator.sgi.com") by oss.sgi.com with ESMTP id <S553683AbQKAVnp>;
	Wed, 1 Nov 2000 13:43:45 -0800
Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id NAA03298
	for <linux-xfs@oss.sgi.com>; Wed, 1 Nov 2000 13:35:55 -0800 (PST)
	mail_from (lord@jen.americas.sgi.com)
Received: from thistle-e185.americas.sgi.com (thistle-e185.americas.sgi.com [128.162.185.204]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id PAA7513477 for <linux-xfs@oss.sgi.com>; Wed, 1 Nov 2000 15:42:28 -0600 (CST)
Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.184.86]) by thistle-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id PAA18881 for <linux-xfs@oss.sgi.com>; Wed, 1 Nov 2000 15:42:28 -0600 (CST)
Received: (from lord@localhost)
	by jen.americas.sgi.com (8.9.3/8.9.3) id PAA01411
	for linux-xfs@oss.sgi.com; Wed, 1 Nov 2000 15:38:49 -0600
Date:   Wed, 1 Nov 2000 15:38:49 -0600
From:   Steve Lord <lord@sgi.com>
Message-Id: <200011012138.PAA01411@jen.americas.sgi.com>
Subject: TAKE - Files removed moerging upto 2.4.0-test10
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


Date:  Wed Nov  1 13:42:00 PST 2000
Workarea:  jen.americas.sgi.com:/src/lord/xfs-linux-test10

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


Modid:  2.4.x-xfs:slinx:77324a
linux/net/protocols.c - 1.5
linux/include/net/x25call.h - 1.3
linux/include/net/spxcall.h - 1.3
linux/include/net/rosecall.h - 1.3
linux/include/net/psnapcall.h - 1.3
linux/include/net/p8022call.h - 1.3
linux/include/net/nrcall.h - 1.3
linux/include/net/netbeuicall.h - 1.3
linux/include/net/llccall.h - 1.3
linux/include/net/lapbcall.h - 1.3
linux/include/net/ipxcall.h - 1.3
linux/include/net/ax25call.h - 1.3
linux/include/net/atalkcall.h - 1.3
linux/drivers/net/skeleton.c - 1.9
linux/include/net/decnet_call.h - 1.2
linux/drivers/usb/usb-core.c - 1.27
linux/arch/ia64/lib/idiv.S - 1.3
linux/arch/alpha/lib/callback_init.c - 1.2


From owner-linux-xfs@oss.sgi.com Wed Nov  1 15:31:54 2000
Received:  by oss.sgi.com id <S553746AbQKAXbe>;
	Wed, 1 Nov 2000 15:31:34 -0800
Received: from mail11.jump.net ([206.196.91.11]:62377 "EHLO mail11.jump.net")
	by oss.sgi.com with ESMTP id <S553733AbQKAXbT>;
	Wed, 1 Nov 2000 15:31:19 -0800
Received: from sgi.com (aus-dsl-dhcp1-26.customer.jump.net [63.163.168.26])
	by mail11.jump.net (8.10.2/) with ESMTP id eA1NVHX03177;
	Wed, 1 Nov 2000 17:31:17 -0600 (CST)
Message-ID: <3A00A7F1.15A6771B@sgi.com>
Date:   Wed, 01 Nov 2000 17:32:01 -0600
From:   Eric Sandeen <sandeen@sgi.com>
X-Mailer: Mozilla 4.7 [en] (X11; I; Linux 2.4.0-test9 i686)
X-Accept-Language: en
MIME-Version: 1.0
To:     Patrick Swartz <pswartz@digitalrom.com>
CC:     linux-xfs@oss.sgi.com
Subject: Re: CVS Download Instructions
References: <OLEAJMNOEMOMMNEIMMINGEGACBAA.pswartz@digitalrom.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

Patrick Swartz wrote:
> My question is now that I have downloaded the latest from the cvs tree what
> do I do now?  The instruction page says "...follow the build process,
> according to the file README.build in the top level directory."  After much
> searching, I can't find any README.build file.

If you're familiar with building your own kernel, then the process is
pretty similar, except that when you configure the kernel, under
Filesystems, you'll want to enable "SGI XFS filesystem support." (You'll
probably not want to enable any of the other incomplete/optional
XFS-related options for now.)  You will also need to enable "Page Buffer
support."  Also, to even see these options, you'll need to enable
"Prompt for development and/or incomplete code" under "Code maturity
level options."

If you're not familiar with building kernels, check out the kernel HOWTO
at http://oss.sgi.com/LDP/HOWTO/Kernel-HOWTO.html for more information.

You'll also need to build the XFS user tools.  Go to the cmd/xfs
directory, and take a look at the INSTALL file.  Basically, you need to
"make configure; make; make install" as root to build and install the
tools.

After the kernel, modules, and tools are compiled & installed, you're
ready to create an XFS filesystem.  Take a look at
http://oss.sgi.com/projects/xfs/beta_filesystem_install.html for
information on doing this.

> I am currently running 2.4.0-test9 on my system with all of the current
> binutils, util-linux, modutils, gcc, etc.  The base system started out as a
> RH7.0 with all of RH bug fixes applied.

RH7.0 changed a few things, and you may run into a couple problems.  For
starters, edit the top level Makefile in the linux/ directory, and
follow the instructions about commenting/uncommenting:

#comment out this line if compiling on RH 7.0
#CC		= $(CROSS_COMPILE)gcc -V egcs-2.91.66
# AND uncomment the following line
CC		= $(CROSS_COMPILE)kgcc 

This will set up the right compiler for the kernel.

You should also look at linux/xfs/xfs_dir2_leaf.h, and change the line
that says:

#define	XFS_DIR2_MAX_DATAPTR	((xfs_dir2_dataptr_t)0xffffffff)

to

#define	XFS_DIR2_MAX_DATAPTR	((xfs_dir2_dataptr_t)0x7fffffff)

to get around a glibc overflow.  (I guess it's time to check this in...)

Let me know if you run into any trouble,

-Eric

From owner-linux-xfs@oss.sgi.com Wed Nov  1 16:53:13 2000
Received:  by oss.sgi.com id <S553756AbQKBAwx>;
	Wed, 1 Nov 2000 16:52:53 -0800
Received: from deliverator.sgi.com ([204.94.214.10]:59694 "EHLO
        deliverator.sgi.com") by oss.sgi.com with ESMTP id <S553743AbQKBAwj>;
	Wed, 1 Nov 2000 16:52:39 -0800
Received: from nodin.corp.sgi.com (nodin.corp.sgi.com [192.26.51.193]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id QAA04163
	for <linux-xfs@oss.sgi.com>; Wed, 1 Nov 2000 16:44:49 -0800 (PST)
	mail_from (eric@eric1.austin.sgi.com)
Received: from eric1.austin.sgi.com (root@eric1.austin.sgi.com [169.238.86.142]) by nodin.corp.sgi.com (980427.SGI.8.8.8/980728.SGI.AUTOCF) via ESMTP id QAA06993 for <linux-xfs@oss.sgi.com>; Wed, 1 Nov 2000 16:52:07 -0800 (PST)
Received: (from eric@localhost)
	by eric1.austin.sgi.com (8.11.0/8.11.0) id eA20lJs24065
	for linux-xfs@oss.sgi.com; Wed, 1 Nov 2000 18:47:19 -0600
Date:   Wed, 1 Nov 2000 18:47:19 -0600
From:   Eric Sandeen <eric@eric1.austin.sgi.com>
Message-Id: <200011020047.eA20lJs24065@eric1.austin.sgi.com>
Subject: TAKE - reduce XFS_DIR2_MAX_DATAPTR
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 leaf directories, xfs_dir2_leaf_getdents() always returns
XFS_DIR2_MAX_DATAPTR (0xffffffff) as the last offset, and this 
overflows the signed 32 bit dp->d_off in newer glibc's with getdents64().

Changing XFS_DIR2_MAX_DATAPTR to 0x7fffffff (unsetting the sign bit)
solves this, if not elegantly.  It also reduces the maximum
directory size from ~4G to ~2G.

There may be a better way to fix this in glibc, rather than in XFS,
but this should suffice for now.

Date:  Mon Oct 30 17:30:52 PST 2000
Workarea:  eric1.austin.sgi.com:/home/eric/xfs/workarea-clean

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


Modid:  2.4.x-xfs:slinx:77184a
linux/fs/xfs/xfs_dir2.c - 1.26
	- Removed unused reclen variable & assignment


Subject: TAKE - 

Date:  Wed Nov  1 16:38:12 PST 2000
Workarea:  eric1.austin.sgi.com:/home/eric/xfs/workarea-clean

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


Modid:  2.4.x-xfs:slinx:77348a
linux/fs/xfs/xfs_dir2_leaf.h - 1.7
	- Change XFS_DIR2_MAX_DATAPTR to avoid glibc overflow in getdents64



From owner-linux-xfs@oss.sgi.com Wed Nov  1 17:45:44 2000
Received:  by oss.sgi.com id <S553781AbQKBBpY>;
	Wed, 1 Nov 2000 17:45:24 -0800
Received: from pneumatic-tube.sgi.com ([204.94.214.22]:53782 "EHLO
        pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP
	id <S553648AbQKBBpA>; Wed, 1 Nov 2000 17:45:00 -0800
Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.55.149]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id RAA05474
	for <linux-xfs@oss.sgi.com>; Wed, 1 Nov 2000 17:48:40 -0800 (PST)
	mail_from (nathans@snort.melbourne.sgi.com)
Received: (from nathans@localhost)
	by snort.melbourne.sgi.com (SGI-8.9.3/8.9.3) id MAA64118
	for linux-xfs@oss.sgi.com; Thu, 2 Nov 2000 12:36:37 +1100 (EST)
Date:   Thu, 2 Nov 2000 12:36:37 +1100 (EST)
From:   Nathan Scott <nathans@snort.melbourne.sgi.com>
Message-Id: <200011020136.MAA64118@snort.melbourne.sgi.com>
To:     linux-xfs@oss.sgi.com
Subject: TAKE - xqm
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.4.x-xfs:slinx:77355a
Date:  Wed Nov  1 17:35:08 PST 2000
Workarea:  snort:/build4/nathans/quota-xfs
Author:  nathans

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

linux/fs/xfs/linux/xfs_globals.c - 1.19
linux/fs/xfs/linux/xfs_globals.h - 1.3
	- remove no longer needed ncsize global.

linux/fs/xfs/linux/xfs_linux.h - 1.34
	- add couple of macros determining sizing of quota data structures.

linux/fs/xfs/linux/xfs_random.c - 1.48
	- add xqm procfs interface.

linux/fs/xfs/xfs_vfsops.c - 1.298
	- remove a TODO, fixed.

linux/fs/xfs/xfs_qm_syscalls.c - 1.45
linux/include/linux/xqm.h - 1.2
	- start thinking about better support for user space quota tools
	  (groups vs irix projects).


From owner-linux-xfs@oss.sgi.com Thu Nov  2 07:36:22 2000
Received:  by oss.sgi.com id <S553817AbQKBPgM>;
	Thu, 2 Nov 2000 07:36:12 -0800
Received: from deliverator.sgi.com ([204.94.214.10]:1648 "EHLO
        deliverator.sgi.com") by oss.sgi.com with ESMTP id <S553812AbQKBPfz>;
	Thu, 2 Nov 2000 07:35:55 -0800
Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id HAA10958
	for <linux-xfs@oss.sgi.com>; Thu, 2 Nov 2000 07:28:06 -0800 (PST)
	mail_from (lord@jen.americas.sgi.com)
Received: from thistle-e185.americas.sgi.com (thistle-e185.americas.sgi.com [128.162.185.204]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id JAA7515541 for <linux-xfs@oss.sgi.com>; Thu, 2 Nov 2000 09:34:39 -0600 (CST)
Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.184.86]) by thistle-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id JAA59353 for <linux-xfs@oss.sgi.com>; Thu, 2 Nov 2000 09:34:39 -0600 (CST)
Received: (from lord@localhost)
	by jen.americas.sgi.com (8.9.3/8.9.3) id JAA11859
	for linux-xfs@oss.sgi.com; Thu, 2 Nov 2000 09:30:52 -0600
Date:   Thu, 2 Nov 2000 09:30:52 -0600
From:   Steve Lord <lord@sgi.com>
Message-Id: <200011021530.JAA11859@jen.americas.sgi.com>
Subject: TAKE - some minor pagebuf cleanup
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

I had some slack time during the storage conference in Miami, this was
one of the results.....

Date:  Thu Nov  2 07:33:56 PST 2000
Workarea:  jen.americas.sgi.com:/src/lord/xfs-linux.2.4

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


Modid:  2.4.x-xfs:slinx:77388a
linux/fs/xfs/xfs_buf.h - 1.63
	- Make xfs_bawrite start the task queue

linux/include/linux/page_buf.h - 1.67
	- Make pagebuf owner tracking a conditional, and encode block size info
	  into pagebuf directly rather than always going to the superblock via
	  the inode. Remove a dead prototype.

linux/kdb/modules/kdbm_pg.c - 1.23
	- Make pagebuf owner tracking a conditional.

linux/fs/pagebuf/page_buf.c - 1.40
	- Make pagebuf owner tracking a conditional, and encode block size info
	  into pagebuf directly rather than always going to the superblock via
	  the inode.

linux/fs/pagebuf/page_buf_locking.c - 1.8
	- Make pagebuf owner tracking a conditional.



From owner-linux-xfs@oss.sgi.com Thu Nov  2 09:00:03 2000
Received:  by oss.sgi.com id <S553823AbQKBQ7x>;
	Thu, 2 Nov 2000 08:59:53 -0800
Received: from deliverator.sgi.com ([204.94.214.10]:4112 "EHLO
        deliverator.sgi.com") by oss.sgi.com with ESMTP id <S553818AbQKBQ7e>;
	Thu, 2 Nov 2000 08:59:34 -0800
Received: from nodin.corp.sgi.com (nodin.corp.sgi.com [192.26.51.193]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id IAA24852
	for <linux-xfs@oss.sgi.com>; Thu, 2 Nov 2000 08:51:45 -0800 (PST)
	mail_from (bjorn@demeern.sgi.com)
Received: from fort.demeern.sgi.com (fort.demeern.sgi.com [144.253.208.2]) by nodin.corp.sgi.com (980427.SGI.8.8.8/980728.SGI.AUTOCF) via ESMTP id IAA53356 for <linux-xfs@oss.sgi.com>; Thu, 2 Nov 2000 08:59:02 -0800 (PST)
Received: from paradijs.demeern.sgi.com (paradijs.demeern.sgi.com [144.253.208.47]) by fort.demeern.sgi.com (980427.SGI.8.8.8/980728.SGI.AUTOCF.hoststrip-1.1) via ESMTP id RAA25168 for <linux-xfs@oss.sgi.com>; Thu, 2 Nov 2000 17:56:23 +0100 (MET)
Date:   Thu, 2 Nov 2000 17:56:20 +0100
From:   Bjorn Kelder <bjorn@demeern.sgi.com>
Reply-To: bjorn@demeern.sgi.com
To:     linux-xfs@oss.sgi.com
Subject: README.build
Message-ID: <Pine.SGI.4.10.10011021751540.132672-100000@paradijs.demeern.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

Hello,

I got the xfs tree with cvs. But as the website says the README.build is
not in the tree. The website I got the information from was
http://oss.sgi.com/projects/xfs/beta.html

Where am I suppose to get the README.build file from? (Or any other file
about what to do next)

Thanks in advance,

Bjorn Kelder

--
Bjorn Kelder
Professional Services
SGI The Netherlands
Email: bkelder@sgi.com
Tel  : +31(0)306696846
Fax  : +31(0)306696899


From owner-linux-xfs@oss.sgi.com Thu Nov  2 09:07:32 2000
Received:  by oss.sgi.com id <S553829AbQKBRHW>;
	Thu, 2 Nov 2000 09:07:22 -0800
Received: from deliverator.sgi.com ([204.94.214.10]:51986 "EHLO
        deliverator.sgi.com") by oss.sgi.com with ESMTP id <S553808AbQKBRHL>;
	Thu, 2 Nov 2000 09:07:11 -0800
Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id IAA26249
	for <linux-xfs@oss.sgi.com>; Thu, 2 Nov 2000 08:59:22 -0800 (PST)
	mail_from (sandeen@sgi.com)
Received: from poppy-e185.americas.sgi.com (poppy.americas.sgi.com [128.162.185.207]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id LAA7515987; Thu, 2 Nov 2000 11:05:55 -0600 (CST)
Received: from sgi.com (eric@eric1.austin.sgi.com [169.238.86.142]) by poppy-e185.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.7) with ESMTP id LAA66086; Thu, 2 Nov 2000 11:05:54 -0600 (CST)
Message-ID: <3A019F24.48425E98@sgi.com>
Date:   Thu, 02 Nov 2000 11:06:44 -0600
From:   Eric Sandeen <sandeen@sgi.com>
X-Mailer: Mozilla 4.75 [en] (X11; U; Linux 2.4.0-XFS-test9 i686)
X-Accept-Language: en
MIME-Version: 1.0
To:     bjorn@demeern.sgi.com
CC:     linux-xfs@oss.sgi.com
Subject: Re: README.build
References: <Pine.SGI.4.10.10011021751540.132672-100000@paradijs.demeern.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

The README.build file doesn't seem to exist...

Please see my post at
http://oss.sgi.com/projects/linux-xfs/indexed/msg02199.html

and the FAQ at http://oss.sgi.com/projects/xfs/faq.html

Those should get you started.

-Eric Sandeen

Bjorn Kelder wrote:
> 
> Hello,
> 
> I got the xfs tree with cvs. But as the website says the README.build is
> not in the tree. The website I got the information from was
> http://oss.sgi.com/projects/xfs/beta.html
> 
> Where am I suppose to get the README.build file from? (Or any other file
> about what to do next)
> 
> Thanks in advance,
> 
> Bjorn Kelder

From owner-linux-xfs@oss.sgi.com Thu Nov  2 14:01:45 2000
Received:  by oss.sgi.com id <S553705AbQKBWBe>;
	Thu, 2 Nov 2000 14:01:34 -0800
Received: from pneumatic-tube.sgi.com ([204.94.214.22]:53342 "EHLO
        pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP
	id <S553652AbQKBWBb>; Thu, 2 Nov 2000 14:01:31 -0800
Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id NAA08684
	for <linux-xfs@oss.sgi.com>; Thu, 2 Nov 2000 13:59:14 -0800 (PST)
	mail_from (cattelan@gibble.americas.sgi.com)
Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id PAA7516085 for <linux-xfs@oss.sgi.com>; Thu, 2 Nov 2000 15:50:25 -0600 (CST)
Received: from gibble.americas.sgi.com (gibble.americas.sgi.com [128.162.195.80]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id PAA85850 for <linux-xfs@oss.sgi.com>; Thu, 2 Nov 2000 15:50:25 -0600 (CST)
Received: (from cattelan@localhost)
	by gibble.americas.sgi.com (8.10.1/8.10.1) id eA2LoOA32001
	for linux-xfs@oss.sgi.com; Thu, 2 Nov 2000 15:50:24 -0600
Date:   Thu, 2 Nov 2000 15:50:24 -0600
From:   Russell Cattelan <cattelan@sgi.com>
Message-Id: <200011022150.eA2LoOA32001@gibble.americas.sgi.com>
Subject: TAKE - Fix XFS module loading.
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

 

Date:  Thu Nov  2 13:49:48 PST 2000
Workarea:  gibble.americas.sgi.com:/export/extra/x2.4-xfs-devel

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


Modid:  2.4.x-xfs:slinx:77433a
linux/fs/xfs/xfs_vfsops.c - 1.299
	- remove definition of ndquot, move to xfs_qm.c.

linux/fs/xfs/xfs_qm.c - 1.57
	- move definition of ndquot from xfs_vfsops.c to here.

linux/fs/xfs/linux/xfs_linux.h - 1.35
	- Remove extern to max_threads... not an exported symbol.



From owner-linux-xfs@oss.sgi.com Thu Nov  2 14:23:24 2000
Received:  by oss.sgi.com id <S553744AbQKBWXP>;
	Thu, 2 Nov 2000 14:23:15 -0800
Received: from deliverator.sgi.com ([204.94.214.10]:28175 "EHLO
        deliverator.sgi.com") by oss.sgi.com with ESMTP id <S553675AbQKBWXD>;
	Thu, 2 Nov 2000 14:23:03 -0800
Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id OAA21677
	for <linux-xfs@oss.sgi.com>; Thu, 2 Nov 2000 14:15:14 -0800 (PST)
	mail_from (lord@jen.americas.sgi.com)
Received: from thistle-e185.americas.sgi.com (thistle-e185.americas.sgi.com [128.162.185.204]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id QAA6751908 for <linux-xfs@oss.sgi.com>; Thu, 2 Nov 2000 16:20:32 -0600 (CST)
Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.184.86]) by thistle-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id QAA03289 for <linux-xfs@oss.sgi.com>; Thu, 2 Nov 2000 16:20:31 -0600 (CST)
Received: (from lord@localhost)
	by jen.americas.sgi.com (8.9.3/8.9.3) id QAA01828
	for linux-xfs@oss.sgi.com; Thu, 2 Nov 2000 16:16:42 -0600
Date:   Thu, 2 Nov 2000 16:16:42 -0600
From:   Steve Lord <lord@sgi.com>
Message-Id: <200011022216.QAA01828@jen.americas.sgi.com>
Subject: TAKE - fix pcmcia in xfs linux tree
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

Some bad code crept in somehere in the merge process, this
takes the code back to vanilla test10 where it should be.

Date:  Thu Nov  2 14:19:46 PST 2000
Workarea:  jen.americas.sgi.com:/src/lord/xfs-linux.2.4

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


Modid:  2.4.x-xfs:slinx:77438a
linux/drivers/pcmcia/cs.c - 1.23
	- Fix merge error which breaks pcmcia



From owner-linux-xfs@oss.sgi.com Thu Nov  2 19:23:26 2000
Received:  by oss.sgi.com id <S553802AbQKCDXQ>;
	Thu, 2 Nov 2000 19:23:16 -0800
Received: from deliverator.sgi.com ([204.94.214.10]:56181 "EHLO
        deliverator.sgi.com") by oss.sgi.com with ESMTP id <S553799AbQKCDW5>;
	Thu, 2 Nov 2000 19:22:57 -0800
Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.55.149]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id TAA12239
	for <linux-xfs@oss.sgi.com>; Thu, 2 Nov 2000 19:15:06 -0800 (PST)
	mail_from (nathans@snort.melbourne.sgi.com)
Received: (from nathans@localhost)
	by snort.melbourne.sgi.com (SGI-8.9.3/8.9.3) id OAA60426
	for linux-xfs@oss.sgi.com; Fri, 3 Nov 2000 14:21:33 +1100 (EST)
Date:   Fri, 3 Nov 2000 14:21:33 +1100 (EST)
From:   Nathan Scott <nathans@snort.melbourne.sgi.com>
Message-Id: <200011030321.OAA60426@snort.melbourne.sgi.com>
To:     linux-xfs@oss.sgi.com
Subject: TAKE - quota
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.4.x-xfs:slinx:77457a
Date:  Thu Nov  2 19:19:17 PST 2000
Workarea:  snort:/build4/nathans/quota-xfs
Author:  nathans

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

cmd/quota/quotaon.c - 1.3
cmd/quota/quotaops.c - 1.4
cmd/quota/xqm.h - 1.2
linux/include/linux/xqm.h - 1.3
	- rework IS_XQM_CMD macro (changed in order to fix module build).

linux/fs/Config.in - 1.44
	- xfs quota now requires vanilla quota support - enforce this.

linux/fs/dquot.c - 1.18
linux/fs/noquot.c - 1.6
linux/fs/xfs/linux/xfs_super.c - 1.98
linux/include/linux/fs.h - 1.68
	- rework the way we get into the xfs quota manager, fixing module build.

linux/fs/xfs/linux/Makefile - 1.28
	- remove xfs_quotactl.o

linux/fs/xfs/linux/xfs_linux.h - 1.36
linux/fs/xfs/xfs_qm.c - 1.58
linux/fs/xfs/xfs_vfsops.c - 1.300
	- rework size heuristics which caused problems with a module build.



From owner-linux-xfs@oss.sgi.com Thu Nov  2 22:12:17 2000
Received:  by oss.sgi.com id <S553810AbQKCGMG>;
	Thu, 2 Nov 2000 22:12:06 -0800
Received: from nic-25-c125-118.mn.mediaone.net ([24.25.125.118]:56839 "EHLO
        lupo.thebarn.com") by oss.sgi.com with ESMTP id <S553804AbQKCGL4>;
	Thu, 2 Nov 2000 22:11:56 -0800
Received: from thebarn.com (localhost [127.0.0.1])
	by lupo.thebarn.com (8.11.0/8.11.0) with ESMTP id eA36B6x90697;
	Fri, 3 Nov 2000 00:11:06 -0600 (CST)
	(envelope-from cattelan@thebarn.com)
Message-ID: <3A0256F9.9B401DDD@thebarn.com>
Date:   Fri, 03 Nov 2000 00:11:06 -0600
From:   Russell Cattelan <cattelan@thebarn.com>
Reply-To: cattelan@thebarn.com
X-Mailer: Mozilla 4.74 [en] (X11; U; Linux 2.2.12 i386)
X-Accept-Language: en
MIME-Version: 1.0
To:     "Steven G. Parker" <sparker@cs.utah.edu>
CC:     linux-xfs@oss.sgi.com
Subject: Re: Corrupt FS
References: <20001027212035.33482B3928E@taz.cs.utah.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

"Steven G. Parker" wrote:

> I somehow managed to corrupt my 18 gig XFS filesystem.  It ran
> fine for several months, but now it is quite trashed.  I filled it up
> with a huge write() call, and then shortly thereafter things started
> failing.  I got I/O error reading ".", and couldn't really do much
> so I rebooted.
>
> The first time I rebooted, it wouldn't mount the partition.  So I
> ran xfs_check on it and got 485k lines of crud.  xfs_repair core
> dumped in phase 3, agno = 0 after several "imap claims a free inode..."
> and "bad version number 0x0..." and "bad magic number 0x0..." messages.
>
> After subsequent reboots, I can now mount the filesystem, but xfs_repair
> still dumps core.  The mounted filesystem has now lost much of it's
> contents, and I get messages like this from ls:
> ls: /home/sparker/News: No such file or directory
>
> So the question is:  How can I turn this catastrophe into something
> useful for the XFS team?  Do you want a copy of the filesystem image?
> Will you be able to do anythign useful with it if I send it? It may take
> me a few days to get it there, so could I give somebody an account on
> this machine to poke at it?  Do you want the output of xfs_check?
>
> Please let me know how I can be useful.

Sorry for not getting back to you sooner...

Ahh lets see, well I really don't don't think sending
and 18gig image across the wire would be a good idea.

The best thing would be if we could access the system directly
and  poke around a bit with xfs_db.

Other things that might be insightful:
any console messages that might have appeared when the FS went bad.
and/or messages in /var/log/messages.

You could send us the output from xfs_check and or xfs_repair.
It's doubtful it will revile anything  useful but it is always worth a
shot.


>
>
> Thanks,
> Steve

--
Russell Cattelan
cattelan@thebarn.com




From owner-linux-xfs@oss.sgi.com Fri Nov  3 04:58:38 2000
Received:  by oss.sgi.com id <S553836AbQKCM62>;
	Fri, 3 Nov 2000 04:58:28 -0800
Received: from oe65.law10.hotmail.com ([64.4.14.200]:42508 "EHLO hotmail.com")
	by oss.sgi.com with ESMTP id <S553761AbQKCM6U>;
	Fri, 3 Nov 2000 04:58:20 -0800
Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC;
	 Fri, 3 Nov 2000 04:58:15 -0800
X-Originating-IP: [61.141.196.249]
From:   "yxy_oversea" <yxy_oversea@hotmail.com>
To:     <linux-xfs@oss.sgi.com>
Cc:     <majordomo@oss.sgi.com>
Subject: fseeko64() suspended(details)
Date:   Fri, 3 Nov 2000 20:57:46 +0800
MIME-Version: 1.0
Content-Type: multipart/alternative;	boundary="----=_NextPart_000_004F_01C045D8.B7EABA40"
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
Message-ID: <OE659T3TGJ2TUSzbAUf00000024@hotmail.com>
X-OriginalArrivalTime: 03 Nov 2000 12:58:15.0282 (UTC) FILETIME=[BACD1520:01C04595]
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_004F_01C045D8.B7EABA40
Content-Type: text/plain;
	charset="gb2312"
Content-Transfer-Encoding: base64

DQpEZWFyIGZyaWVuZHM6DQogVGhhbmtzIGZvciB5b3VyIGFuc3dlcnMuDQogVGhpcyB0aW1lLCBJ
IGluY2x1ZGUgbXkgdGVzdCBzb3VyY2UgY29kZSwgc3RyYWNlIG91dHB1dCBhbmQgeGZzX2JtYXAg
qEN2IHJlc3VsdHMgaGVyZSwgd2lzaCBpdCBoZWxwcyB0byBzb2x2ZSB0aGUgcHJvYmxlbS4NCg0K
PT09PT09PT09PT09PT09PT09PT09PQ0KTXkgc291cmNlIGNvZGUgaXMgYXMgZm9sbG93ZWQ6DQo9
PT09PT09PT09PT09PT09PT09PT09DQoNCiNpbmNsdWRlIDxzdGRsaWIuaD4NCqGtDQojZGVmaW5l
IEJJR19GSUxFICIuL2JpZ29uZSINCg0KaW50IG1haW4oaW50IGFyZ2MsIGNoYXIgKiphcmd2KQ0K
ew0KIEZJTEUgKmZkOw0KIF9fb2ZmNjRfdCBteW9mZjsNCg0KIGlmKCAoZmQ9KEZJTEUgKilmb3Bl
bjY0KCIuL2JpZ29uZSIsICJyYiIpKSA9PSBOVUxMICkgDQogew0KICBwZXJyb3IoICJcbm9wZW4g
Ymlnb25lIGZhaWxcbiIgKTsNCiAgZXhpdCgwKTsNCiB9DQogDQogbXlvZmY9KF9fb2ZmNjRfdCkx
MDAwMDAwKihfX29mZjY0X3QpMjIwMDsgDQogcHJpbnRmKCJcbiBiZWdpbiB0byBzZWVrIFxuIik7
DQogaWYoIGZzZWVrbzY0KGZkLG15b2ZmLCBTRUVLX1NFVCkgIT0wICkNCiB7DQogIHBlcnJvcigi
XG5zZWVrIGZhaWxcbiIpOw0KICBleGl0KDApOw0KIH0NCiBlbHNlDQogew0KICBwcmludGYoIlxu
c2VlayBvayEhXG4iKTsNCiB9IA0KIGZjbG9zZShmZCk7IA0KIHJldHVybiAxOw0KfQ0KLS0tLS0t
IGVuZCBvZiBzb3VyY2UgY29kZSAtLS0tLS0tLQ0KDQoNCj09PT09PT09PT09PT09PT09PT09PT09
PT09PT09PQ0KU3RyYWNlIHJlc3VsdCBpcyBhcyBmb2xsb3dpbmc6DQo9PT09PT09PT09PT09PT09
PT09PT09PT09PT09PT0NCg0KZXhlY3ZlKCIuL2Eub3V0IiwgWyIuL2Eub3V0Il0sIFsvKiAyMCB2
YXJzICovXSkgPSAwDQpicmsoMCkgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgPSAw
eDgwNDk3NTgNCm9sZF9tbWFwKE5VTEwsIDQwOTYsIFBST1RfUkVBRHxQUk9UX1dSSVRFLCBNQVBf
UFJJVkFURXxNQVBfQU5PTllNT1VTLCAtMSwgMCkgPSAweDQwMDE0MDAwDQpvcGVuKCIvZXRjL2xk
LnNvLnByZWxvYWQiLCBPX1JET05MWSkgICAgPSAtMSBFTk9FTlQgKE5vIHN1Y2ggZmlsZSBvciBk
aXJlY3RvcnkpDQpvcGVuKCIvZXRjL2xkLnNvLmNhY2hlIiwgT19SRE9OTFkpICAgICAgPSAzDQpm
c3RhdCgzLCB7c3RfbW9kZT1TX0lGUkVHfDA2NDQsIHN0X3NpemU9MTE2NzEsIC4uLn0pID0gMA0K
b2xkX21tYXAoTlVMTCwgMTE2NzEsIFBST1RfUkVBRCwgTUFQX1BSSVZBVEUsIDMsIDApID0gMHg0
MDAxNTAwMA0KY2xvc2UoMykgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgID0gMA0Kb3Bl
bigiL2xpYi9saWJjLnNvLjYiLCBPX1JET05MWSkgICAgICAgID0gMw0KZnN0YXQoMywge3N0X21v
ZGU9U19JRlJFR3wwNzU1LCBzdF9zaXplPTQxMDEzMjQsIC4uLn0pID0gMA0KcmVhZCgzLCAiXDE3
N0VMRlwxXDFcMVwwXDBcMFwwXDBcMFwwXDBcMFwzXDBcM1wwXDFcMFwwXDBcMjEwXDIxMiIuLi4s
IDQwOTYpID0gNDA5Ng0Kb2xkX21tYXAoTlVMTCwgMTAwMTU2NCwgUFJPVF9SRUFEfFBST1RfRVhF
QywgTUFQX1BSSVZBVEUsIDMsIDApID0gMHg0MDAxODAwMA0KbXByb3RlY3QoMHg0MDEwNTAwMCwg
MzA4MTIsIFBST1RfTk9ORSkgID0gMA0Kb2xkX21tYXAoMHg0MDEwNTAwMCwgMTYzODQsIFBST1Rf
UkVBRHxQUk9UX1dSSVRFLCBNQVBfUFJJVkFURXxNQVBfRklYRUQsIDMsIDB4ZWMwMDApID0gMHg0
MDEwNTAwMA0Kb2xkX21tYXAoMHg0MDEwOTAwMCwgMTQ0MjgsIFBST1RfUkVBRHxQUk9UX1dSSVRF
LCBNQVBfUFJJVkFURXxNQVBfRklYRUR8TUFQX0FOT05ZTU9VUywgLTEsIDApID0gMHg0MDEwOTAw
MA0KY2xvc2UoMykgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgID0gMA0KbXByb3RlY3Qo
MHg0MDAxODAwMCwgOTcwNzUyLCBQUk9UX1JFQUR8UFJPVF9XUklURSkgPSAwDQptcHJvdGVjdCgw
eDQwMDE4MDAwLCA5NzA3NTIsIFBST1RfUkVBRHxQUk9UX0VYRUMpID0gMA0KbXVubWFwKDB4NDAw
MTUwMDAsIDExNjcxKSAgICAgICAgICAgICAgID0gMA0KcGVyc29uYWxpdHkoUEVSX0xJTlVYKSAg
ICAgICAgICAgICAgICAgID0gMA0KZ2V0cGlkKCkgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgID0gMTEzOA0KYnJrKDApICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgID0gMHg4
MDQ5NzU4DQpicmsoMHg4MDQ5ODIwKSAgICAgICAgICAgICAgICAgICAgICAgICAgPSAweDgwNDk4
MjANCmJyaygweDgwNGEwMDApICAgICAgICAgICAgICAgICAgICAgICAgICA9IDB4ODA0YTAwMA0K
b3BlbigiLi9iaWdvbmUiLCBPX1JET05MWXxPX0xBUkdFRklMRSkgID0gMw0KZnN0YXQ2NCgweDEs
IDB4YmZmZmY1ODgpICAgICAgICAgICAgICAgID0gMA0Kb2xkX21tYXAoTlVMTCwgNjU1MzYsIFBS
T1RfUkVBRHxQUk9UX1dSSVRFLCBNQVBfUFJJVkFURXxNQVBfQU5PTllNT1VTLCAtMSwgMCkgPSAw
eDQwMTBkMDAwDQpmc3RhdDY0KDB4MywgMHhiZmZmZmI2YykgICAgICAgICAgICAgICAgPSAwDQpv
bGRfbW1hcChOVUxMLCA2NTUzNiwgUFJPVF9SRUFEfFBST1RfV1JJVEUsIE1BUF9QUklWQVRFfE1B
UF9BTk9OWU1PVVMsIC0xLCAwKSA9IDB4NDAxMWQwMDANCl9sbHNlZWsoMywgMTg0NDY3NDQwNzE2
MTQ1NjIzMDQsIFsyMTk5OTc3OTg0XSwgU0VFS19TRVQpID0gMA0KcmVhZCgzLCAiXDBcMFwwXDBc
MFwwXDBcMFwwXDBcMFwwXDBcMFwwXDBcMFwwXDBcMFwwXDBcMFwwXDBcMFwwIi4uLiwgMjIwMTYp
ID0gMjIwMTYNCmNsb3NlKDMpICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICA9IDANCm11
bm1hcCgweDQwMTFkMDAwLCA2NTUzNikgICAgICAgICAgICAgICA9IDANCndyaXRlKDEsICJcbiBi
ZWdpbiB0byBzZWVrIFxuXG5zZWVrIG9rISFcbiIsIDI4DQogYmVnaW4gdG8gc2VlayANCg0Kc2Vl
ayBvayEhDQopID0gMjgNCm11bm1hcCgweDQwMTBkMDAwLCA2NTUzNikgICAgICAgICAgICAgICA9
IDANCl9leGl0KDEpICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICA9ID8NCg0KLS0tLS0t
IGVuZCBvZiBzdHJhY2UgcmVzdWx0IC0tLS0tLS0tDQoNCj09PT09PT09PT09PT09PT09PT09PQ0K
SW5mb3JtYXRpb24gYWJvdXQgZmlsZSBiaWdvbmUNCj09PT09PT09PT09PT09PT09PT09PQ0KSSBn
ZW5lcmF0ZSChsGJpZ29uZaGxIGJ5IHVzaW5nOg0KZGQgaWY9L2Rldi96ZXJvIG9mPWJpZ29uZSBi
cz0xMDI0ayBjb3VudD00NTAwDQoNCltyb290XSMgeGZzX2JtYXAgLXYgYmlnb25lDQpiaWdvbmU6
DQogRVhUOiBGSUxFLU9GRlNFVCAgICAgICAgIEJMT0NLLVJBTkdFICAgICAgQUcgQUctT0ZGU0VU
ICAgICAgICAgIFRPVEFMDQogICAwOiBbMC4uMTk1OTkzNV06ICAgICAgIDk2Li4xOTYwMDMxICAg
ICAgIDAgKDk2Li4xOTYwMDMxKSAgICAxOTU5OTM2DQogICAxOiBbMTk1OTkzNi4uMzkxNzgyM106
IDE5NzQ5MDQuLjM5MzI3OTEgIDEgKDY0Li4xOTU3OTUxKSAgICAxOTU3ODg4DQogICAyOiBbMzkx
NzgyNC4uNTg1MzE4M106IDM5NDk3NDQuLjU4ODUxMDMgIDIgKDY0Li4xOTM1NDIzKSAgICAxOTM1
MzYwDQogICAzOiBbNTg1MzE4NC4uNzgxMTA3MV06IDU5MjQ1ODQuLjc4ODI0NzEgIDMgKDY0Li4x
OTU3OTUxKSAgICAxOTU3ODg4DQogICA0OiBbNzgxMTA3Mi4uOTIxNTk5OV06IDc5MDkwMjQuLjkz
MTM5NTEgIDQgKDk2NjQuLjE0MTQ1OTEpICAxNDA0OTI4DQoNCg0KICAgVGhhbmsgeW91IHZlcnkg
bXVjaC4NCg0KICAgICAgICAgICAgICAgICAgICB5YW5neHkNCg0K

------=_NextPart_000_004F_01C045D8.B7EABA40
Content-Type: text/html;
	charset="gb2312"
Content-Transfer-Encoding: base64

PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9uYWwv
L0VOIj4NCjxIVE1MPjxIRUFEPg0KPE1FVEEgY29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PWdi
MjMxMiIgaHR0cC1lcXVpdj1Db250ZW50LVR5cGU+DQo8TUVUQSBjb250ZW50PSJNU0hUTUwgNS4w
MC4yOTIwLjAiIG5hbWU9R0VORVJBVE9SPg0KPFNUWUxFPjwvU1RZTEU+DQo8L0hFQUQ+DQo8Qk9E
WSBiZ0NvbG9yPSNmZmZmZmY+DQo8RElWPjxGT05UIHNpemU9Mj48QlI+RGVhciBmcmllbmRzOjxC
Uj4mbmJzcDtUaGFua3MgZm9yIHlvdXIgDQphbnN3ZXJzLjxCUj4mbmJzcDtUaGlzIHRpbWUsIEkg
aW5jbHVkZSBteSB0ZXN0IHNvdXJjZSBjb2RlLCBzdHJhY2Ugb3V0cHV0IGFuZCANCnhmc19ibWFw
IKhDdiByZXN1bHRzIGhlcmUsIHdpc2ggaXQgaGVscHMgdG8gc29sdmUgdGhlIHByb2JsZW0uPC9G
T05UPjwvRElWPg0KPERJVj4mbmJzcDs8L0RJVj4NCjxESVY+PEZPTlQgc2l6ZT0yPj09PT09PT09
PT09PT09PT09PT09PT08QlI+TXkgc291cmNlIGNvZGUgaXMgYXMgDQpmb2xsb3dlZDo8QlI+PT09
PT09PT09PT09PT09PT09PT09PTwvRk9OVD48L0RJVj4NCjxESVY+Jm5ic3A7PC9ESVY+DQo8RElW
PjxGT05UIHNpemU9Mj4jaW5jbHVkZSAmbHQ7c3RkbGliLmgmZ3Q7PEJSPqGtPEJSPiNkZWZpbmUg
QklHX0ZJTEUgDQoiLi9iaWdvbmUiPC9GT05UPjwvRElWPg0KPERJVj4mbmJzcDs8L0RJVj4NCjxE
SVY+PEZPTlQgc2l6ZT0yPmludCBtYWluKGludCBhcmdjLCBjaGFyICoqYXJndik8QlI+ezxCUj4m
bmJzcDtGSUxFIA0KKmZkOzxCUj4mbmJzcDtfX29mZjY0X3QgbXlvZmY7PC9GT05UPjwvRElWPg0K
PERJVj4mbmJzcDs8L0RJVj4NCjxESVY+PEZPTlQgc2l6ZT0yPiZuYnNwO2lmKCAoZmQ9KEZJTEUg
Kilmb3BlbjY0KCIuL2JpZ29uZSIsICJyYiIpKSA9PSBOVUxMIA0KKSZuYnNwOzxCUj4mbmJzcDt7
PEJSPiZuYnNwOyZuYnNwO3BlcnJvciggIlxub3BlbiBiaWdvbmUgZmFpbFxuIiANCik7PEJSPiZu
YnNwOyZuYnNwO2V4aXQoMCk7PEJSPiZuYnNwO308QlI+Jm5ic3A7PEJSPiZuYnNwO215b2ZmPShf
X29mZjY0X3QpMTAwMDAwMCooX19vZmY2NF90KTIyMDA7Jm5ic3A7PEJSPiZuYnNwO3ByaW50Zigi
XG4gDQpiZWdpbiB0byBzZWVrIFxuIik7PEJSPiZuYnNwO2lmKCBmc2Vla282NChmZCxteW9mZiwg
U0VFS19TRVQpICE9MCANCik8QlI+Jm5ic3A7ezxCUj4mbmJzcDsmbmJzcDtwZXJyb3IoIlxuc2Vl
ayANCmZhaWxcbiIpOzxCUj4mbmJzcDsmbmJzcDtleGl0KDApOzxCUj4mbmJzcDt9PEJSPiZuYnNw
O2Vsc2U8QlI+Jm5ic3A7ezxCUj4mbmJzcDsmbmJzcDtwcmludGYoIlxuc2VlayANCm9rISFcbiIp
OzxCUj4mbmJzcDt9Jm5ic3A7PEJSPiZuYnNwO2ZjbG9zZShmZCk7Jm5ic3A7PEJSPiZuYnNwO3Jl
dHVybiANCjE7PEJSPn08QlI+LS0tLS0tIGVuZCBvZiBzb3VyY2UgY29kZSAtLS0tLS0tLTwvRk9O
VD48L0RJVj4NCjxESVY+Jm5ic3A7PC9ESVY+DQo8RElWPjxGT05UIHNpemU9Mj48QlI+PT09PT09
PT09PT09PT09PT09PT09PT09PT09PT09PEJSPlN0cmFjZSByZXN1bHQgaXMgYXMgDQpmb2xsb3dp
bmc6PEJSPj09PT09PT09PT09PT09PT09PT09PT09PT09PT09PTwvRk9OVD48L0RJVj4NCjxESVY+
Jm5ic3A7PC9ESVY+DQo8RElWPjxGT05UIHNpemU9Mj5leGVjdmUoIi4vYS5vdXQiLCBbIi4vYS5v
dXQiXSwgWy8qIDIwIHZhcnMgKi9dKSA9IA0KMDxCUj5icmsoMCkmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsgDQo9IDB4ODA0OTc1ODxCUj5vbGRfbW1hcChOVUxMLCA0MDk2LCBQUk9UX1JFQUR8
UFJPVF9XUklURSwgDQpNQVBfUFJJVkFURXxNQVBfQU5PTllNT1VTLCAtMSwgMCkgPSAweDQwMDE0
MDAwPEJSPm9wZW4oIi9ldGMvbGQuc28ucHJlbG9hZCIsIA0KT19SRE9OTFkpJm5ic3A7Jm5ic3A7
Jm5ic3A7ID0gLTEgRU5PRU5UIChObyBzdWNoIGZpbGUgb3IgDQpkaXJlY3RvcnkpPEJSPm9wZW4o
Ii9ldGMvbGQuc28uY2FjaGUiLCBPX1JET05MWSkmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsgPSANCjM8QlI+ZnN0YXQoMywge3N0X21vZGU9U19JRlJFR3wwNjQ0LCBzdF9zaXplPTExNjcx
LCAuLi59KSA9IDA8QlI+b2xkX21tYXAoTlVMTCwgDQoxMTY3MSwgUFJPVF9SRUFELCBNQVBfUFJJ
VkFURSwgMywgMCkgPSANCjB4NDAwMTUwMDA8QlI+Y2xvc2UoMykmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgDQo9
IDA8QlI+b3BlbigiL2xpYi9saWJjLnNvLjYiLCANCk9fUkRPTkxZKSZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyA9IDM8QlI+ZnN0YXQoMywgDQp7c3RfbW9kZT1TX0lG
UkVHfDA3NTUsIHN0X3NpemU9NDEwMTMyNCwgLi4ufSkgPSAwPEJSPnJlYWQoMywgDQoiXDE3N0VM
RlwxXDFcMVwwXDBcMFwwXDBcMFwwXDBcMFwzXDBcM1wwXDFcMFwwXDBcMjEwXDIxMiIuLi4sIDQw
OTYpID0gDQo0MDk2PEJSPm9sZF9tbWFwKE5VTEwsIDEwMDE1NjQsIFBST1RfUkVBRHxQUk9UX0VY
RUMsIE1BUF9QUklWQVRFLCAzLCAwKSA9IA0KMHg0MDAxODAwMDxCUj5tcHJvdGVjdCgweDQwMTA1
MDAwLCAzMDgxMiwgUFJPVF9OT05FKSZuYnNwOyA9IA0KMDxCUj5vbGRfbW1hcCgweDQwMTA1MDAw
LCAxNjM4NCwgUFJPVF9SRUFEfFBST1RfV1JJVEUsIE1BUF9QUklWQVRFfE1BUF9GSVhFRCwgMywg
DQoweGVjMDAwKSA9IDB4NDAxMDUwMDA8QlI+b2xkX21tYXAoMHg0MDEwOTAwMCwgMTQ0MjgsIFBS
T1RfUkVBRHxQUk9UX1dSSVRFLCANCk1BUF9QUklWQVRFfE1BUF9GSVhFRHxNQVBfQU5PTllNT1VT
LCAtMSwgMCkgPSANCjB4NDAxMDkwMDA8QlI+Y2xvc2UoMykmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgDQo9IDA8
QlI+bXByb3RlY3QoMHg0MDAxODAwMCwgOTcwNzUyLCBQUk9UX1JFQUR8UFJPVF9XUklURSkgPSAN
CjA8QlI+bXByb3RlY3QoMHg0MDAxODAwMCwgOTcwNzUyLCBQUk9UX1JFQUR8UFJPVF9FWEVDKSA9
IDA8QlI+bXVubWFwKDB4NDAwMTUwMDAsIA0KMTE2NzEpJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7IA0KPSANCjA8QlI+cGVyc29uYWxpdHkoUEVSX0xJTlVYKSZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyANCj0gDQowPEJSPmdldHBpZCgpJm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7IA0KPSANCjExMzg8QlI+YnJrKDApJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IA0KPSAN
CjB4ODA0OTc1ODxCUj5icmsoMHg4MDQ5ODIwKSZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyANCj0gDQoweDgwNDk4MjA8QlI+YnJrKDB4ODA0YTAwMCkmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsgDQo9IDB4ODA0YTAwMDxCUj5vcGVuKCIuL2JpZ29uZSIsIE9f
UkRPTkxZfE9fTEFSR0VGSUxFKSZuYnNwOyA9IDM8QlI+ZnN0YXQ2NCgweDEsIA0KMHhiZmZmZjU4
OCkmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgDQo9IDA8QlI+b2xkX21tYXAoTlVM
TCwgNjU1MzYsIFBST1RfUkVBRHxQUk9UX1dSSVRFLCBNQVBfUFJJVkFURXxNQVBfQU5PTllNT1VT
LCANCi0xLCAwKSA9IDB4NDAxMGQwMDA8QlI+ZnN0YXQ2NCgweDMsIA0KMHhiZmZmZmI2YykmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgDQo9IDA8QlI+b2xkX21tYXAoTlVMTCwgNjU1
MzYsIFBST1RfUkVBRHxQUk9UX1dSSVRFLCBNQVBfUFJJVkFURXxNQVBfQU5PTllNT1VTLCANCi0x
LCAwKSA9IDB4NDAxMWQwMDA8QlI+X2xsc2VlaygzLCAxODQ0Njc0NDA3MTYxNDU2MjMwNCwgWzIx
OTk5Nzc5ODRdLCBTRUVLX1NFVCkgDQo9IDA8QlI+cmVhZCgzLCAiXDBcMFwwXDBcMFwwXDBcMFww
XDBcMFwwXDBcMFwwXDBcMFwwXDBcMFwwXDBcMFwwXDBcMFwwIi4uLiwgDQoyMjAxNikgPSANCjIy
MDE2PEJSPmNsb3NlKDMpJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IA0KPSAwPEJSPm11bm1hcCgweDQwMTFkMDAw
LCANCjY1NTM2KSZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyANCj0gMDxCUj53cml0ZSgxLCAi
XG4gYmVnaW4gdG8gc2VlayBcblxuc2VlayBvayEhXG4iLCAyODxCUj4mbmJzcDtiZWdpbiB0byBz
ZWVrIA0KPC9GT05UPjwvRElWPg0KPERJVj4mbmJzcDs8L0RJVj4NCjxESVY+PEZPTlQgc2l6ZT0y
PnNlZWsgb2shITxCUj4pID0gMjg8QlI+bXVubWFwKDB4NDAxMGQwMDAsIA0KNjU1MzYpJm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IA0KPSANCjA8QlI+X2V4aXQoMSkmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsg
DQo9ID88L0ZPTlQ+PC9ESVY+DQo8RElWPiZuYnNwOzwvRElWPg0KPERJVj48Rk9OVCBzaXplPTI+
LS0tLS0tIGVuZCBvZiBzdHJhY2UgcmVzdWx0IC0tLS0tLS0tPC9GT05UPjwvRElWPg0KPERJVj4m
bmJzcDs8L0RJVj4NCjxESVY+PEZPTlQgc2l6ZT0yPj09PT09PT09PT09PT09PT09PT09PTxCUj5J
bmZvcm1hdGlvbiBhYm91dCBmaWxlIA0KYmlnb25lPEJSPj09PT09PT09PT09PT09PT09PT09PTxC
Uj5JIGdlbmVyYXRlIKGwYmlnb25lobEgYnkgdXNpbmc6PEJSPmRkIA0KaWY9L2Rldi96ZXJvIG9m
PWJpZ29uZSBicz0xMDI0ayBjb3VudD00NTAwPC9GT05UPjwvRElWPg0KPERJVj4mbmJzcDs8L0RJ
Vj4NCjxESVY+PEZPTlQgc2l6ZT0yPltyb290XSMgeGZzX2JtYXAgLXYgYmlnb25lPEJSPmJpZ29u
ZTo8QlI+Jm5ic3A7RVhUOiANCkZJTEUtT0ZGU0VUJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IA0KQkxPQ0stUkFOR0UmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsgQUcgDQpBRy1PRkZTRVQmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsgDQpUT1RBTDxCUj4mbmJzcDsmbmJzcDsgMDogWzAuLjE5NTk5
MzVdOiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyANCjk2Li4xOTYwMDMxJm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDAgDQooOTYuLjE5NjAwMzEpJm5ic3A7
Jm5ic3A7Jm5ic3A7IDE5NTk5MzY8QlI+Jm5ic3A7Jm5ic3A7IDE6IFsxOTU5OTM2Li4zOTE3ODIz
XTogDQoxOTc0OTA0Li4zOTMyNzkxJm5ic3A7IDEgKDY0Li4xOTU3OTUxKSZuYnNwOyZuYnNwOyZu
YnNwOyAxOTU3ODg4PEJSPiZuYnNwOyZuYnNwOyANCjI6IFszOTE3ODI0Li41ODUzMTgzXTogMzk0
OTc0NC4uNTg4NTEwMyZuYnNwOyAyICg2NC4uMTkzNTQyMykmbmJzcDsmbmJzcDsmbmJzcDsgDQox
OTM1MzYwPEJSPiZuYnNwOyZuYnNwOyAzOiBbNTg1MzE4NC4uNzgxMTA3MV06IDU5MjQ1ODQuLjc4
ODI0NzEmbmJzcDsgMyANCig2NC4uMTk1Nzk1MSkmbmJzcDsmbmJzcDsmbmJzcDsgMTk1Nzg4ODxC
Uj4mbmJzcDsmbmJzcDsgNDogWzc4MTEwNzIuLjkyMTU5OTldOiANCjc5MDkwMjQuLjkzMTM5NTEm
bmJzcDsgNCAoOTY2NC4uMTQxNDU5MSkmbmJzcDsgMTQwNDkyODwvRk9OVD48L0RJVj4NCjxESVY+
Jm5ic3A7PC9ESVY+DQo8RElWPjxGT05UIHNpemU9Mj48L0ZPTlQ+Jm5ic3A7PC9ESVY+DQo8RElW
PjxGT05UIHNpemU9Mj4mbmJzcDsmbmJzcDsgVGhhbmsgeW91IHZlcnkgbXVjaC48L0ZPTlQ+PC9E
SVY+DQo8RElWPiZuYnNwOzwvRElWPg0KPERJVj48Rk9OVCBzaXplPTI+Jm5ic3A7Jm5ic3A7Jm5i
c3A7ICZuYnNwOyZuYnNwOyZuYnNwOyAmbmJzcDsmbmJzcDsmbmJzcDsgDQombmJzcDsmbmJzcDsm
bmJzcDsgJm5ic3A7Jm5ic3A7Jm5ic3A7IHlhbmd4eTxCUj48L0RJVj48L0ZPTlQ+PC9CT0RZPjwv
SFRNTD4NCg==

------=_NextPart_000_004F_01C045D8.B7EABA40--

From owner-linux-xfs@oss.sgi.com Fri Nov  3 11:58:40 2000
Received:  by oss.sgi.com id <S553876AbQKCT6a>;
	Fri, 3 Nov 2000 11:58:30 -0800
Received: from deliverator.sgi.com ([204.94.214.10]:22132 "EHLO
        deliverator.sgi.com") by oss.sgi.com with ESMTP id <S553871AbQKCT6P>;
	Fri, 3 Nov 2000 11:58:15 -0800
Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id LAA14362
	for <linux-xfs@oss.sgi.com>; Fri, 3 Nov 2000 11:50:25 -0800 (PST)
	mail_from (sandeen@sgi.com)
Received: from poppy-e185.americas.sgi.com (poppy.americas.sgi.com [128.162.185.207]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id NAA7537656; Fri, 3 Nov 2000 13:55:43 -0600 (CST)
Received: from sgi.com (eric@eric1.austin.sgi.com [169.238.86.142]) by poppy-e185.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.7) with ESMTP id NAA98085; Fri, 3 Nov 2000 13:55:42 -0600 (CST)
Message-ID: <3A031895.FB93C8D4@sgi.com>
Date:   Fri, 03 Nov 2000 13:57:09 -0600
From:   Eric Sandeen <sandeen@sgi.com>
X-Mailer: Mozilla 4.75 [en] (X11; U; Linux 2.4.0-XFS-test10 i686)
X-Accept-Language: en
MIME-Version: 1.0
To:     yxy_oversea <yxy_oversea@hotmail.com>
CC:     linux-xfs@oss.sgi.com
Subject: Re: fseeko64() suspended(details)
References: <OE659T3TGJ2TUSzbAUf00000024@hotmail.com>
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

> yxy_oversea wrote:
> 
> Dear friends:
>  Thanks for your answers.
>  This time, I include my test source code, strace output and xfs_bmap
> (Cv results here, wish it helps to solve the problem.

I can reproduce this - I'll take a look.

-Eric

From owner-linux-xfs@oss.sgi.com Fri Nov  3 12:35:01 2000
Received:  by oss.sgi.com id <S553874AbQKCUev>;
	Fri, 3 Nov 2000 12:34:51 -0800
Received: from deliverator.sgi.com ([204.94.214.10]:57605 "EHLO
        deliverator.sgi.com") by oss.sgi.com with ESMTP id <S553870AbQKCUee>;
	Fri, 3 Nov 2000 12:34:34 -0800
Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id MAA20946
	for <linux-xfs@oss.sgi.com>; Fri, 3 Nov 2000 12:26:44 -0800 (PST)
	mail_from (cattelan@gibble.americas.sgi.com)
Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id OAA7507971 for <linux-xfs@oss.sgi.com>; Fri, 3 Nov 2000 14:33:18 -0600 (CST)
Received: from gibble.americas.sgi.com (gibble.americas.sgi.com [128.162.195.80]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id OAA12707 for <linux-xfs@oss.sgi.com>; Fri, 3 Nov 2000 14:33:18 -0600 (CST)
Received: (from cattelan@localhost)
	by gibble.americas.sgi.com (8.10.1/8.10.1) id eA3KXHV11048
	for linux-xfs@oss.sgi.com; Fri, 3 Nov 2000 14:33:17 -0600
Date:   Fri, 3 Nov 2000 14:33:17 -0600
From:   Russell Cattelan <cattelan@sgi.com>
Message-Id: <200011032033.eA3KXHV11048@gibble.americas.sgi.com>
Subject: TAKE - small repair fix.
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

Date:  Fri Nov  3 12:32:50 PST 2000
Workarea:  gibble.americas.sgi.com:/export/extra/x2.4-xfs-devel

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


Modid:  2.4.x-xfs:slinx:77506a
cmd/xfs/repair/dino_chunks.c - 1.42
	- Fix a case where a piece of memory was being double free'd
	  causing repair to dump core.



From owner-linux-xfs@oss.sgi.com Fri Nov  3 17:12:44 2000
Received:  by oss.sgi.com id <S553891AbQKDBMY>;
	Fri, 3 Nov 2000 17:12:24 -0800
Received: from deliverator.sgi.com ([204.94.214.10]:58981 "EHLO
        deliverator.sgi.com") by oss.sgi.com with ESMTP id <S553892AbQKDBMA>;
	Fri, 3 Nov 2000 17:12:00 -0800
Received: from nodin.corp.sgi.com (nodin.corp.sgi.com [192.26.51.193]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id RAA08723; Fri, 3 Nov 2000 17:04:10 -0800 (PST)
	mail_from (nobody@info.engr.sgi.com)
Received: from info.engr.sgi.com (info.engr.sgi.com [192.26.80.216]) by nodin.corp.sgi.com (980427.SGI.8.8.8/980728.SGI.AUTOCF) via ESMTP id RAA30480; Fri, 3 Nov 2000 17:11:29 -0800 (PST)
Received: (from nobody@localhost)
	by info.engr.sgi.com (SGI-8.9.3/8.9.3) id RAA98664;
	Fri, 3 Nov 2000 17:10:13 -0800 (PST)
Date:   Fri, 3 Nov 2000 17:10:13 -0800 (PST)
Message-Id: <200011040110.RAA98664@info.engr.sgi.com>
X-Pv-Incident: 787669 
webPV:  info.engr 
webExec: bugs_update,pvincident 
Reply-To: sgi.bugs.xfs@fido.engr.sgi.com
From:   pv@relay.sgi.com (cvduser@csd.sgi.com)
Subject: UPDATE 787669 - page_buf_locking could not be rmmod'ed
To:     ananth@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 : closed                       Priority : 2                         
 Assigned Engineer : ananth            Submitter : mostek                   
 Opened Date : 04/11/00               *Modified User : cvduser              
*Modified User Domain : csd           *Customer Viewable Description :
WITHHELD: linux bug
*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 (UPDATE)
From: cvduser@csd (BWX)
Date: Nov 03 2000 05:10:12PM
==========================

This is a linux bug. No customer viewable description at this time.
kroy

From owner-linux-xfs@oss.sgi.com Fri Nov  3 18:46:04 2000
Received:  by oss.sgi.com id <S553897AbQKDCpo>;
	Fri, 3 Nov 2000 18:45:44 -0800
Received: from deliverator.sgi.com ([204.94.214.10]:25973 "EHLO
        deliverator.sgi.com") by oss.sgi.com with ESMTP id <S553894AbQKDCpc>;
	Fri, 3 Nov 2000 18:45:32 -0800
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 SAA16728; Fri, 3 Nov 2000 18:37:42 -0800 (PST)
	mail_from (nobody@info.engr.sgi.com)
Received: (from nobody@localhost)
	by info.engr.sgi.com (SGI-8.9.3/8.9.3) id SAA94793;
	Fri, 3 Nov 2000 18:45:31 -0800 (PST)
Date:   Fri, 3 Nov 2000 18:45:31 -0800 (PST)
Message-Id: <200011040245.SAA94793@info.engr.sgi.com>
X-Pv-Incident: 800992 
webPV:  info.engr 
webExec: bugs_update,pvincident 
Reply-To: sgi.bugs.xfs@fido.engr.sgi.com
From:   pv@relay.sgi.com (cvduser@csd.sgi.com)
Subject: UPDATE 800992 - pagebuf_init call to kmem_cache_create BUG()
To:     dxm@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=800992

 Status : closed                       Priority : 2                         
 Assigned Engineer : dxm               Submitter : dxm                      
 Opened Date : 09/05/00               *Modified User : cvduser              
*Modified User Domain : csd           *Customer Viewable Description :
WITHHELD: linux bug
*Description :
On my test box, I'd been playing with xfs, then
umounted, rmmoded and insmoded the modules. When
pagebuf was insmoded, this kernel BUG() was tripped.

I'll see if I can get some more info on this one.

kmem_cache_destroy: Can't free all objects c116d764
kernel BUG at slab.c:806!

Entering kdb (0xc215e000) Panic: invalid operand

.....


==========================
ADDITIONAL INFORMATION (UPDATE)
From: cvduser@csd (BWX)
Date: Nov 03 2000 06:45:31PM
==========================

Linux bug. No customer viewable descriptions at this time.
kroy

From owner-linux-xfs@oss.sgi.com Sat Nov  4 19:41:24 2000
Received:  by oss.sgi.com id <S553937AbQKEDlO>;
	Sat, 4 Nov 2000 19:41:14 -0800
Received: from blount.mail.mindspring.net ([207.69.200.226]:37 "EHLO
        blount.mail.mindspring.net") by oss.sgi.com with ESMTP
	id <S553931AbQKEDkz>; Sat, 4 Nov 2000 19:40:55 -0800
Received: from sprynet.com (pool-63.53.135.141.nwrk.grid.net [63.53.135.141])
	by blount.mail.mindspring.net (8.9.3/8.8.5) with ESMTP id WAA14175
	for <linux-xfs@oss.sgi.com>; Sat, 4 Nov 2000 22:40:51 -0500 (EST)
Message-ID: <3A04FE8F.2AE99DA5@sprynet.com>
Date:   Sat, 04 Nov 2000 22:30:39 -0800
From:   Kallol Biswas <kallol@sprynet.com>
X-Mailer: Mozilla 4.61 [en] (Win95; I)
X-Accept-Language: en
MIME-Version: 1.0
To:     linux-xfs@oss.sgi.com
Subject: xfs file system
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,
    My name is Kallol Biswas, I work with Hewlett Packard as a design
engineer on HP-UX. I am a computer science graduate from Indian
Institute
of Technology, Karagpur(IIT).

A few  professors and students from IIT have become interested to join
xfs open
source development project. They are looking for some work on xfs that
they can start with.
Since they are new to linux kernel, they may need direction and guide
lines.
Any help regarding this will be greatly appreciated.

Regards,
Kallol Biswas

Design Engineer             email: kallol_biswas@hp.com
OS Lab
Hewlett Packard Company
Florham Park
NJ 07932


From owner-linux-xfs@oss.sgi.com Sun Nov  5 15:47:04 2000
Received:  by oss.sgi.com id <S553961AbQKEXqy>;
	Sun, 5 Nov 2000 15:46:54 -0800
Received: from deliverator.sgi.com ([204.94.214.10]:34840 "EHLO
        deliverator.sgi.com") by oss.sgi.com with ESMTP id <S553956AbQKEXqe>;
	Sun, 5 Nov 2000 15:46:34 -0800
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 PAA23800
	for <linux-xfs@oss.sgi.com>; Sun, 5 Nov 2000 15:38:43 -0800 (PST)
	mail_from (nathans@wobbly.melbourne.sgi.com)
Received: from wobbly.melbourne.sgi.com (wobbly.melbourne.sgi.com [134.14.55.135]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id KAA19018; Mon, 6 Nov 2000 10:43:50 +1100
Received: (from nathans@localhost) by wobbly.melbourne.sgi.com (980427.SGI.8.8.8/980728.SGI.AUTOCF) id KAA14250; Mon, 6 Nov 2000 10:43:25 +1100 (EDT)
From:   "Nathan Scott" <nathans@wobbly.melbourne.sgi.com>
Message-Id: <10011061043.ZM111283@wobbly.melbourne.sgi.com>
Date:   Mon, 6 Nov 2000 10:43:22 -0400
In-Reply-To: Kallol Biswas <kallol@sprynet.com>
        "xfs file system" (Nov  4, 10:30pm)
References: <3A04FE8F.2AE99DA5@sprynet.com>
X-Mailer: Z-Mail (3.2.3 08feb96 MediaMail)
To:     Kallol Biswas <kallol@sprynet.com>
Subject: Re: xfs file system
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

hi Kallol,

On Nov 4, 10:30pm, Kallol Biswas wrote:
> Subject: xfs file system
> ...
> A few  professors and students from IIT have become interested to join
> xfs open
> source development project. They are looking for some work on xfs that
> they can start with.

For working on XFS, a good starting point is to setup and
run the XFS qa/stress scripts in an automated or easily
reproducible fashion.  There is a readme in the tree which
describes this process and how to create new stress tests
for everyone to use.  There are a number of people here
who do nightly stress runs (thru cron), then look over the
results in the morning trying to turf out irregularities
and bugs.

This provides a good base for moving forward & making bug
fix and other source changes in XFS.

> Since they are new to linux kernel, they may need direction and guide
> lines.
> Any help regarding this will be greatly appreciated.
> 

Good places to seek knowledge and learn that I have found
useful are a/ the source and b/ mailing lists (linux-fsdevel,
linux-kernel,linux-xfs,...)

Finally, there is a list of work items at
	http://oss.sgi.com/projects/xfs/todos.html

Its quite out of date, unfortunately, but could still be
used as a very rough guide to items which remain to be
done.  The last three items for example, I'm pretty sure
noone is currently looking at.  Some of the other items
listed as unassigned, are actually being pursued by SGI
or external folk already.  The list is also no longer
comprehensive - Steve has another version of this doc
which has a number of additional items which need to be
done, including O_SYNC, making XFS work with more recent
gcc versions, and several other things.

Hope this is helpful.

cheers.

-- 
Nathan

From owner-linux-xfs@oss.sgi.com Sun Nov  5 16:11:05 2000
Received:  by oss.sgi.com id <S553968AbQKFAKz>;
	Sun, 5 Nov 2000 16:10:55 -0800
Received: from deliverator.sgi.com ([204.94.214.10]:23069 "EHLO
        deliverator.sgi.com") by oss.sgi.com with ESMTP id <S553965AbQKFAKt>;
	Sun, 5 Nov 2000 16:10:49 -0800
Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.55.149]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id QAA25923
	for <linux-xfs@oss.sgi.com>; Sun, 5 Nov 2000 16:02:58 -0800 (PST)
	mail_from (nathans@snort.melbourne.sgi.com)
Received: (from nathans@localhost)
	by snort.melbourne.sgi.com (SGI-8.9.3/8.9.3) id LAA57686
	for linux-xfs@oss.sgi.com; Mon, 6 Nov 2000 11:09:25 +1100 (EST)
Date:   Mon, 6 Nov 2000 11:09:25 +1100 (EST)
From:   Nathan Scott <nathans@snort.melbourne.sgi.com>
Message-Id: <200011060009.LAA57686@snort.melbourne.sgi.com>
To:     linux-xfs@oss.sgi.com
Subject: TAKE - Config.in
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.4.x-xfs:slinx:77579a
Date:  Sun Nov  5 16:08:50 PST 2000
Workarea:  snort:/build4/nathans/quota-xfs
Author:  nathans

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

linux/fs/Config.in - 1.45
	- this simplifies and, for some corner cases, corrects "make *config"
	  handling of pagebuf/xfs configuration state.


From owner-linux-xfs@oss.sgi.com Sun Nov  5 19:06:15 2000
Received:  by oss.sgi.com id <S553974AbQKFDGF>;
	Sun, 5 Nov 2000 19:06:05 -0800
Received: from deliverator.sgi.com ([204.94.214.10]:41020 "EHLO
        deliverator.sgi.com") by oss.sgi.com with ESMTP id <S553916AbQKFDFn>;
	Sun, 5 Nov 2000 19:05:43 -0800
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 SAA12051
	for <linux-xfs@oss.sgi.com>; Sun, 5 Nov 2000 18:57:51 -0800 (PST)
	mail_from (kaos@melbourne.sgi.com)
Received: from kao2.melbourne.sgi.com (kao2.melbourne.sgi.com [134.14.55.180]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id OAA20188 for <linux-xfs@oss.sgi.com>; Mon, 6 Nov 2000 14:03:09 +1100
X-Mailer: exmh version 2.1.1 10/15/1999
From:   Keith Owens <kaos@melbourne.sgi.com>
To:     linux-xfs@oss.sgi.com
Subject: KDB and interrupts being unmasked
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date:   Mon, 06 Nov 2000 14:03:09 +1100
Message-ID: <3187.973479789@kao2.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

It has just come to my attention that drivers/video/vgacon.c does an
unconditional cli() and sti() instead of save_flags/restore_flags.
This has the unfortunate side effect of possibly enabling interrupts
when you do console I/O, which kdb does.  AFAICT this should only be a
problem if the screen is blanked when you enter kdb, vga_vesa_unblank
is the only mainline code that does sti(), the rest are in font
handling code.

This bad code might explain why people have seen interrupt routines
being reentered under kdb.  There is a patch by James Simmons
<jsimmons@suse.com> on l-k to fix vgacon.


From owner-linux-xfs@oss.sgi.com Sun Nov  5 19:50:04 2000
Received:  by oss.sgi.com id <S553977AbQKFDtz>;
	Sun, 5 Nov 2000 19:49:55 -0800
Received: from deliverator.sgi.com ([204.94.214.10]:1604 "EHLO
        deliverator.sgi.com") by oss.sgi.com with ESMTP id <S553920AbQKFDth>;
	Sun, 5 Nov 2000 19:49:37 -0800
Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.55.149]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id TAA16029
	for <linux-xfs@oss.sgi.com>; Sun, 5 Nov 2000 19:41:45 -0800 (PST)
	mail_from (dxm@snort.melbourne.sgi.com)
Received: (from dxm@localhost)
	by snort.melbourne.sgi.com (SGI-8.9.3/8.9.3) id OAA78080
	for linux-xfs@oss.sgi.com; Mon, 6 Nov 2000 14:48:12 +1100 (EST)
Date:   Mon, 6 Nov 2000 14:48:12 +1100 (EST)
From:   Daniel Moore <dxm@snort.melbourne.sgi.com>
Message-Id: <200011060348.OAA78080@snort.melbourne.sgi.com>
To:     linux-xfs@oss.sgi.com
Subject: TAKE - xfs_db changes
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.4.x-xfs:slinx:77583a
Date:  Sun Nov  5 19:47:29 PST 2000
Workarea:  snort:/build1/people/dxm/isms/slinx-xfs
Author:  dxm

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

cmd/xfs/db/bit.c - 1.15
	- only endian convert 2/4/8 byte values. fixes setting of sb fname/fpack
	  strings.

cmd/xfs/db/uuid.c - 1.6
	- add a "uuid null" command to zero out the uuid


From owner-linux-xfs@oss.sgi.com Mon Nov  6 07:24:28 2000
Received:  by oss.sgi.com id <S553998AbQKFPYS>;
	Mon, 6 Nov 2000 07:24:18 -0800
Received: from perninha.conectiva.com.br ([200.250.58.156]:10001 "EHLO
        perninha.conectiva.com.br") by oss.sgi.com with ESMTP
	id <S553995AbQKFPYA>; Mon, 6 Nov 2000 07:24:00 -0800
Received: from freak.distro.conectiva (freak.distro.conectiva [10.0.17.22])
	by perninha.conectiva.com.br (8.9.3/8.9.3) with ESMTP id NAA10900;
	Mon, 6 Nov 2000 13:19:46 -0200
Date:   Mon, 6 Nov 2000 11:25:02 -0200 (BRST)
From:   Marcelo Tosatti <marcelo@conectiva.com.br>
X-Sender: marcelo@freak.distro.conectiva
To:     Nathan Scott <nathans@wobbly.melbourne.sgi.com>
cc:     Kallol Biswas <kallol@sprynet.com>, linux-xfs@oss.sgi.com,
        Chaitanya Tumuluri <chait@sgi.com>
Subject: Re: xfs file system
In-Reply-To: <10011061043.ZM111283@wobbly.melbourne.sgi.com>
Message-ID: <Pine.LNX.4.21.0011061026120.27112-100000@freak.distro.conectiva>
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, 6 Nov 2000, Nathan Scott wrote:

<snip>

> Its quite out of date, unfortunately, but could still be
> used as a very rough guide to items which remain to be
> done.  The last three items for example, I'm pretty sure
> noone is currently looking at.  Some of the other items
> listed as unassigned, are actually being pursued by SGI
> or external folk already.  The list is also no longer
> comprehensive - Steve has another version of this doc
> which has a number of additional items which need to be
> done, including O_SYNC, making XFS work with more recent
> gcc versions, and several other things.

Hi, 

One of the things which must done is kiobuf-aware block device drivers, as
listed on the TODO list.

In current XFS CVS tree, nothing except SCSI layer is aware. 

When the majority of the significant block drivers are kiobuf-aware, we
can change significant places in the VM code which currently are
buffer-head based to be kiobuf based.

Looking at latest XFS block layer, function ll_rw_kio:

    /*
     * Only support SCSI disk for now.
     *
     * ENOSYS to indicate caller
     * should try ll_rw_block()
     * for non-SCSI (e.g. IDE) disks.
     */
        if (!SCSI_DISK_MAJOR(MAJOR(dev))) {
        *error = -ENOSYS;
        goto end_io;
    }


I dont see any reason why we can't split the kiobuf request into buffer
heads and send via ll_rw_block here (brw_kiovec() can do that), making
compatibility issues transparent to ll_rw_kio callers.

Comments? 











From owner-linux-xfs@oss.sgi.com Mon Nov  6 09:48:09 2000
Received:  by oss.sgi.com id <S554002AbQKFRr7>;
	Mon, 6 Nov 2000 09:47:59 -0800
Received: from deliverator.sgi.com ([204.94.214.10]:21311 "EHLO
        deliverator.sgi.com") by oss.sgi.com with ESMTP id <S553999AbQKFRrj>;
	Mon, 6 Nov 2000 09:47:39 -0800
Received: from cthulhu.engr.sgi.com (gate3-relay.engr.sgi.com [130.62.1.234]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id JAA11007
	for <linux-xfs@oss.sgi.com>; Mon, 6 Nov 2000 09:39:48 -0800 (PST)
	mail_from (chait@getafix.engr.sgi.com)
Received: from getafix.engr.sgi.com (IDENT:root@getafix.engr.sgi.com [163.154.5.110])
	by cthulhu.engr.sgi.com (SGI-8.9.3/8.9.3) with ESMTP id JAA35702;
	Mon, 6 Nov 2000 09:45:49 -0800 (PST)
Received: from getafix.engr.sgi.com (IDENT:chait@localhost.localdomain [127.0.0.1])
	by getafix.engr.sgi.com (8.9.3/8.9.3) with ESMTP id JAA20862;
	Mon, 6 Nov 2000 09:45:33 -0500
Message-Id: <200011061445.JAA20862@getafix.engr.sgi.com>
To:     Marcelo Tosatti <marcelo@conectiva.com.br>
Cc:     Kallol Biswas <kallol@sprynet.com>, linux-xfs@oss.sgi.com,
        Nathan Scott <nathans@wobbly.melbourne.sgi.com>, axboe@suse.de,
        mkp@linuxcare.com
Subject: Re: xfs file system 
In-reply-to: Your message of "Mon, 06 Nov 2000 11:25:02 -0200."
             <Pine.LNX.4.21.0011061026120.27112-100000@freak.distro.conectiva> 
Date:   Mon, 06 Nov 2000 09:45:33 -0500
From:   Chaitanya Tumuluri <chait@getafix.engr.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, 06 Nov 2000 11:25:02 -0200, Marcelo Tosatti <marcelo@conectiva.com.br> wrote:
>On Mon, 6 Nov 2000, Nathan Scott wrote:
>
><snip>
>
>> Its quite out of date, unfortunately, but could still be
>> used as a very rough guide to items which remain to be
>> done.  The last three items for example, I'm pretty sure
>> noone is currently looking at.  Some of the other items
>> listed as unassigned, are actually being pursued by SGI
>> or external folk already.  The list is also no longer
>> comprehensive - Steve has another version of this doc
>> which has a number of additional items which need to be
>> done, including O_SYNC, making XFS work with more recent
>> gcc versions, and several other things.
>
>Hi, 
>
>One of the things which must done is kiobuf-aware block device drivers, as
>listed on the TODO list.

In principle, agreed. There is work that needs to be done in the DMA-API
layer (calls to bus_to_virt() and virt_to_bus() which need to be redone
for "kiobuf" and "struct page *" awareness), as well.

>In current XFS CVS tree, nothing except SCSI layer is aware. 
>
>When the majority of the significant block drivers are kiobuf-aware, we
>can change significant places in the VM code which currently are
>buffer-head based to be kiobuf based.

Jens Axboe is working on getting the IDE driver aware of kiobufs. Martin
Peterson is looking into the LVM side of things. At one point in time, he
was going to be looking into the `md' driver....perhaps thats one thing
that you folks could pick up.

>Looking at latest XFS block layer, function ll_rw_kio:
>
>    /*
>     * Only support SCSI disk for now.
>     *
>     * ENOSYS to indicate caller
>     * should try ll_rw_block()
>     * for non-SCSI (e.g. IDE) disks.
>     */
>        if (!SCSI_DISK_MAJOR(MAJOR(dev))) {
>        *error = -ENOSYS;
>        goto end_io;
>    }
>
>
>I dont see any reason why we can't split the kiobuf request into buffer
>heads and send via ll_rw_block here (brw_kiovec() can do that), making
>compatibility issues transparent to ll_rw_kio callers.
>
>Comments? 

Again, in principle yes, you are right. However, the only major users of
kiobuf I/O to date (raw I/O and XFS) already have their own compat. 
codepaths. So, its not a burning issue to be addressed...as much as say
someone stepping forward to work on the `md' driver :^)

Cheers,
-Chait.


From owner-linux-xfs@oss.sgi.com Mon Nov  6 11:19:01 2000
Received:  by oss.sgi.com id <S554003AbQKFTSv>;
	Mon, 6 Nov 2000 11:18:51 -0800
Received: from deliverator.sgi.com ([204.94.214.10]:11368 "EHLO
        deliverator.sgi.com") by oss.sgi.com with ESMTP id <S553869AbQKFTSd>;
	Mon, 6 Nov 2000 11:18:33 -0800
Received: from nodin.corp.sgi.com (nodin.corp.sgi.com [192.26.51.193]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id LAA00994; Mon, 6 Nov 2000 11:10:43 -0800 (PST)
	mail_from (nobody@info.engr.sgi.com)
Received: from info.engr.sgi.com (info.engr.sgi.com [192.26.80.216]) by nodin.corp.sgi.com (980427.SGI.8.8.8/980728.SGI.AUTOCF) via ESMTP id LAA83262; Mon, 6 Nov 2000 11:18:03 -0800 (PST)
Received: (from nobody@localhost)
	by info.engr.sgi.com (SGI-8.9.3/8.9.3) id LAA73239;
	Mon, 6 Nov 2000 11:16:45 -0800 (PST)
Date:   Mon, 6 Nov 2000 11:16:45 -0800 (PST)
Message-Id: <200011061916.LAA73239@info.engr.sgi.com>
X-Pv-Incident: 803065 
webPV:  info.engr 
webExec: bugs_update,pvincident 
Reply-To: sgi.bugs.xfs@fido.engr.sgi.com
From:   pv@relay.sgi.com (cvduser@csd.sgi.com)
Subject: UPDATE 803065 - Data corruption while running rwtest
To:     nb@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=803065

 Status : closed                       Priority : 2                         
 Assigned Engineer : nb                Submitter : coreym                   
 Opened Date : 09/27/00               *Modified User : cvduser              
*Modified User Domain : csd           *Customer Viewable Description :
WITHHELD: linux bug
*Description :
I was running rwtest on permit and got a data comparison error.

Here is the output and related information:


[root@permit /mnt]# rwtest
iogen 1000000b:rwtest.file | doio -av

iogen starting up with the following:


.....


==========================
ADDITIONAL INFORMATION (UPDATE)
From: cvduser@csd (BWX)
Date: Nov 06 2000 11:16:45AM
==========================

Linux bug. No customer viewable description at this time.
kroy

From owner-linux-xfs@oss.sgi.com Mon Nov  6 11:55:01 2000
Received:  by oss.sgi.com id <S554019AbQKFTyw>;
	Mon, 6 Nov 2000 11:54:52 -0800
Received: from deliverator.sgi.com ([204.94.214.10]:51831 "EHLO
        deliverator.sgi.com") by oss.sgi.com with ESMTP id <S554016AbQKFTyf>;
	Mon, 6 Nov 2000 11:54:35 -0800
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 LAA08504; Mon, 6 Nov 2000 11:46:45 -0800 (PST)
	mail_from (nobody@info.engr.sgi.com)
Received: (from nobody@localhost)
	by info.engr.sgi.com (SGI-8.9.3/8.9.3) id LAA60245;
	Mon, 6 Nov 2000 11:54:34 -0800 (PST)
Date:   Mon, 6 Nov 2000 11:54:34 -0800 (PST)
Message-Id: <200011061954.LAA60245@info.engr.sgi.com>
X-Pv-Incident: 804398 
webPV:  info.engr 
webExec: bugs_update,pvincident 
Reply-To: sgi.bugs.xfs@fido.engr.sgi.com
From:   pv@relay.sgi.com (cvduser@csd.sgi.com)
Subject: UPDATE 804398 - XFS hits BUG call in pagebuf_read_full_page
To:     cattelan@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=804398

 Status : closed                       Priority : 2                         
 Assigned Engineer : cattelan          Submitter : cattelan                 
 Opened Date : 10/10/00               *Modified User : cvduser              
*Modified User Domain : csd           *Customer Viewable Description :
WITHHELD: linux bug
*Description :
The problem appears to be a page that was orginaly delay alloc
(the underlying disk blocks cam back as zero) but has either
been reused or its state has been cleared.

I don't have all the kbd output... I;ll add to it as
I capture more traces.

[0]kdb> bt
    EBP       EIP         Function(args)
0xc4c13e58 0xc880c914 [pagebuf]pagebuf_read_full_page+0x198 (0xc49eeb60, 0xc11939ac)

.....


==========================
ADDITIONAL INFORMATION (UPDATE)
From: cvduser@csd (BWX)
Date: Nov 06 2000 11:54:33AM
==========================

Linux bug. No customer viewable description at this time.
kroy

From owner-linux-xfs@oss.sgi.com Mon Nov  6 11:57:01 2000
Received:  by oss.sgi.com id <S554021AbQKFT4w>;
	Mon, 6 Nov 2000 11:56:52 -0800
Received: from deliverator.sgi.com ([204.94.214.10]:38520 "EHLO
        deliverator.sgi.com") by oss.sgi.com with ESMTP id <S554018AbQKFT4r>;
	Mon, 6 Nov 2000 11:56:47 -0800
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 LAA08835; Mon, 6 Nov 2000 11:48:57 -0800 (PST)
	mail_from (nobody@info.engr.sgi.com)
Received: (from nobody@localhost)
	by info.engr.sgi.com (SGI-8.9.3/8.9.3) id LAA21995;
	Mon, 6 Nov 2000 11:56:46 -0800 (PST)
Date:   Mon, 6 Nov 2000 11:56:46 -0800 (PST)
Message-Id: <200011061956.LAA21995@info.engr.sgi.com>
X-Pv-Incident: 804570 
webPV:  info.engr 
webExec: bugs_update,pvincident 
Reply-To: sgi.bugs.xfs@fido.engr.sgi.com
From:   pv@relay.sgi.com (cvduser@csd.sgi.com)
Subject: UPDATE 804570 - The elevator bug
To:     nb@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=804570

 Status : open                         Priority : 3                         
 Assigned Engineer : nb                Submitter : coreym                   
 Opened Date : 10/11/00               *Modified User : cvduser              
*Modified User Domain : csd           *Customer Viewable Description :
WITHHELD: linux bug
*Description :
I ran rwtest on a xfs-linux filesystem on the machine permit:

rwtest 100000000:/mnt1/file_1 >/tmp/file_1.out 2>&1 &

This caused df, ls -l, fdisk, and top all to hang.

Permit is running Redhat 6.2 with a 2.4.0-test5 kernel

==========================
ADDITIONAL INFORMATION (ADD)

.....


==========================
ADDITIONAL INFORMATION (UPDATE)
From: cvduser@csd (BWX)
Date: Nov 06 2000 11:56:45AM
==========================

Linux bug. No customer viewable description at this time.
kroy

From owner-linux-xfs@oss.sgi.com Mon Nov  6 12:12:42 2000
Received:  by oss.sgi.com id <S554022AbQKFUMc>;
	Mon, 6 Nov 2000 12:12:32 -0800
Received: from deliverator.sgi.com ([204.94.214.10]:42111 "EHLO
        deliverator.sgi.com") by oss.sgi.com with ESMTP id <S554017AbQKFUM0>;
	Mon, 6 Nov 2000 12:12:26 -0800
Received: from eric1.austin.sgi.com (root@eric1.austin.sgi.com [169.238.86.142]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id MAA12331
	for <linux-xfs@oss.sgi.com>; Mon, 6 Nov 2000 12:04:36 -0800 (PST)
	mail_from (eric@eric1.austin.sgi.com)
Received: (from eric@localhost)
	by eric1.austin.sgi.com (8.11.0/8.11.0) id eA6KC1O02652
	for linux-xfs@oss.sgi.com; Mon, 6 Nov 2000 14:12:01 -0600
Date:   Mon, 6 Nov 2000 14:12:01 -0600
From:   Eric Sandeen <eric@eric1.austin.sgi.com>
Message-Id: <200011062012.eA6KC1O02652@eric1.austin.sgi.com>
Subject: TAKE - pagebuf_fil_read() overflow
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

This fixes the slow seek yxy_oversea @ hotmail.com on the linux-xfs list
was seeing.  rounded_isize was overflowing for large files (large
inode->i_size) , which lead to a wrong read size.

Date:  Mon Nov  6 12:07:43 PST 2000
Workarea:  eric1.austin.sgi.com:/home/eric/xfs/workarea-clean

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


Modid:  2.4.x-xfs:slinx:77659a
linux/fs/pagebuf/page_buf_io.c - 1.34
	- Fix large file overflow in pagebuf_file_read().



From owner-linux-xfs@oss.sgi.com Mon Nov  6 12:16:32 2000
Received:  by oss.sgi.com id <S554024AbQKFUQW>;
	Mon, 6 Nov 2000 12:16:22 -0800
Received: from deliverator.sgi.com ([204.94.214.10]:35333 "EHLO
        deliverator.sgi.com") by oss.sgi.com with ESMTP id <S554020AbQKFUQK>;
	Mon, 6 Nov 2000 12:16:10 -0800
Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id MAA13297
	for <linux-xfs@oss.sgi.com>; Mon, 6 Nov 2000 12:08:19 -0800 (PST)
	mail_from (sandeen@sgi.com)
Received: from poppy-e185.americas.sgi.com (poppy.americas.sgi.com [128.162.185.207]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id OAA7561925; Mon, 6 Nov 2000 14:13:37 -0600 (CST)
Received: from sgi.com (eric@eric1.austin.sgi.com [169.238.86.142]) by poppy-e185.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.7) with ESMTP id OAA62952; Mon, 6 Nov 2000 14:13:36 -0600 (CST)
Message-ID: <3A071150.DDCE1336@sgi.com>
Date:   Mon, 06 Nov 2000 14:15:12 -0600
From:   Eric Sandeen <sandeen@sgi.com>
X-Mailer: Mozilla 4.75 [en] (X11; U; Linux 2.4.0-XFS-test10 i686)
X-Accept-Language: en
MIME-Version: 1.0
To:     yxy_oversea <yxy_oversea@hotmail.com>
CC:     linux-xfs@oss.sgi.com
Subject: Re: fseeko64() suspended FIXED
References: <OE659T3TGJ2TUSzbAUf00000024@hotmail.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

Found the problem:

In page_buf_io.c, on line 710, we have:

rounded_isize = (inode->i_size + rounding - 1) & mask;

However, this overflows for file sizes > 32 bits.  Types are:

inode->i_size:  loff_t (__kernel_off_t, long long)
rounded_isize:  size_t (u int)
rounding:       u_int
mask:           u_int

This overflow eventually caused the size of the read to be very wrong.

This should fix it (it has been checked in):

================

--- linux/fs/pagebuf/page_buf_io.c.orig  Mon Nov  6 11:28:31 2000
+++ linux/fs/pagebuf/page_buf_io.c       Mon Nov  6 11:37:59 2000
@@ -692,11 +692,11 @@
        int maps_returned, map_entry;
        unsigned long chunksize, map_size, size, readahead;
        int     direct = filp->f_flags & O_DIRECT;
-       unsigned int    rounding, mask;
-       size_t rounded_isize;
-
+       unsigned long   rounding;
+       loff_t          mask, rounded_isize;
+        
        rounding = direct ? inode->i_sb->s_blocksize : PAGE_CACHE_SIZE;
-       mask = ~(rounding - 1);
+       mask = ~(loff_t)(rounding - 1);
 
        /*
         * while we have data to do, get a bunch of mapping for this

================

I also changed "rounding" to unsigned long because it's possibly
assigned from inode->i_sb->s_blocksize, which is an unsigned long.

-Eric

From owner-linux-xfs@oss.sgi.com Tue Nov  7 08:03:31 2000
Received:  by oss.sgi.com id <S553678AbQKGQDU>;
	Tue, 7 Nov 2000 08:03:20 -0800
Received: from hermes.mixx.net ([212.84.196.2]:24339 "HELO hermes.mixx.net")
	by oss.sgi.com with SMTP id <S553671AbQKGQC7>;
	Tue, 7 Nov 2000 08:02:59 -0800
Received: from mate.bln.innominate.de (cerberus.berlin.innominate.de [212.84.234.251])
	by hermes.mixx.net (Postfix) with ESMTP id DF624F893
	for <linux-xfs@oss.sgi.com>; Tue,  7 Nov 2000 17:02:40 +0100 (CET)
Received: by mate.bln.innominate.de (Postfix, from userid 9)
	id 8943D2CA6F; Tue,  7 Nov 2000 17:02:10 +0100 (CET)
From:   Thomas Graichen <news-innominate.list.sgi.xfs@innominate.de>
Reply-To: Thomas Graichen <graichen@innominate.de>
X-Newsgroups: innominate.list.sgi.xfs
Subject: XFS on ppc status
Date:   7 Nov 2000 16:02:10 GMT
Organization: innominate AG, Berlin, Germany
Lines:  34
Distribution: local
Message-ID: <news2mail-8u9922$jid$1@mate.bln.innominate.de>
Reply-To: thomas.graichen@innominate.de
X-Trace: mate.bln.innominate.de 973612930 20045 10.0.0.69 (7 Nov 2000 16:02:10 GMT)
X-Complaints-To: news@innominate.de
User-Agent: tin/1.4.2-20000205 ("Possession") (UNIX) (Linux/2.4.0-XFS-test10 (i586))
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

just as a short note: back in berlin at the weekend i found some time
to have a look at XFS on the ppc again and here is the result:

* the current cvs tree no longer needs any significant changes to build
* there were only two small things: CLOCKS_PER_SEC is not defined in
  asm/param.h for the ppc - this one is not related to XFS at all
  looks more like a test10 problem (occures only while compiling
  fs/binfmt_elf.c) and is easily fixed by defining it there
* cmd/xfs/dump/dump/content.c cries about O_DIRECT not being defined
  but as far as i can see it is defined the same way as on i386 in
  the includes (asm/fcntl.h) - but maybe an indirect include
  does not get this one (anyone having an idea?) - just
  commenting out the affected 3 lines gets it going
  so far (they are only relevant for realtime
  volumes which are as far as i remember not
  supported at all so far anyway)

the resulting system run just fine so far - tested it with the rootfs
XFS and ran two dbench (one 4 and one 8) parallel for some hours and
half of a day an dbench 4 parallel to an endless kernel clean build
- both times no problem so far ... will try to start some of the
stress testing in the next days (have to get more disk space
first) ... so far the satus ... my plans are to setup an
alpha and a ppc here at work now for doing more and
better stress testing - hope to get this done
within the next two weeks

t

-- 
thomas.graichen@innominate.com
technical director                                       innominate AG
clustering & security                             the linux architects
tel: +49-30-308806-13   fax: -77             http://www.innominate.com

From owner-linux-xfs@oss.sgi.com Tue Nov  7 08:35:20 2000
Received:  by oss.sgi.com id <S553695AbQKGQfA>;
	Tue, 7 Nov 2000 08:35:00 -0800
Received: from ifi.informatik.uni-stuttgart.de ([129.69.211.1]:65167 "EHLO
        ifi.informatik.uni-stuttgart.de") by oss.sgi.com with ESMTP
	id <S553686AbQKGQef>; Tue, 7 Nov 2000 08:34:35 -0800
Received: from techno.informatik.uni-stuttgart.de (techno [129.69.218.24]) by ifi.informatik.uni-stuttgart.de (8.9.3/2.2) with ESMTP id RAA06272 for <linux-xfs@oss.sgi.com>; Tue, 7 Nov 2000 17:32:49 +0100 (MET)
Received: (from magallon@localhost) by techno.informatik.uni-stuttgart.de (8.9.3/2.2) id RAA17186 for linux-xfs@oss.sgi.com; Tue, 7 Nov 2000 17:34:32 +0100
Date:   Tue, 7 Nov 2000 17:34:32 +0100
From:   "Marcelo E. Magallon" <marcelo.magallon@bigfoot.com>
To:     linux-xfs@oss.sgi.com
Subject: Re: stress test failures
Message-ID: <20001107173432.A16761@techno.informatik.uni-stuttgart.de>
References: <20001031204910.B26772@techno.informatik.uni-stuttgart.de>
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="17pEHd4RhPHOinZp"
Content-Disposition: inline
User-Agent: Mutt/1.1.14i
In-Reply-To: <20001031204910.B26772@techno.informatik.uni-stuttgart.de>; from marcelo.magallon@bigfoot.com on Tue, Oct 31, 2000 at 08:49:10PM +0100
X-Operating-System: Linux techno 2.2.18pre17
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing


--17pEHd4RhPHOinZp
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline

>> "Marcelo E. Magallon" <marcelo.magallon@bigfoot.com> writes:

 >  I've been running the stress tests on a daily basis for a while now and
 >  most failures have dissapered lately. [...]

 The reported failure involving mmap is no longer reproducible.

 From last night's run I have:

 Not run: 022 023 024 025 035 036 037 038 039 040 043 044
 Failures: 020 026 028 046 047
 Failed 5 of 35 tests
 
 020 is a non-bug (/tmp is xfs)

 026 is differences in the output (026.out should be updated)

026 - output mismatch (see 026.out.bad)
30,31c30
< xfsrestore: using online session inventory
< xfsrestore: searching media for directory dump
---
> xfsrestore: searching media for dump
32a32,43
> xfsrestore: found dump matching specified label:
> xfsrestore: hostname: HOSTNAME
> xfsrestore: mount point: SCRATCH_MNT
> xfsrestore: volume: SCRATCH_DEV
> xfsrestore: session time: TIME
> xfsrestore: level: 0
> xfsrestore: session label: "stress_026"
> xfsrestore: media label: "stress_tape_media"
> xfsrestore: file system id: ID
> xfsrestore: session id: ID
> xfsrestore: media id: ID
> xfsrestore: searching media for directory dump

 028 is two large chunks of output not present.

 046 is a difference in the output, just as 046 (046.out needs to be
 updated)

 047 is similar to 028. (047.out.bad.gz attached)

 Thanks,

--
Marcelo

--17pEHd4RhPHOinZp
Content-Type: application/x-gunzip
Content-Disposition: attachment; filename="047.out.bad.gz"
Content-Transfer-Encoding: base64

H4sICBIsCDoCAzA0Ny5vdXQuYmFkAO1YTW/bMAy991cQPTXA8p2hgG9BkqIB6rRrknOgWMyi
1ZYESzaa/fpJsl15q9PTsCGofTBg8pF8/HgXf5uCyLTMNEQpEo0U9icYTG6v5lkiGf8OWsCB
xdjr9a5eD4oaK0D3APNt+LS7Wz4soBuC0ikqtdNE4i5Bygh0H0AZExO8N4D17Hm6md3vwtWm
yhFAjql1w9gAuvCccW6rKfOKsauPhgxF6uEx5hjDABwBcYD7x/VmNQ0XQWNyh6KmnQDm083C
O0pSwGgAy/l7e0z2GAdw/Ub+2mMYF5AQCfJIFMLQBL0w6WZ0Yzwq25spoAIlMWIHhrRzLnQU
QCS4GVoWaRvOONOMxAXrmCl9LnD8R02ZZm5qHCPDl6SnsyUn9UjFfiKg0ixxC2e84nU2/Gs9
XPD4BIJjwdfuniQNkb5FM9dIJDJGjR7m6xdpDKcAVtvQ3J9G5XH9nKT98qvPeI5ci/RUXavH
OYPlV6Qr91lcoz1gczs3xdfgS2no/H4wxSoc+fcOylKMTGVW51Y5ueDdCnByyWsg5NRiPBPv
qrFzO2lo/204duGuSpG/A4HpqAlcjTqA9WK2NpMwi6AKMCZSmYH9NV0PL1nXw1bX/1nXrV7/
sV5Hl6zXUavXVq+fS6/jS9bruNVrq9fPpdfJJet10uq11etF6PUpFfYILCVXuPn/QH+7Xc6V
JvsrALgTGaemD22bE2mzpsA90mdnnOJrUaN0flSrt+T50kZUWIDZEaMXm4lENqct7Z0f5lrr
x/2PGjY0DWiQgpm3uaXoWPhSTETuBmE7LRtsbO4XUIniJ+YTAAA=

--17pEHd4RhPHOinZp--

From owner-linux-xfs@oss.sgi.com Tue Nov  7 15:08:12 2000
Received:  by oss.sgi.com id <S553780AbQKGXHw>;
	Tue, 7 Nov 2000 15:07:52 -0800
Received: from deliverator.sgi.com ([204.94.214.10]:55560 "EHLO
        deliverator.sgi.com") by oss.sgi.com with ESMTP id <S553771AbQKGXHo>;
	Tue, 7 Nov 2000 15:07:44 -0800
Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id OAA10900
	for <linux-xfs@oss.sgi.com>; Tue, 7 Nov 2000 14:59:53 -0800 (PST)
	mail_from (lord@jen.americas.sgi.com)
Received: from thistle-e185.americas.sgi.com (thistle-e185.americas.sgi.com [128.162.185.204]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id RAA7585201; Tue, 7 Nov 2000 17:05:10 -0600 (CST)
Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.184.86]) by thistle-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id RAA02780; Tue, 7 Nov 2000 17:05:09 -0600 (CST)
Received: from jen.americas.sgi.com (lord@localhost)
	by jen.americas.sgi.com (8.9.3/8.9.3) with ESMTP id RAA32007;
	Tue, 7 Nov 2000 17:00:30 -0600
Message-Id: <200011072300.RAA32007@jen.americas.sgi.com>
X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4
To:     Thomas Graichen <graichen@innominate.de>,
        thomas.graichen@innominate.de
cc:     linux-xfs@oss.sgi.com
Subject: Re: XFS on ppc status 
In-Reply-To: Message from Thomas Graichen <news-innominate.list.sgi.xfs@innominate.de> 
   of "07 Nov 2000 16:02:10 GMT." <news2mail-8u9922$jid$1@mate.bln.innominate.de> 
Date:   Tue, 07 Nov 2000 17:00:30 -0600
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



Cool, thanks for the update.

Steve

> just as a short note: back in berlin at the weekend i found some time
> to have a look at XFS on the ppc again and here is the result:
> 
> * the current cvs tree no longer needs any significant changes to build
> * there were only two small things: CLOCKS_PER_SEC is not defined in
>   asm/param.h for the ppc - this one is not related to XFS at all
>   looks more like a test10 problem (occures only while compiling
>   fs/binfmt_elf.c) and is easily fixed by defining it there
> * cmd/xfs/dump/dump/content.c cries about O_DIRECT not being defined
>   but as far as i can see it is defined the same way as on i386 in
>   the includes (asm/fcntl.h) - but maybe an indirect include
>   does not get this one (anyone having an idea?) - just
>   commenting out the affected 3 lines gets it going
>   so far (they are only relevant for realtime
>   volumes which are as far as i remember not
>   supported at all so far anyway)
> 
> the resulting system run just fine so far - tested it with the rootfs
> XFS and ran two dbench (one 4 and one 8) parallel for some hours and
> half of a day an dbench 4 parallel to an endless kernel clean build
> - both times no problem so far ... will try to start some of the
> stress testing in the next days (have to get more disk space
> first) ... so far the satus ... my plans are to setup an
> alpha and a ppc here at work now for doing more and
> better stress testing - hope to get this done
> within the next two weeks
> 
> t
> 
> -- 
> thomas.graichen@innominate.com
> technical director                                       innominate AG
> clustering & security                             the linux architects
> tel: +49-30-308806-13   fax: -77             http://www.innominate.com



From owner-linux-xfs@oss.sgi.com Tue Nov  7 16:04:33 2000
Received:  by oss.sgi.com id <S553819AbQKHAEN>;
	Tue, 7 Nov 2000 16:04:13 -0800
Received: from deliverator.sgi.com ([204.94.214.10]:4893 "EHLO
        deliverator.sgi.com") by oss.sgi.com with ESMTP id <S553774AbQKHAD5>;
	Tue, 7 Nov 2000 16:03:57 -0800
Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.55.149]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id PAA21346
	for <linux-xfs@oss.sgi.com>; Tue, 7 Nov 2000 15:56:06 -0800 (PST)
	mail_from (dxm@snort.melbourne.sgi.com)
Received: (from dxm@localhost)
	by snort.melbourne.sgi.com (SGI-8.9.3/8.9.3) id LAA57059
	for linux-xfs@oss.sgi.com; Wed, 8 Nov 2000 11:02:32 +1100 (EST)
Date:   Wed, 8 Nov 2000 11:02:32 +1100 (EST)
From:   Daniel Moore <dxm@snort.melbourne.sgi.com>
Message-Id: <200011080002.LAA57059@snort.melbourne.sgi.com>
To:     linux-xfs@oss.sgi.com
Subject: TAKE - xfs qa 020
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing

fix 020 for XFS /tmp (for marcelo)

Modid:  2.4.x-xfs:slinx:77779a
Date:  Tue Nov  7 16:01:31 PST 2000
Workarea:  snort:/build1/people/dxm/isms/slinx-xfs
Author:  dxm

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

cmd/xfs/stress/020 - 1.5
	- can't assume /tmp is non-xfs. use /proc instead

cmd/xfs/stress/020.out - 1.3
	- can't assume /tmp is non-xfs. use /proc instead       


From owner-linux-xfs@oss.sgi.com Tue Nov  7 18:46:05 2000
Received:  by oss.sgi.com id <S553918AbQKHCpz>;
	Tue, 7 Nov 2000 18:45:55 -0800
Received: from deliverator.sgi.com ([204.94.214.10]:22602 "EHLO
        deliverator.sgi.com") by oss.sgi.com with ESMTP id <S553822AbQKHCpd>;
	Tue, 7 Nov 2000 18:45:33 -0800
Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.55.149]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id SAA12856
	for <linux-xfs@oss.sgi.com>; Tue, 7 Nov 2000 18:37:41 -0800 (PST)
	mail_from (nathans@snort.melbourne.sgi.com)
Received: (from nathans@localhost)
	by snort.melbourne.sgi.com (SGI-8.9.3/8.9.3) id NAA05190
	for linux-xfs@oss.sgi.com; Wed, 8 Nov 2000 13:43:50 +1100 (EST)
Date:   Wed, 8 Nov 2000 13:43:50 +1100 (EST)
From:   Nathan Scott <nathans@snort.melbourne.sgi.com>
Message-Id: <200011080243.NAA05190@snort.melbourne.sgi.com>
To:     linux-xfs@oss.sgi.com
Subject: TAKE - xfs_admin
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 only really going to be useful with a new mount binary,
which will then allow xfs filesystems to be mounted by-uuid or
by-label rather than by block special device (mount -U/-L).

I'm reliably informed [by Andreas :-)] that this will be in the
2.10q util-linux package.  If anyone wants the 2.10p+xfs patch,
just let me know & I'll post it here.

cheers.


Modid:  2.4.x-xfs:slinx:77786a
Date:  Tue Nov  7 18:00:10 PST 2000
Workarea:  snort:/build4/nathans/linux-xfs
Author:  nathans

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

cmd/quota/bylabel.c - 1.2
	- sync code with that from util-linux patch.

cmd/xfs/db/Makefile - 1.53
	- add xfs_admin shell script.

cmd/xfs/db/uuid.c - 1.7
	- minor uuid tidying, extract some common code & provide a label get/set
	  mechanism which shares it.

cmd/xfs/db/sb.c - 1.32
cmd/xfs/include/xfs_sb.h - 1.3
cmd/xfs/libxfs/xfs_mount.c - 1.3
cmd/xfs/repair/sb.c - 1.37
linux/fs/xfs/xfs_mount.c - 1.244
linux/fs/xfs/xfs_sb.h - 1.49
	- merge fpack and fname into one.

cmd/xfs/db/xfs_admin.sh - 1.1
cmd/xfs/man/man8/xfs_admin.8 - 1.1
	- xfs_db wrapper for getting and setting fs uuid and label.  useful for
	  versions of mount(8) which allow xfs to be mounted by uuid/label.


From owner-linux-xfs@oss.sgi.com Tue Nov  7 19:08:14 2000
Received:  by oss.sgi.com id <S553793AbQKHDIF>;
	Tue, 7 Nov 2000 19:08:05 -0800
Received: from deliverator.sgi.com ([204.94.214.10]:64847 "EHLO
        deliverator.sgi.com") by oss.sgi.com with ESMTP id <S553709AbQKHDHl>;
	Tue, 7 Nov 2000 19:07:41 -0800
Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.55.149]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id SAA15628
	for <linux-xfs@oss.sgi.com>; Tue, 7 Nov 2000 18:59:48 -0800 (PST)
	mail_from (ajag@snort.melbourne.sgi.com)
Received: (from ajag@localhost)
	by snort.melbourne.sgi.com (SGI-8.9.3/8.9.3) id OAA10692
	for linux-xfs@oss.sgi.com; Wed, 8 Nov 2000 14:04:57 +1100 (EST)
Date:   Wed, 8 Nov 2000 14:04:57 +1100 (EST)
From:   Andrew Gildfind <ajag@snort.melbourne.sgi.com>
Message-Id: <200011080304.OAA10692@snort.melbourne.sgi.com>
To:     linux-xfs@oss.sgi.com
Subject: TAKE - xfs_growfs QA fixes
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.4.x-xfs:slinx:77797a
Date:  Tue Nov  7 19:03:48 PST 2000
Workarea:  snort:/build2/ajag/isms/slinx
Author:  ajag

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

cmd/xfs/stress/041 - 1.3
	- Changed test sequence to start with a 32 MB filesystem and grow 
	  from there avoids spurious error messages caused by the default
          layout of smaller filesystems.

linux/fs/xfs/xfs_fsops.c - 1.61
	- Fix broken ASSERT that was causing one class of growfs operation 
	  to die. This (finally) allows the growfs qa test (041) to pass 
	  on debug kernels.

cmd/xfs/stress/041.out - 1.1
	- Verified output for 041 qa test.


From owner-linux-xfs@oss.sgi.com Tue Nov  7 21:39:37 2000
Received:  by oss.sgi.com id <S553950AbQKHFj0>;
	Tue, 7 Nov 2000 21:39:26 -0800
Received: from deliverator.sgi.com ([204.94.214.10]:48494 "EHLO
        deliverator.sgi.com") by oss.sgi.com with ESMTP id <S553806AbQKHFjL>;
	Tue, 7 Nov 2000 21:39:11 -0800
Received: from sherman.melbourne.sgi.com (sherman.melbourne.sgi.com [134.14.55.175]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id VAA01354
	for <linux-xfs@oss.sgi.com>; Tue, 7 Nov 2000 21:31:19 -0800 (PST)
	mail_from (tes@sherman.melbourne.sgi.com)
Received: (from tes@localhost)
	by sherman.melbourne.sgi.com (8.9.3/8.9.3) id QAA20817
	for linux-xfs@oss.sgi.com; Wed, 8 Nov 2000 16:38:06 +1100
Date:   Wed, 8 Nov 2000 16:38:06 +1100
From:   Tim Shimmin <tes@sherman.melbourne.sgi.com>
Message-Id: <200011080538.QAA20817@sherman.melbourne.sgi.com>
Subject: TAKE - xfsdump
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

Thomas,
this should fix the problem about the O_DIRECT reference
in dump/content.c .
There was some remaining real-time stuff that wasn't #ifdef'ed out.

Thanks,
Tim.

Modid:  2.4.x-xfs:slinx:76882a
Date:  Wed Oct 25 19:09:31 PDT 2000
Workarea:  snort:/build4/tes/slinx-xfs
Author:  tes


Date:  Tue Nov  7 21:33:49 PST 2000
Workarea:  sherman.melbourne.sgi.com:/hosts/snort/build4/tes/slinx-xfs

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


Modid:  2.4.x-xfs:slinx:77807a
cmd/xfs/dump/dump/content.c - 1.24
	- Mask out some remaining real-time stuff.




An old QA fix:

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

cmd/xfs/stress/common.dump - 1.20
	- Ensure that stderr from xfsdump/xfsrestore goes thru the
	  dump filter - need to filter out /dev/tty warning
	  for auto-qa run by cron.
	  Make the rewind op wait for the tape to be ready and then
	  wait for the rewind to finish by checking status.

From owner-linux-xfs@oss.sgi.com Tue Nov  7 22:45:07 2000
Received:  by oss.sgi.com id <S553957AbQKHGo5>;
	Tue, 7 Nov 2000 22:44:57 -0800
Received: from deliverator.sgi.com ([204.94.214.10]:40059 "EHLO
        deliverator.sgi.com") by oss.sgi.com with ESMTP id <S553929AbQKHGom>;
	Tue, 7 Nov 2000 22:44:42 -0800
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 WAA07745
	for <linux-xfs@oss.sgi.com>; Tue, 7 Nov 2000 22:36:50 -0800 (PST)
	mail_from (tes@boing.melbourne.sgi.com)
Received: from boing.melbourne.sgi.com (boing.melbourne.sgi.com [134.14.55.141]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id RAA07980; Wed, 8 Nov 2000 17:43:23 +1100
Received: (from tes@localhost) by boing.melbourne.sgi.com (980427.SGI.8.8.8/980728.SGI.AUTOCF) id RAA75122; Wed, 8 Nov 2000 17:43:20 +1100 (EDT)
From:   tes@boing.melbourne.sgi.com (Timothy Shimmin)
Message-Id: <200011080643.RAA75122@boing.melbourne.sgi.com>
Subject: Re: stress test failures
To:     marcelo.magallon@bigfoot.com (Marcelo E. Magallon)
Date:   Wed, 8 Nov 2000 17:43:19 +1100 (EDT)
Cc:     linux-xfs@oss.sgi.com
In-Reply-To: <20001107173432.A16761@techno.informatik.uni-stuttgart.de> from "Marcelo E. Magallon" at Nov 07, 2000 05:34:32 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 Marcelo,

Your xfsdump/xfsrestore failures of: 026, 028, 046, 047
are all consistent with not being able to read the
dump inventory.

028/047 which test out xfsinvutil do an "xfsdump -I"
before and after calling xfsinvutil to verify that the pruning
happens, and it (xfsdump -I) produces nothing for you !
In 026 (and presumably 046), it does not output the msg
"using online session inventory", which seems to indicate that
it wasn't able to successfully read the inventory.

Unfortunately, at the moment, I don't have your setup to
reproduce this failure.
Would you be able to set the environment variable, DEBUGDUMP,
rerun the failing tests (./check -g xfsdump) and 
send me the ???.out.bad files. 
The DEBUGDUMP should cause xfsdump/xfsrestore to be run with -v5.

Thanks,
Tim.

> 
> 
> >> "Marcelo E. Magallon" <marcelo.magallon@bigfoot.com> writes:
> 
>  >  I've been running the stress tests on a daily basis for a while now and
>  >  most failures have dissapered lately. [...]
> 
>  The reported failure involving mmap is no longer reproducible.
> 
>  From last night's run I have:
> 
>  Not run: 022 023 024 025 035 036 037 038 039 040 043 044
>  Failures: 020 026 028 046 047
>  Failed 5 of 35 tests
>  
>  026 is differences in the output (026.out should be updated)
> 
> 026 - output mismatch (see 026.out.bad)
> 30,31c30
> < xfsrestore: using online session inventory
> < xfsrestore: searching media for directory dump
> ---
> > xfsrestore: searching media for dump
> 32a32,43
> > xfsrestore: found dump matching specified label:
> > xfsrestore: hostname: HOSTNAME
> > xfsrestore: mount point: SCRATCH_MNT
> > xfsrestore: volume: SCRATCH_DEV
> > xfsrestore: session time: TIME
> > xfsrestore: level: 0
> > xfsrestore: session label: "stress_026"
> > xfsrestore: media label: "stress_tape_media"
> > xfsrestore: file system id: ID
> > xfsrestore: session id: ID
> > xfsrestore: media id: ID
> > xfsrestore: searching media for directory dump
> 
>  028 is two large chunks of output not present.
> 
>  046 is a difference in the output, just as 046 (046.out needs to be
>  updated)
> 
>  047 is similar to 028. (047.out.bad.gz attached)
> 
>  Thanks,
> 
> --
> Marcelo

From owner-linux-xfs@oss.sgi.com Wed Nov  8 00:10:28 2000
Received:  by oss.sgi.com id <S554005AbQKHIKT>;
	Wed, 8 Nov 2000 00:10:19 -0800
Received: from hermes.mixx.net ([212.84.196.2]:46094 "HELO hermes.mixx.net")
	by oss.sgi.com with SMTP id <S553932AbQKHIKB>;
	Wed, 8 Nov 2000 00:10:01 -0800
Received: from mate.bln.innominate.de (cerberus.berlin.innominate.de [212.84.234.251])
	by hermes.mixx.net (Postfix) with ESMTP id 672BFF80A
	for <linux-xfs@oss.sgi.com>; Wed,  8 Nov 2000 09:09:54 +0100 (CET)
Received: by mate.bln.innominate.de (Postfix, from userid 9)
	id 923B52CAA7; Wed,  8 Nov 2000 09:09:47 +0100 (CET)
From:   Thomas Graichen <news-innominate.list.sgi.xfs@innominate.de>
Reply-To: Thomas Graichen <graichen@innominate.de>
X-Newsgroups: innominate.list.sgi.xfs
Subject: Re: TAKE - xfs_admin
Date:   8 Nov 2000 08:09:47 GMT
Organization: innominate AG, Berlin, Germany
Lines:  20
Distribution: local
Message-ID: <news2mail-8ub1ob$ji0$1@mate.bln.innominate.de>
References: <200011080243.NAA05190@snort.melbourne.sgi.com>
Reply-To: thomas.graichen@innominate.de
X-Trace: mate.bln.innominate.de 973670987 20032 10.0.0.69 (8 Nov 2000 08:09:47 GMT)
X-Complaints-To: news@innominate.de
User-Agent: tin/1.4.2-20000205 ("Possession") (UNIX) (Linux/2.4.0-XFS-test10 (i586))
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

Nathan Scott <nathans@snort.melbourne.sgi.com> wrote:
> This is only really going to be useful with a new mount binary,
> which will then allow xfs filesystems to be mounted by-uuid or
> by-label rather than by block special device (mount -U/-L).

> I'm reliably informed [by Andreas :-)] that this will be in the
> 2.10q util-linux package.  If anyone wants the 2.10p+xfs patch,
> just let me know & I'll post it here.

maybe just put it onto the oss.sgi.com xfs ftp space - i would be
interested in this - because it should nicely integrate into redhat
7.0 (mounting via label) i think - right?

t

-- 
thomas.graichen@innominate.com
technical director                                       innominate AG
clustering & security                             the linux architects
tel: +49-30-308806-13   fax: -77             http://www.innominate.com

From owner-linux-xfs@oss.sgi.com Wed Nov  8 04:34:09 2000
Received:  by oss.sgi.com id <S553786AbQKHMd7>;
	Wed, 8 Nov 2000 04:33:59 -0800
Received: from krokusek.sawan.com.pl ([195.117.143.125]:39691 "EHLO
        proxy.sawan.com.pl") by oss.sgi.com with ESMTP id <S553753AbQKHMdk>;
	Wed, 8 Nov 2000 04:33:40 -0800
Received: from host (02-085.044.popsite.net [64.24.244.85])
	by proxy.sawan.com.pl (8.8.8/8.8.8) with ESMTP id NAA13167;
	Wed, 8 Nov 2000 13:39:10 +0100 (CET)
	(envelope-from nnxt@bettergolf.net)
Message-Id: <200011081239.NAA13167@proxy.sawan.com.pl>
From:   "Trent Dern" <nnxt@bettergolf.net>
Subject: Your Achievements have Paid off #598F
To:     line034m@proxy.sawan.com.pl
X-Mailer: Microsoft Outlook Express 4.72.1712.3
X-MimeOLE: Produced By Microsoft MimeOLE =?ISO-8859-1?Q?V=D0=DFD.1712.3?=
Mime-Version: 1.0
Date:   Wed, 08 Nov 2000 07:41:22 -0500
Content-Type: multipart/mixed; boundary="----=_NextPart_000_007F_01BDF6C7.FABAC1B0"
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 is a MIME Message

------=_NextPart_000_007F_01BDF6C7.FABAC1B0
Content-Type: multipart/alternative; boundary="----=_NextPart_001_0080_01BDF6C7.FABAC1B0"

------=_NextPart_001_0080_01BDF6C7.FABAC1B0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

***** This is an HTML Message ! *****


------=_NextPart_001_0080_01BDF6C7.FABAC1B0
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!doctype html public "-//w3c//dtd html 4=2E0
 transitional//en">
 <html>
 <head>
    
    <title>Executive Guild Membership
 ApplicationResponse-O-Matic Form</title>
 </head>
 <body text=3D"#808080" bgcolor=3D"3D#FDF5E6"
 link=3D"#800040" vlink=3D"#FF0000" alink=3D"#8080C0">
 <p><font color=3D"#000000">Dear Professional,<br>
 <br>
 You have been selected as a potential candidate for a free<br>
 listing in the 2000 - 2001 Edition of the International Executive<br>
 Guild Registry=2E<br>
 <br>
 Please accept our congratulations for this coveted honor=2E<br>
 <br>
 As this edition is so important in view of the new millennium, the<br>
 International Executive Guild Registry will be published in two<br>
 different formats; the searchable CD-ROM and the Online Registry=2E<br>
 <br>
 Since inclusion can be considered recognition of your career position<br>=

 and professionalism, each candidate is evaluated in keeping with high<br>=

 standards of individual achievement=2E In light of this, the Internationa=
l<br>
 Executive Guild thinks that you may make an interesting biographical<br>
 subject=2E<br>
 <br>
 We look forward to your inclusion and appearance in the International<br>=

 Executive Guild's Registry=2E Best wishes for your continued success=2E<b=
r>
 <br>
 International Executive Guild<br>
 Listing Dept=2E<br>
 <br>
 </font></p>
 <p>
 <hr WIDTH=3D"100%">
 <p align=3D"center"><b><i><font color=3D"#000000">If you
 wish to be removed from our list, please submit
 your request</font></i></b>
 <br><b><i><font face=3D"Times New
 Roman,Times"><font color=3D"#000000">at the
 bottom of this email=2E</font></font></i></b>
 </p>
 <hr WIDTH=3D"100%">
 <table WIDTH=3D"695" >
 <caption><script language=3D"JavaScript">
 
 <!--
 function validate_form() {
   validity =3D true; // assume valid
   if (!check_empty(document=2Eform=2Ebusphone=2Evalue))
         { validity =3D false; alert('Day Time
 Phone field is empty!'); }
     if (validity)
         alert ("Thank you for your registration!
 "
                 + "Your form is now being passed
 to your browser's "
                 + "Mail Delivery Sub-System for
 NORMAL"
                 + " NON-ENCRYPTED email
 delivery=2E"
                 + "  All email addresses are
 removed from our system"
                 + " upon registration=2E  Please
 click OK to proceed");
   return validity;
 }

 function check_empty(text) {
   return (text=2Elength > 0); // returns false if
 empty
 }
 
 // -->
 
 </script>
 
 
 <!-- CHANGE EMAIL ADDRESS IN ACTION OF FORM -->
 
 <form name=3D"form"
  method=3D"post"
  action=3D"mailto:ytzz@cmpmail=2Ecom?SUBJECT=3DInternet Lead"
  enctype=3D"text/plain"
  >
 
 <tr>
 <td></td>
 </tr>
 
 <tr>
 <td VALIGN=3DTOP COLSPAN=3D"2">
 <center><b><i><font color=3D"#000000"><font
 size=3D+3>International Executive Guild</font></font></i></b>
 <br><b><font color=3D"#000000"><font
 size=3D+2>Registration Form</font></font></b>
 <br><b><font color=3D"#000000">(US and Canada
 Only)</font></b>
 <br>
 <hr WIDTH=3D"100%"></center>
 </td>
 </tr>
 
 <tr>
 <td VALIGN=3DTOP COLSPAN=3D"2"><i><font
 face=3D"arial,helvetica"><font
 color=3D"#000000"><font size=3D+0>Please
 fill out this form if you would like to be
 included on The International
 Executive Guild, For accuracy and
 publication purposes, please
 complete and send this form at the earliest
 opportunity=2E There is </font>no
 charge or obligation<font size=3D+0> to be listed
 on The International Executive Guild=2E</font></font></font></i>
 <br>
 <hr WIDTH=3D"100%"></td>
 </tr>
 
 <tr>
 <td VALIGN=3DTOP></td>
 </tr>
 
 <tr>
 <td ALIGN=3DRIGHT WIDTH=3D"300"><b><font
 face=3D"arial,helvetica"><font
 color=3D"#000000"><font size=3D-1>Your
 Name</font></font></font></b></td>
 
 <td ALIGN=3DLEFT WIDTH=3D"300"><input type=3D"text"
 value size=3D"50" maxlength=3D"250" name=3D"Name"></td>
 </tr>
 
 <tr>
 <td ALIGN=3DRIGHT WIDTH=3D"300"><b><font
 face=3D"arial,helvetica"><font
 color=3D"#000000"><font size=3D-1>Your
 Company</font></font></font></b></td>
 
 <td ALIGN=3DLEFT WIDTH=3D"300"><input type=3D"text"
 value size=3D"50" maxlength=3D"250"
 name=3D"Company"></td>
 </tr>
 
 <tr>
 <td ALIGN=3DRIGHT WIDTH=3D"300"><b><font
 face=3D"arial,helvetica"><font
 color=3D"#000000"><font size=3D-
 1>Title</font></font></font></b></td>
 
 <td ALIGN=3DLEFT WIDTH=3D"300"><input type=3D"text"
 value size=3D"50" maxlength=3D"250"
 name=3D"Title"></td>
 </tr>
 
 <tr>
 <td ALIGN=3DRIGHT WIDTH=3D"300"><b><font
 face=3D"arial,helvetica"><font
 color=3D"#000000"><font size=3D-
 1>Address</font></font></font></b></td>
 
 <td ALIGN=3DLEFT WIDTH=3D"300"><input type=3D"text"
 value size=3D"50" maxlength=3D"250"
 name=3D"Address"></td>
 </tr>
 
 <tr>
 <td ALIGN=3DRIGHT WIDTH=3D"300"><b><font
 face=3D"arial,helvetica"><font
 color=3D"#000000"><font size=3D-
 1>City</font></font></font></b></td>
 
 <td ALIGN=3DLEFT WIDTH=3D"300"><input type=3D"text"
 value size=3D"50" maxlength=3D"250" name=3D"City"></td>
 </tr>
 
 <tr>
 <td ALIGN=3DRIGHT WIDTH=3D"300"><b><font
 face=3D"arial,helvetica"><font
 color=3D"#000000"><font size=3D-1>State
 or Province</font></font></font></b></td>
 
 <td ALIGN=3DLEFT WIDTH=3D"300"><input type=3D"text"
 value size=3D"12" maxlength=3D"50" name=3D"State"></td>
 </tr>
 
 <tr>
 <td ALIGN=3DRIGHT WIDTH=3D"300"><b><font
 face=3D"arial,helvetica"><font
 color=3D"#000000"><font size=3D-
 1>Country</font></font></font></b></td>
 
 <td ALIGN=3DLEFT WIDTH=3D"300"><select
 NAME=3D"Country" Size=3D"1"><option SELECTED><font
 color=3D"#000000">USA<option
 SELECTED>Canada</font></select></td>
 </tr>
 
 <tr>
 <td ALIGN=3DRIGHT WIDTH=3D"300"><b><font
 face=3D"arial,helvetica"><font
 color=3D"#000000"><font size=3D-1>ZIP/Postal
 Code</font></font></font></b></td>
 
 <td ALIGN=3DLEFT VALIGN=3DCENTER WIDTH=3D"300"><input
 type=3D"text" value size=3D"12" maxlength=3D"50"
 name=3D"Zip"></td>
 </tr>
 
 <tr>
 <td ALIGN=3DRIGHT WIDTH=3D"300"><b><font
 face=3D"arial,helvetica"><font
 color=3D"#000000"><font size=3D-1>Day
 Time Telephone</font></font></font></b></td>
 
 <td ALIGN=3DLEFT WIDTH=3D"300"><input type=3D"text"
 value size=3D"22" maxlength=3D"50"
 name=3D"busphone"></td>
 </tr>
 
 <tr>
 <td>
 <div align=3Dright><b><font
 face=3D"Arial,Helvetica"><font
 color=3D"#000000"><font size=3D-1>Home
 Phone</font></font></font></b></div>
 </td>
 
 <td><input type=3D"text" value size=3D"22"
 maxlength=3D"50" name=3D"homephone"><b><font
 color=3D"#000000"><font size=3D-2>(Not
 To Be Published)</font></font></b></td>
 </tr>
 
 <tr>
 <td>
 <div align=3Dright><b><font
 face=3D"Arial,Helvetica"><font
 color=3D"#000000"><font size=3D-
 1>Email</font></font></font></b></div>
 </td>
 
 <td><input type=3D"text" value size=3D"50"
 maxlength=3D"100" name=3D"Email"></td>
 </tr>
 
 <tr>
 <td></td>
 
 <td></td>
 </tr>
 </table>
 
 <center>
 <p>
 <hr WIDTH=3D"100%"><b><font
 face=3D"ARIAL,HELVETICA"><font
 color=3D"#000000"><font size=3D-1>TO
 HELP US IN CONSIDERING YOUR APPLICATION, PLEASE
 TELL US A LITTLE ABOUT
 YOURSELF=2E=2E=2E</font></font></font></b>
 <br>
 <hr WIDTH=3D"100%"></center>
 
 <center><table WIDTH=3D"81%" >
 <tr>
 <td ALIGN=3DRIGHT VALIGN=3DTOP WIDTH=3D"300"><b><font
 face=3D"arial,helvetica"><font
 color=3D"#000000"><font size=3D-1>Your
 Business</font></font></font></b></td>
 
 <td>
 <div align=3Dright><input type=3D"text" value
 size=3D"50" maxlength=3D"200"
 name=3D"business"></div>
 <font face=3D"arial,helvetica"><font color=3D"#000000"><font
 size=3D-1>(Financial
 Svcs, Banking, Computer Hardware, Software, Professional Svcs,
 Chemicals,
 Apparel, Aerospace, Food, Government, Utility,
 etc=2E)</font></font></font></td>
 </tr>
 
 <tr>
 <td ALIGN=3DRIGHT VALIGN=3DTOP WIDTH=3D"300"><b><font
 face=3D"arial,helvetica"><font
 color=3D"#000000"><font size=3D-1>Type
 of Organization</font></font></font></b></td>
 
 <td>
 <div align=3Dright><input type=3D"text" value size=3D"50" maxlength=3D"25=
0"
 name=3D"Orgtype"></div>
 <font face=3D"arial,helvetica"><font color=3D"#000000"><font size=3D-1>(M=
fg,
 Dist/Wholesaler, Retailer, Law Firm,</font></font></font>
 <br><font face=3D"arial,helvetica"><font color=3D"#000000"><font
 size=3D-1>Investment
 Bank, Commercial Bank, University,</font></font></font>
 <br><font face=3D"arial,helvetica"><font color=3D"#000000"><font
 size=3D-1>Financial
 Consultants, Ad Agency, Contractor, Broker,
 etc=2E)</font></font></font></td>
 </tr>
 
 <tr>
 <td VALIGN=3DTOP WIDTH=3D"300">
 <div align=3Dright><b><font face=3D"arial,helvetica"><font
 color=3D"#000000"><font
 size=3D-1>Your
 Business Expertise</font></font></font></b></div>
 </td>
 
 <td>
 <div align=3Dright><input type=3D"text" value size=3D"50" maxlength=3D"25=
0"
 name=3D"expertise"></div>
 <font face=3D"arial,helvetica"><font color=3D"#000000"><font
 size=3D-1>(Corp=2EMgmt,
 Marketing, Civil Engineering,</font></font></font>
 <br><font face=3D"arial,helvetica"><font color=3D"#000000"><font size=3D-=
1>Tax
 
 Law, Nuclear Physics, Database Development, Operations, Pathologist,
 Mortgage
 Banking, etc=2E)</font></font></font></td>
 </tr>
 
 <tr>
 <td ALIGN=3DRIGHT VALIGN=3DTOP WIDTH=3D"300"><b><font
 face=3D"arial,helvetica"><font
 color=3D"#000000"><font size=3D-1>Major
 Product Line</font></font></font></b></td>

 <td>
 <div align=3Dright><input type=3D"text" value size=3D"50" maxlength=3D"25=
0"
 name=3D"product"></div>
 <font face=3D"arial,helvetica"><font color=3D"#000000"><font
 size=3D-1>(Integrated
 Circuits, Commercial Aircraft, Adhesives, Cosmetics, Plastic Components,
 
 Snack Foods, etc=2E)</font></font></font></td>
 </tr>
 </table></center>
 
 <center>
 <p><input NAME=3D"submit" TYPE=3D"submit" VALUE=3D" Submit By E-Mail "><i=
nput
 NAME=3D"reset" TYPE=3D"reset" VALUE=3D" Clear Form "></form>
 <br><b><font color=3D"#000000"><font size=3D-1>Note: Submitting this form=

 will
 be made by email, not by use of&nbsp; www=2E&nbsp; Confirmation of its de=
livery
 is made by browsing your outgoing mail=2E</font></font></b>
 <br>
 <hr WIDTH=3D"100%"><b><i><font face=3D"arial,helvetica"><font
 color=3D"#000000"><font
 size=3D-1>Thank
 you for filling in this form, we will contact you with more
 information=2E</font></font></font></i></b>
 <br>
 <hr WIDTH=3D"100%">
 <br><b><font size=3D+1>List
 Removal</font></b>
 <br><b><font color=3D"#000000"><font size=3D-1><a
 href=3D"mailto:nnxt2@netscape=2Enet?subject=3Dremove">Click
 Here</a></font></font></b></center>
 
 </body>
 </html>

------=_NextPart_001_0080_01BDF6C7.FABAC1B0--

------=_NextPart_000_007F_01BDF6C7.FABAC1B0--




From owner-linux-xfs@oss.sgi.com Wed Nov  8 14:41:31 2000
Received:  by oss.sgi.com id <S553717AbQKHWlW>;
	Wed, 8 Nov 2000 14:41:22 -0800
Received: from deliverator.sgi.com ([204.94.214.10]:29239 "EHLO
        deliverator.sgi.com") by oss.sgi.com with ESMTP id <S553698AbQKHWlI>;
	Wed, 8 Nov 2000 14:41:08 -0800
Received: from nodin.corp.sgi.com (nodin.corp.sgi.com [192.26.51.193]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id OAA05367; Wed, 8 Nov 2000 14:33:17 -0800 (PST)
	mail_from (nobody@info.engr.sgi.com)
Received: from info.engr.sgi.com (info.engr.sgi.com [192.26.80.216]) by nodin.corp.sgi.com (980427.SGI.8.8.8/980728.SGI.AUTOCF) via ESMTP id OAA56614; Wed, 8 Nov 2000 14:39:22 -0800 (PST)
Received: (from nobody@localhost)
	by info.engr.sgi.com (SGI-8.9.3/8.9.3) id OAA49734;
	Wed, 8 Nov 2000 14:38:05 -0800 (PST)
Date:   Wed, 8 Nov 2000 14:38:05 -0800 (PST)
Message-Id: <200011082238.OAA49734@info.engr.sgi.com>
X-Pv-Incident: 804570 
webPV:  ioperf.americas.sgi.com 
webExec: webpvupdate,pvincident 
Reply-To: sgi.bugs.xfs@fido.engr.sgi.com
From:   pv@relay.sgi.com (raa@sgi.com)
Subject: ADD 804570 - The elevator bug
To:     nb@sgi.com
Cc:     raa@sgi.com, huovinen@sgi.com, cattelan@sgi.com, mann@sgi.com,
        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=804570

*CC List : raa@sgi.com huovinen@sgi.com cattelan@sgi.com mann@sgi.com
 Status : open                        
 Priority : 3                          Assigned Engineer : nb               
 Submitter : coreym                   *Modified User : raa                  
*Modified User Domain : sgi.com       *Description :
I ran rwtest on a xfs-linux filesystem on the machine permit:

rwtest 100000000:/mnt1/file_1 >/tmp/file_1.out 2>&1 &

This caused df, ls -l, fdisk, and top all to hang.

Permit is running Redhat 6.2 with a 2.4.0-test5 kernel

==========================
ADDITIONAL INFORMATION (ADD)

.....


==========================
ADDITIONAL INFORMATION (ADD)
From: raa@sgi.com (BugWorks)
Date: Nov 08 2000 02:38:04PM
==========================

From owner-linux-xfs@oss.sgi.com Wed Nov  8 14:44:11 2000
Received:  by oss.sgi.com id <S554047AbQKHWoB>;
	Wed, 8 Nov 2000 14:44:01 -0800
Received: from deliverator.sgi.com ([204.94.214.10]:48696 "EHLO
        deliverator.sgi.com") by oss.sgi.com with ESMTP id <S553687AbQKHWnw>;
	Wed, 8 Nov 2000 14:43:52 -0800
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 OAA06064; Wed, 8 Nov 2000 14:36:02 -0800 (PST)
	mail_from (nobody@info.engr.sgi.com)
Received: (from nobody@localhost)
	by info.engr.sgi.com (SGI-8.9.3/8.9.3) id OAA69272;
	Wed, 8 Nov 2000 14:43:51 -0800 (PST)
Date:   Wed, 8 Nov 2000 14:43:51 -0800 (PST)
Message-Id: <200011082243.OAA69272@info.engr.sgi.com>
X-Pv-Incident: 804570 
webPV:  ioperf.americas.sgi.com 
webExec: webpvupdate,pvincident 
Reply-To: sgi.bugs.xfs@fido.engr.sgi.com
From:   pv@relay.sgi.com (raa@sgi.com)
Subject: ADD 804570 - The elevator bug
To:     nb@sgi.com
Cc:     raa@sgi.com, huovinen@sgi.com, cattelan@sgi.com, mann@sgi.com,
        tbd@sgi.com, rrl@sgi.com, alaffin@sgi.com, 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=804570

*CC List : raa@sgi.com huovinen@sgi.com cattelan@sgi.com mann@sgi.com tbd@sgi.com rrl@sgi.com alaffin@sgi.com
 Status : open                        
 Priority : 3                          Assigned Engineer : nb               
 Submitter : coreym                   *Modified User : raa                  
*Modified User Domain : sgi.com       *Description :
I ran rwtest on a xfs-linux filesystem on the machine permit:

rwtest 100000000:/mnt1/file_1 >/tmp/file_1.out 2>&1 &

This caused df, ls -l, fdisk, and top all to hang.

Permit is running Redhat 6.2 with a 2.4.0-test5 kernel

==========================
ADDITIONAL INFORMATION (ADD)

.....


==========================
ADDITIONAL INFORMATION (ADD)
From: raa@sgi.com (BugWorks)
Date: Nov 08 2000 02:43:51PM
==========================

From owner-linux-xfs@oss.sgi.com Wed Nov  8 15:12:42 2000
Received:  by oss.sgi.com id <S554050AbQKHXMb>;
	Wed, 8 Nov 2000 15:12:31 -0800
Received: from deliverator.sgi.com ([204.94.214.10]:4421 "EHLO
        deliverator.sgi.com") by oss.sgi.com with ESMTP id <S553704AbQKHXMS>;
	Wed, 8 Nov 2000 15:12:18 -0800
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 PAA12136
	for <linux-xfs@oss.sgi.com>; Wed, 8 Nov 2000 15:04:25 -0800 (PST)
	mail_from (nathans@wobbly.melbourne.sgi.com)
Received: from wobbly.melbourne.sgi.com (wobbly.melbourne.sgi.com [134.14.55.135]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id KAA13637; Thu, 9 Nov 2000 10:10:58 +1100
Received: (from nathans@localhost) by wobbly.melbourne.sgi.com (980427.SGI.8.8.8/980728.SGI.AUTOCF) id KAA24257; Thu, 9 Nov 2000 10:10:56 +1100 (EDT)
From:   "Nathan Scott" <nathans@wobbly.melbourne.sgi.com>
Message-Id: <10011091010.ZM122015@wobbly.melbourne.sgi.com>
Date:   Thu, 9 Nov 2000 10:10:55 -0400
In-Reply-To: Thomas Graichen <news-innominate.list.sgi.xfs@innominate.de>
        "Re: TAKE - xfs_admin" (Nov  8,  8:09am)
References: <200011080243.NAA05190@snort.melbourne.sgi.com> 
	<news2mail-8ub1ob$ji0$1@mate.bln.innominate.de>
X-Mailer: Z-Mail (3.2.3 08feb96 MediaMail)
To:     Thomas Graichen <graichen@innominate.de>,
        thomas.graichen@innominate.de
Subject: Re: TAKE - xfs_admin
Cc:     linux-xfs@oss.sgi.com
Mime-Version: 1.0
Content-Type: multipart/mixed;
	boundary="PART-BOUNDARY=.110011091010.ZM122015.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

--
--PART-BOUNDARY=.110011091010.ZM122015.melbourne.sgi.com
Content-Type: text/plain; charset=us-ascii

hi Thomas,

On Nov 8,  8:09am, Thomas Graichen wrote:
> Subject: Re: TAKE - xfs_admin
> ...
> maybe just put it onto the oss.sgi.com xfs ftp space - i would be
> interested in this - because it should nicely integrate into redhat
> 7.0 (mounting via label) i think - right?
> 

The mount-by-uuid/label has been in mount for some time now I
believe - it exists in my Redhat 6.2 installation for example,
and the changelog at the head of mount_by_label.c dates back
to Feb '99.

I've attached the patch to util-linux-2.10p (I don't have a
login on oss - perhaps some other kind soul could put a copy
there for me?).

cheers.

-- 
Nathan

--PART-BOUNDARY=.110011091010.ZM122015.melbourne.sgi.com
X-Zm-Content-Name: util-linux-2.10p.diff
Content-Description: Text
Content-Type: text/plain ; name="util-linux-2.10p.diff" ; charset=us-ascii

diff -Naur util-linux-2.10p/mount/README.mount util-linux/mount/README.mount
--- util-linux-2.10p/mount/README.mount	Fri Jul  9 12:56:39 1999
+++ util-linux/mount/README.mount	Tue Nov  7 12:14:01 2000
@@ -6,5 +6,5 @@
 Stephen Tweedie <sct@dcs.ed.ac.uk>.
 
 Presently maintained by Andries Brouwer <aeb@cwi.nl>.
-Ftp site: ftp.win.tue.nl:/pub/linux/util .
+Ftp site: ftp.win.tue.nl:/pub/linux/utils/util-linux
 
diff -Naur util-linux-2.10p/mount/linux_fs.h util-linux/mount/linux_fs.h
--- util-linux-2.10p/mount/linux_fs.h	Sun Apr 16 22:23:38 2000
+++ util-linux/mount/linux_fs.h	Tue Nov  7 14:07:58 2000
@@ -100,3 +100,13 @@
     u_char    s_label2[11];	/* for Windows? */
     u_char    s_fs2[8];	        /* garbage or "FAT32   " */
 };
+
+#define XFS_SUPER_MAGIC "XFSB"
+#define XFS_SUPER_MAGIC2 "BSFX"
+struct xfs_super_block {
+    u_char    s_magic[4];
+    u_char    s_dummy[28];
+    u_char    s_uuid[16];
+    u_char    s_dummy2[60];
+    u_char    s_fname[12];
+};
diff -Naur util-linux-2.10p/mount/mount_by_label.c util-linux/mount/mount_by_label.c
--- util-linux-2.10p/mount/mount_by_label.c	Thu Oct  5 11:32:24 2000
+++ util-linux/mount/mount_by_label.c	Tue Nov  7 15:35:28 2000
@@ -7,6 +7,8 @@
  * - Added error message if /proc/partitions cannot be opened
  * 2000-05-09 Erik Troan <ewt@redhat.com>
  * - Added cache for UUID and disk labels
+ * 2000-11-07 Nathan Scott <nathans@sgi.com>
+ * - Added XFS support
  */
 
 #include <stdio.h>
@@ -29,35 +31,44 @@
 	char *device;
 } *uuidCache = NULL;
 
-/* for now, only ext2 is supported */
+/* for now, only ext2 and xfs are supported */
 static int
 get_label_uuid(const char *device, char **label, char *uuid) {
 
-	/* start with a test for ext2, taken from mount_guess_fstype */
+	/* start with ext2 and xfs tests, taken from mount_guess_fstype */
 	/* should merge these later */
 	int fd;
+	int rv = 1;
+	size_t namesize;
 	struct ext2_super_block e2sb;
+	struct xfs_super_block xfsb;
 
 	fd = open(device, O_RDONLY);
 	if (fd < 0)
-		return 1;
+		return rv;
 
-	if (lseek(fd, 1024, SEEK_SET) != 1024
-	    || read(fd, (char *) &e2sb, sizeof(e2sb)) != sizeof(e2sb)
-	    || (ext2magic(e2sb) != EXT2_SUPER_MAGIC)) {
-		close(fd);
-		return 1;
+	if (lseek(fd, 1024, SEEK_SET) == 1024
+	    && read(fd, (char *) &e2sb, sizeof(e2sb)) == sizeof(e2sb)
+	    && (ext2magic(e2sb) == EXT2_SUPER_MAGIC)) {
+		memcpy(uuid, e2sb.s_uuid, sizeof(e2sb.s_uuid));
+		namesize = sizeof(e2sb.s_volume_name);
+		if ((*label = calloc(namesize + 1, 1)) != NULL)
+			memcpy(*label, e2sb.s_volume_name, namesize);
+		rv = 0;
+	}
+	else if (lseek(fd, 0, SEEK_SET) == 0
+	    && read(fd, (char *) &xfsb, sizeof(xfsb)) == sizeof(xfsb)
+	    && (strncmp((char *) &xfsb.s_magic, XFS_SUPER_MAGIC, 4) == 0 ||
+	        strncmp((char *) &xfsb.s_magic, XFS_SUPER_MAGIC2,4) == 0)) {
+		memcpy(uuid, xfsb.s_uuid, sizeof(xfsb.s_uuid));
+		namesize = sizeof(xfsb.s_fname);
+		if ((*label = calloc(namesize + 1, 1)) != NULL)
+			memcpy(*label, xfsb.s_fname, namesize);
+		rv = 0;
 	}
 
 	close(fd);
-
-	/* superblock is ext2 - now what is its label? */
-	memcpy(uuid, e2sb.s_uuid, sizeof(e2sb.s_uuid));
-
-	*label = calloc(sizeof(e2sb.s_volume_name) + 1, 1);
-	memcpy(*label, e2sb.s_volume_name, sizeof(e2sb.s_volume_name));
-
-	return 0;
+	return rv;
 }
 
 static void
diff -Naur util-linux-2.10p/mount/mount_guess_fstype.c util-linux/mount/mount_guess_fstype.c
--- util-linux-2.10p/mount/mount_guess_fstype.c	Mon May 15 22:34:43 2000
+++ util-linux/mount/mount_guess_fstype.c	Tue Nov  7 11:40:34 2000
@@ -131,11 +131,11 @@
     union {
 	struct xiafs_super_block xiasb;
 	char romfs_magic[8];
-	char xfs_magic[4];
 	char qnx4fs_magic[10];	/* ignore first 4 bytes */
 	long bfs_magic;
 	struct ntfs_super_block ntfssb;
 	struct fat_super_block fatsb;
+	struct xfs_super_block xfsb;
     } xsb;
     struct ufs_super_block ufssb;
     union {
@@ -179,8 +179,8 @@
 	      type = "xiafs";
 	 else if(!strncmp(xsb.romfs_magic, "-rom1fs-", 8))
 	      type = "romfs";
-	 else if(!strncmp(xsb.xfs_magic, "XFSB", 4) ||
-		 !strncmp(xsb.xfs_magic, "BSFX", 4))
+	 else if(!strncmp(xsb.xfsb.s_magic, XFS_SUPER_MAGIC, 4) ||
+		 !strncmp(xsb.xfsb.s_magic, XFS_SUPER_MAGIC2, 4))
 	      type = "xfs";
 	 else if(!strncmp(xsb.qnx4fs_magic+4, "QNX4FS", 6))
 	      type = "qnx4fs";
diff -Naur util-linux-2.10p/mount/umount.c util-linux/mount/umount.c
--- util-linux-2.10p/mount/umount.c	Wed Sep 20 00:54:41 2000
+++ util-linux/mount/umount.c	Tue Nov  7 11:08:47 2000
@@ -24,6 +24,7 @@
  *             - Differentiate "user" and "users" key words in fstab
  */
 
+#include <stdio.h>
 #include <unistd.h>
 #include <getopt.h>
 #include <string.h>

--PART-BOUNDARY=.110011091010.ZM122015.melbourne.sgi.com--


From owner-linux-xfs@oss.sgi.com Wed Nov  8 22:35:13 2000
Received:  by oss.sgi.com id <S553690AbQKIGfD>;
	Wed, 8 Nov 2000 22:35:03 -0800
Received: from deliverator.sgi.com ([204.94.214.10]:21570 "EHLO
        deliverator.sgi.com") by oss.sgi.com with ESMTP id <S553648AbQKIGet>;
	Wed, 8 Nov 2000 22:34:49 -0800
Received: from nodin.corp.sgi.com (nodin.corp.sgi.com [192.26.51.193]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id WAA10197; Wed, 8 Nov 2000 22:26:58 -0800 (PST)
	mail_from (nobody@info.engr.sgi.com)
Received: from info.engr.sgi.com (info.engr.sgi.com [192.26.80.216]) by nodin.corp.sgi.com (980427.SGI.8.8.8/980728.SGI.AUTOCF) via ESMTP id WAA21939; Wed, 8 Nov 2000 22:34:18 -0800 (PST)
Received: (from nobody@localhost)
	by info.engr.sgi.com (SGI-8.9.3/8.9.3) id WAA19012;
	Wed, 8 Nov 2000 22:33:01 -0800 (PST)
Date:   Wed, 8 Nov 2000 22:33:01 -0800 (PST)
Message-Id: <200011090633.WAA19012@info.engr.sgi.com>
X-Pv-Incident: 807350 
webPV:  proxy2.melbourne.sgi.com 
webExec: webpvsubmit,PvProjectIncident 
Reply-To: sgi.bugs.xfs@fido.engr.sgi.com
From:   pv@relay.sgi.com (tes@engr.sgi.com)
Subject: BUG 807350 - xfsdump/xfsrestore incorrectly handling inventory
To:     tes@engr.sgi.com
Cc:     ivanr@omen.sgi.com, 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=807350

Submitter : tes                       Submitter Domain : engr               
Assigned Engineer : tes               Assigned Domain : engr                
Assigned Group : xfs-linux            Category : software                   
Customer Reported : F                 Priority : 3                          
Project : xfs-linux                   Status : open                         
Description :
Marcelo E. Magallo (marcelo.magallon@bigfoot.com)
reported failures on the xfs/stress tests: 026, 028, 046, 047.
On inspection of the ???.out.bad files it appears that
xfsdump/xfsrestore is unable to read the online inventory
data.

This is reported for a SuSE 7 box with:

=============================================================
# /lib/libc.so.6 
GNU C Library stable release version 2.1.3, by Roland McGrath et al.
Copyright (C) 1992, 93, 94, 95, 96, 97, 98, 99 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.
There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A
PARTICULAR PURPOSE.
Compiled by GNU CC version 2.95.2 19991024 (release).
Compiled on a Linux 2.2.14 system on 2000-09-05.
Available extensions:
        GNU libio by Per Bothner
        crypt add-on version 2.1 by Michael Glad and others
        linuxthreads-0.8 by Xavier Leroy
        NoVersion patch for broken glibc 2.0 binaries
        BIND-4.9.7-REL
        NIS(YP)/NIS+ NSS modules 0.19 by Thorsten Kukuk
        NSS V1 modules 2.0.2 by Thorsten Kukuk
        libthread_db work sponsored by Alpha Processor Inc
Report bugs using the `glibcbug' script to <bugs@gnu.org>.

bash-2.03# uname -a
Linux bolero 2.4.0-XFS-test10 #1 Tue Nov 7 04:26:19 MET 2000 i686 unknown

# df
Filesystem           1k-blocks      Used Available Use% Mounted on
/dev/hdc3             40784232   4208488  36575744  10% /
/dev/hda7                 7496      5300      1796  75% /boot
/dev/hdc4              2091680       144   2091536   0% /xfs-stress-test/b
/dev/hdc2              2099712     34096   2065616   2% /xfs-stress-test/a

 The kernel is compiled using 

# gcc -v
Reading specs from /usr/lib/gcc-lib/i486-linux/egcs-2.91.66/specs
gcc version egcs-2.91.66 19990314/Linux (egcs-1.1.2 release)

 but the box where the tests are run has:

# gcc -v
Reading specs from /usr/lib/gcc-lib/i486-suse-linux/2.95.2/specs
gcc version 2.95.2 19991024 (release)
=======================================================


My next step is to determine if there is a problem writing
or reading from the inventory files.
I will get Marcello to send me the inventory files and see
if I can read them locally.
I might also see if it is worth adding some more diagnostics
to xfsdump/xfsrestore in the inventory code.

This inventory problem has never been seen locally.

From owner-linux-xfs@oss.sgi.com Wed Nov  8 22:47:03 2000
Received:  by oss.sgi.com id <S553716AbQKIGqn>;
	Wed, 8 Nov 2000 22:46:43 -0800
Received: from deliverator.sgi.com ([204.94.214.10]:34884 "EHLO
        deliverator.sgi.com") by oss.sgi.com with ESMTP id <S553681AbQKIGqV>;
	Wed, 8 Nov 2000 22:46:21 -0800
Received: from nodin.corp.sgi.com (nodin.corp.sgi.com [192.26.51.193]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id WAA11231; Wed, 8 Nov 2000 22:38:30 -0800 (PST)
	mail_from (nobody@info.engr.sgi.com)
Received: from info.engr.sgi.com (info.engr.sgi.com [192.26.80.216]) by nodin.corp.sgi.com (980427.SGI.8.8.8/980728.SGI.AUTOCF) via ESMTP id WAA59535; Wed, 8 Nov 2000 22:44:34 -0800 (PST)
Received: (from nobody@localhost)
	by info.engr.sgi.com (SGI-8.9.3/8.9.3) id WAA26254;
	Wed, 8 Nov 2000 22:44:34 -0800 (PST)
Date:   Wed, 8 Nov 2000 22:44:34 -0800 (PST)
Message-Id: <200011090644.WAA26254@info.engr.sgi.com>
X-Pv-Incident: 807351 
webPV:  proxy2.melbourne.sgi.com 
webExec: webpvsubmit,PvProjectIncident 
Reply-To: sgi.bugs.xfs@fido.engr.sgi.com
From:   pv@relay.sgi.com (tes@engr.sgi.com)
Subject: BUG 807351 - xfsdump not seemingly to always update inventory
To:     tes@engr.sgi.com
Cc:     ivanr@cthulhu.engr.sgi.com, 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=807351

Submitter : tes                       Submitter Domain : engr               
Assigned Engineer : tes               Assigned Domain : engr                
Assigned Group : xfs-linux            Category : software                   
Customer Reported : F                 Priority : 3                          
Project : xfs-linux                   Status : open                         
Description :
Eric Sandeen has reported failures for xfs stress tests
of 028 and 047.
These tests test out invutil by doing 5 dumps and then
pruning out about half of the dump sessions from the inventory.

However, Eric has found that only a maximum of 1 dump
session per file-system shows up in the inventory.

Eric wrote:
------------------------------------------------------
After multiple xfsdumps on the same filesystem, xfsdump -I returns only
the first session.  (Running commands such as `xfsdump -f
/tmp/session1.dumpfile -M stress_tape_media -L session.1 /mnt/scratch`)

The size & date of the *.StObj and *.InvIndex files in
/var/xfsdump/inventory are updated with each xfsdump;
/var/xfsdump/inventory/fstab is unchanged.  If I dump a different
filesystem, (only) the first dump sessionfrom each filesystem shows up
in xfsdump -I.
-------------------------------------------------------------

From owner-linux-xfs@oss.sgi.com Thu Nov  9 00:43:53 2000
Received:  by oss.sgi.com id <S554049AbQKIIno>;
	Thu, 9 Nov 2000 00:43:44 -0800
Received: from deliverator.sgi.com ([204.94.214.10]:21597 "EHLO
        deliverator.sgi.com") by oss.sgi.com with ESMTP id <S553781AbQKIInS>;
	Thu, 9 Nov 2000 00:43:18 -0800
Received: from sherman.melbourne.sgi.com (sherman.melbourne.sgi.com [134.14.55.175]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id AAA23451
	for <linux-xfs@oss.sgi.com>; Thu, 9 Nov 2000 00:35:25 -0800 (PST)
	mail_from (tes@sherman.melbourne.sgi.com)
Received: (from tes@localhost)
	by sherman.melbourne.sgi.com (8.9.3/8.9.3) id TAA05927
	for linux-xfs@oss.sgi.com; Thu, 9 Nov 2000 19:42:13 +1100
Date:   Thu, 9 Nov 2000 19:42:13 +1100
From:   Tim Shimmin <tes@sherman.melbourne.sgi.com>
Message-Id: <200011090842.TAA05927@sherman.melbourne.sgi.com>
Subject: TAKE - dump stress
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

Marcelo,
I've added stuff to common.dump so that if DEBUGDUMP is set
then it stores the inventory for the test in ???.inventory.*


--Tim
 
Date:  Thu Nov  9 00:40:04 PST 2000
Workarea:  sherman.melbourne.sgi.com:/hosts/snort/build4/tes/slinx-xfs

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


Modid:  2.4.x-xfs:slinx:77912a
cmd/xfs/stress/common.dump - 1.21
	- Make invutil get called with debug if DEBUGDUMP set.
	  Also store inventory in seq.inventory.tgz and seq.inventory.ls
	  if DEBUGDUMP set.
	  A step towards helping diagnose inventory problems.

cmd/xfs/stress/028 - 1.5
cmd/xfs/stress/047 - 1.2
	- Put invutil call in common.dump to add debug stuff.



From owner-linux-xfs@oss.sgi.com Thu Nov  9 06:33:45 2000
Received:  by oss.sgi.com id <S553776AbQKIOdf>;
	Thu, 9 Nov 2000 06:33:35 -0800
Received: from hermes.mixx.net ([212.84.196.2]:23823 "HELO hermes.mixx.net")
	by oss.sgi.com with SMTP id <S553746AbQKIOdH>;
	Thu, 9 Nov 2000 06:33:07 -0800
Received: from mate.bln.innominate.de (cerberus.berlin.innominate.de [212.84.234.251])
	by hermes.mixx.net (Postfix) with ESMTP id 7321BF806
	for <linux-xfs@oss.sgi.com>; Thu,  9 Nov 2000 15:33:05 +0100 (CET)
Received: by mate.bln.innominate.de (Postfix, from userid 9)
	id C01B52CA6E; Thu,  9 Nov 2000 15:33:04 +0100 (CET)
From:   Thomas Graichen <news-innominate.list.sgi.xfs@innominate.de>
Reply-To: Thomas Graichen <graichen@innominate.de>
X-Newsgroups: innominate.list.sgi.xfs
Subject: stress test on ppc
Date:   9 Nov 2000 14:33:04 GMT
Organization: innominate AG, Berlin, Germany
Lines:  212
Distribution: local
Message-ID: <news2mail-8uecj0$i5e$1@mate.bln.innominate.de>
Reply-To: thomas.graichen@innominate.de
X-Trace: mate.bln.innominate.de 973780384 18606 10.0.0.69 (9 Nov 2000 14:33:04 GMT)
X-Complaints-To: news@innominate.de
User-Agent: tin/1.4.2-20000205 ("Possession") (UNIX) (Linux/2.4.0-XFS-test10 (i586))
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

heres the output of a stress test run on a ppc machine ... i've set
this one up here at work now and had to fiddle a bit with it due to
the bad integration of the latest ppc code into the main kernel
base - thus the kernel i run is a mixture of the XFS kernel and
the latest ppc kernel - this might also be the reason of the non
working attr stuff (i think i'll have to add the syscalls back to
the arch/ppc tree which i have mostly taken from the ppc sources)

all in all it looks quite fine so far i think (my first stress
test at all :-) ... one thing is not really clear to me: why
it says "[not run] this test requires a valid $SCRATCH_DEV" if
i have a valid scratchdev defined in the config.common file -
any ideas (before i look into it)?

btw. so far it works really nice on ppc now - ran some dbench 32
and so without any problems here ... will test further

i also warmed up the alpha again but will have to fix some
compilation problems first before i can check the status of
XFS on that platform again too ...

t

001 28s ...
002 - output mismatch (see 002.out.bad)
2a3,21
> 002: [: 2    : integer expression expected
> 002: [: 3    : integer expression expected
> 002: [: 4    : integer expression expected
> 002: [: 5    : integer expression expected
> 002: [: 6    : integer expression expected
> 002: [: 7    : integer expression expected
> 002: [: 8    : integer expression expected
> 002: [: 9    : integer expression expected
> 002: [: 10   : integer expression expected
> 002: [: 11   : integer expression expected
> 002: [: 12   : integer expression expected
> 002: [: 13   : integer expression expected
> 002: [: 14   : integer expression expected
> 002: [: 15   : integer expression expected
> 002: [: 16   : integer expression expected
> 002: [: 17   : integer expression expected
> 002: [: 18   : integer expression expected
> 002: [: 19   : integer expression expected
> 002: [: 20   : integer expression expected
003
004 [not run] this test requires a valid $SCRATCH_DEV
005
006
007
008
009 [not run] this test requires a valid $SCRATCH_DEV
010
011
012
013
014
015 [not run] this test requires a valid $SCRATCH_DEV
016 [not run] this test requires a valid $SCRATCH_DEV
017 [not run] this test requires a valid $SCRATCH_DEV
018 [not run] this test requires a valid $SCRATCH_DEV
019 [not run] this test requires a valid $SCRATCH_DEV
020 - output mismatch (see 020.out.bad)
4c4
< attr_list: No such file or directory
---
> attr_list: Function not implemented
9c9
< attr_list: Invalid argument
---
> attr_list: Function not implemented
14c14,16
<       *** 0 attribute(s)
---
> attr_list: Function not implemented
> Could not list attributes for <TESTFILE>
>       !!! error return
16c18
< attr_get: No data available
---
> attr_get: Function not implemented
19,26c21,26
< Attribute "fish" set to a 5 byte value for <TESTFILE>:
< fish
< 
<    *** print attributes
<       *** 1 attribute(s)
<          *** field: fish length: 5
<             ::: fish
<             ::: 
---
> attr_set: Function not implemented
> Could not set "fish" for <TESTFILE>
>    *** print attributes
> attr_list: Function not implemented
> Could not list attributes for <TESTFILE>
>       !!! error return
28,35c28,33
< Attribute "fish" set to a 6 byte value for <TESTFILE>:
< fish3
< 
<    *** print attributes
<       *** 1 attribute(s)
<          *** field: fish length: 6
<             ::: fish3
<             ::: 
---
> attr_set: Function not implemented
> Could not set "fish" for <TESTFILE>
>    *** print attributes
> attr_list: Function not implemented
> Could not list attributes for <TESTFILE>
>       !!! error return
37,47c35,40
< Attribute "snrub" set to a 6 byte value for <TESTFILE>:
< fish2
< 
<    *** print attributes
<       *** 2 attribute(s)
<          *** field: fish length: 6
<             ::: fish3
<             ::: 
<          *** field: snrub length: 6
<             ::: fish2
<             ::: 
---
> attr_set: Function not implemented
> Could not set "snrub" for <TESTFILE>
>    *** print attributes
> attr_list: Function not implemented
> Could not list attributes for <TESTFILE>
>       !!! error return
48a42,43
> attr_remove: Function not implemented
> Could not remove "fish" for <TESTFILE>
50,53c45,47
<       *** 1 attribute(s)
<          *** field: snrub length: 6
<             ::: fish2
<             ::: 
---
> attr_list: Function not implemented
> Could not list attributes for <TESTFILE>
>       !!! error return
55,81c49,51
< *** check
<    *** 1001 attribute(s)
< *** remove lots of attributes
<    *** print attributes
<       *** 1 attribute(s)
<          *** field: snrub length: 6
<             ::: fish2
<             ::: 
< *** really long value
< 0000000 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
< *
< 0200000 0a
< 0200001
< *** set/get/remove really long names (expect failure)
< attr_set: Bad address
< Could not set "XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX" for <TESTFILE>
< attr_get: Bad address
< Could not get "XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX" for <TESTFILE>
< attr_remove: Bad address
< Could not remove "XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX" for <TESTFILE>
< *** check final
<    *** print attributes
<       *** 1 attribute(s)
<          *** field: snrub length: 6
<             ::: fish2
<             ::: 
< *** delete
---
> attr_set: Function not implemented
> Could not set "attribute_0" for /test/attribute_12657
> !!! failed to add "attribute_0"
021 [not run] this test requires a valid $SCRATCH_DEV
022 [not run] No dump tape specified
023 [not run] No dump tape specified
024 [not run] No dump tape specified
025 [not run] No dump tape specified
026 [not run] this test requires a valid $SCRATCH_DEV
027 [not run] this test requires a valid $SCRATCH_DEV
028 [not run] this test requires a valid $SCRATCH_DEV
029 [not run] this test requires a valid $SCRATCH_DEV
030 [not run] this test requires a valid $SCRATCH_DEV
031 [not run] this test requires a valid $SCRATCH_DEV
032 [not run] this test requires a valid $SCRATCH_DEV
033 [not run] this test requires a valid $SCRATCH_DEV
034 [not run] this test requires a valid $SCRATCH_DEV
035 [not run] No dump tape specified
036 [not run] No dump tape specified
037 [not run] No dump tape specified
038 [not run] No dump tape specified
039 [not run] No dump tape specified
040
041 [not run] this test requires a valid $SCRATCH_DEV
042 [not run] this test requires a valid $SCRATCH_DEV
043 [not run] No dump tape specified
044 [not run] this test requires a valid $SCRATCH_LOGDEV
045 [not run] this test requires a valid $SCRATCH_DEV
046 [not run] this test requires a valid $SCRATCH_DEV
047 [not run] this test requires a valid $SCRATCH_DEV
Not run: 004 009 015 016 017 018 019 021 022 023 024 025 026 027 028 029 030 031 032 033 034 035 036 037 038 039 041 042 043 044 045 046 047
Failures: 002 020
Failed 2 of 14 tests

-- 
thomas.graichen@innominate.com
technical director                                       innominate AG
clustering & security                             the linux architects
tel: +49-30-308806-13   fax: -77             http://www.innominate.com

From owner-linux-xfs@oss.sgi.com Thu Nov  9 06:58:29 2000
Received:  by oss.sgi.com id <S554038AbQKIO6J>;
	Thu, 9 Nov 2000 06:58:09 -0800
Received: from mail.connex.com ([216.100.236.3]:28434 "EHLO
        cairn-gorm.cragtech.com") by oss.sgi.com with ESMTP
	id <S553809AbQKIO5n>; Thu, 9 Nov 2000 06:57:43 -0800
Received: by cairn-gorm.cragtech.com with Internet Mail Service (5.5.2650.21)
	id <W1Z1F3N5>; Thu, 9 Nov 2000 06:56:12 -0800
Message-ID: <B14BF8753E65D211ABCA00104B301EF5015A4CB8@cairn-gorm.cragtech.com>
From:   Scott Smyth <SSmyth@Connex.com>
To:     "'linux-xfs@oss.sgi.com'" <linux-xfs@oss.sgi.com>
Cc:     'Nathan Scott ' <nathans@snort.melbourne.sgi.com>
Subject: RE: TAKE - xfs_admin
Date:   Thu, 9 Nov 2000 06:56:08 -0800 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing

Yes, please.  Could you post the 2.10p+patch?

thanks, Scott

-----Original Message-----
From: Nathan Scott
To: linux-xfs@oss.sgi.com
Sent: 11/7/00 6:43 PM
Subject: TAKE - xfs_admin

This is only really going to be useful with a new mount binary,
which will then allow xfs filesystems to be mounted by-uuid or
by-label rather than by block special device (mount -U/-L).

I'm reliably informed [by Andreas :-)] that this will be in the
2.10q util-linux package.  If anyone wants the 2.10p+xfs patch,
just let me know & I'll post it here.

cheers.


Modid:  2.4.x-xfs:slinx:77786a
Date:  Tue Nov  7 18:00:10 PST 2000
Workarea:  snort:/build4/nathans/linux-xfs
Author:  nathans

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

cmd/quota/bylabel.c - 1.2
	- sync code with that from util-linux patch.

cmd/xfs/db/Makefile - 1.53
	- add xfs_admin shell script.

cmd/xfs/db/uuid.c - 1.7
	- minor uuid tidying, extract some common code & provide a label
get/set
	  mechanism which shares it.

cmd/xfs/db/sb.c - 1.32
cmd/xfs/include/xfs_sb.h - 1.3
cmd/xfs/libxfs/xfs_mount.c - 1.3
cmd/xfs/repair/sb.c - 1.37
linux/fs/xfs/xfs_mount.c - 1.244
linux/fs/xfs/xfs_sb.h - 1.49
	- merge fpack and fname into one.

cmd/xfs/db/xfs_admin.sh - 1.1
cmd/xfs/man/man8/xfs_admin.8 - 1.1
	- xfs_db wrapper for getting and setting fs uuid and label.
useful for
	  versions of mount(8) which allow xfs to be mounted by
uuid/label.

From owner-linux-xfs@oss.sgi.com Thu Nov  9 13:18:01 2000
Received:  by oss.sgi.com id <S553834AbQKIVRv>;
	Thu, 9 Nov 2000 13:17:51 -0800
Received: from deliverator.sgi.com ([204.94.214.10]:50527 "EHLO
        deliverator.sgi.com") by oss.sgi.com with ESMTP id <S553652AbQKIVRb>;
	Thu, 9 Nov 2000 13:17:31 -0800
Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id NAA18807
	for <linux-xfs@oss.sgi.com>; Thu, 9 Nov 2000 13:09:40 -0800 (PST)
	mail_from (lord@jen.americas.sgi.com)
Received: from thistle-e185.americas.sgi.com (thistle-e185.americas.sgi.com [128.162.185.204]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id PAA5372960 for <linux-xfs@oss.sgi.com>; Thu, 9 Nov 2000 15:16:15 -0600 (CST)
Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.184.86]) by thistle-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id PAA34254 for <linux-xfs@oss.sgi.com>; Thu, 9 Nov 2000 15:16:15 -0600 (CST)
Received: (from lord@localhost)
	by jen.americas.sgi.com (8.9.3/8.9.3) id PAA12295
	for linux-xfs@oss.sgi.com; Thu, 9 Nov 2000 15:11:23 -0600
Date:   Thu, 9 Nov 2000 15:11:23 -0600
From:   Steve Lord <lord@sgi.com>
Message-Id: <200011092111.PAA12295@jen.americas.sgi.com>
Subject: TAKE - remove writeraw
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

During the merge of xfs into test9 we kept the writeraw concept which had
been removed. pagebuf was still using it, but there were problems, since
pagebuf has been recoded to correctly not use writeraw we can now remove
the code.

Date:  Thu Nov  9 13:14:53 PST 2000
Workarea:  jen.americas.sgi.com:/src/lord/xfs-linux.2.4

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


Modid:  2.4.x-xfs:slinx:77957a
linux/include/linux/fs.h - 1.69
linux/drivers/block/ll_rw_blk.c - 1.50
	- remove WRITERAW - we no longer need it



From owner-linux-xfs@oss.sgi.com Thu Nov  9 15:05:11 2000
Received:  by oss.sgi.com id <S554070AbQKIXEv>;
	Thu, 9 Nov 2000 15:04:51 -0800
Received: from deliverator.sgi.com ([204.94.214.10]:783 "EHLO
        deliverator.sgi.com") by oss.sgi.com with ESMTP id <S553675AbQKIXES>;
	Thu, 9 Nov 2000 15:04:18 -0800
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 OAA09173
	for <linux-xfs@oss.sgi.com>; Thu, 9 Nov 2000 14:56:25 -0800 (PST)
	mail_from (nathans@wobbly.melbourne.sgi.com)
Received: from wobbly.melbourne.sgi.com (wobbly.melbourne.sgi.com [134.14.55.135]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id KAA22118; Fri, 10 Nov 2000 10:02:58 +1100
Received: (from nathans@localhost) by wobbly.melbourne.sgi.com (980427.SGI.8.8.8/980728.SGI.AUTOCF) id KAA26556; Fri, 10 Nov 2000 10:02:56 +1100 (EDT)
From:   "Nathan Scott" <nathans@wobbly.melbourne.sgi.com>
Message-Id: <10011101002.ZM125821@wobbly.melbourne.sgi.com>
Date:   Fri, 10 Nov 2000 10:02:55 -0400
In-Reply-To: Scott Smyth <SSmyth@Connex.com>
        "RE: TAKE - xfs_admin" (Nov  9,  6:56am)
References: <B14BF8753E65D211ABCA00104B301EF5015A4CB8@cairn-gorm.cragtech.com>
X-Mailer: Z-Mail (3.2.3 08feb96 MediaMail)
To:     Scott Smyth <SSmyth@Connex.com>,
        "'linux-xfs@oss.sgi.com '" <linux-xfs@oss.sgi.com>
Subject: Re: TAKE - xfs_admin
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 Scott,

On Nov 9,  6:56am, Scott Smyth wrote:
> Subject: RE: TAKE - xfs_admin
> Yes, please.  Could you post the 2.10p+patch?
> 
> thanks, Scott
> 

you can grab it from this message...
http://oss.sgi.com/projects/linux-xfs/indexed/msg02238.html

cheers.

-- 
Nathan

From owner-linux-xfs@oss.sgi.com Thu Nov  9 16:06:40 2000
Received:  by oss.sgi.com id <S553808AbQKJAGV>;
	Thu, 9 Nov 2000 16:06:21 -0800
Received: from deliverator.sgi.com ([204.94.214.10]:32548 "EHLO
        deliverator.sgi.com") by oss.sgi.com with ESMTP id <S553705AbQKJAF6>;
	Thu, 9 Nov 2000 16:05:58 -0800
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 PAA19518
	for <linux-xfs@oss.sgi.com>; Thu, 9 Nov 2000 15:58:05 -0800 (PST)
	mail_from (nathans@wobbly.melbourne.sgi.com)
Received: from wobbly.melbourne.sgi.com (wobbly.melbourne.sgi.com [134.14.55.135]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id LAA22497; Fri, 10 Nov 2000 11:03:22 +1100
Received: (from nathans@localhost) by wobbly.melbourne.sgi.com (980427.SGI.8.8.8/980728.SGI.AUTOCF) id LAA86149; Fri, 10 Nov 2000 11:03:06 +1100 (EDT)
From:   "Nathan Scott" <nathans@wobbly.melbourne.sgi.com>
Message-Id: <10011101103.ZM113097@wobbly.melbourne.sgi.com>
Date:   Fri, 10 Nov 2000 11:03:05 -0400
In-Reply-To: Thomas Graichen <news-innominate.list.sgi.xfs@innominate.de>
        "stress test on ppc" (Nov  9,  2:33pm)
References: <news2mail-8uecj0$i5e$1@mate.bln.innominate.de>
X-Mailer: Z-Mail (3.2.3 08feb96 MediaMail)
To:     Thomas Graichen <graichen@innominate.de>,
        thomas.graichen@innominate.de
Subject: Re: stress test on ppc
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

hi Thomas,

On Nov 9,  2:33pm, Thomas Graichen wrote:
> Subject: stress test on ppc
> ...
> all in all it looks quite fine so far i think (my first stress
> test at all :-) ... one thing is not really clear to me: why
> it says "[not run] this test requires a valid $SCRATCH_DEV" if
> i have a valid scratchdev defined in the config.common file -
> any ideas (before i look into it)?

from a look at stress/common.rc i'd say your SCRATCH_DEV
is either failing the "_is_block_dev" call (which isn't
very clean - i'll checkin a new version in a second) or
your SCRATCH_DEV is the same as your TEST_DEV (which is
not allowed).

> 
> 001 28s ...
> 002 - output mismatch (see 002.out.bad)
> 2a3,21
> > 002: [: 2    : integer expression expected
> > 002: [: 3    : integer expression expected

can you send me the output from "sh -x 002"? - looks like
the lstat64 output/filtering is off with the pixies.

thanks.

-- 
Nathan

From owner-linux-xfs@oss.sgi.com Thu Nov  9 16:19:41 2000
Received:  by oss.sgi.com id <S553818AbQKJATV>;
	Thu, 9 Nov 2000 16:19:21 -0800
Received: from deliverator.sgi.com ([204.94.214.10]:64040 "EHLO
        deliverator.sgi.com") by oss.sgi.com with ESMTP id <S553744AbQKJATD>;
	Thu, 9 Nov 2000 16:19:03 -0800
Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.55.149]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id QAA21655
	for <linux-xfs@oss.sgi.com>; Thu, 9 Nov 2000 16:11:09 -0800 (PST)
	mail_from (nathans@snort.melbourne.sgi.com)
Received: (from nathans@localhost)
	by snort.melbourne.sgi.com (SGI-8.9.3/8.9.3) id LAA94782
	for linux-xfs@oss.sgi.com; Fri, 10 Nov 2000 11:16:16 +1100 (EST)
Date:   Fri, 10 Nov 2000 11:16:16 +1100 (EST)
From:   Nathan Scott <nathans@snort.melbourne.sgi.com>
Message-Id: <200011100016.LAA94782@snort.melbourne.sgi.com>
To:     linux-xfs@oss.sgi.com
Subject: TAKE - stress
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.4.x-xfs:slinx:77973a
Date:  Thu Nov  9 16:16:02 PST 2000
Workarea:  snort:/build4/nathans/quota-xfs
Author:  nathans

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

cmd/xfs/stress/common.rc - 1.39
	- tidy the check for a block device.


From owner-linux-xfs@oss.sgi.com Thu Nov  9 16:20:41 2000
Received:  by oss.sgi.com id <S554056AbQKJAUW>;
	Thu, 9 Nov 2000 16:20:22 -0800
Received: from usr-mtp-31.sensible-net.com ([208.18.226.31]:9220 "EHLO
        www.esplot.com") by oss.sgi.com with ESMTP id <S553812AbQKJAUU>;
	Thu, 9 Nov 2000 16:20:20 -0800
Received: from esplot.com (IDENT:jeffh@blast [192.180.82.4])
	by www.esplot.com (8.9.3/8.9.3) with ESMTP id TAA09752
	for <linux-xfs@oss.sgi.com>; Thu, 9 Nov 2000 19:20:04 -0500
Message-ID: <3A0B3FBC.4853C078@esplot.com>
Date:   Thu, 09 Nov 2000 19:22:20 -0500
From:   Jeff Hengesbach <jeffh@esplot.com>
X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.4.0-XFS-test9 i586)
X-Accept-Language: en
MIME-Version: 1.0
To:     linux-xfs@oss.sgi.com
Subject: Trouble Updating from CVS
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've tried a few times over the past few days to update my copy of the
source from cvs.  I have consistently received the following error:

.
.
.
cvs server: Updating linux-2.4-xfs/linux/scripts/cramfs
cvs server: Updating linux-2.4-xfs/linux/scripts/ksymoops
cvs server: Updating linux-2.4-xfs/linux/scripts/lxdialog
cvs [update aborted]: connect to penn.netroedge.com:2401 failed:
Connection refused

From owner-linux-xfs@oss.sgi.com Thu Nov  9 16:36:41 2000
Received:  by oss.sgi.com id <S554059AbQKJAgW>;
	Thu, 9 Nov 2000 16:36:22 -0800
Received: from deliverator.sgi.com ([204.94.214.10]:53294 "EHLO
        deliverator.sgi.com") by oss.sgi.com with ESMTP id <S553829AbQKJAgN>;
	Thu, 9 Nov 2000 16:36:13 -0800
Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id QAA24326
	for <linux-xfs@oss.sgi.com>; Thu, 9 Nov 2000 16:28:22 -0800 (PST)
	mail_from (cattelan@thebarn.com)
Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id SAA7572182; Thu, 9 Nov 2000 18:34:52 -0600 (CST)
Received: from gibble.americas.sgi.com (gibble.americas.sgi.com [128.162.195.80]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id SAA96545; Thu, 9 Nov 2000 18:34:51 -0600 (CST)
Received: from thebarn.com (localhost [127.0.0.1])
	by gibble.americas.sgi.com (8.11.0/8.10.1) with ESMTP id eAA0YpU06532;
	Thu, 9 Nov 2000 18:34:51 -0600
Message-ID: <3A0B42AA.9BE99B59@thebarn.com>
Date:   Thu, 09 Nov 2000 18:34:51 -0600
From:   Russell Cattelan <cattelan@thebarn.com>
X-Mailer: Mozilla 4.75 [en] (X11; U; Linux 2.4.0-XFS_BETA_3smp i686)
X-Accept-Language: en
MIME-Version: 1.0
To:     Jeff Hengesbach <jeffh@esplot.com>
CC:     linux-xfs@oss.sgi.com
Subject: Re: Trouble Updating from CVS
References: <3A0B3FBC.4853C078@esplot.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

Jeff Hengesbach wrote:

> I've tried a few times over the past few days to update my copy of the
> source from cvs.  I have consistently received the following error:
>
> .
> .
> .
> cvs server: Updating linux-2.4-xfs/linux/scripts/cramfs
> cvs server: Updating linux-2.4-xfs/linux/scripts/ksymoops
> cvs server: Updating linux-2.4-xfs/linux/scripts/lxdialog
> cvs [update aborted]: connect to penn.netroedge.com:2401 failed:
> Connection refused

Hold on I'll take a look.
Hmm nope every things seems fine from this end.


Can you ping oss.sgi.com ? better yet can you traceroute it?





From owner-linux-xfs@oss.sgi.com Thu Nov  9 16:42:41 2000
Received:  by oss.sgi.com id <S554061AbQKJAmb>;
	Thu, 9 Nov 2000 16:42:31 -0800
Received: from usr-mtp-31.sensible-net.com ([208.18.226.31]:16900 "EHLO
        www.esplot.com") by oss.sgi.com with ESMTP id <S554058AbQKJAmR>;
	Thu, 9 Nov 2000 16:42:17 -0800
Received: from esplot.com (IDENT:jeffh@blast [192.180.82.4])
	by www.esplot.com (8.9.3/8.9.3) with ESMTP id TAA09846;
	Thu, 9 Nov 2000 19:41:40 -0500
Message-ID: <3A0B44CC.45A38B19@esplot.com>
Date:   Thu, 09 Nov 2000 19:43:56 -0500
From:   Jeff Hengesbach <jeffh@esplot.com>
X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.4.0-XFS-test9 i586)
X-Accept-Language: en
MIME-Version: 1.0
To:     Russell Cattelan <cattelan@thebarn.com>
CC:     linux-xfs@oss.sgi.com
Subject: Re: Trouble Updating from CVS
References: <3A0B3FBC.4853C078@esplot.com> <3A0B42AA.9BE99B59@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:
> 
> Jeff Hengesbach wrote:
> 
> > I've tried a few times over the past few days to update my copy of the
> > source from cvs.  I have consistently received the following error:
> >
> > .
> > .
> > .
> > cvs server: Updating linux-2.4-xfs/linux/scripts/cramfs
> > cvs server: Updating linux-2.4-xfs/linux/scripts/ksymoops
> > cvs server: Updating linux-2.4-xfs/linux/scripts/lxdialog
> > cvs [update aborted]: connect to penn.netroedge.com:2401 failed:
> > Connection refused
> 
> Hold on I'll take a look.
> Hmm nope every things seems fine from this end.
> 
> Can you ping oss.sgi.com ? better yet can you traceroute it?

Ping - OK
Traceroute - OK 15 Hops

Using exact(cut and paste) instructions from web page:
setenv CVSROOT  :pserver:cvs@oss.sgi.com:/cvs   
cvs login
cvs
cvs -z3 update -d

From owner-linux-xfs@oss.sgi.com Thu Nov  9 19:50:51 2000
Received:  by oss.sgi.com id <S553757AbQKJDuc>;
	Thu, 9 Nov 2000 19:50:32 -0800
Received: from rmx325-mta.mail.com ([165.251.48.53]:23764 "EHLO
        rmx325-mta.mail.com") by oss.sgi.com with ESMTP id <S553752AbQKJDuF>;
	Thu, 9 Nov 2000 19:50:05 -0800
Received: from web651-mc (web651-mc.mail.com [165.251.48.100])
	by rmx325-mta.mail.com (8.9.3/8.9.3) with SMTP id WAA21081
	for <linux-xfs@oss.sgi.com>; Thu, 9 Nov 2000 22:49:53 -0500 (EST)
Message-ID: <384015606.973828138144.JavaMail.root@web651-mc>
Date:   Thu, 9 Nov 2000 22:48:58 -0500 (EST)
From:   a8d3f2d9 nmxb021 <a8d3f2d9nmxb021@nycmail.com>
To:     linux-xfs@oss.sgi.com
Subject: XFS on other OSes
Mime-Version: 1.0
Content-Type: text/plain
Content-Transfer-Encoding: 7bit
X-Mailer: mail.com
X-Originating-IP: 160.39.176.187
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing

Are there any plans (even the slightest consideration) of porting XFS to
other operating systems?  I had in mind ports to free systems like the BSDs,
and maybe to other Unices if there is any interest.  I know IBM's OpenAFS
has been ported to Digital Unix, Solaris, Linux, AIX (obviously) and even NT
but this is mostly because of commercial demand.  Are there any plans to
extend XFS's capabilities to, say, Free-, Open-, and NetBSD?  As far as I
know, those OSes do not have journaling file systems and could very well
benefit from XFS.

thank you

---------------------------------------------------
"a8d3f2d9nmxb021," he said.  "Naturally."
______________________________________________
FREE Personalized Email at Mail.com
Sign up at http://www.mail.com/?sr=signup

From owner-linux-xfs@oss.sgi.com Fri Nov 10 00:17:23 2000
Received:  by oss.sgi.com id <S553802AbQKJIRO>;
	Fri, 10 Nov 2000 00:17:14 -0800
Received: from plutonium.uunet.be ([194.7.1.47]:35334 "EHLO plutonium.uunet.be")
	by oss.sgi.com with ESMTP id <S553804AbQKJIQr>;
	Fri, 10 Nov 2000 00:16:47 -0800
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 JAA06696
	for <linux-xfs@oss.sgi.com>; Fri, 10 Nov 2000 09:16:45 +0100 (CET)
Received: from pcgx14500003.vum.be (pcgx14500003 [83.105.1.4]) by leonidas.vum.be with ESMTP (8.7.6/8.7.1) id JAA07274 for <linux-xfs@oss.sgi.com>; Fri, 10 Nov 2000 09:18:49 +0100 (MET)
Received: from vum.be (IDENT:kris@localhost.localdomain [127.0.0.1])
	by pcgx14500003.vum.be (8.9.3/8.8.7) with ESMTP id JAA25087
	for <linux-xfs@oss.sgi.com>; Fri, 10 Nov 2000 09:16:13 +0100
Message-ID: <3A0BAECC.3A8297F8@vum.be>
Date:   Fri, 10 Nov 2000 09:16:13 +0100
From:   kris buggenhout <gast6@vum.be>
X-Mailer: Mozilla 4.61 [en] (X11; I; Linux 2.4.0-test5 i686)
X-Accept-Language: en
MIME-Version: 1.0
To:     linux-xfs@oss.sgi.com
Subject: XFS on Ultra penguin ?
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: base64
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing

SSB3b3VsZCBsaWtlIHRvIHN0YXJ0IGFuIGVmZm9ydCB0byBnZXQgeGZzIG9uIGEgU1VOIFVF
MjUwICgyIGNwdSwgNTEyTWINCnJhbSA4IHggMThHIHNjc2kgZGlza3MpLA0KSSBnb3Qgc29t
ZSB0cm91YmxlIHRyeWluZyB0byBnZXQgaXQgdG8gY29tcGlsZS4uLiBidXQgd29ya2luZyBv
biBpdC4uLi4NCmlzIHRoZXJlIGFueWJvZHkgb3V0IHRoZXJlIHRoYXQgbGlrZXMgdG8gZG8g
dGhlIHNhbWUuLi4gbWlnaHQgY29tYmluZQ0Kb3VyIGVmZm9ydHMuLi4NCg0K

From owner-linux-xfs@oss.sgi.com Fri Nov 10 00:43:44 2000
Received:  by oss.sgi.com id <S553804AbQKJIne>;
	Fri, 10 Nov 2000 00:43:34 -0800
Received: from ifi.informatik.uni-stuttgart.de ([129.69.211.1]:2519 "EHLO
        ifi.informatik.uni-stuttgart.de") by oss.sgi.com with ESMTP
	id <S553779AbQKJInQ>; Fri, 10 Nov 2000 00:43:16 -0800
Received: from rock.informatik.uni-stuttgart.de (root@rock [129.69.215.43]) by ifi.informatik.uni-stuttgart.de (8.9.3/2.2) with ESMTP id JAA17506 for <linux-xfs@oss.sgi.com>; Fri, 10 Nov 2000 09:41:27 +0100 (MET)
Received: (from magallon@localhost) by rock.informatik.uni-stuttgart.de (8.9.3/2.2) id JAA13941; Fri, 10 Nov 2000 09:43:11 +0100
Date:   Fri, 10 Nov 2000 09:41:51 +0100
From:   "Marcelo E. Magallon" <marcelo.magallon@bigfoot.com>
To:     linux-xfs@oss.sgi.com
Subject: Re: stress test on ppc
Message-ID: <20001110094151.C333@ysabell>
Mail-Followup-To: linux-xfs@oss.sgi.com
References: <news2mail-8uecj0$i5e$1@mate.bln.innominate.de> <news-innominate.list.sgi.xfs@innominate.de> <10011101103.ZM113097@wobbly.melbourne.sgi.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <10011101103.ZM113097@wobbly.melbourne.sgi.com>; from nathans@wobbly.melbourne.sgi.com on Fri, Nov 10, 2000 at 11:03:05AM -0400
X-Operating-System: Linux ysabell 2.4.0-test10
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing

>> Nathan Scott <nathans@wobbly.melbourne.sgi.com> writes:

 > > > 002: [: 2    : integer expression expected
 > > > 002: [: 3    : integer expression expected
 > 
 > can you send me the output from "sh -x 002"? - looks like
 > the lstat64 output/filtering is off with the pixies.

 This is the bash related bug I reported a while ago (I do remember
 seeing it commited to the CVS tree)

Index: cmd/xfs/stress/002
===================================================================
RCS file: /cvs/linux-2.4-xfs/cmd/xfs/stress/002,v
retrieving revision 1.5
diff -u -r1.5 002
--- cmd/xfs/stress/002  2000/10/31 22:12:46     1.5
+++ cmd/xfs/stress/002  2000/11/10 08:34:40
@@ -64,7 +64,7 @@
 do
     ln $TEST_DIR/$tmp.1 $TEST_DIR/$tmp.$l
     x=`src/lstat64 $TEST_DIR/$tmp.1 | sed -n -e '/ Links: /s/.*Links: *//p'`
-    if [ "$l" -ne "$x" ]
+    if [ "$l" -ne $x ]
     then
        echo "Arrgh, created link #$l and lstat64 looks like ..."
        src/lstat64 $TEST_DIR/$tmp.1

 The problem is a POSIX sh doesn't care about the whitespace inside "$x"
 (something like "2  ") but bash (as /bin/sh) does.  At this point $x is
 not empty, if it is, something else went bonkers.

--
Marcelo


From owner-linux-xfs@oss.sgi.com Fri Nov 10 01:06:54 2000
Received:  by oss.sgi.com id <S554060AbQKJJGe>;
	Fri, 10 Nov 2000 01:06:34 -0800
Received: from plutonium.uunet.be ([194.7.1.47]:20997 "EHLO plutonium.uunet.be")
	by oss.sgi.com with ESMTP id <S553799AbQKJJGF>;
	Fri, 10 Nov 2000 01:06:05 -0800
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 KAA24904
	for <linux-xfs@oss.sgi.com>; Fri, 10 Nov 2000 10:06:03 +0100 (CET)
Received: from pcgx14500003.vum.be (pcgx14500003 [83.105.1.4]) by leonidas.vum.be with ESMTP (8.7.6/8.7.1) id KAA23092 for <linux-xfs@oss.sgi.com>; Fri, 10 Nov 2000 10:08:07 +0100 (MET)
Received: from vum.be (IDENT:kris@localhost.localdomain [127.0.0.1])
	by pcgx14500003.vum.be (8.9.3/8.8.7) with ESMTP id KAA25191
	for <linux-xfs@oss.sgi.com>; Fri, 10 Nov 2000 10:05:31 +0100
Message-ID: <3A0BBA5B.8533215C@vum.be>
Date:   Fri, 10 Nov 2000 10:05:31 +0100
From:   kris buggenhout <gast6@vum.be>
X-Mailer: Mozilla 4.61 [en] (X11; I; Linux 2.4.0-test5 i686)
X-Accept-Language: en
MIME-Version: 1.0
To:     linux-xfs@oss.sgi.com
Subject: Re: XFS on Ultra penguin ?
References: <3A0BAECC.3A8297F8@vum.be>
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: base64
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing

a3JpcyBidWdnZW5ob3V0IHdyb3RlOg0KDQo+IEkgd291bGQgbGlrZSB0byBzdGFydCBhbiBl
ZmZvcnQgdG8gZ2V0IHhmcyBvbiBhIFNVTiBVRTI1MCAoMiBjcHUsIDUxMk1iDQo+IHJhbSA4
IHggMThHIHNjc2kgZGlza3MpLA0KPiBJIGdvdCBzb21lIHRyb3VibGUgdHJ5aW5nIHRvIGdl
dCBpdCB0byBjb21waWxlLi4uIGJ1dCB3b3JraW5nIG9uIGl0Li4uLg0KPiBpcyB0aGVyZSBh
bnlib2R5IG91dCB0aGVyZSB0aGF0IGxpa2VzIHRvIGRvIHRoZSBzYW1lLi4uIG1pZ2h0IGNv
bWJpbmUNCj4gb3VyIGVmZm9ydHMuLi4NCg0KT2sgLi4uIEkgZ290IHVuZGVyIHdheSAuLi4g
dGhlIGtlcm5lbCBpcyBidWluZyBidWlsdCBub3cgLi4NCg0KQ2FuIEkgZXhwZWN0IHByb2Js
ZW1zLi4uIGl0IGlzIGEgNjQgYml0IG1hY2hpbmUgY29tcGlsZWQgd2l0aCBlZ2NzDQo2NGJp
dC4uLiBvciBzaG91bGQgSSB0cnkgdG8gZ2V0IHBybzY0IG9uIHRoYXQgc3BhcmMgbGludXgg
PyAuLi4NCg0K

From owner-linux-xfs@oss.sgi.com Fri Nov 10 01:07:04 2000
Received:  by oss.sgi.com id <S554064AbQKJJGy>;
	Fri, 10 Nov 2000 01:06:54 -0800
Received: from joy.cluon.priv.at ([141.201.109.42]:32262 "HELO
        pain.cluon.priv.at") by oss.sgi.com with SMTP id <S553799AbQKJJGo>;
	Fri, 10 Nov 2000 01:06:44 -0800
Received: by pain.cluon.priv.at (Postfix, from userid 1000)
	id EF604673C; Fri, 10 Nov 2000 10:06:35 +0100 (CET)
Date:   Fri, 10 Nov 2000 10:06:35 +0100
From:   Thomas 'Mike' Michlmayr <mike@cluon.priv.at>
To:     linux-xfs@oss.sgi.com
Subject: Re: XFS on Ultra penguin ?
Message-ID: <20001110100634.B6565@pain.cluon.priv.at>
References: <3A0BAECC.3A8297F8@vum.be>
Mime-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-md5;
	protocol="application/pgp-signature"; boundary="GRPZ8SYKNexpdSJ7"
User-Agent: Mutt/1.0.1i
In-Reply-To: <3A0BAECC.3A8297F8@vum.be>; from gast6@vum.be on Fri, Nov 10, 2000 at 09:16:13AM +0100
Organisation: Cluon Research Center
X-PGP-Key: finger -l mike@joy.cluon.priv.at
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing


--GRPZ8SYKNexpdSJ7
Content-Type: text/plain; charset=us-ascii

On Fri, Nov 10, 2000 at 09:16:13 +0100,
kris buggenhout <gast6@vum.be> wrote:
> I would like to start an effort to get xfs on a SUN UE250 (2 cpu, 512Mb
> ram 8 x 18G scsi disks),

i've compiled the CVS snapshot on sparc32, but it did hang quite soon after
reboot. but this could be a sparc32 breakage. i was not able to investigate
any further as i had to reuse the machine for other purposes.

> I got some trouble trying to get it to compile... but working on it....
> is there anybody out there that likes to do the same... might combine
> our efforts...

all i found was a missing define for O_DIRECT in include/asm-sparc/fcntl.h.
davem suggested in mail to use "#define O_DIRECT 0x80000".

-- 
Thomas 'Mike' Michlmayr  | ignorami: n: The BOFH art of folding problem 
<mike+sig@cluon.priv.at> |           lusers into representational shapes.


--GRPZ8SYKNexpdSJ7
Content-Type: application/pgp-signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.1 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iQCVAwUBOgu6mbAgSjtD8pUhAQF8rAQArBgtDeM8p7NaFrYDkGCNTrKfH0Y2gAlU
1JIYUARpGDXfECHjtzZTxvOJcdbfe0wr7FJYnzJ+IoNhnvAo58SFczpau45pCXQt
TAI4P/40ClSwHWivKXoTC9gQVRK3DoLrYKxCgCdmvJu/mh0N8zoeaZmbArqK79Wx
vUeL4LqBnyA=
=dXTP
-----END PGP SIGNATURE-----

--GRPZ8SYKNexpdSJ7--

From owner-linux-xfs@oss.sgi.com Fri Nov 10 02:17:15 2000
Received:  by oss.sgi.com id <S554069AbQKJKRE>;
	Fri, 10 Nov 2000 02:17:04 -0800
Received: from thorium.uunet.be ([194.7.1.46]:35343 "EHLO thorium.uunet.be")
	by oss.sgi.com with ESMTP id <S553810AbQKJKQg>;
	Fri, 10 Nov 2000 02:16:36 -0800
Received: from gate.vum.be (firewall.vum.be [194.7.240.162])
	by thorium.uunet.be (8.9.1/8.9.3) with SMTP id LAA21137
	for <linux-xfs@oss.sgi.com>; Fri, 10 Nov 2000 11:16:29 +0100 (CET)
Received: from pcgx14500003.vum.be (pcgx14500003 [83.105.1.4]) by leonidas.vum.be with ESMTP (8.7.6/8.7.1) id LAA14745 for <linux-xfs@oss.sgi.com>; Fri, 10 Nov 2000 11:18:32 +0100 (MET)
Received: from vum.be (IDENT:kris@localhost.localdomain [127.0.0.1])
	by pcgx14500003.vum.be (8.9.3/8.8.7) with ESMTP id LAA25285
	for <linux-xfs@oss.sgi.com>; Fri, 10 Nov 2000 11:15:56 +0100
Message-ID: <3A0BCADC.A002F575@vum.be>
Date:   Fri, 10 Nov 2000 11:15:56 +0100
From:   kris buggenhout <gast6@vum.be>
X-Mailer: Mozilla 4.61 [en] (X11; I; Linux 2.4.0-test5 i686)
X-Accept-Language: en
MIME-Version: 1.0
To:     "linux-xfs@oss.sgi.com" <linux-xfs@oss.sgi.com>
Subject: xfs on a sparc64
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: base64
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing

Y291bGQgdGhpcyBiZSByZWxhdGVkIHRvIDY0Yml0IHN0cnVjdHVyZSAuLi4NCg0KDQpwYWdl
X2J1Zl9pby5jOiBJbiBmdW5jdGlvbiBgcGFnZWJ1Zl9maWxlX3JlYWQnOg0KcGFnZV9idWZf
aW8uYzo2OTQ6IGBPX0RJUkVDVCcgdW5kZWNsYXJlZCAoZmlyc3QgdXNlIGluIHRoaXMgZnVu
Y3Rpb24pDQpwYWdlX2J1Zl9pby5jOjY5NDogKEVhY2ggdW5kZWNsYXJlZCBpZGVudGlmaWVy
IGlzIHJlcG9ydGVkIG9ubHkgb25jZQ0KcGFnZV9idWZfaW8uYzo2OTQ6IGZvciBlYWNoIGZ1
bmN0aW9uIGl0IGFwcGVhcnMgaW4uKQ0KcGFnZV9idWZfaW8uYzogSW4gZnVuY3Rpb24gYHBh
Z2VidWZfZ2VuZXJpY19maWxlX3JlYWQnOg0KcGFnZV9idWZfaW8uYzo4OTY6IGBPX0RJUkVD
VCcgdW5kZWNsYXJlZCAoZmlyc3QgdXNlIGluIHRoaXMgZnVuY3Rpb24pDQpwYWdlX2J1Zl9p
by5jOiBJbiBmdW5jdGlvbiBgX19wYl93cml0ZV9vcl9jb252ZXJ0X2JtYXAnOg0KcGFnZV9i
dWZfaW8uYzoxMTkzOiB3YXJuaW5nOiB1bnNpZ25lZCBpbnQgZm9ybWF0LCBkaWZmZXJlbnQg
dHlwZSBhcmcNCihhcmcgNCkNCg0K

From owner-linux-xfs@oss.sgi.com Fri Nov 10 03:02:14 2000
Received:  by oss.sgi.com id <S554072AbQKJLBz>;
	Fri, 10 Nov 2000 03:01:55 -0800
Received: from thorium.uunet.be ([194.7.1.46]:25356 "EHLO thorium.uunet.be")
	by oss.sgi.com with ESMTP id <S554067AbQKJLB0>;
	Fri, 10 Nov 2000 03:01:26 -0800
Received: from gate.vum.be (firewall.vum.be [194.7.240.162])
	by thorium.uunet.be (8.9.1/8.9.3) with SMTP id MAA11209
	for <linux-xfs@oss.sgi.com>; Fri, 10 Nov 2000 12:01:24 +0100 (CET)
Received: from pcgx14500003.vum.be (pcgx14500003 [83.105.1.4]) by leonidas.vum.be with ESMTP (8.7.6/8.7.1) id MAA23684 for <linux-xfs@oss.sgi.com>; Fri, 10 Nov 2000 12:03:27 +0100 (MET)
Received: from vum.be (IDENT:kris@localhost.localdomain [127.0.0.1])
	by pcgx14500003.vum.be (8.9.3/8.8.7) with ESMTP id MAA25388
	for <linux-xfs@oss.sgi.com>; Fri, 10 Nov 2000 12:00:52 +0100
Message-ID: <3A0BD564.1F6DFE89@vum.be>
Date:   Fri, 10 Nov 2000 12:00:52 +0100
From:   kris buggenhout <gast6@vum.be>
X-Mailer: Mozilla 4.61 [en] (X11; I; Linux 2.4.0-test5 i686)
X-Accept-Language: en
MIME-Version: 1.0
To:     linux-xfs@oss.sgi.com
Subject: Sparc linux compile problem...
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: base64
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing

SW4gZmlsZSBpbmNsdWRlZCBmcm9tIHhmcy5oOjEyNiwNCiAgICAgICAgICAgICAgICAgZnJv
bSB4ZnNydHN0dWJzLmM6MzM6DQpsaW51eC94ZnNfZ2xvYmFscy5oOjQ0OiBjb25mbGljdGlu
ZyB0eXBlcyBmb3IgYHhmc19wYW5pY19tYXNrJw0KeGZzX2Vycm9yLmg6MTM5OiBwcmV2aW91
cyBkZWNsYXJhdGlvbiBvZiBgeGZzX3BhbmljX21hc2snDQptYWtlWzJdOiAqKiogW3hmc3J0
c3R1YnMub10gRXJyb3IgMQ0KDQo=

From owner-linux-xfs@oss.sgi.com Fri Nov 10 05:09:37 2000
Received:  by oss.sgi.com id <S553827AbQKJNJ1>;
	Fri, 10 Nov 2000 05:09:27 -0800
Received: from deliverator.sgi.com ([204.94.214.10]:52332 "EHLO
        deliverator.sgi.com") by oss.sgi.com with ESMTP id <S553813AbQKJNJH>;
	Fri, 10 Nov 2000 05:09:07 -0800
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 FAA25210
	for <linux-xfs@oss.sgi.com>; Fri, 10 Nov 2000 05:01:15 -0800 (PST)
	mail_from (nathans@wobbly.melbourne.sgi.com)
Received: from wobbly.melbourne.sgi.com (wobbly.melbourne.sgi.com [134.14.55.135]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id AAA27361; Sat, 11 Nov 2000 00:06:34 +1100
Received: (from nathans@localhost) by wobbly.melbourne.sgi.com (980427.SGI.8.8.8/980728.SGI.AUTOCF) id AAA24796; Sat, 11 Nov 2000 00:06:32 +1100 (EDT)
From:   "Nathan Scott" <nathans@wobbly.melbourne.sgi.com>
Message-Id: <10011110006.ZM127189@wobbly.melbourne.sgi.com>
Date:   Sat, 11 Nov 2000 00:06:31 -0400
In-Reply-To: "Marcelo E. Magallon" <marcelo.magallon@bigfoot.com>
        "Re: stress test on ppc" (Nov 10,  9:41am)
References: <news2mail-8uecj0$i5e$1@mate.bln.innominate.de> 
	<news-innominate.list.sgi.xfs@innominate.de> 
	<10011101103.ZM113097@wobbly.melbourne.sgi.com> 
	<20001110094151.C333@ysabell>
X-Mailer: Z-Mail (3.2.3 08feb96 MediaMail)
To:     "Marcelo E. Magallon" <marcelo.magallon@bigfoot.com>,
        linux-xfs@oss.sgi.com
Subject: Re: stress test on ppc
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 Nov 10,  9:41am, Marcelo E. Magallon wrote:
> Subject: Re: stress test on ppc
> ...
>  This is the bash related bug I reported a while ago (I do remember
>  seeing it commited to the CVS tree)
> ...
>  The problem is a POSIX sh doesn't care about the whitespace inside "$x"
>  (something like "2  ") but bash (as /bin/sh) does.  At this point $x is
>  not empty, if it is, something else went bonkers.
> 

ah - I think I see whats happened - there's two -ne tests like
this & last time I only fixed one ... hopefully its fixed now
(as of two minutes ago).

thanks.

-- 
Nathan

From owner-linux-xfs@oss.sgi.com Fri Nov 10 05:48:07 2000
Received:  by oss.sgi.com id <S553828AbQKJNrr>;
	Fri, 10 Nov 2000 05:47:47 -0800
Received: from deliverator.sgi.com ([204.94.214.10]:57460 "EHLO
        deliverator.sgi.com") by oss.sgi.com with ESMTP id <S553785AbQKJNrX>;
	Fri, 10 Nov 2000 05:47:23 -0800
Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.55.149]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id FAA29392
	for <linux-xfs@oss.sgi.com>; Fri, 10 Nov 2000 05:39:30 -0800 (PST)
	mail_from (nathans@snort.melbourne.sgi.com)
Received: (from nathans@localhost)
	by snort.melbourne.sgi.com (SGI-8.9.3/8.9.3) id AAA82830
	for linux-xfs@oss.sgi.com; Sat, 11 Nov 2000 00:45:57 +1100 (EST)
Date:   Sat, 11 Nov 2000 00:45:57 +1100 (EST)
From:   Nathan Scott <nathans@snort.melbourne.sgi.com>
Message-Id: <200011101345.AAA82830@snort.melbourne.sgi.com>
To:     linux-xfs@oss.sgi.com
Subject: TAKE - sparc build
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 fix the build problem, Kris.

>From a look through the headers, it seems that for some architectures,
__uint64_t != uint64_t (one is a u long long, the other is just a u long).
we were declaring xfs_panic_mask both ways.  now we just use the one that
equates to __u64 on all architectures (uint64_t).

cheers.


Modid:  2.4.x-xfs:slinx:78005a
Date:  Fri Nov 10 05:42:26 PST 2000
Workarea:  snort:/build4/nathans/linux-xfs
Author:  nathans

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

linux/fs/xfs/xfs.h - 1.9
	- move include of globals.h above errors.h

linux/fs/xfs/xfs_error.h - 1.17
	- remove extern of xfs_panic_mask so there is only one.


From owner-linux-xfs@oss.sgi.com Fri Nov 10 07:09:57 2000
Received:  by oss.sgi.com id <S553838AbQKJPJs>;
	Fri, 10 Nov 2000 07:09:48 -0800
Received: from deliverator.sgi.com ([204.94.214.10]:34065 "EHLO
        deliverator.sgi.com") by oss.sgi.com with ESMTP id <S553821AbQKJPJa>;
	Fri, 10 Nov 2000 07:09:30 -0800
Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id HAA11612
	for <linux-xfs@oss.sgi.com>; Fri, 10 Nov 2000 07:01:39 -0800 (PST)
	mail_from (lord@jen.americas.sgi.com)
Received: from thistle-e185.americas.sgi.com (thistle-e185.americas.sgi.com [128.162.185.204]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id JAA7615654; Fri, 10 Nov 2000 09:08:12 -0600 (CST)
Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.184.86]) by thistle-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id JAA72657; Fri, 10 Nov 2000 09:08:12 -0600 (CST)
Received: from jen.americas.sgi.com (lord@localhost)
	by jen.americas.sgi.com (8.9.3/8.9.3) with ESMTP id JAA22312;
	Fri, 10 Nov 2000 09:03:12 -0600
Message-Id: <200011101503.JAA22312@jen.americas.sgi.com>
X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4
To:     a8d3f2d9 nmxb021 <a8d3f2d9nmxb021@nycmail.com>
cc:     linux-xfs@oss.sgi.com
Subject: Re: XFS on other OSes 
In-Reply-To: Message from a8d3f2d9 nmxb021 <a8d3f2d9nmxb021@nycmail.com> 
   of "Thu, 09 Nov 2000 22:48:58 EST." <384015606.973828138144.JavaMail.root@web651-mc> 
Date:   Fri, 10 Nov 2000 09:03:12 -0600
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

> Are there any plans (even the slightest consideration) of porting XFS to
> other operating systems?  I had in mind ports to free systems like the BSDs,
> and maybe to other Unices if there is any interest.  I know IBM's OpenAFS
> has been ported to Digital Unix, Solaris, Linux, AIX (obviously) and even NT
> but this is mostly because of commercial demand.  Are there any plans to
> extend XFS's capabilities to, say, Free-, Open-, and NetBSD?  As far as I
> know, those OSes do not have journaling file systems and could very well
> benefit from XFS.
> 
> thank you
> 


No internal plans - SGI has linux based products, hence our specific interest
in Linux. But since it is GPL, there is nothing stopping you from doing things
like this - unless you put the code places the GPL does not let you....

Steve



From owner-linux-xfs@oss.sgi.com Fri Nov 10 07:20:57 2000
Received:  by oss.sgi.com id <S554073AbQKJPUh>;
	Fri, 10 Nov 2000 07:20:37 -0800
Received: from deliverator.sgi.com ([204.94.214.10]:28181 "EHLO
        deliverator.sgi.com") by oss.sgi.com with ESMTP id <S553836AbQKJPUI>;
	Fri, 10 Nov 2000 07:20:08 -0800
Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id HAA13444
	for <linux-xfs@oss.sgi.com>; Fri, 10 Nov 2000 07:12:17 -0800 (PST)
	mail_from (lord@jen.americas.sgi.com)
Received: from thistle-e185.americas.sgi.com (thistle-e185.americas.sgi.com [128.162.185.204]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id JAA7623707; Fri, 10 Nov 2000 09:17:35 -0600 (CST)
Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.184.86]) by thistle-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id JAA79014; Fri, 10 Nov 2000 09:17:35 -0600 (CST)
Received: from jen.americas.sgi.com (lord@localhost)
	by jen.americas.sgi.com (8.9.3/8.9.3) with ESMTP id JAA22359;
	Fri, 10 Nov 2000 09:12:36 -0600
Message-Id: <200011101512.JAA22359@jen.americas.sgi.com>
X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4
To:     kris buggenhout <gast6@vum.be>
cc:     linux-xfs@oss.sgi.com,
        "Thomas 'Mike' Michlmayr" <mike@cluon.priv.at>
Subject: Re: XFS on Ultra penguin ? 
In-Reply-To: Message from kris buggenhout <gast6@vum.be> 
   of "Fri, 10 Nov 2000 09:16:13 +0100." <3A0BAECC.3A8297F8@vum.be> 
Date:   Fri, 10 Nov 2000 09:12:35 -0600
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 would like to start an effort to get xfs on a SUN UE250 (2 cpu, 512Mb
> ram 8 x 18G scsi disks),
> I got some trouble trying to get it to compile... but working on it....
> is there anybody out there that likes to do the same... might combine
> our efforts...

One aspect we have been warned about on the sparc is the fact that the
internal locking functions within xfs (see fs/xfs/linux/xfs_locks.c and
xfs_locks.h) is that we pass the saved interrupt state around on the
stack - which, I am told will not work on the sparc. It should be
possible to make these functions (sv_wait is the culprit) inline to
work around this. This may explain the sparc32 hang. I think some of the
code plays fast and loose with the type used to save the interrupt state,
it may not be big enough on some 64 bit platforms. 

Code like this is where it may be broken:

                spl = LOG_LOCK(log);
                if (!(iclog->ic_state == XLOG_STATE_ACTIVE ||
                      iclog->ic_state == XLOG_STATE_DIRTY)) {
                        if (!XLOG_FORCED_SHUTDOWN(log)) {
                                sv_wait(&iclog->ic_forcesema, PMEM,
                                        &log->l_icloglock, spl);
                        } else {
                                LOG_UNLOCK(log, spl);
                        }
                } else {
                        LOG_UNLOCK(log, spl);
                }

where LOG_LOCK is mutex_spinlock(&(log)->l_icloglock) which is

static __inline__ int mutex_spinlock(spinlock_t *l)
{
        long flags;
        spin_lock_irqsave(l, flags);
        return(flags);
}

and spl is declared as an int.

Steve
 


From owner-linux-xfs@oss.sgi.com Fri Nov 10 08:20:27 2000
Received:  by oss.sgi.com id <S553831AbQKJQUS>;
	Fri, 10 Nov 2000 08:20:18 -0800
Received: from perninha.conectiva.com.br ([200.250.58.156]:20232 "EHLO
        perninha.conectiva.com.br") by oss.sgi.com with ESMTP
	id <S553761AbQKJQUA>; Fri, 10 Nov 2000 08:20:00 -0800
Received: from freak.distro.conectiva (freak.distro.conectiva [10.0.17.22])
	by perninha.conectiva.com.br (8.9.3/8.9.3) with ESMTP id OAA21678;
	Fri, 10 Nov 2000 14:19:13 -0200
Date:   Fri, 10 Nov 2000 12:21:50 -0200 (BRST)
From:   Marcelo Tosatti <marcelo@conectiva.com.br>
X-Sender: marcelo@freak.distro.conectiva
To:     "Martin K. Petersen" <mkp@linuxcare.com>
cc:     linux-xfs@oss.sgi.com
Subject: LVM kiobuf code
Message-ID: <Pine.LNX.4.21.0011101220380.31061-100000@freak.distro.conectiva>
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 Martin,

Now I've got a bit of time to start looking at the kiobuf/md issues. 

Could you please send me your current kiobufized LVM code ?

Thanks! 


From owner-linux-xfs@oss.sgi.com Fri Nov 10 10:17:18 2000
Received:  by oss.sgi.com id <S554074AbQKJSRI>;
	Fri, 10 Nov 2000 10:17:08 -0800
Received: from deliverator.sgi.com ([204.94.214.10]:48992 "EHLO
        deliverator.sgi.com") by oss.sgi.com with ESMTP id <S553848AbQKJSQs>;
	Fri, 10 Nov 2000 10:16:48 -0800
Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id KAA20884
	for <linux-xfs@oss.sgi.com>; Fri, 10 Nov 2000 10:08:53 -0800 (PST)
	mail_from (cattelan@thebarn.com)
Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id MAA7608583 for <linux-xfs@oss.sgi.com>; Fri, 10 Nov 2000 12:14:12 -0600 (CST)
Received: from gibble.americas.sgi.com (gibble.americas.sgi.com [128.162.195.80]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id MAA69469 for <linux-xfs@oss.sgi.com>; Fri, 10 Nov 2000 12:14:12 -0600 (CST)
Received: from thebarn.com (localhost [127.0.0.1])
	by gibble.americas.sgi.com (8.11.0/8.10.1) with ESMTP id eAAIEBU21883
	for <linux-xfs@oss.sgi.com>; Fri, 10 Nov 2000 12:14:11 -0600
Message-ID: <3A0C3AF3.D518D705@thebarn.com>
Date:   Fri, 10 Nov 2000 12:14:11 -0600
From:   Russell Cattelan <cattelan@thebarn.com>
X-Mailer: Mozilla 4.75 [en] (X11; U; Linux 2.4.0-XFS_BETA_3smp i686)
X-Accept-Language: en
MIME-Version: 1.0
To:     linux-xfs@oss.sgi.com
Subject: [Fwd: TAKE - O_DIRECT on SPARC]
Content-Type: multipart/mixed;
 boundary="------------53E1DFF59430E9AA5406668B"
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.
--------------53E1DFF59430E9AA5406668B
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit



--------------53E1DFF59430E9AA5406668B
Content-Type: message/rfc822
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

Return-Path: <owner-slinx-xfs@cthulhu.engr.sgi.com>
Received: from deliverator.sgi.com (deliverator.sgi.com [204.94.214.10])
	by lips.borg.umn.edu (8.11.0/8.10.1) with ESMTP id eAAI4lR27699
	for <cattelan@thebarn.com>; Fri, 10 Nov 2000 12:04:47 -0600 (CST)
Received: from cthulhu.engr.sgi.com (cthulhu.engr.sgi.com [192.26.80.2]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id JAA18350; Fri, 10 Nov 2000 09:56:49 -0800 (PST)
	mail_from (owner-slinx-xfs@cthulhu.engr.sgi.com)
Received: (from majordomo-owner@localhost)
	by cthulhu.engr.sgi.com (SGI-8.9.3/8.9.3) id KAA25677
	for slinx-xfs-list; Fri, 10 Nov 2000 10:04:35 -0800 (PST)
Received: from sgi.com (sgi.engr.sgi.com [192.26.80.37])
	by cthulhu.engr.sgi.com (SGI-8.9.3/8.9.3) with ESMTP id KAA25874
	for <slinx-xfs@cthulhu.engr.sgi.com>; Fri, 10 Nov 2000 10:04:35 -0800 (PST)
Received: from tux.mkp.net (tux.mkp.net [130.225.60.11]) 
	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 KAA00999
	for <slinx-xfs@cthulhu.engr.sgi.com>; Fri, 10 Nov 2000 10:04:15 -0800 (PST)
	mail_from (mkp@mkp.net)
Received: from tux.mkp.net ([130.225.60.11] helo=jaguar.mkp.net)
	by tux.mkp.net with esmtp (Exim 3.14 #2)
	id 13uIO6-0003I7-00; Fri, 10 Nov 2000 18:54:55 +0100
Received: (from mkp@localhost)
	by jaguar.mkp.net (8.9.3/8.9.3) id NAA17927;
	Fri, 10 Nov 2000 13:03:57 -0500
X-Authentication-Warning: jaguar.mkp.net: mkp set sender to mkp@mkp.net using -f
To: slinx-xfs@cthulhu.engr.sgi.com
Subject: TAKE - O_DIRECT on SPARC
From: "Martin K. Petersen" <mkp@linuxcare.com>
Organization: Linuxcare, Inc.
Date: 10 Nov 2000 13:03:57 -0500
Message-ID: <yq1vgtv3drm.fsf@jaguar.mkp.net>
User-Agent: Gnus/5.0807 (Gnus v5.8.7) XEmacs/21.1 (Canyonlands)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: owner-slinx-xfs@cthulhu.engr.sgi.com
Precedence: bulk


Date:  Fri Nov 10 10:01:04 PST 2000
Workarea:  sshgate.corp.sgi.com:/home/mkp/XFS/slinx-odirect

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


Modid:  2.4.x-xfs:slinx:78018a
linux/include/asm-sparc64/fcntl.h - 1.9
http://gibble.americas.sgi.com/cgi-bin/cvsweb.cgi/slinx_2.4.x-xfs-nodel/linux/include/asm-sparc64/fcntl.h.diff?r1=text&tr1=1.9&r2=text&tr2=1.8&f=h
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/linux/include/asm-sparc64/fcntl.h.diff?r1=text&tr1=1.9&r2=text&tr2=1.8&f=h
linux/include/asm-sparc/fcntl.h - 1.9
http://gibble.americas.sgi.com/cgi-bin/cvsweb.cgi/slinx_2.4.x-xfs-nodel/linux/include/asm-sparc/fcntl.h.diff?r1=text&tr1=1.9&r2=text&tr2=1.8&f=h
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/linux/include/asm-sparc/fcntl.h.diff?r1=text&tr1=1.9&r2=text&tr2=1.8&f=h
        - Add O_DIRECT to SPARC headers

FWIW, XFS on UltraSPARC survives a dbench 64 now.  More fixes coming
this weekend.

And now back to ll_rw_block fun.

-- 
Martin K. Petersen, Principal Linux Consultant, Linuxcare, Inc.
mkp@linuxcare.com, http://www.linuxcare.com/
Linuxcare. Moving Forward.

--------------53E1DFF59430E9AA5406668B--


From owner-linux-xfs@oss.sgi.com Fri Nov 10 11:23:28 2000
Received:  by oss.sgi.com id <S554082AbQKJTXI>;
	Fri, 10 Nov 2000 11:23:08 -0800
Received: from deliverator.sgi.com ([204.94.214.10]:53116 "EHLO
        deliverator.sgi.com") by oss.sgi.com with ESMTP id <S554077AbQKJTXA>;
	Fri, 10 Nov 2000 11:23:00 -0800
Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id LAA04388
	for <linux-xfs@oss.sgi.com>; Fri, 10 Nov 2000 11:15:09 -0800 (PST)
	mail_from (lord@jen.americas.sgi.com)
Received: from thistle-e185.americas.sgi.com (thistle-e185.americas.sgi.com [128.162.185.204]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id NAA7584202 for <linux-xfs@oss.sgi.com>; Fri, 10 Nov 2000 13:20:28 -0600 (CST)
Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.184.86]) by thistle-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id NAA06459 for <linux-xfs@oss.sgi.com>; Fri, 10 Nov 2000 13:20:28 -0600 (CST)
Received: (from lord@localhost)
	by jen.americas.sgi.com (8.9.3/8.9.3) id NAA26847
	for linux-xfs@oss.sgi.com; Fri, 10 Nov 2000 13:15:27 -0600
Date:   Fri, 10 Nov 2000 13:15:27 -0600
From:   Steve Lord <lord@sgi.com>
Message-Id: <200011101915.NAA26847@jen.americas.sgi.com>
Subject: TAKE - small pagebuf cleanup
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

Date:  Fri Nov 10 11:20:04 PST 2000
Workarea:  jen.americas.sgi.com:/src/lord/xfs-linux.2.4

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


Modid:  2.4.x-xfs:slinx:78025a
linux/fs/pagebuf/page_buf.c - 1.42
	- Clean up buffer head I/O path in pagebuf - there are double sets of
	  the buffer flags in here, plus memory leaks on error.



From owner-linux-xfs@oss.sgi.com Fri Nov 10 12:28:49 2000
Received:  by oss.sgi.com id <S553852AbQKJU23>;
	Fri, 10 Nov 2000 12:28:29 -0800
Received: from hermes.mixx.net ([212.84.196.2]:32518 "HELO hermes.mixx.net")
	by oss.sgi.com with SMTP id <S553833AbQKJU2L>;
	Fri, 10 Nov 2000 12:28:11 -0800
Received: from mate.bln.innominate.de (cerberus.berlin.innominate.de [212.84.234.251])
	by hermes.mixx.net (Postfix) with ESMTP
	id EEBA1F80D; Fri, 10 Nov 2000 21:28:08 +0100 (CET)
Received: from h2o.bln.innominate.de (h2o.bln.innominate.de [10.0.0.69])
	by mate.bln.innominate.de (Postfix) with ESMTP
	id A36CA2CA6E; Fri, 10 Nov 2000 21:28:08 +0100 (CET)
Received: by h2o.bln.innominate.de (Postfix, from userid 502)
	id 44398201054; Fri, 10 Nov 2000 21:28:08 +0100 (CET)
Date:   Fri, 10 Nov 2000 21:28:08 +0100
From:   Thomas Graichen <thomas.graichen@innominate.com>
To:     Nathan Scott <nathans@wobbly.melbourne.sgi.com>
Cc:     linux-xfs@oss.sgi.com
Subject: Re: stress test on ppc
Message-ID: <20001110212807.C19347@innominate.com>
References: <news2mail-8uecj0$i5e$1@mate.bln.innominate.de> <news-innominate.list.sgi.xfs@innominate.de> <10011101103.ZM113097@wobbly.melbourne.sgi.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2i
In-Reply-To: <10011101103.ZM113097@wobbly.melbourne.sgi.com>; from nathans@wobbly.melbourne.sgi.com on Fri, Nov 10, 2000 at 11:03:05AM -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 Fri, Nov 10, 2000 at 11:03:05AM -0400, Nathan Scott wrote:
> hi Thomas,
> 
> On Nov 9,  2:33pm, Thomas Graichen wrote:
> > Subject: stress test on ppc
> > ...
> > all in all it looks quite fine so far i think (my first stress
> > test at all :-) ... one thing is not really clear to me: why
> > it says "[not run] this test requires a valid $SCRATCH_DEV" if
> > i have a valid scratchdev defined in the config.common file -
> > any ideas (before i look into it)?
> 
> from a look at stress/common.rc i'd say your SCRATCH_DEV
> is either failing the "_is_block_dev" call (which isn't
> very clean - i'll checkin a new version in a second) or
> your SCRATCH_DEV is the same as your TEST_DEV (which is
> not allowed).

no it's a different one - so it must be the first - will try your
new stuff on monday

> > 001 28s ...
> > 002 - output mismatch (see 002.out.bad)
> > 2a3,21
> > > 002: [: 2    : integer expression expected
> > > 002: [: 3    : integer expression expected
> 
> can you send me the output from "sh -x 002"? - looks like
> the lstat64 output/filtering is off with the pixies.

will do this on monday too - i'm at home right now

t

p.s.: also this machine is now running XFS / and is still up :-)

-- 
thomas.graichen@innominate.com
technical director                                       innominate AG
clustering & security                             the linux architects
tel: +49-30-308806-13   fax: -77             http://www.innominate.com

From owner-linux-xfs@oss.sgi.com Fri Nov 10 13:01:18 2000
Received:  by oss.sgi.com id <S553855AbQKJVBJ>;
	Fri, 10 Nov 2000 13:01:09 -0800
Received: from tux.mkp.net ([130.225.60.11]:28687 "EHLO tux.mkp.net")
	by oss.sgi.com with ESMTP id <S553851AbQKJVAy>;
	Fri, 10 Nov 2000 13:00:54 -0800
Received: from tux.mkp.net ([130.225.60.11] helo=jaguar.mkp.net)
	by tux.mkp.net with esmtp (Exim 3.14 #2)
	id 13uL97-0003Om-00; Fri, 10 Nov 2000 21:51:37 +0100
Received: (from mkp@localhost)
	by jaguar.mkp.net (8.9.3/8.9.3) id QAA17957;
	Fri, 10 Nov 2000 16:00:43 -0500
X-Authentication-Warning: jaguar.mkp.net: mkp set sender to mkp@mkp.net using -f
To:     kris buggenhout <gast6@vum.be>
Cc:     "linux-xfs@oss.sgi.com" <linux-xfs@oss.sgi.com>
Subject: Re: xfs on a sparc64
References: <3A0BCADC.A002F575@vum.be>
From:   "Martin K. Petersen" <mkp@linuxcare.com>
Organization: Linuxcare, Inc.
Date:   10 Nov 2000 16:00:43 -0500
In-Reply-To: kris buggenhout's message of "Fri, 10 Nov 2000 11:15:56 +0100"
Message-ID: <yq1itpv35l0.fsf@jaguar.mkp.net>
Lines:  15
User-Agent: Gnus/5.0807 (Gnus v5.8.7) XEmacs/21.1 (Canyonlands)
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

>>>>> "kris" == kris buggenhout <gast6@vum.be> writes:

kris> could this be related to 64bit structure ...  page_buf_io.c: In
kris> function `pagebuf_file_read': page_buf_io.c:694: `O_DIRECT'

Fixed.  SPARC should compile fine now.

Please note that you need to create your file system with -bsize=8k
because SPARCs use 8KB pages.

-- 
Martin K. Petersen, Principal Linux Consultant, Linuxcare, Inc.
mkp@linuxcare.com, http://www.linuxcare.com/
Linuxcare. Moving Forward.


From owner-linux-xfs@oss.sgi.com Fri Nov 10 13:20:49 2000
Received:  by oss.sgi.com id <S553861AbQKJVUj>;
	Fri, 10 Nov 2000 13:20:39 -0800
Received: from hermes.mixx.net ([212.84.196.2]:1544 "HELO hermes.mixx.net")
	by oss.sgi.com with SMTP id <S553854AbQKJVUS>;
	Fri, 10 Nov 2000 13:20:18 -0800
Received: from mate.bln.innominate.de (cerberus.berlin.innominate.de [212.84.234.251])
	by hermes.mixx.net (Postfix) with ESMTP id 21A6EF811
	for <linux-xfs@oss.sgi.com>; Fri, 10 Nov 2000 22:20:16 +0100 (CET)
Received: by mate.bln.innominate.de (Postfix, from userid 9)
	id CB7302CA6E; Fri, 10 Nov 2000 22:20:15 +0100 (CET)
From:   Thomas Graichen <news-innominate.list.sgi.xfs@innominate.de>
Reply-To: Thomas Graichen <graichen@innominate.de>
X-Newsgroups: innominate.list.sgi.xfs
Subject: Re: TAKE - sparc build
Date:   10 Nov 2000 21:20:15 GMT
Organization: innominate AG, Berlin, Germany
Lines:  88
Distribution: local
Message-ID: <news2mail-8uhoqf$fhg$2@mate.bln.innominate.de>
References: <200011101345.AAA82830@snort.melbourne.sgi.com>
Reply-To: thomas.graichen@innominate.de
X-Trace: mate.bln.innominate.de 973891215 15920 10.0.0.69 (10 Nov 2000 21:20:15 GMT)
X-Complaints-To: news@innominate.de
User-Agent: tin/1.4.2-20000205 ("Possession") (UNIX) (Linux/2.4.0-XFS-test10 (i586))
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

this one also was one of the compile problems i saw on the alpha - which
is fixed now - i there also get:

gcc -D__KERNEL__ -I/usr/src/xfs/linux/include -Wall -Wstrict-prototypes -O2 -fno-strict-aliasing -fomit-frame-pointer -pipe -mno-fp-regs -ffixed-8 -mcpu=ev56 -Wa,-mev6 -DMODULE -g3 -Wno-unused  -Wno-parentheses -Wno-uninitialized -I. -funsigned-char  -Wno-unknown-pragmas -DDEBUG -DXFSDEBUG  -c -o xfs_error.o xfs_error.c
xfs_error.c:169: conflicting types for `xfs_errortag_clearall_umount'
xfs_error.h:123: previous declaration of `xfs_errortag_clearall_umount'
xfs_error.c:233: conflicting types for `xfs_cmn_err'
xfs_error.h:141: previous declaration of `xfs_cmn_err'

which i fixed with

diff -u -r1.17 xfs_error.h
--- xfs_error.h	2000/11/10 13:42:26	1.17
+++ xfs_error.h	2000/11/10 21:14:25
@@ -119,7 +119,7 @@
 int		xfs_errortag_clear(int error_tag, int fd);
 
 int		xfs_errortag_clearall(int fd);
-int		xfs_errortag_clearall_umount(__int64_t fsid, char *fsname,
+int		xfs_errortag_clearall_umount(int64_t fsid, char *fsname,
 						int loud);
 #else
 #define XFS_TEST_ERROR(expr, mp, tag, rf)	(expr)
@@ -137,7 +137,7 @@
 
 struct xfs_mount;
 /* PRINTFLIKE4 */
-void		xfs_cmn_err(__uint64_t panic_tag, int level, struct xfs_mount *mp,
+void		xfs_cmn_err(uint64_t panic_tag, int level, struct xfs_mount *mp, 			    char *fmt, ...);
 /* PRINTFLIKE3 */
 void		xfs_fs_cmn_err(int level, struct xfs_mount *mp, char *fmt, ...);

... which i hope is the right way around ... XFS now also builds again
on the alpha - will try how well it works on monday then i'm at work
again

will go to bed now ... maybe someone here has an idea about the
following on the alpha then building the tools at just looking
at the messages ...?

=== libattr ===
gcc -g -DDEBUG -funsigned-char -Wall -Wno-parentheses  '-DVERSION="1.0.6-0"' -I../include -D_FILE_OFFSET_BITS=64 -D_GNU_SOURCE -DXFS_BIG_FILES=1 -DXFS_BIG_FILESYSTEMS=1   -c -o attr.o attr.c
attr.c: In function `_attr_get':
attr.c:79: warning: type mismatch in implicit declaration for built-in function `memset'
attr.c: At top level:
attr.c:279: parse error before `_attrctl'
attr.c:279: warning: type defaults to `int' in declaration of `_syscall4'
attr.c: In function `attrctl':
attr.c:284: warning: implicit declaration of function `_attrctl'
attr.c: At top level:
attr.c:279: warning: `_syscall4' declared `static' but never defined
make[1]: *** [attr.o] Error 1
make: *** [default] Error 2
root@cyan:/usr/src/xfs/cmd/xfs#

t

Nathan Scott <nathans@snort.melbourne.sgi.com> wrote:
> This should fix the build problem, Kris.

>>From a look through the headers, it seems that for some architectures,
> __uint64_t != uint64_t (one is a u long long, the other is just a u long).
> we were declaring xfs_panic_mask both ways.  now we just use the one that
> equates to __u64 on all architectures (uint64_t).

> cheers.


> Modid:  2.4.x-xfs:slinx:78005a
> Date:  Fri Nov 10 05:42:26 PST 2000
> Workarea:  snort:/build4/nathans/linux-xfs
> Author:  nathans

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

> linux/fs/xfs/xfs.h - 1.9
> 	- move include of globals.h above errors.h

> linux/fs/xfs/xfs_error.h - 1.17
> 	- remove extern of xfs_panic_mask so there is only one.


-- 
thomas.graichen@innominate.com
technical director                                       innominate AG
clustering & security                             the linux architects
tel: +49-30-308806-13   fax: -77             http://www.innominate.com

From owner-linux-xfs@oss.sgi.com Fri Nov 10 13:21:49 2000
Received:  by oss.sgi.com id <S553871AbQKJVV3>;
	Fri, 10 Nov 2000 13:21:29 -0800
Received: from hermes.mixx.net ([212.84.196.2]:4104 "HELO hermes.mixx.net")
	by oss.sgi.com with SMTP id <S553870AbQKJVVR>;
	Fri, 10 Nov 2000 13:21:17 -0800
Received: from mate.bln.innominate.de (cerberus.berlin.innominate.de [212.84.234.251])
	by hermes.mixx.net (Postfix) with ESMTP id 087B3F811
	for <linux-xfs@oss.sgi.com>; Fri, 10 Nov 2000 22:21:15 +0100 (CET)
Received: by mate.bln.innominate.de (Postfix, from userid 9)
	id C34902CA6E; Fri, 10 Nov 2000 22:21:13 +0100 (CET)
From:   Thomas Graichen <news-innominate.list.sgi.xfs@innominate.de>
Reply-To: Thomas Graichen <graichen@innominate.de>
X-Newsgroups: innominate.list.sgi.xfs
Subject: Re: xfs on a sparc64
Date:   10 Nov 2000 21:21:11 GMT
Organization: innominate AG, Berlin, Germany
Lines:  21
Distribution: local
Message-ID: <news2mail-8uhos7$fhg$3@mate.bln.innominate.de>
References: <3A0BCADC.A002F575@vum.be> <yq1itpv35l0.fsf@jaguar.mkp.net>
Reply-To: thomas.graichen@innominate.de
X-Trace: mate.bln.innominate.de 973891271 15920 10.0.0.69 (10 Nov 2000 21:21:11 GMT)
X-Complaints-To: news@innominate.de
User-Agent: tin/1.4.2-20000205 ("Possession") (UNIX) (Linux/2.4.0-XFS-test10 (i586))
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

"Martin K. Petersen" <mkp@linuxcare.com> wrote:
>>>>>> "kris" == kris buggenhout <gast6@vum.be> writes:

> kris> could this be related to 64bit structure ...  page_buf_io.c: In
> kris> function `pagebuf_file_read': page_buf_io.c:694: `O_DIRECT'

> Fixed.  SPARC should compile fine now.

> Please note that you need to create your file system with -bsize=8k
> because SPARCs use 8KB pages.

which i assume i have to take care of on the alpha too (which
also has 8k pages)?

t

-- 
thomas.graichen@innominate.com
technical director                                       innominate AG
clustering & security                             the linux architects
tel: +49-30-308806-13   fax: -77             http://www.innominate.com

From owner-linux-xfs@oss.sgi.com Fri Nov 10 13:31:08 2000
Received:  by oss.sgi.com id <S553876AbQKJVas>;
	Fri, 10 Nov 2000 13:30:48 -0800
Received: from deliverator.sgi.com ([204.94.214.10]:1075 "EHLO
        deliverator.sgi.com") by oss.sgi.com with ESMTP id <S553870AbQKJVal>;
	Fri, 10 Nov 2000 13:30:41 -0800
Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id NAA28334
	for <linux-xfs@oss.sgi.com>; Fri, 10 Nov 2000 13:22:50 -0800 (PST)
	mail_from (lord@jen.americas.sgi.com)
Received: from thistle-e185.americas.sgi.com (thistle-e185.americas.sgi.com [128.162.185.204]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id PAA7612403; Fri, 10 Nov 2000 15:28:05 -0600 (CST)
Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.184.86]) by thistle-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id PAA11491; Fri, 10 Nov 2000 15:28:05 -0600 (CST)
Received: from jen.americas.sgi.com (lord@localhost)
	by jen.americas.sgi.com (8.9.3/8.9.3) with ESMTP id PAA30359;
	Fri, 10 Nov 2000 15:23:03 -0600
Message-Id: <200011102123.PAA30359@jen.americas.sgi.com>
X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4
To:     Thomas Graichen <graichen@innominate.de>,
        thomas.graichen@innominate.de
cc:     linux-xfs@oss.sgi.com
Subject: Re: xfs on a sparc64 
In-Reply-To: Message from Thomas Graichen <news-innominate.list.sgi.xfs@innominate.de> 
   of "10 Nov 2000 21:21:11 GMT." <news2mail-8uhos7$fhg$3@mate.bln.innominate.de> 
Date:   Fri, 10 Nov 2000 15:23:03 -0600
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

> "Martin K. Petersen" <mkp@linuxcare.com> wrote:
> >>>>>> "kris" == kris buggenhout <gast6@vum.be> writes:
> 
> > kris> could this be related to 64bit structure ...  page_buf_io.c: In
> > kris> function `pagebuf_file_read': page_buf_io.c:694: `O_DIRECT'
> 
> > Fixed.  SPARC should compile fine now.
> 
> > Please note that you need to create your file system with -bsize=8k
> > because SPARCs use 8KB pages.
> 
> which i assume i have to take care of on the alpha too (which
> also has 8k pages)?
> 
> t
> 


Yes - this is a pagebuf restriction at the moment, the filesystem blocksize is
tied to the page size of the system. This will get fixed eventually, supporting
blocksizes less than the pagesize is one task which is just a matter of
code within XFS and pagebuf. Supporting block sizes larger than a page is
harder as we really need a guaranteed and cheap way of allocating kernel
memory in chunks bigger than a page - or of making multiple pages look
contiguous in the kernel. There is code in there right now to remap the
memory, but it is not deemed an acceptable solution.

Steve



From owner-linux-xfs@oss.sgi.com Sat Nov 11 18:45:55 2000
Received:  by oss.sgi.com id <S553883AbQKLCpp>;
	Sat, 11 Nov 2000 18:45:45 -0800
Received: from 24.68.55.24.on.wave.home.com ([24.68.55.24]:25842 "EHLO
        picasso.visualfx.org") by oss.sgi.com with ESMTP id <S553832AbQKLCpa>;
	Sat, 11 Nov 2000 18:45:30 -0800
Received: from acm.org (IDENT:root@localhost [127.0.0.1])
	by picasso.visualfx.org (8.9.3/8.9.3) with ESMTP id VAA00870
	for <linux-xfs@oss.sgi.com>; Sat, 11 Nov 2000 21:45:17 -0500
Message-ID: <3A0E043D.17F7890@acm.org>
Date:   Sat, 11 Nov 2000 21:45:17 -0500
From:   Andrew Ho <andrwho@acm.org>
X-Mailer: Mozilla 4.72 [en] (X11; U; Linux 2.4.0-test5 i686)
X-Accept-Language: en
MIME-Version: 1.0
To:     linux-xfs@oss.sgi.com
Subject: CVS Server lockup
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

Please find the following message from oss cvs server.

cvs server: failed to create lock directory in repository
`/cvs/linux-2.4-xfs': Permission denied
cvs server: failed to obtain dir lock in repository `/cvs/linux-2.4-xfs'

cvs [server aborted]: read lock failed - giving up

Thanks,

Andrew Ho



From owner-linux-xfs@oss.sgi.com Sat Nov 11 23:35:37 2000
Received:  by oss.sgi.com id <S553894AbQKLHf1>;
	Sat, 11 Nov 2000 23:35:27 -0800
Received: from nic-31-c12-053.mn.mediaone.net ([24.31.12.53]:15631 "EHLO
        lupo.thebarn.com") by oss.sgi.com with ESMTP id <S553878AbQKLHfK>;
	Sat, 11 Nov 2000 23:35:10 -0800
Received: from thebarn.com (localhost [127.0.0.1])
	by lupo.thebarn.com (8.11.0/8.11.0) with ESMTP id eAC7YRj05955;
	Sun, 12 Nov 2000 01:34:28 -0600 (CST)
	(envelope-from cattelan@thebarn.com)
Message-ID: <3A0E4803.10B78A5E@thebarn.com>
Date:   Sun, 12 Nov 2000 01:34:27 -0600
From:   Russell Cattelan <cattelan@thebarn.com>
Reply-To: cattelan@thebarn.com
X-Mailer: Mozilla 4.74 [en] (X11; U; Linux 2.2.12 i386)
X-Accept-Language: en
MIME-Version: 1.0
To:     Andrew Ho <andrwho@acm.org>
CC:     linux-xfs@oss.sgi.com
Subject: Re: CVS Server lockup
References: <3A0E043D.17F7890@acm.org>
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

Andrew Ho wrote:

> Please find the following message from oss cvs server.
>
> cvs server: failed to create lock directory in repository
> `/cvs/linux-2.4-xfs': Permission denied
> cvs server: failed to obtain dir lock in repository `/cvs/linux-2.4-xfs'
>
> cvs [server aborted]: read lock failed - giving up
>
> Thanks,
>
> Andrew Ho

I fixed this earlier today... try it again.

Let me know if it still fails.


--
Russell Cattelan
cattelan@thebarn.com




From owner-linux-xfs@oss.sgi.com Sun Nov 12 09:31:52 2000
Received:  by oss.sgi.com id <S553924AbQKLRbm>;
	Sun, 12 Nov 2000 09:31:42 -0800
Received: from mailgw1.netvision.net.il ([194.90.1.14]:46801 "EHLO
        mailgw1.netvision.net.il") by oss.sgi.com with ESMTP
	id <S553896AbQKLRba>; Sun, 12 Nov 2000 09:31:30 -0800
Received: from exanet.co.il (exanetmc-ISDN.fix.netvision.net.il [212.143.119.85])
	by mailgw1.netvision.net.il (8.9.3/8.9.3) with ESMTP id TAA04910
	for <linux-xfs@oss.sgi.com>; Sun, 12 Nov 2000 19:31:27 +0200 (IST)
Message-ID: <3A0F6056.D2C91E0B@exanet.co.il>
Date:   Sun, 12 Nov 2000 19:30:30 -0800
From:   Robert Hofner <robert@exanet.co.il>
X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To:     linux-xfs@oss.sgi.com
Subject: Questions about the status of XFS
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,

Are there any news regarding the availability (and functionality) of XFS
on Compaq Alpha machines ?
The release caveats states that  "specifying O_SYNC on open will not
have the desired effect.". Does XFS ignores other synchronous operation
? Is O_SYNC only ignored or also discard (so that the kernel doesn't
know about the existence of this flag at all ?).

Thanks in advance,

Robert


From owner-linux-xfs@oss.sgi.com Sun Nov 12 23:17:47 2000
Received:  by oss.sgi.com id <S553964AbQKMHRh>;
	Sun, 12 Nov 2000 23:17:37 -0800
Received: from hermes.mixx.net ([212.84.196.2]:16652 "HELO hermes.mixx.net")
	by oss.sgi.com with SMTP id <S553959AbQKMHRO>;
	Sun, 12 Nov 2000 23:17:14 -0800
Received: from mate.bln.innominate.de (cerberus.berlin.innominate.de [212.84.234.251])
	by hermes.mixx.net (Postfix) with ESMTP id 7FB10F802
	for <linux-xfs@oss.sgi.com>; Mon, 13 Nov 2000 08:17:11 +0100 (CET)
Received: by mate.bln.innominate.de (Postfix, from userid 9)
	id E24BE2CA6E; Mon, 13 Nov 2000 08:17:10 +0100 (CET)
From:   Thomas Graichen <news-innominate.list.sgi.xfs@innominate.de>
Reply-To: Thomas Graichen <graichen@innominate.de>
X-Newsgroups: innominate.list.sgi.xfs
Subject: Re: Questions about the status of XFS
Date:   13 Nov 2000 07:17:10 GMT
Organization: innominate AG, Berlin, Germany
Lines:  21
Distribution: local
Message-ID: <news2mail-8uo4hm$3v2$1@mate.bln.innominate.de>
References: <3A0F6056.D2C91E0B@exanet.co.il>
Reply-To: thomas.graichen@innominate.de
X-Trace: mate.bln.innominate.de 974099830 4066 10.0.0.69 (13 Nov 2000 07:17:10 GMT)
X-Complaints-To: news@innominate.de
User-Agent: tin/1.4.2-20000205 ("Possession") (UNIX) (Linux/2.4.0-XFS-test10 (i586))
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

Robert Hofner <robert@exanet.co.il> wrote:
> Hi,

> Are there any news regarding the availability (and functionality) of XFS
> on Compaq Alpha machines ?
> ...

i am right now looking into the state of XFS on the alpha ... it in
this moment runs an dbench 8 as a first test - if it survives (which
it did right now) i will run a dbench 64 and after that the xfs
stress tests and do some own stress testing - but basicaly it seems
to work so far but is not heavily tested ... i'll post the state
here from time to time - so stay tuned

t

-- 
thomas.graichen@innominate.com
technical director                                       innominate AG
clustering & security                             the linux architects
tel: +49-30-308806-13   fax: -77             http://www.innominate.com

From owner-linux-xfs@oss.sgi.com Mon Nov 13 00:12:48 2000
Received:  by oss.sgi.com id <S553971AbQKMIM3>;
	Mon, 13 Nov 2000 00:12:29 -0800
Received: from hermes.mixx.net ([212.84.196.2]:8974 "HELO hermes.mixx.net")
	by oss.sgi.com with SMTP id <S553965AbQKMIL7>;
	Mon, 13 Nov 2000 00:11:59 -0800
Received: from mate.bln.innominate.de (cerberus.berlin.innominate.de [212.84.234.251])
	by hermes.mixx.net (Postfix) with ESMTP id 73C34F802
	for <linux-xfs@oss.sgi.com>; Mon, 13 Nov 2000 09:11:57 +0100 (CET)
Received: by mate.bln.innominate.de (Postfix, from userid 9)
	id 332F22CA6E; Mon, 13 Nov 2000 09:11:57 +0100 (CET)
From:   Thomas Graichen <news-innominate.list.sgi.xfs@innominate.de>
Reply-To: Thomas Graichen <graichen@innominate.de>
X-Newsgroups: innominate.list.sgi.xfs
Subject: Re: stress test on ppc
Date:   13 Nov 2000 08:11:57 GMT
Organization: innominate AG, Berlin, Germany
Lines:  34
Distribution: local
Message-ID: <news2mail-8uo7od$4lt$1@mate.bln.innominate.de>
References: <news2mail-8uecj0$i5e$1@mate.bln.innominate.de>   <news-innominate.list.sgi.xfs@innominate.de>   <10011101103.ZM113097@wobbly.melbourne.sgi.com>   <20001110094151.C333@ysabell> <10011110006.ZM127189@wobbly.melbourne.sgi.com>
Reply-To: thomas.graichen@innominate.de
X-Trace: mate.bln.innominate.de 974103117 4797 10.0.0.69 (13 Nov 2000 08:11:57 GMT)
X-Complaints-To: news@innominate.de
User-Agent: tin/1.4.2-20000205 ("Possession") (UNIX) (Linux/2.4.0-XFS-test10 (i586))
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

"Nathan Scott" <nathans@wobbly.melbourne.sgi.com> wrote:
> On Nov 10,  9:41am, Marcelo E. Magallon wrote:
>> Subject: Re: stress test on ppc
>> ...
>>  This is the bash related bug I reported a while ago (I do remember
>>  seeing it commited to the CVS tree)
>> ...
>>  The problem is a POSIX sh doesn't care about the whitespace inside "$x"
>>  (something like "2  ") but bash (as /bin/sh) does.  At this point $x is
>>  not empty, if it is, something else went bonkers.
>> 

> ah - I think I see whats happened - there's two -ne tests like
> this & last time I only fixed one ... hopefully its fixed now
> (as of two minutes ago).

ok - reran the tests with your fixes - the current results (with all
the failed .out and .out.bad files) can be found at

  http://innominate.org/~graichen/projects/xfs/ppc/ppc.13-11-2000.tgz

let my know if i should try some other things too ... have to do some
other work now ... test results fuer XFS on alpha will follow soon
too ... ah before i forget - test 041 seems to have hung the
machine on ppc (thus it is not in here) - i'm right now
rechecking this ... more about this later

t

-- 
thomas.graichen@innominate.com
technical director                                       innominate AG
clustering & security                             the linux architects
tel: +49-30-308806-13   fax: -77             http://www.innominate.com

From owner-linux-xfs@oss.sgi.com Mon Nov 13 02:38:58 2000
Received:  by oss.sgi.com id <S553981AbQKMKis>;
	Mon, 13 Nov 2000 02:38:48 -0800
Received: from hermes.mixx.net ([212.84.196.2]:14596 "HELO hermes.mixx.net")
	by oss.sgi.com with SMTP id <S553978AbQKMKih>;
	Mon, 13 Nov 2000 02:38:37 -0800
Received: from mate.bln.innominate.de (cerberus.berlin.innominate.de [212.84.234.251])
	by hermes.mixx.net (Postfix) with ESMTP id 4F1C8F805
	for <linux-xfs@oss.sgi.com>; Mon, 13 Nov 2000 11:38:35 +0100 (CET)
Received: by mate.bln.innominate.de (Postfix, from userid 9)
	id 920172CA6E; Mon, 13 Nov 2000 11:38:34 +0100 (CET)
From:   Thomas Graichen <news-innominate.list.sgi.xfs@innominate.de>
Reply-To: Thomas Graichen <graichen@innominate.de>
X-Newsgroups: innominate.list.sgi.xfs
Subject: Re: Questions about the status of XFS
Date:   13 Nov 2000 10:38:34 GMT
Organization: innominate AG, Berlin, Germany
Lines:  48
Distribution: local
Message-ID: <news2mail-8uogba$7se$1@mate.bln.innominate.de>
References: <3A0F6056.D2C91E0B@exanet.co.il> <news2mail-8uo4hm$3v2$1@mate.bln.innominate.de>
Reply-To: thomas.graichen@innominate.de
X-Trace: mate.bln.innominate.de 974111914 8078 10.0.0.69 (13 Nov 2000 10:38:34 GMT)
X-Complaints-To: news@innominate.de
User-Agent: tin/1.4.2-20000205 ("Possession") (UNIX) (Linux/2.4.0-XFS-test10 (i586))
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

Thomas Graichen <news-innominate.list.sgi.xfs@innominate.de> wrote:
> Robert Hofner <robert@exanet.co.il> wrote:
>> Hi,

>> Are there any news regarding the availability (and functionality) of XFS
>> on Compaq Alpha machines ?
>> ...

> i am right now looking into the state of XFS on the alpha ... it in
> this moment runs an dbench 8 as a first test - if it survives (which
> it did right now) i will run a dbench 64 and after that the xfs
> stress tests and do some own stress testing - but basicaly it seems
> to work so far but is not heavily tested ... i'll post the state
> here from time to time - so stay tuned

it just finished the dbench 64 fine too - will do the stress tests
now ...

t

p.s.: for the XFS people: after the dbench 64 i got

  root@cyan:~# xfs_repair /dev/sdb3
  Phase 1 - find and verify superblock...
  Phase 2 - using internal log
          - zero log...
          - scan filesystem freespace and inode maps...
  bad magic # 0x0 for agf 0
  bad version # -1 for agf 0
  bad length 0 for agf 0, should be 28491
  flfirst -2147483648 in agf 0 too large (max = 128)
  fllast 50331648 in agf 0 too large (max = 128)
  reset bad agf for ag 0
  freeblk count 1 != flcount 13195527 in ag 0
  bad agbno 2962266880 for btbno root, agno 0
  bad agbno 16580607 for btbcnt root, agno 0
          - found root inode chunk
  Phase 3 - for each AG...
  ...

  but i will see if i can reproduce it ...


-- 
thomas.graichen@innominate.com
technical director                                       innominate AG
clustering & security                             the linux architects
tel: +49-30-308806-13   fax: -77             http://www.innominate.com

From owner-linux-xfs@oss.sgi.com Mon Nov 13 02:50:09 2000
Received:  by oss.sgi.com id <S553983AbQKMKt6>;
	Mon, 13 Nov 2000 02:49:58 -0800
Received: from hermes.mixx.net ([212.84.196.2]:39684 "HELO hermes.mixx.net")
	by oss.sgi.com with SMTP id <S553980AbQKMKtq>;
	Mon, 13 Nov 2000 02:49:46 -0800
Received: from mate.bln.innominate.de (cerberus.berlin.innominate.de [212.84.234.251])
	by hermes.mixx.net (Postfix) with ESMTP id 55889F802
	for <linux-xfs@oss.sgi.com>; Mon, 13 Nov 2000 11:49:44 +0100 (CET)
Received: by mate.bln.innominate.de (Postfix, from userid 9)
	id 3E9982CA6E; Mon, 13 Nov 2000 11:49:44 +0100 (CET)
From:   Thomas Graichen <news-innominate.list.sgi.xfs@innominate.de>
Reply-To: Thomas Graichen <graichen@innominate.de>
X-Newsgroups: innominate.list.sgi.xfs
Subject: XFS on alpha problem
Date:   13 Nov 2000 10:49:44 GMT
Organization: innominate AG, Berlin, Germany
Lines:  33
Distribution: local
Message-ID: <news2mail-8uoh08$7se$2@mate.bln.innominate.de>
Reply-To: thomas.graichen@innominate.de
X-Trace: mate.bln.innominate.de 974112584 8078 10.0.0.69 (13 Nov 2000 10:49:44 GMT)
X-Complaints-To: news@innominate.de
User-Agent: tin/1.4.2-20000205 ("Possession") (UNIX) (Linux/2.4.0-XFS-test10 (i586))
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

running XFS on the alpha results in the following:

* mkfs (with 8k blocksize for the alpha)
* xfs_repair - fs is ok
* mount
* umount (nothing done on the mounted fs)
* xfs_repair:

  root@cyan:/usr/src/xfs/cmd/xfs/stress# xfs_repair /dev/sdb3
  Phase 1 - find and verify superblock...
  Phase 2 - using internal log
          - zero log...
          - scan filesystem freespace and inode maps...
  bad magic # 0x0 for agf 0
  bad version # -1 for agf 0
  bad length 0 for agf 0, should be 28491
  flfirst -2147483648 in agf 0 too large (max = 128)
  reset bad agf for ag 0
  freeblk count 1 != flcount 1086347527 in ag 0
  bad agbno 2962266880 for btbno root, agno 0
  bad agbno 16580607 for btbcnt root, agno 0
          - found root inode chunk
  Phase 3 - for each AG...

any idea?

t

-- 
thomas.graichen@innominate.com
technical director                                       innominate AG
clustering & security                             the linux architects
tel: +49-30-308806-13   fax: -77             http://www.innominate.com

From owner-linux-xfs@oss.sgi.com Mon Nov 13 16:02:53 2000
Received:  by oss.sgi.com id <S553992AbQKNACd>;
	Mon, 13 Nov 2000 16:02:33 -0800
Received: from deliverator.sgi.com ([204.94.214.10]:40758 "EHLO
        deliverator.sgi.com") by oss.sgi.com with ESMTP id <S553975AbQKNAC1>;
	Mon, 13 Nov 2000 16:02:27 -0800
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 PAA28359
	for <linux-xfs@oss.sgi.com>; Mon, 13 Nov 2000 15:54:35 -0800 (PST)
	mail_from (nathans@wobbly.melbourne.sgi.com)
Received: from wobbly.melbourne.sgi.com (wobbly.melbourne.sgi.com [134.14.55.135]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id KAA19897; Tue, 14 Nov 2000 10:59:54 +1100
Received: (from nathans@localhost) by wobbly.melbourne.sgi.com (980427.SGI.8.8.8/980728.SGI.AUTOCF) id KAA29605; Tue, 14 Nov 2000 10:59:51 +1100 (EDT)
From:   "Nathan Scott" <nathans@wobbly.melbourne.sgi.com>
Message-Id: <10011141059.ZM128320@wobbly.melbourne.sgi.com>
Date:   Tue, 14 Nov 2000 10:59:49 -0400
In-Reply-To: Thomas Graichen <news-innominate.list.sgi.xfs@innominate.de>
        "Re: stress test on ppc" (Nov 13,  8:11am)
References: <news2mail-8uecj0$i5e$1@mate.bln.innominate.de> 
	<news-innominate.list.sgi.xfs@innominate.de> 
	<10011101103.ZM113097@wobbly.melbourne.sgi.com> 
	<20001110094151.C333@ysabell> 
	<10011110006.ZM127189@wobbly.melbourne.sgi.com> 
	<news2mail-8uo7od$4lt$1@mate.bln.innominate.de>
X-Mailer: Z-Mail (3.2.3 08feb96 MediaMail)
To:     Thomas Graichen <graichen@innominate.de>,
        thomas.graichen@innominate.de, linux-xfs@oss.sgi.com
Subject: Re: stress test on ppc
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 Thomas,

On Nov 13,  8:11am, Thomas Graichen wrote:
> Subject: Re: stress test on ppc
> ...
> > ah - I think I see whats happened - there's two -ne tests like
> > this & last time I only fixed one ... hopefully its fixed now
> > (as of two minutes ago).
> 
> ok - reran the tests with your fixes - the current results (with all
> the failed .out and .out.bad files) can be found at
> 
>   http://innominate.org/~graichen/projects/xfs/ppc/ppc.13-11-2000.tgz
> 

ok, some progress - looks like the scratch device problem is
resolved and test 002 is fixed - great!

004 - this looks like a 32 bit number overflow in the xfs_db
"freesp" command, i'll need to investigate a bit more.

018 - ??? no idea - looks like theres a bunch of unexpected
records in the log for some reason?  bizarre.

020 - attribute syscall code not there in ppc?

026/027/028/046/047 - a reoccurence of the dump/restore problems
from Marcelo, Tim/Ivan?  or new ones?
also group "nobody" assumed to exist, but doesn't.  can we change
the way the test works, Tim?  or exit cleanly if no "nobody" grp?
or use numeric gids instead of named groups perhaps?

032 - hmmm... could be a problem in mount(8) code which we use
for mkfs.xfs so that it doesn't overwrite other filesystems -
can you see whether mount on ppc can autodetect (i.e. mount
without "-t" a filesystem created by mkfs.minix on ppc?  thanks)

033 - stress/src/devzero is not doing whats expected of it for
some reason? (the "Wrote 0.00Kb messages are very suspect, the
rest looks like consequential failure)


> too ... ah before i forget - test 041 seems to have hung the
> machine on ppc (thus it is not in here) - i'm right now
> rechecking this ... more about this later


cheers.

-- 
Nathan

From owner-linux-xfs@oss.sgi.com Mon Nov 13 18:52:43 2000
Received:  by oss.sgi.com id <S553711AbQKNCwe>;
	Mon, 13 Nov 2000 18:52:34 -0800
Received: from deliverator.sgi.com ([204.94.214.10]:49000 "EHLO
        deliverator.sgi.com") by oss.sgi.com with ESMTP id <S553663AbQKNCwW>;
	Mon, 13 Nov 2000 18:52:22 -0800
Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.55.149]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id SAA21985
	for <linux-xfs@oss.sgi.com>; Mon, 13 Nov 2000 18:44:30 -0800 (PST)
	mail_from (tes@snort.melbourne.sgi.com)
Received: (from tes@localhost)
	by snort.melbourne.sgi.com (SGI-8.9.3/8.9.3) id NAA40779
	for linux-xfs@oss.sgi.com; Tue, 14 Nov 2000 13:51:01 +1100 (EST)
Date:   Tue, 14 Nov 2000 13:51:01 +1100 (EST)
From:   Timothy Shimmin <tes@snort.melbourne.sgi.com>
Message-Id: <200011140251.NAA40779@snort.melbourne.sgi.com>
To:     linux-xfs@oss.sgi.com
Subject: TAKE - stress/dump
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.4.x-xfs:slinx:78142a
Date:  Mon Nov 13 18:50:23 PST 2000
Workarea:  snort:/build4/tes/slinx-xfs
Author:  tes

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

cmd/xfs/stress/common.dump - 1.22
	- Get rid of nobody.


From owner-linux-xfs@oss.sgi.com Mon Nov 13 18:58:44 2000
Received:  by oss.sgi.com id <S553719AbQKNC6e>;
	Mon, 13 Nov 2000 18:58:34 -0800
Received: from deliverator.sgi.com ([204.94.214.10]:64617 "EHLO
        deliverator.sgi.com") by oss.sgi.com with ESMTP id <S553657AbQKNC6W>;
	Mon, 13 Nov 2000 18:58:22 -0800
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 SAA22660
	for <linux-xfs@oss.sgi.com>; Mon, 13 Nov 2000 18:50:29 -0800 (PST)
	mail_from (tes@boing.melbourne.sgi.com)
Received: from boing.melbourne.sgi.com (boing.melbourne.sgi.com [134.14.55.141]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id NAA20950; Tue, 14 Nov 2000 13:55:48 +1100
Received: (from tes@localhost) by boing.melbourne.sgi.com (980427.SGI.8.8.8/980728.SGI.AUTOCF) id NAA95421; Tue, 14 Nov 2000 13:55:47 +1100 (EDT)
From:   tes@boing.melbourne.sgi.com (Timothy Shimmin)
Message-Id: <200011140255.NAA95421@boing.melbourne.sgi.com>
Subject: Re: stress test on ppc
To:     nathans@wobbly.melbourne.sgi.com (Nathan Scott)
Date:   Tue, 14 Nov 2000 13:55:46 +1100 (EDT)
Cc:     graichen@innominate.de (Thomas Graichen), linux-xfs@oss.sgi.com
In-Reply-To: <10011141059.ZM128320@wobbly.melbourne.sgi.com> from "Nathan Scott" at Nov 14, 2000 10:59:49 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

> 
> hi Thomas,
> 
> On Nov 13,  8:11am, Thomas Graichen wrote:
> > Subject: Re: stress test on ppc
> > ...
> > > ah - I think I see whats happened - there's two -ne tests like
> > > this & last time I only fixed one ... hopefully its fixed now
> > > (as of two minutes ago).
> > 
> > ok - reran the tests with your fixes - the current results (with all
> > the failed .out and .out.bad files) can be found at
> > 
> >   http://innominate.org/~graichen/projects/xfs/ppc/ppc.13-11-2000.tgz
> > 
> 
> 026/027/028/046/047 - a reoccurence of the dump/restore problems
> from Marcelo, Tim/Ivan?  or new ones?
Looks like a reoccurrence.
The dump/restore is not reading the inventory.

> also group "nobody" assumed to exist, but doesn't.  can we change
> the way the test works, Tim?  or exit cleanly if no "nobody" grp?
> or use numeric gids instead of named groups perhaps?
I'll use numeric gid instead (fixed in checkin).

--Tim

From owner-linux-xfs@oss.sgi.com Mon Nov 13 19:08:34 2000
Received:  by oss.sgi.com id <S553742AbQKNDIY>;
	Mon, 13 Nov 2000 19:08:24 -0800
Received: from deliverator.sgi.com ([204.94.214.10]:56427 "EHLO
        deliverator.sgi.com") by oss.sgi.com with ESMTP id <S553692AbQKNDH6>;
	Mon, 13 Nov 2000 19:07:58 -0800
Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.55.149]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id SAA23550
	for <linux-xfs@oss.sgi.com>; Mon, 13 Nov 2000 18:59:43 -0800 (PST)
	mail_from (dxm@snort.melbourne.sgi.com)
Received: (from dxm@localhost)
	by snort.melbourne.sgi.com (SGI-8.9.3/8.9.3) id OAA41814
	for linux-xfs@oss.sgi.com; Tue, 14 Nov 2000 14:04:58 +1100 (EST)
Date:   Tue, 14 Nov 2000 14:04:58 +1100 (EST)
From:   Daniel Moore <dxm@snort.melbourne.sgi.com>
Message-Id: <200011140304.OAA41814@snort.melbourne.sgi.com>
To:     linux-xfs@oss.sgi.com
Subject: TAKE - heads up - xfs support code split
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing

Here it is. Note you'll need to run "oldconfig" or "xconfig"
to get the new config option in your .config file. And make
sure you regenerate your dependencies so the xfs_support module
gets loaded.

In response to the two responses I got:
	- I agree with Laurie that if we decide to make this
	  stuff cross-OS, then the right thing to do
	  would be to put the OS specific code within the module
	  rather than have multiple versions of the module
	  ie xfs/support/linux not xfs/linux/support.
	- re the exact name of the module, we had a group meeting
	  here, and couldn't come up with anything better.
	  "services" =~ "support" and "os_*" doesn't imply what
	  the module is actually for whereas "xfs_*" at least
	  gives the xfs connection

I took the path of least resistance.

Modid:  2.4.x-xfs:slinx:78143a
Date:  Mon Nov 13 18:57:58 PST 2000
Workarea:  snort:/build1/people/dxm/isms/slinx-xfs
Author:  dxm

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

linux/fs/Config.in - 1.46
linux/fs/xfs/Makefile - 1.109
linux/fs/xfs/linux/Makefile - 1.29
linux/fs/xfs/linux/qsort.c - 1.3
linux/fs/xfs/linux/xfs_debug.c - 1.13
linux/fs/xfs/linux/xfs_debug.h - 1.3
linux/fs/xfs/linux/xfs_linux.h - 1.37
linux/fs/xfs/linux/xfs_locks.c - 1.23
linux/fs/xfs/linux/xfs_move.c - 1.14
linux/fs/xfs/linux/xfs_move.h - 1.3
linux/fs/xfs/linux/xfs_random.c - 1.49
linux/fs/xfs/linux/xfs_random.h - 1.2
linux/fs/xfs/linux/xfs_sema.h - 1.29
linux/fs/xfs/linux/xfs_uuid.c - 1.23
linux/fs/xfs/linux/xfs_uuid.h - 1.3
linux/fs/xfs/xfs.h - 1.10
linux/fs/xfs/xfs_arch.h - 1.31
linux/fs/xfs/xfs_fsops.c - 1.62
linux/fs/xfs/xfsidbg.c - 1.154
linux/include/linux/xfs_fs.h - 1.18
linux/fs/xfs/linux/xfs_stats.c - 1.1
linux/fs/xfs/linux/xfs_stats.h - 1.1
linux/fs/xfs/support/Makefile - 1.1
linux/fs/xfs/support/arch.h - 1.1
linux/fs/xfs/support/atomic.h - 1.1
linux/fs/xfs/support/debug.c - 1.1
linux/fs/xfs/support/debug.h - 1.1
linux/fs/xfs/support/kmem.c - 1.1
linux/fs/xfs/support/kmem.h - 1.1
linux/fs/xfs/support/ktrace.c - 1.1
linux/fs/xfs/support/ktrace.h - 1.1
linux/fs/xfs/support/move.c - 1.1
linux/fs/xfs/support/move.h - 1.1
linux/fs/xfs/support/mrlock.c - 1.1
linux/fs/xfs/support/mrlock.h - 1.1
linux/fs/xfs/support/mutex.c - 1.1
linux/fs/xfs/support/mutex.h - 1.1
linux/fs/xfs/support/qsort.c - 1.1
linux/fs/xfs/support/qsort.h - 1.1
linux/fs/xfs/support/sema.h - 1.1
linux/fs/xfs/support/spin.h - 1.1
linux/fs/xfs/support/support.c - 1.1
linux/fs/xfs/support/support.h - 1.1
linux/fs/xfs/support/sv.c - 1.1
linux/fs/xfs/support/sv.h - 1.1
linux/fs/xfs/support/time.h - 1.1
linux/fs/xfs/support/types.h - 1.1
linux/fs/xfs/support/uuid.c - 1.1
linux/fs/xfs/support/uuid.h - 1.1
	- Split XFS support code into xfs_support module


From owner-linux-xfs@oss.sgi.com Mon Nov 13 19:47:44 2000
Received:  by oss.sgi.com id <S553777AbQKNDre>;
	Mon, 13 Nov 2000 19:47:34 -0800
Received: from deliverator.sgi.com ([204.94.214.10]:16755 "EHLO
        deliverator.sgi.com") by oss.sgi.com with ESMTP id <S553758AbQKNDrU>;
	Mon, 13 Nov 2000 19:47:20 -0800
Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.55.149]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id TAA27618
	for <linux-xfs@oss.sgi.com>; Mon, 13 Nov 2000 19:39:27 -0800 (PST)
	mail_from (dxm@snort.melbourne.sgi.com)
Received: (from dxm@localhost)
	by snort.melbourne.sgi.com (SGI-8.9.3/8.9.3) id OAA43058
	for linux-xfs@oss.sgi.com; Tue, 14 Nov 2000 14:45:41 +1100 (EST)
Date:   Tue, 14 Nov 2000 14:45:41 +1100 (EST)
From:   Daniel Moore <dxm@snort.melbourne.sgi.com>
Message-Id: <200011140345.OAA43058@snort.melbourne.sgi.com>
To:     linux-xfs@oss.sgi.com
Subject: TAKE - xfs qa 018
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 mostly fix 018 for PPC. Actually it was the
LE version of logprint that was broken. The remaining
differences are a bit scarey and I'd like to see the
output from another run of 018 on PPC...

Modid:  2.4.x-xfs:slinx:78145a
Date:  Mon Nov 13 19:40:49 PST 2000
Workarea:  snort:/build1/people/dxm/isms/slinx-xfs
Author:  dxm

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

cmd/xfs/logprint/log_misc.c - 1.74
	- add missing endian conversions

cmd/xfs/stress/018.out - 1.5
	- correct expected output


From owner-linux-xfs@oss.sgi.com Tue Nov 14 08:28:08 2000
Received:  by oss.sgi.com id <S553650AbQKNQ1r>;
	Tue, 14 Nov 2000 08:27:47 -0800
Received: from deliverator.sgi.com ([204.94.214.10]:10018 "EHLO
        deliverator.sgi.com") by oss.sgi.com with ESMTP id <S553645AbQKNQ10>;
	Tue, 14 Nov 2000 08:27:26 -0800
Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id IAA22356
	for <linux-xfs@oss.sgi.com>; Tue, 14 Nov 2000 08:19:33 -0800 (PST)
	mail_from (lord@jen.americas.sgi.com)
Received: from thistle-e185.americas.sgi.com (thistle-e185.americas.sgi.com [128.162.185.204]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id KAA6700890 for <linux-xfs@oss.sgi.com>; Tue, 14 Nov 2000 10:24:54 -0600 (CST)
Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.184.86]) by thistle-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id KAA28615 for <linux-xfs@oss.sgi.com>; Tue, 14 Nov 2000 10:24:54 -0600 (CST)
Received: (from lord@localhost)
	by jen.americas.sgi.com (8.9.3/8.9.3) id KAA24565
	for linux-xfs@oss.sgi.com; Tue, 14 Nov 2000 10:19:14 -0600
Date:   Tue, 14 Nov 2000 10:19:14 -0600
From:   Steve Lord <lord@sgi.com>
Message-Id: <200011141619.KAA24565@jen.americas.sgi.com>
Subject: TAKE - fix locking in an ioctl call
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

Date:  Tue Nov 14 08:24:30 PST 2000
Workarea:  jen.americas.sgi.com:/src/lord/xfs-linux.2.4

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


Modid:  2.4.x-xfs:slinx:78162a
linux/fs/xfs/linux/xfs_iops.c - 1.78
	- Add required locking around flush call - debug build trips an assert without
	  this.



From owner-linux-xfs@oss.sgi.com Tue Nov 14 08:44:08 2000
Received:  by oss.sgi.com id <S553653AbQKNQn6>;
	Tue, 14 Nov 2000 08:43:58 -0800
Received: from deliverator.sgi.com ([204.94.214.10]:33576 "EHLO
        deliverator.sgi.com") by oss.sgi.com with ESMTP id <S553646AbQKNQni>;
	Tue, 14 Nov 2000 08:43:38 -0800
Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id IAA25440
	for <linux-xfs@oss.sgi.com>; Tue, 14 Nov 2000 08:35:46 -0800 (PST)
	mail_from (lord@jen.americas.sgi.com)
Received: from thistle-e185.americas.sgi.com (thistle-e185.americas.sgi.com [128.162.185.204]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id KAA7635914 for <linux-xfs@oss.sgi.com>; Tue, 14 Nov 2000 10:42:22 -0600 (CST)
Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.184.86]) by thistle-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id KAA24849 for <linux-xfs@oss.sgi.com>; Tue, 14 Nov 2000 10:42:22 -0600 (CST)
Received: (from lord@localhost)
	by jen.americas.sgi.com (8.9.3/8.9.3) id KAA24846
	for linux-xfs@oss.sgi.com; Tue, 14 Nov 2000 10:36:42 -0600
Date:   Tue, 14 Nov 2000 10:36:42 -0600
From:   Steve Lord <lord@sgi.com>
Message-Id: <200011141636.KAA24846@jen.americas.sgi.com>
Subject: TAKE - fix smp build of new support modules
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

Date:  Tue Nov 14 08:42:01 PST 2000
Workarea:  jen.americas.sgi.com:/src/lord/xfs-linux.2.4

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


Modid:  2.4.x-xfs:slinx:78165a
linux/fs/xfs/support/kmem.c - 1.2
linux/fs/xfs/support/ktrace.c - 1.2
	- Fix smp build



From owner-linux-xfs@oss.sgi.com Tue Nov 14 08:45:18 2000
Received:  by oss.sgi.com id <S553656AbQKNQpI>;
	Tue, 14 Nov 2000 08:45:08 -0800
Received: from deliverator.sgi.com ([204.94.214.10]:60712 "EHLO
        deliverator.sgi.com") by oss.sgi.com with ESMTP id <S553651AbQKNQou>;
	Tue, 14 Nov 2000 08:44:50 -0800
Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id IAA25687
	for <linux-xfs@oss.sgi.com>; Tue, 14 Nov 2000 08:36:58 -0800 (PST)
	mail_from (lord@jen.americas.sgi.com)
Received: from thistle-e185.americas.sgi.com (thistle-e185.americas.sgi.com [128.162.185.204]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id KAA6467259 for <linux-xfs@oss.sgi.com>; Tue, 14 Nov 2000 10:43:34 -0600 (CST)
Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.184.86]) by thistle-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id KAA28777 for <linux-xfs@oss.sgi.com>; Tue, 14 Nov 2000 10:43:34 -0600 (CST)
Received: (from lord@localhost)
	by jen.americas.sgi.com (8.9.3/8.9.3) id KAA24918
	for linux-xfs@oss.sgi.com; Tue, 14 Nov 2000 10:37:54 -0600
Date:   Tue, 14 Nov 2000 10:37:54 -0600
From:   Steve Lord <lord@sgi.com>
Message-Id: <200011141637.KAA24918@jen.americas.sgi.com>
Subject: TAKE - remove dead files from tree
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

remove dead module

Date:  Tue Nov 14 08:43:08 PST 2000
Workarea:  jen.americas.sgi.com:/src/lord/xfs-linux.2.4

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


Modid:  2.4.x-xfs:slinx:78167a
linux/fs/xfs/linux/qsort.c - 1.4
linux/fs/xfs/linux/xfs_random.c - 1.50
linux/fs/xfs/linux/xfs_move.c - 1.15
linux/fs/xfs/linux/xfs_debug.c - 1.14
linux/fs/xfs/linux/xfs_uuid.c - 1.24
linux/fs/xfs/linux/xfs_sema.h - 1.30
linux/fs/xfs/linux/xfs_locks.c - 1.24
linux/fs/xfs/linux/xfs_debug.h - 1.4
linux/fs/xfs/linux/xfs_uuid.h - 1.4
linux/fs/xfs/linux/xfs_move.h - 1.4
linux/fs/xfs/linux/xfs_random.h - 1.3


From owner-linux-xfs@oss.sgi.com Tue Nov 14 12:23:20 2000
Received:  by oss.sgi.com id <S553661AbQKNUXK>;
	Tue, 14 Nov 2000 12:23:10 -0800
Received: from deliverator.sgi.com ([204.94.214.10]:20488 "EHLO
        deliverator.sgi.com") by oss.sgi.com with ESMTP id <S553655AbQKNUWz>;
	Tue, 14 Nov 2000 12:22:55 -0800
Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.55.149]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id MAA10176
	for <linux-xfs@oss.sgi.com>; Tue, 14 Nov 2000 12:15:01 -0800 (PST)
	mail_from (dxm@snort.melbourne.sgi.com)
Received: (from dxm@localhost)
	by snort.melbourne.sgi.com (SGI-8.9.3/8.9.3) id HAA92894
	for linux-xfs@oss.sgi.com; Wed, 15 Nov 2000 07:21:31 +1100 (EST)
Date:   Wed, 15 Nov 2000 07:21:31 +1100 (EST)
From:   Daniel Moore <dxm@snort.melbourne.sgi.com>
Message-Id: <200011142021.HAA92894@snort.melbourne.sgi.com>
To:     linux-xfs@oss.sgi.com
Subject: TAKE - fix modular smp build
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.4.x-xfs:slinx:78201a
Date:  Tue Nov 14 12:15:49 PST 2000
Workarea:  snort:/build1/people/dxm/isms/slinx-xfs
Author:  dxm

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

linux/fs/xfs/support/mrlock.c - 1.2
	- fix modular SMP build

linux/fs/xfs/support/support.c - 1.2
	- remove debug messages


From owner-linux-xfs@oss.sgi.com Tue Nov 14 14:10:32 2000
Received:  by oss.sgi.com id <S553721AbQKNWKW>;
	Tue, 14 Nov 2000 14:10:22 -0800
Received: from deliverator.sgi.com ([204.94.214.10]:63291 "EHLO
        deliverator.sgi.com") by oss.sgi.com with ESMTP id <S553679AbQKNWKA>;
	Tue, 14 Nov 2000 14:10:00 -0800
Received: from eric2.austin.sgi.com (root@eric2.austin.sgi.com [169.238.86.147]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id OAA05629
	for <linux-xfs@oss.sgi.com>; Tue, 14 Nov 2000 14:02:08 -0800 (PST)
	mail_from (eric@eric2.austin.sgi.com)
Received: (from eric@localhost)
	by eric2.austin.sgi.com (8.11.0/8.11.0) id eAEM90N22472
	for linux-xfs@oss.sgi.com; Tue, 14 Nov 2000 16:09:00 -0600
Date:   Tue, 14 Nov 2000 16:09:00 -0600
From:   Eric Sandeen <eric@eric2.austin.sgi.com>
Message-Id: <200011142209.eAEM90N22472@eric2.austin.sgi.com>
Subject: TAKE - initialize fsynced in xfs_bmap()
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

Date:  Tue Nov 14 14:06:59 PST 2000
Workarea:  eric2.austin.sgi.com:/home/eric/xfs/workarea-reallyclean

`fsynced' was being used uninitialized in xfs_bmap(), which hosed
the ENOSPC error handling, skipping flushes, etc.


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


Modid:  2.4.x-xfs:slinx:78217a
linux/fs/xfs/linux/xfs_lrw.c - 1.62
	- initialize variable `fsynced' for ENOSPC error condition



From owner-linux-xfs@oss.sgi.com Tue Nov 14 15:03:51 2000
Received:  by oss.sgi.com id <S553760AbQKNXDl>;
	Tue, 14 Nov 2000 15:03:41 -0800
Received: from granger.mail.mindspring.net ([207.69.200.148]:65290 "EHLO
        granger.mail.mindspring.net") by oss.sgi.com with ESMTP
	id <S553699AbQKNXD1>; Tue, 14 Nov 2000 15:03:27 -0800
Received: from mindspring.com (user-38lcnef.dialup.mindspring.com [209.86.93.207])
	by granger.mail.mindspring.net (8.9.3/8.8.5) with ESMTP id SAA20051
	for <linux-xfs@oss.sgi.com>; Tue, 14 Nov 2000 18:03:24 -0500 (EST)
Message-ID: <3A11C6E3.62F04C3D@mindspring.com>
Date:   Tue, 14 Nov 2000 18:12:35 -0500
From:   Danny <danscox@mindspring.com>
Reply-To: dcox@connex.com
Organization: Connex Inc
X-Mailer: Mozilla 4.75 [en] (X11; U; Linux 2.4.0-XFS-test8 i686)
X-Accept-Language: en
MIME-Version: 1.0
To:     linux-xfs@oss.sgi.com
Subject: An Introduction, and some 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

Hello, all!

	By way of introduction, I'm Danny Cox, recently hired by Connex, a
company that makes NAS boxes, among other things.  I was charged with
getting ACLs to work with XFS.  Mr. Lord pointed us to the original ACL
code, and most of it went pretty smoothly.  With some caveats, it all
seems to work, even!

	I do have some issues, though.  I can describe the symptoms, and
perhaps someone will be able to point me in the right direction.  Thanks
in advance.

	First, I have a program that is suid-root, and takes two arguments: a
file of tests to perform, and a file to perform the tests upon.  It
changes the user/group of the file to that specified, and forks.  The
child assumes the user/group specified (perhaps different than the
file's user/group), and performs the tests (read/write/execute).  I
discovered that it didn't always work!  The short form is that if I
place a acl_get(2) or a stat(2) call after the acl_set(2), it works
every time.  I thus conclude that the data is being cached (for lack of
a better term) somewhere, and that it's not available to the xfs_access
call some few milliseconds later.

	Item two: the test file I use has some 49 tests.  Sometimes (sorry,
I've not yet been able to narrow this down any), the file in question
acquires a strange quality.  Thereafter, any attempt to execute it
fails, with a result of 'Text file busy'.  I'm mystified!  No obvious
entries with 'ps ax' appear, and unmount fails with 'Device busy'.  I
don't have any idea of where to begin looking!

	Item last: when adding the various functions to handle the intermediate
steps between system call and xfs_acl.c, I basically copied what
attr_get did.  One of these, in linux/xfs_vnode.h is:
-------------------------------------------------------------
#define VOP_ACL_GET(vp, acl, dacl, rv)                                 
\
{                                                                      
\
        VN_BHV_READ_LOCK(&(vp)->v_bh);                                 
\
        rv = _VOP_(vop_acl_get, vp)((vp),acl,dacl);                    
\
        VN_BHV_READ_UNLOCK(&(vp)->v_bh);                               
\
}
-------------------------------------------------------------
My question is: is this necessary?  Under Linux, VN_BHV_READ_LOCK is
defined away to nothing. However, on other archs, it may not be.  Since
acl_get eventually calls attr_get through a similar macro, the lock is
set twice!  Is this is problem?  Similarly, acl_set does the same.

	Finally, then: once these issues are dealt with, to whom shall I send
the diffs, assuming that folks want it?

	Thanks for your time!

-- 
"Men occasionally stumble over the truth, but most of them pick 
themselves up and hurry off as if nothing had happened." 
   -- Winston Churchill 

Danny

From owner-linux-xfs@oss.sgi.com Tue Nov 14 15:13:41 2000
Received:  by oss.sgi.com id <S553794AbQKNXNb>;
	Tue, 14 Nov 2000 15:13:31 -0800
Received: from ppp0.ocs.com.au ([203.34.97.3]:43023 "HELO mail.ocs.com.au")
	by oss.sgi.com with SMTP id <S553774AbQKNXN0>;
	Tue, 14 Nov 2000 15:13:26 -0800
Received: (qmail 3908 invoked from network); 14 Nov 2000 23:13:20 -0000
Received: from ocs3.ocs-net (192.168.255.3)
  by mail.ocs.com.au with SMTP; 14 Nov 2000 23:13:19 -0000
X-Mailer: exmh version 2.1.1 10/15/1999
From:   Keith Owens <kaos@melbourne.sgi.com>
To:     dcox@connex.com
cc:     linux-xfs@oss.sgi.com
Subject: Re: An Introduction, and some Questions 
In-reply-to: Your message of "Tue, 14 Nov 2000 18:12:35 CDT."
             <3A11C6E3.62F04C3D@mindspring.com> 
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date:   Wed, 15 Nov 2000 10:13:19 +1100
Message-ID: <11755.974243599@ocs3.ocs-net>
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, 14 Nov 2000 18:12:35 -0500, 
Danny <danscox@mindspring.com> wrote:
>	Item two: the test file I use has some 49 tests.  Sometimes (sorry,
>I've not yet been able to narrow this down any), the file in question
>acquires a strange quality.  Thereafter, any attempt to execute it
>fails, with a result of 'Text file busy'.  I'm mystified!  No obvious
>entries with 'ps ax' appear, and unmount fails with 'Device busy'.  I
>don't have any idea of where to begin looking!

Is this an NFS mount?  There used to be problems with writing to NFS
mounted files from a client machine then trying to execute the program
from the host machine.  The host marks the file as text busy but
because NFS is stateless, the host does not know when to clear the busy
flag.  I do not know if this problem still exists on NFS, I just
stopped performing that type of operation.


From owner-linux-xfs@oss.sgi.com Tue Nov 14 15:19:31 2000
Received:  by oss.sgi.com id <S553792AbQKNXTV>;
	Tue, 14 Nov 2000 15:19:21 -0800
Received: from chyndslgw1poolA164.chyn.uswest.net ([63.227.165.164]:53802 "EHLO
        roujin.gargoylecc.com") by oss.sgi.com with ESMTP
	id <S553764AbQKNXTO>; Tue, 14 Nov 2000 15:19:14 -0800
Received: from roujin.gargoylecc.com (IDENT:ringram@roujin.gargoylecc.com [10.0.0.2])
	by roujin.gargoylecc.com (8.9.3/8.9.3) with ESMTP id HAA20383
	for <linux-xfs@oss.sgi.com>; Wed, 15 Nov 2000 07:24:23 -0700
Date:   Wed, 15 Nov 2000 07:24:23 -0700 (MST)
From:   Russel Ingram <ringram@gargoylecc.com>
To:     linux-xfs@oss.sgi.com
Subject: XFS with ReiserFS
Message-ID: <Pine.LNX.4.21.0011150718170.20366-100000@roujin.gargoylecc.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

Does anyone know if the xfs beta kernel source can be patched with the
reiserfs patch to create a working kernel with support for both
filesystems?  I have a system that is already running reiserfs and want to
give xfs a try but can't if I can't get a kernel that supports both.

TIA,
Russ

Russel Ingram
Gargoyle Computer Consulting
http://www.gargoylecc.com


From owner-linux-xfs@oss.sgi.com Tue Nov 14 15:44:41 2000
Received:  by oss.sgi.com id <S553795AbQKNXoc>;
	Tue, 14 Nov 2000 15:44:32 -0800
Received: from deliverator.sgi.com ([204.94.214.10]:63076 "EHLO
        deliverator.sgi.com") by oss.sgi.com with ESMTP id <S553772AbQKNXo3>;
	Tue, 14 Nov 2000 15:44:29 -0800
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 PAA26506
	for <linux-xfs@oss.sgi.com>; Tue, 14 Nov 2000 15:36:35 -0800 (PST)
	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 KAA28280 for <@larry.melbourne.sgi.com:linux-xfs@oss.sgi.com>; Wed, 15 Nov 2000 10:41:55 +1100
Received: (from dxm@localhost) by clouds.melbourne.sgi.com (980427.SGI.8.8.8/980728.SGI.AUTOCF) id KAA05352 for linux-xfs@oss.sgi.com; Wed, 15 Nov 2000 10:41:55 +1100 (EST)
Date:   Wed, 15 Nov 2000 10:41:55 +1100 (EST)
From:   dxm@clouds.melbourne.sgi.com (Daniel Moore)
Message-Id: <200011142341.KAA05352@clouds.melbourne.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

Date:  Tue Nov 14 15:40:34 PST 2000
Workarea:  clouds.melbourne.sgi.com:/hosts/snort/build1/people/dxm/isms/slinx-xfs

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

Modid:  2.4.x-xfs:slinx:78228a
linux/fs/xfs/xfs_log.h - 1.54
linux/fs/xfs/xfs_dinode.h - 1.57
linux/fs/xfs/xfs_os_defs.h - 1.16
cmd/xfs/dump/common/drive_minrmt.c - 1.25
cmd/xfs/dump/common/drive_scsitape.c - 1.29
cmd/xfs/dump/common/drive_simple.c - 1.14
cmd/xfs/dump/common/global.c - 1.13
	- remove extraneous include of "xfs_arch.h" (now arch.h)

linux/fs/xfs/xfs_arch.h - 1.32
	- remove leftover file

cmd/xfs/include/libxfs.h - 1.20
cmd/xfs/include/xfs_arch.h - 1.7
cmd/xfs/tools/srcdiff - 1.12
cmd/xfs/include/arch.h - 1.3
	- rename "xfs_arch.h" to "arch.h"

cmd/xfs/include/xfs_log.h - 1.3
cmd/xfs/include/xfs_dinode.h - 1.2
cmd/xfs/include/xfs_fs.h - 1.7
	- match kernel




From owner-linux-xfs@oss.sgi.com Tue Nov 14 15:56:42 2000
Received:  by oss.sgi.com id <S553805AbQKNX4c>;
	Tue, 14 Nov 2000 15:56:32 -0800
Received: from deliverator.sgi.com ([204.94.214.10]:18537 "EHLO
        deliverator.sgi.com") by oss.sgi.com with ESMTP id <S553789AbQKNX4O>;
	Tue, 14 Nov 2000 15:56:14 -0800
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 PAA28862
	for <linux-xfs@oss.sgi.com>; Tue, 14 Nov 2000 15:48:21 -0800 (PST)
	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 KAA28410; Wed, 15 Nov 2000 10:54:55 +1100
Received: from localhost (dxm@localhost) by clouds.melbourne.sgi.com (980427.SGI.8.8.8/980728.SGI.AUTOCF) via SMTP id KAA05428; Wed, 15 Nov 2000 10:54:55 +1100 (EST)
Message-Id: <200011142354.KAA05428@clouds.melbourne.sgi.com>
X-Mailer: exmh version 2.0.2 2/24/98
To:     Rajagopal Ananthanarayanan <ananth@sgi.com>
cc:     linux-xfs@oss.sgi.com
Subject: Re: xfs as module? 
In-reply-to: Your message of "Tue, 14 Nov 2000 15:41:51 -0800."
             <3A11CDBF.EC499F7E@sgi.com> 
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date:   Wed, 15 Nov 2000 10:54:55 +1100
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


Rajagopal Ananthanarayanan writes:
 => 
 => Has anyone tried compiling xfs as a module
 => with top of trunk sources?
 => I keep getting undefined symbols such as
 => 
 => -- 
 => /lib/modules/2.4.0-xfs-new/kernel/fs/xfs/xfs.o: unresolved symbol uiomove_R
 => smp_44d42441
 => /lib/modules/2.4.0-xfs-new/kernel/fs/xfs/xfs.o: unresolved symbol _sv_init_
 => Rsmp_75cd4486
 => /lib/modules/2.4.0-xfs-new/kernel/fs/xfs/xfs.o: unresolved symbol icmn_err_
 => Rsmp_a55dffaa
 => /lib/modules/2.4.0-xfs-new/kernel/fs/xfs/xfs.o: unresolved symbol uuid_is_n
 => il_Rsmp_378f0e3b
 => /lib/modules/2.4.0-xfs-new/kernel/fs/xfs/xfs.o: unresolved symbol _sv_broad
 => cast_Rsmp_aa89645f
 => /lib/modules/2.4.0-xfs-new/kernel/fs/xfs/xfs.o: unresolved symbol mrlock_in
 => it_Rsmp_45efe373
 => ----------
 => 
 => ... and many more. I've tried the usual
 => make mrproper etc. tricks, but keep getting
 => the same results.

My TAKE yesterday split a whole heap of support stuff into a separate
module. The module is controlled by CONFIG_XFS_SUPPORT.

You'll need to run "make oldconfig" (or similar) before you build to 
get this defined. Also make sure you run "depmod -a" so the dependency
on the new module is picked up.

If you're using insmod not modprobe, you'll have to insmod
xfs/support/xfs_support.o before xfs.

-----------------------------------------------------
 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 Tue Nov 14 16:46:52 2000
Received:  by oss.sgi.com id <S553819AbQKOAqm>;
	Tue, 14 Nov 2000 16:46:42 -0800
Received: from deliverator.sgi.com ([204.94.214.10]:47226 "EHLO
        deliverator.sgi.com") by oss.sgi.com with ESMTP id <S553801AbQKOAq2>;
	Tue, 14 Nov 2000 16:46:28 -0800
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 QAA06592
	for <linux-xfs@oss.sgi.com>; Tue, 14 Nov 2000 16:38:36 -0800 (PST)
	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 QAA27193; Tue, 14 Nov 2000 16:41:09 -0800 (PST)
Message-ID: <3A11DC70.70C03FBD@sgi.com>
Date:   Tue, 14 Nov 2000 16:44:32 -0800
From:   Rajagopal Ananthanarayanan <ananth@sgi.com>
X-Mailer: Mozilla 4.72 [en] (X11; U; Linux 2.2.16-4SGI_20smp i686)
X-Accept-Language: en
MIME-Version: 1.0
To:     Daniel Moore <dxm@clouds.melbourne.sgi.com>
CC:     linux-xfs@oss.sgi.com
Subject: Re: xfs as module?
References: <200011142354.KAA05428@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:


> If you're using insmod not modprobe, you'll have to insmod
> xfs/support/xfs_support.o before xfs.
> 

Sorry, I missed the new module. Insmod xfs_support before xfs
fixed the problem.

thanks,

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

From owner-linux-xfs@oss.sgi.com Wed Nov 15 01:37:45 2000
Received:  by oss.sgi.com id <S553685AbQKOJhf>;
	Wed, 15 Nov 2000 01:37:35 -0800
Received: from hermes.mixx.net ([212.84.196.2]:34834 "HELO hermes.mixx.net")
	by oss.sgi.com with SMTP id <S553677AbQKOJhG>;
	Wed, 15 Nov 2000 01:37:06 -0800
Received: from mate.bln.innominate.de (cerberus.berlin.innominate.de [212.84.234.251])
	by hermes.mixx.net (Postfix) with ESMTP id A1A28F806
	for <linux-xfs@oss.sgi.com>; Wed, 15 Nov 2000 10:37:04 +0100 (CET)
Received: by mate.bln.innominate.de (Postfix, from userid 9)
	id EDE1A2CA6E; Wed, 15 Nov 2000 10:37:03 +0100 (CET)
From:   Thomas Graichen <news-innominate.list.sgi.xfs@innominate.de>
Reply-To: Thomas Graichen <graichen@innominate.de>
X-Newsgroups: innominate.list.sgi.xfs
Subject: Re: stress test on ppc
Date:   15 Nov 2000 09:37:03 GMT
Organization: innominate AG, Berlin, Germany
Lines:  67
Distribution: local
Message-ID: <news2mail-8utlfv$8iu$1@mate.bln.innominate.de>
References: <news2mail-8uecj0$i5e$1@mate.bln.innominate.de>   <news-innominate.list.sgi.xfs@innominate.de>   <10011101103.ZM113097@wobbly.melbourne.sgi.com>   <20001110094151.C333@ysabell>   <10011110006.ZM127189@wobbly.melbourne.sgi.com>   <news2mail-8uo7od$4lt$1@mate.bln.innominate.de> <10011141059.ZM128320@wobbly.melbourne.sgi.com>
Reply-To: thomas.graichen@innominate.de
X-Trace: mate.bln.innominate.de 974281023 8798 10.0.0.69 (15 Nov 2000 09:37:03 GMT)
X-Complaints-To: news@innominate.de
User-Agent: tin/1.4.2-20000205 ("Possession") (UNIX) (Linux/2.4.0-XFS-test10 (i586))
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

"Nathan Scott" <nathans@wobbly.melbourne.sgi.com> wrote:
> hi Thomas,

> On Nov 13,  8:11am, Thomas Graichen wrote:
>> Subject: Re: stress test on ppc
>> ...
>> > ah - I think I see whats happened - there's two -ne tests like
>> > this & last time I only fixed one ... hopefully its fixed now
>> > (as of two minutes ago).
>> 
>> ok - reran the tests with your fixes - the current results (with all
>> the failed .out and .out.bad files) can be found at
>> 
>>   http://innominate.org/~graichen/projects/xfs/ppc/ppc.13-11-2000.tgz
>> 

> ok, some progress - looks like the scratch device problem is
> resolved and test 002 is fixed - great!

> 004 - this looks like a 32 bit number overflow in the xfs_db
> "freesp" command, i'll need to investigate a bit more.

> 018 - ??? no idea - looks like theres a bunch of unexpected
> records in the log for some reason?  bizarre.

> 020 - attribute syscall code not there in ppc?

> 026/027/028/046/047 - a reoccurence of the dump/restore problems
> from Marcelo, Tim/Ivan?  or new ones?
> also group "nobody" assumed to exist, but doesn't.  can we change
> the way the test works, Tim?  or exit cleanly if no "nobody" grp?
> or use numeric gids instead of named groups perhaps?

> 032 - hmmm... could be a problem in mount(8) code which we use
> for mkfs.xfs so that it doesn't overwrite other filesystems -
> can you see whether mount on ppc can autodetect (i.e. mount
> without "-t" a filesystem created by mkfs.minix on ppc?  thanks)

will try that

the current results (with fresh kernel and fresh cmd) are at

  http://innominate.org/~graichen/procjects/xfs/ppc.15-11-2000.tgz

but they are at a rough view not really different - by maybe you
find something in them

i'm also not really shure about the syscall thing: i added sys_attrctl
to arch/ppc/kernel/misc.S (where the sys_call_table on ppc is - it's
not in entry.S here) also as nr 250 (padded with sys_ni_syscall's)
and also added it to unistd.h and recompiled and installed
everything and still get things like

  attr_set: Bad address

which looks like it does still not work - is there any other place i
have to add an entry for this new syscall?

a lot of thanks in advance

t

-- 
thomas.graichen@innominate.com
technical director                                       innominate AG
clustering & security                             the linux architects
tel: +49-30-308806-13   fax: -77             http://www.innominate.com

From owner-linux-xfs@oss.sgi.com Wed Nov 15 01:55:25 2000
Received:  by oss.sgi.com id <S553688AbQKOJzP>;
	Wed, 15 Nov 2000 01:55:15 -0800
Received: from deliverator.sgi.com ([204.94.214.10]:45925 "EHLO
        deliverator.sgi.com") by oss.sgi.com with ESMTP id <S553678AbQKOJyy>;
	Wed, 15 Nov 2000 01:54:54 -0800
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 BAA00059
	for <linux-xfs@oss.sgi.com>; Wed, 15 Nov 2000 01:46:49 -0800 (PST)
	mail_from (nathans@wobbly.melbourne.sgi.com)
Received: from wobbly.melbourne.sgi.com (wobbly.melbourne.sgi.com [134.14.55.135]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id UAA01641; Wed, 15 Nov 2000 20:53:23 +1100
Received: (from nathans@localhost) by wobbly.melbourne.sgi.com (980427.SGI.8.8.8/980728.SGI.AUTOCF) id UAA38370; Wed, 15 Nov 2000 20:53:21 +1100 (EDT)
From:   "Nathan Scott" <nathans@wobbly.melbourne.sgi.com>
Message-Id: <10011152053.ZM138831@wobbly.melbourne.sgi.com>
Date:   Wed, 15 Nov 2000 20:53:20 -0400
In-Reply-To: Danny <danscox@mindspring.com>
        "An Introduction, and some Questions" (Nov 14,  6:12pm)
References: <3A11C6E3.62F04C3D@mindspring.com>
X-Mailer: Z-Mail (3.2.3 08feb96 MediaMail)
To:     dcox@connex.com
Subject: Re: An Introduction, and some Questions
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

On Nov 14,  6:12pm, Danny wrote:
> Subject: An Introduction, and some Questions
> Hello, all!
> 
> 	By way of introduction, I'm Danny Cox, recently hired by Connex, a
> 

hi there Danny,

> ...
> 	Finally, then: once these issues are dealt with, to whom shall I send
> the diffs, assuming that folks want it?
> 

If its not too big, you could post the patch to the list (even
before the issues are dealt with if you like - its easier for
people to give help if they can reproduce the problems you're
seeing themselves).

Otherwise, you could put it in a publicly accessible place
on the web somewhere (like Thomas has been doing with his ppc
patches, and lots of other stuff) then send mail to the list
with a pointer.  Theres a couple of people here who recently
began looking into EAs and ACLs on Linux/XFS & they'll start
going over your changes as soon as you do...

cheers.

-- 
Nathan

From owner-linux-xfs@oss.sgi.com Wed Nov 15 03:20:35 2000
Received:  by oss.sgi.com id <S553709AbQKOLUZ>;
	Wed, 15 Nov 2000 03:20:25 -0800
Received: from plutonium.uunet.be ([194.7.1.47]:1804 "EHLO plutonium.uunet.be")
	by oss.sgi.com with ESMTP id <S553691AbQKOLUH>;
	Wed, 15 Nov 2000 03:20:07 -0800
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 MAA19711
	for <linux-xfs@oss.sgi.com>; Wed, 15 Nov 2000 12:20:04 +0100 (CET)
Received: from pcgx14500003.vum.be (pcgx14500003 [83.105.1.4]) by leonidas.vum.be with ESMTP (8.7.6/8.7.1) id MAA17771 for <linux-xfs@oss.sgi.com>; Wed, 15 Nov 2000 12:22:13 +0100 (MET)
Received: from vum.be (IDENT:kris@localhost.localdomain [127.0.0.1])
	by pcgx14500003.vum.be (8.9.3/8.8.7) with ESMTP id MAA18069
	for <linux-xfs@oss.sgi.com>; Wed, 15 Nov 2000 12:19:32 +0100
Message-ID: <3A127144.BFD8F5E6@vum.be>
Date:   Wed, 15 Nov 2000 12:19:32 +0100
From:   kris buggenhout <gast6@vum.be>
X-Mailer: Mozilla 4.75 [en] (X11; U; Linux 2.4.0-test5 i686)
X-Accept-Language: en
MIME-Version: 1.0
To:     linux-xfs@oss.sgi.com
Subject: Re: xfs on a sparc64
References: <200011102123.PAA30359@jen.americas.sgi.com>
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: base64
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing

T2ssIEkgZ290IHRvIHRoZSBwb2ludCBpIGhhdmUgYSBib290YWJsZSBrZXJuZWwgd2l0aCBh
c3NvY2lhdGVkIG1vZHVsZXMuDQoNCmJ1dCB3aGVuIEkgdHJ5IHRvIGxvYWQgdGhlIHhmcyBt
b2R1bGUgaSBnZXQgYSBidXMgZXJyb3IgKC1jb3JlIGR1bXBlZCkNCg0KSSByZSBjb21waWxl
ZCwgYW5kIG1hZGUgcGFnZWJ1ZiBhIG1vZHVsZSB0b28sIHdoZW4gSSBpbnNtb2QgdGhhdCAu
LiBpdCBjb3JlIGR1bXBzDQooYnVzIGVycm9yKQ0KDQphbnkgc3VnZ2VzdGlvbnMgPw0KDQoN
ClRobngNCg0K

From owner-linux-xfs@oss.sgi.com Wed Nov 15 05:22:57 2000
Received:  by oss.sgi.com id <S553734AbQKONWg>;
	Wed, 15 Nov 2000 05:22:36 -0800
Received: from tux.mkp.net ([130.225.60.11]:51716 "EHLO tux.mkp.net")
	by oss.sgi.com with ESMTP id <S553696AbQKONW0>;
	Wed, 15 Nov 2000 05:22:26 -0800
Received: from tux.mkp.net ([130.225.60.11] helo=jaguar.mkp.net)
	by tux.mkp.net with esmtp (Exim 3.14 #2)
	id 13w2Mz-0007cC-00; Wed, 15 Nov 2000 14:12:57 +0100
Received: (from mkp@localhost)
	by jaguar.mkp.net (8.9.3/8.9.3) id IAA00797;
	Wed, 15 Nov 2000 08:22:58 -0500
X-Authentication-Warning: jaguar.mkp.net: mkp set sender to mkp@mkp.net using -f
To:     kris buggenhout <gast6@vum.be>
Cc:     linux-xfs@oss.sgi.com, kaos@melbourne.sgi.com
Subject: Re: xfs on a sparc64
References: <200011102123.PAA30359@jen.americas.sgi.com>
	<3A127144.BFD8F5E6@vum.be>
From:   "Martin K. Petersen" <mkp@linuxcare.com>
Organization: Linuxcare, Inc.
Date:   15 Nov 2000 08:22:58 -0500
In-Reply-To: kris buggenhout's message of "Wed, 15 Nov 2000 12:19:32 +0100"
Message-ID: <yq1r94did3h.fsf@jaguar.mkp.net>
Lines:  26
User-Agent: Gnus/5.0807 (Gnus v5.8.7) XEmacs/21.1 (Canyonlands)
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

>>>>> "kris" == kris buggenhout <gast6@vum.be> writes:

kris> Ok, I got to the point i have a bootable kernel with associated
kris> modules.  but when I try to load the xfs module i get a bus
kris> error (-core dumped)

kris> I re compiled, and made pagebuf a module too, when I insmod that
kris> .. it core dumps (bus error)

kris> any suggestions ?

modutils problem.

I ended up getting the modutils package from the Red Hat rawhide
directory (modutils-2.3.17-3).

The pristine tarball doesn't work on SPARC, I'm afraid.  Reported it
to Anton Blanchard who said he'd take a look at it.  

Keith, do you have access to sparc64 boxen?

-- 
Martin K. Petersen, Principal Linux Consultant, Linuxcare, Inc.
mkp@linuxcare.com, http://www.linuxcare.com/
Linuxcare. Moving Forward.


From owner-linux-xfs@oss.sgi.com Wed Nov 15 05:35:57 2000
Received:  by oss.sgi.com id <S553728AbQKONfr>;
	Wed, 15 Nov 2000 05:35:47 -0800
Received: from thorium.uunet.be ([194.7.1.46]:26117 "EHLO thorium.uunet.be")
	by oss.sgi.com with ESMTP id <S553695AbQKONf3>;
	Wed, 15 Nov 2000 05:35:29 -0800
Received: from gate.vum.be (firewall.vum.be [194.7.240.162])
	by thorium.uunet.be (8.9.1/8.9.3) with SMTP id OAA20003;
	Wed, 15 Nov 2000 14:35:22 +0100 (CET)
Received: from pcgx14500003.vum.be (pcgx14500003 [83.105.1.4]) by leonidas.vum.be with ESMTP (8.7.6/8.7.1) id OAA09702; Wed, 15 Nov 2000 14:37:28 +0100 (MET)
Received: from vum.be (IDENT:kris@localhost.localdomain [127.0.0.1])
	by pcgx14500003.vum.be (8.9.3/8.8.7) with ESMTP id OAA19178;
	Wed, 15 Nov 2000 14:34:47 +0100
Message-ID: <3A1290F6.153AE744@vum.be>
Date:   Wed, 15 Nov 2000 14:34:46 +0100
From:   kris buggenhout <gast6@vum.be>
X-Mailer: Mozilla 4.75 [en] (X11; U; Linux 2.4.0-test5 i686)
X-Accept-Language: en
MIME-Version: 1.0
To:     "Martin K. Petersen" <mkp@linuxcare.com>, linux-xfs@oss.sgi.com
Subject: Re: xfs on a sparc64
References: <200011102123.PAA30359@jen.americas.sgi.com>
		<3A127144.BFD8F5E6@vum.be> <yq1r94did3h.fsf@jaguar.mkp.net>
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: base64
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing

Ik1hcnRpbiBLLiBQZXRlcnNlbiIgd3JvdGU6DQoNCj4gPj4+Pj4gImtyaXMiID09IGtyaXMg
YnVnZ2VuaG91dCA8Z2FzdDZAdnVtLmJlPiB3cml0ZXM6DQo+DQo+IGtyaXM+IE9rLCBJIGdv
dCB0byB0aGUgcG9pbnQgaSBoYXZlIGEgYm9vdGFibGUga2VybmVsIHdpdGggYXNzb2NpYXRl
ZA0KPiBrcmlzPiBtb2R1bGVzLiAgYnV0IHdoZW4gSSB0cnkgdG8gbG9hZCB0aGUgeGZzIG1v
ZHVsZSBpIGdldCBhIGJ1cw0KPiBrcmlzPiBlcnJvciAoLWNvcmUgZHVtcGVkKQ0KPg0KPiBr
cmlzPiBJIHJlIGNvbXBpbGVkLCBhbmQgbWFkZSBwYWdlYnVmIGEgbW9kdWxlIHRvbywgd2hl
biBJIGluc21vZCB0aGF0DQo+IGtyaXM+IC4uIGl0IGNvcmUgZHVtcHMgKGJ1cyBlcnJvcikN
Cj4NCj4ga3Jpcz4gYW55IHN1Z2dlc3Rpb25zID8NCj4NCj4gbW9kdXRpbHMgcHJvYmxlbS4N
Cj4NCj4gSSBlbmRlZCB1cCBnZXR0aW5nIHRoZSBtb2R1dGlscyBwYWNrYWdlIGZyb20gdGhl
IFJlZCBIYXQgcmF3aGlkZQ0KPiBkaXJlY3RvcnkgKG1vZHV0aWxzLTIuMy4xNy0zKS4NCj4N
Cj4gVGhlIHByaXN0aW5lIHRhcmJhbGwgZG9lc24ndCB3b3JrIG9uIFNQQVJDLCBJJ20gYWZy
YWlkLiAgUmVwb3J0ZWQgaXQNCj4gdG8gQW50b24gQmxhbmNoYXJkIHdobyBzYWlkIGhlJ2Qg
dGFrZSBhIGxvb2sgYXQgaXQuDQoNCmhtbSA6DQoNCltyb290QHdpbm5ldG91IC9yb290XSMg
aW5zbW9kIC1WDQppbnNtb2QgdmVyc2lvbiAyLjMuMTkNCg0KOikNCg0KSSBoYWQgMi4zLjE2
IC4uLiBidXQgdGhvdWdodCB0aGF0IG1pZ2h0IGJlIHRoZSBwcm9ibGVtLCBhcyBJIHdhcyBo
YXZpbmcNCm90aGVyIHByb2JsZW1zIHRvbywgbGlrZSBjZXJ0YWluIG1vZHVsZXMgd291bGRu
dCBhdXRvIGxvYWQuLi4NCnRoZXkgZG8gYXV0b2xvYWQgbm93IC4uIGFzIGRvIG90aGVyIG1v
ZHVsZXMuDQpidXQgb25seSBwYWdlYnVmICwgeGZzX3N1cHBvcnQgIGRvIGEgYnVzIGVycm9y
DQoNCg==

From owner-linux-xfs@oss.sgi.com Wed Nov 15 05:44:56 2000
Received:  by oss.sgi.com id <S553753AbQKONoh>;
	Wed, 15 Nov 2000 05:44:37 -0800
Received: from tux.mkp.net ([130.225.60.11]:2309 "EHLO tux.mkp.net")
	by oss.sgi.com with ESMTP id <S553726AbQKONob>;
	Wed, 15 Nov 2000 05:44:31 -0800
Received: from tux.mkp.net ([130.225.60.11] helo=jaguar.mkp.net)
	by tux.mkp.net with esmtp (Exim 3.14 #2)
	id 13w2iS-0007dO-00; Wed, 15 Nov 2000 14:35:09 +0100
Received: (from mkp@localhost)
	by jaguar.mkp.net (8.9.3/8.9.3) id IAA00806;
	Wed, 15 Nov 2000 08:45:10 -0500
X-Authentication-Warning: jaguar.mkp.net: mkp set sender to mkp@mkp.net using -f
To:     kris buggenhout <gast6@vum.be>
Cc:     linux-xfs@oss.sgi.com
Subject: Re: xfs on a sparc64
References: <200011102123.PAA30359@jen.americas.sgi.com>
	<3A127144.BFD8F5E6@vum.be> <yq1r94did3h.fsf@jaguar.mkp.net>
	<3A1290F6.153AE744@vum.be>
From:   "Martin K. Petersen" <mkp@linuxcare.com>
Organization: Linuxcare, Inc.
Date:   15 Nov 2000 08:45:10 -0500
In-Reply-To: kris buggenhout's message of "Wed, 15 Nov 2000 14:34:46 +0100"
Message-ID: <yq1d7fxic2h.fsf@jaguar.mkp.net>
Lines:  20
User-Agent: Gnus/5.0807 (Gnus v5.8.7) XEmacs/21.1 (Canyonlands)
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

>>>>> "kris" == kris buggenhout <gast6@vum.be> writes:

>> I ended up getting the modutils package from the Red Hat rawhide
>> directory (modutils-2.3.17-3).
>>
>> The pristine tarball doesn't work on SPARC, I'm afraid.  Reported
>> it to Anton Blanchard who said he'd take a look at it.

kris> hmm :

kris> [root@winnetou /root]# insmod -V insmod version 2.3.19

It doesn't really matter which version you are using.  There's a patch
in the rawhide RPM that fixes relocation on SPARC.

-- 
Martin K. Petersen, Principal Linux Consultant, Linuxcare, Inc.
mkp@linuxcare.com, http://www.linuxcare.com/
Linuxcare. Moving Forward.


From owner-linux-xfs@oss.sgi.com Wed Nov 15 06:47:36 2000
Received:  by oss.sgi.com id <S553767AbQKOOr0>;
	Wed, 15 Nov 2000 06:47:26 -0800
Received: from pneumatic-tube.sgi.com ([204.94.214.22]:38492 "EHLO
        pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP
	id <S553747AbQKOOrU>; Wed, 15 Nov 2000 06:47:20 -0800
Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id GAA02941
	for <linux-xfs@oss.sgi.com>; Wed, 15 Nov 2000 06:55:06 -0800 (PST)
	mail_from (lord@jen.americas.sgi.com)
Received: from thistle-e185.americas.sgi.com (thistle-e185.americas.sgi.com [128.162.185.204]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id IAA7582471; Wed, 15 Nov 2000 08:46:03 -0600 (CST)
Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.184.86]) by thistle-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id IAA95964; Wed, 15 Nov 2000 08:46:03 -0600 (CST)
Received: from jen.americas.sgi.com (lord@localhost)
	by jen.americas.sgi.com (8.9.3/8.9.3) with ESMTP id IAA29281;
	Wed, 15 Nov 2000 08:40:09 -0600
Message-Id: <200011151440.IAA29281@jen.americas.sgi.com>
X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4
To:     Russel Ingram <ringram@gargoylecc.com>
cc:     linux-xfs@oss.sgi.com
Subject: Re: XFS with ReiserFS 
In-Reply-To: Message from Russel Ingram <ringram@gargoylecc.com> 
   of "Wed, 15 Nov 2000 07:24:23 MST." <Pine.LNX.4.21.0011150718170.20366-100000@roujin.gargoylecc.com> 
Date:   Wed, 15 Nov 2000 08:40:09 -0600
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

> Does anyone know if the xfs beta kernel source can be patched with the
> reiserfs patch to create a working kernel with support for both
> filesystems?  I have a system that is already running reiserfs and want to
> give xfs a try but can't if I can't get a kernel that supports both.

Since we have a bunch of changes outside the xfs code itself, the 
simplest way to do this would be to take the xfs cvs development tree
(which is 2.4.0-test10 based) and apply a ReiserFS patch to this tree.
You will almost certainly get conflicts in the fs/Makefile and 
include/linux/fs.h files since we probably land right on top of each
other. However, these should be fairly simple to resolve - you will
just need both sets of code.

Steve

> 
> TIA,
> Russ
> 
> Russel Ingram
> Gargoyle Computer Consulting
> http://www.gargoylecc.com



From owner-linux-xfs@oss.sgi.com Wed Nov 15 07:05:28 2000
Received:  by oss.sgi.com id <S553769AbQKOPFI>;
	Wed, 15 Nov 2000 07:05:08 -0800
Received: from plutonium.uunet.be ([194.7.1.47]:17928 "EHLO plutonium.uunet.be")
	by oss.sgi.com with ESMTP id <S553765AbQKOPEj>;
	Wed, 15 Nov 2000 07:04:39 -0800
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 QAA07823;
	Wed, 15 Nov 2000 16:04:32 +0100 (CET)
Received: from pcgx14500003.vum.be (pcgx14500003 [83.105.1.4]) by leonidas.vum.be with ESMTP (8.7.6/8.7.1) id QAA13280; Wed, 15 Nov 2000 16:06:39 +0100 (MET)
Received: from vum.be (IDENT:kris@localhost.localdomain [127.0.0.1])
	by pcgx14500003.vum.be (8.9.3/8.8.7) with ESMTP id QAA19425;
	Wed, 15 Nov 2000 16:03:58 +0100
Message-ID: <3A12A5DE.105B9913@vum.be>
Date:   Wed, 15 Nov 2000 16:03:58 +0100
From:   kris buggenhout <gast6@vum.be>
X-Mailer: Mozilla 4.75 [en] (X11; U; Linux 2.4.0-test5 i686)
X-Accept-Language: en
MIME-Version: 1.0
To:     "Martin K. Petersen" <mkp@linuxcare.com>, linux-xfs@oss.sgi.com
Subject: Re: xfs on a sparc64
References: <200011102123.PAA30359@jen.americas.sgi.com>
		<3A127144.BFD8F5E6@vum.be> <yq1r94did3h.fsf@jaguar.mkp.net>
		<3A1290F6.153AE744@vum.be> <yq1d7fxic2h.fsf@jaguar.mkp.net>
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: base64
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing

Ik1hcnRpbiBLLiBQZXRlcnNlbiIgd3JvdGU6DQoNCj4gPj4+Pj4gImtyaXMiID09IGtyaXMg
YnVnZ2VuaG91dCA8Z2FzdDZAdnVtLmJlPiB3cml0ZXM6DQo+DQo+ID4+IEkgZW5kZWQgdXAg
Z2V0dGluZyB0aGUgbW9kdXRpbHMgcGFja2FnZSBmcm9tIHRoZSBSZWQgSGF0IHJhd2hpZGUN
Cj4gPj4gZGlyZWN0b3J5IChtb2R1dGlscy0yLjMuMTctMykuDQo+ID4+DQo+ID4+IFRoZSBw
cmlzdGluZSB0YXJiYWxsIGRvZXNuJ3Qgd29yayBvbiBTUEFSQywgSSdtIGFmcmFpZC4gIFJl
cG9ydGVkDQo+ID4+IGl0IHRvIEFudG9uIEJsYW5jaGFyZCB3aG8gc2FpZCBoZSdkIHRha2Ug
YSBsb29rIGF0IGl0Lg0KPg0KPiBrcmlzPiBobW0gOg0KPg0KPiBrcmlzPiBbcm9vdEB3aW5u
ZXRvdSAvcm9vdF0jIGluc21vZCAtViBpbnNtb2QgdmVyc2lvbiAyLjMuMTkNCj4NCj4gSXQg
ZG9lc24ndCByZWFsbHkgbWF0dGVyIHdoaWNoIHZlcnNpb24geW91IGFyZSB1c2luZy4gIFRo
ZXJlJ3MgYSBwYXRjaA0KPiBpbiB0aGUgcmF3aGlkZSBSUE0gdGhhdCBmaXhlcyByZWxvY2F0
aW9uIG9uIFNQQVJDLg0KPg0KDQpUaG54IC4uLiBmaXhlZCAuLi4NCg0KaGF2ZSBhIHJ1bm5p
bmcgeGZzIHBhcnRpdGlvbi4uLiAxOCBHaWcgLi4uIGZpbGxpbmcgaXQgdXAgd2l0aCBqdW5r
DQpkYXRhLi4uDQpnb25uYSBkbyBzb21lIHRlc3RzIC4uLg0KDQpzdHJlc3MgdGVzdHMgZXRj
Li4uDQoNCg0KDQo=

From owner-linux-xfs@oss.sgi.com Wed Nov 15 07:35:58 2000
Received:  by oss.sgi.com id <S553780AbQKOPfs>;
	Wed, 15 Nov 2000 07:35:48 -0800
Received: from hermes.mixx.net ([212.84.196.2]:46864 "HELO hermes.mixx.net")
	by oss.sgi.com with SMTP id <S553768AbQKOPf3>;
	Wed, 15 Nov 2000 07:35:29 -0800
Received: from mate.bln.innominate.de (cerberus.berlin.innominate.de [212.84.234.251])
	by hermes.mixx.net (Postfix) with ESMTP id A8507F80B
	for <linux-xfs@oss.sgi.com>; Wed, 15 Nov 2000 16:35:26 +0100 (CET)
Received: by mate.bln.innominate.de (Postfix, from userid 9)
	id 4255A2CA9F; Wed, 15 Nov 2000 16:35:25 +0100 (CET)
From:   Thomas Graichen <news-innominate.list.sgi.xfs@innominate.de>
Reply-To: Thomas Graichen <graichen@innominate.de>
X-Newsgroups: innominate.list.sgi.xfs
Subject: Re: xfs on a sparc64
Date:   15 Nov 2000 15:35:25 GMT
Organization: innominate AG, Berlin, Germany
Lines:  25
Distribution: local
Message-ID: <news2mail-8uuaft$snr$1@mate.bln.innominate.de>
References: <200011102123.PAA30359@jen.americas.sgi.com>   <3A127144.BFD8F5E6@vum.be> <yq1r94did3h.fsf@jaguar.mkp.net>   <3A1290F6.153AE744@vum.be> <yq1d7fxic2h.fsf@jaguar.mkp.net> <3A12A5DE.105B9913@vum.be>
Reply-To: thomas.graichen@innominate.de
X-Trace: mate.bln.innominate.de 974302525 29435 10.0.0.31 (15 Nov 2000 15:35:25 GMT)
X-Complaints-To: news@innominate.de
User-Agent: tin/1.4.4-20000803 ("Vet for the Insane") (UNIX) (Linux/2.4.0-XFS-test10 (i686))
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

kris buggenhout <gast6@vum.be> wrote:

> Thnx ... fixed ...

> have a running xfs partition... 18 Gig ... filling it up with junk
> data...
> gonna do some tests ...

> stress tests etc...

do you also see the problems i saw on the alpha (see my other posting)
with mkfs, mount, umount, xfs_repair -> problems ? - would be good to
compare all the alpha and sparc64 problems to find out what is arch-
or compilerspecific and what depends on 64bit there ...

t

p.s.: if you don't find my posting - just mail me and i can forward
      it to you

-- 
thomas.graichen@innominate.com
technical director                                       innominate AG
clustering & security                             the linux architects
tel: +49-30-308806-13   fax: -77             http://www.innominate.com

From owner-linux-xfs@oss.sgi.com Wed Nov 15 08:00:49 2000
Received:  by oss.sgi.com id <S553800AbQKOQA3>;
	Wed, 15 Nov 2000 08:00:29 -0800
Received: from hermes.mixx.net ([212.84.196.2]:32273 "HELO hermes.mixx.net")
	by oss.sgi.com with SMTP id <S553787AbQKOQAR>;
	Wed, 15 Nov 2000 08:00:17 -0800
Received: from mate.bln.innominate.de (cerberus.berlin.innominate.de [212.84.234.251])
	by hermes.mixx.net (Postfix) with ESMTP id 72913F818
	for <linux-xfs@oss.sgi.com>; Wed, 15 Nov 2000 17:00:15 +0100 (CET)
Received: by mate.bln.innominate.de (Postfix, from userid 9)
	id 12E2D2CAA2; Wed, 15 Nov 2000 17:00:15 +0100 (CET)
From:   Thomas Graichen <news-innominate.list.sgi.xfs@innominate.de>
Reply-To: Thomas Graichen <graichen@innominate.de>
X-Newsgroups: innominate.list.sgi.xfs
Subject: type things on the alpha
Date:   15 Nov 2000 16:00:14 GMT
Organization: innominate AG, Berlin, Germany
Lines:  27
Distribution: local
Message-ID: <news2mail-8uubue$9qp$1@mate.bln.innominate.de>
Reply-To: thomas.graichen@innominate.de
X-Trace: mate.bln.innominate.de 974304014 10073 10.0.0.31 (15 Nov 2000 16:00:14 GMT)
X-Complaints-To: news@innominate.de
User-Agent: tin/1.4.4-20000803 ("Vet for the Insane") (UNIX) (Linux/2.4.0-XFS-test10 (i686))
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

two more warnings i noticed on the alpha:

  xfs_file.c:311: warning: initialization from incompatible pointer type

so linvfs_file_lseek should be typed cleaner in xfs_file.c and

  xfs_vnode.c: In function `vn_trace_entry':
  xfs_vnode.c:660: warning: cast to pointer from integer of different size
  xfs_vnode.c: In function `vn_trace_exit':
  xfs_vnode.c:676: warning: cast to pointer from integer of different size
  xfs_vnode.c: In function `vn_trace_hold':
  xfs_vnode.c:692: warning: cast to pointer from integer of different size
  xfs_vnode.c: In function `vn_trace_ref':
  xfs_vnode.c:708: warning: cast to pointer from integer of different size
  xfs_vnode.c: In function `vn_trace_rele':
  xfs_vnode.c:724: warning: cast to pointer from integer of different size

so it should always be casted correctly ... but i can't really
concentrate any more right now - will better go home now ...

t

-- 
thomas.graichen@innominate.com
technical director                                       innominate AG
clustering & security                             the linux architects
tel: +49-30-308806-13   fax: -77             http://www.innominate.com

From owner-linux-xfs@oss.sgi.com Wed Nov 15 08:42:19 2000
Received:  by oss.sgi.com id <S553771AbQKOQl7>;
	Wed, 15 Nov 2000 08:41:59 -0800
Received: from plutonium.uunet.be ([194.7.1.47]:524 "EHLO plutonium.uunet.be")
	by oss.sgi.com with ESMTP id <S553706AbQKOQlg>;
	Wed, 15 Nov 2000 08:41:36 -0800
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 RAA11555
	for <linux-xfs@oss.sgi.com>; Wed, 15 Nov 2000 17:41:33 +0100 (CET)
Received: from pcgx14500003.vum.be (pcgx14500003 [83.105.1.4]) by leonidas.vum.be with ESMTP (8.7.6/8.7.1) id RAA11647 for <linux-xfs@oss.sgi.com>; Wed, 15 Nov 2000 17:43:39 +0100 (MET)
Received: from vum.be (IDENT:kris@localhost.localdomain [127.0.0.1])
	by pcgx14500003.vum.be (8.9.3/8.8.7) with ESMTP id RAA19621
	for <linux-xfs@oss.sgi.com>; Wed, 15 Nov 2000 17:40:59 +0100
Message-ID: <3A12BC9B.30D04CCF@vum.be>
Date:   Wed, 15 Nov 2000 17:40:59 +0100
From:   kris buggenhout <gast6@vum.be>
X-Mailer: Mozilla 4.75 [en] (X11; U; Linux 2.4.0-test5 i686)
X-Accept-Language: en
MIME-Version: 1.0
To:     linux-xfs@oss.sgi.com
Subject: XFS on sparc 64
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: base64
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing

dGhpcyBpcyB3aGF0IEkgZ2V0DQp3cml0ZSBlcnJvcg0KDQp1bW91bnQgaGFuZ3MgLi4uDQoN
CmFuZCBzaHV0ZG93biBubyBnbyAuLi4NCmluaXQgNiBoYW5ncyAuLi4gKHVtb3VudCkNCg0K
Tm92IDE1IDE1OjU4OjU1IHdpbm5ldG91IGtlcm5lbDogU3RhcnQgbW91bnRpbmcgZmlsZXN5
c3RlbTogc2QoOCw2NykNCk5vdiAxNSAxNTo1ODo1NSB3aW5uZXRvdSBrZXJuZWw6IEVuZGlu
ZyBjbGVhbiBYRlMgbW91bnQgZm9yIGZpbGVzeXN0ZW06DQpzZCg4LDY3KQ0KTm92IDE1IDE2
OjAzOjAxIHdpbm5ldG91IGtlcm5lbDogSS9PIEVycm9yIERldGVjdGVkLiAgU2h1dHRpbmcg
ZG93bg0KZmlsZXN5c3RlbTogc2QoOCw2NykNCk5vdiAxNSAxNjowMzowMSB3aW5uZXRvdSBr
ZXJuZWw6IFBsZWFzZSB1bW91bnQgdGhlIGZpbGVzeXN0ZW0sIGFuZA0KcmVjdGlmeSB0aGUg
cHJvYmxlbShzKQ0KTm92IDE1IDE2OjAzOjAxIHdpbm5ldG91IGtlcm5lbDogUENEOiBwYWdl
YnVmX2JtYXAgZXJyb3IgLTEwMTAgcGJfZmxhZ3MNCjB4MTAwMTAwMDINCk5vdiAxNSAxNjow
MzowMSB3aW5uZXRvdSBrZXJuZWw6IFBDRDogcGFnZWJ1Zl9ibWFwIGVycm9yIC01IHBiX2Zs
YWdzDQoweDEwMDEwMDAyDQpOb3YgMTUgMTY6MDM6MzMgd2lubmV0b3UgbGFzdCBtZXNzYWdl
IHJlcGVhdGVkIDYyMyB0aW1lcw0KTm92IDE1IDE2OjAzOjQ3IHdpbm5ldG91IGxhc3QgbWVz
c2FnZSByZXBlYXRlZCAyODUgdGltZXMNCg0K

From owner-linux-xfs@oss.sgi.com Wed Nov 15 12:35:00 2000
Received:  by oss.sgi.com id <S553787AbQKOUet>;
	Wed, 15 Nov 2000 12:34:49 -0800
Received: from smtp6.mindspring.com ([207.69.200.110]:21036 "EHLO
        smtp6.mindspring.com") by oss.sgi.com with ESMTP id <S553778AbQKOUep>;
	Wed, 15 Nov 2000 12:34:45 -0800
Received: from mindspring.com (user-38lcncq.dialup.mindspring.com [209.86.93.154])
	by smtp6.mindspring.com (8.9.3/8.8.5) with ESMTP id PAA11048
	for <linux-xfs@oss.sgi.com>; Wed, 15 Nov 2000 15:34:30 -0500 (EST)
Message-ID: <3A12F580.68F8EB7D@mindspring.com>
Date:   Wed, 15 Nov 2000 15:43:44 -0500
From:   Danny <danscox@mindspring.com>
Organization: Connex Inc
X-Mailer: Mozilla 4.75 [en] (X11; U; Linux 2.4.0-XFS-test8 i686)
X-Accept-Language: en
MIME-Version: 1.0
To:     linux-xfs@oss.sgi.com
Subject: XFS ACL Patch
References: <3A11C6E3.62F04C3D@mindspring.com> <10011152053.ZM138831@wobbly.melbourne.sgi.com>
Content-Type: multipart/mixed;
 boundary="------------D2D5C20439DB0E109D59E290"
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.
--------------D2D5C20439DB0E109D59E290
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

All,

Nathan Scott wrote:
> 
> If its not too big, you could post the patch to the list (even
> before the issues are dealt with if you like - its easier for
> people to give help if they can reproduce the problems you're
> seeing themselves).

	Okay, here goes!  I've attached the patch.  B2Zipped, it's about 20K. 
Sorry if you're on a dialup, like me ;-(.

	If others would look over my code, and test the dickens (a very
technical term) out of this patch, I'd appreciate it.

	To reiterate, the problems I'm having are:

	First: If I set an ACL, and immediatly attempt to excersize it
(notablly turning off owner execute), it fails.  Inserting an acl_get(2)
or a stat(2) between the acl_set(2) and execl(2) attempt, corrects the
problem.

	Second: sometimes after running the test suite, the executable becomes
unable to execute any more, failing with 'Text file busy'.  The XFS
partition can't be unmounted after that point.  Sorry, I've not been
able to narrow this one any further.

	Third: my use of VOP_READ_LOCK in the VOP_ACL_GET(...) macro in
xfs/linux/xfs_vnode.h.  Is it necessary?  Since it in turn calls
VOP_ATTR_GET, it will attempt to lock it twice.  Is that a Good Thing,
or like in pthreads, a Bad Thing?  Under Linux, by the by, the
VOP_READ_LOCK is #defined away to nothing, so I can't look at the
vop_read_lock function to understand it ;-(.

	Thanks, and have fun!
--

Remember: life is too important to take seriously!

Danny
--------------D2D5C20439DB0E109D59E290
Content-Type: application/octet-stream;
 name="acl.patch.bz2"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
 filename="acl.patch.bz2"

QlpoOTFBWSZTWWRtdh4AgiX/gH//YAJ//////////r////9gbb3vNAaViADoBzvs89oe289Y
nG5t5g+9rx3PhfXqc+GHd22tcXFm6XQNtsQUKDVPgACAAAzvfOeXhbKj0A3t7A6Zy7EXi+3v
FR5swAAd92E9Edtdm9txmvIM9sexbtrdlHRoHVBr3Y8tueQHgbzezq9dNtSjmW7bpKgUtSxc
nVdVWvXHTUqInued6pzrmF1CHLQTpbFSD3Mr3mlDd2Bqt13bktbFe7LuZl7Gs7Di7MWIsNXr
3NsaPTMd3dhjb3NRxZKAvdjqUZN64XKmvNugiovBzj150Z6OXLW65eWXm9nCUAgLmysndrzw
lBAEBNAIjEAEJtATGiMSm1PUZP0NJpPUGmgGI0EVPJ/6qmFSAANAAAA0aANAAAAAAaAACQSI
SCeoCnpU/EGqfqPGqGh6ofpHqnqNMaJtIYhoMhpk9I09RtQJPVKiRoVNBk9R6amgDQ0ADRkN
AAAAAAAAAiSEIBMQEwSaaZGp5E1NqYnlT02pinmk2oQ00ZNqBk0PSDBUUQQCAQBNExTGIp6e
qeGij1GJ5Keo8oHpqekeoNPRNAHqfL29+aWNk00sqbNZSSUCBAhGJDzINIgk8rZ/BvIjYuV5
XGMgffMNDD+0/+o0ZkTIMG22wgOQ/WPpOT4H0h9RTnltnLlX9mK4QGNg2NxwnJdruLql0bLl
EvrOel12TGsaBwcDE2mxs8SL901Gf26VZwHeURRgwY/yn8v74/4yH5T+Eh/SeZ27AxnoIowa
7rxhRl9G6bd1EODRE2iEHarVHRYSVQEzBUcKQiTThR2uUZQaf7aS1ANIyEGRtERB6B10KDZQ
rYFJIxwbGMIEeCwyPHHlyBjxjGGJ/WkBEFYMaDUiFj0QjTaG2mSEhaURKlECf5kb2MlAsHE/
TBSsIf075xkCQf9gRh0Zc9vB/R/Mb2Nb8rCiI4xpfjn7R6g/Hd+zhgw0YQgyZAVY2zu4fxLl
GFC7SxWka5jqtDUUFh9MQveg8v+n7zFwQZfzf1Uptt76OASF4PXG40fgtMWcoCtsy5zklqut
rq3BIHNuuDs67k7p3Zd0a158eE2geM67a7szOqlxY1xbt26vbe+92ChJtulG3COKEIn3UCjj
Sp7A1WOQh7rB2dh8BcKA47ChXE2zQgsrRijBjsCjMIFsAxoNBLSDJjbbcBFaY5IVhBg2rW25
YVldY1ZCktIUlhXKKSBBtsUEyShRlHhaVN1IBl8UppmmMkIgbTZiShIghBkRCRrUCkdeYY0I
zIxg2RMQyDJEOKERhXCEZCuFbdoRMUQyDIyVlo4VttlHKW2qsJRmrmNubcccY5KUGmPUqG3H
GRmWJobSYwQ7ig0SjpBtNMJ9H5bInqODQgoWh+r/6Rj+C2qvgUSViI+cB5QAk7EYRj79Rnp4
35QjX78ka7PsP+WZ4nZU/U/R1byOaoM2k+PKhdS6XDM256+KYw8e/c00n7ZP0mf+/WQ/2QrP
6sfJH3U9A2ebJ6YEDu+Ap3Y33yPLBo6M95nrnVzJE36sOmi863NDDtkIxNPNMpD4vDSrWx5S
Y9Ns096wweIjjNEHxTyQ0uNxEYkQfaQcjY7OXGbcTaeOJm4vV85vTOUg1KR++ez+SLTHNKsH
28MHdM0gbUWpWwp/Az79z+vh0rX07BejMvkTvU42oq0DKw9Q3fUoHNDyhIsiM6D0fgao4wiV
UkPQoFXsf4D4Z68Y13VbtbjLP/v1br88f+ft49b0YvZe2PDKmW9+vfW1M2uX5zaJ4aS77NMX
35Zk7VatkOK2LVLUZIgFniRH4zjF2Y1mLf5+t//L1OFzJ/D35arquAirPI24Jc1aBk4Iib4g
uGE1Ufw3pgiqoLhRGdP8RqLm2+qIb2TvKkHg1n4/vw2a3gfbuR8RTxfd/J/OQ4+ezlH9lkU9
QxXTRvdv5LIEKL8JIYLOxYtP+v2kPi0T0Hqkncx3KFa7CwlZc0YSoYxUp9z6ECoYMBGSIXPV
Ckq1e5iMPrhyWJg12OcP5yBTI2GmRuA+74B4y/pzwZRsZmMUR+rytWA9MWke59B2ODrbkXgt
+v7++Ta8N9/+NztB8B8eYNyR3erjcho8zAuka5WNlzHmDYnAqMhFhLS1OaaJe2vZuvReeydr
py0dvsl6+ITMi0TEVoiMiQjRSaJYhD6Lb8VC4cYOI9pohZxueQvNID3JAfMKT971YaPIvm/4
PmPsaOUJFSbuUJHyO378nx6tO37dOW1vo9rd9LyH6qlWPxvX662RVVU9nx30Zr2qKKHaDfNn
n+r8Pw/B/Jzq7ZCCIGKJqZDQmyHgU4bZT9OMabJ5HKyGqoZVIZaNMMmiqsiyukkBQZZTEHAx
GgUNfKj9NgZZF4DNidT4189FpkCBCkIXMZ8MzJ1Fb8esDeaYRjGMia1rZtGzbu91LuON2HWQ
fqkHhoorrppl+KUzCR9Luawka/BsbK4bvkyaP3vqaMvwY3zyt7PEnc5TMYrae64npVkTPPHx
vxz651IKyQftIWg2ZHu+BNhpNZ5RlVUODwkPCq9JUYSQndTRC8CiKnOq0jRPGBqjnen37LWB
JAvAalR+DDlmSQZ4cQztDnZvWI+9MqknFPf5YCP0OBWzhhkwls8X3reLIq/8Bdc8CmLdsPm7
1ZdPHjj7IaCmSx+Ng/wt44+c3ShlAelHjP+/7S9ueDXpSLKsIxN6idsDvInOSH/yfvmkDFVp
HQ+2W6ijfCzAx1yvP3PPkz5Mw2zMfuPx+wfb7D9Tzn2utttDbbeSIGALBERoJbS2AQhArjug
jNnrq1v4/gtt81bWhBEfOKHwL0m2KYI4iGUUUOUMRUO3ihYWyOIyABhZYiV8dIVEftORgAsm
UU1QFoRGMUENqaYGmRB/pCO77wzT+MdX5D8p+U+c0M1dnuPpPYekPpMFo9uXO2/UhRxoQFS7
rffq/Psr6HBuu0fiMUbvmxa96opEoMVkWwxWwutC9qTnSJSwxrSVZ42pWKxjjMdCtWVpyqRr
AGm0bSq8Vi0ngVgQAACXh/oCf9SvMOO2gJHLP63mJGB0bMxOeduVFccg5LqbprgOriypOK0b
dYwvaQosS9WYhhhN4ywhJaUQRtiWzw8dTOy5N9uFFmNtHDrCSBTA3xjdMHBjjjZMlu7vE28K
Q1zpqIArasjc4Nc60lpc8nBwsBGLEigFFzKUsYisUraVlsU6SyqzkpealYvdfCLWwkypZJ43
wM5WwX3hPWfIe33j8v1qfXPst9mf/j8F5jMwH6PAKEPi+IV/FB+oi9XvDMRT9MCjp6NY/6+B
sMbedH0lZHor/QwX+g+kxObkjax/VWMYMWT0SOLzf9GYb7HU8d8eyF+GHS2Uf11x3XfLHKpw
vop0zWcmyz48nNvOUTU7GyRZMdln67HWiUVNabq+zmYc+jHg6du7/Xe/buxgdEMiX48asHIf
Vxvdv8iCn4VAiRQPeoFW2m1Sttr7Z1lq8FYDuK8RFSR2RW0FkYe8hSOAopZVBYjQwSpC1AiI
EhiooMlGFGR0ciBZBSWQUiiYiJe8YUVLhYKMqINUwZB6PjIaNGiJRg2h9EjMFiBI1QhQJiIS
kHPZ7VtMPd6qRjGNYvjFTCtGCmWVYTLLMuK50yrQrRlMxVlliyrXNZpRlm6MPwU7iIshwboM
yiRJsORYxXp/e/eqF/PU/LQ3vANCCIf1M3882PiWx8nZbVarh4LorkL6fkuBDeanT0EA0iQQ
YYjkQHNIECAXsYCgpVcRRoXGCxcwDsJfk9saZkzGVOw7YOM4i5GAOJCEGJKwQGDF4DO/AaOb
mG39mzB5hFGkfQ/xfsn4fs+yT/HF9map9hmtYkhsHvV0zUf3WUO3ELCK20ERoCsGw2zjUyV3
nmF1xbXcw5ea1VeWVjqQNkNwzK+MSzWfehl3YY5x6z8Icg8I9H03X5r8rcO0Lwf5RYfA+4Dw
gh70ijFVIqyFsBowqw/MiQ8Ppu86gENeowYCpATWzgnsPJmIf4F0yTka/WAGmidU7sTvuXzf
EnlKlGnj5GNC2Wd7kz6+lN4EIkkJ8r8b5PL8WxCGbD+FA+mceM5eXTu7MpEDcujI69w1hNiC
xlMm4kmCSusTb434RgUkRID2MgHXjp1n/JZ224zirhz9al8quGIskNKEpFOjNG4bzsTpD8f3
Mrq8Q6fbf0wwZRlcej1PDxHbyy800hrYqxqZlJhh4PUkcjQsKpxaaLvhmLfF0kuM1oZeoOTf
W7NaOh5tBUNdMm9aN5TQ7wtM3qJLoZ0NI0Zwa1JnHPWoPk56vOcG8EcPGE54ezZ1dmjDGufu
ej0hEN+TV/JfzevZ38EiD4GYnEFEUET2sR9f5mQCfQodSpO3V/3v17GgCek+//d72395+//5
nct+auOHFfTBtVFM2M9YvKR9LciijpSUVVfmPYp8ozFiCDolrEQvE7OQUSR15yEue4Y5E9HP
u6bNaSrMveq48Tow/e4PScFuK28G7hl2Sgvh8PnnwCnwf0aw0fTn1Zw92ms1kLxp61vem+Dj
4Zm4c8bNAjlmtRJBpiDGgFg94rOtJ+t4CrNliwrLShGR5g/9Y+I/gpr+BsRVY83Phvbtny++
5+sg/OwIxPzsSjdQ3IYIJeJIOWiv7F84YH6qoHz/jeylMb+Wx9SlVPlI9pJ0gndsCI/OJsX9
ZkagjKWPx+j4YEEr6QcLUPfcAAgC+8U0E84dBB+aEIwTpol9RsOjHpgm+cfhq4zdh9t432F6
/08z8559fepgpJUqlQTmauYf1hDHr9fEe7pMAJoal/8wzOzvLPqSPlBQ0UU9cT27C5Y8/75l
HuP28ekMz+MhCEOs8vQc4ddiZbzUQFozp9lgsT0QOQLjtsuPdsq3rhqOKPrhqklFJqI2HH4s
kdw0wdVz5ihRAron8D9Ae7hwzPP1FHINop5Hlcdu4SZlqLz5AgoHlFFJFUkVHIPcV1OZHXux
h2Mo3ziZHHnax8A45MCRtr2hhIxH9w6E1WRjFReHMGc19fw99XbZa1Hi/1Hgy+e8NbsJF9ny
YXd+k5z1HMZDfYvVoo6wkA+j4AakIAKowzsSz4hIZvQui8Isp9e4zpipNUQQLT+HHR89t9dh
ytK5cs1/sr3vn27lSrJHk3jFSm1d07sJmn3tCqph09vDRqqt3AaOrgayntrlRjmTdN3Bgqx4
7OfFzcigxKP38zdXguck3rkA0gsWwkWGCoSXYgy9jc4wZu2nh6DsaJwMbN9n3/fbgKEuBMyI
HAjZBy4b948UISZIpIURQ6fRMfyHAJcrqxaAGPP19Fi/cKLo+lViZCWzhC59Fm8+oV0bxdey
UDMuer3+pfqFGZUVRVZ2IGgqGPGq70EOVz8wom9xuOtSgEC2M3KzpPT4XY4qliVYqveVituP
u9l/Z7+tM2LS9Od+wxZpfUbGOZH4ValL6WziSPIGQM5twfdUiXEwTUwMCIARQUs38ClEdF6R
rGZLiofKRDoZ0onto2Joe06c8kDQU3t5anhLhz9DMV548q5icjrOSVL5DUKCiqnl8x9v+UMO
w9WtYpiHuO5O0h7DrvnE5Fit2zr5Zx5x93pMvU5q5t9IGdav9SuEH8SAeGPUHr4ImeJmNDHu
CZjOUyBnxYKrmPuIeZUmVyHBpdGMgUWyqZAsclmqHFcyOeRMj42k4h56g01XyuPVvrMiAZgK
mOk/0WrPkUSEDkeBQjc00DoFSuyUGXghxO5hIZic8cQh8wuKrfmMFhyr0U+b2RpFcq5hGIfS
4biaGQeWqqC09iqopCM5GW8+asgnv8Pmz0cBoAAcOUtCcJY76l7g7vlnpzFLECRx9BNARD6V
iFgVLHw+hChqyqsXaL6ILyGADG1ElUEKKOiwgSbuWwAAlBBjDw6jH+wYcc9bjn9pnHns22Zg
VIBgcHGBzn8u8QADcoqoGfuBT93B/l3whCEIQhCEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAIQhDAw7eBrA5EQ2RNSA4x2qb3IqveQxjArAUr8hQG5TcVScw8KG
CTl6l4IhjKIKSqSsKnZIv6LESDdxFOxYlBmRkQNyTMGI3aRBNJoOOxi428xHrN0YjGrSyf4h
WB+TlcTHEviDkR7dTaJO8qHyClxj4YDhosZnf43hBaqfs8MCJvPR+kGSYbzJxWC4oXsrBBGR
VIbemEzsJRM+l+mZpOA72/2lS+NLymVA5dh1KkjUkX062LV+LTIvQI4RTO9gxCiDkwdFBvNP
IdFPCHH+02RAAsmSFmyRGcH/bHGqzNEwr+h86Tkp3DYdOj+AX89MQPCFZocTcC0zfsjUKAp2
HSftLRMxRASYx87oIMKXWSM7OIyjHQL7/4cdjyJhcR6FgB/njy28ZEPjbbeQRH3qbVhuIzdJ
gpIQ0M3IynVqQLxIyqM1VsYynCAEpLY9ZKcipEMLNYlFcBcKldB5EDA0O2pLfcP22bA8hj6q
fP7WuQnWox6SLVIkpIvGMhdpwXnPM6YcthRqdggtEHp3Cc6E1pIUbKbclXhoQ9BIoPMUOYui
rbwGDrt5aH0lhkFJctIBCbB9doW44OJIw9HccSRp/74dhZESwvMZgXQYVCekAGyQ4jSXdF3F
X/X1DCBEwZF9B0v5e8x6Q72U3jnmDLV8zIzBzUcNpisfrHFFInj4OYRGIijCkPHM7IEpXVZN
hsvobw7sg0fBc4siSMJXCKSNJ1wC5A0gUxu2hR+78SdX9ZdO6Pfpjch3OX9v/ivl6QYKqzNl
WMQf+H0xC3ZF3LIfX3/D2z9yA2g2uBtJiYwS/Yb+2Dd3d3bdJJd0l01JJdZVum5NJdWXWbiu
Wdl11dLkSigjJlh+IAAumn+E4VaygWpBTzid0DYfsdXqULqQkAIiFxIjIMI9bCsorCooqqiV
O83+3rA8fL+Pf4sgg4cjw9+SDCoByRDsGP5iC9SnpsOQpmaGI8BBYNwA/mwOKZ+c2EXUbzLp
DaaWKgUJFzjP8qumZoH6sNCrIw2TBy7/z3/L6jV7WHkZxPwdM3gbHrOZVan0U+b34MK7352x
4mXF+g2PFuwbdVfYzocTEPw2xvK7NX6nwwtW8sRhqkdrattSPGye5oe9WrS7sqfiYaVegi3L
Gh9ZcsclN4Vnfmw8iCngEA9EHqwyJ3Du5iYgwEeuKikoFzAU4RSWVhyfcKme5sqXZa0/p7OT
yN9Tus0dmBxVxWPRXT2Y/weDxZwVzKvg5sx525Z5LsrM70u200Zw56e4oeIscZqKKKagoqKt
BrCkRj2xs5fXRlfexP8f1+ltVVtvB9qLJ3+xa8sOb4uXhsgkmGRWYTI61EEan9xT3HMOwPeO
dCQpAU78vMq9SB1GPFj+LP4lICoO2R2/1FzX8KREQ9Of6cs8IKyK35GVysljK2RM4uTOZBp6
xRTw3IRrFE++AbC074UGMZhAh21S3yzpwrPd74Gd34CfmHYrGW3V+Pq9/YhhJfYd3gqL5T4E
ubHaabQHpFVQ3ihAU8BzqFDMiMFTjxcEggmCdEUxPk9ZlA3jESG/rBhvN53Mmh+7vYjr/EYD
7PQeY6iwOApkL238ua8/L/kLwDQBQOSmBvzliTvA/u6T4EbdZzWpG1gY6xsv5qRwYGnsr1Hc
OJ7T5NAgfpFrVv6cWEzSIon9GN6oB8DrjuCJodoC1OztI8OPP0m7fNqt/v2tJabrQBpx7XhN
U8bI1m8ldInrXtrSsHF/XhgKTtGXfXSKTitagwqoqzKGZBlFBLWi5nrHuE0mqmPoyyvZ529O
HD4Ova6bcWurHvYcWjTdhxO+KspVLSyWkkspSkqUo83d8fe4m87uq0qUbGRIJUbbhuHIyVWH
gpUwquc3ZXyqr9x8hkeeYhyJqNIh9AoFDERGfeDRVcr/hbw0/Y7tiZK1NTTLbUJtllKk1Mee
62SqmlrbJqKqIlNrRttt+grdmyWaaNtW5a2voNtV4Wi1kprNKlpKvyFdKUSvVdJZRq2vPdKa
SUpSbexXJSstEjKZVltnQSS2IxZJ4LA1W21ek2/KTL426muRXLc1irqUza5udddbdaaul+tV
tbQ9JFClBJAYIofChFD0d+LIm21kGoKA5F1RZFAPQYxXj3y9yQnXGh9pY8OvN/kd3kSGGA7h
j9Dimo6Wc1Kd9Rodp0JUPDdX4P1mBAqDE7ijGhvHJF4jhs12FIpqfBvM/JQMaOo5QJsN9mD1
H7T1hmC/lNS5kHkPIGvHDBJps16MsLXLCdn98h/uLDnz7dZohgfCwdduo/LSCAQFCDBanur7
ByQpQaRMhBIDlBRAYgLHkoNumbKT6eeWsQY+dcMSZObIhsxgIyqzFTbG3NVw07CClDINCOiC
pSbXhKli1Qttuurcrq2P2ZN03KYk+fXjH6fe83L2vHd1lcHjjrYqfc7Ewsqyratq9myvBjZO
DZGyvXnWtmvOw8g6OzjICzQoFgqFwkSJaMGyKhD3Hi8X8P6M3vIO35osXXn8+zPi9/PM+p88
vnWs5csznLzLveudaervSZs4d52dclZOKcWbya45T1rN3fEzno3ricRmUus1NcXT2cXU2XRt
8PnmvZucWZnD4JxdccmigVRAgEokgmTSoIUqCglapQKTJMVctfJPJkiKERFrXwvZhKKztFqX
UneVZSlO7GLRKUPbI+JktSOH00W88g1rgixgRqm9G2450VGrU4lwkjoQmWcrUXuXxoY00nmf
2nUeY+L4EfvehK+cmr2Hqe4/WcCjD3G57h8ThheZ/cf2/Hg+nms7Kr85TxNmDUydo/U/QQSf
fI/z1M2KiQq5A6LLWABJQihHppcFkeuC/UsV9IROUSckAlST66tkDNhD7qknP8raPUSEUiHo
9EJU9DgTvOLgeY9XcckC6blOJ05sB3p93giXe3MMjp8IP4Es5eHrrpPUIADjUIoWr1iAAx/i
+HXoeJymJ/d1wE9GWeHLpOY5wFIlDzkiRmi1JnuU33MVl8UIp2fa1/0e9aQ8ere7Fqfa2Cw/
lF46U3R3b0DgMhwFSubNy8rdDyH30++h2/c+L1dmKCudT6t/oT7/f+vBUAmBEMfjlAqCyfVQ
UDIWiEIq1VClJAIsSKAAyQKj7GCFoLY/7HBOz0bN9u36gYEVj2fO0ZqHjV2XdAeudv/0NFtw
mt/q8vBfgXy4wWtFPKp7lXmwwvx76Y/BLOdrS0h5+6EE4Lz90/69cNEaEK6b+K6yrRnFFk21
LPFcYLruzjBN0t26m1b9OutzDrPlGM79dpcF6XsvVd/XDeGuUnIbNEHYIxYeEN2sCW7DKMZ7
t0r9N2y2XbaEMqLsvReYoq9N7OvCuUIbRty3zXCbJ0h04dNJ9dEd3npw4ruluoziiybalniu
cF223Rgm6W7dTat+fXW5h1nyjGd+u0uC9b2Xqu/rhvDXKTkOb9YZZdV6S2oziiybrTB4reC8
9dIwTrLryp1rfbrrcw6z6RjO/XaXBet7L1XrfM4NvTKTJEYMw2AVUE0Ain0SjNoxVZ6ceXfw
rz3/bbGPPnju6syaSXkSuct3WvzTblXAXjpThPCnPlPWXb47s71s+BiVpXDCGD43238q4Qw5
Q3Lx05w5xppafTnnfm0b6t0rjxxePLI45U0ndnXfbgQryxm8FrFhnjOBjjjjTbWmOWUoceMN
l4ZcYbo01tOmJw04R44NQzOHLC/GcLZ8p8uk+lx3e93xMStL44QwfG+3PnXCGHOG5eOnOHON
NLT6c8782jfVulceOLx5ZHHLpHplN6HArfbn0hi+t8+nSuEMOkOC8tOkOMaaWn05Z36NG+rd
F5X4Ww5ZNHSDHIF4AzfsXxSZUEFTtE4Na1ba0rjWtdbj8hTRET6wEOwURBEiC/SQL8X7s4yi
rRilGxujRGnSlSrHJdFmddf8yS8Sv9ZeZeZSSUIhcgTEfzB7vL2nl9kCeb5ZB+cwl4YYS1ql
GP5qE+gwhzrVBja2NZS0jfTJeYcExFsFFyZMaaaNJvYQqaWwAAfGzrQY2c3MXV42DIb5zpc2
bfPG4r1FVzOFrnZyPZC9TONrnZrGAAD+YR6g+rtG43IOVVFWE/T6zv/f6k+LSRhCRFNid4rB
NQnmmxMksmWQqO0VwkEiUJgbDmQi22KI1En1Rd0dI6RxjTiRyRmSAoZCbEsmOcMKqTCuQqP5
YIpdIoHxpATCWSJBWKquYnqEuJuTUmzZmmu04e+9oJZWKgoRIAJEiixYTpH3R2RmO+PCOMd8
aEEsao1P4u7Vy+P5mY3kndHKPONCHAiwlRZBmOXnCSNI7osWEsVFiosVpppppppaaaaaWmmm
vQA0EyT5RyS9xOkTglnpTbvsJ++ycTfeRVtqLFklCN4sVFixY7RxfM1A8/UeFCih/FfIyLU+
c+LKlbSio0gWzqxajNTRtNxhAMYBsJACJpbyUU/zcHApP6JxMMXhw4/S4sWQ3/Fi1DF4oBOE
0Q5qlWWypOCokFRAqScIqoZQUQ9avUUqglgQBMBAc2IoUIgE0iikNgjgW80IpImijOplZwLW
ENbMxisqGNm6sGUruc+nFrJo1Qq6ooFirlIFhFW0kVShgiZYsXBjkSXoDdQYIxnIWpIYmJHh
ADEqomJbiA87iDx58JxPAUM8NKaMmgphiFhmwSwO36ICiPIP7hn5xn5hn5xlGU53eaJDowav
saAMrJ1s7mMRatANju17m123OOJNM41u8kQYwrABjKMiGd/rft1axFDUNMQPnooaj06a522M
Grpp5dM3rwMzXTEuTTXTB1dunoiQ7AMI1AzAJLVLVAkA2bMwkkzDWmtMzabSFC2pUwiQxAFA
YJBikxEUYqMKhcYj8KZUTJT7f4Kq22OA6ZSRPcbTeQf4PfxmmDQGg7ZJA1P4vF5LcpwOHCTe
MJhNtuhqPE089ccUiDhVtU6cmY5JxMRgcMsXmmj7BM9TJDKDkOdxhYsBfZmaEC/KtoLqA0iw
0IhkagvZC2elZYHEkJCdp/PSsaITqfQherIXjBYCFVD5cEHBLWGQRlt4VKv2xyfkioBvTXDh
lxTHfq0NbzYuu1cdthTRKzAyzcs2OmgaBWmgAucGyogdkkk3se+qCjxw6iaqa+My9Am866JJ
JJBJCSSSQTwTadH5SnJEh0NJoR38Al8cC5sY09MgtM0xlImMrAh5BTfye2TXA8ZLXDO192Lj
jxjlUtJb4IBLj7o/Rtbbbbt16xiz4neMuUR6SHTboRIedLFEQqI09TJd3dwNTcGMVV4zauPf
NHykfY49PvOkWbODjix1tselm+CkWjnYUkm3A555upzM2MMjEcBHWYcBGFk25IySDwtvKAhR
BBVlRbURjCkwmDCDTJWmy4C2hOB57OPU1bIeEcCGXsHnyfkP3mZ8wfrq96aJp0DumZCc6DdY
m5AM5VqQCqq1m3dRJGD484KuA8EBreZcEBrWaGiqns+VuhMVuLmFXjEoWCLMjjNfDAUFAIbC
L6bHn6cTG0GynFIg3gDPXWbzOyaaZzgXsolAwOQcqPcM45zXLmllZZeWqWuUr7GPxJV8myt4
COJT2JF3yzw6BLj0/syNd9dMMTCnf1wjTm6I+9H6I3e+u0lXeuYOLjtZlcr7blWsosxXMSuT
JCFPP06OGYhkPUhc8cpa2EbbVZmYH8nPbozn218dEnu1Pa+pl4DXpIpfYX+/xEAAuuvwRyOR
ySSEISTNep5a9mzcbcthM6xfLAuIE38L5SWTCkBpggOx6DVXTROIMhBVotaZ4ElS8S1v0vNs
yuAUaR4Xx3iy9ohiUkI02EYJ9SUZBseiBGFaEhEaEjxYb9/N/JW+7mtMU3nJpHbWYOSTVjMx
3iXo071zZB4bPFT0Vj1wu7BppHcWHG26AVrffxHvdk0qhg7s/ICP3BHfYgPE4FEk+z7du2gC
4ZUDyCO3tIgZcfiC20CRywEowAGmDYC5ThOn1mFcrgNPs3mU3kNb3oxYBuQGMDNKZaqCME9O
mvSI00jEUrfYlgSi4xCNq5VKzFR3gyANIgoZINnF3maToal5kpTVSSVlExRBJ56WyCC9eG9I
7FOyRTg8Dt2d5tvnxbqcp2EIw9j+UtBciTjtghqCI0BcZDSgwtJggBoYJJefhHVazyOZYwkX
3bL2mpGmycXHxu402szL6kIjEzE0N6MTGsSK0jfSMDv6snJ6u0d6ulx2lBG+TyF2mZ5kTsjS
THEcmmlmx9heBe3hq67HIjoEvDM0bOJfA1cR4AY0asLpQ8gx6ZL4Z1eLlSGDUaNXUtAbXSMM
3BNVFYYmhpUQ2CEtXOxrPKdvJ4/E4ztqg9OBs7iAA3WvZr35JrEtPX3/P9YiIiIoqiqNTFx1
sLLMjJ5RRBlc1+tDwjLclcrNUgvlgebZfGECwihgISODueeXT5Os6po1xjNAydK69SePBvc0
tmIMaLWPYashTsI4BLrs9eqZqjb5dy6DrsC4KEBPjGiQSMCEVJGJ8UDcYu42aY38TJDBso2q
XpNc+oTGllTH8gIpQl9+6uN0U3iAp2CPTPOoT8cVCvGPftQe5Nfxf6pr+APnYgNIKqE/P3/2
N+4Mv1EigiMoCqWXsUN/xEHPIxj4eX8xbMFQ2/nxqPWHpHq7ac429Hi8cGKaqoTFHe7fLmSW
bJJJK9Orq1StUkkpSSSS2WyyySlCmmBiSqqIqIqVKkVIoKCqpLEzZjREWoi8N9tJNKm+cVte
N7bbvoa+I/O6AzYZbS1AQCBd3VIFEgRGCIsD53jvi7zePHeXgGgPPdqQCwREaCW0tgEIQK47
oIzZAaA7u1IBYIiNBLaWwCEIE05efPXg89BkS+09lVe34cAHl4CmMbbbY34+XmVaJDXOWMUa
bTPPjjDXBwIKxOXkzCaet65zWuZrfJTjlGmR5ThnBTe50ug5MpdIXPBOFzXvQ7nJtrhmM1mc
Q4i4us0+pzzrjFOgxEYXICA4YIDfB1Q6Wl0Oho2tbd0wnWnsN9QHovGGmdCwNU4Zrjjo60G3
0xLWWpLraFd6JsqaNsNlmaNKPH+P2ezz9PF7WP5nvHvfxYjCRFDzPyFOwgenl+0ijU2fyeVf
foHeZJJBl71GRUuP539Cph8np+vZdvo7pUQup8c4PF6Pp6xbYQQgKKqK2+7abfpcDz9Eoitt
XX5q04zxemOOJtF46R1YpDXCjsjWZVQ+coQ9sTXOn56Qq/oqL2xQN2z7UWIcrjEV+TSjyFQ1
NT8txYzka5BB09BdkuKQUMKOaLA+xoyAbnFGow0xcxwxQ4MfqskRmstDveLRu2w0Wusx/qvB
UOXxMifY/jcD2qGky7kssO1H1JSP665Qg6zUcWdtnNLM2eEscG+ev2PW5/3HE+2H01J9tD+5
/vSq6tf3LdE8LdDFddskbrFET/hQxcUylS0yqSf96wPY4fgTM6Qh9AqnCx0HqpHqAPx/5Cqj
ZVR/sVVPJI+5+UGh9QL8X5z52r+Gv8kYn7x+WVTBpP0z/O2Zf1UOX5GND+rDhFLKpX8bIa6q
XNXU25bqbXLFdZSofql9xvTFJUM1TYG5Uz/tE/UJqH+wyMUHeYPOcrFWHkc2LsP9rZ/u7qcj
zch4pocXMwc+klhP8Y7D9+qSmT/NIFVV0O4K3EqWepF7HPE/w44tqrapI7X+tY9/q9eGf739
rfTuJ/NGh5g7Jo4N2P1U9xxY5bE81bSrrDNOjQ77HMcZfzCWKU9LCSXytSIcbIzR6Zdqavne
weUkZQ/ppSxA+HOcjj2fOR738/DxNY4AMh65gk/aVI+JZKpaSVY21m08Mu58DVrVtLSvqapm
Qm4XtVzglgkLAKqBq5DhUN5LGdhzYrnoYtKxEx0QZRlQyIiJMT/Qtyyv+90NxwDYYSUbagsa
FZEUyj5YaowSEkhNCk2Z9tBsIUUqXM8B3LyIlfGZAZHLr2TdmbCLBdvzgM3MtNANGQgSWSoX
OKqpzQMYuhvsjFgUzeE8ffIdOfosl3RutlVTHr71POMRXRLa+VeyUoJBSYLxL5nu17diEDFD
E3pMJ1uSTld4aVsdDQ6nQzEOAhwE5FI0TStzOGCnt8vZgmruYkwoY0rkrlpt+wn+FlBoIZHY
nV17TeIXgeAVXWp4ahLtEbLJlfc0/GUpza/lWQ8vdMcsRzHJhze2TOVMF01Jgdy/CxwRG7Sb
dmTzXudhVyBmJ2DtNoW4O3Y7SJF3JjxwelS4XB0Cd19hZ08TvVLlUX47Q3Fu1NEjqJZ3aMNn
qsRTY9vQ07bo5ycR4vTT4v8cSQ+0ih6ijaoHzUgp+CJb2V2gBHcneJ4FD0Q7a4ZmsWPhgafe
9zL1FgtKF+i3GGGKiyMaqYzVKpeD3mnM29/DV9E6Wa6/xxHFWhsI4K56+x2MFuxtRv1abozw
Ro36pJOCUTNiHWDaQ+NHsAVobfL4nh0Rx3IdZPCWMPlg/emfBul55MVry+hifLnG7/u/LwT6
yKg+JLNeXcx5rbrYraOkkkkkkkkkk7OF8ZoGj8YWMzBqVwb56tGXr5Rrv3PQts40z0rMf7Vj
DjrG9YOWIYMPFGsh/ishwaQmpyR72cBsmXPeUK+qHT7PH26+okLHMANSp3lgkL0sYubzqFiv
kE8dFHvR0L4tMuAjkQpqIBYMLOQFw3EiJ27U4l8yLigTecA7+LoQ1MzFGsUDMwQEQDFDDMY6
aG4kQ8ZmG4gGg4wewkRDeRGt/27wOVTqiHiKGoQDUdEwHDntVdEIXElxEzcv59ydJkFaBayx
1XYcPIjLScY23aF43ls56HJhhJqKfBzekaPF0XjHN3K+eI927JaRz5VI4ycnAjbsdpg4IxLL
KmDnJmWSZD6GEFTuXZwkIgSD7YtKBBHzii2i2UJa3httuZBMFJlmmaKDNNBBoKK7x19zvd1v
nX43xVQE2f0R9PMyCQQuXPAKaLOJk2tHkAHV8rHYbTp+JDvCYMzRIvPSjaMQwrp6jlkBdDh4
jbEIJQCSA2MTEESInKKQPD0v2GthLhAfj8TYdw9h0kAOMRPqO2ntNyO5kE7IidZxNjXfiHg/
RZwjzAVTAYGEQgVJMyMCFWhAY3y0dKhGSQkF6subktw1hYtjlgLHgb6+vyN3uSt93OMyU0SR
jkRLqaGBnfv9clhxeU6JOgjc3J0yQEiogYyE9R9/KeMnoPPs/G9Dg4ojsjVP+PQdVJ83xO8A
cDMXrIZL2bk6Pbp8CPZNnXrXiqQvsSu2i6NP51nltHif8aWxgVEr3NZ3gMvBZgnChPLcYsGA
Omgq6Z+OQcJG0S0lu9xMiHu9/A3oBy5hNFRLCMIjfANEaQ5wDvxDmH12DrgdIwCCdP8moOT+
v+0t9RYf2eB4mGk+mkIfjpHVMGTBkHDCQpHn4l9v18h/nP4Tx9fCeWnw0/Slz7jzROuP3hD3
ARKEwdp9fxHfOEO8PW5KOCV61Mqj6f7N2iKsLs+ROWT9dap3dd2h1lrllx+k5G+kljY+zeGc
zWV+VtzmX+Zl9bKjRltWgYnMzlJRs/l/U4JaUh5qkTNALTOXrgPZCm9EsINUYT+IgpPKxwjm
7lWqpVKq9e/12/Z24R5vI9rw698nV0cDD88cVj05NBPccm7RoYU49AxT+Xk5Qd06TUdq93DM
DUTWkXpIt4QIbuLR6etPrvFu7qceODD3GBosMZfH46s8EPgRWQh94f0AfI+0kZ+H6bVVFVJV
VSIb4DkkVqA0nsKBMwx91jv4FK5sGBpQ0YwMJjD+VFfpj/q4v6zmqmJjQ/SaBWLWwp4LkGiF
RWCbxpsZG+OS/7jaKb7OXDdFjdqrpUktK5brmbsmWUkbzEdHfLFGzkmhpeapeendxOtODX9s
ZT7WXKZjLLEMqhaeLvZaR2YO/ZJ4anQiJDiuaWySLkjxvxJJJJdsJDVtrM3GgnDjhPwgxNDQ
dAra6ES5oH7k4mQv3/3UZXdTxHlYvcH6KnSXXM3cyEJJmQCxwDZPHud8V/lO+bbtU83FNNHo
ZJw6RzqaLbbamcGEfHLZ7+bEOFngWQ9FPW+tyjx/6QAAPXa9mbQykymqfCVhVFGzHcepKAoa
7GdCI9B3BNe03BjgxY2ERVW/M7Byy3MYjkBxijmQg61ZGRYkHMwPMaRpaCDBeJFoGg0aGHCv
bieOFV5Xqi2c6KU2YYYQgUh4E40dB240scOGCmVPg1O2zDVhKwqaOezTrdnBvJKGg4kNzYOH
COzgF17Tg8iijQzwSEIWFTSmY3xhOCxhHqVHZVT8GFns62SkCYqk+0NQfs9IJYI8NhwhJUqV
GpUKlW1VW3aScUYwyetGnm0kn7qX6nXuHgnLuxHznMkdYOawn9ridOMkbqwpgZGGGBw1FuCt
8muBE49k5SlOCgS6ppyBY5sRM4AZfeX1VYCAHg3mM1iDxQoqHiBIQK5sDmqDYdER5jrhIzMz
+a3DM0f4D85yGtn6rKj1hBlWpV1BRWBWKkGkzQoFDxELvlnNCECW4Yf0wkJAkZIpKGhNmWzV
nsvWlT9caQ+61HmLVDaBIN90kANxAbJkDiv1VQG9kTGMFeMxHHDRMdq6aKm9tBSqADRpwcaj
bBxpLgaYMu7RlCPJlUNRET4N0FUysij21G27gEgKJMGgYjQNLEawqB0Vd8kbgto2xnKvvL1c
lZuYr3CdxeyKQ9B1VR2xHqUsOrixEvmj0Ge+K9z9ri+aRX1PS27UxQhIVxH8Qpj2GZzEhGQH
ccqg+kfjwhv6kfA4OkcWxT04vUjqm3iJZ5/T2f39yMLd0+swAtkB+/LJsTGkYN3o4JhmSMRp
2jwctpAytbDn7bXu+HO2PrU4FNa5u3lHGRykjvGzqj1/eScEkZj8f9HF2ms+/WlpecA/N79V
7ZPyh3DoJgRzHaXlKB4OArWcCSTXkGkHSlOx0evgTsxwIRKuY2ASKahqhIQSRJEU8k+PQN/Q
RUTcdCZJponkJ8AqsHiBrYSFQdRWs3uOPgUaaL32Fgwlg4CIfd3FBFFDDVjWpQqxqiePeop9
qMjnUmtkE/lyQ9pGvmBEvMyBqxI2n9qCSYRSJ2k5D6uZsh+N3D3xG2z2b7XI17KKfk8Kvt+U
5m27E5omp15NelQbYyy0N19I5u949j5PZ5qSx/eFkcMGESMVjBsFDpH0mrZLH6uR60eJd3vK
BO1OQWdU2qC5YV8+k0tYvodo/SHGB88B8AyeCd+5NwqMATTDcDzaA9/sSv2EcHhsNxdTHo0A
ttX8afMiVZwJr4DYdYBMaDCsvOk3ONIKNchbmXESnhFzGNyZT1JyJOc4JxcPYrjMWi8ksckL
A5foiIyUiPYbdo0Tjrbg1XL1C5ZwHiQBoXMEGfKJB+T5fX9pLXJSW23NWrVq1eWsXzjvjuJJ
Jhznc1yHm7+BMk0jUMQ8TvP1x34HD5NW+qR/ckbEiKjAw/XD3FKFR9fz+o+R1221112yy1qR
TvTPRfuO/l0TByP2EhBFsk4F+iWB82+Fnx9emk0W1XIoYGF9IcqkTRGJHAflnFsa5kquManp
KS1zhZJKWSljwhMm5lgpjaJ1i3DL6Sx2m8fFQ5iVwsb00L6iYAiRCXl5CFNDISPORxaPnmHV
vGrO0Ra5oRyRnjG8V6iDQJq6IXImIWoq0KJ8/+3nvy+vQ0eHmfTCxsY7R5dqWvA1upX1ks7B
geyHwgZhCqnDHokmeSKmXs3jJxLJzVWVJ+ErOdpiBZGHRhGFhmMsPSxk1r2847uqjMiQzHyR
8f4pEFIhlQ77AwEwe+1hbjEjGDaPVg6o5nWFkxJaOen18MmeNP52R/kuaKWilKkivPV13W7U
p006e/xz8FsneXDlQglZIbJWN/I4aCJBEw1J00aLcwrG2NvhiGyhSJdUNOoTTR9QROR5piey
xqrbRMkyZ0cMWZNELVLDes5aswwWKxKXGxWyyaW0nz0Yxt7O4v8OXPLpu3NcwmZvbduta1rW
tOiV0STq4kzGiyWuEF9qNWqTMpaKWNx1OTek7AMhND7ho/cyzZwVqL3hmbjXMoUKYEsCFh9p
kSLBkJ2jFA8ETtBaKUpaqmFUjrFIAllUgi5bdp3x56eg6K6lel9uBowVVVhGzafJeXqYz/BB
aiIdtDCZ5jrG1Lv27cjCGs1hsGiD6rycTWak1jfkbA8FLPQAXUzFLJMyrHIwy9eOCJDUk5Jl
mE/uRIcznG5oZJwCD0AfrNhgTqFcHu2j70wnxqIDhe5IOCJJ8nsJzeEGpzkhJcnZ4ZmnFT6o
LYehUFDinOEISTxE06syq7j7E459qHh1nHe95sDiJt7CyJrrkl4W/ymW7JzD2M4ouVVZ1HKj
gDCikAVuaCj60SVQmWrREKjkOx8R40pr5rvOy3V4NJNiGxtDYNnuO08xshgvOSILvzauhps4
3gPVhqsCZ2sZtQKL9DA5ekLxDJpLnVdRpj6l7YjJVSo1MakIklRlITu6WVIi00yyKEZyIOQw
I/TBCNJOGaY3cI0lBMbhciTCVSQauQFv21Fs8h5SSNqWoSziDJjOwXI7giXmG4KEFmlBcIXT
WWYaXKDzvCRoGRCRDNSa3xUQxU3CkyF0MwbMwgJkYGojihJUWhGkAExq/pIilpk7Exh+cFTo
c3tr00TMXGAk9Alo15GyNcyC2gQKki6zEuCgwkkZM5wnF3NxmjCysK18Jw5W4SSTsF4o+2TH
g291CPRQCNJJzNN0SIJUmEWzsX3FyYp/ZuxC4iHeVGNBN3Vxmhoqp65OY0jBl3ZXbuZ6Fjgs
TARC2L2LkLkL0UJmr2u51RH9RDVBcqiYqp3vma9G0N/3HPgS8CYd3zo5ebRwuQz/SX3/o8Vx
tCPQbpUGYhx+b9QbLVhfIHiRiRnNw6zCBMZkY0VKQzn4x0kXhKkgkClzQ2xJqlk5kqhYb2DW
qZ5aY2g1XKxWVJReirQkPRyUKHRIBtIr+cqkhq8vE1/0dpu03b0AlFH2xkAownMEsqpcqNJx
xE6GTk0x447kj0aI4wplHJ8TY742wx1XFS0QJ5uE+M5x3dww8/qn3E3kWbVw5c6nKcjBtp5G
WRa/7YLCL94YvsLmlDpIBFvv4u4Q1kiIvI6N6UQC6omY+9AT2TE56k3PoFkIdfN4E4G2zesR
vFwXN6wN4tUwKlxZRgXDCPnjJgsI9+EPKAKJcCg1duZmiJEkWQu6EV7Q66ClsYA0BiHi8QwZ
ESMtwjRDlUGNlJUCzFXqMdQoTIJA6zqIL4RMEQlgh2nq3XRM1OihYvkhb8Udp4I7o24JvEdp
JmylQveoSUiAJgHQ6p+BogainP7BWPcJkDEzgDaMMvuFS9wyk2kvRec9mvku9r1imvTU/g6a
IIQc+CWKyp+wjJNeRZA79gdPPtBFQ4CgB3qCRQ5DZUPFkFCrBucfvRGiiNJmE73+NSJWj0I4
dpcLKOKL3uQVZlZIlhVqzCrJ6RwZ3FNnxJYTib1vARiRNmt4ML+yul9yc9evPwWqsX8bw8dP
r0w1tq1SlKtjIaDKKlCT630tWt43ipWaTJBMjRGipL3Xrr596ebA36P1SpfMm4U7SrsF3oI9
2v7i6dIOtHI2nJKczuOy+SYUALCKpWAtDtIty6JDVPhJ8yHsFXP1ElUHyUkwstFpez3PBfZu
6xhFkeyJ3mJVEWqQIgsJAjQihATQs3LFUDV7MY6OfbAhQJEhsbGxpbGRH1hmfgHkcHDxjhwV
Vt9vF+5XrN3q4v1OsbRNI80+hFNucNmFVXqVh+NXJOLfPZHuXiiQ6/5st4zs5KbR4Go46JPR
ZMCn16DC1jjdFGpCHAKDpDBTJ/OEdvP2ZBqMDswrsnZpzqSL08kevU13f7FcWZwdzCUfLwVI
20mDFiO3p+57T9Y9pDvg2QkGySE73hucEljckmEE0kgQoAIaSAx2ZtizKtMmUysaPhTWiyrC
f6LM0vbEFsdGUrbp7pw9iGruV5OhhDqetPe4JZiwxDFzYYtqMrOAD5oMma9Z6Zm+0bpl7WO0
e3h3o9aTmjsfp0jlOVasFxY1Y+gk9saM1arVAJZOJBWxVK0LeMoTaeRijogJ1xHtukpQo44k
QDpHmrfTIIwubTQDA79PZVlzS6JumYl+8CaI/Bh/AjJAm4TXqk5PzrhaeLDDplRzm9MdJrl9
4HvUABnmxIY16IQHL3MMbjgm6hH+SpWCewSgrEpMUPaKjQKDndfDaJDYas6NA/bGAwjFKiom
sgUGi+ESFL+Br551k2foxCWi1EtFsjCqnBTYpFzMWDUrW4jyTDjHRPPdoqt5bbFSlFdJJwbO
xsbIaXBg5RixlSmoPBB3EXAauALlhNgsE2KC7Nhz+D7k9gX4X6B0XHs8Tv9WRtqjLYN5haWl
uSDZRlsG8wtjMsG8wt9Ia9+9mmOWmFtMY7aY8zKY0JJffR3bbbbfz+lDRtDb+hNp7B3vrChr
0WKE6+mKv5PQWL0oAFJAriDx/pGhwjFdWQTFvY3ZDISxCG0T8LEuHYnMEwOrIcHqT28ISNZH
SFKQBoztrWB2YQSpAYw1pwIEdBmyM2ZKqqlVSqlPW2Op+Fjwco8CTVhHkwmH5HaxqaLH9jYO
zl8kkTFyMkzM3NkxaO6NIaIkN4wnJGT6OW37vLoSfeXwR7IdnDjXEft7N4eD6oqO71R0QX7y
HWR/IO0fldwX1mXR8nP5cBfeIdHId3OgH2Odwt4KeSsqk+H9L5pq1iOUgMoKBT8DPoOk9qb/
EANT6gZEAnUqpy2sFeDJqokZCLI5eTi/q7ZR7zlt0B0yKWE7ETFFROcCECQg/EoFvoion1R8
Ofs5hIBqcJDTKZ8XXTe6+T6PePwldsU6GrmthU7UGFJVWrFn7mE0Zi6MTLpiWzfXDGOD8zT9
NYUqiqkfyLveNgHuHgPAAEHUJegTPrMxMHYKqukkkFXyd1KbVJhlGrG8a+69Pm/K18D1Vgz8
3q6Vcq6nRH8nCa2rLUWlqi1bC0q2/vdVKq1YyryYcNZJye36Ikg+h5niAN33RuaJ+uxPVHf9
GX3EDcahO404Go9tDRFstHcMSxAS9xDgPUbI1yHF+JhMyQHIWuDu5YODq1UwPSPrRs+Eczxe
O8SJDiIr1e2rVpZr26XFsg6z4un8soBdPWpdpyyYyR2N+bKCw+QR2RiEJEFmVDgsGoH3o46o
yw8uPc98bI3m2JJyjo5YI0hjrfNmLVKgE4RjeNprrOZpIhlY8Uv6r3BNxR+5srsCCfYRLvRA
O4M+C+iE36skO2LaKpRAJCRSBRgly1CdIYi4bHB3V0sESGFQAFDIkAFwjGLPsoQQ2VrGIFGL
YxBCE+IGCVCBCB7tiAAVQHSONVH92RORDkTkndbhiCr00sa86VJqrZfHmETWokYoRl6jzaPE
97aR0SU3fwuSzmltnT89swL9CweXAoOhEgeEG8cw5HF0wbESIgK1G60IsBQSGYJm/S06nGdW
7eLUkqydeDHNxb2O6t2axjBsxF1k5ZhxYao9+aiparijbJunaSMixmekR/vIkfl73LV1fGlY
xHSRIJj4S0lnUry1kc1jsnUehiY8HtwEewS1C84J8E3prE8fNOSnC22EJJxIWny16E8laKNp
9I2aIe7T95qBM8Ox6p4wbqboBfr2JaYDBSdIBfsR6rqWtDpSCCWVfaL5TxZTo8z3PA8ISEMI
HgbaNg1vU02xWpiZWYan2muuDgUbNPkl6yfi44mq6GYhL6pDGCqYKE0O5D1obzlx7DpFBwc5
CDPskiFCVSFvzUpuJyE6Qt8Tt3Jl0auGG4aqaIPAD6TIvmcQo+cVHRNpOewgLdPAWu3G2mSG
rjS1vjCQ+D4Ou94vbZvI0kMyo8tRYyEvY39GGnOk/i0Nz7g4Do5MB8KYllFGSiqS+yMHa2E6
+Wvaco+TGxXYQbO5NFDwkYclfJ8yPzNJwdXmY3zOdpAznHKIqoLKkshJGTMxhg67VRYxKiRF
awDGErabL/ePAw0aiaqARIWtULcCieZgsgxhQayhJiB5pCzSnsiptE1VCIGIWVh3jLERlN73
/WuLhbdIi4VVsud4iJcVGIq2EgJWgrBQOImZlCzc0isljYFiEzTIL0r8rmUoHSRY22CkP6bJ
ucab+T2K/0+XvZaPbwww+ltqpX1mJtbdrOJ5/zJDEfMTsxiVCOpXj0E7PCUt4SKfhDY/0pcS
4WPm0uKHEemDqiQxCbjOOiNud6YzCM1JFpas5fFk7kqXPgmlQgnzHOzlI393qRRCcP8ssOln
X15wy7Q73FNxmYLJSrIqxS2ukhVgywLidXemkkl2YAUgVtLM2RYe8j+zRPdHlUcTKw4uayOM
+tLUsFFWWKtEy3l81WWymKdfKOIb2OMZI6pnCpGiS9KWihCKh6cUFolEsVFpVLQC2NJUaSZb
FyJLSWmwGxJwIRKJaMHCYoRUVEAFSoIKLgbDmFUKCDwimGAnx3IRD3p+H2DvJIgAc/7KcIQb
BELwVorfYD2QZFMv5q6ciQzSuZCEkhuvTCieJyS0a+OrfSK4B+T4o+2RiPj8XLk04WZosHfS
BSatfX8oPPeoQKZVIkCAxCiKmESpTZZOLi5J3SLElj4R9cj4P0jZH7AHekcxj5Ij+E8P2c20
8Szxvd2aJ0+Q7tuhokgByOBYsnTRpxMiw228BVVlh9H9RM6LUarGFk2fDEg2a4E+xw2b8qxc
o6Q6LFtnt0j+1xiNhP4qKp8uB8yUjA9RyjSPenrI9ERqZGvB8OfjjEkkkjc8zBB5AJ/eKcCG
e+EgiIBNEBpJki/yjLZgyNUGhkbSjAA4rCHFYPdnht8j1M5R7DZMRlJOi8XcsvwiBiYYceCQ
8Rl0jdHpvtDY07mZru/qCxklhOuDSfLWPdyEsHrMxXcGZqfFf3BnwFCRsIcgQGOOwd5xaAiJ
YnzqJxgbpC6ivLWdZFS+At64ZTtuVhYvduL9W/uKD0eBCH0xnVN3XnCIIz+iw+6cKtSTkuUz
kDj7gX5uWaSC7tCGuac5lRPXAmibS8BpkQNQCBmRX5GQWx7wmdRsA+YNnJiXmD5Fsh3uIjH7
nBt5BHZBDx4584V3xmg4SO+LCBRJYppTU8z2lGst0Q7Y8mHIDNS/O2Vo0bYd8b/6SqWrmfw4
8NUdkfeclb3v9dPSeJQ8LIXE8N8J4STCoVqWvs6jLpHkZ0AmuK6iCXxQkMzpzwHesLUro+TO
ZffzOMk6xwbF2Afhn2+rXg7D6IUk+j/HDshnD5Su0tywlEVglEQ1AdIB50F04m040ZGno1J5
TY+J159METrE1juV6On4hMT9wiBPcdypersQZjQsS9AMBGUiUjSpiCboC3itiYi2YwqpVQip
n2M5sUsK+ZddCkLNequlfV3V1Mnsm9WZpLak1LPB9gVRLDcbhI3JIatcl28zJJbbY52TVagT
cJtyDKIYIsDUaalsth24LK2VWziwyk0gwYQpTcYjBwfbj+x6tQOrtGQsU5uQbRzGtAbhfPRO
/m04k5ax38CkqCyEtWAiGwr7bYItsWIQhUJaQzq9+swGHll8qW7E8ziNkOkYNDmcngYFddNI
1FU9hmnQ9Qe4CqEk1FzgwPTyE4hhv0ykZBsbd6lz8RB2HDp29w4NgoyItg/5W3pJLTWaSA8e
snVRqqMQ8C9zMdYnkSVlY+oTja/Xvz4bPNxaHrRtsn5ybDwiRIbOibbRHF86MQ0qUIo81WER
SAECCCSIxaFYQxpKJBNXqiYZTch0wckTnPdO6NtFETmlBrNh4iuRcKNfb2ibxNBnB1KUKqUW
ClRULF7Kl0uQUAqFCSKsKqpcMi1UCA9ZusHYu1eaDNEhW8cKJxS0WZsgykKMrCLlnAYmZ9mB
MY3Umgu89vi0ikdqXGHVhTfhUy3rUO9ACqCyRHyUhl8OD6TqFex0BRau0nAVURVN64wBhMKq
8Ahz0Kb5JNRJjDeinC0HUgSFNMYRIg74qBMqSR7sMF5ukykIkNiW81rXeUKFtHqJmKIIamhX
ap/EUuqZiQdBwUYMzrPX6D0XRC+W0a4a6Ztnq7/G+1mRNhbjMzLjMxNhlxmYGZi8VmhgxjGN
tgxpkZBvK1F9hcTqGK7BWog0K0sEpVVgCANUoAwpJSCNJSFJKQRyTTXRRx0Oym+7odRmVtTW
gl4MihFjbaNGxlqW1vfla5a98qeYLfHUHuL+P2h32Vm8KIIbHoW2wxY7iBVWlUqrXCJJNo2J
BUWQWKSSxIpFRUURSPSdZXuHTJEvkUZ06IwNmiJvs39LWw4iL5YB0Nc42hg0i8HDpxqUr2VS
wmLImKsVUrlU+JosrzjZtB8j8jdobYvcXmuVTHrkSGnjp1jvvpnwNpAe2UJIpQhCRvTVQnIT
KjZ2R0J74XEs/rD7SFHXDihsI7wRSRVE0vYdA302LeJQnlK0I9iDGh+NibFxBtxPFD1EMRTi
RFkmAIioTiC8CDazDISJdu3dt4rMsYbYN2Q1cifhSIaFwvW0YfrhhP6gyyO1NSpjXHi7cjKg
uKENRQmowuT93myOR1sIRWEATTYxECIPKl98wMIUYsGKJo97bWGI/Y2OGVppogSSQMIKDCET
IobDfKHwT1UdabjfgTn83UJmD233hdNEcUeuSxuuKnnWbNO60o8aLjebxo6VjkZU0SyqirT1
sMIqn4/sPYqzLT98RWgjQRFXwKOos0BfkQokFdchignYnRQ0IVQ0txtxI9diFd8cCRsSEBle
LmQh1WnXW2X9hdGtxt02UaxUJEI3KMFFVidMMqUpVVSVXPlMXHtQKkC1gHrYAqsjIe8xAGFQ
FKRZE4GMODWMT9OMMv62vLSLrDiA5uiZrDUVTCvkGmDCjL4c7zR4zxuuqdldXXO30fXNvXh1
4GilPO6FWkmLvesJwECANFMf6+Ka7c6mUd5U40YVqpnQwVpWGLtdt53wql4u83i6IxZJS2St
zW9PFPSrruZuvvpeayVGmklLUUVKWXKdxjKndpjp0zi/m4c505a5tl1NbxvMx73NO2XU1vLv
cu5u7mZ4cDtz8Js1rWtmZmZmZmThEENDEMSSR7gR3AnR9aATROMs8XCLwyzHeu7bTMZtukqE
0ONaJF4ma6EBNSQIkGoMiEilHRwA7faZGhtQdeosfLKTA0RTe6hkuRCqUZ8cuA15NMKNlKxn
iysooRsUJdWpDIVaAraCzIEdyGhAIqiIaCsL91i9MFsWlZhyQFrG6GyHtPj46dKzTXGZ9xrK
LikKF50B3JFzQBuRhdMHSUELtG2UhtJ6pG26doqQHeupvHj1N+G7gjRx6V9CN2rbep6vO9MM
MSy4UGKOoxhjBgpaNKm7neQ0AVHUVKkVHKWM2Hgd79aNuBzcmEhyhu6dW88nenWF04UO/WUo
JWpm3MoO3IygSDOhaKSDQRUBiIuRW4nUG6++XON7PQbTV440cTECfm7ckmXfesgaVIexCseV
4mweigmrlggZcLXutIexfCnBE7DwjNYG06chzEUIntDT/ik/PB+CfRxH7RO8KHz7DcoqURDy
EE4JD71RAlSRYJ2jSncRDaH98E9IbIXHzpTb6NJO+uVFFiB4wscD5x8jMhqWjw3h8YbTaPev
Uuq6O1T1Ca+n+UjngHUrqEHIJNqThPMLdBW66ZL9ZOh20Lc2nxSWLJ2UWN5ygWV8cWIQqlEa
OSPE+sxYO469Pk5m47IyCdpALGb1/n1BqPOLJ+tmJ7jb3I1dJfDb1pCEyR8qiuEPqWK8HwSU
ppoltsttWvCo83ZGyRZNStf2PyYeccTCq/BlY2UepHPXrlg6lYO0UsnRmNFVxYjlea56Rjhd
L4sNmWaNmmNTz5+X6MYduLLMXC4p9JJRksyXQsdmdFS4P+amcpg/frmSEhzieDAi6vZ3MYZQ
867pNDgaxu5bX7diRV8JLKC7AdRpGiOw5o2KP+VXS3w13LZU2DTTaw5gUE3h7YQkTg5CRQkb
g2RyES9uIMBL3DRRoR8+yJMVIRH0e/6keHZHnhbVtjSPvfe00k9xs+tDuR9SAVlsslGsWh3Q
LaGAsKcC6+dvp1V+SIdw7ynNdonQYOJ7zEfEog1vn3SqlVKqqqgBHtRZIFikfekc6bOiJCsi
gpt7XrT+Qm5B8hWK3iUCCpEAPl6+61D4hCgr/HAmOJNg7ZSJhMgR3/abEOVR7badpiIDQ2jD
oGgbTTKESWSJRLFFNBZXco80pL+wuJ2sEF8E8JwPSUzBS4IB1QcCkGB5WwVeCjxGD2gp5w8E
YmFQoRKtG0iAQiR7XAdmGKWnxXLbBOmuCSZLO/kPry0sSUnmkU/QYfSj9BOR2IXNSIxB2uAX
IiDjJIlTm68eA4sfKEeG3bZs96oeuyJWyWuhI02vs239lmzb6P6P6nnW9utI1GW+/63TK9c2
bSvXxdrLS1VL/+LuSKcKEgyNrsPA
--------------D2D5C20439DB0E109D59E290--


From owner-linux-xfs@oss.sgi.com Wed Nov 15 12:47:40 2000
Received:  by oss.sgi.com id <S553793AbQKOUra>;
	Wed, 15 Nov 2000 12:47:30 -0800
Received: from ppp0.ocs.com.au ([203.34.97.3]:53521 "HELO mail.ocs.com.au")
	by oss.sgi.com with SMTP id <S553786AbQKOUrP>;
	Wed, 15 Nov 2000 12:47:15 -0800
Received: (qmail 12204 invoked from network); 15 Nov 2000 20:47:10 -0000
Received: from ocs3.ocs-net (192.168.255.3)
  by mail.ocs.com.au with SMTP; 15 Nov 2000 20:47:10 -0000
X-Mailer: exmh version 2.1.1 10/15/1999
From:   Keith Owens <kaos@melbourne.sgi.com>
To:     "Martin K. Petersen" <mkp@linuxcare.com>
cc:     kris buggenhout <gast6@vum.be>, linux-xfs@oss.sgi.com
Subject: Re: xfs on a sparc64 
In-reply-to: Your message of "15 Nov 2000 08:22:58 CDT."
             <yq1r94did3h.fsf@jaguar.mkp.net> 
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date:   Thu, 16 Nov 2000 07:47:09 +1100
Message-ID: <5070.974321229@ocs3.ocs-net>
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing

On 15 Nov 2000 08:22:58 -0500, 
"Martin K. Petersen" <mkp@linuxcare.com> wrote:
>Keith, do you have access to sparc64 boxen?

Dave Miller gave me access a week ago, before that I was relying on bug
reports.  modutils 2.3.20 (out later today) includes some sparc fixes
from davem.


From owner-linux-xfs@oss.sgi.com Wed Nov 15 16:23:10 2000
Received:  by oss.sgi.com id <S553816AbQKPAXA>;
	Wed, 15 Nov 2000 16:23:00 -0800
Received: from deliverator.sgi.com ([204.94.214.10]:12135 "EHLO
        deliverator.sgi.com") by oss.sgi.com with ESMTP id <S553796AbQKPAWj>;
	Wed, 15 Nov 2000 16:22:39 -0800
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 QAA04257
	for <linux-xfs@oss.sgi.com>; Wed, 15 Nov 2000 16:14:44 -0800 (PST)
	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 LAA07356 for <@larry.melbourne.sgi.com:linux-xfs@oss.sgi.com>; Thu, 16 Nov 2000 11:20:02 +1100
Received: from localhost (dxm@localhost) by clouds.melbourne.sgi.com (980427.SGI.8.8.8/980728.SGI.AUTOCF) via SMTP id LAA12894 for <linux-xfs@oss.sgi.com>; Thu, 16 Nov 2000 11:20:01 +1100 (EST)
Message-Id: <200011160020.LAA12894@clouds.melbourne.sgi.com>
X-Mailer: exmh version 2.0.2 2/24/98
To:     linux-xfs@oss.sgi.com
X-URL:  http://zoic.org/dxm
Subject: TAKE remove XFS_kmem_alloc alias
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date:   Thu, 16 Nov 2000 11:20:01 +1100
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


My TAKE got eaten

	2.4.x-xfs:slinx:78314a

linux/fs/xfs/xfs_log_recover.c 1.196
linux/fs/xfs/xfs_mount.c 1.245
linux/fs/xfs/xfs_inode.c 1.307
linux/fs/xfs/xfs_fsops.c 1.63
linux/fs/xfs/xfs_os_defs.h 1.17
linux/fs/xfs/support/kmem.h 1.2


-----------------------------------------------------
 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 Nov 15 18:01:51 2000
Received:  by oss.sgi.com id <S553824AbQKPCBl>;
	Wed, 15 Nov 2000 18:01:41 -0800
Received: from deliverator.sgi.com ([204.94.214.10]:4101 "EHLO
        deliverator.sgi.com") by oss.sgi.com with ESMTP id <S553815AbQKPCB3>;
	Wed, 15 Nov 2000 18:01:29 -0800
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 RAA17572
	for <linux-xfs@oss.sgi.com>; Wed, 15 Nov 2000 17:53:36 -0800 (PST)
	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 NAA08021 for <@larry.melbourne.sgi.com:linux-xfs@oss.sgi.com>; Thu, 16 Nov 2000 13:00:10 +1100
Received: from localhost (dxm@localhost) by clouds.melbourne.sgi.com (980427.SGI.8.8.8/980728.SGI.AUTOCF) via SMTP id NAA13125 for <linux-xfs@oss.sgi.com>; Thu, 16 Nov 2000 13:00:09 +1100 (EST)
Message-Id: <200011160200.NAA13125@clouds.melbourne.sgi.com>
X-Mailer: exmh version 2.0.2 2/24/98
To:     linux-xfs@oss.sgi.com
X-URL:  http://zoic.org/dxm
Subject: TAKE ktrace
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date:   Thu, 16 Nov 2000 13:00:09 +1100
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


plus some lost TAKE messages. 

Date:  Wed Nov 15 16:17:05 PST 2000
Workarea:  snort.melbourne.sgi.com:/build1/people/dxm/isms/slinx-xfs

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


Modid:  2.4.x-xfs:slinx:78314a
linux/fs/xfs/xfs_log_recover.c - 1.196
linux/fs/xfs/xfs_mount.c - 1.245
linux/fs/xfs/xfs_inode.c - 1.307
linux/fs/xfs/xfs_fsops.c - 1.63
linux/fs/xfs/xfs_os_defs.h - 1.17
linux/fs/xfs/support/kmem.h - 1.2
	- drop XFS_kmem_realloc alias

Date:  Wed Nov 15 17:40:22 PST 2000
Workarea:  snort.melbourne.sgi.com:/build1/people/dxm/isms/slinx-xfs

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


Modid:  2.4.x-xfs:slinx:78318a
linux/fs/xfs/support/atomic.h - 1.2
linux/fs/xfs/support/sv.h - 1.2
linux/fs/xfs/support/spin.h - 1.2
linux/fs/xfs/support/sema.h - 1.2
linux/fs/xfs/support/mutex.h - 1.2
linux/fs/xfs/support/mrlock.h - 1.2
	- remove sysinfo kludge

Date:  Wed Nov 15 17:57:15 PST 2000
Workarea:  snort.melbourne.sgi.com:/build1/people/dxm/isms/slinx-xfs

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


Modid:  2.4.x-xfs:slinx:78320a
linux/fs/xfs/xfs_vfsops.c - 1.301
	- use kmem_init & kmem_uninit

linux/fs/xfs/linux/xfs_vnode.h - 1.5
	- move definition of VNODE_TRACE_SIZE

linux/fs/xfs/support/types.h - 1.2
	- add xfs_zone_t and xfs_zone aliases to kmem_zone_t and kmem_zone_s

linux/fs/xfs/support/ktrace.h - 1.2
	- use kmem_zone_t and kmem_zone_s not xfs aliases
	  add kmem_init and kmem_uninit to alloc & dealoc zones and don't export

linux/fs/xfs/support/kmem.h - 1.3
linux/fs/xfs/support/kmem.c - 1.3
	- use kmem_zone_t and kmem_zone_s not xfs aliases

linux/fs/xfs/support/ktrace.c - 1.3
	- use kmem_zone_t and kmem_zone_s not xfs aliases
	  add kmem_init and kmem_uninit to alloc & dealoc zones and don't export





From owner-linux-xfs@oss.sgi.com Wed Nov 15 18:54:53 2000
Received:  by oss.sgi.com id <S553736AbQKPCyn>;
	Wed, 15 Nov 2000 18:54:43 -0800
Received: from pneumatic-tube.sgi.com ([204.94.214.22]:64562 "EHLO
        pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP
	id <S553682AbQKPCyZ>; Wed, 15 Nov 2000 18:54:25 -0800
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 TAA00458
	for <linux-xfs@oss.sgi.com>; Wed, 15 Nov 2000 19:02:10 -0800 (PST)
	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 NAA08346 for <@larry.melbourne.sgi.com:linux-xfs@oss.sgi.com>; Thu, 16 Nov 2000 13:53:06 +1100
Received: from localhost (dxm@localhost) by clouds.melbourne.sgi.com (980427.SGI.8.8.8/980728.SGI.AUTOCF) via SMTP id NAA13514 for <linux-xfs@oss.sgi.com>; Thu, 16 Nov 2000 13:53:05 +1100 (EST)
Message-Id: <200011160253.NAA13514@clouds.melbourne.sgi.com>
X-Mailer: exmh version 2.0.2 2/24/98
To:     linux-xfs@oss.sgi.com
X-URL:  http://zoic.org/dxm
Subject: TAKE arch support
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date:   Thu, 16 Nov 2000 13:53:04 +1100
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


+ cmd cleanup I forgot from earlier TAKE

Date:  Wed Nov 15 18:50:50 PST 2000
Workarea:  snort.melbourne.sgi.com:/build1/people/dxm/isms/slinx-xfs

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


Modid:  2.4.x-xfs:slinx:78327a
linux/fs/xfs/xfs_arch.h - 1.33
	- xfs specific architecture macros

cmd/xfs/logprint/logprint.h - 1.10
	- remove XFS_kmem_realloc

cmd/xfs/include/libxfs.h - 1.21
	- include new xfs_arch.h

cmd/xfs/include/xfs_arch.h - 1.8
	- xfs specific architecture macros

cmd/xfs/libxfs/xfs_inode.c - 1.6
	- match kernel

cmd/xfs/libxfs/xfs.h - 1.9
	- remove XFS_kmem_realloc

cmd/xfs/tools/srcdiff - 1.13
	- check new xfs_arch.h

cmd/xfs/logprint/xfs_log_recover.c - 1.6
	- match kernel

linux/fs/xfs/xfs.h - 1.11
	- include new xfs_arch.h

linux/fs/xfs/support/arch.h - 1.2
cmd/xfs/include/arch.h - 1.4
	- move XFS specific stuff to new xfs_arch.h





From owner-linux-xfs@oss.sgi.com Thu Nov 16 01:41:23 2000
Received:  by oss.sgi.com id <S553681AbQKPJlN>;
	Thu, 16 Nov 2000 01:41:13 -0800
Received: from plutonium.uunet.be ([194.7.1.47]:3339 "EHLO plutonium.uunet.be")
	by oss.sgi.com with ESMTP id <S553648AbQKPJlJ>;
	Thu, 16 Nov 2000 01:41:09 -0800
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 KAA12828
	for <linux-xfs@oss.sgi.com>; Thu, 16 Nov 2000 10:41:05 +0100 (CET)
Received: from pcgx14500003.vum.be (pcgx14500003 [83.105.1.4]) by leonidas.vum.be with ESMTP (8.7.6/8.7.1) id KAA05124 for <linux-xfs@oss.sgi.com>; Thu, 16 Nov 2000 10:43:12 +0100 (MET)
Received: from vum.be (IDENT:kris@localhost.localdomain [127.0.0.1])
	by pcgx14500003.vum.be (8.9.3/8.8.7) with ESMTP id KAA25988
	for <linux-xfs@oss.sgi.com>; Thu, 16 Nov 2000 10:40:30 +0100
Message-ID: <3A13AB8E.5C0629C2@vum.be>
Date:   Thu, 16 Nov 2000 10:40:30 +0100
From:   kris buggenhout <gast6@vum.be>
X-Mailer: Mozilla 4.75 [en] (X11; U; Linux 2.4.0-test5 i686)
X-Accept-Language: en
MIME-Version: 1.0
To:     linux-xfs@oss.sgi.com
Subject: Re: XFS on sparc 64
References: <3A12BC9B.30D04CCF@vum.be>
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: base64
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing

a3JpcyBidWdnZW5ob3V0IHdyb3RlOg0KDQo+IHRoaXMgaXMgd2hhdCBJIGdldA0KPiB3cml0
ZSBlcnJvcg0KPg0KPiB1bW91bnQgaGFuZ3MgLi4uDQo+DQo+IGFuZCBzaHV0ZG93biBubyBn
byAuLi4NCj4gaW5pdCA2IGhhbmdzIC4uLiAodW1vdW50KQ0KPg0KPiBOb3YgMTUgMTU6NTg6
NTUgd2lubmV0b3Uga2VybmVsOiBTdGFydCBtb3VudGluZyBmaWxlc3lzdGVtOiBzZCg4LDY3
KQ0KPiBOb3YgMTUgMTU6NTg6NTUgd2lubmV0b3Uga2VybmVsOiBFbmRpbmcgY2xlYW4gWEZT
IG1vdW50IGZvciBmaWxlc3lzdGVtOg0KPiBzZCg4LDY3KQ0KPiBOb3YgMTUgMTY6MDM6MDEg
d2lubmV0b3Uga2VybmVsOiBJL08gRXJyb3IgRGV0ZWN0ZWQuICBTaHV0dGluZyBkb3duDQo+
IGZpbGVzeXN0ZW06IHNkKDgsNjcpDQo+IE5vdiAxNSAxNjowMzowMSB3aW5uZXRvdSBrZXJu
ZWw6IFBsZWFzZSB1bW91bnQgdGhlIGZpbGVzeXN0ZW0sIGFuZA0KPiByZWN0aWZ5IHRoZSBw
cm9ibGVtKHMpDQo+IE5vdiAxNSAxNjowMzowMSB3aW5uZXRvdSBrZXJuZWw6IFBDRDogcGFn
ZWJ1Zl9ibWFwIGVycm9yIC0xMDEwIHBiX2ZsYWdzDQo+IDB4MTAwMTAwMDINCj4gTm92IDE1
IDE2OjAzOjAxIHdpbm5ldG91IGtlcm5lbDogUENEOiBwYWdlYnVmX2JtYXAgZXJyb3IgLTUg
cGJfZmxhZ3MNCj4gMHgxMDAxMDAwMg0KPiBOb3YgMTUgMTY6MDM6MzMgd2lubmV0b3UgbGFz
dCBtZXNzYWdlIHJlcGVhdGVkIDYyMyB0aW1lcw0KPiBOb3YgMTUgMTY6MDM6NDcgd2lubmV0
b3UgbGFzdCBtZXNzYWdlIHJlcGVhdGVkIDI4NSB0aW1lcw0KDQptb3JlIGluZm8gOi0+DQoN
CndoZW4gdHJ5aW5nIHRvIHJ1biB4ZnNfcmVwYWlyIG9uIHRoZSByZWJvb3RlZCBzeXN0ZW0g
OiBpIGdldCA6Pg0KcGFnZV9idWYgbW9kdWxlIC0gQ29weXJpZ2h0IChDKSBieSBTaWxpY29u
IEdyYXBoaWNzIEluYy4gMjAwMA0Kc3lzMzJfaW9jdGw6IFVua25vd24gY21kIGZkKDQpIGNt
ZCgyMDAwMTI2YykgYXJnKGVmZmZlNTY0KQ0KDQo=

From owner-linux-xfs@oss.sgi.com Thu Nov 16 09:16:46 2000
Received:  by oss.sgi.com id <S553704AbQKPRQg>;
	Thu, 16 Nov 2000 09:16:36 -0800
Received: from chyndslgw1poolA164.chyn.uswest.net ([63.227.165.164]:56629 "EHLO
        roujin.gargoylecc.com") by oss.sgi.com with ESMTP
	id <S553687AbQKPRQI>; Thu, 16 Nov 2000 09:16:08 -0800
Received: from roujin.gargoylecc.com (IDENT:ringram@roujin.gargoylecc.com [10.0.0.2])
	by roujin.gargoylecc.com (8.9.3/8.9.3) with ESMTP id BAA01044
	for <linux-xfs@oss.sgi.com>; Fri, 17 Nov 2000 01:21:04 -0700
Date:   Fri, 17 Nov 2000 01:21:04 -0700 (MST)
From:   Russel Ingram <ringram@gargoylecc.com>
To:     linux-xfs@oss.sgi.com
Subject: RE: XFS with ReiserFS 
In-Reply-To: <B14BF8753E65D211ABCA00104B301EF5015A4CE2@cairn-gorm.cragtech.com>
Message-ID: <Pine.LNX.4.21.0011170116580.1038-100000@roujin.gargoylecc.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Content-ID: <Pine.LNX.4.21.0011170116582.1038@roujin.gargoylecc.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 Wed, 15 Nov 2000, Scott Smyth wrote:

> Hi;
> 
> Here are some preliminary patches to get reiserfs
> into the XFS tree (not the beta cvs tree) for an
> alpha version of 0.9 LVM.  They all applied cleanly
> for me on linux-2.4.0-XFS-test10 as of yesterday
> morning.
> 
> Sincerely,
> Scott


Thanks a billion for the info and patches, guys.  It worked and you save
me loads of time.  By having support for both filesystems in the kernel I
was able to switch from reiserfs to xfs without having to go through an
intermediate stage of ext2.  Now all I have to do is figure out why my
modules have stopped loading at boot time.  I went from 2.2.16 to 2.4.0
kernel so I'm guessing it actually has to do with either the modutils
version I have or with the new devfs.  Anyway, thanx guys.

Russ


From owner-linux-xfs@oss.sgi.com Thu Nov 16 11:07:36 2000
Received:  by oss.sgi.com id <S553740AbQKPTHR>;
	Thu, 16 Nov 2000 11:07:17 -0800
Received: from pneumatic-tube.sgi.com ([204.94.214.22]:43374 "EHLO
        pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP
	id <S553733AbQKPTGt>; Thu, 16 Nov 2000 11:06:49 -0800
Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id LAA01434
	for <linux-xfs@oss.sgi.com>; Thu, 16 Nov 2000 11:14:36 -0800 (PST)
	mail_from (lord@jen.americas.sgi.com)
Received: from thistle-e185.americas.sgi.com (thistle-e185.americas.sgi.com [128.162.185.204]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id NAA7672148; Thu, 16 Nov 2000 13:05:31 -0600 (CST)
Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.184.86]) by thistle-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id NAA81553; Thu, 16 Nov 2000 13:05:31 -0600 (CST)
Received: from jen.americas.sgi.com (lord@localhost)
	by jen.americas.sgi.com (8.9.3/8.9.3) with ESMTP id MAA12613;
	Thu, 16 Nov 2000 12:59:31 -0600
Message-Id: <200011161859.MAA12613@jen.americas.sgi.com>
X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4
To:     Danny <danscox@mindspring.com>
cc:     linux-xfs@oss.sgi.com
Subject: Re: XFS ACL Patch 
In-Reply-To: Message from Danny <danscox@mindspring.com> 
   of "Wed, 15 Nov 2000 15:43:44 EST." <3A12F580.68F8EB7D@mindspring.com> 
Date:   Thu, 16 Nov 2000 12:59:31 -0600
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 a multi-part message in MIME format.
> --------------D2D5C20439DB0E109D59E290
> Content-Type: text/plain; charset=us-ascii
> Content-Transfer-Encoding: 7bit
> 
> All,
> 
> Nathan Scott wrote:
> > 
> > If its not too big, you could post the patch to the list (even
> > before the issues are dealt with if you like - its easier for
> > people to give help if they can reproduce the problems you're
> > seeing themselves).
> 
> 	Okay, here goes!  I've attached the patch.  B2Zipped, it's about 20K. 
> Sorry if you're on a dialup, like me ;-(.
> 
> 	If others would look over my code, and test the dickens (a very
> technical term) out of this patch, I'd appreciate it.
> 
> 	To reiterate, the problems I'm having are:
> 
> 	First: If I set an ACL, and immediatly attempt to excersize it
> (notablly turning off owner execute), it fails.  Inserting an acl_get(2)
> or a stat(2) between the acl_set(2) and execl(2) attempt, corrects the
> problem.
> 
> 	Second: sometimes after running the test suite, the executable becomes
> unable to execute any more, failing with 'Text file busy'.  The XFS
> partition can't be unmounted after that point.  Sorry, I've not been
> able to narrow this one any further.
> 
> 	Third: my use of VOP_READ_LOCK in the VOP_ACL_GET(...) macro in
> xfs/linux/xfs_vnode.h.  Is it necessary?  Since it in turn calls
> VOP_ATTR_GET, it will attempt to lock it twice.  Is that a Good Thing,
> or like in pthreads, a Bad Thing?  Under Linux, by the by, the
> VOP_READ_LOCK is #defined away to nothing, so I can't look at the
> vop_read_lock function to understand it ;-(.
> 
> 	Thanks, and have fun!
> --
> 

This patch does not apply very well - you appear to be sending diffs to
files which do not currently appear in the xfs tree, e.g. the contents of
cmd/xfs/acl. It is also a patch against test8 rather than the current test10.

If possible could you please move your code base up to the latest development
tree, and redo the patch using diff -Nuar between an unmodified tree and your
modified tree.

Thanks

  Steve

p.s. I notice that in xfs_vnodeops.c you added back in all the access checks
which were turned off. These were deliberately removed in the linux port since
they duplicate calls made from above the VFS layer via the permission
function into linvfs_permission. Do you have a reason for this.

The VN_BHV_READ_LOCK ... VN_BHV_READ_UNLOCK macros do evaluate to nothing,
they will turn into calls to obtain a read lock if cxfs is present on the
system. There are a very few occasions where a write lock is obtained, so
nesting is actually a problem in this case - however, when that work is done
someone else here at SGI will have to take care of it.




From owner-linux-xfs@oss.sgi.com Thu Nov 16 13:12:46 2000
Received:  by oss.sgi.com id <S553759AbQKPVMh>;
	Thu, 16 Nov 2000 13:12:37 -0800
Received: from pneumatic-tube.sgi.com ([204.94.214.22]:42620 "EHLO
        pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP
	id <S553750AbQKPVMb>; Thu, 16 Nov 2000 13:12:31 -0800
Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id NAA01714
	for <linux-xfs@oss.sgi.com>; Thu, 16 Nov 2000 13:20:18 -0800 (PST)
	mail_from (lord@jen.americas.sgi.com)
Received: from thistle-e185.americas.sgi.com (thistle-e185.americas.sgi.com [128.162.185.204]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id PAA7649552; Thu, 16 Nov 2000 15:11:13 -0600 (CST)
Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.184.86]) by thistle-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id PAA95389; Thu, 16 Nov 2000 15:11:13 -0600 (CST)
Received: from jen.americas.sgi.com (lord@localhost)
	by jen.americas.sgi.com (8.9.3/8.9.3) with ESMTP id PAA21883;
	Thu, 16 Nov 2000 15:05:11 -0600
Message-Id: <200011162105.PAA21883@jen.americas.sgi.com>
X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4
To:     kris buggenhout <gast6@vum.be>
cc:     linux-xfs@oss.sgi.com
Subject: Re: XFS on sparc 64 
In-Reply-To: Message from kris buggenhout <gast6@vum.be> 
   of "Thu, 16 Nov 2000 10:40:30 +0100." <3A13AB8E.5C0629C2@vum.be> 
Date:   Thu, 16 Nov 2000 15:05:11 -0600
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

> kris buggenhout wrote:
> 
> > this is what I get
> > write error
> >
> > umount hangs ...
> >
> > and shutdown no go ...
> > init 6 hangs ... (umount)
> >
> > Nov 15 15:58:55 winnetou kernel: Start mounting filesystem: sd(8,67)
> > Nov 15 15:58:55 winnetou kernel: Ending clean XFS mount for filesystem:
> > sd(8,67)
> > Nov 15 16:03:01 winnetou kernel: I/O Error Detected.  Shutting down
> > filesystem: sd(8,67)
> > Nov 15 16:03:01 winnetou kernel: Please umount the filesystem, and
> > rectify the problem(s)
> > Nov 15 16:03:01 winnetou kernel: PCD: pagebuf_bmap error -1010 pb_flags
> > 0x10010002
> > Nov 15 16:03:01 winnetou kernel: PCD: pagebuf_bmap error -5 pb_flags
> > 0x10010002
> > Nov 15 16:03:33 winnetou last message repeated 623 times
> > Nov 15 16:03:47 winnetou last message repeated 285 times
> 
> more info :->
> 
> when trying to run xfs_repair on the rebooted system : i get :>
> page_buf module - Copyright (C) by Silicon Graphics Inc. 2000
> sys32_ioctl: Unknown cmd fd(4) cmd(2000126c) arg(efffe564)


Just so you know, internally we have managed to come up with a scenario which 
can kill an xfs filesystem on an ia23 box as well. What were you doing in
this particular case? In our test it involves filling the whole filesystem
with data (I am using lmdd to write 512Mbyte files all over the place).


Steve




From owner-linux-xfs@oss.sgi.com Thu Nov 16 14:27:17 2000
Received:  by oss.sgi.com id <S553775AbQKPW06>;
	Thu, 16 Nov 2000 14:26:58 -0800
Received: from timmo.dsl.psn.net ([209.63.182.212]:24570 "EHLO
        fileserver.nimmo.org") by oss.sgi.com with ESMTP id <S553756AbQKPW0e>;
	Thu, 16 Nov 2000 14:26:34 -0800
Received: from comms (comms.nimmo.org [192.254.254.6])
	by fileserver.nimmo.org (8.9.3/8.9.3) with SMTP id PAA18087
	for <linux-xfs@oss.sgi.com>; Thu, 16 Nov 2000 15:26:23 -0700
Reply-To: <timmo@psn.net>
From:   "Tim N." <timmo@nimmo.org>
To:     <linux-xfs@oss.sgi.com>
Subject: RE: XFS with ReiserFS 
Date:   Thu, 16 Nov 2000 15:26:22 -0700
Message-ID: <000901c0501c$403d9d20$06fefec0@nimmo.org>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2910.0)
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Importance: Normal
In-Reply-To: <Pine.LNX.4.21.0011170116580.1038-100000@roujin.gargoylecc.com>
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing

Would you give us an update after a week or two of runtime? It would be
interesting to know about the stability of your build.

Thanks!

-----Original Message-----
From: owner-linux-xfs@oss.sgi.com [mailto:owner-linux-xfs@oss.sgi.com]On
Behalf Of Russel Ingram
Sent: Friday, November 17, 2000 1:21 AM
To: linux-xfs@oss.sgi.com
Subject: RE: XFS with ReiserFS


On Wed, 15 Nov 2000, Scott Smyth wrote:

> Hi;
>
> Here are some preliminary patches to get reiserfs
> into the XFS tree (not the beta cvs tree) for an
> alpha version of 0.9 LVM.  They all applied cleanly
> for me on linux-2.4.0-XFS-test10 as of yesterday
> morning.
>
> Sincerely,
> Scott


Thanks a billion for the info and patches, guys.  It worked and you save
me loads of time.  By having support for both filesystems in the kernel I
was able to switch from reiserfs to xfs without having to go through an
intermediate stage of ext2.  Now all I have to do is figure out why my
modules have stopped loading at boot time.  I went from 2.2.16 to 2.4.0
kernel so I'm guessing it actually has to do with either the modutils
version I have or with the new devfs.  Anyway, thanx guys.

Russ



From owner-linux-xfs@oss.sgi.com Thu Nov 16 14:42:17 2000
Received:  by oss.sgi.com id <S553847AbQKPWmH>;
	Thu, 16 Nov 2000 14:42:07 -0800
Received: from tisch.mail.mindspring.net ([207.69.200.157]:30506 "EHLO
        tisch.mail.mindspring.net") by oss.sgi.com with ESMTP
	id <S553817AbQKPWlv>; Thu, 16 Nov 2000 14:41:51 -0800
Received: from mindspring.com (user-37ka2n0.dialup.mindspring.com [207.69.10.224])
	by tisch.mail.mindspring.net (8.9.3/8.8.5) with ESMTP id RAA16345;
	Thu, 16 Nov 2000 17:41:32 -0500 (EST)
Message-ID: <3A1464C9.F3027609@mindspring.com>
Date:   Thu, 16 Nov 2000 17:50:49 -0500
From:   Danny <danscox@mindspring.com>
Reply-To: dcox@connex.com
Organization: Connex Inc
X-Mailer: Mozilla 4.75 [en] (X11; U; Linux 2.4.0-XFS-test10 i686)
X-Accept-Language: en
MIME-Version: 1.0
To:     Steve Lord <lord@sgi.com>
CC:     linux-xfs@oss.sgi.com, Scott Smyth <ssmyth@connex.com>,
        John Trostel <jtrostel@connex.com>,
        Robert Stickel <rstickel@connex.com>
Subject: Re: XFS ACL Patch
References: <200011161859.MAA12613@jen.americas.sgi.com>
Content-Type: multipart/mixed;
 boundary="------------85EDE57B5E5A181D6C43A0C4"
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.
--------------85EDE57B5E5A181D6C43A0C4
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Steve Lord wrote:
> >       To reiterate, the problems I'm having are:
> >
> >       First: If I set an ACL, and immediatly attempt to excersize it
> > (notablly turning off owner execute), it fails.  Inserting an acl_get(2)
> > or a stat(2) between the acl_set(2) and execl(2) attempt, corrects the
> > problem.
> >
> >       Second: sometimes after running the test suite, the executable becomes
> > unable to execute any more, failing with 'Text file busy'.  The XFS
> > partition can't be unmounted after that point.  Sorry, I've not been
> > able to narrow this one any further.
>
> This patch does not apply very well - you appear to be sending diffs to
> files which do not currently appear in the xfs tree, e.g. the contents of
> cmd/xfs/acl. It is also a patch against test8 rather than the current test10.
> 
> If possible could you please move your code base up to the latest development
> tree, and redo the patch using diff -Nuar between an unmodified tree and your
> modified tree.

	Okay, here's a patch which should be much happier!  It's against
test10, and seems to work on my system.

	I've corrected the problems Steve mentioned, and ran diff properly (I
think).  Please try it, and let me know what you think.

	I noticed that the attr_get, set, remove, et. al. have been changed to
be just one system call instead of five (or so).  Should I also emulate
that and create only one system call for ACLs?

-- 
"Men occasionally stumble over the truth, but most of them pick 
themselves up and hurry off as if nothing had happened." 
   -- Winston Churchill 

Danny
--------------85EDE57B5E5A181D6C43A0C4
Content-Type: application/octet-stream;
 name="acl.patch.bz2"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
 filename="acl.patch.bz2"

QlpoOTFBWSZTWYEQmD8AaJz/gH/+cAB//////////r////9gaz977NbH1Hy7bqp6Yfelvtrt
p3XcD1Wrz19DY65mcO6tKbvD6e8J9r7rh10KmDq6u717eY9no2sootqy98zgon0wIa6+5962
97r2PrqvMnIAFdPjS+zfPCz7hBYd25mn3ew++k6fbffeAAZPWWYBpd3sNpQl3trn0yKW2quw
1W2hbaqNb75xz7alRXxew7k3R698Gve+NfXrfW2LLejnrVrTPKvd5T3XUQGizjll017zu653
fHuHJ6deZlRb3dU9297B9u9j1Jvu7kx1qZbGONwdCumgdN20feDORU993L3s5JQ+vDduNtlG
x52dSqFxnO5mCiqI9te9226TJyPrhKaQIATIAgAjKbQ0jRHoIwpp6nlNpT1PRMHqAR6EZMJE
ETRAmhGieqep6R6ho0ap4DSNqnqB6geoeoaAAA9QNASaKRJJ6VH5E09TUbT1Rkek9QAD9UGm
gA9QNANAAeoAAk9VKEinqe1J6BGIAAAAANAAAAAAAABEkQEATQIp+iYmQ0aAmFT/VT8k1M8m
k2qHppHqeiejUaDTTEBUURNAQCMmmphTAKepvUNPUp7UJ6k/U0aah5TJmo0GgeU9TRo04I7S
w97GBKsSliVSVSWRZuTbmUxUsqWy1FpSkqJB8pBoAUY+Qgy2fxN5dQKgjLlMVPdoqsRD/B/y
jEJrd2ME/F9rDZ977T7mWm+2t9fq0mcyFUg0oxUgyrqpjbry4U1CRTS147m+hdOKmU/w2wZh
sdeEzCymVKVcP9T/L/b/Ff61H4n3lH6fw6z+XM2u8YcapKoqH+DxouS0uYVQpMbN1XN9xbbm
gomUlJUTLNLLNKbJGzSuu5crImNuLikpNTrzio0wikiv2STmkNJEqUEEFkOWFILAqTaNkpLJ
ElYU6dFuLn3a76XXDgcggIJBEIrBQRJy2Q48MUEzWJbVGStQRLaWyrbbWypC0JYAiWf9GmDF
D2HqZIRhB/svFMgHAx9Ag9JRIaLkLbYXBk5lyO2cTCkFCQRCOr+yqZ+wtQfZ/uucokYwQp0N
OCYYXUJkVPjT145ynsfmn0IwoW2+oXKThJRT0HZoWCFT/x/H+T/eVUJxxgILpOxQ8dKmuHMh
DIIULRsGk2xW3iucWlZqWUWnDq2d6nhKnq8KHkPFF4J4Qkom2NeHnnN0SilBu9uNCA+ml1Cj
FkUikWRZE+dbixS5y47rVyrizalLYWZkQ8qUcIsKkPFlEASRptDdqHNrligFJZkzGdVuTWLS
WZilJ0unToZznGkUsKpUptKxYLXSS62a1VIaYsPSa6TY02S2ypKajN3LFztza41pNCzZlduT
m5mG0tdOSiGtgoMbaZXY4wyCAkSAiJkpxlkQWSVVTjcWKw8FJ1mkPF2VvGtajbiYYj1cs4NX
bYyZDkgcKsApCMkGQCrb+9+wRfUnUj+Tc/qU2wiTvqQrV0/j7T+P5tUTVjPcJCLpBAsqP/vP
FS+zrLgabtkkD7SsOxrUwU+3zkymRZQx/KI2ytqQE0EHN/iRP8r3phasUBqaCQjQ0NrNXebS
ULDx0aygi/4/khqN2qyhVvsZFSfkQHIRDO0eSc/O4exyiI+3uW60MkjGCkQy7iD2LuGCn0Ut
7vsg+33ywPCMBJapznBRiTlgFmWCijCmmgKdxRiLIH7P9SjcRDuD9A2zpm6iBhJ4DIhidEsb
NhwhFxWjT0sU7P4DY6IlOHv8TyE8HfGWKvTggZvMCGUVOIhKqG4g6YDOLsmZRs2wwCdSPaVG
AF/K4xbP+Ls5dbhZSIRizYLJhJonJvXFccsD4fWdeOw9F7wZixVKMtC/qYtEwWaUEmbiIIbJ
LchI0ssVV8skZDwmvTzWlHmsweC8xeTzDyCh3jHGd0asLIseqSw4FKGTCZmmT3g+Eoc3Ix21
L2c1DUIBOTbgbPm49Snii4TL5+Pmr9z2dr+5V3XcLwLhStpAFlryq0yIyElon107ItsQ4RqI
VHGPrK+co/0NgYPjhsMypNJQy1Gl6lJjAxBc38xEOGoGh+v1Yp16nhWmhLdMROye8Utto1iX
IWTBXLTeHkFMIU3HTWihReXm2CtoxM4jry6YYjJhiGpa0WDi1YCs8GDgcvDopIfbYYRIsVRd
bWWCIiVpUllLLfAefGJ2eQWxjFEPJLfEwiFEGUTxdOFGxEllF5j35AdpsBoxqIqNV23vF06d
1y5kUV22IoxmpTttu1ImuEwqBY2iDG0zZdeXM2LJut1qUVixMMWLIIxEDFKKEN8fMIqSIbeY
z9H4aRZ5wZlYcQfga0yiAzo5TC4lOXzxaqqqqiq/070dnOi+994faOjpLWTHpfMossKxzgtj
YS07hRVcqXGZqrPeN6+c19HdCVTn+6BiYutNoIKgsOse3mnC2R9Ad5I4GdcZXdqsV4VWhAcS
YUaQIIIMOnD/AOAHYOWJgEP3x0gP88ukIQeUHU4WrStEtxxNuEECmZr5o6pVSHelcVB5h/HH
AucqmFcD3VBjA8PswYWN1YUxfNsw5KK9j3HW/g0fFTaaG8gGoRE8KjVYRIGJMPgVG81kiBuO
o8C47fR6TeA6GQmPmO4f0eFB5uk6KhhCEIbXG+S8Jv1uTZSuq2k5NsLnPGt4B0ocWIvlcGIM
IBFHdhC+Tp/V5w7O2rzCwlHb2MhAJmEma3BGCE6yinHZSpa8MLQInmIdxauor5raz99vZb5I
PSexZMqwtPZiTRmMHqydRWbNTNkPaqGVSGWawZVVaYdys6GFkpbJutr/Y0bt5uai22W0btQ8
9Pta4aIp9qI2XLaIZ85zSLYhGkApGifoA8dpLcatM6VpFx9PixuduFFeVdsp8HJ5snUqJ3jh
A9J6SJA9I+BkDYFTHQcSz2KEGsg/WopQcSSEmRwPhUb1Y1qR1DM6S1p1La5BIm4PifSoba5P
+d7ZP7JJvR3N9P+U7H9NT7cc5eLqZo6QV78QCQH8UFMXDExoF7GI/mKg6MVl4lIb6SU52WjG
HHZJP3vc/YG6bU4YxNWrcGQ4JBHOd9mhS/1zEqv+lb72FktTCMC4kCigjx/pDS8Ik9g77Hyn
wHynkNDMxCD/SfQfSeUPWewyH3pv0ag8v3nxngXFkD3/gf9DXxFfxTwvmJth1kHyBEDCL5zk
8hI2oPMYBzfONQhzIGgTUyF9jrH6D8X9Fnqx/yMoQU6G0qPbPBvd9/3iQ3vTpMeo2gKTsOiQ
jJg2DZr0Cyaf5PgJKwwe39HbRPeLGuuvQP5FMRBMx9NQTKJeaSWBuNkI1wLijG0RFb/rb8md
2QroPPbYvD1yS6g+GhsG0lxKBn8IvqobpFDC1XMJJJ2gv+f4UePGgPHtTIjNocMBjE2vf4zf
uuXJjYFS28d6JQ2MaYAzc29XxZByYuN1Cb95uoG0dK8yChUtmlog8yU4zPfYsUG+tshZafe8
3O2aRTsHYEDd34GomPG4xGYjoZUcyggAtDCcmbMhaCETigyFjd/wPEqvJmseftO97MXPSnd+
V9GBwhGMR2Z0ROLmvUmViIBnBiZmKwNkw1jVYmenEd+9w0m/5V9I+tZE3OY3wzPLzpLdxmQD
4eFJhIiCrwSjRI4oaDhIIwsBCeHCRNDguKgqCjhsZJREYVkwhjUohejwYyHBsYeC1nmN4CJa
dNYGFFERqLHBBOSuOTy7u3l1K7tySuS3LkZfVaiIiR84JKJwoIYwlJjGjU95KclKcKYExiaC
MZSwsRZuNUwJJdEHcZRKKaB4KCO5EMWDLkCTk7qvtofjk8AubL+i7urPG07hMYKH23BbR5IX
ejz/a5GY6nXGCylnh2Q1pmlW4OmoVUgfhg8TQ4Xohafo2kW9BIMJkWHHLJ1H4E25W0MMyQed
ZWQYG1pKM8jMxWgh46hwuNRg3RN8D8Kfh+4cnn16oDyA10OQSJU0U+Yw+QlhWYPomBqvkpJw
MGHiXtNn052N87+J7YRrRynEoGyJNzRZCwDEg4QxKgn1z6NvuL9hE/E/Z+3+/D7r2MKajC2E
GII/VBPBMkepez39+PaVF5WXHSb2Dgm1+q8zKy44nEsWORzOv0BtrXps/YDh4I/WLDwS6eqD
bvlLZhBhhVfsgd2J5tGzp/Mjb0U5rJWM0R/xYc0FPVKmQUA5QxaDhDP3CPYvoZScdupVXhbZ
Fq0xFoVNH5fd9R8v1T4HWPmLP4tLg0zduj9Z1AAgYJsd0YzBpsQBrG0OYe2Aw8mq67utd/FJ
J11IcSkOsCQ7qCeKZXuyekIqqlIT4sdYXFkS6wh7fQxTfvO4G8Opg4nBglQ2zvOknTK0+Ahv
4H1BrAb3oPlkX3eTJap+xP85bE3G5tn9JSg8ixQdpu+33rYB3HAyHvPoaci1g7v9H1/lIPd8
q8W6A0tTTDwIP/+d6kr76vmQaHw98n7deUDnLjgIR5sbkyipwV7SjKMgxWKZchIrN2x23GRI
82a+0m1Vx4GJ7BFniHxHqFF1QsGvbrOLb0azEoZD64VneZ9V3OmNp0HCB+4v7qy63KwxoyaW
kuUWNAEVV3FSY6STFEhaI7ySrE6bK9kGsQiIfWUrFv4PyZakxaEMS25IjgXoi6acypaF9R+X
7Xy6flLmfnqfz/cxTKcJ4w5nGe8kqTSIKqFI10RNVQPP0jHcdSA8TLPkbQkGsTFf2yje8+3P
6A+soPvDxvBxJI4kGPka53ejcYyeDa3J8PuSTeOM03vKzmH8Wvtj+pfohs+smBMiQgXlEWEO
O6i0GT6RiUu+lKIZFUZhFKiRgSLCFir23b9wlj+bMD6/u0HDSbq4Ft6fSk9xKGjA3OJ+02mp
BNpnnZIkSfR9v/r7d5jiEGfiQ3RKIvlCHkMZWlfOFnxgxT+jidToVtRsVJJ8kdLpXMJU59BP
nE2Ha7GJ2qmIWhSo3MZVkLRuXecQP+SMDLFfR5+KufAkeoiY6n1wOmpzhgF0lYx/4cN+vrjw
aXmz2DU/JKVKWN0dx49xK4rQgTkwc97/XE3CZoCn5O0RNFE9jt3mUng8DB86i2WjphVLVtWs
HPOH4Kis/5mOzsAQah4iPSYT/S2HaVbMX/E+4Yr7BN0+TfmEbIoS2FpAnk/1Mqb4QYQSep4B
6ZPqchPlGumqdqaA3D5B0TljDQEj3oZFsn84W9onD3xCnhPIQYv+VrFIdiCJRI4ZiZGp5zDQ
yPIfH5DXWTATin4CV4JvKcF96hlU/qn0v0pa49mjHpp8zV3PkyV3NpEq2T8QDzgaVFKlLbUP
jPXaWnnV8/PfXIeUfQf2ykl5KUyYJNW9tjnGk2VbkdmlMUwMFqAYiIp2VZY2za1YPPfFgsSS
BIERvvijyEdJXTa3rqWvoVoqqlVKo7nPhGal0Wyq4sM/Dw8p4azZSqfoaFVTDxhhlVat8OT/
I5N5py5b5pyUqp6qw6ybJxcEBQZ+MGD5YMAdtGx1NinASWLoz2SSSS7ltC5veW43O4FQbzV+
ifPw5UvrOE7FEa2tgnLkKkUxtcmBtcKKdqH9vvpOLcxiFCOLLp01ClKqkdBLYHTtTgnBMU2+
ghnsPR1pQwxpIlzTYhcEIt9nKoixwTFLVAo+2RDKhU3vh65GBZGfGpcQLC3KFiwNu1i5hQqy
iUGofS30omcu8dcYKatWgWvhqNQ5pMcwYJbgie/vHLBBowtPEQIzNlYikF8dY49nbR+kRyMs
nbx3kJhnVDXAxphEYRIQhzCFEQh5M88+ByrKgt0T06dDGovZFdNFnteJjgwzoaLMM5MH4wxG
e5zNXUuTjSBLobUchFZVJmZrWEaP/SbcmkYSbggjs95yOwu2mwfTeoKCPXd2hE5HA8DaWHRm
Z62BH9L7IYsGXQ/Xxl9/b2SXB70Y1uSbnO4yn2cML+Fo7G741GddZAEc4UeUiOsOc5gm5AwP
3i51yyeHMqlLCXR6CoEPhCNXD7rGuz3NsH3YEGzLIkmBt84T/nEOkxh/MQZjOvVyB486fTrZ
tgaYGZP15laEhBadz7QUa2MbMH+d9AcNFD4+NyQ0oFJBsECokIMnVZgxkoM2pFz+4sYjJ+6B
WMdRjf0iJDHYTH8ubELkCjnyfAyK7SLZhxCs5DVbCw8UKLlmdrT4JiAdzsX8LZUConKR1+0f
JK98z44TkHMkxMOzcrnBD28BEKgZ+yRFgui9w2M7e8eWcGllKU7vVJCEIy6ZpvO0+T+ozExf
EWevA5jv/8l9WGtMQGK9+2RGUIbJO7MSm+zYczqQq0xTNMqTAjnlCtqd5xA1Bdw20sKlnChJ
2Q5CAwCW2wOZtDkr76N3mGSDIsqQqGZNsr6zawaKRAQKtv+5cMyUevrtQc8cPmVMWihHkXbR
0ecBCMtHB8JefmJ38iEvJaOEb79RFiBSgr7+0RfX947DXljFjM7CmtZb+EklyS/A/Ta8eKr4
eOf12vTWvHK1rWq14Dh5XiAAAAAAAAAADwXjPWXq+TzjzFzzfHeGVRyIuKGJKIPVlASO2YeM
G4z8GMSdUQeqFIXfEbi/lz05tb05rYbBHAvNiJqpG+mUGNtbjIsHdZqCA7CkPQhFDsiH2Iwl
Q+RonFRyoodXNKR74iY6k8elQT5I27SGOTEfplHlQctEZORR7vXj2pGSTnPEo99nXPJ5F+tG
0Aw5yjyLRNCGyYkeZ6zkMJWeJujtWEY2oM/tEfhJRthwtg29Dp+AZFo6OQ40iMDTGXOu1Yvv
2oJVaR6RQSL3ImhUfGQCvjWP0112NF+OY0ll+Q/EtGNBsojk+nE47o4SRBKMInw8RkBua9Dx
nd7dedBoKSOQiFFyI1T8cc+W/Rbkn8v4Rg42+s1su79hsQji52rSUd4hQSH3O3V4R67Y5XHw
7zZFQdB4ncPHhmUOoYeOrVuLJDeZcEzJdo7fJsdAYvNXJDFbERhY4lcY3P8EE/Q8rQLGDIEH
PJ7udVuZJwWQmzD55Qwr5TFwmKw+o3/R6/UNRe0laYxIVFjAciSjxTZ5HznmXoOfAw3mWVox
wMDhpFixi40ECJG8NJtvY53ZjIvd1G7G0qvyrwMQFei5XO0zxNdMmsW2jU1hHCDaA3ELPtrm
5saeYoxdI+8bGDT2545S648KpHW+KoERnIYRkxOuWqb53HXJvkwPMI4iJRkJ35F4LoRyDPPU
VZyNqVtERN4RfLjmEIlEC3RlF4MmetSH6uOTrKME5gbJZ446SZMFI/A9twxEBoXhbb7a5iZE
B9sCpKD1EeiIzT/d7zsfNBx9txYqitheAiGE3Skba4YXuOOMSMMCGxJbLpdBIKcrPXAugzOV
Gym7HdQD6Lq6IaN2bFloJjAmM016XcFgJwdi2AxjoMa2J6ZrBF8eeGiV1fTdlU+rWYWSYlGC
hBmV0XYpJ1cxtyrz1Vu+0LfFWM9kfkjv6o7EU27/iuX8GVVvdfjltqwkIcQjjQ5IE4OxYarx
jdFjkUbjND7xNuhdYl7u5ciNo0W0bZKvKU9GvLPy+B5+hqw/SfPl1SvAdHN8YicCMHzAPxMf
s+L+B/UeCIaGlyzCBeJSMhGSSSBxJ2HwUcfi62zcz+eRrnV7Pr+z9v2yfpqOipHPPR72ipSK
lTV0w9/8no0jZakLVWrCxVVQEQP36Ur5H2CBD2/+Hzmn5HdtsCiIjc5JcmpJKuGJtbk3JSmB
stPdQljC0pilkRgEVgejhQl/vvtxlH3rB95il/M7mhTvP1yRlJRWKFrXirLYxvZXOccn7XFV
479GzxIpAfDqt90zl8tMayb8YpRHUCA1Vdm6IJlMCMip9xN5D3ix5N8sV7+0S2IXD535rNEB
PrWlURVR+CtWeD+lGPs04Mb+jVr2tMxkC8UniA9lgsKY/DmaRdDHvDKkMIplAxBAKn+pwO5T
wDeIyLFh69CkCv+dTD4sHeZxK2t/pNTY4lVrH50+FiVZyeDU6GWk3vkYjtbMI3c1fqZaHAxO
NG6xP56+tWze8E3lYVNKteLlMx2MEB6npI2N7QiDndeEJOgg4YejQGE1Jzanmztvt3K1U+ph
qKsTLD9j+poy9YcQsDpE2kV+wJ45IyPDdR1HYFN4Zm+iHnzqtJlwUbOj/Mw3tmsONHuWHNZw
pprF/dzO46Blk6Rq5uLAaETQd5WMtA7IZs9P9buya3rp6Uu2J1KdS/8D3sTwVxXFSAsE02S6
TYZnkSYzUSNBVCINsGs4AUtCY7Tboyh9RYeguOapCEI3ikWECCsHgKbxTWOqQjE+a9XLhhVo
/4f2d8kIQkkuekSL1HHyE00PMMOWDjGbqSo2qh3Hj1Ea0/sJ7T9XaHSH7CJvKCIiOOHYLHjc
2ff9vNZE2f+PqkVnuoeciP0IECPZ2xhgX1x7t4iRx5jYRwz24sdB+M8sEprX5Z8JkJnAWiJX
Y8qRVBfjw7Zr3bHbrt03OD0HweEQMjqcdrCSz4kE6+PvnIwYxlkBCY78fV4OfowmKTDiMnIK
EjOMUhO5ETfzD7lWSneuf7dtrGrP8f2nyG49Hgft82wN5uDPdEhoWTSaByMaqwaTHAQViPAg
egJmskOEOFmHMju6gp07MzSINoZswoM44JvYx9Pugzcykm2nVAjT8uz0kjTdHrk+e0yfWTRu
m/ec71PUqQU/isiVekNhZ8Qo1cFkWHMPhzUPfVZdax9gV4JtP8zX9W5sgEBzofpN3cDl/rvp
stkRz/NQjaz6g7aodNHKS5nJdz8518x8OmSbB0uD/3HsB4pYxlBq2kIPQjV64RNqYDbvjs4j
THOoBWnVqpN8oQ54lF6+LkZFf/DwBCTJVPLWGBE6SZk1BBRk2occD+q6ZA6CxG6XHHPB87hW
NdeO6QUe06isqqrm03yhJQO5/C6mtERATyHMyo6SJociQQahQCrA/9e70/FqbAh0FNYcX0MD
pESL4pJWGBpKcBdl4D3el7tZuN+kGDLrCqY8i6+PImq+3+MnffDfQqNd0jzLh7unG4xFE6SJ
QhcVR1lQRLyB8xLijj58G16YxJ3eyPLHO4MrKVSlSqiqohkCBAhAIECUx33PPGSFVjcKnCe5
TfWFpa1xbfCrtPYTO+hl4uzBYVsmCtxvYB/QDYtgkksKypWzXFxqzVs1NNSsamaoiU0mrFis
zUzJJUsTbSZLaVRSWrFRYObE+bJhalqm5i5mpZhEpUlKbKZs7c4xkVhLM0bqvmNq2+HUrbbh
DsWIjKxVqlVJE1U0qyvSwShZKigsoyWCAHiakjBDMCuUspsucC3GuNw0uXLlXJqJMS5ctXLT
VyfhtWq27lqQYmIhgiSVCh1faZgf3dWl/DE9D5qozQCufLw9J48L792aCFWwoUqCBdZdSogC
SCg1EVcT4TxmWTITxbKNYXfSR8g4kzrJCPaVmoudrlevXhGMcDPxxxLiZXQdk1UewFFjbOB5
0IOW1SFDQ5yVZUYFCB37KjmA5B57CeaSSSSSPnNMyyxn57iMFgcYnEIjZzaLXvvcRL03JFZC
s8jyPI8jyPzLOevp6t0BucXPhLWmIetXA606dh7knbqeK7B7k/FM9x+sOowi+IojD+g+Ti63
bJOtHKl3OU14W3ho1ZH7PQr5+c/31OnHaTf5Pnln7mD6Ncs/o7NE+mxNVNTBR6HwGa/n+Jf4
i+bfvMoso0blfTHNE4iz6VZAgiSFRdtDmRPsQ4c1lD6Ox7u1jhekuEIMkkmsH/MyLior60rp
VHrN5nmVIusC3m8hvOpiUS7YwteVxDGVECYSEAJJKVwV67N2zAHLmkYlzfVEvGvBA7NSueBX
zaQGOidXcxftuMQtuyY0iQNGRDmjXhUuPGYDmiiDfQUMXAKhpjTG2NscmN4Q4bjKmxFjPmnR
Qj2guEaPoB428J7I5igKWh3gIKDkHAczJxgz3gNzO89kcEJGvrNwX3fd8lMx7K+qfxzDwyqj
8jWcfVJLLarFf5622zijRratZ2mbzOIM1VbanE4xTxFmMassddc4SoVykdYHI5Ax3m0GR1g0
jgGhxDvCoKMPabHkPQ34Xkf7j4vPe+nks6lV95T6DcwamTqP4P2pCnzwiSpJiksClWYiPgf9
2jQqQukCnq45jJP3qHlUn5osn12PdCh8yB7GI0UPkiO34TycvGyoNNQqpRAgRalAFvJE6QPh
BCpJwRUgOYplESSIweK5GBWL8R4IZjmO/3vtZgZ7UDr7MaHHV7/hHzMzV7uqzIkvEGAH+YLp
f2j+REVMFq2EZyf9Mtmpe2dLK3KLhd8kLpBqBChggm0Lw7wwnG+giAi5EE0BkbHBuZMGS+Y8
GDBg2N+REIaN9/1Sbcue1I1wiZNRxMzLnHgXw7Z9azPGfM7DNdUlKXsGTnuuX+w+mP1nyn7C
B78+Rv7u3qeqv2mRbEY/Oy/qglkuMM+/vNEzNJ0sSfQO8PEhgIzmSbLh4mZCgjGJGI3DQErH
4uAsvYe2ZLrjmuzXa83MLeXm5D2P1g70z3YJz5bKET0QISnJzjCHhGqCnwjYqH6113wUDEyG
fKyV3O9e/jnny1LHwJE16wD4lehAUYwFHyQyaT3PjSSYkzD8ObaQlgg2hUUS4xpmSVBKVIxa
J/uIjDCT5xODDg3u1MIiCMCxJ0xPyyHRPqI+kqKNaN+KGDfCKrxCYBD62DkhuCoASSAAAAAF
PhoQfd4mpkywYKampfVYyRraunPB7Dr0V2HWnJJJJIABJIEkgAEkmq7fK5XtR/mj152T4Rg3
lT6DAwOZo7m+MacLVtpKURQOopRSlOx9U/f9nr9MC1Im6CBiYl/6wbFzAwbWBqvbZPbF4H98
FPKwf3Lj98xeowWLJhUZ+JP3cby9fI+XXJ4ZIdlQ5PgTaMyNIDw4TUmylMykyEyCa4M0kv/I
y+DztSGxoZgnBjcmw0MTEWEFhF5IZhYsbaNudbQbltDCtCe9Ukf+T/xwdZ/ir/ir/BX/FWVZ
alxZFxKDvmOQ2kR3vIChmDY1QXsCT+P/AV8aDgKCMUJxKt8BohywpHiFIpZrH7494xZGuOL4
9luvt4q0GWHuRyXx3/un9Ga9TCI56QfAOyDlt2IjbZLkyqN5dkGikEG1AraAkiE/M/wkyJm2
DMN5pADxCIZsXGSsmYdjgwYQl29iJyVkaG2jLUHqdFk9B82QzQzzftJJa5Gkig8M5h85RGeQ
IA8y2bKrhISsYuzWIiyxF9W6O/QqvAiLcZkVKblkMdt7YjE6HpdUNvrn7D9zJCh8tsOiOuyJ
k8BkGD7tAe4MIxGMxMrtuglBoFuc5mP8ofXKCUdjiEPv3cm00VH2ILuqPKl0tI5OE0BzQ+CT
2HWAsuCn3J70ij75Fh45fLD9AQByKR7uh27R4tI0iKqoHqrKuamduvDTfMWw/sYXS8nvgmkU
GWUNs6hXDPXtQVu9PC584R33KqOrmbOCsMwB5IbDmkdLfTqgywVkIAaF1CZaeZDPTYjoWmIw
izp0yfFrjUxDeN+ngGldHxq3A187h9SkS8SjBIiIapY6pMxW+ZJg26VbXvqaTqSwxSST3kCE
no94LoDgOm8FjIugbF0plch2p1uzc2i75k42QOxscb9BroCZpcjpzqr0cqDU8oLcXqZvt0YY
m7fuTEHSIGjyHrfoOXzHx4e7Py/ojIfrfv/GSxNn75MshmVQQaO3acZzOZjDt8Wv2a6JsYSM
OFBg+RAJNiIMXHox85A7mqzHO0+7hq1ZS+/L6l4XyCa/n+jg2DNMY4A3SDc/P197ad1CTMUa
Aw8j5NOcBi7uDI1Tr5YxSDOJctrBWkSJ5zeJczMZuOXUHQqEbNmmzYkh+QeB+Acxu/nIGQ2O
pidsH6WHg975wMD8CmhsQPHY/STQieOzEUjuVab0dwqoxZutS/1B3QXkHkmnydgqqIEAj6nc
QkCEEe/v/lixJGKY+HweyELur0ObCD9lQ/XGmUiWjB5EDQ8Yx9ch9NblGPjkBnUfCDNwtuRA
wVPWsawCCG6qbp02IEmJ0dmYwhK+J5qIuEeidsgdB5oP0QfLmwjr1WcZdm2xvuEMamXdv0Ow
r3UoNQQxrQbyp25t/tIF1jgbZD70zFm19RwQ7N8NucCHdzcJcXsNKQnUMfe8IAlcLFBvLXxO
gc3GNxja+B3yKDZBrcdUQ5oO1qDYI59hthyeqEUstE+ZFNbEIjTRlm7Va7yuNEHcevtxy90L
DgjoQ3dxwwibqWm9RayG7v3UJmM/Gyuy+s2/uey2+141jbSsHOVQdhd4QqRDRwomjFzjIuLn
lJmAvE2dyFWFyPhIqDe4SQhss2DY9pkLGYoliewSsN6R+LffbvV6t75ibvovXAp8qTzNcMJX
9XPO14uUfJf7pW5ukpyS1alR7DB9U5XPcTzL26/7kdSP1j/TLE5KHpUVXyfUxIn/sUwmlRQA
/sifuQooxGkq2UlEAGkRJSHloWQCiCnuTk/0SiJ00tJtTWmSWMGJNCwgiFJbQnGBDMDkScZx
JyMjigjxIVA9cQD+GwoRCfoV5kBDxFzVg0dh9Ze48mjRs/yQIupo/mwk9of4yI8rJBmEf60F
n/dPqEoT6hPjPhE+wwJ9Qfg/yX/NhChNG5FP2QQT2FFAn90uH9tCYhIxIMUr+axLZJumQwZq
TzVMlJmhgIrURkBoYkCHyQx3bmBoib/0hvFCnmf3IZj/cfLMiCUJsE1cg6CbDFdR/gf6Kaid
WiprzkNHibHV5mfXYY2Q9+Oh/LWSgk/7MqF1i9ADnzV4A7MFQ7x3x/xP7ytRP7IyjD+2Zqre
1A4puNXA/uYeqL6NWruUVQ5R/n0Zj4NxjVB6d8kmk6fLS4xsyoTI8pggUirqwERyyJmZwJYl
8BIOaJ97ScpAegyylZBo8ygpNi/Wrl4Vbc5TXIrCRNAHV0OyjUZRE43HEtMK3sqL3yz1GtXy
OKby5s0GMTFVyH/V6zrmpnrVzGxyIKiD/o+mngsZo8SNmbUesmAlEiYjlmxmpYNpDUpExxo2
Yp/UnkLriTpwhuyDUi7IFjCxZZUsfyi4vrb3Zvg7YZjUbrbanI8LD1wernkcL10bcUYMvH/W
hr33ip3a7mlGQUEgQO+9FO4sssd5mJZzRRO02Upbaq0qy2Frt4xq4o6D1Nxns0ODNp1eh7Y6
u82oUAbUoc0tRkJgMEp2s7sOfZZTQ2lGDEsQG2hogvjYvjs4kI59aU9ZtQUsm409TNQrDfCW
MSYlRuUmCw3NNPqMFP+EbkJ02nb7aTjJqjypl38lkNsq3ZRdiZh5Ubet44aO1rD1hyao9V44
8wdid+4unoTFimAmS5vbf7bnhu4dRlzeaQ1cmmWnWnpE3q5K4nc1J5I1RryRyR18HDjI7Yng
0kH8Y/vTxy4IF2R3CRTQQtVlnIoTasN5TSwIqMI1KabZKz125MpZLNOkrmyhmExiqpZVWNni
jpNe96fo+PDM8LzcCg3QKJvz7ig6Ez2tJiJkvCKMIKOdMOqPQ7C3dJ0wb71N8Mm8NuJ2rIic
hioZEQXRAyVTrI2TueeAEJdHadkrFirZULPNNk063Wl5w3I2q+ijomx82HlBIHuIQc/Axtro
PTbbtMUDLwEyNIYMMZXyJkk0iegfF8+cIMsITejlBAmlhhvZmqTgiwVGDpCaxPRYk9FKkpKq
NBGqOSMSmXKvKLCNlsCtfjex7TqQPW3wfFNKvbncy8XvTEOHsjdHDeRW8adaQ+hGpU48PcFH
bGCHbQcA5EYRCkb5opvDMTimJvcuvizx3sxPiXmOpXlcrJxOplGWBj6A9rg96chMBsQjImcD
Mg2EzsxVyCxhIrKE01eC1VnNqjZGdHu0Myax04hi9bcmyaVM3EZxtQjUM33OchoiN2k7DJZS
+IudqOAG40E2BwIcBJwTGlDjwqG82iR1I3I3J1LVqmEb+Mne1FLgEEiIRFv1KbFN5EOR0n9h
lbMt/XUjz8XdZ5k0EyguRZ7SEI2s1UJjEkKqPMTA58jahyE6YmSMQORyNiWFMBbHlSI0snUc
zlqN03Kk2uhNqIXTN8/lNCvLyeTonQ6DR3J3vJXYVJNvwdMZTwxIh1dTuuQc6O5ZwIoI7lli
PMggBUtjDQwCqMaKjIJp1vdxJJTmOZs2QjUqSNErbyjQjRGJzRWfboj0PF3J6k9sjZ2o5SRb
KhnqIPLzBCf4xuJiJkDy88nHTUMchcMlckaJ6mrVqd7pD6hKRPFBQTTJB2mxexXHs4FnsE7T
EzAUsbwDEdH/9yQ5rInp60dSNzaMLIeLDEOfx3pPq6R2bSc3jwjsSFaN8dlYxI8aastdj5Ut
MCpJWVcmFRZJiowKjfO9z9MBwREdVjOhB9JaPR9SEdu6FujYBqO5Y8NX4u8nQ70eaPbUePim
CUms3o64/i/0f/J7PyPuR/OH3n4EKMlLjGz4n3DaUH00hR9NinS8EpwSlOGKYrz5oB9ydHRJ
+0fYP3S0c/W33N9hxNZGPrImokH4h1FBvsLD9ZA2jIsDEHDMP1AzSBDEiGXxn7D8e3rPrTil
/DoajDQDuP3/n/Y825uH6HyiP3VOgr5E2KtPwieTVR0SvsUyqNWJDR+KKylfk0mDG/RYqz+m
bmq/CH6SzJrH5Qox+/Xjoy0eTJFuljDgUYLaLGIk0KRsSAZH2UtiJigZ8vz4ponEM1aIh9ko
PtKB5EE1S8V5UokpTZpFM0QReZ3vC358W9JydhtNEcSphvbo/ONrHc3uSRxxLFgoju8q4bD9
D25G8b4ScuxcAbkukGoLLJOqqrj4J+F1aN9hu4TxMlq2RW+/7v9ntNRHMIhoFsrFSQT9w/D7
/xgkqRkASgxaBpIrTAaT0FAmAfRRrtKRxllKpSpnEfzov+2/0f9vzfM05MKz+5X5FFgEjBdS
PFclSIcBpyHgOCmw3DGvCxoOdiS0rrceC6DcyZZQOcqGJKr5yNU4J26ROvmxFUqnNhdd8nSo
3tMSP7GG+ZMssIypC04dOtpNRuKDhkLxwHQgkOKhTdTjQQSGX/CsMzonDtnAO/u3ji4nAxxG
W462ifn/dhlNp1i5yiQPAhXiKOYFHITawLc5I8OgSRDHzY4j9LiUDULOw8h2GJdxi4AqywkF
uzqBEhiCzcYvBL+JokODFMZuJUmIbSrC0S5XC1jVgy0TDrpTvO17dpFB3Azb5TaSyDS/CBqL
9BmVCEFf9qNxvIhiNdjVklEkG8ncRL3hQnZUki2fDEWrSgYLoQS5gyPaKBYGFhZKtVm46UYu
1ey6QqLskkwUUUQQEkHBGbNLfJapwZIBhIw9xYdMEFkCZAxUcYK5vWoGPHllhoYmioUNIYG5
qpGiFBCgjvbqEddxwdZhHh4LyezycnHZaqw3UwcMGI4qYieTLnbmHaqp/1Hp2Yf8jNkqJlSf
5BBpIH8Quu2Rf0+YEuEcQuAdMaTf3FKH4QJvA4pnA/MqG7ouZFaAz2I9YyBqFCgiFPNnX+aO
SBzNcF/Ni7vFMDHzHRmwL4dtAEV3n2j5EgGG5GDieLQAomadR9lVYg96xBAok2ZA0V1UN/0X
Bf3mrfWIpzBi6xmyquSbrDVH2j+kqT8m4OMG5elT33MUwY5TINxxoNvtFZk8O8mRNoc9yuP4
5bbrMyw6QD82nT6/XpA1vwVs1Lalcq8+R048N+KH0kt8Ng0vpZ8RdiCD5NtJEFDCqWqpaVTX
tsG5SZFNYjXP+fvYoyMO5YiISk4xPmLOmI9BRk8Tx4xoJrPShn1FVZXtPE8XCCJOzqUASIwN
QhxgjEENPGwzBV1lOqFfBRGXwd7wfBQpaB1GdcUoaZJjohjgRshQSCQx4KFEohVItFEkqGGJ
ghxzh2lsG1Czs4ETH7/bdnVDqCpGIfyHC/dcKHDhcMLQSJ3MQGrrR0Af4bWO12J9fwFx8HB2
YiViA5M2nkTwu1ebel6EWNujcWaJTICAgxZISoYU8E9JBWEQkBa8D1AdWAxwSlr2WGmMuZKp
b2okl2vX8L8JAo4oNBTkNDhG1igrAAsc6IQV/mID/EdO8ytVAtSQgSKAOTG2oRr6KJBoQQ7e
sS5AbZQmU4HHvDaicQMC/BAkX66QT4RZHrmmpHKjtV2+miM108o9DxTURuNAgPe/aGBlpiOU
ViLtDZ20bnwOrtMnHD3Cx5FhfJ6qXh474HDgiE8imMYpSUpRRTTRTTQ31MHClNVbhwwEgqPc
gdWK7B8TV0R6Y0YkMCxbFjGJJXedCgafP3nVSdM+OklzD1LBMYHHaEXsjBFVMJXaE9rtWYa7
EP5O4r7Wm3v6+7dzjLArGQ/nqgCESRJHokeQ8k8TvEDqtoQgO1EYmKC/mgIXq/Nqo/qowi+I
F1QhbgHJx3ZzGZH/OxiLGZwNYvWqc44x6He8XnC8Gj7DRJMJY4DdX0vT3ySeqctVDnXxL1dp
n3PHbvfAyivkdtOqk9ptNxhpV/Mse78uAEfV9xaAyEkKlo0SCK/j6frA7gWpEz7RsOgBDEvH
EbDj0oTYzHHlFEuUoFzF/Jp8UJDHVrfSFaAOB9AMADbqOzj59h6Ihm8IJGL8xS+YHdn4oIYT
kYlPDiPvkqTqgVI0sP0xDIpHOPoNdmloNoat99tUio9RcwF1ohwBwC4uh3km5xrU1OEYF48z
A5TGiG+E309bbhya6SPBz2GWkahiHcc36pwwmd1bpoqyxvLiJl2MTDwMhPJs1nH+qWqqy1En
Nbde61myRiW6lKASyHozCIyMgCT1CWuQpaJzCxq72MNa3TyhBrkLQgQJAoiUoFLhDTREeg7C
yjPIhGNsy3mCJWi7h2wxjzI1ZaIG5phYUYG0ZYQ4s4kkNoIx7RJ59JyG0dUEsRTGWoq0CiB8
UPo9x8BMB2EwY71d+JP99a2cTkSqMSvRZhPeLEcBVRAyHRT2hoicPq7HQiUSSl5KALJhswjC
jMZYjEnqPA6BY/1J7SKlJwoSQaigVvVgdAO3BLIyHX49jzhy1+F4786H9qx7Nxi1aPIqMKSl
opS1VWnSK35LUxUsX7lNWlOZDWYbGP0fV0cj5iAHXylvEqPphSklNTAwExCyQWfoF2F5Tt0D
vrzhRveWGaCBxMKRDaIBpNahChWAwkKPMUqzjE5diqwUg2YwNVBLZA6EH+Jb4ZjSydFEp2ga
MLjd8st8AnhFu0W2xIydhfGWxtrq4oRoBLbPBcAkEDzG9lKS0KYOEnUhvcQ9R2SYRCATFpoc
jN37zkzeptD5yfsRFeqEIAqoemNvcHrerTsVwxLRkjL7vA3eyTAec+BUTDBBpzglEWoqlIMB
HIsJO97AIOqwIQiQpE7d44I+hDiVz7Kv/8RGiIkq+WBW9vSxkxIpwLDZsb0wp9N5OsyOq3FO
AnluBfWHTkJmKWE2BXPYOuDEX+1ANonqNu4SJoZLxEivIDY0ahhYCiheYNItoPznRdG2ODxq
9wI4+flHUVek/MZxgcQi7EeF0AylJuGwDEBCJaMvc4kz1v9AT5Mw0PHkomQsZhH1beWwGnjY
a8ltKVON1ZnFctzQMKrluM/eisfr4OS1BjcwjdoSPaEi+yNyQxJAM9xBXW8rHQ6Kjapybo50
sUziTBUstSyUqqsWKWSsVZW3Y65DSEaFi2pzvNnSOMMaLeoi5SyqkOLe3GJuHHb78Sgdi5Tl
axHYpIjPPDN3ghdRyzC5EC4a5jWnoMIzjLfBReKJPCeTuakpgoQ8OUbbE6e0EYv+PFJGyO0C
OnEAPd7OGBznkI4gwjCPA2JyDN7IGNDYmyMZcra+mJ8EYMTzyuVIPlOyJ59hFSRuTKNmHHJ8
zWRHHLK3aOXBDGkucngIxnm9aoUA+O+OSzETIREZ3yK64HzEYUYZ1cFvjIlAM6ljgmuodAi4
EWXNIZNNhxncimSJinfrI7I+kqEaGGd0zjwKZIMlELf255mOu65Gu0+cgzllHLZ4kw8ZQyEb
waKRKN0b89uZNm/AcBJ0CA6dg7M3FjXJ89hc2F4fmiKE3zzLnAblB02L70kzoYyMyOxA9tWg
FvDIwgazaXg+Ix+9qMUvJOt0b5gnhIcOg0jIaKnbl2bdjgaUsa4jEilimSmumjKtFaYYRukh
3BrpEzio4FDxIloQTilbA+wHX6wxUoDFSjsh+HuhQ6Fk2vToGEipgXsWG0jb0PgDgcKHqEwd
u00KUsWOyZ668xMzITHFLiaiUSjJAiEUaDUJZEzQLvBAAxCm4GI885EihYLcsJGOXiIIXghL
rKHZAdsBJED2pVLEhiG+3ipFbkU6yiYes9pGUJNCk0a/wrDMTZGEdTT1Mo4E6I0PA5djMroY
ywbPOc3VKkmpT1HvHoVufAQhVi1SBRVEjyw2ROXZVUZl7ZD7N7E2+kn+xA1f4MCqsocRFl17
yLxhTJiyT/elIV76oUO06c7n19aBYIB8Ogjrov5lA3xOKd+45paSmqpY4O92iECbwqKYGJ4z
KZTNKTA+zDJp+B9yrP8ufRCFsIZifaGd42CqEWvmyK9KJupOXpSL6z1k+P26Hy8sD6RUMH0f
ku+T5Avb3qTNpGw+LRUOpPjJgJpoyFEIfqzPUR+SRK2iqzQ21JwETw0bkrWOjCb4RCygVPkj
xPT27JHFScHVhNkJixKioXkpJJR1va8QNxt2bQ8yd9fMuYHISITrCsiJmlDH3qfTRYVh5CIP
RQ6g+IYb5D2lVieYxUzi2k8lDQx+yBrqVpG8kbzu2B3dRnwSXkiyBMR5igMh54IwZkyVjvg9
FRn56YE59YPzA0WcQPVbzvwGPog3RI6gNAep8ZtsidbnPfFp06gOz7RKk7XeyNocexVUQVFn
1Z8giWaWmKyuKFarpSlIyDRIyYNNMSAQjNLZAzJJJkkmTI0RoqS79L2d055LV5O3W4pYwwIq
XNCU29fbbAVAgZpQ4BuE6+NndGXqbng1jMVJ6mv0Fh515+2RyhVkFUqyZ+okqg1VEwstFpY6
3tdqxzH3SK7LJUtVKsqyRwioxJZC0GBhiSRaFpMGDB4wAgfTPQcMdlZCUT7WMw1LrTSiGshi
uAbrISqJGwe5obhYUkXwwYP1nwU4EUscG36qzJ+9hMIcTx3fyXhG6STvT7ljLR6mYYysVR0g
phRBoKYlkxVAg6BQcCWSzYeAPQDAmbG9MRMR3MDNlJUV9WEwpogKdplifYpo5R0eexq7Fc0c
4x1SPPBAp1GhOscBMi0OOISUlNimwcD9FPGOrDdH7VRhK4RY4FSZkcnd+T+VjAh+PUguTSqt
cqqVVd6zNsWZW0zWNJ6imsprXL5PK5TO/gMgalkhr4nxuZxe9FOGXpOicBLInWDmmh3kFaVs
RLRCyRVhB6eUFbKWsTyPj6N7X3LPThyb1RwPNJZHdO1461b2I5RyTZlg+qzK0qV649yvLhGC
MWqCaWSUiefZSlwxzOQL0B13Y45MhgXK1GsbTJ5MRMsX8T+n4bSNXRu3fF9DWSPRqifH3mdi
tzRIHMoo9HH0dBxLOwgUcxpPAQ3JBIdPjEp80qQhdCVemop7aGxLBPeEoCsCLFBoMYr5uFQx
9WQNooLB0kPjUtlpU+vKHx0SaqSHyslqAqwWjY2xto1rk0+mS3fYSEweSiQI+CWSvYzIkPfJ
SZ5A2q9mVkjcJEwSQhAYhAYpIpZZaxvxGhG9rjJlGiGLEyGBjqQ3EyUDeC30F7jBYSPgNdT1
nmsL85ExTrOaPt9RTjuhun/RBue9PsKnqmHXEd56BaV7FF6j8gaB6AsFcFziE1oXBBukSJ8w
WSlcLK9aek+LdCWxNL8gsXRUANIsC7sK6QQDEORl20QEKCVGC56TgIiULbBCkREFgh8ZpDce
sSU6Ee310rvChwSRLJFPvTFA2spfI9C1XGuLa3kat73LrDixaSLcXUYjezhbE9lYqwbRgous
BHtxGXEuJ1nkNx+XbwE0ifOhDM8Sm0zHEDV99/P3myLiAUwZE/aMUKiAdxBPqV4jXqQ8HVOO
6hhK3BnfgcACfA1MqkppaPBLNIljndLfIbvL0OI+6G73g7xB0PUjIhE9gaic4AjCJrzSk4wa
C+KuFTt84hLNj8HJcNoP8Hmxxn6FxYLC7kxkJmeeIxAMxUWll7i65eCsrPi8b+VZuuDElsXl
GxKVc5Wyu1y1XFis9rlyeBbJgS/IUJ3uhgzfcGxp6XVno5S30HA0+dYUqimzCR+jWzvOEhpp
LJhxkMHqH3nbCJMtwXBHqjLVvRbYd9xYKlSrEWrKlqLVyeP7d7qH5lPHuDZ2E7kg8l93RvBZ
CRkUIQSNqyySrFUSlRZF8GG9xeadDuQ51s3YmeYOQ/LIQc15ljNB6VkuHnt59MFD9VmoTbED
HIskC18lN6nNTETklEMrrGI+uR/Zcho6hwcVltsdOx2azB5Ha9hyR1tnKolbViIlsReXfzw+
WHtjJu/k/qLIe01D0UlH42+lCwOFngRE6JIU9xyC8BzIDK/OW0b7Flh4llbn60mCN1EEdB9Q
WDBewPn3Ntik3bnU5/rSi3bQmzlQFMR42JiiLfRYGVi0mUwdrhjMJ2Q6OsHOE53DU4I8uMQu
lsorTtm5zSLSz85KDCRd5dTSSGBkikNPEYJqpiL+JU1WCmDDBUjdMLiRN1S1CbimlgNGhXCZ
JosIVvBEeoN5Y3IcjVTFaTv05DbNIOAhqYG5AkYvCKswUoewg7daJFcIVGBBS8kLboP16nE2
u84moSAsIuhDa62PMQmzBMwT+DzaNGhfmNsikIBFI9P2HtA5NrshGQVkYDIQ3oNCZK9AU4Mj
gwnq1GZ7esyfDte2lZiBzN1BK8bIMgSE3CQ78k8CPAd7PvQqhk3lUZwIfWeoOdeG6qvRXObR
60xIYizx9m/pYMCGK1WzMcIwdCRp1iKRCUJew9yZcmTPIj1C4eBUh1T7+qGLb8ZC00ilkZye
4NKjIJkswikKaRZ64CfwkFVNdsnQo9I01L5rtxjV6+Pg+mWcOa7zA0hIMjaJop0O3LwO2goj
skgG0J7X2cpG1w0Z/aQV8EfOHWjqHUUI5nsko/VxjFzP7II70KCEORwKiUSGjY6CJDdHMdC8
Z1a2Z8BCVoNbG0ShIs2g/KaJR6fj+MrWQZpuldfJmJpg/b7X723X2TpGx2zlhiVDB8aLMRiL
JlRVE6lVJs2GmEk3p9ca9FhYL1EtDuRJwfBLHfd07rw31/iO3oIEqGT5eUhDEOGDsCXhThZG
SYYNslgzaQNzXSMlOM0nOydHOSSBcWvMdnc7IMJ1OknZnKlWCQgQyHgLsC2SkkHjgfvIwO0s
mSROGmhYwlJwAosyI4DehthKSJmIGAbHEuJYYqGKmIS8aCq16j3i1B1ECVQzzFHBPQGo4Wkl
yjQDuPuQaCgMWuyy0CJSu/ecuvBq4hlFIewNcIXEh/HPQU7ZJAIJmK4pMlNNZQI5EFGMSWLH
DHUVO6KljJkd43omsfljwbo49NlFnwHaB1JqrmBZaYJJFISBGESDAYMDerFsWNSw2brRto4Y
xbrIUtUh/AvXcBcfmxHnBx3c4shBMw+kZBisGEYkJETiXkTI40gG9ieY4pvO1ac05M4E0hHV
DDolkhpCsYgt2KMIK+UwJQyJRKAqK0CNoiMIYSSkSApAwgoTWUJrSEgspKShaWg4mKYJG41d
QaabAYNwuIWIiKYq2Ap1ChUXSSIGqUjUe+KRuv6Tq+P8uMOph/taw0kTKvREqBIBPQkpkLEW
RG0Bw++9vexTP7jMLBvkCe4mPNcHNDCAPrfmDv82W0lxzIjZd1Kbev31dqhBJFWBFixigREi
QTEchyTNHrAIisTTY8QTBByN2BSp9RwPKIvk4/T9ApknOHrCh8iWAOcQpIp0HYWHgGBSHVab
AfvLq4pS3bhghoISwvdIBgLjYaAPpNbBXs1LHQjxEhptXwwT6h2CuSiUkUkSHVn2DzDuHsES
hNAsue/lsolSVVV9oeyZJijuIKQj3ZfMsn9buDSkuTEmFiizFgmP6GYIhhkLBV0LYx6JYfjc
DrdQqNNJCUB1khZhSowJvulIO8/N8aXyPML5rOBrgPqqOxnj6nIrljCVVkqcWgYB3XsgeUPF
mc0l3P70KOAYxH1/hSl/A6vjiv1fAd8snbmMSGxA6jbsPQp+4S/ancdiPjBKH1J14qJmm/Kq
pJBJ226WqYBxQTjUMzkWiMeHGckDxNfoiUYJMB1ByOg2rPnPIiB8hbGD6bdn37CIf4DJgbWc
PQ0dfOVK0x7YcQGdJjSPIa4TAskC4bdNcYIigmYxCkyBnYxYZ8DCQSjJxMpozBltNmr4hq8r
B4bIIyctImjcdtBCTFNBQG9EWRTWRnyyRpgbSjBKY0dAyYtJjBpsIHAKEzHFr3elCgch2eRG
wcTWqk3c+ZhsI0TjajQ/I2APAQLEDg7SsiyUxshweyeFuHRnqvncpymFs8BswwphiKfS2Voq
tBWjT7ml0vU9I6kVI5wsSYPZWMTMQzIulUVUqfcGBYCSbIhQhEzV2lv09OSt0gbOOZimHIYp
vJGKxOB2FDbvMhSs9pbvNvUkT5YlzFnpPa9U3gfmHtMReKyR3RScx4RPZgwmh2DozGpncTwe
QVQGprD4r2P1HjyO7Yqm3E0OcphCJNLVzLqjPv9U36KtiimafwUSfXdZI5liRuyoxELhFVHb
YPFSGNmDj2wlLTvXppEnVvsO9JkkRTsgFu3StyGlefpdWulptEQs2gWQSQP0kDxtkoIpkRec
VbkQMcDKVP6CuamtUpdoW8raxDMrS2oyoyYN6yVpTnq0ky0rWcGGiUpIEHeBR8ZgI4oGMGcj
I/FJuVyVr1Ajhhrs0aFy+H1FBQtkBsjqhyInaZLbBCHIIbT4KdMLwhyMGY43BXaKWtUSix5r
03EnC3bVej5eAqXQ6Dt+ArZcTQ6jguCLHe0jUADzxczJSynsBIqa1waHUqKjDCVGHY5I0j9y
tVWtjk6TP0Pewr34ZQ/Q+tiC0kzRbEYqJUZH/zJAoPvNgUHDgvluUjzeALyOygOyA+sTUftz
6sA7EpE7gvvH5xLmuRhgCZSpKUVKLIsiPSIlVIlJUpYUIpUtkqLJOzVMmR1EwU5H2JBQwNjx
Iq+8uYKpuDEx1UTgMoxPa5SOqSdTqRkJH+gqRmi3g1LI1yRXpqzQ1UxZFNEasKiJPrvrdflJ
1Dcj7pUo+mxsQ5E5O7lpGi1Fm1s1wqiWwjNRSyJMub7cPpuw9RTUwuV0aSJCEP1jcqywHuIa
01cD6lwRXcQZuFeeX7Oje6Oc+k+k6Osqp9q9rlDv1zOJhrEZYOzhpmweErtVTgoz5g8UsbQI
PIrayuJQfCokoRJEIYPxHVwaak59CQWSCtnwbmCQmEY/qIaGj9JJaN7DMOkkNGrNewuWEQQC
xFYqYmHx6SWE1B9NZ72W4gi3LcExsRAzY2i3B4XHSax2SbA4szQpEbCBILceo6KAWN3Xm88U
hU7sQ1Mz1HTO1NQqqtCZiWUqSLGxbQi3Juiy0UB6A0gQOiopEY2r1JtMtz09SfCWta3G52yK
mEco4iOVS2QtS0JbJUKSSyyTiqHkbz4F4mVQ3I9e5k0dkDnB8YQgKfosh+bGhJVJglNJHwmB
cXAZFgXEBjpZXzNKhHfeeF5C9mEBzGjCApxbkaMc45bx+2uMivdnDBRi2VGayIhaESEGFG6l
5KWYwOwMjEFfSJ5TI9uHA6lIb9fWQKMhoW9sOCVAl3mGHQ8EayxYbms3JvdjCeguYttwmPnn
JljJRwWj3ZJ7pVb70cEDhFD+ixISEm4ZYTupNdqUi5cEx8YUb/2xxqH1MmHWW1Ih1kAuUbRd
YCnRIlM2trFA8AyV7zkEF4GNm3ga0mArmhglcI7NWicFgTiqVKm2R2OtM845rDdJ850GuBv4
OXvTZeTRl1Q6cJvZYn84sawnExPWsec4vHsls7Bq7EWqFZVWISzDFtKYVEsiSgbFMfFsHBKY
ScElieSs6OQ93Y05u9tEKFu1Do4SiFLIU0bOIyFD6w8/baO4oMEO48AstPTapjdRZ/G+w8JG
Oq1Yd1GJujEqpvOSyZkq2rCsPYzmPNhhFlR99ezz7mzwzhmfCYyEFEm5vNjBjQMaFYyyJJGw
Gq6UrDX81bvlGW5qxYqb2d6JYskTO0w6EoaRHs1cgjJygtj0hhJstDBM5DIDI0aoli5DU+ZP
NGDnGuUnCEJMYpbqilFVhM4ZWKUqqshjNXG4E8xGyMYRhc40aYuaDE0wSwZg6s7QKsLsubG1
qybkc97KabGJtEySbmsPTMiWrMIXKBbFBb3AIY0bGoppmCNkxYbyQS4GQPNRjYoz0etisQYz
g3U3mdrxuUGbFttJtEBu71mqG02w1CzoV4RRjEWWTpCIAtQiTCRAQA0Sj43/Yx/HgdS9Lp0w
jQVNq5MsFVhTUpWTouhihZNg5t6SmsEGesYSjFBY0OifIcJwRBJEYE8ike4UtCicPBjoFAYk
7LRiHTYIxB7pCgMTCIUYKFz6iKsYcVxip6xBqgbQ4cJw+IMWixckErkBCk3Kmw2ukS27EoZB
1yCsgi4rkRULsBqBaFRCRKYOimgHaHTll8BbMwKkJSUbWQXxRCkkPGqPhh5lR0jZPvraeHNG
VkimrvQ9RG0UhOEKwBukKFIfQESDFuhUFBEQolKSqIcx1zCHRBOQUlsy9DRSUZeGTzhRVC4J
L4idQqNmBAkS+vowTr0OCe9lSGAkIjBYEd8hlPSOTjGS9lS2Rg/BYTeA9VI+FkJNYsUblsbR
3xmZRaYi6RPniMXV2ZkhwIzsHO1cod+0j+Mww1mH6t/rMttReF+hYtv6IwjNTNRyFjBZKWyN
ZTR5YTBwOULJRQ1lRkQegDxPiXQ3G4Sh3BTsTYgZl+412m5HlODkcGkmVkiVu68QyLzjTzya
Ki2SdiGzBkZa5hJJcJItSBtnWrVryhwNHapm6uzpnF2sYjfl9A/E5BvTn7djtEugJropvowA
BzgqckU2D5poe9R1ydcksx1KpqwcOWiMj7Q/GijmUnnA5CBZE9HrDCpsiZWKX2D3fcgKm/98
J9CMx1+96QJLFh7oI9hXzziLXiLI52Fe+SD3L4+nL8u7DOk91ZcmPvPenlvVxhqy5yb30wrl
B6yN/xaLEqQGQOTnO4jc60AvmrmCfiFlPIPGuXmDmW3x2BoniIvtMeZvbjGAGRGk+qUEIWM0
pA9HrLeSQoIqgWEvDmntTwPd7tSRJgb5e05jXGCZqGYnRvPa35/t+yA7XcDrDRA7uyoYGMJj
BJgy+Rod+vwiRJuhHug9Z3tJR2HQWBAuf7hLCkX4Ej0+MfjrtVvYuMKfsqyN1YV5w56tyumG
DoVqM6CgGkuQpSoYzRCw+BzyRGzpu4Faaa8D6H34nmJ7sUh+PwuGn4tKGIUL6iEd4QgMgHbR
qrxG9E8Jvbo9UXehkJwY4Yfl3BYBjWjwEp/Q6Cu0si0glsGnFjGRAp8FKWxo2lspatFK2lTx
XQuCFQSokiX9UpYt72LPq79EfuyOjs9TRllm48VjBq/VFYrMmz7okdITxbTGwNZG0WyJvnEJ
okEw3DkpZUNl3SIfnT1YAFh7IphwT1Jqh601H7cCUUXIeD9hjNzcNX/eetyNiB6LEJohypOK
dRT630IGceB+pdhNSSiNKYSBCE9nf1GU+IhKTfNQvGyKDtcWIXlCu/lOwG6V7VjsPAYIIhw9
AImTEXJTCssUyTlIafxjBPclRFIqJJ4Hwv4dePOz4bMSXZgjUpKlfdGL7WMDq6uokIYrop1g
gCtkEGRDztYhpGQotEwSMpEWgqHaLJRbRDlFx+NSYovpGDF0ixC1Bub2zM92gYEX4k/cpzd4
aTaSCo6prCTpw5b49JETg0xh4rCfwo8KVZIsUqltkxaabdKTRYtqXOc5Nv2WylSyfn/H/Tkk
1LJtiKoTaySKtBHFBH2uDSfXPt3/8XckU4UJCBEJg/A=
--------------85EDE57B5E5A181D6C43A0C4--


From owner-linux-xfs@oss.sgi.com Thu Nov 16 15:18:27 2000
Received:  by oss.sgi.com id <S553853AbQKPXSR>;
	Thu, 16 Nov 2000 15:18:17 -0800
Received: from deliverator.sgi.com ([204.94.214.10]:21094 "EHLO
        deliverator.sgi.com") by oss.sgi.com with ESMTP id <S553822AbQKPXR6>;
	Thu, 16 Nov 2000 15:17:58 -0800
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 PAA07554
	for <linux-xfs@oss.sgi.com>; Thu, 16 Nov 2000 15:10:05 -0800 (PST)
	mail_from (nathans@wobbly.melbourne.sgi.com)
Received: from wobbly.melbourne.sgi.com (wobbly.melbourne.sgi.com [134.14.55.135]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id KAA15576; Fri, 17 Nov 2000 10:15:19 +1100
Received: (from nathans@localhost) by wobbly.melbourne.sgi.com (980427.SGI.8.8.8/980728.SGI.AUTOCF) id KAA45097; Fri, 17 Nov 2000 10:15:15 +1100 (EDT)
From:   "Nathan Scott" <nathans@wobbly.melbourne.sgi.com>
Message-Id: <10011171015.ZM138590@wobbly.melbourne.sgi.com>
Date:   Fri, 17 Nov 2000 10:15:13 -0400
In-Reply-To: Danny <danscox@mindspring.com>
        "Re: XFS ACL Patch" (Nov 16,  5:50pm)
References: <200011161859.MAA12613@jen.americas.sgi.com> 
	<3A1464C9.F3027609@mindspring.com>
X-Mailer: Z-Mail (3.2.3 08feb96 MediaMail)
To:     dcox@connex.com
Subject: Re: XFS ACL Patch
Cc:     linux-xfs@oss.sgi.com, Scott Smyth <ssmyth@connex.com>,
        John Trostel <jtrostel@connex.com>,
        Robert Stickel <rstickel@connex.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

hi Danny,

On Nov 16,  5:50pm, Danny wrote:
> Subject: Re: XFS ACL Patch
> ...
> 	Okay, here's a patch which should be much happier!  It's against
> test10, and seems to work on my system.
> ...
> 	I noticed that the attr_get, set, remove, et. al. have been changed to
> be just one system call instead of five (or so).  Should I also emulate
> that and create only one system call for ACLs?
> 

They were cut down from eight system calls to one, primarily to
solve the system call collision problem which cropped up between
XFS and RedHat 7.0, but also to get some SGI folk looking into
the issues related to EAs & to start thinking about ways to
properly "fix" the XFS source.

WRT system calls for ACLs, I think you need to ask that on the
linux-acl, linux-fsdevel and linux-kernel lists.  I'd suggest
having a look at the approach that Andreas has taken for ext2
ACLs and make use of that if at all possible - would be a good
idea to contact Andreas (Gruenbacher <ag@moses.parsec.at>) and
work together to ensure a consistent interface is used.

As with extended attributes, once an interface is agreed upon,
that is what XFS will have to use (i.e. the existing one-syscall
"attrctl" interface is guaranteed to change, so don't base any
decisions on that!).

cheers.

-- 
Nathan

From owner-linux-xfs@oss.sgi.com Thu Nov 16 16:05:08 2000
Received:  by oss.sgi.com id <S553806AbQKQAE6>;
	Thu, 16 Nov 2000 16:04:58 -0800
Received: from ppp0.ocs.com.au ([203.34.97.3]:39179 "HELO mail.ocs.com.au")
	by oss.sgi.com with SMTP id <S553652AbQKQAEo>;
	Thu, 16 Nov 2000 16:04:44 -0800
Received: (qmail 23426 invoked from network); 17 Nov 2000 00:04:38 -0000
Received: from ocs3.ocs-net (192.168.255.3)
  by mail.ocs.com.au with SMTP; 17 Nov 2000 00:04:38 -0000
X-Mailer: exmh version 2.1.1 10/15/1999
From:   Keith Owens <kaos@melbourne.sgi.com>
To:     Russel Ingram <ringram@gargoylecc.com>
cc:     linux-xfs@oss.sgi.com
Subject: Re: XFS with ReiserFS 
In-reply-to: Your message of "Fri, 17 Nov 2000 01:21:04 PDT."
             <Pine.LNX.4.21.0011170116580.1038-100000@roujin.gargoylecc.com> 
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date:   Fri, 17 Nov 2000 11:04:37 +1100
Message-ID: <6517.974419477@ocs3.ocs-net>
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, 17 Nov 2000 01:21:04 -0700 (MST), 
Russel Ingram <ringram@gargoylecc.com> wrote:
>Now all I have to do is figure out why my
>modules have stopped loading at boot time.  I went from 2.2.16 to 2.4.0
>kernel so I'm guessing it actually has to do with either the modutils
>version I have or with the new devfs.  Anyway, thanx guys.

2.4 kernels need modutils 2.3.  I just released 2.3.20 to fix a
security problem, it should also fix the sparc relocation problems that
were reported on this list.

ftp://ftp.<country>.kernel.org/pub/linux/utils/kernel/modutils/v2.3


From owner-linux-xfs@oss.sgi.com Thu Nov 16 17:19:28 2000
Received:  by oss.sgi.com id <S553863AbQKQBTT>;
	Thu, 16 Nov 2000 17:19:19 -0800
Received: from chyndslgw1poolA164.chyn.uswest.net ([63.227.165.164]:5174 "EHLO
        roujin.gargoylecc.com") by oss.sgi.com with ESMTP
	id <S553812AbQKQBTP>; Thu, 16 Nov 2000 17:19:15 -0800
Received: from roujin.gargoylecc.com (IDENT:ringram@roujin.gargoylecc.com [10.0.0.2])
	by roujin.gargoylecc.com (8.9.3/8.9.3) with ESMTP id JAA05316;
	Fri, 17 Nov 2000 09:23:41 -0700
Date:   Fri, 17 Nov 2000 09:23:41 -0700 (MST)
From:   Russel Ingram <ringram@gargoylecc.com>
To:     timmo@psn.net
cc:     linux-xfs@oss.sgi.com
Subject: RE: XFS with ReiserFS 
In-Reply-To: <000901c0501c$403d9d20$06fefec0@nimmo.org>
Message-ID: <Pine.LNX.4.21.0011170918160.5310-100000@roujin.gargoylecc.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 Thu, 16 Nov 2000, Tim N. wrote:

> Date: Thu, 16 Nov 2000 15:26:22 -0700
> From: Tim N. <timmo@nimmo.org>
> Reply-To: timmo@psn.net
> To: linux-xfs@oss.sgi.com
> Subject: RE: XFS with ReiserFS 
> 
> Would you give us an update after a week or two of runtime? It would be
> interesting to know about the stability of your build.
> 
> Thanks!
> 

Actually this is my main server so I am putting the beta kernel on it
because I figure there is a little less chance of my machine crashing.  I
am however planning a redo of my workstation in the near future so I will
try it on there and report back. =)

Russ


From owner-linux-xfs@oss.sgi.com Thu Nov 16 20:57:09 2000
Received:  by oss.sgi.com id <S553858AbQKQE5A>;
	Thu, 16 Nov 2000 20:57:00 -0800
Received: from pneumatic-tube.sgi.com ([204.94.214.22]:15422 "EHLO
        pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP
	id <S553744AbQKQE4r>; Thu, 16 Nov 2000 20:56:47 -0800
Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.55.149]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id VAA07662
	for <linux-xfs@oss.sgi.com>; Thu, 16 Nov 2000 21:04:33 -0800 (PST)
	mail_from (nathans@snort.melbourne.sgi.com)
Received: (from nathans@localhost)
	by snort.melbourne.sgi.com (SGI-8.9.3/8.9.3) id PAA51561
	for linux-xfs@oss.sgi.com; Fri, 17 Nov 2000 15:55:25 +1100 (EST)
Date:   Fri, 17 Nov 2000 15:55:25 +1100 (EST)
From:   Nathan Scott <nathans@snort.melbourne.sgi.com>
Message-Id: <200011170455.PAA51561@snort.melbourne.sgi.com>
To:     linux-xfs@oss.sgi.com
Subject: TAKE - repair
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.4.x-xfs:slinx:78435a
Date:  Thu Nov 16 20:55:00 PST 2000
Workarea:  snort:/build4/nathans/linux-xfs
Author:  nathans

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

cmd/xfs/repair/bmap.c - 1.6
cmd/xfs/repair/dir2.c - 1.16
cmd/xfs/repair/phase4.c - 1.51
cmd/xfs/repair/phase6.c - 1.62
cmd/xfs/repair/sb.c - 1.38
	- handle memory allocation errors more gracefully than with a core.


From owner-linux-xfs@oss.sgi.com Fri Nov 17 01:04:41 2000
Received:  by oss.sgi.com id <S553797AbQKQJEb>;
	Fri, 17 Nov 2000 01:04:31 -0800
Received: from thorium.uunet.be ([194.7.1.46]:52751 "EHLO thorium.uunet.be")
	by oss.sgi.com with ESMTP id <S553757AbQKQJEM>;
	Fri, 17 Nov 2000 01:04:12 -0800
Received: from gate.vum.be (firewall.vum.be [194.7.240.162])
	by thorium.uunet.be (8.9.1/8.9.3) with SMTP id KAA02833;
	Fri, 17 Nov 2000 10:03:59 +0100 (CET)
Received: from pcgx14500003.vum.be (pcgx14500003 [83.105.1.4]) by leonidas.vum.be with ESMTP (8.7.6/8.7.1) id KAA06738; Fri, 17 Nov 2000 10:06:07 +0100 (MET)
Received: from vum.be (IDENT:kris@localhost.localdomain [127.0.0.1])
	by pcgx14500003.vum.be (8.9.3/8.8.7) with ESMTP id KAA09106;
	Fri, 17 Nov 2000 10:03:26 +0100
Message-ID: <3A14F45E.A844533C@vum.be>
Date:   Fri, 17 Nov 2000 10:03:26 +0100
From:   kris buggenhout <gast6@vum.be>
X-Mailer: Mozilla 4.75 [en] (X11; U; Linux 2.4.0-test5 i686)
X-Accept-Language: en
MIME-Version: 1.0
To:     Steve Lord <lord@sgi.com>, linux-xfs@oss.sgi.com
Subject: Re: XFS on sparc 64
References: <200011162105.PAA21883@jen.americas.sgi.com>
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: base64
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing

U3RldmUgTG9yZCB3cm90ZToNCg0KPiA+IGtyaXMgYnVnZ2VuaG91dCB3cm90ZToNCj4gPg0K
PiA+ID4gdGhpcyBpcyB3aGF0IEkgZ2V0DQo+ID4gPiB3cml0ZSBlcnJvcg0KPiA+ID4NCj4g
PiA+IHVtb3VudCBoYW5ncyAuLi4NCj4gPiA+DQo+ID4gPiBhbmQgc2h1dGRvd24gbm8gZ28g
Li4uDQo+ID4gPiBpbml0IDYgaGFuZ3MgLi4uICh1bW91bnQpDQo+ID4gPg0KPiA+ID4gTm92
IDE1IDE1OjU4OjU1IHdpbm5ldG91IGtlcm5lbDogU3RhcnQgbW91bnRpbmcgZmlsZXN5c3Rl
bTogc2QoOCw2NykNCj4gPiA+IE5vdiAxNSAxNTo1ODo1NSB3aW5uZXRvdSBrZXJuZWw6IEVu
ZGluZyBjbGVhbiBYRlMgbW91bnQgZm9yIGZpbGVzeXN0ZW06DQo+ID4gPiBzZCg4LDY3KQ0K
PiA+ID4gTm92IDE1IDE2OjAzOjAxIHdpbm5ldG91IGtlcm5lbDogSS9PIEVycm9yIERldGVj
dGVkLiAgU2h1dHRpbmcgZG93bg0KPiA+ID4gZmlsZXN5c3RlbTogc2QoOCw2NykNCj4gPiA+
IE5vdiAxNSAxNjowMzowMSB3aW5uZXRvdSBrZXJuZWw6IFBsZWFzZSB1bW91bnQgdGhlIGZp
bGVzeXN0ZW0sIGFuZA0KPiA+ID4gcmVjdGlmeSB0aGUgcHJvYmxlbShzKQ0KPiA+ID4gTm92
IDE1IDE2OjAzOjAxIHdpbm5ldG91IGtlcm5lbDogUENEOiBwYWdlYnVmX2JtYXAgZXJyb3Ig
LTEwMTAgcGJfZmxhZ3MNCj4gPiA+IDB4MTAwMTAwMDINCj4gPiA+IE5vdiAxNSAxNjowMzow
MSB3aW5uZXRvdSBrZXJuZWw6IFBDRDogcGFnZWJ1Zl9ibWFwIGVycm9yIC01IHBiX2ZsYWdz
DQo+ID4gPiAweDEwMDEwMDAyDQo+ID4gPiBOb3YgMTUgMTY6MDM6MzMgd2lubmV0b3UgbGFz
dCBtZXNzYWdlIHJlcGVhdGVkIDYyMyB0aW1lcw0KPiA+ID4gTm92IDE1IDE2OjAzOjQ3IHdp
bm5ldG91IGxhc3QgbWVzc2FnZSByZXBlYXRlZCAyODUgdGltZXMNCj4gPg0KPiA+IG1vcmUg
aW5mbyA6LT4NCj4gPg0KPiA+IHdoZW4gdHJ5aW5nIHRvIHJ1biB4ZnNfcmVwYWlyIG9uIHRo
ZSByZWJvb3RlZCBzeXN0ZW0gOiBpIGdldCA6Pg0KPiA+IHBhZ2VfYnVmIG1vZHVsZSAtIENv
cHlyaWdodCAoQykgYnkgU2lsaWNvbiBHcmFwaGljcyBJbmMuIDIwMDANCj4gPiBzeXMzMl9p
b2N0bDogVW5rbm93biBjbWQgZmQoNCkgY21kKDIwMDAxMjZjKSBhcmcoZWZmZmU1NjQpDQo+
DQo+IEp1c3Qgc28geW91IGtub3csIGludGVybmFsbHkgd2UgaGF2ZSBtYW5hZ2VkIHRvIGNv
bWUgdXAgd2l0aCBhIHNjZW5hcmlvIHdoaWNoDQo+IGNhbiBraWxsIGFuIHhmcyBmaWxlc3lz
dGVtIG9uIGFuIGlhMjMgYm94IGFzIHdlbGwuIFdoYXQgd2VyZSB5b3UgZG9pbmcgaW4NCj4g
dGhpcyBwYXJ0aWN1bGFyIGNhc2U/IEluIG91ciB0ZXN0IGl0IGludm9sdmVzIGZpbGxpbmcg
dGhlIHdob2xlIGZpbGVzeXN0ZW0NCj4gd2l0aCBkYXRhIChJIGFtIHVzaW5nIGxtZGQgdG8g
d3JpdGUgNTEyTWJ5dGUgZmlsZXMgYWxsIG92ZXIgdGhlIHBsYWNlKS4NCj4NCj4gU3RldmUN
Cg0KSSB3YXMgZmlsbGluZyB0aGUgZmlsZXN5c3RlbSB3aXRoIGFuIGZ0cCBjbGllbnQsIGp1
c3QgcGxhaW4gbWdldCA2R2J5dGVzLA0KZ290IHRvICsxIEdpZyBvZiBkYXRhLC4uLiB0aGVu
IGkgZ2V0IGEgd3JpdGUgZXJyb3IgLi4uIGFuZCB0aGUgZnMgaGFuZ3MgLi4uIGNhbnQNCnVt
b3VudCAuLi4gLT4gbm8gc2h1dGRvd24gcG9zc2libGUgLT4gaGFyZCByZXNldCAhDQoNCnRo
ZW4gdHJ5aW5nIHRvIGdldCBpdCByZXBhaXJlZCA6DQoNCltyb290QHdpbm5ldG91IC9ob21l
XSMgeGZzX3JlcGFpciAvZGV2L3NkZQ0KeGZzX3JlcGFpcjogd2FybmluZyAtIGNhbm5vdCBz
ZXQgYmxvY2tzaXplIG9uIGJsb2NrIGRldmljZSAvZGV2L3NkZTogSW52YWxpZA0KYXJndW1l
bnQNClBoYXNlIDEgLSBmaW5kIGFuZCB2ZXJpZnkgc3VwZXJibG9jay4uLg0KUGhhc2UgMiAt
IHVzaW5nIGludGVybmFsIGxvZw0KICAgICAgICAtIHplcm8gbG9nLi4uDQogICAgICAgIC0g
c2NhbiBmaWxlc3lzdGVtIGZyZWVzcGFjZSBhbmQgaW5vZGUgbWFwcy4uLg0KZnJlZWJsayBj
b3VudCAyICE9IGZsY291bnQgLTIwNDggaW4gYWcgMA0KYmFkIGFnYm5vIDQyOTQ5NjUyNDgg
Zm9yIGJ0Ym5vIHJvb3QsIGFnbm8gMA0KYmFkIGFnYm5vIDUzMTI0NDcyMCBmb3IgYnRiY250
IHJvb3QsIGFnbm8gMA0KICAgICAgICAtIGZvdW5kIHJvb3QgaW5vZGUgY2h1bmsNClBoYXNl
IDMgLSBmb3IgZWFjaCBBRy4uLg0KICAgICAgICAtIHNjYW4gYW5kIGNsZWFyIGFnaSB1bmxp
bmtlZCBsaXN0cy4uLg0KICAgICAgICAtIHByb2Nlc3Mga25vd24gaW5vZGVzIGFuZCBwZXJm
b3JtIGlub2RlIGRpc2NvdmVyeS4uLg0KICAgICAgICAtIGFnbm8gPSAwDQpCdXMgZXJyb3Ig
KGNvcmUgZHVtcGVkKQ0KDQoNCltyb290QHdpbm5ldG91IC9ob21lXSMgeGZzX2NoZWNrIC9k
ZXYvc2RlDQp4ZnNfY2hlY2s6IHdhcm5pbmcgLSBjYW5ub3Qgc2V0IGJsb2Nrc2l6ZSBvbiBi
bG9jayBkZXZpY2UgL2Rldi9zZGU6IEludmFsaWQNCmFyZ3VtZW50DQpmcmVlYmxrIGNvdW50
IDIgIT0gZmxjb3VudCA0Mjk0OTY1MjQ4IGluIGFnIDANCmNhbid0IHJlYWQgYnRyZWUgYmxv
Y2sgMC80Mjk0OTY1MjQ4DQpjYW4ndCByZWFkIGJ0cmVlIGJsb2NrIDAvNTMxMjQ0NzIwDQoN
Cg0K

From owner-linux-xfs@oss.sgi.com Fri Nov 17 02:50:42 2000
Received:  by oss.sgi.com id <S553799AbQKQKuc>;
	Fri, 17 Nov 2000 02:50:32 -0800
Received: from plutonium.uunet.be ([194.7.1.47]:62735 "EHLO plutonium.uunet.be")
	by oss.sgi.com with ESMTP id <S553766AbQKQKuD>;
	Fri, 17 Nov 2000 02:50:03 -0800
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 LAA11702
	for <linux-xfs@oss.sgi.com>; Fri, 17 Nov 2000 11:49:58 +0100 (CET)
Received: from pcgx14500003.vum.be (pcgx14500003 [83.105.1.4]) by leonidas.vum.be with ESMTP (8.7.6/8.7.1) id LAA02888 for <linux-xfs@oss.sgi.com>; Fri, 17 Nov 2000 11:52:05 +0100 (MET)
Received: from vum.be (IDENT:kris@localhost.localdomain [127.0.0.1])
	by pcgx14500003.vum.be (8.9.3/8.8.7) with ESMTP id LAA09297
	for <linux-xfs@oss.sgi.com>; Fri, 17 Nov 2000 11:49:24 +0100
Message-ID: <3A150D34.58FAEA1B@vum.be>
Date:   Fri, 17 Nov 2000 11:49:24 +0100
From:   kris buggenhout <gast6@vum.be>
X-Mailer: Mozilla 4.75 [en] (X11; U; Linux 2.4.0-test5 i686)
X-Accept-Language: en
MIME-Version: 1.0
To:     linux-xfs@oss.sgi.com
Subject: Re: XFS on sparc 64
References: <200011162105.PAA21883@jen.americas.sgi.com>
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: base64
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing

SSBmb3VuZCB0aGF0IGFsd2F5cyBjcmFzaGVzIGluIHRoZSBwcm94aW1pdHkgb2YgNTAwTWVn
IC4uLg0KDQpsYXN0bHkgaXQgd2FzIDoNCg0KL2Rldi9zZGUgICAgICAgICAgICAgIDE3Njgx
MjY0ICAgIDQ1MTUzNiAgMTcyMjk3MjggICAzJSAveGZzX2ZpbGVzeXMNCg0Kb24gYSAxOEdp
ZyBkcml2ZQ0KDQpwcmV2ZW91cyBpdCBjcmFzaGVkIGF0IDQ4MjkwMCBLYnl0ZXMNCg0KZ29p
bmcgdG8gd3JpdGUgc2NyaXB0IHRoYXQgd3JpdGVzIGEgZmlsZSBpbiBpbmNyZWFzaW5nIHNp
emUsIGVyYXNlICwgcmV3cml0ZS4uLi4NCg==

From owner-linux-xfs@oss.sgi.com Fri Nov 17 07:04:23 2000
Received:  by oss.sgi.com id <S553834AbQKQPEN>;
	Fri, 17 Nov 2000 07:04:13 -0800
Received: from nic-31-c12-053.mn.mediaone.net ([24.31.12.53]:40722 "EHLO
        lupo.thebarn.com") by oss.sgi.com with ESMTP id <S553813AbQKQPDz>;
	Fri, 17 Nov 2000 07:03:55 -0800
Received: from thebarn.com (localhost [127.0.0.1])
	by lupo.thebarn.com (8.11.0/8.11.0) with ESMTP id eAHF3cj17988;
	Fri, 17 Nov 2000 09:03:39 -0600 (CST)
	(envelope-from cattelan@thebarn.com)
Message-ID: <3A1548CA.71E44765@thebarn.com>
Date:   Fri, 17 Nov 2000 09:03:38 -0600
From:   Russell Cattelan <cattelan@thebarn.com>
Reply-To: cattelan@thebarn.com
X-Mailer: Mozilla 4.74 [en] (X11; U; Linux 2.2.12 i386)
X-Accept-Language: en
MIME-Version: 1.0
To:     kris buggenhout <gast6@vum.be>
CC:     Steve Lord <lord@sgi.com>, linux-xfs@oss.sgi.com
Subject: Re: XFS on sparc 64
References: <200011162105.PAA21883@jen.americas.sgi.com> <3A14F45E.A844533C@vum.be>
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 filling the filesystem with an ftp client, just plain mget 6Gbytes,
> got to +1 Gig of data,... then i get a write error ... and the fs hangs ... cant
> umount ... -> no shutdown possible -> hard reset !
>
> then trying to get it repaired :
>
> [root@winnetou /home]# xfs_repair /dev/sde
> xfs_repair: warning - cannot set blocksize on block device /dev/sde: Invalid
> argument
> Phase 1 - find and verify superblock...
> Phase 2 - using internal log
>         - zero log...
>         - scan filesystem freespace and inode maps...
> freeblk count 2 != flcount -2048 in ag 0
> bad agbno 4294965248 for btbno root, agno 0
> bad agbno 531244720 for btbcnt root, agno 0
>         - found root inode chunk
> Phase 3 - for each AG...
>         - scan and clear agi unlinked lists...
>         - process known inodes and perform inode discovery...
>         - agno = 0
> Bus error (core dumped)

This looks consistent with the problem we are working on right now.

When the file system gets close to being filled it runs around finding all the
small left over extents. At some point one of the writes goes to far and scribbles
over
the the ag structures. We are getting close to resolving the bug... give us a day
or
so.

The core dump on the repair is not a good thing although... do you have a stack
trace?


>
>
> [root@winnetou /home]# xfs_check /dev/sde
> xfs_check: warning - cannot set blocksize on block device /dev/sde: Invalid
> argument
> freeblk count 2 != flcount 4294965248 in ag 0
> can't read btree block 0/4294965248
> can't read btree block 0/531244720

--
Russell Cattelan
cattelan@thebarn.com




From owner-linux-xfs@oss.sgi.com Sun Nov 19 08:12:40 2000
Received:  by oss.sgi.com id <S553784AbQKSQMa>;
	Sun, 19 Nov 2000 08:12:30 -0800
Received: from deliverator.sgi.com ([204.94.214.10]:25136 "EHLO
        deliverator.sgi.com") by oss.sgi.com with ESMTP id <S553664AbQKSQME>;
	Sun, 19 Nov 2000 08:12:04 -0800
Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id IAA06287
	for <linux-xfs@oss.sgi.com>; Sun, 19 Nov 2000 08:04:11 -0800 (PST)
	mail_from (lord@jen.americas.sgi.com)
Received: from thistle-e185.americas.sgi.com (thistle-e185.americas.sgi.com [128.162.185.204]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id KAA6987630 for <linux-xfs@oss.sgi.com>; Sun, 19 Nov 2000 10:09:32 -0600 (CST)
Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.184.86]) by thistle-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id KAA55341 for <linux-xfs@oss.sgi.com>; Sun, 19 Nov 2000 10:09:32 -0600 (CST)
Received: (from lord@localhost)
	by jen.americas.sgi.com (8.9.3/8.9.3) id KAA09872
	for linux-xfs@oss.sgi.com; Sun, 19 Nov 2000 10:03:03 -0600
Date:   Sun, 19 Nov 2000 10:03:03 -0600
From:   Steve Lord <lord@sgi.com>
Message-Id: <200011191603.KAA09872@jen.americas.sgi.com>
Subject: TAKE - fix corruption on full disk
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

When converting delayed allocate extents to real extents on a full
disk there was a problem when the space requested did not fint into
one chunk of disk space.

Date:  Sun Nov 19 08:00:38 PST 2000
Workarea:  jen.americas.sgi.com:/src/lord/xfs-linux.2.4

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


Modid:  2.4.x-xfs:slinx:78535a
linux/fs/xfs/linux/xfs_lrw.c - 1.63
	- In xfs_iomap_write_convert fix min statement which caused us to return
	  zero extents sometimes.



From owner-linux-xfs@oss.sgi.com Sun Nov 19 11:11:31 2000
Received:  by oss.sgi.com id <S553831AbQKSTLL>;
	Sun, 19 Nov 2000 11:11:11 -0800
Received: from deliverator.sgi.com ([204.94.214.10]:10059 "EHLO
        deliverator.sgi.com") by oss.sgi.com with ESMTP id <S553752AbQKSTKy>;
	Sun, 19 Nov 2000 11:10:54 -0800
Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id LAA19747
	for <linux-xfs@oss.sgi.com>; Sun, 19 Nov 2000 11:03:01 -0800 (PST)
	mail_from (cattelan@gibble.americas.sgi.com)
Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id NAA7656884 for <linux-xfs@oss.sgi.com>; Sun, 19 Nov 2000 13:09:31 -0600 (CST)
Received: from gibble.americas.sgi.com (gibble.americas.sgi.com [128.162.195.80]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id NAA32689 for <linux-xfs@oss.sgi.com>; Sun, 19 Nov 2000 13:09:31 -0600 (CST)
Received: (from cattelan@localhost)
	by gibble.americas.sgi.com (8.11.0/8.10.1) id eAJJ9V915829
	for linux-xfs@oss.sgi.com; Sun, 19 Nov 2000 13:09:31 -0600
Date:   Sun, 19 Nov 2000 13:09:31 -0600
From:   Russell Cattelan <cattelan@sgi.com>
Message-Id: <200011191909.eAJJ9V915829@gibble.americas.sgi.com>
Subject: TAKE - 
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

Date:  Sun Nov 19 11:09:16 PST 2000
Workarea:  gibble.americas.sgi.com:/export/extra/x2.4-xfs-beta
Author:  lord
Merged by:  cattelan
Merged mods:  2.4.x-xfs:slinx:78535a

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


Modid:  2.4.x-xfs-beta:slinx:78535a
linux/fs/xfs/linux/xfs_lrw.c - 1.55
	- Merge of 2.4.x-xfs:slinx:78535a by cattelan.
	  In xfs_iomap_write_convert fix min statement which caused us to return
	  zero extents sometimes.



From owner-linux-xfs@oss.sgi.com Sun Nov 19 11:26:31 2000
Received:  by oss.sgi.com id <S553833AbQKST0L>;
	Sun, 19 Nov 2000 11:26:11 -0800
Received: from perninha.conectiva.com.br ([200.250.58.156]:30481 "EHLO
        perninha.conectiva.com.br") by oss.sgi.com with ESMTP
	id <S553818AbQKSTZo>; Sun, 19 Nov 2000 11:25:44 -0800
Received: from freak.distro.conectiva (freak.distro.conectiva [10.0.17.22])
	by perninha.conectiva.com.br (8.9.3/8.9.3) with ESMTP id RAA14693;
	Sun, 19 Nov 2000 17:25:29 -0200
Date:   Sun, 19 Nov 2000 17:24:57 -0200 (BRST)
From:   Marcelo Tosatti <marcelo@conectiva.com.br>
X-Sender: marcelo@freak.distro.conectiva
To:     Chaitanya Tumuluri <chait@getafix.engr.sgi.com>
cc:     linux-xfs@oss.sgi.com, axboe@suse.de, mkp@linuxcare.com
Subject: [RFC] split kiobuf/buffer-head IO code Re: xfs file system 
In-Reply-To: <200011061445.JAA20862@getafix.engr.sgi.com>
Message-ID: <Pine.LNX.4.21.0011191547530.5667-100000@freak.distro.conectiva>
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, 6 Nov 2000, Chaitanya Tumuluri wrote:

<snip>

> Again, in principle yes, you are right. However, the only major users of
> kiobuf I/O to date (raw I/O and XFS) already have their own compat. 
> codepaths. So, its not a burning issue to be addressed...as much as say
> someone stepping forward to work on the `md' driver :^)

Chait, Jens, Martin, 

Currently, generic_make_request() function and the per request queue
make_request_fn() operation implement buffer-head and kiobuf based IO.

IMHO the block layer should handle different IO "methods" (kiobuf and
buffer-head) with different code.

This way the code gets cleaner, more simple, and independant from
each other.

Right now, I think the following should be done: 

- split request_queue_t->make_request_fn into kio_make_request_fn and
bh_make_request_fn.

- Add a flag to be passed in blk_init_queue to inform if the caller
supports kiobuf based IO.  If the flag is on, set req->kio_make_request_fn
to __kio_make_request.
 
- split __make_request into ll_kio_make_request and ll_bh_make_request (or
whatever better name for the functions).

- split generic_make_request into kio_make_request and bh_make_request.
ll_rw_block should use bh_make_request and ll_rw_kio should use
kio_make_request.

This way, LVM and RAID should have their own kio_make_request and
bh_make_request separate functions.


Comments? 

I'm working on RAID1 code. I'm running dbench on a kiobuf mounted XFS
filesystem over a raid1 array with 2 SCSI partitions for some time now
(the code is not complete yet, though, and I want to solve the issue
discussed above).



From owner-linux-xfs@oss.sgi.com Sun Nov 19 22:05:14 2000
Received:  by oss.sgi.com id <S553838AbQKTGEy>;
	Sun, 19 Nov 2000 22:04:54 -0800
Received: from blount.mail.mindspring.net ([207.69.200.226]:11816 "EHLO
        blount.mail.mindspring.net") by oss.sgi.com with ESMTP
	id <S553835AbQKTGEe>; Sun, 19 Nov 2000 22:04:34 -0800
Received: from jtsdell.ceo.com (user-2ivfk6u.dialup.mindspring.com [165.247.208.222])
	by blount.mail.mindspring.net (8.9.3/8.8.5) with SMTP id BAA14286
	for <linux-xfs@oss.sgi.com>; Mon, 20 Nov 2000 01:04:30 -0500 (EST)
Message-Id: <200011200604.BAA14286@blount.mail.mindspring.net>
From:   John M Trostel <jtrostel@connex.com>
To:     linux-xfs@oss.sgi.com
Reply-To: jtrostel@mindspring.com
Subject: Using quotas with Linux XFS
Date:   Mon, 20 Nov 2000 01:01:35 -0500 (EST)
X-Face: 'c9f.yE|?(hy=Y>!'TIC0:!p22rSzh*+Ht<AmVIuw=f?:XV-IYZNC#r^.p9LY\]Sx.sUJ0U&`&Y|}el3-.Q,!>t$K*rn.h!T]q}mt36hNEY\\-/&I/8!x_8(-7JdG<$zLQ^?5f(;j~5=;)FAe,Q^L$<.JbR{&=;FuF:\@liU5)--/P_)q90Ye_[z_vH2rll::uc8LY"M,rx+a%UH<y]LfySg#gjm;R^rPk#KZ&`AwTsGk'nY2Ft"%0^[V'zk=i?u7p1Rd2YO
X-Mailer: XCmail 1.3devel - with PGP support, PGP engine version 0.5 (Linux)
X-Mailerorigin: http://www.fsai.fh-trier.de/~schmitzj/Xclasses/XCmail/
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="boundary_XCmail_1.3devel_3A18BE3F_jtsdell.ceo.com"
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 is the preamble area of a multipart message.
Mail readers that understand multipart format
should ignore this preamble.

If you are reading this text, you might want to
consider changing to a mail reader that understands
how to properly display multipart messages.
(like the cool XCmail)

--boundary_XCmail_1.3devel_3A18BE3F_jtsdell.ceo.com
Content-Type: text/plain
Content-Description: Main text
Content-Transfer-Encoding: quoted-printable

I am having some trouble using quotas with XFS on my linux system.  I am
using kernel 2.4.0-test10 and the XFS file system has been working fairly
well overall.  I am now trying to implement the quota tools (from the
./cmds/quota directory).

The problems I am having are the following:

1. setting grace times - When I invoke 'edquota -t' I get the proper
screen:

Grace period before enforcing soft limits for users:
Time units may be: days, hours, minutes, or seconds
  Filesystem             Block grace period     Inode grace period

When  I attempt to set some grace period quotas on the file system as:

Grace period before enforcing soft limits for users:
Time units may be: days, hours, minutes, or seconds
  Filesystem             Block grace period     Inode grace period
/dev/hda8                   1 day                1 day

I receive no error from the code which parses the temp file, but a
subsequent 'repquota -a' shows no grace period added into the /dev/hda8
limits.

I have mounted the file system with the quota option (usrquota doesn't
work, but a bit of digging showed quota as an alternative).

2. If I set the block and file limits for a user to some non-zero number
such that repquotas responds:

[root@jtsdell quota]# /usr/local/sbin/repquota /dev/hda8

  Electric Fence 2.0.5 Copyright (C) 1987-1998 Bruce Perens.
                        Block limits               File limits
user            used    soft    hard  grace    used  soft  hard  grace
root      --      16       0       0              8     0     0       
jt        --   45856       0       0             12     0     0       
sambaman  --       8     104     104              1    50    50       

The setting of the quota seems to have worked BUT... sambaman can not
change anything or add anything to the filesystem without a disk quota
exceeded error.

Any clues as to what I am doing wrong? or right ;->

-- 
John M. Trostel
Linux OS Engineer
Connex
jtrostel@connex.com


--boundary_XCmail_1.3devel_3A18BE3F_jtsdell.ceo.com
Content-Type: text/x-vcard
Content-Description: vCard
Content-Transfer-Encoding: quoted-printable

begin:vcard
n:Trostel;John
tel;cell:404-735-0423
adr:;;;;;;
version:2.1
email;internet:jtrostel@connex.com
org:Connex
end:vcard



--boundary_XCmail_1.3devel_3A18BE3F_jtsdell.ceo.com--


From owner-linux-xfs@oss.sgi.com Sun Nov 19 23:07:34 2000
Received:  by oss.sgi.com id <S553840AbQKTHHO>;
	Sun, 19 Nov 2000 23:07:14 -0800
Received: from deliverator.sgi.com ([204.94.214.10]:24123 "EHLO
        deliverator.sgi.com") by oss.sgi.com with ESMTP id <S553837AbQKTHGn>;
	Sun, 19 Nov 2000 23:06:43 -0800
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 WAA18874
	for <linux-xfs@oss.sgi.com>; Sun, 19 Nov 2000 22:58:49 -0800 (PST)
	mail_from (nathans@wobbly.melbourne.sgi.com)
Received: from wobbly.melbourne.sgi.com (wobbly.melbourne.sgi.com [134.14.55.135]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id SAA06775; Mon, 20 Nov 2000 18:05:24 +1100
Received: (from nathans@localhost) by wobbly.melbourne.sgi.com (980427.SGI.8.8.8/980728.SGI.AUTOCF) id SAA26364; Mon, 20 Nov 2000 18:05:23 +1100 (EDT)
From:   "Nathan Scott" <nathans@wobbly.melbourne.sgi.com>
Message-Id: <10011201805.ZM152790@wobbly.melbourne.sgi.com>
Date:   Mon, 20 Nov 2000 18:05:22 -0400
In-Reply-To: John M Trostel <jtrostel@connex.com>
        "Using quotas with Linux XFS" (Nov 20,  1:01am)
References: <200011200604.BAA14286@blount.mail.mindspring.net>
X-Mailer: Z-Mail (3.2.3 08feb96 MediaMail)
To:     jtrostel@mindspring.com
Subject: Re: Using quotas with Linux XFS
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

hi John,

On Nov 20,  1:01am, John M Trostel wrote:
> Subject: Using quotas with Linux XFS
> 
> [ Main text
>   Encoded with "quoted-printable" ] :
> 
> I am having some trouble using quotas with XFS on my linux system.  I am

I guess I should butt in right there & say that xfs quota on
linux are a work in progress & anything that works should be
seen as a blessing. ;-)  there's alot left to do here... the
most you should expect currently is that it builds.

> using kernel 2.4.0-test10 and the XFS file system has been working fairly
> well overall.  I am now trying to implement the quota tools (from the
> ./cmds/quota directory).
> 

these are only half (at best) finished, so problems should be
expected...

> The problems I am having are the following:
> ...
> Any clues as to what I am doing wrong? or right ;->
> 

no, I'll have to have a look into this.  there's a good chance
that this has never even been attempted yet, so just send me a
patch if you can see the problem, otherwise i'll have a look
into it tomorrow.

cheers.

-- 
Nathan

From owner-linux-xfs@oss.sgi.com Mon Nov 20 01:30:24 2000
Received:  by oss.sgi.com id <S553843AbQKTJaE>;
	Mon, 20 Nov 2000 01:30:04 -0800
Received: from thorium.uunet.be ([194.7.1.46]:2572 "EHLO thorium.uunet.be")
	by oss.sgi.com with ESMTP id <S553839AbQKTJ3j>;
	Mon, 20 Nov 2000 01:29:39 -0800
Received: from gate.vum.be (firewall.vum.be [194.7.240.162])
	by thorium.uunet.be (8.9.1/8.9.3) with SMTP id KAA12950;
	Mon, 20 Nov 2000 10:29:33 +0100 (CET)
Received: from pcgx14500003.vum.be (pcgx14500003 [83.105.1.4]) by leonidas.vum.be with ESMTP (8.7.6/8.7.1) id KAA18596; Mon, 20 Nov 2000 10:31:44 +0100 (MET)
Received: from vum.be (IDENT:kris@localhost.localdomain [127.0.0.1])
	by pcgx14500003.vum.be (8.9.3/8.8.7) with ESMTP id KAA15711;
	Mon, 20 Nov 2000 10:29:01 +0100
Message-ID: <3A18EEDD.A313D46D@vum.be>
Date:   Mon, 20 Nov 2000 10:29:01 +0100
From:   kris buggenhout <gast6@vum.be>
X-Mailer: Mozilla 4.75 [en] (X11; U; Linux 2.4.0-test5 i686)
X-Accept-Language: en
MIME-Version: 1.0
To:     cattelan@thebarn.com, linux-xfs@oss.sgi.com
Subject: Re: XFS on sparc 64
References: <200011162105.PAA21883@jen.americas.sgi.com> <3A14F45E.A844533C@vum.be> <3A1548CA.71E44765@thebarn.com>
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: base64
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing

UnVzc2VsbCBDYXR0ZWxhbiB3cm90ZToNCg0KPiA+DQo+ID4gSSB3YXMgZmlsbGluZyB0aGUg
ZmlsZXN5c3RlbSB3aXRoIGFuIGZ0cCBjbGllbnQsIGp1c3QgcGxhaW4gbWdldCA2R2J5dGVz
LA0KPiA+IGdvdCB0byArMSBHaWcgb2YgZGF0YSwuLi4gdGhlbiBpIGdldCBhIHdyaXRlIGVy
cm9yIC4uLiBhbmQgdGhlIGZzIGhhbmdzIC4uLiBjYW50DQo+ID4gdW1vdW50IC4uLiAtPiBu
byBzaHV0ZG93biBwb3NzaWJsZSAtPiBoYXJkIHJlc2V0ICENCj4gPg0KPiA+IHRoZW4gdHJ5
aW5nIHRvIGdldCBpdCByZXBhaXJlZCA6DQo+ID4NCj4gPiBbcm9vdEB3aW5uZXRvdSAvaG9t
ZV0jIHhmc19yZXBhaXIgL2Rldi9zZGUNCj4gPiB4ZnNfcmVwYWlyOiB3YXJuaW5nIC0gY2Fu
bm90IHNldCBibG9ja3NpemUgb24gYmxvY2sgZGV2aWNlIC9kZXYvc2RlOiBJbnZhbGlkDQo+
ID4gYXJndW1lbnQNCj4gPiBQaGFzZSAxIC0gZmluZCBhbmQgdmVyaWZ5IHN1cGVyYmxvY2su
Li4NCj4gPiBQaGFzZSAyIC0gdXNpbmcgaW50ZXJuYWwgbG9nDQo+ID4gICAgICAgICAtIHpl
cm8gbG9nLi4uDQo+ID4gICAgICAgICAtIHNjYW4gZmlsZXN5c3RlbSBmcmVlc3BhY2UgYW5k
IGlub2RlIG1hcHMuLi4NCj4gPiBmcmVlYmxrIGNvdW50IDIgIT0gZmxjb3VudCAtMjA0OCBp
biBhZyAwDQo+ID4gYmFkIGFnYm5vIDQyOTQ5NjUyNDggZm9yIGJ0Ym5vIHJvb3QsIGFnbm8g
MA0KPiA+IGJhZCBhZ2JubyA1MzEyNDQ3MjAgZm9yIGJ0YmNudCByb290LCBhZ25vIDANCj4g
PiAgICAgICAgIC0gZm91bmQgcm9vdCBpbm9kZSBjaHVuaw0KPiA+IFBoYXNlIDMgLSBmb3Ig
ZWFjaCBBRy4uLg0KPiA+ICAgICAgICAgLSBzY2FuIGFuZCBjbGVhciBhZ2kgdW5saW5rZWQg
bGlzdHMuLi4NCj4gPiAgICAgICAgIC0gcHJvY2VzcyBrbm93biBpbm9kZXMgYW5kIHBlcmZv
cm0gaW5vZGUgZGlzY292ZXJ5Li4uDQo+ID4gICAgICAgICAtIGFnbm8gPSAwDQo+ID4gQnVz
IGVycm9yIChjb3JlIGR1bXBlZCkNCj4NCj4gVGhpcyBsb29rcyBjb25zaXN0ZW50IHdpdGgg
dGhlIHByb2JsZW0gd2UgYXJlIHdvcmtpbmcgb24gcmlnaHQgbm93Lg0KPg0KPiBXaGVuIHRo
ZSBmaWxlIHN5c3RlbSBnZXRzIGNsb3NlIHRvIGJlaW5nIGZpbGxlZCBpdCBydW5zIGFyb3Vu
ZCBmaW5kaW5nIGFsbCB0aGUNCj4gc21hbGwgbGVmdCBvdmVyIGV4dGVudHMuIEF0IHNvbWUg
cG9pbnQgb25lIG9mIHRoZSB3cml0ZXMgZ29lcyB0byBmYXIgYW5kIHNjcmliYmxlcw0KPiBv
dmVyDQo+IHRoZSB0aGUgYWcgc3RydWN0dXJlcy4gV2UgYXJlIGdldHRpbmcgY2xvc2UgdG8g
cmVzb2x2aW5nIHRoZSBidWcuLi4gZ2l2ZSB1cyBhIGRheQ0KPiBvcg0KPiBzby4NCj4NCj4g
VGhlIGNvcmUgZHVtcCBvbiB0aGUgcmVwYWlyIGlzIG5vdCBhIGdvb2QgdGhpbmcgYWx0aG91
Z2guLi4gZG8geW91IGhhdmUgYSBzdGFjaw0KPiB0cmFjZT8NCg0Kbm90IGFueW1vcmUgLi4u
DQoNCg0KYnV0IEkgY2hlY2tlZCBvdXQgdGhpcyBtb3JuaW5nIHRoZSBjdnMgLi4gYW5kIGRp
ZCBhIHJlZHVpbGQgLi4uIGl0IGFsbCBjb21waWxlZA0KY2xlYW4uLi4NCg0KYnV0IG5vdyBJ
IGhhdmUgYSB3b3JzZSBwcm9ibGVtIC4uLiBpZiBJIHRyeSB0byB3cml0ZSBkYXRhIDogaW5w
dXQvb3V0cHV0IGVycm9yIC4uLg0KdW1vdW50IGFuZCB4ZnNfcmVwYWlyIGRvIHdvcmsgbm93
IC4uLiBidXQgSSBjYW50IHdyaXRlIGEgYml0IG9mIGRhdGEgLCBjYW4gY3JlYXRlDQpkaXJl
Y3RvcmllcyBvayAuLi4gYnV0IGNhbnQgd3JpdGUgZGF0YQ0KDQoNCltyb290QHdpbm5ldG91
IC94ZnNfZmlsZXN5c10jIGVjaG8gMSA+IHR0dHQNCltyb290QHdpbm5ldG91IC94ZnNfZmls
ZXN5c10jIGNhdCB0dHR0DQpjYXQ6IHR0dHQ6IElucHV0L291dHB1dCBlcnJvcg0KDQoNClN0
YXJ0IG1vdW50aW5nIGZpbGVzeXN0ZW06IHNkKDgsNjQpDQpFbmRpbmcgY2xlYW4gWEZTIG1v
dW50IGZvciBmaWxlc3lzdGVtOiBzZCg4LDY0KQ0KSS9PIEVycm9yIERldGVjdGVkLiAgU2h1
dHRpbmcgZG93biBmaWxlc3lzdGVtOiBzZCg4LDY0KQ0KUGxlYXNlIHVtb3VudCB0aGUgZmls
ZXN5c3RlbSwgYW5kIHJlY3RpZnkgdGhlIHByb2JsZW0ocykNClBDRDogcGFnZWJ1Zl9ibWFw
IGVycm9yIC0xMDEwIHBiX2ZsYWdzIDB4MTAwMTAwMDINClN0YXJ0IG1vdW50aW5nIGZpbGVz
eXN0ZW06IHNkKDgsNjQpDQpFbmRpbmcgY2xlYW4gWEZTIG1vdW50IGZvciBmaWxlc3lzdGVt
OiBzZCg4LDY0KQ0KDQoNClNob3VsZCBJIGJlIHdvcnJpZWQgdGhlIGRpc2sgaXMgYnJva2Vu
ID8gLi4uIHRoZSBmaWxlc3lzdGVtIHRoYXQgd2FzIHByZXZlb3VzbHkgdGhlcmUNCi4uLiBz
ZWVtZWQgdG8gYmUgYWxyaWdodCAuLi4gPz8NCg0K

From owner-linux-xfs@oss.sgi.com Mon Nov 20 07:29:54 2000
Received:  by oss.sgi.com id <S553851AbQKTP3o>;
	Mon, 20 Nov 2000 07:29:44 -0800
Received: from pluto.prosalg.no ([213.236.139.11]:35700 "EHLO pluto.prosalg.no")
	by oss.sgi.com with ESMTP id <S553848AbQKTP3c>;
	Mon, 20 Nov 2000 07:29:32 -0800
Received: from prosalg.no (janus.prosalg.no [213.236.139.1])
	by pluto.prosalg.no (8.8.7/8.8.5) with ESMTP id QAA03170
	for <linux-xfs@oss.sgi.com>; Mon, 20 Nov 2000 16:29:29 +0100
Message-ID: <3A1943DB.842BD3AE@prosalg.no>
Date:   Mon, 20 Nov 2000 16:31:39 +0100
From:   Karl Trygve Kalleberg <karltk@prosalg.no>
Organization: Prosalg AS
X-Mailer: Mozilla 4.75 [en] (X11; U; Linux 2.4.0-XFS-test10 i686)
X-Accept-Language: no, en
MIME-Version: 1.0
To:     linux-xfs@oss.sgi.com
Subject: Hang in getdents
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 run today's CVS snapshot (three hours ago), but the problem I'm
experiencing has been with me as long as I've run XFS (about three
weeks).

My XFS filesystem:
/dev/hdc1             45030088  36350920   8679168  81% /mnt/guest

Sometimes, doing various operations on the file system leads to a freeze
which takes a *long time* to thaw. Usually a few hours(!).

After doing some stracing, I've found that the problem seems to be with
getdents(). I've not managed to correlate it to the number of files in
the directory, nor to the directory's depth in the directory tree.

The freeze seems to be bound to the particular directory: if one command
calling getdents() on a directory freezes, so will others when calling
getdents() for the same directory. Calling getdents() for sister or
parent directories works (ie, doesn't freeze).

I've not attempted calling getdents() for a child-directory of a frozen
directory.

I'm running this on an x86 SMP box; I've not seen any advisory about xfs
not being smp-safe. The kernel was built with gcc 2.95.2, which
according to the FAQ might be a problem.

If you don't manage to reproduce the problem, I'd be willing to rebuild
the kernel with egcs 2.91.66 just to eliminate that possibility.

Regards,

Karl T



From owner-linux-xfs@oss.sgi.com Mon Nov 20 08:15:15 2000
Received:  by oss.sgi.com id <S553686AbQKTQPF>;
	Mon, 20 Nov 2000 08:15:05 -0800
Received: from pneumatic-tube.sgi.com ([204.94.214.22]:45061 "EHLO
        pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP
	id <S553647AbQKTQO5>; Mon, 20 Nov 2000 08:14:57 -0800
Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id IAA04283
	for <linux-xfs@oss.sgi.com>; Mon, 20 Nov 2000 08:22:49 -0800 (PST)
	mail_from (lord@jen.americas.sgi.com)
Received: from thistle-e185.americas.sgi.com (thistle-e185.americas.sgi.com [128.162.185.204]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id KAA7695643; Mon, 20 Nov 2000 10:13:39 -0600 (CST)
Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.184.86]) by thistle-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id KAA15805; Mon, 20 Nov 2000 10:13:39 -0600 (CST)
Received: from jen.americas.sgi.com (lord@localhost)
	by jen.americas.sgi.com (8.9.3/8.9.3) with ESMTP id KAA15127;
	Mon, 20 Nov 2000 10:07:00 -0600
Message-Id: <200011201607.KAA15127@jen.americas.sgi.com>
X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4
To:     Karl Trygve Kalleberg <karltk@prosalg.no>
cc:     linux-xfs@oss.sgi.com
Subject: Re: Hang in getdents 
In-Reply-To: Message from Karl Trygve Kalleberg <karltk@prosalg.no> 
   of "Mon, 20 Nov 2000 16:31:39 +0100." <3A1943DB.842BD3AE@prosalg.no> 
Date:   Mon, 20 Nov 2000 10:07:00 -0600
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 run today's CVS snapshot (three hours ago), but the problem I'm
> experiencing has been with me as long as I've run XFS (about three
> weeks).
> 
> My XFS filesystem:
> /dev/hdc1             45030088  36350920   8679168  81% /mnt/guest
> 
> Sometimes, doing various operations on the file system leads to a freeze
> which takes a *long time* to thaw. Usually a few hours(!).
> 
> After doing some stracing, I've found that the problem seems to be with
> getdents(). I've not managed to correlate it to the number of files in
> the directory, nor to the directory's depth in the directory tree.
> 
> The freeze seems to be bound to the particular directory: if one command
> calling getdents() on a directory freezes, so will others when calling
> getdents() for the same directory. Calling getdents() for sister or
> parent directories works (ie, doesn't freeze).
> 
> I've not attempted calling getdents() for a child-directory of a frozen
> directory.
> 
> I'm running this on an x86 SMP box; I've not seen any advisory about xfs
> not being smp-safe. The kernel was built with gcc 2.95.2, which
> according to the FAQ might be a problem.
> 
> If you don't manage to reproduce the problem, I'd be willing to rebuild
> the kernel with egcs 2.91.66 just to eliminate that possibility.
> 
> Regards,
> 
> Karl T
> 

Can you tell us which user space you are using? Different versions of glibc
use different mechanisms to call getdents - including doing lseek backwards
in some cases. Can you confirm that it is one single getdents call which
hangs?

You say this is not a permanent hang which is odd, I would not expect a hang
to be something which recovers - unless you have a failing drive - do
you get any console messages out during this time?

Did you build the filesystem from scratch on linux? Or did it come over
from an Irix system?

You say hang - is this a hang which is consuming cpu time (i.e. a loop
in the kernel), or is it just a hung process. The symptoms you describe 
about other getdents calls locking is not surprising - xfs is probably
stuck somewhere holding a lock on an inode. Any other thread attempting
to access this inode will get stuck too.

I would like to see what happens if you rebuild with the other compiler,
there are too many variables in here for us to attempt to replicate the
problem - short of us getting a binary copy of the disk image!

One other thing you could do is dump out the directory contents using
xfs_db.

do an ls -ld in the parent directory of the inode to get its number:

ls -lid .
33602412 drwxr-xr-x    2 root     bin         40960 Nov  8 16:15 .

run xfs_db on the filesystem (the -r is read only, you do not need to
unmount):

xfs_db -r /dev/xxxx

use the inode command to get to the inode in question:
hung.

xfs_db: inode 33602412

print the inode:

xfs_db: print
core.magic = 0x494e
core.mode = 040755
core.version = 1
core.format = 3 (btree)
core.nlinkv1 = 2
core.uid = 0
core.gid = 1
core.atime.sec = Mon Nov 20 15:38:55 2000
core.atime.nsec = 849055000
core.mtime.sec = Wed Nov  8 16:15:06 2000
core.mtime.nsec = 398148000
core.ctime.sec = Wed Nov  8 16:15:06 2000
core.ctime.nsec = 398148000
core.size = 40960
core.nblocks = 17
core.extsize = 0
core.nextents = 15
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.bmbt.level = 1
u.bmbt.numrecs = 1
u.bmbt.keys[1] = [startoff] 1:[0]
u.bmbt.ptrs[1] = 1:2111173

You probably have a format similar to this - the end of the entry will look
different depending on the directory format. This is a large directory where
the actual entries are stored in other blocks. We can walk into the directory
structure using the addr command:

xfs_db: addr u.bmbt.ptrs[1]
xfs_db: print
magic = 0x424d4150
level = 0
numrecs = 15
leftsib = null
rightsib = null
recs[1-15] = [startoff,startblock,blockcount,extentflag] 1:[0,2102062,1,0] 2:[1,2103642,1,0] 3:[2,2104887,1,0] 4:[3,2106922,1,0] 5:[4,2107330,1,0] 6:[5,2110551,1,0] 7:[6,2114424,1,0] 8:[7,2117505,1,0] 9:[8,2122696,1,0] 10:[9,2138354,1,0] 11:[8388608,2102687,1,0] 12:[8388609,2106916,2,0] 13:[8388611,2111172,1,0] 14:[8388612,2112648,1,0] 15:[16777216,2106915,1,0]


In this case we have a tree with 15 leaf blocks in it, you can walk into the 
leaf blocks by passing the startblock number for each record to the fsblock
commands:

xfs_db: fsblock 2102062

We now have to tell xfs_db what type this is:

xfs_db: type dir2

and we can print it:

xfs_db: print
dhdr.magic = 0x58443244
dhdr.bestfree[0].offset = 0xff8
dhdr.bestfree[0].length = 0x8
dhdr.bestfree[1].offset = 0
dhdr.bestfree[1].length = 0
dhdr.bestfree[2].offset = 0
dhdr.bestfree[2].length = 0
du[0].inumber = 33602412
du[0].namelen = 1
du[0].name = "."
du[0].tag = 0x10
du[1].inumber = 128
du[1].namelen = 2
du[1].name = ".."
du[1].tag = 0x20
du[2].inumber = 33602413
du[2].namelen = 3
du[2].name = "X11"
du[2].tag = 0x30
...
du[187].inumber = 33644452
du[187].namelen = 2
du[187].name = "ee"
du[187].tag = 0xfe8
du[188].freetag = 0xffff
du[188].length = 0x8
du[188].tag = 0xff8

This would need repeating for each block list.

Note that you can record all of this to a file using

log start filename

commands to log

log stop

You could then send us the output.

Steve



From owner-linux-xfs@oss.sgi.com Mon Nov 20 09:28:15 2000
Received:  by oss.sgi.com id <S553665AbQKTR14>;
	Mon, 20 Nov 2000 09:27:56 -0800
Received: from pneumatic-tube.sgi.com ([204.94.214.22]:57614 "EHLO
        pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP
	id <S553659AbQKTR1d>; Mon, 20 Nov 2000 09:27:33 -0800
Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id JAA05161
	for <linux-xfs@oss.sgi.com>; Mon, 20 Nov 2000 09:35:24 -0800 (PST)
	mail_from (cattelan@thebarn.com)
Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id LAA7658085; Mon, 20 Nov 2000 11:26:14 -0600 (CST)
Received: from gibble.americas.sgi.com (gibble.americas.sgi.com [128.162.195.80]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id LAA27698; Mon, 20 Nov 2000 11:26:14 -0600 (CST)
Received: from thebarn.com (localhost [127.0.0.1])
	by gibble.americas.sgi.com (8.11.0/8.10.1) with ESMTP id eAKHQEP21787;
	Mon, 20 Nov 2000 11:26:14 -0600
Message-ID: <3A195EB6.27CD03B8@thebarn.com>
Date:   Mon, 20 Nov 2000 11:26:14 -0600
From:   Russell Cattelan <cattelan@thebarn.com>
X-Mailer: Mozilla 4.75 [en] (X11; U; Linux 2.4.0-XFS_BETA_3smp i686)
X-Accept-Language: en
MIME-Version: 1.0
To:     kris buggenhout <gast6@vum.be>
CC:     linux-xfs@oss.sgi.com
Subject: Re: XFS on sparc 64
References: <200011162105.PAA21883@jen.americas.sgi.com> <3A14F45E.A844533C@vum.be> <3A1548CA.71E44765@thebarn.com> <3A18EEDD.A313D46D@vum.be>
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

kris buggenhout wrote:

> Russell Cattelan wrote:
>
> > >
> > > I was filling the filesystem with an ftp client, just plain mget 6Gbytes,
> > > got to +1 Gig of data,... then i get a write error ... and the fs hangs ... cant
> > > umount ... -> no shutdown possible -> hard reset !
> > >
> > > then trying to get it repaired :
> > >
> > > [root@winnetou /home]# xfs_repair /dev/sde
> > > xfs_repair: warning - cannot set blocksize on block device /dev/sde: Invalid
> > > argument
> > > Phase 1 - find and verify superblock...
> > > Phase 2 - using internal log
> > >         - zero log...
> > >         - scan filesystem freespace and inode maps...
> > > freeblk count 2 != flcount -2048 in ag 0
> > > bad agbno 4294965248 for btbno root, agno 0
> > > bad agbno 531244720 for btbcnt root, agno 0
> > >         - found root inode chunk
> > > Phase 3 - for each AG...
> > >         - scan and clear agi unlinked lists...
> > >         - process known inodes and perform inode discovery...
> > >         - agno = 0
> > > Bus error (core dumped)
> >
> > This looks consistent with the problem we are working on right now.
> >
> > When the file system gets close to being filled it runs around finding all the
> > small left over extents. At some point one of the writes goes to far and scribbles
> > over
> > the the ag structures. We are getting close to resolving the bug... give us a day
> > or
> > so.
> >
> > The core dump on the repair is not a good thing although... do you have a stack
> > trace?
>
> not anymore ...
>
> but I checked out this morning the cvs .. and did a reduild ... it all compiled
> clean...
>
> but now I have a worse problem ... if I try to write data : input/output error ...
> umount and xfs_repair do work now ... but I cant write a bit of data , can create
> directories ok ... but cant write data
>
> [root@winnetou /xfs_filesys]# echo 1 > tttt
> [root@winnetou /xfs_filesys]# cat tttt
> cat: tttt: Input/output error
>
> Start mounting filesystem: sd(8,64)
> Ending clean XFS mount for filesystem: sd(8,64)
> I/O Error Detected.  Shutting down filesystem: sd(8,64)
> Please umount the filesystem, and rectify the problem(s)
> PCD: pagebuf_bmap error -1010 pb_flags 0x10010002
> Start mounting filesystem: sd(8,64)
> Ending clean XFS mount for filesystem: sd(8,64)
>
> Should I be worried the disk is broken ? ... the filesystem that was preveously there
> ... seemed to be alright ... ??

Unclear.
Do you see any error messages on the console from the disk driver?

If xfs_repair runs without reporting IO errors then it probably isn't a disk problem.
Assuming xfs_repair cleaned up the FS, does xfs_check run without errors?

That pagebuf_bmap error does seem to indicate some problem.
It this file system really close to being full?

-Russell




From owner-linux-xfs@oss.sgi.com Mon Nov 20 12:04:56 2000
Received:  by oss.sgi.com id <S553672AbQKTUEg>;
	Mon, 20 Nov 2000 12:04:36 -0800
Received: from deliverator.sgi.com ([204.94.214.10]:35967 "EHLO
        deliverator.sgi.com") by oss.sgi.com with ESMTP id <S553667AbQKTUEa>;
	Mon, 20 Nov 2000 12:04:30 -0800
Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id LAA26747
	for <linux-xfs@oss.sgi.com>; Mon, 20 Nov 2000 11:56:37 -0800 (PST)
	mail_from (lord@jen.americas.sgi.com)
Received: from thistle-e185.americas.sgi.com (thistle-e185.americas.sgi.com [128.162.185.204]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id OAA7680821 for <linux-xfs@oss.sgi.com>; Mon, 20 Nov 2000 14:03:13 -0600 (CST)
Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.184.86]) by thistle-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id OAA49556 for <linux-xfs@oss.sgi.com>; Mon, 20 Nov 2000 14:03:13 -0600 (CST)
Received: (from lord@localhost)
	by jen.americas.sgi.com (8.9.3/8.9.3) id NAA19353
	for linux-xfs@oss.sgi.com; Mon, 20 Nov 2000 13:56:33 -0600
Date:   Mon, 20 Nov 2000 13:56:33 -0600
From:   Steve Lord <lord@sgi.com>
Message-Id: <200011201956.NAA19353@jen.americas.sgi.com>
Subject: TAKE - more corruption fixes
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

This is a workaround for the full filesystem corruption by turning off
a code path which decides to convert an extent in place during a write
call.

Date:  Mon Nov 20 12:00:31 PST 2000
Workarea:  jen.americas.sgi.com:/src/lord/xfs-linux.2.4

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


Modid:  2.4.x-xfs:slinx:78571a
linux/fs/pagebuf/page_buf_io.c - 1.35
	- Turn off the call to __pb_write_or_convert_bmap in __pb_block_commit_write_async
	  as this was converting a delalloc extent to a smaller real extent in the
	  full (or fragmented) disk case and not taking account of the smaller size.
	  This tended to lead to walking off the end of an extent when assigning
	  block numbers to pages. The real fix would be to rewrite the code to cope
	  with arrays of extents rather than processing them one at a time.



From owner-linux-xfs@oss.sgi.com Mon Nov 20 14:56:48 2000
Received:  by oss.sgi.com id <S553690AbQKTW42>;
	Mon, 20 Nov 2000 14:56:28 -0800
Received: from deliverator.sgi.com ([204.94.214.10]:48444 "EHLO
        deliverator.sgi.com") by oss.sgi.com with ESMTP id <S553673AbQKTWzz>;
	Mon, 20 Nov 2000 14:55:55 -0800
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 OAA25612; Mon, 20 Nov 2000 14:48:02 -0800 (PST)
	mail_from (nobody@info.engr.sgi.com)
Received: (from nobody@localhost)
	by info.engr.sgi.com (SGI-8.9.3/8.9.3) id OAA33319;
	Mon, 20 Nov 2000 14:55:54 -0800 (PST)
Date:   Mon, 20 Nov 2000 14:55:54 -0800 (PST)
Message-Id: <200011202255.OAA33319@info.engr.sgi.com>
X-Pv-Incident: 808315 
webPV:  gibble.americas.sgi.com 
webExec: webpvsubmit,PvProjectIncident 
Reply-To: sgi.bugs.xfs@fido.engr.sgi.com
From:   pv@relay.sgi.com (cattelan@engr.sgi.com)
Subject: BUG 808315 - Full file systems can become corrupted with XFS Linux.
To:     nb@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=808315

Submitter : cattelan                  Submitter Domain : engr               
Assigned Engineer : nb                Assigned Domain : sgi.com             
Assigned Group : xfs-linux            Category : software                   
Customer Reported : T                 Priority : 2                          
Project : xfs-linux                   Status : open                         
Description :
Linux XFS may corrupt file system when disk si filled.

Very large write requests causes portions of the user data IO path
to continue writing beyond the end of an allocted extent thus over-writting
the start of the next AG. 

This usally show up as trashed secondary super blocks and probably
other data structures in the AG.

From owner-linux-xfs@oss.sgi.com Mon Nov 20 15:18:18 2000
Received:  by oss.sgi.com id <S553698AbQKTXR5>;
	Mon, 20 Nov 2000 15:17:57 -0800
Received: from deliverator.sgi.com ([204.94.214.10]:26954 "EHLO
        deliverator.sgi.com") by oss.sgi.com with ESMTP id <S553683AbQKTXRq>;
	Mon, 20 Nov 2000 15:17:46 -0800
Received: from nodin.corp.sgi.com (nodin.corp.sgi.com [192.26.51.193]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id PAA03956
	for <linux-xfs@oss.sgi.com>; Mon, 20 Nov 2000 15:09:52 -0800 (PST)
	mail_from (chait@getafix.engr.sgi.com)
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 PAA12733 for <linux-xfs@oss.sgi.com>; Mon, 20 Nov 2000 15:17:14 -0800 (PST)
Received: from getafix.engr.sgi.com (IDENT:root@getafix.engr.sgi.com [163.154.5.110])
	by cthulhu.engr.sgi.com (SGI-8.9.3/8.9.3) with ESMTP id PAA83752;
	Mon, 20 Nov 2000 15:14:39 -0800 (PST)
Received: from getafix.engr.sgi.com (IDENT:chait@localhost.localdomain [127.0.0.1])
	by getafix.engr.sgi.com (8.9.3/8.9.3) with ESMTP id PAA32230;
	Mon, 20 Nov 2000 15:13:48 -0500
Message-Id: <200011202013.PAA32230@getafix.engr.sgi.com>
To:     Marcelo Tosatti <marcelo@conectiva.com.br>
Cc:     linux-xfs@oss.sgi.com, axboe@suse.de, mkp@linuxcare.com,
        chait@sgi.com
Subject: Re: [RFC] split kiobuf/buffer-head IO code Re: xfs file system 
In-reply-to: Your message of "Sun, 19 Nov 2000 17:24:57 -0200."
             <Pine.LNX.4.21.0011191547530.5667-100000@freak.distro.conectiva> 
Date:   Mon, 20 Nov 2000 15:13:48 -0500
From:   Chaitanya Tumuluri <chait@getafix.engr.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 Sun, 19 Nov 2000 17:24:57 -0200, Marcelo Tosatti <marcelo@conectiva.com.br> wrote:
   >
   >Chait, Jens, Martin, 
   >
Hi Marcelo,

Seeing as how no-one's replied as yet; lemme take a quick stab at a response.

   >Currently, generic_make_request() function and the per request queue
   >make_request_fn() operation implement buffer-head and kiobuf based IO.
   >
   >IMHO the block layer should handle different IO "methods" (kiobuf and
   >buffer-head) with different code.
   >

That was the way it was originally implemented in the test1 thro' test5 XFS trees
	with: 	ll_rw_kio() calling __make_kio_request()
	a la:   ll_rw_block() calling __make_request()
Then things changed from test8 on, where generic_make_request() was introduced to
accomodate stackable drivers, which broke things severely for the kiobuf I/O path.

   >This way the code gets cleaner, more simple, and independant from
   >each other.

Yes, that was the original intent of the separate codepaths. However, there were
three comments made (by Alan Cox, Eric Youngdale, Stephen Tweedie among others), 
when I had originally submitted the kiobuf I/O patch to the kernel mailing lists:

	1. develop code only as a prototype/proof-of-concept for the 2.4 timeframe,
	2. reuse code as far as possible,
	3. keep the footprint of the changes small (for 2.4).

Thus, I'd agree with your suggestions below for the 2.5 timeframe. Can it wait
till then, or do you see a need for it in the RAID implementation? As for LVM, 
I think it'd be a fairly simple to rework the 2.4 code for the 2.5 kernel when
the split in the codepaths becomes more apparent. mkp/axboe ?

   >Right now, I think the following should be done: 
   >
   >- split request_queue_t->make_request_fn into kio_make_request_fn and
   >bh_make_request_fn.
   >
   >- Add a flag to be passed in blk_init_queue to inform if the caller
   >supports kiobuf based IO.  If the flag is on, set req->kio_make_request_fn
   >to __kio_make_request.

This would certainly entail touching/modifying a whole bunch of drivers in the
kernel source (since you are changing an API). See 3. above.

   >- split __make_request into ll_kio_make_request and ll_bh_make_request (or
   >whatever better name for the functions).

This results in fairly large amounts of code duplication, especially when the
kiobuf-I/O code path starts to do request merging in the elevator. See 2. above.

To the extent possible, the current implementation tries to reuse code common to
the bh and kiobuf codepath. It deviates only in initializing:
		* req->buffer, req->current_nr_sectors, req->nr_segments
		* req->kiobuf, req->bh, req->bhtail
via two separate functions:	__blk_init_req_kio() and __blk_init_req_bh()

So, in a sense, this separation is there already.

   >- split generic_make_request into kio_make_request and bh_make_request.
   >ll_rw_block should use bh_make_request and ll_rw_kio should use
   >kio_make_request.
   >
   >This way, LVM and RAID should have their own kio_make_request and
   >bh_make_request separate functions.

With your changes above, the LVM/RAID codepath is *forced* to make the separation,
while the current codepath doesn't preclude LVM/RAID from having these separate 
functions, but doesn't _require_ the separation either. For now, I think its 
better to keep the options open, no?

   >Comments? 
   >
   >I'm working on RAID1 code. I'm running dbench on a kiobuf mounted XFS
   >filesystem over a raid1 array with 2 SCSI partitions for some time now
   >(the code is not complete yet, though, and I want to solve the issue
   >discussed above).

Cool! How is it working out?

Cheers,
-Chait.

From owner-linux-xfs@oss.sgi.com Mon Nov 20 15:21:47 2000
Received:  by oss.sgi.com id <S553702AbQKTXV2>;
	Mon, 20 Nov 2000 15:21:28 -0800
Received: from deliverator.sgi.com ([204.94.214.10]:34379 "EHLO
        deliverator.sgi.com") by oss.sgi.com with ESMTP id <S553694AbQKTXVP>;
	Mon, 20 Nov 2000 15:21:15 -0800
Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id PAA04498
	for <linux-xfs@oss.sgi.com>; Mon, 20 Nov 2000 15:13:23 -0800 (PST)
	mail_from (cattelan@gibble.americas.sgi.com)
Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id RAA7685306 for <linux-xfs@oss.sgi.com>; Mon, 20 Nov 2000 17:19:59 -0600 (CST)
Received: from gibble.americas.sgi.com (gibble.americas.sgi.com [128.162.195.80]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id RAA28964 for <linux-xfs@oss.sgi.com>; Mon, 20 Nov 2000 17:19:58 -0600 (CST)
Received: (from cattelan@localhost)
	by gibble.americas.sgi.com (8.11.0/8.10.1) id eAKNJxi25542
	for linux-xfs@oss.sgi.com; Mon, 20 Nov 2000 17:19:59 -0600
Date:   Mon, 20 Nov 2000 17:19:59 -0600
From:   Russell Cattelan <cattelan@sgi.com>
Message-Id: <200011202319.eAKNJxi25542@gibble.americas.sgi.com>
Subject: PARTIAL TAKE - 808315
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

Date:  Mon Nov 20 15:17:15 PST 2000
Workarea:  gibble.americas.sgi.com:/export/extra/x2.4-xfs-beta
Author:  lord
Merged by:  cattelan
Merged mods:  2.4.x-xfs:slinx:78571a

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


Modid:  2.4.x-xfs-beta:slinx:78571a
linux/fs/pagebuf/page_buf_io.c - 1.30
	- Merge of 2.4.x-xfs:slinx:78571a by cattelan.
	  Turn off the call to __pb_write_or_convert_bmap in __pb_block_commit_write_async
	  as this was converting a delalloc extent to a smaller real extent in the
	  full (or fragmented) disk case and not taking account of the smaller size.
	  This tended to lead to walking off the end of an extent when assigning
	  block numbers to pages. The real fix would be to rewrite the code to cope
	  with arrays of extents rather than processing them one at a time.



From owner-linux-xfs@oss.sgi.com Mon Nov 20 15:30:47 2000
Received:  by oss.sgi.com id <S553715AbQKTXa1>;
	Mon, 20 Nov 2000 15:30:27 -0800
Received: from perninha.conectiva.com.br ([200.250.58.156]:44298 "EHLO
        perninha.conectiva.com.br") by oss.sgi.com with ESMTP
	id <S553708AbQKTXaM>; Mon, 20 Nov 2000 15:30:12 -0800
Received: from freak.distro.conectiva (freak.distro.conectiva [10.0.17.22])
	by perninha.conectiva.com.br (8.9.3/8.9.3) with ESMTP id VAA25587;
	Mon, 20 Nov 2000 21:29:51 -0200
Date:   Mon, 20 Nov 2000 21:29:25 -0200 (BRST)
From:   Marcelo Tosatti <marcelo@conectiva.com.br>
X-Sender: marcelo@freak.distro.conectiva
To:     Chaitanya Tumuluri <chait@getafix.engr.sgi.com>
cc:     linux-xfs@oss.sgi.com, axboe@suse.de, mkp@linuxcare.com,
        chait@sgi.com
Subject: Re: [RFC] split kiobuf/buffer-head IO code Re: xfs file system 
In-Reply-To: <200011202013.PAA32230@getafix.engr.sgi.com>
Message-ID: <Pine.LNX.4.21.0011202120270.6397-100000@freak.distro.conectiva>
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, 20 Nov 2000, Chaitanya Tumuluri wrote:

> 
> On Sun, 19 Nov 2000 17:24:57 -0200, Marcelo Tosatti <marcelo@conectiva.com.br> wrote:
>    >
>    >Chait, Jens, Martin, 
>    >
> Hi Marcelo,
> 
> Seeing as how no-one's replied as yet; lemme take a quick stab at a response.
> 
>    >Currently, generic_make_request() function and the per request queue
>    >make_request_fn() operation implement buffer-head and kiobuf based IO.
>    >
>    >IMHO the block layer should handle different IO "methods" (kiobuf and
>    >buffer-head) with different code.
>    >
> 
> That was the way it was originally implemented in the test1 thro' test5 XFS trees
> 	with: 	ll_rw_kio() calling __make_kio_request()
> 	a la:   ll_rw_block() calling __make_request()
> Then things changed from test8 on, where generic_make_request() was introduced to
> accomodate stackable drivers, which broke things severely for the kiobuf I/O path.
> 
>    >This way the code gets cleaner, more simple, and independant from
>    >each other.
> 
> Yes, that was the original intent of the separate codepaths. However, there were
> three comments made (by Alan Cox, Eric Youngdale, Stephen Tweedie among others), 
> when I had originally submitted the kiobuf I/O patch to the kernel mailing lists:
> 
> 	1. develop code only as a prototype/proof-of-concept for the 2.4 timeframe,
> 	2. reuse code as far as possible,
> 	3. keep the footprint of the changes small (for 2.4).
> 
> Thus, I'd agree with your suggestions below for the 2.5 timeframe. Can it wait
> till then, or do you see a need for it in the RAID implementation? 

No, its not needed. 

Currently I'm doing raid1_make_request() in a easy way to port it to when
we have the codepath separation: 

static int bh_raid1_make_request(mddev_t *mddev, int rw, struct buffer_head *bh ...)

and

static int kio_raid1_make_request(mddev_t *mddev, int rw, struct kiobuf *kiobuf...)


The main raid1_make_request is basically this: 

        if(bh)
                return bh_raid1_make_request(mddev, rw, bh, dev, sector, count, r1_bh);
        else if (kiobuf)
		return kio_raid1_make_request(mddev, rw, kiobuf, dev, sector, count, r1_bh);
      
> As for LVM, I think it'd be a fairly simple to rework the 2.4 code for
> the 2.5 kernel when the split in the codepaths becomes more apparent.
> mkp/axboe ?
> 
>    >Right now, I think the following should be done: 
>    >
>    >- split request_queue_t->make_request_fn into kio_make_request_fn and
>    >bh_make_request_fn.
>    >
>    >- Add a flag to be passed in blk_init_queue to inform if the caller
>    >supports kiobuf based IO.  If the flag is on, set req->kio_make_request_fn
>    >to __kio_make_request.
> 
> This would certainly entail touching/modifying a whole bunch of drivers in the
> kernel source (since you are changing an API). See 3. above.
> 
>    >- split __make_request into ll_kio_make_request and ll_bh_make_request (or
>    >whatever better name for the functions).
> 
> This results in fairly large amounts of code duplication, especially when the
> kiobuf-I/O code path starts to do request merging in the elevator. See 2. above.

Are you sure the elevator code for kiobuf and buffer heads will be the
same ?

> To the extent possible, the current implementation tries to reuse code common to
> the bh and kiobuf codepath. It deviates only in initializing:
> 		* req->buffer, req->current_nr_sectors, req->nr_segments
> 		* req->kiobuf, req->bh, req->bhtail
> via two separate functions:	__blk_init_req_kio() and __blk_init_req_bh()
> 
> So, in a sense, this separation is there already.
> 
>    >- split generic_make_request into kio_make_request and bh_make_request.
>    >ll_rw_block should use bh_make_request and ll_rw_kio should use
>    >kio_make_request.
>    >
>    >This way, LVM and RAID should have their own kio_make_request and
>    >bh_make_request separate functions.
> 
> With your changes above, the LVM/RAID codepath is *forced* to make the separation,
> while the current codepath doesn't preclude LVM/RAID from having these separate 
> functions, but doesn't _require_ the separation either. For now, I think its 
> better to keep the options open, no?

The reason I want to force codepath separation in SGI XFS tree is to make
it ready for 2.5 merge without pain.  

>    >Comments? 
>    >
>    >I'm working on RAID1 code. I'm running dbench on a kiobuf mounted XFS
>    >filesystem over a raid1 array with 2 SCSI partitions for some time now
>    >(the code is not complete yet, though, and I want to solve the issue
>    >discussed above).
> 
> Cool! How is it working out?

Working perfectly except when reconstruction is going on. 

hopefully I'll the bug tomorrow.


From owner-linux-xfs@oss.sgi.com Mon Nov 20 16:10:48 2000
Received:  by oss.sgi.com id <S553714AbQKUAKi>;
	Mon, 20 Nov 2000 16:10:38 -0800
Received: from deliverator.sgi.com ([204.94.214.10]:10332 "EHLO
        deliverator.sgi.com") by oss.sgi.com with ESMTP id <S553700AbQKUAKW>;
	Mon, 20 Nov 2000 16:10:22 -0800
Received: from nodin.corp.sgi.com (nodin.corp.sgi.com [192.26.51.193]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id QAA13277
	for <linux-xfs@oss.sgi.com>; Mon, 20 Nov 2000 16:02:25 -0800 (PST)
	mail_from (chait@getafix.engr.sgi.com)
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 QAA35304 for <linux-xfs@oss.sgi.com>; Mon, 20 Nov 2000 16:08:32 -0800 (PST)
Received: from getafix.engr.sgi.com (IDENT:root@getafix.engr.sgi.com [163.154.5.110])
	by cthulhu.engr.sgi.com (SGI-8.9.3/8.9.3) with ESMTP id QAA99325;
	Mon, 20 Nov 2000 16:05:56 -0800 (PST)
Received: from getafix.engr.sgi.com (IDENT:chait@localhost.localdomain [127.0.0.1])
	by getafix.engr.sgi.com (8.9.3/8.9.3) with ESMTP id QAA32648;
	Mon, 20 Nov 2000 16:05:10 -0500
Message-Id: <200011202105.QAA32648@getafix.engr.sgi.com>
To:     Marcelo Tosatti <marcelo@conectiva.com.br>
Cc:     linux-xfs@oss.sgi.com, axboe@suse.de, mkp@linuxcare.com
Subject: Re: [RFC] split kiobuf/buffer-head IO code Re: xfs file system 
In-reply-to: Your message of "Mon, 20 Nov 2000 21:29:25 -0200."
             <Pine.LNX.4.21.0011202120270.6397-100000@freak.distro.conectiva> 
Date:   Mon, 20 Nov 2000 16:05:10 -0500
From:   Chaitanya Tumuluri <chait@getafix.engr.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, 20 Nov 2000 21:29:25 -0200, Marcelo Tosatti <marcelo@conectiva.com.br> wrote:
   >On Mon, 20 Nov 2000, Chaitanya Tumuluri wrote:
   >
   >> 
   >> On Sun, 19 Nov 2000 17:24:57 -0200, Marcelo Tosatti <marcelo@conectiva.com.br> wrot
   >>e:
   >> 
   >> Thus, I'd agree with your suggestions below for the 2.5 timeframe. Can it wait
   >> till then, or do you see a need for it in the RAID implementation? 
   >
   >No, its not needed. 
   >
   >Currently I'm doing raid1_make_request() in a easy way to port it to when
   >we have the codepath separation: 
   >
   >	< Stuff Deleted >
   >
Sweet! That should work.

   >> This results in fairly large amounts of code duplication, especially when the
   >> kiobuf-I/O code path starts to do request merging in the elevator. See 2. above.
   >
   >Are you sure the elevator code for kiobuf and buffer heads will be the
   >same ?

No, not the same. But sufficiently similar that we should think in terms of code reuse
and reducing the footprint of the changes needed.

   >> With your changes above, the LVM/RAID codepath is *forced* to make the separation,
   >> while the current codepath doesn't preclude LVM/RAID from having these separate 
   >> functions, but doesn't _require_ the separation either. For now, I think its 
   >> better to keep the options open, no?
   >
   >The reason I want to force codepath separation in SGI XFS tree is to make
   >it ready for 2.5 merge without pain.  
   >

The other reason (they seem to multiply with every email!) I don't want to make too
many changes currently, is that Eric Youngdale is thinking in terms of a major rewrite
to the block-queueing layer (including getting rid of the old scsi error-handling code
and the drivers that break with it!). So, perhaps, we should revisit this discussion 
when 2.5 does open up and then rework the queueing layer as you suggest along with everyone
else that wants to improve it! :^)
 
Cheers,
-Chait.

From owner-linux-xfs@oss.sgi.com Mon Nov 20 16:31:38 2000
Received:  by oss.sgi.com id <S553717AbQKUAb2>;
	Mon, 20 Nov 2000 16:31:28 -0800
Received: from pneumatic-tube.sgi.com ([204.94.214.22]:38732 "EHLO
        pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP
	id <S553712AbQKUAbG>; Mon, 20 Nov 2000 16:31:06 -0800
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 QAA00875; Mon, 20 Nov 2000 16:38:58 -0800 (PST)
	mail_from (nobody@info.engr.sgi.com)
Received: (from nobody@localhost)
	by info.engr.sgi.com (SGI-8.9.3/8.9.3) id QAA50158;
	Mon, 20 Nov 2000 16:31:04 -0800 (PST)
Date:   Mon, 20 Nov 2000 16:31:04 -0800 (PST)
Message-Id: <200011210031.QAA50158@info.engr.sgi.com>
X-Pv-Incident: 808328 
webPV:  proxy2.melbourne.sgi.com 
webExec: webpvsubmit,PvProjectIncident 
Reply-To: sgi.bugs.xfs@fido.engr.sgi.com
From:   pv@relay.sgi.com (dxm@engr.sgi.com)
Subject: BUG 808328 - xfs_support EXPORTs symbols with generic names
To:     dxm@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=808328

Submitter : dxm                       Submitter Domain : engr               
Assigned Engineer : dxm               Assigned Domain : engr                
Assigned Group : xfs-linux            Category : software                   
Customer Reported : F                 Priority : 4                          
Project : xfs-linux                   Status : open                         
Description :
xfs_support uses EXPORT_SYMBOL to export a bunch of symbols
into the kernel global symbol namespace. Some of the symbol
names are quite generic and hence potentially clash with other
exports.

Case in point is "copyin" and "copyout".

we can:
	- move code back into XFS
	- make simple functions static inline
	- prefix symbols and use macro aliasing to avoid
		changing all references to them
	- prefix symbols and change all references

From owner-linux-xfs@oss.sgi.com Mon Nov 20 16:40:17 2000
Received:  by oss.sgi.com id <S553722AbQKUAkI>;
	Mon, 20 Nov 2000 16:40:08 -0800
Received: from deliverator.sgi.com ([204.94.214.10]:31588 "EHLO
        deliverator.sgi.com") by oss.sgi.com with ESMTP id <S553716AbQKUAjp>;
	Mon, 20 Nov 2000 16:39:45 -0800
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 QAA17619; Mon, 20 Nov 2000 16:31:52 -0800 (PST)
	mail_from (nobody@info.engr.sgi.com)
Received: (from nobody@localhost)
	by info.engr.sgi.com (SGI-8.9.3/8.9.3) id QAA48798;
	Mon, 20 Nov 2000 16:39:44 -0800 (PST)
Date:   Mon, 20 Nov 2000 16:39:44 -0800 (PST)
Message-Id: <200011210039.QAA48798@info.engr.sgi.com>
X-Pv-Incident: 808328 
webPV:  proxy2.melbourne.sgi.com 
webExec: webpvupdate,pvincident 
Reply-To: sgi.bugs.xfs@fido.engr.sgi.com
From:   pv@relay.sgi.com (dxm@engr.sgi.com)
Subject: ADD 808328 - xfs_support EXPORTs symbols with generic names
To:     dxm@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=808328

 Status : open                         Priority : 4                         
 Assigned Engineer : dxm               Submitter : dxm                      
*Modified User : dxm                  *Modified User Domain : engr          
*Description :
xfs_support uses EXPORT_SYMBOL to export a bunch of symbols
into the kernel global symbol namespace. Some of the symbol
names are quite generic and hence potentially clash with other
exports.

Case in point is "copyin" and "copyout".

we can:
	- move code back into XFS
	- make simple functions static inline

.....


==========================
ADDITIONAL INFORMATION (ADD)
From: dxm@engr (BugWorks)
Date: Nov 20 2000 04:39:44PM
==========================

PARTIAL TAKE

Date:  Mon Nov 20 16:38:27 PST 2000
Workarea:  sherman.melbourne.sgi.com:/hosts/snort/build1/people/dxm/isms/slinx-xfs

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


Modid:  2.4.x-xfs:slinx:78617a
linux/fs/xfs/support/move.h - 1.2
linux/fs/xfs/support/move.c - 1.2
        - make copyin & copyout inline

From owner-linux-xfs@oss.sgi.com Mon Nov 20 16:55:38 2000
Received:  by oss.sgi.com id <S553735AbQKUAz2>;
	Mon, 20 Nov 2000 16:55:28 -0800
Received: from deliverator.sgi.com ([204.94.214.10]:43369 "EHLO
        deliverator.sgi.com") by oss.sgi.com with ESMTP id <S553724AbQKUAzO>;
	Mon, 20 Nov 2000 16:55:14 -0800
Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id QAA20256
	for <linux-xfs@oss.sgi.com>; Mon, 20 Nov 2000 16:47:21 -0800 (PST)
	mail_from (cattelan@thebarn.com)
Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id SAA7704668; Mon, 20 Nov 2000 18:53:57 -0600 (CST)
Received: from gibble.americas.sgi.com (gibble.americas.sgi.com [128.162.195.80]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id SAA13834; Mon, 20 Nov 2000 18:53:56 -0600 (CST)
Received: from thebarn.com (localhost [127.0.0.1])
	by gibble.americas.sgi.com (8.11.0/8.10.1) with ESMTP id eAL0ruP26077;
	Mon, 20 Nov 2000 18:53:56 -0600
Message-ID: <3A19C7A2.6323D63D@thebarn.com>
Date:   Mon, 20 Nov 2000 18:53:55 -0600
From:   Russell Cattelan <cattelan@thebarn.com>
X-Mailer: Mozilla 4.75 [en] (X11; U; Linux 2.4.0-XFS_BETA_3smp i686)
X-Accept-Language: en
MIME-Version: 1.0
To:     sgi.bugs.xfs@fido.engr.sgi.com
CC:     dxm@engr.sgi.com, linux-xfs@oss.sgi.com
Subject: Re: BUG 808328 - xfs_support EXPORTs symbols with generic names
References: <200011210031.QAA50158@info.engr.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

"dxm@engr.sgi.com" wrote:

> View Incident: http://co-op.engr.sgi.com/BugWorks/code/bwxquery.cgi?search=Search&wlong=1&view_type=Bug&wi=808328
>
> Submitter : dxm                       Submitter Domain : engr
> Assigned Engineer : dxm               Assigned Domain : engr
> Assigned Group : xfs-linux            Category : software
> Customer Reported : F                 Priority : 4
> Project : xfs-linux                   Status : open
> Description :
> xfs_support uses EXPORT_SYMBOL to export a bunch of symbols
> into the kernel global symbol namespace. Some of the symbol
> names are quite generic and hence potentially clash with other
> exports.
>
> Case in point is "copyin" and "copyout".
>
> we can:
>         - move code back into XFS
>         - make simple functions static inline
>         - prefix symbols and use macro aliasing to avoid
>                 changing all references to them

This seems like the easiest.

Actually is there any reason we shouldn't just define copyin -> copy_from_user and
copyout -> copy_to_user?

The functions were probably originally done for debug purposes.

>
>         - prefix symbols and change all references


From owner-linux-xfs@oss.sgi.com Mon Nov 20 16:58:38 2000
Received:  by oss.sgi.com id <S553729AbQKUA6S>;
	Mon, 20 Nov 2000 16:58:18 -0800
Received: from pneumatic-tube.sgi.com ([204.94.214.22]:64079 "EHLO
        pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP
	id <S553739AbQKUA6K>; Mon, 20 Nov 2000 16:58:10 -0800
Received: from nodin.corp.sgi.com (nodin.corp.sgi.com [192.26.51.193]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id RAA04727; Mon, 20 Nov 2000 17:06:02 -0800 (PST)
	mail_from (pv@feature.engr.sgi.com)
Received: from feature.engr.sgi.com (gate-feature.engr.sgi.com [130.62.42.134]) by nodin.corp.sgi.com (980427.SGI.8.8.8/980728.SGI.AUTOCF) via ESMTP id QAA64588; Mon, 20 Nov 2000 16:57:39 -0800 (PST)
Received: (from pv@localhost) by feature.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) id QAA83099; Mon, 20 Nov 2000 16:55:03 -0800 (PST)
Date:   Mon, 20 Nov 2000 16:55:03 -0800 (PST)
Message-Id: <200011210055.QAA83099@feature.engr.sgi.com>
X-Pv-Incident: 808328 
Reply-To: sgi.bugs.xfs@fido.engr.sgi.com
From:   pv@fddi-odin.corp.sgi.com (cattelan@thebarn.com)
Subject: ADD 808328 - xfs_support EXPORTs symbols with generic names
To:     dxm@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

 Submitter : dxm                       Status : open                        
 Assigned Engineer : dxm               Priority : 4                         
*Modified Date : 11/20/00             *Modified User : cattelan             
*Modified User Domain : thebarn.com   *Description :
xfs_support uses EXPORT_SYMBOL to export a bunch of symbols
into the kernel global symbol namespace. Some of the symbol
names are quite generic and hence potentially clash with other
exports.

Case in point is "copyin" and "copyout".

we can:
	- move code back into XFS
	- make simple functions static inline

.....


==========================
ADDITIONAL INFORMATION (ADD)
From: russell cattelan <cattelan@thebarn.com>
Date: Nov 20 2000 04:55:03PM
[pvnews version: 1.71]
==========================
"dxm@engr.sgi.com" wrote:

> View Incident: http://co-op.engr.sgi.com/BugWorks/code/bwxquery.cgi?search=Search&wlong=1&view_type=Bug&wi=808328
>
> Submitter : dxm                       Submitter Domain : engr
> Assigned Engineer : dxm               Assigned Domain : engr
> Assigned Group : xfs-linux            Category : software
> Customer Reported : F                 Priority : 4
> Project : xfs-linux                   Status : open
> Description :
> xfs_support uses EXPORT_SYMBOL to export a bunch of symbols
> into the kernel global symbol namespace. Some of the symbol
> names are quite generic and hence potentially clash with other
> exports.
>
> Case in point is "copyin" and "copyout".
>
> we can:
>         - move code back into XFS
>         - make simple functions static inline
>         - prefix symbols and use macro aliasing to avoid
>                 changing all references to them

This seems like the easiest.

Actually is there any reason we shouldn't just define copyin -> copy_from_user and
copyout -> copy_to_user?

The functions were probably originally done for debug purposes.

>
>         - prefix symbols and change all references

From owner-linux-xfs@oss.sgi.com Mon Nov 20 18:24:57 2000
Received:  by oss.sgi.com id <S553692AbQKUCYr>;
	Mon, 20 Nov 2000 18:24:47 -0800
Received: from tux.mkp.net ([130.225.60.11]:60174 "EHLO tux.mkp.net")
	by oss.sgi.com with ESMTP id <S553657AbQKUCYV>;
	Mon, 20 Nov 2000 18:24:21 -0800
Received: from tux.mkp.net ([130.225.60.11] helo=jaguar.mkp.net)
	by tux.mkp.net with esmtp (Exim 3.14 #2)
	id 13y2x3-0003No-00; Tue, 21 Nov 2000 03:14:29 +0100
Received: (from mkp@localhost)
	by jaguar.mkp.net (8.9.3/8.9.3) id VAA02865;
	Mon, 20 Nov 2000 21:24:16 -0500
X-Authentication-Warning: jaguar.mkp.net: mkp set sender to mkp@mkp.net using -f
To:     kris buggenhout <gast6@vum.be>
Cc:     linux-xfs@oss.sgi.com
Subject: Re: XFS on sparc 64
References: <200011162105.PAA21883@jen.americas.sgi.com>
	<3A14F45E.A844533C@vum.be> <3A1548CA.71E44765@thebarn.com>
	<3A18EEDD.A313D46D@vum.be>
From:   "Martin K. Petersen" <mkp@linuxcare.com>
Organization: Linuxcare, Inc.
Date:   20 Nov 2000 21:24:15 -0500
In-Reply-To: kris buggenhout's message of "Mon, 20 Nov 2000 10:29:01 +0100"
Message-ID: <yq11yw6t640.fsf@jaguar.mkp.net>
Lines:  21
User-Agent: Gnus/5.0807 (Gnus v5.8.7) XEmacs/21.1 (Canyonlands)
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 a note regarding XFS on sparc64.  

We've previously seen file system corruption due to the fact that
there was no way to set the device block size from userland.  I fixed
this some time ago by adding a BLKSETSIZE ioctl.

Linux on UltraSPARC is a bit tricky, however, (32-bit userland on
64-bit kernel) and as it turns out I hadn't added the new ioctl to the
sparc64 argument conversion list.  I just fixed that.

You'll need to recreate your file systems to make sure that everything
is properly aligned.

Please let me know whether this improves things for you.

-- 
Martin K. Petersen, Principal Linux Consultant, Linuxcare, Inc.
mkp@linuxcare.com, http://www.linuxcare.com/
Linuxcare. Moving Forward.


From owner-linux-xfs@oss.sgi.com Tue Nov 21 02:31:48 2000
Received:  by oss.sgi.com id <S553755AbQKUKbi>;
	Tue, 21 Nov 2000 02:31:38 -0800
Received: from deliverator.sgi.com ([204.94.214.10]:12923 "EHLO
        deliverator.sgi.com") by oss.sgi.com with ESMTP id <S553668AbQKUKbW>;
	Tue, 21 Nov 2000 02:31:22 -0800
Received: from feature.engr.sgi.com (gate-feature.engr.sgi.com [130.62.42.134]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id CAA28042; Tue, 21 Nov 2000 02:23:30 -0800 (PST)
	mail_from (pv@feature.engr.sgi.com)
Received: (from pv@localhost) by feature.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) id CAA95634; Tue, 21 Nov 2000 02:30:04 -0800 (PST)
Date:   Tue, 21 Nov 2000 02:30:04 -0800 (PST)
Message-Id: <200011211030.CAA95634@feature.engr.sgi.com>
X-Pv-Incident: 808315 
Reply-To: sgi.bugs.xfs@fido.engr.sgi.com
From:   pv@fddi-odin.corp.sgi.com (lord@sgi.com)
Subject: TAKE 808315 - Full file systems can become corrupted with XFS Linux.
To:     nb@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

 Submitter : cattelan                 *Status : closed                      
 Assigned Engineer : nb               *Fixed By : lord                      
*Fixed By Domain : sgi.com            *Closed Date : 11/21/00               
 Priority : 2                         *Modified Date : 11/21/00             
*Modified User : lord                 *Modified User Domain : sgi.com       
*Fix Description :
From: steve lord <lord@sgi.com> (TAKE)
Date: Nov 21 2000 02:30:03AM
[pvnews version: 1.71]
----------------------------

Date:  Tue Nov 21 02:24:08 PST 2000
Workarea:  jen.americas.sgi.com:/src/lord/xfs-linux.2.4

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


Modid:  2.4.x-xfs:slinx:78638a
linux/fs/pagebuf/page_buf_io.c - 1.36
	- Final version of the fix for the corruption problem, do the in place
	  extent conversion during the write call, but do not overwrite the bmap
	  being used by the top half of the write path.
Description :
Linux XFS may corrupt file system when disk si filled.

Very large write requests causes portions of the user data IO path
to continue writing beyond the end of an allocted extent thus over-writting
the start of the next AG. 

This usally show up as trashed secondary super blocks and probably
other data structures in the AG.

From owner-linux-xfs@oss.sgi.com Tue Nov 21 03:46:38 2000
Received:  by oss.sgi.com id <S553669AbQKULq2>;
	Tue, 21 Nov 2000 03:46:28 -0800
Received: from perninha.conectiva.com.br ([200.250.58.156]:64014 "EHLO
        perninha.conectiva.com.br") by oss.sgi.com with ESMTP
	id <S553660AbQKULqN>; Tue, 21 Nov 2000 03:46:13 -0800
Received: from freak.distro.conectiva (freak.distro.conectiva [10.0.17.22])
	by perninha.conectiva.com.br (8.9.3/8.9.3) with ESMTP id JAA30642;
	Tue, 21 Nov 2000 09:46:01 -0200
Date:   Tue, 21 Nov 2000 09:45:38 -0200 (BRST)
From:   Marcelo Tosatti <marcelo@conectiva.com.br>
X-Sender: marcelo@freak.distro.conectiva
To:     Chaitanya Tumuluri <chait@getafix.engr.sgi.com>
cc:     linux-xfs@oss.sgi.com, axboe@suse.de, mkp@linuxcare.com
Subject: Re: [RFC] split kiobuf/buffer-head IO code Re: xfs file system 
In-Reply-To: <200011202105.QAA32648@getafix.engr.sgi.com>
Message-ID: <Pine.LNX.4.21.0011210937350.7229-100000@freak.distro.conectiva>
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, 20 Nov 2000, Chaitanya Tumuluri wrote:

<snip>

> The other reason (they seem to multiply with every email!) I don't want to make too
> many changes currently, is that Eric Youngdale is thinking in terms of a major rewrite
> to the block-queueing layer (including getting rid of the old scsi error-handling code
> and the drivers that break with it!). 

I see. 

> So, perhaps, we should revisit this discussion when 2.5 does open up
> and then rework the queueing layer as you suggest along with everyone
> else that wants to improve it! :^)

Agreed. 

For now, I'll finish the RAID1/5 kiobuf IO support and look a bit more at
the difference between bh based XFS and kiobuf based XFS.

Do you have any results with different types of sequential/random IO on
both IO methods?


From owner-linux-xfs@oss.sgi.com Tue Nov 21 04:00:38 2000
Received:  by oss.sgi.com id <S553719AbQKUMAS>;
	Tue, 21 Nov 2000 04:00:18 -0800
Received: from Cantor.suse.de ([194.112.123.193]:14864 "HELO Cantor.suse.de")
	by oss.sgi.com with SMTP id <S553663AbQKUL7y>;
	Tue, 21 Nov 2000 03:59:54 -0800
Received: from Hermes.suse.de (Hermes.suse.de [194.112.123.136])
	by Cantor.suse.de (Postfix) with ESMTP
	id 8A6A31E16F; Tue, 21 Nov 2000 12:59:51 +0100 (MET)
Received: from gruyere.muc.suse.de (unknown [10.23.1.2])
	by Hermes.suse.de (Postfix) with ESMTP
	id 332E23E454; Tue, 21 Nov 2000 12:59:51 +0100 (MET)
Received: by gruyere.muc.suse.de (Postfix, from userid 14446)
	id 1D39D2F300; Tue, 21 Nov 2000 12:59:50 +0100 (MET)
Date:   Tue, 21 Nov 2000 12:59:50 +0100
From:   Andi Kleen <ak@suse.de>
To:     sgi.bugs.xfs@fido.engr.sgi.com
Cc:     dxm@cthulhu.engr.sgi.com, linux-xfs@oss.sgi.com
Subject: Re: ADD 808328 - xfs_support EXPORTs symbols with generic names
Message-ID: <20001121125950.A17267@gruyere.muc.suse.de>
References: <200011210055.QAA83099@feature.engr.sgi.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <200011210055.QAA83099@feature.engr.sgi.com>; from pv@fddi-odin.corp.sgi.com on Mon, Nov 20, 2000 at 04:55:03PM -0800
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, Nov 20, 2000 at 04:55:03PM -0800, cattelan@thebarn.com wrote:
>  Submitter : dxm                       Status : open                        
>  Assigned Engineer : dxm               Priority : 4                         
> *Modified Date : 11/20/00             *Modified User : cattelan             
> *Modified User Domain : thebarn.com   *Description :
> xfs_support uses EXPORT_SYMBOL to export a bunch of symbols
> into the kernel global symbol namespace. Some of the symbol
> names are quite generic and hence potentially clash with other
> exports.
> 
> Case in point is "copyin" and "copyout".
> 
> we can:
> 	- move code back into XFS
> 	- make simple functions static inline
> 
> .....
> 
> 
> ==========================
> ADDITIONAL INFORMATION (ADD)
> From: russell cattelan <cattelan@thebarn.com>
> Date: Nov 20 2000 04:55:03PM
> [pvnews version: 1.71]
> ==========================
> "dxm@engr.sgi.com" wrote:
> 
> > View Incident: http://co-op.engr.sgi.com/BugWorks/code/bwxquery.cgi?search=Search&wlong=1&view_type=Bug&wi=808328
> >
> > Submitter : dxm                       Submitter Domain : engr
> > Assigned Engineer : dxm               Assigned Domain : engr
> > Assigned Group : xfs-linux            Category : software
> > Customer Reported : F                 Priority : 4
> > Project : xfs-linux                   Status : open
> > Description :
> > xfs_support uses EXPORT_SYMBOL to export a bunch of symbols
> > into the kernel global symbol namespace. Some of the symbol
> > names are quite generic and hence potentially clash with other
> > exports.
> >
> > Case in point is "copyin" and "copyout".
> >
> > we can:
> >         - move code back into XFS
> >         - make simple functions static inline
> >         - prefix symbols and use macro aliasing to avoid
> >                 changing all references to them
> 
> This seems like the easiest.
> 
> Actually is there any reason we shouldn't just define copyin -> copy_from_user and
> copyout -> copy_to_user?

When you do that you have to fix a few error checks though: 

% grep copyin fs/xfs/*.c
...
fs/xfs/xfs_qm_syscalls.c:       if (copyin(uflagsp, &uflags, sizeof(uint)) < 0) {
fs/xfs/xfs_qm_syscalls.c:       if (copyin(uflagsp, &uflags, sizeof(uint)) < 0) 

copy_*_user return a positive value on error (number of uncopied bytes) 
It seems to be wrong even without any changes right now, because the copyin wrapper
do not do the ? -EFAULT : 0. 



-Andi


From owner-linux-xfs@oss.sgi.com Tue Nov 21 04:06:48 2000
Received:  by oss.sgi.com id <S553746AbQKUMGj>;
	Tue, 21 Nov 2000 04:06:39 -0800
Received: from deliverator.sgi.com ([204.94.214.10]:4635 "EHLO
        deliverator.sgi.com") by oss.sgi.com with ESMTP id <S553711AbQKUMGX>;
	Tue, 21 Nov 2000 04:06:23 -0800
Received: from feature.engr.sgi.com (gate-feature.engr.sgi.com [130.62.42.134]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id DAA07381; Tue, 21 Nov 2000 03:58:30 -0800 (PST)
	mail_from (pv@feature.engr.sgi.com)
Received: (from pv@localhost) by feature.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) id EAA97149; Tue, 21 Nov 2000 04:05:04 -0800 (PST)
Date:   Tue, 21 Nov 2000 04:05:04 -0800 (PST)
Message-Id: <200011211205.EAA97149@feature.engr.sgi.com>
X-Pv-Incident: 808328 
Reply-To: sgi.bugs.xfs@fido.engr.sgi.com
From:   pv@fddi-odin.corp.sgi.com (ak@suse.de.sgi.com)
Subject: ADD 808328 - xfs_support EXPORTs symbols with generic names
To:     dxm@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

 Submitter : dxm                       Status : open                        
 Assigned Engineer : dxm               Priority : 4                         
*Modified Date : 11/21/00             *Modified User : ak                   
*Modified User Domain : suse.de       *Description :
xfs_support uses EXPORT_SYMBOL to export a bunch of symbols
into the kernel global symbol namespace. Some of the symbol
names are quite generic and hence potentially clash with other
exports.

Case in point is "copyin" and "copyout".

we can:
	- move code back into XFS
	- make simple functions static inline

.....


==========================
ADDITIONAL INFORMATION (ADD)
From: andi kleen <ak@suse.de>
Date: Nov 21 2000 04:05:04AM
[pvnews version: 1.71]
==========================
On Mon, Nov 20, 2000 at 04:55:03PM -0800, cattelan@thebarn.com wrote:
>  Submitter : dxm                       Status : open                        
>  Assigned Engineer : dxm               Priority : 4                         
> *Modified Date : 11/20/00             *Modified User : cattelan             
> *Modified User Domain : thebarn.com   *Description :
> xfs_support uses EXPORT_SYMBOL to export a bunch of symbols
> into the kernel global symbol namespace. Some of the symbol
> names are quite generic and hence potentially clash with other
> exports.
> 
> Case in point is "copyin" and "copyout".
> 
> we can:
> 	- move code back into XFS
> 	- make simple functions static inline
> 
> .....
> 
> 
> ==========================
> ADDITIONAL INFORMATION (ADD)
> From: russell cattelan <cattelan@thebarn.com>
> Date: Nov 20 2000 04:55:03PM
> [pvnews version: 1.71]
> ==========================
> "dxm@engr.sgi.com" wrote:
> 
> > View Incident: http://co-op.engr.sgi.com/BugWorks/code/bwxquery.cgi?search=Search&wlong=1&view_type=Bug&wi=808328
> >
> > Submitter : dxm                       Submitter Domain : engr
> > Assigned Engineer : dxm               Assigned Domain : engr
> > Assigned Group : xfs-linux            Category : software
> > Customer Reported : F                 Priority : 4
> > Project : xfs-linux                   Status : open
> > Description :
> > xfs_support uses EXPORT_SYMBOL to export a bunch of symbols
> > into the kernel global symbol namespace. Some of the symbol
> > names are quite generic and hence potentially clash with other
> > exports.
> >
> > Case in point is "copyin" and "copyout".
> >
> > we can:
> >         - move code back into XFS
> >         - make simple functions static inline
> >         - prefix symbols and use macro aliasing to avoid
> >                 changing all references to them
> 
> This seems like the easiest.
> 
> Actually is there any reason we shouldn't just define copyin -> copy_from_user and
> copyout -> copy_to_user?

When you do that you have to fix a few error checks though: 

% grep copyin fs/xfs/*.c
...
fs/xfs/xfs_qm_syscalls.c:       if (copyin(uflagsp, &uflags, sizeof(uint)) < 0) {
fs/xfs/xfs_qm_syscalls.c:       if (copyin(uflagsp, &uflags, sizeof(uint)) < 0) 

copy_*_user return a positive value on error (number of uncopied bytes) 
It seems to be wrong even without any changes right now, because the copyin wrapper
do not do the ? -EFAULT : 0. 



-Andi

From owner-linux-xfs@oss.sgi.com Tue Nov 21 06:10:59 2000
Received:  by oss.sgi.com id <S553751AbQKUOKt>;
	Tue, 21 Nov 2000 06:10:49 -0800
Received: from pneumatic-tube.sgi.com ([204.94.214.22]:5499 "EHLO
        pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP
	id <S553739AbQKUOKb>; Tue, 21 Nov 2000 06:10:31 -0800
Received: from feature.engr.sgi.com (gate-feature.engr.sgi.com [130.62.42.134]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id GAA04193; Tue, 21 Nov 2000 06:18:24 -0800 (PST)
	mail_from (pv@feature.engr.sgi.com)
Received: (from pv@localhost) by feature.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) id GAA99425; Tue, 21 Nov 2000 06:09:12 -0800 (PST)
Date:   Tue, 21 Nov 2000 06:09:12 -0800 (PST)
Message-Id: <200011211409.GAA99425@feature.engr.sgi.com>
X-Pv-Incident: 808328 
Reply-To: sgi.bugs.xfs@fido.engr.sgi.com
From:   pv@fddi-odin.corp.sgi.com (dxm@melbourne.sgi.com)
Subject: ADD 808328 - xfs_support EXPORTs symbols with generic names
To:     dxm@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

 Submitter : dxm                       Status : open                        
 Assigned Engineer : dxm               Priority : 4                         
*Modified Date : 11/21/00             *Modified User : dxm                  
*Modified User Domain : melbourne     *Description :
xfs_support uses EXPORT_SYMBOL to export a bunch of symbols
into the kernel global symbol namespace. Some of the symbol
names are quite generic and hence potentially clash with other
exports.

Case in point is "copyin" and "copyout".

we can:
	- move code back into XFS
	- make simple functions static inline

.....


==========================
ADDITIONAL INFORMATION (ADD)
From: daniel moore <dxm@clouds.melbourne.sgi.com>
Date: Nov 21 2000 06:09:11AM
[pvnews version: 1.71]
==========================

Russell Cattelan writes:
 => >         - prefix symbols and use macro aliasing to avoid
 => >                 changing all references to them
 => 
 => This seems like the easiest.

Yep. But some, probably including "random", can just go back into
XFS.

 => Actually is there any reason we shouldn't just define copyin -> copy_from_u
 => ser and
 => copyout -> copy_to_user?
 => 
 => The functions were probably originally done for debug purposes.

There's a comment there about side-effects when done with #define
so I just made them inline. Can't see how there could be a problem
however.

-----------------------------------------------------
 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 Tue Nov 21 06:32:59 2000
Received:  by oss.sgi.com id <S553762AbQKUOct>;
	Tue, 21 Nov 2000 06:32:49 -0800
Received: from tux.mkp.net ([130.225.60.11]:49424 "EHLO tux.mkp.net")
	by oss.sgi.com with ESMTP id <S553743AbQKUOcc>;
	Tue, 21 Nov 2000 06:32:32 -0800
Received: from tux.mkp.net ([130.225.60.11] helo=jaguar.mkp.net)
	by tux.mkp.net with esmtp (Exim 3.14 #2)
	id 13yEJm-0003hN-00; Tue, 21 Nov 2000 15:22:42 +0100
Received: (from mkp@localhost)
	by jaguar.mkp.net (8.9.3/8.9.3) id JAA03092;
	Tue, 21 Nov 2000 09:32:31 -0500
X-Authentication-Warning: jaguar.mkp.net: mkp set sender to mkp@mkp.net using -f
To:     kris buggenhout <gast6@vum.be>
Cc:     linux-xfs@oss.sgi.com
Subject: Re: XFS on sparc 64
References: <200011162105.PAA21883@jen.americas.sgi.com>
	<3A14F45E.A844533C@vum.be>
From:   "Martin K. Petersen" <mkp@linuxcare.com>
Organization: Linuxcare, Inc.
Date:   21 Nov 2000 09:32:31 -0500
In-Reply-To: kris buggenhout's message of "Fri, 17 Nov 2000 10:03:26 +0100"
Message-ID: <yq1n1ets8e8.fsf@jaguar.mkp.net>
Lines:  67
User-Agent: Gnus/5.0807 (Gnus v5.8.7) XEmacs/21.1 (Canyonlands)
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


Ok.  I managed to reproduce the bus error during xfs_repair on SPARC.
Btw. this particular file system has several gigs of free space.  It
just finished a successful dbench 32 run.

I'm off to fight my way through the snow to the office now.  I'll look
at this again tonight...

---8<---

This GDB was configured as "sparc-redhat-linux"...
(gdb) run /dev/sdb2
Starting program: /usr/src/slinx-pristine/cmd/xfs/repair/./xfs_repair /
Phase 1 - find and verify superblock...
Phase 2 - using internal log
        - zero log...
        - scan filesystem freespace and inode maps...
freeblk count 1 != flcount -2048 in ag 0
bad agbno 4294965248 for btbno root, agno 0
bad agbno 374885040 for btbcnt root, agno 0
        - found root inode chunk
Phase 3 - for each AG...
        - scan and clear agi unlinked lists...
        - process known inodes and perform inode discovery...
        - agno = 0

Program received signal SIGBUS, Bus error.
0x7b504 in libxfs_bmbt_get_all (r=0xfb5a4, s=0xeffff238)
    at xfs_bmap_btree.c:1567
1567		s->br_startoff = ((xfs_fileoff_t)INT_GET(r->l0, ARCH_CO
(gdb) bt
#0  0x7b504 in libxfs_bmbt_get_all (r=0xfb5a4, s=0xeffff238)
    at xfs_bmap_btree.c:1567
#1  0x1e5d0 in convert_extent (rp=0xfb5a4, op=0xeffff310, sp=0xeffff320
    cp=0xeffff330, fp=0xeffff2f4) at dinode.c:446
#2  0x1e8a8 in process_bmbt_reclist_int (mp=0xeffff830, rp=0xfb5a4, num
    type=5, ino=259, tot=0xeffff550, blkmapp=0xeffff4fc, first_key=0xef
    last_key=0xeffff458, check_dups=0, whichfork=0) at dinode.c:536
#3  0x1fab8 in process_bmbt_reclist (mp=0xeffff830, rp=0xfb5a4, numrecs
    type=5, ino=259, tot=0xeffff550, blkmapp=0xeffff4fc, first_key=0xef
    last_key=0xeffff458, whichfork=0) at dinode.c:782
#4  0x21838 in process_exinode (mp=0xeffff830, agno=0, ino=259, dip=0xf
    type=5, dirty=0xeffff694, tot=0xeffff550, nex=0xeffff520, 
    blkmapp=0xeffff4fc, whichfork=0, check_dups=0) at dinode.c:1294
#5  0x2481c in process_dinode_int (mp=0xeffff830, dino=0xfb540, agno=0,
    ino=259, was_free=0, dirty=0xeffff694, cleared=0xeffff67c, 
    used=0xeffff6a0, verify_mode=0, uncertain=0, ino_discovery=1, 
    check_dups=0, extra_attr_check=1, isa_dir=0xeffff678, parent=0xefff
    at dinode.c:2298
#6  0x25f24 in process_dinode (mp=0xeffff830, dino=0xfb540, agno=0, ino
    was_free=0, dirty=0xeffff694, cleared=0xeffff67c, used=0xeffff6a0, 
    ino_discovery=1, check_dups=0, extra_attr_check=1, isa_dir=0xeffff6
    parent=0xeffff6b8) at dinode.c:2855
#7  0x1c30c in process_inode_chunk (mp=0xeffff830, agno=0, num_inos=64,
    first_irec=0xfb1d8, ino_discovery=1, check_dups=0, extra_attr_check
    bogus=0xeffff740) at dino_chunks.c:739
#8  0x1d0c0 in process_aginodes (mp=0xeffff830, agno=0, ino_discovery=1
    check_dups=0, extra_attr_check=1) at dino_chunks.c:953
#9  0x39fe8 in phase3 (mp=0xeffff830) at phase3.c:193
#10 0x57768 in main (argc=2, argv=0xeffffb8c) at xfs_repair.c:473
(gdb) 

-- 
Martin K. Petersen, Principal Linux Consultant, Linuxcare, Inc.
mkp@linuxcare.com, http://www.linuxcare.com/
Linuxcare. Moving Forward.


From owner-linux-xfs@oss.sgi.com Tue Nov 21 11:49:01 2000
Received:  by oss.sgi.com id <S553779AbQKUTsl>;
	Tue, 21 Nov 2000 11:48:41 -0800
Received: from deliverator.sgi.com ([204.94.214.10]:13615 "EHLO
        deliverator.sgi.com") by oss.sgi.com with ESMTP id <S553656AbQKUTsW>;
	Tue, 21 Nov 2000 11:48:22 -0800
Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id LAA19740
	for <linux-xfs@oss.sgi.com>; Tue, 21 Nov 2000 11:40:29 -0800 (PST)
	mail_from (cattelan@gibble.americas.sgi.com)
Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id NAA7717271 for <linux-xfs@oss.sgi.com>; Tue, 21 Nov 2000 13:47:05 -0600 (CST)
Received: from gibble.americas.sgi.com (gibble.americas.sgi.com [128.162.195.80]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id NAA30908 for <linux-xfs@oss.sgi.com>; Tue, 21 Nov 2000 13:47:05 -0600 (CST)
Received: (from cattelan@localhost)
	by gibble.americas.sgi.com (8.11.0/8.10.1) id eALJl5g31567
	for linux-xfs@oss.sgi.com; Tue, 21 Nov 2000 13:47:05 -0600
Date:   Tue, 21 Nov 2000 13:47:05 -0600
From:   Russell Cattelan <cattelan@sgi.com>
Message-Id: <200011211947.eALJl5g31567@gibble.americas.sgi.com>
Subject: TAKE - Merge of bmap fix to beta tree.
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

Date:  Tue Nov 21 11:46:35 PST 2000
Workarea:  gibble.americas.sgi.com:/export/extra/x2.4-xfs-beta
Author:  lord
Merged by:  cattelan
Merged mods:  2.4.x-xfs:slinx:78638a

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


Modid:  2.4.x-xfs-beta:slinx:78638a
linux/fs/pagebuf/page_buf_io.c - 1.31
	- Merge of 2.4.x-xfs:slinx:78638a by cattelan.
	  Final version of the fix for the corruption problem, do the in place
	  extent conversion during the write call, but do not overwrite the bmap
	  being used by the top half of the write path.



From owner-linux-xfs@oss.sgi.com Tue Nov 21 16:19:54 2000
Received:  by oss.sgi.com id <S553661AbQKVATo>;
	Tue, 21 Nov 2000 16:19:44 -0800
Received: from deliverator.sgi.com ([204.94.214.10]:51470 "EHLO
        deliverator.sgi.com") by oss.sgi.com with ESMTP id <S553653AbQKVATW>;
	Tue, 21 Nov 2000 16:19:22 -0800
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 QAA05499; Tue, 21 Nov 2000 16:11:29 -0800 (PST)
	mail_from (nobody@info.engr.sgi.com)
Received: (from nobody@localhost)
	by info.engr.sgi.com (SGI-8.9.3/8.9.3) id QAA25179;
	Tue, 21 Nov 2000 16:19:21 -0800 (PST)
Date:   Tue, 21 Nov 2000 16:19:21 -0800 (PST)
Message-Id: <200011220019.QAA25179@info.engr.sgi.com>
X-Pv-Incident: 803884 
webPV:  proxy2.melbourne.sgi.com 
webExec: webpvupdate,pvincident 
Reply-To: sgi.bugs.xfs@fido.engr.sgi.com
From:   pv@relay.sgi.com (dxm@engr.sgi.com)
Subject: UPDATE 803884 - double-fault with HIGHMEM
To:     dxm@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=803884

 Status : open                         Priority : 3                         
*Assigned Engineer : dxm              *Assigned Domain : engr               
 Submitter : dxm                       Opened Date : 10/04/00               
*Modified User : dxm                  *Modified User Domain : engr          
*Description :
This is very unlikely to be related to XFS.

However, running the auto-qa suite on a 1Gb machine with
HIGHMEM enabled can cause a process to hang up and render
the machine pretty much useless.

I've seen a couple of different variants but the problem 
has always occured below load_elf_binary, padzero and
clear_user.


.....


==========================
ADDITIONAL INFORMATION (UPDATE)
From: dxm@engr (BugWorks)
Date: Nov 21 2000 04:19:20PM
==========================

From owner-linux-xfs@oss.sgi.com Tue Nov 21 16:20:34 2000
Received:  by oss.sgi.com id <S553699AbQKVAUY>;
	Tue, 21 Nov 2000 16:20:24 -0800
Received: from deliverator.sgi.com ([204.94.214.10]:1807 "EHLO
        deliverator.sgi.com") by oss.sgi.com with ESMTP id <S553656AbQKVAUQ>;
	Tue, 21 Nov 2000 16:20:16 -0800
Received: from nodin.corp.sgi.com (nodin.corp.sgi.com [192.26.51.193]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id QAA05610; Tue, 21 Nov 2000 16:12:23 -0800 (PST)
	mail_from (nobody@info.engr.sgi.com)
Received: from info.engr.sgi.com (info.engr.sgi.com [192.26.80.216]) by nodin.corp.sgi.com (980427.SGI.8.8.8/980728.SGI.AUTOCF) via ESMTP id QAA63443; Tue, 21 Nov 2000 16:19:46 -0800 (PST)
Received: (from nobody@localhost)
	by info.engr.sgi.com (SGI-8.9.3/8.9.3) id QAA73152;
	Tue, 21 Nov 2000 16:18:29 -0800 (PST)
Date:   Tue, 21 Nov 2000 16:18:29 -0800 (PST)
Message-Id: <200011220018.QAA73152@info.engr.sgi.com>
X-Pv-Incident: 803884 
webPV:  proxy2.melbourne.sgi.com 
webExec: webpvupdate,pvincident 
Reply-To: sgi.bugs.xfs@fido.engr.sgi.com
From:   pv@relay.sgi.com (dxm@engr.sgi.com)
Subject: REOPEN 803884 - double-fault with HIGHMEM
To:     nb@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=803884

*Status : open                         Priority : 3                         
 Assigned Engineer : nb                Submitter : dxm                      
 Project : xfs-linux                   Assigned Group : xfs-linux           
 Opened Date : 10/04/00               *Closed Date :                        
*Fixed By :                           *Fixed By Domain :                    
*Verified Date :                      *Modified User : dxm                  
*Modified User Domain : engr          *Description :
This is very unlikely to be related to XFS.

However, running the auto-qa suite on a 1Gb machine with
HIGHMEM enabled can cause a process to hang up and render
the machine pretty much useless.

I've seen a couple of different variants but the problem 
has always occured below load_elf_binary, padzero and
clear_user.


.....


==========================
ADDITIONAL INFORMATION (REOPEN)
From: dxm@engr (BugWorks)
Date: Nov 21 2000 04:18:28PM
==========================

It's not fixed. But it does seem less frequent. I'm 
reopening this to remind me to follow this up.

From owner-linux-xfs@oss.sgi.com Tue Nov 21 16:35:24 2000
Received:  by oss.sgi.com id <S553760AbQKVAfE>;
	Tue, 21 Nov 2000 16:35:04 -0800
Received: from deliverator.sgi.com ([204.94.214.10]:54290 "EHLO
        deliverator.sgi.com") by oss.sgi.com with ESMTP id <S553679AbQKVAef>;
	Tue, 21 Nov 2000 16:34:35 -0800
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 QAA07570
	for <linux-xfs@oss.sgi.com>; Tue, 21 Nov 2000 16:26:37 -0800 (PST)
	mail_from (nathans@wobbly.melbourne.sgi.com)
Received: from wobbly.melbourne.sgi.com (wobbly.melbourne.sgi.com [134.14.55.135]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id LAA21837; Wed, 22 Nov 2000 11:33:13 +1100
Received: (from nathans@localhost) by wobbly.melbourne.sgi.com (980427.SGI.8.8.8/980728.SGI.AUTOCF) id LAA57674; Wed, 22 Nov 2000 11:33:11 +1100 (EDT)
From:   "Nathan Scott" <nathans@wobbly.melbourne.sgi.com>
Message-Id: <10011221133.ZM124976@wobbly.melbourne.sgi.com>
Date:   Wed, 22 Nov 2000 11:33:11 -0400
In-Reply-To: Danny <danscox@mindspring.com>
        "Re: XFS ACL Patch" (Nov 16,  5:50pm)
References: <200011161859.MAA12613@jen.americas.sgi.com> 
	<3A1464C9.F3027609@mindspring.com>
X-Mailer: Z-Mail (3.2.3 08feb96 MediaMail)
To:     dcox@connex.com
Subject: Re: XFS ACL Patch
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

hi Danny,

On Nov 16,  5:50pm, Danny wrote:
> Subject: Re: XFS ACL Patch
> ...
> 	Okay, here's a patch which should be much happier!  It's against
> test10, and seems to work on my system.
> 
> 	I've corrected the problems Steve mentioned, and ran diff properly (I
> think).  Please try it, and let me know what you think.
> 

apologies for not getting back to you sooner - your patch
should make its way into the tree in the next few days,
modulo a few minor changes.

cheers.

-- 
Nathan

From owner-linux-xfs@oss.sgi.com Tue Nov 21 17:33:23 2000
Received:  by oss.sgi.com id <S553774AbQKVBdO>;
	Tue, 21 Nov 2000 17:33:14 -0800
Received: from pneumatic-tube.sgi.com ([204.94.214.22]:5474 "EHLO
        pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP
	id <S553764AbQKVBcv>; Tue, 21 Nov 2000 17:32:51 -0800
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 RAA03997; Tue, 21 Nov 2000 17:40:44 -0800 (PST)
	mail_from (nobody@info.engr.sgi.com)
Received: (from nobody@localhost)
	by info.engr.sgi.com (SGI-8.9.3/8.9.3) id RAA59561;
	Tue, 21 Nov 2000 17:32:43 -0800 (PST)
Date:   Tue, 21 Nov 2000 17:32:43 -0800 (PST)
Message-Id: <200011220132.RAA59561@info.engr.sgi.com>
X-Pv-Incident: 808328 
webPV:  proxy2.melbourne.sgi.com 
webExec: webpvupdate,pvincident 
Reply-To: sgi.bugs.xfs@fido.engr.sgi.com
From:   pv@relay.sgi.com (dxm@engr.sgi.com)
Subject: ADD 808328 - xfs_support EXPORTs symbols with generic names
To:     dxm@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=808328

 Status : open                         Priority : 4                         
 Assigned Engineer : dxm               Submitter : dxm                      
*Modified User : dxm                  *Modified User Domain : engr          
*Description :
xfs_support uses EXPORT_SYMBOL to export a bunch of symbols
into the kernel global symbol namespace. Some of the symbol
names are quite generic and hence potentially clash with other
exports.

Case in point is "copyin" and "copyout".

we can:
	- move code back into XFS
	- make simple functions static inline

.....


==========================
ADDITIONAL INFORMATION (ADD)
From: dxm@engr (BugWorks)
Date: Nov 21 2000 05:32:43PM
==========================

Well spotted Andi - I just moved the code, assuming it 
was correct. I've sinced checked up on this.

Linux copy_to_user and copy_from_user return 0 on success, +ve on failure
Irix copyin and copyout return 0 on success, -1 on failure

So our wrappers were not quite right. What was a bigger problem
was that a bunch of ioctls were assuming that copy_to_user and
copy_from_user return an errno on error.

Modid:  2.4.x-xfs:slinx:78747a
Date:  Tue Nov 21 17:32:17 PST 2000
Workarea:  snort:/build1/people/dxm/isms/slinx-xfs
Author:  dxm

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

cmd/xfs/stress/group - 1.51
        - add 048 fault test

cmd/xfs/stress/src/Makefile - 1.20
        - add fault.c

linux/fs/xfs/linux/xfs_ioctl.c - 1.24
        - fix error checking on copy_to_user and copy_from_user

linux/fs/xfs/support/move.h - 1.3
        - fix copyin/copyout wrappers

cmd/xfs/stress/048 - 1.1
        - run fault to check ioctl return codes on bad user address

cmd/xfs/stress/048.out - 1.1
        - output for 048

cmd/xfs/stress/src/fault.c - 1.1
        - check return codes from ioctls on bad user address

From owner-linux-xfs@oss.sgi.com Tue Nov 21 17:46:13 2000
Received:  by oss.sgi.com id <S553773AbQKVBpx>;
	Tue, 21 Nov 2000 17:45:53 -0800
Received: from pneumatic-tube.sgi.com ([204.94.214.22]:8803 "EHLO
        pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP
	id <S553721AbQKVBpr>; Tue, 21 Nov 2000 17:45:47 -0800
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 RAA08925
	for <linux-xfs@oss.sgi.com>; Tue, 21 Nov 2000 17:53:39 -0800 (PST)
	mail_from (nathans@wobbly.melbourne.sgi.com)
Received: from wobbly.melbourne.sgi.com (wobbly.melbourne.sgi.com [134.14.55.135]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id MAA22297; Wed, 22 Nov 2000 12:44:28 +1100
Received: (from nathans@localhost) by wobbly.melbourne.sgi.com (980427.SGI.8.8.8/980728.SGI.AUTOCF) id MAA56265; Wed, 22 Nov 2000 12:44:26 +1100 (EDT)
From:   "Nathan Scott" <nathans@wobbly.melbourne.sgi.com>
Message-Id: <10011221244.ZM158790@wobbly.melbourne.sgi.com>
Date:   Wed, 22 Nov 2000 12:44:25 -0400
In-Reply-To: Thomas Graichen <news-innominate.list.sgi.xfs@innominate.de>
        "Re: stress test on ppc" (Nov 15,  9:37am)
References: <news2mail-8uecj0$i5e$1@mate.bln.innominate.de> 
	<news-innominate.list.sgi.xfs@innominate.de> 
	<10011101103.ZM113097@wobbly.melbourne.sgi.com> 
	<20001110094151.C333@ysabell> 
	<10011110006.ZM127189@wobbly.melbourne.sgi.com> 
	<news2mail-8uo7od$4lt$1@mate.bln.innominate.de> 
	<10011141059.ZM128320@wobbly.melbourne.sgi.com> 
	<news2mail-8utlfv$8iu$1@mate.bln.innominate.de>
X-Mailer: Z-Mail (3.2.3 08feb96 MediaMail)
To:     Thomas Graichen <graichen@innominate.de>,
        thomas.graichen@innominate.de
Subject: Re: stress test on ppc
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

hi Thomas,

On Nov 15,  9:37am, Thomas Graichen wrote:
> Subject: Re: stress test on ppc
> ...
> > 004 - this looks like a 32 bit number overflow in the xfs_db
> > "freesp" command, i'll need to investigate a bit more.
> 

going through this one again - this doesn't look like a
bug in xfs_db after all (the xfs_db output in the .bad
file looks correct).

(cmd/xfs/stress/004 on ppc produced...)

QA output created by 004
Checking blocks column same as df: no (204776407040 != 1599815680)
Error: /dev/hda9: freesp mismatch: no (204776407040 != 1599815680)
xfs_db output ...
   from      to extents  blocks    pct
      1       1       4       4   0.00
  32768   49152       8  390576 100.00
total free extents 12
total free blocks 390580
average free extent size 32548.3
Checking percent column yields 100: 100

so, xfs_db gave us a total free blocks value of 390580,
which multiplied by the blocksize (4096) gives 1599815680.
df gave us an "avail" value of 1599815680, which all looks
correct - the question is, where did 204776407040 come from??

either the initial blocksize calculation is incorrect,
or perl on ppc is doing some very funky math.  can you
figure out what the blocksize gets calculated as?  (i've
changed the test to create a 004.full with this info in -
could you rerun the test & send me that?)

thanks.

(btw, any luck with ppc mount detecting a minix filesystem?)

-- 
Nathan

From owner-linux-xfs@oss.sgi.com Tue Nov 21 18:38:44 2000
Received:  by oss.sgi.com id <S553772AbQKVCiY>;
	Tue, 21 Nov 2000 18:38:24 -0800
Received: from pneumatic-tube.sgi.com ([204.94.214.22]:36453 "EHLO
        pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP
	id <S553761AbQKVCiE>; Tue, 21 Nov 2000 18:38:04 -0800
Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.55.149]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id SAA02487
	for <linux-xfs@oss.sgi.com>; Tue, 21 Nov 2000 18:45:56 -0800 (PST)
	mail_from (dxm@snort.melbourne.sgi.com)
Received: (from dxm@localhost)
	by snort.melbourne.sgi.com (SGI-8.9.3/8.9.3) id NAA99137
	for linux-xfs@oss.sgi.com; Wed, 22 Nov 2000 13:36:43 +1100 (EST)
Date:   Wed, 22 Nov 2000 13:36:43 +1100 (EST)
From:   Daniel Moore <dxm@snort.melbourne.sgi.com>
Message-Id: <200011220236.NAA99137@snort.melbourne.sgi.com>
To:     linux-xfs@oss.sgi.com
Subject: TAKE - xfs qa - test loopback mounts
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing

tests xfs on ext2 and ext2 on xfs on ext2 (all seems ok!)

Modid:  2.4.x-xfs:slinx:78751a
Date:  Tue Nov 21 18:36:07 PST 2000
Workarea:  snort:/build1/people/dxm/isms/slinx-xfs
Author:  dxm

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

cmd/xfs/stress/group - 1.52
	- add 049

cmd/xfs/stress/049 - 1.1
	- check XFS loop mounted from ext2 and ext2 from XFS from ext2

cmd/xfs/stress/049.out - 1.1
	- output for 049


From owner-linux-xfs@oss.sgi.com Tue Nov 21 19:57:34 2000
Received:  by oss.sgi.com id <S553785AbQKVD5Y>;
	Tue, 21 Nov 2000 19:57:24 -0800
Received: from pneumatic-tube.sgi.com ([204.94.214.22]:23657 "EHLO
        pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP
	id <S553776AbQKVD5G>; Tue, 21 Nov 2000 19:57:06 -0800
Received: from eric2.austin.sgi.com (root@eric2.austin.sgi.com [169.238.86.147]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id UAA05430
	for <linux-xfs@oss.sgi.com>; Tue, 21 Nov 2000 20:04:57 -0800 (PST)
	mail_from (eric@eric2.austin.sgi.com)
Received: (from eric@localhost)
	by eric2.austin.sgi.com (8.11.0/8.11.0) id eAM3uxM22207
	for linux-xfs@oss.sgi.com; Tue, 21 Nov 2000 21:56:59 -0600
Date:   Tue, 21 Nov 2000 21:56:59 -0600
From:   Eric Sandeen <eric@eric2.austin.sgi.com>
Message-Id: <200011220356.eAM3uxM22207@eric2.austin.sgi.com>
Subject: TAKE - Remove unused variables in linux/fs/xfs/linux
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

Date:  Tue Nov 21 19:52:40 PST 2000
Workarea:  eric2.austin.sgi.com:/home/eric/xfs/workarea-clean

Removed -Wno-unused warning option from linux/fs/xfs/linux/Makefile

removed unused variables in linux/fs/xfs/linux/*.c

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


Modid:  2.4.x-xfs:slinx:78754a
linux/fs/xfs/linux/xfs_lrw.c - 1.64
	- remove/fix unused variables

linux/fs/xfs/linux/Makefile - 1.30
	- remove -Wno-unused warning

linux/fs/xfs/linux/xfs_vnode.c - 1.45
linux/fs/xfs/linux/xfs_super.c - 1.99
linux/fs/xfs/linux/xfs_iops.c - 1.80
linux/fs/xfs/linux/xfs_mount_opt.c - 1.17
linux/fs/xfs/linux/xfs_ioctl.c - 1.25
	- remove/fix unused variables



From owner-linux-xfs@oss.sgi.com Tue Nov 21 22:57:25 2000
Received:  by oss.sgi.com id <S553794AbQKVG5Q>;
	Tue, 21 Nov 2000 22:57:16 -0800
Received: from deliverator.sgi.com ([204.94.214.10]:59233 "EHLO
        deliverator.sgi.com") by oss.sgi.com with ESMTP id <S553788AbQKVG5E>;
	Tue, 21 Nov 2000 22:57:04 -0800
Received: from eric2.austin.sgi.com (root@eric2.austin.sgi.com [169.238.86.147]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id WAA21175
	for <linux-xfs@oss.sgi.com>; Tue, 21 Nov 2000 22:49:10 -0800 (PST)
	mail_from (eric@eric2.austin.sgi.com)
Received: (from eric@localhost)
	by eric2.austin.sgi.com (8.11.0/8.11.0) id eAM6ttO08168
	for linux-xfs@oss.sgi.com; Wed, 22 Nov 2000 00:55:55 -0600
Date:   Wed, 22 Nov 2000 00:55:55 -0600
From:   Eric Sandeen <eric@eric2.austin.sgi.com>
Message-Id: <200011220655.eAM6ttO08168@eric2.austin.sgi.com>
Subject: TAKE - uninit'd variables in linux/fs/xfs/linux/ 
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

Date:  Tue Nov 21 22:53:25 PST 2000
Workarea:  eric2.austin.sgi.com:/home/eric/xfs/workarea-clean

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

One uninitialized warning remains, but it's ok, not sure how to
get rid of the warning elegantly...

Modid:  2.4.x-xfs:slinx:78759a
linux/fs/xfs/linux/xfs_vfs.c - 1.21
	- clean up uninitialized variables

linux/fs/xfs/linux/Makefile - 1.31
	- Remove -Wno-uninitialized flag

linux/fs/xfs/linux/xfs_vnode.c - 1.46
linux/fs/xfs/linux/xfs_iops.c - 1.81
	- clean up uninitialized variables



From owner-linux-xfs@oss.sgi.com Wed Nov 22 07:21:51 2000
Received:  by oss.sgi.com id <S553695AbQKVPVb>;
	Wed, 22 Nov 2000 07:21:31 -0800
Received: from plutonium.uunet.be ([194.7.1.47]:12813 "EHLO plutonium.uunet.be")
	by oss.sgi.com with ESMTP id <S553685AbQKVPU6>;
	Wed, 22 Nov 2000 07:20:58 -0800
Received: from gate.vum.be (firewall.vum.be [194.7.240.162])
	by plutonium.uunet.be (8.9.1/8.9.1) with SMTP id QAA01097;
	Wed, 22 Nov 2000 16:20:47 +0100 (CET)
Received: from pcgx14500003.vum.be (pcgx14500003 [83.105.1.4]) by leonidas.vum.be with ESMTP (8.7.6/8.7.1) id QAA27351; Wed, 22 Nov 2000 16:22:59 +0100 (MET)
Received: from vum.be (IDENT:kris@localhost.localdomain [127.0.0.1])
	by pcgx14500003.vum.be (8.9.3/8.8.7) with ESMTP id QAA20359;
	Wed, 22 Nov 2000 16:20:14 +0100
Message-ID: <3A1BE42E.83919DA@vum.be>
Date:   Wed, 22 Nov 2000 16:20:14 +0100
From:   kris buggenhout <gast6@vum.be>
X-Mailer: Mozilla 4.75 [en] (X11; U; Linux 2.4.0-test5 i686)
X-Accept-Language: en
MIME-Version: 1.0
To:     Russell Cattelan <cattelan@thebarn.com>, linux-xfs@oss.sgi.com
Subject: Re: XFS on sparc 64
References: <200011162105.PAA21883@jen.americas.sgi.com> <3A14F45E.A844533C@vum.be> <3A1548CA.71E44765@thebarn.com> <3A18EEDD.A313D46D@vum.be> <3A195EB6.27CD03B8@thebarn.com>
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: base64
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing

UnVzc2VsbCBDYXR0ZWxhbiB3cm90ZToNCg0KPiBrcmlzIGJ1Z2dlbmhvdXQgd3JvdGU6DQo+
DQo+ID4gUnVzc2VsbCBDYXR0ZWxhbiB3cm90ZToNCj4gPg0KPiA+ID4gPg0KPiA+ID4gPiBJ
IHdhcyBmaWxsaW5nIHRoZSBmaWxlc3lzdGVtIHdpdGggYW4gZnRwIGNsaWVudCwganVzdCBw
bGFpbiBtZ2V0IDZHYnl0ZXMsDQo+ID4gPiA+IGdvdCB0byArMSBHaWcgb2YgZGF0YSwuLi4g
dGhlbiBpIGdldCBhIHdyaXRlIGVycm9yIC4uLiBhbmQgdGhlIGZzIGhhbmdzIC4uLiBjYW50
DQo+ID4gPiA+IHVtb3VudCAuLi4gLT4gbm8gc2h1dGRvd24gcG9zc2libGUgLT4gaGFyZCBy
ZXNldCAhDQo+ID4gPiA+DQo+ID4gPiA+IHRoZW4gdHJ5aW5nIHRvIGdldCBpdCByZXBhaXJl
ZCA6DQo+ID4gPiA+DQo+ID4gPiA+IFtyb290QHdpbm5ldG91IC9ob21lXSMgeGZzX3JlcGFp
ciAvZGV2L3NkZQ0KPiA+ID4gPiB4ZnNfcmVwYWlyOiB3YXJuaW5nIC0gY2Fubm90IHNldCBi
bG9ja3NpemUgb24gYmxvY2sgZGV2aWNlIC9kZXYvc2RlOiBJbnZhbGlkDQo+ID4gPiA+IGFy
Z3VtZW50DQo+ID4gPiA+IFBoYXNlIDEgLSBmaW5kIGFuZCB2ZXJpZnkgc3VwZXJibG9jay4u
Lg0KPiA+ID4gPiBQaGFzZSAyIC0gdXNpbmcgaW50ZXJuYWwgbG9nDQo+ID4gPiA+ICAgICAg
ICAgLSB6ZXJvIGxvZy4uLg0KPiA+ID4gPiAgICAgICAgIC0gc2NhbiBmaWxlc3lzdGVtIGZy
ZWVzcGFjZSBhbmQgaW5vZGUgbWFwcy4uLg0KPiA+ID4gPiBmcmVlYmxrIGNvdW50IDIgIT0g
Zmxjb3VudCAtMjA0OCBpbiBhZyAwDQo+ID4gPiA+IGJhZCBhZ2JubyA0Mjk0OTY1MjQ4IGZv
ciBidGJubyByb290LCBhZ25vIDANCj4gPiA+ID4gYmFkIGFnYm5vIDUzMTI0NDcyMCBmb3Ig
YnRiY250IHJvb3QsIGFnbm8gMA0KPiA+ID4gPiAgICAgICAgIC0gZm91bmQgcm9vdCBpbm9k
ZSBjaHVuaw0KPiA+ID4gPiBQaGFzZSAzIC0gZm9yIGVhY2ggQUcuLi4NCj4gPiA+ID4gICAg
ICAgICAtIHNjYW4gYW5kIGNsZWFyIGFnaSB1bmxpbmtlZCBsaXN0cy4uLg0KPiA+ID4gPiAg
ICAgICAgIC0gcHJvY2VzcyBrbm93biBpbm9kZXMgYW5kIHBlcmZvcm0gaW5vZGUgZGlzY292
ZXJ5Li4uDQo+ID4gPiA+ICAgICAgICAgLSBhZ25vID0gMA0KPiA+ID4gPiBCdXMgZXJyb3Ig
KGNvcmUgZHVtcGVkKQ0KPiA+ID4NCj4gPiA+IFRoaXMgbG9va3MgY29uc2lzdGVudCB3aXRo
IHRoZSBwcm9ibGVtIHdlIGFyZSB3b3JraW5nIG9uIHJpZ2h0IG5vdy4NCj4gPiA+DQo+ID4g
PiBXaGVuIHRoZSBmaWxlIHN5c3RlbSBnZXRzIGNsb3NlIHRvIGJlaW5nIGZpbGxlZCBpdCBy
dW5zIGFyb3VuZCBmaW5kaW5nIGFsbCB0aGUNCj4gPiA+IHNtYWxsIGxlZnQgb3ZlciBleHRl
bnRzLiBBdCBzb21lIHBvaW50IG9uZSBvZiB0aGUgd3JpdGVzIGdvZXMgdG8gZmFyIGFuZCBz
Y3JpYmJsZXMNCj4gPiA+IG92ZXINCj4gPiA+IHRoZSB0aGUgYWcgc3RydWN0dXJlcy4gV2Ug
YXJlIGdldHRpbmcgY2xvc2UgdG8gcmVzb2x2aW5nIHRoZSBidWcuLi4gZ2l2ZSB1cyBhIGRh
eQ0KPiA+ID4gb3INCj4gPiA+IHNvLg0KPiA+ID4NCj4gPiA+IFRoZSBjb3JlIGR1bXAgb24g
dGhlIHJlcGFpciBpcyBub3QgYSBnb29kIHRoaW5nIGFsdGhvdWdoLi4uIGRvIHlvdSBoYXZl
IGEgc3RhY2sNCj4gPiA+IHRyYWNlPw0KPiA+DQo+ID4gbm90IGFueW1vcmUgLi4uDQo+ID4N
Cj4gPiBidXQgSSBjaGVja2VkIG91dCB0aGlzIG1vcm5pbmcgdGhlIGN2cyAuLiBhbmQgZGlk
IGEgcmVkdWlsZCAuLi4gaXQgYWxsIGNvbXBpbGVkDQo+ID4gY2xlYW4uLi4NCj4gPg0KPiA+
IGJ1dCBub3cgSSBoYXZlIGEgd29yc2UgcHJvYmxlbSAuLi4gaWYgSSB0cnkgdG8gd3JpdGUg
ZGF0YSA6IGlucHV0L291dHB1dCBlcnJvciAuLi4NCj4gPiB1bW91bnQgYW5kIHhmc19yZXBh
aXIgZG8gd29yayBub3cgLi4uIGJ1dCBJIGNhbnQgd3JpdGUgYSBiaXQgb2YgZGF0YSAsIGNh
biBjcmVhdGUNCj4gPiBkaXJlY3RvcmllcyBvayAuLi4gYnV0IGNhbnQgd3JpdGUgZGF0YQ0K
PiA+DQo+ID4gW3Jvb3RAd2lubmV0b3UgL3hmc19maWxlc3lzXSMgZWNobyAxID4gdHR0dA0K
PiA+IFtyb290QHdpbm5ldG91IC94ZnNfZmlsZXN5c10jIGNhdCB0dHR0DQo+ID4gY2F0OiB0
dHR0OiBJbnB1dC9vdXRwdXQgZXJyb3INCj4gPg0KPiA+IFN0YXJ0IG1vdW50aW5nIGZpbGVz
eXN0ZW06IHNkKDgsNjQpDQo+ID4gRW5kaW5nIGNsZWFuIFhGUyBtb3VudCBmb3IgZmlsZXN5
c3RlbTogc2QoOCw2NCkNCj4gPiBJL08gRXJyb3IgRGV0ZWN0ZWQuICBTaHV0dGluZyBkb3du
IGZpbGVzeXN0ZW06IHNkKDgsNjQpDQo+ID4gUGxlYXNlIHVtb3VudCB0aGUgZmlsZXN5c3Rl
bSwgYW5kIHJlY3RpZnkgdGhlIHByb2JsZW0ocykNCj4gPiBQQ0Q6IHBhZ2VidWZfYm1hcCBl
cnJvciAtMTAxMCBwYl9mbGFncyAweDEwMDEwMDAyDQo+ID4gU3RhcnQgbW91bnRpbmcgZmls
ZXN5c3RlbTogc2QoOCw2NCkNCj4gPiBFbmRpbmcgY2xlYW4gWEZTIG1vdW50IGZvciBmaWxl
c3lzdGVtOiBzZCg4LDY0KQ0KPiA+DQo+ID4gU2hvdWxkIEkgYmUgd29ycmllZCB0aGUgZGlz
ayBpcyBicm9rZW4gPyAuLi4gdGhlIGZpbGVzeXN0ZW0gdGhhdCB3YXMgcHJldmVvdXNseSB0
aGVyZQ0KPiA+IC4uLiBzZWVtZWQgdG8gYmUgYWxyaWdodCAuLi4gPz8NCj4NCj4gVW5jbGVh
ci4NCj4gRG8geW91IHNlZSBhbnkgZXJyb3IgbWVzc2FnZXMgb24gdGhlIGNvbnNvbGUgZnJv
bSB0aGUgZGlzayBkcml2ZXI/DQo+DQo+IElmIHhmc19yZXBhaXIgcnVucyB3aXRob3V0IHJl
cG9ydGluZyBJTyBlcnJvcnMgdGhlbiBpdCBwcm9iYWJseSBpc24ndCBhIGRpc2sgcHJvYmxl
bS4NCj4gQXNzdW1pbmcgeGZzX3JlcGFpciBjbGVhbmVkIHVwIHRoZSBGUywgZG9lcyB4ZnNf
Y2hlY2sgcnVuIHdpdGhvdXQgZXJyb3JzPw0KPg0KPiBUaGF0IHBhZ2VidWZfYm1hcCBlcnJv
ciBkb2VzIHNlZW0gdG8gaW5kaWNhdGUgc29tZSBwcm9ibGVtLg0KPiBJdCB0aGlzIGZpbGUg
c3lzdGVtIHJlYWxseSBjbG9zZSB0byBiZWluZyBmdWxsPw0KPg0KPiAtUnVzc2VsbA0KDQp0
aGUgZmlsZXN5c3RlbSBpcyBjb21wbGV0ZWx5IGVtcHR5LA0KDQphZnRlciBjcCAvZXRjL2Zz
dGFiIC4NCg0KSS9PIEVycm9yIERldGVjdGVkLiAgU2h1dHRpbmcgZG93biBmaWxlc3lzdGVt
OiBzZCg4LDY0KQ0KUGxlYXNlIHVtb3VudCB0aGUgZmlsZXN5c3RlbSwgYW5kIHJlY3RpZnkg
dGhlIHByb2JsZW0ocykNClBDRDogcGFnZWJ1Zl9ibWFwIGVycm9yIC0xMDEwIHBiX2ZsYWdz
IDB4MTAwMTAwMDINCltyb290QHdpbm5ldG91IC9dIyBscyB4ZnNfZmlsZXN5cw0KbHM6IHhm
c19maWxlc3lzOiBJbnB1dC9vdXRwdXQgZXJyb3INCg0KeGZzX3JlcGFpciA6DQp4ZnNfcmVw
YWlyOiB3YXJuaW5nIC0gY2Fubm90IHNldCBibG9ja3NpemUgb24gYmxvY2sgZGV2aWNlIC9k
ZXYvc2RlOiBJbnZhbGlkIGFyZ3VtZW50DQpQaGFzZSAxIC0gZmluZCBhbmQgdmVyaWZ5IHN1
cGVyYmxvY2suLi4NClBoYXNlIDIgLSB1c2luZyBpbnRlcm5hbCBsb2cNCiAgICAgICAgLSB6
ZXJvIGxvZy4uLg0KICAgICAgICAtIHNjYW4gZmlsZXN5c3RlbSBmcmVlc3BhY2UgYW5kIGlu
b2RlIG1hcHMuLi4NCmJhZCBtYWdpYyAjIDB4MTAwMDAgZm9yIGFnZiAwDQpiYWQgdmVyc2lv
biAjIDAgZm9yIGFnZiAwDQpiYWQgbGVuZ3RoIDAgZm9yIGFnZiAwLCBzaG91bGQgYmUgMTMw
MDY5DQpyZXNldCBiYWQgYWdmIGZvciBhZyAwDQpiYWQgbWFnaWMgIyAwIGluIGJ0Ym5vIGJs
b2NrIDAvNTUNCmV4cGVjdGVkIGxldmVsIC0xIGdvdCAwIGluIGJ0Ym5vIGJsb2NrIDAvNTUN
CmJhZCBhZ2JubyAwIGZvciBidGJjbnQgcm9vdCwgYWdubyAwDQogICAgICAgIC0gZm91bmQg
cm9vdCBpbm9kZSBjaHVuaw0KUGhhc2UgMyAtIGZvciBlYWNoIEFHLi4uDQogICAgICAgIC0g
c2NhbiBhbmQgY2xlYXIgYWdpIHVubGlua2VkIGxpc3RzLi4uDQogICAgICAgIC0gcHJvY2Vz
cyBrbm93biBpbm9kZXMgYW5kIHBlcmZvcm0gaW5vZGUgZGlzY292ZXJ5Li4uDQogICAgICAg
IC0gYWdubyA9IDANCmltYXAgY2xhaW1zIGEgZnJlZSBpbm9kZSAyNjQgaXMgaW4gdXNlLCBj
b3JyZWN0aW5nIGltYXAgYW5kIGNsZWFyaW5nIGlub2RlDQogICAgICAgIC0gYWdubyA9IDEN
CiAgICAgICAgLSBhZ25vID0gMg0KICAgICAgICAtIGFnbm8gPSAzDQogICAgICAgIC0gYWdu
byA9IDQNCiAgICAgICAgLSBhZ25vID0gNQ0KICAgICAgICAtIGFnbm8gPSA2DQogICAgICAg
IC0gYWdubyA9IDcNCiAgICAgICAgLSBhZ25vID0gOA0KICAgICAgICAtIGFnbm8gPSA5DQog
ICAgICAgIC0gYWdubyA9IDEwDQogICAgICAgIC0gYWdubyA9IDExDQogICAgICAgIC0gYWdu
byA9IDEyDQogICAgICAgIC0gYWdubyA9IDEzDQogICAgICAgIC0gYWdubyA9IDE0DQogICAg
ICAgIC0gYWdubyA9IDE1DQogICAgICAgIC0gYWdubyA9IDE2DQogICAgICAgIC0gcHJvY2Vz
cyBuZXdseSBkaXNjb3ZlcmVkIGlub2Rlcy4uLg0KUGhhc2UgNCAtIGNoZWNrIGZvciBkdXBs
aWNhdGUgYmxvY2tzLi4uDQogICAgICAgIC0gc2V0dGluZyB1cCBkdXBsaWNhdGUgZXh0ZW50
IGxpc3QuLi4NCiAgICAgICAgLSBjbGVhciBsb3N0K2ZvdW5kIChpZiBpdCBleGlzdHMpIC4u
Lg0KICAgICAgICAtIGNsZWFyaW5nIGV4aXN0aW5nICJsb3N0K2ZvdW5kIiBpbm9kZQ0KICAg
ICAgICAtIGRlbGV0aW5nIGV4aXN0aW5nICJsb3N0K2ZvdW5kIiBlbnRyeQ0KICAgICAgICAt
IGNoZWNrIGZvciBpbm9kZXMgY2xhaW1pbmcgZHVwbGljYXRlIGJsb2Nrcy4uLg0KICAgICAg
ICAtIGFnbm8gPSAwDQogICAgICAgIC0gYWdubyA9IDENCiAgICAgICAgLSBhZ25vID0gMg0K
ICAgICAgICAtIGFnbm8gPSAzDQogICAgICAgIC0gYWdubyA9IDQNCiAgICAgICAgLSBhZ25v
ID0gNQ0KICAgICAgICAtIGFnbm8gPSA2DQogICAgICAgIC0gYWdubyA9IDcNCiAgICAgICAg
LSBhZ25vID0gOA0KICAgICAgICAtIGFnbm8gPSA5DQogICAgICAgIC0gYWdubyA9IDEwDQog
ICAgICAgIC0gYWdubyA9IDExDQogICAgIC0gYWdubyA9IDEyDQogICAgICAgIC0gYWdubyA9
IDEzDQogICAgICAgIC0gYWdubyA9IDE0DQogICAgICAgIC0gYWdubyA9IDE1DQogICAgICAg
IC0gYWdubyA9IDE2DQpQaGFzZSA1IC0gcmVidWlsZCBBRyBoZWFkZXJzIGFuZCB0cmVlcy4u
Lg0KICAgICAgICAtIHJlc2V0IHN1cGVyYmxvY2suLi4NClBoYXNlIDYgLSBjaGVjayBpbm9k
ZSBjb25uZWN0aXZpdHkuLi4NCiAgICAgICAgLSByZXNldHRpbmcgY29udGVudHMgb2YgcmVh
bHRpbWUgYml0bWFwIGFuZCBzdW1tYXJ5IGlub2Rlcw0KICAgICAgICAtIGVuc3VyaW5nIGV4
aXN0ZW5jZSBvZiBsb3N0K2ZvdW5kIGRpcmVjdG9yeQ0KICAgICAgICAtIHRyYXZlcnNpbmcg
ZmlsZXN5c3RlbSBzdGFydGluZyBhdCAvIC4uLg0KICAgICAgICAtIHRyYXZlcnNhbCBmaW5p
c2hlZCAuLi4NCiAgICAgICAgLSB0cmF2ZXJzaW5nIGFsbCB1bmF0dGFjaGVkIHN1YnRyZWVz
IC4uLg0KICAgICAgICAtIHRyYXZlcnNhbHMgZmluaXNoZWQgLi4uDQogICAgICAgIC0gbW92
aW5nIGRpc2Nvbm5lY3RlZCBpbm9kZXMgdG8gbG9zdCtmb3VuZCAuLi4NClBoYXNlIDcgLSB2
ZXJpZnkgYW5kIGNvcnJlY3QgbGluayBjb3VudHMuLi4NCmRvbmUNCg0KDQouLi4NCg==

From owner-linux-xfs@oss.sgi.com Wed Nov 22 13:28:19 2000
Received:  by oss.sgi.com id <S553706AbQKVV17>;
	Wed, 22 Nov 2000 13:27:59 -0800
Received: from deliverator.sgi.com ([204.94.214.10]:56400 "EHLO
        deliverator.sgi.com") by oss.sgi.com with ESMTP id <S553678AbQKVV1p>;
	Wed, 22 Nov 2000 13:27:45 -0800
Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id NAA25150
	for <linux-xfs@oss.sgi.com>; Wed, 22 Nov 2000 13:19:52 -0800 (PST)
	mail_from (lord@jen.americas.sgi.com)
Received: from thistle-e185.americas.sgi.com (thistle-e185.americas.sgi.com [128.162.185.204]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id PAA7718370 for <linux-xfs@oss.sgi.com>; Wed, 22 Nov 2000 15:26:29 -0600 (CST)
Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.184.86]) by thistle-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id PAA69133 for <linux-xfs@oss.sgi.com>; Wed, 22 Nov 2000 15:26:29 -0600 (CST)
Received: from jen.americas.sgi.com (lord@localhost)
	by jen.americas.sgi.com (8.9.3/8.9.3) with ESMTP id PAA32495
	for <linux-xfs@oss.sgi.com>; Wed, 22 Nov 2000 15:19:28 -0600
Message-Id: <200011222119.PAA32495@jen.americas.sgi.com>
X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4
To:     linux-xfs@oss.sgi.com
From:   slord@tricord.com
Subject: Time to move on
Date:   Wed, 22 Nov 2000 15:19:28 -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,

After a long period of thought, I have decided to leave SGI for another
company. This was a difficult decision to make, especially when it came
to my work on the XFS port to Linux which I have really enjoyed. However,
other projects within SGI were taking me away from the XFS linux work
anyway so I decided to take the leap and move on.

XFS Linux will no longer be part of my day job, but I hope to stay as
active as I can, given a full time job, a wife and an 11 month old son
(not necessarily in that order!) I really don't know how Linus copes.

As of next week I should be reachable at slord@tricord.com 

Steve Lord



From owner-linux-xfs@oss.sgi.com Wed Nov 22 13:31:39 2000
Received:  by oss.sgi.com id <S553747AbQKVVb3>;
	Wed, 22 Nov 2000 13:31:29 -0800
Received: from fep04.swip.net ([130.244.199.132]:56239 "EHLO convert =?ISO-8859-1?Q?rfc822-to-8bitCq=0B=01?=
        fep04-svc.swip.net") by oss.sgi.com with ESMTP id <S553696AbQKVVbR>;
	Wed, 22 Nov 2000 13:31:17 -0800
Received: from jal ([212.151.89.245]) by fep04-svc.swip.net
          (InterMail vM.5.01.01.01 201-252-104) with SMTP
          id <20001122213100.MXYZ23474.fep04-svc.swip.net@jal>
          for <linux-xfs@oss.sgi.com>; Wed, 22 Nov 2000 22:31:00 +0100
Message-ID: <001101c054cb$81895810$0101a8c0@jal>
From:   =?iso-8859-1?Q?Johan_Sj=F6holm?= <Netmaster@streetwise.se>
To:     <linux-xfs@oss.sgi.com>
References: <200011222119.PAA32495@jen.americas.sgi.com>
Subject: Re: Time to move on
Date:   Wed, 22 Nov 2000 22:30:58 +0100
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 8BIT
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

Good luck in the after XFS-life, and goodspeed.

I think I speak for us all when I say ; You'll be missed deeply by us.

Whit friendly Regards

- Johan S
----- Original Message ----- 
From: <slord@tricord.com>
To: <linux-xfs@oss.sgi.com>
Sent: Wednesday, November 22, 2000 10:19 PM
Subject: Time to move on


> 
> Hi,
> 
> After a long period of thought, I have decided to leave SGI for another
> company. This was a difficult decision to make, especially when it came
> to my work on the XFS port to Linux which I have really enjoyed. However,
> other projects within SGI were taking me away from the XFS linux work
> anyway so I decided to take the leap and move on.
> 
> XFS Linux will no longer be part of my day job, but I hope to stay as
> active as I can, given a full time job, a wife and an 11 month old son
> (not necessarily in that order!) I really don't know how Linus copes.
> 
> As of next week I should be reachable at slord@tricord.com 
> 
> Steve Lord
> 
> 



From owner-linux-xfs@oss.sgi.com Wed Nov 22 13:48:19 2000
Received:  by oss.sgi.com id <S553765AbQKVVsJ>;
	Wed, 22 Nov 2000 13:48:09 -0800
Received: from ns1.SuSE.com ([202.58.118.2]:8206 "HELO ns1.suse.com")
	by oss.sgi.com with SMTP id <S553734AbQKVVrz>;
	Wed, 22 Nov 2000 13:47:55 -0800
Received: from euclid.oak.suse.com (fw.SuSE.com [202.58.118.35])
	by ns1.suse.com (Postfix) with ESMTP
	id 3A4A1DF928; Wed, 22 Nov 2000 13:36:57 -0800 (PST)
Received: from localhost (jsimmons@localhost)
	by euclid.oak.suse.com (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id NAA00352;
	Wed, 22 Nov 2000 13:48:11 -0800
X-Authentication-Warning: euclid.oak.suse.com: jsimmons owned process doing -bs
Date:   Wed, 22 Nov 2000 13:48:11 -0800 (PST)
From:   James Simmons <jsimmons@suse.com>
X-Sender: jsimmons@euclid.oak.suse.com
To:     slord@tricord.com
Cc:     linux-xfs@oss.sgi.com
Subject: Re: Time to move on
In-Reply-To: <200011222119.PAA32495@jen.americas.sgi.com>
Message-ID: <Pine.LNX.4.21.0011221346480.280-100000@euclid.oak.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


> XFS Linux will no longer be part of my day job, but I hope to stay as
> active as I can, given a full time job, a wife and an 11 month old son
> (not necessarily in that order!) I really don't know how Linus copes.

To bad I didn't know sooner. I mentioned this at suse and we could have
used someone of your talent.  


From owner-linux-xfs@oss.sgi.com Wed Nov 22 13:52:49 2000
Received:  by oss.sgi.com id <S553768AbQKVVwl>;
	Wed, 22 Nov 2000 13:52:41 -0800
Received: from ns1.SuSE.com ([202.58.118.2]:14350 "HELO ns1.suse.com")
	by oss.sgi.com with SMTP id <S553753AbQKVVwX>;
	Wed, 22 Nov 2000 13:52:23 -0800
Received: from euclid.oak.suse.com (fw.SuSE.com [202.58.118.35])
	by ns1.suse.com (Postfix) with ESMTP id A0BBADF929
	for <linux-xfs@oss.sgi.com>; Wed, 22 Nov 2000 13:41:25 -0800 (PST)
Received: from localhost (jsimmons@localhost)
	by euclid.oak.suse.com (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id NAA01311
	for <linux-xfs@oss.sgi.com>; Wed, 22 Nov 2000 13:52:40 -0800
X-Authentication-Warning: euclid.oak.suse.com: jsimmons owned process doing -bs
Date:   Wed, 22 Nov 2000 13:52:40 -0800 (PST)
From:   James Simmons <jsimmons@suse.com>
X-Sender: jsimmons@euclid.oak.suse.com
To:     Linux XFS Mailing List <linux-xfs@oss.sgi.com>
Subject: Apologe
Message-ID: <Pine.LNX.4.21.0011221352180.1309-100000@euclid.oak.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


Sorry a message was sent to the wrong place.


From owner-linux-xfs@oss.sgi.com Wed Nov 22 17:28:18 2000
Received:  by oss.sgi.com id <S553771AbQKWB2I>;
	Wed, 22 Nov 2000 17:28:08 -0800
Received: from pneumatic-tube.sgi.com ([204.94.214.22]:6751 "EHLO
        pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP
	id <S553796AbQKWBBA>; Wed, 22 Nov 2000 17:01:00 -0800
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 RAA08699
	for <linux-xfs@oss.sgi.com>; Wed, 22 Nov 2000 17:08:53 -0800 (PST)
	mail_from (nathans@wobbly.melbourne.sgi.com)
Received: from wobbly.melbourne.sgi.com (wobbly.melbourne.sgi.com [134.14.55.135]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id LAA26565; Thu, 23 Nov 2000 11:59:40 +1100
Received: (from nathans@localhost) by wobbly.melbourne.sgi.com (980427.SGI.8.8.8/980728.SGI.AUTOCF) id LAA56061; Thu, 23 Nov 2000 11:59:38 +1100 (EDT)
From:   "Nathan Scott" <nathans@wobbly.melbourne.sgi.com>
Message-Id: <10011231159.ZM155732@wobbly.melbourne.sgi.com>
Date:   Thu, 23 Nov 2000 11:59:36 -0400
In-Reply-To: John M Trostel <jtrostel@connex.com>
        "Using quotas with Linux XFS" (Nov 20,  1:01am)
References: <200011200604.BAA14286@blount.mail.mindspring.net>
X-Mailer: Z-Mail (3.2.3 08feb96 MediaMail)
To:     jtrostel@mindspring.com
Subject: Re: Using quotas with Linux XFS
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

hi John,

On Nov 20,  1:01am, John M Trostel wrote:
> Subject: Using quotas with Linux XFS
> ...
> 2. If I set the block and file limits for a user to some non-zero number
> such that repquotas responds:
> 
> [root@jtsdell quota]# /usr/local/sbin/repquota /dev/hda8
> 
>   Electric Fence 2.0.5 Copyright (C) 1987-1998 Bruce Perens.
>                         Block limits               File limits
> user            used    soft    hard  grace    used  soft  hard  grace
> root      --      16       0       0              8     0     0       
> jt        --   45856       0       0             12     0     0       
> sambaman  --       8     104     104              1    50    50       
> 
> The setting of the quota seems to have worked BUT... sambaman can not
> change anything or add anything to the filesystem without a disk quota
> exceeded error.
> 

ok, I think I can explain this one now.  the soft/hard blocks
reported above is in basic blocks (512), not filesystem blocks
(probably 4096), so your number should be divided by 8 to start
with (i.e. the hard limit is 13 filesystem blocks).  I need to
fix the way this is reported (in the user tools) and also the
set mechanisms (edquota/setquota).

depending on what you were doing, it is quite likely that you
really were exceeding that each time.

should also note that quota are enforced based on the maximum
number of blocks required by a transaction (which can be quite
a few blocks) and even though the end result might end up using
fewer blocks than anticipated you will not be allowed to proceed
if you have insufficient space to do the initial (maximum) space
reservation.

e.g. even creating an empty file can result in a change in form
of the parent directory (shortform/block/btree) and if one of
these transitions happen, many more blocks than one might think
are needed (some space is needed anyway for the new inode creat).

I've verified using some extra debugging code that using a
larger number of blocks to give you some initial headroom, and
then consuming space till you reach that, does actually work.
the inode limit enforcement is obviously much simpler, and that
also seems to work.

I've fixed your "usrquota" problem.  "grpquota" is a whole other
can of worms, so don't go there yet.  Dunno about your grace
problem yet - will require some further digging.

cheers.

-- 
Nathan

From owner-linux-xfs@oss.sgi.com Thu Nov 23 12:52:38 2000
Received:  by oss.sgi.com id <S553816AbQKWUw2>;
	Thu, 23 Nov 2000 12:52:28 -0800
Received: from c129.h210244143.is.net.tw ([210.244.143.129]:65029 "EHLO
        mail.bates.com.tw") by oss.sgi.com with ESMTP id <S553812AbQKWUwV>;
	Thu, 23 Nov 2000 12:52:21 -0800
Received: from host ([209.206.4.202]) by mail.bates.com.tw
          (Netscape Messaging Server 3.01)  with ESMTP id 437;
          Fri, 24 Nov 2000 04:42:34 +0800
From:   "Craig Harwer" <nmkt2@n2mail.com>
Subject: All in One #4BFC
To:     bill29e@oss.sgi.com
X-Mailer: Microsoft Outlook Express 4.72.1712.3
X-MimeOLE: Produced By Microsoft MimeOLE =?ISO-8859-1?Q?V=D0=DFD.1712.3?=
Mime-Version: 1.0
Date:   Thu, 23 Nov 2000 14:41:00 -0500
Content-Type: multipart/mixed; boundary="----=_NextPart_000_007F_01BDF6C7.FABAC1B0"
Content-Transfer-Encoding: 7bit
Message-Id: <20001123205226Z553812-486+14@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

This is a MIME Message

------=_NextPart_000_007F_01BDF6C7.FABAC1B0
Content-Type: multipart/alternative; boundary="----=_NextPart_001_0080_01BDF6C7.FABAC1B0"

------=_NextPart_001_0080_01BDF6C7.FABAC1B0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

***** This is an HTML Message ! *****


------=_NextPart_001_0080_01BDF6C7.FABAC1B0
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<html>

<head>

<body background=3D"images/bkg2=2Ejpg" leftmargin=3D"95">
<div align=3D"center">
  <center>
  <table border=3D"0" width=3D"98%">
    <tr>
      <td width=3D"100%">
        <p align=3D"center"></td>
    </tr>
    <tr>
      <td width=3D"100%">
        <div align=3D"center">
          <table border=3D"0" width=3D"98%">
            <tr>
              <td width=3D"17%"></td>
              <td width=3D"76%">
                <p align=3D"center"><b><i><font color=3D"#FF0000" size=3D"=
5">&quot;Reducing
                America's Debt!&quot;</font></i></b>
                </p>
              </td>
              <td width=3D"18%"></td>
            </tr>
          </table>
        </div>
        <p align=3D"center">
  </center>
        <div align=3D"center">
          <table border=3D"0" width=3D"100%">
            <tr>
              <td width=3D"100%" colspan=3D"4" bgcolor=3D"#FFFFE8">
                <p align=3D"center"><b><font size=3D"4" color=3D"#000080">=
Ask Yourself
                These 4 Questions=2E=2E=2E</font></b></td>
            </tr>
  <center>
            <tr>
              <td width=3D"5%"></td>
              <td width=3D"45%" valign=3D"middle">Are monthly credit card =
payments eating you alive?&nbsp;</td>
              <td width=3D"6%"></td>
              <td width=3D"44%" valign=3D"top">Would you like to pay off y=
our credit card &amp; other
                unsecured debts in 12 -30 months?</td>
            </tr>
            <tr>
              <td width=3D"100%" colspan=3D"4">
                <hr width=3D"50%" noshade color=3D"#808080">
              </td>
            </tr>
            <tr>
              <td width=3D"5%"></td>
              <td width=3D"45%" valign=3D"top">Would you prefer to pay onl=
y 2% of your unsecured debt per month?<br><i><font size=3D"1">(example: $10=
,000&nbsp;debt
                =3D $200 monthly payment)</font></i></td>
              <td width=3D"6%"></td>
              <td width=3D"44%" valign=3D"top">Would you like to save 40-5=
0% of your total debt
                at the same time?&nbsp;</td>
            </tr>
            <tr>
              <td width=3D"100%" colspan=3D"4" bgcolor=3D"#FFFFE8">
                <p align=3D"center"><b><font color=3D"#000080" size=3D"4">=
If You Answered
                </font><i><font size=3D"4" color=3D"#FF0000">YES</font></i=
><font color=3D"#000080" size=3D"4"> to any of these questions<br>Then This=
 Program is for You=2E=2E=2E&nbsp;</font></b></td>
            </tr>
          </table>
        </div>
        </center><p align=3D"center">We can=2E=2E=2Ereduce your debt up to=
 50%, cut your
        monthly payments by as much as 50%, totally eliminate your debt wi=
thin
        12 - 30 months, and direct you to a brighter more prosperous finan=
cial
        future!<br><a href=3D"#form">For your free consultation click here=
!</a>
        </p>
        <p align=3D"left"><font face=3D"Arial, Helvetica, sans-serif" size=
=3D"2">Our
        goal is to negotiate with your creditors for the purpose of settli=
ng the
        entire account balance at an amount significantly less than what i=
s
        owed=2E Settlements are paid with moneys accumulated in your FDIC
        Insured Bank Account=2E You commit to a single monthly payment int=
o
        the Program=2E As cash accumulates in the Your Account, settlement=

        offers are submitted to Creditors=2E Settlement agreements are ach=
ieved as
        Creditors respond with counter offers, and then finalized by Your
        approval=2E<br>
        <br>
        Settlements are often made in &quot;bulk&quot; (using financial le=
verage
        and using pooled funds) securing discounts well beyond the capabil=
ities
        of individual Consumers and most law firms=2E <b>Preferred Financi=
al
        Services</b> successfully negotiates with Creditors nationwide=2E<=
br>
        <br>
        You will receive monthly statements detailing your Account status =
and
        negotiation activity pertaining to each debt=2E A truly unique asp=
ect of
        our Program is that the You remain in control=2E You determine you=
r own Monthly Payment Commitment;
        You determine the
        approximate amount of time it will take to complete the Program; Y=
ou
        control how much money is withdrawn from the Your Bank Account; an=
d You ultimately
        determine whether or not to accept a settlement=2E Our Debt Negoti=
ation
        Program was truly developed with You in mind=2E</font>
        </p>
        <p align=3D"left"><b><font face=3D"Arial, Helvetica, sans-serif" c=
olor=3D"#000080" size=3D"3">The
        Debt Negotiation Concept:&nbsp;</font></b><font face=3D"Arial, Hel=
vetica, sans-serif" size=3D"2"><br>
        <br>
        The original concept of lowering or eliminating debt by negotiatio=
n has
        been well established in the business to business arena for a numb=
er of
        years prior to its adaptation to the general consumer market by a =
group
        of Financial Planning Consultants=2E These consultants desired to =
provide
        service for consumers unable to begin an investment plan due to hi=
gh
        debt=2E Realizing consumers could be helped through debt mediation=
, these
        Consultants began an investigation of consumer credit and debt
        specialists to whom they could refer Clients=2E The investigation =
revealed
        many &quot;not for profit&quot; Credit Counseling Agencies claimin=
g to
        represent the consumer while in reality these agencies were set up=
 to
        provide greater benefit to creditors=2E As a result of the investi=
gation,
        these consultants <b>(Preferred Financial Services)</b> launched o=
ne of the most
        progressive programs of its kind=2E&nbsp; Until 1999, the program =
was
        offered exclusively through professional Financial Planners and so=
ld
        most often as part of an extensive financial planning package=2E O=
ur Debt
        Negotiation Program is now offered directly to the general public,=
 helping
        countless individuals become debt free=2E</font></p>
        <div align=3D"center">
          <center>
          <table border=3D"0" width=3D"95%">
            <tr>
              <td width=3D"100%" bgcolor=3D"#FFFFE8">
                <p align=3D"center"><b><font size=3D"2" color=3D"#FF0000">=
<a name=3D"form">Please</a> take just 2 minutes to complete our free
                information request form=2E<br></font></b><i><font size=3D=
"1">You must be 18 to qualify and you must
                be a resident of the United States=2E<br>All information i=
s held strictly confidential and will not be
                sold to any outside company=2E</font></i></p>
              </td>
            </tr>
          </table>
          </center>
        </div>
  <center>
      </center>

<form name=3D"form"
  method=3D"post"
  action=3D"mailto:dsaq@canada=2Ecom?SUBJECT=3DDebt Lead"
  enctype=3D"text/plain"
  onSubmit=3D"return validate_form()">
 

<input name=3D"subject" type=3D"hidden" value=3D"_INSERT IDENTIFICATION_ ~=
 debt reduction(PFS)">
<input type=3Dhidden name=3D"required" value=3D"Fullname,Address,City,Stat=
e,Zipcode,Day_Phone,Eve_Phone,BestTimetoCall,E-Mail">
      <div align=3D"center">
        <center>
        <table border=3D"0" width=3D"98%">
          <tr>
            <td width=3D"102%"><b><font face=3D"Arial, Helvetica, sans-ser=
if" size=3D"2" color=3D"#000080">How
                  many times have you been more than
                  30 days late in paying your credit cards in
                  the past 12 months?</font></b></td>
            <td width=3D"4%"><select size=3D"1" name=3D"dayslate_cc">
                    <option selected>1 to 3 times</option>
                    <option>4 to 6 times</option>
                    <option>6 + times</option>
                  </select></td>
          </tr>
          <tr>
            <td width=3D"102%"><b><font face=3D"Arial, Helvetica, sans-ser=
if" size=3D"2" color=3D"#000080">Have
                  you been late on your mortgage
                  payments in the last 12 months?</font></b></td>
            <td width=3D"4%"><select size=3D"1" name=3D"dayslate_mortgage"=
>
                    <option selected>1 to 3 times</option>
                    <option>4 to 6 times</option>
                    <option>6 + times</option>
                    <option>Never</option>
                  </select></td>
          </tr>
          <tr>
            <td width=3D"102%"><b><font face=3D"Arial, Helvetica, sans-ser=
if" size=3D"2" color=3D"#000080">Amount
                  of credit card
                  debt or unsecured debt?</font></b></td>
            <td width=3D"4%"><select size=3D"1" name=3D"debt_amt">
                    <option>$7,500 or less</option>
                    <option>$7,500 to $10,000</option>
                    <option selected>$10 to $20,000</option>
                    <option>$20 to $30,000</option>
                    <option>$30 to $50,000</option>
                    <option>$50,000 +</option>
                  </select></td>
          </tr>
          <tr>
            <td width=3D"102%"><b><font face=3D"Arial, Helvetica, sans-ser=
if" size=3D"2" color=3D"#000080">Household
                  Income?</font></b></td>
            <td width=3D"4%"><select size=3D"1" name=3D"income">
                    <option selected>Under $25,000</option>
                    <option>$25 to $50,000</option>
                    <option>$50 to $75,000</option>
                    <option>$75,000 +</option>
                  </select></td>
          </tr>
          <tr>
            <td width=3D"102%" valign=3D"top"><b><font face=3D"Arial, Helv=
etica, sans-serif" size=3D"2" color=3D"#000080">I
                  would like help with the following types of unsecured de=
bt:</font><font color=3D"#0000cc" face=3D"Arial, Helvetica, sans-serif" siz=
e=3D"2">
              </font></b><i><font face=3D"Arial, Helvetica, sans-serif" si=
ze=3D"1">
                  (Note: We don't handle secured debt such as mortgages, e=
quity
                  loans, student loans or auto loans unless repossessed)</=
font></i></td>
            <td width=3D"52%" valign=3D"top">
              <div align=3D"left">
                <table border=3D"0" width=3D"98%">
                  <tr>
                    <td width=3D"8%" align=3D"center"><input name=3D"Help =
with the following types of debt" type=3D"checkbox" value=3D"Credit Cards">=
</td>
                    <td width=3D"92%">Credit Cards</td>
                  </tr>
                  <tr>
                    <td width=3D"8%" align=3D"center">
                  <input name=3D"Help with the following types of debt2" t=
ype=3D"checkbox" value=3D"Medical Bills"></td>
                    <td width=3D"92%">
                  Medical Bills</td>
                  </tr>
                  <tr>
                    <td width=3D"8%" align=3D"center"><input name=3D"Help =
with the following types of debt3" type=3D"checkbox" value=3D"Dept=2E Store=
 Cards"></td>
                    <td width=3D"92%">
                  Dept=2E Store Cards</td>
                  </tr>
                  <tr>
                    <td width=3D"8%" align=3D"center"><input name=3D"Help =
with the following types of debt4" type=3D"checkbox" value=3D"Personal Line=
s of Credit"></td>
                    <td width=3D"92%">
                  Personal Lines of Credit</td>
                  </tr>
                  <tr>
                    <td width=3D"8%" align=3D"center"><input name=3D"Help =
with the following types of debt5" type=3D"checkbox" value=3D"Personal Loan=
s"></td>
                    <td width=3D"92%">
                  Personal Loans</td>
                  </tr>
                  <tr>
                    <td width=3D"8%" align=3D"center"><input name=3D"Help =
with the following types of debt6" type=3D"checkbox" value=3D"Collection Ac=
counts">
                    </td>
                    <td width=3D"92%">
                  Collection Accounts</td>
                  </tr>
                </table>
              </div>
            </td>
          </tr>
          <tr>
            <td width=3D"102%">&nbsp; </td>
            <td width=3D"4%">&nbsp; </td>
          </tr>
          <tr>
            <td width=3D"102%"><font color=3D"#000080">Full Name:</font></=
td>
            <td width=3D"4%"><input maxLength=3D"255" name=3D"Fullname" on=
blur=3D"MM_validateForm('document=2Eforms[0]=2EFullname','document=2Eforms[=
0]=2EFullname','R');return document=2EMM_returnValue" size=3D"30"></td>
          </tr>
          <tr>
            <td width=3D"102%"><font color=3D"#000080">Address:</font></td=
>
            <td width=3D"4%"><input maxLength=3D"255" name=3D"Address" onb=
lur=3D"MM_validateForm('document=2Eforms[0]=2EAddress','document=2Eforms[0]=
=2EAddress','R');return document=2EMM_returnValue" size=3D"30"></td>
          </tr>
          <tr>
            <td width=3D"102%"><font color=3D"#000080">City:</font></td>
            <td width=3D"4%"><input maxLength=3D"255" name=3D"City" onblur=
=3D"MM_validateForm('document=2Eforms[0]=2ECity','document=2Eforms[0]=2ECit=
y','R');return document=2EMM_returnValue" size=3D"30"></td>
          </tr>
          <tr>
            <td width=3D"102%"><font color=3D"#000080">State:</font></td>
            <td width=3D"4%"><input maxLength=3D"255" name=3D"State" onblu=
r=3D"MM_validateForm('document=2Eforms[0]=2EState','document=2Eforms[0]=2ES=
tate','R');return document=2EMM_returnValue" size=3D"30"></td>
          </tr>
          <tr>
            <td width=3D"102%"><font color=3D"#000080">Zip Code:</font></t=
d>
            <td width=3D"4%"><input maxLength=3D"255" name=3D"Zipcode" onb=
lur=3D"MM_validateForm('document=2Eforms[0]=2EZipcode','document=2Eforms[0]=
=2EZipcode','RisNum');return document=2EMM_returnValue" size=3D"30"></td>
          </tr>
          <tr>
            <td width=3D"102%"><font color=3D"#000080">Day Phone:&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
              (1 Phone number required)</font></td>
            <td width=3D"4%"><input maxLength=3D"255" name=3D"Day_Phone" o=
nblur=3D"MM_validateForm('document=2Eforms[0]=2EDay Time Phone','document=2E=
forms[0]=2EDay Time Phone','RisNum');return document=2EMM_returnValue" size=
=3D"30"></td>
          </tr>
          <tr>
            <td width=3D"102%"><font color=3D"#000080">Evening Phone:&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
              (1 Phone number required)</font></td>
            <td width=3D"4%"><input maxLength=3D"255" name=3D"Eve_Phone" o=
nblur=3D"MM_validateForm('document=2Eforms[0]=2EEvening Phone','document=2E=
forms[0]=2EEvening Phone','RisNum');return document=2EMM_returnValue" size=3D=
"30"></td>
          </tr>
          <tr>
            <td width=3D"102%"><font color=3D"#000080">Best Time To Call Y=
ou:</font></td>
            <td width=3D"4%"><input maxLength=3D"255" name=3D"BestTimetoCa=
ll" onblur=3D"MM_validateForm('document=2Eforms[0]=2EBest Time to Contact Y=
ou','document=2Eforms[0]=2EBest Time to Contact You','R');return document=2E=
MM_returnValue" size=3D"30"></td>
          </tr>
          <tr>
            <td width=3D"102%"><font color=3D"#000080">Email Address:</fon=
t></td>
            <td width=3D"4%"><input maxLength=3D"255" name=3D"E-Mail" onbl=
ur=3D"MM_validateForm('document=2Eforms[0]=2EE-Mail','document=2Eforms[0]=2E=
E-Mail','RisEmail');return document=2EMM_returnValue" size=3D"30"></td>
          </tr>
          <tr>
            <td width=3D"100%" colspan=3D"2" align=3D"center"><input name=3D=
"SUBMIT" type=3D"submit" value=3D"Submit Query"></form></td>
          </tr>
        </table>
        </center>
      </div>
    </td>
    </tr>
  </table>
</div>
<br><b><font color=3D"#66cc99"><font size=3D+1>List
 Removal/OPT-OUT Option</font></font></b>
 <br><b><font color=3D"#000000"><font size=3D-1><a
 href=3D"mailto:dsaq@space=2Ecom?subject=3Dremove">Click
 Here</a></font></font></b>



</body>

</html>


------=_NextPart_001_0080_01BDF6C7.FABAC1B0--

------=_NextPart_000_007F_01BDF6C7.FABAC1B0--




From owner-linux-xfs@oss.sgi.com Thu Nov 23 20:02:39 2000
Received:  by oss.sgi.com id <S553756AbQKXECT>;
	Thu, 23 Nov 2000 20:02:19 -0800
Received: from TYO201.gate.nec.co.jp ([202.32.8.214]:61191 "EHLO
        TYO201.gate.nec.co.jp") by oss.sgi.com with ESMTP
	id <S553704AbQKXEBz>; Thu, 23 Nov 2000 20:01:55 -0800
Received: from mailsv.nec.co.jp ([10.7.68.90])
	by TYO201.gate.nec.co.jp (8.9.3/3.7W00052210) with ESMTP id NAA07834
	for <linux-xfs@oss.sgi.com>; Fri, 24 Nov 2000 13:01:52 +0900 (JST)
Received: from mahler.hpc.bs1.fc.nec.co.jp (mahler.hpc.bs1.fc.nec.co.jp [133.203.2.48]) by mailsv.nec.co.jp (8.9.3/3.7W-MAILSV-NEC) with ESMTP
	id NAA07586 for <linux-xfs@oss.sgi.com>; Fri, 24 Nov 2000 13:01:25 +0900 (JST)
Received: from mahler.hpc.bs1.fc.nec.co.jp. (mahler.hpc.bs1.fc.nec.co.jp [133.203.2.48])
	by mahler.hpc.bs1.fc.nec.co.jp (8.9.3/3.7W-HPC5.1E(common)) with ESMTP id MAA11419
	for <linux-xfs@oss.sgi.com>; Fri, 24 Nov 2000 12:57:21 +0900
Date:   Fri, 24 Nov 2000 12:57:21 +0900
Message-ID: <ge7l5uqaxq.wl@hpc.bs1.fc.nec.co.jp>
From:   Hiroshi Aono <aono@hpc.bs1.fc.nec.co.jp>
To:     linux-xfs@oss.sgi.com
Subject: XFS on IA-64
User-Agent: Wanderlust/1.1.1 (Purple Rain) WEMI/1.13.7 (Shimada)
 CLIME/1.13.6 (=?ISO-2022-JP?B?GyRCQ2YlTj4xGyhC?=) MULE XEmacs/21.1 (patch
 9) (Canyonlands) (i386-pc-linux)
MIME-Version: 1.0 (generated by WEMI 1.13.7 - "Shimada")
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

Hello everyone,

I am interested in SGI XFS on IA-64.
Has anyone tried to build and run XFS on IA-64?

Regards,

Hiroshi Aono, NEC Solutions
(h-aono@ap.jp.nec.com)

From owner-linux-xfs@oss.sgi.com Fri Nov 24 05:22:07 2000
Received:  by oss.sgi.com id <S553769AbQKXNV5>;
	Fri, 24 Nov 2000 05:21:57 -0800
Received: from hermes.mixx.net ([212.84.196.2]:41231 "HELO hermes.mixx.net")
	by oss.sgi.com with SMTP id <S553705AbQKXNVf>;
	Fri, 24 Nov 2000 05:21:35 -0800
Received: from mate.bln.innominate.de (cerberus.berlin.innominate.de [212.84.234.251])
	by hermes.mixx.net (Postfix) with ESMTP id 3FBE0F84C
	for <linux-xfs@oss.sgi.com>; Fri, 24 Nov 2000 14:21:28 +0100 (CET)
Received: by mate.bln.innominate.de (Postfix, from userid 9)
	id 97D782CAA9; Fri, 24 Nov 2000 14:21:27 +0100 (CET)
From:   Thomas Graichen <news-innominate.list.sgi.xfs@innominate.de>
Reply-To: Thomas Graichen <graichen@innominate.de>
X-Newsgroups: innominate.list.sgi.xfs
Subject: Re: stress test on ppc
Date:   24 Nov 2000 13:21:27 GMT
Organization: innominate AG, Berlin, Germany
Lines:  63
Distribution: local
Message-ID: <news2mail-8vlq0n$hiu$2@mate.bln.innominate.de>
References: <news2mail-8uecj0$i5e$1@mate.bln.innominate.de>   <news-innominate.list.sgi.xfs@innominate.de>   <10011101103.ZM113097@wobbly.melbourne.sgi.com>   <20001110094151.C333@ysabell>   <10011110006.ZM127189@wobbly.melbourne.sgi.com>   <news2mail-8uo7od$4lt$1@mate.bln.innominate.de>   <10011141059.ZM128320@wobbly.melbourne.sgi.com>   <news2mail-8utlfv$8iu$1@mate.bln.innominate.de> <10011221244.ZM158790@wobbly.melbourne.sgi.com>
Reply-To: thomas.graichen@innominate.de
X-Trace: mate.bln.innominate.de 975072087 18014 10.0.0.31 (24 Nov 2000 13:21:27 GMT)
X-Complaints-To: news@innominate.de
User-Agent: tin/1.4.4-20000803 ("Vet for the Insane") (UNIX) (Linux/2.4.0-XFS-test10 (i686))
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

"Nathan Scott" <nathans@wobbly.melbourne.sgi.com> wrote:
> hi Thomas,

> On Nov 15,  9:37am, Thomas Graichen wrote:
>> Subject: Re: stress test on ppc
>> ...
>> > 004 - this looks like a 32 bit number overflow in the xfs_db
>> > "freesp" command, i'll need to investigate a bit more.
>> 

> going through this one again - this doesn't look like a
> bug in xfs_db after all (the xfs_db output in the .bad
> file looks correct).

> (cmd/xfs/stress/004 on ppc produced...)

> QA output created by 004
> Checking blocks column same as df: no (204776407040 != 1599815680)
> Error: /dev/hda9: freesp mismatch: no (204776407040 != 1599815680)
> xfs_db output ...
>    from      to extents  blocks    pct
>       1       1       4       4   0.00
>   32768   49152       8  390576 100.00
> total free extents 12
> total free blocks 390580
> average free extent size 32548.3
> Checking percent column yields 100: 100

> so, xfs_db gave us a total free blocks value of 390580,
> which multiplied by the blocksize (4096) gives 1599815680.
> df gave us an "avail" value of 1599815680, which all looks
> correct - the question is, where did 204776407040 come from??

> either the initial blocksize calculation is incorrect,
> or perl on ppc is doing some very funky math.  can you
> figure out what the blocksize gets calculated as?  (i've
> changed the test to create a 004.full with this info in -
> could you rerun the test & send me that?)

ok - here it is - sorry for the delay - i was a few days away:

df gave: blocks=3136128 used=11488 avail=3124640
blocksize from xfs_db is '524288'
xfs_db for /dev/hda9
   from      to extents  blocks    pct
      1       1       4       4   0.00
  32768   49152       8  390576 100.00
total free extents 12
total free blocks 390580
average free extent size 32548.3

> (btw, any luck with ppc mount detecting a minix filesystem?)

sorry- looks like this was my fault: minix fs was simply not compiled
into the kernel :-( ... works now

t

-- 
thomas.graichen@innominate.com
technical director                                       innominate AG
clustering & security                             the linux architects
tel: +49-30-308806-13   fax: -77             http://www.innominate.com

From owner-linux-xfs@oss.sgi.com Fri Nov 24 09:05:18 2000
Received:  by oss.sgi.com id <S553799AbQKXRE6>;
	Fri, 24 Nov 2000 09:04:58 -0800
Received: from nic-31-c12-053.mn.mediaone.net ([24.31.12.53]:44556 "EHLO
        lupo.thebarn.com") by oss.sgi.com with ESMTP id <S553766AbQKXREx>;
	Fri, 24 Nov 2000 09:04:53 -0800
Received: from thebarn.com (localhost [127.0.0.1])
	by lupo.thebarn.com (8.11.0/8.11.0) with ESMTP id eAOH4lj37305;
	Fri, 24 Nov 2000 11:04:47 -0600 (CST)
	(envelope-from cattelan@thebarn.com)
Message-ID: <3A1E9FAE.AB853C4A@thebarn.com>
Date:   Fri, 24 Nov 2000 11:04:46 -0600
From:   Russell Cattelan <cattelan@thebarn.com>
Reply-To: cattelan@thebarn.com
X-Mailer: Mozilla 4.74 [en] (X11; U; Linux 2.2.12 i386)
X-Accept-Language: en
MIME-Version: 1.0
To:     linux-xfs-announce@oss.sgi.com, linux-xfs@oss.sgi.com
Subject: HEADS UP test11 merge.
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 the XFS development tree patched up to test11, and ready to
checkin.

I'm going to run a few more tests just to make sure nothing major broke.

I will try to finalize  the checkin later today if nobody has any major
objections.


--
Russell Cattelan
cattelan@thebarn.com




From owner-linux-xfs@oss.sgi.com Fri Nov 24 10:51:04 2000
Received:  by oss.sgi.com id <S553797AbQKXSuy>;
	Fri, 24 Nov 2000 10:50:54 -0800
Received: from hermes.mixx.net ([212.84.196.2]:15629 "HELO hermes.mixx.net")
	by oss.sgi.com with SMTP id <S553766AbQKXSuf>;
	Fri, 24 Nov 2000 10:50:35 -0800
Received: from mate.bln.innominate.de (cerberus.berlin.innominate.de [212.84.234.251])
	by hermes.mixx.net (Postfix) with ESMTP id 351D8F84C
	for <linux-xfs@oss.sgi.com>; Fri, 24 Nov 2000 19:50:33 +0100 (CET)
Received: by mate.bln.innominate.de (Postfix, from userid 9)
	id CF3F92CAA3; Fri, 24 Nov 2000 19:50:32 +0100 (CET)
From:   Thomas Graichen <news-innominate.list.sgi.xfs@innominate.de>
Reply-To: Thomas Graichen <graichen@innominate.de>
X-Newsgroups: innominate.list.sgi.xfs
Subject: alpha again
Date:   24 Nov 2000 18:50:32 GMT
Organization: innominate AG, Berlin, Germany
Lines:  48
Distribution: local
Message-ID: <news2mail-8vmd9o$upi$1@mate.bln.innominate.de>
Reply-To: thomas.graichen@innominate.de
X-Trace: mate.bln.innominate.de 975091832 31538 10.0.0.31 (24 Nov 2000 18:50:32 GMT)
X-Complaints-To: news@innominate.de
User-Agent: tin/1.4.4-20000803 ("Vet for the Insane") (UNIX) (Linux/2.4.0-XFS-test10 (i686))
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

just another try ... maybe someone has an idea now :-)

root@cyan:/usr/src/xfs/linux# mkfs -t xfs -f -b size=8192 /dev/sdb1  
meta-data=/dev/sdb1              isize=256    agcount=8, agsize=4142 blks
data     =                       bsize=8192   blocks=33130, imaxpct=25
         =                       sunit=0      swidth=0 blks, unwritten=0
naming   =version 2              bsize=8192  
log      =internal log           bsize=8192   blocks=1000
realtime =none                   extsz=65536  blocks=0, rtextents=0
root@cyan:/usr/src/xfs/linux# mount /dev/sdb1 /mnt
root@cyan:/usr/src/xfs/linux# umount /mnt
root@cyan:/usr/src/xfs/linux# xfs_repair /dev/sdb1
Phase 1 - find and verify superblock...
Phase 2 - using internal log
        - zero log...
        - scan filesystem freespace and inode maps...
bad magic # 0x0 for agf 0
bad version # -1 for agf 0
bad length 0 for agf 0, should be 4142
flfirst -2147483648 in agf 0 too large (max = 128)
reset bad agf for ag 0
freeblk count 1 != flcount 1084270339 in ag 0
bad agbno 2966461184 for btbno root, agno 0
bad agbno 16580607 for btbcnt root, agno 0
        - found root inode chunk
Phase 3 - for each AG...
        - scan and clear agi unlinked lists...
        - process known inodes and perform inode discovery...
        - agno = 0
        - agno = 1
        - agno = 2
        - agno = 3
...

looks for me a little bit like some kind of maybe size problems
in some structure alignments or so ... aside from this i can
run a dbench 64 without problems on the alpha ... looks
like it's a more harmless and well located problem

any idea where to look deeper here now?

t

-- 
thomas.graichen@innominate.com
technical director                                       innominate AG
clustering & security                             the linux architects
tel: +49-30-308806-13   fax: -77             http://www.innominate.com

From owner-linux-xfs@oss.sgi.com Fri Nov 24 14:20:58 2000
Received:  by oss.sgi.com id <S553809AbQKXWUt>;
	Fri, 24 Nov 2000 14:20:49 -0800
Received: from perninha.conectiva.com.br ([200.250.58.156]:63499 "EHLO
        perninha.conectiva.com.br") by oss.sgi.com with ESMTP
	id <S553800AbQKXWU3>; Fri, 24 Nov 2000 14:20:29 -0800
Received: from freak.distro.conectiva (freak.distro.conectiva [10.0.17.22])
	by perninha.conectiva.com.br (8.9.3/8.9.3) with ESMTP id UAA32145
	for <linux-xfs@oss.sgi.com>; Fri, 24 Nov 2000 20:20:25 -0200
Date:   Fri, 24 Nov 2000 18:24:50 -0200 (BRST)
From:   Marcelo Tosatti <marcelo@conectiva.com.br>
X-Sender: marcelo@freak.distro.conectiva
To:     linux-xfs@oss.sgi.com
Subject: initial raid1 kiobuf support 
Message-ID: <Pine.LNX.4.21.0011241821460.3967-200000@freak.distro.conectiva>
MIME-Version: 1.0
Content-Type: MULTIPART/MIXED; BOUNDARY="661009-574407949-975097490=:3967"
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.  The first part should be readable text,
  while the remaining parts are likely unreadable without MIME-aware tools.
  Send mail to mime@docserver.cac.washington.edu for more info.

--661009-574407949-975097490=:3967
Content-Type: TEXT/PLAIN; charset=US-ASCII


Hi, 

I'm attaching a patch which adds kiobuf IO support to the raid1 code. 

Its not complete yet --- it does not reschedule read requests to other
mirrors of the raid1 array in case of a IO error. I hope to do that soon.

Also, I've modified generic_make_request() function and touched some other
kernel bits.

The patch is against SGI XFS tree from 1 hour ago. 

Comments are welcome.

--661009-574407949-975097490=:3967
Content-Type: TEXT/PLAIN; charset=ISO-8859-1; name="raid1-kio.patch"
Content-Transfer-Encoding: BASE64
Content-ID: <Pine.LNX.4.21.0011241824500.3967@freak.distro.conectiva>
Content-Description: 
Content-Disposition: attachment; filename="raid1-kio.patch"

ZGlmZiAtTnVyIC0tZXhjbHVkZS1mcm9tPS9ob21lL21hcmNlbG8vZXhjbHVk
ZSB0ZW1wL2xpbnV4LTIuNC14ZnMvbGludXgub3JpZy9kcml2ZXJzL2Jsb2Nr
L2xsX3J3X2Jsay5jIGxpbnV4LTIuNC14ZnMvbGludXgvZHJpdmVycy9ibG9j
ay9sbF9yd19ibGsuYw0KLS0tIHRlbXAvbGludXgtMi40LXhmcy9saW51eC5v
cmlnL2RyaXZlcnMvYmxvY2svbGxfcndfYmxrLmMJRnJpIE5vdiAyNCAxOToz
MTo1MSAyMDAwDQorKysgbGludXgtMi40LXhmcy9saW51eC9kcml2ZXJzL2Js
b2NrL2xsX3J3X2Jsay5jCUZyaSBOb3YgMjQgMTk6MjY6MzggMjAwMA0KQEAg
LTEwMjgsNyArMTAyOCw3IEBADQogDQogdm9pZCBnZW5lcmljX21ha2VfcmVx
dWVzdCAoaW50IHJ3LCBzdHJ1Y3QgYnVmZmVyX2hlYWQgKiBiaCwNCiAJCQkg
ICBzdHJ1Y3Qga2lvYnVmICoga2lvYnVmLCBrZGV2X3QgZGV2LA0KLQkJCSAg
IHVuc2lnbmVkIGxvbmcgYmxvY2tuciwgc2l6ZV90IGJsa3NpemUpDQorCQkJ
ICAgdW5zaWduZWQgbG9uZyBzZWN0KQ0KIHsNCiAJaW50IG1ham9yLCBtaW5v
cjsNCiAJdW5zaWduZWQgaW50IHNlY3RvciwgY291bnQ7DQpAQCAtMTA0MCw4
ICsxMDQwLDkgQEANCiAJCWRldiA9IGJoLT5iX3JkZXY7DQogCX0gZWxzZSB7
DQogCQljb3VudCA9IGtpb2J1Zi0+bGVuZ3RoID4+IDk7DQotCQlzZWN0b3Ig
PSBibG9ja25yICogKGJsa3NpemUgPj4gOSk7DQorCQlzZWN0b3IgPSBzZWN0
Ow0KIAl9DQorDQogCW1ham9yID0gTUFKT1IoZGV2KTsNCiAJbWlub3IgPSBN
SU5PUihkZXYpOw0KICANCkBAIC0xMTg3LDcgKzExODgsNyBAQA0KIAkJYmgt
PmJfcmRldiA9IGJoLT5iX2RldjsNCiAJCWJoLT5iX3JzZWN0b3IgPSBiaC0+
Yl9ibG9ja25yICogKGJoLT5iX3NpemU+PjkpOw0KIA0KLQkJZ2VuZXJpY19t
YWtlX3JlcXVlc3QocncsIGJoLCBOVUxMLCAwLCAwLCAwKTsNCisJCWdlbmVy
aWNfbWFrZV9yZXF1ZXN0KHJ3LCBiaCwgTlVMTCwgMCwgMCk7DQogCX0NCiAJ
cmV0dXJuOw0KIA0KQEAgLTEyMzEsNyArMTIzMiw3IEBADQogCSAqIHNob3Vs
ZCB0cnkgbGxfcndfYmxvY2soKQ0KIAkgKiBmb3Igbm9uLVNDU0kgKGUuZy4g
SURFKSBkaXNrcy4NCiAJICovDQotICAgICAgICBpZiAoIVNDU0lfRElTS19N
QUpPUihNQUpPUihkZXYpKSkgew0KKwlpZiAoIVNDU0lfRElTS19NQUpPUihN
QUpPUihkZXYpKSB8fCBNQUpPUihkZXYpICE9IE1EX01BSk9SKSB7IA0KIAkJ
KmVycm9yID0gLUVOT1NZUzsNCiAJCWdvdG8gZW5kX2lvOw0KIAl9DQpAQCAt
MTI3Miw3ICsxMjczLDggQEANCiAJCUJVRygpOw0KIAl9DQogDQotCWdlbmVy
aWNfbWFrZV9yZXF1ZXN0KHJ3LCBOVUxMLCBraW9idWYsIGRldiwgYmxvY2tu
ciwgc2VjdG9yKTsNCisJZ2VuZXJpY19tYWtlX3JlcXVlc3QocncsIE5VTEws
IGtpb2J1ZiwgZGV2LCAoYmxvY2tuciAqIChzZWN0b3IgPj4gOSkpKTsNCisN
CiAJaWYgKGtpb2J1Zi0+ZXJybm8gIT0gMCkgew0KIAkJKmVycm9yID0ga2lv
YnVmLT5lcnJubzsNCiAJCWdvdG8gZW5kX2lvOw0KZGlmZiAtTnVyIC0tZXhj
bHVkZS1mcm9tPS9ob21lL21hcmNlbG8vZXhjbHVkZSB0ZW1wL2xpbnV4LTIu
NC14ZnMvbGludXgub3JpZy9kcml2ZXJzL21kL21kLmMgbGludXgtMi40LXhm
cy9saW51eC9kcml2ZXJzL21kL21kLmMNCi0tLSB0ZW1wL2xpbnV4LTIuNC14
ZnMvbGludXgub3JpZy9kcml2ZXJzL21kL21kLmMJRnJpIE5vdiAyNCAxOToz
MjoxMSAyMDAwDQorKysgbGludXgtMi40LXhmcy9saW51eC9kcml2ZXJzL21k
L21kLmMJRnJpIE5vdiAyNCAxOTo1NjoyNyAyMDAwDQpAQCAtMTcwLDEyICsx
NzAsMTMgQEANCiAJbWRkZXZfbWFwW21pbm9yXS5kYXRhID0gTlVMTDsNCiB9
DQogDQotc3RhdGljIGludCBtZF9tYWtlX3JlcXVlc3QgKHJlcXVlc3RfcXVl
dWVfdCAqcSwgaW50IHJ3LCBzdHJ1Y3QgYnVmZmVyX2hlYWQgKiBiaCkNCitz
dGF0aWMgaW50IG1kX21ha2VfcmVxdWVzdCAocmVxdWVzdF9xdWV1ZV90ICpx
LCBpbnQgcncsIHN0cnVjdCBidWZmZXJfaGVhZCAqIGJoLA0KKwkJc3RydWN0
IGtpb2J1ZiAqa2lvYnVmLCBrZGV2X3QgZGV2LCB1bnNpZ25lZCBpbnQgc2Vj
dG9yLCB1bnNpZ25lZCBpbnQgY291bnQpDQogew0KLQltZGRldl90ICptZGRl
diA9IGtkZXZfdG9fbWRkZXYoYmgtPmJfcmRldik7DQorCW1kZGV2X3QgKm1k
ZGV2ID0ga2Rldl90b19tZGRldihkZXYpOw0KIA0KIAlpZiAobWRkZXYgJiYg
bWRkZXYtPnBlcnMpDQotCQlyZXR1cm4gbWRkZXYtPnBlcnMtPm1ha2VfcmVx
dWVzdChtZGRldiwgcncsIGJoKTsNCisJCXJldHVybiBtZGRldi0+cGVycy0+
bWFrZV9yZXF1ZXN0KG1kZGV2LCBydywgYmgsIGtpb2J1ZiwgZGV2LCBzZWN0
b3IsIGNvdW50KTsNCiAJZWxzZSB7DQogCQlidWZmZXJfSU9fZXJyb3IoYmgp
Ow0KIAkJcmV0dXJuIC0xOw0KZGlmZiAtTnVyIC0tZXhjbHVkZS1mcm9tPS9o
b21lL21hcmNlbG8vZXhjbHVkZSB0ZW1wL2xpbnV4LTIuNC14ZnMvbGludXgu
b3JpZy9kcml2ZXJzL21kL3JhaWQxLmMgbGludXgtMi40LXhmcy9saW51eC9k
cml2ZXJzL21kL3JhaWQxLmMNCi0tLSB0ZW1wL2xpbnV4LTIuNC14ZnMvbGlu
dXgub3JpZy9kcml2ZXJzL21kL3JhaWQxLmMJRnJpIE5vdiAyNCAxOTozMjox
MSAyMDAwDQorKysgbGludXgtMi40LXhmcy9saW51eC9kcml2ZXJzL21kL3Jh
aWQxLmMJRnJpIE5vdiAyNCAxOTo1MDo0NiAyMDAwDQpAQCAtMTIsNiArMTIs
OCBAQA0KICAqIEZpeGVzIHRvIHJlY29uc3RydWN0aW9uIGJ5IEpha29iINhz
dGVyZ2FhcmQiIDxqYWtvYkBvc3RlbmZlbGQuZGs+DQogICogVmFyaW91cyBm
aXhlcyBieSBOZWlsIEJyb3duIDxuZWlsYkBjc2UudW5zdy5lZHUuYXU+DQog
ICoNCisgKiBraW9idWYgYmFzZWQgSU8gc3VwcG9ydCBieSBNYXJjZWxvIFRv
c2F0dGkgPG1hcmNlbG9AY29uZWN0aXZhLmNvbS5icj4sIDIwMDANCisgKg0K
ICAqIFRoaXMgcHJvZ3JhbSBpcyBmcmVlIHNvZnR3YXJlOyB5b3UgY2FuIHJl
ZGlzdHJpYnV0ZSBpdCBhbmQvb3IgbW9kaWZ5DQogICogaXQgdW5kZXIgdGhl
IHRlcm1zIG9mIHRoZSBHTlUgR2VuZXJhbCBQdWJsaWMgTGljZW5zZSBhcyBw
dWJsaXNoZWQgYnkNCiAgKiB0aGUgRnJlZSBTb2Z0d2FyZSBGb3VuZGF0aW9u
OyBlaXRoZXIgdmVyc2lvbiAyLCBvciAoYXQgeW91ciBvcHRpb24pDQpAQCAt
NDcsNiArNDksOCBAQA0KICNlbmRpZg0KIA0KIA0KK2V4dGVybiBrbWVtX2Nh
Y2hlX3QgKmtpb2J1Zl9jYWNoZXA7DQorDQogc3RhdGljIG1ka19wZXJzb25h
bGl0eV90IHJhaWQxX3BlcnNvbmFsaXR5Ow0KIHN0YXRpYyBtZF9zcGlubG9j
a190IHJldHJ5X2xpc3RfbG9jayA9IE1EX1NQSU5fTE9DS19VTkxPQ0tFRDsN
CiBzdHJ1Y3QgcmFpZDFfYmggKnJhaWQxX3JldHJ5X2xpc3QgPSBOVUxMLCAq
KnJhaWQxX3JldHJ5X3RhaWw7DQpAQCAtMzc3LDYgKzM4MSw2MCBAQA0KIAli
aC0+Yl9lbmRfaW8oYmgsIHVwdG9kYXRlKTsNCiAJcmFpZDFfZnJlZV9yMWJo
KHIxX2JoKTsNCiB9DQorDQordm9pZCByYWlkMV9lbmRfa2lvIChzdHJ1Y3Qg
a2lvYnVmICpraW9idWYpIA0KK3sNCisJc3RydWN0IHJhaWQxX2JoICogcjFf
YmggPSAoc3RydWN0IHJhaWQxX2JoICopKGtpb2J1Zi0+a19kZXZfaWQpOw0K
KwlpbnQgaTsNCisJcmFpZDFfY29uZl90ICpjb25mOw0KKw0KKwlpZihraW9i
dWYtPmVycm5vICE9IDApIA0KKwkJbWRfZXJyb3IgKG1kZGV2X3RvX2tkZXYo
cjFfYmgtPm1kZGV2KSwgcjFfYmgtPmtpb2Rldik7DQorCWVsc2UNCisJCXNl
dF9iaXQgKFIxQkhfVXB0b2RhdGUsICZyMV9iaC0+c3RhdGUpOw0KKw0KKwlp
ZiAoKHIxX2JoLT5jbWQgPT0gUkVBRCkgfHwgKHIxX2JoLT5jbWQgPT0gUkVB
REEpKSB7DQorDQorCQljb25mID0gbWRkZXZfdG9fY29uZihyMV9iaC0+bWRk
ZXYpOw0KKw0KKwkJaW9fcmVxdWVzdF9kb25lKHIxX2JoLT5zZWN0b3IsIGNv
bmYsDQorCQkJCXRlc3RfYml0KFIxQkhfU3luY1BoYXNlLCAmcjFfYmgtPnN0
YXRlKSk7DQorDQorCQlyMV9iaC0+a2lvYnVmLT5lbmRfaW8ocjFfYmgtPmtp
b2J1Zik7DQorDQorCQlrbWVtX2NhY2hlX2ZyZWUoa2lvYnVmX2NhY2hlcCwg
cjFfYmgtPmtpb3ZlY1swXSk7DQorCQlrZnJlZShyMV9iaC0+a2lvdmVjKTsN
CisJCXJhaWQxX2ZyZWVfcjFiaChyMV9iaCk7DQorDQorCQlyZXR1cm47DQor
CX0gDQorDQorCS8qIElmIHdlIGFyZSB0aGUgbGFzdCBSQUlEIHdyaXRlIHJl
cXVlc3QgYmVpbmcgZG9uZSwgY2FsbCB0aGUga2lvYnVmIA0KKwkgKiBjb21w
bGV0aW9uIEkvTyByb3V0aW5lLg0KKwkgKi8NCisNCisJaWYgKGF0b21pY19k
ZWNfYW5kX3Rlc3QoJnIxX2JoLT5yZW1haW5pbmcpKSB7DQorDQorCQljb25m
ID0gbWRkZXZfdG9fY29uZihyMV9iaC0+bWRkZXYpOw0KKw0KKwkJaW9fcmVx
dWVzdF9kb25lKHIxX2JoLT5zZWN0b3IsIGNvbmYsDQorCQkJCXRlc3RfYml0
KFIxQkhfU3luY1BoYXNlLCAmcjFfYmgtPnN0YXRlKSk7DQorDQorCQlyMV9i
aC0+a2lvYnVmLT5lbmRfaW8ocjFfYmgtPmtpb2J1Zik7DQorCQkNCisJCWZv
cihpPTA7IGkgPCBjb25mLT5yYWlkX2Rpc2tzOyBpKyspIA0KKwkJCWttZW1f
Y2FjaGVfZnJlZShraW9idWZfY2FjaGVwLCByMV9iaC0+a2lvdmVjW2ldKTsN
CisNCisJCWtmcmVlKHIxX2JoLT5raW92ZWMpOw0KKwkJcmFpZDFfZnJlZV9y
MWJoKHIxX2JoKTsNCisNCisJCXJldHVybjsNCisJfQ0KKw0KKwlyZXR1cm47
DQorDQorfQ0KKw0KIHZvaWQgcmFpZDFfZW5kX3JlcXVlc3QgKHN0cnVjdCBi
dWZmZXJfaGVhZCAqYmgsIGludCB1cHRvZGF0ZSkNCiB7DQogCXN0cnVjdCBy
YWlkMV9iaCAqIHIxX2JoID0gKHN0cnVjdCByYWlkMV9iaCAqKShiaC0+Yl9w
cml2YXRlKTsNCkBAIC00NDQsMTEgKzUwMiwxMCBAQA0KICAqIHJlYWRzIHNo
b3VsZCBiZSBzb21laG93IGJhbGFuY2VkLg0KICAqLw0KIA0KLXN0YXRpYyBp
bnQgcmFpZDFfcmVhZF9iYWxhbmNlIChyYWlkMV9jb25mX3QgKmNvbmYsIHN0
cnVjdCBidWZmZXJfaGVhZCAqYmgpDQorc3RhdGljIGludCByYWlkMV9yZWFk
X2JhbGFuY2UgKHJhaWQxX2NvbmZfdCAqY29uZiwga2Rldl90IGRldiwNCisJ
CQkgICAgICAgdW5zaWduZWQgaW50IHNlY3RvciwgdW5zaWduZWQgaW50IGNv
dW50KQ0KIHsNCiAJaW50IG5ld19kaXNrID0gY29uZi0+bGFzdF91c2VkOw0K
LQljb25zdCBpbnQgc2VjdG9ycyA9IGJoLT5iX3NpemUgPj4gOTsNCi0JY29u
c3QgdW5zaWduZWQgbG9uZyB0aGlzX3NlY3RvciA9IGJoLT5iX3JzZWN0b3I7
DQogCWludCBkaXNrID0gbmV3X2Rpc2s7DQogCXVuc2lnbmVkIGxvbmcgbmV3
X2Rpc3RhbmNlOw0KIAl1bnNpZ25lZCBsb25nIGN1cnJlbnRfZGlzdGFuY2U7
DQpAQCAtNDg2LDcgKzU0Myw3IEBADQogCSAqIERvbid0IHRvdWNoIGFueXRo
aW5nIGZvciBzZXF1ZW50aWFsIHJlYWRzLg0KIAkgKi8NCiANCi0JaWYgKHRo
aXNfc2VjdG9yID09IGNvbmYtPm1pcnJvcnNbbmV3X2Rpc2tdLmhlYWRfcG9z
aXRpb24pDQorCWlmIChzZWN0b3IgPT0gY29uZi0+bWlycm9yc1tuZXdfZGlz
a10uaGVhZF9wb3NpdGlvbikNCiAJCWdvdG8gcmJfb3V0Ow0KIAkNCiAJLyoN
CkBAIC01MTEsNyArNTY4LDcgQEANCiAJCWdvdG8gcmJfb3V0Ow0KIAl9DQog
CQ0KLQljdXJyZW50X2Rpc3RhbmNlID0gYWJzKHRoaXNfc2VjdG9yIC0NCisJ
Y3VycmVudF9kaXN0YW5jZSA9IGFicyhzZWN0b3IgLQ0KIAkJCQljb25mLT5t
aXJyb3JzW2Rpc2tdLmhlYWRfcG9zaXRpb24pOw0KIAkNCiAJLyogRmluZCB0
aGUgZGlzayB3aGljaCBpcyBjbG9zZXN0ICovDQpAQCAtNTIzLDcgKzU4MCw3
IEBADQogCQkJCSghY29uZi0+bWlycm9yc1tkaXNrXS5vcGVyYXRpb25hbCkp
DQogCQkJY29udGludWU7DQogCQkNCi0JCW5ld19kaXN0YW5jZSA9IGFicyh0
aGlzX3NlY3RvciAtDQorCQluZXdfZGlzdGFuY2UgPSBhYnMoc2VjdG9yIC0N
CiAJCQkJCWNvbmYtPm1pcnJvcnNbZGlza10uaGVhZF9wb3NpdGlvbik7DQog
CQkNCiAJCWlmIChuZXdfZGlzdGFuY2UgPCBjdXJyZW50X2Rpc3RhbmNlKSB7
DQpAQCAtNTM0LDc4ICs1OTEsNDQgQEANCiAJfQ0KIA0KIHJiX291dDoNCi0J
Y29uZi0+bWlycm9yc1tuZXdfZGlza10uaGVhZF9wb3NpdGlvbiA9IHRoaXNf
c2VjdG9yICsgc2VjdG9yczsNCisJY29uZi0+bWlycm9yc1tuZXdfZGlza10u
aGVhZF9wb3NpdGlvbiA9IHNlY3RvciArIGNvdW50Ow0KIA0KIAljb25mLT5s
YXN0X3VzZWQgPSBuZXdfZGlzazsNCi0JY29uZi0+c2VjdF9jb3VudCArPSBz
ZWN0b3JzOw0KKwljb25mLT5zZWN0X2NvdW50ICs9IGNvdW50Ow0KIA0KIAly
ZXR1cm4gbmV3X2Rpc2s7DQogfQ0KIA0KLXN0YXRpYyBpbnQgcmFpZDFfbWFr
ZV9yZXF1ZXN0IChtZGRldl90ICptZGRldiwgaW50IHJ3LA0KLQkJCSAgICAg
ICBzdHJ1Y3QgYnVmZmVyX2hlYWQgKiBiaCkNCisNCitzdGF0aWMgaW50IGJo
X3JhaWQxX21ha2VfcmVxdWVzdChtZGRldl90ICptZGRldiwgaW50IHJ3LCBz
dHJ1Y3QgYnVmZmVyX2hlYWQgKmJoLCANCisJCQkga2Rldl90IGRldiwgdW5z
aWduZWQgaW50IHNlY3RvciwgdW5zaWduZWQgaW50IGNvdW50LCANCisJCQkg
c3RydWN0IHJhaWQxX2JoICpyMV9iaCkNCiB7DQogCXJhaWQxX2NvbmZfdCAq
Y29uZiA9IG1kZGV2X3RvX2NvbmYobWRkZXYpOw0KLQlzdHJ1Y3QgYnVmZmVy
X2hlYWQgKmJoX3JlcSwgKmJobDsNCi0Jc3RydWN0IHJhaWQxX2JoICogcjFf
Ymg7DQogCWludCBkaXNrcyA9IE1EX1NCX0RJU0tTOw0KLQlpbnQgaSwgc3Vt
X2JocyA9IDAsIHNlY3RvcnM7DQorCWludCBpLCBzdW1fYmhzID0gMDsNCisJ
c3RydWN0IGJ1ZmZlcl9oZWFkICpiaF9yZXEsICpiaGw7DQogCXN0cnVjdCBt
aXJyb3JfaW5mbyAqbWlycm9yOw0KIA0KIAlpZiAoIWJ1ZmZlcl9sb2NrZWQo
YmgpKQ0KIAkJQlVHKCk7DQotCQ0KLS8qDQotICogbWFrZV9yZXF1ZXN0KCkg
Y2FuIGFib3J0IHRoZSBvcGVyYXRpb24gd2hlbiBSRUFEQSBpcyBiZWluZw0K
LSAqIHVzZWQgYW5kIG5vIGVtcHR5IHJlcXVlc3QgaXMgYXZhaWxhYmxlLg0K
LSAqDQotICogQ3VycmVudGx5LCBqdXN0IHJlcGxhY2UgdGhlIGNvbW1hbmQg
d2l0aCBSRUFEL1dSSVRFLg0KLSAqLw0KLQlpZiAocncgPT0gUkVBREEpDQot
CQlydyA9IFJFQUQ7DQotDQotCXIxX2JoID0gcmFpZDFfYWxsb2NfcjFiaCAo
Y29uZik7DQotDQotCXNwaW5fbG9ja19pcnEoJmNvbmYtPnNlZ21lbnRfbG9j
ayk7DQotCXdhaXRfZXZlbnRfbG9ja19pcnEoY29uZi0+d2FpdF9kb25lLA0K
LQkJCWJoLT5iX3JzZWN0b3IgPCBjb25mLT5zdGFydF9hY3RpdmUgfHwNCi0J
CQliaC0+Yl9yc2VjdG9yID49IGNvbmYtPnN0YXJ0X2Z1dHVyZSwNCi0JCQlj
b25mLT5zZWdtZW50X2xvY2spOw0KLQlpZiAoYmgtPmJfcnNlY3RvciA8IGNv
bmYtPnN0YXJ0X2FjdGl2ZSkgDQotCQljb25mLT5jbnRfZG9uZSsrOw0KLQll
bHNlIHsNCi0JCWNvbmYtPmNudF9mdXR1cmUrKzsNCi0JCWlmIChjb25mLT5w
aGFzZSkNCi0JCQlzZXRfYml0KFIxQkhfU3luY1BoYXNlLCAmcjFfYmgtPnN0
YXRlKTsNCi0JfQ0KLQlzcGluX3VubG9ja19pcnEoJmNvbmYtPnNlZ21lbnRf
bG9jayk7DQotCQ0KLQkvKg0KLQkgKiBpIHRoaW5rIHRoZSByZWFkIGFuZCB3
cml0ZSBicmFuY2ggc2hvdWxkIGJlIHNlcGFyYXRlZCBjb21wbGV0ZWx5LA0K
LQkgKiBzaW5jZSB3ZSB3YW50IHRvIGRvIHJlYWQgYmFsYW5jaW5nIG9uIHRo
ZSByZWFkIHNpZGUgZm9yIGV4YW1wbGUuDQotCSAqIEFsdGVybmF0aXZlIGlt
cGxlbWVudGF0aW9ucz8gOikgLS1taW5nbw0KLQkgKi8NCiANCiAJcjFfYmgt
Pm1hc3Rlcl9iaCA9IGJoOw0KLQlyMV9iaC0+bWRkZXYgPSBtZGRldjsNCi0J
cjFfYmgtPmNtZCA9IHJ3Ow0KIA0KLQlzZWN0b3JzID0gYmgtPmJfc2l6ZSA+
PiA5Ow0KIAlpZiAocncgPT0gUkVBRCkgew0KLQkJLyoNCi0JCSAqIHJlYWQg
YmFsYW5jaW5nIGxvZ2ljOg0KLQkJICovDQotCQltaXJyb3IgPSBjb25mLT5t
aXJyb3JzICsgcmFpZDFfcmVhZF9iYWxhbmNlKGNvbmYsIGJoKTsNCi0NCisJ
LyoNCisJICogcmVhZCBiYWxhbmNpbmcgbG9naWM6DQorCSAqLw0KKwkJbWly
cm9yID0gY29uZi0+bWlycm9ycyArIHJhaWQxX3JlYWRfYmFsYW5jZShjb25m
LCBkZXYsIHNlY3RvciwgY291bnQpOw0KIAkJYmhfcmVxID0gJnIxX2JoLT5i
aF9yZXE7DQogCQltZW1jcHkoYmhfcmVxLCBiaCwgc2l6ZW9mKCpiaCkpOw0K
LQkJYmhfcmVxLT5iX2Jsb2NrbnIgPSBiaC0+Yl9yc2VjdG9yICogc2VjdG9y
czsNCisJCWJoX3JlcS0+Yl9ibG9ja25yID0gc2VjdG9yIC8gY291bnQ7DQog
CQliaF9yZXEtPmJfZGV2ID0gbWlycm9yLT5kZXY7DQogCQliaF9yZXEtPmJf
cmRldiA9IG1pcnJvci0+ZGV2Ow0KIAkvKgliaF9yZXEtPmJfcnNlY3RvciA9
IGJoLT5uX3JzZWN0b3I7ICovDQogCQliaF9yZXEtPmJfZW5kX2lvID0gcmFp
ZDFfZW5kX3JlcXVlc3Q7DQogCQliaF9yZXEtPmJfcHJpdmF0ZSA9IHIxX2Jo
Ow0KLQkJZ2VuZXJpY19tYWtlX3JlcXVlc3QgKHJ3LCBiaF9yZXEsIE5VTEws
IDAsIDAsIDApOw0KKwkJZ2VuZXJpY19tYWtlX3JlcXVlc3QgKHJ3LCBiaF9y
ZXEsIE5VTEwsIDAsIDApOw0KIAkJcmV0dXJuIDA7DQogCX0NCiANCkBAIC02
MTQsOCArNjM3LDEwIEBADQogCSAqLw0KIA0KIAliaGwgPSByYWlkMV9hbGxv
Y19iaChjb25mLCBjb25mLT5yYWlkX2Rpc2tzKTsNCisNCiAJZm9yIChpID0g
MDsgaSA8IGRpc2tzOyBpKyspIHsNCiAJCXN0cnVjdCBidWZmZXJfaGVhZCAq
bWJoOw0KKwkNCiAJCWlmICghY29uZi0+bWlycm9yc1tpXS5vcGVyYXRpb25h
bCkgDQogCQkJY29udGludWU7DQogIA0KQEAgLTYzOSwyMCArNjY0LDIwIEBA
DQogCQliaGwgPSBtYmgtPmJfbmV4dDsNCiAJCW1iaC0+Yl9uZXh0ID0gTlVM
TDsNCiAJCW1iaC0+Yl90aGlzX3BhZ2UgPSAoc3RydWN0IGJ1ZmZlcl9oZWFk
ICopMTsNCi0JCQ0KKwkJCQ0KICAJLyoNCiAgCSAqIHByZXBhcmUgbWlycm9y
ZWQgbWJoIChmaWVsZHMgb3JkZXJlZCBmb3IgbWF4IG1lbSB0aHJvdWdocHV0
KToNCiAgCSAqLw0KLQkJbWJoLT5iX2Jsb2NrbnIgICAgPSBiaC0+Yl9yc2Vj
dG9yICogc2VjdG9yczsNCisJCW1iaC0+Yl9ibG9ja25yICAgID0gc2VjdG9y
IC8gY291bnQ7DQogCQltYmgtPmJfZGV2ICAgICAgICA9IGNvbmYtPm1pcnJv
cnNbaV0uZGV2Ow0KIAkJbWJoLT5iX3JkZXYJICA9IGNvbmYtPm1pcnJvcnNb
aV0uZGV2Ow0KLQkJbWJoLT5iX3JzZWN0b3IJICA9IGJoLT5iX3JzZWN0b3I7
DQorCQltYmgtPmJfcnNlY3RvcgkgID0gc2VjdG9yOw0KIAkJbWJoLT5iX3N0
YXRlICAgICAgPSAoMTw8QkhfUmVxKSB8ICgxPDxCSF9EaXJ0eSkgfA0KIAkJ
CQkJCSgxPDxCSF9NYXBwZWQpIHwgKDE8PEJIX0xvY2spOw0KIA0KIAkJYXRv
bWljX3NldCgmbWJoLT5iX2NvdW50LCAxKTsNCiAgCQltYmgtPmJfc2l6ZSAg
ICAgICA9IGJoLT5iX3NpemU7DQotIAkJbWJoLT5iX3BhZ2UJICA9IGJoLT5i
X3BhZ2U7DQorCQltYmgtPmJfcGFnZQkgID0gYmgtPmJfcGFnZTsNCiAgCQlt
YmgtPmJfZGF0YQkgID0gYmgtPmJfZGF0YTsNCiAgCQltYmgtPmJfbGlzdCAg
ICAgICA9IEJVRl9MT0NLRUQ7DQogIAkJbWJoLT5iX2VuZF9pbyAgICAgPSBy
YWlkMV9lbmRfcmVxdWVzdDsNCkBAIC02NjAsOSArNjg1LDE0IEBADQogDQog
CQltYmgtPmJfbmV4dCA9IHIxX2JoLT5taXJyb3JfYmhfbGlzdDsNCiAJCXIx
X2JoLT5taXJyb3JfYmhfbGlzdCA9IG1iaDsNCisNCisNCiAJCXN1bV9iaHMr
KzsNCiAJfQ0KKw0KIAlpZiAoYmhsKSByYWlkMV9mcmVlX2JoKGNvbmYsYmhs
KTsNCisNCisNCiAJbWRfYXRvbWljX3NldCgmcjFfYmgtPnJlbWFpbmluZywg
c3VtX2Jocyk7DQogDQogCS8qDQpAQCAtNjgwLDExICs3MTAsMTc3IEBADQog
CXdoaWxlKGJoKSB7DQogCQlzdHJ1Y3QgYnVmZmVyX2hlYWQgKmJoMiA9IGJo
Ow0KIAkJYmggPSBiaC0+Yl9uZXh0Ow0KLQkJZ2VuZXJpY19tYWtlX3JlcXVl
c3QocncsIGJoMiwgTlVMTCwgMCwgMCwgMCk7DQorCQlnZW5lcmljX21ha2Vf
cmVxdWVzdChydywgYmgyLCBOVUxMLCAwLCAwKTsNCiAJfQ0KKw0KIAlyZXR1
cm4gKDApOw0KIH0NCiANCisvKiANCisgKiBraW9idWYgYmFzZWQgbWFrZSBy
ZXF1ZXN0IGZ1bmN0aW9uIA0KKyAqLw0KKw0KK3N0YXRpYyBpbnQga2lvX3Jh
aWQxX21ha2VfcmVxdWVzdChtZGRldl90ICptZGRldiwgaW50IHJ3LCBzdHJ1
Y3Qga2lvYnVmICpraW9idWYsIA0KKwkJCWtkZXZfdCBkZXYsIHVuc2lnbmVk
IGludCBzZWN0b3IsIHVuc2lnbmVkIGNvdW50LCANCisJCQlzdHJ1Y3QgcmFp
ZDFfYmggKnIxX2JoKQ0KK3sNCisJcmFpZDFfY29uZl90ICpjb25mID0gbWRk
ZXZfdG9fY29uZihtZGRldik7DQorCWludCBkaXNrcyA9IE1EX1NCX0RJU0tT
Ow0KKwlpbnQgaSwgc3VtX2JocyA9IDAsIGNudCA9IDA7DQorCXN0cnVjdCBt
aXJyb3JfaW5mbyAqbWlycm9yOw0KKw0KKwlyMV9iaC0+a2lvYnVmID0ga2lv
YnVmOw0KKwlyMV9iaC0+a2lvZGV2ID0gZGV2Ow0KKwlyMV9iaC0+c2VjdG9y
ID0gc2VjdG9yOw0KKw0KKwlpZiAocncgPT0gUkVBRCkgew0KKwkvKg0KKwkg
KiByZWFkIGJhbGFuY2luZyBsb2dpYzoNCisJICovDQorCQlzdHJ1Y3Qga2lv
YnVmICpya2lvOw0KKwkJbWlycm9yID0gY29uZi0+bWlycm9ycyArIHJhaWQx
X3JlYWRfYmFsYW5jZShjb25mLCBkZXYsIHNlY3RvciwgY291bnQpOw0KKw0K
KwkJcjFfYmgtPmtpb3ZlYyA9IChzdHJ1Y3Qga2lvYnVmICoqKWttYWxsb2Mo
c2l6ZW9mKHN0cnVjdCBraW9idWYgKiksIEdGUF9CVUZGRVIpOw0KKwkJYWxs
b2Nfa2lvdmVjKDEsIHIxX2JoLT5raW92ZWMpOw0KKwkNCisJCXJraW8gPSBy
MV9iaC0+a2lvdmVjWzBdOw0KKwkNCisJCXIxX2JoLT5zZWN0b3IgPSBzZWN0
b3I7DQorCQ0KKwkJcmtpby0+bnJfcGFnZXMgPSBraW9idWYtPm5yX3BhZ2Vz
OwkNCisJCXJraW8tPmFycmF5X2xlbiA9IGtpb2J1Zi0+YXJyYXlfbGVuOw0K
KwkJcmtpby0+b2Zmc2V0ID0ga2lvYnVmLT5vZmZzZXQ7DQorCQlya2lvLT5s
ZW5ndGggPSBraW9idWYtPmxlbmd0aDsNCisJDQorCQlya2lvLT5tYXBsaXN0
ID0ga2lvYnVmLT5tYXBsaXN0Ow0KKwkJcmtpby0+b3JpZ19tYXBsaXN0ID0g
a2lvYnVmLT5vcmlnX21hcGxpc3Q7DQorCQlya2lvLT5sb2NrZWQgPSBraW9i
dWYtPmxvY2tlZDsNCisJCXJraW8tPmJvdW5jZWQgPSBraW9idWYtPmJvdW5j
ZWQ7DQorCQ0KKwkJbWVtY3B5KHJraW8tPm1hcF9hcnJheSwga2lvYnVmLT5t
YXBfYXJyYXksIEtJT19TVEFUSUNfUEFHRVMpOw0KKwkNCisJCW1lbWNweShy
a2lvLT5vcmlnX21hcF9hcnJheSwga2lvYnVmLT5vcmlnX21hcF9hcnJheSwg
S0lPX1NUQVRJQ19QQUdFUyk7DQorCQkNCisJCXJraW8tPmVuZF9pbyA9IHJh
aWQxX2VuZF9raW87DQorCQlya2lvLT5rX2Rldl9pZCA9IHIxX2JoOw0KKw0K
KwkJcmtpby0+ZXJybm8gPSBraW9idWYtPmVycm5vOw0KKw0KKwkJZ2VuZXJp
Y19tYWtlX3JlcXVlc3QgKHJ3LCBOVUxMLCBya2lvLCBtaXJyb3ItPmRldiwg
c2VjdG9yKTsNCisJCQ0KKwkJcmV0dXJuIDA7DQorCX0NCisNCisNCisJLyoN
CisJICogV1JJVEU6DQorCSAqLw0KKw0KKwlyMV9iaC0+a2lvdmVjID0gKHN0
cnVjdCBraW9idWYgKiopa21hbGxvYyhzaXplb2Yoc3RydWN0IGtpb2J1ZiAq
KSANCisJCQkqIGNvbmYtPnJhaWRfZGlza3MsIEdGUF9CVUZGRVIpOw0KKw0K
KwlhbGxvY19raW92ZWMoY29uZi0+cmFpZF9kaXNrcywgcjFfYmgtPmtpb3Zl
Yyk7DQorDQorDQorCWZvciAoaSA9IDA7IGkgPCBkaXNrczsgaSsrKSB7DQor
CQlzdHJ1Y3Qga2lvYnVmICp3a2lvOw0KKw0KKwkJaWYgKCFjb25mLT5taXJy
b3JzW2ldLm9wZXJhdGlvbmFsKSANCisJCQljb250aW51ZTsNCisNCisJCXdr
aW8gPSByMV9iaC0+a2lvdmVjW3N1bV9iaHNdOw0KKw0KKwkJd2tpby0+bnJf
cGFnZXMgPSBraW9idWYtPm5yX3BhZ2VzOwkNCisJCXdraW8tPmFycmF5X2xl
biA9IGtpb2J1Zi0+YXJyYXlfbGVuOw0KKwkJd2tpby0+b2Zmc2V0ID0ga2lv
YnVmLT5vZmZzZXQ7DQorCQl3a2lvLT5sZW5ndGggPSBraW9idWYtPmxlbmd0
aDsNCisNCisJCXdraW8tPm1hcGxpc3QgPSBraW9idWYtPm1hcGxpc3Q7DQor
CQl3a2lvLT5vcmlnX21hcGxpc3QgPSBraW9idWYtPm9yaWdfbWFwbGlzdDsN
CisJCXdraW8tPmxvY2tlZCA9IGtpb2J1Zi0+bG9ja2VkOw0KKwkJd2tpby0+
Ym91bmNlZCA9IGtpb2J1Zi0+Ym91bmNlZDsNCisJCW1lbWNweSh3a2lvLT5t
YXBfYXJyYXksIGtpb2J1Zi0+bWFwX2FycmF5LCBLSU9fU1RBVElDX1BBR0VT
KTsNCisJCW1lbWNweSh3a2lvLT5vcmlnX21hcF9hcnJheSwga2lvYnVmLT5v
cmlnX21hcF9hcnJheSwgS0lPX1NUQVRJQ19QQUdFUyk7DQorCQl3a2lvLT5l
bmRfaW8gPSByYWlkMV9lbmRfa2lvOw0KKwkJd2tpby0+a19kZXZfaWQgPSBy
MV9iaDsNCisJCXdraW8tPmVycm5vID0ga2lvYnVmLT5lcnJubzsNCisNCisJ
CXN1bV9iaHMrKzsNCisNCisJfQ0KKw0KKwltZF9hdG9taWNfc2V0KCZyMV9i
aC0+cmVtYWluaW5nLCBzdW1fYmhzKTsNCisNCisJLyogTm93IHN1Ym1pdCBJ
TyB0byBhbGwgd29ya2luZyBtaXJyb3JzICovDQorDQorCWZvcihpPTA7IGkg
PCBkaXNrcyA7IGkrKykgeyANCisJCXN0cnVjdCBraW9idWYgKmtpbyA9IHIx
X2JoLT5raW92ZWNbY250XTsNCisJCWtkZXZfdCBkZXZpICA9IGNvbmYtPm1p
cnJvcnNbaV0uZGV2Ow0KKw0KKwkJaWYgKCFjb25mLT5taXJyb3JzW2ldLm9w
ZXJhdGlvbmFsKSANCisJCQljb250aW51ZTsNCisNCisJCWNudCsrOw0KKw0K
KwkJZ2VuZXJpY19tYWtlX3JlcXVlc3QocncsIE5VTEwsIGtpbywgZGV2aSwg
c2VjdG9yKTsNCisNCisJCWlmKC0tc3VtX2JocyA8IDApIEJVRygpOw0KKwl9
DQorDQorCXJldHVybiAoMCk7DQorfQ0KKw0KKw0KK3N0YXRpYyBpbnQgcmFp
ZDFfbWFrZV9yZXF1ZXN0IChtZGRldl90ICptZGRldiwgaW50IHJ3LCBzdHJ1
Y3QgYnVmZmVyX2hlYWQgKiBiaCwNCisJCQlzdHJ1Y3Qga2lvYnVmICpraW9i
dWYsIGtkZXZfdCBkZXYsIHVuc2lnbmVkIGludCBzZWN0b3IsIA0KKwkJCXVu
c2lnbmVkIGxvbmcgY291bnQpDQorew0KKwlyYWlkMV9jb25mX3QgKmNvbmYg
PSBtZGRldl90b19jb25mKG1kZGV2KTsNCisJc3RydWN0IHJhaWQxX2JoICog
cjFfYmg7DQorCQ0KKy8qDQorICogbWFrZV9yZXF1ZXN0KCkgY2FuIGFib3J0
IHRoZSBvcGVyYXRpb24gd2hlbiBSRUFEQSBpcyBiZWluZw0KKyAqIHVzZWQg
YW5kIG5vIGVtcHR5IHJlcXVlc3QgaXMgYXZhaWxhYmxlLg0KKyAqDQorICog
Q3VycmVudGx5LCBqdXN0IHJlcGxhY2UgdGhlIGNvbW1hbmQgd2l0aCBSRUFE
L1dSSVRFLg0KKyAqLw0KKwlpZiAocncgPT0gUkVBREEpDQorCQlydyA9IFJF
QUQ7DQorDQorCXIxX2JoID0gcmFpZDFfYWxsb2NfcjFiaCAoY29uZik7DQor
DQorCXNwaW5fbG9ja19pcnEoJmNvbmYtPnNlZ21lbnRfbG9jayk7DQorCXdh
aXRfZXZlbnRfbG9ja19pcnEoY29uZi0+d2FpdF9kb25lLA0KKwkJCXNlY3Rv
ciA8IGNvbmYtPnN0YXJ0X2FjdGl2ZSB8fA0KKwkJCXNlY3RvciA+PSBjb25m
LT5zdGFydF9mdXR1cmUsDQorCQkJY29uZi0+c2VnbWVudF9sb2NrKTsNCisJ
aWYgKHNlY3RvciA8IGNvbmYtPnN0YXJ0X2FjdGl2ZSkgIA0KKwkJY29uZi0+
Y250X2RvbmUrKzsNCisJZWxzZSB7DQorCQljb25mLT5jbnRfZnV0dXJlKys7
DQorCQlpZiAoY29uZi0+cGhhc2UpDQorCQkJc2V0X2JpdChSMUJIX1N5bmNQ
aGFzZSwgJnIxX2JoLT5zdGF0ZSk7DQorCX0NCisJc3Bpbl91bmxvY2tfaXJx
KCZjb25mLT5zZWdtZW50X2xvY2spOw0KKw0KKwkvKg0KKwkgKiBpIHRoaW5r
IHRoZSByZWFkIGFuZCB3cml0ZSBicmFuY2ggc2hvdWxkIGJlIHNlcGFyYXRl
ZCBjb21wbGV0ZWx5LA0KKwkgKiBzaW5jZSB3ZSB3YW50IHRvIGRvIHJlYWQg
YmFsYW5jaW5nIG9uIHRoZSByZWFkIHNpZGUgZm9yIGV4YW1wbGUuDQorCSAq
IEFsdGVybmF0aXZlIGltcGxlbWVudGF0aW9ucz8gOikgLS1taW5nbw0KKwkg
Ki8NCisNCisJcjFfYmgtPm1kZGV2ID0gbWRkZXY7DQorCXIxX2JoLT5jbWQg
PSBydzsNCisNCisJaWYoYmgpIA0KKwkJcmV0dXJuIGJoX3JhaWQxX21ha2Vf
cmVxdWVzdChtZGRldiwgcncsIGJoLCBkZXYsIHNlY3RvciwgY291bnQsIHIx
X2JoKTsNCisJZWxzZSBpZiAoa2lvYnVmKSANCisJCXJldHVybiBraW9fcmFp
ZDFfbWFrZV9yZXF1ZXN0KG1kZGV2LCBydywga2lvYnVmLCBkZXYsIHNlY3Rv
ciwgY291bnQsIHIxX2JoKTsNCisJcHJpbnRrKEtFUk5fRVJSICJyYWlkMV9t
YWtlX3JlcXVlc3Q6IG5laXRoZXIga2lvIGFuZCBiaCBJTyFcbiIpOyANCisJ
QlVHKCk7DQorCXJldHVybiAoMSk7DQorfQ0KKw0KIHN0YXRpYyBpbnQgcmFp
ZDFfc3RhdHVzIChjaGFyICpwYWdlLCBtZGRldl90ICptZGRldikNCiB7DQog
CXJhaWQxX2NvbmZfdCAqY29uZiA9IG1kZGV2X3RvX2NvbmYobWRkZXYpOw0K
QEAgLTExODAsNyArMTM3Niw3IEBADQogCQkJCXdoaWxlIChtYmgpIHsNCiAJ
CQkJCXN0cnVjdCBidWZmZXJfaGVhZCAqYmgxID0gbWJoOw0KIAkJCQkJbWJo
ID0gbWJoLT5iX25leHQ7DQotCQkJCQlnZW5lcmljX21ha2VfcmVxdWVzdChX
UklURSwgYmgxLCBOVUxMLCAwLCAwLCAwKTsNCisJCQkJCWdlbmVyaWNfbWFr
ZV9yZXF1ZXN0KFdSSVRFLCBiaDEsIE5VTEwsIDAsIDApOw0KIAkJCQkJbWRf
c3luY19hY2N0KGJoMS0+Yl9yZGV2LCBiaDEtPmJfc2l6ZS81MTIpOw0KIAkJ
CQl9DQogCQkJfSBlbHNlIHsNCkBAIC0xMTkzLDcgKzEzODksNyBAQA0KIAkJ
CQkJcHJpbnRrIChSRURJUkVDVF9TRUNUT1IsDQogCQkJCQkJcGFydGl0aW9u
X25hbWUoYmgtPmJfZGV2KSwgYmgtPmJfYmxvY2tucik7DQogCQkJCQliaC0+
Yl9yZGV2ID0gYmgtPmJfZGV2Ow0KLQkJCQkJZ2VuZXJpY19tYWtlX3JlcXVl
c3QoUkVBRCwgYmgsIE5VTEwsIDAsIDAsIDApOw0KKwkJCQkJZ2VuZXJpY19t
YWtlX3JlcXVlc3QoUkVBRCwgYmgsIE5VTEwsIDAsIDApOw0KIAkJCQl9DQog
CQkJfQ0KIA0KQEAgLTEyMTAsNyArMTQwNiw3IEBADQogCQkJCXByaW50ayAo
UkVESVJFQ1RfU0VDVE9SLA0KIAkJCQkJcGFydGl0aW9uX25hbWUoYmgtPmJf
ZGV2KSwgYmgtPmJfYmxvY2tucik7DQogCQkJCWJoLT5iX3JkZXYgPSBiaC0+
Yl9kZXY7DQotCQkJCWdlbmVyaWNfbWFrZV9yZXF1ZXN0IChyMV9iaC0+Y21k
LCBiaCwgTlVMTCwgMCwgMCwgMCk7DQorCQkJCWdlbmVyaWNfbWFrZV9yZXF1
ZXN0IChyMV9iaC0+Y21kLCBiaCwgTlVMTCwgMCwgMCk7DQogCQkJfQ0KIAkJ
CWJyZWFrOw0KIAkJfQ0KQEAgLTEyNTQsNyArMTQ1MCw3IEBADQogCWNvbmYt
PnN0YXJ0X2Z1dHVyZSA9IG1kZGV2LT5zYi0+c2l6ZSsxOw0KIAljb25mLT5j
bnRfcGVuZGluZyA9IGNvbmYtPmNudF9mdXR1cmU7DQogCWNvbmYtPmNudF9m
dXR1cmUgPSAwOw0KLQljb25mLT5waGFzZSA9IGNvbmYtPnBoYXNlIF4xOw0K
Kwljb25mLT5waGFzZSA9IGNvbmYtPnBoYXNlIF4xOyANCiAJd2FpdF9ldmVu
dF9sb2NrX2lycShjb25mLT53YWl0X3JlYWR5LCAhY29uZi0+Y250X3BlbmRp
bmcsIGNvbmYtPnNlZ21lbnRfbG9jayk7DQogCWNvbmYtPnN0YXJ0X2FjdGl2
ZSA9IGNvbmYtPnN0YXJ0X3JlYWR5ID0gY29uZi0+c3RhcnRfcGVuZGluZyA9
IGNvbmYtPnN0YXJ0X2Z1dHVyZSA9IDA7DQogCWNvbmYtPnBoYXNlID0gMDsN
CkBAIC0xNDA1LDcgKzE2MDEsNyBAQA0KIAliaC0+Yl9yc2VjdG9yID0gYmxv
Y2tfbnI8PDE7DQogCWluaXRfd2FpdHF1ZXVlX2hlYWQoJmJoLT5iX3dhaXQp
Ow0KIA0KLQlnZW5lcmljX21ha2VfcmVxdWVzdChSRUFELCBiaCwgTlVMTCwg
MCwgMCwgMCk7DQorCWdlbmVyaWNfbWFrZV9yZXF1ZXN0KFJFQUQsIGJoLCBO
VUxMLCAwLCAwKTsNCiAJbWRfc3luY19hY2N0KGJoLT5iX3JkZXYsIGJoLT5i
X3NpemUvNTEyKTsNCiANCiAJcmV0dXJuIChic2l6ZSA+PiAxMCk7DQpkaWZm
IC1OdXIgLS1leGNsdWRlLWZyb209L2hvbWUvbWFyY2Vsby9leGNsdWRlIHRl
bXAvbGludXgtMi40LXhmcy9saW51eC5vcmlnL2RyaXZlcnMvbWQvcmFpZDUu
YyBsaW51eC0yLjQteGZzL2xpbnV4L2RyaXZlcnMvbWQvcmFpZDUuYw0KLS0t
IHRlbXAvbGludXgtMi40LXhmcy9saW51eC5vcmlnL2RyaXZlcnMvbWQvcmFp
ZDUuYwlGcmkgTm92IDI0IDE5OjMyOjExIDIwMDANCisrKyBsaW51eC0yLjQt
eGZzL2xpbnV4L2RyaXZlcnMvbWQvcmFpZDUuYwlGcmkgTm92IDI0IDE4OjQ1
OjIyIDIwMDANCkBAIC0xMDY5LDExICsxMDY5LDExIEBADQogCQkJCQlQUklO
VEsoIndyaXRpbmcgc3BhcmUgJWRcbiIsIGkpOw0KIAkJCQkJYXRvbWljX2lu
Yygmc2gtPm5yX3BlbmRpbmcpOw0KIAkJCQkJYmgtPmJfZGV2ID0gYmgtPmJf
cmRldiA9IGNvbmYtPnNwYXJlLT5kZXY7DQotCQkJCQlnZW5lcmljX21ha2Vf
cmVxdWVzdChXUklURSwgYmgsIE5VTEwsIDAsIDAsIDApOw0KKwkJCQkJZ2Vu
ZXJpY19tYWtlX3JlcXVlc3QoV1JJVEUsIGJoLCBOVUxMLCAwLCAwKTsNCiAJ
CQkJfSBlbHNlIHsNCiAJCQkJCWF0b21pY19pbmMoJnNoLT5ucl9wZW5kaW5n
KTsNCiAJCQkJCWJoLT5iX2RldiA9IGJoLT5iX3JkZXYgPSBjb25mLT5kaXNr
c1tpXS5kZXY7DQotCQkJCQlnZW5lcmljX21ha2VfcmVxdWVzdChXUklURSwg
YmgsIE5VTEwsIDAsIDAsIDApOw0KKwkJCQkJZ2VuZXJpY19tYWtlX3JlcXVl
c3QoV1JJVEUsIGJoLCBOVUxMLCAwLCAwKTsNCiAJCQkJfQ0KIAkJCQlhdG9t
aWNfZGVjKCZiaC0+Yl9jb3VudCk7DQogCQkJfQ0KQEAgLTExMTIsNyArMTEx
Miw3IEBADQogCQlsb2NrX2dldF9iaChzaC0+Ymhfb2xkW2ldKTsNCiAJCWF0
b21pY19pbmMoJnNoLT5ucl9wZW5kaW5nKTsNCiAJCXNoLT5iaF9vbGRbaV0t
PmJfZGV2ID0gc2gtPmJoX29sZFtpXS0+Yl9yZGV2ID0gY29uZi0+ZGlza3Nb
aV0uZGV2Ow0KLQkJZ2VuZXJpY19tYWtlX3JlcXVlc3QoUkVBRCwgc2gtPmJo
X29sZFtpXSwgTlVMTCwgMCwgMCwgMCk7DQorCQlnZW5lcmljX21ha2VfcmVx
dWVzdChSRUFELCBzaC0+Ymhfb2xkW2ldLCBOVUxMLCAwLCAwKTsNCiAJCWF0
b21pY19kZWMoJnNoLT5iaF9vbGRbaV0tPmJfY291bnQpOw0KIAl9DQogCVBS
SU5USygiaGFuZGxlX3N0cmlwZSgpICVsdSwgcmVhZGluZyAlZCBvbGQgYnVm
ZmVyc1xuIiwgc2gtPnNlY3RvciwgbWRfYXRvbWljX3JlYWQoJnNoLT5ucl9w
ZW5kaW5nKSk7DQpAQCAtMTE1Nyw3ICsxMTU3LDcgQEANCiAJCQlsb2NrX2dl
dF9iaChzaC0+Ymhfb2xkW2ldKTsNCiAJCQlhdG9taWNfaW5jKCZzaC0+bnJf
cGVuZGluZyk7DQogCQkJc2gtPmJoX29sZFtpXS0+Yl9kZXYgPSBzaC0+Ymhf
b2xkW2ldLT5iX3JkZXYgPSBjb25mLT5kaXNrc1tpXS5kZXY7DQotCQkJZ2Vu
ZXJpY19tYWtlX3JlcXVlc3QoUkVBRCwgc2gtPmJoX29sZFtpXSwgTlVMTCwg
MCwgMCwgMCk7DQorCQkJZ2VuZXJpY19tYWtlX3JlcXVlc3QoUkVBRCwgc2gt
PmJoX29sZFtpXSwgTlVMTCwgMCwgMCk7DQogCQkJYXRvbWljX2RlYygmc2gt
PmJoX29sZFtpXS0+Yl9jb3VudCk7DQogCQl9DQogCQlQUklOVEsoImhhbmRs
ZV9zdHJpcGUoKSAlbHUsIHBoYXNlIFJFQURfT0xELCBwZW5kaW5nICVkIGJ1
ZmZlcnNcbiIsIHNoLT5zZWN0b3IsIG1kX2F0b21pY19yZWFkKCZzaC0+bnJf
cGVuZGluZykpOw0KQEAgLTExODYsNyArMTE4Niw3IEBADQogCQlsb2NrX2dl
dF9iaChzaC0+YmhfcmVxW2ldKTsNCiAJCWF0b21pY19pbmMoJnNoLT5ucl9w
ZW5kaW5nKTsNCiAJCXNoLT5iaF9yZXFbaV0tPmJfZGV2ID0gc2gtPmJoX3Jl
cVtpXS0+Yl9yZGV2ID0gY29uZi0+ZGlza3NbaV0uZGV2Ow0KLQkJZ2VuZXJp
Y19tYWtlX3JlcXVlc3QoUkVBRCwgc2gtPmJoX3JlcVtpXSwgTlVMTCwgMCwg
MCwgMCk7DQorCQlnZW5lcmljX21ha2VfcmVxdWVzdChSRUFELCBzaC0+Ymhf
cmVxW2ldLCBOVUxMLCAwLCAwKTsNCiAJCWF0b21pY19kZWMoJnNoLT5iaF9y
ZXFbaV0tPmJfY291bnQpOw0KIAl9DQogCVBSSU5USygiaGFuZGxlX3N0cmlw
ZSgpICVsdSwgcGhhc2UgUkVBRCwgcGVuZGluZyAlZFxuIiwgc2gtPnNlY3Rv
ciwgbWRfYXRvbWljX3JlYWQoJnNoLT5ucl9wZW5kaW5nKSk7DQpAQCAtMTIy
Miw3ICsxMjIyLDcgQEANCiAJCQlsb2NrX2dldF9iaChiaCk7DQogCQkJYXRv
bWljX2luYygmc2gtPm5yX3BlbmRpbmcpOw0KIAkJCWJoLT5iX2RldiA9IGJo
LT5iX3JkZXYgPSBjb25mLT5kaXNrc1tpXS5kZXY7DQotCQkJZ2VuZXJpY19t
YWtlX3JlcXVlc3QoUkVBRCwgYmgsIE5VTEwsIDAsIDAsIDApOw0KKwkJCWdl
bmVyaWNfbWFrZV9yZXF1ZXN0KFJFQUQsIGJoLCBOVUxMLCAwLCAwKTsNCiAJ
CQltZF9zeW5jX2FjY3QoYmgtPmJfcmRldiwgYmgtPmJfc2l6ZS81MTIpOw0K
IAkJCWF0b21pY19kZWMoJnNoLT5iaF9vbGRbaV0tPmJfY291bnQpOw0KIAkJ
fQ0KQEAgLTEyNTEsNyArMTI1MSw3IEBADQogCQkJCWF0b21pY19pbmMoJnNo
LT5ucl9wZW5kaW5nKTsNCiAJCQkJbG9ja19nZXRfYmgoYmgpOw0KIAkJCQli
aC0+Yl9kZXYgPSBiaC0+Yl9yZGV2ID0gY29uZi0+c3BhcmUtPmRldjsNCi0J
CQkJZ2VuZXJpY19tYWtlX3JlcXVlc3QoV1JJVEUsIGJoLCBOVUxMLCAwLCAw
LCAwKTsNCisJCQkJZ2VuZXJpY19tYWtlX3JlcXVlc3QoV1JJVEUsIGJoLCBO
VUxMLCAwLCAwKTsNCiAJCQkJbWRfc3luY19hY2N0KGJoLT5iX3JkZXYsIGJo
LT5iX3NpemUvNTEyKTsNCiAJCQkJYXRvbWljX2RlYygmYmgtPmJfY291bnQp
Ow0KIAkJUFJJTlRLKCJoYW5kbGVfc3RyaXBlX3N5bmMoKSAlbHUsIHBoYXNl
IFdSSVRFLCBwZW5kaW5nICVkIGJ1ZmZlcnNcbiIsIHNoLT5zZWN0b3IsIG1k
X2F0b21pY19yZWFkKCZzaC0+bnJfcGVuZGluZykpOw0KQEAgLTEyNzcsNyAr
MTI3Nyw3IEBADQogCQlsb2NrX2dldF9iaChiaCk7DQogCQlhdG9taWNfaW5j
KCZzaC0+bnJfcGVuZGluZyk7DQogCQliaC0+Yl9kZXYgPSBiaC0+Yl9yZGV2
ID0gY29uZi0+ZGlza3NbcGRfaWR4XS5kZXY7DQotCQlnZW5lcmljX21ha2Vf
cmVxdWVzdChXUklURSwgYmgsIE5VTEwsIDAsIDAsIDApOw0KKwkJZ2VuZXJp
Y19tYWtlX3JlcXVlc3QoV1JJVEUsIGJoLCBOVUxMLCAwLCAwKTsNCiAJCW1k
X3N5bmNfYWNjdChiaC0+Yl9yZGV2LCBiaC0+Yl9zaXplLzUxMik7DQogCQlh
dG9taWNfZGVjKCZiaC0+Yl9jb3VudCk7DQogCQlQUklOVEsoImhhbmRsZV9z
dHJpcGVfc3luYygpICVsdSBwaGFzZSBXUklURSwgcGVuZGluZyAlZCBidWZm
ZXJzXG4iLA0KZGlmZiAtTnVyIC0tZXhjbHVkZS1mcm9tPS9ob21lL21hcmNl
bG8vZXhjbHVkZSB0ZW1wL2xpbnV4LTIuNC14ZnMvbGludXgub3JpZy9mcy9i
dWZmZXIuYyBsaW51eC0yLjQteGZzL2xpbnV4L2ZzL2J1ZmZlci5jDQotLS0g
dGVtcC9saW51eC0yLjQteGZzL2xpbnV4Lm9yaWcvZnMvYnVmZmVyLmMJRnJp
IE5vdiAyNCAxOTozMjo0MiAyMDAwDQorKysgbGludXgtMi40LXhmcy9saW51
eC9mcy9idWZmZXIuYwlGcmkgTm92IDI0IDE5OjAzOjU4IDIwMDANCkBAIC0y
MDU3LDcgKzIwNTcsNyBAQA0KIA0KIAkJCQlhdG9taWNfaW5jKCZpb2J1Zi0+
aW9fY291bnQpOw0KIA0KLQkJCQlnZW5lcmljX21ha2VfcmVxdWVzdChydywg
dG1wLCBOVUxMLCAwLCAwLCAwKTsNCisJCQkJZ2VuZXJpY19tYWtlX3JlcXVl
c3QocncsIHRtcCwgTlVMTCwgMCwgMCk7DQogCQkJCS8qIA0KIAkJCQkgKiBX
YWl0IGZvciBJTyBpZiB3ZSBoYXZlIGdvdCB0b28gbXVjaCANCiAJCQkJICov
DQpkaWZmIC1OdXIgLS1leGNsdWRlLWZyb209L2hvbWUvbWFyY2Vsby9leGNs
dWRlIHRlbXAvbGludXgtMi40LXhmcy9saW51eC5vcmlnL2ZzL2lvYnVmLmMg
bGludXgtMi40LXhmcy9saW51eC9mcy9pb2J1Zi5jDQotLS0gdGVtcC9saW51
eC0yLjQteGZzL2xpbnV4Lm9yaWcvZnMvaW9idWYuYwlGcmkgTm92IDI0IDE5
OjMyOjQyIDIwMDANCisrKyBsaW51eC0yLjQteGZzL2xpbnV4L2ZzL2lvYnVm
LmMJU3VuIE5vdiAxOSAxNTowMToyOSAyMDAwDQpAQCAtMTEsOCArMTEsNyBA
QA0KICNpbmNsdWRlIDxsaW51eC9zbGFiLmg+DQogI2luY2x1ZGUgPGxpbnV4
L2hpZ2htZW0uaD4NCiANCi1zdGF0aWMga21lbV9jYWNoZV90ICpraW9idWZf
Y2FjaGVwOw0KLQ0KK2ttZW1fY2FjaGVfdCAqa2lvYnVmX2NhY2hlcDsNCiAN
CiB2b2lkIGVuZF9raW9fcmVxdWVzdChzdHJ1Y3Qga2lvYnVmICpraW9idWYs
IGludCB1cHRvZGF0ZSkNCiB7DQpkaWZmIC1OdXIgLS1leGNsdWRlLWZyb209
L2hvbWUvbWFyY2Vsby9leGNsdWRlIHRlbXAvbGludXgtMi40LXhmcy9saW51
eC5vcmlnL2luY2x1ZGUvbGludXgvYmxrZGV2LmggbGludXgtMi40LXhmcy9s
aW51eC9pbmNsdWRlL2xpbnV4L2Jsa2Rldi5oDQotLS0gdGVtcC9saW51eC0y
LjQteGZzL2xpbnV4Lm9yaWcvaW5jbHVkZS9saW51eC9ibGtkZXYuaAlGcmkg
Tm92IDI0IDE5OjMyOjU5IDIwMDANCisrKyBsaW51eC0yLjQteGZzL2xpbnV4
L2luY2x1ZGUvbGludXgvYmxrZGV2LmgJRnJpIE5vdiAyNCAxOTo1MTowOSAy
MDAwDQpAQCAtMTU3LDcgKzE1Nyw3IEBADQogZXh0ZXJuIHZvaWQgcmVnaXN0
ZXJfZGlzayhzdHJ1Y3QgZ2VuZGlzayAqZGV2LCBrZGV2X3QgZmlyc3QsIHVu
c2lnbmVkIG1pbm9ycywgc3RydWN0IGJsb2NrX2RldmljZV9vcGVyYXRpb25z
ICpvcHMsIGxvbmcgc2l6ZSk7DQogZXh0ZXJuIHZvaWQgZ2VuZXJpY19tYWtl
X3JlcXVlc3QoaW50IHJ3LCBzdHJ1Y3QgYnVmZmVyX2hlYWQgKiBiaCwNCiAJ
CQkJIHN0cnVjdCBraW9idWYgKiBraW9idWYsIGtkZXZfdCBkZXYsDQotCQkJ
CSB1bnNpZ25lZCBsb25nIGJsa29ja25yLCBzaXplX3QgYmxrc2l6ZSk7DQor
CQkJCSB1bnNpZ25lZCBsb25nIHNlY3QpOw0KIGV4dGVybiByZXF1ZXN0X3F1
ZXVlX3QgKmJsa19nZXRfcXVldWUoa2Rldl90IGRldik7DQogZXh0ZXJuIHZv
aWQgYmxrZGV2X3JlbGVhc2VfcmVxdWVzdChzdHJ1Y3QgcmVxdWVzdCAqKTsN
CiANCmRpZmYgLU51ciAtLWV4Y2x1ZGUtZnJvbT0vaG9tZS9tYXJjZWxvL2V4
Y2x1ZGUgdGVtcC9saW51eC0yLjQteGZzL2xpbnV4Lm9yaWcvaW5jbHVkZS9s
aW51eC9yYWlkL21kX2suaCBsaW51eC0yLjQteGZzL2xpbnV4L2luY2x1ZGUv
bGludXgvcmFpZC9tZF9rLmgNCi0tLSB0ZW1wL2xpbnV4LTIuNC14ZnMvbGlu
dXgub3JpZy9pbmNsdWRlL2xpbnV4L3JhaWQvbWRfay5oCUZyaSBOb3YgMjQg
MTk6MzM6MDEgMjAwMA0KKysrIGxpbnV4LTIuNC14ZnMvbGludXgvaW5jbHVk
ZS9saW51eC9yYWlkL21kX2suaAlGcmkgTm92IDI0IDE5OjQxOjA2IDIwMDAN
CkBAIC0yMTcsNyArMjE3LDggQEANCiBzdHJ1Y3QgbWRrX3BlcnNvbmFsaXR5
X3MNCiB7DQogCWNoYXIgKm5hbWU7DQotCWludCAoKm1ha2VfcmVxdWVzdCko
bWRkZXZfdCAqbWRkZXYsIGludCBydywgc3RydWN0IGJ1ZmZlcl9oZWFkICog
YmgpOw0KKwlpbnQgKCptYWtlX3JlcXVlc3QpKG1kZGV2X3QgKm1kZGV2LCBp
bnQgcncsIHN0cnVjdCBidWZmZXJfaGVhZCAqIGJoLCANCisJCQlzdHJ1Y3Qg
a2lvYnVmICpraW9idWYsIGtkZXZfdCBkZXYsIHVuc2lnbmVkIGludCBzZWN0
b3IsIHVuc2lnbmVkIGludCBjb3VudCk7DQogCWludCAoKnJ1bikobWRkZXZf
dCAqbWRkZXYpOw0KIAlpbnQgKCpzdG9wKShtZGRldl90ICptZGRldik7DQog
CWludCAoKnN0YXR1cykoY2hhciAqcGFnZSwgbWRkZXZfdCAqbWRkZXYpOw0K
ZGlmZiAtTnVyIC0tZXhjbHVkZS1mcm9tPS9ob21lL21hcmNlbG8vZXhjbHVk
ZSB0ZW1wL2xpbnV4LTIuNC14ZnMvbGludXgub3JpZy9pbmNsdWRlL2xpbnV4
L3JhaWQvcmFpZDEuaCBsaW51eC0yLjQteGZzL2xpbnV4L2luY2x1ZGUvbGlu
dXgvcmFpZC9yYWlkMS5oDQotLS0gdGVtcC9saW51eC0yLjQteGZzL2xpbnV4
Lm9yaWcvaW5jbHVkZS9saW51eC9yYWlkL3JhaWQxLmgJRnJpIE5vdiAyNCAx
OTozMzowMSAyMDAwDQorKysgbGludXgtMi40LXhmcy9saW51eC9pbmNsdWRl
L2xpbnV4L3JhaWQvcmFpZDEuaAlGcmkgTm92IDI0IDE5OjUzOjEzIDIwMDAN
CkBAIC04NCw2ICs4NCwxMiBAQA0KIAlzdHJ1Y3QgYnVmZmVyX2hlYWQJKm1p
cnJvcl9iaF9saXN0Ow0KIAlzdHJ1Y3QgYnVmZmVyX2hlYWQJYmhfcmVxOw0K
IAlzdHJ1Y3QgcmFpZDFfYmgJCSpuZXh0X3IxOwkvKiBuZXh0IGZvciByZXRy
eSBvciBpbiBmcmVlIGxpc3QgKi8NCisNCisJLyogdGhlc2UgaW5mb3JtYXRp
b24gaXMgb25seSB1c2VkIGJ5IGtpb2J1ZiBiYXNlZCBJTyAqLw0KKwlzdHJ1
Y3Qga2lvYnVmCQkqa2lvYnVmOw0KKwlzdHJ1Y3Qga2lvYnVmIAkJKipraW92
ZWM7DQorCWtkZXZfdAkJCWtpb2RldjsgICAgDQorCXVuc2lnbmVkIGxvbmcJ
CXNlY3RvcjsNCiB9Ow0KIC8qIGJpdHMgZm9yIHJhaWQxX2JoLnN0YXRlICov
DQogI2RlZmluZQlSMUJIX1VwdG9kYXRlCTENCmRpZmYgLU51ciAtLWV4Y2x1
ZGUtZnJvbT0vaG9tZS9tYXJjZWxvL2V4Y2x1ZGUgdGVtcC9saW51eC0yLjQt
eGZzL2xpbnV4Lm9yaWcvaW5jbHVkZS9saW51eC9zbGFiLmggbGludXgtMi40
LXhmcy9saW51eC9pbmNsdWRlL2xpbnV4L3NsYWIuaA0KLS0tIHRlbXAvbGlu
dXgtMi40LXhmcy9saW51eC5vcmlnL2luY2x1ZGUvbGludXgvc2xhYi5oCUZy
aSBOb3YgMjQgMTk6MzM6MDAgMjAwMA0KKysrIGxpbnV4LTIuNC14ZnMvbGlu
dXgvaW5jbHVkZS9saW51eC9zbGFiLmgJU3VuIE5vdiAxOSAxNTowMToxNyAy
MDAwDQpAQCAtNzUsNiArNzUsNyBAQA0KIGV4dGVybiBrbWVtX2NhY2hlX3QJ
KmJoX2NhY2hlcDsNCiBleHRlcm4ga21lbV9jYWNoZV90CSpmc19jYWNoZXA7
DQogZXh0ZXJuIGttZW1fY2FjaGVfdAkqc2lnYWN0X2NhY2hlcDsNCitleHRl
cm4ga21lbV9jYWNoZV90CSpraW9idWZfY2FjaGVwOw0KIA0KICNlbmRpZgkv
KiBfX0tFUk5FTF9fICovDQogDQpkaWZmIC1OdXIgLS1leGNsdWRlLWZyb209
L2hvbWUvbWFyY2Vsby9leGNsdWRlIHRlbXAvbGludXgtMi40LXhmcy9saW51
eC5vcmlnL2tlcm5lbC9rc3ltcy5jIGxpbnV4LTIuNC14ZnMvbGludXgva2Vy
bmVsL2tzeW1zLmMNCi0tLSB0ZW1wL2xpbnV4LTIuNC14ZnMvbGludXgub3Jp
Zy9rZXJuZWwva3N5bXMuYwlGcmkgTm92IDI0IDE5OjMzOjAzIDIwMDANCisr
KyBsaW51eC0yLjQteGZzL2xpbnV4L2tlcm5lbC9rc3ltcy5jCUZyaSBOb3Yg
MjQgMTg6MjA6MTYgMjAwMA0KQEAgLTQyMyw2ICs0MjMsOCBAQA0KIC8qIEtp
b2J1ZnMgKi8NCiBFWFBPUlRfU1lNQk9MKGtpb2J1Zl9pbml0KTsNCiANCitF
WFBPUlRfU1lNQk9MKGtpb2J1Zl9jYWNoZXApOw0KKw0KIEVYUE9SVF9TWU1C
T0woYWxsb2Nfa2lvdmVjKTsNCiBFWFBPUlRfU1lNQk9MKGZyZWVfa2lvdmVj
KTsNCiBFWFBPUlRfU1lNQk9MKGV4cGFuZF9raW9idWYpOw0KLS0tIHRlbXAv
bGludXgtMi40LXhmcy9saW51eC9mcy9wYWdlYnVmL3BhZ2VfYnVmLmMJRnJp
IE5vdiAxMCAxNzoyMDowNCAyMDAwDQorKysgbGludXgtMi40LXhmcy9saW51
eC9mcy9wYWdlYnVmL3BhZ2VfYnVmLmMJRnJpIE5vdiAyNCAxODo0OTo1MCAy
MDAwDQpAQCAtMTQzNyw3ICsxNDM3LDcgQEANCiAJCWF0b21pY19pbmMoJlBC
UChwYiktPnBiX2lvX3JlbWFpbmluZyk7DQogDQogCQlmb3IgKGl0cj0wOyBp
dHIgPCBjbnQ7IGl0cisrKXsNCi0JCQlnZW5lcmljX21ha2VfcmVxdWVzdChy
dywgcHN5bmMtPmJoW2l0cl0sIE5VTEwsIDAsIDAsIDApOw0KKwkJCWdlbmVy
aWNfbWFrZV9yZXF1ZXN0KHJ3LCBwc3luYy0+YmhbaXRyXSwgTlVMTCwgMCwg
MCk7DQogCQl9CQkgIA0KIAl9IGVsc2Ugew0KIAkJa2ZyZWUocHN5bmMpOw0K

--661009-574407949-975097490=:3967--

From owner-linux-xfs@oss.sgi.com Fri Nov 24 15:20:18 2000
Received:  by oss.sgi.com id <S553813AbQKXXT6>;
	Fri, 24 Nov 2000 15:19:58 -0800
Received: from perninha.conectiva.com.br ([200.250.58.156]:16652 "EHLO
        perninha.conectiva.com.br") by oss.sgi.com with ESMTP
	id <S553806AbQKXXTg>; Fri, 24 Nov 2000 15:19:36 -0800
Received: from freak.distro.conectiva (freak.distro.conectiva [10.0.17.22])
	by perninha.conectiva.com.br (8.9.3/8.9.3) with ESMTP id VAA32497
	for <linux-xfs@oss.sgi.com>; Fri, 24 Nov 2000 21:19:34 -0200
Date:   Fri, 24 Nov 2000 19:23:59 -0200 (BRST)
From:   Marcelo Tosatti <marcelo@conectiva.com.br>
X-Sender: marcelo@freak.distro.conectiva
To:     linux-xfs@oss.sgi.com
Subject: Re: initial raid1 kiobuf support 
In-Reply-To: <Pine.LNX.4.21.0011241821460.3967-200000@freak.distro.conectiva>
Message-ID: <Pine.LNX.4.21.0011241922380.4674-100000@freak.distro.conectiva>
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, 24 Nov 2000, Marcelo Tosatti wrote:

> 
> Hi, 
> 
> I'm attaching a patch which adds kiobuf IO support to the raid1 code. 
> 
> Its not complete yet --- it does not reschedule read requests to other
> mirrors of the raid1 array in case of a IO error. I hope to do that soon.
> 
> Also, I've modified generic_make_request() function and touched some other
> kernel bits.
> 
> The patch is against SGI XFS tree from 1 hour ago. 
> 
> Comments are welcome.

Silly mistake in my patch:

@@ -1231,7 +1232,7 @@
@@ -1231,7 +1232,7 @@
         * should try ll_rw_block()
         * for non-SCSI (e.g. IDE) disks.
         */
-        if (!SCSI_DISK_MAJOR(MAJOR(dev))) {
+       if (!SCSI_DISK_MAJOR(MAJOR(dev)) || MAJOR(dev) != MD_MAJOR) { 
                *error = -ENOSYS;
                goto end_io;
        }


 
@@ -1231,7 +1232,7 @@
         * should try ll_rw_block()
         * for non-SCSI (e.g. IDE) disks.
         */
-        if (!SCSI_DISK_MAJOR(MAJOR(dev))) {
+       if (!SCSI_DISK_MAJOR(MAJOR(dev)) && MAJOR(dev) != MD_MAJOR) { 
                *error = -ENOSYS;
                goto end_io;
        }





From owner-linux-xfs@oss.sgi.com Sat Nov 25 08:32:19 2000
Received:  by oss.sgi.com id <S553728AbQKYQb7>;
	Sat, 25 Nov 2000 08:31:59 -0800
Received: from deliverator.sgi.com ([204.94.214.10]:3189 "EHLO
        deliverator.sgi.com") by oss.sgi.com with ESMTP id <S553691AbQKYQbd>;
	Sat, 25 Nov 2000 08:31:33 -0800
Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id IAA04288
	for <linux-xfs@oss.sgi.com>; Sat, 25 Nov 2000 08:23:39 -0800 (PST)
	mail_from (cattelan@gibble.americas.sgi.com)
Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id KAA6627400 for <linux-xfs@oss.sgi.com>; Sat, 25 Nov 2000 10:30:16 -0600 (CST)
Received: from gibble.americas.sgi.com (gibble.americas.sgi.com [128.162.195.80]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id KAA15466 for <linux-xfs@oss.sgi.com>; Sat, 25 Nov 2000 10:30:16 -0600 (CST)
Received: (from cattelan@localhost)
	by gibble.americas.sgi.com (8.11.0/8.10.1) id eAPGUGD30756
	for linux-xfs@oss.sgi.com; Sat, 25 Nov 2000 10:30:16 -0600
Date:   Sat, 25 Nov 2000 10:30:16 -0600
From:   Russell Cattelan <cattelan@sgi.com>
Message-Id: <200011251630.eAPGUGD30756@gibble.americas.sgi.com>
Subject: TAKE - 
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

Date:  Sat Nov 25 00:05:45 PST 2000
Workarea:  gibble.americas.sgi.com:/export/extra/x2.4-xfs-clean

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


Modid:  2.4.x-xfs:slinx:78891a
linux/drivers/net/tulip/ChangeLog - 1.1
linux/drivers/usb/pegasus.h - 1.1
linux/drivers/usb/serial/belkin_sa.c - 1.1
linux/drivers/usb/serial/belkin_sa.h - 1.1
linux/Documentation/dnotify.txt - 1.1
linux/drivers/video/sis/Makefile - 1.1
linux/drivers/video/sis/initdef.h - 1.1
linux/drivers/video/sis/sis.h - 1.1
linux/drivers/video/sis/sis_300.c - 1.1
linux/drivers/video/sis/sis_300.h - 1.1
linux/drivers/video/sis/sis_301.c - 1.1
linux/drivers/video/sis/sis_301.h - 1.1
linux/drivers/video/sis/sis_main.c - 1.1
linux/Documentation/networking/netdevices.txt - 1.1
linux/drivers/media/video/tvaudio.h - 1.1
linux/drivers/media/video/tvaudio.c - 1.1
linux/drivers/media/video/id.h - 1.1
linux/Documentation/usb/hotplug.txt - 1.1
linux/drivers/media/video/bttvp.h - 1.1
linux/net/irda/irsyms.c - 1.1
linux/include/asm-alpha/module.h - 1.1
linux/net/irda/irnet/irnet_ppp.h - 1.1
linux/net/irda/irnet/irnet_ppp.c - 1.1
linux/net/irda/irnet/irnet_irda.h - 1.1
linux/Documentation/video4linux/bttv/Specs - 1.1
linux/net/irda/irnet/irnet_irda.c - 1.1
linux/net/irda/irnet/irnet.h - 1.1
linux/net/irda/irnet/Makefile - 1.1
linux/net/irda/irnet/Config.in - 1.1
linux/include/asm-alpha/xor.h - 1.1
linux/include/asm-arm/module.h - 1.1
linux/include/asm-arm/xor.h - 1.1
linux/include/asm-generic/xor.h - 1.1
linux/include/asm-i386/cpufeature.h - 1.1
linux/include/asm-i386/module.h - 1.1
linux/include/asm-i386/xor.h - 1.1
linux/include/asm-ia64/xor.h - 1.1
linux/include/asm-m68k/module.h - 1.1
linux/include/asm-m68k/xor.h - 1.1
linux/include/asm-mips/module.h - 1.1
linux/include/asm-mips/xor.h - 1.1
linux/include/asm-mips64/module.h - 1.1
linux/include/asm-mips64/xor.h - 1.1
linux/include/asm-ppc/module.h - 1.1
linux/include/asm-ppc/xor.h - 1.1
linux/include/asm-s390/module.h - 1.1
linux/include/asm-s390/xor.h - 1.1
linux/include/asm-sh/module.h - 1.1
linux/include/asm-sh/xor.h - 1.1
linux/include/asm-sparc/module.h - 1.1
linux/include/asm-sparc/xor.h - 1.1
linux/include/asm-sparc64/module.h - 1.1
linux/include/asm-sparc64/xor.h - 1.1
linux/include/linux/ethtool.h - 1.1
linux/arch/sparc64/lib/U3memcpy.S - 1.1
linux/arch/sparc64/lib/U3copy_to_user.S - 1.1
linux/arch/sparc64/lib/U3copy_in_user.S - 1.1
linux/arch/sparc64/lib/U3copy_from_user.S - 1.1
linux/kernel/context.c - 1.1
linux/net/x25/x25_out.c - 1.4
linux/net/x25/x25_in.c - 1.6
linux/net/x25/x25_dev.c - 1.7
linux/net/x25/af_x25.c - 1.16
linux/net/unix/garbage.c - 1.7
linux/net/unix/af_unix.c - 1.24
linux/net/sunrpc/sched.c - 1.14
linux/net/socket.c - 1.20
linux/net/netlink/af_netlink.c - 1.11
linux/net/lapb/lapb_in.c - 1.3
linux/net/lapb/lapb_iface.c - 1.6
linux/net/irda/wrapper.c - 1.9
linux/net/irda/timer.c - 1.7
linux/net/irda/qos.c - 1.9
linux/net/irda/irttp.c - 1.11
linux/net/irda/irsysctl.c - 1.4
linux/net/irda/irqueue.c - 1.6
linux/net/irda/irmod.c - 1.16
linux/net/irda/irlmp_frame.c - 1.6
linux/net/irda/irlmp_event.c - 1.9
linux/net/irda/irlmp.c - 1.9
linux/net/irda/irlap_frame.c - 1.11
linux/net/irda/irlap_event.c - 1.10
linux/net/irda/irlap_comp.c - 1.4
linux/net/irda/irlap.c - 1.9
linux/net/irda/irlan/irlan_provider.c - 1.5
linux/net/irda/irlan/irlan_eth.c - 1.13
linux/net/irda/irlan/irlan_common.c - 1.14
linux/net/irda/irlan/irlan_client.c - 1.9
linux/net/irda/irias_object.c - 1.6
linux/net/irda/iriap.c - 1.10
linux/net/irda/irda_device.c - 1.16
linux/net/irda/discovery.c - 1.7
linux/net/irda/compressors/irda_deflate.c - 1.5
linux/net/irda/af_irda.c - 1.16
linux/net/irda/Makefile - 1.5
linux/net/irda/Config.in - 1.7
linux/net/ipx/Config.in - 1.4
linux/net/ipv6/route.c - 1.15
linux/net/ipv6/ndisc.c - 1.10
linux/net/ipv4/tcp_ipv4.c - 1.29
linux/net/ipv4/tcp.c - 1.22
linux/net/ipv4/af_inet.c - 1.22
linux/net/core/sock.c - 1.16
linux/net/core/scm.c - 1.6
linux/net/core/dev.c - 1.29
linux/net/core/datagram.c - 1.8
linux/net/ax25/sysctl_net_ax25.c - 1.3
linux/net/README - 1.7
linux/net/Makefile - 1.13
linux/mm/vmscan.c - 1.39
linux/mm/vmalloc.c - 1.24
linux/mm/swap_state.c - 1.20
linux/mm/mremap.c - 1.18
linux/mm/mprotect.c - 1.12
linux/mm/mmap.c - 1.28
linux/mm/mlock.c - 1.12
linux/mm/memory.c - 1.39
linux/mm/filemap.c - 1.58
linux/kernel/sysctl.c - 1.33
linux/kernel/sched.c - 1.28
linux/kernel/resource.c - 1.13
linux/kernel/module.c - 1.18
linux/kernel/ksyms.c - 1.66
linux/kernel/kmod.c - 1.11
linux/kernel/fork.c - 1.23
linux/kernel/exit.c - 1.23
linux/kernel/Makefile - 1.20
linux/ipc/shm.c - 1.41
linux/init/main.c - 1.45
linux/include/net/x25.h - 1.8
linux/include/net/irda/timer.h - 1.5
linux/include/net/irda/qos.h - 1.6
linux/include/net/irda/irtty.h - 1.8
linux/include/net/irda/irttp.h - 1.8
linux/include/net/irda/irqueue.h - 1.6
linux/include/net/irda/irmod.h - 1.8
linux/include/net/irda/irlmp.h - 1.6
linux/include/net/irda/irlap.h - 1.9
linux/include/net/irda/irlan_common.h - 1.8
linux/include/net/irda/irlan_client.h - 1.3
linux/include/net/irda/irias_object.h - 1.6
linux/include/net/irda/iriap.h - 1.8
linux/include/net/irda/irda_device.h - 1.12
linux/include/net/irda/irda.h - 1.10
linux/include/net/irda/discovery.h - 1.5
linux/include/net/ax25.h - 1.6
linux/include/linux/wrapper.h - 1.8
linux/include/linux/wait.h - 1.9
linux/include/linux/time.h - 1.4
linux/include/linux/sysctl.h - 1.30
linux/include/linux/synclink.h - 1.4
linux/include/linux/sunrpc/sched.h - 1.6
linux/include/linux/sunrpc/debug.h - 1.4
linux/include/linux/soundcard.h - 1.5
linux/include/linux/sockios.h - 1.5
linux/include/linux/sched.h - 1.32
linux/include/linux/rtnetlink.h - 1.8
linux/include/linux/proc_fs.h - 1.26
linux/include/linux/netlink.h - 1.4
linux/include/linux/netdevice.h - 1.19
linux/include/linux/module.h - 1.17
linux/include/linux/mm.h - 1.40
linux/include/linux/lapb.h - 1.3
linux/include/linux/kmod.h - 1.9
linux/include/linux/kernelcapi.h - 1.9
linux/include/linux/kernel.h - 1.14
linux/include/linux/iso_fs.h - 1.8
linux/include/linux/isdn.h - 1.12
linux/include/linux/irda.h - 1.8
linux/include/linux/fs.h - 1.70
linux/include/linux/fb.h - 1.20
linux/include/linux/byteorder/swabb.h - 1.4
linux/include/linux/blk.h - 1.17
linux/include/asm-sparc64/pgtable.h - 1.17
linux/include/asm-sparc64/openpromio.h - 1.4
linux/include/asm-sparc64/ethtool.h - 1.4
linux/include/asm-sparc64/envctrl.h - 1.4
linux/include/asm-sparc64/bpp.h - 1.3
linux/include/asm-sparc/pgtable.h - 1.17
linux/include/asm-sparc/openpromio.h - 1.4
linux/include/asm-sparc/ethtool.h - 1.4
linux/include/asm-sparc/bpp.h - 1.3
linux/include/asm-ppc/vga.h - 1.6
linux/include/asm-ppc/user.h - 1.3
linux/include/asm-ppc/unaligned.h - 1.3
linux/include/asm-ppc/uaccess.h - 1.8
linux/include/asm-ppc/types.h - 1.8
linux/include/asm-ppc/timex.h - 1.4
linux/include/asm-ppc/termbits.h - 1.4
linux/include/asm-ppc/system.h - 1.16
linux/include/asm-ppc/string.h - 1.4
linux/include/asm-ppc/stat.h - 1.6
linux/include/asm-ppc/spinlock.h - 1.9
linux/include/asm-ppc/softirq.h - 1.8
linux/include/asm-ppc/smplock.h - 1.5
linux/include/asm-ppc/smp.h - 1.10
linux/include/asm-ppc/signal.h - 1.4
linux/include/asm-ppc/siginfo.h - 1.6
linux/include/asm-ppc/setup.h - 1.3
linux/include/asm-ppc/serial.h - 1.7
linux/include/asm-ppc/semaphore-helper.h - 1.3
linux/include/asm-ppc/scatterlist.h - 1.3
linux/include/asm-ppc/residual.h - 1.3
linux/include/asm-ppc/raven.h - 1.3
linux/include/asm-ppc/ptrace.h - 1.7
linux/include/asm-ppc/prom.h - 1.8
linux/include/asm-ppc/processor.h - 1.19
linux/include/asm-ppc/prep_nvram.h - 1.3
linux/include/asm-ppc/pnp.h - 1.3
linux/include/asm-ppc/pgtable.h - 1.23
linux/include/asm-ppc/pci-bridge.h - 1.6
linux/include/asm-ppc/param.h - 1.3
linux/include/asm-ppc/page.h - 1.11
linux/include/asm-ppc/nvram.h - 1.5
linux/include/asm-ppc/namei.h - 1.4
linux/include/asm-ppc/mmu_context.h - 1.7
linux/include/asm-ppc/mmu.h - 1.5
linux/include/asm-ppc/mediabay.h - 1.4
linux/include/asm-ppc/md.h - 1.3
linux/include/asm-ppc/mbx.h - 1.5
linux/include/asm-ppc/machdep.h - 1.13
linux/include/asm-ppc/linux_logo.h - 1.5
linux/include/asm-ppc/kgdb.h - 1.3
linux/include/asm-ppc/irq.h - 1.11
linux/include/asm-ppc/io.h - 1.11
linux/include/asm-ppc/init.h - 1.8
linux/include/asm-ppc/ide.h - 1.9
linux/include/asm-ppc/hardirq.h - 1.10
linux/include/asm-ppc/floppy.h - 1.3
linux/include/asm-ppc/feature.h - 1.8
linux/include/asm-ppc/elf.h - 1.7
linux/include/asm-ppc/dma.h - 1.6
linux/include/asm-ppc/delay.h - 1.3
linux/include/asm-ppc/dbdma.h - 1.3
linux/include/asm-ppc/current.h - 1.3
linux/include/asm-ppc/checksum.h - 1.3
linux/include/asm-ppc/cache.h - 1.7
linux/include/asm-ppc/byteorder.h - 1.5
linux/include/asm-ppc/bootinfo.h - 1.5
linux/include/asm-ppc/bitops.h - 1.8
linux/include/asm-ppc/amigappc.h - 1.4
linux/include/asm-ppc/amigaints.h - 1.4
linux/include/asm-ppc/amigahw.h - 1.4
linux/include/asm-ppc/8xx_immap.h - 1.3
linux/include/asm-mips/pgtable.h - 1.12
linux/include/asm-m68k/pgtable.h - 1.12
linux/include/asm-i386/processor.h - 1.19
linux/include/asm-i386/pgtable.h - 1.22
linux/include/asm-i386/elf.h - 1.6
linux/include/asm-i386/bugs.h - 1.13
linux/include/asm-arm/pgtable.h - 1.16
linux/include/asm-alpha/spinlock.h - 1.10
linux/include/asm-alpha/semaphore.h - 1.5
linux/include/asm-alpha/semaphore-helper.h - 1.5
linux/include/asm-alpha/pgtable.h - 1.23
linux/include/asm-alpha/param.h - 1.4
linux/include/asm-alpha/compiler.h - 1.6
linux/include/asm-alpha/atomic.h - 1.6
linux/fs/umsdos/emd.c - 1.6
linux/fs/umsdos/dir.c - 1.14
linux/fs/ufs/ialloc.c - 1.8
linux/fs/sysv/ialloc.c - 1.6
linux/fs/smbfs/inode.c - 1.16
linux/fs/smbfs/cache.c - 1.9
linux/fs/select.c - 1.13
linux/fs/proc/root.c - 1.21
linux/fs/proc/inode.c - 1.12
linux/fs/proc/generic.c - 1.17
linux/fs/proc/base.c - 1.21
linux/fs/proc/array.c - 1.25
linux/fs/pipe.c - 1.20
linux/fs/ntfs/super.c - 1.7
linux/fs/ntfs/inode.c - 1.6
linux/fs/ntfs/fs.c - 1.21
linux/fs/nfsd/vfs.c - 1.30
linux/fs/nfs/write.c - 1.21
linux/fs/nfs/symlink.c - 1.12
linux/fs/nfs/read.c - 1.18
linux/fs/nfs/inode.c - 1.20
linux/fs/nfs/dir.c - 1.23
linux/fs/ncpfs/symlink.c - 1.11
linux/fs/ncpfs/ncplib_kernel.c - 1.8
linux/fs/ncpfs/mmap.c - 1.11
linux/fs/ncpfs/ioctl.c - 1.13
linux/fs/ncpfs/inode.c - 1.17
linux/fs/ncpfs/file.c - 1.13
linux/fs/ncpfs/dir.c - 1.22
linux/fs/namei.c - 1.22
linux/fs/minix/bitmap.c - 1.10
linux/fs/locks.c - 1.13
linux/fs/lockd/svclock.c - 1.10
linux/fs/lockd/clntproc.c - 1.11
linux/fs/lockd/clntlock.c - 1.8
linux/fs/isofs/rock.c - 1.9
linux/fs/isofs/namei.c - 1.3
linux/fs/isofs/joliet.c - 1.4
linux/fs/isofs/inode.c - 1.18
linux/fs/isofs/dir.c - 1.9
linux/fs/file_table.c - 1.12
linux/fs/fcntl.c - 1.14
linux/fs/fat/inode.c - 1.17
linux/fs/ext2/ialloc.c - 1.12
linux/fs/exec.c - 1.33
linux/fs/dquot.c - 1.19
linux/fs/devpts/inode.c - 1.8
linux/fs/coda/symlink.c - 1.10
linux/fs/buffer.c - 1.46
linux/fs/autofs/inode.c - 1.7
linux/fs/affs/symlink.c - 1.10
linux/fs/affs/inode.c - 1.10
linux/fs/adfs/inode.c - 1.13
linux/fs/Config.in - 1.47
linux/drivers/video/virgefb.c - 1.10
linux/drivers/video/vgacon.c - 1.13
linux/drivers/video/vfb.c - 1.7
linux/drivers/video/tgafb.c - 1.12
linux/drivers/video/retz3fb.c - 1.9
linux/drivers/video/hpfb.c - 1.9
linux/drivers/video/g364fb.c - 1.8
linux/drivers/video/fm2fb.c - 1.8
linux/drivers/video/cyberfb.c - 1.10
linux/drivers/video/clgenfb.c - 1.15
linux/drivers/video/atafb.c - 1.8
linux/drivers/video/amifb.c - 1.12
linux/drivers/video/S3triofb.c - 1.8
linux/drivers/video/Makefile - 1.27
linux/drivers/usb/usb.c - 1.41
linux/drivers/usb/hub.c - 1.31
linux/drivers/usb/audio.c - 1.26
linux/drivers/usb/Config.in - 1.37
linux/drivers/sound/yss225.c - 1.3
linux/drivers/sound/wavfront.c - 1.11
linux/drivers/sound/waveartist.c - 1.12
linux/drivers/sound/sscape.c - 1.10
linux/drivers/sound/sonicvibes.c - 1.26
linux/drivers/sound/sgalaxy.c - 1.8
linux/drivers/sound/pss.c - 1.7
linux/drivers/sound/pas2_pcm.c - 1.7
linux/drivers/sound/pas2_mixer.c - 1.8
linux/drivers/sound/pas2_midi.c - 1.7
linux/drivers/sound/msnd_pinnacle.c - 1.13
linux/drivers/sound/msnd.c - 1.6
linux/drivers/sound/mpu401.c - 1.9
linux/drivers/sound/maui.c - 1.8
linux/drivers/sound/iwmem.h - 1.3
linux/drivers/sound/ics2101.c - 1.7
linux/drivers/sound/gus_wave.c - 1.6
linux/drivers/sound/gus_midi.c - 1.7
linux/drivers/sound/es1370.c - 1.25
linux/drivers/sound/cs4232.c - 1.8
linux/drivers/sound/ad1816.c - 1.10
linux/drivers/scsi/wd7000.c - 1.9
linux/drivers/scsi/t128.c - 1.7
linux/drivers/scsi/sym53c416.c - 1.7
linux/drivers/scsi/st.c - 1.26
linux/drivers/scsi/sr_ioctl.c - 1.13
linux/drivers/scsi/sgiwd93.c - 1.10
linux/drivers/scsi/seagate.c - 1.11
linux/drivers/scsi/scsi_obsolete.c - 1.9
linux/drivers/scsi/scsi_ioctl.c - 1.15
linux/drivers/scsi/scsi_error.c - 1.16
linux/drivers/scsi/scsi_debug.c - 1.13
linux/drivers/scsi/psi240i.c - 1.6
linux/drivers/scsi/ppa.c - 1.6
linux/drivers/scsi/pluto.c - 1.10
linux/drivers/scsi/pci2220i.c - 1.13
linux/drivers/scsi/pci2000.c - 1.13
linux/drivers/scsi/pas16.c - 1.8
linux/drivers/scsi/megaraid.c - 1.18
linux/drivers/scsi/mac_scsi.c - 1.8
linux/drivers/scsi/mac53c94.c - 1.7
linux/drivers/scsi/inia100.c - 1.13
linux/drivers/scsi/ini9100u.c - 1.12
linux/drivers/scsi/in2000.c - 1.6
linux/drivers/scsi/imm.c - 1.8
linux/drivers/scsi/ibmmca.c - 1.9
linux/drivers/scsi/gvp11.c - 1.9
linux/drivers/scsi/gdth_proc.c - 1.7
linux/drivers/scsi/gdth.c - 1.10
linux/drivers/scsi/g_NCR5380.c - 1.9
linux/drivers/scsi/fdomain.c - 1.12
linux/drivers/scsi/fcal.c - 1.7
linux/drivers/scsi/esp.c - 1.15
linux/drivers/scsi/eata_pio.c - 1.10
linux/drivers/scsi/eata_dma_proc.c - 1.7
linux/drivers/scsi/eata_dma.c - 1.13
linux/drivers/scsi/dtc.c - 1.7
linux/drivers/scsi/atp870u.c - 1.11
linux/drivers/scsi/atari_scsi.c - 1.6
linux/drivers/scsi/aha1740.c - 1.5
linux/drivers/scsi/aha1542.c - 1.12
linux/drivers/scsi/aha152x.h - 1.5
linux/drivers/scsi/aha152x.c - 1.15
linux/drivers/scsi/advansys.c - 1.15
linux/drivers/scsi/a3000.c - 1.8
linux/drivers/scsi/a2091.c - 1.10
linux/drivers/scsi/Config.in - 1.17
linux/drivers/scsi/BusLogic.c - 1.11
linux/drivers/scsi/AM53C974.h - 1.4
linux/drivers/scsi/AM53C974.c - 1.9
linux/drivers/scsi/53c7xx.c - 1.10
linux/drivers/sbus/sbus.c - 1.9
linux/drivers/sbus/char/su.c - 1.12
linux/drivers/sbus/char/sab82532.c - 1.13
linux/drivers/sbus/char/openprom.c - 1.8
linux/drivers/sbus/char/flash.c - 1.9
linux/drivers/sbus/char/envctrl.c - 1.10
linux/drivers/sbus/char/bpp.c - 1.14
linux/drivers/pci/proc.c - 1.18
linux/drivers/pci/pci.c - 1.31
linux/drivers/net/wd.c - 1.9
linux/drivers/net/sunhme.h - 1.8
linux/drivers/net/sunhme.c - 1.21
linux/drivers/net/smc9194.c - 1.8
linux/drivers/net/smc-ultra32.c - 1.10
linux/drivers/net/smc-ultra.c - 1.11
linux/drivers/net/smc-mca.c - 1.9
linux/drivers/net/seeq8005.c - 1.10
linux/drivers/net/rrunner.c - 1.13
linux/drivers/net/ne3210.c - 1.9
linux/drivers/net/ne2k-pci.c - 1.16
linux/drivers/net/ne2.c - 1.10
linux/drivers/net/ne.c - 1.11
linux/drivers/net/lne390.c - 1.10
linux/drivers/net/lance.c - 1.13
linux/drivers/net/irda/w83977af_ir.c - 1.16
linux/drivers/net/irda/irtty.c - 1.17
linux/drivers/net/irda/irport.c - 1.17
linux/drivers/net/hp.c - 1.8
linux/drivers/net/hp-plus.c - 1.9
linux/drivers/net/hamradio/soundmodem/sm.h - 1.6
linux/drivers/net/hamradio/baycom_epp.c - 1.13
linux/drivers/net/fmv18x.c - 1.9
linux/drivers/net/eth16i.c - 1.12
linux/drivers/net/es3210.c - 1.10
linux/drivers/net/e2100.c - 1.9
linux/drivers/net/de620.c - 1.8
linux/drivers/net/de600.c - 1.9
linux/drivers/net/de4x5.c - 1.17
linux/drivers/net/cs89x0.c - 1.14
linux/drivers/net/bmac.c - 1.12
linux/drivers/net/atp.c - 1.11
linux/drivers/net/atarilance.c - 1.5
linux/drivers/net/atari_pamsnet.c - 1.7
linux/drivers/net/atari_bionet.c - 1.7
linux/drivers/net/at1700.c - 1.9
linux/drivers/net/ariadne2.c - 1.9
linux/drivers/net/apne.c - 1.7
linux/drivers/net/am79c961a.c - 1.9
linux/drivers/net/acenic.c - 1.20
linux/drivers/net/ac3200.c - 1.11
linux/drivers/net/a2065.c - 1.11
linux/drivers/net/Space.c - 1.27
linux/drivers/net/Config.in - 1.32
linux/drivers/net/82596.c - 1.13
linux/drivers/net/3c59x.c - 1.21
linux/drivers/net/3c527.c - 1.14
linux/drivers/net/3c523.c - 1.11
linux/drivers/net/3c515.c - 1.14
linux/drivers/net/3c509.c - 1.17
linux/drivers/net/3c507.c - 1.15
linux/drivers/net/3c505.c - 1.15
linux/drivers/net/3c503.c - 1.12
linux/drivers/net/3c501.c - 1.10
linux/drivers/macintosh/via-pmu.c - 1.12
linux/drivers/isdn/sc/debug.c - 1.4
linux/drivers/isdn/pcbit/drv.c - 1.7
linux/drivers/isdn/isdnloop/isdnloop.h - 1.4
linux/drivers/isdn/isdnloop/isdnloop.c - 1.4
linux/drivers/isdn/isdn_ppp.c - 1.9
linux/drivers/isdn/isdn_net.c - 1.14
linux/drivers/isdn/isdn_common.c - 1.16
linux/drivers/isdn/isdn_cards.c - 1.6
linux/drivers/isdn/icn/icn.h - 1.4
linux/drivers/isdn/icn/icn.c - 1.9
linux/drivers/isdn/hisax/config.c - 1.12
linux/drivers/isdn/avmb1/capidrv.c - 1.12
linux/drivers/isdn/avmb1/capi.c - 1.15
linux/drivers/isdn/avmb1/b1pci.c - 1.9
linux/drivers/isdn/avmb1/Makefile - 1.8
linux/drivers/isdn/act2000/module.c - 1.5
linux/drivers/isdn/act2000/capi.h - 1.4
linux/drivers/isdn/act2000/capi.c - 1.4
linux/drivers/isdn/act2000/act2000_isa.h - 1.4
linux/drivers/isdn/act2000/act2000_isa.c - 1.4
linux/drivers/isdn/act2000/act2000.h - 1.3
linux/drivers/isdn/act2000/Makefile - 1.3
linux/drivers/isdn/Config.in - 1.11
linux/drivers/char/synclink.c - 1.11
linux/drivers/char/rtc.c - 1.18
linux/drivers/char/random.c - 1.12
linux/drivers/char/n_hdlc.c - 1.9
linux/drivers/char/mem.c - 1.28
linux/drivers/char/ftape/lowlevel/ftape-ctl.c - 1.5
linux/drivers/char/defkeymap.c - 1.7
linux/drivers/char/cyclades.c - 1.15
linux/drivers/char/console.c - 1.19
linux/drivers/char/Config.in - 1.39
linux/drivers/block/rd.c - 1.25
linux/drivers/block/loop.c - 1.26
linux/drivers/block/ll_rw_blk.c - 1.51
linux/drivers/acorn/net/etherh.c - 1.9
linux/arch/sparc64/solaris/socket.c - 1.5
linux/arch/sparc64/solaris/ioctl.c - 1.9
linux/arch/sparc64/mm/ultra.S - 1.14
linux/arch/sparc64/mm/init.c - 1.20
linux/arch/sparc64/lib/VIScopy.S - 1.6
linux/arch/sparc64/lib/Makefile - 1.8
linux/arch/sparc64/kernel/sys_sunos32.c - 1.24
linux/arch/sparc64/kernel/sys_sparc32.c - 1.29
linux/arch/sparc64/kernel/sparc64_ksyms.c - 1.23
linux/arch/sparc64/kernel/process.c - 1.16
linux/arch/sparc64/kernel/itlb_base.S - 1.5
linux/arch/sparc64/kernel/ioctl32.c - 1.27
linux/arch/sparc64/kernel/ebus.c - 1.9
linux/arch/sparc64/kernel/dtlb_prot.S - 1.5
linux/arch/sparc64/kernel/dtlb_base.S - 1.5
linux/arch/sparc64/config.in - 1.33
linux/arch/sparc/mm/sun4c.c - 1.22
linux/arch/sparc/mm/srmmu.c - 1.20
linux/arch/sparc/mm/init.c - 1.21
linux/arch/sparc/kernel/pcic.c - 1.13
linux/arch/sparc/kernel/ebus.c - 1.8
linux/arch/sparc/config.in - 1.24
linux/arch/ppc/mm/init.c - 1.29
linux/arch/ppc/kernel/process.c - 1.24
linux/arch/ppc/kernel/ppc_ksyms.c - 1.26
linux/arch/ppc/kernel/pci.c - 1.16
linux/arch/ppc/kernel/misc.S - 1.22
linux/arch/ppc/kernel/irq.c - 1.23
linux/arch/ppc/kernel/head.S - 1.22
linux/arch/ppc/defconfig - 1.26
linux/arch/ppc/config.in - 1.31
linux/arch/ppc/8xx_io/commproc.c - 1.6
linux/arch/mips/config.in - 1.20
linux/arch/m68k/config.in - 1.19
linux/arch/i386/mm/fault.c - 1.14
linux/arch/i386/kernel/traps.c - 1.31
linux/arch/i386/kernel/setup.c - 1.39
linux/arch/i386/kernel/mtrr.c - 1.22
linux/arch/i386/kernel/i386_ksyms.c - 1.32
linux/arch/i386/kernel/apm.c - 1.28
linux/arch/i386/defconfig - 1.48
linux/arch/i386/config.in - 1.50
linux/arch/i386/Makefile - 1.19
linux/arch/arm/config.in - 1.23
linux/arch/alpha/lib/semaphore.S - 1.4
linux/arch/alpha/lib/Makefile - 1.8
linux/arch/alpha/kernel/time.c - 1.15
linux/arch/alpha/kernel/irq.c - 1.15
linux/arch/alpha/kernel/alpha_ksyms.c - 1.17
linux/arch/alpha/config.in - 1.26
linux/Makefile - 1.72
linux/MAINTAINERS - 1.49
linux/Documentation/video4linux/bttv/README - 1.10
linux/Documentation/networking/x25-iface.txt - 1.3
linux/Documentation/networking/tulip.txt - 1.8
linux/Documentation/networking/lapb-module.txt - 1.3
linux/Documentation/networking/ip-sysctl.txt - 1.7
linux/Documentation/isdn/README.icn - 1.4
linux/Documentation/isdn/README.act2000 - 1.4
linux/Documentation/fb/matroxfb.txt - 1.6
linux/Documentation/Configure.help - 1.65
linux/Documentation/00-INDEX - 1.8
linux/CREDITS - 1.45
linux/net/decnet/sysctl_net_decnet.c - 1.8
linux/net/decnet/dn_route.c - 1.15
linux/net/decnet/dn_nsp_out.c - 1.8
linux/net/decnet/dn_nsp_in.c - 1.11
linux/net/decnet/dn_dev.c - 1.10
linux/net/decnet/af_decnet.c - 1.18
linux/net/decnet/TODO - 1.7
linux/net/decnet/Config.in - 1.7
linux/include/net/dn_nsp.h - 1.3
linux/include/linux/dn.h - 1.2
linux/fs/hpfs/namei.c - 1.11
linux/fs/efs/symlink.c - 1.8
linux/fs/efs/dir.c - 1.8
linux/drivers/usb/printer.c - 1.30
linux/drivers/usb/acm.c - 1.33
linux/drivers/sound/cmpci.c - 1.20
linux/drivers/sbus/char/aurora.c - 1.5
linux/drivers/net/irda/toshoboe.c - 1.19
linux/drivers/net/irda/smc-ircc.c - 1.15
linux/drivers/i2o/i2o_proc.c - 1.13
linux/drivers/i2o/i2o_core.c - 1.23
linux/drivers/i2o/i2o_block.c - 1.19
linux/Documentation/isdn/README.eicon - 1.7
linux/drivers/net/bagetlance.c - 1.6
linux/drivers/net/arlan.c - 1.11
linux/drivers/block/cpqarray.c - 1.18
linux/kernel/ptrace.c - 1.11
linux/drivers/char/sx.c - 1.14
linux/drivers/char/generic_serial.c - 1.9
linux/drivers/usb/uss720.c - 1.15
linux/drivers/sound/esssolo1.c - 1.22
linux/net/khttpd/main.c - 1.7
linux/net/khttpd/datasending.c - 1.7
linux/net/khttpd/README - 1.2
linux/drivers/isdn/hisax/hfc_pci.c - 1.11
linux/drivers/isdn/divert/isdn_divert.h - 1.4
linux/drivers/isdn/divert/isdn_divert.c - 1.4
linux/drivers/isdn/divert/divert_procfs.c - 1.11
linux/drivers/isdn/divert/divert_init.c - 1.3
linux/drivers/isdn/avmb1/t1isa.c - 1.8
linux/drivers/isdn/avmb1/b1pcmcia.c - 1.8
linux/drivers/isdn/avmb1/b1isa.c - 1.6
linux/drivers/isdn/avmb1/b1.c - 1.8
linux/drivers/isdn/avmb1/avmcard.h - 1.4
linux/arch/i386/kernel/i8259.c - 1.20
linux/drivers/sound/vwsnd.c - 1.10
linux/drivers/net/sis900.c - 1.16
linux/drivers/net/fc/iph5526.c - 1.9
linux/drivers/atm/nicstar.c - 1.10
linux/drivers/atm/atmtcp.c - 1.6
linux/arch/i386/kernel/semaphore.c - 1.14
linux/arch/alpha/kernel/semaphore.c - 1.4
linux/net/atm/svc.c - 1.9
linux/net/atm/signaling.c - 1.5
linux/net/atm/pvc.c - 1.8
linux/include/linux/netfilter_decnet.h - 1.3
linux/arch/ppc/kernel/semaphore.c - 1.3
linux/arch/ppc/kernel/hashtable.S - 1.8
linux/arch/ppc/kernel/entry.S - 1.16
linux/arch/arm/kernel/semaphore.c - 1.8
linux/arch/sparc64/kernel/semaphore.c - 1.5
linux/arch/sparc64/kernel/pci.c - 1.14
linux/arch/sparc/kernel/semaphore.c - 1.4
linux/arch/sh/kernel/semaphore.c - 1.5
linux/arch/sh/config.in - 1.14
linux/drivers/sound/maestro.c - 1.17
linux/drivers/scsi/ips.c - 1.12
linux/net/irda/parameters.c - 1.7
linux/net/irda/ircomm/ircomm_tty_attach.c - 1.7
linux/net/irda/ircomm/ircomm_tty.c - 1.10
linux/net/irda/ircomm/ircomm_core.c - 1.8
linux/include/net/irda/ircomm_tty.h - 1.7
linux/include/net/irda/ircomm_core.h - 1.4
linux/include/asm-sh/pgtable.h - 1.14
linux/include/asm-ppc/gemini_serial.h - 1.5
linux/include/asm-ppc/gemini.h - 1.3
linux/drivers/pcmcia/tcic.c - 1.10
linux/drivers/pcmcia/i82365.c - 1.15
linux/drivers/pcmcia/cs.c - 1.24
linux/drivers/pcmcia/cardbus.c - 1.15
linux/drivers/pcmcia/Config.in - 1.7
linux/drivers/nubus/proc.c - 1.6
linux/arch/m68k/kernel/semaphore.c - 1.4
linux/fs/udf/ialloc.c - 1.8
linux/fs/udf/file.c - 1.19
linux/fs/udf/dir.c - 1.12
linux/fs/udf/inode.c - 1.17
linux/fs/udf/symlink.c - 1.9
linux/include/asm-ppc/pci.h - 1.8
linux/drivers/sbus/char/uctrl.c - 1.8
linux/drivers/net/pcmcia/Config.in - 1.20
linux/drivers/char/drm/memory.c - 1.6
linux/drivers/char/drm/gamma_drv.c - 1.10
linux/drivers/char/drm/drmP.h - 1.10
linux/drivers/char/drm/dma.c - 1.7
linux/include/linux/acpi.h - 1.16
linux/drivers/sound/nm256_audio.c - 1.10
linux/arch/i386/lib/mmx.c - 1.3
linux/arch/i386/kernel/smpboot.c - 1.17
linux/include/linux/pci_ids.h - 1.28
linux/drivers/net/wan/x25_asy.c - 1.6
linux/include/asm-ppc/rpxlite.h - 1.2
linux/drivers/net/wan/lapbether.c - 1.5
linux/include/asm-ppc/rpxclassic.h - 1.4
linux/include/asm-ppc/mpc8xx.h - 1.4
linux/mm/highmem.c - 1.17
linux/include/linux/highmem.h - 1.10
linux/include/asm-i386/highmem.h - 1.6
linux/fs/proc/proc_misc.c - 1.16
linux/fs/bfs/dir.c - 1.12
linux/drivers/usb/dc2xx.c - 1.13
linux/drivers/net/sis900.h - 1.6
linux/drivers/isdn/avmb1/t1pci.c - 1.8
linux/drivers/isdn/hisax/w6692.c - 1.6
linux/drivers/scsi/sun3_scsi.c - 1.5
linux/drivers/pci/pci.ids - 1.24
linux/Documentation/networking/sis900.txt - 1.4
linux/include/asm-ppc/pgalloc.h - 1.4
linux/arch/ppc/configs/walnut_defconfig - 1.7
linux/arch/ppc/configs/oak_defconfig - 1.7
linux/arch/ppc/configs/mbx_defconfig - 1.2
linux/arch/ppc/configs/gemini_defconfig - 1.9
linux/arch/ppc/configs/common_defconfig - 1.14
linux/arch/ppc/configs/apus_defconfig - 1.3
linux/include/asm-ppc/walnut.h - 1.2
linux/include/asm-ppc/oak.h - 1.3
linux/include/asm-ppc/board.h - 1.3
linux/drivers/sound/trident.c - 1.17
linux/include/linux/agp_backend.h - 1.7
linux/drivers/net/aironet4500_core.c - 1.10
linux/drivers/net/aironet4500_card.c - 1.8
linux/drivers/char/drm/tdfx_drv.c - 1.8
linux/drivers/char/agp/agpgart_be.c - 1.12
linux/drivers/char/agp/agp.h - 1.8
linux/Documentation/video4linux/bttv/Sound-FAQ - 1.4
linux/drivers/usb/dabusb.c - 1.8
linux/Documentation/video4linux/bttv/CARDLIST - 1.8
linux/Documentation/video4linux/bttv/Insmod-options - 1.6
linux/drivers/pcmcia/yenta.c - 1.21
linux/drivers/pcmcia/pci_socket.h - 1.6
linux/drivers/pcmcia/pci_socket.c - 1.6
linux/arch/i386/kernel/acpi.c - 1.20
linux/include/asm-sparc64/pgalloc.h - 1.8
linux/include/asm-ppc/hw_irq.h - 1.4
linux/fs/cramfs/inode.c - 1.12
linux/drivers/usb/scanner.c - 1.16
linux/drivers/usb/usbmouse.c - 1.8
linux/drivers/usb/usbkbd.c - 1.11
linux/drivers/usb/ov511.c - 1.18
linux/drivers/usb/hid.c - 1.19
linux/drivers/telephony/ixj.c - 1.9
linux/Documentation/usb/usb-serial.txt - 1.11
linux/Documentation/usb/ov511.txt - 1.14
linux/drivers/net/oaknet.c - 1.5
linux/drivers/usb/devio.c - 1.12
linux/arch/i386/kernel/apic.c - 1.13
linux/arch/i386/kernel/mpparse.c - 1.8
linux/drivers/char/mxser.c - 1.5
linux/include/asm-ppc/shmbuf.h - 1.2
linux/include/asm-ppc/sembuf.h - 1.2
linux/include/asm-ppc/msgbuf.h - 1.2
linux/include/asm-ppc/ipcbuf.h - 1.2
linux/drivers/scsi/3w-xxxx.c - 1.7
linux/drivers/usb/usb-ohci.c - 1.16
linux/drivers/usb/scanner.h - 1.10
linux/drivers/usb/ibmcam.c - 1.9
linux/fs/autofs4/inode.c - 1.7
linux/drivers/net/irda/nsc-ircc.c - 1.9
linux/arch/ia64/kernel/semaphore.c - 1.6
linux/arch/ia64/ia32/sys_ia32.c - 1.10
linux/arch/ia64/config.in - 1.14
linux/drivers/net/gmac.c - 1.6
linux/include/linux/raid/md_u.h - 1.4
linux/include/linux/raid/md_p.h - 1.3
linux/include/linux/raid/md_k.h - 1.7
linux/include/linux/raid/md_compatible.h - 1.3
linux/include/linux/raid/md.h - 1.5
linux/drivers/net/8139too.c - 1.13
linux/drivers/isdn/avmb1/c4.c - 1.8
linux/drivers/isdn/avmb1/b1dma.c - 1.9
linux/drivers/usb/plusb.h - 1.2
linux/drivers/isdn/hysdn/boardergo.h - 1.2
linux/drivers/usb/plusb.c - 1.7
linux/drivers/isdn/hysdn/hysdn_defs.h - 1.3
linux/drivers/isdn/hysdn/hysdn_init.c - 1.4
linux/drivers/isdn/hysdn/hysdn_net.c - 1.4
linux/drivers/isdn/hysdn/hysdn_pof.h - 1.2
linux/drivers/isdn/hysdn/hysdn_procconf.c - 1.7
linux/fs/devfs/base.c - 1.12
linux/drivers/isdn/hysdn/hysdn_proclog.c - 1.7
linux/drivers/isdn/hysdn/hysdn_sched.c - 1.3
linux/drivers/isdn/hysdn/boardergo.c - 1.4
linux/drivers/isdn/hysdn/hysdn_boot.c - 1.3
linux/Documentation/networking/bridge.txt - 1.2
linux/net/bridge/br_fdb.c - 1.3
linux/net/bridge/br_ioctl.c - 1.4
linux/net/bridge/br_if.c - 1.5
linux/arch/mips/kernel/semaphore.c - 1.2
linux/drivers/net/tulip/tulip_core.c - 1.13
linux/drivers/net/tulip/tulip.h - 1.7
linux/drivers/net/tulip/timer.c - 1.5
linux/drivers/net/tulip/interrupt.c - 1.6
linux/drivers/net/tulip/21142.c - 1.5
linux/include/asm-mips64/pgtable.h - 1.6
linux/arch/mips64/config.in - 1.10
linux/arch/mips64/kernel/semaphore.c - 1.2
linux/arch/mips64/kernel/linux32.c - 1.5
linux/drivers/video/riva/fbdev.c - 1.9
linux/drivers/usb/wacom.c - 1.8
linux/drivers/usb/rio500.c - 1.6
linux/drivers/usb/pegasus.c - 1.12
linux/drivers/net/appletalk/cops.c - 1.5
linux/include/linux/usb.h - 1.11
linux/drivers/usb/serial/usb-serial.h - 1.11
linux/drivers/usb/serial/Makefile - 1.10
linux/drivers/sound/awe_wave.c - 1.5
linux/drivers/sound/aci.c - 1.3
linux/drivers/ide/via82cxxx.c - 1.11
linux/drivers/ide/sl82c105.c - 1.3
linux/drivers/ide/sis5513.c - 1.7
linux/drivers/ide/opti621.c - 1.4
linux/drivers/ide/ide-pci.c - 1.9
linux/drivers/ide/icside.c - 1.7
linux/drivers/ide/hpt366.c - 1.5
linux/drivers/ide/hd.c - 1.6
linux/drivers/ide/amd7409.c - 1.6
linux/drivers/ide/alim15x3.c - 1.7
linux/drivers/ide/Makefile - 1.7
linux/drivers/usb/dsbr100.c - 1.6
linux/drivers/net/wan/comx.c - 1.8
linux/drivers/net/wan/comx-proto-lapb.c - 1.4
linux/drivers/net/pcmcia/xircom_tulip_cb.c - 1.8
linux/drivers/isdn/avmb1/capifs.c - 1.6
linux/drivers/usb/mdc800.c - 1.6
linux/drivers/sound/dmasound/dmasound_core.c - 1.5
linux/drivers/sound/dmasound/dmasound_atari.c - 1.3
linux/drivers/sound/dmasound/dmasound.h - 1.3
linux/drivers/scsi/dmx3191d.c - 1.4
linux/arch/i386/kernel/pci-irq.c - 1.7
linux/fs/ramfs/inode.c - 1.8
linux/drivers/usb/serial/keyspan_pda.c - 1.8
linux/drivers/usb/serial/ftdi_sio.c - 1.9
linux/drivers/usb/serial/usbserial.c - 1.9
linux/drivers/usb/serial/whiteheat.c - 1.8
linux/drivers/usb/serial/visor.c - 1.8
linux/drivers/usb/serial/omninet.c - 1.7
linux/drivers/sound/i810_audio.c - 1.5
linux/drivers/sound/emu10k1/emu_wrapper.h - 1.4
linux/include/linux/nfs_page.h - 1.3
linux/include/asm-ppc/mpc8260.h - 1.2
linux/include/asm-ppc/immap_8260.h - 1.3
linux/include/asm-ppc/cpm_8260.h - 1.4
linux/drivers/usb/serial/digi_acceleport.c - 1.6
linux/drivers/net/pppoe.c - 1.7
linux/arch/ppc/kernel/ppc8260_pic.c - 1.2
linux/drivers/char/rio/rio_linux.c - 1.6
linux/include/linux/raid/xor.h - 1.2
linux/arch/s390/config.in - 1.5
linux/drivers/s390/char/con3215.c - 1.4
linux/include/asm-s390/pgtable.h - 1.5
linux/arch/s390/kernel/semaphore.c - 1.3
linux/drivers/net/stnic.c - 1.4
linux/include/linux/sisfb.h - 1.2
linux/drivers/video/sisfb.c - 1.6
linux/arch/i386/kernel/msr.c - 1.4
linux/kdb/kdb_bt.c - 1.7
linux/include/linux/kdbprivate.h - 1.7
linux/include/linux/kdb.h - 1.11
linux/kdb/kdbsupport.c - 1.7
linux/kdb/kdbmain.c - 1.14
linux/include/linux/dis-asm.h - 1.5
linux/kdb/kdb_io.c - 1.7
linux/include/asm-i386/kdbprivate.h - 1.8
linux/arch/i386/kdb/kdba_id.c - 1.6
linux/kdb/kdb_id.c - 1.6
linux/arch/i386/kdb/kdbasupport.c - 1.10
linux/arch/i386/kdb/i386-dis.c - 1.6
linux/arch/i386/kdb/kdba_io.c - 1.8
linux/drivers/char/joystick/sidewinder.c - 1.3
linux/drivers/char/joystick/ns558.c - 1.4
linux/drivers/char/joystick/analog.c - 1.2
linux/drivers/char/joystick/adi.c - 1.2
linux/include/asm-ppc/backlight.h - 1.3
linux/drivers/char/drm/r128_drv.c - 1.4
linux/drivers/char/drm/r128_drm.h - 1.2
linux/drivers/char/drm/mga_state.c - 1.4
linux/drivers/char/drm/mga_drv.c - 1.4
linux/include/asm-ppc/mc146818rtc.h - 1.2
linux/drivers/char/drm/i810_drv.c - 1.4
linux/drivers/char/drm/ffb_drv.c - 1.3
linux/include/asm-ppc/time.h - 1.3
linux/include/asm-ppc/tqm860.h - 1.2
linux/drivers/char/drm/agpsupport.c - 1.3
linux/drivers/usb/storage/usb.c - 1.5
linux/drivers/usb/storage/transport.c - 1.5
linux/drivers/usb/storage/scsiglue.c - 1.5
linux/include/asm-ppc/tqm8xxL.h - 1.2
linux/drivers/usb/serial/keyspan.h - 1.2
linux/drivers/usb/serial/keyspan.c - 1.4
linux/include/asm-i386/i387.h - 1.3
linux/drivers/usb/microtek.c - 1.4
linux/drivers/usb/bluetooth.c - 1.4
linux/fs/jffs/inode-v23.c - 1.3
linux/fs/jffs/intrep.c - 1.3
linux/drivers/sound/ymf_sb.c - 1.4
linux/drivers/sound/724hwmcode.h - 1.2
linux/arch/i386/kernel/i387.c - 1.3
linux/drivers/acpi/driver.c - 1.3
linux/drivers/mtd/Makefile - 1.3
linux/drivers/mtd/cfi_cmdset_0001.c - 1.2
linux/drivers/mtd/cfi_cmdset_0002.c - 1.3
linux/drivers/mtd/cfi_probe.c - 1.2
linux/drivers/mtd/doc2000.c - 1.2
linux/drivers/mtd/doc2001.c - 1.2
linux/drivers/mtd/docprobe.c - 1.2
linux/drivers/mtd/map_ram.c - 1.2
linux/drivers/net/ibmlana.c - 1.2
linux/arch/ppc/configs/rpxlite_defconfig - 1.2
linux/arch/ppc/configs/rpxcllf_defconfig - 1.3
linux/arch/ppc/configs/est8260_defconfig - 1.3
linux/arch/ppc/configs/bseip_defconfig - 1.2
linux/include/linux/mtd/cfi.h - 1.2
linux/include/linux/mtd/map.h - 1.2
linux/include/asm-sparc/highmem.h - 1.2
linux/Documentation/cachetlb.txt - 1.3
linux/drivers/sound/cs46xx.c - 1.3
linux/drivers/sound/cs461x_image.h - 1.2
linux/drivers/sbus/char/display7seg.c - 1.2
linux/drivers/media/video/zr36120.c - 1.2
linux/drivers/media/video/vino.c - 1.2
linux/drivers/media/video/tvmixer.c - 1.2
linux/drivers/media/video/tuner.h - 1.2
linux/drivers/media/video/tuner.c - 1.2
linux/drivers/media/video/tea6420.c - 1.2
linux/drivers/media/video/tea6300.c - 1.3
linux/drivers/media/video/tda9875.c - 1.3
linux/drivers/media/video/tda985x.c - 1.3
linux/drivers/media/video/tda8425.c - 1.3
linux/drivers/media/video/tda7432.c - 1.3
linux/drivers/media/video/stradis.c - 1.2
linux/drivers/media/video/saa5249.c - 1.2
linux/drivers/media/video/pms.c - 1.2
linux/drivers/media/video/planb.c - 1.2
linux/drivers/media/video/msp3400.c - 1.2
linux/drivers/media/video/cpia_usb.c - 1.3
linux/drivers/media/video/cpia.c - 1.2
linux/drivers/media/video/c-qcam.c - 1.2
linux/drivers/media/video/bw-qcam.c - 1.2
linux/drivers/media/video/buz.c - 1.3
linux/drivers/media/video/bttv.h - 1.3
linux/drivers/media/video/bttv-if.c - 1.2
linux/drivers/media/video/bttv-driver.c - 1.3
linux/drivers/media/video/bttv-cards.c - 1.2
linux/drivers/media/video/audiochip.h - 1.2
linux/drivers/media/video/Makefile - 1.2
linux/drivers/media/radio/radio-zoltrix.c - 1.2
linux/drivers/media/radio/radio-typhoon.c - 1.2
linux/drivers/media/radio/radio-trust.c - 1.2
linux/drivers/media/radio/radio-terratec.c - 1.2
linux/drivers/media/radio/radio-sf16fmi.c - 1.2
linux/drivers/media/radio/radio-rtrack2.c - 1.2
linux/drivers/media/radio/radio-miropcm20.c - 1.2
linux/drivers/media/radio/radio-gemtek.c - 1.2
linux/drivers/media/radio/radio-cadet.c - 1.2
linux/drivers/media/radio/radio-aztech.c - 1.2
linux/drivers/media/radio/radio-aimslab.c - 1.2
linux/drivers/isdn/hysdn/hycapi.c - 1.2
linux/drivers/isdn/hisax/nj_u.c - 1.2
linux/drivers/isdn/hisax/nj_s.c - 1.2
linux/drivers/input/mousedev.c - 1.2
linux/drivers/input/joydev.c - 1.2
linux/drivers/input/input.c - 1.3
linux/drivers/input/evdev.c - 1.2
linux/drivers/char/joystick/iforce.c - 1.2
linux/kdb/ChangeLog - 1.4
linux/drivers/md/lvm.c - 1.3
linux/drivers/md/raid1.c - 1.3
linux/drivers/md/raid5.c - 1.3
linux/Documentation/kbuild/makefiles.txt - 1.3
linux/arch/i386/kernel/bluesmoke.c - 1.4
linux/drivers/md/md.c - 1.3
linux/drivers/md/xor.c - 1.2
linux/drivers/media/radio/radio-maestro.c - 1.2
linux/drivers/scsi/cpqfcTSinit.c - 1.2
linux/drivers/sound/cs4281.c - 1.2
linux/drivers/usb/net1080.c - 1.3
linux/fs/dnotify.c - 1.2
linux/include/asm-ppc/highmem.h - 1.2
linux/include/asm-ppc/kmap_types.h - 1.2
linux/include/asm-ppc/uninorth.h - 1.2
linux/include/linux/divert.h - 1.2
linux/mm/oom_kill.c - 1.2
linux/fs/xfs/support/sv.c - 1.2
linux/fs/xfs/support/mrlock.c - 1.3
	- Moved to test11



From owner-linux-xfs@oss.sgi.com Sat Nov 25 09:37:08 2000
Received:  by oss.sgi.com id <S553796AbQKYRgt>;
	Sat, 25 Nov 2000 09:36:49 -0800
Received: from deliverator.sgi.com ([204.94.214.10]:9340 "EHLO
        deliverator.sgi.com") by oss.sgi.com with ESMTP id <S553709AbQKYRgW>;
	Sat, 25 Nov 2000 09:36:22 -0800
Received: from sherman.melbourne.sgi.com (sherman.melbourne.sgi.com [134.14.55.175]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id JAA08871
	for <linux-xfs@oss.sgi.com>; Sat, 25 Nov 2000 09:28:23 -0800 (PST)
	mail_from (kaos@sherman.melbourne.sgi.com)
Received: (from kaos@localhost)
	by sherman.melbourne.sgi.com (8.9.3/8.9.3) id EAA12218;
	Sun, 26 Nov 2000 04:35:11 +1100
Date:   Sun, 26 Nov 2000 04:35:11 +1100
From:   Keith Owens <kaos@sherman.melbourne.sgi.com>
Message-Id: <200011251735.EAA12218@sherman.melbourne.sgi.com>
Subject: TAKE - Sync 2.4.0-test11-xfs to kdb v1.6 work in progress
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

Sync 2.4.0-test11-xfs to kdb v1.6 work in progress.
You will need a recent version of binutils, it must support
bfd_mach_i386_i386_intel_syntax.  binutils-2.9.5.0.22-6
works.

Date:  Sat Nov 25 09:31:48 PST 2000
Workarea:  sherman.melbourne.sgi.com:/build/kaos/2.4.x-xfs

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


Modid:  2.4.x-xfs:slinx:78892a
linux/arch/i386/kernel/io_apic.c - 1.22
linux/kdb/kdb_bt.c - 1.8
linux/include/linux/kdbprivate.h - 1.8
linux/include/linux/kdb.h - 1.12
linux/kdb/kdbsupport.c - 1.8
linux/kdb/kdbmain.c - 1.15
linux/include/linux/dis-asm.h - 1.6
linux/include/asm-i386/kdb.h - 1.6
linux/include/asm-i386/kdbprivate.h - 1.9
linux/arch/i386/kdb/kdba_id.c - 1.7
linux/kdb/kdb_id.c - 1.7
linux/arch/i386/kdb/i386-dis.c - 1.7
linux/arch/i386/kdb/kdba_bt.c - 1.10


From owner-linux-xfs@oss.sgi.com Sat Nov 25 11:41:09 2000
Received:  by oss.sgi.com id <S553823AbQKYTlA>;
	Sat, 25 Nov 2000 11:41:00 -0800
Received: from Cantor.suse.de ([194.112.123.193]:34579 "HELO Cantor.suse.de")
	by oss.sgi.com with SMTP id <S553744AbQKYTko>;
	Sat, 25 Nov 2000 11:40:44 -0800
Received: from Hermes.suse.de (Hermes.suse.de [194.112.123.136])
	by Cantor.suse.de (Postfix) with ESMTP
	id 2986C1E1AA; Sat, 25 Nov 2000 20:40:42 +0100 (MET)
Received: from gruyere.muc.suse.de (unknown [10.23.1.2])
	by Hermes.suse.de (Postfix) with ESMTP
	id 9183A3E452; Sat, 25 Nov 2000 20:40:40 +0100 (MET)
Received: by gruyere.muc.suse.de (Postfix, from userid 14446)
	id C4D592F300; Sat, 25 Nov 2000 20:40:31 +0100 (MET)
Date:   Sat, 25 Nov 2000 20:40:31 +0100
From:   Andi Kleen <ak@suse.de>
To:     Russell Cattelan <cattelan@thebarn.com>
Cc:     linux-xfs-announce@oss.sgi.com, linux-xfs@oss.sgi.com
Subject: Re: HEADS UP test11 merge.
Message-ID: <20001125204031.A31669@gruyere.muc.suse.de>
References: <3A1E9FAE.AB853C4A@thebarn.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <3A1E9FAE.AB853C4A@thebarn.com>; from cattelan@thebarn.com on Fri, Nov 24, 2000 at 11:04:46AM -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, Nov 24, 2000 at 11:04:46AM -0600, Russell Cattelan wrote:
> I have the XFS development tree patched up to test11, and ready to
> checkin.
> 
> I'm going to run a few more tests just to make sure nothing major broke.
> 
> I will try to finalize  the checkin later today if nobody has any major
> objections.

I needed this patch from Russel King to load xfs again (without it the module
loading put zeroes where support_init should be, causing a crash) 
This was with modutils 2.3.14.

--- ../linux.vanilla/kernel/module.c	Mon Nov 20 15:12:17 2000
+++ kernel/module.c	Thu Nov 23 11:49:42 2000
@@ -480,7 +480,9 @@
 
 	/* Ok, that's about all the sanity we can stomach; copy the rest.  */
 
-	if (copy_from_user(mod+1, mod_user+1, mod->size-sizeof(*mod))) {
+	if (copy_from_user((char *)mod+mod_user_size,
+			   (char *)mod_user+mod_user_size,
+			   mod->size-mod_user_size)) {
 		error = -EFAULT;
 		goto err3;
 	}



-Andi

From owner-linux-xfs@oss.sgi.com Sat Nov 25 12:39:30 2000
Received:  by oss.sgi.com id <S553827AbQKYUjK>;
	Sat, 25 Nov 2000 12:39:10 -0800
Received: from deliverator.sgi.com ([204.94.214.10]:11283 "EHLO
        deliverator.sgi.com") by oss.sgi.com with ESMTP id <S553822AbQKYUit>;
	Sat, 25 Nov 2000 12:38:49 -0800
Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id MAA21145
	for <linux-xfs@oss.sgi.com>; Sat, 25 Nov 2000 12:30:55 -0800 (PST)
	mail_from (cattelan@gibble.americas.sgi.com)
Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id OAA6302277 for <linux-xfs@oss.sgi.com>; Sat, 25 Nov 2000 14:37:32 -0600 (CST)
Received: from gibble.americas.sgi.com (gibble.americas.sgi.com [128.162.195.80]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id OAA23599 for <linux-xfs@oss.sgi.com>; Sat, 25 Nov 2000 14:37:32 -0600 (CST)
Received: (from cattelan@localhost)
	by gibble.americas.sgi.com (8.11.0/8.10.1) id eAPKbW332204
	for linux-xfs@oss.sgi.com; Sat, 25 Nov 2000 14:37:32 -0600
Date:   Sat, 25 Nov 2000 14:37:32 -0600
From:   Russell Cattelan <cattelan@sgi.com>
Message-Id: <200011252037.eAPKbW332204@gibble.americas.sgi.com>
Subject: TAKE - 
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

Date:  Sat Nov 25 12:33:47 PST 2000
Workarea:  gibble.americas.sgi.com:/export/extra/x2.4-xfs-clean

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


Modid:  2.4.x-xfs:slinx:78894a
linux/kernel/module.c - 1.19
	- Patch from Russel King to fix a module load problem
	  Reported by:  
	  Andi Kleen 



From owner-linux-xfs@oss.sgi.com Sat Nov 25 15:25:03 2000
Received:  by oss.sgi.com id <S553829AbQKYXYy>;
	Sat, 25 Nov 2000 15:24:54 -0800
Received: from ppp0.ocs.com.au ([203.34.97.3]:9732 "HELO mail.ocs.com.au")
	by oss.sgi.com with SMTP id <S553811AbQKYXYg>;
	Sat, 25 Nov 2000 15:24:36 -0800
Received: (qmail 4671 invoked from network); 25 Nov 2000 23:24:28 -0000
Received: from ocs3.ocs-net (192.168.255.3)
  by mail.ocs.com.au with SMTP; 25 Nov 2000 23:24:27 -0000
X-Mailer: exmh version 2.1.1 10/15/1999
From:   Keith Owens <kaos@melbourne.sgi.com>
To:     Andi Kleen <ak@suse.de>
cc:     Russell Cattelan <cattelan@thebarn.com>,
        linux-xfs-announce@oss.sgi.com, linux-xfs@oss.sgi.com
Subject: Re: HEADS UP test11 merge. 
In-reply-to: Your message of "Sat, 25 Nov 2000 20:40:31 BST."
             <20001125204031.A31669@gruyere.muc.suse.de> 
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date:   Sun, 26 Nov 2000 10:24:23 +1100
Message-ID: <9839.975194663@ocs3.ocs-net>
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, 25 Nov 2000 20:40:31 +0100, 
Andi Kleen <ak@suse.de> wrote:
>I needed this patch from Russel King to load xfs again (without it the module
>loading put zeroes where support_init should be, causing a crash) 
>This was with modutils 2.3.14.

The fact that Documentation/Changes requires modutils 2.3.18 for
kernels >= 2.4.0-test10 has obviously escaped everybody's notice.
You should be using modutils 2.3.21 anyway, to fix the local root
exploit.


From owner-linux-xfs@oss.sgi.com Sat Nov 25 15:54:04 2000
Received:  by oss.sgi.com id <S553830AbQKYXxy>;
	Sat, 25 Nov 2000 15:53:54 -0800
Received: from Cantor.suse.de ([194.112.123.193]:7949 "HELO Cantor.suse.de")
	by oss.sgi.com with SMTP id <S553811AbQKYXxd>;
	Sat, 25 Nov 2000 15:53:33 -0800
Received: from Hermes.suse.de (Hermes.suse.de [194.112.123.136])
	by Cantor.suse.de (Postfix) with ESMTP
	id 2017E1E1D7; Sun, 26 Nov 2000 00:53:31 +0100 (MET)
Received: from gruyere.muc.suse.de (unknown [10.23.1.2])
	by Hermes.suse.de (Postfix) with ESMTP
	id 683C13E452; Sun, 26 Nov 2000 00:53:30 +0100 (MET)
Received: by gruyere.muc.suse.de (Postfix, from userid 14446)
	id 8B8B82F300; Sun, 26 Nov 2000 00:53:29 +0100 (MET)
Date:   Sun, 26 Nov 2000 00:53:29 +0100
From:   Andi Kleen <ak@suse.de>
To:     Keith Owens <kaos@melbourne.sgi.com>
Cc:     Andi Kleen <ak@suse.de>, Russell Cattelan <cattelan@thebarn.com>,
        linux-xfs-announce@oss.sgi.com, linux-xfs@oss.sgi.com
Subject: Re: HEADS UP test11 merge.
Message-ID: <20001126005329.A3489@gruyere.muc.suse.de>
References: <20001125204031.A31669@gruyere.muc.suse.de> <9839.975194663@ocs3.ocs-net>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <9839.975194663@ocs3.ocs-net>; from kaos@melbourne.sgi.com on Sun, Nov 26, 2000 at 10:24:23AM +1100
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, Nov 26, 2000 at 10:24:23AM +1100, Keith Owens wrote:
> On Sat, 25 Nov 2000 20:40:31 +0100, 
> Andi Kleen <ak@suse.de> wrote:
> >I needed this patch from Russel King to load xfs again (without it the module
> >loading put zeroes where support_init should be, causing a crash) 
> >This was with modutils 2.3.14.
> 
> The fact that Documentation/Changes requires modutils 2.3.18 for
> kernels >= 2.4.0-test10 has obviously escaped everybody's notice.
> You should be using modutils 2.3.21 anyway, to fix the local root
> exploit.

The code in module.c was obviously wrong anyways though, otherwise
it would be rather useless to pass the structure size in. 

I also do not care about local root exploits on my test machines.


-Andi

From owner-linux-xfs@oss.sgi.com Sat Nov 25 16:15:24 2000
Received:  by oss.sgi.com id <S553828AbQKZAPE>;
	Sat, 25 Nov 2000 16:15:04 -0800
Received: from ppp0.ocs.com.au ([203.34.97.3]:23812 "HELO mail.ocs.com.au")
	by oss.sgi.com with SMTP id <S553811AbQKZAOv>;
	Sat, 25 Nov 2000 16:14:51 -0800
Received: (qmail 5181 invoked from network); 26 Nov 2000 00:14:46 -0000
Received: from ocs3.ocs-net (192.168.255.3)
  by mail.ocs.com.au with SMTP; 26 Nov 2000 00:14:46 -0000
X-Mailer: exmh version 2.1.1 10/15/1999
From:   Keith Owens <kaos@melbourne.sgi.com>
To:     Andi Kleen <ak@suse.de>
cc:     Russell Cattelan <cattelan@thebarn.com>,
        linux-xfs-announce@oss.sgi.com, linux-xfs@oss.sgi.com
Subject: Re: HEADS UP test11 merge. 
In-reply-to: Your message of "Sun, 26 Nov 2000 00:53:29 BST."
             <20001126005329.A3489@gruyere.muc.suse.de> 
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date:   Sun, 26 Nov 2000 11:14:45 +1100
Message-ID: <10565.975197685@ocs3.ocs-net>
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, 26 Nov 2000 00:53:29 +0100, 
Andi Kleen <ak@suse.de> wrote:
>On Sun, Nov 26, 2000 at 10:24:23AM +1100, Keith Owens wrote:
>> On Sat, 25 Nov 2000 20:40:31 +0100, 
>> Andi Kleen <ak@suse.de> wrote:
>> >I needed this patch from Russel King to load xfs again (without it the module
>> >loading put zeroes where support_init should be, causing a crash) 
>> >This was with modutils 2.3.14.
>> 
>> The fact that Documentation/Changes requires modutils 2.3.18 for
>> kernels >= 2.4.0-test10 has obviously escaped everybody's notice.
>> You should be using modutils 2.3.21 anyway, to fix the local root
>> exploit.
>
>The code in module.c was obviously wrong anyways though, otherwise
>it would be rather useless to pass the structure size in. 

module.c was wrong but it only trips when you use old modutils on a
current kernel.  BTW, the patch was mine, not Russel King's.  Russel
reported the problem first with a patch but his patch was in the wrong
place, I did the correct patch.

>I also do not care about local root exploits on my test machines.

But you should care about upgrading according to Documentation/Changes.
modutils 2.3.18 was required for kernel 2.4.0-test10, 2.3.14 is too
old.  Before introducing significant kernel changes I issue new
modutils and bump the required version in Changes then wait one or two
kernel releases before adding the corresponding kernel patch.  That way
people get a chance to upgrade modutils gracefully instead of
immediately hitting problems when a new kernel is released.  But that
assumes people read Documentation/Changes.


From owner-linux-xfs@oss.sgi.com Sat Nov 25 17:02:24 2000
Received:  by oss.sgi.com id <S553836AbQKZBCO>;
	Sat, 25 Nov 2000 17:02:14 -0800
Received: from Cantor.suse.de ([194.112.123.193]:8207 "HELO Cantor.suse.de")
	by oss.sgi.com with SMTP id <S553744AbQKZBB5>;
	Sat, 25 Nov 2000 17:01:57 -0800
Received: from Hermes.suse.de (Hermes.suse.de [194.112.123.136])
	by Cantor.suse.de (Postfix) with ESMTP
	id 020E41E1D9; Sun, 26 Nov 2000 02:01:55 +0100 (MET)
Received: from gruyere.muc.suse.de (unknown [10.23.1.2])
	by Hermes.suse.de (Postfix) with ESMTP
	id BA5413E461; Sun, 26 Nov 2000 02:01:55 +0100 (MET)
Received: by gruyere.muc.suse.de (Postfix, from userid 14446)
	id 38EED2F300; Sun, 26 Nov 2000 02:01:55 +0100 (MET)
Date:   Sun, 26 Nov 2000 02:01:55 +0100
From:   Andi Kleen <ak@suse.de>
To:     Keith Owens <kaos@melbourne.sgi.com>
Cc:     Andi Kleen <ak@suse.de>, Russell Cattelan <cattelan@thebarn.com>,
        linux-xfs-announce@oss.sgi.com, linux-xfs@oss.sgi.com
Subject: Re: HEADS UP test11 merge.
Message-ID: <20001126020155.A4052@gruyere.muc.suse.de>
References: <20001126005329.A3489@gruyere.muc.suse.de> <10565.975197685@ocs3.ocs-net>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <10565.975197685@ocs3.ocs-net>; from kaos@melbourne.sgi.com on Sun, Nov 26, 2000 at 11:14:45AM +1100
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, Nov 26, 2000 at 11:14:45AM +1100, Keith Owens wrote:
> On Sun, 26 Nov 2000 00:53:29 +0100, 
> Andi Kleen <ak@suse.de> wrote:
> >On Sun, Nov 26, 2000 at 10:24:23AM +1100, Keith Owens wrote:
> >> On Sat, 25 Nov 2000 20:40:31 +0100, 
> >> Andi Kleen <ak@suse.de> wrote:
> >> >I needed this patch from Russel King to load xfs again (without it the module
> >> >loading put zeroes where support_init should be, causing a crash) 
> >> >This was with modutils 2.3.14.
> >> 
> >> The fact that Documentation/Changes requires modutils 2.3.18 for
> >> kernels >= 2.4.0-test10 has obviously escaped everybody's notice.
> >> You should be using modutils 2.3.21 anyway, to fix the local root
> >> exploit.
> >
> >The code in module.c was obviously wrong anyways though, otherwise
> >it would be rather useless to pass the structure size in. 
> 
> module.c was wrong but it only trips when you use old modutils on a
> current kernel.  BTW, the patch was mine, not Russel King's.  Russel
> reported the problem first with a patch but his patch was in the wrong
> place, I did the correct patch.

Sorry, I was told it was his patch.
> 
> >I also do not care about local root exploits on my test machines.
> 
> But you should care about upgrading according to Documentation/Changes.
> modutils 2.3.18 was required for kernel 2.4.0-test10, 2.3.14 is too
> old.  Before introducing significant kernel changes I issue new

Thank you, 2.3.14 works fine for me so far with this patch.

I also do not remember reading an announcement of you about the binary
breakage on linux-kernel (Changes is useless for frequent kernel testers
because it contains to 95% unnecessary updates) 

-Andi

From owner-linux-xfs@oss.sgi.com Sat Nov 25 17:08:14 2000
Received:  by oss.sgi.com id <S553842AbQKZBHy>;
	Sat, 25 Nov 2000 17:07:54 -0800
Received: from smtp9.xs4all.nl ([194.109.127.135]:1739 "EHLO smtp9.xs4all.nl")
	by oss.sgi.com with ESMTP id <S553744AbQKZBHo>;
	Sat, 25 Nov 2000 17:07:44 -0800
Received: from asterix.xs4all.nl (asterix.xs4all.nl [194.109.6.11])
	by smtp9.xs4all.nl (8.9.3/8.9.3) with ESMTP id CAA23902
	for <linux-xfs@oss.sgi.com>; Sun, 26 Nov 2000 02:07:37 +0100 (CET)
Received: from ramoth.xs4all.nl (uucp@localhost)
	by asterix.xs4all.nl (8.9.1/8.9.1) with UUCP id CAA19218
	for oss.sgi.com!linux-xfs; Sun, 26 Nov 2000 02:07:37 +0100 (CET)
Received: by ladystrange.bluehorizon.nl
	id m13zqHr-0005F9C
	(Debian Smail-3.2.0.102 1998-Aug-2 #2); Sun, 26 Nov 2000 02:07:23 +0100 (CET)
Date:   Sun, 26 Nov 2000 02:07:23 +0100
From:   "P.A.M. van Dam (Pascal)" <tormentor@ramoth.xs4all.nl>
To:     linux-xfs@oss.sgi.com
Subject: Where to get a debian package of egcs 2.91.66
Message-ID: <20001126020723.A29752@ladystrange.bluehorizon.nl>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 0.95.1i
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing

Hi!

In order to compile the latest XFS CVS tree under Debian 2.2, does someone
know where I can get a .deb of the egcs 2.91.66 compiler? Woody (Debian 2.2)
ships with 2.95.2 and while it compiles fine after I boot the kernel ever-
thing works OK execpt when I try to mount the xfs which is on a Logical
Volume. It says it's reading beyond the end of the device. :(

Thanx in advance!

Best regards,

	Pascal


From owner-linux-xfs@oss.sgi.com Sat Nov 25 17:17:14 2000
Received:  by oss.sgi.com id <S553846AbQKZBQy>;
	Sat, 25 Nov 2000 17:16:54 -0800
Received: from ppp0.ocs.com.au ([203.34.97.3]:48644 "HELO mail.ocs.com.au")
	by oss.sgi.com with SMTP id <S553834AbQKZBQp>;
	Sat, 25 Nov 2000 17:16:45 -0800
Received: (qmail 5600 invoked from network); 26 Nov 2000 01:16:40 -0000
Received: from ocs3.ocs-net (192.168.255.3)
  by mail.ocs.com.au with SMTP; 26 Nov 2000 01:16:40 -0000
X-Mailer: exmh version 2.1.1 10/15/1999
From:   Keith Owens <kaos@melbourne.sgi.com>
To:     Andi Kleen <ak@suse.de>
cc:     linux-xfs@oss.sgi.com
Subject: Re: HEADS UP test11 merge. 
In-reply-to: Your message of "Sun, 26 Nov 2000 02:01:55 BST."
             <20001126020155.A4052@gruyere.muc.suse.de> 
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date:   Sun, 26 Nov 2000 12:16:38 +1100
Message-ID: <11043.975201398@ocs3.ocs-net>
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, 26 Nov 2000 02:01:55 +0100, 
Andi Kleen <ak@suse.de> wrote:
>I also do not remember reading an announcement of you about the binary
>breakage on linux-kernel (Changes is useless for frequent kernel testers
>because it contains to 95% unnecessary updates) 

The breakage was a bug, not deliberate.  It only shows up with old
modutils on kernel 2.4.0-test11.  I do my testing with the recommended
versions of software, modutils >= 2.3.16 works with 2.4.0-test11.
Since I still get complaints from people who try to run modutils
2.1.121 on 2.4 kernels, I should not be surprised that Changes is being
ignored, but it is the only official mechanism we have.


From owner-linux-xfs@oss.sgi.com Sat Nov 25 17:23:24 2000
Received:  by oss.sgi.com id <S553850AbQKZBXO>;
	Sat, 25 Nov 2000 17:23:14 -0800
Received: from Cantor.suse.de ([194.112.123.193]:51215 "HELO Cantor.suse.de")
	by oss.sgi.com with SMTP id <S553844AbQKZBXF>;
	Sat, 25 Nov 2000 17:23:05 -0800
Received: from Hermes.suse.de (Hermes.suse.de [194.112.123.136])
	by Cantor.suse.de (Postfix) with ESMTP
	id 54E7C1E1EA; Sun, 26 Nov 2000 02:23:03 +0100 (MET)
Received: from gruyere.muc.suse.de (unknown [10.23.1.2])
	by Hermes.suse.de (Postfix) with ESMTP
	id B16103E461; Sun, 26 Nov 2000 02:23:02 +0100 (MET)
Received: by gruyere.muc.suse.de (Postfix, from userid 14446)
	id 612312F300; Sun, 26 Nov 2000 02:23:02 +0100 (MET)
Date:   Sun, 26 Nov 2000 02:23:02 +0100
From:   Andi Kleen <ak@suse.de>
To:     Keith Owens <kaos@melbourne.sgi.com>
Cc:     Andi Kleen <ak@suse.de>, linux-xfs@oss.sgi.com
Subject: Re: HEADS UP test11 merge.
Message-ID: <20001126022302.A4454@gruyere.muc.suse.de>
References: <20001126020155.A4052@gruyere.muc.suse.de> <11043.975201398@ocs3.ocs-net>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <11043.975201398@ocs3.ocs-net>; from kaos@melbourne.sgi.com on Sun, Nov 26, 2000 at 12:16:38PM +1100
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, Nov 26, 2000 at 12:16:38PM +1100, Keith Owens wrote:
> On Sun, 26 Nov 2000 02:01:55 +0100, 
> Andi Kleen <ak@suse.de> wrote:
> >I also do not remember reading an announcement of you about the binary
> >breakage on linux-kernel (Changes is useless for frequent kernel testers
> >because it contains to 95% unnecessary updates) 
> 
> The breakage was a bug, not deliberate.  It only shows up with old
> modutils on kernel 2.4.0-test11.  I do my testing with the recommended
> versions of software, modutils >= 2.3.16 works with 2.4.0-test11.
> Since I still get complaints from people who try to run modutils
> 2.1.121 on 2.4 kernels, I should not be surprised that Changes is being
> ignored, but it is the only official mechanism we have.

Official mechanism would be Linus' release notes. 
 


-Andi

From owner-linux-xfs@oss.sgi.com Sat Nov 25 17:43:15 2000
Received:  by oss.sgi.com id <S553853AbQKZBnF>;
	Sat, 25 Nov 2000 17:43:05 -0800
Received: from perilith.com ([207.198.250.232]:7440 "HELO
        easywayout.perilith.com") by oss.sgi.com with SMTP
	id <S553847AbQKZBmm>; Sat, 25 Nov 2000 17:42:42 -0800
Received: by easywayout.perilith.com (Postfix, from userid 1034)
	id 141983E018; Sun, 26 Nov 2000 01:42:41 +0000 (US/Pacific)
Date:   Sat, 25 Nov 2000 17:42:41 -0800
From:   Drew Bloechl <drew@cesspool.net>
To:     linux-xfs@oss.sgi.com
Subject: Re: Where to get a debian package of egcs 2.91.66
Message-ID: <20001125174240.J20370@perilith.com>
References: <20001126020723.A29752@ladystrange.bluehorizon.nl>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <20001126020723.A29752@ladystrange.bluehorizon.nl>; from tormentor@ramoth.xs4all.nl on Sun, Nov 26, 2000 at 02:07:23AM +0100
X-PGP-Fingerprint: B8B4 8A05 A58B 5252 FFC5  E455 D831 31A3 3385 5516
X-PGP-Public-Key: http://cesspool.net/drew.pubkey.txt
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, Nov 26, 2000 at 02:07:23AM +0100, P.A.M. van Dam (Pascal) wrote:
> In order to compile the latest XFS CVS tree under Debian 2.2, does someone
> know where I can get a .deb of the egcs 2.91.66 compiler? Woody (Debian 2.2)
> ships with 2.95.2 and while it compiles fine after I boot the kernel ever-
> thing works OK execpt when I try to mount the xfs which is on a Logical
> Volume. It says it's reading beyond the end of the device. :(

Just download the RPM from a RedHat mirror and use alien to convert it.  

"apt-get install alien" if necessary. 

-- 
Drew Bloechl
drew@cesspool.net
PGP key ID: 33855516

From owner-linux-xfs@oss.sgi.com Sat Nov 25 18:39:46 2000
Received:  by oss.sgi.com id <S553855AbQKZCjg>;
	Sat, 25 Nov 2000 18:39:36 -0800
Received: from deliverator.sgi.com ([204.94.214.10]:17466 "EHLO
        deliverator.sgi.com") by oss.sgi.com with ESMTP id <S553852AbQKZCjX>;
	Sat, 25 Nov 2000 18:39:23 -0800
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 SAA17265
	for <linux-xfs@oss.sgi.com>; Sat, 25 Nov 2000 18:31:28 -0800 (PST)
	mail_from (nathans@wobbly.melbourne.sgi.com)
Received: from wobbly.melbourne.sgi.com (wobbly.melbourne.sgi.com [134.14.55.135]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id NAA16686; Sun, 26 Nov 2000 13:36:50 +1100
Received: (from nathans@localhost) by wobbly.melbourne.sgi.com (980427.SGI.8.8.8/980728.SGI.AUTOCF) id NAA24626; Sun, 26 Nov 2000 13:36:48 +1100 (EDT)
From:   "Nathan Scott" <nathans@wobbly.melbourne.sgi.com>
Message-Id: <10011261336.ZM166460@wobbly.melbourne.sgi.com>
Date:   Sun, 26 Nov 2000 13:36:46 -0400
In-Reply-To: Thomas Graichen <news-innominate.list.sgi.xfs@innominate.de>
        "Re: stress test on ppc" (Nov 24,  1:21pm)
References: <news2mail-8uecj0$i5e$1@mate.bln.innominate.de> 
	<news-innominate.list.sgi.xfs@innominate.de> 
	<10011101103.ZM113097@wobbly.melbourne.sgi.com> 
	<20001110094151.C333@ysabell> 
	<10011110006.ZM127189@wobbly.melbourne.sgi.com> 
	<news2mail-8uo7od$4lt$1@mate.bln.innominate.de> 
	<10011141059.ZM128320@wobbly.melbourne.sgi.com> 
	<news2mail-8utlfv$8iu$1@mate.bln.innominate.de> 
	<10011221244.ZM158790@wobbly.melbourne.sgi.com> 
	<news2mail-8vlq0n$hiu$2@mate.bln.innominate.de>
X-Mailer: Z-Mail (3.2.3 08feb96 MediaMail)
To:     Thomas Graichen <graichen@innominate.de>,
        thomas.graichen@innominate.de
Subject: Re: stress test on ppc
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

hi Thomas,

On Nov 24,  1:21pm, Thomas Graichen wrote:
> Subject: Re: stress test on ppc
> ...
> 
> df gave: blocks=3136128 used=11488 avail=3124640
> blocksize from xfs_db is '524288'

that's the problem right there (the blocksize).

I don't understand how one could get a blocksize like
that since the test runs mkfs.xfs on the scratch device
and so should always have a blocksize of 4K (by default)
- see _populate_scratch() in the test, followed by the
blksize=... line a little further down.

> > (btw, any luck with ppc mount detecting a minix filesystem?)
> 
> sorry- looks like this was my fault: minix fs was simply not compiled
> into the kernel :-(

no, that wouldn't affect this test - its all user space
testing of mkfs (no actual mount happens), so no kernel
support for other filesystems is required.

> ... works now

*shrug* - must have been an alignment-of-the-planets issue.

cheers.

-- 
Nathan

From owner-linux-xfs@oss.sgi.com Sat Nov 25 18:55:16 2000
Received:  by oss.sgi.com id <S553857AbQKZCy4>;
	Sat, 25 Nov 2000 18:54:56 -0800
Received: from deliverator.sgi.com ([204.94.214.10]:49723 "EHLO
        deliverator.sgi.com") by oss.sgi.com with ESMTP id <S553854AbQKZCy3>;
	Sat, 25 Nov 2000 18:54:29 -0800
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 SAA18262
	for <linux-xfs@oss.sgi.com>; Sat, 25 Nov 2000 18:46:35 -0800 (PST)
	mail_from (nathans@wobbly.melbourne.sgi.com)
Received: from wobbly.melbourne.sgi.com (wobbly.melbourne.sgi.com [134.14.55.135]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id NAA16733; Sun, 26 Nov 2000 13:53:12 +1100
Received: (from nathans@localhost) by wobbly.melbourne.sgi.com (980427.SGI.8.8.8/980728.SGI.AUTOCF) id NAA66437; Sun, 26 Nov 2000 13:53:11 +1100 (EDT)
From:   "Nathan Scott" <nathans@wobbly.melbourne.sgi.com>
Message-Id: <10011261353.ZM165451@wobbly.melbourne.sgi.com>
Date:   Sun, 26 Nov 2000 13:53:10 -0400
In-Reply-To: Thomas Graichen <news-innominate.list.sgi.xfs@innominate.de>
        "alpha again" (Nov 24,  6:50pm)
References: <news2mail-8vmd9o$upi$1@mate.bln.innominate.de>
X-Mailer: Z-Mail (3.2.3 08feb96 MediaMail)
To:     Thomas Graichen <graichen@innominate.de>,
        thomas.graichen@innominate.de
Subject: Re: alpha again
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

hi,

On Nov 24,  6:50pm, Thomas Graichen wrote:
> Subject: alpha again
> just another try ... maybe someone has an idea now :-)
> 

what does "xfs_db -r -c agf -c p /dev/sdb1" say at each
point (*) below.

> root@cyan:/usr/src/xfs/linux# mkfs -t xfs -f -b size=8192 /dev/sdb1  
> meta-data=/dev/sdb1              isize=256    agcount=8, agsize=4142 blks
> data     =                       bsize=8192   blocks=33130, imaxpct=25
>          =                       sunit=0      swidth=0 blks, unwritten=0
> naming   =version 2              bsize=8192  
> log      =internal log           bsize=8192   blocks=1000
> realtime =none                   extsz=65536  blocks=0, rtextents=0

(*) here

> root@cyan:/usr/src/xfs/linux# mount /dev/sdb1 /mnt
> root@cyan:/usr/src/xfs/linux# umount /mnt

(*) here

> root@cyan:/usr/src/xfs/linux# xfs_repair /dev/sdb1
> Phase 1 - find and verify superblock...
> Phase 2 - using internal log
>         - zero log...
>         - scan filesystem freespace and inode maps...
> bad magic # 0x0 for agf 0
> bad version # -1 for agf 0
> bad length 0 for agf 0, should be 4142
> flfirst -2147483648 in agf 0 too large (max = 128)
> reset bad agf for ag 0
> freeblk count 1 != flcount 1084270339 in ag 0
> bad agbno 2966461184 for btbno root, agno 0
> bad agbno 16580607 for btbcnt root, agno 0
>         - found root inode chunk
> Phase 3 - for each AG...
>         - scan and clear agi unlinked lists...
>         - process known inodes and perform inode discovery...
>         - agno = 0
>         - agno = 1
>         - agno = 2
>         - agno = 3
> ...

and (*) here.

(could you send me the output in each place - thanks).

> 
> looks for me a little bit like some kind of maybe size problems
> in some structure alignments or so ... aside from this i can
> run a dbench 64 without problems on the alpha ... looks
> like it's a more harmless and well located problem
> 

I'm a little surprised that we can get thru dbench with what
seem like such fundamental problems... hmm - perhaps its only
a userspace problem (seeking to the wrong place or something).

cheers.

-- 
Nathan

From owner-linux-xfs@oss.sgi.com Sun Nov 26 03:20:10 2000
Received:  by oss.sgi.com id <S553860AbQKZLTu>;
	Sun, 26 Nov 2000 03:19:50 -0800
Received: from cips.inwind.it ([212.141.53.74]:29347 "EHLO relay3.inwind.it")
	by oss.sgi.com with ESMTP id <S553858AbQKZLT0>;
	Sun, 26 Nov 2000 03:19:26 -0800
Received: from pluto (62.98.58.162) by relay3.inwind.it (5.1.046)
        id 3A1269CB000D9C73; Sun, 26 Nov 2000 12:09:56 +0100
Message-Id: <3.0.6.32.20001126122134.00aac9e0@pop.tiscalinet.it>
X-Sender: lenstra@pop.tiscalinet.it
X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.6 (32)
Date:   Sun, 26 Nov 2000 12:21:34 +0100
To:     "P.A.M. van Dam (Pascal)" <tormentor@ramoth.xs4all.nl>
From:   Lorenzo Allegrucci <lenstra@tiscalinet.it>
Subject: Re: Where to get a debian package of egcs 2.91.66
Cc:     linux-xfs@oss.sgi.com
In-Reply-To: <20001126020723.A29752@ladystrange.bluehorizon.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

At 02.07 26/11/00 +0100, you wrote:
>Hi!
>
>In order to compile the latest XFS CVS tree under Debian 2.2, does someone
>know where I can get a .deb of the egcs 2.91.66 compiler?

ftp://archive.debian.org/debian-archive/dists/Debian-2.1/main/

Does anyone know how to make it to work on Potato?

--
Lorenzo

From owner-linux-xfs@oss.sgi.com Sun Nov 26 04:21:13 2000
Received:  by oss.sgi.com id <S553862AbQKZMVD>;
	Sun, 26 Nov 2000 04:21:03 -0800
Received: from natmail2.webmailer.de ([192.67.198.65]:45985 "EHLO
        post.webmailer.de") by oss.sgi.com with ESMTP id <S553859AbQKZMUp>;
	Sun, 26 Nov 2000 04:20:45 -0800
Received: from babylon2k.dnsalias.com (pC19F2174.dip.t-dialin.net [193.159.33.116])
	by post.webmailer.de (8.9.3/8.8.7) with ESMTP id NAA04485
	for <linux-xfs@oss.sgi.com>; Sun, 26 Nov 2000 13:20:44 +0100 (MET)
Received: from babylon2k.dnsalias.com
	([192.168.131.1] helo=babylon2k.de ident=crossfire)
	by babylon2k.dnsalias.com with esmtp (Exim 3.16 #1 (Debian))
	id 1400nQ-0000Xl-00
	for <linux-xfs@oss.sgi.com>; Sun, 26 Nov 2000 13:20:40 +0100
Message-ID: <3A21000D.F84F4869@babylon2k.de>
Date:   Sun, 26 Nov 2000 13:20:30 +0100
From:   Cullmann Christoph <crossfire@babylon2k.de>
X-Mailer: Mozilla 4.75 [en] (X11; U; Linux 2.4.0-test10 i686)
X-Accept-Language: de, en
MIME-Version: 1.0
To:     linux-xfs@oss.sgi.com
Subject: Debian 2.91.66 gcc
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

Download the kgcc-2.91.66 RPM from RedHat !!
convert it with alien to deb and install it :-)
I have tried it on Debian 2.2 or Woody and all worked well :-)

cu
crossfire


From owner-linux-xfs@oss.sgi.com Sun Nov 26 06:18:32 2000
Received:  by oss.sgi.com id <S553864AbQKZOSN>;
	Sun, 26 Nov 2000 06:18:13 -0800
Received: from smtp7.xs4all.nl ([194.109.127.133]:10484 "EHLO smtp7.xs4all.nl")
	by oss.sgi.com with ESMTP id <S553861AbQKZORl>;
	Sun, 26 Nov 2000 06:17:41 -0800
Received: from asterix.xs4all.nl (asterix.xs4all.nl [194.109.6.11])
	by smtp7.xs4all.nl (8.9.3/8.9.3) with ESMTP id PAA21588;
	Sun, 26 Nov 2000 15:17:37 +0100 (CET)
Received: from ramoth.xs4all.nl (uucp@localhost)
	by asterix.xs4all.nl (8.9.1/8.9.1) with UUCP id PAA25416;
	Sun, 26 Nov 2000 15:17:37 +0100 (CET)
Received: by ladystrange.bluehorizon.nl
	id m1401kJ-0005F9C
	(Debian Smail-3.2.0.102 1998-Aug-2 #2); Sun, 26 Nov 2000 14:21:31 +0100 (CET)
Date:   Sun, 26 Nov 2000 14:21:31 +0100
From:   "P.A.M. van Dam (Pascal)" <tormentor@ramoth.xs4all.nl>
To:     Drew Bloechl <drew@cesspool.net>
Cc:     linux-xfs@oss.sgi.com
Subject: Re: Where to get a debian package of egcs 2.91.66
Message-ID: <20001126142131.A12228@ladystrange.bluehorizon.nl>
References: <20001126020723.A29752@ladystrange.bluehorizon.nl> <20001125174240.J20370@perilith.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 0.95.1i
In-Reply-To: <20001125174240.J20370@perilith.com>; from Drew Bloechl on Sat, Nov 25, 2000 at 05:42:41PM -0800
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, Nov 25, 2000 at 05:42:41PM -0800, Drew Bloechl wrote:

Looks like LVM 0.9 is screwing up things this time.
I'll investigate it further.

Thanx for the help!

Best regards,

	Pascal


From owner-linux-xfs@oss.sgi.com Mon Nov 27 00:10:29 2000
Received:  by oss.sgi.com id <S553784AbQK0IKT>;
	Mon, 27 Nov 2000 00:10:19 -0800
Received: from hermes.mixx.net ([212.84.196.2]:17674 "HELO hermes.mixx.net")
	by oss.sgi.com with SMTP id <S553752AbQK0IKC>;
	Mon, 27 Nov 2000 00:10:02 -0800
Received: from mate.bln.innominate.de (cerberus.berlin.innominate.de [212.84.234.251])
	by hermes.mixx.net (Postfix) with ESMTP id 49F3FF802
	for <linux-xfs@oss.sgi.com>; Mon, 27 Nov 2000 09:10:00 +0100 (CET)
Received: by mate.bln.innominate.de (Postfix, from userid 9)
	id 87DE42CAA2; Mon, 27 Nov 2000 09:09:59 +0100 (CET)
From:   Thomas Graichen <news-innominate.list.sgi.xfs@innominate.de>
Reply-To: Thomas Graichen <graichen@innominate.de>
X-Newsgroups: innominate.list.sgi.xfs
Subject: Re: alpha again
Date:   27 Nov 2000 08:09:59 GMT
Organization: innominate AG, Berlin, Germany
Lines:  120
Distribution: local
Message-ID: <news2mail-8vt4sn$dhv$2@mate.bln.innominate.de>
References: <news2mail-8vmd9o$upi$1@mate.bln.innominate.de> <10011261353.ZM165451@wobbly.melbourne.sgi.com>
Reply-To: thomas.graichen@innominate.de
X-Trace: mate.bln.innominate.de 975312599 13887 10.0.0.31 (27 Nov 2000 08:09:59 GMT)
X-Complaints-To: news@innominate.de
User-Agent: tin/1.4.4-20000803 ("Vet for the Insane") (UNIX) (Linux/2.4.0-XFS-test10 (i686))
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

"Nathan Scott" <nathans@wobbly.melbourne.sgi.com> wrote:
> hi,

> On Nov 24,  6:50pm, Thomas Graichen wrote:
>> Subject: alpha again
>> just another try ... maybe someone has an idea now :-)
>> 

> what does "xfs_db -r -c agf -c p /dev/sdb1" say at each
> point (*) below.

>> root@cyan:/usr/src/xfs/linux# mkfs -t xfs -f -b size=8192 /dev/sdb1  
>> meta-data=/dev/sdb1              isize=256    agcount=8, agsize=4142 blks
>> data     =                       bsize=8192   blocks=33130, imaxpct=25
>>          =                       sunit=0      swidth=0 blks, unwritten=0
>> naming   =version 2              bsize=8192  
>> log      =internal log           bsize=8192   blocks=1000
>> realtime =none                   extsz=65536  blocks=0, rtextents=0

> (*) here

root@cyan:~# xfs_db -r -c agf -c p /dev/sdb1
magicnum = 0x58414746
versionnum = 1
seqno = 0
length = 4142
bnoroot = 1
cntroot = 2
bnolevel = 1
cntlevel = 1
flfirst = 0
fllast = 3
flcount = 4
freeblks = 4132
longest = 4132
root@cyan:~#

>> root@cyan:/usr/src/xfs/linux# mount /dev/sdb1 /mnt
>> root@cyan:/usr/src/xfs/linux# umount /mnt

> (*) here

root@cyan:~# xfs_db -r -c agf -c p /dev/sdb1
magicnum = 0
versionnum = 4294967295
seqno = 0
length = 0
bnoroot = 2966461184
cntroot = 16580607
bnolevel = 16580607
cntlevel = 0
flfirst = 2147483648
fllast = 0
flcount = 1088476165
freeblks = 16580607
longest = 14734341
root@cyan:~#

>> root@cyan:/usr/src/xfs/linux# xfs_repair /dev/sdb1
>> Phase 1 - find and verify superblock...
>> Phase 2 - using internal log
>>         - zero log...
>>         - scan filesystem freespace and inode maps...
>> bad magic # 0x0 for agf 0
>> bad version # -1 for agf 0
>> bad length 0 for agf 0, should be 4142
>> flfirst -2147483648 in agf 0 too large (max = 128)
>> reset bad agf for ag 0
>> freeblk count 1 != flcount 1084270339 in ag 0
>> bad agbno 2966461184 for btbno root, agno 0
>> bad agbno 16580607 for btbcnt root, agno 0
>>         - found root inode chunk
>> Phase 3 - for each AG...
>>         - scan and clear agi unlinked lists...
>>         - process known inodes and perform inode discovery...
>>         - agno = 0
>>         - agno = 1
>>         - agno = 2
>>         - agno = 3
>> ...

> and (*) here.

root@cyan:~# xfs_db -r -c agf -c p /dev/sdb1
magicnum = 0x58414746
versionnum = 1
seqno = 0
length = 4142
bnoroot = 2
cntroot = 3
bnolevel = 1
cntlevel = 1
flfirst = 0
fllast = 127
flcount = 0
freeblks = 4136
longest = 4132
root@cyan:~#

> (could you send me the output in each place - thanks).

>> looks for me a little bit like some kind of maybe size problems
>> in some structure alignments or so ... aside from this i can
>> run a dbench 64 without problems on the alpha ... looks
>> like it's a more harmless and well located problem

> I'm a little surprised that we can get thru dbench with what
> seem like such fundamental problems... hmm - perhaps its only
> a userspace problem (seeking to the wrong place or something).

yes - the filesystem as such runs perfectly so far - tell me if you
need anything else

t

-- 
thomas.graichen@innominate.com
technical director                                       innominate AG
clustering & security                             the linux architects
tel: +49-30-308806-13   fax: -77             http://www.innominate.com

From owner-linux-xfs@oss.sgi.com Mon Nov 27 00:28:20 2000
Received:  by oss.sgi.com id <S553778AbQK0I2K>;
	Mon, 27 Nov 2000 00:28:10 -0800
Received: from hermes.mixx.net ([212.84.196.2]:4363 "HELO hermes.mixx.net")
	by oss.sgi.com with SMTP id <S553818AbQK0I15>;
	Mon, 27 Nov 2000 00:27:57 -0800
Received: from mate.bln.innominate.de (cerberus.berlin.innominate.de [212.84.234.251])
	by hermes.mixx.net (Postfix) with ESMTP id A98B1F804
	for <linux-xfs@oss.sgi.com>; Mon, 27 Nov 2000 09:27:55 +0100 (CET)
Received: by mate.bln.innominate.de (Postfix, from userid 9)
	id 5023E2CAA2; Mon, 27 Nov 2000 09:27:55 +0100 (CET)
From:   Thomas Graichen <news-innominate.list.sgi.xfs@innominate.de>
Reply-To: Thomas Graichen <graichen@innominate.de>
X-Newsgroups: innominate.list.sgi.xfs
Subject: Re: stress test on ppc
Date:   27 Nov 2000 08:27:55 GMT
Organization: innominate AG, Berlin, Germany
Lines:  75
Distribution: local
Message-ID: <news2mail-8vt5ub$dhv$3@mate.bln.innominate.de>
References: <news2mail-8uecj0$i5e$1@mate.bln.innominate.de>   <10011101103.ZM113097@wobbly.melbourne.sgi.com>   <20001110094151.C333@ysabell>   <10011110006.ZM127189@wobbly.melbourne.sgi.com>   <news2mail-8uo7od$4lt$1@mate.bln.innominate.de>   <10011141059.ZM128320@wobbly.melbourne.sgi.com>   <news2mail-8utlfv$8iu$1@mate.bln.innominate.de>   <10011221244.ZM158790@wobbly.melbourne.sgi.com>   <news2mail-8vlq0n$hiu$2@mate.bln.innominate.de> <10011261336.ZM166460@wobbly.melbourne.sgi.com>
Reply-To: thomas.graichen@innominate.de
X-Trace: mate.bln.innominate.de 975313675 13887 10.0.0.31 (27 Nov 2000 08:27:55 GMT)
X-Complaints-To: news@innominate.de
User-Agent: tin/1.4.4-20000803 ("Vet for the Insane") (UNIX) (Linux/2.4.0-XFS-test10 (i686))
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

"Nathan Scott" <nathans@wobbly.melbourne.sgi.com> wrote:
> hi Thomas,

> On Nov 24,  1:21pm, Thomas Graichen wrote:
>> Subject: Re: stress test on ppc
>> ...
>> 
>> df gave: blocks=3136128 used=11488 avail=3124640
>> blocksize from xfs_db is '524288'

> that's the problem right there (the blocksize).

> I don't understand how one could get a blocksize like
> that since the test runs mkfs.xfs on the scratch device
> and so should always have a blocksize of 4K (by default)
> - see _populate_scratch() in the test, followed by the
> blksize=... line a little further down.

ah - i have an idea here: i'm currently using the ide driver from the
ppc linux tree - where i had to add the

  case BLKSETSIZE:

to ide_ioctl in ide.c - maybe i have missed something there - but
from the diffs there was nothing suspect between the two ide drivers
which let me think of something too different ...

>> > (btw, any luck with ppc mount detecting a minix filesystem?)
>> 
>> sorry- looks like this was my fault: minix fs was simply not compiled
>> into the kernel :-(

> no, that wouldn't affect this test - its all user space
> testing of mkfs (no actual mount happens), so no kernel
> support for other filesystems is required.

>> ... works now

> *shrug* - must have been an alignment-of-the-planets issue.

no - you are right - the test still fails ... hm - but mount works
now with minix ... i think this is what you were talking about:

ppc:/usr/src/xfs/cmd/xfs/stress # mkfs -t minix /dev/hda9
21856 inodes
65535 blocks
Firstdatazone=696 (696)
Zonesize=1024
Maxsize=268966912

ppc:/usr/src/xfs/cmd/xfs/stress # mount /dev/hda9 /mnt
ppc:/usr/src/xfs/cmd/xfs/stress # mount | grep /mnt
/dev/hda9 on /mnt type minix (rw)
ppc:/usr/src/xfs/cmd/xfs/stress # umount /mnt
ppc:/usr/src/xfs/cmd/xfs/stress # mkfs -t xfs /dev/hda9
meta-data=/dev/hda9              isize=256    agcount=8, agsize=49152 blks
data     =                       bsize=4096   blocks=393216, imaxpct=25
         =                       sunit=0      swidth=0 blks, unwritten=0
naming   =version 2              bsize=4096  
log      =internal log           bsize=4096   blocks=1200
realtime =none                   extsz=65536  blocks=0, rtextents=0
ppc:/usr/src/xfs/cmd/xfs/stress #

btw. i'm not shure if it really is only usermode - i think at least
the suse mount seems to require fs support (maybe looking into
/proc/filesystems - suse has no /etc/filesystems for instance) for
the mount fs detection - otherwise you get a "wrong major ..."

t

-- 
thomas.graichen@innominate.com
technical director                                       innominate AG
clustering & security                             the linux architects
tel: +49-30-308806-13   fax: -77             http://www.innominate.com

From owner-linux-xfs@oss.sgi.com Mon Nov 27 05:52:41 2000
Received:  by oss.sgi.com id <S553866AbQK0Nwc>;
	Mon, 27 Nov 2000 05:52:32 -0800
Received: from [193.154.31.82] ([193.154.31.82]:32261 "HELO convert rfc822-to-8bit
        cerberus.bsbanksysteme.com") by oss.sgi.com with SMTP
	id <S553845AbQK0NwP>; Mon, 27 Nov 2000 05:52:15 -0800
Received: (qmail 25328 invoked by uid 508); 27 Nov 2000 13:52:13 -0000
Received: from christian.guertler@bs-ag.com by cerberus_bsbanksysteme_com with scan4virus-0.53 (uvscan: v4.0.70/v4107. . Clean. Processed in 0.125632 secs); 27/11/2000 14:52:13
Received: from unknown (HELO ntfax.bsbanksysteme.com) (192.168.0.51)
  by 192.168.0.59 with SMTP; 27 Nov 2000 13:52:13 -0000
Received: by NTFAX.bsbanksysteme.com with Internet Mail Service (5.5.2650.21)
	id <XWKJJ544>; Mon, 27 Nov 2000 14:52:08 +0100
Message-ID: <81CF965D19DDD21195AC00C04FB9ACF58438D8@NTFAX.bsbanksysteme.com>
From:   Christian Guertler <christian.guertler@bs-ag.com>
To:     "'linux-xfs@oss.sgi.com'" <linux-xfs@oss.sgi.com>
Subject: resizing xfs
Date:   Mon, 27 Nov 2000 14:52:07 +0100
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;

does anyone know, howto enlarge a partition with xfs-filesystem? 
xfs_growfs says, that "data-size is too large, maximum is 1024143" after
"xfs_growfs -D 1024500 /test_xfs" for example.

These are the data after "xfs_growfs -n /test_xfs"
meta-data=/test_xfs              isize=256    agcount=8, agsize=128018 blks
data     =                       bsize=4096   blocks=1024143, imaxpct=25
         =                       sunit=0      swidth=0 blks, unwritten=0
naming   =version 2              bsize=4096  
log      =internal               bsize=4096   blocks=1200
realtime =none                   extsz=65536  blocks=0, rtextents=0

But there is enough space on my disk (it is a disk with 30 GB, now 3
partitions each 4 GB)
Do I have to build an new partition with ext2 and do I have to use lvm or
does it work without lvm, too? The man-page on xfs_growfs is not really
clear for me.

Sincerly
Christian Gürtler

From owner-linux-xfs@oss.sgi.com Mon Nov 27 11:19:22 2000
Received:  by oss.sgi.com id <S553682AbQK0TTD>;
	Mon, 27 Nov 2000 11:19:03 -0800
Received: from deliverator.sgi.com ([204.94.214.10]:38223 "EHLO
        deliverator.sgi.com") by oss.sgi.com with ESMTP id <S553652AbQK0TTC>;
	Mon, 27 Nov 2000 11:19:02 -0800
Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id LAA01394
	for <linux-xfs@oss.sgi.com>; Mon, 27 Nov 2000 11:18:57 -0800 (PST)
	mail_from (cattelan@thebarn.com)
Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id NAA7748097; Mon, 27 Nov 2000 13:16:25 -0600 (CST)
Received: from gibble.americas.sgi.com (gibble.americas.sgi.com [128.162.195.80]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id NAA63207; Mon, 27 Nov 2000 13:16:25 -0600 (CST)
Received: from thebarn.com (localhost [127.0.0.1])
	by gibble.americas.sgi.com (8.11.0/8.10.1) with ESMTP id eARJGOm18297;
	Mon, 27 Nov 2000 13:16:25 -0600
Message-ID: <3A22B308.717A170F@thebarn.com>
Date:   Mon, 27 Nov 2000 13:16:24 -0600
From:   Russell Cattelan <cattelan@thebarn.com>
X-Mailer: Mozilla 4.75 [en] (X11; U; Linux 2.4.0-XFS_BETA_3smp i686)
X-Accept-Language: en
MIME-Version: 1.0
To:     Christian Guertler <christian.guertler@bs-ag.com>
CC:     "'linux-xfs@oss.sgi.com'" <linux-xfs@oss.sgi.com>
Subject: Re: resizing xfs
References: <81CF965D19DDD21195AC00C04FB9ACF58438D8@NTFAX.bsbanksysteme.com>
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

Christian Guertler wrote:

> Hi;
>
> does anyone know, howto enlarge a partition with xfs-filesystem?
> xfs_growfs says, that "data-size is too large, maximum is 1024143" after
> "xfs_growfs -D 1024500 /test_xfs" for example.
>
> These are the data after "xfs_growfs -n /test_xfs"
> meta-data=/test_xfs              isize=256    agcount=8, agsize=128018 blks
> data     =                       bsize=4096   blocks=1024143, imaxpct=25
>          =                       sunit=0      swidth=0 blks, unwritten=0
> naming   =version 2              bsize=4096
> log      =internal               bsize=4096   blocks=1200
> realtime =none                   extsz=65536  blocks=0, rtextents=0
>
> But there is enough space on my disk (it is a disk with 30 GB, now 3
> partitions each 4 GB)
> Do I have to build an new partition with ext2 and do I have to use lvm or
> does it work without lvm, too? The man-page on xfs_growfs is not really
> clear for me.

What is the size of your partition?
You are probably requesting a size larger than the partition can handle.
The max size for any XFS file system basic block size 512 rounded down to the
nearest
file system block size in this case (and all case at the moment) 4k.

Simply running xfs_growfs </mntpt> should expand the file system to the max
available
for that partition.



>
> Sincerly
> Christian Gürtler


From owner-linux-xfs@oss.sgi.com Mon Nov 27 14:12:43 2000
Received:  by oss.sgi.com id <S553733AbQK0WMd>;
	Mon, 27 Nov 2000 14:12:33 -0800
Received: from pneumatic-tube.sgi.com ([204.94.214.22]:8038 "EHLO
        pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP
	id <S553687AbQK0WMP>; Mon, 27 Nov 2000 14:12:15 -0800
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 OAA00977
	for <linux-xfs@oss.sgi.com>; Mon, 27 Nov 2000 14:20:14 -0800 (PST)
	mail_from (nathans@wobbly.melbourne.sgi.com)
Received: from wobbly.melbourne.sgi.com (wobbly.melbourne.sgi.com [134.14.55.135]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id JAA28717; Tue, 28 Nov 2000 09:10:57 +1100
Received: (from nathans@localhost) by wobbly.melbourne.sgi.com (980427.SGI.8.8.8/980728.SGI.AUTOCF) id JAA69818; Tue, 28 Nov 2000 09:10:56 +1100 (EDT)
From:   "Nathan Scott" <nathans@wobbly.melbourne.sgi.com>
Message-Id: <10011280910.ZM168487@wobbly.melbourne.sgi.com>
Date:   Tue, 28 Nov 2000 09:10:54 -0400
In-Reply-To: Thomas Graichen <news-innominate.list.sgi.xfs@innominate.de>
        "Re: alpha again" (Nov 27,  8:09am)
References: <news2mail-8vmd9o$upi$1@mate.bln.innominate.de> 
	<10011261353.ZM165451@wobbly.melbourne.sgi.com> 
	<news2mail-8vt4sn$dhv$2@mate.bln.innominate.de>
X-Mailer: Z-Mail (3.2.3 08feb96 MediaMail)
To:     Thomas Graichen <graichen@innominate.de>,
        thomas.graichen@innominate.de
Subject: Re: alpha again
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

hi Thomas,

On Nov 27,  8:09am, Thomas Graichen wrote:
> Subject: Re: alpha again
> ...
> > (could you send me the output in each place - thanks).
> ...

everything looks good up till here...

> >> root@cyan:/usr/src/xfs/linux# mount /dev/sdb1 /mnt
> >> root@cyan:/usr/src/xfs/linux# umount /mnt
> 
> > (*) here
> 
> root@cyan:~# xfs_db -r -c agf -c p /dev/sdb1
> magicnum = 0
> versionnum = 4294967295
> seqno = 0
> length = 0
> bnoroot = 2966461184
> cntroot = 16580607
> bnolevel = 16580607
> cntlevel = 0
> flfirst = 2147483648
> fllast = 0
> flcount = 1088476165
> freeblks = 16580607
> longest = 14734341
> root@cyan:~#
> 

heh - thats completely bogus.  so the problem is in the kernel
(xfs mount/umount code paths) after all.

on the plus side, mkfs and repair both seem to be doing the
right thing.

> ...
> > I'm a little surprised that we can get thru dbench with what
> > seem like such fundamental problems... hmm - perhaps its only
> > a userspace problem (seeking to the wrong place or something).

it seems this is not the case.

my next best guess at the probable cause is that this may
be a blocksize related problem.  we know that the primary
superblock is pretty much intact (otherwise xfs_db would have
gone haywire) - but since its offset is at start of blk 0,
we're always likely to get that right no matter what the page
& blksizes are, I think.

> yes - the filesystem as such runs perfectly so far - tell me if you
> need anything else

I need two more things, then I'll have to go read the code
some & get back to you:
- run "xfs_db -r -c sb -c p /dev/sdb1" after the mkfs, so I
know where we're starting from (primary sb);
- run "xfs_db -r -c agf -c p /dev/sdb1" again, but in-between
the mount and umount (there are writes on the mount path too,
with any luck we'll see corruption early on which should make
it easier to diagnose).

thanks!

-- 
Nathan

From owner-linux-xfs@oss.sgi.com Mon Nov 27 15:45:43 2000
Received:  by oss.sgi.com id <S553694AbQK0Xpe>;
	Mon, 27 Nov 2000 15:45:34 -0800
Received: from deliverator.sgi.com ([204.94.214.10]:45376 "EHLO
        deliverator.sgi.com") by oss.sgi.com with ESMTP id <S553673AbQK0XpK>;
	Mon, 27 Nov 2000 15:45:10 -0800
Received: from nodin.corp.sgi.com (fddi-nodin.corp.sgi.com [198.29.75.193]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id PAA24676; Mon, 27 Nov 2000 15:45:10 -0800 (PST)
	mail_from (nobody@info.engr.sgi.com)
Received: from info.engr.sgi.com (info.engr.sgi.com [192.26.80.216]) by nodin.corp.sgi.com (980427.SGI.8.8.8/980728.SGI.AUTOCF) via ESMTP id PAA39864; Mon, 27 Nov 2000 15:44:39 -0800 (PST)
Received: (from nobody@localhost)
	by info.engr.sgi.com (SGI-8.9.3/8.9.3) id PAA92219;
	Mon, 27 Nov 2000 15:43:22 -0800 (PST)
Date:   Mon, 27 Nov 2000 15:43:22 -0800 (PST)
Message-Id: <200011272343.PAA92219@info.engr.sgi.com>
X-Pv-Incident: 807351 
webPV:  proxy2.melbourne.sgi.com 
webExec: webpvupdate,pvincident 
Reply-To: sgi.bugs.xfs@fido.engr.sgi.com
From:   pv@relay.sgi.com (tes@engr.sgi.com)
Subject: CLOSE 807351 - xfsdump not seemingly to always update inventory
To:     tes@engr.sgi.com
Cc:     ivanr@cthulhu.engr.sgi.com, 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=807351

*Status : closed                       Priority : 3                         
 Assigned Engineer : tes               Submitter : tes                      
 Opened Date : 11/08/00               *Closed Date : 11/27/00               
*Fixed By : tes                       *Fixed By Domain : engr               
*Modified Date : 11/27/00             *Modified User : tes                  
*Modified User Domain : engr          *Fix Description :
==========================
ADDITIONAL INFORMATION (CLOSE)
From: tes@engr (BugWorks)
Date: Nov 27 2000 03:43:21PM
==========================

It appears this problem has gone away after using
the suggested compiler.

Eric wrote:
-----------------------------------------------------------
Ah, using kgcc (egcs-2.91.66) to compile the tools, rather than RH 7.0's
"gcc" (2.96) fixed the problem.  Sorry, should have thought of that
earlier... 

-Eric
-----------------------------------------------------------

From owner-linux-xfs@oss.sgi.com Mon Nov 27 15:51:44 2000
Received:  by oss.sgi.com id <S553708AbQK0Xve>;
	Mon, 27 Nov 2000 15:51:34 -0800
Received: from deliverator.sgi.com ([204.94.214.10]:37698 "EHLO
        deliverator.sgi.com") by oss.sgi.com with ESMTP id <S553690AbQK0XvY>;
	Mon, 27 Nov 2000 15:51:24 -0800
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 PAA25676
	for <linux-xfs@oss.sgi.com>; Mon, 27 Nov 2000 15:51:18 -0800 (PST)
	mail_from (nathans@wobbly.melbourne.sgi.com)
Received: from wobbly.melbourne.sgi.com (wobbly.melbourne.sgi.com [134.14.55.135]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id KAA29613; Tue, 28 Nov 2000 10:48:46 +1100
Received: (from nathans@localhost) by wobbly.melbourne.sgi.com (980427.SGI.8.8.8/980728.SGI.AUTOCF) id KAA52274; Tue, 28 Nov 2000 10:48:45 +1100 (EDT)
From:   "Nathan Scott" <nathans@wobbly.melbourne.sgi.com>
Message-Id: <10011281048.ZM165042@wobbly.melbourne.sgi.com>
Date:   Tue, 28 Nov 2000 10:48:43 -0400
In-Reply-To: Thomas Graichen <news-innominate.list.sgi.xfs@innominate.de>
        "Re: stress test on ppc" (Nov 27,  8:27am)
References: <news2mail-8uecj0$i5e$1@mate.bln.innominate.de> 
	<10011101103.ZM113097@wobbly.melbourne.sgi.com> 
	<20001110094151.C333@ysabell> 
	<10011110006.ZM127189@wobbly.melbourne.sgi.com> 
	<news2mail-8uo7od$4lt$1@mate.bln.innominate.de> 
	<10011141059.ZM128320@wobbly.melbourne.sgi.com> 
	<news2mail-8utlfv$8iu$1@mate.bln.innominate.de> 
	<10011221244.ZM158790@wobbly.melbourne.sgi.com> 
	<news2mail-8vlq0n$hiu$2@mate.bln.innominate.de> 
	<10011261336.ZM166460@wobbly.melbourne.sgi.com> 
	<news2mail-8vt5ub$dhv$3@mate.bln.innominate.de>
X-Mailer: Z-Mail (3.2.3 08feb96 MediaMail)
To:     Thomas Graichen <graichen@innominate.de>,
        thomas.graichen@innominate.de
Subject: Re: stress test on ppc
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

hi,

On Nov 27,  8:27am, Thomas Graichen wrote:
> Subject: Re: stress test on ppc
> > ...
> > I don't understand how one could get a blocksize like
> > that since the test runs mkfs.xfs on the scratch device
> > and so should always have a blocksize of 4K (by default)
> > - see _populate_scratch() in the test, followed by the
> > blksize=... line a little further down.
> 
> ah - i have an idea here: i'm currently using the ide driver from the
> ppc linux tree - where i had to add the
> 
>   case BLKSETSIZE:
> 
> to ide_ioctl in ide.c - maybe i have missed something there - but
> from the diffs there was nothing suspect between the two ide drivers
> which let me think of something too different ...
> 

no, thats not it.  the (filesystem) blocksize comes from mkfs.xfs
and is written into all of the superblocks using the value which
mkfs calculates.  By default (which is the case, in test 004)
this is (1<<XFS_DFL_BLOCKSIZE_LOG)... 4096.  you could trace the
value of the "blocksize" variable in xfs_mkfs.c ... it eventually
gets stuffed into the primary sb (line 1390) and written to disk
(line 1499).

so running xfs_db after doing mkfs.xfs with no blksize options
(as in test 004 - populate_scratch() routine) should always show
the blocksize as 4096.  what i don't understand is how we've ended
up with a non-default (but valid) blocksize after doing a default
mkfs.

> >> > (btw, any luck with ppc mount detecting a minix filesystem?)
> >> 
> >> sorry- looks like this was my fault: minix fs was simply not compiled
> >> into the kernel :-(
> 
> > no, that wouldn't affect this test - its all user space
> > testing of mkfs (no actual mount happens), so no kernel
> > support for other filesystems is required.
> 
> >> ... works now
> 
> > *shrug* - must have been an alignment-of-the-planets issue.
> 
> no - you are right - the test still fails ... hm - but mount works
> now with minix ... i think this is what you were talking about:
> 
> ppc:/usr/src/xfs/cmd/xfs/stress # mkfs -t minix /dev/hda9
> 21856 inodes
> 65535 blocks
> Firstdatazone=696 (696)
> Zonesize=1024
> Maxsize=268966912
> 
> ppc:/usr/src/xfs/cmd/xfs/stress # mount /dev/hda9 /mnt

yup - thats it ... looks like your mount does auto-detect
minix somehow.  hmmm... i'll need to go see whats different
between your mount code and the mkfs/mountinfo.c code.  which
version of mount are you using?  (mount -V?)

> ppc:/usr/src/xfs/cmd/xfs/stress # mount | grep /mnt
> /dev/hda9 on /mnt type minix (rw)
> ppc:/usr/src/xfs/cmd/xfs/stress # umount /mnt
> ppc:/usr/src/xfs/cmd/xfs/stress # mkfs -t xfs /dev/hda9
> meta-data=/dev/hda9              isize=256    agcount=8, agsize=49152 blks
> data     =                       bsize=4096   blocks=393216, imaxpct=25
>          =                       sunit=0      swidth=0 blks, unwritten=0
> naming   =version 2              bsize=4096  
> log      =internal log           bsize=4096   blocks=1200
> realtime =none                   extsz=65536  blocks=0, rtextents=0
> ppc:/usr/src/xfs/cmd/xfs/stress #
> 
> btw. i'm not shure if it really is only usermode - i think at least
> the suse mount seems to require fs support (maybe looking into
> /proc/filesystems - suse has no /etc/filesystems for instance) for
> the mount fs detection - otherwise you get a "wrong major ..."
> 

is Suse mount based on Andries Brouwers' util-linux mount code?
I'd be surprised if not.  This looks in all sorts of places to
try and figure out the filesystem type (including procfs & /etc,
but also by probing).   Its this probing code which mkfs.xfs
uses in order to try not write on an existing filesystem.

do you see something like this on powerpc?...
10:11 nathans@troppo ~/src/util-linux-2.10q/mount 49> sudo mkfs -t minix /dev/hdb9
21856 inodes
65535 blocks
Firstdatazone=696 (696)
Zonesize=1024
Maxsize=268966912

10:12 nathans@troppo ~/src/util-linux-2.10q/mount 50> sudo od -j 1024 -x -N 32 /dev/hdb9
0002000 5560 ffff 0003 0008 02b8 0000 1c00 1008
0002020 138f 0001 0000 0000 0000 0000 0000 0000
        ^^^^
0002040
10:12 nathans@troppo ~/src/util-linux-2.10q/mount 51> 

the 0x138f is the minix magic number which the mount "probe"
code is looking for.

hmmm .... i think this is going to be an endian problem in
mount.  in particular this mount_guess_fstype.c code looks
suspect:

    else if (minixmagic(sb.ms) == MINIX_SUPER_MAGIC
             || minixmagic(sb.ms) == MINIX_SUPER_MAGIC2)
         type = "minix";

especially compared to the ext2 code immediately above it
(this same code is in cmd/xfs/mkfs/mountinfo.c).

cheers.

-- 
Nathan

From owner-linux-xfs@oss.sgi.com Mon Nov 27 16:10:23 2000
Received:  by oss.sgi.com id <S553729AbQK1AKO>;
	Mon, 27 Nov 2000 16:10:14 -0800
Received: from pneumatic-tube.sgi.com ([204.94.214.22]:43375 "EHLO
        pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP
	id <S553702AbQK1AJ5>; Mon, 27 Nov 2000 16:09:57 -0800
Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.55.149]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id QAA05449
	for <linux-xfs@oss.sgi.com>; Mon, 27 Nov 2000 16:17:56 -0800 (PST)
	mail_from (nathans@snort.melbourne.sgi.com)
Received: (from nathans@localhost)
	by snort.melbourne.sgi.com (SGI-8.9.3/8.9.3) id LAA72597
	for linux-xfs@oss.sgi.com; Tue, 28 Nov 2000 11:07:21 +1100 (EST)
Date:   Tue, 28 Nov 2000 11:07:21 +1100 (EST)
From:   Nathan Scott <nathans@snort.melbourne.sgi.com>
Message-Id: <200011280007.LAA72597@snort.melbourne.sgi.com>
To:     linux-xfs@oss.sgi.com
Subject: TAKE - mountinfo.c
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing

Thomas, can you see if this fixes the stress/033 failure on ppc?
-- thanks.

Modid:  2.4.x-xfs:slinx:78970a
Date:  Mon Nov 27 16:04:20 PST 2000
Workarea:  snort:/build4/nathans/linux-xfs
Author:  nathans

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

cmd/xfs/mkfs/mountinfo.c - 1.4
	- fix auto-detection of minix filesystems on big endian systems.


From owner-linux-xfs@oss.sgi.com Mon Nov 27 23:19:25 2000
Received:  by oss.sgi.com id <S553700AbQK1HTP>;
	Mon, 27 Nov 2000 23:19:15 -0800
Received: from deliverator.sgi.com ([204.94.214.10]:1327 "EHLO
        deliverator.sgi.com") by oss.sgi.com with ESMTP id <S553657AbQK1HS5>;
	Mon, 27 Nov 2000 23:18:57 -0800
Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id XAA22263
	for <linux-xfs@oss.sgi.com>; Mon, 27 Nov 2000 23:18:56 -0800 (PST)
	mail_from (cattelan@gibble.americas.sgi.com)
Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id BAA7756635 for <linux-xfs@oss.sgi.com>; Tue, 28 Nov 2000 01:16:25 -0600 (CST)
Received: from gibble.americas.sgi.com (gibble.americas.sgi.com [128.162.195.80]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id BAA40087 for <linux-xfs@oss.sgi.com>; Tue, 28 Nov 2000 01:16:25 -0600 (CST)
Received: (from cattelan@localhost)
	by gibble.americas.sgi.com (8.11.0/8.10.1) id eAS7GPW04366
	for linux-xfs@oss.sgi.com; Tue, 28 Nov 2000 01:16:25 -0600
Date:   Tue, 28 Nov 2000 01:16:25 -0600
From:   Russell Cattelan <cattelan@sgi.com>
Message-Id: <200011280716.eAS7GPW04366@gibble.americas.sgi.com>
Subject: TAKE - 
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

Date:  Mon Nov 27 23:16:05 PST 2000
Workarea:  gibble.americas.sgi.com:/export/extra/x2.4-xfs-clean

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


Modid:  2.4.x-xfs:slinx:78994a
linux/drivers/block/ll_rw_blk.c - 1.52
	- Remove some debugging code that slipped in by mistake.



From owner-linux-xfs@oss.sgi.com Tue Nov 28 01:38:08 2000
Received:  by oss.sgi.com id <S553655AbQK1Jh6>;
	Tue, 28 Nov 2000 01:37:58 -0800
Received: from [193.154.31.82] ([193.154.31.82]:41230 "HELO convert rfc822-to-8bit  =?ISO-8859-1?Q?y=01?=
        cerberus.bsbanksysteme.com") by oss.sgi.com with SMTP
	id <S553647AbQK1Jhn>; Tue, 28 Nov 2000 01:37:43 -0800
Received: (qmail 18361 invoked by uid 508); 28 Nov 2000 09:37:35 -0000
Received: from christian.guertler@bs-ag.com by cerberus_bsbanksysteme_com with scan4virus-0.53 (uvscan: v4.0.70/v4107. . Clean. Processed in 0.124945 secs); 28/11/2000 10:37:35
Received: from unknown (HELO ntfax.bsbanksysteme.com) (192.168.0.51)
  by 192.168.0.59 with SMTP; 28 Nov 2000 09:37:35 -0000
Received: by NTFAX.bsbanksysteme.com with Internet Mail Service (5.5.2650.21)
	id <XWKJJ6CA>; Tue, 28 Nov 2000 10:37:30 +0100
Message-ID: <81CF965D19DDD21195AC00C04FB9ACF58438D9@NTFAX.bsbanksysteme.com>
From:   Christian Guertler <christian.guertler@bs-ag.com>
To:     'Russell Cattelan' <cattelan@thebarn.com>
Cc:     "'linux-xfs@oss.sgi.com'" <linux-xfs@oss.sgi.com>
Subject: AW: resizing xfs
Date:   Tue, 28 Nov 2000 10:37:30 +0100
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

Thanks for the answer, but it is still not clear to me.
The size of  the partiton is 1024143 blocks, each 4K (in summary 4GB). Is
this the maximum? Which max size can the partition handle? Is 1024143 blocks
my maximum?


> Christian Guertler wrote:
> 
> > Hi;
> >
> > does anyone know, howto enlarge a partition with xfs-filesystem?
> > xfs_growfs says, that "data-size is too large, maximum is 1024143" after
> > "xfs_growfs -D 1024500 /test_xfs" for example.
> >
> > These are the data after "xfs_growfs -n /test_xfs"
> > meta-data=/test_xfs              isize=256    agcount=8, agsize=128018
> blks
> > data     =                       bsize=4096   blocks=1024143, imaxpct=25
> >          =                       sunit=0      swidth=0 blks, unwritten=0
> > naming   =version 2              bsize=4096
> > log      =internal               bsize=4096   blocks=1200
> > realtime =none                   extsz=65536  blocks=0, rtextents=0
> >
> > But there is enough space on my disk (it is a disk with 30 GB, now 3
> > partitions each 4 GB)
> > Do I have to build an new partition with ext2 and do I have to use lvm
> or
> > does it work without lvm, too? The man-page on xfs_growfs is not really
> > clear for me.
> 
> What is the size of your partition?
> You are probably requesting a size larger than the partition can handle.
> The max size for any XFS file system basic block size 512 rounded down to
> the
> nearest
> file system block size in this case (and all case at the moment) 4k.
> 
> Simply running xfs_growfs </mntpt> should expand the file system to the
> max
> available
> for that partition.
> 
> 
> 
> >
> > Sincerly
> > Christian Gürtler

From owner-linux-xfs@oss.sgi.com Tue Nov 28 02:26:17 2000
Received:  by oss.sgi.com id <S553692AbQK1K0I>;
	Tue, 28 Nov 2000 02:26:08 -0800
Received: from hermes.mixx.net ([212.84.196.2]:60934 "HELO hermes.mixx.net")
	by oss.sgi.com with SMTP id <S553652AbQK1KZ6>;
	Tue, 28 Nov 2000 02:25:58 -0800
Received: from mate.bln.innominate.de (cerberus.berlin.innominate.de [212.84.234.251])
	by hermes.mixx.net (Postfix) with ESMTP id AFBDCF80F
	for <linux-xfs@oss.sgi.com>; Tue, 28 Nov 2000 11:25:56 +0100 (CET)
Received: by mate.bln.innominate.de (Postfix, from userid 9)
	id 7E7382CAA2; Tue, 28 Nov 2000 11:25:56 +0100 (CET)
From:   Thomas Graichen <news-innominate.list.sgi.xfs@innominate.de>
Reply-To: Thomas Graichen <graichen@innominate.de>
X-Newsgroups: innominate.list.sgi.xfs
Subject: Re: alpha again
Date:   28 Nov 2000 10:25:56 GMT
Organization: innominate AG, Berlin, Germany
Lines:  154
Distribution: local
Message-ID: <news2mail-90017k$n0b$1@mate.bln.innominate.de>
References: <news2mail-8vmd9o$upi$1@mate.bln.innominate.de>   <10011261353.ZM165451@wobbly.melbourne.sgi.com>   <news2mail-8vt4sn$dhv$2@mate.bln.innominate.de> <10011280910.ZM168487@wobbly.melbourne.sgi.com>
Reply-To: thomas.graichen@innominate.de
X-Trace: mate.bln.innominate.de 975407156 23563 10.0.0.31 (28 Nov 2000 10:25:56 GMT)
X-Complaints-To: news@innominate.de
User-Agent: tin/1.4.4-20000803 ("Vet for the Insane") (UNIX) (Linux/2.4.0-XFS-test10 (i686))
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

"Nathan Scott" <nathans@wobbly.melbourne.sgi.com> wrote:
...
> heh - thats completely bogus.  so the problem is in the kernel
> (xfs mount/umount code paths) after all.
...
> my next best guess at the probable cause is that this may
> be a blocksize related problem.  we know that the primary
> superblock is pretty much intact (otherwise xfs_db would have
> gone haywire) - but since its offset is at start of blk 0,
> we're always likely to get that right no matter what the page
> & blksizes are, I think.
...
> I need two more things, then I'll have to go read the code
> some & get back to you:
> - run "xfs_db -r -c sb -c p /dev/sdb1" after the mkfs, so I
> know where we're starting from (primary sb);
> - run "xfs_db -r -c agf -c p /dev/sdb1" again, but in-between
> the mount and umount (there are writes on the mount path too,
> with any luck we'll see corruption early on which should make
> it easier to diagnose).

root@cyan:~# mkfs -t xfs -f -b size=8192 /dev/sdb1
meta-data=/dev/sdb1              isize=256    agcount=8, agsize=4142 blks
data     =                       bsize=8192   blocks=33130, imaxpct=25
         =                       sunit=0      swidth=0 blks, unwritten=0
naming   =version 2              bsize=8192  
log      =internal log           bsize=8192   blocks=1000
realtime =none                   extsz=65536  blocks=0, rtextents=0
root@cyan:~# xfs_db -r -c sb -c p /dev/sdb1
magicnum = 0x58465342
blocksize = 8192
dblocks = 33130
rblocks = 0
rextents = 0
uuid = f30502a5-d2fd-490a-b915-2b48635e5d88
logstart = 32772
rootino = 256
rbmino = 257
rsumino = 258
rextsize = 8
agblocks = 4142
agcount = 8
rbmblocks = 0
logblocks = 1000
versionnum = 0x2084
sectsize = 512
inodesize = 256
inopblock = 32
fname = "\000\000\000\000\000\000\000\000\000\000\000\000"
blocklog = 13
sectlog = 9
inodelog = 8
inopblog = 5
agblklog = 13
rextslog = 0
inprogress = 0
imax_pct = 25
icount = 64
ifree = 61
fdblocks = 32096
frextents = 0
uquotino = 0
pquotino = 0
qflags = 0
flags = 0
shared_vn = 0
inoalignmt = 1
unit = 0
width = 0
dirblklog = 0
root@cyan:~# xfs_db -r -c agf -c p /dev/sdb1
magicnum = 0x58414746
versionnum = 1
seqno = 0
length = 4142
bnoroot = 1
cntroot = 2
bnolevel = 1
cntlevel = 1
flfirst = 0
fllast = 3
flcount = 4
freeblks = 4132
longest = 4132
root@cyan:~# mount /dev/sdb1 /mnt; xfs_db -r -c agf -c p /dev/sdb1
magicnum = 0x58414746
versionnum = 1
seqno = 0
length = 4142
bnoroot = 1
cntroot = 2
bnolevel = 1
cntlevel = 1
flfirst = 0
fllast = 3
flcount = 4
freeblks = 4132
longest = 4132
root@cyan:~# xfs_db -r -c agf -c p /dev/sdb1
magicnum = 0x58414746
versionnum = 1
seqno = 0
length = 4142
bnoroot = 1
cntroot = 2
bnolevel = 1
cntlevel = 1
flfirst = 0
fllast = 3
flcount = 4
freeblks = 4132
longest = 4132
root@cyan:~# xfs_db -r -c agf -c p /dev/sdb1
magicnum = 0x58414746
versionnum = 1
seqno = 0
length = 4142
bnoroot = 1
cntroot = 2
bnolevel = 1
cntlevel = 1
flfirst = 0
fllast = 3
flcount = 4
freeblks = 4132
longest = 4132
root@cyan:~# umount /mnt
root@cyan:~# xfs_db -r -c agf -c p /dev/sdb1
magicnum = 0
versionnum = 4294967295
seqno = 0
length = 0
bnoroot = 2966461184
cntroot = 16580607
bnolevel = 16580607
cntlevel = 0
flfirst = 2147483648
fllast = 0
flcount = 1080068612
freeblks = 16580607
longest = 6326788
root@cyan:~# 

so looks like the umount code trashes things - this would also make
clear why xfs survives the dbench 64 - the filesystem seems to be
stable while operating and only gets trashed on umount ...

t

-- 
thomas.graichen@innominate.com
technical director                                       innominate AG
clustering & security                             the linux architects
tel: +49-30-308806-13   fax: -77             http://www.innominate.com

From owner-linux-xfs@oss.sgi.com Tue Nov 28 02:38:27 2000
Received:  by oss.sgi.com id <S553714AbQK1KiS>;
	Tue, 28 Nov 2000 02:38:18 -0800
Received: from hermes.mixx.net ([212.84.196.2]:31751 "HELO hermes.mixx.net")
	by oss.sgi.com with SMTP id <S553686AbQK1Kh5>;
	Tue, 28 Nov 2000 02:37:57 -0800
Received: from mate.bln.innominate.de (cerberus.berlin.innominate.de [212.84.234.251])
	by hermes.mixx.net (Postfix) with ESMTP id B1C23F82E
	for <linux-xfs@oss.sgi.com>; Tue, 28 Nov 2000 11:37:55 +0100 (CET)
Received: by mate.bln.innominate.de (Postfix, from userid 9)
	id 58E722CAA2; Tue, 28 Nov 2000 11:37:55 +0100 (CET)
From:   Thomas Graichen <news-innominate.list.sgi.xfs@innominate.de>
Reply-To: Thomas Graichen <graichen@innominate.de>
X-Newsgroups: innominate.list.sgi.xfs
Subject: Re: stress test on ppc
Date:   28 Nov 2000 10:37:55 GMT
Organization: innominate AG, Berlin, Germany
Lines:  139
Distribution: local
Message-ID: <news2mail-9001u3$n0b$2@mate.bln.innominate.de>
References: <news2mail-8uecj0$i5e$1@mate.bln.innominate.de>   <10011110006.ZM127189@wobbly.melbourne.sgi.com>   <news2mail-8uo7od$4lt$1@mate.bln.innominate.de>   <10011141059.ZM128320@wobbly.melbourne.sgi.com>   <news2mail-8utlfv$8iu$1@mate.bln.innominate.de>   <10011221244.ZM158790@wobbly.melbourne.sgi.com>   <news2mail-8vlq0n$hiu$2@mate.bln.innominate.de>   <10011261336.ZM166460@wobbly.melbourne.sgi.com>   <news2mail-8vt5ub$dhv$3@mate.bln.innominate.de> <10011281048.ZM165042@wobbly.melbourne.sgi.com>
Reply-To: thomas.graichen@innominate.de
X-Trace: mate.bln.innominate.de 975407875 23563 10.0.0.31 (28 Nov 2000 10:37:55 GMT)
X-Complaints-To: news@innominate.de
User-Agent: tin/1.4.4-20000803 ("Vet for the Insane") (UNIX) (Linux/2.4.0-XFS-test10 (i686))
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

"Nathan Scott" <nathans@wobbly.melbourne.sgi.com> wrote:
...
> no, thats not it.  the (filesystem) blocksize comes from mkfs.xfs
> and is written into all of the superblocks using the value which
> mkfs calculates.  By default (which is the case, in test 004)
> this is (1<<XFS_DFL_BLOCKSIZE_LOG)... 4096.  you could trace the
> value of the "blocksize" variable in xfs_mkfs.c ... it eventually
> gets stuffed into the primary sb (line 1390) and written to disk
> (line 1499).

> so running xfs_db after doing mkfs.xfs with no blksize options
> (as in test 004 - populate_scratch() routine) should always show
> the blocksize as 4096.  what i don't understand is how we've ended
> up with a non-default (but valid) blocksize after doing a default
> mkfs.

hm - but mkfs.xfs is using the correct one:

  ...
  naming   =version 2              bsize=4096  
  log      =internal log           bsize=4096   blocks=1200
  ...

so you assume that either xfs_db gets it wrong or it is stored some-
how wrong on the filesystem (which i can't really believe due to how
well xfs works on the ppc :-)?

>> ppc:/usr/src/xfs/cmd/xfs/stress # mount /dev/hda9 /mnt

> yup - thats it ... looks like your mount does auto-detect
> minix somehow.  hmmm... i'll need to go see whats different
> between your mount code and the mkfs/mountinfo.c code.  which
> version of mount are you using?  (mount -V?)

ppc:~ # mount -V
mount: mount-2.10m
ppc:~ #

>> btw. i'm not shure if it really is only usermode - i think at least
>> the suse mount seems to require fs support (maybe looking into
>> /proc/filesystems - suse has no /etc/filesystems for instance) for
>> the mount fs detection - otherwise you get a "wrong major ..."
>> 

> is Suse mount based on Andries Brouwers' util-linux mount code?
> I'd be surprised if not.  This looks in all sorts of places to
> try and figure out the filesystem type (including procfs & /etc,
> but also by probing).   Its this probing code which mkfs.xfs
> uses in order to try not write on an existing filesystem.

ppc:~ # rpm -qf /bin/mount        
util-2.10m-61
ppc:~ # rpm -qi util-2.10m-61
Name        : util                         Relocations: (not relocateable)
Version     : 2.10m                             Vendor: SuSE GmbH, Nuernberg, Ge
rmany
Release     : 61                            Build Date: Tue Sep 19 03:41:24 2000
Install date: Fri Nov 17 08:54:44 2000      Build Host: papaya.suse.de
Group       : System Environment/Base       Source RPM: util-2.10m-61.src.rpm
Size        : 2497677                          License: GPL/BSD/Sun Microsystems
, Inc.
Packager    : feedback@suse.de
Summary     : Selected utilities
Description :
Selected utilities compiled from Rik Faith's huge utility collection:
agetty arch banner cal clock col colcrt colrm column ctrlaltdel dmesg
fdformat fdisk  flushb frag fsck  hex hexdump ipcrm ipcs kbdrate kill
logger look mesg mkfs.minix mkswap  more mount newgrp passwd pwd rdev
renice reset rev script setfdprm  setserial setsid setterm simpleinit
sln strings swapoff swapon syslogd tsort tunelp ul umount update wall
whereis write

Authors:
--------
    Rik Faith <faith@cs.unc.edu>
    Andries Brouwer <Andries.Brouwer@cwi.nl>
    Eric S. Raymond <esr@snark.thyrsus.com>

SuSE series: a
ppc:~ #

so it looks like Andries Brouwer based

> do you see something like this on powerpc?...
> 10:11 nathans@troppo ~/src/util-linux-2.10q/mount 49> sudo mkfs -t minix /dev/hdb9
> 21856 inodes
> 65535 blocks
> Firstdatazone=696 (696)
> Zonesize=1024
> Maxsize=268966912

> 10:12 nathans@troppo ~/src/util-linux-2.10q/mount 50> sudo od -j 1024 -x -N 32 /dev/hdb9
> 0002000 5560 ffff 0003 0008 02b8 0000 1c00 1008
> 0002020 138f 0001 0000 0000 0000 0000 0000 0000
>         ^^^^
> 0002040
> 10:12 nathans@troppo ~/src/util-linux-2.10q/mount 51> 

> the 0x138f is the minix magic number which the mount "probe"
> code is looking for.

ppc:~ # mkfs -t minix /dev/hda9
21856 inodes
65535 blocks
Firstdatazone=696 (696)
Zonesize=1024
Maxsize=268966912

ppc:~ # od -j 1024 -x -N 32 /dev/hda9
0002000 5560 ffff 0003 0008 02b8 0000 1008 1c00
0002020 138f 0001 0000 0000 0000 0000 0000 0000
0002040
ppc:~ #

so - yes it is there

> hmmm .... i think this is going to be an endian problem in
> mount.  in particular this mount_guess_fstype.c code looks
> suspect:

>     else if (minixmagic(sb.ms) == MINIX_SUPER_MAGIC
>              || minixmagic(sb.ms) == MINIX_SUPER_MAGIC2)
>          type = "minix";

> especially compared to the ext2 code immediately above it
> (this same code is in cmd/xfs/mkfs/mountinfo.c).

so you think this is a problem of the basic mount code which the xfs
utils have taken over too ... if this is the case i may look into
the SuSE mount patches if there are any and check out what they
did to make it work for mount

t

-- 
thomas.graichen@innominate.com
technical director                                       innominate AG
clustering & security                             the linux architects
tel: +49-30-308806-13   fax: -77             http://www.innominate.com

From owner-linux-xfs@oss.sgi.com Tue Nov 28 02:42:09 2000
Received:  by oss.sgi.com id <S553717AbQK1KmA>;
	Tue, 28 Nov 2000 02:42:00 -0800
Received: from hermes.mixx.net ([212.84.196.2]:37639 "HELO hermes.mixx.net")
	by oss.sgi.com with SMTP id <S553712AbQK1Klt>;
	Tue, 28 Nov 2000 02:41:49 -0800
Received: from mate.bln.innominate.de (cerberus.berlin.innominate.de [212.84.234.251])
	by hermes.mixx.net (Postfix) with ESMTP id 8E4E4F82B
	for <linux-xfs@oss.sgi.com>; Tue, 28 Nov 2000 11:41:47 +0100 (CET)
Received: by mate.bln.innominate.de (Postfix, from userid 9)
	id 332002CAA3; Tue, 28 Nov 2000 11:41:47 +0100 (CET)
From:   Thomas Graichen <news-innominate.list.sgi.xfs@innominate.de>
Reply-To: Thomas Graichen <graichen@innominate.de>
X-Newsgroups: innominate.list.sgi.xfs
Subject: Re: TAKE - mountinfo.c
Date:   28 Nov 2000 10:41:47 GMT
Organization: innominate AG, Berlin, Germany
Lines:  36
Distribution: local
Message-ID: <news2mail-90025b$n0b$3@mate.bln.innominate.de>
References: <200011280007.LAA72597@snort.melbourne.sgi.com>
Reply-To: thomas.graichen@innominate.de
X-Trace: mate.bln.innominate.de 975408107 23563 10.0.0.31 (28 Nov 2000 10:41:47 GMT)
X-Complaints-To: news@innominate.de
User-Agent: tin/1.4.4-20000803 ("Vet for the Insane") (UNIX) (Linux/2.4.0-XFS-test10 (i686))
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

Nathan Scott <nathans@snort.melbourne.sgi.com> wrote:
> Thomas, can you see if this fixes the stress/033 failure on ppc?
> -- thanks.

> Modid:  2.4.x-xfs:slinx:78970a
> Date:  Mon Nov 27 16:04:20 PST 2000
> Workarea:  snort:/build4/nathans/linux-xfs
> Author:  nathans

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

> cmd/xfs/mkfs/mountinfo.c - 1.4
> 	- fix auto-detection of minix filesystems on big endian systems.

yes it did - great ... thanks

ppc:/usr/src/xfs/cmd/xfs/mkfs # mkfs -t minix /dev/hda9
21856 inodes
65535 blocks
Firstdatazone=696 (696)
Zonesize=1024
Maxsize=268966912

ppc:/usr/src/xfs/cmd/xfs/mkfs # ./mkfs.xfs /dev/hda9
mkfs.xfs: /dev/hda9 appears to contain an existing filesystem (minix).
mkfs.xfs: Use the -f option to force overwrite
ppc:/usr/src/xfs/cmd/xfs/mkfs #

t

-- 
thomas.graichen@innominate.com
technical director                                       innominate AG
clustering & security                             the linux architects
tel: +49-30-308806-13   fax: -77             http://www.innominate.com

From owner-linux-xfs@oss.sgi.com Tue Nov 28 08:07:06 2000
Received:  by oss.sgi.com id <S553722AbQK1QG4>;
	Tue, 28 Nov 2000 08:06:56 -0800
Received: from hermes.mixx.net ([212.84.196.2]:45828 "HELO hermes.mixx.net")
	by oss.sgi.com with SMTP id <S553675AbQK1QGa>;
	Tue, 28 Nov 2000 08:06:30 -0800
Received: from mate.bln.innominate.de (cerberus.berlin.innominate.de [212.84.234.251])
	by hermes.mixx.net (Postfix) with ESMTP id 2CCB4F819
	for <linux-xfs@oss.sgi.com>; Tue, 28 Nov 2000 17:06:28 +0100 (CET)
Received: by mate.bln.innominate.de (Postfix, from userid 9)
	id 812162CAA3; Tue, 28 Nov 2000 17:06:26 +0100 (CET)
From:   Thomas Graichen <news-innominate.list.sgi.xfs@innominate.de>
Reply-To: Thomas Graichen <graichen@innominate.de>
X-Newsgroups: innominate.list.sgi.xfs
Subject: attr syscall on ppc
Date:   28 Nov 2000 16:06:26 GMT
Organization: innominate AG, Berlin, Germany
Lines:  28
Distribution: local
Message-ID: <news2mail-900l62$6kj$1@mate.bln.innominate.de>
Reply-To: thomas.graichen@innominate.de
X-Trace: mate.bln.innominate.de 975427586 6803 10.0.0.31 (28 Nov 2000 16:06:26 GMT)
X-Complaints-To: news@innominate.de
User-Agent: tin/1.4.4-20000803 ("Vet for the Insane") (UNIX) (Linux/2.4.0-XFS-test10 (i686))
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

i updated my xfs tree now to test11 on ppc and i still have to use
the mixed ppc and xfs tree because the ppc support in the plain
test11 is not useable - i put all together again - got it compiled
and changed the following things in the ppc parts which are taken
from the ppc-devel tree to get it going with XFS

* arch/ppc/kernel/misc.S - add attrctl sysctl as #250 like on
  i386 and now also in this file in the plain test11 in the XFS
  tree
* include/asm-ppc/unistd.h - add __NR__attrctl as 250 too (the
  same as above: like on i386 and now also for ppc in the XFS
  tree)

all the sources are fresh up to date ... and with that kernel i still
get

  Bad address

for the attr calls which looks for me like the kernel does not see
the syscalls - but why? - anyone any idea?

t

-- 
thomas.graichen@innominate.com
technical director                                       innominate AG
clustering & security                             the linux architects
tel: +49-30-308806-13   fax: -77             http://www.innominate.com

From owner-linux-xfs@oss.sgi.com Tue Nov 28 14:42:26 2000
Received:  by oss.sgi.com id <S553711AbQK1WmQ>;
	Tue, 28 Nov 2000 14:42:16 -0800
Received: from deliverator.sgi.com ([204.94.214.10]:7976 "EHLO
        deliverator.sgi.com") by oss.sgi.com with ESMTP id <S553660AbQK1WmA>;
	Tue, 28 Nov 2000 14:42:00 -0800
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 OAA27132
	for <linux-xfs@oss.sgi.com>; Tue, 28 Nov 2000 14:41:59 -0800 (PST)
	mail_from (nathans@wobbly.melbourne.sgi.com)
Received: from wobbly.melbourne.sgi.com (wobbly.melbourne.sgi.com [134.14.55.135]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id JAA07624; Wed, 29 Nov 2000 09:40:42 +1100
Received: (from nathans@localhost) by wobbly.melbourne.sgi.com (980427.SGI.8.8.8/980728.SGI.AUTOCF) id JAA70799; Wed, 29 Nov 2000 09:40:41 +1100 (EDT)
From:   "Nathan Scott" <nathans@wobbly.melbourne.sgi.com>
Message-Id: <10011290940.ZM169800@wobbly.melbourne.sgi.com>
Date:   Wed, 29 Nov 2000 09:40:41 -0400
In-Reply-To: Thomas Graichen <news-innominate.list.sgi.xfs@innominate.de>
        "Re: stress test on ppc" (Nov 28, 10:37am)
References: <news2mail-8uecj0$i5e$1@mate.bln.innominate.de> 
	<10011110006.ZM127189@wobbly.melbourne.sgi.com> 
	<news2mail-8uo7od$4lt$1@mate.bln.innominate.de> 
	<10011141059.ZM128320@wobbly.melbourne.sgi.com> 
	<news2mail-8utlfv$8iu$1@mate.bln.innominate.de> 
	<10011221244.ZM158790@wobbly.melbourne.sgi.com> 
	<news2mail-8vlq0n$hiu$2@mate.bln.innominate.de> 
	<10011261336.ZM166460@wobbly.melbourne.sgi.com> 
	<news2mail-8vt5ub$dhv$3@mate.bln.innominate.de> 
	<10011281048.ZM165042@wobbly.melbourne.sgi.com> 
	<news2mail-9001u3$n0b$2@mate.bln.innominate.de>
X-Mailer: Z-Mail (3.2.3 08feb96 MediaMail)
To:     Thomas Graichen <graichen@innominate.de>,
        thomas.graichen@innominate.de, linux-xfs@oss.sgi.com
Subject: Re: stress test on ppc
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,

On Nov 28, 10:37am, Thomas Graichen wrote:
> Subject: Re: stress test on ppc
> ...
> > so running xfs_db after doing mkfs.xfs with no blksize options
> > (as in test 004 - populate_scratch() routine) should always show
> > the blocksize as 4096.  what i don't understand is how we've ended
> > up with a non-default (but valid) blocksize after doing a default
> > mkfs.
> 
> hm - but mkfs.xfs is using the correct one:
> 
>   ...
>   naming   =version 2              bsize=4096  
>   log      =internal log           bsize=4096   blocks=1200
>   ...
> 

you snipped the interesting bit there - a couple of lines up
from "naming" ("data   =   bsize=????").

> so you assume that either xfs_db gets it wrong or it is stored some-
> how wrong on the filesystem (which i can't really believe due to how
> well xfs works on the ppc :-)?
> 

;-)

i'm not sure where its going wrong - test 004 does a mkfs, mount,
a series of writes, umount, mount, and then runs xfs_db - could
be anywhere in that chain of events that the blksize goes loopy.
(could try running
	"xfs_db -r -c sb -c p $SCRATCH_DEV | grep blocksize"
at each point to see where it goes wrong?)

cheers.

-- 
Nathan

From owner-linux-xfs@oss.sgi.com Tue Nov 28 15:48:57 2000
Received:  by oss.sgi.com id <S553719AbQK1Xsr>;
	Tue, 28 Nov 2000 15:48:47 -0800
Received: from deliverator.sgi.com ([204.94.214.10]:38203 "EHLO
        deliverator.sgi.com") by oss.sgi.com with ESMTP id <S553698AbQK1Xsa>;
	Tue, 28 Nov 2000 15:48:30 -0800
Received: from eric2.austin.sgi.com (root@eric2.austin.sgi.com [169.238.86.147]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id PAA07707
	for <linux-xfs@oss.sgi.com>; Tue, 28 Nov 2000 15:48:30 -0800 (PST)
	mail_from (eric@eric2.austin.sgi.com)
Received: (from eric@localhost)
	by eric2.austin.sgi.com (8.11.0/8.11.0) id eASNo2804033;
	Tue, 28 Nov 2000 17:50:02 -0600
Date:   Tue, 28 Nov 2000 17:50:02 -0600
From:   Eric Sandeen <eric@eric2.austin.sgi.com>
Message-Id: <200011282350.eASNo2804033@eric2.austin.sgi.com>
Subject: TAKE - module load copyright messages
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

Date:  Tue Nov 28 15:46:39 PST 2000
Workarea:  eric2.austin.sgi.com:/home/eric/xfs/workarea-clean

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

Per the discussion in the weekly meeting, added module load copyright
message to the xfs module.  Also made page_buf module copyright message
consistent with xfs module message, and with file headers, i.e.
"Copyright (c) 2000 Silicon Graphics, Inc."

Modid:  2.4.x-xfs:slinx:79097a
linux/fs/xfs/linux/xfs_super.c - 1.102
linux/fs/pagebuf/page_buf.c - 1.43
	- Module load copyright message



From owner-linux-xfs@oss.sgi.com Wed Nov 29 01:22:10 2000
Received:  by oss.sgi.com id <S553679AbQK2JWA>;
	Wed, 29 Nov 2000 01:22:00 -0800
Received: from hermes.mixx.net ([212.84.196.2]:48914 "HELO hermes.mixx.net")
	by oss.sgi.com with SMTP id <S553721AbQK2JVo>;
	Wed, 29 Nov 2000 01:21:44 -0800
Received: from mate.bln.innominate.de (cerberus.berlin.innominate.de [212.84.234.251])
	by hermes.mixx.net (Postfix) with ESMTP id 869D0F838
	for <linux-xfs@oss.sgi.com>; Wed, 29 Nov 2000 10:21:42 +0100 (CET)
Received: by mate.bln.innominate.de (Postfix, from userid 9)
	id 234D12CAA9; Wed, 29 Nov 2000 10:21:42 +0100 (CET)
From:   Thomas Graichen <news-innominate.list.sgi.xfs@innominate.de>
Reply-To: Thomas Graichen <graichen@innominate.de>
X-Newsgroups: innominate.list.sgi.xfs
Subject: Re: stress test on ppc
Date:   29 Nov 2000 09:21:42 GMT
Organization: innominate AG, Berlin, Germany
Lines:  29
Distribution: local
Message-ID: <news2mail-902hr6$307$1@mate.bln.innominate.de>
References: <news2mail-8uecj0$i5e$1@mate.bln.innominate.de>   <10011141059.ZM128320@wobbly.melbourne.sgi.com>   <news2mail-8utlfv$8iu$1@mate.bln.innominate.de>   <10011221244.ZM158790@wobbly.melbourne.sgi.com>   <news2mail-8vlq0n$hiu$2@mate.bln.innominate.de>   <10011261336.ZM166460@wobbly.melbourne.sgi.com>   <news2mail-8vt5ub$dhv$3@mate.bln.innominate.de>   <10011281048.ZM165042@wobbly.melbourne.sgi.com>   <news2mail-9001u3$n0b$2@mate.bln.innominate.de> <10011290940.ZM169800@wobbly.melbourne.sgi.com>
Reply-To: thomas.graichen@innominate.de
X-Trace: mate.bln.innominate.de 975489702 3079 10.0.0.31 (29 Nov 2000 09:21:42 GMT)
X-Complaints-To: news@innominate.de
User-Agent: tin/1.4.4-20000803 ("Vet for the Insane") (UNIX) (Linux/2.4.0-XFS-test10 (i686))
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

"Nathan Scott" <nathans@wobbly.melbourne.sgi.com> wrote:

> i'm not sure where its going wrong - test 004 does a mkfs, mount,
> a series of writes, umount, mount, and then runs xfs_db - could
> be anywhere in that chain of events that the blksize goes loopy.
> (could try running
> 	"xfs_db -r -c sb -c p $SCRATCH_DEV | grep blocksize"
> at each point to see where it goes wrong?)

looks like it happens pretty early

  ppc:/usr/src/xfs/cmd/xfs/mkfs # ./mkfs.xfs -f /dev/hda9
  meta-data=/dev/hda9              isize=256    agcount=8, agsize=49152 blks
  data     =                       bsize=4096   blocks=393216, imaxpct=25
           =                       sunit=0      swidth=0 blks, unwritten=0
  naming   =version 2              bsize=4096  
  log      =internal log           bsize=4096   blocks=1200
  realtime =none                   extsz=65536  blocks=0, rtextents=0
  ppc:/usr/src/xfs/cmd/xfs/mkfs # xfs_db -r -c sb -c p /dev/hda9|grep blocksize
  blocksize = 524288
  ppc:/usr/src/xfs/cmd/xfs/mkfs #

t

-- 
thomas.graichen@innominate.com
technical director                                       innominate AG
clustering & security                             the linux architects
tel: +49-30-308806-13   fax: -77             http://www.innominate.com

From owner-linux-xfs@oss.sgi.com Wed Nov 29 14:18:47 2000
Received:  by oss.sgi.com id <S553706AbQK2WS2>;
	Wed, 29 Nov 2000 14:18:28 -0800
Received: from pneumatic-tube.sgi.com ([204.94.214.22]:44611 "EHLO
        pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP
	id <S553678AbQK2WSK>; Wed, 29 Nov 2000 14:18:10 -0800
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 OAA02629
	for <linux-xfs@oss.sgi.com>; Wed, 29 Nov 2000 14:26:09 -0800 (PST)
	mail_from (nathans@wobbly.melbourne.sgi.com)
Received: from wobbly.melbourne.sgi.com (wobbly.melbourne.sgi.com [134.14.55.135]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id JAA15330; Thu, 30 Nov 2000 09:16:50 +1100
Received: (from nathans@localhost) by wobbly.melbourne.sgi.com (980427.SGI.8.8.8/980728.SGI.AUTOCF) id JAA74873; Thu, 30 Nov 2000 09:16:48 +1100 (EDT)
From:   "Nathan Scott" <nathans@wobbly.melbourne.sgi.com>
Message-Id: <10011300916.ZM156274@wobbly.melbourne.sgi.com>
Date:   Thu, 30 Nov 2000 09:16:46 -0400
In-Reply-To: Thomas Graichen <news-innominate.list.sgi.xfs@innominate.de>
        "Re: alpha again" (Nov 28, 10:25am)
References: <news2mail-8vmd9o$upi$1@mate.bln.innominate.de> 
	<10011261353.ZM165451@wobbly.melbourne.sgi.com> 
	<news2mail-8vt4sn$dhv$2@mate.bln.innominate.de> 
	<10011280910.ZM168487@wobbly.melbourne.sgi.com> 
	<news2mail-90017k$n0b$1@mate.bln.innominate.de>
X-Mailer: Z-Mail (3.2.3 08feb96 MediaMail)
To:     Thomas Graichen <graichen@innominate.de>,
        thomas.graichen@innominate.de
Subject: Re: alpha again
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

hi,

On Nov 28, 10:25am, Thomas Graichen wrote:
> Subject: Re: alpha again
> "Nathan Scott" <nathans@wobbly.melbourne.sgi.com> wrote:
> ...
> > heh - thats completely bogus.  so the problem is in the kernel
> > (xfs mount/umount code paths) after all.
> ...
> > my next best guess at the probable cause is that this may
> > be a blocksize related problem.  we know that the primary
> > superblock is pretty much intact (otherwise xfs_db would have
> > gone haywire) - but since its offset is at start of blk 0,
> > we're always likely to get that right no matter what the page
> > & blksizes are, I think.
> ...
> so looks like the umount code trashes things - this would also make
> clear why xfs survives the dbench 64 - the filesystem seems to be
> stable while operating and only gets trashed on umount ...
> 

ok, i've read through the umount code and have a theory.
(debugging by proxy is fun!)  ;-)

is there any chance that the device block size is being
set back to 1024 at the end of the umount?  i.e. at the
end of linvfs_put_super(), is the set_blocksize() call
being passed 1024?  (throw a printk in there)

if so, is there a chance we are still doing IO at the end
of linvfs_put_super() -(Russell?)- in particular, is there
any chance we could still be writing out the superblock
after we've called set_blocksize() on the device?

i think this would produce the behavior you're seeing here
- if the underlying device blocksize was 1024 and we wrote
out the (512 byte) superblock thinking the blocksize was
512, well we'd end up putting random junk in the AGF since
thats the next 512 bytes right after the superblock.

if the blocksize does prove to be reset to something other
than 512, Thomas, could you try commenting out everything
between "/* Reset device block size */" and the end of the
function (linvfs_put_super) - 3/4 lines - and see if you
still see repair needing to fix the AGF after umount?

>> root@cyan:/usr/src/xfs/linux# xfs_repair /dev/sdb1
>> Phase 1 - find and verify superblock...
>> Phase 2 - using internal log
>>         - zero log...
>>         - scan filesystem freespace and inode maps...
>> bad magic # 0x0 for agf 0
>> bad version # -1 for agf 0
>> bad length 0 for agf 0, should be 4142
>> flfirst -2147483648 in agf 0 too large (max = 128)
>> reset bad agf for ag 0
>> freeblk count 1 != flcount 1084270339 in ag 0
>> bad agbno 2966461184 for btbno root, agno 0
>> bad agbno 16580607 for btbcnt root, agno 0
>>         - found root inode chunk
>> Phase 3 - for each AG...
>>         - scan and clear agi unlinked lists...
>>         - process known inodes and perform inode discovery...
>>         - agno = 0
>>         - agno = 1
>>         - agno = 2
>>         - agno = 3
>> ...


thanks.

-- 
Nathan

From owner-linux-xfs@oss.sgi.com Wed Nov 29 14:45:17 2000
Received:  by oss.sgi.com id <S553747AbQK2Wo6>;
	Wed, 29 Nov 2000 14:44:58 -0800
Received: from barry.mail.mindspring.net ([207.69.200.25]:10005 "EHLO
        barry.mail.mindspring.net") by oss.sgi.com with ESMTP
	id <S553696AbQK2Woa>; Wed, 29 Nov 2000 14:44:30 -0800
Received: from smui04.slb.mindspring.net (smui04.slb.mindspring.net [199.174.114.26])
	by barry.mail.mindspring.net (8.9.3/8.8.5) with ESMTP id RAA08378
	for <linux-xfs@oss.sgi.com>; Wed, 29 Nov 2000 17:44:20 -0500 (EST)
From:   danscox@mindspring.com
Received: by smui04.slb.mindspring.net id RAA0000017832; Wed, 29 Nov 2000 17:44:20 -0500 (EST)
Date:   Wed, 29 Nov 2000 17:44:19 -0500
To:     linux-xfs@oss.sgi.com
Subject: Patch for XFS on LVM and MD (RAID)
Message-ID: <Springmail.105.975537859.0.92840700@www.springmail.com>
X-Originating-IP: 216.100.236.99
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="WBE975537859c14f5cc15dd94a2bc1e1762fa0f0ec76";
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.

--WBE975537859c14f5cc15dd94a2bc1e1762fa0f0ec76
Content-Type: text/plain
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

All,

	I had to make a tiny (but oh-so-important!) change to page_buf.c to make XFS work atop of LVM or RAID.

	Enjoy!

Danny Cox

--WBE975537859c14f5cc15dd94a2bc1e1762fa0f0ec76
Content-Type: application/octet-stream; name="xfs-lvm.patch"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="xfs-lvm.patch"

LS0tIGxpbnV4L2ZzL3BhZ2VidWYvcGFnZV9idWYuYy5vcmlnCVdlZCBOb3YgMjkgMTc6NDU6NTYgMj
AwMAorKysgbGludXgvZnMvcGFnZWJ1Zi9wYWdlX2J1Zi5jCVR1ZSBOb3YgMjggMTk6MDQ6NTYgMjAw
MApAQCAtMTM0Nyw3ICsxMzQ3LDcgQEAKIAlzaXplX3QgYmxrX2xlbmd0aDsKIAlpbnQgZXJyPTA7Ci
AJaW50IGZvcmNlX2lvID0gKHJ3ICE9IFJFQUQpIHx8IChwYi0+cGJfZmxhZ3MgJiBQQkZfRk9SQ0VJ
Tyk7Ci0JaW50IGNvbmNhdF9vayA9ICgoTUFKT1IoZGV2KSAhPSBMVk1fQkxLX01BSk9SKSB8fCAoTU
FKT1IoZGV2KSAhPSBNRF9NQUpPUikpOworCWludCBjb25jYXRfb2sgPSAoKE1BSk9SKGRldikgIT0g
TFZNX0JMS19NQUpPUikgJiYgKE1BSk9SKGRldikgIT0gTURfTUFKT1IpKTsKIAogCS8qIENhbGN1bG
F0ZSB0aGUgYmxvY2sgb2Zmc2V0cyBhbmQgbGVuZ3RoIHdlIHdpbGwgYmUgdXNpbmcgKi8KIAlpZiAo
cGdfb2Zmc2V0KSB7Cg==
--WBE975537859c14f5cc15dd94a2bc1e1762fa0f0ec76--

From owner-linux-xfs@oss.sgi.com Wed Nov 29 15:16:38 2000
Received:  by oss.sgi.com id <S553767AbQK2XQ1>;
	Wed, 29 Nov 2000 15:16:27 -0800
Received: from deliverator.sgi.com ([204.94.214.10]:34097 "EHLO
        deliverator.sgi.com") by oss.sgi.com with ESMTP id <S553734AbQK2XP6>;
	Wed, 29 Nov 2000 15:15:58 -0800
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 PAA13858
	for <linux-xfs@oss.sgi.com>; Wed, 29 Nov 2000 15:15:58 -0800 (PST)
	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 PAA41133; Wed, 29 Nov 2000 15:10:31 -0800 (PST)
Message-ID: <3A258D9A.3BBCC768@sgi.com>
Date:   Wed, 29 Nov 2000 15:13:30 -0800
From:   Rajagopal Ananthanarayanan <ananth@sgi.com>
X-Mailer: Mozilla 4.72 [en] (X11; U; Linux 2.2.16-4SGI_20smp i686)
X-Accept-Language: en
MIME-Version: 1.0
To:     danscox@mindspring.com
CC:     linux-xfs@oss.sgi.com
Subject: Re: Patch for XFS on LVM and MD (RAID)
References: <Springmail.105.975537859.0.92840700@www.springmail.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

danscox@mindspring.com wrote:
> 
> All,
> 
>         I had to make a tiny (but oh-so-important!) change to page_buf.c to make XFS work atop of LVM or RAID.
> 

Yes, that looks like a bug.
Can you please give more details about
your experience with LVM & RAID (MD)?
We are trying to setup a machine with
MD (RAID1/5) but have been seeing problems
in the XOR code in test11 ...

thanks!

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

From owner-linux-xfs@oss.sgi.com Wed Nov 29 15:36:08 2000
Received:  by oss.sgi.com id <S553772AbQK2Xf6>;
	Wed, 29 Nov 2000 15:35:58 -0800
Received: from deliverator.sgi.com ([204.94.214.10]:6456 "EHLO
        deliverator.sgi.com") by oss.sgi.com with ESMTP id <S553765AbQK2Xff>;
	Wed, 29 Nov 2000 15:35:35 -0800
Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id PAA17209
	for <linux-xfs@oss.sgi.com>; Wed, 29 Nov 2000 15:35:34 -0800 (PST)
	mail_from (cattelan@thebarn.com)
Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id RAA7029931; Wed, 29 Nov 2000 17:34:13 -0600 (CST)
Received: from gibble.americas.sgi.com (gibble.americas.sgi.com [128.162.195.80]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id RAA64830; Wed, 29 Nov 2000 17:34:13 -0600 (CST)
Received: from thebarn.com (localhost [127.0.0.1])
	by gibble.americas.sgi.com (8.11.0/8.10.1) with ESMTP id eATNYDj11901;
	Wed, 29 Nov 2000 17:34:13 -0600
Message-ID: <3A259273.D6353426@thebarn.com>
Date:   Wed, 29 Nov 2000 17:34:12 -0600
From:   Russell Cattelan <cattelan@thebarn.com>
X-Mailer: Mozilla 4.75 [en] (X11; U; Linux 2.4.0-whipme11 i686)
X-Accept-Language: en
MIME-Version: 1.0
To:     Nathan Scott <nathans@wobbly.melbourne.sgi.com>
CC:     Thomas Graichen <graichen@innominate.de>,
        thomas.graichen@innominate.de, linux-xfs@oss.sgi.com
Subject: Re: alpha again
References: <news2mail-8vmd9o$upi$1@mate.bln.innominate.de> 
		<10011261353.ZM165451@wobbly.melbourne.sgi.com> 
		<news2mail-8vt4sn$dhv$2@mate.bln.innominate.de> 
		<10011280910.ZM168487@wobbly.melbourne.sgi.com> 
		<news2mail-90017k$n0b$1@mate.bln.innominate.de> <10011300916.ZM156274@wobbly.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

Nathan Scott wrote:

> hi,
>
> On Nov 28, 10:25am, Thomas Graichen wrote:
> > Subject: Re: alpha again
> > "Nathan Scott" <nathans@wobbly.melbourne.sgi.com> wrote:
> > ...
> > > heh - thats completely bogus.  so the problem is in the kernel
> > > (xfs mount/umount code paths) after all.
> > ...
> > > my next best guess at the probable cause is that this may
> > > be a blocksize related problem.  we know that the primary
> > > superblock is pretty much intact (otherwise xfs_db would have
> > > gone haywire) - but since its offset is at start of blk 0,
> > > we're always likely to get that right no matter what the page
> > > & blksizes are, I think.
> > ...
> > so looks like the umount code trashes things - this would also make
> > clear why xfs survives the dbench 64 - the filesystem seems to be
> > stable while operating and only gets trashed on umount ...
> >
>
> ok, i've read through the umount code and have a theory.
> (debugging by proxy is fun!)  ;-)
>
> is there any chance that the device block size is being
> set back to 1024 at the end of the umount?  i.e. at the
> end of linvfs_put_super(), is the set_blocksize() call
> being passed 1024?  (throw a printk in there)
>
> if so, is there a chance we are still doing IO at the end
> of linvfs_put_super() -(Russell?)- in particular, is there
> any chance we could still be writing out the superblock
> after we've called set_blocksize() on the device?

Hmm I doubt it, linvfs_put_super through a series of vfs calls
fs_dounmount -> xfs_unmount calls XFS_bdflush, aka pagebuf_delwri_flush
which should force out any pending meta data buffers.
A few SYNCs have been through in along the way which should  clean
up and io hooked to inodes. Of course all the inodes need to be gone
for the file system can be unbusy enough to unmount in the first place.

>
>
> i think this would produce the behavior you're seeing here
> - if the underlying device blocksize was 1024 and we wrote
> out the (512 byte) superblock thinking the blocksize was
> 512, well we'd end up putting random junk in the AGF since
> thats the next 512 bytes right after the superblock.
>
> if the blocksize does prove to be reset to something other
> than 512, Thomas, could you try commenting out everything
> between "/* Reset device block size */" and the end of the
> function (linvfs_put_super) - 3/4 lines - and see if you
> still see repair needing to fix the AGF after umount?

It is entirely possible the ag is getting trashed the first time the
super block is written out.  The file system will run just
fine since most of the ag info is keep in memory and not
re-read from disk.
I suspect the partially valid page stuff is at fault.

Try this mount a fresh file system.
create a small file.
run xfs_db -r <device>
agf 0
from man page:
The AGF block is the header for block allocation
                 information; it is in the second 512-byte  block
                 of  each allocation group.  The following fields
                 are defined:
                 magicnum: AGF  block  magic  number,  0x58414746
                 ('XAGF')


If the magic number is wrong then we have trashed the block right off
the bat.

Note in thinking about this you may want to wait 5 seconds or so to make
sure
the updates to the super block are written out.

>
>
> >> root@cyan:/usr/src/xfs/linux# xfs_repair /dev/sdb1
> >> Phase 1 - find and verify superblock...
> >> Phase 2 - using internal log
> >>         - zero log...
> >>         - scan filesystem freespace and inode maps...
> >> bad magic # 0x0 for agf 0
> >> bad version # -1 for agf 0
> >> bad length 0 for agf 0, should be 4142
> >> flfirst -2147483648 in agf 0 too large (max = 128)
> >> reset bad agf for ag 0
> >> freeblk count 1 != flcount 1084270339 in ag 0
> >> bad agbno 2966461184 for btbno root, agno 0
> >> bad agbno 16580607 for btbcnt root, agno 0
> >>         - found root inode chunk
> >> Phase 3 - for each AG...
> >>         - scan and clear agi unlinked lists...
> >>         - process known inodes and perform inode discovery...
> >>         - agno = 0
> >>         - agno = 1
> >>         - agno = 2
> >>         - agno = 3
> >> ...
>
> thanks.
>
> --
> Nathan


From owner-linux-xfs@oss.sgi.com Wed Nov 29 15:43:48 2000
Received:  by oss.sgi.com id <S553783AbQK2Xni>;
	Wed, 29 Nov 2000 15:43:38 -0800
Received: from deliverator.sgi.com ([204.94.214.10]:33850 "EHLO
        deliverator.sgi.com") by oss.sgi.com with ESMTP id <S553768AbQK2XnY>;
	Wed, 29 Nov 2000 15:43:24 -0800
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 PAA18435
	for <linux-xfs@oss.sgi.com>; Wed, 29 Nov 2000 15:43:22 -0800 (PST)
	mail_from (nathans@wobbly.melbourne.sgi.com)
Received: from wobbly.melbourne.sgi.com (wobbly.melbourne.sgi.com [134.14.55.135]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id KAA16052; Thu, 30 Nov 2000 10:40:51 +1100
Received: (from nathans@localhost) by wobbly.melbourne.sgi.com (980427.SGI.8.8.8/980728.SGI.AUTOCF) id KAA64954; Thu, 30 Nov 2000 10:40:50 +1100 (EDT)
From:   "Nathan Scott" <nathans@wobbly.melbourne.sgi.com>
Message-Id: <10011301040.ZM164128@wobbly.melbourne.sgi.com>
Date:   Thu, 30 Nov 2000 10:40:48 -0400
In-Reply-To: Thomas Graichen <news-innominate.list.sgi.xfs@innominate.de>
        "Re: stress test on ppc" (Nov 29,  9:21am)
References: <news2mail-8uecj0$i5e$1@mate.bln.innominate.de> 
	<10011141059.ZM128320@wobbly.melbourne.sgi.com> 
	<news2mail-8utlfv$8iu$1@mate.bln.innominate.de> 
	<10011221244.ZM158790@wobbly.melbourne.sgi.com> 
	<news2mail-8vlq0n$hiu$2@mate.bln.innominate.de> 
	<10011261336.ZM166460@wobbly.melbourne.sgi.com> 
	<news2mail-8vt5ub$dhv$3@mate.bln.innominate.de> 
	<10011281048.ZM165042@wobbly.melbourne.sgi.com> 
	<news2mail-9001u3$n0b$2@mate.bln.innominate.de> 
	<10011290940.ZM169800@wobbly.melbourne.sgi.com> 
	<news2mail-902hr6$307$1@mate.bln.innominate.de>
X-Mailer: Z-Mail (3.2.3 08feb96 MediaMail)
To:     Thomas Graichen <graichen@innominate.de>,
        thomas.graichen@innominate.de, linux-xfs@oss.sgi.com
Subject: Re: stress test on ppc
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 Thomas,

On Nov 29,  9:21am, Thomas Graichen wrote:
> Subject: Re: stress test on ppc
> "Nathan Scott" <nathans@wobbly.melbourne.sgi.com> wrote:
> 
> ...looks like it happens pretty early
> 
>   ppc:/usr/src/xfs/cmd/xfs/mkfs # ./mkfs.xfs -f /dev/hda9
>   meta-data=/dev/hda9              isize=256    agcount=8, agsize=49152 blks
>   data     =                       bsize=4096   blocks=393216, imaxpct=25
>            =                       sunit=0      swidth=0 blks, unwritten=0
>   naming   =version 2              bsize=4096  
>   log      =internal log           bsize=4096   blocks=1200
>   realtime =none                   extsz=65536  blocks=0, rtextents=0
>   ppc:/usr/src/xfs/cmd/xfs/mkfs # xfs_db -r -c sb -c p /dev/hda9|grep blocksize
>   blocksize = 524288
>   ppc:/usr/src/xfs/cmd/xfs/mkfs #
> 

ok, so the problem is in either mkfs or xfs_db.  after mkfs, run:

# od -c -N 8 /dev/hda9
0000000   X   F   S   B  \0  \0 020  \0
0000012

you should see exactly that (the second 4 are the blocksize).
if you do, its an xfs_db problem.  if not, its a mkfs problem.
lemme know.  (at the same time, could you send the unfiltered
"xfs_db -r -c sb -c p /dev/hda9" output also?)

thanks.

-- 
Nathan

From owner-linux-xfs@oss.sgi.com Wed Nov 29 23:43:44 2000
Received:  by oss.sgi.com id <S553788AbQK3HnZ>;
	Wed, 29 Nov 2000 23:43:25 -0800
Received: from edge.coltex.nl ([194.151.97.115]:38929 "EHLO mail.coltex.nl")
	by oss.sgi.com with ESMTP id <S553785AbQK3HnF>;
	Wed, 29 Nov 2000 23:43:05 -0800
Received: from auto-nb1.xs4all.nl (auto-nb1.coltex.nl [10.0.1.171])
	by mail.coltex.nl (8.10.0/8.9.3) with ESMTP id eAU7giu22074;
	Thu, 30 Nov 2000 08:42:45 +0100
Message-Id: <4.3.2.7.2.20001130083923.030cfd00@pop.xs4all.nl>
X-Sender: knuffie@pop.xs4all.nl (Unverified)
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
Date:   Thu, 30 Nov 2000 08:40:36 +0100
To:     Rajagopal Ananthanarayanan <ananth@sgi.com>
From:   Seth Mos <knuffie@xs4all.nl>
Subject: Re: Patch for XFS on LVM and MD (RAID)
Cc:     linux-xfs@oss.sgi.com
In-Reply-To: <3A258D9A.3BBCC768@sgi.com>
References: <Springmail.105.975537859.0.92840700@www.springmail.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing

At 15:13 29-11-2000 -0800, you wrote:
>danscox@mindspring.com wrote:
> >
> > All,
> >
> >         I had to make a tiny (but oh-so-important!) change to 
> page_buf.c to make XFS work atop of LVM or RAID.
> >
>
>Yes, that looks like a bug.
>Can you please give more details about
>your experience with LVM & RAID (MD)?
>We are trying to setup a machine with
>MD (RAID1/5) but have been seeing problems
>in the XOR code in test11 ...

test11-ac3 fixed that.

One of alan's patches fixed it

--
Seth
Has anybody seen my lightbulb?
I _really_ need some light here.


From owner-linux-xfs@oss.sgi.com Thu Nov 30 00:54:45 2000
Received:  by oss.sgi.com id <S553801AbQK3Iy0>;
	Thu, 30 Nov 2000 00:54:26 -0800
Received: from hermes.mixx.net ([212.84.196.2]:5648 "HELO hermes.mixx.net")
	by oss.sgi.com with SMTP id <S553794AbQK3IyD>;
	Thu, 30 Nov 2000 00:54:03 -0800
Received: from mate.bln.innominate.de (cerberus.berlin.innominate.de [212.84.234.251])
	by hermes.mixx.net (Postfix) with ESMTP id 45CE0F804
	for <linux-xfs@oss.sgi.com>; Thu, 30 Nov 2000 09:54:01 +0100 (CET)
Received: by mate.bln.innominate.de (Postfix, from userid 9)
	id E02322CAA2; Thu, 30 Nov 2000 09:54:00 +0100 (CET)
From:   Thomas Graichen <news-innominate.list.sgi.xfs@innominate.de>
Reply-To: Thomas Graichen <graichen@innominate.de>
X-Newsgroups: innominate.list.sgi.xfs
Subject: Re: alpha again
Date:   30 Nov 2000 08:54:00 GMT
Organization: innominate AG, Berlin, Germany
Lines:  78
Distribution: local
Message-ID: <news2mail-9054j8$3u0$1@mate.bln.innominate.de>
References: <news2mail-8vmd9o$upi$1@mate.bln.innominate.de>    <10011261353.ZM165451@wobbly.melbourne.sgi.com>    <news2mail-8vt4sn$dhv$2@mate.bln.innominate.de>    <10011280910.ZM168487@wobbly.melbourne.sgi.com>    <news2mail-90017k$n0b$1@mate.bln.innominate.de> <10011300916.ZM156274@wobbly.melbourne.sgi.com> <3A259273.D6353426@thebarn.com>
Reply-To: thomas.graichen@innominate.de
X-Trace: mate.bln.innominate.de 975574440 4032 10.0.0.31 (30 Nov 2000 08:54:00 GMT)
X-Complaints-To: news@innominate.de
User-Agent: tin/1.4.4-20000803 ("Vet for the Insane") (UNIX) (Linux/2.4.0-XFS-test10 (i686))
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

Russell Cattelan <cattelan@thebarn.com> wrote:
>>
>> i think this would produce the behavior you're seeing here
>> - if the underlying device blocksize was 1024 and we wrote
>> out the (512 byte) superblock thinking the blocksize was
>> 512, well we'd end up putting random junk in the AGF since
>> thats the next 512 bytes right after the superblock.
>>
>> if the blocksize does prove to be reset to something other
>> than 512, Thomas, could you try commenting out everything
>> between "/* Reset device block size */" and the end of the
>> function (linvfs_put_super) - 3/4 lines - and see if you
>> still see repair needing to fix the AGF after umount?

> It is entirely possible the ag is getting trashed the first time the
> super block is written out.  The file system will run just
> fine since most of the ag info is keep in memory and not
> re-read from disk.
> I suspect the partially valid page stuff is at fault.

> Try this mount a fresh file system.
> create a small file.
> run xfs_db -r <device>
> agf 0
> from man page:
> The AGF block is the header for block allocation
>                  information; it is in the second 512-byte  block
>                  of  each allocation group.  The following fields
>                  are defined:
>                  magicnum: AGF  block  magic  number,  0x58414746
>                  ('XAGF')


> If the magic number is wrong then we have trashed the block right off
> the bat.

root@cyan:~# mkfs -t xfs -f -b size=8192 /dev/sdb1
meta-data=/dev/sdb1              isize=256    agcount=8, agsize=4142 blks
data     =                       bsize=8192   blocks=33130, imaxpct=25
         =                       sunit=0      swidth=0 blks, unwritten=0
naming   =version 2              bsize=8192  
log      =internal log           bsize=8192   blocks=1000
realtime =none                   extsz=65536  blocks=0, rtextents=0
root@cyan:~# mount /dev/sdb1 /mnt                                 
root@cyan:~# xfs_db -r /dev/sdb1
xfs_db: quit
root@cyan:~# echo test > /mnt/testfile
root@cyan:~# cat /mnt/testfile
test
root@cyan:~# xfs_db -r /dev/sdb1
xfs_db: agf 0
xfs_db: print
magicnum = 0
versionnum = 4294967295
seqno = 0
length = 0
bnoroot = 2966461184
cntroot = 16580607
bnolevel = 16580607
cntlevel = 0
flfirst = 2147483648
fllast = 16777216
flcount = 97794
freeblks = 16580607
longest = 32258
xfs_db:

so looks like you are right - i also double checked it - on the ppc for
instance the magicnum is 0x58414746 and also on the alpha in agf 1 -
any ideas where this might come from?

t

-- 
thomas.graichen@innominate.com
technical director                                       innominate AG
clustering & security                             the linux architects
tel: +49-30-308806-13   fax: -77             http://www.innominate.com

From owner-linux-xfs@oss.sgi.com Thu Nov 30 00:57:04 2000
Received:  by oss.sgi.com id <S553803AbQK3I4p>;
	Thu, 30 Nov 2000 00:56:45 -0800
Received: from hermes.mixx.net ([212.84.196.2]:11280 "HELO hermes.mixx.net")
	by oss.sgi.com with SMTP id <S553798AbQK3I4d>;
	Thu, 30 Nov 2000 00:56:33 -0800
Received: from mate.bln.innominate.de (cerberus.berlin.innominate.de [212.84.234.251])
	by hermes.mixx.net (Postfix) with ESMTP id 32C63F809
	for <linux-xfs@oss.sgi.com>; Thu, 30 Nov 2000 09:56:32 +0100 (CET)
Received: by mate.bln.innominate.de (Postfix, from userid 9)
	id DD53F2CAA2; Thu, 30 Nov 2000 09:56:31 +0100 (CET)
From:   Thomas Graichen <news-innominate.list.sgi.xfs@innominate.de>
Reply-To: Thomas Graichen <graichen@innominate.de>
X-Newsgroups: innominate.list.sgi.xfs
Subject: Re: alpha again
Date:   30 Nov 2000 08:56:31 GMT
Organization: innominate AG, Berlin, Germany
Lines:  62
Distribution: local
Message-ID: <news2mail-9054nv$3u0$2@mate.bln.innominate.de>
References: <news2mail-8vmd9o$upi$1@mate.bln.innominate.de>   <10011261353.ZM165451@wobbly.melbourne.sgi.com>   <news2mail-8vt4sn$dhv$2@mate.bln.innominate.de>   <10011280910.ZM168487@wobbly.melbourne.sgi.com>   <news2mail-90017k$n0b$1@mate.bln.innominate.de> <10011300916.ZM156274@wobbly.melbourne.sgi.com>
Reply-To: thomas.graichen@innominate.de
X-Trace: mate.bln.innominate.de 975574591 4032 10.0.0.31 (30 Nov 2000 08:56:31 GMT)
X-Complaints-To: news@innominate.de
User-Agent: tin/1.4.4-20000803 ("Vet for the Insane") (UNIX) (Linux/2.4.0-XFS-test10 (i686))
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

"Nathan Scott" <nathans@wobbly.melbourne.sgi.com> wrote:
> hi,

> On Nov 28, 10:25am, Thomas Graichen wrote:
>> Subject: Re: alpha again
>> "Nathan Scott" <nathans@wobbly.melbourne.sgi.com> wrote:
>> ...
>> > heh - thats completely bogus.  so the problem is in the kernel
>> > (xfs mount/umount code paths) after all.
>> ...
>> > my next best guess at the probable cause is that this may
>> > be a blocksize related problem.  we know that the primary
>> > superblock is pretty much intact (otherwise xfs_db would have
>> > gone haywire) - but since its offset is at start of blk 0,
>> > we're always likely to get that right no matter what the page
>> > & blksizes are, I think.
>> ...
>> so looks like the umount code trashes things - this would also make
>> clear why xfs survives the dbench 64 - the filesystem seems to be
>> stable while operating and only gets trashed on umount ...
>> 

> ok, i've read through the umount code and have a theory.
> (debugging by proxy is fun!)  ;-)

> is there any chance that the device block size is being
> set back to 1024 at the end of the umount?  i.e. at the
> end of linvfs_put_super(), is the set_blocksize() call
> being passed 1024?  (throw a printk in there)

> if so, is there a chance we are still doing IO at the end
> of linvfs_put_super() -(Russell?)- in particular, is there
> any chance we could still be writing out the superblock
> after we've called set_blocksize() on the device?

> i think this would produce the behavior you're seeing here
> - if the underlying device blocksize was 1024 and we wrote
> out the (512 byte) superblock thinking the blocksize was
> 512, well we'd end up putting random junk in the AGF since
> thats the next 512 bytes right after the superblock.

> if the blocksize does prove to be reset to something other
> than 512, Thomas, could you try commenting out everything
> between "/* Reset device block size */" and the end of the
> function (linvfs_put_super) - 3/4 lines - and see if you
> still see repair needing to fix the AGF after umount?

i will wait with this - because due to russels post it seems to
happen earlier and not really on umount

just for my understanding: it will only be seen on umount
because the trashed blocks will only then be written to disk
and we are looking at the on disk layout with xfs_db only
- right?

t

-- 
thomas.graichen@innominate.com
technical director                                       innominate AG
clustering & security                             the linux architects
tel: +49-30-308806-13   fax: -77             http://www.innominate.com

From owner-linux-xfs@oss.sgi.com Thu Nov 30 01:01:44 2000
Received:  by oss.sgi.com id <S553818AbQK3JBf>;
	Thu, 30 Nov 2000 01:01:35 -0800
Received: from hermes.mixx.net ([212.84.196.2]:28944 "HELO hermes.mixx.net")
	by oss.sgi.com with SMTP id <S553805AbQK3JBO>;
	Thu, 30 Nov 2000 01:01:14 -0800
Received: from mate.bln.innominate.de (cerberus.berlin.innominate.de [212.84.234.251])
	by hermes.mixx.net (Postfix) with ESMTP id 5FA73F804
	for <linux-xfs@oss.sgi.com>; Thu, 30 Nov 2000 10:01:12 +0100 (CET)
Received: by mate.bln.innominate.de (Postfix, from userid 9)
	id 2F6372CAA2; Thu, 30 Nov 2000 10:01:12 +0100 (CET)
From:   Thomas Graichen <news-innominate.list.sgi.xfs@innominate.de>
Reply-To: Thomas Graichen <graichen@innominate.de>
X-Newsgroups: innominate.list.sgi.xfs
Subject: Re: stress test on ppc
Date:   30 Nov 2000 09:01:12 GMT
Organization: innominate AG, Berlin, Germany
Lines:  93
Distribution: local
Message-ID: <news2mail-90550o$3u0$3@mate.bln.innominate.de>
References: <news2mail-8uecj0$i5e$1@mate.bln.innominate.de>   <10011221244.ZM158790@wobbly.melbourne.sgi.com>   <news2mail-8vlq0n$hiu$2@mate.bln.innominate.de>   <10011261336.ZM166460@wobbly.melbourne.sgi.com>   <news2mail-8vt5ub$dhv$3@mate.bln.innominate.de>   <10011281048.ZM165042@wobbly.melbourne.sgi.com>   <news2mail-9001u3$n0b$2@mate.bln.innominate.de>   <10011290940.ZM169800@wobbly.melbourne.sgi.com>   <news2mail-902hr6$307$1@mate.bln.innominate.de> <10011301040.ZM164128@wobbly.melbourne.sgi.com>
Reply-To: thomas.graichen@innominate.de
X-Trace: mate.bln.innominate.de 975574872 4032 10.0.0.31 (30 Nov 2000 09:01:12 GMT)
X-Complaints-To: news@innominate.de
User-Agent: tin/1.4.4-20000803 ("Vet for the Insane") (UNIX) (Linux/2.4.0-XFS-test10 (i686))
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

"Nathan Scott" <nathans@wobbly.melbourne.sgi.com> wrote:
> hi Thomas,

> On Nov 29,  9:21am, Thomas Graichen wrote:
>> Subject: Re: stress test on ppc
>> "Nathan Scott" <nathans@wobbly.melbourne.sgi.com> wrote:
>> 
>> ...looks like it happens pretty early
>> 
>>   ppc:/usr/src/xfs/cmd/xfs/mkfs # ./mkfs.xfs -f /dev/hda9
>>   meta-data=/dev/hda9              isize=256    agcount=8, agsize=49152 blks
>>   data     =                       bsize=4096   blocks=393216, imaxpct=25
>>            =                       sunit=0      swidth=0 blks, unwritten=0
>>   naming   =version 2              bsize=4096  
>>   log      =internal log           bsize=4096   blocks=1200
>>   realtime =none                   extsz=65536  blocks=0, rtextents=0
>>   ppc:/usr/src/xfs/cmd/xfs/mkfs # xfs_db -r -c sb -c p /dev/hda9|grep blocksize
>>   blocksize = 524288
>>   ppc:/usr/src/xfs/cmd/xfs/mkfs #
>> 

> ok, so the problem is in either mkfs or xfs_db.  after mkfs, run:

> # od -c -N 8 /dev/hda9
> 0000000   X   F   S   B  \0  \0 020  \0
> 0000012

> you should see exactly that (the second 4 are the blocksize).
> if you do, its an xfs_db problem.  if not, its a mkfs problem.

ppc:~ # od -c -N 8 /dev/hda9
0000000   X   F   S   B  \0  \0 020  \0
0000010
ppc:~ #

so it looks like xfs_db

> lemme know.  (at the same time, could you send the unfiltered
> "xfs_db -r -c sb -c p /dev/hda9" output also?)

no problem

ppc:~ # xfs_db -r -c sb -c p /dev/hda9
magicnum = 0x58465342
blocksize = 524288
dblocks = 105553116266496
rblocks = 0
rextents = 0
uuid = bc3a44f0-947a-4ebe-964e-5d237161432b
logstart = 262148
rootino = 72057594037927936
rbmino = 129
rsumino = 4683743612465315840
rextsize = 16
agblocks = 196608
agcount = 8
rbmblocks = 0
logblocks = 1200
versionnum = 0x2084
sectsize = 64
inodesize = 256
inopblock = 2048
fname = "\000\000\000\000\000\000\000\000\000\000\000\000"
blocklog = 12
sectlog = 144
inodelog = 8
inopblog = 32
agblklog = 16
rextslog = 0
inprogress = 0
imax_pct = 152
icount = 64
ifree = 13546827679130451968
fdblocks = 391980
frextents = 0
uquotino = 0
pquotino = 0
qflags = 0
flags = 0
shared_vn = 0
inoalignmt = 1073741824
unit = 0
width = 0
dirblklog = 0
ppc:~ #

t

-- 
thomas.graichen@innominate.com
technical director                                       innominate AG
clustering & security                             the linux architects
tel: +49-30-308806-13   fax: -77             http://www.innominate.com

From owner-linux-xfs@oss.sgi.com Thu Nov 30 01:34:05 2000
Received:  by oss.sgi.com id <S553821AbQK3Jdp>;
	Thu, 30 Nov 2000 01:33:45 -0800
Received: from pneumatic-tube.sgi.com ([204.94.214.22]:61194 "EHLO
        pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP
	id <S553815AbQK3JdT>; Thu, 30 Nov 2000 01:33:19 -0800
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 BAA02691
	for <linux-xfs@oss.sgi.com>; Thu, 30 Nov 2000 01:41:20 -0800 (PST)
	mail_from (nathans@wobbly.melbourne.sgi.com)
Received: from wobbly.melbourne.sgi.com (wobbly.melbourne.sgi.com [134.14.55.135]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id UAA19024; Thu, 30 Nov 2000 20:32:01 +1100
Received: (from nathans@localhost) by wobbly.melbourne.sgi.com (980427.SGI.8.8.8/980728.SGI.AUTOCF) id UAA75518; Thu, 30 Nov 2000 20:32:00 +1100 (EDT)
From:   "Nathan Scott" <nathans@wobbly.melbourne.sgi.com>
Message-Id: <10011302031.ZM174105@wobbly.melbourne.sgi.com>
Date:   Thu, 30 Nov 2000 20:31:59 -0400
In-Reply-To: Thomas Graichen <news-innominate.list.sgi.xfs@innominate.de>
        "Re: alpha again" (Nov 30,  8:56am)
References: <news2mail-8vmd9o$upi$1@mate.bln.innominate.de> 
	<10011261353.ZM165451@wobbly.melbourne.sgi.com> 
	<news2mail-8vt4sn$dhv$2@mate.bln.innominate.de> 
	<10011280910.ZM168487@wobbly.melbourne.sgi.com> 
	<news2mail-90017k$n0b$1@mate.bln.innominate.de> 
	<10011300916.ZM156274@wobbly.melbourne.sgi.com> 
	<news2mail-9054nv$3u0$2@mate.bln.innominate.de>
X-Mailer: Z-Mail (3.2.3 08feb96 MediaMail)
To:     Thomas Graichen <graichen@innominate.de>,
        thomas.graichen@innominate.de, linux-xfs@oss.sgi.com
Subject: Re: alpha again
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 Nov 30,  8:56am, Thomas Graichen wrote:
> Subject: Re: alpha again
> ...
> i will wait with this - because due to russels post it seems to
> happen earlier and not really on umount

yup, that blew my theory out of the water.

> 
> just for my understanding: it will only be seen on umount
> because the trashed blocks will only then be written to disk
> and we are looking at the on disk layout with xfs_db only
> - right?
> 

Russells point was it isn't only seen on unmount though - thats
just when we happened to look previously - and we weren't doing
anything inbetween mount & umount which might force the agf out
earlier (we are now though).  yes, xfs_db only looks ondisk.

cheers.

-- 
Nathan

From owner-linux-xfs@oss.sgi.com Thu Nov 30 02:04:35 2000
Received:  by oss.sgi.com id <S553831AbQK3KEZ>;
	Thu, 30 Nov 2000 02:04:25 -0800
Received: from hermes.mixx.net ([212.84.196.2]:45074 "HELO hermes.mixx.net")
	by oss.sgi.com with SMTP id <S553819AbQK3KEL>;
	Thu, 30 Nov 2000 02:04:11 -0800
Received: from mate.bln.innominate.de (cerberus.berlin.innominate.de [212.84.234.251])
	by hermes.mixx.net (Postfix) with ESMTP id 513B7F804
	for <linux-xfs@oss.sgi.com>; Thu, 30 Nov 2000 11:04:10 +0100 (CET)
Received: by mate.bln.innominate.de (Postfix, from userid 9)
	id 7B0D12CAA2; Thu, 30 Nov 2000 11:04:06 +0100 (CET)
From:   Thomas Graichen <news-innominate.list.sgi.xfs@innominate.de>
Reply-To: Thomas Graichen <graichen@innominate.de>
X-Newsgroups: innominate.list.sgi.xfs
Subject: Re: alpha again
Date:   30 Nov 2000 10:04:06 GMT
Organization: innominate AG, Berlin, Germany
Lines:  31
Distribution: local
Message-ID: <news2mail-9058mm$3u0$4@mate.bln.innominate.de>
References: <news2mail-8vmd9o$upi$1@mate.bln.innominate.de>   <10011261353.ZM165451@wobbly.melbourne.sgi.com>   <news2mail-8vt4sn$dhv$2@mate.bln.innominate.de>   <10011280910.ZM168487@wobbly.melbourne.sgi.com>   <news2mail-90017k$n0b$1@mate.bln.innominate.de>   <10011300916.ZM156274@wobbly.melbourne.sgi.com>   <news2mail-9054nv$3u0$2@mate.bln.innominate.de> <10011302031.ZM174105@wobbly.melbourne.sgi.com>
Reply-To: thomas.graichen@innominate.de
X-Trace: mate.bln.innominate.de 975578646 4032 10.0.0.31 (30 Nov 2000 10:04:06 GMT)
X-Complaints-To: news@innominate.de
User-Agent: tin/1.4.4-20000803 ("Vet for the Insane") (UNIX) (Linux/2.4.0-XFS-test10 (i686))
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

"Nathan Scott" <nathans@wobbly.melbourne.sgi.com> wrote:
> On Nov 30,  8:56am, Thomas Graichen wrote:
>> Subject: Re: alpha again
>> ...
>> i will wait with this - because due to russels post it seems to
>> happen earlier and not really on umount

> yup, that blew my theory out of the water.

>> just for my understanding: it will only be seen on umount
>> because the trashed blocks will only then be written to disk
>> and we are looking at the on disk layout with xfs_db only
>> - right?

> Russells point was it isn't only seen on unmount though - thats
> just when we happened to look previously - and we weren't doing
> anything inbetween mount & umount which might force the agf out
> earlier (we are now though).  yes, xfs_db only looks ondisk.

maybe this helps a bit more: i was now able to reproduce it also
before umount - it takes quite a lot of stuff to copy onto the fs
before i see the first corruption with xfs_db but i can see it now
before umount too ... i think this is due to the agressive caching

t

-- 
thomas.graichen@innominate.com
technical director                                       innominate AG
clustering & security                             the linux architects
tel: +49-30-308806-13   fax: -77             http://www.innominate.com

From owner-linux-xfs@oss.sgi.com Thu Nov 30 02:37:55 2000
Received:  by oss.sgi.com id <S553837AbQK3Khp>;
	Thu, 30 Nov 2000 02:37:45 -0800
Received: from [193.154.31.82] ([193.154.31.82]:38930 "HELO convert rfc822-to-8bit
        cerberus.bsbanksysteme.com") by oss.sgi.com with SMTP
	id <S553824AbQK3Kh1>; Thu, 30 Nov 2000 02:37:27 -0800
Received: (qmail 22858 invoked by uid 508); 30 Nov 2000 10:37:24 -0000
Received: from christian.guertler@bs-ag.com by cerberus_bsbanksysteme_com with scan4virus-0.53 (uvscan: v4.0.70/v4107. . Clean. Processed in 0.125707 secs); 30/11/2000 11:37:24
Received: from unknown (HELO ntfax.bsbanksysteme.com) (192.168.0.51)
  by 192.168.0.59 with SMTP; 30 Nov 2000 10:37:24 -0000
Received: by NTFAX.bsbanksysteme.com with Internet Mail Service (5.5.2650.21)
	id <XWKJJ7NS>; Thu, 30 Nov 2000 11:37:19 +0100
Message-ID: <81CF965D19DDD21195AC00C04FB9ACF58438DE@NTFAX.bsbanksysteme.com>
From:   Christian Guertler <christian.guertler@bs-ag.com>
To:     'Russell Cattelan' <cattelan@thebarn.com>
Cc:     "'linux-xfs@oss.sgi.com'" <linux-xfs@oss.sgi.com>
Subject: AW: resizing xfs
Date:   Thu, 30 Nov 2000 11:37:10 +0100
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

Now I know, how expanding of a xfs-filesystem works. The fault was, that the
filesystem was as large as the partition. In a second run I created a
partition (4GB) and a much smaller xfs-filesystem. Now resizing worked. 
But when the partition is full, how can I get space from the rest of the
disk or other partitions? Only with running fdisk?

thank you
Christian Gürtler



> -----Ursprüngliche Nachricht-----
> Von:	Russell Cattelan [SMTP:cattelan@thebarn.com]
> Gesendet am:	Monday, November 27, 2000 8:16 PM
> An:	Christian Guertler
> Cc:	'linux-xfs@oss.sgi.com'
> Betreff:	Re: resizing xfs
> 
> Christian Guertler wrote:
> 
> > Hi;
> >
> > does anyone know, howto enlarge a partition with xfs-filesystem?
> > xfs_growfs says, that "data-size is too large, maximum is 1024143" after
> > "xfs_growfs -D 1024500 /test_xfs" for example.
> >
> > These are the data after "xfs_growfs -n /test_xfs"
> > meta-data=/test_xfs              isize=256    agcount=8, agsize=128018
> blks
> > data     =                       bsize=4096   blocks=1024143, imaxpct=25
> >          =                       sunit=0      swidth=0 blks, unwritten=0
> > naming   =version 2              bsize=4096
> > log      =internal               bsize=4096   blocks=1200
> > realtime =none                   extsz=65536  blocks=0, rtextents=0
> >
> > But there is enough space on my disk (it is a disk with 30 GB, now 3
> > partitions each 4 GB)
> > Do I have to build an new partition with ext2 and do I have to use lvm
> or
> > does it work without lvm, too? The man-page on xfs_growfs is not really
> > clear for me.
> 
> What is the size of your partition?
> You are probably requesting a size larger than the partition can handle.
> The max size for any XFS file system basic block size 512 rounded down to
> the
> nearest
> file system block size in this case (and all case at the moment) 4k.
> 
> Simply running xfs_growfs </mntpt> should expand the file system to the
> max
> available
> for that partition.
> 
> 
> 
> >
> > Sincerly
> > Christian Gürtler

From owner-linux-xfs@oss.sgi.com Thu Nov 30 07:12:08 2000
Received:  by oss.sgi.com id <S553869AbQK3PLs>;
	Thu, 30 Nov 2000 07:11:48 -0800
Received: from hermes.mixx.net ([212.84.196.2]:51983 "HELO hermes.mixx.net")
	by oss.sgi.com with SMTP id <S553865AbQK3PLe>;
	Thu, 30 Nov 2000 07:11:34 -0800
Received: from mate.bln.innominate.de (cerberus.berlin.innominate.de [212.84.234.251])
	by hermes.mixx.net (Postfix) with ESMTP id 0FD67F80C
	for <linux-xfs@oss.sgi.com>; Thu, 30 Nov 2000 16:11:32 +0100 (CET)
Received: by mate.bln.innominate.de (Postfix, from userid 9)
	id 861B52CAA2; Thu, 30 Nov 2000 16:11:31 +0100 (CET)
From:   Thomas Graichen <news-innominate.list.sgi.xfs@innominate.de>
Reply-To: Thomas Graichen <graichen@innominate.de>
X-Newsgroups: innominate.list.sgi.xfs
Subject: Re: resizing xfs
Date:   30 Nov 2000 15:11:31 GMT
Organization: innominate AG, Berlin, Germany
Lines:  17
Distribution: local
Message-ID: <news2mail-905qn3$p11$4@mate.bln.innominate.de>
References: <81CF965D19DDD21195AC00C04FB9ACF58438DE@NTFAX.bsbanksysteme.com>
Reply-To: thomas.graichen@innominate.de
X-Trace: mate.bln.innominate.de 975597091 25633 10.0.0.31 (30 Nov 2000 15:11:31 GMT)
X-Complaints-To: news@innominate.de
User-Agent: tin/1.4.4-20000803 ("Vet for the Insane") (UNIX) (Linux/2.4.0-XFS-test10 (i686))
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

Christian Guertler <christian.guertler@bs-ag.com> wrote:
> Now I know, how expanding of a xfs-filesystem works. The fault was, that the
> filesystem was as large as the partition. In a second run I created a
> partition (4GB) and a much smaller xfs-filesystem. Now resizing worked. 
> But when the partition is full, how can I get space from the rest of the
> disk or other partitions? Only with running fdisk?

thats what an lvm is for :-) ... also parted might be an option
instead of fdisk - but the real solution is an lvm ...

t

-- 
thomas.graichen@innominate.com
technical director                                       innominate AG
clustering & security                             the linux architects
tel: +49-30-308806-13   fax: -77             http://www.innominate.com

From owner-linux-xfs@oss.sgi.com Thu Nov 30 07:14:48 2000
Received:  by oss.sgi.com id <S553873AbQK3POh>;
	Thu, 30 Nov 2000 07:14:37 -0800
Received: from hermes.mixx.net ([212.84.196.2]:58127 "HELO hermes.mixx.net")
	by oss.sgi.com with SMTP id <S553867AbQK3POb>;
	Thu, 30 Nov 2000 07:14:31 -0800
Received: from mate.bln.innominate.de (cerberus.berlin.innominate.de [212.84.234.251])
	by hermes.mixx.net (Postfix) with ESMTP id 57BEFF812
	for <linux-xfs@oss.sgi.com>; Thu, 30 Nov 2000 16:14:29 +0100 (CET)
Received: by mate.bln.innominate.de (Postfix, from userid 9)
	id 28B982CAA2; Thu, 30 Nov 2000 16:14:29 +0100 (CET)
From:   Thomas Graichen <news-innominate.list.sgi.xfs@innominate.de>
Reply-To: Thomas Graichen <graichen@innominate.de>
X-Newsgroups: innominate.list.sgi.xfs
Subject: uname
Date:   30 Nov 2000 15:14:29 GMT
Organization: innominate AG, Berlin, Germany
Lines:  12
Distribution: local
Message-ID: <news2mail-905qsl$p11$5@mate.bln.innominate.de>
Reply-To: thomas.graichen@innominate.de
X-Trace: mate.bln.innominate.de 975597269 25633 10.0.0.31 (30 Nov 2000 15:14:29 GMT)
X-Complaints-To: news@innominate.de
User-Agent: tin/1.4.4-20000803 ("Vet for the Insane") (UNIX) (Linux/2.4.0-XFS-test10 (i686))
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

i found the idea of the uname 2.4.0-XFS-testxy a good idea to avoid
                                   ^^^^
conflicts with other kernels - looks like it got lost in the -test11
update - maybe we can put it back as default?

t

-- 
thomas.graichen@innominate.com
technical director                                       innominate AG
clustering & security                             the linux architects
tel: +49-30-308806-13   fax: -77             http://www.innominate.com

From owner-linux-xfs@oss.sgi.com Thu Nov 30 07:31:07 2000
Received:  by oss.sgi.com id <S553872AbQK3Pa5>;
	Thu, 30 Nov 2000 07:30:57 -0800
Received: from edge.coltex.nl ([194.151.97.115]:29960 "EHLO mail.coltex.nl")
	by oss.sgi.com with ESMTP id <S553867AbQK3Pam>;
	Thu, 30 Nov 2000 07:30:42 -0800
Received: from auto-nb1.xs4all.nl (auto-nb1.coltex.nl [10.0.1.171])
	by mail.coltex.nl (8.10.0/8.9.3) with ESMTP id eAUFU3u23709;
	Thu, 30 Nov 2000 16:30:03 +0100
Message-Id: <4.3.2.7.2.20001130162648.0292aec8@pop.xs4all.nl>
X-Sender: knuffie@pop.xs4all.nl (Unverified)
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
Date:   Thu, 30 Nov 2000 16:27:54 +0100
To:     Thomas Graichen <graichen@innominate.de>, linux-xfs@oss.sgi.com
From:   Seth Mos <knuffie@xs4all.nl>
Subject: Re: uname
In-Reply-To: <news2mail-905qsl$p11$5@mate.bln.innominate.de>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing

At 15:14 30-11-2000 +0000, Thomas Graichen wrote:
>i found the idea of the uname 2.4.0-XFS-testxy a good idea to avoid
>                                    ^^^^
>conflicts with other kernels - looks like it got lost in the -test11
>update - maybe we can put it back as default?

I already patched the Makefile to alter the kernel version.

putting -XFS-test11 in the extra version works.


>t
>
>--
>thomas.graichen@innominate.com
>technical director                                       innominate AG
>clustering & security                             the linux architects
>tel: +49-30-308806-13   fax: -77             http://www.innominate.com

--
Seth
Has anybody seen my lightbulb?
I _really_ need some light here.


From owner-linux-xfs@oss.sgi.com Thu Nov 30 07:57:58 2000
Received:  by oss.sgi.com id <S553875AbQK3P5s>;
	Thu, 30 Nov 2000 07:57:48 -0800
Received: from nic-31-c12-053.mn.mediaone.net ([24.31.12.53]:46098 "EHLO
        lupo.thebarn.com") by oss.sgi.com with ESMTP id <S553871AbQK3P5b>;
	Thu, 30 Nov 2000 07:57:31 -0800
Received: from thebarn.com (localhost [127.0.0.1])
	by lupo.thebarn.com (8.11.1/8.11.0) with ESMTP id eAUFv6Q41589;
	Thu, 30 Nov 2000 09:57:07 -0600 (CST)
	(envelope-from cattelan@thebarn.com)
Message-ID: <3A2678D2.675BBA64@thebarn.com>
Date:   Thu, 30 Nov 2000 09:57:06 -0600
From:   Russell Cattelan <cattelan@thebarn.com>
Reply-To: cattelan@thebarn.com
X-Mailer: Mozilla 4.74 [en] (X11; U; Linux 2.2.12 i386)
X-Accept-Language: en
MIME-Version: 1.0
To:     Thomas Graichen <graichen@innominate.de>
CC:     linux-xfs@oss.sgi.com
Subject: Re: uname
References: <news2mail-905qsl$p11$5@mate.bln.innominate.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

Thomas Graichen wrote:

> i found the idea of the uname 2.4.0-XFS-testxy a good idea to avoid
>                                    ^^^^
> conflicts with other kernels - looks like it got lost in the -test11
> update - maybe we can put it back as default?

Yup  thanks for reminding me, on my list of things todo.


>
>
> t
>
> --
> thomas.graichen@innominate.com
> technical director                                       innominate AG
> clustering & security                             the linux architects
> tel: +49-30-308806-13   fax: -77            http://www.innominate.com

--
Russell Cattelan
cattelan@thebarn.com




From owner-linux-xfs@oss.sgi.com Thu Nov 30 08:08:37 2000
Received:  by oss.sgi.com id <S553881AbQK3QI1>;
	Thu, 30 Nov 2000 08:08:27 -0800
Received: from deliverator.sgi.com ([204.94.214.10]:32051 "EHLO
        deliverator.sgi.com") by oss.sgi.com with ESMTP id <S553878AbQK3QIK>;
	Thu, 30 Nov 2000 08:08:10 -0800
Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id IAA18147
	for <linux-xfs@oss.sgi.com>; Thu, 30 Nov 2000 08:08:10 -0800 (PST)
	mail_from (cattelan@gibble.americas.sgi.com)
Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id KAA7605794 for <linux-xfs@oss.sgi.com>; Thu, 30 Nov 2000 10:05:39 -0600 (CST)
Received: from gibble.americas.sgi.com (gibble.americas.sgi.com [128.162.195.80]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id KAA41053 for <linux-xfs@oss.sgi.com>; Thu, 30 Nov 2000 10:05:39 -0600 (CST)
Received: (from cattelan@localhost)
	by gibble.americas.sgi.com (8.11.0/8.10.1) id eAUG5cP15844
	for linux-xfs@oss.sgi.com; Thu, 30 Nov 2000 10:05:38 -0600
Date:   Thu, 30 Nov 2000 10:05:38 -0600
From:   Russell Cattelan <cattelan@sgi.com>
Message-Id: <200011301605.eAUG5cP15844@gibble.americas.sgi.com>
Subject: TAKE - 
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

Date:  Thu Nov 30 08:05:27 PST 2000
Workarea:  gibble.americas.sgi.com:/export/extra/x2.4-xfs-clean

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


Modid:  2.4.x-xfs:slinx:79370a
linux/Makefile - 1.73
	- Added XFS to the extra version string.



From owner-linux-xfs@oss.sgi.com Thu Nov 30 08:21:37 2000
Received:  by oss.sgi.com id <S553885AbQK3QV1>;
	Thu, 30 Nov 2000 08:21:27 -0800
Received: from hermes.mixx.net ([212.84.196.2]:52498 "HELO hermes.mixx.net")
	by oss.sgi.com with SMTP id <S553882AbQK3QVH>;
	Thu, 30 Nov 2000 08:21:07 -0800
Received: from mate.bln.innominate.de (cerberus.berlin.innominate.de [212.84.234.251])
	by hermes.mixx.net (Postfix) with ESMTP id 57946F813
	for <linux-xfs@oss.sgi.com>; Thu, 30 Nov 2000 17:21:05 +0100 (CET)
Received: by mate.bln.innominate.de (Postfix, from userid 9)
	id 38E3A2CAA3; Thu, 30 Nov 2000 17:21:05 +0100 (CET)
From:   Thomas Graichen <news-innominate.list.sgi.xfs@innominate.de>
Reply-To: Thomas Graichen <graichen@innominate.de>
X-Newsgroups: innominate.list.sgi.xfs
Subject: sync
Date:   30 Nov 2000 16:21:05 GMT
Organization: innominate AG, Berlin, Germany
Lines:  17
Distribution: local
Message-ID: <news2mail-905uph$dc3$1@mate.bln.innominate.de>
Reply-To: thomas.graichen@innominate.de
X-Trace: mate.bln.innominate.de 975601265 13699 10.0.0.31 (30 Nov 2000 16:21:05 GMT)
X-Complaints-To: news@innominate.de
User-Agent: tin/1.4.4-20000803 ("Vet for the Insane") (UNIX) (Linux/2.4.0-XFS-test10 (i686))
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

i just remember some discussion about sync not being fully clean
implemented in the linux port of XFS - so my question: what is
the current state of this? what exactly does now work?

does mount -o sync or -o wsync work? is XFS as it is now useable
(aside from stability points) as an NFS server and satisfy the
sync requirements of NFS?

a lot of thanks in advance

t

-- 
thomas.graichen@innominate.com
technical director                                       innominate AG
clustering & security                             the linux architects
tel: +49-30-308806-13   fax: -77             http://www.innominate.com

From owner-linux-xfs@oss.sgi.com Thu Nov 30 08:22:57 2000
Received:  by oss.sgi.com id <S553887AbQK3QWi>;
	Thu, 30 Nov 2000 08:22:38 -0800
Received: from nic-31-c12-053.mn.mediaone.net ([24.31.12.53]:48402 "EHLO
        lupo.thebarn.com") by oss.sgi.com with ESMTP id <S553884AbQK3QWa>;
	Thu, 30 Nov 2000 08:22:30 -0800
Received: from thebarn.com (localhost [127.0.0.1])
	by lupo.thebarn.com (8.11.1/8.11.0) with ESMTP id eAUGMMQ41617;
	Thu, 30 Nov 2000 10:22:22 -0600 (CST)
	(envelope-from cattelan@thebarn.com)
Message-ID: <3A267EBE.52E6CC95@thebarn.com>
Date:   Thu, 30 Nov 2000 10:22:22 -0600
From:   Russell Cattelan <cattelan@thebarn.com>
Reply-To: cattelan@thebarn.com
X-Mailer: Mozilla 4.74 [en] (X11; U; Linux 2.2.12 i386)
X-Accept-Language: en
MIME-Version: 1.0
To:     Thomas Graichen <graichen@innominate.de>
CC:     linux-xfs@oss.sgi.com
Subject: Re: stress test on ppc
References: <news2mail-8uecj0$i5e$1@mate.bln.innominate.de>   <10011221244.ZM158790@wobbly.melbourne.sgi.com>   <news2mail-8vlq0n$hiu$2@mate.bln.innominate.de>   <10011261336.ZM166460@wobbly.melbourne.sgi.com>   <news2mail-8vt5ub$dhv$3@mate.bln.innominate.de>   <10011281048.ZM165042@wobbly.melbourne.sgi.com>   <news2mail-9001u3$n0b$2@mate.bln.innominate.de>   <10011290940.ZM169800@wobbly.melbourne.sgi.com>   <news2mail-902hr6$307$1@mate.bln.innominate.de> <10011301040.ZM164128@wobbly.melbourne.sgi.com> <news2mail-90550o$3u0$3@mate.bln.innominate.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

Thomas Graichen wrote:

> "Nathan Scott" <nathans@wobbly.melbourne.sgi.com> wrote:
> > hi Thomas,
>
> > On Nov 29,  9:21am, Thomas Graichen wrote:
> >> Subject: Re: stress test on ppc
> >> "Nathan Scott" <nathans@wobbly.melbourne.sgi.com> wrote:
> >>
> >> ...looks like it happens pretty early
> >>
> >>   ppc:/usr/src/xfs/cmd/xfs/mkfs # ./mkfs.xfs -f /dev/hda9
> >>   meta-data=/dev/hda9              isize=256    agcount=8, agsize=49152 blks
> >>   data     =                       bsize=4096   blocks=393216, imaxpct=25
> >>            =                       sunit=0      swidth=0 blks, unwritten=0
> >>   naming   =version 2              bsize=4096
> >>   log      =internal log           bsize=4096   blocks=1200
> >>   realtime =none                   extsz=65536  blocks=0, rtextents=0
> >>   ppc:/usr/src/xfs/cmd/xfs/mkfs # xfs_db -r -c sb -c p /dev/hda9|grep blocksize
> >>   blocksize = 524288
> >>   ppc:/usr/src/xfs/cmd/xfs/mkfs #
> >>
>
> > ok, so the problem is in either mkfs or xfs_db.  after mkfs, run:
>
> > # od -c -N 8 /dev/hda9
> > 0000000   X   F   S   B  \0  \0 020  \0
> > 0000012
>
> > you should see exactly that (the second 4 are the blocksize).
> > if you do, its an xfs_db problem.  if not, its a mkfs problem.
>
> ppc:~ # od -c -N 8 /dev/hda9
> 0000000   X   F   S   B  \0  \0 020  \0
> 0000010
> ppc:~ #
>
> so it looks like xfs_db
>
> > lemme know.  (at the same time, could you send the unfiltered
> > "xfs_db -r -c sb -c p /dev/hda9" output also?)
>
> no problem

Ok this doesn't look good.
Several fields looked bad already.
Notably the rootino should be 128

Was this output taken directly after a mkfs or after a mount?

We need to narrow down our problems.
First we need to figure out if mkfs is correctly
making the file system.
Second is xfs_db correctly reporting the values
on disk.

Finally where in XFS are we trashing AG blocks.

Ok lets do things in this order
mkfs a file system
od -c -N 8 -j 512 /dev/sdb1
should result in
0001000   X   A   G   F  \0  \0  \0 001
od -c -N 8 -j 1024 /dev/sdb1
and
 od -c -N 8 -j 1024 /dev/sdb1
0002000   X   A   G   I  \0  \0  \0 001

Those are the magic #s

now try
xfs_db
sb 0
print
agf 0
print
agi 0
print

save output

Mount the file system
run od commands and xfs_db command again
save output

Now do some FS activity
run od command and xfs_sb commands again
save output.


Send all the output to us.


This should tell us where we need to start fixing things first.

I suspect we will need to find an alpha around someplace to actually
get some of this stuff debugged.



>
>
> ppc:~ # xfs_db -r -c sb -c p /dev/hda9
> magicnum = 0x58465342
> blocksize = 524288
> dblocks = 105553116266496
> rblocks = 0
> rextents = 0
> uuid = bc3a44f0-947a-4ebe-964e-5d237161432b
> logstart = 262148
> rootino = 72057594037927936
> rbmino = 129
> rsumino = 4683743612465315840
> rextsize = 16
> agblocks = 196608
> agcount = 8
> rbmblocks = 0
> logblocks = 1200
> versionnum = 0x2084
> sectsize = 64
> inodesize = 256
> inopblock = 2048
> fname = "\000\000\000\000\000\000\000\000\000\000\000\000"
> blocklog = 12
> sectlog = 144
> inodelog = 8
> inopblog = 32
> agblklog = 16
> rextslog = 0
> inprogress = 0
> imax_pct = 152
> icount = 64
> ifree = 13546827679130451968
> fdblocks = 391980
> frextents = 0
> uquotino = 0
> pquotino = 0
> qflags = 0
> flags = 0
> shared_vn = 0
> inoalignmt = 1073741824
> unit = 0
> width = 0
> dirblklog = 0
> ppc:~ #
>
> t
>
> --
> thomas.graichen@innominate.com
> technical director                                       innominate AG
> clustering & security                             the linux architects
> tel: +49-30-308806-13   fax: -77            http://www.innominate.com

--
Russell Cattelan
cattelan@thebarn.com




From owner-linux-xfs@oss.sgi.com Thu Nov 30 08:46:29 2000
Received:  by oss.sgi.com id <S553886AbQK3QqT>;
	Thu, 30 Nov 2000 08:46:19 -0800
Received: from hermes.mixx.net ([212.84.196.2]:24324 "HELO hermes.mixx.net")
	by oss.sgi.com with SMTP id <S553880AbQK3Qpx>;
	Thu, 30 Nov 2000 08:45:53 -0800
Received: from mate.bln.innominate.de (cerberus.berlin.innominate.de [212.84.234.251])
	by hermes.mixx.net (Postfix) with ESMTP id A22D7F814
	for <linux-xfs@oss.sgi.com>; Thu, 30 Nov 2000 17:45:51 +0100 (CET)
Received: by mate.bln.innominate.de (Postfix, from userid 9)
	id 772E52CAA4; Thu, 30 Nov 2000 17:45:51 +0100 (CET)
From:   Thomas Graichen <news-innominate.list.sgi.xfs@innominate.de>
Reply-To: Thomas Graichen <graichen@innominate.de>
X-Newsgroups: innominate.list.sgi.xfs
Subject: Re: stress test on ppc
Date:   30 Nov 2000 16:45:51 GMT
Organization: innominate AG, Berlin, Germany
Lines:  146
Distribution: local
Message-ID: <news2mail-90607v$dc3$2@mate.bln.innominate.de>
References: <news2mail-8uecj0$i5e$1@mate.bln.innominate.de>   <10011261336.ZM166460@wobbly.melbourne.sgi.com>   <news2mail-8vt5ub$dhv$3@mate.bln.innominate.de>   <10011281048.ZM165042@wobbly.melbourne.sgi.com>   <news2mail-9001u3$n0b$2@mate.bln.innominate.de>   <10011290940.ZM169800@wobbly.melbourne.sgi.com>   <news2mail-902hr6$307$1@mate.bln.innominate.de> <10011301040.ZM164128@wobbly.melbourne.sgi.com> <news2mail-90550o$3u0$3@mate.bln.innominate.de> <3A267EBE.52E6CC95@thebarn.com>
Reply-To: thomas.graichen@innominate.de
X-Trace: mate.bln.innominate.de 975602751 13699 10.0.0.31 (30 Nov 2000 16:45:51 GMT)
X-Complaints-To: news@innominate.de
User-Agent: tin/1.4.4-20000803 ("Vet for the Insane") (UNIX) (Linux/2.4.0-XFS-test10 (i686))
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

Russell Cattelan <cattelan@thebarn.com> wrote:

> Ok this doesn't look good.
> Several fields looked bad already.
> Notably the rootino should be 128

> Was this output taken directly after a mkfs or after a mount?

[just a start info: all the stuff in this posting is on ppc]

directly after a mkfs - i think i remember it was 128 at some time
on xfs before - also xfs_repair or xfs_ch does not find anything
on that fs and it runs as far as i can see close to rock solid
on ppc so i assume the problem is in xfs_db

> We need to narrow down our problems.
> First we need to figure out if mkfs is correctly
> making the file system.

ok - lets see

ppc:~ # dd if=/dev/zero of=/tmp/testfile bs=1024k count=32
32+0 records in
32+0 records out
ppc:~ # mkfs -t xfs -f /tmp/testfile 
meta-data=/tmp/testfile          isize=256    agcount=2, agsize=4096 blks
data     =                       bsize=4096   blocks=8192, imaxpct=25
         =                       sunit=0      swidth=0 blks, unwritten=0
naming   =version 2              bsize=4096  
log      =internal log           bsize=4096   blocks=1200
realtime =none                   extsz=65536  blocks=0, rtextents=0
ppc:~ #
...
[root@orange /tmp]# uname -a
Linux orange.bln.innominate.de 2.4.0-XFS-test10 #2 SMP ... i686 unknown
[root@orange /tmp]# scp ppc:/tmp/testfile .
testfile             100% |*****************************| 32768 KB    00:17    
[root@orange /tmp]# xfs_db -r -c sb -c p testfile 
magicnum = 0x58465342
blocksize = 4096
dblocks = 8192
rblocks = 0
rextents = 0
uuid = a0a20e0a-7fcb-4fc8-a7de-e79e939245de
logstart = 4100
rootino = 128
rbmino = 129
rsumino = 130
rextsize = 16
agblocks = 4096
agcount = 2
rbmblocks = 0
logblocks = 1200
versionnum = 0x2084
sectsize = 512
inodesize = 256
inopblock = 16
fname = "\000\000\000\000\000\000"
fpack = "\000\000\000\000\000\000"
blocklog = 12
sectlog = 9
inodelog = 8
inopblog = 4
agblklog = 12
rextslog = 0
inprogress = 0
imax_pct = 25
icount = 64
ifree = 61
fdblocks = 6980
frextents = 0
uquotino = 0
pquotino = 0
qflags = 0
flags = 0
shared_vn = 0
inoalignmt = 2
unit = 0
width = 0
dirblklog = 0
[root@orange /tmp]# 

so its xfs_db i think (the other direction shows the same: an i386
created image also gives wrong results with the ppc xfs_db)

> Second is xfs_db correctly reporting the values
> on disk.

no - mkfs is ok - xfs_db is wrong and i assume the xfs in the
kernel is also ok - the stress tests only give bad results due
to the broken xfs_db

> Finally where in XFS are we trashing AG blocks.

keep in mind: the agf trashing was on the alpha! - so this has more
to do with 8k blocksize or 64bit but nothing with endianness - just
to keep that in mind

will do the other stuff below on the alpha in a minute in another
posting ...

t

> Ok lets do things in this order
> mkfs a file system
> od -c -N 8 -j 512 /dev/sdb1
> should result in
> 0001000   X   A   G   F  \0  \0  \0 001
> od -c -N 8 -j 1024 /dev/sdb1
> and
>  od -c -N 8 -j 1024 /dev/sdb1
> 0002000   X   A   G   I  \0  \0  \0 001

> Those are the magic #s

> now try
> xfs_db
> sb 0
> print
> agf 0
> print
> agi 0
> print

> save output

> Mount the file system
> run od commands and xfs_db command again
> save output

> Now do some FS activity
> run od command and xfs_sb commands again
> save output.

> Send all the output to us.

> This should tell us where we need to start fixing things first.

> I suspect we will need to find an alpha around someplace to actually
> get some of this stuff debugged.

-- 
thomas.graichen@innominate.com
technical director                                       innominate AG
clustering & security                             the linux architects
tel: +49-30-308806-13   fax: -77             http://www.innominate.com

From owner-linux-xfs@oss.sgi.com Thu Nov 30 08:47:39 2000
Received:  by oss.sgi.com id <S553889AbQK3Qr2>;
	Thu, 30 Nov 2000 08:47:28 -0800
Received: from nic-31-c12-053.mn.mediaone.net ([24.31.12.53]:49938 "EHLO
        lupo.thebarn.com") by oss.sgi.com with ESMTP id <S553883AbQK3QrV>;
	Thu, 30 Nov 2000 08:47:21 -0800
Received: from thebarn.com (localhost [127.0.0.1])
	by lupo.thebarn.com (8.11.1/8.11.0) with ESMTP id eAUGlDQ41642;
	Thu, 30 Nov 2000 10:47:13 -0600 (CST)
	(envelope-from cattelan@thebarn.com)
Message-ID: <3A26848D.444A3043@thebarn.com>
Date:   Thu, 30 Nov 2000 10:47:10 -0600
From:   Russell Cattelan <cattelan@thebarn.com>
Reply-To: cattelan@thebarn.com
X-Mailer: Mozilla 4.74 [en] (X11; U; Linux 2.2.12 i386)
X-Accept-Language: en
MIME-Version: 1.0
To:     Thomas Graichen <graichen@innominate.de>
CC:     linux-xfs@oss.sgi.com
Subject: Re: sync
References: <news2mail-905uph$dc3$1@mate.bln.innominate.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

Thomas Graichen wrote:

> i just remember some discussion about sync not being fully clean
> implemented in the linux port of XFS - so my question: what is
> the current state of this? what exactly does now work?

You might be thinking of the O_SYNC option which is yet to
be implanted, but that should only affect applications which
expect O_SYNC behavior.

As far as the the file system sync operation there hasn't been
any problems in that area.


>
> does mount -o sync or -o wsync work? is XFS as it is now useable
> (aside from stability points) as an NFS server and satisfy the
> sync requirements of NFS?
>
> a lot of thanks in advance
>
> t
>
> --
> thomas.graichen@innominate.com
> technical director                                       innominate AG
> clustering & security                             the linux architects
> tel: +49-30-308806-13   fax: -77            http://www.innominate.com

--
Russell Cattelan
cattelan@thebarn.com




From owner-linux-xfs@oss.sgi.com Thu Nov 30 09:10:39 2000
Received:  by oss.sgi.com id <S553893AbQK3RKa>;
	Thu, 30 Nov 2000 09:10:30 -0800
Received: from hermes.mixx.net ([212.84.196.2]:36357 "HELO hermes.mixx.net")
	by oss.sgi.com with SMTP id <S553890AbQK3RKT>;
	Thu, 30 Nov 2000 09:10:19 -0800
Received: from mate.bln.innominate.de (cerberus.berlin.innominate.de [212.84.234.251])
	by hermes.mixx.net (Postfix) with ESMTP id 78D92F813
	for <linux-xfs@oss.sgi.com>; Thu, 30 Nov 2000 18:10:17 +0100 (CET)
Received: by mate.bln.innominate.de (Postfix, from userid 9)
	id 1A1142CAA4; Thu, 30 Nov 2000 18:10:17 +0100 (CET)
From:   Thomas Graichen <news-innominate.list.sgi.xfs@innominate.de>
Reply-To: Thomas Graichen <graichen@innominate.de>
X-Newsgroups: innominate.list.sgi.xfs
Subject: Re: stress test on ppc
Date:   30 Nov 2000 17:10:16 GMT
Organization: innominate AG, Berlin, Germany
Lines:  309
Distribution: local
Message-ID: <news2mail-9061lo$dc3$3@mate.bln.innominate.de>
References: <news2mail-8uecj0$i5e$1@mate.bln.innominate.de>   <10011261336.ZM166460@wobbly.melbourne.sgi.com>   <news2mail-8vt5ub$dhv$3@mate.bln.innominate.de>   <10011281048.ZM165042@wobbly.melbourne.sgi.com>   <news2mail-9001u3$n0b$2@mate.bln.innominate.de>   <10011290940.ZM169800@wobbly.melbourne.sgi.com>   <news2mail-902hr6$307$1@mate.bln.innominate.de> <10011301040.ZM164128@wobbly.melbourne.sgi.com> <news2mail-90550o$3u0$3@mate.bln.innominate.de> <3A267EBE.52E6CC95@thebarn.com>
Reply-To: thomas.graichen@innominate.de
X-Trace: mate.bln.innominate.de 975604216 13699 10.0.0.31 (30 Nov 2000 17:10:16 GMT)
X-Complaints-To: news@innominate.de
User-Agent: tin/1.4.4-20000803 ("Vet for the Insane") (UNIX) (Linux/2.4.0-XFS-test10 (i686))
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

Russell Cattelan <cattelan@thebarn.com> wrote:

[ok and now the alpha]

> Finally where in XFS are we trashing AG blocks.

> Ok lets do things in this order
> mkfs a file system
> od -c -N 8 -j 512 /dev/sdb1
> should result in
> 0001000   X   A   G   F  \0  \0  \0 001
> od -c -N 8 -j 1024 /dev/sdb1
> and
>  od -c -N 8 -j 1024 /dev/sdb1
> 0002000   X   A   G   I  \0  \0  \0 001

looks like this last one is wrong? - it's the same as the second

> Those are the magic #s

root@cyan:~# od -c -N 8 -j 512 /dev/sdb1
0001000   X   A   G   F  \0  \0  \0 001
0001010
root@cyan:~# od -c -N 8 -j 1024 /dev/sdb1
0002000   X   A   G   I  \0  \0  \0 001
0002010
root@cyan:~#

> now try
> xfs_db
> sb 0
> print
> agf 0
> print
> agi 0
> print

> save output

root@cyan:~# xfs_db /dev/sdb1
xfs_db: sb 0
xfs_db: print
magicnum = 0x58465342
blocksize = 8192
dblocks = 33130
rblocks = 0
rextents = 0
uuid = eac0a48b-4dff-41c3-b2cc-e110bd5c3ff8
logstart = 32772
rootino = 256
rbmino = 257
rsumino = 258
rextsize = 8
agblocks = 4142
agcount = 8
rbmblocks = 0
logblocks = 1000
versionnum = 0x2084
sectsize = 512
inodesize = 256
inopblock = 32
fname = "\000\000\000\000\000\000\000\000\000\000\000\000"
blocklog = 13
sectlog = 9
inodelog = 8
inopblog = 5
agblklog = 13
rextslog = 0
inprogress = 0
imax_pct = 25
icount = 64
ifree = 61
fdblocks = 32096
frextents = 0
uquotino = 0
pquotino = 0
qflags = 0
flags = 0
shared_vn = 0
inoalignmt = 1
unit = 0
width = 0
dirblklog = 0
xfs_db: agf 0
xfs_db: print
magicnum = 0x58414746
versionnum = 1
seqno = 0
length = 4142
bnoroot = 1
cntroot = 2
bnolevel = 1
cntlevel = 1
flfirst = 0
fllast = 3
flcount = 4
freeblks = 4132
longest = 4132
xfs_db: agi 0
xfs_db: print
magicnum = 0x58414749
versionnum = 1
seqno = 0
length = 4142
count = 64
root = 3
level = 1
freecount = 61
newino = 256
dirino = null
unlinked[0-63] = 
xfs_db: quit
root@cyan:~#

> Mount the file system
> run od commands and xfs_db command again
> save output

root@cyan:~# od -c -N 8 -j 512 /dev/sdb1
0001000   X   A   G   F  \0  \0  \0 001
0001010
root@cyan:~# od -c -N 8 -j 1024 /dev/sdb1
0002000   X   A   G   I  \0  \0  \0 001
0002010
root@cyan:~# xfs_db -r /dev/sdb1
xfs_db: sb 0
xfs_db: print
magicnum = 0x58465342
blocksize = 8192
dblocks = 33130
rblocks = 0
rextents = 0
uuid = eac0a48b-4dff-41c3-b2cc-e110bd5c3ff8
logstart = 32772
rootino = 256
rbmino = 257
rsumino = 258
rextsize = 8
agblocks = 4142
agcount = 8
rbmblocks = 0
logblocks = 1000
versionnum = 0x2084
sectsize = 512
inodesize = 256
inopblock = 32
fname = "\000\000\000\000\000\000\000\000\000\000\000\000"
blocklog = 13
sectlog = 9
inodelog = 8
inopblog = 5
agblklog = 13
rextslog = 0
inprogress = 0
imax_pct = 25
icount = 64
ifree = 61
fdblocks = 32096
frextents = 0
uquotino = 0
pquotino = 0
qflags = 0
flags = 0
shared_vn = 0
inoalignmt = 1
unit = 0
width = 0
dirblklog = 0
xfs_db: agf 0
xfs_db: print
magicnum = 0x58414746
versionnum = 1
seqno = 0
length = 4142
bnoroot = 1
cntroot = 2
bnolevel = 1
cntlevel = 1
flfirst = 0
fllast = 3
flcount = 4
freeblks = 4132
longest = 4132
xfs_db: agi 0
xfs_db: print
magicnum = 0x58414749
versionnum = 1
seqno = 0
length = 4142
count = 64
root = 3
level = 1
freecount = 61
newino = 256
dirino = null
unlinked[0-63] = 
xfs_db:

> Now do some FS activity
> run tod command and xfs_sb commands again
> save output.

root@cyan:~# od -c -N 8 -j 512 /dev/sdb1
0001000  \0  \0  \0  \0 377 377 377 377
0001010
root@cyan:~# od -c -N 8 -j 1024 /dev/sdb1
0002000   X   A   G   I  \0  \0  \0 001
0002010
root@cyan:~# xfs_db -r /dev/sdb1
xfs_db: sb 0
xfs_db: print
magicnum = 0x58465342
blocksize = 8192
dblocks = 33130
rblocks = 0
rextents = 0
uuid = 89cb7e3c-c0cc-4a42-8013-aef1f692b80b
logstart = 32772
rootino = 256
rbmino = 257
rsumino = 258
rextsize = 8
agblocks = 4142
agcount = 8
rbmblocks = 0
logblocks = 1000
versionnum = 0x2084
sectsize = 512
inodesize = 256
inopblock = 32
fname = "\000\000\000\000\000\000\000\000\000\000\000\000"
blocklog = 13
sectlog = 9
inodelog = 8
inopblog = 5
agblklog = 13
rextslog = 0
inprogress = 0
imax_pct = 25
icount = 2240
ifree = 202
fdblocks = 8423
frextents = 0
uquotino = 0
pquotino = 0
qflags = 0
flags = 0
shared_vn = 0
inoalignmt = 1
unit = 0
width = 0
dirblklog = 0
xfs_db: agf 0
xfs_db: print
magicnum = 0
versionnum = 4294967295
seqno = 0
length = 0
bnoroot = 2966461184
cntroot = 16580607
bnolevel = 16580607
cntlevel = 0
flfirst = 2147483648
fllast = 16777216
flcount = 3223092738
freeblks = 16580607
longest = 32258
xfs_db:agi 0
xfs_db: print
magicnum = 0x58414749
versionnum = 1
seqno = 0
length = 4142
count = 448
root = 3
level = 1
freecount = 0
newino = 122016
dirino = null
unlinked[0-63] = 
xfs_db:

> Send all the output to us.

i hope it is ok to post it here - i think it's not too much - but if
anyone does not like those big debugging mails i can also upload
them to a ftp accessable place in the future

> This should tell us where we need to start fixing things first.

> I suspect we will need to find an alpha around someplace to actually
> get some of this stuff debugged.

i'll update the alpha to the latest kernel now and recheck that it
is still there (you never know :-) ... also keep in mind: compiler
bugs are possible too ... it's gcc 2.95.2 which has problems on
intel too but seems to work fine on the ppc - but this kind
of problem does not really look like a compiler bug to me
on the other side

good luck

t

-- 
thomas.graichen@innominate.com
technical director                                       innominate AG
clustering & security                             the linux architects
tel: +49-30-308806-13   fax: -77             http://www.innominate.com

From owner-linux-xfs@oss.sgi.com Thu Nov 30 09:34:29 2000
Received:  by oss.sgi.com id <S553895AbQK3ReT>;
	Thu, 30 Nov 2000 09:34:19 -0800
Received: from hermes.mixx.net ([212.84.196.2]:30726 "HELO hermes.mixx.net")
	by oss.sgi.com with SMTP id <S553892AbQK3Rd6>;
	Thu, 30 Nov 2000 09:33:58 -0800
Received: from mate.bln.innominate.de (cerberus.berlin.innominate.de [212.84.234.251])
	by hermes.mixx.net (Postfix) with ESMTP id E4A3FF818
	for <linux-xfs@oss.sgi.com>; Thu, 30 Nov 2000 18:33:55 +0100 (CET)
Received: by mate.bln.innominate.de (Postfix, from userid 9)
	id 5A8DC2CAA2; Thu, 30 Nov 2000 18:33:55 +0100 (CET)
From:   Thomas Graichen <news-innominate.list.sgi.xfs@innominate.de>
Reply-To: Thomas Graichen <graichen@innominate.de>
X-Newsgroups: innominate.list.sgi.xfs
Subject: Re: stress test on ppc
Date:   30 Nov 2000 17:33:55 GMT
Organization: innominate AG, Berlin, Germany
Lines:  14
Distribution: local
Message-ID: <news2mail-906323$nun$1@mate.bln.innominate.de>
References: <news2mail-8uecj0$i5e$1@mate.bln.innominate.de>   <news2mail-8vt5ub$dhv$3@mate.bln.innominate.de>   <10011281048.ZM165042@wobbly.melbourne.sgi.com>   <news2mail-9001u3$n0b$2@mate.bln.innominate.de>   <10011290940.ZM169800@wobbly.melbourne.sgi.com>   <news2mail-902hr6$307$1@mate.bln.innominate.de> <10011301040.ZM164128@wobbly.melbourne.sgi.com> <news2mail-90550o$3u0$3@mate.bln.innominate.de> <3A267EBE.52E6CC95@thebarn.com> <news2mail-9061lo$dc3$3@mate.bln.innominate.de>
Reply-To: thomas.graichen@innominate.de
X-Trace: mate.bln.innominate.de 975605635 24535 10.0.0.31 (30 Nov 2000 17:33:55 GMT)
X-Complaints-To: news@innominate.de
User-Agent: tin/1.4.4-20000803 ("Vet for the Insane") (UNIX) (Linux/2.4.0-XFS-test10 (i686))
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

Thomas Graichen <news-innominate.list.sgi.xfs@innominate.de> wrote:

> i'll update the alpha to the latest kernel now and recheck that it
> is still there (you never know :-) ...

it didn't work - the problem is still there :-)

t

-- 
thomas.graichen@innominate.com
technical director                                       innominate AG
clustering & security                             the linux architects
tel: +49-30-308806-13   fax: -77             http://www.innominate.com

From owner-linux-xfs@oss.sgi.com Thu Nov 30 11:07:19 2000
Received:  by oss.sgi.com id <S553897AbQK3THK>;
	Thu, 30 Nov 2000 11:07:10 -0800
Received: from pC19F0398.dip.t-dialin.net ([193.159.3.152]:39555 "EHLO
        kernelpanix.aura.of.mankind") by oss.sgi.com with ESMTP
	id <S553891AbQK3TGv>; Thu, 30 Nov 2000 11:06:51 -0800
Received: (from utz@localhost)
	by kernelpanix.aura.of.mankind (8.11.0/8.11.0) id eAUJMlt24307
	for linux-xfs@oss.sgi.com; Thu, 30 Nov 2000 20:22:47 +0100
X-Authentication-Warning: kernelpanix.aura.of.mankind: utz set sender to xfs@s2y4n2c.de using -f
Date:   Thu, 30 Nov 2000 20:22:47 +0100
From:   utz lehmann <xfs@s2y4n2c.de>
To:     linux-xfs@oss.sgi.com
Subject: kernelcrash during root filesystem recovery
Message-ID: <20001130202247.A24118@s2y4n2c.de>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
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 found a bug in yesterdays (2000-11-29) kernel (the test11 one).

i had powered off my computer without a clean shutdown. i do this very
often, no problems since month with xfs.

the kernel traped into kdb while recovering the xfs root filesystem. i write
the messages down from the screen, maybe there are typos:


XFS: WARNING: recovery required on readonly filesystem.

XFS: write access will be enabled recovery.

Staring XFS recovery on filesystem: ide0 (3,6) (dev:3/6)
Unable to handle kernel NULL pointer dereference at virtual address 00000008
 printing eip:
c016482b
*pde = 00000000

Entering kdb (currect=0xc125c000, pid1) Panic: Oops
due to panic @ 0xc016482b
eax = 0x00000000 ebx = 0xc12c3460 ecx = 0xc12c3460 edx = 0x00000000
esi = 0xc12c0e60 edi = 0x00000000 esp = 0xc125d940 eip = 0xc016482b
ebp = 0x00000000 xss = 0x00000018 xcs = 0x00000010 eflags = 0x00010246
xds = 0x00000018 xes = 0x00000018 origeax = 0xffffffff &regs = 0xc125d90c


i rebooted the machine with the same result.
rebooting with a kernel from 2000-11-14 works with no problems.

i made some tests with the buggy kernel:

clean shutdown works.
hardreset after "sync" works.
hardreset after booting without sync works.
hardreset during booting works.
hardreset during writing (cp -av /usr/src/linux /tmp) triggers the bug.
4 times it traped into kdb, 1 time the kernel hangs.

booting with the older kernel always works.

my system:
K6-500, 128MB
xfs root filesystem on a ide disk.


hope that helps.


utz

From owner-linux-xfs@oss.sgi.com Thu Nov 30 13:15:41 2000
Received:  by oss.sgi.com id <S553896AbQK3VPW>;
	Thu, 30 Nov 2000 13:15:22 -0800
Received: from pneumatic-tube.sgi.com ([204.94.214.22]:1891 "EHLO
        pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP
	id <S553812AbQK3VPC>; Thu, 30 Nov 2000 13:15:02 -0800
Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id NAA06338
	for <linux-xfs@oss.sgi.com>; Thu, 30 Nov 2000 13:23:04 -0800 (PST)
	mail_from (cattelan@thebarn.com)
Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id PAA7778103; Thu, 30 Nov 2000 15:13:44 -0600 (CST)
Received: from gibble.americas.sgi.com (gibble.americas.sgi.com [128.162.195.80]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id PAA27409; Thu, 30 Nov 2000 15:13:44 -0600 (CST)
Received: from thebarn.com (localhost [127.0.0.1])
	by gibble.americas.sgi.com (8.11.0/8.10.1) with ESMTP id eAULDhj17452;
	Thu, 30 Nov 2000 15:13:43 -0600
Message-ID: <3A26C307.5FCCC673@thebarn.com>
Date:   Thu, 30 Nov 2000 15:13:43 -0600
From:   Russell Cattelan <cattelan@thebarn.com>
X-Mailer: Mozilla 4.75 [en] (X11; U; Linux 2.4.0-whipme11 i686)
X-Accept-Language: en
MIME-Version: 1.0
To:     Thomas Graichen <graichen@innominate.de>
CC:     linux-xfs@oss.sgi.com
Subject: Re: stress test on ppc
References: <news2mail-8uecj0$i5e$1@mate.bln.innominate.de>   <10011261336.ZM166460@wobbly.melbourne.sgi.com>   <news2mail-8vt5ub$dhv$3@mate.bln.innominate.de>   <10011281048.ZM165042@wobbly.melbourne.sgi.com>   <news2mail-9001u3$n0b$2@mate.bln.innominate.de>   <10011290940.ZM169800@wobbly.melbourne.sgi.com>   <news2mail-902hr6$307$1@mate.bln.innominate.de> <10011301040.ZM164128@wobbly.melbourne.sgi.com> <news2mail-90550o$3u0$3@mate.bln.innominate.de> <3A267EBE.52E6CC95@thebarn.com> <news2mail-9061lo$dc3$3@mate.bln.innominate.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

Thomas Graichen wrote:

Ok good...
So everything thing looks good right after mkfs and the mount.

The problem does appear to the first write to the super block.
as shown by
od -c -N 8 -j 512 /dev/sdb1
not reporting XAGF

My best guess that this point as to what it happening:
We have added valid bits to the page structure, with each
bit representing 1 512 byte block.
It appears that someplace in the pagebuf  math the basic unit
is now 1024, rather than 512.
Since the page size has doubled it does make sense the BB size has
doubled.
So now the trick is to find the problem.

Lets verify the problem first
just before the generic_make_request function in page_buf.c:
_pagebuf_page_io
                        printk ("_pagebuf page io calling gmk itr %d bh
0x%p block %d size %ld\t",itr,

psync->bh[itr],psync->bh[itr]->b_blocknr,psync->bh[itr]->b_size);
                        { int i;
                        for(i=0; i < 4; i++){
                          printk("%c",psync->bh[itr]->b_data[i]);
                        }
                        printk("\n");
                        }

The numbers we will be interested in will be the b_ blocknr and the
b_bsize.


> Russell Cattelan <cattelan@thebarn.com> wrote:
>
> [ok and now the alpha]
>
> > Finally where in XFS are we trashing AG blocks.
>
> > Ok lets do things in this order
> > mkfs a file system
> > od -c -N 8 -j 512 /dev/sdb1
> > should result in
> > 0001000   X   A   G   F  \0  \0  \0 001
> > od -c -N 8 -j 1024 /dev/sdb1
> > and
> >  od -c -N 8 -j 1024 /dev/sdb1
> > 0002000   X   A   G   I  \0  \0  \0 001
>
> looks like this last one is wrong? - it's the same as the second
>
> > Those are the magic #s
>
> root@cyan:~# od -c -N 8 -j 512 /dev/sdb1
> 0001000   X   A   G   F  \0  \0  \0 001
> 0001010
> root@cyan:~# od -c -N 8 -j 1024 /dev/sdb1
> 0002000   X   A   G   I  \0  \0  \0 001
> 0002010
> root@cyan:~#
>
> > now try
> > xfs_db
> > sb 0
> > print
> > agf 0
> > print
> > agi 0
> > print
>
> > save output
>
> root@cyan:~# xfs_db /dev/sdb1
> xfs_db: sb 0
> xfs_db: print
> magicnum = 0x58465342
> blocksize = 8192
> dblocks = 33130
> rblocks = 0
> rextents = 0
> uuid = eac0a48b-4dff-41c3-b2cc-e110bd5c3ff8
> logstart = 32772
> rootino = 256
> rbmino = 257
> rsumino = 258
> rextsize = 8
> agblocks = 4142
> agcount = 8
> rbmblocks = 0
> logblocks = 1000
> versionnum = 0x2084
> sectsize = 512
> inodesize = 256
> inopblock = 32
> fname = "\000\000\000\000\000\000\000\000\000\000\000\000"
> blocklog = 13
> sectlog = 9
> inodelog = 8
> inopblog = 5
> agblklog = 13
> rextslog = 0
> inprogress = 0
> imax_pct = 25
> icount = 64
> ifree = 61
> fdblocks = 32096
> frextents = 0
> uquotino = 0
> pquotino = 0
> qflags = 0
> flags = 0
> shared_vn = 0
> inoalignmt = 1
> unit = 0
> width = 0
> dirblklog = 0
> xfs_db: agf 0
> xfs_db: print
> magicnum = 0x58414746
> versionnum = 1
> seqno = 0
> length = 4142
> bnoroot = 1
> cntroot = 2
> bnolevel = 1
> cntlevel = 1
> flfirst = 0
> fllast = 3
> flcount = 4
> freeblks = 4132
> longest = 4132
> xfs_db: agi 0
> xfs_db: print
> magicnum = 0x58414749
> versionnum = 1
> seqno = 0
> length = 4142
> count = 64
> root = 3
> level = 1
> freecount = 61
> newino = 256
> dirino = null
> unlinked[0-63] =
> xfs_db: quit
> root@cyan:~#
>
> > Mount the file system
> > run od commands and xfs_db command again
> > save output
>
> root@cyan:~# od -c -N 8 -j 512 /dev/sdb1
> 0001000   X   A   G   F  \0  \0  \0 001
> 0001010
> root@cyan:~# od -c -N 8 -j 1024 /dev/sdb1
> 0002000   X   A   G   I  \0  \0  \0 001
> 0002010
> root@cyan:~# xfs_db -r /dev/sdb1
> xfs_db: sb 0
> xfs_db: print
> magicnum = 0x58465342
> blocksize = 8192
> dblocks = 33130
> rblocks = 0
> rextents = 0
> uuid = eac0a48b-4dff-41c3-b2cc-e110bd5c3ff8
> logstart = 32772
> rootino = 256
> rbmino = 257
> rsumino = 258
> rextsize = 8
> agblocks = 4142
> agcount = 8
> rbmblocks = 0
> logblocks = 1000
> versionnum = 0x2084
> sectsize = 512
> inodesize = 256
> inopblock = 32
> fname = "\000\000\000\000\000\000\000\000\000\000\000\000"
> blocklog = 13
> sectlog = 9
> inodelog = 8
> inopblog = 5
> agblklog = 13
> rextslog = 0
> inprogress = 0
> imax_pct = 25
> icount = 64
> ifree = 61
> fdblocks = 32096
> frextents = 0
> uquotino = 0
> pquotino = 0
> qflags = 0
> flags = 0
> shared_vn = 0
> inoalignmt = 1
> unit = 0
> width = 0
> dirblklog = 0
> xfs_db: agf 0
> xfs_db: print
> magicnum = 0x58414746
> versionnum = 1
> seqno = 0
> length = 4142
> bnoroot = 1
> cntroot = 2
> bnolevel = 1
> cntlevel = 1
> flfirst = 0
> fllast = 3
> flcount = 4
> freeblks = 4132
> longest = 4132
> xfs_db: agi 0
> xfs_db: print
> magicnum = 0x58414749
> versionnum = 1
> seqno = 0
> length = 4142
> count = 64
> root = 3
> level = 1
> freecount = 61
> newino = 256
> dirino = null
> unlinked[0-63] =
> xfs_db:
>
> > Now do some FS activity
> > run tod command and xfs_sb commands again
> > save output.
>
> root@cyan:~#
> 0001000  \0  \0  \0  \0 377 377 377 377
> 0001010
> root@cyan:~# od -c -N 8 -j 1024 /dev/sdb1
> 0002000   X   A   G   I  \0  \0  \0 001
> 0002010
> root@cyan:~# xfs_db -r /dev/sdb1
> xfs_db: sb 0
> xfs_db: print
> magicnum = 0x58465342
> blocksize = 8192
> dblocks = 33130
> rblocks = 0
> rextents = 0
> uuid = 89cb7e3c-c0cc-4a42-8013-aef1f692b80b
> logstart = 32772
> rootino = 256
> rbmino = 257
> rsumino = 258
> rextsize = 8
> agblocks = 4142
> agcount = 8
> rbmblocks = 0
> logblocks = 1000
> versionnum = 0x2084
> sectsize = 512
> inodesize = 256
> inopblock = 32
> fname = "\000\000\000\000\000\000\000\000\000\000\000\000"
> blocklog = 13
> sectlog = 9
> inodelog = 8
> inopblog = 5
> agblklog = 13
> rextslog = 0
> inprogress = 0
> imax_pct = 25
> icount = 2240
> ifree = 202
> fdblocks = 8423
> frextents = 0
> uquotino = 0
> pquotino = 0
> qflags = 0
> flags = 0
> shared_vn = 0
> inoalignmt = 1
> unit = 0
> width = 0
> dirblklog = 0
> xfs_db: agf 0
> xfs_db: print
> magicnum = 0
> versionnum = 4294967295
> seqno = 0
> length = 0
> bnoroot = 2966461184
> cntroot = 16580607
> bnolevel = 16580607
> cntlevel = 0
> flfirst = 2147483648
> fllast = 16777216
> flcount = 3223092738
> freeblks = 16580607
> longest = 32258
> xfs_db:agi 0
> xfs_db: print
> magicnum = 0x58414749
> versionnum = 1
> seqno = 0
> length = 4142
> count = 448
> root = 3
> level = 1
> freecount = 0
> newino = 122016
> dirino = null
> unlinked[0-63] =
> xfs_db:
>
> > Send all the output to us.
>
> i hope it is ok to post it here - i think it's not too much - but if
> anyone does not like those big debugging mails i can also upload
> them to a ftp accessable place in the future
>
> > This should tell us where we need to start fixing things first.
>
> > I suspect we will need to find an alpha around someplace to actually
> > get some of this stuff debugged.
>
> i'll update the alpha to the latest kernel now and recheck that it
> is still there (you never know :-) ... also keep in mind: compiler
> bugs are possible too ... it's gcc 2.95.2 which has problems on
> intel too but seems to work fine on the ppc - but this kind
> of problem does not really look like a compiler bug to me
> on the other side
>
> good luck
>
> t
>
> --
> thomas.graichen@innominate.com
> technical director                                       innominate AG
> clustering & security                             the linux architects
> tel: +49-30-308806-13   fax: -77            http://www.innominate.com


From owner-linux-xfs@oss.sgi.com Thu Nov 30 13:52:31 2000
Received:  by oss.sgi.com id <S553909AbQK3VwL>;
	Thu, 30 Nov 2000 13:52:11 -0800
Received: from pneumatic-tube.sgi.com ([204.94.214.22]:15720 "EHLO
        pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP
	id <S553906AbQK3Vv7>; Thu, 30 Nov 2000 13:51:59 -0800
Received: from nodin.corp.sgi.com (fddi-nodin.corp.sgi.com [198.29.75.193]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id OAA06762; Thu, 30 Nov 2000 14:00:02 -0800 (PST)
	mail_from (nobody@info.engr.sgi.com)
Received: from info.engr.sgi.com (info.engr.sgi.com [192.26.80.216]) by nodin.corp.sgi.com (980427.SGI.8.8.8/980728.SGI.AUTOCF) via ESMTP id NAA00047; Thu, 30 Nov 2000 13:51:29 -0800 (PST)
Received: (from nobody@localhost)
	by info.engr.sgi.com (SGI-8.9.3/8.9.3) id NAA93605;
	Thu, 30 Nov 2000 13:50:12 -0800 (PST)
Date:   Thu, 30 Nov 2000 13:50:12 -0800 (PST)
Message-Id: <200011302150.NAA93605@info.engr.sgi.com>
X-Pv-Incident: 808315 
webPV:  info.engr 
webExec: bugs_update,pvincident 
Reply-To: sgi.bugs.xfs@fido.engr.sgi.com
From:   pv@relay.sgi.com (cvduser@csd.sgi.com)
Subject: UPDATE 808315 - Full file systems can become corrupted with XFS Linux.
To:     nb@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=808315

 Status : closed                       Priority : 2                         
 Assigned Engineer : nb                Submitter : cattelan                 
 Opened Date : 11/20/00               *Modified User : cvduser              
*Modified User Domain : csd           *Customer Viewable Description :
WITHHELD: linux bug
*Description :
Linux XFS may corrupt file system when disk si filled.

Very large write requests causes portions of the user data IO path
to continue writing beyond the end of an allocted extent thus over-writting
the start of the next AG. 

This usally show up as trashed secondary super blocks and probably
other data structures in the AG.

==========================
ADDITIONAL INFORMATION (UPDATE)
From: cvduser@csd (BWX)
Date: Nov 30 2000 01:50:11PM
==========================

Linux bug. No customer viewable description at this time.
kroy

From owner-linux-xfs@oss.sgi.com Thu Nov 30 14:07:41 2000
Received:  by oss.sgi.com id <S553911AbQK3WHc>;
	Thu, 30 Nov 2000 14:07:32 -0800
Received: from deliverator.sgi.com ([204.94.214.10]:37232 "EHLO
        deliverator.sgi.com") by oss.sgi.com with ESMTP id <S553907AbQK3WHU>;
	Thu, 30 Nov 2000 14:07:20 -0800
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 OAA17997
	for <linux-xfs@oss.sgi.com>; Thu, 30 Nov 2000 14:07:18 -0800 (PST)
	mail_from (nathans@wobbly.melbourne.sgi.com)
Received: from wobbly.melbourne.sgi.com (wobbly.melbourne.sgi.com [134.14.55.135]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id JAA23206; Fri, 1 Dec 2000 09:04:47 +1100
Received: (from nathans@localhost) by wobbly.melbourne.sgi.com (980427.SGI.8.8.8/980728.SGI.AUTOCF) id JAA72084; Fri, 1 Dec 2000 09:04:46 +1100 (EDT)
From:   "Nathan Scott" <nathans@wobbly.melbourne.sgi.com>
Message-Id: <10012010904.ZM174461@wobbly.melbourne.sgi.com>
Date:   Fri, 1 Dec 2000 09:04:45 -0400
In-Reply-To: Thomas Graichen <news-innominate.list.sgi.xfs@innominate.de>
        "Re: stress test on ppc" (Nov 30,  9:01am)
References: <news2mail-8uecj0$i5e$1@mate.bln.innominate.de> 
	<10011221244.ZM158790@wobbly.melbourne.sgi.com> 
	<news2mail-8vlq0n$hiu$2@mate.bln.innominate.de> 
	<10011261336.ZM166460@wobbly.melbourne.sgi.com> 
	<news2mail-8vt5ub$dhv$3@mate.bln.innominate.de> 
	<10011281048.ZM165042@wobbly.melbourne.sgi.com> 
	<news2mail-9001u3$n0b$2@mate.bln.innominate.de> 
	<10011290940.ZM169800@wobbly.melbourne.sgi.com> 
	<news2mail-902hr6$307$1@mate.bln.innominate.de> 
	<10011301040.ZM164128@wobbly.melbourne.sgi.com> 
	<news2mail-90550o$3u0$3@mate.bln.innominate.de>
X-Mailer: Z-Mail (3.2.3 08feb96 MediaMail)
To:     Thomas Graichen <graichen@innominate.de>,
        thomas.graichen@innominate.de, linux-xfs@oss.sgi.com
Subject: Re: stress test on ppc
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 Thomas,

On Nov 30,  9:01am, Thomas Graichen wrote:
> Subject: Re: stress test on ppc
> ...
> > ok, so the problem is in either mkfs or xfs_db.  after mkfs, run:
> ...
> so it looks like xfs_db
> 
> > lemme know.  (at the same time, could you send the unfiltered
> > "xfs_db -r -c sb -c p /dev/hda9" output also?)
> 

as Russell pointed out, this is really odd - some fields
are displayed correctly, others are off with the pixies.
I can't see any obvious pattern either... the only thing
I can think of is that xfs_db is doing some deep and
meaningful bit shifting to come up with these numbers -
perhaps this is a compiler issue (we had problems before
with the xfs_high/lowbit routines on non-2.91.66 compilers,
perhaps this is true on ppc also - its probably worthwhile
trying that compiler to build userspace too if you can).

> ppc:~ # xfs_db -r -c sb -c p /dev/hda9
> magicnum = 0x58465342
> blocksize = 524288
> dblocks = 105553116266496
> rblocks = 0
> rextents = 0
> uuid = bc3a44f0-947a-4ebe-964e-5d237161432b
> logstart = 262148
> rootino = 72057594037927936
> rbmino = 129
> rsumino = 4683743612465315840
> rextsize = 16
> agblocks = 196608
> agcount = 8
> rbmblocks = 0
> logblocks = 1200
> versionnum = 0x2084
> sectsize = 64
> inodesize = 256
> inopblock = 2048
> fname = "\000\000\000\000\000\000\000\000\000\000\000\000"
> blocklog = 12
> sectlog = 144
> inodelog = 8
> inopblog = 32
> agblklog = 16
> rextslog = 0
> inprogress = 0
> imax_pct = 152
> icount = 64
> ifree = 13546827679130451968
> fdblocks = 391980
> frextents = 0
> uquotino = 0
> pquotino = 0
> qflags = 0
> flags = 0
> shared_vn = 0
> inoalignmt = 1073741824
> unit = 0
> width = 0
> dirblklog = 0
> ppc:~ #
> 

cheers.

-- 
Nathan

From owner-linux-xfs@oss.sgi.com Thu Nov 30 15:59:32 2000
Received:  by oss.sgi.com id <S553919AbQK3X7W>;
	Thu, 30 Nov 2000 15:59:22 -0800
Received: from alsa.jcu.cz ([160.217.1.49]:61959 "EHLO alsa.alsa-project.org")
	by oss.sgi.com with ESMTP id <S553916AbQK3X7I>;
	Thu, 30 Nov 2000 15:59:08 -0800
Received: from localhost (andy@localhost)
	by alsa.alsa-project.org (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id AAA16533
	for <linux-xfs@oss.sgi.com>; Fri, 1 Dec 2000 00:58:45 +0100
Date:   Fri, 1 Dec 2000 00:58:44 +0100 (CET)
From:   Andy Lo A Foe <andy@alsa-project.org>
To:     linux-xfs@oss.sgi.com
Subject: latest CVS hangs on boot
Message-ID: <Pine.LNX.4.21.0012010056270.15506-100000@alsa.alsa-project.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

Hello,

Latest CVS tree from XFS hangs at boot right after IDE channel detection,
but before IDE device probing (I think). Is this a known bug? Plain test11
works fine, and so does an earlier -XFS-test10 tree. I can provide
debugging output, if needed..

-andy


From owner-linux-xfs@oss.sgi.com Thu Nov 30 16:20:02 2000
Received:  by oss.sgi.com id <S553925AbQLAATw>;
	Thu, 30 Nov 2000 16:19:52 -0800
Received: from pneumatic-tube.sgi.com ([204.94.214.22]:62585 "EHLO
        pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP
	id <S553921AbQLAATi>; Thu, 30 Nov 2000 16:19:38 -0800
Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id QAA01735
	for <linux-xfs@oss.sgi.com>; Thu, 30 Nov 2000 16:27:41 -0800 (PST)
	mail_from (cattelan@thebarn.com)
Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id SAA7779208; Thu, 30 Nov 2000 18:18:20 -0600 (CST)
Received: from gibble.americas.sgi.com (gibble.americas.sgi.com [128.162.195.80]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id SAA74048; Thu, 30 Nov 2000 18:18:20 -0600 (CST)
Received: from thebarn.com (localhost [127.0.0.1])
	by gibble.americas.sgi.com (8.11.0/8.10.1) with ESMTP id eB10IKj28326;
	Thu, 30 Nov 2000 18:18:20 -0600
Message-ID: <3A26EE4B.13B84B9@thebarn.com>
Date:   Thu, 30 Nov 2000 18:18:20 -0600
From:   Russell Cattelan <cattelan@thebarn.com>
X-Mailer: Mozilla 4.75 [en] (X11; U; Linux 2.4.0-whipme11 i686)
X-Accept-Language: en
MIME-Version: 1.0
To:     Andy Lo A Foe <andy@alsa-project.org>
CC:     linux-xfs@oss.sgi.com
Subject: Re: latest CVS hangs on boot
References: <Pine.LNX.4.21.0012010056270.15506-100000@alsa.alsa-project.org>
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

Andy Lo A Foe wrote:

> Hello,
>
> Latest CVS tree from XFS hangs at boot right after IDE channel detection,
> but before IDE device probing (I think). Is this a known bug? Plain test11
> works fine, and so does an earlier -XFS-test10 tree. I can provide
> debugging output, if needed..

Not as of yet.

What else can you tell us.

Can you break into kdb?
if so a back trace would be a good starting point.


>
>
> -andy


From owner-linux-xfs@oss.sgi.com Thu Nov 30 16:55:22 2000
Received:  by oss.sgi.com id <S553929AbQLAAzN>;
	Thu, 30 Nov 2000 16:55:13 -0800
Received: from deliverator.sgi.com ([204.94.214.10]:44079 "EHLO
        deliverator.sgi.com") by oss.sgi.com with ESMTP id <S553926AbQLAAyv>;
	Thu, 30 Nov 2000 16:54:51 -0800
Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id QAA17803
	for <linux-xfs@oss.sgi.com>; Thu, 30 Nov 2000 16:54:50 -0800 (PST)
	mail_from (cattelan@thebarn.com)
Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id SAA7728723; Thu, 30 Nov 2000 18:52:18 -0600 (CST)
Received: from gibble.americas.sgi.com (gibble.americas.sgi.com [128.162.195.80]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id SAA14969; Thu, 30 Nov 2000 18:52:18 -0600 (CST)
Received: from thebarn.com (localhost [127.0.0.1])
	by gibble.americas.sgi.com (8.11.0/8.10.1) with ESMTP id eB10qHj28517;
	Thu, 30 Nov 2000 18:52:17 -0600
Message-ID: <3A26F641.45226EF7@thebarn.com>
Date:   Thu, 30 Nov 2000 18:52:17 -0600
From:   Russell Cattelan <cattelan@thebarn.com>
X-Mailer: Mozilla 4.75 [en] (X11; U; Linux 2.4.0-whipme11 i686)
X-Accept-Language: en
MIME-Version: 1.0
To:     utz lehmann <xfs@s2y4n2c.de>
CC:     linux-xfs@oss.sgi.com
Subject: Re: kernelcrash during root filesystem recovery
References: <20001130202247.A24118@s2y4n2c.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

utz lehmann wrote:

Hmm not good.
We are going to need a bit more go to on.

Can you get a backtrace from kdb?

If you could hook up to a serial console that would
help in capturing the output.


> hi
>
> i found a bug in yesterdays (2000-11-29) kernel (the test11 one).
>
> i had powered off my computer without a clean shutdown. i do this very
> often, no problems since month with xfs.
>
> the kernel traped into kdb while recovering the xfs root filesystem. i write
> the messages down from the screen, maybe there are typos:
>
> XFS: WARNING: recovery required on readonly filesystem.
>
> XFS: write access will be enabled recovery.
>
> Staring XFS recovery on filesystem: ide0 (3,6) (dev:3/6)
> Unable to handle kernel NULL pointer dereference at virtual address 00000008
>  printing eip:
> c016482b
> *pde = 00000000
>
> Entering kdb (currect=0xc125c000, pid1) Panic: Oops
> due to panic @ 0xc016482b
> eax = 0x00000000 ebx = 0xc12c3460 ecx = 0xc12c3460 edx = 0x00000000
> esi = 0xc12c0e60 edi = 0x00000000 esp = 0xc125d940 eip = 0xc016482b
> ebp = 0x00000000 xss = 0x00000018 xcs = 0x00000010 eflags = 0x00010246
> xds = 0x00000018 xes = 0x00000018 origeax = 0xffffffff &regs = 0xc125d90c
>
> i rebooted the machine with the same result.
> rebooting with a kernel from 2000-11-14 works with no problems.
>
> i made some tests with the buggy kernel:
>
> clean shutdown works.
> hardreset after "sync" works.
> hardreset after booting without sync works.
> hardreset during booting works.
> hardreset during writing (cp -av /usr/src/linux /tmp) triggers the bug.
> 4 times it traped into kdb, 1 time the kernel hangs.
>
> booting with the older kernel always works.
>
> my system:
> K6-500, 128MB
> xfs root filesystem on a ide disk.
>
> hope that helps.
>
> utz


From owner-linux-xfs@oss.sgi.com Thu Nov 30 17:22:22 2000
Received:  by oss.sgi.com id <S553933AbQLABWN>;
	Thu, 30 Nov 2000 17:22:13 -0800
Received: from pneumatic-tube.sgi.com ([204.94.214.22]:9735 "EHLO
        pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP
	id <S553930AbQLABWF>; Thu, 30 Nov 2000 17:22:05 -0800
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 RAA03920
	for <linux-xfs@oss.sgi.com>; Thu, 30 Nov 2000 17:30:07 -0800 (PST)
	mail_from (ajag@fudge.melbourne.sgi.com)
Received: from fudge.melbourne.sgi.com (fudge.melbourne.sgi.com [134.14.55.184]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id MAA24515; Fri, 1 Dec 2000 12:20:47 +1100
Received: (from ajag@localhost) by fudge.melbourne.sgi.com (980427.SGI.8.8.8/980728.SGI.AUTOCF) id MAA38816; Fri, 1 Dec 2000 12:20:46 +1100 (EST)
Date:   Fri, 1 Dec 2000 12:20:46 +1100
From:   Andrew Gildfind <ajag@fudge.melbourne.sgi.com>
To:     thomas.graichen@innominate.de
Cc:     linux-xfs@oss.sgi.com
Subject: Re: stress test on ppc
Message-ID: <20001201122045.G32822@fudge.melbourne.sgi.com>
References: <news2mail-8uecj0$i5e$1@mate.bln.innominate.de> <news-innominate.list.sgi.xfs@innominate.de> <10011101103.ZM113097@wobbly.melbourne.sgi.com> <20001110094151.C333@ysabell> <10011110006.ZM127189@wobbly.melbourne.sgi.com> <news2mail-8uo7od$4lt$1@mate.bln.innominate.de> <10011141059.ZM128320@wobbly.melbourne.sgi.com> <news2mail-8utlfv$8iu$1@mate.bln.innominate.de>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 1.0us
In-Reply-To: <news2mail-8utlfv$8iu$1@mate.bln.innominate.de>; from news-innominate.list.sgi.xfs@innominate.de on Wed, Nov 15, 2000 at 09:37:03AM +0000
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, Nov 15, 2000 at 09:37:03AM +0000, Thomas Graichen wrote:
> "Nathan Scott" <nathans@wobbly.melbourne.sgi.com> wrote:
> > hi Thomas,
> 
> > On Nov 13,  8:11am, Thomas Graichen wrote:
> >> Subject: Re: stress test on ppc
> >> ...
> >> > ah - I think I see whats happened - there's two -ne tests like
> >> > this & last time I only fixed one ... hopefully its fixed now
> >> > (as of two minutes ago).
> >> 
> >> ok - reran the tests with your fixes - the current results (with all
> >> the failed .out and .out.bad files) can be found at
> >> 
> >>   http://innominate.org/~graichen/projects/xfs/ppc/ppc.13-11-2000.tgz
> >> 
> 
> > ok, some progress - looks like the scratch device problem is
> > resolved and test 002 is fixed - great!
> 
> > 004 - this looks like a 32 bit number overflow in the xfs_db
> > "freesp" command, i'll need to investigate a bit more.
> 
> > 018 - ??? no idea - looks like theres a bunch of unexpected
> > records in the log for some reason?  bizarre.
> 
> > 020 - attribute syscall code not there in ppc?
> 
> > 026/027/028/046/047 - a reoccurence of the dump/restore problems
> > from Marcelo, Tim/Ivan?  or new ones?
> > also group "nobody" assumed to exist, but doesn't.  can we change
> > the way the test works, Tim?  or exit cleanly if no "nobody" grp?
> > or use numeric gids instead of named groups perhaps?
> 
> > 032 - hmmm... could be a problem in mount(8) code which we use
> > for mkfs.xfs so that it doesn't overwrite other filesystems -
> > can you see whether mount on ppc can autodetect (i.e. mount
> > without "-t" a filesystem created by mkfs.minix on ppc?  thanks)
> 
> will try that
> 
> the current results (with fresh kernel and fresh cmd) are at
> 
>   http://innominate.org/~graichen/procjects/xfs/ppc.15-11-2000.tgz
> 
> but they are at a rough view not really different - by maybe you
> find something in them
> 
> i'm also not really shure about the syscall thing: i added sys_attrctl
> to arch/ppc/kernel/misc.S (where the sys_call_table on ppc is - it's
> not in entry.S here) also as nr 250 (padded with sys_ni_syscall's)
> and also added it to unistd.h and recompiled and installed
> everything and still get things like
> 
>   attr_set: Bad address
> 
> which looks like it does still not work - is there any other place i
> have to add an entry for this new syscall?
> 
> a lot of thanks in advance
> 

Hi Thomas,

Could you put a printk at the start of the sys_attrctl function defined
in linux/fs/stat.c, and rerun the QA test 020, or drive the attribute code
directly using xfs_attr, and check whether the printk actually gets called.

If it doesn't then we know for sure it's the syscall that isn't hooked up
correctly. unistd.h and entry.S looked like the only places which needed
to be changed but I may have missed something. If it does hit the the attribute
syscall, then there's a more serious problem somewhere else in the code.

ie can you update sys_attrctl with something like the following:

asmlinkage long sys_attrctl(attr_obj_t obj, int type, attr_op_t *ops, int count)
{
	int		error = 0;
	struct inode	*inode;
	struct dentry	*dentry;
	struct file	*f = NULL;
	struct nameidata nd;

+	/* PUT PRINTK HERE */
+	printk("sys_attrctl: attribute system call reached\n");
	
	if (count <= 0)
		return -EINVAL;

	...
}


Andrew

--
Andrew Gildfind - R&D Software Engineer - SGI PTG Melbourne Australia
email: ajag@melbourne.sgi.com - work: +61.3.9834.8200 home: +61.3.9421.5335

From owner-linux-xfs@oss.sgi.com Thu Nov 30 18:05:13 2000
Received:  by oss.sgi.com id <S553937AbQLACEx>;
	Thu, 30 Nov 2000 18:04:53 -0800
Received: from pneumatic-tube.sgi.com ([204.94.214.22]:38926 "EHLO
        pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP
	id <S553934AbQLACEd>; Thu, 30 Nov 2000 18:04:33 -0800
Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.55.149]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id SAA08865
	for <linux-xfs@oss.sgi.com>; Thu, 30 Nov 2000 18:12:35 -0800 (PST)
	mail_from (nathans@snort.melbourne.sgi.com)
Received: (from nathans@localhost)
	by snort.melbourne.sgi.com (SGI-8.9.3/8.9.3) id NAA89039
	for linux-xfs@oss.sgi.com; Fri, 1 Dec 2000 13:03:14 +1100 (EST)
Date:   Fri, 1 Dec 2000 13:03:14 +1100 (EST)
From:   Nathan Scott <nathans@snort.melbourne.sgi.com>
Message-Id: <200012010203.NAA89039@snort.melbourne.sgi.com>
To:     linux-xfs@oss.sgi.com
Subject: TAKE - quota
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing

This changes the ondisk format for XFS quota - like the rest of
XFS, dquots are now big-endian only.  If you've been trying out
the usrquota mount option and have quota enabled (use the updated
cmd/quota/repquota -asv to tell), then you'll need to delete your
current quota information (cmd/quota/quotaoff -d) and start again.
User quota seem to be quite functional now, but not group quota at
this stage.

cheers.

Modid:  2.4.x-xfs:slinx:79595a
Date:  Thu Nov 30 17:52:45 PST 2000
Workarea:  snort:/build4/nathans/quota-xfs
Author:  nathans

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

cmd/xfs/db/check.c - 1.59
cmd/xfs/logprint/log_print_all.c - 1.4
linux/fs/xfs/xfs_dquot.c - 1.54
linux/fs/xfs/xfs_dquot_item.c - 1.21
linux/fs/xfs/xfs_log_recover.c - 1.197
linux/fs/xfs/xfs_qm.c - 1.60
linux/fs/xfs/xfs_qm.h - 1.17
linux/fs/xfs/xfs_qm_syscalls.c - 1.49
linux/fs/xfs/xfs_quota_priv.h - 1.16
linux/fs/xfs/xfs_trans_dquot.c - 1.30
linux/fs/xfs/xfsidbg.c - 1.155
	- ondisk dquots are now big-endian only.


From owner-linux-xfs@oss.sgi.com Thu Nov 30 20:19:03 2000
Received:  by oss.sgi.com id <S553943AbQLAESy>;
	Thu, 30 Nov 2000 20:18:54 -0800
Received: from pneumatic-tube.sgi.com ([204.94.214.22]:10014 "EHLO
        pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP
	id <S553940AbQLAESe>; Thu, 30 Nov 2000 20:18:34 -0800
Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.55.149]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id UAA03169
	for <linux-xfs@oss.sgi.com>; Thu, 30 Nov 2000 20:26:25 -0800 (PST)
	mail_from (nathans@snort.melbourne.sgi.com)
Received: (from nathans@localhost)
	by snort.melbourne.sgi.com (SGI-8.9.3/8.9.3) id PAA16061
	for linux-xfs@oss.sgi.com; Fri, 1 Dec 2000 15:17:04 +1100 (EST)
Date:   Fri, 1 Dec 2000 15:17:04 +1100 (EST)
From:   Nathan Scott <nathans@snort.melbourne.sgi.com>
Message-Id: <200012010417.PAA16061@snort.melbourne.sgi.com>
To:     linux-xfs@oss.sgi.com
Subject: TAKE - physmem
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.4.x-xfs:slinx:79600a
Date:  Thu Nov 30 20:16:09 PST 2000
Workarea:  snort:/build4/nathans/linux-xfs
Author:  nathans

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

linux/fs/xfs/linux/xfs_globals.c - 1.20
linux/fs/xfs/linux/xfs_globals.h - 1.4
	- avoid implicit type cast from kernels view of totalram.


From owner-linux-xfs@oss.sgi.com Thu Nov 30 23:35:57 2000
Received:  by oss.sgi.com id <S553949AbQLAHfr>;
	Thu, 30 Nov 2000 23:35:47 -0800
Received: from edge.coltex.nl ([194.151.97.115]:45328 "EHLO mail.coltex.nl")
	by oss.sgi.com with ESMTP id <S553946AbQLAHf1>;
	Thu, 30 Nov 2000 23:35:27 -0800
Received: from auto-nb1.xs4all.nl (auto-nb1.coltex.nl [10.0.1.171])
	by mail.coltex.nl (8.10.0/8.9.3) with ESMTP id eB17ZHu24891;
	Fri, 1 Dec 2000 08:35:18 +0100
Message-Id: <4.3.2.7.2.20001201083208.029630b8@pop.xs4all.nl>
X-Sender: knuffie@pop.xs4all.nl (Unverified)
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
Date:   Fri, 01 Dec 2000 08:33:09 +0100
To:     Andy Lo A Foe <andy@alsa-project.org>, linux-xfs@oss.sgi.com
From:   Seth Mos <knuffie@xs4all.nl>
Subject: Re: latest CVS hangs on boot
In-Reply-To: <Pine.LNX.4.21.0012010056270.15506-100000@alsa.alsa-project
 .org>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing

At 00:58 1-12-2000 +0100, Andy Lo A Foe wrote:
>Hello,
>
>Latest CVS tree from XFS hangs at boot right after IDE channel detection,
>but before IDE device probing (I think). Is this a known bug? Plain test11
>works fine, and so does an earlier -XFS-test10 tree. I can provide
>debugging output, if needed..
>
>-andy

What IDE controller do you have, I have no problems on a Intel BX 
controller or a AMD 751 Chipset.

Seth
--
Seth
Has anybody seen my lightbulb?
I _really_ need some light here.


From owner-linux-xfs@oss.sgi.com Thu Nov 30 23:54:17 2000
Received:  by oss.sgi.com id <S553948AbQLAHyH>;
	Thu, 30 Nov 2000 23:54:07 -0800
Received: from hermes.mixx.net ([212.84.196.2]:21004 "HELO hermes.mixx.net")
	by oss.sgi.com with SMTP id <S553944AbQLAHxk>;
	Thu, 30 Nov 2000 23:53:40 -0800
Received: from mate.bln.innominate.de (cerberus.berlin.innominate.de [212.84.234.251])
	by hermes.mixx.net (Postfix) with ESMTP id 2DC3AF80D
	for <linux-xfs@oss.sgi.com>; Fri,  1 Dec 2000 08:53:38 +0100 (CET)
Received: by mate.bln.innominate.de (Postfix, from userid 9)
	id E159A2CAA2; Fri,  1 Dec 2000 08:53:37 +0100 (CET)
From:   Thomas Graichen <news-innominate.list.sgi.xfs@innominate.de>
Reply-To: Thomas Graichen <graichen@innominate.de>
X-Newsgroups: innominate.list.sgi.xfs
Subject: agf corruption on the alpha
Date:   1 Dec 2000 07:53:37 GMT
Organization: innominate AG, Berlin, Germany
Lines:  137
Distribution: local
Message-ID: <news2mail-907le1$27r$1@mate.bln.innominate.de>
References: <news2mail-8uecj0$i5e$1@mate.bln.innominate.de>   <10011281048.ZM165042@wobbly.melbourne.sgi.com>   <news2mail-9001u3$n0b$2@mate.bln.innominate.de>   <10011290940.ZM169800@wobbly.melbourne.sgi.com>   <news2mail-902hr6$307$1@mate.bln.innominate.de> <10011301040.ZM164128@wobbly.melbourne.sgi.com> <news2mail-90550o$3u0$3@mate.bln.innominate.de> <3A267EBE.52E6CC95@thebarn.com> <news2mail-9061lo$dc3$3@mate.bln.innominate.de> <3A26C307.5FCCC673@thebarn.com>
Reply-To: thomas.graichen@innominate.de
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
X-Trace: mate.bln.innominate.de 975657217 2299 10.0.0.31 (1 Dec 2000 07:53:37 GMT)
X-Complaints-To: news@innominate.de
User-Agent: tin/1.4.4-20000803 ("Vet for the Insane") (UNIX) (Linux/2.4.0-XFS-test10 (i686))
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

[i changed the subject a bit ... this is no longer ppc :-]

Russell Cattelan <cattelan@thebarn.com> wrote:
> Thomas Graichen wrote:

> Ok good...
> So everything thing looks good right after mkfs and the mount.

> The problem does appear to the first write to the super block.
> as shown by
> od -c -N 8 -j 512 /dev/sdb1
> not reporting XAGF

> My best guess that this point as to what it happening:
> We have added valid bits to the page structure, with each
> bit representing 1 512 byte block.
> It appears that someplace in the pagebuf  math the basic unit
> is now 1024, rather than 512.
> Since the page size has doubled it does make sense the BB size has
> doubled.
> So now the trick is to find the problem.

> Lets verify the problem first
> just before the generic_make_request function in page_buf.c:
> _pagebuf_page_io
>                         printk ("_pagebuf page io calling gmk itr %d bh
> 0x%p block %d size %ld\t",itr,

> psync->bh[itr],psync->bh[itr]->b_blocknr,psync->bh[itr]->b_size);
>                         { int i;
>                         for(i=0; i < 4; i++){
>                           printk("%c",psync->bh[itr]->b_data[i]);
>                         }
>                         printk("\n");
>                         }

> The numbers we will be interested in will be the b_ blocknr and the
> b_bsize.

ok - this is what i got for

root@cyan:/var/log# mkfs -t xfs -f -b size=8192 /dev/sdb1
meta-data=/dev/sdb1              isize=256    agcount=8, agsize=4142 blks
data     =                       bsize=8192   blocks=33130, imaxpct=25
         =                       sunit=0      swidth=0 blks, unwritten=0
naming   =version 2              bsize=8192  
log      =internal log           bsize=8192   blocks=1000
realtime =none                   extsz=65536  blocks=0, rtextents=0
root@cyan:/var/log# mount /dev/sdb1 /mnt
root@cyan:/var/log# echo test > /mnt/testfile
root@cyan:/var/log# umount /mnt
root@cyan:/var/log#

after a fresh reload of the modules

<6>page_buf cache Copyright (c) 2000 Silicon Graphics, Inc.
<6>XFS filesystem Copyright (c) 2000 Silicon Graphics, Inc.
<4>_pagebuf page io calling gmk itr 0 bh 0xfffffc00054f6600 block 0 size 1024	
<4>_pagebuf page io calling gmk itr 0 bh 0xfffffc00054f6600 block 530079 size 512	
<4>Start mounting filesystem: sd(8,17)
<4>_pagebuf page io calling gmk itr 0 bh 0xfffffc00054f6600 block 265152 size 1024	
<4>_pagebuf page io calling gmk itr 0 bh 0xfffffc00054f6600 block 281151 size 1024	þíº¾
<4>_pagebuf page io calling gmk itr 0 bh 0xfffffc00054f6600 block 273151 size 1024	
<4>_pagebuf page io calling gmk itr 0 bh 0xfffffc00054f6600 block 269151 size 1024	
<4>_pagebuf page io calling gmk itr 0 bh 0xfffffc00054f6600 block 267151 size 1024	
<4>_pagebuf page io calling gmk itr 0 bh 0xfffffc00054f6600 block 266151 size 1024	
<4>_pagebuf page io calling gmk itr 0 bh 0xfffffc00054f6600 block 265651 size 1024	
<4>_pagebuf page io calling gmk itr 0 bh 0xfffffc00054f6600 block 265401 size 1024	
<4>_pagebuf page io calling gmk itr 0 bh 0xfffffc00054f6600 block 265276 size 1024	
<4>_pagebuf page io calling gmk itr 0 bh 0xfffffc00054f6600 block 265214 size 1024	
<4>_pagebuf page io calling gmk itr 0 bh 0xfffffc00054f6600 block 265183 size 1024	
<4>_pagebuf page io calling gmk itr 0 bh 0xfffffc00054f6600 block 265167 size 1024	
<4>_pagebuf page io calling gmk itr 0 bh 0xfffffc00054f6600 block 265159 size 1024	
<4>_pagebuf page io calling gmk itr 0 bh 0xfffffc00054f6600 block 265155 size 1024	
<4>_pagebuf page io calling gmk itr 0 bh 0xfffffc00054f6600 block 265153 size 1024	
<4>_pagebuf page io calling gmk itr 0 bh 0xfffffc00054f6600 block 265154 size 1024	
<4>_pagebuf page io calling gmk itr 0 bh 0xfffffc00054f6600 block 265152 size 1024	þíº¾
<4>_pagebuf page io calling gmk itr 0 bh 0xfffffc00054f6600 block 265152 size 1024	þíº¾
<4>_pagebuf page io calling gmk itr 0 bh 0xfffffc00054f6600 block 265153 size 1024	
<4>_pagebuf page io calling gmk itr 0 bh 0xfffffc00054f6600 block 265152 size 1024	
<4>_pagebuf page io calling gmk itr 0 bh 0xfffffc00054f6600 block 265153 size 1024	þíº¾
<4>_pagebuf page io calling gmk itr 0 bh 0xfffffc00054f6600 block 265154 size 8192	þíº¾
<4>_pagebuf page io calling gmk itr 0 bh 0xfffffc00054f7280 block 265170 size 8192	þíº¾
<4>_pagebuf page io calling gmk itr 0 bh 0xfffffc00054f71e0 block 265186 size 8192	þíº¾
<4>_pagebuf page io calling gmk itr 0 bh 0xfffffc00041d7b40 block 265202 size 8192	þíº¾
<4>_pagebuf page io calling gmk itr 0 bh 0xfffffc00041d7a00 block 265218 size 8192	þíº¾
<4>_pagebuf page io calling gmk itr 0 bh 0xfffffc00041d7aa0 block 265234 size 8192	þíº¾
<4>_pagebuf page io calling gmk itr 0 bh 0xfffffc00041d6f60 block 265250 size 8192	þíº¾
<4>_pagebuf page io calling gmk itr 0 bh 0xfffffc00041d7960 block 265266 size 8192	þíº¾
<4>_pagebuf page io calling gmk itr 0 bh 0xfffffc00041d69c0 block 265282 size 8192	þíº¾
<4>_pagebuf page io calling gmk itr 0 bh 0xfffffc00041d76e0 block 265298 size 8192	þíº¾
<4>_pagebuf page io calling gmk itr 0 bh 0xfffffc00041d6d80 block 265314 size 8192	þíº¾
<4>_pagebuf page io calling gmk itr 0 bh 0xfffffc00041d7460 block 265330 size 8192	þíº¾
<4>_pagebuf page io calling gmk itr 0 bh 0xfffffc00041d7e60 block 265346 size 8192	þíº¾
<4>_pagebuf page io calling gmk itr 0 bh 0xfffffc00041d7f00 block 265362 size 8192	þíº¾
<4>_pagebuf page io calling gmk itr 0 bh 0xfffffc00041d7d20 block 265378 size 8192	þíº¾
<4>_pagebuf page io calling gmk itr 0 bh 0xfffffc00041d7dc0 block 265394 size 8192	þíº¾
<4>_pagebuf page io calling gmk itr 0 bh 0xfffffc00054f71e0 block 128 size 8192	
<4>Ending clean XFS mount for filesystem: sd(8,17)
<4>_pagebuf page io calling gmk itr 0 bh 0xfffffc00054f71e0 block 2 size 512	
<4>_pagebuf page io calling gmk itr 0 bh 0xfffffc00054f71e0 block 48 size 8192	°c4
<4>_pagebuf page io calling gmk itr 0 bh 0xfffffc00054f71e0 block 1 size 512	
<4>_pagebuf page io calling gmk itr 0 bh 0xfffffc00054f71e0 block 3 size 512	
<4>_pagebuf page io calling gmk itr 0 bh 0xfffffc00054f71e0 block 32 size 8192	VÓ#
<4>_pagebuf page io calling gmk itr 0 bh 0xfffffc00054f71e0 block 16 size 8192		
<4>_pagebuf page io calling gmk itr 0 bh 0xfffffc00054f7280 block 265154 size 3072	þíº¾
<4>_pagebuf page io calling gmk itr 0 bh 0xfffffc00054f7280 block 2 size 512	XAGI
<4>_pagebuf page io calling gmk itr 0 bh 0xfffffc00054f6600 block 48 size 8192	IABT
<4>_pagebuf page io calling gmk itr 0 bh 0xfffffc00041d7dc0 block 1 size 512	XAGF
<4>_pagebuf page io calling gmk itr 0 bh 0xfffffc00041d7d20 block 32 size 8192	ABTC
<4>_pagebuf page io calling gmk itr 0 bh 0xfffffc00041d7f00 block 16 size 8192	ABTB
<4>_pagebuf page io calling gmk itr 0 bh 0xfffffc00041d7e60 block 0 size 1024	XFSB
<4>_pagebuf page io calling gmk itr 0 bh 0xfffffc00041d7460 block 128 size 8192	INAí
<4>_pagebuf page io calling gmk itr 0 bh 0xfffffc00054f6600 block 0 size 1024	XFSB
<4>_pagebuf page io calling gmk itr 0 bh 0xfffffc00054f6600 block 265160 size 1024	þíº¾

i hope it is complete - because there are problems with the prink's not
getting out all - klogd and syslogd seem to eat them up somehow - the
above is what i got using "cat /proc/kmsg" which should be fine i
think

please let me know if you need also output from some more fs activity
than just that simple echo to file (but i thought this might be
simpler for you to find somthing in)

good luck

t

p.s.: is there any trick to get the printk stuff out in a more prefect
      way (i.e. complete and in perfect sync via klogd/syslogd)?

-- 
thomas.graichen@innominate.com
technical director                                       innominate AG
clustering & security                             the linux architects
tel: +49-30-308806-13   fax: -77             http://www.innominate.com

From owner-linux-xfs@oss.sgi.com Thu Nov 30 23:55:57 2000
Received:  by oss.sgi.com id <S553951AbQLAHzr>;
	Thu, 30 Nov 2000 23:55:47 -0800
Received: from hermes.mixx.net ([212.84.196.2]:23564 "HELO hermes.mixx.net")
	by oss.sgi.com with SMTP id <S553947AbQLAHzb>;
	Thu, 30 Nov 2000 23:55:31 -0800
Received: from mate.bln.innominate.de (cerberus.berlin.innominate.de [212.84.234.251])
	by hermes.mixx.net (Postfix) with ESMTP id 35B7FF80D
	for <linux-xfs@oss.sgi.com>; Fri,  1 Dec 2000 08:55:30 +0100 (CET)
Received: by mate.bln.innominate.de (Postfix, from userid 9)
	id 33CC02CAA3; Fri,  1 Dec 2000 08:55:07 +0100 (CET)
From:   Thomas Graichen <news-innominate.list.sgi.xfs@innominate.de>
Reply-To: Thomas Graichen <graichen@innominate.de>
X-Newsgroups: innominate.list.sgi.xfs
Subject: Re: stress test on ppc
Date:   1 Dec 2000 07:55:07 GMT
Organization: innominate AG, Berlin, Germany
Lines:  21
Distribution: local
Message-ID: <news2mail-907lgr$27r$2@mate.bln.innominate.de>
References: <news2mail-8uecj0$i5e$1@mate.bln.innominate.de>   <10011261336.ZM166460@wobbly.melbourne.sgi.com>   <news2mail-8vt5ub$dhv$3@mate.bln.innominate.de>   <10011281048.ZM165042@wobbly.melbourne.sgi.com>   <news2mail-9001u3$n0b$2@mate.bln.innominate.de>   <10011290940.ZM169800@wobbly.melbourne.sgi.com>   <news2mail-902hr6$307$1@mate.bln.innominate.de>   <10011301040.ZM164128@wobbly.melbourne.sgi.com>   <news2mail-90550o$3u0$3@mate.bln.innominate.de> <10012010904.ZM174461@wobbly.melbourne.sgi.com>
Reply-To: thomas.graichen@innominate.de
X-Trace: mate.bln.innominate.de 975657307 2299 10.0.0.31 (1 Dec 2000 07:55:07 GMT)
X-Complaints-To: news@innominate.de
User-Agent: tin/1.4.4-20000803 ("Vet for the Insane") (UNIX) (Linux/2.4.0-XFS-test10 (i686))
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

"Nathan Scott" <nathans@wobbly.melbourne.sgi.com> wrote:

> as Russell pointed out, this is really odd - some fields
> are displayed correctly, others are off with the pixies.
> I can't see any obvious pattern either... the only thing
> I can think of is that xfs_db is doing some deep and
> meaningful bit shifting to come up with these numbers -
> perhaps this is a compiler issue (we had problems before
> with the xfs_high/lowbit routines on non-2.91.66 compilers,
> perhaps this is true on ppc also - its probably worthwhile
> trying that compiler to build userspace too if you can).

i'll try to find or maybe build an egcs to try this out

t

-- 
thomas.graichen@innominate.com
technical director                                       innominate AG
clustering & security                             the linux architects
tel: +49-30-308806-13   fax: -77             http://www.innominate.com