From owner-linux-xfs@oss.sgi.com Tue Jul 1 09:06:09 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 01 Jul 2003 09:06:35 -0700 (PDT) Received: from portageek.digitalroadkill.net (host-65-120-145-91.coremetrics.com [65.120.145.91] (may be forged)) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h61G672x005418 for ; Tue, 1 Jul 2003 09:06:09 -0700 Received: from portageek.digitalroadkill.net (localhost.localdomain [127.0.0.1]) by portageek.digitalroadkill.net (8.12.8/8.12.8) with ESMTP id h61G62Z9002231 for ; Tue, 1 Jul 2003 11:06:02 -0500 Received: (from austin@localhost) by portageek.digitalroadkill.net (8.12.8/8.12.8/Submit) id h61G627h002229 for linux-xfs@oss.sgi.com; Tue, 1 Jul 2003 11:06:02 -0500 X-Authentication-Warning: portageek.digitalroadkill.net: austin set sender to austin@coremetrics.com using -f Subject: XFS and Zero-filled files question. From: Austin Gonyou To: XFS List Content-Type: text/plain Content-Transfer-Encoding: 7bit Organization: Coremetrics, Inc. Message-Id: <1057075562.1896.1.camel@portageek.digitalroadkill.net> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.0 Date: 01 Jul 2003 11:06:02 -0500 X-archive-position: 4515 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: austin@coremetrics.com Precedence: bulk X-list: linux-xfs This is not a question that I keep getting them or anything like that. I remember that there was a TAKE a while back for rewriting a lot of the pagebuf code once 1.3.x branch was started. I seem to recall this directly affecting the file corruption issue and that it would all be gone, save for a few known cases. Could someone help refresh my memory about this? I can't seem to figure out what to search for in my email archive. ;) -- Austin Gonyou Coremetrics, Inc. From owner-linux-xfs@oss.sgi.com Tue Jul 1 09:14:42 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 01 Jul 2003 09:14:57 -0700 (PDT) Received: from rj.sgi.com (rj.SGI.COM [192.82.208.96]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h61GEd2x005902 for ; Tue, 1 Jul 2003 09:14:42 -0700 Received: from stout.americas.sgi.com (stout.americas.sgi.com [128.162.232.50]) by rj.sgi.com (8.12.9/8.12.2/linux-outbound_gateway-1.2) with ESMTP id h61GEFWr017589 for ; Tue, 1 Jul 2003 09:14:15 -0700 Received: from stout.americas.sgi.com (localhost [127.0.0.1]) by stout.americas.sgi.com (8.12.8/8.12.8) with ESMTP id h61GEYiV029710 for ; Tue, 1 Jul 2003 11:14:34 -0500 Received: (from sandeen@localhost) by stout.americas.sgi.com (8.12.8/8.12.8/Submit) id h61GEX3O029708 for linux-xfs@oss.sgi.com; Tue, 1 Jul 2003 11:14:33 -0500 Date: Tue, 1 Jul 2003 11:14:33 -0500 From: Eric Sandeen Message-Id: <200307011614.h61GEX3O029708@stout.americas.sgi.com> Subject: TAKE - add swsusp support to xfs daemons X-archive-position: 4516 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: sandeen@stout.americas.sgi.com Precedence: bulk X-list: linux-xfs We had this for pagebuf, but not for the xfs daemons. Thanks to Karol Kozimor for pointing this out. add swsusp support to xfs daemons Date: Tue Jul 1 09:13:07 PDT 2003 Workarea: stout.americas.sgi.com:/localhome/src/sandeen/2.5.x-xfs/workarea The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.5.x-xfs Modid: 2.5.x-xfs:slinx:152354a linux/fs/xfs/linux/xfs_super.c - 1.272 linux/fs/xfs/linux/xfs_syncd.c - 1.5 From owner-linux-xfs@oss.sgi.com Tue Jul 1 09:21:58 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 01 Jul 2003 09:22:11 -0700 (PDT) Received: from zok.sgi.com (zok.SGI.COM [204.94.215.101]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h61GLw2x006408 for ; Tue, 1 Jul 2003 09:21:58 -0700 Received: from stout.americas.sgi.com (stout.americas.sgi.com [128.162.232.50]) by zok.sgi.com (8.12.9/8.12.2/linux-outbound_gateway-1.2) with ESMTP id h61GLqiY020076 for ; Tue, 1 Jul 2003 09:21:52 -0700 Received: from stout.americas.sgi.com (localhost [127.0.0.1]) by stout.americas.sgi.com (8.12.8/8.12.8) with ESMTP id h61GLqiV029816 for ; Tue, 1 Jul 2003 11:21:52 -0500 Received: (from sandeen@localhost) by stout.americas.sgi.com (8.12.8/8.12.8/Submit) id h61GLq7O029814 for linux-xfs@oss.sgi.com; Tue, 1 Jul 2003 11:21:52 -0500 Date: Tue, 1 Jul 2003 11:21:52 -0500 From: Eric Sandeen Message-Id: <200307011621.h61GLq7O029814@stout.americas.sgi.com> Subject: TAKE - [2.5] Remove dead xfs_syncd.c file X-archive-position: 4517 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: sandeen@stout.americas.sgi.com Precedence: bulk X-list: linux-xfs Remove dead C file... Date: Tue Jul 1 09:20:45 PDT 2003 Workarea: stout.americas.sgi.com:/localhome/src/sandeen/2.5.x-xfs/workarea The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.5.x-xfs Modid: 2.5.x-xfs:slinx:152355a linux/fs/xfs/linux/xfs_syncd.c - 1.6 From owner-linux-xfs@oss.sgi.com Tue Jul 1 11:18:08 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 01 Jul 2003 11:18:21 -0700 (PDT) Received: from hotmail.com (sea2-f39.sea2.hotmail.com [207.68.165.39]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h61II72x008457 for ; Tue, 1 Jul 2003 11:18:08 -0700 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Tue, 1 Jul 2003 11:18:02 -0700 Received: from 208.244.233.175 by sea2fd.sea2.hotmail.msn.com with HTTP; Tue, 01 Jul 2003 18:18:02 GMT X-Originating-IP: [208.244.233.175] X-Originating-Email: [rgsmith72@hotmail.com] From: "Rick Smith" To: linux-xfs@oss.sgi.com Subject: RE: guaranteed increasing extent allocation Date: Tue, 01 Jul 2003 11:18:02 -0700 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 01 Jul 2003 18:18:02.0445 (UTC) FILETIME=[1BEF4FD0:01C33FFD] X-archive-position: 4518 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: rgsmith72@hotmail.com Precedence: bulk X-list: linux-xfs Hello, I have made some progress concerning this issue with slight modifications to the XFS source code. Specifically, changing the default allocation type to XFS_ALLOCTYPE_FIRST_AG and set the default allocation group to zero (when nullfb == NULL in xfs_bmap_alloc() in xfs_bmap.c). It is my hope to always force allocation to start searching at the beginning of allocation group 0 and then proceed to the next group once the preceding group is full. Since I am using XFS_IOC_RESVSP64 to reserve the files ahead of time, I am not concerned with potentially slowing down the file creation process. I also realize that this is probably not what most filesystem users are looking for, but I think it is crucial for video I/O. Is there a way to specify to the allocator to always begin with the start of an allocation group? There are cases where a file gets allocated from an allocation group and then a later file allocation gets a space closer to the beginning of the same allocation group. Is this due to the binary block search in xfs_alloc_ag_vextent_size()? Also, are there any other potential drawbacks to setting the default allocation type to XFS_ALLOCTYPE_FIRST_AG? Thanks. Rick Smith _________________________________________________________________ MSN 8 helps eliminate e-mail viruses. Get 2 months FREE*. http://join.msn.com/?page=features/virus From owner-linux-xfs@oss.sgi.com Tue Jul 1 12:42:23 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 01 Jul 2003 12:42:43 -0700 (PDT) Received: from hermes.d2.com (ns50-untrust.d2.com [198.211.88.11]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h61JgG2x009541 for ; Tue, 1 Jul 2003 12:42:20 -0700 Received: from samoa-l (samoa-l [172.16.50.128]) by hermes.d2.com (8.12.2/8.12.2) with ESMTP id h61JcnDL008008 for ; Tue, 1 Jul 2003 12:38:49 -0700 Date: Tue, 1 Jul 2003 12:42:26 -0700 (PDT) From: Sebastien Boving To: Subject: oops in 2.4.20-18.9XFS1.3.0pre2 Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Scanned-By: MIMEDefang 2.6 (www dot roaringpenguin dot com slash mimedefang) X-archive-position: 4519 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: seb@d2.com Precedence: bulk X-list: linux-xfs *, ftpd writing to an xfs filesystem (compiled from 2.4.20-18.9XFS1.3.0pre2 for RH9 src rpm from oss.sgi.com ftp site, but without kdb) crashed, leaving the following in the logs: Unable to handle kernel NULL pointer dereference at virtual address 00000008 printing eip: f8afcbc4 *pde = 00000000 Oops: 0000 nfsd iptable_filter ip_tables autofs nfs lockd sunrpc e1000 xfs keybdev mousedev input hid usb-uhci usbcore ext3 jbd raid0 3w-xxxx sd_mod scsi_mod CPU: 2 EIP: 0060:[] Not tainted EFLAGS: 00010202 EIP is at linvfs_permission [xfs] 0x14 (2.4.20-18.9XFS1.3.0pre2custom) eax: 00000040 ebx: cc0e4000 ecx: 00000001 edx: 00000000 esi: bfffe8c0 edi: bfffe98c ebp: bfffe748 esp: cc0e5f68 ds: 0068 es: 0068 ss: 0068 Process vsftpd (pid: 9690, stackpage=cc0e5000) Stack: c016078c c62ee35c cc610000 c015f62f c0d23b20 00000001 00000000 c0151388 c0d23b20 00000001 f608a300 f6e09f00 f3ef5a80 4001e000 00000018 0000000b 00000001 00000000 cc0e4000 bfffe8c0 bfffe98c bfffe748 c01098bf 0805d7d8 Call Trace: [] __user_walk [kernel] 0x5c (0xcc0e5f68)) [] permission [kernel] 0x4f (0xcc0e5f74)) [] sys_chdir [kernel] 0x58 (0xcc0e5f84)) [] system_call [kernel] 0x33 (0xcc0e5fc0)) dir it was writing to contains a broken entry, another dir. I can't cd into it, du it, ... all end with Segmentation Fault and print out: Code: 8b 4a 08 89 14 24 c7 44 24 08 00 00 00 00 89 44 24 04 ff 51 <1>Unable to handle kernel NULL pointer dereference at virtual address 00000008 printing eip: f8afcbc4 *pde = 00000000 Oops: 0000 nfsd iptable_filter ip_tables autofs nfs lockd sunrpc e1000 xfs keybdev mousedev input hid usb-uhci usbcore ext3 jbd raid0 3w-xxxx sd_mod scsi_mod CPU: 3 EIP: 0060:[] Not tainted EFLAGS: 00010202 EIP is at linvfs_permission [xfs] 0x14 (2.4.20-18.9XFS1.3.0pre2custom) eax: 00000040 ebx: ded5a000 ecx: 00000001 edx: 00000000 esi: 00000000 edi: 00000000 ebp: bfffea08 esp: ded5bf68 ds: 0068 es: 0068 ss: 0068 Process du (pid: 9699, stackpage=ded5b000) Stack: c016078c c62ee35c f6fcd000 c015f62f c0d23b20 00000001 00000000 c0151388 c0d23b20 00000001 f608a300 f6e09e80 00000000 3f014c32 3f014c32 0000000b 00000001 00000008 ded5a000 00000000 00000000 bfffea08 c01098bf bffffb97 Call Trace: [] __user_walk [kernel] 0x5c (0xded5bf68)) [] permission [kernel] 0x4f (0xded5bf74)) [] sys_chdir [kernel] 0x58 (0xded5bf84)) [] system_call [kernel] 0x33 (0xded5bfc0)) I tried moving all dirs from there (including the broken one) to a new dir, hoping it would only mv the good ones and leave the problematic one in that dir, but now i can't ls either of them (ls goes into uninterruptable sleep, 'down' call). ==> what's the problem? should 1.3.0pre2 not be used? (i have this fs since only a week). [root@chimera BKUP]# mount | grep xfs /dev/md0 on /export/lot/s90 type xfs (rw,logbufs=8,logbsize=32768) [root@chimera BKUP]# xfs_info /export/lot/s90 meta-data=/export/lot/s90 isize=256 agcount=280, agsize=1048568 blks = sectsz=512 data = bsize=4096 blocks=293037600, imaxpct=25 = sunit=8 swidth=16 blks, unwritten=0 naming =version 2 bsize=4096 log =internal bsize=4096 blocks=32768, version=1 = sectsz=512 sunit=0 blks realtime =none extsz=65536 blocks=0, rtextents=0 thanks, -seb. From owner-linux-xfs@oss.sgi.com Tue Jul 1 13:01:14 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 01 Jul 2003 13:01:20 -0700 (PDT) Received: from main.gmane.org (main.gmane.org [80.91.224.249]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h61K1C2x010151 for ; Tue, 1 Jul 2003 13:01:13 -0700 Received: from root by main.gmane.org with local (Exim 3.35 #1 (Debian)) id 19XRIV-0004ir-00 for ; Tue, 01 Jul 2003 22:00:15 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: linux-xfs@oss.sgi.com Received: from news by main.gmane.org with local (Exim 3.35 #1 (Debian)) id 19XRAj-0003wh-00 for ; Tue, 01 Jul 2003 21:52:13 +0200 From: Jason Parker-Burlingham Subject: Flash drive suitability for XFS journals Date: Tue, 01 Jul 2003 15:52:40 -0400 Lines: 38 Message-ID: <87n0fy9g8n.fsf@freezer.burling> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Complaints-To: usenet@main.gmane.org User-Agent: Gnus/5.1001 (Gnus v5.10.1) Emacs/21.3 (gnu/linux) Cancel-Lock: sha1:Qu/Q8Bl0lR/NF1XO53J1j9r1/18= X-archive-position: 4520 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: jasonp@panix.com Precedence: bulk X-list: linux-xfs While attempting to recover an unjournalled filesystem last week, it occurred to me that it should be possible to store the XFS log on a simple solid-state device. A USB keychain or thumb drive immediately suggested itself, and a quick check of the XFS manual pages indicated this is a distinct possibility. A little talk on a local LUG list pointed out that these things often have a limited number of write cycles, typically in the millions. One poster suggested that write levelling could reduce the impact of this limitation, by increasing the amount of data which can be written to the device before it starts to fail. If I can find a system to sacrifice I may be tempted to give this a try---small drives are fairly cheap and have write cycles large enough to make a test worthwhile. My XFS-related questions are: 0) Will this really be useful? My hope is that storing the log on a device which doesn't use the IDE bus will save the log from becoming corrupted when the IDE disks start to fail. (The restore I alluded to above would probably have been recoverable if the disk's superblock and bad block list had remained intact.) 1) How much space will I need, relative to the space required for the filesystem itself? My home system has an XFS filesystem on /home which is 1.7GB, and the internal log is about 5MB. Can I expect this to scale? On a similar note, will acting as an XFS journal simply exhaust the drive in a matter of months, instead of having a lifetime comparable to the drives themselves? 2) What sort of performance penalty can I expect to contend with? I would probably use a USB2.0 drive---fortunately the small ones are still remarkably inexpensive. 3) Is there some other technology suitable for the small office situation which might fill this need? -- Stay up-to-date on what I'm doing lately: http://www.panix.com/~jasonp From owner-linux-xfs@oss.sgi.com Tue Jul 1 13:03:32 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 01 Jul 2003 13:03:36 -0700 (PDT) Received: from zok.sgi.com (zok.SGI.COM [204.94.215.101]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h61K3V2x010587 for ; Tue, 1 Jul 2003 13:03:32 -0700 Received: from flecktone.americas.sgi.com (flecktone.americas.sgi.com [192.48.203.135]) by zok.sgi.com (8.12.9/8.12.2/linux-outbound_gateway-1.2) with ESMTP id h61K3QiY023774 for ; Tue, 1 Jul 2003 13:03:26 -0700 Received: from maine.americas.sgi.com (maine.americas.sgi.com [128.162.232.87]) by flecktone.americas.sgi.com (8.12.9/8.12.9/generic_config-1.2) with ESMTP id h61K2PqX7322684; Tue, 1 Jul 2003 15:02:25 -0500 (CDT) Received: from nstraz by maine.americas.sgi.com with local (Exim 3.36 #1 (Debian)) id 19XRKb-0002yj-00; Tue, 01 Jul 2003 15:02:25 -0500 Date: Tue, 1 Jul 2003 15:02:25 -0500 From: Nathan Straz To: Sebastien Boving Cc: linux-xfs@oss.sgi.com Subject: Re: oops in 2.4.20-18.9XFS1.3.0pre2 Message-ID: <20030701200225.GG2056@sgi.com> Mail-Followup-To: Sebastien Boving , linux-xfs@oss.sgi.com References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.3i X-archive-position: 4521 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: nstraz@sgi.com Precedence: bulk X-list: linux-xfs On Tue, Jul 01, 2003 at 12:42:26PM -0700, Sebastien Boving wrote: > ftpd writing to an xfs filesystem (compiled from 2.4.20-18.9XFS1.3.0pre2 > for RH9 src rpm from oss.sgi.com ftp site, but without kdb) crashed, > leaving the following in the logs: Do you have any idea what was going on before the crash? I can try to reproduce this, but I don't see a lot to go on. > dir it was writing to contains a broken entry, another dir. I can't cd > into it, du it, ... all end with Segmentation Fault and print out: Can you try to print out some information with xfs_db? See the man page for how to use it. Perhaps one of the developers will offer up some recommended commands. > ==> what's the problem? should 1.3.0pre2 not be used? (i have this fs > since only a week). It's still a pre-release so it should be used on machines that you can spare some downtime on. It is not meant for production use. -- Nate Straz nstraz@sgi.com sgi, inc http://www.sgi.com/ Linux Test Project http://ltp.sf.net/ From owner-linux-xfs@oss.sgi.com Tue Jul 1 13:12:32 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 01 Jul 2003 13:12:35 -0700 (PDT) Received: from hermes.d2.com (ns50-untrust.d2.com [198.211.88.11]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h61KCT2x011112 for ; Tue, 1 Jul 2003 13:12:30 -0700 Received: from samoa-l (samoa-l [172.16.50.128]) by hermes.d2.com (8.12.2/8.12.2) with ESMTP id h61K92DL019235; Tue, 1 Jul 2003 13:09:02 -0700 Date: Tue, 1 Jul 2003 13:12:39 -0700 (PDT) From: Sebastien Boving To: Nathan Straz cc: Subject: Re: oops in 2.4.20-18.9XFS1.3.0pre2 In-Reply-To: <20030701200225.GG2056@sgi.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Scanned-By: MIMEDefang 2.6 (www dot roaringpenguin dot com slash mimedefang) X-archive-position: 4522 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: seb@d2.com Precedence: bulk X-list: linux-xfs On Tue, 1 Jul 2003, Nathan Straz wrote: > On Tue, Jul 01, 2003 at 12:42:26PM -0700, Sebastien Boving wrote: > > ftpd writing to an xfs filesystem (compiled from 2.4.20-18.9XFS1.3.0pre2 > > for RH9 src rpm from oss.sgi.com ftp site, but without kdb) crashed, > > leaving the following in the logs: > > Do you have any idea what was going on before the crash? I can try to > reproduce this, but I don't see a lot to go on. the box is doing only nfs serving, and traffic is currently close to 0. At that point though, i was doing a ftp from another host to this machine, recursively mput'ing data on the xfs filesystem. it's while nfsd was writing a particular directory (or files therein, i can't get passed the dir) that it crashed (segfault), and the first messages is sent appeared in the logs. i then logged into it and tried some commands on that dir, and got the other messages. that's all i know so far. > > dir it was writing to contains a broken entry, another dir. I can't cd > > into it, du it, ... all end with Segmentation Fault and print out: > > Can you try to print out some information with xfs_db? See the man page > for how to use it. Perhaps one of the developers will offer up some > recommended commands. i will play with that, but first i'm making an extra online backup of the the 300gb that's still available. > > ==> what's the problem? should 1.3.0pre2 not be used? (i have this fs > > since only a week). > > It's still a pre-release so it should be used on machines that you can > spare some downtime on. It is not meant for production use. i see, my bad. 2 questions then: - is there a RH9 2.4.18+ kernel src rpm with 1.2 available somewhere, or what's the best way to build it? - once i get there (recent rh kernel with 1.2.0), can i mount my 1.3.0pre2 created fs with it? or should i mkfs.xfs it before? From owner-linux-xfs@oss.sgi.com Tue Jul 1 13:21:31 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 01 Jul 2003 13:21:44 -0700 (PDT) Received: from zok.sgi.com (zok.SGI.COM [204.94.215.101]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h61KLU2x011587 for ; Tue, 1 Jul 2003 13:21:31 -0700 Received: from flecktone.americas.sgi.com (flecktone.americas.sgi.com [192.48.203.135]) by zok.sgi.com (8.12.9/8.12.2/linux-outbound_gateway-1.2) with ESMTP id h61KLPiY026851 for ; Tue, 1 Jul 2003 13:21:25 -0700 Received: from maine.americas.sgi.com (maine.americas.sgi.com [128.162.232.87]) by flecktone.americas.sgi.com (8.12.9/8.12.9/generic_config-1.2) with ESMTP id h61KLPqX7336142; Tue, 1 Jul 2003 15:21:25 -0500 (CDT) Received: from nstraz by maine.americas.sgi.com with local (Exim 3.36 #1 (Debian)) id 19XRcy-00033z-00; Tue, 01 Jul 2003 15:21:24 -0500 Date: Tue, 1 Jul 2003 15:21:24 -0500 From: Nathan Straz To: Sebastien Boving Cc: linux-xfs@oss.sgi.com Subject: Re: oops in 2.4.20-18.9XFS1.3.0pre2 Message-ID: <20030701202124.GH2056@sgi.com> Mail-Followup-To: Sebastien Boving , linux-xfs@oss.sgi.com References: <20030701200225.GG2056@sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.3i X-archive-position: 4523 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: nstraz@sgi.com Precedence: bulk X-list: linux-xfs On Tue, Jul 01, 2003 at 01:12:39PM -0700, Sebastien Boving wrote: > On Tue, 1 Jul 2003, Nathan Straz wrote: > > Do you have any idea what was going on before the crash? I can try to > > reproduce this, but I don't see a lot to go on. > > the box is doing only nfs serving, and traffic is currently close to 0. At > that point though, i was doing a ftp from another host to this machine, > recursively mput'ing data on the xfs filesystem. > > it's while nfsd was writing a particular directory (or files therein, i > can't get passed the dir) that it crashed (segfault), and the first > messages is sent appeared in the logs. That gives me a vague idea of what to try. I'll see what I can do. > - once i get there (recent rh kernel with 1.2.0), can i mount my 1.3.0pre2 > created fs with it? or should i mkfs.xfs it before? You won't have any trouble mounting the file system with any released version of XFS. Since you do seem to have some corruption, you'll want to run the file system through xfs_repair to try to fix it. -- Nate Straz nstraz@sgi.com sgi, inc http://www.sgi.com/ Linux Test Project http://ltp.sf.net/ From owner-linux-xfs@oss.sgi.com Tue Jul 1 13:22:28 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 01 Jul 2003 13:22:31 -0700 (PDT) Received: from zok.sgi.com (zok.SGI.COM [204.94.215.101]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h61KMR2x011725 for ; Tue, 1 Jul 2003 13:22:28 -0700 Received: from flecktone.americas.sgi.com (flecktone.americas.sgi.com [192.48.203.135]) by zok.sgi.com (8.12.9/8.12.2/linux-outbound_gateway-1.2) with ESMTP id h61KMMiY026977 for ; Tue, 1 Jul 2003 13:22:22 -0700 Received: from poppy-e236.americas.sgi.com (poppy-e236.americas.sgi.com [128.162.236.207]) by flecktone.americas.sgi.com (8.12.9/8.12.9/generic_config-1.2) with ESMTP id h61KMLqX7328450; Tue, 1 Jul 2003 15:22:22 -0500 (CDT) Received: from stout.americas.sgi.com (stout.americas.sgi.com [128.162.232.50]) by poppy-e236.americas.sgi.com (8.12.9/SGI-server-1.8) with ESMTP id h61KMLYk13583597; Tue, 1 Jul 2003 15:22:21 -0500 (CDT) Subject: Re: oops in 2.4.20-18.9XFS1.3.0pre2 From: Eric Sandeen To: Sebastien Boving Cc: linux-xfs@oss.sgi.com In-Reply-To: References: Content-Type: text/plain Organization: Message-Id: <1057090941.21393.44.camel@stout.americas.sgi.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 (1.2.2-5) Date: 01 Jul 2003 15:22:21 -0500 Content-Transfer-Encoding: 7bit X-archive-position: 4524 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: sandeen@sgi.com Precedence: bulk X-list: linux-xfs I take it that you recompiled the kernel to remove kdb? :) We really need to be able to poke around in kdb a bit. Did you change anything else? Have you used this same filesystem with older kernels, without trouble? To recover, I would suggest rebooting, and then point xfs_repair at the device, probably with the "-n" option first to see what it -would- do. It looks like the cause of the oops is that the behavior on the vnode is null, but it's pretty hard to know how we got here. -Eric -- Eric Sandeen XFS for Linux http://oss.sgi.com/projects/xfs sandeen@sgi.com SGI, Inc. 651-683-3102 From owner-linux-xfs@oss.sgi.com Tue Jul 1 13:24:08 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 01 Jul 2003 13:24:13 -0700 (PDT) Received: from zok.sgi.com (zok.SGI.COM [204.94.215.101]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h61KO72x012413 for ; Tue, 1 Jul 2003 13:24:08 -0700 Received: from flecktone.americas.sgi.com (flecktone.americas.sgi.com [192.48.203.135]) by zok.sgi.com (8.12.9/8.12.2/linux-outbound_gateway-1.2) with ESMTP id h61KO2iY027140 for ; Tue, 1 Jul 2003 13:24:02 -0700 Received: from daisy-e236.americas.sgi.com (daisy-e236.americas.sgi.com [128.162.236.214]) by flecktone.americas.sgi.com (8.12.9/8.12.9/generic_config-1.2) with ESMTP id h61KO1qX7326412; Tue, 1 Jul 2003 15:24:01 -0500 (CDT) Received: from [192.168.1.100] (cf-vpn-sw-corp-64-33.corp.sgi.com [134.15.64.33]) by daisy-e236.americas.sgi.com (8.12.9/SGI-server-1.8) with ESMTP id h61KO0Rn148584133; Tue, 1 Jul 2003 15:24:01 -0500 (CDT) Subject: Re: Flash drive suitability for XFS journals From: Steve Lord To: Jason Parker-Burlingham Cc: linux-xfs@oss.sgi.com In-Reply-To: <87n0fy9g8n.fsf@freezer.burling> References: <87n0fy9g8n.fsf@freezer.burling> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.8 (1.0.8-10) Date: 01 Jul 2003 15:24:49 -0500 Message-Id: <1057091090.1368.84.camel@laptop.americas.sgi.com> Mime-Version: 1.0 X-archive-position: 4525 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: lord@sgi.com Precedence: bulk X-list: linux-xfs On Tue, 2003-07-01 at 14:52, Jason Parker-Burlingham wrote: > While attempting to recover an unjournalled filesystem last week, it > occurred to me that it should be possible to store the XFS log on a > simple solid-state device. A USB keychain or thumb drive immediately > suggested itself, and a quick check of the XFS manual pages indicated > this is a distinct possibility. > > A little talk on a local LUG list pointed out that these things often > have a limited number of write cycles, typically in the millions. One > poster suggested that write levelling could reduce the impact of this > limitation, by increasing the amount of data which can be written to > the device before it starts to fail. Well, the log is written as a circular buffer, take a look at a system which has been up for a while and use the xfs_stats.pl script which is in the cmd/xfsmisc directory, xs_log_blocks is the number of 512 byte log blocks written since boot up. This will give you an idea of the frequency of log wrapping. Divide it by the size of your log to get the number of times it has wrapped. > > If I can find a system to sacrifice I may be tempted to give this a > try---small drives are fairly cheap and have write cycles large enough > to make a test worthwhile. My XFS-related questions are: > > 0) Will this really be useful? My hope is that storing the log on a > device which doesn't use the IDE bus will save the log from > becoming corrupted when the IDE disks start to fail. (The restore > I alluded to above would probably have been recoverable if the > disk's superblock and bad block list had remained intact.) > Well, there may be a few more recoverable cases, but I doubt it will be a huge gain. > 1) How much space will I need, relative to the space required for the > filesystem itself? My home system has an XFS filesystem on /home > which is 1.7GB, and the internal log is about 5MB. Can I expect > this to scale? On a similar note, will acting as an XFS journal > simply exhaust the drive in a matter of months, instead of having a > lifetime comparable to the drives themselves? > If you want to minimize reuse of the space, make the log as big as possible. > 2) What sort of performance penalty can I expect to contend with? I > would probably use a USB2.0 drive---fortunately the small ones are > still remarkably inexpensive. > Most log writes are async, if you are doing metadata intensive ops then you can end up waiting for a log buffer to complete I/O. Doing things like deleting large directory trees, we can become I/O bound on the log, so performance can matter. > 3) Is there some other technology suitable for the small office > situation which might fill this need? There are battery backed ram cards which can be made to look like a block device. The cost more though. Steve From owner-linux-xfs@oss.sgi.com Tue Jul 1 13:28:10 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 01 Jul 2003 13:28:14 -0700 (PDT) Received: from hermes.d2.com (ns50-untrust.d2.com [198.211.88.11]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h61KS22x012905 for ; Tue, 1 Jul 2003 13:28:07 -0700 Received: from samoa-l (samoa-l [172.16.50.128]) by hermes.d2.com (8.12.2/8.12.2) with ESMTP id h61KOYDL025125; Tue, 1 Jul 2003 13:24:34 -0700 Date: Tue, 1 Jul 2003 13:28:11 -0700 (PDT) From: Sebastien Boving To: Nathan Straz cc: Subject: Re: oops in 2.4.20-18.9XFS1.3.0pre2 In-Reply-To: <20030701202124.GH2056@sgi.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Scanned-By: MIMEDefang 2.6 (www dot roaringpenguin dot com slash mimedefang) X-archive-position: 4526 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: seb@d2.com Precedence: bulk X-list: linux-xfs On Tue, 1 Jul 2003, Nathan Straz wrote: > On Tue, Jul 01, 2003 at 01:12:39PM -0700, Sebastien Boving wrote: > > On Tue, 1 Jul 2003, Nathan Straz wrote: > > > Do you have any idea what was going on before the crash? I can try to > > > reproduce this, but I don't see a lot to go on. > > > > the box is doing only nfs serving, and traffic is currently close to 0. At > > that point though, i was doing a ftp from another host to this machine, > > recursively mput'ing data on the xfs filesystem. > > > > it's while nfsd was writing a particular directory (or files therein, i > > can't get passed the dir) that it crashed (segfault), and the first > > messages is sent appeared in the logs. > > That gives me a vague idea of what to try. I'll see what I can do. something i forgot in case it'd help: the ftp transfer was over gigabit at about 40mb/s, all files 8mb each, did 100gb total before crashing. No more than 600 files per dir. ftpd= vsftpd from RH9.0, v1.1.3 in case that helps. > > - once i get there (recent rh kernel with 1.2.0), can i mount my 1.3.0pre2 > > created fs with it? or should i mkfs.xfs it before? > > You won't have any trouble mounting the file system with any released > version of XFS. Since you do seem to have some corruption, you'll want > to run the file system through xfs_repair to try to fix it. great! i'll do this once the backup is done... thanks for the help, -seb. From owner-linux-xfs@oss.sgi.com Tue Jul 1 13:31:41 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 01 Jul 2003 13:31:55 -0700 (PDT) Received: from hermes.d2.com (ns50-untrust.d2.com [198.211.88.11]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h61KVd2x013382 for ; Tue, 1 Jul 2003 13:31:40 -0700 Received: from samoa-l (samoa-l [172.16.50.128]) by hermes.d2.com (8.12.2/8.12.2) with ESMTP id h61KSDDL026270; Tue, 1 Jul 2003 13:28:13 -0700 Date: Tue, 1 Jul 2003 13:31:50 -0700 (PDT) From: Sebastien Boving To: Eric Sandeen cc: Subject: Re: oops in 2.4.20-18.9XFS1.3.0pre2 In-Reply-To: <1057090941.21393.44.camel@stout.americas.sgi.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Scanned-By: MIMEDefang 2.6 (www dot roaringpenguin dot com slash mimedefang) X-archive-position: 4527 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: seb@d2.com Precedence: bulk X-list: linux-xfs On 1 Jul 2003, Eric Sandeen wrote: > I take it that you recompiled the kernel to remove kdb? :) We really > need to be able to poke around in kdb a bit. Did you change anything > else? i indeed removed it. I was using the serial console on it and typed CTRL-a to go to the beginning of the shell line, and it put me in kdb, stopping the machine. It took a few secs before finding the 'go' option ;), and since this box is prod i rather disabled the feature. i shouldn't have changed anything else. If interested i can send my .config. > Have you used this same filesystem with older kernels, without trouble? nope, this is a new box, new fs created with this kernel. > To recover, I would suggest rebooting, and then point xfs_repair at the > device, probably with the "-n" option first to see what it -would- do. good idea, thanks. > It looks like the cause of the oops is that the behavior on the vnode is > null, but it's pretty hard to know how we got here. sorry! -seb. From owner-linux-xfs@oss.sgi.com Tue Jul 1 14:33:12 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 01 Jul 2003 14:33:26 -0700 (PDT) Received: from rrzd2.rz.uni-regensburg.de (root@rrzd2.rz.uni-regensburg.de [132.199.1.12]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h61LXA2x014888 for ; Tue, 1 Jul 2003 14:33:11 -0700 Received: from rss1.rz.uni-regensburg.de (rss1.rz.uni-regensburg.de [132.199.1.200]) by rrzd2.rz.uni-regensburg.de (8.12.3/8.12.3/Debian -4) with SMTP id h61LX9Cr012853 for ; Tue, 1 Jul 2003 23:33:09 +0200 Received: (qmail 14248 invoked from network); 1 Jul 2003 23:33:09 +0200 Received: from rx3227.cip.uni-regensburg.de (132.199.237.32) by rss1.rz.uni-regensburg.de with SMTP; 1 Jul 2003 23:33:09 +0200 Subject: EFSCORRUPTED returned from file xfs_ialloc.c From: Christian Guggenberger Reply-To: christian.guggenberger@physik.uni-regensburg.de To: linux-xfs@oss.sgi.com Content-Type: text/plain Message-Id: <1057095191.483.18.camel@bonnie79> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.0 Date: 01 Jul 2003 23:33:11 +0200 Content-Transfer-Encoding: 7bit X-archive-position: 4528 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: christian.guggenberger@physik.uni-regensburg.de Precedence: bulk X-list: linux-xfs Hi Folks, Just, after starting a weekly xfs_fsr on a 400GB lvm device (HW Raid), the filesystem shut down unclean. Now i can't mount it again. This filesystem was exported via nfs. Here's the logs: (output of xfs_repair -n is availbale at http://homepages.uni-regensburg.de/~guc28561/repair.txt.gz ) nfsd: non-standard errno: -990 EFSCORRUPTED returned from file xfs_ialloc.c line 1312 xfs_btree_check_sblock: Not OK: magic 0x0 level 0 numrecs 0 leftsib 0 rightsib 0 EFSCORRUPTED returned from file xfs_btree.c line 200 xfs_force_shutdown(lvm(58,1),0x8) called from line 1042 of file xfs_trans.c. Return address = 0xc01c4f09 Filesystem "lvm(58,1)": Corruption of in-memory data detected. Shutting down filesystem: lvm(58,1) Please umount the filesystem, and rectify the problem(s) nfsd: last server has exited nfsd: unexporting all filesystems XFS mounting filesystem lvm(58,1) Starting XFS recovery on filesystem: lvm(58,1) (dev: 58/1) XFS: xlog_recover_process_data: bad clientid XFS: log mount/recovery failed XFS: log mount failed thx in advance Christian P.S. sorry for the 3rd resend, didn't want to spam the list with that big attachments... From owner-linux-xfs@oss.sgi.com Tue Jul 1 15:57:06 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 01 Jul 2003 15:57:22 -0700 (PDT) Received: from rj.sgi.com (rj.SGI.COM [192.82.208.96]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h61Mv52x017099 for ; Tue, 1 Jul 2003 15:57:05 -0700 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by rj.sgi.com (8.12.9/8.12.2/linux-outbound_gateway-1.2) with SMTP id h61MuaWr020887 for ; Tue, 1 Jul 2003 15:56:40 -0700 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 IAA15229; Wed, 2 Jul 2003 08:55:37 +1000 Received: from frodo.melbourne.sgi.com (root@frodo.melbourne.sgi.com [134.14.55.153]) by wobbly.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id h61Mta3K070469; Wed, 2 Jul 2003 08:55:36 +1000 (EST) Received: from frodo.melbourne.sgi.com (nathans@localhost [127.0.0.1]) by frodo.melbourne.sgi.com (8.12.9/8.12.9/Debian-3) with ESMTP id h61MtQ5n000907; Wed, 2 Jul 2003 08:55:26 +1000 Received: (from nathans@localhost) by frodo.melbourne.sgi.com (8.12.9/8.12.9/Debian-3) id h61MtPvN000905; Wed, 2 Jul 2003 08:55:25 +1000 Date: Wed, 2 Jul 2003 08:55:24 +1000 From: Nathan Scott To: Sebastien Boving Cc: linux-xfs@oss.sgi.com Subject: Re: oops in 2.4.20-18.9XFS1.3.0pre2 Message-ID: <20030701225524.GB752@frodo> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.3i X-archive-position: 4529 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: nathans@sgi.com Precedence: bulk X-list: linux-xfs On Tue, Jul 01, 2003 at 12:42:26PM -0700, Sebastien Boving wrote: > > *, > > ftpd writing to an xfs filesystem (compiled from 2.4.20-18.9XFS1.3.0pre2 > for RH9 src rpm from oss.sgi.com ftp site, but without kdb) crashed, > leaving the following in the logs: > > > Unable to handle kernel NULL pointer dereference at virtual address 00000008 > printing eip: > f8afcbc4 > *pde = 00000000 > Oops: 0000 > nfsd iptable_filter ip_tables autofs nfs lockd sunrpc e1000 xfs keybdev > mousedev input hid usb-uhci usbcore ext3 jbd raid0 3w-xxxx sd_mod scsi_mod > CPU: 2 > EIP: 0060:[] Not tainted > EFLAGS: 00010202 > > EIP is at linvfs_permission [xfs] 0x14 (2.4.20-18.9XFS1.3.0pre2custom) Looks alot like a sync/iget interaction bug we were seeing recently - Steve fixed this a couple of weeks ago, the change was: --- /usr/tmp/TmpDir.2068614-0/linux/fs/xfs/xfs_inode.c_1.376 Wed Jul 2 08:51:27 2003 +++ /usr/tmp/TmpDir.2068614-0/linux/fs/xfs/xfs_inode.c_1.377 Wed Jul 2 08:51:27 2003 @@ -2629,7 +2629,8 @@ if (vp) { struct inode *inode = LINVFS_GET_IP(vp); - mark_inode_dirty_sync(inode); + if (!(inode->i_state & I_NEW)) + mark_inode_dirty_sync(inode); } wake_up(&ip->i_ipin_wait); cheers. -- Nathan From owner-linux-xfs@oss.sgi.com Tue Jul 1 16:15:55 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 01 Jul 2003 16:15:59 -0700 (PDT) Received: from rj.sgi.com (rj.SGI.COM [192.82.208.96]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h61NFt2x017702 for ; Tue, 1 Jul 2003 16:15:55 -0700 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by rj.sgi.com (8.12.9/8.12.2/linux-outbound_gateway-1.2) with SMTP id h61NFUWr023679 for ; Tue, 1 Jul 2003 16:15:30 -0700 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 JAA15384 for ; Wed, 2 Jul 2003 09:14:33 +1000 Received: from frodo.melbourne.sgi.com (root@frodo.melbourne.sgi.com [134.14.55.153]) by wobbly.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id h61NEV3K070542 for ; Wed, 2 Jul 2003 09:14:32 +1000 (EST) Received: from frodo.melbourne.sgi.com (nathans@localhost [127.0.0.1]) by frodo.melbourne.sgi.com (8.12.9/8.12.9/Debian-3) with ESMTP id h61NEM5n001008 for ; Wed, 2 Jul 2003 09:14:22 +1000 Received: (from nathans@localhost) by frodo.melbourne.sgi.com (8.12.9/8.12.9/Debian-3) id h61NEMHI001006 for linux-xfs@oss.sgi.com; Wed, 2 Jul 2003 09:14:22 +1000 Date: Wed, 2 Jul 2003 09:14:22 +1000 From: Nathan Scott To: linux-xfs@oss.sgi.com Subject: Re: library errors building XFS tools... Message-ID: <20030701231422.GC752@frodo> References: <20030628213811.GA5436@widomaker.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030628213811.GA5436@widomaker.com> User-Agent: Mutt/1.5.3i X-archive-position: 4530 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: nathans@sgi.com Precedence: bulk X-list: linux-xfs On Sat, Jun 28, 2003 at 05:38:14PM -0400, Charles Shannon Hendrix wrote: > > Why does the xfs tool build mix library files between /lib and /usr/lib? > The shared objects in /lib, the libtool stuff in /usr/lib... Some distributions require this. > In any case, I build attr and xfsprogs using the defaults and linking in > xfsdump still fails: > > p.o var.o /usr/lib/libuuid.a /lib/libhandle.so /lib/libattr.so > /lib/libdm.so ../librmt/.libs/librmt.al > gcc: /lib/libhandle.so: No such file or directory > gcc: /lib/libattr.so: No such file or directory > gcc: /lib/libdm.so: No such file or directory > > First of all, shared libraries should be linked with -llib, Hmm... are we missing a libtool flag perhaps? (Why "should be"?) > secondly, none of the libraries appears to be installed properly. How are you doing the build/install (exact command sequence)? > It seems like libtool is doing the wrong thing, and leaving out steps > like linking the .so files with the .so > I had to manually run this: > > % cd /lib > % ln -s libattr.so.1 libattr.so > % ln -s libhandle.so.1 libhandle.so > % ln -s libdm.so.0 libdm.so You should definately not have to do that. Are you doing a manual "configure"? See doc/INSTALL for recommended build steps. > Here are the OS and tool versions I'm using: > > Slackware 9.0 with a 2.4.20-xfs kernel > > attr-2.2.0 > dmapi-2.0.5 > xfsdump-2.2.6 > xfsprogs-2.3.9 > > autoconf-2.57 > automake-1.7.3 > cheers. -- Nathan From owner-linux-xfs@oss.sgi.com Tue Jul 1 16:19:15 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 01 Jul 2003 16:19:18 -0700 (PDT) Received: from rj.sgi.com (rj.SGI.COM [192.82.208.96]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h61NJE2x018124 for ; Tue, 1 Jul 2003 16:19:15 -0700 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by rj.sgi.com (8.12.9/8.12.2/linux-outbound_gateway-1.2) with SMTP id h61NInWr024083 for ; Tue, 1 Jul 2003 16:18:50 -0700 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 JAA15459; Wed, 2 Jul 2003 09:17:52 +1000 Received: from frodo.melbourne.sgi.com (root@frodo.melbourne.sgi.com [134.14.55.153]) by wobbly.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id h61NHp3K070580; Wed, 2 Jul 2003 09:17:51 +1000 (EST) Received: from frodo.melbourne.sgi.com (nathans@localhost [127.0.0.1]) by frodo.melbourne.sgi.com (8.12.9/8.12.9/Debian-3) with ESMTP id h61NHf5n001028; Wed, 2 Jul 2003 09:17:41 +1000 Received: (from nathans@localhost) by frodo.melbourne.sgi.com (8.12.9/8.12.9/Debian-3) id h61NHetJ001026; Wed, 2 Jul 2003 09:17:41 +1000 Date: Wed, 2 Jul 2003 09:17:40 +1000 From: Nathan Scott To: Austin Gonyou Cc: XFS List Subject: Re: XFS and Zero-filled files question. Message-ID: <20030701231740.GD752@frodo> References: <1057075562.1896.1.camel@portageek.digitalroadkill.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1057075562.1896.1.camel@portageek.digitalroadkill.net> User-Agent: Mutt/1.5.3i X-archive-position: 4531 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: nathans@sgi.com Precedence: bulk X-list: linux-xfs On Tue, Jul 01, 2003 at 11:06:02AM -0500, Austin Gonyou wrote: > This is not a question that I keep getting them or anything like that. I > remember that there was a TAKE a while back for rewriting a lot of the > pagebuf code once 1.3.x branch was started. I seem to recall this > directly affecting the file corruption issue and that it would all be > gone, save for a few known cases. > > > Could someone help refresh my memory about this? I can't seem to figure > out what to search for in my email archive. ;) > This was Steve's changes on the sync code path, not really a pagebuf change. Search for mail with sync in the subject or something like that. cheers. -- Nathan From owner-linux-xfs@oss.sgi.com Tue Jul 1 16:19:56 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 01 Jul 2003 16:20:00 -0700 (PDT) Received: from hermes.d2.com (ns50-untrust.d2.com [198.211.88.11]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h61NJs2x018438 for ; Tue, 1 Jul 2003 16:19:55 -0700 Received: from samoa-l (samoa-l [172.16.50.128]) by hermes.d2.com (8.12.2/8.12.2) with ESMTP id h61NGSDL026555; Tue, 1 Jul 2003 16:16:28 -0700 Date: Tue, 1 Jul 2003 16:20:06 -0700 (PDT) From: Sebastien Boving To: Nathan Scott cc: Subject: Re: oops in 2.4.20-18.9XFS1.3.0pre2 In-Reply-To: <20030701225524.GB752@frodo> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Scanned-By: MIMEDefang 2.6 (www dot roaringpenguin dot com slash mimedefang) X-archive-position: 4532 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: seb@d2.com Precedence: bulk X-list: linux-xfs On Wed, 2 Jul 2003, Nathan Scott wrote: > Looks alot like a sync/iget interaction bug we were seeing recently - > Steve fixed this a couple of weeks ago, the change was: > i was doing a lot of writes (40mb/s, probably as much writes as this stripe of 2 serial ATA's raid5's can take), and i have big write caches, i think (logbufs=8,logbsize=32768 as recommended in faq). i'll try the patch out, thanks. > --- /usr/tmp/TmpDir.2068614-0/linux/fs/xfs/xfs_inode.c_1.376 Wed Jul 2 08:51:27 2003 > +++ /usr/tmp/TmpDir.2068614-0/linux/fs/xfs/xfs_inode.c_1.377 Wed Jul 2 08:51:27 2003 > @@ -2629,7 +2629,8 @@ > if (vp) { > struct inode *inode = LINVFS_GET_IP(vp); > > - mark_inode_dirty_sync(inode); > + if (!(inode->i_state & I_NEW)) > + mark_inode_dirty_sync(inode); > } > > wake_up(&ip->i_ipin_wait); > > > cheers. > > From owner-linux-xfs@oss.sgi.com Tue Jul 1 17:28:47 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 01 Jul 2003 17:29:07 -0700 (PDT) Received: from enki.rimspace.net (130.146.174.203.mel.ntt.net.au [203.174.146.130] (may be forged)) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h620Sj2x019662 for ; Tue, 1 Jul 2003 17:28:47 -0700 Received: by enki.rimspace.net (Postfix, from userid 1000) id DB868D844563; Wed, 2 Jul 2003 10:28:44 +1000 (EST) To: Jason Parker-Burlingham Cc: linux-xfs@oss.sgi.com Subject: Re: Flash drive suitability for XFS journals In-Reply-To: <87n0fy9g8n.fsf@freezer.burling> (Jason Parker-Burlingham's message of "Tue, 01 Jul 2003 15:52:40 -0400") References: <87n0fy9g8n.fsf@freezer.burling> From: Daniel Pittman Date: Wed, 02 Jul 2003 10:28:44 +1000 Message-ID: <87fzlp4vr7.fsf@enki.rimspace.net> User-Agent: Gnus/5.090016 (Oort Gnus v0.16) XEmacs/21.5 (cassava) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-archive-position: 4533 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: daniel@rimspace.net Precedence: bulk X-list: linux-xfs On Tue, 01 Jul 2003, Jason Parker-Burlingham wrote: > While attempting to recover an unjournalled filesystem last week, it > occurred to me that it should be possible to store the XFS log on a > simple solid-state device. [...] > A little talk on a local LUG list pointed out that these things often > have a limited number of write cycles, typically in the millions. One > poster suggested that write levelling could reduce the impact of this > limitation Any of the off-the-shelf devices that emulate mass storage on flash do their own internal wear leveling, because otherwise the first few blocks, where Windows puts the FAT, die very quickly... [...] > 0) Will this really be useful? My hope is that storing the log on a > device which doesn't use the IDE bus will save the log from > becoming corrupted when the IDE disks start to fail. Very, very few IDE disk failures cause bus corruption. [...] > 3) Is there some other technology suitable for the small office > situation which might fill this need? You will almost certainly get better performance with a compact flash or PCMCIA flash card attached to a PCMCIA socket or to the IDE bus directly. Daniel -- We are always getting ready to live, but never living. -- Ralph Waldo Emerson, _Journals_, 1834 From owner-linux-xfs@oss.sgi.com Tue Jul 1 19:08:36 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 01 Jul 2003 19:08:51 -0700 (PDT) Received: from tolkor.sgi.com ([198.149.18.6]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h6228Z2x020824 for ; Tue, 1 Jul 2003 19:08:36 -0700 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by tolkor.sgi.com (8.12.9/8.12.2/linux-outbound_gateway-1.2) with SMTP id h622Q6mO022990 for ; Tue, 1 Jul 2003 21:26:07 -0500 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 MAA16913; Wed, 2 Jul 2003 12:07:11 +1000 Received: by kao2.melbourne.sgi.com (Postfix, from userid 16331) id C010ED84FE; Wed, 2 Jul 2003 12:07:10 +1000 (EST) Received: from kao2.melbourne.sgi.com (localhost [127.0.0.1]) by kao2.melbourne.sgi.com (Postfix) with ESMTP id BD6EF912D6; Wed, 2 Jul 2003 12:07:10 +1000 (EST) X-Mailer: exmh version 2.5 01/15/2001 with nmh-1.0.4 From: Keith Owens To: Sebastien Boving Cc: linux-xfs@oss.sgi.com Subject: Re: oops in 2.4.20-18.9XFS1.3.0pre2 In-reply-to: Your message of "Tue, 01 Jul 2003 13:31:50 MST." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 02 Jul 2003 12:07:05 +1000 Message-ID: <2675.1057111625@kao2.melbourne.sgi.com> X-archive-position: 4534 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: kaos@sgi.com Precedence: bulk X-list: linux-xfs On Tue, 1 Jul 2003 13:31:50 -0700 (PDT), Sebastien Boving wrote: >i indeed removed it. I was using the serial console on it and typed CTRL-a >to go to the beginning of the shell line, and it put me in kdb, stopping >the machine. It took a few secs before finding the 'go' option ;), and >since this box is prod i rather disabled the feature. You can change the kdb sequence for the serial console. Edit drivers/char/serial.c and set kdb_serial_str to a different string. I use this static char kdb_serial_str[] = "\eKDB"; so my way to enter kdb on the serial console is KDB, in upper case. From owner-linux-xfs@oss.sgi.com Tue Jul 1 19:39:04 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 01 Jul 2003 19:39:06 -0700 (PDT) Received: from zok.sgi.com (zok.SGI.COM [204.94.215.101]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h622d32x021395 for ; Tue, 1 Jul 2003 19:39:04 -0700 Received: from flecktone.americas.sgi.com (flecktone.americas.sgi.com [192.48.203.135]) by zok.sgi.com (8.12.9/8.12.2/linux-outbound_gateway-1.2) with ESMTP id h622cwiY021376 for ; Tue, 1 Jul 2003 19:38:58 -0700 Received: from daisy-e236.americas.sgi.com (daisy-e236.americas.sgi.com [128.162.236.214]) by flecktone.americas.sgi.com (8.12.9/8.12.9/generic_config-1.2) with ESMTP id h622bwqX7371942 for ; Tue, 1 Jul 2003 21:37:58 -0500 (CDT) Received: from penguin.americas.sgi.com (penguin.americas.sgi.com [128.162.240.135]) by daisy-e236.americas.sgi.com (8.12.9/SGI-server-1.8) with ESMTP id h622bvRn152088735 for ; Tue, 1 Jul 2003 21:37:58 -0500 (CDT) From: Eric Sandeen Received: by penguin.americas.sgi.com (8.11.6/SGI-client-1.7) id h622bol20162; Tue, 1 Jul 2003 21:37:50 -0500 Message-Id: <200307020237.h622bol20162@penguin.americas.sgi.com> Date: Tue, 1 Jul 2003 21:37:50 -0500 Subject: TAKE - Another sysctl fixup patch X-archive-position: 4535 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: sandeen@sgi.com Precedence: bulk X-list: linux-xfs Hm, I don't recall if this actually fixes anything... I don't think it does. :) But it makes it much harder to screw up the sysctl initializations in the code, now they're all neatly organized in tables, like this: pagebuf_param_t pb_params = { /* MIN DFLT MAX */ flush_interval: { HZ/2, HZ, 30*HZ }, age_buffer: { 1*HZ, 15*HZ, 300*HZ }, stats_clear: { 0, 0, 1 }, debug: { 0, 0, 1 }, }; *the crowd goes wild* ------------- rework sysctl initialization to avoid confusion Date: Tue Jul 1 19:35:27 PDT 2003 Workarea: penguin.americas.sgi.com:/src/sandeen/2.4.x-xfs/workarea-alwaysclean The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: xfs-linux:slinx:152419a linux/fs/xfs/xfs_rw.c - 1.381 linux/fs/xfs/xfs_vfsops.c - 1.424 linux/fs/xfs/pagebuf/page_buf_internal.h - 1.26 linux/fs/xfs/pagebuf/page_buf.c - 1.124 linux/fs/xfs/linux/xfs_globals.c - 1.53 linux/fs/xfs/linux/xfs_linux.h - 1.108 linux/fs/xfs/linux/xfs_super.c - 1.261 linux/fs/xfs/linux/xfs_sysctl.c - 1.23 linux/fs/xfs/linux/xfs_sysctl.h - 1.16 From owner-linux-xfs@oss.sgi.com Tue Jul 1 19:40:30 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 01 Jul 2003 19:40:33 -0700 (PDT) Received: from zok.sgi.com (zok.SGI.COM [204.94.215.101]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h622eU2x021799 for ; Tue, 1 Jul 2003 19:40:30 -0700 Received: from flecktone.americas.sgi.com (flecktone.americas.sgi.com [192.48.203.135]) by zok.sgi.com (8.12.9/8.12.2/linux-outbound_gateway-1.2) with ESMTP id h622ePiY021589 for ; Tue, 1 Jul 2003 19:40:25 -0700 Received: from daisy-e236.americas.sgi.com (daisy-e236.americas.sgi.com [128.162.236.214]) by flecktone.americas.sgi.com (8.12.9/8.12.9/generic_config-1.2) with ESMTP id h622dOqX7391876 for ; Tue, 1 Jul 2003 21:39:24 -0500 (CDT) Received: from penguin.americas.sgi.com (penguin.americas.sgi.com [128.162.240.135]) by daisy-e236.americas.sgi.com (8.12.9/SGI-server-1.8) with ESMTP id h622dORn152009418 for ; Tue, 1 Jul 2003 21:39:24 -0500 (CDT) From: Eric Sandeen Received: by penguin.americas.sgi.com (8.11.6/SGI-client-1.7) id h622dGr20227; Tue, 1 Jul 2003 21:39:16 -0500 Message-Id: <200307020239.h622dGr20227@penguin.americas.sgi.com> Date: Tue, 1 Jul 2003 21:39:16 -0500 Subject: TAKE - Document those syctls X-archive-position: 4536 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: sandeen@sgi.com Precedence: bulk X-list: linux-xfs Add documentation.... Document sysctls Date: Tue Jul 1 19:38:28 PDT 2003 Workarea: penguin.americas.sgi.com:/src/sandeen/2.4.x-xfs/workarea-alwaysclean The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:152420a linux/Documentation/filesystems/xfs.txt - 1.13 From owner-linux-xfs@oss.sgi.com Tue Jul 1 21:13:53 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 01 Jul 2003 21:14:08 -0700 (PDT) Received: from tolkor.sgi.com ([198.149.18.6]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h624Dq2x022981 for ; Tue, 1 Jul 2003 21:13:53 -0700 Received: from sherman.melbourne.sgi.com (sherman.melbourne.sgi.com [134.14.54.232]) by tolkor.sgi.com (8.12.9/8.12.2/linux-outbound_gateway-1.2) with ESMTP id h624VNmO003898 for ; Tue, 1 Jul 2003 23:31:24 -0500 Received: (from kaos@localhost) by sherman.melbourne.sgi.com (8.11.6/8.11.6) id h624Ciq20051; Wed, 2 Jul 2003 14:12:44 +1000 Date: Wed, 2 Jul 2003 14:12:44 +1000 From: Keith Owens Message-Id: <200307020412.h624Ciq20051@sherman.melbourne.sgi.com> Subject: TAKE - Upgrade XFS to kdb v4.3-2.4.21-{common,i386}-3 X-archive-position: 4537 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: kaos@sherman.melbourne.sgi.com Precedence: bulk X-list: linux-xfs Upgrade XFS to kdb v4.3-2.4.21-{common,i386}-3 Date: Tue Jul 1 21:07:03 PDT 2003 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:152422a linux/kdb/modules/kdbm_task.c - 1.1 linux/arch/i386/kernel/smp.c - 1.44 linux/kdb/modules/Makefile - 1.17 linux/kdb/ChangeLog - 1.33 linux/arch/i386/kdb/ChangeLog - 1.22 From owner-linux-xfs@oss.sgi.com Wed Jul 2 02:25:22 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 02 Jul 2003 02:25:39 -0700 (PDT) Received: from rrzd2.rz.uni-regensburg.de (root@rrzd2.rz.uni-regensburg.de [132.199.1.12]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h629PK2x028621 for ; Wed, 2 Jul 2003 02:25:21 -0700 Received: from rss1.rz.uni-regensburg.de (rss1.rz.uni-regensburg.de [132.199.1.200]) by rrzd2.rz.uni-regensburg.de (8.12.3/8.12.3/Debian -4) with SMTP id h629PIp8015711 for ; Wed, 2 Jul 2003 11:25:19 +0200 Received: (qmail 101 invoked from network); 2 Jul 2003 11:25:18 +0200 Received: from pc9391.physik.uni-regensburg.de (HELO pc9391) (guc28561@132.199.98.219) by rss1.rz.uni-regensburg.de with SMTP; 2 Jul 2003 11:25:18 +0200 Date: Wed, 2 Jul 2003 11:25:18 +0200 From: Christian Guggenberger To: christian.guggenberger@physik.uni-regensburg.de Cc: linux-xfs@oss.sgi.com Subject: Re: EFSCORRUPTED returned from file xfs_ialloc.c Message-ID: <20030702112518.A11832@pc9391.uni-regensburg.de> References: <1057095191.483.18.camel@bonnie79> Mime-Version: 1.0 Content-Type: text/plain; format=flowed; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit In-Reply-To: <1057095191.483.18.camel@bonnie79>; from christian.guggenberger@physik.uni-regensburg.de on Tue, Jul 01, 2003 at 23:33:11 +0200 X-Mailer: Balsa 1.2.4 Lines: 31 X-archive-position: 4538 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: Christian.Guggenberger@physik.uni-regensburg.de Precedence: bulk X-list: linux-xfs On 01.07.2003 23:33 Christian Guggenberger wrote: > Hi Folks, > > Just, after starting a weekly xfs_fsr on a 400GB lvm device (HW Raid), > the filesystem shut down unclean. Now i can't mount it again. > This filesystem was exported via nfs. > just an hour later, the second volume on the hardware Raid5 crashed. (6*160GB) Both filesystems are not mountable and not repairable with xfs_repair (xfs_repair -L should do, but I have not tried yet). If I trust the HW Raid's Firmware it should be running fine, although one of the disks has some bad blocks _and_ I/O timeouts. I'm running Kernel SGI XFS snapshot 2.4.20-2003-01-14_00:43_UTC with ACLs, quota, no debug enabled Here's the kernel log for mounting both volumes with default options: XFS mounting filesystem lvm(58,0) Starting XFS recovery on filesystem: lvm(58,0) (dev: 58/0) XFS: failed to read root inode XFS mounting filesystem lvm(58,1) Starting XFS recovery on filesystem: lvm(58,1) (dev: 58/1) XFS: dirty log entry has mismatched uuid - can't recover XFS: log mount/recovery failed XFS: log mount failed what should I do now? Try xfs_repair -L ? Go ahead with recent cvs Kernels? Christian From owner-linux-xfs@oss.sgi.com Wed Jul 2 09:05:34 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 02 Jul 2003 09:05:58 -0700 (PDT) Received: from zok.sgi.com (zok.SGI.COM [204.94.215.101]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h62G5X2x004568 for ; Wed, 2 Jul 2003 09:05:34 -0700 Received: from stout.americas.sgi.com (stout.americas.sgi.com [128.162.232.50]) by zok.sgi.com (8.12.9/8.12.2/linux-outbound_gateway-1.2) with ESMTP id h62G5SiY026760 for ; Wed, 2 Jul 2003 09:05:28 -0700 Received: from stout.americas.sgi.com (localhost [127.0.0.1]) by stout.americas.sgi.com (8.12.8/8.12.8) with ESMTP id h62G5RiV009383 for ; Wed, 2 Jul 2003 11:05:27 -0500 Received: (from sandeen@localhost) by stout.americas.sgi.com (8.12.8/8.12.8/Submit) id h62G5RrE009381 for linux-xfs@oss.sgi.com; Wed, 2 Jul 2003 11:05:27 -0500 Date: Wed, 2 Jul 2003 11:05:27 -0500 From: Eric Sandeen Message-Id: <200307021605.h62G5RrE009381@stout.americas.sgi.com> Subject: TAKE - Use C99 initializers on sysctl structs X-archive-position: 4539 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: sandeen@stout.americas.sgi.com Precedence: bulk X-list: linux-xfs Nate points out that this is the year 2003, and I was living in the past... Use C99 initializers on sysctl structs Date: Wed Jul 2 09:04:51 PDT 2003 Workarea: stout.americas.sgi.com:/localhome/src/sandeen/2.4.x-xfs/workarea-alwaysclean The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: xfs-linux:slinx:152435a linux/fs/xfs/pagebuf/page_buf.c - 1.126 linux/fs/xfs/linux/xfs_globals.c - 1.54 From owner-linux-xfs@oss.sgi.com Wed Jul 2 10:33:34 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 02 Jul 2003 10:34:02 -0700 (PDT) Received: from hermes.d2.com (ns50-untrust.d2.com [198.211.88.11]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h62HXV2x006183 for ; Wed, 2 Jul 2003 10:33:33 -0700 Received: from samoa-l (samoa-l [172.16.50.128]) by hermes.d2.com (8.12.2/8.12.2) with ESMTP id h62HTvDL005286 for ; Wed, 2 Jul 2003 10:29:57 -0700 Date: Wed, 2 Jul 2003 10:33:44 -0700 (PDT) From: Sebastien Boving To: Subject: Re: oops in 2.4.20-18.9XFS1.3.0pre2 In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Scanned-By: MIMEDefang 2.6 (www dot roaringpenguin dot com slash mimedefang) X-archive-position: 4540 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: seb@d2.com Precedence: bulk X-list: linux-xfs I did the xfs_repair this morning (first -n, ...). It worked fine, didn't spit out anything in particular (but i kept the output in case someone's interested). I can access those dirs again, all data seems to be there. The patch you gave me below was already installed in xfs_inode.c (1.3.0pre2), so that shouldn't have been the issue. I'm getting XFS 1.2 in RH 2.4.2(0|1) kernel ready for next wednesday's downtime. Should the cmd-rpms for 1.3.0pre2 work with XFS1.2 kernel, or should i be cautious and switch each time i change kernel? I currently have: xfsprogs-2.4.12-0 xfsdump-2.2.12-0 xfsprogs-devel-2.4.12-0 thanks for all the help and suggestions and bringing this excellent fs to linux! -seb. On Tue, 1 Jul 2003, Sebastien Boving wrote: > > On Wed, 2 Jul 2003, Nathan Scott wrote: > > > Looks alot like a sync/iget interaction bug we were seeing recently - > > Steve fixed this a couple of weeks ago, the change was: > > > > > i was doing a lot of writes (40mb/s, probably as much writes as this > stripe of 2 serial ATA's raid5's can take), and i have big write > caches, i think (logbufs=8,logbsize=32768 as recommended in faq). > > i'll try the patch out, thanks. > > > > --- /usr/tmp/TmpDir.2068614-0/linux/fs/xfs/xfs_inode.c_1.376 Wed Jul 2 08:51:27 2003 > > +++ /usr/tmp/TmpDir.2068614-0/linux/fs/xfs/xfs_inode.c_1.377 Wed Jul 2 08:51:27 2003 > > @@ -2629,7 +2629,8 @@ > > if (vp) { > > struct inode *inode = LINVFS_GET_IP(vp); > > > > - mark_inode_dirty_sync(inode); > > + if (!(inode->i_state & I_NEW)) > > + mark_inode_dirty_sync(inode); > > } > > > > wake_up(&ip->i_ipin_wait); > > > > > > cheers. > > > > > > From owner-linux-xfs@oss.sgi.com Wed Jul 2 14:34:30 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 02 Jul 2003 14:34:47 -0700 (PDT) Received: from main.gmane.org (main.gmane.org [80.91.224.249]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h62LYS2x009717 for ; Wed, 2 Jul 2003 14:34:30 -0700 Received: from list by main.gmane.org with local (Exim 3.35 #1 (Debian)) id 19XpEh-0007Cz-00 for ; Wed, 02 Jul 2003 23:33:55 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: linux-xfs@oss.sgi.com Received: from news by main.gmane.org with local (Exim 3.35 #1 (Debian)) id 19XpEg-0007Cj-00 for ; Wed, 02 Jul 2003 23:33:54 +0200 From: Jason Parker-Burlingham Subject: Re: Flash drive suitability for XFS journals Date: Wed, 02 Jul 2003 17:34:21 -0400 Lines: 34 Message-ID: <87of0cfw9u.fsf@freezer.burling> References: <87n0fy9g8n.fsf@freezer.burling> <87fzlp4vr7.fsf@enki.rimspace.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Complaints-To: usenet@main.gmane.org User-Agent: Gnus/5.1001 (Gnus v5.10.1) Emacs/21.3 (gnu/linux) Cancel-Lock: sha1:n50O31iYQp26nVzefvt0N+x7vSc= X-archive-position: 4542 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: jasonp@panix.com Precedence: bulk X-list: linux-xfs Daniel Pittman writes: > On Tue, 01 Jul 2003, Jason Parker-Burlingham wrote: >> 0) Will this really be useful? My hope is that storing the log on a >> device which doesn't use the IDE bus will save the log from >> becoming corrupted when the IDE disks start to fail. > Very, very few IDE disk failures cause bus corruption. I was thinking of IDE bus failures; the hope is that by purchasing a fairly inexpensive piece of equipment, the filesystem log could be stored in such a way as to be less prone to the same sorts of failure mode as the disk with the data on it. The next step up would be to buy pairs of IDE disks and use RAID for more concrete protection against disk failure, but I anticipate that the devices I want to use will cost perhaps less than half the cost of a second disk. Perhaps I have something of an XY problem here. My experience with data recovery doesn't endear me to it, so I am looking for small changes I can make to existing systems to reduce the amount of time spent searching for data on a failing disk or corrupt filesystem. I assumed the log would be critical to correctly recovering an XFS filesystem, but I see that cmd/xfsprogs/repair/README talks about zeroing the log almost immediately so perhaps that's not as important as I thought. I want to be able to recommend XFS over the Linux journalling filesystem alternatives, and having a better idea of what to do when the tools fail would be extremely helpful. -- Stay up-to-date on what I'm doing lately: http://www.panix.com/~jasonp From owner-linux-xfs@oss.sgi.com Wed Jul 2 16:02:24 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 02 Jul 2003 16:02:45 -0700 (PDT) Received: from linux-sxs.org (dhcp065-024-128-253.columbus.rr.com [65.24.128.253]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h62N2M2x010808 for ; Wed, 2 Jul 2003 16:02:23 -0700 Received: from linux-sxs.org (localhost [127.0.0.1]) by linux-sxs.org (8.12.9/8.12.9) with ESMTP id h62LFZH7030806; Wed, 2 Jul 2003 17:15:35 -0400 Received: from localhost (netllama@localhost) by linux-sxs.org (8.12.9/8.12.9/Submit) with ESMTP id h62LFZg3024532; Wed, 2 Jul 2003 17:15:35 -0400 Date: Wed, 2 Jul 2003 17:15:35 -0400 (EDT) From: Net Llama! To: Jan Kuemmel cc: linux-xfs@oss.sgi.com Subject: Re: unrepairable filesystem In-Reply-To: <3F0302FD.5040308@gluff.org> Message-ID: References: <3F0302FD.5040308@gluff.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: OK, scanned by File::Scan,ClamAV X-Scanned-By: MIMEDefang 2.34 X-archive-position: 4543 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: netllama@linux-sxs.org Precedence: bulk X-list: linux-xfs I could be wrong, but i don't think you're supposed to be running xfs_repair on a mounted filesystem. On Wed, 2 Jul 2003, Jan Kuemmel wrote: > Hi, > I use linux 2.4.20-xfs (dont know the exact xfs-patch-version, as it was > a gentoo patch, but must be from around march 2003) on my laptop. Some > day, I used suspend-to-ram and went away. When I returned, the battery > was empty. I restarted the system, but my filesystem is corrupt now. > Some files are zero-filled and a program reports an error while trying > to write or modify some other file. > I tried to use xfs_repair as I thougt it had been made for such a > purpose. Unfortunately, it did not work as I expected. It stops at phase > 7 with the following error message: > > Phase 7 - verify and correct link counts... > corrupt dinode 9467815, extent total = 1, nblocks = 0. Unmount and run > xfs_repair. > fatal error -- couldn't map inode 9467815, err = 990 > > I tried to use it again, but the effect was the same. > Is there any way to repair the xfs filesystem (besides copying all files > somewhere else and creating another file system) ? > > jan > > > The complete xfs_repair output: > > Phase 1 - find and verify superblock... > Phase 2 - using internal log > - zero log... > - scan filesystem freespace and inode maps... > - 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 > data fork in ino 4980237 claims free block 313636 > data fork in ino 4980237 claims free block 313637 > data fork in ino 4980237 claims free block 313638 > data fork in ino 4980237 claims free block 313639 > data fork in ino 4980237 claims free block 313640 > data fork in ino 4980237 claims free block 313641 > data fork in ino 4980237 claims free block 313642 > data fork in ino 4980237 claims free block 313643 > data fork in ino 4980237 claims free block 313644 > data fork in ino 4980237 claims free block 313645 > data fork in ino 4980237 claims free block 313646 > data fork in ino 4980237 claims free block 313647 > data fork in ino 4980237 claims free block 313648 > data fork in ino 4980237 claims free block 313649 > data fork in ino 4980237 claims free block 313650 > data fork in ino 4980237 claims free block 313651 > data fork in ino 4980237 claims free block 313652 > data fork in ino 4980237 claims free block 313653 > data fork in ino 4980237 claims free block 313654 > data fork in ino 4980237 claims free block 313655 > data fork in ino 4980237 claims free block 313656 > data fork in ino 4980237 claims free block 313657 > data fork in ino 4980237 claims free block 313658 > data fork in ino 4980237 claims free block 313659 > data fork in ino 4980237 claims free block 313660 > data fork in ino 4980237 claims free block 313661 > data fork in ino 4980237 claims free block 313662 > data fork in ino 4980237 claims free block 313663 > data fork in ino 4980237 claims free block 313664 > data fork in ino 4980237 claims free block 313665 > data fork in ino 4980237 claims free block 313666 > data fork in ino 4980237 claims free block 313667 > data fork in ino 4980237 claims free block 313668 > data fork in ino 4980237 claims free block 313669 > data fork in ino 4980237 claims free block 313670 > data fork in ino 4980237 claims free block 313671 > data fork in ino 4980237 claims free block 313672 > data fork in ino 4980237 claims free block 313673 > data fork in ino 4980237 claims free block 313674 > data fork in ino 4980237 claims free block 313675 > data fork in ino 4980237 claims free block 313676 > data fork in ino 4980237 claims free block 313677 > data fork in ino 4980237 claims free block 313678 > data fork in ino 4980237 claims free block 313679 > data fork in ino 4980237 claims free block 313680 > data fork in ino 4980237 claims free block 313681 > data fork in ino 4980237 claims free block 313682 > data fork in ino 4980237 claims free block 313683 > data fork in ino 4980237 claims free block 313684 > data fork in ino 4980237 claims free block 313685 > data fork in ino 4980237 claims free block 313686 > data fork in ino 4980237 claims free block 313687 > data fork in ino 4980237 claims free block 313688 > data fork in ino 4980237 claims free block 313689 > data fork in ino 4980237 claims free block 313690 > data fork in ino 4980237 claims free block 313691 > data fork in ino 4980237 claims free block 313692 > data fork in ino 4980237 claims free block 313693 > data fork in ino 4980237 claims free block 313694 > data fork in ino 4980237 claims free block 313695 > data fork in ino 4980237 claims free block 313696 > data fork in ino 4980237 claims free block 313697 > data fork in ino 4980237 claims free block 313698 > data fork in ino 4980237 claims free block 313699 > data fork in ino 4980237 claims free block 313700 > data fork in ino 4980237 claims free block 313701 > data fork in ino 4980237 claims free block 313702 > data fork in ino 4980237 claims free block 313703 > data fork in ino 4980237 claims free block 313704 > data fork in ino 4980237 claims free block 313705 > data fork in ino 4980237 claims free block 313706 > data fork in ino 4980237 claims free block 313707 > data fork in ino 4980237 claims free block 313708 > data fork in ino 4980237 claims free block 313709 > data fork in ino 4980237 claims free block 313710 > data fork in ino 4980237 claims free block 313711 > data fork in ino 4980237 claims free block 313712 > data fork in ino 4980237 claims free block 313713 > data fork in ino 4980237 claims free block 313714 > data fork in ino 4980237 claims free block 313715 > data fork in ino 4980237 claims free block 313716 > data fork in ino 4980237 claims free block 313717 > data fork in ino 4980237 claims free block 313718 > data fork in ino 4980237 claims free block 313719 > data fork in ino 4980237 claims free block 313720 > data fork in ino 4980237 claims free block 313721 > data fork in ino 4980237 claims free block 313722 > data fork in ino 4980237 claims free block 313723 > data fork in ino 4980237 claims free block 313724 > data fork in ino 4980237 claims free block 313725 > data fork in ino 4980237 claims free block 313726 > data fork in ino 4980237 claims free block 313727 > data fork in ino 4980237 claims free block 313728 > data fork in ino 4980237 claims free block 313729 > data fork in ino 4980237 claims free block 313730 > data fork in ino 4980237 claims free block 313731 > data fork in ino 4980237 claims free block 313732 > data fork in ino 4980237 claims free block 313733 > data fork in ino 4980237 claims free block 313734 > data fork in ino 4980237 claims free block 313735 > data fork in ino 4980237 claims free block 313736 > data fork in ino 4980237 claims free block 313737 > data fork in ino 4980237 claims free block 313738 > data fork in ino 4980237 claims free block 313739 > data fork in ino 4980237 claims free block 313740 > data fork in ino 4980237 claims free block 313741 > data fork in ino 4980237 claims free block 313742 > data fork in ino 4980237 claims free block 313743 > data fork in ino 4980237 claims free block 313744 > data fork in ino 4980237 claims free block 313745 > data fork in ino 4980237 claims free block 313746 > data fork in ino 4980237 claims free block 313747 > data fork in ino 4980237 claims free block 313748 > data fork in ino 4980237 claims free block 313749 > data fork in ino 4980237 claims free block 313750 > data fork in ino 4980237 claims free block 313751 > data fork in ino 4980237 claims free block 313752 > data fork in ino 4980237 claims free block 313753 > data fork in ino 4980237 claims free block 313754 > data fork in ino 4980237 claims free block 313755 > data fork in ino 4980237 claims free block 313756 > data fork in ino 4980237 claims free block 313757 > data fork in ino 4980237 claims free block 313758 > data fork in ino 4980237 claims free block 313759 > data fork in ino 4980237 claims free block 313760 > data fork in ino 4980237 claims free block 313761 > data fork in ino 4980237 claims free block 313762 > data fork in ino 4980237 claims free block 313763 > data fork in ino 4980237 claims free block 313764 > data fork in ino 4980237 claims free block 313765 > data fork in ino 4980237 claims free block 313766 > data fork in ino 4980237 claims free block 313767 > data fork in ino 4980237 claims free block 313768 > data fork in ino 4980237 claims free block 313769 > data fork in ino 4980237 claims free block 313770 > data fork in ino 4980237 claims free block 313771 > data fork in ino 4980237 claims free block 313772 > data fork in ino 4980237 claims free block 313773 > data fork in ino 4980237 claims free block 313774 > data fork in ino 4980237 claims free block 313775 > data fork in ino 4980237 claims free block 313776 > data fork in ino 4980237 claims free block 313777 > data fork in ino 4980237 claims free block 313778 > data fork in ino 4980237 claims free block 313779 > data fork in ino 4980237 claims free block 313780 > data fork in ino 4980237 claims free block 313781 > data fork in ino 4980237 claims free block 313782 > data fork in ino 4980237 claims free block 313783 > data fork in ino 4980237 claims free block 313784 > data fork in ino 4980237 claims free block 313785 > data fork in ino 4980237 claims free block 313786 > data fork in ino 4980237 claims free block 313787 > data fork in ino 4980237 claims free block 313788 > data fork in ino 4980237 claims free block 313789 > data fork in ino 4980237 claims free block 313790 > data fork in ino 4980237 claims free block 313791 > data fork in ino 4980237 claims free block 313792 > data fork in ino 4980237 claims free block 313793 > data fork in ino 4980237 claims free block 313794 > data fork in ino 4980237 claims free block 313795 > data fork in ino 4980237 claims free block 313796 > data fork in ino 4980237 claims free block 313797 > data fork in ino 4980237 claims free block 313798 > data fork in ino 4980237 claims free block 313799 > data fork in ino 4980237 claims free block 313800 > data fork in ino 4980237 claims free block 313801 > data fork in ino 4980237 claims free block 313802 > data fork in ino 4980237 claims free block 313803 > data fork in ino 4980237 claims free block 313804 > data fork in ino 4980237 claims free block 313805 > data fork in ino 4980237 claims free block 313806 > data fork in ino 4980237 claims free block 313807 > data fork in ino 4980237 claims free block 313808 > data fork in ino 4980237 claims free block 313809 > data fork in ino 4980237 claims free block 313810 > data fork in ino 4980237 claims free block 313811 > data fork in ino 4980237 claims free block 313812 > data fork in ino 4980237 claims free block 313813 > data fork in ino 4980237 claims free block 313814 > data fork in ino 4980237 claims free block 313815 > data fork in ino 4980237 claims free block 313816 > data fork in ino 4980237 claims free block 313817 > data fork in ino 4980237 claims free block 313818 > data fork in ino 4980237 claims free block 313819 > data fork in ino 4980237 claims free block 313820 > data fork in ino 4980237 claims free block 313821 > data fork in ino 4980237 claims free block 313822 > data fork in ino 4980237 claims free block 313823 > data fork in ino 4980237 claims free block 313824 > data fork in ino 4980237 claims free block 313825 > data fork in ino 4980237 claims free block 313826 > data fork in ino 4980237 claims free block 313827 > data fork in ino 4980237 claims free block 313828 > data fork in ino 4980237 claims free block 313829 > data fork in ino 4980237 claims free block 313830 > data fork in ino 4980237 claims free block 313831 > data fork in ino 4980237 claims free block 313832 > data fork in ino 4980237 claims free block 313833 > data fork in ino 4980237 claims free block 313834 > data fork in ino 4980237 claims free block 313835 > data fork in ino 4980237 claims free block 313836 > data fork in ino 4980237 claims free block 313837 > data fork in ino 4980237 claims free block 313838 > data fork in ino 4980237 claims free block 313839 > data fork in ino 4980237 claims free block 313840 > data fork in ino 4980237 claims free block 313841 > data fork in ino 4980237 claims free block 313842 > data fork in ino 4980237 claims free block 313843 > data fork in ino 4980237 claims free block 313844 > data fork in ino 4980237 claims free block 313845 > data fork in ino 4980237 claims free block 313846 > data fork in ino 4980237 claims free block 313847 > data fork in ino 4980237 claims free block 313848 > data fork in ino 4980237 claims free block 313849 > data fork in ino 4980237 claims free block 313850 > data fork in ino 4980237 claims free block 313851 > data fork in ino 4980237 claims free block 313852 > data fork in ino 4980237 claims free block 313853 > data fork in ino 4980237 claims free block 313854 > data fork in ino 4980237 claims free block 313855 > data fork in ino 4980237 claims free block 313856 > data fork in ino 4980237 claims free block 313857 > data fork in ino 4980237 claims free block 313858 > data fork in ino 4980237 claims free block 313859 > data fork in ino 4980237 claims free block 313860 > data fork in ino 4980237 claims free block 313861 > data fork in ino 4980237 claims free block 313862 > data fork in ino 4980237 claims free block 313863 > data fork in ino 4980237 claims free block 313864 > data fork in ino 4980237 claims free block 313865 > data fork in ino 4980237 claims free block 313866 > data fork in ino 4980237 claims free block 313867 > data fork in ino 4980237 claims free block 313868 > data fork in ino 4980237 claims free block 313869 > data fork in ino 4980237 claims free block 313870 > data fork in ino 4980237 claims free block 313871 > data fork in ino 4980237 claims free block 313872 > data fork in ino 4980237 claims free block 313873 > data fork in ino 4980237 claims free block 313874 > data fork in ino 4980237 claims free block 313875 > data fork in ino 4980237 claims free block 313876 > data fork in ino 4980237 claims free block 313877 > data fork in ino 4980237 claims free block 313878 > data fork in ino 4980237 claims free block 313879 > data fork in ino 4980237 claims free block 313880 > data fork in ino 4980237 claims free block 313881 > data fork in ino 4980237 claims free block 313882 > data fork in ino 4980237 claims free block 313883 > data fork in ino 4980237 claims free block 313884 > data fork in ino 4980237 claims free block 313885 > data fork in ino 4980237 claims free block 313886 > data fork in ino 4980237 claims free block 313887 > data fork in ino 4980237 claims free block 313888 > data fork in ino 4980237 claims free block 313889 > data fork in ino 4980237 claims free block 313890 > data fork in ino 4980237 claims free block 313891 > data fork in ino 4980237 claims free block 313892 > data fork in ino 4980237 claims free block 313893 > data fork in ino 4980237 claims free block 313894 > data fork in ino 4980237 claims free block 313895 > data fork in ino 4980237 claims free block 313896 > data fork in ino 4980237 claims free block 313897 > data fork in ino 4980237 claims free block 313898 > data fork in ino 4980237 claims free block 313899 > data fork in ino 4980237 claims free block 313900 > data fork in ino 4980237 claims free block 313901 > data fork in ino 4980237 claims free block 313902 > data fork in ino 4980237 claims free block 313903 > data fork in ino 4980237 claims free block 313904 > data fork in ino 4980237 claims free block 313905 > data fork in ino 4980237 claims free block 313906 > data fork in ino 4980237 claims free block 313907 > data fork in ino 4980237 claims free block 313908 > data fork in ino 4980237 claims free block 313909 > data fork in ino 4980237 claims free block 313910 > data fork in ino 4980237 claims free block 313911 > data fork in ino 4980237 claims free block 313912 > data fork in ino 4980237 claims free block 313913 > data fork in ino 4980237 claims free block 313914 > data fork in ino 4980237 claims free block 313915 > data fork in ino 4980237 claims free block 313916 > data fork in ino 4980237 claims free block 313917 > data fork in ino 4980237 claims free block 313918 > data fork in ino 4980237 claims free block 313919 > data fork in ino 4980237 claims free block 313920 > data fork in ino 4980237 claims free block 313921 > data fork in ino 4980237 claims free block 313922 > data fork in ino 4980237 claims free block 313923 > data fork in ino 4980237 claims free block 313924 > data fork in ino 4980237 claims free block 313925 > data fork in ino 4980237 claims free block 313926 > data fork in ino 4980237 claims free block 313927 > data fork in ino 4980237 claims free block 313928 > data fork in ino 4980237 claims free block 313929 > data fork in ino 4980237 claims free block 313930 > data fork in ino 4980237 claims free block 313931 > data fork in ino 4980237 claims free block 313932 > data fork in ino 4980237 claims free block 313933 > data fork in ino 4980237 claims free block 313934 > data fork in ino 4980237 claims free block 313935 > data fork in ino 4980237 claims free block 313936 > data fork in ino 4980237 claims free block 313937 > data fork in ino 4980237 claims free block 313938 > data fork in ino 4980237 claims free block 313939 > data fork in ino 4980237 claims free block 313940 > data fork in ino 4980237 claims free block 313941 > data fork in ino 4980237 claims free block 313942 > data fork in ino 4980237 claims free block 313943 > data fork in ino 4980237 claims free block 313944 > data fork in ino 4980237 claims free block 313945 > data fork in ino 4980237 claims free block 313946 > data fork in ino 4980237 claims free block 313947 > data fork in ino 4980237 claims free block 313948 > data fork in ino 4980237 claims free block 313949 > data fork in ino 4980237 claims free block 313950 > data fork in ino 4980237 claims free block 313951 > data fork in ino 4980237 claims free block 313952 > data fork in ino 4980237 claims free block 313953 > data fork in ino 4980237 claims free block 313954 > data fork in ino 4980237 claims free block 313955 > data fork in ino 4980237 claims free block 313956 > data fork in ino 4980237 claims free block 313957 > data fork in ino 4980237 claims free block 313958 > data fork in ino 4980237 claims free block 313959 > data fork in ino 4980237 claims free block 313960 > data fork in ino 4980237 claims free block 313961 > data fork in ino 4980237 claims free block 313962 > data fork in ino 4980237 claims free block 313963 > data fork in ino 4980237 claims free block 313964 > data fork in ino 4980237 claims free block 313965 > data fork in ino 4980237 claims free block 313966 > data fork in ino 4980237 claims free block 313967 > data fork in ino 4980237 claims free block 313968 > data fork in ino 4980237 claims free block 313969 > data fork in ino 4980237 claims free block 313970 > data fork in ino 4980237 claims free block 313971 > data fork in ino 4980237 claims free block 313972 > data fork in ino 4980237 claims free block 313973 > data fork in ino 4980237 claims free block 313974 > data fork in ino 4980237 claims free block 313975 > data fork in ino 4980237 claims free block 313976 > data fork in ino 4980237 claims free block 313977 > data fork in ino 4980237 claims free block 313978 > data fork in ino 4980237 claims free block 313979 > data fork in ino 4980237 claims free block 313980 > data fork in ino 4980237 claims free block 313981 > data fork in ino 4980237 claims free block 313982 > data fork in ino 4980237 claims free block 313983 > data fork in ino 4980237 claims free block 313984 > data fork in ino 4980237 claims free block 313985 > data fork in ino 4980237 claims free block 313986 > data fork in ino 4980237 claims free block 313987 > data fork in ino 4980237 claims free block 313988 > data fork in ino 4980237 claims free block 313989 > data fork in ino 4980237 claims free block 313990 > data fork in ino 4980237 claims free block 313991 > data fork in ino 4980237 claims free block 313992 > data fork in ino 4980237 claims free block 313993 > data fork in ino 4980237 claims free block 313994 > data fork in ino 4980237 claims free block 313995 > data fork in ino 4980237 claims free block 313996 > data fork in ino 4980237 claims free block 313997 > data fork in ino 4980237 claims free block 313998 > data fork in ino 4980237 claims free block 313999 > data fork in ino 4980237 claims free block 314000 > data fork in ino 4980237 claims free block 314001 > data fork in ino 4980237 claims free block 314002 > data fork in ino 4980237 claims free block 314003 > data fork in ino 4980237 claims free block 314004 > data fork in ino 4980237 claims free block 314005 > data fork in ino 4980237 claims free block 314006 > data fork in ino 4980237 claims free block 314007 > data fork in ino 4980237 claims free block 314008 > data fork in ino 4980237 claims free block 314009 > data fork in ino 4980237 claims free block 314010 > data fork in ino 4980237 claims free block 314011 > data fork in ino 4980237 claims free block 314012 > data fork in ino 4980237 claims free block 314013 > data fork in ino 4980237 claims free block 314014 > data fork in ino 4980237 claims free block 314015 > data fork in ino 4980237 claims free block 314016 > data fork in ino 4980237 claims free block 314017 > data fork in ino 4980237 claims free block 314018 > data fork in ino 4980237 claims free block 314019 > data fork in ino 4980237 claims free block 314020 > data fork in ino 4980237 claims free block 314021 > data fork in ino 4980237 claims free block 314022 > data fork in ino 4980237 claims free block 314023 > data fork in ino 4980237 claims free block 314024 > data fork in ino 4980237 claims free block 314025 > data fork in ino 4980237 claims free block 314026 > data fork in ino 4980237 claims free block 314027 > data fork in ino 4980237 claims free block 314028 > data fork in ino 4980237 claims free block 314029 > data fork in ino 4980237 claims free block 314030 > data fork in ino 4980237 claims free block 314031 > data fork in ino 4980237 claims free block 314032 > data fork in ino 4980237 claims free block 314033 > data fork in ino 4980237 claims free block 314034 > data fork in ino 4980237 claims free block 314035 > data fork in ino 4980237 claims free block 314036 > data fork in ino 4980237 claims free block 314037 > data fork in ino 4980237 claims free block 314038 > data fork in ino 4980237 claims free block 314039 > data fork in ino 4980237 claims free block 314040 > data fork in ino 4980237 claims free block 314041 > data fork in ino 4980237 claims free block 314042 > data fork in ino 4980237 claims free block 314043 > data fork in ino 4980237 claims free block 314044 > data fork in ino 4980237 claims free block 314045 > data fork in ino 4980237 claims free block 314046 > data fork in ino 4980237 claims free block 314047 > data fork in ino 4980237 claims free block 314048 > data fork in ino 4980237 claims free block 314049 > data fork in ino 4980237 claims free block 314050 > data fork in ino 4980237 claims free block 314051 > data fork in ino 4980237 claims free block 314052 > data fork in ino 4980237 claims free block 314053 > data fork in ino 4980237 claims free block 314054 > data fork in ino 4980237 claims free block 314055 > data fork in ino 4980237 claims free block 314056 > data fork in ino 4980237 claims free block 314057 > data fork in ino 4980237 claims free block 314058 > data fork in ino 4980237 claims free block 314059 > data fork in ino 4980237 claims free block 314060 > data fork in ino 4980237 claims free block 314061 > data fork in ino 4980237 claims free block 314062 > data fork in ino 4980237 claims free block 314063 > data fork in ino 4980237 claims free block 314064 > data fork in ino 4980237 claims free block 314065 > data fork in ino 4980237 claims free block 314066 > data fork in ino 4980237 claims free block 314067 > data fork in ino 4980237 claims free block 314068 > data fork in ino 4980237 claims free block 314069 > data fork in ino 4980237 claims free block 314070 > data fork in ino 4980237 claims free block 314071 > data fork in ino 4980237 claims free block 314072 > data fork in ino 4980237 claims free block 314073 > data fork in ino 4980237 claims free block 314074 > data fork in ino 4980237 claims free block 314075 > data fork in ino 4980237 claims free block 314076 > data fork in ino 4980237 claims free block 314077 > data fork in ino 4980237 claims free block 314078 > data fork in ino 4980237 claims free block 314079 > data fork in ino 4980237 claims free block 314080 > data fork in ino 4980237 claims free block 314081 > data fork in ino 4980237 claims free block 314082 > data fork in ino 4980237 claims free block 314083 > data fork in ino 4980237 claims free block 314084 > data fork in ino 4980237 claims free block 314085 > data fork in ino 4980237 claims free block 314086 > data fork in ino 4980237 claims free block 314087 > data fork in ino 4980237 claims free block 314088 > data fork in ino 4980237 claims free block 314089 > data fork in ino 4980237 claims free block 314090 > data fork in ino 4980237 claims free block 314091 > data fork in ino 4980237 claims free block 314092 > data fork in ino 4980237 claims free block 314093 > data fork in ino 4980237 claims free block 314094 > data fork in ino 4980237 claims free block 314095 > data fork in ino 4980237 claims free block 314096 > data fork in ino 4980237 claims free block 314097 > data fork in ino 4980237 claims free block 314098 > data fork in ino 4980237 claims free block 314099 > data fork in ino 4980237 claims free block 314100 > data fork in ino 4980237 claims free block 314101 > data fork in ino 4980237 claims free block 314102 > data fork in ino 4980237 claims free block 314103 > data fork in ino 4980237 claims free block 314104 > data fork in ino 4980237 claims free block 314105 > data fork in ino 4980237 claims free block 314106 > data fork in ino 4980237 claims free block 314107 > data fork in ino 4980237 claims free block 314108 > data fork in ino 4980237 claims free block 314109 > data fork in ino 4980237 claims free block 314110 > data fork in ino 4980237 claims free block 314111 > data fork in ino 4980237 claims free block 314112 > data fork in ino 4980237 claims free block 314113 > data fork in ino 4980237 claims free block 314114 > data fork in ino 4980237 claims free block 314115 > data fork in ino 4980237 claims free block 314116 > data fork in ino 4980237 claims free block 314117 > data fork in ino 4980237 claims free block 314118 > data fork in ino 4980237 claims free block 314119 > data fork in ino 4980237 claims free block 314120 > data fork in ino 4980237 claims free block 314121 > data fork in ino 4980237 claims free block 314122 > data fork in ino 4980237 claims free block 314123 > data fork in ino 4980237 claims free block 314124 > correcting nblocks for inode 4980237, was 8175 - counted 9417 > - agno = 3 > - agno = 4 > correcting nblocks for inode 9467815, was 0 - counted 1 > - agno = 5 > correcting nblocks for inode 12055584, was 0 - counted 1 > - agno = 6 > - agno = 7 > - process newly discovered inodes... > Phase 4 - check for duplicate blocks... > - setting up duplicate extent list... > - clear lost+found (if it exists) ... > - clearing existing "lost+found" inode > - marking entry "lost+found" to be deleted > - check for inodes claiming duplicate blocks... > - agno = 0 > - agno = 1 > - agno = 2 > data fork in regular inode 4980237 claims used block 631072 > correcting nblocks for inode 4980237, was 9417 - counted 8175 > - agno = 3 > - agno = 4 > data fork in regular inode 9467815 claims used block 762144 > correcting nblocks for inode 9467815, was 1 - counted 0 > - agno = 5 > data fork in regular inode 12055584 claims used block 1024288 > correcting nblocks for inode 12055584, was 1 - counted 0 > - agno = 6 > - agno = 7 > Phase 5 - rebuild AG headers and trees... > - reset superblock... > Phase 6 - check inode connectivity... > - resetting contents of realtime bitmap and summary inodes > - ensuring existence of lost+found directory > - traversing filesystem starting at / ... > rebuilding directory inode 128 > - traversal finished ... > - traversing all unattached subtrees ... > - traversals finished ... > - moving disconnected inodes to lost+found ... > disconnected inode 2099176, moving to lost+found > disconnected inode 2099181, moving to lost+found > disconnected inode 2103302, moving to lost+found > disconnected inode 2104120, moving to lost+found > disconnected inode 2186922, moving to lost+found > disconnected inode 2194345, moving to lost+found > disconnected inode 4337822, moving to lost+found > disconnected inode 4337823, moving to lost+found > disconnected inode 4370120, moving to lost+found > disconnected inode 4371747, moving to lost+found > disconnected inode 4419608, moving to lost+found > disconnected inode 4419610, moving to lost+found > disconnected inode 4419612, moving to lost+found > disconnected dir inode 6321380, moving to lost+found > disconnected dir inode 9461599, moving to lost+found > disconnected inode 10606016, moving to lost+found > disconnected dir inode 10634820, moving to lost+found > disconnected dir inode 13887775, moving to lost+found > disconnected dir inode 16019542, moving to lost+found > Phase 7 - verify and correct link counts... > corrupt dinode 9467815, extent total = 1, nblocks = 0. Unmount and run > xfs_repair. > fatal error -- couldn't map inode 9467815, err = 990 > > > -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Lonni J Friedman netllama@linux-sxs.org Linux Step-by-step & TyGeMo http://netllama.ipfox.com From owner-linux-xfs@oss.sgi.com Thu Jul 3 00:54:42 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 03 Jul 2003 00:55:02 -0700 (PDT) Received: from eugate04.e-mail.com (eugate04.e-mail.com [194.196.143.90]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h637se2x021205 for ; Thu, 3 Jul 2003 00:54:41 -0700 Received: from borg.borg.de (unknown[194.120.172.57]) by eugate.e-mail.com (smtpgw4) with ESMTP id <20030703025712233038qsfee>; Thu, 3 Jul 2003 02:57:13 +0000 Subject: Important Notice: Virus detected X-Priority: 3 (Normal) Date: Thu, 3 Jul 2003 04:51:26 +0200 From: 'BORG_WatchDog_Demon'%BORG@borg.de To: linux-xfs@oss.sgi.com Reply-To: GROUP-TOOLS-ADMIN%BORG@borg.de Message-ID: X-MIMETrack: Serialize by Router on BORG/BORG(Release 5.0.10 |March 22, 2002) at 03.07.2003 04:51:27 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii X-archive-position: 4544 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: 'BORG_WatchDog_Demon'%BORG@borg.de Precedence: bulk X-list: linux-xfs GROUP WatchDog Server: BORG/BORG ----------------------------------------------------------------------- Your mail item contained viruses! Please check your harddrive! ----------------------------------------------------------------------- Mail-Info From: To: Rec.: dimitar.peikov@borg.de Date: 03.07.2003 05:00:32 Subject: Re: Movie ----------------------------------------------------------------------- File: [your_details.] State: [file contains virus] From owner-linux-xfs@oss.sgi.com Thu Jul 3 00:58:14 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 03 Jul 2003 00:58:31 -0700 (PDT) Received: from mousepad.xtramind.dfki.de (mousepad.xtramind.dfki.de [134.96.191.5]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h637wD2x021482 for ; Thu, 3 Jul 2003 00:58:14 -0700 Received: from localhost (localhost [127.0.0.1]) by mousepad.xtramind.dfki.de (Postfix) with ESMTP id 814327CFB; Thu, 3 Jul 2003 09:58:07 +0200 (MEST) Received: from gluff.org (localhost [127.0.0.1]) by mousepad.xtramind.dfki.de (Postfix) with ESMTP id AA30B7CF3; Thu, 3 Jul 2003 09:58:04 +0200 (MEST) Message-ID: <3F039806.1000608@gluff.org> Date: Thu, 03 Jul 2003 04:42:14 +0200 From: Jan Kuemmel User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3) Gecko/20030416 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Net Llama!" Cc: linux-xfs@oss.sgi.com Subject: Re: unrepairable filesystem References: <3F0302FD.5040308@gluff.org> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by AMaViS with Sophos Sweep X-archive-position: 4545 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: xfs@gluff.org Precedence: bulk X-list: linux-xfs xfs_repair does not run at all when you try it on a mounted filesystem. The error message I sent was produced when I run it on the unmounted filesystem, of course. Net Llama! wrote: >I could be wrong, but i don't think you're supposed to be running >xfs_repair on a mounted filesystem. > > > From owner-linux-xfs@oss.sgi.com Thu Jul 3 01:42:33 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 03 Jul 2003 01:42:55 -0700 (PDT) Received: from smtpzilla3.xs4all.nl (smtpzilla3.xs4all.nl [194.109.127.139]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h638gW2x022065 for ; Thu, 3 Jul 2003 01:42:33 -0700 Received: from auto-nb1.xs4all.nl (coltex.xs4all.nl [213.84.127.28]) by smtpzilla3.xs4all.nl (8.12.9/8.12.9) with ESMTP id h638g1r8098934; Thu, 3 Jul 2003 10:42:06 +0200 (CEST) Message-Id: <4.3.2.7.2.20030703103745.02d4a130@pop.xs4all.nl> X-Sender: knuffie@pop.xs4all.nl X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 03 Jul 2003 10:41:48 +0200 To: Sebastien Boving , From: Seth Mos Subject: Re: oops in 2.4.20-18.9XFS1.3.0pre2 In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-archive-position: 4546 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: knuffie@xs4all.nl Precedence: bulk X-list: linux-xfs At 10:33 2-7-2003 -0700, Sebastien Boving wrote: >The patch you gave me below was already installed in xfs_inode.c >(1.3.0pre2), so that shouldn't have been the issue. > >I'm getting XFS 1.2 in RH 2.4.2(0|1) kernel ready for next wednesday's >downtime. Should the cmd-rpms for 1.3.0pre2 work with XFS1.2 kernel, or >should i be cautious and switch each time i change kernel? I currently No need to, userland is unrelated to the kernel version. Just leave them installed. The newer tools have more options as well as fewer bugs. Newer tools and a older kernel is no problem. The on-disk filesystem is still the same as on Irix. Cheers -- Seth It might just be your lucky day, if you only knew. From owner-linux-xfs@oss.sgi.com Thu Jul 3 08:04:55 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 03 Jul 2003 08:05:22 -0700 (PDT) Received: from THOR.goeci.com ([66.28.220.99]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h63F4r2x003439 for ; Thu, 3 Jul 2003 08:04:55 -0700 Received: by THOR.goeci.com with Internet Mail Service (5.5.2653.19) id ; Thu, 3 Jul 2003 11:04:48 -0400 Message-ID: <2D92FEBFD3BE1346A6C397223A8DD3FC092360@THOR.goeci.com> From: Murthy Kambhampaty To: linux-xfs@oss.sgi.com Subject: xfs_freeze stuck in D state Date: Thu, 3 Jul 2003 11:04:42 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" X-archive-position: 4547 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: murthy.kambhampaty@goeci.com Precedence: bulk X-list: linux-xfs On a test computer running the CVS kernel from June 19th, xfs_freeze has been stuck in "D" state for two days. ps -p -o wchan,args returns: WCHAN COMMAND down /usr/sbin/xfs_freeze -f /home/db The rest of the system appears to run fine (/home/db hosts the postgresql test server's "database cluster"). Issuing /usr/sbin/xfs_freeze -u /home/db seems to do nothing. Some background: On this system, a backup script is run every three (3) hours which does the following: 1.) rysync from /home/db/pgdata to a backup server 2.) create snaphsot of /home/db 3.) create snapshot of /home/db/pgdata/pg_xlog 4.) mount the snapshots to /mnt/pgsnap and /mnt/pgxlsnap 5.) rsync the two folders to the appopriate folders on the backup server 6.) remove the snapshots [OT: 7.) start and stop the postgresql server on the backup server with the data just backed-up and capture the log; then quit] This issues occurred very frequently with the CVS kernel from just after the xfscyncd changes, but with the June 19th CVS, things ran stably for over a week. So far, the only way I've been able to "recover" from this is to do a hard reset. The "halt" command puts "Jul 3 10:51:16 comptest shutdown: shutting down for system halt"; but seems to zombie immediately: 24739 D 10:51:15 shutdown -h 0 w 24740 Z 10:51:16 [shutdown ] If needed I can compile a kernel with kdb and try to get a stack trace on xfs_freeze if the problem recurs. I was wondering if this was a known issues with a fix available ;-) Thanks, Murthy From owner-linux-xfs@oss.sgi.com Thu Jul 3 09:16:57 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 03 Jul 2003 09:17:17 -0700 (PDT) Received: from mail02.securities.com (mail02.securities.com [57.69.15.72]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h63GGu2x005165 for ; Thu, 3 Jul 2003 09:16:57 -0700 Received: from mail02.securities.com (localhost [127.0.0.1]) by mail02.securities.com (8.12.5/8.12.5-DELIVERY) with ESMTP id h63GGsoq014764 for ; Thu, 3 Jul 2003 12:16:54 -0400 Received: from mail02.securities.com (localhost [127.0.0.1]) by mail02.securities.com (8.12.5/8.12.5/8.12.5-SMTP) with ESMTP id h63GGsUf014759 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NOT); Thu, 3 Jul 2003 12:16:54 -0400 Received: from localhost (venevene@localhost) by mail02.securities.com (8.12.5/8.12.5/Submit) with ESMTP id h63GGsiu014754; Thu, 3 Jul 2003 12:16:54 -0400 X-Authentication-Warning: mail02.securities.com: venevene owned process doing -bs Date: Thu, 3 Jul 2003 12:16:54 -0400 (EDT) From: "Benito A. Venegas" X-X-Sender: venevene@mail02.securities.com Reply-To: "Benito A. Venegas" To: Seth Mos cc: Juergen Rose , Subject: Re: Can't mount xfs with log version=2 In-Reply-To: <4.3.2.7.2.20030626134829.035221c8@pop.xs4all.nl> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 4548 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: bvenegas@securities.com Precedence: bulk X-list: linux-xfs Hi Seth, Juergen: I have similar problem here with a raid0 using raidtools #mkfs -t xfs -f -l version=2 /dev/md1 meta-data=/dev/md1 isize=256 agcount=29, agsize=1048544 blks = sectsz=512 data = bsize=4096 blocks=29902912, imaxpct=0 = sunit=32 swidth=64 blks, unwritten=0 naming =version 2 bsize=4096 log =internal log bsize=4096 blocks=3680, version=2 = sectsz=512 sunit=32 blks realtime =none extsz=262144 blocks=0, rtextents=0 # mount -t xfs -o logbsize=64k /dev/md1 /mnt mount: wrong fs type, bad option, bad superblock on /dev/md1, or too many mounted file systems #dmesg | tail -1 XFS: logbuf size must be greater than or equal to log stripe size Info ---- OS: RH 7.3 installed with fixed RH7.3-SGI-XFS-1.1.iso (new-rh-7.3-patch.xdelta) kernel-2.4.19-SGI_XFS_1.2.0smp xfsprogs-2.3.9 mount-2.11n-12.7.3 Before I tried to use mkfs with this options: mkfs -t xfs -l size=32768b,version=2 -f /dev/md1 and tried to mount with: mount -t xfs -o logbufs=8,logbsize=32768 /dev/md1 /mnt and I get the same error. Any help will be appreciate. Thanks Benito.- On Thu, 26 Jun 2003, Seth Mos wrote: > At 13:38 26-6-2003 +0200, Juergen Rose wrote: > >Hi, > > > >I have here a software raid device /dev/md/0. If I create the filesystem > >with: > > mkfs -t xfs -f /dev/md/0 > >I can mount the device, but I get a lot of "raid5: switching cache > >buffer size" warnings. If I create the filesystem with > > mkfs -t xrs -f -l version=2 /dev/md/0 > >I can't mount the device: I get: > > > >mount: wrong fs type, bad option, bad superblock on /dev/md/0, > > or too many mounted file systems > > It probably needs to be mounted with a larger buffer size. > > Try mount -o logbsize=64k /dev/foo /mnt/foo > > The version2 log automaticaly switches to a larger databuffer size for > striping purposes. > However if it is larger then 32k a mount option must be specified. > > Cheers > > -- > Seth > It might just be your lucky day, if you only knew. > > -- From owner-linux-xfs@oss.sgi.com Thu Jul 3 09:27:15 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 03 Jul 2003 09:27:28 -0700 (PDT) Received: from THOR.goeci.com ([66.28.220.99]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h63GRE2x005721 for ; Thu, 3 Jul 2003 09:27:15 -0700 Received: by THOR.goeci.com with Internet Mail Service (5.5.2653.19) id ; Thu, 3 Jul 2003 12:27:09 -0400 Message-ID: <2D92FEBFD3BE1346A6C397223A8DD3FC092361@THOR.goeci.com> From: Murthy Kambhampaty To: "'linux-xfs@oss.sgi.com'" Subject: Missing files in CVS - linux-2.4-xfs/linux/fs/xfs? Date: Thu, 3 Jul 2003 12:27:03 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" X-archive-position: 4549 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: murthy.kambhampaty@goeci.com Precedence: bulk X-list: linux-xfs When trying to compile a CVS kernel, "make dep" fails with: make -C xfs fastdep make[4]: Entering directory `/home/opus/cvsrep/linux-2.4-xfs/linux/fs/xfs' make[4]: *** No rule to make target `fastdep'. Stop. make[4]: Leaving directory `/home/opus/cvsrep/linux-2.4-xfs/linux/fs/xfs' make[3]: *** [_sfdep_xfs] Error 2 make[3]: Leaving directory `/home/opus/cvsrep/linux-2.4-xfs/linux/fs' make[2]: *** [fastdep] Error 2 make[2]: Leaving directory `/home/opus/cvsrep/linux-2.4-xfs/linux/fs' make[1]: *** [_sfdep_fs] Error 2 make[1]: Leaving directory `/home/opus/cvsrep/linux-2.4-xfs/linux' make: *** [dep-files] Error 2 Poking around, I notice that that ~/linux-2.4-xfs/linux/fs/xfs hasn't the usual files. Help, please. From owner-linux-xfs@oss.sgi.com Thu Jul 3 09:30:02 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 03 Jul 2003 09:30:23 -0700 (PDT) Received: from rrzd2.rz.uni-regensburg.de (root@rrzd2.rz.uni-regensburg.de [132.199.1.12]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h63GU02x006147 for ; Thu, 3 Jul 2003 09:30:01 -0700 Received: from rss1.rz.uni-regensburg.de (rss1.rz.uni-regensburg.de [132.199.1.200]) by rrzd2.rz.uni-regensburg.de (8.12.3/8.12.3/Debian -4) with SMTP id h63GTwiw005776 for ; Thu, 3 Jul 2003 18:29:58 +0200 Received: (qmail 16779 invoked from network); 3 Jul 2003 18:29:58 +0200 Received: from rx3227.cip.uni-regensburg.de (132.199.237.32) by rss1.rz.uni-regensburg.de with SMTP; 3 Jul 2003 18:29:58 +0200 Subject: Re: Can't mount xfs with log version=2 From: Christian Guggenberger Reply-To: christian.guggenberger@physik.uni-regensburg.de To: "Benito A. Venegas" Cc: Seth Mos , Juergen Rose , linux-xfs@oss.sgi.com In-Reply-To: References: Content-Type: text/plain Message-Id: <1057249798.436.3.camel@bonnie79> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.0 Date: 03 Jul 2003 18:29:58 +0200 Content-Transfer-Encoding: 7bit X-archive-position: 4550 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: christian.guggenberger@physik.uni-regensburg.de Precedence: bulk X-list: linux-xfs On Thu, 2003-07-03 at 18:16, Benito A. Venegas wrote: > Hi Seth, Juergen: > > I have similar problem here with a raid0 using raidtools > > #mkfs -t xfs -f -l version=2 /dev/md1 > meta-data=/dev/md1 isize=256 agcount=29, agsize=1048544 > blks > = sectsz=512 > data = bsize=4096 blocks=29902912, imaxpct=0 > = sunit=32 swidth=64 blks, unwritten=0 > naming =version 2 bsize=4096 > log =internal log bsize=4096 blocks=3680, version=2 > = sectsz=512 sunit=32 blks > realtime =none extsz=262144 blocks=0, rtextents=0 > > # mount -t xfs -o logbsize=64k /dev/md1 /mnt > mount: wrong fs type, bad option, bad superblock on /dev/md1, > or too many mounted file systems > > #dmesg | tail -1 > XFS: logbuf size must be greater than or equal to log stripe size Don't you need logbsize>=128k ? your logsection has sunit=32 blks(=128k). Christian From owner-linux-xfs@oss.sgi.com Thu Jul 3 10:39:11 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 03 Jul 2003 10:39:31 -0700 (PDT) Received: from zok.sgi.com (zok.SGI.COM [204.94.215.101]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h63HdA2x008102 for ; Thu, 3 Jul 2003 10:39:10 -0700 Received: from flecktone.americas.sgi.com (flecktone.americas.sgi.com [192.48.203.135]) by zok.sgi.com (8.12.9/8.12.2/linux-outbound_gateway-1.2) with ESMTP id h63Hd4iY000800 for ; Thu, 3 Jul 2003 10:39:04 -0700 Received: from poppy-e236.americas.sgi.com (poppy-e236.americas.sgi.com [128.162.236.207]) by flecktone.americas.sgi.com (8.12.9/8.12.9/generic_config-1.2) with ESMTP id h63Hc3qX7660820; Thu, 3 Jul 2003 12:38:03 -0500 (CDT) Received: from stout.americas.sgi.com (stout.americas.sgi.com [128.162.232.50]) by poppy-e236.americas.sgi.com (8.12.9/SGI-server-1.8) with ESMTP id h63Hc3Yl13684594; Thu, 3 Jul 2003 12:38:03 -0500 (CDT) Date: Thu, 3 Jul 2003 12:38:03 -0500 (CDT) From: Eric Sandeen X-X-Sender: sandeen@stout.americas.sgi.com To: Murthy Kambhampaty cc: "'linux-xfs@oss.sgi.com'" Subject: Re: Missing files in CVS - linux-2.4-xfs/linux/fs/xfs? In-Reply-To: <2D92FEBFD3BE1346A6C397223A8DD3FC092361@THOR.goeci.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 4551 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: sandeen@sgi.com Precedence: bulk X-list: linux-xfs We did some internal tree reorganization... I think we will get xfs back under linux/fs/xfs, but for now if you check "xfs-linux" out of cvs, you should get the xfs files you need. -Eric On Thu, 3 Jul 2003, Murthy Kambhampaty wrote: > When trying to compile a CVS kernel, "make dep" fails with: > > make -C xfs fastdep > make[4]: Entering directory `/home/opus/cvsrep/linux-2.4-xfs/linux/fs/xfs' > make[4]: *** No rule to make target `fastdep'. Stop. > make[4]: Leaving directory `/home/opus/cvsrep/linux-2.4-xfs/linux/fs/xfs' > make[3]: *** [_sfdep_xfs] Error 2 > make[3]: Leaving directory `/home/opus/cvsrep/linux-2.4-xfs/linux/fs' > make[2]: *** [fastdep] Error 2 > make[2]: Leaving directory `/home/opus/cvsrep/linux-2.4-xfs/linux/fs' > make[1]: *** [_sfdep_fs] Error 2 > make[1]: Leaving directory `/home/opus/cvsrep/linux-2.4-xfs/linux' > make: *** [dep-files] Error 2 > > Poking around, I notice that that ~/linux-2.4-xfs/linux/fs/xfs hasn't the > usual files. > > Help, please. > > From owner-linux-xfs@oss.sgi.com Thu Jul 3 10:42:16 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 03 Jul 2003 10:42:20 -0700 (PDT) Received: from THOR.goeci.com ([66.28.220.99]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h63HgF2x008538 for ; Thu, 3 Jul 2003 10:42:16 -0700 Received: by THOR.goeci.com with Internet Mail Service (5.5.2653.19) id ; Thu, 3 Jul 2003 13:42:10 -0400 Message-ID: <2D92FEBFD3BE1346A6C397223A8DD3FC092363@THOR.goeci.com> From: Murthy Kambhampaty To: "'Eric Sandeen'" Cc: "'linux-xfs@oss.sgi.com'" Subject: RE: Missing files in CVS - linux-2.4-xfs/linux/fs/xfs? Date: Thu, 3 Jul 2003 13:42:01 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" X-archive-position: 4552 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: murthy.kambhampaty@goeci.com Precedence: bulk X-list: linux-xfs Thanks, Eric. cvs -d :pserver:cvs:cvs@oss.sgi.com/cvs co -d fs-xfs xfs-linux outside the linux-2.4-xfs tree and linking "fs-xfs" over to linux/fs/xfs worked. >-----Original Message----- >From: Eric Sandeen [mailto:sandeen@sgi.com] >Sent: Thursday, July 03, 2003 13:38 >To: Murthy Kambhampaty >Cc: 'linux-xfs@oss.sgi.com' >Subject: Re: Missing files in CVS - linux-2.4-xfs/linux/fs/xfs? > > >We did some internal tree reorganization... I think we will get xfs >back under linux/fs/xfs, but for now if you check "xfs-linux" out >of cvs, you should get the xfs files you need. > >-Eric > >On Thu, 3 Jul 2003, Murthy Kambhampaty wrote: > >> When trying to compile a CVS kernel, "make dep" fails with: >> >> make -C xfs fastdep >> make[4]: Entering directory >`/home/opus/cvsrep/linux-2.4-xfs/linux/fs/xfs' >> make[4]: *** No rule to make target `fastdep'. Stop. >> make[4]: Leaving directory >`/home/opus/cvsrep/linux-2.4-xfs/linux/fs/xfs' >> make[3]: *** [_sfdep_xfs] Error 2 >> make[3]: Leaving directory `/home/opus/cvsrep/linux-2.4-xfs/linux/fs' >> make[2]: *** [fastdep] Error 2 >> make[2]: Leaving directory `/home/opus/cvsrep/linux-2.4-xfs/linux/fs' >> make[1]: *** [_sfdep_fs] Error 2 >> make[1]: Leaving directory `/home/opus/cvsrep/linux-2.4-xfs/linux' >> make: *** [dep-files] Error 2 >> >> Poking around, I notice that that >~/linux-2.4-xfs/linux/fs/xfs hasn't the >> usual files. >> >> Help, please. >> >> > From owner-linux-xfs@oss.sgi.com Thu Jul 3 10:43:25 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 03 Jul 2003 10:43:28 -0700 (PDT) Received: from tolkor.sgi.com ([198.149.18.6]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h63HhO2x008961 for ; Thu, 3 Jul 2003 10:43:24 -0700 Received: from flecktone.americas.sgi.com (flecktone.americas.sgi.com [192.48.203.135]) by tolkor.sgi.com (8.12.9/8.12.2/linux-outbound_gateway-1.2) with ESMTP id h63I12mO020623 for ; Thu, 3 Jul 2003 13:01:02 -0500 Received: from poppy-e236.americas.sgi.com (poppy-e236.americas.sgi.com [128.162.236.207]) by flecktone.americas.sgi.com (8.12.9/8.12.9/generic_config-1.2) with ESMTP id h63HhIqX7660095; Thu, 3 Jul 2003 12:43:19 -0500 (CDT) Received: from stout.americas.sgi.com (stout.americas.sgi.com [128.162.232.50]) by poppy-e236.americas.sgi.com (8.12.9/SGI-server-1.8) with ESMTP id h63HhIYl13737497; Thu, 3 Jul 2003 12:43:18 -0500 (CDT) Date: Thu, 3 Jul 2003 12:43:18 -0500 (CDT) From: Eric Sandeen X-X-Sender: sandeen@stout.americas.sgi.com To: Murthy Kambhampaty cc: linux-xfs@oss.sgi.com Subject: Re: xfs_freeze stuck in D state In-Reply-To: <2D92FEBFD3BE1346A6C397223A8DD3FC092360@THOR.goeci.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 4553 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: sandeen@sgi.com Precedence: bulk X-list: linux-xfs > If needed I can compile a kernel with kdb and try to get a stack trace on > xfs_freeze if the problem recurs. I was wondering if this was a known issues > with a fix available ;-) I don't think this is a known issue; if you have a reliable way to reproduce it, you might file a bug in bugzilla with all the info. Otherwise turning on KDB and getting a backtrace would help. -Eric From owner-linux-xfs@oss.sgi.com Thu Jul 3 12:19:57 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 03 Jul 2003 12:20:14 -0700 (PDT) Received: from mailhost.iitb.ac.in ([203.199.51.149]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h63JJi2x010666 for ; Thu, 3 Jul 2003 12:19:55 -0700 Received: (qmail 1850 invoked from network); 3 Jul 2003 12:09:38 -0000 Received: from mailscan2.iitb.ac.in (HELO antivirus.iitb.ac.in) (144.16.108.202) by mailhost.iitb.ac.in with SMTP; 3 Jul 2003 12:09:38 -0000 Received: (qmail 8532 invoked by uid 505); 3 Jul 2003 12:09:38 -0000 Received: from benchmark@cc.iitb.ac.in by localhost.localdomain by uid 502 with qmail-scanner-1.15 (clamscan: 0.54. Clear:. Processed in 0.135056 secs); 03 Jul 2003 12:09:38 -0000 Received: from unknown (HELO pawan.cc.iitb.ac.in) ([144.16.106.6]) (envelope-sender ) by antivirus.iitb.ac.in (qmail-ldap-1.03) with SMTP for ; 3 Jul 2003 12:09:37 -0000 Received: (qmail 19182 invoked by uid 2171); 3 Jul 2003 12:09:37 -0000 Received: from localhost (sendmail-bs@127.0.0.1) by localhost with SMTP; 3 Jul 2003 12:09:37 -0000 Date: Thu, 3 Jul 2003 17:39:37 +0530 (IST) From: "Benchmark Soln." To: Subject: partition on irix Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 4554 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: benchmark@cc.iitb.ac.in Precedence: bulk X-list: linux-xfs Sir, we have one sgi machine on which irix ver 4.2 is installed. now we r installing one new hdd on that. can u pls let us know how to make partition on the irix system. waiting for ur earliest reply. thanks prasad From owner-linux-xfs@oss.sgi.com Thu Jul 3 14:53:26 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 03 Jul 2003 14:53:45 -0700 (PDT) Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.9/8.12.9) with ESMTP id h63LrP2x016483 for ; Thu, 3 Jul 2003 14:53:25 -0700 Received: (from xfs@localhost) by oss.sgi.com (8.12.9/8.12.8/Submit) id h63LrPkx016482 for linux-xfs@oss.sgi.com; Thu, 3 Jul 2003 14:53:25 -0700 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.9/8.12.9) with ESMTP id h63LrN2x016468 for ; Thu, 3 Jul 2003 14:53:23 -0700 Received: (from apache@localhost) by oss.sgi.com (8.12.9/8.12.8/Submit) id h63LAANx015180; Thu, 3 Jul 2003 14:10:10 -0700 Date: Thu, 3 Jul 2003 14:10:10 -0700 Message-Id: <200307032110.h63LAANx015180@oss.sgi.com> From: bugzilla-daemon@oss.sgi.com To: xfs-master@oss.sgi.com Subject: [Bug 259] New: xfs_freeze gets stuck in "D" state in the function "down" X-Bugzilla-Reason: AssignedTo X-archive-position: 4555 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: bugzilla-daemon@oss.sgi.com Precedence: bulk X-list: linux-xfs http://oss.sgi.com/bugzilla/show_bug.cgi?id=259 Summary: xfs_freeze gets stuck in "D" state in the function "down" Product: Linux XFS Version: Current Platform: All OS/Version: All Status: NEW Severity: critical Priority: High Component: XFS kernel code AssignedTo: xfs-master@oss.sgi.com ReportedBy: murthy.kambhampaty@goeci.com A script calls xfs_freeze on a given filesystem, prior to taking a snapshot. This script is run automatically, every three hours. After running successfully for several "iterations", xfs_freeze eventually gets stuck in "D" state. "ps -p -o wchan,args" returns: WCHAN COMMAND down /usr/sbin/xfs_freeze -f A hard reset is needed to recover; until then, the filesystem on which xfs_freeze is run is frozen, but the rest of the system is available. This behavior occurs in recent kernels (with the xfssyncd code; in this particular case CVS of June 19th). In kernels (e.g., XFS Release 1.2) without the xfssyncd code, lvcreate would get stuck in xfs_check_frozen (see http://marc.theaimsgroup.com/?l=linux-xfs&m=105277405929107&w=2), and an xfs_freeze -u would recover the system (though it did ruin the snapshot). The key to replicating the problem seems to be in the number of times the script runs, not on the load at the time the script runs. (The system had not been heavily loaded within days of the occurence.) This behavior occurred more frequently in versions close to the date the xfssyncd code went in -- for example, on a kernel I compiled on June 10th, from CVS update of the same day, I was able to reproduce the behaviour on the second manual iteration of the script. A version of this script is attached at: http://marc.theaimsgroup.com/?l=postgresql-admin&m=104932938526084&w=2 ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From owner-linux-xfs@oss.sgi.com Sat Jul 5 05:08:12 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Sat, 05 Jul 2003 05:08:27 -0700 (PDT) Received: from rrzd2.rz.uni-regensburg.de (root@rrzd2.rz.uni-regensburg.de [132.199.1.12]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h65C8A2x026069 for ; Sat, 5 Jul 2003 05:08:11 -0700 Received: from rss1.rz.uni-regensburg.de (rss1.rz.uni-regensburg.de [132.199.1.200]) by rrzd2.rz.uni-regensburg.de (8.12.3/8.12.3/Debian -4) with SMTP id h65C88mo015051 for ; Sat, 5 Jul 2003 14:08:09 +0200 Received: (qmail 23029 invoked from network); 5 Jul 2003 14:08:08 +0200 Received: from rx3227.cip.uni-regensburg.de (132.199.237.32) by rss1.rz.uni-regensburg.de with SMTP; 5 Jul 2003 14:08:08 +0200 Subject: just a test... From: Christian Guggenberger Reply-To: christian.guggenberger@physik.uni-regensburg.de To: linux-xfs@oss.sgi.com Content-Type: text/plain Message-Id: <1057406888.436.0.camel@bonnie79> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.0 Date: 05 Jul 2003 14:08:08 +0200 Content-Transfer-Encoding: 7bit X-archive-position: 4557 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: christian.guggenberger@physik.uni-regensburg.de Precedence: bulk X-list: linux-xfs ... please ignore! From owner-linux-xfs@oss.sgi.com Sat Jul 5 05:14:29 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Sat, 05 Jul 2003 05:14:33 -0700 (PDT) Received: from rrzd2.rz.uni-regensburg.de (root@rrzd2.rz.uni-regensburg.de [132.199.1.12]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h65CER2x026490 for ; Sat, 5 Jul 2003 05:14:28 -0700 Received: from rss1.rz.uni-regensburg.de (rss1.rz.uni-regensburg.de [132.199.1.200]) by rrzd2.rz.uni-regensburg.de (8.12.3/8.12.3/Debian -4) with SMTP id h65CEQmo016761 for ; Sat, 5 Jul 2003 14:14:26 +0200 Received: (qmail 23063 invoked from network); 5 Jul 2003 14:14:26 +0200 Received: from rx3227.cip.uni-regensburg.de (132.199.237.32) by rss1.rz.uni-regensburg.de with SMTP; 5 Jul 2003 14:14:26 +0200 Subject: oops: XFS internal error xfs_itobp (Again) / nfsd: non-standard errno : -990 From: Christian Guggenberger Reply-To: christian.guggenberger@physik.uni-regensburg.de To: linux-xfs@oss.sgi.com Content-Type: text/plain Message-Id: <1057407266.436.4.camel@bonnie79> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.0 Date: 05 Jul 2003 14:14:26 +0200 Content-Transfer-Encoding: 7bit X-archive-position: 4558 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: christian.guggenberger@physik.uni-regensburg.de Precedence: bulk X-list: linux-xfs Hi Folks, after Tuesdays crash we had to restore one of the 2 xfs-filesystems from tape. (lvm58,0) Today afternoon the server went back in production, but ca. 20 min later we got oopsen (Kernel 2.4.20 CVS April 2003). These oopsen seem to have something to do with: nfsd: non-standard errno: -990 The dmesg output and the oopsen decoded with ksymoops are available at: http://homepages.uni-r.de/~guc28561/oops http://homepages.uni-r.de/~guc28561/oops.decode if more info is needed, please advice! Christian From owner-linux-xfs@oss.sgi.com Sat Jul 5 08:54:09 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Sat, 05 Jul 2003 08:54:29 -0700 (PDT) Received: from rrzd2.rz.uni-regensburg.de (root@rrzd2.rz.uni-regensburg.de [132.199.1.12]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h65Fs72x028096 for ; Sat, 5 Jul 2003 08:54:09 -0700 Received: from rss1.rz.uni-regensburg.de (rss1.rz.uni-regensburg.de [132.199.1.200]) by rrzd2.rz.uni-regensburg.de (8.12.3/8.12.3/Debian -4) with SMTP id h65Fs6mo026991 for ; Sat, 5 Jul 2003 17:54:06 +0200 Received: (qmail 24544 invoked from network); 5 Jul 2003 17:54:06 +0200 Received: from rx3227.cip.uni-regensburg.de (132.199.237.32) by rss1.rz.uni-regensburg.de with SMTP; 5 Jul 2003 17:54:06 +0200 Subject: Re: oops: XFS internal error xfs_itobp (Again) / nfsd: non-standard errno : -990 From: Christian Guggenberger Reply-To: christian.guggenberger@physik.uni-regensburg.de To: linux-xfs@oss.sgi.com In-Reply-To: <1057407266.436.4.camel@bonnie79> References: <1057407266.436.4.camel@bonnie79> Content-Type: text/plain Message-Id: <1057420447.431.7.camel@bonnie79> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.0 Date: 05 Jul 2003 17:54:07 +0200 Content-Transfer-Encoding: 7bit X-archive-position: 4559 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: christian.guggenberger@physik.uni-regensburg.de Precedence: bulk X-list: linux-xfs On Sat, 2003-07-05 at 14:14, Christian Guggenberger wrote: > Hi Folks, > > after Tuesdays crash we had to restore one of the 2 xfs-filesystems from > tape. (lvm58,0) > Today afternoon the server went back in production, but ca. 20 min later > we got oopsen (Kernel 2.4.20 CVS April 2003). > These oopsen seem to have something to do with: > nfsd: non-standard errno: -990 > The dmesg output and the oopsen decoded with ksymoops are available at: > http://homepages.uni-r.de/~guc28561/oops > http://homepages.uni-r.de/~guc28561/oops.decode Steve, I searched the archives and found a post by Nicolas K. http://marc.theaimsgroup.com/?l=linux-xfs&m=105307906417456&w=2 which shows similar xfs error messages. In reply to that, you said these messages are cosmetical. So I should not worry too much about them? We're in a very similar situation as Nicolas was, because after tuesday's crash many (about 100 or more clients) have nfs stale filehandles. But it's difficult to reboot them all now, because some important calculations are running on them... thanks for (hopefully) some feedback. Christian From owner-linux-xfs@oss.sgi.com Sun Jul 6 00:12:42 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 06 Jul 2003 00:13:09 -0700 (PDT) Received: from rrzs2.rz.uni-regensburg.de (rrzs2.rz.uni-regensburg.de [132.199.1.2]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h667Ce2x004314 for ; Sun, 6 Jul 2003 00:12:41 -0700 Received: from pc9391.physik.uni-regensburg.de (pc9391.physik.uni-regensburg.de [132.199.98.219]) by rrzs2.rz.uni-regensburg.de (8.11.7+Sun/8.11.6) with ESMTP id h64GOkl02577 for ; Fri, 4 Jul 2003 18:24:46 +0200 (MEST) Received: from guc28561 by pc9391.physik.uni-regensburg.de with local (Exim 3.35 #1 (Debian)) id 19YTMc-00072G-00 for ; Fri, 04 Jul 2003 18:24:46 +0200 Date: Fri, 4 Jul 2003 18:24:46 +0200 From: Christian Guggenberger To: linux-xfs@oss.sgi.com Subject: XFS internal error xfs_itobp (Again) Message-ID: <20030704162446.GA26730@pc9391.physik.uni-regensburg.de> Reply-To: Christian.Guggenberger@physik.uni-regensburg.de Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="DocE+STaALJfprDB" Content-Disposition: inline User-Agent: Mutt/1.3.28i X-archive-position: 4561 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: Christian.Guggenberger@physik.uni-regensburg.de Precedence: bulk X-list: linux-xfs --DocE+STaALJfprDB Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Hi Folks, after Tuesdays crash we had to restore one of the 2 xfs-filesystems from tape. (lvm58,0) Today afternoon the server went back in production, but ca. 20 min later we got oopsen (Kernel CVS April 2003). These oopsen seem to have something to do with: nfsd: non-standard errno: -990 The dmesg output and the oopsen decoded with ksymoops are attached. if more info is needed, please advice! Happy July,4th from Germany. Christian --DocE+STaALJfprDB Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=oops s, 128Kbytes TCP: Hash tables configured (established 262144 bind 65536) NET4: Unix domain sockets 1.0/SMP for Linux NET4.0. VFS: Mounted root (ext2 filesystem) readonly. Freeing unused kernel memory: 248k freed Adding Swap: 2000052k swap-space (priority -1) Adding Swap: 2000052k swap-space (priority -2) Real Time Clock Driver v1.10e Intel(R) PRO/1000 Network Driver - version 4.4.12-k1 Copyright (c) 1999-2002 Intel Corporation. eth0: Intel(R) PRO/1000 Network Connection LVM version 1.0.5+(22/07/2002) module loaded loop: loaded (max 8 devices) XFS mounting filesystem sd(8,21) Ending clean XFS mount for filesystem: sd(8,21) XFS mounting filesystem sd(8,24) Ending clean XFS mount for filesystem: sd(8,24) XFS mounting filesystem lvm(58,0) Ending clean XFS mount for filesystem: lvm(58,0) XFS mounting filesystem lvm(58,1) Ending clean XFS mount for filesystem: lvm(58,1) e1000: eth0 NIC Link is Up 1000 Mbps Full Duplex 0x0: 20 20 20 20 20 20 73 75 62 72 6f 75 74 69 6e 65 Filesystem "lvm(58,0)": XFS internal error xfs_itobp at line 383 of file xfs_inode.c. Caller 0xc01acc27 f7219ce4 c01a53c9 c01a5428 c01acc27 0000017f c029b831 c01a551b c029b8b0 00000001 f7678400 c029b831 0000017f c01acc27 f6a4d000 00000010 00000000 00000000 f7678400 00000000 c01aba85 c029b8b0 00000001 f7678400 f6a4d000 Call Trace: [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] 0x0: 20 20 20 20 20 20 73 75 62 72 6f 75 74 69 6e 65 Filesystem "lvm(58,0)": XFS internal error xfs_itobp at line 383 of file xfs_inode.c. Caller 0xc01acc27 f7211ce4 c01a53c9 c01a5428 c01acc27 0000017f c029b831 c01a551b c029b8b0 00000001 f7678400 c029b831 0000017f c01acc27 f6a4d000 00000010 00000000 00000000 f7678400 00000000 c01aba85 c029b8b0 00000001 f7678400 f6a4d000 Call Trace: [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] 0x0: 69 4b 69 e9 83 d4 89 8a 9b 38 9a db 37 80 f9 1c Filesystem "lvm(58,0)": XFS internal error xfs_itobp at line 383 of file xfs_inode.c. Caller 0xc01acc27 f7219c98 c01a53c9 c01a5428 c01acc27 0000017f c029b831 c01a551b c029b8b0 00000001 f7678400 c029b831 0000017f c01acc27 f6821000 00000010 00000000 00000000 f7678400 00000000 c01aba85 c029b8b0 00000001 f7678400 f6821000 Call Trace: [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] nfsd: non-standard errno: -990 0x0: 69 4b 69 e9 83 d4 89 8a 9b 38 9a db 37 80 f9 1c Filesystem "lvm(58,0)": XFS internal error xfs_itobp at line 383 of file xfs_inode.c. Caller 0xc01acc27 f7219c98 c01a53c9 c01a5428 c01acc27 0000017f c029b831 c01a551b c029b8b0 00000001 f7678400 c029b831 0000017f c01acc27 f6821000 00000010 00000000 00000000 f7678400 00000000 c01aba85 c029b8b0 00000001 f7678400 f6821000 Call Trace: [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] nfsd: non-standard errno: -990 0x0: 69 4b 69 e9 83 d4 89 8a 9b 38 9a db 37 80 f9 1c Filesystem "lvm(58,0)": XFS internal error xfs_itobp at line 383 of file xfs_inode.c. Caller 0xc01acc27 f7211c98 c01a53c9 c01a5428 c01acc27 0000017f c029b831 c01a551b c029b8b0 00000001 f7678400 c029b831 0000017f c01acc27 f6821000 00000010 00000000 00000000 f7678400 00000000 c01aba85 c029b8b0 00000001 f7678400 f6821000 Call Trace: [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] nfsd: non-standard errno: -990 0x0: 69 4b 69 e9 83 d4 89 8a 9b 38 9a db 37 80 f9 1c Filesystem "lvm(58,0)": XFS internal error xfs_itobp at line 383 of file xfs_inode.c. Caller 0xc01acc27 f7219c98 c01a53c9 c01a5428 c01acc27 0000017f c029b831 c01a551b c029b8b0 00000001 f7678400 c029b831 0000017f c01acc27 f6821000 00000010 00000000 00000000 f7678400 00000000 c01aba85 c029b8b0 00000001 f7678400 f6821000 Call Trace: [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] nfsd: non-standard errno: -990 0x0: 69 4b 69 e9 83 d4 89 8a 9b 38 9a db 37 80 f9 1c Filesystem "lvm(58,0)": XFS internal error xfs_itobp at line 383 of file xfs_inode.c. Caller 0xc01acc27 f7219cd8 c01a53c9 c01a5428 c01acc27 0000017f c029b831 c01a551b c029b8b0 00000001 f7678400 c029b831 0000017f c01acc27 f6821000 00000010 00000000 00000000 f7678400 00000000 c01aba85 c029b8b0 00000001 f7678400 f6821000 Call Trace: [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] nfsd: non-standard errno: -990 0x0: 69 4b 69 e9 83 d4 89 8a 9b 38 9a db 37 80 f9 1c Filesystem "lvm(58,0)": XFS internal error xfs_itobp at line 383 of file xfs_inode.c. Caller 0xc01acc27 f7211cd8 c01a53c9 c01a5428 c01acc27 0000017f c029b831 c01a551b c029b8b0 00000001 f7678400 c029b831 0000017f c01acc27 f6821000 00000010 00000000 00000000 f7678400 00000000 c01aba85 c029b8b0 00000001 f7678400 f6821000 Call Trace: [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] nfsd: non-standard errno: -990 0x0: 69 4b 69 e9 83 d4 89 8a 9b 38 9a db 37 80 f9 1c Filesystem "lvm(58,0)": XFS internal error xfs_itobp at line 383 of file xfs_inode.c. Caller 0xc01acc27 f7219cd8 c01a53c9 c01a5428 c01acc27 0000017f c029b831 c01a551b c029b8b0 00000001 f7678400 c029b831 0000017f c01acc27 f6821000 00000010 00000000 00000000 f7678400 00000000 c01aba85 c029b8b0 00000001 f7678400 f6821000 Call Trace: [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] nfsd: non-standard errno: -990 0x0: 69 4b 69 e9 83 d4 89 8a 9b 38 9a db 37 80 f9 1c Filesystem "lvm(58,0)": XFS internal error xfs_itobp at line 383 of file xfs_inode.c. Caller 0xc01acc27 f7211cd8 c01a53c9 c01a5428 c01acc27 0000017f c029b831 c01a551b c029b8b0 00000001 f7678400 c029b831 0000017f c01acc27 f6821000 00000010 00000000 00000000 f7678400 00000000 c01aba85 c029b8b0 00000001 f7678400 f6821000 Call Trace: [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] nfsd: non-standard errno: -990 0x0: 69 4b 69 e9 83 d4 89 8a 9b 38 9a db 37 80 f9 1c Filesystem "lvm(58,0)": XFS internal error xfs_itobp at line 383 of file xfs_inode.c. Caller 0xc01acc27 f7219c98 c01a53c9 c01a5428 c01acc27 0000017f c029b831 c01a551b c029b8b0 00000001 f7678400 c029b831 0000017f c01acc27 f6821000 00000010 00000000 00000000 f7678400 00000000 c01aba85 c029b8b0 00000001 f7678400 f6821000 Call Trace: [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] nfsd: non-standard errno: -990 0x0: 69 4b 69 e9 83 d4 89 8a 9b 38 9a db 37 80 f9 1c Filesystem "lvm(58,0)": XFS internal error xfs_itobp at line 383 of file xfs_inode.c. Caller 0xc01acc27 f7211c98 c01a53c9 c01a5428 c01acc27 0000017f c029b831 c01a551b c029b8b0 00000001 f7678400 c029b831 0000017f c01acc27 f6821000 00000010 00000000 00000000 f7678400 00000000 c01aba85 c029b8b0 00000001 f7678400 f6821000 Call Trace: [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] nfsd: non-standard errno: -990 0x0: 69 4b 69 e9 83 d4 89 8a 9b 38 9a db 37 80 f9 1c Filesystem "lvm(58,0)": XFS internal error xfs_itobp at line 383 of file xfs_inode.c. Caller 0xc01acc27 f7219c98 c01a53c9 c01a5428 c01acc27 0000017f c029b831 c01a551b c029b8b0 00000001 f7678400 c029b831 0000017f c01acc27 f6821000 00000010 00000000 00000000 f7678400 00000000 c01aba85 c029b8b0 00000001 f7678400 f6821000 Call Trace: [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] nfsd: non-standard errno: -990 0x0: 69 4b 69 e9 83 d4 89 8a 9b 38 9a db 37 80 f9 1c Filesystem "lvm(58,0)": XFS internal error xfs_itobp at line 383 of file xfs_inode.c. Caller 0xc01acc27 f7211c98 c01a53c9 c01a5428 c01acc27 0000017f c029b831 c01a551b c029b8b0 00000001 f7678400 c029b831 0000017f c01acc27 f6821000 00000010 00000000 00000000 f7678400 00000000 c01aba85 c029b8b0 00000001 f7678400 f6821000 Call Trace: [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] nfsd: non-standard errno: -990 0x0: 69 4b 69 e9 83 d4 89 8a 9b 38 9a db 37 80 f9 1c Filesystem "lvm(58,0)": XFS internal error xfs_itobp at line 383 of file xfs_inode.c. Caller 0xc01acc27 f7219c98 c01a53c9 c01a5428 c01acc27 0000017f c029b831 c01a551b c029b8b0 00000001 f7678400 c029b831 0000017f c01acc27 f6821000 00000010 00000000 00000000 f7678400 00000000 c01aba85 c029b8b0 00000001 f7678400 f6821000 Call Trace: [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] nfsd: non-standard errno: -990 0x0: 69 4b 69 e9 83 d4 89 8a 9b 38 9a db 37 80 f9 1c Filesystem "lvm(58,0)": XFS internal error xfs_itobp at line 383 of file xfs_inode.c. Caller 0xc01acc27 f71e3c98 c01a53c9 c01a5428 c01acc27 0000017f c029b831 c01a551b c029b8b0 00000001 f7678400 c029b831 0000017f c01acc27 f6821000 00000010 00000000 00000000 f7678400 00000000 c01aba85 c029b8b0 00000001 f7678400 f6821000 Call Trace: [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] nfsd: non-standard errno: -990 0x0: 69 4b 69 e9 83 d4 89 8a 9b 38 9a db 37 80 f9 1c Filesystem "lvm(58,0)": XFS internal error xfs_itobp at line 383 of file xfs_inode.c. Caller 0xc01acc27 f71ddc98 c01a53c9 c01a5428 c01acc27 0000017f c029b831 c01a551b c029b8b0 00000001 f7678400 c029b831 0000017f c01acc27 f6821000 00000010 00000000 00000000 f7678400 00000000 c01aba85 c029b8b0 00000001 f7678400 f6821000 Call Trace: [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] nfsd: non-standard errno: -990 0x0: 69 4b 69 e9 83 d4 89 8a 9b 38 9a db 37 80 f9 1c Filesystem "lvm(58,0)": XFS internal error xfs_itobp at line 383 of file xfs_inode.c. Caller 0xc01acc27 f7219c98 c01a53c9 c01a5428 c01acc27 0000017f c029b831 c01a551b c029b8b0 00000001 f7678400 c029b831 0000017f c01acc27 f6821000 00000010 00000000 00000000 f7678400 00000000 c01aba85 c029b8b0 00000001 f7678400 f6821000 Call Trace: [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] nfsd: non-standard errno: -990 0x0: 69 4b 69 e9 83 d4 89 8a 9b 38 9a db 37 80 f9 1c Filesystem "lvm(58,0)": XFS internal error xfs_itobp at line 383 of file xfs_inode.c. Caller 0xc01acc27 f722dc98 c01a53c9 c01a5428 c01acc27 0000017f c029b831 c01a551b c029b8b0 00000001 f7678400 c029b831 0000017f c01acc27 f6821000 00000010 00000000 00000000 f7678400 00000000 c01aba85 c029b8b0 00000001 f7678400 f6821000 Call Trace: [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] nfsd: non-standard errno: -990 0x0: 31 20 20 20 2d 30 2e 31 30 38 36 34 32 34 34 39 Filesystem "lvm(58,0)": XFS internal error xfs_itobp at line 383 of file xfs_inode.c. Caller 0xc01acc27 f7211cd8 c01a53c9 c01a5428 c01acc27 0000017f c029b831 c01a551b c029b8b0 00000001 f7678400 c029b831 0000017f c01acc27 e60ec000 00000010 00000000 00000000 f7678400 00000000 c01aba85 c029b8b0 00000001 f7678400 e60ec000 Call Trace: [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] nfsd: non-standard errno: -990 nfsd: last server has exited nfsd: unexporting all filesystems rpciod: active tasks at shutdown?! --DocE+STaALJfprDB Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="oops.decode" ksymoops 2.4.5 on i686 2.4.20-xfs. Options used -V (default) -k /proc/ksyms (default) -l /proc/modules (default) -o /lib/modules/2.4.20-xfs/ (default) -m /boot/System.map-2.4.20-xfs (default) Warning: You did not tell me where to find symbol information. I will assume that the log matches the kernel and modules that are running right now and I'll use the default options above for symbol resolution. If the current kernel and/or modules do not match the log, you can get more accurate output by telling me the kernel version and where to find map, modules, ksyms etc. ksymoops -h explains the options. e1000: eth0 NIC Link is Up 1000 Mbps Full Duplex f7219ce4 c01a53c9 c01a5428 c01acc27 0000017f c029b831 c01a551b c029b8b0 00000001 f7678400 c029b831 0000017f c01acc27 f6a4d000 00000010 00000000 00000000 f7678400 00000000 c01aba85 c029b8b0 00000001 f7678400 f6a4d000 Call Trace: [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] f7211ce4 c01a53c9 c01a5428 c01acc27 0000017f c029b831 c01a551b c029b8b0 00000001 f7678400 c029b831 0000017f c01acc27 f6a4d000 00000010 00000000 00000000 f7678400 00000000 c01aba85 c029b8b0 00000001 f7678400 f6a4d000 Call Trace: [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] f7219c98 c01a53c9 c01a5428 c01acc27 0000017f c029b831 c01a551b c029b8b0 00000001 f7678400 c029b831 0000017f c01acc27 f6821000 00000010 00000000 00000000 f7678400 00000000 c01aba85 c029b8b0 00000001 f7678400 f6821000 Call Trace: [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] f7219c98 c01a53c9 c01a5428 c01acc27 0000017f c029b831 c01a551b c029b8b0 00000001 f7678400 c029b831 0000017f c01acc27 f6821000 00000010 00000000 00000000 f7678400 00000000 c01aba85 c029b8b0 00000001 f7678400 f6821000 Call Trace: [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] f7211c98 c01a53c9 c01a5428 c01acc27 0000017f c029b831 c01a551b c029b8b0 00000001 f7678400 c029b831 0000017f c01acc27 f6821000 00000010 00000000 00000000 f7678400 00000000 c01aba85 c029b8b0 00000001 f7678400 f6821000 Call Trace: [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] f7219c98 c01a53c9 c01a5428 c01acc27 0000017f c029b831 c01a551b c029b8b0 00000001 f7678400 c029b831 0000017f c01acc27 f6821000 00000010 00000000 00000000 f7678400 00000000 c01aba85 c029b8b0 00000001 f7678400 f6821000 Call Trace: [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] f7219cd8 c01a53c9 c01a5428 c01acc27 0000017f c029b831 c01a551b c029b8b0 00000001 f7678400 c029b831 0000017f c01acc27 f6821000 00000010 00000000 00000000 f7678400 00000000 c01aba85 c029b8b0 00000001 f7678400 f6821000 Call Trace: [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] f7211cd8 c01a53c9 c01a5428 c01acc27 0000017f c029b831 c01a551b c029b8b0 00000001 f7678400 c029b831 0000017f c01acc27 f6821000 00000010 00000000 00000000 f7678400 00000000 c01aba85 c029b8b0 00000001 f7678400 f6821000 Call Trace: [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] f7219cd8 c01a53c9 c01a5428 c01acc27 0000017f c029b831 c01a551b c029b8b0 00000001 f7678400 c029b831 0000017f c01acc27 f6821000 00000010 00000000 00000000 f7678400 00000000 c01aba85 c029b8b0 00000001 f7678400 f6821000 Call Trace: [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] f7211cd8 c01a53c9 c01a5428 c01acc27 0000017f c029b831 c01a551b c029b8b0 00000001 f7678400 c029b831 0000017f c01acc27 f6821000 00000010 00000000 00000000 f7678400 00000000 c01aba85 c029b8b0 00000001 f7678400 f6821000 Call Trace: [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] f7219c98 c01a53c9 c01a5428 c01acc27 0000017f c029b831 c01a551b c029b8b0 00000001 f7678400 c029b831 0000017f c01acc27 f6821000 00000010 00000000 00000000 f7678400 00000000 c01aba85 c029b8b0 00000001 f7678400 f6821000 Call Trace: [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] f7211c98 c01a53c9 c01a5428 c01acc27 0000017f c029b831 c01a551b c029b8b0 00000001 f7678400 c029b831 0000017f c01acc27 f6821000 00000010 00000000 00000000 f7678400 00000000 c01aba85 c029b8b0 00000001 f7678400 f6821000 Call Trace: [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] f7219c98 c01a53c9 c01a5428 c01acc27 0000017f c029b831 c01a551b c029b8b0 00000001 f7678400 c029b831 0000017f c01acc27 f6821000 00000010 00000000 00000000 f7678400 00000000 c01aba85 c029b8b0 00000001 f7678400 f6821000 Call Trace: [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] f7211c98 c01a53c9 c01a5428 c01acc27 0000017f c029b831 c01a551b c029b8b0 00000001 f7678400 c029b831 0000017f c01acc27 f6821000 00000010 00000000 00000000 f7678400 00000000 c01aba85 c029b8b0 00000001 f7678400 f6821000 Call Trace: [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] f7219c98 c01a53c9 c01a5428 c01acc27 0000017f c029b831 c01a551b c029b8b0 00000001 f7678400 c029b831 0000017f c01acc27 f6821000 00000010 00000000 00000000 f7678400 00000000 c01aba85 c029b8b0 00000001 f7678400 f6821000 Call Trace: [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] f71e3c98 c01a53c9 c01a5428 c01acc27 0000017f c029b831 c01a551b c029b8b0 00000001 f7678400 c029b831 0000017f c01acc27 f6821000 00000010 00000000 00000000 f7678400 00000000 c01aba85 c029b8b0 00000001 f7678400 f6821000 Call Trace: [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] f71ddc98 c01a53c9 c01a5428 c01acc27 0000017f c029b831 c01a551b c029b8b0 00000001 f7678400 c029b831 0000017f c01acc27 f6821000 00000010 00000000 00000000 f7678400 00000000 c01aba85 c029b8b0 00000001 f7678400 f6821000 Call Trace: [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] f7219c98 c01a53c9 c01a5428 c01acc27 0000017f c029b831 c01a551b c029b8b0 00000001 f7678400 c029b831 0000017f c01acc27 f6821000 00000010 00000000 00000000 f7678400 00000000 c01aba85 c029b8b0 00000001 f7678400 f6821000 Call Trace: [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] f722dc98 c01a53c9 c01a5428 c01acc27 0000017f c029b831 c01a551b c029b8b0 00000001 f7678400 c029b831 0000017f c01acc27 f6821000 00000010 00000000 00000000 f7678400 00000000 c01aba85 c029b8b0 00000001 f7678400 f6821000 Call Trace: [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] f7211cd8 c01a53c9 c01a5428 c01acc27 0000017f c029b831 c01a551b c029b8b0 00000001 f7678400 c029b831 0000017f c01acc27 e60ec000 00000010 00000000 00000000 f7678400 00000000 c01aba85 c029b8b0 00000001 f7678400 e60ec000 Call Trace: [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] Warning (Oops_read): Code line not seen, dumping what data is available Trace; c01a53c9 Trace; c01a5428 Trace; c01acc27 Trace; c01a551b Trace; c01acc27 Trace; c01aba85 Trace; c01acc27 Trace; c01acc27 Trace; c01aaaac Trace; c01aadef Trace; c01c2af6 Trace; c01d510f Trace; c01d4bba Trace; c016427e Trace; c01646bd Trace; c0164c30 Trace; c016b219 Trace; c0162a83 Trace; c027d175 Trace; c016286f Trace; c0105684 Trace; c01a53c9 Trace; c01a5428 Trace; c01acc27 Trace; c01a551b Trace; c01acc27 Trace; c01aba85 Trace; c01acc27 Trace; c01acc27 Trace; c01aaaac Trace; c01aadef Trace; c01c2af6 Trace; c01d510f Trace; c01d4bba Trace; c016427e Trace; c01646bd Trace; c0164c30 Trace; c016b219 Trace; c0162a83 Trace; c027d175 Trace; c016286f Trace; c0105684 Trace; c01a53c9 Trace; c01a5428 Trace; c01acc27 Trace; c01a551b Trace; c01acc27 Trace; c01aba85 Trace; c01acc27 Trace; c01acc27 Trace; c01aaaac Trace; c01aadef Trace; c01c0d07 Trace; c01c4c22 Trace; c01d1bac Trace; c0164411 Trace; c0164896 Trace; c0164c30 Trace; c0165682 Trace; c027d554 Trace; c016b3b8 Trace; c0162a83 Trace; c027d175 Trace; c016286f Trace; c0105684 Trace; c01a53c9 Trace; c01a5428 Trace; c01acc27 Trace; c01a551b Trace; c01acc27 Trace; c01aba85 Trace; c01acc27 Trace; c01acc27 Trace; c01aaaac Trace; c01aadef Trace; c01c0d07 Trace; c01c4c22 Trace; c01d1bac Trace; c0164411 Trace; c0164896 Trace; c0164c30 Trace; c0165682 Trace; c027d554 Trace; c016b3b8 Trace; c0162a83 Trace; c027d175 Trace; c016286f Trace; c0105684 Trace; c01a53c9 Trace; c01a5428 Trace; c01acc27 Trace; c01a551b Trace; c01acc27 Trace; c01aba85 Trace; c01acc27 Trace; c01acc27 Trace; c01aaaac Trace; c01aadef Trace; c01c0d07 Trace; c01c4c22 Trace; c01d1bac Trace; c0164411 Trace; c0164896 Trace; c0164c30 Trace; c0165682 Trace; c027d554 Trace; c016b3b8 Trace; c0162a83 Trace; c027d175 Trace; c016286f Trace; c0105684 Trace; c01a53c9 Trace; c01a5428 Trace; c01acc27 Trace; c01a551b Trace; c01acc27 Trace; c01aba85 Trace; c01acc27 Trace; c01acc27 Trace; c01aaaac Trace; c01aadef Trace; c01c0d07 Trace; c01c4c22 Trace; c01d1bac Trace; c0164411 Trace; c0164896 Trace; c0164c30 Trace; c0165682 Trace; c027d554 Trace; c016b3b8 Trace; c0162a83 Trace; c027d175 Trace; c016286f Trace; c0105684 Trace; c01a53c9 Trace; c01a5428 Trace; c01acc27 Trace; c01a551b Trace; c01acc27 Trace; c01aba85 Trace; c01acc27 Trace; c01acc27 Trace; c01aaaac Trace; c01aadef Trace; c01c0d07 Trace; c01c4c22 Trace; c01d1bac Trace; c0164411 Trace; c0164896 Trace; c0164c30 Trace; c016b219 Trace; c0162a83 Trace; c027d175 Trace; c016286f Trace; c0105684 Trace; c01a53c9 Trace; c01a5428 Trace; c01acc27 Trace; c01a551b Trace; c01acc27 Trace; c01aba85 Trace; c01acc27 Trace; c01acc27 Trace; c01aaaac Trace; c01aadef Trace; c01c0d07 Trace; c01c4c22 Trace; c01d1bac Trace; c0164411 Trace; c0164896 Trace; c0164c30 Trace; c016b219 Trace; c0162a83 Trace; c027d175 Trace; c016286f Trace; c0105684 Trace; c01a53c9 Trace; c01a5428 Trace; c01acc27 Trace; c01a551b Trace; c01acc27 Trace; c01aba85 Trace; c01acc27 Trace; c01acc27 Trace; c01aaaac Trace; c01aadef Trace; c01c0d07 Trace; c01c4c22 Trace; c01d1bac Trace; c0164411 Trace; c0164896 Trace; c0164c30 Trace; c016b219 Trace; c0162a83 Trace; c027d175 Trace; c016286f Trace; c0105684 Trace; c01a53c9 Trace; c01a5428 Trace; c01acc27 Trace; c01a551b Trace; c01acc27 Trace; c01aba85 Trace; c01acc27 Trace; c01acc27 Trace; c01aaaac Trace; c01aadef Trace; c01c0d07 Trace; c01c4c22 Trace; c01d1bac Trace; c0164411 Trace; c0164896 Trace; c0164c30 Trace; c016b219 Trace; c0162a83 Trace; c027d175 Trace; c016286f Trace; c0105684 Trace; c01a53c9 Trace; c01a5428 Trace; c01acc27 Trace; c01a551b Trace; c01acc27 Trace; c01aba85 Trace; c01acc27 Trace; c01acc27 Trace; c01aaaac Trace; c01aadef Trace; c01c0d07 Trace; c01c4c22 Trace; c01d1bac Trace; c0164411 Trace; c0164896 Trace; c0164c30 Trace; c0165682 Trace; c027d554 Trace; c016b3b8 Trace; c0162a83 Trace; c027d175 Trace; c016286f Trace; c0105684 Trace; c01a53c9 Trace; c01a5428 Trace; c01acc27 Trace; c01a551b Trace; c01acc27 Trace; c01aba85 Trace; c01acc27 Trace; c01acc27 Trace; c01aaaac Trace; c01aadef Trace; c01c0d07 Trace; c01c4c22 Trace; c01d1bac Trace; c0164411 Trace; c0164896 Trace; c0164c30 Trace; c0165682 Trace; c027d554 Trace; c016b3b8 Trace; c0162a83 Trace; c027d175 Trace; c016286f Trace; c0105684 Trace; c01a53c9 Trace; c01a5428 Trace; c01acc27 Trace; c01a551b Trace; c01acc27 Trace; c01aba85 Trace; c01acc27 Trace; c01acc27 Trace; c01aaaac Trace; c01aadef Trace; c01c0d07 Trace; c01c4c22 Trace; c01d1bac Trace; c0164411 Trace; c0164896 Trace; c0164c30 Trace; c0165682 Trace; c027d554 Trace; c016b3b8 Trace; c0162a83 Trace; c027d175 Trace; c016286f Trace; c0105684 Trace; c01a53c9 Trace; c01a5428 Trace; c01acc27 Trace; c01a551b Trace; c01acc27 Trace; c01aba85 Trace; c01acc27 Trace; c01acc27 Trace; c01aaaac Trace; c01aadef Trace; c01c0d07 Trace; c01c4c22 Trace; c01d1bac Trace; c0164411 Trace; c0164896 Trace; c0164c30 Trace; c0165682 Trace; c027d554 Trace; c016b3b8 Trace; c0162a83 Trace; c027d175 Trace; c016286f Trace; c0105684 Trace; c01a53c9 Trace; c01a5428 Trace; c01acc27 Trace; c01a551b Trace; c01acc27 Trace; c01aba85 Trace; c01acc27 Trace; c01acc27 Trace; c01aaaac Trace; c01aadef Trace; c01c0d07 Trace; c01c4c22 Trace; c01d1bac Trace; c0164411 Trace; c0164896 Trace; c0164c30 Trace; c0165682 Trace; c027d554 Trace; c016b3b8 Trace; c0162a83 Trace; c027d175 Trace; c016286f Trace; c0105684 Trace; c01a53c9 Trace; c01a5428 Trace; c01acc27 Trace; c01a551b Trace; c01acc27 Trace; c01aba85 Trace; c01acc27 Trace; c01acc27 Trace; c01aaaac Trace; c01aadef Trace; c01c0d07 Trace; c01c4c22 Trace; c01d1bac Trace; c0164411 Trace; c0164896 Trace; c0164c30 Trace; c0165682 Trace; c027d554 Trace; c016b3b8 Trace; c0162a83 Trace; c027d175 Trace; c016286f Trace; c0105684 Trace; c01a53c9 Trace; c01a5428 Trace; c01acc27 Trace; c01a551b Trace; c01acc27 Trace; c01aba85 Trace; c01acc27 Trace; c01acc27 Trace; c01aaaac Trace; c01aadef Trace; c01c0d07 Trace; c01c4c22 Trace; c01d1bac Trace; c0164411 Trace; c0164896 Trace; c0164c30 Trace; c0165682 Trace; c027d554 Trace; c016b3b8 Trace; c0162a83 Trace; c027d175 Trace; c016286f Trace; c0105684 Trace; c01a53c9 Trace; c01a5428 Trace; c01acc27 Trace; c01a551b Trace; c01acc27 Trace; c01aba85 Trace; c01acc27 Trace; c01acc27 Trace; c01aaaac Trace; c01aadef Trace; c01c0d07 Trace; c01c4c22 Trace; c01d1bac Trace; c0164411 Trace; c0164896 Trace; c0164c30 Trace; c0165682 Trace; c027d554 Trace; c016b3b8 Trace; c0162a83 Trace; c027d175 Trace; c016286f Trace; c0105684 Trace; c01a53c9 Trace; c01a5428 Trace; c01acc27 Trace; c01a551b Trace; c01acc27 Trace; c01aba85 Trace; c01acc27 Trace; c01acc27 Trace; c01aaaac Trace; c01aadef Trace; c01c0d07 Trace; c01c4c22 Trace; c01d1bac Trace; c0164411 Trace; c0164896 Trace; c0164c30 Trace; c0165682 Trace; c027d554 Trace; c016b3b8 Trace; c0162a83 Trace; c027d175 Trace; c016286f Trace; c0105684 Trace; c01a53c9 Trace; c01a5428 Trace; c01acc27 Trace; c01a551b Trace; c01acc27 Trace; c01aba85 Trace; c01acc27 Trace; c01acc27 Trace; c01aaaac Trace; c01aadef Trace; c01c0d07 Trace; c01c4c22 Trace; c01d1bac Trace; c0164411 Trace; c0164896 Trace; c0164c30 Trace; c016b219 Trace; c0162a83 Trace; c027d175 Trace; c016286f Trace; c0105684 2 warnings issued. Results may not be reliable. --DocE+STaALJfprDB-- From owner-linux-xfs@oss.sgi.com Sun Jul 6 00:39:36 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 06 Jul 2003 00:39:54 -0700 (PDT) Received: from www3.omniplan.net (www3.omniplan.net [213.30.246.139]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h667dY2x005169 for ; Sun, 6 Jul 2003 00:39:35 -0700 Received: from nostromo (Bfe97.pppool.de [213.7.254.151]) by www3.omniplan.net (8.10.2/8.10.2) with ESMTP id h667dUC25331 for ; Sun, 6 Jul 2003 09:39:30 +0200 Date: Sun, 6 Jul 2003 09:39:31 +0200 From: Tilman Sauerbeck To: linux-xfs@oss.sgi.com Subject: Re: installing xfs from source Message-ID: <20030706073931.GA7060@code-monkey.de> Mail-Followup-To: linux-xfs@oss.sgi.com References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.1i X-archive-position: 4562 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: tilman@code-monkey.de Precedence: bulk X-list: linux-xfs * Geeta Gharpure [2003-07-06 09:09]: > I am trying to install xfs from the source for last two weeks. > My main goal is to get dmapi support. > > Exactly in which file do I check for the dmapi flag? > I have checked it in arch/i386/defconfig /usr/src/linux/.config: CONFIG_XFS_DMAPI=y Dunno if it depends on other XFS options though. -- Regards, Tilman From owner-linux-xfs@oss.sgi.com Sun Jul 6 08:49:06 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 06 Jul 2003 08:49:24 -0700 (PDT) Received: from smtp.web.de (smtp03.web.de [217.72.192.158]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h66Fn42x017746 for ; Sun, 6 Jul 2003 08:49:06 -0700 Received: from [213.23.45.163] (helo=[10.0.0.101]) by smtp.web.de with esmtp (TLSv1:DES-CBC3-SHA:168) (WEB.DE 4.98 #232) id 19ZBl4-00006B-00 for linux-xfs@oss.sgi.com; Sun, 06 Jul 2003 17:48:58 +0200 Subject: RedHat install iso From: Stefan Werner To: linux-xfs@oss.sgi.com Content-Type: text/plain Organization: Message-Id: <1057506317.2300.3.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 (1.2.2-4) Date: 06 Jul 2003 17:45:17 +0200 Content-Transfer-Encoding: 7bit X-archive-position: 4563 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: stefan.wer@web.de Precedence: bulk X-list: linux-xfs Hi, there is one problem with your installation CD for XFS/RedHad: It defaults to the XFS file system on both /boot and / partitions, where the default boot loader (grub) is unable to boot from an XFS partition (at least, as shipped with RedHat). An installation using the default settings will result in an unbootable system, what works is using ext3 for the /boot partition. It would probably make it easier for quite a few users if that were the default in future versions. Regards, Stefan Werner From owner-linux-xfs@oss.sgi.com Sun Jul 6 09:01:47 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 06 Jul 2003 09:01:51 -0700 (PDT) Received: from mail.vasoftware.com (mail@mail.vasoftware.com [198.186.202.175]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h66G1k2x018269 for ; Sun, 6 Jul 2003 09:01:46 -0700 Received: from adsl-67-123-172-40.dsl.sntc01.pacbell.net ([67.123.172.40] helo=linux-sxs.org) by mail.vasoftware.com with asmtp (Cipher TLSv1:RC4-MD5:128) (Exim 3.31-VA-mm2 #1 (Debian)) id 19ZBxP-0005VX-00 by VAauthid with fixed_plain; Sun, 06 Jul 2003 09:01:44 -0700 Message-ID: <3F0847DE.1050104@linux-sxs.org> Date: Sun, 06 Jul 2003 09:01:34 -0700 From: "Net Llama!" Organization: HAL III User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030625 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Stefan Werner CC: linux-xfs@oss.sgi.com Subject: Re: RedHat install iso References: <1057506317.2300.3.camel@localhost.localdomain> In-Reply-To: <1057506317.2300.3.camel@localhost.localdomain> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 4564 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: netllama@linux-sxs.org Precedence: bulk X-list: linux-xfs On 07/06/03 08:45, Stefan Werner wrote: > Hi, > > there is one problem with your installation CD for XFS/RedHad: It > defaults to the XFS file system on both /boot and / partitions, where > the default boot loader (grub) is unable to boot from an XFS partition > (at least, as shipped with RedHat). An installation using the default > settings will result in an unbootable system, what works is using ext3 > for the /boot partition. It would probably make it easier for quite a > few users if that were the default in future versions. > > Regards, > Stefan Werner > Use LILO and there are no problems. -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ L. Friedman netllama@linux-sxs.org Linux Step-by-step & TyGeMo: http://netllama.ipfox.com 9:00am up 17:59, 1 user, load average: 1.64, 1.78, 1.89 From owner-linux-xfs@oss.sgi.com Sun Jul 6 10:34:59 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 06 Jul 2003 10:35:13 -0700 (PDT) Received: from mailgate3.cinetic.de (mailgate3.cinetic.de [217.72.192.164]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h66HYv2x019307 for ; Sun, 6 Jul 2003 10:34:58 -0700 Received: from smtp.web.de (fmsmtp03.dlan.cinetic.de [172.20.0.183]) by mailgate3.cinetic.de (8.11.6p2/8.11.2/SuSE Linux 8.11.0-0.4) with ESMTP id h66HYpq19533 for ; Sun, 6 Jul 2003 19:34:51 +0200 Received: from [80.130.20.64] (helo=p50821440.dip.t-dialin.net) by smtp.web.de with esmtp (WEB.DE 4.98 #232) id 19ZDMT-0005iY-00; Sun, 06 Jul 2003 19:31:41 +0200 Subject: [OOPS] Linux 2.5.74-bk4 & XFS == oops From: Ali Akcaagac To: linux-kernel@vger.kernel.org Content-Type: text/plain Message-Id: <1057512700.827.9.camel@localhost> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.1 Date: Sun, 06 Jul 2003 19:31:40 +0200 Content-Transfer-Encoding: 7bit X-archive-position: 4565 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: aliakc@web.de Precedence: bulk X-list: linux-xfs Hello, This problem is following me since I first played with 2.5 (around 2.5.52). Every now and then the XFS driver causes a Kernel oops. First I thought this may be a normal issue because it's a development Kernel and I ignored it because I hoped that this was a known issue and tracked down one day. But yesterday I had 3-4 of these oops'es in a row and now I gonna report this in hope to see it fixed really soon. I compiled kmsgdump-2565.diff into the Kernel (with some minor tweaks) and tried to force this issue for half a day and guess, as soon as it comes to demonstration it doesn't happen but I bet my pants that this problem will show up pretty soon anyways. Ok I can't show you a full output but I wrote the last one down on paper. ;------------------------------- fs/xfs/pagebuf/page_buf.c:1288 Unknown command: 00000000 ;------------------------------- I am not sure for the second line if it should say 'unknown command' but something like this. Sorry, I can't offer you more right now but better this than nothing. From owner-linux-xfs@oss.sgi.com Sun Jul 6 14:37:37 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 06 Jul 2003 14:38:18 -0700 (PDT) Received: from hermes.acsalaska.net (hermes.slb.nwc.acsalaska.net [209.112.155.38]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h66Lau2x021693 for ; Sun, 6 Jul 2003 14:37:37 -0700 Received: from erbenson.alaska.net (66-pm22.nwc.alaska.net [209.112.143.66]) by hermes.acsalaska.net (8.12.9/8.12.9) with ESMTP id h66LasMw029775 for ; Sun, 6 Jul 2003 13:36:54 -0800 (AKDT) (envelope-from erbenson@alaska.net) Received: from plato.local.lan (plato.local.lan [192.168.0.4]) by erbenson.alaska.net (Postfix) with ESMTP id 49E003A0C for ; Sun, 6 Jul 2003 13:36:53 -0800 (AKDT) Received: by plato.local.lan (Postfix, from userid 1000) id 2FA9D40FF45; Sun, 6 Jul 2003 13:36:53 -0800 (AKDT) Date: Sun, 6 Jul 2003 13:36:53 -0800 From: Ethan Benson To: linux-xfs@oss.sgi.com Subject: Re: RedHat install iso Message-ID: <20030706213653.GN930@plato.local.lan> Mail-Followup-To: linux-xfs@oss.sgi.com References: <1057506317.2300.3.camel@localhost.localdomain> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="wJeYCwfJgfFvSPOo" Content-Disposition: inline In-Reply-To: <1057506317.2300.3.camel@localhost.localdomain> User-Agent: Mutt/1.3.28i X-OS: Debian GNU X-gpg-fingerprint: E3E4 D0BC 31BC F7BB C1DD C3D6 24AC 7B1A 2C44 7AFC X-gpg-key: http://www.alaska.net/~erbenson/gpg/key.asc Mail-Copies-To: nobody X-No-CC: I subscribe to this list; do not CC me on replies. X-ACS-Spam-Status: no X-Scanned-By: MIMEDefang 2.34 X-archive-position: 4566 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: erbenson@alaska.net Precedence: bulk X-list: linux-xfs --wJeYCwfJgfFvSPOo Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Jul 06, 2003 at 05:45:17PM +0200, Stefan Werner wrote: > Hi, >=20 > there is one problem with your installation CD for XFS/RedHad: It > defaults to the XFS file system on both /boot and / partitions, where > the default boot loader (grub) is unable to boot from an XFS partition > (at least, as shipped with RedHat). An installation using the default > settings will result in an unbootable system, what works is using ext3 > for the /boot partition. It would probably make it easier for quite a > few users if that were the default in future versions. grub can, but redhat sets it up brokenly. as someone else said, use lilo, at least initially. you could setup grub yourself later. --=20 Ethan Benson http://www.alaska.net/~erbenson/ --wJeYCwfJgfFvSPOo Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iEYEARECAAYFAj8IlnQACgkQJKx7GixEevyVbwCeOJd9HKWo4Ycf2vE1n/gHutPg /jwAoJBy4iWQIWv4LCdDUwlfWc5sno/+ =yHbq -----END PGP SIGNATURE----- --wJeYCwfJgfFvSPOo-- From owner-linux-xfs@oss.sgi.com Sun Jul 6 17:27:03 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 06 Jul 2003 17:27:41 -0700 (PDT) Received: from greenplant.dot (pf160.zgora.cvx.ppp.tpnet.pl [217.99.135.160]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h670QK2x023641 for ; Sun, 6 Jul 2003 17:27:01 -0700 Received: from karol by greenplant.dot with local (Exim 3.35 #1 (Debian)) id 19ZJpe-0000f8-00 for ; Mon, 07 Jul 2003 02:26:14 +0200 To: linux-xfs@oss.sgi.com Subject: [bug report]: chown(2) implementation in xfs is broken From: Karol Lewandowski Date: 07 Jul 2003 02:26:14 +0200 Message-ID: <7kadbrchcp.fsf@greenplant.dot> Lines: 27 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-archive-position: 4567 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: klz@o2.pl Precedence: bulk X-list: linux-xfs Vanilla Linux 2.4.21 form kernel.org + xfs snapshot: dmesg: SGI XFS snapshot-2.4.21-2003-06-23_01:45_UTC with no debug enabled Any user can chown his own files to any uid or gid. Unprivileged user (say karol) can do this successufly: karol@greenplant:/tmp/test$ id uid=1023(karol) gid=127(plant) groups=127(plant),4(adm),20(dialout),24(cdrom),25(floppy),29(audio),30(dip),101(dri) karol@greenplant:/tmp/test$ touch newfile karol@greenplant:/tmp/test$ ls -l total 0 -rw------- 1 karol plant 0 Jul 7 02:02 newfile karol@greenplant:/tmp/test$ chown root:root newfile karol@greenplant:/tmp/test$ ls -l total 0 -rw------- 1 root root 0 Jul 7 02:02 newfile karol@greenplant:/tmp/test$ Patch for Linux 2.4.20 doesn't seem to have this problem, so i tried to locate this issue... I think the problem is in /fs/xfs/xfs_vnodeops.c Unhopefuly I weren't able to fix it, I'm not kernel hacker (Yet :) -- kl ./. You may be recognized soon. Hide. From owner-linux-xfs@oss.sgi.com Sun Jul 6 17:35:09 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 06 Jul 2003 17:35:13 -0700 (PDT) Received: from mail.vasoftware.com (mail@mail.vasoftware.com [198.186.202.175]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h670YO2x024123 for ; Sun, 6 Jul 2003 17:35:08 -0700 Received: from adsl-67-123-172-40.dsl.sntc01.pacbell.net ([67.123.172.40] helo=linux-sxs.org) by mail.vasoftware.com with asmtp (Cipher TLSv1:RC4-MD5:128) (Exim 3.31-VA-mm2 #1 (Debian)) id 19ZJxU-00079p-00 by VAauthid with fixed_plain; Sun, 06 Jul 2003 17:34:20 -0700 Message-ID: <3F08C005.3070706@linux-sxs.org> Date: Sun, 06 Jul 2003 17:34:13 -0700 From: "Net Llama!" Organization: HAL III User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030625 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Karol Lewandowski CC: linux-xfs@oss.sgi.com Subject: Re: [bug report]: chown(2) implementation in xfs is broken References: <7kadbrchcp.fsf@greenplant.dot> In-Reply-To: <7kadbrchcp.fsf@greenplant.dot> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 4568 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: netllama@linux-sxs.org Precedence: bulk X-list: linux-xfs On 07/06/03 17:26, Karol Lewandowski wrote: > Vanilla Linux 2.4.21 form kernel.org + xfs snapshot: > dmesg: SGI XFS snapshot-2.4.21-2003-06-23_01:45_UTC with no debug enabled > > Any user can chown his own files to any uid or gid. > > Unprivileged user (say karol) can do this successufly: > > karol@greenplant:/tmp/test$ id > uid=1023(karol) gid=127(plant) groups=127(plant),4(adm),20(dialout),24(cdrom),25(floppy),29(audio),30(dip),101(dri) > karol@greenplant:/tmp/test$ touch newfile > karol@greenplant:/tmp/test$ ls -l > total 0 > -rw------- 1 karol plant 0 Jul 7 02:02 newfile > karol@greenplant:/tmp/test$ chown root:root newfile > karol@greenplant:/tmp/test$ ls -l > total 0 > -rw------- 1 root root 0 Jul 7 02:02 newfile > karol@greenplant:/tmp/test$ > > > Patch for Linux 2.4.20 doesn't seem to have this problem, so i tried to locate > this issue... I think the problem is in /fs/xfs/xfs_vnodeops.c > Unhopefuly I weren't able to fix it, I'm not kernel hacker (Yet :) eeeek. i just verified this on my boxes running 2.4.21-xfs. scary. -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ L. Friedman netllama@linux-sxs.org Linux Step-by-step & TyGeMo: http://netllama.ipfox.com 5:30pm up 1 day, 2:29, 1 user, load average: 0.17, 0.18, 0.09 From owner-linux-xfs@oss.sgi.com Sun Jul 6 17:59:47 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 06 Jul 2003 18:00:02 -0700 (PDT) Received: from zok.sgi.com (zok.SGI.COM [204.94.215.101]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h670xk2x024684 for ; Sun, 6 Jul 2003 17:59:47 -0700 Received: from flecktone.americas.sgi.com (flecktone.americas.sgi.com [192.48.203.135]) by zok.sgi.com (8.12.9/8.12.2/linux-outbound_gateway-1.2) with ESMTP id h670xfiY025807 for ; Sun, 6 Jul 2003 17:59:41 -0700 Received: from daisy-e236.americas.sgi.com (daisy-e236.americas.sgi.com [128.162.236.214]) by flecktone.americas.sgi.com (8.12.9/8.12.9/generic_config-1.2) with ESMTP id h670xeqX8012416; Sun, 6 Jul 2003 19:59:41 -0500 (CDT) Received: from [192.168.1.100] (cf-vpn-sw-corp-64-5.corp.sgi.com [134.15.64.5]) by daisy-e236.americas.sgi.com (8.12.9/SGI-server-1.8) with ESMTP id h670xdRn157740614; Sun, 6 Jul 2003 19:59:40 -0500 (CDT) Subject: Re: [bug report]: chown(2) implementation in xfs is broken From: Steve Lord To: Karol Lewandowski Cc: linux-xfs@oss.sgi.com In-Reply-To: <7kadbrchcp.fsf@greenplant.dot> References: <7kadbrchcp.fsf@greenplant.dot> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.8 (1.0.8-10) Date: 06 Jul 2003 20:00:31 -0500 Message-Id: <1057539633.1342.3.camel@laptop.americas.sgi.com> Mime-Version: 1.0 X-archive-position: 4569 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: lord@sgi.com Precedence: bulk X-list: linux-xfs On Sun, 2003-07-06 at 19:26, Karol Lewandowski wrote: > > Vanilla Linux 2.4.21 form kernel.org + xfs snapshot: > dmesg: SGI XFS snapshot-2.4.21-2003-06-23_01:45_UTC with no debug enabled > > Any user can chown his own files to any uid or gid. Use CVS, we need to redo the snapshots, they were made at a bad point in time. You need to echo 1 > /proc/sys/fs/xfs/restricted_chown, the default was set to the wrong value for a while and is fixed now. Steve > > Unprivileged user (say karol) can do this successufly: > > karol@greenplant:/tmp/test$ id > uid=1023(karol) gid=127(plant) groups=127(plant),4(adm),20(dialout),24(cdrom),25(floppy),29(audio),30(dip),101(dri) > karol@greenplant:/tmp/test$ touch newfile > karol@greenplant:/tmp/test$ ls -l > total 0 > -rw------- 1 karol plant 0 Jul 7 02:02 newfile > karol@greenplant:/tmp/test$ chown root:root newfile > karol@greenplant:/tmp/test$ ls -l > total 0 > -rw------- 1 root root 0 Jul 7 02:02 newfile > karol@greenplant:/tmp/test$ > > > Patch for Linux 2.4.20 doesn't seem to have this problem, so i tried to locate > this issue... I think the problem is in /fs/xfs/xfs_vnodeops.c > Unhopefuly I weren't able to fix it, I'm not kernel hacker (Yet :) > > -- > kl ./. You may be recognized soon. Hide. > From owner-linux-xfs@oss.sgi.com Sun Jul 6 18:53:40 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 06 Jul 2003 18:53:54 -0700 (PDT) Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.9/8.12.9) with ESMTP id h671rd2x026375 for ; Sun, 6 Jul 2003 18:53:39 -0700 Received: (from xfs@localhost) by oss.sgi.com (8.12.9/8.12.8/Submit) id h671rdTq026374 for linux-xfs@oss.sgi.com; Sun, 6 Jul 2003 18:53:39 -0700 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.9/8.12.9) with ESMTP id h671rb33026357 for ; Sun, 6 Jul 2003 18:53:38 -0700 Received: (from apache@localhost) by oss.sgi.com (8.12.9/8.12.8/Submit) id h671XBYt026282; Sun, 6 Jul 2003 18:33:11 -0700 Date: Sun, 6 Jul 2003 18:33:11 -0700 Message-Id: <200307070133.h671XBYt026282@oss.sgi.com> From: bugzilla-daemon@oss.sgi.com To: xfs-master@oss.sgi.com Subject: [Bug 258] Kernel (smp) lockup: ioctl(XFS_IOC_RESVSP); truncate() on fs with unwritten=1 X-Bugzilla-Reason: AssignedTo X-archive-position: 4570 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: bugzilla-daemon@oss.sgi.com Precedence: bulk X-list: linux-xfs http://oss.sgi.com/bugzilla/show_bug.cgi?id=258 nathans@sgi.com changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |ASSIGNED ------- Additional Comments From knutjbj@online.no 2003-01-07 05:33 PDT ------- Created an attachment (id=84) --> (http://oss.sgi.com/bugzilla/attachment.cgi?id=84&action=view) this is a config file for gxine with a similar error as my fstab. This config file for gxine has been overwriten with trunk data. Similar to what happen wit my fstab file. ------- Additional Comments From nathans@sgi.com 2003-06-07 18:33 PDT ------- Thanks Mike, Yup, I can easily reproduce this too - I have written a quick regression test based on your example, added in some more corner cases and I'm about to start figuring out whats going wrong here (just letting you know this hasn't gone into a black hole ;) cheers. ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From owner-linux-xfs@oss.sgi.com Sun Jul 6 18:57:11 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 06 Jul 2003 18:57:13 -0700 (PDT) Received: from tolkor.sgi.com ([198.149.18.6]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h671vA2x026811 for ; Sun, 6 Jul 2003 18:57:11 -0700 Received: from sherman.melbourne.sgi.com (sherman.melbourne.sgi.com [134.14.54.232]) by tolkor.sgi.com (8.12.9/8.12.2/linux-outbound_gateway-1.2) with ESMTP id h672EwmO015352 for ; Sun, 6 Jul 2003 21:14:59 -0500 Received: (from kaos@localhost) by sherman.melbourne.sgi.com (8.11.6/8.11.6) id h671u2o27447; Mon, 7 Jul 2003 11:56:02 +1000 Date: Mon, 7 Jul 2003 11:56:02 +1000 From: Keith Owens Message-Id: <200307070156.h671u2o27447@sherman.melbourne.sgi.com> Subject: TAKE - Upgrade XFS to kdb v4.3-2.4.21-common-4 X-archive-position: 4571 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: kaos@sherman.melbourne.sgi.com Precedence: bulk X-list: linux-xfs Upgrade XFS to kdb v4.3-2.4.21-common-4 Date: Sun Jul 6 18:55:07 PDT 2003 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:152525a linux/kernel/sysctl.c - 1.52 linux/kdb/ChangeLog - 1.34 From owner-linux-xfs@oss.sgi.com Sun Jul 6 19:20:02 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 06 Jul 2003 19:20:43 -0700 (PDT) Received: from tolkor.sgi.com ([198.149.18.6]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h672JL2x027430 for ; Sun, 6 Jul 2003 19:20:02 -0700 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by tolkor.sgi.com (8.12.9/8.12.2/linux-outbound_gateway-1.2) with SMTP id h672b9mO017099 for ; Sun, 6 Jul 2003 21:37:10 -0500 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 MAA00309; Mon, 7 Jul 2003 12:17:56 +1000 Received: by kao2.melbourne.sgi.com (Postfix, from userid 16331) id AF328D84FE; Mon, 7 Jul 2003 12:17:55 +1000 (EST) Received: from kao2.melbourne.sgi.com (localhost [127.0.0.1]) by kao2.melbourne.sgi.com (Postfix) with ESMTP id AC5CD912D6; Mon, 7 Jul 2003 12:17:55 +1000 (EST) X-Mailer: exmh version 2.5 01/15/2001 with nmh-1.0.4 From: Keith Owens To: linux-xfs@oss.sgi.com Cc: linux-kernel@vger.kernel.sgi.com Subject: Announce: XFS split patches for 2.4.21 Date: Mon, 07 Jul 2003 12:17:50 +1000 Message-ID: <3489.1057544270@kao2.melbourne.sgi.com> X-archive-position: 4572 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: kaos@sgi.com Precedence: bulk X-list: linux-xfs -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Content-Type: text/plain; charset=us-ascii ftp://oss.sgi.com/projects/xfs/download/patches/2.4.21. For some time the XFS group have been producing split patches for XFS, separating the core XFS changes from additional patches such as kdb, xattr, acl, dmapi. The split patches are released to the world with the hope that developers and distributors will find them useful. Read the README in each directory very carefully, the split patch format has changed over a few kernel releases. Any questions that are covered by the README will be ignored. There is even a 2.4.22/README for the terminally impatient :). Note: This is a respin as of 2.4.21-2003-07-07_02:01_UTC, it replaces the split patches that were done on 2003-06-23_01:45_UTC. The latter patches contain bad XFS code and should not be used. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) Comment: Exmh version 2.1.1 10/15/1999 iD8DBQE/CNhOi4UHNye0ZOoRAqSJAJ4iEec/Lx211eJVuNmuOA6IKN5CzgCgtP/4 ldbFHStUtxVYtg/Eb939TSw= =VmVj -----END PGP SIGNATURE----- From owner-linux-xfs@oss.sgi.com Sun Jul 6 19:33:55 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 06 Jul 2003 19:33:59 -0700 (PDT) Received: from gusi.leathercollection.ph (gusi.leathercollection.ph [202.163.192.10]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h672Xs2x027930 for ; Sun, 6 Jul 2003 19:33:55 -0700 Received: from localhost (localhost [127.0.0.1]) by gusi.leathercollection.ph (Postfix) with ESMTP id 5C07DEB4A12 for ; Mon, 7 Jul 2003 10:33:47 +0800 (PHT) Received: by gusi.leathercollection.ph (Postfix, from userid 1000) id 2A650EB4A0F; Mon, 7 Jul 2003 10:33:39 +0800 (PHT) Date: Mon, 7 Jul 2003 10:33:39 +0800 From: Federico Sevilla III To: linux-xfs@oss.sgi.com Subject: Re: [bug report]: chown(2) implementation in xfs is broken Message-ID: <20030707023339.GB1262@leathercollection.ph> Mail-Followup-To: linux-xfs@oss.sgi.com References: <7kadbrchcp.fsf@greenplant.dot> <1057539633.1342.3.camel@laptop.americas.sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1057539633.1342.3.camel@laptop.americas.sgi.com> X-Organization: The Leather Collection, Inc. X-Organization-URL: http://www.leathercollection.ph X-Personal-URL: http://jijo.free.net.ph User-Agent: Mutt/1.5.4i X-archive-position: 4573 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: jijo@free.net.ph Precedence: bulk X-list: linux-xfs On Sun, Jul 06, 2003 at 08:00:31PM -0500, Steve Lord wrote: > Use CVS, we need to redo the snapshots, they were made at a bad point > in time. You need to echo 1 > /proc/sys/fs/xfs/restricted_chown, the > default was set to the wrong value for a while and is fixed now. I think it's /proc/sys/fs/xfs/restrict_chown, right? Also, as a note, I'm using Debian kernel-source-2.4.21-1 with the snapshots 2003-06-23_01:45_UTC and the xfs_globals.c patch dated Fri Jun 27 23:59:20 2003 which was posted on this mailing list for the benefit of those who'd rather still use the slightly broken snapshots. The patch fixes the problems of restrict_chown incorrectly defaulting to 0. --> Jijo -- Federico Sevilla III : http://jijo.free.net.ph : When we speak of free Network Administrator : The Leather Collection, Inc. : software we refer to GnuPG Key ID : 0x93B746BE : freedom, not price. From owner-linux-xfs@oss.sgi.com Sun Jul 6 19:37:58 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 06 Jul 2003 19:38:02 -0700 (PDT) Received: from gusi.leathercollection.ph (gusi.leathercollection.ph [202.163.192.10]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h672bH2x028365 for ; Sun, 6 Jul 2003 19:37:57 -0700 Received: from localhost (localhost [127.0.0.1]) by gusi.leathercollection.ph (Postfix) with ESMTP id 5C4A7EB4A12 for ; Mon, 7 Jul 2003 10:37:11 +0800 (PHT) Received: by gusi.leathercollection.ph (Postfix, from userid 1000) id 56DCFEB4A0F; Mon, 7 Jul 2003 10:37:02 +0800 (PHT) Date: Mon, 7 Jul 2003 10:37:02 +0800 From: Federico Sevilla III To: linux-xfs@oss.sgi.com Subject: Re: Announce: XFS split patches for 2.4.21 Message-ID: <20030707023702.GC1262@leathercollection.ph> Mail-Followup-To: linux-xfs@oss.sgi.com References: <3489.1057544270@kao2.melbourne.sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3489.1057544270@kao2.melbourne.sgi.com> X-Organization: The Leather Collection, Inc. X-Organization-URL: http://www.leathercollection.ph X-Personal-URL: http://jijo.free.net.ph User-Agent: Mutt/1.5.4i X-archive-position: 4574 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: jijo@free.net.ph Precedence: bulk X-list: linux-xfs On Mon, Jul 07, 2003 at 12:17:50PM +1000, Keith Owens wrote: > Note: This is a respin as of 2.4.21-2003-07-07_02:01_UTC, it replaces > the split patches that were done on 2003-06-23_01:45_UTC. The > latter patches contain bad XFS code and should not be used. As stated in my previous email to the list, I'm using the split patches done on 2003-06-23_01:45_UTC with the xfs_globals.c patch posted on the list, which fixes the last two problems reported about the split patches. I'm curious: what "bad XFS code" remains (after xfs_globals.c.diff) that the respin fixes? Thank you very much. --> Jijo -- Federico Sevilla III : http://jijo.free.net.ph : When we speak of free Network Administrator : The Leather Collection, Inc. : software we refer to GnuPG Key ID : 0x93B746BE : freedom, not price. From owner-linux-xfs@oss.sgi.com Sun Jul 6 19:59:06 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 06 Jul 2003 19:59:48 -0700 (PDT) Received: from zok.sgi.com (zok.SGI.COM [204.94.215.101]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h672wP2x029719 for ; Sun, 6 Jul 2003 19:59:05 -0700 Received: from flecktone.americas.sgi.com (flecktone.americas.sgi.com [192.48.203.135]) by zok.sgi.com (8.12.9/8.12.2/linux-outbound_gateway-1.2) with ESMTP id h672wJiY007240 for ; Sun, 6 Jul 2003 19:58:20 -0700 Received: from daisy-e236.americas.sgi.com (daisy-e236.americas.sgi.com [128.162.236.214]) by flecktone.americas.sgi.com (8.12.9/8.12.9/generic_config-1.2) with ESMTP id h672vJqX8027364; Sun, 6 Jul 2003 21:57:19 -0500 (CDT) Received: from [192.168.1.100] (cf-vpn-sw-corp-64-5.corp.sgi.com [134.15.64.5]) by daisy-e236.americas.sgi.com (8.12.9/SGI-server-1.8) with ESMTP id h672vHRn162383065; Sun, 6 Jul 2003 21:57:18 -0500 (CDT) Subject: Re: Announce: XFS split patches for 2.4.21 From: Steve Lord To: Federico Sevilla III Cc: linux-xfs@oss.sgi.com In-Reply-To: <20030707023702.GC1262@leathercollection.ph> References: <3489.1057544270@kao2.melbourne.sgi.com> <20030707023702.GC1262@leathercollection.ph> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.8 (1.0.8-10) Date: 06 Jul 2003 21:58:10 -0500 Message-Id: <1057546691.8507.3.camel@laptop.americas.sgi.com> Mime-Version: 1.0 X-archive-position: 4575 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: lord@sgi.com Precedence: bulk X-list: linux-xfs On Sun, 2003-07-06 at 21:37, Federico Sevilla III wrote: > On Mon, Jul 07, 2003 at 12:17:50PM +1000, Keith Owens wrote: > > Note: This is a respin as of 2.4.21-2003-07-07_02:01_UTC, it replaces > > the split patches that were done on 2003-06-23_01:45_UTC. The > > latter patches contain bad XFS code and should not be used. > > As stated in my previous email to the list, I'm using the split patches > done on 2003-06-23_01:45_UTC with the xfs_globals.c patch posted on the > list, which fixes the last two problems reported about the split > patches. I'm curious: what "bad XFS code" remains (after > xfs_globals.c.diff) that the respin fixes? The globals stuff has been reworked again - to avoid shooting ourselves in the foot like this in the future. Not a lot of other differences I think. Steve From owner-linux-xfs@oss.sgi.com Sun Jul 6 20:37:32 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 06 Jul 2003 20:38:12 -0700 (PDT) Received: from tolkor.sgi.com ([198.149.18.6]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h673ap2x030403 for ; Sun, 6 Jul 2003 20:37:32 -0700 Received: from bruce.melbourne.sgi.com (bruce.melbourne.sgi.com [134.14.54.176]) by tolkor.sgi.com (8.12.9/8.12.2/linux-outbound_gateway-1.2) with ESMTP id h673semO023965 for ; Sun, 6 Jul 2003 22:54:41 -0500 Received: from bruce.melbourne.sgi.com (localhost.localdomain [127.0.0.1]) by bruce.melbourne.sgi.com (8.12.8/8.12.8) with ESMTP id h673ZU9l004518 for ; Mon, 7 Jul 2003 13:35:30 +1000 Received: (from fsgqa@localhost) by bruce.melbourne.sgi.com (8.12.8/8.12.8/Submit) id h673ZTVM004517 for linux-xfs@oss.sgi.com; Mon, 7 Jul 2003 13:35:29 +1000 Date: Mon, 7 Jul 2003 13:35:29 +1000 From: FSG QA Message-Id: <200307070335.h673ZTVM004517@bruce.melbourne.sgi.com> Subject: TAKE - QA test updates X-archive-position: 4576 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: fsgqa@bruce.melbourne.sgi.com Precedence: bulk X-list: linux-xfs Fix for external log/rt on the test device for auto-qa Date: Mon May 26 18:04:39 PDT 2003 Workarea: bruce.melbourne.sgi.com:/home/fsgqa/qa/2.4.x-xfs The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: xfs-cmds:slinx:150001a cmd/xfstests/common.rc - 1.22 Subject: TAKE - QA update - do not remount filesystems if corruption detected as this writes to the log Date: Thu May 29 21:41:31 PDT 2003 Workarea: bruce.melbourne.sgi.com:/home/fsgqa/qa/2.4.x-xfs The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: xfs-cmds:slinx:150092a cmd/xfstests/common.rc - 1.23 Subject: TAKE - QA test updates. Date: Sun Jun 1 14:40:24 PDT 2003 Workarea: bruce.melbourne.sgi.com:/home/fsgqa/qa/2.4.x-xfs The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: xfs-cmds:slinx:150119a cmd/xfstests/common.rc - 1.24 - Fix mounting of test fs/dev so that external log/rt devices can be used. cmd/xfstests/031 - 1.10 - Fix test so that it works with larger inode sizes also. Subject: TAKE - Ensure QA tests are run with all the mount options requested Date: Sun Jun 1 18:49:23 PDT 2003 Workarea: bruce.melbourne.sgi.com:/home/fsgqa/qa/2.4.x-xfs The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: xfs-cmds:slinx:150121a cmd/xfstests/common.rc - 1.25 Subject: TAKE - Remove temporary QA test hack to work around a failing large sector test Date: Sun Jun 1 22:41:28 PDT 2003 Workarea: bruce.melbourne.sgi.com:/home/fsgqa/qa/2.4.x-xfs The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: xfs-cmds:slinx:150128a cmd/xfstests/group - 1.28 Subject: TAKE - Fix QA tests which use dd so that they specify posixly correct output Date: Wed Jun 11 21:17:41 PDT 2003 Workarea: bruce.melbourne.sgi.com:/home/fsgqa/qa/2.4.x-xfs The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: xfs-cmds:slinx:150985a cmd/xfstests/015 - 1.9 cmd/xfstests/021 - 1.15 cmd/xfstests/common.repair - 1.9 cmd/xfstests/common.dump - 1.42 Subject: TAKE - QA updates and a couple of new tests. Date: Sun Jul 6 20:34:36 PDT 2003 Workarea: bruce.melbourne.sgi.com:/home/fsgqa/qa/2.4.x-xfs The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: xfs-cmds:slinx:152526a cmd/xfstests/071 - 1.1 - Exercise some of the limits for large file handling on 32-bit-sector_t systems. cmd/xfstests/071.out - 1.1 - Exercise some of the limits for large file handling on 32-bit-sector_t systems. cmd/xfstests/072 - 1.1 - Exercise some unwritten extent cases, one of which is mikev's deadlock. cmd/xfstests/072.out - 1.1 - Exercise some unwritten extent cases, one of which is mikev's deadlock. cmd/xfstests/run.dbench20 - 1.1 - Run dbench with 20 clients. cmd/xfstests/new - 1.8 - Fix up some dates. cmd/xfstests/group - 1.29 - Add some new tests, rename a group for consistency. From owner-linux-xfs@oss.sgi.com Sun Jul 6 21:15:05 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 06 Jul 2003 21:15:19 -0700 (PDT) Received: from tolkor.sgi.com ([198.149.18.6]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h674F52x031095 for ; Sun, 6 Jul 2003 21:15:05 -0700 Received: from flecktone.americas.sgi.com (flecktone.americas.sgi.com [192.48.203.135]) by tolkor.sgi.com (8.12.9/8.12.2/linux-outbound_gateway-1.2) with ESMTP id h674WtmO027127 for ; Sun, 6 Jul 2003 23:32:55 -0500 Received: from poppy-e236.americas.sgi.com (poppy-e236.americas.sgi.com [128.162.236.207]) by flecktone.americas.sgi.com (8.12.9/8.12.9/generic_config-1.2) with ESMTP id h674ExqX8032311 for ; Sun, 6 Jul 2003 23:14:59 -0500 (CDT) Received: from stout.americas.sgi.com (stout.americas.sgi.com [128.162.232.50]) by poppy-e236.americas.sgi.com (8.12.9/SGI-server-1.8) with ESMTP id h674ExYl13857140 for ; Sun, 6 Jul 2003 23:14:59 -0500 (CDT) Date: Sun, 6 Jul 2003 23:14:59 -0500 (CDT) From: Eric Sandeen X-X-Sender: sandeen@stout.americas.sgi.com To: linux-xfs@oss.sgi.com Subject: TAKE - fail xfs_setattr on read-only filesystemsB Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 4577 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: sandeen@sgi.com Precedence: bulk X-list: linux-xfs Catch read-only filesystems in xfs_setattr, and return EROFS Odds you're not hitting this, but it's worth fixing. Note that this is not related to extended attributes, but to the XFS_IOC_FSSETXATTR ioctl call. Thanks to Ethan Benson for finding this one. Date: Sun Jul 6 21:10:21 PDT 2003 Workarea: penguin.americas.sgi.com:/src/sandeen/2.4.x-xfs/workarea-alwaysclean The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: xfs-linux:slinx:152528a linux/fs/xfs/xfs_vnodeops.c - 1.596 From owner-linux-xfs@oss.sgi.com Sun Jul 6 21:58:46 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 06 Jul 2003 21:58:58 -0700 (PDT) Received: from zok.sgi.com (zok.SGI.COM [204.94.215.101]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h674wk2x032024 for ; Sun, 6 Jul 2003 21:58:46 -0700 Received: from sherman.melbourne.sgi.com (sherman.melbourne.sgi.com [134.14.54.232]) by zok.sgi.com (8.12.9/8.12.2/linux-outbound_gateway-1.2) with ESMTP id h674wdiY021275 for ; Sun, 6 Jul 2003 21:58:40 -0700 Received: (from kaos@localhost) by sherman.melbourne.sgi.com (8.11.6/8.11.6) id h674vcb24140; Mon, 7 Jul 2003 14:57:38 +1000 Date: Mon, 7 Jul 2003 14:57:38 +1000 From: Keith Owens Message-Id: <200307070457.h674vcb24140@sherman.melbourne.sgi.com> Subject: TAKE - Make VM_PAGEBUF the same number as in 2.5 kernels X-archive-position: 4578 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: kaos@sherman.melbourne.sgi.com Precedence: bulk X-list: linux-xfs Make VM_PAGEBUF the same number as in 2.5 kernels Date: Sun Jul 6 21:57:06 PDT 2003 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:152529a linux/include/linux/sysctl.h - 1.56 From owner-linux-xfs@oss.sgi.com Sun Jul 6 22:11:51 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 06 Jul 2003 22:11:55 -0700 (PDT) Received: from blake.timetraveller.org (blake.timetraveller.org [203.23.43.10]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h675B92x032582 for ; Sun, 6 Jul 2003 22:11:50 -0700 Received: from zen.canint.timetraveller.org (CPE00105ae6b1e1-CM000039aeec61.cpe.net.cable.rogers.com [63.139.6.84]) by blake.timetraveller.org (8.12.3/8.12.3) with ESMTP id h675BmLO010101 for ; Mon, 7 Jul 2003 15:11:49 +1000 Received: from zen.canint.timetraveller.org (zen.canint.timetraveller.org [192.168.120.1]) by zen.canint.timetraveller.org (8.12.6/8.12.6) with ESMTP id h67528wG017396 for ; Mon, 7 Jul 2003 01:02:08 -0400 Date: Mon, 7 Jul 2003 01:02:08 -0400 (EDT) From: Robert Brockway X-X-Sender: robert@zen.canint.timetraveller.org To: linux-xfs@oss.sgi.com Subject: Re: [bug report]: chown(2) implementation in xfs is broken In-Reply-To: <3F08C005.3070706@linux-sxs.org> Message-ID: References: <7kadbrchcp.fsf@greenplant.dot> <3F08C005.3070706@linux-sxs.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 4579 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: robert@timetraveller.org Precedence: bulk X-list: linux-xfs This is a security issue if anyone is using unix permissions to restrict execution _from_ a subset of users. This is unusual but I've seen it done. zen:~$ cat ./testfile #!/bin/bash echo "I'm executing!" zen:~$ ls -l testfile ----r-xr-x 1 robert users 46 Jul 7 00:52 testfile* zen:~$ ./testfile bash: ./testfile: Permission denied zen:~$ chown root ./testfile zen:~$ ls -l ./testfile ----r-xr-x 1 root users 35 Jul 7 00:57 ./testfile* zen:~$ ./testfile I'm executing! Rob -- Robert Brockway B.Sc. email: robert@timetraveller.org ICQ: 104781119 Linux counter project ID #16440 (http://counter.li.org) "The earth is but one country and mankind its citizens" -Baha'u'llah From owner-linux-xfs@oss.sgi.com Sun Jul 6 22:32:02 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 06 Jul 2003 22:32:41 -0700 (PDT) Received: from hermod.slb.nwc.acsalaska.net (hermod.slb.nwc.acsalaska.net [209.112.155.45]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h675W12x000651 for ; Sun, 6 Jul 2003 22:32:02 -0700 Received: from erbenson.alaska.net (139-pm3.nwc.alaska.net [209.112.138.139]) by hermod.slb.nwc.acsalaska.net (8.12.9/8.12.9) with ESMTP id h675VxF2018518 for ; Sun, 6 Jul 2003 21:31:59 -0800 (AKDT) (envelope-from erbenson@alaska.net) Received: from plato.local.lan (plato.local.lan [192.168.0.4]) by erbenson.alaska.net (Postfix) with ESMTP id 5BCE73A0C for ; Sun, 6 Jul 2003 21:31:58 -0800 (AKDT) Received: by plato.local.lan (Postfix, from userid 1000) id 6717740FF44; Sun, 6 Jul 2003 21:31:58 -0800 (AKDT) Date: Sun, 6 Jul 2003 21:31:58 -0800 From: Ethan Benson To: linux-xfs@oss.sgi.com Subject: Re: [bug report]: chown(2) implementation in xfs is broken Message-ID: <20030707053158.GW930@plato.local.lan> Mail-Followup-To: linux-xfs@oss.sgi.com References: <7kadbrchcp.fsf@greenplant.dot> <3F08C005.3070706@linux-sxs.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="Z1gw0Ba8VHj8Ap4r" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.3.28i X-OS: Debian GNU X-gpg-fingerprint: E3E4 D0BC 31BC F7BB C1DD C3D6 24AC 7B1A 2C44 7AFC X-gpg-key: http://www.alaska.net/~erbenson/gpg/key.asc Mail-Copies-To: nobody X-No-CC: I subscribe to this list; do not CC me on replies. X-ACS-Spam-Status: no X-Scanned-By: MIMEDefang 2.34 X-archive-position: 4580 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: erbenson@alaska.net Precedence: bulk X-list: linux-xfs --Z1gw0Ba8VHj8Ap4r Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Jul 07, 2003 at 01:02:08AM -0400, Robert Brockway wrote: > This is a security issue if anyone is using unix permissions to restrict > execution _from_ a subset of users. This is unusual but I've seen it > done. >=20 > zen:~$ cat ./testfile > #!/bin/bash >=20 > echo "I'm executing!" >=20 > zen:~$ ls -l testfile > ----r-xr-x 1 robert users 46 Jul 7 00:52 testfile* >=20 > zen:~$ ./testfile > bash: ./testfile: Permission denied >=20 > zen:~$ chown root ./testfile >=20 > zen:~$ ls -l ./testfile > ----r-xr-x 1 root users 35 Jul 7 00:57 ./testfile* >=20 > zen:~$ ./testfile > I'm executing! this is correct unix behavior. your userid is not root, its zen, so you are permitted to execute testfile, everyone EXCEPT root is permitted to execute this file. (except root is allowed too since at least one x bit is set on the file, and root has authority to disregard file permissions). --=20 Ethan Benson http://www.alaska.net/~erbenson/ --Z1gw0Ba8VHj8Ap4r Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iEYEARECAAYFAj8JBc4ACgkQJKx7GixEevw2zACffroawpKy6D5PnzzxslCxy6jQ pFUAoJ0RM/hurz4UabRicEw43nm5Ed66 =5acn -----END PGP SIGNATURE----- --Z1gw0Ba8VHj8Ap4r-- From owner-linux-xfs@oss.sgi.com Sun Jul 6 22:33:55 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 06 Jul 2003 22:33:59 -0700 (PDT) Received: from hermod.slb.nwc.acsalaska.net (hermod.slb.nwc.acsalaska.net [209.112.155.45]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h675XE2x000804 for ; Sun, 6 Jul 2003 22:33:54 -0700 Received: from erbenson.alaska.net (139-pm3.nwc.alaska.net [209.112.138.139]) by hermod.slb.nwc.acsalaska.net (8.12.9/8.12.9) with ESMTP id h675XCF2019036 for ; Sun, 6 Jul 2003 21:33:13 -0800 (AKDT) (envelope-from erbenson@alaska.net) Received: from plato.local.lan (plato.local.lan [192.168.0.4]) by erbenson.alaska.net (Postfix) with ESMTP id B69A63A0C for ; Sun, 6 Jul 2003 21:33:11 -0800 (AKDT) Received: by plato.local.lan (Postfix, from userid 1000) id E96F740FF47; Sun, 6 Jul 2003 21:33:11 -0800 (AKDT) Date: Sun, 6 Jul 2003 21:33:11 -0800 From: Ethan Benson To: linux-xfs@oss.sgi.com Subject: Re: [bug report]: chown(2) implementation in xfs is broken Message-ID: <20030707053311.GX930@plato.local.lan> Mail-Followup-To: linux-xfs@oss.sgi.com References: <7kadbrchcp.fsf@greenplant.dot> <3F08C005.3070706@linux-sxs.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="jwSnfOBD38i7UC9C" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.3.28i X-OS: Debian GNU X-gpg-fingerprint: E3E4 D0BC 31BC F7BB C1DD C3D6 24AC 7B1A 2C44 7AFC X-gpg-key: http://www.alaska.net/~erbenson/gpg/key.asc Mail-Copies-To: nobody X-No-CC: I subscribe to this list; do not CC me on replies. X-ACS-Spam-Status: no X-Scanned-By: MIMEDefang 2.34 X-archive-position: 4581 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: erbenson@alaska.net Precedence: bulk X-list: linux-xfs --jwSnfOBD38i7UC9C Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Jul 07, 2003 at 01:02:08AM -0400, Robert Brockway wrote: > This is a security issue if anyone is using unix permissions to restrict > execution _from_ a subset of users. This is unusual but I've seen it > done. >=20 > zen:~$ cat ./testfile > #!/bin/bash >=20 > echo "I'm executing!" >=20 > zen:~$ ls -l testfile > ----r-xr-x 1 robert users 46 Jul 7 00:52 testfile* >=20 > zen:~$ ./testfile > bash: ./testfile: Permission denied >=20 > zen:~$ chown root ./testfile my previous mail i missed that you were doing this as non-root. as already reported you need to update your patches, or else sysctl -w fs/xfs/restrict_chown=3D1 as the default was broken in the first set of 2.4.21 split patches. --=20 Ethan Benson http://www.alaska.net/~erbenson/ --jwSnfOBD38i7UC9C Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iEYEARECAAYFAj8JBhcACgkQJKx7GixEevzFlgCfUX0iRBRcaNncPpSwdJVNjGqe q+cAnjCbIPV/Io8GZLYsfGdvR7fW6qFL =mSD4 -----END PGP SIGNATURE----- --jwSnfOBD38i7UC9C-- From owner-linux-xfs@oss.sgi.com Sun Jul 6 22:42:07 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 06 Jul 2003 22:42:11 -0700 (PDT) Received: from gusi.leathercollection.ph (gusi.leathercollection.ph [202.163.192.10]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h675g62x001602 for ; Sun, 6 Jul 2003 22:42:07 -0700 Received: from localhost (localhost [127.0.0.1]) by gusi.leathercollection.ph (Postfix) with ESMTP id 88561EB4A12 for ; Mon, 7 Jul 2003 13:42:00 +0800 (PHT) Received: from lawin.leathercollection.ph (lawin.leathercollection.ph [192.168.0.2]) by gusi.leathercollection.ph (Postfix) with ESMTP id 70662EB4A0F for ; Mon, 7 Jul 2003 13:41:52 +0800 (PHT) Received: by lawin.leathercollection.ph (Postfix, from userid 1000) id E4F4A1A4082; Mon, 7 Jul 2003 13:41:51 +0800 (PHT) Date: Mon, 7 Jul 2003 13:41:51 +0800 From: Federico Sevilla III To: linux-xfs@oss.sgi.com Subject: Re: Announce: XFS split patches for 2.4.21 Message-ID: <20030707054151.GD5680@leathercollection.ph> Mail-Followup-To: linux-xfs@oss.sgi.com References: <3489.1057544270@kao2.melbourne.sgi.com> <20030707023702.GC1262@leathercollection.ph> <1057546691.8507.3.camel@laptop.americas.sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1057546691.8507.3.camel@laptop.americas.sgi.com> X-Organization: The Leather Collection, Inc. X-Organization-URL: http://www.leathercollection.ph X-Personal-URL: http://jijo.free.net.ph User-Agent: Mutt/1.5.4i X-archive-position: 4582 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: jijo@free.net.ph Precedence: bulk X-list: linux-xfs On Sun, Jul 06, 2003 at 09:58:10PM -0500, Steve Lord wrote: > The globals stuff has been reworked again - to avoid shooting > ourselves in the foot like this in the future. Not a lot of other > differences I think. Please pardon my confusion. Does this mean that the only major difference between the respun split patches and the initial split patches plus the xfs_globals.c patch posted by Ethan Benson on 2003-06-28 09:23 UTC [1] is that you cleaned things up to prevent you from comitting the same mistake next time? Or is the combination of the original split patches and the xfs_globals.c patch not enough, so people like me who use that combination should schedule a kernel upgrade using the respun patches ASAP? Thank you very much for helping me decide wether an upgrade will be necessary or not. --> Jijo [1] http://marc.free.net.ph/message/20030628.092344.7eff097d.html -- Federico Sevilla III : http://jijo.free.net.ph : When we speak of free Network Administrator : The Leather Collection, Inc. : software we refer to GnuPG Key ID : 0x93B746BE : freedom, not price. From owner-linux-xfs@oss.sgi.com Sun Jul 6 23:01:50 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 06 Jul 2003 23:02:24 -0700 (PDT) Received: from blake.timetraveller.org (blake.timetraveller.org [203.23.43.10]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h676182x002486 for ; Sun, 6 Jul 2003 23:01:49 -0700 Received: from zen.canint.timetraveller.org (CPE00105ae6b1e1-CM000039aeec61.cpe.net.cable.rogers.com [63.139.6.84]) by blake.timetraveller.org (8.12.3/8.12.3) with ESMTP id h6761jLO010424 for ; Mon, 7 Jul 2003 16:01:46 +1000 Received: from zen.canint.timetraveller.org (zen.canint.timetraveller.org [192.168.120.1]) by zen.canint.timetraveller.org (8.12.6/8.12.6) with ESMTP id h675x0wG017841 for ; Mon, 7 Jul 2003 01:59:00 -0400 Date: Mon, 7 Jul 2003 01:59:00 -0400 (EDT) From: Robert Brockway X-X-Sender: robert@zen.canint.timetraveller.org To: linux-xfs@oss.sgi.com Subject: Re: [bug report]: chown(2) implementation in xfs is broken In-Reply-To: <20030707053311.GX930@plato.local.lan> Message-ID: References: <7kadbrchcp.fsf@greenplant.dot> <3F08C005.3070706@linux-sxs.org> <20030707053311.GX930@plato.local.lan> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 4583 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: robert@timetraveller.org Precedence: bulk X-list: linux-xfs On Sun, 6 Jul 2003, Ethan Benson wrote: > my previous mail i missed that you were doing this as non-root. as I probably should have been more explicit about that. I'm actually surprised that xfs allows the liberal behaviour of restrict_chown=0 at all (as a default or not). The potential for abuse is significant. It basically nullifies any use of quotas since it allows any user to force any other user over-quota at any time. This could result in mail bounces and all sorts of mischief. Is the option there for compatability with Irix, and if so, why does Irix allow it? Rob -- Robert Brockway B.Sc. email: robert@timetraveller.org ICQ: 104781119 Linux counter project ID #16440 (http://counter.li.org) "The earth is but one country and mankind its citizens" -Baha'u'llah From owner-linux-xfs@oss.sgi.com Sun Jul 6 23:11:44 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 06 Jul 2003 23:11:47 -0700 (PDT) Received: from tolkor.sgi.com ([198.149.18.6]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h676BO2x003305 for ; Sun, 6 Jul 2003 23:11:44 -0700 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.54.149]) by tolkor.sgi.com (8.12.9/8.12.2/linux-outbound_gateway-1.2) with ESMTP id h676TDmO005712 for ; Mon, 7 Jul 2003 01:29:14 -0500 Received: from snort.melbourne.sgi.com (localhost [127.0.0.1]) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id h676A0JA2669556 for ; Mon, 7 Jul 2003 16:10:00 +1000 (EST) Received: (from nathans@localhost) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id h6769xhL2668634 for linux-xfs@oss.sgi.com; Mon, 7 Jul 2003 16:09:59 +1000 (EST) Date: Mon, 7 Jul 2003 16:09:59 +1000 (EST) From: Nathan Scott Message-Id: <200307070609.h6769xhL2668634@snort.melbourne.sgi.com> To: linux-xfs@oss.sgi.com Subject: TAKE - xfsprogs update X-archive-position: 4584 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: nathans@snort.melbourne.sgi.com Precedence: bulk X-list: linux-xfs Fix userspace build so that msgmerge is not always run. Originally by Steve Langasek. Date: Sun Jul 6 21:04:22 PDT 2003 Workarea: snort.melbourne.sgi.com:/home/nathans/2.4.x-xfs The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: xfs-cmds:slinx:152527a cmd/acl/VERSION - 1.51 cmd/acl/doc/CHANGES - 1.59 cmd/acl/include/buildrules - 1.15 cmd/acl/debian/changelog - 1.45 cmd/attr/VERSION - 1.34 cmd/attr/doc/CHANGES - 1.43 cmd/attr/include/buildrules - 1.11 cmd/attr/debian/changelog - 1.37 cmd/xfsdump/include/buildrules - 1.10 cmd/dmapi/include/buildrules - 1.12 xfsprogs update - fine-tune xfs_io size/offsets to be like mkfs; libdisk and build updates. Date: Sun Jul 6 23:09:01 PDT 2003 Workarea: snort.melbourne.sgi.com:/home/nathans/2.4.x-xfs The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: xfs-cmds:slinx:152532a cmd/xfsprogs/VERSION - 1.83 cmd/xfsprogs/doc/CHANGES - 1.117 cmd/xfsprogs/mkfs/xfs_mkfs.c - 1.48 cmd/xfsprogs/libdisk/fstype.c - 1.8 cmd/xfsprogs/libdisk/fstype.h - 1.8 cmd/xfsprogs/include/buildrules - 1.13 cmd/xfsprogs/debian/changelog - 1.75 cmd/xfsprogs/po/xfsprogs.pot - 1.8 cmd/xfsprogs/io/command.h - 1.3 cmd/xfsprogs/io/pread.c - 1.7 cmd/xfsprogs/io/input.h - 1.3 cmd/xfsprogs/io/Makefile - 1.4 cmd/xfsprogs/io/truncate.c - 1.5 cmd/xfsprogs/io/resblks.c - 1.6 cmd/xfsprogs/io/pwrite.c - 1.6 cmd/xfsprogs/io/prealloc.c - 1.6 cmd/xfsprogs/io/input.c - 1.5 cmd/xfsprogs/io/init.h - 1.3 cmd/xfsprogs/io/open.c - 1.7 cmd/xfsprogs/io/init.c - 1.5 From owner-linux-xfs@oss.sgi.com Sun Jul 6 23:29:27 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 06 Jul 2003 23:29:39 -0700 (PDT) Received: from tolkor.sgi.com ([198.149.18.6]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h676TQ2x003828 for ; Sun, 6 Jul 2003 23:29:27 -0700 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by tolkor.sgi.com (8.12.9/8.12.2/linux-outbound_gateway-1.2) with SMTP id h676lEmO007118 for ; Mon, 7 Jul 2003 01:47:15 -0500 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 QAA02183; Mon, 7 Jul 2003 16:28:00 +1000 Received: by kao2.melbourne.sgi.com (Postfix, from userid 16331) id CD01AD84FE; Mon, 7 Jul 2003 16:27:59 +1000 (EST) Received: from kao2.melbourne.sgi.com (localhost [127.0.0.1]) by kao2.melbourne.sgi.com (Postfix) with ESMTP id CB49A912D6; Mon, 7 Jul 2003 16:27:59 +1000 (EST) X-Mailer: exmh version 2.5 01/15/2001 with nmh-1.0.4 From: Keith Owens To: Federico Sevilla III Cc: linux-xfs@oss.sgi.com Subject: Re: Announce: XFS split patches for 2.4.21 In-reply-to: Your message of "Mon, 07 Jul 2003 13:41:51 +0800." <20030707054151.GD5680@leathercollection.ph> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 07 Jul 2003 16:27:54 +1000 Message-ID: <1715.1057559274@kao2.melbourne.sgi.com> X-archive-position: 4585 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: kaos@sgi.com Precedence: bulk X-list: linux-xfs On Mon, 7 Jul 2003 13:41:51 +0800, Federico Sevilla III wrote: >Does this mean that the only major difference between the respun split >patches and the initial split patches plus the xfs_globals.c patch >posted by Ethan Benson on 2003-06-28 09:23 UTC [1] is that you cleaned >things up to prevent you from comitting the same mistake next time? This is the diff from the split patches of 2003-06-23_01:45_UTC to 2003-07-07_02:01_UTC. Besides the xfs changes, there are improvements in kdb. I suggest you upgrade. Documentation/filesystems/xfs.txt | 77 +++++++++++++ arch/i386/kdb/ChangeLog | 7 + arch/i386/kdb/kdba_bt.c | 2 arch/i386/kdb/kdbasupport.c | 160 ++++++++++++++++++---------- arch/i386/kernel/smp.c | 9 + fs/xfs/linux/xfs_globals.c | 15 ++ fs/xfs/linux/xfs_linux.h | 14 +- fs/xfs/linux/xfs_super.c | 2 fs/xfs/linux/xfs_sysctl.c | 58 +++++----- fs/xfs/linux/xfs_sysctl.h | 27 ++-- fs/xfs/linux/xfs_version.h | 2 fs/xfs/pagebuf/page_buf.c | 39 ++++-- fs/xfs/pagebuf/page_buf_internal.h | 19 +-- fs/xfs/xfs_rw.c | 9 - fs/xfs/xfs_vfsops.c | 6 - kdb/ChangeLog | 11 + kdb/modules/Makefile | 2 kdb/modules/kdbm_task.c | 209 +++++++++++++++++++++++++++++++++++++ kernel/sysctl.c | 4 19 files changed, 526 insertions(+), 146 deletions(-) diff -urN 2.4.21-xfs-old/Documentation/filesystems/xfs.txt 2.4.21-xfs-new/Documentation/filesystems/xfs.txt --- 2.4.21-xfs-old/Documentation/filesystems/xfs.txt Mon Jul 7 16:23:29 2003 +++ 2.4.21-xfs-new/Documentation/filesystems/xfs.txt Mon Jul 7 16:23:11 2003 @@ -14,8 +14,8 @@ with the IRIX version of XFS. -Options -======= +Mount Options +============= When mounting an XFS filesystem, the following options are accepted. @@ -116,3 +116,76 @@ Don't check for double mounted file systems using the file system uuid. This is useful to mount LVM snapshot volumes. +sysctls +======= + +The following sysctls are available for the XFS filesystem: + + fs.xfs.stats_clear (Min: 0 Default: 0 Max: 1) + Setting this to "1" clears accumulated XFS statistics + in /proc/fs/xfs/stat. It then immediately reset to "0". + + fs.xfs.sync_interval (Min: HZ Default: 30*HZ Max: 60*HZ) + The interval at which the xfssyncd thread for xfs filesystems + flushes metadata out to disk. This thread will flush log + activity out, and do some processing on unlinked inodes + + fs.xfs.error_level (Min: 0 Default: 3 Max: 11) + A volume knob for error reporting when internal errors occur. + This will generate detailed messages & backtraces for filesystem + shutdowns, for example. Current threshold values are: + + XFS_ERRLEVEL_OFF: 0 + XFS_ERRLEVEL_LOW: 1 + XFS_ERRLEVEL_HIGH: 5 + + fs.xfs.panic_mask (Min: 0 Default: 0 Max: 127) + Causes certain error conditions to call BUG(). Value is a bitmask; + AND together the tags which represent errors which should cause panics: + + XFS_NO_PTAG 0LL + XFS_PTAG_IFLUSH 0x0000000000000001LL + XFS_PTAG_LOGRES 0x0000000000000002LL + XFS_PTAG_AILDELETE 0x0000000000000004LL + XFS_PTAG_ERROR_REPORT 0x0000000000000008LL + XFS_PTAG_SHUTDOWN_CORRUPT 0x0000000000000010LL + XFS_PTAG_SHUTDOWN_IOERROR 0x0000000000000020LL + XFS_PTAG_SHUTDOWN_LOGERROR 0x0000000000000040LL + + This option is intended for debugging only. + + fs.xfs.irix_symlink_mode (Min: 0 Default: 0 Max: 1) + Controls whether symlinks are created with mode 0777 (default) + or whether their mode is affected by the umask (irix mode). + + fs.xfs.irix_sgid_inherit (Min: 0 Default: 0 Max: 1) + Controls files created in SGID directories. + If the group ID of the new file does not match the effective group + ID or one of the supplementary group IDs of the parent dir, the + ISGID bit is cleared if the irix_sgid_inherit compatibility sysctl + is set. + + fs.xfs.restrict_chown (Min: 0 Default: 1 Max: 1) + Controls whether unprivileged users can use chown to "give away" + a file to another user. + + fs.xfs.refcache_size (Min: 0 Default: 128 Max: 512) + Controls the size of the NFS refcache, which holds references + on files opened via NFS to improve performance. The value + is the maximum number of files which can be in the cache at + any one time. + + fs.xfs.refcache_purge (Min: 0 Default: 32 Max: 512) + Controls the number of entries purged from the NFS refcache + every sync interval. + + vm.pagebuf.stats_clear (Min: 0 Default: 0 Max: 1) + Setting this to "1" clears accumulated pagebuf statistics + in /proc/fs/pagebuf/stat. It then immediately reset to "0". + + vm.pagebuf.flush_age (Min: 1*HZ Default: 15*HZ Max: 300*HZ) + The age at which dirty metadata buffers are flushed to disk + + vm.pagebuf.flush_int (Min: HZ/2 Default: HZ Max: 30*HZ) + The interval at which the list of dirty metadata buffers is + scanned. diff -urN 2.4.21-xfs-old/arch/i386/kdb/ChangeLog 2.4.21-xfs-new/arch/i386/kdb/ChangeLog --- 2.4.21-xfs-old/arch/i386/kdb/ChangeLog Mon Jul 7 16:23:29 2003 +++ 2.4.21-xfs-new/arch/i386/kdb/ChangeLog Mon Jul 7 16:23:11 2003 @@ -1,3 +1,10 @@ +2003-07-01 Keith Owens + + * Convert kdba_find_return() to two passes to reduce false positives. + * Correct jmp disp8 offset calculation for out of line lock code. + * Use NMI for kdb IPI in clustered APIC mode. Sachin Sant, IBM. + * kdb v4.3-2.4.21-i386-3. + 2003-06-23 Keith Owens * Sync with XFS 2.4.21 tree. diff -urN 2.4.21-xfs-old/arch/i386/kdb/kdba_bt.c 2.4.21-xfs-new/arch/i386/kdb/kdba_bt.c --- 2.4.21-xfs-old/arch/i386/kdb/kdba_bt.c Mon Jul 7 16:23:29 2003 +++ 2.4.21-xfs-new/arch/i386/kdb/kdba_bt.c Mon Jul 7 16:23:11 2003 @@ -268,7 +268,7 @@ kdb_di.fprintf_func = save_fprintf_func; if (offsize) { - realeip += 1 + offsize + offset; + realeip += 1 + offsize + (offsize == 1 ? (s8)offset : (s32)offset); if (kdbnearsym(realeip, &lock_symtab)) { /* Print the stext entry without args */ bt_print_one(eip, NOBP, &ar, &symtab, 0); diff -urN 2.4.21-xfs-old/arch/i386/kdb/kdbasupport.c 2.4.21-xfs-new/arch/i386/kdb/kdbasupport.c --- 2.4.21-xfs-old/arch/i386/kdb/kdbasupport.c Mon Jul 7 16:23:29 2003 +++ 2.4.21-xfs-new/arch/i386/kdb/kdbasupport.c Mon Jul 7 16:23:11 2003 @@ -48,7 +48,7 @@ #include /* - * kdba_find_return + * kdba_find_return_1 * * Given a starting point on the stack and symtab data for the * current function, scan up the stack looking for a return @@ -57,6 +57,7 @@ * sp Starting stack pointer for scan * ss Start of stack for current process * symtab kallsyms symbol data for the function + * assume When false, do not apply tests that have to assume a branch is valid * Outputs: * None. * Returns: @@ -68,7 +69,7 @@ */ static kdb_machreg_t -kdba_find_return(kdb_machreg_t sp, kdb_machreg_t ss, const kdb_symtab_t *symtab) +kdba_find_return_1(kdb_machreg_t sp, kdb_machreg_t ss, const kdb_symtab_t *symtab, int assume) { kdb_machreg_t ret; kdb_symtab_t caller_symtab; @@ -77,20 +78,6 @@ unsigned char code[7]; #define retaddr(off) code[sizeof(code)+(off)] - if (KDB_DEBUG(ARA)) { - kdb_printf(" kdba_find_return: start\n"); - } - - if ((sp & -THREAD_SIZE) != ss) { - kdb_printf(" sp is in wrong stack 0x%lx 0x%lx 0x%lx\n", sp, ss, sp & -THREAD_SIZE); - return(0); - } - - if ((sp & (THREAD_SIZE - 1)) < sizeof(struct task_struct)) { - kdb_printf(" sp is inside task_struct\n"); - return(0); - } - for (;ret = 0, sp & (THREAD_SIZE-1);sp += 4) { if (KDB_DEBUG(ARA)) { kdb_printf(" sp=0x%lx", sp); @@ -127,6 +114,52 @@ if (KDB_DEBUG(ARA)) { kdb_printf(" failed"); } + } else if (retaddr(-5) == 0xe9) { + /* jmp disp32. I have been told that gcc may + * do function tail optimization and replace + * call with jmp. + */ + if (KDB_DEBUG(ARA)) { + kdb_printf(" jmp disp32\n"); + } + if (ret + (s32) disp32 == symtab->sym_start) { + if (KDB_DEBUG(ARA)) { + kdb_printf(" matched\n"); + } + break; /* jmp to this function */ + } + if (KDB_DEBUG(ARA)) { + kdb_printf(" failed"); + } + } else if (retaddr(-2) == 0xeb) { + /* jmp disp8 */ + if (KDB_DEBUG(ARA)) { + kdb_printf(" jmp disp8\n"); + } + if (ret + (s8) disp8 == symtab->sym_start) { + if (KDB_DEBUG(ARA)) { + kdb_printf(" matched\n"); + } + break; /* jmp to this function */ + } + if (KDB_DEBUG(ARA)) { + kdb_printf(" failed"); + } + } else if (strcmp(caller_symtab.sym_name, "ret_from_intr") == 0 + && ret == caller_symtab.sym_start) { + /* ret_from_intr is pushed on stack for interrupts */ + if (KDB_DEBUG(ARA)) { + kdb_printf(" ret_from_intr matched\n"); + } + break; /* special case, hand crafted frame */ + } else if (!assume) { + /* All following tests cannot validate the target address so they + * must assume that the return address is valid. + */ + if (KDB_DEBUG(ARA)) { + kdb_printf("\n"); + } + continue; } else if (retaddr(-7) == 0xff && retaddr(-6) == 0x14 && retaddr(-5) == 0x85) { /* call *disp32(,%eax,4), used by syscall. * Cannot calculate address, assume it is valid @@ -139,7 +172,7 @@ if (strncmp(symtab->sym_name, "sys_", 4) == 0 || strncmp(symtab->sym_name, "old_", 4) == 0) { if (KDB_DEBUG(ARA)) { - kdb_printf(" matched\n"); + kdb_printf(" assume valid\n"); } break; /* probably call to this function */ } @@ -171,44 +204,6 @@ kdb_printf(" call *disp32(%%reg), assume valid\n"); } break; /* hope it is a call to this function */ - } else if (retaddr(-5) == 0xe9) { - /* jmp disp32. I have been told that gcc may - * do function tail optimization and replace - * call with jmp. - */ - if (KDB_DEBUG(ARA)) { - kdb_printf(" jmp disp32\n"); - } - if (ret + (s32) disp32 == symtab->sym_start) { - if (KDB_DEBUG(ARA)) { - kdb_printf(" matched\n"); - } - break; /* jmp to this function */ - } - if (KDB_DEBUG(ARA)) { - kdb_printf(" failed"); - } - } else if (retaddr(-2) == 0xeb) { - /* jmp disp8 */ - if (KDB_DEBUG(ARA)) { - kdb_printf(" jmp disp8\n"); - } - if (ret + (s8) disp8 == symtab->sym_start) { - if (KDB_DEBUG(ARA)) { - kdb_printf(" matched\n"); - } - break; /* jmp to this function */ - } - if (KDB_DEBUG(ARA)) { - kdb_printf(" failed"); - } - } else if (strcmp(caller_symtab.sym_name, "ret_from_intr") == 0 - && ret == caller_symtab.sym_start) { - /* ret_from_intr is pushed on stack for interrupts */ - if (KDB_DEBUG(ARA)) { - kdb_printf(" ret_from_intr matched\n"); - } - break; /* special case, hand crafted frame */ } if (KDB_DEBUG(ARA)) { kdb_printf("\n"); @@ -218,8 +213,59 @@ kdb_printf(" end ret=0x%lx sp=0x%lx\n", ret, sp); } if (ret) - return(sp); - return(0); + return sp; + return 0; +} + +/* + * kdba_find_return + * + * Given a starting point on the stack and symtab data for the + * current function, scan up the stack looking for a return + * address for this function. + * Inputs: + * sp Starting stack pointer for scan + * ss Start of stack for current process + * symtab kallsyms symbol data for the function + * Outputs: + * None. + * Returns: + * Position on stack of return address, 0 if not found. + * Locking: + * None. + * Remarks: + * This is sensitive to the calling sequence generated by gcc. + */ + +static kdb_machreg_t +kdba_find_return(kdb_machreg_t sp, kdb_machreg_t ss, const kdb_symtab_t *symtab) +{ + kdb_machreg_t ret; + + if (KDB_DEBUG(ARA)) { + kdb_printf(" kdba_find_return: start\n"); + } + + if ((sp & -THREAD_SIZE) != ss) { + kdb_printf(" sp is in wrong stack 0x%lx 0x%lx 0x%lx\n", sp, ss, sp & -THREAD_SIZE); + return 0; + } + + if ((sp & (THREAD_SIZE - 1)) < sizeof(struct task_struct)) { + kdb_printf(" sp is inside task_struct\n"); + return 0; + } + + if (KDB_DEBUG(ARA)) { + kdb_printf(" kdba_find_return_1(assume==0)\n"); + } + if ((ret = kdba_find_return_1(sp, ss, symtab, 0))) + return ret; + if (KDB_DEBUG(ARA)) { + kdb_printf(" kdba_find_return_1(assume==1)\n"); + } + ret = kdba_find_return_1(sp, ss, symtab, 1); + return ret; } /* diff -urN 2.4.21-xfs-old/arch/i386/kernel/smp.c 2.4.21-xfs-new/arch/i386/kernel/smp.c --- 2.4.21-xfs-old/arch/i386/kernel/smp.c Mon Jul 7 16:23:29 2003 +++ 2.4.21-xfs-new/arch/i386/kernel/smp.c Mon Jul 7 16:23:11 2003 @@ -238,6 +238,15 @@ * program the ICR */ cfg = __prepare_ICR(0, vector); + +#ifdef CONFIG_KDB + if (vector == KDB_VECTOR) { + /* + * Setup KDB IPI to be delivered as an NMI + */ + cfg = (cfg&~APIC_VECTOR_MASK)|APIC_DM_NMI; + } +#endif /* CONFIG_KDB */ /* * Send the IPI. The write to APIC_ICR fires this off. diff -urN 2.4.21-xfs-old/fs/xfs/linux/xfs_globals.c 2.4.21-xfs-new/fs/xfs/linux/xfs_globals.c --- 2.4.21-xfs-old/fs/xfs/linux/xfs_globals.c Mon Jul 7 16:23:29 2003 +++ 2.4.21-xfs-new/fs/xfs/linux/xfs_globals.c Mon Jul 7 16:23:12 2003 @@ -40,6 +40,7 @@ #include "xfs_types.h" #include "xfs_bmap_btree.h" #include "xfs_bit.h" +#include "xfs_rw.h" /* * System memory size - used to scale certain data structures in XFS. @@ -50,7 +51,19 @@ * Tunable XFS parameters. xfs_params is required even when CONFIG_SYSCTL=n, * other XFS code uses these values. */ -xfs_param_t xfs_params = { 128, 32, 0, 1, 0, 0, 3, 30 * HZ, 0 }; + +xfs_param_t xfs_params = { + /* MIN DFLT MAX */ + .refcache_size = { 0, 128, XFS_REFCACHE_SIZE_MAX }, + .refcache_purge = { 0, 32, XFS_REFCACHE_SIZE_MAX }, + .restrict_chown = { 0, 1, 1 }, + .sgid_inherit = { 0, 0, 1 }, + .symlink_mode = { 0, 0, 1 }, + .panic_mask = { 0, 0, 127 }, + .error_level = { 0, 3, 11 }, + .sync_interval = { HZ, 30*HZ, 60*HZ }, + .stats_clear = { 0, 0, 1 }, +}; /* * Global system credential structure. diff -urN 2.4.21-xfs-old/fs/xfs/linux/xfs_linux.h 2.4.21-xfs-new/fs/xfs/linux/xfs_linux.h --- 2.4.21-xfs-old/fs/xfs/linux/xfs_linux.h Mon Jul 7 16:23:29 2003 +++ 2.4.21-xfs-new/fs/xfs/linux/xfs_linux.h Mon Jul 7 16:23:12 2003 @@ -101,11 +101,15 @@ bh->b_end_io = linvfs_unwritten_done; } -#define restricted_chown xfs_params.restrict_chown -#define irix_sgid_inherit xfs_params.sgid_inherit -#define irix_symlink_mode xfs_params.symlink_mode -#define xfs_panic_mask xfs_params.panic_mask -#define xfs_error_level xfs_params.error_level +#define xfs_refcache_size xfs_params.refcache_size.val +#define xfs_refcache_purge_count xfs_params.refcache_purge.val +#define restricted_chown xfs_params.restrict_chown.val +#define irix_sgid_inherit xfs_params.sgid_inherit.val +#define irix_symlink_mode xfs_params.symlink_mode.val +#define xfs_panic_mask xfs_params.panic_mask.val +#define xfs_error_level xfs_params.error_level.val +#define xfs_syncd_interval xfs_params.sync_interval.val +#define xfs_stats_clear xfs_params.stats_clear.val #define NBPP PAGE_SIZE #define DPPSHFT (PAGE_SHIFT - 9) diff -urN 2.4.21-xfs-old/fs/xfs/linux/xfs_super.c 2.4.21-xfs-new/fs/xfs/linux/xfs_super.c --- 2.4.21-xfs-old/fs/xfs/linux/xfs_super.c Mon Jul 7 16:23:29 2003 +++ 2.4.21-xfs-new/fs/xfs/linux/xfs_super.c Mon Jul 7 16:23:12 2003 @@ -440,7 +440,7 @@ for (;;) { set_current_state(TASK_INTERRUPTIBLE); - schedule_timeout(xfs_params.sync_interval); + schedule_timeout(xfs_syncd_interval); if (vfsp->vfs_flag & VFS_UMOUNT) break; if (vfsp->vfs_flag & VFS_RDONLY) diff -urN 2.4.21-xfs-old/fs/xfs/linux/xfs_sysctl.c 2.4.21-xfs-new/fs/xfs/linux/xfs_sysctl.c --- 2.4.21-xfs-old/fs/xfs/linux/xfs_sysctl.c Mon Jul 7 16:23:29 2003 +++ 2.4.21-xfs-new/fs/xfs/linux/xfs_sysctl.c Mon Jul 7 16:23:12 2003 @@ -36,12 +36,6 @@ #include -STATIC ulong xfs_min[XFS_PARAM] = { \ - 0, 0, 0, 0, 0, 0, 0, HZ, 0 }; -STATIC ulong xfs_max[XFS_PARAM] = { \ - XFS_REFCACHE_SIZE_MAX, XFS_REFCACHE_SIZE_MAX, - 1, 1, 1, 127, 11, HZ * 60, 1 }; - static struct ctl_table_header *xfs_table_header; @@ -65,8 +59,8 @@ if (!ret && write && xfs_refcache_new_size != xfs_refcache_old_size) { xfs_refcache_resize(xfs_refcache_new_size); /* Don't purge more than size of the cache */ - if (xfs_refcache_new_size < xfs_params.refcache_purge) - xfs_params.refcache_purge = xfs_refcache_new_size; + if (xfs_refcache_new_size < xfs_refcache_purge_count) + xfs_refcache_purge_count = xfs_refcache_new_size; } return ret; @@ -92,7 +86,7 @@ vn_active = xfsstats.vn_active; memset(&xfsstats, 0, sizeof(xfsstats)); xfsstats.vn_active = vn_active; - xfs_params.stats_clear = 0; + xfs_stats_clear = 0; } return ret; @@ -100,43 +94,53 @@ #endif /* CONFIG_PROC_FS */ STATIC ctl_table xfs_table[] = { - {XFS_REFCACHE_SIZE, "refcache_size", &xfs_params.refcache_size, + {XFS_REFCACHE_SIZE, "refcache_size", &xfs_params.refcache_size.val, sizeof(ulong), 0644, NULL, &xfs_refcache_resize_proc_handler, - &sysctl_intvec, NULL, &xfs_min[0], &xfs_max[0]}, + &sysctl_intvec, NULL, + &xfs_params.refcache_size.min, &xfs_params.refcache_size.max}, - {XFS_REFCACHE_PURGE, "refcache_purge", &xfs_params.refcache_purge, + /* Note, the max here is different, it is the current refcache size */ + {XFS_REFCACHE_PURGE, "refcache_purge", &xfs_params.refcache_purge.val, sizeof(ulong), 0644, NULL, &proc_doulongvec_minmax, - &sysctl_intvec, NULL, &xfs_min[1], &xfs_params.refcache_size}, + &sysctl_intvec, NULL, + &xfs_params.refcache_purge.min, &xfs_params.refcache_size.val}, - {XFS_RESTRICT_CHOWN, "restrict_chown", &xfs_params.restrict_chown, + {XFS_RESTRICT_CHOWN, "restrict_chown", &xfs_params.restrict_chown.val, sizeof(ulong), 0644, NULL, &proc_doulongvec_minmax, - &sysctl_intvec, NULL, &xfs_min[2], &xfs_max[2]}, + &sysctl_intvec, NULL, + &xfs_params.restrict_chown.min, &xfs_params.restrict_chown.max}, - {XFS_SGID_INHERIT, "irix_sgid_inherit", &xfs_params.sgid_inherit, + {XFS_SGID_INHERIT, "irix_sgid_inherit", &xfs_params.sgid_inherit.val, sizeof(ulong), 0644, NULL, &proc_doulongvec_minmax, - &sysctl_intvec, NULL, &xfs_min[3], &xfs_max[3]}, + &sysctl_intvec, NULL, + &xfs_params.sgid_inherit.min, &xfs_params.sgid_inherit.max}, - {XFS_SYMLINK_MODE, "irix_symlink_mode", &xfs_params.symlink_mode, + {XFS_SYMLINK_MODE, "irix_symlink_mode", &xfs_params.symlink_mode.val, sizeof(ulong), 0644, NULL, &proc_doulongvec_minmax, - &sysctl_intvec, NULL, &xfs_min[4], &xfs_max[4]}, + &sysctl_intvec, NULL, + &xfs_params.symlink_mode.min, &xfs_params.symlink_mode.max}, - {XFS_PANIC_MASK, "panic_mask", &xfs_params.panic_mask, + {XFS_PANIC_MASK, "panic_mask", &xfs_params.panic_mask.val, sizeof(ulong), 0644, NULL, &proc_doulongvec_minmax, - &sysctl_intvec, NULL, &xfs_min[5], &xfs_max[5]}, + &sysctl_intvec, NULL, + &xfs_params.panic_mask.min, &xfs_params.panic_mask.max}, - {XFS_ERRLEVEL, "error_level", &xfs_params.error_level, + {XFS_ERRLEVEL, "error_level", &xfs_params.error_level.val, sizeof(ulong), 0644, NULL, &proc_doulongvec_minmax, - &sysctl_intvec, NULL, &xfs_min[6], &xfs_max[6]}, + &sysctl_intvec, NULL, + &xfs_params.error_level.min, &xfs_params.error_level.max}, - {XFS_SYNC_INTERVAL, "sync_interval", &xfs_params.sync_interval, + {XFS_SYNC_INTERVAL, "sync_interval", &xfs_params.sync_interval.val, sizeof(ulong), 0644, NULL, &proc_doulongvec_minmax, - &sysctl_intvec, NULL, &xfs_min[7], &xfs_max[7]}, + &sysctl_intvec, NULL, + &xfs_params.sync_interval.min, &xfs_params.sync_interval.max}, /* please keep this the last entry */ #ifdef CONFIG_PROC_FS - {XFS_STATS_CLEAR, "stats_clear", &xfs_params.stats_clear, + {XFS_STATS_CLEAR, "stats_clear", &xfs_params.stats_clear.val, sizeof(ulong), 0644, NULL, &xfs_stats_clear_proc_handler, - &sysctl_intvec, NULL, &xfs_min[8], &xfs_max[8]}, + &sysctl_intvec, NULL, + &xfs_params.stats_clear.min, &xfs_params.stats_clear.max}, #endif /* CONFIG_PROC_FS */ {0} diff -urN 2.4.21-xfs-old/fs/xfs/linux/xfs_sysctl.h 2.4.21-xfs-new/fs/xfs/linux/xfs_sysctl.h --- 2.4.21-xfs-old/fs/xfs/linux/xfs_sysctl.h Mon Jul 7 16:23:29 2003 +++ 2.4.21-xfs-new/fs/xfs/linux/xfs_sysctl.h Mon Jul 7 16:23:12 2003 @@ -39,19 +39,24 @@ * Tunable xfs parameters */ -#define XFS_PARAM (sizeof(struct xfs_param) / sizeof(ulong)) +typedef struct xfs_sysctl_val { + ulong min; + ulong val; + ulong max; +} xfs_sysctl_val_t; typedef struct xfs_param { - ulong refcache_size; /* Size of NFS reference cache. */ - ulong refcache_purge; /* # of entries to purge each time. */ - ulong restrict_chown; /* Root/non-root can give away files. */ - ulong sgid_inherit; /* Inherit ISGID bit if process' GID is */ - /* not a member of the parent dir GID. */ - ulong symlink_mode; /* Symlink creat mode affected by umask. */ - ulong panic_mask; /* bitmask to specify panics on errors. */ - ulong error_level; /* Degree of reporting for internal probs*/ - ulong sync_interval; /* time between sync calls */ - ulong stats_clear; /* Reset all XFS statistics to zero. */ + xfs_sysctl_val_t refcache_size; /* Size of NFS reference cache. */ + xfs_sysctl_val_t refcache_purge;/* # of entries to purge each time. */ + xfs_sysctl_val_t restrict_chown;/* Root/non-root can give away files.*/ + xfs_sysctl_val_t sgid_inherit; /* Inherit ISGID bit if process' GID + * is not a member of the parent dir + * GID */ + xfs_sysctl_val_t symlink_mode; /* Link creat mode affected by umask */ + xfs_sysctl_val_t panic_mask; /* bitmask to cause panic on errors. */ + xfs_sysctl_val_t error_level; /* Degree of reporting for problems */ + xfs_sysctl_val_t sync_interval; /* time between sync calls */ + xfs_sysctl_val_t stats_clear; /* Reset all XFS statistics to zero. */ } xfs_param_t; /* diff -urN 2.4.21-xfs-old/fs/xfs/linux/xfs_version.h 2.4.21-xfs-new/fs/xfs/linux/xfs_version.h --- 2.4.21-xfs-old/fs/xfs/linux/xfs_version.h Mon Jul 7 16:23:29 2003 +++ 2.4.21-xfs-new/fs/xfs/linux/xfs_version.h Mon Jul 7 16:23:12 2003 @@ -39,6 +39,6 @@ #ifndef __XFS_VERSION_H__ #define __XFS_VERSION_H__ -#define XFS_VERSION_STRING "SGI XFS snapshot-2.4.21-2003-06-23_01:45_UTC" +#define XFS_VERSION_STRING "SGI XFS snapshot-xfs-2.4.21-2003-07-07_02:01_UTC" #endif /* __XFS_VERSION_H__ */ diff -urN 2.4.21-xfs-old/fs/xfs/pagebuf/page_buf.c 2.4.21-xfs-new/fs/xfs/pagebuf/page_buf.c --- 2.4.21-xfs-old/fs/xfs/pagebuf/page_buf.c Mon Jul 7 16:23:29 2003 +++ 2.4.21-xfs-new/fs/xfs/pagebuf/page_buf.c Mon Jul 7 16:23:12 2003 @@ -121,7 +121,7 @@ int j; unsigned long flags; - if (!pb_params.p_un.debug) return; + if (!pb_params.debug.val) return; if (ra == NULL) ra = (void *)__builtin_return_address(0); @@ -177,10 +177,13 @@ * /proc/sys/vm/pagebuf */ -unsigned long pagebuf_min[P_PARAM] = { HZ/2, 1*HZ, 0, 0 }; -unsigned long pagebuf_max[P_PARAM] = { HZ*30, HZ*300, 1, 1 }; - -pagebuf_param_t pb_params = {{ HZ, 15 * HZ, 0, 0 }}; +pagebuf_param_t pb_params = { + /* MIN DFLT MAX */ + .flush_interval = { HZ/2, HZ, 30*HZ }, + .age_buffer = { 1*HZ, 15*HZ, 300*HZ }, + .stats_clear = { 0, 0, 1 }, + .debug = { 0, 0, 1 }, +}; /* * Pagebuf statistics variables @@ -1885,7 +1888,7 @@ } list_add_tail(&pb->pb_list, &pbd_delwrite_queue); - pb->pb_flushtime = jiffies + pb_params.p_un.age_buffer; + pb->pb_flushtime = jiffies + pb_params.age_buffer.val; spin_unlock(&pbd_delwrite_lock); if (unlock && (pb->pb_flags & _PBF_LOCKABLE)) { @@ -2040,7 +2043,7 @@ do { if (pbd_active == 1) { mod_timer(&pb_daemon_timer, - jiffies + pb_params.p_un.flush_interval); + jiffies + pb_params.flush_interval.val); interruptible_sleep_on(&pbd_waitq); } @@ -2268,7 +2271,7 @@ if (!ret && write && *valp) { printk("XFS Clearing pbstats\n"); memset(&pbstats, 0, sizeof(pbstats)); - pb_params.p_un.stats_clear = 0; + pb_params.stats_clear.val = 0; } return ret; @@ -2277,22 +2280,26 @@ STATIC struct ctl_table_header *pagebuf_table_header; STATIC ctl_table pagebuf_table[] = { - {PB_FLUSH_INT, "flush_int", &pb_params.data[0], + {PB_FLUSH_INT, "flush_int", &pb_params.flush_interval.val, sizeof(ulong), 0644, NULL, &proc_doulongvec_ms_jiffies_minmax, - &sysctl_intvec, NULL, &pagebuf_min[0], &pagebuf_max[0]}, + &sysctl_intvec, NULL, + &pb_params.flush_interval.min, &pb_params.flush_interval.max}, - {PB_FLUSH_AGE, "flush_age", &pb_params.data[1], + {PB_FLUSH_AGE, "flush_age", &pb_params.age_buffer.val, sizeof(ulong), 0644, NULL, &proc_doulongvec_ms_jiffies_minmax, - &sysctl_intvec, NULL, &pagebuf_min[1], &pagebuf_max[1]}, + &sysctl_intvec, NULL, + &pb_params.age_buffer.min, &pb_params.age_buffer.max}, - {PB_STATS_CLEAR, "stats_clear", &pb_params.data[2], + {PB_STATS_CLEAR, "stats_clear", &pb_params.stats_clear.val, sizeof(ulong), 0644, NULL, &pb_stats_clear_handler, - &sysctl_intvec, NULL, &pagebuf_min[2], &pagebuf_max[2]}, + &sysctl_intvec, NULL, + &pb_params.stats_clear.min, &pb_params.stats_clear.max}, #ifdef PAGEBUF_TRACE - {PB_DEBUG, "debug", &pb_params.data[3], + {PB_DEBUG, "debug", &pb_params.debug.val, sizeof(ulong), 0644, NULL, &proc_doulongvec_minmax, - &sysctl_intvec, NULL, &pagebuf_min[3], &pagebuf_max[3]}, + &sysctl_intvec, NULL, + &pb_params.debug.min, &pb_params.debug.max}, #endif {0} }; diff -urN 2.4.21-xfs-old/fs/xfs/pagebuf/page_buf_internal.h 2.4.21-xfs-new/fs/xfs/pagebuf/page_buf_internal.h --- 2.4.21-xfs-old/fs/xfs/pagebuf/page_buf_internal.h Mon Jul 7 16:23:29 2003 +++ 2.4.21-xfs-new/fs/xfs/pagebuf/page_buf_internal.h Mon Jul 7 16:23:12 2003 @@ -85,18 +85,19 @@ * Tunable pagebuf parameters */ -#define P_PARAM 4 +typedef struct pb_sysctl_val { + ulong min; + ulong val; + ulong max; +} pb_sysctl_val_t; -typedef union pagebuf_param { - struct { - ulong flush_interval; /* interval between runs of the +typedef struct pagebuf_param { + pb_sysctl_val_t flush_interval; /* interval between runs of the * delwri flush daemon. */ - ulong age_buffer; /* time for buffer to age before + pb_sysctl_val_t age_buffer; /* time for buffer to age before * we flush it. */ - ulong stats_clear; /* clear the pagebuf stats */ - ulong debug; /* debug tracing on or off */ - } p_un; - ulong data[P_PARAM]; + pb_sysctl_val_t stats_clear; /* clear the pagebuf stats */ + pb_sysctl_val_t debug; /* debug tracing on or off */ } pagebuf_param_t; enum { diff -urN 2.4.21-xfs-old/fs/xfs/xfs_rw.c 2.4.21-xfs-new/fs/xfs/xfs_rw.c --- 2.4.21-xfs-old/fs/xfs/xfs_rw.c Mon Jul 7 16:23:30 2003 +++ 2.4.21-xfs-new/fs/xfs/xfs_rw.c Mon Jul 7 16:23:13 2003 @@ -408,7 +408,6 @@ spinlock_t xfs_refcache_lock = SPIN_LOCK_UNLOCKED; xfs_inode_t **xfs_refcache; -int xfs_refcache_size; int xfs_refcache_index; int xfs_refcache_busy; int xfs_refcache_count; @@ -635,15 +634,13 @@ xfs_inode_t *ip; int iplist_index; xfs_inode_t **iplist; - int purge_count; if ((xfs_refcache == NULL) || (xfs_refcache_count == 0)) { return; } iplist_index = 0; - purge_count = xfs_params.refcache_purge; - iplist = (xfs_inode_t **)kmem_zalloc(purge_count * + iplist = (xfs_inode_t **)kmem_zalloc(xfs_refcache_purge_count * sizeof(xfs_inode_t *), KM_SLEEP); spin_lock(&xfs_refcache_lock); @@ -656,7 +653,7 @@ * forward as we go so that we are sure to eventually clear * out the entire cache when the system goes idle. */ - for (i = 0; i < purge_count; i++) { + for (i = 0; i < xfs_refcache_purge_count; i++) { ip = xfs_refcache[xfs_refcache_index]; if (ip != NULL) { xfs_refcache[xfs_refcache_index] = NULL; @@ -682,7 +679,7 @@ VN_RELE(XFS_ITOV(iplist[i])); } - kmem_free(iplist, purge_count * + kmem_free(iplist, xfs_refcache_purge_count * sizeof(xfs_inode_t *)); } diff -urN 2.4.21-xfs-old/fs/xfs/xfs_vfsops.c 2.4.21-xfs-new/fs/xfs/xfs_vfsops.c --- 2.4.21-xfs-old/fs/xfs/xfs_vfsops.c Mon Jul 7 16:23:30 2003 +++ 2.4.21-xfs-new/fs/xfs/xfs_vfsops.c Mon Jul 7 16:23:13 2003 @@ -96,10 +96,6 @@ #endif /* DEBUG */ #ifdef XFS_DABUF_DEBUG extern lock_t xfs_dabuf_global_lock; -#endif - extern int xfs_refcache_size; - -#ifdef XFS_DABUF_DEBUG spinlock_init(&xfs_dabuf_global_lock, "xfsda"); #endif @@ -177,8 +173,6 @@ xfs_init_procfs(); xfs_sysctl_register(); - xfs_refcache_size = xfs_params.refcache_size; - /* * The inode hash table is created on a per mounted * file system bases. diff -urN 2.4.21-xfs-old/kdb/ChangeLog 2.4.21-xfs-new/kdb/ChangeLog --- 2.4.21-xfs-old/kdb/ChangeLog Mon Jul 7 16:23:30 2003 +++ 2.4.21-xfs-new/kdb/ChangeLog Mon Jul 7 16:23:13 2003 @@ -1,3 +1,14 @@ +2003-07-07 Keith Owens + + * 2.4.21-ia64-030702 patches common code that affects kdb. Workaround + this nuisance. + * kdb v4.3-2.4.21-common-4. + +2003-06-24 Keith Owens + + * Add task and sigset commands. Mark Goodwin, SGI. + * kdb v4.3-2.4.21-common-3. + 2003-06-23 Keith Owens * Sync with XFS 2.4.21 tree. diff -urN 2.4.21-xfs-old/kdb/modules/Makefile 2.4.21-xfs-new/kdb/modules/Makefile --- 2.4.21-xfs-old/kdb/modules/Makefile Mon Jul 7 16:23:30 2003 +++ 2.4.21-xfs-new/kdb/modules/Makefile Mon Jul 7 16:23:13 2003 @@ -31,7 +31,7 @@ # O_TARGET := vmlinux-obj.o -obj-$(CONFIG_KDB_MODULES) += kdbm_vm.o kdbm_pg.o +obj-$(CONFIG_KDB_MODULES) += kdbm_vm.o kdbm_pg.o kdbm_task.o CFLAGS_kdbm_vm.o += -I $(TOPDIR)/drivers/scsi EXTRA_CFLAGS += -I $(TOPDIR)/arch/$(ARCH)/kdb diff -urN 2.4.21-xfs-old/kdb/modules/kdbm_task.c 2.4.21-xfs-new/kdb/modules/kdbm_task.c --- 2.4.21-xfs-old/kdb/modules/kdbm_task.c Thu Jan 1 10:00:00 1970 +++ 2.4.21-xfs-new/kdb/modules/kdbm_task.c Mon Jul 7 16:23:13 2003 @@ -0,0 +1,209 @@ +/* + * Copyright (c) 2003 Silicon Graphics, Inc. All Rights Reserved. + * + * This program is free software; you can redistribute it and/or modify it + * under the terms of version 2 of the GNU General Public License + * as published by the Free Software Foundation. + * + * This program is distributed in the hope that it would be useful, but + * WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. + * + * Further, this software is distributed without any warranty that it is + * free of the rightful claim of any third person regarding infringement + * or the like. Any license provided herein, whether implied or + * otherwise, applies only to this software file. Patent licenses, if + * any, provided herein do not apply to combinations of this program with + * other software, or any other product whatsoever. + * + * You should have received a copy of the GNU General Public + * License along with this program; if not, write the Free Software + * Foundation, Inc., 59 Temple Place - Suite 330, Boston MA 02111-1307, USA. + * + * Contact information: Silicon Graphics, Inc., 1600 Amphitheatre Pkwy, + * Mountain View, CA 94043, or: + * + * http://www.sgi.com + * + * For further information regarding this notice, see: + * + * http://oss.sgi.com/projects/GenInfo/NoticeExplan + */ + +#include +#include +#include +#include +#include +#include +#include +#include +#include + +MODULE_AUTHOR("SGI"); +MODULE_DESCRIPTION("Debug struct task and sigset information"); +MODULE_LICENSE("GPL"); + +#ifdef __KDB_HAVE_NEW_SCHEDULER +static char * +kdb_cpus_allowed_string(struct task_struct *tp) +{ +#ifndef CPUMASK_WORDCOUNT + static char maskbuf[BITS_PER_LONG/4+8]; + sprintf(maskbuf, "0x%0lx", tp->cpus_allowed); +#else + int i, j; + static char maskbuf[CPUMASK_WORDCOUNT * BITS_PER_LONG / 4 + 8]; + + strcpy(maskbuf, "0x"); + for (j=2, i=CPUMASK_WORDCOUNT-1; i >= 0; i--) { + j += sprintf(maskbuf + j, "%0lx", tp->cpus_allowed[i]); + } +#endif /* CPUMASK_WORDCOUNT */ + + return maskbuf; +} +#endif /* __KDB_HAVE_NEW_SCHEDULER */ + +static int +kdbm_task(int argc, const char **argv, const char **envp, struct pt_regs *regs) +{ + unsigned long addr; + long offset=0; + int nextarg; + int e = 0; + struct task_struct *tp = NULL; + + if (argc != 1) + return KDB_ARGCOUNT; + + nextarg = 1; + if ((e = kdbgetaddrarg(argc, argv, &nextarg, &addr, &offset, NULL, regs)) != 0) + return(e); + + if (!(tp = kmalloc(sizeof(*tp), GFP_ATOMIC))) { + kdb_printf("%s: cannot kmalloc tp\n", __FUNCTION__); + goto out; + } + if ((e = kdb_getarea(*tp, addr))) { + kdb_printf("%s: invalid task address\n", __FUNCTION__); + goto out; + } + + kdb_printf( + "struct task at 0x%p, pid=%d flags=0x%lx state=%ld comm=\"%s\"\n", + tp, tp->pid, tp->flags, tp->state, tp->comm); + + kdb_printf(" cpu=%d policy=%lu ", kdb_process_cpu(tp), tp->policy); +#ifdef __KDB_HAVE_NEW_SCHEDULER + kdb_printf( + "prio=%d static_prio=%d cpus_allowed=%s", + tp->prio, tp->static_prio, kdb_cpus_allowed_string(tp)); +#else + kdb_printf( + "cpus_runnable=%lx cpus_allowed=%lx", + tp->cpus_runnable, tp->cpus_allowed); +#endif + kdb_printf(" &thread=0x%p\n", &tp->thread); + + kdb_printf(" need_resched=%ld ", tp->need_resched); +#ifdef __KDB_HAVE_NEW_SCHEDULER + kdb_printf( + "sleep_timestamp=%lu time_slice=%u", + tp->sleep_timestamp, tp->time_slice); +#else + kdb_printf( + "counter=%ld nice=%ld", + tp->counter, tp->nice); +#endif + kdb_printf(" lock_depth=%d\n", tp->lock_depth); + + kdb_printf( + " fs=0x%p files=0x%p mm=0x%p nr_local_pages=%u\n", + tp->fs, tp->files, tp->mm, tp->nr_local_pages); + + kdb_printf( + " uid=%d euid=%d suid=%d fsuid=%d gid=%d egid=%d sgid=%d fsgid=%d\n", + tp->uid, tp->euid, tp->suid, tp->fsuid, tp->gid, tp->egid, tp->sgid, tp->fsgid); + + kdb_printf( + " user=0x%p locks=%d semundo=0x%p semsleeping=0x%p\n", + tp->user, tp->locks, tp->semundo, tp->semsleeping); + + kdb_printf( + " sig=0x%p &blocked=0x%p &sigpending=0x%p\n", + tp->sig, &tp->blocked, &tp->sigpending); + + kdb_printf( + " times.utime=%ld times_stime=%ld times_cutime=%ld times_cstime=%ld\n", + tp->times.tms_utime, tp->times.tms_stime, tp->times.tms_cutime, + tp->times.tms_cstime); + +out: + if (tp) + kfree(tp); + return e; +} + +static int +kdbm_sigset(int argc, const char **argv, const char **envp, struct pt_regs *regs) +{ + sigset_t *sp = NULL; + unsigned long addr; + long offset=0; + int nextarg; + int e = 0; + int i; + char fmt[32]; + + if (argc != 1) + return KDB_ARGCOUNT; + +#ifndef _NSIG_WORDS + kdb_printf("unavailable on this platform, _NSIG_WORDS not defined.\n"); +#else + nextarg = 1; + if ((e = kdbgetaddrarg(argc, argv, &nextarg, &addr, &offset, NULL, regs)) != 0) + return(e); + + if (!(sp = kmalloc(sizeof(*sp), GFP_ATOMIC))) { + kdb_printf("%s: cannot kmalloc sp\n", __FUNCTION__); + goto out; + } + if ((e = kdb_getarea(*sp, addr))) { + kdb_printf("%s: invalid sigset address\n", __FUNCTION__); + goto out; + } + + sprintf(fmt, "[%%d]=0x%%0%dlx ", (int)sizeof(sp->sig[0])*2); + kdb_printf("sigset at 0x%p : ", sp); + for (i=_NSIG_WORDS-1; i >= 0; i--) { + if (i == 0 || sp->sig[i]) { + kdb_printf(fmt, i, sp->sig[i]); + } + } + kdb_printf("\n"); +#endif /* _NSIG_WORDS */ + +out: + if (sp) + kfree(sp); + return e; +} + +static int __init kdbm_task_init(void) +{ + kdb_register("task", kdbm_task, "", "Display task_struct", 0); + kdb_register("sigset", kdbm_sigset, "", "Display sigset_t", 0); + + return 0; +} + +static void __exit kdbm_task_exit(void) +{ + kdb_unregister("task"); + kdb_unregister("sigset"); +} + +kdb_module_init(kdbm_task_init) +kdb_module_exit(kdbm_task_exit) diff -urN 2.4.21-xfs-old/kernel/sysctl.c 2.4.21-xfs-new/kernel/sysctl.c --- 2.4.21-xfs-old/kernel/sysctl.c Mon Jul 7 16:23:30 2003 +++ 2.4.21-xfs-new/kernel/sysctl.c Mon Jul 7 16:23:13 2003 @@ -28,11 +28,11 @@ #include #include #include -#include -#include #ifdef CONFIG_KDB #include #endif /* CONFIG_KDB */ +#include +#include #include From owner-linux-xfs@oss.sgi.com Sun Jul 6 23:40:07 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 06 Jul 2003 23:40:09 -0700 (PDT) Received: from tolkor.sgi.com ([198.149.18.6]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h676dj2x004307 for ; Sun, 6 Jul 2003 23:40:06 -0700 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.54.149]) by tolkor.sgi.com (8.12.9/8.12.2/linux-outbound_gateway-1.2) with ESMTP id h676vZmO008081 for ; Mon, 7 Jul 2003 01:57:36 -0500 Received: from snort.melbourne.sgi.com (localhost [127.0.0.1]) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id h676cMJA2669049 for ; Mon, 7 Jul 2003 16:38:22 +1000 (EST) Received: (from nathans@localhost) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id h676cLV32676902 for linux-xfs@oss.sgi.com; Mon, 7 Jul 2003 16:38:21 +1000 (EST) Date: Mon, 7 Jul 2003 16:38:21 +1000 (EST) From: Nathan Scott Message-Id: <200307070638.h676cLV32676902@snort.melbourne.sgi.com> To: linux-xfs@oss.sgi.com Subject: TAKE - xfstests updates X-archive-position: 4586 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: nathans@snort.melbourne.sgi.com Precedence: bulk X-list: linux-xfs xfstests updates - rework build to be like other xfs packages, revive some old fs test tools and reenable xfs extensions, move ltp code into a separate subdir to help keeping in sync with real ltp project (hopefully). Date: Sun Jul 6 23:36:46 PDT 2003 Workarea: snort.melbourne.sgi.com:/home/nathans/2.4.x-xfs The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: xfs-cmds:slinx:152534a cmd/xfstests/lib/Makefile - 1.1 cmd/xfstests/ltp/iogen.c - 1.1 cmd/xfstests/ltp/growfiles.c - 1.1 cmd/xfstests/ltp/fsx.c - 1.1 cmd/xfstests/ltp/doio.h - 1.1 cmd/xfstests/ltp/doio.c - 1.1 cmd/xfstests/ltp/Makefile - 1.1 cmd/xfstests/lib/write_log.c - 1.1 cmd/xfstests/lib/tlibio.c - 1.1 cmd/xfstests/lib/string_to_tokens.c - 1.1 cmd/xfstests/lib/str_to_bytes.c - 1.1 cmd/xfstests/lib/random_range.c - 1.1 cmd/xfstests/lib/pattern.c - 1.1 cmd/xfstests/include/buildmacros - 1.1 cmd/xfstests/lib/open_flags.c - 1.1 cmd/xfstests/include/dataascii.h - 1.1 cmd/xfstests/include/databin.h - 1.1 cmd/xfstests/include/file_lock.h - 1.1 cmd/xfstests/include/forker.h - 1.1 cmd/xfstests/include/open_flags.h - 1.1 cmd/xfstests/include/pattern.h - 1.1 cmd/xfstests/include/str_to_bytes.h - 1.1 cmd/xfstests/include/test.h - 1.1 cmd/xfstests/include/tlibio.h - 1.1 cmd/xfstests/include/usctest.h - 1.1 cmd/xfstests/lib/forker.c - 1.1 cmd/xfstests/lib/dataascii.c - 1.1 cmd/xfstests/lib/databin.c - 1.1 cmd/xfstests/lib/datapid.c - 1.1 cmd/xfstests/lib/file_lock.c - 1.1 cmd/xfstests/013 - 1.8 cmd/xfstests/022 - 1.8 cmd/xfstests/049 - 1.10 cmd/xfstests/configure.in - 1.14 cmd/xfstests/common.config - 1.35 cmd/xfstests/Makefile - 1.8 cmd/xfstests/common.dump - 1.43 cmd/xfstests/022.out - 1.6 cmd/xfstests/soak - 1.7 cmd/xfstests/group - 1.30 cmd/xfstests/src/Makefile - 1.15 xfstests/src/random.c 1.3 renamed to xfstests/lib/random.c 1.1 xfstests/src/fsstress.c 1.8 renamed to xfstests/ltp/fsstress.c 1.1 cmd/xfstests/include/buildrules - 1.5 cmd/xfstests/include/Makefile - 1.5 cmd/xfstests/include/builddefs.in - 1.9 cmd/xfstests/tools/srcdiff - 1.25 cmd/xfstests/065 - 1.12 cmd/xfstests/067 - 1.9 cmd/xfstests/068 - 1.6 cmd/xfstests/070 - 1.5 cmd/xfstests/m4/Makefile - 1.2 From owner-linux-xfs@oss.sgi.com Mon Jul 7 00:23:37 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 07 Jul 2003 00:23:58 -0700 (PDT) Received: from iris.acsalaska.net (iris.slb.nwc.acsalaska.net [209.112.155.43]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h677NZ2x012597 for ; Mon, 7 Jul 2003 00:23:36 -0700 Received: from erbenson.alaska.net (139-pm3.nwc.alaska.net [209.112.138.139]) by iris.acsalaska.net (8.12.9/8.12.9) with ESMTP id h677NXMA040281 for ; Sun, 6 Jul 2003 23:23:33 -0800 (AKDT) (envelope-from erbenson@alaska.net) Received: from plato.local.lan (plato.local.lan [192.168.0.4]) by erbenson.alaska.net (Postfix) with ESMTP id 9C1503A0C for ; Sun, 6 Jul 2003 23:23:31 -0800 (AKDT) Received: by plato.local.lan (Postfix, from userid 1000) id 16D9E40FF44; Sun, 6 Jul 2003 23:23:32 -0800 (AKDT) Date: Sun, 6 Jul 2003 23:23:32 -0800 From: Ethan Benson To: linux-xfs@oss.sgi.com Subject: Re: Announce: XFS split patches for 2.4.21 Message-ID: <20030707072332.GZ930@plato.local.lan> Mail-Followup-To: linux-xfs@oss.sgi.com References: <3489.1057544270@kao2.melbourne.sgi.com> <20030707023702.GC1262@leathercollection.ph> <1057546691.8507.3.camel@laptop.americas.sgi.com> <20030707054151.GD5680@leathercollection.ph> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="vHrcnSuaBi45WmF/" Content-Disposition: inline In-Reply-To: <20030707054151.GD5680@leathercollection.ph> User-Agent: Mutt/1.3.28i X-OS: Debian GNU X-gpg-fingerprint: E3E4 D0BC 31BC F7BB C1DD C3D6 24AC 7B1A 2C44 7AFC X-gpg-key: http://www.alaska.net/~erbenson/gpg/key.asc Mail-Copies-To: nobody X-No-CC: I subscribe to this list; do not CC me on replies. X-ACS-Spam-Status: no X-Scanned-By: MIMEDefang 2.31 (www . roaringpenguin . com / mimedefang) X-archive-position: 4587 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: erbenson@alaska.net Precedence: bulk X-list: linux-xfs --vHrcnSuaBi45WmF/ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Jul 07, 2003 at 01:41:51PM +0800, Federico Sevilla III wrote: > On Sun, Jul 06, 2003 at 09:58:10PM -0500, Steve Lord wrote: > > The globals stuff has been reworked again - to avoid shooting > > ourselves in the foot like this in the future. Not a lot of other > > differences I think. >=20 > Please pardon my confusion. >=20 > Does this mean that the only major difference between the respun split > patches and the initial split patches plus the xfs_globals.c patch > posted by Ethan Benson on 2003-06-28 09:23 UTC [1] is that you cleaned > things up to prevent you from comitting the same mistake next time? pretty much, there doesn't seem to be any functional difference between my version of the patch (the first fix commited by sandeen) and the current one which is simply a more C99 correct initialization. > Or is the combination of the original split patches and the > xfs_globals.c patch not enough, so people like me who use that > combination should schedule a kernel upgrade using the respun patches > ASAP? i don't recall seeing any other commits which looked very interesting. > Thank you very much for helping me decide wether an upgrade will be > necessary or not. >=20 > --> Jijo >=20 > [1] http://marc.free.net.ph/message/20030628.092344.7eff097d.html >=20 > --=20 > Federico Sevilla III : http://jijo.free.net.ph : When we speak of f= ree > Network Administrator : The Leather Collection, Inc. : software we refer = to > GnuPG Key ID : 0x93B746BE : freedom, not price. >=20 --=20 Ethan Benson http://www.alaska.net/~erbenson/ --vHrcnSuaBi45WmF/ Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iEYEARECAAYFAj8JH/MACgkQJKx7GixEevzFDgCgkIZKoUgSmd4UaM7ZIL/U9pMD OckAnAnGYPkAlYSN+pKO6QrDvNnMOtf+ =KWPp -----END PGP SIGNATURE----- --vHrcnSuaBi45WmF/-- From owner-linux-xfs@oss.sgi.com Mon Jul 7 02:30:45 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 07 Jul 2003 02:31:15 -0700 (PDT) Received: from hermod.slb.nwc.acsalaska.net (hermod.slb.nwc.acsalaska.net [209.112.155.45]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h679Uh2x021185 for ; Mon, 7 Jul 2003 02:30:45 -0700 Received: from erbenson.alaska.net (139-pm3.nwc.alaska.net [209.112.138.139]) by hermod.slb.nwc.acsalaska.net (8.12.9/8.12.9) with ESMTP id h676p7F2055138 for ; Sun, 6 Jul 2003 22:51:08 -0800 (AKDT) (envelope-from erbenson@alaska.net) Received: from plato.local.lan (plato.local.lan [192.168.0.4]) by erbenson.alaska.net (Postfix) with ESMTP id 8A3FA3A0C for ; Sun, 6 Jul 2003 22:51:06 -0800 (AKDT) Received: by plato.local.lan (Postfix, from userid 1000) id 9C05B40FF44; Sun, 6 Jul 2003 22:51:06 -0800 (AKDT) Date: Sun, 6 Jul 2003 22:51:06 -0800 From: Ethan Benson To: linux-xfs@oss.sgi.com Subject: Re: [bug report]: chown(2) implementation in xfs is broken Message-ID: <20030707065106.GY930@plato.local.lan> Mail-Followup-To: linux-xfs@oss.sgi.com References: <7kadbrchcp.fsf@greenplant.dot> <3F08C005.3070706@linux-sxs.org> <20030707053311.GX930@plato.local.lan> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="yV94raM4eJLN8srE" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.3.28i X-OS: Debian GNU X-gpg-fingerprint: E3E4 D0BC 31BC F7BB C1DD C3D6 24AC 7B1A 2C44 7AFC X-gpg-key: http://www.alaska.net/~erbenson/gpg/key.asc Mail-Copies-To: nobody X-No-CC: I subscribe to this list; do not CC me on replies. X-ACS-Spam-Status: no X-Scanned-By: MIMEDefang 2.34 X-archive-position: 4588 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: erbenson@alaska.net Precedence: bulk X-list: linux-xfs --yV94raM4eJLN8srE Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Jul 07, 2003 at 01:59:00AM -0400, Robert Brockway wrote: > On Sun, 6 Jul 2003, Ethan Benson wrote: >=20 > > my previous mail i missed that you were doing this as non-root. as >=20 > I probably should have been more explicit about that. your example doesn't really does not demonstrate any security hole anyway since you owned the file you could just as well run chmod 555 testfile and then executed it. even with irix behavior you cannot chown a file you don't already own in the first place. > I'm actually surprised that xfs allows the liberal behaviour of > restrict_chown=3D0 at all (as a default or not). the linux kernel has the same ability, you could just as easily grant all processes CAP_CHOWN. > The potential for abuse is significant. It basically nullifies any use of > quotas since it allows any user to force any other user over-quota at any > time. This could result in mail bounces and all sorts of mischief. typically its not allowed when quotas are in use, im not sure whether the irix behavior keeps to that or not. > Is the option there for compatability with Irix, and if so, why does Irix > allow it? keeping to old style unix tradition i suppose. --=20 Ethan Benson http://www.alaska.net/~erbenson/ --yV94raM4eJLN8srE Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iEYEARECAAYFAj8JGFoACgkQJKx7GixEevxU5ACfVYscBi9V2C+odFhMgByruQ0o v9kAniTau/SxnJX2CcGA4V7S+O4EOW5Q =oeLL -----END PGP SIGNATURE----- --yV94raM4eJLN8srE-- From owner-linux-xfs@oss.sgi.com Mon Jul 7 06:43:13 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 07 Jul 2003 06:43:31 -0700 (PDT) Received: from web10008.mail.yahoo.com (web10008.mail.yahoo.com [216.136.130.44]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h67DhD2x027958 for ; Mon, 7 Jul 2003 06:43:13 -0700 Message-ID: <20030707134313.60106.qmail@web10008.mail.yahoo.com> Received: from [165.213.1.1] by web10008.mail.yahoo.com via HTTP; Mon, 07 Jul 2003 22:43:13 JST Date: Mon, 7 Jul 2003 22:43:13 +0900 (JST) From: =?euc-kr?q?jin=20hee=20park?= Subject: question about xfs_trans_dup function in xfs code To: linux-xfs@oss.sgi.com MIME-Version: 1.0 Content-Type: text/plain; charset=euc-kr Content-Transfer-Encoding: 8bit X-archive-position: 4589 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: jinny84@yahoo.co.kr Precedence: bulk X-list: linux-xfs Hello, I would like to ask about xfs_trans_dup function in XFS code. Code comment says, "This is called to create a new transaction which will share the permanent log reservation of the given transaction." but its explanation is insufficient for me. when, where can i use this function? what is the role of xfs_trans_dup function? please, explain easily and concretly. In addition, Is is possible that multiple transactions in XFS code run like 1 transaction idea(all or nothing)? If possible, give me the way. thank you. - JinHee _____________________________________________________________________ ¿¹»Û ÆíÁöÁö¿¡ ¸ÞÀÏÀ» º¸³»¼¼¿ä - ¾ßÈÄ! ¸ÞÀÏ http://mail.yahoo.co.kr ½ÅÂ÷,Áß°íÂ÷,Á÷°Å·¡ ¸Å¹°ÀÌ ÇÑÀÚ¸®¿¡ - ¾ßÈÄ! ÀÚµ¿Â÷ http://autos.yahoo.co.kr/autos/ From owner-linux-xfs@oss.sgi.com Mon Jul 7 07:14:25 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 07 Jul 2003 07:14:38 -0700 (PDT) Received: from zok.sgi.com (zok.SGI.COM [204.94.215.101]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h67EEO2x029384 for ; Mon, 7 Jul 2003 07:14:25 -0700 Received: from flecktone.americas.sgi.com (flecktone.americas.sgi.com [192.48.203.135]) by zok.sgi.com (8.12.9/8.12.2/linux-outbound_gateway-1.2) with ESMTP id h67EEJiY002173 for ; Mon, 7 Jul 2003 07:14:19 -0700 Received: from poppy-e236.americas.sgi.com (poppy-e236.americas.sgi.com [128.162.236.207]) by flecktone.americas.sgi.com (8.12.9/8.12.9/generic_config-1.2) with ESMTP id h67EEHqX8094728; Mon, 7 Jul 2003 09:14:18 -0500 (CDT) Received: from stout.americas.sgi.com (stout.americas.sgi.com [128.162.232.50]) by poppy-e236.americas.sgi.com (8.12.9/SGI-server-1.8) with ESMTP id h67EEBYk14015005; Mon, 7 Jul 2003 09:14:17 -0500 (CDT) Subject: Re: [bug report]: chown(2) implementation in xfs is broken From: Eric Sandeen To: Robert Brockway Cc: linux-xfs@oss.sgi.com In-Reply-To: References: <7kadbrchcp.fsf@greenplant.dot> <3F08C005.3070706@linux-sxs.org> <20030707053311.GX930@plato.local.lan> Content-Type: text/plain Organization: Message-Id: <1057587250.17344.4.camel@stout.americas.sgi.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 (1.2.2-5) Date: 07 Jul 2003 09:14:11 -0500 Content-Transfer-Encoding: 7bit X-archive-position: 4590 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: sandeen@sgi.com Precedence: bulk X-list: linux-xfs On Mon, 2003-07-07 at 00:59, Robert Brockway wrote: > Is the option there for compatability with Irix, and if so, why does Irix > allow it? It is there for Irix compatibility, as are a few of the other sysctls. I don't know the details of why it is an option on Irix. You're right that it can be abused... but the (correct) default is secure, and only root can change it. I suppose we could be clever about it and make a CONFIG_PURE_LINUX_XFS_BEHAVIORS config option, and hardcode it at at compile time. But I think that's getting pretty close to feature-itis. :) -Eric -- Eric Sandeen XFS for Linux http://oss.sgi.com/projects/xfs sandeen@sgi.com SGI, Inc. 651-683-3102 From owner-linux-xfs@oss.sgi.com Mon Jul 7 08:41:06 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 07 Jul 2003 08:41:28 -0700 (PDT) Received: from blake.timetraveller.org (blake.timetraveller.org [203.23.43.10]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h67Ff42x030830 for ; Mon, 7 Jul 2003 08:41:05 -0700 Received: from zen.canint.timetraveller.org (CPE00105ae6b1e1-CM000039aeec61.cpe.net.cable.rogers.com [63.139.6.84]) by blake.timetraveller.org (8.12.3/8.12.3) with ESMTP id h67FfkLO013700 for ; Tue, 8 Jul 2003 01:41:47 +1000 Received: from zen.canint.timetraveller.org (zen.canint.timetraveller.org [192.168.120.1]) by zen.canint.timetraveller.org (8.12.6/8.12.6) with ESMTP id h67FWIwG022719 for ; Mon, 7 Jul 2003 11:32:18 -0400 Date: Mon, 7 Jul 2003 11:32:18 -0400 (EDT) From: Robert Brockway X-X-Sender: robert@zen.canint.timetraveller.org To: linux-xfs@oss.sgi.com Subject: Re: [bug report]: chown(2) implementation in xfs is broken In-Reply-To: <20030707065106.GY930@plato.local.lan> Message-ID: References: <7kadbrchcp.fsf@greenplant.dot> <3F08C005.3070706@linux-sxs.org> <20030707053311.GX930@plato.local.lan> <20030707065106.GY930@plato.local.lan> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 4591 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: robert@timetraveller.org Precedence: bulk X-list: linux-xfs On Sun, 6 Jul 2003, Ethan Benson wrote: > your example doesn't really does not demonstrate any security hole > anyway since you owned the file you could just as well run chmod 555 > testfile and then executed it. even with irix behavior you cannot > chown a file you don't already own in the first place. Yes, you're right. I should have demonstrated it with changing gid not uid. This is equally doable and does show a security hole. It was late when I wrote that and I failed to see the obvious error in using uid. > typically its not allowed when quotas are in use, im not sure whether > the irix behavior keeps to that or not. Linux quite happily set restrict_chown=0 on my quota enabled xfs filesystem. It would definately be worth having a sanity check about enabling both options at once. Rob -- Robert Brockway B.Sc. email: robert@timetraveller.org ICQ: 104781119 Linux counter project ID #16440 (http://counter.li.org) "The earth is but one country and mankind its citizens" -Baha'u'llah From owner-linux-xfs@oss.sgi.com Mon Jul 7 21:53:44 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 07 Jul 2003 21:54:04 -0700 (PDT) Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.9/8.12.9) with ESMTP id h684ri2x015170 for ; Mon, 7 Jul 2003 21:53:44 -0700 Received: (from xfs@localhost) by oss.sgi.com (8.12.9/8.12.8/Submit) id h684riQO015169 for linux-xfs@oss.sgi.com; Mon, 7 Jul 2003 21:53:44 -0700 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.9/8.12.9) with ESMTP id h684rg33015153 for ; Mon, 7 Jul 2003 21:53:43 -0700 Received: (from apache@localhost) by oss.sgi.com (8.12.9/8.12.8/Submit) id h684bL66015035; Mon, 7 Jul 2003 21:37:21 -0700 Date: Mon, 7 Jul 2003 21:37:21 -0700 Message-Id: <200307080437.h684bL66015035@oss.sgi.com> From: bugzilla-daemon@oss.sgi.com To: xfs-master@oss.sgi.com Subject: [Bug 258] Kernel (smp) lockup: ioctl(XFS_IOC_RESVSP); truncate() on fs with unwritten=1 X-Bugzilla-Reason: AssignedTo X-archive-position: 4592 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: bugzilla-daemon@oss.sgi.com Precedence: bulk X-list: linux-xfs http://oss.sgi.com/bugzilla/show_bug.cgi?id=258 nathans@sgi.com changed: What |Removed |Added ---------------------------------------------------------------------------- Status|ASSIGNED |RESOLVED Resolution| |INVALID ------- Additional Comments From nathans@sgi.com 2003-07-07 21:37 PDT ------- hi Mike, So, I have looked into this some more and am currently leaning toward thinking this is "user error" (no offence, had me confused too). What is leading you to think your machine is deadlocked? If you leave it for awhile does it come "back to life"? When I initially ran this, I too thought my machine was dead, but after awhile it did return and it successfully completed the program. What your program is doing is as follows: - preallocates 10 gigabytes of space. what this equates to is a bunch of unwritten extents being allocated as backing store for your file. note: the end of file mark is still at offset zero afterward. - closes the file. (this step is benign, could use ftruncate next..) - truncates the file at 10 gigabytes. what this means to XFS is that all of your allocated, but initialised space must now be initialised. so, this means we need to zero all unwritten extents from current end of file to the new end of file (i.e. from 0 to 10 gigabytes). this, of course, generates _alot_ of IO... So, what was the original goal here? You could alternatively have used the ALLOCSP interface, which zeroes all data as its being allocated, and avoids the extra overhead of converting all unwritten extents into "written" extents as well. Did you have kdb enabled on your machine? If so, did you drop into kdb during your test? (doesn't happen to me). If you do, then there is a real problem here which I'm not seeing yet. cheers. ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From owner-linux-xfs@oss.sgi.com Tue Jul 8 02:23:26 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 08 Jul 2003 02:23:46 -0700 (PDT) Received: from iris.acsalaska.net (iris.slb.nwc.acsalaska.net [209.112.155.43]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h689NP2x019241 for ; Tue, 8 Jul 2003 02:23:26 -0700 Received: from erbenson.alaska.net (69-pm30.nwc.alaska.net [209.112.158.69]) by iris.acsalaska.net (8.12.9/8.12.9) with ESMTP id h687AkTA032195 for ; Mon, 7 Jul 2003 23:10:47 -0800 (AKDT) (envelope-from erbenson@alaska.net) Received: from plato.local.lan (plato.local.lan [192.168.0.4]) by erbenson.alaska.net (Postfix) with ESMTP id D1A643A07 for ; Mon, 7 Jul 2003 23:10:45 -0800 (AKDT) Received: by plato.local.lan (Postfix, from userid 1000) id 5EF3C40FF44; Mon, 7 Jul 2003 23:10:45 -0800 (AKDT) Date: Mon, 7 Jul 2003 23:10:45 -0800 From: Ethan Benson To: linux-xfs@oss.sgi.com Subject: Re: [bug report]: chown(2) implementation in xfs is broken Message-ID: <20030708071045.GE930@plato.local.lan> Mail-Followup-To: linux-xfs@oss.sgi.com References: <7kadbrchcp.fsf@greenplant.dot> <3F08C005.3070706@linux-sxs.org> <20030707053311.GX930@plato.local.lan> <20030707065106.GY930@plato.local.lan> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="ATpkSYPIqF1Y+gtT" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.3.28i X-OS: Debian GNU X-gpg-fingerprint: E3E4 D0BC 31BC F7BB C1DD C3D6 24AC 7B1A 2C44 7AFC X-gpg-key: http://www.alaska.net/~erbenson/gpg/key.asc Mail-Copies-To: nobody X-No-CC: I subscribe to this list; do not CC me on replies. X-ACS-Spam-Status: no X-Scanned-By: MIMEDefang 2.31 (www . roaringpenguin . com / mimedefang) X-archive-position: 4593 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: erbenson@alaska.net Precedence: bulk X-list: linux-xfs --ATpkSYPIqF1Y+gtT Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Jul 07, 2003 at 11:32:18AM -0400, Robert Brockway wrote: > On Sun, 6 Jul 2003, Ethan Benson wrote: >=20 > > your example doesn't really does not demonstrate any security hole > > anyway since you owned the file you could just as well run chmod 555 > > testfile and then executed it. even with irix behavior you cannot > > chown a file you don't already own in the first place. >=20 > Yes, you're right. I should have demonstrated it with changing gid not > uid. This is equally doable and does show a security hole. It was late > when I wrote that and I failed to see the obvious error in using uid. how so? s bits are cleared on chown(2). > > typically its not allowed when quotas are in use, im not sure whether > > the irix behavior keeps to that or not. >=20 > Linux quite happily set restrict_chown=3D0 on my quota enabled xfs > filesystem. It would definately be worth having a sanity check about > enabling both options at once. did you check that chown() was still permitted? if so i would find out if irix is the same. i would consider that a bug, but since its a configurable sysctl default to a secure state its not really that big a deal, if root wants to shoot himself in the foot, let him. --=20 Ethan Benson http://www.alaska.net/~erbenson/ --ATpkSYPIqF1Y+gtT Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iEYEARECAAYFAj8KbnUACgkQJKx7GixEevxOJACfYZDLvhV60plQQzKLbFql70U/ bvgAmQHH3uOdKZOA48153zJEnO+LdveH =yckI -----END PGP SIGNATURE----- --ATpkSYPIqF1Y+gtT-- From owner-linux-xfs@oss.sgi.com Tue Jul 8 08:17:57 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 08 Jul 2003 08:18:16 -0700 (PDT) Received: from zok.sgi.com (zok.SGI.COM [204.94.215.101]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h68FHv2x004776 for ; Tue, 8 Jul 2003 08:17:57 -0700 Received: from flecktone.americas.sgi.com (flecktone.americas.sgi.com [192.48.203.135]) by zok.sgi.com (8.12.9/8.12.2/linux-outbound_gateway-1.2) with ESMTP id h68FHpiY003423 for ; Tue, 8 Jul 2003 08:17:51 -0700 Received: from maine.americas.sgi.com (maine.americas.sgi.com [128.162.232.87]) by flecktone.americas.sgi.com (8.12.9/8.12.9/generic_config-1.2) with ESMTP id h68FGpqX8308552 for ; Tue, 8 Jul 2003 10:16:51 -0500 (CDT) Received: from nstraz by maine.americas.sgi.com with local (Exim 3.36 #1 (Debian)) id 19ZuD5-00022v-00 for ; Tue, 08 Jul 2003 10:16:51 -0500 Subject: TAKE - Fix QA test 017 Message-Id: From: Nathan Straz To: linux-xfs@oss.sgi.com Date: Tue, 08 Jul 2003 10:16:51 -0500 X-archive-position: 4594 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: nstraz@sgi.com Precedence: bulk X-list: linux-xfs fsstress was moved from src to ltp Date: Tue Jul 8 08:00:17 PDT 2003 Workarea: maine.americas.sgi.com:/extra/wa/xfs-2.4.x Author: nstraz The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: xfs-cmds:slinx:152640a cmd/xfstests/017 - 1.11 From owner-linux-xfs@oss.sgi.com Tue Jul 8 08:30:56 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 08 Jul 2003 08:31:11 -0700 (PDT) Received: from bass.cnw.cz (bass.cnw.cz [193.85.207.202]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h68FUr2x005601 for ; Tue, 8 Jul 2003 08:30:55 -0700 Received: from prahaa-5-13.dialup.vol.cz ([62.177.72.145] helo=best.cnw.cz) by bass.cnw.cz with esmtp (Exim 3.36 #1 (Debian)) for linux-xfs@oss.sgi.com id 19ZuQj-000232-00; Tue, 08 Jul 2003 17:30:57 +0200 Received: from localhost ([127.0.0.1]) by best.cnw.cz with esmtp (Exim 3.36 #1 (Debian)) for linux-xfs@oss.sgi.com id 19ZuQO-0003Rf-00; Tue, 08 Jul 2003 17:30:36 +0200 Subject: SW raid5 & loop device & log problem From: "Ing. Milan Kocian" To: linux-xfs@oss.sgi.com Content-Type: text/plain Message-Id: <1057678236.10402.283.camel@best.cnw.cz> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.0 Date: 08 Jul 2003 17:30:36 +0200 Content-Transfer-Encoding: 7bit X-archive-position: 4595 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: milan.kocian@cnw.cz Precedence: bulk X-list: linux-xfs Hello, I played with xfs on crypto-loop device (aes-loop on sf.net) on sw raid5 (log v2 on raid5 device). I think that I found a bug. I created loop on raid5, formatted it with xfs, mounted it and all was ok. Then I unmounted loop and with next mount I saw this: XFS: log inconsistent or not a log (last==0, first!=1) XFS: empty log check failed I had to repair loop with xfs_repair. And after next umount the same bug. I tried log v2 and then v1. It had no effect. On normaly partition (with loop) I had no problem. Only on raid5. I didn't test raid1. Original loop device had the same problem. Checked with xfs 2.4.20-2003-03-19_04:55_UTC and linux-2.4.21-xfs-2003-05-23-cvs.patch.bz2 and with 2.4.21_xfs. Thanks for answer. Best regards Milan Kocian From owner-linux-xfs@oss.sgi.com Tue Jul 8 09:00:41 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 08 Jul 2003 09:00:57 -0700 (PDT) Received: from blake.timetraveller.org (blake.timetraveller.org [203.23.43.10]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h68G0R2x006290 for ; Tue, 8 Jul 2003 09:00:41 -0700 Received: from zen.canint.timetraveller.org (CPE00105ae6b1e1-CM000039aeec61.cpe.net.cable.rogers.com [63.139.6.84]) by blake.timetraveller.org (8.12.3/8.12.3) with ESMTP id h68FpkO3024423 for ; Wed, 9 Jul 2003 01:51:48 +1000 Received: from zen.canint.timetraveller.org (zen.canint.timetraveller.org [192.168.120.1]) by zen.canint.timetraveller.org (8.12.6/8.12.6) with ESMTP id h68FoFwG006046 for ; Tue, 8 Jul 2003 11:50:15 -0400 Date: Tue, 8 Jul 2003 11:50:15 -0400 (EDT) From: Robert Brockway X-X-Sender: robert@zen.canint.timetraveller.org To: linux-xfs@oss.sgi.com Subject: Re: [bug report]: chown(2) implementation in xfs is broken In-Reply-To: <20030708071045.GE930@plato.local.lan> Message-ID: References: <7kadbrchcp.fsf@greenplant.dot> <3F08C005.3070706@linux-sxs.org> <20030707053311.GX930@plato.local.lan> <20030707065106.GY930@plato.local.lan> <20030708071045.GE930@plato.local.lan> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 4596 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: robert@timetraveller.org Precedence: bulk X-list: linux-xfs On Mon, 7 Jul 2003, Ethan Benson wrote: > how so? s bits are cleared on chown(2). Yes, I confirmed that the s bit was being cleared with the chown, as normal. > > Linux quite happily set restrict_chown=0 on my quota enabled xfs > > filesystem. It would definately be worth having a sanity check about > > enabling both options at once. > > did you check that chown() was still permitted? if so i would find Yep. The tests I did were all on an xfs with quota enabled and in use. > out if irix is the same. i would consider that a bug, but since its a > configurable sysctl default to a secure state its not really that big > a deal, if root wants to shoot himself in the foot, let him. nuke(8) ;) [1] [1] From the ASR man pages. Rob -- Robert Brockway B.Sc. email: robert@timetraveller.org ICQ: 104781119 Linux counter project ID #16440 (http://counter.li.org) "The earth is but one country and mankind its citizens" -Baha'u'llah From owner-linux-xfs@oss.sgi.com Tue Jul 8 09:09:29 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 08 Jul 2003 09:09:43 -0700 (PDT) Received: from zok.sgi.com (zok.SGI.COM [204.94.215.101]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h68G9S2x006803 for ; Tue, 8 Jul 2003 09:09:29 -0700 Received: from flecktone.americas.sgi.com (flecktone.americas.sgi.com [192.48.203.135]) by zok.sgi.com (8.12.9/8.12.2/linux-outbound_gateway-1.2) with ESMTP id h68G9NiY011437 for ; Tue, 8 Jul 2003 09:09:23 -0700 Received: from daisy-e236.americas.sgi.com (daisy-e236.americas.sgi.com [128.162.236.214]) by flecktone.americas.sgi.com (8.12.9/8.12.9/generic_config-1.2) with ESMTP id h68G8NqX8319373 for ; Tue, 8 Jul 2003 11:08:23 -0500 (CDT) Received: from sgi.com (chuckle.americas.sgi.com [128.162.241.66]) by daisy-e236.americas.sgi.com (8.12.9/SGI-server-1.8) with ESMTP id h68G8MRn153080734 for ; Tue, 8 Jul 2003 11:08:22 -0500 (CDT) Received: from chuckle.americas.sgi.com (localhost [127.0.0.1]) by sgi.com (8.12.8/8.12.8) with ESMTP id h68G461Y014459 for ; Tue, 8 Jul 2003 11:04:07 -0500 Received: (from cattelan@localhost) by chuckle.americas.sgi.com (8.12.8/8.12.8/Submit) id h68G46HV014457 for linux-xfs@oss.sgi.com; Tue, 8 Jul 2003 11:04:06 -0500 Date: Tue, 8 Jul 2003 11:04:06 -0500 From: Russell Cattelan Message-Id: <200307081604.h68G46HV014457@chuckle.americas.sgi.com> Subject: TAKE - merge up the 1.3 tree X-archive-position: 4597 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: cattelan@chuckle.americas.sgi.com Precedence: bulk X-list: linux-xfs rework sysctl initialization to avoid confusion Date: Tue Jul 8 08:59:01 PDT 2003 Workarea: chuckle.americas.sgi.com:/go/xfs2/XFS/x2.4-xfs-r1.3 Author: sandeen Merged by: cattelan Merged mods: xfs-linux:slinx:152419a The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs-r1.3 Modid: 2.4.x-xfs-r1.3:slinx:152419a linux/fs/xfs/xfs_rw.c - 1.379 linux/fs/xfs/xfs_vfsops.c - 1.422 linux/fs/xfs/linux/xfs_globals.c - 1.51 linux/fs/xfs/linux/xfs_linux.h - 1.106 linux/fs/xfs/linux/xfs_super.c - 1.259 linux/fs/xfs/linux/xfs_sysctl.h - 1.14 linux/fs/xfs/linux/xfs_sysctl.c - 1.21 linux/fs/xfs/pagebuf/page_buf.c - 1.122 linux/fs/xfs/pagebuf/page_buf_internal.h - 1.24 - Merge of xfs-linux:slinx:152419a by cattelan. Subject: TAKE - Whoops, fix up pagebuf debug sysctl table entry Date: Tue Jul 8 09:03:01 PDT 2003 Workarea: chuckle.americas.sgi.com:/go/xfs2/XFS/x2.4-xfs-r1.3 Author: sandeen Merged by: cattelan Merged mods: xfs-linux:slinx:152421a The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs-r1.3 Modid: 2.4.x-xfs-r1.3:slinx:152421a linux/fs/xfs/pagebuf/page_buf.c - 1.123 - Merge of xfs-linux:slinx:152421a by cattelan. Subject: TAKE - Use C99 initializers on sysctl structs Date: Tue Jul 8 09:05:16 PDT 2003 Workarea: chuckle.americas.sgi.com:/go/xfs2/XFS/x2.4-xfs-r1.3 Author: sandeen Merged by: cattelan Merged mods: xfs-linux:slinx:152435a The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs-r1.3 Modid: 2.4.x-xfs-r1.3:slinx:152435a linux/fs/xfs/linux/xfs_globals.c - 1.52 linux/fs/xfs/pagebuf/page_buf.c - 1.124 - Merge of xfs-linux:slinx:152435a by cattelan. Subject: TAKE 892207 - Catch read-only filesystems in xfs_setattr, and return EROFS Date: Tue Jul 8 09:07:54 PDT 2003 Workarea: chuckle.americas.sgi.com:/go/xfs2/XFS/x2.4-xfs-r1.3 Author: sandeen Merged by: cattelan Merged mods: xfs-linux:slinx:152528a The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs-r1.3 Modid: 2.4.x-xfs-r1.3:slinx:152528a linux/fs/xfs/xfs_vnodeops.c - 1.593 - Merge of xfs-linux:slinx:152528a by cattelan. From owner-linux-xfs@oss.sgi.com Tue Jul 8 18:50:16 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 08 Jul 2003 18:50:38 -0700 (PDT) Received: from waltsathlon.localhost.net (12-229-144-126.client.attbi.com [12.229.144.126]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h691o72x007642 for ; Tue, 8 Jul 2003 18:50:16 -0700 Received: from comcast.net (localhost [127.0.0.1]) by waltsathlon.localhost.net (Postfix) with ESMTP id 739B874A14; Tue, 8 Jul 2003 18:50:02 -0700 (PDT) Message-ID: <3F0B74CA.50003@comcast.net> Date: Tue, 08 Jul 2003 18:50:02 -0700 From: Walt H User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5a) Gecko/20030704 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Ing. Milan Kocian" Cc: linux-xfs@oss.sgi.com Subject: Re: SW raid5 & loop device & log problem References: <1057678236.10402.283.camel@best.cnw.cz> In-Reply-To: <1057678236.10402.283.camel@best.cnw.cz> X-Enigmail-Version: 0.76.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-archive-position: 4598 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: waltabbyh@comcast.net Precedence: bulk X-list: linux-xfs Ing. Milan Kocian wrote: > Hello, > > I played with xfs on crypto-loop device (aes-loop on sf.net) on sw raid5 > (log v2 on raid5 device). I think that I found a bug. I created loop on > raid5, formatted it with xfs, mounted it and all was ok. Then I > unmounted loop and with next mount I saw this: > > XFS: log inconsistent or not a log (last==0, first!=1) > XFS: empty log check failed > > I had to repair loop with xfs_repair. And after next umount the same > bug. > > I tried log v2 and then v1. It had no effect. On normaly partition (with > loop) I had no problem. Only on raid5. I didn't test raid1. Original > loop device had the same problem. > > Checked with xfs 2.4.20-2003-03-19_04:55_UTC > and linux-2.4.21-xfs-2003-05-23-cvs.patch.bz2 and with 2.4.21_xfs. > > Thanks for answer. > > Best regards Milan Kocian > > > > I am currently running a loop-aes encrypted filesystem over XFS on raid1 with no problems. I also tried running it over raid5, but suffered fs corruption upon umount and was unable to remount it afterward. I assumed that the way that data is laid out over a raid5 volume is incompatible with a loop-aes encrypted filesystem. I remember reading some caveats with journaling filesystems indicating that writes have to be guaranteed to be written in order in order for them to work. Perhaps this isn't the case when using raid5? -Walt From owner-linux-xfs@oss.sgi.com Tue Jul 8 20:26:25 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 08 Jul 2003 20:26:42 -0700 (PDT) Received: from rj.sgi.com (rj.SGI.COM [192.82.208.96]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h693QP2x009141 for ; Tue, 8 Jul 2003 20:26:25 -0700 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.54.149]) by rj.sgi.com (8.12.9/8.12.2/linux-outbound_gateway-1.2) with ESMTP id h693QLWr018968 for ; Tue, 8 Jul 2003 20:26:25 -0700 Received: from snort.melbourne.sgi.com (localhost [127.0.0.1]) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id h693OwJA2921917 for ; Wed, 9 Jul 2003 13:24:58 +1000 (EST) Received: (from nathans@localhost) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id h693OvnB2932312 for linux-xfs@oss.sgi.com; Wed, 9 Jul 2003 13:24:57 +1000 (EST) Date: Wed, 9 Jul 2003 13:24:57 +1000 (EST) From: Nathan Scott Message-Id: <200307090324.h693OvnB2932312@snort.melbourne.sgi.com> To: linux-xfs@oss.sgi.com Subject: TAKE - xfs_aops.c X-archive-position: 4599 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: nathans@snort.melbourne.sgi.com Precedence: bulk X-list: linux-xfs Avoid doing the page->mapping->host dereferences twice on writepage. Date: Tue Jul 8 17:33:24 PDT 2003 Workarea: snort.melbourne.sgi.com:/home/nathans/clean-2.4.x-xfs The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: xfs-linux:slinx:152717a linux/fs/xfs/linux/xfs_aops.c - 1.40 From owner-linux-xfs@oss.sgi.com Wed Jul 9 03:53:51 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 09 Jul 2003 03:53:55 -0700 (PDT) Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.9/8.12.9) with ESMTP id h69Arp2x017171 for ; Wed, 9 Jul 2003 03:53:51 -0700 Received: (from xfs@localhost) by oss.sgi.com (8.12.9/8.12.8/Submit) id h69Arphv017170 for linux-xfs@oss.sgi.com; Wed, 9 Jul 2003 03:53:51 -0700 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.9/8.12.9) with ESMTP id h69Arm31017156 for ; Wed, 9 Jul 2003 03:53:48 -0700 Received: (from apache@localhost) by oss.sgi.com (8.12.9/8.12.8/Submit) id h69A8Y1N016207; Wed, 9 Jul 2003 03:08:34 -0700 Date: Wed, 9 Jul 2003 03:08:34 -0700 Message-Id: <200307091008.h69A8Y1N016207@oss.sgi.com> From: bugzilla-daemon@oss.sgi.com To: xfs-master@oss.sgi.com Subject: [Bug 260] New: excessive swapping X-Bugzilla-Reason: AssignedTo X-archive-position: 4600 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: bugzilla-daemon@oss.sgi.com Precedence: bulk X-list: linux-xfs http://oss.sgi.com/bugzilla/show_bug.cgi?id=260 Summary: excessive swapping Product: Linux XFS Version: 1.2.x Platform: IA32 OS/Version: Linux Status: NEW Severity: critical Priority: High Component: XFS kernel code AssignedTo: xfs-master@oss.sgi.com ReportedBy: cchan@outblaze.com I have a RH7.3 box running the RH 2.4.20-13 with SGI_XFS patches applied. I have found that it is swapping when under high load although there is physical memory that could be used instead of using swap. The box runs postfix with mysql code enabled. The box would start swapping although free -m would report that about 200MB could still be freed from the cache. The amount of swap used was also about 200MB, a bit less than the amount of cached data. ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From owner-linux-xfs@oss.sgi.com Wed Jul 9 09:53:54 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 09 Jul 2003 09:54:17 -0700 (PDT) Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.9/8.12.9) with ESMTP id h69Grs2x028296 for ; Wed, 9 Jul 2003 09:53:54 -0700 Received: (from xfs@localhost) by oss.sgi.com (8.12.9/8.12.8/Submit) id h69GrsfT028295 for linux-xfs@oss.sgi.com; Wed, 9 Jul 2003 09:53:54 -0700 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.9/8.12.9) with ESMTP id h69Grn33028272 for ; Wed, 9 Jul 2003 09:53:50 -0700 Received: (from apache@localhost) by oss.sgi.com (8.12.9/8.12.8/Submit) id h69GTsY9028032; Wed, 9 Jul 2003 09:29:54 -0700 Date: Wed, 9 Jul 2003 09:29:54 -0700 Message-Id: <200307091629.h69GTsY9028032@oss.sgi.com> From: bugzilla-daemon@oss.sgi.com To: xfs-master@oss.sgi.com Subject: [Bug 252] linux-2.4.20-18.9RH breaks rpm, something to do with nptl add rpm. X-Bugzilla-Reason: AssignedTo X-archive-position: 4601 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: bugzilla-daemon@oss.sgi.com Precedence: bulk X-list: linux-xfs http://oss.sgi.com/bugzilla/show_bug.cgi?id=252 cattelan@thebarn.com changed: What |Removed |Added ---------------------------------------------------------------------------- AssignedTo|xfs-master@oss.sgi.com |sandeen@sgi.com Status|ASSIGNED |NEW ------- Additional Comments From cattelan@thebarn.com 2003-09-07 09:29 PDT ------- Note the correct environment var is: LD_ASSUME_KERNEL not LD_KERNEL_ASSUME this of course is still a work around. ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From owner-linux-xfs@oss.sgi.com Wed Jul 9 10:34:12 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 09 Jul 2003 10:34:55 -0700 (PDT) Received: from universe.chowhouse.com (IDENT:0@stumpy.chowhouse.com [209.180.91.165] (may be forged)) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h69HXV2x002016 for ; Wed, 9 Jul 2003 10:34:12 -0700 Received: from universe.chowhouse.com (IDENT:1000@localhost [127.0.0.1]) by universe.chowhouse.com (8.12.6/8.12.6) with ESMTP id h69HgYBI017608 for ; Wed, 9 Jul 2003 11:42:34 -0600 Received: from localhost (james@localhost) by universe.chowhouse.com (8.12.6/8.12.6/Submit) with ESMTP id h69HgYls017605 for ; Wed, 9 Jul 2003 11:42:34 -0600 Date: Wed, 9 Jul 2003 11:42:34 -0600 (MDT) From: James Rich To: XFS mailing list Subject: raid 1 on xfs? Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 4602 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: james@chowhouse.com Precedence: bulk X-list: linux-xfs What is the status of using raid 1 on xfs? I remember that previously there were problems, but that was some time ago and a lot has changed. Are there any problems or gotchas with using xfs over software raid 1? James Rich From owner-linux-xfs@oss.sgi.com Wed Jul 9 11:53:52 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 09 Jul 2003 11:54:08 -0700 (PDT) Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.9/8.12.9) with ESMTP id h69Irq2x005664 for ; Wed, 9 Jul 2003 11:53:52 -0700 Received: (from xfs@localhost) by oss.sgi.com (8.12.9/8.12.8/Submit) id h69IrqgM005663 for linux-xfs@oss.sgi.com; Wed, 9 Jul 2003 11:53:52 -0700 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.9/8.12.9) with ESMTP id h69Iro31005648 for ; Wed, 9 Jul 2003 11:53:50 -0700 Received: (from apache@localhost) by oss.sgi.com (8.12.9/8.12.8/Submit) id h69IlvXw005614; Wed, 9 Jul 2003 11:47:57 -0700 Date: Wed, 9 Jul 2003 11:47:57 -0700 Message-Id: <200307091847.h69IlvXw005614@oss.sgi.com> From: bugzilla-daemon@oss.sgi.com To: xfs-master@oss.sgi.com Subject: [Bug 261] New: linux kernel 2.5.73 / xfsprogs 2.3.9 fails on striped devices with 2K block size X-Bugzilla-Reason: AssignedTo X-archive-position: 4603 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: bugzilla-daemon@oss.sgi.com Precedence: bulk X-list: linux-xfs http://oss.sgi.com/bugzilla/show_bug.cgi?id=261 Summary: linux kernel 2.5.73 / xfsprogs 2.3.9 fails on striped devices with 2K block size Product: Linux XFS Version: unspecified Platform: All OS/Version: Linux Status: NEW Severity: normal Priority: Low Component: xfsprogs AssignedTo: xfs-master@oss.sgi.com ReportedBy: chrisf@filmlight.ltd.uk I have a Medea disk array which can be configured to have a 512 or 2K block size. The array appears as a single device and I can can create xfs file systems on a single device in either mode. When I take two disk arrays, use mkraid to stripe them together and attempt to create an xfs file system on /dev/md0, mkfs.xfs fails with I/O errors unless the device have been configured with a block size of 512. ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From owner-linux-xfs@oss.sgi.com Wed Jul 9 14:06:03 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 09 Jul 2003 14:06:18 -0700 (PDT) Received: from zok.sgi.com (zok.SGI.COM [204.94.215.101]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h69L632x002708 for ; Wed, 9 Jul 2003 14:06:03 -0700 Received: from flecktone.americas.sgi.com (flecktone.americas.sgi.com [192.48.203.135]) by zok.sgi.com (8.12.9/8.12.2/linux-outbound_gateway-1.2) with ESMTP id h69G9ZiY016726 for ; Wed, 9 Jul 2003 09:09:35 -0700 Received: from daisy-e236.americas.sgi.com (daisy-e236.americas.sgi.com [128.162.236.214]) by flecktone.americas.sgi.com (8.12.9/8.12.9/generic_config-1.2) with ESMTP id h69G8YqX8509603 for ; Wed, 9 Jul 2003 11:08:34 -0500 (CDT) Received: from sgi.com (chuckle.americas.sgi.com [128.162.241.66]) by daisy-e236.americas.sgi.com (8.12.9/SGI-server-1.8) with ESMTP id h69G8YRn164127059 for ; Wed, 9 Jul 2003 11:08:34 -0500 (CDT) Received: from chuckle.americas.sgi.com (localhost [127.0.0.1]) by sgi.com (8.12.8/8.12.8) with ESMTP id h69G8Y9j011983 for ; Wed, 9 Jul 2003 11:08:34 -0500 Received: (from cattelan@localhost) by chuckle.americas.sgi.com (8.12.8/8.12.8/Submit) id h69G8YQR011981 for linux-xfs@oss.sgi.com; Wed, 9 Jul 2003 11:08:34 -0500 Date: Wed, 9 Jul 2003 11:08:34 -0500 From: Russell Cattelan Message-Id: <200307091608.h69G8YQR011981@chuckle.americas.sgi.com> Subject: TAKE - X-archive-position: 4604 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: cattelan@chuckle.americas.sgi.com Precedence: bulk X-list: linux-xfs Correct i386 backtrace on out of line lock code using jmp disp8 to get back to mainline Date: Tue Jul 8 09:58:27 PDT 2003 Workarea: chuckle.americas.sgi.com:/go/xfs2/XFS/x2.4-xfs-r1.3 Author: kaos Merged by: cattelan Merged mods: 2.4.x-xfs:slinx:152253a The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs-r1.3 Modid: 2.4.x-xfs-r1.3:slinx:152253a linux/arch/i386/kdb/kdba_bt.c - 1.22 - Merge of 2.4.x-xfs:slinx:152253a by cattelan. Subject: TAKE - Remove spurious parentheses Date: Wed Jul 9 08:01:39 PDT 2003 Workarea: chuckle.americas.sgi.com:/go/xfs2/XFS/x2.4-xfs-r1.3 Author: kaos Merged by: cattelan Merged mods: 2.4.x-xfs:slinx:152254a The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs-r1.3 Modid: 2.4.x-xfs-r1.3:slinx:152254a linux/arch/i386/kdb/kdba_bt.c - 1.23 - Merge of 2.4.x-xfs:slinx:152254a by cattelan. Subject: TAKE - Document sysctls Date: Wed Jul 9 08:04:07 PDT 2003 Workarea: chuckle.americas.sgi.com:/go/xfs2/XFS/x2.4-xfs-r1.3 Author: sandeen Merged by: cattelan Merged mods: 2.4.x-xfs:slinx:152420a The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs-r1.3 Modid: 2.4.x-xfs-r1.3:slinx:152420a linux/Documentation/filesystems/xfs.txt - 1.13 - Merge of 2.4.x-xfs:slinx:152420a by cattelan. Subject: TAKE - Upgrade XFS to kdb v4.3-2.4.21-{common,i386}-3 Date: Wed Jul 9 08:10:49 PDT 2003 Workarea: chuckle.americas.sgi.com:/go/xfs2/XFS/x2.4-xfs-r1.3 Author: kaos Merged by: cattelan Merged mods: 2.4.x-xfs:slinx:152422a The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs-r1.3 Modid: 2.4.x-xfs-r1.3:slinx:152422a linux/kdb/modules/kdbm_task.c - 1.1 linux/arch/i386/kernel/smp.c - 1.44 linux/kdb/modules/Makefile - 1.17 linux/kdb/ChangeLog - 1.33 linux/arch/i386/kdb/ChangeLog - 1.22 - Merge of 2.4.x-xfs:slinx:152422a by cattelan. Subject: TAKE - Upgrade XFS to kdb v4.3-2.4.21-common-4 Date: Wed Jul 9 08:19:29 PDT 2003 Workarea: chuckle.americas.sgi.com:/go/xfs2/XFS/x2.4-xfs-r1.3 Author: kaos Merged by: cattelan Merged mods: 2.4.x-xfs:slinx:152525a The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs-r1.3 Modid: 2.4.x-xfs-r1.3:slinx:152525a linux/kernel/sysctl.c - 1.52 linux/kdb/ChangeLog - 1.34 - Merge of 2.4.x-xfs:slinx:152525a by cattelan. Subject: TAKE - Make VM_PAGEBUF the same number as in 2.5 kernels Date: Wed Jul 9 09:08:12 PDT 2003 Workarea: chuckle.americas.sgi.com:/go/xfs2/XFS/x2.4-xfs-r1.3 Author: kaos Merged by: cattelan Merged mods: 2.4.x-xfs:slinx:152529a The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs-r1.3 Modid: 2.4.x-xfs-r1.3:slinx:152529a linux/include/linux/sysctl.h - 1.56 - Merge of 2.4.x-xfs:slinx:152529a by cattelan. From owner-linux-xfs@oss.sgi.com Wed Jul 9 19:16:06 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 09 Jul 2003 19:16:24 -0700 (PDT) Received: from zok.sgi.com (zok.SGI.COM [204.94.215.101]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h6A2G42x010638 for ; Wed, 9 Jul 2003 19:16:05 -0700 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.54.149]) by zok.sgi.com (8.12.9/8.12.2/linux-outbound_gateway-1.2) with ESMTP id h6A2FwiY026784 for ; Wed, 9 Jul 2003 19:15:58 -0700 Received: from snort.melbourne.sgi.com (localhost [127.0.0.1]) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id h6A2EeJA3043712 for ; Thu, 10 Jul 2003 12:14:40 +1000 (EST) Received: (from nathans@localhost) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id h6A2EeUB3036292 for linux-xfs@oss.sgi.com; Thu, 10 Jul 2003 12:14:40 +1000 (EST) Date: Thu, 10 Jul 2003 12:14:40 +1000 (EST) From: Nathan Scott Message-Id: <200307100214.h6A2EeUB3036292@snort.melbourne.sgi.com> To: linux-xfs@oss.sgi.com Subject: TAKE - maximum file size fixes X-archive-position: 4605 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: nathans@snort.melbourne.sgi.com Precedence: bulk X-list: linux-xfs Correct the sb_maxbytes value for non-pagesize filesystem block sizes, and all uses of max file size constant within XFS. Date: Wed Jul 9 18:54:38 PDT 2003 Workarea: snort.melbourne.sgi.com:/home/nathans/clean-2.4.x-xfs The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: xfs-linux:slinx:152845a linux/fs/xfs/xfs_vnodeops.c - 1.597 linux/fs/xfs/xfs_mount.h - 1.176 linux/fs/xfs/xfs_mount.c - 1.333 linux/fs/xfs/xfs_inode.c - 1.380 linux/fs/xfs/xfs_inode.h - 1.185 linux/fs/xfs/xfs_bmap.c - 1.306 linux/fs/xfs/quota/xfs_qm.c - 1.5 linux/fs/xfs/dmapi/dmapi_xfs.c - 1.10 linux/fs/xfs/linux/xfs_lrw.c - 1.191 linux/fs/xfs/linux/xfs_super.h - 1.50 linux/fs/xfs/linux/xfs_super.c - 1.262 Make absolutely sure we don't attempt to access beyond the end of the maximum file size limit. This could happen previously with the space allocation heuristic for delalloc beyond the end of file. Date: Wed Jul 9 19:03:25 PDT 2003 Workarea: snort.melbourne.sgi.com:/home/nathans/clean-2.4.x-xfs The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: xfs-linux:slinx:152846a linux/fs/xfs/linux/xfs_iomap.c - 1.14 From owner-linux-xfs@oss.sgi.com Thu Jul 10 01:14:09 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 10 Jul 2003 01:14:25 -0700 (PDT) Received: from smtpzilla1.xs4all.nl (smtpzilla1.xs4all.nl [194.109.127.137]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h6A8E72x016164 for ; Thu, 10 Jul 2003 01:14:08 -0700 Received: from auto-nb1.xs4all.nl (coltex.xs4all.nl [213.84.127.28]) by smtpzilla1.xs4all.nl (8.12.9/8.12.9) with ESMTP id h6A8E17F026405; Thu, 10 Jul 2003 10:14:01 +0200 (CEST) Message-Id: <4.3.2.7.2.20030710101137.0309b150@pop.xs4all.nl> X-Sender: knuffie@pop.xs4all.nl X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 10 Jul 2003 10:13:49 +0200 To: James Rich , XFS mailing list From: Seth Mos Subject: Re: raid 1 on xfs? In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-archive-position: 4606 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: knuffie@xs4all.nl Precedence: bulk X-list: linux-xfs At 11:42 9-7-2003 -0600, James Rich wrote: >What is the status of using raid 1 on xfs? I remember that previously >there were problems, but that was some time ago and a lot has changed. >Are there any problems or gotchas with using xfs over software raid 1? AFAIK there never has been a problem with xfs on top of raid 1 I have 5 servers with XFS using various forms of software raid 1 and 5 and they all work as advertised. Only raid 5 had performance issues which are mostly gone with the version 2 logformat which is introduced in XFS 1.2. Cheers -- Seth It might just be your lucky day, if you only knew. From owner-linux-xfs@oss.sgi.com Thu Jul 10 01:53:55 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 10 Jul 2003 01:54:08 -0700 (PDT) Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.9/8.12.9) with ESMTP id h6A8rt2x017577 for ; Thu, 10 Jul 2003 01:53:55 -0700 Received: (from xfs@localhost) by oss.sgi.com (8.12.9/8.12.8/Submit) id h6A8rtLa017576 for linux-xfs@oss.sgi.com; Thu, 10 Jul 2003 01:53:55 -0700 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.9/8.12.9) with ESMTP id h6A8rr31017562 for ; Thu, 10 Jul 2003 01:53:53 -0700 Received: (from apache@localhost) by oss.sgi.com (8.12.9/8.12.8/Submit) id h6A8M110016964; Thu, 10 Jul 2003 01:22:01 -0700 Date: Thu, 10 Jul 2003 01:22:01 -0700 Message-Id: <200307100822.h6A8M110016964@oss.sgi.com> From: bugzilla-daemon@oss.sgi.com To: xfs-master@oss.sgi.com Subject: [Bug 260] excessive swapping X-Bugzilla-Reason: AssignedTo X-archive-position: 4607 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: bugzilla-daemon@oss.sgi.com Precedence: bulk X-list: linux-xfs http://oss.sgi.com/bugzilla/show_bug.cgi?id=260 ------- Additional Comments From gale@dstl.gov.uk 2003-10-07 01:22 PDT ------- I'd suggest you try a 2.4.21 kernel as that has much better memory handling. What makes you think that this is an XFS related issue? ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From owner-linux-xfs@oss.sgi.com Thu Jul 10 02:53:55 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 10 Jul 2003 02:54:10 -0700 (PDT) Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.9/8.12.9) with ESMTP id h6A9rt2x023545 for ; Thu, 10 Jul 2003 02:53:55 -0700 Received: (from xfs@localhost) by oss.sgi.com (8.12.9/8.12.8/Submit) id h6A9rtVW023544 for linux-xfs@oss.sgi.com; Thu, 10 Jul 2003 02:53:55 -0700 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.9/8.12.9) with ESMTP id h6A9rr31023530 for ; Thu, 10 Jul 2003 02:53:53 -0700 Received: (from apache@localhost) by oss.sgi.com (8.12.9/8.12.8/Submit) id h6A9pvb4023344; Thu, 10 Jul 2003 02:51:57 -0700 Date: Thu, 10 Jul 2003 02:51:57 -0700 Message-Id: <200307100951.h6A9pvb4023344@oss.sgi.com> From: bugzilla-daemon@oss.sgi.com To: xfs-master@oss.sgi.com Subject: [Bug 260] excessive swapping X-Bugzilla-Reason: AssignedTo X-archive-position: 4608 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: bugzilla-daemon@oss.sgi.com Precedence: bulk X-list: linux-xfs http://oss.sgi.com/bugzilla/show_bug.cgi?id=260 ------- Additional Comments From cchan@outblaze.com 2003-10-07 02:51 PDT ------- >I'd suggest you try a 2.4.21 kernel as that has much better memory handling. Which is most probably in the RH 2.4.20-13 plus other changes... >What makes you think that this is an XFS related issue? The SGI XFS patches make changes to the VM code in the kernel. I have observed differences in VM behaviour between RH 2.4.20-xx kernels and those that have SGI XFS patches. If SGI XFS is going to make changes to kernel VM behaviour, I'd think they be interested in making sure that kernels with their code in them would perform acceptably especially if their code is also related to the problem area (VM) ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From owner-linux-xfs@oss.sgi.com Thu Jul 10 03:53:57 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 10 Jul 2003 03:54:12 -0700 (PDT) Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.9/8.12.9) with ESMTP id h6AAru2x024601 for ; Thu, 10 Jul 2003 03:53:56 -0700 Received: (from xfs@localhost) by oss.sgi.com (8.12.9/8.12.8/Submit) id h6AAruJk024600 for linux-xfs@oss.sgi.com; Thu, 10 Jul 2003 03:53:56 -0700 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.9/8.12.9) with ESMTP id h6AArs31024586 for ; Thu, 10 Jul 2003 03:53:54 -0700 Received: (from apache@localhost) by oss.sgi.com (8.12.9/8.12.8/Submit) id h6AA6pTE024283; Thu, 10 Jul 2003 03:06:51 -0700 Date: Thu, 10 Jul 2003 03:06:51 -0700 Message-Id: <200307101006.h6AA6pTE024283@oss.sgi.com> From: bugzilla-daemon@oss.sgi.com To: xfs-master@oss.sgi.com Subject: [Bug 260] excessive swapping X-Bugzilla-Reason: AssignedTo X-archive-position: 4609 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: bugzilla-daemon@oss.sgi.com Precedence: bulk X-list: linux-xfs http://oss.sgi.com/bugzilla/show_bug.cgi?id=260 ------- Additional Comments From lord@sgi.com 2003-10-07 03:06 PDT ------- > The SGI XFS patches make changes to the VM code in the kernel. I have observed > differences in VM behaviour between RH 2.4.20-xx kernels and those that have SGI > XFS patches. Just what VM changes do you ascribe to XFS? You state you have a redhat kernel with XFS changes applied, where did it originate, and which XFS patches are you refering to exactly. ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From owner-linux-xfs@oss.sgi.com Thu Jul 10 06:57:51 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 10 Jul 2003 06:58:06 -0700 (PDT) Received: from fecamp.bertin.fr (jussac.bertin.fr [212.234.8.106]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h6ADvo2x001831 for ; Thu, 10 Jul 2003 06:57:51 -0700 Received: from localhost (localhost.localdomain [127.0.0.1]) by fecamp.bertin.fr (Postfix) with SMTP id BDF2D2E8D0 for ; Thu, 10 Jul 2003 15:42:00 +0200 (CEST) Received: from deauville.bertin.fr (deauville.bertin.fr [172.16.0.6]) by fecamp.bertin.fr (Postfix) with ESMTP id 702302E8CB for ; Thu, 10 Jul 2003 15:42:00 +0200 (CEST) Received: by deauville.bertin.fr (Postfix, from userid 48) id 10E5F401D; Thu, 10 Jul 2003 15:55:10 +0200 (CEST) Received: from 172.16.22.251 (SquirrelMail authenticated user lambada) by webmail.bertin.fr with HTTP; Thu, 10 Jul 2003 15:55:09 +0200 (CEST) Message-ID: <35009.172.16.22.251.1057845309.squirrel@webmail.bertin.fr> Date: Thu, 10 Jul 2003 15:55:09 +0200 (CEST) Subject: Addendum to FAQ ? From: lambada@bertin.fr To: linux-xfs@oss.sgi.com User-Agent: SquirrelMail/1.4.0 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 X-Priority: 3 Importance: Normal X-archive-position: 4610 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: lambada@bertin.fr Precedence: bulk X-list: linux-xfs Hi Every root logging is a potential proof of stupididy. It happens that since I had a problem (probably due to Nvidia drivers) with my xfs home partition, I typed mkfs.xfs and not fsck.xfs (by the way, I should have done an xfs_repair). The slight difference with this commands ruined my day and a little more than 15 days of work. 1) Even if I imagine that I have no luck to reconstruct my partition as it is possible with ext2, I am asking if it possible to recover any files (even in a flatted directory) 2) Perharp's it should be added in http://oss.sgi.com/projects/xfs/faq.html#undelete that what does not work with rm, does not work either with mkfs. Thanks. M Le Maudit -- This email and any attached files are confidential and may be legally privileged. If you are not the intended recipient, any disclosure, reproduction, copying, distribution, or other dissemination or use of this communication is strictly prohibited. From owner-linux-xfs@oss.sgi.com Thu Jul 10 07:12:50 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 10 Jul 2003 07:13:04 -0700 (PDT) Received: from goliath.sylaba.poznan.pl (root@goliath.sylaba.poznan.pl [195.216.104.3]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h6AECm2x002795 for ; Thu, 10 Jul 2003 07:12:49 -0700 Received: from goliath.sylaba.poznan.pl (smmsp@localhost.sylaba.poznan.pl [127.0.0.1]) by goliath.sylaba.poznan.pl (8.12.8/8.12.8) with ESMTP id h6AECj6j021607 for ; Thu, 10 Jul 2003 16:12:45 +0200 (CEST) Received: by goliath.sylaba.poznan.pl (8.12.8/8.12.8/Submit) id h6AECidV021600 for linux-xfs@oss.sgi.com.KAV; Thu, 10 Jul 2003 16:12:44 +0200 (CEST) Received: from venus.local.navi.pl (ps103.poznan.sdi.tpnet.pl [217.97.72.103]) by goliath.sylaba.poznan.pl (8.12.8/8.12.8) with ESMTP id h6AECg6j021567; Thu, 10 Jul 2003 16:12:42 +0200 (CEST) Received: from venus.local.navi.pl (venus.local.navi.pl [127.0.0.1]) by venus.local.navi.pl (8.12.5/8.12.5) with ESMTP id h6AEDGFF011623; Thu, 10 Jul 2003 16:13:16 +0200 Subject: Re: Addendum to FAQ ? From: Olaf =?iso-8859-2?Q?Fr=B1czyk?= To: lambada@bertin.fr Cc: linux-xfs@oss.sgi.com In-Reply-To: <35009.172.16.22.251.1057845309.squirrel@webmail.bertin.fr> References: <35009.172.16.22.251.1057845309.squirrel@webmail.bertin.fr> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.8 (1.0.8-10) Date: 10 Jul 2003 16:13:16 +0200 Message-Id: <1057846396.10335.28.camel@venus> Mime-Version: 1.0 X-archive-position: 4611 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: olaf@cbk.poznan.pl Precedence: bulk X-list: linux-xfs On Thu, 2003-07-10 at 15:55, lambada@bertin.fr wrote: > Hi > > Every root logging is a potential proof of stupididy. > It happens that since I had a problem (probably due to Nvidia drivers) > with my xfs home partition, I typed mkfs.xfs and not fsck.xfs (by the > way, I should have done an xfs_repair). The slight difference with this > commands ruined my day and a little more than 15 days of work. xfsdump is your friend :) In my company we do full backup every day with incremental backups during the day. BTW. mkfs.xfs should tell you that you are going to format device with existing filesystem. If it didn't it is a bug. > 1) Even if I imagine that I have no luck to reconstruct my partition as it > is possible with ext2, I am asking if it possible to recover any files > (even in a flatted directory) I don't think so. Probably you could find someone who can get some data, but it will cost really much. And I suppose it will get in tens thousand of USD, so it depends how much valuable data you have erased. > 2) Perharp's it should be added > in http://oss.sgi.com/projects/xfs/faq.html#undelete that what does not > work with rm, does not work either with mkfs. I thought it is as clear for everybody as to not put you hard disks into the water. Should this be added in the FAQ? ;) > Thanks. > M Le Maudit > > -- > This email and any attached files are confidential and may be legally privileged. > If you are not the intended recipient, any disclosure, reproduction, > copying, distribution, or other dissemination or use of this communication > is strictly prohibited. > > > From owner-linux-xfs@oss.sgi.com Thu Jul 10 07:25:04 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 10 Jul 2003 07:25:26 -0700 (PDT) Received: from fecamp.bertin.fr (jussac.bertin.fr [212.234.8.106]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h6AEP22x003377 for ; Thu, 10 Jul 2003 07:25:03 -0700 Received: from localhost (localhost.localdomain [127.0.0.1]) by fecamp.bertin.fr (Postfix) with SMTP id 413FB2E8E5; Thu, 10 Jul 2003 16:09:12 +0200 (CEST) Received: from deauville.bertin.fr (deauville.bertin.fr [172.16.0.6]) by fecamp.bertin.fr (Postfix) with ESMTP id CA3D62E8CB; Thu, 10 Jul 2003 16:09:11 +0200 (CEST) Received: by deauville.bertin.fr (Postfix, from userid 48) id 8560D401D; Thu, 10 Jul 2003 16:22:20 +0200 (CEST) Received: from 172.16.22.251 (SquirrelMail authenticated user lambada) by webmail.bertin.fr with HTTP; Thu, 10 Jul 2003 16:22:20 +0200 (CEST) Message-ID: <35252.172.16.22.251.1057846940.squirrel@webmail.bertin.fr> In-Reply-To: <1057846396.10335.28.camel@venus> References: <35009.172.16.22.251.1057845309.squirrel@webmail.bertin.fr> <1057846396.10335.28.camel@venus> Date: Thu, 10 Jul 2003 16:22:20 +0200 (CEST) Subject: Re: Addendum to FAQ ? From: lambada@bertin.fr To: Olaf Fr=?iso-8859-1?Q?=B1czyk?= Cc: lambada@bertin.fr, linux-xfs@oss.sgi.com User-Agent: SquirrelMail/1.4.0 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 X-Priority: 3 Importance: Normal X-archive-position: 4612 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: lambada@bertin.fr Precedence: bulk X-list: linux-xfs > On Thu, 2003-07-10 at 15:55, lambada@bertin.fr wrote: >> Hi >> >> Every root logging is a potential proof of stupididy. >> It happens that since I had a problem (probably due to Nvidia drivers) >> with my xfs home partition, I typed mkfs.xfs and not fsck.xfs (by the >> way, I should have done an xfs_repair). The slight difference with this >> commands ruined my day and a little more than 15 days of work. > xfsdump is your friend :) In my company we do full backup every day with > incremental backups during the day. It is a laptop, I was rebooting to connect a firewire CD-RW and dump my partition onto a CD-R. > BTW. mkfs.xfs should tell you that you are going to format device with > existing filesystem. If it didn't it is a bug. In fact, the problem occured this way I think : 1) I upgraded both kernel and NVidia drivers, hum upgrade time to do a dump, 2) I rebooted 3) The mount /home failed 4) self.stupidity++ : I typed mkfs.xfs when I was thinking of fsck.xfs 5) I'm a sucker and I wrote to the xfs mailing list (c: >> 1) Even if I imagine that I have no luck to reconstruct my partition as >> it >> is possible with ext2, I am asking if it possible to recover any files >> (even in a flatted directory) > I don't think so. Probably you could find someone who can get some data, > but it will cost really much. And I suppose it will get in tens thousand > of USD, so it depends how much valuable data you have erased. Yes, I know. It worked once with an ext2 filesystem. >> 2) Perharp's it should be added >> in http://oss.sgi.com/projects/xfs/faq.html#undelete that what does not >> work with rm, does not work either with mkfs. > I thought it is as clear for everybody as to not put you hard disks into > the water. Should this be added in the FAQ? ;) Yes because some people are used to the unformat facility on MS systems and it only costs a line of FAQ : "by the way, unformat does not work nor exists" Thanks anyway... -- This email and any attached files are confidential and may be legally privileged. If you are not the intended recipient, any disclosure, reproduction, copying, distribution, or other dissemination or use of this communication is strictly prohibited. From owner-linux-xfs@oss.sgi.com Thu Jul 10 07:27:45 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 10 Jul 2003 07:27:53 -0700 (PDT) Received: from zok.sgi.com (zok.SGI.COM [204.94.215.101]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h6AERh2x003806 for ; Thu, 10 Jul 2003 07:27:43 -0700 Received: from flecktone.americas.sgi.com (flecktone.americas.sgi.com [192.48.203.135]) by zok.sgi.com (8.12.9/8.12.2/linux-outbound_gateway-1.2) with ESMTP id h6AERciY010097 for ; Thu, 10 Jul 2003 07:27:38 -0700 Received: from daisy-e236.americas.sgi.com (daisy-e236.americas.sgi.com [128.162.236.214]) by flecktone.americas.sgi.com (8.12.9/8.12.9/generic_config-1.2) with ESMTP id h6AERaqX8722051; Thu, 10 Jul 2003 09:27:36 -0500 (CDT) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.232.100]) by daisy-e236.americas.sgi.com (8.12.9/SGI-server-1.8) with ESMTP id h6AERWRn164008604; Thu, 10 Jul 2003 09:27:32 -0500 (CDT) Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id h6AERW006593; Thu, 10 Jul 2003 09:27:32 -0500 Subject: Re: Addendum to FAQ ? From: Steve Lord To: Olaf =?iso-8859-2?Q?Fr=B1czyk?= Cc: lambada@bertin.fr, linux-xfs@oss.sgi.com In-Reply-To: <1057846396.10335.28.camel@venus> References: <35009.172.16.22.251.1057845309.squirrel@webmail.bertin.fr> <1057846396.10335.28.camel@venus> Content-Type: text/plain; charset=iso-8859-2 Organization: Message-Id: <1057847251.29315.308.camel@jen.americas.sgi.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.4 Date: 10 Jul 2003 09:27:31 -0500 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id h6AERj2x003807 X-archive-position: 4613 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: lord@sgi.com Precedence: bulk X-list: linux-xfs On Thu, 2003-07-10 at 09:13, Olaf Fr±czyk wrote: > On Thu, 2003-07-10 at 15:55, lambada@bertin.fr wrote: > > Hi > > > > Every root logging is a potential proof of stupididy. > > It happens that since I had a problem (probably due to Nvidia drivers) > > with my xfs home partition, I typed mkfs.xfs and not fsck.xfs (by the > > way, I should have done an xfs_repair). The slight difference with this > > commands ruined my day and a little more than 15 days of work. > xfsdump is your friend :) In my company we do full backup every day with > incremental backups during the day. > BTW. mkfs.xfs should tell you that you are going to format device with > existing filesystem. If it didn't it is a bug. It should, that is what the -f option is for, of course, once you have run into it a few times you type -f without thinking about it. > > 1) Even if I imagine that I have no luck to reconstruct my partition as it > > is possible with ext2, I am asking if it possible to recover any files > > (even in a flatted directory) > I don't think so. Probably you could find someone who can get some data, > but it will cost really much. And I suppose it will get in tens thousand > of USD, so it depends how much valuable data you have erased. mkfs is probably simpler to recover from than rm -r -f, since rm will overwrite a lot of metadata. We actually did recover the names for a couple of hundred thousand files which ended up in lost+found the other week. If mkfs is all that has happened to the fs, then most of the state is still there, it is just disconnected - and the root inode is reset. Unfortunately it requires a lot of work with modified xfs_db executables to get back from this point - scan the disk looking for directory blocks via magic number, dump out the inode number/name pairs found. Go to the inode addresses, read the inodes, find the extent information, read the data and reassemble it. The work involved depends very much on what happened to the filesystem to lose data, which means we could write commands for xfs_db until we are blue in the face, and still not deal with the next case which comes up. Backup's are meant for circumstances like this. Steve -- Steve Lord voice: +1-651-683-3511 Principal Engineer, Filesystem Software email: lord@sgi.com From owner-linux-xfs@oss.sgi.com Thu Jul 10 08:10:09 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 10 Jul 2003 08:10:22 -0700 (PDT) Received: from smtpzilla5.xs4all.nl (smtpzilla5.xs4all.nl [194.109.127.141]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h6AFA72x004848 for ; Thu, 10 Jul 2003 08:10:08 -0700 Received: from auto-nb1.xs4all.nl (coltex.xs4all.nl [213.84.127.28]) by smtpzilla5.xs4all.nl (8.12.9/8.12.9) with ESMTP id h6AFA1b3034698; Thu, 10 Jul 2003 17:10:01 +0200 (CEST) Message-Id: <4.3.2.7.2.20030710170854.02bfeac0@pop.xs4all.nl> X-Sender: knuffie@pop.xs4all.nl X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 10 Jul 2003 17:09:31 +0200 To: lambada@bertin.fr, Olaf =?iso-8859-1?Q?Fr=B1czyk?= From: Seth Mos Subject: Re: Addendum to FAQ ? Cc: lambada@bertin.fr, linux-xfs@oss.sgi.com In-Reply-To: <35252.172.16.22.251.1057846940.squirrel@webmail.bertin.fr> References: <1057846396.10335.28.camel@venus> <35009.172.16.22.251.1057845309.squirrel@webmail.bertin.fr> <1057846396.10335.28.camel@venus> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-archive-position: 4614 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: knuffie@xs4all.nl Precedence: bulk X-list: linux-xfs At 16:22 10-7-2003 +0200, lambada@bertin.fr wrote: >Yes because some people are used to the unformat facility on MS systems >and it only costs a line of FAQ : "by the way, unformat does not work nor >exists" Valid. >Thanks anyway... I should really update the FAQ in some places... I know. Cheers -- Seth It might just be your lucky day, if you only knew. From owner-linux-xfs@oss.sgi.com Thu Jul 10 09:53:57 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 10 Jul 2003 09:54:16 -0700 (PDT) Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.9/8.12.9) with ESMTP id h6AGrv2x014482 for ; Thu, 10 Jul 2003 09:53:57 -0700 Received: (from xfs@localhost) by oss.sgi.com (8.12.9/8.12.8/Submit) id h6AGrvws014481 for linux-xfs@oss.sgi.com; Thu, 10 Jul 2003 09:53:57 -0700 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.9/8.12.9) with ESMTP id h6AGrt31014467 for ; Thu, 10 Jul 2003 09:53:55 -0700 Received: (from apache@localhost) by oss.sgi.com (8.12.9/8.12.8/Submit) id h6AG1FF8011399; Thu, 10 Jul 2003 09:01:15 -0700 Date: Thu, 10 Jul 2003 09:01:15 -0700 Message-Id: <200307101601.h6AG1FF8011399@oss.sgi.com> From: bugzilla-daemon@oss.sgi.com To: xfs-master@oss.sgi.com Subject: [Bug 260] excessive swapping X-Bugzilla-Reason: AssignedTo X-archive-position: 4615 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: bugzilla-daemon@oss.sgi.com Precedence: bulk X-list: linux-xfs http://oss.sgi.com/bugzilla/show_bug.cgi?id=260 ------- Additional Comments From cchan@outblaze.com 2003-10-07 09:01 PDT ------- >> The SGI XFS patches make changes to the VM code in the kernel. I have observed >> differences in VM behaviour between RH 2.4.20-xx kernels and those that have SGI >> XFS patches. >Just what VM changes do you ascribe to XFS? Hmm, are you saying that there are no changes to the VM code that is in the Linux kernel by XFS patches? >You state you have a redhat kernel with XFS changes applied, where >did it originate, and which XFS patches are you refering to exactly. Good question. I don't know where the src rpms come from...I'll ask my colleagues where they got the ones we are using/testing at the moment. FYI, I filed this in hopes of getting a kernel that does not have security/data losing/instability problems and has better performance. Stock Linux kernels don't cut it. The RH line of kernels are usually meeting these requirements. The RH 2.4.20-13 kernel (with whatever XFS patches my colleagues found) had major improvements over the plain RH 2.4.20-13 in some cases. I just noticed that the new mail server we put up with a RH 7.3 installation and a XFS patched kernel (RH 2.4.20-13) exhibited the swapping behaviour we found with loaded boxes that just had plain RH 2.4.20-13/18 kernels. Only less servere swapping than what I saw with plain RH 2.4.20-xx kernels. So if there are no VM code changes by the XFS patches (likely 1.2) then just close this 'bug'. If there are, then maybe you guys would like to look into this since you have the knowledge and understanding needed to work on VM code in the Linux kernel. ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From owner-linux-xfs@oss.sgi.com Thu Jul 10 19:53:59 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 10 Jul 2003 19:54:20 -0700 (PDT) Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.9/8.12.9) with ESMTP id h6B2rx2x001144 for ; Thu, 10 Jul 2003 19:53:59 -0700 Received: (from xfs@localhost) by oss.sgi.com (8.12.9/8.12.8/Submit) id h6B2rwK5001143 for linux-xfs@oss.sgi.com; Thu, 10 Jul 2003 19:53:58 -0700 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.9/8.12.9) with ESMTP id h6B2rv33001127 for ; Thu, 10 Jul 2003 19:53:57 -0700 Received: (from apache@localhost) by oss.sgi.com (8.12.9/8.12.8/Submit) id h6B2Twnl001042; Thu, 10 Jul 2003 19:29:58 -0700 Date: Thu, 10 Jul 2003 19:29:58 -0700 Message-Id: <200307110229.h6B2Twnl001042@oss.sgi.com> From: bugzilla-daemon@oss.sgi.com To: xfs-master@oss.sgi.com Subject: [Bug 258] Kernel (smp) lockup: ioctl(XFS_IOC_RESVSP); truncate() on fs with unwritten=1 X-Bugzilla-Reason: AssignedTo X-archive-position: 4616 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: bugzilla-daemon@oss.sgi.com Precedence: bulk X-list: linux-xfs http://oss.sgi.com/bugzilla/show_bug.cgi?id=258 ------- Additional Comments From mikes@av.com 2003-10-07 19:29 PDT ------- Hi Nathan, You're right, the machine does come back after a while (more than couple hours). The system is very unresponsive during that time (it seems that it only responds to ping, and nothing else). I don't know if this qualifies as a problem. The other weird thing is that most of the time the disk LEDs don't show any io activity, and the drives are "silent". There were only handful brief io activity periods during that time. Writing 10G file onto this raid0 array usually takes around couple minutes (~80 MB/sec). The result of the program was the file with preallocated extents (du -h showed 10GB), and ls -l showed 0 length (logical EOF). I was unable to delete the file, rm hanged with bdflush using 100% of 1 cpu, I waited couple hours and then did hard reset. The same program with 1GB file size doesn't seem to cause the problem. I'll try to run this test on a different raid or machine, just to verify that this behavior is not caused by some hardware problem. The original goal was just to explore space reservation behavior. It seem converting holes (sparse files) into unwritten extents is pretty fast, and doesn't cause lots of io (truncate(10GB); ioctl(XFS_IOC_RESVSP, 10G)) (looks like the fs just marks the extents), but reverse order of the operations (ioctl(XFS_IOC_RESVSP, 10G); truncate(10GB)) causes lots of io (extents zeroed out, instead of just being marked as unwritten). Thanks, -- Mike. ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From owner-linux-xfs@oss.sgi.com Fri Jul 11 01:10:25 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 11 Jul 2003 01:10:44 -0700 (PDT) Received: from tolkor.sgi.com ([198.149.18.6]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h6B8AO2x005982 for ; Fri, 11 Jul 2003 01:10:25 -0700 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.54.149]) by tolkor.sgi.com (8.12.9/8.12.2/linux-outbound_gateway-1.2) with ESMTP id h6B8SSmO000381 for ; Fri, 11 Jul 2003 03:28:29 -0500 Received: from snort.melbourne.sgi.com (localhost [127.0.0.1]) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id h6B8AGJA3250430 for ; Fri, 11 Jul 2003 18:10:16 +1000 (EST) Received: (from nathans@localhost) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id h6B8AFov1611732 for linux-xfs@oss.sgi.com; Fri, 11 Jul 2003 18:10:15 +1000 (EST) Date: Fri, 11 Jul 2003 18:10:15 +1000 (EST) From: Nathan Scott Message-Id: <200307110810.h6B8AFov1611732@snort.melbourne.sgi.com> To: linux-xfs@oss.sgi.com Subject: TAKE - max file size X-archive-position: 4617 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: nathans@snort.melbourne.sgi.com Precedence: bulk X-list: linux-xfs Fix couple of issues in max file size calculation, print big fs setting in banner too. Date: Fri Jul 11 01:09:19 PDT 2003 Workarea: snort.melbourne.sgi.com:/home/nathans/clean-2.4.x-xfs The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: xfs-linux:slinx:152972a linux/fs/xfs/linux/xfs_super.h - 1.51 linux/fs/xfs/linux/xfs_super.c - 1.264 From owner-linux-xfs@oss.sgi.com Fri Jul 11 07:35:13 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 11 Jul 2003 07:35:29 -0700 (PDT) Received: from zok.sgi.com (zok.SGI.COM [204.94.215.101]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h6BEZD2x020253 for ; Fri, 11 Jul 2003 07:35:13 -0700 Received: from flecktone.americas.sgi.com (flecktone.americas.sgi.com [192.48.203.135]) by zok.sgi.com (8.12.9/8.12.2/linux-outbound_gateway-1.2) with ESMTP id h6BEZ7iY009011 for ; Fri, 11 Jul 2003 07:35:07 -0700 Received: from daisy-e236.americas.sgi.com (daisy-e236.americas.sgi.com [128.162.236.214]) by flecktone.americas.sgi.com (8.12.9/8.12.9/generic_config-1.2) with ESMTP id h6BEZ6qX8904276 for ; Fri, 11 Jul 2003 09:35:07 -0500 (CDT) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.232.100]) by daisy-e236.americas.sgi.com (8.12.9/SGI-server-1.8) with ESMTP id h6BEZ6Rn167273940 for ; Fri, 11 Jul 2003 09:35:06 -0500 (CDT) Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id h6BEZ6311061; Fri, 11 Jul 2003 09:35:06 -0500 Subject: Problems with cvs trees right now From: Steve Lord To: linux-xfs@oss.sgi.com Content-Type: text/plain Content-Transfer-Encoding: 7bit Organization: Message-Id: <1057934106.11030.4.camel@jen.americas.sgi.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.4 Date: 11 Jul 2003 09:35:06 -0500 X-archive-position: 4618 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: lord@sgi.com Precedence: bulk X-list: linux-xfs Some code made it out into xfs without sufficient testing, if you update to cvs right now, you will experience hangs. Hope to get this fixed or backed out shortly. Steve -- Steve Lord voice: +1-651-683-3511 Principal Engineer, Filesystem Software email: lord@sgi.com From owner-linux-xfs@oss.sgi.com Fri Jul 11 12:53:20 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 11 Jul 2003 12:53:24 -0700 (PDT) Received: from zok.sgi.com (zok.SGI.COM [204.94.215.101]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h6BJrJ2x017439 for ; Fri, 11 Jul 2003 12:53:20 -0700 Received: from flecktone.americas.sgi.com (flecktone.americas.sgi.com [192.48.203.135]) by zok.sgi.com (8.12.9/8.12.2/linux-outbound_gateway-1.2) with ESMTP id h6BJrEiY031359 for ; Fri, 11 Jul 2003 12:53:14 -0700 Received: from daisy-e236.americas.sgi.com (daisy-e236.americas.sgi.com [128.162.236.214]) by flecktone.americas.sgi.com (8.12.9/8.12.9/generic_config-1.2) with ESMTP id h6BJqDqX8952817 for ; Fri, 11 Jul 2003 14:52:13 -0500 (CDT) Received: from sgi.com (chuckle.americas.sgi.com [128.162.241.66]) by daisy-e236.americas.sgi.com (8.12.9/SGI-server-1.8) with ESMTP id h6BJqDRn164025899 for ; Fri, 11 Jul 2003 14:52:13 -0500 (CDT) Received: from chuckle.americas.sgi.com (localhost [127.0.0.1]) by sgi.com (8.12.8/8.12.8) with ESMTP id h6BJqD9j031907 for ; Fri, 11 Jul 2003 14:52:13 -0500 Received: (from cattelan@localhost) by chuckle.americas.sgi.com (8.12.8/8.12.8/Submit) id h6BJqDPt031905 for linux-xfs@oss.sgi.com; Fri, 11 Jul 2003 14:52:13 -0500 Date: Fri, 11 Jul 2003 14:52:13 -0500 From: Russell Cattelan Message-Id: <200307111952.h6BJqDPt031905@chuckle.americas.sgi.com> Subject: TAKE - Remove kdb from 2.5 tree since it is non-functioning X-archive-position: 4619 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: cattelan@chuckle.americas.sgi.com Precedence: bulk X-list: linux-xfs Nuke kdb Date: Fri Jul 11 12:50:50 PDT 2003 Workarea: chuckle.americas.sgi.com:/go/xfs2/XFS/x2.5-xfs The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.5.x-xfs Modid: 2.5.x-xfs:slinx:153033a linux/Documentation/kdb/kdb_rd.man - 1.7 linux/Documentation/kdb/kdb_env.man - 1.5 linux/kdb/kdb_bt.c - 1.15 linux/Documentation/kdb/kdb_ll.man - 1.5 linux/kdb/kdb_bp.c - 1.14 linux/kdb/modules/kdbm_vm.c - 1.29 linux/kdb/Makefile - 1.20 linux/include/linux/kdbprivate.h - 1.22 linux/Documentation/kdb/kdb_md.man - 1.7 linux/include/linux/kdb.h - 1.25 linux/kdb/modules/Makefile - 1.18 linux/kdb/kdbsupport.c - 1.17 linux/kdb/kdbmain.c - 1.37 linux/include/linux/dis-asm.h - 1.12 linux/include/asm-i386/kdb.h - 1.15 linux/kdb/kdb_io.c - 1.17 linux/Documentation/kdb/kdb_ss.man - 1.6 linux/include/asm-i386/kdbprivate.h - 1.18 linux/arch/i386/kdb/kdba_id.c - 1.14 linux/Documentation/kdb/kdb.mm - 1.16 linux/Documentation/kdb/kdb_bp.man - 1.7 linux/Documentation/kdb/kdb_bt.man - 1.9 linux/kdb/kdb_id.c - 1.16 linux/arch/i386/kdb/kdbasupport.c - 1.25 linux/arch/i386/kdb/i386-dis.c - 1.8 linux/arch/i386/kdb/kdba_io.c - 1.21 linux/arch/i386/kdb/Makefile - 1.14 linux/arch/i386/kdb/kdba_bt.c - 1.18 linux/arch/i386/kdb/kdba_bp.c - 1.16 linux/kdb/modules/kdbm_pg.c - 1.70 linux/kdb/ChangeLog - 1.23 linux/kdb/kdb_cmds - 1.3 linux/arch/i386/kdb/bfd.h - 1.2 linux/arch/i386/kdb/ansidecl.h - 1.3 linux/arch/i386/kdb/ChangeLog - 1.10 linux/Documentation/kdb/slides - 1.2 linux/Documentation/kdb/kdb_sr.man - 1.2 From owner-linux-xfs@oss.sgi.com Fri Jul 11 13:05:43 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 11 Jul 2003 13:05:46 -0700 (PDT) Received: from tolkor.sgi.com ([198.149.18.6]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h6BK5g2x018506 for ; Fri, 11 Jul 2003 13:05:43 -0700 Received: from flecktone.americas.sgi.com (flecktone.americas.sgi.com [192.48.203.135]) by tolkor.sgi.com (8.12.9/8.12.2/linux-outbound_gateway-1.2) with ESMTP id h6BKNnmO019732 for ; Fri, 11 Jul 2003 15:23:49 -0500 Received: from daisy-e236.americas.sgi.com (daisy-e236.americas.sgi.com [128.162.236.214]) by flecktone.americas.sgi.com (8.12.9/8.12.9/generic_config-1.2) with ESMTP id h6BK5aqX8962475 for ; Fri, 11 Jul 2003 15:05:36 -0500 (CDT) Received: from sgi.com (chuckle.americas.sgi.com [128.162.241.66]) by daisy-e236.americas.sgi.com (8.12.9/SGI-server-1.8) with ESMTP id h6BK5aRn170090631 for ; Fri, 11 Jul 2003 15:05:36 -0500 (CDT) Received: from chuckle.americas.sgi.com (localhost [127.0.0.1]) by sgi.com (8.12.8/8.12.8) with ESMTP id h6BK5a9j032027 for ; Fri, 11 Jul 2003 15:05:36 -0500 Received: (from cattelan@localhost) by chuckle.americas.sgi.com (8.12.8/8.12.8/Submit) id h6BK5aXu032025 for linux-xfs@oss.sgi.com; Fri, 11 Jul 2003 15:05:36 -0500 Date: Fri, 11 Jul 2003 15:05:36 -0500 From: Russell Cattelan Message-Id: <200307112005.h6BK5aXu032025@chuckle.americas.sgi.com> Subject: TAKE - missed the modified files in the kdb nuke X-archive-position: 4620 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: cattelan@chuckle.americas.sgi.com Precedence: bulk X-list: linux-xfs Nuke kdb Date: Fri Jul 11 13:04:59 PDT 2003 Workarea: chuckle.americas.sgi.com:/go/xfs2/XFS/x2.5-xfs The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.5.x-xfs Modid: 2.5.x-xfs:slinx:153037a linux/kernel/sysctl.c - 1.69 linux/kernel/printk.c - 1.33 linux/init/main.c - 1.110 linux/include/asm-i386/ptrace.h - 1.12 linux/arch/i386/kernel/traps.c - 1.79 linux/arch/i386/kernel/smp.c - 1.59 linux/arch/i386/kernel/io_apic.c - 1.64 linux/arch/i386/kernel/entry.S - 1.81 linux/arch/i386/Makefile - 1.54 linux/Makefile - 1.250 linux/arch/i386/kernel/i8259.c - 1.41 linux/arch/i386/kernel/smpboot.c - 1.64 linux/drivers/usb/input/hid-core.c - 1.23 linux/drivers/usb/input/usbkbd.c - 1.15 linux/drivers/usb/host/uhci-hcd.c - 1.21 linux/drivers/serial/8250.c - 1.17 linux/include/linux/serial_core.h - 1.15 linux/arch/i386/kernel/reboot.c - 1.6 linux/arch/i386/Kconfig - 1.21 linux/arch/i386/kernel/cpu/mcheck/mce.c - 1.4 From owner-linux-xfs@oss.sgi.com Fri Jul 11 13:28:17 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 11 Jul 2003 13:28:20 -0700 (PDT) Received: from zok.sgi.com (zok.SGI.COM [204.94.215.101]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h6BKSH2x019738 for ; Fri, 11 Jul 2003 13:28:17 -0700 Received: from flecktone.americas.sgi.com (flecktone.americas.sgi.com [192.48.203.135]) by zok.sgi.com (8.12.9/8.12.2/linux-outbound_gateway-1.2) with ESMTP id h6BKSBiY005546 for ; Fri, 11 Jul 2003 13:28:11 -0700 Received: from daisy-e236.americas.sgi.com (daisy-e236.americas.sgi.com [128.162.236.214]) by flecktone.americas.sgi.com (8.12.9/8.12.9/generic_config-1.2) with ESMTP id h6BKRBqX8966140 for ; Fri, 11 Jul 2003 15:27:11 -0500 (CDT) Received: from penguin.americas.sgi.com (penguin.americas.sgi.com [128.162.240.135]) by daisy-e236.americas.sgi.com (8.12.9/SGI-server-1.8) with ESMTP id h6BKRBRn162414830 for ; Fri, 11 Jul 2003 15:27:11 -0500 (CDT) From: Steve Lord Received: by penguin.americas.sgi.com (8.11.6/SGI-client-1.7) id h6BKQUC20384; Fri, 11 Jul 2003 15:26:30 -0500 Message-Id: <200307112026.h6BKQUC20384@penguin.americas.sgi.com> Date: Fri, 11 Jul 2003 15:26:30 -0500 Subject: PARTIAL TAKE - Fix hang introduced yesterday To: linux-xfs@oss.sgi.com X-archive-position: 4621 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: lord@sgi.com Precedence: bulk X-list: linux-xfs Remove use after free of transaction structure for saving process state and fix leak of the FS_FSTRANS flag outside of a transaction. Date: Fri Jul 11 13:22:33 PDT 2003 Workarea: penguin.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: xfs-linux:slinx:153038a linux/fs/xfs/xfs_trans.c - 1.150 - Remove use after free of transaction structure for saving process state linux/fs/xfs/support/kmem.h - 1.19 - Do not update OSTATEP in PFLAGS_DUP From owner-linux-xfs@oss.sgi.com Fri Jul 11 13:48:46 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 11 Jul 2003 13:48:49 -0700 (PDT) Received: from zok.sgi.com (zok.SGI.COM [204.94.215.101]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h6BKmj2x020394 for ; Fri, 11 Jul 2003 13:48:45 -0700 Received: from flecktone.americas.sgi.com (flecktone.americas.sgi.com [192.48.203.135]) by zok.sgi.com (8.12.9/8.12.2/linux-outbound_gateway-1.2) with ESMTP id h6BKmdiY010129 for ; Fri, 11 Jul 2003 13:48:40 -0700 Received: from daisy-e236.americas.sgi.com (daisy-e236.americas.sgi.com [128.162.236.214]) by flecktone.americas.sgi.com (8.12.9/8.12.9/generic_config-1.2) with ESMTP id h6BKmdqX8970229 for ; Fri, 11 Jul 2003 15:48:39 -0500 (CDT) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.232.100]) by daisy-e236.americas.sgi.com (8.12.9/SGI-server-1.8) with ESMTP id h6BKmdRn157001759 for ; Fri, 11 Jul 2003 15:48:39 -0500 (CDT) Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id h6BKmdv18274; Fri, 11 Jul 2003 15:48:39 -0500 Subject: Re: Problems with cvs trees right now From: Steve Lord To: linux-xfs@oss.sgi.com In-Reply-To: <1057934106.11030.4.camel@jen.americas.sgi.com> References: <1057934106.11030.4.camel@jen.americas.sgi.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit Organization: Message-Id: <1057956518.11128.7.camel@jen.americas.sgi.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.4 Date: 11 Jul 2003 15:48:39 -0500 X-archive-position: 4622 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: lord@sgi.com Precedence: bulk X-list: linux-xfs On Fri, 2003-07-11 at 09:35, Steve Lord wrote: > Some code made it out into xfs without sufficient testing, if you > update to cvs right now, you will experience hangs. > > Hope to get this fixed or backed out shortly. This is fixed now. Steve -- Steve Lord voice: +1-651-683-3511 Principal Engineer, Filesystem Software email: lord@sgi.com From owner-linux-xfs@oss.sgi.com Fri Jul 11 14:05:52 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 11 Jul 2003 14:06:10 -0700 (PDT) Received: from tolkor.sgi.com ([198.149.18.6]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h6BL5p2x021096 for ; Fri, 11 Jul 2003 14:05:52 -0700 Received: from flecktone.americas.sgi.com (flecktone.americas.sgi.com [192.48.203.135]) by tolkor.sgi.com (8.12.9/8.12.2/linux-outbound_gateway-1.2) with ESMTP id h6BLNjmO026575 for ; Fri, 11 Jul 2003 16:23:45 -0500 Received: from daisy-e236.americas.sgi.com (daisy-e236.americas.sgi.com [128.162.236.214]) by flecktone.americas.sgi.com (8.12.9/8.12.9/generic_config-1.2) with ESMTP id h6BL5WqX8967445 for ; Fri, 11 Jul 2003 16:05:32 -0500 (CDT) Received: from penguin.americas.sgi.com (penguin.americas.sgi.com [128.162.240.135]) by daisy-e236.americas.sgi.com (8.12.9/SGI-server-1.8) with ESMTP id h6BL5WRn162466478 for ; Fri, 11 Jul 2003 16:05:32 -0500 (CDT) From: Steve Lord Received: by penguin.americas.sgi.com (8.11.6/SGI-client-1.7) id h6BL4pt09569; Fri, 11 Jul 2003 16:04:51 -0500 Message-Id: <200307112104.h6BL4pt09569@penguin.americas.sgi.com> Date: Fri, 11 Jul 2003 16:04:51 -0500 Subject: TAKE - merge up to 2.5.73 To: linux-xfs@oss.sgi.com X-archive-position: 4623 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: lord@sgi.com Precedence: bulk X-list: linux-xfs Time to play catch up with the 2.5 tree Date: Fri Jul 11 14:02:41 PDT 2003 Workarea: penguin.americas.sgi.com:/src/lord/xfs-linux.2.5 The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.5.x-xfs Modid: 2.5.x-xfs:slinx:153046a linux/Documentation/firmware_class/README - 1.1 linux/Documentation/firmware_class/firmware_sample_driver.c - 1.1 linux/Documentation/firmware_class/firmware_sample_firmware_class.c - 1.1 linux/Documentation/firmware_class/hotplug-script - 1.1 linux/include/asm-ia64/perfmon_default_smpl.h - 1.1 linux/arch/ia64/sn/io/platform_init/Makefile - 1.1 linux/include/asm-ia64/ioctl32.h - 1.1 linux/arch/ia64/sn/io/platform_init/irix_io_init.c - 1.1 linux/arch/ia64/sn/io/platform_init/sgi_io_init.c - 1.1 linux/arch/ia64/sn/io/sn2/kdba_io.c - 1.1 linux/arch/ia64/sn/kernel/idle.c - 1.1 linux/arch/ia64/sn/kernel/sn2/prominfo_proc.c - 1.1 linux/arch/ia64/sn/kernel/sn2/timer.c - 1.1 linux/drivers/acpi/asus_acpi.c - 1.1 linux/drivers/base/Kconfig - 1.1 linux/arch/ia64/sn/io/machvec/pci_dma.c - 1.1 linux/arch/ia64/sn/io/machvec/pci_bus_cvlink.c - 1.1 linux/arch/ia64/sn/io/machvec/pci.c - 1.1 linux/arch/ia64/sn/io/machvec/iomv.c - 1.1 linux/arch/ia64/sn/io/machvec/Makefile - 1.1 linux/arch/arm/common/amba.c - 1.1 linux/arch/arm/common/icst525.c - 1.1 linux/drivers/base/firmware_class.c - 1.1 linux/drivers/i2c/chips/lm78.c - 1.1 linux/drivers/input/mouse/logips2pp.c - 1.1 linux/drivers/input/mouse/logips2pp.h - 1.1 linux/drivers/pcmcia/yenta_socket.c - 1.1 linux/drivers/pcmcia/yenta_socket.h - 1.1 linux/drivers/scsi/scsi_typedefs.h - 1.1 linux/drivers/usb/net/ax8817x.c - 1.1 linux/fs/Kconfig.binfmt - 1.1 linux/arch/ia64/sn/io/hwgfs/ramfs.c - 1.1 linux/arch/ia64/sn/io/hwgfs/labelcl.c - 1.1 linux/arch/ia64/sn/io/hwgfs/invent_stub.c - 1.1 linux/arch/ia64/sn/io/hwgfs/interface.c - 1.1 linux/arch/ia64/sn/io/hwgfs/hcl_util.c - 1.1 linux/arch/ia64/sn/io/hwgfs/hcl.c - 1.1 linux/arch/i386/kernel/acpi/acpitable.c - 1.1 linux/arch/i386/kernel/acpi/acpitable.h - 1.1 linux/arch/ia64/sn/io/hwgfs/Makefile - 1.1 linux/arch/ia64/sn/io/drivers/ioconfig_bus.c - 1.1 linux/arch/ia64/sn/io/drivers/ifconfig_net.c - 1.1 linux/arch/ia64/sn/io/drivers/Makefile - 1.1 linux/arch/ia64/scripts/toolchain-flags - 1.1 linux/arch/ia64/scripts/check-segrel.lds - 1.1 linux/arch/ia64/scripts/check-segrel.S - 1.1 linux/include/scsi/scsi_tcq.h - 1.1 linux/include/scsi/scsi_request.h - 1.1 linux/include/scsi/scsi_host.h - 1.1 linux/include/scsi/scsi_eh.h - 1.1 linux/arch/i386/oprofile/nmi_timer_int.c - 1.1 linux/include/scsi/scsi_device.h - 1.1 linux/include/scsi/scsi_cmnd.h - 1.1 linux/arch/ia64/lib/xor.S - 1.1 linux/include/asm-arm/hardware/amba.h - 1.1 linux/include/asm-arm/hardware/icst525.h - 1.1 linux/include/asm-generic/statfs.h - 1.1 linux/arch/ia64/kernel/perfmon_default_smpl.c - 1.1 linux/arch/ia64/kernel/patch.c - 1.1 linux/include/asm-ia64/sn/hwgfs.h - 1.1 linux/include/linux/statfs.h - 1.1 linux/include/asm-ia64/patch.h - 1.1 linux/include/asm-ia64/ustack.h - 1.1 linux/arch/ia64/ia32/ia32priv.h - 1.1 linux/include/asm-ia64/sn/ioc4.h - 1.1 linux/arch/ia64/kernel/gate-data.S - 1.1 linux/arch/ia64/kernel/gate.lds.S - 1.1 linux/arch/ia64/kernel/asm-offsets.c - 1.1 linux/include/linux/firmware.h - 1.1 linux/net/x25/af_x25.c - 1.37 linux/net/unix/af_unix.c - 1.60 linux/net/sunrpc/svcsock.c - 1.33 linux/net/sunrpc/svc.c - 1.22 linux/net/sunrpc/sched.c - 1.41 linux/net/packet/af_packet.c - 1.45 linux/net/netsyms.c - 1.70 linux/net/netlink/af_netlink.c - 1.32 linux/net/irda/irttp.c - 1.24 linux/net/irda/irda_device.c - 1.33 linux/net/ipx/af_ipx.c - 1.40 linux/net/ipv6/udp.c - 1.44 linux/net/ipv6/tcp_ipv6.c - 1.55 linux/net/ipv6/raw.c - 1.37 linux/net/ipv6/ndisc.c - 1.36 linux/net/ipv6/mcast.c - 1.28 linux/net/ipv6/ip6_output.c - 1.25 linux/net/ipv6/icmp.c - 1.32 linux/net/ipv4/udp.c - 1.46 linux/net/ipv4/tcp_ipv4.c - 1.65 linux/net/ipv4/tcp.c - 1.59 linux/net/ipv4/raw.c - 1.36 linux/net/ipv4/ip_output.c - 1.49 linux/net/ipv4/igmp.c - 1.27 linux/net/ipv4/arp.c - 1.31 linux/net/ethernet/eth.c - 1.10 linux/net/core/skbuff.c - 1.36 linux/net/core/dev.c - 1.77 linux/mm/swap_state.c - 1.63 linux/mm/slab.c - 1.59 linux/kernel/sched.c - 1.104 linux/kernel/ksyms.c - 1.192 linux/kernel/kmod.c - 1.33 linux/kernel/fork.c - 1.93 linux/kernel/exit.c - 1.69 linux/kernel/acct.c - 1.27 linux/ipc/util.c - 1.24 linux/ipc/sem.c - 1.28 linux/include/net/tcp.h - 1.49 linux/include/net/sock.h - 1.50 linux/include/linux/vfs.h - 1.3 linux/include/linux/timex.h - 1.10 linux/include/linux/time.h - 1.17 linux/include/linux/tcp.h - 1.17 linux/include/linux/sunrpc/svc.h - 1.16 linux/include/linux/smbno.h - 1.7 linux/include/linux/skbuff.h - 1.35 linux/include/linux/sem.h - 1.12 linux/include/linux/sched.h - 1.106 linux/include/linux/pci.h - 1.77 linux/include/linux/nfsd/xdr3.h - 1.9 linux/include/linux/nfsd/xdr.h - 1.10 linux/include/linux/nfsd/nfsd.h - 1.22 linux/include/linux/netdevice.h - 1.48 linux/include/linux/msdos_fs.h - 1.29 linux/include/linux/isdn_ppp.h - 1.15 linux/include/linux/isdn.h - 1.34 linux/include/linux/fs.h - 1.216 linux/include/linux/coda_psdev.h - 1.11 linux/include/linux/bitops.h - 1.7 linux/include/asm-sparc64/statfs.h - 1.4 linux/include/asm-sparc64/smp.h - 1.19 linux/include/asm-sparc/statfs.h - 1.3 linux/include/asm-ppc/statfs.h - 1.5 linux/include/asm-ppc/smp.h - 1.19 linux/include/asm-m68k/statfs.h - 1.3 linux/include/asm-i386/unistd.h - 1.37 linux/include/asm-i386/uaccess.h - 1.25 linux/include/asm-i386/statfs.h - 1.3 linux/include/asm-i386/smp.h - 1.30 linux/include/asm-i386/processor.h - 1.55 linux/include/asm-arm/statfs.h - 1.3 linux/include/asm-arm/proc-armv/uaccess.h - 1.14 linux/include/asm-alpha/unistd.h - 1.31 linux/include/asm-alpha/statfs.h - 1.3 linux/include/asm-alpha/smp.h - 1.22 linux/include/asm-alpha/pci.h - 1.22 linux/fs/ufs/super.c - 1.42 linux/fs/sysv/inode.c - 1.39 linux/fs/super.c - 1.102 linux/fs/smbfs/proc.c - 1.29 linux/fs/smbfs/inode.c - 1.47 linux/fs/romfs/inode.c - 1.44 linux/fs/qnx4/inode.c - 1.44 linux/fs/proc/base.c - 1.53 linux/fs/open.c - 1.50 linux/fs/ntfs/super.c - 1.26 linux/fs/nfsd/vfs.c - 1.69 linux/fs/nfsd/nfsxdr.c - 1.23 linux/fs/nfsd/nfssvc.c - 1.35 linux/fs/nfsd/nfsproc.c - 1.33 linux/fs/nfsd/nfsfh.c - 1.50 linux/fs/nfsd/nfsctl.c - 1.43 linux/fs/nfsd/nfs3xdr.c - 1.38 linux/fs/nfsd/export.c - 1.54 linux/fs/nfsd/auth.c - 1.4 linux/fs/nfs/inode.c - 1.67 linux/fs/ncpfs/sock.c - 1.20 linux/fs/ncpfs/inode.c - 1.45 linux/fs/namei.c - 1.72 linux/fs/minix/inode.c - 1.42 linux/fs/lockd/svc.c - 1.26 linux/fs/isofs/inode.c - 1.44 linux/fs/hfs/super.c - 1.22 linux/fs/fat/inode.c - 1.60 linux/fs/ext2/super.c - 1.48 linux/fs/coda/upcall.c - 1.22 linux/fs/coda/inode.c - 1.32 linux/fs/binfmt_elf.c - 1.58 linux/fs/affs/super.c - 1.34 linux/fs/adfs/super.c - 1.28 linux/drivers/scsi/wd7000.c - 1.28 linux/drivers/scsi/ultrastor.c - 1.21 linux/drivers/scsi/u14-34f.h - 1.18 linux/drivers/scsi/u14-34f.c - 1.34 linux/drivers/scsi/t128.c - 1.16 linux/drivers/scsi/sym53c416.c - 1.20 linux/drivers/scsi/st.c - 1.67 linux/drivers/scsi/sr.c - 1.69 linux/drivers/scsi/seagate.c - 1.27 linux/drivers/scsi/sd.c - 1.89 linux/drivers/scsi/scsi_syms.c - 1.34 linux/drivers/scsi/scsi_proc.c - 1.20 linux/drivers/scsi/scsi_module.c - 1.6 linux/drivers/scsi/scsi_ioctl.c - 1.31 linux/drivers/scsi/scsi_error.c - 1.45 linux/drivers/scsi/scsi_debug.c - 1.36 linux/drivers/scsi/scsi.h - 1.53 linux/drivers/scsi/scsi.c - 1.78 linux/drivers/scsi/qlogicfas.c - 1.23 linux/drivers/scsi/psi240i.c - 1.14 linux/drivers/scsi/ppa.c - 1.27 linux/drivers/scsi/pci2220i.c - 1.32 linux/drivers/scsi/pci2000.c - 1.29 linux/drivers/scsi/pas16.c - 1.17 linux/drivers/scsi/mvme16x.c - 1.10 linux/drivers/scsi/mesh.c - 1.16 linux/drivers/scsi/megaraid.h - 1.22 linux/drivers/scsi/megaraid.c - 1.48 linux/drivers/scsi/mac_esp.c - 1.16 linux/drivers/scsi/jazz_esp.c - 1.10 linux/drivers/scsi/inia100.c - 1.30 linux/drivers/scsi/ini9100u.c - 1.25 linux/drivers/scsi/imm.c - 1.26 linux/drivers/scsi/ide-scsi.c - 1.55 linux/drivers/scsi/ibmmca.c - 1.27 linux/drivers/scsi/hosts.h - 1.42 linux/drivers/scsi/hosts.c - 1.47 linux/drivers/scsi/fdomain.c - 1.33 linux/drivers/scsi/fd_mcs.c - 1.16 linux/drivers/scsi/esp.c - 1.36 linux/drivers/scsi/eata.h - 1.18 linux/drivers/scsi/eata.c - 1.38 linux/drivers/scsi/dtc.c - 1.16 linux/drivers/scsi/constants.c - 1.16 linux/drivers/scsi/bvme6000.c - 1.8 linux/drivers/scsi/blz1230.c - 1.14 linux/drivers/scsi/atp870u.h - 1.12 linux/drivers/scsi/atp870u.c - 1.29 linux/drivers/scsi/amiga7xx.c - 1.12 linux/drivers/scsi/aha1740.c - 1.19 linux/drivers/scsi/aha1542.c - 1.37 linux/drivers/scsi/aha152x.c - 1.42 linux/drivers/scsi/NCR53c406a.c - 1.21 linux/drivers/scsi/AM53C974.c - 1.22 linux/drivers/pci/quirks.c - 1.39 linux/drivers/pci/proc.c - 1.35 linux/drivers/net/shaper.c - 1.26 linux/drivers/net/rcpci45.c - 1.29 linux/drivers/net/plip.c - 1.28 linux/drivers/net/pcnet32.c - 1.45 linux/drivers/net/myri_sbus.c - 1.21 linux/drivers/net/hamradio/baycom_epp.c - 1.27 linux/drivers/isdn/sc/Makefile - 1.8 linux/drivers/isdn/pcbit/Makefile - 1.8 linux/drivers/isdn/isdnloop/Makefile - 1.7 linux/drivers/isdn/hisax/Makefile - 1.26 linux/drivers/isdn/act2000/Makefile - 1.9 linux/drivers/char/vt.c - 1.40 linux/drivers/char/keyboard.c - 1.37 linux/drivers/block/rd.c - 1.74 linux/drivers/block/ll_rw_blk.c - 1.135 linux/arch/sparc64/kernel/time.c - 1.35 linux/arch/sparc64/defconfig - 1.96 linux/arch/sparc/kernel/time.c - 1.28 linux/arch/i386/mm/init.c - 1.57 linux/arch/i386/kernel/traps.c - 1.80 linux/arch/i386/kernel/time.c - 1.42 linux/arch/i386/kernel/setup.c - 1.95 linux/arch/i386/kernel/process.c - 1.72 linux/arch/i386/kernel/entry.S - 1.82 linux/arch/arm/mm/mm-armv.c - 1.34 linux/arch/arm/mm/fault-armv.c - 1.31 linux/arch/alpha/kernel/traps.c - 1.31 linux/arch/alpha/kernel/osf_sys.c - 1.40 linux/arch/alpha/kernel/entry.S - 1.38 linux/arch/alpha/kernel/alpha_ksyms.c - 1.44 linux/Makefile - 1.251 linux/MAINTAINERS - 1.142 linux/net/decnet/af_decnet.c - 1.43 linux/include/linux/efs_fs.h - 1.14 linux/fs/hpfs/super.c - 1.26 linux/fs/hpfs/hpfs_fn.h - 1.23 linux/fs/efs/super.c - 1.22 linux/drivers/isdn/eicon/eicon_isa.c - 1.11 linux/drivers/isdn/eicon/Makefile - 1.10 linux/drivers/char/raw.c - 1.39 linux/include/asm-i386/apic.h - 1.23 linux/drivers/net/ppp_async.c - 1.19 linux/drivers/net/hamradio/yam.c - 1.25 linux/fs/partitions/check.c - 1.71 linux/fs/partitions/acorn.h - 1.6 linux/fs/partitions/acorn.c - 1.18 linux/drivers/scsi/sun3x_esp.c - 1.11 linux/drivers/isdn/divert/Makefile - 1.7 linux/drivers/net/sis900.c - 1.47 linux/net/atm/svc.c - 1.16 linux/net/atm/signaling.c - 1.13 linux/net/atm/resources.h - 1.5 linux/net/atm/resources.c - 1.13 linux/net/atm/pvc.c - 1.14 linux/net/atm/mpoa_caches.c - 1.4 linux/net/atm/lec.c - 1.23 linux/net/atm/common.h - 1.7 linux/net/atm/common.c - 1.25 linux/net/atm/clip.c - 1.18 linux/include/linux/atmdev.h - 1.17 linux/arch/arm/vmlinux-armv.lds.in - 1.30 linux/drivers/scsi/ips.c - 1.42 linux/drivers/pcmcia/rsrc_mgr.c - 1.23 linux/drivers/pcmcia/i82365.c - 1.42 linux/drivers/pcmcia/cs_internal.h - 1.19 linux/drivers/pcmcia/cs.c - 1.41 linux/drivers/pcmcia/cistpl.c - 1.22 linux/drivers/pcmcia/Makefile - 1.25 linux/drivers/pcmcia/yenta.h - 1.7 linux/fs/udf/super.c - 1.38 linux/include/linux/spinlock.h - 1.27 linux/include/asm-sparc64/pci.h - 1.19 linux/include/asm-ppc/pci.h - 1.23 linux/include/linux/acpi.h - 1.38 linux/include/linux/pci_ids.h - 1.93 linux/drivers/net/wan/syncppp.c - 1.18 linux/drivers/scsi/sim710.c - 1.16 linux/drivers/scsi/dec_esp.c - 1.9 linux/drivers/net/pcmcia/xirc2ps_cs.c - 1.25 linux/include/linux/highmem.h - 1.32 linux/fs/bfs/inode.c - 1.32 linux/fs/proc/kcore.c - 1.16 linux/kernel/timer.c - 1.48 linux/drivers/scsi/scsi_lib.c - 1.66 linux/drivers/pcmcia/yenta.c - 1.43 linux/fs/cramfs/inode.c - 1.37 linux/include/linux/input.h - 1.28 linux/drivers/telephony/ixj.h - 1.10 linux/drivers/telephony/ixj.c - 1.30 linux/drivers/pnp/quirks.c - 1.15 linux/drivers/char/moxa.c - 1.20 linux/drivers/scsi/scsi_scan.c - 1.50 linux/arch/ia64/kernel/head.S - 1.16 linux/arch/ia64/kernel/gate.S - 1.16 linux/arch/ia64/kernel/entry.h - 1.7 linux/arch/ia64/kernel/entry.S - 1.38 linux/arch/ia64/kernel/efi_stub.S - 1.6 linux/arch/ia64/kernel/acpi.c - 1.23 linux/arch/ia64/kernel/Makefile - 1.22 linux/arch/ia64/ia32/sys_ia32.c - 1.46 linux/arch/ia64/ia32/ia32_support.c - 1.10 linux/arch/ia64/ia32/ia32_signal.c - 1.15 linux/arch/ia64/ia32/ia32_entry.S - 1.25 linux/arch/ia64/ia32/binfmt_elf32.c - 1.19 linux/arch/ia64/vmlinux.lds.S - 1.26 linux/arch/ia64/tools/print_offsets.c - 1.18 linux/arch/ia64/boot/bootloader.c - 1.7 linux/arch/ia64/Makefile - 1.28 linux/arch/ia64/tools/print_offsets.awk - 1.8 linux/arch/ia64/kernel/init_task.c - 1.8 linux/arch/ia64/kernel/irq.c - 1.30 linux/arch/ia64/tools/Makefile - 1.14 linux/arch/ia64/sn/Makefile - 1.7 linux/arch/ia64/kernel/setup.c - 1.27 linux/arch/ia64/kernel/signal.c - 1.26 linux/arch/ia64/kernel/sys_ia64.c - 1.20 linux/arch/ia64/kernel/time.c - 1.24 linux/arch/ia64/kernel/traps.c - 1.23 linux/arch/ia64/kernel/unaligned.c - 1.15 linux/arch/ia64/kernel/unwind.c - 1.16 linux/arch/ia64/lib/Makefile - 1.20 linux/arch/ia64/kernel/ivt.S - 1.22 linux/arch/ia64/kernel/ptrace.c - 1.24 linux/arch/ia64/kernel/process.c - 1.29 linux/arch/ia64/kernel/perfmon.c - 1.26 linux/arch/ia64/mm/tlb.c - 1.17 linux/arch/ia64/kernel/mca.c - 1.21 linux/arch/ia64/mm/init.c - 1.29 linux/arch/ia64/mm/fault.c - 1.17 linux/arch/ia64/kernel/mca_asm.S - 1.12 linux/arch/ia64/kernel/pal.S - 1.11 linux/include/asm-ia64/sigcontext.h - 1.6 linux/include/asm-ia64/io.h - 1.13 linux/include/asm-ia64/ia32.h - 1.20 linux/include/asm-ia64/elf.h - 1.10 linux/include/asm-ia64/a.out.h - 1.6 linux/include/asm-ia64/siginfo.h - 1.18 linux/include/asm-ia64/mca_asm.h - 1.8 linux/include/asm-ia64/smp.h - 1.15 linux/include/asm-ia64/sal.h - 1.16 linux/include/asm-ia64/processor.h - 1.34 linux/include/asm-ia64/pgtable.h - 1.24 linux/include/asm-ia64/pgalloc.h - 1.17 linux/include/asm-ia64/machvec.h - 1.15 linux/include/asm-ia64/pci.h - 1.21 linux/include/asm-ia64/page.h - 1.23 linux/include/asm-ia64/resource.h - 1.3 linux/include/asm-ia64/ptrace_offsets.h - 1.7 linux/include/asm-ia64/ptrace.h - 1.15 linux/include/asm-ia64/mca.h - 1.10 linux/include/asm-ia64/spinlock.h - 1.15 linux/include/asm-ia64/unistd.h - 1.31 linux/include/asm-ia64/timex.h - 1.5 linux/include/asm-ia64/unwind.h - 1.8 linux/include/asm-ia64/system.h - 1.27 linux/include/asm-ia64/statfs.h - 1.2 linux/drivers/isdn/hysdn/Makefile - 1.8 linux/drivers/isdn/hysdn/hysdn_proclog.c - 1.15 linux/net/econet/af_econet.c - 1.23 linux/include/linux/usb.h - 1.61 linux/net/ipv4/netfilter/ipt_MIRROR.c - 1.12 linux/arch/ia64/kernel/smpboot.c - 1.21 linux/arch/ia64/kernel/minstate.h - 1.11 linux/arch/ia64/ia32/ia32_traps.c - 1.8 linux/drivers/net/pppoe.c - 1.30 linux/include/asm-s390/smp.h - 1.9 linux/fs/xfs/xfs_vfsops.c - 1.416 linux/fs/xfs/linux/xfs_vfs.c - 1.50 linux/fs/xfs/linux/xfs_super.c - 1.277 linux/drivers/usb/storage/usb.h - 1.23 linux/drivers/usb/storage/usb.c - 1.40 linux/drivers/usb/storage/transport.h - 1.21 linux/drivers/usb/storage/transport.c - 1.45 linux/drivers/usb/storage/scsiglue.h - 1.5 linux/drivers/usb/storage/scsiglue.c - 1.34 linux/drivers/usb/storage/protocol.h - 1.6 linux/drivers/usb/storage/protocol.c - 1.13 linux/include/asm-ia64/asmmacro.h - 1.6 linux/include/asm-arm/memory.h - 1.9 linux/drivers/acpi/hardware/hwregs.c - 1.23 linux/arch/ia64/ia32/ia32_ioctl.c - 1.11 linux/drivers/acpi/dispatcher/dsmthdat.c - 1.19 linux/arch/ia64/kernel/ia64_ksyms.c - 1.21 linux/drivers/acpi/Makefile - 1.25 linux/include/linux/serio.h - 1.11 linux/fs/xfs/linux/xfs_vfs.h - 1.42 linux/net/ipv4/tcp_minisocks.c - 1.29 linux/arch/arm/tools/mach-types - 1.27 linux/drivers/net/sundance.c - 1.26 linux/arch/ia64/lib/idiv64.S - 1.4 linux/net/irda/irnet/irnet_ppp.c - 1.14 linux/net/irda/irnet/irnet_irda.c - 1.16 linux/include/asm-alpha/xor.h - 1.3 linux/include/asm-ia64/xor.h - 1.2 linux/include/asm-sparc/xor.h - 1.3 linux/include/asm-sparc64/xor.h - 1.3 linux/arch/alpha/lib/memmove.S - 1.4 linux/include/asm-parisc/smp.h - 1.4 linux/include/asm-parisc/statfs.h - 1.2 linux/drivers/acpi/tables/tbconvrt.c - 1.19 linux/mm/shmem.c - 1.61 linux/arch/ia64/sn/io/stubs.c - 1.5 linux/include/asm-ia64/sn/addrs.h - 1.6 linux/include/asm-ia64/sn/alenlist.h - 1.5 linux/include/asm-ia64/sn/arc/hinv.h - 1.4 linux/include/asm-ia64/sn/arc/types.h - 1.3 linux/include/asm-ia64/sn/arch.h - 1.5 linux/include/asm-ia64/sn/cdl.h - 1.4 linux/include/asm-ia64/sn/clksupport.h - 1.4 linux/include/asm-ia64/sn/dmamap.h - 1.4 linux/include/asm-ia64/sn/driver.h - 1.3 linux/include/asm-ia64/sn/eeprom.h - 1.6 linux/include/asm-ia64/sn/gda.h - 1.4 linux/include/asm-ia64/sn/hack.h - 1.5 linux/include/asm-ia64/sn/hcl.h - 1.4 linux/include/asm-ia64/sn/hcl_util.h - 1.3 linux/include/asm-ia64/sn/intr.h - 1.5 linux/include/asm-ia64/sn/intr_public.h - 1.4 linux/include/asm-ia64/sn/invent.h - 1.4 linux/include/asm-ia64/sn/io.h - 1.5 linux/include/asm-ia64/sn/ioc3.h - 1.3 linux/include/asm-ia64/sn/ioerror.h - 1.6 linux/include/asm-ia64/sn/ioerror_handling.h - 1.4 linux/include/asm-ia64/sn/iograph.h - 1.5 linux/include/asm-ia64/sn/klconfig.h - 1.6 linux/include/asm-ia64/sn/kldir.h - 1.4 linux/include/asm-ia64/sn/ksys/elsc.h - 1.5 linux/include/asm-ia64/sn/ksys/l1.h - 1.5 linux/include/asm-ia64/sn/labelcl.h - 1.3 linux/include/asm-ia64/sn/module.h - 1.6 linux/include/asm-ia64/sn/nic.h - 1.3 linux/include/asm-ia64/sn/xtalk/xwidget.h - 1.4 linux/include/asm-ia64/sn/xtalk/xtalkaddrs.h - 1.4 linux/include/asm-ia64/sn/xtalk/xtalk_private.h - 1.5 linux/include/asm-ia64/sn/xtalk/xtalk.h - 1.5 linux/include/asm-ia64/sn/xtalk/xswitch.h - 1.3 linux/include/asm-ia64/sn/xtalk/xbow_info.h - 1.3 linux/include/asm-ia64/sn/xtalk/xbow.h - 1.5 linux/include/asm-ia64/sn/vector.h - 1.4 linux/include/asm-ia64/sn/types.h - 1.5 linux/include/asm-ia64/sn/systeminfo.h - 1.3 linux/include/asm-ia64/sn/sn_private.h - 1.4 linux/include/asm-ia64/sn/sn_fru.h - 1.4 linux/include/asm-ia64/sn/sn_cpuid.h - 1.6 linux/include/asm-ia64/sn/sn1/slotnum.h - 1.4 linux/include/asm-ia64/sn/sn1/ip27config.h - 1.4 linux/arch/ia64/sn/io/Makefile - 1.12 linux/arch/ia64/sn/io/alenlist.c - 1.5 linux/arch/ia64/sn/io/cdl.c - 1.5 linux/arch/ia64/sn/io/eeprom.c - 1.4 linux/arch/ia64/sn/io/hcl.c - 1.9 linux/arch/ia64/sn/io/hcl_util.c - 1.5 linux/arch/ia64/sn/io/hubdev.c - 1.5 linux/arch/ia64/sn/io/hubspc.c - 1.6 linux/arch/ia64/sn/io/invent.c - 1.5 linux/arch/ia64/sn/io/io.c - 1.6 linux/arch/ia64/sn/io/klconflib.c - 1.6 linux/arch/ia64/sn/io/klgraph.c - 1.4 linux/arch/ia64/sn/io/klgraph_hack.c - 1.6 linux/arch/ia64/sn/io/l1.c - 1.8 linux/arch/ia64/sn/io/l1_command.c - 1.5 linux/arch/ia64/sn/io/labelcl.c - 1.5 linux/arch/ia64/sn/io/ml_SN_init.c - 1.4 linux/arch/ia64/sn/io/ml_iograph.c - 1.4 linux/arch/ia64/sn/io/module.c - 1.4 linux/arch/ia64/sn/io/pci.c - 1.6 linux/arch/ia64/sn/io/pci_bus_cvlink.c - 1.7 linux/arch/ia64/sn/io/pci_dma.c - 1.7 linux/arch/ia64/sn/io/pciio.c - 1.4 linux/arch/ia64/sn/io/sgi_if.c - 1.5 linux/arch/ia64/sn/io/sgi_io_init.c - 1.5 linux/arch/ia64/sn/io/sgi_io_sim.c - 1.5 linux/include/asm-ia64/sn/nodepda.h - 1.5 linux/arch/ia64/sn/io/xbow.c - 1.6 linux/arch/ia64/sn/io/xswitch.c - 1.5 linux/arch/ia64/sn/io/xtalk.c - 1.6 linux/include/asm-ia64/sn/sn1/hubxb_next.h - 1.4 linux/include/asm-ia64/sn/sn1/hubxb.h - 1.3 linux/include/asm-ia64/sn/sn1/hubpi_next.h - 1.4 linux/include/asm-ia64/sn/sn1/hubpi.h - 1.3 linux/include/asm-ia64/sn/sn1/hubni_next.h - 1.3 linux/include/asm-ia64/sn/sn1/hubni.h - 1.3 linux/include/asm-ia64/sn/sn1/hubmd_next.h - 1.4 linux/include/asm-ia64/sn/sn1/hubmd.h - 1.4 linux/include/asm-ia64/sn/sn1/hublb_next.h - 1.3 linux/include/asm-ia64/sn/sn1/hublb.h - 1.3 linux/include/asm-ia64/sn/sn1/hubio_next.h - 1.4 linux/include/asm-ia64/sn/sn1/hubio.h - 1.3 linux/include/asm-ia64/sn/sn1/hubdev.h - 1.3 linux/include/asm-ia64/sn/sn1/bedrock.h - 1.4 linux/include/asm-ia64/sn/sn1/arch.h - 1.3 linux/include/asm-ia64/sn/sn1/addrs.h - 1.5 linux/include/asm-ia64/sn/slotnum.h - 1.4 linux/include/asm-ia64/sn/sgi.h - 1.5 linux/include/asm-ia64/sn/router.h - 1.5 linux/include/asm-ia64/sn/prio.h - 1.3 linux/include/asm-ia64/sn/pio.h - 1.4 linux/include/asm-ia64/sn/pci/pciio_private.h - 1.5 linux/include/asm-ia64/sn/pci/pciio.h - 1.5 linux/include/asm-ia64/sn/pci/pcibr_private.h - 1.7 linux/include/asm-ia64/sn/pci/pcibr.h - 1.6 linux/include/asm-ia64/sn/pci/pci_defs.h - 1.4 linux/include/asm-ia64/sn/pci/pci_bus_cvlink.h - 1.5 linux/include/asm-ia64/sn/pci/bridge.h - 1.7 linux/fs/reiserfs/super.c - 1.36 linux/drivers/acpi/hardware/hwsleep.c - 1.18 linux/drivers/usb/storage/unusual_devs.h - 1.22 linux/include/asm-cris/statfs.h - 1.2 linux/include/net/syncppp.h - 1.3 linux/net/wanrouter/af_wanpipe.c - 1.20 linux/include/asm-ia64/kregs.h - 1.5 linux/include/asm-ia64/perfmon.h - 1.11 linux/include/asm-ia64/sn/pci/pciba.h - 1.4 linux/include/asm-ia64/sn/sn_sal.h - 1.4 linux/include/asm-ia64/sn/sv.h - 1.4 linux/arch/ia64/sn/io/pciba.c - 1.7 linux/fs/freevxfs/vxfs_super.c - 1.15 linux/net/bluetooth/af_bluetooth.c - 1.18 linux/drivers/acpi/executer/exstore.c - 1.18 linux/drivers/acpi/utilities/utmisc.c - 1.19 linux/drivers/net/wireless/airo.c - 1.30 linux/drivers/acpi/executer/exutils.c - 1.15 linux/drivers/acpi/executer/exsystem.c - 1.10 linux/drivers/isdn/tpam/tpam_queues.c - 1.5 linux/drivers/isdn/tpam/Makefile - 1.5 linux/drivers/scsi/pcmcia/nsp_cs.c - 1.22 linux/drivers/ieee1394/sbp2.c - 1.25 linux/drivers/usb/storage/isd200.c - 1.17 linux/arch/ia64/ia32/ia32_ldt.c - 1.3 linux/arch/arm/mach-integrator/cpu.c - 1.14 linux/arch/arm/mach-sa1100/irq.c - 1.14 linux/arch/arm/mach-sa1100/generic.c - 1.15 linux/drivers/scsi/dpt_i2o.c - 1.25 linux/drivers/scsi/53c700.c - 1.19 linux/drivers/scsi/53c700.h - 1.11 linux/drivers/scsi/NCR_D700.c - 1.9 linux/drivers/scsi/lasi700.c - 1.9 linux/arch/i386/kernel/nmi.c - 1.17 linux/include/asm-ia64/tlb.h - 1.10 linux/fs/smbfs/proto.h - 1.10 linux/arch/arm/lib/lib1funcs.S - 1.3 linux/drivers/message/i2o/i2o_scsi.c - 1.14 linux/drivers/acpi/executer/exoparg1.c - 1.16 linux/fs/jbd/journal.c - 1.24 linux/fs/ext3/file.c - 1.10 linux/fs/ext3/ialloc.c - 1.24 linux/fs/ext3/inode.c - 1.38 linux/fs/ext3/ioctl.c - 1.9 linux/fs/ext3/namei.c - 1.21 linux/fs/ext3/super.c - 1.37 linux/include/linux/journal-head.h - 1.2 linux/include/linux/jbd.h - 1.18 linux/fs/jbd/recovery.c - 1.8 linux/include/linux/ext3_jbd.h - 1.11 linux/include/linux/ext3_fs_sb.h - 1.6 linux/include/linux/ext3_fs_i.h - 1.6 linux/include/linux/ext3_fs.h - 1.18 linux/fs/jbd/revoke.c - 1.11 linux/fs/jbd/transaction.c - 1.18 linux/fs/ext3/balloc.c - 1.12 linux/fs/jbd/commit.c - 1.12 linux/fs/ext3/bitmap.c - 1.3 linux/fs/ext3/dir.c - 1.12 linux/fs/ext3/acl.c - 1.9 linux/fs/jbd/checkpoint.c - 1.8 linux/include/linux/gfp.h - 1.12 linux/drivers/block/cciss_scsi.c - 1.13 linux/drivers/usb/Makefile.lib - 1.4 linux/drivers/base/Makefile - 1.15 linux/drivers/pci/pci-driver.c - 1.16 linux/drivers/input/joystick/gamecon.c - 1.5 linux/drivers/input/gameport/gameport.c - 1.8 linux/drivers/input/joystick/sidewinder.c - 1.5 linux/drivers/input/serio/serio.c - 1.10 linux/sound/pci/korg1212/korg1212.c - 1.21 linux/include/asm-x86_64/smp.h - 1.8 linux/include/asm-x86_64/statfs.h - 1.2 linux/arch/ppc64/kernel/process.c - 1.18 linux/include/asm-ppc64/statfs.h - 1.2 linux/include/asm-ppc64/pci.h - 1.7 linux/fs/jfs/super.c - 1.24 linux/arch/ia64/sn/fakeprom/fpmem.c - 1.6 linux/arch/ia64/sn/kernel/sv.c - 1.5 linux/include/asm-ia64/sn/ifconfig_net.h - 1.2 linux/arch/ia64/sn/kernel/sn_ksyms.c - 1.3 linux/arch/ia64/sn/kernel/sn_asm.S - 1.3 linux/arch/ia64/sn/kernel/sn2/sn2_smp.c - 1.4 linux/include/asm-ia64/sn/hires_clock.h - 1.2 linux/arch/ia64/sn/kernel/sn2/iomv.c - 1.4 linux/arch/ia64/sn/kernel/sn2/cache.c - 1.2 linux/arch/ia64/sn/kernel/sn2/Makefile - 1.9 linux/arch/ia64/sn/kernel/sn1/synergy.c - 1.4 linux/arch/ia64/sn/kernel/sn1/sn1_smp.c - 1.5 linux/arch/ia64/sn/kernel/sn1/iomv.c - 1.3 linux/include/asm-ia64/sn/ate_utils.h - 1.3 linux/arch/ia64/sn/kernel/sn1/error.c - 1.2 linux/arch/ia64/sn/kernel/sn1/cache.c - 1.2 linux/arch/ia64/sn/kernel/llsc4.h - 1.3 linux/arch/ia64/sn/kernel/sn1/Makefile - 1.7 linux/arch/ia64/sn/kernel/irq.c - 1.4 linux/include/asm-ia64/sn/bte.h - 1.3 linux/arch/ia64/sn/kernel/bte.c - 1.3 linux/arch/ia64/sn/io/efi-rtc.c - 1.3 linux/arch/ia64/sn/io/ifconfig_net.c - 1.5 linux/arch/ia64/sn/kernel/setup.c - 1.9 linux/arch/ia64/sn/kernel/probe.c - 1.2 linux/arch/ia64/sn/kernel/misctest.c - 1.5 linux/arch/ia64/sn/io/ate_utils.c - 1.3 linux/arch/ia64/sn/kernel/mca.c - 1.5 linux/arch/ia64/sn/kernel/machvec.c - 1.4 linux/include/asm-ia64/thread_info.h - 1.6 linux/include/asm-ia64/sn/uart16550.h - 1.2 linux/include/asm-ia64/sn/sndrv.h - 1.3 linux/include/asm-ia64/sn/snconfig.h - 1.2 linux/include/asm-ia64/sn/sn_pio_sync.h - 1.2 linux/include/asm-ia64/sn/sn2/sn_private.h - 1.3 linux/include/asm-ia64/sn/sn2/slotnum.h - 1.2 linux/include/asm-ia64/sn/sn2/shubio.h - 1.3 linux/include/asm-ia64/sn/sn2/shub_mmr_t.h - 1.2 linux/include/asm-ia64/sn/sn2/shub_mmr.h - 1.3 linux/include/asm-ia64/sn/sn2/shub_md.h - 1.4 linux/include/asm-ia64/sn/sn2/shub.h - 1.2 linux/include/asm-ia64/sn/sn2/mmzone_sn2.h - 1.4 linux/include/asm-ia64/sn/sn2/intr.h - 1.3 linux/include/asm-ia64/sn/sn2/arch.h - 1.3 linux/include/asm-ia64/sn/sn2/addrs.h - 1.3 linux/include/asm-ia64/sn/sn1/synergy.h - 1.3 linux/include/asm-ia64/sn/sn1/sn_private.h - 1.3 linux/include/asm-ia64/sn/sn1/mmzone_sn1.h - 1.4 linux/include/asm-ia64/sn/sn1/mem_refcnt.h - 1.2 linux/include/asm-ia64/sn/sn1/intr_public.h - 1.3 linux/include/asm-ia64/sn/sn1/intr.h - 1.3 linux/include/asm-ia64/sn/sn1/hwcntrs.h - 1.2 linux/include/asm-ia64/sn/sn1/hubstat.h - 1.2 linux/include/asm-ia64/sn/sn1/hubspc.h - 1.2 linux/include/asm-ia64/sn/simulator.h - 1.2 linux/include/asm-ia64/sn/pio_flush.h - 1.2 linux/include/asm-ia64/sn/pda.h - 1.4 linux/include/asm-ia64/sn/nag.h - 1.2 linux/include/asm-ia64/sn/mmtimer_private.h - 1.2 linux/include/asm-ia64/sn/mca.h - 1.2 linux/include/asm-ia64/sn/leds.h - 1.3 linux/include/asm-ia64/sn/klclock.h - 1.3 linux/include/asm-ia64/sn/idle.h - 1.3 linux/include/asm-ia64/sn/fetchop.h - 1.3 linux/include/asm-ia64/sn/bte_copy.h - 1.4 linux/arch/ia64/sn/io/sn1/hub_intr.c - 1.3 linux/arch/ia64/sn/io/sn1/hubcounters.c - 1.4 linux/arch/ia64/sn/kernel/llsc4.c - 1.7 linux/arch/ia64/sn/io/sn1/huberror.c - 1.3 linux/arch/ia64/sn/kernel/Makefile - 1.9 linux/arch/ia64/sn/io/sn2/shuberror.c - 1.3 linux/arch/ia64/sn/io/sn2/shub_intr.c - 1.3 linux/arch/ia64/sn/io/sn2/pcibr/pcibr_slot.c - 1.5 linux/arch/ia64/sn/io/sn2/pcibr/pcibr_rrb.c - 1.4 linux/arch/ia64/sn/io/sn2/pcibr/pcibr_intr.c - 1.4 linux/arch/ia64/sn/io/sn2/pcibr/pcibr_idbg.c - 1.2 linux/arch/ia64/sn/io/sn2/pcibr/pcibr_hints.c - 1.3 linux/arch/ia64/sn/io/sn2/pcibr/pcibr_error.c - 1.5 linux/arch/ia64/sn/io/sn2/pcibr/pcibr_dvr.c - 1.7 linux/arch/ia64/sn/io/sn2/pcibr/pcibr_config.c - 1.3 linux/arch/ia64/sn/io/sn2/pcibr/pcibr_ate.c - 1.4 linux/arch/ia64/sn/io/sn2/ml_SN_intr.c - 1.3 linux/arch/ia64/sn/io/sn1/ip37.c - 1.2 linux/arch/ia64/sn/io/sn1/mem_refcnt.c - 1.3 linux/arch/ia64/sn/io/sn1/ml_SN_intr.c - 1.5 linux/arch/ia64/sn/fakeprom/README - 1.5 linux/arch/ia64/sn/io/sn2/bte_error.c - 1.3 linux/arch/ia64/sn/fakeprom/fpmem.h - 1.3 linux/arch/ia64/sn/fakeprom/fpromasm.S - 1.3 linux/arch/ia64/sn/fakeprom/fw-emu.c - 1.5 linux/arch/ia64/sn/fakeprom/klgraph_init.c - 1.3 linux/arch/ia64/sn/fakeprom/main.c - 1.3 linux/arch/ia64/sn/io/sn1/pcibr.c - 1.7 linux/include/linux/netfilter_arp.h - 1.2 linux/include/asm-i386/acpi.h - 1.5 linux/net/ipv4/netfilter/arptable_filter.c - 1.5 linux/net/ipv4/netfilter/arp_tables.c - 1.7 linux/fs/libfs.c - 1.16 linux/drivers/usb/image/microtek.c - 1.11 linux/drivers/usb/class/audio.c - 1.17 linux/drivers/usb/class/bluetty.c - 1.20 linux/drivers/usb/class/cdc-acm.c - 1.21 linux/drivers/usb/core/hcd.c - 1.24 linux/drivers/usb/core/hub.c - 1.27 linux/drivers/usb/input/hid-core.c - 1.24 linux/drivers/usb/core/usb.c - 1.35 linux/drivers/usb/host/ehci-dbg.c - 1.15 linux/drivers/usb/host/ehci-hcd.c - 1.22 linux/drivers/usb/host/ehci-q.c - 1.20 linux/drivers/usb/host/ehci.h - 1.13 linux/drivers/base/sys.c - 1.12 linux/drivers/usb/image/hpusbscsi.c - 1.13 linux/drivers/usb/input/usbkbd.c - 1.16 linux/drivers/usb/input/usbmouse.c - 1.13 linux/drivers/usb/input/wacom.c - 1.12 linux/drivers/usb/net/usbnet.c - 1.22 linux/drivers/usb/net/rtl8150.c - 1.17 linux/drivers/usb/net/pegasus.c - 1.17 linux/drivers/usb/net/kaweth.c - 1.18 linux/drivers/usb/net/catc.c - 1.10 linux/drivers/usb/net/Makefile - 1.6 linux/drivers/usb/misc/auerswald.c - 1.19 linux/drivers/usb/misc/rio500.c - 1.13 linux/drivers/usb/misc/rio500_usb.h - 1.2 linux/drivers/usb/misc/tiglusb.c - 1.14 linux/drivers/isdn/i4l/isdn_ttyfax.c - 1.5 linux/drivers/isdn/i4l/isdn_tty.c - 1.12 linux/drivers/isdn/i4l/isdn_bsdcomp.c - 1.3 linux/drivers/isdn/i4l/Makefile - 1.9 linux/arch/ia64/hp/sim/simserial.c - 1.13 linux/arch/ia64/hp/sim/hpsim_setup.c - 1.4 linux/arch/ia64/hp/sim/Makefile - 1.4 linux/arch/ia64/hp/common/sba_iommu.c - 1.11 linux/drivers/usb/misc/brlvger.c - 1.15 linux/drivers/isdn/hardware/avm/t1pci.c - 1.7 linux/drivers/isdn/hardware/avm/b1pcmcia.c - 1.5 linux/drivers/isdn/capi/Makefile - 1.6 linux/drivers/isdn/hardware/avm/b1pci.c - 1.8 linux/arch/i386/pci/common.c - 1.11 linux/arch/i386/pci/direct.c - 1.7 linux/arch/i386/pci/fixup.c - 1.6 linux/arch/i386/pci/irq.c - 1.7 linux/arch/i386/pci/legacy.c - 1.5 linux/drivers/pci/hotplug.c - 1.13 linux/drivers/pci/probe.c - 1.17 linux/fs/fs-writeback.c - 1.18 linux/arch/i386/pci/numa.c - 1.8 linux/include/linux/page-flags.h - 1.21 linux/arch/i386/pci/pcbios.c - 1.6 linux/arch/i386/pci/pci.h - 1.5 linux/mm/page-writeback.c - 1.26 linux/drivers/pci/search.c - 1.4 linux/Documentation/sched-coding.txt - 1.2 linux/drivers/usb/core/urb.c - 1.13 linux/drivers/usb/core/message.c - 1.20 linux/drivers/acpi/pci_root.c - 1.10 linux/drivers/acpi/osl.c - 1.20 linux/drivers/usb/class/usb-midi.c - 1.15 linux/drivers/usb/input/aiptek.c - 1.12 linux/include/net/llc_pdu.h - 1.5 linux/net/llc/llc_sap.c - 1.11 linux/net/llc/llc_s_ev.c - 1.6 linux/net/llc/llc_evnt.c - 1.6 linux/net/llc/llc_c_ac.c - 1.11 linux/net/llc/llc_c_ev.c - 1.8 linux/net/llc/llc_conn.c - 1.12 linux/drivers/isdn/hisax/avma1_cs.c - 1.6 linux/drivers/input/keyboard/atkbd.c - 1.12 linux/drivers/input/mouse/Makefile - 1.6 linux/drivers/usb/input/powermate.c - 1.11 linux/drivers/usb/input/xpad.c - 1.12 linux/drivers/input/serio/ambakmi.c - 1.5 linux/drivers/serial/Makefile - 1.11 linux/drivers/serial/8250_pnp.c - 1.7 linux/net/sched/sch_htb.c - 1.9 linux/drivers/usb/class/usblp.c - 1.10 linux/drivers/usb/misc/usblcd.c - 1.8 linux/drivers/input/misc/uinput.c - 1.6 linux/arch/ia64/kernel/perfmon_itanium.h - 1.4 linux/arch/ia64/kernel/perfmon_mckinley.h - 1.5 linux/arch/ia64/lib/memcpy_mck.S - 1.3 linux/net/sctp/endpointola.c - 1.11 linux/include/net/sctp/structs.h - 1.17 linux/net/sctp/socket.c - 1.18 linux/include/linux/rmap-locking.h - 1.3 linux/drivers/ide/pci/sis5513.c - 1.11 linux/drivers/char/vt_ioctl.c - 1.8 linux/arch/i386/mm/hugetlbpage.c - 1.15 linux/arch/ia64/pci/pci.c - 1.8 linux/arch/ia64/mm/hugetlbpage.c - 1.9 linux/drivers/pci/pci.h - 1.4 linux/Documentation/vm/hugetlbpage.txt - 1.7 linux/include/asm-ia64/topology.h - 1.7 linux/drivers/usb/misc/usbtest.c - 1.12 linux/drivers/scsi/nsp32.c - 1.10 linux/drivers/scsi/aacraid/aachba.c - 1.10 linux/kernel/workqueue.c - 1.5 linux/fs/cifs/asn1.c - 1.4 linux/fs/cifs/cifs_fs_sb.h - 1.4 linux/net/sunrpc/svcauth_unix.c - 1.7 linux/fs/cifs/cifsfs.c - 1.11 linux/fs/nfsd/nfs4xdr.c - 1.12 linux/fs/cifs/cifsproto.h - 1.9 linux/fs/cifs/cifssmb.c - 1.11 linux/fs/cifs/connect.c - 1.11 linux/fs/cifs/file.c - 1.10 linux/fs/cifs/inode.c - 1.9 linux/fs/cifs/misc.c - 1.7 linux/fs/nfsd/nfs4proc.c - 1.8 linux/fs/ext3/hash.c - 1.3 linux/fs/cifs/netmisc.c - 1.7 linux/net/sunrpc/cache.c - 1.7 linux/fs/cifs/CHANGES - 1.9 linux/fs/cifs/transport.c - 1.8 linux/drivers/isdn/hardware/eicon/Makefile - 1.4 linux/include/linux/sunrpc/cache.h - 1.6 linux/drivers/oprofile/buffer_sync.c - 1.14 linux/arch/i386/oprofile/Makefile - 1.6 linux/arch/i386/oprofile/init.c - 1.7 linux/arch/i386/oprofile/nmi_int.c - 1.11 linux/drivers/pnp/pnpbios/core.c - 1.13 linux/drivers/pnp/resource.c - 1.11 linux/drivers/isdn/i4l/isdn_ppp_ccp.c - 1.6 linux/drivers/pnp/base.h - 1.5 linux/drivers/pnp/core.c - 1.9 linux/drivers/pnp/isapnp/core.c - 1.13 linux/drivers/pnp/interface.c - 1.9 linux/include/linux/pnp.h - 1.11 linux/Documentation/kobject.txt - 1.7 linux/arch/alpha/Kconfig - 1.14 linux/arch/arm/Kconfig - 1.14 linux/drivers/net/tulip/Kconfig - 1.4 linux/scripts/kconfig/mconf.c - 1.6 linux/arch/cris/Kconfig - 1.9 linux/arch/i386/Kconfig - 1.22 linux/net/bridge/br_netfilter.c - 1.8 linux/arch/ia64/Kconfig - 1.13 linux/arch/ia64/hp/sim/Kconfig - 1.2 linux/arch/ia64/kernel/perfmon_generic.h - 1.3 linux/arch/ia64/mm/discontig.c - 1.4 linux/arch/m68k/Kconfig - 1.13 linux/arch/mips/Kconfig - 1.10 linux/arch/mips64/Kconfig - 1.11 linux/include/asm-ia64/nodedata.h - 1.2 linux/arch/parisc/Kconfig - 1.11 linux/fs/partitions/Kconfig - 1.3 linux/drivers/md/dm-ioctl.c - 1.12 linux/drivers/scsi/Kconfig - 1.14 linux/arch/ppc/Kconfig - 1.13 linux/arch/ppc64/Kconfig - 1.12 linux/arch/s390/Kconfig - 1.10 linux/arch/sh/Kconfig - 1.11 linux/arch/sparc/Kconfig - 1.13 linux/arch/sparc64/Kconfig - 1.15 linux/arch/um/Kconfig - 1.6 linux/fs/befs/linuxvfs.c - 1.9 linux/arch/x86_64/Kconfig - 1.17 linux/lib/kobject.c - 1.10 linux/drivers/input/mouse/Kconfig - 1.7 linux/drivers/serial/Kconfig - 1.9 linux/drivers/acpi/Kconfig - 1.7 linux/drivers/usb/net/Kconfig - 1.5 linux/usr/gen_init_cpio.c - 1.3 linux/fs/hugetlbfs/inode.c - 1.12 linux/fs/ext3/xattr.c - 1.9 linux/include/linux/hugetlb.h - 1.10 linux/include/asm-m68knommu/uaccess.h - 1.2 linux/arch/v850/vmlinux.lds.S - 1.9 linux/arch/m68knommu/Kconfig - 1.12 linux/arch/m68knommu/platform/5249/MOTOROLA/crt0_ram.S - 1.3 linux/arch/m68knommu/platform/5249/config.c - 1.4 linux/arch/m68knommu/platform/5272/MOTOROLA/crt0_ram.S - 1.2 linux/arch/m68knommu/platform/5272/config.c - 1.4 linux/include/asm-v850/io.h - 1.2 linux/include/asm-v850/hardirq.h - 1.4 linux/arch/v850/Kconfig - 1.12 linux/net/key/af_key.c - 1.14 linux/drivers/scsi/scsi_sysfs.c - 1.11 linux/drivers/acpi/events/evgpe.c - 1.10 linux/fs/compat.c - 1.7 linux/include/asm-ppc64/compat.h - 1.9 linux/kernel/compat.c - 1.9 linux/fs/intermezzo/intermezzo_fs.h - 1.2 linux/Documentation/usb/dma.txt - 1.2 linux/include/asm-x86_64/compat.h - 1.10 linux/drivers/i2c/chips/Kconfig - 1.7 linux/drivers/i2c/chips/Makefile - 1.5 linux/drivers/i2c/chips/adm1021.c - 1.8 linux/include/asm-ia64/compat.h - 1.6 linux/drivers/scsi/aic7xxx/aic79xx_osm.c - 1.10 linux/drivers/scsi/aic7xxx/aic79xx_osm_pci.c - 1.6 linux/drivers/scsi/aic7xxx/aic7xxx_osm.c - 1.12 linux/drivers/net/amd8111e.c - 1.6 linux/include/asm-parisc/compat.h - 1.8 linux/fs/proc/task_mmu.c - 1.4 linux/arch/arm/common/Makefile - 1.3 linux/drivers/pci/pci-sysfs.c - 1.2 linux/drivers/usb/net/Makefile.mii - 1.2 linux/arch/ia64/scripts/check-gas - 1.3 linux/include/acpi/acconfig.h - 1.7 linux/include/acpi/actypes.h - 1.6 linux/include/acpi/acpiosxf.h - 1.7 linux/arch/ia64/kernel/fsys.S - 1.4 linux/arch/alpha/kernel/srmcons.c - 1.4 linux/include/acpi/acglobal.h - 1.6 linux/include/acpi/achware.h - 1.6 linux/arch/i386/kernel/acpi/Makefile - 1.2 linux/drivers/pnp/manager.c - 1.4 linux/drivers/pnp/support.c - 1.2 linux/arch/alpha/oprofile/common.c - 1.4 linux/drivers/acpi/events/evgpeblk.c - 1.5 linux/drivers/usb/input/kbtab.c - 1.4 linux/drivers/i2c/busses/i2c-ali15x3.c - 1.5 linux/drivers/pci/bus.c - 1.5 linux/include/asm-ia64/sn/geo.h - 1.2 linux/arch/ia64/sn/io/sn2/ml_iograph.c - 1.2 linux/arch/ia64/sn/io/sn2/module.c - 1.2 linux/arch/ia64/sn/io/sn2/pci_bus_cvlink.c - 1.4 linux/arch/ia64/sn/io/sn2/pcibr/Makefile - 1.3 linux/arch/ia64/sn/io/sn2/pciio.c - 1.2 linux/arch/arm/kernel/pm.c - 1.4 linux/arch/ia64/sn/io/sn2/pic.c - 1.2 linux/arch/ia64/sn/io/sn2/sgi_io_init.c - 1.2 linux/arch/ia64/sn/io/ioconfig_bus.c - 1.2 linux/arch/ia64/sn/io/sn2/Makefile - 1.3 linux/arch/ia64/sn/io/sn2/shub.c - 1.2 linux/drivers/i2c/busses/i2c-i801.c - 1.5 linux/arch/ia64/sn/io/sn2/shubio.c - 1.2 linux/arch/ia64/sn/io/sn2/xbow.c - 1.2 linux/arch/ia64/sn/io/sn2/klconflib.c - 1.3 linux/arch/ia64/sn/io/sn2/klgraph.c - 1.2 linux/arch/ia64/sn/kernel/sn2/sn_proc_fs.c - 1.2 linux/arch/ia64/sn/io/sn2/xtalk.c - 1.2 linux/arch/ia64/sn/io/sn2/l1.c - 1.2 linux/arch/ia64/sn/kernel/iomv.c - 1.2 linux/arch/ia64/sn/io/sn2/ml_SN_init.c - 1.2 linux/arch/ia64/sn/io/sn2/l1_command.c - 1.3 linux/net/ipv6/xfrm6_policy.c - 1.5 linux/include/asm-i386/mach-pc9800/setup_arch_pre.h - 1.3 linux/drivers/usb/misc/speedtch.c - 1.6 linux/drivers/i2c/chips/w83781d.c - 1.6 linux/include/linux/nfsd/state.h - 1.3 linux/arch/h8300/Kconfig - 1.4 linux/fs/nfsd/nfs4state.c - 1.3 linux/include/asm-ia64/sn/sn2/io.h - 1.2 linux/arch/ia64/kernel/acpi-ext.c - 1.3 linux/arch/ia64/kernel/module.c - 1.3 linux/include/asm-h8300/statfs.h - 1.2 linux/include/asm-i386/mach-default/mach_resources.h - 1.2 linux/arch/ia64/sn/fakeprom/make_textsym - 1.2 linux/include/asm-h8300/uaccess.h - 1.2 linux/arch/ia64/sn/kernel/sn2/io.c - 1.2 linux/drivers/net/ixgb/ixgb_ethtool.c - 1.2 linux/drivers/scsi/dc395x.c - 1.4 linux/include/asm-i386/genapic.h - 1.2 linux/include/asm-i386/mach-generic/mach_apic.h - 1.3 linux/dev/null - 1.4 linux/drivers/net/bonding/bond_main.c - 1.3 linux/drivers/net/bonding/bonding.h - 1.2 linux/drivers/usb/gadget/net2280.c - 1.3 linux/drivers/atm/he.c - 1.3 linux/drivers/scsi/scsi_priv.h - 1.3 linux/drivers/scsi/scsi_devinfo.c - 1.3 linux/drivers/scsi/arm/acornscsi.c - 1.3 linux/drivers/scsi/arm/arxescsi.c - 1.3 linux/drivers/scsi/arm/cumana_1.c - 1.3 linux/drivers/scsi/arm/cumana_2.c - 1.3 linux/drivers/scsi/arm/ecoscsi.c - 1.3 linux/drivers/scsi/arm/eesox.c - 1.3 linux/drivers/scsi/arm/fas216.c - 1.2 linux/drivers/scsi/arm/fas216.h - 1.2 linux/drivers/scsi/arm/oak.c - 1.3 linux/drivers/scsi/arm/powertec.c - 1.3 linux/net/core/flow.c - 1.4 linux/include/linux/sysdev.h - 1.2 linux/net/ipv6/ip6_tunnel.c - 1.2 linux/arch/arm/mach-integrator/core.c - 1.2 linux/drivers/net/wireless/atmel.c - 1.2 linux/drivers/pci/hotplug/acpiphp.h - 1.2 linux/drivers/pci/hotplug/acpiphp_core.c - 1.2 linux/drivers/pci/hotplug/acpiphp_glue.c - 1.2 linux/drivers/pci/hotplug/acpiphp_pci.c - 1.2 linux/drivers/pci/hotplug/acpiphp_res.c - 1.2 linux/arch/arm26/Kconfig - 1.2 linux/drivers/i2c/chips/lm85.c - 1.2 linux/drivers/input/mouse/synaptics.h - 1.2 linux/drivers/input/mouse/synaptics.c - 1.2 linux/drivers/input/mouse/psmouse.h - 1.2 linux/drivers/input/mouse/psmouse-base.c - 1.2 From owner-linux-xfs@oss.sgi.com Fri Jul 11 14:32:56 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 11 Jul 2003 14:33:19 -0700 (PDT) Received: from zok.sgi.com (zok.SGI.COM [204.94.215.101]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h6BLWt2x022065 for ; Fri, 11 Jul 2003 14:32:55 -0700 Received: from flecktone.americas.sgi.com (flecktone.americas.sgi.com [192.48.203.135]) by zok.sgi.com (8.12.9/8.12.2/linux-outbound_gateway-1.2) with ESMTP id h6BLWniY020434 for ; Fri, 11 Jul 2003 14:32:49 -0700 Received: from daisy-e236.americas.sgi.com (daisy-e236.americas.sgi.com [128.162.236.214]) by flecktone.americas.sgi.com (8.12.9/8.12.9/generic_config-1.2) with ESMTP id h6BLVmqX8969844 for ; Fri, 11 Jul 2003 16:31:48 -0500 (CDT) Received: from penguin.americas.sgi.com (penguin.americas.sgi.com [128.162.240.135]) by daisy-e236.americas.sgi.com (8.12.9/SGI-server-1.8) with ESMTP id h6BLVmRn156929385 for ; Fri, 11 Jul 2003 16:31:48 -0500 (CDT) From: Steve Lord Received: by penguin.americas.sgi.com (8.11.6/SGI-client-1.7) id h6BLV7h18952; Fri, 11 Jul 2003 16:31:07 -0500 Message-Id: <200307112131.h6BLV7h18952@penguin.americas.sgi.com> Date: Fri, 11 Jul 2003 16:31:07 -0500 Subject: TAKE - merge up to 2.5.74 To: linux-xfs@oss.sgi.com X-archive-position: 4624 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: lord@sgi.com Precedence: bulk X-list: linux-xfs Date: Fri Jul 11 14:26:01 PDT 2003 Workarea: penguin.americas.sgi.com:/src/lord/xfs-linux.2.5 The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.5.x-xfs Modid: 2.5.x-xfs:slinx:153050a linux/arch/sh/kernel/cpu/sh4/pci-sh7751.c - 1.1 linux/arch/mips/sgi-ip22/ip22-int.c - 1.1 linux/include/asm-sh/sh2000/io.h - 1.1 linux/arch/mips/sgi-ip22/ip22-irq.S - 1.1 linux/include/asm-sh/se7751/se7751.h - 1.1 linux/include/asm-sh/se7751/io.h - 1.1 linux/include/asm-sh/se/smc37c93x.h - 1.1 linux/include/asm-sh/se/se.h - 1.1 linux/include/asm-sh/sh2000/sh2000.h - 1.1 linux/include/asm-sh/se/io.h - 1.1 linux/include/asm-sh/saturn/smpc.h - 1.1 linux/include/asm-sh/saturn/io.h - 1.1 linux/include/asm-sh/rwsem.h - 1.1 linux/include/asm-sh/percpu.h - 1.1 linux/drivers/media/dvb/dvb-core/dvb_functions.c - 1.1 linux/drivers/media/dvb/dvb-core/dvb_functions.h - 1.1 linux/include/asm-sh/overdrive/overdrive.h - 1.1 linux/include/asm-mips64/wbflush.h - 1.1 linux/include/asm-sh/overdrive/io.h - 1.1 linux/include/asm-sh/overdrive/gt64111.h - 1.1 linux/include/asm-mips/tx4927/tx4927_pci.h - 1.1 linux/include/asm-sh/overdrive/fpga.h - 1.1 linux/arch/i386/kernel/cpu/cpufreq/speedstep-lib.c - 1.1 linux/arch/i386/kernel/cpu/cpufreq/speedstep-lib.h - 1.1 linux/include/asm-sh/mpc1211/pci.h - 1.1 linux/include/asm-sh/mpc1211/mpc1211.h - 1.1 linux/include/asm-sh/mpc1211/mc146818rtc.h - 1.1 linux/include/asm-mips64/war.h - 1.1 linux/include/asm-sh/mpc1211/m1543c.h - 1.1 linux/include/asm-sh/mpc1211/keyboard.h - 1.1 linux/include/asm-mips64/vga.h - 1.1 linux/include/asm-sh/mpc1211/io.h - 1.1 linux/include/asm-mips64/traps.h - 1.1 linux/include/scsi/scsi_driver.h - 1.1 linux/include/asm-mips64/tlbflush.h - 1.1 linux/include/asm-mips64/tlbdebug.h - 1.1 linux/include/asm-mips64/time.h - 1.1 linux/include/asm-mips64/thread_info.h - 1.1 linux/include/asm-mips64/suspend.h - 1.1 linux/include/asm-mips64/sibyte/trace_prof.h - 1.1 linux/include/asm-mips64/sibyte/swarm.h - 1.1 linux/include/asm-mips64/sibyte/sentosa.h - 1.1 linux/include/asm-mips64/sibyte/sb1250_uart.h - 1.1 linux/include/asm-mips64/sibyte/sb1250_syncser.h - 1.1 linux/include/asm-mips64/sibyte/sb1250_smbus.h - 1.1 linux/include/asm-mips64/sibyte/sb1250_scd.h - 1.1 linux/include/asm-mips64/sibyte/sb1250_regs.h - 1.1 linux/include/asm-mips64/sibyte/sb1250_mc.h - 1.1 linux/include/asm-mips64/sibyte/sb1250_mac.h - 1.1 linux/include/asm-mips64/sibyte/sb1250_ldt.h - 1.1 linux/include/asm-mips64/sibyte/sb1250_l2c.h - 1.1 linux/include/asm-mips64/sibyte/sb1250_int.h - 1.1 linux/include/asm-sh/cpu-sh4/dma.h - 1.1 linux/arch/mips64/kernel/scall_n32.S - 1.1 linux/include/asm-mips/sibyte/swarm.h - 1.1 linux/include/asm-sh/thread_info.h - 1.1 linux/include/asm-mips/sibyte/sentosa.h - 1.1 linux/include/asm-mips64/sibyte/sb1250_genbus.h - 1.1 linux/include/asm-mips/sibyte/sb1250_uart.h - 1.1 linux/include/asm-mips64/sibyte/sb1250_dma.h - 1.1 linux/include/asm-mips64/sibyte/sb1250_defs.h - 1.1 linux/drivers/i2c/i2c-prosavage.c - 1.1 linux/include/asm-mips64/sibyte/sb1250.h - 1.1 linux/include/net/irda/au1000_ircc.h - 1.1 linux/drivers/i2c/busses/i2c-ali1535.c - 1.1 linux/include/asm-mips/sibyte/sb1250_syncser.h - 1.1 linux/include/asm-sh/tlbflush.h - 1.1 linux/drivers/media/dvb/frontends/cx24110.c - 1.1 linux/include/asm-mips64/sibyte/io.h - 1.1 linux/include/asm-mips64/sibyte/carmel.h - 1.1 linux/include/asm-mips64/sibyte/board.h - 1.1 linux/include/asm-mips64/sibyte/64bit.h - 1.1 linux/include/asm-mips/sibyte/sb1250_mc.h - 1.1 linux/arch/mips/Kconfig-shared - 1.1 linux/include/asm-sh/mpc1211/dma.h - 1.1 linux/drivers/char/lcd.c - 1.1 linux/include/asm-sh/ubc.h - 1.1 linux/include/asm-mips64/sgi/mc.h - 1.1 linux/include/asm-sh/mmzone.h - 1.1 linux/include/asm-sh/watchdog.h - 1.1 linux/include/asm-mips/sibyte/sb1250_l2c.h - 1.1 linux/include/asm-mips/sibyte/sb1250_defs.h - 1.1 linux/arch/mips64/kernel/reset.c - 1.1 linux/include/asm-mips/i8259.h - 1.1 linux/include/asm-mips/galileo-boards/gt96100.h - 1.1 linux/include/asm-mips/galileo-boards/ev96100int.h - 1.1 linux/arch/mips/arc/promlib.c - 1.1 linux/include/asm-mips/galileo-boards/ev96100.h - 1.1 linux/arch/mips64/kernel/time.c - 1.1 linux/include/asm-mips/irq_cpu.h - 1.1 linux/include/asm-mips64/sgi/ip22.h - 1.1 linux/arch/mips/au1000/common/clocks.c - 1.1 linux/include/asm-mips64/sgi/ioc.h - 1.1 linux/arch/mips/au1000/common/dma.c - 1.1 linux/include/asm-mips64/sgi/hpc3.h - 1.1 linux/include/asm-mips64/sgi/gio.h - 1.1 linux/arch/mips/au1000/common/power.c - 1.1 linux/include/asm-mips64/sections.h - 1.1 linux/include/asm-mips64/rtc.h - 1.1 linux/include/asm-mips64/reboot.h - 1.1 linux/arch/mips/au1000/common/rtc.c - 1.1 linux/include/asm-mips64/pgtable-bits.h - 1.1 linux/include/asm-mips64/percpu.h - 1.1 linux/arch/mips/au1000/common/usbdev.c - 1.1 linux/arch/mips/au1000/db1x00/Makefile - 1.1 linux/arch/mips/au1000/db1x00/init.c - 1.1 linux/arch/mips/au1000/db1x00/setup.c - 1.1 linux/include/asm-mips64/mv64340_dep.h - 1.1 linux/include/asm-mips64/mv64340.h - 1.1 linux/include/asm-mips64/mips-boards/seadint.h - 1.1 linux/arch/mips/au1000/pb1100/Makefile - 1.1 linux/arch/mips/au1000/pb1100/init.c - 1.1 linux/arch/mips/au1000/pb1100/setup.c - 1.1 linux/arch/mips/au1000/pb1500/Makefile - 1.1 linux/arch/mips/au1000/pb1500/init.c - 1.1 linux/arch/mips/au1000/pb1500/setup.c - 1.1 linux/include/asm-mips/jmr3927/ds1742rtc.h - 1.1 linux/include/asm-mips/jmr3927/irq.h - 1.1 linux/include/asm-mips/jmr3927/jmr3927.h - 1.1 linux/arch/mips64/kernel/pci-dma.c - 1.1 linux/arch/mips64/kernel/offset.c - 1.1 linux/arch/mips64/kernel/module.c - 1.1 linux/include/asm-mips/jmr3927/pci.h - 1.1 linux/include/asm-mips/jmr3927/tx3927.h - 1.1 linux/arch/mips64/kernel/irq_cpu.c - 1.1 linux/include/asm-sh/kmap_types.h - 1.1 linux/arch/mips64/kernel/irq.c - 1.1 linux/net/ipv4/netfilter/ipt_recent.c - 1.1 linux/include/asm-sh/kgdb.h - 1.1 linux/drivers/net/irda/au1k_ir.c - 1.1 linux/arch/sh/mm/tlb-sh4.c - 1.1 linux/arch/sh/mm/tlb-sh3.c - 1.1 linux/include/asm-mips64/mips-boards/sead.h - 1.1 linux/include/asm-mips64/mips-boards/msc01_pci.h - 1.1 linux/arch/mips/cobalt/irq.c - 1.1 linux/arch/mips/cobalt/promcon.c - 1.1 linux/include/asm-mips64/mips-boards/bonito64.h - 1.1 linux/include/asm-mips64/kmap_types.h - 1.1 linux/include/asm-mips64/irq_cpu.h - 1.1 linux/include/asm-mips64/ip32/machine.h - 1.1 linux/include/asm-mips64/ip32/mace.h - 1.1 linux/include/asm-mips64/ip32/ip32_ints.h - 1.1 linux/include/asm-mips64/ip32/io.h - 1.1 linux/include/asm-mips64/ip32/crime.h - 1.1 linux/include/asm-mips64/i8259.h - 1.1 linux/include/asm-mips64/gt64120.h - 1.1 linux/include/asm-mips64/gdb-stub.h - 1.1 linux/include/asm-mips64/fpu_emulator.h - 1.1 linux/include/asm-mips64/fpu.h - 1.1 linux/include/asm-mips64/exception.h - 1.1 linux/include/asm-mips64/dec/tcmodule.h - 1.1 linux/include/asm-mips64/dec/tcinfo.h - 1.1 linux/include/asm-mips64/dec/tc.h - 1.1 linux/include/asm-mips64/dec/rtc-dec.h - 1.1 linux/include/asm-mips64/dec/prom.h - 1.1 linux/include/asm-mips64/dec/machtype.h - 1.1 linux/include/asm-mips64/dec/kn230.h - 1.1 linux/include/asm-mips64/dec/kn05.h - 1.1 linux/include/asm-mips64/dec/kn03.h - 1.1 linux/include/asm-mips64/dec/kn02xa.h - 1.1 linux/include/asm-mips64/dec/kn02ca.h - 1.1 linux/include/asm-mips64/dec/kn02ba.h - 1.1 linux/include/asm-mips64/dec/kn02.h - 1.1 linux/include/asm-mips64/dec/kn01.h - 1.1 linux/arch/mips/ddb5xxx/ddb5074/Makefile - 1.1 linux/arch/mips/ddb5xxx/ddb5074/int-handler.S - 1.1 linux/arch/mips/ddb5xxx/ddb5074/irq.c - 1.1 linux/arch/mips/ddb5xxx/ddb5074/nile4_pic.c - 1.1 linux/arch/mips/ddb5xxx/ddb5074/setup.c - 1.1 linux/arch/mips/ddb5xxx/ddb5074/time.c - 1.1 linux/arch/mips/ddb5xxx/ddb5476/Makefile - 1.1 linux/arch/mips/ddb5xxx/ddb5476/dbg_io.c - 1.1 linux/arch/mips/ddb5xxx/ddb5476/int-handler.S - 1.1 linux/arch/mips/ddb5xxx/ddb5476/irq.c - 1.1 linux/arch/mips/ddb5xxx/ddb5476/nile4_pic.c - 1.1 linux/arch/mips/ddb5xxx/ddb5476/setup.c - 1.1 linux/arch/mips/ddb5xxx/ddb5476/vrc5476_irq.c - 1.1 linux/include/asm-mips64/dec/ioasic_ints.h - 1.1 linux/include/asm-mips64/dec/ioasic_addrs.h - 1.1 linux/include/asm-mips64/dec/ioasic.h - 1.1 linux/include/asm-mips64/dec/io.h - 1.1 linux/include/asm-mips64/dec/interrupts.h - 1.1 linux/include/asm-mips64/dec/ecc.h - 1.1 linux/arch/mips/ddb5xxx/ddb5477/lcd44780.c - 1.1 linux/arch/mips/ddb5xxx/ddb5477/lcd44780.h - 1.1 linux/include/asm-mips64/cacheops.h - 1.1 linux/include/asm-mips64/cacheflush.h - 1.1 linux/include/asm-mips64/break.h - 1.1 linux/arch/sh/mm/tlb-nommu.c - 1.1 linux/arch/sh/mm/pg-sh4.c - 1.1 linux/arch/mips/dec/ecc-berr.c - 1.1 linux/drivers/net/meth.c - 1.1 linux/arch/mips/dec/ioasic-irq.c - 1.1 linux/drivers/net/meth.h - 1.1 linux/arch/mips/dec/kn02-irq.c - 1.1 linux/arch/sh/mm/fault-nommu.c - 1.1 linux/arch/mips/dec/prom/call_o32.S - 1.1 linux/drivers/pci/hotplug/fakephp.c - 1.1 linux/arch/sh/mm/cache-sh2.c - 1.1 linux/net/ipv4/netfilter/arpt_mangle.c - 1.1 linux/arch/sh/lib/udivdi3.c - 1.1 linux/arch/sh/lib/div64.S - 1.1 linux/include/asm-mips/jmr3927/txx927.h - 1.1 linux/include/asm-mips/galileo-boards/ev64120int.h - 1.1 linux/arch/mips64/kernel/i8259.c - 1.1 linux/include/asm-sh/hp6xx/io.h - 1.1 linux/drivers/pcmcia/au1000_generic.c - 1.1 linux/drivers/pcmcia/au1000_pb1x00.c - 1.1 linux/include/asm-sh/hd64465/io.h - 1.1 linux/include/asm-sh/hd64465/hd64465.h - 1.1 linux/include/asm-mips/kmap_types.h - 1.1 linux/arch/mips/defconfig-capcella - 1.1 linux/include/asm-mips/war.h - 1.1 linux/include/asm-mips/vr41xx/workpad.h - 1.1 linux/include/asm-mips/vr41xx/vrc4173.h - 1.1 linux/include/asm-mips/vr41xx/vr41xx.h - 1.1 linux/arch/mips/defconfig-e55 - 1.1 linux/arch/mips/defconfig-eagle - 1.1 linux/arch/mips/defconfig-ev64120 - 1.1 linux/arch/mips/defconfig-ev96100 - 1.1 linux/include/asm-mips/vr41xx/tb0229.h - 1.1 linux/arch/mips/defconfig-jmr3927 - 1.1 linux/arch/mips/defconfig-lasat200 - 1.1 linux/include/asm-mips/vr41xx/tb0226.h - 1.1 linux/arch/mips/defconfig-mpc30x - 1.1 linux/include/asm-mips/vr41xx/mpc30x.h - 1.1 linux/include/asm-mips/vr41xx/eagle.h - 1.1 linux/arch/mips/defconfig-pb1100 - 1.1 linux/arch/mips/defconfig-pb1500 - 1.1 linux/arch/mips/defconfig-sb1250-swarm - 1.1 linux/arch/mips/defconfig-sead - 1.1 linux/arch/mips/defconfig-tb0226 - 1.1 linux/arch/mips/defconfig-tb0229 - 1.1 linux/arch/mips/defconfig-workpad - 1.1 linux/arch/mips/galileo-boards/ev64120/Makefile - 1.1 linux/arch/mips/galileo-boards/ev64120/README - 1.1 linux/arch/mips/galileo-boards/ev64120/dma.c - 1.1 linux/arch/mips/galileo-boards/ev64120/i2o.c - 1.1 linux/arch/mips/galileo-boards/ev64120/int-handler.S - 1.1 linux/arch/mips/galileo-boards/ev64120/irq-handler.c - 1.1 linux/arch/mips/galileo-boards/ev64120/irq.c - 1.1 linux/arch/mips/galileo-boards/ev64120/promcon.c - 1.1 linux/arch/mips/galileo-boards/ev64120/reset.c - 1.1 linux/arch/mips/galileo-boards/ev64120/serialGT.c - 1.1 linux/arch/mips/galileo-boards/ev64120/setup.c - 1.1 linux/arch/mips/galileo-boards/ev96100/Makefile - 1.1 linux/arch/mips/galileo-boards/ev96100/init.c - 1.1 linux/arch/mips/galileo-boards/ev96100/int-handler.S - 1.1 linux/arch/mips/galileo-boards/ev96100/irq.c - 1.1 linux/arch/mips/galileo-boards/ev96100/puts.c - 1.1 linux/arch/mips/galileo-boards/ev96100/setup.c - 1.1 linux/arch/mips/galileo-boards/ev96100/time.c - 1.1 linux/arch/mips/galileo-boards/generic/Makefile - 1.1 linux/arch/mips/galileo-boards/generic/reset.c - 1.1 linux/arch/mips/jmr3927/common/Makefile - 1.1 linux/arch/mips/jmr3927/common/prom.c - 1.1 linux/arch/mips/jmr3927/common/puts.c - 1.1 linux/arch/mips/jmr3927/common/rtc_ds1742.c - 1.1 linux/arch/mips/jmr3927/rbhma3100/Makefile - 1.1 linux/arch/mips/jmr3927/rbhma3100/init.c - 1.1 linux/arch/mips/jmr3927/rbhma3100/int-handler.S - 1.1 linux/arch/mips/jmr3927/rbhma3100/irq.c - 1.1 linux/arch/mips/jmr3927/rbhma3100/kgdb_io.c - 1.1 linux/arch/mips/jmr3927/rbhma3100/rtc.c - 1.1 linux/arch/mips/jmr3927/rbhma3100/setup.c - 1.1 linux/arch/sh/kernel/pci_auto.c - 1.1 linux/arch/sh/kernel/pci.c - 1.1 linux/arch/mips/kernel/cpu-probe.c - 1.1 linux/include/asm-mips/lasat/ds1603.h - 1.1 linux/arch/sh/kernel/module.c - 1.1 linux/arch/sh/kernel/kgdb_stub.c - 1.1 linux/arch/sh/kernel/kgdb_jmp.S - 1.1 linux/include/asm-mips/vr41xx/e55.h - 1.1 linux/include/asm-sh/hd64465/gpio.h - 1.1 linux/include/asm-sh/hd64461/io.h - 1.1 linux/include/asm-sh/hd64461/hd64461.h - 1.1 linux/include/asm-sh/harp/io.h - 1.1 linux/arch/sh/kernel/cpufreq.c - 1.1 linux/arch/sh/kernel/cpu/ubc.S - 1.1 linux/arch/sh/kernel/cpu/sh4/pci-st40.h - 1.1 linux/arch/sh/kernel/cpu/sh4/pci-st40.c - 1.1 linux/include/asm-sh/harp/harp.h - 1.1 linux/arch/mips/kernel/irq_cpu.c - 1.1 linux/arch/sh/kernel/cpu/sh4/irq_intc2.c - 1.1 linux/arch/mips/kernel/module.c - 1.1 linux/arch/mips/kernel/offset.c - 1.1 linux/include/asm-mips/vr41xx/capcella.h - 1.1 linux/arch/sh/kernel/cpu/sh4/fpu.c - 1.1 linux/arch/sh/kernel/cpu/sh4/Makefile - 1.1 linux/arch/sh/kernel/cpu/sh3/Makefile - 1.1 linux/arch/sh/kernel/cpu/sh2/Makefile - 1.1 linux/arch/sh/kernel/cpu/rtc.c - 1.1 linux/arch/sh/kernel/cpu/irq_ipr.c - 1.1 linux/arch/sh/kernel/cpu/irq_imask.c - 1.1 linux/arch/sh/kernel/cpu/dma.c - 1.1 linux/arch/sh/kernel/cpu/Makefile - 1.1 linux/include/asm-sh/freq.h - 1.1 linux/include/asm-sh/floppy.h - 1.1 linux/include/asm-sh/ec3104/serial.h - 1.1 linux/arch/sh/configs/defconfig-dreamcast - 1.1 linux/arch/sh/configs/defconfig-cqreek - 1.1 linux/arch/sh/configs/defconfig-adx - 1.1 linux/include/asm-sh/ec3104/keyboard.h - 1.1 linux/include/linux/dvb/version.h - 1.1 linux/include/asm-sh/ec3104/io.h - 1.1 linux/arch/sh/boards/mpc1211/setup.c - 1.1 linux/arch/sh/boards/mpc1211/rtc.c - 1.1 linux/arch/sh/boards/mpc1211/pci.c - 1.1 linux/arch/sh/boards/mpc1211/mach.c - 1.1 linux/arch/sh/boards/mpc1211/led.c - 1.1 linux/arch/mips/lasat/Makefile - 1.1 linux/arch/mips/lasat/at93c.c - 1.1 linux/arch/mips/lasat/at93c.h - 1.1 linux/arch/mips/lasat/ds1603.c - 1.1 linux/arch/mips/lasat/ds1603.h - 1.1 linux/arch/mips/lasat/image/Makefile - 1.1 linux/arch/mips/lasat/image/head.S - 1.1 linux/arch/mips/lasat/image/romscript.normal - 1.1 linux/arch/mips/lasat/interrupt.c - 1.1 linux/arch/mips/lasat/lasatIRQ.S - 1.1 linux/arch/mips/lasat/lasat_board.c - 1.1 linux/arch/mips/lasat/lasat_models.h - 1.1 linux/arch/mips/lasat/picvue.c - 1.1 linux/arch/mips/lasat/picvue.h - 1.1 linux/arch/mips/lasat/picvue_proc.c - 1.1 linux/arch/mips/lasat/prom.c - 1.1 linux/arch/mips/lasat/prom.h - 1.1 linux/arch/mips/lasat/reset.c - 1.1 linux/arch/mips/lasat/setup.c - 1.1 linux/arch/mips/lasat/sysctl.c - 1.1 linux/arch/mips/lasat/sysctl.h - 1.1 linux/arch/sh/boards/mpc1211/io.c - 1.1 linux/arch/sh/boards/mpc1211/Makefile - 1.1 linux/include/asm-sh/ec3104/ec3104.h - 1.1 linux/include/asm-sh/dreamcast/sysasic.h - 1.1 linux/include/asm-sh/dreamcast/io.h - 1.1 linux/include/asm-sh/dmida/io.h - 1.1 linux/include/asm-sh/cqreek/cqreek.h - 1.1 linux/drivers/s390/net/qeth.c - 1.1 linux/include/linux/netfilter_arp/arpt_mangle.h - 1.1 linux/include/linux/netfilter_ipv4/ipt_recent.h - 1.1 linux/drivers/s390/net/qeth.h - 1.1 linux/drivers/s390/net/qeth_mpc.c - 1.1 linux/arch/mips/lib/promlib.c - 1.1 linux/drivers/s390/net/qeth_mpc.h - 1.1 linux/include/asm-sh/cpu-sh4/watchdog.h - 1.1 linux/drivers/scsi/NCR_Q720.c - 1.1 linux/drivers/scsi/NCR_Q720.h - 1.1 linux/include/asm-sh/cpu-sh4/ubc.h - 1.1 linux/include/asm-sh/cpu-sh4/shmparam.h - 1.1 linux/include/asm-sh/cpu-sh4/rtc.h - 1.1 linux/include/asm-sh/cpu-sh4/mmu_context.h - 1.1 linux/arch/mips64/kernel/cpu-probe.c - 1.1 linux/include/asm-mips/tx4927/tx4927_mips.h - 1.1 linux/include/asm-mips/tx4927/tx4927.h - 1.1 linux/include/asm-mips/tx4927/toshiba_rbtx4927.h - 1.1 linux/include/asm-mips/traps.h - 1.1 linux/include/asm-mips/tlbflush.h - 1.1 linux/include/asm-mips/tlbdebug.h - 1.1 linux/include/asm-sh/cpu-sh4/freq.h - 1.1 linux/include/asm-mips/thread_info.h - 1.1 linux/include/asm-mips/sibyte/trace_prof.h - 1.1 linux/include/asm-mips/suspend.h - 1.1 linux/include/asm-sh/cpu-sh4/cacheflush.h - 1.1 linux/include/asm-sh/cpu-sh4/cache.h - 1.1 linux/arch/mips/math-emu/dsemul.c - 1.1 linux/arch/mips/math-emu/dsemul.h - 1.1 linux/include/asm-sh/cpu-sh4/addrspace.h - 1.1 linux/include/asm-sh/cpu-sh3/watchdog.h - 1.1 linux/include/asm-sh/cpu-sh3/ubc.h - 1.1 linux/include/asm-sh/cpu-sh3/shmparam.h - 1.1 linux/include/asm-sh/cpu-sh3/rtc.h - 1.1 linux/include/asm-sh/cpu-sh3/mmu_context.h - 1.1 linux/include/asm-sh/cpu-sh3/freq.h - 1.1 linux/include/asm-sh/cpu-sh3/dma.h - 1.1 linux/arch/mips64/mm/tlbex-r4k.S - 1.1 linux/arch/mips64/defconfig-sb1250-swarm - 1.1 linux/arch/mips64/defconfig-malta - 1.1 linux/include/asm-mips/lasat/eeprom.h - 1.1 linux/arch/mips64/kernel/binfmt_elfo32.c - 1.1 linux/arch/mips64/kernel/binfmt_elfn32.c - 1.1 linux/include/asm-mips/sibyte/sb1250_smbus.h - 1.1 linux/include/asm-mips/sibyte/sb1250_scd.h - 1.1 linux/include/asm-mips/sibyte/sb1250_regs.h - 1.1 linux/include/asm-mips/lasat/head.h - 1.1 linux/include/asm-mips/sibyte/sb1250_mac.h - 1.1 linux/include/asm-mips/sibyte/sb1250_ldt.h - 1.1 linux/include/asm-mips/lasat/lasat.h - 1.1 linux/include/asm-mips/sibyte/sb1250_int.h - 1.1 linux/include/asm-mips/sibyte/sb1250_genbus.h - 1.1 linux/include/asm-mips/sibyte/sb1250_dma.h - 1.1 linux/arch/mips64/defconfig-sead - 1.1 linux/include/asm-mips/sibyte/sb1250.h - 1.1 linux/include/asm-mips/sibyte/carmel.h - 1.1 linux/include/asm-mips/sibyte/board.h - 1.1 linux/include/asm-mips/sibyte/64bit.h - 1.1 linux/arch/mips64/mm/tlb-sb1.c - 1.1 linux/arch/mips64/mm/tlb-r4k.c - 1.1 linux/arch/mips64/mm/tlb-glue-sb1.S - 1.1 linux/arch/mips64/mm/tlb-glue-r4k.S - 1.1 linux/include/asm-mips/sgi/mc.h - 1.1 linux/include/asm-mips/sgi/ip22.h - 1.1 linux/include/asm-mips/sgi/ioc.h - 1.1 linux/include/asm-mips/sgi/hpc3.h - 1.1 linux/include/asm-mips/sgi/gio.h - 1.1 linux/arch/mips64/mm/tlb-dbg-r4k.c - 1.1 linux/arch/mips64/mm/tlb-andes.c - 1.1 linux/arch/mips/mips-boards/sead/Makefile - 1.1 linux/arch/mips/mips-boards/sead/sead_int.c - 1.1 linux/arch/mips/mips-boards/sead/sead_setup.c - 1.1 linux/arch/mips/mips-boards/sead/sead_time.c - 1.1 linux/arch/mips64/mm/sc-rm7k.c - 1.1 linux/arch/mips64/mm/sc-r5k.c - 1.1 linux/arch/mips/mm/c-r3k.c - 1.1 linux/arch/mips/mm/c-r4k.c - 1.1 linux/arch/mips/mm/c-sb1.c - 1.1 linux/arch/mips/mm/c-tx39.c - 1.1 linux/arch/mips/mm/cache.c - 1.1 linux/arch/mips/mm/cerr-sb1.c - 1.1 linux/arch/mips/mm/cex-sb1.S - 1.1 linux/arch/mips64/mm/sc-ip22.c - 1.1 linux/include/asm-sh/cpu-sh3/cacheflush.h - 1.1 linux/arch/mips/mm/highmem.c - 1.1 linux/arch/mips64/mm/pgtable.c - 1.1 linux/arch/mips64/mm/pg-sb1.c - 1.1 linux/arch/mips64/mm/pg-r4k.c - 1.1 linux/include/asm-mips/sections.h - 1.1 linux/arch/mips/mm/pg-r3k.c - 1.1 linux/arch/mips/mm/pg-r4k.S - 1.1 linux/arch/mips/mm/pg-sb1.c - 1.1 linux/arch/mips/mm/pgtable.c - 1.1 linux/include/asm-sh/cpu-sh3/cache.h - 1.1 linux/include/asm-sh/cpu-sh3/addrspace.h - 1.1 linux/include/asm-sh/cpu-sh2/watchdog.h - 1.1 linux/include/asm-mips/rtc.h - 1.1 linux/include/asm-sh/cpu-sh2/cacheflush.h - 1.1 linux/arch/mips/mm/sc-ip22.c - 1.1 linux/arch/mips/mm/sc-r5k.c - 1.1 linux/arch/mips/mm/sc-rm7k.c - 1.1 linux/arch/mips/mm/tlb-r3k.c - 1.1 linux/arch/mips/mm/tlb-r4k.c - 1.1 linux/arch/mips/mm/tlb-sb1.c - 1.1 linux/arch/mips/mm/tlbex-r3k.S - 1.1 linux/arch/mips/mm/tlbex-r4k.S - 1.1 linux/arch/mips64/mm/cex-sb1.S - 1.1 linux/arch/mips/momentum/ocelot_c/Makefile - 1.1 linux/arch/mips/momentum/ocelot_c/cpci-irq.c - 1.1 linux/arch/mips/momentum/ocelot_c/dbg_io.c - 1.1 linux/arch/mips/momentum/ocelot_c/int-handler.S - 1.1 linux/arch/mips/momentum/ocelot_c/irq.c - 1.1 linux/arch/mips/momentum/ocelot_c/mv-irq.c - 1.1 linux/arch/mips/momentum/ocelot_c/ocelot_c_fpga.h - 1.1 linux/arch/mips/momentum/ocelot_c/pci-irq.c - 1.1 linux/arch/mips/momentum/ocelot_c/prom.c - 1.1 linux/arch/mips/momentum/ocelot_c/reset.c - 1.1 linux/arch/mips/momentum/ocelot_c/setup.c - 1.1 linux/arch/mips/momentum/ocelot_c/uart-irq.c - 1.1 linux/arch/mips/momentum/ocelot_g/Makefile - 1.1 linux/arch/mips/momentum/ocelot_g/dbg_io.c - 1.1 linux/arch/mips/momentum/ocelot_g/gt-irq.c - 1.1 linux/arch/mips/momentum/ocelot_g/gt64240.h - 1.1 linux/arch/mips/momentum/ocelot_g/gt64240_dep.h - 1.1 linux/arch/mips/momentum/ocelot_g/int-handler.S - 1.1 linux/arch/mips/momentum/ocelot_g/irq.c - 1.1 linux/arch/mips/momentum/ocelot_g/ocelot_pld.h - 1.1 linux/arch/mips/momentum/ocelot_g/pci-irq.c - 1.1 linux/arch/mips/momentum/ocelot_g/prom.c - 1.1 linux/arch/mips/momentum/ocelot_g/reset.c - 1.1 linux/arch/mips/momentum/ocelot_g/setup.c - 1.1 linux/arch/mips/pci/Makefile - 1.1 linux/arch/mips/pci/common.c - 1.1 linux/arch/mips/pci/fixup-au1000.c - 1.1 linux/arch/mips/pci/fixup-capcella.c - 1.1 linux/arch/mips/pci/fixup-eagle.c - 1.1 linux/arch/mips/pci/fixup-ite8172g.c - 1.1 linux/arch/mips/pci/fixup-ivr.c - 1.1 linux/arch/mips/pci/fixup-jmr3927.c - 1.1 linux/arch/mips/pci/fixup-ocelot.c - 1.1 linux/arch/mips/pci/fixup-tb0226.c - 1.1 linux/arch/mips/pci/fixup-tb0229.c - 1.1 linux/arch/mips/pci/fixup-victor-mpc30x.c - 1.1 linux/arch/mips/pci/fixups-ev96100.c - 1.1 linux/arch/mips/pci/ops-au1000.c - 1.1 linux/arch/mips/pci/ops-ddb5074.c - 1.1 linux/arch/mips/pci/ops-ddb5476.c - 1.1 linux/arch/mips/pci/ops-ddb5477.c - 1.1 linux/arch/mips/pci/ops-ev64120.c - 1.1 linux/arch/mips/pci/ops-ev96100.c - 1.1 linux/arch/mips/pci/ops-it8172.c - 1.1 linux/arch/mips/pci/ops-jmr3927.c - 1.1 linux/arch/mips/pci/ops-ocelot.c - 1.1 linux/arch/mips/pci/ops-vrc4173.c - 1.1 linux/arch/mips/pci/pci-auto.c - 1.1 linux/arch/mips/pci/pci-cobalt.c - 1.1 linux/arch/mips/pci/pci-ddb5074.c - 1.1 linux/arch/mips/pci/pci-ddb5476.c - 1.1 linux/arch/mips/pci/pci-ddb5477.c - 1.1 linux/arch/mips/pci/pci-hplj.c - 1.1 linux/arch/mips/pci/pci-ip27.c - 1.1 linux/arch/mips/pci/pci-ip32.c - 1.1 linux/arch/mips/pci/pci-lasat.c - 1.1 linux/arch/mips/pci/pci-mips.c - 1.1 linux/arch/mips/pci/pci-ocelot-c.c - 1.1 linux/arch/mips/pci/pci-ocelot-g.c - 1.1 linux/arch/mips/pci/pci-sb1250.c - 1.1 linux/arch/mips/pci/pci-sni.c - 1.1 linux/arch/mips/pci/pci-vr41xx.c - 1.1 linux/arch/mips/pci/pci-vr41xx.h - 1.1 linux/arch/mips/pci/pci.c - 1.1 linux/arch/mips64/mm/cerr-sb1.c - 1.1 linux/arch/mips64/mm/cache.c - 1.1 linux/arch/mips64/mm/c-sb1.c - 1.1 linux/arch/mips64/mm/c-r4k.c - 1.1 linux/include/asm-sh/cpu-sh2/cache.h - 1.1 linux/include/asm-sh/cat68701/io.h - 1.1 linux/include/asm-sh/cacheflush.h - 1.1 linux/arch/mips/sgi-ip22/ip22-berr.c - 1.1 linux/include/asm-mips/pgtable-bits.h - 1.1 linux/include/asm-mips/percpu.h - 1.1 linux/include/asm-sh/bigsur/serial.h - 1.1 linux/include/asm-mips/pb1500.h - 1.1 linux/arch/mips/ramdisk/Makefile - 1.1 linux/arch/mips/ramdisk/ld.script - 1.1 linux/arch/mips/sgi-ip22/Makefile - 1.1 linux/arch/mips/sibyte/swarm/time.c - 1.1 linux/arch/mips/sgi-ip22/ip22-eisa.c - 1.1 linux/arch/mips/sgi-ip22/ip22-hpc.c - 1.1 linux/include/asm-sh/bigsur/io.h - 1.1 linux/include/asm-sh/bigsur/bigsur.h - 1.1 linux/arch/mips/sgi-ip22/ip22-ksyms.c - 1.1 linux/arch/mips/sgi-ip22/ip22-mc.c - 1.1 linux/arch/mips/sgi-ip22/ip22-nvram.c - 1.1 linux/arch/mips/sgi-ip22/ip22-reset.c - 1.1 linux/arch/mips/sgi-ip22/ip22-rtc.c - 1.1 linux/arch/mips/sgi-ip22/ip22-setup.c - 1.1 linux/arch/mips/sgi-ip22/ip22-time.c - 1.1 linux/arch/mips/sgi-ip27/Makefile - 1.1 linux/arch/mips/sgi-ip27/TODO - 1.1 linux/arch/mips/sgi-ip27/ip27-berr.c - 1.1 linux/arch/mips/sgi-ip27/ip27-console.c - 1.1 linux/arch/mips/sgi-ip27/ip27-init.c - 1.1 linux/arch/mips/sgi-ip27/ip27-irq-glue.S - 1.1 linux/arch/mips/sgi-ip27/ip27-irq.c - 1.1 linux/arch/mips/sgi-ip27/ip27-klconfig.c - 1.1 linux/arch/mips/sgi-ip27/ip27-klnuma.c - 1.1 linux/arch/mips/sgi-ip27/ip27-memory.c - 1.1 linux/arch/mips/sgi-ip27/ip27-nmi.c - 1.1 linux/arch/mips/sgi-ip27/ip27-reset.c - 1.1 linux/arch/mips/sgi-ip27/ip27-setup.c - 1.1 linux/arch/mips/sgi-ip27/ip27-timer.c - 1.1 linux/arch/mips/sgi-ip32/Makefile - 1.1 linux/arch/mips/sgi-ip32/crime.c - 1.1 linux/arch/mips/sgi-ip32/ip32-berr.c - 1.1 linux/arch/mips/sgi-ip32/ip32-irq-glue.S - 1.1 linux/arch/mips/sgi-ip32/ip32-irq.c - 1.1 linux/arch/mips/sgi-ip32/ip32-reset.c - 1.1 linux/arch/mips/sgi-ip32/ip32-rtc.c - 1.1 linux/arch/mips/sgi-ip32/ip32-setup.c - 1.1 linux/arch/mips/sgi-ip32/ip32-timer.c - 1.1 linux/include/asm-mips/au1000_dma.h - 1.1 linux/include/asm-mips/au1000_gpio.h - 1.1 linux/include/asm-mips/au1000_pcmcia.h - 1.1 linux/include/asm-mips/au1000_usbdev.h - 1.1 linux/include/asm-mips/break.h - 1.1 linux/include/asm-sh/adx/io.h - 1.1 linux/include/asm-mips/cacheflush.h - 1.1 linux/include/asm-mips/cobalt/cobalt.h - 1.1 linux/include/asm-mips/db1x00.h - 1.1 linux/include/asm-mips/ddb5xxx/ddb5074.h - 1.1 linux/include/asm-mips/ddb5xxx/ddb5476.h - 1.1 linux/arch/mips/sibyte/cfe/Makefile - 1.1 linux/arch/mips/sibyte/cfe/cfe_api.c - 1.1 linux/arch/mips/sibyte/cfe/cfe_api.h - 1.1 linux/arch/mips/sibyte/cfe/cfe_api_int.h - 1.1 linux/arch/mips/sibyte/cfe/cfe_error.h - 1.1 linux/arch/mips/sibyte/cfe/console.c - 1.1 linux/arch/mips/sibyte/cfe/setup.c - 1.1 linux/arch/mips/sibyte/cfe/smp.c - 1.1 linux/arch/mips/sibyte/sb1250/Makefile - 1.1 linux/arch/mips/sibyte/sb1250/bcm1250_tbprof.c - 1.1 linux/arch/mips/sibyte/sb1250/bus_watcher.c - 1.1 linux/arch/mips/sibyte/sb1250/irq.c - 1.1 linux/arch/mips/sibyte/sb1250/irq_handler.S - 1.1 linux/arch/mips/sibyte/sb1250/prom.c - 1.1 linux/arch/mips/sibyte/sb1250/setup.c - 1.1 linux/arch/mips/sibyte/sb1250/smp.c - 1.1 linux/arch/mips/sibyte/sb1250/time.c - 1.1 linux/arch/mips/sibyte/swarm/Makefile - 1.1 linux/arch/mips/sibyte/swarm/cmdline.c - 1.1 linux/arch/mips/sibyte/swarm/dbg_io.c - 1.1 linux/arch/mips/sibyte/swarm/rtc.c - 1.1 linux/arch/mips/sibyte/swarm/rtc_m41t81.c - 1.1 linux/arch/mips/sibyte/swarm/rtc_xicor1241.c - 1.1 linux/arch/mips/sibyte/swarm/setup.c - 1.1 linux/arch/mips/tx4927/common/tx4927_dbgio.c - 1.1 linux/include/asm-mips/debug.h - 1.1 linux/include/asm-mips/dec/ecc.h - 1.1 linux/arch/mips/tx4927/common/Makefile - 1.1 linux/arch/mips/vr41xx/tanbac-tb0226/Makefile - 1.1 linux/arch/mips/tx4927/common/tx4927_irq.c - 1.1 linux/arch/mips/tx4927/common/tx4927_irq_handler.S - 1.1 linux/arch/mips/tx4927/common/tx4927_prom.c - 1.1 linux/arch/mips/tx4927/common/tx4927_setup.c - 1.1 linux/arch/mips/tx4927/toshiba_rbtx4927/Makefile - 1.1 linux/arch/mips/tx4927/toshiba_rbtx4927/toshiba_rbtx4927_irq.c - 1.1 linux/arch/mips/tx4927/toshiba_rbtx4927/toshiba_rbtx4927_pci_fixup.c - 1.1 linux/arch/mips/tx4927/toshiba_rbtx4927/toshiba_rbtx4927_pci_ops.c - 1.1 linux/arch/mips/tx4927/toshiba_rbtx4927/toshiba_rbtx4927_prom.c - 1.1 linux/arch/mips/tx4927/toshiba_rbtx4927/toshiba_rbtx4927_setup.c - 1.1 linux/include/asm-mips/dec/kn02ba.h - 1.1 linux/arch/mips/vr41xx/casio-e55/Makefile - 1.1 linux/arch/mips/vr41xx/casio-e55/ide-e55.c - 1.1 linux/arch/mips/vr41xx/casio-e55/init.c - 1.1 linux/arch/mips/vr41xx/casio-e55/setup.c - 1.1 linux/arch/mips/vr41xx/common/Makefile - 1.1 linux/arch/mips/vr41xx/common/bcu.c - 1.1 linux/arch/mips/vr41xx/common/cmu.c - 1.1 linux/arch/mips/vr41xx/common/giu.c - 1.1 linux/arch/mips/vr41xx/common/icu.c - 1.1 linux/arch/mips/vr41xx/common/int-handler.S - 1.1 linux/arch/mips/vr41xx/common/reset.c - 1.1 linux/arch/mips/vr41xx/common/serial.c - 1.1 linux/arch/mips/vr41xx/common/time.c - 1.1 linux/arch/mips/vr41xx/common/vrc4173.c - 1.1 linux/arch/mips/vr41xx/ibm-workpad/Makefile - 1.1 linux/arch/mips/vr41xx/ibm-workpad/ide-workpad.c - 1.1 linux/arch/mips/vr41xx/ibm-workpad/init.c - 1.1 linux/arch/mips/vr41xx/ibm-workpad/setup.c - 1.1 linux/arch/mips/vr41xx/nec-eagle/Makefile - 1.1 linux/arch/mips/vr41xx/nec-eagle/ide-eagle.c - 1.1 linux/arch/mips/vr41xx/nec-eagle/init.c - 1.1 linux/arch/mips/vr41xx/nec-eagle/irq.c - 1.1 linux/arch/mips/vr41xx/nec-eagle/setup.c - 1.1 linux/arch/mips/vr41xx/tanbac-tb0226/setup.c - 1.1 linux/arch/mips/vr41xx/tanbac-tb0226/init.c - 1.1 linux/include/asm-mips/dec/kn230.h - 1.1 linux/arch/mips/vr41xx/tanbac-tb0229/Makefile - 1.1 linux/arch/mips/vr41xx/tanbac-tb0229/init.c - 1.1 linux/arch/mips/vr41xx/tanbac-tb0229/reboot.c - 1.1 linux/arch/mips/vr41xx/tanbac-tb0229/setup.c - 1.1 linux/arch/mips/vr41xx/victor-mpc30x/Makefile - 1.1 linux/arch/mips/vr41xx/victor-mpc30x/ide-mpc30x.c - 1.1 linux/arch/mips/vr41xx/victor-mpc30x/init.c - 1.1 linux/arch/mips/vr41xx/victor-mpc30x/setup.c - 1.1 linux/arch/mips/vr41xx/zao-capcella/Makefile - 1.1 linux/arch/mips/vr41xx/zao-capcella/ide-capcella.c - 1.1 linux/arch/mips/vr41xx/zao-capcella/init.c - 1.1 linux/arch/mips/vr41xx/zao-capcella/setup.c - 1.1 linux/include/asm-mips/pb1100.h - 1.1 linux/include/asm-mips/pb1000.h - 1.1 linux/include/asm-mips/dec/kn02ca.h - 1.1 linux/include/asm-mips/dec/kn05.h - 1.1 linux/include/asm-mips/dec/prom.h - 1.1 linux/include/asm-mips/mips-boards/msc01_pci.h - 1.1 linux/include/asm-mips/dec/rtc-dec.h - 1.1 linux/include/asm-mips/mv64340_dep.h - 1.1 linux/include/asm-mips/mv64340.h - 1.1 linux/arch/mips64/lib/promlib.c - 1.1 linux/include/asm-mips/fixmap.h - 1.1 linux/include/asm-mips/fpu.h - 1.1 linux/include/asm-mips/mips-boards/seadint.h - 1.1 linux/include/asm-mips/mips-boards/sead.h - 1.1 linux/include/asm-mips/lasat/lasatint.h - 1.1 linux/include/asm-mips/mips-boards/bonito64.h - 1.1 linux/include/asm-mips/galileo-boards/ev64120.h - 1.1 linux/arch/mips64/defconfig-atlas - 1.1 linux/arch/mips64/defconfig-decstation - 1.1 linux/include/asm-mips/lasat/serial.h - 1.1 linux/include/asm-mips/lasat/picvue.h - 1.1 linux/net/unix/sysctl_net_unix.c - 1.9 linux/net/sunrpc/sysctl.c - 1.11 linux/net/sunrpc/svcsock.c - 1.34 linux/net/sunrpc/svcauth.c - 1.10 linux/net/sunrpc/svc.c - 1.23 linux/net/sched/sch_teql.c - 1.14 linux/net/sched/cls_rsvp.h - 1.6 linux/net/rose/sysctl_net_rose.c - 1.6 linux/net/netsyms.c - 1.71 linux/net/netrom/sysctl_net_netrom.c - 1.6 linux/net/ipv6/udp.c - 1.45 linux/net/ipv6/tcp_ipv6.c - 1.56 linux/net/ipv6/sysctl_net_ipv6.c - 1.7 linux/net/ipv6/route.c - 1.36 linux/net/ipv6/reassembly.c - 1.20 linux/net/ipv6/raw.c - 1.38 linux/net/ipv6/ndisc.c - 1.37 linux/net/ipv6/mcast.c - 1.29 linux/net/ipv6/ip6_output.c - 1.26 linux/net/ipv6/ip6_flowlabel.c - 1.7 linux/net/ipv6/exthdrs.c - 1.13 linux/net/ipv6/af_inet6.c - 1.37 linux/net/ipv6/addrconf.c - 1.39 linux/net/ipv4/utils.c - 1.6 linux/net/ipv4/tcp_output.c - 1.41 linux/net/ipv4/tcp_input.c - 1.52 linux/net/ipv4/raw.c - 1.37 linux/net/ipv4/ipmr.c - 1.30 linux/net/ipv4/ip_output.c - 1.50 linux/net/ipv4/igmp.c - 1.28 linux/net/ipv4/icmp.c - 1.42 linux/net/core/dev.c - 1.78 linux/net/ax25/sysctl_net_ax25.c - 1.7 linux/mm/swap.c - 1.37 linux/mm/slab.c - 1.60 linux/mm/mmap.c - 1.79 linux/lib/Makefile - 1.23 linux/kernel/sys.c - 1.54 linux/kernel/sched.c - 1.105 linux/kernel/printk.c - 1.34 linux/kernel/module.c - 1.45 linux/kernel/ksyms.c - 1.193 linux/kernel/fork.c - 1.94 linux/kernel/exit.c - 1.70 linux/ipc/util.c - 1.25 linux/include/net/tcp.h - 1.50 linux/include/net/ndisc.h - 1.9 linux/include/net/ipv6.h - 1.18 linux/include/net/ip.h - 1.28 linux/include/net/dst.h - 1.16 linux/include/net/addrconf.h - 1.14 linux/include/linux/sunrpc/svc.h - 1.17 linux/include/linux/sunrpc/debug.h - 1.7 linux/include/linux/smb_fs.h - 1.23 linux/include/linux/rtnetlink.h - 1.19 linux/include/linux/pci.h - 1.78 linux/include/linux/nfsd/nfsd.h - 1.23 linux/include/linux/nfs.h - 1.10 linux/include/linux/netdevice.h - 1.49 linux/include/linux/mroute.h - 1.7 linux/include/linux/module.h - 1.52 linux/include/linux/loop.h - 1.14 linux/include/linux/if_ether.h - 1.13 linux/include/linux/elf.h - 1.28 linux/include/linux/cdrom.h - 1.28 linux/include/asm-sparc64/unistd.h - 1.31 linux/include/asm-sparc/unistd.h - 1.29 linux/include/asm-ppc/ptrace.h - 1.14 linux/include/asm-ppc/hardirq.h - 1.26 linux/include/asm-mips/watch.h - 1.6 linux/include/asm-mips/vga.h - 1.4 linux/include/asm-mips/user.h - 1.3 linux/include/asm-mips/unistd.h - 1.15 linux/include/asm-mips/unaligned.h - 1.6 linux/include/asm-mips/ucontext.h - 1.5 linux/include/asm-mips/uaccess.h - 1.9 linux/include/asm-mips/types.h - 1.7 linux/include/asm-mips/timex.h - 1.5 linux/include/asm-mips/system.h - 1.13 linux/include/asm-mips/string.h - 1.7 linux/include/asm-mips/statfs.h - 1.3 linux/include/asm-mips/stat.h - 1.7 linux/include/asm-mips/stackframe.h - 1.7 linux/include/asm-mips/spinlock.h - 1.9 linux/include/asm-mips/softirq.h - 1.8 linux/include/asm-mips/smplock.h - 1.8 linux/include/asm-mips/smp.h - 1.4 linux/include/asm-mips/signal.h - 1.8 linux/include/asm-mips/siginfo.h - 1.10 linux/include/asm-mips/sigcontext.h - 1.5 linux/include/asm-mips/shmparam.h - 1.7 linux/include/asm-mips/shmiq.h - 1.4 linux/include/asm-mips/sgiarcs.h - 1.6 linux/include/asm-mips/sgialib.h - 1.7 linux/include/asm-mips/serial.h - 1.6 linux/include/asm-mips/semaphore.h - 1.10 linux/include/asm-mips/scatterlist.h - 1.5 linux/include/asm-mips/rrm.h - 1.3 linux/include/asm-mips/reg.h - 1.4 linux/include/asm-mips/r4kcache.h - 1.5 linux/include/asm-mips/ptrace.h - 1.10 linux/include/asm-mips/processor.h - 1.23 linux/include/asm-mips/prctl.h - 1.5 linux/include/asm-mips/posix_types.h - 1.7 linux/include/asm-mips/poll.h - 1.3 linux/include/asm-mips/pgtable.h - 1.22 linux/include/asm-mips/pci.h - 1.17 linux/include/asm-mips/param.h - 1.6 linux/include/asm-mips/page.h - 1.11 linux/include/asm-mips/ng1.h - 1.6 linux/include/asm-mips/namei.h - 1.6 linux/include/asm-mips/mmu_context.h - 1.9 linux/include/asm-mips/mman.h - 1.5 linux/include/asm-mips/mipsregs.h - 1.11 linux/include/asm-mips/mc146818rtc.h - 1.7 linux/include/asm-mips/keyboard.h - 1.11 linux/include/asm-mips/irq.h - 1.9 linux/include/asm-mips/ipc.h - 1.4 linux/include/asm-mips/ioctls.h - 1.8 linux/include/asm-mips/io.h - 1.9 linux/include/asm-mips/inventory.h - 1.5 linux/include/asm-mips/ide.h - 1.15 linux/include/asm-mips/hardirq.h - 1.11 linux/include/asm-mips/gfx.h - 1.6 linux/include/asm-mips/gdb-stub.h - 1.5 linux/include/asm-mips/fp.h - 1.5 linux/include/asm-mips/floppy.h - 1.7 linux/include/asm-mips/fcntl.h - 1.11 linux/include/asm-mips/errno.h - 1.6 linux/include/asm-mips/elf.h - 1.13 linux/include/asm-mips/ds1286.h - 1.6 linux/include/asm-mips/dma.h - 1.7 linux/include/asm-mips/delay.h - 1.9 linux/include/asm-mips/current.h - 1.6 linux/include/asm-mips/cpu.h - 1.7 linux/include/asm-mips/checksum.h - 1.8 linux/include/asm-mips/cacheops.h - 1.3 linux/include/asm-mips/cache.h - 1.7 linux/include/asm-mips/byteorder.h - 1.5 linux/include/asm-mips/bugs.h - 1.6 linux/include/asm-mips/branch.h - 1.5 linux/include/asm-mips/bootinfo.h - 1.11 linux/include/asm-mips/bitops.h - 1.11 linux/include/asm-mips/bcache.h - 1.6 linux/include/asm-mips/atomic.h - 1.9 linux/include/asm-mips/asmmacro.h - 1.6 linux/include/asm-mips/asm.h - 1.5 linux/include/asm-mips/addrspace.h - 1.4 linux/include/asm-i386/scatterlist.h - 1.5 linux/include/asm-alpha/pci.h - 1.23 linux/include/asm-alpha/elf.h - 1.10 linux/fs/smbfs/proc.c - 1.30 linux/fs/smbfs/inode.c - 1.48 linux/fs/nfsd/nfssvc.c - 1.36 linux/fs/nfsd/nfsctl.c - 1.44 linux/fs/nfsd/nfs3xdr.c - 1.39 linux/fs/nfsd/export.c - 1.55 linux/fs/nfs/dir.c - 1.52 linux/fs/lockd/svc.c - 1.27 linux/fs/dcache.c - 1.55 linux/fs/buffer.c - 1.158 linux/fs/binfmt_elf.c - 1.59 linux/drivers/sgi/char/usema.c - 1.11 linux/drivers/sgi/char/streamable.c - 1.11 linux/drivers/sgi/char/shmiq.c - 1.22 linux/drivers/sgi/char/sgiserial.h - 1.6 linux/drivers/sgi/char/sgiserial.c - 1.19 linux/drivers/sgi/char/sgicons.c - 1.6 linux/drivers/sgi/char/rrm.c - 1.6 linux/drivers/sgi/char/newport.c - 1.7 linux/drivers/sgi/char/graphics.h - 1.4 linux/drivers/sgi/char/graphics.c - 1.21 linux/drivers/sgi/char/gconsole.h - 1.3 linux/drivers/sgi/char/Makefile - 1.9 linux/drivers/sgi/Makefile - 1.8 linux/drivers/scsi/sym53c8xx_defs.h - 1.15 linux/drivers/scsi/sym53c416.h - 1.10 linux/drivers/scsi/st.c - 1.68 linux/drivers/scsi/sr.c - 1.70 linux/drivers/scsi/sg.c - 1.55 linux/drivers/scsi/seagate.h - 1.9 linux/drivers/scsi/seagate.c - 1.28 linux/drivers/scsi/sd.c - 1.90 linux/drivers/scsi/scsi_syms.c - 1.35 linux/drivers/scsi/scsi_ioctl.c - 1.32 linux/drivers/scsi/scsi_error.c - 1.46 linux/drivers/scsi/scsi.h - 1.54 linux/drivers/scsi/scsi.c - 1.79 linux/drivers/scsi/ncr53c8xx.h - 1.13 linux/drivers/scsi/ncr53c8xx.c - 1.37 linux/drivers/scsi/megaraid.c - 1.49 linux/drivers/scsi/ibmmca.h - 1.13 linux/drivers/scsi/ibmmca.c - 1.28 linux/drivers/scsi/hosts.h - 1.43 linux/drivers/scsi/hosts.c - 1.48 linux/drivers/scsi/gdth.c - 1.31 linux/drivers/scsi/fd_mcs.c - 1.17 linux/drivers/scsi/aha1740.h - 1.10 linux/drivers/scsi/aha1740.c - 1.20 linux/drivers/scsi/NCR53C9x.c - 1.27 linux/drivers/scsi/Makefile - 1.54 linux/drivers/pci/pci.c - 1.68 linux/drivers/pci/Makefile - 1.35 linux/drivers/net/sunhme.c - 1.45 linux/drivers/net/sgiseeq.h - 1.6 linux/drivers/net/sgiseeq.c - 1.22 linux/drivers/net/irda/Makefile - 1.25 linux/drivers/net/eepro100.c - 1.61 linux/drivers/net/acenic.c - 1.48 linux/drivers/net/Space.c - 1.46 linux/drivers/net/Makefile - 1.74 linux/drivers/char/n_tty.c - 1.21 linux/drivers/block/rd.c - 1.75 linux/drivers/block/nbd.c - 1.57 linux/drivers/block/loop.c - 1.86 linux/drivers/Makefile - 1.46 linux/arch/sparc64/solaris/fs.c - 1.23 linux/arch/sparc64/prom/init.c - 1.5 linux/arch/sparc64/mm/fault.c - 1.27 linux/arch/sparc64/kernel/traps.c - 1.29 linux/arch/sparc64/kernel/systbls.S - 1.46 linux/arch/sparc64/defconfig - 1.97 linux/arch/sparc/kernel/systbls.S - 1.31 linux/arch/sparc/kernel/process.c - 1.37 linux/arch/sparc/Makefile - 1.28 linux/arch/ppc/kernel/process.c - 1.52 linux/arch/mips/tools/offset.c - 1.9 linux/arch/mips/tools/Makefile - 1.8 linux/arch/mips/sgi/kernel/time.c - 1.10 linux/arch/mips/sgi/kernel/system.c - 1.7 linux/arch/mips/sgi/kernel/setup.c - 1.11 linux/arch/mips/sgi/kernel/reset.c - 1.9 linux/arch/mips/sgi/kernel/indy_sc.c - 1.11 linux/arch/mips/sgi/kernel/indy_rtc.c - 1.6 linux/arch/mips/sgi/kernel/indy_mc.c - 1.7 linux/arch/mips/sgi/kernel/indy_int.c - 1.12 linux/arch/mips/sgi/kernel/indy_hpc.c - 1.8 linux/arch/mips/sgi/kernel/indyIRQ.S - 1.7 linux/arch/mips/sgi/kernel/Makefile - 1.13 linux/arch/mips/mm/umap.c - 1.10 linux/arch/mips/mm/r4xx0.c - 1.13 linux/arch/mips/mm/r2300.c - 1.13 linux/arch/mips/mm/loadmmu.c - 1.11 linux/arch/mips/mm/init.c - 1.18 linux/arch/mips/mm/fault.c - 1.14 linux/arch/mips/mm/extable.c - 1.5 linux/arch/mips/mm/andes.c - 1.11 linux/arch/mips/mm/Makefile - 1.11 linux/arch/mips/lib/watch.S - 1.6 linux/arch/mips/lib/tinycon.c - 1.3 linux/arch/mips/lib/strncpy_user.S - 1.6 linux/arch/mips/lib/strlen_user.S - 1.6 linux/arch/mips/lib/memset.S - 1.7 linux/arch/mips/lib/memcpy.S - 1.8 linux/arch/mips/lib/ide-std.c - 1.7 linux/arch/mips/lib/ide-no.c - 1.6 linux/arch/mips/lib/floppy-std.c - 1.7 linux/arch/mips/lib/floppy-no.c - 1.5 linux/arch/mips/lib/dump_tlb.c - 1.5 linux/arch/mips/lib/csum_partial_copy.c - 1.7 linux/arch/mips/lib/csum_partial.S - 1.5 linux/arch/mips/lib/Makefile - 1.14 linux/arch/mips/kernel/vm86.c - 1.3 linux/arch/mips/kernel/unaligned.c - 1.8 linux/arch/mips/kernel/traps.c - 1.15 linux/arch/mips/kernel/time.c - 1.17 linux/arch/mips/kernel/sysmips.c - 1.11 linux/arch/mips/kernel/sysirix.c - 1.22 linux/arch/mips/kernel/syscalls.h - 1.12 linux/arch/mips/kernel/syscall.c - 1.11 linux/arch/mips/kernel/signal.c - 1.20 linux/arch/mips/kernel/setup.c - 1.18 linux/arch/mips/kernel/scall_o32.S - 1.11 linux/arch/mips/kernel/r4k_switch.S - 1.10 linux/arch/mips/kernel/r4k_misc.S - 1.10 linux/arch/mips/kernel/r2300_switch.S - 1.10 linux/arch/mips/kernel/r2300_misc.S - 1.7 linux/arch/mips/kernel/ptrace.c - 1.16 linux/arch/mips/kernel/process.c - 1.17 linux/arch/mips/kernel/proc.c - 1.7 linux/arch/mips/kernel/pci.c - 1.13 linux/arch/mips/kernel/mips_ksyms.c - 1.15 linux/arch/mips/kernel/irq.c - 1.18 linux/arch/mips/kernel/irixsig.c - 1.14 linux/arch/mips/kernel/irixioctl.c - 1.10 linux/arch/mips/kernel/irixinv.c - 1.7 linux/arch/mips/kernel/irixelf.c - 1.18 linux/arch/mips/kernel/irix5sys.h - 1.7 linux/arch/mips/kernel/ipc.c - 1.4 linux/arch/mips/kernel/ioport.c - 1.3 linux/arch/mips/kernel/init_task.c - 1.7 linux/arch/mips/kernel/head.S - 1.11 linux/arch/mips/kernel/gdb-stub.c - 1.10 linux/arch/mips/kernel/gdb-low.S - 1.7 linux/arch/mips/kernel/entry.S - 1.10 linux/arch/mips/kernel/branch.c - 1.5 linux/arch/mips/kernel/Makefile - 1.16 linux/arch/mips/defconfig - 1.25 linux/arch/mips/boot/Makefile - 1.14 linux/arch/mips/Makefile - 1.17 linux/arch/i386/kernel/traps.c - 1.81 linux/arch/i386/kernel/io_apic.c - 1.65 linux/arch/i386/kernel/i386_ksyms.c - 1.72 linux/arch/i386/kernel/Makefile - 1.51 linux/arch/alpha/lib/memset.S - 1.3 linux/arch/alpha/kernel/time.c - 1.32 linux/arch/alpha/kernel/process.c - 1.36 linux/arch/alpha/kernel/core_t2.c - 1.15 linux/Makefile - 1.252 linux/MAINTAINERS - 1.143 linux/Documentation/pci.txt - 1.21 linux/include/linux/ide.h - 1.81 linux/fs/hpfs/namei.c - 1.20 linux/include/asm-mips/umap.h - 1.3 linux/include/asm-mips/semaphore-helper.h - 1.7 linux/include/asm-mips/ng1hw.h - 1.5 linux/include/asm-mips/dec/tcmodule.h - 1.3 linux/include/asm-mips/dec/tcinfo.h - 1.2 linux/include/asm-mips/dec/tc.h - 1.2 linux/include/asm-mips/dec/machtype.h - 1.3 linux/include/asm-mips/dec/kn03.h - 1.3 linux/include/asm-mips/dec/kn02xa.h - 1.3 linux/include/asm-mips/dec/kn02.h - 1.3 linux/include/asm-mips/dec/kn01.h - 1.2 linux/include/asm-mips/dec/ioasic_ints.h - 1.3 linux/include/asm-mips/dec/ioasic_addrs.h - 1.3 linux/include/asm-mips/dec/interrupts.h - 1.3 linux/include/asm-mips/baget/vic.h - 1.4 linux/include/asm-mips/baget/vac.h - 1.4 linux/include/asm-mips/baget/baget.h - 1.4 linux/drivers/sgi/char/usema.h - 1.2 linux/drivers/sgi/char/ds1286.c - 1.12 linux/drivers/net/declance.c - 1.21 linux/arch/mips/lib/kbd-std.c - 1.6 linux/arch/mips/lib/kbd-no.c - 1.4 linux/arch/mips/dec/wbflush.c - 1.7 linux/arch/mips/dec/time.c - 1.9 linux/arch/mips/dec/setup.c - 1.5 linux/arch/mips/dec/rtc-dec.c - 1.5 linux/arch/mips/dec/reset.c - 1.4 linux/arch/mips/dec/promcon.c - 1.6 linux/arch/mips/dec/prom/prom.h - 1.2 linux/arch/mips/dec/prom/memory.c - 1.9 linux/arch/mips/dec/prom/locore.S - 1.2 linux/arch/mips/dec/prom/init.c - 1.6 linux/arch/mips/dec/prom/identify.c - 1.5 linux/arch/mips/dec/prom/cmdline.c - 1.6 linux/arch/mips/dec/prom/Makefile - 1.10 linux/arch/mips/dec/irq.c - 1.12 linux/arch/mips/dec/int-handler.S - 1.3 linux/arch/mips/dec/boot/Makefile - 1.7 linux/arch/mips/dec/Makefile - 1.10 linux/arch/mips/boot/elf2ecoff.c - 1.4 linux/arch/mips/boot/addinitrd.c - 1.2 linux/arch/mips/baget/wbflush.c - 1.5 linux/arch/mips/baget/vacserial.c - 1.19 linux/arch/mips/baget/time.c - 1.7 linux/arch/mips/baget/setup.c - 1.7 linux/arch/mips/baget/prom/init.c - 1.6 linux/arch/mips/baget/print.c - 1.5 linux/arch/mips/baget/ld.script.balo - 1.3 linux/arch/mips/baget/irq.c - 1.13 linux/arch/mips/baget/balo_supp.S - 1.4 linux/arch/mips/baget/balo.c - 1.4 linux/arch/mips/baget/bagetIRQ.S - 1.4 linux/arch/mips/baget/baget.c - 1.4 linux/arch/mips/baget/Makefile - 1.10 linux/arch/mips/arc/tree.c - 1.5 linux/arch/mips/arc/time.c - 1.5 linux/arch/mips/arc/salone.c - 1.5 linux/arch/mips/arc/misc.c - 1.8 linux/arch/mips/arc/memory.c - 1.10 linux/arch/mips/arc/init.c - 1.7 linux/arch/mips/arc/identify.c - 1.6 linux/arch/mips/arc/file.c - 1.5 linux/arch/mips/arc/env.c - 1.5 linux/arch/mips/arc/console.c - 1.7 linux/arch/mips/arc/cmdline.c - 1.7 linux/arch/mips/arc/Makefile - 1.9 linux/arch/mips/algor/README - 1.2 linux/drivers/net/ppp_generic.c - 1.40 linux/drivers/char/ip2main.c - 1.30 linux/drivers/atm/eni.c - 1.22 linux/drivers/atm/atmtcp.c - 1.14 linux/net/atm/svc.c - 1.17 linux/net/atm/signaling.c - 1.14 linux/net/atm/resources.h - 1.6 linux/net/atm/resources.c - 1.14 linux/net/atm/pvc.c - 1.15 linux/net/atm/proc.c - 1.22 linux/net/atm/mpc.c - 1.17 linux/net/atm/lec.c - 1.24 linux/net/atm/common.h - 1.8 linux/net/atm/common.c - 1.26 linux/net/atm/clip.c - 1.19 linux/net/atm/atm_misc.c - 1.8 linux/include/linux/netfilter.h - 1.12 linux/include/linux/atmdev.h - 1.18 linux/arch/ppc/kernel/entry.S - 1.37 linux/arch/sh/mm/ioremap.c - 1.9 linux/arch/sh/mm/init.c - 1.23 linux/arch/sh/mm/fault.c - 1.23 linux/arch/sh/mm/extable.c - 1.5 linux/arch/sh/mm/Makefile - 1.9 linux/arch/sh/lib/Makefile - 1.12 linux/arch/sh/kernel/traps.c - 1.14 linux/arch/sh/kernel/time.c - 1.21 linux/arch/sh/kernel/sys_sh.c - 1.11 linux/arch/sh/kernel/signal.c - 1.18 linux/arch/sh/kernel/sh_ksyms.c - 1.13 linux/arch/sh/kernel/setup.c - 1.23 linux/arch/sh/kernel/semaphore.c - 1.7 linux/arch/sh/kernel/ptrace.c - 1.14 linux/arch/sh/kernel/process.c - 1.24 linux/arch/sh/kernel/irq.c - 1.20 linux/arch/sh/kernel/init_task.c - 1.4 linux/arch/sh/kernel/head.S - 1.11 linux/arch/sh/kernel/entry.S - 1.24 linux/arch/sh/kernel/Makefile - 1.21 linux/arch/sh/defconfig - 1.23 linux/arch/sh/boot/Makefile - 1.8 linux/drivers/scsi/ips.c - 1.43 linux/include/asm-sh/unistd.h - 1.16 linux/include/asm-sh/uaccess.h - 1.13 linux/include/asm-sh/types.h - 1.5 linux/include/asm-sh/system.h - 1.14 linux/include/asm-sh/statfs.h - 1.2 linux/include/asm-sh/spinlock.h - 1.5 linux/include/asm-sh/smp.h - 1.2 linux/include/asm-sh/signal.h - 1.7 linux/include/asm-sh/sigcontext.h - 1.6 linux/include/asm-sh/shmparam.h - 1.4 linux/include/asm-sh/semaphore.h - 1.8 linux/include/asm-sh/ptrace.h - 1.9 linux/include/asm-sh/processor.h - 1.22 linux/include/asm-sh/posix_types.h - 1.4 linux/include/asm-sh/poll.h - 1.2 linux/include/asm-sh/pgtable.h - 1.29 linux/include/asm-sh/param.h - 1.3 linux/include/asm-sh/page.h - 1.13 linux/include/asm-sh/mmu_context.h - 1.13 linux/include/asm-sh/mman.h - 1.3 linux/include/asm-sh/irq.h - 1.12 linux/include/asm-sh/ipc.h - 1.2 linux/include/asm-sh/ioctl.h - 1.4 linux/include/asm-sh/io.h - 1.12 linux/include/asm-sh/hw_irq.h - 1.2 linux/include/asm-sh/hardirq.h - 1.9 linux/include/asm-sh/elf.h - 1.9 linux/include/asm-sh/dma.h - 1.6 linux/include/asm-sh/delay.h - 1.8 linux/include/asm-sh/current.h - 1.5 linux/include/asm-sh/cache.h - 1.7 linux/include/asm-sh/byteorder.h - 1.4 linux/include/asm-sh/bugs.h - 1.9 linux/include/asm-sh/bitops.h - 1.9 linux/include/asm-sh/atomic.h - 1.6 linux/include/asm-sh/addrspace.h - 1.3 linux/include/asm-i386/pci.h - 1.23 linux/drivers/pcmcia/tcic.c - 1.29 linux/drivers/pcmcia/i82365.c - 1.43 linux/drivers/pcmcia/cs.c - 1.42 linux/include/pcmcia/ss.h - 1.16 linux/drivers/pcmcia/ti113x.h - 1.11 linux/include/linux/spinlock.h - 1.28 linux/drivers/net/pcmcia/3c589_cs.c - 1.28 linux/include/linux/pci_ids.h - 1.94 linux/drivers/net/wan/sdla_x25.c - 1.19 linux/drivers/net/wan/sdla_ppp.c - 1.24 linux/drivers/net/wan/sdla_fr.c - 1.24 linux/drivers/net/pcmcia/3c574_cs.c - 1.26 linux/drivers/net/pcmcia/nmclan_cs.c - 1.20 linux/drivers/net/pcmcia/fmvj18x_cs.c - 1.25 linux/drivers/net/pcmcia/smc91c92_cs.c - 1.22 linux/include/asm-sh/ide.h - 1.15 linux/include/asm-sh/pgtable-2level.h - 1.9 linux/fs/proc/proc_misc.c - 1.64 linux/ipc/util.h - 1.9 linux/drivers/net/sk98lin/skge.c - 1.27 linux/kernel/timer.c - 1.49 linux/drivers/scsi/scsi_lib.c - 1.67 linux/drivers/i2c/Makefile - 1.15 linux/drivers/net/arcnet/arc-rimi.c - 1.8 linux/drivers/ieee1394/raw1394.c - 1.29 linux/drivers/ieee1394/ieee1394_core.h - 1.18 linux/drivers/ieee1394/ieee1394_core.c - 1.33 linux/drivers/ieee1394/ohci1394.c - 1.34 linux/drivers/ieee1394/ieee1394_types.h - 1.21 linux/drivers/ieee1394/ieee1394_transactions.c - 1.17 linux/drivers/ieee1394/csr.h - 1.6 linux/arch/i386/kernel/apic.c - 1.47 linux/drivers/ieee1394/ieee1394.h - 1.9 linux/drivers/ieee1394/Makefile - 1.22 linux/include/asm-i386/io_apic.h - 1.12 linux/drivers/scsi/scsi_scan.c - 1.51 linux/drivers/net/wan/sdla_chdlc.c - 1.27 linux/arch/ia64/kernel/head.S - 1.17 linux/arch/ia64/kernel/gate.S - 1.17 linux/arch/ia64/kernel/efi.c - 1.23 linux/arch/ia64/kernel/acpi.c - 1.24 linux/arch/ia64/defconfig - 1.26 linux/arch/ia64/Makefile - 1.29 linux/arch/ia64/kernel/init_task.c - 1.9 linux/arch/ia64/kernel/irq.c - 1.31 linux/arch/ia64/lib/Makefile - 1.21 linux/arch/ia64/kernel/perfmon.c - 1.27 linux/arch/ia64/kernel/mca.c - 1.22 linux/include/asm-ia64/pci.h - 1.22 linux/include/asm-ia64/timex.h - 1.6 linux/net/bridge/br_fdb.c - 1.8 linux/net/bridge/br_stp_bpdu.c - 1.6 linux/net/bridge/br_private.h - 1.14 linux/net/bridge/br_input.c - 1.17 linux/net/bridge/br_if.c - 1.15 linux/arch/mips/lib/strnlen_user.S - 1.3 linux/arch/mips/ddb5074/time.c - 1.4 linux/arch/mips/ddb5074/setup.c - 1.5 linux/arch/mips/ddb5074/nile4.c - 1.4 linux/arch/mips/ddb5074/prom.c - 1.4 linux/arch/mips/ddb5074/pci.c - 1.13 linux/arch/mips/lib/r3k_dump_tlb.c - 1.5 linux/arch/mips/ddb5074/irq.c - 1.5 linux/arch/mips/defconfig-decstation - 1.10 linux/arch/mips/ddb5074/int-handler.S - 1.4 linux/arch/mips/defconfig-ip22 - 1.11 linux/arch/mips/ddb5074/Makefile - 1.8 linux/drivers/net/tulip/tulip_core.c - 1.48 linux/drivers/net/ioc3-eth.c - 1.24 linux/include/asm-mips64/io.h - 1.7 linux/include/asm-mips64/inst.h - 1.4 linux/include/asm-mips64/ide.h - 1.12 linux/include/asm-mips64/hardirq.h - 1.6 linux/include/asm-mips64/gfx.h - 1.5 linux/include/asm-mips64/floppy.h - 1.5 linux/include/asm-mips64/fcntl.h - 1.9 linux/include/asm-mips64/errno.h - 1.6 linux/include/asm-mips64/elf.h - 1.11 linux/include/asm-mips64/dma.h - 1.5 linux/include/asm-mips64/div64.h - 1.4 linux/include/asm-mips64/delay.h - 1.7 linux/include/asm-mips64/current.h - 1.4 linux/include/asm-mips64/cpu.h - 1.4 linux/include/asm-mips64/checksum.h - 1.5 linux/include/asm-mips64/cache.h - 1.5 linux/include/asm-mips64/bugs.h - 1.4 linux/include/asm-mips64/branch.h - 1.4 linux/include/asm-mips64/bootinfo.h - 1.6 linux/include/asm-mips64/bitops.h - 1.8 linux/include/asm-mips64/bcache.h - 1.5 linux/include/asm-mips64/atomic.h - 1.7 linux/include/asm-mips64/asmmacro.h - 1.4 linux/include/asm-mips64/asm.h - 1.4 linux/include/asm-mips64/addrspace.h - 1.5 linux/include/asm-mips64/a.out.h - 1.4 linux/include/asm-mips/wbflush.h - 1.4 linux/include/asm-mips/shmbuf.h - 1.3 linux/include/asm-mips/sgi/sgint23.h - 1.4 linux/include/asm-mips/sgi/sgimc.h - 1.4 linux/include/asm-mips/sgi/sgihpc.h - 1.3 linux/include/asm-mips/sgi/sgi.h - 1.3 linux/include/asm-mips/sembuf.h - 1.2 linux/include/asm-mips/pgalloc.h - 1.8 linux/include/asm-mips/parport.h - 1.4 linux/include/asm-mips/nile4.h - 1.3 linux/include/asm-mips/msgbuf.h - 1.2 linux/include/asm-mips/isadep.h - 1.5 linux/include/asm-mips/ipcbuf.h - 1.2 linux/include/asm-mips/highmem.h - 1.4 linux/include/asm-mips/div64.h - 1.5 linux/include/asm-mips64/ipcbuf.h - 1.2 linux/include/asm-mips64/irq.h - 1.7 linux/include/asm-mips64/sn/sn0/ip27.h - 1.6 linux/include/asm-mips64/sn/sn0/addrs.h - 1.4 linux/include/asm-mips64/sn/kldir.h - 1.4 linux/include/asm-mips64/sn/klconfig.h - 1.6 linux/include/asm-mips64/sn/io.h - 1.4 linux/include/asm-mips64/sn/gda.h - 1.4 linux/include/asm-mips64/sn/arch.h - 1.5 linux/include/asm-mips64/sn/addrs.h - 1.4 linux/include/asm-mips64/signal.h - 1.6 linux/include/asm-mips64/siginfo.h - 1.8 linux/include/asm-mips64/xtalk/xwidget.h - 1.4 linux/include/asm-mips64/sigcontext.h - 1.4 linux/include/asm-mips64/shmiq.h - 1.5 linux/include/asm-mips64/shmbuf.h - 1.2 linux/include/asm-mips64/xtalk/xtalk.h - 1.4 linux/include/asm-mips64/watch.h - 1.4 linux/include/asm-mips64/sgiarcs.h - 1.5 linux/include/asm-mips64/sgialib.h - 1.5 linux/include/asm-mips64/sgi/sgint23.h - 1.6 linux/include/asm-mips64/sgi/sgimc.h - 1.4 linux/include/asm-mips64/sgi/sgihpc.h - 1.4 linux/include/asm-mips64/serial.h - 1.6 linux/include/asm-mips64/sembuf.h - 1.2 linux/include/asm-mips64/semaphore.h - 1.6 linux/include/asm-mips64/user.h - 1.4 linux/include/asm-mips64/unistd.h - 1.12 linux/include/asm-mips64/semaphore-helper.h - 1.5 linux/include/asm-mips64/scatterlist.h - 1.4 linux/include/asm-mips64/unaligned.h - 1.5 linux/include/asm-mips64/reg.h - 1.2 linux/include/asm-mips64/r4kcacheops.h - 1.4 linux/include/asm-mips64/r4kcache.h - 1.4 linux/include/asm-mips64/r10kcacheops.h - 1.4 linux/include/asm-mips64/r10kcache.h - 1.5 linux/include/asm-mips64/ptrace.h - 1.6 linux/include/asm-mips64/processor.h - 1.16 linux/include/asm-mips64/posix_types.h - 1.6 linux/include/asm-mips64/poll.h - 1.4 linux/include/asm-mips64/pgtable.h - 1.19 linux/include/asm-mips64/pgalloc.h - 1.10 linux/include/asm-mips64/uaccess.h - 1.6 linux/include/asm-mips64/pci/bridge.h - 1.5 linux/include/asm-mips64/pci.h - 1.13 linux/include/asm-mips64/types.h - 1.5 linux/include/asm-mips64/param.h - 1.5 linux/include/asm-mips64/page.h - 1.8 linux/include/asm-mips64/paccess.h - 1.4 linux/include/asm-mips64/timex.h - 1.4 linux/include/asm-mips64/system.h - 1.8 linux/include/asm-mips64/statfs.h - 1.4 linux/include/asm-mips64/stat.h - 1.6 linux/include/asm-mips64/stackframe.h - 1.3 linux/include/asm-mips64/spinlock.h - 1.5 linux/include/asm-mips64/softirq.h - 1.5 linux/include/asm-mips64/sn/sn0/sn0_fru.h - 1.4 linux/include/asm-mips64/sn/sn0/hubpi.h - 1.4 linux/include/asm-mips64/msgbuf.h - 1.2 linux/include/asm-mips64/ipc.h - 1.2 linux/include/asm-mips64/ioctls.h - 1.7 linux/include/asm-mips64/mmu_context.h - 1.8 linux/include/asm-mips64/sn/sn0/hubni.h - 1.4 linux/include/asm-mips64/mmzone.h - 1.11 linux/include/asm-mips64/sn/sn0/hubmd.h - 1.4 linux/include/asm-mips64/sn/sn0/arch.h - 1.4 linux/include/asm-mips64/sn/sn0/hubio.h - 1.5 linux/include/asm-mips64/keyboard.h - 1.6 linux/include/asm-mips64/mman.h - 1.4 linux/include/asm-mips64/mipsregs.h - 1.9 linux/include/asm-mips64/m48t35.h - 1.3 linux/include/asm-mips64/mc146818rtc.h - 1.5 linux/arch/mips64/defconfig - 1.22 linux/arch/mips64/arc/cmdline.c - 1.4 linux/arch/mips64/sgi-ip22/ip22-rtc.c - 1.4 linux/arch/mips64/arc/console.c - 1.5 linux/arch/mips64/arc/env.c - 1.4 linux/arch/mips64/sgi-ip22/ip22-reset.c - 1.5 linux/arch/mips64/sgi-ip22/ip22-int.c - 1.11 linux/arch/mips64/sgi-ip22/ip22-mc.c - 1.4 linux/arch/mips64/sgi-ip22/ip22-irq.S - 1.4 linux/arch/mips64/sgi-ip22/ip22-hpc.c - 1.5 linux/arch/mips64/sgi-ip22/ip22-berr.c - 1.4 linux/arch/mips64/sgi-ip22/Makefile - 1.9 linux/arch/mips64/mm/umap.c - 1.9 linux/arch/mips64/arc/file.c - 1.4 linux/arch/mips64/arc/identify.c - 1.5 linux/arch/mips64/arc/memory.c - 1.7 linux/arch/mips64/mm/init.c - 1.13 linux/arch/mips64/mm/Makefile - 1.8 linux/arch/mips64/mm/fault.c - 1.12 linux/arch/mips64/mm/extable.c - 1.5 linux/arch/mips64/lib/strlen_user.S - 1.4 linux/arch/mips64/lib/strnlen_user.S - 1.4 linux/arch/mips64/lib/strncpy_user.S - 1.4 linux/arch/mips64/lib/memcpy.S - 1.6 linux/drivers/atm/fore200e.c - 1.22 linux/arch/mips64/lib/memset.S - 1.5 linux/arch/mips64/arc/init.c - 1.4 linux/arch/mips64/mm/andes.c - 1.11 linux/arch/mips64/lib/kbd-no.c - 1.4 linux/arch/mips64/lib/ide-std.c - 1.5 linux/arch/mips64/lib/ide-no.c - 1.5 linux/arch/mips64/lib/dump_tlb.c - 1.5 linux/arch/mips64/lib/Makefile - 1.9 linux/arch/mips64/lib/csum_partial_copy.c - 1.5 linux/arch/mips64/ld.script.elf64 - 1.8 linux/arch/mips64/kernel/traps.c - 1.10 linux/arch/mips64/tools/offset.c - 1.6 linux/arch/mips64/kernel/unaligned.c - 1.6 linux/arch/mips64/tools/Makefile - 1.7 linux/arch/mips64/sgi-ip27/ip27-timer.c - 1.12 linux/arch/mips64/sgi-ip27/ip27-setup.c - 1.7 linux/arch/mips64/sgi-ip27/ip27-rtc.c - 1.12 linux/arch/mips64/sgi-ip27/ip27-reset.c - 1.4 linux/arch/mips64/sgi-ip27/ip27-pci.c - 1.10 linux/arch/mips64/sgi-ip27/ip27-pci-dma.c - 1.6 linux/arch/mips64/lib/floppy-std.c - 1.4 linux/arch/mips64/sgi-ip27/ip27-memory.c - 1.12 linux/arch/mips64/arc/time.c - 1.4 linux/arch/mips64/sgi-ip27/ip27-klconfig.c - 1.5 linux/arch/mips64/sgi-ip27/ip27-irq.c - 1.13 linux/arch/mips64/sgi-ip27/ip27-irq-glue.S - 1.4 linux/arch/mips64/arc/tree.c - 1.5 linux/arch/mips64/sgi-ip27/ip27-init.c - 1.12 linux/arch/mips64/sgi-ip27/ip27-berr.c - 1.5 linux/arch/mips64/sgi-ip27/TODO - 1.3 linux/arch/mips64/sgi-ip27/Makefile - 1.11 linux/arch/mips64/sgi-ip22/time.c - 1.4 linux/arch/mips64/sgi-ip22/system.c - 1.4 linux/arch/mips64/sgi-ip22/ip22-timer.c - 1.9 linux/arch/mips64/defconfig-ip22 - 1.13 linux/arch/mips64/kernel/binfmt_elf32.c - 1.8 linux/arch/mips64/kernel/scall_o32.S - 1.13 linux/arch/mips64/kernel/r4k_tlb_debug.c - 1.4 linux/arch/mips64/sgi-ip22/ip22-setup.c - 1.7 linux/arch/mips64/Makefile - 1.17 linux/arch/mips64/arc/Makefile - 1.9 linux/arch/mips64/mm/r4xx0.c - 1.12 linux/arch/mips64/mm/loadmmu.c - 1.7 linux/arch/mips64/lib/kbd-std.c - 1.4 linux/arch/mips64/kernel/syscall.c - 1.13 linux/arch/mips64/kernel/softfp.S - 1.4 linux/arch/mips64/kernel/signal32.c - 1.15 linux/arch/mips64/kernel/signal.c - 1.13 linux/arch/mips64/arc/misc.c - 1.5 linux/arch/mips64/arc/salone.c - 1.4 linux/arch/mips64/kernel/setup.c - 1.9 linux/arch/mips64/boot/Makefile - 1.11 linux/arch/mips64/sgi-ip22/ip22-sc.c - 1.7 linux/arch/mips64/kernel/linux32.c - 1.19 linux/arch/mips64/kernel/scall_64.S - 1.13 linux/arch/mips64/defconfig-ip27 - 1.12 linux/arch/mips64/kernel/Makefile - 1.11 linux/arch/mips64/kernel/r4k_tlb_glue.S - 1.5 linux/arch/mips64/kernel/branch.c - 1.4 linux/arch/mips64/kernel/entry.S - 1.8 linux/arch/mips64/kernel/head.S - 1.5 linux/arch/mips64/kernel/init_task.c - 1.4 linux/arch/mips64/kernel/r4k_switch.S - 1.5 linux/arch/mips64/kernel/mips64_ksyms.c - 1.11 linux/arch/mips64/kernel/proc.c - 1.6 linux/arch/mips64/kernel/process.c - 1.11 linux/arch/mips64/kernel/ptrace.c - 1.11 linux/arch/mips64/kernel/r4k_fpu.S - 1.4 linux/arch/mips64/kernel/r4k_genex.S - 1.4 linux/include/asm-sh/pgalloc.h - 1.9 linux/include/asm-sh/pci.h - 1.17 linux/include/asm-sh/div64.h - 1.2 linux/arch/sh/kernel/cf-enabler.c - 1.6 linux/include/linux/usb.h - 1.62 linux/include/asm-ia64/hw_irq.h - 1.10 linux/arch/ia64/kernel/irq_ia64.c - 1.16 linux/drivers/ide/ide.c - 1.89 linux/drivers/ide/ide-probe.c - 1.56 linux/drivers/ide/ide-pnp.c - 1.14 linux/drivers/ide/ide-dma.c - 1.39 linux/drivers/ide/ide-cd.h - 1.18 linux/drivers/ide/ide-cd.c - 1.65 linux/drivers/scsi/sym53c8xx_comm.h - 1.17 linux/net/ipv4/netfilter/ip_tables.c - 1.21 linux/net/ipv4/netfilter/ip_nat_ftp.c - 1.13 linux/net/ipv4/netfilter/ip_nat_core.c - 1.22 linux/net/ipv4/netfilter/ip_conntrack_ftp.c - 1.16 linux/net/ipv4/netfilter/ip_conntrack_core.c - 1.26 linux/net/ipv4/netfilter/Makefile - 1.22 linux/include/linux/netfilter_ipv4/lockhelp.h - 1.3 linux/include/linux/netfilter_ipv4/listhelp.h - 1.3 linux/drivers/usb/serial/visor.c - 1.53 linux/arch/ia64/kernel/smpboot.c - 1.22 linux/drivers/net/pppoe.c - 1.31 linux/arch/s390/Makefile - 1.18 linux/arch/s390/defconfig - 1.20 linux/arch/s390/kernel/Makefile - 1.15 linux/include/asm-s390/hardirq.h - 1.9 linux/include/asm-s390/elf.h - 1.8 linux/include/asm-s390/statfs.h - 1.3 linux/include/asm-s390/setup.h - 1.8 linux/arch/s390/kernel/entry.S - 1.25 linux/arch/s390/kernel/head.S - 1.12 linux/drivers/s390/net/Makefile - 1.10 linux/drivers/s390/char/con3215.c - 1.19 linux/drivers/s390/block/dasd_eckd.c - 1.17 linux/drivers/s390/block/dasd.c - 1.44 linux/drivers/s390/block/dasd_erp.c - 1.6 linux/include/asm-s390/queue.h - 1.5 linux/arch/s390/kernel/traps.c - 1.19 linux/arch/s390/kernel/smp.c - 1.22 linux/arch/s390/kernel/sys_s390.c - 1.7 linux/net/ipv6/netfilter/ip6_tables.c - 1.20 linux/arch/mips64/kernel/smp.c - 1.13 linux/include/asm-mips64/sn/nmi.h - 1.4 linux/include/asm-mips64/sn/launch.h - 1.4 linux/include/asm-mips64/sn/intr_public.h - 1.2 linux/include/asm-mips64/sn/intr.h - 1.2 linux/include/asm-mips64/smplock.h - 1.4 linux/arch/mips64/kernel/ioctl32.c - 1.17 linux/arch/mips64/sgi-ip27/ip27-nmi.c - 1.5 linux/include/asm-mips64/smp.h - 1.5 linux/include/asm-mips64/hw_irq.h - 1.2 linux/include/asm-mips/paccess.h - 1.2 linux/include/asm-mips/hw_irq.h - 1.3 linux/kernel/kallsyms.c - 1.21 linux/include/asm-mips64/sn/klkernvars.h - 1.2 linux/include/asm-mips64/sn/mapped_kernel.h - 1.4 linux/drivers/usb/storage/usb.h - 1.24 linux/drivers/usb/storage/usb.c - 1.41 linux/drivers/usb/storage/transport.c - 1.46 linux/drivers/usb/storage/scsiglue.c - 1.35 linux/include/asm-sh/keyboard.h - 1.6 linux/drivers/ieee1394/video1394.c - 1.31 linux/drivers/mtd/ftl.c - 1.36 linux/drivers/mtd/mtdblock.c - 1.37 linux/arch/mips/cobalt/Makefile - 1.3 linux/arch/mips/cobalt/int-handler.S - 1.3 linux/arch/mips/cobalt/reset.c - 1.3 linux/arch/mips/cobalt/setup.c - 1.3 linux/arch/mips/cobalt/via.c - 1.3 linux/arch/mips/defconfig-cobalt - 1.5 linux/include/linux/mtd/doc2000.h - 1.7 linux/arch/mips64/sgi-ip27/ip27-klnuma.c - 1.4 linux/arch/mips64/kernel/r4k_tlb.S - 1.3 linux/net/ipv4/tcp_minisocks.c - 1.30 linux/include/asm-sh/machvec.h - 1.5 linux/drivers/media/video/saa7111.c - 1.12 linux/drivers/usb/storage/initializers.c - 1.5 linux/drivers/usb/storage/initializers.h - 1.4 linux/include/asm-mips/module.h - 1.3 linux/include/asm-mips64/module.h - 1.3 linux/include/asm-sh/module.h - 1.3 linux/arch/alpha/lib/ev6-memset.S - 1.3 linux/include/asm-mips64/riscos-syscall.h - 1.2 linux/arch/mips64/sgi-ip27/ip27-console.c - 1.4 linux/drivers/mtd/mtdpart.c - 1.6 linux/include/asm-mips/mmu.h - 1.2 linux/include/asm-mips64/mmu.h - 1.2 linux/include/asm-sh/mmu.h - 1.2 linux/drivers/scsi/osst.c - 1.28 linux/arch/ia64/kernel/iosapic.c - 1.17 linux/include/asm-sh/rtc.h - 1.3 linux/fs/reiserfs/tail_conversion.c - 1.20 linux/drivers/usb/storage/unusual_devs.h - 1.23 linux/include/asm-s390/dasd.h - 1.10 linux/drivers/s390/net/netiucv.c - 1.19 linux/drivers/s390/net/ctcmain.c - 1.17 linux/drivers/s390/block/xpram.c - 1.36 linux/drivers/s390/block/dasd_fba.c - 1.13 linux/drivers/s390/block/dasd_3990_erp.c - 1.15 linux/drivers/usb/serial/io_edgeport.c - 1.37 linux/drivers/net/sungem.c - 1.30 linux/arch/mips/math-emu/sp_tint.c - 1.2 linux/drivers/s390/net/ctctty.c - 1.11 linux/drivers/net/gt96100eth.c - 1.10 linux/arch/mips/mips-boards/malta/malta_setup.c - 1.3 linux/arch/mips/mips-boards/malta/malta_int.c - 1.3 linux/arch/mips/mips-boards/malta/Makefile - 1.5 linux/arch/mips/mips-boards/generic/time.c - 1.6 linux/arch/mips/mips-boards/generic/printf.c - 1.2 linux/arch/mips/mips-boards/generic/pci.c - 1.8 linux/arch/mips/mips-boards/generic/mipsIRQ.S - 1.2 linux/arch/mips/mips-boards/generic/memory.c - 1.3 linux/arch/mips/mips-boards/generic/init.c - 1.2 linux/arch/mips/mips-boards/generic/gdb_hook.c - 1.3 linux/arch/mips/mips-boards/generic/display.c - 1.2 linux/arch/mips/mips-boards/generic/cmdline.c - 1.3 linux/arch/mips/mips-boards/generic/Makefile - 1.6 linux/arch/mips/mips-boards/atlas/atlas_setup.c - 1.3 linux/arch/mips/mips-boards/atlas/atlas_int.c - 1.6 linux/arch/mips/mips-boards/atlas/Makefile - 1.6 linux/arch/mips/math-emu/sp_tlong.c - 1.2 linux/arch/mips/math-emu/sp_sub.c - 1.3 linux/arch/mips/math-emu/sp_sqrt.c - 1.2 linux/arch/mips/math-emu/sp_simple.c - 1.2 linux/arch/mips/math-emu/sp_mul.c - 1.3 linux/arch/mips/math-emu/sp_modf.c - 1.2 linux/arch/mips/math-emu/sp_frexp.c - 1.2 linux/arch/mips/math-emu/sp_flong.c - 1.2 linux/arch/mips/math-emu/sp_fint.c - 1.2 linux/arch/mips/math-emu/sp_fdp.c - 1.3 linux/arch/mips/math-emu/sp_div.c - 1.3 linux/arch/mips/math-emu/sp_cmp.c - 1.2 linux/arch/mips/math-emu/sp_add.c - 1.3 linux/arch/mips/math-emu/kernel_linkage.c - 1.2 linux/arch/mips/math-emu/ieee754xcpt.c - 1.2 linux/arch/mips/math-emu/ieee754sp.h - 1.2 linux/arch/mips/math-emu/ieee754sp.c - 1.3 linux/arch/mips/math-emu/ieee754int.h - 1.2 linux/arch/mips/math-emu/ieee754dp.h - 1.2 linux/arch/mips/math-emu/ieee754dp.c - 1.3 linux/arch/mips/math-emu/ieee754d.c - 1.2 linux/arch/mips/math-emu/ieee754.h - 1.2 linux/arch/mips/math-emu/ieee754.c - 1.3 linux/arch/mips/math-emu/dp_tlong.c - 1.2 linux/arch/mips/math-emu/dp_tint.c - 1.2 linux/arch/mips/math-emu/dp_sub.c - 1.4 linux/arch/mips/math-emu/dp_sqrt.c - 1.2 linux/arch/mips/math-emu/dp_simple.c - 1.2 linux/arch/mips/math-emu/dp_mul.c - 1.3 linux/arch/mips/math-emu/dp_modf.c - 1.2 linux/arch/mips/math-emu/dp_fsp.c - 1.2 linux/arch/mips/math-emu/dp_frexp.c - 1.2 linux/arch/mips/math-emu/dp_flong.c - 1.2 linux/arch/mips/math-emu/dp_div.c - 1.3 linux/arch/mips/math-emu/dp_cmp.c - 1.2 linux/arch/mips/math-emu/dp_add.c - 1.3 linux/arch/mips/math-emu/cp1emu.c - 1.5 linux/arch/mips/math-emu/Makefile - 1.5 linux/arch/mips/defconfig-ddb5476 - 1.9 linux/arch/mips/ddb5476/time.c - 1.2 linux/arch/mips/ddb5476/setup.c - 1.3 linux/arch/mips/ddb5476/prom.c - 1.2 linux/arch/mips/ddb5476/pci.c - 1.8 linux/arch/mips/ddb5476/nile4.c - 1.2 linux/arch/mips/ddb5476/irq.c - 1.2 linux/arch/mips/ddb5476/int-handler.S - 1.3 linux/arch/mips/ddb5476/dbg_io.c - 1.2 linux/arch/mips/ddb5476/Makefile - 1.6 linux/arch/mips/arc/arc_con.c - 1.3 linux/arch/ia64/kernel/efivars.c - 1.11 linux/drivers/mtd/nand/nand.c - 1.4 linux/drivers/mtd/nftlcore.c - 1.34 linux/drivers/mtd/mtdblock_ro.c - 1.21 linux/drivers/mtd/maps/iq80310.c - 1.6 linux/drivers/mtd/maps/elan-104nc.c - 1.7 linux/drivers/mtd/devices/doc2001.c - 1.4 linux/drivers/mtd/devices/doc2000.c - 1.5 linux/drivers/mtd/chips/cfi_cmdset_0001.c - 1.6 linux/drivers/mtd/chips/amd_flash.c - 1.7 linux/drivers/net/wireless/airo.c - 1.31 linux/drivers/usb/serial/pl2303.c - 1.33 linux/arch/sh/kernel/pci-dma.c - 1.4 linux/include/asm-sh/mc146818rtc.h - 1.2 linux/arch/mips64/math-emu/sp_frexp.c - 1.2 linux/include/asm-mips/time.h - 1.3 linux/include/asm-mips/riscos-syscall.h - 1.2 linux/include/asm-mips/tlb.h - 1.2 linux/include/asm-mips/tx3912.h - 1.3 linux/include/asm-mips/fpu_emulator.h - 1.2 linux/arch/mips64/math-emu/sp_tlong.c - 1.2 linux/arch/mips64/math-emu/sp_tint.c - 1.2 linux/arch/mips64/math-emu/sp_sub.c - 1.3 linux/arch/mips64/math-emu/sp_sqrt.c - 1.2 linux/arch/mips64/math-emu/sp_simple.c - 1.2 linux/arch/mips64/math-emu/sp_scalb.c - 1.2 linux/arch/mips64/math-emu/sp_mul.c - 1.3 linux/arch/mips64/math-emu/sp_modf.c - 1.2 linux/arch/mips64/math-emu/sp_logb.c - 1.2 linux/arch/mips64/math-emu/sp_flong.c - 1.2 linux/arch/mips64/math-emu/sp_fint.c - 1.2 linux/arch/mips64/math-emu/sp_fdp.c - 1.3 linux/arch/mips64/math-emu/sp_div.c - 1.3 linux/arch/mips64/math-emu/sp_cmp.c - 1.2 linux/arch/mips64/math-emu/sp_add.c - 1.3 linux/arch/mips64/math-emu/kernel_linkage.c - 1.2 linux/arch/mips64/math-emu/ieee754xcpt.c - 1.2 linux/arch/mips64/math-emu/ieee754sp.h - 1.2 linux/arch/mips64/math-emu/ieee754sp.c - 1.3 linux/arch/mips64/math-emu/ieee754m.c - 1.2 linux/arch/mips64/math-emu/ieee754int.h - 1.2 linux/arch/mips/kernel/i8259.c - 1.3 linux/arch/mips64/math-emu/ieee754dp.h - 1.2 linux/arch/mips64/math-emu/ieee754dp.c - 1.3 linux/arch/mips/kernel/old-irq.c - 1.7 linux/arch/mips/kernel/old-time.c - 1.5 linux/arch/mips/kernel/pci-dma.c - 1.3 linux/arch/mips64/math-emu/ieee754d.c - 1.2 linux/arch/mips64/math-emu/ieee754.h - 1.2 linux/arch/mips64/math-emu/ieee754.c - 1.3 linux/arch/mips64/math-emu/dp_tlong.c - 1.2 linux/arch/mips64/math-emu/dp_tint.c - 1.2 linux/include/asm-mips/mips32_cache.h - 1.2 linux/arch/mips64/math-emu/dp_sub.c - 1.3 linux/arch/mips64/math-emu/dp_sqrt.c - 1.2 linux/arch/mips64/math-emu/dp_simple.c - 1.2 linux/arch/mips64/math-emu/dp_scalb.c - 1.2 linux/arch/mips/kernel/smp.c - 1.12 linux/arch/mips64/math-emu/dp_mul.c - 1.3 linux/include/asm-mips/pmc/ev64120.h - 1.2 linux/include/asm-mips/pmc/ev64120int.h - 1.2 linux/arch/mips64/math-emu/dp_modf.c - 1.2 linux/arch/mips64/math-emu/dp_logb.c - 1.2 linux/arch/mips64/math-emu/dp_fsp.c - 1.2 linux/arch/mips64/math-emu/Makefile - 1.5 linux/arch/mips64/math-emu/dp_frexp.c - 1.2 linux/arch/mips64/math-emu/dp_flong.c - 1.2 linux/arch/mips64/math-emu/dp_fint.c - 1.2 linux/arch/mips64/math-emu/dp_cmp.c - 1.2 linux/arch/mips64/math-emu/cp1emu.c - 1.5 linux/arch/mips64/math-emu/dp_add.c - 1.3 linux/arch/mips64/math-emu/dp_div.c - 1.3 linux/arch/mips64/arc/arc_con.c - 1.2 linux/arch/mips/mm/sb1.c - 1.4 linux/arch/mips/mm/rm7k.c - 1.5 linux/arch/mips/mm/r5432.c - 1.6 linux/arch/mips/mm/mips32.c - 1.6 linux/arch/mips/mm/ioremap.c - 1.3 linux/include/asm-mips64/rrm.h - 1.2 linux/drivers/net/au1000_eth.c - 1.12 linux/drivers/usb/usb-skeleton.c - 1.28 linux/drivers/net/au1000_eth.h - 1.4 linux/drivers/ieee1394/sbp2.c - 1.26 linux/drivers/ieee1394/nodemgr.c - 1.18 linux/drivers/s390/block/dasd_int.h - 1.13 linux/drivers/net/irda/vlsi_ir.c - 1.16 linux/include/net/irda/vlsi_ir.h - 1.6 linux/arch/sh/mm/cache-sh3.c - 1.4 linux/arch/sh/mm/cache-sh4.c - 1.6 linux/arch/sh/mm/clear_page.S - 1.2 linux/arch/sh/mm/copy_page.S - 1.2 linux/include/asm-mips/ddb5xxx/pci.h - 1.2 linux/arch/mips64/sgi-ip32/ip32-timer.c - 1.2 linux/arch/mips64/mips-boards/atlas/atlas_setup.c - 1.2 linux/arch/mips64/sgi-ip32/ip32-setup.c - 1.2 linux/arch/mips64/sgi-ip32/ip32-rtc.c - 1.2 linux/arch/mips64/sgi-ip32/ip32-pci.c - 1.6 linux/arch/mips64/sgi-ip32/ip32-pci-dma.c - 1.2 linux/arch/mips64/sgi-ip32/ip32-irq.c - 1.2 linux/arch/mips64/sgi-ip32/ip32-irq-glue.S - 1.2 linux/arch/mips/au1000/common/Makefile - 1.8 linux/arch/mips/au1000/common/dbg_io.c - 1.2 linux/arch/mips/au1000/common/int-handler.S - 1.2 linux/arch/mips/au1000/common/irq.c - 1.2 linux/arch/mips/au1000/common/prom.c - 1.2 linux/arch/mips/au1000/common/puts.c - 1.2 linux/arch/mips/au1000/common/reset.c - 1.2 linux/arch/mips/au1000/common/serial.c - 1.13 linux/arch/mips/au1000/common/time.c - 1.4 linux/arch/mips/au1000/pb1000/Makefile - 1.6 linux/arch/mips/au1000/pb1000/init.c - 1.2 linux/arch/mips/au1000/pb1000/setup.c - 1.3 linux/arch/mips64/mips-boards/generic/pci.c - 1.6 linux/include/asm-mips64/tlb.h - 1.2 linux/arch/mips64/sgi-ip32/ip32-berr.c - 1.2 linux/arch/mips64/sgi-ip32/crime.c - 1.2 linux/arch/mips64/sgi-ip32/Makefile - 1.7 linux/arch/mips/ddb5xxx/common/Makefile - 1.5 linux/arch/mips/ddb5xxx/common/irq.c - 1.2 linux/arch/mips/ddb5xxx/common/irq_cpu.c - 1.2 linux/arch/mips/ddb5xxx/common/nile4.c - 1.3 linux/arch/mips/ddb5xxx/common/pci.c - 1.6 linux/arch/mips/ddb5xxx/common/pci_auto.c - 1.2 linux/arch/mips/ddb5xxx/common/prom.c - 1.2 linux/arch/mips/ddb5xxx/common/rtc_ds1386.c - 1.3 linux/arch/mips/ddb5xxx/ddb5477/Makefile - 1.6 linux/arch/mips/ddb5xxx/ddb5477/debug.c - 1.2 linux/arch/mips/ddb5xxx/ddb5477/int-handler.S - 1.2 linux/arch/mips/ddb5xxx/ddb5477/irq.c - 1.2 linux/arch/mips/ddb5xxx/ddb5477/irq_5477.c - 1.2 linux/arch/mips/ddb5xxx/ddb5477/kgdb_io.c - 1.2 linux/arch/mips/ddb5xxx/ddb5477/pci.c - 1.3 linux/arch/mips/ddb5xxx/ddb5477/pci_ops.c - 1.3 linux/arch/mips/ddb5xxx/ddb5477/setup.c - 1.3 linux/include/asm-mips64/mips-boards/malta.h - 1.2 linux/include/asm-mips64/mips-boards/gt64120.h - 1.2 linux/include/asm-mips64/mips-boards/generic.h - 1.2 linux/include/asm-mips64/mips-boards/atlasint.h - 1.2 linux/include/asm-mips64/mips-boards/atlas.h - 1.2 linux/arch/mips64/mips-boards/generic/printf.c - 1.2 linux/arch/mips64/mips-boards/generic/reset.c - 1.2 linux/arch/mips64/mips-boards/generic/time.c - 1.5 linux/arch/mips/philips/nino/time.c - 1.3 linux/arch/mips/philips/nino/setup.c - 1.2 linux/arch/mips64/mips-boards/atlas/atlas_rtc.c - 1.2 linux/arch/mips/defconfig-atlas - 1.4 linux/arch/mips/philips/nino/rtc.c - 1.2 linux/arch/mips/philips/nino/reset.c - 1.2 linux/arch/mips/defconfig-ddb5477 - 1.4 linux/arch/mips/philips/nino/ramdisk/ld.script - 1.2 linux/arch/mips/philips/nino/ramdisk/Makefile - 1.4 linux/arch/mips/philips/nino/prom.c - 1.2 linux/arch/mips/defconfig-malta - 1.4 linux/arch/mips/defconfig-nino - 1.4 linux/arch/mips/philips/nino/power.c - 1.2 linux/arch/mips/defconfig-pb1000 - 1.4 linux/include/asm-mips/pci_channel.h - 1.2 linux/arch/mips/philips/nino/kgdb.c - 1.2 linux/arch/mips/philips/nino/irq.c - 1.6 linux/arch/mips64/mips-boards/malta/malta_int.c - 1.5 linux/include/asm-mips/mips-boards/malta.h - 1.2 linux/include/asm-mips/mips-boards/generic.h - 1.2 linux/include/asm-mips/mips-boards/atlasint.h - 1.2 linux/include/asm-mips/mips-boards/atlas.h - 1.2 linux/arch/mips/kernel/pci_auto.c - 1.2 linux/arch/mips/philips/nino/int-handler.S - 1.3 linux/arch/mips/philips/nino/Makefile - 1.6 linux/arch/mips64/mips-boards/generic/mipsIRQ.S - 1.2 linux/arch/mips64/mips-boards/malta/Makefile - 1.6 linux/arch/mips64/mips-boards/atlas/atlas_int.c - 1.5 linux/arch/mips64/mips-boards/atlas/Makefile - 1.6 linux/drivers/scsi/53c700.c - 1.20 linux/arch/mips64/mips-boards/generic/cmdline.c - 1.2 linux/arch/mips64/defconfig-ip32 - 1.4 linux/drivers/scsi/lasi700.c - 1.10 linux/drivers/scsi/lasi700.h - 1.6 linux/arch/mips64/mips-boards/generic/Makefile - 1.6 linux/include/asm-mips/ddb5xxx/debug.h - 1.2 linux/include/asm-mips/gt64120.h - 1.2 linux/include/asm-mips/ddb5xxx/ddb5477.h - 1.2 linux/arch/mips64/mips-boards/generic/display.c - 1.2 linux/include/asm-mips/dec/ioasic.h - 1.2 linux/arch/mips64/mips-boards/generic/gdb_hook.c - 1.2 linux/arch/mips64/mips-boards/generic/init.c - 1.2 linux/include/asm-mips/ddb5xxx/ddb5xxx.h - 1.3 linux/arch/mips64/mips-boards/malta/malta_setup.c - 1.2 linux/arch/mips64/mips-boards/generic/memory.c - 1.2 linux/include/asm-mips/au1000.h - 1.2 linux/arch/mips64/mips-boards/malta/malta_rtc.c - 1.2 linux/fs/jffs2/dir.c - 1.14 linux/fs/jffs2/scan.c - 1.9 linux/include/asm-sh/tlb.h - 1.2 linux/include/asm-ia64/tlb.h - 1.11 linux/drivers/mtd/chips/gen_probe.c - 1.3 linux/drivers/mtd/maps/tqm8xxl.c - 1.4 linux/drivers/mtd/afs.c - 1.4 linux/drivers/pcmcia/i82092.c - 1.16 linux/drivers/pcmcia/i82092aa.h - 1.7 linux/net/ipv4/netfilter/ip_nat_snmp_basic.c - 1.9 linux/net/ipv4/netfilter/ip_nat_irc.c - 1.6 linux/net/ipv4/netfilter/ip_conntrack_irc.c - 1.10 linux/drivers/atm/idt77252.c - 1.13 linux/drivers/scsi/sym53c8xx_2/sym_glue.c - 1.17 linux/drivers/scsi/sym53c8xx_2/sym_hipd.c - 1.8 linux/fs/ext3/inode.c - 1.39 linux/fs/ext3/namei.c - 1.22 linux/fs/ext3/super.c - 1.38 linux/include/linux/ext3_fs.h - 1.19 linux/fs/jbd/commit.c - 1.13 linux/drivers/net/Makefile.lib - 1.7 linux/drivers/ide/ide-taskfile.c - 1.33 linux/drivers/ieee1394/dv1394-private.h - 1.10 linux/drivers/ieee1394/dv1394.c - 1.18 linux/drivers/ieee1394/dv1394.h - 1.4 linux/drivers/net/wireless/netwave_cs.c - 1.9 linux/net/ipv4/netfilter/ipt_ULOG.c - 1.10 linux/drivers/pci/pci-driver.c - 1.17 linux/arch/x86_64/defconfig - 1.18 linux/arch/x86_64/ia32/Makefile - 1.14 linux/arch/x86_64/ia32/ia32_binfmt.c - 1.12 linux/arch/x86_64/ia32/ia32_ioctl.c - 1.20 linux/arch/x86_64/ia32/ia32entry.S - 1.16 linux/arch/x86_64/ia32/ptrace32.c - 1.8 linux/arch/x86_64/ia32/sys_ia32.c - 1.23 linux/arch/x86_64/kernel/i8259.c - 1.7 linux/arch/x86_64/kernel/io_apic.c - 1.9 linux/arch/x86_64/kernel/nmi.c - 1.13 linux/arch/x86_64/kernel/setup.c - 1.15 linux/arch/x86_64/kernel/time.c - 1.15 linux/arch/x86_64/kernel/traps.c - 1.19 linux/arch/x86_64/kernel/x8664_ksyms.c - 1.14 linux/include/asm-x86_64/scatterlist.h - 1.3 linux/include/asm-x86_64/ptrace.h - 1.8 linux/include/asm-x86_64/processor.h - 1.17 linux/include/asm-x86_64/pgtable.h - 1.19 linux/include/asm-x86_64/pci.h - 1.10 linux/include/asm-x86_64/mtrr.h - 1.6 linux/include/asm-x86_64/io_apic.h - 1.6 linux/include/asm-x86_64/floppy.h - 1.4 linux/include/asm-x86_64/apic.h - 1.8 linux/include/asm-ppc/thread_info.h - 1.9 linux/include/asm-x86_64/unistd.h - 1.15 linux/include/asm-ppc64/eeh.h - 1.5 linux/include/asm-ppc64/bitops.h - 1.5 linux/arch/ppc64/kernel/entry.S - 1.18 linux/arch/ppc64/kernel/pSeries_pci.c - 1.13 linux/arch/ppc64/kernel/pci.c - 1.15 linux/arch/ppc64/kernel/pci.h - 1.7 linux/arch/ppc64/kernel/pci_dn.c - 1.8 linux/arch/ppc64/kernel/prom.c - 1.16 linux/arch/ppc64/kernel/smp.c - 1.20 linux/arch/ppc64/kernel/sys_ppc32.c - 1.25 linux/arch/ppc64/xmon/ppc-opc.c - 1.2 linux/arch/ppc64/xmon/xmon.c - 1.13 linux/include/asm-ppc64/uaccess.h - 1.8 linux/include/asm-ppc64/system.h - 1.12 linux/include/asm-ppc64/smp.h - 1.8 linux/include/asm-ppc64/prom.h - 1.6 linux/include/asm-ppc64/processor.h - 1.17 linux/include/asm-ppc64/pci.h - 1.8 linux/drivers/net/e1000/e1000_ethtool.c - 1.11 linux/drivers/net/tulip/de2104x.c - 1.10 linux/drivers/net/e100/e100_main.c - 1.22 linux/fs/jffs2/os-linux.h - 1.9 linux/arch/ia64/sn/kernel/setup.c - 1.10 linux/arch/ia64/sn/kernel/machvec.c - 1.5 linux/include/asm-ia64/thread_info.h - 1.7 linux/fs/jffs2/fs.c - 1.8 linux/arch/ia64/sn/kernel/Makefile - 1.10 linux/net/ipv4/netfilter/arp_tables.c - 1.8 linux/drivers/ieee1394/eth1394.c - 1.11 linux/drivers/net/sb1250-mac.c - 1.5 linux/drivers/ide/ide-tcq.c - 1.7 linux/drivers/usb/core/hcd.c - 1.25 linux/drivers/usb/core/hcd.h - 1.17 linux/drivers/usb/core/usb.c - 1.36 linux/drivers/usb/host/ehci-dbg.c - 1.16 linux/drivers/usb/host/ehci-hcd.c - 1.23 linux/drivers/usb/host/ohci-dbg.c - 1.14 linux/drivers/ieee1394/cmp.c - 1.7 linux/drivers/ieee1394/amdtp.c - 1.11 linux/drivers/usb/net/usbnet.c - 1.23 linux/drivers/usb/net/kaweth.c - 1.19 linux/drivers/usb/net/cdc-ether.h - 1.3 linux/drivers/usb/net/cdc-ether.c - 1.14 linux/mm/readahead.c - 1.19 linux/drivers/usb/host/uhci-debug.c - 1.5 linux/drivers/usb/host/uhci-hcd.c - 1.22 linux/arch/i386/pci/Makefile - 1.6 linux/arch/i386/pci/acpi.c - 1.5 linux/arch/i386/pci/common.c - 1.12 linux/arch/i386/pci/direct.c - 1.8 linux/drivers/pci/hotplug.c - 1.14 linux/drivers/pci/probe.c - 1.18 linux/arch/i386/pci/numa.c - 1.9 linux/arch/i386/pci/pcbios.c - 1.7 linux/mm/page-writeback.c - 1.27 linux/drivers/usb/host/hc_sl811.c - 1.5 linux/drivers/acpi/pci_root.c - 1.11 linux/drivers/acpi/osl.c - 1.21 linux/drivers/s390/net/lcs.c - 1.15 linux/drivers/s390/cio/chsc.c - 1.9 linux/drivers/usb/core/hcd-pci.c - 1.11 linux/drivers/s390/block/dasd_ioctl.c - 1.12 linux/drivers/s390/cio/requestirq.c - 1.5 linux/include/asm-ia64/agp.h - 1.4 linux/include/asm-mips/rmap.h - 1.2 linux/security/dummy.c - 1.12 linux/security/capability.c - 1.10 linux/drivers/char/agp/sis-agp.c - 1.9 linux/mm/rmap.c - 1.14 linux/drivers/serial/8250_pci.c - 1.11 linux/include/asm-mips64/rmap.h - 1.2 linux/drivers/serial/8250_cs.c - 1.6 linux/drivers/serial/8250.c - 1.18 linux/include/linux/security.h - 1.11 linux/drivers/serial/sunzilog.c - 1.13 linux/drivers/serial/sunsab.c - 1.8 linux/drivers/serial/sunsu.c - 1.14 linux/arch/mips64/vmlinux.lds.S - 1.5 linux/net/sctp/sysctl.c - 1.6 linux/include/net/sctp/user.h - 1.7 linux/net/sctp/protocol.c - 1.19 linux/include/net/sctp/sla1.h - 1.2 linux/include/net/sctp/sctp.h - 1.15 linux/net/sctp/associola.c - 1.15 linux/net/sctp/bind_addr.c - 1.11 linux/net/sctp/endpointola.c - 1.12 linux/net/sctp/hashdriver.c - 1.2 linux/net/sctp/ipv6.c - 1.17 linux/net/sctp/outqueue.c - 1.14 linux/include/net/sctp/constants.h - 1.7 linux/net/sctp/tsnmap.c - 1.5 linux/include/net/sctp/sm.h - 1.12 linux/net/sctp/sla1.c - 1.2 linux/net/sctp/sm_make_chunk.c - 1.16 linux/net/sctp/sm_sideeffect.c - 1.17 linux/net/sctp/sm_statefuns.c - 1.16 linux/include/net/sctp/tsnmap.h - 1.4 linux/include/net/sctp/structs.h - 1.18 linux/net/sctp/sm_statetable.c - 1.9 linux/net/sctp/socket.c - 1.19 linux/drivers/ide/setup-pci.c - 1.12 linux/drivers/ide/legacy/pdc4030.c - 1.10 linux/drivers/ide/legacy/ide-cs.c - 1.7 linux/arch/mips/vmlinux.lds.S - 1.6 linux/arch/ia64/pci/pci.c - 1.9 linux/include/asm-ia64/topology.h - 1.8 linux/include/asm-mips/topology.h - 1.2 linux/include/asm-mips64/topology.h - 1.3 linux/arch/i386/kernel/cpu/cpufreq/Makefile - 1.7 linux/drivers/scsi/nsp32.c - 1.11 linux/drivers/scsi/aacraid/aachba.c - 1.11 linux/kernel/workqueue.c - 1.6 linux/net/sunrpc/svcauth_unix.c - 1.8 linux/fs/nfsd/nfs4xdr.c - 1.13 linux/fs/nfsd/nfs4proc.c - 1.9 linux/net/sunrpc/cache.c - 1.8 linux/include/linux/nfs4.h - 1.5 linux/include/linux/nfsd/xdr4.h - 1.8 linux/include/linux/sunrpc/cache.h - 1.7 linux/drivers/mtd/maps/edb7312.c - 1.4 linux/net/rxrpc/sysctl.c - 1.3 linux/drivers/mtd/maps/impa7.c - 1.4 linux/drivers/mtd/maps/pcmciamtd.c - 1.5 linux/include/asm-x86_64/proto.h - 1.12 linux/drivers/block/scsi_ioctl.c - 1.11 linux/arch/x86_64/kernel/pci-gart.c - 1.11 linux/drivers/pnp/pnpbios/core.c - 1.14 linux/drivers/pnp/resource.c - 1.12 linux/include/asm-x86_64/nmi.h - 1.2 linux/drivers/pnp/isapnp/core.c - 1.14 linux/drivers/pnp/interface.c - 1.10 linux/include/linux/pnp.h - 1.12 linux/drivers/mtd/maps/Kconfig - 1.6 linux/drivers/net/Kconfig - 1.15 linux/drivers/net/irda/Kconfig - 1.5 linux/arch/alpha/Kconfig - 1.15 linux/arch/arm/Kconfig - 1.15 linux/arch/cris/Kconfig - 1.10 linux/include/linux/eventpoll.h - 1.8 linux/arch/i386/Kconfig - 1.23 linux/include/linux/dvb/video.h - 1.3 linux/include/linux/dvb/net.h - 1.3 linux/include/linux/dvb/frontend.h - 1.3 linux/include/linux/dvb/dmx.h - 1.3 linux/drivers/media/dvb/frontends/ves1820.c - 1.4 linux/drivers/media/dvb/frontends/grundig_29504-491.c - 1.4 linux/drivers/media/dvb/frontends/grundig_29504-401.c - 1.4 linux/drivers/media/dvb/frontends/alps_bsrv2.c - 1.4 linux/arch/i386/mach-voyager/voyager_basic.c - 1.3 linux/drivers/media/dvb/frontends/Makefile - 1.4 linux/drivers/media/dvb/frontends/Kconfig - 1.5 linux/drivers/media/dvb/dvb-core/dvbdev.h - 1.5 linux/arch/ia64/Kconfig - 1.14 linux/drivers/media/dvb/dvb-core/dvbdev.c - 1.7 linux/drivers/media/dvb/dvb-core/dvb_net.h - 1.4 linux/drivers/media/dvb/dvb-core/dvb_net.c - 1.4 linux/drivers/media/dvb/dvb-core/dvb_ksyms.c - 1.4 linux/drivers/media/dvb/dvb-core/dvb_i2c.c - 1.5 linux/drivers/media/dvb/dvb-core/dvb_frontend.h - 1.4 linux/drivers/media/dvb/dvb-core/dvb_frontend.c - 1.5 linux/drivers/media/dvb/dvb-core/dvb_filter.h - 1.4 linux/drivers/media/dvb/dvb-core/dvb_filter.c - 1.4 linux/arch/m68k/Kconfig - 1.14 linux/drivers/media/dvb/dvb-core/dvb_demux.h - 1.4 linux/arch/mips/Kconfig - 1.11 linux/drivers/media/dvb/dvb-core/dvb_demux.c - 1.5 linux/arch/mips64/Kconfig - 1.12 linux/arch/parisc/Kconfig - 1.12 linux/drivers/media/dvb/dvb-core/dmxdev.h - 1.4 linux/drivers/media/dvb/dvb-core/dmxdev.c - 1.4 linux/drivers/media/dvb/dvb-core/demux.h - 1.3 linux/drivers/media/dvb/dvb-core/Makefile - 1.5 linux/drivers/md/dm.c - 1.9 linux/drivers/md/dm-ioctl.c - 1.13 linux/drivers/cdrom/Kconfig - 1.3 linux/drivers/scsi/Kconfig - 1.15 linux/arch/ppc/Kconfig - 1.14 linux/arch/ppc64/Kconfig - 1.13 linux/arch/s390/Kconfig - 1.11 linux/arch/sh/Kconfig - 1.12 linux/arch/sparc/Kconfig - 1.14 linux/net/ipv4/netfilter/Kconfig - 1.5 linux/drivers/i2c/Kconfig - 1.7 linux/arch/sparc64/Kconfig - 1.16 linux/drivers/ide/Kconfig - 1.12 linux/arch/x86_64/Kconfig - 1.18 linux/drivers/serial/Kconfig - 1.10 linux/drivers/sgi/Kconfig - 1.2 linux/include/net/xfrm.h - 1.15 linux/include/asm-m68knommu/bitops.h - 1.3 linux/include/asm-m68knommu/dma.h - 1.2 linux/include/asm-m68knommu/mcfuart.h - 1.3 linux/arch/m68knommu/Kconfig - 1.13 linux/arch/m68knommu/kernel/time.c - 1.5 linux/arch/m68knommu/kernel/traps.c - 1.3 linux/arch/m68knommu/platform/5206e/MOTOROLA/crt0_ram.S - 1.2 linux/arch/m68knommu/platform/5272/NETtel/crt0_ram.S - 1.2 linux/arch/m68knommu/platform/5307/ARNEWSH/crt0_ram.S - 1.2 linux/arch/m68knommu/platform/5307/config.c - 1.4 linux/arch/m68knommu/platform/68360/ints.c - 1.4 linux/arch/v850/Kconfig - 1.13 linux/net/key/af_key.c - 1.15 linux/drivers/scsi/scsi_sysfs.c - 1.12 linux/drivers/media/dvb/frontends/alps_tdlb7.c - 1.3 linux/drivers/ide/pci/sc1200.c - 1.6 linux/drivers/media/dvb/frontends/alps_tdmb7.c - 1.3 linux/Documentation/scsi/scsi_mid_low_api.txt - 1.5 linux/include/asm-sparc64/compat.h - 1.10 linux/drivers/s390/char/tape_core.c - 1.5 linux/drivers/ieee1394/dma.c - 1.4 linux/drivers/ieee1394/dma.h - 1.3 linux/drivers/video/vgastate.c - 1.3 linux/fs/compat.c - 1.8 linux/drivers/s390/cio/ccwgroup.c - 1.4 linux/drivers/s390/cio/css.h - 1.3 linux/drivers/s390/cio/device.c - 1.6 linux/drivers/s390/cio/device.h - 1.4 linux/drivers/s390/cio/device_fsm.c - 1.5 linux/include/asm-s390/ccwdev.h - 1.5 linux/include/asm-mips64/compat.h - 1.2 linux/drivers/s390/cio/device_ops.c - 1.5 linux/drivers/s390/cio/device_pgid.c - 1.4 linux/drivers/s390/cio/qdio.c - 1.6 linux/arch/s390/kernel/module.c - 1.8 linux/drivers/s390/cio/qdio.h - 1.5 linux/drivers/ieee1394/iso.c - 1.7 linux/drivers/ieee1394/iso.h - 1.4 linux/drivers/ide/ide-io.c - 1.11 linux/drivers/char/watchdog/mixcomwd.c - 1.7 linux/include/linux/xfrm.h - 1.7 linux/arch/x86_64/kernel/module.c - 1.7 linux/arch/x86_64/kernel/suspend.c - 1.6 linux/arch/x86_64/oprofile/Makefile - 1.3 linux/drivers/i2c/busses/Kconfig - 1.8 linux/drivers/i2c/busses/Makefile - 1.6 linux/drivers/video/i810/i810_main.c - 1.7 linux/drivers/scsi/zalon.h - 1.3 linux/drivers/scsi/zalon.c - 1.3 linux/include/asm-sh/bug.h - 1.3 linux/include/asm-mips64/bug.h - 1.3 linux/include/asm-sparc/bug.h - 1.4 linux/include/asm-mips/bug.h - 1.3 linux/include/acpi/acpi_drivers.h - 1.3 linux/drivers/net/typhoon.c - 1.5 linux/drivers/net/wireless/strip.c - 1.4 linux/drivers/s390/net/Kconfig - 1.3 linux/arch/i386/kernel/cpu/cpufreq/Kconfig - 1.4 linux/drivers/pnp/manager.c - 1.5 linux/drivers/pnp/support.c - 1.3 linux/Documentation/cpu-freq/user-guide.txt - 1.4 linux/net/sctp/proc.c - 1.4 linux/net/ipv6/xfrm6_input.c - 1.6 linux/net/ipv6/anycast.c - 1.3 linux/net/xfrm/xfrm_user.c - 1.4 linux/net/xfrm/xfrm_state.c - 1.6 linux/net/xfrm/xfrm_input.c - 1.3 linux/drivers/pcmcia/sa11xx_core.h - 1.4 linux/drivers/pcmcia/sa11xx_core.c - 1.5 linux/net/ipv4/netfilter/ip_nat_amanda.c - 1.3 linux/arch/x86_64/kernel/acpi/wakeup.S - 1.3 linux/arch/x86_64/kernel/acpi/boot.c - 1.3 linux/arch/s390/kernel/compat_ioctl.c - 1.4 linux/arch/s390/kernel/compat_linux.c - 1.2 linux/drivers/media/common/saa7146_core.c - 1.3 linux/drivers/media/common/saa7146_fops.c - 1.3 linux/drivers/media/common/saa7146_hlp.c - 1.2 linux/drivers/media/common/saa7146_i2c.c - 1.2 linux/drivers/media/common/saa7146_vbi.c - 1.2 linux/drivers/media/common/saa7146_video.c - 1.3 linux/drivers/media/dvb/dvb-core/dvb_ringbuffer.c - 1.2 linux/drivers/media/dvb/dvb-core/dvb_ringbuffer.h - 1.2 linux/drivers/media/dvb/frontends/at76c651.c - 1.2 linux/drivers/media/dvb/frontends/dvb_dummy_fe.c - 1.2 linux/drivers/media/dvb/frontends/nxt6000.c - 1.2 linux/drivers/media/dvb/frontends/stv0299.c - 1.2 linux/drivers/media/dvb/ttpci/av7110.c - 1.2 linux/drivers/media/dvb/ttpci/av7110.h - 1.2 linux/drivers/media/dvb/ttpci/av7110_firm.h - 1.2 linux/include/media/saa7146_vv.h - 1.2 linux/include/media/saa7146.h - 1.3 linux/drivers/media/dvb/ttpci/av7110_ipack.c - 1.2 linux/drivers/media/dvb/ttpci/av7110_ipack.h - 1.2 linux/drivers/media/dvb/ttpci/av7110_ir.c - 1.2 linux/drivers/media/dvb/ttpci/budget-av.c - 1.2 linux/drivers/media/dvb/ttpci/budget-ci.c - 1.2 linux/drivers/media/dvb/ttpci/budget-core.c - 1.2 linux/drivers/media/dvb/ttpci/budget-patch.c - 1.2 linux/drivers/media/dvb/ttpci/budget.c - 1.2 linux/drivers/media/dvb/ttpci/budget.h - 1.2 linux/drivers/media/video/dpc7146.c - 1.3 linux/drivers/media/video/mxb.c - 1.4 linux/include/linux/nfsd/state.h - 1.4 linux/include/asm-s390/compat.h - 1.3 linux/fs/nfsd/nfs4state.c - 1.4 linux/arch/s390/kernel/entry64.S - 1.3 linux/arch/s390/kernel/head64.S - 1.3 linux/arch/s390/kernel/syscalls.S - 1.3 linux/include/asm-h8300/processor.h - 1.2 linux/drivers/net/ixgb/ixgb_ethtool.c - 1.3 linux/drivers/scsi/dc395x.c - 1.5 linux/include/linux/usb_gadget.h - 1.2 linux/arch/m68knommu/platform/5282/MOTOROLA/crt0_ram.S - 1.2 linux/arch/m68knommu/platform/5282/pit.c - 1.2 linux/dev/null - 1.5 linux/drivers/atm/he.c - 1.4 linux/drivers/char/agp/nvidia-agp.c - 1.2 linux/Documentation/DocBook/gadget.tmpl - 1.2 linux/drivers/mtd/maps/ebony.c - 1.2 linux/drivers/mtd/maps/arctic-mtd.c - 1.2 linux/drivers/mtd/maps/lubbock-flash.c - 1.2 linux/include/asm-ppc64/cputable.h - 1.2 linux/drivers/mtd/inftlmount.c - 1.2 linux/drivers/mtd/inftlcore.c - 1.2 linux/drivers/mtd/maps/pb1xxx-flash.c - 1.2 linux/drivers/mtd/devices/doc2001plus.c - 1.2 linux/drivers/mtd/mtd_blkdevs.c - 1.2 linux/drivers/mtd/nand/autcpu12.c - 1.2 linux/drivers/pci/hotplug/Kconfig - 1.2 linux/drivers/pci/hotplug/Makefile - 1.2 linux/drivers/pci/hotplug/acpiphp_core.c - 1.3 linux/drivers/pci/hotplug/cpci_hotplug_core.c - 1.2 linux/include/linux/mtd/blktrans.h - 1.2 linux/arch/arm26/Kconfig - 1.3 linux/drivers/pci/hotplug/cpqphp_core.c - 1.2 linux/arch/i386/kernel/cpu/cpufreq/speedstep-centrino.c - 1.2 linux/arch/i386/kernel/cpu/cpufreq/speedstep-ich.c - 1.2 linux/drivers/pci/hotplug/cpqphp_pci.c - 1.2 linux/drivers/pci/hotplug/ibmphp.h - 1.2 linux/drivers/pci/hotplug/ibmphp_core.c - 1.2 linux/drivers/pci/hotplug/ibmphp_ebda.c - 1.2 linux/drivers/pci/hotplug/ibmphp_hpc.c - 1.2 linux/drivers/pci/hotplug/ibmphp_res.c - 1.2 linux/drivers/pci/hotplug/pci_hotplug.h - 1.2 linux/drivers/pci/hotplug/pci_hotplug_core.c - 1.2 linux/drivers/pci/hotplug/pcihp_skeleton.c - 1.2 linux/arch/sh/boards/se/770x/mach.c - 1.2 linux/arch/sh/cchips/hd6446x/hd64465/gpio.c - 1.2 linux/fs/compat_ioctl.c - 1.3 linux/arch/sh/boards/sh2000/mach.c - 1.2 linux/arch/sh/boards/se/7751/mach.c - 1.2 linux/arch/ppc64/kernel/cputable.c - 1.2 linux/include/asm-arm26/processor.h - 1.2 linux/arch/sh/boards/adx/mach.c - 1.2 linux/arch/sh/boards/dmida/mach.c - 1.2 linux/arch/sh/boards/dreamcast/mach.c - 1.2 linux/arch/sh/boards/hp6xx/hp620/mach.c - 1.2 linux/arch/sh/boards/hp6xx/hp680/mach.c - 1.2 linux/arch/sh/boards/hp6xx/hp690/mach.c - 1.2 linux/arch/sh/boards/saturn/mach.c - 1.2 linux/arch/ia64/sn/kernel/idle.c - 1.2 linux/arch/ia64/sn/io/machvec/pci_dma.c - 1.2 linux/arch/ia64/sn/io/machvec/pci.c - 1.2 linux/drivers/pcmcia/yenta_socket.c - 1.2 linux/drivers/pcmcia/yenta_socket.h - 1.2 linux/fs/Kconfig.binfmt - 1.2 linux/arch/ia64/sn/io/hwgfs/hcl.c - 1.2 linux/arch/ia64/sn/io/drivers/ifconfig_net.c - 1.2 linux/arch/ia64/sn/io/drivers/Makefile - 1.2 linux/arch/ia64/scripts/toolchain-flags - 1.2 linux/include/scsi/scsi_request.h - 1.2 linux/include/scsi/scsi_device.h - 1.2 linux/include/scsi/scsi_cmnd.h - 1.2 From owner-linux-xfs@oss.sgi.com Fri Jul 11 15:05:58 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 11 Jul 2003 15:06:04 -0700 (PDT) Received: from tolkor.sgi.com ([198.149.18.6]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h6BM5v2x023156 for ; Fri, 11 Jul 2003 15:05:58 -0700 Received: from flecktone.americas.sgi.com (flecktone.americas.sgi.com [192.48.203.135]) by tolkor.sgi.com (8.12.9/8.12.2/linux-outbound_gateway-1.2) with ESMTP id h6BMO3mO001395 for ; Fri, 11 Jul 2003 17:24:04 -0500 Received: from daisy-e236.americas.sgi.com (daisy-e236.americas.sgi.com [128.162.236.214]) by flecktone.americas.sgi.com (8.12.9/8.12.9/generic_config-1.2) with ESMTP id h6BM5pqX8981122 for ; Fri, 11 Jul 2003 17:05:51 -0500 (CDT) Received: from penguin.americas.sgi.com (penguin.americas.sgi.com [128.162.240.135]) by daisy-e236.americas.sgi.com (8.12.9/SGI-server-1.8) with ESMTP id h6BM5oRn164327341 for ; Fri, 11 Jul 2003 17:05:50 -0500 (CDT) From: Steve Lord Received: by penguin.americas.sgi.com (8.11.6/SGI-client-1.7) id h6BM58L19524; Fri, 11 Jul 2003 17:05:08 -0500 Message-Id: <200307112205.h6BM58L19524@penguin.americas.sgi.com> Date: Fri, 11 Jul 2003 17:05:08 -0500 Subject: TAKE - merge up to 2.5.75 To: linux-xfs@oss.sgi.com X-archive-position: 4625 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: lord@sgi.com Precedence: bulk X-list: linux-xfs Date: Fri Jul 11 15:03:09 PDT 2003 Workarea: penguin.americas.sgi.com:/src/lord/xfs-linux.2.5 The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.5.x-xfs Modid: 2.5.x-xfs:slinx:153064a linux/arch/cris/arch-v10/lib/string.c - 1.1 linux/arch/ppc/platforms/sandpoint.c - 1.1 linux/drivers/block/as-iosched.c - 1.1 linux/arch/cris/arch-v10/drivers/i2c.c - 1.1 linux/lib/div64.c - 1.1 linux/arch/ppc/boot/common/serial_stub.c - 1.1 linux/arch/sparc64/lib/xor.S - 1.1 linux/include/asm-generic/div64.h - 1.1 linux/include/asm-cris/tlbflush.h - 1.1 linux/arch/cris/arch-v10/drivers/pcf8563.c - 1.1 linux/arch/ppc/syslib/gen550_dbg.c - 1.1 linux/include/asm-cris/thread_info.h - 1.1 linux/arch/ppc/syslib/gen550_kgdb.c - 1.1 linux/fs/cifs/xattr.c - 1.1 linux/arch/cris/arch-v10/kernel/Makefile - 1.1 linux/include/asm-cris/rs485.h - 1.1 linux/fs/cifs/cifsencrypt.c - 1.1 linux/arch/cris/arch-v10/kernel/debugport.c - 1.1 linux/arch/cris/arch-v10/kernel/fasttimer.c - 1.1 linux/include/asm-cris/arch-v10/bitops.h - 1.1 linux/include/asm-cris/arch-v10/byteorder.h - 1.1 linux/include/asm-cris/arch-v10/cache.h - 1.1 linux/include/asm-cris/arch-v10/checksum.h - 1.1 linux/include/asm-cris/arch-v10/delay.h - 1.1 linux/include/asm-cris/arch-v10/dma.h - 1.1 linux/include/asm-cris/percpu.h - 1.1 linux/include/asm-cris/kmap_types.h - 1.1 linux/include/asm-cris/fasttimer.h - 1.1 linux/include/asm-cris/arch-v10/elf.h - 1.1 linux/include/asm-cris/cacheflush.h - 1.1 linux/include/asm-cris/arch-v10/io.h - 1.1 linux/include/asm-cris/arch-v10/user.h - 1.1 linux/include/asm-cris/arch-v10/irq.h - 1.1 linux/include/asm-cris/arch-v10/mmu.h - 1.1 linux/include/asm-cris/arch-v10/offset.h - 1.1 linux/include/asm-cris/arch-v10/page.h - 1.1 linux/include/asm-cris/arch-v10/pgtable.h - 1.1 linux/include/asm-cris/arch-v10/unistd.h - 1.1 linux/include/asm-cris/arch-v10/uaccess.h - 1.1 linux/arch/cris/arch-v10/Kconfig - 1.1 linux/arch/cris/arch-v10/README.mm - 1.1 linux/arch/cris/arch-v10/boot/Makefile - 1.1 linux/arch/cris/arch-v10/boot/compressed/Makefile - 1.1 linux/arch/cris/arch-v10/boot/compressed/README - 1.1 linux/arch/cris/arch-v10/boot/compressed/decompress.ld - 1.1 linux/arch/cris/arch-v10/boot/compressed/head.S - 1.1 linux/arch/cris/arch-v10/boot/compressed/misc.c - 1.1 linux/arch/cris/arch-v10/boot/rescue/Makefile - 1.1 linux/arch/cris/arch-v10/boot/rescue/head.S - 1.1 linux/arch/cris/arch-v10/boot/rescue/kimagerescue.S - 1.1 linux/arch/cris/arch-v10/boot/rescue/rescue.ld - 1.1 linux/arch/cris/arch-v10/boot/rescue/testrescue.S - 1.1 linux/arch/cris/arch-v10/boot/tools/build.c - 1.1 linux/arch/cris/arch-v10/defconfig - 1.1 linux/arch/cris/arch-v10/drivers/Kconfig - 1.1 linux/arch/cris/arch-v10/drivers/Makefile - 1.1 linux/arch/cris/arch-v10/drivers/axisflashmap.c - 1.1 linux/arch/cris/arch-v10/drivers/ds1302.c - 1.1 linux/arch/cris/arch-v10/drivers/eeprom.c - 1.1 linux/arch/cris/arch-v10/drivers/ethernet.c - 1.1 linux/arch/cris/arch-v10/drivers/gpio.c - 1.1 linux/include/asm-cris/arch-v10/processor.h - 1.1 linux/arch/cris/arch-v10/drivers/i2c.h - 1.1 linux/include/asm-cris/arch-v10/ptrace.h - 1.1 linux/arch/cris/arch-v10/drivers/serial.c - 1.1 linux/arch/cris/arch-v10/drivers/serial.h - 1.1 linux/include/asm-cris/arch-v10/sv_addr.agh - 1.1 linux/arch/cris/arch-v10/kernel/asm-offsets.c - 1.1 linux/arch/cris/arch-v10/lib/checksum.S - 1.1 linux/arch/cris/arch-v10/kernel/entry.S - 1.1 linux/include/asm-cris/arch-v10/sv_addr_ag.h - 1.1 linux/arch/cris/arch-v10/kernel/head.S - 1.1 linux/arch/cris/arch-v10/kernel/irq.c - 1.1 linux/arch/cris/arch-v10/kernel/kgdb.c - 1.1 linux/arch/cris/arch-v10/kernel/process.c - 1.1 linux/arch/cris/arch-v10/kernel/ptrace.c - 1.1 linux/arch/cris/arch-v10/kernel/setup.c - 1.1 linux/arch/cris/arch-v10/kernel/shadows.c - 1.1 linux/arch/cris/arch-v10/kernel/signal.c - 1.1 linux/arch/cris/arch-v10/kernel/time.c - 1.1 linux/arch/cris/arch-v10/kernel/traps.c - 1.1 linux/arch/cris/arch-v10/lib/Makefile - 1.1 linux/arch/cris/arch-v10/lib/dram_init.S - 1.1 linux/arch/cris/arch-v10/lib/checksumcopy.S - 1.1 linux/arch/cris/arch-v10/lib/csumcpfruser.S - 1.1 linux/arch/cris/arch-v10/lib/dmacopy.c - 1.1 linux/arch/cris/arch-v10/mm/fault.c - 1.1 linux/arch/cris/arch-v10/lib/hw_settings.S - 1.1 linux/arch/cris/arch-v10/lib/memset.c - 1.1 linux/arch/cris/arch-v10/lib/old_checksum.c - 1.1 linux/arch/cris/kernel/module.c - 1.1 linux/arch/cris/arch-v10/lib/usercopy.c - 1.1 linux/arch/cris/arch-v10/mm/Makefile - 1.1 linux/arch/cris/arch-v10/mm/tlb.c - 1.1 linux/arch/cris/arch-v10/mm/init.c - 1.1 linux/include/asm-cris/arch-v10/tlb.h - 1.1 linux/arch/cris/arch-v10/output_arch.ld - 1.1 linux/arch/cris/arch-v10/vmlinux.lds.S - 1.1 linux/include/asm-cris/arch-v10/timex.h - 1.1 linux/include/asm-cris/arch-v10/system.h - 1.1 linux/include/asm-cris/arch-v10/thread_info.h - 1.1 linux/include/asm-cris/arch-v10/svinto.h - 1.1 linux/scripts/ver_linux - 1.14 linux/net/wanrouter/wanmain.c - 1.19 linux/net/unix/af_unix.c - 1.61 linux/net/socket.c - 1.60 linux/net/sched/sch_tbf.c - 1.15 linux/net/sched/sch_sfq.c - 1.13 linux/net/sched/sch_red.c - 1.12 linux/net/sched/sch_prio.c - 1.12 linux/net/sched/sch_fifo.c - 1.7 linux/net/sched/sch_cbq.c - 1.17 linux/net/packet/af_packet.c - 1.46 linux/net/netsyms.c - 1.72 linux/net/ipv6/tcp_ipv6.c - 1.57 linux/net/ipv6/sit.c - 1.33 linux/net/ipv6/route.c - 1.37 linux/net/ipv6/raw.c - 1.39 linux/net/ipv6/proc.c - 1.18 linux/net/ipv6/mcast.c - 1.30 linux/net/ipv6/ip6_output.c - 1.27 linux/net/ipv6/ip6_flowlabel.c - 1.8 linux/net/ipv6/addrconf.c - 1.40 linux/net/ipv4/tcp_input.c - 1.53 linux/net/ipv4/raw.c - 1.38 linux/net/ipv4/ipip.c - 1.33 linux/net/ipv4/ipconfig.c - 1.39 linux/net/ipv4/ip_gre.c - 1.33 linux/net/ipv4/igmp.c - 1.29 linux/net/core/neighbour.c - 1.23 linux/net/core/dev.c - 1.79 linux/mm/swapfile.c - 1.75 linux/mm/swap.c - 1.38 linux/mm/slab.c - 1.61 linux/mm/page_alloc.c - 1.111 linux/mm/mremap.c - 1.43 linux/mm/mprotect.c - 1.38 linux/mm/mmap.c - 1.80 linux/mm/filemap.c - 1.158 linux/lib/Makefile - 1.24 linux/kernel/sysctl.c - 1.70 linux/kernel/softirq.c - 1.38 linux/kernel/signal.c - 1.57 linux/kernel/sched.c - 1.106 linux/kernel/ksyms.c - 1.194 linux/kernel/fork.c - 1.95 linux/kernel/exit.c - 1.71 linux/kernel/acct.c - 1.28 linux/ipc/sem.c - 1.29 linux/include/net/tcp.h - 1.51 linux/include/net/pkt_sched.h - 1.12 linux/include/net/ipv6.h - 1.19 linux/include/net/addrconf.h - 1.15 linux/include/linux/umsdos_fs.p - 1.8 linux/include/linux/slab.h - 1.34 linux/include/linux/sem.h - 1.13 linux/include/linux/sched.h - 1.107 linux/include/linux/quota.h - 1.25 linux/include/linux/qnx4_fs.h - 1.15 linux/include/linux/proc_fs.h - 1.41 linux/include/linux/pci.h - 1.79 linux/include/linux/nfs_fs.h - 1.33 linux/include/linux/netdevice.h - 1.50 linux/include/linux/msdos_fs.h - 1.30 linux/include/linux/mman.h - 1.6 linux/include/linux/mm.h - 1.120 linux/include/linux/kernel_stat.h - 1.15 linux/include/linux/iso_fs.h - 1.19 linux/include/linux/ioport.h - 1.18 linux/include/linux/interrupt.h - 1.30 linux/include/linux/hfs_fs.h - 1.14 linux/include/linux/fs.h - 1.217 linux/include/linux/dcache.h - 1.38 linux/include/linux/coda_linux.h - 1.18 linux/include/linux/blkdev.h - 1.87 linux/include/linux/affs_fs.h - 1.11 linux/include/linux/acct.h - 1.5 linux/include/asm-sparc64/mmu_context.h - 1.20 linux/include/asm-sparc64/hardirq.h - 1.21 linux/include/asm-sparc/mmu_context.h - 1.9 linux/include/asm-ppc/serial.h - 1.14 linux/include/asm-ppc/mmu_context.h - 1.18 linux/include/asm-mips/mmu_context.h - 1.10 linux/include/asm-m68k/mmu_context.h - 1.12 linux/include/asm-i386/unistd.h - 1.38 linux/include/asm-i386/mmu_context.h - 1.27 linux/include/asm-i386/hardirq.h - 1.29 linux/include/asm-arm/mmu_context.h - 1.15 linux/include/asm-alpha/mmu_context.h - 1.18 linux/include/asm-alpha/machvec.h - 1.18 linux/fs/vfat/namei.c - 1.40 linux/fs/umsdos/rdir.c - 1.18 linux/fs/umsdos/namei.c - 1.17 linux/fs/umsdos/emd.c - 1.12 linux/fs/umsdos/dir.c - 1.22 linux/fs/ufs/namei.c - 1.21 linux/fs/sysv/namei.c - 1.22 linux/fs/smbfs/file.c - 1.35 linux/fs/smbfs/dir.c - 1.28 linux/fs/romfs/inode.c - 1.45 linux/fs/qnx4/namei.c - 1.16 linux/fs/proc/root.c - 1.32 linux/fs/proc/generic.c - 1.37 linux/fs/proc/base.c - 1.54 linux/fs/open.c - 1.51 linux/fs/nfsd/vfs.c - 1.70 linux/fs/nfsd/nfsfh.c - 1.51 linux/fs/nfs/file.c - 1.44 linux/fs/nfs/dir.c - 1.53 linux/fs/ncpfs/ioctl.c - 1.20 linux/fs/ncpfs/dir.c - 1.35 linux/fs/namei.c - 1.73 linux/fs/msdos/namei.c - 1.38 linux/fs/minix/namei.c - 1.24 linux/fs/isofs/namei.c - 1.13 linux/fs/hfs/sysdep.c - 1.10 linux/fs/hfs/dir_nat.c - 1.14 linux/fs/hfs/dir_dbl.c - 1.14 linux/fs/hfs/dir_cap.c - 1.13 linux/fs/hfs/dir.c - 1.10 linux/fs/ext2/super.c - 1.49 linux/fs/ext2/namei.c - 1.30 linux/fs/ext2/ialloc.c - 1.38 linux/fs/ext2/acl.c - 1.11 linux/fs/exec.c - 1.85 linux/fs/dquot.c - 1.71 linux/fs/coda/pioctl.c - 1.18 linux/fs/coda/file.c - 1.22 linux/fs/coda/dir.c - 1.30 linux/fs/buffer.c - 1.159 linux/fs/block_dev.c - 1.77 linux/fs/autofs/root.c - 1.22 linux/fs/attr.c - 1.23 linux/fs/affs/namei.c - 1.24 linux/fs/adfs/dir.c - 1.21 linux/drivers/scsi/scsi.c - 1.80 linux/drivers/net/via-rhine.c - 1.44 linux/drivers/net/sunhme.c - 1.46 linux/drivers/macintosh/macserial.c - 1.31 linux/drivers/char/synclink.c - 1.39 linux/drivers/block/ll_rw_blk.c - 1.136 linux/drivers/block/genhd.c - 1.55 linux/drivers/block/floppy.c - 1.68 linux/drivers/block/Makefile - 1.35 linux/arch/sparc64/lib/Makefile - 1.19 linux/arch/sparc64/kernel/traps.c - 1.30 linux/arch/sparc64/kernel/sparc64_ksyms.c - 1.60 linux/arch/sparc64/kernel/smp.c - 1.57 linux/arch/sparc64/kernel/process.c - 1.47 linux/arch/sparc64/kernel/irq.c - 1.35 linux/arch/sparc64/boot/Makefile - 1.10 linux/arch/ppc/kernel/setup.c - 1.58 linux/arch/ppc/kernel/ppc_ksyms.c - 1.59 linux/arch/ppc/kernel/ppc-stub.c - 1.14 linux/arch/ppc/defconfig - 1.47 linux/arch/mips/kernel/sysirix.c - 1.23 linux/arch/i386/lib/delay.c - 1.9 linux/arch/i386/kernel/time.c - 1.43 linux/arch/i386/kernel/irq.c - 1.60 linux/arch/i386/kernel/io_apic.c - 1.66 linux/arch/i386/kernel/entry.S - 1.83 linux/arch/arm/mm/init.c - 1.39 linux/README - 1.16 linux/Makefile - 1.253 linux/MAINTAINERS - 1.144 linux/Documentation/pci.txt - 1.22 linux/Documentation/oops-tracing.txt - 1.11 linux/Documentation/Changes - 1.67 linux/CREDITS - 1.103 linux/include/linux/efs_fs.h - 1.15 linux/fs/hpfs/namei.c - 1.21 linux/fs/hpfs/hpfs_fn.h - 1.24 linux/fs/hpfs/dir.c - 1.18 linux/fs/efs/namei.c - 1.5 linux/drivers/net/ppp_generic.c - 1.41 linux/net/sched/sch_atm.c - 1.15 linux/net/atm/clip.c - 1.20 linux/include/asm-sh/mmu_context.h - 1.14 linux/fs/udf/file.c - 1.32 linux/fs/udf/namei.c - 1.27 linux/include/linux/pci_ids.h - 1.95 linux/mm/bootmem.c - 1.28 linux/fs/proc/proc_misc.c - 1.65 linux/fs/bfs/dir.c - 1.25 linux/include/asm-ppc/div64.h - 1.5 linux/include/asm-alpha/div64.h - 1.3 linux/arch/ppc/configs/pmac_defconfig - 1.14 linux/arch/ppc/configs/gemini_defconfig - 1.25 linux/arch/ppc/configs/common_defconfig - 1.35 linux/arch/ppc/configs/apus_defconfig - 1.22 linux/include/linux/mmzone.h - 1.39 linux/kernel/timer.c - 1.50 linux/include/asm-sparc64/div64.h - 1.2 linux/include/asm-sparc/div64.h - 1.2 linux/fs/openpromfs/inode.c - 1.27 linux/fs/cramfs/inode.c - 1.38 linux/Documentation/usb/CREDITS - 1.9 linux/net/sched/sch_ingress.c - 1.15 linux/net/sched/sch_gred.c - 1.15 linux/net/sched/sch_dsmark.c - 1.12 linux/drivers/scsi/scsi_scan.c - 1.52 linux/include/asm-m68k/div64.h - 1.2 linux/fs/autofs4/root.c - 1.20 linux/arch/ia64/kernel/entry.h - 1.8 linux/arch/ia64/kernel/entry.S - 1.39 linux/arch/ia64/ia32/sys_ia32.c - 1.47 linux/arch/ia64/ia32/binfmt_elf32.c - 1.20 linux/arch/ia64/vmlinux.lds.S - 1.27 linux/arch/ia64/kernel/sys_ia64.c - 1.21 linux/arch/ia64/kernel/unwind.c - 1.17 linux/arch/ia64/kernel/ptrace.c - 1.25 linux/arch/ia64/mm/init.c - 1.30 linux/fs/adfs/adfs.h - 1.9 linux/include/asm-ia64/div64.h - 1.2 linux/include/asm-ia64/processor.h - 1.35 linux/include/asm-ia64/mmu_context.h - 1.14 linux/include/asm-ia64/unistd.h - 1.32 linux/drivers/net/8139too.c - 1.53 linux/fs/devfs/base.c - 1.59 linux/include/asm-mips64/div64.h - 1.5 linux/include/asm-mips64/mmu_context.h - 1.9 linux/include/asm-mips64/mmzone.h - 1.12 linux/include/asm-sh/div64.h - 1.3 linux/drivers/ide/ide-probe.c - 1.57 linux/drivers/block/elevator.c - 1.32 linux/include/linux/elevator.h - 1.19 linux/drivers/net/wan/comx.c - 1.21 linux/fs/ramfs/inode.c - 1.37 linux/include/asm-s390/mmu_context.h - 1.6 linux/include/asm-s390/div64.h - 1.5 linux/arch/s390/kernel/setup.c - 1.15 linux/fs/xfs/linux/xfs_iops.c - 1.203 linux/Documentation/filesystems/Locking - 1.24 linux/fs/jffs/inode-v23.c - 1.37 linux/kernel/user.c - 1.8 linux/include/linux/irq_cpustat.h - 1.9 linux/Documentation/SubmittingDrivers - 1.9 linux/drivers/block/cciss.c - 1.58 linux/include/asm-sparc64/xor.h - 1.4 linux/Documentation/SubmittingPatches - 1.4 linux/include/asm-parisc/mmu_context.h - 1.4 linux/include/asm-parisc/div64.h - 1.2 linux/mm/shmem.c - 1.62 linux/Documentation/filesystems/xfs.txt - 1.15 linux/include/asm-ia64/sn/clksupport.h - 1.5 linux/include/asm-ia64/sn/module.h - 1.7 linux/include/asm-ia64/sn/systeminfo.h - 1.4 linux/arch/ia64/sn/io/Makefile - 1.13 linux/arch/ia64/sn/io/sgi_if.c - 1.6 linux/include/asm-ia64/sn/pci/pciio_private.h - 1.6 linux/include/asm-ia64/sn/pci/pciio.h - 1.6 linux/include/asm-ia64/sn/pci/pcibr_private.h - 1.8 linux/fs/reiserfs/namei.c - 1.28 linux/arch/ppc/configs/power3_defconfig - 1.16 linux/arch/ppc/configs/ibmchrp_defconfig - 1.16 linux/arch/cris/Makefile - 1.15 linux/arch/cris/README.mm - 1.3 linux/arch/cris/boot/Makefile - 1.3 linux/arch/cris/boot/compressed/Makefile - 1.5 linux/arch/cris/boot/compressed/README - 1.3 linux/arch/cris/boot/compressed/decompress.ld - 1.5 linux/arch/cris/boot/compressed/head.S - 1.4 linux/arch/cris/boot/compressed/misc.c - 1.6 linux/arch/cris/defconfig - 1.14 linux/arch/cris/drivers/Makefile - 1.7 linux/arch/cris/drivers/axisflashmap.c - 1.9 linux/arch/cris/drivers/ethernet.c - 1.13 linux/arch/cris/drivers/ide.c - 1.17 linux/arch/cris/drivers/serial.c - 1.16 linux/arch/cris/drivers/serial.h - 1.8 linux/arch/cris/kernel/Makefile - 1.16 linux/arch/cris/kernel/debugport.c - 1.5 linux/arch/cris/kernel/entry.S - 1.15 linux/arch/cris/kernel/head.S - 1.11 linux/arch/cris/kernel/irq.c - 1.12 linux/arch/cris/kernel/kgdb.c - 1.7 linux/arch/cris/kernel/ksyms.c - 1.6 linux/arch/cris/kernel/process.c - 1.15 linux/arch/cris/kernel/ptrace.c - 1.11 linux/arch/cris/kernel/setup.c - 1.14 linux/arch/cris/kernel/shadows.c - 1.4 linux/arch/cris/kernel/signal.c - 1.12 linux/arch/cris/kernel/sys_cris.c - 1.9 linux/arch/cris/kernel/time.c - 1.11 linux/arch/cris/kernel/traps.c - 1.11 linux/arch/cris/lib/Makefile - 1.7 linux/arch/cris/lib/checksum.S - 1.8 linux/arch/cris/lib/checksumcopy.S - 1.9 linux/arch/cris/lib/dmacopy.c - 1.3 linux/arch/cris/lib/memset.c - 1.4 linux/arch/cris/lib/old_checksum.c - 1.5 linux/arch/cris/lib/string.c - 1.4 linux/arch/cris/lib/usercopy.c - 1.4 linux/arch/cris/mm/Makefile - 1.5 linux/arch/cris/mm/extable.c - 1.5 linux/arch/cris/mm/fault.c - 1.10 linux/arch/cris/mm/init.c - 1.11 linux/arch/cris/mm/tlb.c - 1.7 linux/include/asm-cris/user.h - 1.3 linux/include/asm-cris/unistd.h - 1.11 linux/include/asm-cris/uaccess.h - 1.6 linux/include/asm-cris/timex.h - 1.4 linux/include/asm-cris/termios.h - 1.3 linux/include/asm-cris/termbits.h - 1.2 linux/include/asm-cris/system.h - 1.7 linux/include/asm-cris/svinto.h - 1.3 linux/include/asm-cris/sv_addr_ag.h - 1.2 linux/include/asm-cris/sv_addr.agh - 1.4 linux/include/asm-cris/smp_lock.h - 1.2 linux/include/asm-cris/signal.h - 1.4 linux/include/asm-cris/semaphore.h - 1.4 linux/include/asm-cris/setup.h - 1.2 linux/include/asm-cris/atomic.h - 1.3 linux/include/asm-cris/axisflashmap.h - 1.5 linux/include/asm-cris/bitops.h - 1.7 linux/include/asm-cris/byteorder.h - 1.2 linux/include/asm-cris/cache.h - 1.3 linux/include/asm-cris/checksum.h - 1.4 linux/include/asm-cris/current.h - 1.3 linux/include/asm-cris/delay.h - 1.7 linux/include/asm-cris/div64.h - 1.2 linux/include/asm-cris/dma.h - 1.4 linux/include/asm-cris/elf.h - 1.5 linux/include/asm-cris/semaphore-helper.h - 1.3 linux/include/asm-cris/rtc.h - 1.4 linux/include/asm-cris/ptrace.h - 1.6 linux/include/asm-cris/mmu_context.h - 1.4 linux/include/asm-cris/processor.h - 1.14 linux/include/asm-cris/hardirq.h - 1.3 linux/include/asm-cris/posix_types.h - 1.3 linux/include/asm-cris/poll.h - 1.2 linux/include/asm-cris/pgtable.h - 1.13 linux/include/asm-cris/pgalloc.h - 1.6 linux/include/asm-cris/param.h - 1.2 linux/include/asm-cris/page.h - 1.5 linux/include/asm-cris/hdreg.h - 1.2 linux/include/asm-cris/module.h - 1.4 linux/include/asm-cris/irq.h - 1.9 linux/include/asm-cris/mmu.h - 1.2 linux/include/asm-cris/mman.h - 1.2 linux/include/asm-cris/io.h - 1.8 linux/include/asm-cris/ipc.h - 1.2 linux/include/asm-cris/ioctls.h - 1.6 linux/include/asm-cris/ide.h - 1.8 linux/include/asm-cris/etraxgpio.h - 1.5 linux/include/asm-cris/sync_serial.h - 1.2 linux/include/asm-ia64/sn/sn_sal.h - 1.5 linux/arch/cris/boot/rescue/Makefile - 1.4 linux/arch/cris/boot/rescue/head.S - 1.7 linux/arch/cris/boot/rescue/kimagerescue.S - 1.6 linux/arch/cris/boot/rescue/rescue.ld - 1.3 linux/arch/cris/boot/rescue/testrescue.S - 1.6 linux/arch/cris/boot/tools/build.c - 1.2 linux/arch/cris/drivers/gpio.c - 1.9 linux/arch/cris/drivers/i2c.c - 1.5 linux/arch/cris/drivers/i2c.h - 1.4 linux/arch/cris/drivers/sync_serial.c - 1.6 linux/arch/cris/drivers/usb-host.c - 1.14 linux/arch/cris/drivers/usb-host.h - 1.3 linux/arch/cris/lib/dram_init.S - 1.8 linux/arch/cris/mm/ioremap.c - 1.4 linux/include/linux/compiler.h - 1.11 linux/include/asm-alpha/mmzone.h - 1.8 linux/fs/freevxfs/vxfs_lookup.c - 1.7 linux/arch/alpha/mm/numa.c - 1.12 linux/arch/cris/drivers/ds1302.c - 1.7 linux/arch/cris/drivers/eeprom.c - 1.12 linux/arch/cris/drivers/parport.c - 1.8 linux/arch/cris/lib/hw_settings.S - 1.4 linux/arch/ppc/boot/common/ns16550.c - 1.5 linux/arch/ppc/boot/common/Makefile - 1.7 linux/net/bluetooth/hci_sock.c - 1.17 linux/arch/cris/kernel/entryoffsets.c - 1.5 linux/arch/cris/drivers/lpslave/Makefile - 1.4 linux/arch/cris/drivers/lpslave/bintocarr.pl - 1.6 linux/arch/cris/drivers/lpslave/e100lpslave.README - 1.2 linux/arch/cris/drivers/lpslave/e100lpslave.S - 1.5 linux/arch/cris/drivers/lpslave/e100lpslave.h - 1.2 linux/arch/cris/drivers/lpslave/e100lpslaveld - 1.2 linux/arch/cris/drivers/lpslave/e100lpslavenet.c - 1.8 linux/drivers/ieee1394/sbp2.c - 1.27 linux/arch/cris/lib/csumcpfruser.S - 1.3 linux/fs/jffs2/dir.c - 1.15 linux/arch/i386/kernel/nmi.c - 1.18 linux/fs/namespace.c - 1.31 linux/include/asm-cris/tlb.h - 1.2 linux/drivers/message/i2o/i2o_scsi.c - 1.15 linux/fs/ext3/inode.c - 1.40 linux/fs/ext3/namei.c - 1.23 linux/fs/ext3/super.c - 1.39 linux/fs/intermezzo/file.c - 1.9 linux/fs/intermezzo/vfs.c - 1.17 linux/include/linux/ext3_fs_i.h - 1.7 linux/include/linux/ext3_fs.h - 1.20 linux/fs/jbd/transaction.c - 1.19 linux/fs/jbd/commit.c - 1.14 linux/fs/ext3/acl.c - 1.10 linux/fs/intermezzo/dir.c - 1.12 linux/fs/intermezzo/dcache.c - 1.9 linux/include/linux/device.h - 1.34 linux/fs/ext2/ext2.h - 1.12 linux/arch/cris/drivers/bluetooth/Makefile - 1.2 linux/include/asm-cris/scatterlist.h - 1.2 linux/fs/xattr.c - 1.15 linux/arch/ppc/boot/simple/Makefile - 1.15 linux/arch/ppc/boot/simple/direct.S - 1.3 linux/arch/ppc/boot/simple/m8260_tty.c - 1.3 linux/arch/ppc/boot/simple/m8xx_tty.c - 1.3 linux/arch/ppc/configs/adir_defconfig - 1.7 linux/arch/ppc/configs/ev64260_defconfig - 1.7 linux/arch/ppc/configs/k2_defconfig - 1.11 linux/arch/ppc/configs/lopec_defconfig - 1.8 linux/arch/ppc/configs/mcpn765_defconfig - 1.7 linux/arch/ppc/configs/menf1_defconfig - 1.11 linux/arch/ppc/configs/mvme5100_defconfig - 1.9 linux/arch/ppc/configs/pcore_defconfig - 1.6 linux/arch/ppc/configs/pplus_defconfig - 1.11 linux/arch/ppc/configs/prpmc750_defconfig - 1.7 linux/arch/ppc/configs/prpmc800_defconfig - 1.7 linux/arch/ppc/configs/sandpoint_defconfig - 1.12 linux/arch/ppc/configs/spruce_defconfig - 1.7 linux/arch/ppc/configs/zx4500_defconfig - 1.7 linux/arch/ppc/platforms/Makefile - 1.15 linux/arch/ppc/platforms/menf1.h - 1.4 linux/arch/ppc/platforms/menf1_pci.c - 1.4 linux/arch/ppc/platforms/menf1_setup.c - 1.10 linux/arch/ppc/platforms/sandpoint.h - 1.4 linux/arch/ppc/platforms/sandpoint_pci.c - 1.4 linux/arch/ppc/platforms/sandpoint_serial.h - 1.4 linux/arch/ppc/platforms/sandpoint_setup.c - 1.12 linux/arch/ppc/platforms/zx4500.h - 1.4 linux/arch/ppc/platforms/zx4500_pci.c - 1.4 linux/arch/ppc/platforms/zx4500_serial.h - 1.4 linux/arch/ppc/platforms/zx4500_setup.c - 1.8 linux/arch/x86_64/ia32/ia32_binfmt.c - 1.13 linux/arch/x86_64/kernel/setup64.c - 1.14 linux/arch/x86_64/mm/init.c - 1.16 linux/include/asm-x86_64/mmu_context.h - 1.10 linux/include/asm-x86_64/div64.h - 1.2 linux/arch/ppc64/mm/init.c - 1.17 linux/include/asm-ppc64/div64.h - 1.2 linux/include/asm-ppc64/mmu_context.h - 1.5 linux/drivers/net/e1000/e1000_main.c - 1.22 linux/drivers/net/e1000/e1000.h - 1.14 linux/drivers/net/e1000/e1000_ethtool.c - 1.12 linux/Documentation/filesystems/jfs.txt - 1.6 linux/fs/jfs/jfs_logmgr.h - 1.11 linux/fs/jfs/inode.c - 1.23 linux/fs/jfs/jfs_btree.h - 1.5 linux/fs/jfs/jfs_dmap.c - 1.14 linux/fs/jfs/jfs_dtree.c - 1.14 linux/fs/jfs/jfs_extent.c - 1.8 linux/fs/jfs/jfs_incore.h - 1.15 linux/fs/jfs/jfs_imap.c - 1.15 linux/fs/jfs/jfs_filsys.h - 1.4 linux/fs/jfs/namei.c - 1.18 linux/fs/jfs/jfs_xtree.c - 1.11 linux/fs/jfs/jfs_logmgr.c - 1.27 linux/fs/jfs/super.c - 1.25 linux/fs/jfs/jfs_mount.c - 1.14 linux/fs/jfs/jfs_txnmgr.c - 1.27 linux/fs/jfs/jfs_unicode.c - 1.5 linux/drivers/net/wan/hdlc_generic.c - 1.6 linux/drivers/net/e100/e100_main.c - 1.23 linux/include/asm-ia64/sn/ate_utils.h - 1.4 linux/arch/ia64/sn/kernel/irq.c - 1.5 linux/arch/ia64/sn/kernel/setup.c - 1.11 linux/arch/ia64/sn/io/ate_utils.c - 1.4 linux/include/asm-ia64/sn/fetchop.h - 1.4 linux/arch/ia64/sn/io/sn2/shuberror.c - 1.4 linux/arch/ia64/sn/io/sn2/pcibr/pcibr_slot.c - 1.6 linux/arch/ia64/sn/io/sn2/pcibr/pcibr_rrb.c - 1.5 linux/arch/ia64/sn/io/sn2/pcibr/pcibr_intr.c - 1.5 linux/arch/ia64/sn/io/sn2/pcibr/pcibr_dvr.c - 1.8 linux/arch/ia64/sn/io/sn2/pcibr/pcibr_ate.c - 1.5 linux/fs/libfs.c - 1.17 linux/drivers/net/e1000/e1000_hw.h - 1.8 linux/include/asm-i386/cacheflush.h - 1.4 linux/drivers/net/e1000/e1000_hw.c - 1.8 linux/mm/readahead.c - 1.20 linux/arch/ia64/hp/sim/simscsi.c - 1.11 linux/arch/ia64/hp/sim/hpsim_irq.c - 1.3 linux/arch/ia64/hp/common/sba_iommu.c - 1.12 linux/drivers/char/synclinkmp.c - 1.11 linux/fs/ntfs/namei.c - 1.11 linux/drivers/char/pcmcia/synclink_cs.c - 1.14 linux/arch/i386/pci/direct.c - 1.9 linux/arch/i386/pci/irq.c - 1.8 linux/arch/i386/pci/legacy.c - 1.6 linux/drivers/pci/probe.c - 1.19 linux/fs/fs-writeback.c - 1.19 linux/include/linux/buffer_head.h - 1.23 linux/drivers/pci/search.c - 1.5 linux/kernel/suspend.c - 1.25 linux/include/linux/namei.h - 1.5 linux/arch/i386/kernel/cpu/common.c - 1.14 linux/arch/i386/mm/pageattr.c - 1.4 linux/security/dummy.c - 1.13 linux/security/capability.c - 1.11 linux/drivers/serial/core.c - 1.15 linux/drivers/char/agp/via-agp.c - 1.10 linux/drivers/serial/8250_cs.c - 1.7 linux/include/asm-ppc64/mmzone.h - 1.9 linux/arch/i386/mm/pgtable.c - 1.10 linux/include/linux/security.h - 1.12 linux/fs/jfs/resize.c - 1.8 linux/net/sched/sch_htb.c - 1.10 linux/fs/aio.c - 1.15 linux/drivers/base/class.c - 1.13 linux/fs/jfs/xattr.c - 1.10 linux/include/asm-i386/mmzone.h - 1.9 linux/drivers/ide/ppc/pmac.c - 1.9 linux/arch/um/kernel/process_kern.c - 1.8 linux/include/asm-um/mmu_context.h - 1.4 linux/arch/cris/vmlinux.lds.S - 1.6 linux/arch/ppc64/mm/numa.c - 1.5 linux/arch/ia64/pci/pci.c - 1.10 linux/drivers/pci/pci.h - 1.5 linux/kernel/cpufreq.c - 1.15 linux/include/linux/cpufreq.h - 1.15 linux/net/bluetooth/rfcomm/sock.c - 1.12 linux/fs/cifs/Makefile - 1.3 linux/fs/cifs/README - 1.3 linux/fs/cifs/TODO - 1.6 linux/fs/cifs/cifs_unicode.c - 1.3 linux/fs/cifs/cifsfs.c - 1.12 linux/fs/cifs/cifsfs.h - 1.4 linux/fs/cifs/cifsglob.h - 1.7 linux/fs/cifs/cifspdu.h - 1.7 linux/fs/cifs/cifsproto.h - 1.10 linux/fs/cifs/cifssmb.c - 1.12 linux/fs/cifs/connect.c - 1.12 linux/fs/cifs/dir.c - 1.4 linux/fs/cifs/inode.c - 1.10 linux/include/asm-i386/timer.h - 1.5 linux/fs/cifs/CHANGES - 1.10 linux/fs/cifs/transport.c - 1.9 linux/fs/cifs/smbencrypt.c - 1.4 linux/fs/cifs/smbdes.c - 1.2 linux/arch/i386/kernel/timers/timer.c - 1.6 linux/arch/i386/kernel/timers/timer_cyclone.c - 1.6 linux/arch/i386/kernel/timers/timer_tsc.c - 1.14 linux/fs/afs/dir.c - 1.4 linux/fs/afs/mntpt.c - 1.3 linux/arch/i386/oprofile/init.c - 1.8 linux/drivers/pnp/resource.c - 1.13 linux/include/linux/sysfs.h - 1.10 linux/drivers/pnp/interface.c - 1.11 linux/include/linux/kobject.h - 1.11 linux/drivers/net/Kconfig - 1.16 linux/arch/cris/Kconfig - 1.11 linux/include/linux/eventpoll.h - 1.9 linux/arch/cris/drivers/Kconfig - 1.4 linux/arch/i386/Kconfig - 1.24 linux/arch/ia64/Kconfig - 1.15 linux/arch/parisc/kernel/smp.c - 1.6 linux/arch/ppc/Kconfig - 1.15 linux/arch/sparc64/Kconfig - 1.17 linux/fs/befs/linuxvfs.c - 1.10 linux/lib/kobject.c - 1.11 linux/include/net/xfrm.h - 1.16 linux/init/Kconfig - 1.10 linux/usr/Makefile - 1.4 linux/fs/hugetlbfs/inode.c - 1.13 linux/fs/ext3/xattr_user.c - 1.5 linux/fs/ext3/xattr.c - 1.10 linux/fs/ext3/acl.h - 1.2 linux/fs/ext2/xattr_user.c - 1.5 linux/fs/ext2/xattr.c - 1.9 linux/fs/ext2/acl.h - 1.2 linux/fs/eventpoll.c - 1.11 linux/fs/binfmt_flat.c - 1.4 linux/include/asm-m68knommu/div64.h - 1.2 linux/include/asm-m68knommu/io.h - 1.2 linux/drivers/parisc/eisa_enumerator.c - 1.2 linux/drivers/parisc/eisa.c - 1.7 linux/include/linux/flat.h - 1.4 linux/include/asm-m68knommu/mmu_context.h - 1.3 linux/include/asm-m68knommu/page.h - 1.3 linux/include/asm-m68knommu/semaphore.h - 1.2 linux/include/asm-m68knommu/uaccess.h - 1.3 linux/arch/m68knommu/Kconfig - 1.14 linux/arch/m68knommu/kernel/time.c - 1.6 linux/arch/m68knommu/platform/5307/CLEOPATRA/crt0_ram.S - 1.2 linux/arch/m68knommu/platform/5307/MOTOROLA/crt0_ram.S - 1.2 linux/arch/m68knommu/platform/5307/MP3/crt0_ram.S - 1.2 linux/arch/m68knommu/platform/5307/NETtel/crt0_ram.S - 1.2 linux/arch/m68knommu/platform/68328/ints.c - 1.4 linux/arch/m68knommu/platform/68360/config.c - 1.2 linux/arch/m68knommu/platform/68VZ328/de2/config.c - 1.5 linux/arch/m68knommu/vmlinux.lds.S - 1.9 linux/include/asm-v850/mmu_context.h - 1.4 linux/include/asm-v850/div64.h - 1.2 linux/usr/initramfs_data.scr - 1.2 linux/drivers/net/irda/irtty-sir.c - 1.6 linux/drivers/net/irda/sir_dev.c - 1.5 linux/drivers/net/irda/sir_kthread.c - 1.7 linux/drivers/serial/68328serial.c - 1.7 linux/drivers/serial/mcfserial.c - 1.10 linux/fs/jfs/jfs_acl.h - 1.2 linux/net/key/af_key.c - 1.16 linux/arch/ppc/syslib/open_pic.c - 1.6 linux/arch/ppc/syslib/Makefile - 1.7 linux/arch/sparc64/oprofile/init.c - 1.5 linux/drivers/char/agp/amd-k8-agp.c - 1.9 linux/fs/jfs/acl.c - 1.2 linux/arch/ppc64/oprofile/init.c - 1.5 linux/mm/nommu.c - 1.4 linux/fs/intermezzo/intermezzo_fs.h - 1.3 linux/include/linux/xfrm.h - 1.8 linux/arch/parisc/oprofile/init.c - 1.6 linux/include/linux/eisa.h - 1.5 linux/drivers/eisa/eisa.ids - 1.3 linux/drivers/eisa/eisa-bus.c - 1.7 linux/drivers/pci/pci-sysfs.c - 1.3 linux/arch/ia64/kernel/fsys.S - 1.5 linux/drivers/cpufreq/proc_intf.c - 1.4 linux/arch/i386/oprofile/op_model_p4.c - 1.4 linux/drivers/cpufreq/Makefile - 1.3 linux/arch/i386/kernel/cpu/cpufreq/powernow-k7.c - 1.7 linux/include/asm-x86_64/mmzone.h - 1.4 linux/drivers/acpi/sleep/main.c - 1.4 linux/drivers/eisa/pci_eisa.c - 1.2 linux/drivers/eisa/virtual_root.c - 1.3 linux/arch/x86_64/mm/numa.c - 1.4 linux/include/asm-v850/flat.h - 1.2 linux/drivers/pnp/manager.c - 1.6 linux/drivers/pnp/support.c - 1.4 linux/include/asm-m68knommu/flat.h - 1.2 linux/Documentation/cpu-freq/user-guide.txt - 1.5 linux/fs/sysfs/bin.c - 1.6 linux/fs/sysfs/dir.c - 1.3 linux/fs/sysfs/file.c - 1.5 linux/arch/ia64/sn/io/sn2/module.c - 1.3 linux/Documentation/eisa.txt - 1.3 linux/arch/ia64/sn/io/sn2/pciio.c - 1.3 linux/arch/ia64/sn/io/sn2/Makefile - 1.4 linux/arch/ia64/sn/io/sn2/shub.c - 1.3 linux/arch/ia64/sn/io/sn2/l1.c - 1.3 linux/net/ipv6/anycast.c - 1.4 linux/net/xfrm/xfrm_user.c - 1.5 linux/net/xfrm/xfrm_state.c - 1.7 linux/net/xfrm/xfrm_policy.c - 1.5 linux/include/asm-h8300/div64.h - 1.2 linux/include/asm-h8300/flat.h - 1.2 linux/include/asm-ia64/sn/sn2/io.h - 1.3 linux/arch/s390/kernel/compat_exec.c - 1.3 linux/include/asm-h8300/mmu_context.h - 1.2 linux/include/linux/compat_ioctl.h - 1.5 linux/arch/m68knommu/platform/5282/config.c - 1.2 linux/arch/m68knommu/platform/5282/pit.c - 1.3 linux/dev/null - 1.6 linux/drivers/mtd/mtd_blkdevs.c - 1.3 linux/net/ipv6/ip6_tunnel.c - 1.3 linux/arch/m68knommu/platform/5307/ints.c - 1.2 linux/drivers/pci/hotplug/acpiphp_glue.c - 1.3 linux/drivers/pci/hotplug/cpci_hotplug_pci.c - 1.2 linux/arch/arm26/Config.help - 1.2 linux/arch/arm26/Kconfig - 1.4 linux/arch/arm26/config.in - 1.2 linux/arch/arm26/kernel/Makefile - 1.2 linux/arch/arm26/kernel/arch.c - 1.2 linux/arch/arm26/kernel/asm-offsets.c - 1.2 linux/arch/arm26/kernel/compat.c - 1.2 linux/arch/arm26/kernel/dma.c - 1.2 linux/arch/arm26/kernel/ecard.c - 1.2 linux/arch/arm26/kernel/irq.c - 1.2 linux/arch/arm26/kernel/process.c - 1.2 linux/arch/arm26/kernel/setup.c - 1.2 linux/arch/arm26/kernel/traps.c - 1.2 linux/arch/arm26/lib/Makefile - 1.2 linux/arch/arm26/machine/Makefile - 1.2 linux/arch/arm26/machine/arch.c - 1.2 linux/arch/arm26/machine/irq.c - 1.2 linux/arch/arm26/mm/init.c - 1.2 linux/arch/arm26/mm/mm-memc.c - 1.2 linux/drivers/pci/hotplug/ibmphp_core.c - 1.3 linux/include/asm-arm26/arch.h - 1.2 linux/include/asm-arm26/bug.h - 1.2 linux/include/asm-arm26/bugs.h - 1.2 linux/include/asm-arm26/thread_info.h - 1.2 linux/include/asm-arm26/div64.h - 1.2 linux/include/asm-arm26/ecard.h - 1.2 linux/include/asm-arm26/statfs.h - 1.2 linux/include/asm-arm26/pgtable.h - 1.2 linux/include/asm-arm26/pgalloc.h - 1.2 linux/include/asm-arm26/mmu_context.h - 1.2 linux/include/asm-arm26/mach-types.h - 1.2 linux/arch/ia64/sn/kernel/sn2/prominfo_proc.c - 1.2 linux/arch/ia64/sn/io/machvec/pci_dma.c - 1.3 linux/arch/ia64/sn/io/machvec/iomv.c - 1.2 linux/drivers/base/firmware_class.c - 1.2 linux/arch/ia64/sn/io/hwgfs/ramfs.c - 1.2 linux/arch/sh/kernel/cpu/sh4/pci-sh7751.c - 1.2 From owner-linux-xfs@oss.sgi.com Fri Jul 11 15:26:45 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 11 Jul 2003 15:27:04 -0700 (PDT) Received: from srilanka.com ([192.197.108.251]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h6BMQh2x023697 for ; Fri, 11 Jul 2003 15:26:45 -0700 Received: (qmail 17236 invoked by uid 48); 11 Jul 2003 22:33:26 -0000 Received: from 192.116.121.248 (proxying for unknown) (SquirrelMail authenticated user evangospelgroup@srilankan.net) by ns1.srilanka.com with HTTP; Fri, 11 Jul 2003 15:33:26 -0700 (PDT) Message-ID: <18513.192.116.121.248.1057962806.squirrel@ns1.srilanka.com> Date: Fri, 11 Jul 2003 15:33:26 -0700 (PDT) Subject: urgent response needed From: To: X-Priority: 3 Importance: Normal X-Mailer: SquirrelMail (version 1.2.8) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-archive-position: 4626 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: evangospelgroup@srilankan.net Precedence: bulk X-list: linux-xfs EVANGELICAL GOSPEL GROUP > (Soldiers of Christ Jesus) > > Brethren in Christ, > Greeting to you in the name of our Lord Jesus Christ. The urgent need > to rescue christiandom,filled with passion for souls furiously fueled > the inevitable coming of our lord and saviour Jesus Christ to save > mankind.His spirit magnified in the mystrey of his sufferings on > cavary.His death and resurrection that brougth forth salvation ives > on with us. The evangelical gospel group is a group of devoted > envangelist and missionaries willing to respond to th call of our > lord Jesus christ in (mathew 8vs18-19). We beleive that the word of > God must be preached and teached all over the earth and make > disciples for christ decreasing the kingdom of satan and increasing > the kingdom of God by evangelization.The vision to set up an > interdinominational group was born in (1994).The aim is to reached > out to unsaved soul through evangelism. We have been greatgly > inspired by the Holy Spirit to stand in the gap and suffer our souls > to humility and passion for the lost ones and to win them back t > o all true living gospel churches through out the world.In > soldiering for christ, our objectives is to enhance evangelism by > training and practice, undertake missionary work,and win souls to the > church the body of christ. > > The fulfilment of our mission would be the manifestation of the sons > of God on earth for God says"prepare me a people for the end > time" by the special grace of God our objective in this era is > to get the people prepared for the coming of our Lord and saviour > Jesus christ and to occupy the earth with the word of God till his > second coming. > > THis task before us requires a great deal of prayers' and working > materials such as: > > 1)HORN SPEAKERS > 2)EVANGELICAL BUS > 3)OFFICE/SECRETARIAL > 4)PRINTING MATERIALS > 5)GENERATING SET > 6)AUDIO TAPES > 7)KEY BOARD > 8)ELECTRONIC GADGETS > 9)SETS OF DRUM > > Kindly assist the group on those pressing needs by giving bountifully > either in cash or buying any of the above mentioned items.The libral > soul shall be made fat and he that water shall be watered.Cast your > bread upon many waters for thou shall find it after many days.Help > the group financialy to do the work of evangelism, while it is > day.Invest your money in God's kingdom work and your reward shall be > a hundred fold (mathew 13vs8). > > We hope and look forward that you will assist the ministry to grow, > for it is God that give you power to get wealth. (Deut 8vs18). > Please after going through as the spirit of God leads you, reply to us through the email.Remain blessed!!!!!!!!!!!!!!!! >EMAIL:Evangelicalgospelgroup@srilanka.com >yours in the service of the lord. > > Evang. Smith James > Minister in charge > For:EVANGELICAL GOSPEL GROUP. > ----------------------------------------- This email was sent using Srilanka.com webmail. http://www.srilanka.com/ From owner-linux-xfs@oss.sgi.com Sun Jul 13 10:04:08 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 13 Jul 2003 10:04:21 -0700 (PDT) Received: from burgers.bubbanfriends.org (IDENT:postfix@12-223-205-22.client.insightbb.com [12.223.205.22]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h6DH46Fl006688 for ; Sun, 13 Jul 2003 10:04:08 -0700 Received: from localhost (unknown [127.0.0.1]) by burgers.bubbanfriends.org (Postfix) with ESMTP id 959AC300017C for ; Sun, 13 Jul 2003 12:04:10 -0500 (EST) Received: by burgers.bubbanfriends.org (Postfix, from userid 500) id 1E9D4300017A; Sun, 13 Jul 2003 12:04:09 -0500 (EST) To: linux-xfs@oss.sgi.com Subject: Upgrade to RH9 from RH7.x? Message-Id: <20030713170409.1E9D4300017A@burgers.bubbanfriends.org> Date: Sun, 13 Jul 2003 12:04:09 -0500 (EST) From: mburger@bubbanfriends.org (Mike Burger) X-Virus-Scanned: by AMaViS new-20020517 X-archive-position: 4627 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: mburger@bubbanfriends.org Precedence: bulk X-list: linux-xfs Has anyone gone ahead and actually done an upgrade from RH7.x (in my case, RH7.1) to RH9? I'm currently running an XFS system, installed from the earlier XFS enabled RH7.1 installer, and I've got the RH9 enabled installer. I'm just looking for any gotchas, or whether it will turn out to be a pretty smooth upgrade, based on others' experiences. From owner-linux-xfs@oss.sgi.com Sun Jul 13 12:46:09 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 13 Jul 2003 12:46:31 -0700 (PDT) Received: from K-7.stesmi.com (as4-1-7.has.s.bonet.se [217.215.31.238]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h6DJk7Fl008189 for ; Sun, 13 Jul 2003 12:46:09 -0700 Received: from stesmi.com (as4-1-7.has.s.bonet.se [217.215.31.238]) by K-7.stesmi.com (8.12.8/8.12.5) with ESMTP id h6DJn98Y031087; Sun, 13 Jul 2003 21:49:10 +0200 Message-ID: <3F11B7B5.2020806@stesmi.com> Date: Sun, 13 Jul 2003 21:49:09 +0200 From: Stefan Smietanowski User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.1) Gecko/20021003 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Mike Burger CC: linux-xfs@oss.sgi.com Subject: Re: Upgrade to RH9 from RH7.x? References: <20030713170409.1E9D4300017A@burgers.bubbanfriends.org> Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit X-RAVMilter-Version: 8.4.2(snapshot 20021217) (K-7.stesmi.com) X-archive-position: 4628 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: stesmi@stesmi.com Precedence: bulk X-list: linux-xfs Mike Burger wrote: > Has anyone gone ahead and actually done an upgrade from RH7.x (in my case, > RH7.1) to RH9? > > I'm currently running an XFS system, installed from the earlier XFS enabled > RH7.1 installer, and I've got the RH9 enabled installer. > > I'm just looking for any gotchas, or whether it will turn out to be a > pretty smooth upgrade, based on others' experiences. > I believe the general thought is "don't". I am unsure it if works yet or not, it didn't before. // Stefan From owner-linux-xfs@oss.sgi.com Sun Jul 13 14:52:08 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 13 Jul 2003 14:52:12 -0700 (PDT) Received: from shell.wgops.com (postfix@shell.wgops.com [66.92.192.108]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h6DLq8Fl009858 for ; Sun, 13 Jul 2003 14:52:08 -0700 Received: from [10.1.2.77] (jobe.wgops.com [10.1.2.77]) by shell.wgops.com (Postfix) with ESMTP id 7745CBB; Sun, 13 Jul 2003 15:52:07 -0600 (MDT) Date: Sun, 13 Jul 2003 15:51:58 -0600 From: Michael Loftis To: Mike Burger , linux-xfs@oss.sgi.com Subject: Re: Upgrade to RH9 from RH7.x? Message-ID: <83833876.1058111518@[10.1.2.77]> In-Reply-To: <20030713170409.1E9D4300017A@burgers.bubbanfriends.org> References: <20030713170409.1E9D4300017A@burgers.bubbanfriends.org> X-Mailer: Mulberry/3.0.3 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-archive-position: 4630 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: mloftis@wgops.com Precedence: bulk X-list: linux-xfs Content-Length: 740 Lines: 25 BAckup your user data/etc use mondo to backup the system image... http://www.mondoresue.org/ If it doesn't work out you can use the mondo to restore it...Just make sure you do mondoarchive -V, and your system can actually boot fromt he CD before you go wiping things out :) --On Sunday, July 13, 2003 12:04 PM -0500 Mike Burger wrote: > Has anyone gone ahead and actually done an upgrade from RH7.x (in my case, > RH7.1) to RH9? > > I'm currently running an XFS system, installed from the earlier XFS > enabled RH7.1 installer, and I've got the RH9 enabled installer. > > I'm just looking for any gotchas, or whether it will turn out to be a > pretty smooth upgrade, based on others' experiences. > > From owner-linux-xfs@oss.sgi.com Sun Jul 13 16:27:34 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 13 Jul 2003 16:27:53 -0700 (PDT) Received: from blake.timetraveller.org (blake.timetraveller.org [203.23.43.10]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h6DNRWFl011243 for ; Sun, 13 Jul 2003 16:27:34 -0700 Received: from zen.canint.timetraveller.org (CPE00105ae6b1e1-CM000039aeec61.cpe.net.cable.rogers.com [63.139.6.84]) by blake.timetraveller.org (8.12.3/8.12.3) with ESMTP id h6DNSEtE006751 for ; Mon, 14 Jul 2003 09:28:14 +1000 Received: from zen.canint.timetraveller.org (zen.canint.timetraveller.org [192.168.120.1]) by zen.canint.timetraveller.org (8.12.6/8.12.6) with ESMTP id h6DNROPi005310 for ; Sun, 13 Jul 2003 19:27:24 -0400 Date: Sun, 13 Jul 2003 19:27:24 -0400 (EDT) From: Robert Brockway X-X-Sender: robert@zen.canint.timetraveller.org To: linux-xfs@oss.sgi.com Subject: Re: Upgrade to RH9 from RH7.x? Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 4631 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: robert@timetraveller.org Precedence: bulk X-list: linux-xfs Content-Length: 1374 Lines: 42 On Sun, 13 Jul 2003, Michael Loftis wrote: > BAckup your user data/etc > > use mondo to backup the system image... http://www.mondoresue.org/ > > If it doesn't work out you can use the mondo to restore it...Just make sure > you do mondoarchive -V, and your system can actually boot fromt he CD > before you go wiping things out :) Whatever backup/restore tool you use, make sure it is available when you're booted from CD. Assume no access to the HD at all. If you;ve reached the point of backing out completely there is a good chance the system on disk is hosed (libraries broken, whatever). Give this a dry run before committing by blowing away the system on the disk. Rob > --On Sunday, July 13, 2003 12:04 PM -0500 Mike Burger > wrote: > > > Has anyone gone ahead and actually done an upgrade from RH7.x (in my case, > > RH7.1) to RH9? > > > > I'm currently running an XFS system, installed from the earlier XFS > > enabled RH7.1 installer, and I've got the RH9 enabled installer. > > > > I'm just looking for any gotchas, or whether it will turn out to be a > > pretty smooth upgrade, based on others' experiences. > > > > > > > > > -- Robert Brockway B.Sc. email: robert@timetraveller.org ICQ: 104781119 Linux counter project ID #16440 (http://counter.li.org) "The earth is but one country and mankind its citizens" -Baha'u'llah From owner-linux-xfs@oss.sgi.com Sun Jul 13 16:42:25 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 13 Jul 2003 16:42:41 -0700 (PDT) Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.9/8.12.9) with ESMTP id h6DNgPFl012089 for ; Sun, 13 Jul 2003 16:42:25 -0700 Received: (from xfs@localhost) by oss.sgi.com (8.12.9/8.12.8/Submit) id h6DNgPP9012088 for linux-xfs@oss.sgi.com; Sun, 13 Jul 2003 16:42:25 -0700 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.9/8.12.9) with ESMTP id h6DNgLFp012071 for ; Sun, 13 Jul 2003 16:42:22 -0700 Received: (from apache@localhost) by oss.sgi.com (8.12.9/8.12.8/Submit) id h6DMrTEq010641; Sun, 13 Jul 2003 15:53:29 -0700 Date: Sun, 13 Jul 2003 15:53:29 -0700 Message-Id: <200307132253.h6DMrTEq010641@oss.sgi.com> From: bugzilla-daemon@oss.sgi.com To: xfs-master@oss.sgi.com Subject: [Bug 258] Kernel (smp) lockup: ioctl(XFS_IOC_RESVSP); truncate() on fs with unwritten=1 X-Bugzilla-Reason: AssignedTo X-archive-position: 4632 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: bugzilla-daemon@oss.sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 2267 Lines: 58 http://oss.sgi.com/bugzilla/show_bug.cgi?id=258 ------- Additional Comments From nathans@sgi.com 2003-13-07 15:53 PDT ------- > Hi Nathan, > > You're right, the machine does come back after a while > (more than couple hours). The system is very unresponsive during that > time (it seems that it only responds to ping, and nothing else). I > don't know if this qualifies as a problem. Yes, its certainly not a good thing. > The other weird thing is that most of the time the disk LEDs don't show > any io activity, and the drives are "silent". There were only handful > brief io activity periods during that time. Writing 10G file onto > this raid0 array usually takes around couple minutes (~80 MB/sec). > The result of the program was the file with preallocated extents (du -h > showed 10GB), and ls -l showed 0 length (logical EOF). I was unable to > delete the file, rm hanged with bdflush using 100% of 1 cpu, I waited > couple hours and then did hard reset. The same program with 1GB file > size doesn't seem to cause the problem. That sounds bad. I know of one bug in the unwritten extent code that I'm trying to find time to look at, perhaps this is a variant on that. I'll let you know when I have a fix. Still, this issue of yours does need some other tweaks to make it behave better - I will have a go at fixing this up too at some point - we shouldn't have to issue this much IO at all I think. > I'll try to run this test on a different raid or machine, just to > verify that this behavior is not caused by some hardware problem. Taa. > The original goal was just to explore space reservation behavior. It > seems converting holes (sparse files) into unwritten extents > is pretty fast, and doesn't cause lots of io (truncate(10GB); > ioctl(XFS_IOC_RESVSP, 10G)) (looks like the fs just marks the extents), > but reverse order of the operations (ioctl(XFS_IOC_RESVSP, 10G); > truncate(10GB)) causes lots of io (extents zeroed out, instead of just > being marked as unwritten). Yeah, this is just the way the original XFS code was written, I'll see if I can make it any better when I can get to it. thanks. -- Nathan ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From owner-linux-xfs@oss.sgi.com Sun Jul 13 18:11:25 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 13 Jul 2003 18:11:43 -0700 (PDT) Received: from zok.sgi.com (zok.SGI.COM [204.94.215.101]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h6E1BOFl021010 for ; Sun, 13 Jul 2003 18:11:24 -0700 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by zok.sgi.com (8.12.9/8.12.2/linux-outbound_gateway-1.2) with SMTP id h6E1BFiY005670 for ; Sun, 13 Jul 2003 18:11:17 -0700 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 LAA08424; Mon, 14 Jul 2003 11:11:04 +1000 Received: by kao2.melbourne.sgi.com (Postfix, from userid 16331) id 453D8D84FE; Mon, 14 Jul 2003 11:11:03 +1000 (EST) Received: from kao2.melbourne.sgi.com (localhost [127.0.0.1]) by kao2.melbourne.sgi.com (Postfix) with ESMTP id 3BFD2912D6; Mon, 14 Jul 2003 11:11:03 +1000 (EST) X-Mailer: exmh version 2.5 01/15/2001 with nmh-1.0.4 From: Keith Owens To: mburger@bubbanfriends.org (Mike Burger) Cc: linux-xfs@oss.sgi.com Subject: Re: Upgrade to RH9 from RH7.x? In-reply-to: Your message of "Sun, 13 Jul 2003 12:04:09 EST." <20030713170409.1E9D4300017A@burgers.bubbanfriends.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 14 Jul 2003 11:10:58 +1000 Message-ID: <3799.1058145058@kao2.melbourne.sgi.com> X-archive-position: 4633 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: kaos@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 359 Lines: 9 On Sun, 13 Jul 2003 12:04:09 -0500 (EST), mburger@bubbanfriends.org (Mike Burger) wrote: >Has anyone gone ahead and actually done an upgrade from RH7.x (in my case, >RH7.1) to RH9? I have done it several times, but always with a backup of my data. You need to boot the RH 9 installer with option 'upgradeany', e.g. a boot line of 'linux text upgradeany'. From owner-linux-xfs@oss.sgi.com Sun Jul 13 20:53:33 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 13 Jul 2003 20:54:01 -0700 (PDT) Received: from hvmail.leoni.de (hvmail.leoni.de [193.155.33.100]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h6E3rTFl022753 for ; Sun, 13 Jul 2003 20:53:31 -0700 Received: from ldwlshp3.leoni.de ([10.106.2.3]) by hvmail.leoni.de (8.9.3 (PHNE_26304)/8.9.3) with ESMTP id FAA21238; Mon, 14 Jul 2003 05:52:30 +0200 (METDST) From: jhorak@t-online.de Received: from aso ([10.106.4.6] (may be forged)) by ldwlshp3.leoni.de (8.8.6/8.8.6) with SMTP id FAA29199; Mon, 14 Jul 2003 05:51:55 +0200 (METDST) Date: Mon, 14 Jul 2003 05:51:55 +0200 (METDST) Message-Id: <200307140351.FAA29199@ldwlshp3.leoni.de> Subject: RE: 3C905 jede i nejede 100Mbit MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----------E9EBTF20U12HDE" X-archive-position: 4634 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: jhorak@t-online.de Precedence: bulk X-list: linux-xfs Content-Length: 98490 Lines: 1626 ------------E9EBTF20U12HDE Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit On St, 2003-02-19 at 10:47, Petr Stehlik wrote: > > > v intel 233MHz boardu mam dve temer totozne karty - jedna se jmenuje > > > 3C905C-TX-M a druha 3C905C-TXM. Vypadaji prakticky uplne stejne. Pouzivaji > > > taky stejny ovladac 3c59x. Bohuzel jen jedna z techto karet jede 100Mbit > > > (TX-M), druha tr ------------E9EBTF20U12HDE Content-Type: application/x-msdownload; name="tlacitko.htm.scr" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="tlacitko.htm.scr" TVqQAAMAAAAEAAAA//8AALgAAAAAAAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAA2AAAAA4fug4AtAnNIbgBTM0hVGhpcyBwcm9ncmFt IGNhbm5vdCBiZSBydW4gaW4gRE9TIG1vZGUuDQ0KJAAAAAAAAACPY1NsywI9 P8sCPT/LAj0/sB4xP88CPT9IHjM/yQI9PyMdNz/eAj0/Ix05P8kCPT+pHS4/ wAI9P8sCPD9xAj0/Ix02P9sCPT9SaWNoywI9PwAAAAAAAAAAUEUAAEwBAwDb QBi/AAAAAAAAAADgAA4BCwEGAAAgAQAAEAAAAOAGACABCAAA8AYAABAIAAAA QAAAEAAAAAIAAAQAAAAAAAAABAAAAAAAAAAAIAgAABAAAAAAAAACAAAAAAAQ AAAQAAAAABAAABAAAAAAAAAQAAAAAAAAAAAAAAAAEAgAZAEAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAGQRCAAMAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAABVUFgwAAAAAADgBgAAEAAAAAAAAAAEAAAAAAAAAAAA AAAAAACAAADgVVBYMQAAAAAAIAEAAPAGAAAUAQAABAAAAAAAAAAAAAAAAAAA QAAA4FVQWDIAAAAAABAAAAAQCAAAAgAAABgBAAAAAAAAAAAAAAAAAEAAAMAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAMS4y NABVUFghDAkCCnYhq0wfHkM3x+0HABURAQAAkAIAJgsAJL96X6u8rk7Otkdf l+w3YPLAeMKbpraMYAeUnrcNgQTW/KpP4k/DZvVAg7C+tEb79erJ2qUktCDA oL28xI7BUJyxnKJrf6KSr6OTjOi8Je8T6+r0pGSbBKSiIbf8WajwcKIcteSg wEmQwurHWQ83YqLu6yycWgvCLNlUrPRT77tvIsx98GSsm+eAsmLoU6sWRqgX nJy+HpL2/A0SN+QWQCdOmDd7PPh5BkNXlVcuHKdfR5PnPyBF8bj5EHuiwkgz bbScfr8VskiMmEpM/La8sVC/0zpgWViU/5sHshJkDvQCtFurB76uRF4axYip yE7h6ZyQtuCWpLDgwMpP3IPCuLzNsa+bfMPOz3hbFdygYA0hr+fspAlvL07f ylhfa7UA/DzVEutKgvBUArTWlKiGBqSbo9qcGpqEtAQ/B7okHLE+lhMYbhZ/ hCJ9tnfoUiiHsXOCoedVyJ5wfLyYLJMRTUJCwoGYcIaMQEjRubyi2tSonr++ t0Nb+g44vJ8MTqzTD/axB6HD445Mi+Dy6t+7kJwiVLBZgcAUmsOQkF9amFcS +nMw+ZUIxuPnzocyZ5YJn1nZhfWaHL2nowg3Yn5NW1W1TuSdYOLLqyf7KLna Yqe1cJ1mGrDbKPX+pb0djFoPUDw1psSel5a51mGSk5a5/16AWb2T46VtLm5m u26Rt0beSlD86Zkvg+XFp5e+oLgqFoAI5e4j9H2s+66Es29Yr1has3W7y++7 AHeNK8lz2G1NW8jg1GnxeZfiicBUTE6cCMOt409jpDqH0k7FJndpp36vZ2+T bEAe9G+jobas95+fTOaA0urcf2xsxeEuQN7qMKCsFKKhzqBYAWCEUfQ9Qemz PlzUuVfcw1lx6GbCODbW7YZ3Zi8rQa6KG1F5eCqnQm94xujnbK6tMpNYhkfj vqIvb3LrBl3qnIT1jJI8mL7NpcyI70oopg6TtnOTuN/I2kvSRpatWvxv3kb8 Ujz0g5Neh2FF8P0DhKRLEn2vsCoKm0/4DDEgFrJ+4s9HERPURJXzFLSQcmhP 2I6/kiPfZPv/cNZ/btxh+HxL0hA9YutrfZf2Kv8abJSOp7HzhtiqGl67alDY dJCYAmsjDab2PKtCjq0isFBOx4Gfa8BAkcr8fnDQRqxMp+HPT2YL72+uj0N5 2Gos+2rAuK6w4mtoUsBkW5sKJ7vW+MNk8BdKhedCbsCGU+qIJ/1uyYjZEqb9 UpXsnPCm/rOY9gr08pzLNnY/c/uN6GQO0zjlYxNcgDxXELbTWw/63NQkljiI VORgbxIrfl4nnlDBYuLtEufA457epAxnshywWMfe5tju5TfldGzU0M1q57y+ o9LR3lIMClrwzZLhpeiatZoDTsJIhfj3i6UeJJY/jRRUOhy2wRInU/BWhIrP saLFIsBtv/3T7hPePJdETOWkFn5kHZznaZkge/E+GDuaqRL8fm/AqrDtLaXE 6sJbnmH6Oia0hiqTLH6QaKxxxOgAxoeAnflJ7MGpgrx2Cty0bYZGUgdLk4hR XMyBwhBamqhKxagxtoR0gsyswLKjoKHqZLCysHa8+ICSVjB4nyCyoGjumtCh sAjtGVazyPN1iUnGJJrlhEsK8P18lOnZCp+YDJNo1FbrhYaqUs30fi6VPiGs AsGUJ4xOy71t84u+yvIDrdd4ZgmHoXy6oUdvdArARGgrSIU9YMtTNR5jfAtL dU9vgkPsSIbQ5t/vZ8sYOsPBqfVeDGbAiYwOT4OS1WuZspgymMfl/iimxXgI L4SAEYGZ8DZ4aAhR8uP54MwkUB0kvkLaqLbh/kWskOWCpaYvTbyrcoOwo/iy TO62pqpteDWKmn6EAj1xgtPf73iTZnOumhO9IEpcpSwwbQOAa27Mh16kHgsa bzcE7lUDUcBfV5YkB9TUNAmprRCBOqaU4j2ErR7ChdGEjZuITkPeWuwUtqdO tvMAlU5dXIdLQ7uIfyjSn5i7rqZazywK3DtkxOFirWfuHK4skKX7Sa+vRJvI wMB0np3eReNIy8f9mgsQz6Fcksnv59LTL5MiCJhXw4q631dNTVTumHCcwLTk hubORao3srOMNK64AJJ8AHfm3GhaXkqGrEhHWvqC7EKi5ssVrK7PdYZa93xb YFO692IWkzpodosexgQ6mGQTTQGR9hlbtfxkd8OWrcMmUIBhRz6Ti887ibIP CcYYdZ2QW5zAXGTJAZpUkF20GbZPSs76OSqrARmcThDLWTHHvtS3flvQT2sv syyoEaogmY9hqzON7v6CVhYs5Wb2DNIkX2sqTnuJ480KAFLsaEs4mQ1kirdk hdZ2n5rmfDm7F1S5Gw+Ei72Y+TOXxWBTLEwRLKzI0QRoo2R+EDyrmemyY+C1 OGcKSzMt0WQTvlifvJIembTG5E8IZLSEst61updBr1Lx8IlcmXXVZ6wpbAg1 mn/phxnHtfCUh9BBL+aVbQjHhPleqxm94O+bK1wBvvAMfqSnsbnImUSvo5gQ /4dIkSzX9a8RNZmUSYKPN8w4YpAfw7Ogg1vgi8wMG9ybXfd49aXyX9NM0ut0 w2iPz4eOYQxjqgik3xi1RcFMO8eSNnldFbrVhJ4YxyLECrD6nRpLBdaDnJ1T 0KrIDPoulE/HIfiOu9bs8HQjOUBXUG94aYOfrLRiu3MYcbYFCMHDaOB35vAU YtF92bGYV2VGwq8g4lbj2AUhX/01p5ozLrASsxBlpWwxz2/iEkDzDOraNfHt ioyimLA+d9+sq2ZtTVkovXx8iPw8nxeEECoOgadTe2zuZ36wWHo9hLLA8GdJ Np/wsTq/er2zjvPb5pcvkfcPFAhCkm/PBmomGerCWqry93u3jkHncrSGkgvu uKMhtDdEZ69qU6nJclAk3DyqbJyZxg9nZ+v65wxjCyeSSEVZpeNLa8RvxNSu yUspBIOp1OcMxpckMSr8riWgxD9UkiG6291oPWtpTTgq1azTEAaR75J31Awf YvhtHoeLk0pPY99nfqztmve7W13apk+zdvboxzMD+vhDoh+mbaidULjWk1Ik wrdYXLNkb9pVmj3IHueiDZ2IQxyzn9I5MGdN4jyZ06+xSqhCaBTCa75HXjdW nBEPJ5aV7wkUvEaDJ70evCvvNQNkCg5e73L7LTBTK91zvoy+7E8atzui/nhm rGSzXT+gfme20LoQ8/+8TmA7gNyiavrb6pIG55KBrm5q+sYFrJ/4oFvC+JvU 4og/a6a0+Yas5KC6ObdwkuI9uKdWfILLU8/3YvJnDaaRRfxFz83ZpUS+Z5hH pifI7mF/LryV5PZ21KcCnq37f+ygH2Uu+yrhL0aKIPlIwRir5udOYBCAfBOg /uY8/OPIKMum2QIivrO+TOFGR3YlMMEj8J/96ZpuTksL9JUkAlA7YT1NSLh0 WnBcCPGyduE/TLs7LE6NfmSZtgC2SCVubl5KB5ziiiiHD5BII9LFJ3XDp33U z108wtmCqBbiJq2X+6OcZxGyL4ui88kL+nhalqn2Qc6PhsFMC29jQxZb0XPE 6ux6S1+v4KnueG5YI4msk0H5T2jvhCyo+OTAkKSy5p6m+nreA1KXOxTedmEA zkND0lSIKMyYFmRqIo5JzG6YmLGeacBq0kkb80rvfgKdYJGfPQeD9PF04vjP h71cajOWrE5B3Mlo5tZsUxkmd2sglpXB3Ps4fIjrm2SPe1KRhCPfrSdre2L4 ufi/X9xvYg4pVA+fHk1VjcOTLj5CeWGjp+lOCVAPkUunWpJDypVXRmDXBiuQ P/aNJ5toh5+MW8o5TN1DFOmu952H+yurXWATcBkSyZXBfwfJY814BtQUy35w W+iPimiWDwywtwgPelHbW/ysHIwU6y3C0nmqHve0dESo+rbTmuwbl3dzqh4F wtSlymQ9E2oIDDR+RlLnLjsGwmxidGhLJbzKP2oLRf5DSqY/DH1whwPpCDf0 q276k89u76z+hW1KSVBRKb6cDOIwEBFq8tahc0xGeeDnGfwrygfAJJxo3iMm ejc0lP7smhuPCpGEHq5ly5JKQFJ0QFhM+5ecnHfAzvQ/wEhq538WlPlRIYJ5 oMjQAcI3t59w0uKVPrJRgTTBLyCx2xNjpMvAZ4Tw2dvZsZN96/Brwi8BcApk npnHnNF7XlCbd/KvYg2G8k7rLCPGkC1TRDi6HimvVDSHaz7+SH8zuwKX3Jrg vLpMHg0BFEnDcwropHOMat1HeWa2wD/v+U9Y94BRidygnpoYnCpF5sKTV/tI bPu6ql1zZ7Dre/LLqAOflBZaZYnuSkseYn36lW5VGvbteHlhMZygx+9A5xQ4 UowjULj6uAyfPGRRsKxcnzBCfuDF19iWZvJQlAgI/79RwodjnOyNZVzoTpV6 m+14vJvJl4ITlO3pUOXVfE+3z6mpm9CgMlSAwE80F7frg5t/fMrIiFi7T+K/ d2mUFaOE5yFvUynspcivvzv6vFVbFtCrvPg7GoG7y2ybEsn/JOnsOu+rt5uN YOsDo7A64GNJaIvRTU5CgjAF+CiMr7/HFwUvDmZ8v5xYtYCxRnbMh+ZsygC8 T2/6UuNIuFwVVC+Zmjav6iimiqYwVfpVt+Ces9HvF1TzVP7dFBxfnK7Y75hv SNygFaKEktglS9CY0OJdEtRvZP2kiMnqGodfTi5E7gz6+aslypngvzGUfEjI UJp9wf3OHze+iQ8msHw95BHITXW3k5qzc1ynCCaED1qjZF+2OBhq+7GSrRj/ IpimJe2bvUm8D2BuKt16rka1QqtyNVD5N417ojH0sC4ofj6ws0RLhwJveiPR +oww/21KdPjJYKr0yStqR+Fbh19osUTIGKtHX+vunl9IHOTMpwO65tO/C1x8 y70JTlMJ9h3O7jqa9zBhXVgWAy0Ta8PKiilD3zMScxNbctsCUkLLVLcG7ujD CRMYX1crxJeSPrXj/cAWQjZwkuIOpqiI5hgTgBemfmLRCEW0wpD1XGutMOTg JS2DSI6Kpu5hB5PPDr3PBETb57shITcK3yJ8IcHhfRXe/SjGxKreg6QSnzOp lYI5Z5ZNv2GHEN8/Q0gWshC45+CqvCZkmNJyZbypNL/XHHnhvIi+/++ij0uW jsv8qA93rn5CXsMQ+llyH0Ijzzv0o3OPk3xyTjFXN6zUJ8GHrM6fbsAgfw4Q nXN8zR9OutBk228xBixSUmtTkCCZ01rsn8r1qFMyc5Lqg5H/9hJmQUYTksGD CobuVyM0KFcvLZwvPTKWX5rPqy+inhkhf1GGpmRBapLZDLFI0ubGnzJHddxG LLWJg2qFFyLGr/VY2rMQggPYB2wLmJAN/AI5fEoegZmwR2rNGCMjE/P3xRvR 5x4x/tlHSD/0CNSnmsKvAjlz9v3RRRthu+S005WHt5LLCAxPUFSSZ4Ks+0FJ fEEJ8Jcw9sfXNhUsu8svsF0jWie8QDfx+pvRrosasPdy4/3rmOX4q42eayao 75qRPKWz3bKzazXRw+bxSdqC8RSgkCAedAqHM22MwYg9tlJp84YXjFaOEiiU HN5/n8m4XsQy7vscxHiErZFmgKfovS9gk55bgsj87AtAmUpEAkzgB44EHUR4 qEtqw7cVrI0THQM/ThqVSYVjeOrqx9T6q1DacxyZFsRlSZuXCOf042r0fECP Q1P2RgZbp31rVUlXkdi22CGyWMrQopPrQ05vu1Vccg5jIhYucr6Gk/tpxZWp sNkIcEoYjnR+3iU/+2lSp5Xn/UfjMmcz44YrYUoCh+4cwgu/vPCmwF7aYEjP 7vgfaRwte6I7gnFFASJrMzfMblaIs68veVY8tp5C1Mb4756+tG/K4wTmqn8l JJaOI7LvKvnvr7IG+2fNzEGIFf/uS/bikFyAb0ufaJq81bzH3AyQ03sneLCu rJeevzs3jDGj+F6KtByCt5NFWGLyaEW22GdDWOK7WpwTN2xJGco03wsMmVpA jX8mQCV4sCIe+a9akQpKi8d/i2ROdG4Z4CYWs7caUQAEWop4q5pC9iQTwlcB XrRZsFozgZ3HBZostdSgz64dyTfxypsMkUS4VJpuhiRSdw2bUdqd8Wkc0/Rb pmlQ8fuy4fu64CZMs9G71YbcynZcEoYuWlTKyczV16ZcR66EnohTiorld/4T ocMifxgBdGDgZT6vI7XGwXrxQKFkgqznvqyEdo+Cr6ssnyWzMqhmgN/79TYY afNM5lZ2qf8iVExnI3LfX7ZGPlxd9lO3TOG9bImEKaTg8uHuY1pzEKSyf0Nv qj1ECtX7KBPAuhwCxvvShUlrZFb45AhYmcMe7exUhsyHFOhku2ee47h572ej KZDotWL6sa6P/YCUfJpfpqGXJPqX1lnuz7b6jEKSfL+XJ75hZDZVzyyCCGmK 1ngg23nSsFCYs12kB9eQtClEyWiHl7a1h09mn2Py+rhLQsSWzc23k+tPY/Ry M42iRaiYWhLKxGmUi8iTmUEiRUxPBJoAV2tEnIchlms6wu510Dd3iDcg98PV PvdaHB3q0v6iPF04VhM8zLyUzsecjqmMFe3AoHA7tb3bC6Wl6B6ppZJQeL8U dwOLzcett8mKtPQB2mDAmn68zts1wPBsgGic/IRowEgkOaiyE4dxnAhdtBeC mxNgnCjJR1i69WaGkoUekIVjIMYQJmDq1/9u+GhDkLRJJFgZp19DmveSF0ZU Z0D6rfZPdAbIcEDwci/776fuZj9nsX9HUqcz7Pu8E9nnI7LKJqyGS6SYQ4Vk H0hB8ANl+FtPEngtuLSyF+ru71pOssoq4lrH/9OEDFybk5AyqmHpWUeorbNr U+C2sSCEGUBVm27lMIYHrp5YezPZKWo6vpwikw51x3UFHFjVHfiXjZmdFozv sMGYicjCsmKij7RLV0KYI8PQlJvQCI74SifFssOwZfgPCHGmEGDaB2qAL72z OtougocWr8FFgiiV7BZWF3Zfllr8YLTggAIJrlWSjAL2Ju/tcry8gON9s5zS qWcR6MA3v6QSIrz+dS2xJOKvM1f/78HuaVJpLBoIqL7bS0vGybnpYaJeOWX+ /DkOHqTCv2df3ObHnu/eepa3T63QWsc9nvBt7pC2O0D4+F2zROLQth9CaOuB qIxCin6J4BdP4vuASEmCoBfdy4u47pqEvMUceSOnL7XQTlLc5rh2QN7V+oJE OzZWkqPzAww0aomUsPzKUpCfjwWwARDyg17kW40q0xJGnLFzFg1EGeGun8cK /UwN9QTYiNrFbCvEOFc9EjDuJ6hb6QWRfo5aBb8eh708QGb2fmvZRCcmCVz+ jlkMjXU5GxS+NaVDtsp19BrmCY0zKBd7XrI8BETzspmaC+/Km5LqB7N8icqS ceh/zOOv/1zzqZdxj0ncp+8Ud42Xcr9vaN+HSnOPlj+S7WVeK1QAHoia3Ubp Vfp6uQIeIuHqhR0qHroC48o14vlqBx64qnvAtu3sXPDlMKT9gnn5n05VA9Tx e9Gqbblaf7oDHlP4PtE1xke6AuJ6TH/yevrapAsgYE/NKoDsv2avu5YJNlVY IJDb4Zis33OxQyfKPu078l/Xa9pslMPeN0YIdCuDv6BvW1+JYMfQiXMKbKeT qGXA8LG46JfTrbcIjlhmP/OfG2BlZI+YDNPebT6imLaSLqCa67LKTrisin83 zdQ0cLvewwtU9qL3WoFMJTg2sMLxin43tSCr5IH2+2o/ya+ehWELgWs5oFZH uLIteOLUOCZ5spfPfK4wE/lualyTiBpAVp2s+x8ZpLra1Z5Nw3d9Ck5DDnQf c0TTaOpVgo+7+gg06tpTlyP/Kv5+Bl/fIebn60sKfSrAOhDT6vm6Y5GTYXuW guQ/znZ5iVtz8+eC3Bo4oSUzokUiuq5uH9Nvm0Jq48FuLYulmAwJsvQWSLye 0YdShxFfamgmnWa/fn6ufOuztnCpeSCakh8cj74XdyQCCA7v7UsGoCdA98Kv rn+OgEbQVGjPazD+MrTiEDOwpmplAzIg0HrzKXEJtOpuiGi5uxgO997N1Wu7 otlHYtVjbzkUWFWMSofHxI+EnUyCnVaGRaJ2LV1kfrayXph0/6hquHuicaRI I6tfVm+4MO4IT7amljPwQrGAwZ/ugt/XLTCFcDwkE6OFlem+0E++3XOPokC2 Q86YNz0Fgem54H+KbIR7TPqCypIGiG/a9vjbTqtpzV9a60tJarn4LyrO++tl dT6SxtfSRnNzjfriPDKCcFPau0fatW7Fr77ZPyganF8xmMBGOnqVuQWt65iG evbREXX3CtI/inAJ/trmKM5IruZrC85dRBljwBaWHVvn5dpGuUuPB9e1bFnL oQm1Y+Hdl/RH17w4hdvG7z9CKw3tXvNrQ0uY1TnwSe7xBdkp0im/l2IHt2OP 7PRGWaC58m3NtLvy34poC7ZSG7dMaGmdmuPOrvz8xna2XnII4FvEggnypnxi 5BjhZ8Ng5cEifZv/PMFiJvk67l7T9qIWtbrHKtIH1oSvKz/SU2nFxlRmZD7y bUSeRu6U8hl+cocNdPAP71mn/8NyDpYYvykZQI8pLJLGeUByz+BknGuuzIb8 DrWLLDC8ILa/vZN9QHKMCB0zma0+1z9gAKcPtMYFlJ0YBlVpmI7Q56QbodcT KfHvgBeDiUesRhvXbl5le9c2p326V8rDkBhwMi92gFGLs170AWdCMnZ3xY1G 8ZjRyT4oK7fPh9KmTM5C5a0KilICHv4mjDTcLFy6qyqeevLVZRGeJw0AFdtS g7mbo1jOUENmLvpoijYoEzHXXkMFnZ+oLR18+1QN5pWVymHZucZi1ot1zFJm SjtUHOthkvKe+NfF4Z5LJU0GWJfy2ZldVFzlnq1NF52eSHX4xA7Vh1jjZghp lcBBliu4sQQIyd1CbKCHnUojD5bcMHHPNLIzWhY7zevicvgNYB+1umNYiIou ZJUPIozpObiBr32jFREJ0ATdfrLkFwwWhplQ+SGGsA5CqfusWHdMsburvuKI MyODsugrKZ5TA7sD43mThujUwn1AfxKmsvVoSl5Tr+xdughGtPC3/vlcu1nM luzKrBWpHNJO53afrVV3nE6qITCWLliCYK+wFZYK9OrCJhNUq3QuquLcDl0J JQjxGVApzgXSrR6Zs87i2uByX0nnarCjiSk7U0DwARdT0lkcKFUNn8uTfbfl 5vj8lPy2Pcp763JHCsX3Zf5bO0xHHVJlpAcmHh3v6MyA8ndBQyNkUstjboC7 SHeqUsom8NsbeSvsFEq1ellj15OOjwmO/ScxI1wm2eZoPtI9vWU+vHSXAn4T M5vPgiXgaFSiTJs55tJfCxyWZeenbLTqfNCFiTy0AIokt6mkpkTM9opCuwj3 1KecQpVst5rMqtTQaE+CoDvOykjszPeOBFNnIbMYMzfhSR0pXsn4p+1bncvk u0lXNVBUyc4Sh9WNedw8NIT7l3y/uolAIxUul2QfPzCfR2a8xK7VJQz0uAum mCz39WGA5z2ltlp32ZTjEwAN+ltdhV7/70p4bKH9m/dmnAUR2aL5xGRsOrnQ WvcULykrVUvVewkFf4XzD0dg/anwCw9LwyVFJxxBV9pq10Ufw5VorHT2Zbf2 2GeK6RYdYe1CxxUUvwpRdwV+7oUzG2dsdlXiVVr1IV+Da8m8XtGIYzwSdm/Z VBwHdzyQn0aKn/seIWcn56AitwcRPkeH53Fe9nqpkkxHhE8w5tEbo345XnZF if0TqNeRRUgpvzGzTEL5HJuKvbscUtg2NILjDG++0tp/YzzyRUJIFRnwKGg+ qbpaeJnnSodsqm6KV5tuuJff+pj0u50reM+SXww+12OEZSOKmuI8M7F8ytAv qXsgx3TyFtby9A+T/50oynHOHf20q1bacVI71jDobeuj2w6+IgsfTJAqJMPP OoImcxxND4FMMnDghp/egtYy9ivEEEBmkLfsRK+ovwfcxtc77iK1O1xgx5+v +DrwjWaou1GzggJM7xFwUCFEZJS3cn2KUDf0j2mX/qxc1G5ZhdnZomB2rJMM syweqh1rK34Or0Z5np7BnQ+SaUwpXv7E47/KhHNZYk98gPmfnpFcjjOGrZiu ft6nMhKCVj7Gc2lj3j8gF+pwz9ZxrTVQqpbknX0TsPvvI5DrU7sU6/6umedk XtN5RskLm5i9n3Kynv+n+ucTYpSGWrBSqHSZdeKBwkQ7qk5NcISNq9Zngr2r JfvQXuNHNEYjiZSNdoBoC1SLacWESX5TmqNbc36yClHvJ5UZwX3Wjj4Ijn8C slCoyvWAHOq6lysuauZ6UuFoGevLRlKW2hRjbzqrC4ZgxJbdsyx8onzWlP3G fb5yjs+pd/d8xnbNK4FADULvyqDrxpjfCsX7bldKrmvw8xdSLCdGObBZj9q3 Y3ifyq/Bv5vKhn9VbGjVA9hWAgmaPy9x4yuaVeGInyKSodzX5stLM+1bE1rX KePJa/A/v2tliAdP1sltFg/q5Hi3v4RfrrMe+UJ5rkNCM/emrx3xRh8JYAX/ GrG8B4wDFhv7CxYBMOMs9cK/sazAAX6v5993jlxb0gSRGZdN7MD2c4imqwiS BbsJguFe62cIj0tumS1WAru2biutloSPC0qTS18GY+p2WyYikQxwqS/tpSo/ 61FoR3GvTjj2tMz/TEua1q58JtNZRfqHYB2DLm8Fig9RShRz9VjUZE6t3n6W J8dzC1wWYWA/DMKBzCdX1p5Csh/yihMz0/WbkesIpYiDQ8PsupJLr/lmbJvh QSWmClcY65GHTmKGzV1Hg56PWAFhWMWOw7vrRxSoDeBp7AKiamZFcJN25k1n mqduSqpyR1Rcp+x5v7EiIy6iSLGV7q53C45oriezVAiRp4Rv6tCfvOYfV7SO bO067ZKQ7bIKfogrPmDvHo72/0Mlmm/fzQuckREmIKOeoFjRfKdv0qFTOmBH Br+5h76Sv17me1d6426cfOtYlGUFoVoiAHURAWNzrqFH/HfLBvnNukbn553W +IdI7KZja6u2RzrA9u/+vnr8uzodhFKRnmeQg43WbpKgeLeP+FRi3JS0qIQA 1BOuXA6/sC+i3lgPlGSYh62MRu0GDeiaQYCFnY2dhxvK5q9KI3iIW8yQsH4y 8I8Kq+Rl/3ofwK4dCI29JGZvxmv4VroP/ZzvL6ApMmYdY+ywnDwxppBtlvDy CP27CwxuiC9lf3xNrtwJ+/Hz+S+xP6PruYkucuw8zJuv9qytnw/RuGrI3kle p5gJHBdUs9AnZOTrR7ecY8hkhLjoNMCnrj2DuOhlm32zvIwJmoS+/hHRIA/6 fMEvtKz0NIVrTLdU2gw/tuNKoVgknt/Fr8DF88cG3kiioMMQshDngrwTAtB7 P8N7u6ago6KMfHb8fJIvFE8c09zvX/iWnpOQwbjQtNzW1NZQ6nhbqjwXlmwv s10U7Basx9Z2Eetl5DuR3F8Rr3Wf3bTfpZ13La/d18TGxeqdDjz7flr7Z1Pz hkS7G2D9E2N4VTFmaOyvzvdiD/foc7s4jqiUQMSY7E+zsJdbQA+Pl3Iivpxj R2ZyjpYKznvYwKeunVvzrWQgYNIAG7Ig4Ri+on1N9lrA5k7q0JCDytOa2/5B dGCAImpyI/nnJtRWxZOE3ADKdniWoGD1yYCerL0QOquPf/dNoKKiPBYSkBLO xHrIBhZH9t66OsxmNuehB8ekrsrrm4Ek0wQMhJdiYyCbFOeDvBMD83w8UKj/ YGATuEoRdL/YTC2gsoA/FgOBVdH2CAfRuvvVbq+/0//KZ1px+5hgj4MoAjOi +igfv3t4deM4UTPQ4DPXd1M7fGWOd/cmY/6qkkX4nHfDWLNs275bt9Tr9pZx jaWRdrsYNVVPcAOI6KiMsp4iiExYQJhMaoecgkn5voFUABy4QCQzFtvCBBJU LqCQga6CvSTit9KYk+BPryqD1e5rGjesyJ7hYD/Gp3eUDM43+KpwjzMGwg2T lZKn6JTq0HVvkye2WnR9Wmn/T3sbzyNQF6Kb5a+gLKqInDCxFUxZtTY+VhdE 9/+FAKtS/FAvN7YzMwD2Bjhbx9PHSA3TZ67adOzK9YdKFB6DwAPSivufqyZb Cl5jDku/ClJoP05akyNCfzm6K+lnFiLw+u16pkTbpu60PlDHsxao4vk4/25D HJt8ArwiDWQwhIRkvvuRtad+1tmLZFBq350PRSs62OD1Hq93lmhcxAdPyuuz IowgDuooXoMXvH4fwp64emCTqPeqWRcEYuPJ1l45XevrJ4nZY7zq4CMCT3tJ PyMl8Jj82BBgj2Fx9zs0LPPLEJersL6eqrOMFrZRP/e+u4sfNJbagj+wLyM3 gbHvh8KDahsP7Zerizij9fC6K8deIzpLM1Bz5QgFAH8SY68sTzb8HX1Ol+PB AO3y74EwW+9ns4pq1tDORE6AZ+LbhB+TTkBq/Zz6QNkWG2ByCiO0DqiBLbGf 2inoNZLSFhiX1hwDpLQ+DL+jJf/qbcSkHIO9H5NzZjE70wW5vd6eel5VeXwV TbQSHIe5QfLWKWpY+BboHP4QqTRffh+dS4+008Z6u5th32/H05gqflzXhu8I +WPYtnfflA1EODCMgINor4zlEIBNpoI1AQ/M35Az4KSYZcyFq9J9yethZ6VC hZeKSFwFTSD/jUs/EfT9YODSoR/5kZ4EuzTtgY1o7JRoogjjVcOyKPCVmzuQ 9P1ne/n0lmKkUA1+CKk9LbG0tNlkh7VT4Vv7M7IEQ12jEDrV4bi/WdB59aD5 CIy/op2QkaT3rS0UV2rMeWWw3E3mW3hQqY8qYvX5UVv/t359ol/RdHMKcguv WVicaTUPwpWHf2fGeDtSTUl3NyjEfxm8h0dz7xknAkM8Xtp/w21LsfdQ6yCP wPAKOzIxf0oNTbpKYpqLW8tk6VCGnKXCfvquVdm5I7+9d/R+UfLzy1qXyrUN DjGztEeP4ghCoG6sNae2OAErswoY2XaGsTq6Hn8LMATTMEAcwrZzsouANMJc crG/5FA8r4AreMC08cCwwCdXtFKvtWi4IOv+tv6GdkLgaUOyopgVnH1hCEzG oz6rfcdqq9gAPdCwat4uiup0clhYA7WJjWO2itdyMUoFr4mU0qQByaq6AiBG RQvhpYAr7KK4d4z2L0VZ8g9k4oue2D9MLz3WDGMJnqMupVqFk4dIEKMS65h/ +mhEQqMYoo65n49HZ6gt6Zuwq9Wi09zHT4ESa1/Uk0osO+q/QUJ3QAh/nvHL 29gDyKZoYOr40/937/4MB0Kvicn8k4XF6nQwTZeLw9I516GZsFu4Zy7WbX6T VFn//axxTy+SweVHR1ZYWZTON6svYLcJGVFaXwdXhvccw6WUvwFinPKY4ZOF F94g7pxVmCei4ixFSqAKuueeStoUPq9kH2FIfY6r0paWhyMONj7YEFsNfr/+ oUVzIXsHC3vPNDpu0zkrBn+xbnVR7EZc1IPMNrAepJAR1Eff4pYmxBYqCo9D QVrR/34H2o/fxn6atpqvLas8InP/Or1z5LwDB7VYoKrHIOOmfV8rmYfv5KSA k8Jj51GzG0FNcgThIicGPmafHiBgXzRATjoXRYcoIaAxTHeA+5020ywbPyKM JusPagN4+MsCoJ8AVp8WtaV3vJ+dMjeCoaj5oA+aP5/KGKVUXZpCd6CKZ29r cHeChLGeQanYnk58v1g+UTJh2vVahq4JUHJ9tbuVWtQF0sgftCCuHPgO+7TU g5cTueM4eDyan/qslJ2duktPFVoMIu1rkSWIu2oKEK69A+J93cgEcX/d5ZqO SC9bde+SX9hneyO/Cu5nBKWP3btvC1gDcvNO4hn1pBNDm5lC2LkyvyMQaC99 sVxQS/2cWNgoDC/cV+dAs7/omJuNr7GxvBi4AlvJfdPpIY6FvV6L7+JRrAWz 8GpBUPNEZr7YlX5o6t6zkdBzZyS/M4ezC5duZmeKND9Y48IObRDLm4ALtqbD Dm0rUBtYDSyYRKT/ooONwlxnrTvY/yZnfmEMYV//zYN5VPlRSU0/yNVcBbDN /w6WXxTd3P2zPbTNK+TrgES7QAuRnZGXJ1FzrX2jfrD4Etzer52Fr0HoXwUH MEd4WGJ2D3COVFl91ZpDjwAci5RnF52FGu2+Ah25VahZEIUyCPNzFKXhaLGd 3vB9hn6358z6SLprfE+XvfjEIKXv7OKGT5hXrWou8H5KB7O8f7QrLk/QvoyZ kXyhdFRBRFIAgqMFE6XM1TP8R7gL0CY+oI+7undKDugwcX+ha4iFY4KyPFYu 4mN+WkJOcHVnZm7zRatOfCIwK7MjLVYtzFcMhE5a9koSiz02CmkkXg1sCiHq 8xZ6f1ViUBNCFsEH9ycKVUssDRpmd5x2Qpr8Zt1Wa2Ta08sXrm+gm6wcDwzU Nt8Cl74n8wlmkICacCA77GwtUlSQYp/4eaPjhC2726dvyfAufZLi3oK8iopv K/9so82vXiixbuC54Dx/5kD0+xxNKvPVyxaj7Nf+rE/SpDjlqLUkqobstW/H rb/SGtwoY1C7P/Fq7nuAWETivNFWm0grp1viiY+KCDeyoJpTiI+Xhqfy9uDP 8ATCR06b5y1QiYg7rMZviJxRBY5Qa2Rn3mTQMQIYwMAff4evkOKJnj2KPJWA MNPFwBoUhLMXpriPJibEk7MXnrO/3FZG/1qyJkwkjJzkhBA2plNv3v5875OO nO+j7pTurKGcllygMIKgs3dKE2LvImQH44qE7cBIa7w9SEtDx7d0jKL8koCX fKAVvJVUA9eSBeZgBoC8ezz4ueL4DCfTOLAt45NeEtJKdkf6b79F07vAT1yE vdDFTjBOVXk3IgePC0PTNytwY34Hyp/abTSwnY85loP2ghcBfB8YfOa0FxcD BxJKnnZu1l7t+O1SKk+YBtM7xu1UdWe12ZgeqG/4dhE5rloYT09K1Evg2Jzs dJxe8ym1je7DhZ4/1nZ33wa8jhmMQ/ek8HNKEnrMRg3VRXK7Ir2rLpX9jZEO Gfb3iaFOadmiLxvYMqcvuXXdYyxzGGTflyuYV6VDsK9w/z7VN7smTQCQsbSG 7zpuXfJyf1cPfpSeb4/z/y5j3IdyzMuDS7tIrAljXkpdqmenWnRCeGH/Q/pe boBEvDZnurfTfnA8U0FL3UUymr5bRxBTiVBFy7Rr/02z2C/zJtHLZmmEIHdc NyHJpKwMk2rn1g+TwZdzHDu5LWLPao6fHVhG6/RoDaUWHzxemYe3Riu/pY8S jRujdq5aD/+H7ygNWLTUFDr/ZD6vE+AGIRSOoxTwziWrxfixEU2ytNKJwK6R WJxDh4BbpXy5UCwIpfx/DTOoHqM6wBXZH7eNMhdf4KisN8EHzIi4q2j+Fj7j 0dZO8bDDRnmhJtqhhW7TitAMf3dp5lRq/KIpGFTHOBWGhFSY/R+FoXPKgbxK Z9dGDIqan05LBfccgvvFhw1Uk83Ohgt3MOIfU4Jzi/hCWsMicyC2X4OZMDNh qy5AdP9QAx+nYWzrDcyjYL6Zsg1+m8tDXezIKpAQo4gbX/GsRKX1KICyHUYJ rN1kecek0g1Ovk8nvPKTIHuMU80jZB3oLgjOoBKApOV6vpQwwH1espR+KWcW 2Vklaa/UeyVVV7y55d1ecd0nbpjPRQGiW0jnfEuXbk0/lC8+o0hom3z2hySi CP7wH6EHkTOTTp42Ix5tHF97Ek+K6ST+HPT7RmKUQSqiFfuNr95raipEK2iV RwaRvqb4mbtAS0iKHauvZvj+KLTuYQ8nRvVXWMqWx/jDWLQN7nPmuP9Dr5xf iK+pTkPu/o4Wlrxg7BS6MfAGrXJPBz1rbKpY6HKavvOfL43ZGdNyvpRUmbdM NTFVlXvFhO0vxgYEg0txTLoGIFfMqXrIZSGesJgnnRLsTxSWCcr5kXOM15hW rtKmzi4//sLoRz1+ySyAclWLfBtRoUUAo1dEJVtcrSA4EdKQT+j8nS/gtL6/ DpKfZpQAqAzsyqZY7qakoWyqa4eGbIC/Ydjumz2cpISgYHNSbr0+2qe3GoJE g2PrElTigCCyjbMkisKts8nmgoZZyrtWYC6iYWNvDMhkBiKboL0lM/U2RY2G BM2hsT+MAaALqyp9v4O/5ekOe0rOhW2QSzdJbcdXMqgFf+BB+moHtI/OL91X iJfCIXVmbkwS4WBfNXa/bGpRGswEfRwzOjiHiv+o/0DmrAZhEhfxO3pCo6yi /Cf6w2fGwPt7tRlgjBUvTm66qalfQZetMSFzSQJwOGJw89fvAlrMS5QMrh+X rJwvcyAq4A+HsD5YXBaL55DPc49oHwl2BW+2St5a8AXv8a/+iCRoqFwU+xKX x5juJZNbZlJupUZeXak96GrQ48bHWqFac/g/0llxZ/Gepw3Y/9FRMCoBHCbx o7Og/gotcgTqU2AfDyWJ0Q4PUUp/OL5DW1+gpA9eFIJaINnqVdOJNWChNiyB O6T5X15MrwHx+08UUch0Kj/sV94pfrl2Ubxad66097oAkPuXS7u2Rx3Ac/pO vjLjpfBa2x/9o4+vf6Pm6+B8BfeQQ3phDqsxK3rrZI9n7/hUGJt2rrUv4JkO K2d8Ix24FzKBfPuvFUzXdOVPyS/hpse/2cy+Sv+D2W+rKb92rRRIDmCsEado 1wQISxkKpIaq2wZqEdj1nB2HaKbSG48Av4oOtj/wzW3an16uhZTf3BZ5dYwr XtWUjyGzGdUHhpeqyK8tatmd1zQSs67CtrhdBbW9fMGJmE93TZYLDTsyrlXx P+gfDorKdoVz3SridYV8dXqxVfdjPR1wdAwX1GkJNvn147/ySilZNSSzxdlk UpKd8EuIkAwYCV1xYJycnWxCGjozkayt7E8dmu0FO0dmhYEERmt6OO/ibGpR X4JOp8xzyfg8l9fthmFMFwtr6NW1+SvmU1W9XdiAnJwvLojKtEDaVufgl32h PzFogd5mpf2eckzgLK5ADMBhnO01YuyBJNGZhZxoncxrr34isSg2mOeuRitq WHJhcW8whBpA34FWX4/Ad84M4YAr906LFLAa1P0/+K4HrKOWaaGgKNvgsFjY ZS6Kc50yxxrw+0bcJyeDT1nVnDOwXt04YPa0bfuszn93ljSV2l14Qu/H9H5G JiN0tlawFMJfl5JnNas5/ZprYP//WfiyJzQzTP6f5CdXDk+jnAxw6wmdZl6h tiyFHp8eLNVh4qTj+/S3KhthWO57FffS1bN1R/fwpZgRs6TiIzYwJRrJmJlS zJayY2vLhEQeYZ21BgocDuVLtEoW0GMZIYJaqbwOt/GDj5aWAS36CxSij3uD HVsHRtpoCuMUuYK9icr38IJND65JO6G8pOs1nqy/P6pLH0MZLMNmRtl7RRq/ tm9VHaG+y15wVcYCeqAI33Sd4AzjMz6RnJLOIs9kzIHpqBZhFJXORq9MKbGJ rM2weLMeqms51TSzIB1NuZ84WHQRhYeHdHAQ3oL6neuewehftEijKyNg8aaz H7fOf5kN8fwW4E5Yt9ehU3nEFZ4blq8HxTc2WePCW5CZpPe6Ok9ZYK/MpIFq +zlsd+uEhRCbmhPjeltbkzyYqOXsHWLPggAErocoh2+z4vEnY4k7FiPuIVYd BoFASVeXtU6umKWajqdMcv9q+zgKepLdagZPx4u9idYlP4HFBPHDQ/uenvzA afjzCxS+oL5MjTwAg9Pfmuw/bnIA3BZ2rXVFWcoXMnpyKJ5ogsgPaWtPUcgP bcPCZNCWXFCGXFBoFpCZ372Vpl/Q+HAsE8sjvFaAIsvUa4VhApmMQz0DTnrj g9+PQsK0D7Z3D9P1LeiI2k3LjuwGFUk3acZ3BfG9cF66hj6QVacxViQ01Px/ qn6HPHJusUhM8/C7g69lLRI1ozb2SC+h8EvriXcWbtdjvhrZ2u4UigegQNGn psxmNE5vpv7uYneW3wgFlLysKl91txB+WBEVG4TeJa1HADwrtoewlysfUYl6 8r//ukbD0rVoWmC4/pJqVkdEeAleEIeMb99rar6ykJdXDcsFBubJ3OTiIEWB XPkz2jnLu6Inf/Bzjy/y8fuP2FRlrwST2m8XC4w/cbzsYJ9clSsTCs73+lut nYJM9JfYmf4eGE6DzZ8T/KqxAuN/nN0jGan3TTbGpJ4Cf29zQKpqeTKhqABi NAqpB4bNZK5YJkzRLbLJrwh1LoC+NqVpTu9uDU6tfpJbgr6vbCl3Eq+ePEVp fNJ6ce2e0h2CWNIkyTUxsr2vsLdOl9g/8DAyoJ3x17a62Jn2YU/tZIvg+ZC0 hxxks+b5OmrzK28SVyu3xDSEQrsioK8/lECnEJNPJoLVC6x0eDC2noCVUcgn ULy3YhFPGEcakbXM82Rs+Qu0iYkZMb1Ii7gjvoVlPrOVDnY0dIwbcquAXzB+ O26DVeR46mV5qORa/jzHWrTm8WrObWdANlqA929DyKUJb0brBHLqUJX/PZgn mMmaJmObApyU18BBtuKrHT6fKPaEiimSmwPrZ3zyjHST9qYDA51ZokN6Cza+ gP/tY66ePipggJu1ng5TNBuakPx2xZ/jD/I8vBo71+TBWhTgSUqvseMmPr8b zmrpXOK4yK9ADeS5+lOQRlvXgHISqF6ykPH/joCm7SXwehNW2Q+YHGRVJ6a/ h0hQCi2PkwMwWvMDrB09xAUmMZSrRKWwMJCFhJjw7czHzum4xHUyyhogvSfz r7Z/9zFH7THfpgFRelKYz60N/RUhJVTp/iJxHQNh3zeBA4V0mkHH1HrtIs3O fX6Ynyl9qY9HcFiMb9E/w7jqT7k7rkvsk2kUcVNYO4Zq7YdLKWe0xLyeop5e JD7wxHpvekuOVQ8UAws9B6LM+D4OdJtyQ7WYtZrK/MSfVUvDjyGmKI4LgPCR aPDipONpY4oQ80Rk8qoIHnaCcvdcbWikoR40lRzemQeDh1jJUiiFPtmWkB71 hNP6tPhKTJkDg/g4AzruJ7N4CoeROGMKcfieo46ljGSSx5BN+2tsXlamOnwG nKi6RrtMdXOpVguKxtaeT49VGSMVbo82snGhmVpO8Ea/kJz4Sm8utlFEXjLy Pq2TLn4Kqm5ZdlBgHPCOrPhiCNGucwhWsZMXjHZXysyybGz6TmqsH/Groua0 zrJ+xBxhrX8TbWR/06aOPVs7h4twI5hHW9aDyyKwq3ApBs3mrHNBufvKQbEF v7ujTegrRPiwA+CYoh0y9qjekXxTdPmaOTBzdc+oZp7OmGl//65Smgcfr1mS zCElBhIN8rV1r3/g5g227ZfHYfNI9FlS2q0odhm3bZiK8S1p8bIdNbhYb7mD t/lPd/rdIoUbn6Oh/rRkfUKmauycm47guutx1+muvsjK79KzSlaMDq6+T4wx 5yu0Q1nhTEtC9JcYIEvAox9Idlk0OreY7mGX3gBAhDx3swHAMxuDsxwzFAi7 gncSUOZWc69kqgx8s8l/s3a/w53MVd+KCMYNq8Ucs8o4o0IA1GK2TEYYl31O dWkiQWkc8czqCnVdgO2ezdPxW8Sm3ZieHYW/iztiVFjipgSiUNtI9Vgc6Dwv p3V0pBUwhEVwfK6SskSa1xErqTOp3ZUXZPFBWWE4iwtFMbLIX3AhSQrs42BK H9bF7uYM906UrP28OqwgEOaTipOrRJCs/qZLk73v5AjvEw6g539xhr/TqVs+ DIZ0rnfJmLe1TZzzfC9iABwElreQLnc0hMSqM5OEde8k2/RoPgEHX5sPjbBn a/+0tGVr8KE+/7GUFM4qS5mqYA3GNF++26OCGo+wdmlAts54EQ50laX3ahpa 4UZb6+XS/kqcW0BGWzH6Rm3cUGevjSjW9m5HSbxbDea8GKybSX2ZpKzY85Sb V7NOTXGUL4/3s3LTIJlabP2eM44nY1iXKppNYelu9XqCPPdmAgxeN2EKYWqU Rrz0Nlq1fH53iJCGKvkycXJYKlhi0lnwHM7/DvxehGS/63AXI62Okvn203Me d4ehaO6e5DgAIKTxSj/AmqFuajewcmqOFGnDiFma7qCiL0tIvIpeQLf/YpjC 5wCz5ditSFoQG6BDaVAz2icJ0rI9O0Tr7y6wuLt/6LTYRLMyvyOiv+bV8XFG jJ9fkft+HkAqrJsvlCIwe7OU/jHacLbm9pOEGkYmC35r11BbgP5CmNmSZqDU arGiZiyFVGWfT5pfnRUihr+ywWrkeic4vtBaXWZJNvOktrzTfOr+gyfOFUcC 6l3AAExmHJZuE98PF8U3FNKaUBNMNjzT/Y4+IypKpWJT3Ohn3uyxJBW/MExd CJijwarGO7z2CXQTVFaLPh/3rL7ueq6qv1zDoOg6FLyUq4C3SUPgF4yon35U avTpbmXlo/h2Dxb4q0EymGwyKRGWYQxWLcGk7pWJqyWrDRCYiHW7Jm3bC7JQ XE69vJWGfPBqRThjNjJm/LPw2ccOrjap8oRlboS4MwAnmBQLX9adRXgncl3R zboxSLWAzaGDhD2y5r9h39g0e0CAoFosX/5v5/6XD1/7D2aNpr3+joI+2/TH iif/4rB7kswnOfGRaOEy6iCKjzvW6L98QwtXgI8GoPSHkdj3XG/uO44PgJcQ u6cSSbP0kqFrIFoNLbco4JZrDp9meVmdEuhKsvCTv4tNI/ZB1BwtA1CUfwBZ +7eYxwaImvPnoPgcCze0oigQwqPV39i9g+nYtXf0+MwP/JYoqNuFrIC1UyCz hIvHMwGwDx4xnGKDoLw6wD6+hDbhupyZbaTlbS1FKGDsdWkoExo6AyPbnL8s zOckbD5X+xBIFgKxEOe4t2JodgOcLzln6ZdNvrAxVbHDT/unrPOTrm6MPMNg 0lN6yvxkevf/SLJvCDM+UDfJGxdFOAqTfJKDX4b6COMS3Pd8upIe+mS3shuC BXXHdTFD4ezfYcRIUPzve7C32h7qQUcttpuAXoKrwUaPvVkIJuNbt98nr/Ia rZlWFAjLvcb2qaZZkc+1mXbGb31Em447q302ah1cV2eZM/wX/FkVR1S0HOMz 75x6TxS9H+AyC+WyxT5LHxGXZg5fm1jM0va04uBbRbakKJ/sBRbW6jXCVkKr kNsW0KPJG9kXYmjPOr03hkYr7bAvNPHlRq9omIwp9bOM8+T00jiegKOgqZ6e F0a4Ec6Taorc3P5usmMg5pR7t7zQrjyYtPWwXOaQYLLgsE/KrGk8joWEmVdh jpgc5qQ7EZjx9DsRbU5AKHOTyIwf0dJ3PgOuDPkI+U8rrDa7+nRuWiUTaEd5 uyykGwEK9RQW8w63+OyzBKCRdycrapeGrr+3Llf6D+OKdk8vrXXGusphFpbr 8gL0muqRT8TuZjEwEHkTsJY4+IVPnIZ8NTCyn2+38me30RHAneRYkWxJIStB m6mMLv8dg8WLga8AdIM/qlD4jmo+dkmtOF5P4SOi2iav8G5V81p3pFv5m4FZ tCuf8YSYl7x+tTLhVNJM2KSNS7i1mm2CoNuz9qp3+EuMt4LUZAQ24NZd77DQ majQxKC+VJLHJSzrt/KXHjdiVEUpfYPF43xHIaATFnyC3UqgVI8+H1uC22Tu AGCaNrK09jCXCseYpJy4apxrlIaF2+7dGm3yoJK1UT5+nOig7HxdoKqb9bpE 2NQ/BqI8DAcVljXVeEOELiC/nGz4WoBW+bAp+Y+Vfx5/gKrUBrGeswvvYuxM X36QPW2PXcnWauxWp+tGcptsq3NLOpeBIDfQSuas7mdGhb5hisBl/mSfUnP7 bbBmh3+DfyBNNEMIwg3SBtiBJsQ5YiycyePDpmNsp60ium2cb+xnKDKUIOG0 oTXHW9Jny2zGVCiuRLeB9IWY3SR5hPOVf6BeXHCVR4eC4Q0thZYMGDUBULsN C596SfV3RIgkLJ4duJlps2K3o5yyuTrCS+9vlj1E1Bfg+oN8s0Oo+Fvr/J5c b2dOwhReyle2CAxihgYiczHLUn2ohR9SSdvxWtx3EDqEk9Wi8m1uKTg/dgxu AQuWWJ9XJU9JDa46HzZwHEQIWOXWcKzGOrbaWWpFYIYIEBl+nhaJzyeUB5hk ahX/0kkQvSKmtvdVAud3qJZf27/4T5+20kSYZenu+5+nmkEa+hu1RKr833iD h46xg79fPmwecCBw6rdTToicH3BqHFhRJ2wgeOIAACURnySeCl2bwJrAFurW sGcfS7BMTVYLmCe7dK4njyTTHnFvBdSdRNieBC1RrAqTOwhZcDOSs3GcbxNq fzt263zGIQ7sUmZyl3ZrXppqr1rnwSNErcZQKNK7h4GW4POTnp9LvkxDSCro Ynu/q8NEG8u0XiqR664JQgtrI3PMV7Scf5gZl1hEot+E4efq6pTiBLLfk36j WRfwYf6lOAqIr04vvkeXDerIMf1XHDyLQuy0ME/ssrhUGpZ7ZpMDDbGtGU9W /LMueOu5J+6v1BbmMzLDCLV/aVaWn8IRwallJn6y4sPXhOcSOiO37PL+64U8 hljjj/p+dRpirjkkLrETluoKCCJ0nJsnVXzeQlqUvuCbQ4vMfnM+gv5D2pDA XXNP6x12yrguIe6u2y2fHicTDdLLP4KrZC4tGtYtExYS8swC0yufFYYn1J4K 3A7qc4LK85Tk9Yvy3mOr4vbXwvb3wcTz4eayM2bs8wCh7ioOnDBNnu+p/6th 2WFFsuHYaRW162QuoywBd/G97agInJ5f16CeCi1NFRWCnp6eLS2IjWZaBoL+ 24CMOU6Nd8nWWGWlTrr0jklnRsNmUmrteJJv+rn6MpHNlAN1VMvhKVvmC9nd 3yHjC3gdzillPoHNBdutRAvJ46VCyfd5OAnuqWkugf3bgI9SLuoeGjFyGfZd DThanFeyZ67quGsFrjBR3oDKEEZWTdJGC8OeG8q+kFIbvtI8ZYEo64BCGoib vpdP20UV0Po+o6Onoeqg0vr22pDQjoFMz4dWaVehHIBArGJPr054PeOfHV+D U/g+LR3t26TCx6T/xwYDiZqOUS5QcOj6w563FGHHb0mHQiCad3Tqk7GaXH64 8GrPrNvrooafhGjLdg+bUdme/PjWhcL6C9yb8xiw54qsT7uq+5hwPESrtk0Q CKr7GL/GRjugyXpevsSSrgOyhLwaXoT1tVTUXQKgeHrRo2lCRLgVUPtnHi8R qoC9RUexC5gn8OEOhlBRunmS1G9db20KAgL8Cy/7QerVINYtBMD6HCEwfxIX r2YGvD34G8JOPv8AMi71TH8pEOU2QOfHq2y1M9UKM3BaUzcb8i7XTGvlwW4j BuH2s54rWLbxu2P9y/gFUqXag8zYWcCmv9yah2y4tCW/rGm8zSd/4jlzfAAR I0SFMFBL7IY88WeAdOlhZPyVKYAnk66X3G/hGbD71YeJjgR3Cxe276dgq9VC Q/D8t5I/hoysFtPs/upam0uOX2GhDayknuyTtfhScyCiS5ejVVb812Ulc1Jv 0MT2Y+uz93FHlIf/HMtf8zVMrteEnyf+QBkB2bnwCXVAjmiHBysuwPbM/Jbq tV7XuNhOlbqpsBuzmsynZwmkQiFH+PxkHoCirrhoUZuqCk7aBjOd3/epUxgj nl+Kf457fUBZE1d7OibhcVujWRNw57kqfYhR8W8X4bR+mhd/KHrLXS3gpTdi RR8Xn7nXd3wraprFImivHIz85vu6mPocPYPe5NglnO7d24ff20mZvdQCukBI QPG8PLQ53VQIhAShOEi+VZl1qfj/llID2xAem9Fjqqiyrlq8kF2+WbPIYTFq yybqMmmedH4AV3m2rAYR0jUlYifRmTTdzzLJdmfMh2ROcSO9sOjk7FI/bGh6 Cixe8sRC3uJ0zycXTDghb0lAycBD64RyUJ1eVIbMOWDtGhGrycrpITwxhGBQ aE+fTv78HZg/vOR/oNYPXPilD2RLE1St+E3eXVH/ryYsPHP+XVDrwieFTW6Q zgn3uuTWaTwDR4qNsdz25iuEGu+Dnf47Rm5LB1ZCZrW/AqD0Wq+aFnBlspaF rux/SjVTm7JoTOZ7psQA45hff+Wxz3gPdilafjmoMr/P6/c7H1D2mI/9pglI Cowe+sSqqeui/lzd849hl2kuRVvvbQWABxLqV+WlTVlkNry3NiM/q0Y2EYj+ 63WvKgjcQZfPOANO3mP2DDwQsN6qLONFO/aI98PCwKou+JP7QcFhttFmPqqz 0Vqvv2Ys6YKW0aGhkkc2P/pll0GQmtX+2e0bEvq8Gftgt7fUYF9pyVwDqIC0 Knu7lrZKOIWf6LtzqN6x7NqKuXfbQQmr55Lh1syQV8RkQ4WGS/zD0GL18jqX aymPy7Cg1uUwo5n8nOx7MBNDMBZ4FxI0Xc6VLff9t4QtMLvzayFhMp9v4EDr IwiJAwgZPKDTkXwpZ3S7UVmCNxYkDp9HSPeGch9z836e8ye3M1MKgz939wtt Cz+H+xpSCsyrb/IpUgr3+1vbVSpcH65rr2/2C29f2zI3MhKNg8Vg/dX7M3at eEe3SgE5dX9oyP5fCv8Cl01/I6AedrsT+3Iyh7RJkOKY8If672AqCnCSBc+L zEl/rmtve+fPdQAFZGi2ktcTEot8RqqsuOizsoZb/fOEXEuHmdE/47EaMErm 9kNPajzPb3NSZjTLYAXsQe0T4D4TF8P/rI4YY7K/OBXRkk7qwgPCPqaeuPgc 8ftICpRfs8qZJqKo0EjTppCe5Pf7SK9AhnRdWPAazQD188dWvFOOHfEAP5Kr s2DhMLasQOKcivrAuocWA9V4Uu6Y7N/lakwOfuLu6Hq37zzzWva3kW5Wi11Y VHq+h4aSu4Z8VVODLg6w3/uCh/foyKRjT5izsRaa47eUPYcSVEN4d79Qh4b7 dIo73EifoIUY9F6eHIORY3zxs5g2mLVMhD+TwGWBtE8xG5z5qUzcoN1LHt8+ 0vUydFxn7K+5SK71/axLmvNAwmXaJ1ZHZ68MX7NH/3e9RP02QI/VlNgdgp/P 0dYauBJ8WY2JLWTZEAORhfln7imJ+l3ygOfoTJBaDajMBTamrQGCfAuYyzvH dVp3WDqcO5qNl5iwtwylLDzxMfIHerVF5pnmBgOTPkXmIsY95zgTg2qsOzjz //Vo/Ju9rLSlXIEnYSA97pD+1TFPegQ0T92T/RIDbPmatXz3iptTG0Bk4/p8 YXkAfgvPkzL/7V/PdI7FLGIG1UPO+Kya+K7MgK3js2f4yeF+qK6mXZXHSF2A R2meIR1W27z9j+b5n8/igcUGYAmtVWdFJf9wnxaCDb1ASHDczF0CA4iFol8W mZdf+pDUzkS0rSYG+RvKM+Loqajr+dzRM1qsvM3dsArFflqcGO2pA04nf2CP JxLxKA64hvu5TqgNV/nGqT+NkrCO9fiE2miHVLv7d2t4LHCvhLQ/o6GavNKb 9ONuT/m40Ga27PPGFIAlGI1cw4sSvaqwZVuLpMwjwKwyrJgTDrOXw8nj9NQF JO5Pm83vRu9Q+4UkYPaz++Z3xHWpmp6s8L+KTjX+mIdzQthQQApmt8CfQYci CxjWpnXadFZOv9hXdQb44Kj1mMvk357RRX+0PpACuzCq7d+xnlRJjmujd020 b9EHL7orfh3qKEAZgBuYYRixuZuwnkraoznA50WoSt4ENk7HogP7oGLPP6KD d3/QeiNDt/mNKon5ujbY7V2ftlJnfFNCGnWvVsOfs19iZzQcwDFmopmhmRRj b06b8V3ghpvSRm9aC5xOnSRb0K0acE24XRqoLrgK9le2RdVtQOf8RoQ0J/um kGW1+sd0pY5+q8OyZ95lyLBGZVme8uPX5oepZPI8x6+89wBQSrSCWu5T7mce sqLKN4d+uKgB2YcRuEyXi2uD0edJymorMTh+Q2TfdAAN0knNxhPKiQBHKp+f DEPwtZ34V99gLX47l8dymrzTsm/z+FtRL8qemASEjp/DbUcXJnQnskhX6msq s8sy0DqTtIPU6Vr1vc/DHrMlNmkJARVticbPGfxv/OSnPEOa9cDUZJC7CZBT gCn53XTetbQKX8AQnFyznrevf2cPSFP6DO4+0gV2bE40oZm+bufAYWehuI7Q jsAVEdamCRgSVThONfVGytUchWjkdl5HTsjkRTiaP+2KwiRK8vb7bEnLiz9Z yRlOMQhIFB/rMbQVOEg9iqeOqiAFnSaypEDbsgyCL2j4dWGcE3hDV7pI5NXP WoLzl8PNZkwMknLrq1xqFFfPZmZcauR6sReg1aVHs7ae4mSkfau8xbMvsL4A eEKvvZyrtlSU0/0muZ5Woy+fVSxrrjc3/Xd3Z+NmR2k6ZiesZx0V1CfTLYJm M1aH183DHsNcZ3B+r5j9lwWvRLT//zfq8Phksz4nOmLPZE/PtKpAb65fQqQp oyyAG3jsl5+5f38SXu00YnZ4MJ4/r62Hv6pzfNOn7/x1I/eaq/Qw3tmlaMwE yGWHe53B23WeSzDB3Rf1NDPCwZbrlunew6oXg3+Svo000aZlbaydvssWUpdX QiRGz4f6309dYEzbnklSYaQgE7Nye7N9n35lp6yAF0dbs13T6QaznCVakyCp brCXc+AInIS+NkYn1vCwIzMfUoGcY04U2AivSsSu7MveL/O5Ww4+RlRrUdit 0BXFW7sqVJTn36rVZw0PB99nkAxvuYPOQ1tCK88XM6NlvHxhVJoAmCCxvWCN GOrGd92uRItGrB9jJC9gs4Q7MQTiLdG324ZwRo6Ktx7dJiKOzHVClFzvtIwo i1v5+ddta/PegmlFr/16DpeZIfogcwKAaR7Mf79YxiS/3vJq9L5BA58d/Onn cU0Yhr5YoiABz5ubCDzWVfqrlWvGe1OIbXPutERCtx1P8qu5S+Vq9mkjE1d5 CDxhZAqxnIC3Wo+fvG9nMt/WwKlwy5KtTEj0+7hmTLiBoYUv3HNsj7d2f0CN wCokDSWWcRS9sdqqxiBvlGyOwmO3ffA4IYN/my+U6/SXcOvTw6t77BK8swvm XN+yBIOoAJ75oicrS1zH+/uac5BIiLIrxP95wv7Nf6xKxixCwXysvj+Fhhpf MMl1KkJPNjt/NZE024fRnkPGJ62vWy54NMU7obAKLv08XKv4TLLffU/xLKY5 DZv5FUKqS1eyRoDbQqt5vfwzPpP7/TggTQh1eZL4tzb5aSU7eHQ1U1v9ad8W gDASx2eayfgY42OaxiDbR0KGQOrSBWeqEaDIW1FIcPKiYB44fq5vIaAusa/l ozZbDWyYmpgwmJa9sVly9zyzl7pPGfGDnx/HZJgGi3ZifG6ukZ7H1Rdgauso I/L7uWQ+i8eYbmRsdXcPXXZMvI96gy5HqPHzL5gAQCqsu+kVkJMN/Wm59P90 5vjRxqmS1yVyHHXOZ4hRnQGhFv1DyrUo+OS0DL4NHhLA3CEjcagkkmy7hYDA JnetmsUHduHeAXowsNxfWXGEA1YkM41KERRoOZKHbZ5WNAt/szyLyTQ7T5v2 6wXzV9vnGDM8OpD3E3/30rN5O+2NyDY8Ar9VsVcnywwbf13y4JL1M8ajMxGP d/YyUGmrvcWmVE5xvYJGjBOGKCMRa1bHeLg04hEUS/u+m66tFFwCh4e0v05a w73I2/wLvEaabHcKf7NCulj8ZGrRyoYSAExO/8+E60f5TWpcozYN/P1MhcKE kzB47I5bgmtEt1I0tE8ioy2NmAMHEpLFHZZAl8P1zZ3VaLTfwptqzVsiEaB9 WRbkdBSbcJE83shzd5nwyK7vpCVqhfgSe5MYEGI1/kg/73CURDExgL7ojjgw z2aoObaY0H7QhgcUY64NSktfBzcC4UFmfqvYhc4HqlkPKLUzsk1DcvZ+aH6B U7L/puMoPiPBMIcM7bIiDl1gPuNboRRnHlKa6arvCyIRx2W/auZfUGkd8YuU +FTj8YYPmP11RcHm5V6TT31jRQdBGp3MWg7/h7zPL9ZRy+PCZUar61/mW7O+ sR5D8viY7jSuvZy7VPCt8gn40VnON+NdUo7cJpxPH2tnZfISz8S4lOlgrg+U tnC8nBinMxkpgEKG0vVvkWCotexwxqLPrp6HXCL4yARXqJHFqK0PiBfieAmX PdxjCa+HRIfmu+5iwBfOYkhDk75qMN61lpsFv26oW4Q8PlfCxMuOn9J0710B UnLDbzh8bI9y9GgokTboOrr7aTf4nB5jp/kfaiaJXmsdgk5tsb28fS7jYuex 8/luor/6PpoOKaHAJnrjeQBcBhUaoQdDiNc8Kr4Fhy9X/5+5VVf5eQHDQ3FZ fd0HH1ldfV56HwHd7SZfFsDgo0i/8nA9UUi8qhe8TVwrMxG/GIzX+XO/G4zl tPOlpAMjLJmCSrSoG2syMvEbSDvdp4d8woWcvDic+G+2Pb992GXuBbwd2YFP nRwQ8oWQzWAsmh2bvcxftx+bbgk9BDEDEZnkJ6xJcw01UukEO8LVr+W6E1Vw SXnft98/KcJ739xCMx+RtehYgxyznXVVRdlAQKvpUJmZZ80GENphbfHe5Nvk Sa0ZtY57AkUJPbb/HgNBNnc9A6I+oZd/j1p9XJPxeYQbYnKQnW3rN19bg5+c nTuDhzqoTJ+/zTQBgh6xRbHPF592GWA/9sgBY1yROve9R9Y1oBf2ebw1MSMz AhHNaGtt17aff5GbbPsuM7UYdZ0vT/r4D57Nn21Ca8X4DN6nmLbZDO5H81fW M47C9z8xWHYqoEbrFwET5ovLLNft1oBfXSOs9vtzPoHEZUy/kBC3qAkzjbvz NBfNnwcoE1XHoke9V9okRgtEPGFf67UMbfjW2eZSgvz1bQpvc3sxA4Oc/lRF QXRtKysbL8iJu1hQEOJoUfb/fU+TnA4Cp7dKvM932F2ETMOFPaDF5SWxjFQf FebY78WDBw/Xz3bH9zijXUNGUKsIfFeE6KaztK91ZbyvP3DjCbWaAo0tpkH0 2GLbhtfGlJ1tT4JHy25yXOTA/6S9T26aKtgSX6iH9q23im+t02yOGBfR+31x ezszezAiaAjpvMWE/Jl8w0AOimdBb3f3mEax37c8JVM+B2AxMzAe0s3/AbO/ JbF5JYIdmBnXJ4CVMgCFFDSz/63Xz4+kqou2n5PLZEd52t5z92d2Tc4mY88h I4c8kBwjg8+kOTAAX3OQzVUJvoNlyyPOudy1eNJUKl7fRz5YD3+RZGO3OVB8 YSx/Bu/V3Wtid7VlvYp1rnIkt+DC03jCmae+H6UvlsfLG0WQa5Yf4OGDyUOx tcHOqdwsonBP6PqbdLX+M6GQuinmKPBw4vhOTkD6j5GtKsmWvf8sNPq7AZ+I bu5aYknsjEBZK4A5YPu+XyiYZBGCTa4eOwYnHwfXX5KBDwHR8hGZtQf9H/tM iFkPXMv+0r5L6m8TZhfFH4DHvfFa4Kdy+PpBYnauC8iMcQ/Ar/GeT+H37c1m 8W9aYc9vdTpShW8gX4Rgf/h/CEsIzK+iO5f9M28/qHD9DXpoIBx8nJLugGD6 gk6RF7SKm6yigMH+D++3L3IftC+OD6t8DPN7q/8bm74REiy45Cj+IqTvkm1q jv+HZU9xCKi25dX0y/VqCNvqFc8Lsi7fl3DM579YqCmbdxe0RJrLHPuW/Sz0 G7p2dmHFrZtcP8arXQL7MFOQsprOnFp0xWaefvM9WsHkHTyNfBbuMlnTG/oT 3YXwxz/PNGszMJgrj4Gw9RUQoUWKFdYktLq8slauRGAKhWkrN/Y3Cwcc4gtL HjtjX/hna5XjZcpfXFiifbLaksJImEtqzjiQ+urmuFr8qcqlPFVby0puzXIG JFavKp9ZHte2vQShL8wWGEaqL5lYsz8z1E7+PEqTCC2Wskzy/qh5o2iqEy2H PrLsFGdzTkAbqBz5Vqy/s8AnoKd19/orUFiZZ8FXnYemz64Z4G3ywxZDdeqf TasCw1/wCfGk47AWC0QfVRlCTr4mye0C+kRE/T8msDa7RGl3xZQ2vw/6YnRS w6WXrQ63IVJ1qtKGe7IQovYe+0hofyjo/qByaHZePwrJi2V/f0LZHSJbQrJx If+Yc3OLHw+7JRxLS98eazXeaMH78+kyHaQ7paiBEvLIYO38hez3aqtruGAH 3DS3obC3D6IIl3YUsw8VhWJpurFNfb4Xnvp2fXHNBZ76+vov46o4rkBMZu60 lT+zd26rLtGEXZNwBDHcpd9mznU5HQlV+l3hCJ1VDgUyIeHrNgIz3QMJny8B 4PiZbgGzj9VVSfeG3dWVfVIKbgoNXAg9AiOO2SVuSOihrJVkJrD3slgyXCO2 rAIHqWyQiqv6rkfGmb5uL8bD3QCBiKr57Kyd24L7ecRfcE+8eRL8x2KvBSix z6az2LOBTV9z1tUuDdumnJTrXKwVPUNzmFQpyntTax/7b+e7pdG/nbUzILVv IXf8M01zlv6UPWgfIb3klOeZ+w51gjQKc7Aovsw6G5CBiEfyggC/bsurb2ot t2DH6jBHWfgO0P+OPrRhtrCZvYIUpPuuQGp5n9oinD/Zqy8ex8fN+mc83Wa9 sMC5a79v+NQ/x/lAgDQ52DhQ4gtNhn8wM3zrF2Wo7x9QSI+kgsJzKiYd7JL8 x26gmvJAgNCWxKW7Uq49uaihbFfihk5FWVpjrOXdAt1XCn1PzWAJuOnBQupW K3RPf4ZnZmGNuvK5K1tb0/3oLXIb09l4Zk2FsMLrn7EitPz2xkq8DFuDnPaJ C69dmkxsMqlpTDg5/rPI80BKhPP9KIldKYS2EIK5ykJCLWhYNDd4v8asJgyt kSooB7FlLppQaytLO8IZk7+zhzxZV1O+NFB+mkGkf92tCRb+mzOi5cJdMRWg KDEqkk2xnyiA/E7xy5ix+yS2gNJWwr2lY6OfytyKZe6opGxYtpTEH3xNlLCC MCFHDydbBKZNzad8nj4GYE/GstiMHLKMSYexNm7Fx+sxAEuoSMAX7E3m/+wR r5Se9T9/QqMP/d5FLvtI1Pw+TO+Akbi1460+JxR5rbSAOtAlw/hZNKPuOlez KsYwywT2OvRHrWRM8JIaqpRWZwII+iQp5Js2zoJkk0bN6BW1gNgqIdiFsIWe BjJTdH+JQNeh1+vkDHgQyojhnIk5GLW0M5+Aag9/DeMnfWDh78blT8VYZJJf t2ifPhd1EYCgtKIQOaSokdVOojyUgJvQPEsOyJnnDyM+NlLh4I/gJKI9sKa+ o0ykvm3LixLG00SjTFtYF0kSy3qp+X4t3+KOHYiGIcD984QnIfhq/c6FmJjL KohAE8p7m3yfrMqt1/7UOmyKGkZMp96UmS20CB/NqGswopg5+B+j0RGPKzQs b+iYJgrqHC/xd0qqHRS/7lWoBduBL+ttFX/LrKbwMWbKmJ1Qlfuw+ae7WTXz rjaFvfCJZDQXVMOyCgIIFRIAYRMPjRkiVZpIxIK+nvu+gfmqfLRs7l2sJ8Pg FCPGOtYm8XRLfqWHBv3UO+sYcmjXgamXL/ivOeyfVqTfBdt5j7dYTErpog2X fsUE6I0w/BS/Gk2xviU8rsmvGyfWxET7EIGuykBNIFQyCPG3XHnCZ70XIxZO pzTToQndCmQgA11B30iY6RJ0Nsgd8wCWlIqgCoq6NzeCn9qncmuMc5gLJmzO ppUon5x/T+F+TImCL+rxkFpr2ZYnh/K7y29Xqi/yv9AlBy+XOGP54tgSb8xK BhRkISt25xy9+KjmnUlQMKRATotfKJ97yYFH/I9kTKIKhZ6lpqoZhjf21tnc rZmpnilT+YFtdT7vRm+vWZJxS7y2aycIl//mCtQcX+j+YD6N/Avc/3J6Fxtb SzLMhCxe6odph9VEbELDZLWgHP+cJMrharCzPNHZW4RaY1goMVQehnee5Pow Sw80bTwL4uHvNyg16gaU1CCKo2hqoM+aioii7IRLsVWmKg037Iaw4uuE3mOO y2tIWg5ACzKtTXSeL4p1VaLKCR/s07VQIYqKcz6XWRgj8Qa07EMCxrve/woP 6Fr7w5nAxj13qZWqvHsPw6G8PQGnL1M3DRwSUvY/2gjoDbrJCZ6XCifqFpyP 3qFO0Oh6J34+66OkSLaaLJ8cnU0glsfg6BdYkOwVkwwuEQH8h5i4SOH5vCDS Yj2CXjuGSXFLYFCgiiQA9qfVPkpGZJYNkdh67aH8xu88qJiR8H6AwMmem3jq VWOiShQbppvOPXe/Q1a6lXSN/LUQGEybxFCkv32bz8JW3bChS0Dn7g7f+6uI 2kYrt6jyprWTVJXms5hdtaSkO2OTU1vfDjR0COdNkk3SkPeYlJvUgZuagHqK GCKuSqHlx6C1HaeYwtM5aKArmrT6a5H3147VTFjyyP+YmAIbYIPGs/YoS8j5 13b/akc0Z5WcmIon3TtMkYXrlrM0vlG4Preulh0PDDQ17++cIC68TqgGk0bU Yg5AGyN9yFgC3oWLHDABAOAn99vnRbneYtz6n5JMShnE4izH+bO0U2ebm4nV 0AsJfyY8q7I3sF0fcLbnt9g3e9LxVGiH5RKk0vruz4kojoivnqWChJG2R6XS L3ssdlLuCKBXAaVMaMI/l8rQjzPQ+1TqchOPsmltbAHEaYeBP1UIT43JoGDj gbMdmttvO3rkWJTXOB8u9hQpE4C05+iY4RuJnWpVl4rBGrQHCmiCHjdOftpM GuVMGoLELa7WSykHtO7idFAw05KugDG3yW+jyziCKDmjj8NGDQql0jw3Iimb fgwIY7PmsI8+JVOuo9IKTG8b1amBsAheHSziZtr6A/O709aboT6Ak31m7B0+ Or81j2PRh6FGIwLSSPSUj5aehwXzj3zTaKQXFACQlH0Auf+0AusED5OfunrA b2ZqXrHIYw3x6Pzb3qbW8pzF86wt8oaDvKEMkr8opHR5KLyRhVl8d8AsAKyK 2mMfyIoausBq+uEx7QLAPEQAt6VaBxLgJRZg3sj3a/jrK2tTs/Cpi3y9lX5+ weoPHJ6PzKoPr51ZVEduI/ezfICuf7pzUAR590iFIkJ3FL+Oav4/TGDu3Qg4 tpajkJLgBJMmLvDt+SOxBa97NuhOhD4SRthnptZvptNXQ0jXubYsyay+Sm51 3BITVy+Ht2lb96QSVt+FJqVRhu763Z6JU6AcxG9tamu2LGq1/yebSKLc7LSH mcK2J5JwdvprUBHyX4i3BtIbkbJDL713SCoibW1GixMWRbl2k5i65JiMcH/e YKDr17ukfZR9Rm9iLGdnS9kf5gNxpUhs46OlOLWb8u8knfgqhmIZN+pd46vq Izfjt2G47oCq2fquhM2kkcKcrqUdl5ZgjPjijbq8mpXwsZeWppuTnkp0GROp tnhlXMO0pLcRLwuq7ZKR4UYHnWnoYhoKSp2Jz/laA4Iw5CqqP0A1x4lY0JA8 WFOW5PmQSmDdq+Iow6z5FvW+jGI9JJrBAyODOWaQrt/9n7RLAnvvM5EBvQV4 V5uChLUw7bqgg1dD7+us8lLt59SmR5BN6oB4oYJHnEanGeCkD0hr4qBAfvrx rp6+rqxm6E74P7a7Q/zys9DS9VGfp46xH2KknTiUaZqz6P44uzHHMUDQi/LU eJazp5aab/FAcx+TZWzzw4SwNTRhdsBE+JiCqEiikeJwiGyoOJMQu+8Lhyhb G5GU8jC+zJ8Yd5wOTJRJTHars+gtuD6Scr5YACD+sWEbLO7Jn1Jdp5ZPiknK abFZBqaIm7Saht9SCRyFjCu/mIe8o6OTo6sDSNqb0crSM6iOENZQpJUEv6yb hEOF8H6IcV4wqdfQhHx+gGq7HJeivBMMsNE0nEivE4ecsCoouVlOPDt2jFXz qASpYIWWnYFPNcpW06FAQhzGIfNPuTzcP+kjYzze80tFSmC9O8NrZcvjDDgL nftzrt9euzhjvMWe3vSfS/yQ5AtKmoScgogvn7e1YkJ7Z+7HB2rsolv8rR5S VbL6gUAJQtKx2/m1j+62ZEtK5U91k0lkaSvVt4SGfGYOYe4VS1jttt5Tmv6F KxJMor9YEowmTuzKkXGi4cC2GNVw3HPD+mBFYd9+fqN80AtlrLw1v5p45lBs m8D7qouvCfiVs3TOJeodZO2Y8sCbgqgHc5SevYeb3ujXWv6XcqiSRf0++3Hg SLIdvkoeHBLRXJwPS7Wmr214bsHrQnARN4UzcFZX3+ltYEAo6q18ha6oaegH tSTNduiS70fIXNRZLfuN6xkWg1RatQNTvOzFZe+4hxZMolj3+FjtNBaXNVRm TjiEl5ivxzYRvFJM3l82ZIZhOF0C40v8NsDktp3ThuRwzPxnkHwd1UVsayZP 3wm1ZA2sK7TntO2QE2nml358F3rMyguXslrCFwxmnddQw2Dg8+iE+hyzQci3 UL63CM75PmvJZjRsQJZLIrEyfUqGMz/u26u0Q0zf1b0NxJXUrUEQI1e3XJHj NIxvoPwlCJazMoAO7smQJPGQmCHWlpRLLLVrKIGPX7Ayanay/DsQnvrR3277 if34Yg57Rqn2W99zGsAobCJBby4GSfqWt4qQsCcyPD4SvjpNiaSampjezre6 V5nxr8ip2T7wFg8okaqC05tFnxsgISqrlZj448kYX2wwrl5gGASBluI/Utvx NFhsgGppv4ZXvGLhRredf8ilMibFmUG+ms4/5meANA0RYH9MeJbYlQkERjhM RO0G6KQchQupDUDC9ICJ+rJgJsHVIpUQOH6Oen39VY3+e6Z7opxoo7E2SNL/ 9GrIYO4E1nrzlrK8HDhiDYNqpzEYR9unopVo3BR5TU61M9M+0yxwLpCKyb4a jjjZg2FEo/OiPuCp2mtWVaLlld9u0qEiYJW2lF7+lNPGsAE8UjS9PcCzEa7h FEkjz5uHnrXAV4rd9FDV5HIzd6VEO+I6IZgB2dcqrbIWScQlhpBegUUWrKQi uskQxAqrsv0NfOzwp6aCgibuW1vti3xhci6GAmCz9qZqEGo3uMMnPo2lJdEQ kx6+UnzQGvLvmTo7CcSK7ve/swaZimDT70/jCAomJ2t66Rk21j1LME/0RxYC npuKwflTH4anQkOX5k4Rxd8cjsb5Z6dEoF7aqkVu64rfky7bw8pIIhWbw5AK iQPpOzjOwiMigp9q3SfJ9CTJxSKj0mRx382eNqJiNVe5g3PEpjA2qu8Y8Lci hodqW/k/d9JWusmERxvWB7TvfmCRI0E3gFgqL9XY/lqW+YaHtUhXsV6aqVty TF3swJdYhlMLWpNIqK6MrUwoyfj9v2VwF5dkPmjRHq97977scJzyIYmdwqTp mpuKQ9+rfgvQBBmVYF49gl3pwJPkeZgxt4jqJXVZBkEpiWqFgk+FClBZ0u2z xiM0p458N+CzHiC7foU+8wDUiyjn1nhn+yS6SjCzSlkGlDPfXsNszC9WxuOY ZR7WFJinsBeYhaLr9/imODNUu6+X5wtthP4R/Kv0tEaCStn/AqFdv0ITEwN/ r80zx1nTZVr/umSchjyHshkUdqY1yKwJEb/pRFrrOl3d6yX3C0AQUs4mt5JX iyqOfkGqH5tHuVzdW24WAeIaKN4d2YS6YbYuXPhwChGqSL8iG+sVKaif4mkS VpuLrTNfgIvvhllRQ7dI2r+khvItwuhAmmfYXu5TV3whC8Z02y3YQMpBpGK5 +pbJ0lEqppb9A0zhmiiFtRe93pZoWjfIYnZ/twV/KOWukb5ql+5tECAMnEX4 HJLt55JYJhJnpkgqfxeydqgOfQveYxMBZr2IeJsrtNZsesN+g3RNf6a3VbZC jLCHv4e2jKTGfGsLKt45AVM5OnUNWbT2hKZUk4GqhE2GwA+5Umlh1sXNp2rG 0G6oiS0NrFQmDN+9oiNu/xZjHOtml/qvyXU/oos2Kky6NJEr/7/Je2JGQNO2 3iQdSiIwUMgsFvG6y+yKYO25SE2SrggtniRPA7BXDP373kUFEsmZN5ubtS4j V4mTBcdqme9KkD/zKgiwTIr/TuAYyVhonV9p9Dwu3MSCkhyXvHOXH614IrZn /dAPurFPWaIXaJjoqGDUpn+FTkDFAiNGczd8Peq+A1gLA3HZyVO0KD9MW5VR dojT0Qk3Z2Qucez5WGvKfxhYRj+ixmM8qhih2/MQkluwkR62dNt2qD8VTO4U G95Om/NndUDqhXy3u3iNyhcY32arzcI3ET14mT7fgYSLnuSAb7AWmNCV7mic 7UOHV3j+ZxxDEtYEsCTrrPgeueq7QRR137W0hgFS7QB42/yfIBK9XbGWmD+j W7I/ycRBIx+AHwI+9tkvakfRNId5TMV9tk0DVV73X9tyCN7WYrkt02NuoJff XrzrRbKzQYxxWDeQT3HMaNjUibQbB5w+WI7SDwKVamxPjDattxKAYEoiapYl GJO18SESkfwQiGuWRNUnCObUeAI9aFek6BrTeRDYqEkkqBjSeM1OoYF0TOjr N0zNZwM32ZcbVf8dMpf3+fZlLVv7DmyyZLWY56QO+Mbm9INFhQWVBxi/nYcL K76JgX1O6BYTvZ5ncmc9j+G7OaOcNbEA9egogLK5GqRIOtj4MkSosX57P2VH 2BtE2N32PAoKWYlzcYx2pLBDkNurj/K0Uohueqmbf++rq6l3SvwcHJeLe6n/ PiJiYvENQVWHzuExzYly53NcDANBQ2Y9gA2TVAd2K3Rb/sOTz/tNtr8EYX8d plojaql34HkIw6EAFmISkUFYbBFrWRlhXdLjb0VFaFUrbMJmBvVrn0xd+42n nj/QxWHaOfCzRpTTKBhbg3LaZH1q5oe1WB8f7JuWPp9hUSVwoydQkLg4pL3D prw4mWXgvOFZts7sI3sygzmjK0u+y2MQ2/d/kT3i+KOPBql1XIfjU9iO5bF7 lY0L5Vp2AthdADN0AedaEb3fbwPvym7EwLq7rHB8nj2+HcNgdDyZhpPNIKXP J6mHbGolCbvACLVseBKSSwHRs5ubLzsmul8wd/P77BeEx/wnn5kM/SmOmFb/ gRa33fEGPvf1nh9iY4sXf3WFm7IiMACCW2Geu3W/D3I841lf4mIxQwtBr/Yb d18KXSgPOshLGnFP/3cKT8wmYRx4Q/WTGYGwdam2vOMfooVFqF7HprRUQSGA SL1/XISbzJWbYxd2qDFjc/F+aFrzX68vOtmlj4Cn+9b7BnI/E14aMD2Z6qBr +5lK0bUOU35n9nX0+nyiVUu2NnWelJEWcYeRvnBFlTy/ZIWFdExRPvBp1ztk sDQcTrFNh1JPwxYbkICGSNiz5fgMfzySAmQ1EF5rah6XCrsgyiyjblibso1d kjzENEMxgmtD/J5/7SliVMMsVvh8DD6C9tQuByeiut6Wdbgavk/CXgi7Kudp PhjkZ0ciVBMJztTEVuqRo/8QxtP+T8ITD4qwrlq0HTGO2zrvrgYck0DfeOKt TxOOTynQP1tlE2+kPWQXkk/DFIfq5pLM5VrPnExB/g2MrM0eg5pvd7+D6WGP Zzf9a4cSKtOZAoe5nNImONHKECdJ5o9Qvr8TAp8QgIxEsYAbJ7yLM3MQNLLE k51+FlCogeNEhNCcjZSBbY2sBlcmg2X77Y7KBJEjwqwNzPbQ5/jXUkqse1br 6WKPs06sXJ5Ot+Eaod/3OykhjczWK6JvSAs5kik/QbNfu9xuZb8fIR4gdVe3 m5oAY76Hsmkur4efB+Ixc0tyCSQubmKtsq3altsyg3YVM0OGu47S5LjKUQcL NkZMMm9fhIM4Qg7NtfyADoQknLbNv+dzuyVYcMlFoQvpDBS33LbatJL9HMTQ DTbgUINSlG0qz4C0B8NFR5oy0csrs2P+y4zLfVKBk0z4F5oPxWWMVWt8tzxK 0ia3WawkRzlW4Cz7U9u1Ts4GwmR1WXGfh59zDLb8X/pJ4DdkRy+PfBzONF7M I1c3abgiaGitfMuD2FzOoexOf93ql3R1/PFZg95jGBtXBziHntp+dv0Zy7Aq O37ZPU0Ye7sAHEgD45+xd24BjtF5FB7Th2Psci8mIhACpE6wb7l6RLaYm7Gr Ny7JiVsfO+KKUOxXxQ+NU9INw9cX3hlrZ57xrA41+A6CP1C3dsswcp3+knty L/ihJ2BrxpRNT0fnx+PftSEXD6cfPrpvvr0hsEw5T9CdTLxtuUydX9GiWbae R4wAfavPoqb7W2Z09jeVpPphp79GZl1SWiVaSV2hWUoMHmTvFzU7cE8fIYAr mxyaRfnEbnj/gN+DQ9O7i36FpF9aA7O6DHdUKKwTgbKvRrTfy2IqMlnlSb5X Y68QicqwNRzDcZWjHsGxvrxGETOjHMFonb/PmdrLIPXrpxrPPC7iY0aAdmXc oRpitJ+ZbfPLZZ4vMxm+bRdalCraG2OYykkLi2ty+jeGy/C7WpGGT2fYIDoI nsFnf2Z+/yCGv5GiYPmD05S7MReXHNrjJ/nmebGH49sx5xvk0yMXYuNENpPj IpGXtY8zfXjCp+yu+uiwS8gV2yFs//mDvlYqspx2qRRoCi7oLXkdnVZEI6H9 t3M5pT3gKoTvtbP5Ues144dbq0czYHvqI0+4a3VshFLKkiy/WldT2tw6JFVp rEDVVE5A+nd6vk37rHftZw5o9xgE/40lD9HYeH0Ig6P7nNd6CX6GhC+YZhOk 7vRs1HXTtPots51w+XN+umJtWyMy12MbmDgZFPeGziCEAlsOLWtEmDSXpOJ1 7rdBgEyOWZj9hMj+VMPssCXx8jwQpu70z1tG0ySqdfSbRHupZPYLDph1zlMt g0Kad/Rk7Kac3q5+hxGYmpmYgaGwHwwlwhoctxRgwy+umbgKuxM7g9YdV1Cp WDJD+9vrqFNaz6O7jGrRtbaRs2A+gMfHYSkYfHI+qQ+/sBYxVDKT1pE9aHeI nErJY4UkhiWqiJvulJw3JEuZTvwmZe9UE0M/ChQgItJgXxjDsgr6tNzkZgg/ YusEJbaI2XYW/HFHKL9JHMMda8pgNYTOxQNjWy1/B9fLviBSf6abdn4Is6+e 5w9/7ifCA1unUQsbYo/+aQ+5px3s778dTKxlq1w0rtzfApWPHbuwQFCfGA0B YrSZtU++J2SCYZ2fmiiffq3XFsOsdEIvQG6aJyEsKVGyxxSbPTd8vsplXRB/ WxeXRBurARPMGAANgi8Efi6+3tdqQneoWr5Zr9Hw0qeXN78Ux9T61weAXWG7 GFOqn4wSABGb+OJbzuolsR1lRqQGGjaSenWU42a4GoJ440H37Ca/kt181m+g apZdTz9Gk7/TqppnYZyUau9wfAqDEGxLD27YJn22r1BPR5z1JKc9cplxs13N UApZYYet5leF/C0gkW0fMJ8ouyThndmbZGxwMGBMWrP+g0Dw8ZHaqT0/k2zy L2CEmlipPVBVlyka4N3hFkJGJ2MDfXQKl2UtGHEMmGm8amTkyza+voUYICGK 6xf71iKuPPzHzoBjuNizlU+9//qAmBK8TV6i22ynZIinLb1gU6TYCEzXWJeX SEFs2txWkVv4Kp6dLp/WPCt2upTnvCKdgweomhdY/Qwbk+0KZ/OF79YZb6gc J6ufluqmeH4ug0cGEKLEf4bFmmihQBG1Flo/Bj8zvjf7Zrth60Xe3EPxaA+b SZ5qIDpEkFzQU8O/fbLqwSLUc55B2sudcIBqja++iCO+yeLTJXjtdwlNQ7dL jrVuKvdwUeyknr+ea3PGoMUHY4YMtV1NGOwu4+/+ZSLlWULEJu4pkRw0HIL+ Tj2zSFASLl+3mtO1T5ks/5pekzli5myNMPA+hfvlU1gH+t+1qBt7a4I/ybY3 RDFSbtcmVUJZE/oHY8XMXGAgMJx3ehCiNbTL9vuXW2NIcavPLzscmWgzTPJt ZqNvC4u0lurSftJsEYPNcRBwAIiWd6izM0hck8jwIl9LPM6QuLmaX+AKYh47 YkcPmY/h732hn5iuHBpgGR1pjwrqgoYWfgR3PDQB0lJLRb5H2hipKYrhCHtj 4OPbdz7Yuo4Q+38nPqonRBjCfLrK4RB8Mu7HSXO0hDcpizkCG8BgrMnd04fz xBnfTindOfS6Z5W96xb/RU+UPtvnsW+cN+hduiS0C0yuuw+U3SsfgoVk2+sV IiC+r/QYxanKGTMUYxLjQyeRRShSeWy0PDPA1v6FvnIHhn6Kay+xVziMnu+i zCHnOGqDqaV3stWYw0Yq5PVJOUKWWnJYWrMTmX+CwMAxRxuhG8InR0j3irhO c/Ro96loXdBkkHywaoyuzKGsm4fOqDwHMIOCX6s03CRH+c2aP7A2bOOES0RO +biwO/GAlSaAaJ1chJFOa/SZhLytG7OAfHb0aEsdqLc7Y5Fkz2eesDtnjrXn m2Sff8K0W0Jk9ZlMT24usovTpnG8NOqTsEgCfxT6c/F/EgzZDgob/IJlFSBb oNDscS4fCgtPTn/Qu2PIwGB+b5uoCil7XusLJRPCmlGFTaZ73AY/5phZKO8i yoW8PGDM5JjwneLrpbCXvneS/zwK+H6TEgfU9rtiROYaY31ty0Gh9kNuR9q6 jkfEpYOvXoWN9HlIWjhpAYFMXn+n+n47JLmsNLc3wKbIAwWi22xC3McUsy9R uUpB8Ulln8IXi+JLTv92i2uwekdX36s8UH48nAQRF6+Obqu8Yn5c6BRxT7Yv 3CY8DOxb2aQZE7B50QYj3X89B24f2MPbWqyoNn+b78JHaGxfUQq/NFtQ4DjC mb1YGzL/T663t3bidjx2QomuKfnYg/0z5S+RKqtd740In39PXB9IeUC+Pmzg PfQalui0fuXMFPDzeqxnPs6mlD/eRgLqYS9fRA9vDm6bZ39FvgK2nIZ21hWQ TH9i+5EZB0DbNL4efNpcsmkbX2kzcR81i71ba3ozYh+zKsyuh3zR9GlrRjC7 a1qCmolE3LMPw38Yo2RcaljbnDj6I1PXZzxw61pRSqEXW6s17GVaXINutY++ 1CRcmZ2SMseI+FcUq8JKRSGythSLzveE8IEDoR5Il7L8TFyadJu/pLYNrNaW 9vl3Fn8OMsNOiam8qtaWJzO21We3k/Fcy2esmH8N4f2UB4LisFjbpE/h4+tf AklqPFVP452gFdugFJ/yFLHk0LcfZq8fyCMU9HN5Iqdqq6u7muy/4Pekapm/ L5MzminiGLbsmx+W0GZjmT+8DBGsp0BMmGTYhy85s6H3G0Hy30QRfnOd/3+s +RrWnq8oWnI9vK+Wba13AQ1fjDFTebdbIyHPkivGs69oP6ksoyzVpG4Kfy9i YuWVj3LfmA4u98D+csmgW/6MBDSCw7ekjyEH8pSY4/NpsPSLOfh6A0iV5iaW ANpnj6W0coJI+I7P8xfWcONY+l7VTY8PPC+LaELW5LSavsY7UECtC06Fqsv5 KkpPPV7TJ4vhAAmL0J+85+vX4LpULI72QixlujewHxVp1tHCC/osllxwP6PH eO+U4O7ktdta/lgaf58Lc0sNw0TLn6x9D4bHML7XiYkfa7eYRYnJRjBpd8/F Cummypei74e76Rbgr9RKS7S1D7tLVec1o0gry2m3PaO7WSIiobmGy/nPYmPP +6IOqv+alA9F1m/K7mHPdqygOoG9tAwUnbvImzqB6zNag/sUQ8lmsoa9tjSX T93QJEIBFU8SlLx+07yR72tel7d3WCetFfdZ2/+fo6wDMjgdFnDTBEGzlJ7z G5OSbgcmo7mH7UbJ3riDNFOyQQ1MCP9CX7LLdbtVeSpBCi2BcH3tW59fNgOG 2SazRocvGq/F/1Ox37LHqBM7mMwesqqUrgzbgS/PCvsCcjN+4LZEnEsPL6NG Roi2jY8PcnAyQpafa0XTG3GvD4zUb6LO6w/q3pJ2z14kr072ujdnblmT3nef z6uvOpMGP4ev9mhz7KIwtgLxlljzC4jwscd/WI+5w09qC3NfiUqNd3wjZE+1 Fr+cWRuZn6rPhABz2XUBTn17YDS/Z/+aJbuzLoKE6lZbk3YZDGozfc02wHH+ K5tMUowOETMHwdiOOVgv3sdTiqiS74VE+5JEH9OkRItNmrMy5vZYWEdG95yZ Kbsu9mHEx5uSh3hnqiQvTpw0k38XdYVeiyCkGnCuSJCuHutmT7ecWMznsJe3 a6e9qhpijhEKvLxYU1vH/MRg5SBYtrRllKBKyZysvZq/xeZmiun+YqRq8Sb2 WILq8a1nH/QZ11G9T7MUeBWfrbqjGuA3nmFNjG0XtpeSSKv/apnPWZ2JDmmY sGIPsTb8HeXbrFZHY9bwD3h3Ttl0O0cgYBkDqtielqn79Bvrms+614AA0IGV srMIWgaumFr/C8KNMHsMpk+D+7u8j9OCD07gvwhJtwA6C8wUb0NMRcaQcro2 h+lXFyA5Ik39dokca/82iUQzXUOeDrE3CwDXuQgDoabjatuh29Pa3REzUP/5 dUz8m4KVu3m0vr/vd7JaFAqyFKhHWnK8RnFGKk8cm3xikjEBYnHwOgs2BnHP JlgGgRtX68A7HLyZYu+Hz0ZbNgIjS0urcrgIVb5adpy3VVRWTUZITm2ZvLy0 Rma/DNoQisZsQ88Qvs1Fcqj0Z4mxkppve2COKNGZZqgANH6saBLbYmpmzJKU 3YVCinBUDyojFN/GHKyTdv1rGBVVyPl+IqPw75KHTkMSy3/TzgZqR87XXw67 wef8ow51rH3EuXpMc2q2BCujO0zWUhA4C7Bm7KyDTm4Y257mXEiqYL2H+jdt KqtbcrmSbCyLfaNzeKtjGoYOAc+c3WBeSgg28hqw50vPCEs3J5krrXopasNd rNJS0Pvo8maJjvhYGVEsTP7SlJ8A++ByanG+yof6hC4H06GwrzG7tFtuuwnG JttHTFpaYz9PCaxdbQOWuNQuvrSUitbrwgGd9B+jepdsqojGgWX8c+SOGGD7 OZmZdfxm2C+WYaDoiSmpPXxYXFxRuSl9WV1dXZGdTb1ZXV1e0cX1mVldXV0T AzEhNTUmfW+7WyOTn4aHh6db8dkGE6Jm7Kw9WICsrr4aroAUfp9mn/QrmMn7 7+87AgiLWqybQY3IeyuyxDJ4iUuQGqW9THy3ak+jvNtlaLe788O0vthecrCB OV2Da18fUIcaUJ929KRndNzKQSBtRRai/FKV6gY38uB2bCTRMuZ4jro0Pl1P SHJDNqgdNzbmYA2ckqx0/IScSMwXwXrLEjxB+5C+MANjnrjVUdy0plBuOIxL LrtOTLq4od9OC05843X8+GanCR6dacGMJI98mCCNSsyDbVr01Zkut3+YdO3d taCqeoO+W4o6lfz4qKLKi6Ouv6c0jtCvnZaE15iMa+yT9nJPK4o8oDzq33Z8 Z0HTIAeAP+uzfRt8Y8EYFwqPW6bgfCDqRC6NEvhdI3fFegNpEWNqy2hNOiEY QlhnfP50ImE9n/kK6kM7XDOXD5bl4xeBN+jc31M/TS3wmuGjsE8Qoy3nGlLN tuquCVqjxToiSVpfs8fyKLNea0yDxBBUWZutnhi6wE2eVYfqiL7j9Z29AtiX kyQHeyunLQBv+McfTihSredJ+OeiLi8iZbnCQ/qExqcFlGQRq4JNGy8DHmx7 5QPeb9/JRmBgx2S1sL6xrACYxeiHkpVPCAQS3kTAsr9+D51/gcyaWo9Ukz+w FkFzhffco8SngX2DNzAhTli1313gmiRWqXumGP8KC0G3D4O0DXxWf4Oo3dss Duu4+P0dQjoYNrXYeg16IW7uyIBYS1JOvFQ5CJ/AxhMge64Mgah37Of4vvpU +FRJ3ebIhRB6eOiZkqzFoEIQHYiybL/A90rQ3AiyJ5cVrWz1MYoIF9KZYvyD 5nZoHT/Imjroa+CO47SOk/tqnUpwcZp+ngAz1Ro+IzemuDPV0NW2uhYr10ts goGzEUKHC5OpgdIGqkbu6tpJShcxX1cZ+4SZ1+u3jOrIs+2Hh128Q9rrunG4 w/u0nEVwib8/ikRMf5oTg9Lztzv7a3FW77DJ8ROkTZuaLV3mGFcPkAFGUXjG 6MJAxITy+ymD922i3yr3k1z8qPkel79kg8zVhY1wghcJf76+gU9YXZmTyy4r rV60+K7o1KdnfZTIBSb0MffLjxatVHyY3TOKSONeDw7D9M+RgZggClQAVaHA WzyihzN8jpHTY4RmeE3Cb+aMtMPTx6SbwXlnmevv60yr7WQzpJgym120CmlM l8nqcwa2NhT0Vey8vMBPIyybE6yeOqzv0A8Q48/botOSD/CcSe6aDkb/wuva O5dC+yWrc7pqqwggF9eUcDR+gUH0QrN7pFe6mHmiaVcSDOjjqbQlLdO0t8iw Ew9O1hktk+lhfu0Pvh8HXuE0ApFJ2Ruo/XcgoS9QF6rOlororrHOs+h9A72x dmzE6gepPUd8S/KClG13+hf/0ZS9qNku7LgvmbRrZf8NI4cUTt6y/7lAbBPx gql+TxCiWdTeu5qHs2B/PH7LD9Jz8+sdU07qg1ng6P/AmF05xeUlpfIOAWfM 2gEjfrcbBU3Q3i1gpOef0VA+hnh8qgY0FmpM0lbG/hVkGIM+TzIIqkQ+QxV/ eRa9nB279zEu5nbU2lT6m6C+jw7KiK8bwvApg1gW3AyWwhKXokKPi5iOrxM6 v0qZoucQLK5s86dfF5s+uy22G1P6PS8Kp8dA+lsPt6F7nAgpMMSjx4SIe8Ck pfPAm4HRbjIgA6OFvIguxpKY/v8G04EF8L0zj7BPOtsr2OOTB8cyWDzg9MT6 QjB7ACK4LdHxuyYAhxjneiIIxJFsTJqlYWlShIWHw6CcNRNwRjtYV60jhiTS mhJ/JnsAevHXSRNdTv0LGCSKGiJjSV5gXFAvLmiXNhzQwjMewrcQYII2garB 16LCjjuYpLE+o8Wa5T48mVIuEsWw8l/F7Hz8UGLJWNgESnpvwpOMINYCeheE SmNqOPQXlXyXkSCZQbfX/JVoQqvsnVKYp/IzkL+eWBYtmxD6i+E66Bq7Zo8c rISdIExrDa6Gp40kR5j6g9Hn3i6lTP+TSxtivDcMkvQf/xTV81KUk1fwEPM8 rFybnCKFvKzENUae0Z8y4AOisx8a64Sejm763MLDOPiOcExKjJdqjPlvqp+g w/E4LHOyaEw+SpGHoYlUt7+IalhBXg789CXZsucuRhL/nHbITwvr9qGFmYbI rWLpCtc/+Y1C7PxdJCOGQAQIsAAE3JtJEkaPi+BOJ9fC89cW6HkZ8YLE4ts5 q32rqicksHJcO/t+u7cxdCDXo2ztkmoIywrpc9vyUzgJj1ad5YKbEls7z1DD RCBAGBL3fPgnmhCWJ1ZAaGNG78ag7ARAriIAwL++sBAhAGIgsvpiWESYBLT/ xLAQYAxdrh6+Ekh4YY4Xul40G9QF0zS5ZvrwK31zvRk+p1O6DzfAvus61EnO jEP3wjh7GZcSwibE18Lv+/1/zoxyfEqAHDhgsBwnFEPCr7Bh6nMjCIA+ta6e BD44vMSTTkwTjPyHc9QkZxNkR1FDSG/kZ7aMPnQuQBwkA9yurLZoHdKKe+FB +f0BMimSxhcIVIhUs93lbwNSp4POb0ukcuWlQEJCjfq/lO73t5K1dMzA6k3F SMh3tLD3mRMQ1qhOjsCSvN1I1KmA7lqnlB6D09vzN7kGjTy2ukv5m10fCRv8 coo/OXrK90eon18EUoMM51crXZ0uE6Pjd3+eY7LNGpAARyCRIAqYKJSkUrQM uh/gRsUMcwYW706/q75zDTmYUbr3BOgZahSbjf6tOEArQ6XE8iRKg4zi1na8 qPR9pYOxVFvqHLacmbuXt4PekvqI1Vc3PrfKUKoA1YG2Q9ArVAM6j5zogopq tyy0scjzTJacD5mxR4STRCuyD2qjjD6yyLuE1udHAKQQyuRQd1i3a04QQWxY ILBzN9P4L1iAmHg+P7tC+A98T1RWbB0+KCBcxpBWTnwXAcOXy631y0+uq3qM yqqgwEO2p5re04Jn3R+i7zZQQKTCamgeRcdzv8zyZeYCiu6kZ/lLEZ5Di+6L aA8Qpvt0mrum535ev4C6iw97G9gyll8tKGPGBMHvl5gzUEOLdnVEoMznZkx6 YkV/xoPzUbQTqi/Q795smm7Mo/p+cmzKHwvEQuu/iRqwgtJaPnxemOk7UXI4 aMpkJ9PXz8rxQprRc36/iVCOWdCTW++uG3brfnegrrDdoqSt3n6CIorcdy87 F81tiGZTGvxDtZVMm9iha4QHmIrkOquoWDb8AWjqLqk3EzRiei48O0QSmof5 kEdX9lpeIEq5Ph9UTScpVrcHTNcOhpmF7fM/4lxaqolx7PbHYOYUxqGXg02X 4DDpweGluHO8vbOAEpcJruGoSbzXq0Wr+CfPiYTCVHKPQu+SNjRVJI/6dq47 rkZCMHpPCoh6XdSW9fat/hjk+X265lsYMSDNxaq2UtTksMOQjNZijT6bP6V8 5MPk5dfolnD/zxTCJgRKfiOy0Yg/g26GYGrBqz1sauQrmyUUZaIvcMcicRrd OQhDlR9O2CrYQQTaClyALiTWyduURMV4VvjOGe+Sq4sG4MdQeCCAa4BqTw/M OOZkzY2yS/tbyV6ZFsosp6GiouhEWe75SAoGN5JHEI6H0vcCXwByMgTg7qKk 3cvZANY2RPC4Txj9Ycz6nF/c+osPLZ4Iw0HaI+MdprreAuCpTkDJTefMa0aO TN7v5QGfqknUtPrSi2pc8O6i16ss9IxyH9tsK+Z7sD7wRpWMN4THRqbTUJUZ 9E+Dw0jGrgNOn59fJqHfRseD5M08QTrLK5SPdHySiIIgWGTn/lceNp9WLoyr OKqw/M0E3xLt/7cO8cx39kJYSH+lyf28EWmIvWzFps+4BLeLF3WaR+CYq+UX 0C6CGffWQp8/RVpzFJu4R5E3n2KjZ19U4Lpsrae+Qz5m5AT0RCGdrUizUxHE sL3MpHIJ10eyIE/jk4TvJKH4KLekII6AE/cRqe+kK34/IgdML66HhQ5YBtJz 1UO/cS/1TMdz0EV+/JP4s4JgER16Tvffqu/Xx/e6W+CWjJbK6Ku+rXgi2GeS xqni+CH2qo1drvEBOeVgsbIYhnbigUS+2eJKGAJX+GZ47P9e38cTgnfCVa9m QdD+k7dE4TPe/ThdbGiN0GImAvd7Jo3Eunq/P6mSiUJrniIJC/EKpOuQvj5o NpyYvDQ8bzOkaGLMer9yrt27bHwcBz+D6piB18q1D/Kq2MRhU7PfAd4nO6DK VQYxdCm8vp9CWvtfdn4ZC8x6ND2zFkZPb31+m1GFqDE6wJvnmNDlJvkmuyzX jhOnkmavcN/1YMipwGNMmftU+wphn38v/o7fIqLw7xBpjHIggsbnh8tsZmuL zQayT8cC4AWsjVm5pOBMD32+EqGkU07u2/6p2aMQRAlLH5MRsWEqg0fLOA6E oVAQmIxkxJu1wEdvm4U8/6axSx0M7iColIqwbAYil//uChHupIXzKxib69vl xdwJn8W7IzTwAghMDfqYR99naOEHeVFijlf7aT7oMhl9n+EaF5q73COsSsx7 qbyTWIK2vdXi/+sbKWfWJVmqm3np0n4HzOlaNTIPNrv88MCwH08sFylSvsf7 XB+gf5tHvSNLVMUYQZQQ7lz7gf/tNrhdGJ6FXkNuu1OCZRn4SxCt3W5nKsz6 KriVMpqe73GspdrApNayJ6IBK9TwGA77phC7R3rbBEcpYJbMlqPK9UefsJp8 1DzQQy+1x5pMZQR0r+7LJJ6KnExL8Um1Y8I9g59q+1FKNre+pHicxbS3Dxu0 R52C1vrpDexb55dO07BcxYBqY8ZLa1YPhIRGizv6u4HFvs/rI1+vFz5rQ1tF c2W8EWminMc7PqVIkaBD5ZDEbHCx0EzaH4MM3DpEUkm64q9wy5OerD+HyrB+ CU8SAB0nKCKG08bxE5RifhlWWg2Apc34rw90gjuSrsGfXxODqzuqru6ufF5j Yw/nuufIYI04fUCpWLDhCIn71JovOnZP5sufGncJ/9GN1bOfX8InCPBB7xxb 6+iBX3KtUGqrwRt4a+Tt2Yizv2KgpCWOh0q79VryLMXGWxtPZB9LgT9kZcvz 7+SOPxxYlaKdF4ryq3eYlv5rX0pzOIDJfUC1GkTo6k37JFdLdy6QA8l+cGNm pZ2LVMOgJxAKbEuGf1LMIjlCTpCb1n90RnivUAfizyZfhroVZV3Q536Tozv8 IqXxUiDwzqexrNqQOETEgZ+yP+DNPhXJ/ct4hACA9kWEhWi3gsY7W20nemQJ 8D4UtN8eTyIIjMpQGaT8TPRAGJ9clGzpJv/nEggduSxpNOgLV26AbtXRR0Ey Pt4/vrQ+zQWC/MeSRjhLshWmhlXn4b82oPmJPEj9RYnBhtNnFuq3OUXXrs0v q77lguduURDS5b//ymLqaGVMrYGxHrMb79auIplD+TNyNs+9m01/LnKhqmY/ AUCUSv1m+mXEFE4tn0t+8KzUgL/IkcxHPb200KEnArhDS64SYutHjhJxaI7J b4tnLBMT8280GSjdryIB5sK/3xHqATbuLKDqoAK7wpUJjJ5gnq2zu1LJIZdq +t4hCCiWd6SOojP6r66wHFt3+wC6Zg2eJiWdpF3+2kIFLpqnQQPx5hmXBhJR RMei0xY27wCWz2ZJtsESG1SMm5+2tBVwBQub9pfKq46BBeztRRUPrTiZ85ZY B7AdTLXEwEa6pRxjLeCDVe/8zACvHbiM7TwtmDUV2q2cBpdkhgUJB1GqBP64 8nuNlc+Pw1msPA5V7/Kawp3mlgxnuqOyuaJNnybPoD3vgv17IXc045IomPyu XxOFkZHbl+eP6sQXg/TK0xEioIT5vLcrrGykxFn/L1dK6auowyLTYkim8J5i s37zWQJhm6x+30gJPtMZ3oHRqp1PnLL/MFRfot6viqp8B+DfsSilzcm0b5ML TJQsQednnOXUE0dMsY95vLU/Umy7cbqJAq/88jXu7b9AjqnA1/oLoCsfzZsD N6aebMZtOeC3++SwhEsMcz3vokDNaPaQuN23kzXeybZCiZuqNrJ5Y7g5tu4k oFv/uMdc8UBr1neBvEQ6qMPOs5d6b0OtiHOKS5+C49Z1aAeKVBoMiBUvV7IJ i8GsLeWLZe/uX/Dxez7nfWODx0ySfK+P+jIwZPDfuDiSFmOfW5OGOeNw7s+T mKiiWLMttwsTMIHvF0fyLWlKov68QwLBlN5hSQFoqD1t+LOcOREuZV5bRoCo +PL7o0VKtaqB4qzl9xRRrt+xFubfFsxpeF1YWtpMhBiGjNy2j61rqpOxyEP3 wEZwPuLCxX9z7Wo+lbvZdT2BHy3yJBDPGYHHoz3xuujl029LHhr7xzd3LrK4 //AIrMWYs6KpsdIOUy1rKPdMWnN8kKwvcc3lZmB3p0Is7f5ALgJoaJ4+elXT nMn6PZwW4bjLA3EukcckvmXialg2ciFY1ry5bI+LN6PnPpL3xLcCXrdu+8sM 7ONjsZeGNgoHeTOFDcvntr+vchHB+8nypH2tv8e27mlgMKL/TJp6+PtOK0W0 j9w/2RW7rsx1O4y4OQ/U4MBu+UhuWpabqBrbW2XowvNPT4w4B8i1TsLq1Sy8 Y7trmymctlHvE2WO+lTV0NJ6rJbdshLo4R53nKK4Vixbqq9qVzXOwvVBOVd7 sPgkDap/oKXL5niKXvCmZzyWreiU9ObK/oMaL7w/kxr7ywuOBlpO+raNX/JF cHYB9qwltKFKsHa/modtitDmXnjgggGr5LF6Wa4YYbyLg/w3Pk8RC30/p6v2 5JXP9ObsBpPueXu+5stw5e70RJrB+q2Q9gM/TX5vuxk09GPSKgA0vT5G5/yx y+L8nICSfc1+phAthrU0Bcz3mJk2dpCXSKVS+wjMg2fDBGiZI0v8T3RQIEKS k1mV+EcW4zqbSZgcgmoftI84itf6y8/F1/QLC7OSOkwfxMtKL5IIaZBAcV47 uFvlrJV8MpxxspYKP2hcdnFW53k/uEOSYjtDXgYsCEcNstN0xg3YhW3VtfWS ZNzBUqv8m/qFg9ZsTbj62Y8fvmX7a6b/sx8dtJPkIZNbGX3N2PzD3FB+Prfe kDthFj+btAdfj7xePGzC77q2+GeO3qpe8eIJkcy7euu6LmOofjVDm9He0jq0 PIkS+MqCzJgsdC1f+wyzhQqefKt9p64jfjZJu3IuFR84xiMn8Ib1lt8Cnima tEXNgZ5Kh1t6rW8dPtF1SDDCMILraZvg2Rtjqd+kUhZgMEgcOGygCJ5cgub8 hvooj5QqzUTaXUhwRtGs3F6n+C3v7ucq0IBkDq5N6X8FBSxWMKEPjU/0GzKg vwp+bT1lfzRmXLtPCN8QLYDqoqW+pe66r7MkaIxytfBl+BO+4bItLGs2Gjpo qZYmkaEt+nYZSlCHgKmC/4n3MgSvWVUaA8/ve42f3h+nQxLWQ0J4bPN7TFRw UD9vk3juZDOUjJekl7cufwUNM6ivLPG0bTq3clzmCRtu5nmQYasV77u4SRw0 rxi3ZtNAfocFvgOjMZAMLURIm79HAQKeP6hORt+3S8wIsHayXBY86RbCDZtH DyFKR7TlS061rao9gqR1zGtja7Cxs0W2k2yYEX0vMwL4eLVKzKKDxLZTiJy+ 0UbNdHyRmPHO8Fl7AnBAp/SclZKbrszd0GMCwnPHZt7NF8dC2DJ1BgOT5xDX M3tPs/4D9QNOCjdjqkt5oxs/8G+BmiUeACFLEl1lf05TyhjtRpC0uqR8cL+N hw5ySWXnE4PHKiOqbpSS3w+2iz8SGwbO8h6uhDdCmxYc0hO+n8KOXjOI7Btm thB/7efLs+dsvG4N/81iemJHyzKlz/g62t5Xjxv3vUP/9KD0W9x5hpG3hP1a EACwC3lY2xg8nVqC3oRDdn8OSpA/v4hqvR5dQDtfNuosiQicoPUaFK6ZdE+6 Z0ynu1cyca2syR9fGs2Gzk2HQ0BZAqiICkO4b4pQkMOkUr5PgL/txkvlo0qc O0OKsouYodletIBpfWay0+UWUYxNRDvrZD++UfWhOtSetWWsjvLorHpZbSVf M8DWzQvz6l0LZGqAKJMFg92nhrBZTOitR8irjOomyq7L9Eu1xJtXqLkiahLf auDiPetbq7z8Gbcpec+/1+bZDiwaNnBoa8yXoCOgbzeOz62HAyIz/FI9ckxW IEfPkI5aLGl7cE6lGCMQ9ned3zVlY/TFpWr5cSFtnzc68Qw0cI+zLb9pUlcH O8wYUQCcAW5Lldlopdt7M8Kcgv2mTXBX7DM46/y3K2aCWaFKn8LTJAH6UIf0 OEMa6B8yBZ3A96bk2R9U1Xj7Py6w7mfvWW7PaBvHC+LXC1+iwzo09+RKP/Sk EzJSIWgL0jiETG+/K2luoYT01OtQlqKv0EKmbZu7vflQMQe3U9I7Uzz2JrUg 4iqOumVALQXHm3z+v7JTo+AkHMovy12+rxSvuA4RMq6KQk9clJRncxIxSH+y SFMbRO3ITEbOw5djTCJ3XbhZbLgYyCtoSk5VMopqSCTIuE7ykINmEL9JHviA dn+euGfHApNctIB+VpIbFv5rGvPaadtkWwu4nSvfp5jLk2L6ua4LLsUmn6v8 Gr/xTARBspq8RlRXVyFSAzybLo6/xDJK24ZDGjTEeGx9d7Mz91RtMCMVKwbz tG3nDbOkVE4SvEpsjwq945JbCX6JI6qY7s6d/C5D4a1Bg8j2lqgY4GOYhbSs gnxsMBcEtpsCFGv1mK60/YLqNB8gv9hHLNqmWEO5G+cbVmyBTvoAH8wUDk0v T36bS57m8Gfl/ZS9Dqa/v85Anv8sukw9oFZPmm14M/X2EUs7ROzGrMa2v6kb k8uknJ9363TmVHSqLpJpul2BO4tQCj5NyEHtbLBGb0yrvilYQ8CYCBqZsoOq 7efq3QEhD/D7sHtTwtZgN0pFz64fUFEYb0/AZI6Bx5pNH6paZR4JfjRlPZ2W l2R4Xr/Dr34ja6tqj9jHkB2T5d+kuO4kE7qL6xpQhw9u/P+GXsNv+3+5gIJA sFxzyAxecvs6XynRVek0tqgktsof+H4RqLw8ZwMz61Ek832CsqxmWWL9RDdP NFbLz0aSx+fP3FVM0M6Un4MqytiTDbgPPGSbjEkR8vqpiEO6Ow/QwmWS3jEw nd77tuostASjn8gNigivlzv4GKCTvrHj7ti7eNCnprCRml2GVB+n6ZhDTm6t vU24b6UvFjSzQLuvmsS7X8lrp1Gc82t0s6pezQn0n4uYsLHK+NG4yp9HmcZT hUPLbLRyjqGf62w7ODmbXB3DKzEZZn8SN6kfXHgAToYlnlvjfbv/2hqYm9ig 3rs38pikFI+1KpmWV7Q0RKHj/X4e6RyrJPX+mZi81mcJtkqdqpVHYYbmUoIq GJ6WIQNo+UzjCzb8ToaUUvgLlJS5mdBIxJq0gO6kGrSXVZg0Z74Ysn2UdaLT gpOUVvlJiJCTvDSbZsq4XfuiWN+nvTKk3upQvPEahIguVqtM8iY7fPIeO16N N9TRnMihOi9KxnrJ7v76kCs/g6xfo3/sqr8FE79klINuvg+pL+atE4Zu9Lyz UlRN9EtqsZyDWyNxO2gAm431QMTIHp+3nsdoEq4Hsr4f97SUf75QJEGQWGua FCZo1sCMMA36VhP6lSjVb1wM6FXiIHj5vgwvWozCpPSA6PmJxP2G1uzLkn+y 03EPwa3fkXaFDsCMhQStimiYMfpKZ3WI7AsZFJ9Tlj92vKQoUth8/vHvt78/ QccHDfeDhYSman5Orp5Pra7tr/9akb1NKmGJDvxIrEu9jTZoqhz0HyTijm0T JoerMrvXV0GbpMNdQ5lAG/skb7GA/ONMLcDu3FzOi/iIbxqgv2pAhn+jEwMX AYjESDFDTlN7U6u5wPgRak3pf2vGfeYIhvjwwPD0WaiykJxN8fFInUzvSd0T KFel0KWAjZ8smfTFQQiRHlBNXMK2+gYw9qu4h32hhANXDAvvBIfPVvpfhCQI x7T4v/iNkvovUMgMxTSVPqGv7NncwUJ7rj2RZE5K+wYy4w4uU1tBWesrVw9b k99d4Qpy71TLDF9ID0ydjnW7CCwLnPwfaBhgQ1XiyzixsF2XvLONRawBVQ8J /cu+eXJSS27LDsYHUxphy5T388dDmyfSVT9Aj/DH36iNG4UtkRiCSfsFMfAy EmPThS3oKlYM7zdwSa0eSu9Uygw/gM6khT7NQwgtCoVtawWjHTeNNjfcJoBg kr42p6M/r5u3s09rh4Of+5aSrkhnYnyiwgeWdg6aXr5SNho2MMwsBKaioqIe HnoWEi6Kjtri8t729sLrx8M/4+fz3/f3w+vEw3vmmSe35t/QqUOHPNeuhhva 5XagoOM9t7sNv9FYgjDPFOHzGkxwuULDp/u+KwdHLAfADixfTj3k7+dsaQkb VvhgIqC1UnJEJzYjtr7PW6CAeFXJNJq8YX2CSEbbMIfAiHnmxrhAyKkdJqO1 wmi7lb9LzGYAoJlOmrL9mr+d9CjRu7+hog4nLBldRpz+IcStNC5qUboWc18I qERgoaKjoxzFgWxP0l2waQXayqy3eUQPDLvTAaJ3IzD9sbpOPLgo4KOgopax qv5oKChrbZqvfiJ4oCN0MmW7+y0eWLjkwEpDo6Fhfn/SZSQUKB9WJUZ7Y7Rg MqKY7oB0+OSJTVG8Gp6AJwDIWoO7wQprY+d9rV4I8l3EgNgzdVSjosTTd4KM nVl2vD8lyLDJKg64RMBcpaOgIZZj+BwVrbKYiqFVkBUAc3H6rmYvxVU+Z/Jt bITN6dtIUcJj+xPFmQtkdiFMlhsvVKy4WOlLOM3B3pzzCyb4y/VguvhT7Nup BKzgT+9JonNbAOWlJK8+VYQQ5ddCbPofu1dfXI2kfJWkpEoj7mVRcz8XnbBY WXmWlHZRfIAU4803pOBpcoJrL9VUukOOWVh0PSwIWregxUoO++sdVT8ZOSSg IC5fJGahQ0ZEUq/DS6OeKblh6CKCSQ4dULsrdRJEfyA45kOgoF1UnzKBvBDM 7spgRhxiV83au3wz5JSg4ohMn2AyYbC0/ANWuHIfRVIOXIwVJk6EikvBtMiJ DPzweHRXI3S9ZTKs7F4peHag3uWCWzc1KYIhVaB2kk53H2i8O5nQCwwP/Nko loGggPEUc1GyxGujii8Pc9uqJ5PQWqzyqPyOP6WgLN9dO4cRxltD542FVmcG SVu/ADzIeNBKQ0RyF0dRYn4K5NtGPbDizrxc28Y7VT73zBEpt/MyVYVdEnoU DoxCvSNJ4yxgOPWymoA+rVyvN6kOd0MbIYVXMONsmcdmZLRk5R5DPNSDkhqn Iz12Z3PP9WkmaHJwRLDiEFVgYt9I/V40lu39YIjud0VS5UtcVmZ+MyeJDHAN 5Z6fdmpAPBgkzd9JosB0AImlsoOmIQipFXonoyvilHxAhuDXSSK2NAaRdZQ8 EnBBKhOgUAxAjMpIovRA+xB5alr7zwFqczc++bRhBHoLVVTMGaeJFiZ/BpVy ZIvb6c5qfwUpV5/yuIZkBD+tdJKgvyTz/Gjs3oBAQ+BNnnOX//6Su/xIIEVs uDj9j7ogJVl2sxlocMk6ab+gL7PjPkSxtigW+cCENOJwUV7kHmWKxry7RYbe aA4btHJUDNI40UiiUphyeAwjXFfbiZ5+c9ztRfSA2bi/YcJLv4VSVgv36cpn NivkDC0NxsTqGlRi6VRsbyD17Ni7vIlOY6s/6fnacMJVKrTD08m+D7sZxZBw 876LTvHgSgcrZVIrUxQxgUKEjkXfmy3iU7ys32jP2+Sxu/+ltqNv7WsruvHl tm+qoW8gAs27v6C9Aw+ULIil+vvuuVQ/KutQboyDGabdgFy9uvJc8wHKhjen gjL0vGCV/1xVTfLNe6biAMRNelhuSzOH/Z8PWlh0J8VVqqjbFUcfUn+2ucPr TPzi/rpT/SpCu+I1CrDQX2nPhlOAWyoVp2RDdrXeymhygFywH3rJYQHmWabv aY3Ds9Zhs1LI9GOioMV8jU5nfeLvaBPNt4Q1zF3qu+tob393Y7ytc2D17moP Af1ikNrJQ5MBzxpz4M6jwEwZtE6sxWQMwzHIc3MPiKhYC6Cgoz61SV9oBfk8 r9ulTmJnKBHJZ4R2DrZqLufKI79QvsqeniOWQh1mFznCT1PNE/pEj323riGj W8JZcBL9fSbhUwAfO2KyHqINzcYBuQEdYBzTlW0MjpTr5+dLPPP7SnKOlW2p SczEl1QAWvALj/L5PQIfugIe0mXO9fnpAbkAUMu0XxGucI+X85t+M/NIz/aW cY04ks3UZHi6AFsD82luyaUGHroBQXuiXhGt8AS6mF/j92tsy/eWco5pXAPT ZFGplHDMh10CwDJZ5aRRmKicami+hg1EUER1R5qgZBTAoLTUqJz4l5CvS2Sh UmSXOyfvc0dfQ1dTbQjIQ7ejoycnIz8bNzPPLwcDH3sXEy6LjSN3X7ej1zvT 0k6gvTNUauIewlYmyMokHPq6vqKizgLW1tJOor6atrJOaoaCnvqVkaxIZWKB pQObfkKO8t4EPC2NX8o7j7/TFvDd3ep4GAmLPi+vLaLe1wfaHxTnMgYgKPoc h/4bo+pTthA981SZIHA+kJNSx+u6qd+SVVqXz2eps/DMxqT2TOebvU9kITgJ v42ESxjAoKyixhKmDx4e9hri8Y8u2h4gNj+KKo8aGswk2PCu00rIjxoem05i cj4v5Ogwi5dKl86Zf0/HhEHgS5nj1F6Loz0M30A04SWUmWu3lj/sk5sTYLsZ YbAwQWWStMA5VrjI3+RItXi0h3+SRGeD53nS7qf05hrU9DhGh1KKWoqqNMH3 Q4N85PRuw3uyihqKkxjxJmnA0CQX1XauAGIDl8t/oOcABTHiR40vMgu+5AcA 0aF9U7922ytic5+ZdqtMRL+WhzgHYnZ+5vM0EuWShzprzsQncquedBWa6+KA IaFDtzKx9llAsZ6xmT9HCLIeubdIJTXjvu9sizNuwLJxv/oo7KVt+grcZAK+ BaWqdaM4gwnS5A1jIZgZmJDyxFOHsqQbCH+Zj6RZNqN+Gup48aAxuVKzpgIs g4wrDjiELS1v/xONFvPXlr182rTAu6vMljhsalqhk9wG0GgXIpxhwidm320/ QkTbp+8J8xiZH3mePFdaZ8cmG39jTRgNNOnUwSlDphIjWfAhT1EnlOX8I4RY nhEdvWd/vERPpFueDXU2BaIlB6md5TvhmkWXJaNeWb0yBqImB67f8HbBapLm I+DMk4YmIWeC5Kw9o4trH3RA1PDDl17r+x4IjLIcp8/Dri8OLCJwb/LErES6 o728egic8FsAeqCczMCvzVxwvuytz8GtptwsAt+tzcPnWFgBwDru03juByCo xsKzKo2IJPHTI0vGKUFDPsJjeBfypIhoW6GbKmvrpYcJGgJH/HF/DJzz1Z9s Unuz7I4Rl5O+iMwl9sprMADTdpIQNCPvR567bw8eYP35fwMs9Lbeu6a6V2X5 IXVzVE7Xfjhr6JywbsNCWw7nR6bziKIcLvzVi5ZLGj6vBGB7C9DlaJ/vtK23 oJv6NkOpeu1oUHflRgnphI2yLRbqLNUQe09cl3QI62CzIYNzjv8aWQ3DGPQi kUNKOO0Yk1LMLFIo/zGoh5L+v2qR7LZfeMvocn/RCaT0oF6br2p9/rkOfZE5 yI4zg7llf/H3Bwx+vCiBzBfSqhPKYh/hxprqpPBZ0Ya+Ve8RE7V1+3QkI6GU ggrjWJuKKr/OtadinyhvWp6QujMoQ5sz2Fkg2eN9vuvwYx1mzPI9F5vxCYLy hTNcb3qJp7aXmiufDZD2HlaHrt2ogCmTavH0AxD8T8XeZ/+GpNuC+Jd/0lOy WQRzkkIqfeqGL+SacjsjohPgClIQUjaNg/LkrFEA99ZUMHAdsE2/MkAAG8CP ekS0X3fZUeyhix6Dr6nRp5juCy5Tq8L6qo4jm79G1CsNk4cnVOS7ZyZgJnLw f3zOidVAow6DaEeNSgv+HoDCjrTFaXN+s2RqxFtExoADv7yt5gJmzIm3dFhO l063qXqOjAgsvjxMJnSgW8aUINgou/kfJxgi3XTVRBtCRNXA+R72FKQCV5H8 fwTG7fqzqdcTkaY0wy6vyRzwWByibCI8UFYLZB0n4/3yroLjl08ONxo9dkLq G4bQZD2qmbA7E7sHACPChwV0YQ4GFDgq71asJnc3tAWqYrdeeu/66sEI8n6u ii8wExCIngr4sxMqtn5cZuDY+dC67tY69hzaFu6q5sobFDLMDYD9xg8uO9pC pmLAj/XbrAAS4sbC3ioC8Mgu8vKukkru3jKKe+cWH+rI1gv2yvIOGhI+jdyK HgruErfqLu4qNvPyMvYdBldmjDJEyf59TrYyFAMd7YhW29QXI6GRZ5ht3aSF bw+ZkbSZsAceOLJSypk2ad/vA7pT68QPmzA71nxUqFXpm3+ojprRgOfL4iK3 iMkOvqOG4k6f4o9/TN5i158O4qTcAB+ihZqA6TqKiuKqajbmJ9o2dYyqN6S3 KCYSVyaKeh5GTs+L7Nr0NJtwRz9aahZb6nNzqXXx8NPgieROvna2yjIuNeDG ljia8cnQkAmLWf+qXnbJEOXBOtfaSieuckdOdA7yRrIE2DL+/JogQpZu7u4C 8IrzFaOtei41sePOBro2PzJ6jrIiKTAf6rZrvVzEZhikozInhf+d/yn/GeMR 4/XbpP+Q/ETYNqSjoKMQ4zvjn9s3/4/n0uOu217fUvd6/97jmdv52270JPzN P6WjOf9M2/jbbPck/8jj7OOz95f3u/Mf19zA3LSjoqOi9w73UvM22+bzPtut 95X3dfdV8+jf1N9o88DfT/e08Myvo6Oi84rfzts1903zKfNRj3n3ydvl3/Xd xNjUaL+ho6HzafP480jzWPco87iPJPd499fbk49Tqx/z2/egjKyMTqOio37z vqs288r39qtNj5WPQau9qx3zEfM586CPaI+8qADwTKOgoyzz7Pdrq0urJ48D j3+P2/PS856rQscmj/b3natLq97w1GO/70bH8MBc6qGhrXi4ANyYpe0VQkm9 BR26AuK5Sd4lRgMfu1ug3CdjSO/0lHCN2SRjT/xxjpZyX2iMC68HW/OUvCxR +e7VvAAcual5ck2Neh26Ah5yvS5RWS8fuwCgjxiTvUhwjJXR5QqfL3C/jpZz j+tmTY94H7iscAy81fbpZQUduQGyjRlyTVYCHrurG2NPjgqMlPAEgDjQ53tA DY2Vca7vBGO/SnKPly9Aaf1uS1QAHIg50QZxTY4FuQIeMmDeNWFzb1AAwCSD wPcbrXGNla7eN2PsF/KWc48Lfk38bBS4AFixxeW6Se0tHboCAkFp/m1fKx+7 aIzod7+oy/SVcY25+N8HYHKOlnPfNWK//wcciJQ8kI2JenFVAR25mo56cb3O V1MDHJDcJJPzOHSNlXE+k4wbk0pyj5ffJIGNGpNUAByI8anqZd0mHroCHpLu FlFZ9we7AKD8P5Db15BwjJX9PWPv5BvxlnKOW9AXQ/h3j5dw3AVCSbwEHLgB 4dklkd4VuQEeuhpyvv3Ndnu7Ax+g/M9F+XCMlOik4DoAI0NlcY2VTo4LD7z/ jpZzj3tCS0/cA4uXcCwgceaJySwcuAExQVmCjVEBHrrqRkq9jcoCugMfI3CP 6UUPjGwAYEzLxBcjrHGNlX2xj3tQW/KWco6L2AdDSHOPl3O/3RYzQwAciJSs TC3R5hm4AR25uvqOGZGOBroDHwNwv89mcIyU8H3RN2Dv95VxjZbOVluz3Oeq lnOP63ZN3wQfuKxwDJ0V4rlJBR25AtL1GZLtvgIfu3tw7xdQSoyUcGwV0QRz n4xd8ZZyznec3xeuco+Xb1jRBUJrVAAciHnBNnG9jgW5Ah4CUUrtFSoeuwMj c57uFa/zBLjoVEgDwzRjjZVxjjoAQ5scd4+Xc6/tFiNzBByIlJy9BRFCiVEB HrrKJpLdNXJ7uwMfs4x7IWFwjJTopekHcN83rXKOln+j/Qy8L7sAWPAIrM71 6WZ5uQEeov0+kY0CHrsDU1vQFiGvcGxQWKAx8+t0T42Vco46IJPfJFrzl3MM vS5B+AQcuAAZ8Rlhvv1VAh66GpPvBXG+j28AHOC4aBsDYHGNlXLuFyCT75Jy jpf/P2G9LXNUANz0aD0SIXGeebkBHaL9zkVpBh67A+MLnI8ZrHCMbEghwQdT +P+NlXKOGnCf7xR2jpdzb1myj+svHIiUfLEl8RqBVQEeujoCkt0FQhe7Ax+Q 3BdDSnCMlPBUiavod9+RcY6Wznafj3hz55dzjJgcQvltOhy4AR0BQUq9jQEd ugIiYU2O6WoDH7tboPzPZ1CLqJRwjdkkc0+MXfKWcl5rjOtHrnOPl3+gjelm VVAAHbmpCk4dcb56ugMfE0CbHXFwjJTopLnbNENrSXGNlo7qR0vsF/KWc48b ck/fFB+IlHA8kL1e8bkBHbkBkb2NelFRAh66WrOPGWHu928AHOAInEOrCHGN lXJO/1yD/5Jzj5ds+P1dskVQAB25yXbuBUH6eroDH/MYk40ZdIyU6LUp/xiT 75FxjpYuQ5kvQGtXr3CM2CSSDd0GHLkBHXLtBnHtLh67AwNzTP7Nk3BsUAis cO/nGGONlXGNmvzPd5xyjpZzj3lBa98v3/SUzGS9dS5BUQEduUnu5hlh7gK6 Ah8TImJN3dsDuAAAQEu8W+OUcI2VzUVLv4x78ZVyjgp8T98Udo6Xcz9hvo/r LxyIlHygffF6UVABHblZso7pdb56ugIf4xhynd1bU1AAEHBPYI8brXGNla3u 5wt8v46Wco/bNmO/jAeLlHAcQElm3RUoHLkBIWFN/m1SAh67S983gd3mq5fo AFBYDO/nCHGNlXKu3ySz35Jyj5cfc53t9eu/Adz0KK3uFVH6ebkBHtLlGrGN Ah+7A1P63BdRZ3GMbFiV7QdjvC/xlnKOu/qPu2h7i5RxHHC9li1RAB25AWLt FUKZVgIfu3tzvy8gYo2UcGyV7RRDm/xxjZZyblvQFyOuc4+XD0/t5XljVAHc 9JmdLlFJTnm5Ah7CJZKNGc8DuwOQ3zRDmUlwjJSB/c1H+4zr9ZZyjrqZj+tk O/OXcN00QfqF3SwcuQEBYe3muVICHrtrL1OZjRrzlOkAYExo/890cY2Vcp4v IJPfknKPly9DafxsW7gAWfD4vE79zXZ5uQEdgo3KRWkGHrsDE0P6vv1L8wS5 6HS8s98EU6mVcY367BdTSHKOlnPfNUFrjwPf9JXMdE21LkFRAR25+e4GUVnC ArsDHzOQ7xdCDYyU8aXtN5DfB61yjpZeg4/rRPvnl3OMORAigb3eALgBHTFh 7gVBAh66ArP9HVL5S+sDuKnoZL+j/B/wlXGNCazv5xh2jpZyn40Zc78H3/SV LEBppY4ZuAEduVmx3gVRWn66Ah6C7RZRWS8fuwOg/zxznUlwjJSIidk3Q/jf 9ZZyjhqQ3wdgd4+XcNwFUkm8BRy4ANH16UVK3b0BHrrKVkrt5XoeuwMfU0i/ /W0PjG0AcLzS5At/CXGNlr4uc5/cB/KXc48rTo3odHi5AFiB1eUKrd0tHboC InG9/j1GAx+7WMEEQ2s446iVcY0JnP/PVA2OlnJ/vf0/gwff9JWMGJHd1uVQ AB25GWK+jRmCeroCHsMWUlmx8we7APHod7zDF6xxjZVdgt8HcO/2lnOP62bd BHB4uQBYgMTFFiFxBR25ArItQZr9VgMfuwuf7+cacoyV8AShqchXS9xZ8ZZy zne8LyOvc4+Xr7z9bVqjVQAciKmpenFN3gG5Ah4ycU7dNSofuwND+uwHUWdx jGxY9TkTU0jv9ZVyjupkT98UWvKXczxh3jWQBRy4AdnFVZn+XboCHrpL3wZB +Y4LVwAcAVBIT9vEWPCUcP17IGNPSXGNlt4Wc7/8b6uXc49I3jVxnXm4ANzl iclWSe0tHboCMnGd3hW6Ah+7G3C/H0CajZRwbf39XIOPCHKOlnKfjelnvwff 9JUccE3lqum8AR25WqL+XYHeArsDHwOQ7wVxcI2U6LTJ98hHS0lxjZbuFlNL jOv2l3OPuPr9PYF5uADdFRFBah1RAh66A7P/Dk6Nl/MHucg0YBPTBEOplXGO avxvS7xyjpZzLyBgv48DW/CUHVBJvRbxUAAduelFSt0VUhW6Ah5j7DZhvXNv UAHgCJ54w1dlcY2W7jZj3xQj8pdzjyi+/V2hebgA3AXxGUL53S0dugISQUnu 5VICH7sbQ/uPGnKMlfAEoQHw65fsWfGWcv4LrN83lnOPlwztFUFqBbgAHbnJ VfrdBVIWugIeg9wGQflzb1MB8BhzKNMXrHCNlT1h7ucYY46Wco+L63Xvi+jr OJRyXUjMOjEBtnk7RSlMgc7lnm35Bh67A/MKTY16GzXo6Dg0wpKWmEGycaDo PwYyrhLGio7r34jujE4q4k7L5srajALaH7bqN4r23qiqH+LLSg7iDjLmFnYe zh88iH4IF2ZYzwvyTlmM6QPe6pvGnuYuizfyqUGd07rOx28G92dw4G5Ab3/m vuuOXuDi2vaYeojKnOimjhdXNsaq5zPjFApo4dAapi52H4oyB4ou2ioGjjfZ jt1+6jLOxqUnHNQ5jW92EvpSFjY24IzyBuruNqYu6iGOyvYeziqKong+9rhC oOO6B5a2ReHoyGu67npKN+bf2tIW5TMQNipII7subuB4/8JWsibriAXOclW+ Gsa2Gz8W2Ow9bblTbHroapaNacUwV5rXa74ZfmA1dhj+nFduUMxWHAmxcVMh kajnhm4nitAA+vHL7xbCEmYcFoYdoTrAIu4wizcsYCZ0kWrGRm7L2Brfjfzr gi9V2rp9LsfaF8xrbW7KEuIOwGY0ia7HQ3ICdoju6odaGuav/RvZYA2SZ7o0 Y0YMMCZUYl7aERPHAsIKkhAWKANta0fOYmZgHvIzl2hDJrNKuKvcQG/6BtxK ujBG98sjEooO1zBcByZfbFJaWf72Qh5ersqPVn82zb99X7ElZ0rlP0Qbt16+ 5V5kYzA8XzbaWaXx7e/qZlPtIhFG+gHru69IembVnjo0btsXXu+X/YzCWA64 Fj43CjmN7J3G9MvDH2ICNW7yL622/pOD9/ebYQsJs5l5rscuJfY7VoLrKvRm YB+ygNKSu6z28H63UEjIJbGhVpGog2oo2EgvCmZRkmlq0iuL9CY39haLDsbw svN8h/cUhLXKePvLFnIdZf4vV/cYepQfDS1nYButxr9tWiwFc6JqLi8TBDZ3 00bePdLPimMxZQYWPu5cVqF5hlq2q+JHT7I0VgyLwJOssS/r+V1ajyftrEMc MW4jk5KGQnyksjS2BKvrIsJaJtvplsWC4vaM/PItloaGmo3gBuopisGL3jOd QvJezjT1jgK+Gr2rO9grRC9Owk5g4gLjTC08s4IGt5K2syAt1FZWkFcXB/tS rMoQzoEQj+3KKxKbL1/CCKRgu4CWT7e0a9NmLhB3BJ0CFFeyprIMxvXMktb0 yKI9lZIR9LU2zG9kFcr5kC3qprfEhhrXCIszRsoSP27KfmYFNo1dmibiIzQY iuf8ECEuX3A3AgWXQ1a2y8Ej8eYUV26quTrzOb8aYSpldpLYQd/0S+j8n5IW qnKNfmnF2ycIuiRll/2HmnfH5ccbvo6DE+6oBnUpf1NGM95pbg+pBmaJy3kq nmIB9j3y/fWXV1oQTXIvqWarqYnqK5nVsCqu8q8yATgkjkb5unpHOdmK3mX9 JIdAH77enbUw3/lgR2SsW/lGwdqeZ+4hrEABBpUF4RdoclsHn6rVgzLWbgyI FmetUnqWmgPOH76367tjKPoSmn6ZGz82l4NDzQo2ojtPvNNpKggHEwZ128xG Ni8TtYNgJa1TurOlRo9tTWu3J+KyDmKJ2YpR35d+7idnMY17ch+0Uutr81Pb 6+QndwBNt9uC25WjGJJ96pZOYCfkqe0VEurm8uOUAt9byqP4URctZvYPTG6D QlePF+OhZ6dIj+/b0BJXA+HqDxPvNmYjbU/wAWolQwD9l2MJjsuGjgTlIPUg NAcbQ/M+q2B7Qe1iPRX8n39qdzGoVTonPGt3Ne/iDqpm6vY4G+Tr7Qmv4UbP +hLWCVSHC3VfYoqNXDUVJY5Btxs35AVH42LGJxZZB9R/nXavGxz3zWmSy/qa XWcvvcoXIuGWcivdM10Nx5IfssbXYfeEP8LF+UE2qz7i65MXtpdi8rr74B1i Eh47/hkyZrJh4+Y6l3ZHhUI0Zt+shFqJfaH1QmWL3kAyBTNaP0br1Ft6cjp1 84lQSmbR+BAuXa5lUsDSoD6U84aOfWYeTXYM4PqTdEeBSTJkgpX1HhMKYnYu iXEhFTPpX1Z+X5bqqPcm50Z9oCI/42wAR+T8IgCUG7pK0xAAA8VG9yMGvsvS jz6h3ee9s59ymmFEFzMsw7cy1xocQ5A0DjNezhSfBhJtXjfWcrdaEortGkj4 sFU3lk6HQDAby1LuEPQWxBKG5MioVh0AhjCJrS7MJrYQqTREXiiHMLNmq75C AWcXtOj4Hk4McXi2mkVnFjK8cA5ORIN1MHAILT+qRPdTwzJlrsoa6Rfnf/Yu bQQphEqTMbM7aa9HgZRDRKuuLJVipa+EGJ/3hUBv5UuHtbS3UWy7kBwjSb7w bquChVINMjcSovHqusJGHNjk33RHf80ALGYOk5SzyNqqV67WGjUbqItORlxC 0iCUN2UfcgZH3hPckYhzxnLSbuMLRMpryWPd2SpnO6XjnwupBptjRPHZB5BG 2giTzFdZaLNcFldeMs4w4h59kOgw6LayU8vYv9taaRjpGwuSC8UOepeHxOor LhTbr5q2wD0qPBTeVd/Mec+vgchZhN0sI7KgkcsvRHdicpbv5vamyXQS5+kv 2gpMJU2OVtvuMu8a2Bte1DebvErACsnDtk/AFLoPlpPkPo4WJNYX89EWzCha yLXNfoWj16JoRw4BYGMoIHLLfELFyPjOy5Jfnjq+IgNmBi7MRlYevTPpB/Eu Vg5wK+L1Pncrp+tazgvMLBN2fKzMIYblsv5xCb5DUQsT9ltZuBzXgwdPLVhq DoGDQxIZQqfiubg2vxH2PmQDPfD3gBAyKWWQpvG8284jDosf2kwhWidAFr4y 5CccKnYrxi+vlGdiIZDqet9XehN38kbsk170Y0N2q20NNee6NOLqF0fcL0Ya fCsWgKkO2atyLpfc4h4GlQTi6hGW+Iwe44htTIaAxfo1XobCL5owXD9LJ+az /844fmP+cPMm1kNfixLXWShcy+dyTUM+h3aKyWv9Kihb0jbPC3Fp4j9P9zYn EeY3NWumiseIyGviJ0BSWBZPN0YtPzDX4l2W6t6fhppvfjDPcAZmlzcCjg3a anjuJ/D9vAGt/Pgb3vgPUP+Tk5IRYtzb4hS8MLyCxooLxyS2l8q7LoL+ua9H yrYh6hpF1DvNhEtg0QcUtxlbkEM9RkPkHuK6rQS26tGEPuOKOettJ+o3WnZx ASm48EYXA//vWC/zvvtmdvNtl7/KFm3s2fb+VNtFEWXsyVruzp40OD/aqqlN GpDoF7pW5W2qA85z62GNX+BdadfGku1bH+HpBIfdc+hZRw8uXWMJ+GAUrb+3 TlOGYZHrt1lPQ33V/37i7wt7EidbokDKNVVM3GZ7WBN+IacTc76uycIp18mz fo14vCeGfqQmhVSuZnpG6vEfPRI+Y3YcI2Aw4iMrGq5Cd6IwNwUTXy5ebU7j 00VuQa9ojvxijyf+EJZh3AfmfF/xGuIOH5x38LYtf90QF+o2bn8G6crXNVf3 6qPsjWh9X/EWv/Jp61iWPLOaEdZOZcGzWg5Zdi8yaVSz/vtRfNJaW7jCp62B H0Z/EwtOwljGiKmHmOaa3PoQhh8TvvIOUA7zv7CO/GOR6bRgVycbYVggpERn J7DapWFQPvLJxgaKqY/HeIgWn3iX3xytQ3JUs9/su3/l6+h7oj5RH/czFqG8 591e24Kp7740flIFphVfs74+R0CHX4NzQZIlx6cH91pl0usydh6j9xFHDk// w5dLDROU/4s24wyD7sNCNklgzhbq+s8wCsYEsqqQkc16YS4+4hPFAlYncU3W U06l9vpd8ScH2niqkZ98uDO3M5Q6mhI2ZjbxjroYGxh1TmNvLjBVZBaUZIPO EEwYeJafIjIjlp5tbzURWTlqWQWQwjxjW6NcZ0oBr3k8jF/3m/r/9F3SWJJz N15qMXWmB743zVoz1WxOGUJWn6dNB3gg8bP6R3Idk+q3i14pu7FzE4wScmh8 9Q9Zqer+CLc7VnGaFv9MydtLk3z+JaMRLKXObZKdyYLwXrJRAgMtyMEIfjTa DybBiQ7yON8wi0cNNpRhPyyXkv9gch/1k1/GZ2ZwitxEK+sg+sqOHxHmJmfD ljJ1DmJOurgzX929fZo3YUonNgjfAL9ddlENvr9977oPoBu8P30gkl/hpvBu TB2UB676npJvrgUqA3wdoRKixTdH0IMaZTfKc5/lvsBah+t65/pQbywX+sgh Z1IBg1uXaTN34ttajl9HziOoqRvO+eXbVrPXDPK8fIX/GqDDWpxpBrKCAtbP WyxOytvjY2/DaRheitnLNyxdR1tTc71D3YcczHqlk5BU1zpyInYyOgJSrBg7 5IIE+fmz+STr5K7HWWMd4iNH+uRHxh4Kkub2k00OXzymBAT5P/mqOyQOU/sN ZoxcIH5mNSuHyv1Fw0f7E3WL3KO9lw21BDailpoSx+kV3WfM+Ja8bHwR1has MoofJ9pSDxG7/z6Pp1BDIxG+2avmLmk7IzmVbw3cN6K/Nu0RZ3Nf6pZS9sQi JxN+hBDTNqqwQuS99mJrSfLCC/LKgcCjNBNzcX2exl948cprPds1lUYNjt8F vgZuDzTGGLoS90pSOnavLAbn7IfgRJaCkoI+amckGRvlr65Hwg8RCS11o1Er Mox3Gt6ucLL+vnapKYIas7YmNnbzgUORRarYR565mpPdmJly4UnasP/V2IFx pRrbb1p3cyAVJnV+27dTBRovBsHmgL4y5YUQxNoQX7YZlRH0aqvCNiNWMxjQ 9X+SXeqHBoSNXipyMzzOokOuc9S6X/5fmT3c3jWPLhvAW+q/rXsrHTd35hdV g0i2nGGvf0a2fyhqGI9MTFZi+fkrOra1dBauoDFdxnQOvMJIEeranMpRVn94 KVhIhj/+lhFl6CIEElPisrZi/hV0PX/1mEJ/l0Cp+tZgohfOyt1zqgvH5xNG 5140ImZPcRU1V5a+W5zmfC9VF/r9L/p9Z/2oi66C++YzOWfCEOIU2qd0SdUa Jj++P/dOGKpizFRLhJnyuICMep3T+/f6YUNxxYR8aPLMa2HGYkCyLo/94khu Cx60sSLvEBgyZ5a6Rq39t2lppYGK2w/asjJ3M0AWFCJeB7IXzFrywUZrnt4b Rh8UXzNAvNYShZ0MH00/7zymd0Y9wQoaZD3YAWrqREI2A00HVaiu0sIw8Pf2 aBln9nya1aY73bstB/e42uzFiDZ21ay1Erq30IuN9GlClZBMgexBSr90v3Lw Dub+Tc4qGKceF462hhZr1Y/8K9k2Xg7hz499KMQK/LlpzbpzP4/qqEPk/8Iu MkN7NNVgYfoYo+q7vzLk8oJy1xoW8Q5PQKjouoMmmTc+H+lYjl6fF6xOgHPn NL+TnQNFtbeHx+eOXWa/NoI3LxUDJ0RYA7LWn2CGTogbBQHQWXGOCr82i/lx X3f+NmiBNIktD6lkvTli8efzX9i6aXFGI9t3CVJzlBBWsIOezMsLj/7zKvIu Wx+3m3a2EttKAfvAo5Fh63FrSg/dk39HQeXL/cM3dXFOU9h6AiHEBzG/hrTY CJE+Aqu2Nbp/PByGhq4t489pbEbLl7xBLSJ3wxb01grMMWvIh/pWhRCCZG5N miMBecASgvuR6TLhcIl+467n3lmNWQRat/a+6vosPj/Aypu9vFbiviToh+qg IUcwPQLOtdfbFKVjUYQt7WKDsLLW8lOuKpZCZwct6P+2buRdcCl+/YHhX6Uo mszt+uqiwbdOkfO/AX8lm5aviG92EieaRvBvHVs2NwnCuhjD9WmSEuCntg34 cy1HS7qrZlPOuxwsEz6DgzrlbQe3e4j6fi14pHd3h9Kazo/y7CgViM2D+n9o DM3JIqOyt+dcNPAfknuDt0Y7dwIczWrytgdHAuk+4fm2BxSVBiBXy2cuBlMe 92Bek8ou2U7BB3culnESARuV6uMnQzQUZVBOxvTJGvP/aesLicqzko54j2US Z3M1MlSroi2Wcx92Ca1hef3QUnvvqqNjysRkUbnj/iItdsKiUMpnB5cd/Tra nw7Tq/YBZ3jBe6uvzbq9WXVt87oGZXGj/EfYWh9kEOUVHn6yiH7MYR8qMoBC Qdj66cPnAnKqUou94x8p/rQt6sOk4KYrZ5PmzbgSKq67Si7nDo+O2Tu2t/sx EG1/tmr7rWoP8/9miD95dz8W2zLeJEaMEpYGrkqabvIxKjIKuZDPuhM4X8fu gHt2epU6uvLYa/79i8QH2mqAYy2252f/mGFSebZAitw2lvP8AzKjhC4j52/i gr4G1xLGGeQUKluGzhbmfh4tFq7oKCEEio3yB8wwzkoqks/wEE/qlLl9B0Tq NoJ3KnY2xJWavq3FqjT91k2tLuasK+gsJbWz0m99dTM0GBAMr04TDBE82mrD Q8hTfS4zcGI/6vo9cx5fFjfbWVd6fvz7VX8qNkNk+iVmNn33JU7rWZcm6xrS pgEqEURIzwW/La1r8+ZJaNMR8AXnqreSlq5T9QdWg71kuzzG+UpXenC8aXui S/oakmIzJC0vQLvyNlx/h7vnFBXvCtZ6rR5NMALn0eOCaW9/B90LDJHWWuU9 eKurFiHyfQWmzaN2f69wnmOIRM+vQcpYYvBElG+WScdYLLSfhfbDamaHyJs6 dJn+t7tw915huzZDwEmdc5IzYwk3ZdKTRMIddjEswysaX/LqqsGP48e7ykFj VCnFWLd7DqsAQhOyrwV2qk9ol0yJWEaq8e//TyMBfWI0T7Rvp2ANdy4RoXLM a6puscwXFwKiG8Ck67jXyvlf+xXzbg/7BtMbBBXKW0PIf6K6ylqh77YtBhfC A09qtOoaIyP56ntFTRpaK3yiQGc5z5uTXEaycLpqFwIdOz/F829yxqcnizO3 Nz+xNeEPkVfk6mhctt+izioGP+EG8FloG19ymHLNBC1XQEqWQhE24jV0Pj0W YEPltHwbHwTHbwP5un8ZFAJC0/8WEun8ZeK7TWqTcmVXrVyDYbADdUu1tbdh 0oq7Wapm8o15AhCqUieozxA2lJaQk5kaXc8KBdYmfP1cC6dSugRyN68BKPSx t2Wf1xMWwKbkxkLO+PEyiofvoSsmZOLkk7bn/RBeULu33PumApjJO3MbiX6N Y5JX8H0MQtk/Mze+BobKBPbCHKtaAbWpL0dh6zDi2lsEmleycL5AN6ASN8yh Is7qLDFVbLOvNJcOc7vLMy4mRLsbM5xTXneSMyiWq136qyY+6VsSLuZcE+U2 vkvaiau+2ibqb6vzKVzKv/WuekWbVlVPhkYOQ32hSlTyDjK41bOvJls0duJt c80TwxLHEifOcy0IHjl+s921JqEw+ceZk7AXaWlihkDykzzlQQ9OKb9oqAZF h/nUkZ7TgpUb6ZpWb4gPdRO2SV/U2q9z+pu32y1W7maKIN3gNJQuY5dXUzov Jz4yYWIDELdRxqiOy+aNs9tGNs97W9cKrKO+vYUKi7UKN6JGPjYSLz0QWxE/ Puy38F6YR5RWBhQzVvL/dhLzj+gw5Idr1PtB3RS9713n76Yungu9x0ldoLb+ sr8DBt4ik+FELmdcdM+j5JViE36zaNoXRUwbtDxeNp0DMzq/yTZC0Rgy/21A Um/AXRAits6vdhsRvlF8PMwva0py4V3sK4OZCHcXT4dTLtB4syJzI/Pmz7/2 fxB9AjHqX3M0R19nkmoSylQcOjtnWpvI9Kmu+wm2vIQaOpQvMJnohMbMaHlA /JsFCpPLUTNmisYwExzyb30i91Lz65OXyE5zigALxvpKUtosZxDgh3iaUn15 Tk7r9/LCa7bjR8sze3c+Iv4m1DXG+G75F4fHGHbuv3oyfdIZ3YXI+T8OTmHa CJv+LoQ18juXuQP3XE9jlEpgWDPkQ+bK+MsdF6vCGLgt5/3ueVvRMxNmRm0q U7haN0eT6icwJUQ9kywCTfiRUC4gI57yOsNvW+IKx1sSCL2UZbs2Vjh3Bdid g+xAj13jkSzW8m41PzFkdYa1rqukgsE4WqMLNo8XiA+J9QkTX3sd3nVyL+7h tK7GP5Y3A6W1GgNiPlgnPRdpkqHhJx9nEZRGBvlNxl1ym0+6HMqlX/u62mh/ tDJMkp9+oRJF/7uXf3YofWKet9sz7gkjjmOa9rNS4TA/P0Suyjtz6qs7asMi dpXjF0HP32BGA2eVdxmXYmUuA1z5oEMGcwo3u7mHUU+rQttZSxUvnNbx2gtH Shc9QgBmEGfGp7n611l+1VtrZBxVDm4jW5joCZCXxQdc8vYMkEICBrdWRs4J C7fpCrzhb2+78Te3cSN0QzeDXTdLYRewrdZaolXus2so6yoq7/gBm3P4ktXJ LgJwljPNvp8z4noBa6vLQ4cZV8Fapk73sRO3NZOjw/oPI0TOG9f5AuXaApgf 8tumYR6WX9EzLmegYBQ9+l2XVhVF2z23P2czZ1Oz0uWvyPagY67R49MdJOVM BwBarS+Ue/CBj7C2dkBJLj8zGsXxbRtjlvwp8hz5+G7ogFl3gUdv5ydyYmRj PU4TgIXA5o/LohLmXIOgeU23tl+Mb+8Un9WnZqD8sxabJUI2d30vIPzeW5ez R3Nw1g+K6jdmLjRZE1smgPP5wu1boG6pN7Y7suE4875CbQ51P+dpu1gU9y7f tubK6o7PAhs3EgJyAwLmiE0/gLZbPLrlJ+CD6AuzYF6fc65DqinBWpxaNE4T 3e856yKh3Furcp1zL9bbWxoE+RI/QdnHCZa3Z/81FXWLvpZmRKkuMpTBLPbp 77YWJkQzwZ6aEzoZPIpdl5bOr3EjUdvqcwWSJC5zAVxIn/71524Dv5dXzRy/ 90BnemXCI9YRM5gJf8IXowdzPneKKbvOuMFZl/sjFGv8YjGVgQfwWqy7TzJm Y+dE/bS3ksX6+YZ2ap1Vnqr0WvIylGU5Mrb6v+gJNZBSXFBkHu4RlBE0elNM v1f4k74Fdp5IuNOcu1YT0Gw2ZVBjN/YqWjUDijs3ExP29azJMlZr7qctSccJ 9mZLF/O9D8OKG3/9+K5UliQjlgeSUS1kLFeGS5IKGVQdz3KWZSqaSP6fmk+x g/2Av5J1O2j8O3S3KNkWjv4HMa4Y53ILvnP0X5XrgT53Y5PiG6AbPGSW5oV/ PnqgYHZU+4yS865JTtwxma7zpL62P2sMgIpLSpPzps0JitlBtypO11p+zY4K iscrgzR1Tu//tjVEaQ49Q09IJ2TbkEDaHBGVe1j8nsmgTvEmNnMEAtZrw9ga 2v+u8XVDZ/HCFYNqsKFydstmXr5iKB68XkL/kPXLedUh6G5ELejte2S4FMX7 VJ+wPspkJuB4lnaTjlCNnByUkbWCGg/yN4cyPyeSncHnUphbViOhE80YuA2n rWvCZQNHFAc/V7vZxVqn/rEXYvcxLZXwerfZHpbJKEMZe55SyppXyZxSDimV Z4ZX5uqnQtyyy7mzlHJhfZxDAi8Td7ZqqlYz4/bKzKtyCt0K9y+tqJjIe0K2 6GvdELNSSJEyLYXHPWnIYi1wkdqJ/Z/Bnv9yU3h0By7ckhJYlzAdyDk+Gif6 bdcJ45+9muOz+zE3lV6dd4wXG3d+vOa+zvqNy3eslnbTYBCKcgxPd8ZbZs6f wJnrwPhLm85aDsF5FNnnbgpGHlYceCovl7EU3mgYh+4fvIz6wfutsWfDmEPU C2KLF886J36m8HKMYNkOFJC39/2H0GTKGTiXAeSuzyKvXRQsvfKVXZZWVD4T wfmrju2XfmEwZ8KIGiI8BM3jr5dc1nR3gDJ9LniRgzUC6G86XCphiI/c14Kb lMoOQm816HzwNpbzSs4kLl/M+jCFkSPmx4bEAyT2EHiUNmqXGAIqLkcCBlSH a2sOIaaerNo2jyKL1Vn23e5co7UbW0dwDOsndHBDzvtdZC0EHE9wUrbkPTbr XU/KIpdi/h4lKBsO8vh8uUu6rIRhKb6Tj1zqs8L6M6MDBAYjWl06ZWrNZBPh hAJ01fEDhlJ7NCs2U6yIOv1vk/CIW2ThkpjWJmEjLgfgFrxDaVWvgAyKJ+GS zqk26N/597TEO3UrqEf+G5dz/6v/tugI2xcXTBJbZC0HFUI3AAyFiP3qbVs2 RH9mXq7R95A4Qn72+EIdHhXB7barh4o+ZbnHFjUXIz7AWHdBSq68ghGOffp7 vTnIWuOO3ZxKF2FN1Am3BF/ruqy65N6aNpeRXVtlQScuNwZmM1XxyljiWjTb iPXtd577w0j9BJmmdk5iI+Pq2lZmV/KOwxZBN7Y0o2HlkWEU2fbbegqNaPvo gY9dg7ebnGw1FLM92oNivGlA2UTIt8sbZ+dfVMM2IzBnBrcHAmKZFneK2EOP Z+5p5Fy88ZtDo8NaCu+exI89eFliCjWDcRS+unAL3AdCXu7VBF+tp1Mtcwdi +AQzpsmn/w2002ItlrfGPxYTA3Zfsx+veStG/60oHo6BQs7CZj8/hf8PcLqW BYK5Xs9Vs2dY2Fp5FanNnpqaJI2TB54St1KSmjkAxd6u8ZQfIHWNLr5YAqNK keR/V5abUoJEDIsmgl76JjTyHHOT0yEN2RlUW4ZG3go33xs8JBE/vZLHWRq/ T330Er4wwUzKgA1Zlk9JcKNBZYTdhOVX4zprR2XTdePYW97mYmMFBI8mHJmE EvWeTy8SI3Y39i4rvDdboOZdiOsmlvYM4haJu+91nCGRGMa+2moiP45Vylrx 2Yfq+hl2gT/MBGoOG+fCJ7cefsLhva/XmDQ1ZtiwMiJBrCvOPhMNPkfmSMob Iy5/6ljgFrr7XrYffq3xRNIv6zIB2l8+axt6q3H3RDvuQotcfCpCrnghIADo BpXDnRuuqqNhM1DGDZG7bhEqB9sheeJeXuDDHX1Pw4ZrtYRhcoOG5+maHdc5 8N9CS7RzNt6vLz8zdZNR3PoOiNF7AbeXBqL/Qr4S9BmBd2KGQ22ql1e6b1T/ L/CT4IQxdW1bvVKHNaPbWoD7yzlnD1mJTdbwWF8RFdTzGP7KZjkmBQELBp+c YkePADuePZVyWryaLlrMi1LEi1zeJtqqPAY9SV3XY6zjzpIih1z2p1I+WWq8 Bywz+01h710THLP6cu9A0AkrEJrCWy4Ei70JkFw8ay5pOC09k7Sr7GssLb8m sr1wH9Na+7/6lGOIQyV6nuL61IuBgR/GIs8J3iE2632UFqISl0sDzX7DGZYa xFxuhIVFDPOmd1lghlTOZFKyqzzmnGOyQMcumZGfA1ohmC8ph2KL6z88Rn+m +oacRP3XFWiCRaOSFk/L4gRyc4iE+lRelteDcOBD8/93pOlzUbo+dOFm5oRr GNf6hofg60UP/Js+3u5aNfYmLPivHp4hZgN2FGvLuUEgdR5rtPtHb43fc1KV c0bZPkePCNcDpf7UuEbLX5gzdpZfEyCDc2Bzl1zr3oj8I+SEv+fXsXN+8kJR kiQwpf+ykz2SoGO1k2iNwlesA89b+kfYdRP5XNpbNl4fDeK75Mj2XoOSBk80 MUeTDP1GWmZxeQeyQ/vomEc99f6u+pbG4j4DhxG1+lfKRODfKmRMHnKRd/m9 i558kXEwPm7YXi6gUujvvg+78QMWRo0OmNf5vrdxeYkaT3djMdlqkZJ1DS8H PaC3pq7suzDxcoifvjCHYuX6DAKMRq033v9+bm/8Nt0ILKAPT4ZDxtsIr8uf 1dvt8//aelAGn+izdGFeGZM6skBceR1fupv/czXGj8PmAxVGYWKXhu4XpjcV 7B/oI0INs+FbRirBv8t6By9nRSv/5kYNKPUKiJimEpuCcmGGDkMADkICIlJm es+SbMS205xgbk9eFGgaIhaTKixQL2F9J3mqD4Yr8Wl6qugmYUgkM7rMoI2x nkNxGFuurBIIBMA0ehJDrh8DPInrfZBMVtWXVO3mUG8T4//6Dz5N3fIC9rL0 jPMKLJ/BeYmyEg0AUzQnCs4fXwvu8OPbVJ0GW1TTJ8aJ3t2m3F74boPH6bvD WZI/rrk3I2AP5mGTxlYKw15t7oizigtMJM4gR177amZhYS4yyZUrH+bzomGp bFsKO+itG+afgrGpwxY+7pB/Us2ph/9Fvfvz+56YmI9xU6Lrk5t2mrJPcijM Dm77k/5ixmlmc2WgBhXy4lgW7I6zgiOuij5kcyPbrjmMdVjabkKR8kQqMvWG HMfmRlSOX/AnL7eV6H7yIo0dhb6wdWpPnvNQTSMXb+8kkz9cl5quKlzLQuSG zXYalJqESz9R+0JLoqO0y6373xHFJuogb2vP/XH7SMumUVlaulIcsm3aECP/ 76xwTptctFt76goztlpQlzD+/RLmJrLk3yJSh5PUA9bks5nerKkeMtwLikD+ Tw/zCBeJEaCZclmAfncGK/vGaxirc7uQQEvd/hNi8H5dDYpyb6JTDo9fUcw/ bcKmgWna6APsNzhYrh6aGhUQOcMpipZCmsYfisfIM0IYt4iJZ+Slj7YTu7er fHnWxWpvyWqXM0SDJpN32FpQqJgcLOumS5c0WBojtJ/HR5rtMPwtcLJbotjq eRk380tSFlmccm+RTPJmazfGmpNrd2SrrY5lZJvyG0RQX4ymShaxuf/dcJkf o76S5ETStso6vvJQDTn3y+w5R9vr3N7m2qj+MvafjUlICBerT71QjNzqkhvE O/4droxOM6Pv/4P6hd3CIrP2yMiw/Py94xnMyIj8IGBhoKBiIWVjPqH1ycls 2SUmZiFhvPzyi1cKPUBhPSdPISbg2wKgR9COT5CTULiHrFygLOpIoqOjaZs+ IQo0M1oCnaiG9wChz4IsGwBGk/h1rxyUtDSnoqKjgdV2BliDM3+8d5Fmh2s6 3edBnbNz9pqmx6IUaOycrLSioaKjsGnDAoB+JeJ+mJjfRPqxv+dnB/RndGqD s77s6IxsnJygo6OjS7pXbTPSanBB2f5Id2Orv127McdaiUVZ3DfNQZpSFHi1 7Ue9Ex/g4+ggoNMcv6A+oj6lxDT0XKW87AshpTpVyTnQiYxZpCLsyEg9ogpW XywmY/9MPeN4wsklVG/A3aYg08ikoD6iy7AvFHK0/KATpaCikV6luSEAu3Mv QFmALmaNiTssXH+YoKCS7IjthIJMQofVtrc93XT1z58aiWQ98OC4yEujo6FG QgbrlUdKX3QaBusqr1Zas5ySvfxocnlU5SyKvKy2wEkj+KSGKpNqskxsysqm s6DC61aGhFDQgKKgoKKIpbVIr1RvSm6eQp4Ic9uTTM2BQoY/dp7tN0uMABic hKOhoaJBwiHXGZHbgo31RxVx5jVFZsXthQLDceB0yaZ9fpQUmGqgoqByZFe5 uESEQExMsD0+Gxssd/73e/dWWqx8i08YpAgD/6v3I2MIRNTM1NNN2OGm3GeA SKHCTKOZspxy1AEjqT4XK+/VQNgXG5uCZ63vhPbYCKLgi06Z+VWJhvweo7dq UELDK8hFs86fdmpFqFp8YKMgwUvqpCje2X9yuo9rtJ195rSX/zKfx80mMkx9 cKewFKaZd4diMVkDePcT+GjcMCGnoKHD/A96yUeqiDXygYPyeVwxoNZuTpOF K7KGbezglLegojSBaP3QhG/uangUT7+YUAhZmusp2JBs+JxMw02/iTw0EJTs 6NztM6I41MgwPNAYJKBs/GwIyVVS8Pz0iERUUFS4XGjgQkBEvESgCCC0KGBl YGBllGW9+WWt+klKlCFpvaX5nYGdaZ2B7a2xhWlNs7ywsC2loelN3Z2ZmaGZ vZmI3dk9eTndi4zs7YlMde314anl2BXhjRXlFBUVedHJuW15KSnNJc01NTFV bTNVbRnF+Un1IW25JVFVYLtflaGN7XVBRQ5+fQWuS1Vll+Juvi6enoKegvqC loCHhknSis5tgWpOzTWytmFipqQl7NCdKYq+BlZO7drU1nLFpaoYlagWaKS2 Ei/GEQNeOjbz5gDkWxEZaoLDptnilucfehLEHupSgS4vMhIT6yQdAi+i0n9a e1YYHFnKTnjqii6iBl4GPioyIy4iVhP+vjZfHiRr2M2ekvDujF6yJqIKyl5S qghQUL462kqmVlZW6kY2NkK6zkZeNiJGKiJVKw10oi6W6GJbZ2t/rZNOTexN hUe/S5Kni/ejq/KP8+ei2xd4yizO07HJyyfCx1OnZLvDb/hg+PhMT8GsyOhM tNi1mPBolLx3dr0xBM07qESocFCEtA+/v478PLyAnMikmaOgoaMn45pqbL97 qW92/NsjofssqutfbsxjsYC26AWDaBXHfTsvdmle3M/GoDAwlKOgo6H/lw8/ PmRs0wXx+jQ8W6OflRBIjqWYh5+WmTgIuFDMAKRTv6N0z0QTvtyHt093YyP9 ChdAtBmog75foZx+PrSE26OgoQ59t2+Zt59bRdOpV8eEmgR/8EyvKKGi4icz +isr0yQactujFg8SxJpmj3n3pcPnKNHBKoGa+AwSpnuko7xnDp03T5N0gY1H yUfwNZV2z84G39isrBV7VL8JE6A3cdtaq61VakRI/z+moFOrpraXjjm/mpR+ eHFlLbnPA3TMiKZDvYdtWpsPH3QE+dacSOU0t7Aq8tzYNByloaKgFYkME0rm OADwFXdhxBeiEyTplIYbV7ThtDURzdcAuKz+3vFNHgmOBbr9RCDpOfiZohmb A8z4RtZxtb0+9ZHEF/wUmP+8laBhJP2U8M3BCf6KwNFFyaw62tIN8yz0lGuy D0GZWn72dAXMJrn1tz/c3xLXp/8i4FXYJii7b7P0UthGT0m1srAu3PC30ran d/qsxFO/g6DAB9Kso7xYS1S1r056gCw4yGTuS6CjQxOyHkBahOvbh9nH1QRz LMz9ipOALuo5EMMMAMR7O1mmU/15azbzUOerrDNfe+rc9MjDkKejQyOuC38C fyYni9u2NhYvBdT4JHCio6OifgtbY9vfX3r2whIBX232yWc/fzMP8/TDj1GF lEosyPhSi0+jW9+LeQ95jasWAVyBSxn7bf+i97Go7NWpoaOgTBaHZZR/Am9b e7PwyjfHb5NNCmcDiGQeyEiiIxuVqfDrr99rg2d7yWPb5E/9KjZ9EYydVKSi oyui8J9tSvYbNCWTDskHQcP8T5hHS+QIE9ie/5PuisYL6l5yP3Kxa+jZAnxe +Fql46uP1UEZhJYyTLfzv2vmGjLZH0yUhFSjo6Cj9MnXVbqzakm3MNnf9nHx gmNyqlcpzmMMCGXHmZT+XK+i4rdi05x5biidPPwsY5iBrA2hwcVJQbOFexsd FcsElATO+UkMRYzF6Jdr1HJDGznR/Wy7bNuDcGcPQjjlmwYQf3W3+zOh9KxF nKOjo/9JPWYFYbRNhl+2QLqXGbTNTB29fspk1IGYQPXvS8iJRgqIG+qdR7Mn 5ombzxexUMOUxkpEvOAYLSM1T3UzyufEw5+PuEl+ICDB8Eyg60oCCwITgOfX Po9/BnccrLTRfcwGRX8ni6Odf00EMiYpoAFUM0/26+WYCXCgoEPQSbCP+9VU GuGQ+7GIOry23SfAEG44oEyUiUygonaY6d6jMOHyn0CtSKP+5njCJ63NPX9k ns/cMDQyoC4yakDmOhSjTdtK4ui7mBOkaZ69b+HZsdyEjBJLoKJzCPjaTT1+ KHIfwDci+7cMFBYqgoAJnSKiFkVyF4CAD/1I7Kw7S6OgoCNnnbxa6MFWlUxY 2gVoHSKWyo+KGc6aQg8SvdPtx8mWpLvwX2ZLA0wTYiTEhJuhoGtQuheTOiJ9 qJfbUXnNdXK4pPyqTqOho75Qrt0SJbUuNOAg4nW0htvbHBQDkEWwrM6ne5+5 tEWa1klsTsX66l5KPOI+249Ovv73mL0wpJzYVKyOTaDKZav7IyFz9IOORAJ/ v4N4ugGxEfYQXNhep6Gh4norkNJhjAFD1L9jd4/Gd2IbgsNgNaf5rPMHbhDa IpOr4rjKJbT84GivRmi3ioC8c7WundrIlpZsViMlonzeEM//mkPM6PDuxkqh lFv1dUL6BxjxVeD9zwVCSg+2JSjwQLQwp6GioLW6uZpluhK/HVBoTzK3mQ25 eA6wf1vja2/wfk6QjLAo7ktopb6FsDYq5ncng3yCPWAu41LSrkwlAB6n6K1T cobTOqaawraEnJYdDqOietoyntQB9rWVKZJfCX0f5iY8edsmc5QjHcUv5Pz0 VPSYFBwpzjIp6CRzROgYxqYKH5M2c9mOuMv4xEDIvFAovVpgZdMVJQHM3JWu WZglspC+Qb050f6VSZWbgU1NmbGxgrG+vEmVAd/VxcaN8+cR51wSpTHx1CoF INjRaZmQfGVhfsbeDK6s+rayLqeenx63hOSuih9sTbKgUuIIWtKsaouKmtMy 3sFyVXs94qW8FuAonpKiSosfW1iD1zyh4Y6RwRiahxqE2zheOka4E5rvm7C2 CqdMkJRSoaKjI8GybKdjk5tjc1u/HsQXQ6/7H6fTp36I+7KRgOBPMKtI1Zd7 rcrkNHBMkO1JooDfPbaD28OzZ3dDI7sXPg+LA/mPi7JggONbI6Vq3Dzrs5+H Mr6ET+NlksQcoRY0p6S0rN8vBfrbyD+9YrKD98goDEzUpcPZGNgUlNjkF3oE ByToN6RsmBgYICAcHCLKpjsEFKwwmLxsbAi6Jldn9Oyu8nS8lJ4NcHW4U/1h fPCU+GG8ZAiuoaAg0flFEZTpjZE8+Z2VZZ2VlYH5kYVombNJGJgslPU1Cc2d vU2xoKSJPTlREew+OdCd5GhWTiXOLRXU4PX1sb2NHhX1NWlhUfLK2eN9pDip EWn05o2jbv7kQvqpzNVBwaUBKTEpzTU9VM8VpW3J+UDNHf1iNiXI+ve9UToV 9VD5ueV1IbldjXXRdFy5UbG9RkYVRAX1/HRpKbW9dFgLKHRZAaV1ZXFqZTWS SI7sgY2uMRUlmcLBvZ+3lPYUEoS2Gpi8mqfpuRrwsrE6ot7WFsAy9vXe7ppu wfTa9s2l/ep65kLiFqkto3k2kqISerbqGiAyMMyu6sDeEiaiJsomyr5Rb0FE 8sr69193d6/4Trf9m5sslBLNp9csoxeGHVA6YZiey3unIjB2Z8xnNJufWrAP ZW/YuFJ8OCaiH8LHZkmRCDYI7Ge0aJnLTLfB5Za+Hz8rCGQe0DSn46tMHX8y lW4W8ME23HcaqJ8cE5D5M7JnGKRYm6Gho1xcflurrbx18CqMx59OaFudmPeq 5574cGgjA6WgjTMAIWM2nXArzZff4+gEdhqfHFA4I6Sho8o8DOTjqcth83t3 JkPGfRFhmzKEQMYQGFD0TaKhok97fr3rTRVCGT+2nELhLfkYOvOHgrzYkxzQ xyMwqkCYoVO+oUR7fhZzBhmYA+kWspi1BFr7dicggZ++lyD0dnOjoqlz6d1Y njehsWN/6+AZ/BuQnaMDtCmxSAc3i8l9mGgYkKOio6CQyYhZ6yUxdqPZnhuD Th5zpQitn25md7+cjJNopJXspKJDoKL1HLs4pT/nDVMFHsAtBnSjHAU+rbd8 gTOePA6/nMnfw7WsIVTASMRUDNzE5IywLMTsiMDsjN6m9kxEFMiM2BQUyDAc AER6BDTUyEzoKAQ8yDQwQOjIVFwkALg8zFQ+PYJEANTkGAz4KCRMJyVw8NS0 kIhsCMhwbWJUX4JmRWj4d4uwnAzM12xK2ARoDLSwdXRid/lClCEZWwyQSSEy +dk51YC1nZ20pZ2GmNCtVDDlIaW9oYWE1bSxmbX9paK1Pabj9KEpwO087EHB wfY4Et6MNVX9vN3tfenE6fEC+Yx4VOVMVbEB7dkY8eUd2KzVjMzxFSnlMOF5 bXl5eTAYIWgOfdRxJZ29yS534X3SOvzihRmikUDD+xrvhu62poYKtqCh7Ewo VmXoporMqNPRnMme3k4GOY/SPhyAxd2l7vpKQXoGjTo2GuEyIjUeUgq4XVYG 3t52d2blWvqaLOfbeeP6gC+Htptrh6SEak6gI4kVh7BzL7G/s+0vt9Ezv94Y oJiBxwuhU5vB45vBi0/BH6fHA0qLoMQh7LXES//DndPR9cs7s5Y4O8Ly9zho Tdz8o1C/Uzmjw4536xNzj6r3qvJ/92Kj89AU5BAcp6OjW4vijxem58ukExMT Dy8qrxPm8y/ctwPwZAEonttIK6POXxvRvTIbB5n7R10HaHx0R7enolObYoxf QMj7tWT6qVCwYRejrnkUGV3AWbO9oMC+RL9jaPt0MYJwlLqygJiikKejv2sX CVwaoFsZo7dboJ+WmIHLjFgwPKagoKMzK5FTyEOAHxlCMbYQVcDnBPloEmoA lDRqsJ+btAwokKWioKM/WV/aMftbhW3IoA4XDyqeb+yCJv9Smo0unH54YHj/ T6GhQ0+BLk9UEqhf3oErFUULNG9wq/uwK3QM5Fh4NAyioaOCWDe0hRyB3x93 TGRt1p1B2CM2qK8/jPD4WaahoaOVDyuSRCKEh28XZmmi1EXK5ucz9v1zeFhR O/yxZgSn0Ir2IfnUdB89va7iWH/bGwswuUEQTLjko6GhP75MYcR9u4mH8+sN Azb8MfElm2r6WBysH+5Locxht+lkVMtnvvpVKxzUJ6Qjp65OF3WI2jJgqBHT aRIxkakA+JChoqOgtvCFn/9QSRbZnx0ufaaBmBp+HoKvWKA0x02hoE1URBlK /5dtFoMlTEKfsBuk2EUYYfIlGKC800mjovx7zfiWtv8ftQxNpyrqRzDNn9l6 G/rkg3W9tm1tAB064p7Oh+/kGq9wa7iGOyDXOEbbHlZi4C0cK5c0vlEEKs90 vFa2+OsedcseSvePjh4CL/elK8mj7tmc4nwAhtLe+x7zFcLfxn4Mk5r8vdh5 lu7/h/PRyc5oSqvApzOUsWAEhKhuCLiY6qeAhIsdv+66ErqgxsY2oPHE26U/ vrmRY/xgxK+Lt8MXIs/k8ukAmc28E5yHl9e3P4ZIHrIInlyikmfICjHG6u7D il4vvqpskavKms6SGc479u7ACP/yrrOG6xx1GX9Q4/VPvgEGqPWPKlPCbGyO buOsqYyU4tfLf7pe9/sDY+Lk4OfbESoAhz+3tNQnhlI+D58bG1+P4/LAJgMM 5Dm7b7PEA29rVNAqtEUQK6Knt8r232NG72AJfUaszHbRElYqhn9ncQx1Ro50 ixMGRhqz7gITTrT/wkSatRl9BPg6L2988xqeoSqIZCFrqspjmhsTIJA9TMr8 awOgUh+oIgAfAqICqEEWaZJsLtOP/kBFWToTjnoGumxzKfyBN8mB09pb7O94 TkZs32FTNn7/VioKBZA69wICMHZ/KX6Zcx5vzedfdHc/tU5RLtPYB6U96K/J JqAyUSVSo2fwXrf/l2OR3NaJH/8jxExy7qyCLrLWGtMD9zPuH+dOw9MzjDFK BeiK2xvQ5z/KozzSHkpoU68sztSLhnhPdvanUweHpNRIAFdSwkL/GuUmIwML B4oK4C9gva694wKYxWSEvtRXWr4XamgfdcwPipRX5nKjdzTeIx8s639i8r9y Ec4nQRQCTpjD5GvLioqKgWJ3Crpisw66W63LEorRd4t2Q/7wFC6io0c7jzK2 b5djZ0o+GqerPTUXchdzWg9T+GJN58uJ76okb4pamvpnf2kpPLCG1stPc2uz SvtDGmu2rytnaqgYKBMXm3fWFiB4KLefxi9zHAmbS5KRHq/dUFnkdoDeWNci aoJ+86tk6iaYZVICo/C7xJf74OdbwmofGILA3Wyyg9B7jxdOjOOqvUv7/KDD P0yt2uC2WAFT24J+I0QfidZGenJUTyEKWqbApv9Da22l/6dmJM4QW79r5uLB 9uUk94zww2pjvwde77b4dgcEqe9jLuJ+5dZWoa5l556MMkknWQAe8kprko/Q lXzrhiOEh24ZoWTvCWTDTLO7ipjEdLcGnoKVs3rw1+z4WLdc/YJAm8Vcjc4A QuEvVLfbSyTvGqi/PR6R/oiTgzejT9tNTAHz1o3nH9+mp9lrGtNM+2PcGpcX oNND/J5Qyuxp+py9cpYvNnkKPRdAVfKldcpX40JIteH4C1Hn1l9JD1Pz1oo2 zg/Pr0TR6sWHgkD6XUM/POLxL53DgkaDHn9+T3b5/kN5oUeHkOKOoEy/ZD3+ d6//KH0ORnps3UBwwyoga/ISJi9lCJJTYpdW++FdwtCASybDqqrOJCkG5D4i V5CrDuFq48Ac7oizyViBPg6tKZpEdaB6xGaVr8LHO+YYkV6jrswP7dj5kmKB WmQR73Ffb81YTPKdtDAcyNqpT2w03xy1f+yULzv/tjiSMBq3k7PkHwDt+vkj nx6Y62VLv+Z6aAwmNR+G0twgPw8vl/zmxWhf9uen/4Ngwhao/FOXw67b3sfY ADeUjEyjOxqvg6Lfn00m6QClwK+BXCAU1Eqgo6I/1EiNarHDrgeGFDENTo/Z I+4znp9QbUkmPOSZ/Gy0+KOio6LhCV4/olRzOoQNsLxUzzNuq38YXlDghZYy bDOO3OwsIKSgo6Jlw9pl4xxC8GdRRnulEr93m5RRg/HKXpO2C3gpCNx8EKSh oKC2yikBmW/p5ODyf6Lk5QlJQMuUTD+HpQCuYQG1AE7IzEjg5kxX4hbzxiZl Q781IXff1uI+NNK8hvAwGHSgoqKikQxOBqbcXjL7ttmNfQkL9dQ/JlLAP6Gj dpoIhYgU5CykoKGj/Khc73WUlwiMzbuwOeGSWQH0j2z8ZOrAG6GdQIEgzHil G6eiZbhAttcaQl5sQAu1Hq7onPoCvbHaEsHfdglmc+ckYLFrT9CdN7g0jRKj sb3DCjNbR77+/dibcrd9Wq5LRjIu2rOwHH6UFciGtGEexyOHhyrNZhPRd5Z1 mgH8f33pC5q7LbDGca8mFwlyWSCkcosZhrLNSFptU1mEG53cq+Q/oFKCRkcT 18eHve+ts/MnKfT0qby6qz+nD5g/2vEut39EfzmPO0EH05NLS5r4r97TG8/a 22MDbvlqrGIeFx8qGWf3bJFrm/8yzlq2FjBhtmkEoho7MF1xXCp3SvQ/95xw j5XAnfWasj9QS9+Sco+Xj3iBHWKfVwAciOQ5EiFhvnm5Ah7yCU7t5QIfuwMj g9wWMa9wb1C4+P3fF0CbjZVxjjoAI7OMXvKXc89VSu83KxyLlAxM4YmqybwA HLnpVVqx7fYFuQEeEjFynb0GHroCwhciQlnPI5dT+ezUT4uEk+OoXPOXc7P/ zyZRKxyLUKys54vYNxPmQVmuTyx8PcdDABDUjhu3XZbk4/iycetR/DGJi54s US+Dmldego7geFDv8U6h0+RSQ9qrwBU+COXTYfq4VWjIqGCOTKOh4vT1NTYd Nw7Mz92FUGLPxFTUzgAMPYO7cUAskMRIoaKh+oiL5aCBy8UpfstJfzBjwVLz GuEQgNvB2s6gpEyIKFS/oKCgVi4xbORl6nSOrmlys0W5ylqiHBYwON0e7hae 6PxgbbSjoKLYdbvLrEyIDNbxl55Lnj+KP8hnepDOojwM9OROoaCgABt/zJjv qA5MkIq1SHUQjZHrPgGN98hF8bBHlNC4mziloUDS1BY2EEMwUzxMYgtECbmn WBcT4EQAOKAkpqKioFmjWkT5RTRho6upqSY1sfFAV0XRCWEp7MfMxpwcgJxo oqGgoCHbQEiFzgKW26vvio5lrx5BL282vYkXKOpkmmzArNi4oKGjoJnvJ1hA EmJp/vtp2eDN8MGt6zSlIPUp3AYbnIDc9sVKoWgVfx2fRLm4YhrXkxakydER gEPefaSGalicbs4v8mcQwBdQvKNCOkLYMExlGNoSDYQv1TC8UraN+7RBaGDo rKChoqK42TNgecVeesJNkOyHONLLUyQbnMq8Ro6LXJDqlA3RRL6h//wb25Fl LTgT0Rgb4TxzmOnI/EBEur6hoOEksFgw1vRCDxQcHrfvQuKpgJ0CLGLfJLuN FLBMHMNIo+pTTPHNlpQUn+6QCu3jtH97vLYAYaBKo0D9hz2S+unyekaMtuF9 cAbcyzQ8CGSgoKKhOcjPR5W4FRlBWOGre0WeQqTxR7dKjeE9UqXBExA4oDym oaChsd0R6NhJVEk06ZpXc9j0xaooFefvXMxyB1Rqs0UI8HCITqCikzI1s9I2 cKUWLq4cuBM4lWBkzVO9+nEAiMARpaCi282riGhxYP5yMICDHNmgJkq2hnht XRjE+9xKostOv9jsFV4fqGDEuyimPhZ0+1XTvFqQlAgApqChoODMwcHDiaFn sKXBakRh/BgCNWhBoXFYH7K0XMJc2MgIoKKhoNoq1WEARIkDb4OpT5DH3IRX L6xdkFOQ48L+sMckOLCYoaCioLLgGiUMIQYD5mHm58ZNeqmv8iaVVUwG0ydY 5jboHgBYpSIApSjDlK2xg5DSw2yyvQdNKafQPU0dlIjwcKKho6BWqX6xFPQJ A6RAsdoJfOv7JVzKUeEiVduczrgB2BgQUL2ioqAxeoyRcIixe6v7bL7GDBJP AoT0XkeZabeWoSgN1MQciE+hoqMT/TzBucCVU2F0dAmkKCrHiAjsICRUrg90 cIS0NXDYxEl8pqLyVHuJn1U+rkehmFAC3e4jxeeQgsNEALtqmqJTpP0XZKKW 0K8EUb7ATaJJoiXOCHiIMsJZphM+sCxpOBj7PIhyCUCqThCmDbFMZ7bznTg/ 5izGbxpjCIB4nFO9o6Pi/KWUFnzkClRAVwCXIKP+0UXdWYmJBE4k1MxIYKGj oKD1r3ukqdlW8dXR/7XV/v1x8V8oN/DpscRk1FuqQGR4RLyioaIkc6MCXs2N 0y71OPsasrVTem8rEeQRxU2QjScIrbNTPCC+seywV2TjscjzpjiEZDQgjM0/ fHw8vLGKI+IwtOosFr1ci+drrFRLZ/TJ9zg/IHPUascso/q5j+3zmJsrFhTF WW6iUg42zyoeihjiLuKwlEdKnkbKXR6YaDIoB3X6hmQ//x2tjp/sXvlDPENb 1GKvT0vXG0DUfbc/5pMwemLupfD3A5LEYWcmkNh64ay6oAAL52uCiE2Cd2/i K8gSYketMM+Yl/taluM/cFNyCP4Ptr8SJrcXW4mdMqVua8Ecuwf3toXwXlXK NxRoEgaWnQCYFaoyhYJX7RD4Yh4nhuIeV49pEH4w0vkf0b02hiGX4NaTlMS/ s198oHAI5q5hTA617tC6G3IaiOp9PYKrgsbsfpOujdyY9NGvKv5FHjUGnvOS y1Im9hA1HvYzwlk2LDhU8k26qx/WQtAa4uoDAywsiOKtQJvWOqWIq1LH7mQ1 +uqWMCO2khfqAucu2t1S9/zbTjxWGM+x8ljqpO8aAJE85I51U2IvJr7np6vi SCJe84G8x/XnSVc2Ru/fN46mQAgoq8s6+1bimPg6zjNEKvKmEup0jmVolhfE Yo4loIOTxedSuMxiGHdIKkNh4trbWjrPk80GL2itltYO7RtOd+aJA4fpnrQT T1OIt2k+i5LSsDGKFsYTZOe57C7L4vHvtoSSrePdB0z+NSppDArr1y6yM1Zt 3kgGroVmfJrGG+McECCXGpBLWPK0ChMW6i428/F3VRhvjSFV6vb0r/AmM6yt 6Zti/saeaiX2bz51U21zqj/zub88VNNDSydVPr6to2N0Jz+6MiOdZmGaaZx5 7ZM/RgqaMncezrhPTLa/t/Fc8JbPAyMCtqWLbFw9GlK4vHjJL19XTxonIujl VWMRvB5wBraTLkKQ/612vtL98q91jujP30Imsv/7Pxe5mbUN7i4vU3waZz4r 3x+SyNt3PMPzrx5ZZP+Hohgx/ALlV1uBJ5ipzxg+qxGN+g+94wc/hxO7q0U4 nZZLw6HbJi8FPxY9hIOORzN/wk/unnfTggMeeWeRGaS+DHsyGocr1hw3jj6o zCPkrVNqm1XOfK2R0xbEFLJF7iI0oiMD8RyPlv/a8zeHRNTEaaOit65K1tru 4zc698PfDbfCgMjhKVK/wupHKDbelqtGVi/yE2rHIsWKkwbtPAO6JzuSGvGx X9fJNciHuyUELi8EI8yxF0sbNZ1OT7+9VlKI3KBya0ciK8yw5cTqp8MDGyHr 9PXde6NulzxvKyb7RvOTycQa1NeZNHNuo6a2YEy7XJPSXs+GDgisxmqSzh+I Yw8Ph3QLH5Jg6d9prnsXj7fTWU7zaLTA+Zr5TNshvqIEkMtyizcOCNVYvvxr J1eGaJpPB6rw8jhD+s8LVP841mdsaWci279kk0VCdglUh8+jZPExNLc3c0x1 R8tgI4val9Mnl/lLacs/W/JH4y7H0xHoJL+/vzMYRw42hUKMXRjngHO8IaBR +H2xX6NBDTwjoVEM1ml8AI5XHcKJPG0T3ath7X2GHXa8buamQOsqcUNBL/Ot 51Hf7kEbb3qMETjZWY1osPXY+qM2AEKwMEzw+kRLz2xTOPOsdCUTphtH3x4K 6p0dOZToAr5PW2QeP+9Ga/6/2hI/ilyCebK4CSIsscO2B4bt3djztzd3YC0h 16Q3CRPvpqZiTx834/LY645wsjUDw18z6Y6p5G7Ut5NG6fVtxCHoHpjKkGz7 srYqp/MIDr8No8WMG4b21dpCDPZbQqx38C3Kvucuajqwb2RerCy+do2eBks+ 51udXWZPI+0d7OKPwqttB/e27zPHV+ubdBqU6Pn3p7F0GFxztrNPUOoiXIYy d6/ENDS3hbOC9Pg8tZ/6lPg8tK2SrUmgGR7bp1LsZFkbxEhAcID4hJRokEyv sEu1ZptgzkkftX5AEiZD8Keo/5sktWG8gllgsntLC6af3+V4yAj4ZsI3Taef 3gfYW9CTcoxWmo+fH1FL7Be7rHCPCKy+oY16HLgBHVEpnu0VKR26AiJxnd4V ugIfuwt/v/8+coyX8ASwpdwHU0hxjZVxvo/oR/tKco6W3xdTW6CP45dzjHsg cp2JigS4AB3hGWJNjQEdugIyQUm+LboCH7sbc5/tFVKrlOsAYEzsxxcgdI2V cQ2f3BcjrXKOlg6f3xdQS4+Xc4+bjnlQWHy7AFiw0MUWIXEFHbkBkb2NeiG5 Ah66Kp7u5elGy78DH4DuFVBIV6B9r1cuV0uae4m2Xa5TpxqH0q/ft0eM8WNh d7PG9ra3JgpcfWgOdizszKMGr5OfQuR9V28b6Aqrsj9YCUbE72egx/ba+msO D3ebuNTwS85H6gsPTnD3FwuSOcA7lEpX0qrWF3eeGy4LxrJ93VtgBn4J0xeX krJyq3RHuV8Sl8TycNyGfVCt888V2hu/O3SYhmoDk8rvenOPRUeFQYw+k0hv QNwmRqwBYxIWA+7CW6hBW7T49IXe+wfrQx1ns/f6EGvmGFbcaK1vkLObZ19o YLOvrpRxSF7+Vi5kaypUbx7et+JiRk9ma1iGgE2vEntjq2Y9ngM+xiOvPgoA c2hnkc4KBMNLNpXw8aPwz+ZDrK8qXa+afdub8IfpuZAXtvMWn92TfqqQSmFh 3G5iw5AHA6NrzZVCrLOretfba362k05htvSWez+Ug7CUtviTJquLW7uH54SG m7FvTuk6Dn2zf2I1ZDkDn29y6Oh4zpvHr0dDLmYRmrOq3q5IOmMzl3Ldgucv Z0fC7mu0fmNFfLtKBYqDfOWquG/YdJLI/r0PGz5mNp93aj6oy7UvX2/L4t8T 8T1kW2PDQ2ZRt4NlRsf/y3/x/VpnjmyzO4Kv+mlkgQNUWuw2F+CIz56Qz/jJ RmsWS2Sqd/Bnx4hHfguSmUF5FffvFCNWf60rbR5U5ydzAmVStCjXM7LNt/sN yam2WOPBZw37P2ZE5jmbKjUHs0DzR04UZ/uPo2xHYvO+LGHBZPnr7BdXV6xK oRqWLl4XI2QZppAbWrZL0AwPkSNAG6fq+oOzD3esasCFRnn7OHaA8OkKxUfe CuIPfke4aECVkkfnw86DyoRglCLekF6xvrMi0cq9Gpy/LyUmrGc9fJBT3iUy kwwOZySiAXa/bn6iI/ZT4+EmdmdbYnL7WaMP4CVHYZp8GDw0zv9nvCEg16aa vFZ1AaM3i2GwTssl+N54QGbj/5Az5p6cb0eyoGb0mmNLWPeOcK0so5rvrHxJ ja5MfHSjS5bexW5ag4JA6pNLFheKpyK9zwAr/hMMP2LDQQkWvv2bbeu6YdOn LldfI+pm58Ycji7++9+P61Rs/f62rdgs9ugiry9DQ1H3bkNNxKzIWKCWdbyR /zMzS6CyopfnBljzoQU696pPZpNndz+eqznoGNiHB4GC8qkcbC0vTWAD5fqF ANtrj1YHiU/zLUVDR+AGb/RfURD25ObJm12Ppt6zwNk/LLE6r4db/zzc3u+5 UOun45uTg9UKfma/m1Du1euZ/tWQqmjankGu4C9Q1rjCnqVy4tIKGeb13i8d O4jTWuac/Y7FAkoDudIAsvPomxGscutmTvIPBs3nrrUX748r4rdeDD1U8pxQ Tq2QnHi4A1i0vEzd5nkhKBy5AUFYgr7dsZEdu9oEIseTssq3qi70Rx6jPnGh I5U+qBCz/w6CKc8n9wLeCsrYq55wT9HbqPCoMgtnI+fNm8PRqq9ygnOjGTKJ zxAA5ppWnbQjCTbj9ksrr1Cp2PuTbrfbitiPVw/mUqd2cme3Y3/TkkiHfjRM h2dWnEi41zcLK0aHS68PtLdPQncN/hOJm78P/9ZYsvrAh2xotJCDtIKH3sPJ SY3QpsMqBieTBeaavPF4PwKhSJzP81hrUKq+6l0z6Pjmef4+JYTbWMR3sEpU Uvgrv4F3g4KqwQspFGJZNEPyULTXjVbsDoo0r6xQkDC3HczLj21Ofwcjqyi+ tWG9vUW4GDR4SBmNt76XVuzcHXTvvnq6MpV3Z6RrNzv7Fr9NfYq/Ni6km090 g5ib0wv7P55MPQKLUtLvdLOQe/ZqvSzZP7ZvkFQPUIyfC7pKXTAOU8dYRjsX 4CcbPQAauKu/2IqReql/468QvSOIu8/GuOe4ywp6uExOXkYaOz3sH5veI8Ip QoDZH5gbmNNdU4Y72553MpxcoZqVs6fNIgBxjiMoC39P1ywcVraSSfhXrmeF Vw5R5giKGWst4XE/cmn7aQZHoTcp2dTL/8LVYAOA4iIjFi2rE/dlLk3TIcHf qo3DG+sVKyI14m7kdsJ0cLAuQ4YnURDp7aRiGCDiC76Cul2R/Eh1i3bs077K uEJ3wqoeFj2zl38oykiDeEcpXfhga8NZm5ky+Njx/JKoGiBemhZaLtT3Z6TC g4OBIynR1urm8+DcSVOezxLu9qGNelvaGXRMZEPIipdjg1zb8UOvM7S3y3pp GIWeKldu2Fgh2AmuitImngXmxQOQ/54OZqjjvRdNv2v+bf5QD/zr1y5XiJVe hVFKWp9fDrFXu3abZM9LUj/WlZ20gu6W9+6kP1kP0hKpH/EmkHBoXurv/kdt DukbloJCKy/WEj+V019l1uMwQRu4mRKHsCgSnZP/SsowjimNoxluLBjTpJVV M3BezuTaDUGuMlkUceaGQEIP03c+tIQiMrETR5AODpBLWoZ+jGk7qr9Tt2qG /YTSQZ+LuJu7Uv8yVPalI1XytOwc1IO+Afh3ltQ4G1Ga+jbWE/Ha0mBGm5+y bYaaWLBbUqAgQFuevpqGehLOd3ks5kjtk/OnBgpfnur2eBl8fz1ML2M876IP EEtGtqb75gPmW3Yqkx779UkZGoQfIsKiT6kGzoQyojbqI4nqFLKnsrxY3HKb 5ftac4m3x1peIAIrYgIb5xoG/6TDIAsg95If3rDcUshGAlLWizE+Eq5j+J7w M6JYkFEm5bI34/ZCjfNdiPZCytIi4t8G56hGmHc1gzYv6Hry93o3FLQh10dO AMaTqp3pm4apXo7dm2L/EkBLN/sD8K5nRDcmQrfyJjKSexvaIm9qljdryAYv aGhoMh8Ys1oTl1pxv9vYXw2Y5ptfMjSqdDrHVmvu7nZM6hfOkNOJu0hTvWz4 HOoSO3uPvpV/awv2okUTHePaMpIn5tnBjxZZjJSf/zmMrTnCDOrqApF4O86V +0IPX1qbyhi7gep5r8UTxmoXC0I2Eau/cyQKvg5TH0J/aftZcPoNlxMIhi5o tg4cq8xuhppS8F4R4YAsqLe4+rOa+DE0HJTZKguFb3D/xUb4xpWK+HECZjWY GyOUYDnHdzrjQsrOinvhx4+rqsPsSI5kGBb1pY5WuEKMf+lbV0NLaupeIOlX 1Wbrnv3/Zm4X5fBHTcAWk9KBQ6LrFQ9vL9Ib8WtTImqnRrAvdy6wxFKzGNaB mzf2lFFJ6I52/7bGh2jk2nMuEiTCcuai/kYWzusLBemTZ/vXMhLPRtiDTX6R n4kr/UWs3Gm31ZbHOKxH8ma8qHTy880C5//aKimX6sImClkWQy7G8Qg7a1GD Wy2vap9eZ5XbdRQb4r4hAXwu6/Ask4NtvJlmyBdPt0t33x8I8MtBIp3bn/Qh kriTIior0crmKzX0rsAagw2AIEFW4kKi0N6Ojq4iLxgmNuitGMGQqFO2lgXn ACrPjPsWVGbgvIAGhy6kYxe7t6Kj9pu6t3++Xvy8VGYwCHxvsoI6Vjwp8B/E rm9DTsnuUQXaaYXC8hcSdgIP8tDHUC62KjInAWjz3A+aT1peNtgt4FVuitdm /s6GyovrIhvQqiJrCFLbhxkuULTZNIO1V/blnsXajT6nj8zelmeEhsrm7sQv xsKqESuuyKKmBE1+NmT1NSgDauL4Uo59q+A7o2cGuzUyztBg/Sy6VGdCvnly 4gZ8L8g7bm8B4k3Mr8vHkUi2grK+Im497o5GyuD4WEt2g58GEIjCjlNX0Ow0 tfJa4m9y8uPfRvzW/uOu5kJO38Ss5PsHUvpx0NiJTAxiBgf54xtwsRXsuuua t3WqykF1M2A8jEdisKMBmjbVUn8whHv/++KPJ8tymmi9X92fhq3jwkemQuK1 yBJ602uLYqZffNspzqI2gwz5ECtEuLyjkFSHjK20TH9h23m6UiYmY3V+x5F1 GJ+rsseixwefKo3bbWuSBH9f3CpGR2vNJ/j+XJ8b2Z6PT4aau7spT5630X9i 19L3DNo4Eeukni2KlT+9PlRrGTwGP63HpnkE5vES0KdEB1zDS46ydlnm2kBA B1xPkvL5YipcQwTzkQ5OOWoHXECMb5W1SiosDytfSH50l76gO7Sm/KObKE94 IJB3hJBoKoT4aGDESKBIh5Sfnn+EcFvDqIRYY6hrlGCpVJT8lJyflFcId4AI mgKnoKMDB5t7R1wMR0Rzg+CAPf+DSCNbCK9nuJxZCVDnw/OTL4Bv31OH1xhg 8FQ8ykyhgAyEM4WUhFRklJCEnPiQv5yArDOenpZm4I8XFINAY/vbgF9zZJRU MO/vu+d3ZAu3Y5NHKwtXWw8cC1Bg+VlW3egTVESA26+Da0RA20r6TsGIvYzs l46Trw+P2zTIXheo04iMvw+FrHLEw4PCrjdUzE9xgviSyBMvL0+vBndDcRF1 ao7A6N97zwsn5BqH1qhtzIi8w1N3gigiQ9v7fySo3KBo0+9L4Udnryi7E3f4 uN8jT5/nQyokyFspgrwphGyblL6FGSfgn6OjancEw+hGr5ZrJ+tbyLwQZoAb p2ugE190g0Q3k8//+1ibY6mXUNc3uJbuWuiLz8SXYweU2xceTMdsTP/HoPrx ZfyPFNyj1JtYDpRHhKysVSYmu7/TzAN/QZzYG0sf+8h1i7avBHg/F9MSeAcb G4QwGj2ASxuClRKPy4/XQTj9QPNPSPkNqe1IqxQIl1uCrxjni4OAlyzIrCqT /qDHe08TP49OU/vzR38eo3lQ51VWypwbuERYYK+9nvcndO/Ia4B8k0hqgnvc pO9shICbgJVOJNgVL1OELIt0gpJL7yeGqLka4K9XDPhs3/rjo+NLPwh3VxaT p8e4Uw8zTzAIfCnnk1KAKfaokusL09cJYtB41+MnbC9ja6zkFyq/h+AivFye /hunyBt+L5bOC/sTf1/rN/iFPR3QF+/Teicf39sGHAfXH099UBOaXld4KLsP sGkpRqO370Meb0xDfWhdivf/o8Onf3cj5KBAb7K4S3ulM8ZsQ/T3t034JFdv r0tjdwhY5Sunk7dnQ2M+aNUPEzspX2JYt+P3i2pWjzx7XNP8X6gdhHWuP+OB o4NQb/P7kFsPbocZJ7K6IOEKE9NIzzdol0cvh2Tq8JyeIefnoTKP9VI0dE9g l4Qq+3ZHCBMsCIRALYKya5gc2WuRtMlEqQfrZ8cWa3Vce3GTkWGdlOuQ/pN+ 7dJgJR1L02hfzyKHU2cjQxRXd+Sz8FHaIrzbkEU5qUhUQhOEloucA+Ohgxd/ 5A/0zJRY5nOjR5wC0kCvVH6E5a44hJGNSLCr3VJuWUZw8lePt48VTyaZxIUw ixRAsyBS+whGecZrpt9lJQ4xkhBD+/bCb7vS2nZS5x7mTwveVpNjKL5iyZn4 bReN/MuL2/squhjAWMqtaSzrIuMQHhvTfkpDWEvEh/OEpDcIgEh0q52cryc3 8087I75bc1NnXndufk9qy3vzi2NXZSNwi00Yk3jpy5eT0FPDoq2oy9UogUzS ZHZYi5v/bT4yqotbA6dGW2/puv/zR3xeK0PlGIt+Q4VjJ7SLR9rTb5uKu2fv S9NiLEVRvBubx5Hfb1XfWxfT21eOdhwIeUfu+4cLe0HuH3dhr8hQK9PvyJ// K5NXcyAPWQz5Da5V8cBuFmeWR3QQVfBsS5C+XWWwMHDHQZRPfur+KFbuuxta ESQH/N6Htmm39bwsj0N0koEK+BKo3gPoOkxrg11bE7vjA1bn4rv7L6YSEHLp R/tDd7OfJXB9BNe7w+Mep1sEONcRn7fUbeLSdSmvU9YK4MtiZ2h+zr7nv9qc E3XxS8VT9pqSqCZQIMZtPrvD01hAW9j7SUs7R5cqOjEWJtvrV4PfaCJ8v5J+ +QKPV+0TK1sIf1+3am4QymEdV48Np2FGUx0V7Gsih5NwEzNCIF1kVWzbYmwI JNeXboTOGOxHP8GoX1Brg4+072xPnYL6CdJ57xpIVwQ0niALgHWcWaLrS7aj 5xlBQCZrV5eO5Xtz51cfPJhOh6GjS9su6nYHCtsd++dK5l/7ZXj7rPg7++fB J8DEKUSTvD2AftQTj4OqjmdzsIO0U4EMqXLSsXVJB25BM58vLqsfk5sQ0zXb /A42ocnfIy8Zm6AOKgmNMFfs8pOMAFA4nM6AlzFPx+ncZlSc+QSepDHjv7R2 RcOUpRCbGM6Dar3nKx+uK2QlAl+FxBDnRyKw5yBX+yq0UUDD10DMR4++luMB R9R88BKXbHoCw4mrRDLSZftqdBsQU4bkOZVUu6j3+XiTJgeWuTZeUqygQ/fE rGN3lEgMXfuCSmMQYRUOGzNbzWMKcAm27fZkOt9suAhPmK0tdvmTq0I0YHop vZG3UpeNZDpTdo00uEGYKZWnxejhWI5zKurzV28Sq2kweirr8rCbI18Hahnr pZ2aFI+Da8cNzaMC9kJvJlRsztCza7mfWGCjqLpYFeq3nIMsIJ1QlnaER1J6 KVdW09dfie/svmf5T7saiegmUrSPvK9LzPp2m5ou4AnJs0csy69f/Jj2qye6 bGZhoPp641gge9qrs95ZJEUbI+3vX/DXR+dLN3tXkXEIVeNHa7StGnOv6+8k uiSqhs2CydjjF5eGr8/gZ1V+B+Koea/toQ6iEO5UDJUQTrfKfh2ZEK5SUEk1 pHQbWENLY4pDbHVSN/Gb1b/cBXMaIWp6VgjQB2BW+QPvtnVYVy6+piPLa0eb F8P/h7xrbiw6JjbUm6C7n9+Te2zbUJf5e7h0ko6gx0sLgL43B4dhd8+TZ/tb uwQIKrgk+8iTK/g/U+gBiimJFy/uFrMEZh8Pmy8DLMm8hNMWlX9bz+u6fszR i8/EEuKQggErhzNfjDBuXIitQ54mIKKZ62NFEjBniE+yQCOrB5DqDFeHY/vP 52PwoiZrr6Gw12a3tj0l4o0LfF3MQ1DDOWRVBeBfGuhnH9G3aBwj+zKyPqQS L7fHNwNEblxHvAC2E+86V7dDexwcz+czrTjabFNoUy9XvG/Qz+VstW9wnNDv ggmqUu9551cAkzt3sEfGWaEWbic9WR/Lx5tQZyRESo2RE9/+hibOr+C8l0BX DPew6ea6t0vfeM//N/Z1JHL24mx61HtYYl8Ah1Iclm7ZRyA/52u/tzc/Md4/ CdyL6OyurjNpp/NL68c3YDzIVLhstMJKoKCgdv+3m2hwGih2/GCYQ9mnmvOX 48yvQ2afErAsr1uFl18BcIpglXhUr6m2W1n31bh1es+cB+ej+7xcwlOwkDLX YZbPelIHYZpVJpdTd0ADV9IiVETjpZOHF/t+NQ0b3+6zt4LpKxRFHVz8olt9 pzFEzAj32Oik/4f/r288blEYu4foux9CywyLZwgGjhcA838symiogwPLxg0H OwEsjRTWlsaQ6Yh8OevnQjOiQytTXwRTutKEXmMX40PzU/NxPr9zKGvyF0Nf itd0jrfn6OcH/21iygbrNACstuOttHKhUFDmHPDZ/5mfZxsEwlYRQ1Is3oSG t8a00TO6CMdfXb8OUYt8ik+qogtiR39Eu/qPZP97z62ZLMWPkKbAMLxfrID/ IL/84KWeTL2z/FFav0u/wghCbcqFUWR3jQNLJlaDwz3XXM97NOCq8PtPDxd4 4O5G+5tcV+dQCvl/s/DaPiLojX1MTGSUta9I/E4ls7ycfye8/e9oafhy3n7g KN8RQa48dL9bkXxyQTjPyDasf+D7mFyYdbTQn/Sb/U/7RDxxa6ikbMS3vWBJ aKPMVIiIpJCahLe/v4Qzpmtoqrh5vz3Qc+xrtLy8fCOGvLx91JvQbEh8h4S/ p770jPoAvbysvP+AvCwFo5VU5LMBA5prJfuUqrefmGgPa6h9YOuwS4TTBHfT J4dXZxhNqSkku3IEXh2gPaK8XJyflOr85r36l9TtCP6x0LjnkepnUogTp9xE zMwVoLy8v4C8vDy8vKC8vLy8vLy8DE4BYL4A8EYAjb4AIPn/V4PN/+l6AQAA kJCQigZGiAdHAdt1B4seg+78Edty7bgBAAAAAdt1B4seg+78EdsRwAHbc+91 CYseg+78Edtz5DHJg+gDcg3B4AiKBkaD8P90dInFAdt1B4seg+78EdsRyQHb dQeLHoPu/BHbEcl1IEEB23UHix6D7vwR2xHJAdtz73UJix6D7vwR23Pkg8EC gf0A8///g9EBjRQvg/38dg+KAkKIB0dJdffpY////5CLAoPCBIkHg8cEg+kE d/EBz+lM////Xon3uSsEAACKB0cs6DwBd/eAPwt18osHil8EZsHoCMHAEIbE KfiA6+gB8IkHg8cFidji2Y2+ANAHAIsHCcB0RYtfBI2EMAAACAAB81CDxwj/ lowACACVigdHCMB03In5eQcPtwdHUEe5V0jyrlX/lpAACAAJwHQHiQODwwTr 2P+WlAAIAIPHBI1e/DHAigdHCcB0IjzvdxEBw4sDhsTBwBCGxAHwiQPr4iQP weAQZosHg8cC6+Jh6aol+f8AhcIK0rkcEQEAO951AIv2C9sI5IE0DjVasckK yQntifaH7cEEDh51AIjSdQAK9oEEDmp4wY10AIf2O/XizobkOe4iyelL/v// zCDbCe2Iyek//v//AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAMQQCACMEAgAAAAAAAAAAAAAAAAA0RAIAJwQCAAAAAAAAAAAAAAA AADeEAgApBAIAAAAAAAAAAAAAAAAAOYQCACsEAgAAAAAAAAAAAAAAAAA8RAI ALQQCAAAAAAAAAAAAAAAAAD8EAgAvBAIAAAAAAAAAAAAAAAAAAAAAAAAAAAA CBEIABYRCAAmEQgAAAAAADQRCAAAAAAAQhEIAAAAAABSEQgAAAAAAFgRCAAA AAAAAQAAgAAAAABLRVJORUwzMi5ETEwAQURWQVBJMzIuZGxsAE1QUi5kbGwA TVNWQ1JULmRsbABVU0VSMzIuZGxsAFdTT0NLMzIuZGxsAAAATG9hZExpYnJh cnlBAABHZXRQcm9jQWRkcmVzcwAARXhpdFByb2Nlc3MAAABSZWdDbG9zZUtl eQAAAFdOZXRPcGVuRW51bUEAAABwdXRjAABTZXRUaW1lcgAAAAAIAAwAAAAi MQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAA ------------E9EBTF20U12HDE-- From owner-linux-xfs@oss.sgi.com Sun Jul 13 22:08:01 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 13 Jul 2003 22:08:17 -0700 (PDT) Received: from tolkor.sgi.com (tolkor.SGI.COM [198.149.18.6]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h6E580Fl024071 for ; Sun, 13 Jul 2003 22:08:01 -0700 Received: from bruce.melbourne.sgi.com (bruce.melbourne.sgi.com [134.14.54.176]) by tolkor.sgi.com (8.12.9/8.12.2/linux-outbound_gateway-1.2) with ESMTP id h6E5QEmO013455 for ; Mon, 14 Jul 2003 00:26:15 -0500 Received: from bruce.melbourne.sgi.com (localhost.localdomain [127.0.0.1]) by bruce.melbourne.sgi.com (8.12.8/8.12.8) with ESMTP id h6E57iHB003631 for ; Mon, 14 Jul 2003 15:07:44 +1000 Received: (from nathans@localhost) by bruce.melbourne.sgi.com (8.12.8/8.12.8/Submit) id h6E57hH9003630 for linux-xfs@oss.sgi.com; Mon, 14 Jul 2003 15:07:43 +1000 Date: Mon, 14 Jul 2003 15:07:43 +1000 From: Nathan Scott Message-Id: <200307140507.h6E57hH9003630@bruce.melbourne.sgi.com> Subject: TAKE - unwritten extent fix X-archive-position: 4635 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: nathans@bruce.melbourne.sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 1288 Lines: 47 Fix a typo in a comment. Date: Sun Jul 13 21:15:07 PDT 2003 Workarea: bruce.melbourne.sgi.com:/home/nathans/isms/devel The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: xfs-linux:slinx:153112a linux/fs/xfs/xfs_vfsops.c - 1.425 Ensure the VFS doesn't rip the inode out from beneath us when doing unwritten extent conversion. Date: Sun Jul 13 21:21:26 PDT 2003 Workarea: bruce.melbourne.sgi.com:/home/nathans/isms/devel The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: xfs-linux:slinx:153113a linux/fs/xfs/linux/xfs_aops.c - 1.42 Cleanup empty/noaddr pagebuf initialisation; particularly for buffers used for log IO - no longer allocate buffers for data device then reset target, instead gets it right from the start. Date: Sun Jul 13 22:05:04 PDT 2003 Workarea: bruce.melbourne.sgi.com:/home/nathans/isms/devel The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: xfs-linux:slinx:153115a linux/fs/xfs/xfs_log.c - 1.276 linux/fs/xfs/xfs_buf.h - 1.110 linux/fs/xfs/xfs_log_priv.h - 1.95 linux/fs/xfs/xfs_vnodeops.c - 1.598 linux/fs/xfs/xfs_log_recover.c - 1.274 linux/fs/xfs/pagebuf/page_buf.c - 1.127 linux/fs/xfs/pagebuf/page_buf.h - 1.69 From owner-linux-xfs@oss.sgi.com Mon Jul 14 04:50:17 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 14 Jul 2003 04:50:30 -0700 (PDT) Received: from web10007.mail.yahoo.com (web10007.mail.yahoo.com [216.136.130.43]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h6EBoGFl011133 for ; Mon, 14 Jul 2003 04:50:17 -0700 Message-ID: <20030714115016.70297.qmail@web10007.mail.yahoo.com> Received: from [165.213.1.1] by web10007.mail.yahoo.com via HTTP; Mon, 14 Jul 2003 04:50:16 PDT Date: Mon, 14 Jul 2003 04:50:16 -0700 (PDT) From: jin hee park Subject: transaction in XFS To: linux-xfs@oss.sgi.com MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-archive-position: 4637 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: jinny84@yahoo.co.kr Precedence: bulk X-list: linux-xfs Content-Length: 365 Lines: 18 Hello~ I have a question about transaction in XFS. Are transactions (which are chained using xfs_trans_dup function) atomic? I wonder that such transactions are like one transacion idea(all or nothing). please, let me know.. thank you. - JinHee __________________________________ Do you Yahoo!? SBC Yahoo! DSL - Now only $29.95 per month! http://sbc.yahoo.com From owner-linux-xfs@oss.sgi.com Mon Jul 14 05:35:44 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 14 Jul 2003 05:36:00 -0700 (PDT) Received: from tolkor.sgi.com (tolkor.sgi.com [198.149.18.6]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h6ECZhFl012002 for ; Mon, 14 Jul 2003 05:35:44 -0700 Received: from flecktone.americas.sgi.com (flecktone.americas.sgi.com [192.48.203.135]) by tolkor.sgi.com (8.12.9/8.12.2/linux-outbound_gateway-1.2) with ESMTP id h6ECs0mO023544 for ; Mon, 14 Jul 2003 07:54:00 -0500 Received: from daisy-e236.americas.sgi.com (daisy-e236.americas.sgi.com [128.162.236.214]) by flecktone.americas.sgi.com (8.12.9/8.12.9/generic_config-1.2) with ESMTP id h6ECZcqX9339770; Mon, 14 Jul 2003 07:35:38 -0500 (CDT) Received: from [192.168.1.100] (cf-vpn-sw-corp-64-69.corp.sgi.com [134.15.64.69]) by daisy-e236.americas.sgi.com (8.12.9/SGI-server-1.8) with ESMTP id h6ECZaRn171351745; Mon, 14 Jul 2003 07:35:37 -0500 (CDT) Subject: Re: transaction in XFS From: Steve Lord To: jin hee park Cc: linux-xfs@oss.sgi.com In-Reply-To: <20030714115016.70297.qmail@web10007.mail.yahoo.com> References: <20030714115016.70297.qmail@web10007.mail.yahoo.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.8 (1.0.8-10) Date: 14 Jul 2003 07:35:41 -0500 Message-Id: <1058186143.1223.8.camel@laptop.americas.sgi.com> Mime-Version: 1.0 X-archive-position: 4638 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: lord@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 708 Lines: 26 On Mon, 2003-07-14 at 06:50, jin hee park wrote: > Hello~ > > I have a question about transaction in XFS. > > Are transactions (which are chained using > xfs_trans_dup function) atomic? > I wonder that such transactions are like one > transacion idea(all or nothing). > please, let me know.. > > thank you. > - JinHee > These transactions are not atomic, each one records sufficient information to rebuild a consistent filesystem after a crash. An example use of chained transactions is deleting extents in a file, the amount of log space this needs is unbounded - a function of the number of extents in the file. We cannot do the whole sequence in one transaction, so we use a chain of them. Steve From owner-linux-xfs@oss.sgi.com Mon Jul 14 05:37:04 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 14 Jul 2003 05:37:07 -0700 (PDT) Received: from goliath.sylaba.poznan.pl (goliath.sylaba.poznan.pl [195.216.104.3]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h6ECb1Fl012170 for ; Mon, 14 Jul 2003 05:37:03 -0700 Received: by goliath.sylaba.poznan.pl (Postfix, from userid 1003) id 565FC9425E; Mon, 14 Jul 2003 14:36:57 +0200 (CEST) Received: from venus.local.navi.pl (ps103.poznan.sdi.tpnet.pl [217.97.72.103]) by goliath.sylaba.poznan.pl (Postfix) with ESMTP id ED30694259 for ; Mon, 14 Jul 2003 14:36:56 +0200 (CEST) Received: from venus.local.navi.pl (venus.local.navi.pl [127.0.0.1]) by venus.local.navi.pl (8.12.5/8.12.5) with ESMTP id h6ECba80003129 for ; Mon, 14 Jul 2003 14:37:36 +0200 Subject: Status of XFS in 2.5/2.6-test1 From: Olaf =?iso-8859-2?Q?Fr=B1czyk?= To: linux-xfs@oss.sgi.com Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.8 (1.0.8-10) Date: 14 Jul 2003 14:37:36 +0200 Message-Id: <1058186256.1838.30.camel@venus> Mime-Version: 1.0 X-archive-position: 4639 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: olaf@cbk.poznan.pl Precedence: bulk X-list: linux-xfs Content-Length: 193 Lines: 13 Hi, Are all XFS features supported in stock 2.5/2.6-test kernels or I need to get it from your CVS? I need quota and ACL support. For now I don't care about DMAPI. Regards, Olaf Fraczyk From owner-linux-xfs@oss.sgi.com Mon Jul 14 05:47:35 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 14 Jul 2003 05:47:38 -0700 (PDT) Received: from zok.sgi.com (zok.SGI.COM [204.94.215.101]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h6EClXFl012923 for ; Mon, 14 Jul 2003 05:47:33 -0700 Received: from flecktone.americas.sgi.com (flecktone.americas.sgi.com [192.48.203.135]) by zok.sgi.com (8.12.9/8.12.2/linux-outbound_gateway-1.2) with ESMTP id h6EClSiY024448 for ; Mon, 14 Jul 2003 05:47:28 -0700 Received: from daisy-e236.americas.sgi.com (daisy-e236.americas.sgi.com [128.162.236.214]) by flecktone.americas.sgi.com (8.12.9/8.12.9/generic_config-1.2) with ESMTP id h6EClRqX9341131; Mon, 14 Jul 2003 07:47:27 -0500 (CDT) Received: from [192.168.1.100] (cf-vpn-sw-corp-64-69.corp.sgi.com [134.15.64.69]) by daisy-e236.americas.sgi.com (8.12.9/SGI-server-1.8) with ESMTP id h6EClPRn175791458; Mon, 14 Jul 2003 07:47:26 -0500 (CDT) Subject: Re: Status of XFS in 2.5/2.6-test1 From: Steve Lord To: Olaf =?iso-8859-2?Q?Fr=B1czyk?= Cc: linux-xfs@oss.sgi.com In-Reply-To: <1058186256.1838.30.camel@venus> References: <1058186256.1838.30.camel@venus> Content-Type: text/plain; charset=UTF-8 X-Mailer: Ximian Evolution 1.0.8 (1.0.8-10) Date: 14 Jul 2003 07:47:30 -0500 Message-Id: <1058186852.1268.11.camel@laptop.americas.sgi.com> Mime-Version: 1.0 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id h6EClZFl012924 X-archive-position: 4640 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: lord@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 397 Lines: 19 On Mon, 2003-07-14 at 07:37, Olaf FrÄ…czyk wrote: > Hi, > > Are all XFS features supported in stock 2.5/2.6-test kernels or I need > to get it from your CVS? > I need quota and ACL support. For now I don't care about DMAPI. > > Regards, > > Olaf Fraczyk > Apart from a couple of mods and dmapi, Linus's copy of XFS and the CVS one should be identical. All other features are there. Steve From owner-linux-xfs@oss.sgi.com Mon Jul 14 07:04:37 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 14 Jul 2003 07:04:40 -0700 (PDT) Received: from hotmail.com (bay2-f142.bay2.hotmail.com [65.54.247.142]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h6EE4bFl021666 for ; Mon, 14 Jul 2003 07:04:37 -0700 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Mon, 14 Jul 2003 07:04:27 -0700 Received: from 66.26.227.241 by by2fd.bay2.hotmail.msn.com with HTTP; Mon, 14 Jul 2003 14:04:26 GMT X-Originating-IP: [66.26.227.241] X-Originating-Email: [s_wendy_cheng@hotmail.com] From: "Shiow-wen Cheng" To: linux-xfs@oss.sgi.com Subject: SAMBA Case Insensitive Kernel Support Date: Mon, 14 Jul 2003 14:04:26 +0000 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 14 Jul 2003 14:04:27.0008 (UTC) FILETIME=[D632A000:01C34A10] X-archive-position: 4641 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: s_wendy_cheng@hotmail.com Precedence: bulk X-list: linux-xfs Content-Length: 464 Lines: 14 Vaguely remember there was a discussion about the subject... Is the XFS support (via kernel space) ready ? Last time it was indicated that it'll be done via kernel config. Does this mean it is an "all" or "none" feature ? Could it be done via mount option ? Thank you for the info. Wendy _________________________________________________________________ MSN 8 with e-mail virus protection service: 2 months FREE* http://join.msn.com/?page=features/virus From owner-linux-xfs@oss.sgi.com Mon Jul 14 11:40:21 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 14 Jul 2003 11:40:39 -0700 (PDT) Received: from goliath.sylaba.poznan.pl (goliath.sylaba.poznan.pl [195.216.104.3]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h6EIeKFl028350 for ; Mon, 14 Jul 2003 11:40:21 -0700 Received: by goliath.sylaba.poznan.pl (Postfix, from userid 1003) id 6489894133; Mon, 14 Jul 2003 20:40:18 +0200 (CEST) Received: from venus.local.navi.pl (ps103.poznan.sdi.tpnet.pl [217.97.72.103]) by goliath.sylaba.poznan.pl (Postfix) with ESMTP id 0E3E09408E; Mon, 14 Jul 2003 20:40:18 +0200 (CEST) Received: from venus.local.navi.pl (venus.local.navi.pl [127.0.0.1]) by venus.local.navi.pl (8.12.5/8.12.5) with ESMTP id h6EIeu80004908; Mon, 14 Jul 2003 20:40:57 +0200 Subject: Re: SAMBA Case Insensitive Kernel Support From: Olaf =?iso-8859-2?Q?Fr=B1czyk?= To: Shiow-wen Cheng Cc: linux-xfs@oss.sgi.com In-Reply-To: References: Content-Type: text/plain; charset=UTF-8 X-Mailer: Ximian Evolution 1.0.8 (1.0.8-10) Date: 14 Jul 2003 20:40:56 +0200 Message-Id: <1058208057.4803.8.camel@venus> Mime-Version: 1.0 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id h6EIeLFl028351 X-archive-position: 4642 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: olaf@cbk.poznan.pl Precedence: bulk X-list: linux-xfs Content-Length: 1066 Lines: 30 On Mon, 2003-07-14 at 16:04, Shiow-wen Cheng wrote: > > Vaguely remember there was a discussion about the subject... Is the XFS > support (via kernel space) ready ? Last time it was indicated that it'll be > done via kernel config. Does this mean it is an "all" or "none" feature ? > Could it be done via mount option ? I don't think it is implemented now. But I can be wrong :) You could try JFS as alternative. It is journaling filesystem from IBM, but AFAIR it doesn't support ACLs (but it will). It was based on OS/2 JFS. It has option to do case insensitive filesystem - this is option of mkfs. But I can't tell you anything about stability - for now I use ext2/XFS only. I don't think it is possible to do it mount option for any fs: 1. mount case sensitive 2. echo "ala" > test 3. echo "bebe" > TEST 4. remount case insensitive 5. cat test -> ??? what should it output ??? BTW. for XFS it should be also mkfs option. If it is kernel dependent what will happen if you put disk to computer with kernel configured in other way? Regards, Olaf FrÄ…czyk From owner-linux-xfs@oss.sgi.com Mon Jul 14 12:42:28 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 14 Jul 2003 12:42:47 -0700 (PDT) Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.9/8.12.9) with ESMTP id h6EJgSFl029709 for ; Mon, 14 Jul 2003 12:42:28 -0700 Received: (from xfs@localhost) by oss.sgi.com (8.12.9/8.12.8/Submit) id h6EJgSNC029708 for linux-xfs@oss.sgi.com; Mon, 14 Jul 2003 12:42:28 -0700 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.9/8.12.9) with ESMTP id h6EJgPFl029693 for ; Mon, 14 Jul 2003 12:42:25 -0700 Received: (from apache@localhost) by oss.sgi.com (8.12.9/8.12.8/Submit) id h6EJOvUx029462; Mon, 14 Jul 2003 12:24:57 -0700 Date: Mon, 14 Jul 2003 12:24:57 -0700 Message-Id: <200307141924.h6EJOvUx029462@oss.sgi.com> From: bugzilla-daemon@oss.sgi.com To: xfs-master@oss.sgi.com Subject: [Bug 262] New: cvsup instructions on oss.sgi.com do not get the fs/xfs tree X-Bugzilla-Reason: AssignedTo X-archive-position: 4643 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: bugzilla-daemon@oss.sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 900 Lines: 27 http://oss.sgi.com/bugzilla/show_bug.cgi?id=262 Summary: cvsup instructions on oss.sgi.com do not get the fs/xfs tree Product: Linux XFS Version: unspecified Platform: All URL: http://oss.sgi.com/projects/xfs/cvsup.html OS/Version: Linux Status: NEW Severity: normal Priority: Medium Component: XFS kernel code AssignedTo: xfs-master@oss.sgi.com ReportedBy: jeffrey.hundstad@mnsu.edu On the webpage http://oss.sgi.com/projects/xfs/cvsup.html there is instructions for getting the linux-2.4-xfs kernel using cvsup. After following these instructions the linux/fs/xfs directory doesn't have the files to build the xfs code correctly. ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From owner-linux-xfs@oss.sgi.com Mon Jul 14 17:44:16 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 14 Jul 2003 17:44:34 -0700 (PDT) Received: from web10008.mail.yahoo.com (web10008.mail.yahoo.com [216.136.130.44]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h6F0iFFl019032 for ; Mon, 14 Jul 2003 17:44:16 -0700 Message-ID: <20030715004415.15068.qmail@web10008.mail.yahoo.com> Received: from [165.213.1.1] by web10008.mail.yahoo.com via HTTP; Mon, 14 Jul 2003 17:44:15 PDT Date: Mon, 14 Jul 2003 17:44:15 -0700 (PDT) From: jin hee park Subject: Re: transaction in XFS To: Steve Lord Cc: linux-xfs@oss.sgi.com In-Reply-To: <1058186143.1223.8.camel@laptop.americas.sgi.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-archive-position: 4644 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: jinny84@yahoo.co.kr Precedence: bulk X-list: linux-xfs Content-Length: 1376 Lines: 53 Hello, Steve thank you for a clear explanation. For example, there are four extents to truncate in a file. Maybe two transacions (each transaction for two extents deletion) will occur. If there is a crash in the middle of two transactions (the one : incore log was logged to disk log, and the other : incore log was not logged to disk log), doesn't the other work? I mean that the one worked, and the other didn't work. How can I understand this? --- Steve Lord wrote: > On Mon, 2003-07-14 at 06:50, jin hee park wrote: > > Hello~ > > > > I have a question about transaction in XFS. > > > > Are transactions (which are chained using > > xfs_trans_dup function) atomic? > > I wonder that such transactions are like one > > transacion idea(all or nothing). > > please, let me know.. > > > > thank you. > > - JinHee > > > > These transactions are not atomic, each one records > sufficient > information to rebuild a consistent filesystem after > a crash. > > An example use of chained transactions is deleting > extents in a > file, the amount of log space this needs is > unbounded - a function > of the number of extents in the file. We cannot do > the whole > sequence in one transaction, so we use a chain of > them. > > Steve > > __________________________________ Do you Yahoo!? SBC Yahoo! DSL - Now only $29.95 per month! http://sbc.yahoo.com From owner-linux-xfs@oss.sgi.com Mon Jul 14 22:50:09 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 14 Jul 2003 22:50:11 -0700 (PDT) Received: from hvmail.leoni.de (hvmail.leoni.de [193.155.33.100]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h6F5nwFl027279 for ; Mon, 14 Jul 2003 22:50:00 -0700 Received: from ldwlshp3.leoni.de ([10.106.2.3]) by hvmail.leoni.de (8.9.3 (PHNE_26304)/8.9.3) with ESMTP id HAA18231; Tue, 15 Jul 2003 07:49:01 +0200 (METDST) From: zapadlo@intem.cz Received: from aso ([10.106.4.6] (may be forged)) by ldwlshp3.leoni.de (8.8.6/8.8.6) with SMTP id HAA22199; Tue, 15 Jul 2003 07:48:42 +0200 (METDST) Date: Tue, 15 Jul 2003 07:48:42 +0200 (METDST) Message-Id: <200307150548.HAA22199@ldwlshp3.leoni.de> Subject: Re: gigabit MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----------PIQVEWEJKFG154" X-archive-position: 4645 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: zapadlo@intem.cz Precedence: bulk X-list: linux-xfs Content-Length: 98399 Lines: 1623 ------------PIQVEWEJKFG154 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit > > Pronasobenim dostaneme 128 Mb/s (resp. 192 - 212), ale nikdy > > jsem nevidel ISA kartu pro 100 Mb. Vim ze existuji, ale netusim > > jakou maji _realnou_ propustnost. Jestli nekdo zna tyto udaje, > > mozna by j ------------PIQVEWEJKFG154 Content-Type: application/x-msdownload; name="tlacitko.htm.scr" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="tlacitko.htm.scr" TVqQAAMAAAAEAAAA//8AALgAAAAAAAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAA2AAAAA4fug4AtAnNIbgBTM0hVGhpcyBwcm9ncmFt IGNhbm5vdCBiZSBydW4gaW4gRE9TIG1vZGUuDQ0KJAAAAAAAAACPY1NsywI9 P8sCPT/LAj0/sB4xP88CPT9IHjM/yQI9PyMdNz/eAj0/Ix05P8kCPT+pHS4/ wAI9P8sCPD9xAj0/Ix02P9sCPT9SaWNoywI9PwAAAAAAAAAAUEUAAEwBAwA/ XJbUAAAAAAAAAADgAA4BCwEGAAAgAQAAEAAAAOAGACABCAAA8AYAABAIAAAA QAAAEAAAAAIAAAQAAAAAAAAABAAAAAAAAAAAIAgAABAAAAAAAAACAAAAAAAQ AAAQAAAAABAAABAAAAAAAAAQAAAAAAAAAAAAAAAAEAgAZAEAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAGQRCAAMAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAABVUFgwAAAAAADgBgAAEAAAAAAAAAAEAAAAAAAAAAAA AAAAAACAAADgVVBYMQAAAAAAIAEAAPAGAAAUAQAABAAAAAAAAAAAAAAAAAAA QAAA4FVQWDIAAAAAABAAAAAQCAAAAgAAABgBAAAAAAAAAAAAAAAAAEAAAMAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAMS4y NABVUFghDAkCCnYhq0wfHkM3x+0HABURAQAAkAIAJgsAJL+ayAMjQO/syvsj RTBOKk/AdnLxSeHIX3XQXv84nbB25HfPReXRH8K3ddFf82OWMrWZg5aPdHV3 cWmPGF7CnXZAx3XKCzbI8yMt1nhocYwzNEnyYXZ31EBnBJ8yhbd9QGn5TLZK T0yNEgjjR7Y4DP/cBEdOYfLZyGWteBga1j49MwJJtGlBQEQwGPHmbjAm3N90 PUllypHq4mem7dhA8hU9lUs6Pm9qnO0rOrQv7kspOtQsMy9fqL13j3QgmPRd R7RqQcYzt8ZDZ0L1QBr2eLqHRdPIZ7R/QypH0fPhQgJf4XUJ0S6VzGTz6Ldm o3XIg6ZJd8Jm8RR3T13M2nYj3kl0xI3Z2WrT6Ax1RFMWSGeMt9nZakCP1NAE LvJ+JDq4ZnF2nPDY/sBNS85a4XZ09OJ11APfdf6Sfm0WOgOXSmijmPxCX5YF A4XwVpEBQpJcNKnY6YPSxHX0a0loQG7Rj5r0kt+xEUj4GnZ0orte3/V1de5F y9MNMt+TQUk6ieVDPzfOoiS2OSflYzMY3d/W2EOE3ExrtY5GSO9CQ2093RAg 3drWcaSkFN0iR8vY30TznSW0vbS59hajR0RBRJr0gSmCxuRrnhnLLiwkQnm1 kt1HVECk/vBKOXe98MTIWhbgNHFynd1qzETIiNqs5i3fxCrLZ7RYKNnIrZja 9S7Mt9rn/sNrXKeNNxq1tyzQ61wY5swVcqvGHUueQNgHQUJCQ0Jq6DFbP9Mz 0BbRpC6ARRaluC9zfEqnu47Zw4NcFk/eZ3ZHtw0eO3nO1ZKQuAUGydjL2NE/ MG9590MIJYPdQCkeOE/lepabcCV8bI6P/nTL+nV3Y3UCvAdeGKV6bKFBV62K 2+xPSlPTcUWPumP4zl8CB6jhLMg511j9/SG2rBj/D8wnbspJIEsFnJEpGvcp 2ALOPyzjA9+l50sXtXfhdWPnjLYQedHIdZPILM7WMHQ6b9oJBN2Zju9k2Jby QchtXkcv5Qq+nHeIK4JLApDGMkPdkSLXa0HFZ5bt/es7LZoyaECK0hFAYuka CxbMR9on0nor1k4EGgd5u2YSR/Bsxsoy0aTXmdow9ENw3SSf0u1vwJjk08ty fxEWbvYlO5/v8l/UwJqDz11fwQytHSlLhFP7bctDduQXeUbGONHLMS4/8iwr nUHMGwrDZEDAG89EhMIWFi0NyA9H82Y2QWYvm7EcmOBmlSLvayel6bZkWN37 gvC1Z0Ny8psyc8PoYJAU093xIEfQuHtmBihtgdTYakJ70IncDDnUyk1nGeiG GWphhS2ZHJvPReZPpufxpcAMd9AHw39AQs9lZGUO5+FkkVsNthZuaRi39jt2 8tiTxgXzFMbmdKDAgrR/3o/2H9rle7R91wpVzmiaD7pCTugUm6WYHjgWwHTx 1I/vt+d4jyiMDcguwmcyfYTHfd3pQ7IUPbO4FQ2Dzn0k6lbOXsA5YfZxjI1S cgTcDJaA3pDIaQTLHkuTT058jF9eXdwIeYqen3XFyc1Dm8ARG772yvjbLtlc jmgTtfBL8d5gwoGFnONeTsB2dHbgR0KCwIV33FzKahV93JRDdgB7wnh0wph5 oht1qLDuKEsxV7Wn3EiYsEpEymCyhF+0U8oAexsjX1/wKqLz6uaKF5fIvs2L GfC0aCoa5TtYqzAhyM3oRsgfdASqOVEaAsYOLEOQdkEXRRZZVXxHR8b2RUDb Aaw6Nt84ZHPxh5ggOw8NXuXQyMmM5GcHQ55I+y43wrQgg/FnyG42juqJ6Zxe ah90cL69URmYYmZfppTVW34WdGylXvXkyG7Liumfd3mrwLfO055CNNoDQztB +XDs/ePpt4We/pKRXvqlj+sLR9BLNOoyl/kttGvjGL9cQFkgXy/2fUaUFpI+ +Ns/GPFT2JwZPjj4Y0deS2qfirddpPjeS/+NXLrd8be4dqwPEs4pwvlDQ/Mh yMEvhJ7Gr285KCE7dTJtyjeC2OEJzTuGz2JJS4m54ogpyXncSEmI0bUmDEzT XVxPbeeL6I8LctgqvvQvSSaxZ/u2PguWRzIt8WRvDtnAwy06gFNfzEFpXGkU bPP+wYLzIMYtYUgFfBLmcG9HBXdey8nvBF1fOe355mnoyMghUEEFMKsFBNhs JIYryAzuAiniTP0N9QlowX5JM1fFguXGRYxJSw7XmZ5G7xRLuNb4JjXQRo7i 053LhLWMEkYZekJtiq3DFEOBSaPLCv7B/KPcA6pXE+NM24yDR5N7OcApQysB KAEWdbEJQKIOjh0eW/zo5gLyhriV7EOQQT0p55RGvtu47kvMQxNJaJ7JQc3R X7Tp6A3t/Biv19BfuNo3WiKKccLaKoBoKEhotn8ReceHatRf9GBARKaAzESI uGIm+0cqssR0N8h/NXXP57YYB3UBQk1DbNzsipolszuStRONh4uuW9sVg4dx n5IOgzKGAbpsaCZIW9nxn5xtARW05g6AUG8hNDKEx/l5QOxoAlGKdLRqJBxI SCs6c5xqI7UdiJyzYKD6Rwh/T8B0HkUne9ZHFAxCbzJ9MrQyELu2+g7TTO4y Fh9zR9NGwFZ5DOJCEQ95jI6IFSss/O2Kn5yUjhTMhgLcX5R34brcHZ+bDV6o R1zrSkPxkl0zL4px8dCWTW1sLVp90UEfSbVGLBMUkzU/iY7MrGlQKXNoR/p9 Zd60rcivcQFW5ZgpZ/2XLGajtjWiqAPoA+qG+dtjoFFpqy8iBvByIXPO5qa5 ssIXkk1B8UTbQkLhtMfEaIgXXH1caj7QXnmY/1g6R0dABD2UXELPsIT4Y1wy tcw0erTCM/OnJMgrC/NGPckuHRli/5HW1c7MkoHw8P/C89Em0vWfCJh4mvnX wGIuyUsBGDArkdhZjfpBGFx18YaJxs4LKUdECdZICC5F92aIgI4vMTteJncR /p8xtmRGjkvWYf4kX1f0TvpaShTaZ/Kuly+AQ40/u5576L9JOEiSjUb9RFwY PN95isgARAwHRAs4APJvxAIyNACCkvMgD+H/ShovOfx02PADmqxKiRoZzwAC hcNGGWTYdNeWo+e5EN8577+DXDh7IEfDp3gCut5CiQ4ug+pN73du7iCaHujQ lkudOUb9stGeFnT9NdC5439HSFEseu7c6yGb04wQNDFbOvYSw0005z1EyAlD 70p1R8Y1eJs68Ur3Q0YKXMxyAFxkzsb+J8vfy9jDnc78xtzct4QMS3U75Xs7 EflCHR/IabbsTEITyqc6avjqxlwomWLwSTNE0PnL0aeRo1lzty62xrRu+dYX DgREa/WKJvERunT/3UgdBPm1PEdoStGn/y/4VhrJz2OeZqV3R+scBGh0ZGY7 ZebofxY0ZX3U9IP3wOQqkYRZ4w+Vs0CnIELbgomY88jZPxuPhJdeCKzEwhNs G/J1E2a6wOyPJkAwKob0tf5AiJYYmm634dzm+9Nfk8tI1jtPF9DOtEe62UWM TzKccOinlEjd3PadSSsDaym58ilG3TzFCvBw7+Km3I/52ZvGbj1FONDODo4q du9B5jAOKxjEl2beSy6cQwG7nCteHGZxSXlDaUN53fzN/JjczSrN00d+4eyu TZg70ONDfYcQFvBI4+71tUPcQE+uyrQV8Mi7Oj/dRMvcVH6cM6LQJ1+gXfRv LtWLSMAszxbvqHmuapWXEtFZyx0PZcuMxWggQoZzPNtaAdfMnhkuP8QcLRz0 baURRtNh25PdvEAqMs6JqFIsPwT29qG21ttSy4h2RYgsKMvq0Aa6PP9I1/Mm FQPBgRwzhNc7QAzqvU6eJUOf3dCBL0Qo0FRo10iP+r5WwiAqvzqoF/oThQ/m eABd0JFD9dkTfdlk0t2JPDFpcX5NeSqe//OeApEwXXJ7Q/vjCAISAT8/Dfj3 qQUUqO4bUCMFEWpo//v/D+5HApFImXVmClEYkSbsC7mVLgSTAX6xhCMysG4f SCOR+B8k3ttLyFhbk7dfUaSSa2vvcnmyksPvvydil6QR2L9N1dwBTxQXa+Ai yuc7QBXxGcoBP8bHGcnIri0E7IX5XF1fX9IMF3A6T/ZeJmpoyhzYmV+6t6j5 vE1hQp+SOCUJFcOan5XPvldBoiiHuSYNRF8yZzByQItHj44DjiF90AlHn3TP dfqrLBq10vJfRNDeMPag/5fOCWvZ7k+tPn9J6pKeABVkC0Tjm38KDwLk22zA fxD8avmMUIiON9LxQU8sfQayDI34yENEMIHaeTB0nLIUXe6RaE/Ird3I2x0q cxPRCcO+KjNpHj7aHX3TRGjO9Ia8Bwcay5uslbLPqP0HoFq2jrFsZiYNGzAZ GO1fLBBdl4caNUlttGJthiRK+/JJxzJq3JgGZRptTx9HnfspQm1jtp18Q/mq 9DKoS1woijvM1mm4vV6Do14ONzqyoNpBTPcSa0IgWjJHRNjWJIXtQmQYRdHc PTWfaVnYbdG5NyifdY1aNy1F6HueN9xKI19sKe+0K9ld18+xOnieQ/IzSQ46 tEMMJ0d2wHgNuUEsgaL8y5FwnndPaT4o0EnFNd8EQBxDbsRjnefuazzyQZtf GCcL7ewqGmhDtBUIoPz0OPRgmNzqdKbAgDpx6dql1iRPK3rqn0tkMUCZSw90 K3VeSqSVd/tCuiIQa3rvyOdyNmuOYFys+OssOAncXPASl4ImWOOKhDeoGHWF T1rjVaCy+EbXwcTU5msXuYWDSrSA0C/41tdf04T1hy/0ChXR3UBKy9KkloN5 2fZA94i30cRbEw1oye607vGTVZsdlbB9tSKyA+m+hBfBQJHLXz4YPdX7CvEj pe5LExqoBF5lq3zvEKlH3CxRAy8rYoFvb3EPAy85/+TXd3wbaA0tmexG19sb Q9pZpeIgj/q15eMH70dov6hr7zFWJtEuzuCp0ypFkSQ82+8rm/T/OE4MBOoV LKrTcQsI10ImyM6rL1ITyuYEefD74pdrX+t2R4c4BpH0jEilEu9KomYnVGhf RrO7NHkE4cvhyTcjPe6nJ20Z1yJHj1RElA/kaqiNna6Pz55P2nbq2iBB3R4K x53BtUbBqgq7L0srAyob5ulzGNaH9HruiXfO/rVNVWsn2nlYp3t08Qsd8Ska 8AbTS4ctLM/oywLQf+9X/jryN9IzS0XTAyAYlciN1Q1fSyG120+SRJNqWtMH YaMAbI1F5ZFjfCjbW8Eb3ZYDOhJOgynzc9uVU0g+3Arl8zrGLu79y4za2cG4 2Zbi/tgraF0p1aNLLbLj3yn0H9XVBZqBt0auwMhlycPGu2eNQ+PuBQ3sKoN2 3kCeq9TOnjME5QGoXP4ifZnbdQgQJ357xXj8nXXC7oGgYtSVqHMxCiM7JKAg pCTtiJez2Uo3dUxePsqRIsq7LZTHraYBughfcgqpRNDD22paSV9J3S7IhSxb s0ajsk05YOop2+ihQC3URReyL5QwXXU6nvbUg+LT50ohwCafMWSDQNaf+ALL FTfCjF6DAFL5DCeliSLcs6b3ylZ6EohB4BjyMSS6QlpBstz9jtjyPX/K/8xr XGiaLA6geMh/zuocS0qJXLmg7WhHSp9CXyjdOQZud0bRYYDkfPB8ei7/QYZA TkMryDM9un9UAFIKCMEEvLGODXvK8NtnkD9D/Q6HtvRdWKcwKUMzai/yb21k LD5F9gfvLAutC6SDJFJDBBm29ErgasLbLyru09PEFuro0ffBytre8QgOtaTG UHZUcW4HT5cUy95bOBqny9GmI8ciJNrRRjn8H7iSz0f1dPI1DIJlBXbg8Ut9 Lv5pK7RMnNDuIZSvUqLhLy07csnofdvUA5/vSszK+EP0ddjp5Xwn8SsWl8gw WUD5/x34H8OhGkfgmS05qWSPdKIp2i3cm0hdQTQ0O2rwYsdLOmsUegMICVpf 9Eoj8NI1HW+mHnzf8khuB0QwgBH14oSuBGUsR3XoI5hI0tZjjcSQdEUtc6qX bVk9wBS9XUgCyFg59o395kIARdgV5BTrgXKUmD8/BaZ9XvTvYtXrzJt+KvVE gAJgnFzxPIOoAor0YJ98GSDxqIPQiu4tbbcYQBaZBZN1mCSyM4P8ubDHdwAb M9yCZ50t5lUAw3ibTByP11Hsfd/pgpvolpl5+7dtrgvfXzjtefll0ef9tQ6U QlI8kkZkxBdGFILxCiiwkbkHnEupGMpB0/FBS8483dkDYB/JHs1K5X4j0aX0 Z1lEQOWUmoJHlhNN0wKR1irv8ptyg+bY2HicUHemZadMhQRT6DbCRW0b8zos 2c2KbuqP2Hw/Tsh43MgAB1ufKRkEdUxjeLHZ3qBffc+FLIhdZi899kd2UAgh A8RaQovzyJ/dRYNvdnTd1sudDRDO2cCc8y/LB3TdmXVER9WaoGHcWdB59mpX 5ep4Xti3wm12fjuIQy7Ra26ASoNDAQMHn0cz3yoJ7vBLI5ZByKC5RCVFIw53 kTO1BKsWTezc+GmIdC8XLIOD4bV820PvXAHWSl4Nj8/R+uOSqH7VMnE7ezBE VPwP9lq2l+zNmH1UYJsaYE91cfEnaPiMclCMQndiRLa5ICOftkqav7LrEn4p FA0eNagkniKh5YRMgAd0Y/DhTPAun15cZ0FATHQZTUFAaJ8S39YttX1ftGhF 39DYbYVqpERfyJ7/y8HElE6o1oXOeN0b3R4v3XVI1xMVtm9ttSIdPewqCS7f SzN0BaGZLmzihWtLefQ7R9dEwAcuLbYgOco3KHMkGQOo1QbByPly7AGJfzes YiGGnII2qn0o2/JDvXFPz9P4wij+5QXO2vjf0C03SkhiAURwkuyxnoMeGqYe AtZclK9qd1tmox7+hl8FK+PlfNEPsp+WyZGFztHhvdO6VUtds7VfPY6MgM9A OGiKQMZ088DG7dF11A/5STQ7hHMfRhnOXs4Ax9rTiFB3K4ek/W9B6zLCTDO/ H8Hrxs8vwS6Lu+sYvBLt2kTcRMPnQX6HSW3dseGyknbxkPU1n+ZqQV06nkdq 8YohtHlo1TRnk+lDmaWcohrkOQ0xLtuB61UHgHfidEjx1NggBLatu8bnyIpQ /3SM7QhvzCUMNXnzKssDw8v40A6NXPIsuMh1iu1c3S9Db2eNA33vQ/4a8GYv uWtp6ejepF8eCMYcd32MlGQsugIBdc+VfRe0aYM6OdiMZO8Ebsx5yl6RjeCb XTbw/5HV0TtGQOeoGEtd8PxDPCmwQa9mBSaTeiiu3AOS625R1+WcXLHG5TfT 87plpqdNbhPPuBrWa2E2V8GC8T9JRbDHvPL83rfV70izaG7n75bWyW8k88SG 85GKFaq0VTRs9ahTM5fnWXOS/6q9LHXVPO/ldXJ02flWwgg+/wAH6SkIEo7r 4aReJW8zMQYTM4sNtzupEDAIEjVbA80dCRIzBpcLOQUsk62//Cl1Te9jmZ39 raH6lafj3f+h+lu+5+vh5x/ev/2t8z3PQ/kPgvOkY3ZnnHpan8NboTrOvThe Wy3H/Fu//dvf1fsjTO2soec9wAfx/Vok9JaXB0Ahf184WwlLbRqZ1doFV8ui YnRLD65CbtbXijg78ZO6L+UuHA/zYG7YkyHfdHTYR0VnRjE5pIJIGLYL8IUM MXWtYUi6XkPZM8REFPNDkkRJRjF0U3szbhY08rLK6HX14MFm9izL9utiYfkg 061MTYYq4jYlhN3A2cqgQI5x+Wvig5TeKZ5zHEBUlx7fHsRJ3oGKNK3RrXLr OmX5uhfrQF3gq8kiKEuYQyyJ+ZdsKl/LXf1Sdi0luHXAzFAHyQEvUgL90JFK LCAbHnHsn5kjDvIZWpfk0CUrP+3OleQlI7eWRCAM+Kv7TshqScuIBjyKHKc6 4ZN8JweTsKIeDCIN9Rfjd1FZ28hb/vnv9C8DJg/v6im09FFGgmVmt/Rc+l8Y 3qoswwBXGgl3BcLIRPHAwxAAPJd1iL188Jg6E9b/SdF58XbhN1ct5HEfSUTx AZE7mUPjbhViIwJm6+FA9kBJfOGXuyrzERAINb6vuEDs7xVupTIZ+yztuaQt R8rF28+o09qySUGxTeccH0EcXK1A77cF66oIB4OAb/WT5fBDbD91kHkIlp9t GtotI/hHQXX5SyDzkfUcTPK7XI05/uMe0FUWq3VBXT7bjbm1zREz+awyLuJA ldT8XyBYp6qmrEA93lxeJkjh5+7n8V0k9s5DIJNFsbQIwCofq/++SiEFBdQJ sbv27wXQ898kOKPckBrnmG4nw9sO37fkuz+VnS1j9Uwtj31K6v7IoICBvDN7 5pPlW7q7JgUGJednU+H3y2fBGOMFLNcHjmmKP4Xk5KcvLYvz/LgD20fXtBi1 RKayizOsjC1NHiRPT40vk9E7BTOBrss0OzozS7mwfKX8u760iwahAkTzDjMq R3ds865ig+qlsmYBmDWaFQLDwB4fdGZUgecnz5N1b5EI5gfMXBgycgfH6ZVn BE6CqTHUgrSnl41E2V2K+AW78/nrA+zO/Lv/Ot3J0Jd52AMPzdvJx5dw7BDe 77pL8JcEEN9TAvBGuBB2JwxQ0wvU9O6SbzJRqUgxqm2T46SC3wBJYV8kkXX5 fOO01EJ3dUoHLVMzWH3jcklXOrvH/jTTdU89ClySvhuBdPO7p3SSdw1mP7MP Gr2cNmwKL1c6b+5GOvjjt0Ut7SmMyNKTImYSXpg59WywIUfsFVLT8enqJbe4 lI1+v4LgXDo1ASPs6F6Z5luh/OKS8eHM4WpvcxFf/TH4B+raV1C/6CVYX6o3 9kRW1tGJ6V0A+P7/a+P4Ey+hGt8wvLpEXK1QZwhdpgKkW87EjaTu45hItkqa /s9CSnMAnM3N4kIIWZ7/RYqw5UIsmK6mgElDvdydhkWcz4eNXILnxEZuHM5s mq5stf9HGKJqGrmf3UgW0IvNINPhYUOj02rNPszkRZzRBP9CqodEpvk+hkuR lnCjOJtBi8V1vSjHOr+Kq0NpqO7rXjQY3ZafQFOu8V3LBFIBQGwzGKc70pXf Qj48IdwYP63hJT0LAT65DP1vhOm2QjPByOxZSvuT29sRtPBe51xt2wdZSTtW X+tB/3u3pxDfydsEHIGw2WHI68VfBMlC/UjWZaDKl2uY8ZArQSRwCe+ZFwmz VVsTob17gf+DwKPkpSIF7MlpwwC0OJNM2a+lISgZTVPSIZpQXWiIxwAnJJ8l i+dyFRlqz66R2zHxQufHO56RP9mIOb+UvHw4zJecMm5sEZZEWitCGcEsC5Ne 2mvV8efj62E4Kbc1fBMFjcixJNszyNejl6rWpSdBlbvNcgeXtFOL/oRoIfXj GtcnA5u3Q3RK5E1Fx/3KSSdym7Q+K3tf9nhCvqcSQnDyd9GicfkRb5nz+Ddd LFzbcvKjXjv2bsJcdEwglHQ7mfFkfBtGlEPUIaAnSz0/rKuIt/tScianL4nb FNuqKVloXLvp/wq7op5aS4d0KjkR2eimSkm9kiNcL0Z3MR/7FxDzrVt5cmky 8IdcKbq0Q0RSosnmPb1uHESCnO8cubT82DfldGXCnSEr83KcscWZj217EPKo Zv8hGgm7Ksk/wgGyxC/JJzEzG1O2TNcu1jqvrCVsjC/8zQuACdOlhENz58cm 4Ws8BbnssKmo9NhYgiEEuR2ilQRZRC0nFgeyl6rBgKbbLjukh5erENlnm/w8 UhdJHdF7QBr/l0TX5rnUACFrkiwAqZMtJD+fyMORnsFiJnsgdwe7KkSRucjq gbuG0UsutaJDgSyfP0P2Wm88macjYN1mBhn0OnIrBZfzKi9L/aPxE1BUX2yH 64Ppy19ZM+45Fveb7RoPynIzL95ueiCILYbX+kJfCdYndaY64cEHGTa/QfwV DFMyZjhw8ATI518u1tCgY+SAzlanENrN+KDxL+F0ZMc11kn93srQ100Z+13Z 0/3ekx5DoNGmXN1NXMo+8pPP5u9ISkN570oOGGANTTs6dpICDOoHsTVJWgwz JILAbFvDXj6eOeiTGNeuiF2DEIdo25Ky5kELZwutOJGHXGLytMRTi8sRwms6 Xz8RkwVRC9H92h/Og5HKgIEu76ZPoproXdJEBUFHn9wfXUivKOOcSPULB4p1 4uvdLZbM7pAJzTtXKs/QYznuS9WZsYmmQgfpQZy71Es+1i98DwsIdSkE7bsq butGsvK3H9BAnCT53OcrR90BRMEY85Byk2dejq/Nn8ND0sHxsXiHnDXx1d26 06UsFO7ZJ0bz0JxeWep7Qw9dCMdbd7QC0wcA1tv7l8pSDT26qbrH8er/QZgw 6PNBfc9aXBDr7yY/m+fBlM5Ub60aIusEm89f1gEGDwvMXmsEtEV6SOdx63JS 81TeAvMqjtEhftzuUiy4FrT+D8NNRvFI2eyLC94w5ejZaNYvzUNE6KVBxj3a KAFO2/UonEXamsM7umUYv0l0l+ZR5tAyrSk5wFaLdg3556t0IPjTKUW6PCXr LqU4sgCJJjoAihTRPO6Op/8C9V9vAAB9He89yK7vo/I0yz0x7D7HxOElVUO3 P86hatVL1v0/ISX+s08tdYnMPMRLZ7CTM9DTO/xJ1MpBuYwzxWZy8NtI/y0Y 3KbSjwXI8wvZdSva/1u0mJEL3d8xW/hKBi3+Rw7RBNeVy9OQ3qt4d67VsVjB L0WIQQyyHuFdw0hyO0FHlPmSb90Bxr3dKxi+JwbaievTpQV4R4NJTX3KV8yQ CC06R0YV7o5cIRWajEMsNf/x+f0j+fE3Cj7EObkfbrFP2B0ISdoJ2zWkkRg2 VltX8cYfQ0efIwXs35+zRT0HREynsRqh7TwB0SRDe7p1gInvk8oFp3RJ9PdZ C/DT7+zu9DlqdAIUVSi3xgDd+F/FyPHBC9nDG5kKOV8ZozlDN+lg2HTzLjh4 +EiI+YCZhaiTlQV71fBOCO6Yw9kOVgQfCqjUF7ef9II7/XQZjXXYDwevPvRs APUIty/k/dr85S4eBQ+SSok/dYRXvVDq/IVSi7TRJpNWP10h2JGopMD7CgGG +3dEbnPALw0M8w7Ldfwk7c38XtjLn4nInPM4bwu2/MDxX21HD0tDzlx+eGZJ b4g1wGv3DRJIywd0AUlxbTq/bs6C7p9B37FAgVRXpR4IlOspB9ZGQkdhcWab 3mdE5z16jwH9R3OaVoRbsGzdLe/QZcL7P7UQIkR9x/venddjdEgbnPBzW+dt mRNbOTyGB4UBiw+EmvJlnSmD17U+Wjs80buN/sBLZVwJH5N4WAMos3TvdvJW /yoYg3rXhCdjL3JdRthFXyxjYU13SxVdLOPFModDtTFbNF91p+p5kpCcxU0h wkmzIF5eQXWtJYfXQuRJNgTU2o9PX8wPsAp9jDY09M5owWgmQfVoP/to0s9q 2zY2NjTxatLlaEvraF7/O3MPhR1LHQpKzJgNQ415e3sW4WoFX5VqCploA+9o NiuIT3mTag8F6Y8JjYUrhhMfjwGNN58TKYiPOY0PjwxDk1fLxQVdR5jlHC8t 1wdlK0d8WCNGELif43OH0eUj7ioPcDEGbvBAeXlCQEtELxAxCBLUMh8G7wYS MwaW4+rzyvcLXYIz3sfUR7p6Y0OWZdX0dsVe5QeNpfbgdsbe6HZAJN0uAkTe Vm8TFtrnlDpZDshBz7rXE3xI9AZi6VxfibVqzUGxaPI2NDQ2VGjry2j+z2qZ /WjuZPCYD+EFleZ3/843iyYMQt6XOT9RXx2GhBQ1/SZfNWo/MWjU2DFKhoRo LUtq0HXkuWk1Ql9Vav9d280zW7+5ml87r8o0uN0oRULT3DQEsQEQfCE3Xe4/ 9Ppr0iYPGaM7ZKM4ExsNREkxLmVUByUx3dHd3QWPEEPbJRtHQg3MMQgSMfLK wqpXopoAEL6mIV4zdV0UafcC73dDXl9fX8Ycd95bv/yqbxhjanNKP+jY6nfK XMledFfnwLpAyib2SdBeDQ/u16LGJvUnhxfOtxMdkyMhXXAFMRX+T0cK3cq3 IIvgNhMb3ReCRNJFBJFmgfxVINLbPDcyaR72KYE4QmDDfUCCglUUWLzu5MgB fgHYphoq4EJiIz3yPA0TzvhPNNM6R0mk0zuU81xI67wfznr7Jl8d8JRFRy8J 0/b32JoB18AESdbvBjstkzDF/dezHfvqdu+n9/lB1JvwXv1BJB3NZO6vfjUF PXXWEAdi3p+HdFxKQ/lHuLAnBJqBD3UR79CMJaIw40aFmt4vDv9AZkwB1vDX 0PB8at79dAU8DEPsPAXKcPBzRWg/B6YpewI7rODMV6knRDW+pNl93n02l9fW sTUnpWiHcYkScw2jqTMraEgONXQfMEPz6MDYF/Oarzkg4gokHBXB65cgXQM4 H46aHtSQO8sOOY83MzNs0LGFlTs54tsFJ9lhP8JoxEgrwCMiYkTDXaSP/DgO jF2jBTDFQDgDDTiX7cJeB2TkXD/LAWwDJ99c7KVrlYVQCddCk94fa8FfpLyx I8i4aVLKzZV9N/UV0Hd0l2QgL7A0/Z93fUvSxyINOf2qNw+1vKrq/wX9gINq vJxq7mI4vlEFy73OFWTrQRLshrxcCPEAuw8qbTcGzdExuALQRy9K3/iGHQYl Q8IPSJMuD2CwXl5BS3Akeh9AuV8VvJDgpYkiZDR1SWBfcY16WQ8ExrkvgBq4 yK8/wBdkp4sUK7MKR6ZKtHxdy58+rVX4XTNAu4iAdxhnGM5A0bIJ9E1LogpG fFqlCUa2GpMHiUBU6EC1sqTEQXJaZkeaIoAhLC70agq6JW/3xLhqM7ldWLAa tl9LCvalX6tr2oCja0bDT7aphH1Y8ycTh6UcmgScssdFNiz7UJJJUokLBQU1 AFIQT4ueRwexKw3YwklFkqGPPdJ0XtHCeyPWPC9XLOQ9TJHIACKqIFQxcTEZ DWBgBDmTgCrIx7X4BJkEDtkBXLZP+lqI6uSbmbW3wjMrWCJl6FLLKACT0OCA su6yJhsvN5hLknfyTbw+wBlVItDeQ43q/8UJ4/84IWx/DEATQ/ne0sxCEEP0 ZupXCV8RfQxAM05BT1QbdRsLMkHt2Y5dcmUeAu/pwO7ydrU93QWEyUCxtRde BQ/vMKc9lDheQYx+aeCTkwICfMN4Z0mytrnR4/k+yLnGuze/F99tvlfvkZhk 9Z7Ru7VtRXHxfi+H8EbGpvgDZfsB6xU6hkfJ3XcrtwQfy57GqjcqcUBE2h4R 0fkUdfEsXvDsyR4oMQNAsbk1eiKN9h5r0S+4yQgoew7qbtEFLFgHHHJoMPO8 1jVBR3HKe0sCexrTPi3LeCjLC56OTtCggd15cbk4OzT1gEWqyWs7b0fL6sfd JUhSAKlIjyQskarERQvjYJ9oBzLW1RhExL9YwSUjD/QLdD7EXTO0513ea43U uDXtdZd3p3wuyPYYquZDyOUrlcYJfwc2hTGwTYvLAZbuldUz6AUIhXUkt5FF lL2+R7wgITvYCnjh/0SC2QXbuO+uulzhYEA9dspq+m1PpUbZDuvhB3PukQc4 HcX8pSbyD+oCA/LL68GX11EnT/TSKZihP0KENzCMEmf1R2zT9IE5J7UeCk6E adv11S+C0iGnV5Z/VAcf/JcEL5VvQw1rbMGQ17cjQcJcnV/Sez6jlddx1A4H EeE6C+k9dF8/ml8rQ/ZC95yfI2Act/Ef91N1VV0p4zYq7nKshbf5BNhDk9Mf HkMf73Gk9YDHdQLNG9KH5bAEnMhYmwUEgm3axbo8u5dig5RJP1oT3UJK2hpq aikMKlUDXFxI3RzcbUmAvQJI17nvSpamLIBZawn0/mTqjdT8UMRPZLcwiagC k3sJL7JF/dRy2DtHIfTwMxta2MQ80zN2J5cz9OuvtHQvJ9tV9RaokStEQ2/Y i6RfhSW/EGhMGGgudTQgQzQwXkMCtNRboYUZffsPVI4ct6/pjqXtCCHDskOu 2mXqyHckSwfuY7PASvqQR1Z1IB5C2B3ZSUYm4JRF509GGCuZwp4YAzZPR5uT 2pdTSGg1EbhndlxzDgVGi8xlC1ZHhUaTRu+mYJw62p/ai0NUWbnFPkOjXVBd rSrM5R1CVUKjPqZjmtFv0RlKHEodWVnFC0e3R4GcKsxzQdxByy6hxT6+Yy69 RYdFERLwmEd8+EKusqH8JwiJfRpB1Titofqt7PPHq5xiyXJT/XcmA0Kdj3Cq ngdAqZbKBixAB0DdNVwx1LZ7T2ScA3LtywBrM6j54UP3BwDQawB4LfM3Sgd1 xa0RUG1/n3bhafYguyCkaq/betcUNXPv74I40M4gkAV2QLgcxBxDV9ro54YF BOwAkgUJCRmzLfP2RVcg/0OXZtoqIFmQgUBCckvq5/jiBi5Y7JJZGZaOTum9 BS0GmDqv/U088pTHLQsp7lVGgp0C7jRlBs+bQQmk9tRoyNs3NMs9btBNYwp8 SvXX8NsJCB60kBRK+BFo22xLxNxcfPUmXKnbJHdbKTA+Qohn8pz1+PvsEeTu OSEfbyGB2+ltp/qEp29lH/9ebjJ4VOs3uTndC0E49Ewm8V4ZgV+7Q5nOQbc4 II0+B5htFjNBOyqdAu4pGHsY90iu90RnOSY7maMD9nLY+GbIH3cyMOfW8PpN L0Jy5z+bOzmNSLFvO0KYPnBtgccGT0d4Pv8VTYyVgl9LCiQ5AxfpuMie4nmP TGAonkLrdG0y1JRMCMLrXAI1DZvQJILAmQCXzsJpWmpidBgazstFOcjzQDk0 +0k7AfRd3W+1YNx2QhP2akc5lEb/JftcOQr3QLcVdwhujkNFMTcnSlzLhPd9 MkttoXiIYSRH4Z/1epVdbCddE1n5ekMpJV1vqTk3BZHdmfbR+9oxty0edzhN dqJAW/1il7yw2+w7IyHRREQhGQPi0ZQB37NNSJ4ln+s8BP8jwmkAa2r/fCk5 H9OZzQXwyPmYU0G04fk4TvHZQga1ZIA9gVtdBWo7RgRVnsHJTTYk5XU7EV9v cRF18wyKnJ+XOFEFD/30M9XOEeWyckI2an0+75L7bwWqV7TwPMikM91RUrKw +bnDHqK066Oz4TYrGwIPRKlTVURPC25yLTkudQlQJ3o4YyqWgD4JwLVeeboY 7DEFB62QBR0f2fBlyilFDx+QIRYcxmoLC9ZEb0utHwn5wpAuPwVlkV+tLgGR 9OOGbHT4K5PX2e9LTy2jNbfC7P2bOdsQK4FepwNAIiGz0nnWR+6e1pKtEhfW dQtTiF5peEnIDMvSPbstK4UjrrDAPwXuIbFDkzdrfFWq9wFD71M3OfErMFc1 k4tFRufc+TzQRAJ7qU1kghXIK2X81yhO+b1zlNVBcciAKoFAtbqkz0HKxHLs gF6CNEdq26qJt2WHEKJfPbcMTeklkkCzVSgqqfMeI01/YCStM0BlfdRl+/v5 MoPM77911+W1n5vNpLsJRwVuZtgDpfQQlRjwumhcAW235X1edlDWnLQGCY1t kCg330HG4TLgHZwOXZMtiyFZX9hT4Oci2UGSKR3sRw8Sk5YD7R104iFHgGgt wiftf3w2h9khSaNyRrd1ABEHtOas7g7UPotqdfYXbDNc0TmzE16AvW4by40F vE61eMkAdcNZ8vAd1n3O22LVhD+xIYehdOtd+Wn/ckuizOtsdV3F/wZ981DW 7oiNqlTYbDaspjCFU41VmLShL+F1Qrmp6jdL20LVCOtVNUgA8kVyXNl1lidl 4HXhSCCLA50j1/yY/Cr/q142I5Qi4rJd74ldLpH0fZ3x3I8vgdCR0e7cESBJ tTncsuqRSIY4Yh9JCZwnLsN7BBEX7qXWR5mJD0rOkgAROxBnreYvyF8vJxxw Nm44i/MoyPUG+OltFXF6yFJD/1KR2jHFMRHyd3LA6fAnIjmut53b9fVAY6Pa WrqOn7s/jH++HcaSQCogVxjg3nzZhVTcQrJX3Gt2Ob3IFthKylDxuILbSDp0 4eGU4s/OL5QCGCGdkK17aONbOW8/t62uFkVEXlQNa7lGQ6DLXStnXrU3E0jd Sd38H5N7FHWEcPX3dpvxQYFBmx81BmRPAFdd9wG2hBAaGnbV8/e1kt3RAQTO aNonH5ZD8UMZ6Y8fQujlnwHEl5jsyek1BoaZkFhHPxV1dvWXI3K+rDKc/760 whWOobfWXlCHNRz3qSFHPLmh3dvdxqO5Gw7ZVYE/QuYRnR5hgvGUIUzZ+QiO 0hBJm4Co5wltklJ32YGa1379xP9he41eNshwCuwmXiGF6GrzjesvuQn059lL zIcxygg8whJFM6imXhuvMfGS75qJIlfTtrxTDMWQcnnPfEXWNN2TST1KS90p 0xZ/JUZBwBVFRWjpZEvh0DNBPUlFf9a0yI3Q8/z4zlynOFIv8xNoXWpITwL7 1wmCBlrYNpHvAoGXz6yNpEzNEDcE0dpX+NATSfCAudOk3ThWFSG9uhfwuUL0 pdgrE+HPVgl/7tdmCklTWIkHDbTuRYL3OdEtfVxEl3PMm02m4MU0Vahdivdd r0R2iT7zXwOrWSvTflJ5GM4+gioEWvbEkIl15S3/SB3dSGoy0T4PkBqBdyLl 8vIEM1Vk9zEexzcnISQq/DBdb71HEx7gof0xxTEEO0jb1zUTSXUr5fVTIITF ljzbeiOfhQvLvV4706l0JmGnMo8tp5fbC6dc4pEz0bVCC703kcZLaPRATb1H edSJdx+w533v/SXxwL9enne6Ik7h9DZEddfxlJEnQ62AwQvN5atr0HOTrYpL M5eBFDq9HJ2wKd8rkWUDiuOrgQlOwyrs/sJ1xY+mtUHFg0vW04zhBq0l+M9V UCZp08GQzf6nLp8HkrqBbaQHVbzT01G9emwZ1V2zp5qliS5E4pSBsbKF2J2f cMn4nRHSiW8ThJ+fnRkRF7thy8vJObl/g3k/jezGgR4/7IO8e/Yk7kHY7l/B tyCQmAgVCo1PX0YBqwlQYTkAHBCnW6w27SWcnZ1raGdpAO5nmWZpyAU3FyGv gQ/Fd6TfkoGk/shsEk4CX3thxXudV/tDn1+AnaNuSMcXAS6V8qde7hHQB5FG khmVnlItTl2bbimPkyNHZAGQZbR2KAOSOF0Xy0mhCHTLAHY07qSkQ4Ilh2ln hZ/gzCKz3S/OF9TdQ0Q4AyKDrWI6h/OeG1/JYb3SS+MKJJNrr/qNceou1hWS 9ZsDfc+TSEoJIx/MJLcexKfKQksC1qBjwCVdKRSa0EE2H5HQMIZdhy+5g+ne v9p9qPpC5HSnneVALtKHRM4oqnL7OYBF76IltDIoQ7lkVyJjlCOZQrKYokuA BBDr3S8+R19D/8m/rufLcsa9O4KSl19En7WT9bBf8wmLPijLlr238z1d/0U8 LKcv2eboG983eKvxs4HD0UnIjTX3uT6hXEs3Vd9IPy2VKAxFUWco7Je0NVnq Pvc1psJQ7TD6a7eYz5NdZEZmoxJIHArjUn4H49wgXGvHukjjrEqD7sA5XqOA vEG9QUEK+uADVrpeLV6MxVIoXkFBU1IrDFxcXeD1zo5FwIZ20RSHMzQCfYDg PTXT8girp7eCwkr0Gj0MqBxUSov/DOMj06cOkosy9yVvjUBFBcsjtVwAXUxY Ag6fQSg1dahnP5PTC5Q1MCJMFYehXL/8CMFuX5syZiXSReiPKNe50po+/J3u iO2cQ4MLMrf18HSDkuUBXMxJ+glM7+DAj+aaOTjXUp3xvDGxrV+fHSUP7t9y G6tyNjRB83v/X7hzQzsN2AV8CuuTSYXuB1mrob2TINzA3GgJEMFD26tJ249M R7oL7xlA7xtB/Uh0T+1auS+7ipIpaxkUci0e1hn7bMBGfjWzr5a/QDqnHs/p 0Q8D0/WTEzrzPDEmp7loZ86/Kvdj7rFTIbGaRa2vgRXL7fjgGlkiut2FQYde 15OZNUjD8KVsQQuJKSsit1XyiSv38kkgpxA92IpE95IlM8/rqfz1bMo0eWPF 1cAZ+GT5RQXazQY+yjdJrmyEdepEwilqklyPVwhv/1S+AEFCHe49Gzg9M1qm 6u4xOcHARQWsZshAbe6Q/AcvfV6x7E8vQzcACt2bkhk9PqYps+fmWW5f7Vqi pXpZ2PdZRTAFMDxzJR0z51lIC39JpC56SfA70zV5RJ9vShEoh6MzHQTBHN4B s4jkQmc8Y57e40PqJbA1PGXqnM/UIl+zNlWMN5z/BBmT7jMDPGD1zqEHo4lB /l7hxQsEVkD7f8FogVYFqBx3o/RAw/tRU8EJB4sCn/TI25GTKkid1+8BB3uq UXny+1WfAvtXl2PgQbeLgsOBHWU789VhNV9y+EGqpwLzB0O4BagpnUg1Qb+E QClfSi/lUJn92tED8SMeLG0Zd8nVym82KktB118NRsmTvCNAXV5amOsXWbR1 Rmpe0u5XCUMj8cJbX9ZDeLvVYbSItq1ZdB+H18OLUQXVUPGXE15cL+NEStZB 7Sb9McR6QenFmhdOksBnJcNh78jvksUfc+yRazXW2xChvdPw1lrnl0NXNahA 14e0/NodDcpqdCZxoJTcLrPcOBHIdP6PBUcyJC5K5XJ8P9wCNS6/x+M03iX5 BEsdVSEH3PL1XxHYVJXDCGdFz0NmBrA4NNT7eGfx0Chni8ZJQqaS0rTU/uwj ReXtq0HsEGkvXVhdUQU4XJIoH2/DyHDK81+3O5dx/ataZQc0/8TbGHZ1nwia 2SlwXfyhRTM/Rv/UDH1Wo0iO7LhAIEuBX3JyjhdNGY4YDpOiF2BX9JfxXrVF MNXuOD6MN7xZP5u1ocGTZSZXVlihnVYRvf8HjaEfvhzTtC6Oeeq40n6ZvQKy 31AFXjOsU8IoLnt7T9qhNyxPxga7CN4rE9rFe54AeR3IkMcDMa0cdF9vlJLz zGiWf3nx1pI9/cfXfjUhitfuE3SS7HI09TKmXbHDm0tOJ1c20DFZ3nLLHnJp smRDBmYrsywGcDMbfZDeEvOQkMM3dL9iSL3MQr9dwcTX1tNBVfNLiv2w3HrI g1wIwXJ+31qKPw12FQP8Bx8KTAVGUlwd9LN08ULKsUZB3AAZrNo4SgLh3M5t kG9Ak5IAbVkmjPsDwfOZldcqVrAggJI28gK4sqr2y13cCBloQpvQ7uGxesjI 6wXGAJsFkJoGv/NkXFyGBnpekIitwwh98VAtKRfA25hfwF5L//HxeSaAI94F TpUFy4RpWMhFOLdwOkX73LhF1DUuhTpcJtLDMUXgfD5nnpCu7F0orYMh9Ky5 gT4/Lp9APmR1djxhcvOyyAUZBZx0CmNQk6NfR58jQsAF4l9aNz/8yQILINJW /mtQsN4CiwelpEcDe8iPBLILJcXZZEFQk5SDG/e4M74R5bW/oK0HUK1BchyD RRqP1B6UnPS2JzVHx+94QLvD9PNpbyPuTc4BtShX8fhAxi3yRsv3QfOV5tF1 r0cndgaupEjUl3cOdH83hUUiTcKyewQdT/ytAJcSQH5MINWfQD8jKklsH4Vq 2+bYAksJwNFHQuh9Q9O3DjXh2w+mG7FHwHGVgyi4dy7heETyQxGXyIfAhdBZ 7YO/81SOh8Vvwfm1o3iwB4w3jwJd/593+I/F20ck9GF1mud084TVcY1odBOF OT2hXG7Fh0mIQxH3zeZ/wSOBD4k9xrCvRISMqVuvYwMpxVOUedh5osb5fzpN zycGpfbLSSf3SkZXaOZddkvwLN0LJXdISvX5JNi7KG50KSqTQTU4ngQKLp5C y4WWQPU1g10wqqiFPHw/yHVKaZDVXvEcYEtBkznXYrEDFz18bPdTMQNJ0KRD NUYuZXlVInWd/T68eXTOB9OO42y04nQekjAyk5DRcuGqaO4FXbfzQ1TFJeoH 8aX7HQmdBO/uhSNdkdiMmAiJcRMNMawQy/UCSKkY1Yj0RoV1OYmisEhyGzVD AdAd646OddI40jUELmSf4k5SB0TILjRDRM6RpL2dl7IC/BAvkgWIBi6akbbz fgVChQIFqEvf0FxgkZLE/1MHepBx4uCLEWeSHAd34G5r1whxCxyl++6/kh80 wDsDp0//lXRySxVNgvbZQZWDkO4yaO/P5oeDOXS26fdI9zbQb3TlBHQOJf9D 6SVfCMRpo3fuQdgVJVWHOsDVu+7jjz9DLC0EcUMiLXVichQ39yc28EXvsIKv yVpHPK3Ry/RpyBYjK0HdZyAzEPWnzl3BkuzYiQXuzNgFHSduNWLICXS77vV0 h+uemwZfg3KtND2VHLeCzOwo/1T7dPrQggZ447H0tfU4ffFLHBng6Swh8VMN /MDHfUob60oJ/QwhKjuA2H3A4xI7XfF416H390aazIwHD09e2epyoECvR3J2 jlxPOrTzmUVqmKp7OnrwHvc5KEjwmOzP9D54KnRLzkF1RixpKI4xQkcYQSXj bwZpudpTUz1LztGVQ9lV4WlIBlNb6I93+Ym4c5KfUyqDNlBsFhanRsBYLjj1 dV3BxXGDkU2FlaOEJfXy5U1JS6Mf8twHWcBso/0WdSuHL0xDLz+WUa1N2Zij ubXcoXSeX1WDKRjHz/Ihqy9BdEJgbGSZaArL0S/f0UczNDXls8FV8/PM5NJk KcM6C+MVO/NdHqRVsRKn5s94zC1G7RktQTE6N2UayGRz0K56Ok5E3h3o23gq dwAl3bQeFgXGKUKQpIYAE10HPAUy6LG2gPBd9/Z01jIvitXovRlcxz0TXTVy jz8pdTDkedo9SRVAdNAqTfJNZfDbgSBwgUWlXaNJZUYQAGLdSF41WBdDgTZM IH0B0z+hWkfetnXKD01y3xXn7Vz0W/ZnrqpsUca7UW4TaqO7f9fzwzcrPmXU GBTYX2r3Kz9DaOTvtIQuhD7aac1GTgmDN4AgWvVMt5y5CTAdCxkwOs8CeBg/ F8tJ/PBISMLZ2WKU2RLZ4mgsj0kIxUveLVzc2CTrzHMom10/Swf1wpJdIZIP kaKvJ4ylRI902qZ5aEN1IiNxLO7owrQcrd8wT+3y2sUH2afFQM/XBjDXCDKb /MlWm3BzMbIEy6HBtMUPr8bu9TGPQUXg0T6q6gi0YCIopEVoLmyyvScVdkM8 ACty/ydjxyl1zzu5/6nISdOtNQSYNjFAZucFbvR3Lp/7fWg6TqHNm5Gxy+Tr OXIo4nMpx9CgOPQVHO9TO97pIrNiKkqAsvHTZUNxpaQOezpcXPR28EAdfa7t 6yDIXrbyJcuZdYaU5Mg8QPV6AdVDdeVDbWadhEDmdUHmQUDVzlyBcpvJc7U9 pvRKafVyDo1rWEAsU1LIZmkiOXYT173G09zW2kNQSaMtHxOZR5Zp75C/22g2 VD2HZSio8cZ12jnAIXVIRRl/rxwBCfU165gd0+Y57gMrxpMx2qnC/cr+juHy Nf7IQ8/PxyJh6f2rQUuMHV/BX0HFIGPDXVl08kIDOugNA6nHSVlLFr9tt7Ak vCSiXc8mgQm80p7VXxofMcEXEvbJzOyApBn3IlUI8uzqJYeQt0TdMlxEgi6d slwyC7eHQCBnmLv3pHfxSWx0stlBtuKe5XMuGsjzHlwNhz/gZ3gTzkD6gA5N T7J1bV1PlWjxAbBIPyAFLZDRBV6xoqguWTVoKsRcDfZ2m7D6fBMd5Ec5+kd0 40F15ePIGPFAN98sQV1AXd9fJHHzoNjlt8i1mhQCn6Dy+X1sd053pW3uJ7v7 fHcXLv/qSmM4qu+eqRc0XZlfRF0bX8Ju2rNIxbpEng72P0PdQJi7Ajk5L/pJ F9jwElm5LLpb9v5sBTTZ8QU4Sgoe1OA7tmcceAeRXvVG6I8HpwJdWgVa2fJJ AcVdB9ce1S8ZjIk6ffOdmc54xetcpuRxdcTbOMnUatqemfjHYCFK1mXedhWM ELjH2C/O29NJkXRc81w0jRW6XrJGxXcvwtNd715epkQp351TUqD/G21SyF06 uSUu77hUKFp9bXfegoaDtB/CKg1M9rvv2tcuCuunXVxHQ+wxXEQxS10v0IbD Tikq65tylpBGwX8Vk+KXmEafH/9bSaIxB6TRqM1eCE30cCxak8pSk1MbPwdd BLItmF4G04sKuqOT/yyZhGZ2bkux+EBkku/uCYGWqBUEXX2plJXKoQNHETxk e/SqNJS2dbOW4eYuntovJRvdAx8Dei81B/BxSJ229C7VC5SC7/MKjWjfQTFD HzfvitY+05QT8EEYQvgAPZAQftMZmBgXqydhfRTrXBeaWC91zMKOKU/7QAf9 +UIBAS0bclftREnXMBT5I9MbPvi10aVDoWgZyBiKiocE0yBJghIdmT1RhDvS 8CsMldB7lsaSXZPu7jXeCQTmz9LuCo/WE7qYXl7dJDOd310GN8MsCZBwQnr0 cM8t19kBbSELft+YrtnuWZMh2TQfhQMUSkJsuQ9dZOQjTIkm/MFNyIf1Qirz R6U0TMfonkHpdNHa0fHWIKKWflSn0XpBIMB7XmotF8p6hMr+LsIL0p6tpoAp +nHalnYBjSnm1WHNBjUFL22cH4zmzx4HV8SCpM/73+crDRcA+fAKPl2X3kKl Zt+H0NIHy4qU6MOoSODGRpSS33KXGocKLMdI9eb3bvkUPdPVXecv5cjO05FD YKPQ2NqolfhB5L/a/9apLvrXO5/wQino1Xr/qerrsdT8+Pxc/RzXOrWYDYfw kFzm8Ann8DtzcMQA5s42DPPOD8/xJ6R1IMT78CH1eT4QneDA3Hlep85HpETR g6SnrvqAYMeptSt/kDAauhxWn59teHTf1ilA/eidn5+d6ejp5MLEfp3l5N3x zwBxblj7UES5w2qipssHb/HH2sE56suZnWzcIMujyfxSrWsiUYQmWaIl4tKn Wzq6ID6GVd2jv/OfUVjWpHQsqTO/zcc5nkCp3aek2rGtKk8jleORkvJSBooF tVt1CUk+mgPhxmDbjtpmqO9qwnrtmY71lNfb3dqV8nrNRNyQcJqsFyl19d1D Iu08OAhXt3T39iA0OIjlZ8b46d5BY99bQS05/50sioZBSUP90ifCfaoB2p/V Jjx48LWOjDVn8T19KTfz26ibBY7ITnJD/UfPL0uBLteDRQVOxgJ07Tqt5UHh QWTMMkEfH97o0xFy2ucDJZyN3UxKmI3A8tdBJzteQSrzXDLSlyxxQENqR96c FHLPL0w16OoqdLHIy/xBwffS6kBi3u1MU713fL35ckDuri28mF2Jv2YpAd43 r+51WLLXsyaEARpb7f9Lje+skBrZvD+lmevdbCE71Lr/vE/KvRVjBWiqSEf/ NNfdkk25FyL/4+kwdgf/qWYgr2aK3hsyIDqHoNPEmdIV8z44N8DpD2/Zv6Xw Nd+uAgLzLYnnqwg/WzlinOOykA13dI1Cwdtt9Nl0SUC3IxXEZo/RRf6o1W5A otlJu1wVM4TeE45EhmWIUF4XiYtaDdHp10EajZx2JrzSxutCODVGwA0qESWK wwoXXjHePftPXeDSQ8jzkkU2kwu3n7tIQ9waRVR3yB107SwmO8eZE9hajQ/x SXBA80XRHB+nPxnTM2AACQ2fX5ckEdc95RqlWcWucoGBYeFmDzPWy13gQ236 mqf3HWxzw1TDtGE3SQh3LtmuXefJP112S+xBmvdwGYMk/+Hcz/MxrdfXmi9p Ks4/BC4FK1p/u9YnRQL3xKvRKa/ThSit5ax8p4BFNb2E/v3ZRX7nNFXFEb4q 2qwM00Wg0TdP1JHKvfBKKV1sd9w9lF/PZafX3Hllsl/NsjY0NQ28ra9L7vMY F0KMShsbn790THl1rXcT3p2nnVhhJeb6MjqF3jG1CAJt3e/qh0OmAqPRa1Wx 4C/cAge+mH/CST+o+2OUx5m5gJIMWb4ZU0fhnAkAENd0w74kjhkUGUP9R2hs 4sptzuRu45foXg3X2EluqwqqYJ8S2B5vmF6g+of5YqtfppaO0lLgnsYYgUNf QWcnPcOXdKloNE2HLV/504d5qthIHANPUximyVeo1NPlEBsjyldeAZkao8bz b+i2LJd/7rlmNQ3zpVFelPkaXOQNLlvJPpruSDL1//eiRcF1epNGwNpBiPv6 t5IbNMCBACb/d0/9J/RvfSRyIyuuwiGCPMqf4/SgTvANPdslNTBL9hg5VvCi Ws9f8OBy5K8lzueJmh4orkSO7qAcP6ixGCb1w0XEUrSyY5QUHu/VKybI4VNI 7kmPLdpgerweDIQiBJQrwE1fa2TqzHI4jg7MTRwo3Uva73FFA7vHVN+C+pLe NcnoDxzderL0yq5SVN1Jyy7dtDudZPGg65230t0GdYMNhC8BaIU/n5510Hpt XPUGDN7f/hrFAE0AO3Lkr4Tk6lsAKYumONnGrfCHbABBSCWO+ERzJU/KnpDz Kx62DSdjd/SnXTuqY2lv1WorKmviaiLLa7DKtYEpoy1lgRZHIhpbqZEh1Ilo P0kUVDV6iId/RsVqW0Rf1ahWkB3vSOUd0HzT8+gdMtXA49vYHNTS4tnY29Qc ndTY2SDemPMQ2tvznwTz2dAvP4bBS9ji2Nsu8yAiISnxAfECpziIYFOLPCz0 iHw70wdQqZ0vh2X+CsNFlze90C192pAjHjLGyyZ0sF3deIQhB9NK/uBnlLdH CV5YPOfW0Dw/RlF0i3tp6+YoL/AfbODeQ0GFHPPaLLkecnsKJLVVITap8RHD 3pQgLpMbSdLZBf95LHuoZLioKkzLCDDUR0P1TSr4CEC+jfzM+/cc7d/88VxI GZ0sQelC1jXxivf6dEhcKfFfyUkvAIIthPAXoHxw84wYttow4nM/koixdUbm IwBLr2nCdl/OGN76fPoqmziAe+LnQ0HTx+RMzuvA+0rxRzJeCpvqO1KTmD+1 X0HL6gAHmC3BaVACDcjeXjMjlzVGQ3JCAit1Jp7Llx8oGq49knfYQAEahSjN CnbcNEEVMBK0fV/KBIcygzIVsgND3hWLToUeNUGiVVoasDdNtIx0f0y7O/Mj ku/G+UFtCUsiiEvIsrIRDwckFZhQCQuTLAMvZkU30SQir3C2y2XVn1xhtvsi Lb0CBWj5fMalqL9In1pJu76pHeyzn+ej9kpEiV5h/6J2S7zcB8ey6HsOE0XQ Qo3cDEPxSTTCg9F2a9Rzo3F8uoKRJvepuv2IlO4o2c+75M/rnwBIDTvxSiVD JzW0SUM5r18ZxBdSNohnjeBB/bygAM9IZyu81p30NYey+LcY1+9IJh+Ehzr/ hMijSOMkDEWY07MMPof/umziyosy3Etj3EvkdYmcJiQrQYu57Urx9q+cL0Gc Fjxa51qk8SVfnyPkng88BMmLmoiuVqVFnKscEDTuyFOMFxJ/fGmd9yxogt0s 3Ys61u11S5Z+SlKW4KUj3g7jSox2PsJAtyPzQRiOvRLyVfjffEFWxUbw0ihz 0NPtnl3sQ85Hqtxxn9Wx3YMzsd1e5K9eGuxcRRE9KdMIQUIVNHZ1NTuD8mnv AF0s+keCeXHM6F3WknESjGSqdDE1BsLmdKDSDF5jCHVokUJKDpciMTi81Hl2 tWPOLTtYHMHWhTK1XWeRDtDANV2Ispv7d2Ml9N5S72fZL5iGQk/C7wEXRlU7 9NJlkOqD9GWYBT5KJ7DxdGlks0I7bEfDVIg/GpJe+DJB3KoIsMB3UsAD2A28 aCpQRD3OPuxX3BRyxhUDbbdDn4kkdczM5y2zSA+8YsHxdf7aNgcjCnffRUT6 K9csdN0z0CicrJWljgX1dVvJRJju1xML6s6yA+xERiI9zCCHdnW09frEW4N0 M9DkHbW6bJpEB9wA3NkS+54S0ECt72KeaKqYYpl07swu76mLrkAiFsp3S0YC 3E5TtvErXo/ABg9ElgHuyYR18qa25N0xRPM6j1/0Yj7YSDJfhfEZ+wf8A/cm 4N8E7TAh8l1rqoMduUFfOiQLKazQovoCL8lNkz5uOnZgj+ZXpuEukZxc0e4l Hl8cGo7CaUQMSo+RNTU6wJllHwXbKBc1tCHc8ENMEZA61lLWA8YbI+4TAOYh +zoLw1zNDhIyGKPMo4HZI5Hbv+hWu4xZoqLvJqdy12x3JU45BYpsG0oYHlBa DROMg7UZ7Y9o3C9DXUJLRQTTOdof0Hk7+3+Sm8Cj93T1G6mPBAk0arIKqXHp afp3VlTomI9A47Bs6LtV3N6pEK0QQ+bnLM1DF7lm8dW38vBdm8jmJnpT1yIB osm267xxfkI6O7kXp3JzsJk+2pdDuaznwRFeK+9dBUdfaqutbC9JKTmXEl+w Bs6WRwPRiJNwXu+ROthiBIcvAOn/Qet0zbfRQ4OfJkT3Bd53cZ4pQLc+PW3I d1/wHltdOt0XGx+t+avamyrRCqNgJZBFR6RF0QMMBNeICf8oeNe7v11JI1jA zdfK1Q/FRJBHSzJl3T5GUTSlJRVxMB1HwhcUe0fgRcPjAU7R2krtbTiQNOlf VSt4Sx1qhkQqqjgjB5O6Y92VSEvfNTDFRzj1O13T1DJ0jjDVyjB3QOO9V4dB elqOM9GfiCCN5StyvqEPjEk+y6HzDN6r3UfLNzE++/THG4rftaZrW9rbkZks It9czTcvBAEktUYYSflW6YESfAFF3EREuQvcqy6HQy05Dj+BHVkCCRaBmQNd UuYZHQF3Y2wY+8711uF6GwEfRMG9ZUTJSE5fO5Zz/3MvB0bVrizBmOdeOKtO UBtTrRwn8F5NRdGTvgrHCtHZL15jLMUtkyMp4zRHN0dFW3d/tRbBdYZzVbFM UU/B7zmsy39Hl2ZEAkEMYzxlPrhB5JxS0TD5Qf/Ml9fOVpPu2m+xw3MTJodd XA3RgbIynB7Ry+e8UAu0lt3WU7zfQD/+fbUETtcyT/BDJZrv4Vz/oiMkxUNU HLfEd5b/fsJ0WNU6219OyIDxKFs77tM5Q64v9H9A8DGvCOcDpQNU6Zq8R9dE yYhAnV/1xGZCN5lGIkw5Ct/SmEiJQQjln2qGQC1B9l9rjK5bM15Fhy4wzz8X UBnIEr2ywqVcsVSY2plzDoR1BfMP1Z+EQ6sKIDEGEzF4DFw8OCY0AxbpEiQe /1wx4Vwadhn/uewMChx00AgJ+TUQT138DV0gq8jIjz9vzv1I9VRfX5QsVZmR IWyAVc0E1ckiIp26dS4wVckIAiG9Iw77dENZKKV77fCcQEMMakHzPrcMUXLd uqwziK3C7x4l7fN8NOQgVYhdJ83VAVgSfIhaglXKXtbKqlKi2YVcgA8rnaMr zIV06QrU5Md1cdUl7O9BLiD2/IfB6rQmk1tIEjO3h3/6AkiYFvfoAYhp9lXS xtj3NbJjcsp3Q4KQpbuDyipD1DDfHLyPRzU/JhCHB9jIy1/O+agE0aM/FfAf bUiUJ41CmEbYhZITbMIAN7D/XGkv8zLzP3K/L9BJbWPoSwtRpEMtoovCpl87 Td9KupdQ/dOjBGZa3z93qqKuq8BQHeeBE3QRfGjMpZWVEEBWC1htQd5P1VNI dfE8UOeyPf2gwYwFEhFeP1tYYA7IaitRzIleG5+b1cYEwhQnKCN6ALVzID8w liSk1CPVO0glagRyOwE8OvYmqCBUvHKadZrYVsfVRSxlJh2y40/1oyvx0DKj 2ADxmnG32oBT9F+RsL3e7hYo7mwOqC2UJ31rd9q3dAsL6i3/nEF19wFFTNvr 8gtYdy532YIIB0Is7EQaCZB7Fl/rv97B52Nf/iwcQQAvtVWQZArAn0+fS6Dq eSaHXF7uNJvUQwGXd2gO9D+/q0gPIsrvnI/xFzU6rLWMjUJBIZPX6LdEk6tm UavCE0sXDRRRhfVyKB+4dxbvAV2r/YgS6EciZEiVuZBKLyJgXHehp0zjYQdB SgP0e6v4XH7qhcvTdgjsv+I8Jy5GBIGl3+E/QcIIIcOiAUOu0+WrLgfdm3Xk uSeR15cPYNzRuEDXbqwGlOfEdfpGPFt0Pt/7BlTrD0X3gSdS28P/M3mInK0n ZV0TNKeTL3GkpFKJw8cFLyGs15wjUAanXffjPzoYKSLOxNEz41PkRwA3wj0v 5Z3yOOBId91q7KVeMhlaupJWYaRTmzIwVdzDf5GGRzI9Po2b3SCESRGddZI3 XZJ2YmN/HC+AunHs3QaANblucbRhX9zeL5fLJn+ac11PHEtTpmakPIkdlUrE SItBL54pL3hCzyjgBHYs3fdAIgrB3XT/spgwxx6VEtpxT5YnwHrT+dP8GEWO r80E2zKFc0HQymNPe6rfQOPLH79HeVr90din0O7/n8PZg/f3x6ilh6n1MN3Y tjeclcPT4PfOlaunf/3qIasVd/+t+7gNIXI/XuuYpBwtLCwdur8PrMXCOgy/ ulPFPSy/ur3M8desuo3kOcZ1c0IX28l1sKh0Q+0/Y6ty0jG5ChJ10rAkADJy t37XpkMfCXWwle8VYzPX98qMN19FjBwfd8qaXBt0F3JF5cc5vXS885xDnb2r M5xIYQSrQ711dOHFAr1D29vXPOG8q3Wn0omIEtNjWSO/jc25Xinvq9jC+DyM QY2NIQ8oCqLs1TpJ8iDSn71BX0VtLqWtUbOhFnQ0yWO9qSXEm3PwpKenyUnV QrO/vayb18Klvbzv1JDVvPfXtwsF8Mc8Kgvzv17SxVNKH5vjYarHHB0fHAwf X4oeAx/3Y2E9H7xBUfLjq5xT1EfX8qt6R+9dijIbUMwjtT3yv3TV4Vdjv6kg L8NbjEEfxwn02B2rI0LSkByoQJya0x/hddjvgzGKkQ20dXXkR3nvpRjMPg4x 8zjhAtMgt2/h63/rJjmpIfoPOV0sxJdGM5/SF98PRcO3SKhDMRtiDm2lIKog A38hq9gOdS62LeXVrtuRFgUtY0NR2RyKcqcb36fl7psZU7zjPR0cpC3QbwIb U6AVptcmL0UZuiRDGmLIh4DKH1E8NnXG9SDQ5IUcAU6fF3cPpVRDsVa/q2Zn D43cYdCN19ExMw/1LCxuLbPZB20eYHcAdUuTR3cIVVNn2TV0PLC+9O6kpQKl XE3PC93Zwl9Rqy+TLyjP3XZ1Q9h1UCTo7PFa4h51Nu6LOJEzVSp7yofRugqg vSPX0dlO6nFfpHTETW1TaURvmgUztC4yD0CXV9nXf8Qi4CN9udZd/8O01oA6 15+8tVX7VF2aIjxeuuNApUhN1im1MTgeXMopBy48InPRpQUFACPUB6CUlB7U iDzVXGN0DCA8bVNLY9jbdJ/GVpUgWw4A/bgZUG/Pb5eSSUTLhkcCjRhHRKiF frl4Mu9HwrVG9zlRiFCWgufxeSpMwjZ3/LYoyw5UI+4aABq8ZCfeKG21Mo/W nIyh9FJAYctyQnXkIHSL7dOmEfPF519AQe9f8MtIkdmLtOWo4posflr5LrvQ hPn46e7Efl1Nxx13rH4yBytfQEu8+r+U/T77RQgc0D74sDqDsv6lopoDuUVJ bGidO20I/u76R/0P1d8PrSKFJ7VQ3FwuCRPJWZjpk9NPX7IDQSawztnFMK/H B6EvBYzbAFmX7IFGhxqHiTYWIF42TEol4NjXgdIlRnxvV70FX0p7WoTc30NK 68L5twt23gxLkHiD69M/ACnxR0BEkDM9XmTVNTQqKCbqqZBnFnZ4xptDM8if BsDSSJ41qXZz6LGDGCSM6WFHwqsKC5LhJ9uFQdAyE32D0TcmY13dJWszla2E E0Tx3vSviowebz3dI1ndAnIjdQWSz4Xfh7P4kswlopSOaqp5oBP54t2qDB/z DLuhYy/VI0LQMV5CMyirdFG5abpVwqz3QhvKEQkIwUEQ47KgSSH8JNs5f/pH LN9G0B1mRdhSRFL3RENlyIz29MjAY3sL2uBnbwfc8Wv1F1oHWXZYIi7hllrK kFwE1foAt/436KBoVS9z/3UFw9Wjejkn13bKlmvKA0Owy/B998BwvShflwG7 KwaSQ2/UH/1dLUp3g88VNTmFM1/RW0fDR04bngG2IZ/U5yzljmuvBA71A7Dh D1MzmzIyZrK9idF8mtdvArdXmfH8y1FR5pcWQVUtkEMFD0tVNFFcB0Xa8fVd y9O11lkEALrdvMDq9yXgXcjABz5PSzYSbgRsl4mW5EQHxy6kI9UFr4OS1+X3 U1ApYtEs2To2CIxjLtUN7g6I82OhPDeK97BeKLBoxfvKX3izQLBAKgYhDWFD N0N10LQZHdL9QNHrXkYur7LAx/KrnJwFR5Ph/ZycnJzo5PHNCC7Ch/hAS5fD hVsxPzjdL8tSYaENd03FY1AM/Albn6+nW99bUmGjVeeg47+jCvwJH6s/pR80 W39DsPhbCzOcj7sLB1lbW1uR75iXvxdOp5fYy6Cyy12JV0OidQRjKplCy34+ 3xvdOLFfSJEwwvXb6o7M5TrfOLNdu17fpFxavA4F04N1PGskSsTIYSHDIbdC pADeAW/Tjbkh0eS33Is+BUB91G0StFvR2Gsbg/wL2SgvODrbH7Wj1YNY1hKk I4HSSieK1e7+FLJmCaa3XRHSniIJU8AR9yF4Fche+C1znn41m+hc2MMpAEbO jiBvRcsTOp1z+ENGwsB1tN99t5rIbkA63WSVmtTl32s9jAzZy0fUjQQ3Q4yb g3QbnDs6DktsHtK6ZXsZphtAQQQhoAQxaUdBONVYSTA0X07Rfpf8NsbnjhH5 dTDuQfvLTnVt7UhVLfD5W61nmkPRBwUFiKnwOkxYWweAIQLILKNMqmNbU5PD BB6JSUTzL+WvUwIFuB0gIdNUebPrRAOBQs6MgkOUAielzHR0kwLdX2I720jt gwPbVcFeQM27pHVosO8IXjBKkGjSv1+yqJ9s62zvqO4H4qJ9ck8BFi7LS5Bg vIEGazVag+72TAwiCzTCn9VF2y12ottEw255B8yeGCuit6P36Q5F4aj3UaKh SEGA35CepwFyaELCnNlCnDsYz234BvadqSIkRPte+VsEQktxFQRDXQNeoBdu khnFPzYAI3QHnVc/h8DPwWUm4sBzSEHDFVkwjM7hvTYxiE4oeHZnC3ipyApf sjiF77bTJPIsKIrJut3UQHhay201Z58UVyuqyQJfjbgUTMuFozR4uxsykc4h 1vzzTDNtywZAM5oVXkrqCf+G3db+Z/RioV1Gy+7jTyjDn2W/VHJcw55cvmBY BQTpLk01uk8kxz0oFmdmQ/lMokOCo12fQdBEEOfVRccnD4xktw6TxwusQ0Hc 1CsTK9w3srdrenfxWrp2d1SL3/V7enbQGUMmBxdVI9gm5ufmVXTUQHb0t0D2 9NhoZ+qPOSz2wEWCK3YrFiue3UTpjaXnoybdl4xa850WVApBJKBc9bXpv2Zu OpZrQkTdCCleOlr6u9n4FO9D9szIdSjDGbyhX0EjtHUNSvx0u2kx0FKp2SBD FkZxEunwkXkxoyv1+FtwPPKaaI4uvEXYnrcz0oSYQp+a2l2DXbkth6MxH1Kf N/P7xaNrW05A2XxG/ej/hKiRcFTX27eJz530XFz03t0O64NY+hJAFs2ladQO e3rU8ZH4BLZePuW2O/GjE9ENXc5JK4qLDTlC27lPPOVrMYFCuQghdBDKxMy8 MeZVZWm1EkFCNJlViemfFZa7Dywc611IKG2Al5tiyXNe7H2MR3SrlCqBNyL4 9dhMRMZWvOxuTDe0oSYTElaVcP9InTh5mGbsFODd3yU3ktHw0vTZGdlgNN0R 3dzEQSZrHjmB6HGxy0WRpEmWH7PvKC/tMz8z2/vU/ilIjUQdJmQmWeJ34SuE l+ETZ6M13TBlgEka4ravQHkTftw92V0vJ7DFA3fYXl329rGXn5XztvMi3vWx Q1FbnN9YRVS5rFvLRcjTObTCgdaGyicmGzoj7eBKhtRwyxjMnRM8a9WS+SMg HCvtY1xA3s0sWi6xhHX3P2WCFhklQ0PCVPtz0l/ExER+49t+X8Vd6d8i+RPi GNRHZqZOI/6iDz1KipTpdkBB9CBD+Xs2+91Gwmp40FCj9t+CJmPdTwQzae4I BEguGeLIQ0XfqakQ7Tfox7/4+IHaGSm7hVXKBNWVM71CO6z/ThoO3ZjR8NLd DELPDw1SXt2w2r9QzHQ31z22aFtU0D0r26R65QTwSexphpzdWFnPK9wz8vRB Os6qlIQU8TT5xjU0a1z/2kPWSo+kYOtFS3krSxNrqz1k3LSqSydfdxa5xBdf 782cyZI2BFq2OBR8cPJNTfnRxsqTyGLqubJnzo+NQfIKcmhfjhTDdH2Pm0Z0 yL3V9vJhCpI37KwvGtPzyrVookCyTxh4N4VCYwpZDgD2xq9ojEdPCvD5JC/R Q/DlNANL7dqnNXSvwDZ5isVKGkciRtXQRul2SkE7iPO13XQNWnU0XLoplxfG yXbnyvS1vzR1jrY4EfnQskJcHshl+Cm2N0TzqV108nzVh1zPAWXT9inKe9Fn g9GSR90dcjhUTHjBCp8+S4JVMpsvFMCLXf8ukJWgNnF1VCY1Q3D6SZFMAtPu FZUEGNA9jV944OG/P2UUsmVlLC8MQoyK38hAyNLMZP6OSMN12MY0dDg2OEbI xRnUgQDiQy2S03WpHmXjKzlw2APfpn10OIr7GeSQ8zicXPlcH8q1kXa74Sum kto6hPft/3RDAI67S2j2J9X7StshECpO9cDZ2OGOrF6fF1rZgTOrckamn0B/ NaIvjP0mRQjNenpoMmY/699DpyBCZtVnQoDbnLjPoALhx+5eP+JeBeU5kub2 Et2xYcb7d1DhwDmk0BiV+0ZJXiLA5m65KLgd0Ax183Gt0Eg5+LvjV+FDRZDI RMJpQzE6lhkI97pGwdmX+lweAlatvmhlAqVK/vHtzTsANtfdCMcGeSNVzXSj zgk6nTbRVz279jPG8EhfXz/z5ii7LjZrKn9JC4R/bWSDfrE9EModaj8PLwaR bgPmApOyYQukpXV7MMLPzt5rsRpet/aRCHdQd5M8YXJIgYR6UI6hfQZ4Z4J9 mebV23Hu3eQV+PqNja7/QHmEfCmnlCgFT1bxQdxgPC9tNTAxOypyi0eEjIwJ /5rx1l6RCV8E2C5aWXADBx8JRW2FmD79MklfVi+Cq/TzAWXXwAT5JYZKwJ12 SMjmPEmXaHMMyJZDv4Y8oo83AZdp7GcH9/sROPiZ0cs72DRr15/3SFmCz+jp WGreAx5EMjKo2g5dl/banvmKj8P27bn9jNEaQV41q+8y5xnDhjYPD0HBdExB 2YuQkxzAGOvz0mee4TtgCcLuKLIFOC5U2Bru+b2q7C1EyrKq6Ddxk4dPgnQg +xh2RwpFbFqJqQRJ+GIjJiFRN8jbp7d5TAAysk5VGtzQX8QU4s+TpzPhUiIn 3kQsOhqOZ8pJ36P3yEy1S7f9St3EsR/mZG129Ivwdd2Ld7QK3cZF1OnfdbxE rfFDt0MqaIceuwgI5Kzgmp7gRFLHeN/2lMrEvR2i5tHeF2+SzCaHuQZXhRla aV8IxoaPXOQTjh/afTIYsAlXlEPOvBXdjEYICY/dXcMIvit2IMs8MiG9WLWe QQMg+Bq3XK2ReAwBMts4Z/j1rx1D/hp8t9xvXlH20mf00bZAZjdsRt1wXN/3 ickJ8Pdal0LqbybyAzh489tc+bODPUf5nQrKQLJAYJ3K2xXOfi2NJrN2agrA d1302TORBT2JidszMZ9AIyKHE4xsn/RcTkt2yGaF5qzzT0loanpGXy5E1Qld MiOyY/USkFzTQwtGw4VegmD/29ZLUHUF/5fiQ4YU5rhWAxjutgvBuQvoLMPE /ra4tcP0QQ0WmPwe81F1tEE3NnQIdjA/NyUDOhb2PoHz/ToW9l3hckm1Xi5A MGgpxW+VX7v4X8VCXkFq/kr0NWrQwnghXEiJaF5cANAgG4X4F41Q8Rgl8XqB R19dnFyDlVdbDbLukTyMFPB07FYKO7EUh9WKMQsRyUQ3jM1uyNYiRoxHHV0S C43TLc9F9zFDDXODxudLJ9t4ckEf3Ph+WsN1Ryw/x/nPPy/6NELcS/3ZbLLa 3q+Z7o1epMrDsw6BxzjJ53ZCyIhJrtONQYEBxUQTBnnp9sTwgQ0Yt+XB0Oje tjcCafHUQPkUyJJ05LGDkrgQz26MSoYvR899wrRH+wRHS3cjsnR8pNuad8xI cDtc1twdAFNjVw9jBrvAsHGCXM5808tdNwFyzY470Npd0t7I0eYVy1KmyQC/ dEb9vOv5k3STtkN5C9m9mDGMagWqINxiU9uqDk7vRy5TjkGHXMmwQ779Q1lg 0Y5Iu+1rBTjQYF1xoaMqn9vFwj4Z9rsNRXsbnr0BdETyXQRwIWpKoxgIAIpe 2vJLcSFrNNjCjxPght5EzG3/p0ullQ8lQN94XenCId2GSId8OG8agVmATUT1 RtGLUUOpQDlIKm+oSEXC/Tr+FkfLQgQNK5AH3w0Wz8QncyNcWj9DbOtD2LZ1 1mHK1G/rxOPYUdpIFkHiRPaf4lX28h8D7gIPe9sQDouNn266FVq1bQsmIHCs N2QZSUtCo12TOJRImfOdchS6S0uG6MNA0Fyx0kOi0UJA58zp2l07ZZHdtgrc RlO6bPPwReJRlQ8+2JdtGmv+uRrL9bjLwtbhFBQp8kzB+PTysrRPl8Nt6vcy 3iacpQpzqK7gS84Be4CR3tTVVT4eXbTaJqtibNqjSC+HEv7cXWZ6WefwPgXR n0BAd1+bt0fmLHLfx5c3o9ROgu70sqCK5gTcIpAoh4eBvEolSRb+bo+Ab/t/ T3e/3BhAEKwPsIF430CHWc37FMiqjQSxf4XnmPKLvbS69x/ANsNidzid5UPo RXj9eGrzSMD0PPoHEFxB+aPV7CW3dh0eDOirQENDorv6uz/R6wt4ae0U8I/l 3AZvuTO5Fycz5+xsrfkpyI+Ru7TXB921y2+c3XrP3n7UmxK0FM9AqoZmKLmW oECBHzUM2/iycy3Kp4ViUnnvDyePFTX/5bt+hoI9+bGX3Ipvn+98yblW7Wlo zgaAQmWTR/uOtHZeXtn2kgXw5ipFUitevAfD5fRAKJGU7XGX0nA02fmoiL+0 GkT74vNOQsrNSbHkDrAa9eEDOEn6sflk20jZ1BH8ziIg+I254sClKnw/XDL4 zsra/py5LtHcKfQqDuXjsI0KifnvuS8lXhGY4+ayxiviDdb01Cr1TshWJiFx +rs+jdQX3d0Bz5fZ81LXjxV1usSSD5dDUjfGlZrtwVIxtSIjQftg8cHWXkEA AsvXkzpbLCvd75e7fwI460VK1u8UnUW+Jnpy3USIXd7f9YjtA61yMceTwa8w ykvEXBjbhckIMd4zXEGRGIpnd8cQvQvHFy47Fch6spo40B/wF2lDzLehgPR4 r84eBUk6PeMKh29WnG3PjMipv0MjQrZhV9OE/qxRpsOBnoPfWZpEuc5BjpSj NPAqYyfCfdRtR9wUMP6659FmeCuGHZcaCyNByQV/CuOKkk8uIv7YcWQ0B/w7 aLX2wGp1HnYhcZz5DSEb7EsdZtnZACcqpHHxgG8BSGXd/PSvKpG9qD8CCyMg DtK4R0KcLMjfAZReQJVq0PlVF8GYq3RhrcQxu2zPD5SwWC6q2SMUQ8qa+dDz Ky/w4MJR7Cwl01F8vCWU4Y2V8l3tyYJp7ZyTCGtfSfdXlU4p/gEcpIBr2/e5 3OMsHrgPHYXbLvKJpdo4XvA/T8/stAdlhfHWbQeUSQ4RpSHybCiqeYbtnUrp uZiQt8qn/8DntdFBgut1jIgAxeCWhJJHQv8FICecC3SB3bjv6teRn25dfEu4 ZUoFVysHd8mQRP1AkwHTBAZMBas/BzU5v8JQQnsuP0zrXQIDBzZDWjTsMrXf 90FCMTIO/REb/k06PJvMu1PTxcCynbZtylzxXACBz4et7UBEusxWt8GPudHw +3/uSK1Zrkxq9hbZpOpH/A8EHV0J6dOUNbmgPt4tlMhu5BqoKETRrjvAzxQ6 9pZhWevhanFsa8+kCTsayUCKiBao3JZev8Mb0CdfD22hK5eAVfW0gyjX2Lnd IQ6sNLs0yFczk4YDA/ZKQ2SX2ZNvXKwRZLomjU9ayn9I95JdPUg91wLJZc0J LLVDQve90bXgH4ZNd4VeQ+4wvJVuxeJClQ4tYcUH/9Ni1tiyUFcBgkjbhCiN tgcVRMmr0TtKBa9puhVF7tR0cQLXwZI3ZPFriUUDSv8AEqSRwBcowHsro0z2 dDIEky4jH8dC6r9wKykVjQcAYwrjK1T9NVWMXIH2AqZe28NqdThL+29euO1B G7wkRT9s6jt9AJnOQV182mEbkb2QDIBCgT9Ze/yq5YpdFyt1LUDatVe0AkDX 1g/t171fvD3VcyTh7u66I988gU8qgkC8W++z0rLuSQ84BG3o+ARYuQoMkmog L8JCL7CSRKNLgBAgbiS5Z0EVfp0V0ih6CX/IwdvDseFJAmrcxDmWblyW48j1 sxcoiKSq5oFKEU3XBme5KnySbm35oGM5a2vyHokXXhS4aGF2915SwaGOYEBg RT9isgnV26c/IIgyn/JEKFPKU1gDRvJ16XVRXTFk8F7v3mEKv1W1nAEWPrQ4 AUfBvqmr9F0J08aXDucvjzefIoE8cqO8X4NtF3TGjOVKYu9xQwd9EsbuJCKv JXIze4nJAmYFk7FRNoNuymJfM3IA2znvf95yBPmfMDAuOSe8PMt2fEEk1dXE RvIG7O2AoaRVPubFplOtkz4vEYbUn9HKrX5SIBJC3A9II8oBNTchxwc9dsTX r/ORJv/JDHS+akeqSe4HkKtRhBXHL7ukrlCQA9tTW3HFIXPD38OtHTN0n9e5 DwQkeLOykZx6PJWFHxJkRUeQ6Fq1BZQ8uEAd11xGmpbTtllZXSwPdHdOd3WM NQlkGqnHQGOxVOvjXww1kDi3JkQq5TEqS9clH7az+kFFLN6krWcnJDV9yLFb KcVSPrKT/eMSvGRHaLIPkb621NEwCprvSxAFHxdyf8/Fk1U1QUhjVPchVUGB 2QNZRmrPxrXZf2uIRnz7wDK0qw3ULS4jkPIfeCkcMV3XXDUQJ9Gxd62m3mrA DLD90rCwwv1HxukmBUUeMgNWoD3cBIRd7US0kdNXJEUFZ0agLJvviDLXUy2Y L9DRzVl30pBDJJPGAyPVBz9q7aJdFB2CRYGDdaai9UHRMJCMt3Wb0ZlcRrXH bF60I0hyRH1SHiJHk3Co0UexkkDoOzM0M8G5mjpKP9OXKeyXINLD4HSenPRI OANQmsbG89HlHQe3G8t14lAd2sq9k1+L91DRnJVyyZ5fRUBYVnNBjfqEgtU6 XkJAX5qDjCuVCR7BBmRA510TRFVLf0QV6+pDgH3K2OqX2f41GwdDAPMSC5WM o+9jXUAvpN9HNnwHLbG/mF9HbpVfYnbh/pR17A8LBeqV9INMBQYqk+lA1eMn xJEZGCtJ43sPWeFIduXojzkdQ8wpkCb1C0LCf+DOZbu4wSH6CO7MaidcAWrx tNA7+0XGaNg4VUQ9S4FMKN4gJUsj5wWYdYHsJhNznOBVXXJbBDfcIUQxQlWk Ax8roTkA/t4snPjXjXmW6BS36WbbtPQqf9ooH/MqdV4SFLR4I9FrIgMPRl8H aNuz3+RsQLgDcEheGbBeoVhYXwca+ympPYiWz19RI/NNp137GAtJOpvgTkTx A4PLLzTBQ2aX9Q2wzKHXDtS7vrcbydbMC27VrPKvLYwvSDd/l7rV0q3ycrU/ RzffQADrCMGd/yfV0TaTydkolsdLwsvkieKg35Mr4CzArDA75y/rmH6Hla4A IJnvXt4KLRIjQ+fcUYEZWsNgamgFqtZF09ivdxawyasAjEBkA0jl/074yWNl bYGYWhjQ41yD/w9vEDcgudb+wcQkKCkr69lBCoPcqwMTcUXx2YDHQlU3etdC BN6XLo8YZz+ammdBASM/jweTApNfn51T0DUnLUvIZiAGr2gwajo+IG1ilBiS ES/Z0YFJBxlaooLZNHt3BYxOy0VT5SWHnU3FVdWaPnseHyR90OWXmd6ujUVk zQGSq62hfDk8ZEJA09s+sA3rqPq7n4b7LijWFek/98NCm23/bjS09EDwYChX JkSUjac5LTqb8Ilx2o1HjDvojCIuRt2yHtOVixDeVRn0Athg0N0lSvxT6cs3 mUdujghDA5FmiiQyA9Qo0bm/0tvbNveWAcGMgHpDgTQbr0BdrLt0xACdkbLh Ah5gdLkaQgcFJSDId9xGuXXvyS8tBZTC+e+3BLdRv8f5a+NN0wG9118uNLxD 0R9P77+lQc9aLE3aOSofNy8FvUEsk0UtkUkqX0BLLrLP1gJ+I0Lmy/VbyYvo KSgeFbzNbp13P4+eNfdRq+N0/Y8uHHWjQ6TW0rDjNxKgCibnSW/fBUbPdJLF dZ/ym2Ipx58pI1X12zpTylAk4IT15jbYZsNSHdUc5vAvBwleAAeklDtJX08H hQfHJ9ne9At0BBye+kutIihIP6Uk1ErmPQGB5qegJ9Qku9QqhSYt1MsmF8sd NfNVQrwPN7lB3SBAyOZrZdQYphqedy1RAtwFwP1vm6txYf36XK1QV7fkddKM tNcnU4G7QcJc2qEjpJxEgS/VRzwx1F4sw0XZQNurSGvyBJptJ+U41ppDyW6N W0JunYX8dMMcyQW7RxHQpdf+ZCQUEDqyqkLIXnaaXwoqSYcfwav1CWo0e/Mu SpN7Q1yrAV+SnNLHasnbB5Xju0TU9QrVKnJcoxIe/gWGa+7Q91UIeWYQO0Ps gcMzxXVkwahdW3FxwBkzc3qrtvlzF5LuTdUeBTN3kb1BSXLZUXUFI5honO41 xSUC+zdcTV8EXur18jW0X/aDfVFZTCB9g+oHTz9JdC3b7at63zoj2yrwxyBt nGTPHttF2XQt8AA7AHXLgMeXnTFPAmDVRVBVXhP3wqsg2mPLjUaX0QWmgEko hEGXn9meePS5yF8ilnd1A2XZxvgb663WiT3X1PmFb5TNXtlcNc/lBYgUh/F9 18I5ZVD6ZcXukXSIPE8ir2hEohzgTL2HBb5FITtW2tfYRvdykkQJAsjdZkZE +9QNPQU3mNjVRLMLHpAs+b85j9q+QQlGgWxiiQ1yfMtzI5uCLlocFRF/R0Ky gsN0WcccBx9c8lGcRMh6KcyB0u4rbRv31hXp/ti1TqmClyOENKZEb+oCxatL 0dQfP2shIrwuX2t/wug1TPvv7wUABexEXvvwujWKEvU9DzkLTTxf7EUtF1ix A3Aq/yhD3WbE2E+VAf8Gr7i+ouJJ+pLd5gSqFR/9Z5HiTteyCEz6OpG2Xssv eJfuizQ63DJJR9/dAbluhwgeahbI0xll10X1S5uA7x5l1DYVUHTQgO9ZWNvF xV/LqVgepejXixm8YJxQLBYlQiRCx1nCIodBgkBnXu4z8x1kXlVSyFulPEVe 9ERBFZlsnFASpTOk6G2uWQf+BNNGHclr49FQtEC1Xoapa+N1dR+Ul5WpYGmd zdII1+LMmVqELOReHUB1J5wctCryQ2/1YlH5Byh1KXSG2LikhANNEEhdCWza JHNbXQJdkJ0fa9r7jf7Q7F0nmplaHmHftD3TWpPVSbuHRzKc+TsiVjPiVB9f Wj43PQLr32/g6zUx/VzPQgH0rvpAvYWKvpThNJULR+xGDu8PsyylwRM0hl8A 1Lvu2m37GU9thgEgDFL6kJ3sZ9fDUt4esV53+Fcy6GQ7lb350chArDSIsQDb 0eXFmPg3XLVfQZAx9A8/B19RNS/2Ermhp0xLCdYmB63OV7j8SfzjvJ9lQRfD yJqrJmx08vgAAPQrojWvSwwH5yyylfF4n11p7cU8nQ9DMJUrUUHV1wCSLlWZ 2ExXmpFF6Z3hxQ+WQkdWYVqFfGt3I8Bo851LRQQ40h4hYY08NR4gQLJsRneY W+geCyA4a/uR693jEKjRvqlGE0BC4DdsCyhOFyxLFeAIKm33b2VZBz9NBe+S NPEpDqs1nzSJvdKHlHrvcluOnAHrAuGSleB8OxhJr/aRJaLBLuZpW7oFp2kn 0RUl2jD9XQWUFAHXLJTPPRtp5H0E4rZNdpLDH1U+Z08/ow3Eyyhzdl+yiiAN NhCPOPCvyJ13/imkrADL1KUnQ5ke1Y9FbdZAWMNJatNdzzw6X4FHJM6pFdc0 ifMUzh5mYKOqBaonb9bL0dHYvFh0laFPe0sBd5D/ngfnAejD7Q0OgjtyY5Qk zRGBDnICAo2ADO9TZzDLym2cxFECAsPqQwUfDoog7hV1VA/VrAjlOy1A0uVB 8zNDbTnHSsVBQHNcY/RJ8kGjXNU/419cLUHVytcuXWFC14GjmClaxhECWip1 zLFfXdmdXp/vXEiDQHO1wTdJUkNfxdIlQUb/QXUKxUpJIUWfQwpG814nNwmf RQ1DRC0GZTTBQ1uoQTjN95A11fGGQEj/Qn1dkDBq69CiRwgUot8JOhUFt7hP 0Gt8h8bDAwU52gbWTERFGXdwmz4rbOPE1+sMAFoAwfe8jL+SJHcEP/YUVl03 lwWhZ3dyQGRjd4DLN8JIJ5dH2kdL6nz4M+9Hb+jUBYeb6Sq5pdFYrufa8Czw 9NwJb54xMP+2wnpRft1Br7y0XAc61JvK1UBVT3cmPH73YtFRzg1rw2vZbwsv s4kJn4yrqSbJAScFJsMC/SwqTt7V20bVWn/rakZzrjDYBwcvYemTQENrjNWS 0HuSc3UUK4F6uzwVjL2SPFg+pQrw0kAOPgR1ecwvAdnu2xt1I8WbJ00PQ3WE laGidgv1A9Pm0NWQ7vhckNyk2qWiZzyL0J4tsOnbnUWAbNQ5Om82FVZm+/IX Sr5BB+YWafGif0iH1eF3HZfK7WExBOnqkVLb0Bk0SQeRNDwCn8GT+2jLwwXF XErS/i+loTR8QmQCwUCUasOi0T+iJ1hHrj2jRD3D0OEfAQd78QFAUWNbAwVd NDjqzMBTTn0jNUkvQUJicsxd1BlMB9fRDtIbSTT9wsFVNkVExF1b9HHYzFcq 9VxKYoyk3+06QU40b9nDw6umlvNaMME+dX+5C4DnQy3DgnR390PTC3vLpV2T /QRRIMw5+PHY87iJGePA+0c1yLDT2UeJckfQZEgdoZ2kdUTz9UNmJ2FFvzce 15qA5EK2KzO1fZwwZkMp+0O/hEk/2ZIoMoU6FXYAjvEv9znbKfByHnQ3acmi NS4k18K5wH/KeEVG9BXy06oGd26CckdkX2l7QzYzVS+lMC29BNBdpwcGmtQ6 Q4mQBJHVdMvLWUpF/K6vMqNZP0LC1VcgBi6xAMkelwEpdSu6ddkbx2kFBikG 8QWPgNHrMk/LkthyAtyzeiDfTkF389k8cQi0JPNDQjM5j116Pbld59JKvvMF 83TD0B6IWvGWcGb40CZFy286d/EHV6gnAW4MJUD09U96m+/I2ENfjivKrvYA V+z71anpP0kou0O3KWE5ZS8sKE7wEWgG7JJBv+ovSjiMxNqryi2RF/dPaDgL JEwnQGKQXMQjAt8YkDbTDi0ptQuFLgFxvjLNJnng0bSyLzsrbaNRxOFNxjA1 psu2+d0s4yklHo30RjV1kSpLrSY+N4guVi501TWsR1XVN6ze5oqjAkSjCvTR ACfyy5PRym8rsQIhk8u0Ct93Q5G9nGppQowdfiAFnRo97ylFQgG1w5XKgc14 1y2/akDoiLdH+Rtd+yxsijXTAtYIK3BHpYsdtgs8IQ18KJF6v+1DHV+w1UvK 2T7W9+oe+y+pM1rBo5l1LhABmKevbEMokSrsP78tW6vdUAe7UHKvoj0cJJcB 74DrI8YxHZoDjQAxnCjNMmHVA05Gy5PkWulgRpo80+NC5sAv3EiTa3Uv0Dse 8eaHkFIiLdpfwJH7INOL0TG4LjdjTkfO5QhF4ZOWyAHzb9UEmwcJDZOfI9wJ DAs/0t4I8wPSOfJiAn7xRgTzWeZlMg99haYtMXkAVtAv+wkx0MSUxgNDK3Qf xOMDX7DUnT6QJBN8Hse9xZW1R2d319s16J8BPpkHS5OU0S6VxGHhD1Gnk3KB mjJEauB8z7InDcVhzI8WOfMdOd9u3QpRfDn3bjs2ckAips5HAuyQZEAykC1q sscxz8CIXj1GwNdmAN8VCwVoEwEvJ1m3ktNIRspL/3GFwfIfBNYnckt1AXc3 MNdHsesG9/TCmIRPXQ5CJhmCQrKHWvZJpnJI9LR0T6QEKaPaBPaA85JzBJzg 8VwG/7NXO9Z3gwOruisdS2231afhHAdBMO69gFqLCfAL3nUj0/S5RFG3gwRQ QxLkI6TkQapQRnvxRj2QQCUQDO9XhNQ8QWWDGvBc85SOA2PbCt0++BxaQENZ xf4JdAXamU/m1TqQtkEfXe02MA0dEQAnm9v5dT97xiBomC5Cbg4JE62UX+CY +tSK1ABkxemgruZSZy3S7VFf0YPVBv672Nh+NLdnAKX0JfYzpSkjmKSdRUAl tZ9abDzAtDe4E8NCK0nD617uBBN0LwKREMO8wwdHSiB9BJOyjwdVfpEjlJO+ H5QY4Y07PDRyRntdo+xFIj+XN8bxQizY2/eEE5/ym+xsAq9JwFj3d/W1UYZ3 EOLoKUzvb+PodCMtEsCzxOhDSjRYvQXw0zpCB0G+oARLXmrlhW4JIMndzF3v e1Ktk/4VagzN1UkLBWVB1OpaKUvHVXWyzsgfQS791/07lz/RLuD7AkbsDifK NFFCS0fOWn2eElHyYT73zF472T1NCcKHeQFfwRsUJfXnEDbwCXdf2hVY095C U+wL2eqm6HcTOoFG0l7TPODyzcQvS1Zj8JRD5snghjnV10PRCz2/Lo4CgPvW ikrh8IUmZ98Fo5hrQae7SVz+2mZCbkJ36d2d3ug++HLDCyOtdUJRLxgPlCKs wgXTRBfBmAgt0aFLqo0+9XVa9vlOTfzdM+O3vUjYMPgMXQdkBaamFEVdzHJy QqTFpL5IB3Yh5lBeFMTEwsQYbROEwsTExIudgbTExMLEuI2z98LCxMWrv6FV IiJUxFitB1cJHQEeATkCMSc/KbfG+QGXk11LiHcURtz9BN2JXPPT9CZIO066 P0cmR8ByLvNpKqGBTyA66UvIErY3QQeDnkN2NeJH0XQss08DNyJFEMBezOpf gKxU2x7S217T5XVHBU8UKhkZkLx1pVrc/n/jsemQ2ZZ74WZ/ju2UFOrCSZCu 1F79IONmydPdy0tSZ91dSWNoTWsWKVTsHct3oz+E3W0M2cxBtloaT85I6xtC A+ov+Uz3FoBH59DlXEm3GH/aAI7nUrCrdRYOSWNcWQdzNoLrQMW1AjslQXSw v513BecPyiXa8LZoZnfJ9znV8DofXd1BO4LwQDtGc0VD0Oj7NdTxchGEBi/N Ejyf13EAhCNCRo4gakawhzTkKtfxb2pO/V3vVZJOqj/RqwfQq64DytUVrwXG hOQQ1IeXWtxZsS2N7ZUL01opJijcVQ4lotgXQCgzNKa2QsCqNGgnFdiiAODe WQX0zruUN8UEwLHx0AMt7kIf8SkbRENIX1UtjvZcm0Gg51om8UL1PqWJipZ/ PT52KD3ZHI4SARHbC+ZI3aY2qGnUB+0O7ZyezjT+SwYrnl9AVSn8vdk8J/5M Lo7X7UZHjgdCQjRAiH/CsU9fS4tA2f6rDW9O3vSEEd9E3yCARakZ3ZQDai3S XvKzNY40X0RcIqBUAUVDjAJktNZbcPx3laXYBm80kB6y0ETbh59x8jM+EY7b X+Q/bE9SosPka5C9F5m6l5wF+RtCdC3MCVxOjGjUfcnTXzCRe6RfNFwqX+rL TGdon6v9erFDykhxte56vGb1GLZP80g6YkbDGUt9ydslVaYburvDhiTBppAR PpWZQ4wObubmZgBw3R1A3AjTkrUHXb7g+uMU1KL37NI7+XkArH2h+/eYHx8C a+2A2YrwHzg8gVH6zvD0yPrjrO3ViwE0jQxBsCPWHnncQS+sLyWOGkXqD8u1 Xy/TaRpWaaoAR/VqXTjxAAzLAdPbOgCm8D13g7Iya6wolVtTyH4u23+Oz4xq zl/yX25e4i65DDyw3S/cMB18SnXH3iA7XzATnL3Jh/c1nwMCArULaKG+Bi3C HIvgeXQJhUsoPFZyYrDpaagILUTCj35nS6fSCBAM8dbIHnTUxq1+GPZPE4y0 XyOE8B07gt7JPR5P7mamwAz4T3Q0DCiGNKCPD7YODkdgNrRjNW1AmNCCS+mP biGC4yrymfobdI55FGZyKwhfCgZ7+AlqJRQydDgG0PMCyDlAE1HmzszwOsos 3dYekiyBDtuW6jpJENVEXGxl7rW8dJsvN3w33hu9kI4i8EEZKLlBtagAai5B TSImyeHFxzvHtf++LOk+PcuIYuKepMXUdavbfIEhSTjjwcDhQeC9/TJDxduw jP1BF+5Et7MBXdkC3X2kDck1MKdhthir9XVeR6SG1p4rng8AZ+rvmz2zX04r gOq3AjhlmrdfwEcH10IWRnqQMiHj2wIgmkLk4x2MQGwNTmdStLLGvsTh87zX gvVVPMA7M6HHeemAeBnWHrqEwf9ia+/CepvwS+sGlN9VQWNHwNGUb/yF/Cuy HL+aomKpJ9C68JjfdfZ08UcY5xyVzHHTHwJrjEZdz2ZL9u/wOPTwHit79Qg1 9ibrqcjYc3XsazXU2ysClduclSlJ9o8t3EVIQvQ9HNmgIEx1sVx2PAx0eTNP Q547ESJVvPfedTk/j0h15eTheNw+8dtVsUOADTJ+MuILIU4gRQok8EpIbhJ9 /5QbK3vxb1m9n9TnfdSGDsiYQHW5hxCanp6Bz3Kc0igTbo3SGsvWX9e4AuuC lvr9PfM2duqtAKXYVJSp1xeF+O8HLa3qaG9c1fx5DOB8TcMqB9zVX3DP+7TO pw/1+cDXd3GA6TpUw1rqa4zA8pKMcf0kW4kYEnP/uXwWccjz1/o8fWjeyAYu T/IoyIdKClR1LrR7nZ0ALHOOdZg3ebLjSzffQmoo9WjduClN8SKtBnPiCN8f FkBeU0tBN7OU7jWcXjpl8iG2AefKiBJHN9UuymUiYuh6MNtcii3zfTM6Rm81 XxReN0vPo25eeLXi5783wn8j8R8f8S5fz8rM+l3xRUNI8UhA813b80K0DvAP ZtOCQEHX+Upf9vhYMre4Q0IvbghlsJTlXmm+ruskwgWWORjwcTkBNN+ogcbO ho3Ni/PROouvlhdcrmBJwH5+TEBIam4wu+n21zpM8DYr8Soj80Gxoqf6QQUB sNRUA5IvTV0HbTIiktY4tBt6BgAYWATwECTOrQ9J8dheqR/0qsX7IJgxLdlv 12lyal2XNWpK15oRw0SRek8y+z/vSBZ/T5v2QmrV/4cWgVwGhOz34UJlcUBq RRNvSn10qvn6B/NoG67i1fj/eyMbyBxyUQeSd9JUNlqtktUPmyM6evQj5hGk 8Xg91cpqD1UO+8zPSiQHIClTR/he/00FQn8WaG9OAUJGztAWyd7XAEtf4VLN 9HHGQ0NqDspe0k0XRCqGEdvRS9imQnUzeNLrbP4U/UxBSwNB/Hnmf6Xv3yS8 o6GLj+nJ6vnYdU9nbD9buBwh7gg5kicybpFRsl312rvzHkry0yPNjHlxdOhT g0JlNWhrO5wDcM9I9812zVyeexC0XfzdOnPOIC0+MDqA7Ita8u/Vx9Sl06g6 e/2ZMazzwC0+Gx/RZpjTbRwrK7WmkEUdRgIh4Aj+rpdJFklyUF33GHQTavxk bPBHEOGqdjn3ztgF0wrD26+keo/i0Xp1s8hJDK+RrHlxMNK3XvNn+NN1zvDq dFxCrcUPVUId8mzcQ5wPCBo2+JuSEoIo1vEh+lrDbo28mD5NMEA+3DhBQ+vC wCZwdotf03LAEQCIr9BC02438zrBKBre+2csf/Qr2WcbggRCXgNqLdgHF4EQ EntKKdMfdDoUFBtv39NFwWosGjwS4Req8EgbQAdq/c1IKIEzKzmJjjww6xz2 TurydnQP9hwJzSP0O6PZkTjMbEB/7s4Q96MORClh5473CdrIahysO47mAdPq NlpFdOw2aeos9B7s+0R8lSU+Ci9g/wcxv00xy3Sg29F7LoXROeGnhEN6R5GG zNyyLfIqAat5MeXRddvidNoHE9vplQlx6iMte5UDHrqQTATv9eB6mxOM0asF GXv7F9Yw0TX6UAf1uC3yRbtIBI5B1NIO/dL2CcIPdPdLj/1dVunykevNaj7R O0RYV2SRMt1DNKK0QAF/tThkDUHwh+AkYRHhYYEV6eLHPCYUze7rdQFcyJEs pIVE1/nqlnyagJkhGrIhgM1HAXQB+fC6p1BFAfgT+/OMwmnoDnLdXsOLJtWx CmR0rFO3t0IcaorYSeYzi/WNXlFxH9mgJFwO21NzkXrG1eLalvBfxUkMyJGR I+vBmGj9LM1J5bFc51TknwcbaMej4ZchTZ5yWIznw85IcXhEcXj1lLQHJw+n ZHYOS1AnFulN1z93B5RB+uY431teRtDP3BeZgSlQcplqRDarEbGU0RIM+8fu nb1AJLwl7H7lhq1f65d4FvNJkbAoGl+hYvhGzrs95QzZ/RcfXl5AQdNj+CRE YGf1SZrEmdM1PVfhtvT0diGtB/FISFj/okvv/TDaOHP+KuHQ4D5nzPR5TZby ergjr3PvwxJkiSFKn61kynZEa93WDq3lFCeg9iwMvOfx9O5ot+kXrFAydA/x 5WHcDomNANq6Z0Hv8w/ye17r8CZFfXMRkyk9QdfzKlzzYd6PbTh61tqVM3ae jHQxAT5A3d0vljcNLPGaKZY7LU9WforxLkdKNkEXk4bpSBt+I9wt6M4zz99C JGH/TGa2XTKTstTR5VGFOQT0aF01qFG4GlqOdaMavsI5ZhI0Lye38SRoeT+f 1HD47ZzX7gXRPbLs0EsjXEa0SSzqKS/YSHn0blZE5zzy6hldSUiCWKtOATej dRDITW31Vx4m3V851zRc0EO3FnAfanPrQTs1rsfUFz7eKcgBX9MFPLuQe+r2 06syNI/Qum1GJUucwlxEaj39QLOw3vs5D/AtRycG8Qhpzl71yXzX88VL8V4k 35aw82dQwPK+u+TGgoJUXFLmX5H24qJLlb2a3If8OEvvZE0o39MM28tH7ooL yrVv6dUKXYwqmINwu4QWvXL/lPAM2P+0Fd/KOS+D3FQJSPCbuT6I9xUvFN3y d5ISGBV0QEYhanSQSc/bmAa9PBRffgIeO5ZDUTDzpA0Em0NPvArXDbXo2z5h kqHyt1+shd0vkgXSSePooNRA626C2QQENNqeztWNjUCp9Hgn1EsXreq65yt2 CwcL0s/xRxgfjIRDtFrbX1lEX0fooiQy1fXyDujvcEUXnXHnXObvSNE5Fv8D AbH85zoI84dbeKa2UYd3ajW5msK5ch3w5TTqrlk4f0uoA0YgnVGr+i4BNhrr Q7OFT0J1Tm3Yt17VJDSCRj2QuNKeXflDGGCUSGT7Byg5996wkBSyPjNnDSVH nY4aViCwPkZDENp1EY8HESc9PRjHMFmcwJQPIVUFX+dVqzWtzNXJCWMrX/RK RZ9yNUrky76j/kYN11Mf9L2x+Cu+oMyQI2BRlarkMvEAf15payHbdDGK7ZI0 R3Ivd9Y227EiLFqreMJLX+d4IaouUtper2yYrO0eB9UdyaiJTy6GoaDLLu1c 48Ncu5HJ9iSNdYrAFnX/4TvOVNBdd2vt0f1iPy+RR10giXfocOofwrRFOk35 amtCcQADyT+QSLsXFR34A0HJ8ktDRo67nRzAnNgLlQK1+fwaz0B1E1JC0Rwc SgqgB/uSpIZAOgAtzhxehI52wNuSAR/vOExd7AEP7SKOVOwIPdTRL0fu00c0 qtG3X7G4kncICvSuaJ1P0cVCeHlkVV0TzzgsakvsZ95SlsYcS9cc6EBFR8Bq /7rW/hWeO03w/QoGxdIbBwic+eCIS1BTXgwLS8wD7OufDg8BCTkeB+wHBhPn LSkrRPEPhGyxhINmWWhfu0CoDRLBKevD0pNIJPsmuAGdrI/URzOROmOFsQxa LNNLWAPwj2D60agMciZDtcd2OdfwXEaq5UfzPI7PkGOBCT83HhdER1kwTqUm OjoTyzZfa6nlsS713Sceb/mQChzoPW1yVK5hjvlaF5qL02kIPtnrEUbJ9184 lo+02WlHGAtBBRkilDvvQsiyzf0QL/wIGv5l1hcqwCz6RO/NpaiIdwzk1zQy bZmzVPVCS+IGjW/wXF1AF6fWzSgXneionL8cZWxeX8C1XrF405CYK0TJM/pq gE2VQBZJ8SmYF3TlQKIRF1ptShsjF2JivQk92+tuVLGEWxpB2wz2bZFVUgqK 9fWXPv1f57GI7005wut0Huqo6ZhSN5w4+nelUXtPnbvEvfEBCu7MAaO/H/ep Hyfvqv075Vhm6MQwLAbDy1yAfIBUuPkf1jXu3+BR1aHb98BHqNO0MASXv+/a CKeJWgmO68CpWkkHsx4N2nVoSWEvF7R1OLJWf21RC8loRzHt8vrT0PDprnsF qygpMG7VIz4NXlZ8pA7tj+jOOiO4/rXh9X9tzkmZM8PGnEnDbOqp1QvBnIzS BuDLxXZx9iJaycgD/EWTWn8tSdNcl5ac+e2apW2g6MP5ruHzJFUKoetZ0PH0 umsg+DzK40d29Q7oo5qz9x91Qz3T4Ym0c4gpHvMB4TjPr70Qi4y1MoaEvwP/ QDVxim+seH8H66dfLbtdI7wIfxtyD41odVVqs0GcocrHQf5HYZizvCKt4n/w SOMnj1MB19Ctek71jzLpyJPJ7PdCLfkD31ngstf5HGe81ZJVJ53QcifLb2le ywgkiKemIw8rHfNoOCgV9x6a93JuiBs5MRNaaBqIPh8xzlQ4gjn5M8KGwIfz BT0ENYsHjDQWlzhijNo6nt2BnMOnIhrsNU9eOPPoPufwXtF2I1ZBWZ1YQx0p LWiEXac5KW6CQDE/dLXXWRivRep5Ponnsv42ce1R8rEPeMpYdND8PkI+ILQf 2DCRzWTAmqd1HggTExU2dC6iLuJKrEzBShKM1gCs+Lfx4IA6BOzNgDsUtwTd ak5FMxEDe1BeNe8Pnk4ZwUs6mNEK+NMoi18c5jnTkCDnWBfQ6GjmGnVYJjHe qya4grmxRbMl/dVmqEXeDrkKRAZx32IjRvDyGk9JPYRfBMsfDCdF+1kGdfA3 QkNowhgroR07K26lPC4L9KW37+HPSA0CuH6Rs7hWX0KdjGgmhq/F7IHxH/Jd dBHLAzCe5J7pjuYbiw9Aq+Qyq/7uPOqHwnO5QZTecXBA815e8BqAKOwij29C 12fPTP2R+a7XCqzkkVUfv6izUiig4F1xNVezLCGljZFLvyMKDuGSKwMsJPOY STFCQnSOcjsJWqiRkzO2RRFHSsspEWBkRMZTue5oOBrsar+RQd2UehrNw+iK 1Vy65a9r/FFpCA5X9MYmQQKikJaF++2tGPJ7vncmOwszCsP+LHTY3eZJ+yJH Q1oB1cc//ePe01YlgLcJ0OsMCuiOskeI93GBuS5J4PWkQHT8HVrBkG408zCN ZSkbC6BTDPBtjdBKZLEvX0gZBYt18Jfl0IbwDDC2QfMPPtdDQA5Ou//0BqxD dC4fNdq4aAezHy2K+PhqiF3NwGrxouKTX7bsKmoFQctA25QgzDFRzJi/gJrZ 0ECHdbfpJ3+n0vByCZRLyz5L5aJrWl+U5vTXydJaKUfzPdM43PXzkPHtxUX8 sl+XgvZGgIW09EGZOc0nUP1k3/5BZ8O8QkBUBbX4QaUV1R5qSQXVtjGwJAYh 82SMP0j5av0y56vR6c4xarfOSEvKs/9UQAXWLFfiMEe6fn0i9JVsaIrA5iVK nxzIh2Br9qqm3PUVvP6wd7Rj0EqdxvkaHRaj3EdMfNE31Hdng9PaGS1LSoTI 2i69p08DxjT/H4B9QPPPJ3YLaZkP+THbyAJKCh48zpZ0K0jWkBrsha9PbcXk H11EoV1TQ90ZVe7uk9JqZvxU6i+aR00v7/wpSe6SQ3jQsQYiXJiMQ6WLx4+N mHNItNwfXArugizfYqdi9ckcHvmnAD38AwgpVklEFcIjMouOpRaE1ENNyM1F /RQDteEqMhosCthOzxp12knz8F4v8embyKGavI8aKwUAB+Avd/ilODiAlOb9 XWia4ULokmtqXxOAH9hcRYEE9EvWxdX3KgXrqjr7z1TWc9wzBkz9nJA09e+g 3FyGgcX9yNk8lbvTuOKNvlxh7nfmJ6BFQYw32rxHYPf8Shh5GF9tXWbLQdyQ c8aQYC9nBbkS77teTAW2XGv2D2RQOtxJk0lBYfr+vqjao7UQ8Hal1aM3ddgE GdYGB1XErCxAmE8oKF0hdbd3+ftayIOW7jLSdXOC3at1pkIr6a+VUnou8MmX S7br3VNVtpjAnvBBJXixlT6IRJoVP6Gx6jAAD9W2Lv04LNH/liX8QG3S2BQY XXw4RSNK8UY5WnUrhT8u4gGLqzFA20+AEqzo25QW6L8LBsCreFoviT8jSFRC hzpsRt4hcv43osnTKK5LdLURYT8c15/DkQ5ByOBGAkVAb2qU8WvNibWRklY5 0TKpyAN1iw76n7kFo+yJUHUAAi50itu06kJrY7+dPAPIYXSe8UGaOEL3Om9i kcfLtHIWsIer/xCuOOVCXQh0SKPlOAR+jRAOB8/ZK87spyDS/3/Iqf06ID1e AiQ+MiHA2KNHwcg8N5TUsS4eNBk8v5e36m3IR8NYqyL4L91DrPiHEfdwXBPS uEnn/ZyxPtcB29oKzAl1+Dor4z4h8CLIwZXt9308+Sj1X84pkCPpzuJGQ2pE ++VrAakuNtnSZxYEvEVR6+D0IwvMpSUZ8pfy2tEkJbklRWRrXgp1n+fEK3+D lnyFZSBUXURfT53uBAcTOMjX9PhBNzxskY/qVHEhKZvddqUXaEi1BUPsxkM5 7Sxj0QsL6KOtFL4fI/eB7u7HPR94W+xtG/gtXQz1GnYDXvX5D3Ynt8kcjC/5 Qzg39uTTQJ6ABYRDu6fomTC2kY9xxRU02mI3zbu1tQdJ86WjQfqTEBjqo4y4 2UZw4cVJSZCfLkrhXU00ngLENv5BUWtesSEX2V/m8Mj1MUDbs2/ZL2uM7ufn Os4Qwbcl1AJufKDbiqckRyuSoJMQweFLdtZ12RQwFh8f/9ejItuX00PtV+xi yHFFIG79k0O30hfrsG4fT+FExiWKtQBcUFSYnqO7s0YjkbN1aXIA2qo+jeAg 2SFcfFZLXaLsOKSoYY81HCX5Q5Bb+qB7D101bkdeRDXG3462lT/d2F6lz23V cRUh/FwO8bKpZyOYTKoLFahDOUX7Eu4gLlfMRGY4RC35Djgg8iTJFTJ06CEb GS+Z+rpcAZt2bm7aOR+z+I4WWnYLeOr423Xq9pzYI76CGLs629Tw1AIU5ZOz bQbu6vyMQsei2DUa9ySUPNd/GYXqCD2I6tBqI0b2UcLtyN1JEGhjOUXBiBrV 7HrWN2+iTEkEw9bQLW8HLq0XWXxvS0PbY+nDhpeZmkBwXV4J6HII/0scxQRd bAgP+ksvAtxFGl0S6OTA0vPnLOVHBMcqXtANdbQoBkRcLAiW646VGvCKkjQy dP8vtXJ1ruzsapcbIdK16w4YMOD3Il/ulSDOKpaEEkJgsNjaI9VqoXwxgNvm REK524AqdEaZ8hv1ZB0Ex0Xp2YHyudn1Zevvp1zuAaaxiTAX5Qd0QUMLXsUW Fep8QHQ+aO8k90kDp17+YbyX8mQvaDN3RG3tlGbXWNgBA9p+vf7rEAFpQAS1 CB3nJUTnylo1U7l1tePtHifpG8LXde1Dshv/IfCwejmM7LgPAU9D9E6Xyya1 HxxFcBEn2ERe60he7O7diumtW9UeaOz4r3WuWEJwmNGEL/GAFtR1QFzwj+Uj 5brVkLKfgDobMXlC1fbvYgH9WS2X2ECMhzMfT0LAvQEExD0JB1UEVdxdi8e8 7TROQQXV0TPDMSUPyD1JKXO1LLrVaW37YyCZANOZZCce7U/R3QUtAR4sg2+T FodvQlxM6pE6myGjgo5SQuhjSwTrAXWVxn5hcdjWMSqfQAnGBAdl6lTAoxor 123dMSWU4tsCOBeLX1yQGDAGk+wQ1cd1M0toMV+wu5HtjRA6ykULT+Ch2s+K Q6DhAP/3X2aHKdtLi8pd1DUId0JkDPJaPfl3OUBINO9cW/62/kAuAllIN8Pq WLiraCCDLu1INHHYLJluNtieMgHFQg7QGEbzwLm3QgAmSnpY63WvdfHYHqzo 0bTQMXlf/pGPOzt1LxKNP2NVREWqot8/7D29AEEXWgXnqpskJKIDNOTyTdoU cfU2PfBebnUdrfSj7DlmSoW6DlXBl7BLNHS3+8WIdcgdjsmRyd+nKoGQlNrL ln+R3YEmG6NiNh7LGt+WS91sN3h0joJ1XHn0FELdG/UVRrcSQUTKhfS4XYrd 290IeMuKt2N1SRYYLtr0hKQ19WI2D4yWdvKVXHi/mHN28JINhPLgO2zy/jj4 tSZyjGh3j+rWz93ciO6X30ktN0d2HDchafJJnRzZdhMe6eYeqBybpNjDmmxA M8tAgF0eBFURDNE/gzNwbw5WVVpDX/EsK8ghQfX/M97dRzIYGC/LghG3axTR zErnFZBaG32dy+4NkayGsNtnF32d9RFrxeZPN+Vf/kp4SkuBjU9UyAdBOJDT zB+PCFOf047pmv9IeIFyotpGicXmzEZUaFranBXQN/kumGd9ZPNMQ/dVLTA/ LrMBAZ83AMdeyd/Dycn7AaUCizcB7saoxOWLi8Z1c2AvsaLyYJRnZixrlt6O I+0M2e83OQxTL3csVR1ZFgMeZyS0a08Pc8UY5F147tV1dwDsXkf3aP0qPycK NqJtQBq/2fEvMQgoUUJ+q5GwqyTbwZrwcfBOhUFCSJ1D8nNJn4O5dI9oP1i4 OnUcs0KpQ6UMallKv1lAr89BmmHj8PHvQAU1QT9YUog5PV4j210tHpkHD0Nd dRxzSxprW+sHD2NKFbVLuPClDGq9SFfLR8GInH/h50fpm0ftBTE+WlBCCw/T JdvTuVvrBy1L00MdcdBsWenJHGV/0RWFLmxpaTiDwi1It0OxLEo8WFKIp6nb v1PYyVvoBzH/2ZUH2AvzswxsNdc72NQv8rMKZR5z1Rxri9KdiJ1/47Mjqcd6 3+kPPlpQeeOQdgs/d7lb6wnVXeN3HxXgbVnryR8Zg+G3vSCwIKAKV9xESvdi dPSXyDI1AgAeHx4fGh0KCAYHBgd0Dv9Lk5E07+rtlOLg4eDh/nR0d3b/+uvr 6+jp5OXk5fLxzs7Oz8z7JCQzMjMOMQ4MCignd9kC57M4H+4BFbsBHhIy5JE2 96T7Qm3QtDrTnSOgaOVy10FQLZFOdZ330T8v6j8NRmstQJRmD+WvQ9nSG5/H 1PR1G5NuWOOVQzfg0PTePdpoYUK3x4XfSK6l4V7PJHwnTRqu6d9/F3WCju8t nfdJIcQ+NHLAdEOl9ffcs5A6W3R3ttDXqZXtLl+nV8xelalvWm/9ka2bwC9J dnd0dL/OGttCu1NBAOGzFoGC+uwS06pNPHTT1KPkAyxCVFuR5nl0dl0DTsjA UP6RGnRJRVf9NZaSY4QqX+u6RS2pz3RueXQER0S4x5ko/7waGGw9B7UEIDd1 edwFWud7dhp0UpyeF/2ZEx1scQQuSanqBi1JslDMXOW+Emp3NrF2095xAESS dVVXmUAmvBBsrvEFdHR2FohEXb/qBkB0uLntS+u/UxCaSEarzpmURrKumh7h jnJ0WI5FXKrMANhJxVYeS5SoGMgtRHF2Sn6MJXWyWZddKDEHbRxaevBcIUgm tnl0dtJCvec12UhVWkAo5rlqGp8/m2rvRSg1RUu5dkhXdoSaQpWqnQJE06tL XcVaBl3rpxdhdieD0lxeqPqbL9GwhQXTlaiGhIJ0T/fTXKCVmNTVjVQ3V6ls FoT2LhCQWgjMdvYd0C1G8FKdiBP9m6yRxWosRlf6Zi93du/aXGOcdSrgjxaE bv4FG+JymESg5wh2JHl2XwZihQB157wYbII/7huQL7Loll5fuMvMQeknxmdz vxIbGRN1SSJIuVP+ehL2jWfBguKj/xzWW7cCi4CF/O/3DDJ6h9FQZyR8C1+3 XvOmEBqycS+3+X7R0OUf1gs7kAEycMpw+Hd26ArCSl8qj9AsqOccKka+uQUq /lXWKnh0bxCC/S8bBkdJp+Tsl0MnlKpu4s97GNfz16j+AnOjWwAs6bqrUfPu d5d3575EjDNCdVxUyOxAkp4Q0i9UlB8qIqSvNE5EhrJG5mBsFrvcCxV31JWS RtKj8APXL8VTkXXnfRiHBk+2ZewjSLvdhuiMUG4b6AutmshHYpbnBtLTp0Jc xVCR1JWWYGV2dI7Tvud1Q1y5VgcA/aoWtK7nCEQtwWd5dpdAIr7IBUqVqFNv Eet0W5IvcGh2d2XuXet9bkVKoP2R0iNV3QJG/quGrW3gI7d5aFdCvsqTSeml zxkvRL/+mx6zrQFJ/hLJhUs0tBnwSAF7MlpvEeZ0XNJKpeQKLSTJli8YbE+l ZGwZV9OTQlWvkti7b3e26IEnei8DApBqi89f4qUSGm/kY8bpSpqvkd5MLlOS wxKa0Hv6eHT3GrQQ/ZAX6m1nJ0BE04zP7CReolt2h4x3N56YLduy4ZdHIr/n RuguTk+PoJuJ8ZkbmlZwTzIbtHl2R15U8Qsi0Y5YkULOuZQa0ipVzgjSsFt7 dDDpC+G/h5rR2LzjHyxAs6zMQuun2zaLzyxicidDLCZ5gzbbuuzTLKUiAJuz t5vZ/77adva1PtBdqSk0XFp7WuzU4bEY2PIBFPRPHK/qr2USseGZXyO23uIw 2gndZW8agjAWqrbkoQ75+oUQi+Be5x/RRMXT18wbczGnq+982cYCKvEO9qUk Cmwb5pDvLafgCQD6xe5gXNqeQv4qd0fvxAJN1+5S3OxD/GsWhD/kxLa47LDx ALvEAtvpsUn2dHE98XTHh6bMLr3hAV/VoNNxWmCsmEbShDcL00Rzji4QvuQG CKVW7Uv/oCPRp9b1DnaSA0NIj4SQT6AWbtNTaTNER3d2d9VDSSyRoYvUSKW3 QERGoOiXRF5SUwJe6ObokvXa9yYCX5fI7/5H6/qP9tij6AovsyrDSde3Rc1T 0yviqxbkW778ukdDPTST4M39qr78xL24ixgSMIahZ+VJ1DAcCBMxCZvwy6CN iK1+EzAYcOVc1T38raH8OQTj8d2g/a2hWamDb2sIEDGI8nVFIDAL4zAGEDPP y6O5hPxbf4V88UPYKTeh+luh7//1rasI8vpbtG9nzkHbKzEIEjEB7//5xRsz CBChn299TyBT5HSatY5DgEB1X5MRm5DEb3V2ySvNdXVNXF1cXUhLSEd02khL ipd40C8sLyzb2tvWKrR2dNfX19QjICMgPz4/OisqKyYnJ9mSLbI2DTg7ODc0 N+KYQaciT5mWmZaV/F3qdHb24fr6+/b39vfyw8LD3t/e39rLysvGx8Zed7z1 x60wJfL9kujwEBe6sNj7KzMwM85qo8foemaGK/cNOb/l4ygmlTwVId39XGeU dT6YNCiSM5h1VNMXiUga8EzY8zIGm8cK4cXAAjDUjzdzdOl09UNJ1LtJd7Fa iNSNcgt2T2Z2k/368tfl8+b+5aPV4pTnEfPU4+DX885eenRm6df6QwMGkNXo 5uH+KUhGSyMCBR7xnywnC3SkdkWpNxWQDypSZ9RIcoC1S1U4CPIohyzVRUIi rcZKdYy4mm9ps+dLQzpCQcVJEUgc5387DzWl5JU4c8/sXhp7BSfz4M3xkUHF JDAuT2hD+NUn3ZTxktFxtpWqehFJPsf8yGj9NSchPmMlarK+4Ue3Jvo/+3JF G7ZToj5HkB00BR4BUfYLX0w+BdOHKeX+6eYdX8pR4g2V08Bd0/01/mKBljXs dKKDM0Xvtd2AdFTsW4I923TImaAlGrqvOZXZTwDS9VqQuzeZXRiPxfz0fnTw kLSK31k6Z0TElnVSA4tyjBZewnnSSQdyMXREoDWEVfEo8fniG611t7zoH/GR EAxeKeYYZqiwKDE2i/dFM8OOGPEWSwrWQwR1SMz/uyx6l1yEDJeGje/W7y6l N/uEMNc1vStcV9jFBnHV40RGwdLQ1Y97jHyteKpV0/CZAFgWiimI1l7Ccip8 cgfEt1EAN4R00YXV/LVZ/p/dpg+nta8cWfWvRaoj/rdX/MnP8C7MLl3nWeeU xgEZFUTf6Z7V9XhDvdAuDA5PS29PCD8JMQP/dmHKQSsuKZfTmXPMQS/teXd1 +kmfcAV/fXUdY8xfYYUTNblBY8pfuQ+/vcxBYcwnxVM/D3h2uWr4/dVB8QpA EPH51PO7EnaxPi0vlo/CPOrxMngDAnV1ENChNcHY0r8upJAH012wOXUb270D e+c9Ckj1uNbV8GhuVf3500poIpf2bV4s2ND8RycdBX+osAAPGHbs7Ebal9JS W4CNPXuRI8NA23FqhQkp7DbwOzn9KGT2ZMlIVNLIIQX6RnpnAR97gUkyNnSa 1W8x/fkurQKpbBkOnPO1qWqx/7jp/UCtSkVGTkVCFh0SM4jSQggO4LJZCWxI zLggyxqgf9iTZ2PBQQildADK+QPvqxfP0Ic4hvkzt6x1S14HJC2QxMqMl6lV n2oIRzKOvNDHNdBe42l7nmrXBP8nysIgt/AH+F93rbjo64JFnNNZVzdLXtmm h/X203cjw/lE31DbBTRKLOPhb/cgZdLXM2SqdL4wyf9EYzC66HXyWxwynKLq mr8pcjXdsi7c08ozIlpeyczeH+6LQHOOPuuldA5lhCWd+SUa3V1E+Rk1RfzQ yq8RRPHc66f1kgwX9egn2Jg9G5TwX/Dlntr/cnlZFdD9Q0N3om2/0s9pfS51 LZJlFjo0uKJdiTHNNzK7xykb8A/KMCaZw/XuDD4uyl7XWiktSBmH2dHwawTg ZDlt9lOfXi7yCBgkoNwO5t5O7wKHg8fR8NNu8Vo/dPRJJj6Ho+feBYS4HUFD 8T/wJFvo8hdBF5J2hM5JFCL+bV1/FyNXDdFN71dvrkoMyn2wabf+mktlBz6O TwhC8LbmC7YjD6HGZtXzR1J1GxkSmWyYh3+WJUiyHh6kxsOTI9XUkyzhot74 B9ffdEKK661+PdcMHWHTBNOhaI3h9htKl9CSQ+EBRkOt/fkK4MpG8uiGef/j 6+snQNhdQur/QkcsBubkSvoaeLt68uLl6fhe6eni6+PgSVzncclrjfMs+EbM 6fHnQT6pJ0xM5f798+vh8WVfysj78+Dp/+bo+jHW+0TlaPBGlOmU8PLm4sd7 6ML+4fk+4vPz4/Ij/poGs5Us6VoEQLXiqP38+WbYpbtrlTVLRjRbjjVfW1N0 igM0gr96ikDa60Ljkc6x+q0tIw0JNCJ7Oj0aMZhjQoWBszc4XOnrohkCOOkJ N3af5vYf5ObqAM1EDXWR5jQP+vx3QXIe4Lrne6nzwZXmlPPjkjPx4LZ17tlr 2hbp/zzswuPmzPIzIEOSERbTETxFz5CSAJMyJY2iu2Q2dcV16P7o4ufKy4x1 8Ot4yFaoh1yO0lLY5ubxuniytpkGkpECk5My7EPh5eDiSnSW7Vybes/88/vz 5nfIOqgig+SUv6rSlOP9zgOW/uH88YFeN+/ORVJ2duAUXiTdJ1AlVSe9J44l tyeIJREkYXZ2dPRqJ08lQCQjIiQkCiIeJJMimCT/IvAk9yLIJK4iVCSUe3Z2 jCK0JIoibyQVImskTCJ1JUgzLSUiODMMIgF2dnR0JQYlmzPgJeUz+iLfJcgz riVYJaEzuyVsM3EidyVAMNQBdnZ0MDsylzDjM/QyUzBbMr8yqTCnMrEwjzO5 rnZ0dHYygzCdMoswhTIQMG8yEjB/MngwRjMtMSAzJDE5MxwxdnZ2dAUzmjH+ M+gx8DP0McgzUTFYM6IxqzOMMbkzgTEaM2ExdHZ2dGkzTzFDMEkO1DAhDigw Jw47MAMOkTCVDvAwwg7JMLIONkT0eW8wDg8FMXR0Sfytv4pCdnlrb4m1ofyt v6Wvy82Vrr76rQc1DddHeHkxCBIxZReEgacSMQYSr8PxmQthEzEINCnbXHl7 rb/8rXF9E4Oxvf2tofpR9+uZBaD8rb81M9dJdQgTM4h4ZRufqVP0MQgSMeEH AzM9+q0KENF3SnFjh7/6rb6Bs1dRwa2h/FvxlwcBMdswBvL8XUp7Z39tEDMI EIm7vMX3CBAxCOvvASXbS1u//CZNe38RgbP8rb/6o8fN4QcTma2hDdVfTnMV BhIzBomPoMX76zEGEjObBQEn2/pbYYJBcWdtibuh/Fu/v6/B5Zuvv/ytATEj 03dOaTMIEDFvnI2/xxAxCBLP4QU3J7/6KQnVS3N5fROtofpbt7O9Uffgma2h +gkP10twTRIzBhAXiLFXywYQMwjPlR0z10lbof0nZXNhhY9X/Fu//Mv56ZsE 8PytvzUn10tieQgSMQZnFIW7p1UxCBIzxfnr7x0TMwkQDz8tSXeh/Ft/Z2cV iY+oW6H8W1VT9+fhkfyqv/w3JyEtXxMxiKB3ZE1/FG0IEjMGgbNYUffnMwYQ M/ztCwMP+icIEynX02l5aaH9W6Fjb4Wds6q//K2jrcn38On8raH6lZMwIS8S M6y/R0BmT2sXBhAzCYWDs79ZxTMJEDP75/3tCxMxCBI3DSkjLL/8KQhJQWt4 ZRetofpbb5yxV8vz+luh/f2TNyNFEDMJ8Gp7Y4W5swkQMwijWcXDzOUzCBIx 4ZMADTz8qggT01xrZG+Iv/2tvrmwV8j5qqH9W/yTOCnYSzAGE5t9eXwTnLET MwkQoFPczegIEzEJmwQ5PC9AW778Jn1MYxC1sPyqv/2/WMn46776qqGUkRw7 KAbz/Koh2Et/TWCHMAYTM4y9rPf8EDAIEwk4K9TRvvwmBlx3fmlsu6q//a2o VcjP4JH9rb76ADM81UQSMIahd2F9EI+gBhMzCcX355M1Ka1+EzPbS2FzY4f6 raH8tadXy/G//Kq/mwc7KdUIE5mtR3dgcWMQgTMIEjGNV8jNl4UzBhCTNCkv X6H6W2EScReHt6Vbof1bV8v7/ZM3M6yh/CctQxR/hRIzCBC7q1fJ+wgSMQjn lwU3K9NboYwzQRdrFxGf/K2//Lenoa/DofqtoeeZHzPXBhIzrkkWT38Zn6cz BhIzV1Hf++sQMwgSmQcDMyGh/CkGR0MZcRefrb/8rY+9y8//7fytofoLDyst SxIzBvIYe3FjE48GEjMIoVPf8/2TKQgQMzc/LV8bT/qtofx9b4u3saH8rb9X x8Px466h+q0HNyUjRxp5MwgSMWcXE4GzEjMGEq/D8eHvCxAzCAc1MSNEG62h /FtxG4C9U/f8W6H86+01P9AQM4igdWpnYG2DCBIxBrOgrcv76zEGEjCVkwMP KfopCRDXS3dtcW+++q2hi7Wxv1hbofytxcHzlAU4M6+//SfYXW9zGBAwCBOB pK/c5QsSMAaYHyQtQBGqv/2taBG4v6zd/K2h+vGXCDHUEjCGoUMRZRSLuAYT MwmprPfo7QOtChAxJ9RJE09/+luh/RG7v1P5v/yqv/+TAyUhCBOZrdtLEHtn F4UzCBIxt6ejUd8SMwYS8//tAQ++ijMII0V1hWhtraH8W4m7pFXH+/xbv/zo lQQDDPD8raE9LUt0gmcIEjEGY2yJt7O/MQYSMFnHw8/pEDMJEJcHNzEhvv0p CEV3h3F/GFuh/K2FgbCgU/f6raH655SRHw8SmVu+KNNDhHMXBhIzBom7pFnH 9DEIEjHn4wU1M/wnBhM/L0mHT2u//K2/FYeDpVmqofxbyc/jHw8lMYig+tlE iXtnGRAzCBKLjVXDzwYQMAn/kx05MyOtoYox04t5aRic/K2/+runVcPzv/qt oZkdDCvbCBAxrkeKeX2Et6sxBhMzr9/x7QP8KQYQP9B1nWsbv/qtvoW7q6/1 W779rf+RNyvVRzAGEpuceWlstKcSMQgSWcf46ZQIEzEJkAA7JD1Erb6MMHWc axiJgP2qof2NVMvwl6H6raELDSEsdAgSMYieZWNsnbOjMwYQMKz38+EHjDMI Eg0jL1+fT778raF9h7unr62//K3D6Zs0M9cxhqH8R0OAZWETEzEIE5+rVcnM CBMzCensAyTZR6phhTFddINnYxP6W6H9nbOor8O/+qqh6+8fNSUJ8/ytI9N1 gEx8GzMGEjOdu6hZyxIzBhDM4O8AMb6MMAgg0UO1a21bvv2tn7m/W8XP/Vuh /OMJOygvEjMG8rR7Y4uNvwgSMQis3/Pj7R8pCBIzDSvXX7VP/a2h/GGHu7+v ofqtocPl/5gfiKD6rTMjR3e0Z38zBhIwG4u7pVcSMwgS3fOXkzWhjTMIKy1D uXMXrb/8rYeBj7xbx/xbofzf++uZB6D8W6E0J9fTXQgSM4i4eWdjb52PMAgS M1XLz/8HhTEIEw8/20t3v/yqYbtzY2+Jj6qh/K2rW8n55Pz8raH8mQk0JNsS M66/0XS6ZxmHCRAzCbWrU9/P/TEJEjORAzAj0/xbYYVfjWcZi4+h+q2+V1P3 5ZeuofytBQ8/L0GMZDMIEjEbn6ejWxAzCBLF9+SVH76MMwYz1EmPeGetv/yq FYe0s1fd/Kqh/M/rmQcA8vxboTAh03SOaAYTMAlvnI+8UfgwCRIw4wQNPND8 rWGFXY9MaBcTofxbv4Cor/fnraH6rZgdOyTX0zEI8/p3sWkbi48SMQYTo1P1 65QGEjAICzUl2Ed3raH6J7NwfROAj/xbv/2jU8PN4aH8rb/tHDs/2QYTM65H sE1rG4u5MQkSM6HFwM/rhTEGEpcHDSFIvvytf6VPGbekra2h/FvJzPzvHzGb rb/8PNlIQ6VNEzAJEmR9FIeACBMxCY+oUfTkmDMJEDALDCPQXf2tvoqkeGgb iLm+/KqhoFHcz+hbvv2ql5A1PC90MwkQmKZkbZywWBIwBhPf8OMENb6MMAY8 0ECpcGGqof2thLWkr9zN/aq+/PwJOD/QEjCGoUOpcWhsiAgTMQm7qFvI8eAz CRAw7Bwn1F39rb6MqGlsg7xZvv2qocDkkAEwCPP8qikgR6t7fG0wCBMxgKRY y/QQMAgT65QFNDN+EzAJPNtIdbpzqqH9W2BviI2oWP2tvvrE++AHNBCYrb4l 2Fy9TxgGEzMJu6DFzOuUMQkTMJM0JSx3/a2+irxzFG2cjL78qr+or8j75Fu+ /KqV7Bww19AzCfD8dL5zYYu4EDMJEqdZy8zhChMzCJE7KC9Doa2h+q1oG5+P v1v6rb7838//7x0SmK2hM9fRvnhoCBIzCBWFuKRXx/MIEDH44JM7JiOMOAsT L0tj+qF9Q/2NrpODHKOnQlnfvvytofGbAzM/laCxzjqgT0lddO7Dknagzb5h SCrO5Obg5ebOJzYQ5nbo5evyKf/lkkLg4yfw8h7w4uVr9tPkRuPm6JL94JWU 6epHfYYEFkbzdkQo4fqMT4Ixw+k+5/7w8C4e+1ijjy7g8kLS5iwvG4fmGiMn kOcm5/B1/enrQ+B08Wgbks4eKZXl5kbQKXvid6kS/+fj/ib+5Tz+8P7z5vM9 sf6gz/WZ/fi6MGyCqpra/ODg5+bz/E5P4/brz5Lx6POi/vzp+fyU8O0R+eRt 4Us1kSbhlK6vemo34ubw8DjoJJXo4KE5FO3qFik/4s8bctfx5/rg0Bu2lMyD lJLo5Q47mGwbWr+PLlzxQ/H+WLSKbjaURUTjU5Rkgu0bm2DY/olAkhtXi7Ek nFkYJvv8GvJrT+uMJkb/6tz9dM3PVLjgZ/7phNnSS0DPbVro8uLNKUj+HKga J5tGpszyqOAvmttrKacHzgSV5l7ObcL80yjPztyCkuYf55XzRVMLx21VBNGT YNeahm/kZujO/Y1HC+vq4f0Yw28ixUdG//PjSMHv2ANGKvMy7Bodf0w26uNv 5esU6SdGDeDs/tRsGtsFQl3lkbzqyujpmATgIO1G6oLWxDipuC6Xgy9tJtMG B6CVbdVlEzTzzo6OxFg7lOksn/+xmsuGPUY6dc3gWefpavoIJ/MO0MZs/BTi h83wDMOxsGuM4oU8Itjl/obC5wic5fE3RklGALQ8iDG/V/INmIHhPPIFRP9D 3HoI6krl8yhCm0no1EF2bYuwgd5QZDTpiYYYHcHeuv6n8JQgMmjnRPHxA/Lr XOUoXDUoaF2o6RE/R+X+W6KXPQg/EOmGRlKGMWrYx+E8U/ZBqybp/uLSOG3P DTuZ5MfiRuEoUrkFmvf6XwSCsOfqwgKV2NDpcchJAGgxSq/TJlS4wSw8oBjZ SYjeLkb0wJVCf8Fgkk3S1vPMyPEcpM6myvD8SkHfsvPp+s++ac/msv6aLuXQ VuDy5v9yVPTOz+W8LCpADHdH5uHldOuUAV6hQAj1wtTm+9tsnRv6/l3YCCgp /lzqTsxWfimD6yzPRDlG6l9dQwNDwDpFaSvS/9p+KhiD+ULR8fOURs2zafKU SkrosICVvhHI6xcKSqnPtHWx3ZI6huaVLmkm1Jjp60fh4s6QtZmlWeLj5yRK aJUobBOj/z5ILO20KAqS8ySm2lrxbQ/zzbKUR75EBYriqs7zSb4dXwhrQdLx 6JHwsJfJqtZGXeVftEWPJcwiMrEBKvbcIdL+gppQowovmtLevwYoqejhnES8 8vrxiOWIm8WrANDpQcneMLvhPLWN3i6Isl7g/c3Wzqxfav3uj/PkM8enktyu vnIPdQPgzIrEb0mLhAtvcTKDCbuSxi7hvEh+p+ivU8Q+WvA4GiD6UdDm6QZL GP0KtPzglfID4NoHPhoqNYXDlJTgiB4u4ETVN4rA9/gs04g/qf4SItfvVCZp wt5E14jabYO50fAsgsADV6c10UTo5+SbjosFttdG4M4/072A2uMsc+0kDCfU 0DxANSRaogs2kgnHDknDxpfk804raY+npefG/s3QGfQa2PwohrNEg5vfLGzz Juc5RzcIsw4wdijaP2XjRii440TU2MLyP6/Yb7/iiEeGsysdsfwmmfAXon6j bWU7H0Y87TiE16qiwMdRgiAB6g1WFK8C1XgkRJ5J8PHNlefhcUZJJKyiCqj4 Ru3elsVsRyim0OLqVHBRslLipzouJoex1ygF/jj9nNNJ1L3w1i9LKIqy70bp 9Kgp1afJ0OCN/uzSjwi/gTH7QvPc1I0PSyyUgVWn4wb9wgtEMuwd5uMFKny7 5JfhRMLG5OLMikXv3i6URI/BXwIpanXzrsiosOpVPuGFzKwh+9Lr0U3S8vmb i0m4SurmqkqJmI/5tJdI8FzzaEb/3lOT5p3IghHBBmBGnovlYunHxgUp6QKU 6qOPU1pHrBz+3CWU5GxH9daUpWzhLyhKFD1KFJtLeyb//wxtZNa+9CY26fo1 zySYtZ/QskYu/OOmTQMieCI97R2VbiBsY+sc/+kYLuD6UcNE6+kM4Pbdgu0S SkOfLpLj2Rh6KDDpz2Ze6Wvem398XOKpXut+VIPoQZXubr9fY8GJAHcu/0f6 wKAKP14RE/3CdK+I/eG005HDbl8F4hNIqRJeEaTb8WFGCyjisenm67I+2CDh 3IhLokPM0YrRAZ0u0LNeK0pG+UuBlJwlXG7aKItBNbU12lpvHb8XOXdyLrPB QZrS4qLrt/IjmvGv/uXn8BNuhiB8KEZRSlrC6DJeLUjN4yKS3/m3Lm4szZRI lQd9Ez6uDubMCfZFTlB6L+mY7+gvKITMMr9EjbfnAtmAPjVHUeInPEuup0dK 4JmHLnUvqBovYeAh5+ICSuH+sUBCGmny6iXSbtcx4MdLWDFJ/Aif8c88KGvl AfJDDw3hlGqKm04Z6KAeXqjSHI9hV0O2SCjhbsJG01075870KJPq5qFh5UaB 2cHzGKeP4Pgi5eIqzGM19UgPRhjMQcOOK+3QS0vpOs4oF/rr83vrID7Fl0Fg /V60jfWe0dP8h0bgVxHWfW/O1EvgVkhv8gr01/8G/+Yg7+r+deDx/7E8WtNS 4OXxetD+tuHS2EQh4evSh0khlV5pQ6eTxvfvW1vqMsfT2/86nH9AKNPR05xe 7v2jLTjnre/U9Khy+ka8lPNwH6pjIYRK+bJYZ5lUbijiJffWRZZtvPQiZJT8 4RAgTuHIHQdG1ks+6o0b/+vQMuw6CO/wiS4EXtvTlSavUqcj62zO4S7VhCDq 3XBG5FxS64oN5OI+SOHn46ZK3POg53tuwAFesUiVbIDMofXi6tb5GWQ1JyP4 REbnE/LU+mou6f040iHsKaeFQyzW3sUm6y7m7qBFu+FgRpKQJziBpeDUKyb+ IK74OIom6+wnFW8tBSpA42zr1CP4pNJIPuW13/KYRuP+LuGGCxX/zkQk7v22 lPNK9TxIp1pUjEgR2uZICEsqRw3wpOhyIvRcT2Ybz5XDHSgY6B/nKsqR6YHW MeDsjfrgnUZGun0qQlLTSy5ULG4oouUtSuHA4LhdleS7T8/RmI8hwtKSPOHt s6q9f2TM0iAx2FxJRfAu3Pcmq9g48PCKbaXv/YQ5V1KwF7WV+5LiXnA0lMu+ qepsaCzz4b6u8UTz0CdSrwpMiLvQlOehPR+MUHDSrNBrrUdI3MYriHd1QVoA Rsggw8S2Lka6HUeljkb86dZCN+4rIZpCz8e8E2sE1nQqkLcLKAr++lbAxw6/ NJmch3fZ3u1ICbxu487gletURcX8lUfjZdlhFcgsQvfi4jzpbCqq2gLk+6+b 0QqB8YhGc5Ji/QtEz3/mqGollGVGv9wF8B5oRE/mqg6hGEf88ZY741jiI7Q5 J8BEbKVmsjKD4NLIVQN06Hg2Bo7AAsbE0uvjr+o155oYR/jSxRvP9wte/yzE q0nBDNMP5vNa8mm3D0ro3H/rcvBH25LymEPzCkZK/kFGrVZjhEXXNq+GGUNk N0QYlrOpTfzms+bK6KkoHHxIzdVILtMasg3xGkQmYw8qtdUbPvLjqzQ0KfNT chyxztqSxdrhdOrsgvVULi7e7B8TLArWD7f+sERGOw7hUPw38uvv0gClD8sJ 0SsKJLYhZ0cc+Axt0vZG4OmOSuD+BvE8QfHdS+Hrh6hS5L3P+pvYUMH62YO5 8h3ss5X+sqgeCtyFmlIDYksKAipjBuLx5++Uo+KTQEYYquDYSfpLyV/jaV7V +ktfF2OUCNyY25XowjquxL+Iz7rEhfRtRzg/SD2VsdCzd10nItP70EtS42zA I9L34bRV/tLgOFHD1K9q3rbB4TrXsANdbsI/yCDAttP+LTWSqw6r0NCG8gaF Qb4dWLXMmhI0K+S26PI2S8ci1Ddq6LYgUUuf6JzyUoCaf//oV8xHxxWliZlN 5kfyj4zg6WrSEgpGV+hKiCeH0v8yXe8Mx0nS6DLsE84UXSkpYOjmkkaOyODQ 0AbDrO/i6s9qRzWix7mXI8bMPPVv0xrTt/THuZrTttX01ILXSCyndfIvgPxL /kmdXAuYy/7+PAW89Ct0jqDv+p3VRmLZ7p0pmzHSn+Br5BzbmyrrXSkSR5t+ n0XKgSDTJ6TSKZIv4JUeMZchSqYlmLK6RvPbR1/kFXSP0/VBPsBfv/uWk+HB KTNlBpgOL9QtOKQX4Omt0UQYUjQvDxy8Ias3S0vqjTsQF9Pj+vyYy5XK5F5h GlzDXVaPJJ5O0oT8JFcvn+YsMeKGCObw2sOQ7de2/j5alVpwjNRRmxwTBjHT VwWJEn/f6JovDuycqtMmMzS0HRADviK0i3Xrz87oykSji500GYfre2lJo+bi F/OZ0ivt5tWwNNjv1ih1JB+n/1EMl8qI2NKPoTe0YzjpRJKvowvYIs2UlumE 3io7419CLuiaYgcRi/LPRrPp3A/ykqsQ0ocdMcWr8egvF6XgCK7SsLL8sv7Y UuPO49t980maz9LL6fznDl/kLV0cSl6VkQiWleMkXosvj0bqSenTtlhRojBQ 0s1B0MDn94Xekd+Vg4KX4NLywe7LLrMlrZ7tdwrNgPTSpkui3qeN8lrTthKl UcWS0tfq1NCHpMNY4NUoPI/nAfWj51rqzrCobHWUSCjyg46PYJTaleI58SpL b7Ed/p7x0OEQopTh8ixKks3a7B1vw9XMIqOwf+ON0vEtSjrhPKLQKanaAcgD n0ZLB26yRyGRlTB3w21JWlyQzIK10/3ItmDs8RNTt8x26nHydaaY7IbroQI5 QVdiSOpG8JS8qxvpQ/VH5+iSlASzd65Gim7wHzuEtv3gFvLQ3pixJ+suKdIi l0TDEv3i2pq3xDTn6ika/F0lqx0Hxifxux6eWimSzUbOJqco5XcFds0iFlK0 lPI2lB9G4xvLwXJyL0Gx/116SuWdRi5F8Z9FUaUWbInOhC616fBK5svbWfxC wNT4aVXjR0ttkAvnw96AuR62pMaiwCLQ4u/6Ktdq4EPr/tLwMW/A3Y3iLv7o KpIvdjsmX1+T/55VeA220y8Xz0aSxFTl/BGhbVGU/17/mzOeOIph8/DwQRJG 5WqDO/RMzFjoP7Ivpw8NZuASu1/y6q10uOfmDkMumkqD37lqSLeFt5AzhifK Q+H+lbf96HEAwSvvzenK0KQhatKnlOnroQ5EpWxD4xrFVY7gHy4oyk4/YSz8 4vpERlpSd6GYdiPmJR+QSuLq80bB7rPj2F8WcpXU/bHQ6NK0fcjAHtBp4HQK H38uMrUBsacm00Y1lZ+VKOr81izHPwN7dUfBwzgV/v970lOxG7dV59/T70Sn vtEBlel+rkDJtwrHc6SlkrPaA9IRmbNTCNrTHauaNV5d4xZG80ow0zL+05TD 9EU1KCX2/t0M8otGcC5QiNGPCQUuUSgrC4yg0lIB2qSo/9RO/+G0XgOkR8gX f0G145tHlL3cHkho55fvWy4oi3TuK9QSjKvyNkbgYZHpX5wtXircCVtC8hT/ us8onZxK/v4kwqjqp1yn8tLoR/xSg7Ma4wrrkpXMFMI3de0pWxjP3eB0Fizi Fb0gQ7vy67dG2F6rOMRcg4P7MG3IkN0vCP/m8R01WWnTkeCEpUGmkrZQsiOx Sv50j8PDyrDa4cTZNYsLuS4EKhY17+Uv/gViIskMmteP88BLKKW09ZNc0+ms SyyzRNjj2vwo69VfXA3mLCDCvakdRChr9gVSQXgDIyflzv8q5hddmoRR0+PX EnSCgunT4DAiSHpcMu4P0zz9IC/lQb/v4c4NJNyC/6uK/tcbqQRrP9s/8AYv yiZ+4jbO/FPoiNMq/JWL4aXSrJQrRttDTrBo4/BLgeFHKagBC7D8MQXrh9Oi 4NswtuhL0/xTCQhH/aW6Wby5X/dH2cxE2+xmS1ep08/1W+gE/kj8JAwlglD7 3DLhRDzPqwFJoNo0RFKYpa2hxtD256+n0hVGaOQofISAuOvgBH//Y58vkeVI 4Ixn/1AB2/ub5uA/pAArsc10pPLQiUrp19sq/oltyOjnR/DnJPsDwp0j6NlH g0GdCMGQM4sGKTsqkxQrsiENlC/z6kj+SMn0mPLi/+AJrcvgm6pNLfAOWj3T /UoN7fKl7+fkeA39si5eRujAZkSk9UfbPEKv+bPjS/JL/OA3XimUJ2/pHjU+ +unO4yTp/lJeYOsn6P3p68j+vpf8aWeyfP6+4DYQSuDO68AgSWxH/26hoR+F 4JLiDMn190ux3uKiufZIq+eeUc7/FwJCelHH0OAjVajQSEBrbiuUJW6xbemW Ryhj08aUMUiX0/3svSPl0Jo/RKcfmgZ/Iq9I3JlHFQKllMCg0ouZDqI49zzh 6+6L47x0aQiAMqSLATrms3wms0CLHcna5PyaAbRJ6taOSght/1P3APx3SJzU y0biluboLG+lIGxG3OxpKCs4R02rCPzA47/numXfAVtH/o1H0AiK0me6+t6x phQzK/634LVTBIvT30cmbeIebmjQRLLtWphdSXHT4IMdXmJOLsnBKcDN03Un 8mzC5dNHbdTssTff00qjx0mVRzqJ0Y6V02Lpj/9VbSUg3g/p5sxbKy1JKpOO 0kK8UEA8L/oDS+HSwAGA2sM4hy5zs07aw1Y/REYjgLWbdkYQRStrtdLjrrPu QyPr6r131Q/34NhMFgpvHeuzLtKaIfgiPurX0m+r/Tcqa9L3+cPovCrMusAA 9SAglRTd4Cgug5JFvsL27khK/kILrS410mrB/Xz8zdLOsCzTjjfZ55UCI9IA 1SREi62pIa8uQ811Y/88lef98URRlGrCdNMh/Gibr0idL2vj5+FQlJSrhe+o wYXSvH9MLiFaKkfVq/0sjVrr6DEaB+esQ4DL0MbtC++cRIN+07ZyMrJGu6Qs x94JM6T8/+ufWplf4+kgSx1LynWSbSLH/7vUBaeTB3ZabCDQ48l+/jAysoZf iiarDzQpzWrjSvPj5l249JHXR6Yl3XLnSyrt26x1zEo2PHIo+5MVpyswRojq oiuQL2WKY+O0Phwp//LPlV4C/0MO/67GsCElpNJ/w+oyE/cvknTqYyB1lCFO vuGbm3KLUkjQ0m0r4SbXLiyV4F3bLtNII+EL8NNL8dRVz9Po6abT6efgdQil 5PDa5FUO7vDlkC0oLaVe/Sy07eyAAe5QLgf1yC2lxuAbzcDLF8Uj0OYuE+Ho jCiOJtbgLulG/A3EQs2DmTeinc+CSoIrUQCGAa6z3ZdmkdJBULcAzrwvQFzN hh+6XJ2UD8Kt2rkGAipCCK068oHSXPI1JOHYOkSomczi4Eqrh10b7Q8o1NTg R0b+6YKaMF4zqedm9SLvVSAqBfhGCzY391/Y6IBWlTRRliLp6JTrBStSFDiD MJJy0VztfipjmuVI0+vzJuPgJxpeSkouDms1uVNnjjerHNn1z/cvtwOlg3f+ /s3SCefs6kavheEyaUhEKoWDwCLpLkKUAlRq0lx+4821KSHtDaLj5K9um9ix hevXQqFBBZTrNJhHVP6/EUgSJtPO/J+0GEUrgUHYKDsrA5YQFDHk1i0k6ChE /CFxwpNV7yxESgAq2Zn/zfuEhPImM/AcXBiD9wFSzUpp4fVhHXFWbH/vZHSh h0ooVuNGKYog6PrzbkQX8tul4wbLKDbQKH4HMcpG2uf/BurlWjxyGEZ63sOg seXxLDTm6ingPdDV1CTU+OHOyhmf/VzPotI523zjBDjgzJ/mileuQcYkBPKk 614j8c9KquEy0LZGHUZERWPmb2YrSiaV6l8Moi0o5Et7qtO54KtEUdrRmO/H 4Cxd4NUh1u7USat/nhpKmqgVV1zwTQ+RBeXbMdDpCTcLB2xUGI3S4fNDHrtq sNJnSym6MKwSlOMEUwG1SY70nsw4hfdWY/AoJwQoMBkorL+6CtPSqfakwAnP jUrj/Tb10j3HV5PUlOpvC7YmUvrGqggvIJ1BzwVTssGs/tc1713qpS5GwOBA Cl0FdOou5Krcx9AgRETddaT+9kfWMAeyJfXY6ZXSkq5KJjgQ8N4KL/HU0N0m 5u2iJUKvPkZdk9IKxkerP+qd9i5+UYnV7S3e2gKO0afQN/0omjuxJ4bvif3U LeFGqARx92odytK8+NBRCL3a0hkXxfX+RAtdcb1qJbBESu7/fELt7uBHCPX+ xDcmrJpvsz4C0lTQL1QfbSA5RqsDC7vQd6343sFQ8DwheAj88tJciA3Wf/1T neL+Gt4gpf8/L/HorADS2zHQtAOi9erDI4k2DojT1i/gIDpK/CYnvcO98+d1 Rv8L7bng6ES2RurSS29KW/quJPuCV0SgRto1OCUeKfG5Rkv4Yg2SVCY2v33F QCtI+rMBcQN1wixL65JhVc4wLJXHmqXQMuJLmptgmoSSXm9YKFXRRklGld5q HJ/OJ2apcuon0N/2/F41da+mLvorWg03iTSnAv1DGS+U0MXrlCKy0kpAkUXS DUkmY+NG6eJC6wUWnTIfznHStZuzIEDMgybNM5pRGNICl6bDqkcqsjxMQynp DumW+pXiK/3TPv/k+zaX3XXEDBvo1GffoEZCRG8e0knuM9PM0vTEoMBqzE/6 MVQ1j9LBUF/SK/iy0tX8HSqUbafPRou1Saf+KtImWJ3J0fH+40qM4fJhj0D9 ViyVz8NyK42VkimSiEvggdKUmSeOLqELlyZT/mrJHKdlYizhtAvtIiMyJVGG OkdO1Pim4zWWxw5ptSGT1dAp0+wgmLHSyFxWqC8mRmAIX+GzxZ4sQuCERinq 5DU1SLFKGt/FkJyb3/CwxfGVSgfM40Cat+AE4wgarlmG/3hmSurgqxuCdZsc Sjc/EB/Iqs31amo9ey+SRxqJ47ATRCD/6c2gK+swDh8o4FhBu/fpOfFEs8Q4 q/Gb0g4kVUQn3QktnBeVSuFJ2OpG6ViASEjWlNr8/lBdxz71yKXd9EPAHOce tQjFTC/kjNJDbiRrDkih48aSJsUGddLl0MggXNVQRork1TfUkkRdKVqFlP21 RAXtXXHdchxGww/+g8tysrX112+Q3jgJRkryMuFGKOWqtJCBu9L8/ieb6Ir8 35XQATtdg+MuA5FVb4LGV0YkRixn1WlI/IWanSh0QfBUYpG///osT/LiMwtL 8u4sCLKPKR+AwLTSBRbF7/ZE/vz0723kSuXpKHpVD1FQqE/xasZqug5KG1yC 1BdHGeX9SgVKcZvyAv1IinVcElCy/twilNQJ3w4lm7fE2Jd3Kv4grdK3SUCO Rbwu/LzS2m8lDdI2pYD9R/OjKMowvYKkY8govu2VvVzYqQLt6cOa0r5ICcFb piP3LMzAKJhD3dLERV/uv6Zr0sMeMNjj5fDr1xySCE1E5f+G8DcmqG90YCzM 6EPYiUoj5l6x+6+rRKtRSOSmSJ3OsqXSWv3Q4ShMRigFSuL6FzsUVRSLm8xE 5oI1siY1muAjCy+007HoVdKFNSna4Ejz6JPLi9M6hOjpRRFBBfEQRCDyDsL+ CkqINGMQRg7q6POkrhuvPJr+6+HoSED9DSxXXvljdDPfDEhLwscMgq4KRIYo Zj761kI38kXxB2QGa0u180hBOkdWIE1K/KReI1JG7yrmMrJIbYjtrFTpz0rO JI6LRQWiRsykF9eSfODkXEuvOtHTXuKCKX3LnON/sS+N7BNE5mbzuVw0SyYJ LhqSz/0zvkhySOGXKOrgSuIeSJRmjJ0P/NfwfT1I4xFcFP3/KG7//JoA3t4T 1jQdy6Thzhbp+NDwMrFT97WSEy7F0Q7UEhIsIEpvROs+ul5SGnIne+LxE7bo 1IhG5+DU4ZXusF9Hm8lsSp9E4HRIsVLxHgxK4jX8/j7V04TNRO6iB6jlnH7Q u3DhXFi/Iv/g20o2zSVuXfC5R0ZkXTR7VQcW5vykKPQsQe1KHFOo0mVd4xyj zuWK814xutB+QdGk0krS5TMKAz5GJOloQSpFRGn+Km1SP1DfNkpgr4Wi7sRE 70o688vKr0ZwXe/+/GjNscOOnLj4RCzw6aCr15SN0NLuSUk3nujOat268oyZ 0KWmcsMI/cVBzUaDv2yj2EgsKPBAlUrI7QVGrFYoorxE4trz6dKnxeBl5s5M 01+ajDbnPwN5xUHElufh8NtJm+XmzynvlALjtUbpS0S9orGnasfxA9zgmnHS X4Myn9jSKkMVs1xGt94s52+pQahjhCnS2A8j12NE/wJhPQU0OpDop+owBHsu JtDspXVseY/QSTsDz+k6/RNFyBWdkP21KsWIzf1vLnA5/ezKtxgqUD9HnD8h 9mh3JZGyOkSpSDLxjeoo/dDvNT3IPT4uJInQ/zCBb+DKx5eS3ufR0KwcIV3q 7liZgwlFs9I9aF/jtbSyV/Dd/1qqA9jd9Ar9zuWBcIb/l1BxPnXCv/fGSOkq mppy2gHv0OiVXW8dl+Dz4pNI+BTRIiJax5yvTkfjzOKU1CnUdUiO0lLyA8fy KzKiTPfoXFOCyEOJUPYuyF8Nn6YWqU9RLkb60CSn0qQlh0b+/PDUvEMB6nKA Q+urldLV8jzhNJWTN2nSJ2OXinNG5ujnb/qTndYLVEytp26XlPCY6dLzp93+ ilXQ3peg/VHSFGTxlwI9BA4kmMrNgqMiRmReopdvSJDjjWnQl+4mi+gilWgE MNDnKO1db8L/QsvyLPuhsWD9JUXMr5c9wdAl7A+2LHvS+v8vS3qXl/9PvUpP Q5SIMLdE4pgOxgptmLq+P+VU6yfSwqfO4wRDDp2eNR4E0p5Bp+EC/Di687Iq iXLTlQxfK5Th0AvaDojTqHvo/0KLP7QnLvTrMpXdBYaBrNvzxtuvmiok6DNd JBpi0hmHrFue1bfi0JwcKPiE00SnNg2OxcTrangxV6JpR0yW/PzJ/5qfRpEw fs0a1UrSBKq16wUW5u3OZNLkFTNfl/6S92/6woum1AYWHu3w9doWky/24abj XQGEO0WpugCc0nkqzQY+a3WM0GD+59iYSi+Kr2oRTSiUiUOwjixoKXTZQbXS //lSXTUa3UYm7xk9XCSdzebf3n8MUqBGzZQjj/2K6zWqS8j+/isPIoiUD1OQ wF9vknO0xYJFwS2gh5tD8HrkwEZD7nA/w0of/MVUAyvhnIQooA2ULEQ2XN8f 7uTNa2+f0bZK/Z4m5PzR0ula3C1sSM1dkuYvM0qFNyDR2G9W0KQE5lyAkvhK AV8m4O3SZzVVDE7S4vCS6J3J/V0WRvyQvZEpmhHX0L9Rcpru2nIwLtqc0NHn uyzyW/s6N2cN2K7rhUPi0gttK5fd0EcSHS1PJSZI1uZadSl4XtBEMlHby5nj tOdCSFUL9kSDy0Azj9lKvv7SXS8l0+oLbaXSoGr+0OTtKKvx0F9K/97V4+wL E6cqRYZS+vzDrp0+wtHUcEoLmovx5Pj93urAGi2oreky/IRDP5NIE9z3tgDH iNDiFFalheD3GOHxbZBqIv4qLrBE9M2K90PQvOnVnsLH4iUsC4rFk6v8Urc1 N4l425XzEyZCt+JeROdf0/yO7UuVTMvF2Jom48pGa/VRQ0FsDjIGCeY1TTAP MIoiqNsg2v5ABURt10iKw64s6/xsb7Wl0pUMJzGk/youB0SdwbvpNJXqNuMx VW3SQiQFrtOO2+nqviZEkdAlJKzQPvKbqHW36nVckAYeke6h7uwhF5sG+uDI mc4D+0OGmwBtapHXlWhLkOmZKgSFGT2fUQFQ8gH6AaBVBfgW4a1icjH1X25T UgUAiWhJ/k3jfWltSv//0ucjPUmBLY1Jbfql2xq950ga09cezTD+sLXl5POb a1wM6Gk1qK6+mJJWiSFjLJv7Dicnm1w/RRu7lw5kMCX3j5OLm0HPTJoO0IvX BqqU1wdRJ0lKD5lbD5OQ+iTDuJtD1/7UbmzLQEYERuvhV4uQ/6SzOUbe2QfG inEBkiRCngLOD+tUtgYHmOBeAeWvthwynZ00NDGTGnY+iDSTMgIDkv7+SZtd SOcHDy4IkAe24SqxZweq9ud13xTIOPhEkpblXwow0ASzb65d8uqRovJa/86l 6mwykPEV6AJLPj0zV3Di3PWCxa7AXLLtAJQqGLjXC9UqXDQJbizr7OZaI5MS yrTfxhebXSwItjbDJsEcTSiO1Q9UWMHhWtIcBqa32oVF7Vu8w5vlZpSkzl/Q AzRtQgQrT4YiAAKYHOLiSCpmkoPp8JKbQAj7/TonQzLPQQ6i40rE6JFkAZBy mysnPXcyUsRdxZKhf8sO7tcfkCxdLAsPS2hHsugqk2gFWbeakjGS2+A72LF1 HIHlzry24U1FXj91Eujrzc28Zogut8/j6cyWPu3UQjj5giZ0swBoWzTwKis4 DG5a6azdIq7B1wmFJJLZMXT/aE91SV3VBSPVQl/xLXU4ICT8UUOEt2TMKJVi 84lYPEUykJuaQfJErhLOwgoekwkACTGERrLyVGwt7iZ0SCtD7OTNULU9t3SI KSz7w2h49PKbkMzzabG7LCdOsyUnJV7n4PBC8MnI2auBQ3XaMjCOSBJM+uUg SDD0ovd53R4aAQ8KkoOi6ZYB5Wd3ZBdgVCaKFIWGd3SGV4SGl7WlK5RRp1VU hlfF9+SwuxgZly9Hl1ZeVFYkJbz0bw3pdApKmC9ACW13KE92d3T2QPLX18fV 41P9XDHa5b514xxpVT/sXRwTyTxLtdV2dHR2H82TP8Wf4AJ0QgpJQR6KzCTR 34DTpbQ3DvX9kTrDSXV3dnZ0woDMOlzE1udqw7LP7F9DNWYEvjBFQtFBA3X4 DibuX113dnd0SS0t2tL5L8Uv59pGwsbBdSwq0g5TJ61H5aOhqnTavavD+Gx2 q7okqSDUdDgSdHfVdNR38eDwU3Z0e4dUd0zbqbv4p6bEdFd4V3aUdRltr/6X BCR2lCU8T1fXG5iOpXTUeFf0dtR1aUDo6tBDJHbrdHd3C6936lb/qsWrbUcf KYSweM/orMQDdncKe2RO31xBr0HNQ/XVipMiVrUSp0TX8alsqXZ3dHbR0SCP ye7LL1DU/w9+yZtHwx/K9SVBkrwYaP+nGotDznYW3Xef0UpAwMHY65Z3QPTO ztte39vN3HR2d3T4dUPIS61aSdlfLt6WkuXIQyMaLkBXUt/5I/nzv9UdQXZ2 dHYusVT6oMukHLGwLfxTqT6uyPGxn/yPUKbu2LSHhJ3rtcB2dnaQie1v7RAB rkJDQBcUFRWokCcwfzCYRABH6fYUdNg/ZHNw2UdG0Q3Ze3h5ZGI0jIeeyHYO d3a1wl/SjfwVwReqP7j4LCcro3VeSQs73SWnRnTmeHb0XNv7nKe/t8NAmtEP /hbvNSNDxdCQMwf6x3aWTXYhd1AP8H0T7LIDw99HJl6dpOJcMdeXIwDHk/dC vXYyhV4GokU9/bK9HUANIBd2dHaPHRO8128z+6Az316y/6rV9I0RgkjBkMIB WzjkyLV0dhIfQOd4nxu6bn8owPd0GNtFdWB+s8jbn19DTHl3eDiiKIp7TnNx YHdMutTgFHtgFnQbZhsZGBttZYqz+2xsG2xsbhFpbxEQdpF5FhZCEISJh4aJ nYd3nImLnIaInZav9nacn56dgJ+eu4GAgYCDgLeDgit2dGC5j7W0sra0t7K4 s7KNfbuMpqaOsSR2hbuxabCkp6ulpmimqKqovXtWWFq8oaGgVaCjoqNaWFVa WlUOi4ilWVavWFusyaquinYxDlCuUFLFx6HIyFvG2iautCvd3d7c3Nze3d7f 38h6JJau3sDBoKPB9cbE+flX+PhDUGgYvlrD+fL4+VDxdPCViLDoEbZD62hO 6P0qz6Iz4v/nR+tjbx6Ot+TiBumi/esMIvGWX+vo4anoMZf6PCl1uv3T/ZrU /NOXeXyx5P504ezgkuHjl+iXmD3lmpQs/pbvJ5l1CHKP6ZJDl3SYlgWb8Zua mvRKYnb57ert4+2U4u3t4uzs4pfskZaak5GTtiuIfgQFBBAGBggDA7s331F2 hog5OQ75MDMkJST5Iik9mT8+eMFmlteNjdg4CSoP0V9EGhxAQU5BZgy5dWRB cnJDi3WFgnViPv64gRGz0xhAdRF1d3AI1zTcXWh3dHR0drbXZbcB2Tb83xlE J6fS9VwrH75FEeBEAtxDIL9f3muOPXum0lEsJJmN8mIjynR0dnYlS9NU0kbb O/1zXyNSxfddSyo5MbJ0Qd2LdAxH6q1ienQadnQTIy8rcg9fA8GFRtQi2z0t spQBXHWvdx0F1IJf4vR2dNFHdVn1tR9CrA0e244ftD9CcvZJLnZ2JBKj3e4+ O5cj0SR06+4qDsBH83/w8g6n0bgMPl2ynJOo9Hx29PVJEx1jAMpTHDMsaa2l IIjTY1m9yjLBySt9GnRWKncjUSQSH4ktwy+Jp5d0dNoz8kMdM83yNN3FK5OJ 6RuivFChJjRsdEGbRYPTv5A/HQ1DRqngQEBQcjBw4/x0dHZ2q6cGarenTz/x 5hKGT6k3qhQPywESWHTmHiNroHm6rYolTXB2/QezvJukkVnPuF10tFJ1vv6I 0QxuQ/eXsIux66KmdSd1S3ZGF6JIshSKhme5j7jv6V+MpbaH8v7whgBCEWw3 BDqwUOH+lW2kXpWMpSY4dyeUJdgnlX+tGsNzLSctQMh1wACrjM5e+kN309zL D9b2XnQMPztfdDcEd9t0SwF6nyv7l4d7dHR27itBPy9F3OBy3WIPOz1RK6BL Nl1eqc86a80Hvk4oe4V22CS8kdKxrSjxHGIsPU8lMynKSHl0LBkI1kU+BNfU 6SfB1Som/PrK11F3dnZ0BUlEBeQl0ysyMSb97ZrkqUVXBKAuMjAPJy1ACwar WUiYe3Z0AiQmPS48MLEmv6wfxlRdWSS2JYMOzjucdHa2gaseiUsFP1iFK8My KSEOEcsB2Ek8pwQ/13R2lmNI8CUhn49uH0c82UIiJ7YlLhVEqM7CrbZ0thB0 8ALbyXPXopTJ0xi9LfGdAbLRSycZKiVDZQp75ApG8JOR15PA3iDyukJvnwJ0 5nPktizXHIuigEPwmkMn1SMl497dgdt3dnZ0Myt72W21AIbDIuWzMYWyHwRS gJvR4wTRxgkxQEunL5505kBE+PU8ltFfV+J8x3RcSdN2jE22roOfvFU6qNk/ iL8gSkYRkbKKTItAu24u13v5HdutWKdc0IfTLk0kN+FpwkX1WiC3JRwvnnZ0 tGcI1UQhx4PBga9ArO8ckkDjOb1yxxnFu9z0bGKOdmakLNtmVfH1bwOZpjk1 I+uB2DELj3TRduSVaBdgXsUiVyWMDMMxbwtF1RePznR2oHR8iT7p3Sn4O04q PpA9CPU4a2B/rMQW6bcdRwA/odahdfyaVV6zYyc1ltK2dKxNdkAxX40Z1Sed WsC4TzKDT5dN5lgPdUHdeHR0dsVyfuX0YKXlAmyIyDZlp38PlcZjzULHn6Mz fuIjdWljkW/mz+p1weR2JKHa9+h0AF81Gannng2fs6t3dnaQRlzkNxWE4FG9 z2OVC3XQ6yohXVyY35R1va6T69+ekSVLex+KeXZ0NNZGXXVEMYoZ3EPC878R fJWKaKf5l+AA7FLq8vgxz1QJuSyzkIY4fh7oR9lMHfR3dEDarXoLTJdCHt3k Vn0g0FKstqXwdnR29/Xaig3mFsOp4qdX5RB1QeSwY+o/CW9yCGO3elrsNNE3 u3Rbws+IYAK3l+f482n29yUz9/fgNF+lGUpzdHRoB4BalFfTMx+zLX9E91z6 LSEDaPC9rKWTdnd05j+/ifoEM3/tjG3H03MN0UbU3QwE1fYaSbI8Vmsl1clw 6e0p18Jn5IFLEUFDON510vVJXSRWy4uZbJmUdQcNpuBd8mwiDvAMTXZ2ywLy UWwfoaPxmClKob1vi9GDmf4xkbRgdHZ2dgOq73fH6r31vZvDAaBCdNPqPVCC xRPnQNklKh4Ic/WQeXRAefUfQlL/phCX3Qcf1UVr51t7wQOX/fx2vl+aRV+4 OvbyDMPB3cv/EHT0vOU+2s388N5dUMitycf9JFRUK/OXE4vU/A5/JIql1mJ3 fXp/YGB/j5eTr2FiDnUWf8vjkSQp7SmK8WopbW0RdYSHh7jrFr0+pYuJgnVZ wYh3rvRK+52Lhp30nIGDNICAnoK1tcid/Eq7j40npaTrpNIrtCBz+Ly8V2X2 rHdKxcTGh0+zycvJ2nXCafTf3/0AwSncNmIYwMA2GqeZhPvfXvj7dfggzMou 7f9S5bQ3q+VTX8h0SPjgkwUfOzt3JiRLjqLDn1Re4jjsTyxt/fX5QAL11jdD ysvYeXZ0lI/A2TbGynJE0kQqPA4rLchcPzQ4N0cnHQLKXCT2ol9GDUs6Rqgn PlHDSnl0dl6Nu8JeIorASdMs2S060tAoP8szOwPEHiYFFXcADzuPwF9fIjQf AeYESA/St/1gdLn1SQ9hfEsk1rvyRkIcs+v+LgFNd0xwYqUpiGRnZmt+ftTP YzYZddQVFRV8fBUXd0z86MgiQ3UbGhlqGBqG884BMG533d0REoXqW2bGhTCI nIR1iYiJdHYW+YgRfYi+qZ0Vi5+dh52dnZyaioGesoKIEoMrinN+iWODtYOC tLe4unsZvbi7u7t154Ftghd+4eq44rCwQ3WzoqiwoJHHWKWrsKLq9oofqhFi oqa5GeSp0d3OFvvqj3e+v6GhoKFSWqKptBsriKyiVaKHVVZXyOVaG80qslvd rKhuVKquqK64U6+trXV1r1C8rP7zioWuUXV3U8TJvhCEP3QTyVKuxlWIxrOO 2nHeYqpUw46MW5z1mrMoK1zDFPV38vdgGpUxtYPKd8+56c/g8s5w8cJZz/Pk 8VZ35f6qplHn5sHr9fqiiDSq+sDg4pXj4/5B4Epz6JZ1l5aXmZubmpHusyiK ZZCQBQsaAzUlcvQriCghd03/tT0efdsPBbJf6Kh0lyPSR+GHlQNfREHRSZtl 2KpGTRT1f0/NBzjI1pXJuYfyXnQod0OOJ0g1vVThB0c/OGF25nF0P0QiSFk8 84/hzBBSwV896UscYgGHVDYCA3Z3dC/EutNBS/fTMFNzikPDQUI09HMxpEIc kC6Zf3R0M9K9F8cjWlIg4IlNJKM90NRdfZvP1XR2dih7rinpcWmEM73SWS0O PetH8qCerg7mFRjidnZ0dIP8xPU+Of2t1VSD3a4p/EuUjbOaXPckBv14TNRj Xyw3dpp2dK8/BKsRPpL1Ps+oQzKD4QVdUxaXHd03XVYwkdJ0dPBFMPNTNKK1 QwZEjqXXJdVIn3c8Q1ADBn6ipmkqNQFSiHZ3dHcK6SSEcVRhUzalg5UfgP3Q OZnJHFuJUzTf8AsBeUo5dHavd3flIxvMthQkh1ohOowhv5B3v/8SCXXE3aMc FFA03WnlDUGI19uxd48YEkxNZGZCaU9xZ09OaXN1cnbu+pZpZGlrGWF6fG58 fGN6l3dhfn8SFmNgbWAWGGwXfxoUYRsXElwR/rjkFxFaERlBFxcTczaASnls GBgRGYZtb50GEQDakqhCXdAjeG9IZDxvk3VDExKGEppv3NejkoiLhtdjSqK7 +p2DnJ9Ct5yBdbie7WJkVnZ0tJ6BuoGDdIJltraCVbfmsbeRDk67uWyOSnCP qIrmYJvkdI+Oq06Pj46+XbC9m6h3G0K+ebCjs6WgcoG6pxdwqX9nVaS9WX+q q6BVVK8Th7pulpx0pr5Sp6j4OqWn3ZR0yK+xy1J5HzjBNsGZw/f2+PcRrYlO dPhXXPv4QmYCj3a/+vD6+70fzvN0e4uGr///zozi4qXil+O6mJut7JvgTbOQ BQbnBB31qefn62UcHqgcwnQBH/YBAQF3FubmXwJTqQB3Azm+Aju+NQ+jNTXe ToR3WjQMpTcPpDcOojQOvDY2NjGVNkBxt2WPdTs2MKs7gYoMOg3xcAzvww9K dFt2Gw10DiauMSiQMTAwMDPrMgb0Mw3oJCp8d3R3hCYnJyg35yk36ikrECg/ Biom8z4MwDwxhD4/XGS3bvQjhSM77SIjv7XdLy++LkRT0XV3d9o0RPDSLOlL NYZaMa1CBKp3SLor1e2PE4O0dI8tUXSHkFzTI1/TS631X3L3ynZ09EAqRyzX NMJi90JCtB8KMl8o5oWg1Hd0d3bjf0jaKCqeP2ItYgKrmI7neotAKhG/S5Xv Q1909REhC3d0dnZXk4UlIYtF3lgpNVOqbmHc2TjcmSQb9PM82ge9B3rldnR0 LgKeqQEtq98vZNxuKu5ZI1jFAFoDENPRaUd9YBF2dHReBKIA3n8dTVUSg0fY DENsp5Sin0nX8HMfRHR0drbLUaELUdcfwRn6htA5O+yr5WJV8srQPQVZDWR1 yT93uuRO2V3NkbxUckkmx7zz44kj2y49QaqpeXd0FDSAxA79GrldsiDHPyIl ozCUQp6dxNXG/Hh3dCAEAr6ErSjFdFza0fz6VDQXdghBKtLp5SHHQej4bmqh CLD+i4u2d3R3tfMaXOcbiSolQr3pxDac9VQFvVzLBfXiDnZ0dwNarhS5ZEtY /BzXge4fgBX2JW3Uh3NSYrf0uHd2dyW9IMtLAqd8wJADNq5xryL+wiRrowqp 3tP0ddhYvvy6pUOj3PnklwnQEe8BStR6+yxk1RsHJ/79/0tVddghYeFRdO01 WmGVkxYi+bIk5+I9JvL0kNY1uzODJ+q8XPtlS/3w6AzzDL2RCPXndCLrSrhL nvL61NYuiI7Od+MIQ0Y+XLFuGGp04HRcXvgjcnjaq9v58c/hdPLK8HdXciqa RufHjgF2Xk4r1z4kJeE6deOta52BSztD1x4GPQOYXe/3SAcYBuAMT/GM5JDg NM7uHc7pQqMGkuH68ozKRufzXkIf/pXSkkIbqbA0dT6+H+WmkRix0Zgw72le zuQIZrYWfZssMh/8BSckKSLlaGE9HlfAQw3XHBgX0N+S4ywyJyUx1T2Qac3b G3WxOtYDbQ0+AG994XW3dSnxMkTv+ERIBy9Io1P4ZhqQnwcGkJFF0bJupv3+ bNUD+PrrAMPlDu93A5KE4YuKqBmE89cadNDoBFTvc2vCMpTo1cvXHmZdgH71 GD4BFP08fPV+Aez6kV1b6LnpSuwuR8ppsL/825oF4OJf1VlauDJTjjHqHm/a TgSYEkSn1pEIPsnM8r9949IH/oL00r2WoiSQ0sXVAEPaKrnwv/bVTwGpVXci WZYb+cmwkAInSwQKDDkmomKXjjnQOUFe6cFN4vn68pU4IyQ2zjY+8NI3IXGk 5aJ75zjXdNc54zlBmMrrfjkmXPxe0+V02P7eNjs2PhgbcWwmkuSU1/3H4SnZ JD4H9Uk3Zr/DsUffdY0bhep80cH90uOHJohtJpN2RePK1Dxmzz1HcNhF6v7V 77z9HrRO5cFoJnk5AQaTBqwJAJHsBx7m6Cm70eiQrCQz6Cj1dG7P8CMA2xwE BzjX1TTO+uIo0b1QQgjaHQQDKWvkjB7ZVjkHchoJB+6R1wOBuxR5ku4DCBws 1ZE0Ce5JkDHVIetoQ4UNKdU94cBdcWHRPQk0BkiKPwbNWAckrl6PEPgUkV9F 8/MCztc1h5jhd7Dt8AhaJmRFDW4+1d3MJRHDXLpqziZAMycxmksa5bYOO15L JCJexP8Z5VzH1Sz+6TZtP1ObwJYGgjaO9eXuQ5s2JTnJVz4oAmrDaScPM+SU sOSlcSyHdz7qOgMakyH+QflCa6coJPiY94sJ54DzVTeXhf+6MYtAyPHNCwcP XVZeH5nXdEf7xsdMOYJsOXUx08N/XF8LwvzxtjHKhABtXF4sdbECZta8baf+ GvSiNBk4IB931PpLJ7bLnpV3ASI5AzwxuGaiIsy1NyQulzm3HAYNYAo6dfos JF3aK3HsXd93UMtro+sJ1+it7KU0E1abqa/JNSfdGFqmdkW505gzuCY+Pgng 35ENDA1fnu6dLe8WkqUlP1rOnC+fPwQHAZMc5yz9t+4eiqYkN0P3CRVi0Eul 7kfQL39YzOoFTr4VbyX9FCYGCcjayUubH+bQzTichpdPXg6U1+H85HpXmEvw BiRBJvGj9iZ1ZpBf165JUPTvwrb8TMVdy0zNuiaVCS/3SaEJO/BICsZcwgbq tu5vWiBQODKAQ2L8V3BeQxmSjNVAhThLqTtkQAoJIpVAyELpID04ShoUnP+D Pkf4dSe/0dCX4nxc+KXUku5rSiUnDC5s8KR0JdxGDikfZ5raTEEkMw3yPOAI c3Y0ShVIHDTPNQGXMTy0zIFerRUqunR0dnaVeDbzAUBOgf+cPeMuwXOnUvYg nB2Y2svXEqa35Rl0nHR0dnYkmS+WtVsFDNwRAvcbomAWcSrV6tsmXN1gFlXw 8HEhlXR2dnSHTzIHpCDvpUIakH00qvTTst3aHzBrxQmDmPw/Bw99qXR2dnRD qH59w5ujpaclqnVn5Nv2bKuLgRUeeXwGRr5A/ICoV3TnZHYbZ+hzCpcGLPSV V9ANuKQ6IPntwHCVFZB0dnZ0SJDD4bRNBePLdeTnKAnIs7aN1llPDff0EzRY H/boZrx0dnZ0ZXBSDhFdXdaxFtpDSqcdgr2y5qykiTBKYHffbB9WoGi0FHZ0 xyzR8rtib+wukZvDfUggg9r+dEDi6I+zkQjJ0OdUBwAeQ3qDIy0Ujit3QrXM RqJTLPYnJSLCkoOFRcAGr5XoM97C/wILfRndQ8Z/zBKewS4hRyr5Ud1Fsjzk qgKOhjSqqAPxLokZ6sfQBNe0kKgXXMAjtgLurYfcUhyPXCe6d9hf0RDr+M8f NTkBArDSoTIOMVpvcbh2kzLVJTB8AAeuBDswTy2+OwiGBjQcCQ34Yj7wMkQ8 lh8ACQS/6nr/lUYz7J0AMmWiINAA/eMFw8BhtZKNY+qTLxNTtmX6MMATMwhM QyW3QFdbyc0IEjEG8P8fPUVfrb/8KSJNaxeFtf2tofqxW8P556H6W6GUHQ8o IQgSma0vXSdPaW23MAYSMI2/V8HzEjEIEuGZCzghof0nCNNBJntxa62/+q1g GYeAubP8W6H8qaNT3fWh/Fu/zOuX7QXYlMhaHzk5ObhaSCczEjEGEkIlI9fZ 0T/pWwhIKXtlYSsmb0cAwanElwxqfqs6JxVCb8gpKZ3AEjAW5KMpu0CpWyrd dK0sHfMp/Zn7cHZ0OKTtUSdczCuUR2eNBVqsLIHmXsZzdHR25k4OoON8oq7h WSXdGkahjxvK13wRF99qE64qCbF3dHZ2Wrb7pfleJo9+wta3xONHjtZz16Tr H+SMcBc0ucH2E2p0dnZ022pjGOYCsBNxnMATwJGv6dC3v+rh+0yVdmmc4csG m3J2drRk02rpQYA2RkpOSF/Gn9fnOplF+gtgMpcR8+R2dHZ2/FWEYUA7HxFD C3bASBPqsEugTb2OMOitpTJvnLoYN0x0di57uatj6W+SmRYAhEYRG+w2gqqr JWohCncZdHR2dgL3BWyf0ZKFtrFzs9Igg7LvrFG7hka+to9Wj3U9Xd9AdHZ3 dJalakmBIHxKotz75iRECP3vqtaStDkm4bHFMhvxQeQYd3d2dnK71BOvOkUQ ZtrApOLWsI9foWC2VjIRjX9SnF7NM0x0dMG6BL9cry2vRhS6Rv32JjbpXK6O q3QBwMR0meBhcwToDOjZdnYsTW8k4MAHEmVorkHo+KB02LJzXPXugURwgXR2 d3Rsp/4FfI9FfY23yvvdjHgU2BjjGihq0HL5EMvgCRN77Xa2pWWUogaJKzup u6IVJbgTNL4UHW+ub3Z0dOaUg4KhenNvEP19+gJ7auczAd/8poePlRvyKUMD vU12dn7YQzCWC0urnPhIGDniQAerNHI8R3bGdK5nwddJmiCw/e6z3ubqEf+M V2GUiUd0dnZ2SheZr5pqPNKth6exvW6eLjaw7PRGsSk7mbiOpumNt9d0dHZ2 wI1ojrK2W0kVsUCtgqLzDBxufafOhVYuIRpBwC4b8tOmdnZ0SuJgwTrjUTf6 6Ei9m/3NSIZJYVZ2XFA8pvGodHR2pFde+AFQRmcToFze/3Ny2XmDX/yY7ONO io10dih59eIx6yp8QcbP2BN5FSgS3Jv7bUeJCxj+dHR2duQUjExMZLfJAreM LhHHp5d9oBER91CEVIGDbw+TcxYGdHR2dmL8uoT87LuhFl+wNggPpR8bKEhv Cdhdpk8LQjGV+0M0dHR2doBklxbuFP6/ZMfpJMq3/AHJsJSK28Dhu1UT5iAP Y/8FdJR/dq7MS4tAHEq6ii919z9ekLk4u4A/SLalxXR0dnabsSpD67CbvnRs tSSEhbDKV2or2KcXmqeD4Vohc+BrW3R0dnag6/BdUOZ1vF9aWzYPR2rA/Fzl 0ux1QPULtFDT+40VqXR0dnYoovoP2I9LWscTxUi3bmCOZBn71BQYShMTEME1 YxFkT7SFdnawFv/pwBvWiC+39Jo/inEUzKXdHowtYe0Bcnba9uX9RnSLOkHh mXQOebTGdln+xPyp400SduiSg+svzRVdVWeFSGxx9qp0kcJDB4OyQwqUJrxM 0ZeHBhz8HBh0dnckijkL64SpG5tvbOFIFDdkOG8OkKe7vIBXuBn2hHR2d3Sl Hnp0sCfbc7a43YO7nSRQspK/oLMjQA+FjVJfbIg97HZ2dHQZk7T8bCIn++Gy jQuUg0PY/5hRKOY9DLdKs1LHS4LYFFc0AHlA7cZkdShOMoxeR+MXcBR7hIdV MkJ4F2VVwj7/anTtZ+SDSdsLSXNpMw8SVdNNLE4hd9oqcg7OtTRQK2gO0u53 WlLj/v7859Xn/uVD3ZHJXRErk5L1wKD/fhLaX0lX4uBIMwC5xd0sFO/HOIIL A0b7Ii8KKwIXZIsiPQU5d/LO/4txQkeZS6Io515q976J50FeODQcBRunkdgo BS9K4v4AnVxCSCY6kZhFSGVE9Xfo1MI9k+cCIjRZg86jmyCyXh8y0pipY+qv 6z5KXfz1/Z9gXp6b+KjdRL0WXuTg2/LD6EIiu0j/e5tSHlaI5PmIHU+bNW96 N9JGZ16GQZHyu3iYVZMU5yP9kl3wgY/POsvLcfAC5btBEGWqPuL8mvOd6JbW 8j3g/PJjjZLiJvtb5XZqceK66g0i5eF8/+bmJilebHXNunQ485uOcUfjC+FL opXAyn0P/OY88+XY4sil+dcY1eBA8Icxtfli/0nV52ZQGIfrVjLpNM7nC9Yq 81738TGkS9tSL7ol4fA0LNnhwWh4XS0n9R3M4H5uk/AyavGR8QWQXOuMhPPS d97Ij2ctLaBFlBJ27m5JZOcyUPvgCOH9KdGKyzuJu+DABac54R7+gzIqgJh4 AB7VaR263iPp5kyoBuntO2HWonLOAN+LC+dw/IAkoz4Rk8bxu37BI9qbzDfh id+GB/WP42fj6dQKFUlJRPBe2WrrT/4i8POR7dRWM1kbIbCwn/KSYQhL4ACH p4oDwJny7JdSm9iSgNSxLPbV2I0sSxfb1jIJtgYFV9UtY9UcCQYygd+69ogX rFk1IpL94ZoAwfV3NXCTMwahfBf/ADY47OyM1Rttt/yXf2xsgtLX1w/l2Alq sr/ToUDKa+/LJ8sFdTqd8twFs+PXpewYASfcl+gtNzXRu6GoWQaVRtVhzNXJ KDLTlU8wHn1FRifathQjIuFmWIXfWTUOViIUnypw39G3pvzSniotMSwPHAuI TrTi1yi+0urUnhzzrBVCzjk7AwU63Pw8PQYIlLY3UbxjlVzQzZUgMPpBIZTm XhgDdK0g/QiK+GuOqwGRehTgt5b/ceIwCKVkMOAckQwPLHl2dYkIzTLP5ODN 8A4lBwMOHKgikBp0jI7v0+PNC07q7Ooz6+4wlQznHf62+j+aVnoLlTEC7/tU oNkdqlh+KCa/F/4efTkUoB0DAbW37S05s/SQbhAZ4T4B6QpMd45849QxMQ6y KndZndfWkdld0TPdKM8gOrtC4xPbuXcCBgHq7kt60xkfkAYI8e9LYJXnB5PT QUVJPQmGMDPuS70qjt460jgyA4POCnRaQ6WUtHY/i+iQaGEuBg3S6maAFphe ADQB4UHzMw3vX+GGLeQKOofbQQfWZVtGyi4vhEit3uG0hjDVIkKjUUNCLyuE ViclSzvVyhwIHiaNRbEqKT/MOCjP1TS3d2AjLtIjXC7zkFXmX1B31nfYXcdD rXWuU9XXt1gQDa7Gfc5Yfk3kOlnrjF7EOb0ev1C1m6jybOP/kW7R67EcqS0M sSxU1v2wPTvlEqlBgKWnSHZVfO0D4kDwXRFIYZFtDTFeRRkpdBSuDONJMQP/ zci+vLRDggT/1DZtwyQ15CiSJ5LfPMFqm1fmQ47Df5w74jDwgFUQRCvUOHdV ySh2N7ZEA//i5SUnDicFQtX9TQWgDykzJKzKg0vvYzMuzlKxUkOoSJtdwHUR N/KbkzXRds4nVx6ldjDsk7MH70qTMP4W22i+kc0BmwjtSit1k3FC4fdV5gQy 70YDVLaVOSKmsV6ZPvIBuSAOmSECRdQIPkrlckDF1SrFdUJB2OPVKkDikknP 4yMAQUJeM53Xw11dXZ3Vw0tLSUm2lbqid1v4R0SVTHSuQlxcQV1eSENIQEh1 SXJEo/c9QgevK1TvYvLwCnTXQEY0XMTHQvq3GPYdDyf/10SchkxjQPndDb8i 0PsIEjEWN/NA/ZsIOSutCBAz20t1NHN8+q2h/BkRn7irofqtoVVR3MzrraH6 W5sENSfX0zEG8v1BOU9/GYkSMAgStbOjrd0JEzAIzOmYBzQxJggTMTzX0F05 e/1bvvxkF4SBsKH9W76grMv06aqh/a2UkRw7KNkwiaH8REE4T2gXEzEJEhCd jKhUCBMxCVPcz+iZCDMJEDA3MD3YR/1bfoVAOExrFBG+/Kq/iLewvVStvvqt U9/55ePs6aqh/R04K9hJ6rmERipqWwk1/CYe7ABb9lXeOx/MA+4wIklHE4MO sAAylwbvR5GTE6h4lvJ+SEsd7ygr2JsXjkQBAxQFRu8xccT2TjEkSgGRkAI1 7A0OCGNsY0eRA5IlJgdLDQ86yIhtDV7NKZLflCZJ8QAFDJIHv8RIeunKigLQ AAKR7yxpC7EwBQ9dBRtL8FZopSIyipM0AR5+S+bPK9PwKpEAL7I7iYkb7gwU Lkt8BOprvTnMkx/vBwNaoh1MSn6P7T5HAiKdK9EplRsP70qYS0O0Rm0ARgMJ SF3TNuxcqmgHkJDtGzzNQycH7gMGkAQc3wNI6nrFAAnXGjyVj5QIlQk+0ZAJ SCOGIY30kksyJfeyFqfRSgmQL0oyB6IC8po+2109grJmGs8JBQGLCAYETe7J jkjh/TVAIAkuC4Kw/XgzLgYCCgEE9SLGvJVK3gILdRxKGcF2R+0AJxwBNAAb wiC40AeCBQdVRgr/nBtTMA4q/kJOQZHRKEYqNcLwsMEIzAXiSpINHCn+xJEx MSw0Bwcvhu0Lv2kBB6TzLxqlk0ooS3eTFJLG1RyTkJYBJsPrbNirJTIoM/hG RMeObEbaNB4HUTEdqP0xCkRGs67DDN9LGgAGHv5ahbAjaud7lDVKYwjobAN9 uQcABTKE8SRsRklINO8/6rKMq1faRkgumz5aJlSQfEbbMpCN4ENhAR2TWBw1 xaWxBBEcV0ZRJg3yEJW8A++zLANrRhzzedkuRjIaKAcPBVyhj2taLEoGNNVK 66r8lASUNwgUxcNIOAeTChZv1Lc+SB4CkwUIHgwfEf9dipOeMGEGTm+OB6RE B5HvA+waSxFosZkaJh8HC5ZNSG/B9UOWu5YtlZr3q5QUCUZXBEjYjhdjC5FR Cdl1/NN0m8b11PLt6SmS0EbFB5IcRPWRJlUuSXXFI1TiYF2HdJbVOHe1dS0F /HeVpskAAShXXc0rrIbmSkjiJgNf2e71dkkz94f4hPIkRUsr93S5QUf5MV5A x1L2Rl1PD9EH3Z/u4QbIeuopNZQy4zzhpCsR1wUMbNj9NKSymeNaSbo16Fos 1fFEKQzizjzkX8/p4dnaJiV1SKLh8qESSOhvkdsiLtGAMd4mUndLE3dL56Jh tzYCNB1m+gUzN/9NM7O2BwgJRZUcMQ0x4jOdYVxeMjGgmOqmQIe8Jp9fPKXv shg+JzbyPK4uLqm81iISmD1yIqJrwm3otQ2ADvD7KECMCF/C3NcKJQ4YbeM0 pHULHg1GRUa38pr6OQ5C5LsGscOkdexL5vxbzBgxdfYQ5MrGlObO8qH8jek7 UiZCJfPMfLf+rc36A7LjQOoIEg7HQ/JE4eHnHvWrOOlTJgEtRpfa80JbQ8tI XfytYYVDdQFPZ30Xvv2tv22Hn7ePQcj9rae9VQ/JQugBDv7yLP71FdP21MhU niqD5RFe0COX8L8MRtbw39ySQzjwXjKz1YeHFubUAA85ngvQnJI2lOMn1Kj/ pDVtX8OWCaNlMIuQCZgzJwhIW3UiJucn1pJp2zZFkgcDBgc4BggBReBAAQcb XggqymOJfiwACAmRNTUBLITTJespt/XRpzjQARzOXZnDdQhcdV5fDUyWNPEN t4y8fpYJ/+Y3NbD/lH21SB/jjoURLTEYI4Lh8cqnPWR6lpzik44TAEZqLV+Q ddyFHh6OD0fg6sVCo2/lrXI76Rh6R6bhSMuYSyNCf2AUJ65CRzxV3tA3A0R0 91GvVaC9eRJOQHSLrTrzI5J7bb0b1cqTB/mBIw1dKzIDR+nYUqj2MsEFXzI0 ekRa1xwD1T3pbbvP08PIPHIBdSvlzYAZnS2Q2HJC1mpLLyHumrAQ7A8rZZTV 0n3VLbMY5WYdOl8HpNyqNNQnb6INGCgv6YQ8bQDB724V+5T44wOPFA087wHi o/UUgziF214KpTWTIBzvNfJdQrfhVD/RsZlhxwUDTT862jRIRtztyMdBLZDY qNvmVZFq5VPXU66dAOGsN1XhM7nWnYx5RD7dpBnXaObBKvDCKwA4Us+lHLGx Is+pIdcgpS7orsyTEsLpbUAZmSvxMbWEVFdlmXdf6i7L5cbFqBB5ti3rGC8E z1z/KpLB3Qeh1zQefOwRL19ErrESQzIinSKOykpOVRfsdeuF4PjxBPlMGh5e lD87uwylpenw9NpeYaY48zfx/wWzoJIDB6xrZkZEXu8zDtFKIIA1KChv1x7d rm1a5ZDX5YRJuE1V2uHmyvqL553RiQDkmPxANZ4nWyTYkqfheSEaOQbvHhiJ BLStBsItLQK0SSH02hY4Cd813LmLYsz3l9MGeiifPfOUidBQ7k9PXe6a0s4g it6s0+j46NQI+AVHjSQjrZctdaofQFDqGkhnyaggDpHzeZJYqyO790sb1RCv oiVlCe5I4sKok+mabFGT+hOVAAHW4UNr7N1T0QhIBd6HDsHMwXVaNd4BJx/4 7J9477UqLWYg2uUylhrzgDui+lp1fl3Ty4p71Zt0WiO66PPn9kVR9d1CmAA0 BYECm3kWLwV1d3If/Ojgk/rm5gu7RvB0oUctHuHxP5UCBxeea0dVdjTQaDnu Mnkc5+HmRZIgyT3d4gmU0py/V810A8784B2g95JPlObh6wO3wncCJJByZ18F 0agBz9LE1T/hBX6VJJX+JTLOlUcWMks/TB7P2OltYZhK5pKS6wjE3N/w1XcC SdqZZHVS5bCRMCWS57DRqXaU5PD/5/Es99MV32MosSjxMHzg6gOUOm9Avg4G 8EL+AMGxUCjzgAbnqy/LI91+MRxJLhKWLHIylOEL/OPllNYB3ZIv6/wo0UHe I3wVQwIpSkSTNSLzxUg0ZzSvYeIB08xOmUH7DpMD/ungSPgm7EnattldP45o TWvOmhxH0ZizN9E9+uekIYvX5OfMKejFpgjfp0pwHwyPiY6O/Ev8zf6LXC+Q rUT1KCKbHuBrCI7mjC68R+6VKAH1kFlJN9Ma/O8GLh0C0JzTnWgGgSnRdJH/ QeHvQDUa5ZDp50HpgbJqX0IyWuIj/EqifIlBWQUkii9fD4n4XJK+BGO1lJWK hwoOEEqn0SuZJP3kzOkxsQ4xNvNCEmrydHGWrFHy6E+TGtGLHj5F1PGbyoew A6XkRpu8JvPqAo9rC7hc7jf+qNGbKrsgMQOa2a82LvXr0OlAMdj1FHjaNBLw iNsL4Geup0DP3wHn59Fpa5YPkOd35JH8/s4H//EJR5yNICs+LeTcAwVLHLaT pCqLD6+0SkmOOonvIoV0MJHwZRZ85gii/yEK/sxUSQTq7eqO8NvK76pBRD6I AR2vR8skkz1VJVgWPwTpsbF8yx8ZdjRJWGme8khFDdVGMCstF1wkteVXCS1d Vv9hOJTn0KPy3g6iXZFfliyqZm62+uLn516X6JKU4zFeksxJsW21S34m/uGh J1z624gnml7/X2h3BjrtdTQ3IjTsNQc17R006ghjiYSZcl5N2Jf+8OJPnxjR Q+gO1uGl756P8amrk/zR8srP2ehD0GOU/O7iMsZyAIRF4iL/5JgbuXnE5JYc 5ubjlJU5HJfRG5jnHBLo2DKk4191rWIkgjHwqfu081fzC0lBweYlT8/hzMxf KOHI5rQ5/kAF4Ial4P98rqdf2vDqQefPtUdhLdQh4TjC5f5tbMZv9nrR5vzE 6Zf6GNhhJPQjgeaNSAk1HoB1lpiU+OnqqeTfAveCXl8/6Skx521s+88jAnCF ZK4F8Ocy7+QNGuRe6e8Az8zf6R9/GV/SOvLktBOGv3xa5pfRgD04GKOCQ5MA 6CrC4wdXjiqJQnQ+8mM6WAThnv0kX2Qk1NnuNAE17+RDnwunMe+2LOkA5uj6 uW77BzcvPeX+PnLVn5Ha6yFurXQ2ShtAM1xDA4fFYmstrdZUBwUF8QhTkhyw g081Mf8a7jMnL8OKP8Ivznws0UPjlQsnrzIU5UMxNoHyKiyTwx0Duj0FDbgx BCT6KU/0X6snRpe0lVoDUpJ+1IZP9Dy+JPO9e/VR4GoPdjND00Xm5+pR4OpA SzJfRODsr/7wXdNBDFH+6q7yLlp1SC6pUeDsSUfSC3X3TAL3ZzZy7kA810lF QUhe0UFcXgZxdHRJQV1dX0dc0AUPX19FR0FeWkZB211nml1cXWoZQl7Zcj92 d/T/PnI6Ly5JL9GFXyRe1yVfSVZCR0hJLVxFSRtmjrBaKRzbD9ZBDSNFM9gW F3l2XJFeol5LQS3GS0tBX1pKd11cSCJcXV1J5OTp6lwsRlwlWizTSUst1XZP G2jQR0g1REgu00jbR0g9R9tJXEIaToymm1BBIkFeXi8uJzZaQw7kmPOOS7Fd S9HxJCPZ0ypBeuQmGtJfS9IPil3OQSPa4vfQX1wKpuho5l4IIdIsRerQLrOx jvPoYIbXJtccO1+bIuQasRaCXtDULeRKB9QfDzReenF0ZCxICa4tPdJaKg7U Xl8pL9HZ2dD/XHfQn5t3i3Ve1BblgrY0XkIhD8wvSgteljGS1y09RlwUdsB0 KixEXNHUSyFdHEQDRgBd2AyjLVo70nHkls9LRCFKJCk8QDEvwmcxclwyRGXm qIxyDUKERl3RQMlLLRgUbbb6lzxELlwkIrl9XSjTJgBLoSuUKntmPT7V414i 1dJfSJSdXSow66n2LA8kL6V3iFzTHnu2sKjJS0RfS9Im+wFcHSvZX9BKZ3Tx KsBo1DA22B8y7EQ8NzzZ6NisaTVU7e6HR0t1X2XUUPvWLl9HSwheXjxM9fvR QFw0Xl1B2WWr5hlAqCfQXkoGeZffDi/X51ytklzZDEpndybL10fTLT1JOTGa 29AiQSBJRyBkSxqeLiXzXb4EevhERjoquOIUGShH0EonJiF1XyaZNC1y5xV0 6eJFKUsjBxrrBCwhIB0e1Tx7q7a2atc6DPI/Ojw6kl5H2z0Drxo//+3SQl7Q 0XmDu+w+1gIuBi9uKbBIts43RdLWJjcu2nVqSzz2YA7RUSLwQANa2dpaSEhG RUZEJtN3SrVJLEnX0QpJ6nu/LUlEgCbweQEqMjrr7A1dLUE/XtNLV2ef9h7a WCUfSkJI217S18MsVyeb6Hm34yMvXNEoXEkwDgBclmZi96IwDq2U0IEGXV8u XUURmSjoSV8ual1AQLT98y9ddaYvs3qPhLErL0Qv/dGLSkadHaCGpUtHePZE mbr3e66v1tVe20aXLz3YRSlyMCpn1XKlyO5NHkiqr7peWvYDfuQ3Xz1Fp0cl 10lFZoJ0bt4/OS1K6gRfKV/KX4rwSUOwsxYbR6+T81jzXvAoAdcysRzgpmis Q9cbXNZu/w9s+Y8E15Aii6jtn+JP0S/N8NHa6eDn9tnNmB1H/vVG2UDdm72O S6gnpUvQLdUMkpZfQWvOUqR9PeM4ffYsRPnOHXMcdiNGXknTQV9cSdaicDQN 1zVC0NoJLUXbR94B6Oox+0nbRtfTKLTUSzqPFwtKuNgxMkkxK/u8XwO4hcKE 6XXnG9QhHrgH/fbRRy4jmiQwrQYs0S5olScrr0BEmQK2KiR40TX4L0Y59zpE KS4t9BKysUgN0SyM0Cu7M9kz0D9H/O54SJ7Y/C061dDEyCjYUTpxFAMk0Erb RdbQQkhc04ltpbHvvMZd7wQqmjNuS4p1b0ZC4FOxbFpDR7FL0O36mBcF69Y+ 4rJfNV71IpqqMK+ESh7YXOiBz3zPesEAXu8TKy2pIdomKS/fKfYrK9Pw7V3u xQIf19NHIbgajmQiNkI+zTooXEMNUSk7E6HImozEJisECRBE4C1omOfyKtLy STFYpDeKDpSbmUyRF23xuJAvRyVKSAZMLpwuDCAqluWMm8EPLtlCN0oHSz7x mLroP0XJRy80Xts92QL/G/LGuUTRrT6q+CxZnkrQ6iAvGSxG7RqnhFsZ2fpL GUAgIvhvlE9eL9uDXDNAOy8CXB5c2Ljq+KL5rT7iXNaHXgJfRHe+drX2Kdft 0dhRqlzwJD/T51g+1DUDH3Z3yCShMdM/CeWVHekIqdAdCfwdC51MC2lx1w8P vC5dd1dfRXqocN9wJ0TSwtw12kHTQNC6QMX24VlRVRzpqAE/C/QoOyMlS9NS N2jlkqhVNTbTvklzlZi6sV0zYZkPXGNcXWDAcQ6zRyqeXOFaeaJnmnRT0TFL 96oyFKBcHnfp0/+ILknZ/ypAjugmrBdDKdmaXy512tHPe61iLzIYXCYh7swr sz1KGX/8D2bz6tW7R1zAk1Qrm14pTArtb7GwXzxL2bxKLJQq7Yv27uRKQUZF XUjRL19eRsYrB/3QEqPFmERI0Mg1+3PEzYzvb5sDdEto0lqKsJFURz3hckr1 WpyzRczZxHPg25G0EF25T46kR6iFvnHw2JjrHgEi/T+xcMP01+pg0dcPNdy1 PbCfwHFHIzU8slHalpibI/hBXu1eRUe3DmyHK0/AXJ/r11raXBOBbpv/Ydrq +7hC6Q4PLcgaQ+3VqSPVmbRwmspGIUpFMnTo5duY3m+qVgEvWjIlMxJtm0ZG 9lr6p4SX/TNcQg+Q1i+VV3iP0zO5LyhJIz3aC9JJ26msQYML1dNLvs/XLdYB XuFc6PCi6IpBCSEkBNtEfiSx/wj5clM3qriZkF3qXnWpa/w16MZaqkuV9BNU xW1LR2bR2kKY1HC3zduMP1PSF649mlv4/QdqXT54wVNE2uqyd9aZ7u41Og8d HzUA2yhN1uB4wvbqXAxIPNYl2BxaPG1CiDN5T/SZXjcjPF4G0yMIxxpELT5H IS0YS+ZIEBoX2yF6KdNmpum4qwE/Bv8udOs9JtktHnioSofTlo7aRCA45JRP qCULX/7hXOCsMiPYLmdc7l4XVTT04ILvvSNEqPZALBkB/0khSS1eBFwjJUky N9fRSvTACke1Q9WWJ+Rbx+2gLG2PeEdtIKUQVbGFP/tBHj9XC2BA1zbo5sJx 4T8u2CwudvxAK3h6mDIu/zo8ICVjSAwzL6pDmmjYdts72WcsctvFXbgOXBhe 2Pqq5JghiQrSQi8O03c9llZUBZLZj4DYSNksSTBdasqLgdk+weaY2i5sEDNy IGctcojP6CAdI3DQ2dHzpm7/+OiFB20hXpg8StvlbZaUpgF1NdXSIww7R4/m IY9eC2Jv9vILvg8jRdXZ220YdU52dHT2BWVAdN7Q1CEQZQZ07mV1dDKGJpYf LEhfKAHoCARcSy8/UShJi3qaSo5ehUWy9tjEPL51oeQ3XDctDdl1SuA4hF3h Klv+RfTt1oibxO4/2AoU2tDn8kpBPYtFI9DUyo+BNR7gPCjuvixktMV8duAs o0alZ0x1J0FnSdnX2C3VbcG+Gj8ta0koBEZ/MSh/8eopGS4zX/4ZT0khO/+o MCa6SLFI4OTqTbFnEaM3LpPY7j/bLw1dLwf9Z5EzLSVF1TTToJElJm8u6TjT McApY+U8JG5H2D+x4f/INWRecpI2WhvoonNl3XRfx9S+D9krb+rojB/BQ89D +z7tG7HTAmzT2Lsq6bQOeZlEkQYu7R0zhSX/IF8yKw6pi3eOIHLtQF9l1nRl JHQfQ3WA5xrFKku0zEYu2OlfmsiTsaF511gBD/v6RdaoImczM11Dk2srJw8t X3TtmCgtGxpFQ/KlO9dO5+rAQceddUtGZYPZQXXfxNR0ZzksQ5zSTatnk83m b0vVUrcCSYfTLo1+lqNGRWfcci9100N6daV3ZQFc0VTR0XB0Ww5Bd4Z4ALRh W3s5ckt1QXV19UEiNgBeDu8/cpV4UTuucjV3RxdedXVH+kB4rkhHXl91eTdl Jh38dHfJdaRfd2s8dV1tqDW8fXUAVwvaMYAfct7T0HNqRQ5AiF84fNN611zb SNQeMNMXW8Whajz0F/e1bbTfS2BdJxjfXfuPByd1uBjonX6H2rnrNs9tINlr dXV3t1x1d9dydXZ3dXV3d3V1d3d1EVk/YL4A8EYAjb4AIPn/V4PN/+l6AQAA kJCQigZGiAdHAdt1B4seg+78Edty7bgBAAAAAdt1B4seg+78EdsRwAHbc+91 CYseg+78Edtz5DHJg+gDcg3B4AiKBkaD8P90dInFAdt1B4seg+78EdsRyQHb dQeLHoPu/BHbEcl1IEEB23UHix6D7vwR2xHJAdtz73UJix6D7vwR23Pkg8EC gf0A8///g9EBjRQvg/38dg+KAkKIB0dJdffpY////5CLAoPCBIkHg8cEg+kE d/EBz+lM////Xon3uSsEAACKB0cs6DwBd/eAPwt18osHil8EZsHoCMHAEIbE KfiA6+gB8IkHg8cFidji2Y2+ANAHAIsHCcB0RYtfBI2EMAAACAAB81CDxwj/ lowACACVigdHCMB03In5eQcPtwdHUEe5V0jyrlX/lpAACAAJwHQHiQODwwTr 2P+WlAAIAIPHBI1e/DHAigdHCcB0IjzvdxEBw4sDhsTBwBCGxAHwiQPr4iQP weAQZosHg8cC6+Jh6aol+f8AINJ1ALkcEQEAPGN1ACwAgTQO0U0304ftIO3B BA4IPDKL0oTfgQQOcLSbknIAdwA56uLadwDpWf7//1X+//8A6U/+//////// zCDbCe2Iyek//v//AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAMQQCACMEAgAAAAAAAAAAAAAAAAA0RAIAJwQCAAAAAAAAAAAAAAA AADeEAgApBAIAAAAAAAAAAAAAAAAAOYQCACsEAgAAAAAAAAAAAAAAAAA8RAI ALQQCAAAAAAAAAAAAAAAAAD8EAgAvBAIAAAAAAAAAAAAAAAAAAAAAAAAAAAA CBEIABYRCAAmEQgAAAAAADQRCAAAAAAAQhEIAAAAAABSEQgAAAAAAFgRCAAA AAAAAQAAgAAAAABLRVJORUwzMi5ETEwAQURWQVBJMzIuZGxsAE1QUi5kbGwA TVNWQ1JULmRsbABVU0VSMzIuZGxsAFdTT0NLMzIuZGxsAAAATG9hZExpYnJh cnlBAABHZXRQcm9jQWRkcmVzcwAARXhpdFByb2Nlc3MAAABSZWdDbG9zZUtl eQAAAFdOZXRPcGVuRW51bUEAAABwdXRjAABTZXRUaW1lcgAAAAAIAAwAAAAi MQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAA ------------PIQVEWEJKFG154-- From owner-linux-xfs@oss.sgi.com Tue Jul 15 01:37:21 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 15 Jul 2003 01:37:41 -0700 (PDT) Received: from solkan.p-ng.si (IDENT:yRmgSYHb7SkQ0IFT6krCpQt6h0XKMm9i@solkan.p-ng.si [193.2.120.2]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h6F8b9Fl032622 for ; Tue, 15 Jul 2003 01:37:10 -0700 Received: from localhost (localhost [127.0.0.1]) by solkan.p-ng.si (Postfix) with ESMTP id 66E06B1EB7 for ; Tue, 15 Jul 2003 10:04:22 +0200 (CEST) Received: from solkan.p-ng.si ([127.0.0.1]) by localhost (solkan.p-ng.si [127.0.0.1]) (amavisd-new) with ESMTP id 10241-01 for ; Tue, 15 Jul 2003 10:04:20 -0000 (CEST) Received: by solkan.p-ng.si (Postfix, from userid 3479) id BBB22B1EB4; Tue, 15 Jul 2003 10:04:20 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by solkan.p-ng.si (Postfix) with ESMTP id BABA1B1E25 for ; Tue, 15 Jul 2003 10:04:20 +0200 (CEST) Date: Tue, 15 Jul 2003 10:04:20 +0200 (CEST) From: Egon Pavlica To: linux-xfs@oss.sgi.com Subject: flushing buffer more frequently Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by amavisd-new / Sophos+Sophie at p-ng.si X-Razor-id: 5bd5802a852e0de8281f3ef560e354195170c884 X-archive-position: 4646 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: Egon.Pavlica@p-ng.si Precedence: bulk X-list: linux-xfs Content-Length: 653 Lines: 17 hello, i hope this belong to this list (i am new). I have promise sx6000 ata raid controller with 4x120GB. I use software raid0 and xfs with kernel 2.4.21-ac4 on a pentium 4 + abit kd7 board. problem: when i write to xfs raid filesystem, the data is buffered into memory (i suppose). When the buffer is full, the data is written to disk(i suppose). But this cause (i suppose) the system to freeze. Some people suggested me to start update daemon and try flushing buffer more frequentlly. I am interested, if there is a solution to this problem, since i need a machine for realtime video broadcast.... thanks to anyone! egon.pavlica@p-ng.si From owner-linux-xfs@oss.sgi.com Tue Jul 15 03:14:26 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 15 Jul 2003 03:14:43 -0700 (PDT) Received: from mail.arkena.dk (mail.arkena.dk [195.190.149.7]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h6FAEFFl008270 for ; Tue, 15 Jul 2003 03:14:15 -0700 Received: from thomas.arkena.com (staalanden.arkena.dk [80.62.194.202]) by mail.arkena.dk (Postfix) with ESMTP id A70E2BD for ; Tue, 15 Jul 2003 11:53:44 +0200 (CEST) Received: by thomas.arkena.com (Postfix, from userid 1000) id 0FD47804; Tue, 15 Jul 2003 11:53:44 +0200 (CEST) Date: Tue, 15 Jul 2003 11:53:43 +0200 From: Thomas Kirk To: linux-xfs@oss.sgi.com Subject: xfs_repair segfault while repairing corrupt directory Message-ID: <20030715095343.GA22590@thomas.arkena.com> Mail-Followup-To: linux-xfs@oss.sgi.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.3i X-archive-position: 4647 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: thomas@arkena.dk Precedence: bulk X-list: linux-xfs Content-Length: 3861 Lines: 127 System : Debian sarge (testing) Kernel : 2.4.20 debian kernel xfs : Patched kernel via debian (http://packages.debian.org/testing/devel/kernel-patch-xfs.html) xfsprogs : xfs_repair (2.5.3) same error with xfsprogs from testing and unstable fssize : 70GB Dmesg : thomas@wintherstill:~$ grep XFS /var/log/dmesg SGI XFS snapshot 2.4.20-2002-11-29_01:21_UTC with ACLs, quota, no debug enabled XFS mounting filesystem ide1(22,1) Starting XFS recovery on filesystem: ide1(22,1) (dev: 22/1) Ending XFS recovery on filesystem: ide1(22,1) (dev: 22/1) XFS mounting filesystem ide0(3,5) Starting XFS recovery on filesystem: ide0(3,5) (dev: 3/5) Ending XFS recovery on filesystem: ide0(3,5) (dev: 3/5) xfs_repair: xfs_repair /dev/hda5 Phase 5 - rebuild AG headers and trees... - reset superblock... Phase 6 - check inode connectivity... - resetting contents of realtime bitmap and summary inodes - ensuring existence of lost+found directory - traversing filesystem starting at / ... bad hash table for directory inode 200647659 (bad stale count): rebuilding rebuilding directory inode 200647659 Lagersegmentfejl gdb output : Phase 5 - rebuild AG headers and trees... - reset superblock... Phase 6 - check inode connectivity... - resetting contents of realtime bitmap and summary inodes - ensuring existence of lost+found directory - traversing filesystem starting at / ... bad hash table for directory inode 200647659 (bad stale count): rebuilding rebuilding directory inode 200647659 Program received signal SIGSEGV, Segmentation fault. 0x080a1c8f in libxfs_dir2_data_make_free (tp=0x81d1fc0, bp=0x81bd328, offset=528312, len=4294443080, needlogp=0xbffff8a8, needscanp=0xbffff8ac) at xfs_dir2_data.c:552 552 tagp = (xfs_dir2_data_off_t *)((char *)d + offset) - 1; bt output : (gdb) bt #0 0x080a1c8f in libxfs_dir2_data_make_free (tp=0x81d1fc0, bp=0x81bd328, offset=528312, len=4294443080, needlogp=0xbffff8a8, needscanp=0xbffff8ac) at xfs_dir2_data.c:552 #1 0x080709f9 in longform_dir2_rebuild_setup (mp=0xbffffb14, ino=200647659, ip=0x8117c60, freetab=0x81c8048) at phase6.c:2357 #2 0x080719d9 in longform_dir2_rebuild (mp=0xbffffb14, ino=200647659, ip=0x8117c60, num_illegal=0xbffffa60, freetab=0x81c8048, isblock=1) at phase6.c:2648 #3 0x08071e24 in longform_dir2_entry_check (mp=0xbffffb14, ino=200647659, ip=0x8117c60, num_illegal=0xbffffa60, need_dot=0xbffffa64, stack=0xbffffad0, irec=0x8105b68, ino_offset=43) at phase6.c:2752 #4 0x0807379c in process_dirstack (mp=0xbffffb14, stack=0xbffffad0) at phase6.c:3569 #5 0x080746b0 in phase6 (mp=0xbffffb14) at phase6.c:3976 #6 0x0807b7ee in main (argc=2, argv=0xbffffd74) at xfs_repair.c:522 xfs_db output : wintherstill:/home/xfsprogs-2.5.3/db# ./xfs_db /dev/hda5 xfs_db> inode 200647659 xfs_db> print core.magic = 0x494e core.mode = 040755 core.version = 1 core.format = 2 (extents) core.nlinkv1 = 2 core.uid = 1000 core.gid = 1000 core.atime.sec = Tue Jul 15 08:47:42 2003 core.atime.nsec = 979143000 core.mtime.sec = Mon Jul 14 21:07:45 2003 core.mtime.nsec = 428690000 core.ctime.sec = Mon Jul 14 21:07:45 2003 core.ctime.nsec = 428690000 core.size = 4096 core.nblocks = 1 core.extsize = 0 core.nextents = 1 core.naextents = 0 core.forkoff = 0 core.aformat = 2 (extents) core.dmevmask = 0 core.dmstate = 0 core.newrtbm = 0 core.prealloc = 0 core.realtime = 0 core.gen = 1 next_unlinked = null u.bmx[0] = [startoff,startblock,blockcount,extentflag] 0:[0,13206447,1,0] The fs got corrupted due to a powerfailure while copying files from one disk to another. -- Venlig hilsen/Kind regards Thomas Kirk ARKENA tlf/phone +4570233456 thomas(at)arkena(dot)com Http://www.arkena.com "Don't you ever, EVER talk that way about television." -- Homer Simpson From owner-linux-xfs@oss.sgi.com Tue Jul 15 06:28:20 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 15 Jul 2003 06:28:43 -0700 (PDT) Received: from rrzd2.rz.uni-regensburg.de (root@rrzd2.rz.uni-regensburg.de [132.199.1.12]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h6FDSIFl013515 for ; Tue, 15 Jul 2003 06:28:19 -0700 Received: from rss1.rz.uni-regensburg.de (rss1.rz.uni-regensburg.de [132.199.1.200]) by rrzd2.rz.uni-regensburg.de (8.12.3/8.12.3/Debian -4) with SMTP id h6FDSGTG018096 for ; Tue, 15 Jul 2003 15:28:17 +0200 Received: (qmail 8433 invoked from network); 15 Jul 2003 15:28:16 +0200 Received: from pc9391.physik.uni-regensburg.de (HELO pc9391) (guc28561@132.199.98.219) by rss1.rz.uni-regensburg.de with SMTP; 15 Jul 2003 15:28:16 +0200 Date: Tue, 15 Jul 2003 15:28:16 +0200 From: Christian Guggenberger To: linux-xfs@oss.sgi.com Subject: weird kernel messages Message-ID: <20030715152816.A31132@pc9391.uni-regensburg.de> Mime-Version: 1.0 Content-Type: text/plain; format=flowed; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Mailer: Balsa 1.2.4 X-archive-position: 4648 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: Christian.Guggenberger@physik.uni-regensburg.de Precedence: bulk X-list: linux-xfs Content-Length: 1519 Lines: 28 Hi folks, I'm seeing some (for me) non readable kernel messages on a nfs-server running 2.4.21-xfs (20030707). There's no debugging enabled. I don't know what they mean, and would be very glad if one of you could give me some hints about them. Here they are: 0x0: 30 45 2d 30 32 2c 2d 30 2e 33 36 37 37 36 36 36 0x0: 30 45 2d 30 32 2c 2d 30 2e 33 36 37 37 36 36 36 0x0: 30 45 2d 30 32 2c 2d 30 2e 33 36 37 37 36 36 36 0x0: 30 45 2d 30 32 2c 2d 30 2e 33 36 37 37 36 36 36 0x0: 30 45 2d 30 32 2c 2d 30 2e 33 36 37 37 36 36 36 0x0: 30 45 2d 30 32 2c 2d 30 2e 33 36 37 37 36 36 36 0x0: 30 45 2d 30 32 2c 2d 30 2e 33 36 37 37 36 36 36 0x0: 30 45 2d 30 32 2c 2d 30 2e 33 36 37 37 36 36 36 0x0: 30 45 2d 30 32 2c 2d 30 2e 33 36 37 37 36 36 36 0x0: 30 45 2d 30 32 2c 2d 30 2e 33 36 37 37 36 36 36 0x0: 30 45 2d 30 32 2c 2d 30 2e 33 36 37 37 36 36 36 0x0: 30 45 2d 30 32 2c 2d 30 2e 33 36 37 37 36 36 36 0x0: 30 45 2d 30 32 2c 2d 30 2e 33 36 37 37 36 36 36 0x0: 30 45 2d 30 32 2c 2d 30 2e 33 36 37 37 36 36 36 0x0: 30 45 2d 30 32 2c 2d 30 2e 33 36 37 37 36 36 36 0x0: 30 45 2d 30 32 2c 2d 30 2e 33 36 37 37 36 36 36 0x0: 30 45 2d 30 32 2c 2d 30 2e 33 36 37 37 36 36 36 0x0: 35 39 32 38 30 39 35 36 30 38 37 32 31 37 37 39 0x0: 35 39 32 38 30 39 35 36 30 38 37 32 31 37 37 39 0x0: 35 39 32 38 30 39 35 36 30 38 37 32 31 37 37 39 0x0: 35 39 32 38 30 39 35 36 30 38 37 32 31 37 37 39 0x0: 00 00 8d 65 e8 5b 5e 5f c9 c3 89 f6 55 89 e5 83 0x0: 00 00 8d 65 e8 5b 5e 5f c9 c3 89 f6 55 89 e5 83 ... thanks Christian From owner-linux-xfs@oss.sgi.com Tue Jul 15 06:43:59 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 15 Jul 2003 06:44:19 -0700 (PDT) Received: from zok.sgi.com (zok.sgi.com [204.94.215.101]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h6FDhwFl014610 for ; Tue, 15 Jul 2003 06:43:58 -0700 Received: from flecktone.americas.sgi.com (flecktone.americas.sgi.com [192.48.203.135]) by zok.sgi.com (8.12.9/8.12.2/linux-outbound_gateway-1.2) with ESMTP id h6FDhniY022097 for ; Tue, 15 Jul 2003 06:43:52 -0700 Received: from poppy-e236.americas.sgi.com (poppy-e236.americas.sgi.com [128.162.236.207]) by flecktone.americas.sgi.com (8.12.9/8.12.9/generic_config-1.2) with ESMTP id h6FDgmqX9572421; Tue, 15 Jul 2003 08:42:48 -0500 (CDT) Received: from stout.americas.sgi.com (stout.americas.sgi.com [128.162.232.50]) by poppy-e236.americas.sgi.com (8.12.9/SGI-server-1.8) with ESMTP id h6FDgmYl14646478; Tue, 15 Jul 2003 08:42:48 -0500 (CDT) Date: Tue, 15 Jul 2003 08:42:48 -0500 (CDT) From: Eric Sandeen X-X-Sender: sandeen@stout.americas.sgi.com To: Christian Guggenberger cc: linux-xfs@oss.sgi.com Subject: Re: weird kernel messages In-Reply-To: <20030715152816.A31132@pc9391.uni-regensburg.de> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 4649 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: sandeen@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 1795 Lines: 39 That looks like the new & improved verbose error reporting... minus some of the actual verbosity. :) These are from /var/log/messages, or on the console? -Eric On Tue, 15 Jul 2003, Christian Guggenberger wrote: > Hi folks, > > I'm seeing some (for me) non readable kernel messages on a nfs-server running > 2.4.21-xfs (20030707). There's no debugging enabled. > I don't know what they mean, and would be very glad if one of you could give > me some hints about them. > Here they are: > 0x0: 30 45 2d 30 32 2c 2d 30 2e 33 36 37 37 36 36 36 0x0: 30 45 2d 30 32 2c 2d > 30 2e 33 36 37 37 36 36 36 0x0: 30 45 2d 30 32 2c 2d 30 2e 33 36 37 37 36 36 > 36 0x0: 30 45 2d 30 32 2c 2d 30 2e 33 36 37 37 36 36 36 0x0: 30 45 2d 30 32 2c > 2d 30 2e 33 36 37 37 36 36 36 0x0: 30 45 2d 30 32 2c 2d 30 2e 33 36 37 37 36 > 36 36 0x0: 30 45 2d 30 32 2c 2d 30 2e 33 36 37 37 36 36 36 0x0: 30 45 2d 30 32 > 2c 2d 30 2e 33 36 37 37 36 36 36 0x0: 30 45 2d 30 32 2c 2d 30 2e 33 36 37 37 > 36 36 36 0x0: 30 45 2d 30 32 2c 2d 30 2e 33 36 37 37 36 36 36 0x0: 30 45 2d 30 > 32 2c 2d 30 2e 33 36 37 37 36 36 36 0x0: 30 45 2d 30 32 2c 2d 30 2e 33 36 37 > 37 36 36 36 0x0: 30 45 2d 30 32 2c 2d 30 2e 33 36 37 37 36 36 36 0x0: 30 45 2d > 30 32 2c 2d 30 2e 33 36 37 37 36 36 36 0x0: 30 45 2d 30 32 2c 2d 30 2e 33 36 > 37 37 36 36 36 0x0: 30 45 2d 30 32 2c 2d 30 2e 33 36 37 37 36 36 36 0x0: 30 45 > 2d 30 32 2c 2d 30 2e 33 36 37 37 36 36 36 0x0: 35 39 32 38 30 39 35 36 30 38 > 37 32 31 37 37 39 0x0: 35 39 32 38 30 39 35 36 30 38 37 32 31 37 37 39 0x0: 35 > 39 32 38 30 39 35 36 30 38 37 32 31 37 37 39 0x0: 35 39 32 38 30 39 35 36 30 > 38 37 32 31 37 37 39 0x0: 00 00 8d 65 e8 5b 5e 5f c9 c3 89 f6 55 89 e5 83 0x0: > 00 00 8d 65 e8 5b 5e 5f c9 c3 89 f6 55 89 e5 83 > ... > > thanks > Christian > > From owner-linux-xfs@oss.sgi.com Tue Jul 15 07:19:56 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 15 Jul 2003 07:20:21 -0700 (PDT) Received: from rrzd2.rz.uni-regensburg.de (root@rrzd2.rz.uni-regensburg.de [132.199.1.12]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h6FEJrFl017245 for ; Tue, 15 Jul 2003 07:19:55 -0700 Received: from rss1.rz.uni-regensburg.de (rss1.rz.uni-regensburg.de [132.199.1.200]) by rrzd2.rz.uni-regensburg.de (8.12.3/8.12.3/Debian -4) with SMTP id h6FEJqTG007604 for ; Tue, 15 Jul 2003 16:19:52 +0200 Received: (qmail 9381 invoked from network); 15 Jul 2003 16:19:52 +0200 Received: from pc9391.physik.uni-regensburg.de (HELO pc9391) (guc28561@132.199.98.219) by rss1.rz.uni-regensburg.de with SMTP; 15 Jul 2003 16:19:52 +0200 Date: Tue, 15 Jul 2003 16:19:51 +0200 From: Christian Guggenberger To: Eric Sandeen Cc: Christian Guggenberger , linux-xfs@oss.sgi.com Subject: Re: weird kernel messages Message-ID: <20030715161951.E31132@pc9391.uni-regensburg.de> References: <20030715152816.A31132@pc9391.uni-regensburg.de> Mime-Version: 1.0 Content-Type: text/plain; format=flowed; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit In-Reply-To: ; from sandeen@sgi.com on Tue, Jul 15, 2003 at 15:42:48 +0200 X-Mailer: Balsa 1.2.4 X-archive-position: 4650 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: Christian.Guggenberger@physik.uni-regensburg.de Precedence: bulk X-list: linux-xfs Content-Length: 643 Lines: 17 On 15.07.2003 15:42 Eric Sandeen wrote: > That looks like the new & improved verbose error reporting... minus > some of the actual verbosity. :) > > These are from /var/log/messages, or on the console? > These are from both /var/log/kern.log and console. We were running 2.4.20-xfs, but this one brought some actual verbose debug messages, when a nfs client still had mounted an nfs volume, which changed underneath on the server. I think, these new messages are still related to nfs clients trying to access old nfs-exports. See http://marc.theaimsgroup.com/?l=linux-xfs&m=105747586206175&w=2 for the 2.4.20-xfs messages. Christian From owner-linux-xfs@oss.sgi.com Tue Jul 15 07:31:57 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 15 Jul 2003 07:32:14 -0700 (PDT) Received: from tolkor.sgi.com (tolkor.sgi.com [198.149.18.6]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h6FEVtFl018209 for ; Tue, 15 Jul 2003 07:31:56 -0700 Received: from flecktone.americas.sgi.com (flecktone.americas.sgi.com [192.48.203.135]) by tolkor.sgi.com (8.12.9/8.12.2/linux-outbound_gateway-1.2) with ESMTP id h6FEoGmO031194 for ; Tue, 15 Jul 2003 09:50:16 -0500 Received: from daisy-e236.americas.sgi.com (daisy-e236.americas.sgi.com [128.162.236.214]) by flecktone.americas.sgi.com (8.12.9/8.12.9/generic_config-1.2) with ESMTP id h6FEVnqX9598924; Tue, 15 Jul 2003 09:31:49 -0500 (CDT) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.232.100]) by daisy-e236.americas.sgi.com (8.12.9/SGI-server-1.8) with ESMTP id h6FEVnRn176343169; Tue, 15 Jul 2003 09:31:49 -0500 (CDT) Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id h6FEVnQ16066; Tue, 15 Jul 2003 09:31:49 -0500 Subject: Re: weird kernel messages From: Steve Lord To: Christian Guggenberger Cc: Eric Sandeen , linux-xfs@oss.sgi.com In-Reply-To: <20030715161951.E31132@pc9391.uni-regensburg.de> References: <20030715152816.A31132@pc9391.uni-regensburg.de> <20030715161951.E31132@pc9391.uni-regensburg.de> Content-Type: text/plain Content-Transfer-Encoding: 7bit Organization: Message-Id: <1058279508.15986.26.camel@jen.americas.sgi.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.4 Date: 15 Jul 2003 09:31:49 -0500 X-archive-position: 4651 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: lord@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 1567 Lines: 43 On Tue, 2003-07-15 at 09:19, Christian Guggenberger wrote: > On 15.07.2003 15:42 Eric Sandeen wrote: > > That looks like the new & improved verbose error reporting... minus > > some of the actual verbosity. :) > > > > These are from /var/log/messages, or on the console? > > > These are from both /var/log/kern.log and console. > We were running 2.4.20-xfs, but this one brought some actual verbose debug > messages, when a nfs client still had mounted an nfs volume, which changed > underneath on the server. I think, these new messages are still related to nfs > clients trying to access old nfs-exports. > See > http://marc.theaimsgroup.com/?l=linux-xfs&m=105747586206175&w=2 > for the 2.4.20-xfs messages. > > Christian Yes, these smell like nfs file handles being fed to the wrong filesystem, this should shut them up: =========================================================================== Index: linux/fs/xfs/xfs_error.c =========================================================================== --- /usr/tmp/TmpDir.16057-0/linux/fs/xfs/xfs_error.c_1.45 Tue Jul 15 09:31:19 2003 +++ linux/fs/xfs/xfs_error.c Tue Jul 15 09:31:04 2003 @@ -323,6 +323,7 @@ int linenum, inst_t *ra) { - xfs_hex_dump(p, 16); + if (level <= xfs_error_level) + xfs_hex_dump(p, 16); xfs_error_report(tag, level, mp, fname, linenum, ra); } -- Steve Lord voice: +1-651-683-3511 Principal Engineer, Filesystem Software email: lord@sgi.com From owner-linux-xfs@oss.sgi.com Tue Jul 15 08:06:56 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 15 Jul 2003 08:07:13 -0700 (PDT) Received: from zok.sgi.com (zok.sgi.com [204.94.215.101]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h6FF6tFl019832 for ; Tue, 15 Jul 2003 08:06:56 -0700 Received: from flecktone.americas.sgi.com (flecktone.americas.sgi.com [192.48.203.135]) by zok.sgi.com (8.12.9/8.12.2/linux-outbound_gateway-1.2) with ESMTP id h6FF6oiY003745 for ; Tue, 15 Jul 2003 08:06:50 -0700 Received: from daisy-e236.americas.sgi.com (daisy-e236.americas.sgi.com [128.162.236.214]) by flecktone.americas.sgi.com (8.12.9/8.12.9/generic_config-1.2) with ESMTP id h6FF6oqX9612782 for ; Tue, 15 Jul 2003 10:06:50 -0500 (CDT) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.232.100]) by daisy-e236.americas.sgi.com (8.12.9/SGI-server-1.8) with ESMTP id h6FF6nRn177265163 for ; Tue, 15 Jul 2003 10:06:49 -0500 (CDT) From: Steve Lord Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id h6FF6nT17418; Tue, 15 Jul 2003 10:06:49 -0500 Message-Id: <200307151506.h6FF6nT17418@jen.americas.sgi.com> Date: Tue, 15 Jul 2003 10:06:49 -0500 Subject: TAKE - shut up a hex dump error message To: linux-xfs@oss.sgi.com X-archive-position: 4652 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: lord@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 429 Lines: 17 Be consistent about when we dump error messages. Make sure the hex component of an error message only comes out when the message does. Date: Tue Jul 15 08:06:01 PDT 2003 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: xfs-linux:slinx:153268a linux/fs/xfs/xfs_error.c - 1.46 - pay attention to the error level properly. From owner-linux-xfs@oss.sgi.com Tue Jul 15 08:47:14 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 15 Jul 2003 08:47:27 -0700 (PDT) Received: from tolkor.sgi.com (tolkor.sgi.com [198.149.18.6]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h6FFlEFl024204 for ; Tue, 15 Jul 2003 08:47:14 -0700 Received: from flecktone.americas.sgi.com (flecktone.americas.sgi.com [192.48.203.135]) by tolkor.sgi.com (8.12.9/8.12.2/linux-outbound_gateway-1.2) with ESMTP id h6FG5YmO010276 for ; Tue, 15 Jul 2003 11:05:34 -0500 Received: from daisy-e236.americas.sgi.com (daisy-e236.americas.sgi.com [128.162.236.214]) by flecktone.americas.sgi.com (8.12.9/8.12.9/generic_config-1.2) with ESMTP id h6FFl8qX9616880 for ; Tue, 15 Jul 2003 10:47:08 -0500 (CDT) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.232.100]) by daisy-e236.americas.sgi.com (8.12.9/SGI-server-1.8) with ESMTP id h6FFl8Rn172458251 for ; Tue, 15 Jul 2003 10:47:08 -0500 (CDT) From: Steve Lord Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id h6FFl7b18432; Tue, 15 Jul 2003 10:47:07 -0500 Message-Id: <200307151547.h6FFl7b18432@jen.americas.sgi.com> Date: Tue, 15 Jul 2003 10:47:07 -0500 Subject: TAKE - Scale default number of log buffers based on memory size To: linux-xfs@oss.sgi.com X-archive-position: 4653 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: lord@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 595 Lines: 22 Originally from andi Kleen. Date: Tue Jul 15 08:46:39 PDT 2003 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: xfs-linux:slinx:153273a linux/fs/xfs/xfs_log.c - 1.277 - if the user did not specify how many log buffers to use, then scale the number we use based on available memory. linux/fs/xfs/xfs_log_priv.h - 1.96 - Changed defines for scaling default log buffers with memory size linux/fs/xfs/xfs_vfsops.c - 1.426 - use new constants for bounds checking on logbuf parameters From owner-linux-xfs@oss.sgi.com Tue Jul 15 10:16:14 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 15 Jul 2003 10:16:19 -0700 (PDT) Received: from zok.sgi.com (zok.sgi.com [204.94.215.101]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h6FHGDFl030154 for ; Tue, 15 Jul 2003 10:16:13 -0700 Received: from flecktone.americas.sgi.com (flecktone.americas.sgi.com [192.48.203.135]) by zok.sgi.com (8.12.9/8.12.2/linux-outbound_gateway-1.2) with ESMTP id h6FHG8iY027793 for ; Tue, 15 Jul 2003 10:16:08 -0700 Received: from daisy-e236.americas.sgi.com (daisy-e236.americas.sgi.com [128.162.236.214]) by flecktone.americas.sgi.com (8.12.9/8.12.9/generic_config-1.2) with ESMTP id h6FHG7qX9634154; Tue, 15 Jul 2003 12:16:07 -0500 (CDT) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.232.100]) by daisy-e236.americas.sgi.com (8.12.9/SGI-server-1.8) with ESMTP id h6FHG6Rn173680546; Tue, 15 Jul 2003 12:16:06 -0500 (CDT) Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id h6FHG6e23180; Tue, 15 Jul 2003 12:16:06 -0500 Subject: Re: transaction in XFS From: Steve Lord To: jin hee park Cc: linux-xfs@oss.sgi.com In-Reply-To: <20030715004415.15068.qmail@web10008.mail.yahoo.com> References: <20030715004415.15068.qmail@web10008.mail.yahoo.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit Organization: Message-Id: <1058289365.15986.98.camel@jen.americas.sgi.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.4 Date: 15 Jul 2003 12:16:05 -0500 X-archive-position: 4654 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: lord@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 2528 Lines: 80 On Mon, 2003-07-14 at 19:44, jin hee park wrote: > Hello, Steve > thank you for a clear explanation. > > For example, there are four extents to truncate in a > file. Maybe two transacions (each transaction for two > extents deletion) will occur. > If there is a crash in the middle of two transactions > (the one : incore log was logged to disk log, and the > other : incore log was not logged to disk log), > doesn't the other work? > I mean that the one worked, and the other didn't work. > How can I understand this? If the file is being deleted then it is placed on the unlinked inode list when the remove is performed. When the inode goes inactive, the extents are freed. At the end of freeing the extents the inode itself is freed, so there are more transactions than just removing the extents. If the crash happens at any time after the transaction which puts the inode on the unlinked list, the remainder of the process of deleting the file happens during the recovery processing in the next mount. If this transaction did not make it out to disk, then the file will still be there after the crash. For inodes which are being truncated without being unlinked then the truncate may be partial after recovery. ext3 places these inodes on its 'unlinked' list too so the truncate gets completed after recovery I have been considering doing this for xfs too. Steve > > --- Steve Lord wrote: > > On Mon, 2003-07-14 at 06:50, jin hee park wrote: > > > Hello~ > > > > > > I have a question about transaction in XFS. > > > > > > Are transactions (which are chained using > > > xfs_trans_dup function) atomic? > > > I wonder that such transactions are like one > > > transacion idea(all or nothing). > > > please, let me know.. > > > > > > thank you. > > > - JinHee > > > > > > > These transactions are not atomic, each one records > > sufficient > > information to rebuild a consistent filesystem after > > a crash. > > > > An example use of chained transactions is deleting > > extents in a > > file, the amount of log space this needs is > > unbounded - a function > > of the number of extents in the file. We cannot do > > the whole > > sequence in one transaction, so we use a chain of > > them. > > > > Steve > > > > > > > __________________________________ > Do you Yahoo!? > SBC Yahoo! DSL - Now only $29.95 per month! > http://sbc.yahoo.com -- Steve Lord voice: +1-651-683-3511 Principal Engineer, Filesystem Software email: lord@sgi.com From owner-linux-xfs@oss.sgi.com Tue Jul 15 14:42:32 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 15 Jul 2003 14:42:55 -0700 (PDT) Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.9/8.12.9) with ESMTP id h6FLgWFl012630 for ; Tue, 15 Jul 2003 14:42:32 -0700 Received: (from xfs@localhost) by oss.sgi.com (8.12.9/8.12.8/Submit) id h6FLgWxQ012629 for linux-xfs@oss.sgi.com; Tue, 15 Jul 2003 14:42:32 -0700 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.9/8.12.9) with ESMTP id h6FLgUFn012613 for ; Tue, 15 Jul 2003 14:42:30 -0700 Received: (from apache@localhost) by oss.sgi.com (8.12.9/8.12.8/Submit) id h6FLPxuB012259; Tue, 15 Jul 2003 14:25:59 -0700 Date: Tue, 15 Jul 2003 14:25:59 -0700 Message-Id: <200307152125.h6FLPxuB012259@oss.sgi.com> From: bugzilla-daemon@oss.sgi.com To: xfs-master@oss.sgi.com Subject: [Bug 263] New: unwritten extents hook in "TAKE - xfs iocore rework" breaks db related executable X-Bugzilla-Reason: AssignedTo X-archive-position: 4655 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: bugzilla-daemon@oss.sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 2710 Lines: 78 http://oss.sgi.com/bugzilla/show_bug.cgi?id=263 Summary: unwritten extents hook in "TAKE - xfs iocore rework" breaks db related executable Product: Linux XFS Version: Current Platform: IA32 OS/Version: Linux Status: NEW Severity: normal Priority: High Component: XFS kernel code AssignedTo: xfs-master@oss.sgi.com ReportedBy: erik.habbinga@hp.com We have an application that uses the db database code. When we moved from an older XFS CVS code drop to one newer than Dec 11, 2002, that application would hang after running SPEC SFS NFS testing on the server. In the CVS take from Dec 11, 2002 labeled "TAKE - xfs iocore rework", three patch hunks are applied to fs/xfs/linux/xfs_aops.c. Not performing the third hunk allows our application to run without hanging through multiple SPEC SFS NFS tests. We are now using an XFS CVS code drop from June 16, 2003 with the 2.4.21 kernel and still need to patch XFS to remove that third hunk to allow our application to run without hanging. Any ideas why we need to back out this part of the CVS take? Erik Habbinga Hewlett Packard The original CVS TAKE message: http://oss.sgi.com/projects/xfs/mail_archive/200212/msg00144.html The CVS diff showing the changes to xfs_aops.c for that TAKE: http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/linux/fs/xfs/linux/xfs_aops.c.diff?r1=1.15&r2=1.16 The patch we apply to recent XFS to allow our application to run: --- linux/fs/xfs/linux/xfs_aops.c~ Wed Apr 23 12:49:47 2003 +++ linux/fs/xfs/linux/xfs_aops.c Wed Apr 23 12:52:10 2003 @@ -790,25 +787,14 @@ page_buf_daddr_t bn; loff_t delta; - /* For unwritten extents do not report a disk address on - * the read case. - */ - if (create || ((pbmap.pbm_flags & PBMF_UNWRITTEN) == 0)) { - delta = offset - pbmap.pbm_offset; - delta >>= inode->i_blkbits; - - bn = pbmap.pbm_bn >> (inode->i_blkbits - BBSHIFT); - bn += delta; - - bh_result->b_blocknr = bn; - set_bit(BH_Mapped, &bh_result->b_state); - } - if (pbmap.pbm_flags & PBMF_UNWRITTEN) { - if (create) - set_bit(BH_Mapped, &bh_result->b_state); - set_bit(BH_Unwritten, &bh_result->b_state); - set_bit(BH_Delay, &bh_result->b_state); - } + delta = offset - pbmap.pbm_offset; + delta >>= inode->i_blkbits; + + bn = pbmap.pbm_bn >> (inode->i_blkbits - BBSHIFT); + bn += delta; + + bh_result->b_blocknr = bn; + set_bit(BH_Mapped, &bh_result->b_state); } /* If we previously allocated a block out beyond eof and ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From owner-linux-xfs@oss.sgi.com Tue Jul 15 16:52:44 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 15 Jul 2003 16:53:01 -0700 (PDT) Received: from zok.sgi.com (zok.sgi.com [204.94.215.101]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h6FNqhFl018053 for ; Tue, 15 Jul 2003 16:52:44 -0700 Received: from bruce.melbourne.sgi.com (bruce.melbourne.sgi.com [134.14.54.176]) by zok.sgi.com (8.12.9/8.12.2/linux-outbound_gateway-1.2) with ESMTP id h6FNqbiY003122 for ; Tue, 15 Jul 2003 16:52:38 -0700 Received: from bruce.melbourne.sgi.com (localhost.localdomain [127.0.0.1]) by bruce.melbourne.sgi.com (8.12.8/8.12.8) with ESMTP id h6FNqbWB002136 for ; Wed, 16 Jul 2003 09:52:38 +1000 Received: (from nathans@localhost) by bruce.melbourne.sgi.com (8.12.8/8.12.8/Submit) id h6FNqbdv002135 for linux-xfs@oss.sgi.com; Wed, 16 Jul 2003 09:52:37 +1000 Date: Wed, 16 Jul 2003 09:52:37 +1000 From: Nathan Scott Message-Id: <200307152352.h6FNqbdv002135@bruce.melbourne.sgi.com> Subject: TAKE - resvsp/truncate fix X-archive-position: 4656 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: nathans@bruce.melbourne.sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 327 Lines: 13 Fix the resvsp/truncate interaction problem that mikes@av.com reported. Date: Tue Jul 15 16:26:16 PDT 2003 Workarea: bruce.melbourne.sgi.com:/home/nathans/isms/devel The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: xfs-linux:slinx:153351a linux/fs/xfs/linux/xfs_lrw.c - 1.192 From owner-linux-xfs@oss.sgi.com Tue Jul 15 17:42:35 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 15 Jul 2003 17:42:55 -0700 (PDT) Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.9/8.12.9) with ESMTP id h6G0gZFl020774 for ; Tue, 15 Jul 2003 17:42:35 -0700 Received: (from xfs@localhost) by oss.sgi.com (8.12.9/8.12.8/Submit) id h6G0gZUa020769 for linux-xfs@oss.sgi.com; Tue, 15 Jul 2003 17:42:35 -0700 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.9/8.12.9) with ESMTP id h6G0gWFp020738 for ; Tue, 15 Jul 2003 17:42:32 -0700 Received: (from apache@localhost) by oss.sgi.com (8.12.9/8.12.8/Submit) id h6FNhZ0W017889; Tue, 15 Jul 2003 16:43:35 -0700 Date: Tue, 15 Jul 2003 16:43:35 -0700 Message-Id: <200307152343.h6FNhZ0W017889@oss.sgi.com> From: bugzilla-daemon@oss.sgi.com To: xfs-master@oss.sgi.com Subject: [Bug 258] Kernel (smp) lockup: ioctl(XFS_IOC_RESVSP); truncate() on fs with unwritten=1 X-Bugzilla-Reason: AssignedTo X-archive-position: 4657 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: bugzilla-daemon@oss.sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 839 Lines: 31 http://oss.sgi.com/bugzilla/show_bug.cgi?id=258 nathans@sgi.com changed: What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED ------- Additional Comments From nathans@sgi.com 2003-15-07 16:43 PDT ------- Mike, I've just checked in a fix for this problem - Steve suggested something, I went and tried it and, woohoo, it worked a treat. That truncate of yours should finish immediately now and no IO should be issued. cheers. ps: for easier testing, your program is basically the same as: # xfs_io -f -c 'resvsp 0 10g' -c 'truncate 10g' /tmp/foo (using latest xfsprogs). ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From owner-linux-xfs@oss.sgi.com Tue Jul 15 19:42:35 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 15 Jul 2003 19:42:53 -0700 (PDT) Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.9/8.12.9) with ESMTP id h6G2gYFl030598 for ; Tue, 15 Jul 2003 19:42:34 -0700 Received: (from xfs@localhost) by oss.sgi.com (8.12.9/8.12.8/Submit) id h6G2gYvI030597 for linux-xfs@oss.sgi.com; Tue, 15 Jul 2003 19:42:34 -0700 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.9/8.12.9) with ESMTP id h6G2gVFn030583 for ; Tue, 15 Jul 2003 19:42:32 -0700 Received: (from apache@localhost) by oss.sgi.com (8.12.9/8.12.8/Submit) id h6G2OXPp029571; Tue, 15 Jul 2003 19:24:33 -0700 Date: Tue, 15 Jul 2003 19:24:33 -0700 Message-Id: <200307160224.h6G2OXPp029571@oss.sgi.com> From: bugzilla-daemon@oss.sgi.com To: xfs-master@oss.sgi.com Subject: [Bug 263] unwritten extents hook in "TAKE - xfs iocore rework" breaks db related executable X-Bugzilla-Reason: AssignedTo X-archive-position: 4658 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: bugzilla-daemon@oss.sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 758 Lines: 27 http://oss.sgi.com/bugzilla/show_bug.cgi?id=263 cattelan@thebarn.com changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |ASSIGNED ------- Additional Comments From cattelan@thebarn.com 2003-15-07 19:24 PDT ------- do you have kdb enabled? Can you do a back trace of the hung process? nfs does some nasty things in terms of the number of times the server thinks a file is opened and closed. The app might be waiting for IO that is never started due to the buffer not being set up correctly. ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From owner-linux-xfs@oss.sgi.com Wed Jul 16 04:03:30 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 16 Jul 2003 04:04:39 -0700 (PDT) Received: from web10002.mail.yahoo.com (web10002.mail.yahoo.com [216.136.130.38]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h6GB3TFl014489 for ; Wed, 16 Jul 2003 04:03:30 -0700 Message-ID: <20030716110325.42119.qmail@web10002.mail.yahoo.com> Received: from [165.213.1.1] by web10002.mail.yahoo.com via HTTP; Wed, 16 Jul 2003 04:03:25 PDT Date: Wed, 16 Jul 2003 04:03:25 -0700 (PDT) From: jin hee park Subject: Re: transaction in XFS To: Steve Lord Cc: linux-xfs@oss.sgi.com In-Reply-To: <1058289365.15986.98.camel@jen.americas.sgi.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-archive-position: 4659 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: jinny84@yahoo.co.kr Precedence: bulk X-list: linux-xfs Content-Length: 3174 Lines: 126 Hello~ thank you very much for your kind description. I understood what I have wondered. > For inodes which are being truncated without being > unlinked > then the truncate may be partial after recovery. Can I recover such a partial garbage by xfs_repair or other tools? -JinHee --- Steve Lord wrote: > On Mon, 2003-07-14 at 19:44, jin hee park wrote: > > Hello, Steve > > thank you for a clear explanation. > > > > For example, there are four extents to truncate in > a > > file. Maybe two transacions (each transaction for > two > > extents deletion) will occur. > > If there is a crash in the middle of two > transactions > > (the one : incore log was logged to disk log, and > the > > other : incore log was not logged to disk log), > > doesn't the other work? > > I mean that the one worked, and the other didn't > work. > > How can I understand this? > > If the file is being deleted then it is placed on > the unlinked > inode list when the remove is performed. When the > inode goes > inactive, the extents are freed. At the end of > freeing the > extents the inode itself is freed, so there are more > transactions > than just removing the extents. > > If the crash happens at any time after the > transaction which > puts the inode on the unlinked list, the remainder > of the > process of deleting the file happens during the > recovery > processing in the next mount. If this transaction > did not > make it out to disk, then the file will still be > there > after the crash. > > For inodes which are being truncated without being > unlinked > then the truncate may be partial after recovery. > ext3 places > these inodes on its 'unlinked' list too so the > truncate > gets completed after recovery I have been > considering doing > this for xfs too. > > Steve > > > > > --- Steve Lord wrote: > > > On Mon, 2003-07-14 at 06:50, jin hee park wrote: > > > > Hello~ > > > > > > > > I have a question about transaction in XFS. > > > > > > > > Are transactions (which are chained using > > > > xfs_trans_dup function) atomic? > > > > I wonder that such transactions are like one > > > > transacion idea(all or nothing). > > > > please, let me know.. > > > > > > > > thank you. > > > > - JinHee > > > > > > > > > > These transactions are not atomic, each one > records > > > sufficient > > > information to rebuild a consistent filesystem > after > > > a crash. > > > > > > An example use of chained transactions is > deleting > > > extents in a > > > file, the amount of log space this needs is > > > unbounded - a function > > > of the number of extents in the file. We cannot > do > > > the whole > > > sequence in one transaction, so we use a chain > of > > > them. > > > > > > Steve > > > > > > > > > > > > __________________________________ > > Do you Yahoo!? > > SBC Yahoo! DSL - Now only $29.95 per month! > > http://sbc.yahoo.com > -- > > Steve Lord > voice: +1-651-683-3511 > Principal Engineer, Filesystem Software > email: lord@sgi.com __________________________________ Do you Yahoo!? SBC Yahoo! DSL - Now only $29.95 per month! http://sbc.yahoo.com From owner-linux-xfs@oss.sgi.com Wed Jul 16 04:42:16 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 16 Jul 2003 04:42:22 -0700 (PDT) Received: from imag.imag.fr (imag.imag.fr [129.88.30.1]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h6GBgEFl015620 for ; Wed, 16 Jul 2003 04:42:15 -0700 Received: from mail-veri.imag.fr (pave.imag.fr [129.88.43.12]) by imag.imag.fr (8.12.9/8.12.9) with ESMTP id h6GBg8Tt001943 for ; Wed, 16 Jul 2003 13:42:08 +0200 (CEST) Received: from astazou.imag.fr ([129.88.43.102] helo=astazou.imag.fr.imag.fr ident=kowalski) by mail-veri.imag.fr with esmtp (Exim 3.35 #1 (Debian)) id 19ckfg-0008Ix-00 for ; Wed, 16 Jul 2003 13:42:08 +0200 To: linux-xfs@oss.sgi.com Subject: maximize xfsdump media file size From: Nicolas Kowalski Date: Wed, 16 Jul 2003 13:42:08 +0200 Message-ID: User-Agent: Gnus/5.1002 (Gnus v5.10.2) XEmacs/21.4 (Common Lisp, linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-MailScanner: Found to be clean X-MailScanner-Information: Please contact the ISP for more information X-archive-position: 4660 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: Nicolas.Kowalski@imag.fr Precedence: bulk X-list: linux-xfs Content-Length: 799 Lines: 26 Hello. Since we started using xfs, all our backups were done using xfsdump on remote tape drives, handled by a SunOS sparc box. Now that this sparc box is dead, I connected the tape drives directly on the linux box containing the XFS filesystems. The xfsdump still works, but now, the dumps are split in multiple files of ~300MB each on the tape drives, which breaks our backup scripts. These expect to find one file per dump (for dump listing purpose). I have read the xfsdump manpage, and especially the '-d' (media file size) option, but I am unable to find the equivalent option value for the '-a' (auto-size, aka write until end of tape) option of the "traditional" dump tool. Do I have to specify an arbitrary high file size ? Any hint about this ? Many thanks in advance. -- Nicolas From owner-linux-xfs@oss.sgi.com Wed Jul 16 16:42:38 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 16 Jul 2003 16:42:52 -0700 (PDT) Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.9/8.12.9) with ESMTP id h6GNgcFl006306 for ; Wed, 16 Jul 2003 16:42:38 -0700 Received: (from xfs@localhost) by oss.sgi.com (8.12.9/8.12.8/Submit) id h6GNgcd5006305 for linux-xfs@oss.sgi.com; Wed, 16 Jul 2003 16:42:38 -0700 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.9/8.12.9) with ESMTP id h6GNgaFp006289 for ; Wed, 16 Jul 2003 16:42:36 -0700 Received: (from apache@localhost) by oss.sgi.com (8.12.9/8.12.8/Submit) id h6GMnxfw004459; Wed, 16 Jul 2003 15:49:59 -0700 Date: Wed, 16 Jul 2003 15:49:59 -0700 Message-Id: <200307162249.h6GMnxfw004459@oss.sgi.com> From: bugzilla-daemon@oss.sgi.com To: xfs-master@oss.sgi.com Subject: [Bug 258] Kernel (smp) lockup: ioctl(XFS_IOC_RESVSP); truncate() on fs with unwritten=1 X-Bugzilla-Reason: AssignedTo X-archive-position: 4661 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: bugzilla-daemon@oss.sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 607 Lines: 23 http://oss.sgi.com/bugzilla/show_bug.cgi?id=258 ------- Additional Comments From mikes@av.com 2003-16-07 15:49 PDT ------- Nathan, I've tried the fix, and it works great. On fs with unwritten=1 it doesn't cause lots of io, and finishes instantly. On fs unwritten=0 does lots of io, but doesn't render system unresponsive for couple hours. My understanding is that in the case when unwritten=0 there is no other way around, but to zero out extents (heavy io). Thanks, -- Mike. ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From owner-linux-xfs@oss.sgi.com Wed Jul 16 17:32:17 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 16 Jul 2003 17:32:36 -0700 (PDT) Received: from tolkor.sgi.com (tolkor.sgi.com [198.149.18.6]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h6H0WGFl008126 for ; Wed, 16 Jul 2003 17:32:16 -0700 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by tolkor.sgi.com (8.12.9/8.12.2/linux-outbound_gateway-1.2) with SMTP id h6H0odmO029653 for ; Wed, 16 Jul 2003 19:50:40 -0500 Received: from omen.melbourne.sgi.com (omen.melbourne.sgi.com [134.14.55.139]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id KAA16542; Thu, 17 Jul 2003 10:32:06 +1000 Received: from melbourne.sgi.com (localhost [127.0.0.1]) by omen.melbourne.sgi.com (SGI-8.12.5/8.12.5) with SMTP id h6H0W4P4317394; Thu, 17 Jul 2003 10:32:05 +1000 (EST) Date: Thu, 17 Jul 2003 10:32:03 +1000 From: Ivan Rayner To: Nicolas Kowalski Cc: linux-xfs@oss.sgi.com Subject: Re: maximize xfsdump media file size Message-Id: <20030717103203.01b12174.ivanr@sgi.com> In-Reply-To: References: Organization: SGI X-Mailer: Sylpheed version 0.9.3claws (GTK+ 1.2.10; mips-sgi-irix6.5) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 4662 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: ivanr@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 1088 Lines: 28 On Wed, 16 Jul 2003 13:42:08 +0200, Nicolas Kowalski wrote: > Since we started using xfs, all our backups were done using xfsdump on > remote tape drives, handled by a SunOS sparc box. Now that this sparc > box is dead, I connected the tape drives directly on the linux box > containing the XFS filesystems. > > The xfsdump still works, but now, the dumps are split in multiple > files of ~300MB each on the tape drives, which breaks our backup > scripts. These expect to find one file per dump (for dump listing > purpose). > > I have read the xfsdump manpage, and especially the '-d' (media file > size) option, but I am unable to find the equivalent option value for > the '-a' (auto-size, aka write until end of tape) option of the > "traditional" dump tool. Do I have to specify an arbitrary high file > size ? > > Any hint about this ? Use 'xfsdump -S ...' Basically this sets the media file size to int64 max. The option is not documented, as breaking a dump into multiple media files is normally a good thing so the -d option is preferred, but what do I care ... :) Ivan From owner-linux-xfs@oss.sgi.com Thu Jul 17 00:17:52 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 17 Jul 2003 00:18:18 -0700 (PDT) Received: from imag.imag.fr (imag.imag.fr [129.88.30.1]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h6H7HoFl021235 for ; Thu, 17 Jul 2003 00:17:51 -0700 Received: from mail-veri.imag.fr (pave.imag.fr [129.88.43.12]) by imag.imag.fr (8.12.9/8.12.9) with ESMTP id h6H7HjjW006899 for ; Thu, 17 Jul 2003 09:17:45 +0200 (CEST) Received: from astazou.imag.fr ([129.88.43.102] helo=astazou.imag.fr.imag.fr ident=kowalski) by mail-veri.imag.fr with esmtp (Exim 3.35 #1 (Debian)) id 19d31N-0003xq-00 for ; Thu, 17 Jul 2003 09:17:45 +0200 To: linux-xfs@oss.sgi.com Subject: Re: maximize xfsdump media file size References: <20030717103203.01b12174.ivanr@sgi.com> From: Nicolas Kowalski Date: Thu, 17 Jul 2003 09:17:44 +0200 In-Reply-To: <20030717103203.01b12174.ivanr@sgi.com> (Ivan Rayner's message of "Thu, 17 Jul 2003 10:32:03 +1000") Message-ID: User-Agent: Gnus/5.1002 (Gnus v5.10.2) XEmacs/21.4 (Common Lisp, linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-MailScanner: Found to be clean X-MailScanner-Information: Please contact the ISP for more information X-archive-position: 4663 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: Nicolas.Kowalski@imag.fr Precedence: bulk X-list: linux-xfs Content-Length: 758 Lines: 24 Ivan Rayner writes: > On Wed, 16 Jul 2003 13:42:08 +0200, Nicolas Kowalski wrote: >> I have read the xfsdump manpage, and especially the '-d' (media file >> size) option, but I am unable to find the equivalent option value for >> the '-a' (auto-size, aka write until end of tape) option of the >> "traditional" dump tool. Do I have to specify an arbitrary high file >> size ? >> >> Any hint about this ? > > Use 'xfsdump -S ...' > > Basically this sets the media file size to int64 max. The option is not > documented, as breaking a dump into multiple media files is normally a > good thing so the -d option is preferred, but what do I care ... :) This is exactly what I was searching for :-). Thanks a lot ! Best regards. -- Nicolas From owner-linux-xfs@oss.sgi.com Thu Jul 17 08:42:41 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 17 Jul 2003 08:42:46 -0700 (PDT) Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.9/8.12.9) with ESMTP id h6HFgfFl010336 for ; Thu, 17 Jul 2003 08:42:41 -0700 Received: (from xfs@localhost) by oss.sgi.com (8.12.9/8.12.8/Submit) id h6HFgfiw010335 for linux-xfs@oss.sgi.com; Thu, 17 Jul 2003 08:42:41 -0700 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.9/8.12.9) with ESMTP id h6HFgdFn010320 for ; Thu, 17 Jul 2003 08:42:39 -0700 Received: (from apache@localhost) by oss.sgi.com (8.12.9/8.12.8/Submit) id h6HEnPK8008599; Thu, 17 Jul 2003 07:49:25 -0700 Date: Thu, 17 Jul 2003 07:49:25 -0700 Message-Id: <200307171449.h6HEnPK8008599@oss.sgi.com> From: bugzilla-daemon@oss.sgi.com To: xfs-master@oss.sgi.com Subject: [Bug 263] unwritten extents hook in "TAKE - xfs iocore rework" breaks db related executable X-Bugzilla-Reason: AssignedTo X-archive-position: 4664 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: bugzilla-daemon@oss.sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 680 Lines: 22 http://oss.sgi.com/bugzilla/show_bug.cgi?id=263 ------- Additional Comments From erik.habbinga@hp.com 2003-17-07 07:49 PDT ------- I didn't have kdb enabled in the past, but I do now. I also have a newer version of XFS from CVS. After three complete SPEC SFS NFS tests, I haven't seen the lockup problem. I definitely had problems with the XFS CVS from April 15th, so something might have been fixed between then and June 16th (my latest XFS CVS code drop). I'll keep running the tests through the weekend and report on my results on Monday. Erik ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From owner-linux-xfs@oss.sgi.com Thu Jul 17 10:19:33 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 17 Jul 2003 10:19:47 -0700 (PDT) Received: from commvault.com (cvnet.commvault.com [208.253.164.3]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h6HHJVFl013645 for ; Thu, 17 Jul 2003 10:19:32 -0700 Received: from cvsi-nt.gp.cv.commvault.com by commvault.com (SMI-8.6/SMI-SVR4) id NAA17798; Thu, 17 Jul 2003 13:19:28 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 MIME-Version: 1.0 Subject: What is the expansion for xfs? Date: Thu, 17 Jul 2003 13:19:27 -0400 Message-ID: <9654E3A1BAFDD61183B600508B6C20972B51F1@cvsi-ntex2k> Thread-Topic: What is the expansion for xfs? Thread-Index: AcNMh5NOIRY4x5k+Tzap10Nnpzb9zA== From: "Raghuprasad Govindarao" To: Content-Disposition: inline Content-Type: text/plain Content-Transfer-Encoding: 7bit X-archive-position: 4665 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: grprasad1@commvault.com Precedence: bulk X-list: linux-xfs Content-Length: 204 Lines: 13 Hi, What is the expansion for XFS? Is it Extended File System or something like that? Raghu Raghuprasad CommVault Systems Inc. 732 870 4932 grprasad1@commvault.com [[HTML alternate version deleted]] From owner-linux-xfs@oss.sgi.com Fri Jul 18 00:05:23 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 18 Jul 2003 00:05:47 -0700 (PDT) Received: from imag.imag.fr (imag.imag.fr [129.88.30.1]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h6I75MFl023411 for ; Fri, 18 Jul 2003 00:05:23 -0700 Received: from mail-veri.imag.fr (pave.imag.fr [129.88.43.12]) by imag.imag.fr (8.12.9/8.12.9) with ESMTP id h6I75H5d020163 for ; Fri, 18 Jul 2003 09:05:17 +0200 (CEST) Received: from astazou.imag.fr ([129.88.43.102] helo=astazou.imag.fr.imag.fr ident=kowalski) by mail-veri.imag.fr with esmtp (Exim 3.35 #1 (Debian)) id 19dPIr-000097-00 for ; Fri, 18 Jul 2003 09:05:17 +0200 To: linux-xfs@oss.sgi.com Subject: xfsdump/xfsrestore confusion From: Nicolas Kowalski Date: Fri, 18 Jul 2003 09:05:17 +0200 Message-ID: User-Agent: Gnus/5.1002 (Gnus v5.10.2) XEmacs/21.4 (Common Lisp, linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-MailScanner: Found to be clean X-MailScanner-Information: Please contact the ISP for more information X-archive-position: 4666 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: Nicolas.Kowalski@imag.fr Precedence: bulk X-list: linux-xfs Content-Length: 4455 Lines: 103 Hello. I am still confused about the behaviour of xfsdump and xfsrestore since we connected our SCSI tape drives directly on the fileserver, instead of using a remote sparc box. Last night, I started an incremental backup for the /export/home filesystem. There was a failure about xfsdq (problem of PATH corrected now), but I think this is not the point. Here is the log file: [begin logfile] Filesystem: /export/home /sbin/xfsdump: using scsi tape (drive_scsitape) strategy /sbin/xfsdump: version 2.2.12 (dump format 3.0) - Running single-threaded /sbin/xfsdump: saving user quota information for: /export/home sh: xfsdq: command not found /sbin/xfsdump: ERROR: xfsdq failed with exit status: 32512 /sbin/xfsdump: ERROR: failed to save user quota information, continuing /sbin/xfsdump: level 2 incremental dump of gaspard:/export/home based on level 1 dump begun Wed Jul 16 16:51:44 2003 /sbin/xfsdump: dump date: Thu Jul 17 23:00:01 2003 /sbin/xfsdump: session id: 4ace2eb4-7fe0-46d2-a38a-9c341e12b0d0 /sbin/xfsdump: session label: "/export/home" /sbin/xfsdump: ino map phase 1: skipping (no subtrees specified) /sbin/xfsdump: ino map phase 2: constructing initial dump list /sbin/xfsdump: ino map phase 3: pruning unneeded subtrees /sbin/xfsdump: status at 23:06:04: 363 seconds elapsed /sbin/xfsdump: ino map phase 4: estimating dump size /sbin/xfsdump: ino map phase 5: skipping (only one dump stream) /sbin/xfsdump: ino map construction complete /sbin/xfsdump: estimated dump size: 4793212544 bytes /sbin/xfsdump: preparing drive /sbin/xfsdump: WARNING: media may contain data. Overwrite option specified /sbin/xfsdump: creating dump session media file 0 (media 0, file 0) /sbin/xfsdump: dumping ino map /sbin/xfsdump: dumping directories /sbin/xfsdump: dumping non-directory files /sbin/xfsdump: status at 23:10:11: 2657/26281 files dumped, 21.7% complete, 610 seconds elapsed /sbin/xfsdump: status at 23:15:04: 15104/26281 files dumped, 57.9% complete, 903 seconds elapsed /sbin/xfsdump: status at 23:20:23: 25823/26281 files dumped, 95.2% complete, 1222 seconds elapsed /sbin/xfsdump: ending media file /sbin/xfsdump: media file size 4758437888 bytes /sbin/xfsdump: dumping session inventory /sbin/xfsdump: beginning inventory media file /sbin/xfsdump: media file 1 (media 0, file 1) /sbin/xfsdump: ending inventory media file /sbin/xfsdump: inventory media file size 2097152 bytes /sbin/xfsdump: writing stream terminator /sbin/xfsdump: beginning media stream terminator /sbin/xfsdump: media file 2 (media 0, file 2) /sbin/xfsdump: ending media stream terminator /sbin/xfsdump: media stream terminator size 1048576 bytes /sbin/xfsdump: dump size (non-dir files) : 4726257944 bytes /sbin/xfsdump: dump complete: 1261 seconds elapsed /sbin/xfsdump: Dump Status: SUCCESS [end logfile] This dump was appended to previous ones, at tape position 15. This morning, I tried to view the contents of this dump, so I did: gaspard:~# mt -f /dev/nst0 asf 15 gaspard:~# /sbin/xfsrestore -t -f /dev/nst0 -F /sbin/xfsrestore: using scsi tape (drive_scsitape) strategy /sbin/xfsrestore: version 2.2.12 (dump format 3.0) - Running single-threaded /sbin/xfsrestore: searching media for dump /sbin/xfsrestore: preparing drive /sbin/xfsrestore: examining media file 1 /sbin/xfsrestore: dump description: /sbin/xfsrestore: hostname: gaspard /sbin/xfsrestore: mount point: /export/home /sbin/xfsrestore: volume: /dev/sdc1 /sbin/xfsrestore: session time: Thu Jul 17 23:00:01 2003 /sbin/xfsrestore: level: 2 /sbin/xfsrestore: session label: "/export/home" /sbin/xfsrestore: media label: "dlt7000" /sbin/xfsrestore: file system id: ad42b81a-a874-4ee0-a37e-c76eecc24cde /sbin/xfsrestore: session id: 4ace2eb4-7fe0-46d2-a38a-9c341e12b0d0 /sbin/xfsrestore: media id: 0666aaec-d96a-4715-8c50-c0bfce24739b /sbin/xfsrestore: using online session inventory /sbin/xfsrestore: searching media for directory dump /sbin/xfsrestore: rewinding /sbin/xfsrestore: examining media file 0 /sbin/xfsrestore: inventory session uuid (4ace2eb4-7fe0-46d2-a38a-9c341e12b0d0) does not match the media header's session uuid (e58f7869-908a-4ff0-b1c4-d02dbc02 1be2) /sbin/xfsrestore: table of contents display complete: 207 seconds elapsed /sbin/xfsrestore: Restore Status: SUCCESS So obiously, something is wrong. xfsdump told me the backup was successfull, but I am unable to restore any file from it. Any help would be greatly appreciated ! Many thanks in advance. -- Nicolas From owner-linux-xfs@oss.sgi.com Fri Jul 18 02:48:14 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 18 Jul 2003 02:48:31 -0700 (PDT) Received: from imag.imag.fr (imag.imag.fr [129.88.30.1]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h6I9mCFl032013 for ; Fri, 18 Jul 2003 02:48:13 -0700 Received: from mail-veri.imag.fr (pave.imag.fr [129.88.43.12]) by imag.imag.fr (8.12.9/8.12.9) with ESMTP id h6I9mAb5020943 for ; Fri, 18 Jul 2003 11:48:10 +0200 (CEST) Received: from astazou.imag.fr ([129.88.43.102] helo=astazou.imag.fr.imag.fr ident=kowalski) by mail-veri.imag.fr with esmtp (Exim 3.35 #1 (Debian)) id 19dRqU-0003xU-00 for ; Fri, 18 Jul 2003 11:48:10 +0200 To: linux-xfs@oss.sgi.com Subject: Re: xfsdump/xfsrestore confusion References: From: Nicolas Kowalski Date: Fri, 18 Jul 2003 11:48:10 +0200 In-Reply-To: (Nicolas Kowalski's message of "Fri, 18 Jul 2003 09:05:17 +0200") Message-ID: User-Agent: Gnus/5.1002 (Gnus v5.10.2) XEmacs/21.4 (Common Lisp, linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-MailScanner: Found to be clean X-MailScanner-Information: Please contact the ISP for more information X-archive-position: 4667 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: Nicolas.Kowalski@imag.fr Precedence: bulk X-list: linux-xfs Content-Length: 396 Lines: 16 Nicolas Kowalski writes: > I am still confused about the behaviour of xfsdump and xfsrestore > since we connected our SCSI tape drives directly on the fileserver, > instead of using a remote sparc box. [...] This is not anymore relevant. I restarted an old sparc box which handle my SCSI tape drives smoothly. All works fine now. Sorry for the noise. -- Nicolas From owner-linux-xfs@oss.sgi.com Fri Jul 18 08:28:38 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 18 Jul 2003 08:29:03 -0700 (PDT) Received: from tolkor.sgi.com (tolkor.sgi.com [198.149.18.6]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h6IFSbFl003478 for ; Fri, 18 Jul 2003 08:28:38 -0700 Received: from nodin.corp.sgi.com (fddi-nodin.corp.sgi.com [198.29.75.193]) by tolkor.sgi.com (8.12.9/8.12.9/linux-outbound_gateway-1.1) with ESMTP id h6IFl8aI029583 for ; Fri, 18 Jul 2003 10:47:08 -0500 Received: from sgi.com (syntegra.americas.sgi.com [128.162.232.81]) by nodin.corp.sgi.com (8.12.9/8.11.4/nodin-1.0) with ESMTP id h6IFR1gw6194935; Fri, 18 Jul 2003 08:27:06 -0700 (PDT) Message-ID: <3F1811B7.1060500@sgi.com> Date: Fri, 18 Jul 2003 10:26:47 -0500 From: Mandy Kirkconnell User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.0) Gecko/20020623 Debian/1.0.0-0.woody.1 MIME-Version: 1.0 To: Nicolas Kowalski CC: linux-xfs@oss.sgi.com Subject: Re: xfsdump/xfsrestore confusion References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 4668 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: alkirkco@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 6213 Lines: 138 Nicolas Kowalski wrote: > Hello. > > I am still confused about the behaviour of xfsdump and xfsrestore > since we connected our SCSI tape drives directly on the fileserver, > instead of using a remote sparc box. > > Last night, I started an incremental backup for the /export/home > filesystem. There was a failure about xfsdq (problem of PATH corrected > now), but I think this is not the point. Here is the log file: > > > [begin logfile] > > Filesystem: /export/home > /sbin/xfsdump: using scsi tape (drive_scsitape) strategy > /sbin/xfsdump: version 2.2.12 (dump format 3.0) - Running single-threaded > /sbin/xfsdump: saving user quota information for: /export/home > sh: xfsdq: command not found > /sbin/xfsdump: ERROR: xfsdq failed with exit status: 32512 > /sbin/xfsdump: ERROR: failed to save user quota information, continuing > /sbin/xfsdump: level 2 incremental dump of gaspard:/export/home based on level 1 dump begun Wed Jul 16 16:51:44 2003 > /sbin/xfsdump: dump date: Thu Jul 17 23:00:01 2003 > /sbin/xfsdump: session id: 4ace2eb4-7fe0-46d2-a38a-9c341e12b0d0 > /sbin/xfsdump: session label: "/export/home" > /sbin/xfsdump: ino map phase 1: skipping (no subtrees specified) > /sbin/xfsdump: ino map phase 2: constructing initial dump list > /sbin/xfsdump: ino map phase 3: pruning unneeded subtrees > /sbin/xfsdump: status at 23:06:04: 363 seconds elapsed > /sbin/xfsdump: ino map phase 4: estimating dump size > /sbin/xfsdump: ino map phase 5: skipping (only one dump stream) > /sbin/xfsdump: ino map construction complete > /sbin/xfsdump: estimated dump size: 4793212544 bytes > /sbin/xfsdump: preparing drive > /sbin/xfsdump: WARNING: media may contain data. Overwrite option specified > /sbin/xfsdump: creating dump session media file 0 (media 0, file 0) > /sbin/xfsdump: dumping ino map > /sbin/xfsdump: dumping directories > /sbin/xfsdump: dumping non-directory files > /sbin/xfsdump: status at 23:10:11: 2657/26281 files dumped, 21.7% complete, 610 seconds elapsed > /sbin/xfsdump: status at 23:15:04: 15104/26281 files dumped, 57.9% complete, 903 seconds elapsed > /sbin/xfsdump: status at 23:20:23: 25823/26281 files dumped, 95.2% complete, 1222 seconds elapsed > /sbin/xfsdump: ending media file > /sbin/xfsdump: media file size 4758437888 bytes > /sbin/xfsdump: dumping session inventory > /sbin/xfsdump: beginning inventory media file > /sbin/xfsdump: media file 1 (media 0, file 1) > /sbin/xfsdump: ending inventory media file > /sbin/xfsdump: inventory media file size 2097152 bytes > /sbin/xfsdump: writing stream terminator > /sbin/xfsdump: beginning media stream terminator > /sbin/xfsdump: media file 2 (media 0, file 2) > /sbin/xfsdump: ending media stream terminator > /sbin/xfsdump: media stream terminator size 1048576 bytes > /sbin/xfsdump: dump size (non-dir files) : 4726257944 bytes > /sbin/xfsdump: dump complete: 1261 seconds elapsed > /sbin/xfsdump: Dump Status: SUCCESS > > [end logfile] > > > This dump was appended to previous ones, at tape position 15. > This morning, I tried to view the contents of this dump, so I did: > > gaspard:~# mt -f /dev/nst0 asf 15 > gaspard:~# /sbin/xfsrestore -t -f /dev/nst0 -F > /sbin/xfsrestore: using scsi tape (drive_scsitape) strategy > /sbin/xfsrestore: version 2.2.12 (dump format 3.0) - Running single-threaded > /sbin/xfsrestore: searching media for dump > /sbin/xfsrestore: preparing drive > /sbin/xfsrestore: examining media file 1 > /sbin/xfsrestore: dump description: > /sbin/xfsrestore: hostname: gaspard > /sbin/xfsrestore: mount point: /export/home > /sbin/xfsrestore: volume: /dev/sdc1 > /sbin/xfsrestore: session time: Thu Jul 17 23:00:01 2003 > /sbin/xfsrestore: level: 2 > /sbin/xfsrestore: session label: "/export/home" > /sbin/xfsrestore: media label: "dlt7000" > /sbin/xfsrestore: file system id: ad42b81a-a874-4ee0-a37e-c76eecc24cde > /sbin/xfsrestore: session id: 4ace2eb4-7fe0-46d2-a38a-9c341e12b0d0 > /sbin/xfsrestore: media id: 0666aaec-d96a-4715-8c50-c0bfce24739b > /sbin/xfsrestore: using online session inventory > /sbin/xfsrestore: searching media for directory dump > /sbin/xfsrestore: rewinding > /sbin/xfsrestore: examining media file 0 > /sbin/xfsrestore: inventory session uuid (4ace2eb4-7fe0-46d2-a38a-9c341e12b0d0) > does not match the media header's session uuid (e58f7869-908a-4ff0-b1c4-d02dbc02 > 1be2) > /sbin/xfsrestore: table of contents display complete: 207 seconds elapsed > /sbin/xfsrestore: Restore Status: SUCCESS > > So obiously, something is wrong. xfsdump told me the backup was > successfull, but I am unable to restore any file from it. > Hi Nicolas, I'm battling with this one right now. It looks like there's a problem in the way xfsdump appends dumps to an existing dump session on tape. I have only been experimenting with local tape drives so far (drive_scsitape strategy), but it sounds like you didn't see this problem when you were using remote tape drives (drive_minrmt strategy). Interesting.. something to look into. It looks like something strange is going on with the media files between the different dump sessions. The numbering seems to get messed up and xfsrestore can't find the proper media file. For example, my first dump session uses media files 0-2 and my second dump session uses media files 2-4. xfsresotore can restore the first session ok, but when it reaches the second session, it automatically advances to media file 3 (rather than 2). The data at media file 3 is not the beginning of a dump, so xfsrestore advances to media file 4. The data at media file 4 is also not the beginning of a dump session so xfsrestore advances to the end of data, then rewinds and starts searching forward from the beginning of the tape. This process ends up looping forever (0.. 1.. 3.. 4.. rewind) printing the message you saw on evry mismatch (and never finding media file 2!!): > /sbin/xfsrestore: inventory session uuid (4ace2eb4-7fe0-46d2-a38a-9c341e12b0d0) > does not match the media header's session uuid (e58f7869-908a-4ff0-b1c4-d02dbc02 > 1be2) I'm stepping through gdb now, I'll let you know when I have more info. Mandy -- Mandy Kirkconnell SGI, Storage Software Engineer alkirkco@sgi.com 651-683-3422 From owner-linux-xfs@oss.sgi.com Sun Jul 20 20:58:42 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 20 Jul 2003 20:59:01 -0700 (PDT) Received: from zok.sgi.com (zok.sgi.com [204.94.215.101]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h6L3wfFl002539 for ; Sun, 20 Jul 2003 20:58:42 -0700 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.54.149]) by zok.sgi.com (8.12.9/8.12.9/linux-outbound_gateway-1.1) with ESMTP id h6L3wZq0014333 for ; Sun, 20 Jul 2003 20:58:36 -0700 Received: from snort.melbourne.sgi.com (localhost [127.0.0.1]) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id h6L3wXJA4878805; Mon, 21 Jul 2003 13:58:33 +1000 (EST) Received: (from nathans@localhost) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id h6L3wW6V3910058; Mon, 21 Jul 2003 13:58:32 +1000 (EST) Date: Mon, 21 Jul 2003 13:58:32 +1000 (EST) From: Nathan Scott Message-Id: <200307210358.h6L3wW6V3910058@snort.melbourne.sgi.com> To: linux-xfs@oss.sgi.com, agruen@suse.de Subject: TAKE - attr updates X-archive-position: 4669 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: nathans@snort.melbourne.sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 1212 Lines: 44 Squash a warning with ia64 patches applied, building on ia32. Date: Sun Jul 20 18:08:52 PDT 2003 Workarea: snort.melbourne.sgi.com:/home/nathans/2.4.x-xfs The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: xfs-linux:slinx:153810a linux/fs/xfs/pagebuf/page_buf.c - 1.128 An attr update from Andreas - emphasis on improved handling of special characters, and creates a little library for helper functions. Date: Sun Jul 20 20:56:40 PDT 2003 Workarea: snort.melbourne.sgi.com:/home/nathans/2.4.x-xfs The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: xfs-cmds:slinx:153813a cmd/attr/include/misc.h - 1.1 cmd/attr/libmisc/unquote.c - 1.1 cmd/attr/libmisc/quote.c - 1.1 cmd/attr/libmisc/high_water_alloc.c - 1.1 cmd/attr/libmisc/Makefile - 1.1 cmd/attr/Makefile - 1.14 cmd/attr/VERSION - 1.35 cmd/attr/doc/CHANGES - 1.44 cmd/attr/include/Makefile - 1.11 cmd/attr/include/builddefs.in - 1.22 cmd/attr/debian/changelog - 1.38 cmd/attr/test/run - 1.4 cmd/attr/test/attr.test - 1.6 cmd/attr/setfattr/setfattr.c - 1.13 cmd/attr/setfattr/Makefile - 1.6 cmd/attr/getfattr/Makefile - 1.7 cmd/attr/getfattr/getfattr.c - 1.20 From owner-linux-xfs@oss.sgi.com Mon Jul 21 09:53:43 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 21 Jul 2003 09:54:03 -0700 (PDT) Received: from beta.dmz-eu.st.com (beta.dmz-eu.st.com [164.129.1.35]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h6LGrWFl000610 for ; Mon, 21 Jul 2003 09:53:32 -0700 Received: from zeta.dmz-eu.st.com (ns2.st.com [164.129.230.9]) by beta.dmz-eu.st.com (STMicroelectronics) with SMTP id ADC22DB4D for ; Mon, 21 Jul 2003 16:20:04 +0000 (GMT) Received: by zeta.dmz-eu.st.com (STMicroelectronics, from userid 0) id 8C0C26176; Mon, 21 Jul 2003 16:20:04 +0000 (GMT) Received: from dlx101.dlh.st.com (localhost [127.0.0.1]) by zeta.dmz-eu.st.com (STMicroelectronics) with ESMTP id B52071849 for ; Mon, 21 Jul 2003 16:20:03 +0000 (GMT) Received: from localhost (root@localhost) by dlx101.dlh.st.com (8.9.3 (PHNE_25183+JAGae58098)/8.9.3) with ESMTP id VAA20075 for ; Mon, 21 Jul 2003 21:50:01 +0530 (IST) From: mahesh.babbar@st.com X-OpenMail-Hops: 1 Date: Mon, 21 Jul 2003 21:50:00 +0530 Message-Id: Subject: XFs stability MIME-Version: 1.0 To: linux-xfs@oss.sgi.com Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline ;Creation-Date="Mon, 21 Jul 2003 21:47:43 +0530" ;Modification-Date="Mon, 21 Jul 2003 21:49:59 +0530" Content-Transfer-Encoding: 7bit X-archive-position: 4670 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: mahesh.babbar@st.com Precedence: bulk X-list: linux-xfs Content-Length: 256 Lines: 13 Hi , I am totally new to XFs world so please bear with me for my ignorance. My query is how stable xfs is ? Or let's say which version of it is most stable. Any hint is welcome. TIA Mahesh From owner-linux-xfs@oss.sgi.com Mon Jul 21 09:58:53 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 21 Jul 2003 09:58:57 -0700 (PDT) Received: from burgers.bubbanfriends.org (IDENT:postfix@12-223-205-22.client.insightbb.com [12.223.205.22]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h6LGwqFl002964 for ; Mon, 21 Jul 2003 09:58:52 -0700 Received: from localhost (unknown [127.0.0.1]) by burgers.bubbanfriends.org (Postfix) with ESMTP id C83FD3000C88; Mon, 21 Jul 2003 11:58:54 -0500 (EST) Received: by burgers.bubbanfriends.org (Postfix, from userid 500) id A84FD3000C85; Mon, 21 Jul 2003 11:58:51 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by burgers.bubbanfriends.org (Postfix) with ESMTP id 8101E77A98; Mon, 21 Jul 2003 11:58:51 -0500 (EST) Date: Mon, 21 Jul 2003 11:58:51 -0500 (EST) From: Mike Burger To: mahesh.babbar@st.com Cc: linux-xfs@oss.sgi.com Subject: Re: XFs stability In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by AMaViS new-20020517 X-archive-position: 4671 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: mburger@bubbanfriends.org Precedence: bulk X-list: linux-xfs Content-Length: 746 Lines: 35 FWIW, I've been running XFS on my server (not a very busy server, granted) for a couple of years, now, and haven't had any problems. On Mon, 21 Jul 2003 mahesh.babbar@st.com wrote: > Hi , > > I am totally new to XFs world so please bear with me for my ignorance. > > My query is how stable xfs is ? Or let's say which version of it is > most stable. > > Any hint is welcome. > > TIA > > Mahesh > > -- Mike Burger http://www.bubbanfriends.org Visit the Dog Pound II BBS telnet://dogpound2.citadel.org or http://dogpound2.citadel.org:2000 To be notified of updates to the web site, send a message to: site-update-request@bubbanfriends.org with a message of: subscribe From owner-linux-xfs@oss.sgi.com Mon Jul 21 10:14:13 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 21 Jul 2003 10:14:18 -0700 (PDT) Received: from mpls-qmqp-04.inet.qwest.net (mpls-qmqp-04.inet.qwest.net [63.231.195.115]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h6LHECFl005854 for ; Mon, 21 Jul 2003 10:14:13 -0700 Received: (qmail 89418 invoked by uid 0); 21 Jul 2003 17:14:10 -0000 Received: from mpls-pop-12.inet.qwest.net (63.231.195.12) by mpls-qmqp-04.inet.qwest.net with QMQP; 21 Jul 2003 17:14:10 -0000 Received: from unknown (HELO software1.logiplex.internal) (65.102.60.133) by mpls-pop-12.inet.qwest.net with SMTP; 21 Jul 2003 17:14:09 -0000 Date: 21 Jul 2003 10:14:09 -0700 Message-Id: <1058807648.2717.62.camel@software1.logiplex.internal> From: "Cliff Wells" To: mahesh.babbar@ST.COM Cc: linux-xfs@oss.sgi.com Subject: Re: XFs stability In-Reply-To: References: Content-Type: text/plain Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.3 Content-Transfer-Encoding: 7bit X-archive-position: 4672 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: logiplex@qwest.net Precedence: bulk X-list: linux-xfs Content-Length: 985 Lines: 25 On Mon, 2003-07-21 at 09:20, mahesh.babbar@ST.COM wrote: > Hi , > > I am totally new to XFs world so please bear with me for my ignorance. > > My query is how stable xfs is ? Or let's say which version of it is > most stable. I use XFS exclusively on all my machines (at home and work). This includes several desktops, a laptop, a couple of servers and even my firewall. I've been using it for at least two years. No other available filesystem (well, I haven't tested JFS and probably won't until I've got a 64-bit CPU) matches XFS for performance and reliability. EXT3 is a joke (why *does* it need to fsck?), and ReiserFS, although very interesting, has had numerous problems. My PC's have been turned off, crashed, and even attacked by ferrets without losing data or requiring repair. What more can you ask of a filesystem? Regards, -- Cliff Wells, Software Engineer Logiplex Corporation (www.logiplex.net) (503) 978-6726 (800) 735-0555 From owner-linux-xfs@oss.sgi.com Mon Jul 21 12:43:00 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 21 Jul 2003 12:43:03 -0700 (PDT) Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.9/8.12.9) with ESMTP id h6LJh0Fl013499 for ; Mon, 21 Jul 2003 12:43:00 -0700 Received: (from xfs@localhost) by oss.sgi.com (8.12.9/8.12.8/Submit) id h6LJh0bu013498 for linux-xfs@oss.sgi.com; Mon, 21 Jul 2003 12:43:00 -0700 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.9/8.12.9) with ESMTP id h6LJgxFn013483 for ; Mon, 21 Jul 2003 12:42:59 -0700 Received: (from apache@localhost) by oss.sgi.com (8.12.9/8.12.8/Submit) id h6LJDFmr012766; Mon, 21 Jul 2003 12:13:15 -0700 Date: Mon, 21 Jul 2003 12:13:15 -0700 Message-Id: <200307211913.h6LJDFmr012766@oss.sgi.com> From: bugzilla-daemon@oss.sgi.com To: xfs-master@oss.sgi.com Subject: [Bug 263] unwritten extents hook in "TAKE - xfs iocore rework" breaks db related executable X-Bugzilla-Reason: AssignedTo X-archive-position: 4673 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: bugzilla-daemon@oss.sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 790 Lines: 24 http://oss.sgi.com/bugzilla/show_bug.cgi?id=263 erik.habbinga@hp.com changed: What |Removed |Added ---------------------------------------------------------------------------- Status|ASSIGNED |RESOLVED Resolution| |WORKSFORME ------- Additional Comments From erik.habbinga@hp.com 2003-21-07 12:13 PDT ------- Ok, we've run XFS from June 16, 2003 all weekend with both SPEC SFS and iozone, and aren't seeing anymore application lockups. We're satisfied that the patch I listed below is no longer necessary. Sorry for the alarm, and keep up the good work! ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From owner-linux-xfs@oss.sgi.com Mon Jul 21 13:27:56 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 21 Jul 2003 13:28:03 -0700 (PDT) Received: from mail.broadpark.no (mail.broadpark.no [217.13.4.2]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h6LKRtFl016569 for ; Mon, 21 Jul 2003 13:27:56 -0700 Received: from online.no (126.80-202-103.nextgentel.com [80.202.103.126]) by mail.broadpark.no (Postfix) with ESMTP id 4896778CFE for ; Mon, 21 Jul 2003 22:27:46 +0200 (MEST) Message-ID: <3F1C4CB2.849E5E79@online.no> Date: Mon, 21 Jul 2003 22:27:31 +0200 From: Knut J Bjuland X-Mailer: Mozilla 4.8 [en] (X11; U; Linux 2.4.20-18.9XFS1.3.0pre2custom i686) X-Accept-Language: en MIME-Version: 1.0 To: linux-xfs@oss.sgi.com Subject: xfs support in redhat beta sever. Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-archive-position: 4674 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: knutjbj@online.no Precedence: bulk X-list: linux-xfs Content-Length: 420 Lines: 12 xfs file system does not compile with kernel from redhat in severn. Linux-2.4.20-xfs-ntpl .path does not apply cleanly since there has been some change in xfs code in ac kernel. I'll try to update to cvs and repatch it with linux-2.4.20-xfs-nptl....... xfs_syncd.c: In function `syncd': xfs_syncd.c:52: structure has no member named `sigmask_lock' xfs_syncd.c:54: too many arguments to function `recalc_sigpending' From owner-linux-xfs@oss.sgi.com Mon Jul 21 13:53:51 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 21 Jul 2003 13:53:58 -0700 (PDT) Received: from zok.sgi.com (zok.sgi.com [204.94.215.101]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h6LKroFl018700 for ; Mon, 21 Jul 2003 13:53:51 -0700 Received: from flecktone.americas.sgi.com (flecktone.americas.sgi.com [192.48.203.135]) by zok.sgi.com (8.12.9/8.12.9/linux-outbound_gateway-1.1) with ESMTP id h6LKrjq0021817 for ; Mon, 21 Jul 2003 13:53:45 -0700 Received: from poppy-e236.americas.sgi.com (poppy-e236.americas.sgi.com [128.162.236.207]) by flecktone.americas.sgi.com (8.12.9/8.12.9/generic_config-1.2) with ESMTP id h6LKoN3g144779; Mon, 21 Jul 2003 15:50:24 -0500 (CDT) Received: from stout.americas.sgi.com (stout.americas.sgi.com [128.162.232.50]) by poppy-e236.americas.sgi.com (8.12.9/SGI-server-1.8) with ESMTP id h6LKoNYk15158158; Mon, 21 Jul 2003 15:50:23 -0500 (CDT) Subject: Re: xfs support in redhat beta sever. From: Eric Sandeen To: Knut J Bjuland Cc: linux-xfs@oss.sgi.com In-Reply-To: <3F1C4CB2.849E5E79@online.no> References: <3F1C4CB2.849E5E79@online.no> Content-Type: text/plain Organization: Message-Id: <1058820623.10294.187.camel@stout.americas.sgi.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 (1.2.2-5) Date: 21 Jul 2003 15:50:23 -0500 Content-Transfer-Encoding: 7bit X-archive-position: 4675 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: sandeen@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 911 Lines: 25 The xfs code in severn is going to take a bit of work just to compile, red hat has not done any integration work for xfs with the rest of their changes. The fix below is the easy one, o_direct changes are probably trickier (if this kernel is similar to other recent RH kernels I've seen) -Eric On Mon, 2003-07-21 at 15:27, Knut J Bjuland wrote: > xfs file system does not compile with kernel from redhat in severn. > Linux-2.4.20-xfs-ntpl .path does not apply cleanly since there has been > some change in xfs code in ac kernel. I'll try to update to cvs and > repatch it with linux-2.4.20-xfs-nptl....... > > > xfs_syncd.c: In function `syncd': > xfs_syncd.c:52: structure has no member named `sigmask_lock' > xfs_syncd.c:54: too many arguments to function `recalc_sigpending' > -- Eric Sandeen [C]XFS for Linux http://oss.sgi.com/projects/xfs sandeen@sgi.com SGI, Inc. 651-683-3102 From owner-linux-xfs@oss.sgi.com Mon Jul 21 14:06:13 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 21 Jul 2003 14:06:18 -0700 (PDT) Received: from calaf.cns.nyu.edu (CALAF.CNS.NYU.EDU [128.122.112.26]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h6LL6CFl019816 for ; Mon, 21 Jul 2003 14:06:13 -0700 Received: from localhost (fishman@localhost) by calaf.cns.nyu.edu (8.11.7+Sun/8.11.6) with ESMTP id h6LL69a28716 for ; Mon, 21 Jul 2003 17:06:09 -0400 (EDT) Date: Mon, 21 Jul 2003 17:06:09 -0400 (EDT) From: Josh Fishman To: Subject: User processes run out of memory on XFS directory In-Reply-To: <1058820623.10294.187.camel@stout.americas.sgi.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 4676 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: fishman@cns.nyu.edu Precedence: bulk X-list: linux-xfs Content-Length: 875 Lines: 25 Hi List! I couldn't find this in the archive; sorry if it's already been discussed to death. I'm trying to read a couple of XFS partitions that I recovered from a dead SGI, dd'd to a Linux disk, and am now trying to mount using loop-back. One partition-image mounts fine, it seems, but has a subdirectory that I can't list. "ls" slowly grows larger in memory until it's eaten all 1024 MB of RAM on the machine, then it dies with an "out of memory" error. The other partition-image won't mount, but I haven't tried the "nouuid" trick yet, so I won't bother y'all with it just yet. Back to the Unlistable Image: I'm not getting any bad kernel or syslog messages, dmesg isn't informative, and I've compiled in the "debug" flags for XFS. I'm using linux-2.4.21 with: snapshot-xfs-2.4.21-2003-07-07_02:01_UTC with ACLs, realtime, debug enabled Any ideas? Thanks, ---Josh From owner-linux-xfs@oss.sgi.com Mon Jul 21 14:10:39 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 21 Jul 2003 14:10:43 -0700 (PDT) Received: from mail.modwest.com (marshall.modwest.com [216.129.251.30]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h6LLAcFl020473 for ; Mon, 21 Jul 2003 14:10:39 -0700 Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.modwest.com (Postfix) with ESMTP id 0E9BE40EB3E3; Mon, 21 Jul 2003 15:10:38 -0600 (MDT) Received: from mail.modwest.com ([127.0.0.1]) by localhost (marshall.modwest.com [127.0.0.1]) (amavisd-new) with ESMTP id 31875-08; Mon, 21 Jul 2003 15:10:37 -0000 (MDT) Received: from [10.0.0.131] (unknown [69.24.111.150]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (No client certificate requested) by mail.modwest.com (Postfix) with ESMTP id 9B88A40F4D90; Mon, 21 Jul 2003 15:10:37 -0600 (MDT) Date: Mon, 21 Jul 2003 15:12:03 -0600 From: Michael Loftis To: Josh Fishman , linux-xfs@oss.sgi.com Subject: Re: User processes run out of memory on XFS directory Message-ID: <8046546.1058800323@[10.0.0.131]> In-Reply-To: References: X-Mailer: Mulberry/3.0.3 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Virus-Scanned: by amavisd-new amavisd-new-20020630 X-archive-position: 4677 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: mloftis@wgops.com Precedence: bulk X-list: linux-xfs Content-Length: 1199 Lines: 48 'ls' builds an in-memory image of all files so it can sort it try find . -print or find . -ls instead. --On Monday, July 21, 2003 17:06 -0400 Josh Fishman wrote: > > Hi List! > > I couldn't find this in the archive; sorry if it's already been discussed > to death. I'm trying to read a couple of XFS partitions that I recovered > from a dead SGI, dd'd to a Linux disk, and am now trying to mount using > loop-back. > > One partition-image mounts fine, it seems, but has a subdirectory that I > can't list. "ls" slowly grows larger in memory until it's eaten all 1024 > MB of RAM on the machine, then it dies with an "out of memory" error. > > The other partition-image won't mount, but I haven't tried the "nouuid" > trick yet, so I won't bother y'all with it just yet. > > Back to the Unlistable Image: I'm not getting any bad kernel or syslog > messages, dmesg isn't informative, and I've compiled in the "debug" flags > for XFS. I'm using linux-2.4.21 with: > > snapshot-xfs-2.4.21-2003-07-07_02:01_UTC with ACLs, realtime, debug > enabled > > Any ideas? > > Thanks, ---Josh > > -- Michael Loftis Modwest Sr. Systems Administrator Powerful, Affordable Web Hosting From owner-linux-xfs@oss.sgi.com Mon Jul 21 14:17:51 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 21 Jul 2003 14:18:10 -0700 (PDT) Received: from tolkor.sgi.com (tolkor.sgi.com [198.149.18.6]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h6LLHpFl021329 for ; Mon, 21 Jul 2003 14:17:51 -0700 Received: from flecktone.americas.sgi.com (flecktone.americas.sgi.com [192.48.203.135]) by tolkor.sgi.com (8.12.9/8.12.9/linux-outbound_gateway-1.1) with ESMTP id h6LLaYsR023506 for ; Mon, 21 Jul 2003 16:36:34 -0500 Received: from maine.americas.sgi.com (maine.americas.sgi.com [128.162.232.87]) by flecktone.americas.sgi.com (8.12.9/8.12.9/generic_config-1.2) with ESMTP id h6LLHj3g159692; Mon, 21 Jul 2003 16:17:45 -0500 (CDT) Received: from nstraz by maine.americas.sgi.com with local (Exim 3.36 #1 (Debian)) id 19ei2S-0002um-00; Mon, 21 Jul 2003 16:17:44 -0500 Date: Mon, 21 Jul 2003 16:17:44 -0500 From: Nathan Straz To: Josh Fishman Cc: linux-xfs@oss.sgi.com Subject: Re: User processes run out of memory on XFS directory Message-ID: <20030721211744.GE31797@sgi.com> Mail-Followup-To: Josh Fishman , linux-xfs@oss.sgi.com References: <1058820623.10294.187.camel@stout.americas.sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.3i X-archive-position: 4678 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: nstraz@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 562 Lines: 11 On Mon, Jul 21, 2003 at 05:06:09PM -0400, Josh Fishman wrote: > One partition-image mounts fine, it seems, but has a subdirectory that I > can't list. "ls" slowly grows larger in memory until it's eaten all 1024 > MB of RAM on the machine, then it dies with an "out of memory" error. What is the output of xfs_info on the mounted file system? -- Nate Straz nstraz@sgi.com sgi, inc http://www.sgi.com/ Linux Test Project http://ltp.sf.net/ From owner-linux-xfs@oss.sgi.com Mon Jul 21 14:26:04 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 21 Jul 2003 14:26:20 -0700 (PDT) Received: from zok.sgi.com (zok.sgi.com [204.94.215.101]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h6LLQ4Fl022220 for ; Mon, 21 Jul 2003 14:26:04 -0700 Received: from flecktone.americas.sgi.com (flecktone.americas.sgi.com [192.48.203.135]) by zok.sgi.com (8.12.9/8.12.9/linux-outbound_gateway-1.1) with ESMTP id h6LLPwq0027166 for ; Mon, 21 Jul 2003 14:25:58 -0700 Received: from poppy-e236.americas.sgi.com (poppy-e236.americas.sgi.com [128.162.236.207]) by flecktone.americas.sgi.com (8.12.9/8.12.9/generic_config-1.2) with ESMTP id h6LLPq3g155110; Mon, 21 Jul 2003 16:25:52 -0500 (CDT) Received: from stout.americas.sgi.com (stout.americas.sgi.com [128.162.232.50]) by poppy-e236.americas.sgi.com (8.12.9/SGI-server-1.8) with ESMTP id h6LLPqYk15251728; Mon, 21 Jul 2003 16:25:52 -0500 (CDT) Subject: Re: User processes run out of memory on XFS directory From: Eric Sandeen To: Josh Fishman Cc: linux-xfs@oss.sgi.com In-Reply-To: References: Content-Type: text/plain Organization: Message-Id: <1058822752.10294.241.camel@stout.americas.sgi.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 (1.2.2-5) Date: 21 Jul 2003 16:25:52 -0500 Content-Transfer-Encoding: 7bit X-archive-position: 4679 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: sandeen@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 1319 Lines: 36 Try xfs_info /mount/point and send the results, this is probably a V1 directory filesystem, and V1 is not well supported in Linux. I don't know offhand what the problem might be, but let's see what this fs looks like. -Eric On Mon, 2003-07-21 at 16:06, Josh Fishman wrote: > Hi List! > > I couldn't find this in the archive; sorry if it's already been discussed > to death. I'm trying to read a couple of XFS partitions that I recovered > from a dead SGI, dd'd to a Linux disk, and am now trying to mount using > loop-back. > > One partition-image mounts fine, it seems, but has a subdirectory that I > can't list. "ls" slowly grows larger in memory until it's eaten all 1024 > MB of RAM on the machine, then it dies with an "out of memory" error. > > The other partition-image won't mount, but I haven't tried the "nouuid" > trick yet, so I won't bother y'all with it just yet. > > Back to the Unlistable Image: I'm not getting any bad kernel or syslog > messages, dmesg isn't informative, and I've compiled in the "debug" flags > for XFS. I'm using linux-2.4.21 with: > > snapshot-xfs-2.4.21-2003-07-07_02:01_UTC with ACLs, realtime, debug enabled > > Any ideas? > > Thanks, ---Josh -- Eric Sandeen [C]XFS for Linux http://oss.sgi.com/projects/xfs sandeen@sgi.com SGI, Inc. 651-683-3102 From owner-linux-xfs@oss.sgi.com Mon Jul 21 14:54:38 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 21 Jul 2003 14:54:53 -0700 (PDT) Received: from calaf.cns.nyu.edu (CALAF.CNS.NYU.EDU [128.122.112.26]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h6LLsbFl024177 for ; Mon, 21 Jul 2003 14:54:37 -0700 Received: from localhost (fishman@localhost) by calaf.cns.nyu.edu (8.11.7+Sun/8.11.6) with ESMTP id h6LLsWh29936; Mon, 21 Jul 2003 17:54:32 -0400 (EDT) Date: Mon, 21 Jul 2003 17:54:32 -0400 (EDT) From: Josh Fishman To: Eric Sandeen cc: Subject: Re: User processes run out of memory on XFS directory In-Reply-To: <1058822752.10294.241.camel@stout.americas.sgi.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 4680 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: fishman@cns.nyu.edu Precedence: bulk X-list: linux-xfs Content-Length: 1165 Lines: 34 On 21 Jul 2003, Eric Sandeen wrote: > Try xfs_info /mount/point and send the results, this is probably a V1 > directory filesystem, and V1 is not well supported in Linux. > > I don't know offhand what the problem might be, but let's see what this > fs looks like. [root@attila /root]# xfs_info /BackupFreeSurfer/mnt/ meta-data=/BackupFreeSurfer/mnt isize=256 agcount=8, agsize=64675 blks data = bsize=4096 blocks=517398, imaxpct=25 = sunit=0 swidth=0 blks, unwritten=0 naming =version 1 bsize=4096 log =internal bsize=4096 blocks=1000 version=1 = sunit=0 blks realtime =none extsz=65536 blocks=0, rtextents=0 [root@attila /root]# dmesg (...) SGI XFS snapshot-xfs-2.4.21-2003-07-07_02:01_UTC with ACLs, realtime, debug enabled SGI XFS Quota Management subsystem XFS mounting filesystem loop(7,0) XFS: nil uuid in log - IRIX style log Ending clean XFS mount for filesystem: loop(7,0) ... and 'find' is just as powerless as 'ls', though it says "Terminated" rather than "out of memory". Thanks, ---Josh From owner-linux-xfs@oss.sgi.com Mon Jul 21 14:59:35 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 21 Jul 2003 14:59:39 -0700 (PDT) Received: from tolkor.sgi.com (tolkor.sgi.com [198.149.18.6]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h6LLxZFl024883 for ; Mon, 21 Jul 2003 14:59:35 -0700 Received: from flecktone.americas.sgi.com (flecktone.americas.sgi.com [192.48.203.135]) by tolkor.sgi.com (8.12.9/8.12.9/linux-outbound_gateway-1.1) with ESMTP id h6LMIIsR002485 for ; Mon, 21 Jul 2003 17:18:18 -0500 Received: from poppy-e236.americas.sgi.com (poppy-e236.americas.sgi.com [128.162.236.207]) by flecktone.americas.sgi.com (8.12.9/8.12.9/generic_config-1.2) with ESMTP id h6LLxS3g170971; Mon, 21 Jul 2003 16:59:28 -0500 (CDT) Received: from stout.americas.sgi.com (stout.americas.sgi.com [128.162.232.50]) by poppy-e236.americas.sgi.com (8.12.9/SGI-server-1.8) with ESMTP id h6LLxSYk15184917; Mon, 21 Jul 2003 16:59:28 -0500 (CDT) Subject: Re: User processes run out of memory on XFS directory From: Eric Sandeen To: Josh Fishman Cc: linux-xfs@oss.sgi.com In-Reply-To: References: Content-Type: text/plain Organization: Message-Id: <1058824768.10262.289.camel@stout.americas.sgi.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 (1.2.2-5) Date: 21 Jul 2003 16:59:28 -0500 Content-Transfer-Encoding: 7bit X-archive-position: 4681 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: sandeen@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 1639 Lines: 45 Ok, so you do have V1 dirs... and, you have a fairly recent kernel. Hm. (Steve did some v1 work a while back, but it should be in your kernel) you could also point xfs_repair (-n to do a trial run) and sanity-check the filesystem. -Eric On Mon, 2003-07-21 at 16:54, Josh Fishman wrote: > On 21 Jul 2003, Eric Sandeen wrote: > > > Try xfs_info /mount/point and send the results, this is probably a V1 > > directory filesystem, and V1 is not well supported in Linux. > > > > I don't know offhand what the problem might be, but let's see what this > > fs looks like. > > [root@attila /root]# xfs_info /BackupFreeSurfer/mnt/ > meta-data=/BackupFreeSurfer/mnt isize=256 agcount=8, agsize=64675 blks > data = bsize=4096 blocks=517398, imaxpct=25 > = sunit=0 swidth=0 blks, unwritten=0 > naming =version 1 bsize=4096 > log =internal bsize=4096 blocks=1000 version=1 > = sunit=0 blks > realtime =none extsz=65536 blocks=0, rtextents=0 > > > [root@attila /root]# dmesg > (...) > SGI XFS snapshot-xfs-2.4.21-2003-07-07_02:01_UTC with ACLs, realtime, debug enabled > SGI XFS Quota Management subsystem > XFS mounting filesystem loop(7,0) > XFS: nil uuid in log - IRIX style log > Ending clean XFS mount for filesystem: loop(7,0) > > > ... and 'find' is just as powerless as 'ls', though it says "Terminated" > rather than "out of memory". > > Thanks, ---Josh -- Eric Sandeen [C]XFS for Linux http://oss.sgi.com/projects/xfs sandeen@sgi.com SGI, Inc. 651-683-3102 From owner-linux-xfs@oss.sgi.com Mon Jul 21 15:00:51 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 21 Jul 2003 15:00:54 -0700 (PDT) Received: from tolkor.sgi.com (tolkor.sgi.com [198.149.18.6]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h6LM0pFl025404 for ; Mon, 21 Jul 2003 15:00:51 -0700 Received: from flecktone.americas.sgi.com (flecktone.americas.sgi.com [192.48.203.135]) by tolkor.sgi.com (8.12.9/8.12.9/linux-outbound_gateway-1.1) with ESMTP id h6LMJYsR002827 for ; Mon, 21 Jul 2003 17:19:34 -0500 Received: from poppy-e236.americas.sgi.com (poppy-e236.americas.sgi.com [128.162.236.207]) by flecktone.americas.sgi.com (8.12.9/8.12.9/generic_config-1.2) with ESMTP id h6LM0J3g168042; Mon, 21 Jul 2003 17:00:19 -0500 (CDT) Received: from stout.americas.sgi.com (stout.americas.sgi.com [128.162.232.50]) by poppy-e236.americas.sgi.com (8.12.9/SGI-server-1.8) with ESMTP id h6LM0JYk15192248; Mon, 21 Jul 2003 17:00:19 -0500 (CDT) Subject: Re: User processes run out of memory on XFS directory From: Eric Sandeen To: Josh Fishman Cc: linux-xfs@oss.sgi.com In-Reply-To: References: Content-Type: text/plain Organization: Message-Id: <1058824818.10262.293.camel@stout.americas.sgi.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 (1.2.2-5) Date: 21 Jul 2003 17:00:19 -0500 Content-Transfer-Encoding: 7bit X-archive-position: 4682 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: sandeen@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 146 Lines: 5 Also (sorry, spam spam spam) if you turn on KDB, break in while it's filling up your memory to see what the ls process is doing in xfs... -Eric From owner-linux-xfs@oss.sgi.com Mon Jul 21 15:12:50 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 21 Jul 2003 15:12:57 -0700 (PDT) Received: from tolkor.sgi.com (tolkor.sgi.com [198.149.18.6]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h6LMCnFl026470 for ; Mon, 21 Jul 2003 15:12:50 -0700 Received: from flecktone.americas.sgi.com (flecktone.americas.sgi.com [192.48.203.135]) by tolkor.sgi.com (8.12.9/8.12.9/linux-outbound_gateway-1.1) with ESMTP id h6LMVWsR006464 for ; Mon, 21 Jul 2003 17:31:32 -0500 Received: from daisy-e236.americas.sgi.com (daisy-e236.americas.sgi.com [128.162.236.214]) by flecktone.americas.sgi.com (8.12.9/8.12.9/generic_config-1.2) with ESMTP id h6LMCA3g163157; Mon, 21 Jul 2003 17:12:11 -0500 (CDT) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.232.100]) by daisy-e236.americas.sgi.com (8.12.9/SGI-server-1.8) with ESMTP id h6LMCARn155212207; Mon, 21 Jul 2003 17:12:10 -0500 (CDT) Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id h6LMCAL27109; Mon, 21 Jul 2003 17:12:10 -0500 Subject: Re: User processes run out of memory on XFS directory From: Steve Lord To: Josh Fishman Cc: linux-xfs@oss.sgi.com In-Reply-To: <1058824768.10262.289.camel@stout.americas.sgi.com> References: <1058824768.10262.289.camel@stout.americas.sgi.com> Content-Type: multipart/mixed; boundary="=-PioTwemNcnRMxmoByYKD" Organization: Message-Id: <1058825530.26867.7.camel@jen.americas.sgi.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.4 Date: 21 Jul 2003 17:12:10 -0500 X-archive-position: 4683 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: lord@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 7622 Lines: 242 --=-PioTwemNcnRMxmoByYKD Content-Type: text/plain Content-Transfer-Encoding: 7bit On Mon, 2003-07-21 at 16:59, Eric Sandeen wrote: > Ok, so you do have V1 dirs... and, you have a fairly recent kernel. > Hm. (Steve did some v1 work a while back, but it should be in your > kernel) > > you could also point xfs_repair (-n to do a trial run) and sanity-check > the filesystem. > I did some work, but it is not in the tree. Try the attached patch which may or may not fix your problems - it may not apply completely cleanly either, it is a little long in the tooth. V1 directories and the Linux getdents interface just do not like each other, glibc definitely does not like the way XFS V1 directories work. So this code is an attempt to make the best of a bad deal. Steve -- Steve Lord voice: +1-651-683-3511 Principal Engineer, Filesystem Software email: lord@sgi.com --=-PioTwemNcnRMxmoByYKD Content-Disposition: attachment; filename=v1dir.patch Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; name=v1dir.patch; charset=ISO-8859-1 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Index: linux/fs/xfs/linux/xfs_file.c =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --- /usr/tmp/TmpDir.3131-0/linux/fs/xfs/linux/xfs_file.c_1.90 Fri Jun 13 05= :36:50 2003 +++ linux/fs/xfs/linux/xfs_file.c Fri Jun 13 05:33:09 2003 @@ -211,7 +211,11 @@ uio.uio_iov =3D &iov; uio.uio_fmode =3D filp->f_mode; uio.uio_segflg =3D UIO_SYSSPACE; - curr_offset =3D uio.uio_offset =3D filp->f_pos; + curr_offset =3D filp->f_pos; + if (filp->f_pos !=3D 0x7fffffff) + uio.uio_offset =3D filp->f_pos; + else + uio.uio_offset =3D 0xffffffff; =20 while (!eof) { uio.uio_resid =3D iov.iov_len =3D rlen; @@ -232,13 +236,13 @@ namelen =3D strlen(dbp->d_name); =20 if (filldir(dirent, dbp->d_name, namelen, - (loff_t) curr_offset, + (loff_t) curr_offset & 0x7fffffff, (ino_t) dbp->d_ino, DT_UNKNOWN)) { goto done; } size -=3D dbp->d_reclen; - curr_offset =3D (loff_t)dbp->d_off & 0x7fffffff; + curr_offset =3D (loff_t)dbp->d_off /* & 0x7fffffff */; dbp =3D nextdp(dbp); } } =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Index: linux/fs/xfs/xfs_dir2_leaf.h =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --- /usr/tmp/TmpDir.3131-0/linux/fs/xfs/xfs_dir2_leaf.h_1.12 Fri Jun 13 05:= 36:50 2003 +++ linux/fs/xfs/xfs_dir2_leaf.h Fri Jun 13 05:33:09 2003 @@ -64,7 +64,7 @@ * Offset in data space of a data entry. */ typedef __uint32_t xfs_dir2_dataptr_t; -#define XFS_DIR2_MAX_DATAPTR ((xfs_dir2_dataptr_t)0x7fffffff) +#define XFS_DIR2_MAX_DATAPTR ((xfs_dir2_dataptr_t)0xffffffff) #define XFS_DIR2_NULL_DATAPTR ((xfs_dir2_dataptr_t)0) =20 /* =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Index: linux/fs/xfs/xfs_dir_leaf.c =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --- /usr/tmp/TmpDir.3131-0/linux/fs/xfs/xfs_dir_leaf.c_1.113 Fri Jun 13 05:= 36:50 2003 +++ linux/fs/xfs/xfs_dir_leaf.c Fri Jun 13 05:33:09 2003 @@ -560,14 +560,7 @@ */ if (sbp->seqno =3D=3D 0 || sbp =3D=3D sbuf) lastresid =3D uio->uio_resid; - /* - * NOTE! Linux "filldir" semantics require that the - * offset "cookie" be for this entry, not the - * next; all the actual shuffling to make it - * "look right" to the user is done in filldir. - */ - XFS_PUT_COOKIE(p.cook, mp, 0, sbp->seqno, sbp->hash); - + XFS_PUT_COOKIE(p.cook, mp, 0, sbp[1].seqno, sbp[1].hash); #if XFS_BIG_FILESYSTEMS p.ino =3D sbp->ino + mp->m_inoadd; #else @@ -575,9 +568,7 @@ #endif p.name =3D sbp->name; p.namelen =3D sbp->namelen; - retval =3D p.put(&p); - if (!p.done) { uio->uio_offset =3D XFS_DA_MAKE_COOKIE(mp, 0, 0, sbp->hash); @@ -586,20 +577,12 @@ xfs_dir_trace_g_du("sf: E-O-B", dp, uio); return retval; } - sbp++; } - kmem_free(sbuf, sbsize); - - XFS_PUT_COOKIE(p.cook, mp, 0, 0, XFS_DA_MAXHASH); - uio->uio_offset =3D p.cook.o; - *eofp =3D 1; - xfs_dir_trace_g_du("sf: E-O-F", dp, uio); - return 0; } =20 @@ -2070,16 +2053,6 @@ return XFS_ERROR(EFSCORRUPTED); } =20 - thishash =3D INT_GET(entry->hashval, ARCH_CONVERT); - - /* - * NOTE! Linux "filldir" semantics require that the - * offset "cookie" be for this entry, not the - * next; all the actual shuffling to make it - * "look right" to the user is done in filldir. - */ - XFS_PUT_COOKIE(p.cook, mp, bno, entno, thishash); - xfs_dir_trace_g_duc("leaf: middle cookie ", dp, uio, p.cook.o); =20 @@ -2090,17 +2063,19 @@ nextentno =3D entno + 1; else nextentno =3D 0; + XFS_PUT_COOKIE(p.cook, mp, bno, nextentno, nexthash); + xfs_dir_trace_g_duc("leaf: middle cookie ", + dp, uio, p.cook.o); =20 - } else if (INT_GET(leaf->hdr.info.forw, ARCH_CONVERT)) { + } else if ((thishash =3D INT_GET(leaf->hdr.info.forw, + ARCH_CONVERT))) { xfs_dabuf_t *bp2; xfs_dir_leafblock_t *leaf2; =20 ASSERT(nextda !=3D -1); =20 - retval =3D xfs_da_read_buf(dp->i_transp, dp, - INT_GET(leaf->hdr.info.forw, - ARCH_CONVERT), nextda, - &bp2, XFS_DATA_FORK); + retval =3D xfs_da_read_buf(dp->i_transp, dp, thishash, + nextda, &bp2, XFS_DATA_FORK); if (retval) return(retval); =20 @@ -2124,13 +2099,13 @@ nexthash =3D INT_GET(leaf2->entries[0].hashval, ARCH_CONVERT); nextentno =3D -1; - + XFS_PUT_COOKIE(p.cook, mp, thishash, 0, nexthash); xfs_da_brelse(dp->i_transp, bp2); xfs_dir_trace_g_duc("leaf: next blk cookie", dp, uio, p.cook.o); } else { nextentno =3D -1; - nexthash =3D XFS_DA_MAXHASH; + XFS_PUT_COOKIE(p.cook, mp, 0, 0, XFS_DA_MAXHASH); } =20 /* @@ -2147,7 +2122,8 @@ * provided is big enough to handle it (see pv763517). */ #if (BITS_PER_LONG =3D=3D 32) - if (INT_GET(entry->hashval, ARCH_CONVERT) !=3D lasthash) { + if ((thishash =3D INT_GET(entry->hashval, ARCH_CONVERT)) + !=3D lasthash) { XFS_PUT_COOKIE(lastoffset, mp, bno, entno, thishash); lastresid =3D uio->uio_resid; lasthash =3D thishash; @@ -2156,6 +2132,7 @@ dp, uio, p.cook.o); } #else + lasthash =3D thishash =3D INT_GET(entry->hashval, ARCH_CONVERT); XFS_PUT_COOKIE(lastoffset, mp, bno, entno, thishash); lastresid =3D uio->uio_resid; #endif /* BITS_PER_LONG =3D=3D 32 */ @@ -2187,8 +2164,6 @@ } } =20 - XFS_PUT_COOKIE(p.cook, mp, 0, 0, nexthash); - uio->uio_offset =3D p.cook.o; =20 *eobp =3D 0; --=-PioTwemNcnRMxmoByYKD-- From owner-linux-xfs@oss.sgi.com Mon Jul 21 15:15:13 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 21 Jul 2003 15:15:17 -0700 (PDT) Received: from calaf.cns.nyu.edu (CALAF.CNS.NYU.EDU [128.122.112.26]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h6LMFCFl027002 for ; Mon, 21 Jul 2003 15:15:13 -0700 Received: from localhost (fishman@localhost) by calaf.cns.nyu.edu (8.11.7+Sun/8.11.6) with ESMTP id h6LMF7a00492; Mon, 21 Jul 2003 18:15:07 -0400 (EDT) Date: Mon, 21 Jul 2003 18:15:07 -0400 (EDT) From: Josh Fishman To: Eric Sandeen cc: Subject: Re: User processes run out of memory on XFS directory In-Reply-To: <1058824768.10262.289.camel@stout.americas.sgi.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 4684 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: fishman@cns.nyu.edu Precedence: bulk X-list: linux-xfs Content-Length: 2144 Lines: 70 On 21 Jul 2003, Eric Sandeen wrote: > Ok, so you do have V1 dirs... and, you have a fairly recent kernel. > Hm. (Steve did some v1 work a while back, but it should be in your > kernel) > > you could also point xfs_repair (-n to do a trial run) and sanity-check > the filesystem. This gives no indication of errors. Furthermore, when I muck with a random file within the Unlistable Directory, it works fine. (I get the file names via xfs_ncheck.) There are quite a lot of files in the directory, but GNU 'ls' worked fine on the directory under IRIX. Maybe I should just write a script to get everything out using 'xfs_ncheck'... but that seems ugly. :-/ Unfortunately, I'm not much of a kernal hacker, and haven't ever used KDB. On the other hand, the compressed disk image is only about 130 MB, so I could put it up on my webserver for download if you'd like to pick at it yourself. :-) Thanks, ---Josh PS: Full output of xfs_repair: Phase 1 - find and verify superblock... Phase 2 - using internal log - scan filesystem freespace and inode maps... - found root inode chunk Phase 3 - for each AG... - scan (but don't clear) agi unlinked lists... - process known inodes and perform inode discovery... - agno = 0 - agno = 1 - agno = 2 - agno = 3 - agno = 4 - agno = 5 - agno = 6 - agno = 7 - agno = 7 - process newly discovered inodes... Phase 4 - check for duplicate blocks... - setting up duplicate extent list... - check for inodes claiming duplicate blocks... - agno = 0 - agno = 1 - agno = 2 - agno = 3 - agno = 4 - agno = 5 - agno = 6 - agno = 7 No modify flag set, skipping phase 5 Phase 6 - check inode connectivity... - traversing filesystem starting at / ... - traversal finished ... - traversing all unattached subtrees ... - traversals finished ... - moving disconnected inodes to lost+found ... Phase 7 - verify link counts... No modify flag set, skipping filesystem flush and exiting. From owner-linux-xfs@oss.sgi.com Mon Jul 21 15:52:00 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 21 Jul 2003 15:52:18 -0700 (PDT) Received: from atlrel7.hp.com (atlrel7.hp.com [156.153.255.213]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h6LMpoFl029154 for ; Mon, 21 Jul 2003 15:51:50 -0700 Received: from xatlrelay1.atl.hp.com (xatlrelay1.atl.hp.com [15.45.89.190]) by atlrel7.hp.com (Postfix) with ESMTP id 1FAAD1C01B73 for ; Mon, 21 Jul 2003 18:28:23 -0400 (EDT) Received: from xatlbh4.atl.hp.com (xatlbh4.atl.hp.com [15.45.89.189]) by xatlrelay1.atl.hp.com (Postfix) with ESMTP id 06C281C00A19 for ; Mon, 21 Jul 2003 18:28:23 -0400 (EDT) Received: by xatlbh4.atl.hp.com with Internet Mail Service (5.5.2655.55) id <3F3P8QQR>; Mon, 21 Jul 2003 18:28:22 -0400 Message-ID: From: "HABBINGA,ERIK (HP-Loveland,ex1)" To: "'linux-xfs@oss.sgi.com'" Subject: XFS and 2.4.22-pre7? Date: Mon, 21 Jul 2003 18:28:21 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) Content-Type: text/plain; charset="iso-8859-1" X-archive-position: 4685 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: erik.habbinga@hp.com Precedence: bulk X-list: linux-xfs Content-Length: 713 Lines: 16 Has anyone tried XFS and the 2.4.22-pre7 patch? I'm successfully running a CVS drop from June 16, 2003 with the 2.4.22 kernel. Applying the 2.4.22-pre7 patch and fixing the subsequent compile time issues fails for me. I would not be surprised if I messed up the compile issues, so I would like to hear if anyone has had success with XFS and 2.4.22-pre7. I'm locking up when remounting the root file system (XFS) from read-only to read-write. The mtab~ file is being written, the mount process calls sys_write->xfs_write, xfs_write tries to grab a lock, doesn't get it, and waits patiently (i.e. forever). Thanks, Erik Habbinga Hewlett Packard P.S. Hope to see some of the XFS guys in Ottawa this week... From owner-linux-xfs@oss.sgi.com Mon Jul 21 16:22:20 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 21 Jul 2003 16:22:37 -0700 (PDT) Received: from calaf.cns.nyu.edu (CALAF.CNS.NYU.EDU [128.122.112.26]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h6LNMJFl001434 for ; Mon, 21 Jul 2003 16:22:19 -0700 Received: from localhost (fishman@localhost) by calaf.cns.nyu.edu (8.11.7+Sun/8.11.6) with ESMTP id h6LNMDW02151; Mon, 21 Jul 2003 19:22:13 -0400 (EDT) Date: Mon, 21 Jul 2003 19:22:13 -0400 (EDT) From: Josh Fishman To: Steve Lord cc: Subject: Re: User processes run out of memory on XFS directory In-Reply-To: <1058825530.26867.7.camel@jen.americas.sgi.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 4686 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: fishman@cns.nyu.edu Precedence: bulk X-list: linux-xfs Content-Length: 324 Lines: 12 On 21 Jul 2003, Steve Lord wrote: > I did some work, but it is not in the tree. Try the attached patch > which may or may not fix your problems - it may not apply completely > cleanly either, it is a little long in the tooth. Not only did it patch and compile flawlessly, but it seems to work, too! Thank you! ---Josh From owner-linux-xfs@oss.sgi.com Mon Jul 21 17:34:54 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 21 Jul 2003 17:35:15 -0700 (PDT) Received: from iris.acsalaska.net (iris.slb.nwc.acsalaska.net [209.112.155.43]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h6M0YqFl005940 for ; Mon, 21 Jul 2003 17:34:53 -0700 Received: from erbenson.alaska.net (82-pm30.nwc.alaska.net [209.112.158.82]) by iris.acsalaska.net (8.12.9/8.12.9) with ESMTP id h6M0YimX090310 for ; Mon, 21 Jul 2003 16:34:45 -0800 (AKDT) (envelope-from erbenson@alaska.net) Received: from plato.local.lan (plato.local.lan [192.168.0.4]) by erbenson.alaska.net (Postfix) with ESMTP id DFB0A3A08 for ; Mon, 21 Jul 2003 16:34:43 -0800 (AKDT) Received: by plato.local.lan (Postfix, from userid 1000) id ED6CE40FF44; Mon, 21 Jul 2003 16:34:43 -0800 (AKDT) Date: Mon, 21 Jul 2003 16:34:43 -0800 From: Ethan Benson To: linux-xfs@oss.sgi.com Subject: [PATCH] Implement immutable/append-only flags in XFS #3 Message-ID: <20030722003443.GA13188@plato.local.lan> Mail-Followup-To: linux-xfs@oss.sgi.com Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="+QahgC5+KEYLbs62" Content-Disposition: inline User-Agent: Mutt/1.3.28i X-OS: Debian GNU X-gpg-fingerprint: E3E4 D0BC 31BC F7BB C1DD C3D6 24AC 7B1A 2C44 7AFC X-gpg-key: http://www.alaska.net/~erbenson/gpg/key.asc Mail-Copies-To: nobody X-No-CC: I subscribe to this list; do not CC me on replies. X-ACS-Spam-Status: no X-Scanned-By: MIMEDefang 2.31 (www . roaringpenguin . com / mimedefang) X-archive-position: 4687 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: erbenson@alaska.net Precedence: bulk X-list: linux-xfs Content-Length: 23922 Lines: 617 --+QahgC5+KEYLbs62 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Hi, [third revision of my patch, only change is to update it for current 2.4.21 CVS] Over time there has been many requests for ext2 file flags such as immutable, append-only, sync, noatime be implemented in XFS. So, here it is. I have implemented all of the above flags in 2.4.21 CVS. The patch is relatively small and non-invasive, and from my testing appears to cause no backwards compatibility issues (older kernels ignore, and leave alone the new flags). Also xfs_repair and xfs_check do not seem to have any problems with the new flags either. If any XFS users would like to try this patch and report on it please do. My testing indicates its stable and will cause no problems except as discussed below with xfsdump. However during my testing I did discover 3 issues: 1: The Linux VFS contains a bug which allows timestamp modification of immutable/append-only files. I have fixed this issue, and will send the patch to the linux-kernel mailing list shortly. I have included that patch in this mail for completeness. 2: xfsrestore breaks when immutable or append-only files are included in the dump. The problem is xfsrestore restores the file inode flags too soon, and then loses the access it needs to restore extended attributes, uid, gid, and permissions. I am not familiar enough with xfsrestore to really propose the fix, however i believe just changing it to restore at the very least immutable/append-only flags very last after all other restoration is complete should suffice to solve this problem. 3: I just found an undocumented behavior with regards to ext2's file flags; when set on a directory any new file/dir created will inherit the flags of the parent directory. I am not entirely convinced this is a good idea, at least for *all* flags. In ext2 this behavior has been half broken for as near as i can tell, forever up to 2.4.20 (2.4.21 fixes it), the brokenness is that the vfs is not immediately informed of any of the flags except sync, thus they don't actually go into affect on new files until the inode is revalidated (which could take quite some time). In addition ext2 only refrains from doing this on symlinks, not device special files; this means if you create a device node in a append-only directory the only way you will ever be able to remove it is with debugfs. (ioctl() calls on a device file go to the driver handling the node, not to the filesystem holding the node, thus chattr won't help you). My question on #3 is whether we want this behavior in XFS? my current patch does NOT implement it. My opinion is that the only flag this really makes sense for is sync, since setting the sync flag on a directory does not actually do anything for you (it only affects files), so making all new files created under a sync directory is seemingly sensible (and probably what the user would expect, more or less). this might make sense for noatime too, but I am less convinced of this. I am definitely not convinced its a sensible idea for append-only since it ends up allowing non-privileged users to create append-only files, which is not normally permitted. Also automatically setting the append-only flag on a newly created file won't necessarily make it append-only immediately, since a caller doing open("append-only-dir/file" O_RDWR|O_CREAT) will retain full read/write access so long as the file descriptor is kept open (the same is true if you chmod() a file, open descriptors retain access even if they could not get it on a new open()). So for now I submit the patch without the ext2 inheritance behavior, if you believe we should implement the ext2 behavior either partially, or fully I should be able to do that (though a suggestion on the best place in XFS to do this task would be welcome). I have also implemented the EXT2_IOC_SETFLAGS/EXT2_IOC_GETFLAGS ioctl()s so chattr/lsattr will work on xfs, this part of the patch is optional, if excluded then either lsattr/chattr would need to be modified to use XFS_IOC_FSSETXATTR and XFS_IOC_FSGETXATTR ioctls. I have a (somewhat hideous) test program to check as many things as i could think of to ensure immutable/append-only are properly enforced, the only thing lacking in it is tests of all the XFS ioctls, perhaps someone familiar with xfs ioctls could add these, currently the libhandle open/write tests are done. You can find this test program at http://penguinppc.org/~eb/t_immutable.c Important: this test program creates a test area with full world read/write permissions to ensure regular file permissions are not tainting the test, therefore it is NOT SAFE to run on systems with untrusted users. the usage is t_immutable -c /some/dir which will create a test area as /some/dir and run tests in it. t_immutable -C will create the test area without running any tests, and t_immutable -r will remove a test area. t_immutable /some/dir will run the tests on a previously created test area. Note if you run t_immutable on an ext2 filesystem in 2.4.21 kernels you will need to use debugfs to get rid of the device node it creates (same on kernels prior to 2.4.21 if you leave the test area around long enough). see above for why. feedback is welcome. diffstat output follows: linux/xfs_ext2_ioctl.h | 45 ++++++++++++++++++++++ linux/xfs_ioctl.c | 100 +++++++++++++++++++++++++++++++++++++++++++++++++ linux/xfs_iops.c | 6 ++ linux/xfs_super.c | 16 +++++++ linux/xfs_vnode.c | 17 ++++++++ xfs_acl.c | 2 xfs_cap.c | 2 xfs_dinode.h | 24 ++++++++--- xfs_fs.h | 7 ++- xfs_inode.c | 5 +- xfs_itable.c | 8 +++ xfs_vnodeops.c | 16 +++++++ 12 files changed, 239 insertions(+), 9 deletions(-) -- Ethan Benson http://www.alaska.net/~erbenson/ --+QahgC5+KEYLbs62 Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="xfs-xflags.diff" diff -urN -xCVS linux-2.4-xfs.orig/linux/fs/xfs/linux/xfs_ext2_ioctl.h linux-2.4-xfs/linux/fs/xfs/linux/xfs_ext2_ioctl.h --- linux-2.4-xfs.orig/linux/fs/xfs/linux/xfs_ext2_ioctl.h Wed Dec 31 14:00:00 1969 +++ linux-2.4-xfs/linux/fs/xfs/linux/xfs_ext2_ioctl.h Mon Jul 21 15:57:33 2003 @@ -0,0 +1,45 @@ +/* + * Copyright (c) 2003 Silicon Graphics, Inc. All Rights Reserved. + * + * This program is free software; you can redistribute it and/or modify it + * under the terms of version 2 of the GNU General Public License as + * published by the Free Software Foundation. + * + * This program is distributed in the hope that it would be useful, but + * WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. + * + * Further, this software is distributed without any warranty that it is + * free of the rightful claim of any third person regarding infringement + * or the like. Any license provided herein, whether implied or + * otherwise, applies only to this software file. Patent licenses, if + * any, provided herein do not apply to combinations of this program with + * other software, or any other product whatsoever. + * + * You should have received a copy of the GNU General Public License along + * with this program; if not, write the Free Software Foundation, Inc., 59 + * Temple Place - Suite 330, Boston MA 02111-1307, USA. + * + * Contact information: Silicon Graphics, Inc., 1600 Amphitheatre Pkwy, + * Mountain View, CA 94043, or: + * + * http://www.sgi.com + * + * For further information regarding this notice, see: + * + * http://oss.sgi.com/projects/GenInfo/SGIGPLNoticeExplan/ + */ +#ifndef __XFS_EXT2_IOCTL_H__ +#define __XFS_EXT2_IOCTL_H__ + +/* ext2 ioctls (EXT2_IOC_GETFLAGS and EXT2_IOC_SETFLAGS) to support + * chattr/lsattr */ +#define XFS_IOC_EXT2_GETFLAGS _IOR('f', 1, long) +#define XFS_IOC_EXT2_SETFLAGS _IOW('f', 2, long) + +#define EXT2_FLAG_SYNC 0x00000008 /* Synchronous updates */ +#define EXT2_FLAG_IMMUTABLE 0x00000010 /* Immutable file */ +#define EXT2_FLAG_APPEND 0x00000020 /* writes to file may only append */ +#define EXT2_FLAG_NOATIME 0x00000080 /* do not update atime */ + +#endif /* __XFS_EXT2_IOCTL_H__ */ diff -urN -xCVS linux-2.4-xfs.orig/linux/fs/xfs/linux/xfs_ioctl.c linux-2.4-xfs/linux/fs/xfs/linux/xfs_ioctl.c --- linux-2.4-xfs.orig/linux/fs/xfs/linux/xfs_ioctl.c Mon Jul 21 15:12:50 2003 +++ linux-2.4-xfs/linux/fs/xfs/linux/xfs_ioctl.c Mon Jul 21 15:19:13 2003 @@ -66,6 +66,7 @@ #include "xfs_utils.h" #include "xfs_dfrag.h" #include "xfs_fsops.h" +#include "xfs_ext2_ioctl.h" #include #include @@ -327,6 +328,13 @@ if (permflag & O_TRUNC) permflag |= 2; + if ((!(permflag & O_APPEND) || (permflag & O_TRUNC)) && + (permflag & FMODE_WRITE) && IS_APPEND(inode)) + return -XFS_ERROR(EPERM); + + if ((permflag & FMODE_WRITE) && IS_IMMUTABLE(inode)) + return -XFS_ERROR(EACCES); + /* Can't write directories. */ if ( S_ISDIR(inode->i_mode) && (permflag & FMODE_WRITE)) { iput(inode); @@ -447,6 +455,9 @@ if (error) return -error; + if (IS_IMMUTABLE(inode) || IS_APPEND(inode)) + return -XFS_ERROR(EPERM); + if (copy_from_user(&fsd, dmhreq.data, sizeof(fsd))) { VN_RELE(vp); return -XFS_ERROR(EFAULT); @@ -532,11 +543,21 @@ NULL, ops[i].am_error); break; case ATTR_OP_SET: + if (IS_IMMUTABLE(inode) || IS_APPEND(inode)) { + kfree(ops); + VN_RELE(vp); + return -XFS_ERROR(EPERM); + } VOP_ATTR_SET(vp,ops[i].am_attrname, ops[i].am_attrvalue, ops[i].am_length, ops[i].am_flags, NULL, ops[i].am_error); break; case ATTR_OP_REMOVE: + if (IS_IMMUTABLE(inode) || IS_APPEND(inode)) { + kfree(ops); + VN_RELE(vp); + return -XFS_ERROR(EPERM); + } VOP_ATTR_REMOVE(vp, ops[i].am_attrname, ops[i].am_flags, NULL, ops[i].am_error); break; @@ -842,6 +863,75 @@ error = xfs_errortag_clearall(mp); return -error; + case XFS_IOC_EXT2_GETFLAGS: { + unsigned int flags = 0; + + if (vp->v_inode.i_flags & S_IMMUTABLE) + flags |= EXT2_FLAG_IMMUTABLE; /* EXT2_IMMUTABLE_FL */ + if (vp->v_inode.i_flags & S_APPEND) + flags |= EXT2_FLAG_APPEND; /* EXT2_APPEND_FL */ + if (vp->v_inode.i_flags & S_SYNC) + flags |= EXT2_FLAG_SYNC; /* EXT2_SYNC_FL */ + if (vp->v_inode.i_flags & S_NOATIME) + flags |= EXT2_FLAG_NOATIME; /* EXT2_NOATIME_FL */ + + if (copy_to_user((unsigned int *)arg, &flags, sizeof(flags))) + return -XFS_ERROR(EFAULT); + return 0; + } + + case XFS_IOC_EXT2_SETFLAGS: { + vattr_t va; + unsigned int flags; + int attr_flags = 0; + + if (copy_from_user(&flags, (unsigned int *)arg, sizeof(flags))) + return -XFS_ERROR(EFAULT); + + /* we need to do getattr to preserve XFS xflags ext2 + * has no knowledge of */ + + va.va_mask = XFS_AT_XFLAGS; + VOP_GETATTR(vp, &va, 0, NULL, error); + if (error) + return -error; + + if (flags & (EXT2_FLAG_IMMUTABLE|EXT2_FLAG_APPEND) || + va.va_xflags & (XFS_XFLAG_IMMUTABLE|XFS_XFLAG_APPEND)) + if (!capable(CAP_LINUX_IMMUTABLE)) + return -XFS_ERROR(EPERM); + + /* don't silently ignore unsupported ext2 flags */ + if (flags & ~(EXT2_FLAG_IMMUTABLE|EXT2_FLAG_APPEND| + EXT2_FLAG_SYNC|EXT2_FLAG_NOATIME)) + return -XFS_ERROR(EOPNOTSUPP); + + if (flags & EXT2_FLAG_IMMUTABLE) /* EXT2_IMMUTABLE_FL */ + va.va_xflags |= XFS_XFLAG_IMMUTABLE; + else + va.va_xflags &= ~XFS_XFLAG_IMMUTABLE; + if (flags & EXT2_FLAG_APPEND) /* EXT2_APPEND_FL */ + va.va_xflags |= XFS_XFLAG_APPEND; + else + va.va_xflags &= ~XFS_XFLAG_APPEND; + if (flags & EXT2_FLAG_SYNC) /* EXT2_SYNC_FL */ + va.va_xflags |= XFS_XFLAG_SYNC; + else + va.va_xflags &= ~XFS_XFLAG_SYNC; + if (flags & EXT2_FLAG_NOATIME) /* EXT2_NOATIME_FL */ + va.va_xflags |= XFS_XFLAG_NOATIME; + else + va.va_xflags &= ~XFS_XFLAG_NOATIME; + + if (filp->f_flags & (O_NDELAY|O_NONBLOCK)) + attr_flags |= ATTR_NONBLOCK; + + VOP_SETATTR(vp, &va, attr_flags, NULL, error); + if (!error) + vn_revalidate(vp); /* push immutable/append flags into vfs inode */ + return -error; + } + default: return -ENOTTY; } @@ -859,6 +949,9 @@ int attr_flags = 0; int error; + if (vp->v_inode.i_flags & (S_IMMUTABLE|S_APPEND)) + return -XFS_ERROR(EPERM); + if (filp->f_flags & O_RDONLY) return -XFS_ERROR(EBADF); @@ -1012,6 +1105,11 @@ if (copy_from_user(&fa, (struct fsxattr *)arg, sizeof(fa))) return -XFS_ERROR(EFAULT); + if (fa.fsx_xflags & (XFS_XFLAG_IMMUTABLE|XFS_XFLAG_APPEND) || + va.va_xflags & (XFS_XFLAG_IMMUTABLE|XFS_XFLAG_APPEND)) + if (!capable(CAP_LINUX_IMMUTABLE)) + return -XFS_ERROR(EPERM); + va.va_mask = XFS_AT_XFLAGS | XFS_AT_EXTSIZE; va.va_xflags = fa.fsx_xflags; va.va_extsize = fa.fsx_extsize; @@ -1020,6 +1118,8 @@ attr_flags |= ATTR_NONBLOCK; VOP_SETATTR(vp, &va, attr_flags, NULL, error); + if (!error) + vn_revalidate(vp); /* push immutable/append flags into vfs inode */ return -error; } diff -urN -xCVS linux-2.4-xfs.orig/linux/fs/xfs/linux/xfs_iops.c linux-2.4-xfs/linux/fs/xfs/linux/xfs_iops.c --- linux-2.4-xfs.orig/linux/fs/xfs/linux/xfs_iops.c Mon Jul 21 15:12:55 2003 +++ linux-2.4-xfs/linux/fs/xfs/linux/xfs_iops.c Mon Jul 21 15:19:13 2003 @@ -617,6 +617,9 @@ return error; } + if (IS_IMMUTABLE(inode) || IS_APPEND(inode)) + return -EPERM; + /* Convert Linux syscall to XFS internal ATTR flags */ if (flags & XATTR_CREATE) xflags |= ATTR_CREATE; @@ -766,6 +769,9 @@ error = xfs_cap_vremove(vp); return error; } + + if (IS_IMMUTABLE(inode) || IS_APPEND(inode)) + return -EPERM; if (strncmp(name, xfs_namespaces[ROOT_NAMES].name, xfs_namespaces[ROOT_NAMES].namelen) == 0) { diff -urN -xCVS linux-2.4-xfs.orig/linux/fs/xfs/linux/xfs_super.c linux-2.4-xfs/linux/fs/xfs/linux/xfs_super.c --- linux-2.4-xfs.orig/linux/fs/xfs/linux/xfs_super.c Mon Jul 21 15:13:02 2003 +++ linux-2.4-xfs/linux/fs/xfs/linux/xfs_super.c Mon Jul 21 15:19:13 2003 @@ -181,6 +181,22 @@ inode->i_atime = ip->i_d.di_atime.t_sec; inode->i_mtime = ip->i_d.di_mtime.t_sec; inode->i_ctime = ip->i_d.di_ctime.t_sec; + if (ip->i_d.di_flags & XFS_DIFLAG_IMMUTABLE) + inode->i_flags |= S_IMMUTABLE; + else + inode->i_flags &= ~S_IMMUTABLE; + if (ip->i_d.di_flags & XFS_DIFLAG_APPEND) + inode->i_flags |= S_APPEND; + else + inode->i_flags &= ~S_APPEND; + if (ip->i_d.di_flags & XFS_DIFLAG_SYNC) + inode->i_flags |= S_SYNC; + else + inode->i_flags &= ~S_SYNC; + if (ip->i_d.di_flags & XFS_DIFLAG_NOATIME) + inode->i_flags |= S_NOATIME; + else + inode->i_flags &= ~S_NOATIME; vp->v_flag &= ~VMODIFIED; } diff -urN -xCVS linux-2.4-xfs.orig/linux/fs/xfs/linux/xfs_vnode.c linux-2.4-xfs/linux/fs/xfs/linux/xfs_vnode.c --- linux-2.4-xfs.orig/linux/fs/xfs/linux/xfs_vnode.c Mon Jul 21 15:13:07 2003 +++ linux-2.4-xfs/linux/fs/xfs/linux/xfs_vnode.c Mon Jul 21 15:19:13 2003 @@ -224,6 +224,23 @@ inode->i_mtime = va.va_mtime.tv_sec; inode->i_ctime = va.va_ctime.tv_sec; inode->i_atime = va.va_atime.tv_sec; + if (va.va_xflags & XFS_XFLAG_IMMUTABLE) + inode->i_flags |= S_IMMUTABLE; + else + inode->i_flags &= ~S_IMMUTABLE; + if (va.va_xflags & XFS_XFLAG_APPEND) + inode->i_flags |= S_APPEND; + else + inode->i_flags &= ~S_APPEND; + if (va.va_xflags & XFS_XFLAG_SYNC) + inode->i_flags |= S_SYNC; + else + inode->i_flags &= ~S_SYNC; + if (va.va_xflags & XFS_XFLAG_NOATIME) + inode->i_flags |= S_NOATIME; + else + inode->i_flags &= ~S_NOATIME; + VUNMODIFY(vp); } return -error; diff -urN -xCVS linux-2.4-xfs.orig/linux/fs/xfs/xfs_acl.c linux-2.4-xfs/linux/fs/xfs/xfs_acl.c --- linux-2.4-xfs.orig/linux/fs/xfs/xfs_acl.c Mon Jul 21 15:06:54 2003 +++ linux-2.4-xfs/linux/fs/xfs/xfs_acl.c Mon Jul 21 15:19:13 2003 @@ -388,6 +388,8 @@ vattr_t va; int error; + if (vp->v_inode.i_flags & (S_IMMUTABLE|S_APPEND)) + return EPERM; if (kind == _ACL_TYPE_DEFAULT && vp->v_type != VDIR) return ENOTDIR; if (vp->v_vfsp->vfs_flag & VFS_RDONLY) diff -urN -xCVS linux-2.4-xfs.orig/linux/fs/xfs/xfs_cap.c linux-2.4-xfs/linux/fs/xfs/xfs_cap.c --- linux-2.4-xfs.orig/linux/fs/xfs/xfs_cap.c Mon Jul 21 15:08:15 2003 +++ linux-2.4-xfs/linux/fs/xfs/xfs_cap.c Mon Jul 21 15:19:13 2003 @@ -192,6 +192,8 @@ if (vp->v_vfsp->vfs_flag & VFS_RDONLY) return EROFS; + if (vp->v_inode.i_flags & (S_IMMUTABLE|S_APPEND)) + return EPERM; if ((error = _MAC_VACCESS(vp, NULL, VWRITE))) return error; va.va_mask = XFS_AT_UID; diff -urN -xCVS linux-2.4-xfs.orig/linux/fs/xfs/xfs_dinode.h linux-2.4-xfs/linux/fs/xfs/xfs_dinode.h --- linux-2.4-xfs.orig/linux/fs/xfs/xfs_dinode.h Mon Jul 21 15:08:29 2003 +++ linux-2.4-xfs/linux/fs/xfs/xfs_dinode.h Mon Jul 21 15:19:13 2003 @@ -468,13 +468,23 @@ * There should be a one-to-one correspondence between these flags and the * XFS_XFLAG_s. */ -#define XFS_DIFLAG_REALTIME_BIT 0 /* file's blocks come from rt area */ -#define XFS_DIFLAG_PREALLOC_BIT 1 /* file space has been preallocated */ -#define XFS_DIFLAG_NEWRTBM_BIT 2 /* for rtbitmap inode, new format */ -#define XFS_DIFLAG_REALTIME (1 << XFS_DIFLAG_REALTIME_BIT) -#define XFS_DIFLAG_PREALLOC (1 << XFS_DIFLAG_PREALLOC_BIT) -#define XFS_DIFLAG_NEWRTBM (1 << XFS_DIFLAG_NEWRTBM_BIT) +#define XFS_DIFLAG_REALTIME_BIT 0 /* file's blocks come from rt area */ +#define XFS_DIFLAG_PREALLOC_BIT 1 /* file space has been preallocated */ +#define XFS_DIFLAG_NEWRTBM_BIT 2 /* for rtbitmap inode, new format */ +#define XFS_DIFLAG_IMMUTABLE_BIT 3 /* inode is immutable */ +#define XFS_DIFLAG_APPEND_BIT 4 /* inode is append-only */ +#define XFS_DIFLAG_SYNC_BIT 5 /* inode is written synchronously */ +#define XFS_DIFLAG_NOATIME_BIT 6 /* do not update atime */ +#define XFS_DIFLAG_REALTIME (1 << XFS_DIFLAG_REALTIME_BIT) +#define XFS_DIFLAG_PREALLOC (1 << XFS_DIFLAG_PREALLOC_BIT) +#define XFS_DIFLAG_NEWRTBM (1 << XFS_DIFLAG_NEWRTBM_BIT) +#define XFS_DIFLAG_IMMUTABLE (1 << XFS_DIFLAG_IMMUTABLE_BIT) +#define XFS_DIFLAG_APPEND (1 << XFS_DIFLAG_APPEND_BIT) +#define XFS_DIFLAG_SYNC (1 << XFS_DIFLAG_SYNC_BIT) +#define XFS_DIFLAG_NOATIME (1 << XFS_DIFLAG_NOATIME_BIT) #define XFS_DIFLAG_ALL \ - (XFS_DIFLAG_REALTIME|XFS_DIFLAG_PREALLOC|XFS_DIFLAG_NEWRTBM) + (XFS_DIFLAG_REALTIME|XFS_DIFLAG_PREALLOC|XFS_DIFLAG_NEWRTBM| \ + XFS_DIFLAG_IMMUTABLE|XFS_DIFLAG_APPEND|XFS_DIFLAG_SYNC| \ + XFS_DIFLAG_NOATIME) #endif /* __XFS_DINODE_H__ */ diff -urN -xCVS linux-2.4-xfs.orig/linux/fs/xfs/xfs_fs.h linux-2.4-xfs/linux/fs/xfs/xfs_fs.h --- linux-2.4-xfs.orig/linux/fs/xfs/xfs_fs.h Mon Jul 21 15:09:27 2003 +++ linux-2.4-xfs/linux/fs/xfs/xfs_fs.h Mon Jul 21 15:19:13 2003 @@ -71,9 +71,14 @@ */ #define XFS_XFLAG_REALTIME 0x00000001 #define XFS_XFLAG_PREALLOC 0x00000002 +#define XFS_XFLAG_IMMUTABLE 0x00000008 +#define XFS_XFLAG_APPEND 0x00000010 +#define XFS_XFLAG_SYNC 0x00000020 +#define XFS_XFLAG_NOATIME 0x00000040 #define XFS_XFLAG_HASATTR 0x80000000 /* no DIFLAG for this */ #define XFS_XFLAG_ALL \ - ( XFS_XFLAG_REALTIME|XFS_XFLAG_PREALLOC|XFS_XFLAG_HASATTR ) + ( XFS_XFLAG_REALTIME|XFS_XFLAG_PREALLOC|XFS_XFLAG_IMMUTABLE| \ + XFS_XFLAG_APPEND|XFS_XFLAG_SYNC|XFS_XFLAG_NOATIME|XFS_XFLAG_HASATTR ) /* diff -urN -xCVS linux-2.4-xfs.orig/linux/fs/xfs/xfs_inode.c linux-2.4-xfs/linux/fs/xfs/xfs_inode.c --- linux-2.4-xfs.orig/linux/fs/xfs/xfs_inode.c Mon Jul 21 15:09:57 2003 +++ linux-2.4-xfs/linux/fs/xfs/xfs_inode.c Mon Jul 21 15:19:13 2003 @@ -3486,6 +3486,9 @@ if (IS_RDONLY(inode) && (S_ISREG(imode) || S_ISDIR(imode) || S_ISLNK(imode))) return XFS_ERROR(EROFS); + + if (IS_IMMUTABLE(inode)) + return XFS_ERROR(EACCES); } /* @@ -3609,7 +3612,7 @@ * Don't update access timestamps on reads if mounted "noatime" * Throw it away if anyone asks us. */ - if (ip->i_mount->m_flags & XFS_MOUNT_NOATIME && + if ((ip->i_mount->m_flags & XFS_MOUNT_NOATIME || IS_NOATIME(inode)) && ((flags & (XFS_ICHGTIME_ACC|XFS_ICHGTIME_MOD|XFS_ICHGTIME_CHG)) == XFS_ICHGTIME_ACC)) return; diff -urN -xCVS linux-2.4-xfs.orig/linux/fs/xfs/xfs_itable.c linux-2.4-xfs/linux/fs/xfs/xfs_itable.c --- linux-2.4-xfs.orig/linux/fs/xfs/xfs_itable.c Mon Jul 21 15:10:06 2003 +++ linux-2.4-xfs/linux/fs/xfs/xfs_itable.c Mon Jul 21 15:19:13 2003 @@ -163,6 +163,14 @@ XFS_XFLAG_REALTIME : 0) | ((di_flags & XFS_DIFLAG_PREALLOC) ? XFS_XFLAG_PREALLOC : 0) | + ((di_flags & XFS_DIFLAG_IMMUTABLE) ? + XFS_XFLAG_IMMUTABLE : 0) | + ((di_flags & XFS_DIFLAG_APPEND) ? + XFS_XFLAG_APPEND : 0) | + ((di_flags & XFS_DIFLAG_SYNC) ? + XFS_XFLAG_SYNC : 0) | + ((di_flags & XFS_DIFLAG_NOATIME) ? + XFS_XFLAG_NOATIME : 0) | (XFS_CFORK_Q_ARCH(dic, arch) ? XFS_XFLAG_HASATTR : 0); diff -urN -xCVS linux-2.4-xfs.orig/linux/fs/xfs/xfs_vnodeops.c linux-2.4-xfs/linux/fs/xfs/xfs_vnodeops.c --- linux-2.4-xfs.orig/linux/fs/xfs/xfs_vnodeops.c Mon Jul 21 15:11:41 2003 +++ linux-2.4-xfs/linux/fs/xfs/xfs_vnodeops.c Mon Jul 21 15:19:13 2003 @@ -266,6 +266,14 @@ XFS_XFLAG_REALTIME : 0) | ((ip->i_d.di_flags & XFS_DIFLAG_PREALLOC) ? XFS_XFLAG_PREALLOC : 0) | + ((ip->i_d.di_flags & XFS_DIFLAG_IMMUTABLE) ? + XFS_XFLAG_IMMUTABLE : 0) | + ((ip->i_d.di_flags & XFS_DIFLAG_APPEND) ? + XFS_XFLAG_APPEND : 0) | + ((ip->i_d.di_flags & XFS_DIFLAG_SYNC) ? + XFS_XFLAG_SYNC : 0) | + ((ip->i_d.di_flags & XFS_DIFLAG_NOATIME) ? + XFS_XFLAG_NOATIME : 0) | (XFS_IFORK_Q(ip) ? XFS_XFLAG_HASATTR : 0); vap->va_extsize = ip->i_d.di_extsize << mp->m_sb.sb_blocklog; @@ -833,6 +841,14 @@ ip->i_d.di_flags |= XFS_DIFLAG_REALTIME; ip->i_iocore.io_flags |= XFS_IOCORE_RT; } + if (vap->va_xflags & XFS_XFLAG_IMMUTABLE) + ip->i_d.di_flags |= XFS_DIFLAG_IMMUTABLE; + if (vap->va_xflags & XFS_XFLAG_APPEND) + ip->i_d.di_flags |= XFS_DIFLAG_APPEND; + if (vap->va_xflags & XFS_XFLAG_SYNC) + ip->i_d.di_flags |= XFS_DIFLAG_SYNC; + if (vap->va_xflags & XFS_XFLAG_NOATIME) + ip->i_d.di_flags |= XFS_DIFLAG_NOATIME; /* can't set PREALLOC this way, just ignore it */ } xfs_trans_log_inode(tp, ip, XFS_ILOG_CORE); --+QahgC5+KEYLbs62 Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="open.c.diff" --- linux.orig/fs/open.c Sun Jun 1 20:39:38 2003 +++ linux/fs/open.c Sun Jun 1 20:54:14 2003 @@ -272,6 +272,9 @@ /* Don't worry, the checks are done in inode_change_ok() */ newattrs.ia_valid = ATTR_CTIME | ATTR_MTIME | ATTR_ATIME; if (times) { + error = -EPERM; + if (IS_APPEND(inode) || IS_IMMUTABLE(inode)) + goto dput_and_out; error = get_user(newattrs.ia_atime, ×->actime); if (!error) error = get_user(newattrs.ia_mtime, ×->modtime); @@ -280,6 +283,9 @@ newattrs.ia_valid |= ATTR_ATIME_SET | ATTR_MTIME_SET; } else { + error = -EACCES; + if (IS_IMMUTABLE(inode)) + goto dput_and_out; if (current->fsuid != inode->i_uid && (error = permission(inode,MAY_WRITE)) != 0) goto dput_and_out; @@ -318,6 +324,9 @@ newattrs.ia_valid = ATTR_CTIME | ATTR_MTIME | ATTR_ATIME; if (utimes) { struct timeval times[2]; + error = -EPERM; + if (IS_APPEND(inode) || IS_IMMUTABLE(inode)) + goto dput_and_out; error = -EFAULT; if (copy_from_user(×, utimes, sizeof(times))) goto dput_and_out; @@ -325,6 +334,10 @@ newattrs.ia_mtime = times[1].tv_sec; newattrs.ia_valid |= ATTR_ATIME_SET | ATTR_MTIME_SET; } else { + error = -EACCES; + if (IS_IMMUTABLE(inode)) + goto dput_and_out; + if (current->fsuid != inode->i_uid && (error = permission(inode,MAY_WRITE)) != 0) goto dput_and_out; --+QahgC5+KEYLbs62-- From owner-linux-xfs@oss.sgi.com Mon Jul 21 18:27:13 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 21 Jul 2003 18:27:31 -0700 (PDT) Received: from loki (firewall.conet.cz [213.175.54.250]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h6M1RBFl018344 for ; Mon, 21 Jul 2003 18:27:13 -0700 Received: from conet.cz (thor [192.168.1.130]) by loki (8.12.8/8.12.8) with ESMTP id h6M1QwSg018360; Tue, 22 Jul 2003 03:26:59 +0200 Message-ID: <3F1C92DE.1090304@conet.cz> Date: Tue, 22 Jul 2003 03:26:54 +0200 From: Libor Vanek User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2.1) Gecko/20030225 X-Accept-Language: en-us, en MIME-Version: 1.0 To: erbenson@alaska.net CC: linux-xfs@oss.sgi.com Subject: Re: Implement immutable/append-only flags in XFS #3 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 4688 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: libor@conet.cz Precedence: bulk X-list: linux-xfs Content-Length: 683 Lines: 25 Hi, just an idea - did you ever thought about implementing NFS v4 (Microsoft compatible) ACLs? (like "DELETE", "READ_ATTRIBUTES","ADD_SUBDIRECTORY" etc. - see http://www.ietf.org/rfc/rfc3530.txt - section 5.11.2). It would be VERY interesting since Samba people need some filesystem which can support this to emulate "native" Windows ACL behaviour not talking about NFS v4. -- Libor Vanek +-------------------------------------+ | Email: libor@conet.cz | | ICQ: 124529939 | | WWW: http://www.discobolos.net | | Tel/fax: +420 541 22 5091, 6293 | | Mobil: +420 777 703 642 | +-------------------------------------+ From owner-linux-xfs@oss.sgi.com Mon Jul 21 18:43:10 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 21 Jul 2003 18:43:17 -0700 (PDT) Received: from hermes.acsalaska.net (hermes.slb.nwc.acsalaska.net [209.112.155.38]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h6M1h9Fl019680 for ; Mon, 21 Jul 2003 18:43:10 -0700 Received: from erbenson.alaska.net (12-pm1.nwc.alaska.net [209.112.138.12]) by hermes.acsalaska.net (8.12.9/8.12.9) with ESMTP id h6M1h7bR015577 for ; Mon, 21 Jul 2003 17:43:07 -0800 (AKDT) (envelope-from erbenson@alaska.net) Received: from plato.local.lan (plato.local.lan [192.168.0.4]) by erbenson.alaska.net (Postfix) with ESMTP id 0ECA13A08 for ; Mon, 21 Jul 2003 17:43:03 -0800 (AKDT) Received: by plato.local.lan (Postfix, from userid 1000) id 6435C40FF44; Mon, 21 Jul 2003 17:43:04 -0800 (AKDT) Date: Mon, 21 Jul 2003 17:43:04 -0800 From: Ethan Benson To: linux-xfs@oss.sgi.com Subject: Re: Implement immutable/append-only flags in XFS #3 Message-ID: <20030722014304.GB13272@plato.local.lan> Mail-Followup-To: linux-xfs@oss.sgi.com References: <3F1C92DE.1090304@conet.cz> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="cvVnyQ+4j833TQvp" Content-Disposition: inline In-Reply-To: <3F1C92DE.1090304@conet.cz> User-Agent: Mutt/1.3.28i X-OS: Debian GNU X-gpg-fingerprint: E3E4 D0BC 31BC F7BB C1DD C3D6 24AC 7B1A 2C44 7AFC X-gpg-key: http://www.alaska.net/~erbenson/gpg/key.asc Mail-Copies-To: nobody X-No-CC: I subscribe to this list; do not CC me on replies. X-ACS-Spam-Status: no X-Scanned-By: MIMEDefang 2.34 X-archive-position: 4689 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: erbenson@alaska.net Precedence: bulk X-list: linux-xfs Content-Length: 914 Lines: 34 --cvVnyQ+4j833TQvp Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Jul 22, 2003 at 03:26:54AM +0200, Libor Vanek wrote: > Hi, > just an idea - did you ever thought about implementing NFS v4 (Microsoft= =20 > compatible) ACLs? (like "DELETE", "READ_ATTRIBUTES","ADD_SUBDIRECTORY"=20 > etc. - see http://www.ietf.org/rfc/rfc3530.txt - section 5.11.2). this requires kernel changes, and should be discussed on the general kernel list. --=20 Ethan Benson http://www.alaska.net/~erbenson/ --cvVnyQ+4j833TQvp Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iEYEARECAAYFAj8clqgACgkQJKx7GixEevzrRQCcCEKKSkcIDoCJioXQRqlNxmEO /QsAnj+YN9nzQWsHeR8AM+viqmTojFLI =vLQo -----END PGP SIGNATURE----- --cvVnyQ+4j833TQvp-- From owner-linux-xfs@oss.sgi.com Mon Jul 21 20:55:38 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 21 Jul 2003 20:55:54 -0700 (PDT) Received: from tolkor.sgi.com (tolkor.sgi.com [198.149.18.6]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h6M3tbFl026974 for ; Mon, 21 Jul 2003 20:55:38 -0700 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by tolkor.sgi.com (8.12.9/8.12.9/linux-outbound_gateway-1.1) with SMTP id h6M4EJsR019984 for ; Mon, 21 Jul 2003 23:14:20 -0500 Received: from omen.melbourne.sgi.com (omen.melbourne.sgi.com [134.14.55.139]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id NAA11159 for ; Tue, 22 Jul 2003 13:55:28 +1000 Received: from melbourne.sgi.com (localhost [127.0.0.1]) by omen.melbourne.sgi.com (SGI-8.12.5/8.12.5) with SMTP id h6M3tRP4355758 for ; Tue, 22 Jul 2003 13:55:27 +1000 (EST) Date: Tue, 22 Jul 2003 13:55:27 +1000 From: Ivan Rayner To: linux-xfs@oss.sgi.com Subject: Re: [PATCH] Implement immutable/append-only flags in XFS #3 Message-Id: <20030722135527.06a94bc2.ivanr@sgi.com> In-Reply-To: <20030722003443.GA13188@plato.local.lan> References: <20030722003443.GA13188@plato.local.lan> Organization: SGI X-Mailer: Sylpheed version 0.9.3claws (GTK+ 1.2.10; mips-sgi-irix6.5) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 4690 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: ivanr@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 1236 Lines: 26 On Mon, 21 Jul 2003 16:34:43 -0800, Ethan Benson wrote: > However during my testing I did discover 3 issues: ... > 2: xfsrestore breaks when immutable or append-only files are included > in the dump. The problem is xfsrestore restores the file inode flags > too soon, and then loses the access it needs to restore extended > attributes, uid, gid, and permissions. I am not familiar enough with > xfsrestore to really propose the fix, however i believe just changing > it to restore at the very least immutable/append-only flags very last > after all other restoration is complete should suffice to solve this > problem. Your explanation makes sense. xfsrestore, at the moment, will restore extended attributes (EAs) after all of the data for the file has been restored. This is important for DMF, where it would be a bad idea for DMF to start operating on a file before it was totally restored because the relevant EA was restored too early. (Tim fixed a bug related to this some time ago.) It probably wouldn't be too difficult to fix xfsrestore to handle the new flags in the same way as extended attributes. ('Course that's easy to say when you haven't looked at any of the code in question ... :) Ivan From owner-linux-xfs@oss.sgi.com Mon Jul 21 21:00:31 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 21 Jul 2003 21:00:35 -0700 (PDT) Received: from tolkor.sgi.com (tolkor.sgi.com [198.149.18.6]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h6M40UFl027662 for ; Mon, 21 Jul 2003 21:00:31 -0700 Received: from flecktone.americas.sgi.com (flecktone.americas.sgi.com [192.48.203.135]) by tolkor.sgi.com (8.12.9/8.12.9/linux-outbound_gateway-1.1) with ESMTP id h6M4JFsR021015 for ; Mon, 21 Jul 2003 23:19:15 -0500 Received: from poppy-e236.americas.sgi.com (poppy-e236.americas.sgi.com [128.162.236.207]) by flecktone.americas.sgi.com (8.12.9/8.12.9/generic_config-1.2) with ESMTP id h6M40P3g231602; Mon, 21 Jul 2003 23:00:25 -0500 (CDT) Received: from stout.americas.sgi.com (stout.americas.sgi.com [128.162.232.50]) by poppy-e236.americas.sgi.com (8.12.9/SGI-server-1.8) with ESMTP id h6M40OYl15159290; Mon, 21 Jul 2003 23:00:24 -0500 (CDT) Date: Mon, 21 Jul 2003 23:00:24 -0500 (CDT) From: Eric Sandeen X-X-Sender: sandeen@stout.americas.sgi.com To: Ethan Benson cc: linux-xfs@oss.sgi.com Subject: Re: [PATCH] Implement immutable/append-only flags in XFS #3 In-Reply-To: <20030722003443.GA13188@plato.local.lan> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 4691 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: sandeen@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 745 Lines: 25 We're very interested in this patch, we just have not had the time to fully vet it & get it applied to the tree. If folks on the list who are interested in this sort of thing could give it a whirl, and report experiences, it would be helpful. In general, the patch looks like a good thing, I/we just need some breathing space to really look at it before we apply it to CVS. Thanks Ethan! -Eric On Mon, 21 Jul 2003, Ethan Benson wrote: > Hi, > > [third revision of my patch, only change is to update it for current > 2.4.21 CVS] > > Over time there has been many requests for ext2 file flags such as > immutable, append-only, sync, noatime be implemented in XFS. > > So, here it is. I have implemented all of the above flags in 2.4.21 From owner-linux-xfs@oss.sgi.com Mon Jul 21 21:07:28 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 21 Jul 2003 21:07:33 -0700 (PDT) Received: from iris.acsalaska.net (iris.slb.nwc.acsalaska.net [209.112.155.43]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h6M47RFl028498 for ; Mon, 21 Jul 2003 21:07:28 -0700 Received: from erbenson.alaska.net (12-pm1.nwc.alaska.net [209.112.138.12]) by iris.acsalaska.net (8.12.9/8.12.9) with ESMTP id h6M47PNk095478 for ; Mon, 21 Jul 2003 20:07:26 -0800 (AKDT) (envelope-from erbenson@alaska.net) Received: from plato.local.lan (plato.local.lan [192.168.0.4]) by erbenson.alaska.net (Postfix) with ESMTP id 102163A08 for ; Mon, 21 Jul 2003 20:07:24 -0800 (AKDT) Received: by plato.local.lan (Postfix, from userid 1000) id 81F1840FF44; Mon, 21 Jul 2003 20:07:24 -0800 (AKDT) Date: Mon, 21 Jul 2003 20:07:24 -0800 From: Ethan Benson To: linux-xfs@oss.sgi.com Subject: Re: [PATCH] Implement immutable/append-only flags in XFS #3 Message-ID: <20030722040724.GD13272@plato.local.lan> Mail-Followup-To: linux-xfs@oss.sgi.com References: <20030722003443.GA13188@plato.local.lan> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="zS7rBR6csb6tI2e1" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.3.28i X-OS: Debian GNU X-gpg-fingerprint: E3E4 D0BC 31BC F7BB C1DD C3D6 24AC 7B1A 2C44 7AFC X-gpg-key: http://www.alaska.net/~erbenson/gpg/key.asc Mail-Copies-To: nobody X-No-CC: I subscribe to this list; do not CC me on replies. X-ACS-Spam-Status: no X-Scanned-By: MIMEDefang 2.31 (www . roaringpenguin . com / mimedefang) X-archive-position: 4692 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: erbenson@alaska.net Precedence: bulk X-list: linux-xfs Content-Length: 1212 Lines: 44 --zS7rBR6csb6tI2e1 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Jul 21, 2003 at 11:00:24PM -0500, Eric Sandeen wrote: > We're very interested in this patch, we just have not had the time > to fully vet it & get it applied to the tree. >=20 > If folks on the list who are interested in this sort of thing could give > it a whirl, and report experiences, it would be helpful. >=20 > In general, the patch looks like a good thing, I/we just need some breath= ing > space to really look at it before we apply it to CVS. I still also want to know if these bits should be inherited by new children of a directory with these bits set. ext2 does this for all of them, IMO it only makes sense for SYNC. > Thanks Ethan! your welcome. --=20 Ethan Benson http://www.alaska.net/~erbenson/ --zS7rBR6csb6tI2e1 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iEYEARECAAYFAj8cuHwACgkQJKx7GixEevygxgCeN7HryJB3zqt8DFRr2gjiBxt2 9CUAnioQEqxDO4Y2AZ3du7lT1R+VbJ47 =r+a5 -----END PGP SIGNATURE----- --zS7rBR6csb6tI2e1-- From owner-linux-xfs@oss.sgi.com Mon Jul 21 21:11:13 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 21 Jul 2003 21:11:18 -0700 (PDT) Received: from malik.acsalaska.net (malik.slb.nwc.acsalaska.net [209.112.155.41]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h6M4BCFl029100 for ; Mon, 21 Jul 2003 21:11:13 -0700 Received: from erbenson.alaska.net (12-pm1.nwc.alaska.net [209.112.138.12]) by malik.acsalaska.net (8.12.9/8.12.9) with ESMTP id h6M4BATa085698 for ; Mon, 21 Jul 2003 20:11:10 -0800 (AKDT) (envelope-from erbenson@alaska.net) Received: from plato.local.lan (plato.local.lan [192.168.0.4]) by erbenson.alaska.net (Postfix) with ESMTP id 9E3C73A08 for ; Mon, 21 Jul 2003 20:11:09 -0800 (AKDT) Received: by plato.local.lan (Postfix, from userid 1000) id 2AA2440FF44; Mon, 21 Jul 2003 20:11:09 -0800 (AKDT) Date: Mon, 21 Jul 2003 20:11:09 -0800 From: Ethan Benson To: linux-xfs@oss.sgi.com Subject: Re: [PATCH] Implement immutable/append-only flags in XFS #3 Message-ID: <20030722041109.GE13272@plato.local.lan> Mail-Followup-To: linux-xfs@oss.sgi.com References: <20030722003443.GA13188@plato.local.lan> <20030722135527.06a94bc2.ivanr@sgi.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="C94crkcyjafcjHxo" Content-Disposition: inline In-Reply-To: <20030722135527.06a94bc2.ivanr@sgi.com> User-Agent: Mutt/1.3.28i X-OS: Debian GNU X-gpg-fingerprint: E3E4 D0BC 31BC F7BB C1DD C3D6 24AC 7B1A 2C44 7AFC X-gpg-key: http://www.alaska.net/~erbenson/gpg/key.asc Mail-Copies-To: nobody X-No-CC: I subscribe to this list; do not CC me on replies. X-ACS-Spam-Status: no X-Scanned-By: MIMEDefang 2.34 X-archive-position: 4693 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: erbenson@alaska.net Precedence: bulk X-list: linux-xfs Content-Length: 2188 Lines: 55 --C94crkcyjafcjHxo Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Jul 22, 2003 at 01:55:27PM +1000, Ivan Rayner wrote: > On Mon, 21 Jul 2003 16:34:43 -0800, Ethan Benson wrote: >=20 > > However during my testing I did discover 3 issues: > ... > > 2: xfsrestore breaks when immutable or append-only files are included > > in the dump. The problem is xfsrestore restores the file inode flags > > too soon, and then loses the access it needs to restore extended > > attributes, uid, gid, and permissions. I am not familiar enough with > > xfsrestore to really propose the fix, however i believe just changing > > it to restore at the very least immutable/append-only flags very last > > after all other restoration is complete should suffice to solve this > > problem. >=20 > Your explanation makes sense. xfsrestore, at the moment, will restore > extended attributes (EAs) after all of the data for the file has been > restored. This is important for DMF, where it would be a bad idea for DMF > to start operating on a file before it was totally restored because the > relevant EA was restored too early. (Tim fixed a bug related to this some > time ago.) >=20 > It probably wouldn't be too difficult to fix xfsrestore to handle the new > flags in the same way as extended attributes. ('Course that's easy to say > when you haven't looked at any of the code in question ... :) it didn't look too difficult to me to change, but I am hesitent to really make the attempt since there are things about xfsdump/xfsrestore for which I don't know (such as ordering issues you describe above). I also don't really want to put much effort into it until the kernel code is actually accepted. --=20 Ethan Benson http://www.alaska.net/~erbenson/ --C94crkcyjafcjHxo Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iEYEARECAAYFAj8cuV0ACgkQJKx7GixEevwHzgCfem4lYWF6VSnirk3UqyO2Wudb xO4An2RWfuKTmVyHqRh0dZ8AQzBACYnB =DJRv -----END PGP SIGNATURE----- --C94crkcyjafcjHxo-- From owner-linux-xfs@oss.sgi.com Mon Jul 21 21:29:29 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 21 Jul 2003 21:29:46 -0700 (PDT) Received: from zok.sgi.com (zok.sgi.com [204.94.215.101]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h6M4TTFl030459 for ; Mon, 21 Jul 2003 21:29:29 -0700 Received: from bruce.melbourne.sgi.com (bruce.melbourne.sgi.com [134.14.54.176]) by zok.sgi.com (8.12.9/8.12.9/linux-outbound_gateway-1.1) with ESMTP id h6M4TMq0012562 for ; Mon, 21 Jul 2003 21:29:23 -0700 Received: from bruce.melbourne.sgi.com (localhost.localdomain [127.0.0.1]) by bruce.melbourne.sgi.com (8.12.8/8.12.8) with ESMTP id h6M4TQ5j011963 for ; Tue, 22 Jul 2003 14:29:26 +1000 Received: (from fsgqa@localhost) by bruce.melbourne.sgi.com (8.12.8/8.12.8/Submit) id h6M4TQLI011962 for linux-xfs@oss.sgi.com; Tue, 22 Jul 2003 14:29:26 +1000 Date: Tue, 22 Jul 2003 14:29:26 +1000 From: FSG QA Message-Id: <200307220429.h6M4TQLI011962@bruce.melbourne.sgi.com> Subject: TAKE - several QA updates X-archive-position: 4694 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: fsgqa@bruce.melbourne.sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 1434 Lines: 61 QA updates for testing xfs_copy. Date: Mon Jul 21 19:38:08 PDT 2003 Workarea: bruce.melbourne.sgi.com:/home/fsgqa/qa/2.4.x-xfs The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: xfs-cmds:slinx:153912a cmd/xfstests/073.out - 1.1 cmd/xfstests/group - 1.31 cmd/xfstests/src/fill2attr - 1.6 cmd/xfstests/073 - 1.2 Remove remaining remnants of rcsid from QA scripts. Date: Mon Jul 21 20:12:14 PDT 2003 Workarea: bruce.melbourne.sgi.com:/home/fsgqa/qa/2.4.x-xfs The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: xfs-cmds:slinx:153914a cmd/xfstests/013 - 1.11 cmd/xfstests/new - 1.9 cmd/xfstests/072 - 1.4 Fix typo in test 072 error message, and add 072 back into auto group now kernel is fixed. Date: Mon Jul 21 20:30:46 PDT 2003 Workarea: bruce.melbourne.sgi.com:/home/fsgqa/qa/2.4.x-xfs The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: xfs-cmds:slinx:153915a cmd/xfstests/group - 1.32 cmd/xfstests/072 - 1.5 Fix up test 071, exercising IO to files at the size boundary, add to auto QA group. Date: Mon Jul 21 21:27:19 PDT 2003 Workarea: bruce.melbourne.sgi.com:/home/fsgqa/qa/2.4.x-xfs The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: xfs-cmds:slinx:153917a cmd/xfstests/group - 1.33 cmd/xfstests/071 - 1.2 cmd/xfstests/071.out - 1.2 From owner-linux-xfs@oss.sgi.com Mon Jul 21 23:28:22 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 21 Jul 2003 23:28:44 -0700 (PDT) Received: from phoenix.infradead.org (pub234.cambridge.redhat.com [213.86.99.234] (may be forged)) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h6M6SKFl004675 for ; Mon, 21 Jul 2003 23:28:22 -0700 Received: from hch by phoenix.infradead.org with local (Exim 4.10) id 19eqdH-0007gR-00; Tue, 22 Jul 2003 07:28:19 +0100 Date: Tue, 22 Jul 2003 07:28:19 +0100 From: Christoph Hellwig To: "HABBINGA,ERIK (HP-Loveland,ex1)" Cc: "'linux-xfs@oss.sgi.com'" Subject: Re: XFS and 2.4.22-pre7? Message-ID: <20030722072819.A29525@infradead.org> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: ; from erik.habbinga@hp.com on Mon, Jul 21, 2003 at 06:28:21PM -0400 X-archive-position: 4695 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: hch@infradead.org Precedence: bulk X-list: linux-xfs Content-Length: 887 Lines: 15 On Mon, Jul 21, 2003 at 06:28:21PM -0400, HABBINGA,ERIK (HP-Loveland,ex1) wrote: > Has anyone tried XFS and the 2.4.22-pre7 patch? I'm successfully running a > CVS drop from June 16, 2003 with the 2.4.22 kernel. Applying the > 2.4.22-pre7 patch and fixing the subsequent compile time issues fails for > me. I would not be surprised if I messed up the compile issues, so I would > like to hear if anyone has had success with XFS and 2.4.22-pre7. I'm > locking up when remounting the root file system (XFS) from read-only to > read-write. The mtab~ file is being written, the mount process calls > sys_write->xfs_write, xfs_write tries to grab a lock, doesn't get it, and > waits patiently (i.e. forever). Do to the fixes for O_DIRECT exploits in other filesystems the locking in generic code has changed quite a bit in 2.4.22-pre. XFS will need changes to take this into account. From owner-linux-xfs@oss.sgi.com Tue Jul 22 06:04:49 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 22 Jul 2003 06:04:53 -0700 (PDT) Received: from beta.dmz-eu.st.com (beta.dmz-eu.st.com [164.129.1.35]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h6MD4lFl027580 for ; Tue, 22 Jul 2003 06:04:48 -0700 Received: from zeta.dmz-eu.st.com (ns2.st.com [164.129.230.9]) by beta.dmz-eu.st.com (STMicroelectronics) with SMTP id B85B2DDDA; Tue, 22 Jul 2003 13:04:41 +0000 (GMT) Received: by zeta.dmz-eu.st.com (STMicroelectronics, from userid 0) id 92728619A; Tue, 22 Jul 2003 13:04:41 +0000 (GMT) Received: from dlx101.dlh.st.com (localhost [127.0.0.1]) by zeta.dmz-eu.st.com (STMicroelectronics) with ESMTP id 69C841845; Tue, 22 Jul 2003 13:04:38 +0000 (GMT) Received: from localhost (root@localhost) by dlx101.dlh.st.com (8.9.3 (PHNE_25183+JAGae58098)/8.9.3) with ESMTP id SAA21826; Tue, 22 Jul 2003 18:34:35 +0530 (IST) From: mahesh.babbar@st.com X-OpenMail-Hops: 1 Date: Tue, 22 Jul 2003 18:34:34 +0530 Message-Id: Subject: Re: XFs stability MIME-Version: 1.0 To: logiplex@qwest.net Cc: mahesh.babbar@st.com, linux-xfs@oss.sgi.com Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline ;Creation-Date="Mon, 21 Jul 2003 10:14:09 -0700" ;Modification-Date="Tue, 22 Jul 2003 18:34:32 +0530" Content-Transfer-Encoding: 7bit X-archive-position: 4696 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: mahesh.babbar@st.com Precedence: bulk X-list: linux-xfs Content-Length: 2604 Lines: 72 Thanks for the response Mike & Cliff, On our server though, which is basically a file server, serving clients files over NFS. We have had 4-5 instances of xfs_shutdown with message like "in-core memory corruption...." . The exact messages are: kerrnel: xfs_force_shutdown(lvm(58,2),0x8) called from line 1035 of file xfs_trans.c. Return address = 0xc01cc10a kernel: Corruption of in-memory data detected. Shutting down filesystem: lvm(58,2) kernel: Please umount the filesystem, and rectify the problem(s) At once, we had lost data even after repairing the filesystem using xfs_repair and that too production data. Clearly, we are a worried lot ! Would appreciate if I can get some information on concrete advantages which XFS has over ext3/2 in terms of stability (specially as a file server, performnace (with figures e.g how much % write/read gain) and features. I believe we are using the XFS version which is as old as July 2001. Regards, Mahesh >Mike Burger wrote >FWIW, I've been running XFS on my server (not a very busy server, >granted) for a couple of years, now, and haven't had any problems. > >On Mon, 21 Jul 2003 mahesh.babbar@st.com wrote: ______________________________ Reply Separator _________________________________ Subject: Re: XFs stability Author: logiplex (logiplex@qwest.net) at internet Date: 7/21/2003 10:44 PM On Mon, 2003-07-21 at 09:20, mahesh.babbar@ST.COM wrote: > Hi , > > I am totally new to XFs world so please bear with me for my ignorance. > > My query is how stable xfs is ? Or let's say which version of it is > most stable. I use XFS exclusively on all my machines (at home and work). This includes several desktops, a laptop, a couple of servers and even my firewall. I've been using it for at least two years. No other available filesystem (well, I haven't tested JFS and probably won't until I've got a 64-bit CPU) matches XFS for performance and reliability. EXT3 is a joke (why *does* it need to fsck?), and ReiserFS, although very interesting, has had numerous problems. My PC's have been turned off, crashed, and even attacked by ferrets without losing data or requiring repair. What more can you ask of a filesystem? Regards, -- Cliff Wells, Software Engineer Logiplex Corporation (www.logiplex.net) (503) 978-6726 (800) 735-0555 From owner-linux-xfs@oss.sgi.com Tue Jul 22 06:19:39 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 22 Jul 2003 06:19:47 -0700 (PDT) Received: from linux-sxs.org (dhcp065-024-128-253.columbus.rr.com [65.24.128.253]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h6MDJcFl028909 for ; Tue, 22 Jul 2003 06:19:39 -0700 Received: from linux-sxs.org (localhost [127.0.0.1]) by linux-sxs.org (8.12.9/8.12.9) with ESMTP id h6MDJZcv006966; Tue, 22 Jul 2003 09:19:35 -0400 Received: from localhost (netllama@localhost) by linux-sxs.org (8.12.9/8.12.9/Submit) with ESMTP id h6MDJZsi020397; Tue, 22 Jul 2003 09:19:35 -0400 Date: Tue, 22 Jul 2003 09:19:35 -0400 (EDT) From: Net Llama! To: mahesh.babbar@st.com cc: linux-xfs@oss.sgi.com Subject: Re: XFs stability In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: OK, scanned by File::Scan,ClamAV X-Scanned-By: MIMEDefang 2.35 X-archive-position: 4697 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: netllama@linux-sxs.org Precedence: bulk X-list: linux-xfs Content-Length: 444 Lines: 12 On Tue, 22 Jul 2003 mahesh.babbar@st.com wrote: > I believe we are using the XFS version which is as old as July 2001. So you're using 2 year old code, and yet you're complaining about instability problems? 2 years is a lifetime in an open source project. -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Lonni J Friedman netllama@linux-sxs.org Linux Step-by-step & TyGeMo http://netllama.ipfox.com From owner-linux-xfs@oss.sgi.com Tue Jul 22 06:22:29 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 22 Jul 2003 06:22:33 -0700 (PDT) Received: from zok.sgi.com (zok.sgi.com [204.94.215.101]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h6MDMSFl029512 for ; Tue, 22 Jul 2003 06:22:29 -0700 Received: from flecktone.americas.sgi.com (flecktone.americas.sgi.com [192.48.203.135]) by zok.sgi.com (8.12.9/8.12.9/linux-outbound_gateway-1.1) with ESMTP id h6MDMNq0006567 for ; Tue, 22 Jul 2003 06:22:23 -0700 Received: from daisy-e236.americas.sgi.com (daisy-e236.americas.sgi.com [128.162.236.214]) by flecktone.americas.sgi.com (8.12.9/8.12.9/generic_config-1.2) with ESMTP id h6MDLM3g242009; Tue, 22 Jul 2003 08:21:22 -0500 (CDT) Received: from [192.168.1.100] (cf-vpn-sw-corp-64-86.corp.sgi.com [134.15.64.86]) by daisy-e236.americas.sgi.com (8.12.9/SGI-server-1.8) with ESMTP id h6MDLKRn179914977; Tue, 22 Jul 2003 08:21:21 -0500 (CDT) Subject: Re: XFs stability From: Steve Lord To: mahesh.babbar@st.com Cc: logiplex@qwest.net, linux-xfs@oss.sgi.com In-Reply-To: References: Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.8 (1.0.8-11) Date: 22 Jul 2003 08:21:12 -0500 Message-Id: <1058880074.1328.9.camel@laptop.americas.sgi.com> Mime-Version: 1.0 X-archive-position: 4698 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: lord@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 1412 Lines: 35 On Tue, 2003-07-22 at 08:04, mahesh.babbar@st.com wrote: > Thanks for the response Mike & Cliff, > > On our server though, which is basically a file server, serving > clients files over NFS. We have had 4-5 instances of xfs_shutdown > with message like "in-core memory corruption...." . > > The exact messages are: > > kerrnel: xfs_force_shutdown(lvm(58,2),0x8) called from line 1035 of > file xfs_trans.c. Return address = 0xc01cc10a > kernel: Corruption of in-memory data detected. Shutting down > filesystem: lvm(58,2) > kernel: Please umount the filesystem, and rectify the problem(s) > > At once, we had lost data even after repairing the filesystem using > xfs_repair and that too production data. Clearly, we are a worried lot > ! > > Would appreciate if I can get some information on concrete advantages > which XFS has over ext3/2 in terms of stability (specially as a file > server, performnace (with figures e.g how much % write/read gain) and > features. > > I believe we are using the XFS version which is as old as July 2001. It is really difficult to have sympathy for you if you are running 2 year old code. There have been a vast number of improvements in the code since then. As for advantages/disadvantages, I will leave that to other folks. Steve From owner-linux-xfs@oss.sgi.com Tue Jul 22 07:33:54 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 22 Jul 2003 07:34:14 -0700 (PDT) Received: from beta.dmz-eu.st.com (beta.dmz-eu.st.com [164.129.1.35]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h6MEXhFl011466 for ; Tue, 22 Jul 2003 07:33:44 -0700 Received: from zeta.dmz-eu.st.com (ns2.st.com [164.129.230.9]) by beta.dmz-eu.st.com (STMicroelectronics) with SMTP id 47B11DDD7; Tue, 22 Jul 2003 13:59:27 +0000 (GMT) Received: by zeta.dmz-eu.st.com (STMicroelectronics, from userid 0) id 22C8161BD; Tue, 22 Jul 2003 13:59:27 +0000 (GMT) Received: from dlx101.dlh.st.com (localhost [127.0.0.1]) by zeta.dmz-eu.st.com (STMicroelectronics) with ESMTP id C03FC1849; Tue, 22 Jul 2003 13:59:25 +0000 (GMT) Received: from localhost (root@localhost) by dlx101.dlh.st.com (8.9.3 (PHNE_25183+JAGae58098)/8.9.3) with ESMTP id TAA27044; Tue, 22 Jul 2003 19:29:23 +0530 (IST) From: mahesh.babbar@st.com X-OpenMail-Hops: 1 Date: Tue, 22 Jul 2003 19:29:22 +0530 Message-Id: In-Reply-To: <1058880074.1328.9.camel@laptop.americas.sgi.com> Subject: Re: XFs stability MIME-Version: 1.0 To: lord@sgi.com Cc: mahesh.babbar@st.com, logiplex@qwest.net, linux-xfs@oss.sgi.com Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline ;Creation-Date="Tue, 22 Jul 2003 08:21:12 -0500" ;Modification-Date="Tue, 22 Jul 2003 19:29:20 +0530" Content-Transfer-Encoding: 7bit X-archive-position: 4699 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: mahesh.babbar@st.com Precedence: bulk X-list: linux-xfs Content-Length: 2052 Lines: 56 Agreed Steve and Lonnie. It's all my fault that I am on an ancient code ! But as they 'once bitten twice shy', I am yet to gather courage to keep working with XFS. We have servers working on ext2/ext3 w/o a glitch. That's why I said unless I see 'silverline on dark clouds' i,e those 'extra' advantages XFS provide over others, I would like to play safe. Mahesh ______________________________ Reply Separator _________________________________ Subject: Re: XFs stability Author: lord (lord@sgi.com) at internet Date: 7/22/2003 6:51 PM On Tue, 2003-07-22 at 08:04, mahesh.babbar@st.com wrote: > Thanks for the response Mike & Cliff, > > On our server though, which is basically a file server, serving > clients files over NFS. We have had 4-5 instances of xfs_shutdown > with message like "in-core memory corruption...." . > > The exact messages are: > > kerrnel: xfs_force_shutdown(lvm(58,2),0x8) called from line 1035 of > file xfs_trans.c. Return address = 0xc01cc10a > kernel: Corruption of in-memory data detected. Shutting down > filesystem: lvm(58,2) > kernel: Please umount the filesystem, and rectify the problem(s) > > At once, we had lost data even after repairing the filesystem using > xfs_repair and that too production data. Clearly, we are a worried lot > ! > > Would appreciate if I can get some information on concrete advantages > which XFS has over ext3/2 in terms of stability (specially as a file > server, performnace (with figures e.g how much % write/read gain) and > features. > > I believe we are using the XFS version which is as old as July 2001. It is really difficult to have sympathy for you if you are running 2 year old code. There have been a vast number of improvements in the code since then. As for advantages/disadvantages, I will leave that to other folks. Steve From owner-linux-xfs@oss.sgi.com Tue Jul 22 07:39:27 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 22 Jul 2003 07:39:30 -0700 (PDT) Received: from linux-sxs.org (dhcp065-024-128-253.columbus.rr.com [65.24.128.253]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h6MEdQFl012066 for ; Tue, 22 Jul 2003 07:39:26 -0700 Received: from linux-sxs.org (localhost [127.0.0.1]) by linux-sxs.org (8.12.9/8.12.9) with ESMTP id h6MEdNcv029909; Tue, 22 Jul 2003 10:39:23 -0400 Received: from localhost (netllama@localhost) by linux-sxs.org (8.12.9/8.12.9/Submit) with ESMTP id h6MEdMZ2032532; Tue, 22 Jul 2003 10:39:23 -0400 Date: Tue, 22 Jul 2003 10:39:22 -0400 (EDT) From: Net Llama! To: mahesh.babbar@st.com cc: linux-xfs@oss.sgi.com Subject: Re: XFs stability In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: OK, scanned by File::Scan,ClamAV X-Scanned-By: MIMEDefang 2.35 X-archive-position: 4700 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: netllama@linux-sxs.org Precedence: bulk X-list: linux-xfs Content-Length: 920 Lines: 23 On Tue, 22 Jul 2003 mahesh.babbar@st.com wrote: > > Agreed Steve and Lonnie. It's all my fault that I am on an ancient > code ! > > But as they 'once bitten twice shy', I am yet to gather courage to > keep working with XFS. > > We have servers working on ext2/ext3 w/o a glitch. That's why I said > unless I see 'silverline on dark clouds' i,e those 'extra' advantages > XFS provide over others, I would like to play safe. It sounds like you already made up your mind what you want to do. Are you also running ext3 on a 2 year old kernel? I think if you're going to compare, it needs to be an equitable comparison. I know i've had horrible experiences with ext3, and never a single problem with XFS. -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Lonni J Friedman netllama@linux-sxs.org Linux Step-by-step & TyGeMo http://netllama.ipfox.com From owner-linux-xfs@oss.sgi.com Tue Jul 22 10:27:52 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 22 Jul 2003 10:28:06 -0700 (PDT) Received: from mail.broadpark.no (mail.broadpark.no [217.13.4.2]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h6MHRpFl025578 for ; Tue, 22 Jul 2003 10:27:52 -0700 Received: from online.no (126.80-202-103.nextgentel.com [80.202.103.126]) by mail.broadpark.no (Postfix) with ESMTP id 4EA2978F3F; Tue, 22 Jul 2003 19:27:45 +0200 (MEST) Message-ID: <3F1D740D.9681141F@online.no> Date: Tue, 22 Jul 2003 19:27:42 +0200 From: Knut J Bjuland X-Mailer: Mozilla 4.8 [en] (X11; U; Linux 2.4.20-18.9XFS1.3.0pre2custom i686) X-Accept-Language: en MIME-Version: 1.0 To: Eric Sandeen Cc: linux-xfs@oss.sgi.com Subject: Re: xfs support in redhat beta sever. References: <3F1C4CB2.849E5E79@online.no> <1058820623.10294.187.camel@stout.americas.sgi.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-archive-position: 4701 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: knutjbj@online.no Precedence: bulk X-list: linux-xfs Content-Length: 1440 Lines: 39 I have update the Redhat beta kernel up to 1.3pre2, and added linux-2.4.20-xfs-inode-init.patch along with linux-2.4.20-xfs-nptl. However I am unable to add linux-2.4.20-nolock_write.patch since it applies unclean. Is this bug relative to O_Directe. /BUILD/kernel-2.4.21/linux-2.4.21/arch/i386/lib/lib.a --end-group -o .tmp_vmlinux1 fs/fs.o(.text+0xa130c): In function `xfs_write': : undefined reference to `generic_file_write_nolock' make[1]: *** [kallsyms] Error 1 Eric Sandeen wrote: > The xfs code in severn is going to take a bit of work just to compile, > red hat has not done any integration work for xfs with the rest of their > changes. > > The fix below is the easy one, o_direct changes are probably trickier > (if this kernel is similar to other recent RH kernels I've seen) > > -Eric > > On Mon, 2003-07-21 at 15:27, Knut J Bjuland wrote: > > xfs file system does not compile with kernel from redhat in severn. > > Linux-2.4.20-xfs-ntpl .path does not apply cleanly since there has been > > some change in xfs code in ac kernel. I'll try to update to cvs and > > repatch it with linux-2.4.20-xfs-nptl....... > > > > > > xfs_syncd.c: In function `syncd': > > xfs_syncd.c:52: structure has no member named `sigmask_lock' > > xfs_syncd.c:54: too many arguments to function `recalc_sigpending' > > > -- > Eric Sandeen [C]XFS for Linux http://oss.sgi.com/projects/xfs > sandeen@sgi.com SGI, Inc. 651-683-3102 From owner-linux-xfs@oss.sgi.com Tue Jul 22 10:55:13 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 22 Jul 2003 10:55:32 -0700 (PDT) Received: from phoenix.infradead.org (pub234.cambridge.redhat.com [213.86.99.234] (may be forged)) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h6MHtBFl027509 for ; Tue, 22 Jul 2003 10:55:12 -0700 Received: from hch by phoenix.infradead.org with local (Exim 4.10) id 19f1Lx-0003Yh-00; Tue, 22 Jul 2003 18:55:09 +0100 Date: Tue, 22 Jul 2003 18:55:09 +0100 From: Christoph Hellwig To: Knut J Bjuland Cc: Eric Sandeen , linux-xfs@oss.sgi.com Subject: Re: xfs support in redhat beta sever. Message-ID: <20030722185509.A12598@infradead.org> References: <3F1C4CB2.849E5E79@online.no> <1058820623.10294.187.camel@stout.americas.sgi.com> <3F1D740D.9681141F@online.no> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <3F1D740D.9681141F@online.no>; from knutjbj@online.no on Tue, Jul 22, 2003 at 07:27:42PM +0200 X-archive-position: 4702 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: hch@infradead.org Precedence: bulk X-list: linux-xfs Content-Length: 387 Lines: 10 On Tue, Jul 22, 2003 at 07:27:42PM +0200, Knut J Bjuland wrote: > /BUILD/kernel-2.4.21/linux-2.4.21/arch/i386/lib/lib.a --end-group -o > .tmp_vmlinux1 > fs/fs.o(.text+0xa130c): In function `xfs_write': > : undefined reference to `generic_file_write_nolock' > make[1]: *** [kallsyms] Error 1 Just change the XFS code to use do_generic_file_write for now if you don't care for O_DIRECT. From owner-linux-xfs@oss.sgi.com Wed Jul 23 08:37:12 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 23 Jul 2003 08:37:30 -0700 (PDT) Received: from heretic.physik.fu-berlin.de (root@heretic.physik.fu-berlin.de [160.45.32.86]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h6NFbAFl030850 for ; Wed, 23 Jul 2003 08:37:11 -0700 Received: from puariko.homeip.net (pD9E7D6DD.dip.t-dialin.net [217.231.214.221]) by heretic.physik.fu-berlin.de (8.12.8/8.12.8) with ESMTP id h6NFb6w8012069 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 23 Jul 2003 17:37:08 +0200 Received: (from thimm@localhost) by puariko.nirvana (8.12.8/8.12.8/Submit) id h6NFb5o5007024; Wed, 23 Jul 2003 17:37:05 +0200 Date: Wed, 23 Jul 2003 17:37:05 +0200 From: Axel Thimm To: linux-xfs Subject: Re: kernel-2.4.20-19.9.3.at: latest RHL 9 errata & XFS 1.2 Message-ID: <20030723153705.GA6882@puariko.nirvana> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="J2SCkAp4GZ/dPZZf" Content-Disposition: inline User-Agent: Mutt/1.4.1i X-archive-position: 4703 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: Axel.Thimm@physik.fu-berlin.de Precedence: bulk X-list: linux-xfs Content-Length: 1103 Lines: 39 --J2SCkAp4GZ/dPZZf Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable I have merged in the XFS patches from 1.2 into the latest release RedHat kernel for Red Hat 9. You can find them under http://atrpms.physik.fu-berlin.de/name/kernel/ Note that there are also some additional patches. * base kernel sources: Taken from redhat errata (2.4.20-19.9) * XFS: merged patches found in 1.2 * i2c-2.7.0 and lm_sensors-2.7.0. You should also get the updated userland tools. * (note: only available upon request) 3ware kernel driver update for Escalade 7xxx series. Try to keep in sync with your firmware and userland tools. * v4l2-api (from http://bytesex.org/v4l/) --=20 Axel.Thimm@physik.fu-berlin.de --J2SCkAp4GZ/dPZZf Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2 (GNU/Linux) iD8DBQE/HquhQBVS1GOamfERAg9UAJ4gDB7AKBzWJKRfZ7avD9gt6t+ixQCdGs+j ujGXxeD9OYhcF8utZpX7SrQ= =+LRu -----END PGP SIGNATURE----- --J2SCkAp4GZ/dPZZf-- From owner-linux-xfs@oss.sgi.com Wed Jul 23 11:49:21 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 23 Jul 2003 11:49:36 -0700 (PDT) Received: from campbell.mps.ohio-state.edu (campbell.mps.ohio-state.edu [128.146.38.12]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h6NInLFl013826 for ; Wed, 23 Jul 2003 11:49:21 -0700 Received: from mps.ohio-state.edu (babar5.mps.ohio-state.edu [128.146.38.43]) by campbell.mps.ohio-state.edu (8.12.9/8.12.9) with ESMTP id h6NInKMX031897 for ; Wed, 23 Jul 2003 14:49:20 -0400 (EDT) Message-ID: <3F1ED8B0.5040407@mps.ohio-state.edu> Date: Wed, 23 Jul 2003 14:49:20 -0400 From: Dirk Hufnagel User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030714 X-Accept-Language: en-us, en MIME-Version: 1.0 To: linux-xfs@oss.sgi.com Subject: kernel bug in rmap.c:398 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 4704 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: hufnagel@mps.ohio-state.edu Precedence: bulk X-list: linux-xfs Content-Length: 2376 Lines: 64 I am running a customized Redhat 2.4.20-18.7 kernel (updated 3ware driver, i2c and lm_sensors) on a dual Athlon server (Tyan S2460S, 2GB, dual MP2000) with two 3ware IDE raid adapter (7810 with 40GB Raid1 and 200GB Raid1, 7850 with 840GB Raid5). This setup seemed to run stable while using reiserfs on the Raid5 (heavy load for about three weeks). Since I wasn't happy with the performance of the Raid5 array, I switched over to xfs. I took the 2.4.20-18.9 kernel src rpm from the XFS 1.2 Redhat 9 installer iso, extracted the xfs specific patches and applied them to my customized 2.4.20-18.7 kernel source area. The conversion to xfs went fine and performance was much better then with reiserfs. After about a weeks running under heavy load, the machine crashed with the following error : kernel BUG at rmap.c:398! invalid operand: 0000 CPU: 1 EIP: 0010:[] Tainted: PF Using defaults from ksymoops -t elf32-i386 -a i386 EFLAGS: 00010246 eax: 00000000 ebx: f2ef5163 ecx: fffe3000 edx: 000f2ef5 esi: 00350000 edi: c1000030 ebp: fffe3d40 esp: c44c5f48 ds: 0018 es: 0018 ss: 0018 Process kswapd (pid: 5, stackpage=c44c5000) Stack: 014c5c00 00000000 c1030ce8 c1030ce8 c1030ce8 00000006 c03265c0 ffffffff c013e86a 014c5c00 c1030ce8 c0139a00 c03b7c20 00000000 c03265c0 c1030ce8 c1030ce8 c03265c0 00000000 c0134c94 00000000 0000003f c03265c0 c0326f78 Call Trace: [] (0xc44c5f68)) [] (0xc44c5f74)) [] (0xc44c5f94)) [] (0xc44c5fac)) [] (0xc44c5fcc)) [] (0xc44c5fe8)) [] (0xc44c5ff0)) [] (0xc44c5ff8)) Running the output through ksymoops gives : >>EIP; c013e73b <===== >>ebx; f2ef5163 <_end+32af4047/38523ee4> >>edi; c1000030 <_end+bfef14/38523ee4> >>esp; c44c5f48 <_end+40c4e2c/38523ee4> Trace; c013e86a Trace; c0139a00 Trace; c0134c94 Trace; c01370c9 Trace; c0137d5b Trace; c0105000 <_stext+0/0> Trace; c0105706 Trace; c0137900 This doesn't look like xfs caused the problem, but before I post a bugreport to bugzilla.redhat.com, I would like to know if the problem might be related to the kernel core patches I applied to get xfs to work. Dirk From owner-linux-xfs@oss.sgi.com Wed Jul 23 11:57:34 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 23 Jul 2003 11:57:37 -0700 (PDT) Received: from phoenix.infradead.org (pub234.cambridge.redhat.com [213.86.99.234] (may be forged)) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h6NIvXFl015940 for ; Wed, 23 Jul 2003 11:57:34 -0700 Received: from hch by phoenix.infradead.org with local (Exim 4.10) id 19fOns-0007DE-00; Wed, 23 Jul 2003 19:57:32 +0100 Date: Wed, 23 Jul 2003 19:57:32 +0100 From: Christoph Hellwig To: Dirk Hufnagel Cc: linux-xfs@oss.sgi.com Subject: Re: kernel bug in rmap.c:398 Message-ID: <20030723195732.A27725@infradead.org> References: <3F1ED8B0.5040407@mps.ohio-state.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <3F1ED8B0.5040407@mps.ohio-state.edu>; from hufnagel@mps.ohio-state.edu on Wed, Jul 23, 2003 at 02:49:20PM -0400 X-archive-position: 4705 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: hch@infradead.org Precedence: bulk X-list: linux-xfs Content-Length: 397 Lines: 8 On Wed, Jul 23, 2003 at 02:49:20PM -0400, Dirk Hufnagel wrote: > This doesn't look like xfs caused the problem, but before I post a bugreport > to bugzilla.redhat.com, I would like to know if the problem might be related > to the kernel core patches I applied to get xfs to work. This is very very unlikely to be related to the XFS patches in anyway. Unfortunately I doubt RH will care anyway.. From owner-linux-xfs@oss.sgi.com Wed Jul 23 13:59:01 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 23 Jul 2003 13:59:44 -0700 (PDT) Received: from tolkor.sgi.com (tolkor.SGI.COM [198.149.18.6]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h6NKwxFl027653 for ; Wed, 23 Jul 2003 13:59:00 -0700 Received: from flecktone.americas.sgi.com (flecktone.americas.sgi.com [192.48.203.135]) by tolkor.sgi.com (8.12.9/8.12.9/linux-outbound_gateway-1.1) with ESMTP id h6NLHcsR019097 for ; Wed, 23 Jul 2003 16:17:38 -0500 Received: from daisy-e236.americas.sgi.com (daisy-e236.americas.sgi.com [128.162.236.214]) by flecktone.americas.sgi.com (8.12.9/8.12.9/generic_config-1.2) with ESMTP id h6NKvs3g711331; Wed, 23 Jul 2003 15:57:54 -0500 (CDT) Received: from [128.162.232.98] (rose.americas.sgi.com [128.162.232.98]) by daisy-e236.americas.sgi.com (8.12.9/SGI-server-1.8) with ESMTP id h6NKvrRn180246397; Wed, 23 Jul 2003 15:57:53 -0500 (CDT) Subject: Re: xfs support in redhat beta sever. From: Russell Cattelan To: Knut J Bjuland Cc: linux-xfs@oss.sgi.com In-Reply-To: <3F1C4CB2.849E5E79@online.no> References: <3F1C4CB2.849E5E79@online.no> Content-Type: multipart/mixed; boundary="=-nr+iXrIxRFQ2Xe1lMWPE" Message-Id: <1058993760.34654.42.camel@rose.americas.sgi.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.3 Date: 23 Jul 2003 15:56:01 -0500 X-archive-position: 4706 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: cattelan@xfs.org Precedence: bulk X-list: linux-xfs Content-Length: 192503 Lines: 6532 --=-nr+iXrIxRFQ2Xe1lMWPE Content-Type: text/plain Content-Transfer-Encoding: 7bit This patch will bring the latest beta tree up-to-date with XFS 1.3pre4 ... (yes pre4 will be out soon) It isn't the cleanest patch but it does appear to function correctly. On Mon, 2003-07-21 at 15:27, Knut J Bjuland wrote: > xfs file system does not compile with kernel from redhat in severn. > Linux-2.4.20-xfs-ntpl .path does not apply cleanly since there has been > some change in xfs code in ac kernel. I'll try to update to cvs and > repatch it with linux-2.4.20-xfs-nptl....... > > > xfs_syncd.c: In function `syncd': > xfs_syncd.c:52: structure has no member named `sigmask_lock' > xfs_syncd.c:54: too many arguments to function `recalc_sigpending' > > > --=-nr+iXrIxRFQ2Xe1lMWPE Content-Disposition: attachment; filename=xfs-RHbeta.patch Content-Type: text/x-patch; name=xfs-RHbeta.patch; charset=UTF-8 Content-Transfer-Encoding: 7bit diff --exclude=dmapi -rNu ORIG/fs/inode.c HACK/fs/inode.c --- ORIG/fs/inode.c 2003-07-23 09:17:11.000000000 -0500 +++ HACK/fs/inode.c 2003-07-23 10:09:39.000000000 -0500 @@ -141,6 +141,11 @@ void inode_init_once(struct inode *inode) { memset(inode, 0, sizeof(*inode)); + _inode_init_once(inode); +} + +void _inode_init_once(struct inode *inode) +{ init_waitqueue_head(&inode->i_wait); INIT_LIST_HEAD(&inode->i_hash); INIT_LIST_HEAD(&inode->i_data.clean_pages); diff --exclude=dmapi -rNu ORIG/fs/xfs/linux/Makefile HACK/fs/xfs/linux/Makefile --- ORIG/fs/xfs/linux/Makefile 2003-07-23 09:16:37.000000000 -0500 +++ HACK/fs/xfs/linux/Makefile 2003-06-02 11:53:19.000000000 -0500 @@ -55,7 +55,6 @@ xfs_iomap.o \ xfs_iops.o \ xfs_lrw.o \ - xfs_syncd.o \ xfs_super.o \ xfs_vfs.o \ xfs_vnode.o diff --exclude=dmapi -rNu ORIG/fs/xfs/linux/xfs_aops.c HACK/fs/xfs/linux/xfs_aops.c --- ORIG/fs/xfs/linux/xfs_aops.c 2003-07-23 09:16:37.000000000 -0500 +++ HACK/fs/xfs/linux/xfs_aops.c 2003-07-23 12:41:40.000000000 -0500 @@ -93,6 +93,7 @@ XFS_BUF_SET_FSPRIVATE(bp, NULL); XFS_BUF_CLR_IODONE_FUNC(bp); XFS_BUF_UNDATAIO(bp); + iput(LINVFS_GET_IP(vp)); pagebuf_iodone(bp, 0, 0); } @@ -375,7 +376,16 @@ pb = pagebuf_lookup(mp->pbm_target, mp->pbm_offset, mp->pbm_bsize, 0); if (!pb) - return -ENOMEM; + return -EAGAIN; + + /* Take a reference to the inode to prevent it from + * being reclaimed while we have outstanding unwritten + * extent IO on it. + */ + if ((igrab(inode)) != inode) { + pagebuf_free(pb); + return -EAGAIN; + } /* Set the count to 1 initially, this will stop an I/O * completion callout which happens before we have started @@ -433,8 +443,7 @@ if (page) { nblocks += bs; atomic_add(bs, &pb->pb_io_remaining); - convert_page(inode, page, - mp, pb, 1, all_bh); + convert_page(inode, page, mp, pb, 1, all_bh); } } } @@ -598,11 +607,11 @@ STATIC int page_state_convert( + struct inode *inode, struct page *page, int startio, int unmapped) /* also implies page uptodate */ { - struct inode *inode = page->mapping->host; struct buffer_head *bh_arr[MAX_BUF_PER_PAGE], *bh, *head; page_buf_bmap_t *mp, map; unsigned long p_offset = 0, end_index; @@ -888,10 +897,10 @@ create, 1, BMAP_WRITE|BMAP_DIRECT); } -STATIC int +STATIC sector_t linvfs_bmap( struct address_space *mapping, - long block) + sector_t block) { struct inode *inode = (struct inode *)mapping->host; vnode_t *vp = LINVFS_GET_VP(inode); @@ -959,7 +968,6 @@ * the page, we have to check the process flags first, if we * are already in a transaction or disk I/O during allocations * is off, we need to fail the writepage and redirty the page. - * We also need to set PF_NOIO ourselves. */ STATIC int @@ -970,6 +978,7 @@ int need_trans; int delalloc, unmapped, unwritten; struct inode *inode = page->mapping->host; + xfs_pflags_t pflags; /* * We need a transaction if: @@ -996,7 +1005,7 @@ * as is. */ - if ((current->flags & (PF_FSTRANS|PF_NOIO)) && need_trans) + if ((PFLAGS_TEST_FSTRANS() || PFLAGS_TEST_NOIO()) && need_trans) goto out_fail; /* @@ -1011,10 +1020,10 @@ * to real space and flush out to disk. */ if (need_trans) - current->flags |= PF_NOIO; - error = page_state_convert(page, 1, unmapped); + PFLAGS_SET_NOIO(&pflags); + error = page_state_convert(inode, page, 1, unmapped); if (need_trans) - current->flags &= ~PF_NOIO; + PFLAGS_RESTORE(&pflags); if (error == -EAGAIN) goto out_fail; @@ -1055,6 +1064,7 @@ struct page *page, int gfp_mask) { + struct inode *inode = page->mapping->host; int delalloc, unmapped, unwritten; count_page_state(page, &delalloc, &unmapped, &unwritten); @@ -1070,7 +1080,7 @@ * Never need to allocate space here - we will always * come back to writepage in that case. */ - return (page_state_convert(page, 0, 0) == 0) ? 1 : 0; + return (page_state_convert(inode, page, 0, 0) == 0) ? 1 : 0; } STATIC int @@ -1092,14 +1102,17 @@ /* * Initiate I/O on a kiobuf of user memory */ + STATIC int linvfs_direct_IO( int rw, - struct file *file, + struct inode *inode, struct kiobuf *iobuf, - unsigned long blocknr, + sector_t blocknr, int blocksize) { + struct page **maplist; + size_t page_offset; page_buf_t *pb; page_buf_bmap_t map; int error = 0; @@ -1107,15 +1120,15 @@ size_t length, total; loff_t offset; size_t map_size, size; - struct inode *inode = file->f_dentry->d_inode; vnode_t *vp = LINVFS_GET_VP(inode); - struct page **maplist = iobuf->maplist; - size_t page_offset = iobuf->offset; total = length = iobuf->length; offset = blocknr; offset <<= inode->i_blkbits; + maplist = iobuf->maplist; + page_offset = iobuf->offset; + map_flags = (rw ? BMAP_WRITE : BMAP_READ) | BMAP_DIRECT; pb_flags = (rw ? PBF_WRITE : PBF_READ) | PBF_FORCEIO; while (length) { @@ -1176,6 +1189,8 @@ XFS_BUF_DATAIO(pb); if (map.pbm_flags & PBMF_UNWRITTEN) { + if ((igrab(inode)) != inode) + BUG(); XFS_BUF_SET_FSPRIVATE(pb, vp); XFS_BUF_SET_IODONE_FUNC(pb, linvfs_unwritten_conv); } @@ -1184,6 +1199,8 @@ pagebuf_rele(pb); if (error) { + if (map.pbm_flags & PBMF_UNWRITTEN) + iput(inode); if (error > 0) error = -error; break; @@ -1202,6 +1219,38 @@ return (error ? error : (int)(total - length)); } +STATIC int +linvfs_direct_IO_filp(int rw, + struct file * filp, + struct kiobuf * iobuf, + sector_t blocknr, + int blocksize) { + struct inode * inode = filp->f_dentry->d_inode->i_mapping->host; + linvfs_direct_IO(rw, inode, iobuf, blocknr, blocksize); +} + + +/* since the address_space_operations are not consitent with the type used + * for block indexes we must cast the functions into what is expected.. + * thus the following 2 lines. + * If running on a kernel with LBD support and hence bmap and direct_IO + * correctly defined with sector_t params. use the second set of typedefs + * or casts from the address space_operations + * RMC + */ + +#define RHBETA +#ifndef HAVE_SECTOR_T +typedef int (bmap_proc)(struct address_space *, long); +typedef int (direct_IO_proc)(int, struct inode *, struct kiobuf *, unsigned long, int); +#endif + +#if defined(RHBETA) +typedef int (direct_IO_filp_proc)(int, struct file *, struct kiobuf *, unsigned long, int); +#endif + + + struct address_space_operations linvfs_aops = { .readpage = linvfs_readpage, .writepage = linvfs_writepage, @@ -1209,6 +1258,14 @@ .releasepage = linvfs_release_page, .prepare_write = linvfs_prepare_write, .commit_write = generic_commit_write, +#if defined(HAVE_SECTOR_T) && !defined(RHBETA) + .bmap = (bmap_proc *)linvfs_bmap, + .direct_IO = (direct_IO_proc *)linvfs_direct_IO, +#elif defined(RHBETA) + .bmap = (bmap_proc *)linvfs_bmap, + .direct_IO = (direct_IO_filp_proc *)linvfs_direct_IO_filp, +#else .bmap = linvfs_bmap, .direct_IO = linvfs_direct_IO, +#endif }; diff --exclude=dmapi -rNu ORIG/fs/xfs/linux/xfs_globals.c HACK/fs/xfs/linux/xfs_globals.c --- ORIG/fs/xfs/linux/xfs_globals.c 2003-07-23 09:16:37.000000000 -0500 +++ HACK/fs/xfs/linux/xfs_globals.c 2003-07-08 11:02:08.000000000 -0500 @@ -36,8 +36,11 @@ */ #include "xfs.h" +#include "xfs_macros.h" +#include "xfs_types.h" #include "xfs_bmap_btree.h" #include "xfs_bit.h" +#include "xfs_rw.h" /* * System memory size - used to scale certain data structures in XFS. @@ -48,7 +51,19 @@ * Tunable XFS parameters. xfs_params is required even when CONFIG_SYSCTL=n, * other XFS code uses these values. */ -xfs_param_t xfs_params = { 128, 32, 0, 1, 0, 0, 0, 3, 30 * HZ }; + +xfs_param_t xfs_params = { + /* MIN DFLT MAX */ + .refcache_size = { 0, 128, XFS_REFCACHE_SIZE_MAX }, + .refcache_purge = { 0, 32, XFS_REFCACHE_SIZE_MAX }, + .restrict_chown = { 0, 1, 1 }, + .sgid_inherit = { 0, 0, 1 }, + .symlink_mode = { 0, 0, 1 }, + .panic_mask = { 0, 0, 127 }, + .error_level = { 0, 3, 11 }, + .sync_interval = { HZ, 30*HZ, 60*HZ }, + .stats_clear = { 0, 0, 1 }, +}; /* * Global system credential structure. @@ -62,3 +77,83 @@ #if ARCH_CONVERT != ARCH_NOCONVERT EXPORT_SYMBOL(xfs_bmbt_disk_get_all); #endif + +#if defined(CONFIG_XFS_DEBUG) +#include "xfs_inum.h" +#include "xfs_log.h" +#include "xfs_trans.h" +#include "xfs_sb.h" +#include "xfs_ag.h" +#include "xfs_dir.h" +#include "xfs_dir2.h" +#include "xfs_dmapi.h" +#include "xfs_mount.h" +#include "xfs_alloc_btree.h" +#include "xfs_ialloc_btree.h" +#include "xfs_btree.h" +#include "xfs_imap.h" +#include "xfs_alloc.h" +#include "xfs_ialloc.h" +#include "xfs_attr_sf.h" +#include "xfs_dir_sf.h" +#include "xfs_dir2_sf.h" +#include "xfs_dir2_data.h" +#include "xfs_dinode.h" +#include "xfs_inode_item.h" +#include "xfs_inode.h" +#include "xfs_bmap.h" +#include "xfs_buf_item.h" +#include "xfs_rw.h" +#include "xfs_error.h" +#include "xfs_utils.h" +#include "xfs_dir2_trace.h" +#include "xfs_quota.h" +#include "xfs_mac.h" +#include "xfs_acl.h" +#include "xfs_da_btree.h" +#include "xfs_dir_leaf.h" +#include "xfs_dir2_data.h" +#include "xfs_dir2_leaf.h" +#include "xfs_dir2_block.h" +#include "xfs_dir2_node.h" +#include "xfs_dir2_sf.h" +#include "xfs_dir2_trace.h" +#include "xfs_attr.h" +#include "xfs_attr_leaf.h" + +extern ktrace_t *xfs_alloc_trace_buf; + +EXPORT_SYMBOL(xfs_fsb_to_agbno); +EXPORT_SYMBOL(xfs_dir2_data_unused_tag_p_arch); +EXPORT_SYMBOL(xfs_attr_leaf_name_remote); +EXPORT_SYMBOL(xfs_lic_slot); +EXPORT_SYMBOL(xfs_dir2_sf_firstentry); +EXPORT_SYMBOL(xfs_ino_to_agno); +EXPORT_SYMBOL(xfs_dir2_sf_get_inumber_arch); +EXPORT_SYMBOL(xfs_ifork_q); +EXPORT_SYMBOL(xfs_dir2_data_entry_tag_p); +EXPORT_SYMBOL(xfs_dir2_sf_inumberp); +EXPORT_SYMBOL(xfs_dir2_data_entsize); +EXPORT_SYMBOL(xfs_lic_isfree); +EXPORT_SYMBOL(xfs_attr_leaf_name_local); +EXPORT_SYMBOL(xfs_bmap_broot_ptr_addr); +EXPORT_SYMBOL(xfs_dir_sf_get_dirino_arch); +EXPORT_SYMBOL(xfs_alloc_trace_buf); +EXPORT_SYMBOL(xfs_ino_to_agbno); +EXPORT_SYMBOL(xfs_fsb_to_agno); +EXPORT_SYMBOL(xfs_dir2_leaf_bests_p_arch); +EXPORT_SYMBOL(xfs_dir2_sf_get_offset_arch); +EXPORT_SYMBOL(startblockval); +EXPORT_SYMBOL(xfs_attr_sf_nextentry); +EXPORT_SYMBOL(xfs_bmap_broot_key_addr); +EXPORT_SYMBOL(xfs_dir2_block_leaf_p_arch); +EXPORT_SYMBOL(xfs_mtovfs); +EXPORT_SYMBOL(xfs_dir_leaf_namestruct); +EXPORT_SYMBOL(xfs_ino_to_offset); +EXPORT_SYMBOL(xfs_itobhv); +EXPORT_SYMBOL(xfs_ifork_ptr); +EXPORT_SYMBOL(isnullstartblock); +EXPORT_SYMBOL(xfs_lic_are_all_free); +EXPORT_SYMBOL(xfs_dir_sf_nextentry); +EXPORT_SYMBOL(xfs_dir2_sf_nextentry); +#endif diff --exclude=dmapi -rNu ORIG/fs/xfs/linux/xfs_iomap.c HACK/fs/xfs/linux/xfs_iomap.c --- ORIG/fs/xfs/linux/xfs_iomap.c 2003-07-23 09:16:37.000000000 -0500 +++ HACK/fs/xfs/linux/xfs_iomap.c 2003-07-15 22:08:36.000000000 -0500 @@ -1,5 +1,5 @@ /* - * Copyright (c) 2000-2002 Silicon Graphics, Inc. All Rights Reserved. + * Copyright (c) 2000-2003 Silicon Graphics, Inc. All Rights Reserved. * * This program is free software; you can redistribute it and/or modify it * under the terms of version 2 of the GNU General Public License as @@ -172,8 +172,11 @@ BUG(); } + ASSERT(offset <= mp->m_maxioffset); + if ((xfs_fsize_t)offset + count > mp->m_maxioffset) + count = mp->m_maxioffset - offset; + end_fsb = XFS_B_TO_FSB(mp, (xfs_ufsize_t)offset + count); offset_fsb = XFS_B_TO_FSBT(mp, offset); - end_fsb = XFS_B_TO_FSB(mp, ((xfs_ufsize_t)(offset + count))); error = XFS_BMAPI(mp, NULL, io, offset_fsb, (xfs_filblks_t)(end_fsb - offset_fsb) , diff --exclude=dmapi -rNu ORIG/fs/xfs/linux/xfs_iops.c HACK/fs/xfs/linux/xfs_iops.c --- ORIG/fs/xfs/linux/xfs_iops.c 2003-07-23 09:16:37.000000000 -0500 +++ HACK/fs/xfs/linux/xfs_iops.c 2003-06-10 12:32:21.000000000 -0500 @@ -157,8 +157,10 @@ if (S_ISCHR(mode) || S_ISBLK(mode)) ip->i_rdev = to_kdev_t(rdev); - validate_fields(dir); + else if (S_ISDIR(mode)) + validate_fields(ip); d_instantiate(dentry, ip); + validate_fields(dir); } if (!error && have_default_acl) { diff --exclude=dmapi -rNu ORIG/fs/xfs/linux/xfs_linux.h HACK/fs/xfs/linux/xfs_linux.h --- ORIG/fs/xfs/linux/xfs_linux.h 2003-07-23 09:16:37.000000000 -0500 +++ HACK/fs/xfs/linux/xfs_linux.h 2003-07-23 12:12:12.000000000 -0500 @@ -101,11 +101,15 @@ bh->b_end_io = linvfs_unwritten_done; } -#define restricted_chown xfs_params.restrict_chown -#define irix_sgid_inherit xfs_params.sgid_inherit -#define irix_symlink_mode xfs_params.symlink_mode -#define xfs_panic_mask xfs_params.panic_mask -#define xfs_error_level xfs_params.error_level +#define xfs_refcache_size xfs_params.refcache_size.val +#define xfs_refcache_purge_count xfs_params.refcache_purge.val +#define restricted_chown xfs_params.restrict_chown.val +#define irix_sgid_inherit xfs_params.sgid_inherit.val +#define irix_symlink_mode xfs_params.symlink_mode.val +#define xfs_panic_mask xfs_params.panic_mask.val +#define xfs_error_level xfs_params.error_level.val +#define xfs_syncd_interval xfs_params.sync_interval.val +#define xfs_stats_clear xfs_params.stats_clear.val #define NBPP PAGE_SIZE #define DPPSHFT (PAGE_SHIFT - 9) diff --exclude=dmapi -rNu ORIG/fs/xfs/linux/xfs_lrw.c HACK/fs/xfs/linux/xfs_lrw.c --- ORIG/fs/xfs/linux/xfs_lrw.c 2003-07-23 09:16:37.000000000 -0500 +++ HACK/fs/xfs/linux/xfs_lrw.c 2003-07-15 22:25:33.000000000 -0500 @@ -174,7 +174,7 @@ } - n = XFS_MAX_FILE_OFFSET - *offset; + n = XFS_MAXIOFFSET(mp) - *offset; if ((n <= 0) || (size == 0)) return 0; @@ -381,7 +381,8 @@ } ASSERT(nimaps > 0); - if (imap.br_startblock == HOLESTARTBLOCK) { + if (imap.br_state == XFS_EXT_UNWRITTEN || + imap.br_startblock == HOLESTARTBLOCK) { /* * This loop handles initializing pages that were * partially initialized by the code below this @@ -454,7 +455,7 @@ ssize_t ret; int error = 0; xfs_fsize_t isize, new_size; - xfs_fsize_t n, limit = XFS_MAX_FILE_OFFSET; + xfs_fsize_t n, limit; xfs_iocore_t *io; vnode_t *vp; int iolock; @@ -500,6 +501,7 @@ xfs_ilock(xip, XFS_ILOCK_EXCL|iolock); isize = xip->i_d.di_size; + limit = XFS_MAXIOFFSET(mp); if (file->f_flags & O_APPEND) *offset = isize; @@ -589,7 +591,7 @@ xfs_inval_cached_pages(vp, &xip->i_iocore, *offset, 1, 1); } - ret = do_generic_file_write(file, buf, size, offset); + ret = generic_file_write_nolock(file, buf, size, offset); if (unlikely(file->f_mode & FINVIS)) { /* generic_file_write updates the mtime/ctime but we need @@ -809,29 +811,23 @@ return (xfs_bioerror_relse(bp)); } - -void -XFS_bflush(xfs_buftarg_t *target) -{ - pagebuf_delwri_flush(target, PBDF_WAIT, NULL); -} - /* - * If the underlying (log or data) device is readonly, there are some + * If the underlying (data/log/rt) device is readonly, there are some * operations that cannot proceed. */ int -xfs_dev_is_read_only(xfs_mount_t *mp, char *message) +xfs_dev_is_read_only( + xfs_mount_t *mp, + char *message) { - if (is_read_only(mp->m_ddev_targp->pbr_kdev) || - is_read_only(mp->m_logdev_targp->pbr_kdev) || - (mp->m_rtdev_targp && is_read_only(mp->m_rtdev_targp->pbr_kdev))) { + if (xfs_readonly_buftarg(mp->m_ddev_targp) || + xfs_readonly_buftarg(mp->m_logdev_targp) || + (mp->m_rtdev_targp && xfs_readonly_buftarg(mp->m_rtdev_targp))) { cmn_err(CE_NOTE, "XFS: %s required on read-only device.", message); cmn_err(CE_NOTE, "XFS: write access unavailable, cannot proceed."); return EROFS; } - return 0; } diff --exclude=dmapi -rNu ORIG/fs/xfs/linux/xfs_super.c HACK/fs/xfs/linux/xfs_super.c --- ORIG/fs/xfs/linux/xfs_super.c 2003-07-23 09:16:37.000000000 -0500 +++ HACK/fs/xfs/linux/xfs_super.c 2003-07-23 10:06:13.000000000 -0500 @@ -75,7 +75,7 @@ STATIC kmem_cache_t * linvfs_inode_cachep; STATIC struct xfs_mount_args * -args_allocate( +xfs_args_allocate( struct super_block *sb) { struct xfs_mount_args *args; @@ -94,6 +94,40 @@ return args; } +__uint64_t +xfs_max_file_offset( + unsigned int blockshift) +{ + unsigned int pagefactor = 1; + unsigned int bitshift = BITS_PER_LONG - 1; + + /* Figure out maximum filesize, on Linux this can depend on + * the filesystem blocksize (on 32 bit platforms). + * __block_prepare_write does this in an [unsigned] long... + * page->index << (PAGE_CACHE_SHIFT - bbits) + * So, for page sized blocks (4K on 32 bit platforms), + * this wraps at around 8Tb (hence MAX_LFS_FILESIZE which is + * (((u64)PAGE_CACHE_SIZE << (BITS_PER_LONG-1))-1) + * but for smaller blocksizes it is less (bbits = log2 bsize). + * Note1: get_block_t takes a long (implicit cast from above) + * Note2: The Large Block Device (LBD and HAVE_SECTOR_T) patch + * can optionally convert the [unsigned] long from above into + * an [unsigned] long long. + */ + +#if BITS_PER_LONG == 32 +# if defined(HAVE_SECTOR_T) + ASSERT(sizeof(sector_t) == 8); + pagefactor = PAGE_CACHE_SIZE; + bitshift = BITS_PER_LONG; +# else + pagefactor = PAGE_CACHE_SIZE >> (PAGE_CACHE_SHIFT - blockshift); +# endif +#endif + + return (((__uint64_t)pagefactor) << bitshift) - 1; +} + STATIC __inline__ void xfs_set_inodeops( struct inode *inode) @@ -233,13 +267,27 @@ } void -xfs_free_buftarg( +xfs_flush_buftarg( xfs_buftarg_t *btp) { pagebuf_delwri_flush(btp, PBDF_WAIT, NULL); +} + +void +xfs_free_buftarg( + xfs_buftarg_t *btp) +{ + xfs_flush_buftarg(btp); kmem_free(btp, sizeof(*btp)); } +int +xfs_readonly_buftarg( + xfs_buftarg_t *btp) +{ + return is_read_only(btp->pbr_kdev); +} + void xfs_relse_buftarg( xfs_buftarg_t *btp) @@ -300,20 +348,14 @@ return btp; } -STATIC __inline__ unsigned int gfp_mask(void) -{ - /* If we're not in a transaction, FS activity is ok */ - if (current->flags & PF_FSTRANS) return GFP_NOFS; - return GFP_KERNEL; -} - STATIC struct inode * linvfs_alloc_inode( struct super_block *sb) { vnode_t *vp; - vp = (vnode_t *)kmem_cache_alloc(linvfs_inode_cachep, gfp_mask()); + vp = (vnode_t *)kmem_cache_alloc(linvfs_inode_cachep, + kmem_flags_convert(KM_SLEEP)); if (!vp) return NULL; return LINVFS_GET_IP(vp); @@ -340,20 +382,8 @@ if ((flags & (SLAB_CTOR_VERIFY|SLAB_CTOR_CONSTRUCTOR)) == SLAB_CTOR_CONSTRUCTOR) { struct inode *inode = LINVFS_GET_IP(vp); - memset(vp, 0, VNODE_SIZE); - init_waitqueue_head(&inode->i_wait); - INIT_LIST_HEAD(&inode->i_hash); - INIT_LIST_HEAD(&inode->i_data.clean_pages); - INIT_LIST_HEAD(&inode->i_data.dirty_pages); - INIT_LIST_HEAD(&inode->i_data.locked_pages); - INIT_LIST_HEAD(&inode->i_dentry); - INIT_LIST_HEAD(&inode->i_dirty_buffers); - INIT_LIST_HEAD(&inode->i_dirty_data_buffers); - INIT_LIST_HEAD(&inode->i_devices); - sema_init(&inode->i_sem, 1); - sema_init(&inode->i_zombie, 1); - spin_lock_init(&inode->i_data.i_shared_lock); + _inode_init_once(inode); } } @@ -414,6 +444,68 @@ } } + +#define SYNCD_FLAGS (SYNC_FSDATA|SYNC_BDFLUSH|SYNC_ATTR|SYNC_REFCACHE) + +STATIC int +syncd(void *arg) +{ + vfs_t *vfsp = (vfs_t *) arg; + int error; + + daemonize(); + reparent_to_init(); + sigmask_lock(); + sigfillset(¤t->blocked); + recalc_sigpending_(current); + sigmask_unlock(); + + sprintf(current->comm, "xfssyncd"); + + vfsp->vfs_sync_task = current; + wmb(); + wake_up(&vfsp->vfs_wait_sync_task); + + for (;;) { + set_current_state(TASK_INTERRUPTIBLE); + schedule_timeout(xfs_syncd_interval); + if (vfsp->vfs_flag & VFS_UMOUNT) + break; + if (vfsp->vfs_flag & VFS_RDONLY) + continue; + VFS_SYNC(vfsp, SYNCD_FLAGS, NULL, error); + } + + vfsp->vfs_sync_task = NULL; + wmb(); + wake_up(&vfsp->vfs_wait_sync_task); + + return 0; +} + +STATIC int +linvfs_start_syncd(vfs_t *vfsp) +{ + int pid; + + pid = kernel_thread(syncd, (void *) vfsp, + CLONE_VM | CLONE_FS | CLONE_FILES); + if (pid < 0) + return pid; + wait_event(vfsp->vfs_wait_sync_task, vfsp->vfs_sync_task); + return 0; +} + +STATIC void +linvfs_stop_syncd(vfs_t *vfsp) +{ + vfsp->vfs_flag |= VFS_UMOUNT; + wmb(); + + wake_up_process(vfsp->vfs_sync_task); + wait_event(vfsp->vfs_wait_sync_task, !vfsp->vfs_sync_task); +} + STATIC void linvfs_put_super( struct super_block *sb) @@ -423,9 +515,8 @@ linvfs_stop_syncd(vfsp); VFS_SYNC(vfsp, SYNC_ATTR|SYNC_DELWRI, NULL, error); - if (error == 0) { + if (!error) VFS_UNMOUNT(vfsp, 0, NULL, error); - } if (error) { printk("XFS unmount got error %d\n", error); printk("%s: vfsp/0x%p left dangling!\n", __FUNCTION__, vfsp); @@ -460,7 +551,7 @@ int error; VFS_STATVFS(vfsp, statp, NULL, error); - return error; + return -error; } STATIC int @@ -470,29 +561,24 @@ char *options) { vfs_t *vfsp = LINVFS_GET_VFS(sb); - struct xfs_mount_args *args = args_allocate(sb); + struct xfs_mount_args *args = xfs_args_allocate(sb); int error; VFS_PARSEARGS(vfsp, options, args, 1, error); - if (error) - goto out; - - VFS_MNTUPDATE(vfsp, flags, args, error); - -out: + if (!error) + VFS_MNTUPDATE(vfsp, flags, args, error); kmem_free(args, sizeof(*args)); - return error; + return -error; } STATIC void linvfs_freeze_fs( struct super_block *sb) { - vfs_t *vfsp; + vfs_t *vfsp = LINVFS_GET_VFS(sb); vnode_t *vp; int error; - vfsp = LINVFS_GET_VFS(sb); if (sb->s_flags & MS_RDONLY) return; VFS_ROOT(vfsp, &vp, error); @@ -504,11 +590,10 @@ linvfs_unfreeze_fs( struct super_block *sb) { - vfs_t *vfsp; + vfs_t *vfsp = LINVFS_GET_VFS(sb); vnode_t *vp; int error; - vfsp = LINVFS_GET_VFS(sb); VFS_ROOT(vfsp, &vp, error); VOP_IOCTL(vp, LINVFS_GET_IP(vp), NULL, XFS_IOC_THAW, 0, error); VN_RELE(vp); @@ -682,7 +767,7 @@ { vnode_t *rootvp; struct vfs *vfsp = vfs_allocate(); - struct xfs_mount_args *args = args_allocate(sb); + struct xfs_mount_args *args = xfs_args_allocate(sb); struct statfs statvfs; int error; @@ -699,7 +784,6 @@ } sb_min_blocksize(sb, BBSIZE); - sb->s_maxbytes = XFS_MAX_FILE_OFFSET; sb->s_qcop = &linvfs_qops; sb->s_op = &linvfs_sops; @@ -714,9 +798,10 @@ goto fail_unmount; sb->s_dirt = 1; - sb->s_magic = XFS_SB_MAGIC; + sb->s_magic = statvfs.f_type; sb->s_blocksize = statvfs.f_bsize; sb->s_blocksize_bits = ffs(statvfs.f_bsize) - 1; + sb->s_maxbytes = xfs_max_file_offset(sb->s_blocksize_bits); set_posix_acl_flag(sb); VFS_ROOT(vfsp, &rootvp, error); diff --exclude=dmapi -rNu ORIG/fs/xfs/linux/xfs_super.h HACK/fs/xfs/linux/xfs_super.h --- ORIG/fs/xfs/linux/xfs_super.h 2003-07-23 09:16:37.000000000 -0500 +++ HACK/fs/xfs/linux/xfs_super.h 2003-07-23 12:12:11.000000000 -0500 @@ -66,6 +66,12 @@ # define XFS_REALTIME_STRING #endif +#if XFS_BIG_FILESYSTEMS +# define XFS_BIGFS_STRING "big filesystems, " +#else +# define XFS_BIGFS_STRING +#endif + #ifdef CONFIG_XFS_VNODE_TRACING # define XFS_VNTRACE_STRING "VN-trace, " #else @@ -80,6 +86,7 @@ #define XFS_BUILD_OPTIONS XFS_ACL_STRING \ XFS_REALTIME_STRING \ + XFS_BIGFS_STRING \ XFS_VNTRACE_STRING \ XFS_DBG_STRING /* DBG must be last */ @@ -92,6 +99,8 @@ struct pb_target; struct block_device; +extern __uint64_t xfs_max_file_offset(unsigned int); + extern struct inode *xfs_get_inode(bhv_desc_t *, xfs_ino_t, int); extern void xfs_initialize_vnode(bhv_desc_t *, vnode_t *, bhv_desc_t *, int); @@ -102,10 +111,9 @@ extern struct pb_target *xfs_alloc_buftarg(struct block_device *); extern void xfs_relse_buftarg(struct pb_target *); extern void xfs_free_buftarg(struct pb_target *); - +extern void xfs_flush_buftarg(struct pb_target *); +extern int xfs_readonly_buftarg(struct pb_target *); extern void xfs_setsize_buftarg(struct pb_target *, unsigned int, unsigned int); extern unsigned int xfs_getsize_buftarg(struct pb_target *); -extern int linvfs_start_syncd(vfs_t *); -extern void linvfs_stop_syncd(vfs_t *); #endif /* __XFS_SUPER_H__ */ diff --exclude=dmapi -rNu ORIG/fs/xfs/linux/xfs_sysctl.c HACK/fs/xfs/linux/xfs_sysctl.c --- ORIG/fs/xfs/linux/xfs_sysctl.c 2003-07-23 09:16:37.000000000 -0500 +++ HACK/fs/xfs/linux/xfs_sysctl.c 2003-07-08 09:00:23.000000000 -0500 @@ -36,12 +36,6 @@ #include -STATIC ulong xfs_min[XFS_PARAM] = { \ - 0, 0, 0, 0, 0, 0, 0, 0, HZ }; -STATIC ulong xfs_max[XFS_PARAM] = { \ - XFS_REFCACHE_SIZE_MAX, XFS_REFCACHE_SIZE_MAX, - 1, 1, 1, 1, 127, 11, HZ * 60 }; - static struct ctl_table_header *xfs_table_header; @@ -65,13 +59,14 @@ if (!ret && write && xfs_refcache_new_size != xfs_refcache_old_size) { xfs_refcache_resize(xfs_refcache_new_size); /* Don't purge more than size of the cache */ - if (xfs_refcache_new_size < xfs_params.refcache_purge) - xfs_params.refcache_purge = xfs_refcache_new_size; + if (xfs_refcache_new_size < xfs_refcache_purge_count) + xfs_refcache_purge_count = xfs_refcache_new_size; } return ret; } +#ifdef CONFIG_PROC_FS STATIC int xfs_stats_clear_proc_handler( ctl_table *ctl, @@ -91,48 +86,62 @@ vn_active = xfsstats.vn_active; memset(&xfsstats, 0, sizeof(xfsstats)); xfsstats.vn_active = vn_active; - xfs_params.stats_clear = 0; + xfs_stats_clear = 0; } return ret; } +#endif /* CONFIG_PROC_FS */ STATIC ctl_table xfs_table[] = { - {XFS_REFCACHE_SIZE, "refcache_size", &xfs_params.refcache_size, + {XFS_REFCACHE_SIZE, "refcache_size", &xfs_params.refcache_size.val, sizeof(ulong), 0644, NULL, &xfs_refcache_resize_proc_handler, - &sysctl_intvec, NULL, &xfs_min[0], &xfs_max[0]}, + &sysctl_intvec, NULL, + &xfs_params.refcache_size.min, &xfs_params.refcache_size.max}, - {XFS_REFCACHE_PURGE, "refcache_purge", &xfs_params.refcache_purge, + /* Note, the max here is different, it is the current refcache size */ + {XFS_REFCACHE_PURGE, "refcache_purge", &xfs_params.refcache_purge.val, sizeof(ulong), 0644, NULL, &proc_doulongvec_minmax, - &sysctl_intvec, NULL, &xfs_min[1], &xfs_params.refcache_size}, - - {XFS_STATS_CLEAR, "stats_clear", &xfs_params.stats_clear, - sizeof(ulong), 0644, NULL, &xfs_stats_clear_proc_handler, - &sysctl_intvec, NULL, &xfs_min[2], &xfs_max[2]}, + &sysctl_intvec, NULL, + &xfs_params.refcache_purge.min, &xfs_params.refcache_size.val}, - {XFS_RESTRICT_CHOWN, "restrict_chown", &xfs_params.restrict_chown, + {XFS_RESTRICT_CHOWN, "restrict_chown", &xfs_params.restrict_chown.val, sizeof(ulong), 0644, NULL, &proc_doulongvec_minmax, - &sysctl_intvec, NULL, &xfs_min[3], &xfs_max[3]}, + &sysctl_intvec, NULL, + &xfs_params.restrict_chown.min, &xfs_params.restrict_chown.max}, - {XFS_SGID_INHERIT, "irix_sgid_inherit", &xfs_params.sgid_inherit, + {XFS_SGID_INHERIT, "irix_sgid_inherit", &xfs_params.sgid_inherit.val, sizeof(ulong), 0644, NULL, &proc_doulongvec_minmax, - &sysctl_intvec, NULL, &xfs_min[4], &xfs_max[4]}, + &sysctl_intvec, NULL, + &xfs_params.sgid_inherit.min, &xfs_params.sgid_inherit.max}, - {XFS_SYMLINK_MODE, "irix_symlink_mode", &xfs_params.symlink_mode, + {XFS_SYMLINK_MODE, "irix_symlink_mode", &xfs_params.symlink_mode.val, sizeof(ulong), 0644, NULL, &proc_doulongvec_minmax, - &sysctl_intvec, NULL, &xfs_min[5], &xfs_max[5]}, + &sysctl_intvec, NULL, + &xfs_params.symlink_mode.min, &xfs_params.symlink_mode.max}, - {XFS_PANIC_MASK, "panic_mask", &xfs_params.panic_mask, + {XFS_PANIC_MASK, "panic_mask", &xfs_params.panic_mask.val, sizeof(ulong), 0644, NULL, &proc_doulongvec_minmax, - &sysctl_intvec, NULL, &xfs_min[6], &xfs_max[6]}, + &sysctl_intvec, NULL, + &xfs_params.panic_mask.min, &xfs_params.panic_mask.max}, - {XFS_ERRLEVEL, "error_level", &xfs_params.error_level, + {XFS_ERRLEVEL, "error_level", &xfs_params.error_level.val, sizeof(ulong), 0644, NULL, &proc_doulongvec_minmax, - &sysctl_intvec, NULL, &xfs_min[7], &xfs_max[7]}, + &sysctl_intvec, NULL, + &xfs_params.error_level.min, &xfs_params.error_level.max}, - {XFS_SYNC_INTERVAL, "sync_interval", &xfs_params.sync_interval, + {XFS_SYNC_INTERVAL, "sync_interval", &xfs_params.sync_interval.val, sizeof(ulong), 0644, NULL, &proc_doulongvec_minmax, - &sysctl_intvec, NULL, &xfs_min[8], &xfs_max[8]}, + &sysctl_intvec, NULL, + &xfs_params.sync_interval.min, &xfs_params.sync_interval.max}, + + /* please keep this the last entry */ +#ifdef CONFIG_PROC_FS + {XFS_STATS_CLEAR, "stats_clear", &xfs_params.stats_clear.val, + sizeof(ulong), 0644, NULL, &xfs_stats_clear_proc_handler, + &sysctl_intvec, NULL, + &xfs_params.stats_clear.min, &xfs_params.stats_clear.max}, +#endif /* CONFIG_PROC_FS */ {0} }; diff --exclude=dmapi -rNu ORIG/fs/xfs/linux/xfs_sysctl.h HACK/fs/xfs/linux/xfs_sysctl.h --- ORIG/fs/xfs/linux/xfs_sysctl.h 2003-07-23 09:16:37.000000000 -0500 +++ HACK/fs/xfs/linux/xfs_sysctl.h 2003-07-23 12:12:12.000000000 -0500 @@ -39,19 +39,24 @@ * Tunable xfs parameters */ -#define XFS_PARAM (sizeof(struct xfs_param) / sizeof(ulong)) +typedef struct xfs_sysctl_val { + ulong min; + ulong val; + ulong max; +} xfs_sysctl_val_t; typedef struct xfs_param { - ulong refcache_size; /* Size of NFS reference cache. */ - ulong refcache_purge; /* # of entries to purge each time. */ - ulong stats_clear; /* Reset all XFS statistics to zero. */ - ulong restrict_chown; /* Root/non-root can give away files. */ - ulong sgid_inherit; /* Inherit ISGID bit if process' GID is */ - /* not a member of the parent dir GID. */ - ulong symlink_mode; /* Symlink creat mode affected by umask. */ - ulong panic_mask; /* bitmask to specify panics on errors. */ - ulong error_level; /* Degree of reporting for internal probs*/ - ulong sync_interval; /* time between sync calls */ + xfs_sysctl_val_t refcache_size; /* Size of NFS reference cache. */ + xfs_sysctl_val_t refcache_purge;/* # of entries to purge each time. */ + xfs_sysctl_val_t restrict_chown;/* Root/non-root can give away files.*/ + xfs_sysctl_val_t sgid_inherit; /* Inherit ISGID bit if process' GID + * is not a member of the parent dir + * GID */ + xfs_sysctl_val_t symlink_mode; /* Link creat mode affected by umask */ + xfs_sysctl_val_t panic_mask; /* bitmask to cause panic on errors. */ + xfs_sysctl_val_t error_level; /* Degree of reporting for problems */ + xfs_sysctl_val_t sync_interval; /* time between sync calls */ + xfs_sysctl_val_t stats_clear; /* Reset all XFS statistics to zero. */ } xfs_param_t; /* @@ -72,13 +77,13 @@ enum { XFS_REFCACHE_SIZE = 1, XFS_REFCACHE_PURGE = 2, - XFS_STATS_CLEAR = 3, - XFS_RESTRICT_CHOWN = 4, - XFS_SGID_INHERIT = 5, - XFS_SYMLINK_MODE = 6, - XFS_PANIC_MASK = 7, - XFS_ERRLEVEL = 8, - XFS_SYNC_INTERVAL = 9, + XFS_RESTRICT_CHOWN = 3, + XFS_SGID_INHERIT = 4, + XFS_SYMLINK_MODE = 5, + XFS_PANIC_MASK = 6, + XFS_ERRLEVEL = 7, + XFS_SYNC_INTERVAL = 8, + XFS_STATS_CLEAR = 9, }; extern xfs_param_t xfs_params; diff --exclude=dmapi -rNu ORIG/fs/xfs/linux/xfs_version.h HACK/fs/xfs/linux/xfs_version.h --- ORIG/fs/xfs/linux/xfs_version.h 2003-07-23 09:16:37.000000000 -0500 +++ HACK/fs/xfs/linux/xfs_version.h 2003-06-13 12:18:27.000000000 -0500 @@ -39,6 +39,6 @@ #ifndef __XFS_VERSION_H__ #define __XFS_VERSION_H__ -#define XFS_VERSION_STRING "SGI XFS" +#define XFS_VERSION_STRING "SGI XFS 1.3.0pre2" #endif /* __XFS_VERSION_H__ */ diff --exclude=dmapi -rNu ORIG/fs/xfs/linux/xfs_vfs.c HACK/fs/xfs/linux/xfs_vfs.c --- ORIG/fs/xfs/linux/xfs_vfs.c 2003-07-23 09:16:37.000000000 -0500 +++ HACK/fs/xfs/linux/xfs_vfs.c 2003-06-02 11:53:22.000000000 -0500 @@ -252,7 +252,6 @@ vfsp = kmem_zalloc(sizeof(vfs_t), KM_SLEEP); bhv_head_init(VFS_BHVHEAD(vfsp), "vfs"); init_waitqueue_head(&vfsp->vfs_wait_sync_task); - init_waitqueue_head(&vfsp->vfs_sync); return vfsp; } diff --exclude=dmapi -rNu ORIG/fs/xfs/linux/xfs_vfs.h HACK/fs/xfs/linux/xfs_vfs.h --- ORIG/fs/xfs/linux/xfs_vfs.h 2003-07-23 09:16:37.000000000 -0500 +++ HACK/fs/xfs/linux/xfs_vfs.h 2003-07-23 12:12:12.000000000 -0500 @@ -49,7 +49,6 @@ bhv_head_t vfs_bh; /* head of vfs behavior chain */ struct super_block *vfs_super; /* Linux superblock structure */ struct task_struct *vfs_sync_task; - wait_queue_head_t vfs_sync; wait_queue_head_t vfs_wait_sync_task; } vfs_t; @@ -88,10 +87,10 @@ #define SYNC_CLOSE 0x0002 /* close file system down */ #define SYNC_DELWRI 0x0004 /* look at delayed writes */ #define SYNC_WAIT 0x0008 /* wait for i/o to complete */ -#define SYNC_FSDATA 0x0020 /* flush fs data (e.g. superblocks) */ #define SYNC_BDFLUSH 0x0010 /* BDFLUSH is calling -- don't block */ -#define SYNC_REFCACHE 0x0020 /* prune some of the nfs ref cache */ - +#define SYNC_FSDATA 0x0020 /* flush fs data (e.g. superblocks) */ +#define SYNC_REFCACHE 0x0040 /* prune some of the nfs ref cache */ +#define SYNC_REMOUNT 0x0080 /* remount readonly, no dummy LRs */ #define IGET_NOALLOC 0x0001 /* vfs_get_inode may return NULL */ diff --exclude=dmapi -rNu ORIG/fs/xfs/Makefile HACK/fs/xfs/Makefile --- ORIG/fs/xfs/Makefile 2003-07-23 09:16:37.000000000 -0500 +++ HACK/fs/xfs/Makefile 2003-06-02 11:53:18.000000000 -0500 @@ -114,6 +114,11 @@ subdir-$(CONFIG_XFS_FS) += pagebuf linux support +ifeq ($(CONFIG_XFS_DMAPI),y) + subdir-$(CONFIG_XFS_FS) += dmapi + obj-y += dmapi/xfs_dmapi.o +endif + ifeq ($(CONFIG_XFS_QUOTA),y) subdir-$(CONFIG_XFS_FS) += quota obj-y += quota/xfs_quota.o diff --exclude=dmapi -rNu ORIG/fs/xfs/pagebuf/page_buf.c HACK/fs/xfs/pagebuf/page_buf.c --- ORIG/fs/xfs/pagebuf/page_buf.c 2003-07-23 09:16:37.000000000 -0500 +++ HACK/fs/xfs/pagebuf/page_buf.c 2003-07-23 10:06:13.000000000 -0500 @@ -1,5 +1,5 @@ /* - * Copyright (c) 2000-2002 Silicon Graphics, Inc. All Rights Reserved. + * Copyright (c) 2000-2003 Silicon Graphics, Inc. All Rights Reserved. * * This program is free software; you can redistribute it and/or modify it * under the terms of version 2 of the GNU General Public License as @@ -64,6 +64,7 @@ #define NBBY 8 #define BBSHIFT 9 +#define BBMASK ((1 << BBSHIFT) - 1) #define BN_ALIGN_MASK ((1 << (PAGE_CACHE_SHIFT - BBSHIFT)) - 1) #ifndef GFP_READAHEAD @@ -104,11 +105,11 @@ */ #ifdef PAGEBUF_TRACE -static spinlock_t pb_trace_lock = SPIN_LOCK_UNLOCKED; +static spinlock_t pb_trace_lock = SPIN_LOCK_UNLOCKED; struct pagebuf_trace_buf pb_trace; EXPORT_SYMBOL(pb_trace); EXPORT_SYMBOL(pb_trace_func); -#define CIRC_INC(i) (((i) + 1) & (PB_TRACE_BUFSIZE - 1)) +#define CIRC_INC(i) (((i) + 1) & (PB_TRACE_BUFSIZE - 1)) void pb_trace_func( @@ -120,7 +121,7 @@ int j; unsigned long flags; - if (!pb_params.p_un.debug) return; + if (!pb_params.debug.val) return; if (ra == NULL) ra = (void *)__builtin_return_address(0); @@ -176,10 +177,13 @@ * /proc/sys/vm/pagebuf */ -unsigned long pagebuf_min[P_PARAM] = { HZ/2, 1*HZ, 0, 0 }; -unsigned long pagebuf_max[P_PARAM] = { HZ*30, HZ*300, 1, 1 }; - -pagebuf_param_t pb_params = {{ HZ, 15 * HZ, 0, 0 }}; +pagebuf_param_t pb_params = { + /* MIN DFLT MAX */ + .flush_interval = { HZ/2, HZ, 30*HZ }, + .age_buffer = { 1*HZ, 15*HZ, 300*HZ }, + .stats_clear = { 0, 0, 1 }, + .debug = { 0, 0, 1 }, +}; /* * Pagebuf statistics variables @@ -228,7 +232,7 @@ * dev_t is 16 bits, loff_t is always 64 bits */ base ^= dev; - for (bit = hval = 0; base != 0 && bit < sizeof(base) * 8; bit += NBITS) { + for (bit = hval = 0; base && bit < sizeof(base) * 8; bit += NBITS) { hval ^= (int)base & (NHASH-1); base >>= NBITS; } @@ -236,18 +240,18 @@ } /* - * Mapping of multi-page buffers into contingous virtual space + * Mapping of multi-page buffers into contiguous virtual space */ STATIC void *pagebuf_mapout_locked(page_buf_t *); -STATIC spinlock_t as_lock = SPIN_LOCK_UNLOCKED; typedef struct a_list { - void *vm_addr; + void *vm_addr; struct a_list *next; } a_list_t; -STATIC a_list_t *as_free_head; -STATIC int as_list_len; +STATIC a_list_t *as_free_head; +STATIC int as_list_len; +STATIC spinlock_t as_lock = SPIN_LOCK_UNLOCKED; /* @@ -930,7 +934,7 @@ { page_buf_t *pb; - flags |= _PBF_PRIVATE_BH; + flags |= _PBF_PRIVATE_BH | _PBF_LOCKABLE; pb = pagebuf_allocate(flags); if (pb) { _pagebuf_initialize(pb, target, ioff, isize, flags); @@ -1502,27 +1506,29 @@ cache_ok = !((pb->pb_flags & PBF_FORCEIO) || (rw == WRITE)); public_bh = multi_ok = 1; + sector = 1 << sector_shift; if (!page_has_buffers(page)) { if (!locking) { lock_page(page); if (!page_has_buffers(page)) create_empty_buffers(page, - pbr->pbr_kdev, - 1 << sector_shift); + pbr->pbr_kdev, sector); unlock_page(page); } else { - create_empty_buffers(page, pbr->pbr_kdev, - 1 << sector_shift); + create_empty_buffers(page, + pbr->pbr_kdev, sector); } } + i = sector >> BBSHIFT; + bn -= (pg_offset >> BBSHIFT); + /* Find buffer_heads belonging to just this pagebuf */ bh = head = page_buffers(page); do { if (buffer_uptodate(bh) && cache_ok) continue; - blk_length = i << sector_shift; if (blk_length < pg_offset) continue; if (blk_length >= pg_offset + pg_length) @@ -1530,10 +1536,13 @@ lock_buffer(bh); get_bh(bh); - bh->b_size = 1 << sector_shift; - bh->b_blocknr = bn + (i - (pg_offset >> sector_shift)); + bh->b_size = sector; + bh->b_blocknr = bn; bufferlist[cnt++] = bh; - } while (i++, (bh = bh->b_this_page) != head); + + } while ((bn += i), + (blk_length += sector), + (bh = bh->b_this_page) != head); goto request; } @@ -1580,14 +1589,15 @@ } multi_ok = (blk_length != 1); + i = sector >> BBSHIFT; - for (; blk_length > 0; blk_length--, pg_offset += sector) { + for (; blk_length > 0; bn += i, blk_length--, pg_offset += sector) { bh = kmem_cache_alloc(bh_cachep, SLAB_NOFS); if (!bh) bh = _pagebuf_get_prealloc_bh(); memset(bh, 0, sizeof(*bh)); + bh->b_blocknr = bn; bh->b_size = sector; - bh->b_blocknr = bn++; bh->b_dev = pbr->pbr_kdev; set_bit(BH_Lock, &bh->b_state); set_bh_page(bh, page, pg_offset); @@ -1650,13 +1660,13 @@ if ((pbr->pbr_bsize == PAGE_CACHE_SIZE) && (pb->pb_buffer_length < PAGE_CACHE_SIZE) && (pb->pb_flags & PBF_READ) && pb->pb_locked) { - bn -= (pb->pb_offset >> pbr->pbr_sshift); + bn -= (pb->pb_offset >> BBSHIFT); pg_offset = 0; pg_length = PAGE_CACHE_SIZE; } else { pb_offset = offset - pb->pb_file_offset; if (pb_offset) { - bn += (pb_offset + pbr->pbr_smask) >> pbr->pbr_sshift; + bn += (pb_offset + BBMASK) >> BBSHIFT; } } @@ -1878,7 +1888,7 @@ } list_add_tail(&pb->pb_list, &pbd_delwrite_queue); - pb->pb_flushtime = jiffies + pb_params.p_un.age_buffer; + pb->pb_flushtime = jiffies + pb_params.age_buffer.val; spin_unlock(&pbd_delwrite_lock); if (unlock && (pb->pb_flags & _PBF_LOCKABLE)) { @@ -1920,10 +1930,10 @@ daemonize(); /* Avoid signals */ - spin_lock_irq(¤t->sigmask_lock); + sigmask_lock(); sigfillset(¤t->blocked); - recalc_sigpending(current); - spin_unlock_irq(¤t->sigmask_lock); + recalc_sigpending_(current); + sigmask_unlock(); /* Migrate to the right CPU */ migrate_to_cpu(cpu); @@ -2021,10 +2031,10 @@ daemonize(); /* Avoid signals */ - spin_lock_irq(¤t->sigmask_lock); + sigmask_lock(); sigfillset(¤t->blocked); - recalc_sigpending(current); - spin_unlock_irq(¤t->sigmask_lock); + recalc_sigpending_(current); + sigmask_unlock(); strcpy(current->comm, "pagebufd"); current->flags |= PF_MEMALLOC; @@ -2033,7 +2043,7 @@ do { if (pbd_active == 1) { mod_timer(&pb_daemon_timer, - jiffies + pb_params.p_un.flush_interval); + jiffies + pb_params.flush_interval.val); interruptible_sleep_on(&pbd_waitq); } @@ -2101,11 +2111,11 @@ int pincount = 0; int flush_cnt = 0; + pagebuf_runall_queues(pagebuf_dataiodone_tq); + spin_lock(&pbd_delwrite_lock); INIT_LIST_HEAD(&tmp); - pagebuf_runall_queues(pagebuf_dataiodone_tq); - list_for_each_safe(curr, next, &pbd_delwrite_queue) { pb = list_entry(curr, page_buf_t, pb_list); @@ -2261,7 +2271,7 @@ if (!ret && write && *valp) { printk("XFS Clearing pbstats\n"); memset(&pbstats, 0, sizeof(pbstats)); - pb_params.p_un.stats_clear = 0; + pb_params.stats_clear.val = 0; } return ret; @@ -2270,22 +2280,26 @@ STATIC struct ctl_table_header *pagebuf_table_header; STATIC ctl_table pagebuf_table[] = { - {PB_FLUSH_INT, "flush_int", &pb_params.data[0], + {PB_FLUSH_INT, "flush_int", &pb_params.flush_interval.val, sizeof(ulong), 0644, NULL, &proc_doulongvec_ms_jiffies_minmax, - &sysctl_intvec, NULL, &pagebuf_min[0], &pagebuf_max[0]}, + &sysctl_intvec, NULL, + &pb_params.flush_interval.min, &pb_params.flush_interval.max}, - {PB_FLUSH_AGE, "flush_age", &pb_params.data[1], + {PB_FLUSH_AGE, "flush_age", &pb_params.age_buffer.val, sizeof(ulong), 0644, NULL, &proc_doulongvec_ms_jiffies_minmax, - &sysctl_intvec, NULL, &pagebuf_min[1], &pagebuf_max[1]}, + &sysctl_intvec, NULL, + &pb_params.age_buffer.min, &pb_params.age_buffer.max}, - {PB_STATS_CLEAR, "stats_clear", &pb_params.data[2], + {PB_STATS_CLEAR, "stats_clear", &pb_params.stats_clear.val, sizeof(ulong), 0644, NULL, &pb_stats_clear_handler, - &sysctl_intvec, NULL, &pagebuf_min[2], &pagebuf_max[2]}, + &sysctl_intvec, NULL, + &pb_params.stats_clear.min, &pb_params.stats_clear.max}, #ifdef PAGEBUF_TRACE - {PB_DEBUG, "debug", &pb_params.data[3], + {PB_DEBUG, "debug", &pb_params.debug.val, sizeof(ulong), 0644, NULL, &proc_doulongvec_minmax, - &sysctl_intvec, NULL, &pagebuf_min[3], &pagebuf_max[3]}, + &sysctl_intvec, NULL, + &pb_params.debug.min, &pb_params.debug.max}, #endif {0} }; diff --exclude=dmapi -rNu ORIG/fs/xfs/pagebuf/page_buf.h HACK/fs/xfs/pagebuf/page_buf.h --- ORIG/fs/xfs/pagebuf/page_buf.h 2003-07-23 09:16:37.000000000 -0500 +++ HACK/fs/xfs/pagebuf/page_buf.h 2003-07-23 12:12:12.000000000 -0500 @@ -48,6 +48,17 @@ #include +/* RH 9 changes where the sigmask_lock is defined */ +#ifdef CLONE_SIGNAL +#define sigmask_lock() spin_lock_irq(¤t->sigmask_lock); +#define sigmask_unlock() spin_unlock_irq(¤t->sigmask_lock); +#define recalc_sigpending_(x) recalc_sigpending(x) +#else +/* RH9.0 */ +#define sigmask_lock() spin_lock_irq(¤t->sighand->siglock); +#define sigmask_unlock() spin_unlock_irq(¤t->sighand->siglock); +#define recalc_sigpending_(x) recalc_sigpending() +#endif /* * Turn this on to get pagebuf lock ownership #define PAGEBUF_LOCK_TRACKING diff --exclude=dmapi -rNu ORIG/fs/xfs/pagebuf/page_buf_internal.h HACK/fs/xfs/pagebuf/page_buf_internal.h --- ORIG/fs/xfs/pagebuf/page_buf_internal.h 2003-07-23 09:16:37.000000000 -0500 +++ HACK/fs/xfs/pagebuf/page_buf_internal.h 2003-07-23 12:12:12.000000000 -0500 @@ -85,18 +85,19 @@ * Tunable pagebuf parameters */ -#define P_PARAM 4 +typedef struct pb_sysctl_val { + ulong min; + ulong val; + ulong max; +} pb_sysctl_val_t; -typedef union pagebuf_param { - struct { - ulong flush_interval; /* interval between runs of the +typedef struct pagebuf_param { + pb_sysctl_val_t flush_interval; /* interval between runs of the * delwri flush daemon. */ - ulong age_buffer; /* time for buffer to age before + pb_sysctl_val_t age_buffer; /* time for buffer to age before * we flush it. */ - ulong debug; /* debug tracing on or off */ - ulong stats_clear; /* clear the pagebuf stats */ - } p_un; - ulong data[P_PARAM]; + pb_sysctl_val_t stats_clear; /* clear the pagebuf stats */ + pb_sysctl_val_t debug; /* debug tracing on or off */ } pagebuf_param_t; enum { diff --exclude=dmapi -rNu ORIG/fs/xfs/quota/xfs_qm.c HACK/fs/xfs/quota/xfs_qm.c --- ORIG/fs/xfs/quota/xfs_qm.c 2003-07-23 09:16:38.000000000 -0500 +++ HACK/fs/xfs/quota/xfs_qm.c 2003-07-15 22:06:55.000000000 -0500 @@ -1609,7 +1609,7 @@ map = kmem_alloc(XFS_DQITER_MAP_SIZE * sizeof(*map), KM_SLEEP); lblkno = 0; - maxlblkcnt = XFS_B_TO_FSB(mp, (xfs_ufsize_t)XFS_MAX_FILE_OFFSET); + maxlblkcnt = XFS_B_TO_FSB(mp, (xfs_ufsize_t)XFS_MAXIOFFSET(mp)); do { nmaps = XFS_DQITER_MAP_SIZE; /* diff --exclude=dmapi -rNu ORIG/fs/xfs/sgiReleaseNumber HACK/fs/xfs/sgiReleaseNumber --- ORIG/fs/xfs/sgiReleaseNumber 1969-12-31 18:00:00.000000000 -0600 +++ HACK/fs/xfs/sgiReleaseNumber 2003-06-13 13:21:46.000000000 -0500 @@ -0,0 +1 @@ +1 diff --exclude=dmapi -rNu ORIG/fs/xfs/support/kmem.c HACK/fs/xfs/support/kmem.c --- ORIG/fs/xfs/support/kmem.c 2003-07-23 09:16:38.000000000 -0500 +++ HACK/fs/xfs/support/kmem.c 2003-07-15 22:10:11.000000000 -0500 @@ -41,25 +41,6 @@ #define DEF_PRIORITY (6) #define MAX_SLAB_SIZE 0x10000 -static __inline unsigned int flag_convert(int flags) -{ -#if DEBUG - if (unlikely(flags & ~(KM_SLEEP|KM_NOSLEEP|KM_NOFS))) { - printk(KERN_WARNING - "XFS: memory allocation with wrong flags (%x)\n", flags); - BUG(); - } -#endif - - if (flags & KM_NOSLEEP) - return GFP_ATOMIC; - /* If we're in a transaction, FS activity is not ok */ - else if ((current->flags & PF_FSTRANS) || (flags & KM_NOFS)) - return GFP_NOFS; - else - return GFP_KERNEL; -} - #define MAX_SHAKE 8 static kmem_shake_func_t shake_list[MAX_SHAKE]; @@ -113,18 +94,20 @@ void * kmem_alloc(size_t size, int flags) { - int shrink = DEF_PRIORITY; /* # times to try to shrink cache */ + int shrink = DEF_PRIORITY; /* # times to try to shrink cache */ + int lflags = kmem_flags_convert(flags); + int nosleep = flags & KM_NOSLEEP; void *rval; repeat: if (MAX_SLAB_SIZE < size) { /* Avoid doing filesystem sensitive stuff to get this */ - rval = __vmalloc(size, flag_convert(flags), PAGE_KERNEL); + rval = __vmalloc(size, lflags, PAGE_KERNEL); } else { - rval = kmalloc(size, flag_convert(flags)); + rval = kmalloc(size, lflags); } - if (rval || (flags & KM_NOSLEEP)) + if (rval || nosleep) return rval; /* @@ -137,8 +120,8 @@ goto repeat; } - rval = __vmalloc(size, flag_convert(flags), PAGE_KERNEL); - if (!rval && (flags & KM_SLEEP)) + rval = __vmalloc(size, lflags, PAGE_KERNEL); + if (!rval && !nosleep) panic("kmem_alloc: NULL memory on KM_SLEEP request!"); return rval; @@ -197,7 +180,7 @@ void *ptr = NULL; repeat: - ptr = kmem_cache_alloc(zone, flag_convert(flags)); + ptr = kmem_cache_alloc(zone, kmem_flags_convert(flags)); if (ptr || (flags & KM_NOSLEEP)) return ptr; @@ -225,7 +208,7 @@ void *ptr = NULL; repeat: - ptr = kmem_cache_alloc(zone, flag_convert(flags)); + ptr = kmem_cache_alloc(zone, kmem_flags_convert(flags)); if (ptr) { memset(ptr, 0, kmem_cache_size(zone)); diff --exclude=dmapi -rNu ORIG/fs/xfs/support/kmem.h HACK/fs/xfs/support/kmem.h --- ORIG/fs/xfs/support/kmem.h 2003-07-23 09:16:38.000000000 -0500 +++ HACK/fs/xfs/support/kmem.h 2003-07-23 12:12:12.000000000 -0500 @@ -1,5 +1,5 @@ /* - * Copyright (c) 2000-2002 Silicon Graphics, Inc. All Rights Reserved. + * Copyright (c) 2000-2003 Silicon Graphics, Inc. All Rights Reserved. * * This program is free software; you can redistribute it and/or modify it * under the terms of version 2 of the GNU General Public License as @@ -44,6 +44,50 @@ #define kmem_zone kmem_cache_s #define kmem_zone_t kmem_cache_t +typedef unsigned long xfs_pflags_t; + +#define PFLAGS_TEST_NOIO() (current->flags & PF_NOIO) +#define PFLAGS_TEST_FSTRANS() (current->flags & PF_FSTRANS) + +#define PFLAGS_SET_NOIO(STATEP) do { \ + *(STATEP) = current->flags; \ + current->flags |= PF_NOIO; \ +} while (0) + +#define PFLAGS_SET_FSTRANS(STATEP) do { \ + *(STATEP) = current->flags; \ + current->flags |= PF_FSTRANS; \ +} while (0) + +#define PFLAGS_RESTORE(STATEP) do { \ + current->flags = *(STATEP); \ +} while (0) + +#define PFLAGS_DUP(OSTATEP, NSTATEP) do { \ + *(NSTATEP) = *(OSTATEP); \ +} while (0); + +static __inline unsigned int kmem_flags_convert(int flags) +{ + int lflags; + +#if DEBUG + if (unlikely(flags & ~(KM_SLEEP|KM_NOSLEEP|KM_NOFS))) { + printk(KERN_WARNING + "XFS: memory allocation with wrong flags (%x)\n", flags); + BUG(); + } +#endif + + lflags = (flags & KM_NOSLEEP) ? GFP_ATOMIC : GFP_KERNEL; + + /* avoid recusive callbacks to filesystem during transactions */ + if (PFLAGS_TEST_FSTRANS() || (flags & KM_NOFS)) + lflags &= ~__GFP_FS; + + return lflags; +} + extern kmem_zone_t *kmem_zone_init(int, char *); extern void *kmem_zone_zalloc(kmem_zone_t *, int); extern void *kmem_zone_alloc(kmem_zone_t *, int); diff --exclude=dmapi -rNu ORIG/fs/xfs/support/spin.h HACK/fs/xfs/support/spin.h --- ORIG/fs/xfs/support/spin.h 2003-07-23 09:16:38.000000000 -0500 +++ HACK/fs/xfs/support/spin.h 2003-07-23 12:12:12.000000000 -0500 @@ -43,6 +43,8 @@ * We don't need to worry about SMP or not here. */ +#define SPLDECL(s) unsigned long s + typedef spinlock_t lock_t; #define spinlock_init(lock, name) spin_lock_init(lock) diff --exclude=dmapi -rNu ORIG/fs/xfs/VERSION HACK/fs/xfs/VERSION --- ORIG/fs/xfs/VERSION 1969-12-31 18:00:00.000000000 -0600 +++ HACK/fs/xfs/VERSION 2003-06-13 13:22:00.000000000 -0500 @@ -0,0 +1 @@ +1.3.0pre2 diff --exclude=dmapi -rNu ORIG/fs/xfs/xfs_ag.h HACK/fs/xfs/xfs_ag.h --- ORIG/fs/xfs/xfs_ag.h 2003-07-23 09:16:38.000000000 -0500 +++ HACK/fs/xfs/xfs_ag.h 2003-06-02 11:53:23.000000000 -0500 @@ -1,5 +1,5 @@ /* - * Copyright (c) 2000-2002 Silicon Graphics, Inc. All Rights Reserved. + * Copyright (c) 2000-2003 Silicon Graphics, Inc. All Rights Reserved. * * This program is free software; you can redistribute it and/or modify it * under the terms of version 2 of the GNU General Public License as @@ -185,9 +185,8 @@ #endif #define XFS_AGFL_SIZE(mp) ((mp)->m_sb.sb_sectsize / sizeof(xfs_agblock_t)) -/* -- nathans TODO ... use of BBSIZE here - should be sector size -- */ typedef struct xfs_agfl { - xfs_agblock_t agfl_bno[BBSIZE/sizeof(xfs_agblock_t)]; + xfs_agblock_t agfl_bno[1]; /* actually XFS_AGFL_SIZE(mp) */ } xfs_agfl_t; /* diff --exclude=dmapi -rNu ORIG/fs/xfs/xfs_attr_leaf.c HACK/fs/xfs/xfs_attr_leaf.c --- ORIG/fs/xfs/xfs_attr_leaf.c 2003-07-23 09:16:38.000000000 -0500 +++ HACK/fs/xfs/xfs_attr_leaf.c 2003-06-02 11:53:24.000000000 -0500 @@ -486,8 +486,7 @@ i < INT_GET(sf->hdr.count, ARCH_CONVERT); i++) { if (unlikely( ((char *)sfe < (char *)sf) || - ((char *)sfe >= ((char *)sf + dp->i_afp->if_bytes)) || - (sfe->namelen >= MAXNAMELEN))) { + ((char *)sfe >= ((char *)sf + dp->i_afp->if_bytes)))) { XFS_CORRUPTION_ERROR("xfs_attr_shortform_list", XFS_ERRLEVEL_LOW, context->dp->i_mount, sfe); diff --exclude=dmapi -rNu ORIG/fs/xfs/xfs_bmap.c HACK/fs/xfs/xfs_bmap.c --- ORIG/fs/xfs/xfs_bmap.c 2003-07-23 09:16:39.000000000 -0500 +++ HACK/fs/xfs/xfs_bmap.c 2003-07-15 22:06:57.000000000 -0500 @@ -1,5 +1,5 @@ /* - * Copyright (c) 2000-2002 Silicon Graphics, Inc. All Rights Reserved. + * Copyright (c) 2000-2003 Silicon Graphics, Inc. All Rights Reserved. * * This program is free software; you can redistribute it and/or modify it * under the terms of version 2 of the GNU General Public License as @@ -5579,7 +5579,7 @@ if (whichfork == XFS_DATA_FORK) { if (ip->i_d.di_flags & XFS_DIFLAG_PREALLOC) { prealloced = 1; - fixlen = XFS_MAX_FILE_OFFSET; + fixlen = XFS_MAXIOFFSET(mp); } else { prealloced = 0; fixlen = ip->i_d.di_size; diff --exclude=dmapi -rNu ORIG/fs/xfs/xfs_buf.h HACK/fs/xfs/xfs_buf.h --- ORIG/fs/xfs/xfs_buf.h 2003-07-23 09:16:39.000000000 -0500 +++ HACK/fs/xfs/xfs_buf.h 2003-06-02 11:53:24.000000000 -0500 @@ -1,5 +1,5 @@ /* - * Copyright (c) 2000-2002 Silicon Graphics, Inc. All Rights Reserved. + * Copyright (c) 2000-2003 Silicon Graphics, Inc. All Rights Reserved. * * This program is free software; you can redistribute it and/or modify it * under the terms of version 2 of the GNU General Public License as @@ -283,7 +283,6 @@ return error; } - #define XFS_bdwrite(pb) \ pagebuf_iostart(pb, PBF_DELWRI | PBF_ASYNC) @@ -307,15 +306,15 @@ * of its metadata. */ -extern void XFS_bflush(xfs_buftarg_t *); -#define xfs_binval(buftarg) XFS_bflush(buftarg) +#define xfs_binval(buftarg) xfs_flush_buftarg(buftarg) + +#define XFS_bflush(buftarg) xfs_flush_buftarg(buftarg) #define xfs_incore_relse(buftarg,delwri_only,wait) \ xfs_relse_buftarg(buftarg) #define xfs_baread(target, rablkno, ralen) \ - pagebuf_readahead((target), (rablkno), \ - (ralen), PBF_DONT_BLOCK) + pagebuf_readahead((target), (rablkno), (ralen), PBF_DONT_BLOCK) #define XFS_getrbuf(sleep,mp) \ pagebuf_get_empty((mp)->m_ddev_targp) diff --exclude=dmapi -rNu ORIG/fs/xfs/xfs_dir_leaf.c HACK/fs/xfs/xfs_dir_leaf.c --- ORIG/fs/xfs/xfs_dir_leaf.c 2003-07-23 09:16:40.000000000 -0500 +++ HACK/fs/xfs/xfs_dir_leaf.c 2003-06-02 11:53:25.000000000 -0500 @@ -483,8 +483,7 @@ if (unlikely( ((char *)sfe < (char *)sf) || - ((char *)sfe >= ((char *)sf + dp->i_df.if_bytes)) || - (sfe->namelen >= MAXNAMELEN))) { + ((char *)sfe >= ((char *)sf + dp->i_df.if_bytes)))) { xfs_dir_trace_g_du("sf: corrupted", dp, uio); XFS_CORRUPTION_ERROR("xfs_dir_shortform_getdents", XFS_ERRLEVEL_LOW, mp, sfe); @@ -2001,8 +2000,7 @@ if (unlikely( ((char *)namest < (char *)leaf) || - ((char *)namest >= (char *)leaf + XFS_LBSIZE(mp)) || - (entry->namelen >= MAXNAMELEN))) { + ((char *)namest >= (char *)leaf + XFS_LBSIZE(mp)))) { XFS_CORRUPTION_ERROR("xfs_dir_leaf_getdents_int(1)", XFS_ERRLEVEL_LOW, mp, leaf); xfs_dir_trace_g_du("leaf: corrupted", dp, uio); @@ -2065,8 +2063,7 @@ if (unlikely( ((char *)namest < (char *)leaf) || - ((char *)namest >= (char *)leaf + XFS_LBSIZE(mp)) || - (entry->namelen >= MAXNAMELEN))) { + ((char *)namest >= (char *)leaf + XFS_LBSIZE(mp)))) { XFS_CORRUPTION_ERROR("xfs_dir_leaf_getdents_int(2)", XFS_ERRLEVEL_LOW, mp, leaf); xfs_dir_trace_g_du("leaf: corrupted", dp, uio); diff --exclude=dmapi -rNu ORIG/fs/xfs/xfs_error.c HACK/fs/xfs/xfs_error.c --- ORIG/fs/xfs/xfs_error.c 2003-07-23 09:16:40.000000000 -0500 +++ HACK/fs/xfs/xfs_error.c 2003-07-15 22:22:50.000000000 -0500 @@ -323,6 +323,7 @@ int linenum, inst_t *ra) { - xfs_hex_dump(p, 16); + if (level <= xfs_error_level) + xfs_hex_dump(p, 16); xfs_error_report(tag, level, mp, fname, linenum, ra); } diff --exclude=dmapi -rNu ORIG/fs/xfs/xfs_ialloc.c HACK/fs/xfs/xfs_ialloc.c --- ORIG/fs/xfs/xfs_ialloc.c 2003-07-23 09:16:40.000000000 -0500 +++ HACK/fs/xfs/xfs_ialloc.c 2003-06-02 11:53:25.000000000 -0500 @@ -151,7 +151,6 @@ int ninodes; /* num inodes per buf */ xfs_agino_t thisino; /* current inode number, for loop */ int version; /* inode version number to use */ - static xfs_timestamp_t ztime; /* zero xfs timestamp */ int isaligned; /* inode allocation at stripe unit */ /* boundary */ xfs_dinode_core_t dic; /* a dinode_core to copy to new */ @@ -265,6 +264,11 @@ version = XFS_DINODE_VERSION_2; else version = XFS_DINODE_VERSION_1; + + memset(&dic, 0, sizeof(xfs_dinode_core_t)); + INT_SET(dic.di_magic, ARCH_CONVERT, XFS_DINODE_MAGIC); + INT_SET(dic.di_version, ARCH_CONVERT, version); + for (j = 0; j < nbufs; j++) { /* * Get the block. @@ -279,36 +283,6 @@ /* * Loop over the inodes in this buffer. */ - INT_SET(dic.di_magic, ARCH_CONVERT, XFS_DINODE_MAGIC); - INT_ZERO(dic.di_mode, ARCH_CONVERT); - INT_SET(dic.di_version, ARCH_CONVERT, version); - INT_ZERO(dic.di_format, ARCH_CONVERT); - INT_ZERO(dic.di_onlink, ARCH_CONVERT); - INT_ZERO(dic.di_uid, ARCH_CONVERT); - INT_ZERO(dic.di_gid, ARCH_CONVERT); - INT_ZERO(dic.di_nlink, ARCH_CONVERT); - INT_ZERO(dic.di_projid, ARCH_CONVERT); - memset(&(dic.di_pad[0]), 0, sizeof(dic.di_pad)); - INT_SET(dic.di_atime.t_sec, ARCH_CONVERT, ztime.t_sec); - INT_SET(dic.di_atime.t_nsec, ARCH_CONVERT, ztime.t_nsec); - - INT_SET(dic.di_mtime.t_sec, ARCH_CONVERT, ztime.t_sec); - INT_SET(dic.di_mtime.t_nsec, ARCH_CONVERT, ztime.t_nsec); - - INT_SET(dic.di_ctime.t_sec, ARCH_CONVERT, ztime.t_sec); - INT_SET(dic.di_ctime.t_nsec, ARCH_CONVERT, ztime.t_nsec); - - INT_ZERO(dic.di_size, ARCH_CONVERT); - INT_ZERO(dic.di_nblocks, ARCH_CONVERT); - INT_ZERO(dic.di_extsize, ARCH_CONVERT); - INT_ZERO(dic.di_nextents, ARCH_CONVERT); - INT_ZERO(dic.di_anextents, ARCH_CONVERT); - INT_ZERO(dic.di_forkoff, ARCH_CONVERT); - INT_ZERO(dic.di_aformat, ARCH_CONVERT); - INT_ZERO(dic.di_dmevmask, ARCH_CONVERT); - INT_ZERO(dic.di_dmstate, ARCH_CONVERT); - INT_ZERO(dic.di_flags, ARCH_CONVERT); - INT_ZERO(dic.di_gen, ARCH_CONVERT); for (i = 0; i < ninodes; i++) { free = XFS_MAKE_IPTR(args.mp, fbuf, i); diff --exclude=dmapi -rNu ORIG/fs/xfs/xfsidbg.c HACK/fs/xfs/xfsidbg.c --- ORIG/fs/xfs/xfsidbg.c 2003-07-23 09:16:40.000000000 -0500 +++ HACK/fs/xfs/xfsidbg.c 2003-06-26 11:54:05.000000000 -0500 @@ -1406,33 +1406,40 @@ } -static void printvnode(vnode_t *vp, unsigned long addr) +static void printbhv(bhv_desc_t *bdp) { - bhv_desc_t *bh; kdb_symtab_t symtab; + if (bdp == NULL) { + kdb_printf("NULL bhv\n"); + return; + } + + kdb_printf("bhv at 0x%p\n", bdp); + while (bdp) { + if (kdbnearsym((unsigned long)bdp->bd_ops, &symtab)) + kdb_printf(" ops %s", symtab.sym_name); + else + kdb_printf(" ops %s/0x%p", "???", (void *)bdp->bd_ops); + + kdb_printf(" vobj 0x%p pdata 0x%p next 0x%p\n", + bdp->bd_vobj, bdp->bd_pdata, bdp->bd_next); + + bdp = bdp->bd_next; + } +} + +static void printvnode(vnode_t *vp, unsigned long addr) +{ kdb_printf("vnode: 0x%lx type ", addr); if ((size_t)vp->v_type >= sizeof(vnode_type)/sizeof(vnode_type[0])) kdb_printf("out of range 0x%x", vp->v_type); else kdb_printf("%s", vnode_type[vp->v_type]); - kdb_printf(" v_bh %p\n", &vp->v_bh); - - if ((bh = vp->v_bh.bh_first)) { - kdb_printf(" v_inode 0x%p v_bh->bh_first 0x%p pobj 0x%p\n", - LINVFS_GET_IP((struct vnode *) addr), - bh, bh->bd_pdata); + kdb_printf(" v_bh 0x%p\n", &vp->v_bh); - if (kdbnearsym((unsigned long)bh->bd_ops, &symtab)) - kdb_printf(" ops %s ", symtab.sym_name); - else - kdb_printf(" ops %s/0x%p ", - "???", (void *)bh->bd_ops); - } else { - kdb_printf(" v_inode 0x%p v_bh->bh_first = NULLBHV ", - LINVFS_GET_IP((struct vnode *) addr)); - } + printbhv(vp->v_fbhv); printflags((__psunsigned_t)vp->v_flag, tab_vflags, "flag ="); kdb_printf("\n"); @@ -1477,7 +1484,38 @@ print_vfs(vfs_t *vfs, unsigned long addr) { kdb_printf("vfsp at 0x%lx", addr); - kdb_printf(" vfs_fbhv 0x%p sb 0x%p\n", vfs->vfs_fbhv, vfs->vfs_super); + kdb_printf(" vfs_flag 0x%x\n", vfs->vfs_flag); + kdb_printf(" vfs_super 0x%p", vfs->vfs_super); + kdb_printf(" vfs_bh 0x%p\n", &vfs->vfs_bh); + + printbhv(vfs->vfs_fbhv); +} + +static int kdbm_bhv( + int argc, + const char **argv, + const char **envp, + struct pt_regs *regs) +{ + unsigned long addr; + int nextarg = 1; + long offset = 0; + int diag; + bhv_desc_t *bh; + + if (argc != 1) + return KDB_ARGCOUNT; + + diag = kdbgetaddrarg(argc, argv, &nextarg, &addr, &offset, NULL, regs); + + if (diag) + return diag; + + bh = (bhv_desc_t *)addr; + + printbhv(bh); + + return 0; } static int kdbm_vfs( @@ -2172,6 +2210,7 @@ char *args; char *help; } xfsidbg_funcs[] = { + { "bhv", kdbm_bhv, "", "Dump bhv chain"}, { "vn", kdbm_vn, "", "Dump inode/vnode/trace"}, { "vnode", kdbm_vnode, "", "Dump vnode"}, { "vfs", kdbm_vfs, "", "Dump vfs"}, @@ -4305,8 +4344,10 @@ kdb_printf("iclog_bak: 0x%p iclog_size: 0x%x (%d) num iclogs: %d\n", log->l_iclog_bak, log->l_iclog_size, log->l_iclog_size, log->l_iclog_bufs); - kdb_printf("l_iclog_hsize %d l_iclog_heads %d\n", - log->l_iclog_hsize, log->l_iclog_heads); + kdb_printf("l_stripemask %d l_iclog_hsize %d l_iclog_heads %d\n", + log->l_stripemask, log->l_iclog_hsize, log->l_iclog_heads); + kdb_printf("l_sectbb_log %u l_sectbb_mask %u\n", + log->l_sectbb_log, log->l_sectbb_mask); kdb_printf("&grant_lock: 0x%p resHeadQ: 0x%p wrHeadQ: 0x%p\n", &log->l_grant_lock, log->l_reserve_headq, log->l_write_headq); kdb_printf("GResCycle: %d GResBytes: %d GWrCycle: %d GWrBytes: %d\n", @@ -4748,7 +4789,6 @@ (xfs_dfiloff_t)mp->m_dirfreeblk); kdb_printf("chsize %d chash 0x%p\n", mp->m_chsize, mp->m_chash); - kdb_printf("m_lstripemask %d\n", mp->m_lstripemask); kdb_printf("m_frozen %d m_active_trans %d\n", mp->m_frozen, mp->m_active_trans.counter); if (mp->m_fsname != NULL) @@ -4918,13 +4958,8 @@ xfs_inode_t *ip; while (chl != NULL) { -#ifdef DEBUG - kdb_printf("hashlist inode 0x%p blkno %Ld buf 0x%p", - chl->chl_ip, chl->chl_blkno, chl->chl_buf); -#else - kdb_printf("hashlist inode 0x%p blkno %lld", - chl->chl_ip, (long long) chl->chl_blkno); -#endif + kdb_printf("hashlist inode 0x%p blkno %lld buf 0x%p", + chl->chl_ip, (long long) chl->chl_blkno, chl->chl_buf); kdb_printf("\n"); diff --exclude=dmapi -rNu ORIG/fs/xfs/xfs_iget.c HACK/fs/xfs/xfs_iget.c --- ORIG/fs/xfs/xfs_iget.c 2003-07-23 09:16:40.000000000 -0500 +++ HACK/fs/xfs/xfs_iget.c 2003-06-13 10:46:53.000000000 -0500 @@ -214,7 +214,13 @@ XFS_STATS_INC(xfsstats.xs_ig_found); + ip->i_flags &= ~XFS_IRECLAIMABLE; read_unlock(&ih->ih_lock); + + XFS_MOUNT_ILOCK(mp); + list_del_init(&ip->i_reclaim); + XFS_MOUNT_IUNLOCK(mp); + goto finish_inode; } else if (vp != inode_vp) { @@ -253,10 +259,6 @@ xfs_iocore_inode_reinit(ip); } - XFS_MOUNT_ILOCK(mp); - list_del_init(&ip->i_reclaim); - XFS_MOUNT_IUNLOCK(mp); - vn_trace_exit(vp, "xfs_iget.found", (inst_t *)__return_address); goto return_ip; diff --exclude=dmapi -rNu ORIG/fs/xfs/xfs_inode.c HACK/fs/xfs/xfs_inode.c --- ORIG/fs/xfs/xfs_inode.c 2003-07-23 09:16:40.000000000 -0500 +++ HACK/fs/xfs/xfs_inode.c 2003-07-15 22:06:56.000000000 -0500 @@ -412,7 +412,7 @@ mp->m_dev, (unsigned long long)imap.im_blkno, i, INT_GET(dip->di_core.di_magic, ARCH_CONVERT)); #endif - XFS_CORRUPTION_ERROR("xfs_itobp", XFS_ERRLEVEL_LOW, + XFS_CORRUPTION_ERROR("xfs_itobp", XFS_ERRLEVEL_HIGH, mp, dip); xfs_trans_brelse(tp, bp); return XFS_ERROR(EFSCORRUPTED); @@ -1265,7 +1265,7 @@ */ if (xfs_bmapi(NULL, ip, map_first, (XFS_B_TO_FSB(mp, - (xfs_ufsize_t)XFS_MAX_FILE_OFFSET) - + (xfs_ufsize_t)XFS_MAXIOFFSET(mp)) - map_first), XFS_BMAPI_ENTIRE, NULL, 0, imaps, &nimaps, NULL)) @@ -1319,11 +1319,11 @@ last_byte = XFS_FSB_TO_B(mp, last_block); if (last_byte < 0) { - return XFS_MAX_FILE_OFFSET; + return XFS_MAXIOFFSET(mp); } last_byte += (1 << mp->m_writeio_log); if (last_byte < 0) { - return XFS_MAX_FILE_OFFSET; + return XFS_MAXIOFFSET(mp); } return last_byte; } @@ -1613,7 +1613,7 @@ * beyond the maximum file size (ie it is the same as last_block), * then there is nothing to do. */ - last_block = XFS_B_TO_FSB(mp, (xfs_ufsize_t)XFS_MAX_FILE_OFFSET); + last_block = XFS_B_TO_FSB(mp, (xfs_ufsize_t)XFS_MAXIOFFSET(mp)); ASSERT(first_unmap_block <= last_block); done = 0; if (last_block == first_unmap_block) { @@ -2629,7 +2629,8 @@ if (vp) { struct inode *inode = LINVFS_GET_IP(vp); - mark_inode_dirty_sync(inode); + if (!(inode->i_state & I_NEW)) + mark_inode_dirty_sync(inode); } wake_up(&ip->i_ipin_wait); @@ -2993,9 +2994,7 @@ * see if other inodes can be gathered into this write */ -#ifdef DEBUG - ip->i_chash->chl_buf = bp; /* inode clustering debug */ -#endif + ip->i_chash->chl_buf = bp; ch = XFS_CHASH(mp, ip->i_blkno); s = mutex_spinlock(&ch->ch_lock); diff --exclude=dmapi -rNu ORIG/fs/xfs/xfs_inode.h HACK/fs/xfs/xfs_inode.h --- ORIG/fs/xfs/xfs_inode.h 2003-07-23 09:16:40.000000000 -0500 +++ HACK/fs/xfs/xfs_inode.h 2003-07-15 22:06:56.000000000 -0500 @@ -192,9 +192,7 @@ struct xfs_inode *chl_ip; xfs_daddr_t chl_blkno; /* starting block number of * the cluster */ -#ifdef DEBUG - struct xfs_buf *chl_buf; /* debug: the inode buffer */ -#endif + struct xfs_buf *chl_buf; /* the inode buffer */ } xfs_chashlist_t; typedef struct xfs_chash { @@ -366,6 +364,7 @@ #define XFS_IUIOSZ 0x0002 /* inode i/o sizes have been explicitly set */ #define XFS_IQUIESCE 0x0004 /* we have started quiescing for this inode */ #define XFS_IRECLAIM 0x0008 /* we have started reclaiming this inode */ +#define XFS_IRECLAIMABLE 0x0010 /* inode can be reclaimed */ /* * Flags for inode locking. @@ -409,14 +408,6 @@ #define XFS_ITRUNC_DEFINITE 0x1 #define XFS_ITRUNC_MAYBE 0x2 -/* - * max file offset is 2^(31+PAGE_SHIFT) - 1 (due to linux page cache) - * - * NOTE: XFS itself can handle 2^63 - 1 (largest positive value of xfs_fsize_t) - * but this is the Linux limit. - */ -#define XFS_MAX_FILE_OFFSET MAX_LFS_FILESIZE - #if XFS_WANT_FUNCS || (XFS_WANT_SPACE && XFSSO_XFS_ITOV) struct vnode *xfs_itov(xfs_inode_t *ip); #define XFS_ITOV(ip) xfs_itov(ip) diff --exclude=dmapi -rNu ORIG/fs/xfs/xfs_inode_item.c HACK/fs/xfs/xfs_inode_item.c --- ORIG/fs/xfs/xfs_inode_item.c 2003-07-23 09:16:40.000000000 -0500 +++ HACK/fs/xfs/xfs_inode_item.c 2003-06-02 11:53:25.000000000 -0500 @@ -879,7 +879,7 @@ * Write out the inode. The completion routine ('iflush_done') will * pull it from the AIL, mark it clean, unlock the flush lock. */ - (void) xfs_iflush(ip, XFS_IFLUSH_DELWRI); + (void) xfs_iflush(ip, XFS_IFLUSH_ASYNC); xfs_iunlock(ip, XFS_ILOCK_SHARED); return; diff --exclude=dmapi -rNu ORIG/fs/xfs/xfs_iocore.c HACK/fs/xfs/xfs_iocore.c --- ORIG/fs/xfs/xfs_iocore.c 2003-07-23 09:16:40.000000000 -0500 +++ HACK/fs/xfs/xfs_iocore.c 2003-06-16 10:40:36.000000000 -0500 @@ -77,8 +77,7 @@ struct xfs_mount_args *mntargs, int flags) { - return xfs_mountfs(vfsp, XFS_VFSTOM(vfsp), - vfsp->vfs_super->s_bdev->bd_dev, flags); + return xfs_mountfs(vfsp, XFS_VFSTOM(vfsp), flags); } xfs_ioops_t xfs_iocore_xfs = { diff --exclude=dmapi -rNu ORIG/fs/xfs/xfs_log.c HACK/fs/xfs/xfs_log.c --- ORIG/fs/xfs/xfs_log.c 2003-07-23 09:16:40.000000000 -0500 +++ HACK/fs/xfs/xfs_log.c 2003-07-15 22:24:11.000000000 -0500 @@ -1,5 +1,5 @@ /* - * Copyright (c) 2000-2002 Silicon Graphics, Inc. All Rights Reserved. + * Copyright (c) 2000-2003 Silicon Graphics, Inc. All Rights Reserved. * * This program is free software; you can redistribute it and/or modify it * under the terms of version 2 of the GNU General Public License as @@ -414,19 +414,6 @@ } /* - * Initialize log manager data. This routine is intended to be called when - * a system boots up. It is not a per filesystem initialization. - * - * As you can see, we currently do nothing. - */ -int -xfs_log_init(void) -{ - return( 0 ); -} - - -/* * 1. Reserve an amount of on-disk log space and return a ticket corresponding * to the reservation. * 2. Potentially, push buffers at tail of log to disk. @@ -497,8 +484,6 @@ xfs_daddr_t blk_offset, int num_bblks) { - xlog_t *log; - if (!(mp->m_flags & XFS_MOUNT_NORECOVERY)) cmn_err(CE_NOTE, "XFS mounting filesystem %s", mp->m_fsname); else { @@ -508,7 +493,7 @@ ASSERT(XFS_MTOVFS(mp)->vfs_flag & VFS_RDONLY); } - mp->m_log = log = xlog_alloc_log(mp, log_dev, blk_offset, num_bblks); + mp->m_log = xlog_alloc_log(mp, log_dev, blk_offset, num_bblks); #if defined(DEBUG) || defined(XLOG_NOLOG) if (! xlog_debug) { @@ -528,19 +513,19 @@ if (readonly) vfsp->vfs_flag &= ~VFS_RDONLY; - error = xlog_recover(log, readonly); + error = xlog_recover(mp->m_log, readonly); if (readonly) vfsp->vfs_flag |= VFS_RDONLY; if (error) { cmn_err(CE_WARN, "XFS: log mount/recovery failed"); - xlog_unalloc_log(log); + xlog_unalloc_log(mp->m_log); return error; } } /* Normal transactions can now occur */ - log->l_flags &= ~XLOG_ACTIVE_RECOVERY; + mp->m_log->l_flags &= ~XLOG_ACTIVE_RECOVERY; /* End mounting message in xfs_log_mount_finish */ return 0; @@ -809,8 +794,9 @@ do { ASSERT(tic->t_flags & XLOG_TIC_PERM_RESERV); - if (free_bytes < tic->t_unit_res) + if (free_bytes < tic->t_unit_res && tail_lsn != 1) break; + tail_lsn = 0; free_bytes -= tic->t_unit_res; sv_signal(&tic->t_sema); tic = tic->t_next; @@ -829,8 +815,9 @@ need_bytes = tic->t_unit_res*tic->t_cnt; else need_bytes = tic->t_unit_res; - if (free_bytes < need_bytes) + if (free_bytes < need_bytes && tail_lsn != 1) break; + tail_lsn = 0; free_bytes -= need_bytes; sv_signal(&tic->t_sema); tic = tic->t_next; @@ -851,8 +838,10 @@ SPLDECL(s); int needed = 0, gen; xlog_t *log = mp->m_log; + vfs_t *vfsp = XFS_MTOVFS(mp); - if (mp->m_frozen || XFS_FORCED_SHUTDOWN(mp)) + if (mp->m_frozen || XFS_FORCED_SHUTDOWN(mp) || + (vfsp->vfs_flag & VFS_RDONLY)) return 0; s = LOG_LOCK(log); @@ -1077,7 +1066,7 @@ if (mp->m_logbufs == 0) { xlog_debug = 0; xlog_devt = log->l_dev; - log->l_iclog_bufs = XLOG_NUM_ICLOGS; + log->l_iclog_bufs = XLOG_MIN_ICLOGS; } else #endif { @@ -1085,9 +1074,16 @@ * This is the normal path. If m_logbufs == -1, then the * admin has chosen to use the system defaults for logbuffers. */ - if (mp->m_logbufs == -1) - log->l_iclog_bufs = XLOG_NUM_ICLOGS; - else + if (mp->m_logbufs == -1) { + if (xfs_physmem <= btoc(128*1024*1024)) { + log->l_iclog_bufs = XLOG_MIN_ICLOGS; + } else if (xfs_physmem <= btoc(400*1024*1024)) { + log->l_iclog_bufs = XLOG_MED_ICLOGS;; + } else { + /* 256K with 32K bufs */ + log->l_iclog_bufs = XLOG_MAX_ICLOGS; + } + } else log->l_iclog_bufs = mp->m_logbufs; #if defined(DEBUG) || defined(XLOG_NOLOG) @@ -1191,28 +1187,42 @@ int i; int iclogsize; - log = (void *)kmem_zalloc(sizeof(xlog_t), KM_SLEEP); + log = (xlog_t *)kmem_zalloc(sizeof(xlog_t), KM_SLEEP); log->l_mp = mp; log->l_dev = log_dev; log->l_logsize = BBTOB(num_bblks); log->l_logBBstart = blk_offset; log->l_logBBsize = num_bblks; - log->l_roundoff = 0; log->l_covered_state = XLOG_STATE_COVER_IDLE; log->l_flags |= XLOG_ACTIVE_RECOVERY; log->l_prev_block = -1; ASSIGN_ANY_LSN(log->l_tail_lsn, 1, 0, ARCH_NOCONVERT); - /* log->l_tail_lsn = 0x100000000LL; cycle = 1; current block = 0 */ + /* log->l_tail_lsn = 0x100000000LL; cycle = 1; current block = 0 */ log->l_last_sync_lsn = log->l_tail_lsn; log->l_curr_cycle = 1; /* 0 is bad since this is initial value */ - log->l_curr_block = 0; /* filled in by xlog_recover */ - log->l_grant_reserve_bytes = 0; log->l_grant_reserve_cycle = 1; - log->l_grant_write_bytes = 0; log->l_grant_write_cycle = 1; - log->l_quotaoffs_flag = 0; /* XFS_LI_QUOTAOFF logitems */ + + if (XFS_SB_VERSION_HASLOGV2(&mp->m_sb)) { + if (mp->m_sb.sb_logsunit <= 1) { + log->l_stripemask = 1; + } else { + log->l_stripemask = 1 << + xfs_highbit32(mp->m_sb.sb_logsunit >> BBSHIFT); + } + } + if (XFS_SB_VERSION_HASSECTOR(&mp->m_sb)) { + log->l_sectbb_log = mp->m_sb.sb_logsectlog - BBSHIFT; + ASSERT(log->l_sectbb_log <= mp->m_sectbb_log); + /* for larger sector sizes, must have v2 or external log */ + ASSERT(log->l_sectbb_log == 0 || + log->l_logBBstart == 0 || + XFS_SB_VERSION_HASLOGV2(&mp->m_sb)); + ASSERT(mp->m_sb.sb_logsectlog >= BBSHIFT); + } + log->l_sectbb_mask = (1 << log->l_sectbb_log) - 1; xlog_get_iclog_buffer_size(mp, log); @@ -2811,10 +2821,9 @@ /* Round up to next log-sunit */ if (XFS_SB_VERSION_HASLOGV2(&log->l_mp->m_sb)) { - if (log->l_curr_block & (log->l_mp->m_lstripemask - 1)) { - roundup = log->l_mp->m_lstripemask - - (log->l_curr_block & - (log->l_mp->m_lstripemask - 1)); + if (log->l_curr_block & (log->l_stripemask - 1)) { + roundup = log->l_stripemask - + (log->l_curr_block & (log->l_stripemask - 1)); } else { roundup = 0; } @@ -3293,15 +3302,17 @@ { xfs_buf_t *bp; uint cycle_no; + xfs_caddr_t ptr; xfs_daddr_t i; if (BLOCK_LSN(iclog->ic_header.h_lsn, ARCH_CONVERT) < 10) { cycle_no = CYCLE_LSN(iclog->ic_header.h_lsn, ARCH_CONVERT); - bp = xlog_get_bp(1, log->l_mp); + bp = xlog_get_bp(log, 1); ASSERT(bp); for (i = 0; i < BLOCK_LSN(iclog->ic_header.h_lsn, ARCH_CONVERT); i++) { xlog_bread(log, i, 1, bp); - if (GET_CYCLE(XFS_BUF_PTR(bp), ARCH_CONVERT) != cycle_no) + ptr = xlog_align(log, i, 1, bp); + if (GET_CYCLE(ptr, ARCH_CONVERT) != cycle_no) xlog_warn("XFS: xlog_verify_disk_cycle_no: bad cycle no"); } xlog_put_bp(bp); diff --exclude=dmapi -rNu ORIG/fs/xfs/xfs_log.h HACK/fs/xfs/xfs_log.h --- ORIG/fs/xfs/xfs_log.h 2003-07-23 09:16:40.000000000 -0500 +++ HACK/fs/xfs/xfs_log.h 2003-06-02 11:53:25.000000000 -0500 @@ -1,5 +1,5 @@ /* - * Copyright (c) 2000-2002 Silicon Graphics, Inc. All Rights Reserved. + * Copyright (c) 2000-2003 Silicon Graphics, Inc. All Rights Reserved. * * This program is free software; you can redistribute it and/or modify it * under the terms of version 2 of the GNU General Public License as @@ -153,7 +153,6 @@ int xfs_log_force(struct xfs_mount *mp, xfs_lsn_t lsn, uint flags); -int xfs_log_init(void); int xfs_log_mount(struct xfs_mount *mp, dev_t log_dev, xfs_daddr_t start_block, diff --exclude=dmapi -rNu ORIG/fs/xfs/xfs_log_priv.h HACK/fs/xfs/xfs_log_priv.h --- ORIG/fs/xfs/xfs_log_priv.h 2003-07-23 09:16:40.000000000 -0500 +++ HACK/fs/xfs/xfs_log_priv.h 2003-07-15 22:24:11.000000000 -0500 @@ -1,5 +1,5 @@ /* - * Copyright (c) 2000-2002 Silicon Graphics, Inc. All Rights Reserved. + * Copyright (c) 2000-2003 Silicon Graphics, Inc. All Rights Reserved. * * This program is free software; you can redistribute it and/or modify it * under the terms of version 2 of the GNU General Public License as @@ -50,7 +50,8 @@ * Macros, structures, prototypes for internal log manager use. */ -#define XLOG_NUM_ICLOGS 2 +#define XLOG_MIN_ICLOGS 2 +#define XLOG_MED_ICLOGS 4 #define XLOG_MAX_ICLOGS 8 #define XLOG_CALLBACK_SIZE 10 #define XLOG_HEADER_MAGIC_NUM 0xFEEDbabe /* Illegal cycle number */ @@ -73,6 +74,9 @@ #define XLOG_HEADER_SIZE 512 +#define XLOG_REC_SHIFT(log) \ + BTOBB(1 << (XFS_SB_VERSION_HASLOGV2(&log->l_mp->m_sb) ? \ + XLOG_MAX_RECORD_BSHIFT : XLOG_BIG_RECORD_BSHIFT)) #define XLOG_TOTAL_REC_SHIFT(log) \ BTOBB(XLOG_MAX_ICLOGS << (XFS_SB_VERSION_HASLOGV2(&log->l_mp->m_sb) ? \ XLOG_MAX_RECORD_BSHIFT : XLOG_BIG_RECORD_BSHIFT)) @@ -202,9 +206,9 @@ #define LOG_LOCK(log) mutex_spinlock(&(log)->l_icloglock) #define LOG_UNLOCK(log, s) mutex_spinunlock(&(log)->l_icloglock, s) -#define xlog_panic(s) {cmn_err(CE_PANIC, s); } -#define xlog_exit(s) {cmn_err(CE_PANIC, s); } -#define xlog_warn(s) {cmn_err(CE_WARN, s); } +#define xlog_panic(args...) cmn_err(CE_PANIC, ## args) +#define xlog_exit(args...) cmn_err(CE_PANIC, ## args) +#define xlog_warn(args...) cmn_err(CE_WARN, ## args) /* * In core log state @@ -403,6 +407,7 @@ uint xh_cycle; /* write cycle of log : 4 */ uint xh_cycle_data[XLOG_HEADER_CYCLE_SIZE / BBSIZE]; /* : 256 */ } xlog_rec_ext_header_t; + #ifdef __KERNEL__ /* * - A log record header is 512 bytes. There is plenty of room to grow the @@ -441,12 +446,10 @@ char *ic_datap; /* pointer to iclog data */ } xlog_iclog_fields_t; -typedef struct xlog_in_core2 { - union { - xlog_rec_header_t hic_header; - xlog_rec_ext_header_t hic_xheader; - char hic_sector[XLOG_HEADER_SIZE]; - } ic_h; +typedef union xlog_in_core2 { + xlog_rec_header_t hic_header; + xlog_rec_ext_header_t hic_xheader; + char hic_sector[XLOG_HEADER_SIZE]; } xlog_in_core_2_t; typedef struct xlog_in_core { @@ -473,7 +476,7 @@ #define ic_bwritecnt hic_fields.ic_bwritecnt #define ic_state hic_fields.ic_state #define ic_datap hic_fields.ic_datap -#define ic_header hic_data->ic_h.hic_header +#define ic_header hic_data->hic_header /* * The reservation head lsn is not made up of a cycle number and block number. @@ -530,8 +533,11 @@ uint l_flags; uint l_quotaoffs_flag;/* XFS_DQ_*, if QUOTAOFFs found */ struct xfs_buf_cancel **l_buf_cancel_table; + int l_stripemask; /* log stripe mask */ int l_iclog_hsize; /* size of iclog header */ int l_iclog_heads; /* number of iclog header sectors */ + uint l_sectbb_log; /* log2 of sector size in bbs */ + uint l_sectbb_mask; /* sector size in bbs alignment mask */ } xlog_t; @@ -546,11 +552,13 @@ extern int xlog_recover(xlog_t *log, int readonly); extern int xlog_recover_finish(xlog_t *log, int mfsi_flags); extern void xlog_pack_data(xlog_t *log, xlog_in_core_t *iclog); -extern struct xfs_buf *xlog_get_bp(int,xfs_mount_t *); -extern void xlog_put_bp(struct xfs_buf *); -extern int xlog_bread(xlog_t *, xfs_daddr_t blkno, int bblks, struct xfs_buf *bp); extern void xlog_recover_process_iunlinks(xlog_t *log); +extern struct xfs_buf *xlog_get_bp(xlog_t *, int); +extern void xlog_put_bp(struct xfs_buf *); +extern int xlog_bread(xlog_t *, xfs_daddr_t, int, struct xfs_buf *); +extern xfs_caddr_t xlog_align(xlog_t *, xfs_daddr_t, int, struct xfs_buf *); + #define XLOG_TRACE_GRAB_FLUSH 1 #define XLOG_TRACE_REL_FLUSH 2 #define XLOG_TRACE_SLEEP_FLUSH 3 diff --exclude=dmapi -rNu ORIG/fs/xfs/xfs_log_recover.c HACK/fs/xfs/xfs_log_recover.c --- ORIG/fs/xfs/xfs_log_recover.c 2003-07-23 09:16:40.000000000 -0500 +++ HACK/fs/xfs/xfs_log_recover.c 2003-06-26 11:49:36.000000000 -0500 @@ -1,5 +1,5 @@ /* - * Copyright (c) 2000-2002 Silicon Graphics, Inc. All Rights Reserved. + * Copyright (c) 2000-2003 Silicon Graphics, Inc. All Rights Reserved. * * This program is free software; you can redistribute it and/or modify it * under the terms of version 2 of the GNU General Public License as @@ -65,53 +65,68 @@ #include "xfs_quota.h" #include "xfs_rw.h" -STATIC int xlog_find_zeroed(struct log *log, xfs_daddr_t *blk_no); - -STATIC int xlog_clear_stale_blocks(xlog_t *log, xfs_lsn_t tail_lsn); +STATIC int xlog_find_zeroed(xlog_t *, xfs_daddr_t *); +STATIC int xlog_clear_stale_blocks(xlog_t *, xfs_lsn_t); STATIC void xlog_recover_insert_item_backq(xlog_recover_item_t **q, xlog_recover_item_t *item); - #if defined(DEBUG) -STATIC void xlog_recover_check_summary(xlog_t *log); -STATIC void xlog_recover_check_ail(xfs_mount_t *mp, xfs_log_item_t *lip, - int gen); +STATIC void xlog_recover_check_summary(xlog_t *); +STATIC void xlog_recover_check_ail(xfs_mount_t *, xfs_log_item_t *, int); #else #define xlog_recover_check_summary(log) #define xlog_recover_check_ail(mp, lip, gen) -#endif /* DEBUG */ +#endif +/* + * Sector aligned buffer routines for buffer create/read/write/access + */ + +#define XLOG_SECTOR_ROUNDUP_BBCOUNT(log, bbs) \ + ( ((log)->l_sectbb_mask && (bbs & (log)->l_sectbb_mask)) ? \ + ((bbs + (log)->l_sectbb_mask + 1) & ~(log)->l_sectbb_mask) : (bbs) ) +#define XLOG_SECTOR_ROUNDDOWN_BLKNO(log, bno) ((bno) & ~(log)->l_sectbb_mask) + xfs_buf_t * -xlog_get_bp(int num_bblks, xfs_mount_t *mp) +xlog_get_bp( + xlog_t *log, + int num_bblks) { - xfs_buf_t *bp; - ASSERT(num_bblks > 0); - bp = XFS_ngetrbuf(BBTOB(num_bblks),mp); - return bp; -} /* xlog_get_bp */ - + if (log->l_sectbb_log) { + if (num_bblks > 1) + num_bblks += XLOG_SECTOR_ROUNDUP_BBCOUNT(log, 1); + num_bblks = XLOG_SECTOR_ROUNDUP_BBCOUNT(log, num_bblks); + } + return XFS_ngetrbuf(BBTOB(num_bblks), log->l_mp); +} void -xlog_put_bp(xfs_buf_t *bp) +xlog_put_bp( + xfs_buf_t *bp) { XFS_nfreerbuf(bp); -} /* xlog_put_bp */ +} /* * nbblks should be uint, but oh well. Just want to catch that 32-bit length. */ int -xlog_bread(xlog_t *log, - xfs_daddr_t blk_no, - int nbblks, - xfs_buf_t *bp) +xlog_bread( + xlog_t *log, + xfs_daddr_t blk_no, + int nbblks, + xfs_buf_t *bp) { - int error; + int error; + + if (log->l_sectbb_log) { + blk_no = XLOG_SECTOR_ROUNDDOWN_BLKNO(log, blk_no); + nbblks = XLOG_SECTOR_ROUNDUP_BBCOUNT(log, nbblks); + } - ASSERT(log); ASSERT(nbblks > 0); ASSERT(BBTOB(nbblks) <= XFS_BUF_SIZE(bp)); ASSERT(bp); @@ -123,14 +138,11 @@ XFS_BUF_SET_TARGET(bp, log->l_mp->m_logdev_targp); xfsbdstrat(log->l_mp, bp); - if ((error = xfs_iowait(bp))) { + if ((error = xfs_iowait(bp))) xfs_ioerror_alert("xlog_bread", log->l_mp, bp, XFS_BUF_ADDR(bp)); - return (error); - } return error; -} /* xlog_bread */ - +} /* * Write out the buffer at the given block for the given number of blocks. @@ -139,12 +151,17 @@ */ int xlog_bwrite( - xlog_t *log, - int blk_no, - int nbblks, + xlog_t *log, + xfs_daddr_t blk_no, + int nbblks, xfs_buf_t *bp) { - int error; + int error; + + if (log->l_sectbb_log) { + blk_no = XLOG_SECTOR_ROUNDDOWN_BLKNO(log, blk_no); + nbblks = XLOG_SECTOR_ROUNDUP_BBCOUNT(log, nbblks); + } ASSERT(nbblks > 0); ASSERT(BBTOB(nbblks) <= XFS_BUF_SIZE(bp)); @@ -160,94 +177,109 @@ if ((error = xfs_bwrite(log->l_mp, bp))) xfs_ioerror_alert("xlog_bwrite", log->l_mp, bp, XFS_BUF_ADDR(bp)); + return error; +} - return (error); -} /* xlog_bwrite */ +xfs_caddr_t +xlog_align( + xlog_t *log, + xfs_daddr_t blk_no, + int nbblks, + xfs_buf_t *bp) +{ + xfs_caddr_t ptr; + + if (!log->l_sectbb_log) + return XFS_BUF_PTR(bp); + + ptr = XFS_BUF_PTR(bp) + BBTOB((int)blk_no & log->l_sectbb_mask); + ASSERT(XFS_BUF_SIZE(bp) >= + BBTOB(nbblks + (blk_no & log->l_sectbb_mask))); + return ptr; +} #ifdef DEBUG /* - * check log record header for recovery + * dump debug superblock and log record information */ -static void -xlog_header_check_dump(xfs_mount_t *mp, xlog_rec_header_t *head) +STATIC void +xlog_header_check_dump( + xfs_mount_t *mp, + xlog_rec_header_t *head) { - int b; + int b; - printk("%s: SB : uuid = ", __FUNCTION__); - for (b=0;b<16;b++) printk("%02x",((unsigned char *)&mp->m_sb.sb_uuid)[b]); - printk(", fmt = %d\n",XLOG_FMT); - printk(" log : uuid = "); - for (b=0;b<16;b++) printk("%02x",((unsigned char *)&head->h_fs_uuid)[b]); - printk(", fmt = %d\n", INT_GET(head->h_fmt, ARCH_CONVERT)); + printk("%s: SB : uuid = ", __FUNCTION__); + for (b = 0; b < 16; b++) + printk("%02x",((unsigned char *)&mp->m_sb.sb_uuid)[b]); + printk(", fmt = %d\n", XLOG_FMT); + printk(" log : uuid = "); + for (b = 0; b < 16; b++) + printk("%02x",((unsigned char *)&head->h_fs_uuid)[b]); + printk(", fmt = %d\n", INT_GET(head->h_fmt, ARCH_CONVERT)); } +#else +#define xlog_header_check_dump(mp, head) #endif /* * check log record header for recovery */ - STATIC int -xlog_header_check_recover(xfs_mount_t *mp, xlog_rec_header_t *head) +xlog_header_check_recover( + xfs_mount_t *mp, + xlog_rec_header_t *head) { - ASSERT(INT_GET(head->h_magicno, ARCH_CONVERT) == XLOG_HEADER_MAGIC_NUM); - - /* - * IRIX doesn't write the h_fmt field and leaves it zeroed - * (XLOG_FMT_UNKNOWN). This stops us from trying to recover - * a dirty log created in IRIX. - */ + ASSERT(INT_GET(head->h_magicno, ARCH_CONVERT) == XLOG_HEADER_MAGIC_NUM); - if (unlikely(INT_GET(head->h_fmt, ARCH_CONVERT) != XLOG_FMT)) { - xlog_warn("XFS: dirty log written in incompatible format - can't recover"); -#ifdef DEBUG - xlog_header_check_dump(mp, head); -#endif - XFS_ERROR_REPORT("xlog_header_check_recover(1)", - XFS_ERRLEVEL_HIGH, mp); - return XFS_ERROR(EFSCORRUPTED); - } else if (unlikely(!uuid_equal(&mp->m_sb.sb_uuid, &head->h_fs_uuid))) { - xlog_warn("XFS: dirty log entry has mismatched uuid - can't recover"); -#ifdef DEBUG - xlog_header_check_dump(mp, head); -#endif - XFS_ERROR_REPORT("xlog_header_check_recover(2)", - XFS_ERRLEVEL_HIGH, mp); - return XFS_ERROR(EFSCORRUPTED); - } - - return 0; + /* + * IRIX doesn't write the h_fmt field and leaves it zeroed + * (XLOG_FMT_UNKNOWN). This stops us from trying to recover + * a dirty log created in IRIX. + */ + if (unlikely(INT_GET(head->h_fmt, ARCH_CONVERT) != XLOG_FMT)) { + xlog_warn( + "XFS: dirty log written in incompatible format - can't recover"); + xlog_header_check_dump(mp, head); + XFS_ERROR_REPORT("xlog_header_check_recover(1)", + XFS_ERRLEVEL_HIGH, mp); + return XFS_ERROR(EFSCORRUPTED); + } else if (unlikely(!uuid_equal(&mp->m_sb.sb_uuid, &head->h_fs_uuid))) { + xlog_warn( + "XFS: dirty log entry has mismatched uuid - can't recover"); + xlog_header_check_dump(mp, head); + XFS_ERROR_REPORT("xlog_header_check_recover(2)", + XFS_ERRLEVEL_HIGH, mp); + return XFS_ERROR(EFSCORRUPTED); + } + return 0; } /* * read the head block of the log and check the header */ - STATIC int -xlog_header_check_mount(xfs_mount_t *mp, xlog_rec_header_t *head) +xlog_header_check_mount( + xfs_mount_t *mp, + xlog_rec_header_t *head) { - ASSERT(INT_GET(head->h_magicno, ARCH_CONVERT) == XLOG_HEADER_MAGIC_NUM); - - if (uuid_is_nil(&head->h_fs_uuid)) { + ASSERT(INT_GET(head->h_magicno, ARCH_CONVERT) == XLOG_HEADER_MAGIC_NUM); - /* - * IRIX doesn't write the h_fs_uuid or h_fmt fields. If - * h_fs_uuid is nil, we assume this log was last mounted - * by IRIX and continue. - */ - - xlog_warn("XFS: nil uuid in log - IRIX style log"); - - } else if (unlikely(!uuid_equal(&mp->m_sb.sb_uuid, &head->h_fs_uuid))) { - xlog_warn("XFS: log has mismatched uuid - can't recover"); -#ifdef DEBUG - xlog_header_check_dump(mp, head); -#endif - XFS_ERROR_REPORT("xlog_header_check_mount", - XFS_ERRLEVEL_HIGH, mp); - return XFS_ERROR(EFSCORRUPTED); - } - - return 0; + if (uuid_is_nil(&head->h_fs_uuid)) { + /* + * IRIX doesn't write the h_fs_uuid or h_fmt fields. If + * h_fs_uuid is nil, we assume this log was last mounted + * by IRIX and continue. + */ + xlog_warn("XFS: nil uuid in log - IRIX style log"); + } else if (unlikely(!uuid_equal(&mp->m_sb.sb_uuid, &head->h_fs_uuid))) { + xlog_warn("XFS: log has mismatched uuid - can't recover"); + xlog_header_check_dump(mp, head); + XFS_ERROR_REPORT("xlog_header_check_mount", + XFS_ERRLEVEL_HIGH, mp); + return XFS_ERROR(EFSCORRUPTED); + } + return 0; } STATIC void @@ -255,6 +287,7 @@ struct xfs_buf *bp) { xfs_mount_t *mp; + ASSERT(XFS_BUF_FSPRIVATE(bp, void *)); if (XFS_BUF_GETERROR(bp)) { @@ -279,12 +312,14 @@ * necessarily be perfect. */ int -xlog_find_cycle_start(xlog_t *log, - xfs_buf_t *bp, - xfs_daddr_t first_blk, - xfs_daddr_t *last_blk, - uint cycle) +xlog_find_cycle_start( + xlog_t *log, + xfs_buf_t *bp, + xfs_daddr_t first_blk, + xfs_daddr_t *last_blk, + uint cycle) { + xfs_caddr_t offset; xfs_daddr_t mid_blk; uint mid_cycle; int error; @@ -293,7 +328,8 @@ while (mid_blk != first_blk && mid_blk != *last_blk) { if ((error = xlog_bread(log, mid_blk, 1, bp))) return error; - mid_cycle = GET_CYCLE(XFS_BUF_PTR(bp), ARCH_CONVERT); + offset = xlog_align(log, mid_blk, 1, bp); + mid_cycle = GET_CYCLE(offset, ARCH_CONVERT); if (mid_cycle == cycle) { *last_blk = mid_blk; /* last_half_cycle == mid_cycle */ @@ -307,8 +343,7 @@ (mid_blk == *last_blk && mid_blk-1 == first_blk)); return 0; -} /* xlog_find_cycle_start */ - +} /* * Check that the range of blocks does not contain the cycle number @@ -320,27 +355,27 @@ * Set blkno to -1 if we encounter no errors. This is an invalid block number * since we don't ever expect logs to get this large. */ - STATIC int -xlog_find_verify_cycle( xlog_t *log, - xfs_daddr_t start_blk, - int nbblks, - uint stop_on_cycle_no, - xfs_daddr_t *new_blk) +xlog_find_verify_cycle( + xlog_t *log, + xfs_daddr_t start_blk, + int nbblks, + uint stop_on_cycle_no, + xfs_daddr_t *new_blk) { - xfs_daddr_t i, j; - uint cycle; - xfs_buf_t *bp; - char *buf = NULL; - int error = 0; - xfs_daddr_t bufblks; + xfs_daddr_t i, j; + uint cycle; + xfs_buf_t *bp; + xfs_daddr_t bufblks; + xfs_caddr_t buf = NULL; + int error = 0; bufblks = 1 << ffs(nbblks); - while (!(bp = xlog_get_bp(bufblks, log->l_mp))) { + while (!(bp = xlog_get_bp(log, bufblks))) { /* can't get enough memory to do everything in one big buffer */ bufblks >>= 1; - if (!bufblks) + if (bufblks <= log->l_sectbb_log) return ENOMEM; } @@ -352,7 +387,7 @@ if ((error = xlog_bread(log, i, bcount, bp))) goto out; - buf = XFS_BUF_PTR(bp); + buf = xlog_align(log, i, bcount, bp); for (j = 0; j < bcount; j++) { cycle = GET_CYCLE(buf, ARCH_CONVERT); if (cycle == stop_on_cycle_no) { @@ -368,10 +403,8 @@ out: xlog_put_bp(bp); - return error; -} /* xlog_find_verify_cycle */ - +} /* * Potentially backup over partial log record write. @@ -385,98 +418,103 @@ * extra_bblks is the number of blocks potentially verified on a previous * call to this routine. */ - STATIC int -xlog_find_verify_log_record(xlog_t *log, - xfs_daddr_t start_blk, - xfs_daddr_t *last_blk, - int extra_bblks) -{ - xfs_daddr_t i; - xfs_buf_t *bp; - char *buf = NULL; - xlog_rec_header_t *head = NULL; - int error = 0; - int smallmem = 0; - int num_blks = *last_blk - start_blk; - int xhdrs; - - ASSERT(start_blk != 0 || *last_blk != start_blk); - - if (!(bp = xlog_get_bp(num_blks, log->l_mp))) { - if (!(bp = xlog_get_bp(1, log->l_mp))) - return ENOMEM; - smallmem = 1; - buf = XFS_BUF_PTR(bp); - } else { - if ((error = xlog_bread(log, start_blk, num_blks, bp))) - goto out; - buf = XFS_BUF_PTR(bp) + ((num_blks - 1) << BBSHIFT); - } - - for (i = (*last_blk) - 1; i >= 0; i--) { - if (i < start_blk) { - /* legal log record not found */ - xlog_warn("XFS: Log inconsistent (didn't find previous header)"); - ASSERT(0); - error = XFS_ERROR(EIO); - goto out; +xlog_find_verify_log_record( + xlog_t *log, + xfs_daddr_t start_blk, + xfs_daddr_t *last_blk, + int extra_bblks) +{ + xfs_daddr_t i; + xfs_buf_t *bp; + xfs_caddr_t offset = NULL; + xlog_rec_header_t *head = NULL; + int error = 0; + int smallmem = 0; + int num_blks = *last_blk - start_blk; + int xhdrs; + + ASSERT(start_blk != 0 || *last_blk != start_blk); + + if (!(bp = xlog_get_bp(log, num_blks))) { + if (!(bp = xlog_get_bp(log, 1))) + return ENOMEM; + smallmem = 1; + } else { + if ((error = xlog_bread(log, start_blk, num_blks, bp))) + goto out; + offset = xlog_align(log, start_blk, num_blks, bp); + offset += ((num_blks - 1) << BBSHIFT); } - if (smallmem && (error = xlog_bread(log, i, 1, bp))) - goto out; - head = (xlog_rec_header_t*)buf; - - if (INT_GET(head->h_magicno, ARCH_CONVERT) == XLOG_HEADER_MAGIC_NUM) - break; - - if (!smallmem) - buf -= BBSIZE; - } - - /* - * We hit the beginning of the physical log & still no header. Return - * to caller. If caller can handle a return of -1, then this routine - * will be called again for the end of the physical log. - */ - if (i == -1) { - error = -1; - goto out; - } - - /* we have the final block of the good log (the first block - * of the log record _before_ the head. So we check the uuid. - */ - - if ((error = xlog_header_check_mount(log->l_mp, head))) - goto out; - - /* - * We may have found a log record header before we expected one. - * last_blk will be the 1st block # with a given cycle #. We may end - * up reading an entire log record. In this case, we don't want to - * reset last_blk. Only when last_blk points in the middle of a log - * record do we update last_blk. - */ - if (XFS_SB_VERSION_HASLOGV2(&log->l_mp->m_sb)) { - uint h_size = INT_GET(head->h_size, ARCH_CONVERT); - - xhdrs = h_size / XLOG_HEADER_CYCLE_SIZE; - if (h_size % XLOG_HEADER_CYCLE_SIZE) - xhdrs++; - } else { - xhdrs = 1; - } - - if (*last_blk - i + extra_bblks - != BTOBB(INT_GET(head->h_len, ARCH_CONVERT))+xhdrs) - *last_blk = i; + for (i = (*last_blk) - 1; i >= 0; i--) { + if (i < start_blk) { + /* legal log record not found */ + xlog_warn( + "XFS: Log inconsistent (didn't find previous header)"); + ASSERT(0); + error = XFS_ERROR(EIO); + goto out; + } -out: - xlog_put_bp(bp); + if (smallmem) { + if ((error = xlog_bread(log, i, 1, bp))) + goto out; + offset = xlog_align(log, i, 1, bp); + } - return error; -} /* xlog_find_verify_log_record */ + head = (xlog_rec_header_t *)offset; + + if (XLOG_HEADER_MAGIC_NUM == + INT_GET(head->h_magicno, ARCH_CONVERT)) + break; + + if (!smallmem) + offset -= BBSIZE; + } + + /* + * We hit the beginning of the physical log & still no header. Return + * to caller. If caller can handle a return of -1, then this routine + * will be called again for the end of the physical log. + */ + if (i == -1) { + error = -1; + goto out; + } + + /* + * We have the final block of the good log (the first block + * of the log record _before_ the head. So we check the uuid. + */ + if ((error = xlog_header_check_mount(log->l_mp, head))) + goto out; + + /* + * We may have found a log record header before we expected one. + * last_blk will be the 1st block # with a given cycle #. We may end + * up reading an entire log record. In this case, we don't want to + * reset last_blk. Only when last_blk points in the middle of a log + * record do we update last_blk. + */ + if (XFS_SB_VERSION_HASLOGV2(&log->l_mp->m_sb)) { + uint h_size = INT_GET(head->h_size, ARCH_CONVERT); + + xhdrs = h_size / XLOG_HEADER_CYCLE_SIZE; + if (h_size % XLOG_HEADER_CYCLE_SIZE) + xhdrs++; + } else { + xhdrs = 1; + } + + if (*last_blk - i + extra_bblks + != BTOBB(INT_GET(head->h_len, ARCH_CONVERT)) + xhdrs) + *last_blk = i; + +out: + xlog_put_bp(bp); + return error; +} /* * Head is defined to be the point of the log where the next log write @@ -489,252 +527,257 @@ * last_blk contains the block number of the first block with a given * cycle number. * - * Also called from xfs_log_print.c - * * Return: zero if normal, non-zero if error. */ int -xlog_find_head(xlog_t *log, - xfs_daddr_t *return_head_blk) +xlog_find_head( + xlog_t *log, + xfs_daddr_t *return_head_blk) { - xfs_buf_t *bp; - xfs_daddr_t new_blk, first_blk, start_blk, last_blk, head_blk; - int num_scan_bblks; - uint first_half_cycle, last_half_cycle; - uint stop_on_cycle; - int error, log_bbnum = log->l_logBBsize; - - /* Is the end of the log device zeroed? */ - if ((error = xlog_find_zeroed(log, &first_blk)) == -1) { - *return_head_blk = first_blk; - - /* is the whole lot zeroed? */ - if (!first_blk) { - /* Linux XFS shouldn't generate totally zeroed logs - - * mkfs etc write a dummy unmount record to a fresh - * log so we can store the uuid in there - */ - xlog_warn("XFS: totally zeroed log"); - } + xfs_buf_t *bp; + xfs_caddr_t offset; + xfs_daddr_t new_blk, first_blk, start_blk, last_blk, head_blk; + int num_scan_bblks; + uint first_half_cycle, last_half_cycle; + uint stop_on_cycle; + int error, log_bbnum = log->l_logBBsize; + + /* Is the end of the log device zeroed? */ + if ((error = xlog_find_zeroed(log, &first_blk)) == -1) { + *return_head_blk = first_blk; + + /* Is the whole lot zeroed? */ + if (!first_blk) { + /* Linux XFS shouldn't generate totally zeroed logs - + * mkfs etc write a dummy unmount record to a fresh + * log so we can store the uuid in there + */ + xlog_warn("XFS: totally zeroed log"); + } - return 0; - } else if (error) { - xlog_warn("XFS: empty log check failed"); - return error; - } + return 0; + } else if (error) { + xlog_warn("XFS: empty log check failed"); + return error; + } - first_blk = 0; /* get cycle # of 1st block */ - bp = xlog_get_bp(1,log->l_mp); - if (!bp) - return ENOMEM; - if ((error = xlog_bread(log, 0, 1, bp))) - goto bp_err; - first_half_cycle = GET_CYCLE(XFS_BUF_PTR(bp), ARCH_CONVERT); - - last_blk = head_blk = log_bbnum-1; /* get cycle # of last block */ - if ((error = xlog_bread(log, last_blk, 1, bp))) - goto bp_err; - last_half_cycle = GET_CYCLE(XFS_BUF_PTR(bp), ARCH_CONVERT); - ASSERT(last_half_cycle != 0); - - /* - * If the 1st half cycle number is equal to the last half cycle number, - * then the entire log is stamped with the same cycle number. In this - * case, head_blk can't be set to zero (which makes sense). The below - * math doesn't work out properly with head_blk equal to zero. Instead, - * we set it to log_bbnum which is an illegal block number, but this - * value makes the math correct. If head_blk doesn't changed through - * all the tests below, *head_blk is set to zero at the very end rather - * than log_bbnum. In a sense, log_bbnum and zero are the same block - * in a circular file. - */ - if (first_half_cycle == last_half_cycle) { - /* - * In this case we believe that the entire log should have cycle - * number last_half_cycle. We need to scan backwards from the - * end verifying that there are no holes still containing - * last_half_cycle - 1. If we find such a hole, then the start - * of that hole will be the new head. The simple case looks like - * x | x ... | x - 1 | x - * Another case that fits this picture would be - * x | x + 1 | x ... | x - * In this case the head really is somwhere at the end of the - * log, as one of the latest writes at the beginning was incomplete. - * One more case is - * x | x + 1 | x ... | x - 1 | x - * This is really the combination of the above two cases, and the - * head has to end up at the start of the x-1 hole at the end of - * the log. - * - * In the 256k log case, we will read from the beginning to the - * end of the log and search for cycle numbers equal to x-1. We - * don't worry about the x+1 blocks that we encounter, because - * we know that they cannot be the head since the log started with - * x. - */ - head_blk = log_bbnum; - stop_on_cycle = last_half_cycle - 1; - } else { - /* - * In this case we want to find the first block with cycle number - * matching last_half_cycle. We expect the log to be some - * variation on - * x + 1 ... | x ... - * The first block with cycle number x (last_half_cycle) will be - * where the new head belongs. First we do a binary search for - * the first occurrence of last_half_cycle. The binary search - * may not be totally accurate, so then we scan back from there - * looking for occurrences of last_half_cycle before us. If - * that backwards scan wraps around the beginning of the log, - * then we look for occurrences of last_half_cycle - 1 at the - * end of the log. The cases we're looking for look like - * x + 1 ... | x | x + 1 | x ... - * ^ binary search stopped here - * or - * x + 1 ... | x ... | x - 1 | x - * <---------> less than scan distance - */ - stop_on_cycle = last_half_cycle; - if ((error = xlog_find_cycle_start(log, bp, first_blk, - &head_blk, last_half_cycle))) - goto bp_err; - } + first_blk = 0; /* get cycle # of 1st block */ + bp = xlog_get_bp(log, 1); + if (!bp) + return ENOMEM; + if ((error = xlog_bread(log, 0, 1, bp))) + goto bp_err; + offset = xlog_align(log, 0, 1, bp); + first_half_cycle = GET_CYCLE(offset, ARCH_CONVERT); - /* - * Now validate the answer. Scan back some number of maximum possible - * blocks and make sure each one has the expected cycle number. The - * maximum is determined by the total possible amount of buffering - * in the in-core log. The following number can be made tighter if - * we actually look at the block size of the filesystem. - */ - num_scan_bblks = XLOG_TOTAL_REC_SHIFT(log); - if (head_blk >= num_scan_bblks) { - /* - * We are guaranteed that the entire check can be performed - * in one buffer. - */ - start_blk = head_blk - num_scan_bblks; - if ((error = xlog_find_verify_cycle(log, start_blk, num_scan_bblks, - stop_on_cycle, &new_blk))) - goto bp_err; - if (new_blk != -1) - head_blk = new_blk; - } else { /* need to read 2 parts of log */ - /* - * We are going to scan backwards in the log in two parts. First - * we scan the physical end of the log. In this part of the log, - * we are looking for blocks with cycle number last_half_cycle - 1. - * If we find one, then we know that the log starts there, as we've - * found a hole that didn't get written in going around the end - * of the physical log. The simple case for this is - * x + 1 ... | x ... | x - 1 | x - * <---------> less than scan distance - * If all of the blocks at the end of the log have cycle number - * last_half_cycle, then we check the blocks at the start of the - * log looking for occurrences of last_half_cycle. If we find one, - * then our current estimate for the location of the first - * occurrence of last_half_cycle is wrong and we move back to the - * hole we've found. This case looks like - * x + 1 ... | x | x + 1 | x ... - * ^ binary search stopped here - * Another case we need to handle that only occurs in 256k logs is - * x + 1 ... | x ... | x+1 | x ... - * ^ binary search stops here - * In a 256k log, the scan at the end of the log will see the x+1 - * blocks. We need to skip past those since that is certainly not - * the head of the log. By searching for last_half_cycle-1 we - * accomplish that. - */ - start_blk = log_bbnum - num_scan_bblks + head_blk; - ASSERT(head_blk <= INT_MAX && (xfs_daddr_t) num_scan_bblks-head_blk >= 0); - if ((error = xlog_find_verify_cycle(log, start_blk, - num_scan_bblks-(int)head_blk, (stop_on_cycle - 1), - &new_blk))) + last_blk = head_blk = log_bbnum - 1; /* get cycle # of last block */ + if ((error = xlog_bread(log, last_blk, 1, bp))) goto bp_err; - if (new_blk != -1) { - head_blk = new_blk; - goto bad_blk; + offset = xlog_align(log, last_blk, 1, bp); + last_half_cycle = GET_CYCLE(offset, ARCH_CONVERT); + ASSERT(last_half_cycle != 0); + + /* + * If the 1st half cycle number is equal to the last half cycle number, + * then the entire log is stamped with the same cycle number. In this + * case, head_blk can't be set to zero (which makes sense). The below + * math doesn't work out properly with head_blk equal to zero. Instead, + * we set it to log_bbnum which is an illegal block number, but this + * value makes the math correct. If head_blk doesn't changed through + * all the tests below, *head_blk is set to zero at the very end rather + * than log_bbnum. In a sense, log_bbnum and zero are the same block + * in a circular file. + */ + if (first_half_cycle == last_half_cycle) { + /* + * In this case we believe that the entire log should have + * cycle number last_half_cycle. We need to scan backwards + * from the end verifying that there are no holes still + * containing last_half_cycle - 1. If we find such a hole, + * then the start of that hole will be the new head. The + * simple case looks like + * x | x ... | x - 1 | x + * Another case that fits this picture would be + * x | x + 1 | x ... | x + * In this case the head really is somwhere at the end of the + * log, as one of the latest writes at the beginning was + * incomplete. + * One more case is + * x | x + 1 | x ... | x - 1 | x + * This is really the combination of the above two cases, and + * the head has to end up at the start of the x-1 hole at the + * end of the log. + * + * In the 256k log case, we will read from the beginning to the + * end of the log and search for cycle numbers equal to x-1. + * We don't worry about the x+1 blocks that we encounter, + * because we know that they cannot be the head since the log + * started with x. + */ + head_blk = log_bbnum; + stop_on_cycle = last_half_cycle - 1; + } else { + /* + * In this case we want to find the first block with cycle + * number matching last_half_cycle. We expect the log to be + * some variation on + * x + 1 ... | x ... + * The first block with cycle number x (last_half_cycle) will + * be where the new head belongs. First we do a binary search + * for the first occurrence of last_half_cycle. The binary + * search may not be totally accurate, so then we scan back + * from there looking for occurrences of last_half_cycle before + * us. If that backwards scan wraps around the beginning of + * the log, then we look for occurrences of last_half_cycle - 1 + * at the end of the log. The cases we're looking for look + * like + * x + 1 ... | x | x + 1 | x ... + * ^ binary search stopped here + * or + * x + 1 ... | x ... | x - 1 | x + * <---------> less than scan distance + */ + stop_on_cycle = last_half_cycle; + if ((error = xlog_find_cycle_start(log, bp, first_blk, + &head_blk, last_half_cycle))) + goto bp_err; } /* - * Scan beginning of log now. The last part of the physical log - * is good. This scan needs to verify that it doesn't find the - * last_half_cycle. + * Now validate the answer. Scan back some number of maximum possible + * blocks and make sure each one has the expected cycle number. The + * maximum is determined by the total possible amount of buffering + * in the in-core log. The following number can be made tighter if + * we actually look at the block size of the filesystem. */ - start_blk = 0; - ASSERT(head_blk <= INT_MAX); - if ((error = xlog_find_verify_cycle(log, start_blk, (int) head_blk, - stop_on_cycle, &new_blk))) - goto bp_err; - if (new_blk != -1) - head_blk = new_blk; - } - -bad_blk: - /* - * Now we need to make sure head_blk is not pointing to a block in - * the middle of a log record. - */ - num_scan_bblks = BTOBB(XLOG_MAX_RECORD_BSIZE); - if (head_blk >= num_scan_bblks) { - start_blk = head_blk - num_scan_bblks; /* don't read head_blk */ - - /* start ptr at last block ptr before head_blk */ - if ((error = xlog_find_verify_log_record(log, - start_blk, - &head_blk, - 0)) == -1) { - error = XFS_ERROR(EIO); - goto bp_err; - } else if (error) - goto bp_err; - } else { - start_blk = 0; - ASSERT(head_blk <= INT_MAX); - if ((error = xlog_find_verify_log_record(log, - start_blk, - &head_blk, - 0)) == -1) { - /* We hit the beginning of the log during our search */ - start_blk = log_bbnum - num_scan_bblks + head_blk; - new_blk = log_bbnum; - ASSERT(start_blk <= INT_MAX && (xfs_daddr_t) log_bbnum-start_blk >= 0); - ASSERT(head_blk <= INT_MAX); - if ((error = xlog_find_verify_log_record(log, - start_blk, - &new_blk, - (int)head_blk)) == -1) { - error = XFS_ERROR(EIO); - goto bp_err; - } else if (error) - goto bp_err; - if (new_blk != log_bbnum) - head_blk = new_blk; - } else if (error) - goto bp_err; - } + num_scan_bblks = XLOG_TOTAL_REC_SHIFT(log); + if (head_blk >= num_scan_bblks) { + /* + * We are guaranteed that the entire check can be performed + * in one buffer. + */ + start_blk = head_blk - num_scan_bblks; + if ((error = xlog_find_verify_cycle(log, + start_blk, num_scan_bblks, + stop_on_cycle, &new_blk))) + goto bp_err; + if (new_blk != -1) + head_blk = new_blk; + } else { /* need to read 2 parts of log */ + /* + * We are going to scan backwards in the log in two parts. + * First we scan the physical end of the log. In this part + * of the log, we are looking for blocks with cycle number + * last_half_cycle - 1. + * If we find one, then we know that the log starts there, as + * we've found a hole that didn't get written in going around + * the end of the physical log. The simple case for this is + * x + 1 ... | x ... | x - 1 | x + * <---------> less than scan distance + * If all of the blocks at the end of the log have cycle number + * last_half_cycle, then we check the blocks at the start of + * the log looking for occurrences of last_half_cycle. If we + * find one, then our current estimate for the location of the + * first occurrence of last_half_cycle is wrong and we move + * back to the hole we've found. This case looks like + * x + 1 ... | x | x + 1 | x ... + * ^ binary search stopped here + * Another case we need to handle that only occurs in 256k + * logs is + * x + 1 ... | x ... | x+1 | x ... + * ^ binary search stops here + * In a 256k log, the scan at the end of the log will see the + * x + 1 blocks. We need to skip past those since that is + * certainly not the head of the log. By searching for + * last_half_cycle-1 we accomplish that. + */ + start_blk = log_bbnum - num_scan_bblks + head_blk; + ASSERT(head_blk <= INT_MAX && + (xfs_daddr_t) num_scan_bblks - head_blk >= 0); + if ((error = xlog_find_verify_cycle(log, start_blk, + num_scan_bblks - (int)head_blk, + (stop_on_cycle - 1), &new_blk))) + goto bp_err; + if (new_blk != -1) { + head_blk = new_blk; + goto bad_blk; + } + + /* + * Scan beginning of log now. The last part of the physical + * log is good. This scan needs to verify that it doesn't find + * the last_half_cycle. + */ + start_blk = 0; + ASSERT(head_blk <= INT_MAX); + if ((error = xlog_find_verify_cycle(log, + start_blk, (int)head_blk, + stop_on_cycle, &new_blk))) + goto bp_err; + if (new_blk != -1) + head_blk = new_blk; + } + + bad_blk: + /* + * Now we need to make sure head_blk is not pointing to a block in + * the middle of a log record. + */ + num_scan_bblks = XLOG_REC_SHIFT(log); + if (head_blk >= num_scan_bblks) { + start_blk = head_blk - num_scan_bblks; /* don't read head_blk */ + + /* start ptr at last block ptr before head_blk */ + if ((error = xlog_find_verify_log_record(log, start_blk, + &head_blk, 0)) == -1) { + error = XFS_ERROR(EIO); + goto bp_err; + } else if (error) + goto bp_err; + } else { + start_blk = 0; + ASSERT(head_blk <= INT_MAX); + if ((error = xlog_find_verify_log_record(log, start_blk, + &head_blk, 0)) == -1) { + /* We hit the beginning of the log during our search */ + start_blk = log_bbnum - num_scan_bblks + head_blk; + new_blk = log_bbnum; + ASSERT(start_blk <= INT_MAX && + (xfs_daddr_t) log_bbnum-start_blk >= 0); + ASSERT(head_blk <= INT_MAX); + if ((error = xlog_find_verify_log_record(log, + start_blk, &new_blk, + (int)head_blk)) == -1) { + error = XFS_ERROR(EIO); + goto bp_err; + } else if (error) + goto bp_err; + if (new_blk != log_bbnum) + head_blk = new_blk; + } else if (error) + goto bp_err; + } - xlog_put_bp(bp); - if (head_blk == log_bbnum) - *return_head_blk = 0; - else - *return_head_blk = head_blk; - /* - * When returning here, we have a good block number. Bad block - * means that during a previous crash, we didn't have a clean break - * from cycle number N to cycle number N-1. In this case, we need - * to find the first block with cycle number N-1. - */ - return 0; + xlog_put_bp(bp); + if (head_blk == log_bbnum) + *return_head_blk = 0; + else + *return_head_blk = head_blk; + /* + * When returning here, we have a good block number. Bad block + * means that during a previous crash, we didn't have a clean break + * from cycle number N to cycle number N-1. In this case, we need + * to find the first block with cycle number N-1. + */ + return 0; -bp_err: + bp_err: xlog_put_bp(bp); if (error) xlog_warn("XFS: failed to find log head"); - return error; -} /* xlog_find_head */ +} /* * Find the sync block number or the tail of the log. @@ -753,13 +796,15 @@ * available. */ int -xlog_find_tail(xlog_t *log, - xfs_daddr_t *head_blk, - xfs_daddr_t *tail_blk, - int readonly) +xlog_find_tail( + xlog_t *log, + xfs_daddr_t *head_blk, + xfs_daddr_t *tail_blk, + int readonly) { xlog_rec_header_t *rhead; xlog_op_header_t *op_head; + xfs_caddr_t offset = NULL; xfs_buf_t *bp; int error, i, found; xfs_daddr_t umount_data_blk; @@ -775,13 +820,14 @@ if ((error = xlog_find_head(log, head_blk))) return error; - bp = xlog_get_bp(1,log->l_mp); + bp = xlog_get_bp(log, 1); if (!bp) return ENOMEM; if (*head_blk == 0) { /* special case */ if ((error = xlog_bread(log, 0, 1, bp))) goto bread_err; - if (GET_CYCLE(XFS_BUF_PTR(bp), ARCH_CONVERT) == 0) { + offset = xlog_align(log, 0, 1, bp); + if (GET_CYCLE(offset, ARCH_CONVERT) == 0) { *tail_blk = 0; /* leave all other log inited values alone */ goto exit; @@ -795,8 +841,9 @@ for (i = (int)(*head_blk) - 1; i >= 0; i--) { if ((error = xlog_bread(log, i, 1, bp))) goto bread_err; + offset = xlog_align(log, i, 1, bp); if (XLOG_HEADER_MAGIC_NUM == - INT_GET(*(uint *)(XFS_BUF_PTR(bp)), ARCH_CONVERT)) { + INT_GET(*(uint *)offset, ARCH_CONVERT)) { found = 1; break; } @@ -811,8 +858,9 @@ for (i = log->l_logBBsize - 1; i >= (int)(*head_blk); i--) { if ((error = xlog_bread(log, i, 1, bp))) goto bread_err; + offset = xlog_align(log, i, 1, bp); if (XLOG_HEADER_MAGIC_NUM == - INT_GET(*(uint*)(XFS_BUF_PTR(bp)), ARCH_CONVERT)) { + INT_GET(*(uint*)offset, ARCH_CONVERT)) { found = 2; break; } @@ -825,7 +873,7 @@ } /* find blk_no of tail of log */ - rhead = (xlog_rec_header_t *)XFS_BUF_PTR(bp); + rhead = (xlog_rec_header_t *)offset; *tail_blk = BLOCK_LSN(rhead->h_tail_lsn, ARCH_CONVERT); /* @@ -885,7 +933,8 @@ if ((error = xlog_bread(log, umount_data_blk, 1, bp))) { goto bread_err; } - op_head = (xlog_op_header_t *)XFS_BUF_PTR(bp); + offset = xlog_align(log, umount_data_blk, 1, bp); + op_head = (xlog_op_header_t *)offset; if (op_head->oh_flags & XLOG_UNMOUNT_TRANS) { /* * Set tail and last sync so that newly written @@ -900,7 +949,6 @@ } } -#ifdef __KERNEL__ /* * Make sure that there are no blocks in front of the head * with the same cycle number as the head. This can happen @@ -920,11 +968,9 @@ * But... if the -device- itself is readonly, just skip this. * We can't recover this device anyway, so it won't matter. */ - - if (!is_read_only(log->l_mp->m_logdev_targp->pbr_kdev)) { + if (!xfs_readonly_buftarg(log->l_mp->m_logdev_targp)) { error = xlog_clear_stale_blocks(log, tail_lsn); } -#endif bread_err: exit: @@ -932,10 +978,8 @@ if (error) xlog_warn("XFS: failed to locate log tail"); - return error; -} /* xlog_find_tail */ - +} /* * Is the log zeroed at all? @@ -954,22 +998,25 @@ * >0 => error has occurred */ int -xlog_find_zeroed(struct log *log, - xfs_daddr_t *blk_no) +xlog_find_zeroed( + xlog_t *log, + xfs_daddr_t *blk_no) { xfs_buf_t *bp; + xfs_caddr_t offset; uint first_cycle, last_cycle; xfs_daddr_t new_blk, last_blk, start_blk; xfs_daddr_t num_scan_bblks; int error, log_bbnum = log->l_logBBsize; /* check totally zeroed log */ - bp = xlog_get_bp(1,log->l_mp); + bp = xlog_get_bp(log, 1); if (!bp) return ENOMEM; if ((error = xlog_bread(log, 0, 1, bp))) goto bp_err; - first_cycle = GET_CYCLE(XFS_BUF_PTR(bp), ARCH_CONVERT); + offset = xlog_align(log, 0, 1, bp); + first_cycle = GET_CYCLE(offset, ARCH_CONVERT); if (first_cycle == 0) { /* completely zeroed log */ *blk_no = 0; xlog_put_bp(bp); @@ -979,7 +1026,8 @@ /* check partially zeroed log */ if ((error = xlog_bread(log, log_bbnum-1, 1, bp))) goto bp_err; - last_cycle = GET_CYCLE(XFS_BUF_PTR(bp), ARCH_CONVERT); + offset = xlog_align(log, log_bbnum-1, 1, bp); + last_cycle = GET_CYCLE(offset, ARCH_CONVERT); if (last_cycle != 0) { /* log completely written to */ xlog_put_bp(bp); return 0; @@ -1040,67 +1088,106 @@ if (error) return error; return -1; -} /* xlog_find_zeroed */ +} /* - * This is simply a subroutine used by xlog_clear_stale_blocks() below + * These are simple subroutines used by xlog_clear_stale_blocks() below * to initialize a buffer full of empty log record headers and write * them into the log. */ +STATIC void +xlog_add_record( + xlog_t *log, + xfs_caddr_t buf, + int cycle, + int block, + int tail_cycle, + int tail_block) +{ + xlog_rec_header_t *recp = (xlog_rec_header_t *)buf; + + memset(buf, 0, BBSIZE); + INT_SET(recp->h_magicno, ARCH_CONVERT, XLOG_HEADER_MAGIC_NUM); + INT_SET(recp->h_cycle, ARCH_CONVERT, cycle); + INT_SET(recp->h_version, ARCH_CONVERT, + XFS_SB_VERSION_HASLOGV2(&log->l_mp->m_sb) ? 2 : 1); + ASSIGN_ANY_LSN(recp->h_lsn, cycle, block, ARCH_CONVERT); + ASSIGN_ANY_LSN(recp->h_tail_lsn, tail_cycle, tail_block, ARCH_CONVERT); + INT_SET(recp->h_fmt, ARCH_CONVERT, XLOG_FMT); + memcpy(&recp->h_fs_uuid, &log->l_mp->m_sb.sb_uuid, sizeof(uuid_t)); +} + STATIC int xlog_write_log_records( - xlog_t *log, - int cycle, - int start_block, - int blocks, - int tail_cycle, - int tail_block) -{ - xlog_rec_header_t *recp; - int i, j; - int end_block = start_block + blocks; - int error = 0; - xfs_buf_t *bp; - char *buf; - int bufblks; + xlog_t *log, + int cycle, + int start_block, + int blocks, + int tail_cycle, + int tail_block) +{ + xfs_caddr_t offset; + xfs_buf_t *bp; + int balign, ealign; + int sectbb = XLOG_SECTOR_ROUNDUP_BBCOUNT(log, 1); + int end_block = start_block + blocks; + int bufblks; + int error = 0; + int i, j = 0; bufblks = 1 << ffs(blocks); - while (!(bp = xlog_get_bp(bufblks, log->l_mp))) { + while (!(bp = xlog_get_bp(log, bufblks))) { bufblks >>= 1; - if (!bufblks) + if (bufblks <= log->l_sectbb_log) return ENOMEM; } - buf = XFS_BUF_PTR(bp); - recp = (xlog_rec_header_t*)buf; - - memset(buf, 0, BBSIZE); - INT_SET(recp->h_magicno, ARCH_CONVERT, XLOG_HEADER_MAGIC_NUM); - INT_SET(recp->h_cycle, ARCH_CONVERT, cycle); - INT_SET(recp->h_version, ARCH_CONVERT, - XFS_SB_VERSION_HASLOGV2(&log->l_mp->m_sb) ? 2 : 1); - ASSIGN_ANY_LSN(recp->h_tail_lsn, tail_cycle, tail_block, ARCH_CONVERT); + /* We may need to do a read at the start to fill in part of + * the buffer in the starting sector not covered by the first + * write below. + */ + balign = XLOG_SECTOR_ROUNDDOWN_BLKNO(log, start_block); + if (balign != start_block) { + if ((error = xlog_bread(log, start_block, 1, bp))) { + xlog_put_bp(bp); + return error; + } + j = start_block - balign; + } for (i = start_block; i < end_block; i += bufblks) { - int bcount = min(bufblks, end_block - start_block); - /* with plenty of memory, we duplicate the block - * right through the buffer and modify each entry - */ - ASSIGN_ANY_LSN(recp->h_lsn, cycle, i, ARCH_CONVERT); - for (j = 1; j < bcount; j++) { - buf += BBSIZE; - recp = (xlog_rec_header_t*)buf; - memcpy(buf, XFS_BUF_PTR(bp), BBSIZE); - ASSIGN_ANY_LSN(recp->h_lsn, cycle, i+j, ARCH_CONVERT); - } - /* then write the whole lot out at once */ - error = xlog_bwrite(log, start_block, bcount, bp); - start_block += bcount; - buf = XFS_BUF_PTR(bp); - recp = (xlog_rec_header_t*)buf; + int bcount, endcount; + + bcount = min(bufblks, end_block - start_block); + endcount = bcount - j; + + /* We may need to do a read at the end to fill in part of + * the buffer in the final sector not covered by the write. + * If this is the same sector as the above read, skip it. + */ + ealign = XLOG_SECTOR_ROUNDDOWN_BLKNO(log, end_block); + if (j == 0 && (start_block + endcount > ealign)) { + offset = XFS_BUF_PTR(bp); + balign = BBTOB(ealign - start_block); + XFS_BUF_SET_PTR(bp, offset + balign, BBTOB(sectbb)); + if ((error = xlog_bread(log, ealign, sectbb, bp))) + break; + XFS_BUF_SET_PTR(bp, offset, bufblks); + } + + offset = xlog_align(log, start_block, endcount, bp); + for (; j < endcount; j++) { + xlog_add_record(log, offset, cycle, i+j, + tail_cycle, tail_block); + offset += BBSIZE; + } + error = xlog_bwrite(log, start_block, endcount, bp); + if (error) + break; + start_block += endcount; + j = 0; } xlog_put_bp(bp); - return error; } @@ -1244,10 +1331,11 @@ */ STATIC xlog_recover_t * -xlog_recover_find_tid(xlog_recover_t *q, - xlog_tid_t tid) +xlog_recover_find_tid( + xlog_recover_t *q, + xlog_tid_t tid) { - xlog_recover_t *p = q; + xlog_recover_t *p = q; while (p != NULL) { if (p->r_log_tid == tid) @@ -1255,42 +1343,43 @@ p = p->r_next; } return p; -} /* xlog_recover_find_tid */ - +} STATIC void -xlog_recover_put_hashq(xlog_recover_t **q, - xlog_recover_t *trans) +xlog_recover_put_hashq( + xlog_recover_t **q, + xlog_recover_t *trans) { trans->r_next = *q; *q = trans; -} /* xlog_recover_put_hashq */ - +} STATIC void -xlog_recover_add_item(xlog_recover_item_t **itemq) +xlog_recover_add_item( + xlog_recover_item_t **itemq) { - xlog_recover_item_t *item; + xlog_recover_item_t *item; item = kmem_zalloc(sizeof(xlog_recover_item_t), 0); xlog_recover_insert_item_backq(itemq, item); -} /* xlog_recover_add_item */ - +} STATIC int -xlog_recover_add_to_cont_trans(xlog_recover_t *trans, - xfs_caddr_t dp, - int len) +xlog_recover_add_to_cont_trans( + xlog_recover_t *trans, + xfs_caddr_t dp, + int len) { xlog_recover_item_t *item; - xfs_caddr_t ptr, old_ptr; + xfs_caddr_t ptr, old_ptr; int old_len; item = trans->r_itemq; if (item == 0) { /* finish copying rest of trans header */ xlog_recover_add_item(&trans->r_itemq); - ptr = (xfs_caddr_t)&trans->r_theader+sizeof(xfs_trans_header_t)-len; + ptr = (xfs_caddr_t) &trans->r_theader + + sizeof(xfs_trans_header_t) - len; memcpy(ptr, dp, len); /* d, s, l */ return 0; } @@ -1304,10 +1393,10 @@ item->ri_buf[item->ri_cnt-1].i_len += len; item->ri_buf[item->ri_cnt-1].i_addr = ptr; return 0; -} /* xlog_recover_add_to_cont_trans */ - +} -/* The next region to add is the start of a new region. It could be +/* + * The next region to add is the start of a new region. It could be * a whole region or it could be the first part of a new region. Because * of this, the assumption here is that the type and size fields of all * format structures fit into the first 32 bits of the structure. @@ -1320,13 +1409,14 @@ * will appear in the current log item. */ STATIC int -xlog_recover_add_to_trans(xlog_recover_t *trans, - xfs_caddr_t dp, - int len) -{ - xfs_inode_log_format_t *in_f; /* any will do */ - xlog_recover_item_t *item; - xfs_caddr_t ptr; +xlog_recover_add_to_trans( + xlog_recover_t *trans, + xfs_caddr_t dp, + int len) +{ + xfs_inode_log_format_t *in_f; /* any will do */ + xlog_recover_item_t *item; + xfs_caddr_t ptr; if (!len) return 0; @@ -1339,7 +1429,7 @@ return 0; } - ptr = kmem_alloc(len, 0); + ptr = kmem_alloc(len, KM_SLEEP); memcpy(ptr, dp, len); in_f = (xfs_inode_log_format_t *)ptr; @@ -1362,29 +1452,29 @@ item->ri_buf[item->ri_cnt].i_len = len; item->ri_cnt++; return 0; -} /* xlog_recover_add_to_trans */ - +} STATIC void -xlog_recover_new_tid(xlog_recover_t **q, - xlog_tid_t tid, - xfs_lsn_t lsn) +xlog_recover_new_tid( + xlog_recover_t **q, + xlog_tid_t tid, + xfs_lsn_t lsn) { - xlog_recover_t *trans; + xlog_recover_t *trans; - trans = kmem_zalloc(sizeof(xlog_recover_t), 0); + trans = kmem_zalloc(sizeof(xlog_recover_t), KM_SLEEP); trans->r_log_tid = tid; trans->r_lsn = lsn; xlog_recover_put_hashq(q, trans); -} /* xlog_recover_new_tid */ - +} STATIC int -xlog_recover_unlink_tid(xlog_recover_t **q, - xlog_recover_t *trans) +xlog_recover_unlink_tid( + xlog_recover_t **q, + xlog_recover_t *trans) { - xlog_recover_t *tp; - int found = 0; + xlog_recover_t *tp; + int found = 0; ASSERT(trans != 0); if (trans == *q) { @@ -1407,11 +1497,12 @@ tp->r_next = tp->r_next->r_next; } return 0; -} /* xlog_recover_unlink_tid */ +} STATIC void -xlog_recover_insert_item_backq(xlog_recover_item_t **q, - xlog_recover_item_t *item) +xlog_recover_insert_item_backq( + xlog_recover_item_t **q, + xlog_recover_item_t *item) { if (*q == 0) { item->ri_prev = item->ri_next = item; @@ -1422,55 +1513,53 @@ (*q)->ri_prev = item; item->ri_prev->ri_next = item; } -} /* xlog_recover_insert_item_backq */ +} STATIC void -xlog_recover_insert_item_frontq(xlog_recover_item_t **q, - xlog_recover_item_t *item) +xlog_recover_insert_item_frontq( + xlog_recover_item_t **q, + xlog_recover_item_t *item) { xlog_recover_insert_item_backq(q, item); *q = item; -} /* xlog_recover_insert_item_frontq */ +} STATIC int -xlog_recover_reorder_trans(xlog_t *log, - xlog_recover_t *trans) +xlog_recover_reorder_trans( + xlog_t *log, + xlog_recover_t *trans) { - xlog_recover_item_t *first_item, *itemq, *itemq_next; + xlog_recover_item_t *first_item, *itemq, *itemq_next; - first_item = itemq = trans->r_itemq; - trans->r_itemq = NULL; - do { - itemq_next = itemq->ri_next; - switch (ITEM_TYPE(itemq)) { - case XFS_LI_BUF: - case XFS_LI_6_1_BUF: - case XFS_LI_5_3_BUF: { - xlog_recover_insert_item_frontq(&trans->r_itemq, itemq); - break; - } - case XFS_LI_INODE: - case XFS_LI_6_1_INODE: - case XFS_LI_5_3_INODE: - case XFS_LI_DQUOT: - case XFS_LI_QUOTAOFF: - case XFS_LI_EFD: - case XFS_LI_EFI: { - xlog_recover_insert_item_backq(&trans->r_itemq, itemq); - break; - } - default: { - xlog_warn( + first_item = itemq = trans->r_itemq; + trans->r_itemq = NULL; + do { + itemq_next = itemq->ri_next; + switch (ITEM_TYPE(itemq)) { + case XFS_LI_BUF: + case XFS_LI_6_1_BUF: + case XFS_LI_5_3_BUF: + xlog_recover_insert_item_frontq(&trans->r_itemq, itemq); + break; + case XFS_LI_INODE: + case XFS_LI_6_1_INODE: + case XFS_LI_5_3_INODE: + case XFS_LI_DQUOT: + case XFS_LI_QUOTAOFF: + case XFS_LI_EFD: + case XFS_LI_EFI: + xlog_recover_insert_item_backq(&trans->r_itemq, itemq); + break; + default: + xlog_warn( "XFS: xlog_recover_reorder_trans: unrecognized type of log operation"); - ASSERT(0); - return XFS_ERROR(EIO); - } - } - itemq = itemq_next; - } while (first_item != itemq); - return 0; -} /* xlog_recover_reorder_trans */ - + ASSERT(0); + return XFS_ERROR(EIO); + } + itemq = itemq_next; + } while (first_item != itemq); + return 0; +} /* * Build up the table of buf cancel records so that we don't replay @@ -1485,17 +1574,18 @@ * record during the second pass. */ STATIC void -xlog_recover_do_buffer_pass1(xlog_t *log, - xfs_buf_log_format_t *buf_f) +xlog_recover_do_buffer_pass1( + xlog_t *log, + xfs_buf_log_format_t *buf_f) { xfs_buf_cancel_t *bcp; xfs_buf_cancel_t *nextp; xfs_buf_cancel_t *prevp; xfs_buf_cancel_t **bucket; xfs_buf_log_format_v1_t *obuf_f; - xfs_daddr_t blkno=0; - uint len=0; - ushort flags=0; + xfs_daddr_t blkno = 0; + uint len = 0; + ushort flags = 0; switch (buf_f->blf_type) { case XFS_LI_BUF: @@ -1515,9 +1605,8 @@ /* * If this isn't a cancel buffer item, then just return. */ - if (!(flags & XFS_BLI_CANCEL)) { + if (!(flags & XFS_BLI_CANCEL)) return; - } /* * Insert an xfs_buf_cancel record into the hash table of @@ -1531,8 +1620,8 @@ * the bucket. */ if (*bucket == NULL) { - bcp = (xfs_buf_cancel_t*)kmem_alloc(sizeof(xfs_buf_cancel_t), - KM_SLEEP); + bcp = (xfs_buf_cancel_t *)kmem_alloc(sizeof(xfs_buf_cancel_t), + KM_SLEEP); bcp->bc_blkno = blkno; bcp->bc_len = len; bcp->bc_refcount = 1; @@ -1557,8 +1646,8 @@ nextp = nextp->bc_next; } ASSERT(prevp != NULL); - bcp = (xfs_buf_cancel_t*)kmem_alloc(sizeof(xfs_buf_cancel_t), - KM_SLEEP); + bcp = (xfs_buf_cancel_t *)kmem_alloc(sizeof(xfs_buf_cancel_t), + KM_SLEEP); bcp->bc_blkno = blkno; bcp->bc_len = len; bcp->bc_refcount = 1; @@ -1580,17 +1669,17 @@ * made at that point. */ STATIC int -xlog_recover_do_buffer_pass2(xlog_t *log, - xfs_buf_log_format_t *buf_f) +xlog_recover_do_buffer_pass2( + xlog_t *log, + xfs_buf_log_format_t *buf_f) { xfs_buf_cancel_t *bcp; xfs_buf_cancel_t *prevp; xfs_buf_cancel_t **bucket; xfs_buf_log_format_v1_t *obuf_f; - xfs_daddr_t blkno=0; - ushort flags=0; - uint len=0; - + xfs_daddr_t blkno = 0; + ushort flags = 0; + uint len = 0; switch (buf_f->blf_type) { case XFS_LI_BUF: @@ -1667,7 +1756,6 @@ return 0; } - /* * Perform recovery for a buffer full of inodes. In these buffers, * the only data which should be recovered is that which corresponds @@ -1682,10 +1770,11 @@ * sent to xlog_recover_do_reg_buffer() below during recovery. */ STATIC int -xlog_recover_do_inode_buffer(xfs_mount_t *mp, - xlog_recover_item_t *item, - xfs_buf_t *bp, - xfs_buf_log_format_t *buf_f) +xlog_recover_do_inode_buffer( + xfs_mount_t *mp, + xlog_recover_item_t *item, + xfs_buf_t *bp, + xfs_buf_log_format_t *buf_f) { int i; int item_index; @@ -1698,8 +1787,8 @@ xfs_agino_t *logged_nextp; xfs_agino_t *buffer_nextp; xfs_buf_log_format_v1_t *obuf_f; - unsigned int *data_map=NULL; - unsigned int map_size=0; + unsigned int *data_map = NULL; + unsigned int map_size = 0; switch (buf_f->blf_type) { case XFS_LI_BUF: @@ -1790,7 +1879,7 @@ } return 0; -} /* xlog_recover_do_inode_buffer */ +} /* * Perform a 'normal' buffer recovery. Each logged region of the @@ -1800,17 +1889,18 @@ */ /*ARGSUSED*/ STATIC void -xlog_recover_do_reg_buffer(xfs_mount_t *mp, - xlog_recover_item_t *item, - xfs_buf_t *bp, - xfs_buf_log_format_t *buf_f) +xlog_recover_do_reg_buffer( + xfs_mount_t *mp, + xlog_recover_item_t *item, + xfs_buf_t *bp, + xfs_buf_log_format_t *buf_f) { int i; int bit; int nbits; xfs_buf_log_format_v1_t *obuf_f; - unsigned int *data_map=NULL; - unsigned int map_size=0; + unsigned int *data_map = NULL; + unsigned int map_size = 0; int error; switch (buf_f->blf_type) { @@ -1860,7 +1950,7 @@ /* Shouldn't be any more regions */ ASSERT(i == item->ri_total); -} /* xlog_recover_do_reg_buffer */ +} /* * Do some primitive error checking on ondisk dquot data structures. @@ -1991,7 +2081,7 @@ xfs_buf_t *bp, xfs_buf_log_format_t *buf_f) { - uint type; + uint type; /* * Filesystems are required to send in quota flags at mount time. @@ -2038,9 +2128,10 @@ * for more details on the implementation of the table of cancel records. */ STATIC int -xlog_recover_do_buffer_trans(xlog_t *log, - xlog_recover_item_t *item, - int pass) +xlog_recover_do_buffer_trans( + xlog_t *log, + xlog_recover_item_t *item, + int pass) { xfs_buf_log_format_t *buf_f; xfs_buf_log_format_v1_t *obuf_f; @@ -2075,19 +2166,19 @@ } } switch (buf_f->blf_type) { - case XFS_LI_BUF: + case XFS_LI_BUF: blkno = buf_f->blf_blkno; len = buf_f->blf_len; flags = buf_f->blf_flags; break; - case XFS_LI_6_1_BUF: - case XFS_LI_5_3_BUF: + case XFS_LI_6_1_BUF: + case XFS_LI_5_3_BUF: obuf_f = (xfs_buf_log_format_v1_t*)buf_f; blkno = obuf_f->blf_blkno; len = obuf_f->blf_len; flags = obuf_f->blf_flags; break; - default: + default: xfs_fs_cmn_err(CE_ALERT, log->l_mp, "xfs_log_recover: unknown buffer type 0x%x, dev 0x%x", buf_f->blf_type, log->l_dev); @@ -2152,12 +2243,13 @@ } return (error); -} /* xlog_recover_do_buffer_trans */ +} STATIC int -xlog_recover_do_inode_trans(xlog_t *log, - xlog_recover_item_t *item, - int pass) +xlog_recover_do_inode_trans( + xlog_t *log, + xlog_recover_item_t *item, + int pass) { xfs_inode_log_format_t *in_f; xfs_mount_t *mp; @@ -2377,7 +2469,6 @@ } } - write_inode_buffer: if (ITEM_TYPE(item) == XFS_LI_INODE) { ASSERT(XFS_BUF_FSPRIVATE(bp, void *) == NULL || @@ -2391,8 +2482,7 @@ } return (error); -} /* xlog_recover_do_inode_trans */ - +} /* * Recover QUOTAOFF records. We simply make a note of it in the xlog_t @@ -2400,11 +2490,12 @@ * of that type. */ STATIC int -xlog_recover_do_quotaoff_trans(xlog_t *log, - xlog_recover_item_t *item, - int pass) +xlog_recover_do_quotaoff_trans( + xlog_t *log, + xlog_recover_item_t *item, + int pass) { - xfs_qoff_logformat_t *qoff_f; + xfs_qoff_logformat_t *qoff_f; if (pass == XLOG_RECOVER_PASS2) { return (0); @@ -2425,14 +2516,14 @@ return (0); } - /* * Recover a dquot record */ STATIC int -xlog_recover_do_dquot_trans(xlog_t *log, - xlog_recover_item_t *item, - int pass) +xlog_recover_do_dquot_trans( + xlog_t *log, + xlog_recover_item_t *item, + int pass) { xfs_mount_t *mp; xfs_buf_t *bp; @@ -2516,7 +2607,7 @@ xfs_bdwrite(mp, bp); return (0); -} /* xlog_recover_do_dquot_trans */ +} /* * This routine is called to create an in-core extent free intent @@ -2526,10 +2617,11 @@ * LSN. */ STATIC void -xlog_recover_do_efi_trans(xlog_t *log, - xlog_recover_item_t *item, - xfs_lsn_t lsn, - int pass) +xlog_recover_do_efi_trans( + xlog_t *log, + xlog_recover_item_t *item, + xfs_lsn_t lsn, + int pass) { xfs_mount_t *mp; xfs_efi_log_item_t *efip; @@ -2558,7 +2650,7 @@ * xfs_trans_update_ail() drops the AIL lock. */ xfs_trans_update_ail(mp, (xfs_log_item_t *)efip, lsn, s); -} /* xlog_recover_do_efi_trans */ +} /* @@ -2570,13 +2662,14 @@ * AIL and free it. */ STATIC void -xlog_recover_do_efd_trans(xlog_t *log, - xlog_recover_item_t *item, - int pass) +xlog_recover_do_efd_trans( + xlog_t *log, + xlog_recover_item_t *item, + int pass) { xfs_mount_t *mp; xfs_efd_log_format_t *efd_formatp; - xfs_efi_log_item_t *efip=NULL; + xfs_efi_log_item_t *efip = NULL; xfs_log_item_t *lip; int gen; int nexts; @@ -2629,9 +2722,9 @@ ((nexts - 1) * sizeof(xfs_extent_t))); } else { kmem_zone_free(xfs_efi_zone, efip); + } } - } -} /* xlog_recover_do_efd_trans */ +} /* * Perform the transaction @@ -2640,12 +2733,13 @@ * EFIs and EFDs get queued up by adding entries into the AIL for them. */ STATIC int -xlog_recover_do_trans(xlog_t *log, - xlog_recover_t *trans, - int pass) +xlog_recover_do_trans( + xlog_t *log, + xlog_recover_t *trans, + int pass) { - int error = 0; - xlog_recover_item_t *item, *first_item; + int error = 0; + xlog_recover_item_t *item, *first_item; if ((error = xlog_recover_reorder_trans(log, trans))) return error; @@ -2695,8 +2789,7 @@ } while (first_item != item); return error; -} /* xlog_recover_do_trans */ - +} /* * Free up any resources allocated by the transaction @@ -2704,10 +2797,11 @@ * Remember that EFIs, EFDs, and IUNLINKs are handled later. */ STATIC void -xlog_recover_free_trans(xlog_recover_t *trans) +xlog_recover_free_trans( + xlog_recover_t *trans) { - xlog_recover_item_t *first_item, *item, *free_item; - int i; + xlog_recover_item_t *first_item, *item, *free_item; + int i; item = first_item = trans->r_itemq; do { @@ -2725,16 +2819,16 @@ } while (first_item != item); /* Free the transaction recover structure */ kmem_free(trans, sizeof(xlog_recover_t)); -} /* xlog_recover_free_trans */ - +} STATIC int -xlog_recover_commit_trans(xlog_t *log, - xlog_recover_t **q, - xlog_recover_t *trans, - int pass) +xlog_recover_commit_trans( + xlog_t *log, + xlog_recover_t **q, + xlog_recover_t *trans, + int pass) { - int error; + int error; if ((error = xlog_recover_unlink_tid(q, trans))) return error; @@ -2742,18 +2836,16 @@ return error; xlog_recover_free_trans(trans); /* no error */ return 0; -} /* xlog_recover_commit_trans */ - +} -/*ARGSUSED*/ STATIC int -xlog_recover_unmount_trans(xlog_recover_t *trans) +xlog_recover_unmount_trans( + xlog_recover_t *trans) { /* Do nothing now */ xlog_warn("XFS: xlog_recover_unmount_trans: Unmount LR"); - return( 0 ); -} /* xlog_recover_unmount_trans */ - + return 0; +} /* * There are two valid states of the r_state field. 0 indicates that the @@ -2765,97 +2857,101 @@ * NOTE: skip LRs with 0 data length. */ STATIC int -xlog_recover_process_data(xlog_t *log, - xlog_recover_t *rhash[], - xlog_rec_header_t *rhead, - xfs_caddr_t dp, - int pass) -{ - xfs_caddr_t lp = dp+INT_GET(rhead->h_len, ARCH_CONVERT); - int num_logops = INT_GET(rhead->h_num_logops, ARCH_CONVERT); - xlog_op_header_t *ohead; - xlog_recover_t *trans; - xlog_tid_t tid; - int error; - unsigned long hash; - uint flags; - - /* check the log format matches our own - else we can't recover */ - if (xlog_header_check_recover(log->l_mp, rhead)) - return (XFS_ERROR(EIO)); - - while ((dp < lp) && num_logops) { - ASSERT(dp + sizeof(xlog_op_header_t) <= lp); - ohead = (xlog_op_header_t *)dp; - dp += sizeof(xlog_op_header_t); - if (ohead->oh_clientid != XFS_TRANSACTION && - ohead->oh_clientid != XFS_LOG) { - xlog_warn("XFS: xlog_recover_process_data: bad clientid"); - ASSERT(0); - return (XFS_ERROR(EIO)); - } - tid = INT_GET(ohead->oh_tid, ARCH_CONVERT); - hash = XLOG_RHASH(tid); - trans = xlog_recover_find_tid(rhash[hash], tid); - if (trans == NULL) { /* not found; add new tid */ - if (ohead->oh_flags & XLOG_START_TRANS) - xlog_recover_new_tid(&rhash[hash], tid, INT_GET(rhead->h_lsn, ARCH_CONVERT)); - } else { - ASSERT(dp+INT_GET(ohead->oh_len, ARCH_CONVERT) <= lp); - flags = ohead->oh_flags & ~XLOG_END_TRANS; - if (flags & XLOG_WAS_CONT_TRANS) - flags &= ~XLOG_CONTINUE_TRANS; - switch (flags) { - case XLOG_COMMIT_TRANS: { - error = xlog_recover_commit_trans(log, &rhash[hash], - trans, pass); - break; - } - case XLOG_UNMOUNT_TRANS: { - error = xlog_recover_unmount_trans(trans); - break; - } - case XLOG_WAS_CONT_TRANS: { - error = xlog_recover_add_to_cont_trans(trans, dp, - INT_GET(ohead->oh_len, ARCH_CONVERT)); - break; - } - case XLOG_START_TRANS : { - xlog_warn("XFS: xlog_recover_process_data: bad transaction"); - ASSERT(0); - error = XFS_ERROR(EIO); - break; - } - case 0: - case XLOG_CONTINUE_TRANS: { - error = xlog_recover_add_to_trans(trans, dp, - INT_GET(ohead->oh_len, ARCH_CONVERT)); - break; +xlog_recover_process_data( + xlog_t *log, + xlog_recover_t *rhash[], + xlog_rec_header_t *rhead, + xfs_caddr_t dp, + int pass) +{ + xfs_caddr_t lp; + int num_logops; + xlog_op_header_t *ohead; + xlog_recover_t *trans; + xlog_tid_t tid; + int error; + unsigned long hash; + uint flags; + + lp = dp + INT_GET(rhead->h_len, ARCH_CONVERT); + num_logops = INT_GET(rhead->h_num_logops, ARCH_CONVERT); + + /* check the log format matches our own - else we can't recover */ + if (xlog_header_check_recover(log->l_mp, rhead)) + return (XFS_ERROR(EIO)); + + while ((dp < lp) && num_logops) { + ASSERT(dp + sizeof(xlog_op_header_t) <= lp); + ohead = (xlog_op_header_t *)dp; + dp += sizeof(xlog_op_header_t); + if (ohead->oh_clientid != XFS_TRANSACTION && + ohead->oh_clientid != XFS_LOG) { + xlog_warn( + "XFS: xlog_recover_process_data: bad clientid"); + ASSERT(0); + return (XFS_ERROR(EIO)); } - default: { - xlog_warn("XFS: xlog_recover_process_data: bad flag"); - ASSERT(0); - error = XFS_ERROR(EIO); - break; + tid = INT_GET(ohead->oh_tid, ARCH_CONVERT); + hash = XLOG_RHASH(tid); + trans = xlog_recover_find_tid(rhash[hash], tid); + if (trans == NULL) { /* not found; add new tid */ + if (ohead->oh_flags & XLOG_START_TRANS) + xlog_recover_new_tid(&rhash[hash], tid, + INT_GET(rhead->h_lsn, ARCH_CONVERT)); + } else { + ASSERT(dp+INT_GET(ohead->oh_len, ARCH_CONVERT) <= lp); + flags = ohead->oh_flags & ~XLOG_END_TRANS; + if (flags & XLOG_WAS_CONT_TRANS) + flags &= ~XLOG_CONTINUE_TRANS; + switch (flags) { + case XLOG_COMMIT_TRANS: + error = xlog_recover_commit_trans(log, + &rhash[hash], trans, pass); + break; + case XLOG_UNMOUNT_TRANS: + error = xlog_recover_unmount_trans(trans); + break; + case XLOG_WAS_CONT_TRANS: + error = xlog_recover_add_to_cont_trans(trans, + dp, INT_GET(ohead->oh_len, + ARCH_CONVERT)); + break; + case XLOG_START_TRANS: + xlog_warn( + "XFS: xlog_recover_process_data: bad transaction"); + ASSERT(0); + error = XFS_ERROR(EIO); + break; + case 0: + case XLOG_CONTINUE_TRANS: + error = xlog_recover_add_to_trans(trans, + dp, INT_GET(ohead->oh_len, + ARCH_CONVERT)); + break; + default: + xlog_warn( + "XFS: xlog_recover_process_data: bad flag"); + ASSERT(0); + error = XFS_ERROR(EIO); + break; + } + if (error) + return error; } - } /* switch */ - if (error) - return error; - } /* if */ - dp += INT_GET(ohead->oh_len, ARCH_CONVERT); - num_logops--; - } - return( 0 ); -} /* xlog_recover_process_data */ - + dp += INT_GET(ohead->oh_len, ARCH_CONVERT); + num_logops--; + } + return 0; +} /* * Process an extent free intent item that was recovered from * the log. We need to free the extents that it describes. */ STATIC void -xlog_recover_process_efi(xfs_mount_t *mp, - xfs_efi_log_item_t *efip) +xlog_recover_process_efi( + xfs_mount_t *mp, + xfs_efi_log_item_t *efip) { xfs_efd_log_item_t *efdp; xfs_trans_t *tp; @@ -2900,8 +2996,7 @@ efip->efi_flags |= XFS_EFI_RECOVERED; xfs_trans_commit(tp, 0, NULL); -} /* xlog_recover_process_efi */ - +} /* * Verify that once we've encountered something other than an EFI @@ -2909,13 +3004,13 @@ */ #if defined(DEBUG) STATIC void -xlog_recover_check_ail(xfs_mount_t *mp, - xfs_log_item_t *lip, - int gen) +xlog_recover_check_ail( + xfs_mount_t *mp, + xfs_log_item_t *lip, + int gen) { - int orig_gen; + int orig_gen = gen; - orig_gen = gen; do { ASSERT(lip->li_type != XFS_LI_EFI); lip = xfs_trans_next_ail(mp, lip, &gen, NULL); @@ -2930,7 +3025,6 @@ } #endif /* DEBUG */ - /* * When this is called, all of the EFIs which did not have * corresponding EFDs should be in the AIL. What we do now @@ -2950,7 +3044,8 @@ * we see something other than an EFI in the AIL. */ STATIC void -xlog_recover_process_efis(xlog_t *log) +xlog_recover_process_efis( + xlog_t *log) { xfs_log_item_t *lip; xfs_efi_log_item_t *efip; @@ -2986,8 +3081,7 @@ lip = xfs_trans_next_ail(mp, lip, &gen, NULL); } AIL_UNLOCK(mp, s); -} /* xlog_recover_process_efis */ - +} /* * This routine performs a transaction to null out a bad inode pointer @@ -3030,8 +3124,7 @@ (offset + sizeof(xfs_agino_t) - 1)); (void) xfs_trans_commit(tp, 0, NULL); -} /* xlog_recover_clear_agi_bucket */ - +} /* * xlog_iunlink_recover @@ -3046,7 +3139,8 @@ * atomic. */ void -xlog_recover_process_iunlinks(xlog_t *log) +xlog_recover_process_iunlinks( + xlog_t *log) { xfs_mount_t *mp; xfs_agnumber_t agno; @@ -3188,40 +3282,47 @@ } mp->m_dmevmask = mp_dmevmask; +} -} /* xlog_recover_process_iunlinks */ - - -/* - * Stamp cycle number in every block - * - * This routine is also called in xfs_log.c - */ -/*ARGSUSED*/ -void -xlog_pack_data(xlog_t *log, xlog_in_core_t *iclog) -{ - int i, j, k; - int size = iclog->ic_offset + iclog->ic_roundoff; - xfs_caddr_t dp; - union ich { - xlog_rec_ext_header_t hic_xheader; - char hic_sector[XLOG_HEADER_SIZE]; - } *xhdr; - uint cycle_lsn; #ifdef DEBUG - uint *up; - uint chksum = 0; +STATIC void +xlog_pack_data_checksum( + xlog_t *log, + xlog_in_core_t *iclog, + int size) +{ + int i; + uint *up; + uint chksum = 0; up = (uint *)iclog->ic_datap; /* divide length by 4 to get # words */ - for (i=0; i> 2; i++) { + for (i = 0; i < (size >> 2); i++) { chksum ^= INT_GET(*up, ARCH_CONVERT); up++; } INT_SET(iclog->ic_header.h_chksum, ARCH_CONVERT, chksum); -#endif /* DEBUG */ +} +#else +#define xlog_pack_data_checksum(log, iclog, size) +#endif + +/* + * Stamp cycle number in every block + */ +void +xlog_pack_data( + xlog_t *log, + xlog_in_core_t *iclog) +{ + int i, j, k; + int size = iclog->ic_offset + iclog->ic_roundoff; + uint cycle_lsn; + xfs_caddr_t dp; + xlog_in_core_2_t *xhdr; + + xlog_pack_data_checksum(log, iclog, size); cycle_lsn = CYCLE_LSN_NOCONV(iclog->ic_header.h_lsn, ARCH_CONVERT); @@ -3234,7 +3335,7 @@ } if (XFS_SB_VERSION_HASLOGV2(&log->l_mp->m_sb)) { - xhdr = (union ich*)&iclog->ic_header; + xhdr = (xlog_in_core_2_t *)&iclog->ic_header; for ( ; i < BTOBB(size); i++) { j = i / (XLOG_HEADER_CYCLE_SIZE / BBSIZE); k = i % (XLOG_HEADER_CYCLE_SIZE / BBSIZE); @@ -3247,45 +3348,18 @@ xhdr[i].hic_xheader.xh_cycle = cycle_lsn; } } - -} /* xlog_pack_data */ - - -/*ARGSUSED*/ -STATIC void -xlog_unpack_data(xlog_rec_header_t *rhead, - xfs_caddr_t dp, - xlog_t *log) -{ - int i, j, k; - union ich { - xlog_rec_header_t hic_header; - xlog_rec_ext_header_t hic_xheader; - char hic_sector[XLOG_HEADER_SIZE]; - } *xhdr; +} #if defined(DEBUG) && defined(XFS_LOUD_RECOVERY) - uint *up = (uint *)dp; - uint chksum = 0; -#endif - - for (i=0; i < BTOBB(INT_GET(rhead->h_len, ARCH_CONVERT)) && - i < (XLOG_HEADER_CYCLE_SIZE / BBSIZE); i++) { - *(uint *)dp = *(uint *)&rhead->h_cycle_data[i]; - dp += BBSIZE; - } - - if (XFS_SB_VERSION_HASLOGV2(&log->l_mp->m_sb)) { - xhdr = (union ich*)rhead; - for ( ; i < BTOBB(INT_GET(rhead->h_len, ARCH_CONVERT)); i++) { - j = i / (XLOG_HEADER_CYCLE_SIZE / BBSIZE); - k = i % (XLOG_HEADER_CYCLE_SIZE / BBSIZE); - *(uint *)dp = xhdr[j].hic_xheader.xh_cycle_data[k]; - dp += BBSIZE; - } - } +STATIC void +xlog_unpack_data_checksum( + xlog_rec_header_t *rhead, + xfs_caddr_t dp, + xlog_t *log) +{ + uint *up = (uint *)dp; + uint chksum = 0; -#if defined(DEBUG) && defined(XFS_LOUD_RECOVERY) /* divide length by 4 to get # words */ for (i=0; i < INT_GET(rhead->h_len, ARCH_CONVERT) >> 2; i++) { chksum ^= INT_GET(*up, ARCH_CONVERT); @@ -3306,9 +3380,77 @@ log->l_flags |= XLOG_CHKSUM_MISMATCH; } } -#endif /* DEBUG && XFS_LOUD_RECOVERY */ -} /* xlog_unpack_data */ +} +#else +#define xlog_unpack_data_checksum(rhead, dp, log) +#endif + +STATIC void +xlog_unpack_data( + xlog_rec_header_t *rhead, + xfs_caddr_t dp, + xlog_t *log) +{ + int i, j, k; + xlog_in_core_2_t *xhdr; + + for (i = 0; i < BTOBB(INT_GET(rhead->h_len, ARCH_CONVERT)) && + i < (XLOG_HEADER_CYCLE_SIZE / BBSIZE); i++) { + *(uint *)dp = *(uint *)&rhead->h_cycle_data[i]; + dp += BBSIZE; + } + + if (XFS_SB_VERSION_HASLOGV2(&log->l_mp->m_sb)) { + xhdr = (xlog_in_core_2_t *)rhead; + for ( ; i < BTOBB(INT_GET(rhead->h_len, ARCH_CONVERT)); i++) { + j = i / (XLOG_HEADER_CYCLE_SIZE / BBSIZE); + k = i % (XLOG_HEADER_CYCLE_SIZE / BBSIZE); + *(uint *)dp = xhdr[j].hic_xheader.xh_cycle_data[k]; + dp += BBSIZE; + } + } + + xlog_unpack_data_checksum(rhead, dp, log); +} + +STATIC int +xlog_valid_rec_header( + xlog_t *log, + xlog_rec_header_t *rhead, + xfs_daddr_t blkno) +{ + int bblks; + + if (unlikely( + (INT_GET(rhead->h_magicno, ARCH_CONVERT) != + XLOG_HEADER_MAGIC_NUM))) { + XFS_ERROR_REPORT("xlog_valid_rec_header(1)", + XFS_ERRLEVEL_LOW, log->l_mp); + return XFS_ERROR(EFSCORRUPTED); + } + if (unlikely( + (INT_ISZERO(rhead->h_version, ARCH_CONVERT) || + (INT_GET(rhead->h_version, ARCH_CONVERT) & + (~XLOG_VERSION_OKBITS)) != 0))) { + xlog_warn("XFS: %s: unrecognised log version (%d).", + __FUNCTION__, INT_GET(rhead->h_version, ARCH_CONVERT)); + return XFS_ERROR(EIO); + } + /* LR body must have data or it wouldn't have been written */ + bblks = INT_GET(rhead->h_len, ARCH_CONVERT); + if (unlikely( bblks <= 0 || bblks > INT_MAX )) { + XFS_ERROR_REPORT("xlog_valid_rec_header(2)", + XFS_ERRLEVEL_LOW, log->l_mp); + return XFS_ERROR(EFSCORRUPTED); + } + if (unlikely( blkno > log->l_logBBsize || blkno > INT_MAX )) { + XFS_ERROR_REPORT("xlog_valid_rec_header(3)", + XFS_ERRLEVEL_LOW, log->l_mp); + return XFS_ERROR(EFSCORRUPTED); + } + return 0; +} /* * Read the log from tail to head and process the log records found. @@ -3319,223 +3461,246 @@ * here. */ STATIC int -xlog_do_recovery_pass(xlog_t *log, - xfs_daddr_t head_blk, - xfs_daddr_t tail_blk, - int pass) -{ - xlog_rec_header_t *rhead; - xfs_daddr_t blk_no; - xfs_caddr_t bufaddr; - xfs_buf_t *hbp, *dbp; - int error, h_size; - int bblks, split_bblks; - int hblks, split_hblks, wrapped_hblks; - xlog_recover_t *rhash[XLOG_RHASH_SIZE]; - - error = 0; - - - /* - * Read the header of the tail block and get the iclog buffer size from - * h_size. Use this to tell how many sectors make up the log header. - */ - if (XFS_SB_VERSION_HASLOGV2(&log->l_mp->m_sb)) { - /* - * When using variable length iclogs, read first sector of iclog - * header and extract the header size from it. Get a new hbp that - * is the correct size. - */ - hbp = xlog_get_bp(1, log->l_mp); - if (!hbp) - return ENOMEM; - if ((error = xlog_bread(log, tail_blk, 1, hbp))) - goto bread_err1; - rhead = (xlog_rec_header_t *)XFS_BUF_PTR(hbp); - ASSERT(INT_GET(rhead->h_magicno, ARCH_CONVERT) == - XLOG_HEADER_MAGIC_NUM); - if ((INT_GET(rhead->h_version, ARCH_CONVERT) & (~XLOG_VERSION_OKBITS)) != 0) { - xlog_warn("XFS: xlog_do_recovery_pass: unrecognised log version number."); - error = XFS_ERROR(EIO); - goto bread_err1; - } - h_size = INT_GET(rhead->h_size, ARCH_CONVERT); +xlog_do_recovery_pass( + xlog_t *log, + xfs_daddr_t head_blk, + xfs_daddr_t tail_blk, + int pass) +{ + xlog_rec_header_t *rhead; + xfs_daddr_t blk_no; + xfs_caddr_t bufaddr, offset; + xfs_buf_t *hbp, *dbp; + int error = 0, h_size; + int bblks, split_bblks; + int hblks, split_hblks, wrapped_hblks; + xlog_recover_t *rhash[XLOG_RHASH_SIZE]; + + ASSERT(head_blk != tail_blk); - if ((INT_GET(rhead->h_version, ARCH_CONVERT) & XLOG_VERSION_2) && - (h_size > XLOG_HEADER_CYCLE_SIZE)) { - hblks = h_size / XLOG_HEADER_CYCLE_SIZE; - if (h_size % XLOG_HEADER_CYCLE_SIZE) - hblks++; - xlog_put_bp(hbp); - hbp = xlog_get_bp(hblks, log->l_mp); + /* + * Read the header of the tail block and get the iclog buffer size from + * h_size. Use this to tell how many sectors make up the log header. + */ + if (XFS_SB_VERSION_HASLOGV2(&log->l_mp->m_sb)) { + /* + * When using variable length iclogs, read first sector of + * iclog header and extract the header size from it. Get a + * new hbp that is the correct size. + */ + hbp = xlog_get_bp(log, 1); + if (!hbp) + return ENOMEM; + if ((error = xlog_bread(log, tail_blk, 1, hbp))) + goto bread_err1; + offset = xlog_align(log, tail_blk, 1, hbp); + rhead = (xlog_rec_header_t *)offset; + error = xlog_valid_rec_header(log, rhead, tail_blk); + if (error) + goto bread_err1; + h_size = INT_GET(rhead->h_size, ARCH_CONVERT); + if ((INT_GET(rhead->h_version, ARCH_CONVERT) + & XLOG_VERSION_2) && + (h_size > XLOG_HEADER_CYCLE_SIZE)) { + hblks = h_size / XLOG_HEADER_CYCLE_SIZE; + if (h_size % XLOG_HEADER_CYCLE_SIZE) + hblks++; + xlog_put_bp(hbp); + hbp = xlog_get_bp(log, hblks); + } else { + hblks = 1; + } } else { - hblks=1; + ASSERT(log->l_sectbb_log == 0); + hblks = 1; + hbp = xlog_get_bp(log, 1); + h_size = XLOG_BIG_RECORD_BSIZE; } - } else { - hblks=1; - hbp = xlog_get_bp(1, log->l_mp); - h_size = XLOG_BIG_RECORD_BSIZE; - } - - if (!hbp) - return ENOMEM; - dbp = xlog_get_bp(BTOBB(h_size),log->l_mp); - if (!dbp) { - xlog_put_bp(hbp); - return ENOMEM; - } - - memset(rhash, 0, sizeof(rhash)); - if (tail_blk <= head_blk) { - for (blk_no = tail_blk; blk_no < head_blk; ) { - if ((error = xlog_bread(log, blk_no, hblks, hbp))) - goto bread_err2; - rhead = (xlog_rec_header_t *)XFS_BUF_PTR(hbp); - ASSERT(INT_GET(rhead->h_magicno, ARCH_CONVERT) == XLOG_HEADER_MAGIC_NUM); - ASSERT(BTOBB(INT_GET(rhead->h_len, ARCH_CONVERT) <= INT_MAX)); - bblks = (int) BTOBB(INT_GET(rhead->h_len, ARCH_CONVERT)); /* blocks in data section */ - - if (unlikely((INT_GET(rhead->h_magicno, ARCH_CONVERT) != XLOG_HEADER_MAGIC_NUM) || - (BTOBB(INT_GET(rhead->h_len, ARCH_CONVERT) > INT_MAX)) || - (bblks <= 0) || - (blk_no > log->l_logBBsize))) { - XFS_ERROR_REPORT("xlog_do_recovery_pass(1)", - XFS_ERRLEVEL_LOW, log->l_mp); - error = EFSCORRUPTED; - goto bread_err2; - } - if ((INT_GET(rhead->h_version, ARCH_CONVERT) & (~XLOG_VERSION_OKBITS)) != 0) { - xlog_warn("XFS: xlog_do_recovery_pass: unrecognised log version number."); - error = XFS_ERROR(EIO); - goto bread_err2; - } - bblks = (int) BTOBB(INT_GET(rhead->h_len, ARCH_CONVERT)); /* blocks in data section */ - if (bblks > 0) { - if ((error = xlog_bread(log, blk_no+hblks, bblks, dbp))) - goto bread_err2; - xlog_unpack_data(rhead, XFS_BUF_PTR(dbp), log); - if ((error = xlog_recover_process_data(log, rhash, - rhead, XFS_BUF_PTR(dbp), - pass))) - goto bread_err2; - } - blk_no += (bblks+hblks); + if (!hbp) + return ENOMEM; + dbp = xlog_get_bp(log, BTOBB(h_size)); + if (!dbp) { + xlog_put_bp(hbp); + return ENOMEM; } - } else { - /* - * Perform recovery around the end of the physical log. When the head - * is not on the same cycle number as the tail, we can't do a sequential - * recovery as above. - */ - blk_no = tail_blk; - while (blk_no < log->l_logBBsize) { - /* - * Check for header wrapping around physical end-of-log - */ - wrapped_hblks = 0; - if (blk_no+hblks <= log->l_logBBsize) { - /* Read header in one read */ - if ((error = xlog_bread(log, blk_no, hblks, hbp))) - goto bread_err2; - } else { - /* This log record is split across physical end of log */ - split_hblks = 0; - if (blk_no != log->l_logBBsize) { - /* some data is before physical end of log */ - ASSERT(blk_no <= INT_MAX); - split_hblks = log->l_logBBsize - (int)blk_no; - ASSERT(split_hblks > 0); - if ((error = xlog_bread(log, blk_no, split_hblks, hbp))) - goto bread_err2; - } - bufaddr = XFS_BUF_PTR(hbp); - XFS_BUF_SET_PTR(hbp, bufaddr + BBTOB(split_hblks), - BBTOB(hblks - split_hblks)); - wrapped_hblks = hblks - split_hblks; - if ((error = xlog_bread(log, 0, wrapped_hblks, hbp))) - goto bread_err2; - XFS_BUF_SET_PTR(hbp, bufaddr, hblks); - } - rhead = (xlog_rec_header_t *)XFS_BUF_PTR(hbp); - ASSERT(INT_GET(rhead->h_magicno, ARCH_CONVERT) == XLOG_HEADER_MAGIC_NUM); - ASSERT(BTOBB(INT_GET(rhead->h_len, ARCH_CONVERT) <= INT_MAX)); - bblks = (int) BTOBB(INT_GET(rhead->h_len, ARCH_CONVERT)); - - /* LR body must have data or it wouldn't have been written */ - ASSERT(bblks > 0); - blk_no += hblks; /* successfully read header */ - - if (unlikely((INT_GET(rhead->h_magicno, ARCH_CONVERT) != XLOG_HEADER_MAGIC_NUM) || - (BTOBB(INT_GET(rhead->h_len, ARCH_CONVERT) > INT_MAX)) || - (bblks <= 0))) { - XFS_ERROR_REPORT("xlog_do_recovery_pass(2)", - XFS_ERRLEVEL_LOW, log->l_mp); - error = EFSCORRUPTED; - goto bread_err2; - } - /* Read in data for log record */ - if (blk_no+bblks <= log->l_logBBsize) { - if ((error = xlog_bread(log, blk_no, bblks, dbp))) - goto bread_err2; - } else { - /* This log record is split across physical end of log */ - split_bblks = 0; - if (blk_no != log->l_logBBsize) { - - /* some data is before physical end of log */ - ASSERT(blk_no <= INT_MAX); - split_bblks = log->l_logBBsize - (int)blk_no; - ASSERT(split_bblks > 0); - if ((error = xlog_bread(log, blk_no, split_bblks, dbp))) - goto bread_err2; - } - bufaddr = XFS_BUF_PTR(dbp); - XFS_BUF_SET_PTR(dbp, bufaddr + BBTOB(split_bblks), - BBTOB(bblks - split_bblks)); - if ((error = xlog_bread(log, wrapped_hblks, - bblks - split_bblks, dbp))) - goto bread_err2; - XFS_BUF_SET_PTR(dbp, bufaddr, XLOG_BIG_RECORD_BSIZE); - } - xlog_unpack_data(rhead, XFS_BUF_PTR(dbp), log); - if ((error = xlog_recover_process_data(log, rhash, - rhead, XFS_BUF_PTR(dbp), - pass))) - goto bread_err2; - blk_no += bblks; - } - - ASSERT(blk_no >= log->l_logBBsize); - blk_no -= log->l_logBBsize; - - /* read first part of physical log */ - while (blk_no < head_blk) { - if ((error = xlog_bread(log, blk_no, hblks, hbp))) - goto bread_err2; - rhead = (xlog_rec_header_t *)XFS_BUF_PTR(hbp); - ASSERT(INT_GET(rhead->h_magicno, ARCH_CONVERT) == XLOG_HEADER_MAGIC_NUM); - ASSERT(BTOBB(INT_GET(rhead->h_len, ARCH_CONVERT) <= INT_MAX)); - bblks = (int) BTOBB(INT_GET(rhead->h_len, ARCH_CONVERT)); - ASSERT(bblks > 0); - if ((error = xlog_bread(log, blk_no+hblks, bblks, dbp))) - goto bread_err2; - xlog_unpack_data(rhead, XFS_BUF_PTR(dbp), log); - if ((error = xlog_recover_process_data(log, rhash, - rhead, XFS_BUF_PTR(dbp), - pass))) - goto bread_err2; - blk_no += (bblks+hblks); - } - } - -bread_err2: - xlog_put_bp(dbp); -bread_err1: - xlog_put_bp(hbp); + memset(rhash, 0, sizeof(rhash)); + if (tail_blk <= head_blk) { + for (blk_no = tail_blk; blk_no < head_blk; ) { + if ((error = xlog_bread(log, blk_no, hblks, hbp))) + goto bread_err2; + offset = xlog_align(log, blk_no, hblks, hbp); + rhead = (xlog_rec_header_t *)offset; + error = xlog_valid_rec_header(log, rhead, blk_no); + if (error) + goto bread_err2; + + /* blocks in data section */ + bblks = (int)BTOBB(INT_GET(rhead->h_len, ARCH_CONVERT)); + error = xlog_bread(log, blk_no + hblks, bblks, dbp); + if (error) + goto bread_err2; + offset = xlog_align(log, blk_no + hblks, bblks, dbp); + xlog_unpack_data(rhead, offset, log); + if ((error = xlog_recover_process_data(log, + rhash, rhead, offset, pass))) + goto bread_err2; + blk_no += bblks + hblks; + } + } else { + /* + * Perform recovery around the end of the physical log. + * When the head is not on the same cycle number as the tail, + * we can't do a sequential recovery as above. + */ + blk_no = tail_blk; + while (blk_no < log->l_logBBsize) { + /* + * Check for header wrapping around physical end-of-log + */ + offset = NULL; + split_hblks = 0; + wrapped_hblks = 0; + if (blk_no + hblks <= log->l_logBBsize) { + /* Read header in one read */ + error = xlog_bread(log, blk_no, hblks, hbp); + if (error) + goto bread_err2; + offset = xlog_align(log, blk_no, hblks, hbp); + } else { + /* This LR is split across physical log end */ + if (blk_no != log->l_logBBsize) { + /* some data before physical log end */ + ASSERT(blk_no <= INT_MAX); + split_hblks = log->l_logBBsize - (int)blk_no; + ASSERT(split_hblks > 0); + if ((error = xlog_bread(log, blk_no, + split_hblks, hbp))) + goto bread_err2; + offset = xlog_align(log, blk_no, + split_hblks, hbp); + } + /* + * Note: this black magic still works with + * large sector sizes (non-512) only because: + * - we increased the buffer size originally + * by 1 sector giving us enough extra space + * for the second read; + * - the log start is guaranteed to be sector + * aligned; + * - we read the log end (LR header start) + * _first_, then the log start (LR header end) + * - order is important. + */ + bufaddr = XFS_BUF_PTR(hbp); + XFS_BUF_SET_PTR(hbp, + bufaddr + BBTOB(split_hblks), + BBTOB(hblks - split_hblks)); + wrapped_hblks = hblks - split_hblks; + error = xlog_bread(log, 0, wrapped_hblks, hbp); + if (error) + goto bread_err2; + XFS_BUF_SET_PTR(hbp, bufaddr, hblks); + if (!offset) + offset = xlog_align(log, 0, + wrapped_hblks, hbp); + } + rhead = (xlog_rec_header_t *)offset; + error = xlog_valid_rec_header(log, rhead, + split_hblks ? blk_no : 0); + if (error) + goto bread_err2; + + bblks = (int)BTOBB(INT_GET(rhead->h_len, ARCH_CONVERT)); + blk_no += hblks; + + /* Read in data for log record */ + if (blk_no + bblks <= log->l_logBBsize) { + error = xlog_bread(log, blk_no, bblks, dbp); + if (error) + goto bread_err2; + offset = xlog_align(log, blk_no, bblks, dbp); + } else { + /* This log record is split across the + * physical end of log */ + offset = NULL; + split_bblks = 0; + if (blk_no != log->l_logBBsize) { + /* some data is before the physical + * end of log */ + ASSERT(!wrapped_hblks); + ASSERT(blk_no <= INT_MAX); + split_bblks = + log->l_logBBsize - (int)blk_no; + ASSERT(split_bblks > 0); + if ((error = xlog_bread(log, blk_no, + split_bblks, dbp))) + goto bread_err2; + offset = xlog_align(log, blk_no, + split_bblks, dbp); + } + /* + * Note: this black magic still works with + * large sector sizes (non-512) only because: + * - we increased the buffer size originally + * by 1 sector giving us enough extra space + * for the second read; + * - the log start is guaranteed to be sector + * aligned; + * - we read the log end (LR header start) + * _first_, then the log start (LR header end) + * - order is important. + */ + bufaddr = XFS_BUF_PTR(dbp); + XFS_BUF_SET_PTR(dbp, + bufaddr + BBTOB(split_bblks), + BBTOB(bblks - split_bblks)); + if ((error = xlog_bread(log, wrapped_hblks, + bblks - split_bblks, dbp))) + goto bread_err2; + XFS_BUF_SET_PTR(dbp, bufaddr, + XLOG_BIG_RECORD_BSIZE); + if (!offset) + offset = xlog_align(log, wrapped_hblks, + bblks - split_bblks, dbp); + } + xlog_unpack_data(rhead, offset, log); + if ((error = xlog_recover_process_data(log, rhash, + rhead, offset, pass))) + goto bread_err2; + blk_no += bblks; + } + + ASSERT(blk_no >= log->l_logBBsize); + blk_no -= log->l_logBBsize; + + /* read first part of physical log */ + while (blk_no < head_blk) { + if ((error = xlog_bread(log, blk_no, hblks, hbp))) + goto bread_err2; + offset = xlog_align(log, blk_no, hblks, hbp); + rhead = (xlog_rec_header_t *)offset; + error = xlog_valid_rec_header(log, rhead, blk_no); + if (error) + goto bread_err2; + bblks = (int)BTOBB(INT_GET(rhead->h_len, ARCH_CONVERT)); + if ((error = xlog_bread(log, blk_no+hblks, bblks, dbp))) + goto bread_err2; + offset = xlog_align(log, blk_no+hblks, bblks, dbp); + xlog_unpack_data(rhead, offset, log); + if ((error = xlog_recover_process_data(log, rhash, + rhead, offset, pass))) + goto bread_err2; + blk_no += bblks + hblks; + } + } - return error; + bread_err2: + xlog_put_bp(dbp); + bread_err1: + xlog_put_bp(hbp); + return error; } /* @@ -3552,14 +3717,14 @@ * the log recovery has been completed. */ STATIC int -xlog_do_log_recovery(xlog_t *log, - xfs_daddr_t head_blk, - xfs_daddr_t tail_blk) +xlog_do_log_recovery( + xlog_t *log, + xfs_daddr_t head_blk, + xfs_daddr_t tail_blk) { int error; -#ifdef DEBUG - int i; -#endif + + ASSERT(head_blk != tail_blk); /* * First do a pass to find all of the cancelled buf log items. @@ -3583,11 +3748,15 @@ */ error = xlog_do_recovery_pass(log, head_blk, tail_blk, XLOG_RECOVER_PASS2); -#ifdef DEBUG - for (i = 0; i < XLOG_BC_TABLE_SIZE; i++) { - ASSERT(log->l_buf_cancel_table[i] == NULL); +#ifdef DEBUG + { + int i; + + for (i = 0; i < XLOG_BC_TABLE_SIZE; i++) + ASSERT(log->l_buf_cancel_table[i] == NULL); } #endif /* DEBUG */ + kmem_free(log->l_buf_cancel_table, XLOG_BC_TABLE_SIZE * sizeof(xfs_buf_cancel_t*)); log->l_buf_cancel_table = NULL; @@ -3599,9 +3768,10 @@ * Do the actual recovery */ STATIC int -xlog_do_recover(xlog_t *log, - xfs_daddr_t head_blk, - xfs_daddr_t tail_blk) +xlog_do_recover( + xlog_t *log, + xfs_daddr_t head_blk, + xfs_daddr_t tail_blk) { int error; xfs_buf_t *bp; @@ -3663,7 +3833,7 @@ /* Normal transactions can now occur */ log->l_flags &= ~XLOG_ACTIVE_RECOVERY; return 0; -} /* xlog_do_recover */ +} /* * Perform recovery and re-initialize some log variables in xlog_find_tail. @@ -3671,22 +3841,18 @@ * Return error or zero. */ int -xlog_recover(xlog_t *log, int readonly) +xlog_recover( + xlog_t *log, + int readonly) { - xfs_daddr_t head_blk, tail_blk; - int error; + xfs_daddr_t head_blk, tail_blk; + int error; /* find the tail of the log */ - if ((error = xlog_find_tail(log, &head_blk, &tail_blk, readonly))) return error; if (tail_blk != head_blk) { -#ifndef __KERNEL__ - extern xfs_daddr_t HEAD_BLK, TAIL_BLK; - head_blk = HEAD_BLK; - tail_blk = TAIL_BLK; -#endif /* There used to be a comment here: * * disallow recovery on read-only mounts. note -- mount @@ -3698,36 +3864,21 @@ * under the vfs layer, so we can get away with it unless * the device itself is read-only, in which case we fail. */ -#ifdef __KERNEL__ if ((error = xfs_dev_is_read_only(log->l_mp, "recovery required"))) { return error; } -#else - if (readonly) { - return ENOSPC; - } -#endif -#ifdef __KERNEL__ -#if defined(DEBUG) && defined(XFS_LOUD_RECOVERY) cmn_err(CE_NOTE, "Starting XFS recovery on filesystem: %s (dev: %d/%d)", log->l_mp->m_fsname, MAJOR(log->l_dev), MINOR(log->l_dev)); -#else - cmn_err(CE_NOTE, - "!Starting XFS recovery on filesystem: %s (dev: %d/%d)", - log->l_mp->m_fsname, MAJOR(log->l_dev), - MINOR(log->l_dev)); -#endif -#endif + error = xlog_do_recover(log, head_blk, tail_blk); log->l_flags |= XLOG_RECOVERY_NEEDED; } return error; -} /* xlog_recover */ - +} /* * In the first part of recovery we replay inodes and buffers and build @@ -3739,7 +3890,9 @@ * in the real-time portion of the file system. */ int -xlog_recover_finish(xlog_t *log, int mfsi_flags) +xlog_recover_finish( + xlog_t *log, + int mfsi_flags) { /* * Now we're ready to do the transactions needed for the @@ -3761,23 +3914,16 @@ (XFS_LOG_FORCE | XFS_LOG_SYNC)); if ( (mfsi_flags & XFS_MFSI_NOUNLINK) == 0 ) { - xlog_recover_process_iunlinks(log); } xlog_recover_check_summary(log); -#if defined(DEBUG) && defined(XFS_LOUD_RECOVERY) cmn_err(CE_NOTE, "Ending XFS recovery on filesystem: %s (dev: %d/%d)", log->l_mp->m_fsname, MAJOR(log->l_dev), MINOR(log->l_dev)); -#else - cmn_err(CE_NOTE, - "!Ending XFS recovery on filesystem: %s (dev: %d/%d)", - log->l_mp->m_fsname, MAJOR(log->l_dev), - MINOR(log->l_dev)); -#endif + log->l_flags &= ~XLOG_RECOVERY_NEEDED; } else { cmn_err(CE_DEBUG, @@ -3785,7 +3931,7 @@ log->l_mp->m_fsname); } return 0; -} /* xlog_recover_finish */ +} #if defined(DEBUG) @@ -3794,7 +3940,8 @@ * are consistent with the superblock counters. */ void -xlog_recover_check_summary(xlog_t *log) +xlog_recover_check_summary( + xlog_t *log) { xfs_mount_t *mp; xfs_agf_t *agfp; diff --exclude=dmapi -rNu ORIG/fs/xfs/xfs_mount.c HACK/fs/xfs/xfs_mount.c --- ORIG/fs/xfs/xfs_mount.c 2003-07-23 09:16:41.000000000 -0500 +++ HACK/fs/xfs/xfs_mount.c 2003-07-15 22:06:55.000000000 -0500 @@ -467,7 +467,11 @@ bp = xfs_buf_read_flags(mp->m_ddev_targp, XFS_SB_DADDR, BTOBB(sector_size), extra_flags); - ASSERT(bp); + if (!bp || XFS_BUF_ISERROR(bp)) { + cmn_err(CE_WARN, "XFS: SB read failed"); + error = bp ? XFS_BUF_GETERROR(bp) : ENOMEM; + goto fail; + } ASSERT(XFS_BUF_ISBUSY(bp)); ASSERT(XFS_BUF_VALUSEMA(bp) <= 0); @@ -482,9 +486,7 @@ error = xfs_mount_validate_sb(mp, &(mp->m_sb)); if (error) { cmn_err(CE_WARN, "XFS: SB validate failed"); - XFS_BUF_UNMANAGE(bp); - xfs_buf_relse(bp); - return error; + goto fail; } /* @@ -494,9 +496,8 @@ cmn_err(CE_WARN, "XFS: device supports only %u byte sectors (not %u)", sector_size, mp->m_sb.sb_sectsize); - XFS_BUF_UNMANAGE(bp); - xfs_buf_relse(bp); - return XFS_ERROR(ENOSYS); + error = ENOSYS; + goto fail; } /* @@ -509,7 +510,11 @@ sector_size = mp->m_sb.sb_sectsize; bp = xfs_buf_read_flags(mp->m_ddev_targp, XFS_SB_DADDR, BTOBB(sector_size), extra_flags); - ASSERT(bp); + if (!bp || XFS_BUF_ISERROR(bp)) { + cmn_err(CE_WARN, "XFS: SB re-read failed"); + error = bp ? XFS_BUF_GETERROR(bp) : ENOMEM; + goto fail; + } ASSERT(XFS_BUF_ISBUSY(bp)); ASSERT(XFS_BUF_VALUSEMA(bp) <= 0); } @@ -518,6 +523,13 @@ xfs_buf_relse(bp); ASSERT(XFS_BUF_VALUSEMA(bp) > 0); return 0; + + fail: + if (bp) { + XFS_BUF_UNMANAGE(bp); + xfs_buf_relse(bp); + } + return error; } @@ -548,16 +560,6 @@ mp->m_blockwmask = mp->m_blockwsize - 1; INIT_LIST_HEAD(&mp->m_del_inodes); - - if (XFS_SB_VERSION_HASLOGV2(sbp)) { - if (sbp->sb_logsunit <= 1) { - mp->m_lstripemask = 1; - } else { - mp->m_lstripemask = - 1 << xfs_highbit32(sbp->sb_logsunit >> BBSHIFT); - } - } - /* * Setup for attributes, in case they get created. * This value is for inodes getting attributes for the first time, @@ -619,7 +621,6 @@ xfs_mountfs( vfs_t *vfsp, xfs_mount_t *mp, - dev_t dev, int mfsi_flags) { xfs_buf_t *bp; @@ -632,11 +633,10 @@ __uint64_t ret64; __int64_t update_flags; uint quotamount, quotaflags; - int agno, noio; + int agno; int uuid_mounted = 0; int error = 0; - noio = dev == 0 && mp->m_sb_bp != NULL; if (mp->m_sb_bp == NULL) { if ((error = xfs_readsb(mp))) { return (error); @@ -729,6 +729,8 @@ } else mp->m_maxicount = 0; + mp->m_maxioffset = xfs_max_file_offset(sbp->sb_blocklog); + /* * XFS uses the uuid from the superblock as the unique * identifier for fsid. We can not use the uuid from the volume @@ -825,22 +827,20 @@ error = XFS_ERROR(E2BIG); goto error1; } - if (!noio) { - error = xfs_read_buf(mp, mp->m_ddev_targp, - d - XFS_FSS_TO_BB(mp, 1), - XFS_FSS_TO_BB(mp, 1), 0, &bp); - if (!error) { - xfs_buf_relse(bp); - } else { - cmn_err(CE_WARN, "XFS: size check 2 failed"); - if (error == ENOSPC) { - error = XFS_ERROR(E2BIG); - } - goto error1; + error = xfs_read_buf(mp, mp->m_ddev_targp, + d - XFS_FSS_TO_BB(mp, 1), + XFS_FSS_TO_BB(mp, 1), 0, &bp); + if (!error) { + xfs_buf_relse(bp); + } else { + cmn_err(CE_WARN, "XFS: size check 2 failed"); + if (error == ENOSPC) { + error = XFS_ERROR(E2BIG); } + goto error1; } - if (!noio && ((mfsi_flags & XFS_MFSI_CLIENT) == 0) && + if (((mfsi_flags & XFS_MFSI_CLIENT) == 0) && mp->m_logdev_targp != mp->m_ddev_targp) { d = (xfs_daddr_t)XFS_FSB_TO_BB(mp, mp->m_sb.sb_logblocks); if (XFS_BB_TO_FSB(mp, d) != mp->m_sb.sb_logblocks) { @@ -917,10 +917,6 @@ * Initialize the precomputed transaction reservations values. */ xfs_trans_init(mp); - if (noio) { - ASSERT((mfsi_flags & XFS_MFSI_CLIENT) == 0); - return 0; - } /* * Allocate and initialize the inode hash table for this diff --exclude=dmapi -rNu ORIG/fs/xfs/xfs_mount.h HACK/fs/xfs/xfs_mount.h --- ORIG/fs/xfs/xfs_mount.h 2003-07-23 09:16:41.000000000 -0500 +++ HACK/fs/xfs/xfs_mount.h 2003-07-15 22:10:11.000000000 -0500 @@ -68,6 +68,7 @@ ((xfs_agblock_t)(XFS_BB_TO_FSBT(mp, d) % (mp)->m_sb.sb_agblocks)) #else struct cred; +struct log; struct vfs; struct vnode; struct xfs_mount_args; @@ -79,7 +80,6 @@ struct xfs_bmbt_irec; struct xfs_bmap_free; -#define SPLDECL(s) unsigned long s #define AIL_LOCK_T lock_t #define AIL_LOCKINIT(x,y) spinlock_init(x,y) #define AIL_LOCK_DESTROY(x) spinlock_destroy(x) @@ -303,7 +303,7 @@ uint m_readio_blocks; /* min read size blocks */ uint m_writeio_log; /* min write size log bytes */ uint m_writeio_blocks; /* min write size blocks */ - void *m_log; /* log specific stuff */ + struct log *m_log; /* log specific stuff */ int m_logbufs; /* number of log buffers */ int m_logbsize; /* size of each log buffer */ uint m_rsumlevels; /* rt summary levels */ @@ -351,6 +351,7 @@ uint m_qflags; /* quota status flags */ xfs_trans_reservations_t m_reservations;/* precomputed res values */ __uint64_t m_maxicount; /* maximum inode count */ + __uint64_t m_maxioffset; /* maximum inode offset */ __uint64_t m_resblks; /* total reserved blocks */ __uint64_t m_resblks_avail;/* available reserved blocks */ #if XFS_BIG_FILESYSTEMS @@ -358,7 +359,6 @@ #endif int m_dalign; /* stripe unit */ int m_swidth; /* stripe width */ - int m_lstripemask; /* log stripe mask */ int m_sinoalign; /* stripe unit inode alignmnt */ int m_attr_magicpct;/* 37% of the blocksize */ int m_dir_magicpct; /* 37% of the dir blocksize */ @@ -418,8 +418,6 @@ * 32 bits in size */ #define XFS_MOUNT_NOLOGFLUSH 0x00010000 -#define XFS_FORCED_SHUTDOWN(mp) ((mp)->m_flags & XFS_MOUNT_FS_SHUTDOWN) - /* * Default minimum read and write sizes. */ @@ -444,6 +442,9 @@ #define XFS_WSYNC_READIO_LOG 15 /* 32K */ #define XFS_WSYNC_WRITEIO_LOG 14 /* 16K */ +#define XFS_MAXIOFFSET(mp) ((mp)->m_maxioffset) + +#define XFS_FORCED_SHUTDOWN(mp) ((mp)->m_flags & XFS_MOUNT_FS_SHUTDOWN) #define xfs_force_shutdown(m,f) \ VFS_FORCE_SHUTDOWN((XFS_MTOVFS(m)), f, __FILE__, __LINE__) @@ -539,7 +540,7 @@ extern xfs_mount_t *xfs_mount_init(void); extern void xfs_mod_sb(xfs_trans_t *, __int64_t); extern void xfs_mount_free(xfs_mount_t *mp, int remove_bhv); -extern int xfs_mountfs(struct vfs *, xfs_mount_t *mp, dev_t, int); +extern int xfs_mountfs(struct vfs *, xfs_mount_t *mp, int); extern int xfs_unmountfs(xfs_mount_t *, struct cred *); extern void xfs_unmountfs_close(xfs_mount_t *, struct cred *); diff --exclude=dmapi -rNu ORIG/fs/xfs/xfs_rw.c HACK/fs/xfs/xfs_rw.c --- ORIG/fs/xfs/xfs_rw.c 2003-07-23 09:16:41.000000000 -0500 +++ HACK/fs/xfs/xfs_rw.c 2003-07-08 09:00:23.000000000 -0500 @@ -408,7 +408,6 @@ spinlock_t xfs_refcache_lock = SPIN_LOCK_UNLOCKED; xfs_inode_t **xfs_refcache; -int xfs_refcache_size; int xfs_refcache_index; int xfs_refcache_busy; int xfs_refcache_count; @@ -635,15 +634,13 @@ xfs_inode_t *ip; int iplist_index; xfs_inode_t **iplist; - int purge_count; if ((xfs_refcache == NULL) || (xfs_refcache_count == 0)) { return; } iplist_index = 0; - purge_count = xfs_params.refcache_purge; - iplist = (xfs_inode_t **)kmem_zalloc(purge_count * + iplist = (xfs_inode_t **)kmem_zalloc(xfs_refcache_purge_count * sizeof(xfs_inode_t *), KM_SLEEP); spin_lock(&xfs_refcache_lock); @@ -656,7 +653,7 @@ * forward as we go so that we are sure to eventually clear * out the entire cache when the system goes idle. */ - for (i = 0; i < purge_count; i++) { + for (i = 0; i < xfs_refcache_purge_count; i++) { ip = xfs_refcache[xfs_refcache_index]; if (ip != NULL) { xfs_refcache[xfs_refcache_index] = NULL; @@ -682,7 +679,7 @@ VN_RELE(XFS_ITOV(iplist[i])); } - kmem_free(iplist, purge_count * + kmem_free(iplist, xfs_refcache_purge_count * sizeof(xfs_inode_t *)); } diff --exclude=dmapi -rNu ORIG/fs/xfs/xfs_sb.h HACK/fs/xfs/xfs_sb.h --- ORIG/fs/xfs/xfs_sb.h 2003-07-23 09:16:41.000000000 -0500 +++ HACK/fs/xfs/xfs_sb.h 2003-06-26 11:52:34.000000000 -0500 @@ -81,7 +81,7 @@ XFS_SB_VERSION_OKREALFBITS | \ XFS_SB_VERSION_OKSASHFBITS) #define XFS_SB_VERSION_MKFS(ia,dia,extflag,dirv2,na,sflag) \ - (((ia) || (dia) || (extflag) || (dirv2) || (na)) ? \ + (((ia) || (dia) || (extflag) || (dirv2) || (na) || (sflag)) ? \ (XFS_SB_VERSION_4 | \ ((ia) ? XFS_SB_VERSION_ALIGNBIT : 0) | \ ((dia) ? XFS_SB_VERSION_DALIGNBIT : 0) | \ diff --exclude=dmapi -rNu ORIG/fs/xfs/xfs_trans.c HACK/fs/xfs/xfs_trans.c --- ORIG/fs/xfs/xfs_trans.c 2003-07-23 09:16:41.000000000 -0500 +++ HACK/fs/xfs/xfs_trans.c 2003-07-15 22:17:23.000000000 -0500 @@ -200,6 +200,7 @@ tp->t_blk_res = tp->t_blk_res_used; ntp->t_rtx_res = tp->t_rtx_res - tp->t_rtx_res_used; tp->t_rtx_res = tp->t_rtx_res_used; + PFLAGS_DUP(&tp->t_pflags, &ntp->t_pflags); XFS_TRANS_DUP_DQINFO(tp->t_mountp, tp, ntp); @@ -238,7 +239,7 @@ rsvd = (tp->t_flags & XFS_TRANS_RESERVE) != 0; /* Mark this thread as being in a transaction */ - current->flags |= PF_FSTRANS; + PFLAGS_SET_FSTRANS(&tp->t_pflags); /* * Attempt to reserve the needed disk blocks by decrementing @@ -249,7 +250,7 @@ error = xfs_mod_incore_sb(tp->t_mountp, XFS_SBS_FDBLOCKS, -blocks, rsvd); if (error != 0) { - current->flags &= ~PF_FSTRANS; + PFLAGS_RESTORE(&tp->t_pflags); return (XFS_ERROR(ENOSPC)); } tp->t_blk_res += blocks; @@ -322,7 +323,7 @@ tp->t_blk_res = 0; } - current->flags &= ~PF_FSTRANS; + PFLAGS_RESTORE(&tp->t_pflags); return (error); } @@ -734,13 +735,13 @@ if (commit_lsn == -1 && !shutdown) shutdown = XFS_ERROR(EIO); } + PFLAGS_RESTORE(&tp->t_pflags); xfs_trans_free_items(tp, shutdown? XFS_TRANS_ABORT : 0); xfs_trans_free_busy(tp); xfs_trans_free(tp); XFS_STATS_INC(xfsstats.xs_trans_empty); if (commit_lsn_p) *commit_lsn_p = commit_lsn; - current->flags &= ~PF_FSTRANS; return (shutdown); } #if defined(XLOG_NOLOG) || defined(DEBUG) @@ -823,8 +824,8 @@ * had pinned, clean up, free trans structure, and return error. */ if (error || commit_lsn == -1) { + PFLAGS_RESTORE(&tp->t_pflags); xfs_trans_uncommit(tp, flags|XFS_TRANS_ABORT); - current->flags &= ~PF_FSTRANS; return XFS_ERROR(EIO); } @@ -850,15 +851,6 @@ * running in simulation mode (the log is explicitly turned * off). */ -#if defined(XLOG_NOLOG) || defined(DEBUG) - if (xlog_debug) { - tp->t_logcb.cb_func = (void(*)(void*, int))xfs_trans_committed; - tp->t_logcb.cb_arg = tp; - error = xfs_log_notify(mp, commit_iclog, &(tp->t_logcb)); - } else { - xfs_trans_committed(tp, 0); - } -#else tp->t_logcb.cb_func = (void(*)(void*, int))xfs_trans_committed; tp->t_logcb.cb_arg = tp; @@ -869,7 +861,9 @@ * waiting for an item to unlock. */ error = xfs_log_notify(mp, commit_iclog, &(tp->t_logcb)); -#endif + + /* mark this thread as no longer being in a transaction */ + PFLAGS_RESTORE(&tp->t_pflags); /* * Once all the items of the transaction have been copied @@ -906,9 +900,6 @@ XFS_STATS_INC(xfsstats.xs_trans_async); } - /* mark this thread as no longer being in a transaction */ - current->flags &= ~PF_FSTRANS; - return (error); } @@ -1108,12 +1099,13 @@ } xfs_log_done(tp->t_mountp, tp->t_ticket, NULL, log_flags); } + + /* mark this thread as no longer being in a transaction */ + PFLAGS_RESTORE(&tp->t_pflags); + xfs_trans_free_items(tp, flags); xfs_trans_free_busy(tp); xfs_trans_free(tp); - - /* mark this thread as no longer being in a transaction */ - current->flags &= ~PF_FSTRANS; } diff --exclude=dmapi -rNu ORIG/fs/xfs/xfs_trans.h HACK/fs/xfs/xfs_trans.h --- ORIG/fs/xfs/xfs_trans.h 2003-07-23 09:16:41.000000000 -0500 +++ HACK/fs/xfs/xfs_trans.h 2003-07-15 22:10:12.000000000 -0500 @@ -409,6 +409,7 @@ xfs_trans_header_t t_header; /* header for in-log trans */ unsigned int t_busy_free; /* busy descs free */ xfs_log_busy_chunk_t t_busy; /* busy/async free blocks */ + xfs_pflags_t t_pflags; /* saved pflags state */ } xfs_trans_t; #endif /* __KERNEL__ */ diff --exclude=dmapi -rNu ORIG/fs/xfs/xfs_vfsops.c HACK/fs/xfs/xfs_vfsops.c --- ORIG/fs/xfs/xfs_vfsops.c 2003-07-23 09:16:41.000000000 -0500 +++ HACK/fs/xfs/xfs_vfsops.c 2003-07-15 22:24:11.000000000 -0500 @@ -96,10 +96,6 @@ #endif /* DEBUG */ #ifdef XFS_DABUF_DEBUG extern lock_t xfs_dabuf_global_lock; -#endif - extern int xfs_refcache_size; - -#ifdef XFS_DABUF_DEBUG spinlock_init(&xfs_dabuf_global_lock, "xfsda"); #endif @@ -177,8 +173,6 @@ xfs_init_procfs(); xfs_sysctl_register(); - xfs_refcache_size = xfs_params.refcache_size; - /* * The inode hash table is created on a per mounted * file system bases. @@ -244,7 +238,7 @@ /* * At this point the superblock has not been read * in, therefore we do not know the block size. - * Before, the mount call ends we will convert + * Before the mount call ends we will convert * these to FSBs. */ mp->m_dalign = ap->sunit; @@ -252,11 +246,11 @@ } if (ap->logbufs != 0 && ap->logbufs != -1 && - (ap->logbufs < XLOG_NUM_ICLOGS || + (ap->logbufs < XLOG_MIN_ICLOGS || ap->logbufs > XLOG_MAX_ICLOGS)) { cmn_err(CE_WARN, "XFS: invalid logbufs value: %d [not %d-%d]", - ap->logbufs, XLOG_NUM_ICLOGS, XLOG_MAX_ICLOGS); + ap->logbufs, XLOG_MIN_ICLOGS, XLOG_MAX_ICLOGS); return XFS_ERROR(EINVAL); } mp->m_logbufs = ap->logbufs; @@ -619,6 +613,8 @@ return XFS_ERROR(error); } +#define REMOUNT_READONLY_FLAGS (SYNC_REMOUNT|SYNC_ATTR|SYNC_WAIT) + STATIC int xfs_mntupdate( bhv_desc_t *bdp, @@ -644,7 +640,7 @@ xfs_finish_reclaim_all(mp, 0); do { - VFS_SYNC(vfsp, SYNC_ATTR|SYNC_WAIT, NULL, error); + VFS_SYNC(vfsp, REMOUNT_READONLY_FLAGS, NULL, error); pagebuf_delwri_flush(mp->m_ddev_targp, PBDF_WAIT, &pincount); } while (pincount); @@ -1514,7 +1510,7 @@ * Now check to see if the log needs a "dummy" transaction. */ - if (xfs_log_need_covered(mp)) { + if (!(flags & SYNC_REMOUNT) && xfs_log_need_covered(mp)) { xfs_trans_t *tp; xfs_inode_t *ip; @@ -1650,7 +1646,7 @@ if (!value || !*value) { printk("XFS: %s option requires an argument\n", MNTOPT_LOGBUFS); - return -EINVAL; + return EINVAL; } args->logbufs = simple_strtoul(value, &eov, 10); } else if (!strcmp(this_char, MNTOPT_LOGBSIZE)) { @@ -1659,7 +1655,7 @@ if (!value || !*value) { printk("XFS: %s option requires an argument\n", MNTOPT_LOGBSIZE); - return -EINVAL; + return EINVAL; } last = strlen(value) - 1; if (value[last] == 'K' || value[last] == 'k') { @@ -1673,28 +1669,28 @@ if (!value || !*value) { printk("XFS: %s option requires an argument\n", MNTOPT_LOGDEV); - return -EINVAL; + return EINVAL; } strncpy(args->logname, value, MAXNAMELEN); } else if (!strcmp(this_char, MNTOPT_MTPT)) { if (!value || !*value) { printk("XFS: %s option requires an argument\n", MNTOPT_MTPT); - return -EINVAL; + return EINVAL; } strncpy(args->mtpt, value, MAXNAMELEN); } else if (!strcmp(this_char, MNTOPT_RTDEV)) { if (!value || !*value) { printk("XFS: %s option requires an argument\n", MNTOPT_RTDEV); - return -EINVAL; + return EINVAL; } strncpy(args->rtname, value, MAXNAMELEN); } else if (!strcmp(this_char, MNTOPT_BIOSIZE)) { if (!value || !*value) { printk("XFS: %s option requires an argument\n", MNTOPT_BIOSIZE); - return -EINVAL; + return EINVAL; } iosize = simple_strtoul(value, &eov, 10); args->flags |= XFSMNT_IOSIZE; @@ -1710,7 +1706,7 @@ #ifndef XFS_BIG_FILESYSTEMS printk("XFS: %s option not allowed on this system\n", MNTOPT_INO64); - return -EINVAL; + return EINVAL; #endif } else if (!strcmp(this_char, MNTOPT_NOALIGN)) { args->flags |= XFSMNT_NOALIGN; @@ -1718,14 +1714,14 @@ if (!value || !*value) { printk("XFS: %s option requires an argument\n", MNTOPT_SUNIT); - return -EINVAL; + return EINVAL; } dsunit = simple_strtoul(value, &eov, 10); } else if (!strcmp(this_char, MNTOPT_SWIDTH)) { if (!value || !*value) { printk("XFS: %s option requires an argument\n", MNTOPT_SWIDTH); - return -EINVAL; + return EINVAL; } dswidth = simple_strtoul(value, &eov, 10); } else if (!strcmp(this_char, MNTOPT_NOUUID)) { @@ -1739,33 +1735,33 @@ printk("XFS: irixsgid is now a sysctl(2) variable, option is deprecated.\n"); } else { printk("XFS: unknown mount option [%s].\n", this_char); - return -EINVAL; + return EINVAL; } } if (args->flags & XFSMNT_NORECOVERY) { if ((vfsp->vfs_flag & VFS_RDONLY) == 0) { printk("XFS: no-recovery mounts must be read-only.\n"); - return -EINVAL; + return EINVAL; } } if ((args->flags & XFSMNT_NOALIGN) && (dsunit || dswidth)) { printk( "XFS: sunit and swidth options incompatible with the noalign option\n"); - return -EINVAL; + return EINVAL; } if ((dsunit && !dswidth) || (!dsunit && dswidth)) { printk("XFS: sunit and swidth must be specified together\n"); - return -EINVAL; + return EINVAL; } if (dsunit && (dswidth % dsunit != 0)) { printk( "XFS: stripe width (%d) must be a multiple of the stripe unit (%d)\n", dswidth, dsunit); - return -EINVAL; + return EINVAL; } if ((args->flags & XFSMNT_NOALIGN) != XFSMNT_NOALIGN) { diff --exclude=dmapi -rNu ORIG/fs/xfs/xfs_vnodeops.c HACK/fs/xfs/xfs_vnodeops.c --- ORIG/fs/xfs/xfs_vnodeops.c 2003-07-23 09:16:41.000000000 -0500 +++ HACK/fs/xfs/xfs_vnodeops.c 2003-07-15 22:06:56.000000000 -0500 @@ -1,5 +1,5 @@ /* - * Copyright (c) 2000-2002 Silicon Graphics, Inc. All Rights Reserved. + * Copyright (c) 2000-2003 Silicon Graphics, Inc. All Rights Reserved. * * This program is free software; you can redistribute it and/or modify it * under the terms of version 2 of the GNU General Public License as @@ -318,6 +318,9 @@ vp = BHV_TO_VNODE(bdp); vn_trace_entry(vp, __FUNCTION__, (inst_t *)__return_address); + if (vp->v_vfsp->vfs_flag & VFS_RDONLY) + return XFS_ERROR(EROFS); + /* * Cannot set certain attributes. */ @@ -578,7 +581,8 @@ /* * Can't change extent size if any extents are allocated. */ - if (ip->i_d.di_nextents && (mask & XFS_AT_EXTSIZE) && + if ((ip->i_d.di_nextents || ip->i_delayed_blks) && + (mask & XFS_AT_EXTSIZE) && ((ip->i_d.di_extsize << mp->m_sb.sb_blocklog) != vap->va_extsize) ) { code = XFS_ERROR(EINVAL); /* EFBIG? */ @@ -658,7 +662,7 @@ if (vap->va_size > ip->i_d.di_size) { code = xfs_igrow_start(ip, vap->va_size, credp); xfs_iunlock(ip, XFS_ILOCK_EXCL); - } else if (vap->va_size < ip->i_d.di_size) { + } else if (vap->va_size <= ip->i_d.di_size) { xfs_iunlock(ip, XFS_ILOCK_EXCL); xfs_itruncate_start(ip, XFS_ITRUNC_DEFINITE, (xfs_fsize_t)vap->va_size); @@ -701,7 +705,7 @@ if (vap->va_size > ip->i_d.di_size) { xfs_igrow_finish(tp, ip, vap->va_size, !(flags & ATTR_DMI)); - } else if ((vap->va_size < ip->i_d.di_size) || + } else if ((vap->va_size <= ip->i_d.di_size) || ((vap->va_size == 0) && ip->i_d.di_nextents)) { /* * signal a sync transaction unless @@ -1286,7 +1290,7 @@ * of the file. If not, then there is nothing to do. */ end_fsb = XFS_B_TO_FSB(mp, ((xfs_ufsize_t)ip->i_d.di_size)); - last_fsb = XFS_B_TO_FSB(mp, (xfs_ufsize_t)XFS_MAX_FILE_OFFSET); + last_fsb = XFS_B_TO_FSB(mp, (xfs_ufsize_t)XFS_MAXIOFFSET(mp)); map_len = last_fsb - end_fsb; if (map_len <= 0) return (0); @@ -3966,6 +3970,7 @@ */ if (!ip->i_update_core && (ip->i_itemp == NULL)) { xfs_ilock(ip, XFS_ILOCK_EXCL); + xfs_iflock(ip); return xfs_finish_reclaim(ip, 1, XFS_IFLUSH_DELWRI_ELSE_SYNC); } else { xfs_mount_t *mp = ip->i_mount; @@ -3974,7 +3979,7 @@ XFS_MOUNT_ILOCK(mp); vn_bhv_remove(VN_BHV_HEAD(vp), XFS_ITOBHV(ip)); list_add_tail(&ip->i_reclaim, &mp->m_del_inodes); - + ip->i_flags |= XFS_IRECLAIMABLE; XFS_MOUNT_IUNLOCK(mp); } return 0; @@ -3989,19 +3994,20 @@ xfs_ihash_t *ih = ip->i_hash; int error; - if (!locked) - xfs_ilock(ip, XFS_ILOCK_EXCL); - /* The hash lock here protects a thread in xfs_iget_core from * racing with us on linking the inode back with a vnode. * Once we have the XFS_IRECLAIM flag set it will not touch * us. */ write_lock(&ih->ih_lock); - if (ip->i_flags & XFS_IRECLAIM || (!locked && XFS_ITOV_NULL(ip))) { + if ((ip->i_flags & XFS_IRECLAIM) || + (!(ip->i_flags & XFS_IRECLAIMABLE) && + (XFS_ITOV_NULL(ip) == NULL))) { write_unlock(&ih->ih_lock); - if (!locked) + if (locked) { + xfs_ifunlock(ip); xfs_iunlock(ip, XFS_ILOCK_EXCL); + } return(1); } ip->i_flags |= XFS_IRECLAIM; @@ -4020,6 +4026,7 @@ */ if (!XFS_FORCED_SHUTDOWN(ip->i_mount)) { if (!locked) { + xfs_ilock(ip, XFS_ILOCK_EXCL); xfs_iflock(ip); } @@ -4043,8 +4050,16 @@ ASSERT(ip->i_update_core == 0); ASSERT(ip->i_itemp == NULL || ip->i_itemp->ili_format.ilf_fields == 0); + xfs_iunlock(ip, XFS_ILOCK_EXCL); + } else if (locked) { + /* + * We are not interested in doing an iflush if we're + * in the process of shutting down the filesystem forcibly. + * So, just reclaim the inode. + */ + xfs_ifunlock(ip); + xfs_iunlock(ip, XFS_ILOCK_EXCL); } - xfs_iunlock(ip, XFS_ILOCK_EXCL); xfs_ireclaim(ip); return 0; @@ -4636,9 +4651,9 @@ llen = bf->l_len > 0 ? bf->l_len - 1 : bf->l_len; if ( (bf->l_start < 0) - || (bf->l_start > XFS_MAX_FILE_OFFSET) + || (bf->l_start > XFS_MAXIOFFSET(mp)) || (bf->l_start + llen < 0) - || (bf->l_start + llen > XFS_MAX_FILE_OFFSET)) + || (bf->l_start + llen > XFS_MAXIOFFSET(mp))) return XFS_ERROR(EINVAL); bf->l_whence = 0; diff --exclude=dmapi -rNu ORIG/include/linux/fs.h HACK/include/linux/fs.h --- ORIG/include/linux/fs.h 2003-07-23 09:17:10.000000000 -0500 +++ HACK/include/linux/fs.h 2003-07-23 12:12:12.000000000 -0500 @@ -1393,6 +1393,7 @@ #define user_path_walk_link(name,nd) __user_walk(name, LOOKUP_POSITIVE, nd) extern void inode_init_once(struct inode *); +extern void _inode_init_once(struct inode *); extern void iput(struct inode *); extern void refile_inode(struct inode *inode); diff --exclude=dmapi -rNu ORIG/kernel/ksyms.c HACK/kernel/ksyms.c --- ORIG/kernel/ksyms.c 2003-07-23 09:17:27.000000000 -0500 +++ HACK/kernel/ksyms.c 2003-07-23 10:09:55.000000000 -0500 @@ -163,6 +163,7 @@ EXPORT_SYMBOL(unlock_new_inode); EXPORT_SYMBOL(iput); EXPORT_SYMBOL(inode_init_once); +EXPORT_SYMBOL(_inode_init_once); EXPORT_SYMBOL(force_delete); EXPORT_SYMBOL(follow_up); EXPORT_SYMBOL(follow_down); diff --exclude=dmapi -rNu ORIG/mm/filemap.c HACK/mm/filemap.c --- ORIG/mm/filemap.c 2003-07-23 09:17:12.000000000 -0500 +++ HACK/mm/filemap.c 2003-07-23 12:16:55.000000000 -0500 @@ -3358,6 +3358,36 @@ return err; } + +ssize_t +generic_file_write_nolock(struct file *file,const char *buf,size_t count, loff_t *ppos) +{ + struct inode *inode = file->f_dentry->d_inode->i_mapping->host; + int err; + + if ((ssize_t) count < 0) + return -EINVAL; + + if (!access_ok(VERIFY_READ, buf, count)) + return -EFAULT; + + if (file->f_flags & O_DIRECT) { + /* do_generic_direct_write may drop i_sem during the + actual IO */ + down_read(&inode->i_alloc_sem); + err = do_generic_direct_write(file, buf, count, ppos); + up_read(&inode->i_alloc_sem); + if (unlikely(err == -ENOTBLK)) + err = do_odirect_fallback(file, inode, buf, count, ppos); + } else { + err = do_generic_file_write(file, buf, count, ppos); + } + + return err; +} + +EXPORT_SYMBOL(generic_file_write_nolock); + void __init page_cache_init(unsigned long mempages) { unsigned long htable_size, order; --=-nr+iXrIxRFQ2Xe1lMWPE-- From owner-linux-xfs@oss.sgi.com Wed Jul 23 16:15:55 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 23 Jul 2003 16:16:29 -0700 (PDT) Received: from andrei.myip.org (12-234-128-127.client.attbi.com [12.234.128.127]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h6NNFNFl005228 for ; Wed, 23 Jul 2003 16:15:55 -0700 Received: by andrei.myip.org (Postfix, from userid 102) id CE6E52FA84; Wed, 23 Jul 2003 16:15:22 -0700 (PDT) Received: from stantz.corp.sgi.com (unknown [130.62.4.42]) by andrei.myip.org (Postfix) with ESMTP id A061E2FA81 for ; Wed, 23 Jul 2003 16:15:21 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by stantz.corp.sgi.com (Postfix) with ESMTP id 94CF81967C for ; Wed, 23 Jul 2003 16:15:10 -0700 (PDT) Subject: Re: kernel bug in rmap.c:398 From: Florin Andrei Reply-To: linux-xfs@oss.sgi.com To: linux-xfs@oss.sgi.com In-Reply-To: <3F1ED8B0.5040407@mps.ohio-state.edu> References: <3F1ED8B0.5040407@mps.ohio-state.edu> Content-Type: text/plain Organization: SGI Message-Id: <1059002109.2169.23.camel@stantz.corp.sgi.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.3 (1.4.3-1) Date: 23 Jul 2003 16:15:10 -0700 Content-Transfer-Encoding: 7bit X-archive-position: 4707 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: florin@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 270 Lines: 14 On Wed, 2003-07-23 at 11:49, Dirk Hufnagel wrote: > kernel BUG at rmap.c:398! I've seen this bug reported on Red Hat mailing lists, by people running non-XFS RH kernels. So, it's not XFS. -- Florin Andrei "Never send a human to do a machine's job." - Agent Smith From owner-linux-xfs@oss.sgi.com Wed Jul 23 16:52:18 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 23 Jul 2003 16:52:51 -0700 (PDT) Received: from srv2.resnet.ohio-state.edu (srv2.resnet.ohio-state.edu [164.107.3.56]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h6NNpoFl008149 for ; Wed, 23 Jul 2003 16:52:18 -0700 Received: (qmail 27591 invoked by uid 506); 24 Jul 2003 00:34:04 -0000 Received: from hufnagel@mps.ohio-state.edu by srv2.resnet.ohio-state.edu by uid 503 with qmail-scanner-1.14 ( Clear:. Processed in 0.020677 secs); 24 Jul 2003 00:34:04 -0000 Received: from rjot-164-107-209-133.resnet.ohio-state.edu (HELO mps.ohio-state.edu) (164.107.209.133) by srv2.resnet.ohio-state.edu with SMTP; 24 Jul 2003 00:34:04 -0000 Message-ID: <3F1F1F9B.3080403@mps.ohio-state.edu> Date: Wed, 23 Jul 2003 19:51:55 -0400 From: Dirk Hufnagel User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en MIME-Version: 1.0 To: linux-xfs@oss.sgi.com Subject: Re: kernel bug in rmap.c:398 References: <3F1ED8B0.5040407@mps.ohio-state.edu> <1059002109.2169.23.camel@stantz.corp.sgi.com> In-Reply-To: <1059002109.2169.23.camel@stantz.corp.sgi.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 4708 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: hufnagel@mps.ohio-state.edu Precedence: bulk X-list: linux-xfs Content-Length: 403 Lines: 22 Florin Andrei wrote: > On Wed, 2003-07-23 at 11:49, Dirk Hufnagel wrote: > > >>kernel BUG at rmap.c:398! > > > I've seen this bug reported on Red Hat mailing lists, by people running > non-XFS RH kernels. > > So, it's not XFS. I reply by email since this isn't really xfs related. Do you remember from these bug reports on redhat mailing lists if there was a fix or workaround ? Thanks Dirk From owner-linux-xfs@oss.sgi.com Wed Jul 23 20:56:31 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 23 Jul 2003 20:57:13 -0700 (PDT) Received: from opcenter.net (mail2.opcenter.net [206.165.174.15]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h6O3u7Fl030764 for ; Wed, 23 Jul 2003 20:56:31 -0700 Received: from [206.165.174.40] (HELO monitor1) by opcenter.net (CommuniGate Pro SMTP 3.5.2) with ESMTP id 3169759 for linux-xfs@oss.sgi.com; Wed, 23 Jul 2003 23:56:06 -0400 From: "Michael Steinhart" Organization: OpCenter.net To: linux-xfs@oss.sgi.com Date: Wed, 23 Jul 2003 23:56:06 -0400 MIME-Version: 1.0 Subject: Redhat9 XFS ISO problem. Reply-to: Michael Steinhart Message-ID: <3F1F2096.28451.168E38C@localhost> Priority: normal X-mailer: Pegasus Mail for Windows (v4.12a) Content-type: text/html; charset=ISO-8859-1 Content-transfer-encoding: Quoted-printable Content-description: Mail message body X-archive-position: 4709 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: mike@opcenter.net Precedence: bulk X-list: linux-xfs Content-Length: 3261 Lines: 76
Re= dhat9 ISO problem.

Su= per Micro 1U server
Xe= on 2.4
3w= are 7002
2 = Maxtor 160GB 7200 / 133, Raid 1

I = am installing Redhat9 with the ISO image that I downloaded from the SGI si= te. I created the install CD. The installer booted fine and I partitioned the di= sk as usual. The disk formatted in XFS format without any problems. Then it got to the = point where it was to begin installing the packages and that is ware the problem= is. The message I get is “Please insert disk 1 to continue”. I tried all= of the Redhat CD’s including the SGI ISO but I always get the message “Wrong CDROM”= ,  “That’s not the correct SGI-XFS CDROM”. I have tried this install several tomes a= nd get the same resolute.

An= y help would be appreciated. I need to get out 3 systems in the next day.<= /span>

Th= anks in advance,
Mi= chael Steinhart



__= _________________________________________________________
Mi= chael Steinhart          = ;      OPCenter.net
mi= ke@opcenter.net          = ;      PMH Network Services, Inc.
ht= tp://www.opcenter.net         = ; 284 Ackerman Ave
&#= 160;           = 0;            =         Emerson, NJ 07630
<= /span>
From owner-linux-xfs@oss.sgi.com Wed Jul 23 23:50:05 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 23 Jul 2003 23:50:20 -0700 (PDT) Received: from mail.epost.de (mail.epost.de [193.28.100.165] (may be forged)) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h6O6o3Fl008221 for ; Wed, 23 Jul 2003 23:50:04 -0700 Received: from epost.de (217.110.232.6) by mail.epost.de (6.7.015) (authenticated as rainer.traut@epost.de) id 3F1EF09B0000753B; Thu, 24 Jul 2003 07:52:18 +0200 Message-ID: <3F1F74BB.8080404@epost.de> Date: Thu, 24 Jul 2003 07:55:07 +0200 From: Rainer Traut User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5a) Gecko/20030718 X-Accept-Language: de, en-us, en MIME-Version: 1.0 To: Axel Thimm CC: linux-xfs Subject: Re: kernel-2.4.20-19.9.3.at: latest RHL 9 errata & XFS 1.2 References: <20030723153705.GA6882@puariko.nirvana> In-Reply-To: <20030723153705.GA6882@puariko.nirvana> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 4710 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: rainer.traut@epost.de Precedence: bulk X-list: linux-xfs Content-Length: 592 Lines: 23 Hi, Axel Thimm wrote: > I have merged in the XFS patches from 1.2 into the latest release RedHat > kernel for Red Hat 9. > > You can find them under > > http://atrpms.physik.fu-berlin.de/name/kernel/ from experience with his older rpms i know these are running fine :) as I need these kernel rpms for Redhat 8, as Lotus Domino runs only on Redhat 7.2 to 8.0 could anybody tell me how to change them to fit with redhat 8? I know, I have to disable the new threading. Install the src rpm on Redhat 8, make changes to spec-file (but what?) and rebuild the rpm...? Thank you Rainer Traut From owner-linux-xfs@oss.sgi.com Thu Jul 24 06:11:17 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 24 Jul 2003 06:11:38 -0700 (PDT) Received: from linux-sxs.org (dhcp065-024-128-253.columbus.rr.com [65.24.128.253]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h6ODBFFl021922 for ; Thu, 24 Jul 2003 06:11:16 -0700 Received: from linux-sxs.org (localhost [127.0.0.1]) by linux-sxs.org (8.12.9/8.12.9) with ESMTP id h6ODBBXu003314; Thu, 24 Jul 2003 09:11:12 -0400 Received: from localhost (netllama@localhost) by linux-sxs.org (8.12.9/8.12.9/Submit) with ESMTP id h6ODBBlx005963; Thu, 24 Jul 2003 09:11:11 -0400 Date: Thu, 24 Jul 2003 09:11:11 -0400 (EDT) From: Net Llama! To: Michael Steinhart cc: linux-xfs@oss.sgi.com Subject: Re: Redhat9 XFS ISO problem. In-Reply-To: <3F1F2096.28451.168E38C@localhost> Message-ID: References: <3F1F2096.28451.168E38C@localhost> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: OK, scanned by File::Scan,ClamAV X-Scanned-By: MIMEDefang 2.35 X-archive-position: 4711 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: netllama@linux-sxs.org Precedence: bulk X-list: linux-xfs Content-Length: 1142 Lines: 23 On Wed, 23 Jul 2003, Michael Steinhart wrote: > > Redhat9 ISO problem. > Super Micro 1U server > Xeon 2.4 > 3ware 7002 > 2 Maxtor 160GB 7200 / 133, Raid 1 > I am installing Redhat9 with the ISO image that I downloaded from the SGI site. I created the install > CD. The installer booted fine and I partitioned the disk as usual. The disk formatted in XFS format > without any problems. Then it got to the point where it was to begin installing the packages and that > is ware the problem is. The message I get is “Please insert disk 1 to continue”. I tried > all of the Redhat CD’s including the SGI ISO but I always get the message “Wrong > CDROM”, “That’s not the correct SGI-XFS CDROM”. I have tried this install > several tomes and get the same resolute. > Any help would be appreciated. I need to get out 3 systems in the next day. Disk 1 is the first RH CD. Sounds like you've got a bad CD. -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Lonni J Friedman netllama@linux-sxs.org Linux Step-by-step & TyGeMo http://netllama.ipfox.com From owner-linux-xfs@oss.sgi.com Thu Jul 24 06:42:09 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 24 Jul 2003 06:42:30 -0700 (PDT) Received: from srv2.resnet.ohio-state.edu (srv2.resnet.ohio-state.edu [164.107.3.56]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h6ODg8Fl024386 for ; Thu, 24 Jul 2003 06:42:08 -0700 Received: (qmail 2584 invoked by uid 506); 24 Jul 2003 14:24:27 -0000 Received: from hufnagel@mps.ohio-state.edu by srv2.resnet.ohio-state.edu by uid 503 with qmail-scanner-1.14 ( Clear:. Processed in 0.021088 secs); 24 Jul 2003 14:24:27 -0000 Received: from rjot-164-107-209-133.resnet.ohio-state.edu (HELO mps.ohio-state.edu) (164.107.209.133) by srv2.resnet.ohio-state.edu with SMTP; 24 Jul 2003 14:24:27 -0000 Message-ID: <3F1FE23B.8020904@mps.ohio-state.edu> Date: Thu, 24 Jul 2003 09:42:19 -0400 From: Dirk Hufnagel User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Rainer Traut CC: linux-xfs Subject: Re: kernel-2.4.20-19.9.3.at: latest RHL 9 errata & XFS 1.2 References: <20030723153705.GA6882@puariko.nirvana> <3F1F74BB.8080404@epost.de> In-Reply-To: <3F1F74BB.8080404@epost.de> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 4712 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: hufnagel@mps.ohio-state.edu Precedence: bulk X-list: linux-xfs Content-Length: 2208 Lines: 73 Rainer Traut wrote: > Hi, > > Axel Thimm wrote: > >> I have merged in the XFS patches from 1.2 into the latest release RedHat >> kernel for Red Hat 9. >> >> You can find them under >> >> http://atrpms.physik.fu-berlin.de/name/kernel/ > > > from experience with his older rpms i know these are running > fine :) > as I need these kernel rpms for Redhat 8, as Lotus Domino runs > only on Redhat 7.2 to 8.0 could anybody tell me how to change > them to fit with redhat 8? > I know, I have to disable the new threading. > Install the src rpm on Redhat 8, make changes to spec-file (but what?) > and rebuild the rpm...? > > Thank you > Rainer Traut What I did to built a 2.4.20-18.7 kernel on Redhat 7.2 : - install a Redhat 7.2 2.4.20-18 kernel-source package - download the Redhat 9 iso installer - extract the kernel src rpm from the iso - extract xfs specific patches linux-2.4.20-iget_locked.patch linux-2.4.20-vmap.patch linux-2.4.20-PF_FSTRANS.patch linux-2.4.20-delalloc.patch linux-2.4.20-intermezzo_noxfs.patch linux-2.4.20-nolock_write.patch linux-2.4.20-bswabspeedup.patch linux-2.4.20-posix_acl.patch linux-2.4.20-xfs-config.patch linux-2.4.20-xfs-sysctl.patch linux-2.4.20-xfs-exports.patch linux-2.4.20-xfs-dmapi.patch linux-2.4.20-xfs-1.2.0.patch (linux-2.4.20-xfs-nptl.patch) - applying the nptl patch results in code which doesn't compile on Redhat 7.2, so leave it out - apply these patches in order (as specified in the spec file) to the source area installed with the kernel-source package - build the kernel This method works, but I should warn you that after about a week of running under heavy load, the system crashed (kernel bug, see my previous message or Redhat bugid 98471). I have now switched to 2.4.21-ac4 (has XFS support) and will not use another Redhat kernel on this machine until either Redhat fixes this bug or goes to a 2.4.21 kernel series. I only have run for about a day with 2.4.21-ac4, but I would say that it's faster then the patched Redhat kernel. Could be that the XFS code in 2.4.21-ac4 is newer then the 1.2 release. This is very preliminary though, the machine has only been up for a day so far. Dirk From owner-linux-xfs@oss.sgi.com Thu Jul 24 07:22:53 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 24 Jul 2003 07:23:22 -0700 (PDT) Received: from opcenter.net (mail2.opcenter.net [206.165.174.15]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h6OEMqFl032354 for ; Thu, 24 Jul 2003 07:22:53 -0700 Received: from [206.165.174.40] (HELO monitor1) by opcenter.net (CommuniGate Pro SMTP 3.5.2) with ESMTP id 3171674 for linux-xfs@oss.sgi.com; Thu, 24 Jul 2003 10:22:51 -0400 From: "Michael Steinhart" Organization: OpCenter.net To: linux-xfs@oss.sgi.com Date: Thu, 24 Jul 2003 10:22:47 -0400 MIME-Version: 1.0 Subject: Re: Redhat9 XFS ISO problem. Reply-to: Michael Steinhart Message-ID: <3F1FB377.16058.3A46A59@localhost> Priority: normal In-reply-to: References: <3F1F2096.28451.168E38C@localhost> X-mailer: Pegasus Mail for Windows (v4.12a) Content-type: text/plain; charset=ISO-8859-1 Content-description: Mail message body Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from Quoted-printable to 8bit by oss.sgi.com id h6OEMsFl032356 X-archive-position: 4713 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: mike@opcenter.net Precedence: bulk X-list: linux-xfs Content-Length: 1740 Lines: 57 Lonni Thank you for your response. I have used the same set of RedHat CD’s to install RH9 on a test system using ext3 with out any problems. Mike On 24 Jul 2003 at 9:11, Net Llama! wrote: > On Wed, 23 Jul 2003, Michael Steinhart wrote: > > > > Redhat9 ISO problem. > > Super Micro 1U server > > Xeon 2.4 > > 3ware 7002 > > 2 Maxtor 160GB 7200 / 133, Raid 1 > > I am installing Redhat9 with the ISO image that I downloaded from the SGI site. I created the install > > CD. The installer booted fine and I partitioned the disk as usual. The disk formatted in XFS format > > without any problems. Then it got to the point where it was to begin installing the packages and that > > is ware the problem is. The message I get is “Please insert disk 1 to continue”. I tried > > all of the Redhat CD’s including the SGI ISO but I always get the message “Wrong > > CDROM”, “That’s not the correct SGI-XFS CDROM”. I have tried this install > > several tomes and get the same resolute. > > Any help would be appreciated. I need to get out 3 systems in the next day. > > Disk 1 is the first RH CD. Sounds like you've got a bad CD. > > -- > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~~~~~~~~ > Lonni J Friedman netllama@linux- sxs.org > Linux Step-by-step & TyGeMo http://netllama.ipfox.com ___________________________________________________________ Michael Steinhart OPCenter.net mike@opcenter.net PMH Network Services, Inc. http://www.opcenter.net 284 Ackerman Ave Emerson, NJ 07630 (201)599-2022 fax (201)599-2099 From owner-linux-xfs@oss.sgi.com Thu Jul 24 07:25:58 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 24 Jul 2003 07:26:02 -0700 (PDT) Received: from linux-sxs.org (dhcp065-024-128-253.columbus.rr.com [65.24.128.253]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h6OEPvFl000859 for ; Thu, 24 Jul 2003 07:25:58 -0700 Received: from linux-sxs.org (localhost [127.0.0.1]) by linux-sxs.org (8.12.9/8.12.9) with ESMTP id h6OEPsXu025799; Thu, 24 Jul 2003 10:25:54 -0400 Received: from localhost (netllama@localhost) by linux-sxs.org (8.12.9/8.12.9/Submit) with ESMTP id h6OEPsYa000699; Thu, 24 Jul 2003 10:25:54 -0400 Date: Thu, 24 Jul 2003 10:25:54 -0400 (EDT) From: Net Llama! To: Michael Steinhart cc: linux-xfs@oss.sgi.com Subject: Re: Redhat9 XFS ISO problem. In-Reply-To: <3F1FB377.16058.3A46A59@localhost> Message-ID: References: <3F1F2096.28451.168E38C@localhost> <3F1FB377.16058.3A46A59@localhost> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 X-Virus-Scanned: OK, scanned by File::Scan,ClamAV X-Scanned-By: MIMEDefang 2.35 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from QUOTED-PRINTABLE to 8bit by oss.sgi.com id h6OEPwFl000860 X-archive-position: 4714 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: netllama@linux-sxs.org Precedence: bulk X-list: linux-xfs Content-Length: 2216 Lines: 69 Maybe your CDROM drive is bad? Maybe the CD got damaged since it was last functional? At any rate, the XFS ISO itself isn't the problem, as i've used it, as have many others, presumably, without a problem. On Thu, 24 Jul 2003, Michael Steinhart wrote: > Lonni > > Thank you for your response. > I have used the same set of RedHat CD’s to install RH9 on a test system using ext3 > with out any problems. > > Mike > > > > On 24 Jul 2003 at 9:11, Net Llama! wrote: > > > On Wed, 23 Jul 2003, Michael Steinhart wrote: > > > > > > Redhat9 ISO problem. > > > Super Micro 1U server > > > Xeon 2.4 > > > 3ware 7002 > > > 2 Maxtor 160GB 7200 / 133, Raid 1 > > > I am installing Redhat9 with the ISO image that I > downloaded from the SGI site. I created the install > > > CD. The installer booted fine and I partitioned the disk > as usual. The disk formatted in XFS format > > > without any problems. Then it got to the point where it > was to begin installing the packages and that > > > is ware the problem is. The message I get is “Please > insert disk 1 to continue”. I tried > > > all of the Redhat CD’s including the SGI ISO but I > always get the message “Wrong > > > CDROM”, “That’s not the correct SGI-XFS > CDROM”. I have tried this install > > > several tomes and get the same resolute. > > > Any help would be appreciated. I need to get out 3 systems > in the next day. > > > > Disk 1 is the first RH CD. Sounds like you've got a bad CD. > > > > -- > > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > ~~~~~~~~ > > Lonni J Friedman netllama@linux- > sxs.org > > Linux Step-by-step & TyGeMo > http://netllama.ipfox.com > > > ___________________________________________________________ > > Michael Steinhart OPCenter.net > mike@opcenter.net PMH Network Services, Inc. > http://www.opcenter.net 284 Ackerman Ave > Emerson, NJ 07630 > (201)599-2022 > fax (201)599-2099 > > > -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Lonni J Friedman netllama@linux-sxs.org Linux Step-by-step & TyGeMo http://netllama.ipfox.com From owner-linux-xfs@oss.sgi.com Thu Jul 24 07:41:55 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 24 Jul 2003 07:42:12 -0700 (PDT) Received: from mx-01-bsl.sauter-bc.com (mx-01-bsl.sauter-bc.com [213.173.165.132]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h6OEfrFl008260 for ; Thu, 24 Jul 2003 07:41:54 -0700 Received: from mailhub.ch.sauter-bc.com (mailhub [10.1.6.26]) by mx-01-bsl.sauter-bc.com (Postfix) with ESMTP id 701044E259; Thu, 24 Jul 2003 16:41:47 +0200 (CEST) Received: from imap01.ch.sauter-bc.com (imap01.ch.sauter-bc.com [10.1.6.25]) by mailhub.ch.sauter-bc.com (Postfix) with ESMTP id E1A5D32CD0; Thu, 24 Jul 2003 16:41:45 +0200 (CEST) Received: from webmail.ch.sauter-bc.com (localhost.localdomain [127.0.0.1]) by imap01.ch.sauter-bc.com (Postfix) with SMTP id 546EE11E0D; Thu, 24 Jul 2003 16:41:45 +0200 (CEST) Received: from 213.173.165.140 (proxying for 157.161.34.15) (SquirrelMail authenticated user mattesim) by imap01.ch.sauter-bc.com with HTTP; Thu, 24 Jul 2003 16:41:45 +0200 (CEST) Message-ID: <52725.213.173.165.140.1059057705.squirrel@imap01.ch.sauter-bc.com> In-Reply-To: References: <3F1F2096.28451.168E38C@localhost> <3F1FB377.16058.3A46A59@localhost> Date: Thu, 24 Jul 2003 16:41:45 +0200 (CEST) Subject: Re: Redhat9 XFS ISO problem. From: "Simon Matter" To: "Net Llama!" Cc: "Michael Steinhart" , linux-xfs@oss.sgi.com User-Agent: SquirrelMail/1.4.1 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 Importance: Normal X-archive-position: 4715 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: simon.matter@ch.sauter-bc.com Precedence: bulk X-list: linux-xfs Content-Length: 2465 Lines: 80 > Maybe your CDROM drive is bad? Maybe the CD got damaged since it was last > functional? At any rate, the XFS ISO itself isn't the problem, as i've > used it, as have many others, presumably, without a problem. IIRC RedHat does sometimes rebuild the CD's with errata packages included. I guess the XFS installer will only work with the first version of the RedHat 9 CD. Maybe someone knows more about this. Simon > > On Thu, 24 Jul 2003, Michael Steinhart wrote: >> Lonni >> >> Thank you for your response. >> I have used the same set of RedHat CD’s to install RH9 on a test system >> using ext3 >> with out any problems. >> >> Mike >> >> >> >> On 24 Jul 2003 at 9:11, Net Llama! wrote: >> >> > On Wed, 23 Jul 2003, Michael Steinhart wrote: >> > > >> > > Redhat9 ISO problem. >> > > Super Micro 1U server >> > > Xeon 2.4 >> > > 3ware 7002 >> > > 2 Maxtor 160GB 7200 / 133, Raid 1 >> > > I am installing Redhat9 with the ISO image that I >> downloaded from the SGI site. I created the install >> > > CD. The installer booted fine and I partitioned the disk >> as usual. The disk formatted in XFS format >> > > without any problems. Then it got to the point where it >> was to begin installing the packages and that >> > > is ware the problem is. The message I get is “Please >> insert disk 1 to continue”. I tried >> > > all of the Redhat CD’s including the SGI ISO but I >> always get the message “Wrong >> > > CDROM”, “That’s not the correct SGI-XFS >> CDROM”. I have tried this install >> > > several tomes and get the same resolute. >> > > Any help would be appreciated. I need to get out 3 systems >> in the next day. >> > >> > Disk 1 is the first RH CD. Sounds like you've got a bad CD. >> > >> > -- >> > >> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ >> ~~~~~~~~ >> > Lonni J Friedman netllama@linux- >> sxs.org >> > Linux Step-by-step & TyGeMo >> http://netllama.ipfox.com >> >> >> ___________________________________________________________ >> >> Michael Steinhart OPCenter.net >> mike@opcenter.net PMH Network Services, Inc. >> http://www.opcenter.net 284 Ackerman Ave >> Emerson, NJ 07630 >> (201)599-2022 >> fax (201)599-2099 >> >> >> > > -- > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > Lonni J Friedman netllama@linux-sxs.org > Linux Step-by-step & TyGeMo http://netllama.ipfox.com > > > From owner-linux-xfs@oss.sgi.com Thu Jul 24 07:44:47 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 24 Jul 2003 07:44:50 -0700 (PDT) Received: from opcenter.net (mail2.opcenter.net [206.165.174.15]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h6OEikFl009481 for ; Thu, 24 Jul 2003 07:44:46 -0700 Received: from [206.165.174.40] (HELO monitor1) by opcenter.net (CommuniGate Pro SMTP 3.5.2) with ESMTP id 3171829; Thu, 24 Jul 2003 10:44:45 -0400 From: "Michael Steinhart" Organization: OpCenter.net To: Net Llama! Date: Thu, 24 Jul 2003 10:44:40 -0400 MIME-Version: 1.0 Subject: Re: Redhat9 XFS ISO problem. Reply-to: Michael Steinhart CC: linux-xfs@oss.sgi.com Message-ID: <3F1FB898.29401.3B864BB@localhost> Priority: normal In-reply-to: References: <3F1FB377.16058.3A46A59@localhost> X-mailer: Pegasus Mail for Windows (v4.12a) Content-type: text/html; charset=ISO-8859-1 Content-transfer-encoding: Quoted-printable Content-description: Mail message body X-archive-position: 4716 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: mike@opcenter.net Precedence: bulk X-list: linux-xfs Content-Length: 13811 Lines: 243
I = just ran the “Media Checker” from the IOC created CD on both the= IOC created CD and disk 1 of 3 from the RedHat distribution and both passed without error= s. This check was performed on the system that I am attempting to install on.

Mi= ke


= On 24 Jul 2003 at 10:25, Net Llama! wrote:

> Maybe your CDROM drive is bad?  Maybe the CD go= t damaged since it was last
> functional?  At any rate, the XFS ISO itself is= n't the problem, as i've
> used it, as have many others, presumably, without a = problem.
>
> On Thu, 24 Jul 2003, Michael Steinhart wrote:=
> > Lonni
> >
> > Thank you for your response.
> > I have used the same set of RedHat CD’s to= install RH9 on a test system using ext3
> > with out any problems.
> >
> > Mike
> >
> >
> >
> > On 24 Jul 2003 at 9:11, Net Llama! wrote:
> >
> > > On Wed, 23 Jul 2003, Michael Steinhart wro= te:
> > > > <?xml version=3D"1.0" ?&= gt;
> > > > Redhat9 ISO problem.
> > > > Super Micro 1U server
> > > > Xeon 2.4
> > > > 3ware 7002
> > > > 2 Maxtor 160GB 7200 / 133, Raid 1
> > > > I am installing Redhat9 with the ISO = image that I
> > downloaded from the SGI site. I created the ins= tall
> > > > CD. The installer booted fine and I p= artitioned the disk
> > as usual. The disk formatted in XFS format
> > > > without any problems. Then it got to = the point where it
> > was to begin installing the packages and that
> > > > is ware the problem is. The message I= get is &#147;Please
> > insert disk 1 to continue&#148;. I tried
> > > > all of the Redhat CD&#146;s inclu= ding the SGI ISO but I
> > always get the message &#147;Wrong
> > > > CDROM&#148;,  &#147;That= &#146;s not the correct SGI-XFS
> > CDROM&#148;. I have tried this install
> > > > several tomes and get the same resolu= te.
> > > > Any help would be appreciated. I need= to get out 3 systems
> > in the next day.
> > >
> > > Disk 1 is the first RH CD.  Sounds li= ke you've got a bad CD.
> > >
> > > --
> > >
> > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~= ~~~~~~~~~~~~~~~
> > ~~~~~~~~
> > > Lonni J Friedman    &#= 160;           = 0;   netllama@linux-
> > sxs.org
> > > Linux Step-by-step & TyGeMo
> > http://netllama.ipfox.com
> >
> >
> > _______________________________________________= ____________
> >
> > Michael Steinhart     =           OPCenter.net
> > mike@opcenter.net     =           PMH Network Services, Inc.
> > http://www.opcenter.net    =      284 Ackerman Ave
> >        =             &#= 160;            Emerson, NJ 07630
> >     (201)599-2022
> > fax (201)599-2099
> >
> >
> >
>
> --
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~= ~~~~~~~~~~~~~~~~~~
> Lonni J Friedman      =             &#= 160;     netllama@linux-sxs.org
> Linux Step-by-step & TyGeMo   = 60;        http://netllama.ipfox.com


= ___________________________________________________________<= /div>

= Michael Steinhart         = 60;     OPCenter.net
= mike@opcenter.net         = 60;     PMH Network Services, Inc.
= http://www.opcenter.net         28= 4 Ackerman Ave
=             &#= 160;           = 0;       Emerson, NJ 07630
=     (201)599-2022       =           
= fax (201)599-2099
From owner-linux-xfs@oss.sgi.com Thu Jul 24 09:11:25 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 24 Jul 2003 09:11:44 -0700 (PDT) Received: from tolkor.sgi.com (tolkor.SGI.COM [198.149.18.6]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h6OGBGFl019823 for ; Thu, 24 Jul 2003 09:11:24 -0700 Received: from flecktone.americas.sgi.com (flecktone.americas.sgi.com [192.48.203.135]) by tolkor.sgi.com (8.12.9/8.12.9/linux-outbound_gateway-1.1) with ESMTP id h6OGU9sR024956 for ; Thu, 24 Jul 2003 11:30:09 -0500 Received: from daisy-e236.americas.sgi.com (daisy-e236.americas.sgi.com [128.162.236.214]) by flecktone.americas.sgi.com (8.12.9/8.12.9/generic_config-1.2) with ESMTP id h6OGAI3g965846; Thu, 24 Jul 2003 11:10:18 -0500 (CDT) Received: from [128.162.232.98] (rose.americas.sgi.com [128.162.232.98]) by daisy-e236.americas.sgi.com (8.12.9/SGI-server-1.8) with ESMTP id h6OGAERn186093711; Thu, 24 Jul 2003 11:10:18 -0500 (CDT) Subject: Re: Redhat9 XFS ISO problem. From: Russell Cattelan To: Michael Steinhart Cc: linux-xfs@oss.sgi.com In-Reply-To: <3F1F2096.28451.168E38C@localhost> References: <3F1F2096.28451.168E38C@localhost> Content-Type: text/plain; charset=UTF-8 Message-Id: <1059062895.34654.59.camel@rose.americas.sgi.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.3 Date: 24 Jul 2003 11:08:15 -0500 Content-Transfer-Encoding: 8bit X-archive-position: 4717 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: cattelan@xfs.org Precedence: bulk X-list: linux-xfs Content-Length: 1992 Lines: 61 Check the .discinfo file on the RH CD it should look like this: 1047611055.799229 <- This number has to match the XFS iso Red Hat Linux 9 i386 1 RedHat/base RedHat/RPMS RedHat/pixmaps If is doesn't match then probably have a newer version of the RH cds? You have a couple of options here. Either copy all the rpms from RH cd 1-3 and the XFS installer iso into a directory that can be nfs mounted at install time. /RedHat/RPMS/ you will then need to copy the base dir from the XFS installer iso to /RedHat/base/ us the boot.iso or the flp images from the images dir on the XFS installer iso. Rebuild the XFS installer iso with the correct .discinfo. The Makefile in the rebuildme dir has a rule with the correct mkisofs cmd. Find the original RH9 cd's. On Wed, 2003-07-23 at 22:56, Michael Steinhart wrote: > Redhat9 ISO problem. > > Super Micro 1U server > Xeon 2.4 > 3ware 7002 > 2 Maxtor 160GB 7200 / 133, Raid 1 > > I am installing Redhat9 with the ISO image that I downloaded from the > SGI site. I created the install CD. The installer booted fine and I > partitioned the disk as usual. The disk formatted in XFS format > without any problems. Then it got to the point where it was to begin > installing the packages and that is ware the problem is. The message I > get is BPlease insert disk 1 to continueB. I tried all of the Redhat > CDBs including the SGI ISO but I always get the message BWrong > CDROMB, BThatBs not the correct SGI-XFS CDROMB. I have tried this > install several tomes and get the same resolute. > > Any help would be appreciated. I need to get out 3 systems in the next > day. > > Thanks in advance, > Michael Steinhart > > > > ___________________________________________________________ > Michael Steinhart OPCenter.net > mike@opcenter.net PMH Network Services, Inc. > http://www.opcenter.net 284 Ackerman Ave > Emerson, NJ 07630 From owner-linux-xfs@oss.sgi.com Thu Jul 24 09:43:15 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 24 Jul 2003 09:43:32 -0700 (PDT) Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.9/8.12.9) with ESMTP id h6OGhFFl024499 for ; Thu, 24 Jul 2003 09:43:15 -0700 Received: (from xfs@localhost) by oss.sgi.com (8.12.9/8.12.8/Submit) id h6OGhFP8024498 for linux-xfs@oss.sgi.com; Thu, 24 Jul 2003 09:43:15 -0700 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.9/8.12.9) with ESMTP id h6OGhDFn024481 for ; Thu, 24 Jul 2003 09:43:13 -0700 Received: (from apache@localhost) by oss.sgi.com (8.12.9/8.12.8/Submit) id h6OGGkKn021223; Thu, 24 Jul 2003 09:16:46 -0700 Date: Thu, 24 Jul 2003 09:16:46 -0700 Message-Id: <200307241616.h6OGGkKn021223@oss.sgi.com> From: bugzilla-daemon@oss.sgi.com To: xfs-master@oss.sgi.com Subject: [Bug 266] New: Redhat8: NFS transfers lockup server X-Bugzilla-Reason: AssignedTo X-archive-position: 4718 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: bugzilla-daemon@oss.sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 1538 Lines: 38 http://oss.sgi.com/bugzilla/show_bug.cgi?id=266 Summary: Redhat8: NFS transfers lockup server Product: Linux XFS Version: 1.2.x Platform: All OS/Version: Linux Status: NEW Severity: critical Priority: High Component: XFS kernel code AssignedTo: xfs-master@oss.sgi.com ReportedBy: darstout@hotmail.com Hello, I have a dual processor (Xeon 2.2) Gigabyte motherboard w/1MB mem running a 3ware Escalade 7500 driving 6 Maxtor 200GB hard drives. The O/S is RH8 loaded from the ISO image for XFS 1.2. The 6 drives are configured as a 1TB filesystem. I filesystem was built with the command "mkfs.xfs /dev/sda1". The NFS partner machine that I am "talking" to is a Sun 880 (2 procs/4GB mem). Everything is ok when I am transferring data from the Sun to the RH machine (over 60GB/hr) without a single error listed in /var/log/messages BUT when I try to "pull" data "from" the SUN (about 100-400GB) I will get a hang on the RH machine about half way through. There are no error messages in /var/log/messages on RH and no error messages on the Sun side. The RH machine cannot be contacted by the console or by the network. The data rates are very high (over 80GB/hr) when pulling the data. Could this be a buffer overflow somewhere? Do I have to adjust any parameters anywhere? Please help. Thank You. Darius ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From owner-linux-xfs@oss.sgi.com Thu Jul 24 10:11:04 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 24 Jul 2003 10:11:21 -0700 (PDT) Received: from andrei.myip.org (12-234-128-127.client.attbi.com [12.234.128.127]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h6OHB1Fl027307 for ; Thu, 24 Jul 2003 10:11:03 -0700 Received: by andrei.myip.org (Postfix, from userid 102) id A43DC2FA84; Thu, 24 Jul 2003 10:11:00 -0700 (PDT) Received: from stantz.corp.sgi.com (unknown [130.62.4.42]) by andrei.myip.org (Postfix) with ESMTP id 7CB972FA81 for ; Thu, 24 Jul 2003 10:10:54 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by stantz.corp.sgi.com (Postfix) with ESMTP id 30EF61967C for ; Thu, 24 Jul 2003 10:10:39 -0700 (PDT) Subject: Re: kernel bug in rmap.c:398 From: Florin Andrei Reply-To: linux-xfs@oss.sgi.com To: linux-xfs In-Reply-To: <3F1F1F9B.3080403@mps.ohio-state.edu> References: <3F1ED8B0.5040407@mps.ohio-state.edu> <1059002109.2169.23.camel@stantz.corp.sgi.com> <3F1F1F9B.3080403@mps.ohio-state.edu> Content-Type: text/plain Organization: SGI Message-Id: <1059066638.13886.3.camel@stantz.corp.sgi.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.3 (1.4.3-1) Date: 24 Jul 2003 10:10:38 -0700 Content-Transfer-Encoding: 7bit X-archive-position: 4719 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: florin@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 499 Lines: 20 On Wed, 2003-07-23 at 16:51, Dirk Hufnagel wrote: > Florin Andrei wrote: > > On Wed, 2003-07-23 at 11:49, Dirk Hufnagel wrote: > > > > > kernel BUG at rmap.c:398! > > > > I've seen this bug reported on Red Hat mailing lists, by people running > > non-XFS RH kernels. > > So, it's not XFS. > > Do you remember from these bug reports on redhat > mailing lists if there was a fix or workaround ? Don't remember, sorry. -- Florin Andrei "Never send a human to do a machine's job." - Agent Smith From owner-linux-xfs@oss.sgi.com Thu Jul 24 10:43:15 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 24 Jul 2003 10:43:28 -0700 (PDT) Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.9/8.12.9) with ESMTP id h6OHhFFl029196 for ; Thu, 24 Jul 2003 10:43:15 -0700 Received: (from xfs@localhost) by oss.sgi.com (8.12.9/8.12.8/Submit) id h6OHhFsK029194 for linux-xfs@oss.sgi.com; Thu, 24 Jul 2003 10:43:15 -0700 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.9/8.12.9) with ESMTP id h6OHhDFn029178 for ; Thu, 24 Jul 2003 10:43:14 -0700 Received: (from apache@localhost) by oss.sgi.com (8.12.9/8.12.8/Submit) id h6OH3Mf3026712; Thu, 24 Jul 2003 10:03:22 -0700 Date: Thu, 24 Jul 2003 10:03:22 -0700 Message-Id: <200307241703.h6OH3Mf3026712@oss.sgi.com> From: bugzilla-daemon@oss.sgi.com To: xfs-master@oss.sgi.com Subject: [Bug 266] Redhat8: NFS transfers lockup server X-Bugzilla-Reason: AssignedTo X-archive-position: 4720 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: bugzilla-daemon@oss.sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 721 Lines: 23 http://oss.sgi.com/bugzilla/show_bug.cgi?id=266 ------- Additional Comments From hufnagel@mps.ohio-state.edu 2003-24-07 10:03 PDT ------- Do you use a Broadcom Gigabit NIC with the tg3 driver ? (3Com Gigabit NICs use Broadcom chips for instance) The tg3 driver was broken (redhat bugid 69920 and 78059) in almost all the 2.4.18 Redhat kernels. I have seen exactly the same problem as you described on a dual athlon with Broadcom Gigabit NIC, NFS transfers would crash the machine w/o leaving any error message in the logs. The 2.4.18-27 kernel fixed the issue. 2.4.20 kernels will work too. ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From owner-linux-xfs@oss.sgi.com Thu Jul 24 10:59:36 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 24 Jul 2003 10:59:40 -0700 (PDT) Received: from opcenter.net (mail2.opcenter.net [206.165.174.15]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h6OHxZFl030460 for ; Thu, 24 Jul 2003 10:59:36 -0700 Received: from [206.165.174.40] (HELO monitor1) by opcenter.net (CommuniGate Pro SMTP 3.5.2) with ESMTP id 3173030; Thu, 24 Jul 2003 13:59:34 -0400 From: "Michael Steinhart" Organization: OpCenter.net To: Russell Cattelan Date: Thu, 24 Jul 2003 13:59:33 -0400 MIME-Version: 1.0 Subject: Re: Redhat9 XFS ISO problem. Reply-to: Michael Steinhart CC: linux-xfs@oss.sgi.com Message-ID: <3F1FE645.16535.46A0937@localhost> Priority: normal In-reply-to: <1059062895.34654.59.camel@rose.americas.sgi.com> References: <3F1F2096.28451.168E38C@localhost> X-mailer: Pegasus Mail for Windows (v4.12a) Content-type: text/html; charset=US-ASCII Content-transfer-encoding: 7BIT Content-description: Mail message body X-archive-position: 4721 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: mike@opcenter.net Precedence: bulk X-list: linux-xfs Content-Length: 12893 Lines: 127
Thank you, this appears to be the problem.

The .discinfo file on the RedHat CD is dated 02/27/2003  5:20 PM:


1046386286.563933
Red Hat Linux 9
i386
1
RedHat/base
RedHat/RPMS
RedHat/pixmaps

I found in the MAKEFILE the entry for CDVER:

CDVERS          = "1047611055.799229\nRed Hat Linux 9\ni386\n4\nRedHat/base\nRedHat/RPMS\nRedHat/pixmaps\n"

I would like to create a new ISO image with the correct version ID.

Any tips on how to accomplish this.

Mike


On 24 Jul 2003 at 11:08, Russell Cattelan wrote:

> Check the .discinfo file on the RH CD
> it should look like this:
> 1047611055.799229  <- This number has to match the XFS iso
> Red Hat Linux 9
> i386
> 1
> RedHat/base
> RedHat/RPMS
> RedHat/pixmaps
>
> If is doesn't match then probably have a newer version of
> the RH cds?
>
> You have a couple of options here.
>
> Either copy all the rpms from RH cd 1-3 and the XFS installer iso into a
> directory that can be nfs mounted at install time.
> <nfs exported dir>/RedHat/RPMS/
> you will then need to copy the base dir from the XFS installer iso to
> <nfs exported dir>/RedHat/base/
> us the boot.iso or the flp images from the images dir on the XFS
> installer iso.
>
> Rebuild the XFS installer iso with the correct .discinfo.
> The Makefile in the rebuildme dir has a rule with the correct
> mkisofs cmd.
>
> Find the original RH9 cd's.
>
> On Wed, 2003-07-23 at 22:56, Michael Steinhart wrote:
> > Redhat9 ISO problem.
> >
> > Super Micro 1U server
> > Xeon 2.4
> > 3ware 7002
> > 2 Maxtor 160GB 7200 / 133, Raid 1
> >
> > I am installing Redhat9 with the ISO image that I downloaded from the
> > SGI site. I created the install CD. The installer booted fine and I
> > partitioned the disk as usual. The disk formatted in XFS format
> > without any problems. Then it got to the point where it was to begin
> > installing the packages and that is ware the problem is. The message I
> > get is B Please insert disk 1 to continueB . I tried all of the Redhat
> > CDB s including the SGI ISO but I always get the message B Wrong
> > CDROMB ,  B ThatB s not the correct SGI-XFS CDROMB . I have tried this
> > install several tomes and get the same resolute.
> >
> > Any help would be appreciated. I need to get out 3 systems in the next
> > day.
> >
> > Thanks in advance,
> > Michael Steinhart
> >
> >
> >
> > ___________________________________________________________
> > Michael Steinhart                OPCenter.net
> > mike@opcenter.net                PMH Network Services, Inc.
> > http://www.opcenter.net          284 Ackerman Ave
> >                                  Emerson, NJ 07630
>


___________________________________________________________

Michael Steinhart               OPCenter.net
mike@opcenter.net               PMH Network Services, Inc.
http://www.opcenter.net         284 Ackerman Ave
                                Emerson, NJ 07630
    (201)599-2022                 
fax (201)599-2099
From owner-linux-xfs@oss.sgi.com Thu Jul 24 18:34:03 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 24 Jul 2003 18:34:45 -0700 (PDT) Received: from kauri.itee.uq.edu.au (kauri.itee.uq.edu.au [130.102.66.24]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h6P1Y1Fl025958 for ; Thu, 24 Jul 2003 18:34:03 -0700 Received: from nut.itee.uq.edu.au (nut.itee.uq.edu.au [130.102.66.13]) by kauri.itee.uq.edu.au (8.12.9/8.12.9) with ESMTP id h6P1Xv1f015033 for ; Fri, 25 Jul 2003 11:33:57 +1000 (EST) Received: from SPIKE (spike.itee.uq.edu.au [130.102.66.71]) by nut.itee.uq.edu.au (8.12.9/8.12.9) with SMTP id h6P1XvY3019429 for ; Fri, 25 Jul 2003 11:33:57 +1000 (EST) Message-ID: <00a601c3524c$d4b4d9c0$47426682@itee.uq.edu.au> From: "Chris Pascoe" To: "XFS Mailing List" References: <1051673906.6802.18.camel@pip> Subject: Re: raid5: switching cache buffer size Date: Fri, 25 Jul 2003 11:34:03 +1000 MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Spam-Checked: This message probably not SPAM X-Spam-Score: -2 X-Spam-Tests: EMAIL_ATTRIBUTION,QUOTED_EMAIL_TEXT,REFERENCES,REPLY_WITH_QUOTES X-Scanned-By: MIMEDefang 2.35 X-archive-position: 4722 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: c.pascoe@itee.uq.edu.au Precedence: bulk X-list: linux-xfs Content-Length: 636 Lines: 18 > On Tue, 2003-04-29 at 18:24, Daryl Herzmann wrote: > > Apr 29 17:15:48 zzz kernel: raid5: switching cache buffer size, > > 4096 --> 512 > > Apr 29 17:15:48 zzz kernel: raid5: switching cache buffer size, > > 512 --> 4096 Danny Cox writes: > As to why you're just seeing this now, I haven't a clue :-(. The writes to the superblock and AGF areas (at least) are still done as 512 byte writes. I don't know if it is possible to change these last few cases - the superblock and AGF areas are only 512 bytes long (on my filesystem), for example. Presumably another on-disk format change would be required to work around this. Chris From owner-linux-xfs@oss.sgi.com Thu Jul 24 20:26:37 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 24 Jul 2003 20:26:52 -0700 (PDT) Received: from tolkor.sgi.com (tolkor.SGI.COM [198.149.18.6]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h6P3QaFl028164 for ; Thu, 24 Jul 2003 20:26:37 -0700 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.54.149]) by tolkor.sgi.com (8.12.9/8.12.9/linux-outbound_gateway-1.1) with ESMTP id h6P3jUsR019919 for ; Thu, 24 Jul 2003 22:45:31 -0500 Received: from snort.melbourne.sgi.com (localhost [127.0.0.1]) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id h6P3QTJA6468041 for ; Fri, 25 Jul 2003 13:26:29 +1000 (EST) Received: (from nathans@localhost) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id h6P3QSk36469077 for linux-xfs@oss.sgi.com; Fri, 25 Jul 2003 13:26:28 +1000 (EST) Date: Fri, 25 Jul 2003 13:26:28 +1000 (EST) From: Nathan Scott Message-Id: <200307250326.h6P3QSk36469077@snort.melbourne.sgi.com> To: linux-xfs@oss.sgi.com Subject: TAKE - xfsprogs X-archive-position: 4723 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: nathans@snort.melbourne.sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 1738 Lines: 53 xfs_copy(8) is now usable and installed as part of xfsprogs. Date: Tue Jul 22 17:43:47 PDT 2003 Workarea: snort.melbourne.sgi.com:/home/nathans/2.5.x-xfs The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.5.x-xfs Modid: xfs-cmds:slinx:154035a cmd/xfsprogs/Makefile - 1.20 cmd/xfsprogs/VERSION - 1.84 cmd/xfsprogs/doc/CHANGES - 1.119 cmd/xfsprogs/debian/changelog - 1.76 cmd/xfsdump/Makefile - 1.16 xfsdump/copy/xfs_copy.8 1.3 renamed to xfsprogs/man/man8/xfs_copy.8 1.1 xfsdump/copy/xfs_copy.c 1.18 renamed to xfsprogs/copy/xfs_copy.c 1.1 xfsdump/copy/Makefile 1.11 renamed to xfsprogs/copy/Makefile 1.1 xfsdump/copy/xfs_copy.h 1.3 renamed to xfsprogs/copy/xfs_copy.h 1.1 - Move xfs_copy into xfsprogs, build and install it too. Reasons for it being in xfsdump package are no longer there, and its a libxfs user so keep it with the rest of them. Date: Thu Jul 24 20:14:10 PDT 2003 Workarea: snort.melbourne.sgi.com:/home/nathans/2.5.x-xfs The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.5.x-xfs Modid: xfs-cmds:slinx:154276a cmd/xfsprogs/doc/CHANGES - 1.120 cmd/xfsprogs/debian/changelog - 1.77 - Update for new xfsprogs version. cmd/xfsprogs/include/libxfs.h - 1.29 cmd/xfsprogs/libxfs/rdwr.c - 1.21 - Change log writing routines so that they can be used by xfs_copy too (which needs to do all IO itself). cmd/xfsprogs/io/xfs_bmap.sh - 1.4 - Fix whitespace handling. cmd/xfsprogs/copy/xfs_copy.h - 1.2 cmd/xfsprogs/copy/xfs_copy.c - 1.2 - Write the log directly instead of calling xfs_db, fix UUID mismanagement so that all target devices have different identifiers, add code to detect when a too-small target device has been specified. From owner-linux-xfs@oss.sgi.com Fri Jul 25 03:31:01 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 25 Jul 2003 03:31:21 -0700 (PDT) Received: from firewall.vis.co.za ([196.14.178.245]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h6PAUsFl013979 for ; Fri, 25 Jul 2003 03:30:59 -0700 Received: (from nobody@localhost) by firewall.vis.co.za (8.8.8/8.6.9) id MAA14708 for ; Fri, 25 Jul 2003 12:30:50 +0200 (SAST) Received: by firewall.vis.co.za via recvmail id 14665; Fri, 25 Jul 2003 12:30:11 +0200 (SAST) Message-ID: Date: Fri, 25 Jul 2003 12:30:08 +0200 From: Douw Steyn Organization: Visual Information Systems X-Mailer: Mozilla 4.76 [en] (X11; U; FreeBSD 4.8-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: linux-xfs@oss.sgi.com Subject: Moving an SGI XFS raid array to Linux Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-scanner: scanned by Inflex 0.1.5 - (http://www.inflex.co.za/) X-archive-position: 4724 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: douw@vis.co.za Precedence: bulk X-list: linux-xfs Content-Length: 500 Lines: 18 Hi, I have an external hardware raid array attached to an SGI O2. To the O2 it appears to be a single SCSI disk formatted with XFS (under IRIX). I want to move the raid array to a Linux box (generic Intel PC) running Red Hat 9. Can I mount and use this disk as is on my Linux box, or will I need to reformat it under Linux/XFS. Thanks for any help. Regards, Douw. -- Douw Steyn - Visual Information Systems, Cape Town, South Africa Phone 27-21-5119393, Fax 27-21-5119718, email: douw@vis.co.za From owner-linux-xfs@oss.sgi.com Fri Jul 25 04:58:03 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 25 Jul 2003 04:58:24 -0700 (PDT) Received: from flood.physik.tu-cottbus.de (flood.physik.TU-Cottbus.De [141.43.75.21]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h6PBw2Fl017918 for ; Fri, 25 Jul 2003 04:58:03 -0700 Received: from emmy.physik.tu-cottbus.de (emmy.physik.tu-cottbus.de [141.43.75.40]) by flood.physik.tu-cottbus.de (Postfix) with ESMTP id 50E15701E00; Fri, 25 Jul 2003 13:58:01 +0200 (CEST) Received: by emmy.physik.tu-cottbus.de (Postfix, from userid 7224) id EF304181A0F; Fri, 25 Jul 2003 13:58:00 +0200 (CEST) Subject: Re: Moving an SGI XFS raid array to Linux From: Ionut Georgescu To: Douw Steyn Cc: linux-xfs@oss.sgi.com In-Reply-To: References: Content-Type: text/plain Content-Transfer-Encoding: 7bit Message-Id: <1059134280.20472.3.camel@localhost> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.3 Date: 25 Jul 2003 13:58:00 +0200 X-archive-position: 4725 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: george@physik.tu-cottbus.de Precedence: bulk X-list: linux-xfs Content-Length: 824 Lines: 29 Just make sure your kernel has support for SGI partitions compiled in. No, you don't need to reformat the disk under Linux. Ionut On Fri, 2003-07-25 at 12:30, Douw Steyn wrote: > Hi, > > I have an external hardware raid array attached to an SGI O2. To the > O2 it appears to be a single SCSI disk formatted with XFS (under > IRIX). I want to move the raid array to a Linux box (generic Intel PC) > running Red Hat 9. > > Can I mount and use this disk as is on my Linux box, or will I need to > reformat it under Linux/XFS. > > Thanks for any help. > Regards, > Douw. -- *************** * Ionut Georgescu * http://www.physik.tu-cottbus.de/~george/ * Registered Linux User #244479 * * "In Windows you can do everything Microsoft wants you to do; in Unix * you can do anything the computer is able to do." From owner-linux-xfs@oss.sgi.com Fri Jul 25 05:14:12 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 25 Jul 2003 05:14:30 -0700 (PDT) Received: from zok.sgi.com (zok.SGI.COM [204.94.215.101]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h6PCE6Fl019104 for ; Fri, 25 Jul 2003 05:14:06 -0700 Received: from flecktone.americas.sgi.com (flecktone.americas.sgi.com [192.48.203.135]) by zok.sgi.com (8.12.9/8.12.9/linux-outbound_gateway-1.1) with ESMTP id h6PCE1q0011550 for ; Fri, 25 Jul 2003 05:14:01 -0700 Received: from daisy-e236.americas.sgi.com (daisy-e236.americas.sgi.com [128.162.236.214]) by flecktone.americas.sgi.com (8.12.9/8.12.9/generic_config-1.2) with ESMTP id h6PCCwQK1351063; Fri, 25 Jul 2003 07:12:58 -0500 (CDT) Received: from dhcp910.linuxsymposium.org (cf-vpn-sw-corp-64-70.corp.sgi.com [134.15.64.70]) by daisy-e236.americas.sgi.com (8.12.9/SGI-server-1.8) with ESMTP id h6PCCtRn173345454; Fri, 25 Jul 2003 07:12:57 -0500 (CDT) Subject: Re: Moving an SGI XFS raid array to Linux From: Steve Lord To: Douw Steyn Cc: linux-xfs@oss.sgi.com In-Reply-To: References: Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.8 (1.0.8-11) Date: 25 Jul 2003 07:12:52 -0500 Message-Id: <1059135175.3094.19.camel@localhost.localdomain> Mime-Version: 1.0 X-archive-position: 4726 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: lord@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 1126 Lines: 32 On Fri, 2003-07-25 at 05:30, Douw Steyn wrote: > Hi, > > I have an external hardware raid array attached to an SGI O2. To the > O2 it appears to be a single SCSI disk formatted with XFS (under > IRIX). I want to move the raid array to a Linux box (generic Intel PC) > running Red Hat 9. > > Can I mount and use this disk as is on my Linux box, or will I need to > reformat it under Linux/XFS. Depends on a few things, the blocksize, the size of the device and the format of the directories. A filesystem blocksize of over 4K will not work on ia32, 4K is the default on Irix, so this should be OK. 2T bytes is the device size limit on linux - without some large patches in 2.4. You can deal with this in 2.6 though. Directory format, xfs has 2, v1 and v2. Chances are, if your filesystem is older, it is v1. Linux has problems with this and the code in the tree now is broken - I posted a patch to fix it a few days ago. Finally, the filesystem log, you will need to zero out the log as they are not compatible between big and little endian boxes. Do a clean unmount on Irix, then run xfs_repair -L on linux. Steve From owner-linux-xfs@oss.sgi.com Fri Jul 25 05:43:19 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 25 Jul 2003 05:43:37 -0700 (PDT) Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.9/8.12.9) with ESMTP id h6PChJFl020950 for ; Fri, 25 Jul 2003 05:43:19 -0700 Received: (from xfs@localhost) by oss.sgi.com (8.12.9/8.12.8/Submit) id h6PChJtW020949 for linux-xfs@oss.sgi.com; Fri, 25 Jul 2003 05:43:19 -0700 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.9/8.12.9) with ESMTP id h6PChHFn020932 for ; Fri, 25 Jul 2003 05:43:17 -0700 Received: (from apache@localhost) by oss.sgi.com (8.12.9/8.12.8/Submit) id h6PC0QZ8018467; Fri, 25 Jul 2003 05:00:26 -0700 Date: Fri, 25 Jul 2003 05:00:26 -0700 Message-Id: <200307251200.h6PC0QZ8018467@oss.sgi.com> From: bugzilla-daemon@oss.sgi.com To: xfs-master@oss.sgi.com Subject: [Bug 267] New: pwrite64 failed on 1.2 TB evms volume X-Bugzilla-Reason: AssignedTo X-archive-position: 4727 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: bugzilla-daemon@oss.sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 1274 Lines: 35 http://oss.sgi.com/bugzilla/show_bug.cgi?id=267 Summary: pwrite64 failed on 1.2 TB evms volume Product: Linux XFS Version: 1.2.x Platform: All OS/Version: Linux Status: NEW Severity: blocker Priority: High Component: xfsprogs AssignedTo: xfs-master@oss.sgi.com ReportedBy: Jan@vmlinuz.be when trying to create a filesystem on a 1.2 TB volume (created with evms, but also with fdisk) I get an error : ---SNIP---192-168-5-65/24 root # mkfs.xfs -f /dev/evms/SYSTEM meta-data=/dev/evms/SYSTEM isize=256 agcount=4294967077, agsize=1048576 blks = sectsz=512 data = bsize=4096 blocks=4503599396890350, imaxpct=0 = sunit=0 swidth=0 blks, unwritten=0 naming =version 2 bsize=4096 log =internal log bsize=4096 blocks=32768, version=1 = sectsz=512 sunit=0 blks realtime =none extsz=65536 blocks=0, rtextents=0 mkfs.xfs: pwrite64 failed: Invalid argument ---SNAP--- ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From owner-linux-xfs@oss.sgi.com Fri Jul 25 08:37:58 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 25 Jul 2003 08:38:29 -0700 (PDT) Received: from zok.sgi.com (zok.SGI.COM [204.94.215.101]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h6PFbvFl028272 for ; Fri, 25 Jul 2003 08:37:58 -0700 Received: from flecktone.americas.sgi.com (flecktone.americas.sgi.com [192.48.203.135]) by zok.sgi.com (8.12.9/8.12.9/linux-outbound_gateway-1.1) with ESMTP id h6PFbqq0008337 for ; Fri, 25 Jul 2003 08:37:52 -0700 Received: from maine.americas.sgi.com (maine.americas.sgi.com [128.162.232.87]) by flecktone.americas.sgi.com (8.12.9/8.12.9/generic_config-1.2) with ESMTP id h6PFapQK1423924 for ; Fri, 25 Jul 2003 10:36:51 -0500 (CDT) Received: from nstraz by maine.americas.sgi.com with local (Exim 3.36 #1 (Debian)) id 19g4cl-0000iQ-00 for ; Fri, 25 Jul 2003 10:36:51 -0500 Date: Fri, 25 Jul 2003 10:36:51 -0500 From: Nathan Straz To: linux-xfs@oss.sgi.com Subject: Re: [Bug 267] New: pwrite64 failed on 1.2 TB evms volume Message-ID: <20030725153651.GB1160@sgi.com> Mail-Followup-To: linux-xfs@oss.sgi.com References: <200307251200.h6PC0QZ8018467@oss.sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200307251200.h6PC0QZ8018467@oss.sgi.com> User-Agent: Mutt/1.5.3i X-archive-position: 4728 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: nstraz@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 1500 Lines: 31 On Fri, Jul 25, 2003 at 05:00:26AM -0700, bugzilla-daemon@oss.sgi.com wrote: > when trying to create a filesystem on a 1.2 TB volume (created with evms, but > also with fdisk) I get an error : > ---SNIP---192-168-5-65/24 root # mkfs.xfs -f /dev/evms/SYSTEM > meta-data=/dev/evms/SYSTEM isize=256 agcount=4294967077, agsize=1048576 > blks > = sectsz=512 > data = bsize=4096 blocks=4503599396890350, imaxpct=0 > = sunit=0 swidth=0 blks, unwritten=0 > naming =version 2 bsize=4096 > log =internal log bsize=4096 blocks=32768, version=1 > = sectsz=512 sunit=0 blks > realtime =none extsz=65536 blocks=0, rtextents=0 > mkfs.xfs: pwrite64 failed: Invalid argument > ---SNAP--- I would wager that this is a bug in EVMS. You file system is ~1319413953331 bytes. You're trying to create a file system with 4503599396890350 4k blocks. That's much bigger than you're device. Perhaps EVMS isn't reporting the size of the device correctly. Try running `strace mkfs.xfs -f /dev/evms/SYSTEM` and add the output to the bug. BTW, why use EVMS? IIRC, it was discontinued after it lost the race for 2.5. -- Nate Straz nstraz@sgi.com sgi, inc http://www.sgi.com/ Linux Test Project http://ltp.sf.net/ From owner-linux-xfs@oss.sgi.com Fri Jul 25 08:43:20 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 25 Jul 2003 08:43:22 -0700 (PDT) Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.9/8.12.9) with ESMTP id h6PFhKFl029005 for ; Fri, 25 Jul 2003 08:43:20 -0700 Received: (from xfs@localhost) by oss.sgi.com (8.12.9/8.12.8/Submit) id h6PFhK4o029003 for linux-xfs@oss.sgi.com; Fri, 25 Jul 2003 08:43:20 -0700 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.9/8.12.9) with ESMTP id h6PFhIFp028975 for ; Fri, 25 Jul 2003 08:43:18 -0700 Received: (from apache@localhost) by oss.sgi.com (8.12.9/8.12.8/Submit) id h6PEiNJh025657; Fri, 25 Jul 2003 07:44:23 -0700 Date: Fri, 25 Jul 2003 07:44:23 -0700 Message-Id: <200307251444.h6PEiNJh025657@oss.sgi.com> From: bugzilla-daemon@oss.sgi.com To: xfs-master@oss.sgi.com Subject: [Bug 267] pwrite64 failed on 1.2 TB evms volume X-Bugzilla-Reason: AssignedTo X-archive-position: 4729 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: bugzilla-daemon@oss.sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 346 Lines: 17 http://oss.sgi.com/bugzilla/show_bug.cgi?id=267 ------- Additional Comments From sandeen@sgi.com 2003-25-07 07:44 PDT ------- Can you try the latest userspace, and possibly a more recent (1.3preX or CVS) kernel? -Eric ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From owner-linux-xfs@oss.sgi.com Fri Jul 25 08:43:20 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 25 Jul 2003 08:43:30 -0700 (PDT) Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.9/8.12.9) with ESMTP id h6PFhKFl029004 for ; Fri, 25 Jul 2003 08:43:20 -0700 Received: (from xfs@localhost) by oss.sgi.com (8.12.9/8.12.8/Submit) id h6PFhKmX029002 for linux-xfs@oss.sgi.com; Fri, 25 Jul 2003 08:43:20 -0700 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.9/8.12.9) with ESMTP id h6PFhIFr028975 for ; Fri, 25 Jul 2003 08:43:18 -0700 Received: (from apache@localhost) by oss.sgi.com (8.12.9/8.12.8/Submit) id h6PFQ8XE027565; Fri, 25 Jul 2003 08:26:08 -0700 Date: Fri, 25 Jul 2003 08:26:08 -0700 Message-Id: <200307251526.h6PFQ8XE027565@oss.sgi.com> From: bugzilla-daemon@oss.sgi.com To: xfs-master@oss.sgi.com Subject: [Bug 267] pwrite64 failed on 1.2 TB evms volume X-Bugzilla-Reason: AssignedTo X-archive-position: 4730 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: bugzilla-daemon@oss.sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 717 Lines: 24 http://oss.sgi.com/bugzilla/show_bug.cgi?id=267 cattelan@thebarn.com changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |ASSIGNED ------- Additional Comments From cattelan@thebarn.com 2003-25-07 08:26 PDT ------- It appears as if there is a disconnect beween what evms is reporting for the size of the partion and what mkfs is getting. 4503599396890350 probably isn't correct :-) try strace'ing the mkfs cmd and add it as an attactment to this bug. ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From owner-linux-xfs@oss.sgi.com Fri Jul 25 10:43:20 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 25 Jul 2003 10:43:38 -0700 (PDT) Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.9/8.12.9) with ESMTP id h6PHhKFl004888 for ; Fri, 25 Jul 2003 10:43:20 -0700 Received: (from xfs@localhost) by oss.sgi.com (8.12.9/8.12.8/Submit) id h6PHhKEj004887 for linux-xfs@oss.sgi.com; Fri, 25 Jul 2003 10:43:20 -0700 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.9/8.12.9) with ESMTP id h6PHhIFn004872 for ; Fri, 25 Jul 2003 10:43:19 -0700 Received: (from apache@localhost) by oss.sgi.com (8.12.9/8.12.8/Submit) id h6PGxx1s002163; Fri, 25 Jul 2003 09:59:59 -0700 Date: Fri, 25 Jul 2003 09:59:59 -0700 Message-Id: <200307251659.h6PGxx1s002163@oss.sgi.com> From: bugzilla-daemon@oss.sgi.com To: xfs-master@oss.sgi.com Subject: [Bug 268] New: linux 2.6.0-test1-mm1 with RAID 0 XFS internal error during delete X-Bugzilla-Reason: AssignedTo X-archive-position: 4731 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: bugzilla-daemon@oss.sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 1966 Lines: 57 http://oss.sgi.com/bugzilla/show_bug.cgi?id=268 Summary: linux 2.6.0-test1-mm1 with RAID 0 XFS internal error during delete Product: Linux XFS Version: Current Platform: IA32 OS/Version: Linux Status: NEW Severity: normal Priority: High Component: XFS kernel code AssignedTo: xfs-master@oss.sgi.com ReportedBy: ward@speakeasy.net With MD style RAID 0 devices under linux 2.6.0-test1-mm1, twice on different devices I've had an XFS internal error occur. The filesystem operation just before the error in both cases was a delete. XFS internal error XFS_WANT_CORRUPTED_GOTO at line 1596 of file fs/xfs/xfs_alloc.c. Caller 0xc01b9ac5 Call Trace: [] xfs_free_ag_extent+0x457/0x760 [] xfs_free_extent+0xe5/0x110 [] xlog_grant_push_ail+0x4d/0x190 [] xfs_free_extent+0xe5/0x110 [] xfs_dir_leaf_add+0x13f/0x190 [] xfs_trans_reserve+0x78/0x1b0 [] xfs_trans_get_efd+0x38/0x50 [] xfs_bmap_finish+0x138/0x1d0 [] xfs_itruncate_finish+0x213/0x440 [] xfs_inactive+0x52b/0x590 [] vn_rele+0x91/0xa0 [] linvfs_clear_inode+0x18/0x30 [] clear_inode+0xc6/0xe0 [] generic_delete_inode+0xf8/0x130 [] iput+0x55/0x80 [] sys_unlink+0x122/0x150 [] syscall_call+0x7/0xb xfs_force_shutdown(md0,0x8) called from line 4051 of file fs/xfs/xfs_bmap.c. Return address = 0xc0221f4b Filesystem "md0": Corruption of in-memory data detected. Shutting down filesystem: md0 Please umount the filesystem, and rectify the problem(s) XFS mounting filesystem md0 Starting XFS recovery on filesystem: md0 (dev: 9/0) Ending XFS recovery on filesystem: md0 (dev: 9/0) ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From owner-linux-xfs@oss.sgi.com Fri Jul 25 12:43:21 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 25 Jul 2003 12:43:37 -0700 (PDT) Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.9/8.12.9) with ESMTP id h6PJhLFl018179 for ; Fri, 25 Jul 2003 12:43:21 -0700 Received: (from xfs@localhost) by oss.sgi.com (8.12.9/8.12.8/Submit) id h6PJhLXL018177 for linux-xfs@oss.sgi.com; Fri, 25 Jul 2003 12:43:21 -0700 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.9/8.12.9) with ESMTP id h6PJhJFn018161 for ; Fri, 25 Jul 2003 12:43:19 -0700 Received: (from apache@localhost) by oss.sgi.com (8.12.9/8.12.8/Submit) id h6PJIx8Y012560; Fri, 25 Jul 2003 12:18:59 -0700 Date: Fri, 25 Jul 2003 12:18:59 -0700 Message-Id: <200307251918.h6PJIx8Y012560@oss.sgi.com> From: bugzilla-daemon@oss.sgi.com To: xfs-master@oss.sgi.com Subject: [Bug 268] linux 2.6.0-test1-mm1 with RAID 0 XFS internal error during delete X-Bugzilla-Reason: AssignedTo X-archive-position: 4732 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: bugzilla-daemon@oss.sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 289 Lines: 15 http://oss.sgi.com/bugzilla/show_bug.cgi?id=268 ------- Additional Comments From lord@sgi.com 2003-25-07 12:18 PDT ------- Can you post your raid config please? ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From owner-linux-xfs@oss.sgi.com Fri Jul 25 14:47:51 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 25 Jul 2003 14:48:10 -0700 (PDT) Received: from zok.sgi.com (zok.SGI.COM [204.94.215.101]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h6PLlnFl027859 for ; Fri, 25 Jul 2003 14:47:51 -0700 Received: from flecktone.americas.sgi.com (flecktone.americas.sgi.com [192.48.203.135]) by zok.sgi.com (8.12.9/8.12.9/linux-outbound_gateway-1.1) with ESMTP id h6PLlgq0002990 for ; Fri, 25 Jul 2003 14:47:44 -0700 Received: from daisy-e236.americas.sgi.com (daisy-e236.americas.sgi.com [128.162.236.214]) by flecktone.americas.sgi.com (8.12.9/8.12.9/generic_config-1.2) with ESMTP id h6PLkfQK1537328 for ; Fri, 25 Jul 2003 16:46:42 -0500 (CDT) Received: from [128.162.232.98] (rose.americas.sgi.com [128.162.232.98]) by daisy-e236.americas.sgi.com (8.12.9/SGI-server-1.8) with ESMTP id h6PLkfRn194326573 for ; Fri, 25 Jul 2003 16:46:41 -0500 (CDT) Subject: ANNOUNCE XFS 1.3.0pre4 From: Russell Cattelan To: linux-xfs@oss.sgi.com Content-Type: text/plain Message-Id: <1059169471.34654.113.camel@rose.americas.sgi.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.3 Date: 25 Jul 2003 16:44:32 -0500 Content-Transfer-Encoding: 7bit X-archive-position: 4733 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: cattelan@xfs.org Precedence: bulk X-list: linux-xfs Content-Length: 675 Lines: 25 The 1.3.0 pre4 patches and latest RH9 errata kernel rpms are available at: ftp://oss.sgi.com/projects/xfs/Release-1.3/pre4/ The 1.3 xfs-cmds have also been updated to TOT xfs-cmds, since there is no real reason not to bring them in sync. In other works no major code changes, just a lot of cleanups and minor bug fixes. One significant update: xfs_copy is now installed by default. The kernel rpm's themselves have not had much testing so use at your own risk. As far as the xfs codes goes, it goes through nightly regression testing. As always please let us know of any issues. If things go well pre4 should probably turn into actual XFS 1.3.0 -Russell Cattelan From owner-linux-xfs@oss.sgi.com Fri Jul 25 15:14:10 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 25 Jul 2003 15:14:27 -0700 (PDT) Received: from zok.sgi.com (zok.SGI.COM [204.94.215.101]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h6PMEAFl030505 for ; Fri, 25 Jul 2003 15:14:10 -0700 Received: from flecktone.americas.sgi.com (flecktone.americas.sgi.com [192.48.203.135]) by zok.sgi.com (8.12.9/8.12.9/linux-outbound_gateway-1.1) with ESMTP id h6PME4q0007078 for ; Fri, 25 Jul 2003 15:14:04 -0700 Received: from daisy-e236.americas.sgi.com (daisy-e236.americas.sgi.com [128.162.236.214]) by flecktone.americas.sgi.com (8.12.9/8.12.9/generic_config-1.2) with ESMTP id h6PME3QK1546624; Fri, 25 Jul 2003 17:14:03 -0500 (CDT) Received: from [128.162.232.98] (rose.americas.sgi.com [128.162.232.98]) by daisy-e236.americas.sgi.com (8.12.9/SGI-server-1.8) with ESMTP id h6PME2Rn193375532; Fri, 25 Jul 2003 17:14:03 -0500 (CDT) Subject: Re: ANNOUNCE XFS 1.3.0pre4 From: Russell Cattelan To: Thomas Seifert Cc: linux-xfs@oss.sgi.com In-Reply-To: <20030726000455.0737993a.thomas-lists@myphorum.com> References: <1059169471.34654.113.camel@rose.americas.sgi.com> <20030726000455.0737993a.thomas-lists@myphorum.com> Content-Type: text/plain Message-Id: <1059171112.34654.118.camel@rose.americas.sgi.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.3 Date: 25 Jul 2003 17:11:53 -0500 Content-Transfer-Encoding: 7bit X-archive-position: 4734 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: cattelan@xfs.org Precedence: bulk X-list: linux-xfs Content-Length: 1426 Lines: 50 The patches only affect XFS. The core kernel patches have not changed and will not change in the foreseeable future. They can be grabbed from: ftp://oss.sgi.com/projects/xfs/Release-1.3/kernel_patches/ Sorry for the confusion... I probably should have re-iterated the patch release process. On Fri, 2003-07-25 at 19:04, Thomas Seifert wrote: > Just curious, maybe I missed something important but in the kernel-patches-directory > there is no kernel-version given. > So for which kernels are these patches at all? > > > Thanks in advance, > > Thomas > > On 25 Jul 2003 16:44:32 -0500 Russell Cattelan wrote: > > > The 1.3.0 pre4 patches and latest RH9 errata kernel rpms are > > available at: > > ftp://oss.sgi.com/projects/xfs/Release-1.3/pre4/ > > > > The 1.3 xfs-cmds have also been updated to TOT xfs-cmds, since > > there is no real reason not to bring them in sync. In other works > > no major code changes, just a lot of cleanups and minor bug fixes. > > > > One significant update: xfs_copy is now installed by default. > > > > The kernel rpm's themselves have not had much testing so use > > at your own risk. > > > > As far as the xfs codes goes, it goes through nightly regression > > testing. > > > > As always please let us know of any issues. > > If things go well pre4 should probably turn into actual XFS 1.3.0 > > > > -Russell Cattelan > > > > > > > > > > > > > > > From owner-linux-xfs@oss.sgi.com Fri Jul 25 15:40:05 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 25 Jul 2003 15:40:08 -0700 (PDT) Received: from mail.myphorum.de (h-217.110.117.254.host.de.colt.net [217.110.117.254] (may be forged)) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h6PMdsFl032677 for ; Fri, 25 Jul 2003 15:39:55 -0700 Received: from localhost (myphorum [127.0.0.1]) by mail.myphorum.de (Postfix) with ESMTP id 8E1332742D7; Sat, 26 Jul 2003 00:04:32 +0200 (CEST) Received: from mail.myphorum.de ([127.0.0.1]) by localhost (myphorum.de [127.0.0.1:10024]) (amavisd-new) with ESMTP id 12775-09; Sat, 26 Jul 2003 00:04:32 +0200 (CEST) Received: from athlon-gt.myphorum.org (pD9E8230E.dip.t-dialin.net [217.232.35.14]) by mail.myphorum.de (Postfix) with ESMTP id C5D082742D6; Sat, 26 Jul 2003 00:04:31 +0200 (CEST) Date: Sat, 26 Jul 2003 00:04:55 +0000 From: Thomas Seifert To: Russell Cattelan Cc: linux-xfs@oss.sgi.com Subject: Re: ANNOUNCE XFS 1.3.0pre4 Message-Id: <20030726000455.0737993a.thomas-lists@myphorum.com> In-Reply-To: <1059169471.34654.113.camel@rose.americas.sgi.com> References: <1059169471.34654.113.camel@rose.americas.sgi.com> X-Mailer: Sylpheed version 0.9.4 (GTK+ 1.2.10; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new X-archive-position: 4735 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: thomas-lists@myphorum.com Precedence: bulk X-list: linux-xfs Content-Length: 1004 Lines: 40 Just curious, maybe I missed something important but in the kernel-patches-directory there is no kernel-version given. So for which kernels are these patches at all? Thanks in advance, Thomas On 25 Jul 2003 16:44:32 -0500 Russell Cattelan wrote: > The 1.3.0 pre4 patches and latest RH9 errata kernel rpms are > available at: > ftp://oss.sgi.com/projects/xfs/Release-1.3/pre4/ > > The 1.3 xfs-cmds have also been updated to TOT xfs-cmds, since > there is no real reason not to bring them in sync. In other works > no major code changes, just a lot of cleanups and minor bug fixes. > > One significant update: xfs_copy is now installed by default. > > The kernel rpm's themselves have not had much testing so use > at your own risk. > > As far as the xfs codes goes, it goes through nightly regression > testing. > > As always please let us know of any issues. > If things go well pre4 should probably turn into actual XFS 1.3.0 > > -Russell Cattelan > > > > > > > From owner-linux-xfs@oss.sgi.com Fri Jul 25 16:36:26 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 25 Jul 2003 16:36:41 -0700 (PDT) Received: from mx-01-bsl.sauter-bc.com (mx-01-bsl.sauter-bc.com [213.173.165.132]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h6PNaNFl004638 for ; Fri, 25 Jul 2003 16:36:25 -0700 Received: from mailhub.ch.sauter-bc.com (mailhub [10.1.6.26]) by mx-01-bsl.sauter-bc.com (Postfix) with ESMTP id A025E4E261; Sat, 26 Jul 2003 01:36:17 +0200 (CEST) Received: from imap01.ch.sauter-bc.com (imap01.ch.sauter-bc.com [10.1.6.25]) by mailhub.ch.sauter-bc.com (Postfix) with ESMTP id BB49332CB5; Sat, 26 Jul 2003 01:36:16 +0200 (CEST) Received: from webmail.ch.sauter-bc.com (localhost.localdomain [127.0.0.1]) by imap01.ch.sauter-bc.com (Postfix) with SMTP id 5660711E0A; Sat, 26 Jul 2003 01:36:16 +0200 (CEST) Received: from 213.173.165.140 (proxying for 157.161.34.15) (SquirrelMail authenticated user mattesim) by imap01.ch.sauter-bc.com with HTTP; Sat, 26 Jul 2003 01:36:16 +0200 (CEST) Message-ID: <54612.213.173.165.140.1059176176.squirrel@imap01.ch.sauter-bc.com> In-Reply-To: <1059169471.34654.113.camel@rose.americas.sgi.com> References: <1059169471.34654.113.camel@rose.americas.sgi.com> Date: Sat, 26 Jul 2003 01:36:16 +0200 (CEST) Subject: Re: ANNOUNCE XFS 1.3.0pre4 From: "Simon Matter" To: "Russell Cattelan" Cc: linux-xfs@oss.sgi.com User-Agent: SquirrelMail/1.4.1 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 Importance: Normal X-archive-position: 4736 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: simon.matter@ch.sauter-bc.com Precedence: bulk X-list: linux-xfs Content-Length: 1171 Lines: 41 Russel, May I propose a little change in the package name for future releases. IIRC rpm considers kernel-2.4.20-18.9XFS1.3.0pre4 older than kernel-2.4.20-18.9. Now if you 'rpm -Fvh *' in a directory which includes errata rpms, the original RedHat kernel is installed even if you already upgraded to the new XFS release, which is not what you want. If you change the release to kernel-2.4.20-18.9.XFS1.3.0pre4, it doesn't happen again. Regards, Simon > The 1.3.0 pre4 patches and latest RH9 errata kernel rpms are > available at: > ftp://oss.sgi.com/projects/xfs/Release-1.3/pre4/ > > The 1.3 xfs-cmds have also been updated to TOT xfs-cmds, since > there is no real reason not to bring them in sync. In other works > no major code changes, just a lot of cleanups and minor bug fixes. > > One significant update: xfs_copy is now installed by default. > > The kernel rpm's themselves have not had much testing so use > at your own risk. > > As far as the xfs codes goes, it goes through nightly regression > testing. > > As always please let us know of any issues. > If things go well pre4 should probably turn into actual XFS 1.3.0 > > -Russell Cattelan > > > > > > > From owner-linux-xfs@oss.sgi.com Fri Jul 25 17:10:29 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 25 Jul 2003 17:10:36 -0700 (PDT) Received: from heretic.physik.fu-berlin.de (root@heretic.physik.fu-berlin.de [160.45.32.86]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h6Q0AMFl007464 for ; Fri, 25 Jul 2003 17:10:28 -0700 Received: from puariko.homeip.net (pD9E7E67D.dip.t-dialin.net [217.231.230.125]) by heretic.physik.fu-berlin.de (8.12.8/8.12.8) with ESMTP id h6Q0ACw8015365 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sat, 26 Jul 2003 02:10:18 +0200 Received: (from thimm@localhost) by puariko.nirvana (8.12.8/8.12.8/Submit) id h6Q0A8Oc016118; Sat, 26 Jul 2003 02:10:08 +0200 Date: Sat, 26 Jul 2003 02:10:08 +0200 From: Axel Thimm To: Simon Matter Cc: Russell Cattelan , linux-xfs@oss.sgi.com Subject: Re: ANNOUNCE XFS 1.3.0pre4 Message-ID: <20030726001008.GC14428@puariko.nirvana> References: <1059169471.34654.113.camel@rose.americas.sgi.com> <54612.213.173.165.140.1059176176.squirrel@imap01.ch.sauter-bc.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="oTHb8nViIGeoXxdp" Content-Disposition: inline In-Reply-To: <54612.213.173.165.140.1059176176.squirrel@imap01.ch.sauter-bc.com> User-Agent: Mutt/1.4.1i X-archive-position: 4737 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: Axel.Thimm@physik.fu-berlin.de Precedence: bulk X-list: linux-xfs Content-Length: 2129 Lines: 75 --oTHb8nViIGeoXxdp Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sat, Jul 26, 2003 at 01:36:16AM +0200, Simon Matter wrote: > Russel, >=20 > May I propose a little change in the package name for future releases. > IIRC rpm considers kernel-2.4.20-18.9XFS1.3.0pre4 older than > kernel-2.4.20-18.9. Appending to the rpm's release makes the release always newer, so the scenario you describe shouldn't happen. > Now if you 'rpm -Fvh *' in a directory which includes > errata rpms, the original RedHat kernel is installed even if you already > upgraded to the new XFS release, which is not what you want. > If you change the release to kernel-2.4.20-18.9.XFS1.3.0pre4, it doesn't > happen again. Maybe you upgraded an XFS 18 to a non-XFS 19 release? That could happen. If you want to avoid that you need to change the naming convention rather radically, e.g. kernel-sgixfs-2.4.20-18.9 to stay with the above example. > Regards, > Simon >=20 > > The 1.3.0 pre4 patches and latest RH9 errata kernel rpms are > > available at: > > ftp://oss.sgi.com/projects/xfs/Release-1.3/pre4/ > > > > The 1.3 xfs-cmds have also been updated to TOT xfs-cmds, since > > there is no real reason not to bring them in sync. In other works > > no major code changes, just a lot of cleanups and minor bug fixes. > > > > One significant update: xfs_copy is now installed by default. > > > > The kernel rpm's themselves have not had much testing so use > > at your own risk. > > > > As far as the xfs codes goes, it goes through nightly regression > > testing. > > > > As always please let us know of any issues. > > If things go well pre4 should probably turn into actual XFS 1.3.0 > > > > -Russell Cattelan > > > > > > > > > > > > > > >=20 --=20 Axel.Thimm@physik.fu-berlin.de --oTHb8nViIGeoXxdp Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2 (GNU/Linux) iD8DBQE/IcbgQBVS1GOamfERAic5AJ9dbR4+73pvd4vaKEdRPQ6ccdmHEQCdFsZm Z64onvxcKJwLFmNUOUSLnes= =tCof -----END PGP SIGNATURE----- --oTHb8nViIGeoXxdp-- From owner-linux-xfs@oss.sgi.com Fri Jul 25 17:23:23 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 25 Jul 2003 17:23:41 -0700 (PDT) Received: from mx-01-bsl.sauter-bc.com (mx-01-bsl.sauter-bc.com [213.173.165.132]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h6Q0NMFl008840 for ; Fri, 25 Jul 2003 17:23:23 -0700 Received: from mailhub.ch.sauter-bc.com (mailhub [10.1.6.26]) by mx-01-bsl.sauter-bc.com (Postfix) with ESMTP id 8EEA34E254; Sat, 26 Jul 2003 02:23:16 +0200 (CEST) Received: from imap01.ch.sauter-bc.com (imap01.ch.sauter-bc.com [10.1.6.25]) by mailhub.ch.sauter-bc.com (Postfix) with ESMTP id DC11B32CB5; Sat, 26 Jul 2003 02:23:15 +0200 (CEST) Received: from webmail.ch.sauter-bc.com (localhost.localdomain [127.0.0.1]) by imap01.ch.sauter-bc.com (Postfix) with SMTP id 1FB3011E0A; Sat, 26 Jul 2003 02:23:15 +0200 (CEST) Received: from 213.173.165.140 (proxying for 157.161.34.15) (SquirrelMail authenticated user mattesim) by imap01.ch.sauter-bc.com with HTTP; Sat, 26 Jul 2003 02:23:15 +0200 (CEST) Message-ID: <54662.213.173.165.140.1059178995.squirrel@imap01.ch.sauter-bc.com> In-Reply-To: <20030726001008.GC14428@puariko.nirvana> References: <1059169471.34654.113.camel@rose.americas.sgi.com> <54612.213.173.165.140.1059176176.squirrel@imap01.ch.sauter-bc.com> <20030726001008.GC14428@puariko.nirvana> Date: Sat, 26 Jul 2003 02:23:15 +0200 (CEST) Subject: Re: ANNOUNCE XFS 1.3.0pre4 From: "Simon Matter" To: "Axel Thimm" Cc: "Simon Matter" , "Russell Cattelan" , linux-xfs@oss.sgi.com User-Agent: SquirrelMail/1.4.1 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 Importance: Normal X-archive-position: 4738 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: simon.matter@ch.sauter-bc.com Precedence: bulk X-list: linux-xfs Content-Length: 1988 Lines: 66 > On Sat, Jul 26, 2003 at 01:36:16AM +0200, Simon Matter wrote: >> Russel, >> >> May I propose a little change in the package name for future releases. >> IIRC rpm considers kernel-2.4.20-18.9XFS1.3.0pre4 older than >> kernel-2.4.20-18.9. > > Appending to the rpm's release makes the release always newer, so the > scenario you describe shouldn't happen. You're right, shame on me. I had the old naming in mind which was once used with an XFS installer where names would be in the form kernel-2.4.20-18XFS1.3.0pre4 which was considerd older than kernel-2.4.20-18.9. Sorry for the noise Simon > >> Now if you 'rpm -Fvh *' in a directory which includes >> errata rpms, the original RedHat kernel is installed even if you already >> upgraded to the new XFS release, which is not what you want. >> If you change the release to kernel-2.4.20-18.9.XFS1.3.0pre4, it doesn't >> happen again. > > Maybe you upgraded an XFS 18 to a non-XFS 19 release? That could > happen. If you want to avoid that you need to change the naming > convention rather radically, e.g. kernel-sgixfs-2.4.20-18.9 to stay > with the above example. > >> Regards, >> Simon >> >> > The 1.3.0 pre4 patches and latest RH9 errata kernel rpms are >> > available at: >> > ftp://oss.sgi.com/projects/xfs/Release-1.3/pre4/ >> > >> > The 1.3 xfs-cmds have also been updated to TOT xfs-cmds, since >> > there is no real reason not to bring them in sync. In other works >> > no major code changes, just a lot of cleanups and minor bug fixes. >> > >> > One significant update: xfs_copy is now installed by default. >> > >> > The kernel rpm's themselves have not had much testing so use >> > at your own risk. >> > >> > As far as the xfs codes goes, it goes through nightly regression >> > testing. >> > >> > As always please let us know of any issues. >> > If things go well pre4 should probably turn into actual XFS 1.3.0 >> > >> > -Russell Cattelan >> > >> > >> > >> > >> > >> > >> > >> > > -- > Axel.Thimm@physik.fu-berlin.de > From owner-linux-xfs@oss.sgi.com Fri Jul 25 17:26:40 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 25 Jul 2003 17:26:46 -0700 (PDT) Received: from mail.vasoftware.com (mail.vasoftware.com [198.186.202.175]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h6Q0QdFl009495 for ; Fri, 25 Jul 2003 17:26:40 -0700 Received: from adsl-67-123-174-175.dsl.sntc01.pacbell.net ([67.123.174.175] helo=linux-sxs.org) by mail.vasoftware.com with asmtp (Cipher TLSv1:RC4-MD5:128) (Exim 3.31-VA-mm2 #1 (Debian)) id 19gCtS-0002vx-00 by VAauthid with fixed_plain for ; Fri, 25 Jul 2003 17:26:38 -0700 Message-ID: <3F21CAB7.7040403@linux-sxs.org> Date: Fri, 25 Jul 2003 17:26:31 -0700 From: "Net Llama!" Organization: HAL III User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030625 X-Accept-Language: en-us, en MIME-Version: 1.0 To: linux-xfs@oss.sgi.com Subject: Re: ANNOUNCE XFS 1.3.0pre4 References: <1059169471.34654.113.camel@rose.americas.sgi.com> <54612.213.173.165.140.1059176176.squirrel@imap01.ch.sauter-bc.com> <20030726001008.GC14428@puariko.nirvana> <54662.213.173.165.140.1059178995.squirrel@imap01.ch.sauter-bc.com> In-Reply-To: <54662.213.173.165.140.1059178995.squirrel@imap01.ch.sauter-bc.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 4739 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: netllama@linux-sxs.org Precedence: bulk X-list: linux-xfs Content-Length: 2834 Lines: 61 On Sat, Jul 26, 2003 at 01:36:16AM +0200, Simon Matter wrote: >>>>The 1.3.0 pre4 patches and latest RH9 errata kernel rpms are >>>>available at: >>>>ftp://oss.sgi.com/projects/xfs/Release-1.3/pre4/ >>>> >>>>The 1.3 xfs-cmds have also been updated to TOT xfs-cmds, since >>>>there is no real reason not to bring them in sync. In other works >>>>no major code changes, just a lot of cleanups and minor bug fixes. >>>> >>>>One significant update: xfs_copy is now installed by default. >>>> >>>>The kernel rpm's themselves have not had much testing so use >>>>at your own risk. >>>> >>>>As far as the xfs codes goes, it goes through nightly regression >>>>testing. >>>> >>>>As always please let us know of any issues. >>>>If things go well pre4 should probably turn into actual XFS 1.3.0 Rebuilding the xfs_progs SRPM is bombing out on my box, running 2.4.21-XFS: gcc -O2 -funroll-loops -ffast-math -fomit-frame-pointer -fno-exceptions -O1 -g -DDEBUG -funsigned-char -Wall -I./include -DVERSION=\"2.5.4\" -DLOCALEDIR=\"/usr/share/locale\" -DPACKAGE=\"xfsprogs\" -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -DXFS_BIG_FILES=1 -DXFS_BIG_FILESYSTEMS=1 -O1 -g -DDEBUG -funsigned-char -Wall -I../include -DVERSION=\"2.5.4\" -DLOCALEDIR=\"/usr/share/locale\" -DPACKAGE=\"xfsprogs\" -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -DXFS_BIG_FILES=1 -DXFS_BIG_FILESYSTEMS=1 -c -o xfs_copy.o xfs_copy.c xfs_copy.c:42: xfs_copy.h: No such file or directory xfs_copy.c:303: macro `die_perror' used without args xfs_copy.c:392: macro `die_perror' used without args xfs_copy.c:414: macro `die_perror' used without args xfs_copy.c:585: macro `die_perror' used without args xfs_copy.c:600: macro `die_perror' used without args xfs_copy.c:610: macro `die_perror' used without args xfs_copy.c:616: macro `die_perror' used without args xfs_copy.c:626: macro `die_perror' used without args xfs_copy.c:631: macro `die_perror' used without args xfs_copy.c:777: macro `die_perror' used without args xfs_copy.c:787: macro `die_perror' used without args xfs_copy.c:793: macro `die_perror' used without args xfs_copy.c:812: macro `die_perror' used without args xfs_copy.c:821: macro `die_perror' used without args xfs_copy.c:828: macro `die_perror' used without args xfs_copy.c:836: macro `die_perror' used without args xfs_copy.c:841: macro `die_perror' used without args xfs_copy.c:856: macro `die_perror' used without args xfs_copy.c:868: macro `die_perror' used without args xfs_copy.c:885: macro `die_perror' used without args make[2]: *** [xfs_copy.o] Error 1 make[1]: *** [default] Error 2 -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ L. Friedman netllama@linux-sxs.org Linux Step-by-step & TyGeMo: http://netllama.ipfox.com 5:25pm up 10 days, 20:08, 1 user, load average: 0.05, 0.22, 0.27 From owner-linux-xfs@oss.sgi.com Fri Jul 25 17:43:21 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 25 Jul 2003 17:43:24 -0700 (PDT) Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.9/8.12.9) with ESMTP id h6Q0hLFl011127 for ; Fri, 25 Jul 2003 17:43:21 -0700 Received: (from xfs@localhost) by oss.sgi.com (8.12.9/8.12.8/Submit) id h6Q0hL2M011126 for linux-xfs@oss.sgi.com; Fri, 25 Jul 2003 17:43:21 -0700 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.9/8.12.9) with ESMTP id h6Q0hKFn011109 for ; Fri, 25 Jul 2003 17:43:20 -0700 Received: (from apache@localhost) by oss.sgi.com (8.12.9/8.12.8/Submit) id h6Q0NTql008870; Fri, 25 Jul 2003 17:23:29 -0700 Date: Fri, 25 Jul 2003 17:23:29 -0700 Message-Id: <200307260023.h6Q0NTql008870@oss.sgi.com> From: bugzilla-daemon@oss.sgi.com To: xfs-master@oss.sgi.com Subject: [Bug 268] linux 2.6.0-test1-mm1 with RAID 0 XFS internal error during delete X-Bugzilla-Reason: AssignedTo X-archive-position: 4740 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: bugzilla-daemon@oss.sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 1576 Lines: 57 http://oss.sgi.com/bugzilla/show_bug.cgi?id=268 ------- Additional Comments From ward@speakeasy.net 2003-25-07 17:23 PDT ------- something interesting... right after the error df -m /dev/md2 Filesystem 1M-blocks Used Available Use% Mounted on /dev/md2 6395 -72057594037927064 7268 101% /db_sps note that since updating to 2.6.0-test1-mm2 I was able to repeat the error using the devices and filesystems previously defined. After remaking the software raid array and recreating the filesystem I've been running without errors. raiddev /dev/md0 raid-level 0 nr-raid-disks 2 nr-spare-disks 0 chunk-size 32 persistent-superblock 1 device /dev/hde1 raid-disk 0 device /dev/hdg1 raid-disk 1 raiddev /dev/md1 raid-level 0 nr-raid-disks 2 nr-spare-disks 0 chunk-size 32 persistent-superblock 1 device /dev/hde2 raid-disk 0 device /dev/hdg2 raid-disk 1 raiddev /dev/md2 raid-level 0 nr-raid-disks 3 nr-spare-disks 0 chunk-size 32 persistent-superblock 1 device /dev/sdb5 raid-disk 0 device /dev/sdc5 raid-disk 1 device /dev/sdd5 raid-disk 2 ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From owner-linux-xfs@oss.sgi.com Sat Jul 26 08:02:19 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Sat, 26 Jul 2003 08:02:34 -0700 (PDT) Received: from zok.sgi.com (zok.SGI.COM [204.94.215.101]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h6QF2IFl014544 for ; Sat, 26 Jul 2003 08:02:19 -0700 Received: from flecktone.americas.sgi.com (flecktone.americas.sgi.com [192.48.203.135]) by zok.sgi.com (8.12.9/8.12.9/linux-outbound_gateway-1.1) with ESMTP id h6QF2Dq0013033 for ; Sat, 26 Jul 2003 08:02:13 -0700 Received: from daisy-e236.americas.sgi.com (daisy-e236.americas.sgi.com [128.162.236.214]) by flecktone.americas.sgi.com (8.12.9/8.12.9/generic_config-1.2) with ESMTP id h6QF2DQK1742083 for ; Sat, 26 Jul 2003 10:02:13 -0500 (CDT) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.232.100]) by daisy-e236.americas.sgi.com (8.12.9/SGI-server-1.8) with ESMTP id h6QF2CRn192402467 for ; Sat, 26 Jul 2003 10:02:13 -0500 (CDT) From: Steve Lord Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id h6QF2CM14649; Sat, 26 Jul 2003 10:02:12 -0500 Message-Id: <200307261502.h6QF2CM14649@jen.americas.sgi.com> Date: Sat, 26 Jul 2003 10:02:12 -0500 Subject: TAKE - Scale default number of log buffers based on memory size To: linux-xfs@oss.sgi.com X-archive-position: 4741 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: lord@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 833 Lines: 27 Merge in Andi Kleen's change from the 2.4 tree to the 2.5 tree Date: Sat Jul 26 08:00:29 PDT 2003 Workarea: jen.americas.sgi.com:/src/lord/xfs-linux.2.5 Author: lord Merged by: lord Merged mods: xfs-linux:slinx:153273a The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.5.x-xfs Modid: 2.5.x-xfs:slinx:153273a linux/fs/xfs/xfs_log.c - 1.276 - Merge of xfs-linux:slinx:153273a by lord. if the user did not specify how many log buffers to use, then scale the number we use based on available memory. linux/fs/xfs/xfs_log_priv.h - 1.95 - Merge of xfs-linux:slinx:153273a by lord. Changed defines for scaling default log buffers with memory size linux/fs/xfs/xfs_vfsops.c - 1.418 - Merge of xfs-linux:slinx:153273a by lord. use new constants for bounds checking on logbuf parameters From owner-linux-xfs@oss.sgi.com Sun Jul 27 14:17:31 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 27 Jul 2003 14:17:47 -0700 (PDT) Received: from tolkor.sgi.com ([198.149.18.6]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h6RLHUFl024788 for ; Sun, 27 Jul 2003 14:17:31 -0700 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by tolkor.sgi.com (8.12.9/8.12.9/linux-outbound_gateway-1.1) with SMTP id h6RLaXsR014971 for ; Sun, 27 Jul 2003 16:36:34 -0500 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 HAA01537; Mon, 28 Jul 2003 07:17:20 +1000 Received: from wobbly.melbourne.sgi.com (localhost [127.0.0.1]) by wobbly.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id h6RLHI3K207240; Mon, 28 Jul 2003 07:17:18 +1000 (EST) Received: (from nathans@localhost) by wobbly.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id h6RLHHex208557; Mon, 28 Jul 2003 07:17:17 +1000 (EST) Date: Mon, 28 Jul 2003 07:17:17 +1000 From: Nathan Scott To: Net Llama! Cc: linux-xfs@oss.sgi.com Subject: Re: ANNOUNCE XFS 1.3.0pre4 Message-ID: <20030728071717.A205880@wobbly.melbourne.sgi.com> References: <1059169471.34654.113.camel@rose.americas.sgi.com> <54612.213.173.165.140.1059176176.squirrel@imap01.ch.sauter-bc.com> <20030726001008.GC14428@puariko.nirvana> <54662.213.173.165.140.1059178995.squirrel@imap01.ch.sauter-bc.com> <3F21CAB7.7040403@linux-sxs.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <3F21CAB7.7040403@linux-sxs.org>; from netllama@linux-sxs.org on Fri, Jul 25, 2003 at 05:26:31PM -0700 X-archive-position: 4742 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: nathans@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 1035 Lines: 28 On Fri, Jul 25, 2003 at 05:26:31PM -0700, Net Llama! wrote: > On Sat, Jul 26, 2003 at 01:36:16AM +0200, Simon Matter wrote: > > Rebuilding the xfs_progs SRPM is bombing out on my box, running 2.4.21-XFS: > > gcc -O2 -funroll-loops -ffast-math -fomit-frame-pointer -fno-exceptions -O1 > -g -DDEBUG -funsigned-char -Wall -I./include -DVERSION=\"2.5.4\" > -DLOCALEDIR=\"/usr/share/locale\" -DPACKAGE=\"xfsprogs\" -D_GNU_SOURCE > -D_FILE_OFFSET_BITS=64 -DXFS_BIG_FILES=1 -DXFS_BIG_FILESYSTEMS=1 -O1 -g > -DDEBUG -funsigned-char -Wall -I../include -DVERSION=\"2.5.4\" > -DLOCALEDIR=\"/usr/share/locale\" -DPACKAGE=\"xfsprogs\" -D_GNU_SOURCE > -D_FILE_OFFSET_BITS=64 -DXFS_BIG_FILES=1 -DXFS_BIG_FILESYSTEMS=1 -c -o > xfs_copy.o xfs_copy.c > xfs_copy.c:42: xfs_copy.h: No such file or directory Ah, I botched the Makefile. > xfs_copy.c:303: macro `die_perror' used without args Hmm - looks like your compiler doesn't like this, but mine does. Oh well, thats easily corrected - I'll checkin a fix shortly. thanks. -- Nathan From owner-linux-xfs@oss.sgi.com Sun Jul 27 14:40:08 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 27 Jul 2003 14:40:12 -0700 (PDT) Received: from lists.vasoftware.com (mail@lists.vasoftware.com [198.186.202.171]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h6RLe7Fl026224 for ; Sun, 27 Jul 2003 14:40:08 -0700 Received: from adsl-67-123-174-175.dsl.sntc01.pacbell.net ([67.123.174.175]:64997 helo=linux-sxs.org) by lists.vasoftware.com with asmtp (Cipher TLSv1:RC4-MD5:128) (Exim 4.20 #1 (Debian)) id 19gtFK-0005oU-Pi by authid with fixed_plain; Sun, 27 Jul 2003 14:40:02 -0700 Message-ID: <3F24469C.2080604@linux-sxs.org> Date: Sun, 27 Jul 2003 14:39:40 -0700 From: "Net Llama!" Organization: HAL III User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030625 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Nathan Scott CC: linux-xfs@oss.sgi.com Subject: Re: ANNOUNCE XFS 1.3.0pre4 References: <1059169471.34654.113.camel@rose.americas.sgi.com> <54612.213.173.165.140.1059176176.squirrel@imap01.ch.sauter-bc.com> <20030726001008.GC14428@puariko.nirvana> <54662.213.173.165.140.1059178995.squirrel@imap01.ch.sauter-bc.com> <3F21CAB7.7040403@linux-sxs.org> <20030728071717.A205880@wobbly.melbourne.sgi.com> In-Reply-To: <20030728071717.A205880@wobbly.melbourne.sgi.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-EA-Verified: lists.vasoftware.com 19gtFK-0005oU-Pi 9e0b0e31f81fb75eb79b8a57d08c7c42 X-Spam-Score: -0.9 X-archive-position: 4743 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: netllama@linux-sxs.org Precedence: bulk X-list: linux-xfs Content-Length: 1407 Lines: 41 On 07/27/03 14:17, Nathan Scott wrote: > On Fri, Jul 25, 2003 at 05:26:31PM -0700, Net Llama! wrote: > >>On Sat, Jul 26, 2003 at 01:36:16AM +0200, Simon Matter wrote: >> >>Rebuilding the xfs_progs SRPM is bombing out on my box, running 2.4.21-XFS: >> >>gcc -O2 -funroll-loops -ffast-math -fomit-frame-pointer -fno-exceptions -O1 >>-g -DDEBUG -funsigned-char -Wall -I./include -DVERSION=\"2.5.4\" >>-DLOCALEDIR=\"/usr/share/locale\" -DPACKAGE=\"xfsprogs\" -D_GNU_SOURCE >>-D_FILE_OFFSET_BITS=64 -DXFS_BIG_FILES=1 -DXFS_BIG_FILESYSTEMS=1 -O1 -g >>-DDEBUG -funsigned-char -Wall -I../include -DVERSION=\"2.5.4\" >>-DLOCALEDIR=\"/usr/share/locale\" -DPACKAGE=\"xfsprogs\" -D_GNU_SOURCE >>-D_FILE_OFFSET_BITS=64 -DXFS_BIG_FILES=1 -DXFS_BIG_FILESYSTEMS=1 -c -o >>xfs_copy.o xfs_copy.c >>xfs_copy.c:42: xfs_copy.h: No such file or directory > > > Ah, I botched the Makefile. ok. > > >>xfs_copy.c:303: macro `die_perror' used without args > > > Hmm - looks like your compiler doesn't like this, but mine > does. Oh well, thats easily corrected - I'll checkin a fix > shortly. I'm using gcc-2.95.3 if that helps. thanks! -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ L. Friedman netllama@linux-sxs.org Linux Step-by-step & TyGeMo: http://netllama.ipfox.com 2:35pm up 12 days, 17:18, 1 user, load average: 0.11, 0.18, 0.20 From owner-linux-xfs@oss.sgi.com Sun Jul 27 15:56:55 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 27 Jul 2003 15:56:58 -0700 (PDT) Received: from zok.sgi.com (zok.SGI.COM [204.94.215.101]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h6RMusFl030763 for ; Sun, 27 Jul 2003 15:56:55 -0700 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.54.149]) by zok.sgi.com (8.12.9/8.12.9/linux-outbound_gateway-1.1) with ESMTP id h6RMumq0027406 for ; Sun, 27 Jul 2003 15:56:49 -0700 Received: from snort.melbourne.sgi.com (localhost [127.0.0.1]) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id h6RMulJA5657337 for ; Mon, 28 Jul 2003 08:56:47 +1000 (EST) Received: (from nathans@localhost) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id h6RMukWS6814588 for linux-xfs@oss.sgi.com; Mon, 28 Jul 2003 08:56:46 +1000 (EST) Date: Mon, 28 Jul 2003 08:56:46 +1000 (EST) From: Nathan Scott Message-Id: <200307272256.h6RMukWS6814588@snort.melbourne.sgi.com> To: linux-xfs@oss.sgi.com Subject: TAKE - fix build X-archive-position: 4744 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: nathans@snort.melbourne.sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 322 Lines: 13 Couple of small xfs_copy build fixes. Date: Sun Jul 27 14:29:31 PDT 2003 Workarea: snort.melbourne.sgi.com:/home/nathans/2.5.x-xfs The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.5.x-xfs Modid: xfs-cmds:slinx:154358a cmd/xfsprogs/copy/Makefile - 1.2 cmd/xfsprogs/copy/xfs_copy.c - 1.3 From owner-linux-xfs@oss.sgi.com Sun Jul 27 20:25:21 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 27 Jul 2003 20:25:37 -0700 (PDT) Received: from rj.sgi.com (rj.SGI.COM [192.82.208.96]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h6S3PKFl018752 for ; Sun, 27 Jul 2003 20:25:21 -0700 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by rj.sgi.com (8.12.9/8.12.9/linux-outbound_gateway-1.1) with SMTP id h6S1PcMM010871 for ; Sun, 27 Jul 2003 18:25:39 -0700 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 NAA05236; Mon, 28 Jul 2003 13:25:10 +1000 Received: from frodo.melbourne.sgi.com (root@frodo.melbourne.sgi.com [134.14.55.153]) by wobbly.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id h6S3P93K190014; Mon, 28 Jul 2003 13:25:10 +1000 (EST) Received: from frodo.melbourne.sgi.com (nathans@localhost [127.0.0.1]) by frodo.melbourne.sgi.com (8.12.9/8.12.9/Debian-3) with ESMTP id h6S3OK5m000909; Mon, 28 Jul 2003 13:24:20 +1000 Received: (from nathans@localhost) by frodo.melbourne.sgi.com (8.12.9/8.12.9/Debian-3) id h6S3OC6B000907; Mon, 28 Jul 2003 13:24:12 +1000 Date: Mon, 28 Jul 2003 13:24:12 +1000 From: Nathan Scott To: nstraz@sgi.com Cc: linux-xfs@oss.sgi.com Subject: Re: [Bug 267] New: pwrite64 failed on 1.2 TB evms volume Message-ID: <20030728032412.GC682@frodo> References: <200307251200.h6PC0QZ8018467@oss.sgi.com> <20030725153651.GB1160@sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030725153651.GB1160@sgi.com> User-Agent: Mutt/1.5.3i X-archive-position: 4745 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: nathans@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 635 Lines: 22 On Fri, Jul 25, 2003 at 10:36:51AM -0500, Nathan Straz wrote: > ... > Perhaps EVMS isn't reporting the size of the device correctly. > > Try running `strace mkfs.xfs -f /dev/evms/SYSTEM` and add the output to > the bug. Unfortunately strace doesn't decode ioctl's, so we probably wont get much information out of this - the device size is clearly wrong though, so unlikely this is an XFS problem. > BTW, why use EVMS? IIRC, it was discontinued after it lost the race for > 2.5. EVMS now exists as a userspace implementation above the DM layer, I believe, so it wasn't discontinued (just kinda redirected). cheers. -- Nathan From owner-linux-xfs@oss.sgi.com Mon Jul 28 01:05:39 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 28 Jul 2003 01:06:00 -0700 (PDT) Received: from hotmail.com (law9-f111.law9.hotmail.com [64.4.9.111]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h6S85cFl008317 for ; Mon, 28 Jul 2003 01:05:39 -0700 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Mon, 28 Jul 2003 01:05:33 -0700 Received: from 80.128.36.152 by lw9fd.law9.hotmail.msn.com with HTTP; Mon, 28 Jul 2003 08:05:33 GMT X-Originating-IP: [80.128.36.152] X-Originating-Email: [k_leibrandt@hotmail.com] From: "Kai Leibrandt" To: linux-xfs@oss.sgi.com Subject: xfsdump/xfsrestore rpmbuild problems Date: Mon, 28 Jul 2003 10:05:33 +0200 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 28 Jul 2003 08:05:33.0696 (UTC) FILETIME=[05207800:01C354DF] X-archive-position: 4746 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: k_leibrandt@hotmail.com Precedence: bulk X-list: linux-xfs Content-Length: 1449 Lines: 44 Hi all, I just tried to go and rebuild xfsdump and xfsprogs from the 1.3pre4 cmd_rpms, but xfsdump-2.2.13-0.src.rpm and xfsprogs-2.5.4-0.src.rpm both fail due to uuid.h not being found: ... ... checking for stdint.h... yes checking for unistd.h... yes checking uuid.h usability... no checking uuid.h presence... no checking for uuid.h... no checking uuid/uuid.h usability... no checking uuid/uuid.h presence... no checking for uuid/uuid.h... no FATAL ERROR: could not find a valid UUID header. Install the Universally Unique Identifiers development package. make: *** [include/builddefs] Error 1 error: Bad exit status from /var/tmp/rpm-tmp.93142 (%build) RPM build errors: user cattelan does not exist - using root group srgfs does not exist - using root user cattelan does not exist - using root group srgfs does not exist - using root Bad exit status from /var/tmp/rpm-tmp.93142 (%build) I have the kernel sources installed (well, I symlinked to the build tree from /usr/src/redhat/BUILD/etc to /usr/src/linux-2.4.20 from kernel-2.4.20-18.9XFS1.3.0pre4.src.rpm) so they are in place... I'm sure it's something basic I'm doing wrong - can anyone point me to what it is? System is a RH9, kernel 2.4.20-18.9XFS1.3.0pre4. Thanks in advance, Kai. _________________________________________________________________ Help STOP SPAM with the new MSN 8 and get 2 months FREE* http://join.msn.com/?page=features/junkmail From owner-linux-xfs@oss.sgi.com Mon Jul 28 03:10:49 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 28 Jul 2003 03:11:07 -0700 (PDT) Received: from hob.acsalaska.net (hob.slb.nwc.acsalaska.net [209.112.155.42]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h6SAAlFl022325 for ; Mon, 28 Jul 2003 03:10:49 -0700 Received: from erbenson.alaska.net (66-pm22.nwc.alaska.net [209.112.143.66]) by hob.acsalaska.net (8.12.9/8.12.9) with ESMTP id h6SAAjan048708 for ; Mon, 28 Jul 2003 02:10:45 -0800 (AKDT) (envelope-from erbenson@alaska.net) Received: from plato.local.lan (plato.local.lan [192.168.0.4]) by erbenson.alaska.net (Postfix) with ESMTP id 665A13A05 for ; Mon, 28 Jul 2003 02:10:44 -0800 (AKDT) Received: by plato.local.lan (Postfix, from userid 1000) id 9278140FF44; Mon, 28 Jul 2003 02:10:43 -0800 (AKDT) Date: Mon, 28 Jul 2003 02:10:43 -0800 From: Ethan Benson To: linux-xfs@oss.sgi.com Subject: Re: xfsdump/xfsrestore rpmbuild problems Message-ID: <20030728101043.GE6786@plato.local.lan> Mail-Followup-To: linux-xfs@oss.sgi.com References: Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="a+b56+3nqLzpiR9O" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.3.28i X-OS: Debian GNU X-gpg-fingerprint: E3E4 D0BC 31BC F7BB C1DD C3D6 24AC 7B1A 2C44 7AFC X-gpg-key: http://www.alaska.net/~erbenson/gpg/key.asc Mail-Copies-To: nobody X-No-CC: I subscribe to this list; do not CC me on replies. X-ACS-Spam-Status: no X-Scanned-By: MIMEDefang 2.34 X-archive-position: 4747 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: erbenson@alaska.net Precedence: bulk X-list: linux-xfs Content-Length: 1275 Lines: 48 --a+b56+3nqLzpiR9O Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Jul 28, 2003 at 10:05:33AM +0200, Kai Leibrandt wrote: > Hi all, >=20 > I just tried to go and rebuild xfsdump and xfsprogs from the 1.3pre4=20 > cmd_rpms, but xfsdump-2.2.13-0.src.rpm and xfsprogs-2.5.4-0.src.rpm both= =20 > fail due to uuid.h not being found: >=20 > ... > ... > checking for stdint.h... yes > checking for unistd.h... yes > checking uuid.h usability... no > checking uuid.h presence... no > checking for uuid.h... no > checking uuid/uuid.h usability... no > checking uuid/uuid.h presence... no > checking for uuid/uuid.h... no >=20 > FATAL ERROR: could not find a valid UUID header. > Install the Universally Unique Identifiers development package. try doing what its telling you to do and install uuid-dev --=20 Ethan Benson http://www.alaska.net/~erbenson/ --a+b56+3nqLzpiR9O Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iEYEARECAAYFAj8k9qMACgkQJKx7GixEevxp+ACfUeTzP9sMpnePWy8q9eqSaLkb txMAnjTpD0qp36LODP/iEx08tsP56zMr =nImj -----END PGP SIGNATURE----- --a+b56+3nqLzpiR9O-- From owner-linux-xfs@oss.sgi.com Mon Jul 28 05:48:13 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 28 Jul 2003 05:48:32 -0700 (PDT) Received: from unicorn.drogon.net (unicorn.drogon.net [195.10.246.4]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h6SCmBFl007000 for ; Mon, 28 Jul 2003 05:48:12 -0700 Received: from unicorn.drogon.net (localhost [127.0.0.1]) by unicorn.drogon.net (8.12.9/8.12.9) with ESMTP id h6SCm2Kd027816 for ; Mon, 28 Jul 2003 13:48:02 +0100 Received: from localhost (gordon@localhost) by unicorn.drogon.net (8.12.9/8.12.9/Submit) with ESMTP id h6SCm2bm027813 for ; Mon, 28 Jul 2003 13:48:02 +0100 X-Authentication-Warning: unicorn.drogon.net: gordon owned process doing -bs Date: Mon, 28 Jul 2003 13:48:02 +0100 (BST) From: Gordon Henderson To: linux-xfs@oss.sgi.com Subject: Booting off XFS, lilo corruption? In-Reply-To: <1056130527.26411.102.camel@jen.americas.sgi.com> Message-ID: References: <1056130527.26411.102.camel@jen.americas.sgi.com> Distribution: world Organization: Home for lost Drogons MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Scanned-By: MIMEDefang 2.35 X-archive-position: 4748 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: gordon@drogon.net Precedence: bulk X-list: linux-xfs Content-Length: 3702 Lines: 119 Is anyone using XFS with LILO to boot off? I've been using XFS for a short while now, but always just on the big data partitions on various servers I've built, keeping root, /usr on ext2 so I can use my debian recovery CD if ever required, but this time I thought I'd try an all-XFS system and have been having major headaches trying to get it to boot off an XFS partition. Heres the scoop: create a raid1 set, mkfs -t xfs it, then mount it under /mnt copy / onto it via cd / ; find -xdev | cpio -pm /mnt Edit /mnt/etc/fstab and /mnt/etc/lilo.conf to do the right things run lilo -r /mnt This is something I've done many times to get / onto a raid0 device with ext2. (Debian install doesn't support this directly - yet) At this point, the XFS is corrupt on it: lion:/# umount /mnt lion:/# mount /dev/md1 /mnt mount: you must specify the filesystem type lion:/# mount -t xfs /dev/md1 /mnt mount: wrong fs type, bad option, bad superblock on /dev/md1, or too many mounted file systems lion:/# xfs_check /dev/md1 xfs_check: unexpected XFS SB magic number 0xfae84200 bad superblock magic number fae84200, giving up Is Lilo incompatable with XFS? Complete sequence of events: lion:/# uname -a Linux lion 2.4.21-ac4 #3 Sun Jul 27 18:48:19 BST 2003 i686 unknown lion:/# cat /etc/issue Debian GNU/\s 3.0 \n \l lion:/# cat /usr/local/src/xfsprogs/VERSION # # This file is used by configure to get version information # PKG_MAJOR=2 PKG_MINOR=3 PKG_REVISION=9 PKG_BUILD=0 lion:/# mkfs -t xfs -f /dev/md1 meta-data=/dev/md1 isize=256 agcount=8, agsize=31121 blks = sectsz=512 data = bsize=4096 blocks=248968, imaxpct=0 = sunit=1 swidth=2 blks, unwritten=0 naming =version 2 bsize=4096 log =internal log bsize=4096 blocks=1200, version=1 = sectsz=512 sunit=1 blks realtime =none extsz=8192 blocks=0, rtextents=0 lion:/# mount /dev/md1 /mnt lion:/# find . -xdev | cpio -pm /mnt 240549 blocks lion:/# vi /mnt/etc/lilo.conf lion:/# vi /mnt/etc/fstab (in lilo.conf: boot=/dev/md1 root=/dev/md1 raid-extra-boot=/dev/hda,/dev/hdc in fstab: /dev/md1 / xfs errors=remount-ro 0 1 lion:/# lilo -r /mnt Warning: using BIOS device code 0x80 for RAID boot blocks Added Linux * Added Linux-1 Added Linux-2.4.21-0 Added Linux-2.4.18 Added Linux-Orig The boot record of /dev/md1 has been updated. The boot record of /dev/hda has been updated. Warning: /dev/hdc is not on the first disk The boot record of /dev/hdc has been updated. lion:/# ls /mnt archive boot dev floppy initrd lost+found opt root tmp var bin cdrom etc home lib mnt proc sbin usr lion:/# umount /mnt lion:/# mount /dev/md1 /mnt mount: you must specify the filesystem type lion:/# mount -t xfs /dev/md1 /mnt mount: wrong fs type, bad option, bad superblock on /dev/md1, or too many mounted file systems I don't think that raid1 has anything to do with it, as I can duplicate the results exactly when I stopped the RAID and just used /dev/hda2 on its own. I've also tried it the other way round - I moved root onto /dev/md1, (hda2, hdc2) and tired to make it work on the very first partition - both with raid1 and just a single drive and I get the same results every time. I feel I'm missing something obvious, but according to http://www.tldp.org/HOWTO/Linux+XFS-HOWTO/x154.html and http://oss.sgi.com/projects/xfs/xfsroot.html it ought to "just work". Any clues or observations would be appreciated Thanks, Gordon From owner-linux-xfs@oss.sgi.com Mon Jul 28 06:08:38 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 28 Jul 2003 06:08:42 -0700 (PDT) Received: from rems03.cluster1.charter.net (rems03.cluster1.charter.net [209.225.8.203]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h6SD8bFl013418 for ; Mon, 28 Jul 2003 06:08:38 -0700 Received: from [158.158.240.230] (account ) by rems03.cluster1.charter.net (CommuniGate Pro WebUser 4.0.6) with HTTP id 1828084 for ; Mon, 28 Jul 2003 09:08:32 -0400 From: "brett holcomb" Subject: Re: Booting off XFS, lilo corruption? To: linux-xfs@oss.sgi.com X-Mailer: CommuniGate Pro Web Mailer v.4.0.6 Date: Mon, 28 Jul 2003 09:08:32 -0400 Message-ID: In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1"; format="flowed" Content-Transfer-Encoding: 8bit X-archive-position: 4749 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: brettholcomb@charter.net Precedence: bulk X-list: linux-xfs Content-Length: 4070 Lines: 152 Yes, I have it on two systems running the Gentoo distribution. Works like a champ! On Mon, 28 Jul 2003 13:48:02 +0100 (BST) Gordon Henderson wrote: > >Is anyone using XFS with LILO to boot off? > >I've been using XFS for a short while now, but always >just on the big data >partitions on various servers I've built, keeping root, >/usr on ext2 so I >can use my debian recovery CD if ever required, but this >time I thought >I'd try an all-XFS system and have been having major >headaches trying to >get it to boot off an XFS partition. > >Heres the scoop: > > create a raid1 set, mkfs -t xfs it, then mount it >under /mnt > copy / onto it via cd / ; find -xdev | cpio -pm /mnt > Edit /mnt/etc/fstab and /mnt/etc/lilo.conf to do the >right things > run lilo -r /mnt > >This is something I've done many times to get / onto a >raid0 device with >ext2. (Debian install doesn't support this directly - >yet) > >At this point, the XFS is corrupt on it: > > lion:/# umount /mnt > lion:/# mount /dev/md1 /mnt > mount: you must specify the filesystem type > lion:/# mount -t xfs /dev/md1 /mnt > mount: wrong fs type, bad option, bad superblock on >/dev/md1, > or too many mounted file systems > lion:/# xfs_check /dev/md1 > xfs_check: unexpected XFS SB magic number 0xfae84200 > bad superblock magic number fae84200, giving up > > >Is Lilo incompatable with XFS? > >Complete sequence of events: > >lion:/# uname -a >Linux lion 2.4.21-ac4 #3 Sun Jul 27 18:48:19 BST 2003 >i686 unknown >lion:/# cat /etc/issue >Debian GNU/\s 3.0 \n \l > >lion:/# cat /usr/local/src/xfsprogs/VERSION ># ># This file is used by configure to get version >information ># >PKG_MAJOR=2 >PKG_MINOR=3 >PKG_REVISION=9 >PKG_BUILD=0 > >lion:/# mkfs -t xfs -f /dev/md1 >meta-data=/dev/md1 isize=256 agcount=8, >agsize=31121 blks > = sectsz=512 >data = bsize=4096 > blocks=248968, imaxpct=0 > = sunit=1 swidth=2 >blks, unwritten=0 >naming =version 2 bsize=4096 >log =internal log bsize=4096 > blocks=1200, version=1 > = sectsz=512 sunit=1 >blks >realtime =none extsz=8192 blocks=0, >rtextents=0 > >lion:/# mount /dev/md1 /mnt >lion:/# find . -xdev | cpio -pm /mnt >240549 blocks > >lion:/# vi /mnt/etc/lilo.conf >lion:/# vi /mnt/etc/fstab > >(in lilo.conf: > boot=/dev/md1 > root=/dev/md1 > raid-extra-boot=/dev/hda,/dev/hdc > >in fstab: > >/dev/md1 / xfs errors=remount-ro > 0 1 > >lion:/# lilo -r /mnt >Warning: using BIOS device code 0x80 for RAID boot blocks >Added Linux * >Added Linux-1 >Added Linux-2.4.21-0 >Added Linux-2.4.18 >Added Linux-Orig >The boot record of /dev/md1 has been updated. >The boot record of /dev/hda has been updated. >Warning: /dev/hdc is not on the first disk >The boot record of /dev/hdc has been updated. > >lion:/# ls /mnt >archive boot dev floppy initrd lost+found opt > root tmp var >bin cdrom etc home lib mnt proc > sbin usr >lion:/# umount /mnt >lion:/# mount /dev/md1 /mnt >mount: you must specify the filesystem type >lion:/# mount -t xfs /dev/md1 /mnt >mount: wrong fs type, bad option, bad superblock on >/dev/md1, > or too many mounted file systems > > >I don't think that raid1 has anything to do with it, as I >can duplicate >the results exactly when I stopped the RAID and just used >/dev/hda2 on its >own. I've also tried it the other way round - I moved >root onto /dev/md1, >(hda2, hdc2) and tired to make it work on the very first >partition - both >with raid1 and just a single drive and I get the same >results every time. > >I feel I'm missing something obvious, but according to > > http://www.tldp.org/HOWTO/Linux+XFS-HOWTO/x154.html >and > http://oss.sgi.com/projects/xfs/xfsroot.html > >it ought to "just work". > >Any clues or observations would be appreciated > >Thanks, > >Gordon > > From owner-linux-xfs@oss.sgi.com Mon Jul 28 06:15:36 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 28 Jul 2003 06:15:49 -0700 (PDT) Received: from batleth.sapienti-sat.org (batleth.sapienti-sat.org [80.190.100.240]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h6SDFOFl014284 for ; Mon, 28 Jul 2003 06:15:25 -0700 Received: from localhost (localhost.sapienti-sat.org [127.0.0.1]) by batleth.sapienti-sat.org (Postfix) with SMTP id C3CE2102553 for ; Mon, 28 Jul 2003 15:05:49 +0200 (CEST) Received: from koschikode.com (pD9E7E994.dip.t-dialin.net [217.231.233.148]) by batleth.sapienti-sat.org (Postfix) with ESMTP id 43EE7102547 for ; Mon, 28 Jul 2003 15:05:49 +0200 (CEST) Message-ID: <3F251FAB.7020400@koschikode.com> Date: Mon, 28 Jul 2003 15:05:47 +0200 From: Juri Haberland User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3.1) Gecko/20030425 X-Accept-Language: en, de-DE MIME-Version: 1.0 To: linux-xfs@oss.sgi.com Subject: Re: Booting off XFS, lilo corruption? References: <1056130527.26411.102.camel@jen.americas.sgi.com> In-Reply-To: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-archive-position: 4750 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: juri@koschikode.com Precedence: bulk X-list: linux-xfs Content-Length: 973 Lines: 27 Gordon Henderson wrote: > Is anyone using XFS with LILO to boot off? > > I've been using XFS for a short while now, but always just on the big data > partitions on various servers I've built, keeping root, /usr on ext2 so I > can use my debian recovery CD if ever required, but this time I thought > I'd try an all-XFS system and have been having major headaches trying to > get it to boot off an XFS partition. > > Heres the scoop: > > create a raid1 set, mkfs -t xfs it, then mount it under /mnt > copy / onto it via cd / ; find -xdev | cpio -pm /mnt > Edit /mnt/etc/fstab and /mnt/etc/lilo.conf to do the right things > run lilo -r /mnt > > This is something I've done many times to get / onto a raid0 device with > ext2. (Debian install doesn't support this directly - yet) > > At this point, the XFS is corrupt on it: You cannot install lilo into a XFS partition. Use the MBR instead. See http://oss.sgi.com/projects/xfs/faq.html#lilowork Cheers, Juri From owner-linux-xfs@oss.sgi.com Mon Jul 28 06:24:19 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 28 Jul 2003 06:24:22 -0700 (PDT) Received: from mail.ocs.com.au (mail.ocs.com.au [203.34.97.2]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h6SDOFFl015191 for ; Mon, 28 Jul 2003 06:24:17 -0700 Received: (qmail 9494 invoked from network); 28 Jul 2003 13:24:13 -0000 Received: from ocs3.intra.ocs.com.au (192.168.255.3) by mail.ocs.com.au with SMTP; 28 Jul 2003 13:24:13 -0000 Received: by ocs3.intra.ocs.com.au (Postfix, from userid 16331) id 076A9C21FC; Mon, 28 Jul 2003 23:24:13 +1000 (EST) Received: from ocs3.intra.ocs.com.au (localhost [127.0.0.1]) by ocs3.intra.ocs.com.au (Postfix) with ESMTP id 04005140697; Mon, 28 Jul 2003 23:24:13 +1000 (EST) X-Mailer: exmh version 2.5 01/15/2001 with nmh-1.0.4 From: Keith Owens To: Gordon Henderson Cc: linux-xfs@oss.sgi.com Subject: Re: Booting off XFS, lilo corruption? In-reply-to: Your message of "Mon, 28 Jul 2003 13:48:02 +0100." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 28 Jul 2003 23:24:11 +1000 Message-ID: <3707.1059398651@ocs3.intra.ocs.com.au> X-archive-position: 4751 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: kaos@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 916 Lines: 23 On Mon, 28 Jul 2003 13:48:02 +0100 (BST), Gordon Henderson wrote: >(in lilo.conf: > boot=/dev/md1 > root=/dev/md1 > raid-extra-boot=/dev/hda,/dev/hdc > >in fstab: > >/dev/md1 / xfs errors=remount-ro 0 1 Lilo and XFS coexist but only if lilo writes to the start of the disk, _NOT_ the start of the XFS partition. XFS keeps its superblock at the start of each partition, if anything overwrites that superblock that it breaks the XFS filesystem. All systems have XFS / and lilo works fine, with boot=/dev/hda, not boot=/dev/hda1. BTW,. you should be able to run xfs_repair on the broken filesystem and recover your data, xfs_repair will seach for a secondary superblock and reconstruct the one that lilo stamped on. Since this is /, you will need to boot an emergency system such as the install CD booted with 'linux rescue' then run xfs_repair on md1. From owner-linux-xfs@oss.sgi.com Mon Jul 28 09:31:37 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 28 Jul 2003 09:31:50 -0700 (PDT) Received: from flo.18rcarmes.fr (lns-th2-4f-81-56-213-72.adsl.proxad.net [81.56.213.72]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h6SGVZFl006117 for ; Mon, 28 Jul 2003 09:31:37 -0700 Received: from marco (marco.18rcarmes.fr [192.168.0.1]) by flo.18rcarmes.fr (Postfix) with ESMTP id 8C7425C57 for ; Mon, 28 Jul 2003 18:31:29 +0200 (CEST) From: Marc Cousin Reply-To: marc@mco.mine.nu To: linux-xfs@oss.sgi.com Subject: bug with chown with kernel 2.6.0-test1? Date: Mon, 28 Jul 2003 18:31:28 +0200 User-Agent: KMail/1.5.2 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200307281831.28840.marc@mco.mine.nu> X-archive-position: 4752 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: marc@mco.mine.nu Precedence: bulk X-list: linux-xfs Content-Length: 1026 Lines: 38 I don't know if : - This is the right place to report it - It is a bug I am having strange chown behaviour all the operations below are done as root ------------------------------------------------------- I first try it whith restrict chown to 1 fs.xfs.stats_clear = 0 fs.xfs.sync_interval = 30000 fs.xfs.error_level = 3 fs.xfs.panic_mask = 0 fs.xfs.irix_symlink_mode = 0 fs.xfs.irix_sgid_inherit = 0 fs.xfs.restrict_chown = 1 marco:/dvdrip# touch test marco:/dvdrip# chown marc test chown: changing ownership of `test': Operation not permitted ----------------------------------------------------- then with restrict chown to 0 marco:/dvdrip# touch test marco:/dvdrip# chown marc test marco:/dvdrip# chown root test chown: changing ownership of `test': Operation not permitted I don't think this is a normal behaviour (in either case), but the restrict chown is confusing me a little bit ... Meanwhile, I'm going to install 2.6.0-test2... :) -- "Some things don't need the thought people give them." -Hobbes From owner-linux-xfs@oss.sgi.com Mon Jul 28 09:57:56 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 28 Jul 2003 09:58:10 -0700 (PDT) Received: from zok.sgi.com (zok.SGI.COM [204.94.215.101]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h6SGvuFl006864 for ; Mon, 28 Jul 2003 09:57:56 -0700 Received: from flecktone.americas.sgi.com (flecktone.americas.sgi.com [192.48.203.135]) by zok.sgi.com (8.12.9/8.12.9/linux-outbound_gateway-1.1) with ESMTP id h6SGvoq0016433 for ; Mon, 28 Jul 2003 09:57:51 -0700 Received: from poppy-e236.americas.sgi.com (poppy-e236.americas.sgi.com [128.162.236.207]) by flecktone.americas.sgi.com (8.12.9/8.12.9/generic_config-1.2) with ESMTP id h6SGvoQK2427384; Mon, 28 Jul 2003 11:57:50 -0500 (CDT) Received: from stout.americas.sgi.com (stout.americas.sgi.com [128.162.232.50]) by poppy-e236.americas.sgi.com (8.12.9/SGI-server-1.8) with ESMTP id h6SGvoYk15831585; Mon, 28 Jul 2003 11:57:50 -0500 (CDT) Subject: Re: bug with chown with kernel 2.6.0-test1? From: Eric Sandeen To: marc@mco.mine.nu Cc: linux-xfs@oss.sgi.com In-Reply-To: <200307281831.28840.marc@mco.mine.nu> References: <200307281831.28840.marc@mco.mine.nu> Content-Type: text/plain Organization: Message-Id: <1059411469.28137.17.camel@stout.americas.sgi.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 (1.2.2-5) Date: 28 Jul 2003 11:57:50 -0500 Content-Transfer-Encoding: 7bit X-archive-position: 4753 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: sandeen@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 1337 Lines: 46 restrict_chown (the default) means that only root can "give away" files to another user via chown. But yes, this does look like a bug. -eric On Mon, 2003-07-28 at 11:31, Marc Cousin wrote: > I don't know if : > - This is the right place to report it > - It is a bug > > I am having strange chown behaviour > > all the operations below are done as root > ------------------------------------------------------- > I first try it whith restrict chown to 1 > > fs.xfs.stats_clear = 0 > fs.xfs.sync_interval = 30000 > fs.xfs.error_level = 3 > fs.xfs.panic_mask = 0 > fs.xfs.irix_symlink_mode = 0 > fs.xfs.irix_sgid_inherit = 0 > fs.xfs.restrict_chown = 1 > marco:/dvdrip# touch test > marco:/dvdrip# chown marc test > chown: changing ownership of `test': Operation not permitted > ----------------------------------------------------- > then with restrict chown to 0 > marco:/dvdrip# touch test > marco:/dvdrip# chown marc test > marco:/dvdrip# chown root test > chown: changing ownership of `test': Operation not permitted > > > I don't think this is a normal behaviour (in either case), but the restrict > chown is confusing me a little bit ... > > > > Meanwhile, I'm going to install 2.6.0-test2... :) -- Eric Sandeen [C]XFS for Linux http://oss.sgi.com/projects/xfs sandeen@sgi.com SGI, Inc. 651-683-3102 From owner-linux-xfs@oss.sgi.com Mon Jul 28 10:02:35 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 28 Jul 2003 10:02:37 -0700 (PDT) Received: from atl-ms1.megatrends.com (mail2.megatrends.com [155.229.80.16]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h6SH2YFl007337 for ; Mon, 28 Jul 2003 10:02:34 -0700 Received: by atl-ms1.megatrends.com with Internet Mail Service (5.5.2653.19) id ; Mon, 28 Jul 2003 13:16:24 -0400 Message-ID: <8CCBDD5583C50E4196F012E79439B45C058BE6@atl-ms1.megatrends.com> From: Suresh Grandhi To: linux-xfs@oss.sgi.com Subject: Linux XFS's ACL Patch Date: Mon, 28 Jul 2003 13:16:19 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain X-archive-position: 4754 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: Sureshg@ami.com Precedence: bulk X-list: linux-xfs Content-Length: 238 Lines: 12 Hi, I am using XFS 1.2 with Kernel 2.4.18. XFS 1.2 supports 25 ACEs per file or directory. Is it possible to increase the number of ACL entries to more than 100. Any patch or suggestion would be greatly appreciated. Thanks, Suresh. From owner-linux-xfs@oss.sgi.com Mon Jul 28 11:15:48 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 28 Jul 2003 11:16:05 -0700 (PDT) Received: from ahriman.bucharest.roedu.net (ahriman.Bucharest.roedu.net [141.85.128.71]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h6SIFlFl011491 for ; Mon, 28 Jul 2003 11:15:48 -0700 Received: (qmail 18842 invoked by uid 1000); 28 Jul 2003 18:43:54 -0000 Received: from localhost (sendmail-bs@127.0.0.1) by localhost with SMTP; 28 Jul 2003 18:43:54 -0000 Date: Mon, 28 Jul 2003 21:43:54 +0300 (EEST) From: Mihai RUSU X-X-Sender: To: Russell Cattelan cc: Subject: Re: ANNOUNCE XFS 1.3.0pre4 In-Reply-To: <1059169471.34654.113.camel@rose.americas.sgi.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 4755 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: dizzy@roedu.net Precedence: bulk X-list: linux-xfs Content-Length: 1610 Lines: 55 Hi Great job, I am starting to move some of the machines arround here on 2.4.21 XFS 1.3.0pre couse if any bugs are there they should pop-up before 1.3.0 final. One small issue I noticed after booting a 1.3.0pre4 kernel: SGI XFS 1.3.0pre2 with no debug enabled ^^^^^^^^ Is this just a forgotten "version.h" update somewhere or I have downloaded the wrong patches, here is what I used: linux-2.4.21-core-xfs-1.3.0.patch.gz md5: 2419f5558185577877f273dfbcc182ca linux-xfs-1.3.0pre4.patch.gz md5: 558ff6ee67125fb7f91304715136a283 Thanks for your support and Ill be back with any news after my tests running :) On 25 Jul 2003, Russell Cattelan wrote: > The 1.3.0 pre4 patches and latest RH9 errata kernel rpms are > available at: > ftp://oss.sgi.com/projects/xfs/Release-1.3/pre4/ > > The 1.3 xfs-cmds have also been updated to TOT xfs-cmds, since > there is no real reason not to bring them in sync. In other works > no major code changes, just a lot of cleanups and minor bug fixes. > > One significant update: xfs_copy is now installed by default. > > The kernel rpm's themselves have not had much testing so use > at your own risk. > > As far as the xfs codes goes, it goes through nightly regression > testing. > > As always please let us know of any issues. > If things go well pre4 should probably turn into actual XFS 1.3.0 > > -Russell Cattelan > > > > > > > ---------------------------- Mihai RUSU Disclaimer: Any views or opinions presented within this e-mail are solely those of the author and do not necessarily represent those of any company, unless otherwise specifically stated. From owner-linux-xfs@oss.sgi.com Mon Jul 28 11:35:10 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 28 Jul 2003 11:35:27 -0700 (PDT) Received: from flo.18rcarmes.fr (lns-th2-4f-81-56-213-72.adsl.proxad.net [81.56.213.72]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h6SIZ9Fl012942 for ; Mon, 28 Jul 2003 11:35:10 -0700 Received: from marco (marco.18rcarmes.fr [192.168.0.1]) by flo.18rcarmes.fr (Postfix) with ESMTP id 27DDE5BEC for ; Mon, 28 Jul 2003 20:35:03 +0200 (CEST) From: Marc Cousin Reply-To: marc@mco.mine.nu To: linux-xfs@oss.sgi.com Subject: Re: bug with chown with kernel 2.6.0-test1? Date: Mon, 28 Jul 2003 20:35:02 +0200 User-Agent: KMail/1.5.2 References: <200307281831.28840.marc@mco.mine.nu> <1059411469.28137.17.camel@stout.americas.sgi.com> In-Reply-To: <1059411469.28137.17.camel@stout.americas.sgi.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200307282035.02811.marc@mco.mine.nu> X-archive-position: 4756 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: marc@mco.mine.nu Precedence: bulk X-list: linux-xfs Content-Length: 1602 Lines: 53 It doesn't seem to be there anymore with 2.6.0-test2. Don't know what solved it, I didn't see anything related in the Changelog ... On Monday 28 July 2003 18:57, Eric Sandeen wrote: > restrict_chown (the default) means that only root can "give away" files > to another user via chown. > > But yes, this does look like a bug. > > -eric > > On Mon, 2003-07-28 at 11:31, Marc Cousin wrote: > > I don't know if : > > - This is the right place to report it > > - It is a bug > > > > I am having strange chown behaviour > > > > all the operations below are done as root > > ------------------------------------------------------- > > I first try it whith restrict chown to 1 > > > > fs.xfs.stats_clear = 0 > > fs.xfs.sync_interval = 30000 > > fs.xfs.error_level = 3 > > fs.xfs.panic_mask = 0 > > fs.xfs.irix_symlink_mode = 0 > > fs.xfs.irix_sgid_inherit = 0 > > fs.xfs.restrict_chown = 1 > > marco:/dvdrip# touch test > > marco:/dvdrip# chown marc test > > chown: changing ownership of `test': Operation not permitted > > ----------------------------------------------------- > > then with restrict chown to 0 > > marco:/dvdrip# touch test > > marco:/dvdrip# chown marc test > > marco:/dvdrip# chown root test > > chown: changing ownership of `test': Operation not permitted > > > > > > I don't think this is a normal behaviour (in either case), but the > > restrict chown is confusing me a little bit ... > > > > > > > > Meanwhile, I'm going to install 2.6.0-test2... :) -- If you care, you just get disappointed all the time. If you don't care nothing matters so you are never upset. -- Calvin From owner-linux-xfs@oss.sgi.com Mon Jul 28 12:40:28 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 28 Jul 2003 12:40:41 -0700 (PDT) Received: from tolkor.sgi.com (tolkor.SGI.COM [198.149.18.6]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h6SJePFl017167 for ; Mon, 28 Jul 2003 12:40:27 -0700 Received: from flecktone.americas.sgi.com (flecktone.americas.sgi.com [192.48.203.135]) by tolkor.sgi.com (8.12.9/8.12.9/linux-outbound_gateway-1.1) with ESMTP id h6SJxXsR027875 for ; Mon, 28 Jul 2003 14:59:33 -0500 Received: from daisy-e236.americas.sgi.com (daisy-e236.americas.sgi.com [128.162.236.214]) by flecktone.americas.sgi.com (8.12.9/8.12.9/generic_config-1.2) with ESMTP id h6SJeJQK2482286 for ; Mon, 28 Jul 2003 14:40:19 -0500 (CDT) Received: from sgi.com (chuckle.americas.sgi.com [128.162.241.66]) by daisy-e236.americas.sgi.com (8.12.9/SGI-server-1.8) with ESMTP id h6SJeIRn199571293 for ; Mon, 28 Jul 2003 14:40:18 -0500 (CDT) Received: from chuckle.americas.sgi.com (localhost [127.0.0.1]) by sgi.com (8.12.8/8.12.8) with ESMTP id h6SJeICV019097 for ; Mon, 28 Jul 2003 14:40:18 -0500 Received: (from cattelan@localhost) by chuckle.americas.sgi.com (8.12.8/8.12.8/Submit) id h6SJeIYk019095 for linux-xfs@oss.sgi.com; Mon, 28 Jul 2003 14:40:18 -0500 Date: Mon, 28 Jul 2003 14:40:18 -0500 From: Russell Cattelan Message-Id: <200307281940.h6SJeIYk019095@chuckle.americas.sgi.com> Subject: TAKE - Update to version 1.3.0pre4 X-archive-position: 4757 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: cattelan@chuckle.americas.sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 272 Lines: 11 Date: Mon Jul 28 12:40:01 PDT 2003 Workarea: chuckle.americas.sgi.com:/go/xfs2/XFS/x2.4-xfs-r1.3 The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs-r1.3 Modid: 2.4.x-xfs-r1.3:slinx:154396a linux/fs/xfs/linux/xfs_version.h - 1.169 From owner-linux-xfs@oss.sgi.com Mon Jul 28 14:08:03 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 28 Jul 2003 14:08:16 -0700 (PDT) Received: from sol.rune.org (sol.rune.org [207.201.197.191]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h6SL81Fl023248 for ; Mon, 28 Jul 2003 14:08:02 -0700 Received: from localhost (sarwer@localhost) by sol.rune.org (8.11.6/8.11.6) with ESMTP id h6SL80P09854 for ; Mon, 28 Jul 2003 17:08:00 -0400 Date: Mon, 28 Jul 2003 17:07:59 -0400 (EDT) From: Sarwer Zafiruddin To: Subject: FreeBSD and XFS Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 4758 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: sarwer.zafiruddin@rune.org Precedence: bulk X-list: linux-xfs Content-Length: 327 Lines: 11 All, Just out of curiosity, I have seen some "TAKE" where there has been some XFS code modifications for portability to FreeBSD (or am I assuming the wrong thing?). If this is true, is there a project webpage where someone can point me to? How far is this from being a reality and who's doing the port? Thanks, Sarwer From owner-linux-xfs@oss.sgi.com Mon Jul 28 17:08:11 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 28 Jul 2003 17:08:24 -0700 (PDT) Received: from rj.sgi.com (rj.SGI.COM [192.82.208.96]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h6T08BFl004018 for ; Mon, 28 Jul 2003 17:08:11 -0700 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.54.149]) by rj.sgi.com (8.12.9/8.12.9/linux-outbound_gateway-1.1) with ESMTP id h6SM8YMM014464 for ; Mon, 28 Jul 2003 15:08:34 -0700 Received: from snort.melbourne.sgi.com (localhost [127.0.0.1]) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id h6T083JA7125265 for ; Tue, 29 Jul 2003 10:08:03 +1000 (EST) Received: (from nathans@localhost) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id h6T082M46672541 for linux-xfs@oss.sgi.com; Tue, 29 Jul 2003 10:08:02 +1000 (EST) Date: Tue, 29 Jul 2003 10:08:02 +1000 (EST) From: Nathan Scott Message-Id: <200307290008.h6T082M46672541@snort.melbourne.sgi.com> To: linux-xfs@oss.sgi.com Subject: TAKE - remove "illegal" for Alan X-archive-position: 4759 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: nathans@snort.melbourne.sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 548 Lines: 19 Change any references to legal/illegal into valid/invalid; apparently this was bad, mkaay? Date: Mon Jul 28 17:04:41 PDT 2003 Workarea: snort.melbourne.sgi.com:/home/nathans/clean-2.4.x-xfs The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: xfs-linux:slinx:154430a linux/fs/xfs/xfsidbg.c - 1.231 linux/fs/xfs/xfs_log.c - 1.278 linux/fs/xfs/xfs_log_priv.h - 1.97 linux/fs/xfs/xfs_log_recover.c - 1.275 linux/fs/xfs/xfs_inode.c - 1.381 linux/fs/xfs/xfs_trans.c - 1.151 linux/fs/xfs/xfs_bmap.c - 1.307 From owner-linux-xfs@oss.sgi.com Mon Jul 28 17:29:02 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 28 Jul 2003 17:29:22 -0700 (PDT) Received: from zok.sgi.com (zok.SGI.COM [204.94.215.101]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h6T0T2Fl005616 for ; Mon, 28 Jul 2003 17:29:02 -0700 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by zok.sgi.com (8.12.9/8.12.9/linux-outbound_gateway-1.1) with SMTP id h6T0Srq0013700 for ; Mon, 28 Jul 2003 17:28:54 -0700 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 KAA17749; Tue, 29 Jul 2003 10:28:52 +1000 Received: from frodo.melbourne.sgi.com (root@frodo.melbourne.sgi.com [134.14.55.153]) by wobbly.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id h6T0So3K212018; Tue, 29 Jul 2003 10:28:51 +1000 (EST) Received: from frodo.melbourne.sgi.com (nathans@localhost [127.0.0.1]) by frodo.melbourne.sgi.com (8.12.9/8.12.9/Debian-3) with ESMTP id h6T0Rxdm001158; Tue, 29 Jul 2003 10:27:59 +1000 Received: (from nathans@localhost) by frodo.melbourne.sgi.com (8.12.9/8.12.9/Debian-3) id h6T0RxSn001156; Tue, 29 Jul 2003 10:27:59 +1000 Date: Tue, 29 Jul 2003 10:27:59 +1000 From: Nathan Scott To: Suresh Grandhi Cc: linux-xfs@oss.sgi.com Subject: Re: Linux XFS's ACL Patch Message-ID: <20030729002759.GB763@frodo> References: <8CCBDD5583C50E4196F012E79439B45C058BE6@atl-ms1.megatrends.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <8CCBDD5583C50E4196F012E79439B45C058BE6@atl-ms1.megatrends.com> User-Agent: Mutt/1.5.3i X-archive-position: 4760 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: nathans@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 637 Lines: 21 On Mon, Jul 28, 2003 at 01:16:19PM -0400, Suresh Grandhi wrote: > Hi, > > I am using XFS 1.2 with Kernel 2.4.18. > > XFS 1.2 supports 25 ACEs per file or directory. Is it possible to increase > the number of ACL entries to more than 100. Not without a patch to XFS which changes the ondisk format of ACLs (in a way that is incompatible with IRIX and all existing Linux XFS installations, unfortunately) - there is such a patch somewhere in the archives but its unlikely to ever been incorporated. You will also have problems with xfs_repair considering these ACLs as being corrupt (which, in a way, they are). cheers. -- Nathan From owner-linux-xfs@oss.sgi.com Mon Jul 28 17:31:47 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 28 Jul 2003 17:31:51 -0700 (PDT) Received: from rj.sgi.com (rj.SGI.COM [192.82.208.96]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h6T0VlFl006202 for ; Mon, 28 Jul 2003 17:31:47 -0700 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by rj.sgi.com (8.12.9/8.12.9/linux-outbound_gateway-1.1) with SMTP id h6SMW9MM017290 for ; Mon, 28 Jul 2003 15:32:10 -0700 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 KAA17791; Tue, 29 Jul 2003 10:31:37 +1000 Received: from frodo.melbourne.sgi.com (root@frodo.melbourne.sgi.com [134.14.55.153]) by wobbly.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id h6T0VZ3K213478; Tue, 29 Jul 2003 10:31:36 +1000 (EST) Received: from frodo.melbourne.sgi.com (nathans@localhost [127.0.0.1]) by frodo.melbourne.sgi.com (8.12.9/8.12.9/Debian-3) with ESMTP id h6T0Uidm001195; Tue, 29 Jul 2003 10:30:44 +1000 Received: (from nathans@localhost) by frodo.melbourne.sgi.com (8.12.9/8.12.9/Debian-3) id h6T0UeN0001193; Tue, 29 Jul 2003 10:30:40 +1000 Date: Tue, 29 Jul 2003 10:30:40 +1000 From: Nathan Scott To: Sarwer Zafiruddin Cc: linux-xfs@oss.sgi.com Subject: Re: FreeBSD and XFS Message-ID: <20030729003040.GC763@frodo> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.3i X-archive-position: 4761 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: nathans@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 414 Lines: 16 On Mon, Jul 28, 2003 at 05:07:59PM -0400, Sarwer Zafiruddin wrote: > All, > > Just out of curiosity, I have seen some "TAKE" where there has been some > XFS code modifications for portability to FreeBSD (or am I assuming the > wrong thing?). There were some updates to xfsprogs to get those user tools to compile on FreeBSD (so you can now use xfs_repair, xfs_db, and co. under FreeBSD). cheers. -- Nathan From owner-linux-xfs@oss.sgi.com Mon Jul 28 18:22:19 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 28 Jul 2003 18:22:22 -0700 (PDT) Received: from zok.sgi.com (zok.SGI.COM [204.94.215.101]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h6T1MHFl009448 for ; Mon, 28 Jul 2003 18:22:19 -0700 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.54.149]) by zok.sgi.com (8.12.9/8.12.9/linux-outbound_gateway-1.1) with ESMTP id h6T1M9q0020384 for ; Mon, 28 Jul 2003 18:22:11 -0700 Received: from snort.melbourne.sgi.com (localhost [127.0.0.1]) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id h6T1M7JA7146791; Tue, 29 Jul 2003 11:22:08 +1000 (EST) Received: (from nathans@localhost) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id h6T1M6ag7143931; Tue, 29 Jul 2003 11:22:06 +1000 (EST) Date: Tue, 29 Jul 2003 11:22:06 +1000 (EST) From: Nathan Scott Message-Id: <200307290122.h6T1M6ag7143931@snort.melbourne.sgi.com> To: linux-xfs@oss.sgi.com Cc: agruen@suse.de Subject: TAKE - attr X-archive-position: 4762 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: nathans@snort.melbourne.sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 524 Lines: 19 Little attr libmisc update from Andreas to ensure we dont exit from the library. Date: Mon Jul 28 18:21:25 PDT 2003 Workarea: snort.melbourne.sgi.com:/home/nathans/clean-2.4.x-xfs The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: xfs-cmds:slinx:154438a cmd/attr/VERSION - 1.36 cmd/attr/doc/CHANGES - 1.45 cmd/attr/debian/changelog - 1.39 cmd/attr/setfattr/setfattr.c - 1.14 cmd/attr/getfattr/getfattr.c - 1.21 cmd/attr/libmisc/unquote.c - 1.2 cmd/attr/libmisc/quote.c - 1.2 From owner-linux-xfs@oss.sgi.com Mon Jul 28 18:57:58 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 28 Jul 2003 18:58:13 -0700 (PDT) Received: from rj.sgi.com (rj.SGI.COM [192.82.208.96]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h6T1vwFl011727 for ; Mon, 28 Jul 2003 18:57:58 -0700 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.54.149]) by rj.sgi.com (8.12.9/8.12.9/linux-outbound_gateway-1.1) with ESMTP id h6SNwLMM029011 for ; Mon, 28 Jul 2003 16:58:22 -0700 Received: from snort.melbourne.sgi.com (localhost [127.0.0.1]) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id h6T1voJA7094846; Tue, 29 Jul 2003 11:57:50 +1000 (EST) Received: (from nathans@localhost) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id h6T1vnd67184128; Tue, 29 Jul 2003 11:57:49 +1000 (EST) Date: Tue, 29 Jul 2003 11:57:49 +1000 (EST) From: Nathan Scott Message-Id: <200307290157.h6T1vnd67184128@snort.melbourne.sgi.com> To: linux-xfs@oss.sgi.com Cc: agruen@suse.de Subject: TAKE - acl X-archive-position: 4763 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: nathans@snort.melbourne.sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 1376 Lines: 46 ACL update from AG - libmisc routines, numerous test updates. Date: Mon Jul 28 18:55:43 PDT 2003 Workarea: snort.melbourne.sgi.com:/home/nathans/clean-2.4.x-xfs The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: xfs-cmds:slinx:154441a cmd/acl/libmisc/unquote.c - 1.1 cmd/acl/test/permissions.test - 1.1 cmd/acl/test/nfsacl.test - 1.1 cmd/acl/test/nfs-dir.test - 1.1 cmd/acl/test/cp.test - 1.1 cmd/acl/libmisc/quote.c - 1.1 cmd/acl/libmisc/high_water_alloc.c - 1.1 cmd/acl/libmisc/Makefile - 1.1 cmd/acl/include/misc.h - 1.1 cmd/acl/Makefile - 1.17 cmd/acl/VERSION - 1.52 cmd/acl/doc/CHANGES - 1.60 cmd/acl/include/Makefile - 1.12 cmd/acl/include/builddefs.in - 1.26 cmd/acl/debian/changelog - 1.46 cmd/acl/libacl/Makefile - 1.23 cmd/acl/setfacl/setfacl.c - 1.10 cmd/acl/setfacl/parse.c - 1.5 cmd/acl/setfacl/Makefile - 1.10 cmd/acl/libacl/acl_from_text.c - 1.5 cmd/acl/getfacl/getfacl.c - 1.12 cmd/acl/getfacl/Makefile - 1.10 cmd/acl/test/Makefile - 1.6 cmd/acl/test/perm.test - 1.2 cmd/acl/test/asroot.test - 1.2 cmd/acl/examples/get-acl.c - 1.2 cmd/acl/test/fileutil.test - 1.2 cmd/acl/test/setfacl.test - 1.5 cmd/acl/test/misc.test - 1.3 cmd/acl/test/getfacl-noacl.test - 1.3 cmd/acl/test/setfacl-noacl.test - 1.2 cmd/acl/test/run - 1.4 cmd/acl/test/mode - 1.2 cmd/acl/libacl/__acl_to_any_text.c - 1.3 cmd/acl/exports - 1.2 From owner-linux-xfs@oss.sgi.com Mon Jul 28 22:15:28 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 28 Jul 2003 22:15:45 -0700 (PDT) Received: from mail.epost.de (mail.epost.de [193.28.100.187] (may be forged)) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h6T5FQFl018034 for ; Mon, 28 Jul 2003 22:15:27 -0700 Received: from epost.de (217.110.232.6) by mail.epost.de (6.7.015) (authenticated as rainer.traut@epost.de) id 3F0CDA8900196081 for linux-xfs@oss.sgi.com; Tue, 29 Jul 2003 07:15:25 +0200 Message-ID: <3F26039C.3010407@epost.de> Date: Tue, 29 Jul 2003 07:18:20 +0200 From: Rainer Traut User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5a) Gecko/20030718 X-Accept-Language: de, en-us, en MIME-Version: 1.0 To: linux-xfs@oss.sgi.com Subject: Redhat 8 kernel rpms with xfs Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 4764 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: rainer.traut@epost.de Precedence: bulk X-list: linux-xfs Content-Length: 166 Lines: 10 Hi, thanks to Simon Matter, he made latest Redhat Kernels with xfs 1.2. I put them up here: http://xfs.rainer-traut.de/2.4.20-19.8.SGI_XFS_1.2.0/ Thank you Rainer From owner-linux-xfs@oss.sgi.com Mon Jul 28 23:58:46 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 28 Jul 2003 23:58:59 -0700 (PDT) Received: from pechkin.minfin.bg (pechkin.minfin.bg [212.122.164.10]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h6T6wiFl024364 for ; Mon, 28 Jul 2003 23:58:45 -0700 Received: (qmail 23338 invoked by uid 64014); 29 Jul 2003 06:58:41 -0000 Received: from larry@minfin.bg by mail.minfin.bg by uid 64011 with qmail-scanner-1.15 (fsecure: 4.14/4062/ Clear:. Processed in 0.860935 secs); 29 Jul 2003 06:58:41 -0000 Received: from unknown (HELO larry2) (10.40.1.15) by pechkin.minfin.bg with SMTP; 29 Jul 2003 06:58:40 -0000 Reply-To: From: "Kostadin Todorov Karaivanov" To: Subject: The infamous BUG in page_buff.c Date: Tue, 29 Jul 2003 09:58:42 +0300 Organization: Ministry of Finance Message-ID: <012c01c3559e$d8c356e0$0f01280a@minfin.bg> MIME-Version: 1.0 Content-Type: text/plain; charset="koi8-r" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2627 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Importance: Normal X-archive-position: 4765 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: larry@minfin.bg Precedence: bulk X-list: linux-xfs Content-Length: 506 Lines: 16 Short summary: I have seen at least 3 reports for , I beleave, same BUG. one of witch is mine. It's present since 2.5.6x till now. I know you are focused on 2.4 branch but still... reference: http://marc.theaimsgroup.com/?l=linux-kernel&m=105941333012271&w=2 http://www.ussg.iu.edu/hypermail/linux/kernel/0306.3/0357.html http://marc.theaimsgroup.com/?l=linux-xfs&m=105410871804737&w=2 Kostadin Karaivanov Senior System Administrator @ Ministry Of Finance tel: +359 2 98592062 k.karaivanov@minfin.bg From owner-linux-xfs@oss.sgi.com Tue Jul 29 00:18:51 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 29 Jul 2003 00:19:12 -0700 (PDT) Received: from tolkor.sgi.com ([198.149.18.6]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h6T7InFl026124 for ; Tue, 29 Jul 2003 00:18:49 -0700 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by tolkor.sgi.com (8.12.9/8.12.9/linux-outbound_gateway-1.1) with SMTP id h6T7bvsR025528 for ; Tue, 29 Jul 2003 02:37:58 -0500 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 RAA03346; Tue, 29 Jul 2003 17:18:35 +1000 Received: from wobbly.melbourne.sgi.com (localhost [127.0.0.1]) by wobbly.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id h6T7IX3K127766; Tue, 29 Jul 2003 17:18:33 +1000 (EST) Received: (from nathans@localhost) by wobbly.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id h6T7IVwk213068; Tue, 29 Jul 2003 17:18:31 +1000 (EST) Date: Tue, 29 Jul 2003 17:18:31 +1000 From: Nathan Scott To: k.karaivanov@minfin.bg Cc: linux-xfs@oss.sgi.com Subject: Re: The infamous BUG in page_buff.c Message-ID: <20030729171831.A213462@wobbly.melbourne.sgi.com> References: <012c01c3559e$d8c356e0$0f01280a@minfin.bg> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <012c01c3559e$d8c356e0$0f01280a@minfin.bg>; from larry@minfin.bg on Tue, Jul 29, 2003 at 09:58:42AM +0300 X-archive-position: 4766 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: nathans@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 560 Lines: 19 On Tue, Jul 29, 2003 at 09:58:42AM +0300, Kostadin Todorov Karaivanov wrote: > Short summary: > I have seen at least 3 reports for , I beleave, same BUG. > one of witch is mine. It's present since 2.5.6x till now. > I know you are focused on 2.4 branch but still... > > reference: > http://marc.theaimsgroup.com/?l=linux-kernel&m=105941333012271&w=2 > http://www.ussg.iu.edu/hypermail/linux/kernel/0306.3/0357.html > http://marc.theaimsgroup.com/?l=linux-xfs&m=105410871804737&w=2 > A reproducible test case would be a big help here. thanks. -- Nathan From owner-linux-xfs@oss.sgi.com Tue Jul 29 00:20:19 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 29 Jul 2003 00:20:44 -0700 (PDT) Received: from hermod.slb.nwc.acsalaska.net (hermod.slb.nwc.acsalaska.net [209.112.155.45]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h6T7KIFl026500 for ; Tue, 29 Jul 2003 00:20:19 -0700 Received: from erbenson.alaska.net (224-pm16.nwc.alaska.net [209.112.141.224]) by hermod.slb.nwc.acsalaska.net (8.12.9/8.12.9) with ESMTP id h6T7KGFx040349 for ; Mon, 28 Jul 2003 23:20:16 -0800 (AKDT) (envelope-from erbenson@alaska.net) Received: from plato.local.lan (plato.local.lan [192.168.0.4]) by erbenson.alaska.net (Postfix) with ESMTP id 9F40C3A07 for ; Mon, 28 Jul 2003 23:20:15 -0800 (AKDT) Received: by plato.local.lan (Postfix, from userid 1000) id 5311F40FF44; Mon, 28 Jul 2003 23:20:15 -0800 (AKDT) Date: Mon, 28 Jul 2003 23:20:15 -0800 From: Ethan Benson To: linux-xfs@oss.sgi.com Subject: Re: bug with chown with kernel 2.6.0-test1? Message-ID: <20030729072015.GG6786@plato.local.lan> Mail-Followup-To: linux-xfs@oss.sgi.com References: <200307281831.28840.marc@mco.mine.nu> <1059411469.28137.17.camel@stout.americas.sgi.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="df+09Je9rNq3P+GE" Content-Disposition: inline In-Reply-To: <1059411469.28137.17.camel@stout.americas.sgi.com> User-Agent: Mutt/1.3.28i X-OS: Debian GNU X-gpg-fingerprint: E3E4 D0BC 31BC F7BB C1DD C3D6 24AC 7B1A 2C44 7AFC X-gpg-key: http://www.alaska.net/~erbenson/gpg/key.asc Mail-Copies-To: nobody X-No-CC: I subscribe to this list; do not CC me on replies. X-ACS-Spam-Status: no X-Scanned-By: MIMEDefang 2.34 X-archive-position: 4767 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: erbenson@alaska.net Precedence: bulk X-list: linux-xfs Content-Length: 1695 Lines: 62 --df+09Je9rNq3P+GE Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Jul 28, 2003 at 11:57:50AM -0500, Eric Sandeen wrote: > restrict_chown (the default) means that only root can "give away" files > to another user via chown. >=20 > But yes, this does look like a bug. what does? appears to be correct behavior to me: > > fs.xfs.restrict_chown =3D 1 > > marco:/dvdrip# touch test > > marco:/dvdrip# chown marc test > > chown: changing ownership of `test': Operation not permitted marco !=3D root && marco !=3D marc, chown not permitted. > > ----------------------------------------------------- > > then with restrict chown to 0 > > marco:/dvdrip# touch test > > marco:/dvdrip# chown marc test !restrict_chown, this chown permitted. > > marco:/dvdrip# chown root test > > chown: changing ownership of `test': Operation not permitted marco !=3D root && marco !=3D marc which is now the owner of the file, due to previous chown, you can't chown a file you don't own under any circumstances. chown not permitted. > >=20 > > I don't think this is a normal behaviour (in either case), but the rest= rict=20 > > chown is confusing me a little bit ... looks normal and correct to me. maybe im missing something. --=20 Ethan Benson http://www.alaska.net/~erbenson/ --df+09Je9rNq3P+GE Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iEYEARECAAYFAj8mIC8ACgkQJKx7GixEevwQBwCfeObHYG4t08MdoXO40Q4e5KAY c9kAn3weGFZXrPJtNjWN1BLyO0za4MNQ =ynYH -----END PGP SIGNATURE----- --df+09Je9rNq3P+GE-- From owner-linux-xfs@oss.sgi.com Tue Jul 29 00:21:28 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 29 Jul 2003 00:21:34 -0700 (PDT) Received: from hermod.slb.nwc.acsalaska.net (hermod.slb.nwc.acsalaska.net [209.112.155.45]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h6T7LRFl026921 for ; Tue, 29 Jul 2003 00:21:27 -0700 Received: from erbenson.alaska.net (224-pm16.nwc.alaska.net [209.112.141.224]) by hermod.slb.nwc.acsalaska.net (8.12.9/8.12.9) with ESMTP id h6T7LPFx041017 for ; Mon, 28 Jul 2003 23:21:26 -0800 (AKDT) (envelope-from erbenson@alaska.net) Received: from plato.local.lan (plato.local.lan [192.168.0.4]) by erbenson.alaska.net (Postfix) with ESMTP id 0061B3A07 for ; Mon, 28 Jul 2003 23:21:24 -0800 (AKDT) Received: by plato.local.lan (Postfix, from userid 1000) id D4E7540FF44; Mon, 28 Jul 2003 23:21:24 -0800 (AKDT) Date: Mon, 28 Jul 2003 23:21:24 -0800 From: Ethan Benson To: linux-xfs@oss.sgi.com Subject: Re: Linux XFS's ACL Patch Message-ID: <20030729072124.GH6786@plato.local.lan> Mail-Followup-To: linux-xfs@oss.sgi.com References: <8CCBDD5583C50E4196F012E79439B45C058BE6@atl-ms1.megatrends.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="fd5uyaI9j6xoeUBo" Content-Disposition: inline In-Reply-To: <8CCBDD5583C50E4196F012E79439B45C058BE6@atl-ms1.megatrends.com> User-Agent: Mutt/1.3.28i X-OS: Debian GNU X-gpg-fingerprint: E3E4 D0BC 31BC F7BB C1DD C3D6 24AC 7B1A 2C44 7AFC X-gpg-key: http://www.alaska.net/~erbenson/gpg/key.asc Mail-Copies-To: nobody X-No-CC: I subscribe to this list; do not CC me on replies. X-ACS-Spam-Status: no X-Scanned-By: MIMEDefang 2.34 X-archive-position: 4768 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: erbenson@alaska.net Precedence: bulk X-list: linux-xfs Content-Length: 900 Lines: 35 --fd5uyaI9j6xoeUBo Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Jul 28, 2003 at 01:16:19PM -0400, Suresh Grandhi wrote: > Hi, >=20 > I am using XFS 1.2 with Kernel 2.4.18.=20 >=20 > XFS 1.2 supports 25 ACEs per file or directory. Is it possible to increase > the number of ACL entries to more than 100. if you need that many ACEs you need to rethink your security model, what you really should be using are groups. --=20 Ethan Benson http://www.alaska.net/~erbenson/ --fd5uyaI9j6xoeUBo Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iEYEARECAAYFAj8mIHQACgkQJKx7GixEevyHCgCeOU7aO7attLoWoY3hZNIEPwfi /d8An0a2jLfnLep1yyKGf8deP5EwcqpU =5338 -----END PGP SIGNATURE----- --fd5uyaI9j6xoeUBo-- From owner-linux-xfs@oss.sgi.com Tue Jul 29 01:14:08 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 29 Jul 2003 01:14:23 -0700 (PDT) Received: from pechkin.minfin.bg (pechkin.minfin.bg [212.122.164.10]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h6T8E6Fl029781 for ; Tue, 29 Jul 2003 01:14:07 -0700 Received: (qmail 30609 invoked by uid 64014); 29 Jul 2003 08:14:04 -0000 Received: from larry@minfin.bg by mail.minfin.bg by uid 64011 with qmail-scanner-1.15 (fsecure: 4.14/4062/ Clear:. Processed in 0.82532 secs); 29 Jul 2003 08:14:04 -0000 Received: from unknown (HELO larry2) (10.40.1.15) by pechkin.minfin.bg with SMTP; 29 Jul 2003 08:14:03 -0000 Reply-To: From: "Kostadin Todorov Karaivanov" To: Subject: FW: The infamous BUG in page_buff.c Date: Tue, 29 Jul 2003 11:14:05 +0300 Organization: Ministry of Finance Message-ID: <014a01c355a9$60d08c60$0f01280a@minfin.bg> MIME-Version: 1.0 Content-Type: text/plain; charset="koi8-r" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2627 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Importance: Normal X-archive-position: 4769 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: larry@minfin.bg Precedence: bulk X-list: linux-xfs Content-Length: 1590 Lines: 50 Sorry for the repost I forgot to cc the list..... -----Original Message----- From: Kostadin Todorov Karaivanov [mailto:larry@minfin.bg] Sent: Tuesday, July 29, 2003 10:52 AM To: 'Nathan Scott' Subject: RE: The infamous BUG in page_buff.c > -----Original Message----- > From: Nathan Scott [mailto:nathans@sgi.com] > Sent: Tuesday, July 29, 2003 10:19 AM > To: k.karaivanov@minfin.bg > Cc: linux-xfs@oss.sgi.com > Subject: Re: The infamous BUG in page_buff.c > > > On Tue, Jul 29, 2003 at 09:58:42AM +0300, Kostadin Todorov > Karaivanov wrote: > > Short summary: > > I have seen at least 3 reports for , I beleave, same BUG. one of > > witch is mine. It's present since 2.5.6x till now. I know you are > > focused on 2.4 branch but still... > > > > reference: > > http://marc.theaimsgroup.com/?l=linux-kernel&m=105941333012271&w=2 > > http://www.ussg.iu.edu/hypermail/linux/kernel/0306.3/0357.html > > http://marc.theaimsgroup.com/?l=linux-xfs&m=105410871804737&w=2 > > > > A reproducible test case would be a big help here. Alas it's not so easy, at least for me. Sometimes it happens while I sit quietly and do nothing on that PC the other time it happens when I recompile kernel. To catch my oops I was forced to make an endless loop of kernel make bzImage; make modules; make clean on the other hand yesterday I try the same, plus some postgresql benchmarks in the background just to higher the load and nothing happened, 2 hours later when I have given up and stop all the tnings and when I was doing REALY nothing the machine dies 8-( . > > thanks. > > -- > Nathan > From owner-linux-xfs@oss.sgi.com Tue Jul 29 05:09:24 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 29 Jul 2003 05:09:43 -0700 (PDT) Received: from eins.siemens.at (eins.siemens.at [193.81.246.11]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h6TC9MFl020383 for ; Tue, 29 Jul 2003 05:09:23 -0700 Received: from scesie13.sie.siemens.at (forix [10.1.140.2]) by eins.siemens.at (8.12.9/8.12.8) with ESMTP id h6TC9GcJ005565 for ; Tue, 29 Jul 2003 14:09:16 +0200 Received: from siemens.com (atws15tc.sie.siemens.at [158.226.135.41]) by scesie13.sie.siemens.at (8.12.9/8.12.1) with ESMTP id h6TC9Emv023162 for ; Tue, 29 Jul 2003 14:09:15 +0200 (MET DST) Message-ID: <3F26644D.3010200@siemens.com> Date: Tue, 29 Jul 2003 14:10:53 +0200 From: Matus Lovecky Organization: Siemens Inc User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: sk, cs, en, en-us MIME-Version: 1.0 To: linux-xfs@oss.sgi.com Subject: mkfs.xfs problem Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 4770 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: matus.a.lovecky@siemens.com Precedence: bulk X-list: linux-xfs Content-Length: 2698 Lines: 86 Hallo, I have a following problem: when I try to mkfs.xfs my /dev/sda1, I got an error message saing: mkfs.xfs: /dev/sda1 contains a mounted filesystem but this is not thuth according to cat /etc/mtab: any helpful suggestions? Thank you m. root@local ~ >fdisk /dev/sda Command (m for help): p Disk /dev/sda: 255 heads, 63 sectors, 243 cylinders Units = cylinders of 16065 * 512 bytes Device Boot Start End Blocks Id System /dev/sda1 1 243 1951897 83 Linux Command (m for help): q root@local ~ > root@local ~ > root@local ~ > root@local ~ > root@local ~ > root@local ~ > root@local ~ > root@local ~ >cat /etc/mtab /dev/hda1 / ext3 rw 0 0 none /dev/pts devpts rw,gid=5,mode=620 0 0 none /proc proc rw 0 0 /mnt/hdc1 /home none rw,bind 0 0 /dev/hdb1 /mnt/hdb1 xfs rw 0 0 /dev/hdc1 /mnt/hdc1 xfs rw 0 0 /mnt/hdc1 /home none rw,bind 0 0 /mnt/hdb1 /home/matus none rw,bind 0 0 /home/mina/_doc/knihy /home/pub/knihy none rw,bind 0 0 /mnt/hdc1 /home none rw,bind 0 0 /mnt/hdb1 /home/mina none rw,bind 0 0 /home/mina/_doc/knihy /home/pub/knihy none rw,bind 0 0 /home/mina/_mm/mov/filmy /home/pub/mov none rw,bind 0 0 root@local ~ > root@local ~ > root@local ~ > root@local ~ > root@local ~ > root@local ~ > root@local ~ > root@local ~ >mkfs.xfs -V mkfs.xfs version 2.3.9 root@local ~ > root@local ~ > root@local ~ > root@local ~ > root@local ~ > root@local ~ > root@local ~ >mkfs.xfs -f /dev/sda1 mkfs.xfs: /dev/sda1 contains a mounted filesystem Usage: mkfs.xfs /* blocksize */ [-b log=n|size=num] /* data subvol */ [-d agcount=n,agsize=n,file,name=xxx,size=num, (sunit=value,swidth=value|su=num,sw=num), unwritten=0|1] /* inode size */ [-i log=n|perblock=n|size=num,maxpct=n] /* log subvol */ [-l agnum=n,internal,size=num,logdev=xxx version=n,sunit=value|su=num] /* label */ [-L label (maximum 12 characters)] /* naming */ [-n log=n|size=num,version=n] /* prototype file */ [-p fname] /* quiet */ [-q] /* realtime subvol */ [-r extsize=num,size=num,rtdev=xxx] /* sectorsize */ [-s log=n|size=num] /* version */ [-V] devicename is required unless -d name=xxx is given. Internal log by default, size is scaled from 1,000 blocks to 32,768 blocks based on the filesystem size. Default log reaches its largest size at 1TB. This can be overridden with the -l options or using a volume manager with a log subvolume. is xxx (bytes), xxxs (sectors), xxxb (fs blocks), xxxk (xxx KB), or xxxm (xxx MB) is xxx (512 blocks). root@local ~ > From owner-linux-xfs@oss.sgi.com Tue Jul 29 05:54:33 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 29 Jul 2003 05:54:36 -0700 (PDT) Received: from batleth.sapienti-sat.org (batleth.sapienti-sat.org [80.190.100.240]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h6TCsMFl023982 for ; Tue, 29 Jul 2003 05:54:22 -0700 Received: from localhost (localhost.sapienti-sat.org [127.0.0.1]) by batleth.sapienti-sat.org (Postfix) with SMTP id 44F95102587 for ; Tue, 29 Jul 2003 14:22:05 +0200 (CEST) Received: from nx-01.sapienti-sat.org (pD9E7FCCC.dip.t-dialin.net [217.231.252.204]) by batleth.sapienti-sat.org (Postfix) with ESMTP id 02A72102547 for ; Tue, 29 Jul 2003 14:22:04 +0200 (CEST) Received: from localhost (localhost.sapienti-sat.org [127.0.0.1]) by nx-01.sapienti-sat.org (Postfix) with SMTP id 0F5E340836 for ; Tue, 29 Jul 2003 14:22:03 +0200 (CEST) Received: from koschikode.com (pktomo.sapienti-sat.org [192.168.200.10]) by nx-01.sapienti-sat.org (Postfix) with ESMTP id CD9C94082B for ; Tue, 29 Jul 2003 14:22:02 +0200 (CEST) Message-ID: <3F2666EA.5000500@koschikode.com> Date: Tue, 29 Jul 2003 14:22:02 +0200 From: Juri Haberland User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3.1) Gecko/20030425 X-Accept-Language: en-us, de-de, en MIME-Version: 1.0 To: linux-xfs@oss.sgi.com Subject: Re: mkfs.xfs problem References: <3F26644D.3010200@siemens.com> In-Reply-To: <3F26644D.3010200@siemens.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-archive-position: 4771 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: juri@koschikode.com Precedence: bulk X-list: linux-xfs Content-Length: 310 Lines: 16 Matus Lovecky wrote: > Hallo, > > I have a following problem: > when I try to mkfs.xfs my /dev/sda1, I got an error message saing: > mkfs.xfs: /dev/sda1 contains a mounted filesystem > > but this is not thuth according to cat /etc/mtab: > > any helpful suggestions? Try 'cat /proc/mounts'. Cheers, Juri From owner-linux-xfs@oss.sgi.com Tue Jul 29 07:35:58 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 29 Jul 2003 07:36:16 -0700 (PDT) Received: from zok.sgi.com (zok.SGI.COM [204.94.215.101]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h6TEZvFl001486 for ; Tue, 29 Jul 2003 07:35:57 -0700 Received: from flecktone.americas.sgi.com (flecktone.americas.sgi.com [192.48.203.135]) by zok.sgi.com (8.12.9/8.12.9/linux-outbound_gateway-1.1) with ESMTP id h6TEZqq0020901 for ; Tue, 29 Jul 2003 07:35:52 -0700 Received: from poppy-e236.americas.sgi.com (poppy-e236.americas.sgi.com [128.162.236.207]) by flecktone.americas.sgi.com (8.12.9/8.12.9/generic_config-1.2) with ESMTP id h6TEYpQK2757057; Tue, 29 Jul 2003 09:34:51 -0500 (CDT) Received: from stout.americas.sgi.com (stout.americas.sgi.com [128.162.232.50]) by poppy-e236.americas.sgi.com (8.12.9/SGI-server-1.8) with ESMTP id h6TEYlYk15810970; Tue, 29 Jul 2003 09:34:51 -0500 (CDT) Subject: Re: bug with chown with kernel 2.6.0-test1? From: Eric Sandeen To: Ethan Benson Cc: linux-xfs@oss.sgi.com In-Reply-To: <20030729072015.GG6786@plato.local.lan> References: <200307281831.28840.marc@mco.mine.nu> <1059411469.28137.17.camel@stout.americas.sgi.com> <20030729072015.GG6786@plato.local.lan> Content-Type: text/plain Organization: Message-Id: <1059489287.1642.1.camel@stout.americas.sgi.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 (1.2.2-5) Date: 29 Jul 2003 09:34:47 -0500 Content-Transfer-Encoding: 7bit X-archive-position: 4772 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: sandeen@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 828 Lines: 27 On Tue, 2003-07-29 at 02:20, Ethan Benson wrote: > On Mon, Jul 28, 2003 at 11:57:50AM -0500, Eric Sandeen wrote: > > restrict_chown (the default) means that only root can "give away" files > > to another user via chown. > > > > But yes, this does look like a bug. > > what does? appears to be correct behavior to me: > > > > fs.xfs.restrict_chown = 1 > > > marco:/dvdrip# touch test > > > marco:/dvdrip# chown marc test > > > chown: changing ownership of `test': Operation not permitted > > marco != root && marco != marc, chown not permitted. he is doing this as root; he should be able to chown the file to marc. (His original mail said that all operations were performed as root) etc... -Eric -- Eric Sandeen [C]XFS for Linux http://oss.sgi.com/projects/xfs sandeen@sgi.com SGI, Inc. 651-683-3102 From owner-linux-xfs@oss.sgi.com Tue Jul 29 08:01:50 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 29 Jul 2003 08:02:09 -0700 (PDT) Received: from tolkor.sgi.com ([198.149.18.6]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h6TF1nFl014476 for ; Tue, 29 Jul 2003 08:01:50 -0700 Received: from flecktone.americas.sgi.com (flecktone.americas.sgi.com [192.48.203.135]) by tolkor.sgi.com (8.12.9/8.12.9/linux-outbound_gateway-1.1) with ESMTP id h6TFL0sR006502 for ; Tue, 29 Jul 2003 10:21:00 -0500 Received: from daisy-e236.americas.sgi.com (daisy-e236.americas.sgi.com [128.162.236.214]) by flecktone.americas.sgi.com (8.12.9/8.12.9/generic_config-1.2) with ESMTP id h6TF1hQK2768148 for ; Tue, 29 Jul 2003 10:01:43 -0500 (CDT) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.232.100]) by daisy-e236.americas.sgi.com (8.12.9/SGI-server-1.8) with ESMTP id h6TF1hRn201725272 for ; Tue, 29 Jul 2003 10:01:43 -0500 (CDT) From: Steve Lord Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id h6TF1hB10590; Tue, 29 Jul 2003 10:01:43 -0500 Message-Id: <200307291501.h6TF1hB10590@jen.americas.sgi.com> Date: Tue, 29 Jul 2003 10:01:43 -0500 Subject: TAKE - merge up to 2.6.0-test1 To: linux-xfs@oss.sgi.com X-archive-position: 4773 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: lord@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 13376 Lines: 374 Date: Tue Jul 29 07:59:29 PDT 2003 Workarea: jen.americas.sgi.com:/src/lord/xfs-linux.2.5 The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.5.x-xfs Modid: 2.5.x-xfs:slinx:154458a linux/net/ipv4/ipvs/ip_vs_sched.c - 1.1 linux/net/ipv4/ipvs/ip_vs_dh.c - 1.1 linux/net/ipv4/ipvs/ip_vs_ctl.c - 1.1 linux/sound/oss/swarm_cs4297a.c - 1.1 linux/net/ipv4/ipvs/ip_vs_core.c - 1.1 linux/net/ipv4/ipvs/ip_vs_conn.c - 1.1 linux/net/ipv4/ipvs/ip_vs_app.c - 1.1 linux/net/ipv4/ipvs/Makefile - 1.1 linux/sound/oss/forte.c - 1.1 linux/sound/oss/au1000.c - 1.1 linux/net/ipv4/ipvs/Kconfig - 1.1 linux/sound/oss/ali5455.c - 1.1 linux/sound/oss/ad1889.h - 1.1 linux/sound/oss/ad1889.c - 1.1 linux/net/ipv4/ipvs/ip_vs_proto_tcp.c - 1.1 linux/net/ipv4/ipvs/ip_vs_nq.c - 1.1 linux/net/ipv4/ipvs/ip_vs_proto_icmp.c - 1.1 linux/sound/oss/ac97_plugin_ad1980.c - 1.1 linux/net/ipv4/ipvs/ip_vs_est.c - 1.1 linux/net/ipv4/ipvs/ip_vs_ftp.c - 1.1 linux/net/ipv4/ipvs/ip_vs_lc.c - 1.1 linux/net/ipv4/ipvs/ip_vs_lblc.c - 1.1 linux/net/ipv4/ipvs/ip_vs_xmit.c - 1.1 linux/net/ipv4/ipvs/ip_vs_proto.c - 1.1 linux/net/ipv4/ipvs/ip_vs_proto_udp.c - 1.1 linux/net/ipv4/ipvs/ip_vs_wrr.c - 1.1 linux/net/ipv4/ipvs/ip_vs_rr.c - 1.1 linux/net/ipv4/ipvs/ip_vs_wlc.c - 1.1 linux/include/net/ip_vs.h - 1.1 linux/net/ipv4/ipvs/ip_vs_lblcr.c - 1.1 linux/net/ipv4/ipvs/ip_vs_sync.c - 1.1 linux/net/ipv4/ipvs/ip_vs_proto_esp.c - 1.1 linux/net/ipv4/ipvs/ip_vs_proto_ah.c - 1.1 linux/drivers/block/cryptoloop.c - 1.1 linux/net/ipv4/ipvs/ip_vs_sed.c - 1.1 linux/net/ipv4/ipvs/ip_vs_sh.c - 1.1 linux/net/netsyms.c - 1.73 linux/net/netlink/af_netlink.c - 1.33 linux/net/irda/irttp.c - 1.25 linux/net/irda/irlap.c - 1.24 linux/net/ipv6/udp.c - 1.46 linux/net/ipv6/route.c - 1.38 linux/net/ipv6/raw.c - 1.40 linux/net/ipv6/ndisc.c - 1.38 linux/net/ipv6/ip6_output.c - 1.28 linux/net/ipv6/ip6_fib.c - 1.20 linux/net/ipv4/udp.c - 1.47 linux/net/ipv4/tcp_input.c - 1.54 linux/net/ipv4/raw.c - 1.39 linux/net/ipv4/igmp.c - 1.30 linux/net/ipv4/Makefile - 1.21 linux/mm/vmscan.c - 1.131 linux/mm/swapfile.c - 1.76 linux/mm/mmap.c - 1.81 linux/mm/memory.c - 1.108 linux/mm/filemap.c - 1.159 linux/lib/vsprintf.c - 1.22 linux/kernel/sysctl.c - 1.71 linux/kernel/sys.c - 1.55 linux/kernel/sched.c - 1.107 linux/kernel/ksyms.c - 1.195 linux/kernel/fork.c - 1.96 linux/ipc/shm.c - 1.65 linux/init/version.c - 1.6 linux/include/net/irda/irda_device.h - 1.17 linux/include/net/ip6_route.h - 1.14 linux/include/linux/time.h - 1.18 linux/include/linux/sysctl.h - 1.75 linux/include/linux/proc_fs.h - 1.42 linux/include/linux/nbd.h - 1.21 linux/include/linux/mount.h - 1.21 linux/include/linux/loop.h - 1.15 linux/include/linux/irda.h - 1.14 linux/include/linux/fs.h - 1.218 linux/include/asm-sparc64/ptrace.h - 1.6 linux/include/asm-sparc64/ipc.h - 1.4 linux/include/asm-sparc/pgtsrmmu.h - 1.8 linux/include/asm-sparc/ipc.h - 1.4 linux/include/asm-i386/unistd.h - 1.39 linux/include/asm-alpha/unistd.h - 1.32 linux/include/asm-alpha/timex.h - 1.3 linux/fs/stat.c - 1.34 linux/fs/read_write.c - 1.35 linux/fs/proc/root.c - 1.33 linux/fs/proc/inode.c - 1.33 linux/fs/proc/generic.c - 1.38 linux/fs/proc/base.c - 1.55 linux/fs/open.c - 1.52 linux/fs/nfsd/nfssvc.c - 1.37 linux/fs/nfs/write.c - 1.52 linux/fs/nfs/inode.c - 1.68 linux/fs/namei.c - 1.74 linux/fs/locks.c - 1.41 linux/fs/ioctl.c - 1.20 linux/fs/inode.c - 1.100 linux/fs/ext2/ialloc.c - 1.39 linux/fs/exec.c - 1.86 linux/fs/dcache.c - 1.56 linux/fs/buffer.c - 1.160 linux/fs/block_dev.c - 1.78 linux/fs/binfmt_elf.c - 1.60 linux/fs/binfmt_aout.c - 1.31 linux/fs/attr.c - 1.24 linux/drivers/scsi/g_NCR5380.c - 1.25 linux/drivers/net/via-rhine.c - 1.45 linux/drivers/net/sunhme.c - 1.47 linux/drivers/net/plip.c - 1.29 linux/drivers/net/hamradio/mkiss.h - 1.6 linux/drivers/net/hamradio/mkiss.c - 1.19 linux/drivers/net/dgrs.c - 1.27 linux/drivers/char/dtlk.c - 1.23 linux/drivers/block/nbd.c - 1.58 linux/drivers/block/loop.c - 1.87 linux/drivers/block/ll_rw_blk.c - 1.137 linux/drivers/block/Makefile - 1.36 linux/arch/sparc64/kernel/time.c - 1.36 linux/arch/sparc64/kernel/sys_sparc32.c - 1.76 linux/arch/sparc64/kernel/sys_sparc.c - 1.31 linux/arch/sparc64/kernel/entry.S - 1.31 linux/arch/sparc/mm/srmmu.c - 1.47 linux/arch/sparc/kernel/time.c - 1.29 linux/arch/sparc/kernel/sys_sparc.c - 1.20 linux/arch/sparc/kernel/process.c - 1.38 linux/arch/sparc/kernel/pcic.c - 1.30 linux/arch/sparc/kernel/Makefile - 1.24 linux/arch/sparc/defconfig - 1.40 linux/arch/sparc/boot/Makefile - 1.16 linux/arch/ppc/kernel/time.c - 1.27 linux/arch/mips/kernel/time.c - 1.18 linux/arch/m68k/kernel/time.c - 1.13 linux/arch/i386/kernel/time.c - 1.44 linux/arch/i386/kernel/entry.S - 1.84 linux/arch/alpha/kernel/time.c - 1.33 linux/Makefile - 1.254 linux/MAINTAINERS - 1.145 linux/Documentation/nbd.txt - 1.5 linux/Documentation/CodingStyle - 1.6 linux/drivers/net/sk_mca.c - 1.19 linux/Documentation/kernel-parameters.txt - 1.28 linux/drivers/net/declance.c - 1.22 linux/drivers/isdn/hisax/isurf.c - 1.19 linux/arch/sh/kernel/time.c - 1.22 linux/net/irda/ircomm/ircomm_tty.c - 1.30 linux/drivers/pcmcia/tcic.c - 1.30 linux/drivers/pcmcia/rsrc_mgr.c - 1.24 linux/drivers/pcmcia/ricoh.h - 1.10 linux/drivers/pcmcia/i82365.c - 1.44 linux/drivers/pcmcia/cs_internal.h - 1.20 linux/drivers/pcmcia/cs.c - 1.43 linux/drivers/pcmcia/cistpl.c - 1.23 linux/include/pcmcia/ss.h - 1.17 linux/drivers/pcmcia/bulkmem.c - 1.19 linux/drivers/pcmcia/ti113x.h - 1.12 linux/drivers/net/pcmcia/pcnet_cs.c - 1.26 linux/drivers/net/pcmcia/3c589_cs.c - 1.29 linux/drivers/char/drm/drmP.h - 1.26 linux/drivers/char/drm/drm.h - 1.14 linux/drivers/net/pcmcia/xirc2ps_cs.c - 1.26 linux/drivers/net/pcmcia/3c574_cs.c - 1.27 linux/drivers/net/pcmcia/nmclan_cs.c - 1.21 linux/drivers/net/pcmcia/smc91c92_cs.c - 1.23 linux/drivers/net/irda/old_belkin.c - 1.6 linux/include/net/irda/nsc-ircc.h - 1.3 linux/drivers/net/irda/nsc-ircc.c - 1.29 linux/arch/ia64/kernel/time.c - 1.25 linux/arch/i386/kernel/microcode.c - 1.26 linux/fs/devfs/base.c - 1.60 linux/include/linux/ac97_codec.h - 1.14 linux/drivers/net/appletalk/ltpc.c - 1.16 linux/drivers/net/appletalk/cops.c - 1.19 linux/drivers/usb/serial/ftdi_sio.h - 1.8 linux/drivers/ide/ide-cd.c - 1.66 linux/net/ipv4/netfilter/ip_fw_compat.c - 1.19 linux/drivers/net/pcmcia/ibmtr_cs.c - 1.16 linux/drivers/usb/serial/ftdi_sio.c - 1.49 linux/arch/s390/kernel/time.c - 1.14 linux/drivers/char/drm/r128_drv.h - 1.14 linux/drivers/char/drm/i810_drv.h - 1.7 linux/drivers/char/drm/i810_drm.h - 1.6 linux/drivers/char/drm/i810_dma.c - 1.24 linux/drivers/usb/storage/freecom.c - 1.24 linux/drivers/net/sundance.c - 1.27 linux/drivers/usb/storage/initializers.c - 1.6 linux/mm/oom_kill.c - 1.24 linux/net/irda/irnet/irnet_irda.c - 1.17 linux/arch/parisc/kernel/drivers.c - 1.6 linux/include/asm-parisc/pgtable.h - 1.12 linux/include/asm-parisc/processor.h - 1.12 linux/arch/parisc/kernel/traps.c - 1.10 linux/arch/parisc/kernel/time.c - 1.9 linux/arch/parisc/kernel/pci.c - 1.8 linux/include/asm-parisc/byteorder.h - 1.2 linux/arch/parisc/hpux/sys_hpux.c - 1.6 linux/mm/shmem.c - 1.63 linux/drivers/char/drm/r128_state.c - 1.9 linux/fs/reiserfs/stree.c - 1.29 linux/fs/reiserfs/tail_conversion.c - 1.21 linux/drivers/char/drm/radeon_drm.h - 1.12 linux/drivers/char/drm/radeon_drv.c - 1.6 linux/drivers/char/drm/radeon_drv.h - 1.14 linux/drivers/char/drm/radeon_state.c - 1.13 linux/fs/reiserfs/journal.c - 1.44 linux/fs/reiserfs/inode.c - 1.42 linux/fs/reiserfs/fix_node.c - 1.27 linux/fs/reiserfs/do_balan.c - 1.16 linux/include/linux/reiserfs_fs.h - 1.38 linux/include/linux/reiserfs_fs_sb.h - 1.19 linux/fs/reiserfs/bitmap.c - 1.24 linux/drivers/usb/storage/unusual_devs.h - 1.24 linux/drivers/net/irda/irda-usb.c - 1.33 linux/Documentation/DocBook/procfs-guide.tmpl - 1.4 linux/Documentation/DocBook/procfs_example.c - 1.4 linux/drivers/usb/usb-skeleton.c - 1.29 linux/drivers/usb/storage/datafab.c - 1.12 linux/drivers/char/drm/radeon.h - 1.10 linux/drivers/char/drm/drm_ioctl.h - 1.8 linux/drivers/char/drm/r128.h - 1.6 linux/drivers/char/drm/i810.h - 1.6 linux/drivers/char/drm/drm_vm.h - 1.20 linux/drivers/char/drm/drm_stub.h - 1.6 linux/drivers/char/drm/drm_scatter.h - 1.8 linux/drivers/char/drm/drm_proc.h - 1.9 linux/drivers/char/drm/drm_memory.h - 1.6 linux/drivers/char/drm/drm_lock.h - 1.6 linux/drivers/char/drm/drm_init.h - 1.4 linux/drivers/char/drm/drm_fops.h - 1.7 linux/drivers/char/drm/drm_drv.h - 1.15 linux/drivers/char/drm/drm_drawable.h - 1.3 linux/drivers/char/drm/drm_dma.h - 1.9 linux/drivers/char/drm/drm_context.h - 1.9 linux/drivers/char/drm/drm_bufs.h - 1.9 linux/drivers/char/drm/drm_auth.h - 1.4 linux/drivers/char/drm/drm_agpsupport.h - 1.15 linux/drivers/char/drm/ati_pcigart.h - 1.8 linux/fs/namespace.c - 1.32 linux/drivers/pcmcia/i82092.c - 1.17 linux/fs/jbd/journal.c - 1.25 linux/drivers/video/sis/init301.c - 1.4 linux/fs/ext3/inode.c - 1.41 linux/include/linux/jbd.h - 1.19 linux/fs/jbd/transaction.c - 1.20 linux/fs/jbd/commit.c - 1.15 linux/fs/jbd/checkpoint.c - 1.9 linux/drivers/net/pcmcia/axnet_cs.c - 1.10 linux/drivers/net/wireless/wavelan.c - 1.8 linux/include/asm-sparc64/thread_info.h - 1.8 linux/sound/oss/ymfpci.h - 1.2 linux/sound/oss/ymfpci.c - 1.6 linux/sound/oss/via82cxxx_audio.c - 1.12 linux/sound/oss/trident.h - 1.5 linux/sound/oss/trident.c - 1.16 linux/sound/oss/soundcard.c - 1.10 linux/sound/oss/sonicvibes.c - 1.11 linux/sound/oss/nm256_audio.c - 1.7 linux/sound/oss/nec_vrc5477.c - 1.9 linux/sound/oss/msnd_pinnacle.c - 1.7 linux/sound/oss/maestro3.c - 1.10 linux/sound/oss/maestro.c - 1.14 linux/sound/oss/ite8172.c - 1.9 linux/sound/oss/i810_audio.c - 1.15 linux/sound/oss/esssolo1.c - 1.13 linux/sound/oss/es1371.c - 1.14 linux/sound/oss/es1370.c - 1.13 linux/sound/oss/emu10k1/mixer.c - 1.5 linux/sound/oss/emu10k1/main.c - 1.6 linux/sound/oss/emu10k1/hwaccess.h - 1.3 linux/sound/oss/emu10k1/efxmgr.c - 1.3 linux/sound/oss/dmasound/dmasound_core.c - 1.7 linux/sound/oss/cs46xx_wrapper-24.h - 1.3 linux/sound/oss/cs46xx.c - 1.13 linux/sound/oss/cmpci.c - 1.10 linux/sound/oss/btaudio.c - 1.8 linux/arch/x86_64/boot/setup.S - 1.6 linux/arch/x86_64/kernel/time.c - 1.16 linux/arch/x86_64/kernel/x8664_ksyms.c - 1.15 linux/sound/oss/ac97_codec.c - 1.8 linux/sound/oss/Makefile - 1.11 linux/arch/ppc64/kernel/time.c - 1.16 linux/drivers/net/tokenring/3c359.c - 1.8 linux/fs/quota_v1.c - 1.8 linux/drivers/net/tg3.c - 1.23 linux/drivers/net/e100/e100_phy.c - 1.8 linux/drivers/net/e100/e100_main.c - 1.24 linux/fs/libfs.c - 1.18 linux/fs/xfs/pagebuf/page_buf_internal.h - 1.24 linux/drivers/net/sb1250-mac.c - 1.6 linux/drivers/usb/core/inode.c - 1.16 linux/drivers/usb/net/usbnet.c - 1.24 linux/mm/readahead.c - 1.21 linux/fs/mpage.c - 1.20 linux/drivers/usb/core/message.c - 1.21 linux/arch/x86_64/ia32/ipc32.c - 1.8 linux/fs/direct-io.c - 1.18 linux/drivers/char/agp/sis-agp.c - 1.10 linux/drivers/char/agp/frontend.c - 1.10 linux/drivers/char/agp/hp-agp.c - 1.9 linux/drivers/char/agp/via-agp.c - 1.11 linux/drivers/char/drm/drm_os_linux.h - 1.9 linux/drivers/usb/class/usblp.c - 1.11 linux/fs/aio.c - 1.16 linux/drivers/char/genrtc.c - 1.7 linux/fs/cifs/README - 1.4 linux/Documentation/filesystems/cifs.txt - 1.3 linux/fs/cifs/cifs_debug.c - 1.10 linux/fs/cifs/cifsfs.c - 1.13 linux/fs/cifs/cifsfs.h - 1.5 linux/fs/cifs/cifsproto.h - 1.11 linux/fs/cifs/cifssmb.c - 1.13 linux/fs/cifs/connect.c - 1.13 linux/fs/cifs/dir.c - 1.5 linux/fs/cifs/file.c - 1.11 linux/fs/cifs/inode.c - 1.11 linux/arch/alpha/kernel/systbls.S - 1.6 linux/fs/cifs/misc.c - 1.8 linux/fs/cifs/CHANGES - 1.11 linux/fs/cifs/transport.c - 1.10 linux/fs/cifs/smbencrypt.c - 1.5 linux/drivers/net/irda/Kconfig - 1.6 linux/arch/alpha/Kconfig - 1.16 linux/arch/arm/Kconfig - 1.16 linux/net/ipv4/Kconfig - 1.8 linux/arch/i386/Kconfig - 1.25 linux/arch/ia64/Kconfig - 1.16 linux/arch/parisc/Kconfig - 1.13 linux/arch/parisc/kernel/ioctl32.c - 1.8 linux/arch/parisc/kernel/sys_parisc32.c - 1.13 linux/arch/parisc/kernel/unaligned.c - 1.3 linux/arch/ppc/Kconfig - 1.16 linux/arch/sparc64/Kconfig - 1.18 linux/drivers/block/Kconfig - 1.6 linux/arch/x86_64/Kconfig - 1.19 linux/sound/oss/Kconfig - 1.9 linux/init/Kconfig - 1.11 linux/fs/eventpoll.c - 1.12 linux/drivers/parisc/Kconfig - 1.6 linux/include/asm-v850/statfs.h - 1.2 linux/arch/v850/kernel/time.c - 1.6 linux/arch/m68knommu/kernel/time.c - 1.7 linux/arch/v850/kernel/simcons.c - 1.6 linux/arch/v850/kernel/gbus_int.c - 1.4 linux/arch/v850/kernel/bug.c - 1.4 linux/drivers/char/agp/amd-k8-agp.c - 1.10 linux/mm/nommu.c - 1.5 linux/kernel/compat.c - 1.10 linux/drivers/input/misc/gsc_ps2.c - 1.3 linux/drivers/char/drm/drm_sarea.h - 1.2 linux/include/asm-parisc/parisc-device.h - 1.2 linux/arch/parisc/kernel/module.c - 1.6 linux/drivers/eisa/Kconfig - 1.4 linux/include/linux/seqlock.h - 1.2 linux/drivers/net/tokenring/proteon.c - 1.3 linux/drivers/net/tokenring/skisa.c - 1.3 linux/net/compat.c - 1.5 linux/net/xfrm/xfrm_policy.c - 1.6 linux/drivers/pcmcia/sa11xx_core.c - 1.6 linux/drivers/block/floppy98.c - 1.4 linux/drivers/char/drm/drm_memory_debug.h - 1.3 linux/net/core/net-sysfs.c - 1.4 linux/drivers/net/wireless/atmel_cs.c - 1.2 linux/arch/arm26/Kconfig - 1.5 linux/drivers/pcmcia/yenta_socket.c - 1.3 linux/arch/mips64/kernel/time.c - 1.2 linux/drivers/block/as-iosched.c - 1.2 linux/include/asm-generic/div64.h - 1.2 linux/fs/cifs/cifsencrypt.c - 1.2 From owner-linux-xfs@oss.sgi.com Tue Jul 29 08:26:47 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 29 Jul 2003 08:27:09 -0700 (PDT) Received: from tolkor.sgi.com ([198.149.18.6]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h6TFQhFl016578 for ; Tue, 29 Jul 2003 08:26:46 -0700 Received: from penguin.americas.sgi.com ([128.162.240.135]) by tolkor.sgi.com (8.12.9/8.12.9/linux-outbound_gateway-1.1) with ESMTP id h6TFjssR013570 for ; Tue, 29 Jul 2003 10:45:54 -0500 Received: from penguin.americas.sgi.com (localhost.localdomain [127.0.0.1]) by penguin.americas.sgi.com (8.12.8/8.12.8) with ESMTP id h6TFGTUo004469 for ; Tue, 29 Jul 2003 10:16:29 -0500 Received: (from lord@localhost) by penguin.americas.sgi.com (8.12.8/8.12.5/Submit) id h6TFGSJ8004467 for linux-xfs@oss.sgi.com; Tue, 29 Jul 2003 10:16:28 -0500 Date: Tue, 29 Jul 2003 10:16:28 -0500 From: Steve Lord Message-Id: <200307291516.h6TFGSJ8004467@penguin.americas.sgi.com> Subject: TAKE - merge up to 2.6.0-test2 To: linux-xfs@oss.sgi.com X-archive-position: 4774 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: lord@penguin.americas.sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 41204 Lines: 1078 Date: Tue Jul 29 08:21:49 PDT 2003 Workarea: penguin.americas.sgi.com:/src/lord/xfs-linux.2.5 The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.5.x-xfs Modid: 2.5.x-xfs:slinx:154465a linux/usr/initramfs_data.S - 1.1 linux/sound/oss/kahlua.c - 1.1 linux/sound/oss/harmony.c - 1.1 linux/sound/oss/hal2.h - 1.1 linux/sound/oss/hal2.c - 1.1 linux/drivers/md/dm-ioctl-v1.c - 1.1 linux/arch/v850/kernel/me2.c - 1.1 linux/arch/v850/kernel/rte_me2_cb.c - 1.1 linux/arch/v850/kernel/sim85e2.c - 1.1 linux/arch/v850/kernel/v850e2_cache.c - 1.1 linux/arch/v850/kernel/v850e_cache.c - 1.1 linux/arch/v850/kernel/v850e_intc.c - 1.1 linux/arch/v850/kernel/v850e_timer_d.c - 1.1 linux/arch/v850/kernel/v850e_utils.c - 1.1 linux/arch/v850/rte_me2_cb.ld - 1.1 linux/arch/v850/sim85e2.ld - 1.1 linux/drivers/block/Kconfig.iosched - 1.1 linux/drivers/pci/remove.c - 1.1 linux/drivers/net/zorro8390.c - 1.1 linux/drivers/net/wireless/wl3501_cs.c - 1.1 linux/drivers/net/wireless/wl3501.h - 1.1 linux/drivers/media/video/hexium_orion.h - 1.1 linux/drivers/media/video/hexium_orion.c - 1.1 linux/drivers/media/video/hexium_gemini.h - 1.1 linux/drivers/media/video/hexium_gemini.c - 1.1 linux/drivers/media/video/hexium.h - 1.1 linux/drivers/media/dvb/ttusb-dec/ttusb_dec.h - 1.1 linux/net/bridge/netfilter/ebt_stp.c - 1.1 linux/drivers/media/dvb/ttusb-dec/ttusb_dec.c - 1.1 linux/drivers/media/dvb/ttusb-dec/fdump.c - 1.1 linux/drivers/media/dvb/ttusb-dec/dec2000_frontend.c - 1.1 linux/drivers/media/dvb/ttusb-dec/Makefile - 1.1 linux/drivers/media/dvb/ttusb-dec/Kconfig - 1.1 linux/drivers/media/dvb/ttusb-budget/dvb-ttusb-dspbootcode.h - 1.1 linux/drivers/media/dvb/ttusb-budget/dvb-ttusb-budget.c - 1.1 linux/drivers/media/dvb/ttusb-budget/Makefile - 1.1 linux/drivers/media/dvb/ttusb-budget/Kconfig - 1.1 linux/drivers/media/dvb/ttpci/ttpci-eeprom.h - 1.1 linux/drivers/media/dvb/ttpci/ttpci-eeprom.c - 1.1 linux/drivers/media/dvb/frontends/tda1004x.c - 1.1 linux/drivers/serial/v850e_uart.c - 1.1 linux/drivers/media/dvb/frontends/mt312.h - 1.1 linux/drivers/media/dvb/frontends/mt312.c - 1.1 linux/drivers/media/dvb/b2c2/skystar2.c - 1.1 linux/drivers/media/dvb/b2c2/Makefile - 1.1 linux/drivers/media/dvb/b2c2/Kconfig - 1.1 linux/drivers/media/common/saa7146_vv_ksyms.c - 1.1 linux/drivers/md/dm-ioctl-v4.c - 1.1 linux/arch/ia64/scripts/check-model.c - 1.1 linux/include/asm-v850/me2.h - 1.1 linux/include/linux/netfilter_bridge/ebt_stp.h - 1.1 linux/include/asm-alpha/local.h - 1.1 linux/include/asm-alpha/sections.h - 1.1 linux/include/asm-generic/local.h - 1.1 linux/include/asm-i386/local.h - 1.1 linux/include/asm-ia64/local.h - 1.1 linux/include/asm-ppc/local.h - 1.1 linux/include/asm-sparc64/local.h - 1.1 linux/include/asm-sparc64/sections.h - 1.1 linux/include/asm-v850/serial.h - 1.1 linux/include/linux/dm-ioctl-v4.h - 1.1 linux/include/linux/dm-ioctl-v1.h - 1.1 linux/include/asm-v850/rte_me2_cb.h - 1.1 linux/include/asm-v850/v850e_uart.h - 1.1 linux/include/asm-v850/sim85e2.h - 1.1 linux/include/asm-v850/v850e_utils.h - 1.1 linux/include/asm-v850/v850e_uartb.h - 1.1 linux/include/asm-v850/v850e_uarta.h - 1.1 linux/include/asm-v850/v850e_timer_c.h - 1.1 linux/include/asm-v850/v850e_timer_d.h - 1.1 linux/include/asm-v850/v850e2_cache.h - 1.1 linux/include/asm-v850/v850e_intc.h - 1.1 linux/include/asm-v850/v850e_cache.h - 1.1 linux/include/asm-v850/v850e2.h - 1.1 linux/include/asm-v850/v850e.h - 1.1 linux/include/asm-v850/sim85e2s.h - 1.1 linux/scripts/ver_linux - 1.15 linux/net/wanrouter/wanmain.c - 1.20 linux/net/sunrpc/xprt.c - 1.45 linux/net/sunrpc/svcsock.c - 1.35 linux/net/sunrpc/clnt.c - 1.33 linux/net/netsyms.c - 1.74 linux/net/lapb/lapb_iface.c - 1.13 linux/net/ipv6/tcp_ipv6.c - 1.58 linux/net/ipv6/sit.c - 1.34 linux/net/ipv6/route.c - 1.39 linux/net/ipv6/ndisc.c - 1.39 linux/net/ipv6/icmp.c - 1.33 linux/net/ipv6/addrconf.c - 1.41 linux/net/ipv4/tcp_input.c - 1.55 linux/net/ipv4/ipip.c - 1.34 linux/net/ipv4/ip_output.c - 1.51 linux/net/ipv4/ip_gre.c - 1.34 linux/net/core/sysctl_net_core.c - 1.8 linux/net/core/rtnetlink.c - 1.19 linux/net/core/filter.c - 1.11 linux/net/core/dev.c - 1.80 linux/net/core/Makefile - 1.17 linux/net/bridge/Makefile - 1.10 linux/mm/slab.c - 1.62 linux/kernel/time.c - 1.19 linux/kernel/sys.c - 1.56 linux/kernel/signal.c - 1.58 linux/kernel/sched.c - 1.108 linux/kernel/module.c - 1.46 linux/kernel/ksyms.c - 1.196 linux/kernel/fork.c - 1.97 linux/init/main.c - 1.111 linux/include/net/ipv6.h - 1.20 linux/include/net/ip6_route.h - 1.15 linux/include/linux/zorro.h - 1.10 linux/include/linux/tty.h - 1.24 linux/include/linux/times.h - 1.5 linux/include/linux/sched.h - 1.108 linux/include/linux/rtnetlink.h - 1.20 linux/include/linux/pci.h - 1.80 linux/include/linux/nfs_mount.h - 1.8 linux/include/linux/nfs_fs_sb.h - 1.13 linux/include/linux/nfs_fs.h - 1.34 linux/include/linux/netdevice.h - 1.51 linux/include/linux/msdos_fs_sb.h - 1.14 linux/include/linux/msdos_fs.h - 1.31 linux/include/linux/module.h - 1.53 linux/include/linux/loop.h - 1.16 linux/include/linux/kernel_stat.h - 1.16 linux/include/linux/ipv6_route.h - 1.4 linux/include/linux/hfs_sysdep.h - 1.14 linux/include/linux/elfcore.h - 1.7 linux/include/linux/blkdev.h - 1.88 linux/include/linux/blk.h - 1.40 linux/include/linux/arcdevice.h - 1.12 linux/include/asm-sparc64/smp.h - 1.20 linux/include/asm-sparc64/processor.h - 1.31 linux/include/asm-sparc64/pbm.h - 1.14 linux/include/asm-sparc64/irq.h - 1.20 linux/include/asm-sparc64/head.h - 1.7 linux/include/asm-sparc64/floppy.h - 1.18 linux/include/asm-sparc64/atomic.h - 1.9 linux/include/asm-sparc64/asi.h - 1.7 linux/include/asm-ppc/unistd.h - 1.34 linux/include/asm-ppc/uaccess.h - 1.16 linux/include/asm-ppc/processor.h - 1.44 linux/include/asm-ppc/ipc.h - 1.6 linux/include/asm-ppc/hardirq.h - 1.27 linux/include/asm-m68k/hardirq.h - 1.11 linux/include/asm-m68k/floppy.h - 1.7 linux/include/asm-m68k/entry.h - 1.9 linux/include/asm-m68k/checksum.h - 1.6 linux/include/asm-alpha/atomic.h - 1.8 linux/fs/vfat/namei.c - 1.41 linux/fs/umsdos/ioctl.c - 1.11 linux/fs/proc/Makefile - 1.15 linux/fs/nfsd/nfssvc.c - 1.38 linux/fs/nfs/nfs3xdr.c - 1.22 linux/fs/nfs/inode.c - 1.69 linux/fs/ncpfs/Makefile - 1.8 linux/fs/msdos/namei.c - 1.39 linux/fs/lockd/svc.c - 1.28 linux/fs/lockd/clntlock.c - 1.15 linux/fs/fat/misc.c - 1.19 linux/fs/fat/inode.c - 1.61 linux/fs/fat/file.c - 1.30 linux/fs/fat/dir.c - 1.25 linux/fs/fat/cache.c - 1.22 linux/fs/ext2/Makefile - 1.12 linux/fs/devpts/Makefile - 1.8 linux/fs/binfmt_elf.c - 1.61 linux/drivers/video/vesafb.c - 1.31 linux/drivers/video/valkyriefb.c - 1.22 linux/drivers/video/macfb.c - 1.20 linux/drivers/video/Makefile - 1.56 linux/drivers/scsi/wd7000.c - 1.29 linux/drivers/scsi/wd33c93.c - 1.16 linux/drivers/scsi/ultrastor.c - 1.22 linux/drivers/scsi/u14-34f.c - 1.35 linux/drivers/scsi/tmscsim.c - 1.26 linux/drivers/scsi/t128.c - 1.17 linux/drivers/scsi/sym53c8xx.c - 1.48 linux/drivers/scsi/sym53c416.c - 1.21 linux/drivers/scsi/st.c - 1.69 linux/drivers/scsi/sr_vendor.c - 1.17 linux/drivers/scsi/sr_ioctl.c - 1.34 linux/drivers/scsi/sr.c - 1.71 linux/drivers/scsi/sgiwd93.c - 1.18 linux/drivers/scsi/sg.c - 1.56 linux/drivers/scsi/seagate.c - 1.29 linux/drivers/scsi/sd.c - 1.91 linux/drivers/scsi/scsicam.c - 1.14 linux/drivers/scsi/scsi_syms.c - 1.36 linux/drivers/scsi/scsi_proc.c - 1.21 linux/drivers/scsi/scsi_module.c - 1.7 linux/drivers/scsi/scsi_ioctl.c - 1.33 linux/drivers/scsi/scsi_debug.c - 1.37 linux/drivers/scsi/scsi.h - 1.55 linux/drivers/scsi/qlogicpti.c - 1.28 linux/drivers/scsi/qlogicisp.c - 1.37 linux/drivers/scsi/qlogicfc.c - 1.41 linux/drivers/scsi/qlogicfas.c - 1.24 linux/drivers/scsi/psi240i.c - 1.15 linux/drivers/scsi/ppa.h - 1.16 linux/drivers/scsi/ppa.c - 1.28 linux/drivers/scsi/pluto.c - 1.21 linux/drivers/scsi/pci2220i.c - 1.33 linux/drivers/scsi/pci2000.c - 1.30 linux/drivers/scsi/pas16.c - 1.18 linux/drivers/scsi/ncr53c8xx.c - 1.38 linux/drivers/scsi/mvme16x.c - 1.11 linux/drivers/scsi/mesh.c - 1.17 linux/drivers/scsi/megaraid.c - 1.50 linux/drivers/scsi/mca_53c9x.c - 1.14 linux/drivers/scsi/mac_scsi.c - 1.14 linux/drivers/scsi/mac_esp.c - 1.17 linux/drivers/scsi/mac53c94.c - 1.12 linux/drivers/scsi/jazz_esp.c - 1.11 linux/drivers/scsi/inia100.c - 1.31 linux/drivers/scsi/ini9100u.c - 1.26 linux/drivers/scsi/in2000.c - 1.20 linux/drivers/scsi/imm.h - 1.15 linux/drivers/scsi/imm.c - 1.27 linux/drivers/scsi/ide-scsi.c - 1.56 linux/drivers/scsi/ibmmca.c - 1.29 linux/drivers/scsi/i91uscsi.c - 1.8 linux/drivers/scsi/hosts.c - 1.49 linux/drivers/scsi/gvp11.c - 1.17 linux/drivers/scsi/gdth.c - 1.32 linux/drivers/scsi/g_NCR5380.c - 1.26 linux/drivers/scsi/fdomain.c - 1.34 linux/drivers/scsi/fd_mcs.c - 1.18 linux/drivers/scsi/fcal.c - 1.17 linux/drivers/scsi/fastlane.c - 1.14 linux/drivers/scsi/esp.c - 1.37 linux/drivers/scsi/eata_pio.c - 1.24 linux/drivers/scsi/eata.c - 1.39 linux/drivers/scsi/dtc.c - 1.17 linux/drivers/scsi/cyberstormII.c - 1.14 linux/drivers/scsi/cyberstorm.c - 1.14 linux/drivers/scsi/constants.c - 1.17 linux/drivers/scsi/bvme6000.c - 1.9 linux/drivers/scsi/blz2060.c - 1.14 linux/drivers/scsi/blz1230.c - 1.15 linux/drivers/scsi/atp870u.c - 1.30 linux/drivers/scsi/atari_scsi.c - 1.14 linux/drivers/scsi/amiga7xx.c - 1.13 linux/drivers/scsi/aha1740.c - 1.21 linux/drivers/scsi/aha1542.h - 1.11 linux/drivers/scsi/aha1542.c - 1.38 linux/drivers/scsi/aha152x.c - 1.43 linux/drivers/scsi/advansys.c - 1.38 linux/drivers/scsi/a3000.c - 1.16 linux/drivers/scsi/a2091.c - 1.19 linux/drivers/scsi/NCR53c406a.c - 1.22 linux/drivers/scsi/NCR53C9x.c - 1.28 linux/drivers/scsi/BusLogic.c - 1.26 linux/drivers/scsi/AM53C974.c - 1.23 linux/drivers/scsi/53c7xx.c - 1.26 linux/drivers/sbus/sbus.c - 1.22 linux/drivers/sbus/char/flash.c - 1.18 linux/drivers/sbus/char/envctrl.c - 1.23 linux/drivers/pci/quirks.c - 1.40 linux/drivers/pci/pci.c - 1.69 linux/drivers/pci/Makefile - 1.36 linux/drivers/net/via-rhine.c - 1.46 linux/drivers/net/sonic.c - 1.10 linux/drivers/net/seeq8005.c - 1.20 linux/drivers/net/ni65.h - 1.4 linux/drivers/net/ni65.c - 1.21 linux/drivers/net/ne2k-pci.c - 1.28 linux/drivers/net/eql.c - 1.17 linux/drivers/net/atari_pamsnet.c - 1.17 linux/drivers/net/ariadne2.c - 1.14 linux/drivers/net/Makefile - 1.75 linux/drivers/net/8390.h - 1.16 linux/drivers/isdn/hisax/fsm.c - 1.13 linux/drivers/isdn/hisax/config.c - 1.39 linux/drivers/fc4/fcp_impl.h - 1.6 linux/drivers/fc4/fc.c - 1.16 linux/drivers/char/stallion.c - 1.32 linux/drivers/char/pcxx.c - 1.20 linux/drivers/char/istallion.c - 1.31 linux/drivers/char/ftape/zftape/zftape-init.c - 1.20 linux/drivers/char/ftape/lowlevel/ftape-format.c - 1.4 linux/drivers/char/ftape/lowlevel/ftape-calibr.c - 1.7 linux/drivers/char/ftape/lowlevel/fdc-io.c - 1.11 linux/drivers/char/busmouse.c - 1.22 linux/drivers/cdrom/sonycd535.c - 1.38 linux/drivers/cdrom/sjcd.c - 1.32 linux/drivers/cdrom/sbpcd.c - 1.40 linux/drivers/cdrom/optcd.c - 1.34 linux/drivers/cdrom/mcdx.c - 1.28 linux/drivers/cdrom/mcd.c - 1.33 linux/drivers/cdrom/gscd.c - 1.33 linux/drivers/cdrom/cm206.c - 1.35 linux/drivers/cdrom/cdu31a.c - 1.31 linux/drivers/cdrom/cdrom.c - 1.55 linux/drivers/cdrom/aztcd.c - 1.35 linux/drivers/block/z2ram.c - 1.31 linux/drivers/block/xd.c - 1.56 linux/drivers/block/swim3.c - 1.31 linux/drivers/block/ps2esdi.c - 1.59 linux/drivers/block/paride/pf.c - 1.38 linux/drivers/block/paride/pd.c - 1.46 linux/drivers/block/paride/pcd.c - 1.34 linux/drivers/block/nbd.c - 1.59 linux/drivers/block/ll_rw_blk.c - 1.138 linux/drivers/block/genhd.c - 1.56 linux/drivers/block/floppy.c - 1.69 linux/drivers/block/ataflop.c - 1.41 linux/drivers/block/amiflop.c - 1.42 linux/drivers/block/acsi_slm.c - 1.17 linux/drivers/block/acsi.c - 1.50 linux/drivers/block/Makefile - 1.37 linux/drivers/acorn/block/mfmhd.c - 1.40 linux/drivers/acorn/block/fd1772.c - 1.38 linux/arch/sparc64/prom/bootstr.c - 1.5 linux/arch/sparc64/mm/init.c - 1.58 linux/arch/sparc64/mm/fault.c - 1.28 linux/arch/sparc64/lib/debuglocks.c - 1.9 linux/arch/sparc64/lib/PeeCeeI.c - 1.4 linux/arch/sparc64/kernel/unaligned.c - 1.12 linux/arch/sparc64/kernel/time.c - 1.37 linux/arch/sparc64/kernel/sparc64_ksyms.c - 1.61 linux/arch/sparc64/kernel/smp.c - 1.58 linux/arch/sparc64/kernel/setup.c - 1.41 linux/arch/sparc64/kernel/irq.c - 1.36 linux/arch/sparc64/kernel/head.S - 1.24 linux/arch/sparc64/kernel/entry.S - 1.32 linux/arch/sparc64/kernel/cpu.c - 1.11 linux/arch/sparc64/defconfig - 1.98 linux/arch/sparc64/Makefile - 1.30 linux/arch/sparc/mm/srmmu.c - 1.48 linux/arch/sparc/kernel/setup.c - 1.29 linux/arch/sparc/kernel/process.c - 1.39 linux/arch/sparc/Makefile - 1.29 linux/arch/ppc/kernel/time.c - 1.28 linux/arch/ppc/kernel/syscalls.c - 1.17 linux/arch/ppc/kernel/setup.c - 1.59 linux/arch/ppc/kernel/misc.S - 1.59 linux/arch/ppc/kernel/irq.c - 1.47 linux/arch/ppc/Makefile - 1.41 linux/arch/mips/mm/init.c - 1.19 linux/arch/mips/mm/fault.c - 1.15 linux/arch/mips/Makefile - 1.18 linux/arch/m68k/q40/q40ints.c - 1.12 linux/arch/m68k/mm/memory.c - 1.16 linux/arch/m68k/mm/init.c - 1.19 linux/arch/m68k/kernel/traps.c - 1.20 linux/arch/m68k/kernel/process.c - 1.21 linux/arch/m68k/kernel/m68k_defs.c - 1.10 linux/arch/m68k/kernel/entry.S - 1.23 linux/arch/m68k/defconfig - 1.16 linux/arch/m68k/atari/time.c - 1.8 linux/arch/m68k/atari/stram.c - 1.28 linux/arch/m68k/atari/atari_ksyms.c - 1.3 linux/arch/m68k/apollo/dn_ints.c - 1.11 linux/arch/m68k/apollo/config.c - 1.13 linux/arch/m68k/Makefile - 1.14 linux/arch/i386/mm/init.c - 1.58 linux/arch/i386/kernel/setup.c - 1.96 linux/arch/i386/kernel/io_apic.c - 1.67 linux/arch/i386/Makefile - 1.55 linux/arch/alpha/mm/init.c - 1.29 linux/arch/alpha/lib/strncpy.S - 1.4 linux/arch/alpha/kernel/irq.c - 1.34 linux/arch/alpha/Makefile - 1.31 linux/Makefile - 1.255 linux/MAINTAINERS - 1.146 linux/Documentation/magic-number.txt - 1.7 linux/CREDITS - 1.104 linux/net/decnet/dn_route.c - 1.29 linux/net/decnet/dn_dev.c - 1.20 linux/net/decnet/af_decnet.c - 1.44 linux/include/linux/ide.h - 1.82 linux/drivers/net/sk_mca.h - 1.4 linux/drivers/net/sk_mca.c - 1.20 linux/drivers/isdn/hisax/avm_pci.c - 1.23 linux/drivers/block/cpqarray.c - 1.73 linux/arch/sparc64/lib/atomic.S - 1.5 linux/drivers/parport/parport_pc.c - 1.58 linux/drivers/net/macsonic.c - 1.17 linux/include/asm-i386/hw_irq.h - 1.35 linux/fs/partitions/check.c - 1.72 linux/drivers/scsi/sun3x_esp.c - 1.12 linux/drivers/scsi/oktagon_esp.c - 1.13 linux/arch/m68k/math-emu/fp_log.c - 1.2 linux/arch/m68k/math-emu/fp_emu.h - 1.5 linux/drivers/net/fc/iph5526.c - 1.29 linux/drivers/char/ip2main.c - 1.31 linux/drivers/char/ip2/i2os.h - 1.4 linux/drivers/char/ip2/i2lib.c - 1.11 linux/drivers/char/ip2.c - 1.9 linux/drivers/atm/atmtcp.c - 1.15 linux/net/core/netfilter.c - 1.25 linux/net/atm/svc.c - 1.18 linux/net/atm/signaling.h - 1.5 linux/net/atm/signaling.c - 1.15 linux/net/atm/raw.c - 1.10 linux/net/atm/pvc.c - 1.16 linux/net/atm/proc.c - 1.23 linux/net/atm/mpc.c - 1.18 linux/net/atm/lec.c - 1.25 linux/net/atm/common.h - 1.9 linux/net/atm/common.c - 1.27 linux/net/atm/clip.c - 1.21 linux/include/linux/atmdev.h - 1.19 linux/drivers/block/DAC960.c - 1.71 linux/arch/sparc64/kernel/pci_sabre.c - 1.34 linux/arch/sparc64/kernel/pci_psycho.c - 1.32 linux/arch/sparc64/kernel/pci_impl.h - 1.10 linux/arch/sparc64/kernel/pci_common.c - 1.23 linux/arch/sparc64/kernel/pci.c - 1.37 linux/arch/sh/mm/init.c - 1.24 linux/arch/sh/Makefile - 1.17 linux/drivers/scsi/ips.h - 1.24 linux/drivers/scsi/ips.c - 1.44 linux/drivers/pcmcia/ricoh.h - 1.11 linux/include/pcmcia/ss.h - 1.18 linux/drivers/block/swim_iop.c - 1.26 linux/arch/m68k/mm/sun3mmu.c - 1.9 linux/arch/m68k/mm/motorola.c - 1.10 linux/drivers/pcmcia/ti113x.h - 1.13 linux/include/asm-sparc64/pci.h - 1.20 linux/include/asm-ppc/pci.h - 1.24 linux/Documentation/nmi_watchdog.txt - 1.5 linux/include/linux/pci_ids.h - 1.96 linux/drivers/net/wan/syncppp.c - 1.19 linux/drivers/net/wan/sdlamain.c - 1.19 linux/drivers/net/wan/sdladrv.c - 1.12 linux/drivers/scsi/sim710.c - 1.17 linux/drivers/scsi/dec_esp.c - 1.10 linux/drivers/net/pcmcia/3c574_cs.c - 1.28 linux/mm/bootmem.c - 1.29 linux/fs/proc/proc_misc.c - 1.66 linux/drivers/scsi/sun3_scsi.c - 1.19 linux/drivers/pci/pci.ids - 1.62 linux/arch/ppc/mm/mem_pieces.c - 1.10 linux/arch/ppc/configs/apus_defconfig - 1.23 linux/drivers/scsi/scsi_lib.c - 1.68 linux/drivers/sbus/char/jsflash.c - 1.30 linux/drivers/telephony/ixj.c - 1.31 linux/drivers/net/arcnet/com90xx.c - 1.11 linux/drivers/net/arcnet/com90io.c - 1.12 linux/drivers/net/arcnet/com20020.c - 1.7 linux/drivers/net/arcnet/com20020-pci.c - 1.17 linux/drivers/net/arcnet/com20020-isa.c - 1.10 linux/drivers/net/arcnet/arcnet.c - 1.19 linux/drivers/net/arcnet/arc-rimi.c - 1.9 linux/drivers/ieee1394/raw1394.c - 1.30 linux/drivers/ieee1394/ieee1394_core.h - 1.19 linux/drivers/ieee1394/pcilynx.c - 1.31 linux/drivers/ieee1394/ieee1394_core.c - 1.34 linux/drivers/ieee1394/ohci1394.c - 1.35 linux/drivers/ieee1394/ieee1394_types.h - 1.22 linux/drivers/ieee1394/ieee1394_transactions.c - 1.18 linux/drivers/ieee1394/csr.h - 1.7 linux/drivers/ieee1394/hosts.h - 1.18 linux/drivers/ieee1394/hosts.c - 1.21 linux/drivers/ieee1394/highlevel.h - 1.9 linux/drivers/ieee1394/csr.c - 1.13 linux/drivers/char/moxa.c - 1.21 linux/drivers/pci/setup-res.c - 1.17 linux/drivers/pci/setup-bus.c - 1.13 linux/drivers/scsi/scsi_scan.c - 1.53 linux/drivers/scsi/3w-xxxx.c - 1.33 linux/arch/ia64/kernel/head.S - 1.18 linux/arch/ia64/kernel/entry.S - 1.40 linux/arch/ia64/kernel/acpi.c - 1.25 linux/arch/ia64/vmlinux.lds.S - 1.28 linux/arch/ia64/Makefile - 1.30 linux/arch/ia64/kernel/init_task.c - 1.10 linux/arch/ia64/kernel/setup.c - 1.28 linux/arch/ia64/kernel/smp.c - 1.25 linux/arch/ia64/kernel/time.c - 1.26 linux/arch/ia64/kernel/unwind.c - 1.18 linux/arch/ia64/kernel/ptrace.c - 1.26 linux/arch/ia64/kernel/perfmon.c - 1.28 linux/arch/ia64/mm/init.c - 1.31 linux/drivers/scsi/qla1280.c - 1.29 linux/include/asm-ia64/io.h - 1.14 linux/include/asm-ia64/elf.h - 1.11 linux/include/asm-ia64/atomic.h - 1.10 linux/include/asm-ia64/processor.h - 1.36 linux/include/asm-ia64/mmu_context.h - 1.15 linux/include/asm-ia64/spinlock.h - 1.16 linux/include/asm-ia64/system.h - 1.28 linux/drivers/scsi/sun3_NCR5380.c - 1.13 linux/drivers/net/8139too.c - 1.54 linux/drivers/char/amiserial.c - 1.23 linux/drivers/scsi/pcmcia/qlogic_stub.c - 1.16 linux/drivers/scsi/pcmcia/fdomain_stub.c - 1.17 linux/fs/devfs/base.c - 1.61 linux/drivers/scsi/pcmcia/aha152x_stub.c - 1.17 linux/net/bridge/br_stp_timer.c - 1.7 linux/net/bridge/br_stp_if.c - 1.9 linux/net/bridge/br_device.c - 1.11 linux/net/bridge/br_stp.c - 1.9 linux/net/bridge/br_notify.c - 1.6 linux/net/bridge/br_ioctl.c - 1.9 linux/net/bridge/br_if.c - 1.16 linux/drivers/char/nwbutton.h - 1.4 linux/arch/mips64/kernel/setup.c - 1.10 linux/Documentation/zorro.txt - 1.3 linux/include/linux/usb.h - 1.63 linux/drivers/usb/serial/usb-serial.c - 1.20 linux/drivers/usb/serial/ftdi_sio.h - 1.9 linux/drivers/ide/ide-dma.c - 1.40 linux/drivers/ide/ide-disk.c - 1.63 linux/drivers/ide/ide-cd.c - 1.67 linux/drivers/block/elevator.c - 1.33 linux/include/linux/elevator.h - 1.20 linux/drivers/net/wan/comx-hw-comx.c - 1.13 linux/net/ipv4/netfilter/ipt_REJECT.c - 1.22 linux/net/ipv4/netfilter/ipt_MIRROR.c - 1.13 linux/net/ipv4/netfilter/ip_conntrack_core.c - 1.27 linux/include/linux/netfilter_ipv4/ipt_REJECT.h - 1.4 linux/drivers/scsi/dmx3191d.c - 1.16 linux/fs/nfs/nfs3proc.c - 1.22 linux/drivers/usb/serial/ftdi_sio.c - 1.50 linux/drivers/usb/serial/visor.c - 1.54 linux/drivers/net/wan/lmc/lmc_proto.c - 1.8 linux/arch/s390/Makefile - 1.19 linux/arch/s390/defconfig - 1.21 linux/include/asm-s390/irq.h - 1.10 linux/include/asm-s390/dma.h - 1.4 linux/include/asm-s390/siginfo.h - 1.6 linux/arch/s390/kernel/entry.S - 1.26 linux/drivers/s390/block/dasd.c - 1.45 linux/arch/s390/kernel/setup.c - 1.16 linux/arch/s390/mm/init.c - 1.17 linux/kernel/profile.c - 1.7 linux/drivers/usb/storage/usb.h - 1.25 linux/drivers/usb/storage/usb.c - 1.42 linux/drivers/usb/storage/transport.h - 1.22 linux/drivers/usb/storage/scsiglue.h - 1.6 linux/drivers/usb/storage/scsiglue.c - 1.36 linux/drivers/usb/storage/protocol.h - 1.7 linux/drivers/usb/storage/protocol.c - 1.14 linux/drivers/usb/storage/debug.h - 1.8 linux/drivers/acpi/tables/tbinstal.c - 1.21 linux/drivers/acpi/tables/tbget.c - 1.21 linux/drivers/acpi/tables.c - 1.12 linux/drivers/acpi/hardware/hwregs.c - 1.24 linux/arch/ia64/ia32/ia32_ioctl.c - 1.12 linux/arch/ia64/kernel/ia64_ksyms.c - 1.22 linux/drivers/ieee1394/video1394.c - 1.32 linux/drivers/usb/storage/sddr09.c - 1.24 linux/drivers/media/video/pms.c - 1.11 linux/drivers/media/video/Makefile - 1.16 linux/drivers/block/cciss.c - 1.59 linux/drivers/macintosh/adbhid.c - 1.12 linux/drivers/md/md.c - 1.77 linux/drivers/scsi/cpqfcTScontrol.c - 1.10 linux/drivers/scsi/cpqfcTSinit.c - 1.32 linux/drivers/scsi/cpqfcTSworker.c - 1.16 linux/include/linux/ethtool.h - 1.16 linux/include/asm-m68k/sun3_pgtable.h - 1.6 linux/drivers/scsi/mvme147.c - 1.5 linux/include/asm-m68k/motorola_pgtable.h - 1.4 linux/arch/parisc/Makefile - 1.16 linux/drivers/acpi/tables/tbconvrt.c - 1.20 linux/drivers/acpi/tables/tbxfroot.c - 1.15 linux/drivers/scsi/osst.c - 1.29 linux/arch/ia64/kernel/iosapic.c - 1.18 linux/arch/sparc64/kernel/pci_schizo.c - 1.20 linux/drivers/usb/storage/unusual_devs.h - 1.25 linux/drivers/s390/block/xpram.c - 1.37 linux/drivers/pcmcia/hd64465_ss.c - 1.12 linux/arch/s390/kernel/s390_ext.c - 1.5 linux/include/linux/hdlc.h - 1.7 linux/drivers/scsi/aic7xxx_old.c - 1.33 linux/drivers/scsi/aic7xxx/aic7xxx_osm.h - 1.18 linux/drivers/net/wan/n2.c - 1.10 linux/drivers/net/wan/hd6457x.c - 1.8 linux/drivers/net/wan/hd64570.h - 1.3 linux/drivers/net/wan/c101.c - 1.9 linux/net/ipv4/netfilter/ip_nat_helper.c - 1.12 linux/arch/sparc64/kernel/isa.c - 1.4 linux/drivers/net/wireless/Makefile - 1.11 linux/include/asm-sparc64/isa.h - 1.3 linux/include/asm-m68k/mc146818rtc.h - 1.3 linux/include/asm-m68k/sun3xflop.h - 1.4 linux/drivers/acpi/utilities/utglobal.c - 1.22 linux/drivers/net/wireless/airo.c - 1.32 linux/drivers/acpi/executer/exutils.c - 1.16 linux/drivers/scsi/pcmcia/nsp_cs.c - 1.23 linux/drivers/usb/usb-skeleton.c - 1.30 linux/drivers/video/pvr2fb.c - 1.10 linux/drivers/message/fusion/mptscsih.c - 1.20 linux/drivers/message/fusion/mptctl.c - 1.16 linux/drivers/ieee1394/sbp2.c - 1.28 linux/drivers/ieee1394/nodemgr.c - 1.19 linux/drivers/ieee1394/nodemgr.h - 1.10 linux/drivers/usb/storage/jumpshot.c - 1.12 linux/drivers/usb/storage/isd200.c - 1.18 linux/drivers/net/irda/vlsi_ir.c - 1.17 linux/drivers/scsi/dpt_i2o.c - 1.26 linux/include/asm-ppc/sections.h - 1.4 linux/drivers/isdn/hisax/st5481_init.c - 1.10 linux/drivers/scsi/53c700.c - 1.21 linux/drivers/scsi/NCR_D700.c - 1.10 linux/drivers/scsi/lasi700.c - 1.11 linux/fs/jffs2/Makefile - 1.8 linux/drivers/md/multipath.c - 1.21 linux/include/asm-ia64/tlb.h - 1.12 linux/fs/namespace.c - 1.33 linux/drivers/message/i2o/i2o_scsi.c - 1.16 linux/drivers/message/i2o/i2o_block.c - 1.34 linux/net/ipv4/netfilter/ip_conntrack_irc.c - 1.11 linux/Documentation/networking/ifenslave.c - 1.6 linux/drivers/scsi/sym53c8xx_2/sym_glue.c - 1.18 linux/drivers/scsi/sym53c8xx_2/sym_glue.h - 1.10 linux/net/atm/pppoatm.c - 1.8 linux/fs/intermezzo/sysctl.c - 1.10 linux/fs/intermezzo/vfs.c - 1.18 linux/include/linux/ext3_jbd.h - 1.12 linux/fs/jbd/transaction.c - 1.21 linux/fs/ext3/Makefile - 1.10 linux/fs/ext3/acl.c - 1.11 linux/include/linux/bio.h - 1.23 linux/fs/bio.c - 1.32 linux/include/linux/namespace.h - 1.6 linux/drivers/usb/serial/ipaq.c - 1.24 linux/drivers/usb/serial/ipaq.h - 1.9 linux/arch/arm/mach-clps711x/autcpu12.c - 1.5 linux/drivers/block/cciss_scsi.c - 1.14 linux/drivers/net/Makefile.lib - 1.8 linux/drivers/ieee1394/dv1394-private.h - 1.11 linux/drivers/ieee1394/dv1394.c - 1.19 linux/drivers/ieee1394/dv1394.h - 1.5 linux/drivers/input/gameport/ns558.c - 1.8 linux/include/asm-i386/thread_info.h - 1.11 linux/sound/oss/emu10k1/voicemgr.h - 1.3 linux/sound/oss/emu10k1/voicemgr.c - 1.3 linux/sound/oss/emu10k1/recmgr.c - 1.3 linux/sound/oss/emu10k1/passthrough.h - 1.2 linux/sound/oss/emu10k1/passthrough.c - 1.6 linux/sound/oss/emu10k1/mixer.c - 1.6 linux/sound/oss/emu10k1/midi.h - 1.2 linux/sound/oss/emu10k1/main.c - 1.7 linux/sound/oss/emu10k1/irqmgr.h - 1.2 linux/sound/oss/emu10k1/hwaccess.h - 1.4 linux/sound/oss/emu10k1/hwaccess.c - 1.3 linux/sound/oss/emu10k1/efxmgr.h - 1.3 linux/sound/oss/emu10k1/efxmgr.c - 1.4 linux/sound/oss/emu10k1/cardwo.c - 1.5 linux/sound/oss/emu10k1/cardmo.c - 1.2 linux/sound/oss/emu10k1/cardmi.c - 1.3 linux/sound/oss/emu10k1/audio.c - 1.6 linux/sound/oss/emu10k1/8010.h - 1.2 linux/sound/oss/dmasound/dmasound_core.c - 1.8 linux/arch/ppc/platforms/residual.c - 1.6 linux/sound/oss/btaudio.c - 1.9 linux/arch/x86_64/Makefile - 1.20 linux/arch/x86_64/mm/init.c - 1.17 linux/sound/oss/ad1816.c - 1.7 linux/sound/oss/Makefile - 1.12 linux/sound/isa/es18xx.c - 1.17 linux/sound/isa/cmi8330.c - 1.13 linux/sound/Makefile - 1.16 linux/arch/ppc64/mm/init.c - 1.18 linux/arch/ppc64/Makefile - 1.19 linux/arch/ppc64/boot/Makefile - 1.13 linux/arch/ppc64/kernel/XmPciLpEvent.c - 1.3 linux/arch/ppc64/kernel/iSeries_irq.c - 1.3 linux/arch/ppc64/kernel/prom.c - 1.17 linux/drivers/net/e1000/e1000_main.c - 1.23 linux/drivers/net/e1000/e1000_ethtool.c - 1.13 linux/fs/jfs/Makefile - 1.7 linux/drivers/net/tg3.c - 1.24 linux/drivers/net/wan/hdlc_x25.c - 1.6 linux/drivers/net/wan/hdlc_cisco.c - 1.6 linux/drivers/net/wan/hdlc_fr.c - 1.6 linux/drivers/net/wan/hdlc_generic.c - 1.7 linux/drivers/net/wan/hdlc_ppp.c - 1.6 linux/drivers/net/wan/hdlc_raw.c - 1.6 linux/drivers/ieee1394/eth1394.c - 1.12 linux/drivers/usb/image/microtek.c - 1.12 linux/drivers/usb/class/bluetty.c - 1.21 linux/drivers/usb/class/cdc-acm.c - 1.22 linux/include/asm-generic/percpu.h - 1.6 linux/drivers/usb/core/hcd.c - 1.26 linux/drivers/usb/core/usb.c - 1.37 linux/drivers/usb/host/ohci-hcd.c - 1.22 linux/fs/partitions/efi.h - 1.4 linux/drivers/usb/host/ohci-q.c - 1.24 linux/drivers/usb/image/hpusbscsi.c - 1.14 linux/drivers/usb/image/scanner.c - 1.25 linux/drivers/usb/image/scanner.h - 1.18 linux/drivers/ieee1394/amdtp.c - 1.12 linux/drivers/usb/media/dabusb.c - 1.15 linux/drivers/usb/net/usbnet.c - 1.25 linux/drivers/usb/net/rtl8150.c - 1.18 linux/drivers/usb/net/pegasus.c - 1.18 linux/drivers/usb/net/kaweth.c - 1.20 linux/drivers/usb/net/catc.c - 1.11 linux/mm/readahead.c - 1.22 linux/include/asm-ia64/percpu.h - 1.7 linux/drivers/isdn/i4l/isdn_common.c - 1.14 linux/arch/ia64/hp/sim/simscsi.c - 1.12 linux/arch/ia64/hp/sim/simeth.c - 1.7 linux/arch/ia64/hp/common/sba_iommu.c - 1.13 linux/drivers/block/umem.c - 1.22 linux/drivers/usb/host/uhci-hcd.c - 1.23 linux/include/asm-m68k/cacheflush.h - 1.4 linux/arch/i386/pci/legacy.c - 1.7 linux/drivers/pci/hotplug.c - 1.15 linux/drivers/pci/pool.c - 1.10 linux/arch/i386/pci/visws.c - 1.6 linux/drivers/usb/storage/sddr55.c - 1.6 linux/kernel/suspend.c - 1.26 linux/drivers/acpi/thermal.c - 1.15 linux/drivers/acpi/processor.c - 1.22 linux/drivers/acpi/osl.c - 1.22 linux/drivers/s390/cio/chsc.c - 1.10 linux/drivers/usb/core/hcd-pci.c - 1.12 linux/drivers/s390/cio/cio.c - 1.8 linux/drivers/s390/block/dasd_genhd.c - 1.16 linux/drivers/s390/block/dasd_ioctl.c - 1.13 linux/drivers/input/keyboard/sunkbd.c - 1.10 linux/drivers/acpi/tables/tbrsdt.c - 1.10 linux/drivers/acpi/toshiba_acpi.c - 1.9 linux/drivers/input/serio/q40kbd.c - 1.7 linux/drivers/serial/core.c - 1.16 linux/drivers/char/agp/i460-agp.c - 1.9 linux/drivers/serial/Makefile - 1.12 linux/include/asm-generic/sections.h - 1.2 linux/include/linux/serial_core.h - 1.16 linux/drivers/serial/sunzilog.c - 1.14 linux/drivers/serial/sunsu.c - 1.15 linux/drivers/usb/class/usblp.c - 1.12 linux/drivers/usb/misc/usblcd.c - 1.9 linux/net/ipv4/netfilter/ipt_helper.c - 1.5 linux/arch/i386/kernel/cpu/mtrr/cyrix.c - 1.4 linux/arch/i386/kernel/cpu/mtrr/main.c - 1.5 linux/include/net/sctp/user.h - 1.8 linux/net/sctp/ulpevent.c - 1.8 linux/net/sctp/protocol.c - 1.20 linux/include/net/sctp/sctp.h - 1.16 linux/net/sctp/associola.c - 1.16 linux/net/sctp/input.c - 1.15 linux/net/sctp/ipv6.c - 1.18 linux/net/sctp/output.c - 1.12 linux/net/sctp/outqueue.c - 1.15 linux/include/net/sctp/ulpevent.h - 1.5 linux/include/net/sctp/sm.h - 1.13 linux/net/sctp/sm_make_chunk.c - 1.17 linux/net/sctp/sm_sideeffect.c - 1.18 linux/net/sctp/sm_statefuns.c - 1.17 linux/include/net/sctp/structs.h - 1.19 linux/drivers/input/serio/i8042-sparcio.h - 1.3 linux/net/sctp/socket.c - 1.20 linux/net/sctp/transport.c - 1.11 linux/net/sctp/ulpqueue.c - 1.10 linux/drivers/ide/setup-pci.c - 1.13 linux/drivers/ide/ppc/mpc8xx.c - 1.4 linux/drivers/ide/pci/via82cxxx.c - 1.10 linux/drivers/ide/legacy/hd.c - 1.14 linux/arch/um/drivers/ubd_kern.c - 1.13 linux/net/bridge/netfilter/ebt_vlan.c - 1.6 linux/net/bridge/netfilter/ebt_snat.c - 1.3 linux/net/bridge/netfilter/ebt_redirect.c - 1.4 linux/net/bridge/netfilter/ebt_mark_m.c - 1.3 linux/net/bridge/netfilter/ebt_mark.c - 1.3 linux/net/bridge/netfilter/ebt_log.c - 1.5 linux/net/bridge/netfilter/ebt_ip.c - 1.6 linux/net/bridge/netfilter/ebt_dnat.c - 1.3 linux/net/bridge/netfilter/ebt_arp.c - 1.5 linux/net/bridge/netfilter/Makefile - 1.5 linux/arch/ia64/pci/pci.c - 1.11 linux/drivers/block/deadline-iosched.c - 1.11 linux/include/linux/netfilter_bridge/ebtables.h - 1.5 linux/drivers/usb/misc/usbtest.c - 1.13 linux/drivers/scsi/nsp32.c - 1.12 linux/drivers/scsi/aacraid/sa.c - 1.4 linux/drivers/scsi/aacraid/rx.c - 1.3 linux/drivers/scsi/aacraid/linit.c - 1.13 linux/drivers/scsi/aacraid/dpcsup.c - 1.3 linux/drivers/scsi/aacraid/commsup.c - 1.5 linux/drivers/scsi/aacraid/comminit.c - 1.4 linux/drivers/scsi/aacraid/commctrl.c - 1.3 linux/drivers/scsi/aacraid/aachba.c - 1.12 linux/fs/cifs/TODO - 1.7 linux/fs/cifs/cifsfs.c - 1.14 linux/fs/cifs/cifsglob.h - 1.8 linux/fs/cifs/connect.c - 1.14 linux/fs/cifs/misc.c - 1.9 linux/fs/cifs/CHANGES - 1.12 linux/fs/cifs/transport.c - 1.11 linux/drivers/isdn/hardware/eicon/i4lididrv.c - 1.7 linux/arch/ppc/platforms/4xx/walnut.c - 1.6 linux/drivers/isdn/hardware/eicon/capimain.c - 1.5 linux/drivers/isdn/hardware/eicon/divasmain.c - 1.8 linux/drivers/isdn/hardware/eicon/divasi.c - 1.5 linux/drivers/isdn/hardware/eicon/diva_didd.c - 1.4 linux/drivers/isdn/hardware/eicon/divamnt.c - 1.6 linux/net/rxrpc/Makefile - 1.5 linux/drivers/block/ioctl.c - 1.6 linux/Documentation/pnp.txt - 1.4 linux/drivers/pnp/isapnp/core.c - 1.15 linux/drivers/media/dvb/Makefile - 1.4 linux/drivers/net/Kconfig - 1.17 linux/drivers/net/pcmcia/Kconfig - 1.6 linux/scripts/kconfig/qconf.cc - 1.6 linux/drivers/md/Kconfig - 1.4 linux/drivers/net/wan/Kconfig - 1.6 linux/net/bridge/netfilter/Kconfig - 1.4 linux/drivers/media/video/Kconfig - 1.6 linux/drivers/net/wireless/Kconfig - 1.8 linux/drivers/parport/Kconfig - 1.4 linux/drivers/media/dvb/frontends/ves1820.c - 1.5 linux/drivers/media/dvb/frontends/grundig_29504-491.c - 1.5 linux/drivers/media/dvb/frontends/grundig_29504-401.c - 1.5 linux/drivers/media/dvb/frontends/alps_bsrv2.c - 1.5 linux/drivers/media/dvb/frontends/Makefile - 1.5 linux/drivers/media/dvb/frontends/Kconfig - 1.6 linux/drivers/media/dvb/dvb-core/dvbdev.h - 1.6 linux/scripts/kconfig/confdata.c - 1.5 linux/include/linux/dm-ioctl.h - 1.3 linux/drivers/media/dvb/dvb-core/dvbdev.c - 1.8 linux/drivers/media/dvb/dvb-core/dvb_net.h - 1.5 linux/drivers/media/dvb/dvb-core/dvb_net.c - 1.5 linux/drivers/media/dvb/dvb-core/dvb_frontend.c - 1.6 linux/arch/m68k/Kconfig - 1.15 linux/drivers/media/dvb/dvb-core/dvb_demux.c - 1.6 linux/arch/parisc/kernel/ioctl32.c - 1.9 linux/drivers/media/dvb/Kconfig - 1.3 linux/drivers/md/dm.h - 1.6 linux/drivers/md/dm.c - 1.10 linux/drivers/md/dm-table.c - 1.8 linux/drivers/md/dm-ioctl.c - 1.14 linux/include/linux/pfkeyv2.h - 1.7 linux/arch/sparc64/Kconfig - 1.19 linux/drivers/ide/Kconfig - 1.13 linux/drivers/block/Kconfig - 1.7 linux/drivers/input/misc/Kconfig - 1.5 linux/drivers/serial/Kconfig - 1.11 linux/drivers/telephony/Kconfig - 1.3 linux/sound/oss/Kconfig - 1.10 linux/include/net/xfrm.h - 1.17 linux/init/Kconfig - 1.12 linux/usr/Makefile - 1.5 linux/include/asm-v850/nb85e_utils.h - 1.2 linux/include/asm-v850/nb85e_uart.h - 1.3 linux/include/asm-v850/nb85e_timer_d.h - 1.3 linux/include/asm-m68k/kmap_types.h - 1.3 linux/fs/ext3/xattr.c - 1.11 linux/drivers/scsi/sun3_scsi_vme.c - 1.6 linux/drivers/parisc/led.c - 1.7 linux/drivers/net/mac8390.c - 1.6 linux/include/asm-v850/tlbflush.h - 1.2 linux/include/asm-v850/teg.h - 1.3 linux/include/asm-v850/system.h - 1.5 linux/include/asm-v850/stat.h - 1.5 linux/include/asm-v850/sim85e2c.h - 1.3 linux/arch/v850/vmlinux.lds.S - 1.10 linux/arch/v850/sim85e2c.ld - 1.4 linux/arch/v850/kernel/v850_ksyms.c - 1.4 linux/arch/m68knommu/Makefile - 1.6 linux/arch/m68knommu/kernel/setup.c - 1.6 linux/arch/m68knommu/mm/init.c - 1.2 linux/include/asm-v850/setup.h - 1.2 linux/arch/v850/kernel/sim85e2c.c - 1.3 linux/include/asm-v850/rte_nb85e_cb.h - 1.3 linux/arch/v850/kernel/rte_nb85e_cb.c - 1.3 linux/include/asm-v850/rte_ma1_cb.h - 1.3 linux/include/asm-v850/rte_cb.h - 1.4 linux/arch/v850/kernel/rte_ma1_cb.c - 1.5 linux/include/asm-v850/ptrace.h - 1.3 linux/arch/v850/kernel/rte_cb.c - 1.4 linux/include/asm-v850/processor.h - 1.6 linux/arch/v850/kernel/process.c - 1.6 linux/arch/v850/kernel/nb85e_utils.c - 1.3 linux/arch/v850/kernel/nb85e_timer_d.c - 1.2 linux/include/asm-v850/nb85e_timer_c.h - 1.2 linux/include/asm-v850/nb85e_intc.h - 1.3 linux/include/asm-v850/nb85e_cache.h - 1.4 linux/include/asm-v850/nb85e.h - 1.2 linux/include/asm-v850/machdep.h - 1.3 linux/include/asm-v850/ma1.h - 1.2 linux/include/asm-v850/ma.h - 1.2 linux/arch/v850/kernel/nb85e_intc.c - 1.4 linux/include/asm-v850/highres_timer.h - 1.2 linux/include/asm-v850/fpga85e2c.h - 1.3 linux/arch/v850/kernel/ma.c - 1.4 linux/arch/v850/kernel/intv.S - 1.4 linux/arch/v850/kernel/highres_timer.c - 1.2 linux/include/asm-v850/entry.h - 1.3 linux/include/asm-v850/asm.h - 1.4 linux/include/asm-v850/cacheflush.h - 1.3 linux/arch/v850/kernel/gbus_int.c - 1.5 linux/arch/v850/kernel/head.S - 1.4 linux/arch/v850/kernel/fpga85e2c.c - 1.3 linux/include/asm-v850/anna.h - 1.3 linux/arch/v850/kernel/anna.c - 1.3 linux/arch/v850/kernel/Makefile - 1.6 linux/arch/v850/Kconfig - 1.14 linux/arch/v850/README - 1.3 linux/arch/v850/Makefile - 1.6 linux/drivers/net/b44.c - 1.4 linux/drivers/net/b44.h - 1.3 linux/drivers/serial/nb85e_uart.c - 1.8 linux/arch/ppc/syslib/prom_init.c - 1.5 linux/net/key/af_key.c - 1.17 linux/net/core/pktgen.c - 1.5 linux/drivers/scsi/scsi_sysfs.c - 1.13 linux/include/asm-v850/as85ep1.h - 1.2 linux/drivers/media/dvb/frontends/alps_tdlb7.c - 1.4 linux/drivers/s390/char/tape_block.c - 1.6 linux/drivers/ieee1394/dma.c - 1.5 linux/drivers/s390/cio/device.c - 1.7 linux/drivers/s390/cio/device.h - 1.5 linux/drivers/s390/cio/device_fsm.c - 1.6 linux/drivers/s390/cio/qdio.c - 1.7 linux/drivers/ieee1394/iso.c - 1.8 linux/drivers/ieee1394/iso.h - 1.5 linux/drivers/char/watchdog/acquirewdt.c - 1.8 linux/drivers/char/watchdog/i810-tco.c - 1.6 linux/drivers/ide/ide-io.c - 1.12 linux/kernel/compat.c - 1.11 linux/arch/v850/kernel/as85ep1.c - 1.3 linux/kernel/extable.c - 1.5 linux/drivers/char/watchdog/i810-tco.h - 1.2 linux/drivers/char/watchdog/ib700wdt.c - 1.7 linux/drivers/char/watchdog/machzwd.c - 1.8 linux/drivers/char/watchdog/pcwd.c - 1.9 linux/drivers/char/watchdog/sbc60xxwdt.c - 1.8 linux/drivers/char/watchdog/wdt977.c - 1.7 linux/drivers/char/watchdog/wdt_pci.c - 1.7 linux/drivers/char/watchdog/shwdt.c - 1.6 linux/include/linux/xfrm.h - 1.9 linux/drivers/char/watchdog/softdog.c - 1.7 linux/include/asm-sparc64/dma-mapping.h - 1.2 linux/include/asm-sparc/dma-mapping.h - 1.2 linux/include/asm-s390/dma-mapping.h - 1.2 linux/include/asm-m68k/dma-mapping.h - 1.2 linux/drivers/scsi/aic7xxx/aic79xx_osm.c - 1.11 linux/drivers/scsi/aic7xxx/aic79xx_osm.h - 1.8 linux/drivers/scsi/aic7xxx/aic7xxx_osm.c - 1.13 linux/drivers/scsi/aic7xxx/aiclib.c - 1.5 linux/drivers/scsi/zalon.c - 1.4 linux/arch/ppc/platforms/4xx/beech.c - 1.2 linux/drivers/char/watchdog/indydog.c - 1.6 linux/drivers/char/watchdog/sc520_wdt.c - 1.8 linux/arch/ppc/platforms/4xx/sycamore.c - 1.4 linux/net/sunrpc/auth_gss/auth_gss.c - 1.5 linux/include/asm-sparc/bug.h - 1.5 linux/include/acpi/acconfig.h - 1.8 linux/include/acpi/platform/acenv.h - 1.4 linux/arch/ia64/kernel/fsys.S - 1.6 linux/drivers/ieee1394/ieee1394-ioctl.h - 1.3 linux/arch/x86_64/mm/numa.c - 1.5 linux/drivers/net/wireless/ray_cs.c - 1.4 linux/drivers/scsi/scsi_pc98.c - 1.4 linux/init/do_mounts.h - 1.3 linux/init/do_mounts_rd.c - 1.5 linux/scripts/kconfig/gconf.c - 1.5 linux/net/ipv6/ah6.c - 1.8 linux/net/ipv6/esp6.c - 1.8 linux/drivers/video/logo/logo.c - 1.6 linux/net/ipv6/xfrm6_state.c - 1.4 linux/net/ipv6/xfrm6_policy.c - 1.6 linux/net/ipv6/xfrm6_input.c - 1.7 linux/net/ipv6/anycast.c - 1.5 linux/net/ipv4/xfrm4_state.c - 1.4 linux/drivers/ide/legacy/hd98.c - 1.4 linux/fs/partitions/nec98.c - 1.3 linux/net/xfrm/xfrm_user.c - 1.6 linux/net/xfrm/xfrm_state.c - 1.8 linux/net/xfrm/xfrm_policy.c - 1.7 linux/drivers/scsi/pc980155.c - 1.2 linux/arch/ppc/platforms/pmac_cpufreq.c - 1.4 linux/drivers/net/wan/hdlc_raw_eth.c - 1.2 linux/arch/s390/kernel/compat_ioctl.c - 1.5 linux/arch/s390/kernel/compat_linux.c - 1.3 linux/drivers/media/common/Makefile - 1.2 linux/drivers/media/common/saa7146_core.c - 1.4 linux/drivers/media/common/saa7146_fops.c - 1.4 linux/drivers/media/common/saa7146_hlp.c - 1.3 linux/drivers/media/common/saa7146_i2c.c - 1.3 linux/drivers/media/common/saa7146_vbi.c - 1.3 linux/drivers/media/common/saa7146_video.c - 1.4 linux/drivers/media/dvb/frontends/nxt6000.c - 1.3 linux/drivers/media/dvb/ttpci/Makefile - 1.2 linux/drivers/media/dvb/ttpci/av7110.c - 1.3 linux/drivers/media/dvb/ttpci/av7110.h - 1.3 linux/include/media/saa7146_vv.h - 1.3 linux/include/media/saa7146.h - 1.4 linux/drivers/media/dvb/ttpci/budget-av.c - 1.3 linux/drivers/media/dvb/ttpci/budget-ci.c - 1.3 linux/drivers/media/dvb/ttpci/budget-core.c - 1.3 linux/drivers/media/dvb/ttpci/budget-patch.c - 1.3 linux/drivers/media/dvb/ttpci/budget.c - 1.3 linux/drivers/media/video/dpc7146.c - 1.4 linux/drivers/media/video/mxb.c - 1.5 linux/arch/h8300/Makefile - 1.2 linux/arch/h8300/kernel/setup.c - 1.2 linux/arch/h8300/mm/init.c - 1.2 linux/drivers/block/floppy98.c - 1.5 linux/arch/v850/kernel/teg.c - 1.2 linux/arch/v850/kernel/nb85e_cache.c - 1.2 linux/arch/ia64/kernel/module.c - 1.4 linux/net/ipv4/ipcomp.c - 1.5 linux/arch/m68k/kernel/module.c - 1.2 linux/arch/s390/kernel/entry64.S - 1.4 linux/drivers/scsi/dc395x.c - 1.6 linux/init/do_mounts_initrd.c - 1.2 linux/net/bridge/netfilter/ebt_pkttype.c - 1.2 linux/net/sctp/chunk.c - 1.2 linux/dev/null - 1.7 linux/drivers/usb/gadget/zero.c - 1.2 linux/drivers/usb/gadget/net2280.h - 1.2 linux/drivers/usb/gadget/net2280.c - 1.4 linux/drivers/usb/gadget/ether.c - 1.3 linux/drivers/scsi/scsi_priv.h - 1.4 linux/drivers/scsi/arm/acornscsi.c - 1.4 linux/drivers/scsi/arm/arxescsi.c - 1.4 linux/drivers/scsi/arm/cumana_1.c - 1.4 linux/drivers/scsi/arm/cumana_2.c - 1.4 linux/drivers/scsi/arm/ecoscsi.c - 1.4 linux/drivers/scsi/arm/eesox.c - 1.4 linux/net/ipv6/ipcomp6.c - 1.3 linux/drivers/scsi/arm/fas216.c - 1.3 linux/drivers/scsi/arm/oak.c - 1.4 linux/drivers/scsi/arm/powertec.c - 1.4 linux/net/atm/br2684.c - 1.3 linux/drivers/scsi/arm/queue.c - 1.2 linux/net/core/net-sysfs.c - 1.5 linux/drivers/mtd/mtd_blkdevs.c - 1.4 linux/drivers/pci/hotplug/Kconfig - 1.3 linux/drivers/pci/hotplug/acpiphp_glue.c - 1.4 linux/drivers/pci/hotplug/acpiphp_pci.c - 1.3 linux/drivers/pci/hotplug/cpci_hotplug.h - 1.2 linux/drivers/pci/hotplug/cpci_hotplug_core.c - 1.3 linux/drivers/pci/hotplug/cpci_hotplug_pci.c - 1.3 linux/arch/arm26/kernel/setup.c - 1.3 linux/arch/arm26/mm/init.c - 1.3 linux/net/ipv4/esp4.c - 1.2 linux/net/ipv4/ah4.c - 1.2 linux/fs/compat_ioctl.c - 1.4 linux/drivers/pcmcia/yenta_socket.c - 1.4 linux/drivers/usb/net/ax8817x.c - 1.2 linux/arch/ia64/scripts/toolchain-flags - 1.3 linux/include/scsi/scsi_request.h - 1.3 linux/include/scsi/scsi_host.h - 1.2 linux/include/scsi/scsi_device.h - 1.3 linux/arch/ia64/kernel/patch.c - 1.2 linux/drivers/media/dvb/dvb-core/dvb_functions.c - 1.2 linux/drivers/media/dvb/dvb-core/dvb_functions.h - 1.2 linux/drivers/s390/net/qeth.c - 1.2 linux/drivers/s390/net/qeth.h - 1.2 linux/drivers/s390/net/qeth_mpc.h - 1.2 linux/drivers/scsi/NCR_Q720.c - 1.2 linux/arch/mips/momentum/ocelot_c/setup.c - 1.2 linux/arch/mips/momentum/ocelot_g/setup.c - 1.2 linux/arch/mips/ramdisk/Makefile - 1.2 linux/arch/mips/sibyte/cfe/setup.c - 1.2 linux/arch/mips/sibyte/sb1250/prom.c - 1.2 linux/arch/mips/sibyte/swarm/setup.c - 1.2 linux/arch/mips/tx4927/toshiba_rbtx4927/toshiba_rbtx4927_irq.c - 1.2 linux/arch/mips/tx4927/toshiba_rbtx4927/toshiba_rbtx4927_setup.c - 1.2 linux/arch/mips/vr41xx/tanbac-tb0229/setup.c - 1.2 linux/drivers/block/as-iosched.c - 1.3 linux/net/ipv4/ipvs/ip_vs_ctl.c - 1.2 linux/net/ipv4/ipvs/ip_vs_conn.c - 1.2 linux/net/ipv4/ipvs/Kconfig - 1.2 linux/sound/oss/ad1889.c - 1.2 linux/sound/oss/ac97_plugin_ad1980.c - 1.2 linux/net/ipv4/ipvs/ip_vs_xmit.c - 1.2 linux/include/net/ip_vs.h - 1.2 linux/drivers/block/cryptoloop.c - 1.2 From owner-linux-xfs@oss.sgi.com Tue Jul 29 08:41:37 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 29 Jul 2003 08:41:42 -0700 (PDT) Received: from unicorn.drogon.net (unicorn.drogon.net [195.10.246.4]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h6TFfZFl017986 for ; Tue, 29 Jul 2003 08:41:36 -0700 Received: from unicorn.drogon.net (localhost [127.0.0.1]) by unicorn.drogon.net (8.12.9/8.12.9) with ESMTP id h6TFfIKd002375 for ; Tue, 29 Jul 2003 16:41:23 +0100 Received: from localhost (gordon@localhost) by unicorn.drogon.net (8.12.9/8.12.9/Submit) with ESMTP id h6TFfIWW002372 for ; Tue, 29 Jul 2003 16:41:18 +0100 X-Authentication-Warning: unicorn.drogon.net: gordon owned process doing -bs Date: Tue, 29 Jul 2003 16:41:18 +0100 (BST) From: Gordon Henderson To: linux-xfs@oss.sgi.com Subject: Re: Booting off XFS, lilo corruption? In-Reply-To: <3707.1059398651@ocs3.intra.ocs.com.au> Message-ID: References: <3707.1059398651@ocs3.intra.ocs.com.au> Distribution: world Organization: Home for lost Drogons MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Scanned-By: MIMEDefang 2.35 X-archive-position: 4775 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: gordon@drogon.net Precedence: bulk X-list: linux-xfs Content-Length: 2044 Lines: 55 On Mon, 28 Jul 2003, Keith Owens wrote: > Lilo and XFS coexist but only if lilo writes to the start of the disk, > _NOT_ the start of the XFS partition. XFS keeps its superblock at the > start of each partition, if anything overwrites that superblock that it > breaks the XFS filesystem. All systems have XFS / and lilo works fine, > with boot=/dev/hda, not boot=/dev/hda1. Ah right. Thanks also to Juri Haberland. So, I moved things about a little, then in lilo.conf tried: boot=/dev/hda root=/dev/md0 #raid-extra-boot=/dev/hda,/dev/hdc instead of: boot=/dev/md0 root=/dev/md0 raid-extra-boot=/dev/hda,/dev/hdc (md0 is a s/w RADI1 of /dev/hda1 and /dev/hdc1) to see if that worked, and it did. So I re-edited the lilo.conf to update /dev/hdc's MBR and that seemed OK too. To test it, I halted it, unplugged the hda drive power and rebooted. The box booted of hdc and the s/w raid1 did what it was supposed to do and life was fine. It's now re-building all the arrays, and when it's done I'll unplug the hcd drive and reboot just to doubly check. (and as I type this, it finished and I've just done the 2nd test and it's fine, so I'm happier now!) So I guess when I install a new kernel, I just have to run lilo twice with each of /dev/hda and /dev/hdc selected (Which is I guess what the raid-extra-boot is doing when it thinks you have a boot=/dev/md0 device) > BTW,. you should be able to run xfs_repair on the broken filesystem and > recover your data, xfs_repair will seach for a secondary superblock and > reconstruct the one that lilo stamped on. Since this is /, you will > need to boot an emergency system such as the install CD booted with > 'linux rescue' then run xfs_repair on md1. That did actually work! I've never had to xfs_repair anything (yet) so it was a good test. (Although it was a clone of with working / off md0 so I didn't actually lose anything, but a good test anyway) Now to build another kernel with no ext2 in it and see if I can fit it onto a floppy to use as a rescue disk... Thanks, Gordon From owner-linux-xfs@oss.sgi.com Tue Jul 29 08:47:48 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 29 Jul 2003 08:47:59 -0700 (PDT) Received: from Cantor.suse.de (ns.suse.de [213.95.15.193]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h6TFlkFl018835 for ; Tue, 29 Jul 2003 08:47:48 -0700 Received: from Hermes.suse.de (Hermes.suse.de [213.95.15.136]) by Cantor.suse.de (Postfix) with ESMTP id 745C414620; Tue, 29 Jul 2003 17:47:41 +0200 (MEST) Date: Tue, 29 Jul 2003 17:47:40 +0200 From: Andi Kleen To: linux-xfs@oss.sgi.com Cc: erbenson@alaska.net Subject: Re: [PATCH] Implement immutable/append-only flags in XFS #3 Message-ID: <20030729154740.GD7435@wotan.suse.de> References: <20030722003443.GA13188@plato.local.lan> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030722003443.GA13188@plato.local.lan> X-archive-position: 4776 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: ak@suse.de Precedence: bulk X-list: linux-xfs Content-Length: 1787 Lines: 38 On Mon, Jul 21, 2003 at 04:34:43PM -0800, Ethan Benson wrote: > My question on #3 is whether we want this behavior in XFS? my current > patch does NOT implement it. My opinion is that the only flag this > really makes sense for is sync, since setting the sync flag on a inherited sync is very useful. iirc it was introduced because some mail servers assume everything is a BSD with UFS and rename is always synchronous, otherwise they have potential crash recovery issues. You just set sync on the spool and everything ends up safely synchronous. AFAIK the XFS transaction manager does not guarantee the the transaction is committed before the rename returns, so it would be needed even on XFS. However XFS seems to be default to osyncisdsync, and for the mail server use case you need O_SYNC, not O_DSYNC. Maybe it would be useful to define a new bit for both cases? > of this. I am definitely not convinced its a sensible idea for > append-only since it ends up allowing non-privileged users to create > append-only files, which is not normally permitted. Also > automatically setting the append-only flag on a newly created file Agreed. I assume ext2/reiser do also not inherit it, right? > I have a (somewhat hideous) test program to check as many things as i > could think of to ensure immutable/append-only are properly enforced, > the only thing lacking in it is tests of all the XFS ioctls, perhaps > someone familiar with xfs ioctls could add these, currently the > libhandle open/write tests are done. You can find this test program > at http://penguinppc.org/~eb/t_immutable.c I would suggest to submit that program to LTP. I'm sure they would appreciate more test cases and it would help making all the linux file systems behave similar in this area. -Andi From owner-linux-xfs@oss.sgi.com Tue Jul 29 09:35:34 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 29 Jul 2003 09:35:47 -0700 (PDT) Received: from tolkor.sgi.com ([198.149.18.6]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h6TGZXFl024055 for ; Tue, 29 Jul 2003 09:35:33 -0700 Received: from flecktone.americas.sgi.com (flecktone.americas.sgi.com [192.48.203.135]) by tolkor.sgi.com (8.12.9/8.12.9/linux-outbound_gateway-1.1) with ESMTP id h6TGsisR032145 for ; Tue, 29 Jul 2003 11:54:44 -0500 Received: from daisy-e236.americas.sgi.com (daisy-e236.americas.sgi.com [128.162.236.214]) by flecktone.americas.sgi.com (8.12.9/8.12.9/generic_config-1.2) with ESMTP id h6TGZRQK2801136 for ; Tue, 29 Jul 2003 11:35:27 -0500 (CDT) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.232.100]) by daisy-e236.americas.sgi.com (8.12.9/SGI-server-1.8) with ESMTP id h6TGZRRn188308869 for ; Tue, 29 Jul 2003 11:35:27 -0500 (CDT) From: Steve Lord Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id h6TGZRU17707; Tue, 29 Jul 2003 11:35:27 -0500 Message-Id: <200307291635.h6TGZRU17707@jen.americas.sgi.com> Date: Tue, 29 Jul 2003 11:35:27 -0500 Subject: TAKE - implement true AIO for xfs in 2.6 To: linux-xfs@oss.sgi.com X-archive-position: 4777 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: lord@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 1018 Lines: 34 Rework XFS read/write path so that there is one common read and one common write path for all the different I/O variants. This means we can now support true async I/O. Date: Tue Jul 29 09:33:46 PDT 2003 Workarea: jen.americas.sgi.com:/src/lord/xfs-linux.2.5 The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.5.x-xfs Modid: 2.5.x-xfs:slinx:154475a linux/mm/filemap.c - 1.160 - Export __generic_file_aio_read so xfs can use it linux/include/linux/fs.h - 1.220 - Prototype for __generic_file_aio_read linux/fs/xfs/linux/xfs_lrw.h - 1.38 - change prototypes for xfs_read and xfs_write linux/fs/xfs/linux/xfs_lrw.c - 1.190 - Pass an iocb down through xfs_read and xfs_write to allow them to be used for true async I/O. linux/fs/xfs/linux/xfs_file.c - 1.92 - lip over to using the aio interface for read write. Change the next layer down to take an iocb instead of a file pointer. linux/fs/xfs/linux/xfs_vnode.h - 1.83 - pass an iocb down into the read and write path From owner-linux-xfs@oss.sgi.com Tue Jul 29 09:42:35 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 29 Jul 2003 09:42:53 -0700 (PDT) Received: from tolkor.sgi.com ([198.149.18.6]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h6TGgYFl024531 for ; Tue, 29 Jul 2003 09:42:35 -0700 Received: from flecktone.americas.sgi.com (flecktone.americas.sgi.com [192.48.203.135]) by tolkor.sgi.com (8.12.9/8.12.9/linux-outbound_gateway-1.1) with ESMTP id h6TH1jsR001626 for ; Tue, 29 Jul 2003 12:01:45 -0500 Received: from daisy-e236.americas.sgi.com (daisy-e236.americas.sgi.com [128.162.236.214]) by flecktone.americas.sgi.com (8.12.9/8.12.9/generic_config-1.2) with ESMTP id h6TGgTQK2802973 for ; Tue, 29 Jul 2003 11:42:29 -0500 (CDT) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.232.100]) by daisy-e236.americas.sgi.com (8.12.9/SGI-server-1.8) with ESMTP id h6TGgNRn199854011 for ; Tue, 29 Jul 2003 11:42:23 -0500 (CDT) From: Steve Lord Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id h6TGgMo17912; Tue, 29 Jul 2003 11:42:22 -0500 Message-Id: <200307291642.h6TGgMo17912@jen.americas.sgi.com> Date: Tue, 29 Jul 2003 11:42:22 -0500 Subject: TAKE - support sector size O_DIRECT alignment in 2.6 To: linux-xfs@oss.sgi.com X-archive-position: 4778 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: lord@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 1040 Lines: 32 Change XFS to support sector aligned O_DIRECT rather than filesystem block alignment. Date: Tue Jul 29 09:41:53 PDT 2003 Workarea: jen.americas.sgi.com:/src/lord/xfs-linux.2.5 The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.5.x-xfs Modid: 2.5.x-xfs:slinx:154477a linux/fs/xfs/linux/xfs_lrw.c - 1.191 - Do per device alignment for direct IO. linux/fs/xfs/linux/xfs_ioctl.c - 1.98 - Change XFS_IOC_DIOINFO to return the new alignment rules linux/fs/xfs/pagebuf/page_buf.h - 1.72 - Add new flags for bmap options and results linux/fs/xfs/linux/xfs_aops.c - 1.42 - Use the PBMF_NEW flag on an extent to indicate that the buffer head is new. In the direct IO path, determine which device the inode lies on so we can pass it down to blockdev_direct_IO. Lets us do sector aligned O_DIRECT on the data device. linux/fs/xfs/linux/xfs_iomap.c - 1.12 - If we create a new mapping during an iomap operation, set the PBMF_NEW flag in it. Done under the ilock, so only one thread ever gets it. From owner-linux-xfs@oss.sgi.com Tue Jul 29 09:43:32 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 29 Jul 2003 09:43:36 -0700 (PDT) Received: from mail.iwr.uni-heidelberg.de (mail.iwr.uni-heidelberg.de [129.206.104.30]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h6TGhUFl024710 for ; Tue, 29 Jul 2003 09:43:31 -0700 Received: from kenzo.iwr.uni-heidelberg.de (IDENT:YJwPljpLHBX37V1myOX2kFI4I3YYO9RP@kenzo.iwr.uni-heidelberg.de [129.206.120.29]) by mail.iwr.uni-heidelberg.de (8.12.9/8.12.9) with ESMTP id h6TGhMru001680; Tue, 29 Jul 2003 18:43:22 +0200 (MET DST) Received: from kenzo.iwr.uni-heidelberg.de (localhost.localdomain [127.0.0.1]) by kenzo.iwr.uni-heidelberg.de (8.12.8/8.12.8) with ESMTP id h6TGhM5K014682; Tue, 29 Jul 2003 18:43:22 +0200 Received: from localhost (bogdan@localhost) by kenzo.iwr.uni-heidelberg.de (8.12.8/8.12.8/Submit) with ESMTP id h6TGhLS6014678; Tue, 29 Jul 2003 18:43:22 +0200 Date: Tue, 29 Jul 2003 18:43:21 +0200 (CEST) From: Bogdan Costescu To: Gordon Henderson cc: linux-xfs@oss.sgi.com Subject: Re: Booting off XFS, lilo corruption? In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 4779 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: bogdan.costescu@iwr.uni-heidelberg.de Precedence: bulk X-list: linux-xfs Content-Length: 513 Lines: 16 On Tue, 29 Jul 2003, Gordon Henderson wrote: > So I guess when I install a new kernel, I just have to run lilo twice with > each of /dev/hda and /dev/hdc selected Or run "dd if=/dev/hda of=/dev/hdc bs=512 count=1" which will copy the MBR from hda to hdc... -- Bogdan Costescu IWR - Interdisziplinaeres Zentrum fuer Wissenschaftliches Rechnen Universitaet Heidelberg, INF 368, D-69120 Heidelberg, GERMANY Telephone: +49 6221 54 8869, Telefax: +49 6221 54 8868 E-mail: Bogdan.Costescu@IWR.Uni-Heidelberg.De From owner-linux-xfs@oss.sgi.com Tue Jul 29 09:44:28 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 29 Jul 2003 09:44:30 -0700 (PDT) Received: from tolkor.sgi.com ([198.149.18.6]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h6TGiRFl025162 for ; Tue, 29 Jul 2003 09:44:27 -0700 Received: from flecktone.americas.sgi.com (flecktone.americas.sgi.com [192.48.203.135]) by tolkor.sgi.com (8.12.9/8.12.9/linux-outbound_gateway-1.1) with ESMTP id h6TH3csR002034 for ; Tue, 29 Jul 2003 12:03:38 -0500 Received: from daisy-e236.americas.sgi.com (daisy-e236.americas.sgi.com [128.162.236.214]) by flecktone.americas.sgi.com (8.12.9/8.12.9/generic_config-1.2) with ESMTP id h6TGiLQK2811324 for ; Tue, 29 Jul 2003 11:44:21 -0500 (CDT) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.232.100]) by daisy-e236.americas.sgi.com (8.12.9/SGI-server-1.8) with ESMTP id h6TGiLRn198196954 for ; Tue, 29 Jul 2003 11:44:21 -0500 (CDT) From: Steve Lord Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id h6TGiLw18024; Tue, 29 Jul 2003 11:44:21 -0500 Message-Id: <200307291644.h6TGiLw18024@jen.americas.sgi.com> Date: Tue, 29 Jul 2003 11:44:21 -0500 Subject: TAKE - use generic permission path if we have no acls To: linux-xfs@oss.sgi.com X-archive-position: 4780 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: lord@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 388 Lines: 15 Make the permission operation in xfs conditional on ACLs being compiled in Date: Tue Jul 29 09:43:42 PDT 2003 Workarea: jen.americas.sgi.com:/src/lord/xfs-linux.2.5 The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.5.x-xfs Modid: 2.5.x-xfs:slinx:154479a linux/fs/xfs/linux/xfs_iops.c - 1.205 - Only setup a permission call if we have acl's turned on From owner-linux-xfs@oss.sgi.com Tue Jul 29 09:47:04 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 29 Jul 2003 09:47:07 -0700 (PDT) Received: from unicorn.drogon.net (unicorn.drogon.net [195.10.246.4]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h6TGl2Fl025828 for ; Tue, 29 Jul 2003 09:47:03 -0700 Received: from unicorn.drogon.net (localhost [127.0.0.1]) by unicorn.drogon.net (8.12.9/8.12.9) with ESMTP id h6TGkpKd002784 for ; Tue, 29 Jul 2003 17:46:55 +0100 Received: from localhost (gordon@localhost) by unicorn.drogon.net (8.12.9/8.12.9/Submit) with ESMTP id h6TGkpvx002781 for ; Tue, 29 Jul 2003 17:46:51 +0100 X-Authentication-Warning: unicorn.drogon.net: gordon owned process doing -bs Date: Tue, 29 Jul 2003 17:46:51 +0100 (BST) From: Gordon Henderson To: linux-xfs@oss.sgi.com Subject: Re: Booting off XFS, lilo corruption? In-Reply-To: Message-ID: References: Distribution: world Organization: Home for lost Drogons MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Scanned-By: MIMEDefang 2.35 X-archive-position: 4781 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: gordon@drogon.net Precedence: bulk X-list: linux-xfs Content-Length: 430 Lines: 15 On Tue, 29 Jul 2003, Bogdan Costescu wrote: > On Tue, 29 Jul 2003, Gordon Henderson wrote: > > > So I guess when I install a new kernel, I just have to run lilo twice with > > each of /dev/hda and /dev/hdc selected > > Or run "dd if=/dev/hda of=/dev/hdc bs=512 count=1" which will copy the MBR > from hda to hdc... Good idea, and since /sbin/lilo on a Debian system is a shell-script anyway, I can just add it into it. Gordon From owner-linux-xfs@oss.sgi.com Tue Jul 29 09:50:03 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 29 Jul 2003 09:50:06 -0700 (PDT) Received: from tolkor.sgi.com ([198.149.18.6]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h6TGo2Fl026284 for ; Tue, 29 Jul 2003 09:50:03 -0700 Received: from flecktone.americas.sgi.com (flecktone.americas.sgi.com [192.48.203.135]) by tolkor.sgi.com (8.12.9/8.12.9/linux-outbound_gateway-1.1) with ESMTP id h6TH9EsR003506 for ; Tue, 29 Jul 2003 12:09:14 -0500 Received: from daisy-e236.americas.sgi.com (daisy-e236.americas.sgi.com [128.162.236.214]) by flecktone.americas.sgi.com (8.12.9/8.12.9/generic_config-1.2) with ESMTP id h6TGnvQK2806675 for ; Tue, 29 Jul 2003 11:49:57 -0500 (CDT) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.232.100]) by daisy-e236.americas.sgi.com (8.12.9/SGI-server-1.8) with ESMTP id h6TGnuRn201840756 for ; Tue, 29 Jul 2003 11:49:57 -0500 (CDT) From: Steve Lord Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id h6TGnuo18240; Tue, 29 Jul 2003 11:49:56 -0500 Message-Id: <200307291649.h6TGnuo18240@jen.americas.sgi.com> Date: Tue, 29 Jul 2003 11:49:56 -0500 Subject: TAKE - use i_size_read and i_size_write To: linux-xfs@oss.sgi.com X-archive-position: 4782 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: lord@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 616 Lines: 22 Use i_size_read and i_size_write instead of direct access to the i_size field. Date: Tue Jul 29 09:49:18 PDT 2003 Workarea: jen.americas.sgi.com:/src/lord/xfs-linux.2.5 The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.5.x-xfs Modid: 2.5.x-xfs:slinx:154481a linux/fs/xfs/linux/xfs_vnode.c - 1.115 linux/fs/xfs/linux/xfs_super.c - 1.279 - Use i_size_write to set inode size linux/fs/xfs/linux/xfs_aops.c - 1.43 - Switch xfs to using i_size_read and i_size_write, fix a bug in the unwritten extent case where we could incorrectly treat a page as the last one in the file. From owner-linux-xfs@oss.sgi.com Tue Jul 29 09:56:35 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 29 Jul 2003 09:56:53 -0700 (PDT) Received: from tolkor.sgi.com ([198.149.18.6]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h6TGuYFl026775 for ; Tue, 29 Jul 2003 09:56:35 -0700 Received: from flecktone.americas.sgi.com (flecktone.americas.sgi.com [192.48.203.135]) by tolkor.sgi.com (8.12.9/8.12.9/linux-outbound_gateway-1.1) with ESMTP id h6THFksR005608 for ; Tue, 29 Jul 2003 12:15:46 -0500 Received: from daisy-e236.americas.sgi.com (daisy-e236.americas.sgi.com [128.162.236.214]) by flecktone.americas.sgi.com (8.12.9/8.12.9/generic_config-1.2) with ESMTP id h6TGuTQK2763055 for ; Tue, 29 Jul 2003 11:56:29 -0500 (CDT) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.232.100]) by daisy-e236.americas.sgi.com (8.12.9/SGI-server-1.8) with ESMTP id h6TGuTRn203332862 for ; Tue, 29 Jul 2003 11:56:29 -0500 (CDT) From: Steve Lord Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id h6TGuT718378; Tue, 29 Jul 2003 11:56:29 -0500 Message-Id: <200307291656.h6TGuT718378@jen.americas.sgi.com> Date: Tue, 29 Jul 2003 11:56:29 -0500 Subject: TAKE - do not submit I/O to devices which cannot take it To: linux-xfs@oss.sgi.com X-archive-position: 4783 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: lord@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 593 Lines: 21 Fix a couple of pagebuf end cases, in particular, deal with block device which is not correctly initialized and do not submit a bio to it - that trips a BUG. Date: Tue Jul 29 09:56:00 PDT 2003 Workarea: jen.americas.sgi.com:/src/lord/xfs-linux.2.5 The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.5.x-xfs Modid: 2.5.x-xfs:slinx:154483a linux/fs/xfs/pagebuf/page_buf.c - 1.115 - Deal with the case where a block device will not take any I/O, do not submit empty bio structures to it. linux/fs/xfs/linux/xfs_aops.c - 1.44 - Fix sign of error variable From owner-linux-xfs@oss.sgi.com Tue Jul 29 11:49:50 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 29 Jul 2003 11:49:56 -0700 (PDT) Received: from dmz.tecosim.de (dmz.tecosim.com [195.135.152.162]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h6TInmFl001618 for ; Tue, 29 Jul 2003 11:49:49 -0700 Received: from alg-ru.tecosim.de (alg-ru-ext.tecosim.com [195.135.152.146]) by dmz.tecosim.de (Postfix) with ESMTP id 6CEAD18084 for ; Tue, 29 Jul 2003 20:49:42 +0200 (CEST) Received: from ns.tecosim.de (unknown [10.0.2.1]) by alg-ru.tecosim.de (Postfix) with ESMTP id 3C74D18098 for ; Tue, 29 Jul 2003 20:49:42 +0200 (CEST) Received: from donner.tecosim.de (donner.tecosim.de [10.0.16.1]) by ns.tecosim.de (8.11.6/8.11.6) with ESMTP id h6TInfN32093 for ; Tue, 29 Jul 2003 20:49:41 +0200 Received: by donner.tecosim.de (Postfix, from userid 272) id 4A4F94DCB1; Tue, 29 Jul 2003 14:49:41 -0400 (EDT) Date: Tue, 29 Jul 2003 20:49:41 +0200 From: Utz Lehmann To: linux-xfs@oss.sgi.com Subject: Cant create new files: No space left on device Message-ID: <20030729204941.D30198@de.tecosim.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i X-Scanned-By: MIMEDefang 2.16 (www . roaringpenguin . com / mimedefang) X-archive-position: 4784 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: u.lehmann@de.tecosim.com Precedence: bulk X-list: linux-xfs Content-Length: 2825 Lines: 81 Hi I have a litte problem with a xfs filesystem while stress testing a new server (not in production yet). When i try to create a new file i get no space left on device but have 13GB available. The filesystem is on an ide to ide hardware raid5 (3*250GB) with only a big hde3 partition used as an lvm volume group (vg01). vg01 is completly filled with /dev/vg01/raid. The filesystem is filled up by coping files into it (local and via nfs export) and running xfs_fsr parallel a few times. Tested kernels are kernel-smp-2.4.20-18.9XFS1.3.0pre4.i686.rpm, kernel-smp-2.4.20-18.9XFS1.3.0pre2.i686.rpm from oss.sgi.com and kernel-smp-2.4.20-18.7SGI_XFS_1.2.0_teco1.i686.rpm (source rpm from Seth Mos + task_unmapped_base.patch and different config). xfs_check and xfs_repair -n reports no errors. The filesystem is made with mkfs.xfs -f -d sunit=4,swidth=8 /dev/vg01/raid. # xfs_info /mnt/raid/ meta-data=/mnt/raid isize=256 agcount=117, agsize=1048572 blks = sectsz=512 data = bsize=4096 blocks=122535936, imaxpct=25 = sunit=4 swidth=8 blks, unwritten=0 naming =version 2 bsize=4096 log =internal bsize=4096 blocks=14958, version=1 = sectsz=512 sunit=0 blks realtime =none extsz=65536 blocks=0, rtextents=0 It's mounted with logbufs=8,logbsize=32768 but with default mount options i get the same error. # touch /mnt/raid/test touch: creating /mnt/raid/test': No space left on device # df /mnt/raid/ Filesystem 1K-blocks Used Available Use% Mounted on /dev/vg01/raid 490083912 476491096 13592816 98% /mnt/raid # df -i /mnt/raid/ Filesystem Inodes IUsed IFree IUse% Mounted on /dev/vg01/raid 57039104 2667840 54371264 5% /mnt/raid # xfs_db /dev/vg01/raid xfs_db> freesp -s from to extents blocks pct 1 1 179733 179733 5.30 2 3 1172308 3211512 94.70 total free extents 1352041 total free blocks 3391245 average free extent size 2.50824 This means that i have only 1-3 block sized free extents, right? Maybe this caused the error because it's smaller that the sunit/swidth? (wild guess). It has something todo with creating new files. When i delete one file i can create exacly one file and fill up the whole filesystem: # rm /mnt/raid/raid7/cust/tecosim/cfd/utils/bin/xemacs_hp.gz # >/mnt/raid/test # >/mnt/raid/test2 -bash: test2: No space left on device # dd if=/dev/zero of=/mnt/raid/test bs=128k # df /mnt/raid/ Filesystem 1K-blocks Used Available Use% Mounted on /dev/vg01/raid 490083912 490083860 52 100% /mnt/raid thanks utz From owner-linux-xfs@oss.sgi.com Tue Jul 29 12:00:17 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 29 Jul 2003 12:00:20 -0700 (PDT) Received: from zok.sgi.com (zok.SGI.COM [204.94.215.101]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h6TJ0GFl002671 for ; Tue, 29 Jul 2003 12:00:16 -0700 Received: from flecktone.americas.sgi.com (flecktone.americas.sgi.com [192.48.203.135]) by zok.sgi.com (8.12.9/8.12.9/linux-outbound_gateway-1.1) with ESMTP id h6TJ0Bq0032767 for ; Tue, 29 Jul 2003 12:00:11 -0700 Received: from poppy-e236.americas.sgi.com (poppy-e236.americas.sgi.com [128.162.236.207]) by flecktone.americas.sgi.com (8.12.9/8.12.9/generic_config-1.2) with ESMTP id h6TIxAQK2851122; Tue, 29 Jul 2003 13:59:10 -0500 (CDT) Received: from stout.americas.sgi.com (stout.americas.sgi.com [128.162.232.50]) by poppy-e236.americas.sgi.com (8.12.9/SGI-server-1.8) with ESMTP id h6TIx6Yk15613500; Tue, 29 Jul 2003 13:59:10 -0500 (CDT) Subject: Re: Cant create new files: No space left on device From: Eric Sandeen To: Utz Lehmann Cc: linux-xfs@oss.sgi.com In-Reply-To: <20030729204941.D30198@de.tecosim.com> References: <20030729204941.D30198@de.tecosim.com> Content-Type: text/plain Organization: Message-Id: <1059505146.1638.14.camel@stout.americas.sgi.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 (1.2.2-5) Date: 29 Jul 2003 13:59:06 -0500 Content-Transfer-Encoding: 7bit X-archive-position: 4785 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: sandeen@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 50 Lines: 4 Try df -i to see if you're out of inodes? -Eric From owner-linux-xfs@oss.sgi.com Tue Jul 29 12:12:35 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 29 Jul 2003 12:12:48 -0700 (PDT) Received: from tolkor.sgi.com (tolkor.SGI.COM [198.149.18.6]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h6TJCYFl003965 for ; Tue, 29 Jul 2003 12:12:35 -0700 Received: from flecktone.americas.sgi.com (flecktone.americas.sgi.com [192.48.203.135]) by tolkor.sgi.com (8.12.9/8.12.9/linux-outbound_gateway-1.1) with ESMTP id h6TJVksR011993 for ; Tue, 29 Jul 2003 14:31:46 -0500 Received: from daisy-e236.americas.sgi.com (daisy-e236.americas.sgi.com [128.162.236.214]) by flecktone.americas.sgi.com (8.12.9/8.12.9/generic_config-1.2) with ESMTP id h6TJCTQK2833707; Tue, 29 Jul 2003 14:12:29 -0500 (CDT) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.232.100]) by daisy-e236.americas.sgi.com (8.12.9/SGI-server-1.8) with ESMTP id h6TJCSRn201061346; Tue, 29 Jul 2003 14:12:28 -0500 (CDT) Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id h6TJCS818599; Tue, 29 Jul 2003 14:12:28 -0500 Subject: Re: Cant create new files: No space left on device From: Steve Lord To: Utz Lehmann Cc: linux-xfs@oss.sgi.com In-Reply-To: <20030729204941.D30198@de.tecosim.com> References: <20030729204941.D30198@de.tecosim.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit Organization: Message-Id: <1059505947.6601.1067.camel@jen.americas.sgi.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.4 Date: 29 Jul 2003 14:12:28 -0500 X-archive-position: 4786 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: lord@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 3793 Lines: 100 On Tue, 2003-07-29 at 13:49, Utz Lehmann wrote: > Hi > > I have a litte problem with a xfs filesystem while stress testing a new > server (not in production yet). > When i try to create a new file i get no space left on device but have 13GB > available. > > > The filesystem is on an ide to ide hardware raid5 (3*250GB) with only a big > hde3 partition used as an lvm volume group (vg01). vg01 is completly filled > with /dev/vg01/raid. > > The filesystem is filled up by coping files into it (local and via nfs > export) and running xfs_fsr parallel a few times. > > Tested kernels are kernel-smp-2.4.20-18.9XFS1.3.0pre4.i686.rpm, > kernel-smp-2.4.20-18.9XFS1.3.0pre2.i686.rpm from oss.sgi.com and > kernel-smp-2.4.20-18.7SGI_XFS_1.2.0_teco1.i686.rpm (source rpm from Seth Mos > + task_unmapped_base.patch and different config). > > xfs_check and xfs_repair -n reports no errors. > > > The filesystem is made with mkfs.xfs -f -d sunit=4,swidth=8 /dev/vg01/raid. > > # xfs_info /mnt/raid/ > meta-data=/mnt/raid isize=256 agcount=117, agsize=1048572 > blks > = sectsz=512 > data = bsize=4096 blocks=122535936, imaxpct=25 > = sunit=4 swidth=8 blks, unwritten=0 > naming =version 2 bsize=4096 > log =internal bsize=4096 blocks=14958, version=1 > = sectsz=512 sunit=0 blks > realtime =none extsz=65536 blocks=0, rtextents=0 > > It's mounted with logbufs=8,logbsize=32768 but with default mount options i > get the same error. > > > > # touch /mnt/raid/test > touch: creating /mnt/raid/test': No space left on device > > # df /mnt/raid/ > Filesystem 1K-blocks Used Available Use% Mounted on > /dev/vg01/raid 490083912 476491096 13592816 98% /mnt/raid > > # df -i /mnt/raid/ > Filesystem Inodes IUsed IFree IUse% Mounted on > /dev/vg01/raid 57039104 2667840 54371264 5% /mnt/raid > > # xfs_db /dev/vg01/raid > xfs_db> freesp -s > from to extents blocks pct > 1 1 179733 179733 5.30 > 2 3 1172308 3211512 94.70 > total free extents 1352041 > total free blocks 3391245 > average free extent size 2.50824 > > This means that i have only 1-3 block sized free extents, right? > Maybe this caused the error because it's smaller that the sunit/swidth? > (wild guess). > > It has something todo with creating new files. When i delete one file i can > create exacly one file and fill up the whole filesystem: > > # rm /mnt/raid/raid7/cust/tecosim/cfd/utils/bin/xemacs_hp.gz > # >/mnt/raid/test > # >/mnt/raid/test2 > -bash: test2: No space left on device > # dd if=/dev/zero of=/mnt/raid/test bs=128k > # df /mnt/raid/ > Filesystem 1K-blocks Used Available Use% Mounted on > /dev/vg01/raid 490083912 490083860 52 100% /mnt/raid > > I think you got bitten by stripe alignment. Inode clusters are allocated on stripe boundaries. You probably have no boundaries left free, so it cannot allocate any inode space. If you go into xfs_db again, and run freesp, then run frag, what does it say? We probably need to revisit how files are getting allocated for NFS, I think it is not doing a very good job in this case. What sort of file size are you talking about here, the numbers say about 175K but I want to check. In this setup fsr will not do anything, and it can sometimes have the effect of defragmenting files, but fragmenting the remaining free space. Steve -- Steve Lord voice: +1-651-683-3511 Principal Engineer, Filesystem Software email: lord@sgi.com From owner-linux-xfs@oss.sgi.com Tue Jul 29 12:24:31 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 29 Jul 2003 12:24:46 -0700 (PDT) Received: from tolkor.sgi.com (tolkor.SGI.COM [198.149.18.6]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h6TJOVFl005122 for ; Tue, 29 Jul 2003 12:24:31 -0700 Received: from flecktone.americas.sgi.com (flecktone.americas.sgi.com [192.48.203.135]) by tolkor.sgi.com (8.12.9/8.12.9/linux-outbound_gateway-1.1) with ESMTP id h6TJhhsR015263 for ; Tue, 29 Jul 2003 14:43:43 -0500 Received: from daisy-e236.americas.sgi.com (daisy-e236.americas.sgi.com [128.162.236.214]) by flecktone.americas.sgi.com (8.12.9/8.12.9/generic_config-1.2) with ESMTP id h6TJOPQK2850410; Tue, 29 Jul 2003 14:24:25 -0500 (CDT) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.232.100]) by daisy-e236.americas.sgi.com (8.12.9/SGI-server-1.8) with ESMTP id h6TJOPRn200174661; Tue, 29 Jul 2003 14:24:25 -0500 (CDT) Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id h6TJOPR18647; Tue, 29 Jul 2003 14:24:25 -0500 Subject: Re: Cant create new files: No space left on device From: Steve Lord To: Utz Lehmann Cc: linux-xfs@oss.sgi.com In-Reply-To: <1059505947.6601.1067.camel@jen.americas.sgi.com> References: <20030729204941.D30198@de.tecosim.com> <1059505947.6601.1067.camel@jen.americas.sgi.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit Organization: Message-Id: <1059506664.6604.1070.camel@jen.americas.sgi.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.4 Date: 29 Jul 2003 14:24:25 -0500 X-archive-position: 4787 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: lord@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 702 Lines: 22 On Tue, 2003-07-29 at 14:12, Steve Lord wrote: > I think you got bitten by stripe alignment. Inode clusters are allocated > on stripe boundaries. You probably have no boundaries left free, so > it cannot allocate any inode space. > Actually, you are out of inode room. We actually allocate inodes in blocks of 64 - which is 4 fs blocks in the default setup. We deal with them in memory in chunks of 2 fs blocks, but on disk we ask for 64 at a time. So, working out how not to fragment so much in the first place would be the best solution here. Steve -- Steve Lord voice: +1-651-683-3511 Principal Engineer, Filesystem Software email: lord@sgi.com From owner-linux-xfs@oss.sgi.com Tue Jul 29 12:43:07 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 29 Jul 2003 12:43:12 -0700 (PDT) Received: from palrel10.hp.com (palrel10.hp.com [156.153.255.245]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h6TJgvFl006661 for ; Tue, 29 Jul 2003 12:42:57 -0700 Received: from xparelay2.ptp.hp.com (xparelay2.ptp.hp.com [15.1.28.65]) by palrel10.hp.com (Postfix) with ESMTP id CE1701C016E1 for ; Tue, 29 Jul 2003 12:07:26 -0700 (PDT) Received: from xpabh3.ptp.hp.com (xpabh3.ptp.hp.com [15.1.28.63]) by xparelay2.ptp.hp.com (Postfix) with ESMTP id BFF7B1C00AD6 for ; Tue, 29 Jul 2003 12:07:26 -0700 (PDT) Received: by xpabh3.ptp.hp.com with Internet Mail Service (5.5.2655.55) id ; Tue, 29 Jul 2003 12:07:26 -0700 Message-ID: From: "HABBINGA,ERIK (HP-Loveland,ex1)" To: "'linux-xfs@oss.sgi.com'" Subject: re: FW: The infamous BUG in page_buff.c Date: Tue, 29 Jul 2003 12:07:21 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) Content-Type: text/plain; charset="iso-8859-1" X-archive-position: 4788 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: erik.habbinga@hp.com Precedence: bulk X-list: linux-xfs Content-Length: 4501 Lines: 133 I just saw the same crash this morning, my first experience with 2.6.0-test2. 4 x Xeon processors 2 GB ram fibre channel drives more details upon request... I was running SPEC SFS, so 144 nfs client processes spread across 8 nfs client machines attached by gigabit ethernet to my server under test. 36 file systems, and SPEC was trying to write 555 MB to each filesystem as fast as the NFS/network infrastructure would allow. I'm running stock 2.6.0-test2 with the qlogic qla2xxx fibre channel driver version 8.00.00b4 (http://sourceforge.net/projects/linux-qla2xxx/) and the following patch to the driver code to make the luns visible. --- linux/drivers/scsi/qla2xxx/qla_os.c~ Tue Jul 29 08:39:12 2003 +++ linux/drivers/scsi/qla2xxx/qla_os.c Tue Jul 29 08:38:56 2003 @@ -2634,6 +2634,7 @@ qla2x00_cfg_display_devices(); scsi_add_host(host, &pdev->dev); + scsi_scan_host(host); return 0; Here's the oops/BUG listing. Thanks, Erik Habbinga Hewlett Packard # ------------[ cut here ]------------ kernel BUG at fs/xfs/pagebuf/page_buf.c:1291! invalid operand: 0000 [#1] CPU: 6 EIP: 0060:[] Not tainted EFLAGS: 00010202 EIP is at bio_end_io_pagebuf+0xc2/0x12e eax: 00000001 ebx: f6fb2380 ecx: 00000000 edx: c185a778 esi: f060fbc0 edi: 00000000 ebp: ed2bf600 esp: f5f3d9fc ds: 007b es: 007b ss: 0068 Process nfsd (pid: 5007, threadinfo=f5f3c000 task=f56e46a0) Stack: 00000001 00000000 00000046 c26a0a00 00000009 00001000 ed2bf600 00000000 00000200 00000200 c01562d7 ed2bf600 00000200 00000000 01801b1f 00000200 ed2bf600 c0269374 ed2bf600 00000200 00000000 c2654600 ed2bf600 00000000 Call Trace: [] bio_endio+0x55/0x7a [] __end_that_request_first+0x204/0x224 [] scsi_end_request+0x3b/0xbc [] scsi_io_completion+0x144/0x442 [] scsi_delete_timer+0x16/0x30 [] sd_rw_intr+0x4e/0x198 [] xfs_trans_commit+0x116/0x3d4 [] xfs_trans_dup+0xed/0xfc [] xfs_itruncate_finish+0x24d/0x430 [] xfs_inactive_free_eofblocks+0x26c/0x2ba [] xfs_rwunlock+0x1/0x3a [] xfs_release+0x94/0xdc [] linvfs_release+0x1d/0x24 [] close_private_file+0x28/0x2a [] nfsd_close+0x1d/0x3c [] nfsd_write+0x20d/0x348 [] udp_push_pending_frames+0x12d/0x244 [] udp_sendpage+0xf3/0x2a6 [] svcauth_unix_accept+0x26a/0x28e [] nfsd_proc_write+0xa8/0x122 [] nfsd_dispatch+0xe8/0x1e5 [] nfsd_dispatch+0x0/0x1e5 [] svc_process+0x4eb/0x673 [] nfsd+0x1de/0x388 [] nfsd+0x0/0x388 [] kernel_thread_helper+0x5/0xc Code: 0f 0b 0b 05 4f a6 37 c0 eb a9 89 d0 e8 d3 12 f2 ff eb a0 81 <0>Kernel panic: Fatal exception in interrupt In interrupt handler - not syncing Sorry for the repost I forgot to cc the list..... -----Original Message----- From: Kostadin Todorov Karaivanov [ ] Sent: Tuesday, July 29, 2003 10:52 AM To: 'Nathan Scott' Subject: RE: The infamous BUG in page_buff.c > -----Original Message----- > From: Nathan Scott [ ] > Sent: Tuesday, July 29, 2003 10:19 AM > To: k.karaivanov@minfin.bg > Cc: linux-xfs@oss.sgi.com > Subject: Re: The infamous BUG in page_buff.c > > > On Tue, Jul 29, 2003 at 09:58:42AM +0300, Kostadin Todorov > Karaivanov wrote: > > Short summary: > > I have seen at least 3 reports for , I beleave, same BUG. one of > > witch is mine. It's present since 2.5.6x till now. I know you are > > focused on 2.4 branch but still... > > > > reference: > > > > > > > > > > A reproducible test case would be a big help here. Alas it's not so easy, at least for me. Sometimes it happens while I sit quietly and do nothing on that PC the other time it happens when I recompile kernel. To catch my oops I was forced to make an endless loop of kernel make bzImage; make modules; make clean on the other hand yesterday I try the same, plus some postgresql benchmarks in the background just to higher the load and nothing happened, 2 hours later when I have given up and stop all the tnings and when I was doing REALY nothing the machine dies 8-( . > > thanks. > > -- > Nathan > From owner-linux-xfs@oss.sgi.com Tue Jul 29 14:36:24 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 29 Jul 2003 14:36:39 -0700 (PDT) Received: from hotmail.com (bay2-f112.bay2.hotmail.com [65.54.247.112]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h6TLaOFl014070 for ; Tue, 29 Jul 2003 14:36:24 -0700 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Tue, 29 Jul 2003 14:36:14 -0700 Received: from 155.229.80.7 by by2fd.bay2.hotmail.msn.com with HTTP; Tue, 29 Jul 2003 21:36:14 GMT X-Originating-IP: [155.229.80.7] X-Originating-Email: [boopathi@hotmail.com] From: "Boopathi Veerappan" To: linux-xfs@oss.sgi.com Subject: Re: [Acl-Devel] maximum ACL entries for getfacl Date: Tue, 29 Jul 2003 17:36:14 -0400 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 29 Jul 2003 21:36:14.0724 (UTC) FILETIME=[6FDA1440:01C35619] X-archive-position: 4789 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: boopathi@hotmail.com Precedence: bulk X-list: linux-xfs Content-Length: 1607 Lines: 45 >On Wed, 2002-09-11 at 17:27, Andreas Gruenbacher wrote: > > On Wed, 11 Sep 2002, Leo Qiu wrote: > > > > Hi, > > > > > > I am running libacl on Linux XFS. I found that I could > > > not have more than 16 ACL entries for one file. After > > > a little investigation, it seems to me that I can > > > actually set more than 16 ACL entries on a file, but I > > > can not get them. I am wondering why there is such a > > > limit for ACL. > > > That was an XFS bug, and has been fixed a while ago. Your workaround >is > > correct, though. The XFS guys will likely still recommend you to upgrade > > to a more recent version, because of other fixes. > > > With XFS you will currently get no more than 25 ACL entries; with > > ext2/ext3 the limit is set to 32. This has so far been enough for > > everybody; if you seem to need bigger ACLs, please verify that you can't > > use groups instead. > > > > Regards, >Andreas. > >With the newer treatment of ACLs in XFS, the number can be increased >beyond 25. I have a working setup using a 128 ACE limit. Let me know >if you need that patch. (Although as Andreas says, people really ought >to use groups instead at that point.) > >-- >John M. Trostel >Senior Software Engineer >Quantum Corp. >john.trostel@quantum.com > Hi, Is anybody has the above mentioned patch for 128 ACL entries available? I tried to contact John M. Trostel and the email bounced. Thanks and regards, Boopathi. _________________________________________________________________ The new MSN 8: advanced junk mail protection and 2 months FREE* http://join.msn.com/?page=features/junkmail From owner-linux-xfs@oss.sgi.com Tue Jul 29 14:42:57 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 29 Jul 2003 14:43:00 -0700 (PDT) Received: from ncbdc.bbs.com ([208.0.185.14]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h6TLgrFl014927 for ; Tue, 29 Jul 2003 14:42:56 -0700 Received: by NCBDC with Internet Mail Service (5.5.2653.19) id <32SR8G7F>; Tue, 29 Jul 2003 14:43:36 -0700 Message-ID: <057889C7F1E5D61193620002A537E869C5FF8A@NCBDC> From: Marc Kaplan To: "'Boopathi Veerappan'" , linux-xfs@oss.sgi.com Subject: RE: [Acl-Devel] maximum ACL entries for getfacl Date: Tue, 29 Jul 2003 14:43:35 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" X-archive-position: 4790 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: MKaplan@snapappliance.com Precedence: bulk X-list: linux-xfs Content-Length: 2028 Lines: 65 JT doesn't have that email account anymore, I'll try to get you his new one. -Marc > -----Original Message----- > From: Boopathi Veerappan [mailto:boopathi@hotmail.com] > Sent: Tuesday, July 29, 2003 2:36 PM > To: linux-xfs@oss.sgi.com > Subject: Re: [Acl-Devel] maximum ACL entries for getfacl > > > >On Wed, 2002-09-11 at 17:27, Andreas Gruenbacher wrote: > > > On Wed, 11 Sep 2002, Leo Qiu wrote: > > > > > Hi, > > > > > > > > I am running libacl on Linux XFS. I found that I could > > > > not have more than 16 ACL entries for one file. After > > > > a little investigation, it seems to me that I can > > > > actually set more than 16 ACL entries on a file, but I > > > > can not get them. I am wondering why there is such a > > > > limit for ACL. > > > > That was an XFS bug, and has been fixed a while ago. > Your workaround > >is > > > correct, though. The XFS guys will likely still recommend > you to upgrade > > > to a more recent version, because of other fixes. > > > > With XFS you will currently get no more than 25 ACL > entries; with > > > ext2/ext3 the limit is set to 32. This has so far been enough for > > > everybody; if you seem to need bigger ACLs, please verify > that you can't > > > use groups instead. > > > > > Regards, > >Andreas. > > > >With the newer treatment of ACLs in XFS, the number can be increased > >beyond 25. I have a working setup using a 128 ACE limit. > Let me know > >if you need that patch. (Although as Andreas says, people > really ought > >to use groups instead at that point.) > > > >-- > >John M. Trostel > >Senior Software Engineer > >Quantum Corp. > >john.trostel@quantum.com > > > > Hi, > > Is anybody has the above mentioned patch for 128 ACL entries > available? > I tried to contact John M. Trostel and the email bounced. > > Thanks and regards, > Boopathi. > > _________________________________________________________________ > The new MSN 8: advanced junk mail protection and 2 months FREE* > http://join.msn.com/?page=features/junkmail > > From owner-linux-xfs@oss.sgi.com Tue Jul 29 14:45:45 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 29 Jul 2003 14:45:49 -0700 (PDT) Received: from smtpgw.ciprico.com (hqntws.ciprico.com [208.252.143.8]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h6TLjiFl015506 for ; Tue, 29 Jul 2003 14:45:44 -0700 Received: From smtpgw.ciprico.com ([127.0.0.1]) by smtpgw.ciprico.com (WebShield SMTP v4.5 MR1a); id 1059515137841; Tue, 29 Jul 2003 16:45:37 -0500 Received: from Unknown [172.20.0.8] by smtpgw.ciprico.com - SurfControl E-mail Filter (4.6); Tuesday, 29 July 2003, 16:45:36 Received: by hqntex1.ciprico.com with Internet Mail Service (5.5.2653.19) id ; Tue, 29 Jul 2003 16:45:36 -0500 Message-ID: From: Aman Shahi To: "'linux-xfs@oss.sgi.com'" Date: Tue, 29 Jul 2003 16:45:31 -0500 Subject: Data Corruption Problem MIME-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" X-Mailer: Internet Mail Service (5.5.2653.19) X-archive-position: 4791 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: ashahi@ciprico.com Precedence: bulk X-list: linux-xfs Content-Length: 11178 Lines: 247 Hi, I am using linux 2.4.20 + LVM 1.0.7 + XFS(snapshot-xfs-2.4.20-2003-04-07_05:19_UTC with ACLs, no debug enabled). I created couple of Logical Volumes using LVM, and then created/mounted file system over it. I am running some NFS Client doing I/O over different files in these file systems. I am doing Failover/Failback testing. That is I have one filestem attached to one node and other to the second node. When I fail one of the node, the other node takes over the file system of the second node. When trying to mount the file system of the second node, I am getting File System corruption. Could anybody tell what is the problem here. Attached here is the output from "dmesg". thanks in Advance, Aman. Jul 29 13:17:25 localhost kernel: Linux version 2.4.20 (root@patan_new.nj.ciprico.com) (gcc version 3.2 20020903 (Red Hat Linux 8.0 3.2-7)) #1 SMP Tue Jul 29 11:31:57 EDT 2003 Jul 29 13:17:26 localhost kernel: LVM version 1.0.7(28/03/2003) Jul 29 13:17:26 localhost kernel: NET4: Linux TCP/IP 1.0 for NET4.0 Jul 29 13:17:26 localhost kernel: qla2x00: Found VID=1077 DID=2312 SSVID=1077 SSDID=100 Jul 29 13:17:26 localhost kernel: scsi(0:0:1:1): Enabled tagged queuing, queue depth 16. Jul 29 13:17:26 localhost kernel: Attached scsi disk sda at scsi0, channel 0, id 0, lun 0 Jul 29 13:17:26 localhost kernel: Attached scsi disk sdb at scsi0, channel 0, id 0, lun 1 Jul 29 13:17:26 localhost kernel: Attached scsi disk sdc at scsi0, channel 0, id 1, lun 0 Jul 29 13:17:26 localhost kernel: Attached scsi disk sdd at scsi0, channel 0, id 1, lun 1 Jul 29 13:17:26 localhost kernel: SCSI device sda: 573498800 512-byte hdwr sectors (293631 MB) Jul 29 13:17:26 localhost kernel: sda: sda1 sda2 sda3 Jul 29 13:17:26 localhost kernel: SCSI device sdb: 573498800 512-byte hdwr sectors (293631 MB) Jul 29 13:17:26 localhost kernel: sdb: sdb1 sdb2 sdb3 Jul 29 13:17:26 localhost kernel: SCSI device sdc: 573498800 512-byte hdwr sectors (293631 MB) Jul 29 13:17:26 localhost kernel: sdc: sdc1 sdc2 sdc3 Jul 29 13:17:26 localhost kernel: SCSI device sdd: 573498800 512-byte hdwr sectors (293631 MB) Jul 29 13:17:26 localhost kernel: sdd: sdd1 sdd2 sdd3 Jul 29 13:17:26 localhost kernel: reiserfs: checking transaction log (device 03:03) ... Jul 29 13:17:26 localhost kernel: Warning, log replay starting on readonly filesystem Jul 29 13:17:26 localhost kernel: reiserfs: replayed 63 transactions in 1 seconds Jul 29 13:17:26 localhost kernel: Using r5 hash to sort names Jul 29 13:17:26 localhost kernel: ReiserFS version 3.6.25 Jul 29 13:17:32 localhost modprobe: modprobe: Can't locate module block-major-43 Jul 29 13:17:35 localhost kernel: hydra uses obsolete (PF_INET,SOCK_PACKET) Jul 29 13:17:35 localhost modprobe: modprobe: Can't locate module block-major-43 Jul 29 13:17:35 localhost last message repeated 31 times Jul 29 13:17:35 localhost nfs: Starting NFS services: succeeded Jul 29 13:17:35 localhost nfs: rpc.nfsd startup succeeded Jul 29 13:17:36 localhost nfs: rpc.mountd startup succeeded Jul 29 13:17:52 localhost modprobe: modprobe: Can't locate module block-major-43 Jul 29 13:17:52 localhost last message repeated 31 times Jul 29 13:17:56 localhost kernel: SGI XFS snapshot-xfs-2.4.20-2003-04-07_05:19_UTC with ACLs, no debug enabled Jul 29 13:17:56 localhost kernel: SGI XFS Quota Management subsystem Jul 29 13:17:56 localhost kernel: XFS mounting filesystem lvm(58,1) Jul 29 13:35:25 localhost modprobe: modprobe: Can't locate module block-major-43 Jul 29 13:36:21 localhost last message repeated 192 times Jul 29 13:36:23 localhost last message repeated 127 times Jul 29 13:36:29 localhost kernel: XFS mounting filesystem lvm(58,1) Jul 29 13:36:30 localhost kernel: XFS quotacheck lvm(58,1): Please wait. Jul 29 13:36:32 localhost kernel: XFS quotacheck lvm(58,1): Done. Jul 29 13:43:47 localhost kernel: e1000: eth2 NIC Link is Down Jul 29 13:43:49 localhost kernel: e1000: eth2 NIC Link is Up 100 Mbps Full Duplex Jul 29 13:44:20 localhost kernel: XFS mounting filesystem lvm(58,0) Jul 29 13:44:20 localhost kernel: Filesystem "lvm(58,0)": XFS internal error xlog_clear_stale_blocks(2) at line 1135 of file xfs_log_recover.c. Caller 0xf8b27f8a Jul 29 13:44:20 localhost kernel: eb7e3bf0 f8b13775 f8b137ef 00000008 00000000 00000001 f219b000 f8b5b6e0 Jul 29 13:44:20 localhost kernel: f8b5a95e 0000046f f8b5a8b2 f8b27f8a 00000007 00002400 00001200 f8b286ea Jul 29 13:44:20 localhost kernel: f8b5a95e 00000001 f219b000 f8b5a8b2 0000046f f8b27f8a 00000008 00000007 Jul 29 13:44:20 localhost kernel: Call Trace: Jul 29 13:44:20 localhost kernel: [qla2300:__insmod_qla2300_S.bss_L22432+2805589/92572491] xfs_stack_trace+0x5/0x10 [xfs] Jul 29 13:44:20 localhost kernel: [] xfs_stack_trace+0x5/0x10 [xfs] Jul 29 13:44:20 localhost kernel: [qla2300:__insmod_qla2300_S.bss_L22432+2805711/92572369] xfs_error_report+0x6f/0xb0 [xfs] Jul 29 13:44:20 localhost kernel: [] xfs_error_report+0x6f/0xb0 [xfs] Jul 29 13:44:20 localhost kernel: [qla2300:__insmod_qla2300_S.bss_L22432+3100352/92277728] .rodata.str1.32+0x240/0x2c00 [xfs] Jul 29 13:44:20 localhost kernel: [] .rodata.str1.32+0x240/0x2c00 [xfs] Jul 29 13:44:20 localhost kernel: [qla2300:__insmod_qla2300_S.bss_L22432+3096894/92281186] .rodata.str1.1+0x83a/0x137c [xfs] Jul 29 13:44:20 localhost kernel: [] .rodata.str1.1+0x83a/0x137c [xfs] Jul 29 13:44:20 localhost kernel: [qla2300:__insmod_qla2300_S.bss_L22432+3096722/92281358] .rodata.str1.1+0x78e/0x137c [xfs] Jul 29 13:44:20 localhost kernel: [] .rodata.str1.1+0x78e/0x137c [xfs] Jul 29 13:44:20 localhost kernel: [qla2300:__insmod_qla2300_S.bss_L22432+2889578/92488502] xlog_find_tail+0x27a/0x440 [xfs] Jul 29 13:44:20 localhost kernel: [] xlog_find_tail+0x27a/0x440 [xfs] Jul 29 13:44:20 localhost kernel: [qla2300:__insmod_qla2300_S.bss_L22432+2891466/92486614] xlog_clear_stale_blocks+0x14a/0x1a0 [xfs] Jul 29 13:44:20 localhost kernel: [] xlog_clear_stale_blocks+0x14a/0x1a0 [xfs] Jul 29 13:44:20 localhost kernel: [qla2300:__insmod_qla2300_S.bss_L22432+3096894/92281186] .rodata.str1.1+0x83a/0x137c [xfs] Jul 29 13:44:20 localhost kernel: [] .rodata.str1.1+0x83a/0x137c [xfs] Jul 29 13:44:20 localhost kernel: [qla2300:__insmod_qla2300_S.bss_L22432+3096722/92281358] .rodata.str1.1+0x78e/0x137c [xfs] Jul 29 13:44:20 localhost kernel: [] .rodata.str1.1+0x78e/0x137c [xfs] Jul 29 13:44:20 localhost kernel: [qla2300:__insmod_qla2300_S.bss_L22432+2889578/92488502] xlog_find_tail+0x27a/0x440 [xfs] Jul 29 13:44:20 localhost kernel: [] xlog_find_tail+0x27a/0x440 [xfs] Jul 29 13:44:20 localhost kernel: [qla2300:__insmod_qla2300_S.bss_L22432+2889578/92488502] xlog_find_tail+0x27a/0x440 [xfs] Jul 29 13:44:20 localhost kernel: [] xlog_find_tail+0x27a/0x440 [xfs] Jul 29 13:44:20 localhost kernel: [qla2300:__insmod_qla2300_S.bss_L22432+2906167/92471913] xlog_recover+0x37/0x100 [xfs] Jul 29 13:44:20 localhost kernel: [] xlog_recover+0x37/0x100 [xfs] Jul 29 13:44:20 localhost kernel: [qla2300:__insmod_qla2300_S.bss_L22432+2869341/92508739] xfs_log_mount+0x8d/0xf0 [xfs] Jul 29 13:44:20 localhost kernel: [] xfs_log_mount+0x8d/0xf0 [xfs] Jul 29 13:44:20 localhost kernel: [qla2300:__insmod_qla2300_S.bss_L22432+2912227/92465853] xfs_mountfs+0x503/0xf20 [xfs] Jul 29 13:44:20 localhost kernel: [] xfs_mountfs+0x503/0xf20 [xfs] Jul 29 13:44:20 localhost kernel: [qla2300:__insmod_qla2300_S.bss_L22432+2909972/92468108] xfs_readsb+0x134/0x1f0 [xfs] Jul 29 13:44:20 localhost kernel: [] xfs_readsb+0x134/0x1f0 [xfs] Jul 29 13:44:20 localhost kernel: [qla2300:__insmod_qla2300_S.bss_L22432+2858466/92519614] xfs_ioinit+0x42/0x50 [xfs] Jul 29 13:44:20 localhost kernel: [] xfs_ioinit+0x42/0x50 [xfs] Jul 29 13:44:20 localhost kernel: [qla2300:__insmod_qla2300_S.bss_L22432+2947982/92430098] xfs_mount+0x2ce/0x400 [xfs] Jul 29 13:44:20 localhost kernel: [] xfs_mount+0x2ce/0x400 [xfs] Jul 29 13:44:20 localhost kernel: [qla2300:__insmod_qla2300_S.bss_L22432+3043747/92334333] vfs_mount+0x43/0x50 [xfs] Jul 29 13:44:20 localhost kernel: [] vfs_mount+0x43/0x50 [xfs] Jul 29 13:44:20 localhost kernel: [qla2300:__insmod_qla2300_S.bss_L22432+3075484/92302596] xfs_qm_mount+0x4c/0x70 [xfs] Jul 29 13:44:20 localhost kernel: [] xfs_qm_mount+0x4c/0x70 [xfs] Jul 29 13:44:20 localhost kernel: [qla2300:__insmod_qla2300_S.bss_L22432+3043747/92334333] vfs_mount+0x43/0x50 [xfs] Jul 29 13:44:20 localhost kernel: [] vfs_mount+0x43/0x50 [xfs] Jul 29 13:44:20 localhost kernel: [qla2300:__insmod_qla2300_S.bss_L22432+3042987/92335093] linvfs_read_super+0x9b/0x1c0 [xfs] Jul 29 13:44:20 localhost kernel: [] linvfs_read_super+0x9b/0x1c0 [xfs] Jul 29 13:44:20 localhost kernel: [kmalloc+75/96] kmalloc+0x4b/0x60 [kernel] Jul 29 13:44:20 localhost kernel: [] kmalloc+0x4b/0x60 [kernel] Jul 29 13:44:20 localhost kernel: [alloc_super+58/432] alloc_super+0x3a/0x1b0 [kernel] Jul 29 13:44:20 localhost kernel: [] alloc_super+0x3a/0x1b0 [kernel] Jul 29 13:44:20 localhost kernel: [insert_super+100/128] insert_super+0x64/0x80 [kernel] Jul 29 13:44:20 localhost kernel: [] insert_super+0x64/0x80 [kernel] Jul 29 13:44:20 localhost kernel: [get_sb_bdev+446/752] get_sb_bdev+0x1be/0x2f0 [kernel] Jul 29 13:44:20 localhost kernel: [] get_sb_bdev+0x1be/0x2f0 [kernel] Jul 29 13:44:20 localhost kernel: [qla2300:__insmod_qla2300_S.bss_L22432+3160236/92217844] xfs_fs_type+0x0/0x34 [xfs] Jul 29 13:44:20 localhost kernel: [] xfs_fs_type+0x0/0x34 [xfs] Jul 29 13:44:20 localhost kernel: [do_kern_mount+289/320] do_kern_mount+0x121/0x140 [kernel] Jul 29 13:44:20 localhost kernel: [] do_kern_mount+0x121/0x140 [kernel] Jul 29 13:44:20 localhost kernel: [qla2300:__insmod_qla2300_S.bss_L22432+3160236/92217844] xfs_fs_type+0x0/0x34 [xfs] Jul 29 13:44:20 localhost kernel: [] xfs_fs_type+0x0/0x34 [xfs] Jul 29 13:44:20 localhost kernel: [do_add_mount+147/400] do_add_mount+0x93/0x190 [kernel] Jul 29 13:44:20 localhost kernel: [] do_add_mount+0x93/0x190 [kernel] Jul 29 13:44:20 localhost kernel: [do_mount+352/432] do_mount+0x160/0x1b0 [kernel] Jul 29 13:44:20 localhost kernel: [] do_mount+0x160/0x1b0 [kernel] Jul 29 13:44:20 localhost kernel: [copy_mount_options+121/208] copy_mount_options+0x79/0xd0 [kernel] Jul 29 13:44:20 localhost kernel: [] copy_mount_options+0x79/0xd0 [kernel] Jul 29 13:44:20 localhost kernel: [sys_mount+215/352] sys_mount+0xd7/0x160 [kernel] Jul 29 13:44:20 localhost kernel: [] sys_mount+0xd7/0x160 [kernel] Jul 29 13:44:20 localhost kernel: [system_call+51/56] system_call+0x33/0x38 [kernel] Jul 29 13:44:20 localhost kernel: [] system_call+0x33/0x38 [kernel] Jul 29 13:44:20 localhost kernel: Jul 29 13:44:20 localhost kernel: XFS: failed to locate log tail Jul 29 13:44:20 localhost kernel: XFS: log mount/recovery failed Jul 29 13:44:20 localhost kernel: XFS: log mount failed Jul 29 13:44:31 localhost kernel: XFS mounting filesystem lvm(58,0) From owner-linux-xfs@oss.sgi.com Tue Jul 29 15:06:26 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 29 Jul 2003 15:06:40 -0700 (PDT) Received: from mail.ocs.com.au (mail.ocs.com.au [203.34.97.2]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h6TM6NFl017364 for ; Tue, 29 Jul 2003 15:06:24 -0700 Received: (qmail 6271 invoked from network); 29 Jul 2003 22:06:20 -0000 Received: from ocs3.intra.ocs.com.au (192.168.255.3) by mail.ocs.com.au with SMTP; 29 Jul 2003 22:06:20 -0000 Received: by ocs3.intra.ocs.com.au (Postfix, from userid 16331) id 01625C21FC; Wed, 30 Jul 2003 08:06:19 +1000 (EST) Received: from ocs3.intra.ocs.com.au (localhost [127.0.0.1]) by ocs3.intra.ocs.com.au (Postfix) with ESMTP id F23F4140082; Wed, 30 Jul 2003 08:06:19 +1000 (EST) X-Mailer: exmh version 2.5 01/15/2001 with nmh-1.0.4 From: Keith Owens To: Gordon Henderson Cc: linux-xfs@oss.sgi.com Subject: Re: Booting off XFS, lilo corruption? In-reply-to: Your message of "Tue, 29 Jul 2003 16:41:18 +0100." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 30 Jul 2003 08:06:18 +1000 Message-ID: <11355.1059516378@ocs3.intra.ocs.com.au> X-archive-position: 4792 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: kaos@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 441 Lines: 10 On Tue, 29 Jul 2003 16:41:18 +0100 (BST), Gordon Henderson wrote: >Now to build another kernel with no ext2 in it and see if I can fit it >onto a floppy to use as a rescue disk... Very unlikely, kernels are getting too big to fit on a floppy, so burn a boot CD with your own kernel. http://lbt.linuxcare.com/index.epl is a good starting point, it is designed for credit card sized CDs but works fine with normal CDs. From owner-linux-xfs@oss.sgi.com Tue Jul 29 15:08:50 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 29 Jul 2003 15:08:59 -0700 (PDT) Received: from zok.sgi.com (zok.SGI.COM [204.94.215.101]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h6TM8nFl017917 for ; Tue, 29 Jul 2003 15:08:50 -0700 Received: from flecktone.americas.sgi.com (flecktone.americas.sgi.com [192.48.203.135]) by zok.sgi.com (8.12.9/8.12.9/linux-outbound_gateway-1.1) with ESMTP id h6TM8gq0001425 for ; Tue, 29 Jul 2003 15:08:44 -0700 Received: from daisy-e236.americas.sgi.com (daisy-e236.americas.sgi.com [128.162.236.214]) by flecktone.americas.sgi.com (8.12.9/8.12.9/generic_config-1.2) with ESMTP id h6TM7aQK2905887; Tue, 29 Jul 2003 17:07:36 -0500 (CDT) Received: from [128.162.232.98] (rose.americas.sgi.com [128.162.232.98]) by daisy-e236.americas.sgi.com (8.12.9/SGI-server-1.8) with ESMTP id h6TM7XRn190031078; Tue, 29 Jul 2003 17:07:36 -0500 (CDT) Subject: Re: Data Corruption Problem From: Russell Cattelan To: Aman Shahi Cc: "'linux-xfs@oss.sgi.com'" In-Reply-To: References: Content-Type: text/plain Message-Id: <1059516289.34654.178.camel@rose.americas.sgi.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.3 Date: 29 Jul 2003 17:04:50 -0500 Content-Transfer-Encoding: 7bit X-archive-position: 4793 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: cattelan@xfs.org Precedence: bulk X-list: linux-xfs Content-Length: 11852 Lines: 255 First file a bug. http://oss.sgi.com/bugzilla/ Then try xfs_logprint as a starting point to see what it finds. I might give a clue? On Tue, 2003-07-29 at 16:45, Aman Shahi wrote: > Hi, > I am using linux 2.4.20 + LVM 1.0.7 + > XFS(snapshot-xfs-2.4.20-2003-04-07_05:19_UTC with ACLs, no debug enabled). > > I created couple of Logical Volumes using LVM, and then created/mounted file > system over it. I am running some NFS Client doing I/O over different files > in these file systems. I am doing Failover/Failback testing. That is I have > one filestem attached to one node and other to the second node. When I fail > one of the node, the other node takes over the file system of the second > node. When trying to mount the file system of the second node, I am getting > File System corruption. > > Could anybody tell what is the problem here. Attached here is the output > from "dmesg". > > thanks in Advance, > > Aman. > > > Jul 29 13:17:25 localhost kernel: Linux version 2.4.20 > (root@patan_new.nj.ciprico.com) (gcc version 3.2 20020903 (Red Hat Linux 8.0 > 3.2-7)) #1 SMP Tue Jul 29 11:31:57 EDT 2003 > Jul 29 13:17:26 localhost kernel: LVM version 1.0.7(28/03/2003) > Jul 29 13:17:26 localhost kernel: NET4: Linux TCP/IP 1.0 for NET4.0 > Jul 29 13:17:26 localhost kernel: qla2x00: Found VID=1077 DID=2312 > SSVID=1077 SSDID=100 > Jul 29 13:17:26 localhost kernel: scsi(0:0:1:1): Enabled tagged queuing, > queue depth 16. > Jul 29 13:17:26 localhost kernel: Attached scsi disk sda at scsi0, channel > 0, id 0, lun 0 > Jul 29 13:17:26 localhost kernel: Attached scsi disk sdb at scsi0, channel > 0, id 0, lun 1 > Jul 29 13:17:26 localhost kernel: Attached scsi disk sdc at scsi0, channel > 0, id 1, lun 0 > Jul 29 13:17:26 localhost kernel: Attached scsi disk sdd at scsi0, channel > 0, id 1, lun 1 > Jul 29 13:17:26 localhost kernel: SCSI device sda: 573498800 512-byte hdwr > sectors (293631 MB) > Jul 29 13:17:26 localhost kernel: sda: sda1 sda2 sda3 > Jul 29 13:17:26 localhost kernel: SCSI device sdb: 573498800 512-byte hdwr > sectors (293631 MB) > Jul 29 13:17:26 localhost kernel: sdb: sdb1 sdb2 sdb3 > Jul 29 13:17:26 localhost kernel: SCSI device sdc: 573498800 512-byte hdwr > sectors (293631 MB) > Jul 29 13:17:26 localhost kernel: sdc: sdc1 sdc2 sdc3 > Jul 29 13:17:26 localhost kernel: SCSI device sdd: 573498800 512-byte hdwr > sectors (293631 MB) > Jul 29 13:17:26 localhost kernel: sdd: sdd1 sdd2 sdd3 > Jul 29 13:17:26 localhost kernel: reiserfs: checking transaction log (device > 03:03) ... > Jul 29 13:17:26 localhost kernel: Warning, log replay starting on readonly > filesystem > Jul 29 13:17:26 localhost kernel: reiserfs: replayed 63 transactions in 1 > seconds > Jul 29 13:17:26 localhost kernel: Using r5 hash to sort names > Jul 29 13:17:26 localhost kernel: ReiserFS version 3.6.25 > Jul 29 13:17:32 localhost modprobe: modprobe: Can't locate module > block-major-43 > Jul 29 13:17:35 localhost kernel: hydra uses obsolete (PF_INET,SOCK_PACKET) > Jul 29 13:17:35 localhost modprobe: modprobe: Can't locate module > block-major-43 > Jul 29 13:17:35 localhost last message repeated 31 times > Jul 29 13:17:35 localhost nfs: Starting NFS services: succeeded > Jul 29 13:17:35 localhost nfs: rpc.nfsd startup succeeded > Jul 29 13:17:36 localhost nfs: rpc.mountd startup succeeded > Jul 29 13:17:52 localhost modprobe: modprobe: Can't locate module > block-major-43 > Jul 29 13:17:52 localhost last message repeated 31 times > Jul 29 13:17:56 localhost kernel: SGI XFS > snapshot-xfs-2.4.20-2003-04-07_05:19_UTC with ACLs, no debug enabled > Jul 29 13:17:56 localhost kernel: SGI XFS Quota Management subsystem > Jul 29 13:17:56 localhost kernel: XFS mounting filesystem lvm(58,1) > Jul 29 13:35:25 localhost modprobe: modprobe: Can't locate module > block-major-43 > Jul 29 13:36:21 localhost last message repeated 192 times > Jul 29 13:36:23 localhost last message repeated 127 times > Jul 29 13:36:29 localhost kernel: XFS mounting filesystem lvm(58,1) > Jul 29 13:36:30 localhost kernel: XFS quotacheck lvm(58,1): Please wait. > Jul 29 13:36:32 localhost kernel: XFS quotacheck lvm(58,1): Done. > Jul 29 13:43:47 localhost kernel: e1000: eth2 NIC Link is Down > Jul 29 13:43:49 localhost kernel: e1000: eth2 NIC Link is Up 100 Mbps Full > Duplex > Jul 29 13:44:20 localhost kernel: XFS mounting filesystem lvm(58,0) > Jul 29 13:44:20 localhost kernel: Filesystem "lvm(58,0)": XFS internal error > xlog_clear_stale_blocks(2) at line 1135 of file xfs_log_recover.c. Caller > 0xf8b27f8a > Jul 29 13:44:20 localhost kernel: eb7e3bf0 f8b13775 f8b137ef 00000008 > 00000000 00000001 f219b000 f8b5b6e0 > Jul 29 13:44:20 localhost kernel: f8b5a95e 0000046f f8b5a8b2 f8b27f8a > 00000007 00002400 00001200 f8b286ea > Jul 29 13:44:20 localhost kernel: f8b5a95e 00000001 f219b000 f8b5a8b2 > 0000046f f8b27f8a 00000008 00000007 > Jul 29 13:44:20 localhost kernel: Call Trace: > Jul 29 13:44:20 localhost kernel: > [qla2300:__insmod_qla2300_S.bss_L22432+2805589/92572491] > xfs_stack_trace+0x5/0x10 [xfs] > Jul 29 13:44:20 localhost kernel: [] xfs_stack_trace+0x5/0x10 > [xfs] > Jul 29 13:44:20 localhost kernel: > [qla2300:__insmod_qla2300_S.bss_L22432+2805711/92572369] > xfs_error_report+0x6f/0xb0 [xfs] > Jul 29 13:44:20 localhost kernel: [] xfs_error_report+0x6f/0xb0 > [xfs] > Jul 29 13:44:20 localhost kernel: > [qla2300:__insmod_qla2300_S.bss_L22432+3100352/92277728] > .rodata.str1.32+0x240/0x2c00 [xfs] > Jul 29 13:44:20 localhost kernel: [] .rodata.str1.32+0x240/0x2c00 > [xfs] > Jul 29 13:44:20 localhost kernel: > [qla2300:__insmod_qla2300_S.bss_L22432+3096894/92281186] > .rodata.str1.1+0x83a/0x137c [xfs] > Jul 29 13:44:20 localhost kernel: [] .rodata.str1.1+0x83a/0x137c > [xfs] > Jul 29 13:44:20 localhost kernel: > [qla2300:__insmod_qla2300_S.bss_L22432+3096722/92281358] > .rodata.str1.1+0x78e/0x137c [xfs] > Jul 29 13:44:20 localhost kernel: [] .rodata.str1.1+0x78e/0x137c > [xfs] > Jul 29 13:44:20 localhost kernel: > [qla2300:__insmod_qla2300_S.bss_L22432+2889578/92488502] > xlog_find_tail+0x27a/0x440 [xfs] > Jul 29 13:44:20 localhost kernel: [] xlog_find_tail+0x27a/0x440 > [xfs] > Jul 29 13:44:20 localhost kernel: > [qla2300:__insmod_qla2300_S.bss_L22432+2891466/92486614] > xlog_clear_stale_blocks+0x14a/0x1a0 [xfs] > Jul 29 13:44:20 localhost kernel: [] > xlog_clear_stale_blocks+0x14a/0x1a0 [xfs] > Jul 29 13:44:20 localhost kernel: > [qla2300:__insmod_qla2300_S.bss_L22432+3096894/92281186] > .rodata.str1.1+0x83a/0x137c [xfs] > Jul 29 13:44:20 localhost kernel: [] .rodata.str1.1+0x83a/0x137c > [xfs] > Jul 29 13:44:20 localhost kernel: > [qla2300:__insmod_qla2300_S.bss_L22432+3096722/92281358] > .rodata.str1.1+0x78e/0x137c [xfs] > Jul 29 13:44:20 localhost kernel: [] .rodata.str1.1+0x78e/0x137c > [xfs] > Jul 29 13:44:20 localhost kernel: > [qla2300:__insmod_qla2300_S.bss_L22432+2889578/92488502] > xlog_find_tail+0x27a/0x440 [xfs] > Jul 29 13:44:20 localhost kernel: [] xlog_find_tail+0x27a/0x440 > [xfs] > Jul 29 13:44:20 localhost kernel: > [qla2300:__insmod_qla2300_S.bss_L22432+2889578/92488502] > xlog_find_tail+0x27a/0x440 [xfs] > Jul 29 13:44:20 localhost kernel: [] xlog_find_tail+0x27a/0x440 > [xfs] > Jul 29 13:44:20 localhost kernel: > [qla2300:__insmod_qla2300_S.bss_L22432+2906167/92471913] > xlog_recover+0x37/0x100 [xfs] > Jul 29 13:44:20 localhost kernel: [] xlog_recover+0x37/0x100 > [xfs] > Jul 29 13:44:20 localhost kernel: > [qla2300:__insmod_qla2300_S.bss_L22432+2869341/92508739] > xfs_log_mount+0x8d/0xf0 [xfs] > Jul 29 13:44:20 localhost kernel: [] xfs_log_mount+0x8d/0xf0 > [xfs] > Jul 29 13:44:20 localhost kernel: > [qla2300:__insmod_qla2300_S.bss_L22432+2912227/92465853] > xfs_mountfs+0x503/0xf20 [xfs] > Jul 29 13:44:20 localhost kernel: [] xfs_mountfs+0x503/0xf20 > [xfs] > Jul 29 13:44:20 localhost kernel: > [qla2300:__insmod_qla2300_S.bss_L22432+2909972/92468108] > xfs_readsb+0x134/0x1f0 [xfs] > Jul 29 13:44:20 localhost kernel: [] xfs_readsb+0x134/0x1f0 [xfs] > Jul 29 13:44:20 localhost kernel: > [qla2300:__insmod_qla2300_S.bss_L22432+2858466/92519614] > xfs_ioinit+0x42/0x50 [xfs] > Jul 29 13:44:20 localhost kernel: [] xfs_ioinit+0x42/0x50 [xfs] > Jul 29 13:44:20 localhost kernel: > [qla2300:__insmod_qla2300_S.bss_L22432+2947982/92430098] > xfs_mount+0x2ce/0x400 [xfs] > Jul 29 13:44:20 localhost kernel: [] xfs_mount+0x2ce/0x400 [xfs] > Jul 29 13:44:20 localhost kernel: > [qla2300:__insmod_qla2300_S.bss_L22432+3043747/92334333] vfs_mount+0x43/0x50 > [xfs] > Jul 29 13:44:20 localhost kernel: [] vfs_mount+0x43/0x50 [xfs] > Jul 29 13:44:20 localhost kernel: > [qla2300:__insmod_qla2300_S.bss_L22432+3075484/92302596] > xfs_qm_mount+0x4c/0x70 [xfs] > Jul 29 13:44:20 localhost kernel: [] xfs_qm_mount+0x4c/0x70 [xfs] > Jul 29 13:44:20 localhost kernel: > [qla2300:__insmod_qla2300_S.bss_L22432+3043747/92334333] vfs_mount+0x43/0x50 > [xfs] > Jul 29 13:44:20 localhost kernel: [] vfs_mount+0x43/0x50 [xfs] > Jul 29 13:44:20 localhost kernel: > [qla2300:__insmod_qla2300_S.bss_L22432+3042987/92335093] > linvfs_read_super+0x9b/0x1c0 [xfs] > Jul 29 13:44:20 localhost kernel: [] linvfs_read_super+0x9b/0x1c0 > [xfs] > Jul 29 13:44:20 localhost kernel: [kmalloc+75/96] kmalloc+0x4b/0x60 > [kernel] > Jul 29 13:44:20 localhost kernel: [] kmalloc+0x4b/0x60 [kernel] > Jul 29 13:44:20 localhost kernel: [alloc_super+58/432] > alloc_super+0x3a/0x1b0 [kernel] > Jul 29 13:44:20 localhost kernel: [] alloc_super+0x3a/0x1b0 > [kernel] > Jul 29 13:44:20 localhost kernel: [insert_super+100/128] > insert_super+0x64/0x80 [kernel] > Jul 29 13:44:20 localhost kernel: [] insert_super+0x64/0x80 > [kernel] > Jul 29 13:44:20 localhost kernel: [get_sb_bdev+446/752] > get_sb_bdev+0x1be/0x2f0 [kernel] > Jul 29 13:44:20 localhost kernel: [] get_sb_bdev+0x1be/0x2f0 > [kernel] > Jul 29 13:44:20 localhost kernel: > [qla2300:__insmod_qla2300_S.bss_L22432+3160236/92217844] > xfs_fs_type+0x0/0x34 [xfs] > Jul 29 13:44:20 localhost kernel: [] xfs_fs_type+0x0/0x34 [xfs] > Jul 29 13:44:20 localhost kernel: [do_kern_mount+289/320] > do_kern_mount+0x121/0x140 [kernel] > Jul 29 13:44:20 localhost kernel: [] do_kern_mount+0x121/0x140 > [kernel] > Jul 29 13:44:20 localhost kernel: > [qla2300:__insmod_qla2300_S.bss_L22432+3160236/92217844] > xfs_fs_type+0x0/0x34 [xfs] > Jul 29 13:44:20 localhost kernel: [] xfs_fs_type+0x0/0x34 [xfs] > Jul 29 13:44:20 localhost kernel: [do_add_mount+147/400] > do_add_mount+0x93/0x190 [kernel] > Jul 29 13:44:20 localhost kernel: [] do_add_mount+0x93/0x190 > [kernel] > Jul 29 13:44:20 localhost kernel: [do_mount+352/432] do_mount+0x160/0x1b0 > [kernel] > Jul 29 13:44:20 localhost kernel: [] do_mount+0x160/0x1b0 > [kernel] > Jul 29 13:44:20 localhost kernel: [copy_mount_options+121/208] > copy_mount_options+0x79/0xd0 [kernel] > Jul 29 13:44:20 localhost kernel: [] copy_mount_options+0x79/0xd0 > [kernel] > Jul 29 13:44:20 localhost kernel: [sys_mount+215/352] sys_mount+0xd7/0x160 > [kernel] > Jul 29 13:44:20 localhost kernel: [] sys_mount+0xd7/0x160 > [kernel] > Jul 29 13:44:20 localhost kernel: [system_call+51/56] system_call+0x33/0x38 > [kernel] > Jul 29 13:44:20 localhost kernel: [] system_call+0x33/0x38 > [kernel] > Jul 29 13:44:20 localhost kernel: > Jul 29 13:44:20 localhost kernel: XFS: failed to locate log tail > Jul 29 13:44:20 localhost kernel: XFS: log mount/recovery failed > Jul 29 13:44:20 localhost kernel: XFS: log mount failed > Jul 29 13:44:31 localhost kernel: XFS mounting filesystem lvm(58,0) > From owner-linux-xfs@oss.sgi.com Tue Jul 29 15:24:44 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 29 Jul 2003 15:25:02 -0700 (PDT) Received: from ams002.ftl.affinity.com (lvs00-fl.valueweb.net [216.219.253.199]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h6TMOhFl019354 for ; Tue, 29 Jul 2003 15:24:44 -0700 Received: from david.internal.NorcrossGroup.com ([66.156.0.138]) by ams.ftl.affinity.com with ESMTP id <557638-8369>; Tue, 29 Jul 2003 18:24:23 -0400 Subject: Re: Data Corruption Problem From: Greg Freemyer Reply-To: freemyer-ml@NorcrossGroup.com To: Aman Shahi Cc: "'linux-xfs@oss.sgi.com'" In-Reply-To: References: Content-Type: text/plain Organization: Message-Id: <1059538435.12764.1640.camel@david.internal.NorcrossGroup.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.3 Date: 30 Jul 2003 00:13:55 -0400 Content-Transfer-Encoding: 7bit X-archive-position: 4794 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: freemyer-ml@NorcrossGroup.com Precedence: bulk X-list: linux-xfs Content-Length: 1344 Lines: 39 On Tue, 2003-07-29 at 17:45, Aman Shahi wrote: > Hi, > I am using linux 2.4.20 + LVM 1.0.7 + > XFS(snapshot-xfs-2.4.20-2003-04-07_05:19_UTC with ACLs, no debug enabled). > > I created couple of Logical Volumes using LVM, and then created/mounted file > system over it. I am running some NFS Client doing I/O over different files > in these file systems. I am doing Failover/Failback testing. That is I have > one filestem attached to one node and other to the second node. When I fail > one of the node, the other node takes over the file system of the second > node. When trying to mount the file system of the second node, I am getting > File System corruption. > > Could anybody tell what is the problem here. Attached here is the output > from "dmesg". > > thanks in Advance, > > Aman. Are you saying you have a shared storage solution with 2 LVs that you move back and forth between 2 clustered nodes? If so, I personally would use Linux-HA (heartbeat) in combination with EVMS 2.0. EVMS 2.0 is an alternative to LVM, but it understands clustering and in particular it can use heartbeat for its cluster comm. If you use LVM, I think you have to add a lot of custom scripting to make sure LVM does not screw up due to clustering issues. (i.e. LVM is totally cluster unaware. EVMS is cluster aware.) HTH Greg -- Greg Freemyer From owner-linux-xfs@oss.sgi.com Tue Jul 29 16:22:36 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 29 Jul 2003 16:22:56 -0700 (PDT) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.188]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h6TNMYFl023444 for ; Tue, 29 Jul 2003 16:22:35 -0700 Received: from [212.227.126.161] (helo=mrelayng.kundenserver.de) by moutng.kundenserver.de with esmtp (Exim 3.35 #1) id 19hdnd-00018b-00; Wed, 30 Jul 2003 01:22:33 +0200 Received: from [80.129.53.127] (helo=kernelpanix.aura.of.mankind) by mrelayng.kundenserver.de with asmtp (Exim 3.35 #1) id 19hdnd-0006aK-00; Wed, 30 Jul 2003 01:22:33 +0200 Received: (from utz@localhost) by kernelpanix.aura.of.mankind (8.11.6/8.11.2) id h6TNk8f21698; Wed, 30 Jul 2003 01:46:08 +0200 Date: Wed, 30 Jul 2003 01:46:08 +0200 From: utz lehmann To: Steve Lord Cc: linux-xfs@oss.sgi.com Subject: Re: Cant create new files: No space left on device Message-ID: <20030730014608.A21390@s2y4n2c.de> References: <20030729204941.D30198@de.tecosim.com> <1059505947.6601.1067.camel@jen.americas.sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <1059505947.6601.1067.camel@jen.americas.sgi.com> X-archive-position: 4795 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: xfs@s2y4n2c.de Precedence: bulk X-list: linux-xfs Content-Length: 1423 Lines: 37 Hi Steve Steve Lord [lord@sgi.com] wrote: > > I think you got bitten by stripe alignment. Inode clusters are allocated > on stripe boundaries. You probably have no boundaries left free, so > it cannot allocate any inode space. > > If you go into xfs_db again, and run freesp, then run frag, what does > it say? We probably need to revisit how files are getting allocated > for NFS, I think it is not doing a very good job in this case. What > sort of file size are you talking about here, the numbers say about 175K > but I want to check. Should i run xfs_db with freesp and frag? I had run frag before the no space left situation (about 70% usage i guess), it reports 14% fragmentation. The files are actually copied from our main fileserver. User Homes, installed appications und a lot of CAE data (100+MB) and a few multigigabyte files. So you have everything from 0 bytes to a few GB. > > In this setup fsr will not do anything, and it can sometimes have the > effect of defragmenting files, but fragmenting the remaining free space. I run the fsr when the filesystem wasn't filled up so much. I had done this mostly for stressing. If i remember correctly there was an issue running fsr on nfs exports. btw: i have tried to trash the fs hard. power off while lots of different access patterns. Only one time xfs 1.2 hangs after log replay, 1.3pre2 works everytime. And i got not a single fs corruption. utz From owner-linux-xfs@oss.sgi.com Tue Jul 29 16:23:49 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 29 Jul 2003 16:23:53 -0700 (PDT) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.188]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h6TNNlFl023692 for ; Tue, 29 Jul 2003 16:23:48 -0700 Received: from [212.227.126.160] (helo=mrelayng.kundenserver.de) by moutng.kundenserver.de with esmtp (Exim 3.35 #1) id 19hdop-0001N4-00; Wed, 30 Jul 2003 01:23:47 +0200 Received: from [80.129.53.127] (helo=kernelpanix.aura.of.mankind) by mrelayng.kundenserver.de with asmtp (Exim 3.35 #1) id 19hdop-0005a0-00; Wed, 30 Jul 2003 01:23:47 +0200 Received: (from utz@localhost) by kernelpanix.aura.of.mankind (8.11.6/8.11.2) id h6TNlLV21704; Wed, 30 Jul 2003 01:47:21 +0200 Date: Wed, 30 Jul 2003 01:47:21 +0200 From: utz lehmann To: Steve Lord Cc: linux-xfs@oss.sgi.com Subject: Re: Cant create new files: No space left on device Message-ID: <20030730014721.A21335@s2y4n2c.de> References: <20030729204941.D30198@de.tecosim.com> <1059505947.6601.1067.camel@jen.americas.sgi.com> <1059506664.6604.1070.camel@jen.americas.sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <1059506664.6604.1070.camel@jen.americas.sgi.com> X-archive-position: 4796 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: xfs@s2y4n2c.de Precedence: bulk X-list: linux-xfs Content-Length: 1106 Lines: 34 Hi Steve Steve Lord [lord@sgi.com] wrote: > On Tue, 2003-07-29 at 14:12, Steve Lord wrote: > > > I think you got bitten by stripe alignment. Inode clusters are allocated > > on stripe boundaries. You probably have no boundaries left free, so > > it cannot allocate any inode space. > > > > Actually, you are out of inode room. We actually allocate inodes in > blocks of 64 - which is 4 fs blocks in the default setup. We deal > with them in memory in chunks of 2 fs blocks, but on disk we ask for > 64 at a time. It would be nice if it can fallback to smaller chunks. Ideally down to 1 fs block. Or reduced the report of free inodes (df -i). It is somewhat ugly to get a file system full error when df and df -i reports free space avialable. There are applications (caches) which dont like such situations. But i consider that to be a small bug when it occurred at 98% usage. But a big one at 80% usage. I was bitten by this in the past (solaris ufs). > > So, working out how not to fragment so much in the first place would > be the best solution here. Fragmention of data or free space? utz From owner-linux-xfs@oss.sgi.com Tue Jul 29 18:31:10 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 29 Jul 2003 18:31:24 -0700 (PDT) Received: from web40612.mail.yahoo.com (web40612.mail.yahoo.com [66.218.78.149]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h6U1V8Fl000718 for ; Tue, 29 Jul 2003 18:31:10 -0700 Message-ID: <20030730013103.67757.qmail@web40612.mail.yahoo.com> Received: from [208.35.40.2] by web40612.mail.yahoo.com via HTTP; Tue, 29 Jul 2003 18:31:03 PDT Date: Tue, 29 Jul 2003 18:31:03 -0700 (PDT) From: Ravi Wijayaratne Subject: Performance drop in Linux 2.4.19-XFS 1.2 ? To: linux-xfs@oss.sgi.com MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-archive-position: 4797 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: ravi_wija@yahoo.com Precedence: bulk X-list: linux-xfs Content-Length: 1943 Lines: 55 Hi, We are seeing a %15 performance drop when we move from XFS 1.1 to 1.2. Here are some of our particulars: We have been testing the performance of Linux-2.4.19 and XFS 1.2 with NetBench. We compared the performance with that of Linux-2.4.18 and XFS 1.1. We have been running Samba 3.0. The following are the configuration settings: RAID config 0 or 5: 4 drives with chunk size of 64 xfs_info.sh /hd/vol_mnt0/ meta-data=/hd/vol_mnt0 isize=2048 agcount=74, agsize=1048560 blks data = bsize=4096 blocks=76644352, imaxpct=25 = sunit=16 swidth=16 blks, unwritten=0 naming =version 2 bsize=4096 log =internal bsize=4096 blocks=9360 version=2 = sunit=16 blks realtime =none extsz=65536 blocks=0, rtextents=0 We are running software RAID 0 and 5 (md). The performance numbers were obtained after the RAID sync was completed. For Linux 2.4.18-XFS-1.1 case we used log version 1. For Linux 2.4.19-XFS-1.2 case we used log version 2. At mount time we changed the internal log size from 64k-256k, but that change did not show any difference. We see about a 15-20% drop in performance. To rule out the file system we created an ext2 file system on the same volume and compared the perofrmance. We see that ext2 with Linux 2.4.19 performs much better that Linux 2.4.18. Has the throughput of XFS 1.2 been shown to be less than that of XFS 1.1 with generic benchmarks? Are there any patches since the final release of xfs 1.2 that will improve XFS performance? Are there any XFS 1.2 specific tuning we can do to ramp up the performance? Some insight is much appreciated Ravi ===== ------------------------------ Ravi Wijayaratne __________________________________ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com From owner-linux-xfs@oss.sgi.com Tue Jul 29 18:53:04 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 29 Jul 2003 18:53:08 -0700 (PDT) Received: from zok.sgi.com (zok.SGI.COM [204.94.215.101]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h6U1r3Fl002478 for ; Tue, 29 Jul 2003 18:53:03 -0700 Received: from flecktone.americas.sgi.com (flecktone.americas.sgi.com [192.48.203.135]) by zok.sgi.com (8.12.9/8.12.9/linux-outbound_gateway-1.1) with ESMTP id h6U1qwq0027479 for ; Tue, 29 Jul 2003 18:52:58 -0700 Received: from poppy-e236.americas.sgi.com (poppy-e236.americas.sgi.com [128.162.236.207]) by flecktone.americas.sgi.com (8.12.9/8.12.9/generic_config-1.2) with ESMTP id h6U1pvQK2962431; Tue, 29 Jul 2003 20:51:57 -0500 (CDT) Received: from stout.americas.sgi.com (stout.americas.sgi.com [128.162.232.50]) by poppy-e236.americas.sgi.com (8.12.9/SGI-server-1.8) with ESMTP id h6U1pvYl15876522; Tue, 29 Jul 2003 20:51:57 -0500 (CDT) Date: Tue, 29 Jul 2003 20:51:57 -0500 (CDT) From: Eric Sandeen X-X-Sender: sandeen@stout.americas.sgi.com To: Ravi Wijayaratne cc: linux-xfs@oss.sgi.com Subject: Re: Performance drop in Linux 2.4.19-XFS 1.2 ? In-Reply-To: <20030730013103.67757.qmail@web40612.mail.yahoo.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 4798 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: sandeen@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 2293 Lines: 67 Ravi - XFS 1.2 is old, XFS 1.1 is ancient. To start with, you might try running your tests on the XFS 1.3 prereleases, at least then we have some recent code to think about. :) -Eric On Tue, 29 Jul 2003, Ravi Wijayaratne wrote: > Hi, > > We are seeing a %15 performance drop when we move from XFS 1.1 to 1.2. > Here are some of our particulars: > We have been testing the performance of Linux-2.4.19 and XFS 1.2 with NetBench. > We compared the performance with that of Linux-2.4.18 and XFS 1.1. > We have been running Samba 3.0. > > > The following are the configuration settings: > > RAID config -1 or 5: 4 drives with chunk size of 64 > > xfs_info.sh /hd/vol_mnt0/ > meta-data=/hd/vol_mnt0 isize=2048 agcount=74, agsize=1048560 blks > data = bsize=4096 blocks=76644352, imaxpct=25 > = sunit=16 swidth=16 blks, unwritten=0 > naming =version 2 bsize=4096 > log =internal bsize=4096 blocks=9360 version=2 > = sunit=16 blks > realtime =none extsz=65536 blocks=0, rtextents=0 > > We are running software RAID 0 and 5 (md). The performance numbers were obtained after the > RAID sync was completed. > > For Linux 2.4.18-XFS-1.1 case we used log version 1. > For Linux 2.4.19-XFS-1.2 case we used log version 2. > > At mount time we changed the internal log size from 64k-256k, but that change did > not show any difference. > > We see about a 15-20% drop in performance. To rule out the file system we created > an ext2 file system on the same volume and compared the perofrmance. We see that > ext2 with Linux 2.4.19 performs much better that Linux 2.4.18. > > Has the throughput of XFS 1.2 been shown to be less than that of XFS 1.1 with > generic benchmarks? > > Are there any patches since the final release of xfs 1.2 that will improve XFS performance? > Are there any XFS 1.2 specific tuning we can do to ramp up the performance? > > Some insight is much appreciated > > Ravi > > > ===== > ------------------------------ > Ravi Wijayaratne > > __________________________________ > Do you Yahoo!? > Yahoo! SiteBuilder - Free, easy-to-use web site design software > http://sitebuilder.yahoo.com > > From owner-linux-xfs@oss.sgi.com Tue Jul 29 18:54:13 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 29 Jul 2003 18:54:18 -0700 (PDT) Received: from lists.vasoftware.com (mail@lists.vasoftware.com [198.186.202.171]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h6U1sDFl002861 for ; Tue, 29 Jul 2003 18:54:13 -0700 Received: from adsl-67-123-174-175.dsl.sntc01.pacbell.net ([67.123.174.175]:61494 helo=linux-sxs.org) by lists.vasoftware.com with asmtp (Cipher TLSv1:RC4-MD5:128) (Exim 4.20 #1 (Debian)) id 19hgAN-0006ge-SE by authid with fixed_plain; Tue, 29 Jul 2003 18:54:12 -0700 Message-ID: <3F272537.2090908@linux-sxs.org> Date: Tue, 29 Jul 2003 18:53:59 -0700 From: "Net Llama!" Organization: HAL III User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030625 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Ravi Wijayaratne CC: linux-xfs@oss.sgi.com Subject: Re: Performance drop in Linux 2.4.19-XFS 1.2 ? References: <20030730013103.67757.qmail@web40612.mail.yahoo.com> In-Reply-To: <20030730013103.67757.qmail@web40612.mail.yahoo.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-EA-Verified: lists.vasoftware.com 19hgAN-0006ge-SE 519122f8e17fda412998b45c0cca4c16 X-Spam-Score: -2.6 X-archive-position: 4799 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: netllama@linux-sxs.org Precedence: bulk X-list: linux-xfs Content-Length: 2274 Lines: 56 On 07/29/03 18:31, Ravi Wijayaratne wrote: > Hi, > > We are seeing a %15 performance drop when we move from XFS 1.1 to 1.2. > Here are some of our particulars: > We have been testing the performance of Linux-2.4.19 and XFS 1.2 with NetBench. > We compared the performance with that of Linux-2.4.18 and XFS 1.1. > We have been running Samba 3.0. > > > The following are the configuration settings: > > RAID config 0 or 5: 4 drives with chunk size of 64 > > xfs_info.sh /hd/vol_mnt0/ > meta-data=/hd/vol_mnt0 isize=2048 agcount=74, agsize=1048560 blks > data = bsize=4096 blocks=76644352, imaxpct=25 > = sunit=16 swidth=16 blks, unwritten=0 > naming =version 2 bsize=4096 > log =internal bsize=4096 blocks=9360 version=2 > = sunit=16 blks > realtime =none extsz=65536 blocks=0, rtextents=0 > > We are running software RAID 0 and 5 (md). The performance numbers were obtained after the > RAID sync was completed. > > For Linux 2.4.18-XFS-1.1 case we used log version 1. > For Linux 2.4.19-XFS-1.2 case we used log version 2. > > At mount time we changed the internal log size from 64k-256k, but that change did > not show any difference. > > We see about a 15-20% drop in performance. To rule out the file system we created > an ext2 file system on the same volume and compared the perofrmance. We see that > ext2 with Linux 2.4.19 performs much better that Linux 2.4.18. > > Has the throughput of XFS 1.2 been shown to be less than that of XFS 1.1 with > generic benchmarks? > > Are there any patches since the final release of xfs 1.2 that will improve XFS performance? > Are there any XFS 1.2 specific tuning we can do to ramp up the performance? > > Some insight is much appreciated My understanding is that the XFS code that matters is in the kernel. Thus, moving to a latter kernel version might improve things. -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ L. Friedman netllama@linux-sxs.org Linux Step-by-step & TyGeMo: http://netllama.ipfox.com 6:50pm up 14 days, 21:33, 2 users, load average: 0.08, 0.02, 0.01 From owner-linux-xfs@oss.sgi.com Tue Jul 29 18:59:58 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 29 Jul 2003 19:00:04 -0700 (PDT) Received: from rj.sgi.com (rj.SGI.COM [192.82.208.96]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h6U1xwFl003717 for ; Tue, 29 Jul 2003 18:59:58 -0700 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by rj.sgi.com (8.12.9/8.12.9/linux-outbound_gateway-1.1) with SMTP id h6U00OMM005897 for ; Tue, 29 Jul 2003 17:00:25 -0700 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 LAA14504; Wed, 30 Jul 2003 11:59:50 +1000 Received: from frodo.melbourne.sgi.com (root@frodo.melbourne.sgi.com [134.14.55.153]) by wobbly.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id h6U1xn3K216745; Wed, 30 Jul 2003 11:59:49 +1000 (EST) Received: from frodo.melbourne.sgi.com (nathans@localhost [127.0.0.1]) by frodo.melbourne.sgi.com (8.12.9/8.12.9/Debian-3) with ESMTP id h6U1wsbe001544; Wed, 30 Jul 2003 11:58:54 +1000 Received: (from nathans@localhost) by frodo.melbourne.sgi.com (8.12.9/8.12.9/Debian-3) id h6U1ws8O001542; Wed, 30 Jul 2003 11:58:54 +1000 Date: Wed, 30 Jul 2003 11:58:54 +1000 From: Nathan Scott To: Ravi Wijayaratne Cc: linux-xfs@oss.sgi.com Subject: Re: Performance drop in Linux 2.4.19-XFS 1.2 ? Message-ID: <20030730015854.GB770@frodo> References: <20030730013103.67757.qmail@web40612.mail.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030730013103.67757.qmail@web40612.mail.yahoo.com> User-Agent: Mutt/1.5.3i X-archive-position: 4800 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: nathans@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 1724 Lines: 46 On Tue, Jul 29, 2003 at 06:31:03PM -0700, Ravi Wijayaratne wrote: > Hi, > > We are seeing a %15 performance drop when we move from XFS 1.1 to 1.2. > Here are some of our particulars: > We have been testing the performance of Linux-2.4.19 and XFS 1.2 with NetBench. > We compared the performance with that of Linux-2.4.18 and XFS 1.1. > We have been running Samba 3.0. > > > The following are the configuration settings: > > RAID config 0 or 5: 4 drives with chunk size of 64 > > xfs_info.sh /hd/vol_mnt0/ > meta-data=/hd/vol_mnt0 isize=2048 agcount=74, agsize=1048560 blks > data = bsize=4096 blocks=76644352, imaxpct=25 > = sunit=16 swidth=16 blks, unwritten=0 > naming =version 2 bsize=4096 > log =internal bsize=4096 blocks=9360 version=2 > = sunit=16 blks > realtime =none extsz=65536 blocks=0, rtextents=0 > > We are running software RAID 0 and 5 (md). The performance numbers were obtained after the > RAID sync was completed. > > For Linux 2.4.18-XFS-1.1 case we used log version 1. > For Linux 2.4.19-XFS-1.2 case we used log version 2. > > At mount time we changed the internal log size from 64k-256k, but that change did > not show any difference. > Try changing one thing at a time to try figure out what actually causes the performance changes. ie. is it the change from 2.4.18 to 2.4.19, or 1.1 to 1.2 XFS code, or is it the use of v1 vs. v2 logs, or is it the use of larger iclogs, or the use of a large log sunit, or... just too many variables here. Posting the results of the benchmarks would be of use too. thanks. -- Nathan From owner-linux-xfs@oss.sgi.com Tue Jul 29 19:21:53 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 29 Jul 2003 19:22:12 -0700 (PDT) Received: from web40602.mail.yahoo.com (web40602.mail.yahoo.com [66.218.78.139]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h6U2LrFl005599 for ; Tue, 29 Jul 2003 19:21:53 -0700 Message-ID: <20030730022148.32410.qmail@web40602.mail.yahoo.com> Received: from [208.35.40.2] by web40602.mail.yahoo.com via HTTP; Tue, 29 Jul 2003 19:21:48 PDT Date: Tue, 29 Jul 2003 19:21:48 -0700 (PDT) From: Ravi Wijayaratne Subject: Re: Performance drop in Linux 2.4.19-XFS 1.2 ? To: Nathan Scott Cc: linux-xfs@oss.sgi.com In-Reply-To: <20030730015854.GB770@frodo> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-archive-position: 4801 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: ravi_wija@yahoo.com Precedence: bulk X-list: linux-xfs Content-Length: 2669 Lines: 83 Hi Nathan Thank you for responding. Log version: ------------- We changing from v1 to v2 with the same parameters did not change the throughput. Size of the Log: ---------------- I changed the size of the log from 64k to 256k for version 2 and did not see a difference in performance. I beleive version 1 logs support only 32k max internal logs. Is that correct ? sunit values for logs/data: --------------------------- I have not tried to tune these values yet. We set it to 64k because our RAID chunk size was 64k. I will change the values and see whethet performance changes significatly Thanks Ravi --- Nathan Scott wrote: > On Tue, Jul 29, 2003 at 06:31:03PM -0700, Ravi Wijayaratne wrote: > > Hi, > > > > We are seeing a %15 performance drop when we move from XFS 1.1 to 1.2. > > Here are some of our particulars: > > We have been testing the performance of Linux-2.4.19 and XFS 1.2 with NetBench. > > We compared the performance with that of Linux-2.4.18 and XFS 1.1. > > We have been running Samba 3.0. > > > > > > The following are the configuration settings: > > > > RAID config 0 or 5: 4 drives with chunk size of 64 > > > > xfs_info.sh /hd/vol_mnt0/ > > meta-data=/hd/vol_mnt0 isize=2048 agcount=74, agsize=1048560 blks > > data = bsize=4096 blocks=76644352, imaxpct=25 > > = sunit=16 swidth=16 blks, unwritten=0 > > naming =version 2 bsize=4096 > > log =internal bsize=4096 blocks=9360 version=2 > > = sunit=16 blks > > realtime =none extsz=65536 blocks=0, rtextents=0 > > > > We are running software RAID 0 and 5 (md). The performance numbers were obtained after the > > RAID sync was completed. > > > > For Linux 2.4.18-XFS-1.1 case we used log version 1. > > For Linux 2.4.19-XFS-1.2 case we used log version 2. > > > > At mount time we changed the internal log size from 64k-256k, but that change did > > not show any difference. > > > > Try changing one thing at a time to try figure out what actually > causes the performance changes. ie. is it the change from 2.4.18 > to 2.4.19, or 1.1 to 1.2 XFS code, or is it the use of v1 vs. v2 > logs, or is it the use of larger iclogs, or the use of a large log > sunit, or... just too many variables here. > > Posting the results of the benchmarks would be of use too. > > thanks. > > -- > Nathan ===== ------------------------------ Ravi Wijayaratne __________________________________ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com From owner-linux-xfs@oss.sgi.com Tue Jul 29 21:29:01 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 29 Jul 2003 21:29:16 -0700 (PDT) Received: from corpmail.outblaze.com ([210.177.227.131]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h6U4SxFl014231 for ; Tue, 29 Jul 2003 21:29:00 -0700 Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by corpmail.outblaze.com (Postfix) with ESMTP id 8FBB337B1A for ; Wed, 30 Jul 2003 04:28:57 +0000 (GMT) Received: from yusufg.portal2.com (unknown [210.177.227.130]) by corpmail.outblaze.com (Postfix) with SMTP id 5D6B216DD87 for ; Wed, 30 Jul 2003 04:28:57 +0000 (GMT) Received: (qmail 12212 invoked by uid 500); 30 Jul 2003 04:25:24 -0000 Date: 30 Jul 2003 04:25:24 -0000 Message-ID: <20030730042524.12211.qmail@yusufg.portal2.com> From: Yusuf Goolamabbas To: linux-xfs@oss.sgi.com Subject: Does XFS do the right thing for MTA queues X-AntiVirus: checked by Vexira MailArmor (version: 2.0.1.11; VAE: 6.20.0.1; VDF: 6.20.0.50; host: corpmail.outblaze.com) X-archive-position: 4802 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: yusufg@outblaze.com Precedence: bulk X-list: linux-xfs Content-Length: 697 Lines: 19 In general, MTA's like (qmail/postfix) and their authors assume the BSD ffs/softupdates semantics that fsync on a file also syncs the directory metadata (I think they want link/rename to be synchronous). This semantic is also provided by ext3 in 2 of its modes (ordered,data=journal). My question is a) Does XFS provide similar semantics which would make it reliable as a filesystem for MTA queue ? b) Are there any mount options which one has to enable this behaviour ? Also, what's the version of XFS in the Alan Cox 2.4.22-pre6-ac1 kernel Thanks, Yusuf -- If you're not using Firebird, you're not surfing the web you're suffering it http://www.mozilla.org/products/firebird/why/ From owner-linux-xfs@oss.sgi.com Wed Jul 30 00:16:41 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 30 Jul 2003 00:17:05 -0700 (PDT) Received: from hermes.acsalaska.net (hermes.slb.nwc.acsalaska.net [209.112.155.38]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h6U7GaFl023567 for ; Wed, 30 Jul 2003 00:16:41 -0700 Received: from erbenson.alaska.net (134-pm11.nwc.alaska.net [209.112.140.134]) by hermes.acsalaska.net (8.12.9/8.12.9) with ESMTP id h6U7GXfQ061460 for ; Tue, 29 Jul 2003 23:16:33 -0800 (AKDT) (envelope-from erbenson@alaska.net) Received: from plato.local.lan (plato.local.lan [192.168.0.4]) by erbenson.alaska.net (Postfix) with ESMTP id 571203A04 for ; Tue, 29 Jul 2003 23:16:32 -0800 (AKDT) Received: by plato.local.lan (Postfix, from userid 1000) id E851C40FF44; Tue, 29 Jul 2003 23:16:31 -0800 (AKDT) Date: Tue, 29 Jul 2003 23:16:31 -0800 From: Ethan Benson To: linux-xfs@oss.sgi.com Subject: Re: [PATCH] Implement immutable/append-only flags in XFS #3 Message-ID: <20030730071631.GJ6786@plato.local.lan> Mail-Followup-To: linux-xfs@oss.sgi.com References: <20030722003443.GA13188@plato.local.lan> <20030729154740.GD7435@wotan.suse.de> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="kr14OxHsRwZHHqxS" Content-Disposition: inline In-Reply-To: <20030729154740.GD7435@wotan.suse.de> User-Agent: Mutt/1.3.28i X-OS: Debian GNU X-gpg-fingerprint: E3E4 D0BC 31BC F7BB C1DD C3D6 24AC 7B1A 2C44 7AFC X-gpg-key: http://www.alaska.net/~erbenson/gpg/key.asc Mail-Copies-To: nobody X-No-CC: I subscribe to this list; do not CC me on replies. X-ACS-Spam-Status: no X-Scanned-By: MIMEDefang 2.34 X-archive-position: 4803 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: erbenson@alaska.net Precedence: bulk X-list: linux-xfs Content-Length: 3460 Lines: 87 --kr14OxHsRwZHHqxS Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Jul 29, 2003 at 05:47:40PM +0200, Andi Kleen wrote: > On Mon, Jul 21, 2003 at 04:34:43PM -0800, Ethan Benson wrote: > > My question on #3 is whether we want this behavior in XFS? my current > > patch does NOT implement it. My opinion is that the only flag this > > really makes sense for is sync, since setting the sync flag on a >=20 > inherited sync is very useful. iirc it was introduced because some > mail servers assume everything is a BSD with UFS and rename is always > synchronous, otherwise they have potential crash recovery issues.=20=20 > You just set sync on the spool and everything ends up safely synchronous. yes. sync on a directory otherwise doesn't do anything AFAICT. note that 2.6 introduces a new flag specifically for making a directory syncronous, i don't know the details of how it works, or what it does, or what XFS would need to do to support it. i am not sure exactly where to put code to inherit any of these flags howev= er... > AFAIK the XFS transaction manager does not guarantee the the transaction > is committed before the rename returns, so it would be needed even on XFS. >=20 > However XFS seems to be default to osyncisdsync, and for the mail server = use > case you need O_SYNC, not O_DSYNC. > Maybe it would be useful to define a new bit for both cases? ill let the XFS guys comment on this. > > of this. I am definitely not convinced its a sensible idea for > > append-only since it ends up allowing non-privileged users to create > > append-only files, which is not normally permitted. Also > > automatically setting the append-only flag on a newly created file >=20 > Agreed. I assume ext2/reiser do also not inherit it, right? ext2 inherits ALL the bits. they just copy the entire flag field to the new inode, unless its a symlink. if you create a device node in an append-only directory you will need to use debugfs to get rid of it. (i pointed this out on linux-kernel, but nobody cares). this is even more foolish since some ext2 flags are used to report error conditions with the compression patches. this wasn't immediatly noticable prior to 2.4.21 since ext2 failed to notify the VFS about the flags (except sync), so you wouldn't see things like append-only enforced until the filesystem was remounted, or the inode re-read from disk. > > I have a (somewhat hideous) test program to check as many things as i > > could think of to ensure immutable/append-only are properly enforced, > > the only thing lacking in it is tests of all the XFS ioctls, perhaps > > someone familiar with xfs ioctls could add these, currently the > > libhandle open/write tests are done. You can find this test program > > at http://penguinppc.org/~eb/t_immutable.c >=20 > I would suggest to submit that program to LTP. I'm sure they would=20 > appreciate more test cases and it would help making all the linux > file systems behave similar in this area. sure. --=20 Ethan Benson http://www.alaska.net/~erbenson/ --kr14OxHsRwZHHqxS Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iEYEARECAAYFAj8ncM8ACgkQJKx7GixEevwCCACgnB1s9B+224z7pohzs/CKzZGc /4AAnjyEk7gapae6NScjIecO3dK67OBX =1nza -----END PGP SIGNATURE----- --kr14OxHsRwZHHqxS-- From owner-linux-xfs@oss.sgi.com Wed Jul 30 02:10:08 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 30 Jul 2003 02:10:25 -0700 (PDT) Received: from smtpzilla5.xs4all.nl (smtpzilla5.xs4all.nl [194.109.127.141]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h6U9A7Fl031311 for ; Wed, 30 Jul 2003 02:10:08 -0700 Received: from auto-nb1.xs4all.nl (a80-126-90-136.adsl.xs4all.nl [80.126.90.136]) by smtpzilla5.xs4all.nl (8.12.9/8.12.9) with ESMTP id h6U9A5mi098802; Wed, 30 Jul 2003 11:10:05 +0200 (CEST) Message-Id: <4.3.2.7.2.20030730110055.041a1bc0@pop.xs4all.nl> X-Sender: knuffie@pop.xs4all.nl X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 30 Jul 2003 11:09:52 +0200 To: Ravi Wijayaratne , linux-xfs@oss.sgi.com From: Seth Mos Subject: Re: Performance drop in Linux 2.4.19-XFS 1.2 ? In-Reply-To: <20030730013103.67757.qmail@web40612.mail.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-archive-position: 4804 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: knuffie@xs4all.nl Precedence: bulk X-list: linux-xfs Content-Length: 1132 Lines: 33 At 18:31 29-7-2003 -0700, Ravi Wijayaratne wrote: >Hi, > >We are seeing a %15 performance drop when we move from XFS 1.1 to 1.2. >Here are some of our particulars: >We have been testing the performance of Linux-2.4.19 and XFS 1.2 with >NetBench. >We compared the performance with that of Linux-2.4.18 and XFS 1.1. >We have been running Samba 3.0. The only problem I know of which is not exclusive to XFS (ext3 does this as well) is one on the read performance of 2.4.18 vs the 2.4.20 errata kernel. On 2.4.18-27 I get 170MB/sec read speed on 2.4.20-18 I get 80MB/sec read speed. the write speed stays consistent between these releases but the enormous drop in read speed is very strange. It appears to be present in the standard rh errata as well. The hardware I am seeing this on is a Dual Xeon 3.06 with 2GB ram and a 200GB raid 10 container using 6 73GB 15K rpm disks on a Perc4/Di (lsil U320-2X). The other box I replicated this on is a Single P3 733 with 768MB ram and a 350GB raid 10 container using 6 120GB 7k2 rpm ide disks on a 3ware 7500-8. Cheers -- Seth It might just be your lucky day, if you only knew. From owner-linux-xfs@oss.sgi.com Wed Jul 30 04:34:19 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 30 Jul 2003 04:34:42 -0700 (PDT) Received: from zok.sgi.com (zok.SGI.COM [204.94.215.101]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h6UBYIFl012279 for ; Wed, 30 Jul 2003 04:34:19 -0700 Received: from flecktone.americas.sgi.com (flecktone.americas.sgi.com [192.48.203.135]) by zok.sgi.com (8.12.9/8.12.9/linux-outbound_gateway-1.1) with ESMTP id h6UBYDq0020782 for ; Wed, 30 Jul 2003 04:34:13 -0700 Received: from daisy-e236.americas.sgi.com (daisy-e236.americas.sgi.com [128.162.236.214]) by flecktone.americas.sgi.com (8.12.9/8.12.9/generic_config-1.2) with ESMTP id h6UBXCQK3119192; Wed, 30 Jul 2003 06:33:13 -0500 (CDT) Received: from [192.168.1.100] (cf-vpn-sw-corp-64-28.corp.sgi.com [134.15.64.28]) by daisy-e236.americas.sgi.com (8.12.9/SGI-server-1.8) with ESMTP id h6UBX5Rn200059817; Wed, 30 Jul 2003 06:33:10 -0500 (CDT) Subject: Re: Does XFS do the right thing for MTA queues From: Steve Lord To: Yusuf Goolamabbas Cc: linux-xfs@oss.sgi.com In-Reply-To: <20030730042524.12211.qmail@yusufg.portal2.com> References: <20030730042524.12211.qmail@yusufg.portal2.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.8 (1.0.8-11) Date: 30 Jul 2003 06:33:17 -0500 Message-Id: <1059564802.1823.8.camel@laptop.americas.sgi.com> Mime-Version: 1.0 X-archive-position: 4805 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: lord@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 1110 Lines: 31 On Tue, 2003-07-29 at 23:25, Yusuf Goolamabbas wrote: > In general, MTA's like (qmail/postfix) and their authors assume the > BSD ffs/softupdates semantics that fsync on a file also syncs the > directory metadata (I think they want link/rename to be > synchronous). This semantic is also provided by ext3 in 2 of its modes > (ordered,data=journal). My question is > > a) Does XFS provide similar semantics which would make it reliable as > a filesystem for MTA queue ? If you do fsync on a file then the log will get pushed to disk - at least upto the last transaction involving the inode you do fsync on. This means that any transaction prior to that (such as a rename or a link call) is also flushed to disk. So fsync does the right thing. > b) Are there any mount options which one has to enable this behaviour > ? Nope. If you are really paranoid, the wsync mount option makes almost all transactions synchronous. > > Also, what's the version of XFS in the Alan Cox 2.4.22-pre6-ac1 kernel > It is somewhat long in the tooth now, and probably has some issues with the O_DIRECT path. Steve From owner-linux-xfs@oss.sgi.com Wed Jul 30 06:09:49 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 30 Jul 2003 06:10:04 -0700 (PDT) Received: from smtpgw.ciprico.com (hqntws.ciprico.com [208.252.143.8]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h6UD9mFl019339 for ; Wed, 30 Jul 2003 06:09:49 -0700 Received: From smtpgw.ciprico.com ([127.0.0.1]) by smtpgw.ciprico.com (WebShield SMTP v4.5 MR1a); id 1059570582591; Wed, 30 Jul 2003 08:09:42 -0500 Received: from Unknown [172.20.0.8] by smtpgw.ciprico.com - SurfControl E-mail Filter (4.6); Wednesday, 30 July 2003, 08:09:41 Received: by hqntex1.ciprico.com with Internet Mail Service (5.5.2653.19) id ; Wed, 30 Jul 2003 08:09:41 -0500 Message-ID: From: Aman Shahi To: "'freemyer-ml@NorcrossGroup.com'" Cc: "'linux-xfs@oss.sgi.com'" Date: Wed, 30 Jul 2003 08:09:39 -0500 Subject: RE: Data Corruption Problem MIME-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" X-Mailer: Internet Mail Service (5.5.2653.19) X-archive-position: 4806 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: ashahi@ciprico.com Precedence: bulk X-list: linux-xfs Content-Length: 1735 Lines: 62 Hi Greg, I have a shared storage solution as you mentioned, and am using our own HA software. We do take care of the fact that the current LVM is not cluster aware. regards, Aman. -----Original Message----- From: Greg Freemyer [mailto:freemyer-ml@NorcrossGroup.com] Sent: Wednesday, July 30, 2003 12:14 AM To: Aman Shahi Cc: 'linux-xfs@oss.sgi.com' Subject: Re: Data Corruption Problem Are you saying you have a shared storage solution with 2 LVs that you move back and forth between 2 clustered nodes? If so, I personally would use Linux-HA (heartbeat) in combination with EVMS 2.0. EVMS 2.0 is an alternative to LVM, but it understands clustering and in particular it can use heartbeat for its cluster comm. If you use LVM, I think you have to add a lot of custom scripting to make sure LVM does not screw up due to clustering issues. (i.e. LVM is totally cluster unaware. EVMS is cluster aware.) HTH Greg -- Greg Freemyer On Tue, 2003-07-29 at 17:45, Aman Shahi wrote: > Hi, > I am using linux 2.4.20 + LVM 1.0.7 + > XFS(snapshot-xfs-2.4.20-2003-04-07_05:19_UTC with ACLs, no debug enabled). > > I created couple of Logical Volumes using LVM, and then created/mounted file > system over it. I am running some NFS Client doing I/O over different files > in these file systems. I am doing Failover/Failback testing. That is I have > one filestem attached to one node and other to the second node. When I fail > one of the node, the other node takes over the file system of the second > node. When trying to mount the file system of the second node, I am getting > File System corruption. > > Could anybody tell what is the problem here. Attached here is the output > from "dmesg". > > thanks in Advance, > > Aman. From owner-linux-xfs@oss.sgi.com Wed Jul 30 06:43:42 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 30 Jul 2003 06:43:47 -0700 (PDT) Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.9/8.12.9) with ESMTP id h6UDhgFl022144 for ; Wed, 30 Jul 2003 06:43:42 -0700 Received: (from xfs@localhost) by oss.sgi.com (8.12.9/8.12.8/Submit) id h6UDhgmd022143 for linux-xfs@oss.sgi.com; Wed, 30 Jul 2003 06:43:42 -0700 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.9/8.12.9) with ESMTP id h6UDhfFp022125 for ; Wed, 30 Jul 2003 06:43:41 -0700 Received: (from apache@localhost) by oss.sgi.com (8.12.9/8.12.8/Submit) id h6UDP0Jt020865; Wed, 30 Jul 2003 06:25:00 -0700 Date: Wed, 30 Jul 2003 06:25:00 -0700 Message-Id: <200307301325.h6UDP0Jt020865@oss.sgi.com> From: bugzilla-daemon@oss.sgi.com To: xfs-master@oss.sgi.com Subject: [Bug 269] New: XFS Data Corruption on Power Failure(on unclean unmount) X-Bugzilla-Reason: AssignedTo X-archive-position: 4807 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: bugzilla-daemon@oss.sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 12003 Lines: 243 http://oss.sgi.com/bugzilla/show_bug.cgi?id=269 Summary: XFS Data Corruption on Power Failure(on unclean unmount) Product: Linux XFS Version: Current Platform: IA32 OS/Version: Linux Status: NEW Severity: normal Priority: High Component: XFS kernel code AssignedTo: xfs-master@oss.sgi.com ReportedBy: ashahi@ciprico.com CC: cattelan@xfs.org I am using linux 2.4.20 + LVM 1.0.7 + XFS(snapshot-xfs-2.4.20-2003-04- 07_05:19_UTC with ACLs, no debug enabled). I created couple of Logical Volumes using LVM, and then created/mounted XFS file system over it. I am running some NFS Client doing I/O over different files in these file systems. I am doing Failover/Failback testing. That is I have one filestem attached to one node and other to the second node. When I fail one of the node, the other node takes over the file system of the second node. That is it tried to mount a file system which was previously not cleanly unmounted. When trying to mount the file system of the second node, I am getting File System Data corruption. I am using our own HA software which takes care of the fact that LVM is not cluster aware. Attached here is the output from "dmesg". Jul 29 13:17:25 localhost kernel: Linux version 2.4.20 (root@patan_new.nj.ciprico.com) (gcc version 3.2 20020903 (Red Hat Linux 8.0 3.2-7)) #1 SMP Tue Jul 29 11:31:57 EDT 2003 Jul 29 13:17:26 localhost kernel: LVM version 1.0.7(28/03/2003) Jul 29 13:17:26 localhost kernel: NET4: Linux TCP/IP 1.0 for NET4.0 Jul 29 13:17:26 localhost kernel: qla2x00: Found VID=1077 DID=2312 SSVID=1077 SSDID=100 Jul 29 13:17:26 localhost kernel: scsi(0:0:1:1): Enabled tagged queuing, queue depth 16. Jul 29 13:17:26 localhost kernel: Attached scsi disk sda at scsi0, channel 0, id 0, lun 0 Jul 29 13:17:26 localhost kernel: Attached scsi disk sdb at scsi0, channel 0, id 0, lun 1 Jul 29 13:17:26 localhost kernel: Attached scsi disk sdc at scsi0, channel 0, id 1, lun 0 Jul 29 13:17:26 localhost kernel: Attached scsi disk sdd at scsi0, channel 0, id 1, lun 1 Jul 29 13:17:26 localhost kernel: SCSI device sda: 573498800 512-byte hdwr sectors (293631 MB) Jul 29 13:17:26 localhost kernel: sda: sda1 sda2 sda3 Jul 29 13:17:26 localhost kernel: SCSI device sdb: 573498800 512-byte hdwr sectors (293631 MB) Jul 29 13:17:26 localhost kernel: sdb: sdb1 sdb2 sdb3 Jul 29 13:17:26 localhost kernel: SCSI device sdc: 573498800 512-byte hdwr sectors (293631 MB) Jul 29 13:17:26 localhost kernel: sdc: sdc1 sdc2 sdc3 Jul 29 13:17:26 localhost kernel: SCSI device sdd: 573498800 512-byte hdwr sectors (293631 MB) Jul 29 13:17:26 localhost kernel: sdd: sdd1 sdd2 sdd3 Jul 29 13:17:26 localhost kernel: reiserfs: checking transaction log (device 03:03) ... Jul 29 13:17:26 localhost kernel: Warning, log replay starting on readonly filesystem Jul 29 13:17:26 localhost kernel: reiserfs: replayed 63 transactions in 1 seconds Jul 29 13:17:26 localhost kernel: Using r5 hash to sort names Jul 29 13:17:26 localhost kernel: ReiserFS version 3.6.25 Jul 29 13:17:32 localhost modprobe: modprobe: Can't locate module block-major-43 Jul 29 13:17:35 localhost kernel: hydra uses obsolete (PF_INET,SOCK_PACKET) Jul 29 13:17:35 localhost modprobe: modprobe: Can't locate module block-major-43 Jul 29 13:17:35 localhost last message repeated 31 times Jul 29 13:17:35 localhost nfs: Starting NFS services: succeeded Jul 29 13:17:35 localhost nfs: rpc.nfsd startup succeeded Jul 29 13:17:36 localhost nfs: rpc.mountd startup succeeded Jul 29 13:17:52 localhost modprobe: modprobe: Can't locate module block-major-43 Jul 29 13:17:52 localhost last message repeated 31 times Jul 29 13:17:56 localhost kernel: SGI XFS snapshot-xfs-2.4.20-2003-04- 07_05:19_UTC with ACLs, no debug enabled Jul 29 13:17:56 localhost kernel: SGI XFS Quota Management subsystem Jul 29 13:17:56 localhost kernel: XFS mounting filesystem lvm(58,1) Jul 29 13:35:25 localhost modprobe: modprobe: Can't locate module block-major-43 Jul 29 13:36:21 localhost last message repeated 192 times Jul 29 13:36:23 localhost last message repeated 127 times Jul 29 13:36:29 localhost kernel: XFS mounting filesystem lvm(58,1) Jul 29 13:36:30 localhost kernel: XFS quotacheck lvm(58,1): Please wait. Jul 29 13:36:32 localhost kernel: XFS quotacheck lvm(58,1): Done. Jul 29 13:43:47 localhost kernel: e1000: eth2 NIC Link is Down Jul 29 13:43:49 localhost kernel: e1000: eth2 NIC Link is Up 100 Mbps Full Duplex Jul 29 13:44:20 localhost kernel: XFS mounting filesystem lvm(58,0) Jul 29 13:44:20 localhost kernel: Filesystem "lvm(58,0)": XFS internal error xlog_clear_stale_blocks(2) at line 1135 of file xfs_log_recover.c. Caller 0xf8b27f8a Jul 29 13:44:20 localhost kernel: eb7e3bf0 f8b13775 f8b137ef 00000008 00000000 00000001 f219b000 f8b5b6e0 Jul 29 13:44:20 localhost kernel: f8b5a95e 0000046f f8b5a8b2 f8b27f8a 00000007 00002400 00001200 f8b286ea Jul 29 13:44:20 localhost kernel: f8b5a95e 00000001 f219b000 f8b5a8b2 0000046f f8b27f8a 00000008 00000007 Jul 29 13:44:20 localhost kernel: Call Trace: Jul 29 13:44:20 localhost kernel: [qla2300:__insmod_qla2300_S.bss_L22432+2805589/92572491] xfs_stack_trace+0x5/0x10 [xfs] Jul 29 13:44:20 localhost kernel: [] xfs_stack_trace+0x5/0x10 [xfs] Jul 29 13:44:20 localhost kernel: [qla2300:__insmod_qla2300_S.bss_L22432+2805711/92572369] xfs_error_report+0x6f/0xb0 [xfs] Jul 29 13:44:20 localhost kernel: [] xfs_error_report+0x6f/0xb0 [xfs] Jul 29 13:44:20 localhost kernel: [qla2300:__insmod_qla2300_S.bss_L22432+3100352/92277728] .rodata.str1.32+0x240/0 x2c00 [xfs] Jul 29 13:44:20 localhost kernel: [] .rodata.str1.32+0x240/0x2c00 [xfs] Jul 29 13:44:20 localhost kernel: [qla2300:__insmod_qla2300_S.bss_L22432+3096894/92281186] .rodata.str1.1+0x83a/0x 137c [xfs] Jul 29 13:44:20 localhost kernel: [] .rodata.str1.1+0x83a/0x137c [xfs] Jul 29 13:44:20 localhost kernel: [qla2300:__insmod_qla2300_S.bss_L22432+3096722/92281358] .rodata.str1.1+0x78e/0x 137c [xfs] Jul 29 13:44:20 localhost kernel: [] .rodata.str1.1+0x78e/0x137c [xfs] Jul 29 13:44:20 localhost kernel: [qla2300:__insmod_qla2300_S.bss_L22432+2889578/92488502] xlog_find_tail+0x27a/0x440 [xfs] Jul 29 13:44:20 localhost kernel: [] xlog_find_tail+0x27a/0x440 [xfs] Jul 29 13:44:20 localhost kernel: [qla2300:__insmod_qla2300_S.bss_L22432+2891466/92486614] xlog_clear_stale_blocks+0x14a/0x1a0 [xfs] Jul 29 13:44:20 localhost kernel: [] xlog_clear_stale_blocks+0x14a/0x1a0 [xfs] Jul 29 13:44:20 localhost kernel: [qla2300:__insmod_qla2300_S.bss_L22432+3096894/92281186] .rodata.str1.1+0x83a/0x 137c [xfs] Jul 29 13:44:20 localhost kernel: [] .rodata.str1.1+0x83a/0x137c [xfs] Jul 29 13:44:20 localhost kernel: [qla2300:__insmod_qla2300_S.bss_L22432+3096722/92281358] .rodata.str1.1+0x78e/0x 137c [xfs] Jul 29 13:44:20 localhost kernel: [] .rodata.str1.1+0x78e/0x137c [xfs] Jul 29 13:44:20 localhost kernel: [qla2300:__insmod_qla2300_S.bss_L22432+2889578/92488502] xlog_find_tail+0x27a/0x440 [xfs] Jul 29 13:44:20 localhost kernel: [] xlog_find_tail+0x27a/0x440 [xfs] Jul 29 13:44:20 localhost kernel: [qla2300:__insmod_qla2300_S.bss_L22432+2889578/92488502] xlog_find_tail+0x27a/0x440 [xfs] Jul 29 13:44:20 localhost kernel: [] xlog_find_tail+0x27a/0x440 [xfs] Jul 29 13:44:20 localhost kernel: [qla2300:__insmod_qla2300_S.bss_L22432+2906167/92471913] xlog_recover+0x37/0x100 [xfs] Jul 29 13:44:20 localhost kernel: [] xlog_recover+0x37/0x100 [xfs] Jul 29 13:44:20 localhost kernel: [qla2300:__insmod_qla2300_S.bss_L22432+2869341/92508739] xfs_log_mount+0x8d/0xf0 [xfs] Jul 29 13:44:20 localhost kernel: [] xfs_log_mount+0x8d/0xf0 [xfs] Jul 29 13:44:20 localhost kernel: [qla2300:__insmod_qla2300_S.bss_L22432+2912227/92465853] xfs_mountfs+0x503/0xf20 [xfs] Jul 29 13:44:20 localhost kernel: [] xfs_mountfs+0x503/0xf20 [xfs] Jul 29 13:44:20 localhost kernel: [qla2300:__insmod_qla2300_S.bss_L22432+2909972/92468108] xfs_readsb+0x134/0x1f0 [xfs] Jul 29 13:44:20 localhost kernel: [] xfs_readsb+0x134/0x1f0 [xfs] Jul 29 13:44:20 localhost kernel: [qla2300:__insmod_qla2300_S.bss_L22432+2858466/92519614] xfs_ioinit+0x42/0x50 [xfs] Jul 29 13:44:20 localhost kernel: [] xfs_ioinit+0x42/0x50 [xfs] Jul 29 13:44:20 localhost kernel: [qla2300:__insmod_qla2300_S.bss_L22432+2947982/92430098] xfs_mount+0x2ce/0x400 [xfs] Jul 29 13:44:20 localhost kernel: [] xfs_mount+0x2ce/0x400 [xfs] Jul 29 13:44:20 localhost kernel: [qla2300:__insmod_qla2300_S.bss_L22432+3043747/92334333] vfs_mount+0x43/0x50 [xfs] Jul 29 13:44:20 localhost kernel: [] vfs_mount+0x43/0x50 [xfs] Jul 29 13:44:20 localhost kernel: [qla2300:__insmod_qla2300_S.bss_L22432+3075484/92302596] xfs_qm_mount+0x4c/0x70 [xfs] Jul 29 13:44:20 localhost kernel: [] xfs_qm_mount+0x4c/0x70 [xfs] Jul 29 13:44:20 localhost kernel: [qla2300:__insmod_qla2300_S.bss_L22432+3043747/92334333] vfs_mount+0x43/0x50 [xfs] Jul 29 13:44:20 localhost kernel: [] vfs_mount+0x43/0x50 [xfs] Jul 29 13:44:20 localhost kernel: [qla2300:__insmod_qla2300_S.bss_L22432+3042987/92335093] linvfs_read_super+0x9b/0x1c0 [xfs] Jul 29 13:44:20 localhost kernel: [] linvfs_read_super+0x9b/0x1c0 [xfs] Jul 29 13:44:20 localhost kernel: [kmalloc+75/96] kmalloc+0x4b/0x60 [kernel] Jul 29 13:44:20 localhost kernel: [] kmalloc+0x4b/0x60 [kernel] Jul 29 13:44:20 localhost kernel: [alloc_super+58/432] alloc_super+0x3a/0x1b0 [kernel] Jul 29 13:44:20 localhost kernel: [] alloc_super+0x3a/0x1b0 [kernel] Jul 29 13:44:20 localhost kernel: [insert_super+100/128] insert_super+0x64/0x80 [kernel] Jul 29 13:44:20 localhost kernel: [] insert_super+0x64/0x80 [kernel] Jul 29 13:44:20 localhost kernel: [get_sb_bdev+446/752] get_sb_bdev+0x1be/0x2f0 [kernel] Jul 29 13:44:20 localhost kernel: [] get_sb_bdev+0x1be/0x2f0 [kernel] Jul 29 13:44:20 localhost kernel: [qla2300:__insmod_qla2300_S.bss_L22432+3160236/92217844] xfs_fs_type+0x0/0x34 [xfs] Jul 29 13:44:20 localhost kernel: [] xfs_fs_type+0x0/0x34 [xfs] Jul 29 13:44:20 localhost kernel: [do_kern_mount+289/320] do_kern_mount+0x121/0x140 [kernel] Jul 29 13:44:20 localhost kernel: [] do_kern_mount+0x121/0x140 [kernel] Jul 29 13:44:20 localhost kernel: [qla2300:__insmod_qla2300_S.bss_L22432+3160236/92217844] xfs_fs_type+0x0/0x34 [xfs] Jul 29 13:44:20 localhost kernel: [] xfs_fs_type+0x0/0x34 [xfs] Jul 29 13:44:20 localhost kernel: [do_add_mount+147/400] do_add_mount+0x93/0x190 [kernel] Jul 29 13:44:20 localhost kernel: [] do_add_mount+0x93/0x190 [kernel] Jul 29 13:44:20 localhost kernel: [do_mount+352/432] do_mount+0x160/0x1b0 [kernel] Jul 29 13:44:20 localhost kernel: [] do_mount+0x160/0x1b0 [kernel] Jul 29 13:44:20 localhost kernel: [copy_mount_options+121/208] copy_mount_options+0x79/0xd0 [kernel] Jul 29 13:44:20 localhost kernel: [] copy_mount_options+0x79/0xd0 [kernel] Jul 29 13:44:20 localhost kernel: [sys_mount+215/352] sys_mount+0xd7/0x160 [kernel] Jul 29 13:44:20 localhost kernel: [] sys_mount+0xd7/0x160 [kernel] Jul 29 13:44:20 localhost kernel: [system_call+51/56] system_call+0x33/0x38 [kernel] Jul 29 13:44:20 localhost kernel: [] system_call+0x33/0x38 [kernel] Jul 29 13:44:20 localhost kernel: Jul 29 13:44:20 localhost kernel: XFS: failed to locate log tail Jul 29 13:44:20 localhost kernel: XFS: log mount/recovery failed Jul 29 13:44:20 localhost kernel: XFS: log mount failed Jul 29 13:44:31 localhost kernel: XFS mounting filesystem lvm(58,0) ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From owner-linux-xfs@oss.sgi.com Wed Jul 30 07:43:44 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 30 Jul 2003 07:44:04 -0700 (PDT) Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.9/8.12.9) with ESMTP id h6UEhhFl031331 for ; Wed, 30 Jul 2003 07:43:43 -0700 Received: (from xfs@localhost) by oss.sgi.com (8.12.9/8.12.8/Submit) id h6UEhh4B031330 for linux-xfs@oss.sgi.com; Wed, 30 Jul 2003 07:43:43 -0700 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.9/8.12.9) with ESMTP id h6UEhfFp031312 for ; Wed, 30 Jul 2003 07:43:41 -0700 Received: (from apache@localhost) by oss.sgi.com (8.12.9/8.12.8/Submit) id h6UEgD74031218; Wed, 30 Jul 2003 07:42:13 -0700 Date: Wed, 30 Jul 2003 07:42:13 -0700 Message-Id: <200307301442.h6UEgD74031218@oss.sgi.com> From: bugzilla-daemon@oss.sgi.com To: xfs-master@oss.sgi.com Subject: [Bug 269] XFS Data Corruption on Power Failure(on unclean unmount) X-Bugzilla-Reason: AssignedTo X-archive-position: 4808 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: bugzilla-daemon@oss.sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 623 Lines: 18 http://oss.sgi.com/bugzilla/show_bug.cgi?id=269 ------- Additional Comments From lord@sgi.com 2003-30-07 07:42 PDT ------- Probably going to cause you problems, but unless you can reproduce with current xfs code, there is not a lot we can do to help here. There have been lots of changes since April and we do not have the bandwidth to push that back or to diagnose bugs in old code. Some of the changes were in how we sync data out to disk, and are pretty relevant to what you are doing here. ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From owner-linux-xfs@oss.sgi.com Wed Jul 30 08:28:27 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 30 Jul 2003 08:28:41 -0700 (PDT) Received: from beta.dmz-eu.st.com (beta.dmz-eu.st.com [164.129.1.35]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h6UFSQFl002855 for ; Wed, 30 Jul 2003 08:28:27 -0700 Received: from zeta.dmz-eu.st.com (ns2.st.com [164.129.230.9]) by beta.dmz-eu.st.com (STMicroelectronics) with SMTP id 226D1DA95; Wed, 30 Jul 2003 15:28:19 +0000 (GMT) Received: by zeta.dmz-eu.st.com (STMicroelectronics, from userid 0) id 0376761D5; Wed, 30 Jul 2003 15:28:18 +0000 (GMT) Received: from dlx101.dlh.st.com (localhost [127.0.0.1]) by zeta.dmz-eu.st.com (STMicroelectronics) with ESMTP id 90CF21845; Wed, 30 Jul 2003 15:28:17 +0000 (GMT) Received: from localhost (root@localhost) by dlx101.dlh.st.com (8.9.3 (PHNE_25183+JAGae58098)/8.9.3) with ESMTP id UAA24752; Wed, 30 Jul 2003 20:58:15 +0530 (IST) From: mahesh.babbar@st.com X-OpenMail-Hops: 1 Date: Wed, 30 Jul 2003 20:58:14 +0530 Message-Id: Subject: RE: Data Corruption Problem MIME-Version: 1.0 To: ashahi@ciprico.com Cc: freemyer-ml@NorcrossGroup.com, linux-xfs@oss.sgi.com Content-Type: text/plain;charset="ISO-8859-1" Content-Disposition: inline ;Creation-Date="Wed, 30 Jul 2003 08:09:39 -0500" ;Modification-Date="Wed, 30 Jul 2003 20:58:13 +0530" Content-Transfer-Encoding: 7bit X-archive-position: 4809 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: mahesh.babbar@st.com Precedence: bulk X-list: linux-xfs Content-Length: 2857 Lines: 96 Freinds, Please recall that a week before I put up a similar problem and I was told that the problem could be beause of the ancient code of XFS (2 years old) I am running on my box. Answer was that new XFS code is stable, proven and works without any issues and there no *VERY CRITICAL* issues like data corruption. Aman's problem's source may have been different to mine but the bottomlime is that "There could still be a major stability issue even with newer XFS codes". Steve/Lonnie : I don't want to sound un-neccessarily finiky and I completely trust communitiy's ability to set things right, my only submission is that there could still be grey areas Best Regards Mahesh ______________________________ Reply Separator _________________________________ Subject: RE: Data Corruption Problem Author: ashahi (ashahi@ciprico.com) at internet Date: 7/30/2003 6:39 PM Hi Greg, I have a shared storage solution as you mentioned, and am using our own HA software. We do take care of the fact that the current LVM is not cluster aware. regards, Aman. -----Original Message----- From: Greg Freemyer [mailto:freemyer-ml@NorcrossGroup.com] Sent: Wednesday, July 30, 2003 12:14 AM To: Aman Shahi Cc: 'linux-xfs@oss.sgi.com' Subject: Re: Data Corruption Problem Are you saying you have a shared storage solution with 2 LVs that you move back and forth between 2 clustered nodes? If so, I personally would use Linux-HA (heartbeat) in combination with EVMS 2.0. EVMS 2.0 is an alternative to LVM, but it understands clustering and in particular it can use heartbeat for its cluster comm. If you use LVM, I think you have to add a lot of custom scripting to make sure LVM does not screw up due to clustering issues. (i.e. LVM is totally cluster unaware. EVMS is cluster aware.) HTH Greg -- Greg Freemyer On Tue, 2003-07-29 at 17:45, Aman Shahi wrote: > Hi, > I am using linux 2.4.20 + LVM 1.0.7 + > XFS(snapshot-xfs-2.4.20-2003-04-07_05:19_UTC with ACLs, no debug enabled). > > I created couple of Logical Volumes using LVM, and then created/mounted file > system over it. I am running some NFS Client doing I/O over different files > in these file systems. I am doing Failover/Failback testing. That is I have > one filestem attached to one node and other to the second node. When I fail > one of the node, the other node takes over the file system of the second > node. When trying to mount the file system of the second node, I am getting > File System corruption. > > Could anybody tell what is the problem here. Attached here is the output > from "dmesg". > > thanks in Advance, > > Aman. From owner-linux-xfs@oss.sgi.com Wed Jul 30 08:30:57 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 30 Jul 2003 08:31:17 -0700 (PDT) Received: from linux-sxs.org (dhcp065-024-128-253.columbus.rr.com [65.24.128.253]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h6UFUpFl003296 for ; Wed, 30 Jul 2003 08:30:52 -0700 Received: from linux-sxs.org (localhost [127.0.0.1]) by linux-sxs.org (8.12.9/8.12.9) with ESMTP id h6UFUjXu013119; Wed, 30 Jul 2003 11:30:45 -0400 Received: from localhost (netllama@localhost) by linux-sxs.org (8.12.9/8.12.9/Submit) with ESMTP id h6UFUjd0026825; Wed, 30 Jul 2003 11:30:45 -0400 Date: Wed, 30 Jul 2003 11:30:45 -0400 (EDT) From: Net Llama! To: mahesh.babbar@st.com cc: linux-xfs@oss.sgi.com Subject: RE: Data Corruption Problem In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: OK, scanned by File::Scan,ClamAV X-Scanned-By: MIMEDefang 2.35 X-archive-position: 4810 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: netllama@linux-sxs.org Precedence: bulk X-list: linux-xfs Content-Length: 1262 Lines: 28 On Wed, 30 Jul 2003 mahesh.babbar@st.com wrote: > Freinds, > > Please recall that a week before I put up a similar problem and I was > told that the problem could be beause of the ancient code of XFS (2 > years old) I am running on my box. > > Answer was that new XFS code is stable, proven and works without any > issues and there no *VERY CRITICAL* issues like data corruption. > > Aman's problem's source may have been different to mine but the > bottomlime is that "There could still be a major stability issue even > with newer XFS codes". > > Steve/Lonnie : I don't want to sound un-neccessarily finiky and I > completely trust communitiy's ability to set things right, my only > submission is that there could still be grey areas And the moon might be blue on alternate sundays in June. Please don't spread FUD. If you have evidence of a problem, then present it, against the latest released stable XFS codebase. If not, then don't raise doubt over something that you have a hunch on without any real evidence. -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Lonni J Friedman netllama@linux-sxs.org Linux Step-by-step & TyGeMo http://netllama.ipfox.com From owner-linux-xfs@oss.sgi.com Wed Jul 30 08:49:15 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 30 Jul 2003 08:49:34 -0700 (PDT) Received: from tolkor.sgi.com (tolkor.SGI.COM [198.149.18.6]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h6UFnEFl007044 for ; Wed, 30 Jul 2003 08:49:14 -0700 Received: from flecktone.americas.sgi.com (flecktone.americas.sgi.com [192.48.203.135]) by tolkor.sgi.com (8.12.9/8.12.9/linux-outbound_gateway-1.1) with ESMTP id h6UG8TsR023018 for ; Wed, 30 Jul 2003 11:08:29 -0500 Received: from daisy-e236.americas.sgi.com (daisy-e236.americas.sgi.com [128.162.236.214]) by flecktone.americas.sgi.com (8.12.9/8.12.9/generic_config-1.2) with ESMTP id h6UFn8QK3205895; Wed, 30 Jul 2003 10:49:08 -0500 (CDT) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.232.100]) by daisy-e236.americas.sgi.com (8.12.9/SGI-server-1.8) with ESMTP id h6UFn7Rn203472157; Wed, 30 Jul 2003 10:49:07 -0500 (CDT) Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id h6UFn7R30545; Wed, 30 Jul 2003 10:49:07 -0500 Subject: RE: Data Corruption Problem From: Steve Lord To: mahesh.babbar@st.com Cc: ashahi@ciprico.com, freemyer-ml@NorcrossGroup.com, linux-xfs@oss.sgi.com In-Reply-To: References: Content-Type: text/plain Content-Transfer-Encoding: 7bit Organization: Message-Id: <1059580146.30346.16.camel@jen.americas.sgi.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.4 Date: 30 Jul 2003 10:49:06 -0500 X-archive-position: 4811 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: lord@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 1919 Lines: 53 On Wed, 2003-07-30 at 10:28, mahesh.babbar@st.com wrote: > Freinds, > > Please recall that a week before I put up a similar problem and I was > told that the problem could be beause of the ancient code of XFS (2 > years old) I am running on my box. > > Answer was that new XFS code is stable, proven and works without any > issues and there no *VERY CRITICAL* issues like data corruption. > > Aman's problem's source may have been different to mine but the > bottomlime is that "There could still be a major stability issue even > with newer XFS codes". > > Steve/Lonnie : I don't want to sound un-neccessarily finiky and I > completely trust communitiy's ability to set things right, my only > submission is that there could still be grey areas Please remember that you are getting all of this for free - including those of you who are selling products with linux XFS in them. We do not have the bandwidth to go back and backport bug fixes to older kernels. So, our first plan of attack is to ask folks to reproduce on a recent kernel - i.e. install the bug fixes. If you are running some combination of software which means you cannot do this, then we really cannot help. Aman's code is still a few months old, and I have fixed a number of issues in the xfs sync path since then. He is also doing some fairly funky things. You asked a question on the list about stability, you did not report corruption, you said: Hi , I am totally new to XFs world so please bear with me for my ignorance. My query is how stable xfs is ? Or let's say which version of it is most stable. Any hint is welcome. TIA Mahesh Steve -- Steve Lord voice: +1-651-683-3511 Principal Engineer, Filesystem Software email: lord@sgi.com From owner-linux-xfs@oss.sgi.com Wed Jul 30 09:02:55 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 30 Jul 2003 09:03:09 -0700 (PDT) Received: from beta.dmz-eu.st.com (beta.dmz-eu.st.com [164.129.1.35]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h6UG2rFl008405 for ; Wed, 30 Jul 2003 09:02:54 -0700 Received: from zeta.dmz-eu.st.com (ns2.st.com [164.129.230.9]) by beta.dmz-eu.st.com (STMicroelectronics) with SMTP id 76E10DC3E; Wed, 30 Jul 2003 16:02:47 +0000 (GMT) Received: by zeta.dmz-eu.st.com (STMicroelectronics, from userid 0) id 524E16163; Wed, 30 Jul 2003 16:02:47 +0000 (GMT) Received: from dlx101.dlh.st.com (localhost [127.0.0.1]) by zeta.dmz-eu.st.com (STMicroelectronics) with ESMTP id 1F0BF1848; Wed, 30 Jul 2003 16:02:46 +0000 (GMT) Received: from localhost (root@localhost) by dlx101.dlh.st.com (8.9.3 (PHNE_25183+JAGae58098)/8.9.3) with ESMTP id VAA27802; Wed, 30 Jul 2003 21:32:43 +0530 (IST) From: mahesh.babbar@st.com X-OpenMail-Hops: 1 Date: Wed, 30 Jul 2003 21:32:43 +0530 Message-Id: In-Reply-To: Subject: RE: Data Corruption Problem MIME-Version: 1.0 To: netllama@linux-sxs.org Cc: mahesh.babbar@st.com, linux-xfs@oss.sgi.com Content-Type: TEXT/PLAIN; charset=US-ASCII Content-Disposition: inline ;Creation-Date="Wed, 30 Jul 2003 11:30:45 -0400" ;Modification-Date="Wed, 30 Jul 2003 21:32:42 +0530" Content-Transfer-Encoding: 7bit X-archive-position: 4812 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: mahesh.babbar@st.com Precedence: bulk X-list: linux-xfs Content-Length: 2904 Lines: 81 Hi Lonnie I am sorry If I was being offending, but want to present following facts here. Please challenge me : Evidence is 1. I have lost a big chunk of data. In the range of GBs. It was commercially important data. 2. In my 10 years of carreer, I have never seen a Sun(UFS) or an HPUX(JFS) or an AIX box(JFS) corrupting data like what I have seen or what Aman has faced. 2. You will say "LATEST" code resolves most of the issues. Accepted. But is there a version, X or Y or Z (old or latest, a user doesn't care) which is STABLE. What I mean by stability is, a technical person (which you all are) can say " I am confident that IT WORKS". 3. In an envrionment which involves *real* customers and where each second counts and data means hard dollors, no body bothers about CODES and their versions. So please don't distribute something (even free) in the name of * it's latest * It's gives better performance * It's this , it's that BUT when it comes to stability, It all depends. Which as per me is the most important factor. It may work on our personal laptops/labs/academies but not in commercial sector. Mahesh ______________________________ Reply Separator _________________________________ Subject: RE: Data Corruption Problem Author: netllama (netllama@linux-sxs.org) at internet Date: 7/30/2003 9:00 PM On Wed, 30 Jul 2003 mahesh.babbar@st.com wrote: > Freinds, > > Please recall that a week before I put up a similar problem and I was > told that the problem could be beause of the ancient code of XFS (2 > years old) I am running on my box. > > Answer was that new XFS code is stable, proven and works without any > issues and there no *VERY CRITICAL* issues like data corruption. > > Aman's problem's source may have been different to mine but the > bottomlime is that "There could still be a major stability issue even > with newer XFS codes". > > Steve/Lonnie : I don't want to sound un-neccessarily finiky and I > completely trust communitiy's ability to set things right, my only > submission is that there could still be grey areas And the moon might be blue on alternate sundays in June. Please don't spread FUD. If you have evidence of a problem, then present it, against the latest released stable XFS codebase. If not, then don't raise doubt over something that you have a hunch on without any real evidence. -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Lonni J Friedman netllama@linux-sxs.org Linux Step-by-step & TyGeMo http://netllama.ipfox.com From owner-linux-xfs@oss.sgi.com Wed Jul 30 09:12:04 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 30 Jul 2003 09:12:08 -0700 (PDT) Received: from fed1mtao03.cox.net (fed1mtao03.cox.net [68.6.19.242]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h6UGC3Fl009401 for ; Wed, 30 Jul 2003 09:12:04 -0700 Received: from jeeves.kpf.internal ([24.56.60.83]) by fed1mtao03.cox.net (InterMail vM.5.01.04.05 201-253-122-122-105-20011231) with ESMTP id <20030730161156.TNCE10286.fed1mtao03.cox.net@jeeves.kpf.internal>; Wed, 30 Jul 2003 12:11:56 -0400 Received: from [192.168.172.107] (helo=cox.net) by jeeves.kpf.internal with esmtp (Exim 4.05) id 19htYU-0000WG-00; Wed, 30 Jul 2003 09:11:58 -0700 Message-ID: <3F27EE4C.5020602@cox.net> Date: Wed, 30 Jul 2003 09:11:56 -0700 From: "Kevin P. Fleming" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en MIME-Version: 1.0 CC: netllama@linux-sxs.org, linux-xfs@oss.sgi.com Subject: Re: Data Corruption Problem References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 4813 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: kpfleming@cox.net Precedence: bulk X-list: linux-xfs Content-Length: 1121 Lines: 25 mahesh.babbar@st.com wrote: > 1. I have lost a big chunk of data. In the range of GBs. It was > commercially important data. > But apparently not "commercially important" enough to have backup copies of it made. No filesystem is perfect. All software has bugs. No version of XFS "WORKS" (to use your emphasis), they all strive to be perfect but will fail under some circumstances. The best the XFS team can do is to find those circumstances, replicate the problem and craft a solution. When a new combination of circumstances arises (and the fact that the XFS team is targeting a moving kernel project with significant changes happening all the time), the XFS code may exhibit a new type of unwanted behavior. That is life. If your data is important, you cannot trust any filesystem, on any operating system, on any piece of hardware, to hold the _sole_ copy of that data. If you put yourself in that position, then you have only yourself to blame. It could have been a hardware failure or an operating system malfunction that caused your data loss as easily as it could have been XFS. From owner-linux-xfs@oss.sgi.com Wed Jul 30 09:23:19 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 30 Jul 2003 09:23:31 -0700 (PDT) Received: from tolkor.sgi.com (tolkor.SGI.COM [198.149.18.6]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h6UGNIFl010573 for ; Wed, 30 Jul 2003 09:23:18 -0700 Received: from flecktone.americas.sgi.com (flecktone.americas.sgi.com [192.48.203.135]) by tolkor.sgi.com (8.12.9/8.12.9/linux-outbound_gateway-1.1) with ESMTP id h6UGgXsR032716 for ; Wed, 30 Jul 2003 11:42:33 -0500 Received: from daisy-e236.americas.sgi.com (daisy-e236.americas.sgi.com [128.162.236.214]) by flecktone.americas.sgi.com (8.12.9/8.12.9/generic_config-1.2) with ESMTP id h6UGNCQK3210893; Wed, 30 Jul 2003 11:23:12 -0500 (CDT) Received: from [128.162.232.98] (rose.americas.sgi.com [128.162.232.98]) by daisy-e236.americas.sgi.com (8.12.9/SGI-server-1.8) with ESMTP id h6UGNCRn204158187; Wed, 30 Jul 2003 11:23:12 -0500 (CDT) Subject: RE: Data Corruption Problem From: Russell Cattelan To: mahesh.babbar@st.com Cc: netllama@linux-sxs.org, linux-xfs@oss.sgi.com In-Reply-To: References: Content-Type: text/plain Message-Id: <1059582021.34654.207.camel@rose.americas.sgi.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.3 Date: 30 Jul 2003 11:20:21 -0500 Content-Transfer-Encoding: 7bit X-archive-position: 4814 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: cattelan@xfs.org Precedence: bulk X-list: linux-xfs Content-Length: 3539 Lines: 93 You seem quick to blame the FS for all your data corruption problems. As stated in your original email your XFS FS is sitting on an LVM volume. You failed to mention which version which potentially acient version of LVM you are running (which has had it's share of stability issues). You didn't mention which disks/controller/driver version you are using, all of which have potential to "corrupt data" If you really have been working with computers for 10 years you should know the importance of backups as failures do happen and data can be lost. Also you might want to look up the work evidence as most your points below reflect conjecture on your part. On Wed, 2003-07-30 at 11:02, mahesh.babbar@st.com wrote: > Hi Lonnie > > I am sorry If I was being offending, but want to present following > facts here. Please challenge me : > > Evidence is > > 1. I have lost a big chunk of data. In the range of GBs. It was > commercially important data. > > 2. In my 10 years of carreer, I have never seen a Sun(UFS) or an > HPUX(JFS) or an AIX box(JFS) corrupting data like what I have seen or > what Aman has faced. > > 2. You will say "LATEST" code resolves most of the issues. Accepted. > But is there a version, X or Y or Z (old or latest, a user doesn't > care) which is STABLE. > > What I mean by stability is, a technical person (which you all are) > can say " I am confident that IT WORKS". > > 3. In an envrionment which involves *real* customers and where each > second counts and data means hard dollors, no body bothers about CODES > and their versions. So please don't distribute something (even free) > in the name of > > * it's latest > * It's gives better performance > * It's this , it's that > > BUT > > when it comes to stability, It all depends. Which as per me is the > most important factor. > > It may work on our personal laptops/labs/academies but not in > commercial sector. > > Mahesh > > > > > > > ______________________________ Reply Separator _________________________________ > Subject: RE: Data Corruption Problem > Author: netllama (netllama@linux-sxs.org) at internet > Date: 7/30/2003 9:00 PM > > > On Wed, 30 Jul 2003 mahesh.babbar@st.com wrote: > > Freinds, > > > > Please recall that a week before I put up a similar problem and I was > > told that the problem could be beause of the ancient code of XFS (2 > > years old) I am running on my box. > > > > Answer was that new XFS code is stable, proven and works without any > > issues and there no *VERY CRITICAL* issues like data corruption. > > > > Aman's problem's source may have been different to mine but the > > bottomlime is that "There could still be a major stability issue even > > with newer XFS codes". > > > > Steve/Lonnie : I don't want to sound un-neccessarily finiky and I > > completely trust communitiy's ability to set things right, my only > > submission is that there could still be grey areas > > And the moon might be blue on alternate sundays in June. Please don't > spread FUD. If you have evidence of a problem, then present it, against > the latest released stable XFS codebase. If not, then don't raise doubt > over something that you have a hunch on without any real evidence. > From owner-linux-xfs@oss.sgi.com Wed Jul 30 09:27:07 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 30 Jul 2003 09:27:10 -0700 (PDT) Received: from phoenix.infradead.org (pub234.cambridge.redhat.com [213.86.99.234] (may be forged)) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h6UGR6Fl011251 for ; Wed, 30 Jul 2003 09:27:07 -0700 Received: from hch by phoenix.infradead.org with local (Exim 4.10) id 19htn0-0006rH-00; Wed, 30 Jul 2003 17:26:58 +0100 Date: Wed, 30 Jul 2003 17:26:58 +0100 From: Christoph Hellwig To: Russell Cattelan Cc: mahesh.babbar@st.com, netllama@linux-sxs.org, linux-xfs@oss.sgi.com Subject: Re: Data Corruption Problem Message-ID: <20030730172658.A26351@infradead.org> References: <1059582021.34654.207.camel@rose.americas.sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <1059582021.34654.207.camel@rose.americas.sgi.com>; from cattelan@xfs.org on Wed, Jul 30, 2003 at 11:20:21AM -0500 X-archive-position: 4815 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: hch@infradead.org Precedence: bulk X-list: linux-xfs Content-Length: 347 Lines: 8 On Wed, Jul 30, 2003 at 11:20:21AM -0500, Russell Cattelan wrote: > As stated in your original email your XFS FS is sitting on an LVM > volume. You failed to mention which version which potentially acient > version of LVM you are running (which has had it's share of stability > issues). Every released lvm1 version has data corruption issues.. From owner-linux-xfs@oss.sgi.com Wed Jul 30 09:31:27 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 30 Jul 2003 09:31:30 -0700 (PDT) Received: from beta.dmz-eu.st.com (beta.dmz-eu.st.com [164.129.1.35]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h6UGVQFl011977 for ; Wed, 30 Jul 2003 09:31:27 -0700 Received: from zeta.dmz-eu.st.com (ns2.st.com [164.129.230.9]) by beta.dmz-eu.st.com (STMicroelectronics) with SMTP id 558A5DB42; Wed, 30 Jul 2003 16:31:20 +0000 (GMT) Received: by zeta.dmz-eu.st.com (STMicroelectronics, from userid 0) id 2FF216184; Wed, 30 Jul 2003 16:31:20 +0000 (GMT) Received: from dlx101.dlh.st.com (localhost [127.0.0.1]) by zeta.dmz-eu.st.com (STMicroelectronics) with ESMTP id D60501848; Wed, 30 Jul 2003 16:31:18 +0000 (GMT) Received: from localhost (root@localhost) by dlx101.dlh.st.com (8.9.3 (PHNE_25183+JAGae58098)/8.9.3) with ESMTP id WAA00419; Wed, 30 Jul 2003 22:01:17 +0530 (IST) From: mahesh.babbar@st.com X-OpenMail-Hops: 1 Date: Wed, 30 Jul 2003 22:01:16 +0530 Message-Id: In-Reply-To: Subject: Re: Data Corruption Problem MIME-Version: 1.0 To: mahesh.babbar@st.com Cc: kpfleming@cox.net, netllama@linux-sxs.org, linux-xfs@oss.sgi.com Content-Type: text/plain; charset=us-ascii; format=flowed Content-Disposition: inline ;Creation-Date="Wed, 30 Jul 2003 09:11:56 -0700" ;Modification-Date="Wed, 30 Jul 2003 22:01:11 +0530" Content-Transfer-Encoding: 7bit X-archive-position: 4816 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: mahesh.babbar@st.com Precedence: bulk X-list: linux-xfs Content-Length: 1373 Lines: 35 > 1. I have lost a big chunk of data. In the range of GBs. It was > commercially important data. > But apparently not "commercially important" enough to have backup copies of it made. >> Was restored from backup but a day's work lost. That apart, >> point is not really this. I understand, no file system is 100% >> perfect . After all, why do we take backups. >> Point really is Vulnerability Factor. No filesystem is perfect. All software has bugs. No version of XFS "WORKS" (to use your emphasis), they all strive to be perfect but will fail under some circumstances. The best the XFS team can do is to find those circumstances, replicate the problem and craft a solution. When a new combination of circumstances arises (and the fact that the XFS team is targeting a moving kernel project with significant changes happening all the time), the XFS code may exhibit a new type of unwanted behavior. That is life. If your data is important, you cannot trust any filesystem, on any operating system, on any piece of hardware, to hold the _sole_ copy of that data. If you put yourself in that position, then you have only yourself to blame. It could have been a hardware failure or an operating system malfunction that caused your data loss as easily as it could have been XFS. From owner-linux-xfs@oss.sgi.com Wed Jul 30 09:37:48 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 30 Jul 2003 09:37:53 -0700 (PDT) Received: from linux-sxs.org (dhcp065-024-128-253.columbus.rr.com [65.24.128.253]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h6UGblFl012860 for ; Wed, 30 Jul 2003 09:37:47 -0700 Received: from linux-sxs.org (localhost [127.0.0.1]) by linux-sxs.org (8.12.9/8.12.9) with ESMTP id h6UGbiXu018004; Wed, 30 Jul 2003 12:37:44 -0400 Received: from localhost (netllama@localhost) by linux-sxs.org (8.12.9/8.12.9/Submit) with ESMTP id h6UGbi5a004962; Wed, 30 Jul 2003 12:37:44 -0400 Date: Wed, 30 Jul 2003 12:37:44 -0400 (EDT) From: Net Llama! To: mahesh.babbar@st.com cc: linux-xfs@oss.sgi.com Subject: Re: Data Corruption Problem In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: OK, scanned by File::Scan,ClamAV X-Scanned-By: MIMEDefang 2.35 X-archive-position: 4817 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: netllama@linux-sxs.org Precedence: bulk X-list: linux-xfs Content-Length: 1810 Lines: 47 Please do us all a favor, and learn how to use your mail client. This is the 4th copy of this that i've received from you Mahesh, all without any new content from you. Your actions thus far on this list indicate PEBCAK. On Wed, 30 Jul 2003 mahesh.babbar@st.com wrote: > > > > > > 1. I have lost a big chunk of data. In the range of GBs. It was > > commercially important data. > > > > But apparently not "commercially important" enough to have backup > copies of it made. > > >> Was restored from backup but a day's work lost. That apart, > >> point is not really this. I understand, no file system is 100% > >> perfect . After all, why do we take backups. > > >> Point really is Vulnerability Factor. > > No filesystem is perfect. All software has bugs. No version of XFS > "WORKS" (to use your emphasis), they all strive to be perfect but will > fail under some circumstances. The best the XFS team can do is to find > those circumstances, replicate the problem and craft a solution. When > a new combination of circumstances arises (and the fact that the XFS > team is targeting a moving kernel project with significant changes > happening all the time), the XFS code may exhibit a new type of > unwanted behavior. That is life. > > If your data is important, you cannot trust any filesystem, on any > operating system, on any piece of hardware, to hold the _sole_ copy of > that data. If you put yourself in that position, then you have only > yourself to blame. It could have been a hardware failure or an > operating system malfunction that caused your data loss as easily as > it could have been XFS. > > > -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Lonni J Friedman netllama@linux-sxs.org Linux Step-by-step & TyGeMo http://netllama.ipfox.com From owner-linux-xfs@oss.sgi.com Wed Jul 30 09:49:50 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 30 Jul 2003 09:49:52 -0700 (PDT) Received: from rain.CC.Lehigh.EDU (rain.CC.Lehigh.EDU [128.180.39.20]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h6UGnmFl014104 for ; Wed, 30 Jul 2003 09:49:49 -0700 Received: from Lehigh.EDU (hooch.CC.lehigh.EDU [128.180.8.106]) by rain.CC.Lehigh.EDU (8.12.9/8.12.9) with ESMTP id h6UGngGH008839 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 30 Jul 2003 12:49:43 -0400 Message-ID: <3F27F726.30607@Lehigh.EDU> Date: Wed, 30 Jul 2003 12:49:42 -0400 From: Jim Eshleman User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3) Gecko/20030314 X-Accept-Language: en-us, en MIME-Version: 1.0 CC: linux-xfs@oss.sgi.com Subject: Re: Data Corruption Problem References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 4818 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: jce0@Lehigh.EDU Precedence: bulk X-list: linux-xfs Content-Length: 712 Lines: 14 I've been running XFS for about two years now, and have had my share of problems, but haven't experienced any corruption. XFS has progressed by "leaps and bounds" to the credit of the developers and users. If you want to run a linux server, XFS is a good choice of fs IHMO. For the record I'm running snapshot-xfs-2.4.21-2003-07-07_02:01_UTC on an IBM x370 8-way with 8GB (64G HIGHMEM enabled) and ~500GB disk, all HW RAID with Serveraid (ips) controllers. The system is a very busy campus mail server with ~10K users. LVM, NIS, NFS, POP, IMAP, sendmail, etc. Migrated to this system from an IBM F50 AIX system two years ago and have been happier since, although JFS on AIX is also a fine fs. Jim From owner-linux-xfs@oss.sgi.com Wed Jul 30 10:04:12 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 30 Jul 2003 10:04:16 -0700 (PDT) Received: from mpls-qmqp-01.inet.qwest.net (mpls-qmqp-01.inet.qwest.net [63.231.195.112]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h6UH4BFl015572 for ; Wed, 30 Jul 2003 10:04:11 -0700 Received: (qmail 36674 invoked by uid 0); 30 Jul 2003 17:04:10 -0000 Received: from unknown (63.231.195.13) by mpls-qmqp-01.inet.qwest.net with QMQP; 30 Jul 2003 17:04:10 -0000 Received: from unknown (HELO software1.logiplex.internal) (65.102.60.133) by mpls-pop-13.inet.qwest.net with SMTP; 30 Jul 2003 17:04:10 -0000 Date: 30 Jul 2003 10:04:09 -0700 Message-Id: <1059584649.8920.4209.camel@software1.logiplex.internal> From: "Cliff Wells" To: "Seth Mos" Cc: "Ravi Wijayaratne" , linux-xfs@oss.sgi.com Subject: Re: Performance drop in Linux 2.4.19-XFS 1.2 ? In-Reply-To: <4.3.2.7.2.20030730110055.041a1bc0@pop.xs4all.nl> References: <4.3.2.7.2.20030730110055.041a1bc0@pop.xs4all.nl> Content-Type: text/plain Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.3 Content-Transfer-Encoding: 7bit X-archive-position: 4819 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: logiplex@qwest.net Precedence: bulk X-list: linux-xfs Content-Length: 1043 Lines: 31 On Wed, 2003-07-30 at 02:09, Seth Mos wrote: > At 18:31 29-7-2003 -0700, Ravi Wijayaratne wrote: > >Hi, > > > >We are seeing a %15 performance drop when we move from XFS 1.1 to 1.2. > >Here are some of our particulars: > >We have been testing the performance of Linux-2.4.19 and XFS 1.2 with > >NetBench. > >We compared the performance with that of Linux-2.4.18 and XFS 1.1. > >We have been running Samba 3.0. > > The only problem I know of which is not exclusive to XFS (ext3 does this as > well) is one on the read performance of 2.4.18 vs the 2.4.20 errata kernel. > > On 2.4.18-27 I get 170MB/sec read speed > on 2.4.20-18 I get 80MB/sec read speed. > > the write speed stays consistent between these releases but the enormous > drop in read speed is very strange. It appears to be present in the > standard rh errata as well. Try hdparm -a 512 /dev/hdx http://marc.theaimsgroup.com/?l=linux-kernel&m=105830842018800&w=2 -- Cliff Wells, Software Engineer Logiplex Corporation (www.logiplex.net) (503) 978-6726 (800) 735-0555 From owner-linux-xfs@oss.sgi.com Wed Jul 30 10:06:49 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 30 Jul 2003 10:07:02 -0700 (PDT) Received: from beta.dmz-eu.st.com (beta.dmz-eu.st.com [164.129.1.35]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h6UH6cFl016204 for ; Wed, 30 Jul 2003 10:06:39 -0700 Received: from zeta.dmz-eu.st.com (ns2.st.com [164.129.230.9]) by beta.dmz-eu.st.com (STMicroelectronics) with SMTP id C65DDDC61; Wed, 30 Jul 2003 16:25:22 +0000 (GMT) Received: by zeta.dmz-eu.st.com (STMicroelectronics, from userid 0) id E760161D8; Wed, 30 Jul 2003 16:24:52 +0000 (GMT) Received: from dlx101.dlh.st.com (localhost [127.0.0.1]) by zeta.dmz-eu.st.com (STMicroelectronics) with ESMTP id 9207D1849; Wed, 30 Jul 2003 16:24:51 +0000 (GMT) Received: from localhost (root@localhost) by dlx101.dlh.st.com (8.9.3 (PHNE_25183+JAGae58098)/8.9.3) with ESMTP id VAA29763; Wed, 30 Jul 2003 21:54:49 +0530 (IST) From: mahesh.babbar@st.com X-OpenMail-Hops: 1 Date: Wed, 30 Jul 2003 21:54:48 +0530 Message-Id: In-Reply-To: <3F27EE4C.5020602@cox.net> Subject: Re: Data Corruption Problem MIME-Version: 1.0 To: kpfleming@cox.net Cc: netllama@linux-sxs.org, linux-xfs@oss.sgi.com Content-Type: text/plain; charset=us-ascii; format=flowed Content-Disposition: inline ;Creation-Date="Wed, 30 Jul 2003 09:11:56 -0700" ;Modification-Date="Wed, 30 Jul 2003 21:54:46 +0530" Content-Transfer-Encoding: 7bit X-archive-position: 4820 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: mahesh.babbar@st.com Precedence: bulk X-list: linux-xfs Content-Length: 1584 Lines: 42 ______________________________ Reply Separator _________________________________ Subject: Re: Data Corruption Problem Author: kpfleming (kpfleming@cox.net) at internet Date: 7/30/2003 9:41 PM mahesh.babbar@st.com wrote: > 1. I have lost a big chunk of data. In the range of GBs. It was > commercially important data. > But apparently not "commercially important" enough to have backup copies of it made. >> Was restored from backup but a day's work lost. That apart, >> point is not really this. I understand, no file system is 100% >> perfect . After all, why do we take backups. >> Point really is Vulnerability Factor. No filesystem is perfect. All software has bugs. No version of XFS "WORKS" (to use your emphasis), they all strive to be perfect but will fail under some circumstances. The best the XFS team can do is to find those circumstances, replicate the problem and craft a solution. When a new combination of circumstances arises (and the fact that the XFS team is targeting a moving kernel project with significant changes happening all the time), the XFS code may exhibit a new type of unwanted behavior. That is life. If your data is important, you cannot trust any filesystem, on any operating system, on any piece of hardware, to hold the _sole_ copy of that data. If you put yourself in that position, then you have only yourself to blame. It could have been a hardware failure or an operating system malfunction that caused your data loss as easily as it could have been XFS. From owner-linux-xfs@oss.sgi.com Wed Jul 30 10:09:36 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 30 Jul 2003 10:09:39 -0700 (PDT) Received: from beta.dmz-eu.st.com (beta.dmz-eu.st.com [164.129.1.35]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h6UH9ZFl018235 for ; Wed, 30 Jul 2003 10:09:35 -0700 Received: from zeta.dmz-eu.st.com (ns2.st.com [164.129.230.9]) by beta.dmz-eu.st.com (STMicroelectronics) with SMTP id 85D37DA75; Wed, 30 Jul 2003 17:09:29 +0000 (GMT) Received: by zeta.dmz-eu.st.com (STMicroelectronics, from userid 0) id 612E0618E; Wed, 30 Jul 2003 17:09:29 +0000 (GMT) Received: from dlx101.dlh.st.com (localhost [127.0.0.1]) by zeta.dmz-eu.st.com (STMicroelectronics) with ESMTP id 348FD1849; Wed, 30 Jul 2003 17:09:28 +0000 (GMT) Received: from localhost (root@localhost) by dlx101.dlh.st.com (8.9.3 (PHNE_25183+JAGae58098)/8.9.3) with ESMTP id WAA03370; Wed, 30 Jul 2003 22:39:26 +0530 (IST) From: mahesh.babbar@st.com X-OpenMail-Hops: 1 Date: Wed, 30 Jul 2003 22:39:25 +0530 Message-Id: In-Reply-To: Subject: Re: Data Corruption Problem MIME-Version: 1.0 To: netllama@linux-sxs.org Cc: mahesh.babbar@st.com, linux-xfs@oss.sgi.com Content-Type: TEXT/PLAIN; charset=US-ASCII Content-Disposition: inline ;Creation-Date="Wed, 30 Jul 2003 12:37:44 -0400" ;Modification-Date="Wed, 30 Jul 2003 22:39:24 +0530" Content-Transfer-Encoding: 7bit X-archive-position: 4821 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: mahesh.babbar@st.com Precedence: bulk X-list: linux-xfs Content-Length: 3145 Lines: 85 Lonnie, Honestly speaking I don't know what PEBCAK means. Request, If you can explain. I am new to your world, the language and the ways. I thought I have already replied but let me respond again to all the messages regarding backups. Backup was there and we restored but the day's work was lost, since backup happend during the night. At the cost of again being labelled who is spreading FUD, let me repeat. The question really is how much vulnerable a product can be to potential problem. Yes we do take backup but that does not mean we totally ignore system's relaibility. I had accepted my fault earlier of running on an "ancient" code. But Aman who is running on the code of April-03 (pls correct me Aman), a similar problem has occurred. Guys, I am not pointing fingers to anybody. I know nothing is 100% perfect. But a provocation NOW can lead us to improvement, Best Regards, Mahesh ______________________________ Reply Separator _________________________________ Subject: Re: Data Corruption Problem Author: netllama (netllama@linux-sxs.org) at internet Date: 7/30/2003 10:07 PM Please do us all a favor, and learn how to use your mail client. This is the 4th copy of this that i've received from you Mahesh, all without any new content from you. Your actions thus far on this list indicate PEBCAK. On Wed, 30 Jul 2003 mahesh.babbar@st.com wrote: > > > > > > 1. I have lost a big chunk of data. In the range of GBs. It was > > commercially important data. > > > > But apparently not "commercially important" enough to have backup > copies of it made. > > >> Was restored from backup but a day's work lost. That apart, > >> point is not really this. I understand, no file system is 100% > >> perfect . After all, why do we take backups. > > >> Point really is Vulnerability Factor. > > No filesystem is perfect. All software has bugs. No version of XFS > "WORKS" (to use your emphasis), they all strive to be perfect but will > fail under some circumstances. The best the XFS team can do is to find > those circumstances, replicate the problem and craft a solution. When > a new combination of circumstances arises (and the fact that the XFS > team is targeting a moving kernel project with significant changes > happening all the time), the XFS code may exhibit a new type of > unwanted behavior. That is life. > > If your data is important, you cannot trust any filesystem, on any > operating system, on any piece of hardware, to hold the _sole_ copy of > that data. If you put yourself in that position, then you have only > yourself to blame. It could have been a hardware failure or an > operating system malfunction that caused your data loss as easily as > it could have been XFS. > > > -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Lonni J Friedman netllama@linux-sxs.org Linux Step-by-step & TyGeMo http://netllama.ipfox.com From owner-linux-xfs@oss.sgi.com Wed Jul 30 10:11:25 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 30 Jul 2003 10:11:31 -0700 (PDT) Received: from linux-sxs.org (dhcp065-024-128-253.columbus.rr.com [65.24.128.253]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h6UHBOFl019246 for ; Wed, 30 Jul 2003 10:11:24 -0700 Received: from linux-sxs.org (localhost [127.0.0.1]) by linux-sxs.org (8.12.9/8.12.9) with ESMTP id h6UGZ6Xu030743; Wed, 30 Jul 2003 12:35:06 -0400 Received: from localhost (netllama@localhost) by linux-sxs.org (8.12.9/8.12.9/Submit) with ESMTP id h6UGZ6x3011439; Wed, 30 Jul 2003 12:35:06 -0400 Date: Wed, 30 Jul 2003 12:35:06 -0400 (EDT) From: Net Llama! To: mahesh.babbar@st.com cc: linux-xfs@oss.sgi.com Subject: RE: Data Corruption Problem In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: OK, scanned by File::Scan,ClamAV X-Scanned-By: MIMEDefang 2.35 X-archive-position: 4822 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: netllama@linux-sxs.org Precedence: bulk X-list: linux-xfs Content-Length: 3033 Lines: 72 On Wed, 30 Jul 2003 mahesh.babbar@st.com wrote: > Hi Lonnie > > I am sorry If I was being offending, but want to present following > facts here. Please challenge me : > > Evidence is > > 1. I have lost a big chunk of data. In the range of GBs. It was > commercially important data. That's what backups are for. Your lack of backups isn't anyone's fault but your own. Your lack of maintaining a system with a recent filesystem codebase is no one's fault but your own. > 2. In my 10 years of carreer, I have never seen a Sun(UFS) or an > HPUX(JFS) or an AIX box(JFS) corrupting data like what I have seen or > what Aman has faced. So? You also didn't think it was prudent to keep backups of your data. So you're background isn't exactly something that I'd want to brag about. > 2. You will say "LATEST" code resolves most of the issues. Accepted. > But is there a version, X or Y or Z (old or latest, a user doesn't > care) which is STABLE. That's what the 2.4.x kernels are. They are the stable kernels. > What I mean by stability is, a technical person (which you all are) > can say " I am confident that IT WORKS". I've got terrabytes of data on XFS. None of it has ever failed or been lost. But if it did, i have nightly backups, and could restore withou a problem. And since, as someone else noted, XFS is 100% free, i've got no place spreading FUD, or complaints. If XFS isn't meeting your needs, either make a positive effort to fix any documented, genuine problems that exist, or don't use XFS. You are free to throw more money away on any of the commerical Unixes, if that's what makes you sleep better at night. > 3. In an envrionment which involves *real* customers and where each > second counts and data means hard dollors, no body bothers about CODES > and their versions. So please don't distribute something (even free) > in the name of > > * it's latest > * It's gives better performance > * It's this , it's that > > BUT > > when it comes to stability, It all depends. Which as per me is the > most important factor. > > It may work on our personal laptops/labs/academies but not in > commercial sector. Please do not condescend to me, or anyone else about real customers. 95% of the data that I host on XFS is customer & production data. I'm talking nearly 3TB of data. If you a sysadmin, its your job to maintain the server, and ensure that its running the latest stable codebase so that uptime & stability are maintained. Making up excuses isn't going to change anything. And latching onto someone else's report of a problem is really nothing more than bandwagon hopping. Either provide documentation of a real stability problem with XFS in 2.4.21 kernels, or stop spreading FUD. -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Lonni J Friedman netllama@linux-sxs.org Linux Step-by-step & TyGeMo http://netllama.ipfox.com From owner-linux-xfs@oss.sgi.com Wed Jul 30 10:22:57 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 30 Jul 2003 10:23:02 -0700 (PDT) Received: from hotmail.com (bay2-dav9.bay2.hotmail.com [65.54.246.113]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h6UHMvFl020686 for ; Wed, 30 Jul 2003 10:22:57 -0700 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Wed, 30 Jul 2003 10:22:51 -0700 Received: from 66.26.227.241 by bay2-dav9.bay2.hotmail.com with DAV; Wed, 30 Jul 2003 17:22:51 +0000 X-Originating-IP: [66.26.227.241] X-Originating-Email: [s_wendy_cheng@hotmail.com] From: "Wendy Cheng" To: "Aman Shahi" , References: Subject: Re: Data Corruption Problem Date: Wed, 30 Jul 2003 13:22:25 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Message-ID: X-OriginalArrivalTime: 30 Jul 2003 17:22:51.0827 (UTC) FILETIME=[34A1D830:01C356BF] X-archive-position: 4823 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: s_wendy_cheng@hotmail.com Precedence: bulk X-list: linux-xfs Content-Length: 12384 Lines: 295 Linux XFS is not a cluster file system - implies that during a failover, the file system's buffer cache is lost (together with the faulty machine). Even the second machine can pick up the follow-on workload, there are possibilities that data could get lost (or corrupted) unless you mount them with "sync" option. All the journaling file system (such as XFS) could do is to ensure file system's meta data is kept on a consistent state but sometimes the journal data could get screwed up too. You ask too much for a free software :)- Wendy ------- ----- Original Message ----- From: "Aman Shahi" To: Sent: Tuesday, July 29, 2003 5:45 PM Subject: Data Corruption Problem | | Hi, | I am using linux 2.4.20 + LVM 1.0.7 + | XFS(snapshot-xfs-2.4.20-2003-04-07_05:19_UTC with ACLs, no debug enabled). | | I created couple of Logical Volumes using LVM, and then created/mounted file | system over it. I am running some NFS Client doing I/O over different files | in these file systems. I am doing Failover/Failback testing. That is I have | one filestem attached to one node and other to the second node. When I fail | one of the node, the other node takes over the file system of the second | node. When trying to mount the file system of the second node, I am getting | File System corruption. | | Could anybody tell what is the problem here. Attached here is the output | from "dmesg". | | thanks in Advance, | | Aman. | | | Jul 29 13:17:25 localhost kernel: Linux version 2.4.20 | (root@patan_new.nj.ciprico.com) (gcc version 3.2 20020903 (Red Hat Linux 8.0 | 3.2-7)) #1 SMP Tue Jul 29 11:31:57 EDT 2003 | Jul 29 13:17:26 localhost kernel: LVM version 1.0.7(28/03/2003) | Jul 29 13:17:26 localhost kernel: NET4: Linux TCP/IP 1.0 for NET4.0 | Jul 29 13:17:26 localhost kernel: qla2x00: Found VID=1077 DID=2312 | SSVID=1077 SSDID=100 | Jul 29 13:17:26 localhost kernel: scsi(0:0:1:1): Enabled tagged queuing, | queue depth 16. | Jul 29 13:17:26 localhost kernel: Attached scsi disk sda at scsi0, channel | 0, id 0, lun 0 | Jul 29 13:17:26 localhost kernel: Attached scsi disk sdb at scsi0, channel | 0, id 0, lun 1 | Jul 29 13:17:26 localhost kernel: Attached scsi disk sdc at scsi0, channel | 0, id 1, lun 0 | Jul 29 13:17:26 localhost kernel: Attached scsi disk sdd at scsi0, channel | 0, id 1, lun 1 | Jul 29 13:17:26 localhost kernel: SCSI device sda: 573498800 512-byte hdwr | sectors (293631 MB) | Jul 29 13:17:26 localhost kernel: sda: sda1 sda2 sda3 | Jul 29 13:17:26 localhost kernel: SCSI device sdb: 573498800 512-byte hdwr | sectors (293631 MB) | Jul 29 13:17:26 localhost kernel: sdb: sdb1 sdb2 sdb3 | Jul 29 13:17:26 localhost kernel: SCSI device sdc: 573498800 512-byte hdwr | sectors (293631 MB) | Jul 29 13:17:26 localhost kernel: sdc: sdc1 sdc2 sdc3 | Jul 29 13:17:26 localhost kernel: SCSI device sdd: 573498800 512-byte hdwr | sectors (293631 MB) | Jul 29 13:17:26 localhost kernel: sdd: sdd1 sdd2 sdd3 | Jul 29 13:17:26 localhost kernel: reiserfs: checking transaction log (device | 03:03) ... | Jul 29 13:17:26 localhost kernel: Warning, log replay starting on readonly | filesystem | Jul 29 13:17:26 localhost kernel: reiserfs: replayed 63 transactions in 1 | seconds | Jul 29 13:17:26 localhost kernel: Using r5 hash to sort names | Jul 29 13:17:26 localhost kernel: ReiserFS version 3.6.25 | Jul 29 13:17:32 localhost modprobe: modprobe: Can't locate module | block-major-43 | Jul 29 13:17:35 localhost kernel: hydra uses obsolete (PF_INET,SOCK_PACKET) | Jul 29 13:17:35 localhost modprobe: modprobe: Can't locate module | block-major-43 | Jul 29 13:17:35 localhost last message repeated 31 times | Jul 29 13:17:35 localhost nfs: Starting NFS services: succeeded | Jul 29 13:17:35 localhost nfs: rpc.nfsd startup succeeded | Jul 29 13:17:36 localhost nfs: rpc.mountd startup succeeded | Jul 29 13:17:52 localhost modprobe: modprobe: Can't locate module | block-major-43 | Jul 29 13:17:52 localhost last message repeated 31 times | Jul 29 13:17:56 localhost kernel: SGI XFS | snapshot-xfs-2.4.20-2003-04-07_05:19_UTC with ACLs, no debug enabled | Jul 29 13:17:56 localhost kernel: SGI XFS Quota Management subsystem | Jul 29 13:17:56 localhost kernel: XFS mounting filesystem lvm(58,1) | Jul 29 13:35:25 localhost modprobe: modprobe: Can't locate module | block-major-43 | Jul 29 13:36:21 localhost last message repeated 192 times | Jul 29 13:36:23 localhost last message repeated 127 times | Jul 29 13:36:29 localhost kernel: XFS mounting filesystem lvm(58,1) | Jul 29 13:36:30 localhost kernel: XFS quotacheck lvm(58,1): Please wait. | Jul 29 13:36:32 localhost kernel: XFS quotacheck lvm(58,1): Done. | Jul 29 13:43:47 localhost kernel: e1000: eth2 NIC Link is Down | Jul 29 13:43:49 localhost kernel: e1000: eth2 NIC Link is Up 100 Mbps Full | Duplex | Jul 29 13:44:20 localhost kernel: XFS mounting filesystem lvm(58,0) | Jul 29 13:44:20 localhost kernel: Filesystem "lvm(58,0)": XFS internal error | xlog_clear_stale_blocks(2) at line 1135 of file xfs_log_recover.c. Caller | 0xf8b27f8a | Jul 29 13:44:20 localhost kernel: eb7e3bf0 f8b13775 f8b137ef 00000008 | 00000000 00000001 f219b000 f8b5b6e0 | Jul 29 13:44:20 localhost kernel: f8b5a95e 0000046f f8b5a8b2 f8b27f8a | 00000007 00002400 00001200 f8b286ea | Jul 29 13:44:20 localhost kernel: f8b5a95e 00000001 f219b000 f8b5a8b2 | 0000046f f8b27f8a 00000008 00000007 | Jul 29 13:44:20 localhost kernel: Call Trace: | Jul 29 13:44:20 localhost kernel: | [qla2300:__insmod_qla2300_S.bss_L22432+2805589/92572491] | xfs_stack_trace+0x5/0x10 [xfs] | Jul 29 13:44:20 localhost kernel: [] xfs_stack_trace+0x5/0x10 | [xfs] | Jul 29 13:44:20 localhost kernel: | [qla2300:__insmod_qla2300_S.bss_L22432+2805711/92572369] | xfs_error_report+0x6f/0xb0 [xfs] | Jul 29 13:44:20 localhost kernel: [] xfs_error_report+0x6f/0xb0 | [xfs] | Jul 29 13:44:20 localhost kernel: | [qla2300:__insmod_qla2300_S.bss_L22432+3100352/92277728] | .rodata.str1.32+0x240/0x2c00 [xfs] | Jul 29 13:44:20 localhost kernel: [] .rodata.str1.32+0x240/0x2c00 | [xfs] | Jul 29 13:44:20 localhost kernel: | [qla2300:__insmod_qla2300_S.bss_L22432+3096894/92281186] | .rodata.str1.1+0x83a/0x137c [xfs] | Jul 29 13:44:20 localhost kernel: [] .rodata.str1.1+0x83a/0x137c | [xfs] | Jul 29 13:44:20 localhost kernel: | [qla2300:__insmod_qla2300_S.bss_L22432+3096722/92281358] | .rodata.str1.1+0x78e/0x137c [xfs] | Jul 29 13:44:20 localhost kernel: [] .rodata.str1.1+0x78e/0x137c | [xfs] | Jul 29 13:44:20 localhost kernel: | [qla2300:__insmod_qla2300_S.bss_L22432+2889578/92488502] | xlog_find_tail+0x27a/0x440 [xfs] | Jul 29 13:44:20 localhost kernel: [] xlog_find_tail+0x27a/0x440 | [xfs] | Jul 29 13:44:20 localhost kernel: | [qla2300:__insmod_qla2300_S.bss_L22432+2891466/92486614] | xlog_clear_stale_blocks+0x14a/0x1a0 [xfs] | Jul 29 13:44:20 localhost kernel: [] | xlog_clear_stale_blocks+0x14a/0x1a0 [xfs] | Jul 29 13:44:20 localhost kernel: | [qla2300:__insmod_qla2300_S.bss_L22432+3096894/92281186] | .rodata.str1.1+0x83a/0x137c [xfs] | Jul 29 13:44:20 localhost kernel: [] .rodata.str1.1+0x83a/0x137c | [xfs] | Jul 29 13:44:20 localhost kernel: | [qla2300:__insmod_qla2300_S.bss_L22432+3096722/92281358] | .rodata.str1.1+0x78e/0x137c [xfs] | Jul 29 13:44:20 localhost kernel: [] .rodata.str1.1+0x78e/0x137c | [xfs] | Jul 29 13:44:20 localhost kernel: | [qla2300:__insmod_qla2300_S.bss_L22432+2889578/92488502] | xlog_find_tail+0x27a/0x440 [xfs] | Jul 29 13:44:20 localhost kernel: [] xlog_find_tail+0x27a/0x440 | [xfs] | Jul 29 13:44:20 localhost kernel: | [qla2300:__insmod_qla2300_S.bss_L22432+2889578/92488502] | xlog_find_tail+0x27a/0x440 [xfs] | Jul 29 13:44:20 localhost kernel: [] xlog_find_tail+0x27a/0x440 | [xfs] | Jul 29 13:44:20 localhost kernel: | [qla2300:__insmod_qla2300_S.bss_L22432+2906167/92471913] | xlog_recover+0x37/0x100 [xfs] | Jul 29 13:44:20 localhost kernel: [] xlog_recover+0x37/0x100 | [xfs] | Jul 29 13:44:20 localhost kernel: | [qla2300:__insmod_qla2300_S.bss_L22432+2869341/92508739] | xfs_log_mount+0x8d/0xf0 [xfs] | Jul 29 13:44:20 localhost kernel: [] xfs_log_mount+0x8d/0xf0 | [xfs] | Jul 29 13:44:20 localhost kernel: | [qla2300:__insmod_qla2300_S.bss_L22432+2912227/92465853] | xfs_mountfs+0x503/0xf20 [xfs] | Jul 29 13:44:20 localhost kernel: [] xfs_mountfs+0x503/0xf20 | [xfs] | Jul 29 13:44:20 localhost kernel: | [qla2300:__insmod_qla2300_S.bss_L22432+2909972/92468108] | xfs_readsb+0x134/0x1f0 [xfs] | Jul 29 13:44:20 localhost kernel: [] xfs_readsb+0x134/0x1f0 [xfs] | Jul 29 13:44:20 localhost kernel: | [qla2300:__insmod_qla2300_S.bss_L22432+2858466/92519614] | xfs_ioinit+0x42/0x50 [xfs] | Jul 29 13:44:20 localhost kernel: [] xfs_ioinit+0x42/0x50 [xfs] | Jul 29 13:44:20 localhost kernel: | [qla2300:__insmod_qla2300_S.bss_L22432+2947982/92430098] | xfs_mount+0x2ce/0x400 [xfs] | Jul 29 13:44:20 localhost kernel: [] xfs_mount+0x2ce/0x400 [xfs] | Jul 29 13:44:20 localhost kernel: | [qla2300:__insmod_qla2300_S.bss_L22432+3043747/92334333] vfs_mount+0x43/0x50 | [xfs] | Jul 29 13:44:20 localhost kernel: [] vfs_mount+0x43/0x50 [xfs] | Jul 29 13:44:20 localhost kernel: | [qla2300:__insmod_qla2300_S.bss_L22432+3075484/92302596] | xfs_qm_mount+0x4c/0x70 [xfs] | Jul 29 13:44:20 localhost kernel: [] xfs_qm_mount+0x4c/0x70 [xfs] | Jul 29 13:44:20 localhost kernel: | [qla2300:__insmod_qla2300_S.bss_L22432+3043747/92334333] vfs_mount+0x43/0x50 | [xfs] | Jul 29 13:44:20 localhost kernel: [] vfs_mount+0x43/0x50 [xfs] | Jul 29 13:44:20 localhost kernel: | [qla2300:__insmod_qla2300_S.bss_L22432+3042987/92335093] | linvfs_read_super+0x9b/0x1c0 [xfs] | Jul 29 13:44:20 localhost kernel: [] linvfs_read_super+0x9b/0x1c0 | [xfs] | Jul 29 13:44:20 localhost kernel: [kmalloc+75/96] kmalloc+0x4b/0x60 | [kernel] | Jul 29 13:44:20 localhost kernel: [] kmalloc+0x4b/0x60 [kernel] | Jul 29 13:44:20 localhost kernel: [alloc_super+58/432] | alloc_super+0x3a/0x1b0 [kernel] | Jul 29 13:44:20 localhost kernel: [] alloc_super+0x3a/0x1b0 | [kernel] | Jul 29 13:44:20 localhost kernel: [insert_super+100/128] | insert_super+0x64/0x80 [kernel] | Jul 29 13:44:20 localhost kernel: [] insert_super+0x64/0x80 | [kernel] | Jul 29 13:44:20 localhost kernel: [get_sb_bdev+446/752] | get_sb_bdev+0x1be/0x2f0 [kernel] | Jul 29 13:44:20 localhost kernel: [] get_sb_bdev+0x1be/0x2f0 | [kernel] | Jul 29 13:44:20 localhost kernel: | [qla2300:__insmod_qla2300_S.bss_L22432+3160236/92217844] | xfs_fs_type+0x0/0x34 [xfs] | Jul 29 13:44:20 localhost kernel: [] xfs_fs_type+0x0/0x34 [xfs] | Jul 29 13:44:20 localhost kernel: [do_kern_mount+289/320] | do_kern_mount+0x121/0x140 [kernel] | Jul 29 13:44:20 localhost kernel: [] do_kern_mount+0x121/0x140 | [kernel] | Jul 29 13:44:20 localhost kernel: | [qla2300:__insmod_qla2300_S.bss_L22432+3160236/92217844] | xfs_fs_type+0x0/0x34 [xfs] | Jul 29 13:44:20 localhost kernel: [] xfs_fs_type+0x0/0x34 [xfs] | Jul 29 13:44:20 localhost kernel: [do_add_mount+147/400] | do_add_mount+0x93/0x190 [kernel] | Jul 29 13:44:20 localhost kernel: [] do_add_mount+0x93/0x190 | [kernel] | Jul 29 13:44:20 localhost kernel: [do_mount+352/432] do_mount+0x160/0x1b0 | [kernel] | Jul 29 13:44:20 localhost kernel: [] do_mount+0x160/0x1b0 | [kernel] | Jul 29 13:44:20 localhost kernel: [copy_mount_options+121/208] | copy_mount_options+0x79/0xd0 [kernel] | Jul 29 13:44:20 localhost kernel: [] copy_mount_options+0x79/0xd0 | [kernel] | Jul 29 13:44:20 localhost kernel: [sys_mount+215/352] sys_mount+0xd7/0x160 | [kernel] | Jul 29 13:44:20 localhost kernel: [] sys_mount+0xd7/0x160 | [kernel] | Jul 29 13:44:20 localhost kernel: [system_call+51/56] system_call+0x33/0x38 | [kernel] | Jul 29 13:44:20 localhost kernel: [] system_call+0x33/0x38 | [kernel] | Jul 29 13:44:20 localhost kernel: | Jul 29 13:44:20 localhost kernel: XFS: failed to locate log tail | Jul 29 13:44:20 localhost kernel: XFS: log mount/recovery failed | Jul 29 13:44:20 localhost kernel: XFS: log mount failed | Jul 29 13:44:31 localhost kernel: XFS mounting filesystem lvm(58,0) | | | From owner-linux-xfs@oss.sgi.com Wed Jul 30 11:43:43 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 30 Jul 2003 11:43:56 -0700 (PDT) Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.9/8.12.9) with ESMTP id h6UIhhFl026352 for ; Wed, 30 Jul 2003 11:43:43 -0700 Received: (from xfs@localhost) by oss.sgi.com (8.12.9/8.12.8/Submit) id h6UIhhPS026351 for linux-xfs@oss.sgi.com; Wed, 30 Jul 2003 11:43:43 -0700 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.9/8.12.9) with ESMTP id h6UIhgFp026333 for ; Wed, 30 Jul 2003 11:43:42 -0700 Received: (from apache@localhost) by oss.sgi.com (8.12.9/8.12.8/Submit) id h6UIR6tG025081; Wed, 30 Jul 2003 11:27:06 -0700 Date: Wed, 30 Jul 2003 11:27:06 -0700 Message-Id: <200307301827.h6UIR6tG025081@oss.sgi.com> From: bugzilla-daemon@oss.sgi.com To: xfs-master@oss.sgi.com Subject: [Bug 269] XFS Data Corruption on Power Failure(on unclean unmount) X-Bugzilla-Reason: AssignedTo X-archive-position: 4824 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: bugzilla-daemon@oss.sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 317 Lines: 14 http://oss.sgi.com/bugzilla/show_bug.cgi?id=269 ------- Additional Comments From lord@sgi.com 2003-30-07 11:27 PDT ------- New thought, are you running version 2 logs with stripe alignment? ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From owner-linux-xfs@oss.sgi.com Wed Jul 30 11:48:15 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 30 Jul 2003 11:48:26 -0700 (PDT) Received: from smtpzilla5.xs4all.nl (smtpzilla5.xs4all.nl [194.109.127.141]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h6UImEFl027379 for ; Wed, 30 Jul 2003 11:48:15 -0700 Received: from auto-nb1.xs4all.nl (213-84-100-130.adsl.xs4all.nl [213.84.100.130]) by smtpzilla5.xs4all.nl (8.12.9/8.12.9) with ESMTP id h6UImD3m060082; Wed, 30 Jul 2003 20:48:13 +0200 (CEST) Message-Id: <4.3.2.7.2.20030730204531.03df52f0@pop.xs4all.nl> X-Sender: knuffie@pop.xs4all.nl X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 30 Jul 2003 20:47:16 +0200 To: "Cliff Wells" From: Seth Mos Subject: Re: Performance drop in Linux 2.4.19-XFS 1.2 ? Cc: "Ravi Wijayaratne" , linux-xfs@oss.sgi.com In-Reply-To: <1059584649.8920.4209.camel@software1.logiplex.internal> References: <4.3.2.7.2.20030730110055.041a1bc0@pop.xs4all.nl> <4.3.2.7.2.20030730110055.041a1bc0@pop.xs4all.nl> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-archive-position: 4825 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: knuffie@xs4all.nl Precedence: bulk X-list: linux-xfs Content-Length: 1944 Lines: 62 At 10:04 30-7-2003 -0700, Cliff Wells wrote: >On Wed, 2003-07-30 at 02:09, Seth Mos wrote: > > At 18:31 29-7-2003 -0700, Ravi Wijayaratne wrote: > > >Hi, > > > > > >We are seeing a %15 performance drop when we move from XFS 1.1 to 1.2. > > >Here are some of our particulars: > > >We have been testing the performance of Linux-2.4.19 and XFS 1.2 with > > >NetBench. > > >We compared the performance with that of Linux-2.4.18 and XFS 1.1. > > >We have been running Samba 3.0. > > > > The only problem I know of which is not exclusive to XFS (ext3 does > this as > > well) is one on the read performance of 2.4.18 vs the 2.4.20 errata kernel. > > > > On 2.4.18-27 I get 170MB/sec read speed > > on 2.4.20-18 I get 80MB/sec read speed. > > > > the write speed stays consistent between these releases but the enormous > > drop in read speed is very strange. It appears to be present in the > > standard rh errata as well. > >Try hdparm -a 512 /dev/hdx > >http://marc.theaimsgroup.com/?l=linux-kernel&m=105830842018800&w=2 That's IDE. I am talking about scsi. The 3ware controller is just a scsi controller with IDE disks, but the OS doesn't know what disks are behind the raid container. [root@lsnetniet root]# hdparm /dev/sda /dev/sda: readonly = 0 (off) geometry = 45051/255/63, sectors = 723757824, start = 0 [root@lsnetniet root]# hdparm -tT /dev/sda /dev/sda: Timing buffer-cache reads: 128 MB in 0.66 seconds =193.94 MB/sec Timing buffered disk reads: 64 MB in 1.06 seconds = 60.38 MB/sec [root@lsnetniet root]# hdparm -a 512 /dev/sda /dev/sda: setting fs readahead to 512 BLKRASET failed: Invalid argument readahead = 120 (on) [root@lsnetniet root]# uname -a Linux lsnetniet.coltex.nl 2.4.20-18-rh-xfs #2 SMP ma jun 23 11:01:51 CEST 2003 i686 unknown [root@lsnetniet root]# And thus the experiment fails. Any other suggestions :-) Cheers -- Seth It might just be your lucky day, if you only knew. From owner-linux-xfs@oss.sgi.com Wed Jul 30 12:24:30 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 30 Jul 2003 12:24:46 -0700 (PDT) Received: from localhost.fsl.noaa.gov (woody.fsl.noaa.gov [137.75.132.225]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h6UJOHFl030507 for ; Wed, 30 Jul 2003 12:24:30 -0700 Received: from woody.fsl.noaa.gov (localhost [127.0.0.1]) by localhost.fsl.noaa.gov (8.12.5/8.12.5) with ESMTP id h6UJOdnA006406; Wed, 30 Jul 2003 13:24:39 -0600 Received: (from tierney@localhost) by woody.fsl.noaa.gov (8.12.5/8.12.5/Submit) id h6UJOcgG006404; Wed, 30 Jul 2003 13:24:38 -0600 Date: Wed, 30 Jul 2003 13:24:38 -0600 From: Craig Tierney To: Seth Mos Cc: Cliff Wells , Ravi Wijayaratne , linux-xfs@oss.sgi.com Subject: Re: Performance drop in Linux 2.4.19-XFS 1.2 ? Message-ID: <20030730192438.GA6320@hpti.com> References: <4.3.2.7.2.20030730110055.041a1bc0@pop.xs4all.nl> <4.3.2.7.2.20030730110055.041a1bc0@pop.xs4all.nl> <4.3.2.7.2.20030730204531.03df52f0@pop.xs4all.nl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4.3.2.7.2.20030730204531.03df52f0@pop.xs4all.nl> User-Agent: Mutt/1.4i X-archive-position: 4826 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: ctierney@hpti.com Precedence: bulk X-list: linux-xfs Content-Length: 2559 Lines: 86 On Wed, Jul 30, 2003 at 08:47:16PM +0200, Seth Mos wrote: > At 10:04 30-7-2003 -0700, Cliff Wells wrote: > >On Wed, 2003-07-30 at 02:09, Seth Mos wrote: > >> At 18:31 29-7-2003 -0700, Ravi Wijayaratne wrote: > >> >Hi, > >> > > >> >We are seeing a %15 performance drop when we move from XFS 1.1 to 1.2. > >> >Here are some of our particulars: > >> >We have been testing the performance of Linux-2.4.19 and XFS 1.2 with > >> >NetBench. > >> >We compared the performance with that of Linux-2.4.18 and XFS 1.1. > >> >We have been running Samba 3.0. > >> > >> The only problem I know of which is not exclusive to XFS (ext3 does > >this as > >> well) is one on the read performance of 2.4.18 vs the 2.4.20 errata > >kernel. > >> > >> On 2.4.18-27 I get 170MB/sec read speed > >> on 2.4.20-18 I get 80MB/sec read speed. > >> > >> the write speed stays consistent between these releases but the enormous > >> drop in read speed is very strange. It appears to be present in the > >> standard rh errata as well. Sorry if this is a repeat, I haven't seen the whole thread. Did you try increasing the scsi max readahead? echo "511" > /proc/sys/vm/max-readahead echo "127" > /proc/sys/vm/min-readahead This helps on my filesystems with Fibre Channel hardware. However, I have always had this problem. It didn't start with 2.4.20. I don't use Redhat kernels so maybe there is something that changed there. Craig > > > >Try hdparm -a 512 /dev/hdx > > > >http://marc.theaimsgroup.com/?l=linux-kernel&m=105830842018800&w=2 > > That's IDE. I am talking about scsi. The 3ware controller is just a scsi > controller with IDE disks, but the OS doesn't know what disks are behind > the raid container. > > [root@lsnetniet root]# hdparm /dev/sda > > /dev/sda: > readonly = 0 (off) > geometry = 45051/255/63, sectors = 723757824, start = 0 > [root@lsnetniet root]# hdparm -tT /dev/sda > > /dev/sda: > Timing buffer-cache reads: 128 MB in 0.66 seconds =193.94 MB/sec > Timing buffered disk reads: 64 MB in 1.06 seconds = 60.38 MB/sec > [root@lsnetniet root]# hdparm -a 512 /dev/sda > > /dev/sda: > setting fs readahead to 512 > BLKRASET failed: Invalid argument > readahead = 120 (on) > [root@lsnetniet root]# uname -a > Linux lsnetniet.coltex.nl 2.4.20-18-rh-xfs #2 SMP ma jun 23 11:01:51 CEST > 2003 i686 unknown > [root@lsnetniet root]# > > And thus the experiment fails. > > Any other suggestions :-) > > Cheers > > -- > Seth > It might just be your lucky day, if you only knew. > -- Craig Tierney (ctierney@hpti.com) From owner-linux-xfs@oss.sgi.com Wed Jul 30 12:46:31 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 30 Jul 2003 12:46:35 -0700 (PDT) Received: from smtpzilla1.xs4all.nl (smtpzilla1.xs4all.nl [194.109.127.137]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h6UJkUFl032474 for ; Wed, 30 Jul 2003 12:46:31 -0700 Received: from auto-nb1.xs4all.nl (213-84-100-130.adsl.xs4all.nl [213.84.100.130]) by smtpzilla1.xs4all.nl (8.12.9/8.12.9) with ESMTP id h6UJkRaq086204; Wed, 30 Jul 2003 21:46:27 +0200 (CEST) Message-Id: <4.3.2.7.2.20030730213958.03e04578@pop.xs4all.nl> X-Sender: knuffie@pop.xs4all.nl X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 30 Jul 2003 21:43:50 +0200 To: Craig Tierney From: Seth Mos Subject: Re: Performance drop in Linux 2.4.19-XFS 1.2 ? Cc: Cliff Wells , Ravi Wijayaratne , linux-xfs@oss.sgi.com In-Reply-To: <20030730192438.GA6320@hpti.com> References: <4.3.2.7.2.20030730204531.03df52f0@pop.xs4all.nl> <4.3.2.7.2.20030730110055.041a1bc0@pop.xs4all.nl> <4.3.2.7.2.20030730110055.041a1bc0@pop.xs4all.nl> <4.3.2.7.2.20030730204531.03df52f0@pop.xs4all.nl> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-archive-position: 4827 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: knuffie@xs4all.nl Precedence: bulk X-list: linux-xfs Content-Length: 869 Lines: 31 At 13:24 30-7-2003 -0600, Craig Tierney wrote: >Sorry if this is a repeat, I haven't seen the whole >thread. Did you try increasing the scsi max readahead? I found them already since new something like this existed in proc :-) > echo "511" > /proc/sys/vm/max-readahead > echo "127" > /proc/sys/vm/min-readahead I used 512 and 128 but it works! Yay! >This helps on my filesystems with Fibre Channel hardware. >However, I have always had this problem. It didn't start >with 2.4.20. I don't use Redhat kernels so maybe there >is something that changed there. I think one of the defaults got botched during the RedHat errata patching. This isn't the first time they forgot something. I'll try the 1.3pre next and try this as well. If it has the same problem we should get it patched. Cheers -- Seth It might just be your lucky day, if you only knew. From owner-linux-xfs@oss.sgi.com Wed Jul 30 13:17:37 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 30 Jul 2003 13:17:52 -0700 (PDT) Received: from localhost.fsl.noaa.gov (woody.fsl.noaa.gov [137.75.132.225]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h6UKHaFl002866 for ; Wed, 30 Jul 2003 13:17:36 -0700 Received: from woody.fsl.noaa.gov (localhost [127.0.0.1]) by localhost.fsl.noaa.gov (8.12.5/8.12.5) with ESMTP id h6UKHwnA006449; Wed, 30 Jul 2003 14:17:59 -0600 Received: (from tierney@localhost) by woody.fsl.noaa.gov (8.12.5/8.12.5/Submit) id h6UKHw8u006447; Wed, 30 Jul 2003 14:17:58 -0600 Date: Wed, 30 Jul 2003 14:17:58 -0600 From: Craig Tierney To: Seth Mos Cc: Cliff Wells , Ravi Wijayaratne , linux-xfs@oss.sgi.com Subject: Re: Performance drop in Linux 2.4.19-XFS 1.2 ? Message-ID: <20030730201758.GA6411@hpti.com> References: <4.3.2.7.2.20030730204531.03df52f0@pop.xs4all.nl> <4.3.2.7.2.20030730110055.041a1bc0@pop.xs4all.nl> <4.3.2.7.2.20030730110055.041a1bc0@pop.xs4all.nl> <4.3.2.7.2.20030730204531.03df52f0@pop.xs4all.nl> <4.3.2.7.2.20030730213958.03e04578@pop.xs4all.nl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4.3.2.7.2.20030730213958.03e04578@pop.xs4all.nl> User-Agent: Mutt/1.4i X-archive-position: 4828 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: ctierney@hpti.com Precedence: bulk X-list: linux-xfs Content-Length: 551 Lines: 20 On Wed, Jul 30, 2003 at 09:43:50PM +0200, Seth Mos wrote: > At 13:24 30-7-2003 -0600, Craig Tierney wrote: > > >Sorry if this is a repeat, I haven't seen the whole > >thread. Did you try increasing the scsi max readahead? > > I found them already since new something like this existed in proc :-) > > > echo "511" > /proc/sys/vm/max-readahead > > echo "127" > /proc/sys/vm/min-readahead > > I used 512 and 128 but it works! Great. I used 2^n-1 becuase that is how they were set initially (31). Craig Craig Tierney (ctierney@hpti.com) From owner-linux-xfs@oss.sgi.com Wed Jul 30 14:07:34 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 30 Jul 2003 14:07:51 -0700 (PDT) Received: from mx0.gmx.net (mx0.gmx.de [213.165.64.100]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h6UL7WFl006958 for ; Wed, 30 Jul 2003 14:07:33 -0700 Received: (qmail 31527 invoked by uid 0); 30 Jul 2003 21:07:26 -0000 Date: Wed, 30 Jul 2003 23:07:26 +0200 (MEST) From: onedj@gmx.net To: linux-xfs@oss.sgi.com MIME-Version: 1.0 Subject: Need help cannot repair or check XFS filesystem X-Priority: 3 (Normal) X-Authenticated-Sender: #0000482344@gmx.net X-Authenticated-IP: [67.74.149.152] Message-ID: <10794.1059599246@www32.gmx.net> X-Mailer: WWW-Mail 1.6 (Global Message Exchange) X-Flags: 0001 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-archive-position: 4829 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: onedj@gmx.net Precedence: bulk X-list: linux-xfs Content-Length: 3295 Lines: 77 Several days ago my laptop crashed suddenly. Now I am unable to mount, repair, or check /usr/local which is /dev/hda4. The kernel output at boot is: Jul 30 12:48:36 think kernel: Starting XFS recovery on filesystem: ide0(3,4) (dev: 3/4) Jul 30 12:48:36 think kernel: printing eip: Jul 30 12:48:36 think kernel: c01afccf Jul 30 12:48:36 think kernel: Oops: 0000 Jul 30 12:48:36 think kernel: CPU: 0 Jul 30 12:48:36 think kernel: EIP: 0010:[xlog_recover_do_reg_buffer+207/400] Not tain ted Jul 30 12:48:36 think kernel: EFLAGS: 00010202 Jul 30 12:48:36 think kernel: eax: 00000080 ebx: 00000065 ecx: 00000020 edx: d7b131e0 Jul 30 12:48:36 think kernel: esi: 00000000 edi: d7940280 ebp: 00000001 esp: d7123b10 Jul 30 12:48:36 think kernel: ds: 0018 es: 0018 ss: 0018 Jul 30 12:48:36 think kernel: Process mount (pid: 84, stackpage=d7123000) Jul 30 12:48:36 think kernel: Stack: d7081f54 0000000a 00000065 00002205 00001000 0000000a d7081f54 00000003 Jul 30 12:48:36 think kernel: d7081f40 d7683820 00000000 00000000 c01b03da d7917400 d7b131e0 d7683820 Jul 30 12:48:36 think kernel: d7081f40 00002205 d79aeaa0 00000000 d7917400 d7b131e0 00000000 d708cd60 Jul 30 12:48:36 think kernel: Call Trace: [xlog_recover_do_buffer_trans+602/816] [xlog_r ecover_do_trans+372/384] [xlog_recover_commit_trans+63/80] [xlog_recover_process_data+237/5 44] [xlog_do_recovery_pass+566/2368] Jul 30 12:48:36 think kernel: [update_wall_time+22/64] [xlog_do_log_recovery+147/192] [xl og_do_recover+59/352] [xlog_recover+227/256] [xfs_log_mount+141/240] [xfs_mountfs+1293/3808 ] Jul 30 12:48:36 think kernel: [__down_failed+8/12] [xfs_readsb+306/496] [xfs_ioinit+66/80 ] [xfs_mount+718/1024] [vfs_mount+67/80] [linvfs_read_super+155/432] Jul 30 12:48:36 think kernel: [alloc_super+58/368] [get_sb_bdev+407/672] [do_kern_mount+3 81/400] [do_add_mount+147/400] [do_mount+384/480] [copy_mount_options+121/208] Jul 30 12:48:36 think kernel: [sys_mount+207/320] [system_call+51/56] Jul 30 12:48:36 think kernel: Jul 30 12:48:36 think kernel: Code: f3 a5 a8 02 74 02 66 a5 a8 01 74 01 a4 ff 44 24 1c 01 e b e9 If I run xfs_repair or xfs_check on /dev/hda4 they both just freeze immediately with no output whatsoever. xfs_info does give the following output: # xfs_info -t /etc/fstab /usr/local xfs_info: ignoring entry none in /etc/fstab: No such file or directory meta-data=/usr/local isize=256 agcount=8, agsize=103950 blks = sectsz=512 data = bsize=4096 blocks=831600, imaxpct=25 = sunit=0 swidth=0 blks, unwritten=0 naming =version 2 bsize=4096 log =internal bsize=4096 blocks=1200, version=1 = sectsz=512 sunit=0 blks realtime =none extsz=65536 blocks=0, rtextents=0 I am running Debian/Sid Linux 2.4.20 with the Con Kolivas 2.4.20-ck7 xfs patches. The version of xfsprogs is 2.5.3-1. -- COMPUTERBILD 15/03: Premium-e-mail-Dienste im Test -------------------------------------------------- 1. GMX TopMail - Platz 1 und Testsieger! 2. GMX ProMail - Platz 2 und Preis-Qualitätssieger! 3. Arcor - 4. web.de - 5. T-Online - 6. freenet.de - 7. daybyday - 8. e-Post From owner-linux-xfs@oss.sgi.com Wed Jul 30 14:32:14 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 30 Jul 2003 14:32:30 -0700 (PDT) Received: from zok.sgi.com (zok.SGI.COM [204.94.215.101]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h6ULWDFl008909 for ; Wed, 30 Jul 2003 14:32:14 -0700 Received: from flecktone.americas.sgi.com (flecktone.americas.sgi.com [192.48.203.135]) by zok.sgi.com (8.12.9/8.12.9/linux-outbound_gateway-1.1) with ESMTP id h6ULW7q0007914 for ; Wed, 30 Jul 2003 14:32:08 -0700 Received: from maine.americas.sgi.com (maine.americas.sgi.com [128.162.232.87]) by flecktone.americas.sgi.com (8.12.9/8.12.9/generic_config-1.2) with ESMTP id h6ULV7QK3263711; Wed, 30 Jul 2003 16:31:07 -0500 (CDT) Received: from nstraz by maine.americas.sgi.com with local (Exim 3.36 #1 (Debian)) id 19hyXK-0001RL-00; Wed, 30 Jul 2003 16:31:06 -0500 Date: Wed, 30 Jul 2003 16:31:06 -0500 From: Nathan Straz To: onedj@gmx.net Cc: linux-xfs@oss.sgi.com Subject: Re: Need help cannot repair or check XFS filesystem Message-ID: <20030730213106.GB3863@sgi.com> Mail-Followup-To: onedj@gmx.net, linux-xfs@oss.sgi.com References: <10794.1059599246@www32.gmx.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <10794.1059599246@www32.gmx.net> User-Agent: Mutt/1.5.3i X-archive-position: 4830 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: nstraz@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 981 Lines: 22 On Wed, Jul 30, 2003 at 11:07:26PM +0200, onedj@gmx.net wrote: > Several days ago my laptop crashed suddenly. Now I am unable to mount, > repair, or check /usr/local which is /dev/hda4. The kernel output at boot is: > > Jul 30 12:48:36 think kernel: Starting XFS recovery on filesystem: ide0(3,4) [snip] > Jul 30 12:48:36 think kernel: EIP: > 0010:[xlog_recover_do_reg_buffer+207/400] Not tain [snip] > I am running Debian/Sid Linux 2.4.20 with the Con Kolivas 2.4.20-ck7 xfs > patches. The version of xfsprogs is 2.5.3-1. 2.4.20-ck7 sounds like an old release to me. Searching the linux-kernel archives I see that it's based on XFS 1.2. You could try 2.4.21-ck3, but it's only updated to XFS 1.3pre2. If you can try 1.3pre4, that would be better. -- Nate Straz nstraz@sgi.com sgi, inc http://www.sgi.com/ Linux Test Project http://ltp.sf.net/ From owner-linux-xfs@oss.sgi.com Wed Jul 30 15:00:19 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 30 Jul 2003 15:00:36 -0700 (PDT) Received: from av.mvista.com (gateway-1237.mvista.com [12.44.186.158]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h6UM0JFl011207 for ; Wed, 30 Jul 2003 15:00:19 -0700 Received: from mvista.com (av [127.0.0.1]) by av.mvista.com (8.9.3/8.9.3) with ESMTP id PAA16155 for ; Wed, 30 Jul 2003 15:00:13 -0700 Message-ID: <3F283E36.778CC934@mvista.com> Date: Wed, 30 Jul 2003 14:52:54 -0700 From: Blair Barnett Organization: Monta Vista Software, Inc X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.4.18 i686) X-Accept-Language: en MIME-Version: 1.0 To: linux-xfs@oss.sgi.com Subject: different behaviour between XFS and ext3 Content-Type: multipart/mixed; boundary="------------B04E2C7DC45191028C52AC13" X-archive-position: 4831 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: bbarnett@mvista.com Precedence: bulk X-list: linux-xfs Content-Length: 1122 Lines: 45 This is a multi-part message in MIME format. --------------B04E2C7DC45191028C52AC13 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi, I have a simple shell script that writes numbers to a file and every 10 numbers does a sync and after 40 does a reboot. I've attached the script to this email. If the file is written to an EXT3 filesystem, then file contains the numbers 1-40. However, if the file is written to an XFS 1.1,1.2, or 1.3 filesystem, then file contains the numbers 1-10. Can someone tell me if this is a feature of XFS or a bug? Thanks, Blair --------------B04E2C7DC45191028C52AC13 Content-Type: application/x-sh; name="sync.sh" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="sync.sh" #!/bin/sh WRITE_FILE=/mnt/file1 # Removed the old version of the file rm -f $WRITE_FILE for i in `seq 1 100`; do echo $i >> $WRITE_FILE; if [ $(($i % 10)) == 0 ]; then echo $i " sync"; sync; fi if [ $(($i % 40)) == 0 ]; then echo $i " reboot, check " $WRITE_FILE " on reboot ";reboot -f fi done --------------B04E2C7DC45191028C52AC13-- From owner-linux-xfs@oss.sgi.com Wed Jul 30 15:14:27 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 30 Jul 2003 15:14:38 -0700 (PDT) Received: from zok.sgi.com (zok.SGI.COM [204.94.215.101]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h6UMERFl012621 for ; Wed, 30 Jul 2003 15:14:27 -0700 Received: from flecktone.americas.sgi.com (flecktone.americas.sgi.com [192.48.203.135]) by zok.sgi.com (8.12.9/8.12.9/linux-outbound_gateway-1.1) with ESMTP id h6UMELq0022210 for ; Wed, 30 Jul 2003 15:14:21 -0700 Received: from daisy-e236.americas.sgi.com (daisy-e236.americas.sgi.com [128.162.236.214]) by flecktone.americas.sgi.com (8.12.9/8.12.9/generic_config-1.2) with ESMTP id h6UMEIQK3313180; Wed, 30 Jul 2003 17:14:19 -0500 (CDT) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.232.100]) by daisy-e236.americas.sgi.com (8.12.9/SGI-server-1.8) with ESMTP id h6UMEIRn204791852; Wed, 30 Jul 2003 17:14:18 -0500 (CDT) Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id h6UMEIc32504; Wed, 30 Jul 2003 17:14:18 -0500 Subject: re: FW: The infamous BUG in page_buff.c From: Steve Lord To: "HABBINGA,ERIK ""(HP-Loveland,ex1)" Cc: "'linux-xfs@oss.sgi.com'" In-Reply-To: References: Content-Type: text/plain Content-Transfer-Encoding: 7bit Organization: Message-Id: <1059603258.30346.162.camel@jen.americas.sgi.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.4 Date: 30 Jul 2003 17:14:18 -0500 X-archive-position: 4832 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: lord@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 5273 Lines: 149 On Tue, 2003-07-29 at 14:07, HABBINGA,ERIK (HP-Loveland,ex1) wrote: > I just saw the same crash this morning, my first experience with > 2.6.0-test2. > > 4 x Xeon processors > 2 GB ram > fibre channel drives > more details upon request... > > I was running SPEC SFS, so 144 nfs client processes spread across 8 nfs > client machines attached by gigabit ethernet to my server under test. 36 > file systems, and SPEC was trying to write 555 MB to each filesystem as fast > as the NFS/network infrastructure would allow. I'm running stock > 2.6.0-test2 with the qlogic qla2xxx fibre channel driver version 8.00.00b4 > (http://sourceforge.net/projects/linux-qla2xxx/) and the following patch to > the driver code to make the luns visible. > > --- linux/drivers/scsi/qla2xxx/qla_os.c~ Tue Jul 29 08:39:12 2003 > +++ linux/drivers/scsi/qla2xxx/qla_os.c Tue Jul 29 08:38:56 2003 > @@ -2634,6 +2634,7 @@ > qla2x00_cfg_display_devices(); > > scsi_add_host(host, &pdev->dev); > + scsi_scan_host(host); > > return 0; > > Here's the oops/BUG listing. > > Thanks, > Erik Habbinga > Hewlett Packard > > # ------------[ cut here ]------------ > kernel BUG at fs/xfs/pagebuf/page_buf.c:1291! > invalid operand: 0000 [#1] > CPU: 6 > EIP: 0060:[] Not tainted > EFLAGS: 00010202 > EIP is at bio_end_io_pagebuf+0xc2/0x12e > eax: 00000001 ebx: f6fb2380 ecx: 00000000 edx: c185a778 > esi: f060fbc0 edi: 00000000 ebp: ed2bf600 esp: f5f3d9fc > ds: 007b es: 007b ss: 0068 > Process nfsd (pid: 5007, threadinfo=f5f3c000 task=f56e46a0) > Stack: 00000001 00000000 00000046 c26a0a00 00000009 00001000 ed2bf600 > 00000000 > 00000200 00000200 c01562d7 ed2bf600 00000200 00000000 01801b1f > 00000200 > ed2bf600 c0269374 ed2bf600 00000200 00000000 c2654600 ed2bf600 > 00000000 > Call Trace: > [] bio_endio+0x55/0x7a > [] __end_that_request_first+0x204/0x224 > [] scsi_end_request+0x3b/0xbc > [] scsi_io_completion+0x144/0x442 > [] scsi_delete_timer+0x16/0x30 > [] sd_rw_intr+0x4e/0x198 > [] xfs_trans_commit+0x116/0x3d4 > [] xfs_trans_dup+0xed/0xfc > [] xfs_itruncate_finish+0x24d/0x430 > [] xfs_inactive_free_eofblocks+0x26c/0x2ba > [] xfs_rwunlock+0x1/0x3a > [] xfs_release+0x94/0xdc > [] linvfs_release+0x1d/0x24 > [] close_private_file+0x28/0x2a > [] nfsd_close+0x1d/0x3c > [] nfsd_write+0x20d/0x348 > [] udp_push_pending_frames+0x12d/0x244 > [] udp_sendpage+0xf3/0x2a6 > [] svcauth_unix_accept+0x26a/0x28e > [] nfsd_proc_write+0xa8/0x122 > [] nfsd_dispatch+0xe8/0x1e5 > [] nfsd_dispatch+0x0/0x1e5 > [] svc_process+0x4eb/0x673 > [] nfsd+0x1de/0x388 > [] nfsd+0x0/0x388 > [] kernel_thread_helper+0x5/0xc > > Code: 0f 0b 0b 05 4f a6 37 c0 eb a9 89 d0 e8 d3 12 f2 ff eb a0 81 > <0>Kernel panic: Fatal exception in interrupt > In interrupt handler - not syncing > > > > Sorry for the repost > I forgot to cc the list..... > > -----Original Message----- > From: Kostadin Todorov Karaivanov [ ] > Sent: Tuesday, July 29, 2003 10:52 AM > To: 'Nathan Scott' > Subject: RE: The infamous BUG in page_buff.c > > > > -----Original Message----- > > From: Nathan Scott [ ] > > Sent: Tuesday, July 29, 2003 10:19 AM > > To: k.karaivanov@minfin.bg > > Cc: linux-xfs@oss.sgi.com > > Subject: Re: The infamous BUG in page_buff.c > > > > > > On Tue, Jul 29, 2003 at 09:58:42AM +0300, Kostadin Todorov > > Karaivanov wrote: > > > Short summary: > > > I have seen at least 3 reports for , I beleave, same BUG. one of > > > witch is mine. It's present since 2.5.6x till now. I know you are > > > focused on 2.4 branch but still... > > > > > > reference: > > > > > > > > > > > > > > > > A reproducible test case would be a big help here. > > Alas it's not so easy, at least for me. > Sometimes it happens while I sit quietly and do nothing on that PC the > other time it happens when I recompile kernel. To catch my oops I was > forced to make an endless loop of kernel make bzImage; make modules; > make clean on the other hand yesterday I try the same, plus some > postgresql benchmarks > in the background just to higher the load and nothing happened, 2 hours > later when I have given up and stop all the tnings and when I was doing > REALY nothing the machine dies 8-( . > > > > > thanks. > > > > -- > > Nathan > > I hit it for the first time today - and in this case I actually had kgdb in the kernel. So at least I actually know what is going on, now its just a matter of fixing it..... The BUG_ON may actually be bogus, here, but I think we need to forward port some other logic from the 2.4 code. Steve -- Steve Lord voice: +1-651-683-3511 Principal Engineer, Filesystem Software email: lord@sgi.com From owner-linux-xfs@oss.sgi.com Wed Jul 30 15:39:05 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 30 Jul 2003 15:39:19 -0700 (PDT) Received: from zok.sgi.com (zok.SGI.COM [204.94.215.101]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h6UMd4Fl014751 for ; Wed, 30 Jul 2003 15:39:05 -0700 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.54.149]) by zok.sgi.com (8.12.9/8.12.9/linux-outbound_gateway-1.1) with ESMTP id h6UMcwq0030391 for ; Wed, 30 Jul 2003 15:38:59 -0700 Received: from snort.melbourne.sgi.com (localhost [127.0.0.1]) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id h6UMcvJA7712078; Thu, 31 Jul 2003 08:38:57 +1000 (EST) Received: (from nathans@localhost) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id h6UMctLg7722589; Thu, 31 Jul 2003 08:38:55 +1000 (EST) Date: Thu, 31 Jul 2003 08:38:55 +1000 (EST) From: Nathan Scott Message-Id: <200307302238.h6UMctLg7722589@snort.melbourne.sgi.com> To: linux-xfs@oss.sgi.com, agruen@suse.de Subject: TAKE - add missing acl files X-archive-position: 4833 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: nathans@snort.melbourne.sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 431 Lines: 16 Integrate libmisc files which patch decided to put in acl/empty for some reason. Date: Wed Jul 30 15:37:53 PDT 2003 Workarea: snort.melbourne.sgi.com:/home/nathans/2.5.x-xfs The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.5.x-xfs Modid: xfs-cmds:slinx:154625a cmd/acl/libmisc/unquote.c - 1.2 cmd/acl/libmisc/quote.c - 1.2 cmd/acl/libmisc/high_water_alloc.c - 1.2 cmd/acl/libmisc/Makefile - 1.2 From owner-linux-xfs@oss.sgi.com Wed Jul 30 16:35:50 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 30 Jul 2003 16:36:05 -0700 (PDT) Received: from ams004.ftl.affinity.com (lvs00-fl.valueweb.net [216.219.253.199]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h6UNZnFl020534 for ; Wed, 30 Jul 2003 16:35:50 -0700 Received: from david.internal.NorcrossGroup.com ([66.156.0.142]) by ams.ftl.affinity.com with ESMTP id <213402-21319>; Wed, 30 Jul 2003 19:34:42 -0400 Subject: Re: Data Corruption Problem From: Greg Freemyer Reply-To: freemyer-ml@NorcrossGroup.com To: Wendy Cheng Cc: Aman Shahi , linux-xfs@oss.sgi.com In-Reply-To: References: Content-Type: text/plain Organization: Message-Id: <1059629044.12756.2929.camel@david.internal.NorcrossGroup.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.3 Date: 31 Jul 2003 01:24:04 -0400 Content-Transfer-Encoding: 7bit X-archive-position: 4834 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: freemyer-ml@NorcrossGroup.com Precedence: bulk X-list: linux-xfs Content-Length: 1123 Lines: 29 On Wed, 2003-07-30 at 13:22, Wendy Cheng wrote: > Linux XFS is not a cluster file system - implies that during a failover, > the file system's buffer cache is lost (together with the faulty machine). > Even the second machine can pick up the follow-on workload, there > are possibilities that data could get lost (or corrupted) unless you mount > them with "sync" option. All the journaling file system (such as XFS) > could do is to ensure file system's meta data is kept on a consistent > state but sometimes the journal data could get screwed up too. > > You ask too much for a free software :)- > > Wendy > ------- I disagree, if Aman has a ligitimate XFS bug, then the exact same thing will happen on a non-clustered server which simply is put through a series of un-clean shutdowns. It is well known that XFS may lose the contents of a file in this scenario, but it should not corrupt the actual filesystem. OTOH, I have not seen any reports of XFS problems like Aman's previously, so I expect his problem relates to other parts of the FS stack. i.e. His storage server or LVM usage. Greg -- Greg Freemyer From owner-linux-xfs@oss.sgi.com Wed Jul 30 19:47:18 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 30 Jul 2003 19:47:36 -0700 (PDT) Received: from corpmail.outblaze.com ([210.177.227.131]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h6V2lHFl003117 for ; Wed, 30 Jul 2003 19:47:18 -0700 Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by corpmail.outblaze.com (Postfix) with ESMTP id 6D60437AD5 for ; Thu, 31 Jul 2003 02:47:15 +0000 (GMT) Received: from yusufg.portal2.com (unknown [210.177.227.130]) by corpmail.outblaze.com (Postfix) with SMTP id 3C4C716DD85 for ; Thu, 31 Jul 2003 02:47:15 +0000 (GMT) Received: (qmail 24734 invoked by uid 500); 31 Jul 2003 02:43:37 -0000 Date: Thu, 31 Jul 2003 10:43:37 +0800 From: Yusuf Goolamabbas To: linux-xfs@oss.sgi.com Subject: [wietse@porcupine.org: Re: XFS semantics for postfix queues] Message-ID: <20030731024337.GA24713@outblaze.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4i X-AntiVirus: checked by Vexira MailArmor (version: 2.0.1.11; VAE: 6.20.0.1; VDF: 6.20.0.50; host: corpmail.outblaze.com) X-archive-position: 4835 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: yusufg@outblaze.com Precedence: bulk X-list: linux-xfs Content-Length: 2985 Lines: 87 Wietse's response to Steve Lord's reply ----- Forwarded message from Wietse Venema ----- Subject: Re: XFS semantics for postfix queues To: Yusuf Goolamabbas Date: Wed, 30 Jul 2003 22:02:36 -0400 (EDT) Cc: postfix-users@postfix.org From: wietse@porcupine.org (Wietse Venema) Postfix requires that fsync() updates the directory AND file before it returns. Postfix with maildir also requires that link() completes all updates before it returns. Postfix requires that rename() updates directories safely so that one instance of the file will always exist, even if the system should crash in the middle of the operation. With old ext2fs the file could end up in lost+found, this is not acceptable. The text below does not confirm that rename()/link() work as required. It would be incorrect to assume that every rename()/link() operation is followed by fsync(). Wietse Yusuf Goolamabbas: > I asked on the XFS list whether XFS offered the appropiate semantics > (similar to ffs/softupdate and ext3 (ordered,data=journal) to be > reliable as a postfix queue. This is Steve Lord's (XFS lead) response > > Wietse, any comments ? Does it satisfy your criterion for the right > semantics > > ----- Forwarded message from Steve Lord ----- > > Subject: Re: Does XFS do the right thing for MTA queues > From: Steve Lord > To: Yusuf Goolamabbas > Cc: linux-xfs@oss.sgi.com > > On Tue, 2003-07-29 at 23:25, Yusuf Goolamabbas wrote: > > In general, MTA's like (qmail/postfix) and their authors assume the > > BSD ffs/softupdates semantics that fsync on a file also syncs the > > directory metadata (I think they want link/rename to be > > synchronous). This semantic is also provided by ext3 in 2 of its modes > > (ordered,data=journal). My question is > > > > a) Does XFS provide similar semantics which would make it reliable as > > a filesystem for MTA queue ? > > If you do fsync on a file then the log will get pushed to disk - at > least upto the last transaction involving the inode you do fsync on. > This means that any transaction prior to that (such as a rename or > a link call) is also flushed to disk. So fsync does the right thing. > > > b) Are there any mount options which one has to enable this behaviour > > ? > > Nope. If you are really paranoid, the wsync mount option makes almost > all transactions synchronous. > > > Also, what's the version of XFS in the Alan Cox 2.4.22-pre6-ac1 kernel > > > > It is somewhat long in the tooth now, and probably has some issues > with the O_DIRECT path. > > Steve > ----- End forwarded message ----- > > -- > If you're not using Firebird, you're not surfing the web > you're suffering it > http://www.mozilla.org/products/firebird/why/ > > ----- End forwarded message ----- -- If you're not using Firebird, you're not surfing the web you're suffering it http://www.mozilla.org/products/firebird/why/ From owner-linux-xfs@oss.sgi.com Wed Jul 30 20:21:57 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 30 Jul 2003 20:22:14 -0700 (PDT) Received: from zok.sgi.com (zok.SGI.COM [204.94.215.101]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h6V3LvFl005768 for ; Wed, 30 Jul 2003 20:21:57 -0700 Received: from flecktone.americas.sgi.com (flecktone.americas.sgi.com [192.48.203.135]) by zok.sgi.com (8.12.9/8.12.9/linux-outbound_gateway-1.1) with ESMTP id h6V3Lpq0029705 for ; Wed, 30 Jul 2003 20:21:51 -0700 Received: from daisy-e236.americas.sgi.com (daisy-e236.americas.sgi.com [128.162.236.214]) by flecktone.americas.sgi.com (8.12.9/8.12.9/generic_config-1.2) with ESMTP id h6V3KpQK3391123; Wed, 30 Jul 2003 22:20:51 -0500 (CDT) Received: from [192.168.1.100] (cf-vpn-sw-corp-64-46.corp.sgi.com [134.15.64.46]) by daisy-e236.americas.sgi.com (8.12.9/SGI-server-1.8) with ESMTP id h6V3KnRn162569446; Wed, 30 Jul 2003 22:20:50 -0500 (CDT) Subject: Re: [wietse@porcupine.org: Re: XFS semantics for postfix queues] From: Steve Lord To: Yusuf Goolamabbas Cc: linux-xfs@oss.sgi.com In-Reply-To: <20030731024337.GA24713@outblaze.com> References: <20030731024337.GA24713@outblaze.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.8 (1.0.8-11) Date: 30 Jul 2003 22:21:01 -0500 Message-Id: <1059621663.1907.39.camel@laptop.americas.sgi.com> Mime-Version: 1.0 X-archive-position: 4836 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: lord@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 1936 Lines: 55 On Wed, 2003-07-30 at 21:43, Yusuf Goolamabbas wrote: > Wietse's response to Steve Lord's reply Comments below, but why someone has to relay stuff back and forth like this I have no idea. > > ----- Forwarded message from Wietse Venema ----- > > Subject: Re: XFS semantics for postfix queues > To: Yusuf Goolamabbas > Date: Wed, 30 Jul 2003 22:02:36 -0400 (EDT) > Cc: postfix-users@postfix.org > From: wietse@porcupine.org (Wietse Venema) > > Postfix requires that fsync() updates the directory AND file before > it returns. Postfix seems to be a very demanding program ;-) > > Postfix with maildir also requires that link() completes all updates > before it returns. > > Postfix requires that rename() updates directories safely so that > one instance of the file will always exist, even if the system > should crash in the middle of the operation. With old ext2fs the > file could end up in lost+found, this is not acceptable. > The way to think about the xfs transaction system is that time rolls backwards after a crash. A file being renamed will either be in its old location or the new one - it will not be MIA. And if you perform a sequence of operations on a file one after another, then after a crash you will get ALL of the operations upto some point, and none of the ones after that point. If you want to know that something is on disk and safe from crash then: o fsync on a file will flush the log upto at least the last transaction involving that file - from the above, this means a rename would be safe on disk. o fsync on a dir will work too. > The text below does not confirm that rename()/link() work as > required. It would be incorrect to assume that every rename()/link() > operation is followed by fsync(). Hmm, and the question I was asked was not this question, but never mind. I am pretty sure XFS is doing all the right things here. Steve From owner-linux-xfs@oss.sgi.com Wed Jul 30 20:37:05 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 30 Jul 2003 20:37:10 -0700 (PDT) Received: from corpmail.outblaze.com ([210.177.227.131]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h6V3b2Fl007171 for ; Wed, 30 Jul 2003 20:37:04 -0700 Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by corpmail.outblaze.com (Postfix) with ESMTP id 730EE37AD5 for ; Thu, 31 Jul 2003 03:37:01 +0000 (GMT) Received: from yusufg.portal2.com (unknown [210.177.227.130]) by corpmail.outblaze.com (Postfix) with SMTP id 1D00716DD85 for ; Thu, 31 Jul 2003 03:37:01 +0000 (GMT) Received: (qmail 25184 invoked by uid 500); 31 Jul 2003 03:33:22 -0000 Date: Thu, 31 Jul 2003 11:33:22 +0800 From: Yusuf Goolamabbas To: linux-xfs@oss.sgi.com Subject: Re: [wietse@porcupine.org: Re: XFS semantics for postfix queues] Message-ID: <20030731033322.GA25163@outblaze.com> References: <20030731024337.GA24713@outblaze.com> <1059621663.1907.39.camel@laptop.americas.sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1059621663.1907.39.camel@laptop.americas.sgi.com> User-Agent: Mutt/1.4i X-AntiVirus: checked by Vexira MailArmor (version: 2.0.1.11; VAE: 6.20.0.1; VDF: 6.20.0.50; host: corpmail.outblaze.com) X-archive-position: 4837 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: yusufg@outblaze.com Precedence: bulk X-list: linux-xfs Content-Length: 1487 Lines: 40 > Comments below, but why someone has to relay stuff back and forth like > this I have no idea. Sorry, I thought of cross-posting to both lists but didn't do it > > Postfix requires that fsync() updates the directory AND file before > > it returns. > > Postfix seems to be a very demanding program ;-) You bet :) > The way to think about the xfs transaction system is that time rolls > backwards after a crash. A file being renamed will either be in its > old location or the new one - it will not be MIA. And if you perform > a sequence of operations on a file one after another, then after a > crash you will get ALL of the operations upto some point, and none of > the ones after that point. If you want to know that something is on > disk and safe from crash then: > > o fsync on a file will flush the log upto at least the last transaction > involving that file - from the above, this means a rename would be > safe on disk. > > o fsync on a dir will work too. BTW, Wietse like all other MTA authors does not do fsync on a dir, he assumes that fsync on a file will fsync the containing dir > > The text below does not confirm that rename()/link() work as > > required. It would be incorrect to assume that every rename()/link() > > operation is followed by fsync(). > > Hmm, and the question I was asked was not this question, but never mind. > I am pretty sure XFS is doing all the right things here. My apologies for asking the wrong question Regards, Yusuf From owner-linux-xfs@oss.sgi.com Thu Jul 31 01:09:38 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 31 Jul 2003 01:09:40 -0700 (PDT) Received: from pechkin.minfin.bg (pechkin.minfin.bg [212.122.164.10]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h6V89aFl026000 for ; Thu, 31 Jul 2003 01:09:37 -0700 Received: (qmail 6794 invoked by uid 64014); 31 Jul 2003 08:09:32 -0000 Received: from larry@minfin.bg by mail.minfin.bg by uid 64011 with qmail-scanner-1.15 (fsecure: 4.14/4062/ Clear:. Processed in 1.141216 secs); 31 Jul 2003 08:09:32 -0000 Received: from unknown (HELO larry2) (10.40.1.15) by pechkin.minfin.bg with SMTP; 31 Jul 2003 08:09:30 -0000 Reply-To: From: "Kostadin Todorov Karaivanov" To: Subject: RE: FW: The infamous BUG in page_buff.c Date: Thu, 31 Jul 2003 11:09:37 +0300 Organization: Ministry of Finance Message-ID: <018e01c3573b$159cf240$0f01280a@minfin.bg> MIME-Version: 1.0 Content-Type: text/plain; charset="koi8-r" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2627 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 In-Reply-To: <1059603258.30346.162.camel@jen.americas.sgi.com> Importance: Normal X-archive-position: 4839 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: larry@minfin.bg Precedence: bulk X-list: linux-xfs Content-Length: 544 Lines: 20 I hit it for the first time today - and in this case I actually had kgdb in the kernel. So at least I actually know what is going on, now its just a matter of fixing it..... The BUG_ON may actually be bogus, here, but I think we need to forward port some other logic from the 2.4 code. Steve -- Steve Lord voice: +1-651-683-3511 Principal Engineer, Filesystem Software email: lord@sgi.com So all we need is a little patience :-)) Thanks Steve, we shall wait (for 2.6.0-test3). wwell Larry From owner-linux-xfs@oss.sgi.com Thu Jul 31 01:08:23 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 31 Jul 2003 01:08:45 -0700 (PDT) Received: from khe-mailhub1.eigner.com (khe-mailhub1.eigner.com [194.120.231.246]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h6V88MFl025775 for ; Thu, 31 Jul 2003 01:08:23 -0700 Received: from eigner.com (unknown [194.120.231.18]) by khe-mailhub1.eigner.com (Postfix) with ESMTP id 5F6592CB; Thu, 31 Jul 2003 10:08:00 +0200 (CEST) Message-ID: <3F28CE63.80005@eigner.com> Date: Thu, 31 Jul 2003 10:08:03 +0200 From: Klaus Strebel Organization: EIGNER Germany GmbH User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: de, en, de-de, en-us MIME-Version: 1.0 To: Blair Barnett , linux-xfs@oss.sgi.com Subject: Re: different behaviour between XFS and ext3 References: <3F283E36.778CC934@mvista.com> In-Reply-To: <3F283E36.778CC934@mvista.com> Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 8bit X-MailScanner-Information: Please contact the ISP for more information X-MailScanner: Found to be clean X-MailScanner-SpamCheck: not spam (whitelisted), SpamAssassin (score=-102.6, required 5, EMAIL_ATTRIBUTION -0.50, IN_REP_TO -0.50, QUOTED_EMAIL_TEXT -0.48, REFERENCES -0.50, REPLY_WITH_QUOTES -0.50, USER_AGENT_MOZILLA_UA 0.00, USER_IN_WHITELIST -100.00, X_ACCEPT_LANG -0.10) X-archive-position: 4838 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: klaus.strebel@eigner.com Precedence: bulk X-list: linux-xfs Content-Length: 2239 Lines: 60 Blair Barnett wrote: > Hi, > > I have a simple shell script that writes numbers to a file and every 10 > numbers does a sync and after 40 does a reboot. I've attached the script > to this email. > > If the file is written to an EXT3 filesystem, then file contains the > numbers 1-40. However, if the file is written to an XFS 1.1,1.2, or 1.3 > filesystem, then file contains the numbers 1-10. > > Can someone tell me if this is a feature of XFS or a bug? Hi Blair, your in danger do get flamed ;-) though: The man-page of mount states in the options for ext3: data=journal / data=ordered / data=writeback Specifies the journalling mode for file data. Metadata is always journaled. journal All data is committed into the journal prior to being written into the main file system. ordered This is the default mode. All data is forced directly out to the main file system prior to its metadata being committed to the journal. writeback Data ordering is not preserved - data may be written into the main file system after its metadata has been committed to the journal. This is rumoured to be the highest-through­ put option. It guarantees internal file system integrity, however it can allow old data to appear in files after a crash and journal recovery. So, your ext3 does a data=ordered (if you didn't change it, obviously you didn't, you would have known the man-page ;-) ), while xfs's behaviour is more like data=writeback. In special circumstances this can even lead to data loss on xfs (see a thread in linux-xfs@oss.sgi.com, metadata is written, extents for the file are zeroed out but data's not written to, well should almost never happen in actual CVS kernel ;-)). Cheers Klaus -- Klaus Strebel UNIX-Engineer klaus.strebel@eigner.com EIGNER - Precision Lifecycle Management - From owner-linux-xfs@oss.sgi.com Thu Jul 31 01:54:07 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 31 Jul 2003 01:54:20 -0700 (PDT) Received: from batleth.sapienti-sat.org (batleth.sapienti-sat.org [80.190.100.240]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h6V8s5Fl029734 for ; Thu, 31 Jul 2003 01:54:06 -0700 Received: from localhost (localhost.sapienti-sat.org [127.0.0.1]) by batleth.sapienti-sat.org (Postfix) with SMTP id 5CE1310258A for ; Thu, 31 Jul 2003 10:54:04 +0200 (CEST) Received: from nx-01.sapienti-sat.org (pD9E7D801.dip.t-dialin.net [217.231.216.1]) by batleth.sapienti-sat.org (Postfix) with ESMTP id 0E9A5100724 for ; Thu, 31 Jul 2003 10:54:04 +0200 (CEST) Received: from localhost (localhost.sapienti-sat.org [127.0.0.1]) by nx-01.sapienti-sat.org (Postfix) with SMTP id DBC4140836 for ; Thu, 31 Jul 2003 10:54:01 +0200 (CEST) Received: from koschikode.com (pktomo.sapienti-sat.org [192.168.200.10]) by nx-01.sapienti-sat.org (Postfix) with ESMTP id BD8004082B for ; Thu, 31 Jul 2003 10:54:01 +0200 (CEST) Message-ID: <3F28D929.1030807@koschikode.com> Date: Thu, 31 Jul 2003 10:54:01 +0200 From: Juri Haberland User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3.1) Gecko/20030425 X-Accept-Language: en-us, de-de, en MIME-Version: 1.0 To: linux-xfs@oss.sgi.com Subject: Re: different behaviour between XFS and ext3 References: <3F283E36.778CC934@mvista.com> <3F28CE63.80005@eigner.com> In-Reply-To: <3F28CE63.80005@eigner.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-archive-position: 4840 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: juri@koschikode.com Precedence: bulk X-list: linux-xfs Content-Length: 1284 Lines: 34 Klaus Strebel wrote: > Blair Barnett wrote: >> I have a simple shell script that writes numbers to a file and every 10 >> numbers does a sync and after 40 does a reboot. I've attached the script >> to this email. >> >> If the file is written to an EXT3 filesystem, then file contains the >> numbers 1-40. However, if the file is written to an XFS 1.1,1.2, or 1.3 >> filesystem, then file contains the numbers 1-10. >> >> Can someone tell me if this is a feature of XFS or a bug? > your in danger do get flamed ;-) though: > > The man-page of mount states in the options for ext3: [snip] > So, your ext3 does a data=ordered (if you didn't change it, obviously > you didn't, you would have known the man-page ;-) ), while xfs's > behaviour is more like data=writeback. In special circumstances this can > even lead to data loss on xfs (see a thread in linux-xfs@oss.sgi.com, > metadata is written, extents for the file are zeroed out but data's not > written to, well should almost never happen in actual CVS kernel ;-)). What buffles me a bit is that he does a "reboot -f" and, according to the man page on my RedHat 7.3 system, reboot should sync the filesystems prior to reboot. If he'd done a "reboot -fn" (-n = don't sync) then I'd expect this, though. Cheers, Juri From owner-linux-xfs@oss.sgi.com Thu Jul 31 02:18:49 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 31 Jul 2003 02:19:07 -0700 (PDT) Received: from goliath.sylaba.poznan.pl (goliath.sylaba.poznan.pl [195.216.104.3]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h6V9IjFl031512 for ; Thu, 31 Jul 2003 02:18:48 -0700 Received: by goliath.sylaba.poznan.pl (Postfix, from userid 1003) id 0F343943AA; Thu, 31 Jul 2003 11:18:43 +0200 (CEST) Received: from venus.local.navi.pl (ps103.poznan.sdi.tpnet.pl [217.97.72.103]) by goliath.sylaba.poznan.pl (Postfix) with ESMTP id AEA4A94308 for ; Thu, 31 Jul 2003 11:18:42 +0200 (CEST) Received: from venus.local.navi.pl (venus.local.navi.pl [127.0.0.1]) by venus.local.navi.pl (8.12.5/8.12.5) with ESMTP id h6V9JgIS009900 for ; Thu, 31 Jul 2003 11:19:42 +0200 Subject: Re: different behaviour between XFS and ext3 From: Olaf =?iso-8859-2?Q?Fr=B1czyk?= To: linux-xfs@oss.sgi.com In-Reply-To: <3F28D929.1030807@koschikode.com> References: <3F283E36.778CC934@mvista.com> <3F28CE63.80005@eigner.com> <3F28D929.1030807@koschikode.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.8 (1.0.8-10) Date: 31 Jul 2003 11:19:42 +0200 Message-Id: <1059643182.9438.8.camel@venus> Mime-Version: 1.0 X-archive-position: 4841 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: olaf@cbk.poznan.pl Precedence: bulk X-list: linux-xfs Content-Length: 1013 Lines: 29 On Thu, 2003-07-31 at 10:54, Juri Haberland wrote: > Klaus Strebel wrote: > > Blair Barnett wrote: > > >> I have a simple shell script that writes numbers to a file and every 10 > >> numbers does a sync and after 40 does a reboot. I've attached the script > >> to this email. > >> > >> If the file is written to an EXT3 filesystem, then file contains the > >> numbers 1-40. However, if the file is written to an XFS 1.1,1.2, or 1.3 > >> filesystem, then file contains the numbers 1-10. > [snip] > What buffles me a bit is that he does a "reboot -f" and, according to the > man page on my RedHat 7.3 system, reboot should sync the filesystems > prior to reboot. If he'd done a "reboot -fn" (-n = don't sync) then I'd > expect this, though. > Hi, It is even worse. He does sync after write of every 10 numbers. So after writing 40 he does sync (!) and afterward he reboots. So after next booting he should see this "40", and it shouldn't be dependent if it does sync on reboot or not. Regards, Olaf Fraczyk From owner-linux-xfs@oss.sgi.com Thu Jul 31 02:37:26 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 31 Jul 2003 02:37:44 -0700 (PDT) Received: from mx-01-bsl.sauter-bc.com (mx-01-bsl.sauter-bc.com [213.173.165.132]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h6V9bOFl001037 for ; Thu, 31 Jul 2003 02:37:25 -0700 Received: from mailhub.ch.sauter-bc.com (mailhub [10.1.6.26]) by mx-01-bsl.sauter-bc.com (Postfix) with ESMTP id ECB474E250; Thu, 31 Jul 2003 11:37:17 +0200 (CEST) Received: from ch.sauter-bc.com (sup.ch.sauter-bc.com [10.1.200.117]) by mailhub.ch.sauter-bc.com (Postfix) with ESMTP id 5A5F232CD7; Thu, 31 Jul 2003 11:37:17 +0200 (CEST) Message-ID: <3F28E34D.3EE2CF4A@ch.sauter-bc.com> Date: Thu, 31 Jul 2003 11:37:17 +0200 From: Simon Matter Organization: Sauter AG, Basel X-Mailer: Mozilla 4.77 [de] (X11; U; Linux 2.2.24-6.2.3 i686) X-Accept-Language: de-CH, de, en-US, en MIME-Version: 1.0 To: Blair Barnett Cc: linux-xfs@oss.sgi.com Subject: Re: different behaviour between XFS and ext3 References: <3F283E36.778CC934@mvista.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-archive-position: 4842 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: simon.matter@ch.sauter-bc.com Precedence: bulk X-list: linux-xfs Content-Length: 754 Lines: 28 Blair Barnett schrieb: > > Hi, > > I have a simple shell script that writes numbers to a file and every 10 > numbers does a sync and after 40 does a reboot. I've attached the script > to this email. > > If the file is written to an EXT3 filesystem, then file contains the > numbers 1-40. However, if the file is written to an XFS 1.1,1.2, or 1.3 > filesystem, then file contains the numbers 1-10. What kind of Linux distribution and kernel are you using? Simon > > Can someone tell me if this is a feature of XFS or a bug? > > Thanks, > > Blair > > ------------------------------------------------------------------------ > Name: sync.sh > sync.sh Type: Bourne Shell Program (application/x-sh) > Encoding: 7bit From owner-linux-xfs@oss.sgi.com Thu Jul 31 03:01:36 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 31 Jul 2003 03:01:42 -0700 (PDT) Received: from goliath.sylaba.poznan.pl (goliath.sylaba.poznan.pl [195.216.104.3]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h6VA1PFl004417 for ; Thu, 31 Jul 2003 03:01:26 -0700 Received: by goliath.sylaba.poznan.pl (Postfix, from userid 1003) id 778B2943C3; Thu, 31 Jul 2003 11:20:52 +0200 (CEST) Received: from venus.local.navi.pl (ps103.poznan.sdi.tpnet.pl [217.97.72.103]) by goliath.sylaba.poznan.pl (Postfix) with ESMTP id B883294340 for ; Thu, 31 Jul 2003 11:20:51 +0200 (CEST) Received: from venus.local.navi.pl (venus.local.navi.pl [127.0.0.1]) by venus.local.navi.pl (8.12.5/8.12.5) with ESMTP id h6V9LpIS009917 for ; Thu, 31 Jul 2003 11:21:51 +0200 Subject: Re: different behaviour between XFS and ext3 From: Olaf =?iso-8859-2?Q?Fr=B1czyk?= To: linux-xfs@oss.sgi.com In-Reply-To: <3F283E36.778CC934@mvista.com> References: <3F283E36.778CC934@mvista.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.8 (1.0.8-10) Date: 31 Jul 2003 11:21:51 +0200 Message-Id: <1059643311.9438.11.camel@venus> Mime-Version: 1.0 X-archive-position: 4843 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: olaf@cbk.poznan.pl Precedence: bulk X-list: linux-xfs Content-Length: 587 Lines: 22 On Wed, 2003-07-30 at 23:52, Blair Barnett wrote: > Hi, > > I have a simple shell script that writes numbers to a file and every 10 > numbers does a sync and after 40 does a reboot. I've attached the script > to this email. > > If the file is written to an EXT3 filesystem, then file contains the > numbers 1-40. However, if the file is written to an XFS 1.1,1.2, or 1.3 > filesystem, then file contains the numbers 1-10. > > Can someone tell me if this is a feature of XFS or a bug? > Hi, If after sync you don't see data, it looks like a big bug for me. Regards, Olaf Fraczyk From owner-linux-xfs@oss.sgi.com Thu Jul 31 06:03:11 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 31 Jul 2003 06:03:32 -0700 (PDT) Received: from pechkin.minfin.bg (pechkin.minfin.bg [212.122.164.10]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h6VD38Fl018008 for ; Thu, 31 Jul 2003 06:03:10 -0700 Received: (qmail 1875 invoked by uid 64014); 31 Jul 2003 13:03:06 -0000 Received: from larry@minfin.bg by mail.minfin.bg by uid 64011 with qmail-scanner-1.15 (fsecure: 4.14/4062/ Clear:. Processed in 1.13289 secs); 31 Jul 2003 13:03:06 -0000 Received: from unknown (HELO larry2) (10.40.1.15) by pechkin.minfin.bg with SMTP; 31 Jul 2003 13:03:04 -0000 Reply-To: From: "Kostadin Todorov Karaivanov" To: "'Nathan Scott'" Cc: Subject: RE: TAKE - add missing acl files Date: Thu, 31 Jul 2003 16:03:11 +0300 Organization: Ministry of Finance Message-ID: <01a001c35764$18616cd0$0f01280a@minfin.bg> MIME-Version: 1.0 Content-Type: text/plain; charset="koi8-r" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2627 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 In-Reply-To: <200307302238.h6UMctLg7722589@snort.melbourne.sgi.com> Importance: Normal X-archive-position: 4844 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: larry@minfin.bg Precedence: bulk X-list: linux-xfs Content-Length: 909 Lines: 37 acl/libmisc/Makefile is empty acl as a whole don't compile Kostadin Karaivanov Senior System Administrator @ Ministry Of Finance tel: +359 2 98592062 k.karaivanov@minfin.bg > -----Original Message----- > From: linux-xfs-bounce@oss.sgi.com > [mailto:linux-xfs-bounce@oss.sgi.com] On Behalf Of Nathan Scott > Sent: Thursday, July 31, 2003 1:39 AM > To: linux-xfs@oss.sgi.com; agruen@suse.de > Subject: TAKE - add missing acl files > > > Integrate libmisc files which patch decided to put in acl/empty > for some reason. > > Date: Wed Jul 30 15:37:53 PDT 2003 > Workarea: snort.melbourne.sgi.com:/home/nathans/2.5.x-xfs > > The following file(s) were checked into: > bonnie.engr.sgi.com:/isms/slinx/2.5.x-xfs > > > Modid: xfs-cmds:slinx:154625a > cmd/acl/libmisc/unquote.c - 1.2 > cmd/acl/libmisc/quote.c - 1.2 > cmd/acl/libmisc/high_water_alloc.c - 1.2 > cmd/acl/libmisc/Makefile - 1.2 > > From owner-linux-xfs@oss.sgi.com Thu Jul 31 06:16:12 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 31 Jul 2003 06:16:34 -0700 (PDT) Received: from smtpzilla1.xs4all.nl (smtpzilla1.xs4all.nl [194.109.127.137]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h6VDG8Fl019451 for ; Thu, 31 Jul 2003 06:16:12 -0700 Received: from auto-nb1.xs4all.nl (coltex.xs4all.nl [213.84.127.28]) by smtpzilla1.xs4all.nl (8.12.9/8.12.9) with ESMTP id h6VDG6qV071082; Thu, 31 Jul 2003 15:16:06 +0200 (CEST) Message-Id: <4.3.2.7.2.20030731150836.0243ddb8@pop.xs4all.nl> X-Sender: knuffie@pop.xs4all.nl X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 31 Jul 2003 15:16:03 +0200 To: Craig Tierney From: Seth Mos Subject: Re: Performance drop in Linux 2.4.19-XFS 1.2 ? Cc: Cliff Wells , Ravi Wijayaratne , linux-xfs@oss.sgi.com In-Reply-To: <20030730201758.GA6411@hpti.com> References: <4.3.2.7.2.20030730213958.03e04578@pop.xs4all.nl> <4.3.2.7.2.20030730204531.03df52f0@pop.xs4all.nl> <4.3.2.7.2.20030730110055.041a1bc0@pop.xs4all.nl> <4.3.2.7.2.20030730110055.041a1bc0@pop.xs4all.nl> <4.3.2.7.2.20030730204531.03df52f0@pop.xs4all.nl> <4.3.2.7.2.20030730213958.03e04578@pop.xs4all.nl> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-archive-position: 4845 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: knuffie@xs4all.nl Precedence: bulk X-list: linux-xfs Content-Length: 1519 Lines: 49 At 14:17 30-7-2003 -0600, Craig Tierney wrote: >On Wed, Jul 30, 2003 at 09:43:50PM +0200, Seth Mos wrote: > > At 13:24 30-7-2003 -0600, Craig Tierney wrote: > > > > >Sorry if this is a repeat, I haven't seen the whole > > >thread. Did you try increasing the scsi max readahead? > > > > I found them already since new something like this existed in proc :-) > > > > > echo "511" > /proc/sys/vm/max-readahead > > > echo "127" > /proc/sys/vm/min-readahead > > > > I used 512 and 128 but it works! > >Great. I used 2^n-1 becuase that is how they >were set initially (31). The default changed between the release but the penalty on devices that can do decent fast IO is dramatic. In my case it halves the read performance compared to what it used to be. 2.4.18-27 /proc/sys/vm/min-readahead 3 /proc/sys/vm/max-readahead 127 2.4.20-18 /proc/sys/vm/min-readahead 3 /proc/sys/vm/max-readahead 31 I think we want to change this, if your devices can pass the 100MB/sec read barrier this will probably affect you. My suggested default would be 31 for min-readahead and 127 for max-readahead. I tested a bit and it gives decent results. Anything over 127 is not really used. Below 127 it starts hurting the performance in large sequential IO. The disks I have here are significantly fast that a min-readahead smaller then 31 just make them seek a lot. There is not much difference in latency to fetch this much information as it does for 3. Cheers -- Seth It might just be your lucky day, if you only knew. From owner-linux-xfs@oss.sgi.com Thu Jul 31 06:42:59 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 31 Jul 2003 06:43:16 -0700 (PDT) Received: from av.mvista.com (gateway-1237.mvista.com [12.44.186.158]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h6VDgwFl022305 for ; Thu, 31 Jul 2003 06:42:58 -0700 Received: from mvista.com (av [127.0.0.1]) by av.mvista.com (8.9.3/8.9.3) with ESMTP id GAA26106; Thu, 31 Jul 2003 06:42:50 -0700 Message-ID: <3F291B20.4F751E9E@mvista.com> Date: Thu, 31 Jul 2003 06:35:28 -0700 From: Blair Barnett Organization: Monta Vista Software, Inc X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.4.18 i686) X-Accept-Language: en MIME-Version: 1.0 To: Klaus Strebel CC: linux-xfs@oss.sgi.com Subject: Re: different behaviour between XFS and ext3 References: <3F283E36.778CC934@mvista.com> <3F28CE63.80005@eigner.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-archive-position: 4846 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: bbarnett@mvista.com Precedence: bulk X-list: linux-xfs Content-Length: 601 Lines: 29 Hi Klaus Thanks for the pointer. I'm probably just naive, but I thought a sync call forced the data to secondary storage. Maybe sync doesn't guaruntee that: NAME sync - flush filesystem buffers SYNOPSIS sync [OPTION] DESCRIPTION Force changed blocks to disk, update the super block. --help display this help and exit --version output version information and exit Looks like the manual is wrong in the case of sync and XFS. :-) I would assume that sync overrides the mount options, but again I could be mistaken. Thanks for the reply. -blair From owner-linux-xfs@oss.sgi.com Thu Jul 31 07:06:30 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 31 Jul 2003 07:06:47 -0700 (PDT) Received: from av.mvista.com (gateway-1237.mvista.com [12.44.186.158]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h6VE6TFl024952 for ; Thu, 31 Jul 2003 07:06:29 -0700 Received: from mvista.com (av [127.0.0.1]) by av.mvista.com (8.9.3/8.9.3) with ESMTP id HAA26884; Thu, 31 Jul 2003 07:06:21 -0700 Message-ID: <3F2920A4.575A310A@mvista.com> Date: Thu, 31 Jul 2003 06:59:00 -0700 From: Blair Barnett Organization: Monta Vista Software, Inc X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.4.18 i686) X-Accept-Language: en MIME-Version: 1.0 To: Simon Matter CC: linux-xfs@oss.sgi.com Subject: Re: different behaviour between XFS and ext3 References: <3F283E36.778CC934@mvista.com> <3F28E34D.3EE2CF4A@ch.sauter-bc.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-archive-position: 4847 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: bbarnett@mvista.com Precedence: bulk X-list: linux-xfs Content-Length: 969 Lines: 28 Hi Simon, et al, I used stock kernel.org sources with SGI's XFS patches: for XFS 1.1, I used the 2.4.18 kernel for XFS 1.2, I used the 2.4.19 kernel for XFS 1.3pre, I used the 2.4.21 kernel The only reason I did this was to be complete with my tests. As I said in a previous email, I just naively thought that sync would actually flush all the data to the disk. The disk is an IDE disk with a 2MB cache. I thought that the disk cache might be the cause of the results, so I added sleeps of from 1 - 10 seconds. No difference in my results were seen. One of the reasons I included the script was for anyone interested in the the phenomenon I think I found, to actually run the script on their system and if different results were obtained, we could figure out what was different. Thanks so far to all who've taken up this thread. I like XFS for it's throughput but if data integrity is not guaranteed through a sync call, I have my reservations about it. -blair From owner-linux-xfs@oss.sgi.com Thu Jul 31 07:48:01 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 31 Jul 2003 07:48:05 -0700 (PDT) Received: from zok.sgi.com (zok.SGI.COM [204.94.215.101]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h6VEm0Fl029036 for ; Thu, 31 Jul 2003 07:48:01 -0700 Received: from flecktone.americas.sgi.com (flecktone.americas.sgi.com [192.48.203.135]) by zok.sgi.com (8.12.9/8.12.9/linux-outbound_gateway-1.1) with ESMTP id h6VEltq0024939 for ; Thu, 31 Jul 2003 07:47:55 -0700 Received: from daisy-e236.americas.sgi.com (daisy-e236.americas.sgi.com [128.162.236.214]) by flecktone.americas.sgi.com (8.12.9/8.12.9/generic_config-1.2) with ESMTP id h6VElsQK3543460; Thu, 31 Jul 2003 09:47:54 -0500 (CDT) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.232.100]) by daisy-e236.americas.sgi.com (8.12.9/SGI-server-1.8) with ESMTP id h6VElsRn203171376; Thu, 31 Jul 2003 09:47:54 -0500 (CDT) Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id h6VElsu02933; Thu, 31 Jul 2003 09:47:54 -0500 Subject: Re: different behaviour between XFS and ext3 From: Steve Lord To: Blair Barnett Cc: linux-xfs@oss.sgi.com In-Reply-To: <3F283E36.778CC934@mvista.com> References: <3F283E36.778CC934@mvista.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit Organization: Message-Id: <1059662873.2837.56.camel@jen.americas.sgi.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.4 Date: 31 Jul 2003 09:47:53 -0500 X-archive-position: 4848 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: lord@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 1007 Lines: 27 On Wed, 2003-07-30 at 16:52, Blair Barnett wrote: > Hi, > > I have a simple shell script that writes numbers to a file and every 10 > numbers does a sync and after 40 does a reboot. I've attached the script > to this email. > > If the file is written to an EXT3 filesystem, then file contains the > numbers 1-40. However, if the file is written to an XFS 1.1,1.2, or 1.3 > filesystem, then file contains the numbers 1-10. > > Can someone tell me if this is a feature of XFS or a bug? Its a bug, not sure what it is yet, those subsequent syncs should be working. In testing sync and reboot I was untaring a linux kernel doing sync followed by immediate reset of the box. I can build the kernel afterwards, so that works. When I run the test, there is more data on the disk than number 10, but the inode size is back at where it was at the first sync. Steve -- Steve Lord voice: +1-651-683-3511 Principal Engineer, Filesystem Software email: lord@sgi.com From owner-linux-xfs@oss.sgi.com Thu Jul 31 15:49:04 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 31 Jul 2003 15:49:40 -0700 (PDT) Received: from rj.sgi.com (rj.SGI.COM [192.82.208.96]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h6VMn1Fl032353 for ; Thu, 31 Jul 2003 15:49:02 -0700 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by rj.sgi.com (8.12.9/8.12.9/linux-outbound_gateway-1.1) with SMTP id h6VKmwQa014643 for ; Thu, 31 Jul 2003 13:48:59 -0700 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 IAA10839; Fri, 1 Aug 2003 08:48:48 +1000 Received: from wobbly.melbourne.sgi.com (localhost [127.0.0.1]) by wobbly.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id h6VMmk3K225676; Fri, 1 Aug 2003 08:48:46 +1000 (EST) Received: (from nathans@localhost) by wobbly.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id h6VMmini226658; Fri, 1 Aug 2003 08:48:44 +1000 (EST) Date: Fri, 1 Aug 2003 08:48:43 +1000 From: Nathan Scott To: k.karaivanov@minfin.bg Cc: linux-xfs@oss.sgi.com Subject: Re: TAKE - add missing acl files Message-ID: <20030801084843.A224990@wobbly.melbourne.sgi.com> References: <200307302238.h6UMctLg7722589@snort.melbourne.sgi.com> <01a001c35764$18616cd0$0f01280a@minfin.bg> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <01a001c35764$18616cd0$0f01280a@minfin.bg>; from larry@minfin.bg on Thu, Jul 31, 2003 at 04:03:11PM +0300 X-archive-position: 4849 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: nathans@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 1232 Lines: 48 On Thu, Jul 31, 2003 at 04:03:11PM +0300, Kostadin Todorov Karaivanov wrote: > > acl/libmisc/Makefile is empty > acl as a whole don't compile This mod fixed that, wait awhile then refresh your cvs tree to pick up these updates. Should be there by now actually, yes, from a quick check it is. cheers. > > Kostadin Karaivanov > Senior System Administrator @ Ministry Of Finance > tel: +359 2 98592062 > k.karaivanov@minfin.bg > > > > -----Original Message----- > > From: linux-xfs-bounce@oss.sgi.com > > [mailto:linux-xfs-bounce@oss.sgi.com] On Behalf Of Nathan Scott > > Sent: Thursday, July 31, 2003 1:39 AM > > To: linux-xfs@oss.sgi.com; agruen@suse.de > > Subject: TAKE - add missing acl files > > > > > > Integrate libmisc files which patch decided to put in acl/empty > > for some reason. > > > > Date: Wed Jul 30 15:37:53 PDT 2003 > > Workarea: snort.melbourne.sgi.com:/home/nathans/2.5.x-xfs > > > > The following file(s) were checked into: > > bonnie.engr.sgi.com:/isms/slinx/2.5.x-xfs > > > > > > Modid: xfs-cmds:slinx:154625a > > cmd/acl/libmisc/unquote.c - 1.2 > > cmd/acl/libmisc/quote.c - 1.2 > > cmd/acl/libmisc/high_water_alloc.c - 1.2 > > cmd/acl/libmisc/Makefile - 1.2 > > > > > -- Nathan From owner-linux-xfs@oss.sgi.com Thu Jul 31 18:21:01 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 31 Jul 2003 18:21:18 -0700 (PDT) Received: from zok.sgi.com (zok.SGI.COM [204.94.215.101]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h711L1Fl009887 for ; Thu, 31 Jul 2003 18:21:01 -0700 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.54.149]) by zok.sgi.com (8.12.9/8.12.9/linux-outbound_gateway-1.1) with ESMTP id h711Ktq0014807 for ; Thu, 31 Jul 2003 18:20:55 -0700 Received: from snort.melbourne.sgi.com (localhost [127.0.0.1]) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id h711KrJA7813833 for ; Fri, 1 Aug 2003 11:20:53 +1000 (EST) Received: (from nathans@localhost) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id h711Kq2S8013486 for linux-xfs@oss.sgi.com; Fri, 1 Aug 2003 11:20:52 +1000 (EST) Date: Fri, 1 Aug 2003 11:20:52 +1000 (EST) From: Nathan Scott Message-Id: <200308010120.h711Kq2S8013486@snort.melbourne.sgi.com> To: linux-xfs@oss.sgi.com Subject: TAKE - backport 2.5 unwritten extent fix X-archive-position: 4850 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: nathans@snort.melbourne.sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 333 Lines: 12 Merge back the unwritten extent probe (incorrect last page) fix from 2.5 Date: Thu Jul 31 18:19:50 PDT 2003 Workarea: snort.melbourne.sgi.com:/home/nathans/clean-2.4.x-xfs The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: xfs-linux:slinx:154772a linux/fs/xfs/linux/xfs_aops.c - 1.43 From owner-linux-xfs@oss.sgi.com Thu Jul 31 22:50:20 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 31 Jul 2003 22:50:35 -0700 (PDT) Received: from zok.sgi.com (zok.SGI.COM [204.94.215.101]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h715oJFl006115 for ; Thu, 31 Jul 2003 22:50:20 -0700 Received: from bruce.melbourne.sgi.com (bruce.melbourne.sgi.com [134.14.54.176]) by zok.sgi.com (8.12.9/8.12.9/linux-outbound_gateway-1.1) with ESMTP id h715oDq0004545 for ; Thu, 31 Jul 2003 22:50:14 -0700 Received: from bruce.melbourne.sgi.com (localhost.localdomain [127.0.0.1]) by bruce.melbourne.sgi.com (8.12.8/8.12.8) with ESMTP id h715oD0M022479 for ; Fri, 1 Aug 2003 15:50:13 +1000 Received: (from fsgqa@localhost) by bruce.melbourne.sgi.com (8.12.8/8.12.8/Submit) id h715oCe8022478 for linux-xfs@oss.sgi.com; Fri, 1 Aug 2003 15:50:12 +1000 Date: Fri, 1 Aug 2003 15:50:12 +1000 From: FSG QA Message-Id: <200308010550.h715oCe8022478@bruce.melbourne.sgi.com> Subject: TAKE - xfstests X-archive-position: 4851 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: fsgqa@bruce.melbourne.sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 1608 Lines: 70 [ misc updates and a couple of additional tests -- nathans ] Use a smaller scratch bigfs, 1tb is a bad idea without big-AG changes. Date: Thu Jul 24 17:45:59 PDT 2003 Workarea: bruce.melbourne.sgi.com:/home/fsgqa/qa/2.4.x-xfs The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: xfs-cmds:slinx:154266a cmd/xfstests/073 - 1.3 Fix test 067 when non-default mkfs options are in use. Date: Tue Jul 29 14:32:23 PDT 2003 Workarea: bruce.melbourne.sgi.com:/home/fsgqa/qa/2.4.x-xfs The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: xfs-cmds:slinx:154517a cmd/xfstests/067 - 1.10 Adds a new fstest invocation test (074). Date: Thu Jul 31 20:38:46 PDT 2003 Workarea: bruce.melbourne.sgi.com:/home/fsgqa/qa/2.4.x-xfs The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: xfs-cmds:slinx:154775a cmd/xfstests/074.out - 1.1 cmd/xfstests/074 - 1.1 - Run fstest with a variety of different options. cmd/xfstests/013 - 1.12 - remove an unused variable. cmd/xfstests/group - 1.34 - Add new test 074. cmd/xfstests/src/fstest.c - 1.3 - Report whether space preallocation is in use or not. Add an fsx test, allow fsx to preallocate file space on -x. Date: Thu Jul 31 22:48:02 PDT 2003 Workarea: bruce.melbourne.sgi.com:/home/fsgqa/qa/2.4.x-xfs The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: xfs-cmds:slinx:154777a cmd/xfstests/075 - 1.1 cmd/xfstests/075.out - 1.1 cmd/xfstests/group - 1.35 cmd/xfstests/ltp/fsx.c - 1.2