From owner-linux-xfs@oss.sgi.com Tue Jan 1 16:13:09 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g020D9L29128 for linux-xfs-outgoing; Tue, 1 Jan 2002 16:13:09 -0800 Received: from deliverator.sgi.com (deliverator.sgi.com [204.94.214.10]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g020D4g29106 for ; Tue, 1 Jan 2002 16:13:04 -0800 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via SMTP id PAA13552 for ; Tue, 1 Jan 2002 15:12:45 -0800 (PST) mail_from (ivanr@sgi.com) From: ivanr@sgi.com Received: from omen.melbourne.sgi.com (omen.melbourne.sgi.com [134.14.55.139]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id KAA02398; Wed, 2 Jan 2002 10:11:42 +1100 Received: from localhost (ivanr@localhost) by omen.melbourne.sgi.com (SGI-8.9.3/8.9.3) with ESMTP id KAA96989; Wed, 2 Jan 2002 10:11:42 +1100 (EST) X-Authentication-Warning: omen.melbourne.sgi.com: ivanr owned process doing -bs Date: Wed, 2 Jan 2002 10:11:41 +1100 X-X-Sender: ivanr@omen.melbourne.sgi.com To: Jason White cc: linux-xfs@oss.sgi.com Subject: Re: XFS and backup solutions In-Reply-To: <15396.20671.333468.703578@gargle.gargle.HOWL> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 1185 Lines: 35 On Sat, 22 Dec 2001, Jason White wrote: > Mike Gigante writes: > > > > Ivan Raynor here in the Melbourne XFS group did a "proof of concept" > > xfsdump with removable media (zip disks I think) > > > > Not production code, but a useful starting point for someone to pick > > up. I believe it was discussed on this list a few months ago -- check > > the archives. > > I found the discussion in the October archive. He had indeed written a > patch for this, but it wasn't sent to the list or integrated into CVS as > much more work needed to be done first. He did however indicate that he > would make it available to anyone who was interested. > > Thus, if any list subscribers would like to work on it... My work would allow xfsdump to write to multiple removeable disks, or devices that behaved like removeable disks. I don't think it'd work very well for a CD writer. At the moment, I think your best option is to dump to a file and then split the file up into chunks which can be written to a CD. Of course, if you don't use XFS's extended attributes (including ACLs) then there's no reason you can't use whatever backup utility you like. Ivan -- Ivan Rayner ivanr@sgi.com From owner-linux-xfs@oss.sgi.com Tue Jan 1 20:51:48 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g024pms00889 for linux-xfs-outgoing; Tue, 1 Jan 2002 20:51:48 -0800 Received: from mta02ps.bigpond.com (mta02ps.bigpond.com [144.135.25.134]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g024pPg00867 for ; Tue, 1 Jan 2002 20:51:25 -0800 Message-Id: <200201020451.g024pPg00867@oss.sgi.com> Received: from there ([144.135.25.75]) by mta02ps.bigpond.com (Netscape Messaging Server 4.15) with SMTP id GPALP100.ANK; Wed, 2 Jan 2002 13:58:13 +1000 Received: from CPE-144-137-138-230.qld.bigpond.net.au ([144.137.138.230]) by PSMAM03.mailsvc.email.bigpond.com(MailRouter V3.0h 89/713517); 02 Jan 2002 13:51:15 Content-Type: text/plain; charset="us-ascii" From: Adrian Head To: Linux XFS Mailing List , linux-lvm@sistina.com Subject: Unable to get XFS, ext3, reiserfs & LVM to coexist happily Date: Wed, 2 Jan 2002 13:51:01 +1000 X-Mailer: KMail [version 1.3.1] MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 6457 Lines: 217 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hope everyone had a happy new year :-) I'm starting to play around with LVM with the goal of having XFS, ext3, reiserfs and LVM coexist nicely together. Has anyone been able to get , ext3, reiserfs, XFS and LVM running nicely together? A week ago I posted a problem I was having with XFS and LVM in that the machine would Oops if the snapshot ever overflowed: Original post: http://marc.theaimsgroup.com/?l=linux-lvm&m=100942205812492&w=2 My followup: http://marc.theaimsgroup.com/?l=linux-lvm&m=100946566202294&w=2 At the time I thought I had solved the problem but upon further tests I found that the problems had just moved elsewhere. What I did was to run a series of tests using the SGI, CVS kernel (for XFS) as the base and added the appropriate LVM patches. The LVM patches were the VFS-lock patch and the lvm-1.0.1 upgrade patch. I ran various tests like creating snapshots and attempting to mount them, and then if that was successful would then overflow the snapshot to see if there were any problems. (I have not attempting to test pvmove or any of the others yet.) Attached below is the summary from the tests. After running all the tests I have found that there is not one case where ext3, reiserfs and xfs successfully coexist. Does anyone have any suggestions? as I'm completely stumped at the moment. The SGI CVS kernel is from the 26th Dec 2001 and is a 2.4.17 kernel. The LVM source is directly from the LVM download site. The system is based on RH7.2 with the default gcc compiler. There were no changes of the default kernel or LVM compile flags. If I have left out any important info please let me know. Any ideas or suggestions would be appreciated. Adrian NOTE: The back traces were done in kdb and are written here in shorthand only for the moment. NOTE: The LVM_VFS_ENHANCEMENT in lvm.c seems to disappear when using the lvm-1.0.1 upgrade patch. CVS XFS kernel & lvm Test results ============================ 2.4.17-xfs While source volume mounted: * Can create ext3 snapshot? | yes * Can mount a ext3 snapshot? | no: EXT3-fs: INFO: recovery required on readonly filesystem. EXT3-fs: write access unavailable, cannot proceed. * Can create resierfs snapshot? | yes * Can mount a resierfs snapshot? | yes * Can create xfs snapshot? | yes * Can mount a xfs snapshot? | yes NOTE: For some reason kernel thinks xfs is resierfs when mounted without -t xfs! When source & snapshot mounted: * Cause oops when snapshot overflows? | - ext3 | Cannot test - resierfs | OK - Stable - xfs | Oops btp 1207 (cp) lvm_snapshot_remap_block lvm_map md_make_request generic_makw_request [pagebuf]_pagebuf_page [pagebuf]_page_buf_page_apply [xfs]xlog_sync [xfs]xlog_state_release_iclog [xfs]xlog_write [xfs]xfs_log_write [xfs]xfs_trans_commit [xfs]xfs_create [xfslinvfs_common_cr [xfs]linvfs_create lookup_hash Running process (cp) 2.4.17-xfs + VFS-lock While source volume mounted: * Can create ext3 snapshot? | yes * Can mount a ext3 snapshot? | yes * Can create resierfs snapshot? | yes * Can mount a resierfs snapshot? | yes * Can create xfs snapshot? | yes * Can mount a xfs snapshot? | yes When source & snapshot mounted: * Cause oops when snapshot overflows? | - ext3 | Oops btp 5 (bdflush) lvm_snapshot_remap_block lvm_map lvm_make_request submit_bh write_locked_buffers write_some_buffers bdflush kernel_thread Running processes (bdflush, kjournald, klogd, cp) - resierfs | Oops btp 6 (kupdated) lvm_snapshot_remap_block lvm_map lvm_make_request generic_make_request submit_bh write_locked_buffers write_some_buffers balance_dirty sync_supers sync_old_buffers kupdated kernel_thread Running processes (kupdated, kreiserfsd, klogd) - xfs | OK - Stable 2.4.17-xfs + lvm-1.0.1 upgrade (without LVM_VFS_ENHANCEMENT) While source volume mounted: * Can create ext3 snapshot? | yes * Can mount a ext3 snapshot? | no EXT3-fs: INFO: recovery required on readonly filesystem. EXT3-fs: write access unavailable, cannot proceed. * Can create resierfs snapshot? | yes * Can mount a resierfs snapshot? | no resierfs: checking trasaction log (device 3a:04) ... clm-2076: device is readonly, unable to replay log Replay Failure, unable to mount resierfs_read_super: unable to initialize journal space * Can create xfs snapshot? | yes * Can mount a xfs snapshot? | yes When source & snapshot mounted: * Cause oops when snapshot overflows? | - ext3 | Cannot test - resierfs | Cannot test - xfs | OK - Stable 2.4.17-xfs + lvm-1.0.1 upgrade (with LVM_VFS_ENHANCEMENT) While source volume mounted: * Can create ext3 snapshot? | Cannot test * Can mount a ext3 snapshot? | Cannot test * Can create resierfs snapshot? | Cannot test * Can mount a resierfs snapshot? | Cannot test * Can create xfs snapshot? | Cannot test * Can mount a xfs snapshot? | Cannot test When source & snapshot mounted: * Cause oops when snapshot overflows? | - ext3 | Cannot test - resierfs | Cannot test - xfs | Cannot test Note: Kernel compile dies with: undefined reference to `fsync_dev_lockfs' undefined reference to `unlockfs' 2.4.17-xfs While source volume mounted: + VFS-lock + lvm-1.0.1 upgrade (VFS-lock patch removes LVM_VFS_ENHANCEMENT) * Can create ext3 snapshot? | yes * Can mount a ext3 snapshot? | yes * Can create resierfs snapshot? | yes * Can mount a resierfs snapshot? | yes * Can create xfs snapshot? | no - Oops btp 1356 (lvcreate) journal_start ext3_dirty_inode __mark_inode_dirty update_atime do_generic_file_read generic_file_read sys_read system_call Running processes (lvcreate) * Can mount a xfs snapshot? | Cannot test When source & snapshot mounted: * Cause oops when snapshot overflows? | - ext3 | OK - Stable - resierfs | OK - Stable - xfs | Cannot test Cannot complete boot sequence (RH scripts) after attempting to create xfs snapshot because of Oops - need to do full recovery! btp 154 (mount) send_signal deliver_signal send_sig_info error_code Running processes (none) - -- Adrian Head (Public Key available on request.) -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE8MoOq8ZJI8OvSkAcRArVHAJ0UkaOT2/agPlr667k/d+UAT0i2igCfedA7 3EDNqrrDDvRL7GWoBuglytk= =GwyP -----END PGP SIGNATURE----- From owner-linux-xfs@oss.sgi.com Tue Jan 1 21:13:28 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g025DS001341 for linux-xfs-outgoing; Tue, 1 Jan 2002 21:13:28 -0800 Received: from mta01ps.bigpond.com (mta01ps.bigpond.com [144.135.25.133]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g025DKg01319 for ; Tue, 1 Jan 2002 21:13:21 -0800 Message-Id: <200201020513.g025DKg01319@oss.sgi.com> Received: from there ([144.135.25.87]) by mta01ps.bigpond.com (Netscape Messaging Server 4.15) with SMTP id GPAMPM00.5AM for ; Wed, 2 Jan 2002 14:20:10 +1000 Received: from CPE-144-137-138-230.qld.bigpond.net.au ([144.137.138.230]) by psmam07.mailsvc.email.bigpond.com(MailRouter V3.0h 125/1332477); 02 Jan 2002 14:13:11 Content-Type: text/plain; charset="us-ascii" From: Adrian Head To: Linux XFS Mailing List Subject: Re: Unable to get XFS, ext3, reiserfs & LVM to coexist happily Date: Wed, 2 Jan 2002 14:13:01 +1000 X-Mailer: KMail [version 1.3.1] References: <200201020451.g024pPg00867@oss.sgi.com> In-Reply-To: <200201020451.g024pPg00867@oss.sgi.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 1743 Lines: 54 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 As I cross posted this I didn't make a big deal out of it but I find it interesting that sometimes (I haven't spent the time to nail this down properly yet) when mounting an xfs snapshot like so: mount /dev/HDA/SNAP /mnt/snapshot it thinks that the snapshot is a resierfs snapshot and sill go to great lengths to do so (takes up to and over a minute to mount it). Everything seems fine at the end of the day ie. I can see files in the snapshot but I find it interesting that either: 1) There is a problem and the kernel is mistaking an XFS snapshot as a resierfs snapshot, or 2) There is a problem and the kernel is just misreporting the filesystem on the snapshot. Of course this is easily to get around just use: mount -t xfs /dev/HDA/SNAP /mnt/snapshot I'm intreged now. On Wed, 2 Jan 2002 13:51, Adrian Head wrote: > Hope everyone had a happy new year :-) > > I'm starting to play around with LVM with the goal of having XFS, ext3, > reiserfs and LVM coexist nicely together. > > Has anyone been able to get , ext3, reiserfs, XFS and LVM running nicely > together? [....] > * Can create xfs snapshot? | yes > * Can mount a xfs snapshot? | yes > NOTE: For some reason kernel thinks xfs is resierfs when mounted without -t > xfs! > When source & snapshot mounted: > * Cause oops when snapshot overflows? | > - ext3 | Cannot test > - resierfs | OK - Stable > - xfs | Oops - -- Adrian Head (Public Key available on request.) -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE8MojQ8ZJI8OvSkAcRAqsxAJ9sAO32yfafwJBIiHgttNDdwMB4/wCfVBUe ZJxWFrWW4BNj54EnrJogRuc= =+T/L -----END PGP SIGNATURE----- From owner-linux-xfs@oss.sgi.com Wed Jan 2 00:51:27 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g028pRN04558 for linux-xfs-outgoing; Wed, 2 Jan 2002 00:51:27 -0800 Received: from relay.xlink.net (relay.xlink.net [193.141.40.4]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g028pIg04526 for ; Wed, 2 Jan 2002 00:51:18 -0800 Received: from lizard.webland.de (lizard.webland.de [194.122.76.201]) by relay.xlink.net (8.9.3/8.8.7) with ESMTP id IAA23607; Wed, 2 Jan 2002 08:51:12 +0100 (MET) Received: (from uucp@localhost) by lizard.webland.de (8.8.8/8.8.7) id IAA06419; Wed, 2 Jan 2002 08:51:11 +0100 (MET) >Received: from mobile.sauter-bc.com (unknown [10.1.6.21]) by basel1.sauter-bc.com (Postfix) with ESMTP id A4B4B57306; Wed, 2 Jan 2002 08:50:35 +0100 (CET) Received: from ch.sauter-bc.com (support.cad.sba [10.1.200.117]) by mobile.sauter-bc.com (Postfix) with ESMTP id 78B7325835; Wed, 2 Jan 2002 08:50:20 +0100 (CET) Message-ID: <3C32BBBC.5962F2B6@ch.sauter-bc.com> Date: Wed, 02 Jan 2002 08:50:20 +0100 From: Simon Matter Organization: Sauter AG, Basel X-Mailer: Mozilla 4.77 [de] (X11; U; Linux 2.2.19-6.2.12 i686) X-Accept-Language: de-CH, en MIME-Version: 1.0 To: Adrian Head Cc: linux-xfs@oss.sgi.com Subject: Re: XFS dying when many processes copy many files/directories References: <200112170121.fBH1Lio02958@oss.sgi.com> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 1533 Lines: 44 Hello Adrian Maybe you remember that I experienced the same problem (system hang) when running several cp processes simultaneously. The difference was that I was able to hang the system with different filesystems (even with good old ext2). I gave up on this but now I woke up and will try again tonight. IIRC I was trying last with the 2.4.9-12 rpm of RH7.1-XFS and did not have this problem again. Simon Adrian Head schrieb: > > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > I am again in the process of building a couple of file servers for various > purposes over the last week and thought that I'd have another serious look at > using XFS on the new file servers. > > Base system is Redhat 7.1 with a custom kernel - 2.4.16+xfs. > > My standard process before putting servers into production is to run a few > tests to make sure that I can trust the hardware/software combination. One > of my standard tests is to simulate many users simultaniously copying many > files across the filesystem. The volume is a software raid5 over 4 IDE > drives. > > It is during this test that the machine hangs after getting almost 95% > complete. I have tried running this test using XFS, ext2, ext3, reiserfs and > only XFS fails to complete. This situation is completely reproducable every > time I have run this test to date. > > I'm at a loss as to what to do next to troubleshoot this problem or even what > info people need. > > Attached is some info: > > - -- > Adrian Head > > (Public Key available on request.) From owner-linux-xfs@oss.sgi.com Wed Jan 2 09:11:35 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g02HBZp15844 for linux-xfs-outgoing; Wed, 2 Jan 2002 09:11:35 -0800 Received: from eagle.oceana.com (eagle.oceana.com [208.17.123.12]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g02HBTg15822 for ; Wed, 2 Jan 2002 09:11:29 -0800 Received: from oceana.com (ken.oceana.com [192.168.10.26]) by eagle.oceana.com (8.12.1/8.12.1) with ESMTP id g02GBMMJ020410 for ; Wed, 2 Jan 2002 11:11:22 -0500 Message-ID: <3C3331B6.4C74864C@oceana.com> Date: Wed, 02 Jan 2002 11:13:42 -0500 From: Ken Murchison Organization: Oceana Matrix Ltd. X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,pdf MIME-Version: 1.0 To: linux-xfs@oss.sgi.com Subject: Re: Random Kernel Panic on Boot References: <3C2BD056.4000507@duke.edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 1097 Lines: 32 Mike Baptiste wrote: > > I've got a new system I'm working to put into production and I have one > nagging problem that I'm trying to resolve and perhaps one of you has > seen this or can point me in the right direction. I know this may not > be an XFS problem but since I'm using the XFS installer I figured I'd > start here. [...] > The problem is this: When booting either the smp or enterprise kernels > (stock RH 2.4.9-XFS from the XFS installer CD), I get random kernel > panics. Maybe 3 out of 4 boots, at varying points in Interactive boot > (from LVM activiation forward), I'll get a Kernel Panic from the DAC960 > driver: > > DAC960#0: SegmentNumber != SegmentCount I have the same problem with my quad Xeon. No problem with RH 2.4.3-SGI_XFS_1.0.1 or 2.4.14-SGI_XFS_1.0.2. I haven't been able to try a stock RH 2.4.9-13 (without the XFS bits) because all of my filesystems are XFS Ken -- Kenneth Murchison Oceana Matrix Ltd. Software Engineer 21 Princeton Place 716-662-8973 x26 Orchard Park, NY 14127 --PGP Public Key-- http://www.oceana.com/~ken/ksm.pgp From owner-linux-xfs@oss.sgi.com Wed Jan 2 09:33:23 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g02HXN616165 for linux-xfs-outgoing; Wed, 2 Jan 2002 09:33:23 -0800 Received: from mail.ocs.com.au (mail.ocs.com.au [203.34.97.2]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g02HXCg16141 for ; Wed, 2 Jan 2002 09:33:13 -0800 Received: (qmail 10486 invoked from network); 2 Jan 2002 16:33:06 -0000 Received: from ocs3.intra.ocs.com.au (192.168.255.3) by mail.ocs.com.au with SMTP; 2 Jan 2002 16:33:06 -0000 Received: by ocs3.intra.ocs.com.au (Postfix, from userid 16331) id B94BB300095; Thu, 3 Jan 2002 03:33:04 +1100 (EST) Received: from ocs3.intra.ocs.com.au (localhost [127.0.0.1]) by ocs3.intra.ocs.com.au (Postfix) with ESMTP id 55C0794; Thu, 3 Jan 2002 03:33:04 +1100 (EST) X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 From: Keith Owens To: Ken Murchison Cc: linux-xfs@oss.sgi.com Subject: Re: Random Kernel Panic on Boot In-reply-to: Your message of "Wed, 02 Jan 2002 11:13:42 CDT." <3C3331B6.4C74864C@oceana.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 03 Jan 2002 03:32:58 +1100 Message-ID: <7700.1009989178@ocs3.intra.ocs.com.au> Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 1720 Lines: 35 On Wed, 02 Jan 2002 11:13:42 -0500, Ken Murchison wrote: >Mike Baptiste wrote: >> The problem is this: When booting either the smp or enterprise kernels >> (stock RH 2.4.9-XFS from the XFS installer CD), I get random kernel >> panics. Maybe 3 out of 4 boots, at varying points in Interactive boot >> (from LVM activiation forward), I'll get a Kernel Panic from the DAC960 >> driver: >> >> DAC960#0: SegmentNumber != SegmentCount > >I have the same problem with my quad Xeon. No problem with RH >2.4.3-SGI_XFS_1.0.1 or 2.4.14-SGI_XFS_1.0.2. I haven't been able to try >a stock RH 2.4.9-13 (without the XFS bits) because all of my filesystems >are XFS The SMP kernels for 2.4.9-13SGI_XFS_PR1 are broken. I just installed a new machine, install (UP) was fine, booting the SMP kernel broke at random in the ncr53c8xx SCSI driver. Booting the UP kernel avoided the oops, but then I hit Al Viro's "corrupt hard links and super blocks" bug. These are all problems caused by bugs in Linus's kernel. I used another machine to compile 2.4.17-XFS from the CVS tree and it runs fine in SMP on the machine that was failing. Installing was "interesting" because links did not work, preventing the use of rsync to copy the new kernel to the target machine. In the end I created a tarball of module and kernel, transferred it by ftp and unpacked on the target system. Then sync several times, boot into single user mode on 2.4.17-XFS and run e2fsck or xfs_repair on each partition to find any corrupt inodes left by Al Viro's 2.4.9 bug. I don't trust any kernel between about 2.4.9 and 2.4.16. There were too many bugs in the base kernel code, not XFS. 2.4.17-XFS from CVS is looking nice and stable. From owner-linux-xfs@oss.sgi.com Wed Jan 2 09:54:56 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g02Hsua16628 for linux-xfs-outgoing; Wed, 2 Jan 2002 09:54:56 -0800 Received: from e31.co.us.ibm.com (e31.co.us.ibm.com [32.97.110.129]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g02Hsqg16606 for ; Wed, 2 Jan 2002 09:54:52 -0800 Received: from westrelay03.boulder.ibm.com (westrelay03.boulder.ibm.com [9.99.140.24]) by e31.co.us.ibm.com (8.9.3/8.9.3) with ESMTP id LAA154052 for ; Wed, 2 Jan 2002 11:51:08 -0500 Received: from d03nm800.boulder.ibm.com (avpilot.boulder.ibm.com [9.17.188.135]) by westrelay03.boulder.ibm.com (8.11.1m3/NCO v5.01) with ESMTP id g02Grrh80290 for ; Wed, 2 Jan 2002 09:53:53 -0700 Subject: XFS DMAPI file I/O To: linux-xfs@oss.sgi.com X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 Message-ID: From: "James A Goodwin" Date: Wed, 2 Jan 2002 10:53:38 -0600 X-MIMETrack: Serialize by Router on D03NM800/03/M/IBM(Release 5.0.9 |November 16, 2001) at 01/02/2002 09:53:52 AM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 803 Lines: 23 I have two questions about I/O using the Linux XFS DMAPI implementation: 1. Some filesystems store a little bit of the file data in the i-node. This results in the first X bytes staying resident even after a dm_punch_hole command tries to free them. Is this the case with XFS, and if so, how many bytes are stored this way? 2. I just noticed that the DM_WRITE_SYNC flag is not supported for calls to dm_write_invis(). This is a fairly critical piece of missing functionality. Is there any chance this flag may be implemented in the future? I am currently porting a DMAPI application from another platform, and this could cause some major problems. Thanks, -James Goodwin Software Engineer IBM Global Services - Federal jagoodwi@us.ibm.com Phone: (281) 336 2578 Fax: (281) 335 4231 T/L 260-2578 From owner-linux-xfs@oss.sgi.com Wed Jan 2 09:59:49 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g02HxnV16807 for linux-xfs-outgoing; Wed, 2 Jan 2002 09:59:49 -0800 Received: from deliverator.sgi.com (deliverator.sgi.com [204.94.214.10]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g02Hxig16785 for ; Wed, 2 Jan 2002 09:59:44 -0800 Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id IAA20692 for ; Wed, 2 Jan 2002 08:59:27 -0800 (PST) mail_from (lord@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id KAA3983155; Wed, 2 Jan 2002 10:58:25 -0600 (CST) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id KAA17709; Wed, 2 Jan 2002 10:58:25 -0600 (CST) Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id g02GrQi18084; Wed, 2 Jan 2002 10:53:26 -0600 Subject: Re: XFS DMAPI file I/O From: Steve Lord To: James A Goodwin Cc: linux-xfs@oss.sgi.com In-Reply-To: References: Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/1.0.0.99+cvs.2001.12.18.08.57 (Preview Release) Date: 02 Jan 2002 10:53:26 -0600 Message-Id: <1009990406.14239.5.camel@jen.americas.sgi.com> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 1258 Lines: 39 On Wed, 2002-01-02 at 10:53, James A Goodwin wrote: > I have two questions about I/O using the Linux XFS DMAPI implementation: > > 1. Some filesystems store a little bit of the file data in the i-node. > This results in the first X bytes staying resident even after a > dm_punch_hole command tries to free them. Is this the case with XFS, and > if so, how many bytes are stored this way? There is never any file data in the xfs inode - the original data structures allowed for it, but it was never implemented. Things like mmap etc probably got too nasty. > > 2. I just noticed that the DM_WRITE_SYNC flag is not supported for calls to > dm_write_invis(). This is a fairly critical piece of missing > functionality. Is there any chance this flag may be implemented in the > future? I am currently porting a DMAPI application from another platform, > and this could cause some major problems. Dean will have to answer that one. Steve > > Thanks, > > -James Goodwin > Software Engineer > IBM Global Services - Federal > jagoodwi@us.ibm.com > Phone: (281) 336 2578 > Fax: (281) 335 4231 > T/L 260-2578 -- Steve Lord voice: +1-651-683-3511 Principal Engineer, Filesystem Software email: lord@sgi.com From owner-linux-xfs@oss.sgi.com Wed Jan 2 10:58:30 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g02IwUS17818 for linux-xfs-outgoing; Wed, 2 Jan 2002 10:58:30 -0800 Received: from mxzilla4.xs4all.nl (mxzilla4.xs4all.nl [194.109.6.48]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g02IwMg17795 for ; Wed, 2 Jan 2002 10:58:23 -0800 Received: from xs3.xs4all.nl (knuffie@xs3.xs4all.nl [194.109.6.44]) by mxzilla4.xs4all.nl (8.12.0/8.12.0) with ESMTP id g02HwIHP038949; Wed, 2 Jan 2002 18:58:18 +0100 (CET) Received: from localhost (knuffie@localhost) by xs3.xs4all.nl (8.9.0/8.9.0) with ESMTP id SAA26386; Wed, 2 Jan 2002 18:58:18 +0100 (CET) Date: Wed, 2 Jan 2002 18:58:18 +0100 (CET) From: Seth Mos To: Ken Murchison cc: linux-xfs@oss.sgi.com Subject: Re: Random Kernel Panic on Boot In-Reply-To: <3C3331B6.4C74864C@oceana.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 1334 Lines: 37 On Wed, 2 Jan 2002, Ken Murchison wrote: > > > Mike Baptiste wrote: > > > > I've got a new system I'm working to put into production and I have one > > nagging problem that I'm trying to resolve and perhaps one of you has > > seen this or can point me in the right direction. I know this may not > > be an XFS problem but since I'm using the XFS installer I figured I'd > > start here. > > [...] > > > The problem is this: When booting either the smp or enterprise kernels > > (stock RH 2.4.9-XFS from the XFS installer CD), I get random kernel > > panics. Maybe 3 out of 4 boots, at varying points in Interactive boot > > (from LVM activiation forward), I'll get a Kernel Panic from the DAC960 > > driver: > > > > DAC960#0: SegmentNumber != SegmentCount > > I have the same problem with my quad Xeon. No problem with RH > 2.4.3-SGI_XFS_1.0.1 or 2.4.14-SGI_XFS_1.0.2. I haven't been able to try > a stock RH 2.4.9-13 (without the XFS bits) because all of my filesystems > are XFS I don't think this is XFS related at all. The aacraid driver also broke in 2.4.9. Better stick with something else or patch in a newer dac960 driver. I think there was a block layer change in 2.4.9 which broke some drivers. The kernel had to be released soon because of the security issues which might have caused this slip. Cheers Seth From owner-linux-xfs@oss.sgi.com Wed Jan 2 10:59:59 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g02Ixxk17962 for linux-xfs-outgoing; Wed, 2 Jan 2002 10:59:59 -0800 Received: from pa42.warszawa.sdi.tpnet.pl (pa42.warszawa.sdi.tpnet.pl [213.25.213.42]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g02IxKg17923 for ; Wed, 2 Jan 2002 10:59:20 -0800 Received: (qmail 579 invoked by uid 1000); 2 Jan 2002 17:59:10 -0000 Date: Wed, 2 Jan 2002 18:59:10 +0100 From: Piotrek Kaczmarek To: linux-xfs@oss.sgi.com Subject: 2.4.10-pre2-xfs Oops on mount Message-ID: <20020102185910.A534@msg.beta.pl> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="ikeVEW9yuYc//A+q" Content-Disposition: inline User-Agent: Mutt/1.2.5i Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 18093 Lines: 331 --ikeVEW9yuYc//A+q Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Hi, There was a power failure and after bootup mount -a oopsed in a following way (ksymoops output attached) leaving "Starting XFS recovery on filesystem: ide0(3,9) (dev: 3/9)" in klog. Kernel was checked out about 1 Sep 2001. PS. Please CC, not a subscriber. Cheers, Piotr Kaczmarek --ikeVEW9yuYc//A+q Content-Type: text/plain; charset=iso-8859-2 Content-Disposition: attachment; filename=output Content-Transfer-Encoding: quoted-printable ksymoops 2.4.2 on i586 2.4.10-pre2-xfs. Options used -V (specified) -k /proc/ksyms (default) -l /proc/modules (default) -o /lib/modules/2.4.10-pre2-xfs/ (default) -m /boot/System.map-2.4.10-pre2-xfs (specified) EIP: %04x:[<%08lx>] CPU: %d ESP: %04x:%08lx EFLAGS: %08lx EAX: %08lx EBX: %08lx ECX: %08lx EDX: %08lx ESI: %08lx EDI: %08lx EBP: %08lx DS: %04x ES: %04x CR0: %08lx CR2: %08lx CR3: %08lx CR4: %08lx WARNING: dead process %8s still has LDT? <%p> process.ckernel BUG at %s:%d! EIP: %04x:[<%08lx>] EFLAGS: %08lx eax: %08lx ebx: %08lx ecx: %08lx edx: %08lx esi: %08lx edi: %08lx ebp: %08lx esp: %08lx ds: %04x es: %04x ss: %04x Process %s (pid: %d, stackpage=3D%08lx) Stack:=20 Code: Bad EIP value.%02x %s: %04lx Using defaults from ksymoops -t elf32-i386 -a i386 divide errorint3overflowboundsinvalid operanddevice not availabledouble fau= ltcoprocessor segment overruninvalid TSSsegment not presentstack segmentali= gnment checkgeneral protection faultUhhuh. NMI received. Dazed and confused= , but trying to continue NMI: IOCK error (debug interrupt?) Uhhuh. NMI received for unknown reason %02x. <6>AMD K6 stepping B detected - <6>K6 BUG %ld %d (Report these if test repo= rt is incorrect) C6432A2B2<6>CPU: Processor revision %u.%u.%u.%u, %u MHz Mobile Pentium II (Dixon)Celeron (Covington)Celeron (Coppermine)Celeron (Me= ndocino)<5>Intel Pentium with F0 0F bug - workaround enabled. yesnofdiv_bug : %s hlt_bug : %s f00f_bug : %s coma_bug : %s setup.ckernel BUG at %s:%d! <3>PCI: BIOS BUG #%x[%08x] found, report to PAE BUG #01! kernel BUG at %s:%d! <1>Unable to handle kernel NULL pointer dereference at virtual address %08lx <1>*pde =3D %08lx Oops<1>Unable to handle kernel paging requestVM: killing process %s ioremap.ckernel BUG at %s:%d! sched.ckernel BUG at %s:%d! RSDZTW%-13.13s %08lX %5lu %5d %6d %5d %7d %5d (NOTLB) (L-TLB) Warning (Oops_read): Code line not seen, dumping what data is available Proc; RSDZTW%-13.13s >>EIP; 00000008 Before first symbol <=3D=3D=3D=3D=3D /kaczorek/linux-2.4-xfs/linux/include/linux/dcache.hkernel BUG at %s:%d! <0>Kernel panic: %s ttyS=AE1=11=C0=AE1=11=C0h1=11=C0=A02=11=C0=B53=11=C0=C03=11=C0=D13=11=C0=E2= 3=11=C0=F33=11=C0<3>inter_module_register: duplicate im_name '%s'module.cke= rnel BUG at %s:%d! <3>Aiee, inter_module_register: cannot kmalloc entry for '%s' /kaczorek/linux-2.4-xfs/linux/include/linux/sched.hkernel BUG at %s:%d! exit.cAiee, killing interrupt handler!Attempted to kill the idle task!Attem= pted to kill init!softirq.ckernel BUG at %s:%d! /kaczorek/linux-2.4-xfs/linux/include/asm/highmem.hkernel BUG at %s:%d! =B0=E4=11=C0=D0=E4=11=C0=F6=E4=11=C0=06=E5=11=C0=B5=E4=11=C0=B5=E4=11=C00= =E5=11=C0P=E5=11=C0/kaczorek/linux-2.4-xfs/linux/include/linux/dcache.hkern= el BUG at %s:%d! kernel BUG at %s:%d! filemap.ckernel BUG at %s:%d! mprotect.ckernel BUG at %s:%d! kernel BUG at %s:%d! slab.ckernel BUG at %s:%d! bootmem.ckernel BUG at %s:%d! Out of memoryswap.ckernel BUG at %s:%d! vmscan.ckernel BUG at %s:%d! page_io.ckernel BUG at %s:%d! DMANormalHighMempage_alloc.ckernel BUG at %s:%d! swap_state.ckernel BUG at %s:%d! swapfile.ckernel BUG at %s:%d! Internal error: bad swap-device shmem.ckernel BUG at %s:%d! dev/zerohighmem.ckernel BUG at %s:%d! /kaczorek/linux-2.4-xfs/linux/include/asm/highmem.h/kaczorek/linux-2.4-xfs/= linux/include/linux/dcache.hkernel BUG at %s:%d! buffer.ckernel BUG at %s:%d! nodev/kaczorek/linux-2.4-xfs/linux/include/linux/dcache.hkernel BUG at %s:%= d! bdev_cacheCannot create bdev_cache SLAB cacheblock_dev.ckernel BUG at %s:%d! /kaczorek/linux-2.4-xfs/linux/include/asm/highmem.hkernel BUG at %s:%d! exec.cbinfmt-%04xcore.pipe.ckernel BUG at %s:%d! [%lu]/kaczorek/linux-2.4-xfs/linux/include/linux/file.h/kaczorek/linux-2.4-= xfs/linux/include/linux/dcache.hpipe:pipefs/kaczorek/linux-2.4-xfs/linux/in= clude/linux/dcache.hkernel BUG at %s:%d! =04=02=06/kaczorek/linux-2.4-xfs/linux/include/asm/highmem.h/kaczorek/linux= -2.4-xfs/linux/include/linux/file.hkernel BUG at %s:%d! locks.ckernel BUG at %s:%d! EOF READ WRITENONE POSIX *NOINODE*FLOCK MSNFS FLOCK ADVISORY L= EASE MANDATORY UNKNOWN UNKNOWN ->file lock cachecannot create file lock = slab cachedcache.ckernel BUG at %s:%d! buffer_headnames_cachefilpdquotCannot create buffer head SLAB cacheCannot c= reate names SLAB cacheCannot create filp SLAB cacheCannot create dquot SLAB= cacheinode.ckernel BUG at %s:%d! cannot create inode slab cacheattr.ckernel BUG at %s:%d! /kaczorek/linux-2.4-xfs/linux/include/linux/dcache.hkernel BUG at %s:%d! =7FELF/kaczorek/linux-2.4-xfs/linux/include/linux/file.hkernel BUG at %s:%d! procnetsysvipcsysfsdriverbus/proc/kaczorek/linux-2.4-xfs/linux/include/linu= x/dcache.hkernel BUG at %s:%d! %08lx-%08lx %s %08lx %s %lu/kaczorek/linux-2.4-xfs/linux/include/linux/dcac= he.hkernel BUG at %s:%d! block_group >=3D groups_count - block_group =3D %d, groups_count =3D %luext= 2_get_group_descGroup descriptor not loaded - block_group =3D %d, group_des= c =3D %lu, desc =3D %luCannot read block bitmap - block_group =3D %d, block= _bitmap =3D %luread_block_bitmapblock_group !=3D block_bitmap_number__load_= block_bitmapload_block_bitmapFreeing blocks not in datazone - block =3D %lu= , count =3D %luext2_free_blocksFreeing blocks in system zones - Block =3D %= lu, count =3D %lubit already cleared for block %luext2_free_blocks: nonexis= tent deviceAllocating block in system zone - block =3D %uext2_new_blockbit = already set for block %dblock(%d) >=3D blocks count(%d) - block_group =3D %= d, es =3D=3D %p Free blocks count corrupted for block group %dext2_new_bloc= k: nonexistent devicerec_len is smaller than minimalunaligned directory ent= rybad entry in directory #%lu: %s - offset=3D%lu, inode=3D%lu, rec_len=3D%d= , name_len=3D%dext2_check_pagedirectory entry across blocksentry in directo= ry #%lu spans the page boundaryoffset=3D%lu, inode=3D%luinode out of bounds= rec_len is too small for name_lensize of directory #%lu is not a multiple o= f chunk size/kaczorek/linux-2.4-xfs/linux/include/asm/highmem.hkernel BUG a= t %s:%d! /kaczorek/linux-2.4-xfs/linux/include/asm/highmem.hkernel BUG at %s:%d! CD001CDROM<4>Logical zone size(%d) < hardware blocksize(%u) <4>Warning: defective CD-ROM (volume sequence number %d). Enabling "cruft" = mount option. <4>Warning: defective CD-ROM. Enabling "cruft" mount option. /kaczorek/linux-2.4-xfs/linux/include/asm/highmem.hkernel BUG at %s:%d! defaultiso8859-1vs-4030: is_reusable: there is no so many bitmap blocks: bl= ock=3D%lu, bitmap_nr=3D%d 12290PAP-12290: balance_leaf: insert_size is still not 0 (%d)12285PAP-12285= : balance_leaf: insert_size must be 0 (%d)PAP-12280: balance_leaf: insert_s= ize for indirect item must be %d, not %dPAP-12275: balance_leaf: insert siz= e must not be %dPAP-12270: balance_leaf: CFL[0]/L[0] must be specifiedPAP-1= 2260: balance_leaf: insert_size is 0 alreadyPAP-12235: balance_leaf: pos_in= _item must be equal to ih_item_lenPAP-12240: balance_leaf: unexpected value= returned by leaf_move_items (%d)PAP-12210: balance_leaf: ih must be 0PAP-1= 2225: balance_leaf: item too short or insert_size <=3D 0PAP-12230: balance_= leaf: invalid action with indirect itemPAP-12220: balance_leaf: there are n= o so much entries (%d), only %dPAP-12215: balance_leaif: insert_size is alr= eady 0PAP-12205: balance_leaf: non-direct item can not be broken when inser= tingPAP-12200: balance_leaf: snum[%d] =3D=3D %d. Must be > 0do_balancevs-12= 195: balance_leaf: CFR not initializedPAP-12190: balance_leaf: lnum and rnu= m must not be zeroPAP-12185: balance_leaf: blknum can not be %d. It must be= >=3D 0PAP-12165: balance_leaf: directory item must be first item of node w= hen pasting is in 0th positionPAP-12155: balance_leaf: invalid position to = paste. ih_item_len=3D%d, pos_in_item=3D%dPAP-12160: balance_leaf: paste mor= e than one unformatted node pointerPAP-12145: balance_leaf: illegal paramet= r in case of a directoryPAP-12150: balance_leaf: no enough of entries to sh= ift to R[0]: rbytes=3D%d, entry_count=3D%dPAP-12135: balance_leaf: only dir= ect item can be split. (%h)PAP-12100: balance_leaf: incorrect position to p= aste: item_len=3D%d, pos_in_item=3D%dPAP-12120: balance_leaf: item must be = merge-able with left neighboring itemPAP-12110: balance_leaf: pasting more = than 1 unformatted node pointer into indirect itemPAP-12105: balance_leaf: = there is nothing to paste into L[0]. insert_size=3D%dPAP-12125: balance_lea= f: no place for paste. pos_in_item=3D%dPAP-12095: balance_leaf: there is no= thing to shift to L[0]. lbytes=3D%dPAP-12090: balance_leaf: illegal paramet= er in case of a directoryPAP-12075: balance_leaf: only direct inserted item= can be broken. %hPAP-12085: balance_leaf: there is nothing to insert into = S[0]: ih_item_len=3D%dPAP-12080: balance_leaf: there is nothing to insert i= nto L[0]: ih_item_len=3D%dPAP-12295: make_empty_node: pointer to the buffer= is NULLvs-12300: get_FEB: FEB list is emptystore_thrown deals with dirty b= uffer PAP-12340: do_balance: locked buffers in TBPAP-12350: do_balance: insert_si= ze =3D=3D 0, mode =3D=3D %cvs-7002: search_by_entry_key: no path to herevs-= 7005: search_by_entry_key: found item %h is not directory item or does not = belong to the same directory as key %knamei.ckernel BUG at %s:%d! delete_inodeinode.ckernel BUG at %s:%d! file.ckernel BUG at %s:%d! vs-8110: get_num_ver: direct item length is %d. It can not be longer than %= dvs-8125: are_leaves_removable: item number must be 1: it is %dvs-8130: are= _leaves_removable: first directory item can not be removed until directory = is not emptyfix_node.ckernel BUG at %s:%d! super.ckernel BUG at %s:%d! reiserfs0x%Lx%Lu(%Lu)DIRDIRECTINDUNKNOWNSD[%d %d %s %s][NULL]*NEW* *OLD*%s,= item_len %d, item_location %d, free_space(entry_count) %d"%s"=3D=3D>[%d %d= ]level=3D%d, nr_items=3D%d, free_space=3D%d rdkey LOCKEDDIRTYUPTODATEdev %s= , size %d, blocknr %ld, count %d, list %d, state 0x%lx, page %p, (%s, %s, %= s)!UPTODATECLEANUNLOCKED[dc_number=3D%d, dc_size=3D%u]<4>%s=D0=EB=16=C0=AB= =EB=16=C0=AB=EB=16=C0=AB=EB=16=C0=AB=EB=16=C0=AB=EB=16=C0=AB=EB=16=C0=AB=EB= =16=C0=AB=EB=16=C0=AB=EB=16=C0=AB=EB=16=C0=AB=EB=16=C0=AB=EB=16=C0=AB=EB=16= =C0=AB=EB=16=C0=AB=EB=16=C0=AB=EB=16=C0=AB=EB=16=C0=AB=EB=16=C0=AB=EB=16=C0= =AB=EB=16=C0=AB=EB=16=C0=AB=EB=16=C0=E3=EB=16=C0=AB=EB=16=C0=AB=EB=16=C0=AB= =EB=16=C0=AB=EB=16=C0=AB=EB=16=C0=F8=EB=16=C0=AB=EB=16=C0=AB=EB=16=C0=98=EB= =16=C0=AB=EB=16=C0=AB=EB=16=C0=AB=EB=16=C0=AB=EB=16=C0=AB=EB=16=C0=AB=EB=16= =C0=AB=EB=16=C0=AB=EB=16=C0=10=EC=16=C0=AB=EB=16=C0=AB=EB=16=C0=AB=EB=16=C0= =AB=EB=16=C0%=EC=16=C0@=EC=16=C0<7>%s0=ED=16=C0=0B=ED=16=C0=0B=ED=16=C0=0B= =ED=16=C0=0B=ED=16=C0=0B=ED=16=C0=0B=ED=16=C0=0B=ED=16=C0=0B=ED=16=C0=0B=ED= =16=C0=0B=ED=16=C0=0B=ED=16=C0=0B=ED=16=C0=0B=ED=16=C0=0B=ED=16=C0=0B=ED=16= =C0=0B=ED=16=C0=0B=ED=16=C0=0B=ED=16=C0=0B=ED=16=C0=0B=ED=16=C0=0B=ED=16=C0= =0B=ED=16=C0C=ED=16=C0=0B=ED=16=C0=0B=ED=16=C0=0B=ED=16=C0=0B=ED=16=C0=0B= =ED=16=C0X=ED=16=C0=0B=ED=16=C0=0B=ED=16=C0=F8=EC=16=C0=0B=ED=16=C0=0B=ED= =16=C0=0B=ED=16=C0=0B=ED=16=C0=0B=ED=16=C0=0B=ED=16=C0=0B=ED=16=C0=0B=ED=16= =C0p=ED=16=C0=0B=ED=16=C0=0B=ED=16=C0=0B=ED=16=C0=0B=ED=16=C0=85=ED=16=C0= =A0=ED=16=C0prints.ckernel BUG at %s:%d! stree.ckernel BUG at %s:%d! PAP-14100: get_new_buffer: not free or dirty buffer %b for the new blockvs-= 14055: direct2indirect: direct item expected(%k), found %hPAP-14050: direct= 2indirect: direct item (%k) not foundPAP-14030: direct2indirect: pasted or = inserted byte exists in the treetail_conversion.ckernel BUG at %s:%d! journal.ckernel BUG at %s:%d! item_ops.ckernel BUG at %s:%d! ioctl.ckernel BUG at %s:%d! devptsavl_object_tavl_entry_tpage_buf.ckernel BUG at %s:%d! page_buf_io.ckernel BUG at %s:%d! Warning: buffer 0x%p with weird blockno (%ld) =02=04=05=06=08=0C=10=14=16 (08@HLPRSTXZ\`d|=8Cxfs_difree: agno >=3D mp->m_= sb.sb_agcount (%d >=3D %d) on %s. Returning EINVAL.xfs_difree: inode !=3D = XFS_AGINO_TO_INO() (%d !=3D %d) on %s. Returning EINVAL.xfs_difree: agbno = >=3D mp->m_sb.sb_agblocks (%d >=3D %d) on %s. Returning EINVAL.xfs_difree:= xfs_ialloc_read_agi() returned an error %d on %s. Returning error.xfs_dif= ree: xfs_inobt_lookup_le returned() an error %d on %s. Returning error.xf= s_difree: xfs_inobt_get_rec() returned an error %d on %s. Returning error= .xfs_difree: xfs_inobt_update() returned an error %d on %s. Returning err= or.=04=08=0C=10=14=18=1C $((=01=04=06=08=0C=10xfshashxfs_iget_core: ambiguo= us vns: vp/0x%p, invp/0x%pxfs_iget.ckernel BUG at %s:%d! /kaczorek/linux-2.4-xfs/linux/include/linux/file.hkernel BUG at %s:%d! =C8=9B=1E=C0=12=9C=1E=C0c=9C=1E=C0=B0=9C=1E=C0=B0=9C=1E=C0=B0=9C=1E=C0=B0= =9C=1E=C0=B0=9C=1E=C0=B0=9C=1E=C0=B0=9C=1E=C0=B0=9C=1E=C0=B0=9C=1E=C0=B0=9C= =1E=C0=B0=9C=1E=C0=B0=9C=1E=C0=B0=9C=1E=C0=B0=9C=1E=C0=B0=9C=1E=C0=B0=9C=1E= =C0=B0=9C=1E=C0=B0=9C=1E=C0=B0=9C=1E=C0=B0=9C=1E=C0=B0=9C=1E=C0=B0=9C=1E=C0= =B0=9C=1E=C0=B0=9C=1E=C0=B0=9C=1E=C0=B0=9C=1E=C0=B0=9C=1E=C0=B0=9C=1E=C0=C0= =9C=1E=C0/kaczorek/linux-2.4-xfs/linux/include/asm/highmem.hkernel BUG at %= s:%d! debug.ckernel BUG at %s:%d! util.ckernel BUG at %s:%d! sysvipc/msgmsg.ckernel BUG at %s:%d! sysvipc/semsem.ckernel BUG at %s:%d! sysvipc/shmshm.ckernel BUG at %s:%d! <4>Warning: null TTY for (%s) in %s <4>Warning: dev (%s) tty->count(%d) !=3D #fd's(%d) in %s ll_rw_blk.ckernel BUG at %s:%d! /kaczorek/linux-2.4-xfs/linux/include/asm/highmem.hkernel BUG at %s:%d! ide-dma.ckernel BUG at %s:%d! Internal error %s %d=20 Internal error in file %s, line %d. VTOBMPOOL/kaczorek/linux-2.4-xfs/linux/include/asm/pci.hkernel BUG at %s:%d! internal error: cmd=3D%02x !=3D %02x=3D(vdsp[0] >> 24) 810810a815820825825a860875875J885895896895a875a1510D1010-331010-66devtbl<6>= sym53c8xx: 53c%s state OFF thus not attached Debug flags 0x%x, verbosity level %d caddytraypop-upchangercartridge changersr%i: scsi-1 drive cdda xa/form2 cd/rw dvd-ram writer sr%i: scsi3-mmc drive: %dx/%dx %s%s%s%s%= s%s egamdavga+cgaVGA+EGA*CGAEGA+*MDA=86^$=C0c^$=C0=90^$=C0=B6^$=C0=D0^$=C0 J/= =C0=B0Z$=C0`[$=C0=B0l$=C0=B0l$=C0=B0l$=C0=D0]$=C0=90j$=C0=B0l$=C0`_$=C0 c$= =C0=C0g$=C0=10`$=C0=80h$=C0=B0i$=C00j$=C0=F0[$=C0=A0\$=C0socket:sockfs[%lu]= /kaczorek/linux-2.4-xfs/linux/include/linux/file.hkernel BUG at %s:%d! sock<2>sk_init: Cannot create sock SLAB cache!/kaczorek/linux-2.4-xfs/linux= /include/asm/highmem.hkernel BUG at %s:%d! skput:over: %p:%d put:%d dev:%sskbuff.ckernel BUG at %s:%d! <4>Warning: kfree_skb passed an skb still on a list (from %p). <4>Warning: kfree_skb on hard IRQ %p /kaczorek/linux-2.4-xfs/linux/include/asm/highmem.hkernel BUG at %s:%d! /kaczorek/linux-2.4-xfs/linux/include/linux/file.hkernel BUG at %s:%d! dev.ckernel BUG at %s:%d! <7>Dead loop on virtual device %s, fix it urgently! face |bytes packets errs drop fifo frame compressed multicast|bytes = packets errs drop fifo colls carrier compressed /kaczorek/linux-2.4-xfs/linux/include/linux/skbuff.hkernel BUG at %s:%d! =06=0C=03=0C=05=05=05/kaczorek/linux-2.4-xfs/linux/include/linux/skbuff.hke= rnel BUG at %s:%d! /kaczorek/linux-2.4-xfs/linux/include/linux/skbuff.hkernel BUG at %s:%d! sch_%s/kaczorek/linux-2.4-xfs/linux/include/linux/skbuff.hkernel BUG at %s:= %d! net/pschedcls_%s/kaczorek/linux-2.4-xfs/linux/include/linux/skbuff.hkernel = BUG at %s:%d! ?<2>Bug in ip_route_input_slow(). Please, report /kaczorek/linux-2.4-xfs/linux/include/linux/skbuff.hkernel BUG at %s:%d! inet_peer_cacheinetpeer.ckernel BUG at %s:%d! TcpExt:TCPUDPICMP/kaczorek/linux-2.4-xfs/linux/include/linux/skbuff.hkernel= BUG at %s:%d! /kaczorek/linux-2.4-xfs/linux/include/linux/skbuff.hkernel BUG at %s:%d! /kaczorek/linux-2.4-xfs/linux/include/linux/skbuff.hkernel BUG at %s:%d! /kaczorek/linux-2.4-xfs/linux/include/linux/skbuff.hkernel BUG at %s:%d! /kaczorek/linux-2.4-xfs/linux/include/linux/skbuff.hkernel BUG at %s:%d! /kaczorek/linux-2.4-xfs/linux/include/linux/skbuff.hkernel BUG at %s:%d! /kaczorek/linux-2.4-xfs/linux/include/net/tcp.hkernel BUG at %s:%d! udp.ckernel BUG at %s:%d! /kaczorek/linux-2.4-xfs/linux/include/linux/skbuff.hkernel BUG at %s:%d! 0123456789ABCDEFIP address HW type Flags HW address = Mask Device icmp.ckernel BUG at %s:%d! =B0=D3'=C0 =D4'=C0=A5=D3'=C0=A5=D3'=C0=90=D3'=C00=D4'=C0@=D4'=C0=A5=D3'=C0= =A5=D3'=C0P=D4'=C0/kaczorek/linux-2.4-xfs/linux/include/linux/skbuff.hkerne= l BUG at %s:%d! /kaczorek/linux-2.4-xfs/linux/include/linux/skbuff.hkernel BUG at %s:%d! %05x/kaczorek/linux-2.4-xfs/linux/include/linux/dcache.hkernel BUG at %s:%d! /kaczorek/linux-2.4-xfs/linux/include/linux/skbuff.hkernel BUG at %s:%d! /kaczorek/linux-2.4-xfs/linux/include/linux/skbuff.hkernel BUG at %s:%d! )=C0nomce=F0Y.=C0=93=13)=C0=A7=13)=C0=01=C0=13)=C0=02=C4=13)=C0=FF`Y.=C0=CF= =13)=C0=14)=C0=01#=14)=C0=02-=14)=C0=FF0Y.=C07=14)=C0=03J=14)=C0=047=14)=C0= =FF=FF0Y.=C0d=14)=C0=03J=14)=C0=04d=14)=C0=FF=FF=90Y.=C0w=14)=C0=03w=14)=C0= =FF=FF=FF=90Y.=C0{=14)=C0=03J=14)=C0=04=89=14)=C0=FF=FF=90Y.=C0=97=14)=C0= =03=9F=14)=C0=04=B5=14)=C0=FF=FF=C0Y.=C0=CF=14)=C0=03=DD=14)=C0=04=F2=14)= =C0=FF=FF=10Z.=C0=F9=14)=C0=A7=13)=C0=01=03=15)=C0=02=0B=15)=C0=FF=10Z.=C0= =F9=14)=C0=A7=13)=C0=01=14=15)=C0=02=1C=15)=C0=FF=10Z.=C0=F9=14)=C0=A7=13)= =C0=01%=15)=C0=02-=15)=C0=FF=84=1F)=C0=89=1F)=C0=8F=1F)=C0=96=1F)=C0=A0=1F)= =C0panic=3Dconsole=3Dreserve=3Dmemfrac=3D=E4g/=C0=E4g/=C0<6>SGI XFS with AC= Ls, EAs, quota, no debug enabled 1 warning issued. Results may not be reliable. --ikeVEW9yuYc//A+q-- From owner-linux-xfs@oss.sgi.com Wed Jan 2 11:06:02 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g02J62J18217 for linux-xfs-outgoing; Wed, 2 Jan 2002 11:06:02 -0800 Received: from lynx.adilger.int (h24-64-71-161.cg.shawcable.net [24.64.71.161]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g02J5ug18192 for ; Wed, 2 Jan 2002 11:05:56 -0800 Received: (from adilger@localhost) by lynx.adilger.int (8.11.2/8.11.2) id g02I5cU03296; Wed, 2 Jan 2002 11:05:38 -0700 Date: Wed, 2 Jan 2002 11:05:38 -0700 From: Andreas Dilger To: Adrian Head Cc: Linux XFS Mailing List , linux-lvm@sistina.com Subject: Re: [linux-lvm] Unable to get XFS, ext3, reiserfs & LVM to coexist happily Message-ID: <20020102110538.K12868@lynx.no> Mail-Followup-To: Adrian Head , Linux XFS Mailing List , linux-lvm@sistina.com References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.4i In-Reply-To: ; from ahead@bigpond.net.au on Wed, Jan 02, 2002 at 01:51:01PM +1000 X-GPG-Key: 1024D/0D35BED6 X-GPG-Fingerprint: 7A37 5D79 BF1B CECA D44F 8A29 A488 39F5 0D35 BED6 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 1188 Lines: 34 On Jan 02, 2002 13:51 +1000, Adrian Head wrote: > > 2.4.17-xfs > + lvm-1.0.1 upgrade > (with LVM_VFS_ENHANCEMENT) > While source volume mounted: > * Can create ext3 snapshot? | Cannot test > * Can mount a ext3 snapshot? | Cannot test > * Can create resierfs snapshot? | Cannot test > undefined reference to `fsync_dev_lockfs' > undefined reference to `unlockfs' Note that you need to apply the VFS-lock patch AFTER the lvm-1.0.1 upgrade patch, otherwise that patch will reverse the VFS-lock patch! > When source & snapshot mounted: > * Cause oops when snapshot overflows? | > - ext3 | Oops > btp 5 (bdflush) You should try ext3 from 2.4.18, or get it from the ext3 CVS (at cvs.gkernel.sourceforge.net:/cvsroot/gkernel ext3). It has fixes for a number of problems caused by error conditions while running. If there is still a problem with ext3 oopsing with a full snapshot (which is essentially an oops because of an I/O error on the disk) then please file a separate bug report to the ext3 developers (ext2-devel@lists.sourceforge.net). Cheers, Andreas -- Andreas Dilger http://sourceforge.net/projects/ext2resize/ http://www-mddsp.enel.ucalgary.ca/People/adilger/ From owner-linux-xfs@oss.sgi.com Wed Jan 2 11:14:29 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g02JET918494 for linux-xfs-outgoing; Wed, 2 Jan 2002 11:14:29 -0800 Received: from pa42.warszawa.sdi.tpnet.pl (qmailr@pa42.warszawa.sdi.tpnet.pl [213.25.213.42]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g02JEJg18470 for ; Wed, 2 Jan 2002 11:14:19 -0800 Received: (qmail 648 invoked by uid 1000); 2 Jan 2002 18:14:17 -0000 Date: Wed, 2 Jan 2002 19:14:17 +0100 From: Piotrek Kaczmarek To: linux-xfs@oss.sgi.com Subject: 2.4.10-pre2-xfs Oops on mount (sorry) Message-ID: <20020102191417.A638@msg.beta.pl> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="ReaqsoxgOBHFXBhH" Content-Disposition: inline User-Agent: Mutt/1.2.5i Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 2045 Lines: 57 --ReaqsoxgOBHFXBhH Content-Type: text/plain; charset=us-ascii Content-Disposition: inline By mistake i put vmlinux as a ksymoops input, sorry for that, now proper output attached. Cheers, Piotr Kaczmarek --ReaqsoxgOBHFXBhH Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=output ksymoops 2.4.2 on i586 2.4.10-pre2-xfs. Options used -v /boot/vmlinux-2.4.10-pre2-xfs (specified) -k /proc/ksyms (default) -l /proc/modules (default) -o /lib/modules/2.4.10-pre2-xfs/ (default) -m /boot/System.map-2.4.10-pre2-xfs (specified) Unable to handle kernel NULL pointer dereference at virtual address 0000012a c01c5948 *pde = 00000000 Oops: 0000 CPU: 0 EIP: 0010:[xfs_iget+168/352] EFLAGS: 00010246 eax: c02d2000 ebx: ffffffe8 ecx: 00000019 edx: c02d2000 esi: 00000000 edi: c132cbd0 ebp: c132cbbc esp: c7d278f8 ds: 0018 es: 0018 ss: 0018 Process mount (pid: 27, stackpage=c7d27000) Stack: 00000000 00000000 c669b740 226d0600 00000000 c7ed7400 c01d28e4 c7ed7400 00000000 226d0600 00000000 00000000 c7d2794c 00000000 00000000 02000000 00000000 02067562 00000000 00000022 00000008 c690abf4 00000003 00000000 Call Trace: [xlog_recover_process_iunlinks+308/672] [xfs_log_force+87/96] [xlog_recover_finish+118/160] [xfs_log_mount_finish+33/48] [xfs_mountfs+2070/3744] Code: 66 83 bb 42 01 00 00 00 75 10 66 81 a3 28 01 00 00 f7 ff 53 Using defaults from ksymoops -t elf32-i386 -a i386 Code; 00000000 Before first symbol 00000000 <_EIP>: Code; 00000000 Before first symbol 0: 66 83 bb 42 01 00 00 cmpw $0x0,0x142(%ebx) Code; 00000006 Before first symbol 7: 00 Code; 00000008 Before first symbol 8: 75 10 jne 1a <_EIP+0x1a> 0000001a Before first symbol Code; 0000000a Before first symbol a: 66 81 a3 28 01 00 00 andw $0xfff7,0x128(%ebx) Code; 00000010 Before first symbol 11: f7 ff Code; 00000012 Before first symbol 13: 53 pushl %ebx --ReaqsoxgOBHFXBhH-- From owner-linux-xfs@oss.sgi.com Wed Jan 2 11:16:26 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g02JGQF18659 for linux-xfs-outgoing; Wed, 2 Jan 2002 11:16:26 -0800 Received: from zork.zork.net (zork.zork.net [64.81.65.8]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g02JGNg18637 for ; Wed, 2 Jan 2002 11:16:23 -0800 Received: from localhost (zork.zork.net) [127.0.0.1] by zork.zork.net with esmtp (Exim 3.33 #1 (Debian)) id 16Lpw5-0000yp-00; Wed, 02 Jan 2002 10:16:21 -0800 To: linux-xfs@oss.sgi.com Subject: file corruption during emacs build on XFS logical volume From: Sean Neakums X-Message-Flag: Message text advisory: DISCLOSURE OF TRADE SECRET(S), ULTERIOR MOTIVES X-Mailer: Norman Date: Wed, 02 Jan 2002 18:16:21 +0000 Message-ID: <6u4rm4r53e.fsf@zork.zork.net> User-Agent: Gnus/5.090004 (Oort Gnus v0.04) Emacs/21.1 (i386-debian-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 930 Lines: 20 I'm getting some random file corruption on one of my XFS LVM volumes, leading to things like an emacs binary that is filled with runs of NULs and pieces of deleted files. I've been able to build successfully on an ext2 logical volume on the same machine with the same kernel. I've tried both a kernel built from a 2.4.17 and a 2.4.16 CVS pull, built with gcc 2.95.4 from Debian unstable. I still have a 2.4.14-pre7 lying around, so I'll try an emacs build on that, too. I'm not really sure how to start tracking this down; I don't even have a simple test case to reproduce it apart from doing `apt-get source --build emacs21', so suggestions for things to try and information to gather would be appreciated. Sean. -- ///////////////// | | The spark of a pin | (require 'gnu) | dropping, falling feather-like. \\\\\\\\\\\\\\\\\ | | There is too much noise. From owner-linux-xfs@oss.sgi.com Wed Jan 2 11:24:47 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g02JOll19430 for linux-xfs-outgoing; Wed, 2 Jan 2002 11:24:47 -0800 Received: from deliverator.sgi.com (deliverator.sgi.com [204.94.214.10]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g02JOhg19408 for ; Wed, 2 Jan 2002 11:24:43 -0800 Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id KAA26825 for ; Wed, 2 Jan 2002 10:24:26 -0800 (PST) mail_from (lord@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id MAA3974314; Wed, 2 Jan 2002 12:23:24 -0600 (CST) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id MAA25162; Wed, 2 Jan 2002 12:23:24 -0600 (CST) Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id g02IIP923172; Wed, 2 Jan 2002 12:18:25 -0600 Subject: Re: file corruption during emacs build on XFS logical volume From: Steve Lord To: Sean Neakums Cc: linux-xfs@oss.sgi.com In-Reply-To: <6u4rm4r53e.fsf@zork.zork.net> References: <6u4rm4r53e.fsf@zork.zork.net> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/1.0.0.99+cvs.2001.12.18.08.57 (Preview Release) Date: 02 Jan 2002 12:18:25 -0600 Message-Id: <1009995505.14223.9.camel@jen.americas.sgi.com> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 1244 Lines: 31 On Wed, 2002-01-02 at 12:16, Sean Neakums wrote: > I'm getting some random file corruption on one of my XFS LVM volumes, > leading to things like an emacs binary that is filled with runs of > NULs and pieces of deleted files. I've been able to build > successfully on an ext2 logical volume on the same machine with the > same kernel. I've tried both a kernel built from a 2.4.17 and a > 2.4.16 CVS pull, built with gcc 2.95.4 from Debian unstable. I still > have a 2.4.14-pre7 lying around, so I'll try an emacs build on that, > too. > > I'm not really sure how to start tracking this down; I don't even have > a simple test case to reproduce it apart from doing `apt-get source > --build emacs21', so suggestions for things to try and information to > gather would be appreciated. How much memory do you have on this machine, and how many cpus? And can you tell if the build is doing things in parallel or is just single threaded? I don't think there is much point going back to earlier kernels to be honest. I will fire up an emacs build here, on a non-lvm partition for starters. Steve -- Steve Lord voice: +1-651-683-3511 Principal Engineer, Filesystem Software email: lord@sgi.com From owner-linux-xfs@oss.sgi.com Wed Jan 2 12:02:58 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g02K2wb23603 for linux-xfs-outgoing; Wed, 2 Jan 2002 12:02:58 -0800 Received: from eagle.oceana.com (eagle.oceana.com [208.17.123.12]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g02K2og23581 for ; Wed, 2 Jan 2002 12:02:51 -0800 Received: from oceana.com (ken.oceana.com [192.168.10.26]) by eagle.oceana.com (8.12.1/8.12.1) with ESMTP id g02J2hMJ001131; Wed, 2 Jan 2002 14:02:43 -0500 Message-ID: <3C3359DF.714145FD@oceana.com> Date: Wed, 02 Jan 2002 14:05:03 -0500 From: Ken Murchison Organization: Oceana Matrix Ltd. X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,pdf MIME-Version: 1.0 To: Seth Mos CC: linux-xfs@oss.sgi.com, Keith Owens Subject: Re: Random Kernel Panic on Boot References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 2230 Lines: 60 Seth Mos wrote: > > On Wed, 2 Jan 2002, Ken Murchison wrote: > > > > > > > Mike Baptiste wrote: > > > > > > I've got a new system I'm working to put into production and I have one > > > nagging problem that I'm trying to resolve and perhaps one of you has > > > seen this or can point me in the right direction. I know this may not > > > be an XFS problem but since I'm using the XFS installer I figured I'd > > > start here. > > > > [...] > > > > > The problem is this: When booting either the smp or enterprise kernels > > > (stock RH 2.4.9-XFS from the XFS installer CD), I get random kernel > > > panics. Maybe 3 out of 4 boots, at varying points in Interactive boot > > > (from LVM activiation forward), I'll get a Kernel Panic from the DAC960 > > > driver: > > > > > > DAC960#0: SegmentNumber != SegmentCount > > > > I have the same problem with my quad Xeon. No problem with RH > > 2.4.3-SGI_XFS_1.0.1 or 2.4.14-SGI_XFS_1.0.2. I haven't been able to try > > a stock RH 2.4.9-13 (without the XFS bits) because all of my filesystems > > are XFS > > I don't think this is XFS related at all. The aacraid driver also broke in > 2.4.9. Better stick with something else or patch in a newer dac960 driver. > > I think there was a block layer change in 2.4.9 which broke some drivers. > The kernel had to be released soon because of the security issues which > might have caused this slip. I decided to check with RedHat, which I should have done in the first place, and I found this: http://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=56603 I haven't tested the mem=800M fix (I have 1G), but since the kernel is now way past 2.4.9, should I care about a fix? 2.4.14-SGI_XFS_1.0.2 is working fine for me right now, so I'm assuming that this *might* be better than running 2.4.3-SGI_XFS_1.0.1. Does anybody know where I can find a list of RedHat's improvements/fixes/hacks to the stock kernels? I'd really like to know if there are any compelling reasons to track their kernels, or just go with the latest SGI_XFS RPMS. Ken -- Kenneth Murchison Oceana Matrix Ltd. Software Engineer 21 Princeton Place 716-662-8973 x26 Orchard Park, NY 14127 --PGP Public Key-- http://www.oceana.com/~ken/ksm.pgp From owner-linux-xfs@oss.sgi.com Wed Jan 2 12:30:54 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g02KUss24167 for linux-xfs-outgoing; Wed, 2 Jan 2002 12:30:54 -0800 Received: from zork.zork.net (zork.zork.net [64.81.65.8]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g02KUmg24145 for ; Wed, 2 Jan 2002 12:30:49 -0800 Received: from localhost (zork.zork.net) [127.0.0.1] by zork.zork.net with esmtp (Exim 3.33 #1 (Debian)) id 16Lr66-00020x-00; Wed, 02 Jan 2002 11:30:46 -0800 To: Linux XFS Subject: Re: file corruption during emacs build on XFS logical volume References: <6u4rm4r53e.fsf@zork.zork.net> <1009995505.14223.9.camel@jen.americas.sgi.com> From: Sean Neakums X-Message-Flag: Message text advisory: RANTING, HATE SPEECH X-Mailer: Norman Mail-Followup-To: Linux XFS Date: Wed, 02 Jan 2002 19:30:46 +0000 In-Reply-To: <1009995505.14223.9.camel@jen.americas.sgi.com> (Steve Lord's message of "02 Jan 2002 12:18:25 -0600") Message-ID: <6uy9jgpn2x.fsf@zork.zork.net> User-Agent: Gnus/5.090004 (Oort Gnus v0.04) Emacs/21.1 (i386-debian-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 1912 Lines: 42 begin Steve Lord quotation: > On Wed, 2002-01-02 at 12:16, Sean Neakums wrote: >> I'm getting some random file corruption on one of my XFS LVM volumes, >> leading to things like an emacs binary that is filled with runs of >> NULs and pieces of deleted files. I've been able to build >> successfully on an ext2 logical volume on the same machine with the >> same kernel. I've tried both a kernel built from a 2.4.17 and a >> 2.4.16 CVS pull, built with gcc 2.95.4 from Debian unstable. I still >> have a 2.4.14-pre7 lying around, so I'll try an emacs build on that, >> too. >> >> I'm not really sure how to start tracking this down; I don't even >> have a simple test case to reproduce it apart from doing `apt-get >> source --build emacs21', so suggestions for things to try and >> information to gather would be appreciated. > > How much memory do you have on this machine, and how many cpus? 256M: two 128M DIMMs. I ran two passes of memtest a couple days ago with no errors. I have one CPU, a PII-450. The kernel is a UP build, with Robert Love's preempt patch applied, as was the 2.4.16 kernel. > And can you tell if the build is doing things in parallel or is just > single threaded? I'm certain it's a single-threaded build. I grepped for -j, and got nothing except some stuff regarding jpeg libraries. > I don't think there is much point going back to earlier kernels to > be honest. I will fire up an emacs build here, on a non-lvm > partition for starters. I went back to my 2.4.14-pre7 CVS pull, and the build went perfectly on the XFS volume. But it seems that that kernel doesn't have preempt applied, so I'll rebuild 2.4.17-xfs without the patch, to eliminate that possibility. -- ///////////////// | | The spark of a pin | (require 'gnu) | dropping, falling feather-like. \\\\\\\\\\\\\\\\\ | | There is too much noise. From owner-linux-xfs@oss.sgi.com Wed Jan 2 13:45:05 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g02Lj5u25624 for linux-xfs-outgoing; Wed, 2 Jan 2002 13:45:05 -0800 Received: from mail.ocs.com.au (mail.ocs.com.au [203.34.97.2]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g02Lj0g25592 for ; Wed, 2 Jan 2002 13:45:00 -0800 Received: (qmail 12319 invoked from network); 2 Jan 2002 20:44:56 -0000 Received: from ocs3.intra.ocs.com.au (192.168.255.3) by mail.ocs.com.au with SMTP; 2 Jan 2002 20:44:56 -0000 Received: by ocs3.intra.ocs.com.au (Postfix, from userid 16331) id 6FB88300090; Thu, 3 Jan 2002 07:44:56 +1100 (EST) Received: from ocs3.intra.ocs.com.au (localhost [127.0.0.1]) by ocs3.intra.ocs.com.au (Postfix) with ESMTP id 4CDAB94 for ; Thu, 3 Jan 2002 07:44:56 +1100 (EST) X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 From: Keith Owens To: linux-xfs@oss.sgi.com Subject: ANNOUCEMENT: XFS support to the -mjc 2.4.17 branch (fwd) Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 03 Jan 2002 07:44:51 +1100 Message-ID: <9313.1010004291@ocs3.intra.ocs.com.au> Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 478 Lines: 21 For those not on linux-kernel, the -mjc branch is trying to take up on 2.4 where -ac left off. ------- Forwarded Message Return-Path: Date: Wed, 2 Jan 2002 13:06:41 -0500 (EST) From: Shawn Starr To: linux-kernel@vger.kernel.org Subject: ANNOUCEMENT: XFS support to the -mjc 2.4.17 branch It's been running for 8 hours. There's still a little work to go but so far It's up. Shawn. ------- End of Forwarded Message From owner-linux-xfs@oss.sgi.com Wed Jan 2 15:04:21 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g02N4LZ27033 for linux-xfs-outgoing; Wed, 2 Jan 2002 15:04:21 -0800 Received: from burgers.bubbanfriends.org (IDENT:postfix@burgers.bubbanfriends.org [216.140.122.113]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g02N4Fg27011 for ; Wed, 2 Jan 2002 15:04:15 -0800 Received: by burgers.bubbanfriends.org (Postfix, from userid 500) id 28038401A58; Wed, 2 Jan 2002 17:04:13 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by burgers.bubbanfriends.org (Postfix) with ESMTP id 26B772400233 for ; Wed, 2 Jan 2002 17:04:13 -0500 (EST) Date: Wed, 2 Jan 2002 17:04:13 -0500 (EST) From: Mike Burger To: Subject: Re: ANNOUCEMENT: XFS support to the -mjc 2.4.17 branch (fwd) In-Reply-To: <9313.1010004291@ocs3.intra.ocs.com.au> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 613 Lines: 27 Alan Cox isn't working on kernel mods, anymore? On Thu, 3 Jan 2002, Keith Owens wrote: > For those not on linux-kernel, the -mjc branch is trying to take up on > 2.4 where -ac left off. > > ------- Forwarded Message > > Return-Path: > Date: Wed, 2 Jan 2002 13:06:41 -0500 (EST) > From: Shawn Starr > To: linux-kernel@vger.kernel.org > Subject: ANNOUCEMENT: XFS support to the -mjc 2.4.17 branch > > > It's been running for 8 hours. There's still a little work to go but so > far It's up. > > Shawn. > > > ------- End of Forwarded Message > > > From owner-linux-xfs@oss.sgi.com Wed Jan 2 15:10:48 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g02NAmU27264 for linux-xfs-outgoing; Wed, 2 Jan 2002 15:10:48 -0800 Received: from deliverator.sgi.com (deliverator.sgi.com [204.94.214.10]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g02NAjg27242 for ; Wed, 2 Jan 2002 15:10:45 -0800 Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id OAA15046 for ; Wed, 2 Jan 2002 14:10:28 -0800 (PST) mail_from (lord@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id QAA3992440; Wed, 2 Jan 2002 16:09:26 -0600 (CST) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id QAA43240; Wed, 2 Jan 2002 16:09:26 -0600 (CST) Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id g02M4QW01303; Wed, 2 Jan 2002 16:04:26 -0600 Subject: Re: ANNOUCEMENT: XFS support to the -mjc 2.4.17 branch (fwd) From: Steve Lord To: Mike Burger Cc: linux-xfs@oss.sgi.com In-Reply-To: References: Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/1.0.0.99+cvs.2001.12.18.08.57 (Preview Release) Date: 02 Jan 2002 16:04:26 -0600 Message-Id: <1010009066.1281.1.camel@jen.americas.sgi.com> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 385 Lines: 14 On Wed, 2002-01-02 at 16:04, Mike Burger wrote: > Alan Cox isn't working on kernel mods, anymore? > No, he decided not to do the 2.4 leg, and I can't blame him, think what a few years of merging countless patches would do to you. Steve -- Steve Lord voice: +1-651-683-3511 Principal Engineer, Filesystem Software email: lord@sgi.com From owner-linux-xfs@oss.sgi.com Wed Jan 2 15:11:32 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g02NBWT27393 for linux-xfs-outgoing; Wed, 2 Jan 2002 15:11:32 -0800 Received: from mxzilla2.xs4all.nl (mxzilla2.xs4all.nl [194.109.6.50]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g02NBPg27371 for ; Wed, 2 Jan 2002 15:11:25 -0800 Received: from xs3.xs4all.nl (knuffie@xs3.xs4all.nl [194.109.6.44]) by mxzilla2.xs4all.nl (8.12.0/8.12.0) with ESMTP id g02MBKPG044967; Wed, 2 Jan 2002 23:11:20 +0100 (CET) Received: from localhost (knuffie@localhost) by xs3.xs4all.nl (8.9.0/8.9.0) with ESMTP id XAA18414; Wed, 2 Jan 2002 23:11:19 +0100 (CET) Date: Wed, 2 Jan 2002 23:11:19 +0100 (CET) From: Seth Mos To: Ken Murchison cc: linux-xfs@oss.sgi.com, Keith Owens Subject: Re: Random Kernel Panic on Boot In-Reply-To: <3C3359DF.714145FD@oceana.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 2289 Lines: 57 On Wed, 2 Jan 2002, Ken Murchison wrote: > Seth Mos wrote: > > > > On Wed, 2 Jan 2002, Ken Murchison wrote: > > > > I think there was a block layer change in 2.4.9 which broke some drivers. > > The kernel had to be released soon because of the security issues which > > might have caused this slip. > > I decided to check with RedHat, which I should have done in the first > place, and I found this: > > http://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=56603 > > I haven't tested the mem=800M fix (I have 1G), but since the kernel is > now way past 2.4.9, should I care about a fix? 2.4.14-SGI_XFS_1.0.2 is > working fine for me right now, so I'm assuming that this *might* be > better than running 2.4.3-SGI_XFS_1.0.1. The reason the driver fails is because it had problems with highmem buffers. Staying below this was the safe solution. But losing more then half of your ram if you have 2GB is not acceptable is it? > Does anybody know where I can find a list of RedHat's > improvements/fixes/hacks to the stock kernels? I'd really like to know > if there are any compelling reasons to track their kernels, or just go > with the latest SGI_XFS RPMS. ! They have a _lot_ of patches in there but their kernels tend to be fairly stable, have had a lot of testing, have support for most hardware out there of which a driver is available but is not included in the mainline tree yet (or never will). This was just bad luck I guess. The 2.4.14 XFS rpm is actually just a linus tree with XFS. So if you would checkout a CVS XFS tree you would get all the latest fixes and a 2.4.17 kernel whithout losing any features that are available in the 2.4.14 release. This kernel is not tested as much as an official release but does a have relative wide userbase of people testing it for problems. If you really need a fix that came with a later kernel this would be your best shot. Bit if your box is doing just fine there is no real hurry. The most important production database server at work is running the 2.4.9 1.0.2 release since the redhat kernel has drivers for the gigabit ethernet card included. Note that the 2.4.17 kernel has gotten a lot of decent reports and Marcelo is doing a lot of good work. Cheers Seth For Arjen van de Ven sed 's/redhat/Red Hat Linux/g' :-) From owner-linux-xfs@oss.sgi.com Wed Jan 2 15:17:32 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g02NHWs27589 for linux-xfs-outgoing; Wed, 2 Jan 2002 15:17:32 -0800 Received: from mxzilla1.xs4all.nl (mxzilla1.xs4all.nl [194.109.6.54]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g02NHRg27566 for ; Wed, 2 Jan 2002 15:17:27 -0800 Received: from xs3.xs4all.nl (knuffie@xs3.xs4all.nl [194.109.6.44]) by mxzilla1.xs4all.nl (8.12.0/8.12.0) with ESMTP id g02MHCls030338; Wed, 2 Jan 2002 23:17:12 +0100 (CET) Received: from localhost (knuffie@localhost) by xs3.xs4all.nl (8.9.0/8.9.0) with ESMTP id XAA19605; Wed, 2 Jan 2002 23:17:12 +0100 (CET) Date: Wed, 2 Jan 2002 23:17:12 +0100 (CET) From: Seth Mos To: Keith Owens cc: linux-xfs@oss.sgi.com Subject: Re: ANNOUCEMENT: XFS support to the -mjc 2.4.17 branch (fwd) In-Reply-To: <9313.1010004291@ocs3.intra.ocs.com.au> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 671 Lines: 26 On Thu, 3 Jan 2002, Keith Owens wrote: > For those not on linux-kernel, the -mjc branch is trying to take up on > 2.4 where -ac left off. > > ------- Forwarded Message > > Return-Path: > Date: Wed, 2 Jan 2002 13:06:41 -0500 (EST) > From: Shawn Starr > To: linux-kernel@vger.kernel.org > Subject: ANNOUCEMENT: XFS support to the -mjc 2.4.17 branch > > > It's been running for 8 hours. There's still a little work to go but so > far It's up. Excellent, our userbase just upped by a couple of thousand :-) That's a nice new year presemt isn't it? Happy new Year everyone. (Yeah I know I'm late). Cheers Seth From owner-linux-xfs@oss.sgi.com Wed Jan 2 15:22:57 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g02NMvu27750 for linux-xfs-outgoing; Wed, 2 Jan 2002 15:22:57 -0800 Received: from zork.zork.net (zork.zork.net [64.81.65.8]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g02NMsg27727 for ; Wed, 2 Jan 2002 15:22:54 -0800 Received: from localhost (zork.zork.net) [127.0.0.1] by zork.zork.net with esmtp (Exim 3.33 #1 (Debian)) id 16LtmZ-0004Gi-00; Wed, 02 Jan 2002 14:22:47 -0800 To: Linux XFS Subject: Re: file corruption during emacs build on XFS logical volume References: <6u4rm4r53e.fsf@zork.zork.net> <1009995505.14223.9.camel@jen.americas.sgi.com> <6uy9jgpn2x.fsf@zork.zork.net> From: Sean Neakums X-Message-Flag: Message text advisory: DISCLOSURE OF TRADE SECRET(S), HATE SPEECH X-Mailer: Norman Mail-Followup-To: Linux XFS Date: Wed, 02 Jan 2002 22:22:47 +0000 In-Reply-To: <6uy9jgpn2x.fsf@zork.zork.net> (Sean Neakums's message of "Wed, 02 Jan 2002 19:30:46 +0000") Message-ID: <6uu1u4pf48.fsf@zork.zork.net> User-Agent: Gnus/5.090004 (Oort Gnus v0.04) Emacs/21.1 (i386-debian-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 826 Lines: 20 begin Sean Neakums quotation: > begin Steve Lord quotation: >> I don't think there is much point going back to earlier kernels to >> be honest. I will fire up an emacs build here, on a non-lvm >> partition for starters. > > I went back to my 2.4.14-pre7 CVS pull, and the build went perfectly > on the XFS volume. But it seems that that kernel doesn't have > preempt applied, so I'll rebuild 2.4.17-xfs without the patch, to > eliminate that possibility. I'm now running a fresh build of 2.4.17, without the preempt patch. emacs reliably fails to build on the XFS volume, and builds successfully on the ext2 volume. -- ///////////////// | | The spark of a pin | (require 'gnu) | dropping, falling feather-like. \\\\\\\\\\\\\\\\\ | | There is too much noise. From owner-linux-xfs@oss.sgi.com Wed Jan 2 16:16:44 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g030GiQ28776 for linux-xfs-outgoing; Wed, 2 Jan 2002 16:16:44 -0800 Received: from deliverator.sgi.com (deliverator.sgi.com [204.94.214.10]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g030Gdg28754 for ; Wed, 2 Jan 2002 16:16:39 -0800 Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id PAA20270 for ; Wed, 2 Jan 2002 15:16:21 -0800 (PST) mail_from (lord@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id RAA3984916; Wed, 2 Jan 2002 17:15:19 -0600 (CST) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id RAA48425; Wed, 2 Jan 2002 17:15:19 -0600 (CST) Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id g02NAJl04925; Wed, 2 Jan 2002 17:10:19 -0600 Subject: Re: file corruption during emacs build on XFS logical volume From: Steve Lord To: Sean Neakums Cc: Linux XFS In-Reply-To: <6uu1u4pf48.fsf@zork.zork.net> References: <6u4rm4r53e.fsf@zork.zork.net> <1009995505.14223.9.camel@jen.americas.sgi.com> <6uy9jgpn2x.fsf@zork.zork.net> <6uu1u4pf48.fsf@zork.zork.net> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/1.0.0.99+cvs.2001.12.18.08.57 (Preview Release) Date: 02 Jan 2002 17:10:19 -0600 Message-Id: <1010013019.1281.6.camel@jen.americas.sgi.com> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 978 Lines: 27 On Wed, 2002-01-02 at 16:22, Sean Neakums wrote: > begin Sean Neakums quotation: > > > begin Steve Lord quotation: > >> I don't think there is much point going back to earlier kernels to > >> be honest. I will fire up an emacs build here, on a non-lvm > >> partition for starters. > > > > I went back to my 2.4.14-pre7 CVS pull, and the build went perfectly > > on the XFS volume. But it seems that that kernel doesn't have > > preempt applied, so I'll rebuild 2.4.17-xfs without the patch, to > > eliminate that possibility. > > I'm now running a fresh build of 2.4.17, without the preempt patch. > emacs reliably fails to build on the XFS volume, and builds > successfully on the ext2 volume. Doing a non lvm build here, lets see if the that works. I have my suspicions that lvm is going to be the magic factor here. Steve -- Steve Lord voice: +1-651-683-3511 Principal Engineer, Filesystem Software email: lord@sgi.com From owner-linux-xfs@oss.sgi.com Wed Jan 2 16:22:31 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g030MVH28960 for linux-xfs-outgoing; Wed, 2 Jan 2002 16:22:31 -0800 Received: from zork.zork.net (zork.zork.net [64.81.65.8]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g030MQg28938 for ; Wed, 2 Jan 2002 16:22:26 -0800 Received: from localhost (zork.zork.net) [127.0.0.1] by zork.zork.net with esmtp (Exim 3.33 #1 (Debian)) id 16LuiG-0004yU-00; Wed, 02 Jan 2002 15:22:24 -0800 To: Linux XFS Subject: Re: file corruption during emacs build on XFS logical volume References: <6u4rm4r53e.fsf@zork.zork.net> <1009995505.14223.9.camel@jen.americas.sgi.com> <6uy9jgpn2x.fsf@zork.zork.net> <6uu1u4pf48.fsf@zork.zork.net> <1010013019.1281.6.camel@jen.americas.sgi.com> From: Sean Neakums X-Message-Flag: Message text advisory: STYLE OVER SUBSTANCE, PROMOTION OF SELF X-Mailer: Norman Mail-Followup-To: Linux XFS Date: Wed, 02 Jan 2002 23:22:24 +0000 In-Reply-To: <1010013019.1281.6.camel@jen.americas.sgi.com> (Steve Lord's message of "02 Jan 2002 17:10:19 -0600") Message-ID: <6upu4spccv.fsf@zork.zork.net> User-Agent: Gnus/5.090004 (Oort Gnus v0.04) Emacs/21.1 (i386-debian-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 1292 Lines: 31 begin Steve Lord quotation: > On Wed, 2002-01-02 at 16:22, Sean Neakums wrote: >> begin Sean Neakums quotation: >> >> > begin Steve Lord quotation: >> >> I don't think there is much point going back to earlier kernels to >> >> be honest. I will fire up an emacs build here, on a non-lvm >> >> partition for starters. >> > >> > I went back to my 2.4.14-pre7 CVS pull, and the build went >> > perfectly on the XFS volume. But it seems that that kernel >> > doesn't have preempt applied, so I'll rebuild 2.4.17-xfs without >> > the patch, to eliminate that possibility. >> >> I'm now running a fresh build of 2.4.17, without the preempt patch. >> emacs reliably fails to build on the XFS volume, and builds >> successfully on the ext2 volume. > > Doing a non lvm build here, lets see if the that works. I have > my suspicions that lvm is going to be the magic factor here. I'm using the LVM as shipped in SGI's CVS tree, which claims to be "1.0.1-rc4(ish)". As I recall, that's the version being shippedin stock 2.4.17. Is there a newer version or some patches I should be using? -- ///////////////// | | The spark of a pin | (require 'gnu) | dropping, falling feather-like. \\\\\\\\\\\\\\\\\ | | There is too much noise. From owner-linux-xfs@oss.sgi.com Wed Jan 2 16:33:02 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g030X2b29212 for linux-xfs-outgoing; Wed, 2 Jan 2002 16:33:02 -0800 Received: from pneumatic-tube.sgi.com (pneumatic-tube.sgi.com [204.94.214.22]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g030Wvg29186 for ; Wed, 2 Jan 2002 16:32:57 -0800 Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id PAA07574 for ; Wed, 2 Jan 2002 15:33:27 -0800 (PST) mail_from (lord@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id RAA3926505; Wed, 2 Jan 2002 17:31:39 -0600 (CST) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id RAA49572; Wed, 2 Jan 2002 17:31:38 -0600 (CST) Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id g02NQbQ22396; Wed, 2 Jan 2002 17:26:37 -0600 Subject: Re: file corruption during emacs build on XFS logical volume From: Steve Lord To: Sean Neakums Cc: Linux XFS In-Reply-To: <6upu4spccv.fsf@zork.zork.net> References: <6u4rm4r53e.fsf@zork.zork.net> <1009995505.14223.9.camel@jen.americas.sgi.com> <6uy9jgpn2x.fsf@zork.zork.net> <6uu1u4pf48.fsf@zork.zork.net> <1010013019.1281.6.camel@jen.americas.sgi.com> <6upu4spccv.fsf@zork.zork.net> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/1.0.0.99+cvs.2001.12.18.08.57 (Preview Release) Date: 02 Jan 2002 17:26:37 -0600 Message-Id: <1010013997.1315.11.camel@jen.americas.sgi.com> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 1067 Lines: 29 On Wed, 2002-01-02 at 17:22, Sean Neakums wrote: > begin Steve Lord quotation: > > > > Doing a non lvm build here, lets see if the that works. I have > > my suspicions that lvm is going to be the magic factor here. > > I'm using the LVM as shipped in SGI's CVS tree, which claims to be > "1.0.1-rc4(ish)". As I recall, that's the version being shippedin > stock 2.4.17. Is there a newer version or some patches I should be > using? > No, I was refering to XFS on top of lvm being a possible culprit, independent of lvm version. I completed an emacs build - surprisingly quickly, but I want to try a different version, I am building rpms here and there is something wrong with the rpm package I have - or it is incompatible with my machine.... the compile worked, but the rpm failed to build, but the error seems more to do with the rpm package itself than a corrupted file. Have to dash now, more tomorrow. Steve -- Steve Lord voice: +1-651-683-3511 Principal Engineer, Filesystem Software email: lord@sgi.com From owner-linux-xfs@oss.sgi.com Wed Jan 2 16:36:39 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g030adi29384 for linux-xfs-outgoing; Wed, 2 Jan 2002 16:36:39 -0800 Received: from pneumatic-tube.sgi.com (pneumatic-tube.sgi.com [204.94.214.22]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g030ZYg29349 for ; Wed, 2 Jan 2002 16:35:34 -0800 Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id PAA09543 for ; Wed, 2 Jan 2002 15:36:04 -0800 (PST) mail_from (lord@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id RAA3988218 for ; Wed, 2 Jan 2002 17:34:16 -0600 (CST) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id RAA48888 for ; Wed, 2 Jan 2002 17:34:16 -0600 (CST) From: Steve Lord Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id g02NTFg22442; Wed, 2 Jan 2002 17:29:15 -0600 Message-Id: <200201022329.g02NTFg22442@jen.americas.sgi.com> Date: Wed, 2 Jan 2002 17:29:15 -0600 Subject: TAKE - merge up to 2.5.2-pre6 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 22925 Lines: 651 This is pretty big - and Linus started messing with other kernel structures, kdev_t is a structure now. Seems to run OK though. Date: Wed Jan 2 15:27:09 PST 2002 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:109025a linux/drivers/usb/hcd/ehci-mem.c - 1.1 linux/include/linux/namespace.h - 1.1 linux/include/linux/gfp.h - 1.1 linux/drivers/usb/hcd.c - 1.1 linux/drivers/usb/hcd.h - 1.1 linux/drivers/usb/hcd/Config.in - 1.1 linux/drivers/usb/hcd/Makefile - 1.1 linux/drivers/usb/hcd/ehci-dbg.c - 1.1 linux/drivers/usb/hcd/ehci-hcd.c - 1.1 linux/drivers/usb/hcd/ehci-hub.c - 1.1 linux/drivers/usb/hcd/ehci-q.c - 1.1 linux/drivers/usb/hcd/ehci-sched.c - 1.1 linux/drivers/usb/hcd/ehci.h - 1.1 linux/drivers/usb/serial/ipaq.c - 1.1 linux/drivers/usb/serial/ipaq.h - 1.1 linux/drivers/usb/serial/kl5kusb105.c - 1.1 linux/drivers/usb/serial/kl5kusb105.h - 1.1 linux/arch/i386/kernel/setup-visws.c - 1.1 linux/net/x25/x25_timer.c - 1.5 linux/net/x25/x25_subr.c - 1.6 linux/net/x25/x25_route.c - 1.7 linux/net/x25/x25_out.c - 1.7 linux/net/x25/x25_link.c - 1.10 linux/net/x25/x25_in.c - 1.8 linux/net/x25/x25_facilities.c - 1.5 linux/net/x25/x25_dev.c - 1.9 linux/net/x25/af_x25.c - 1.23 linux/net/wanrouter/wanproc.c - 1.19 linux/net/wanrouter/wanmain.c - 1.14 linux/net/sunrpc/auth_unix.c - 1.7 linux/net/sunrpc/auth_null.c - 1.7 linux/net/rose/rose_timer.c - 1.4 linux/net/rose/rose_subr.c - 1.5 linux/net/rose/rose_route.c - 1.8 linux/net/rose/rose_out.c - 1.4 linux/net/rose/rose_link.c - 1.6 linux/net/rose/rose_in.c - 1.4 linux/net/rose/rose_dev.c - 1.9 linux/net/rose/af_rose.c - 1.21 linux/net/packet/af_packet.c - 1.27 linux/net/netlink/netlink_dev.c - 1.11 linux/net/irda/irsysctl.c - 1.8 linux/net/irda/irda_device.c - 1.22 linux/net/802/hippi.c - 1.5 linux/net/802/fddi.c - 1.5 linux/mm/vmscan.c - 1.92 linux/mm/swapfile.c - 1.47 linux/mm/slab.c - 1.29 linux/mm/page_io.c - 1.21 linux/mm/mremap.c - 1.25 linux/mm/mprotect.c - 1.20 linux/mm/memory.c - 1.73 linux/mm/filemap.c - 1.105 linux/kernel/sysctl.c - 1.46 linux/kernel/sched.c - 1.47 linux/kernel/ksyms.c - 1.124 linux/kernel/kmod.c - 1.16 linux/kernel/fork.c - 1.40 linux/kernel/exit.c - 1.35 linux/kernel/acct.c - 1.15 linux/ipc/shm.c - 1.52 linux/include/scsi/scsicam.h - 1.3 linux/include/linux/wait.h - 1.13 linux/include/linux/sunrpc/clnt.h - 1.7 linux/include/linux/slab.h - 1.21 linux/include/linux/shm.h - 1.13 linux/include/linux/sched.h - 1.50 linux/include/linux/quotaops.h - 1.12 linux/include/linux/quota.h - 1.8 linux/include/linux/proc_fs.h - 1.31 linux/include/linux/parport.h - 1.22 linux/include/linux/nfsd/nfsfh.h - 1.12 linux/include/linux/msdos_fs.h - 1.13 linux/include/linux/mm.h - 1.76 linux/include/linux/linkage.h - 1.8 linux/include/linux/keyboard.h - 1.3 linux/include/linux/kernel.h - 1.31 linux/include/linux/kdev_t.h - 1.5 linux/include/linux/kbd_kern.h - 1.8 linux/include/linux/isdn.h - 1.20 linux/include/linux/interrupt.h - 1.17 linux/include/linux/genhd.h - 1.19 linux/include/linux/fs.h - 1.139 linux/include/linux/file.h - 1.11 linux/include/linux/ext2_fs_sb.h - 1.6 linux/include/linux/console.h - 1.9 linux/include/linux/cdrom.h - 1.21 linux/include/linux/blkdev.h - 1.49 linux/include/linux/blk.h - 1.27 linux/include/linux/amigaffs.h - 1.7 linux/include/linux/acct.h - 1.3 linux/include/asm-sparc64/keyboard.h - 1.5 linux/include/asm-sparc/keyboard.h - 1.6 linux/include/asm-i386/smp.h - 1.15 linux/include/asm-i386/msr.h - 1.10 linux/include/asm-arm/bitops.h - 1.8 linux/fs/vfat/vfatfs_syms.c - 1.6 linux/fs/vfat/namei.c - 1.21 linux/fs/umsdos/inode.c - 1.20 linux/fs/ufs/super.c - 1.21 linux/fs/ufs/inode.c - 1.19 linux/fs/sysv/inode.c - 1.26 linux/fs/sysv/dir.c - 1.12 linux/fs/super.c - 1.72 linux/fs/romfs/inode.c - 1.27 linux/fs/qnx4/truncate.c - 1.4 linux/fs/qnx4/namei.c - 1.10 linux/fs/qnx4/inode.c - 1.27 linux/fs/qnx4/fsync.c - 1.7 linux/fs/qnx4/dir.c - 1.12 linux/fs/proc/base.c - 1.31 linux/fs/proc/array.c - 1.33 linux/fs/ntfs/fs.c - 1.36 linux/fs/nls/nls_koi8-r.c - 1.6 linux/fs/nls/nls_iso8859-9.c - 1.6 linux/fs/nls/nls_iso8859-8.c - 1.7 linux/fs/nls/nls_iso8859-7.c - 1.6 linux/fs/nls/nls_iso8859-6.c - 1.6 linux/fs/nls/nls_iso8859-5.c - 1.6 linux/fs/nls/nls_iso8859-4.c - 1.6 linux/fs/nls/nls_iso8859-3.c - 1.6 linux/fs/nls/nls_iso8859-2.c - 1.6 linux/fs/nls/nls_iso8859-15.c - 1.6 linux/fs/nls/nls_iso8859-1.c - 1.6 linux/fs/nls/nls_cp874.c - 1.7 linux/fs/nls/nls_cp869.c - 1.7 linux/fs/nls/nls_cp866.c - 1.7 linux/fs/nls/nls_cp865.c - 1.7 linux/fs/nls/nls_cp864.c - 1.7 linux/fs/nls/nls_cp863.c - 1.7 linux/fs/nls/nls_cp862.c - 1.7 linux/fs/nls/nls_cp861.c - 1.7 linux/fs/nls/nls_cp860.c - 1.7 linux/fs/nls/nls_cp857.c - 1.7 linux/fs/nls/nls_cp855.c - 1.7 linux/fs/nls/nls_cp852.c - 1.7 linux/fs/nls/nls_cp850.c - 1.7 linux/fs/nls/nls_cp775.c - 1.7 linux/fs/nls/nls_cp737.c - 1.7 linux/fs/nls/nls_cp437.c - 1.7 linux/fs/nls/nls_base.c - 1.9 linux/fs/nfsd/vfs.c - 1.40 linux/fs/nfsd/nfsxdr.c - 1.13 linux/fs/nfsd/nfsproc.c - 1.20 linux/fs/nfsd/nfsfh.c - 1.33 linux/fs/nfsd/nfsctl.c - 1.23 linux/fs/nfsd/nfs3xdr.c - 1.22 linux/fs/nfsd/export.c - 1.22 linux/fs/nfs/write.c - 1.33 linux/fs/nfs/read.c - 1.26 linux/fs/nfs/inode.c - 1.33 linux/fs/nfs/file.c - 1.26 linux/fs/nfs/dir.c - 1.30 linux/fs/ncpfs/symlink.c - 1.13 linux/fs/namei.c - 1.43 linux/fs/msdos/namei.c - 1.21 linux/fs/msdos/msdosfs_syms.c - 1.6 linux/fs/minix/inode.c - 1.26 linux/fs/lockd/svclock.c - 1.13 linux/fs/isofs/rock.c - 1.17 linux/fs/isofs/namei.c - 1.7 linux/fs/isofs/joliet.c - 1.7 linux/fs/isofs/inode.c - 1.29 linux/fs/inode.c - 1.61 linux/fs/hfs/super.c - 1.11 linux/fs/hfs/file_hdr.c - 1.11 linux/fs/hfs/file_cap.c - 1.11 linux/fs/hfs/file.c - 1.14 linux/fs/hfs/dir.c - 1.8 linux/fs/fat/inode.c - 1.30 linux/fs/fat/file.c - 1.16 linux/fs/fat/cache.c - 1.14 linux/fs/ext2/super.c - 1.22 linux/fs/ext2/inode.c - 1.37 linux/fs/ext2/ialloc.c - 1.21 linux/fs/exec.c - 1.51 linux/fs/dquot.c - 1.46 linux/fs/devices.c - 1.18 linux/fs/coda/upcall.c - 1.15 linux/fs/coda/sysctl.c - 1.14 linux/fs/coda/psdev.c - 1.18 linux/fs/coda/pioctl.c - 1.11 linux/fs/coda/inode.c - 1.15 linux/fs/coda/file.c - 1.17 linux/fs/coda/coda_linux.c - 1.7 linux/fs/coda/cache.c - 1.10 linux/fs/buffer.c - 1.103 linux/fs/block_dev.c - 1.35 linux/fs/binfmt_elf.c - 1.36 linux/fs/autofs/inode.c - 1.10 linux/fs/affs/super.c - 1.15 linux/fs/affs/file.c - 1.21 linux/fs/adfs/super.c - 1.14 linux/fs/adfs/inode.c - 1.20 linux/fs/Config.in - 1.73 linux/drivers/video/q40fb.c - 1.10 linux/drivers/video/fbmem.c - 1.41 linux/drivers/video/dnfb.c - 1.12 linux/drivers/usb/usb.c - 1.61 linux/drivers/usb/usb-debug.c - 1.15 linux/drivers/usb/hub.h - 1.18 linux/drivers/usb/hub.c - 1.41 linux/drivers/usb/audio.c - 1.34 linux/drivers/sound/sscape.c - 1.13 linux/drivers/sound/soundcard.c - 1.21 linux/drivers/sound/sound_core.c - 1.21 linux/drivers/sound/sb_card.c - 1.31 linux/drivers/sound/os.h - 1.5 linux/drivers/sound/msnd.c - 1.9 linux/drivers/sound/es1371.c - 1.36 linux/drivers/sound/ad1848.c - 1.15 linux/drivers/sgi/char/sgiserial.c - 1.10 linux/drivers/scsi/wd7000.c - 1.13 linux/drivers/scsi/tmscsim.c - 1.14 linux/drivers/scsi/st.c - 1.37 linux/drivers/scsi/sr.c - 1.35 linux/drivers/scsi/sg.c - 1.26 linux/drivers/scsi/sd.h - 1.6 linux/drivers/scsi/sd.c - 1.54 linux/drivers/scsi/scsicam.c - 1.6 linux/drivers/scsi/scsi_syms.c - 1.15 linux/drivers/scsi/scsi_module.c - 1.5 linux/drivers/scsi/scsi.h - 1.25 linux/drivers/scsi/scsi.c - 1.48 linux/drivers/scsi/ncr53c8xx.c - 1.24 linux/drivers/scsi/megaraid.c - 1.31 linux/drivers/scsi/mac_scsi.c - 1.9 linux/drivers/scsi/ide-scsi.h - 1.3 linux/drivers/scsi/ide-scsi.c - 1.21 linux/drivers/scsi/hosts.h - 1.20 linux/drivers/scsi/hosts.c - 1.28 linux/drivers/scsi/fdomain.h - 1.4 linux/drivers/scsi/fdomain.c - 1.17 linux/drivers/scsi/aha1542.c - 1.20 linux/drivers/scsi/BusLogic.c - 1.14 linux/drivers/sbus/char/zs.c - 1.21 linux/drivers/sbus/char/sunkbd.c - 1.18 linux/drivers/sbus/char/su.c - 1.21 linux/drivers/sbus/char/sab82532.c - 1.24 linux/drivers/sbus/char/bpp.c - 1.18 linux/drivers/net/strip.c - 1.17 linux/drivers/net/slip.c - 1.18 linux/drivers/net/sgiseeq.c - 1.12 linux/drivers/net/irda/irtty.c - 1.24 linux/drivers/net/hamradio/soundmodem/sm_wss.c - 1.7 linux/drivers/net/hamradio/soundmodem/sm_sbc.c - 1.6 linux/drivers/net/hamradio/mkiss.c - 1.13 linux/drivers/net/hamradio/dmascc.c - 1.10 linux/drivers/net/hamradio/bpqether.c - 1.18 linux/drivers/macintosh/macserial.c - 1.20 linux/drivers/macintosh/mac_keyb.c - 1.16 linux/drivers/isdn/sc/includes.h - 1.5 linux/drivers/isdn/isdnloop/isdnloop.h - 1.9 linux/drivers/isdn/icn/icn.h - 1.11 linux/drivers/isdn/hisax/hisax.h - 1.23 linux/drivers/isdn/avmb1/capiutil.c - 1.10 linux/drivers/isdn/avmb1/capidrv.c - 1.19 linux/drivers/isdn/act2000/act2000.h - 1.7 linux/drivers/char/vc_screen.c - 1.12 linux/drivers/char/tty_io.c - 1.39 linux/drivers/char/synclink.c - 1.19 linux/drivers/char/serial167.c - 1.11 linux/drivers/char/serial.c - 1.52 linux/drivers/char/pty.c - 1.12 linux/drivers/char/pc110pad.c - 1.14 linux/drivers/char/n_tty.c - 1.13 linux/drivers/char/n_hdlc.c - 1.12 linux/drivers/char/misc.c - 1.28 linux/drivers/char/mem.c - 1.40 linux/drivers/char/keyboard.c - 1.23 linux/drivers/char/isicom.c - 1.16 linux/drivers/char/h8.c - 1.12 linux/drivers/char/ftape/zftape/zftape-write.c - 1.4 linux/drivers/char/ftape/zftape/zftape-vtbl.c - 1.6 linux/drivers/char/ftape/zftape/zftape-rw.c - 1.4 linux/drivers/char/ftape/zftape/zftape-read.c - 1.4 linux/drivers/char/ftape/zftape/zftape-init.c - 1.12 linux/drivers/char/ftape/zftape/zftape-ctl.c - 1.4 linux/drivers/char/ftape/zftape/zftape-buffers.c - 1.5 linux/drivers/char/ftape/lowlevel/ftape-write.c - 1.4 linux/drivers/char/ftape/lowlevel/ftape-setup.c - 1.5 linux/drivers/char/ftape/lowlevel/ftape-read.c - 1.3 linux/drivers/char/ftape/lowlevel/ftape-io.c - 1.5 linux/drivers/char/ftape/lowlevel/ftape-ctl.c - 1.6 linux/drivers/char/ftape/lowlevel/ftape-buffer.c - 1.6 linux/drivers/char/ftape/compressor/zftape-compress.c - 1.5 linux/drivers/char/ftape/RELEASE-NOTES - 1.3 linux/drivers/char/esp.c - 1.14 linux/drivers/char/epca.c - 1.19 linux/drivers/char/dtlk.c - 1.16 linux/drivers/char/dsp56k.c - 1.18 linux/drivers/char/console.c - 1.26 linux/drivers/char/Config.in - 1.55 linux/drivers/cdrom/cdu31a.c - 1.11 linux/drivers/cdrom/cdrom.c - 1.39 linux/drivers/block/xd.c - 1.30 linux/drivers/block/ps2esdi.c - 1.31 linux/drivers/block/paride/pd.c - 1.24 linux/drivers/block/paride/Config.in - 1.6 linux/drivers/block/nbd.c - 1.30 linux/drivers/block/loop.c - 1.46 linux/drivers/block/ll_rw_blk.c - 1.88 linux/drivers/block/genhd.c - 1.24 linux/drivers/block/floppy.c - 1.34 linux/drivers/block/acsi.c - 1.23 linux/drivers/acorn/scsi/powertec.c - 1.13 linux/drivers/acorn/scsi/oak.c - 1.7 linux/drivers/acorn/scsi/eesox.c - 1.12 linux/drivers/acorn/scsi/ecoscsi.c - 1.8 linux/drivers/acorn/scsi/cumana_2.c - 1.12 linux/drivers/acorn/scsi/cumana_1.c - 1.6 linux/drivers/acorn/scsi/acornscsi.c - 1.12 linux/drivers/acorn/block/mfmhd.c - 1.17 linux/arch/sparc64/kernel/smp.c - 1.33 linux/arch/sparc64/kernel/process.c - 1.25 linux/arch/sparc/kernel/smp.c - 1.15 linux/arch/sparc/kernel/process.c - 1.22 linux/arch/ppc/kernel/smp.c - 1.30 linux/arch/ppc/kernel/idle.c - 1.19 linux/arch/ppc/amiga/config.c - 1.15 linux/arch/ppc/8xx_io/uart.c - 1.17 linux/arch/mips/kernel/process.c - 1.13 linux/arch/m68k/q40/config.c - 1.13 linux/arch/m68k/mvme147/config.c - 1.10 linux/arch/m68k/mac/debug.c - 1.8 linux/arch/m68k/kernel/process.c - 1.14 linux/arch/m68k/amiga/config.c - 1.12 linux/arch/i386/kernel/smp.c - 1.37 linux/arch/i386/kernel/setup.c - 1.64 linux/arch/i386/kernel/process.c - 1.37 linux/arch/i386/kernel/Makefile - 1.24 linux/arch/i386/defconfig - 1.86 linux/arch/i386/config.in - 1.69 linux/arch/arm/kernel/process.c - 1.21 linux/arch/alpha/kernel/smp.c - 1.29 linux/arch/alpha/kernel/setup.c - 1.26 linux/arch/alpha/kernel/process.c - 1.20 linux/arch/alpha/kernel/alpha_ksyms.c - 1.31 linux/Makefile - 1.169 linux/MAINTAINERS - 1.89 linux/net/decnet/dn_nsp_out.c - 1.10 linux/net/decnet/dn_nsp_in.c - 1.15 linux/net/decnet/af_decnet.c - 1.27 linux/include/linux/ide.h - 1.34 linux/fs/hpfs/super.c - 1.11 linux/fs/hpfs/hpfs_fn.h - 1.14 linux/fs/hpfs/file.c - 1.16 linux/fs/efs/super.c - 1.10 linux/fs/efs/file.c - 1.8 linux/drivers/sbus/char/aurora.c - 1.17 linux/drivers/isdn/isdn_bsdcomp.c - 1.7 linux/drivers/isdn/eicon/eicon.h - 1.13 linux/drivers/block/blkpg.c - 1.15 linux/drivers/acorn/scsi/arxescsi.c - 1.10 linux/arch/arm/nwfpe/fpa11_cpdt.c - 1.6 linux/arch/arm/nwfpe/fpa11.c - 1.6 linux/arch/arm/nwfpe/entry.S - 1.5 linux/arch/arm/nwfpe/ARM-gcc.h - 1.2 linux/drivers/tc/zs.c - 1.7 linux/drivers/net/jazzsonic.c - 1.9 linux/drivers/char/dz.c - 1.14 linux/arch/mips/dec/promcon.c - 1.4 linux/arch/mips/baget/vacserial.c - 1.11 linux/drivers/block/cpqarray.c - 1.38 linux/kernel/ptrace.c - 1.17 linux/include/linux/threads.h - 1.3 linux/drivers/char/raw.c - 1.21 linux/drivers/net/macsonic.c - 1.11 linux/fs/partitions/check.h - 1.6 linux/fs/partitions/check.c - 1.36 linux/fs/partitions/atari.c - 1.7 linux/drivers/isdn/avmb1/kcapi.c - 1.16 linux/fs/nls/nls_iso8859-14.c - 1.5 linux/drivers/net/fc/iph5526.c - 1.18 linux/drivers/char/ip2main.c - 1.15 linux/net/atm/resources.c - 1.6 linux/drivers/block/DAC960.c - 1.42 linux/arch/sh/kernel/setup.c - 1.18 linux/arch/sh/kernel/process.c - 1.17 linux/net/irda/ircomm/ircomm_tty_ioctl.c - 1.7 linux/net/irda/ircomm/ircomm_tty.c - 1.15 linux/drivers/pcmcia/tcic.c - 1.14 linux/drivers/pcmcia/i82365.c - 1.24 linux/drivers/pcmcia/ds.c - 1.19 linux/fs/udf/inode.c - 1.26 linux/fs/udf/namei.c - 1.19 linux/fs/udf/super.c - 1.22 linux/arch/i386/kernel/smpboot.c - 1.25 linux/arch/i386/kernel/pci-pc.c - 1.32 linux/include/linux/pci_ids.h - 1.55 linux/drivers/net/wan/sdlamain.c - 1.11 linux/drivers/net/wan/sdla_x25.c - 1.13 linux/drivers/net/wan/sdla_ppp.c - 1.16 linux/drivers/net/wan/sdla_fr.c - 1.17 linux/drivers/net/wan/lapbether.c - 1.10 linux/drivers/net/pcmcia/fmvj18x_cs.c - 1.14 linux/mm/highmem.c - 1.33 linux/fs/proc/proc_misc.c - 1.29 linux/fs/bfs/inode.c - 1.17 linux/fs/bfs/file.c - 1.17 linux/fs/bfs/dir.c - 1.14 linux/drivers/char/agp/agpgart_fe.c - 1.14 linux/kernel/timer.c - 1.15 linux/drivers/scsi/scsi_lib.c - 1.40 linux/drivers/usb/dabusb.h - 1.7 linux/drivers/usb/dabusb.c - 1.15 linux/fs/cramfs/inode.c - 1.21 linux/drivers/telephony/ixj.c - 1.21 linux/drivers/usb/devio.c - 1.21 linux/drivers/usb/inode.c - 1.18 linux/drivers/ieee1394/ohci1394.c - 1.19 linux/arch/arm/lib/changebit.S - 1.4 linux/arch/arm/lib/clearbit.S - 1.4 linux/arch/arm/lib/findbit.S - 1.5 linux/arch/i386/kernel/apic.c - 1.23 linux/arch/arm/lib/setbit.S - 1.4 linux/arch/arm/lib/testchangebit.S - 1.4 linux/arch/arm/lib/testclearbit.S - 1.4 linux/arch/arm/lib/testsetbit.S - 1.4 linux/drivers/char/moxa.c - 1.10 linux/drivers/char/mxser.c - 1.13 linux/drivers/scsi/scsi_scan.c - 1.21 linux/drivers/net/wan/sdla_chdlc.c - 1.15 linux/fs/autofs4/inode.c - 1.10 linux/drivers/video/dn_cfb8.c - 1.7 linux/drivers/video/dn_cfb4.c - 1.6 linux/drivers/char/vme_scc.c - 1.7 linux/arch/ia64/hp/hpsim_console.c - 1.3 linux/arch/ia64/kernel/smp.c - 1.11 linux/arch/ia64/kernel/process.c - 1.12 linux/drivers/scsi/qla1280.c - 1.12 linux/kernel/pm.c - 1.9 linux/include/linux/raid/md_k.h - 1.18 linux/Documentation/filesystems/devfs/rc.devfs - 1.2 linux/Documentation/filesystems/devfs/README - 1.11 linux/Documentation/filesystems/devfs/ChangeLog - 1.16 linux/include/linux/devfs_fs_kernel.h - 1.10 linux/drivers/scsi/pcmcia/qlogic_stub.c - 1.6 linux/drivers/scsi/pcmcia/fdomain_stub.c - 1.6 linux/include/linux/devfs_fs.h - 1.3 linux/fs/devfs/util.c - 1.9 linux/fs/devfs/base.c - 1.25 linux/drivers/scsi/pcmcia/aha152x_stub.c - 1.7 linux/drivers/atm/fore200e.c - 1.13 linux/arch/mips64/kernel/process.c - 1.7 linux/drivers/char/sh-sci.c - 1.16 linux/include/linux/usb.h - 1.23 linux/drivers/ide/via82cxxx.c - 1.21 linux/drivers/ide/ide.c - 1.39 linux/drivers/ide/ide-probe.c - 1.21 linux/drivers/ide/ide-floppy.c - 1.13 linux/drivers/ide/ide-disk.c - 1.19 linux/drivers/ide/ide-cd.c - 1.24 linux/drivers/ide/icside.c - 1.10 linux/drivers/ide/hd.c - 1.16 linux/drivers/block/elevator.c - 1.13 linux/drivers/scsi/sym53c8xx_comm.h - 1.11 linux/drivers/usb/mdc800.c - 1.15 linux/include/linux/usbdevice_fs.h - 1.6 linux/fs/ramfs/inode.c - 1.15 linux/drivers/net/wan/lmc/lmc_proto.c - 1.4 linux/drivers/net/wan/lmc/lmc_media.c - 1.4 linux/drivers/net/wan/lmc/lmc_main.c - 1.9 linux/arch/ppc/8260_io/uart.c - 1.9 linux/arch/s390/kernel/process.c - 1.10 linux/arch/s390/kernel/smp.c - 1.10 linux/arch/mips64/kernel/smp.c - 1.8 linux/fs/xfs/xfsidbg.c - 1.167 linux/fs/xfs/xfs_rw.c - 1.349 linux/fs/xfs/xfs_buf.h - 1.77 linux/fs/xfs/xfs_buf_item.c - 1.116 linux/fs/xfs/xfs_vnodeops.c - 1.514 linux/fs/xfs/xfs_itable.c - 1.102 linux/fs/xfs/xfs_dmapi.c - 1.47 linux/fs/xfs/xfs_qm_syscalls.c - 1.56 linux/fs/xfs/xfs_log_recover.c - 1.217 linux/fs/xfs/xfs_vfsops.c - 1.331 linux/fs/xfs/xfs_dquot.c - 1.60 linux/fs/xfs/xfs_mount.h - 1.133 linux/fs/xfs/xfs_mount.c - 1.265 linux/fs/xfs/xfs_qm.c - 1.71 linux/fs/xfs/xfs_inode.c - 1.323 linux/fs/xfs/xfs_types.h - 1.54 linux/fs/xfs/xfs_fsops.c - 1.73 linux/fs/xfs/xfs_trans_buf.c - 1.97 linux/fs/xfs/linux/xfs_vfs.c - 1.26 linux/fs/xfs/linux/xfs_linux.h - 1.58 linux/fs/xfs/linux/xfs_vnode.c - 1.69 linux/fs/xfs/linux/xfs_super.h - 1.13 linux/fs/xfs/linux/xfs_super.c - 1.153 linux/kdb/modules/kdbm_vm.c - 1.16 linux/fs/pagebuf/page_buf_locking.c - 1.18 linux/fs/pagebuf/page_buf_io.c - 1.105 linux/drivers/usb/storage/usb.c - 1.14 linux/drivers/usb/microtek.c - 1.13 linux/fs/jffs/inode-v23.c - 1.14 linux/drivers/ieee1394/video1394.c - 1.13 linux/drivers/mtd/ftl.c - 1.12 linux/fs/nls/nls_big5.c - 1.3 linux/fs/nls/nls_cp932.c - 1.3 linux/fs/nls/nls_cp936.c - 1.2 linux/fs/nls/nls_cp949.c - 1.2 linux/fs/nls/nls_cp950.c - 1.2 linux/fs/nls/nls_euc-jp.c - 1.4 linux/fs/nls/nls_euc-kr.c - 1.3 linux/fs/nls/nls_gb2312.c - 1.3 linux/fs/nls/nls_sjis.c - 1.3 linux/fs/nls/nls_utf8.c - 1.2 linux/drivers/media/video/zr36120.c - 1.11 linux/drivers/media/video/stradis.c - 1.9 linux/drivers/media/video/saa7185.c - 1.6 linux/drivers/media/video/bttv-driver.c - 1.15 linux/drivers/isdn/eicon/lincfg.c - 1.5 linux/drivers/input/joydev.c - 1.7 linux/drivers/char/serial_21285.c - 1.5 linux/drivers/md/lvm.c - 1.26 linux/drivers/md/raid5.c - 1.23 linux/drivers/block/cciss.c - 1.25 linux/drivers/block/cciss.h - 1.7 linux/drivers/char/serial_amba.c - 1.6 linux/drivers/md/lvm-snap.c - 1.12 linux/drivers/md/md.c - 1.34 linux/drivers/scsi/cpqfcTSworker.c - 1.9 linux/fs/minix/itree_common.c - 1.7 linux/mm/oom_kill.c - 1.11 linux/net/irda/irsyms.c - 1.4 linux/include/asm-i386/cpufeature.h - 1.2 linux/arch/i386/kernel/dmi_scan.c - 1.13 linux/arch/parisc/kernel/process.c - 1.3 linux/arch/parisc/kernel/pdc_cons.c - 1.3 linux/drivers/scsi/osst.c - 1.11 linux/arch/ia64/sn/io/hcl.c - 1.3 linux/fs/reiserfs/stree.c - 1.13 linux/fs/reiserfs/super.c - 1.11 linux/fs/reiserfs/resize.c - 1.4 linux/fs/reiserfs/namei.c - 1.13 linux/fs/reiserfs/inode.c - 1.20 linux/fs/reiserfs/fix_node.c - 1.12 linux/fs/reiserfs/buffer2.c - 1.6 linux/include/linux/reiserfs_fs.h - 1.14 linux/drivers/ide/ide-timing.h - 1.2 linux/arch/s390x/kernel/smp.c - 1.7 linux/arch/alpha/kernel/pci-noop.c - 1.4 linux/arch/s390x/kernel/process.c - 1.7 linux/arch/cris/kernel/process.c - 1.11 linux/drivers/s390/s390io.c - 1.7 linux/drivers/md/lvm-fs.c - 1.4 linux/drivers/scsi/aic7xxx_old.c - 1.14 linux/drivers/scsi/aic7xxx/aic7xxx_linux.c - 1.11 linux/drivers/s390/char/tuball.c - 1.5 linux/fs/nls/nls_cp1251.c - 1.3 linux/fs/nls/nls_cp1255.c - 1.4 linux/fs/nls/nls_iso8859-13.c - 1.3 linux/fs/nls/nls_koi8-u.c - 1.3 linux/fs/nls/nls_tis-620.c - 1.2 linux/arch/cris/drivers/usb-host.c - 1.9 linux/fs/nls/nls_koi8-ru.c - 1.2 linux/fs/freevxfs/vxfs_subr.c - 1.4 linux/drivers/net/irda/irda-usb.c - 1.11 linux/fs/freevxfs/vxfs_inode.c - 1.7 linux/drivers/media/video/bt856.c - 1.5 linux/drivers/media/video/adv7175.c - 1.5 linux/fs/char_dev.c - 1.3 linux/drivers/usb/pwc.h - 1.8 linux/drivers/usb/pwc-if.c - 1.8 linux/arch/m68k/sun3x/prom.c - 1.2 linux/drivers/mtd/nftlcore.c - 1.9 linux/drivers/mtd/devices/slram.c - 1.3 linux/drivers/mtd/devices/pmc551.c - 1.3 linux/drivers/mtd/devices/doc1000.c - 1.3 linux/drivers/acpi/ospm/ec/ec_osl.c - 1.5 linux/drivers/acpi/ospm/button/bn_osl.c - 1.5 linux/drivers/acpi/ospm/busmgr/bm_osl.c - 1.5 linux/drivers/acpi/ospm/battery/bt_osl.c - 1.5 linux/drivers/acpi/ospm/system/sm_osl.c - 1.5 linux/drivers/acpi/ospm/thermal/tz_osl.c - 1.6 linux/drivers/acpi/ospm/thermal/tzpolicy.c - 1.4 linux/drivers/net/wireless/airo.c - 1.11 linux/drivers/acpi/ospm/processor/pr_osl.c - 1.6 linux/drivers/acpi/ospm/ac_adapter/ac_osl.c - 1.5 linux/fs/sysv/itree.c - 1.3 linux/fs/sysv/super.c - 1.6 linux/arch/mips/kernel/smp.c - 1.3 linux/drivers/scsi/pcmcia/nsp_cs.c - 1.9 linux/drivers/media/video/zr36067.c - 1.6 linux/drivers/video/aty/atyfb_base.c - 1.7 linux/drivers/s390/block/dasd_int.h - 1.3 linux/drivers/char/drm/drm_stub.h - 1.2 linux/drivers/char/drm/drm_fops.h - 1.2 linux/drivers/char/drm/drm_drv.h - 1.4 linux/drivers/usb/usbnet.c - 1.9 linux/drivers/char/serial_tx3912.c - 1.3 linux/arch/mips/au1000/common/serial.c - 1.3 linux/fs/jffs2/write.c - 1.3 linux/drivers/ide/pdcraid.c - 1.7 linux/drivers/ide/hptraid.c - 1.6 linux/drivers/ide/ataraid.c - 1.4 linux/drivers/mtd/devices/blkmtd.c - 1.3 linux/fs/namespace.c - 1.11 linux/drivers/usb/hpusbscsi.c - 1.3 linux/drivers/message/i2o/i2o_block.c - 1.7 linux/fs/inflate_fs/inflate_syms.c - 1.2 linux/net/8021q/vlanproc.c - 1.3 linux/drivers/char/i8k.c - 1.2 linux/include/linux/i8k.h - 1.2 linux/fs/jbd/journal.c - 1.2 linux/fs/ext3/ialloc.c - 1.3 linux/fs/ext3/inode.c - 1.4 linux/fs/ext3/super.c - 1.3 linux/fs/intermezzo/ext_attr.c - 1.2 linux/fs/intermezzo/file.c - 1.2 linux/fs/intermezzo/inode.c - 1.2 linux/fs/intermezzo/journal.c - 1.3 linux/fs/intermezzo/journal_ext2.c - 1.2 linux/fs/intermezzo/journal_ext3.c - 1.2 linux/fs/intermezzo/journal_obdfs.c - 1.2 linux/fs/intermezzo/journal_reiserfs.c - 1.2 linux/fs/intermezzo/journal_xfs.c - 1.4 linux/fs/intermezzo/presto.c - 1.3 linux/fs/intermezzo/psdev.c - 1.2 linux/fs/intermezzo/sysctl.c - 1.2 linux/fs/intermezzo/upcall.c - 1.2 linux/include/linux/jbd.h - 1.2 linux/fs/jbd/recovery.c - 1.2 linux/include/linux/ext3_jbd.h - 1.2 linux/include/linux/ext3_fs.h - 1.2 linux/fs/jbd/revoke.c - 1.2 linux/fs/jbd/transaction.c - 1.2 linux/fs/sysv/ChangeLog - 1.2 linux/fs/jbd/commit.c - 1.2 linux/fs/ext3/Makefile - 1.2 linux/fs/ext3/acl.c - 1.2 linux/fs/intermezzo/dcache.c - 1.3 linux/include/linux/bio.h - 1.6 linux/fs/bio.c - 1.9 linux/drivers/block/block_ioctl.c - 1.6 linux/init/do_mounts.c - 1.6 linux/mm/mempool.c - 1.4 linux/fs/xfs_dmapi/dmapi_sysent.c - 1.3 From owner-linux-xfs@oss.sgi.com Wed Jan 2 16:55:24 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g030tO129811 for linux-xfs-outgoing; Wed, 2 Jan 2002 16:55:24 -0800 Received: from zork.zork.net (zork.zork.net [64.81.65.8]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g030tHg29789 for ; Wed, 2 Jan 2002 16:55:17 -0800 Received: from localhost (zork.zork.net) [127.0.0.1] by zork.zork.net with esmtp (Exim 3.33 #1 (Debian)) id 16LvE3-0005Nm-00; Wed, 02 Jan 2002 15:55:15 -0800 To: Linux XFS Subject: Re: file corruption during emacs build on XFS logical volume References: <6u4rm4r53e.fsf@zork.zork.net> <1009995505.14223.9.camel@jen.americas.sgi.com> <6uy9jgpn2x.fsf@zork.zork.net> <6uu1u4pf48.fsf@zork.zork.net> <1010013019.1281.6.camel@jen.americas.sgi.com> <6upu4spccv.fsf@zork.zork.net> <1010013997.1315.11.camel@jen.americas.sgi.com> From: Sean Neakums X-Message-Flag: Message text advisory: IGNORATIO ELENCHI, MISMATCHED PARENTHESES X-Mailer: Norman Mail-Followup-To: Linux XFS Date: Wed, 02 Jan 2002 23:55:14 +0000 In-Reply-To: <1010013997.1315.11.camel@jen.americas.sgi.com> (Steve Lord's message of "02 Jan 2002 17:26:37 -0600") Message-ID: <6ulmfgpau5.fsf@zork.zork.net> User-Agent: Gnus/5.090004 (Oort Gnus v0.04) Emacs/21.1 (i386-debian-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 771 Lines: 19 begin Steve Lord quotation: > I completed an emacs build - surprisingly quickly, but I want to try > a different version, I am building rpms here and there is something > wrong with the rpm package I have - or it is incompatible with my > machine.... the compile worked, but the rpm failed to build, but the > error seems more to do with the rpm package itself than a corrupted > file. > > Have to dash now, more tomorrow. I've just realised that my swap is divided between two partitions. I've taken one and created an XFS filesystem on it. Building emacs now. -- ///////////////// | | The spark of a pin | (require 'gnu) | dropping, falling feather-like. \\\\\\\\\\\\\\\\\ | | There is too much noise. From owner-linux-xfs@oss.sgi.com Wed Jan 2 17:20:41 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g031KfD30544 for linux-xfs-outgoing; Wed, 2 Jan 2002 17:20:41 -0800 Received: from zork.zork.net (zork.zork.net [64.81.65.8]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g031KZg30522 for ; Wed, 2 Jan 2002 17:20:35 -0800 Received: from localhost (zork.zork.net) [127.0.0.1] by zork.zork.net with esmtp (Exim 3.33 #1 (Debian)) id 16LvcX-0005kf-00; Wed, 02 Jan 2002 16:20:33 -0800 To: Linux XFS Subject: Re: file corruption during emacs build on XFS logical volume References: <6u4rm4r53e.fsf@zork.zork.net> <1009995505.14223.9.camel@jen.americas.sgi.com> <6uy9jgpn2x.fsf@zork.zork.net> <6uu1u4pf48.fsf@zork.zork.net> <1010013019.1281.6.camel@jen.americas.sgi.com> <6upu4spccv.fsf@zork.zork.net> <1010013997.1315.11.camel@jen.americas.sgi.com> <6ulmfgpau5.fsf@zork.zork.net> From: Sean Neakums X-Message-Flag: Message text advisory: PRURIENT SUBTEXT, HEINOUS SELF-AGGRANDIZATION X-Mailer: Norman Mail-Followup-To: Linux XFS Date: Thu, 03 Jan 2002 00:20:33 +0000 In-Reply-To: <6ulmfgpau5.fsf@zork.zork.net> (Sean Neakums's message of "Wed, 02 Jan 2002 23:55:14 +0000") Message-ID: <6uheq4p9ny.fsf@zork.zork.net> User-Agent: Gnus/5.090004 (Oort Gnus v0.04) Emacs/21.1 (i386-debian-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 1782 Lines: 42 begin Sean Neakums quotation: > begin Steve Lord quotation: > >> I completed an emacs build - surprisingly quickly, but I want to try >> a different version, I am building rpms here and there is something >> wrong with the rpm package I have - or it is incompatible with my >> machine.... the compile worked, but the rpm failed to build, but the >> error seems more to do with the rpm package itself than a corrupted >> file. >> >> Have to dash now, more tomorrow. > > I've just realised that my swap is divided between two partitions. > I've taken one and created an XFS filesystem on it. Building emacs > now. Weird, it failed the with the same errors I was getting using the XFS LVM volume: make[2]: *** No rule to make target `/datacomp/emacs21-21.1/src/../lisp/register.elc', needed by `../etc/DOC'. Stop. make[2]: Leaving directory `/datacomp/emacs21-21.1/src' make[1]: *** [src] Error 2 make[1]: Leaving directory `/datacomp/emacs21-21.1' make: *** [debian/stamp-build] Error 2 I've been unpacking the source fresh for each try. What seems to be causing this build error is that the dumped emacs binary is missing. I scrolled back in the make output, and saw messages indicating that the dump had been successfully done to the files src/emacs-21.1 and src/emacs, and that src/temacs had been deleted. But when I look in src/, temacs is still there, and there is no sign of emacs-21.1 and emacs, but temacs is still there. This is jolly strange. Could the very presence of LVM be affecting XFS, even though the filesystem is on a simple partition? -- ///////////////// | | The spark of a pin | (require 'gnu) | dropping, falling feather-like. \\\\\\\\\\\\\\\\\ | | There is too much noise. From owner-linux-xfs@oss.sgi.com Wed Jan 2 18:08:18 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0328If31407 for linux-xfs-outgoing; Wed, 2 Jan 2002 18:08:18 -0800 Received: from mailhost.idcomm.com (mailhost.idcomm.com [207.40.196.14]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0328Cg31384 for ; Wed, 2 Jan 2002 18:08:12 -0800 Received: from idcomm.com (IDENT:4PQSRYNn+u1Mt+7siGAbeaK47pmN9jl1@k56-pip30.idcomm.com [209.60.72.157]) by mailhost.idcomm.com (8.10.2/8.10.0) with ESMTP id g031CIO18681 for ; Wed, 2 Jan 2002 18:12:18 -0700 Message-ID: <3C33AF81.AC235AD0@idcomm.com> Date: Wed, 02 Jan 2002 18:10:25 -0700 From: "D. Stimits" Reply-To: stimits@idcomm.com X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.6-pre1-xfs-4 i686) X-Accept-Language: en MIME-Version: 1.0 CC: Linux XFS Subject: Re: file corruption during emacs build on XFS logical volume References: <6u4rm4r53e.fsf@zork.zork.net> <1009995505.14223.9.camel@jen.americas.sgi.com> <6uy9jgpn2x.fsf@zork.zork.net> <6uu1u4pf48.fsf@zork.zork.net> <1010013019.1281.6.camel@jen.americas.sgi.com> <6upu4spccv.fsf@zork.zork.net> <1010013997.1315.11.camel@jen.americas.sgi.com> <6ulmfgpau5.fsf@zork.zork.net> <6uheq4p9ny.fsf@zork.zork.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 2173 Lines: 53 Sean Neakums wrote: > > begin Sean Neakums quotation: > > > begin Steve Lord quotation: > > > >> I completed an emacs build - surprisingly quickly, but I want to try > >> a different version, I am building rpms here and there is something > >> wrong with the rpm package I have - or it is incompatible with my > >> machine.... the compile worked, but the rpm failed to build, but the > >> error seems more to do with the rpm package itself than a corrupted > >> file. > >> > >> Have to dash now, more tomorrow. > > > > I've just realised that my swap is divided between two partitions. > > I've taken one and created an XFS filesystem on it. Building emacs > > now. > > Weird, it failed the with the same errors I was getting using the XFS > LVM volume: > > make[2]: *** No rule to make target `/datacomp/emacs21-21.1/src/../lisp/register.elc', needed by `../etc/DOC'. Stop. > make[2]: Leaving directory `/datacomp/emacs21-21.1/src' > make[1]: *** [src] Error 2 > make[1]: Leaving directory `/datacomp/emacs21-21.1' > make: *** [debian/stamp-build] Error 2 > > I've been unpacking the source fresh for each try. FYI, file compression is extremely sensitive to marginal ram. If unpacking has anything to do with it at all, and not the source of the unpack or destination, you should double-check ram with memtest86 or something similar. Let it run for many hours. D. Stimits, stimits@idcomm.com > > What seems to be causing this build error is that the dumped emacs > binary is missing. I scrolled back in the make output, and saw > messages indicating that the dump had been successfully done to the > files src/emacs-21.1 and src/emacs, and that src/temacs had been > deleted. But when I look in src/, temacs is still there, and there is > no sign of emacs-21.1 and emacs, but temacs is still there. > > This is jolly strange. Could the very presence of LVM be affecting > XFS, even though the filesystem is on a simple partition? > > -- > ///////////////// | | The spark of a pin > | (require 'gnu) | dropping, falling feather-like. > \\\\\\\\\\\\\\\\\ | | There is too much noise. From owner-linux-xfs@oss.sgi.com Wed Jan 2 18:44:43 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g032ihO32200 for linux-xfs-outgoing; Wed, 2 Jan 2002 18:44:43 -0800 Received: from mta05bw.bigpond.com (mta05bw.bigpond.com [139.134.6.95]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g032iZg32176 for ; Wed, 2 Jan 2002 18:44:35 -0800 Message-Id: <200201030244.g032iZg32176@oss.sgi.com> Received: from there ([144.135.24.69]) by mta05bw.bigpond.com (Netscape Messaging Server 4.15) with SMTP id GPCAHP00.53Y; Thu, 3 Jan 2002 11:51:25 +1000 Received: from CPE-144-137-138-230.qld.bigpond.net.au ([144.137.138.230]) by bwmam01.mailsvc.email.bigpond.com(MailRouter V3.0h 8/7174928); 03 Jan 2002 11:44:26 Content-Type: text/plain; charset="us-ascii" From: Adrian Head To: Andreas Dilger Subject: Re: [linux-lvm] Unable to get XFS, ext3, reiserfs & LVM to coexist happily Date: Thu, 3 Jan 2002 11:44:21 +1000 X-Mailer: KMail [version 1.3.1] Cc: linux-xfs@oss.sgi.com, linux-lvm@sistina.com References: <20020102110538.K12868@lynx.no> In-Reply-To: <20020102110538.K12868@lynx.no> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 1979 Lines: 53 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Thu, 3 Jan 2002 04:05, Andreas Dilger wrote: > Note that you need to apply the VFS-lock patch AFTER the lvm-1.0.1 upgrade > patch, otherwise that patch will reverse the VFS-lock patch! OK - thanks I will try this and rerun my tests. What I have found though is that the LVM_VFS_ENHANCEMENT in lvm.c gets removed with the lvm-1.0.1 upgrade patch. Is this the way it is supose to be? Isn't LVM_VFS_ENHANCEMENT needed anymore? > You should try ext3 from 2.4.18, or get it from the ext3 CVS (at > cvs.gkernel.sourceforge.net:/cvsroot/gkernel ext3). It has fixes > for a number of problems caused by error conditions while running. > If there is still a problem with ext3 oopsing with a full snapshot > (which is essentially an oops because of an I/O error on the disk) > then please file a separate bug report to the ext3 developers > (ext2-devel@lists.sourceforge.net). > > Cheers, Andreas Let me see if I understand this correctly: The problem of the kernel Oops when a snapshot overflows is actually a filesystem maintainer's/developer's problem because. The reason is that when a snapshot overflows it generates a disk full and it is up to the filesystem to deal with that and pass that error up the stack? Therefore, if there was an Oops on an: * ext3 snapshot I would have to tell the ext3 developer's/maintainer's * resierfs snapshot I would have to tell the resierfs developer's/maintainer's * xfs snapshot I would have to tell the xfs developer's/maintainer's All I'm trying to do here is understand this a little more so that I can follow up with the correct people about these problems. Thanks Andreas for your time. - -- Adrian Head (Public Key available on request.) -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE8M7d58ZJI8OvSkAcRAt9cAKCARFiVZgeQLbOLa5KDSzDKa/AbHACfQcJE 1exTKu5RksbNI+STCzB4JQ4= =HFaI -----END PGP SIGNATURE----- From owner-linux-xfs@oss.sgi.com Wed Jan 2 18:45:55 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g032jt732355 for linux-xfs-outgoing; Wed, 2 Jan 2002 18:45:55 -0800 Received: from cream.ece.utexas.edu (cream.ece.utexas.edu [128.83.51.54]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g032jrg32333 for ; Wed, 2 Jan 2002 18:45:53 -0800 Received: from localhost ([127.0.0.1] helo=cream.ece.utexas.edu) by cream.ece.utexas.edu with esmtp (Exim 3.12 #1 (Debian)) id 16Lwx4-0000bS-00; Wed, 02 Jan 2002 19:45:50 -0600 Content-Type: text/plain; charset="us-ascii" From: Adrian Head To: 5124157602@mobile.att.net Subject: X-Mailer: Perl5 Mail::Internet v1.42 Cc: linux-xfs@oss.sgi.com, linux-lvm@sistina.com References: <20020102110538.K12868@lynx.no> In-Reply-To: <20020102110538.K12868@lynx.no> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Message-Id: X-Spam-Status: No, hits=0 required=5 tests= X-Beenthere: linux-lvm@sistina.com X-Mailman-Version: 2.0.6 Reply-To: linux-lvm@sistina.com List-Help: List-Post: List-Subscribe: , List-Id: linux-lvm general discussion List-Unsubscribe: , List-Archive: X-Original-Date: Thu, 3 Jan 2002 11:44:21 +1000 Date: Thu, 3 Jan 2002 11:44:21 +1000 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 168 Lines: 4 -----BEGIN PGP SGN msg On Thu, 3 Jan 2002 04:05, Andrea Dilg > Not u ned to aply VFS-lck patch AFTR lvm-1.0.1 upgrade > patch, othrwse patch /w rvrse VFS-lck patch From owner-linux-xfs@oss.sgi.com Wed Jan 2 20:15:39 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g034FdY01569 for linux-xfs-outgoing; Wed, 2 Jan 2002 20:15:39 -0800 Received: from cream.ece.utexas.edu (cream.ece.utexas.edu [128.83.51.54]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g034Fag01547 for ; Wed, 2 Jan 2002 20:15:36 -0800 Received: from localhost ([127.0.0.1] helo=cream.ece.utexas.edu) by cream.ece.utexas.edu with esmtp (Exim 3.12 #1 (Debian)) id 16LyLu-0000s4-00; Wed, 02 Jan 2002 21:15:34 -0600 Content-Type: text/plain; charset="us-ascii" From: Adrian Head To: 5124157602@mobile.att.net Subject: X-Mailer: Perl5 Mail::Internet v1.42 Cc: linux-xfs@oss.sgi.com, linux-lvm@sistina.com References: <20020102110538.K12868@lynx.no> <200201030244.g032iZg32176@oss.sgi.com> In-Reply-To: <200201030244.g032iZg32176@oss.sgi.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Message-Id: X-Spam-Status: No, hits=0 required=5 tests= X-Beenthere: linux-lvm@sistina.com X-Mailman-Version: 2.0.6 Reply-To: linux-lvm@sistina.com List-Help: List-Post: List-Subscribe: , List-Id: linux-lvm general discussion List-Unsubscribe: , List-Archive: X-Original-Date: Thu, 3 Jan 2002 13:14:32 +1000 Date: Thu, 3 Jan 2002 13:14:32 +1000 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 172 Lines: 5 -----BEGIN PGP SGN msg Andrea I hv rerun my tst w/ lvm patch aplid in crr ordr 1) lvm-1.0.1 upgrade 2) VFS-lck w/ thi cas ext3 & rserf are fin 4 crtng snapshot, mntng From owner-linux-xfs@oss.sgi.com Wed Jan 2 20:15:08 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g034F8T01513 for linux-xfs-outgoing; Wed, 2 Jan 2002 20:15:08 -0800 Received: from mta01bw.bigpond.com (mta01bw.bigpond.com [139.134.6.78]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g034Esg01477 for ; Wed, 2 Jan 2002 20:14:54 -0800 Message-Id: <200201030414.g034Esg01477@oss.sgi.com> Received: from there ([144.135.24.87]) by mta01bw.bigpond.com (Netscape Messaging Server 4.15) with SMTP id GPCEO700.1HY; Thu, 3 Jan 2002 13:21:43 +1000 Received: from CPE-144-137-138-230.qld.bigpond.net.au ([144.137.138.230]) by bwmam07.mailsvc.email.bigpond.com(MailRouter V3.0h 62/6760085); 03 Jan 2002 13:14:44 Content-Type: text/plain; charset="us-ascii" From: Adrian Head To: Andreas Dilger Subject: Re: [linux-lvm] Unable to get XFS, ext3, reiserfs & LVM to coexist happily Date: Thu, 3 Jan 2002 13:14:32 +1000 X-Mailer: KMail [version 1.3.1] Cc: linux-xfs@oss.sgi.com, linux-lvm@sistina.com References: <20020102110538.K12868@lynx.no> <200201030244.g032iZg32176@oss.sgi.com> In-Reply-To: <200201030244.g032iZg32176@oss.sgi.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 3422 Lines: 102 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Andreas, I have rerun my tests with the lvm patches applied in the correct order: 1) lvm-1.0.1 upgrade 2) VFS-lock With this case ext3 & resierfs are fine for creating snapshots, mounting snapshots and being stable when snapshots overflow. However, XFS dies during snapshot creation. In this case where do you recommend I take this problem? LVM developers or XFS developers? - From the backtrace it appears that it is ext3 that is actually dying - am I reading this correctly? In which case does this need to be CC'd to the ext3 developers as well? Do you think it is worth my while to upgrade ext3 and try again, considering the problem is creating XFS snapshots? 2.4.17-xfs While source volume mounted: + lvm-1.0.1 upgrade + VFS-lock (In that order) * Can create ext3 snapshot? | yes * Can mount a ext3 snapshot? | yes * Can create resierfs snapshot? | yes * Can mount a resierfs snapshot? | yes * Can create xfs snapshot? | Oops btp 1234 (lvcreate) journal_start ext3_dirty_inode __mark_inode_dirty update_atime do_generic_file_read generic_file_read sys_read system_call Running processes (lvcreate) * Can mount a xfs snapshot? | Cannot test When source & snapshot mounted: * Cause oops when snapshot overflows? | - ext3 | OK - Stable - resierfs | OK - Stable - xfs | Cannot test On Thu, 3 Jan 2002 11:44, Adrian Head wrote: > On Thu, 3 Jan 2002 04:05, Andreas Dilger wrote: > > Note that you need to apply the VFS-lock patch AFTER the lvm-1.0.1 > > upgrade patch, otherwise that patch will reverse the VFS-lock patch! > > OK - thanks I will try this and rerun my tests. > > What I have found though is that the LVM_VFS_ENHANCEMENT in lvm.c gets > removed with the lvm-1.0.1 upgrade patch. Is this the way it is supose to > be? Isn't LVM_VFS_ENHANCEMENT needed anymore? > > > You should try ext3 from 2.4.18, or get it from the ext3 CVS (at > > cvs.gkernel.sourceforge.net:/cvsroot/gkernel ext3). It has fixes > > for a number of problems caused by error conditions while running. > > If there is still a problem with ext3 oopsing with a full snapshot > > (which is essentially an oops because of an I/O error on the disk) > > then please file a separate bug report to the ext3 developers > > (ext2-devel@lists.sourceforge.net). > > > > Cheers, Andreas > > Let me see if I understand this correctly: > The problem of the kernel Oops when a snapshot overflows is actually a > filesystem maintainer's/developer's problem because. The reason is that > when a snapshot overflows it generates a disk full and it is up to the > filesystem to deal with that and pass that error up the stack? > > Therefore, if there was an Oops on an: > * ext3 snapshot I would have to tell the ext3 developer's/maintainer's > * resierfs snapshot I would have to tell the resierfs > developer's/maintainer's * xfs snapshot I would have to tell the xfs > developer's/maintainer's > > All I'm trying to do here is understand this a little more so that I can > follow up with the correct people about these problems. > > Thanks Andreas for your time. - -- Adrian Head (Public Key available on request.) -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE8M8yb8ZJI8OvSkAcRAjWvAJ4u1m2L2ECk23/zBuu/BEGXZ1EQnQCgmNHC WYtni02/ThZNBfKQ8LGH1qE= =CyfK -----END PGP SIGNATURE----- From owner-linux-xfs@oss.sgi.com Wed Jan 2 21:21:38 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g035Lct02468 for linux-xfs-outgoing; Wed, 2 Jan 2002 21:21:38 -0800 Received: from cream.ece.utexas.edu (cream.ece.utexas.edu [128.83.51.54]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g035Lag02443 for ; Wed, 2 Jan 2002 21:21:36 -0800 Received: from localhost ([127.0.0.1] helo=cream.ece.utexas.edu) by cream.ece.utexas.edu with esmtp (Exim 3.12 #1 (Debian)) id 16LzNl-000131-00; Wed, 02 Jan 2002 22:21:33 -0600 Content-Type: text/plain; charset="us-ascii" From: Adrian Head To: 5124157602@mobile.att.net Subject: X-Mailer: Perl5 Mail::Internet v1.42 Cc: Linux XFS Mailing List , linux-lvm@sistina.com References: <20020102110538.K12868@lynx.no> In-Reply-To: <20020102110538.K12868@lynx.no> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Message-Id: X-Spam-Status: No, hits=0 required=5 tests= X-Beenthere: linux-lvm@sistina.com X-Mailman-Version: 2.0.6 Reply-To: linux-lvm@sistina.com List-Help: List-Post: List-Subscribe: , List-Id: linux-lvm general discussion List-Unsubscribe: , List-Archive: X-Original-Date: Thu, 3 Jan 2002 14:20:34 +1000 Date: Thu, 3 Jan 2002 14:20:34 +1000 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 184 Lines: 5 -----BEGIN PGP SGN msg On Thu, 3 Jan 2002 04:05, Andrea Dilg > u s/d try ext3 from 2.4.18, or get it from ext3 CVS (at > cvs.gkernel.sorceforg.nt:/cvsrot/gkernel ext3)It has fix From owner-linux-xfs@oss.sgi.com Wed Jan 2 21:21:01 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g035L1m02434 for linux-xfs-outgoing; Wed, 2 Jan 2002 21:21:01 -0800 Received: from mta03ps.bigpond.com (mta03ps.bigpond.com [144.135.25.135]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g035Krg02412 for ; Wed, 2 Jan 2002 21:20:56 -0800 Message-Id: <200201030520.g035Krg02412@oss.sgi.com> Received: from there ([144.135.25.87]) by mta03ps.bigpond.com (Netscape Messaging Server 4.15) with SMTP id GPCHQ600.B34; Thu, 3 Jan 2002 14:27:42 +1000 Received: from CPE-144-137-138-230.qld.bigpond.net.au ([144.137.138.230]) by psmam07.mailsvc.email.bigpond.com(MailRouter V3.0h 125/2238906); 03 Jan 2002 14:20:43 Content-Type: text/plain; charset="us-ascii" From: Adrian Head To: Andreas Dilger Subject: Re: [linux-lvm] Unable to get XFS, ext3, reiserfs & LVM to coexist happily Date: Thu, 3 Jan 2002 14:20:34 +1000 X-Mailer: KMail [version 1.3.1] Cc: Linux XFS Mailing List , linux-lvm@sistina.com References: <20020102110538.K12868@lynx.no> In-Reply-To: <20020102110538.K12868@lynx.no> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 1247 Lines: 36 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Thu, 3 Jan 2002 04:05, Andreas Dilger wrote: > > You should try ext3 from 2.4.18, or get it from the ext3 CVS (at > cvs.gkernel.sourceforge.net:/cvsroot/gkernel ext3). It has fixes > for a number of problems caused by error conditions while running. > If there is still a problem with ext3 oopsing with a full snapshot > (which is essentially an oops because of an I/O error on the disk) > then please file a separate bug report to the ext3 developers > (ext2-devel@lists.sourceforge.net). > > Cheers, Andreas I have been looking at the changlog for 2.4.18-pre1 which seems to be the latest at the moment and I cannot see any changes relating to ext3? http://www.kernel.org/pub/linux/kernel/v2.4/testing/patch-2.4.18.log The 2.4.17 has a few changes relating to ext3: http://www.kernel.org/pub/linux/kernel/v2.4/testing/patch-2.4.17.log Do you think it is worth my while to update ext3 from the ext3 CVS? - -- Adrian Head (Public Key available on request.) -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE8M9wV8ZJI8OvSkAcRAibbAJ9K8ldAR5jGoamKu542vg6UVh4MswCeKDSw NryXQBft4SdUc5PQ9Kroqcw= =qO7n -----END PGP SIGNATURE----- From owner-linux-xfs@oss.sgi.com Thu Jan 3 01:35:15 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g039ZFr06235 for linux-xfs-outgoing; Thu, 3 Jan 2002 01:35:15 -0800 Received: from ns.martos.bme.hu (ns.martos.bme.hu [152.66.232.1]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g039ZCg06213 for ; Thu, 3 Jan 2002 01:35:12 -0800 Received: from amavis by ns.martos.bme.hu with scanned-ok (Exim 3.33 #1 (Debian)) id 16M3LA-0002PG-00 for ; Thu, 03 Jan 2002 09:35:08 +0100 Received: from tompos by ns.martos.bme.hu with local (Exim 3.33 #1 (Debian)) id 16M3L8-0002P8-00 for ; Thu, 03 Jan 2002 09:35:06 +0100 Date: Thu, 3 Jan 2002 09:35:06 +0100 From: Papp Tamas To: linux-xfs@oss.sgi.com Subject: boot-floppies for debian Message-ID: <20020103083506.GA9129@ns> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.25i X-Virus-Scanned: by AMaViS 0.3.12pre3 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 120 Lines: 12 hi, where can I get boot-floppies for debian? there was an URL in the maiing list, but now it's dead 10x tompos From owner-linux-xfs@oss.sgi.com Thu Jan 3 02:00:40 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g03A0eI06789 for linux-xfs-outgoing; Thu, 3 Jan 2002 02:00:40 -0800 Received: from com.esnaola.org (aboukir-101-1-5-ldarnis.adsl.nerim.net [80.65.225.199]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g03A0ag06767 for ; Thu, 3 Jan 2002 02:00:37 -0800 Received: from localhost (localhost [127.0.0.1]) by com.esnaola.org (Microsoft Exchange) with ESMTP id ED2BB2817A0 for ; Thu, 3 Jan 2002 10:00:30 +0100 (CET) Received: from neotrantor.esnaola.org (neotrantor.esnaola.org [192.168.33.18]) by com.esnaola.org (Microsoft Exchange) with ESMTP id E05A2281A42 for ; Thu, 3 Jan 2002 10:00:28 +0100 (CET) Subject: BOOT DISKS DEBIAN From: Lionel DARNIS To: linux-xfs@oss.sgi.com Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/1.0.1.99+cvs.2001.12.19.09.00 (Preview Release) Date: 03 Jan 2002 10:00:30 +0100 Message-Id: <1010048430.29989.5.camel@neotrantor> Mime-Version: 1.0 X-Virus-Scanned: by AMaViS perl-10 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 94 Lines: 9 You can download here : http://www.esnaola.org/docs/debianxfs/didac2.html See ya, Lionel From owner-linux-xfs@oss.sgi.com Thu Jan 3 02:03:30 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g03A3Uh06991 for linux-xfs-outgoing; Thu, 3 Jan 2002 02:03:30 -0800 Received: from zork.zork.net (zork.zork.net [64.81.65.8]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g03A3Og06945 for ; Thu, 3 Jan 2002 02:03:24 -0800 Received: from localhost (zork.zork.net) [127.0.0.1] by zork.zork.net with esmtp (Exim 3.33 #1 (Debian)) id 16M3mS-0003SH-00; Thu, 03 Jan 2002 01:03:20 -0800 To: Linux XFS Subject: Re: file corruption during emacs build on XFS logical volume References: <6u4rm4r53e.fsf@zork.zork.net> <1009995505.14223.9.camel@jen.americas.sgi.com> <6uy9jgpn2x.fsf@zork.zork.net> <6uu1u4pf48.fsf@zork.zork.net> <1010013019.1281.6.camel@jen.americas.sgi.com> <6upu4spccv.fsf@zork.zork.net> <1010013997.1315.11.camel@jen.americas.sgi.com> <6ulmfgpau5.fsf@zork.zork.net> <6uheq4p9ny.fsf@zork.zork.net> <3C33AF81.AC235AD0@idcomm.com> From: Sean Neakums X-Message-Flag: Message text advisory: HYPERLINK PATENT INFRINGEMENT, DISCLOSURE OF TRADE SECRET(S) X-Mailer: Norman Mail-Followup-To: Linux XFS Date: Thu, 03 Jan 2002 09:03:20 +0000 In-Reply-To: <3C33AF81.AC235AD0@idcomm.com> ("D. Stimits"'s message of "Wed, 02 Jan 2002 18:10:25 -0700") Message-ID: <6ubsgbq013.fsf@zork.zork.net> User-Agent: Gnus/5.090004 (Oort Gnus v0.04) Emacs/21.1 (i386-debian-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 1039 Lines: 24 begin D. Stimits quotation: > Sean Neakums wrote: >> I've been unpacking the source fresh for each try. > > FYI, file compression is extremely sensitive to marginal ram. If > unpacking has anything to do with it at all, and not the source of > the unpack or destination, you should double-check ram with > memtest86 or something similar. Let it run for many hours. I ran two passes of memtest-86 a few days ago, after I had that XFS filesystem shutdown. I'm not getting any errors at the unpack stage. I mentioned that I was unpacking fresh for each try in order to establish that the tree itself was not b0rked. Note from my previous messages that the builds have only failed when I built on XFS, and not when I built on ext2, and that builds on XFS have succeeded when I use 2.4.14-pre7. This just doesn't feel random to me. -- ///////////////// | | The spark of a pin | (require 'gnu) | dropping, falling feather-like. \\\\\\\\\\\\\\\\\ | | There is too much noise. From owner-linux-xfs@oss.sgi.com Thu Jan 3 02:31:50 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g03AVow07693 for linux-xfs-outgoing; Thu, 3 Jan 2002 02:31:50 -0800 Received: from hob.slb.nwc.acsalaska.net (hob.slb.nwc.acsalaska.net [209.112.155.42]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g03AVig07669 for ; Thu, 3 Jan 2002 02:31:44 -0800 Received: from erbenson.alaska.net (15-pm33.nwc.alaska.net [209.112.159.15]) by hob.slb.nwc.acsalaska.net (8.11.6/8.11.6) with ESMTP id g039VeE00609 for ; Thu, 3 Jan 2002 00:31:41 -0900 (AKST) (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 1A2EB393A for ; Thu, 3 Jan 2002 00:31:38 -0900 (AKST) Received: by plato.local.lan (Postfix, from userid 1000) id A41301027B; Thu, 3 Jan 2002 00:31:38 -0900 (AKST) Date: Thu, 3 Jan 2002 00:31:38 -0900 From: Ethan Benson To: linux-xfs@oss.sgi.com Subject: Re: boot-floppies for debian Message-ID: <20020103003138.A11107@plato.local.lan> Mail-Followup-To: linux-xfs@oss.sgi.com References: <20020103083506.GA9129@ns> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="k1lZvvs/B4yU6o8G" Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20020103083506.GA9129@ns>; from tompos@martos.bme.hu on Thu, Jan 03, 2002 at 09:35:06AM +0100 X-OS: Debian GNU Mail-Copies-To: nobody X-No-CC: I subscribe to this list; do not CC me on replies. Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 973 Lines: 37 --k1lZvvs/B4yU6o8G Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Jan 03, 2002 at 09:35:06AM +0100, Papp Tamas wrote: >=20 >=20 > hi,=20 >=20 > where can I get boot-floppies for debian? just replace the woody boot-floppies kernel with a xfs enabled one, and add mkfs.xfs to the root.bin ramdisk (from xfsprogs-bf). xfs will be offered as a choice automatically then. woody boot-floppies completly support XFS, but debian is not planning on shipping any flavor with an XFS enabled kernel. --=20 Ethan Benson http://www.alaska.net/~erbenson/ --k1lZvvs/B4yU6o8G 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 iEYEARECAAYFAjw0JPoACgkQJKx7GixEevy5AACdHgxJ7b2WZPLvTx5ImxNYLpgz n1sAn3qaNpoFkfysIcHSKbj/bHAPVdVs =1dVT -----END PGP SIGNATURE----- --k1lZvvs/B4yU6o8G-- From owner-linux-xfs@oss.sgi.com Thu Jan 3 07:56:09 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g03Fu9E19782 for linux-xfs-outgoing; Thu, 3 Jan 2002 07:56:09 -0800 Received: from pneumatic-tube.sgi.com (pneumatic-tube.sgi.com [204.94.214.22]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g03Fu3g19760 for ; Thu, 3 Jan 2002 07:56:03 -0800 Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id GAA02897 for ; Thu, 3 Jan 2002 06:56:34 -0800 (PST) mail_from (lord@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id IAA3989266; Thu, 3 Jan 2002 08:54:44 -0600 (CST) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id IAA98952; Thu, 3 Jan 2002 08:54:44 -0600 (CST) Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id g03EnbF12076; Thu, 3 Jan 2002 08:49:37 -0600 Subject: Re: file corruption during emacs build on XFS logical volume From: Steve Lord To: Sean Neakums Cc: Linux XFS In-Reply-To: <6ubsgbq013.fsf@zork.zork.net> References: <6u4rm4r53e.fsf@zork.zork.net> <1009995505.14223.9.camel@jen.americas.sgi.com> <6uy9jgpn2x.fsf@zork.zork.net> <6uu1u4pf48.fsf@zork.zork.net> <1010013019.1281.6.camel@jen.americas.sgi.com> <6upu4spccv.fsf@zork.zork.net> <1010013997.1315.11.camel@jen.americas.sgi.com> <6ulmfgpau5.fsf@zork.zork.net> <6uheq4p9ny.fsf@zork.zork.net> <3C33AF81.AC235AD0@idcomm.com> <6ubsgbq013.fsf@zork.zork.net> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/1.0.0.99+cvs.2001.12.18.08.57 (Preview Release) Date: 03 Jan 2002 08:49:37 -0600 Message-Id: <1010069377.23328.15.camel@jen.americas.sgi.com> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 1768 Lines: 43 On Thu, 2002-01-03 at 03:03, Sean Neakums wrote: > begin D. Stimits quotation: > > > Sean Neakums wrote: > >> I've been unpacking the source fresh for each try. > > > > FYI, file compression is extremely sensitive to marginal ram. If > > unpacking has anything to do with it at all, and not the source of > > the unpack or destination, you should double-check ram with > > memtest86 or something similar. Let it run for many hours. > > I ran two passes of memtest-86 a few days ago, after I had that XFS > filesystem shutdown. > > I'm not getting any errors at the unpack stage. I mentioned that I > was unpacking fresh for each try in order to establish that the tree > itself was not b0rked. Note from my previous messages that the builds > have only failed when I built on XFS, and not when I built on ext2, > and that builds on XFS have succeeded when I use 2.4.14-pre7. This > just doesn't feel random to me. > Since I am building on a redhat based box, I am doing rpm builds not debian package builds, and the rpm version which appears friendly to this box is emacs-20 not emacs-21. Having said that, emacs is building OK for me here. It is difficult to tell if the problem you are seeing is in the true emacs build, or in the package generation. Can you tell, if it is the package generation then the rpm build is not a valid test case here. I do not think that the presence of LVM in the kernel will have any effect on XFS, it is good to have a simpler test case though, there are some subtle interactions between XFS and LVM. I am off to find a combo where the rpm build will work for emacs-21. Steve -- Steve Lord voice: +1-651-683-3511 Principal Engineer, Filesystem Software email: lord@sgi.com From owner-linux-xfs@oss.sgi.com Thu Jan 3 08:38:24 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g03GcOW20760 for linux-xfs-outgoing; Thu, 3 Jan 2002 08:38:24 -0800 Received: from mta01ps.bigpond.com (mta01ps.bigpond.com [144.135.25.133]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g03GcJg20734 for ; Thu, 3 Jan 2002 08:38:19 -0800 Message-Id: <200201031638.g03GcJg20734@oss.sgi.com> Received: from there ([144.135.25.87]) by mta01ps.bigpond.com (Netscape Messaging Server 4.15) with SMTP id GPDD3900.05L for ; Fri, 4 Jan 2002 01:45:09 +1000 Received: from CPE-144-137-138-230.qld.bigpond.net.au ([144.137.138.230]) by psmam07.mailsvc.email.bigpond.com(MailRouter V3.0h 125/2677139); 04 Jan 2002 01:38:10 Content-Type: text/plain; charset="us-ascii" From: Adrian Head To: Linux XFS Subject: Re: file corruption during emacs build on XFS logical volume Date: Fri, 4 Jan 2002 01:38:06 +1000 X-Mailer: KMail [version 1.3.1] References: <6u4rm4r53e.fsf@zork.zork.net> <6ubsgbq013.fsf@zork.zork.net> <1010069377.23328.15.camel@jen.americas.sgi.com> In-Reply-To: <1010069377.23328.15.camel@jen.americas.sgi.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 949 Lines: 30 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Fri, 4 Jan 2002 00:49, Steve Lord wrote: > > I do not think that the presence of LVM in the kernel will have any > effect on XFS, it is good to have a simpler test case though, there > are some subtle interactions between XFS and LVM. This is probabily unrelated & OT but just straight XFS on LVM seems OK in the fact that I have not seen any problems with it as yet (but then again I have not been looking for problems like file corruption) in any of my tests to date. There are however, may subtle (unhappy) interactions between XFS, LVM and other kernel areas when you try to do snapshots for example. - -- Adrian Head (Public Key available on request.) -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE8NHrh8ZJI8OvSkAcRAkp4AKCG0zoFe1k4Mg9QzkRMxhogT7J/UACeN3Yf TRaK72ZvXelDk+x+CzjDVKI= =lzJS -----END PGP SIGNATURE----- From owner-linux-xfs@oss.sgi.com Thu Jan 3 08:45:23 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g03GjNO21035 for linux-xfs-outgoing; Thu, 3 Jan 2002 08:45:23 -0800 Received: from zork.zork.net (zork.zork.net [64.81.65.8]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g03GjIg21009 for ; Thu, 3 Jan 2002 08:45:18 -0800 Received: from localhost (zork.zork.net) [127.0.0.1] by zork.zork.net with esmtp (Exim 3.33 #1 (Debian)) id 16MA3Q-0007aO-00; Thu, 03 Jan 2002 07:45:16 -0800 To: Linux XFS Subject: Re: file corruption during emacs build on XFS logical volume References: <6u4rm4r53e.fsf@zork.zork.net> <1009995505.14223.9.camel@jen.americas.sgi.com> <6uy9jgpn2x.fsf@zork.zork.net> <6uu1u4pf48.fsf@zork.zork.net> <1010013019.1281.6.camel@jen.americas.sgi.com> <6upu4spccv.fsf@zork.zork.net> <1010013997.1315.11.camel@jen.americas.sgi.com> <6ulmfgpau5.fsf@zork.zork.net> <6uheq4p9ny.fsf@zork.zork.net> <3C33AF81.AC235AD0@idcomm.com> <6ubsgbq013.fsf@zork.zork.net> <1010069377.23328.15.camel@jen.americas.sgi.com> From: Sean Neakums X-Message-Flag: Message text advisory: AFFIRMATION OF THE CONSEQUENT, DENIAL OF THE ANTECEDENT X-Mailer: Norman Mail-Followup-To: Linux XFS Date: Thu, 03 Jan 2002 15:45:16 +0000 In-Reply-To: <1010069377.23328.15.camel@jen.americas.sgi.com> (Steve Lord's message of "03 Jan 2002 08:49:37 -0600") Message-ID: <6u7kqzphf7.fsf@zork.zork.net> User-Agent: Gnus/5.090004 (Oort Gnus v0.04) Emacs/21.1 (i386-debian-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 1489 Lines: 32 begin Steve Lord quotation: > On Thu, 2002-01-03 at 03:03, Sean Neakums wrote: >> begin D. Stimits quotation: >> I'm not getting any errors at the unpack stage. I mentioned that I >> was unpacking fresh for each try in order to establish that the tree >> itself was not b0rked. Note from my previous messages that the builds >> have only failed when I built on XFS, and not when I built on ext2, >> and that builds on XFS have succeeded when I use 2.4.14-pre7. This >> just doesn't feel random to me. >> > > Since I am building on a redhat based box, I am doing rpm builds not > debian package builds, and the rpm version which appears friendly to > this box is emacs-20 not emacs-21. Having said that, emacs is building > OK for me here. It is difficult to tell if the problem you are seeing > is in the true emacs build, or in the package generation. Can you tell, > if it is the package generation then the rpm build is not a valid test > case here. I don't even get as far as generating packages when I build on XFS; the part I mentioned about temacs re-appearing mysteriously happens during the actual emacs21 build. I can't remember if I've mentioned it before, but Ive run xfs_repair on the FS in question, with no errors reported. Ugh, this sure is weird and crazy. -- ///////////////// | | The spark of a pin | (require 'gnu) | dropping, falling feather-like. \\\\\\\\\\\\\\\\\ | | There is too much noise. From owner-linux-xfs@oss.sgi.com Thu Jan 3 08:46:16 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g03GkGf21167 for linux-xfs-outgoing; Thu, 3 Jan 2002 08:46:16 -0800 Received: from rj.sgi.com (rj.sgi.com [204.94.215.100]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g03GkCg21145 for ; Thu, 3 Jan 2002 08:46:12 -0800 Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by rj.sgi.com (8.11.4/8.11.4/linux-outbound_gateway-1.1) with ESMTP id g03Fk5Y26507 for ; Thu, 3 Jan 2002 07:46:05 -0800 Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id JAA3984575; Thu, 3 Jan 2002 09:44:49 -0600 (CST) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id JAA08506; Thu, 3 Jan 2002 09:44:49 -0600 (CST) Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id g03Fdgc12141; Thu, 3 Jan 2002 09:39:42 -0600 Subject: Re: file corruption during emacs build on XFS logical volume From: Steve Lord To: Steve Lord Cc: Sean Neakums , Linux XFS In-Reply-To: <1010069377.23328.15.camel@jen.americas.sgi.com> References: <6u4rm4r53e.fsf@zork.zork.net> <1009995505.14223.9.camel@jen.americas.sgi.com> <6uy9jgpn2x.fsf@zork.zork.net> <6uu1u4pf48.fsf@zork.zork.net> <1010013019.1281.6.camel@jen.americas.sgi.com> <6upu4spccv.fsf@zork.zork.net> <1010013997.1315.11.camel@jen.americas.sgi.com> <6ulmfgpau5.fsf@zork.zork.net> <6uheq4p9ny.fsf@zork.zork.net> <3C33AF81.AC235AD0@idcomm.com> <6ubsgbq013.fsf@zork.zork.net> <1010069377.23328.15.camel@jen.americas.sgi.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/1.0.0.99+cvs.2001.12.18.08.57 (Preview Release) Date: 03 Jan 2002 09:39:42 -0600 Message-Id: <1010072382.23328.38.camel@jen.americas.sgi.com> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 802 Lines: 23 On Thu, 2002-01-03 at 08:49, Steve Lord wrote: > > Since I am building on a redhat based box, I am doing rpm builds not > debian package builds, and the rpm version which appears friendly to > this box is emacs-20 not emacs-21. Having said that, emacs is building > OK for me here. It is difficult to tell if the problem you are seeing > is in the true emacs build, or in the package generation. Can you tell, > if it is the package generation then the rpm build is not a valid test > case here. > Following up to myself, dropping the system memory to 128M seems to have triggered the problem here, so yes there does seem to be an XFS bug here. Steve -- Steve Lord voice: +1-651-683-3511 Principal Engineer, Filesystem Software email: lord@sgi.com From owner-linux-xfs@oss.sgi.com Thu Jan 3 08:48:13 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g03GmDn21329 for linux-xfs-outgoing; Thu, 3 Jan 2002 08:48:13 -0800 Received: from rj.sgi.com (rj.sgi.com [204.94.215.100]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g03Gm7g21302 for ; Thu, 3 Jan 2002 08:48:07 -0800 Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by rj.sgi.com (8.11.4/8.11.4/linux-outbound_gateway-1.1) with ESMTP id g03Fm0Y26599 for ; Thu, 3 Jan 2002 07:48:00 -0800 Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id JAA3992568; Thu, 3 Jan 2002 09:46:44 -0600 (CST) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id JAA08657; Thu, 3 Jan 2002 09:46:44 -0600 (CST) Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id g03Ffb812145; Thu, 3 Jan 2002 09:41:37 -0600 Subject: Re: file corruption during emacs build on XFS logical volume From: Steve Lord To: Adrian Head Cc: Linux XFS In-Reply-To: <200201031638.g03GcJg20734@oss.sgi.com> References: <6u4rm4r53e.fsf@zork.zork.net> <6ubsgbq013.fsf@zork.zork.net> <1010069377.23328.15.camel@jen.americas.sgi.com> <200201031638.g03GcJg20734@oss.sgi.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/1.0.0.99+cvs.2001.12.18.08.57 (Preview Release) Date: 03 Jan 2002 09:41:37 -0600 Message-Id: <1010072497.12080.42.camel@jen.americas.sgi.com> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 1769 Lines: 55 On Thu, 2002-01-03 at 09:38, Adrian Head wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On Fri, 4 Jan 2002 00:49, Steve Lord wrote: > > > > I do not think that the presence of LVM in the kernel will have any > > effect on XFS, it is good to have a simpler test case though, there > > are some subtle interactions between XFS and LVM. > > This is probabily unrelated & OT but just straight XFS on LVM seems OK in the > fact that I have not seen any problems with it as yet (but then again I have > not been looking for problems like file corruption) in any of my tests to > date. > > There are however, may subtle (unhappy) interactions between XFS, LVM and > other kernel areas when you try to do snapshots for example. Yes, I have seen the thread, I have just not had the time to look into it yet. Your last message said that the xfs snapshot creation was failing, but with an ext3 stack trace..... You also mention out of space problems in the snapshot. Can you summarize where your kernel came from - I see you have lots of stuff in there. Do you still need special lvm patches to turn on snapshotting support - it has been a while. Also, send me a quick rundown of the commands you need to use to setup a volume for snapshotting - it will save me the research. Thanks Steve > > - -- > Adrian Head > > (Public Key available on request.) > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.0.6 (GNU/Linux) > Comment: For info see http://www.gnupg.org > > iD8DBQE8NHrh8ZJI8OvSkAcRAkp4AKCG0zoFe1k4Mg9QzkRMxhogT7J/UACeN3Yf > TRaK72ZvXelDk+x+CzjDVKI= > =lzJS > -----END PGP SIGNATURE----- -- Steve Lord voice: +1-651-683-3511 Principal Engineer, Filesystem Software email: lord@sgi.com From owner-linux-xfs@oss.sgi.com Thu Jan 3 08:56:08 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g03Gu8121605 for linux-xfs-outgoing; Thu, 3 Jan 2002 08:56:08 -0800 Received: from zork.zork.net (zork.zork.net [64.81.65.8]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g03Gu4g21583 for ; Thu, 3 Jan 2002 08:56:04 -0800 Received: from localhost (zork.zork.net) [127.0.0.1] by zork.zork.net with esmtp (Exim 3.33 #1 (Debian)) id 16MADq-0007gb-00; Thu, 03 Jan 2002 07:56:02 -0800 To: Linux XFS Subject: Re: file corruption during emacs build on XFS logical volume References: <6u4rm4r53e.fsf@zork.zork.net> <1009995505.14223.9.camel@jen.americas.sgi.com> <6uy9jgpn2x.fsf@zork.zork.net> <6uu1u4pf48.fsf@zork.zork.net> <1010013019.1281.6.camel@jen.americas.sgi.com> <6upu4spccv.fsf@zork.zork.net> <1010013997.1315.11.camel@jen.americas.sgi.com> <6ulmfgpau5.fsf@zork.zork.net> <6uheq4p9ny.fsf@zork.zork.net> <3C33AF81.AC235AD0@idcomm.com> <6ubsgbq013.fsf@zork.zork.net> <1010069377.23328.15.camel@jen.americas.sgi.com> <1010072382.23328.38.camel@jen.americas.sgi.com> From: Sean Neakums X-Message-Flag: Message text advisory: BRAZEN SELF-DECEIT, HATE SPEECH X-Mailer: Norman Mail-Followup-To: Linux XFS Date: Thu, 03 Jan 2002 15:56:02 +0000 In-Reply-To: <1010072382.23328.38.camel@jen.americas.sgi.com> (Steve Lord's message of "03 Jan 2002 09:39:42 -0600") Message-ID: <6u3d1npgx9.fsf@zork.zork.net> User-Agent: Gnus/5.090004 (Oort Gnus v0.04) Emacs/21.1 (i386-debian-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 979 Lines: 23 begin Steve Lord quotation: > On Thu, 2002-01-03 at 08:49, Steve Lord wrote: >> >> Since I am building on a redhat based box, I am doing rpm builds not >> debian package builds, and the rpm version which appears friendly to >> this box is emacs-20 not emacs-21. Having said that, emacs is building >> OK for me here. It is difficult to tell if the problem you are seeing >> is in the true emacs build, or in the package generation. Can you tell, >> if it is the package generation then the rpm build is not a valid test >> case here. > > Following up to myself, dropping the system memory to 128M seems to > have triggered the problem here, so yes there does seem to be an > XFS bug here. Excellent. I was beginning to think that it was something specific to my setup. -- ///////////////// | | The spark of a pin | (require 'gnu) | dropping, falling feather-like. \\\\\\\\\\\\\\\\\ | | There is too much noise. From owner-linux-xfs@oss.sgi.com Thu Jan 3 09:36:38 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g03Hacl22630 for linux-xfs-outgoing; Thu, 3 Jan 2002 09:36:38 -0800 Received: from deliverator.sgi.com (deliverator.sgi.com [204.94.214.10]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g03HaVg22607 for ; Thu, 3 Jan 2002 09:36:31 -0800 Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id IAA05464 for ; Thu, 3 Jan 2002 08:36:13 -0800 (PST) mail_from (lord@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id KAA3974006; Thu, 3 Jan 2002 10:35:12 -0600 (CST) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id KAA14991; Thu, 3 Jan 2002 10:35:12 -0600 (CST) Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id g03GU4w28422; Thu, 3 Jan 2002 10:30:04 -0600 Subject: Re: file corruption during emacs build on XFS logical volume From: Steve Lord To: Sean Neakums Cc: Linux XFS In-Reply-To: <6u3d1npgx9.fsf@zork.zork.net> References: <6u4rm4r53e.fsf@zork.zork.net> <1009995505.14223.9.camel@jen.americas.sgi.com> <6uy9jgpn2x.fsf@zork.zork.net> <6uu1u4pf48.fsf@zork.zork.net> <1010013019.1281.6.camel@jen.americas.sgi.com> <6upu4spccv.fsf@zork.zork.net> <1010013997.1315.11.camel@jen.americas.sgi.com> <6ulmfgpau5.fsf@zork.zork.net> <6uheq4p9ny.fsf@zork.zork.net> <3C33AF81.AC235AD0@idcomm.com> <6ubsgbq013.fsf@zork.zork.net> <1010069377.23328.15.camel@jen.americas.sgi.com> <1010072382.23328.38.camel@jen.americas.sgi.com> <6u3d1npgx9.fsf@zork.zork.net> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/1.0.0.99+cvs.2001.12.18.08.57 (Preview Release) Date: 03 Jan 2002 10:30:04 -0600 Message-Id: <1010075404.12080.79.camel@jen.americas.sgi.com> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 1451 Lines: 37 On Thu, 2002-01-03 at 09:56, Sean Neakums wrote: > begin Steve Lord quotation: > > > On Thu, 2002-01-03 at 08:49, Steve Lord wrote: > >> > >> Since I am building on a redhat based box, I am doing rpm builds not > >> debian package builds, and the rpm version which appears friendly to > >> this box is emacs-20 not emacs-21. Having said that, emacs is building > >> OK for me here. It is difficult to tell if the problem you are seeing > >> is in the true emacs build, or in the package generation. Can you tell, > >> if it is the package generation then the rpm build is not a valid test > >> case here. > > > > Following up to myself, dropping the system memory to 128M seems to > > have triggered the problem here, so yes there does seem to be an > > XFS bug here. > > Excellent. I was beginning to think that it was something specific to > my setup. It gets even better, the other difference was that emacs was already installed on the box were it worked, if I remove emacs it fails to find it and fails in the same manner. So scratch memory size as being the trigger here. Steve > > -- > ///////////////// | | The spark of a pin > | (require 'gnu) | dropping, falling feather-like. > \\\\\\\\\\\\\\\\\ | | There is too much noise. -- Steve Lord voice: +1-651-683-3511 Principal Engineer, Filesystem Software email: lord@sgi.com From owner-linux-xfs@oss.sgi.com Thu Jan 3 09:53:37 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g03HrbR23137 for linux-xfs-outgoing; Thu, 3 Jan 2002 09:53:37 -0800 Received: from pneumatic-tube.sgi.com (pneumatic-tube.sgi.com [204.94.214.22]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g03HrWg23113 for ; Thu, 3 Jan 2002 09:53:32 -0800 Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id IAA01185 for ; Thu, 3 Jan 2002 08:54:03 -0800 (PST) mail_from (lord@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id KAA3995046; Thu, 3 Jan 2002 10:52:13 -0600 (CST) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id KAA16365; Thu, 3 Jan 2002 10:52:13 -0600 (CST) Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id g03Gl6R28473; Thu, 3 Jan 2002 10:47:06 -0600 Subject: Re: file corruption during emacs build on XFS logical volume From: Steve Lord To: Sean Neakums Cc: Linux XFS In-Reply-To: <1010075404.12080.79.camel@jen.americas.sgi.com> References: <6u4rm4r53e.fsf@zork.zork.net> <1009995505.14223.9.camel@jen.americas.sgi.com> <6uy9jgpn2x.fsf@zork.zork.net> <6uu1u4pf48.fsf@zork.zork.net> <1010013019.1281.6.camel@jen.americas.sgi.com> <6upu4spccv.fsf@zork.zork.net> <1010013997.1315.11.camel@jen.americas.sgi.com> <6ulmfgpau5.fsf@zork.zork.net> <6uheq4p9ny.fsf@zork.zork.net> <3C33AF81.AC235AD0@idcomm.com> <6ubsgbq013.fsf@zork.zork.net> <1010069377.23328.15.camel@jen.americas.sgi.com> <1010072382.23328.38.camel@jen.americas.sgi.com> <6u3d1npgx9.fsf@zork.zork.net> <1010075404.12080.79.camel@jen.americas.sgi.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/1.0.0.99+cvs.2001.12.18.08.57 (Preview Release) Date: 03 Jan 2002 10:47:06 -0600 Message-Id: <1010076426.12080.86.camel@jen.americas.sgi.com> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 1158 Lines: 35 On Thu, 2002-01-03 at 10:30, Steve Lord wrote: > On Thu, 2002-01-03 at 09:56, Sean Neakums wrote: > > begin Steve Lord quotation: > > > > > Following up to myself, dropping the system memory to 128M seems to > > > have triggered the problem here, so yes there does seem to be an > > > XFS bug here. > > > > Excellent. I was beginning to think that it was something specific to > > my setup. > > It gets even better, the other difference was that emacs was already > installed on the box were it worked, if I remove emacs it fails to find > it and fails in the same manner. So scratch memory size as being the > trigger here. > > Steve > However, a build of emacs on a box running ext3 filesystems and no emacs installed fails with exactly the same error. So it would appear to not be XFS related at all, and more of an emacs build issue. Can you check out a build on another fs on a box which does not have emacs installed already? You could just rename your emacs binary rather than deinstall. Steve -- Steve Lord voice: +1-651-683-3511 Principal Engineer, Filesystem Software email: lord@sgi.com From owner-linux-xfs@oss.sgi.com Thu Jan 3 09:54:55 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g03Hsti23302 for linux-xfs-outgoing; Thu, 3 Jan 2002 09:54:55 -0800 Received: from lynx.adilger.int (h24-64-71-161.cg.shawcable.net [24.64.71.161]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g03Hsng23275 for ; Thu, 3 Jan 2002 09:54:49 -0800 Received: (from adilger@localhost) by lynx.adilger.int (8.11.2/8.11.2) id g03GsZm10630; Thu, 3 Jan 2002 09:54:35 -0700 Date: Thu, 3 Jan 2002 09:54:35 -0700 From: Andreas Dilger To: Adrian Head Cc: linux-xfs@oss.sgi.com, linux-lvm@sistina.com Subject: Re: [linux-lvm] Unable to get XFS, ext3, reiserfs & LVM to coexist happily Message-ID: <20020103095435.U12868@lynx.no> Mail-Followup-To: Adrian Head , linux-xfs@oss.sgi.com, linux-lvm@sistina.com References: <20020102110538.K12868@lynx.no> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.4i In-Reply-To: ; from ahead@bigpond.net.au on Thu, Jan 03, 2002 at 11:44:21AM +1000 X-GPG-Key: 1024D/0D35BED6 X-GPG-Fingerprint: 7A37 5D79 BF1B CECA D44F 8A29 A488 39F5 0D35 BED6 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 2154 Lines: 43 On Jan 03, 2002 11:44 +1000, Adrian Head wrote: > On Thu, 3 Jan 2002 04:05, Andreas Dilger wrote: > > You should try ext3 from 2.4.18, or get it from the ext3 CVS (at > > cvs.gkernel.sourceforge.net:/cvsroot/gkernel ext3). It has fixes > > for a number of problems caused by error conditions while running. > > If there is still a problem with ext3 oopsing with a full snapshot > > (which is essentially an oops because of an I/O error on the disk) > > then please file a separate bug report to the ext3 developers > > (ext2-devel@lists.sourceforge.net). > > Let me see if I understand this correctly: > The problem of the kernel Oops when a snapshot overflows is actually a > filesystem maintainer's/developer's problem because. The reason is that when > a snapshot overflows it generates a disk full and it is up to the filesystem > to deal with that and pass that error up the stack? Close. When a snapshot overflows, it actually generates an "I/O error" (i.e. read or write error, just like if the disk had a bad sector on it) and if the filesystem doesn't handle that properly then it will oops. > Therefore, if there was an Oops on an: > * ext3 snapshot I would have to tell the ext3 developer's/maintainer's > * resierfs snapshot I would have to tell the resierfs developer's/maintainer's > * xfs snapshot I would have to tell the xfs developer's/maintainer's Probably - you have to see where the oops is happening, but generally it will be the filesystem that is having problems with the I/O error. It may be in some cases that the oops is "on purpose" because it is catching some situation that was never expected to happen, and it is safer to "blow up" than to write garbage onto the disk, and potentially corrupt data there. > All I'm trying to do here is understand this a little more so that I can > follow up with the correct people about these problems. Note that you also need to send "real" oops messages for them to be useful to the developers, so they can find exactly what is going wrong. Cheers, Andreas -- Andreas Dilger http://sourceforge.net/projects/ext2resize/ http://www-mddsp.enel.ucalgary.ca/People/adilger/ From owner-linux-xfs@oss.sgi.com Thu Jan 3 10:00:51 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g03I0pU23560 for linux-xfs-outgoing; Thu, 3 Jan 2002 10:00:51 -0800 Received: from lynx.adilger.int (h24-64-71-161.cg.shawcable.net [24.64.71.161]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g03I0gg23538 for ; Thu, 3 Jan 2002 10:00:42 -0800 Received: (from adilger@localhost) by lynx.adilger.int (8.11.2/8.11.2) id g03H0UH10642; Thu, 3 Jan 2002 10:00:30 -0700 Date: Thu, 3 Jan 2002 10:00:30 -0700 From: Andreas Dilger To: Adrian Head Cc: linux-xfs@oss.sgi.com, linux-lvm@sistina.com Subject: Re: [linux-lvm] Unable to get XFS, ext3, reiserfs & LVM to coexist happily Message-ID: <20020103100030.V12868@lynx.no> Mail-Followup-To: Adrian Head , linux-xfs@oss.sgi.com, linux-lvm@sistina.com References: <20020102110538.K12868@lynx.no> <200201030244.g032iZg32176@oss.sgi.com> <200201030315.UAA21279@cthulhu.turbolabs.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.4i In-Reply-To: <200201030315.UAA21279@cthulhu.turbolabs.com>; from ahead@bigpond.net.au on Thu, Jan 03, 2002 at 01:14:32PM +1000 X-GPG-Key: 1024D/0D35BED6 X-GPG-Fingerprint: 7A37 5D79 BF1B CECA D44F 8A29 A488 39F5 0D35 BED6 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 1919 Lines: 53 On Jan 03, 2002 13:14 +1000, Adrian Head wrote: > With this case ext3 & resierfs are fine for creating snapshots, mounting > snapshots and being stable when snapshots overflow. However, XFS dies during > snapshot creation. > > In this case where do you recommend I take this problem? LVM developers or > XFS developers? Probably XFS. Note that XFS needs some non-standard changes made to the LVM code, so it may be that you are hitting a "known" problem with XFS and snapshots. Hmm, reading further, maybe it is an ext3 problem??? > - From the backtrace it appears that it is ext3 that is actually dying - am I > reading this correctly? In which case does this need to be CC'd to the ext3 > developers as well? Maybe yes. This is very strange. Are you testing all of these filesystems on the same LV in order? Can you try just doing XFS by itself on a clean reboot? I assume that you are rebooting after every oops, because if you don't there is junk in the kernel memory that will screw up further tests. > 2.4.17-xfs > While source volume mounted: > + lvm-1.0.1 upgrade > + VFS-lock > (In that order) > * Can create ext3 snapshot? | yes > * Can mount a ext3 snapshot? | yes > * Can create resierfs snapshot? | yes > * Can mount a resierfs snapshot? | yes > * Can create xfs snapshot? | Oops > btp 1234 (lvcreate) > journal_start > ext3_dirty_inode ^^^^^^^^^^^^^^^^ yes, very strange. > __mark_inode_dirty > update_atime > do_generic_file_read > generic_file_read > sys_read > system_call Note that it appears most of the ext3 fixes went into 2.4.17, so this may be a new bug. As I said, let's try first with XFS snapshots only, and if that doesn't have a problem, try to re-create the above problem and send a full oops report to ext2-devel. Cheers, Andreas -- Andreas Dilger http://sourceforge.net/projects/ext2resize/ http://www-mddsp.enel.ucalgary.ca/People/adilger/ From owner-linux-xfs@oss.sgi.com Thu Jan 3 11:51:07 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g03Jp7l25369 for linux-xfs-outgoing; Thu, 3 Jan 2002 11:51:07 -0800 Received: from monk.verbum.org (postfix@monk.debian.net [216.185.54.61]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g03Jp4g25347 for ; Thu, 3 Jan 2002 11:51:05 -0800 Received: from space-ghost.verbum.private (dhcp065-024-011-149.columbus.rr.com [65.24.11.149]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (Client CN "space-ghost.verbum.org", Issuer CN "monk.verbum.org" (verified OK)) by monk.verbum.org (Postfix (Debian/GNU)) with ESMTP id DF66574004DB for ; Thu, 3 Jan 2002 13:47:03 -0500 (EST) Received: by space-ghost.verbum.private (Postfix (Debian/GNU), from userid 1000) id 9DB16800332; Thu, 3 Jan 2002 13:50:55 -0500 (EST) Subject: Re: file corruption during emacs build on XFS logical volume From: Colin Walters To: linux-xfs@oss.sgi.com In-Reply-To: <6u4rm4r53e.fsf@zork.zork.net> References: <6u4rm4r53e.fsf@zork.zork.net> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/1.0 (Preview Release) Date: 03 Jan 2002 13:50:54 -0500 Message-Id: <1010083854.822.16.camel@space-ghost> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 526 Lines: 12 On Wed, 2002-01-02 at 13:16, Sean Neakums wrote: > I'm getting some random file corruption on one of my XFS LVM volumes, > leading to things like an emacs binary that is filled with runs of > NULs and pieces of deleted files. There was a problem reported with dumping emacs on NFS; it had to do with a bad interaction with mmap(). Are you sure you're not actually building over NFS? As one data point, I'm running a 2.4.16+xfs kernel, and I've been able to build emacs21 on Debian sid just fine (on an XFS file system). From owner-linux-xfs@oss.sgi.com Thu Jan 3 11:55:55 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g03JttW25650 for linux-xfs-outgoing; Thu, 3 Jan 2002 11:55:55 -0800 Received: from zork.zork.net (zork.zork.net [64.81.65.8]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g03Jtqg25628 for ; Thu, 3 Jan 2002 11:55:52 -0800 Received: from localhost (zork.zork.net) [127.0.0.1] by zork.zork.net with esmtp (Exim 3.33 #1 (Debian)) id 16MD1q-0001YO-00; Thu, 03 Jan 2002 10:55:50 -0800 To: Linux XFS Subject: Re: file corruption during emacs build on XFS logical volume References: <6u4rm4r53e.fsf@zork.zork.net> <1010083854.822.16.camel@space-ghost> From: Sean Neakums X-Message-Flag: Message text advisory: SLOTHFUL INDUCTION, ADULT LANGUAGE/SITUATIONS X-Mailer: Norman Mail-Followup-To: Linux XFS Date: Thu, 03 Jan 2002 18:55:50 +0000 In-Reply-To: <1010083854.822.16.camel@space-ghost> (Colin Walters's message of "03 Jan 2002 13:50:54 -0500") Message-ID: <6uy9jfnu15.fsf@zork.zork.net> User-Agent: Gnus/5.090004 (Oort Gnus v0.04) Emacs/21.1 (i386-debian-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 647 Lines: 17 begin Colin Walters quotation: > On Wed, 2002-01-02 at 13:16, Sean Neakums wrote: >> I'm getting some random file corruption on one of my XFS LVM >> volumes, leading to things like an emacs binary that is filled with >> runs of NULs and pieces of deleted files. > > There was a problem reported with dumping emacs on NFS; it had to do > with a bad interaction with mmap(). Are you sure you're not > actually building over NFS? Very sure. -- ///////////////// | | The spark of a pin | (require 'gnu) | dropping, falling feather-like. \\\\\\\\\\\\\\\\\ | | There is too much noise. From owner-linux-xfs@oss.sgi.com Thu Jan 3 12:04:57 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g03K4vI25934 for linux-xfs-outgoing; Thu, 3 Jan 2002 12:04:57 -0800 Received: from hotmail.com (f118.law11.hotmail.com [64.4.17.118]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g03K4tg25912 for ; Thu, 3 Jan 2002 12:04:55 -0800 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Thu, 3 Jan 2002 11:04:48 -0800 Received: from 4.21.59.2 by lw11fd.law11.hotmail.msn.com with HTTP; Thu, 03 Jan 2002 19:04:48 GMT X-Originating-IP: [4.21.59.2] From: "Quang Nguyen (Ngo)" To: linux-xfs@oss.sgi.com Subject: File System Job Date: Thu, 03 Jan 2002 11:04:48 -0800 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 03 Jan 2002 19:04:48.0383 (UTC) FILETIME=[83AF78F0:01C19489] Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 345 Lines: 12 SOFTWARE ENGINEER: 3 to 7 years programming experience, familiar with file system concepts, journaling, file management systems, and snapshot capabilities. Please send resumes to martin@webrew.net. _________________________________________________________________ Chat with friends online, try MSN Messenger: http://messenger.msn.com From owner-linux-xfs@oss.sgi.com Thu Jan 3 12:16:10 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g03KGAZ26326 for linux-xfs-outgoing; Thu, 3 Jan 2002 12:16:10 -0800 Received: from zork.zork.net (zork.zork.net [64.81.65.8]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g03KG3g26297 for ; Thu, 3 Jan 2002 12:16:03 -0800 Received: from localhost (zork.zork.net) [127.0.0.1] by zork.zork.net with esmtp (Exim 3.33 #1 (Debian)) id 16MDLO-0001qP-00; Thu, 03 Jan 2002 11:16:02 -0800 To: Linux XFS Subject: Re: file corruption during emacs build on XFS logical volume References: <6u4rm4r53e.fsf@zork.zork.net> <1009995505.14223.9.camel@jen.americas.sgi.com> <6uy9jgpn2x.fsf@zork.zork.net> <6uu1u4pf48.fsf@zork.zork.net> <1010013019.1281.6.camel@jen.americas.sgi.com> <6upu4spccv.fsf@zork.zork.net> <1010013997.1315.11.camel@jen.americas.sgi.com> <6ulmfgpau5.fsf@zork.zork.net> <6uheq4p9ny.fsf@zork.zork.net> <3C33AF81.AC235AD0@idcomm.com> <6ubsgbq013.fsf@zork.zork.net> <1010069377.23328.15.camel@jen.americas.sgi.com> <1010072382.23328.38.camel@jen.americas.sgi.com> <6u3d1npgx9.fsf@zork.zork.net> <1010075404.12080.79.camel@jen.americas.sgi.com> <1010076426.12080.86.camel@jen.americas.sgi.com> From: Sean Neakums X-Message-Flag: Message text advisory: DRUGS/ALCOHOL, DENIAL OF THE ANTECEDENT X-Mailer: Norman Mail-Followup-To: Linux XFS Date: Thu, 03 Jan 2002 19:16:02 +0000 In-Reply-To: <1010076426.12080.86.camel@jen.americas.sgi.com> (Steve Lord's message of "03 Jan 2002 10:47:06 -0600") Message-ID: <6uu1u3nt3h.fsf@zork.zork.net> User-Agent: Gnus/5.090004 (Oort Gnus v0.04) Emacs/21.1 (i386-debian-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 1886 Lines: 45 begin Steve Lord quotation: > On Thu, 2002-01-03 at 10:30, Steve Lord wrote: >> On Thu, 2002-01-03 at 09:56, Sean Neakums wrote: >> > begin Steve Lord quotation: >> > >> > > Following up to myself, dropping the system memory to 128M seems to >> > > have triggered the problem here, so yes there does seem to be an >> > > XFS bug here. >> > >> > Excellent. I was beginning to think that it was something >> > specific to my setup. >> >> It gets even better, the other difference was that emacs was >> already installed on the box were it worked, if I remove emacs it >> fails to find it and fails in the same manner. So scratch memory >> size as being the trigger here. The box I was building on had emacs installed, showed consistent build failure on XFS and consistent build success on ext2. However... > However, a build of emacs on a box running ext3 filesystems and no > emacs installed fails with exactly the same error. So it would > appear to not be XFS related at all, and more of an emacs build > issue. > > Can you check out a build on another fs on a box which does not have > emacs installed already? You could just rename your emacs binary > rather than deinstall. ...I am building now on an ext2 volume, emacs removed. (The build just passed the dump stage; src/emacs-21.1 is there and src/temacs is not, as the make output indicates should be the case.) Is there any chance that the mmap issue that Colin mentioned could be cropping up on XFS, too? Since the emacs21 build has worked for me on 2.4.14-pre7 on an XFS volume, perhaps there were changes introduced or a fix accidentally reversed during a merge with the Linus tree tha might trigger this. -- ///////////////// | | The spark of a pin | (require 'gnu) | dropping, falling feather-like. \\\\\\\\\\\\\\\\\ | | There is too much noise. From owner-linux-xfs@oss.sgi.com Thu Jan 3 12:53:00 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g03Kr0A26925 for linux-xfs-outgoing; Thu, 3 Jan 2002 12:53:00 -0800 Received: from rj.sgi.com (rj.sgi.com [204.94.215.100]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g03Kqog26903 for ; Thu, 3 Jan 2002 12:52:50 -0800 Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by rj.sgi.com (8.11.4/8.11.4/linux-outbound_gateway-1.1) with ESMTP id g03JqgY10125 for ; Thu, 3 Jan 2002 11:52:43 -0800 Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id NAA3788455; Thu, 3 Jan 2002 13:51:26 -0600 (CST) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id NAA33108; Thu, 3 Jan 2002 13:51:26 -0600 (CST) Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id g03JkID06870; Thu, 3 Jan 2002 13:46:18 -0600 Subject: Re: file corruption during emacs build on XFS logical volume From: Steve Lord To: Sean Neakums Cc: Linux XFS In-Reply-To: <6uu1u3nt3h.fsf@zork.zork.net> References: <6u4rm4r53e.fsf@zork.zork.net> <1009995505.14223.9.camel@jen.americas.sgi.com> <6uy9jgpn2x.fsf@zork.zork.net> <6uu1u4pf48.fsf@zork.zork.net> <1010013019.1281.6.camel@jen.americas.sgi.com> <6upu4spccv.fsf@zork.zork.net> <1010013997.1315.11.camel@jen.americas.sgi.com> <6ulmfgpau5.fsf@zork.zork.net> <6uheq4p9ny.fsf@zork.zork.net> <3C33AF81.AC235AD0@idcomm.com> <6ubsgbq013.fsf@zork.zork.net> <1010069377.23328.15.camel@jen.americas.sgi.com> <1010072382.23328.38.camel@jen.americas.sgi.com> <6u3d1npgx9.fsf@zork.zork.net> <1010075404.12080.79.camel@jen.americas.sgi.com> <1010076426.12080.86.camel@jen.americas.sgi.com> <6uu1u3nt3h.fsf@zork.zork.net> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/1.0.0.99+cvs.2001.12.18.08.57 (Preview Release) Date: 03 Jan 2002 13:46:17 -0600 Message-Id: <1010087177.12080.104.camel@jen.americas.sgi.com> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 3624 Lines: 87 On Thu, 2002-01-03 at 13:16, Sean Neakums wrote: > begin Steve Lord quotation: > > > On Thu, 2002-01-03 at 10:30, Steve Lord wrote: > >> On Thu, 2002-01-03 at 09:56, Sean Neakums wrote: > >> > begin Steve Lord quotation: > >> > > >> > > Following up to myself, dropping the system memory to 128M seems to > >> > > have triggered the problem here, so yes there does seem to be an > >> > > XFS bug here. > >> > > >> > Excellent. I was beginning to think that it was something > >> > specific to my setup. > >> > >> It gets even better, the other difference was that emacs was > >> already installed on the box were it worked, if I remove emacs it > >> fails to find it and fails in the same manner. So scratch memory > >> size as being the trigger here. > > The box I was building on had emacs installed, showed consistent build > failure on XFS and consistent build success on ext2. However... For me it was consistent success with emacs installed, consistent failure with emacs removed. This was independent of filesystem type, ext3 failed in exactly the same manner as xfs. The failure looked like this: + make cd lisp && make EMACS="emacs" lispdir="/var/tmp/emacs-20.7-root/usr/share/emacs/site-lisp" all make[1]: Entering directory `/usr/src/redhat/BUILD/emacs-20.7/gnus-5.8.8/lisp' rm -f *.elc W3DIR=no lispdir=/var/tmp/emacs-20.7-root/usr/share/emacs/site-lisp srcdir=. emacs -batch -q -no-site-file -l ./dgnushack.el -f dgnushack-compile /bin/sh: emacs: command not found make[1]: *** [all] Error 127 make[1]: Leaving directory `/usr/src/redhat/BUILD/emacs-20.7/gnus-5.8.8/lisp' make: *** [lick] Error 2 error: Bad exit status from /var/tmp/rpm-tmp.26560 (%install) And this is on a machine which build emacs correctly when an emacs package was installed. > > > However, a build of emacs on a box running ext3 filesystems and no > > emacs installed fails with exactly the same error. So it would > > appear to not be XFS related at all, and more of an emacs build > > issue. > > > > Can you check out a build on another fs on a box which does not have > > emacs installed already? You could just rename your emacs binary > > rather than deinstall. > > ...I am building now on an ext2 volume, emacs removed. > > (The build just passed the dump stage; src/emacs-21.1 is there and > src/temacs is not, as the make output indicates should be the case.) > > Is there any chance that the mmap issue that Colin mentioned could be > cropping up on XFS, too? Since the emacs21 build has worked for me on > 2.4.14-pre7 on an XFS volume, perhaps there were changes introduced or > a fix accidentally reversed during a merge with the Linus tree tha > might trigger this. If you look at the failure output, are you getting a message saying the command emacs was not found? A few lines up in the output it is setting the path: PATH=/var/tmp/emacs-20.7-root/usr/bin:/usr/local/bin:/bin:/usr/bin:/usr/X11R6/bin:/home/tulip15/lord/bin:/usr/local/bin/ptools:/sbin:/usr/sbin:. this is the path on my machine, the first of those directories has an emacs binary in it. I do not know why it does not find it though, and as I said, for me, it does not matter which fs type I am using, if I have emacs packages installed it finds the binary and works. Steve > > -- > ///////////////// | | The spark of a pin > | (require 'gnu) | dropping, falling feather-like. > \\\\\\\\\\\\\\\\\ | | There is too much noise. -- Steve Lord voice: +1-651-683-3511 Principal Engineer, Filesystem Software email: lord@sgi.com From owner-linux-xfs@oss.sgi.com Thu Jan 3 13:04:53 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g03L4rA27449 for linux-xfs-outgoing; Thu, 3 Jan 2002 13:04:53 -0800 Received: from zork.zork.net (zork.zork.net [64.81.65.8]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g03L4gg27427 for ; Thu, 3 Jan 2002 13:04:42 -0800 Received: from localhost (zork.zork.net) [127.0.0.1] by zork.zork.net with esmtp (Exim 3.33 #1 (Debian)) id 16ME6S-0002Ph-00; Thu, 03 Jan 2002 12:04:40 -0800 To: Linux XFS Subject: Re: file corruption during emacs build on XFS logical volume References: <6u4rm4r53e.fsf@zork.zork.net> <1009995505.14223.9.camel@jen.americas.sgi.com> <6uy9jgpn2x.fsf@zork.zork.net> <6uu1u4pf48.fsf@zork.zork.net> <1010013019.1281.6.camel@jen.americas.sgi.com> <6upu4spccv.fsf@zork.zork.net> <1010013997.1315.11.camel@jen.americas.sgi.com> <6ulmfgpau5.fsf@zork.zork.net> <6uheq4p9ny.fsf@zork.zork.net> <3C33AF81.AC235AD0@idcomm.com> <6ubsgbq013.fsf@zork.zork.net> <1010069377.23328.15.camel@jen.americas.sgi.com> <1010072382.23328.38.camel@jen.americas.sgi.com> <6u3d1npgx9.fsf@zork.zork.net> <1010075404.12080.79.camel@jen.americas.sgi.com> <1010076426.12080.86.camel@jen.americas.sgi.com> <6uu1u3nt3h.fsf@zork.zork.net> <1010087177.12080.104.camel@jen.americas.sgi.com> From: Sean Neakums X-Message-Flag: Message text advisory: STYLE OVER SUBSTANCE, RANTING X-Mailer: Norman Mail-Followup-To: Linux XFS Date: Thu, 03 Jan 2002 20:04:40 +0000 In-Reply-To: <1010087177.12080.104.camel@jen.americas.sgi.com> (Steve Lord's message of "03 Jan 2002 13:46:17 -0600") Message-ID: <6upu4rnquf.fsf@zork.zork.net> User-Agent: Gnus/5.090004 (Oort Gnus v0.04) Emacs/21.1 (i386-debian-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 3966 Lines: 85 begin Steve Lord quotation: > On Thu, 2002-01-03 at 13:16, Sean Neakums wrote: >> The box I was building on had emacs installed, showed consistent >> build failure on XFS and consistent build success on ext2. >> However... > > For me it was consistent success with emacs installed, consistent > failure with emacs removed. This was independent of filesystem type, > ext3 failed in exactly the same manner as xfs. > > The failure looked like this: > > + make > cd lisp && make EMACS="emacs" lispdir="/var/tmp/emacs-20.7-root/usr/share/emacs/site-lisp" all > make[1]: Entering directory `/usr/src/redhat/BUILD/emacs-20.7/gnus-5.8.8/lisp' > rm -f *.elc > W3DIR=no lispdir=/var/tmp/emacs-20.7-root/usr/share/emacs/site-lisp srcdir=. emacs -batch -q -no-site-file -l ./dgnushack.el -f dgnushack-compile > /bin/sh: emacs: command not found > make[1]: *** [all] Error 127 > make[1]: Leaving directory `/usr/src/redhat/BUILD/emacs-20.7/gnus-5.8.8/lisp' > make: *** [lick] Error 2 > error: Bad exit status from /var/tmp/rpm-tmp.26560 (%install) > > And this is on a machine which build emacs correctly when an emacs > package was installed. > >> >> > However, a build of emacs on a box running ext3 filesystems and no >> > emacs installed fails with exactly the same error. So it would >> > appear to not be XFS related at all, and more of an emacs build >> > issue. >> > >> > Can you check out a build on another fs on a box which does not have >> > emacs installed already? You could just rename your emacs binary >> > rather than deinstall. >> >> ...I am building now on an ext2 volume, emacs removed. >> >> (The build just passed the dump stage; src/emacs-21.1 is there and >> src/temacs is not, as the make output indicates should be the case.) >> >> Is there any chance that the mmap issue that Colin mentioned could >> be cropping up on XFS, too? Since the emacs21 build has worked for >> me on 2.4.14-pre7 on an XFS volume, perhaps there were changes >> introduced or a fix accidentally reversed during a merge with the >> Linus tree tha might trigger this. > > If you look at the failure output, are you getting a message saying > the command emacs was not found? A few lines up in the output it is > setting the path: > > PATH=/var/tmp/emacs-20.7-root/usr/bin:/usr/local/bin:/bin:/usr/bin:/usr/X11R6/bin:/home/tulip15/lord/bin:/usr/local/bin/ptools:/sbin:/usr/sbin:. > > this is the path on my machine, the first of those directories has > an emacs binary in it. I do not know why it does not find it though, > and as I said, for me, it does not matter which fs type I am using, > if I have emacs packages installed it finds the binary and works. I just successfully completed a build on ext2. I then did another build on xfs, which failed in the same manner as previously: make[2]: *** No rule to make target `/home/sneakums/src/emacs/emacs21-21.1/src/../lisp/widget.elc', needed by `../etc/DOC'. Stop. make[2]: Leaving directory `/home/sneakums/src/emacs/emacs21-21.1/src' make[1]: *** [src] Error 2 make[1]: Leaving directory `/home/sneakums/src/emacs/emacs21-21.1' make: *** [debian/stamp-build] Error 2 These builds were done with the emacs21 package fully de-installed. My earlier comments about src/emacs-21.1 disappearing were misleading, by the way. The emacs binary is built twice, once to bootstrap the Lisp, and a second time with the full set of features configured. So if the build fals before emacs-21.1. is dumped the second time, as seems to ba happening here, it's not surprisiing surprising that temacs would have "mysteriously" reappeared. You're building emacs 20, though, whose build process may be different from the emacs 21 build process. There's about three years of development between those two releases. -- ///////////////// | | The spark of a pin | (require 'gnu) | dropping, falling feather-like. \\\\\\\\\\\\\\\\\ | | There is too much noise. From owner-linux-xfs@oss.sgi.com Thu Jan 3 13:23:00 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g03LN0h27841 for linux-xfs-outgoing; Thu, 3 Jan 2002 13:23:00 -0800 Received: from sgi.com (sgi-too.SGI.COM [204.94.211.39]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g03LMqg27807 for ; Thu, 3 Jan 2002 13:22:53 -0800 Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id MAA07855 for ; Thu, 3 Jan 2002 12:21:51 -0800 (PST) mail_from (lord@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id OAA3994340; Thu, 3 Jan 2002 14:21:33 -0600 (CST) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id OAA34772; Thu, 3 Jan 2002 14:21:33 -0600 (CST) Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id g03KGOL18560; Thu, 3 Jan 2002 14:16:24 -0600 Subject: Re: file corruption during emacs build on XFS logical volume From: Steve Lord To: Sean Neakums Cc: Linux XFS In-Reply-To: <6upu4rnquf.fsf@zork.zork.net> References: <6u4rm4r53e.fsf@zork.zork.net> <1009995505.14223.9.camel@jen.americas.sgi.com> <6uy9jgpn2x.fsf@zork.zork.net> <6uu1u4pf48.fsf@zork.zork.net> <1010013019.1281.6.camel@jen.americas.sgi.com> <6upu4spccv.fsf@zork.zork.net> <1010013997.1315.11.camel@jen.americas.sgi.com> <6ulmfgpau5.fsf@zork.zork.net> <6uheq4p9ny.fsf@zork.zork.net> <3C33AF81.AC235AD0@idcomm.com> <6ubsgbq013.fsf@zork.zork.net> <1010069377.23328.15.camel@jen.americas.sgi.com> <1010072382.23328.38.camel@jen.americas.sgi.com> <6u3d1npgx9.fsf@zork.zork.net> <1010075404.12080.79.camel@jen.americas.sgi.com> <1010076426.12080.86.camel@jen.americas.sgi.com> <6uu1u3nt3h.fsf@zork.zork.net> <1010087177.12080.104.camel@jen.americas.sgi.com> <6upu4rnquf.fsf@zork.zork.net> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/1.0.0.99+cvs.2001.12.18.08.57 (Preview Release) Date: 03 Jan 2002 14:16:24 -0600 Message-Id: <1010088984.23328.115.camel@jen.americas.sgi.com> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 463 Lines: 17 On Thu, 2002-01-03 at 14:04, Sean Neakums wrote: > You're building emacs 20, though, whose build process may be different > from the emacs 21 build process. There's about three years of > development between those two releases. > Yes, I will go back to emacs 21 again, I might be chasing different things. Steve -- Steve Lord voice: +1-651-683-3511 Principal Engineer, Filesystem Software email: lord@sgi.com From owner-linux-xfs@oss.sgi.com Thu Jan 3 14:46:25 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g03MkP630230 for linux-xfs-outgoing; Thu, 3 Jan 2002 14:46:25 -0800 Received: from sgi.com (sgi-too.SGI.COM [204.94.211.39]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g03MkKg30205 for ; Thu, 3 Jan 2002 14:46:20 -0800 Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id NAA00142 for ; Thu, 3 Jan 2002 13:45:18 -0800 (PST) mail_from (eric@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id PAA3999561 for ; Thu, 3 Jan 2002 15:45:02 -0600 (CST) Received: from stout.americas.sgi.com (stout.americas.sgi.com [128.162.187.5]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id PAA39661 for ; Thu, 3 Jan 2002 15:45:02 -0600 (CST) Received: by stout.americas.sgi.com (8.11.6/SGI-client-1.7) id g03Lj2B18813; Thu, 3 Jan 2002 15:45:02 -0600 Message-Id: <200201032145.g03Lj2B18813@stout.americas.sgi.com> Date: Thu, 3 Jan 2002 15:45:02 -0600 From: Eric Sandeen Subject: TAKE - force even number of 512-byte blocks when data/log/rt fills partition Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 1100 Lines: 29 Although linux allows disk addressing in 512-byte chunks, it only tracks device SIZE in 1024-byte increments. Thus, if we try to access the last, odd, 512-byte block on a partition, linux will tell us we're past the end of the disk even if we're not, since it rounds down to the nearest multiple of 1024 bytes. This will only matter when: multiple blocksizes get implemented, 512-byte blocks are selected, the filesystem fills the partition, and the partition size is not a 1024-byte multiple. This is not currently a problem, since mkfs rounds the size down to a multiple of the filesystem blocksize, which is currently 4096 on x86. This results in a nice 1024 multiple as well. So this is just planning ahead: force even number of 512-byte blocks when data/log/rt fills partition Date: Thu Jan 3 13:39:35 PST 2002 Workarea: stout.americas.sgi.com:/localhome/eric/2.4.x-xfs/workarea-reallyclean The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: xfs-cmds:slinx:109087a cmd/xfsprogs/mkfs/xfs_mkfs.c - 1.19 cmd/xfsprogs/growfs/xfs_growfs.c - 1.8 From owner-linux-xfs@oss.sgi.com Thu Jan 3 15:25:07 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g03NP7k04642 for linux-xfs-outgoing; Thu, 3 Jan 2002 15:25:07 -0800 Received: from UberGeek.coremetrics.com ([209.184.141.163]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g03NOwg04615 for ; Thu, 3 Jan 2002 15:24:58 -0800 Received: (from austin@localhost) by UberGeek.coremetrics.com (8.11.6/8.11.6) id g03MOAV32149; Thu, 3 Jan 2002 16:24:10 -0600 X-Authentication-Warning: UberGeek.coremetrics.com: austin set sender to austin@coremetrics.com using -f Subject: Re: file corruption during emacs build on XFS logical volume From: Austin Gonyou To: Steve Lord Cc: Sean Neakums , Linux XFS In-Reply-To: <1010088984.23328.115.camel@jen.americas.sgi.com> References: <1010088984.23328.115.camel@jen.americas.sgi.com> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-+hUPwLysP7BSKeX9W99f" X-Mailer: Evolution/1.0.0.99+cvs.2001.12.18.08.57 (Preview Release) Date: 03 Jan 2002 16:24:10 -0600 Message-Id: <1010096650.32126.2.camel@UberGeek> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 1741 Lines: 58 --=-+hUPwLysP7BSKeX9W99f Content-Type: text/plain Content-Transfer-Encoding: quoted-printable To throw some fat on the fire here, I've build emacs 21.1 several times on xfs only systems without failure. (as well as anything else under the sun.)=20 Currently I'm building an XFS based distribution for use locally, and I've build glibc 2.2.4(and cvs) + emacs 21.1 + kernels etc. No issues ever. I've had LVM in my kernel and NOT in my kernel. I've not ever had an issue like this. I've built all these things on SCSI and IDE. With HW Raid and without. No failures as yet.=20 On Thu, 2002-01-03 at 14:16, Steve Lord wrote: > On Thu, 2002-01-03 at 14:04, Sean Neakums wrote: >=20 > > You're building emacs 20, though, whose build process may be different > > from the emacs 21 build process. There's about three years of > > development between those two releases. > >=20 >=20 > Yes, I will go back to emacs 21 again, I might be chasing different > things. >=20 > Steve >=20 > --=20 >=20 > Steve Lord voice: +1-651-683-3511 > Principal Engineer, Filesystem Software email: lord@sgi.com --=20 Austin Gonyou Systems Architect, CCNA Coremetrics, Inc. Phone: 512-698-7250 email: austin@coremetrics.com "It is the part of a good shepherd to shear his flock, not to skin it." Latin Proverb --=-+hUPwLysP7BSKeX9W99f Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQA8NNoK94g6ZVmFMoIRAj87AKDGC755ZlrGxkkaxIK1FzjtpwXSdwCgsvUm FBqXVM7ZS/u3nQyElwas3hg= =OozI -----END PGP SIGNATURE----- --=-+hUPwLysP7BSKeX9W99f-- From owner-linux-xfs@oss.sgi.com Thu Jan 3 15:33:03 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g03NX3A05201 for linux-xfs-outgoing; Thu, 3 Jan 2002 15:33:03 -0800 Received: from deliverator.sgi.com (deliverator.sgi.com [204.94.214.10]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g03NWpg05178 for ; Thu, 3 Jan 2002 15:32:52 -0800 Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id OAA04710 for ; Thu, 3 Jan 2002 14:32:33 -0800 (PST) mail_from (lord@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id QAA3997023; Thu, 3 Jan 2002 16:31:32 -0600 (CST) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id QAA44965; Thu, 3 Jan 2002 16:31:32 -0600 (CST) Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id g03MVV009833; Thu, 3 Jan 2002 16:31:31 -0600 Subject: Re: file corruption during emacs build on XFS logical volume From: Steve Lord To: Steve Lord Cc: Sean Neakums , Linux XFS In-Reply-To: <1010088984.23328.115.camel@jen.americas.sgi.com> References: <6u4rm4r53e.fsf@zork.zork.net> <1009995505.14223.9.camel@jen.americas.sgi.com> <6uy9jgpn2x.fsf@zork.zork.net> <6uu1u4pf48.fsf@zork.zork.net> <1010013019.1281.6.camel@jen.americas.sgi.com> <6upu4spccv.fsf@zork.zork.net> <1010013997.1315.11.camel@jen.americas.sgi.com> <6ulmfgpau5.fsf@zork.zork.net> <6uheq4p9ny.fsf@zork.zork.net> <3C33AF81.AC235AD0@idcomm.com> <6ubsgbq013.fsf@zork.zork.net> <1010069377.23328.15.camel@jen.americas.sgi.com> <1010072382.23328.38.camel@jen.americas.sgi.com> <6u3d1npgx9.fsf@zork.zork.net> <1010075404.12080.79.camel@jen.americas.sgi.com> <1010076426.12080.86.camel@jen.americas.sgi.com> <6uu1u3nt3h.fsf@zork.zork.net> <1010087177.12080.104.camel@jen.americas.sgi.com> <6upu4rnquf.fsf@zork.zork.net> <1010088984.23328.115.camel@jen.americas.sgi.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/1.0.0.99+cvs.2001.12.18.08.57 (Preview Release) Date: 03 Jan 2002 16:31:31 -0600 Message-Id: <1010097091.23328.117.camel@jen.americas.sgi.com> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 618 Lines: 22 On Thu, 2002-01-03 at 14:16, Steve Lord wrote: > On Thu, 2002-01-03 at 14:04, Sean Neakums wrote: > > > You're building emacs 20, though, whose build process may be different > > from the emacs 21 build process. There's about three years of > > development between those two releases. > > > > Yes, I will go back to emacs 21 again, I might be chasing different > things. OK, I was chasing different things, but emacs 21 is building OK for me on xfs and ext3. Steve -- Steve Lord voice: +1-651-683-3511 Principal Engineer, Filesystem Software email: lord@sgi.com From owner-linux-xfs@oss.sgi.com Thu Jan 3 15:37:12 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g03NbCD05362 for linux-xfs-outgoing; Thu, 3 Jan 2002 15:37:12 -0800 Received: from zork.zork.net (zork.zork.net [64.81.65.8]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g03Nb9g05339 for ; Thu, 3 Jan 2002 15:37:09 -0800 Received: from localhost (zork.zork.net) [127.0.0.1] by zork.zork.net with esmtp (Exim 3.33 #1 (Debian)) id 16MGTz-0004QM-00; Thu, 03 Jan 2002 14:37:07 -0800 To: Linux XFS Subject: Re: file corruption during emacs build on XFS logical volume References: <6u4rm4r53e.fsf@zork.zork.net> <1009995505.14223.9.camel@jen.americas.sgi.com> <6uy9jgpn2x.fsf@zork.zork.net> <6uu1u4pf48.fsf@zork.zork.net> <1010013019.1281.6.camel@jen.americas.sgi.com> <6upu4spccv.fsf@zork.zork.net> <1010013997.1315.11.camel@jen.americas.sgi.com> <6ulmfgpau5.fsf@zork.zork.net> <6uheq4p9ny.fsf@zork.zork.net> <3C33AF81.AC235AD0@idcomm.com> <6ubsgbq013.fsf@zork.zork.net> <1010069377.23328.15.camel@jen.americas.sgi.com> <1010072382.23328.38.camel@jen.americas.sgi.com> <6u3d1npgx9.fsf@zork.zork.net> <1010075404.12080.79.camel@jen.americas.sgi.com> <1010076426.12080.86.camel@jen.americas.sgi.com> <6uu1u3nt3h.fsf@zork.zork.net> <1010087177.12080.104.camel@jen.americas.sgi.com> <6upu4rnquf.fsf@zork.zork.net> <1010088984.23328.115.camel@jen.americas.sgi.com> <1010097091.23328.117.camel@jen.americas.sgi.com> From: Sean Neakums X-Message-Flag: Message text advisory: AMPHIBOLY, ADULT LANGUAGE/SITUATIONS X-Mailer: Norman Mail-Followup-To: Linux XFS Date: Thu, 03 Jan 2002 22:37:07 +0000 In-Reply-To: <1010097091.23328.117.camel@jen.americas.sgi.com> (Steve Lord's message of "03 Jan 2002 16:31:31 -0600") Message-ID: <6u3d1nnjsc.fsf@zork.zork.net> User-Agent: Gnus/5.090004 (Oort Gnus v0.04) Emacs/21.1 (i386-debian-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 846 Lines: 21 begin Steve Lord quotation: > On Thu, 2002-01-03 at 14:16, Steve Lord wrote: >> On Thu, 2002-01-03 at 14:04, Sean Neakums wrote: >> > You're building emacs 20, though, whose build process may be >> > different from the emacs 21 build process. There's about three >> > years of development between those two releases. >> >> Yes, I will go back to emacs 21 again, I might be chasing different >> things. > > OK, I was chasing different things, but emacs 21 is building OK for > me on xfs and ext3. This is very weird. I find it hard to believe that there's something about Debian's packaging that causes the build to fail on XFS *only*. -- ///////////////// | | The spark of a pin | (require 'gnu) | dropping, falling feather-like. \\\\\\\\\\\\\\\\\ | | There is too much noise. From owner-linux-xfs@oss.sgi.com Thu Jan 3 15:55:15 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g03NtFO05822 for linux-xfs-outgoing; Thu, 3 Jan 2002 15:55:15 -0800 Received: from zork.zork.net (zork.zork.net [64.81.65.8]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g03NtBg05800 for ; Thu, 3 Jan 2002 15:55:11 -0800 Received: from localhost (zork.zork.net) [127.0.0.1] by zork.zork.net with esmtp (Exim 3.33 #1 (Debian)) id 16MGlR-0004ka-00; Thu, 03 Jan 2002 14:55:09 -0800 To: Linux XFS Subject: Re: file corruption during emacs build on XFS logical volume References: <6u4rm4r53e.fsf@zork.zork.net> <6uy9jgpn2x.fsf@zork.zork.net> <6uu1u4pf48.fsf@zork.zork.net> <1010013019.1281.6.camel@jen.americas.sgi.com> <6upu4spccv.fsf@zork.zork.net> <1010013997.1315.11.camel@jen.americas.sgi.com> <6ulmfgpau5.fsf@zork.zork.net> <6uheq4p9ny.fsf@zork.zork.net> <3C33AF81.AC235AD0@idcomm.com> <6ubsgbq013.fsf@zork.zork.net> <1010069377.23328.15.camel@jen.americas.sgi.com> <1010072382.23328.38.camel@jen.americas.sgi.com> <6u3d1npgx9.fsf@zork.zork.net> <1010075404.12080.79.camel@jen.americas.sgi.com> <1010076426.12080.86.camel@jen.americas.sgi.com> <6uu1u3nt3h.fsf@zork.zork.net> <1010087177.12080.104.camel@jen.americas.sgi.com> <6upu4rnquf.fsf@zork.zork.net> <1010088984.23328.115.camel@jen.americas.sgi.com> <1010097091.23328.117.camel@jen.americas.sgi.com> <6u3d1nnjsc.fsf@zork.zork.net> From: Sean Neakums X-Message-Flag: Message text advisory: EXCRETORY SPEECH, PROMOTION OF SELF X-Mailer: Norman Mail-Followup-To: Linux XFS Date: Thu, 03 Jan 2002 22:55:09 +0000 In-Reply-To: <6u3d1nnjsc.fsf@zork.zork.net> (Sean Neakums's message of "Thu, 03 Jan 2002 22:37:07 +0000") Message-ID: <6uwuyzm4du.fsf@zork.zork.net> User-Agent: Gnus/5.090004 (Oort Gnus v0.04) Emacs/21.1 (i386-debian-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 1079 Lines: 26 begin Sean Neakums quotation: > begin Steve Lord quotation: > >> On Thu, 2002-01-03 at 14:16, Steve Lord wrote: >>> On Thu, 2002-01-03 at 14:04, Sean Neakums wrote: >>> > You're building emacs 20, though, whose build process may be >>> > different from the emacs 21 build process. There's about three >>> > years of development between those two releases. >>> Yes, I will go back to emacs 21 again, I might be chasing different >>> things. >> OK, I was chasing different things, but emacs 21 is building OK for >> me on xfs and ext3. > > This is very weird. I find it hard to believe that there's > something about Debian's packaging that causes the build to fail on > XFS *only*. Taking a cue from Sherlock Holmes, I've just kicked off a build of the vanilla upstream source, to see if this is being triggered by something in the way Debian's package does its build. -- ///////////////// | | The spark of a pin | (require 'gnu) | dropping, falling feather-like. \\\\\\\\\\\\\\\\\ | | There is too much noise. From owner-linux-xfs@oss.sgi.com Thu Jan 3 16:10:23 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g040ANc06175 for linux-xfs-outgoing; Thu, 3 Jan 2002 16:10:23 -0800 Received: from zork.zork.net (zork.zork.net [64.81.65.8]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g040AJg06153 for ; Thu, 3 Jan 2002 16:10:19 -0800 Received: from localhost (zork.zork.net) [127.0.0.1] by zork.zork.net with esmtp (Exim 3.33 #1 (Debian)) id 16MH05-00056Y-00; Thu, 03 Jan 2002 15:10:17 -0800 To: Linux XFS Subject: Re: file corruption during emacs build on XFS logical volume References: <6u4rm4r53e.fsf@zork.zork.net> <6uu1u4pf48.fsf@zork.zork.net> <1010013019.1281.6.camel@jen.americas.sgi.com> <6upu4spccv.fsf@zork.zork.net> <1010013997.1315.11.camel@jen.americas.sgi.com> <6ulmfgpau5.fsf@zork.zork.net> <6uheq4p9ny.fsf@zork.zork.net> <3C33AF81.AC235AD0@idcomm.com> <6ubsgbq013.fsf@zork.zork.net> <1010069377.23328.15.camel@jen.americas.sgi.com> <1010072382.23328.38.camel@jen.americas.sgi.com> <6u3d1npgx9.fsf@zork.zork.net> <1010075404.12080.79.camel@jen.americas.sgi.com> <1010076426.12080.86.camel@jen.americas.sgi.com> <6uu1u3nt3h.fsf@zork.zork.net> <1010087177.12080.104.camel@jen.americas.sgi.com> <6upu4rnquf.fsf@zork.zork.net> <1010088984.23328.115.camel@jen.americas.sgi.com> <1010097091.23328.117.camel@jen.americas.sgi.com> <6u3d1nnjsc.fsf@zork.zork.net> <6uwuyzm4du.fsf@zork.zork.net> From: Sean Neakums X-Message-Flag: Message text advisory: MISMATCHED PARENTHESES, IGNORATIO ELENCHI X-Mailer: Norman Mail-Followup-To: Linux XFS Date: Thu, 03 Jan 2002 23:10:17 +0000 In-Reply-To: <6uwuyzm4du.fsf@zork.zork.net> (Sean Neakums's message of "Thu, 03 Jan 2002 22:55:09 +0000") Message-ID: <6usn9nm3om.fsf@zork.zork.net> User-Agent: Gnus/5.090004 (Oort Gnus v0.04) Emacs/21.1 (i386-debian-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 1025 Lines: 24 begin Sean Neakums quotation: > begin Sean Neakums quotation: >> begin Steve Lord quotation: >>> OK, I was chasing different things, but emacs 21 is building OK for >>> me on xfs and ext3. >> This is very weird. I find it hard to believe that there's >> something about Debian's packaging that causes the build to fail on >> XFS *only*. > > Taking a cue from Sherlock Holmes, I've just kicked off a build of the > vanilla upstream source, to see if this is being triggered by > something in the way Debian's package does its build. The upstream build went perfectly, with the same configure options as the Debian package uses. I'm composing a message to the maintainer, to see if he can tell me what's failing in the package build and why, and what is different about the way the build is handled in the package. -- ///////////////// | | The spark of a pin | (require 'gnu) | dropping, falling feather-like. \\\\\\\\\\\\\\\\\ | | There is too much noise. From owner-linux-xfs@oss.sgi.com Thu Jan 3 16:42:45 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g040gjt06852 for linux-xfs-outgoing; Thu, 3 Jan 2002 16:42:45 -0800 Received: from server-23.tower-15.messagelabs.com (mail15.messagelabs.com [63.210.62.243]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g040geg06827 for ; Thu, 3 Jan 2002 16:42:40 -0800 X-VirusChecked: Checked Received: (qmail 14583 invoked from network); 3 Jan 2002 23:32:24 -0000 Received: from mail.tapeware.com (HELO yt-internet.tapeware.com) (4.21.59.10) by server-23.tower-15.messagelabs.com with SMTP; 3 Jan 2002 23:32:24 -0000 Received: by mail.tapeware.com with Internet Mail Service (5.5.2653.19) id ; Thu, 3 Jan 2002 15:42:14 -0800 Message-ID: From: "Quang Nguyen (Ngo)" To: "'linux-xfs@oss.sgi.com'" Subject: Disk Geometry/Partition API Date: Thu, 3 Jan 2002 15:42:09 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Disposition: inline Content-Type: text/plain Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 1023 Lines: 23 I'm writing a backup utility, which hopefully will handle full disaster recovery in case of a disk failure. I want it to backup not only the data, ACL, etc, but also disk geometry and partition information. This information will be used during the recovery procedure to recreate the partitions the original disk had with an option of resizing, etc... The app is Linux based, but I want it to be aware of other partitions created by a different OS as well. I studied the source code of fdisk and sfdisk, /usr/include/linux/genhd.h hdreg.h so I have some ideas. However, I wondered if there are C functions available that simplify the task. I also need some documents on the ioctl commands specified in hdreg.h. Any hints/tips/ideas would be appreciated. -- Quang This email has been scanned for all viruses by the MessageLabs SkyScan service. For more information on a pro-active anti-virus service working around the clock, around the globe visit http://www.messagelabs.com/ [[HTML alternate version deleted]] From owner-linux-xfs@oss.sgi.com Thu Jan 3 16:45:54 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g040jsG07056 for linux-xfs-outgoing; Thu, 3 Jan 2002 16:45:54 -0800 Received: from zork.zork.net (zork.zork.net [64.81.65.8]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g040jng07031 for ; Thu, 3 Jan 2002 16:45:49 -0800 Received: from localhost (zork.zork.net) [127.0.0.1] by zork.zork.net with esmtp (Exim 3.33 #1 (Debian)) id 16MHYR-0005Vx-00; Thu, 03 Jan 2002 15:45:47 -0800 To: Linux XFS Subject: Re: file corruption during emacs build on XFS logical volume References: <6u4rm4r53e.fsf@zork.zork.net> <1010013019.1281.6.camel@jen.americas.sgi.com> <6upu4spccv.fsf@zork.zork.net> <1010013997.1315.11.camel@jen.americas.sgi.com> <6ulmfgpau5.fsf@zork.zork.net> <6uheq4p9ny.fsf@zork.zork.net> <3C33AF81.AC235AD0@idcomm.com> <6ubsgbq013.fsf@zork.zork.net> <1010069377.23328.15.camel@jen.americas.sgi.com> <1010072382.23328.38.camel@jen.americas.sgi.com> <6u3d1npgx9.fsf@zork.zork.net> <1010075404.12080.79.camel@jen.americas.sgi.com> <1010076426.12080.86.camel@jen.americas.sgi.com> <6uu1u3nt3h.fsf@zork.zork.net> <1010087177.12080.104.camel@jen.americas.sgi.com> <6upu4rnquf.fsf@zork.zork.net> <1010088984.23328.115.camel@jen.americas.sgi.com> <1010097091.23328.117.camel@jen.americas.sgi.com> <6u3d1nnjsc.fsf@zork.zork.net> <6uwuyzm4du.fsf@zork.zork.net> <6usn9nm3om.fsf@zork.zork.net> From: Sean Neakums X-Message-Flag: Message text advisory: BRAZEN SELF-DECEIT, PROMOTION OF SELF X-Mailer: Norman Mail-Followup-To: Linux XFS Date: Thu, 03 Jan 2002 23:45:47 +0000 In-Reply-To: <6usn9nm3om.fsf@zork.zork.net> (Sean Neakums's message of "Thu, 03 Jan 2002 23:10:17 +0000") Message-ID: <6un0zvm21g.fsf@zork.zork.net> User-Agent: Gnus/5.090004 (Oort Gnus v0.04) Emacs/21.1 (i386-debian-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 1501 Lines: 33 begin Sean Neakums quotation: > begin Sean Neakums quotation: >> begin Sean Neakums quotation: >>> begin Steve Lord quotation: >>>> OK, I was chasing different things, but emacs 21 is building OK for >>>> me on xfs and ext3. >>> This is very weird. I find it hard to believe that there's >>> something about Debian's packaging that causes the build to fail on >>> XFS *only*. >> Taking a cue from Sherlock Holmes, I've just kicked off a build of >> the vanilla upstream source, to see if this is being triggered by >> something in the way Debian's package does its build. > > The upstream build went perfectly, with the same configure options > as the Debian package uses. I'm composing a message to the > maintainer, to see if he can tell me what's failing in the package > build and why, and what is different about the way the build is > handled in the package. Aargh. In the process of trying to create a log of the failed build to send to the maintainer, instead of getting the errors I've quoted before, I've gotten the error I orignally found: strip failing with a `Memory exhausted' error. I've run strings on the dumped binary, and it's full of chunks of source, and cores immediately on startup. Maybe I should just keep an ext2 partition around for building emacs packages. -- ///////////////// | | The spark of a pin | (require 'gnu) | dropping, falling feather-like. \\\\\\\\\\\\\\\\\ | | There is too much noise. From owner-linux-xfs@oss.sgi.com Thu Jan 3 17:15:15 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g041FFl07799 for linux-xfs-outgoing; Thu, 3 Jan 2002 17:15:15 -0800 Received: from sgi.com (sgi-too.SGI.COM [204.94.211.39]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g041FAg07777 for ; Thu, 3 Jan 2002 17:15:10 -0800 Received: from mailhost.idcomm.com (mailhost.idcomm.com [207.40.196.14]) by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id QAA01549 for ; Thu, 3 Jan 2002 16:14:06 -0800 (PST) mail_from (stimits@idcomm.com) Received: from idcomm.com (IDENT:94QS8/lVgQLkNAihWLkiUrAtNDbp8nrm@k56-pip64.idcomm.com [209.60.72.191]) by mailhost.idcomm.com (8.10.2/8.10.0) with ESMTP id g040AmO08656 for ; Thu, 3 Jan 2002 17:10:48 -0700 Message-ID: <3C34F294.D6D015BC@idcomm.com> Date: Thu, 03 Jan 2002 17:08:52 -0700 From: "D. Stimits" Reply-To: stimits@idcomm.com X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.6-pre1-xfs-4 i686) X-Accept-Language: en MIME-Version: 1.0 CC: Linux XFS Subject: Re: file corruption during emacs build on XFS logical volume References: <6u4rm4r53e.fsf@zork.zork.net> <1009995505.14223.9.camel@jen.americas.sgi.com> <6uy9jgpn2x.fsf@zork.zork.net> <6uu1u4pf48.fsf@zork.zork.net> <1010013019.1281.6.camel@jen.americas.sgi.com> <6upu4spccv.fsf@zork.zork.net> <1010013997.1315.11.camel@jen.americas.sgi.com> <6ulmfgpau5.fsf@zork.zork.net> <6uheq4p9ny.fsf@zork.zork.net> <3C33AF81.AC235AD0@idcomm.com> <6ubsgbq013.fsf@zork.zork.net> <1010069377.23328.15.camel@jen.americas.sgi.com> <1010072382.23328.38.camel@jen.americas.sgi.com> <6u3d1npgx9.fsf@zork.zork.net> <1010075404.12080.79.camel@jen.americas.sgi.com> <1010076426.12080.86.camel@jen.americas.sgi.com> <6uu1u3nt3h.fsf@zork.zork.net> <1010087177.12080.104.camel@jen.americas.sgi.com> <6upu4rnquf.fsf@zork.zork.net> <1010088984.23328.115.camel@jen.americas.sgi.com> <1010097091.23328.117.camel@jen.americas.sgi.com> <6u3d1nnjsc.fsf@zork.zork.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 1077 Lines: 30 Sean Neakums wrote: > > begin Steve Lord quotation: > > > On Thu, 2002-01-03 at 14:16, Steve Lord wrote: > >> On Thu, 2002-01-03 at 14:04, Sean Neakums wrote: > >> > You're building emacs 20, though, whose build process may be > >> > different from the emacs 21 build process. There's about three > >> > years of development between those two releases. > >> > >> Yes, I will go back to emacs 21 again, I might be chasing different > >> things. > > > > OK, I was chasing different things, but emacs 21 is building OK for > > me on xfs and ext3. > > This is very weird. I find it hard to believe that there's something > about Debian's packaging that causes the build to fail on XFS *only*. Why not find the exact compile line of first failure or first file corruption; then run it by hand under strace and see what it says? D. Stimits, stimits@idcomm.com > > -- > ///////////////// | | The spark of a pin > | (require 'gnu) | dropping, falling feather-like. > \\\\\\\\\\\\\\\\\ | | There is too much noise. From owner-linux-xfs@oss.sgi.com Thu Jan 3 17:16:19 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g041GJt07950 for linux-xfs-outgoing; Thu, 3 Jan 2002 17:16:19 -0800 Received: from mta06ps.bigpond.com (mta06ps.bigpond.com [144.135.25.138]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g041G0g07910 for ; Thu, 3 Jan 2002 17:16:00 -0800 Message-Id: <200201040116.g041G0g07910@oss.sgi.com> Received: from there ([144.135.25.87]) by mta06ps.bigpond.com (Netscape Messaging Server 4.15) with SMTP id GPE12000.BFU; Fri, 4 Jan 2002 10:22:48 +1000 Received: from CPE-144-137-138-230.qld.bigpond.net.au ([144.137.138.230]) by psmam07.mailsvc.email.bigpond.com(MailRouter V3.0h 125/2952500); 04 Jan 2002 10:15:49 Content-Type: text/plain; charset="us-ascii" From: Adrian Head To: Steve Lord , Andreas Dilger Subject: Re: Unable to get XFS, ext3, reiserfs & LVM to coexist happily Date: Fri, 4 Jan 2002 10:15:34 +1000 X-Mailer: KMail [version 1.3.1] Cc: Linux XFS , linux-lvm@sistina.com References: <6u4rm4r53e.fsf@zork.zork.net> <200201031638.g03GcJg20734@oss.sgi.com> <1010072497.12080.42.camel@jen.americas.sgi.com> In-Reply-To: <1010072497.12080.42.camel@jen.americas.sgi.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 7468 Lines: 178 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Fri, 4 Jan 2002 01:41, Steve Lord wrote: > > There are however, may subtle (unhappy) interactions between XFS, LVM and > > other kernel areas when you try to do snapshots for example. > > Yes, I have seen the thread, I have just not had the time to look into > it yet. Your last message said that the xfs snapshot creation was > failing, but with an ext3 stack trace..... > > You also mention out of space problems in the snapshot. > > Can you summarize where your kernel came from - I see you have lots of > stuff in there. Do you still need special lvm patches to turn on > snapshotting support - it has been a while. > > Also, send me a quick rundown of the commands you need to use to setup > a volume for snapshotting - it will save me the research. Thats fine Steve, all I was doing at the time was just saying that running XFS on a straight LVM seems to be very happy as far as I can tell. However, since you have asked the questions I will answer now before I forget about it. ;-) The problem I have encountered is just as strange (ext3 stack trace) as the file corruption during compile problem that you are dealing with now. What I was going to do was fall back to ext2 and remove ext3 from the kernel and rerun the tests. Hopefully by doing this it will shed more light onto the problem. Not sure what you mean by have lots of stuff in the kernel but to summarise where it came from. The recent kernel - the one I did the last series of tests with was from the SGI CVS and was: 2.4.17-xfs 20011226 Previous kernels also from SGI CVS that I have tried were: 2.4.16-xfs 20011218 2.4.16-xfs 20011223 The system is a minimal install of RH7.2 and all compiles have used the default compile flags using the default RH7.2 compiler. gcc version 2.96 20000731 (Re Hat Linux 7.1 2.96-89) A more indepth of the make-up of my system can be found here: from the thread "XFS dying when many processes copy many files/directories" http://marc.theaimsgroup.com/?l=linux-xfs&m=100942550316126&w=2 The only other things added to the kernel are the LVM patches of which there are two that the LVM people recommend. * The LVM-1.0.1 upgrade patch and * The VFS-lock patch (in that order) - From my understanding the LVM-1.0.1 patch is recommended as it has many bugfixes from the LVM-1.0.1rc4(ish) that is currently in the linus & SGI 2.4.17 kernel. Unfortunately I don't have handy a URL to the changlog - sorry. The VFS-lock patch from my understanding is required for creating snapshots on journaling filesystems like ext3, resierfs and maybe XFS. (AFAIK XFS is a special case as you can also use xfs_freeze). The VFS-lock patch locks the VFS layer and forces all filesystems to sync to disk dumping all dirty buffers/pages etc... If this doesn't happen; although you can create a snapshot you will never be able to mount it as the journals of at least ext3 & resierfs will need to be replayed - which cannot happen as the snapshot is read-only. Maybe some of the LVM developers may be able to give you more information than that. There are 3rd party patches to make the snapshot writable but I don't see the advantage for my situation as yet and I'm having enough trouble getting the basics running. Therefore, I have not applied these patches. ;-) Now with regards to the out of space problems I have been referring to: What I was wanting was to not only use LVM snapshots for backups but to also hold a known disk state for a while ie. 24hrs. This has the advantage that I as a sysadmin can snapshot a volume before I start volume maintance and have a backout strategy if I accidently do something I should not have. And I was wanting to have the same concept for staff - if they accidently delete a file off the server they can go to the mounted snapshot and get it back without running to me for the backup. Under normal office operations I can guess how much space the snapshot needs; however, there will always be a time/situation where someone will dump data way in excess of what the snapshot size can handle. Under this situation the snapshot should just be taken offline automatically without killing the system. This is what I was reffering to with overflowing the snapshot. It was the Oops generated when an XFS snapshot overflowed during one of my many pre-production tests that started me on this quest ;-) This was how the HDD was divided up on my test system: ======================================================================= - - - hda1 - /boot 20M ext3 - - - hda2 - / 512M ext3 - - - hda3 - /usr 512M ext3 - - - hda4 - {extended} - - - hda5 - /var 512M ext3 - - - hda6 - swap 768M - - - hda7 - {LVM volume group HDA} 36941M - Remaining Space (36G) - /dev/HDA/TMP /tmp 128M reiserfs - /dev/HDA/CACHE /cache 512M reiserfs - /dev/HDA/CHROOT /chroot 512M ext3 - /dev/HDA/SRC /usr/src 4096M reiserfs - /dev/HDA/SRC_SNAP /usr/src/snapshot/admin 1024M (30G Unallocated) ======================================================================= The test procedure was: 1) Unpack a clean SGI CVS kernel and patch LVM as required. 2) Compile, install and reboot. 3) For a mounted ext3 logical volume a) create a snapshot lvcreate -L50M -s -n SNAP /dev/HDA/CHROOT b) mount the snapshot mount /dev/HDA/SNAP /mnt/snapshot c) copy more than the snapshot size onto the original logical volume to see what happens. cp -fr /usr/src/ /chroot 4) Repeat for resierfs 5) Repeat for XFS Note: becareful when mounting an XFS snaphot without using "mount -t xfs" otherwise i have found it will mount the snapshot as resierfs. See http://marc.theaimsgroup.com/?l=linux-xfs&m=100994490716530&w=2 for more info on this. If there was a Kernel Oops there would be a reboot and recovery inbetween 3, 4 &/or 5. The exact results from the tests can be found here: http://marc.theaimsgroup.com/?l=linux-xfs&m=100994356415003&w=2 A quick summary of commands: To initialise a partition for LVM usage: pvcreate /dev/hda7 To create a volume group (the container for the logical volumes) vgcreate -s32M HDA /dev/hda7 Note: -s32M is optional; default is 4M. To create a logical volume (the volume that will contain the filesystem) lvcreate -L4G -n CHROOT /dev/HDA Then put the filesystem on top: eg: mkfs -t ext2 -j /dev/HDA/CHROOT or mkfs -t xfs /dev/HDA/TEST or mkfs -t resierfs /dev/HDA/SRC Then mount logical volume: eg: mount /dev/HDA/SRC /usr/src A good quick tutorial on LVM can be found here: http://www.sistina.com/lvm_howtos/lvm_howto/ and the basic lvm commands here: http://www.sistina.com/lvm_howtos/lvm_howto/Common_tasks.html I hope this has answered your questions. My next move is to remove ext3 from the kernel and rerun the tests to see what happens. If I have left out anything please contact me. - -- Adrian Head (Public Key available on request.) -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE8NPQs8ZJI8OvSkAcRApMRAJ9qkytpP8RXUHuD2dgFp9CV/sQSJACfeo6F SM6pTcPryGjyHAMn3QIdQ2o= =f+ak -----END PGP SIGNATURE----- From owner-linux-xfs@oss.sgi.com Thu Jan 3 17:24:37 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g041Obq08173 for linux-xfs-outgoing; Thu, 3 Jan 2002 17:24:37 -0800 Received: from zork.zork.net (zork.zork.net [64.81.65.8]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g041OVg08148 for ; Thu, 3 Jan 2002 17:24:31 -0800 Received: from localhost (zork.zork.net) [127.0.0.1] by zork.zork.net with esmtp (Exim 3.33 #1 (Debian)) id 16MI9t-0006Ao-00; Thu, 03 Jan 2002 16:24:29 -0800 To: Linux XFS Subject: Re: file corruption during emacs build on XFS logical volume References: <6u4rm4r53e.fsf@zork.zork.net> <6uu1u4pf48.fsf@zork.zork.net> <1010013019.1281.6.camel@jen.americas.sgi.com> <6upu4spccv.fsf@zork.zork.net> <1010013997.1315.11.camel@jen.americas.sgi.com> <6ulmfgpau5.fsf@zork.zork.net> <6uheq4p9ny.fsf@zork.zork.net> <3C33AF81.AC235AD0@idcomm.com> <6ubsgbq013.fsf@zork.zork.net> <1010069377.23328.15.camel@jen.americas.sgi.com> <1010072382.23328.38.camel@jen.americas.sgi.com> <6u3d1npgx9.fsf@zork.zork.net> <1010075404.12080.79.camel@jen.americas.sgi.com> <1010076426.12080.86.camel@jen.americas.sgi.com> <6uu1u3nt3h.fsf@zork.zork.net> <1010087177.12080.104.camel@jen.americas.sgi.com> <6upu4rnquf.fsf@zork.zork.net> <1010088984.23328.115.camel@jen.americas.sgi.com> <1010097091.23328.117.camel@jen.americas.sgi.com> <6u3d1nnjsc.fsf@zork.zork.net> <3C34F294.D6D015BC@idcomm.com> From: Sean Neakums X-Message-Flag: Message text advisory: PROMOTION OF SELF, HATE SPEECH X-Mailer: Norman Mail-Followup-To: Linux XFS Date: Fri, 04 Jan 2002 00:24:29 +0000 In-Reply-To: <3C34F294.D6D015BC@idcomm.com> ("D. Stimits"'s message of "Thu, 03 Jan 2002 17:08:52 -0700") Message-ID: <6uheq3m08y.fsf@zork.zork.net> User-Agent: Gnus/5.090004 (Oort Gnus v0.04) Emacs/21.1 (i386-debian-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 1404 Lines: 33 begin D. Stimits quotation: > Sean Neakums wrote: >> begin Steve Lord quotation: >> > On Thu, 2002-01-03 at 14:16, Steve Lord wrote: >> >> On Thu, 2002-01-03 at 14:04, Sean Neakums wrote: >> >> > You're building emacs 20, though, whose build process may be >> >> > different from the emacs 21 build process. There's about three >> >> > years of development between those two releases. >> >> >> >> Yes, I will go back to emacs 21 again, I might be chasing different >> >> things. >> > >> > OK, I was chasing different things, but emacs 21 is building OK for >> > me on xfs and ext3. >> >> This is very weird. I find it hard to believe that there's >> something about Debian's packaging that causes the build to fail on >> XFS *only*. > > Why not find the exact compile line of first failure or first file > corruption; then run it by hand under strace and see what it says? After I got that bogus dumped binary, I've done about thirty more dumps, by hand. They all seem to run fine, although I'm getting different md5sums for each of them, even though I'm taking pains to dump each under the same filename. I'm not sure if the dumping process guarantees identical binaries each time or not. -- ///////////////// | | The spark of a pin | (require 'gnu) | dropping, falling feather-like. \\\\\\\\\\\\\\\\\ | | There is too much noise. From owner-linux-xfs@oss.sgi.com Thu Jan 3 17:27:21 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g041RLM08323 for linux-xfs-outgoing; Thu, 3 Jan 2002 17:27:21 -0800 Received: from sgi.com (sgi-too.SGI.COM [204.94.211.39]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g041RIg08301 for ; Thu, 3 Jan 2002 17:27:18 -0800 Received: from peach.ece.utexas.edu (peach.ece.utexas.edu [128.83.51.53]) by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id QAA00655; Thu, 3 Jan 2002 16:26:14 -0800 (PST) mail_from (thecap@peach.ece.utexas.edu) Received: from localhost ([127.0.0.1] helo=peach.ece.utexas.edu) by peach.ece.utexas.edu with esmtp (Exim 3.33 #1 (Debian)) id 16MI2s-0002Ge-00; Thu, 03 Jan 2002 18:17:14 -0600 Content-Type: text/plain; charset="us-ascii" From: Adrian Head To: 5124157602@mobile.att.net X-Mailer: Perl5 Mail::Internet v1.41 Cc: Linux XFS , linux-lvm@sistina.com References: <6u4rm4r53e.fsf@zork.zork.net> <200201031638.g03GcJg20734@oss.sgi.com> <1010072497.12080.42.camel@jen.americas.sgi.com> In-Reply-To: <1010072497.12080.42.camel@jen.americas.sgi.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Message-Id: X-Spam-Status: No, hits=0 required=5 tests= Subject: [linux-lvm] Re: Unable to get XFS, ext3, reiserf & LVM to coexist hply X-Beenthere: linux-lvm@sistina.com X-Mailman-Version: 2.0.6 Reply-To: linux-lvm@sistina.com List-Help: List-Post: List-Subscribe: , List-Id: linux-lvm general discussion List-Unsubscribe: , List-Archive: X-Original-Date: Fri, 4 Jan 2002 10:15:34 +1000 Date: Fri, 4 Jan 2002 10:15:34 +1000 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 184 Lines: 5 -----BEGIN PGP SGN msg On Fri, 4 Jan 2002 01:41, Stev Lrd > > Ther are h/ve, may subtl (unhapy) intercton btwen XFS, LVM and > > otr kernel area when u try to do snapshot f_xmple From owner-linux-xfs@oss.sgi.com Thu Jan 3 17:38:44 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g041ci108600 for linux-xfs-outgoing; Thu, 3 Jan 2002 17:38:44 -0800 Received: from lynx.adilger.int (h24-64-71-161.cg.shawcable.net [24.64.71.161]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g041ceg08578 for ; Thu, 3 Jan 2002 17:38:40 -0800 Received: (from adilger@localhost) by lynx.adilger.int (8.11.2/8.11.2) id g040cJf12355; Thu, 3 Jan 2002 17:38:19 -0700 Date: Thu, 3 Jan 2002 17:38:19 -0700 From: Andreas Dilger To: Adrian Head Cc: Steve Lord , Linux XFS , linux-lvm@sistina.com Subject: Re: Unable to get XFS, ext3, reiserfs & LVM to coexist happily Message-ID: <20020103173819.J12868@lynx.no> Mail-Followup-To: Adrian Head , Steve Lord , Linux XFS , linux-lvm@sistina.com References: <6u4rm4r53e.fsf@zork.zork.net> <200201031638.g03GcJg20734@oss.sgi.com> <1010072497.12080.42.camel@jen.americas.sgi.com> <200201040015.RAA00441@cthulhu.turbolabs.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.4i In-Reply-To: <200201040015.RAA00441@cthulhu.turbolabs.com>; from ahead@bigpond.net.au on Fri, Jan 04, 2002 at 10:15:34AM +1000 X-GPG-Key: 1024D/0D35BED6 X-GPG-Fingerprint: 7A37 5D79 BF1B CECA D44F 8A29 A488 39F5 0D35 BED6 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 1059 Lines: 23 On Jan 04, 2002 10:15 +1000, Adrian Head wrote: > Note: becareful when mounting an XFS snaphot without using "mount -t xfs" > otherwise i have found it will mount the snapshot as resierfs. > See http://marc.theaimsgroup.com/?l=linux-xfs&m=100994490716530&w=2 for more > info on this. This is because the reiserfs superblock is 64kB into the filesystem, and it appears that the mkfs.xfs does not overwrite this part of the disk. I have heard of another person with this same problem. It would probably behoove the XFS folks to zero the first and last 128kB of a partition when doing mkfs.xfs to avoid this sort of problem. For mkfs.ext2, it will zero the first 4kB, overwrite the next tens of kB, and also zero the last 128kB. I should probably make sure that it will _always_ overwrite at least the first 68kB, but with the default parameters it will at least do so except on the smallest of filesystems (i.e. floppies). Cheers, Andreas -- Andreas Dilger http://sourceforge.net/projects/ext2resize/ http://www-mddsp.enel.ucalgary.ca/People/adilger/ From owner-linux-xfs@oss.sgi.com Thu Jan 3 17:39:09 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g041d9308730 for linux-xfs-outgoing; Thu, 3 Jan 2002 17:39:09 -0800 Received: from yog-sothoth.sgi.com (eugate.sgi.com [192.48.160.10]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g041d5g08708 for ; Thu, 3 Jan 2002 17:39:06 -0800 Received: from nodin.corp.sgi.com (nodin.corp.sgi.com [192.26.51.193]) by yog-sothoth.sgi.com (980305.SGI.8.8.8-aspam-6.2/980304.SGI-aspam-europe) via ESMTP id BAA1199681 for ; Fri, 4 Jan 2002 01:38:01 +0100 (CET) mail_from (kaos@sgi.com) Received: from kao2.melbourne.sgi.com (kao2.melbourne.sgi.com [134.14.55.180]) by nodin.corp.sgi.com (8.11.4/8.11.2/nodin-1.0) with ESMTP id g040bx421291797; Thu, 3 Jan 2002 16:38:00 -0800 (PST) Received: by kao2.melbourne.sgi.com (Postfix, from userid 16331) id 798FC300095; Fri, 4 Jan 2002 11:37:58 +1100 (EST) Received: from kao2.melbourne.sgi.com (localhost [127.0.0.1]) by kao2.melbourne.sgi.com (Postfix) with ESMTP id 322A394; Fri, 4 Jan 2002 11:37:58 +1100 (EST) X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 From: Keith Owens To: "Quang Nguyen (Ngo)" Cc: "'linux-xfs@oss.sgi.com'" Subject: Re: Disk Geometry/Partition API In-reply-to: Your message of "Thu, 03 Jan 2002 15:42:09 -0800." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 04 Jan 2002 11:37:52 +1100 Message-ID: <23545.1010104672@kao2.melbourne.sgi.com> Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 912 Lines: 17 On Thu, 3 Jan 2002 15:42:09 -0800 , "Quang Nguyen (Ngo)" wrote: >I'm writing a backup utility, which hopefully will handle full disaster >recovery in case of a disk failure. I want it to backup not only the data, >ACL, etc, but also disk geometry and partition information. This >information will be used during the recovery procedure to recreate the >partitions the original disk had with an option of resizing, etc... > >The app is Linux based, but I want it to be aware of other partitions >created by a different OS as well. I studied the source code of fdisk and >sfdisk, /usr/include/linux/genhd.h hdreg.h so I have some ideas. However, I >wondered if there are C functions available that simplify the task. I also >need some documents on the ioctl commands specified in hdreg.h. Look at the GNU partition editor (parted). http://www.fsf.org/software/parted/parted.html From owner-linux-xfs@oss.sgi.com Thu Jan 3 21:02:26 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0452QN11520 for linux-xfs-outgoing; Thu, 3 Jan 2002 21:02:26 -0800 Received: from sgi.com (sgi-too.SGI.COM [204.94.211.39]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0452Ng11497 for ; Thu, 3 Jan 2002 21:02:23 -0800 Received: from sherman.melbourne.sgi.com (sherman.melbourne.sgi.com [134.14.55.232]) by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id UAA05888 for ; Thu, 3 Jan 2002 20:01:14 -0800 (PST) mail_from (kaos@sherman.melbourne.sgi.com) Received: (from kaos@localhost) by sherman.melbourne.sgi.com (8.11.6/8.11.6) id g0442Ed09670; Fri, 4 Jan 2002 15:02:14 +1100 Date: Fri, 4 Jan 2002 15:02:14 +1100 From: Keith Owens Message-Id: <200201040402.g0442Ed09670@sherman.melbourne.sgi.com> Subject: TAKE - Sync kdb v2.0-2.4.17 common code with xfs Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 478 Lines: 17 Date: Thu Jan 3 19:48:48 PST 2002 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:109105a linux/kernel/sysctl.c - 1.47 linux/init/main.c - 1.66 linux/include/linux/sysctl.h - 1.44 linux/drivers/char/serial.c - 1.52 linux/drivers/char/keyboard.c - 1.23 linux/include/linux/kdbprivate.h - 1.16 linux/include/linux/kdb.h - 1.19 linux/kdb/ChangeLog - 1.14 From owner-linux-xfs@oss.sgi.com Thu Jan 3 21:27:08 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g045R8D12033 for linux-xfs-outgoing; Thu, 3 Jan 2002 21:27:08 -0800 Received: from deliverator.sgi.com (deliverator.sgi.com [204.94.214.10]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g045R5g12011 for ; Thu, 3 Jan 2002 21:27:05 -0800 Received: from sherman.melbourne.sgi.com (sherman.melbourne.sgi.com [134.14.55.232]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id UAA03404 for ; Thu, 3 Jan 2002 20:26:47 -0800 (PST) mail_from (kaos@sherman.melbourne.sgi.com) Received: (from kaos@localhost) by sherman.melbourne.sgi.com (8.11.6/8.11.6) id g044Qv923358; Fri, 4 Jan 2002 15:26:57 +1100 Date: Fri, 4 Jan 2002 15:26:57 +1100 From: Keith Owens Message-Id: <200201040426.g044Qv923358@sherman.melbourne.sgi.com> Subject: TAKE - Sync kdb v2.0-2.4.17 i386 code with xfs Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 562 Lines: 18 Date: Thu Jan 3 20:24:15 PST 2002 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:109106a linux/arch/i386/kdb/ChangeLog - 1.1 linux/arch/i386/kernel/traps.c - 1.41 linux/arch/i386/kernel/smp.c - 1.38 linux/arch/i386/kernel/process.c - 1.37 linux/arch/i386/kernel/irq.c - 1.38 linux/arch/i386/kernel/smpboot.c - 1.26 linux/include/asm-i386/kdb.h - 1.9 linux/include/asm-i386/kdbprivate.h - 1.14 linux/arch/i386/kernel/bluesmoke.c - 1.15 From owner-linux-xfs@oss.sgi.com Thu Jan 3 22:38:59 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g046cxE13321 for linux-xfs-outgoing; Thu, 3 Jan 2002 22:38:59 -0800 Received: from mta04ps.bigpond.com (mta04ps.bigpond.com [144.135.25.136]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g046cng13298 for ; Thu, 3 Jan 2002 22:38:50 -0800 Message-Id: <200201040638.g046cng13298@oss.sgi.com> Received: from there ([144.135.25.84]) by mta04ps.bigpond.com (Netscape Messaging Server 4.15) with SMTP id GPEFZH00.48I; Fri, 4 Jan 2002 15:45:17 +1000 Received: from CPE-144-137-138-230.qld.bigpond.net.au ([144.137.138.230]) by psmam06.mailsvc.email.bigpond.com(MailRouter V3.0h 116/6828866); 04 Jan 2002 15:38:18 Content-Type: text/plain; charset="us-ascii" From: Adrian Head To: Eric Sandeen , Steve Lord Subject: Re: Unable to get XFS, ext3, reiserfs & LVM to coexist happily Date: Fri, 4 Jan 2002 15:38:12 +1000 X-Mailer: KMail [version 1.3.1] References: In-Reply-To: Cc: Linux XFS MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 2533 Lines: 79 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Sorry - I thought I had :-( The patches for lvm come in the lvm tar.gz on the LVM site. lvm_1.0.1.tar.gz extract it out and you will have a path lke: LVM/1.0.1 Then there will be a directory "PATCHES" In the directory PATCHES run make clean && make and it will autogenerate a lvm-1.0.1 upgrade patch for you. Note however, that on my system it calls the patch lvm-1.0.1-2.4.16-xfs.patch although it looks in the 2.4.17-xfs directory. Another thing to be aware of is that the autogen patch requires the kernel tree to reside in /usr/src/linux - link as necessary. The other patch is the VFS-lock patch which is also in the PATCHES directory and is named linux-2.4.11-VFS-lock.patch. It will apply cleanly; however, there will be offsets. Remember that the order of patches is: lvm-1.0.1 upgrade; then the VFS-lock If your not using a distro that has the lvm tools already in the "LVM/1.0.1" directory ./configure make make install and that should compile and install the lvm tools. One gotcha that I found is that it you have alternative CFLAGS as a global variable in your profile there will be problems with either compiling the tools or running the tools later. Apparently gcc has a complie bug that causes problems if you don't use the default compile flags that are in the Makefile. If you guy's want my .config from the kernel tree just tell me. At the moment I have ext2 & ext3 compiled into the kernel as well as md and lvm. Everything else is modules. What I was going to do was remove ext3 from my kernel and rerun the tests - this I hope will shed some more light on the problem. I am still having problems with multiple background cp processes on an XFS volume killing the machine. Do you need more information about this problem? On Fri, 4 Jan 2002 15:01, Eric Sandeen wrote: > Hi Adrian - thanks for the very complete summary! > > One more... where did the 2 lvm patches come from? I didn't see them on > the lvm ftp or cvs... maybe I'm just dense. :) Your not dense - I wish that I had the skills to be able to dbug this stuff like you or Steve. I hope your Christmas was Merry and your New Years Happy and your break relaxing. > > -Eric - -- Adrian Head (Public Key available on request.) -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE8NT/I8ZJI8OvSkAcRAjr6AJsH6uwQwZarr0s759l4RuOOOL0PUwCghF5e /u+WfoXptNlkKrSkRXioRAI= =nrop -----END PGP SIGNATURE----- From owner-linux-xfs@oss.sgi.com Thu Jan 3 22:51:49 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g046pnw13572 for linux-xfs-outgoing; Thu, 3 Jan 2002 22:51:49 -0800 Received: from zok.sgi.com (zok.sgi.com [204.94.215.101]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g046plg13550 for ; Thu, 3 Jan 2002 22:51:47 -0800 Received: from relay1.corp.sgi.com (spindle.corp.sgi.com [198.29.75.13]) by zok.sgi.com (8.11.4/8.11.4/linux-outbound_gateway-1.1) with ESMTP id g045peA11469 for ; Thu, 3 Jan 2002 21:51:40 -0800 Received: from chuckle.americas.sgi.com (sandeen@chuckle.americas.sgi.com [128.162.211.44]) by relay1.corp.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) via ESMTP id VAA17649; Thu, 3 Jan 2002 21:51:09 -0800 (PST) Date: Thu, 3 Jan 2002 23:51:08 -0600 (CST) From: Eric Sandeen X-X-Sender: To: Adrian Head cc: Steve Lord , Linux XFS Subject: Re: Unable to get XFS, ext3, reiserfs & LVM to coexist happily In-Reply-To: <200201040537.VAA07315@sgi.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 121 Lines: 8 Thanks, didn't realize the upgrade patch was generated. I'll see if I can duplicate your troubles tomorrow... -Eric From owner-linux-xfs@oss.sgi.com Fri Jan 4 00:53:29 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g048rTB15430 for linux-xfs-outgoing; Fri, 4 Jan 2002 00:53:29 -0800 Received: from mta06ps.bigpond.com (mta06ps.bigpond.com [144.135.25.138]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g048rLg15408 for ; Fri, 4 Jan 2002 00:53:21 -0800 Message-Id: <200201040853.g048rLg15408@oss.sgi.com> Received: from there ([144.135.25.87]) by mta06ps.bigpond.com (Netscape Messaging Server 4.15) with SMTP id GPEM8C00.0CF; Fri, 4 Jan 2002 18:00:12 +1000 Received: from CPE-144-137-138-230.qld.bigpond.net.au ([144.137.138.230]) by psmam07.mailsvc.email.bigpond.com(MailRouter V3.0h 125/3329888); 04 Jan 2002 17:53:12 Content-Type: text/plain; charset="us-ascii" From: Adrian Head To: Andreas Dilger Subject: Re: [linux-lvm] Unable to get XFS, ext3, reiserfs & LVM to coexist happily Date: Fri, 4 Jan 2002 17:53:05 +1000 X-Mailer: KMail [version 1.3.1] Cc: linux-xfs@oss.sgi.com, linux-lvm@sistina.com References: <200201030315.UAA21279@cthulhu.turbolabs.com> <20020103100030.V12868@lynx.no> In-Reply-To: <20020103100030.V12868@lynx.no> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 2186 Lines: 61 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Fri, 4 Jan 2002 03:00, Andreas Dilger wrote: > Maybe yes. This is very strange. Are you testing all of these filesystems > on the same LV in order? Can you try just doing XFS by itself on a clean > reboot? I assume that you are rebooting after every oops, because if you > don't there is junk in the kernel memory that will screw up further tests. Each test is done on its own LV and there is always a reboot and recovery before every test after an Oops. More information about the vg's and lv's as well as the test procedure can be found halfway down: http://marc.theaimsgroup.com/?l=linux-xfs&m=101010337524477&w=2 > > > * Can create xfs snapshot? | Oops > > btp 1234 (lvcreate) > > journal_start > > ext3_dirty_inode > > ^^^^^^^^^^^^^^^^ yes, very strange. > > > __mark_inode_dirty > > update_atime > > do_generic_file_read > > generic_file_read > > sys_read > > system_call I have been thinking - the VFS-lock patch tries to get all (not sure - at least ext3 & resierfs) to flush everything to disk. Maybe its actually an interaction problem between ext3 and LVM? but why XFS? I'm only guessing here at the moment. > > Note that it appears most of the ext3 fixes went into 2.4.17, so this may > be a new bug. As I said, let's try first with XFS snapshots only, and if > that doesn't have a problem, try to re-create the above problem and send > a full oops report to ext2-devel. This is what I'm having trouble with at the moment. When the kernel Oops occurs it drops me into kdb (kernel debugger). From here I can look at current process status, do back traces on anything thats running etc.. but it never shows me the full Kernel Oops and there is no record of it in the logs either. I expect that a couple of backtraces, list of processes, register values would be equivalent to a Kernel Oops report? - -- Adrian Head (Public Key available on request.) -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE8NV9k8ZJI8OvSkAcRArjiAJ9aID1RCLX1ePuHYEYtsrYuxfAMOQCeKepa iobc03+nCMZhPdUQ0Yg6E/U= =RAuQ -----END PGP SIGNATURE----- From owner-linux-xfs@oss.sgi.com Fri Jan 4 01:43:41 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g049hfY16254 for linux-xfs-outgoing; Fri, 4 Jan 2002 01:43:41 -0800 Received: from mail.ocs.com.au (mail.ocs.com.au [203.34.97.2]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g049hag16232 for ; Fri, 4 Jan 2002 01:43:36 -0800 Received: (qmail 3778 invoked from network); 4 Jan 2002 08:43:32 -0000 Received: from ocs3.intra.ocs.com.au (192.168.255.3) by mail.ocs.com.au with SMTP; 4 Jan 2002 08:43:32 -0000 Received: by ocs3.intra.ocs.com.au (Postfix, from userid 16331) id DDD47300095; Fri, 4 Jan 2002 19:43:25 +1100 (EST) Received: from ocs3.intra.ocs.com.au (localhost [127.0.0.1]) by ocs3.intra.ocs.com.au (Postfix) with ESMTP id 6229194; Fri, 4 Jan 2002 19:43:25 +1100 (EST) X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 From: Keith Owens To: Adrian Head Cc: Andreas Dilger , linux-xfs@oss.sgi.com, linux-lvm@sistina.com Subject: Re: [linux-lvm] Unable to get XFS, ext3, reiserfs & LVM to coexist happily In-reply-to: Your message of "Fri, 04 Jan 2002 17:53:05 +1000." <200201040853.g048rLg15408@oss.sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 04 Jan 2002 19:43:19 +1100 Message-ID: <2519.1010133799@ocs3.intra.ocs.com.au> Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 814 Lines: 15 On Fri, 4 Jan 2002 17:53:05 +1000, Adrian Head wrote: >This is what I'm having trouble with at the moment. When the kernel Oops >occurs it drops me into kdb (kernel debugger). From here I can look at >current process status, do back traces on anything thats running etc.. but it >never shows me the full Kernel Oops and there is no record of it in the logs >either. I expect that a couple of backtraces, list of processes, register >values would be equivalent to a Kernel Oops report? If you type 'go' in kdb then the kernel will continue with the rest of the oops processing. The registers and backtrace from kdb are better data than oops can do, more detailed and more accurate. The oops report gives the failing code, use 'id %eip' in kdb to decode the current instructions. From owner-linux-xfs@oss.sgi.com Fri Jan 4 03:32:59 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g04BWxK18266 for linux-xfs-outgoing; Fri, 4 Jan 2002 03:32:59 -0800 Received: from ADSL-Bergs.RZ.RWTH-Aachen.DE (adsl-bergs.rz.RWTH-Aachen.DE [137.226.80.218]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g04BWLg18232 for ; Fri, 4 Jan 2002 03:32:22 -0800 Received: from [192.168.1.2] (helo=ralf) by ADSL-Bergs.RZ.RWTH-Aachen.DE with smtp (Exim 3.12 #1) id 16MRdp-00027I-00; Fri, 04 Jan 2002 11:32:01 +0100 From: "Ralf G. R. Bergs" To: "Seth Mos" Cc: "Linux XFS Mailing List" , "Eric Sandeen" Date: Fri, 04 Jan 2002 11:32:01 +0100 Reply-To: "Ralf G. R. Bergs" X-Mailer: PMMail 2000 Professional (2.20.2380) For Windows 2000 (5.0.2195;2) In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Subject: Re: UPDATE: VERY URGENT: "cp -a" creates mysteriously "hidden" files?! Message-Id: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 6500 Lines: 212 First: Happy new year all!! On Sun, 30 Dec 2001 13:19:16 +0100 (CET), Seth Mos wrote: [...] >> This is what I got (dramatically truncated because of 60,000 lines output!!!): > >Ick! We need a expert in here. This is why I'm asking here. :-) [...] >Can you give some hardware details about the machine? I am not really >suspecting that your hardware is broken but sometimes slight variations in >a machine config make it do funny things. Ok. Fileserver:~# cat /proc/cpuinfo processor : 0 vendor_id : GenuineIntel cpu family : 6 model : 7 model name : Pentium III (Katmai) stepping : 3 cpu MHz : 451.028 cache size : 512 KB fdiv_bug : no hlt_bug : no f00f_bug : no coma_bug : no fpu : yes fpu_exception : yes cpuid level : 2 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 mmx fxsr sse bogomips : 897.84 processor : 1 vendor_id : GenuineIntel cpu family : 6 model : 7 model name : Pentium III (Katmai) stepping : 3 cpu MHz : 451.028 cache size : 512 KB fdiv_bug : no hlt_bug : no f00f_bug : no coma_bug : no fpu : yes fpu_exception : yes cpuid level : 2 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 mmx fxsr sse bogomips : 901.12 Fileserver:~# free total used free shared buffers cached Mem: 514068 509088 4980 0 26976 275744 -/+ buffers/cache: 206368 307700 Swap: 1670720 6632 1664088 Fileserver:~# uname -a Linux Fileserver.my.domain.de 2.4.17-xfs #1 SMP Sat Dec 29 16:53:18 CET 2001 i686 unknown Fileserver:~# less /boot/config-2.4.17-xfs CONFIG_MPENTIUMIII=y [...] CONFIG_X86_WP_WORKS_OK=y CONFIG_X86_INVLPG=y CONFIG_X86_CMPXCHG=y CONFIG_X86_XADD=y CONFIG_X86_BSWAP=y CONFIG_X86_POPAD_OK=y # CONFIG_RWSEM_GENERIC_SPINLOCK is not set CONFIG_RWSEM_XCHGADD_ALGORITHM=y CONFIG_X86_L1_CACHE_SHIFT=5 CONFIG_X86_TSC=y CONFIG_X86_GOOD_APIC=y CONFIG_X86_PGE=y CONFIG_X86_USE_PPRO_CHECKSUM=y [...] CONFIG_MICROCODE=m CONFIG_X86_MSR=m CONFIG_X86_CPUID=m CONFIG_NOHIGHMEM=y # CONFIG_HIGHMEM4G is not set # CONFIG_HIGHMEM64G is not set # CONFIG_MATH_EMULATION is not set CONFIG_MTRR=y CONFIG_SMP=y # CONFIG_MULTIQUAD is not set CONFIG_HAVE_DEC_LOCK=y Fileserver:~# cat /proc/pci PCI devices found: Bus 0, device 0, function 0: Host bridge: Intel Corp. 440BX/ZX - 82443BX/ZX Host bridge (rev 3). Master Capable. Latency=64. Prefetchable 32 bit memory at 0xd0000000 [0xdfffffff]. Bus 0, device 1, function 0: PCI bridge: Intel Corp. 440BX/ZX - 82443BX/ZX AGP bridge (rev 3). Master Capable. Latency=64. Min Gnt=136. Bus 0, device 4, function 0: ISA bridge: Intel Corp. 82371AB PIIX4 ISA (rev 2). Bus 0, device 4, function 1: IDE interface: Intel Corp. 82371AB PIIX4 IDE (rev 1). Master Capable. Latency=32. I/O at 0xd800 [0xd80f]. Bus 0, device 4, function 2: USB Controller: Intel Corp. 82371AB PIIX4 USB (rev 1). IRQ 12. Master Capable. Latency=32. I/O at 0xd400 [0xd41f]. Bus 0, device 4, function 3: Bridge: Intel Corp. 82371AB PIIX4 ACPI (rev 2). IRQ 9. Bus 0, device 10, function 0: SCSI storage controller: Adaptec AHA-2940U2/W (rev 0). IRQ 11. Master Capable. Latency=32. Min Gnt=39.Max Lat=25. I/O at 0xd000 [0xd0ff]. Non-prefetchable 64 bit memory at 0xc7800000 [0xc7800fff]. Bus 0, device 11, function 0: Ethernet controller: 3Com Corporation 3c905B 100BaseTX [Cyclone] (rev 36). IRQ 10. Master Capable. Latency=32. Min Gnt=10.Max Lat=10. I/O at 0xb800 [0xb87f]. Non-prefetchable 32 bit memory at 0xc7000000 [0xc700007f]. Bus 1, device 0, function 0: VGA compatible controller: S3 Inc. 86c368 [Trio 3D/2X] (rev 2). Master Capable. Latency=64. Min Gnt=4.Max Lat=255. Non-prefetchable 32 bit memory at 0xc8000000 [0xcbffffff]. Fileserver:~# cat /proc/scsi/scsi Attached devices: Host: scsi0 Channel: 00 Id: 00 Lun: 00 Vendor: IBM Model: DNES-309170W Rev: SA30 Type: Direct-Access ANSI SCSI revision: 03 Host: scsi0 Channel: 00 Id: 01 Lun: 00 Vendor: IFT Model: 3102 Rev: 0223 Type: Direct-Access ANSI SCSI revision: 02 Host: scsi0 Channel: 00 Id: 03 Lun: 00 Vendor: PLEXTOR Model: CD-ROM PX-40TS Rev: 1.01 Type: CD-ROM ANSI SCSI revision: 02 Host: scsi0 Channel: 00 Id: 04 Lun: 00 Vendor: easyRAID Model: II Rev: Type: Direct-Access ANSI SCSI revision: 02 Dec 29 17:12:05 Fileserver kernel: Vendor: easyRAID Model: II Rev: Dec 29 17:12:05 Fileserver kernel: Type: Direct-Access ANSI SCSI revision: 02 Dec 29 17:12:05 Fileserver kernel: (scsi0:A:4): 80.000MB/s transfers (40.000MHz, offset 31, 16bit) Dec 29 17:12:05 Fileserver kernel: SCSI device sdc: 720355328 512-byte hdwr sect ors (368822 MB) Dec 29 17:12:05 Fileserver kernel: sdc: sdc1 < sdc5 > Disk Drive: /dev/sdc Size: 368821927936 bytes Heads: 255 Sectors per Track: 63 Cylinders: 44840 Disk /dev/sdc: 255 heads, 63 sectors, 44840 cylinders Units = cylinders of 16065 * 512 bytes Device Boot Start End Blocks Id System /dev/sdc1 1 44840 360177268+ 5 Extended /dev/sdc5 1 44840 360177237 83 Linux Anything else that might be interesting? >Since you have hardware raid I am asuming you are running SMP and possibly >highmem? Is this a self built machine or a certain "brand" Like Dell, HP, SMP: yes, highmem: NO It's a self-built machine, not a brand machine. >> Still any ideas?! > >I am out. You might get an answer next year or so :-) That's fine for me. It IS next year now... :-) >Holidays and all. Thanks, you too. Ralf -- Verkaufe Original-BMW-Raeder: L I N U X .~. http://adsl-bergs.rz.rwth-aachen.de/~rabe The Choice /V\ of a GNU /( )\ Generation ^^-^^ From owner-linux-xfs@oss.sgi.com Fri Jan 4 03:52:30 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g04BqUH18665 for linux-xfs-outgoing; Fri, 4 Jan 2002 03:52:30 -0800 Received: from s1.uklinux.net (mail.uklinux.net [80.84.72.21]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g04BqQg18643 for ; Fri, 4 Jan 2002 03:52:26 -0800 Received: from pyewacket.nic.uklinux.net (host213-122-112-86.btinternet.com [213.122.112.86]) (authenticated) by s1.uklinux.net (8.11.6/8.11.6) with ESMTP id g04ApxA22824; Fri, 4 Jan 2002 10:52:00 GMT Envelope-To: linux-xfs@oss.sgi.com Received: from nic by pyewacket.nic.uklinux.net with local (Exim 3.33 #1) id 16MRvw-0000Xm-00; Fri, 04 Jan 2002 10:50:44 +0000 Subject: Re: file corruption during emacs build on XFS logical volume From: Nic Doye To: Sean Neakums Cc: linux-xfs@oss.sgi.com In-Reply-To: <6uheq3m08y.fsf@zork.zork.net> References: <6u4rm4r53e.fsf@zork.zork.net> <6uu1u4pf48.fsf@zork.zork.net> <1010013019.1281.6.camel@jen.americas.sgi.com> <6upu4spccv.fsf@zork.zork.net> <1010013997.1315.11.camel@jen.americas.sgi.com> <6ulmfgpau5.fsf@zork.zork.net> <6uheq4p9ny.fsf@zork.zork.net> <3C33AF81.AC235AD0@idcomm.com> <6ubsgbq013.fsf@zork.zork.net> <1010069377.23328.15.camel@jen.americas.sgi.com> <1010072382.23328.38.camel@jen.americas.sgi.com> <6u3d1npgx9.fsf@zork.zork.net> <1010075404.12080.79.camel@jen.americas.sgi.com> <1010076426.12080.86.camel@jen.americas.sgi.com> <6uu1u3nt3h.fsf@zork.zork.net> <1010087177.12080.104.camel@jen.americas.sgi.com> <6upu4rnquf.fsf@zork.zork.net> <1010088984.23328.115.camel@jen.americas.sgi.com> <1010097091.23328.117.camel@jen.americas.sgi.com> <6u3d1nnjsc.fsf@zork.zork.net> <3C34F294.D6D015BC@idcomm.com> <6uheq3m08y.fsf@zork.zork.net> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/1.0 Date: 04 Jan 2002 10:50:44 +0000 Message-Id: <1010141444.1992.3.camel@pyewacket> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 516 Lines: 13 On Fri, 2002-01-04 at 00:24, Sean Neakums wrote: > After I got that bogus dumped binary, I've done about thirty more > dumps, by hand. They all seem to run fine, although I'm getting > different md5sums for each of them, even though I'm taking pains to > dump each under the same filename. I'm not sure if the dumping > process guarantees identical binaries each time or not. I think the binary contains things like the date/time of the build (as visible in the spash screen). Hence the different md5sums. nic From owner-linux-xfs@oss.sgi.com Fri Jan 4 10:12:47 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g04IClQ13470 for linux-xfs-outgoing; Fri, 4 Jan 2002 10:12:47 -0800 Received: from sgi.com (sgi-too.SGI.COM [204.94.211.39]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g04ICTg13444 for ; Fri, 4 Jan 2002 10:12:29 -0800 Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id JAA09638 for ; Fri, 4 Jan 2002 09:11:16 -0800 (PST) mail_from (lord@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id LAA3952795 for ; Fri, 4 Jan 2002 11:11:10 -0600 (CST) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id LAA20702 for ; Fri, 4 Jan 2002 11:11:10 -0600 (CST) From: Steve Lord Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id g04HB1d22972; Fri, 4 Jan 2002 11:11:01 -0600 Message-Id: <200201041711.g04HB1d22972@jen.americas.sgi.com> Date: Fri, 4 Jan 2002 11:11:01 -0600 Subject: TAKE - merge up to 2.5.2-pre7 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 5743 Lines: 167 If anyone is building this stuff, do a make clean before rebuilding this one. I don't know why, but xfs got very confused until I did this. Date: Fri Jan 4 09:06:31 PST 2002 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:109113a linux/drivers/usb/stv680.h - 1.1 linux/Documentation/usb/ehci.txt - 1.1 linux/Documentation/usb/stv680.txt - 1.1 linux/drivers/usb/stv680.c - 1.1 linux/drivers/usb/vicam.c - 1.1 linux/drivers/usb/vicam.h - 1.1 linux/drivers/usb/vicamurbs.h - 1.1 linux/net/netlink/netlink_dev.c - 1.12 linux/kernel/sched.c - 1.48 linux/include/linux/sched.h - 1.51 linux/include/linux/blkdev.h - 1.50 linux/include/linux/blk.h - 1.28 linux/fs/umsdos/inode.c - 1.21 linux/fs/smbfs/inode.c - 1.26 linux/fs/smbfs/file.c - 1.23 linux/fs/romfs/inode.c - 1.28 linux/fs/nfsd/nfs3xdr.c - 1.23 linux/fs/nfs/write.c - 1.34 linux/fs/ncpfs/inode.c - 1.23 linux/fs/namei.c - 1.44 linux/fs/hfs/file.c - 1.15 linux/fs/dquot.c - 1.47 linux/fs/coda/inode.c - 1.16 linux/fs/affs/super.c - 1.16 linux/drivers/video/vesafb.c - 1.18 linux/drivers/video/fbmem.c - 1.42 linux/drivers/video/fbcon.c - 1.24 linux/drivers/usb/audio.c - 1.35 linux/drivers/usb/Makefile - 1.45 linux/drivers/usb/Config.in - 1.51 linux/drivers/sound/soundcard.c - 1.22 linux/drivers/sound/es1370.c - 1.35 linux/drivers/scsi/u14-34f.h - 1.10 linux/drivers/scsi/u14-34f.c - 1.19 linux/drivers/scsi/sr_vendor.c - 1.11 linux/drivers/scsi/sr_ioctl.c - 1.21 linux/drivers/scsi/sr.c - 1.36 linux/drivers/scsi/sg.c - 1.27 linux/drivers/scsi/scsi.c - 1.49 linux/drivers/scsi/pci2220i.c - 1.21 linux/drivers/scsi/pci2000.c - 1.18 linux/drivers/scsi/in2000.h - 1.8 linux/drivers/scsi/in2000.c - 1.10 linux/drivers/scsi/ide-scsi.c - 1.22 linux/drivers/scsi/fdomain.c - 1.18 linux/drivers/scsi/eata.h - 1.9 linux/drivers/scsi/eata.c - 1.20 linux/drivers/scsi/aha1740.c - 1.8 linux/drivers/scsi/aha152x.c - 1.26 linux/drivers/scsi/advansys.c - 1.21 linux/drivers/scsi/BusLogic.h - 1.7 linux/drivers/net/slip.c - 1.19 linux/drivers/net/irda/irtty.c - 1.25 linux/drivers/net/defxx.c - 1.19 linux/drivers/isdn/isdn_tty.c - 1.19 linux/drivers/isdn/isdn_ppp.c - 1.21 linux/drivers/isdn/isdn_common.c - 1.31 linux/drivers/isdn/hisax/hisax.h - 1.24 linux/drivers/isdn/hisax/config.c - 1.26 linux/drivers/isdn/hisax/Makefile - 1.15 linux/drivers/isdn/avmb1/capi.c - 1.27 linux/drivers/isdn/avmb1/b1pci.c - 1.16 linux/drivers/isdn/Config.in - 1.21 linux/drivers/char/wdt.c - 1.14 linux/drivers/char/tty_io.c - 1.40 linux/drivers/char/sysrq.c - 1.21 linux/drivers/char/pcwd.c - 1.17 linux/drivers/char/lp.c - 1.27 linux/drivers/char/busmouse.c - 1.19 linux/drivers/char/acquirewdt.c - 1.14 linux/drivers/cdrom/sonycd535.c - 1.15 linux/drivers/block/rd.c - 1.44 linux/drivers/block/loop.c - 1.47 linux/drivers/block/ll_rw_blk.c - 1.89 linux/Makefile - 1.170 linux/Documentation/Configure.help - 1.121 linux/include/linux/ide.h - 1.35 linux/drivers/usb/printer.c - 1.41 linux/drivers/usb/acm.c - 1.43 linux/drivers/char/ppdev.c - 1.27 linux/drivers/block/cpqarray.c - 1.39 linux/drivers/sound/esssolo1.c - 1.33 linux/fs/partitions/acorn.c - 1.13 linux/drivers/isdn/avmb1/b1.c - 1.15 linux/drivers/isdn/avmb1/avmcard.h - 1.8 linux/drivers/block/DAC960.h - 1.12 linux/drivers/sound/maestro.c - 1.26 linux/drivers/scsi/ips.c - 1.21 linux/net/irda/ircomm/ircomm_tty.c - 1.16 linux/drivers/net/wan/cosa.c - 1.23 linux/drivers/scsi/sim710.c - 1.9 linux/drivers/usb/dc2xx.c - 1.24 linux/drivers/isdn/avmb1/t1pci.c - 1.15 linux/drivers/scsi/scsi_lib.c - 1.41 linux/drivers/i2c/i2c-dev.c - 1.15 linux/drivers/usb/dabusb.c - 1.16 linux/fs/cramfs/inode.c - 1.22 linux/drivers/usb/scanner.c - 1.26 linux/Documentation/usb/usb-serial.txt - 1.18 linux/drivers/net/wan/sdla_chdlc.c - 1.16 linux/drivers/usb/scanner.h - 1.19 linux/drivers/isdn/avmb1/c4.c - 1.16 linux/drivers/isdn/avmb1/b1dma.c - 1.18 linux/fs/devfs/util.c - 1.10 linux/fs/devfs/base.c - 1.26 linux/drivers/usb/serial/Makefile - 1.17 linux/drivers/ide/pdc4030.c - 1.7 linux/drivers/ide/ide.c - 1.40 linux/drivers/ide/ide-probe.c - 1.22 linux/drivers/ide/ide-disk.c - 1.20 linux/drivers/block/elevator.c - 1.14 linux/include/linux/elevator.h - 1.9 linux/drivers/isdn/avmb1/capifs.c - 1.13 linux/drivers/char/wdt_pci.c - 1.9 linux/drivers/usb/serial/usbserial.c - 1.27 linux/drivers/sound/i810_audio.c - 1.19 linux/fs/partitions/ibm.c - 1.10 linux/arch/i386/kernel/msr.c - 1.13 linux/arch/i386/kernel/cpuid.c - 1.6 linux/drivers/char/joystick/serport.c - 1.4 linux/drivers/usb/bluetooth.c - 1.20 linux/fs/jffs/inode-v23.c - 1.15 linux/fs/smbfs/ChangeLog - 1.8 linux/fs/smbfs/getopt.h - 1.2 linux/fs/smbfs/getopt.c - 1.3 linux/drivers/sound/cs46xx.c - 1.16 linux/drivers/media/video/videodev.c - 1.10 linux/drivers/media/video/cpia.c - 1.8 linux/drivers/input/mousedev.c - 1.8 linux/drivers/input/joydev.c - 1.8 linux/drivers/input/input.c - 1.7 linux/drivers/input/evdev.c - 1.7 linux/drivers/block/cciss.c - 1.26 linux/drivers/block/cciss_cmd.h - 1.6 linux/drivers/usb/serial/Config.in - 1.11 linux/drivers/sound/maestro3.c - 1.10 linux/drivers/sound/cs4281/cs4281m.c - 1.8 linux/drivers/char/machzwd.c - 1.6 linux/drivers/char/advantechwdt.c - 1.5 linux/drivers/scsi/dpt_i2o.c - 1.8 linux/drivers/usb/hiddev.c - 1.4 linux/fs/jffs2/dir.c - 1.2 linux/fs/jffs2/file.c - 1.3 linux/fs/jffs2/gc.c - 1.3 linux/fs/jffs2/super.c - 1.3 linux/drivers/char/ib700wdt.c - 1.2 linux/drivers/char/eurotechwdt.c - 1.2 linux/fs/ext3/ialloc.c - 1.4 linux/fs/ext3/super.c - 1.4 linux/fs/intermezzo/psdev.c - 1.3 linux/fs/intermezzo/super.c - 1.2 linux/kernel/device.c - 1.4 linux/drivers/net/de2104x.c - 1.2 linux/drivers/usb/hcd/Config.in - 1.2 From owner-linux-xfs@oss.sgi.com Fri Jan 4 10:23:26 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g04INQV13743 for linux-xfs-outgoing; Fri, 4 Jan 2002 10:23:26 -0800 Received: from UberGeek.coremetrics.com ([209.184.141.163]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g04INAg13719 for ; Fri, 4 Jan 2002 10:23:11 -0800 Received: (from austin@localhost) by UberGeek.coremetrics.com (8.11.6/8.11.6) id g04HMFQ02136; Fri, 4 Jan 2002 11:22:15 -0600 X-Authentication-Warning: UberGeek.coremetrics.com: austin set sender to austin@coremetrics.com using -f Subject: Re: file corruption during emacs build on XFS logical volume From: Austin Gonyou To: Nic Doye Cc: Sean Neakums , linux-xfs@oss.sgi.com In-Reply-To: <1010141444.1992.3.camel@pyewacket> References: <1010141444.1992.3.camel@pyewacket> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-sLeojJsueIO8OQXhpIGh" X-Mailer: Evolution/1.0.0.99+cvs.2001.12.18.08.57 (Preview Release) Date: 04 Jan 2002 11:22:15 -0600 Message-Id: <1010164935.1945.8.camel@UberGeek> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 1729 Lines: 51 --=-sLeojJsueIO8OQXhpIGh Content-Type: text/plain Content-Transfer-Encoding: quoted-printable No, It does not guarantee. Also, if you're not on the same Inode the file time is different, etc, it's possible to have different md5sums. A basic size and file comparison is probably best for what you want to do. Something you can do to test what I'm talking about is copy each of your dumps to another name, binfilexyz.1 or something, then compare it's md5sum against the original. Those should be the only time they match.=20= =20 On Fri, 2002-01-04 at 04:50, Nic Doye wrote: > On Fri, 2002-01-04 at 00:24, Sean Neakums wrote: >=20 > > After I got that bogus dumped binary, I've done about thirty more > > dumps, by hand. They all seem to run fine, although I'm getting > > different md5sums for each of them, even though I'm taking pains to > > dump each under the same filename. I'm not sure if the dumping > > process guarantees identical binaries each time or not. >=20 > I think the binary contains things like the date/time of the build (as > visible in the spash screen). Hence the different md5sums. >=20 > nic --=20 Austin Gonyou Systems Architect, CCNA Coremetrics, Inc. Phone: 512-698-7250 email: austin@coremetrics.com "It is the part of a good shepherd to shear his flock, not to skin it." Latin Proverb --=-sLeojJsueIO8OQXhpIGh Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQA8NeTH94g6ZVmFMoIRAtn3AJ9ob4FI5KgfV3eV6XYUY3s2HR4TfQCg3iX2 WXULPfSuU4BP2joJAq8nuxk= =iiuQ -----END PGP SIGNATURE----- --=-sLeojJsueIO8OQXhpIGh-- From owner-linux-xfs@oss.sgi.com Fri Jan 4 11:05:02 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g04J52l17954 for linux-xfs-outgoing; Fri, 4 Jan 2002 11:05:02 -0800 Received: from zork.zork.net (zork.zork.net [64.81.65.8]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g04J4tg17931 for ; Fri, 4 Jan 2002 11:04:56 -0800 Received: from localhost (zork.zork.net) [127.0.0.1] by zork.zork.net with esmtp (Exim 3.33 #1 (Debian)) id 16MYi4-0005xj-00; Fri, 04 Jan 2002 10:04:52 -0800 To: Linux XFS Subject: Re: file corruption during emacs build on XFS logical volume References: <1010141444.1992.3.camel@pyewacket> <1010164935.1945.8.camel@UberGeek> From: Sean Neakums X-Message-Flag: Message text advisory: DENIAL OF THE ANTECEDENT, IGNORATIO ELENCHI X-Mailer: Norman Mail-Followup-To: Linux XFS Date: Fri, 04 Jan 2002 18:04:52 +0000 In-Reply-To: <1010164935.1945.8.camel@UberGeek> (Austin Gonyou's message of "04 Jan 2002 11:22:15 -0600") Message-ID: <6u666ikn5n.fsf@zork.zork.net> User-Agent: Gnus/5.090004 (Oort Gnus v0.04) Emacs/21.1 (i386-debian-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 885 Lines: 20 begin Austin Gonyou quotation: > No, It does not guarantee. Also, if you're not on the same Inode the > file time is different, etc, it's possible to have different md5sums. A > basic size and file comparison is probably best for what you want to do. The md5sum of a file is based on its contents only. The inode has nothing to do with it. > Something you can do to test what I'm talking about is copy each of your > dumps to another name, binfilexyz.1 or something, then compare it's > md5sum against the original. Those should be the only time they match. I'm not sure exaclty what you mean by this. The name of the file is irrelevant in the computation of the md5sum. -- ///////////////// | | The spark of a pin | (require 'gnu) | dropping, falling feather-like. \\\\\\\\\\\\\\\\\ | | There is too much noise. From owner-linux-xfs@oss.sgi.com Fri Jan 4 11:24:39 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g04JOdx18343 for linux-xfs-outgoing; Fri, 4 Jan 2002 11:24:39 -0800 Received: from itmpi08.mpi.it ([195.223.47.194]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g04JOXg18321 for ; Fri, 4 Jan 2002 11:24:35 -0800 Received: from istruzione.it ([172.16.56.46]) by itmpi08.mpi.it (Netscape Messaging Server 4.15) with SMTP id GPFEDQ00.H3I; Fri, 4 Jan 2002 19:08:14 +0100 Received: from 213.82.150.92 (SquirrelMail authenticated user fabrizio.celli) by www2.trampi.istruzione.it with HTTP; Fri, 4 Jan 2002 19:12:04 -0100 (NFT) Message-ID: <3221.213.82.150.92.1010167924.squirrel@www2.trampi.istruzione.it> Date: Fri, 4 Jan 2002 19:12:04 -0100 (NFT) Subject: SAMBA 2.2.2 AND XFS QUOTA SUPPORT From: "Fabrizio Celli" To: linux-xfs@oss.sgi.com Cc: nathans@sgi.com X-Mailer: SquirrelMail (version 1.0.2) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 810 Lines: 24 Hi everybody, testing the Nathan's "experimental" patch we got samba working on a xfs filesystem with quota enabled, Our configuration is: RH 7.2 with SGI custom kernel 2.4.9-13 samba 2.2.2 with the xfs quota patch The only problem we encountered (by now) is that from a win2k client, when we access the smb share with quota on, the win2k file manager show us the whole size of the filesystem instead of the soft limit size. Naturally we can't write more than the hard limit but it's not nice for our customers to think of having 100Gb of free space and get the message "DISK FULL" Using an ext3 filesystem everything seem working (if we don't consider that we can't call it a journaled filesystem). We don't know if it's a samba xfs quota implementation problem or not. Any suggestion ? Thank you all From owner-linux-xfs@oss.sgi.com Fri Jan 4 11:28:18 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g04JSIB18486 for linux-xfs-outgoing; Fri, 4 Jan 2002 11:28:18 -0800 Received: from zork.zork.net (zork.zork.net [64.81.65.8]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g04JSCg18464 for ; Fri, 4 Jan 2002 11:28:12 -0800 Received: from localhost (zork.zork.net) [127.0.0.1] by zork.zork.net with esmtp (Exim 3.33 #1 (Debian)) id 16MZ4c-0006UC-00; Fri, 04 Jan 2002 10:28:10 -0800 To: Linux XFS Subject: Re: file corruption during emacs build on XFS logical volume References: <1010141444.1992.3.camel@pyewacket> <1010164935.1945.8.camel@UberGeek> <6u666ikn5n.fsf@zork.zork.net> From: Sean Neakums X-Message-Flag: Message text advisory: NON-SEQUITUR, ADULT LANGUAGE/SITUATIONS X-Mailer: Norman Mail-Followup-To: Linux XFS Date: Fri, 04 Jan 2002 18:28:10 +0000 In-Reply-To: <6u666ikn5n.fsf@zork.zork.net> (Sean Neakums's message of "Fri, 04 Jan 2002 18:04:52 +0000") Message-ID: <6usn9mj7id.fsf@zork.zork.net> User-Agent: Gnus/5.090004 (Oort Gnus v0.04) Emacs/21.1 (i386-debian-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 1991 Lines: 43 begin Sean Neakums quotation: > begin Austin Gonyou quotation: > >> No, It does not guarantee. Also, if you're not on the same Inode the >> file time is different, etc, it's possible to have different md5sums. A >> basic size and file comparison is probably best for what you want to do. > > The md5sum of a file is based on its contents only. The inode has > nothing to do with it. > >> Something you can do to test what I'm talking about is copy each of your >> dumps to another name, binfilexyz.1 or something, then compare it's >> md5sum against the original. Those should be the only time they match. > > I'm not sure exaclty what you mean by this. The name of the file is > irrelevant in the computation of the md5sum. In Emacs' case, there's a niggle with this: if there's already an emacs-21.1.1 file there, it'll dump as emacs-21.1.2, and the dumped file will have that version embedded in it. The script I was using to generate the ms5sum was aware of this, and deleted the dumped files before each dump, so that the dump always happened to the name emacs-21.1.1. However, there is a variable, emacs-build-time, which contains the exact time the dump occurred. So md5sums are no use anyway. Funnily, the last file dump I did worked correctly at the time, but is now segfaulting, some hours later. I was doing the dumps while running three instances of this program, which I hacked up in a hurry, to generate lots of dirty pages and actual I/O: http://zork.net/~sneakums/io-test.c I wonder if the pages that are modified by the dump are not being written to disk correctly? This last dump was in a D state for a few minutes while the three io-test instances were running, but it did complete and seemingly start up correctly a few minutes after I killed them. -- ///////////////// | | The spark of a pin | (require 'gnu) | dropping, falling feather-like. \\\\\\\\\\\\\\\\\ | | There is too much noise. From owner-linux-xfs@oss.sgi.com Fri Jan 4 11:30:04 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g04JU4l18628 for linux-xfs-outgoing; Fri, 4 Jan 2002 11:30:04 -0800 Received: from www.fortuitous.com (cs6625128-203.austin.rr.com [66.25.128.203]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g04JTxg18593 for ; Fri, 4 Jan 2002 11:29:59 -0800 Received: by www.fortuitous.com (Postfix, from userid 500) id BE746122; Fri, 4 Jan 2002 12:28:45 -0600 (CST) Date: Fri, 4 Jan 2002 12:28:45 -0600 From: pac@fortuitous.com To: Alan Eldridge Cc: linux-xfs@oss.sgi.com Subject: Re: vmware compatiblity Message-ID: <20020104122845.A8140@bistro.marx> Reply-To: pac@fortuitous.com References: <20011011182134.A5027@bistro.marx> <20011011201458.A2899@wwweasel.geeksrus.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20011011201458.A2899@wwweasel.geeksrus.net> User-Agent: Mutt/1.3.23i Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 1048 Lines: 28 > I'm now happily running VMWare 2.0.4 under Linux 2.4.7. So, to make this > work first download the patch: > > ftp://platan.vc.cvut.cz/pub/vmware/vmmon-for-2.4.7-only.tar.gz > Then copy it to the '/usr/local/lib/vmware/modules/source' directory. > Next, > run: > cd /usr/local/lib/vmware/modules/source > gunzip vmmon-for-2.4.7-only.tar.gz > > After that, make a backup of the existing 'vmmon.tar' file and copy the Alan, Have you heard any reports about vmware 2.x for newer kernels? 2.4.17+ ? The patch site ftp://platan.vc.cvut.cz/pub/vmware/ seems to indicate that all is ok on 2.4.6+ if you use the vmware-ws-1455-update3.tar.gz fix... Any gossip or news appreciated. -Phil Carinhas -- .--------------------------------------------------------. | Dr. Philip A. Carinhas | pac@fortuitous.com | | Fortuitous Technologies Inc. | http://fortuitous.com | | Linux Consulting & Training | Tel : 1-512-467-2154 | `--------------------------------------------------------' From owner-linux-xfs@oss.sgi.com Fri Jan 4 11:31:38 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g04JVcZ18763 for linux-xfs-outgoing; Fri, 4 Jan 2002 11:31:38 -0800 Received: from rj.sgi.com (rj.sgi.com [204.94.215.100]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g04JVXg18741 for ; Fri, 4 Jan 2002 11:31:33 -0800 Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by rj.sgi.com (8.11.4/8.11.4/linux-outbound_gateway-1.1) with ESMTP id g04IVPY27394 for ; Fri, 4 Jan 2002 10:31:26 -0800 Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id MAA3939491; Fri, 4 Jan 2002 12:30:09 -0600 (CST) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id MAA19167; Fri, 4 Jan 2002 12:30:09 -0600 (CST) Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id g04IU0D28828; Fri, 4 Jan 2002 12:30:00 -0600 Subject: Re: file corruption during emacs build on XFS logical volume From: Steve Lord To: Sean Neakums Cc: Linux XFS In-Reply-To: <6u666ikn5n.fsf@zork.zork.net> References: <1010141444.1992.3.camel@pyewacket> <1010164935.1945.8.camel@UberGeek> <6u666ikn5n.fsf@zork.zork.net> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/1.0.0.99+cvs.2001.12.18.08.57 (Preview Release) Date: 04 Jan 2002 12:29:59 -0600 Message-Id: <1010168999.28743.5.camel@jen.americas.sgi.com> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 1372 Lines: 44 On Fri, 2002-01-04 at 12:04, Sean Neakums wrote: > begin Austin Gonyou quotation: > > > No, It does not guarantee. Also, if you're not on the same Inode the > > file time is different, etc, it's possible to have different md5sums. A > > basic size and file comparison is probably best for what you want to do. > > The md5sum of a file is based on its contents only. The inode has > nothing to do with it. > > > Something you can do to test what I'm talking about is copy each of your > > dumps to another name, binfilexyz.1 or something, then compare it's > > md5sum against the original. Those should be the only time they match. > > I'm not sure exaclty what you mean by this. The name of the file is > irrelevant in the computation of the md5sum. A lot of binaries have generated strings put into them which are created, an example would be: cpp -E << /EOF __TIME__ /EOF # 1 "" "12:25:35" Compilers can also put strings into .o files which include the time stamp and absolute pathnames. Steve > > -- > ///////////////// | | The spark of a pin > | (require 'gnu) | dropping, falling feather-like. > \\\\\\\\\\\\\\\\\ | | There is too much noise. -- Steve Lord voice: +1-651-683-3511 Principal Engineer, Filesystem Software email: lord@sgi.com From owner-linux-xfs@oss.sgi.com Fri Jan 4 11:39:38 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g04Jdc818923 for linux-xfs-outgoing; Fri, 4 Jan 2002 11:39:38 -0800 Received: from zork.zork.net (zork.zork.net [64.81.65.8]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g04JdUg18901 for ; Fri, 4 Jan 2002 11:39:30 -0800 Received: from localhost (zork.zork.net) [127.0.0.1] by zork.zork.net with esmtp (Exim 3.33 #1 (Debian)) id 16MZFY-0006eA-00; Fri, 04 Jan 2002 10:39:28 -0800 To: Linux XFS Subject: Re: file corruption during emacs build on XFS logical volume References: <1010141444.1992.3.camel@pyewacket> <1010164935.1945.8.camel@UberGeek> <6u666ikn5n.fsf@zork.zork.net> <6usn9mj7id.fsf@zork.zork.net> From: Sean Neakums X-Message-Flag: Message text advisory: AMPHIBOLY, DENIAL OF THE ANTECEDENT X-Mailer: Norman Mail-Followup-To: Linux XFS Date: Fri, 04 Jan 2002 18:39:28 +0000 In-Reply-To: <6usn9mj7id.fsf@zork.zork.net> (Sean Neakums's message of "Fri, 04 Jan 2002 18:28:10 +0000") Message-ID: <6uofkaj6zj.fsf@zork.zork.net> User-Agent: Gnus/5.090004 (Oort Gnus v0.04) Emacs/21.1 (i386-debian-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 2973 Lines: 62 begin Sean Neakums quotation: > begin Sean Neakums quotation: > >> begin Austin Gonyou quotation: >> >>> No, It does not guarantee. Also, if you're not on the same Inode the >>> file time is different, etc, it's possible to have different md5sums. A >>> basic size and file comparison is probably best for what you want to do. >> >> The md5sum of a file is based on its contents only. The inode has >> nothing to do with it. >> >>> Something you can do to test what I'm talking about is copy each of your >>> dumps to another name, binfilexyz.1 or something, then compare it's >>> md5sum against the original. Those should be the only time they match. >> >> I'm not sure exaclty what you mean by this. The name of the file is >> irrelevant in the computation of the md5sum. > > In Emacs' case, there's a niggle with this: if there's already an > emacs-21.1.1 file there, it'll dump as emacs-21.1.2, and the dumped > file will have that version embedded in it. The script I was using to > generate the ms5sum was aware of this, and deleted the dumped files > before each dump, so that the dump always happened to the name > emacs-21.1.1. However, there is a variable, emacs-build-time, which > contains the exact time the dump occurred. So md5sums are no use anyway. > > Funnily, the last file dump I did worked correctly at the time, but is > now segfaulting, some hours later. > > I was doing the dumps while running three instances of this program, > which I hacked up in a hurry, to generate lots of dirty pages and > actual I/O: http://zork.net/~sneakums/io-test.c > > I wonder if the pages that are modified by the dump are not being > written to disk correctly? This last dump was in a D state for a few > minutes while the three io-test instances were running, but it did > complete and seemingly start up correctly a few minutes after I killed > them. I think I can finally reproduce the bogus dumps. I just did it here, three times. What I did was: run the io-test program above on two different files for approx three minutes, then start the emacs dump. When the dump completed, I started a third io-test and left the three of them run for about five or so more minutes. What I'm trying to do with all this I/O is to force the dumped binary's pages to be written to disk. So after the five minutes or so, I killed the io-test threads and attempted to start the dumped binary, which failed with a `cannot execute' message from the shell. I looked in the file, and it pure garbage: not even an "ELF" string at the start of the file. I am now going to do a build of the upstream source and see if I can make the dump break on that too. I'm hopeful that it will, as the unexec code is the same in upstream as in the Debian emacs21 package. -- ///////////////// | | The spark of a pin | (require 'gnu) | dropping, falling feather-like. \\\\\\\\\\\\\\\\\ | | There is too much noise. From owner-linux-xfs@oss.sgi.com Fri Jan 4 11:43:48 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g04Jhmr19078 for linux-xfs-outgoing; Fri, 4 Jan 2002 11:43:48 -0800 Received: from zok.sgi.com (zok.sgi.com [204.94.215.101]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g04Jhhg19050 for ; Fri, 4 Jan 2002 11:43:43 -0800 Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by zok.sgi.com (8.11.4/8.11.4/linux-outbound_gateway-1.1) with ESMTP id g04IhaA06870 for ; Fri, 4 Jan 2002 10:43:36 -0800 Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id MAA4004761; Fri, 4 Jan 2002 12:42:20 -0600 (CST) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id MAA26637; Fri, 4 Jan 2002 12:42:20 -0600 (CST) Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id g04IgBO28846; Fri, 4 Jan 2002 12:42:11 -0600 Subject: Re: file corruption during emacs build on XFS logical volume From: Steve Lord To: Sean Neakums Cc: Linux XFS In-Reply-To: <6uofkaj6zj.fsf@zork.zork.net> References: <1010141444.1992.3.camel@pyewacket> <1010164935.1945.8.camel@UberGeek> <6u666ikn5n.fsf@zork.zork.net> <6usn9mj7id.fsf@zork.zork.net> <6uofkaj6zj.fsf@zork.zork.net> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/1.0.0.99+cvs.2001.12.18.08.57 (Preview Release) Date: 04 Jan 2002 12:42:10 -0600 Message-Id: <1010169730.28743.7.camel@jen.americas.sgi.com> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 1499 Lines: 36 On Fri, 2002-01-04 at 12:39, Sean Neakums wrote: > > I think I can finally reproduce the bogus dumps. I just did it here, > three times. What I did was: run the io-test program above on two > different files for approx three minutes, then start the emacs dump. > When the dump completed, I started a third io-test and left the three > of them run for about five or so more minutes. What I'm trying to do > with all this I/O is to force the dumped binary's pages to be written > to disk. Can you expand on the 'dumps' I am not really familiar with the emacs build process, so I don't know which part of the process you are refering to here. Steve > > So after the five minutes or so, I killed the io-test threads and > attempted to start the dumped binary, which failed with a `cannot > execute' message from the shell. I looked in the file, and it pure > garbage: not even an "ELF" string at the start of the file. > > I am now going to do a build of the upstream source and see if I can > make the dump break on that too. I'm hopeful that it will, as the > unexec code is the same in upstream as in the Debian emacs21 package. > > -- > ///////////////// | | The spark of a pin > | (require 'gnu) | dropping, falling feather-like. > \\\\\\\\\\\\\\\\\ | | There is too much noise. -- Steve Lord voice: +1-651-683-3511 Principal Engineer, Filesystem Software email: lord@sgi.com From owner-linux-xfs@oss.sgi.com Fri Jan 4 11:46:21 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g04JkLk19233 for linux-xfs-outgoing; Fri, 4 Jan 2002 11:46:21 -0800 Received: from localhost.localdomain (home.brown-dog.org [207.231.66.180]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g04JkGg19211 for ; Fri, 4 Jan 2002 11:46:16 -0800 Received: (from jcoffin@localhost) by localhost.localdomain (8.11.6/8.11.2) id g04IuUd12094; Fri, 4 Jan 2002 10:56:30 -0800 X-Authentication-Warning: localhost.localdomain: jcoffin set sender to jcoffin@brown-dog.org using -f To: pac@fortuitous.com Cc: linux-xfs@oss.sgi.com Subject: Re: vmware compatiblity References: <20011011182134.A5027@bistro.marx> <20011011201458.A2899@wwweasel.geeksrus.net> <20020104122845.A8140@bistro.marx> From: Jeff Coffin Date: 04 Jan 2002 10:56:30 -0800 In-Reply-To: pac@fortuitous.com's message of "Fri, 4 Jan 2002 12:28:45 -0600" Message-ID: User-Agent: Gnus/5.0807 (Gnus v5.8.7) Emacs/20.7 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 1177 Lines: 34 pac@fortuitous.com writes: > > I'm now happily running VMWare 2.0.4 under Linux 2.4.7. So, to make this > > work first download the patch: > > > > ftp://platan.vc.cvut.cz/pub/vmware/vmmon-for-2.4.7-only.tar.gz > > Then copy it to the '/usr/local/lib/vmware/modules/source' directory. > > Next, > > run: > > cd /usr/local/lib/vmware/modules/source > > gunzip vmmon-for-2.4.7-only.tar.gz > > > > After that, make a backup of the existing 'vmmon.tar' file and copy the > > Alan, > Have you heard any reports about vmware 2.x for newer kernels? > 2.4.17+ ? > > The patch site ftp://platan.vc.cvut.cz/pub/vmware/ seems to indicate > that all is ok on 2.4.6+ if you use the vmware-ws-1455-update3.tar.gz > fix... Any gossip or news appreciated. FWIW, I was running 2.0.4-1142 with kernels 2.4.10, 2.4.14 + xfs and the preempt patch for a while without incident. I used the above patch against vmmon to and all the kernels worked for me. I also briefly ran 2.0.4 with a 2.4.17 kernel from CVS before I upgarded to 3.0.0-1455 yesterday and am now running that. The interactive response and "feel" is much improved. --jeff From owner-linux-xfs@oss.sgi.com Fri Jan 4 11:49:16 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g04JnG519411 for linux-xfs-outgoing; Fri, 4 Jan 2002 11:49:16 -0800 Received: from zork.zork.net (zork.zork.net [64.81.65.8]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g04JnBg19389 for ; Fri, 4 Jan 2002 11:49:11 -0800 Received: from localhost (zork.zork.net) [127.0.0.1] by zork.zork.net with esmtp (Exim 3.33 #1 (Debian)) id 16MZOv-0006ky-00; Fri, 04 Jan 2002 10:49:09 -0800 To: Linux XFS Subject: Re: file corruption during emacs build on XFS logical volume References: <1010141444.1992.3.camel@pyewacket> <1010164935.1945.8.camel@UberGeek> <6u666ikn5n.fsf@zork.zork.net> <6usn9mj7id.fsf@zork.zork.net> <6uofkaj6zj.fsf@zork.zork.net> <1010169730.28743.7.camel@jen.americas.sgi.com> From: Sean Neakums X-Message-Flag: Message text advisory: GROSS INDECENCY, GRAVE ILL-JUDGEMENT X-Mailer: Norman Mail-Followup-To: Linux XFS Date: Fri, 04 Jan 2002 18:49:09 +0000 In-Reply-To: <1010169730.28743.7.camel@jen.americas.sgi.com> (Steve Lord's message of "04 Jan 2002 12:42:10 -0600") Message-ID: <6uk7uyj6je.fsf@zork.zork.net> User-Agent: Gnus/5.090004 (Oort Gnus v0.04) Emacs/21.1 (i386-debian-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 1835 Lines: 41 begin Steve Lord quotation: > On Fri, 2002-01-04 at 12:39, Sean Neakums wrote: > >> >> I think I can finally reproduce the bogus dumps. I just did it here, >> three times. What I did was: run the io-test program above on two >> different files for approx three minutes, then start the emacs dump. >> When the dump completed, I started a third io-test and left the three >> of them run for about five or so more minutes. What I'm trying to do >> with all this I/O is to force the dumped binary's pages to be written >> to disk. > > Can you expand on the 'dumps' I am not really familiar with the > emacs build process, so I don't know which part of the process > you are refering to here. Of course, my bad. An Emacs binary contains a bunch of C code making up the Lisp interpeter and primitive functions (subrs) and a .data section that contains pre-loaded Lisp code. I think they get the Lisp code into the .data section by allocating a large array and using it as Lisp storage. The idea is for the code that is used to implement basic editor functionality to be present as soon as the binary is execed. It's handled by copying out the constituents of the binary from core to a fresh file. On Linux, this is handled by the code in src/unexelf.c. The comments seems to describe the process fairly thoroughly; much of the detail is beyond me. If you have a tree in which you've already built Emacs, doing a dump is very straighforward: $ cd src $ LC_ALL=C ./temacs -batch -l loadup dump You'll get a bunch of messages about Lisp files being loaded, and then it will tell you to which files it has dumped the emacs. -- ///////////////// | | The spark of a pin | (require 'gnu) | dropping, falling feather-like. \\\\\\\\\\\\\\\\\ | | There is too much noise. From owner-linux-xfs@oss.sgi.com Fri Jan 4 11:54:36 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g04JsaG19592 for linux-xfs-outgoing; Fri, 4 Jan 2002 11:54:36 -0800 Received: from zork.zork.net (zork.zork.net [64.81.65.8]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g04JsWg19570 for ; Fri, 4 Jan 2002 11:54:33 -0800 Received: from localhost (zork.zork.net) [127.0.0.1] by zork.zork.net with esmtp (Exim 3.33 #1 (Debian)) id 16MZU6-0006wo-00; Fri, 04 Jan 2002 10:54:30 -0800 To: Linux XFS Subject: Re: file corruption during emacs build on XFS logical volume References: <1010141444.1992.3.camel@pyewacket> <1010164935.1945.8.camel@UberGeek> <6u666ikn5n.fsf@zork.zork.net> <6usn9mj7id.fsf@zork.zork.net> <6uofkaj6zj.fsf@zork.zork.net> From: Sean Neakums X-Message-Flag: Message text advisory: HACKING, EXCRETORY SPEECH X-Mailer: Norman Mail-Followup-To: Linux XFS Date: Fri, 04 Jan 2002 18:54:30 +0000 In-Reply-To: <6uofkaj6zj.fsf@zork.zork.net> (Sean Neakums's message of "Fri, 04 Jan 2002 18:39:28 +0000") Message-ID: <6ug05mj6ah.fsf@zork.zork.net> User-Agent: Gnus/5.090004 (Oort Gnus v0.04) Emacs/21.1 (i386-debian-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 536 Lines: 14 begin Sean Neakums quotation: > I am now going to do a build of the upstream source and see if I can > make the dump break on that too. I'm hopeful that it will, as the > unexec code is the same in upstream as in the Debian emacs21 > package. Yep, I just got me a dumped emacs binary full of NULs with the original GNU source. -- ///////////////// | | The spark of a pin | (require 'gnu) | dropping, falling feather-like. \\\\\\\\\\\\\\\\\ | | There is too much noise. From owner-linux-xfs@oss.sgi.com Fri Jan 4 12:53:31 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g04KrVT21801 for linux-xfs-outgoing; Fri, 4 Jan 2002 12:53:31 -0800 Received: from deliverator.sgi.com (deliverator.sgi.com [204.94.214.10]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g04KrQg21779 for ; Fri, 4 Jan 2002 12:53:26 -0800 Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id LAA03572 for ; Fri, 4 Jan 2002 11:53:08 -0800 (PST) mail_from (sandeen@sgi.com) Received: from poppy-e185.americas.sgi.com (poppy-e185.americas.sgi.com [128.162.185.207]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id NAA3977199; Fri, 4 Jan 2002 13:52:06 -0600 (CST) Received: from stout.americas.sgi.com (stout.americas.sgi.com [128.162.187.5]) by poppy-e185.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.7) with ESMTP id NAA74967; Fri, 4 Jan 2002 13:52:06 -0600 (CST) Subject: Re: Unable to get XFS, ext3, reiserfs & LVM to coexist happily From: Eric Sandeen To: Adrian Head Cc: Linux XFS Mailing List , linux-lvm@sistina.com In-Reply-To: <200201020451.g024pPg00867@oss.sgi.com> References: <200201020451.g024pPg00867@oss.sgi.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/1.0 (Preview Release) Date: 04 Jan 2002 13:52:05 -0600 Message-Id: <1010173926.1414.12.camel@stout.americas.sgi.com> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 1101 Lines: 35 Ok, I have 2.4.17-xfs (cvs checkout today) with patches from lvm-1.0.1, applied lvm-1.0.1-2.4.17-xfs.patch then linux-2.4.11-VFS-lock.patch. I tried creating lvm volumes & snapshots w/ an xfs filesystem. I did run into problems (creating snapshot against my "test" volume while it was mounted caused an oops; creating snapshot volume then mounting test oopsed....) but eventually I got a volume mounted, and had a snapshot volume against it. Overflowing the snapshot behaved well: lvm -- giving up to snapshot /dev/test/foo on /dev/test/snap: out of space I'll check out the oopses to see if I can figure out what's going on. -Eric On Tue, 2002-01-01 at 21:51, Adrian Head wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Hope everyone had a happy new year :-) > > I'm starting to play around with LVM with the goal of having XFS, ext3, > reiserfs and LVM coexist nicely together. > > Has anyone been able to get , ext3, reiserfs, XFS and LVM running nicely > together? -- Eric Sandeen XFS for Linux http://oss.sgi.com/projects/xfs sandeen@sgi.com SGI, Inc. From owner-linux-xfs@oss.sgi.com Fri Jan 4 13:09:28 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g04L9S922456 for linux-xfs-outgoing; Fri, 4 Jan 2002 13:09:28 -0800 Received: from pneumatic-tube.sgi.com (pneumatic-tube.sgi.com [204.94.214.22]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g04L9Ng22434 for ; Fri, 4 Jan 2002 13:09:23 -0800 Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id MAA01455 for ; Fri, 4 Jan 2002 12:09:55 -0800 (PST) mail_from (lord@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id OAA3980571; Fri, 4 Jan 2002 14:08:02 -0600 (CST) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id OAA34306; Fri, 4 Jan 2002 14:08:01 -0600 (CST) Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id g04K7pW30086; Fri, 4 Jan 2002 14:07:51 -0600 Subject: Re: file corruption during emacs build on XFS logical volume From: Steve Lord To: Sean Neakums Cc: Linux XFS In-Reply-To: <6ug05mj6ah.fsf@zork.zork.net> References: <1010141444.1992.3.camel@pyewacket> <1010164935.1945.8.camel@UberGeek> <6u666ikn5n.fsf@zork.zork.net> <6usn9mj7id.fsf@zork.zork.net> <6uofkaj6zj.fsf@zork.zork.net> <6ug05mj6ah.fsf@zork.zork.net> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/1.0.0.99+cvs.2001.12.18.08.57 (Preview Release) Date: 04 Jan 2002 14:07:51 -0600 Message-Id: <1010174871.30053.6.camel@jen.americas.sgi.com> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 875 Lines: 27 On Fri, 2002-01-04 at 12:54, Sean Neakums wrote: > begin Sean Neakums quotation: > > > I am now going to do a build of the upstream source and see if I can > > make the dump break on that too. I'm hopeful that it will, as the > > unexec code is the same in upstream as in the Debian emacs21 > > package. > > Yep, I just got me a dumped emacs binary full of NULs with the > original GNU source. OK, bingo, I can replicate this now, I too have a bad binary, it looks like the memory is getting reclaimed without getting flushed out to disk - which is not good at all. This actually gives me something to go on, hopefully it won't take too long to find now. Thanks for your persistance in generating a test case here. Steve -- Steve Lord voice: +1-651-683-3511 Principal Engineer, Filesystem Software email: lord@sgi.com From owner-linux-xfs@oss.sgi.com Fri Jan 4 13:26:38 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g04LQcW22764 for linux-xfs-outgoing; Fri, 4 Jan 2002 13:26:38 -0800 Received: from smtpzilla3.xs4all.nl (smtpzilla3.xs4all.nl [194.109.127.139]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g04LQWg22742 for ; Fri, 4 Jan 2002 13:26:33 -0800 Received: from auto-nb1.xs4all.nl (qn-212-58-167-191.quicknet.nl [212.58.167.191]) by smtpzilla3.xs4all.nl (8.12.0/8.12.0) with ESMTP id g04KQQmR052627; Fri, 4 Jan 2002 21:26:26 +0100 (CET) Message-Id: <4.3.2.7.2.20020104212504.03ca1ab0@pop.xs4all.nl> X-Sender: knuffie@pop.xs4all.nl X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 04 Jan 2002 21:26:06 +0100 To: Steve Lord , Sean Neakums From: Seth Mos Subject: Re: file corruption during emacs build on XFS logical volume Cc: Linux XFS In-Reply-To: <1010174871.30053.6.camel@jen.americas.sgi.com> References: <6ug05mj6ah.fsf@zork.zork.net> <1010141444.1992.3.camel@pyewacket> <1010164935.1945.8.camel@UberGeek> <6u666ikn5n.fsf@zork.zork.net> <6usn9mj7id.fsf@zork.zork.net> <6uofkaj6zj.fsf@zork.zork.net> <6ug05mj6ah.fsf@zork.zork.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 1056 Lines: 33 At 14:07 4-1-2002 -0600, Steve Lord wrote: >On Fri, 2002-01-04 at 12:54, Sean Neakums wrote: > > begin Sean Neakums quotation: > > > > > I am now going to do a build of the upstream source and see if I can > > > make the dump break on that too. I'm hopeful that it will, as the > > > unexec code is the same in upstream as in the Debian emacs21 > > > package. > > > > Yep, I just got me a dumped emacs binary full of NULs with the > > original GNU source. > >OK, bingo, I can replicate this now, I too have a bad binary, it looks >like the memory is getting reclaimed without getting flushed out to >disk - which is not good at all. > >This actually gives me something to go on, hopefully it won't take too >long to find now. Thanks for your persistance in generating a test >case here. This might explain the fs corruption that some other people saw as well on 2.4.17-xfs. I can't remember who it was, i'll look it up. Cheers -- Seth Every program has two purposes one for which it was written and another for which it wasn't I use the last kind. From owner-linux-xfs@oss.sgi.com Fri Jan 4 13:30:47 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g04LUll22927 for linux-xfs-outgoing; Fri, 4 Jan 2002 13:30:47 -0800 Received: from UberGeek.coremetrics.com ([209.184.141.163]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g04LUag22903 for ; Fri, 4 Jan 2002 13:30:36 -0800 Received: (from austin@localhost) by UberGeek.coremetrics.com (8.11.6/8.11.6) id g04KTrm02987; Fri, 4 Jan 2002 14:29:53 -0600 X-Authentication-Warning: UberGeek.coremetrics.com: austin set sender to austin@coremetrics.com using -f Subject: Re: file corruption during emacs build on XFS logical volume From: Austin Gonyou To: Steve Lord Cc: Sean Neakums , Linux XFS In-Reply-To: <1010174871.30053.6.camel@jen.americas.sgi.com> References: <1010174871.30053.6.camel@jen.americas.sgi.com> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-o6QU+/pKf99HLAvQE+9F" X-Mailer: Evolution/1.0.0.99+cvs.2001.12.18.08.57 (Preview Release) Date: 04 Jan 2002 14:29:53 -0600 Message-Id: <1010176193.2938.14.camel@UberGeek> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 1750 Lines: 58 --=-o6QU+/pKf99HLAvQE+9F Content-Type: text/plain Content-Transfer-Encoding: quoted-printable What is the affected version with this? 2.4.17 or all? On Fri, 2002-01-04 at 14:07, Steve Lord wrote: > On Fri, 2002-01-04 at 12:54, Sean Neakums wrote: > > begin Sean Neakums quotation: > >=20 > > > I am now going to do a build of the upstream source and see if I can > > > make the dump break on that too. I'm hopeful that it will, as the > > > unexec code is the same in upstream as in the Debian emacs21 > > > package. > >=20 > > Yep, I just got me a dumped emacs binary full of NULs with the > > original GNU source. >=20 > OK, bingo, I can replicate this now, I too have a bad binary, it looks > like the memory is getting reclaimed without getting flushed out to > disk - which is not good at all. >=20 > This actually gives me something to go on, hopefully it won't take too > long to find now. Thanks for your persistance in generating a test > case here. >=20 > Steve >=20 >=20 > --=20 >=20 > Steve Lord voice: +1-651-683-3511 > Principal Engineer, Filesystem Software email: lord@sgi.com --=20 Austin Gonyou Systems Architect, CCNA Coremetrics, Inc. Phone: 512-698-7250 email: austin@coremetrics.com "It is the part of a good shepherd to shear his flock, not to skin it." Latin Proverb --=-o6QU+/pKf99HLAvQE+9F Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQA8NhDB94g6ZVmFMoIRAs3xAKCzyN2HwfdDa58/p7oLXmr7czIGxwCfTXKp iR+ki6IYq0QmIrkcklNXs4U= =rUqq -----END PGP SIGNATURE----- --=-o6QU+/pKf99HLAvQE+9F-- From owner-linux-xfs@oss.sgi.com Fri Jan 4 13:34:07 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g04LY7N23095 for linux-xfs-outgoing; Fri, 4 Jan 2002 13:34:07 -0800 Received: from zork.zork.net (zork.zork.net [64.81.65.8]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g04LY4g23072 for ; Fri, 4 Jan 2002 13:34:04 -0800 Received: from localhost (zork.zork.net) [127.0.0.1] by zork.zork.net with esmtp (Exim 3.33 #1 (Debian)) id 16Mb2Q-0000df-00; Fri, 04 Jan 2002 12:34:02 -0800 To: Linux XFS Subject: Re: file corruption during emacs build on XFS logical volume References: <1010174871.30053.6.camel@jen.americas.sgi.com> <1010176193.2938.14.camel@UberGeek> From: Sean Neakums X-Message-Flag: Message text advisory: DENIAL OF THE ANTECEDENT, ARGUMENTUM AD BACULUM X-Mailer: Norman Mail-Followup-To: Linux XFS Date: Fri, 04 Jan 2002 20:34:02 +0000 In-Reply-To: <1010176193.2938.14.camel@UberGeek> (Austin Gonyou's message of "04 Jan 2002 14:29:53 -0600") Message-ID: <6upu4pj1ol.fsf@zork.zork.net> User-Agent: Gnus/5.090004 (Oort Gnus v0.04) Emacs/21.1 (i386-debian-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 578 Lines: 14 begin Austin Gonyou quotation: > What is the affected version with this? 2.4.17 or all? I had the Emacs build failures on my 2.4.16 CVS pull, too. I haven't tried to reproduce on 2.4.16 with io-test.c and the manual Emacs dump. I haven't had the Emacs build failures on my 2.4.14-pre7 CVS pull. I haven't tried the io-test.c/manual dump scenario there either, though. -- ///////////////// | | The spark of a pin | (require 'gnu) | dropping, falling feather-like. \\\\\\\\\\\\\\\\\ | | There is too much noise. From owner-linux-xfs@oss.sgi.com Fri Jan 4 13:34:54 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g04LYsm23233 for linux-xfs-outgoing; Fri, 4 Jan 2002 13:34:54 -0800 Received: from yog-sothoth.sgi.com (eugate.sgi.com [192.48.160.10]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g04LYkg23210 for ; Fri, 4 Jan 2002 13:34:47 -0800 Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by yog-sothoth.sgi.com (980305.SGI.8.8.8-aspam-6.2/980304.SGI-aspam-europe) via ESMTP id VAA1222973 for ; Fri, 4 Jan 2002 21:33:30 +0100 (CET) mail_from (lord@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id OAA4007586; Fri, 4 Jan 2002 14:33:24 -0600 (CST) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id OAA18901; Fri, 4 Jan 2002 14:33:24 -0600 (CST) Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id g04KXDk30911; Fri, 4 Jan 2002 14:33:13 -0600 Subject: Re: file corruption during emacs build on XFS logical volume From: Steve Lord To: Austin Gonyou Cc: Sean Neakums , Linux XFS In-Reply-To: <1010176193.2938.14.camel@UberGeek> References: <1010174871.30053.6.camel@jen.americas.sgi.com> <1010176193.2938.14.camel@UberGeek> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/1.0.0.99+cvs.2001.12.18.08.57 (Preview Release) Date: 04 Jan 2002 14:33:13 -0600 Message-Id: <1010176393.30037.9.camel@jen.americas.sgi.com> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 1677 Lines: 52 On Fri, 2002-01-04 at 14:29, Austin Gonyou wrote: > What is the affected version with this? 2.4.17 or all? Well I hit it in 2.5.2-pre7, but I suspect it goes back into 2.4.16 at least. I may have made a mistake in the changes which went in to fix various things during 2.4.16. Steve > > On Fri, 2002-01-04 at 14:07, Steve Lord wrote: > > On Fri, 2002-01-04 at 12:54, Sean Neakums wrote: > > > begin Sean Neakums quotation: > > > > > > > I am now going to do a build of the upstream source and see if I can > > > > make the dump break on that too. I'm hopeful that it will, as the > > > > unexec code is the same in upstream as in the Debian emacs21 > > > > package. > > > > > > Yep, I just got me a dumped emacs binary full of NULs with the > > > original GNU source. > > > > OK, bingo, I can replicate this now, I too have a bad binary, it looks > > like the memory is getting reclaimed without getting flushed out to > > disk - which is not good at all. > > > > This actually gives me something to go on, hopefully it won't take too > > long to find now. Thanks for your persistance in generating a test > > case here. > > > > Steve > > > > > > -- > > > > Steve Lord voice: +1-651-683-3511 > > Principal Engineer, Filesystem Software email: lord@sgi.com > -- > Austin Gonyou > Systems Architect, CCNA > Coremetrics, Inc. > Phone: 512-698-7250 > email: austin@coremetrics.com > > "It is the part of a good shepherd to shear his flock, not to skin it." > Latin Proverb -- Steve Lord voice: +1-651-683-3511 Principal Engineer, Filesystem Software email: lord@sgi.com From owner-linux-xfs@oss.sgi.com Fri Jan 4 13:35:05 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g04LZ5T23355 for linux-xfs-outgoing; Fri, 4 Jan 2002 13:35:05 -0800 Received: from penguin.truevibe.net (IDENT:root@[64.71.181.116]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g04LZ2g23333 for ; Fri, 4 Jan 2002 13:35:02 -0800 Received: from imageevent.com (12-234-199-68.client.attbi.com [12.234.199.68]) by penguin.truevibe.net (8.9.3/8.8.7) with ESMTP id MAA25115 for ; Fri, 4 Jan 2002 12:44:39 -0800 Message-ID: <3C3611F3.8457919E@imageevent.com> Date: Fri, 04 Jan 2002 12:34:59 -0800 From: Jay Vasa X-Mailer: Mozilla 4.76 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: linux-xfs@oss.sgi.com Subject: kernel Makefile prob with tulip Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 366 Lines: 20 The Tulip network driver will not compile in the kernel source I downloaded at: linux-2.4.9-13SGI_XFS_1.0.2 drivers/net/Makefile It should be changed from: ifeq ($(CONFIG_TULIP),y) obj-y += tulip/tulip.o tulip_old/tulip_old.o endi ifeq ($(CONFIG_TULIP),y) obj-y += tulip/tulip.o endi You will get errors compiling of "multiple defines" all over. Thanks, Jay From owner-linux-xfs@oss.sgi.com Fri Jan 4 13:35:28 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g04LZSN23485 for linux-xfs-outgoing; Fri, 4 Jan 2002 13:35:28 -0800 Received: from yog-sothoth.sgi.com (eugate.sgi.com [192.48.160.10]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g04LZPg23463 for ; Fri, 4 Jan 2002 13:35:25 -0800 Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by yog-sothoth.sgi.com (980305.SGI.8.8.8-aspam-6.2/980304.SGI-aspam-europe) via ESMTP id VAA1227633 for ; Fri, 4 Jan 2002 21:34:08 +0100 (CET) mail_from (sandeen@sgi.com) Received: from poppy-e185.americas.sgi.com (poppy-e185.americas.sgi.com [128.162.185.207]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id OAA4009947; Fri, 4 Jan 2002 14:34:03 -0600 (CST) Received: from stout.americas.sgi.com (stout.americas.sgi.com [128.162.187.5]) by poppy-e185.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.7) with ESMTP id OAA77002; Fri, 4 Jan 2002 14:34:03 -0600 (CST) Subject: Re: file corruption during emacs build on XFS logical volume From: Eric Sandeen To: Austin Gonyou Cc: Steve Lord , Sean Neakums , Linux XFS In-Reply-To: <1010176193.2938.14.camel@UberGeek> References: <1010174871.30053.6.camel@jen.americas.sgi.com> <1010176193.2938.14.camel@UberGeek> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/1.0 (Preview Release) Date: 04 Jan 2002 14:34:03 -0600 Message-Id: <1010176443.1414.14.camel@stout.americas.sgi.com> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 356 Lines: 12 On Fri, 2002-01-04 at 14:29, Austin Gonyou wrote: > What is the affected version with this? 2.4.17 or all? Sean said that 2.4.14 did not seem to be affected; it may be that a bug got pushed somewhere since then and popped out somewhere else. :) -Eric -- Eric Sandeen XFS for Linux http://oss.sgi.com/projects/xfs sandeen@sgi.com SGI, Inc. From owner-linux-xfs@oss.sgi.com Fri Jan 4 14:00:52 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g04M0qb24561 for linux-xfs-outgoing; Fri, 4 Jan 2002 14:00:52 -0800 Received: from yog-sothoth.sgi.com (eugate.sgi.com [192.48.160.10]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g04M0kg24534 for ; Fri, 4 Jan 2002 14:00:46 -0800 Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by yog-sothoth.sgi.com (980305.SGI.8.8.8-aspam-6.2/980304.SGI-aspam-europe) via ESMTP id VAA1215981 for ; Fri, 4 Jan 2002 21:59:28 +0100 (CET) mail_from (sandeen@sgi.com) Received: from poppy-e185.americas.sgi.com (poppy-e185.americas.sgi.com [128.162.185.207]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id OAA3993014; Fri, 4 Jan 2002 14:59:24 -0600 (CST) Received: from stout.americas.sgi.com (stout.americas.sgi.com [128.162.187.5]) by poppy-e185.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.7) with ESMTP id OAA78722; Fri, 4 Jan 2002 14:59:23 -0600 (CST) Subject: Re: kernel Makefile prob with tulip From: Eric Sandeen To: Jay Vasa Cc: linux-xfs@oss.sgi.com In-Reply-To: <3C3611F3.8457919E@imageevent.com> References: <3C3611F3.8457919E@imageevent.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/1.0 (Preview Release) Date: 04 Jan 2002 14:59:23 -0600 Message-Id: <1010177964.2576.16.camel@stout.americas.sgi.com> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 738 Lines: 33 hi Jay - Thanks, looks like this got inherited from Red Hat. Interesting that it didn't cause problems with our RPM kernel builds, though, since we do build the tulip module...? -Eric On Fri, 2002-01-04 at 14:34, Jay Vasa wrote: > The Tulip network driver will not compile in the kernel source I > downloaded at: > linux-2.4.9-13SGI_XFS_1.0.2 > > drivers/net/Makefile > > It should be changed from: > ifeq ($(CONFIG_TULIP),y) > obj-y += tulip/tulip.o tulip_old/tulip_old.o > endi > > ifeq ($(CONFIG_TULIP),y) > obj-y += tulip/tulip.o > endi > > You will get errors compiling of "multiple defines" all over. > > Thanks, > Jay -- Eric Sandeen XFS for Linux http://oss.sgi.com/projects/xfs sandeen@sgi.com SGI, Inc. From owner-linux-xfs@oss.sgi.com Fri Jan 4 14:30:00 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g04MU0f25089 for linux-xfs-outgoing; Fri, 4 Jan 2002 14:30:00 -0800 Received: from rj.sgi.com (rj.sgi.com [204.94.215.100]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g04MTtg25065 for ; Fri, 4 Jan 2002 14:29:56 -0800 Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by rj.sgi.com (8.11.4/8.11.4/linux-outbound_gateway-1.1) with ESMTP id g04LTlY05532 for ; Fri, 4 Jan 2002 13:29:47 -0800 Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id PAA4002430; Fri, 4 Jan 2002 15:28:31 -0600 (CST) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id PAA33497; Fri, 4 Jan 2002 15:28:31 -0600 (CST) Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id g04LSKH04747; Fri, 4 Jan 2002 15:28:20 -0600 Subject: Re: file corruption during emacs build on XFS logical volume From: Steve Lord To: Steve Lord Cc: Austin Gonyou , Sean Neakums , Linux XFS In-Reply-To: <1010176393.30037.9.camel@jen.americas.sgi.com> References: <1010174871.30053.6.camel@jen.americas.sgi.com> <1010176193.2938.14.camel@UberGeek> <1010176393.30037.9.camel@jen.americas.sgi.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/1.0.0.99+cvs.2001.12.18.08.57 (Preview Release) Date: 04 Jan 2002 15:28:20 -0600 Message-Id: <1010179700.30053.13.camel@jen.americas.sgi.com> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 760 Lines: 23 On Fri, 2002-01-04 at 14:33, Steve Lord wrote: > On Fri, 2002-01-04 at 14:29, Austin Gonyou wrote: > > What is the affected version with this? 2.4.17 or all? > > Well I hit it in 2.5.2-pre7, but I suspect it goes back into 2.4.16 > at least. I may have made a mistake in the changes which went in > to fix various things during 2.4.16. > > Steve > It looks like the problem was introduced sometime after the original split patches for 2.4.16 were put out on Dec 3rd. So it is either related to something in the fixes for dbench on low memory systems, or something missed in the 2.4.17 and 2.5.2 merges. Steve -- Steve Lord voice: +1-651-683-3511 Principal Engineer, Filesystem Software email: lord@sgi.com From owner-linux-xfs@oss.sgi.com Fri Jan 4 14:30:28 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g04MUSE25232 for linux-xfs-outgoing; Fri, 4 Jan 2002 14:30:28 -0800 Received: from c144417-a.mntp1.il.home.com (12-248-156-110.client.attbi.com [12.248.156.110]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g04MUMg25206 for ; Fri, 4 Jan 2002 14:30:23 -0800 Received: (qmail 29027 invoked by uid 500); 4 Jan 2002 21:34:00 -0000 Date: Fri, 4 Jan 2002 15:34:00 -0600 (CST) From: Brian Johnson X-X-Sender: To: Linux XFS Subject: Quota block usage out of date until sync Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 1229 Lines: 42 I noticed the block usage amount repquota reports is out of date for about 40 sec after a file is written or until sync is run. For example, # /usr/sbin/repquota /users | grep root ;\ dd count=1024 bs=1024 if=/dev/zero of=writetest ;\ /usr/sbin/repquota /users | grep root ;\ sleep 30 ;\ /usr/sbin/repquota /users | grep root ;\ sleep 10 ;\ /usr/sbin/repquota /users | grep root Produces: root -- 6176 0 0 19 0 0 1024+0 records in 1024+0 records out root -- 6176 0 0 20 0 0 root -- 6176 0 0 20 0 0 root -- 7200 0 0 20 0 0 Running sync after the write gives up to date usage data: # /usr/sbin/repquota /users | grep root ;\ dd count=1024 bs=1024 if=/dev/zero of=writetest2 ;\ sync ;\ /usr/sbin/repquota /users | grep root root -- 7200 0 0 20 0 0 1024+0 records in 1024+0 records out root -- 8224 0 0 21 0 0 Is there a way to get the number of used blocks that is not out of date? I am running kernel 2.4.17 from CVS and also have tested this on the 1.0.2a release. Thanks, Brian From owner-linux-xfs@oss.sgi.com Fri Jan 4 14:45:48 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g04MjmU25450 for linux-xfs-outgoing; Fri, 4 Jan 2002 14:45:48 -0800 Received: from burgers.bubbanfriends.org (IDENT:postfix@burgers.bubbanfriends.org [216.140.122.113]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g04Mjfg25428 for ; Fri, 4 Jan 2002 14:45:41 -0800 Received: by burgers.bubbanfriends.org (Postfix, from userid 500) id 56090400E1E; Fri, 4 Jan 2002 16:45:45 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by burgers.bubbanfriends.org (Postfix) with ESMTP id 503B02400234; Fri, 4 Jan 2002 16:45:45 -0500 (EST) Date: Fri, 4 Jan 2002 16:45:45 -0500 (EST) From: Mike Burger To: Brian Johnson Cc: Linux XFS Subject: Re: Quota block usage out of date until sync In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 1768 Lines: 55 To me, this makes perfect sense. You can't really get the used block count to change until the blocks have actually been written, and teh allocation tables written along with them. It seems to me, and I'm not involved in any way with the development project, that you'd be asking for a lot of trouble to try to update part of the allocation table without actually having had the data written to disk. On Fri, 4 Jan 2002, Brian Johnson wrote: > I noticed the block usage amount repquota reports is out of date for about > 40 sec after a file is written or until sync is run. > > For example, > # /usr/sbin/repquota /users | grep root ;\ > dd count=1024 bs=1024 if=/dev/zero of=writetest ;\ > /usr/sbin/repquota /users | grep root ;\ > sleep 30 ;\ > /usr/sbin/repquota /users | grep root ;\ > sleep 10 ;\ > /usr/sbin/repquota /users | grep root > > Produces: > > root -- 6176 0 0 19 0 0 > 1024+0 records in > 1024+0 records out > root -- 6176 0 0 20 0 0 > root -- 6176 0 0 20 0 0 > root -- 7200 0 0 20 0 0 > > > Running sync after the write gives up to date usage data: > > # /usr/sbin/repquota /users | grep root ;\ > dd count=1024 bs=1024 if=/dev/zero of=writetest2 ;\ > sync ;\ > /usr/sbin/repquota /users | grep root > > root -- 7200 0 0 20 0 0 > 1024+0 records in > 1024+0 records out > root -- 8224 0 0 21 0 0 > > > Is there a way to get the number of used blocks that is not out of date? I > am running kernel 2.4.17 from CVS and also have tested this on the 1.0.2a > release. > > Thanks, > Brian > > From owner-linux-xfs@oss.sgi.com Fri Jan 4 15:34:57 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g04NYvM26078 for linux-xfs-outgoing; Fri, 4 Jan 2002 15:34:57 -0800 Received: from beaver.iucha.org (mplsdslgw14poolA71.mpls.uswest.net [63.229.192.71]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g04NYog26054 for ; Fri, 4 Jan 2002 15:34:50 -0800 Received: by beaver.iucha.org (Postfix, from userid 1000) id D61EE2D69; Fri, 4 Jan 2002 16:34:40 -0600 (CST) Date: Fri, 4 Jan 2002 16:34:38 -0600 From: Florin Iucha To: linux-xfs@oss.sgi.com Subject: TAKE - Sync kdb v2.0-2.4.17 i386 code with xfs Message-ID: <20020104163438.A30706@iucha.net> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-md5; protocol="application/pgp-signature"; boundary="gKMricLos+KVdGMg" Content-Disposition: inline User-Agent: Mutt/1.2.5i Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 1108 Lines: 43 --gKMricLos+KVdGMg Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable I have checked out latest linux-2.4-xfs branch and copied my old .config from the same box and ran make oldconfig. I was prompted as expected for "PAGEBUF" and "XFS", but not for kdb. When compiling, however, compiling kdb failed. I went into "Kernel Haking" and enabled "Kernel Hacking" and disabled kdb. So: 1. Why was kdb enabled without prompting me? 2. Why do I need to enable kernel hacking in orderto be able to disable kdb? 0. kdb doesn't compile Machine is a PPro/200 running Debian Unstable. Thank you, florin --=20 "If it's not broken, let's fix it till it is." 41A9 2BDE 8E11 F1C5 87A6 03EE 34B3 E075 3B90 DFE4 --gKMricLos+KVdGMg Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.4 (OpenBSD) Comment: For info see http://www.gnupg.org iD8DBQE8Ni39NLPgdTuQ3+QRAvfLAJ9thK3LH4s1HrGVO3Ype3ihjolxuQCghEuv x1ZdRWcyr0kcD6Kw+POxzmk= =5Rff -----END PGP SIGNATURE----- --gKMricLos+KVdGMg-- From owner-linux-xfs@oss.sgi.com Fri Jan 4 15:49:45 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g04Nnjs26342 for linux-xfs-outgoing; Fri, 4 Jan 2002 15:49:45 -0800 Received: from mta03ps.bigpond.com (mta03ps.bigpond.com [144.135.25.135]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g04Nnag26320 for ; Fri, 4 Jan 2002 15:49:36 -0800 Message-Id: <200201042349.g04Nnag26320@oss.sgi.com> Received: from there ([144.135.25.87]) by mta03ps.bigpond.com (Netscape Messaging Server 4.15) with SMTP id GPFRQ200.5YA; Sat, 5 Jan 2002 08:56:26 +1000 Received: from CPE-144-137-138-230.qld.bigpond.net.au ([144.137.138.230]) by psmam07.mailsvc.email.bigpond.com(MailRouter V3.0h 125/3764757); 05 Jan 2002 08:49:26 Content-Type: text/plain; charset="us-ascii" From: Adrian Head To: Eric Sandeen Subject: Re: Unable to get XFS, ext3, reiserfs & LVM to coexist happily Date: Sat, 5 Jan 2002 08:49:22 +1000 X-Mailer: KMail [version 1.3.1] Cc: Linux XFS Mailing List , linux-lvm@sistina.com References: <200201020451.g024pPg00867@oss.sgi.com> <1010173926.1414.12.camel@stout.americas.sgi.com> In-Reply-To: <1010173926.1414.12.camel@stout.americas.sgi.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 2400 Lines: 78 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Sat, 5 Jan 2002 05:52, Eric Sandeen wrote: > Ok, I have 2.4.17-xfs (cvs checkout today) with patches from lvm-1.0.1, > applied lvm-1.0.1-2.4.17-xfs.patch then linux-2.4.11-VFS-lock.patch. > > I tried creating lvm volumes & snapshots w/ an xfs filesystem. > > I did run into problems (creating snapshot against my "test" volume > while it was mounted caused an oops; creating snapshot volume then > mounting test oopsed....) but eventually I got a volume mounted, and had > a snapshot volume against it. > > Overflowing the snapshot behaved well: > > lvm -- giving up to snapshot /dev/test/foo on /dev/test/snap: out of > space > > I'll check out the oopses to see if I can figure out what's going on. > > -Eric Well this seems consistant with what I'm seeing: 2.4.17-xfs While source volume mounted: + lvm-1.0.1 upgrade + VFS-lock (In that order) * Can create ext3 snapshot? | yes * Can mount a ext3 snapshot? | yes * Can create resierfs snapshot? | yes * Can mount a resierfs snapshot? | yes * Can create xfs snapshot? | Oops btp 1234 (lvcreate) journal_start ext3_dirty_inode __mark_inode_dirty update_atime do_generic_file_read generic_file_read sys_read system_call Running processes (lvcreate) * Can mount a xfs snapshot? | Cannot test When source & snapshot mounted: * Cause oops when snapshot overflows? | - ext3 | OK - Stable - resierfs | OK - Stable - xfs | Cannot test What does your backtrace look like? Its the ext3_dirt_inode in my backtrace thats got me. I have compiled a kernel without ext3 so will also give it a run later. I now have a serial cable and once I work out how to use kdb with it I'll be able to capture the full kdb output.. I was wanting to be in this position now; but ran into an issue with the Linux kernel which killed a lot of time.. OT: There is an option in the linux kernel config that allows extra debugging info to be compled into the kernel. Don't use it as it stops all modules from being loaded. It took me a couple of hours to realise what was happening :-( - -- Adrian Head (Public Key available on request.) -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE8NjF18ZJI8OvSkAcRAiFHAJ9oHz9ntOT+pNatBj3SxTMqw0je1gCfasWm 8zvETAseafRuSEpOaAFQkuE= =+BBG -----END PGP SIGNATURE----- From owner-linux-xfs@oss.sgi.com Fri Jan 4 16:04:57 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0504v826656 for linux-xfs-outgoing; Fri, 4 Jan 2002 16:04:57 -0800 Received: from beaver.iucha.org (mplsdslgw14poolA71.mpls.uswest.net [63.229.192.71]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0504mg26631 for ; Fri, 4 Jan 2002 16:04:48 -0800 Received: by beaver.iucha.org (Postfix, from userid 1000) id 3B5912D69; Fri, 4 Jan 2002 17:04:22 -0600 (CST) Date: Fri, 4 Jan 2002 17:04:19 -0600 From: Florin Iucha To: linux-xfs@oss.sgi.com Cc: kaos@sherman.melbourne.sgi.com Subject: Fwd: TAKE - Sync kdb v2.0-2.4.17 i386 code with xfs Message-ID: <20020104170418.B30706@iucha.net> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-md5; protocol="application/pgp-signature"; boundary="1LKvkjL3sHcu1TtY" Content-Disposition: inline User-Agent: Mutt/1.2.5i Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 1920 Lines: 63 --1LKvkjL3sHcu1TtY Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable > I have checked out latest linux-2.4-xfs branch and copied my old .config > from the same box and ran make oldconfig. >=20 > I was prompted as expected for "PAGEBUF" and "XFS", but not for kdb. When > compiling, however, compiling kdb failed. I went into "Kernel Haking" and > enabled "Kernel Hacking" and disabled kdb. >=20 > So: > 1. Why was kdb enabled without prompting me? > 2. Why do I need to enable kernel hacking in orderto be able to disable k= db? > 0. kdb doesn't compile Actually the kernel doesn't compile, even without kdb, so probably most of the issues from my previous e-mail vanish: -- cut here -- gcc -D__KERNEL__ -I/usr/local/src/linux-2.4-xfs/linux/include -Wall -Wstri= ct-pr ototypes -Wno-trigraphs -O2 -fno-strict-aliasing -fno-common -fomit-frame-p= ointe r -pipe -mpreferred-stack-boundary=3D2 -march=3Di686 -c -o traps.o traps= .c traps.c: In function `unknown_nmi_error': traps.c:584: warning: implicit declaration of function `kdb' traps.c:584: `KDB_REASON_NMI' undeclared (first use in this function) traps.c:584: (Each undeclared identifier is reported only once traps.c:584: for each function it appears in.) make[1]: *** [traps.o] Error 1 make[1]: Leaving directory `/usr/local/src/linux-2.4-xfs/linux/arch/i386/ke= rnel' make: *** [_dir_arch/i386/kernel] Error 2 -- cut here -- Thanks, florin --=20 "If it's not broken, let's fix it till it is." 41A9 2BDE 8E11 F1C5 87A6 03EE 34B3 E075 3B90 DFE4 --1LKvkjL3sHcu1TtY Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.4 (OpenBSD) Comment: For info see http://www.gnupg.org iD8DBQE8NjTwNLPgdTuQ3+QRAj9uAKCdISrG9SJPM6fBMRBZMwIAF4lgTwCdH3rC l0d8xM2J8kCpIFZAGQeutOs= =ewQp -----END PGP SIGNATURE----- --1LKvkjL3sHcu1TtY-- From owner-linux-xfs@oss.sgi.com Fri Jan 4 16:16:04 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g050G4p26889 for linux-xfs-outgoing; Fri, 4 Jan 2002 16:16:04 -0800 Received: from pneumatic-tube.sgi.com (pneumatic-tube.sgi.com [204.94.214.22]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g050Fwg26866 for ; Fri, 4 Jan 2002 16:15:58 -0800 Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id PAA09291 for ; Fri, 4 Jan 2002 15:16:29 -0800 (PST) mail_from (sandeen@sgi.com) Received: from poppy-e185.americas.sgi.com (poppy-e185.americas.sgi.com [128.162.185.207]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id RAA4005696; Fri, 4 Jan 2002 17:14:36 -0600 (CST) Received: from stout.americas.sgi.com (stout.americas.sgi.com [128.162.187.5]) by poppy-e185.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.7) with ESMTP id RAA83109; Fri, 4 Jan 2002 17:14:36 -0600 (CST) Subject: Re: Unable to get XFS, ext3, reiserfs & LVM to coexist happily From: Eric Sandeen To: Adrian Head Cc: Linux XFS Mailing List , linux-lvm@sistina.com In-Reply-To: <200201042349.g04Nnag26320@oss.sgi.com> References: <200201020451.g024pPg00867@oss.sgi.com> <1010173926.1414.12.camel@stout.americas.sgi.com> <200201042349.g04Nnag26320@oss.sgi.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/1.0 (Preview Release) Date: 04 Jan 2002 17:14:35 -0600 Message-Id: <1010186076.1414.22.camel@stout.americas.sgi.com> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 1218 Lines: 35 On Fri, 2002-01-04 at 16:49, Adrian Head wrote: > What does your backtrace look like? Its the ext3_dirt_inode in my backtrace > thats got me. I have compiled a kernel without ext3 so will also give it a > run later. No, ext3 functions do not show up for me when it oopses on snapshot creation: kdb> bt EBP EIP Function(args) 0xc1c2bf78 0xc013649e path_init+0x36 (0xc1c2a000) kernel .text 0xc0100000 0xc0136468 0xc013659c 0xc1c2bf90 0xc01366cf __user_walk+0x2f (0xc1c2a000, 0x804f1bc) kernel .text 0xc0100000 0xc01366a0 0xc01366f8 0xc1c2bfbc 0xc013381e sys_stat64+0x1a (0x8052474, 0xbfffe980, 0x40196154, 0x804f1bc, 0x3) kernel .text 0xc0100000 0xc0133804 0xc0133874 0xc0106c5b system_call+0x33 kernel .text 0xc0100000 0xc0106c28 0xc0106c60 It's trying to stat64 /dev/sda2, one of my lvm partitions. I dunno why this blows up. :/ The code has some fastcalls & inlines around here, though, so this may not be the most accurate. Still looking... -Eric -- Eric Sandeen XFS for Linux http://oss.sgi.com/projects/xfs sandeen@sgi.com SGI, Inc. From owner-linux-xfs@oss.sgi.com Fri Jan 4 16:38:06 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g050c6w27194 for linux-xfs-outgoing; Fri, 4 Jan 2002 16:38:06 -0800 Received: from yog-sothoth.sgi.com (eugate.sgi.com [192.48.160.10]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g050bxg27167 for ; Fri, 4 Jan 2002 16:37:59 -0800 Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by yog-sothoth.sgi.com (980305.SGI.8.8.8-aspam-6.2/980304.SGI-aspam-europe) via ESMTP id AAA1230418 for ; Sat, 5 Jan 2002 00:36:37 +0100 (CET) mail_from (lord@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id RAA3977330; Fri, 4 Jan 2002 17:36:24 -0600 (CST) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id RAA49888; Fri, 4 Jan 2002 17:36:23 -0600 (CST) Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id g04NaCV12944; Fri, 4 Jan 2002 17:36:12 -0600 Subject: Re: file corruption during emacs build on XFS logical volume From: Steve Lord To: Sean Neakums Cc: Linux XFS In-Reply-To: <1010179700.30053.13.camel@jen.americas.sgi.com> References: <1010174871.30053.6.camel@jen.americas.sgi.com> <1010176193.2938.14.camel@UberGeek> <1010176393.30037.9.camel@jen.americas.sgi.com> <1010179700.30053.13.camel@jen.americas.sgi.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/1.0.0.99+cvs.2001.12.18.08.57 (Preview Release) Date: 04 Jan 2002 17:36:11 -0600 Message-Id: <1010187371.30053.32.camel@jen.americas.sgi.com> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 1550 Lines: 44 On Fri, 2002-01-04 at 15:28, Steve Lord wrote: > On Fri, 2002-01-04 at 14:33, Steve Lord wrote: > > On Fri, 2002-01-04 at 14:29, Austin Gonyou wrote: > > > What is the affected version with this? 2.4.17 or all? > > > > Well I hit it in 2.5.2-pre7, but I suspect it goes back into 2.4.16 > > at least. I may have made a mistake in the changes which went in > > to fix various things during 2.4.16. > > > > Steve > > > > It looks like the problem was introduced sometime after the original > split patches for 2.4.16 were put out on Dec 3rd. So it is either > related to something in the fixes for dbench on low memory systems, > or something missed in the 2.4.17 and 2.5.2 merges. > > Steve > > I started with the initial 2.4.16 patches and kept applying fixes to them - so far I have not managed to reproduce the problem, so I am going to try a kernel from just before the 2.4.17 merge went in and see if that works. This does not totally explain why the 2.5 tree exhibits the same problem. I am out of time for today, I may or may not be able to look at this again before Monday. Sean, if you could apply the xfs patches for 2.4.16 (on oss.sgi.com in the projects/xfs/download/patches/2.4.16 directory) and see if you could make this fail I would appreciate it. As I said, for me this worked just fine - as did adding all the I/O path related changes I made before Christmas. Steve (puzzled) -- Steve Lord voice: +1-651-683-3511 Principal Engineer, Filesystem Software email: lord@sgi.com From owner-linux-xfs@oss.sgi.com Fri Jan 4 16:40:00 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g050e0n27336 for linux-xfs-outgoing; Fri, 4 Jan 2002 16:40:00 -0800 Received: from lynx.adilger.int (h24-64-71-161.cg.shawcable.net [24.64.71.161]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g050dtg27309 for ; Fri, 4 Jan 2002 16:39:55 -0800 Received: (from adilger@localhost) by lynx.adilger.int (8.11.2/8.11.2) id g04Nde125624; Fri, 4 Jan 2002 16:39:40 -0700 Date: Fri, 4 Jan 2002 16:39:39 -0700 From: Andreas Dilger To: Adrian Head Cc: Eric Sandeen , Linux XFS Mailing List , linux-lvm@sistina.com Subject: Re: [linux-lvm] Re: Unable to get XFS, ext3, reiserfs & LVM to coexist happily Message-ID: <20020104163939.C12868@lynx.no> Mail-Followup-To: Adrian Head , Eric Sandeen , Linux XFS Mailing List , linux-lvm@sistina.com References: <200201020451.g024pPg00867@oss.sgi.com> <1010173926.1414.12.camel@stout.americas.sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.4i In-Reply-To: ; from ahead@bigpond.net.au on Sat, Jan 05, 2002 at 08:49:22AM +1000 X-GPG-Key: 1024D/0D35BED6 X-GPG-Fingerprint: 7A37 5D79 BF1B CECA D44F 8A29 A488 39F5 0D35 BED6 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 1081 Lines: 35 On Jan 05, 2002 08:49 +1000, Adrian Head wrote: > Well this seems consistant with what I'm seeing: > 2.4.17-xfs > While source volume mounted: > + lvm-1.0.1 upgrade > + VFS-lock > (In that order) > * Can create ext3 snapshot? | yes > * Can mount a ext3 snapshot? | yes > * Can create resierfs snapshot? | yes > * Can mount a resierfs snapshot? | yes > * Can create xfs snapshot? | Oops > btp 1234 (lvcreate) > journal_start > ext3_dirty_inode > __mark_inode_dirty > update_atime > do_generic_file_read > generic_file_read > sys_read > system_call Can you repeat this test, but skip the ext3 snapshot creation part of it entirely (i.e. create a reiserfs snapshot and an XFS snapshot, without changing the kernel)? I'm wondering if XFS is getting an old inode that ext3 was using, but either ext3 or XFS is not clearing it, so that is why it is calling into ext3. Also, are you using ext3 on other filesystems in this computer? Cheers, Andreas -- Andreas Dilger http://sourceforge.net/projects/ext2resize/ http://www-mddsp.enel.ucalgary.ca/People/adilger/ From owner-linux-xfs@oss.sgi.com Fri Jan 4 16:40:43 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g050ehO27470 for linux-xfs-outgoing; Fri, 4 Jan 2002 16:40:43 -0800 Received: from yog-sothoth.sgi.com (eugate.sgi.com [192.48.160.10]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g050eZg27447 for ; Fri, 4 Jan 2002 16:40:36 -0800 Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by yog-sothoth.sgi.com (980305.SGI.8.8.8-aspam-6.2/980304.SGI-aspam-europe) via ESMTP id AAA1238523 for ; Sat, 5 Jan 2002 00:39:17 +0100 (CET) mail_from (lord@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id RAA4005324; Fri, 4 Jan 2002 17:39:07 -0600 (CST) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id RAA49482; Fri, 4 Jan 2002 17:39:07 -0600 (CST) Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id g04NctI12973; Fri, 4 Jan 2002 17:38:55 -0600 Subject: Re: Fwd: TAKE - Sync kdb v2.0-2.4.17 i386 code with xfs From: Steve Lord To: Florin Iucha Cc: linux-xfs@oss.sgi.com, kaos@sherman.melbourne.sgi.com In-Reply-To: <20020104170418.B30706@iucha.net> References: <20020104170418.B30706@iucha.net> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/1.0.0.99+cvs.2001.12.18.08.57 (Preview Release) Date: 04 Jan 2002 17:38:55 -0600 Message-Id: <1010187535.30037.35.camel@jen.americas.sgi.com> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 1862 Lines: 50 On Fri, 2002-01-04 at 17:04, Florin Iucha wrote: > > I have checked out latest linux-2.4-xfs branch and copied my old .config > > from the same box and ran make oldconfig. > > > > I was prompted as expected for "PAGEBUF" and "XFS", but not for kdb. When > > compiling, however, compiling kdb failed. I went into "Kernel Haking" and > > enabled "Kernel Hacking" and disabled kdb. > > > > So: > > 1. Why was kdb enabled without prompting me? > > 2. Why do I need to enable kernel hacking in orderto be able to disable kdb? > > 0. kdb doesn't compile > > Actually the kernel doesn't compile, even without kdb, so probably most of > the issues from my previous e-mail vanish: > > -- cut here -- > gcc -D__KERNEL__ -I/usr/local/src/linux-2.4-xfs/linux/include -Wall -Wstrict-pr > ototypes -Wno-trigraphs -O2 -fno-strict-aliasing -fno-common -fomit-frame-pointe > r -pipe -mpreferred-stack-boundary=2 -march=i686 -c -o traps.o traps.c > traps.c: In function `unknown_nmi_error': > traps.c:584: warning: implicit declaration of function `kdb' > traps.c:584: `KDB_REASON_NMI' undeclared (first use in this function) > traps.c:584: (Each undeclared identifier is reported only once > traps.c:584: for each function it appears in.) > make[1]: *** [traps.o] Error 1 > make[1]: Leaving directory `/usr/local/src/linux-2.4-xfs/linux/arch/i386/kernel' > make: *** [_dir_arch/i386/kernel] Error 2 > -- cut here -- >From a quick scan of the code it does indeed look like there is no way to build with kdb turned off right now. Looks like a few too many ifdefs were eliminated. Steve > > Thanks, > florin > > -- > > "If it's not broken, let's fix it till it is." > > 41A9 2BDE 8E11 F1C5 87A6 03EE 34B3 E075 3B90 DFE4 -- Steve Lord voice: +1-651-683-3511 Principal Engineer, Filesystem Software email: lord@sgi.com From owner-linux-xfs@oss.sgi.com Fri Jan 4 16:55:25 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g050tPE27735 for linux-xfs-outgoing; Fri, 4 Jan 2002 16:55:25 -0800 Received: from zork.zork.net (zork.zork.net [64.81.65.8]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g050tKg27711 for ; Fri, 4 Jan 2002 16:55:20 -0800 Received: from localhost (zork.zork.net) [127.0.0.1] by zork.zork.net with esmtp (Exim 3.33 #1 (Debian)) id 16MeBA-0004XS-00; Fri, 04 Jan 2002 15:55:17 -0800 To: Linux XFS Subject: Re: file corruption during emacs build on XFS logical volume References: <1010174871.30053.6.camel@jen.americas.sgi.com> <1010176193.2938.14.camel@UberGeek> <1010176393.30037.9.camel@jen.americas.sgi.com> <1010179700.30053.13.camel@jen.americas.sgi.com> <1010187371.30053.32.camel@jen.americas.sgi.com> From: Sean Neakums X-Message-Flag: Message text advisory: ULTERIOR MOTIVES, NON-SEQUITUR X-Mailer: Norman Mail-Followup-To: Linux XFS Date: Fri, 04 Jan 2002 23:55:16 +0000 In-Reply-To: <1010187371.30053.32.camel@jen.americas.sgi.com> (Steve Lord's message of "04 Jan 2002 17:36:11 -0600") Message-ID: <6uy9jdhdsr.fsf@zork.zork.net> User-Agent: Gnus/5.090004 (Oort Gnus v0.04) Emacs/21.1 (i386-debian-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 799 Lines: 17 begin Steve Lord quotation: > Sean, if you could apply the xfs patches for 2.4.16 (on oss.sgi.com > in the projects/xfs/download/patches/2.4.16 directory) and see if > you could make this fail I would appreciate it. As I said, for me > this worked just fine - as did adding all the I/O path related > changes I made before Christmas. Sure thing, I'll get that built and tested. The 2.4.16 that's failing for me was built on the 18th December. The cvs update probably didn't happen very long before that. I should try the io-test/emacs dump procedure on that kernel too, for completeness. -- ///////////////// | | The spark of a pin | (require 'gnu) | dropping, falling feather-like. \\\\\\\\\\\\\\\\\ | | There is too much noise. From owner-linux-xfs@oss.sgi.com Fri Jan 4 18:53:21 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g052rLs28864 for linux-xfs-outgoing; Fri, 4 Jan 2002 18:53:21 -0800 Received: from zork.zork.net (zork.zork.net [64.81.65.8]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g052rGg28842 for ; Fri, 4 Jan 2002 18:53:16 -0800 Received: from localhost (zork.zork.net) [127.0.0.1] by zork.zork.net with esmtp (Exim 3.33 #1 (Debian)) id 16Mg1K-0006Kq-00; Fri, 04 Jan 2002 17:53:14 -0800 To: Linux XFS Subject: Re: file corruption during emacs build on XFS logical volume References: <1010174871.30053.6.camel@jen.americas.sgi.com> <1010176193.2938.14.camel@UberGeek> <1010176393.30037.9.camel@jen.americas.sgi.com> <1010179700.30053.13.camel@jen.americas.sgi.com> <1010187371.30053.32.camel@jen.americas.sgi.com> <6uy9jdhdsr.fsf@zork.zork.net> From: Sean Neakums X-Message-Flag: Message text advisory: EXCRETORY SPEECH, PROMOTION OF SELF X-Mailer: Norman Mail-Followup-To: Linux XFS Date: Sat, 05 Jan 2002 01:53:14 +0000 In-Reply-To: <6uy9jdhdsr.fsf@zork.zork.net> (Sean Neakums's message of "Fri, 04 Jan 2002 23:55:16 +0000") Message-ID: <6upu4ph8c5.fsf@zork.zork.net> User-Agent: Gnus/5.090004 (Oort Gnus v0.04) Emacs/21.1 (i386-debian-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 2014 Lines: 41 begin Sean Neakums quotation: > begin Steve Lord quotation: > >> Sean, if you could apply the xfs patches for 2.4.16 (on oss.sgi.com >> in the projects/xfs/download/patches/2.4.16 directory) and see if >> you could make this fail I would appreciate it. As I said, for me >> this worked just fine - as did adding all the I/O path related >> changes I made before Christmas. > > Sure thing, I'll get that built and tested. The 2.4.16 that's > failing for me was built on the 18th December. The cvs update > probably didn't happen very long before that. I should try the > io-test/emacs dump procedure on that kernel too, for completeness. I built a Linus 2.4.16, patched for XFS with the patch from the above location, and I'm certain that the bug was not present in XFS when that patch was generated. I successfully recreated the problem with the CVS 2.4.16 of the 18th using the io-test procedure. (I hadn't done this previously with io-test on that kernel; I had only tried the Debian Emacs build up to now on that kernel.) I've found the best way to do this reliably is to use vmstat (I used "vmstat 3") to watch the amount of used cache. For example, on this machine, which has 256M, used cache stabilised at about 198M with four copies of io-test running to four separate files, and ~1100 in the bo column. At that point, I kicked off the dump, which took over a minute to complete, and started another io-test. The machine load got to the point where a VT switch took many seconds to be acknowledged. I then killed one of the io-test instances and attempted to start the dumped Emacs. The dumped Emacsen started perfectly (though very slowly) on vanilla 2.4.16-plus-patch, but the ones dumped on the CVS-pulled 2.4.16 failed with various nasty dynamic linker errors due to the corruption. -- ///////////////// | | The spark of a pin | (require 'gnu) | dropping, falling feather-like. \\\\\\\\\\\\\\\\\ | | There is too much noise. From owner-linux-xfs@oss.sgi.com Fri Jan 4 19:13:01 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g053D1x29271 for linux-xfs-outgoing; Fri, 4 Jan 2002 19:13:01 -0800 Received: from mta06ps.bigpond.com (mta06ps.bigpond.com [144.135.25.138]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g053Crg29249 for ; Fri, 4 Jan 2002 19:12:53 -0800 Message-Id: <200201050312.g053Crg29249@oss.sgi.com> Received: from there ([144.135.25.87]) by mta06ps.bigpond.com (Netscape Messaging Server 4.15) with SMTP id GPG14V00.E0Y; Sat, 5 Jan 2002 12:19:43 +1000 Received: from CPE-144-137-138-230.qld.bigpond.net.au ([144.137.138.230]) by psmam07.mailsvc.email.bigpond.com(MailRouter V3.0h 125/3885523); 05 Jan 2002 12:12:43 Content-Type: text/plain; charset="us-ascii" From: Adrian Head To: Andreas Dilger Subject: Re: [linux-lvm] Re: Unable to get XFS, ext3, reiserfs & LVM to coexist happily Date: Sat, 5 Jan 2002 12:12:40 +1000 X-Mailer: KMail [version 1.3.1] Cc: Eric Sandeen , Linux XFS Mailing List , linux-lvm@sistina.com References: <200201020451.g024pPg00867@oss.sgi.com> <20020104163939.C12868@lynx.no> In-Reply-To: <20020104163939.C12868@lynx.no> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 1507 Lines: 50 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Sat, 5 Jan 2002 09:39, Andreas Dilger wrote: > Can you repeat this test, but skip the ext3 snapshot creation part of it > entirely (i.e. create a reiserfs snapshot and an XFS snapshot, without > changing the kernel)? I'm wondering if XFS is getting an old inode that > ext3 was using, but either ext3 or XFS is not clearing it, so that is why > it is calling into ext3. Also, are you using ext3 on other filesystems in > this computer? > > Cheers, Andreas Yes there are other volumes using ext3. /boot 20M ext3 / 512M ext3 /usr 512M ext3 /var 512M ext3 swap 768M /tmp 128M reiserfs LVM /cache 512M reiserfs LVM /chroot 512M ext3 LVM /usr/src 4096Mreiserfs LVM /data ~30G xfs LVM the tests are done on /chroot for ext3, /usr/src for resierfs & /data for xfs. I can skip the ext3 snapshot creation part - each test is done on its own logical volume; however, in the dark dim past any of these could have had other filesystems on them. Does this sound sensible? 1) Run tests without doing the ext3 snapshot creation, then 2) dd the entire lv that is giving problems and try again? Thanks for your time & effort. - -- Adrian Head (Public Key available on request.) -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE8NmEb8ZJI8OvSkAcRAiJGAJ9SeL5O399a56EQc2hOu3KbAlTsngCgksF+ y/yKm/SxB7lji0XMLXaAQXo= =DRn3 -----END PGP SIGNATURE----- From owner-linux-xfs@oss.sgi.com Fri Jan 4 19:30:47 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g053Uls29462 for linux-xfs-outgoing; Fri, 4 Jan 2002 19:30:47 -0800 Received: from yog-sothoth.sgi.com (eugate.sgi.com [192.48.160.10]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g053Uig29440 for ; Fri, 4 Jan 2002 19:30:44 -0800 Received: from sherman.melbourne.sgi.com (sherman.melbourne.sgi.com [134.14.55.232]) by yog-sothoth.sgi.com (980305.SGI.8.8.8-aspam-6.2/980304.SGI-aspam-europe) via ESMTP id DAA1232705 for ; Sat, 5 Jan 2002 03:29:24 +0100 (CET) mail_from (kaos@sherman.melbourne.sgi.com) Received: (from kaos@localhost) by sherman.melbourne.sgi.com (8.11.6/8.11.6) id g052UXV04925; Sat, 5 Jan 2002 13:30:33 +1100 Date: Sat, 5 Jan 2002 13:30:33 +1100 From: Keith Owens Message-Id: <200201050230.g052UXV04925@sherman.melbourne.sgi.com> Subject: TAKE - Correct typo in arch/i386/kernel/traps/c Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 254 Lines: 10 Date: Fri Jan 4 18:28:41 PST 2002 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:109136a linux/arch/i386/kernel/traps.c - 1.42 From owner-linux-xfs@oss.sgi.com Fri Jan 4 19:33:16 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g053XGU29592 for linux-xfs-outgoing; Fri, 4 Jan 2002 19:33:16 -0800 Received: from mail.ocs.com.au (mail.ocs.com.au [203.34.97.2]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g053XBg29570 for ; Fri, 4 Jan 2002 19:33:11 -0800 Received: (qmail 19033 invoked from network); 5 Jan 2002 02:33:07 -0000 Received: from ocs3.intra.ocs.com.au (192.168.255.3) by mail.ocs.com.au with SMTP; 5 Jan 2002 02:33:07 -0000 Received: by ocs3.intra.ocs.com.au (Postfix, from userid 16331) id 625D1300090; Sat, 5 Jan 2002 13:33:05 +1100 (EST) Received: from ocs3.intra.ocs.com.au (localhost [127.0.0.1]) by ocs3.intra.ocs.com.au (Postfix) with ESMTP id 1E75094; Sat, 5 Jan 2002 13:33:05 +1100 (EST) X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 From: Keith Owens To: Florin Iucha Cc: linux-xfs@oss.sgi.com Subject: Re: TAKE - Sync kdb v2.0-2.4.17 i386 code with xfs In-reply-to: Your message of "Fri, 04 Jan 2002 16:34:38 MDT." <20020104163438.A30706@iucha.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sat, 05 Jan 2002 13:32:59 +1100 Message-ID: <5810.1010197979@ocs3.intra.ocs.com.au> Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 826 Lines: 22 On Fri, 4 Jan 2002 16:34:38 -0600, Florin Iucha wrote: >I was prompted as expected for "PAGEBUF" and "XFS", but not for kdb. When >compiling, however, compiling kdb failed. I went into "Kernel Haking" and >enabled "Kernel Hacking" and disabled kdb. I missed one set of ifdef during the merge. Updated in ptools, it will be in CVS in a couple of hours. --- linux/arch/i386/kernel/traps.c_1.41 Sat Jan 5 13:30:06 2002 +++ linux/arch/i386/kernel/traps.c_1.42 Sat Jan 5 13:30:06 2002 @@ -581,7 +581,9 @@ return; } #endif +#ifdef CONFIG_KDB (void)kdb(KDB_REASON_NMI, reason, regs); +#endif /* CONFIG_KDB */ printk("Uhhuh. NMI received for unknown reason %02x.\n", reason); printk("Dazed and confused, but trying to continue\n"); printk("Do you have a strange power saving mode enabled?\n"); From owner-linux-xfs@oss.sgi.com Fri Jan 4 19:47:07 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g053l7g29760 for linux-xfs-outgoing; Fri, 4 Jan 2002 19:47:07 -0800 Received: from mta02ps.bigpond.com (mta02ps.bigpond.com [144.135.25.134]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g053kmg29738 for ; Fri, 4 Jan 2002 19:46:48 -0800 Message-Id: <200201050346.g053kmg29738@oss.sgi.com> Received: from there ([144.135.25.87]) by mta02ps.bigpond.com (Netscape Messaging Server 4.15) with SMTP id GPG2PE00.5KD; Sat, 5 Jan 2002 12:53:38 +1000 Received: from CPE-144-137-138-230.qld.bigpond.net.au ([144.137.138.230]) by psmam07.mailsvc.email.bigpond.com(MailRouter V3.0h 125/3907107); 05 Jan 2002 12:46:38 Content-Type: text/plain; charset="us-ascii" From: Adrian Head To: Eric Sandeen Subject: Re: Unable to get XFS, ext3, reiserfs & LVM to coexist happily Date: Sat, 5 Jan 2002 12:46:32 +1000 X-Mailer: KMail [version 1.3.1] Cc: Linux XFS Mailing List , linux-lvm@sistina.com References: <200201020451.g024pPg00867@oss.sgi.com> <200201042349.g04Nnag26320@oss.sgi.com> <1010186076.1414.22.camel@stout.americas.sgi.com> In-Reply-To: <1010186076.1414.22.camel@stout.americas.sgi.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 8346 Lines: 175 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 This is the full output from kdb when trying to create a snapshot on an XFS volume for me. What I was going to do next was follow Andreas Dilger's sugestion and try again. Entering kdb (current=0xc7228000, pid 1435) Oops: Oops due to oops @ 0xc015c446 eax = 0x748b5356 ebx = 0xc01a1550 ecx = 0xd7894040 edx = 0x00000000 esi = 0xc7228000 edi = 0xd7894040 esp = 0xc7229eac eip = 0xc015c446 ebp = 0xd7ed4800 xss = 0x00000018 xcs = 0x00000010 eflags = 0x00010286 xds = 0x00000018 xes = 0x00000018 origeax = 0xffffffff ®s = 0xc7229e78 kdb> bt EBP EIP Function(args) 0xd7ed4800 0xc015c446 journal_start+0x36 (0xd7ed4800, 0x1, 0x40018000, 0xc7229f5c, 0x2) kernel .text 0xc0100000 0xc015c410 0xc015c4f0 0xc01571a8 ext3_dirty_inode+0x58 (0xd7894040) kernel .text 0xc0100000 0xc0157150 0xc0157250 0xc0141b1e __mark_inode_dirty+0x2e (0xd7894040, 0x1) kernel .text 0xc0100000 0xc0141af0 0xc0141b70 0xc0143001 update_atime+0x51 (0xd7894040, 0x6d6, 0x1, 0x0, 0x6d6) kernel .text 0xc0100000 0xc0142fb0 0xc0143010 0xc01254ac do_generic_file_read+0x40c (0xd5fc7740, 0xd5fc7760, 0xc7229f5c, 0xc0125690, 0x6d6) kernel .text 0xc0100000 0xc01250a0 0xc01254c0 0xc012576a generic_file_read+0x7a (0xd5fc7740, 0x40018000, 0x1000, 0xd5fc7760, 0x0) kernel .text 0xc0100000 0xc01256f0 0xc0125810 0xc0130cf5 sys_read+0x95 (0x4, 0x40018000, 0x1000, 0x8086ab0, 0x40018000) kernel .text 0xc0100000 0xc0130c60 0xc0130d30 0xc0106d1b system_call+0x33 kernel .text 0xc0100000 0xc0106ce8 0xc0106d20 kdb> btp 1435 EBP EIP Function(args) 0xc01a1550 0xc015c446 journal_start+0x36 (0xd7ed4800, 0x1, 0x40018000, 0xc7229f5c, 0x2) kernel .text 0xc0100000 0xc015c410 0xc015c4f0 0xc01571a8 ext3_dirty_inode+0x58 (0xd7894040) kernel .text 0xc0100000 0xc0157150 0xc0157250 0xc0141b1e __mark_inode_dirty+0x2e (0xd7894040, 0x1) kernel .text 0xc0100000 0xc0141af0 0xc0141b70 0xc0143001 update_atime+0x51 (0xd7894040, 0x6d6, 0x1, 0x0, 0x6d6) kernel .text 0xc0100000 0xc0142fb0 0xc0143010 0xc01254ac do_generic_file_read+0x40c (0xd5fc7740, 0xd5fc7760, 0xc7229f5c, 0xc0125690, 0x6d6) kernel .text 0xc0100000 0xc01250a0 0xc01254c0 0xc012576a generic_file_read+0x7a (0xd5fc7740, 0x40018000, 0x1000, 0xd5fc7760, 0x0) kernel .text 0xc0100000 0xc01256f0 0xc0125810 0xc0130cf5 sys_read+0x95 (0x4, 0x40018000, 0x1000, 0x8086ab0, 0x40018000) kernel .text 0xc0100000 0xc0130c60 0xc0130d30 0xc0106d1b system_call+0x33 kernel .text 0xc0100000 0xc0106ce8 0xc0106d20 kdb> ps Task Addr Pid Parent [*] cpu State Thread Command 0xd7fe2000 00000001 00000000 1 000 stop 0xd7fe2270 init 0xc163c000 00000002 00000001 1 000 stop 0xc163c270 keventd 0xc1638000 00000003 00000000 1 000 stop 0xc1638270 ksoftirqd_CPU0 0xc1636000 00000004 00000000 1 000 stop 0xc1636270 kswapd 0xc1634000 00000005 00000000 1 000 stop 0xc1634270 bdflush 0xc1632000 00000006 00000000 1 000 stop 0xc1632270 kupdated 0xd7ec4000 00000007 00000001 1 000 stop 0xd7ec4270 mdrecoveryd 0xd7eae000 00000008 00000001 1 000 stop 0xd7eae270 raid5d 0xd7b32000 00000009 00000001 1 000 stop 0xd7b32270 kjournald 0xd72a6000 00000153 00000001 1 000 stop 0xd72a6270 kjournald 0xd729c000 00000154 00000001 1 000 stop 0xd729c270 kjournald 0xd7292000 00000155 00000001 1 000 stop 0xd7292270 kjournald 0xd7174000 00000157 00000001 1 000 stop 0xd7174270 kreiserfsd 0xd70ac000 00000158 00000001 1 000 stop 0xd70ac270 kjournald 0xd6f68000 00000160 00000001 1 000 stop 0xd6f68270 pagebuf_daemon 0xd6250000 00000525 00000001 1 000 stop 0xd6250270 dhcpcd 0xd6c56000 00000661 00000001 1 000 stop 0xd6c56270 syslogd 0xd623a000 00000666 00000001 1 000 stop 0xd623a270 klogd 0xd619e000 00000686 00000001 1 000 stop 0xd619e270 portmap 0xd60ac000 00000714 00000001 1 000 stop 0xd60ac270 rpc.statd 0xd62d6000 00000827 00000001 1 000 stop 0xd62d6270 crond more> 0xd5f3a000 00000863 00000001 1 000 stop 0xd5f3a270 atd 0xd6a80000 00000870 00000001 1 000 stop 0xd6a80270 login 0xd5f5a000 00000871 00000001 1 000 stop 0xd5f5a270 login 0xd5f56000 00000872 00000001 1 000 stop 0xd5f56270 mingetty 0xd6c9c000 00000873 00000001 1 000 stop 0xd6c9c270 mingetty 0xd5f6a000 00000874 00000001 1 000 stop 0xd5f6a270 mingetty 0xd6c9a000 00000875 00000001 1 000 stop 0xd6c9a270 mingetty 0xd6338000 00000876 00000001 1 000 stop 0xd6338270 login 0xd739c000 00000879 00000876 1 000 stop 0xd739c270 bash 0xd5d86000 00000925 00000870 1 000 stop 0xd5d86270 bash 0xd580c000 00000977 00000871 1 000 stop 0xd580c270 bash 0xc7228000 00001435 00000925 1 000 run 0xc7228270*lvcreate kdb> id %eip 0xc015c446 journal_start+0x36: cmp %ebp,(%eax) 0xc015c448 journal_start+0x38: je 0xc015c46d journal_start+0x5d: 0xc015c44a journal_start+0x3a: push $0xc02309e0 0xc015c44f journal_start+0x3f: push $0xe1 0xc015c454 journal_start+0x44: push $0xc022becf 0xc015c459 journal_start+0x49: push $0xc022b6a0 0xc015c45e journal_start+0x4e: push $0xc022e6a0 0xc015c463 journal_start+0x53: call 0xc0115380 printk: 0xc015c468 journal_start+0x58: ud2a 0xc015c46a journal_start+0x5a: add $0x14,%esp 0xc015c46d journal_start+0x5d: incl 0x8(%ebx) 0xc015c470 journal_start+0x60: jmp 0xc015c4e0 journal_start+0xd0: 0xc015c472 journal_start+0x62: push $0x1 0xc015c474 journal_start+0x64: push $0xf0 0xc015c479 journal_start+0x69: push $0x14 0xc015c47b journal_start+0x6b: push $0xc022b6a0 kdb> go Oops: 0000 CPU: 0 EIP: 0010:[] Not tainted EFLAGS: 00010286 eax: 748b5356 ebx: c01a1550 ecx: d7894040 edx: 00000000 esi: c7228000 edi: d7894040 ebp: d7ed4800 esp: c7229eac ds: 0018 es: 0018 ss: 0018 Process lvcreate (pid: 1435, stackpage=c7229000) Stack: c01a1550 c01a1550 ffffffe2 d7894040 00000000 c01571a8 d7ed4800 00000001 40018000 c7229f5c 00000002 00000018 d7894040 d7b41000 00000001 c0141b1e d7894040 3c36dd6f d5fc7760 d78940f0 c0143001 d7894040 00000001 00000000 Call Trace: [] [] [] [] [] [] [] [] [] [] Code: 39 28 74 23 68 e0 09 23 c0 68 e1 00 00 00 68 cf be 22 c0 68 On Sat, 5 Jan 2002 09:14, Eric Sandeen wrote: > On Fri, 2002-01-04 at 16:49, Adrian Head wrote: > > What does your backtrace look like? Its the ext3_dirt_inode in my > > backtrace thats got me. I have compiled a kernel without ext3 so will > > also give it a run later. > > No, ext3 functions do not show up for me when it oopses on snapshot > creation: > > kdb> bt > EBP EIP Function(args) > 0xc1c2bf78 0xc013649e path_init+0x36 (0xc1c2a000) > kernel .text 0xc0100000 0xc0136468 > 0xc013659c 0xc1c2bf90 0xc01366cf __user_walk+0x2f (0xc1c2a000, 0x804f1bc) > kernel .text 0xc0100000 0xc01366a0 > 0xc01366f8 0xc1c2bfbc 0xc013381e sys_stat64+0x1a (0x8052474, 0xbfffe980, > 0x40196154, 0x804f1bc, 0x3) kernel .text 0xc0100000 0xc0133804 0xc0133874 > 0xc0106c5b system_call+0x33 > kernel .text 0xc0100000 0xc0106c28 > 0xc0106c60 > > > It's trying to stat64 /dev/sda2, one of my lvm partitions. I dunno why > this blows up. :/ > > The code has some fastcalls & inlines around here, though, so this may > not be the most accurate. > > Still looking... > > -Eric - -- Adrian Head (Public Key available on request.) -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE8NmkN8ZJI8OvSkAcRAk6FAJ0SKQPujP4BQbjs0tZprVhAyDwehQCfcjxA lONpZIiIHSojcBPRkyNFfvA= =k23i -----END PGP SIGNATURE----- From owner-linux-xfs@oss.sgi.com Fri Jan 4 20:11:14 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g054BEi30084 for linux-xfs-outgoing; Fri, 4 Jan 2002 20:11:14 -0800 Received: from zok.sgi.com (zok.sgi.com [204.94.215.101]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g054B4g30062 for ; Fri, 4 Jan 2002 20:11:04 -0800 Received: from relay1.corp.sgi.com (spindle.corp.sgi.com [198.29.75.13]) by zok.sgi.com (8.11.4/8.11.4/linux-outbound_gateway-1.1) with ESMTP id g053AvA30861 for ; Fri, 4 Jan 2002 19:10:57 -0800 Received: from chuckle.americas.sgi.com (sandeen@chuckle.americas.sgi.com [128.162.211.44]) by relay1.corp.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) via ESMTP id TAA79076; Fri, 4 Jan 2002 19:10:26 -0800 (PST) Date: Fri, 4 Jan 2002 21:10:25 -0600 (CST) From: Eric Sandeen X-X-Sender: To: Adrian Head cc: Linux XFS Mailing List , Subject: Re: Unable to get XFS, ext3, reiserfs & LVM to coexist happily In-Reply-To: <200201050346.g053kmg29738@oss.sgi.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 3803 Lines: 83 Ok, I've done a bit of kdb sleuthing over here... it looks like it's blowing up shortly after lvm_snapshot_COW, although for some reason kdb says the backtrace is from sys_stat64 after the oops. On the other hand, setting a breakpoint at lvm_snapshot_COW, it oopses just a couple steps later. Here's the backtrace out of lvm_snapshot_COW. It gets there from lvm_do_lv_creat via unlockfs; does this make sense? I didn't expect to get into lvm_snapshot_COW until after the snapshot volume was created... kdb> bp lvm_snapshot_COW Instruction(i) BP #0 at 0xc8848ab4 ([lvm-mod]lvm_snapshot_COW) is enabled globally adjust 1 kdb> go Instruction(i) breakpoint #0 at 0xc8848ab4 (adjusted) 0xc8848ab4 lvm_snapshot_COW: int3 Entering kdb (current=0xc5ca0000, pid 1063) due to Breakpoint @ 0xc8848ab4 kdb> bt EBP EIP Function(args) 0xc5ca1718 0xc8848ab4 [lvm-mod]lvm_snapshot_COW (0x802, 0x10178, 0x10178, 0x10178, 0xc5e8f000) lvm-mod .text 0xc8844060 0xc8848ab4 0xc8848fc0 0xc884538b [lvm-mod]__remap_snapshot+0x5b (0x802, 0x10178, 0x10178, 0xc5b10a00, 0xc5e8f000) lvm-mod .text 0xc8844060 0xc8845330 0xc88453b8 0xc5ca179c 0xc8845760 [lvm-mod]lvm_map+0x3a8 (0xc5777900, 0x1) lvm-mod .text 0xc8844060 0xc88453b8 0xc88457e8 0xc5ca17ac 0xc88457f8 [lvm-mod]lvm_make_request_fn+0x10 (0xc039e028, 0x1, 0xc5777900) lvm-mod .text 0xc8844060 0xc88457e8 0xc8845808 0xc5ca17d0 0xc01a004b generic_make_request+0xa7 (0x1, 0xc5777900) kernel .text 0xc0100000 0xc019ffa4 0xc01a00d0 0xc5ca182c 0xc882caa2 [pagebuf]_pagebuf_page_io+0x24a (0xc116c400, 0xc5caa080, 0x1, 0x0, 0x3a00) pagebuf .text 0xc882b060 0xc882c858 0xc882cb1c 0xc5ca1888 0xc882cc6b [pagebuf]_page_buf_page_apply+0x14f (0xc5caa080, 0x0, 0x0, 0xc116c400, 0x600) pagebuf .text 0xc882b060 0xc882cb1c 0xc882cc78 0xc5ca18c8 0xc882d0a8 [pagebuf]pagebuf_segment_apply+0x98 (0xc882cb1c, 0xc5caa080) pagebuf .text 0xc882b060 0xc882d010 0xc882d0f0 0xc5ca1908 0xc882cd64 [pagebuf]pagebuf_iorequest+0xec (0xc5caa080) pagebuf .text 0xc882b060 0xc882cc78 0xc882cdb8 0xc5ca1914 0xc88c977a [xfs]xfsbdstrat+0x2a (0xc13cfc00, 0xc5caa080) xfs .text 0xc8866060 0xc88c9750 0xc88c978c 0xc5ca1934 0xc88b20a8 [xfs]xfs_unmountfs_writesb+0xc4 (0xc13cfc00) more> xfs .text 0xc8866060 0xc88b1fe4 0xc88b2108 0xc5ca1944 0xc889ef4d [xfs]xfs_fs_thaw+0xd (0xc13cfc00) xfs .text 0xc8866060 0xc889ef40 0xc889ef60 0xc5ca1ce0 0xc88c55b0 [xfs]xfs_ioctl+0x1684 (0xc5ca6058, 0xc5b11440, 0x0, 0xc0045878, 0x0) xfs .text 0xc8866060 0xc88c3f2c 0xc88c5660 0xc5ca1d08 0xc88caabd [xfs]linvfs_unfreeze_fs+0x41 (0xc13cf400) xfs .text 0xc8866060 0xc88caa7c 0xc88caacc 0xc5ca1d18 0xc0131469 unlockfs+0x31 (0x3a00) kernel .text 0xc0100000 0xc0131438 0xc013148c 0xc5ca1da8 0xc8847174 [lvm-mod]lvm_do_lv_create+0x7fc (0x0, 0xc884ce60, 0xc5ca1dec, 0xc6482cc0) lvm-mod .text 0xc8844060 0xc8846978 0xc88471ac 0xc5ca1f90 0xc8844900 [lvm-mod]lvm_chr_ioctl+0x644 (0xc5b11800, 0xc6482cc0, 0x4004fe20, 0xbfffec60, 0xc5ca0000) lvm-mod .text 0xc8844060 0xc88442bc 0xc8844a0c 0xc5ca1fbc 0xc01393f4 sys_ioctl+0x174 (0x4, 0x4004fe20, 0xbfffec60, 0x804f1bc, 0xbffff940) kernel .text 0xc0100000 0xc0139280 0xc0139410 0xc0106c5b system_call+0x33 kernel .text 0xc0100000 0xc0106c28 0xc0106c60 From owner-linux-xfs@oss.sgi.com Fri Jan 4 20:38:08 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g054c8s30555 for linux-xfs-outgoing; Fri, 4 Jan 2002 20:38:08 -0800 Received: from mta02ps.bigpond.com (mta02ps.bigpond.com [144.135.25.134]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g054c2g30533 for ; Fri, 4 Jan 2002 20:38:02 -0800 Message-Id: <200201050438.g054c2g30533@oss.sgi.com> Received: from there ([144.135.25.87]) by mta02ps.bigpond.com (Netscape Messaging Server 4.15) with SMTP id GPG52T00.6J5; Sat, 5 Jan 2002 13:44:53 +1000 Received: from CPE-144-137-138-230.qld.bigpond.net.au ([144.137.138.230]) by psmam07.mailsvc.email.bigpond.com(MailRouter V3.0h 125/3937587); 05 Jan 2002 13:37:54 Content-Type: text/plain; charset="us-ascii" From: Adrian Head To: Andreas Dilger Subject: Re: [linux-lvm] Re: Unable to get XFS, ext3, reiserfs & LVM to coexist happily Date: Sat, 5 Jan 2002 13:37:50 +1000 X-Mailer: KMail [version 1.3.1] Cc: Eric Sandeen , Linux XFS Mailing List , linux-lvm@sistina.com References: <200201020451.g024pPg00867@oss.sgi.com> <20020104163939.C12868@lynx.no> In-Reply-To: <20020104163939.C12868@lynx.no> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 1266 Lines: 43 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Andreas or any other LVM gurus, This is related to but not imeadiately concerned with the problem we have been discussing. When lvcreate dies when creating an XFS snapshot it doesn't finish the snapshot creation and although lvdisplay shows that the XFS lv has an active snapshot (shows even its name) lvdisplay tells me that the snapshot doesn't exist and therefore, cannot be removed. During the reboot the machine fails to run through the startup scripts and dies somewhere within mount. I have found that kernels without the lvm-1.0.1 upgrade patch are able to carry on and even fix the half created snapshot whereas kernels with the lvm-1.0.1 upgrade patch are unable to deal with the problem snapshot and just die. Are you aware of what this might be? And if this is going to be the default behaviour in future versions of LVM how would I recover using a lvm-1.0.1 patched kernel? Just interested Thanks - -- Adrian Head (Public Key available on request.) -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE8NnUR8ZJI8OvSkAcRAnegAJ9rayag2AQ7AMKufbL0d7PlxB3jxwCdGaQz UKinrM4ZVskDCt13J+3HAs0= =UDmt -----END PGP SIGNATURE----- From owner-linux-xfs@oss.sgi.com Sat Jan 5 04:30:29 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g05CUT406117 for linux-xfs-outgoing; Sat, 5 Jan 2002 04:30:29 -0800 Received: from smtpzilla3.xs4all.nl (smtpzilla3.xs4all.nl [194.109.127.139]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g05CUPg06095 for ; Sat, 5 Jan 2002 04:30:25 -0800 Received: from auto-nb1.xs4all.nl (qn-212-58-167-191.quicknet.nl [212.58.167.191]) by smtpzilla3.xs4all.nl (8.12.0/8.12.0) with ESMTP id g05BUEFt017082; Sat, 5 Jan 2002 12:30:14 +0100 (CET) Message-Id: <4.3.2.7.2.20020105122921.02cde538@pop.xs4all.nl> X-Sender: knuffie@pop.xs4all.nl X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Sat, 05 Jan 2002 12:29:52 +0100 To: Eric Sandeen , Jay Vasa From: Seth Mos Subject: Re: kernel Makefile prob with tulip Cc: linux-xfs@oss.sgi.com In-Reply-To: <1010177964.2576.16.camel@stout.americas.sgi.com> References: <3C3611F3.8457919E@imageevent.com> <3C3611F3.8457919E@imageevent.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 378 Lines: 18 At 14:59 4-1-2002 -0600, Eric Sandeen wrote: >hi Jay - > >Thanks, looks like this got inherited from Red Hat. > >Interesting that it didn't cause problems with our RPM kernel builds, >though, since we do build the tulip module...? make mrproper? Cheers -- Seth Every program has two purposes one for which it was written and another for which it wasn't I use the last kind. From owner-linux-xfs@oss.sgi.com Sat Jan 5 08:55:24 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g05GtOs09842 for linux-xfs-outgoing; Sat, 5 Jan 2002 08:55:24 -0800 Received: from ADSL-Bergs.RZ.RWTH-Aachen.DE (adsl-bergs.rz.RWTH-Aachen.DE [137.226.80.218]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g05Gsrg09800 for ; Sat, 5 Jan 2002 08:54:55 -0800 Received: from [192.168.1.2] (helo=ralf) by ADSL-Bergs.RZ.RWTH-Aachen.DE with smtp (Exim 3.12 #1) id 16Mt9d-0004cr-00; Sat, 05 Jan 2002 16:54:41 +0100 From: "Ralf G. R. Bergs" To: "Eric Sandeen" Cc: "Linux XFS Mailing List" Date: Sat, 05 Jan 2002 16:54:40 +0100 Reply-To: "Ralf G. R. Bergs" X-Mailer: PMMail 2000 Professional (2.20.2380) For Windows 2000 (5.0.2195;2) In-Reply-To: <1010172903.2576.10.camel@stout.americas.sgi.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Subject: Re: VERY URGENT: "cp -a" creates mysteriously "hidden" files?! Message-Id: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 5933 Lines: 239 On Fri, 04 Jan 2002 13:35:03 -0600, Eric Sandeen wrote: [...] >Ok, I'm not sure what to tell you about the force shutdowns at this >point... but try to get it into a state where it did not shut down, but >you have "missing" files, and I can talk you through some exploration >with xfs_db. I've now managed to copy the whole old RAID over to the new (larger) RAID running XFS, PLUS I got the same errors about missing files again: Fileserver:/mnt/raidNEU# ls -lahR >/tmp/ls-R.txt ls: ./daten/software/win 2000/Standard Fonts/.AppleDouble/M CORSVA.TTF: No such file or directory ls: ./home/hiwi/willared/Netscapestangdefaultdefault__/Cache/MVDALU23.3IF: No such file or directory This is what I received when running "xfs_repair -n" on the UNMOUNTED filesystem: Fileserver:/mnt# xfs_repair -n /dev/sdc5 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 = 8 - agno = 9 - agno = 10 - agno = 11 - agno = 12 - agno = 13 - agno = 14 - agno = 15 - agno = 16 - agno = 17 - agno = 18 - agno = 19 - agno = 20 - agno = 21 - agno = 22 - agno = 23 - agno = 24 - agno = 25 - agno = 26 - agno = 27 - agno = 28 - agno = 29 - agno = 30 - agno = 31 - agno = 32 - agno = 33 - agno = 34 - agno = 35 - agno = 36 - agno = 37 - agno = 38 - agno = 39 - agno = 40 - agno = 41 - agno = 42 - agno = 43 - agno = 44 - agno = 45 - agno = 46 - agno = 47 - agno = 48 - agno = 49 - agno = 50 - agno = 51 - agno = 52 - agno = 53 - agno = 54 - agno = 55 - agno = 56 - agno = 57 - agno = 58 - agno = 59 entry contains offset out of order in shortform dir 989855872 would have corrected entry offsets in directory 989855872 - agno = 60 - agno = 61 - agno = 62 - agno = 63 - agno = 64 - agno = 65 - agno = 66 - agno = 67 - agno = 68 - agno = 69 - agno = 70 - agno = 71 - agno = 72 - agno = 73 - agno = 74 - agno = 75 - agno = 76 - agno = 77 - agno = 78 - agno = 79 - agno = 80 - agno = 81 - agno = 82 - agno = 83 - agno = 84 - agno = 85 - 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 - agno = 8 - agno = 9 - agno = 10 - agno = 11 - agno = 12 - agno = 13 - agno = 14 - agno = 15 - agno = 16 - agno = 17 - agno = 18 - agno = 19 - agno = 20 - agno = 21 - agno = 22 - agno = 23 - agno = 24 - agno = 25 - agno = 26 - agno = 27 - agno = 28 - agno = 29 - agno = 30 - agno = 31 - agno = 32 - agno = 33 - agno = 34 - agno = 35 - agno = 36 - agno = 37 - agno = 38 - agno = 39 - agno = 40 - agno = 41 - agno = 42 - agno = 43 - agno = 44 - agno = 45 - agno = 46 - agno = 47 - agno = 48 - agno = 49 - agno = 50 - agno = 51 - agno = 52 - agno = 53 - agno = 54 - agno = 55 - agno = 56 - agno = 57 - agno = 58 - agno = 59 entry contains offset out of order in shortform dir 989855872 would have corrected entry offsets in directory 989855872 - agno = 60 - agno = 61 - agno = 62 - agno = 63 - agno = 64 - agno = 65 - agno = 66 - agno = 67 - agno = 68 - agno = 69 - agno = 70 - agno = 71 - agno = 72 - agno = 73 - agno = 74 - agno = 75 - agno = 76 - agno = 77 - agno = 78 - agno = 79 - agno = 80 - agno = 81 - agno = 82 - agno = 83 - agno = 84 - agno = 85 No modify flag set, skipping phase 5 Phase 6 - check inode connectivity... - traversing filesystem starting at / ... bad hash table for directory inode 950985409 (hash value mismatch): would rebuild - 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. That's it. Does this tell you anything about what could be going wrong? Can I do anything else to further investigate the problem? Thanks, Ralf -- Verkaufe Original-BMW-Raeder: L I N U X .~. http://adsl-bergs.rz.rwth-aachen.de/~rabe The Choice /V\ of a GNU /( )\ Generation ^^-^^ From owner-linux-xfs@oss.sgi.com Sat Jan 5 09:08:12 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g05H8CD10260 for linux-xfs-outgoing; Sat, 5 Jan 2002 09:08:12 -0800 Received: from mel-rto6.wanadoo.fr (smtp-out-6.wanadoo.fr [193.252.19.25]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g05H7kg10230 for ; Sat, 5 Jan 2002 09:07:47 -0800 Received: from citronier.wanadoo.fr (193.252.19.222) by mel-rto6.wanadoo.fr; 5 Jan 2002 17:07:39 +0100 Received: from haibi (193.252.186.64) by citronier.wanadoo.fr; 5 Jan 2002 17:07:32 +0100 Message-ID: <3c3724c53d05b4ba@citronier.wanadoo.fr> (added by citronier.wanadoo.fr) From: Habib HAIBI To: linux-xfs@oss.sgi.com Subject: Meilleurs Voeux pour 2002 : année de mémoire, de mobilisation, d'action, de justice et de sérénité - Appel au soutien moral et financier Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Sat, 5 Jan 2002 17:08:05 +0100 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 10509 Lines: 238 Meilleurs Voeux pour 2002 : année de mémoire, de mobilisation, d'action, de justice et de sérénité - Appel au soutien moral et financier ======================== M. Habib HAIBI, 7, Aguesseau St. 69007 LYON - France Tél. 00 33 4 72 73 19 08 - Fax 00 33 4 78 61 39 27 Email : haibi@free.fr http://haibi.free.fr Je suis qualifié pour exprimer mes voeux pour le Nouvel An à tous les survivants et les familles des victimes des attaques terroristes, au peuple américain, ses dirigeants, ses institutions, son président et tous les combattants de la liberté, loin de leurs foyers, tout autour du monde! Je suis fier de vous dire avec gratitude combien Les USA sont puissants, démocratiques et qualifiés pour défendre la liberté et la démocratie avec humanisme et sérénité. L'ennemi du progrès du genre humain peut encore frapper. La liberté et la démocratie peuvent être encore sous attaques! Personne ne s'imaginait que cela pouvait arriver et c'est arrivé en ce jour pacifique du 11 septembre 2001 Personne ne s'imaginait que cela pouvait arriver… en France et c'est arrivé le 26 février 2001 quand les magistrats du parquet de Lyon, par impulsion suicidaire et préméditée, ont eu recours à l'arbitraire pour entraver l'action Publique mise en Mouvement : ils ont requis l'expertise psychiatrique de la Partie Civile par l'action avant de l'entendre dans ses accusations ! Cette dérive obscurantiste a dépassé tout entendement C'est arrivé un jour pacifique pour moi et pour les institutions de la République en France. Le réquisitoire aux fins de l'expertise psychiatrique de la partie civile par l'action, avant de l'entendre dans ses accusations, constitue une atteinte obscurantiste à l'intégrité de la personne de la partie civile et surtout un attentat aux valeurs fondamentales de la société civilisée et une infamie assénée à la République et ses Institutions: - à tous les martyrs de la liberté qui ont payé de leur vie la défense des personnes et des biens et des valeurs fondamentales et universelles de la République. - à tous ceux qui dans l'exercice de leurs fonctions, au nom du devoir de servir, exposeraient leurs vies, sans hésitation, pour la défense de ces mêmes valeurs - à tous les hommes ou femmes de bonne volonté, citoyens anonymes, élevés sur la foi en une société pacifiée par l'avènement de la République, la crainte des lois et l'indéfectibilité de l'Etat, de la Justice et des Institutions en Démocratie. J'étais, longtemps avant le WTC l'autre "point zéro" de la planète qui a subit les premières vagues d'attaque contre les institutions de la République, la liberté et les droits de l'homme … en France ! Il y a eu trois autres attaques avec la même détermination, diabolique et suicidaire, de stopper l'action publique régulièrement mise en mouvement ! J'ai fait face à l'adversité en mettant en accusation 15 magistrats, saisis par la foudre de l'action publique en colère, nominativement impliqués, des deux juridictions de Lyon tout rôle et rang confondus pour abus d'autorité aggravé et trafic d'influence aggravé. Une fois que vous avez pris la mesure de l'attaque contre les valeurs universelles de la liberté et la justice en démocratie en France… et assimilé la grandeur de la querelle qui m'anime … Votre réaction sera vivement souhaitée et sollicitée ! Je recevrai vos contributions morales et financières comme une juste consolation pour le grand préjudice moral que je subis dans l'attente de la réparation de la faute lourde par la justice et l'Etat. Souvenez-vous que la paix civile fut conquise au prix de feu, de sang et de sacrifices… avec pour objectif le règne absolu et égalitaire de la loi. Imaginez les victimes du 11 septembre 2001 dans un monde sans liberté, sans justice et sans démocratie… Imaginez tous les sacrifices de tous les combattants de la liberté, depuis deux siècles et plus, laissés pour compte et discrédités en une seule journée d'attaques perpétrées par les forces diaboliques de l'arbitraire et de l'obscurantisme dans le pays qui a donné naissance au reigne de la loi, l'avènement de la République et les droits de l'homme. Une nouvelle ère a commencé où le grand pays que sont les Etats Unis vont guider et pour longtemps l'impulsion de l'alerte et de la réaction pour perpétuer la liberté et la justice en démocraties. C'est aussi votre combat et le combat de tous les hommes libres. Merci au président des Etats Unis pour son leadership, l'immense puissance de son pays et sa sérénité. Merci à tous d'avoir lu et compris ce message. Merci pour vos réactions et vos contributions. ========================== Ces contributions sont souhaitées à la hauteur de 500 $ ou euros et plus pour tous les représentants élus des peuples, sénateurs et députés, quelque soit leur pays et quelque soit le moyen utilisé pour les alerter des attaques contre la démocratie et de la colère de l'action Publique en mouvement : "ma tristesse s'est muée en colère et la colère en résolution "! (ma conviction est que si de tels actes ont pu se produire c'est à cause d'un climat de permissivité qui a pu s'installer par l'absence du contrôle de l'exécutif par le pouvoir législatif…). ======= vous pouvez verser directement vos contributions financières sur le compte : RIP RELEVE D'IDENTITE BANCAIRE 20041 01007 1112632 F038 69 IBAN IDENTIFIANT INTERNATIONAL FR 53 20041 01007 1112632 F 038 69 Ou envoyer un mandat cash à mon nom et à mon adresse. ================================ Les contributions seront libres et bienvenues de la part de tout autre citoyen sensible à l'idée de vivre dans une société pacifiée par la crainte des lois et la crédibilité des institutions démocratiques. ============ Mon objectif est de réunir 10 000 réactions à 100 $ ou euros chacune : vous pouvez m'aider à atteindre ce but. Je serai, à coup sûr, un homme riche! Mais je ne recouvrerai la paix intérieure avant que justice soit faite! 'J'ai un rêve"! La justice sera faite ! ============ Le site où est publié l'ensemble du dossier est en français, vous pouvez vous aider pour la traduction par un moteur de traduction sur internet. http://haibi.free.fr ============ Cette mailing liste, non exhaustive, est composée de 30 000 emails : des représentants élus, les représentants de l'Etat, hauts fonctionnaires, magistrats, avocats, journalistes, chefs d'entreprise, président ou membre d'association, profession libérale ou tout autre simple citoyen intéressé par la vie sociale, administrative et judiciaire. ======================= Vous pourrez discuter en circuit interne non publié sur le net en vous abonnant au groupe créé pour cet objet "Il n'y a pas d'alternative à la justice en république en france" Coordonnées du groupe : Email du groupe : lecitoyen.laloi.larepublique@smartgroups.com Email du gestionnaire : lecitoyen.laloi.larepublique-owner@smartgroups.com Pour devenir membre : lecitoyen.laloi.larepublique-subscribe@smartgroups.com Pour ne plus être membre : lecitoyen.laloi.larepublique-unsubscribe@smartgroups.com Accueil du groupe : http://smartgroups.wanadoo.fr/groups/lecitoyen.laloi.larepubliqu e ====================== Si vous ne vous sentez pas concerné, vous pouvez demander à ce que votre email soit effacer en exprimant votre volonté à l'adresse email : haibi@free.fr Merci encore de participer à l'alerte et au suivi de l'action publique en mouvement, et au soutien moral et financier de la partie civile par l'action. ================================ =================================================== =================================================== =================================================== =================================================== =================================================== =================================================== =================================================== =================================================== =================================================== =================================================== =================================================== =================================================== =================================================== =================================================== =================================================== =================================================== =================================================== =================================================== =================================================== =================================================== =================================================== =================================================== =================================================== =================================================== =================================================== =================================================== =================================================== =============================== =================================================== =================================================== =================================================== =================================================== =================================================== =================================================== =================================================== =================================================== =================================================== =================================================== =================================================== =================================================== =================================================== =================================================== =================================================== =================================================== =================================================== =================================================== =================================================== =================================================== =================================================== =================================================== =================================================== =================================================== =================================================== =================================================== ================================================== Vous pourrez recevoir une autre version en anglais. Ceci n'est pas un spam Merci! NEVER SEND SPAM. IT IS BAD. From owner-linux-xfs@oss.sgi.com Sat Jan 5 12:10:45 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g05KAjI12471 for linux-xfs-outgoing; Sat, 5 Jan 2002 12:10:45 -0800 Received: from atlrel8.hp.com (atlrel8.hp.com [156.153.255.206]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g05KAfg12449 for ; Sat, 5 Jan 2002 12:10:41 -0800 Received: from xatlrelay1.atl.hp.com (xatlrelay1.atl.hp.com [15.45.89.190]) by atlrel8.hp.com (Postfix) with ESMTP id 29768E0065E for ; Fri, 4 Jan 2002 20:52:32 -0500 (EST) Received: from xatlbh4.atl.hp.com (xatlbh4.atl.hp.com [15.45.89.189]) by xatlrelay1.atl.hp.com (Postfix) with ESMTP id 13B43400093 for ; Fri, 4 Jan 2002 20:52:32 -0500 (EST) Received: by xatlbh4.atl.hp.com with Internet Mail Service (5.5.2653.19) id ; Fri, 4 Jan 2002 20:52:31 -0500 Message-ID: From: "ZINKEVICIUS,MATT (HP-Loveland,ex1)" To: "'linux-xfs@oss.sgi.com'" Subject: link() messes up file attributes Date: Fri, 4 Jan 2002 20:52:29 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 683 Lines: 20 Hi gang, We have been running specSFSv2 (NFS benchmark) against a server running XFS. All was well previously (kernel 2.4.14), but we recently checked out the XFS CVS (2002-01-03) and it now fails. The test fails a part of the validation stage which does the following steps: 1) Create a file (file1) with permissions 666 2) Create a hardlinked file (file2) to file1 3) Check that permissions of file1 are still 666 Step 3 now fails as file1 now has 644 permissions! Using the same kernel we tried ext2 instead and everything behaved normally. If anybody wants anymore detail just let me know. Matt Zinkevicius Software Engineer Network Storage Array Solutions Hewlett-Packard From owner-linux-xfs@oss.sgi.com Sat Jan 5 12:14:13 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g05KEDR12603 for linux-xfs-outgoing; Sat, 5 Jan 2002 12:14:13 -0800 Received: from deliverator.sgi.com (deliverator.sgi.com [204.94.214.10]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g05KE7g12580 for ; Sat, 5 Jan 2002 12:14:07 -0800 Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id LAA01506 for ; Sat, 5 Jan 2002 11:13:49 -0800 (PST) mail_from (lord@sgi.com) Received: from tulip-e185.americas.sgi.com (tulip-e185.americas.sgi.com [128.162.185.208]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id NAA3947906; Sat, 5 Jan 2002 13:12:49 -0600 (CST) Received: from sgi.com (1hfZbhfcVqIHUDAfBaiiaclobyxeMpsz@lord-h1.americas.sgi.com [206.11.101.42]) by tulip-e185.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.7) with ESMTP id NAA10794; Sat, 5 Jan 2002 13:12:48 -0600 (CST) Message-ID: <3C37511F.6050809@sgi.com> Date: Sat, 05 Jan 2002 13:16:47 -0600 From: Stephen Lord User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.6) Gecko/20011120 X-Accept-Language: en-us MIME-Version: 1.0 To: Sean Neakums CC: Linux XFS Subject: Re: file corruption during emacs build on XFS logical volume References: <1010174871.30053.6.camel@jen.americas.sgi.com> <1010176193.2938.14.camel@UberGeek> <1010176393.30037.9.camel@jen.americas.sgi.com> <1010179700.30053.13.camel@jen.americas.sgi.com> <1010187371.30053.32.camel@jen.americas.sgi.com> <6uy9jdhdsr.fsf@zork.zork.net> <6upu4ph8c5.fsf@zork.zork.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 2109 Lines: 50 Sean Neakums wrote: >begin Sean Neakums quotation: > >>begin Steve Lord quotation: >> >>>Sean, if you could apply the xfs patches for 2.4.16 (on oss.sgi.com >>>in the projects/xfs/download/patches/2.4.16 directory) and see if >>>you could make this fail I would appreciate it. As I said, for me >>>this worked just fine - as did adding all the I/O path related >>>changes I made before Christmas. >>> >>Sure thing, I'll get that built and tested. The 2.4.16 that's >>failing for me was built on the 18th December. The cvs update >>probably didn't happen very long before that. I should try the >>io-test/emacs dump procedure on that kernel too, for completeness. >> > >I built a Linus 2.4.16, patched for XFS with the patch from the above >location, and I'm certain that the bug was not present in XFS when >that patch was generated. I successfully recreated the problem with >the CVS 2.4.16 of the 18th using the io-test procedure. (I hadn't >done this previously with io-test on that kernel; I had only tried the >Debian Emacs build up to now on that kernel.) > >I've found the best way to do this reliably is to use vmstat (I used >"vmstat 3") to watch the amount of used cache. For example, on this >machine, which has 256M, used cache stabilised at about 198M with four >copies of io-test running to four separate files, and ~1100 in the bo >column. > >At that point, I kicked off the dump, which took over a minute to >complete, and started another io-test. The machine load got to the >point where a VT switch took many seconds to be acknowledged. I then >killed one of the io-test instances and attempted to start the dumped >Emacs. The dumped Emacsen started perfectly (though very slowly) on >vanilla 2.4.16-plus-patch, but the ones dumped on the CVS-pulled >2.4.16 failed with various nasty dynamic linker errors due to the >corruption. > OK, thanks, this narrows it down even more than I had - I was running a kernel from Dec 22nd and recreating the problem. I had tried the individual patches to the I/O path and failed to recreate it - but maybe I should try that again. Steve From owner-linux-xfs@oss.sgi.com Sat Jan 5 12:18:53 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g05KIrZ12761 for linux-xfs-outgoing; Sat, 5 Jan 2002 12:18:53 -0800 Received: from deliverator.sgi.com (deliverator.sgi.com [204.94.214.10]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g05KIng12738 for ; Sat, 5 Jan 2002 12:18:49 -0800 Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id LAA01844 for ; Sat, 5 Jan 2002 11:18:31 -0800 (PST) mail_from (lord@sgi.com) Received: from tulip-e185.americas.sgi.com (tulip-e185.americas.sgi.com [128.162.185.208]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id NAA3222054; Sat, 5 Jan 2002 13:17:31 -0600 (CST) Received: from sgi.com (ea6sidS4FkJpd5btv1kY2PT+nV2YSP70@lord-h1.americas.sgi.com [206.11.101.42]) by tulip-e185.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.7) with ESMTP id NAA10584; Sat, 5 Jan 2002 13:17:30 -0600 (CST) Message-ID: <3C375239.2090505@sgi.com> Date: Sat, 05 Jan 2002 13:21:29 -0600 From: Stephen Lord User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.6) Gecko/20011120 X-Accept-Language: en-us MIME-Version: 1.0 To: "ZINKEVICIUS,MATT (HP-Loveland,ex1)" CC: "'linux-xfs@oss.sgi.com'" Subject: Re: link() messes up file attributes References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 1083 Lines: 37 ZINKEVICIUS,MATT (HP-Loveland,ex1) wrote: >Hi gang, > >We have been running specSFSv2 (NFS benchmark) against a server running XFS. >All was well previously (kernel 2.4.14), but we recently checked out the XFS >CVS (2002-01-03) and it now fails. The test fails a part of the validation >stage which does the following steps: > >1) Create a file (file1) with permissions 666 >2) Create a hardlinked file (file2) to file1 >3) Check that permissions of file1 are still 666 > >Step 3 now fails as file1 now has 644 permissions! Using the same kernel we >tried ext2 instead and everything behaved normally. If anybody wants anymore >detail just let me know. > >Matt Zinkevicius >Software Engineer >Network Storage Array Solutions >Hewlett-Packard > Can you try this: Edit fs/xfs/linux/xfs_super.c and comment out these lines: fh_to_dentry: linvfs_fh_to_dentry, dentry_to_fh: linvfs_dentry_to_fh, At around line 907 and try again. I doubt it will fix it, but it is worth a shot. This will change the calls NFS uses to interact with XFS. Steve From owner-linux-xfs@oss.sgi.com Sat Jan 5 12:33:34 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g05KXYF13004 for linux-xfs-outgoing; Sat, 5 Jan 2002 12:33:34 -0800 Received: from zork.zork.net (zork.zork.net [64.81.65.8]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g05KXMg12981 for ; Sat, 5 Jan 2002 12:33:22 -0800 Received: from localhost (zork.zork.net) [127.0.0.1] by zork.zork.net with esmtp (Exim 3.33 #1 (Debian)) id 16MwZE-0008SB-00; Sat, 05 Jan 2002 11:33:20 -0800 To: Linux XFS Subject: Oops on 2.4.17-xfs From: Sean Neakums X-Message-Flag: Message text advisory: PRURIENT SUBTEXT, IGNORATIO ELENCHI X-Mailer: Norman Mail-Followup-To: Linux XFS Date: Sat, 05 Jan 2002 19:33:20 +0000 Message-ID: <6ur8p4fv9b.fsf@zork.zork.net> User-Agent: Gnus/5.090004 (Oort Gnus v0.04) Emacs/21.1 (i386-debian-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 4949 Lines: 112 I must be charged up with bogons, or something. I just got the following Oops during a dist-upgrade: ksymoops 2.4.3 on i686 2.4.17-xfs-2. Options used -V (default) -k /proc/ksyms (default) -l /proc/modules (default) -o /lib/modules/2.4.17-xfs-2/ (default) -m /boot/System.map-2.4.17-xfs-2 (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. Reading Oops report from the terminal Unable to handle kernel NULL pointer dereference at virtual address 00000152 c018f164 *pde = 00000000 Oops: 0000 CPU: 0 EIP: 0010:[] Tainted: P Using defaults from ksymoops -t elf32-i386 -a i386 EFLAGS: 00010246 eax: 00000000 ebx: ffffffe8 ecx: c026c1a4 edx: c026e280 esi: c98af940 edi: cf706000 ebp: 00000000 esp: c7a09d54 ds: 0018 es: 0018 ss: 0018 Process dpkg (pid: 7123, stackpage=c7a09000) Stack: 000008d1 c347f830 00000000 00000008 c01a496c cf706000 00000000 00309a8a 00000000 00000000 c7a09dfc 00000000 00000000 c7a09df4 c7a09e0c 00000000 c7a09ecc 00000000 00000010 00000288 00000008 c019f494 00000000 c347f848 Call Trace: [] [] [] [] [] [] [] [] [] [] [] [] Code: 66 83 bb 6a 01 00 00 00 75 10 80 a3 50 01 00 00 f7 53 e8 65 >>EIP; c018f164 <===== Trace; c01a496c Trace; c019f494 Trace; c019fa38 Trace; c01b293e Trace; c01a3092 Trace; c018f73e Trace; c01a7caa Trace; c01b22ea Trace; c013c9cc Trace; c013ca68 Trace; c013cc68 Trace; c0106d2a Code; c018f164 00000000 <_EIP>: Code; c018f164 <===== 0: 66 83 bb 6a 01 00 00 cmpw $0x0,0x16a(%ebx) <===== Code; c018f16a 7: 00 Code; c018f16c 8: 75 10 jne 1a <_EIP+0x1a> c018f17e Code; c018f16e a: 80 a3 50 01 00 00 f7 andb $0xf7,0x150(%ebx) Code; c018f174 11: 53 push %ebx Code; c018f176 12: e8 65 00 00 00 call 7c <_EIP+0x7c> c018f1e0 1 warning issued. Results may not be reliable. Modules list: Module Size Used by Tainted: P bsd_comp 3968 0 (autoclean) ipt_LOG 3200 3 (autoclean) ipt_state 608 1 (autoclean) ipt_REJECT 2816 3 (autoclean) nfs 71996 3 (autoclean) nfsd 65248 8 (autoclean) lockd 46912 1 (autoclean) [nfs nfsd] sunrpc 62676 1 (autoclean) [nfs nfsd lockd] 3c509 7104 1 (autoclean) hid 12576 0 (unused) mousedev 3872 1 input 3136 0 [hid mousedev] sg 24484 0 (unused) sr_mod 11448 0 cdrom 26656 0 [sr_mod] ide-scsi 7456 0 scsi_mod 78440 3 [sg sr_mod ide-scsi] usb-uhci 22084 0 (unused) usbcore 48928 1 [hid usb-uhci] ip_conntrack_ftp 3296 0 (unused) ip_conntrack 14284 2 [ipt_state ip_conntrack_ftp] iptable_filter 1728 0 (unused) ip_tables 10400 4 [ipt_LOG ipt_state ipt_REJECT iptable_filter] sb 7392 1 sb_lib 33248 0 [sb] uart401 6048 0 [sb_lib] parport_pc 21352 0 parport 24288 0 [parport_pc] sound 52172 1 [sb_lib uart401] soundcore 3460 5 [sb_lib sound] ppp_deflate 39072 0 ppp_async 6336 1 ppp_generic 16872 3 [bsd_comp ppp_deflate ppp_async] slhc 4304 1 [ppp_generic] rtc 6168 0 (autoclean) -- ///////////////// | | The spark of a pin | (require 'gnu) | dropping, falling feather-like. \\\\\\\\\\\\\\\\\ | | There is too much noise. From owner-linux-xfs@oss.sgi.com Sat Jan 5 13:25:43 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g05LPhT13708 for linux-xfs-outgoing; Sat, 5 Jan 2002 13:25:43 -0800 Received: from zork.zork.net (zork.zork.net [64.81.65.8]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g05LPdg13601 for ; Sat, 5 Jan 2002 13:25:39 -0800 Received: from localhost (zork.zork.net) [127.0.0.1] by zork.zork.net with esmtp (Exim 3.33 #1 (Debian)) id 16MxNp-0000bS-00; Sat, 05 Jan 2002 12:25:37 -0800 To: Linux XFS Subject: Re: file corruption during emacs build on XFS logical volume References: <1010174871.30053.6.camel@jen.americas.sgi.com> <1010176193.2938.14.camel@UberGeek> <1010176393.30037.9.camel@jen.americas.sgi.com> <1010179700.30053.13.camel@jen.americas.sgi.com> <1010187371.30053.32.camel@jen.americas.sgi.com> <6uy9jdhdsr.fsf@zork.zork.net> <6upu4ph8c5.fsf@zork.zork.net> <3C37511F.6050809@sgi.com> From: Sean Neakums X-Message-Flag: Message text advisory: ARGUMENTUM AD HOMINEM, BRAZEN SELF-DECEIT X-Mailer: Norman Mail-Followup-To: Linux XFS Date: Sat, 05 Jan 2002 20:25:37 +0000 In-Reply-To: <3C37511F.6050809@sgi.com> (Stephen Lord's message of "Sat, 05 Jan 2002 13:16:47 -0600") Message-ID: <6uheq0fsu6.fsf@zork.zork.net> User-Agent: Gnus/5.090004 (Oort Gnus v0.04) Emacs/21.1 (i386-debian-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 643 Lines: 15 begin Stephen Lord quotation: > OK, thanks, this narrows it down even more than I had - I was > running a kernel from Dec 22nd and recreating the problem. I had > tried the individual patches to the I/O path and failed to recreate > it - but maybe I should try that again. I just found a kernel from December 8 (I had removed it from lilo.conf, but forgotten to delete the kernel itself and the modules) and I cannot recreate on that. -- ///////////////// | | The spark of a pin | (require 'gnu) | dropping, falling feather-like. \\\\\\\\\\\\\\\\\ | | There is too much noise. From owner-linux-xfs@oss.sgi.com Sat Jan 5 14:13:53 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g05MDri19826 for linux-xfs-outgoing; Sat, 5 Jan 2002 14:13:53 -0800 Received: from ms1.adiis.net (IDENT:root@ms1.adiis.net [207.177.36.3]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g05MDlg19804 for ; Sat, 5 Jan 2002 14:13:48 -0800 Received: (from root@localhost) by ms1.adiis.net (8.11.2/8.11.2) id g05MCqX08219 for linux-xfs@oss.sgi.com; Sat, 5 Jan 2002 16:12:52 -0600 Received: from hoi-dsl-cust33.adiis.net (rbutler@hoi-dsl-cust33.adiis.net [206.72.1.68]) by ms1.adiis.net (8.11.2/8.11.2) with ESMTP id g05MCpV08165 for ; Sat, 5 Jan 2002 16:12:51 -0600 Subject: Release 1.0.2 Installer (RedHat) Rescue problems From: Ryan Butler To: Linux XFS Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/1.0.0.99+cvs.2001.12.18.08.57 (Preview Release) Date: 05 Jan 2002 15:13:43 -0600 Message-Id: <1010265223.5095.7.camel@hoi-dsl-cust33.adiis.net> Mime-Version: 1.0 X-Virus-Scanned: by AMaViS perl-11 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 1250 Lines: 35 Hello, Our mail server was running kernel 2.4.5 + XFS, in a raid 1 configuration for /. After about 100 days, it started deadlocking processes and doing weird things, so I tried to reboot it and upgrade to 2.4.17+xfs, the shutdown was hectic and resulted in the reset switch due to more deadlocking processes. So I thought it would be smart to run xfs_repair. I used the Release 1.0.2 installer rescue mode to try this. One thing I have noticed between 1.0.1 and 1.0.2 is with 1.0.1, you could have the installer search and find your installation, then unmount /mnt/sysimage/boot and /mnt/sysimage then run xfs_repair, with 1.0.2 you now have to skip the auto detection of the installation as if you do mount the installation, you are now unable to unmount /mnt/sysimage. so I inserted the raid1 module and tried to run xfs_repair on the raid device and I keep getting invalid superblock errors and repair will not run, if I let it detect the installation it mounts it fine (so the superblock isn't missint or corrupted) but I'm unable to repair since I can't unmount. Is this a bug, or something that I'm needing to do and missing? Thanks -- Ryan Butler ADI Internet Solutions rbutler@adiis.net Work: 641-753-8080 Fax: 641-753-7779 From owner-linux-xfs@oss.sgi.com Sat Jan 5 14:31:25 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g05MVPc20291 for linux-xfs-outgoing; Sat, 5 Jan 2002 14:31:25 -0800 Received: from lynx.adilger.int (h24-64-71-161.cg.shawcable.net [24.64.71.161]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g05MVBg20244 for ; Sat, 5 Jan 2002 14:31:11 -0800 Received: (from adilger@localhost) by lynx.adilger.int (8.11.2/8.11.2) id g05LPRX03787; Sat, 5 Jan 2002 14:25:27 -0700 Date: Sat, 5 Jan 2002 14:25:27 -0700 From: Andreas Dilger To: Adrian Head Cc: Eric Sandeen , Linux XFS Mailing List , linux-lvm@sistina.com Subject: Re: [linux-lvm] Re: Unable to get XFS, ext3, reiserfs & LVM to coexist happily Message-ID: <20020105142527.I12868@lynx.no> Mail-Followup-To: Adrian Head , Eric Sandeen , Linux XFS Mailing List , linux-lvm@sistina.com References: <200201020451.g024pPg00867@oss.sgi.com> <20020104163939.C12868@lynx.no> <200201050212.TAA16774@cthulhu.turbolabs.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.4i In-Reply-To: <200201050212.TAA16774@cthulhu.turbolabs.com>; from ahead@bigpond.net.au on Sat, Jan 05, 2002 at 12:12:40PM +1000 X-GPG-Key: 1024D/0D35BED6 X-GPG-Fingerprint: 7A37 5D79 BF1B CECA D44F 8A29 A488 39F5 0D35 BED6 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 1807 Lines: 46 On Jan 05, 2002 12:12 +1000, Adrian Head wrote: > On Sat, 5 Jan 2002 09:39, Andreas Dilger wrote: > > Can you repeat this test, but skip the ext3 snapshot creation part of it > > entirely (i.e. create a reiserfs snapshot and an XFS snapshot, without > > changing the kernel)? I'm wondering if XFS is getting an old inode that > > ext3 was using, but either ext3 or XFS is not clearing it, so that is why > > it is calling into ext3. Also, are you using ext3 on other filesystems in > > this computer? > > Yes there are other volumes using ext3. > /boot 20M ext3 > / 512M ext3 > /usr 512M ext3 > /var 512M ext3 > swap 768M > /tmp 128M reiserfs LVM > /cache 512M reiserfs LVM > /chroot 512M ext3 LVM > /usr/src 4096Mreiserfs LVM > /data ~30G xfs LVM > > the tests are done on /chroot for ext3, > /usr/src for resierfs & /data for xfs. > > I can skip the ext3 snapshot creation part - each test is done on its own > logical volume; however, in the dark dim past any of these could have had > other filesystems on them. > Does this sound sensible? > 1) Run tests without doing the ext3 snapshot creation, then > 2) dd the entire lv that is giving problems and try again? Hmm, no I'm not worried about old filesystems on the disk. I thought maybe you were running the tests on the same LV, and creating new filesystems on a single LV between the tests. What I'm worried about is old inodes being kept in memory between the tests. If the tests are being run on separate LVs, then that is not a possibility. I guess what is needed is a real oops report from the ext3 problem. Maybe Andrew or Stephen can figure it out. Cheers, Andreas -- Andreas Dilger http://sourceforge.net/projects/ext2resize/ http://www-mddsp.enel.ucalgary.ca/People/adilger/ From owner-linux-xfs@oss.sgi.com Sat Jan 5 16:09:11 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0609BW28251 for linux-xfs-outgoing; Sat, 5 Jan 2002 16:09:11 -0800 Received: from lynx.adilger.int (h24-64-71-161.cg.shawcable.net [24.64.71.161]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g06097g28229 for ; Sat, 5 Jan 2002 16:09:07 -0800 Received: (from adilger@localhost) by lynx.adilger.int (8.11.2/8.11.2) id g05N8nc04000; Sat, 5 Jan 2002 16:08:49 -0700 Date: Sat, 5 Jan 2002 16:08:49 -0700 From: Andreas Dilger To: Adrian Head Cc: Eric Sandeen , Linux XFS Mailing List , linux-lvm@sistina.com Subject: Re: [linux-lvm] Re: Unable to get XFS, ext3, reiserfs & LVM to coexist happily Message-ID: <20020105160849.J12868@lynx.no> Mail-Followup-To: Adrian Head , Eric Sandeen , Linux XFS Mailing List , linux-lvm@sistina.com References: <200201020451.g024pPg00867@oss.sgi.com> <200201042349.g04Nnag26320@oss.sgi.com> <1010186076.1414.22.camel@stout.americas.sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.4i In-Reply-To: ; from ahead@bigpond.net.au on Sat, Jan 05, 2002 at 12:46:32PM +1000 X-GPG-Key: 1024D/0D35BED6 X-GPG-Fingerprint: 7A37 5D79 BF1B CECA D44F 8A29 A488 39F5 0D35 BED6 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 336 Lines: 12 On Jan 05, 2002 12:46 +1000, Adrian Head wrote: > This is the full output from kdb when trying to create a snapshot on an XFS > volume for me. I've forwarded this to ext2-devel so the ext3 folks see it. Cheers, Andreas -- Andreas Dilger http://sourceforge.net/projects/ext2resize/ http://www-mddsp.enel.ucalgary.ca/People/adilger/ From owner-linux-xfs@oss.sgi.com Sat Jan 5 18:23:38 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g062NcL29975 for linux-xfs-outgoing; Sat, 5 Jan 2002 18:23:38 -0800 Received: from mail.ocs.com.au (mail.ocs.com.au [203.34.97.2]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g062NPg29953 for ; Sat, 5 Jan 2002 18:23:27 -0800 Received: (qmail 2543 invoked from network); 6 Jan 2002 01:23:20 -0000 Received: from ocs3.intra.ocs.com.au (192.168.255.3) by mail.ocs.com.au with SMTP; 6 Jan 2002 01:23:20 -0000 Received: by ocs3.intra.ocs.com.au (Postfix, from userid 16331) id 014D4300095; Sun, 6 Jan 2002 12:23:17 +1100 (EST) Received: from ocs3.intra.ocs.com.au (localhost [127.0.0.1]) by ocs3.intra.ocs.com.au (Postfix) with ESMTP id D0F4D94 for ; Sun, 6 Jan 2002 12:23:17 +1100 (EST) X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 From: Keith Owens To: linux-xfs@oss.sgi.com Subject: LVM causing memory corruption Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sun, 06 Jan 2002 12:23:12 +1100 Message-ID: <18764.1010280192@ocs3.intra.ocs.com.au> Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 3086 Lines: 92 This just appeared on linux-kernel. It might throw some light on recent bug reports about LVM. ------- Forwarded Message Date: Sat, 5 Jan 2002 17:47:04 -0700 From: Richard Gooch To: Jason Thomas Cc: linux-kernel , marcelo@conectiva.com.br Subject: Re: oops in devfs Jason Thomas writes: > Okay same thing. > > On Thu, Jan 03, 2002 at 12:24:23AM -0700, Richard Gooch wrote: > > Grab devfs-patch-v199.6 from your local kernel.org mirror site and try > > again. If you still have the same problem, send the new ksymoops > > output as well as *complete* kernel boot logs. > > they are attached. [...] > LVM version 1.0.1-rc4(ish)(03/10/2001) Ah! You're using LVM! There are known bugs in LVM which cause memory corruptions. I told Heinz about this on 16-DEC, but it appears the CVS tree hasn't been updated yet. So grab the latest CVS tree (which fixes some bugs) and then apply the appended patch (which fixes more bugs). You definately need both. The patch should be applied in the drivers/md directory. I'm afraid that you will need to manually apply this patch, because the LVM CVS tree has a pile of #ifdef CONFIG_DEVFS_FS's in it, whereas the LVM code in the kernel tree (which is what I generated the patch against) has these #ifdef's stripped. I've offered to Marcelo to take the current LVM CVS, apply my fixes and send him a patch. That would avoid this problem coming up again (and again). I haven't had a response yet. Perhaps he's still recovering from his holiday. I hope so, because that probably means he enjoyed himself :-) Marcelo: will you accept such a patch? Regards, Richard.... Permanent: rgooch@atnf.csiro.au Current: rgooch@ras.ucalgary.ca --- lvm-fs.c~ Sun Nov 11 11:09:32 2001 +++ lvm-fs.c Sun Dec 16 17:37:32 2001 @@ -30,6 +30,7 @@ * 04/10/2001 - corrected devfs_register() call in lvm_init_fs() * 11/04/2001 - don't devfs_register("lvm") as user-space always does it * 10/05/2001 - show more of PV name in /proc/lvm/global + * 16/12/2001 - fix devfs unregister order and prevent duplicate unreg (REG) * */ @@ -138,7 +139,7 @@ int i; devfs_unregister(ch_devfs_handle[vg_ptr->vg_number]); - devfs_unregister(vg_devfs_handle[vg_ptr->vg_number]); + ch_devfs_handle[vg_ptr->vg_number] = NULL; /* remove lv's */ for(i = 0; i < vg_ptr->lv_max; i++) @@ -148,6 +149,10 @@ for(i = 0; i < vg_ptr->pv_max; i++) if(vg_ptr->pv[i]) lvm_fs_remove_pv(vg_ptr, vg_ptr->pv[i]); + /* must not remove directory before leaf nodes */ + devfs_unregister(vg_devfs_handle[vg_ptr->vg_number]); + vg_devfs_handle[vg_ptr->vg_number] = NULL; + if(vg_ptr->vg_dir_pde) { remove_proc_entry(LVM_LV_SUBDIR, vg_ptr->vg_dir_pde); vg_ptr->lv_subdir_pde = NULL; @@ -189,6 +194,7 @@ void lvm_fs_remove_lv(vg_t *vg_ptr, lv_t *lv) { devfs_unregister(lv_devfs_handle[MINOR(lv->lv_dev)]); + lv_devfs_handle[MINOR(lv->lv_dev)] = NULL; if(vg_ptr->lv_subdir_pde) { const char *name = _basename(lv->lv_name); - ------- End of Forwarded Message From owner-linux-xfs@oss.sgi.com Sat Jan 5 20:20:04 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g064K4u31360 for linux-xfs-outgoing; Sat, 5 Jan 2002 20:20:04 -0800 Received: from c144417-a.mntp1.il.home.com (12-248-156-110.client.attbi.com [12.248.156.110]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g064Jng31336 for ; Sat, 5 Jan 2002 20:19:49 -0800 Received: (qmail 32158 invoked by uid 500); 6 Jan 2002 03:23:14 -0000 Date: Sat, 5 Jan 2002 21:23:14 -0600 (CST) From: Brian Johnson X-X-Sender: To: Mike Burger cc: Linux XFS Subject: Re: Quota block usage out of date until sync Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 4867 Lines: 129 This behavior is different from ext2/ext3. In ext2/3 the data does not need to be written to disk to be reflected in the quota. I have tested this and my output is below. I watched vmstat and xfs showed the correct block quota only after the 1024 kbytes where written to disk while ext2/3 showed it right after dd was run but before it was written to disk. It seems that in XFS repquota show only what was written to disk and ext2/3 shows what was is on the disk plus what is in the buffer so the block quota number is never out of date. ext2 (I think I remember testing this with ext3 and it was the same): Here repquota shows the correct block change before the data is written to disk. # /usr/sbin/repquota /users | egrep "^root" ;\ > dd count=1024 bs=1024 if=/dev/zero of=writetest ;\ > /usr/sbin/repquota /users | egrep "^root" ;\ > sleep 30 ;\ > /usr/sbin/repquota /users | egrep "^root" ;\ > sleep 10 ;\ > /usr/sbin/repquota /users | egrep "^root" root -- 4238746 0 0 129504 0 0 1024+0 records in 1024+0 records out root -- 4239775 0 0 129505 0 0 << "vmstat 1" output with this line that shows write to disk occured here in time r b w swpd free buff cache si so bi bo in cs us sy id 0 0 0 64012 18344 260140 152864 0 0 0 1049 112 20 0 6 94 >> root -- 4239775 0 0 129505 0 0 root -- 4239775 0 0 129505 0 0 XFS: Here repquota shows the block change only after the data is written to disk. # /usr/sbin/repquota /users | egrep "^root" ;\ > dd count=1024 bs=1024 if=/dev/zero of=writetest ;\ > /usr/sbin/repquota /users | egrep "^root" ;\ > sleep 30 ;\ > /usr/sbin/repquota /users | egrep "^root" ;\ > sleep 10 ;\ > /usr/sbin/repquota /users | egrep "^root" root -- 7200 0 0 20 0 0 1024+0 records in 1024+0 records out root -- 7200 0 0 21 0 0 root -- 7200 0 0 21 0 0 << "vmstat 1" output with this line that shows write to disk occured here in time r b w swpd free buff cache si so bi bo in cs us sy id 0 0 0 21516 2904 0 10168 0 0 0 1024 114 14 2 8 90 >> root -- 8224 0 0 21 0 0 So it seems ext2 shows not what is on disk, but what the user has written and may be in the buffer and XFS just shows what is on the disk. It looks like XFS knows about the number of block written because if it says I have 10000 kbytes free and I have just written 9000 kbytes that has not been written to disk and I try to write another 9000 kbytes (because repquota shows I have 10000 kB free) the file will be cut off at 1000 kB. So XFS seems to know the blocks witten by the user (not just what is on the disk) but repquota is reporting something else. Brian On Fri, 4 Jan 2002, Mike Burger wrote: > To me, this makes perfect sense. You can't really get the used block > count to change until the blocks have actually been written, and teh > allocation tables written along with them. > > It seems to me, and I'm not involved in any way with the development > project, that you'd be asking for a lot of trouble to try to update part > of the allocation table without actually having had the data written to > disk. > > On Fri, 4 Jan 2002, Brian Johnson wrote: > > > I noticed the block usage amount repquota reports is out of date for about > > 40 sec after a file is written or until sync is run. > > > > For example, > > # /usr/sbin/repquota /users | grep root ;\ > > dd count=1024 bs=1024 if=/dev/zero of=writetest ;\ > > /usr/sbin/repquota /users | grep root ;\ > > sleep 30 ;\ > > /usr/sbin/repquota /users | grep root ;\ > > sleep 10 ;\ > > /usr/sbin/repquota /users | grep root > > > > Produces: > > > > root -- 6176 0 0 19 0 0 > > 1024+0 records in > > 1024+0 records out > > root -- 6176 0 0 20 0 0 > > root -- 6176 0 0 20 0 0 > > root -- 7200 0 0 20 0 0 > > > > > > Running sync after the write gives up to date usage data: > > > > # /usr/sbin/repquota /users | grep root ;\ > > dd count=1024 bs=1024 if=/dev/zero of=writetest2 ;\ > > sync ;\ > > /usr/sbin/repquota /users | grep root > > > > root -- 7200 0 0 20 0 0 > > 1024+0 records in > > 1024+0 records out > > root -- 8224 0 0 21 0 0 > > > > > > Is there a way to get the number of used blocks that is not out of date? I > > am running kernel 2.4.17 from CVS and also have tested this on the 1.0.2a > > release. > > > > Thanks, > > Brian > > > > > > From owner-linux-xfs@oss.sgi.com Sat Jan 5 23:16:34 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g067GYD01052 for linux-xfs-outgoing; Sat, 5 Jan 2002 23:16:34 -0800 Received: from mta02bw.bigpond.com (mta02bw.bigpond.com [139.134.6.34]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g067GPg01029 for ; Sat, 5 Jan 2002 23:16:25 -0800 Message-Id: <200201060716.g067GPg01029@oss.sgi.com> Received: from there ([144.135.24.81]) by mta02bw.bigpond.com (Netscape Messaging Server 4.15) with SMTP id GPI72R00.HMM for ; Sun, 6 Jan 2002 16:23:15 +1000 Received: from CPE-144-137-138-230.qld.bigpond.net.au ([144.137.138.230]) by bwmam05.mailsvc.email.bigpond.com(MailRouter V3.0h 44/7947922); 06 Jan 2002 16:16:15 Content-Type: text/plain; charset="us-ascii" From: Adrian Head To: Linux XFS Mailing List Subject: Re: [linux-lvm] Re: Unable to get XFS, ext3, reiserfs & LVM to coexist happily Date: Sun, 6 Jan 2002 16:16:12 +1000 X-Mailer: KMail [version 1.3.1] References: <200201020451.g024pPg00867@oss.sgi.com> <20020104163939.C12868@lynx.no> <200201050438.g054c2g30533@oss.sgi.com> In-Reply-To: <200201050438.g054c2g30533@oss.sgi.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 1598 Lines: 49 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 The issue about lvm-1.0.1rc4 being more robust than lvm-1.0.1 when snapshot creation fails has been moved directly to linux-lvm. For those who are interested you can find the thread here: http://marc.theaimsgroup.com/?l=linux-lvm&m=101029758204374&w=2 On Sat, 5 Jan 2002 13:37, Adrian Head wrote: > Andreas or any other LVM gurus, > > This is related to but not imeadiately concerned with the problem we have > been discussing. > > When lvcreate dies when creating an XFS snapshot it doesn't finish the > snapshot creation and although lvdisplay shows that the XFS lv has an > active snapshot (shows even its name) lvdisplay tells me that the snapshot > doesn't exist and therefore, cannot be removed. > > During the reboot the machine fails to run through the startup scripts and > dies somewhere within mount. > > I have found that kernels without the lvm-1.0.1 upgrade patch are able to > carry on and even fix the half created snapshot whereas kernels with the > lvm-1.0.1 upgrade patch are unable to deal with the problem snapshot and > just die. > > Are you aware of what this might be? > > And if this is going to be the default behaviour in future versions of LVM > how would I recover using a lvm-1.0.1 patched kernel? > > Just interested > > Thanks - -- Adrian Head (Public Key available on request.) -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE8N+uv8ZJI8OvSkAcRAqq7AKCfkgEiTEjx1alsyFH/lu5gR3mohgCdGCyu V4jJZRCXm177Nd7jgqnTXR4= =QEw1 -----END PGP SIGNATURE----- From owner-linux-xfs@oss.sgi.com Sat Jan 5 23:23:16 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g067NGB01223 for linux-xfs-outgoing; Sat, 5 Jan 2002 23:23:16 -0800 Received: from mta03bw.bigpond.com (mta03bw.bigpond.com [139.134.6.86]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g067Mhg01197 for ; Sat, 5 Jan 2002 23:22:43 -0800 Message-Id: <200201060722.g067Mhg01197@oss.sgi.com> Received: from there ([144.135.24.81]) by mta03bw.bigpond.com (Netscape Messaging Server 4.15) with SMTP id GPI7D900.4YV; Sun, 6 Jan 2002 16:29:33 +1000 Received: from CPE-144-137-138-230.qld.bigpond.net.au ([144.137.138.230]) by bwmam05.mailsvc.email.bigpond.com(MailRouter V3.0h 44/7952592); 06 Jan 2002 16:22:33 Content-Type: text/plain; charset="us-ascii" From: Adrian Head To: Eric Sandeen Subject: Re: Unable to get XFS, ext3, reiserfs & LVM to coexist happily Date: Sun, 6 Jan 2002 16:22:28 +1000 X-Mailer: KMail [version 1.3.1] Cc: Linux XFS Mailing List , linux-lvm@sistina.com References: <200201020451.g024pPg00867@oss.sgi.com> <1010186076.1414.22.camel@stout.americas.sgi.com> <200201050346.g053kmg29738@oss.sgi.com> In-Reply-To: <200201050346.g053kmg29738@oss.sgi.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 15482 Lines: 307 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I have upgraded the lvm in the kernel to the CVS version from the sistina site. The lvm-1.0.1 upgrade patch it generates is different from the previous one used. The kdb output is pretty much identical though. What I will do next is to remove ext3 from the kernel and see what happens as well as upgrade to the ext3 CVS and see what happens. This is the full Oops output when trying to create an XFS snapshot. 2.4.17-xfs + lvm-1.0.1 upgrade (from LVM CVS) + VFS-lock Entering kdb (current=0xd5db2000, pid 934) Oops: Oops due to oops @ 0xc015bc06 eax = 0x748b5356 ebx = 0xc019fdf0 ecx = 0xd7894040 edx = 0x00000000 esi = 0xd5db2000 edi = 0xd7894040 esp = 0xd5db3eac eip = 0xc015bc06 ebp = 0xd7ed4800 xss = 0x00000018 xcs = 0x00000010 eflags = 0x00010286 xds = 0x00000018 xes = 0x00000018 origeax = 0xffffffff ®s = 0xd5db3e78 kdb> bt EBP EIP Function(args) 0xd7ed4800 0xc015bc06 journal_start+0x36 (0xd7ed4800, 0x1, 0x40018000, 0xd5db3f5c, 0x2) kernel .text 0xc0100000 0xc015bbd0 0xc015bcb0 0xc0156fd8 ext3_dirty_inode+0x58 (0xd7894040) kernel .text 0xc0100000 0xc0156f80 0xc0157050 0xc0141b1e __mark_inode_dirty+0x2e (0xd7894040, 0x1) kernel .text 0xc0100000 0xc0141af0 0xc0141b70 0xc0143001 update_atime+0x51 (0xd7894040, 0x6d6, 0x1, 0x0, 0x6d6) kernel .text 0xc0100000 0xc0142fb0 0xc0143010 0xc01254ac do_generic_file_read+0x40c (0xd7757840, 0xd7757860, 0xd5db3f5c, 0xc0125690, 0x6d6) kernel .text 0xc0100000 0xc01250a0 0xc01254c0 0xc012576a generic_file_read+0x7a (0xd7757840, 0x40018000, 0x1000, 0xd7757860, 0x0) kernel .text 0xc0100000 0xc01256f0 0xc0125810 0xc0130cf5 sys_read+0x95 (0x4, 0x40018000, 0x1000, 0x8086ab0, 0x40018000) kernel .text 0xc0100000 0xc0130c60 0xc0130d30 0xc0106d1b system_call+0x33 kernel .text 0xc0100000 0xc0106ce8 0xc0106d20 kdb> btp 934 EBP EIP Function(args) 0xc019fdf0 0xc015bc06 journal_start+0x36 (0xd7ed4800, 0x1, 0x40018000, 0xd5db3f5c, 0x2) kernel .text 0xc0100000 0xc015bbd0 0xc015bcb0 0xc0156fd8 ext3_dirty_inode+0x58 (0xd7894040) kernel .text 0xc0100000 0xc0156f80 0xc0157050 0xc0141b1e __mark_inode_dirty+0x2e (0xd7894040, 0x1) kernel .text 0xc0100000 0xc0141af0 0xc0141b70 0xc0143001 update_atime+0x51 (0xd7894040, 0x6d6, 0x1, 0x0, 0x6d6) kernel .text 0xc0100000 0xc0142fb0 0xc0143010 0xc01254ac do_generic_file_read+0x40c (0xd7757840, 0xd7757860, 0xd5db3f5c, 0xc0125690, 0x6d6) kernel .text 0xc0100000 0xc01250a0 0xc01254c0 0xc012576a generic_file_read+0x7a (0xd7757840, 0x40018000, 0x1000, 0xd7757860, 0x0) kernel .text 0xc0100000 0xc01256f0 0xc0125810 0xc0130cf5 sys_read+0x95 (0x4, 0x40018000, 0x1000, 0x8086ab0, 0x40018000) kernel .text 0xc0100000 0xc0130c60 0xc0130d30 0xc0106d1b system_call+0x33 kernel .text 0xc0100000 0xc0106ce8 0xc0106d20 kdb> ps Task Addr Pid Parent [*] cpu State Thread Command 0xd7fe2000 00000001 00000000 1 000 stop 0xd7fe2270 init 0xc163c000 00000002 00000001 1 000 stop 0xc163c270 keventd 0xc1638000 00000003 00000000 1 000 stop 0xc1638270 ksoftirqd_CPU0 0xc1636000 00000004 00000000 1 000 stop 0xc1636270 kswapd 0xc1634000 00000005 00000000 1 000 stop 0xc1634270 bdflush 0xc1632000 00000006 00000000 1 000 stop 0xc1632270 kupdated 0xd7ec4000 00000007 00000001 1 000 stop 0xd7ec4270 mdrecoveryd 0xd7eae000 00000008 00000001 1 000 stop 0xd7eae270 raid5d 0xd7b32000 00000009 00000001 1 000 stop 0xd7b32270 kjournald 0xd72a6000 00000153 00000001 1 000 stop 0xd72a6270 kjournald 0xd729a000 00000154 00000001 1 000 stop 0xd729a270 kjournald 0xd7292000 00000155 00000001 1 000 stop 0xd7292270 kjournald 0xd7172000 00000157 00000001 1 000 stop 0xd7172270 kreiserfsd 0xd70ac000 00000158 00000001 1 000 stop 0xd70ac270 kjournald 0xd6f68000 00000160 00000001 1 000 stop 0xd6f68270 pagebuf_daemon 0xd6256000 00000523 00000001 1 000 stop 0xd6256270 dhcpcd 0xd77e0000 00000659 00000001 1 000 stop 0xd77e0270 syslogd 0xd6212000 00000664 00000001 1 000 stop 0xd6212270 klogd 0xd61a2000 00000684 00000001 1 000 stop 0xd61a2270 portmap 0xd60aa000 00000712 00000001 1 000 stop 0xd60aa270 rpc.statd 0xd5f74000 00000825 00000001 1 000 stop 0xd5f74270 crond more> 0xd5f5e000 00000861 00000001 1 000 stop 0xd5f5e270 atd 0xd602c000 00000868 00000001 1 000 stop 0xd602c270 login 0xd5f48000 00000869 00000001 1 000 stop 0xd5f48270 mingetty 0xd5fa2000 00000870 00000001 1 000 stop 0xd5fa2270 mingetty 0xd5f5a000 00000871 00000001 1 000 stop 0xd5f5a270 mingetty 0xd63a8000 00000872 00000001 1 000 stop 0xd63a8270 mingetty 0xd6008000 00000873 00000001 1 000 stop 0xd6008270 mingetty 0xd5f76000 00000874 00000001 1 000 stop 0xd5f76270 mgetty 0xd74aa000 00000877 00000868 1 000 stop 0xd74aa270 bash 0xd5db2000 00000934 00000877 1 000 run 0xd5db2270*lvcreate kdb> id %eip 0xc015bc06 journal_start+0x36: cmp %ebp,(%eax) 0xc015bc08 journal_start+0x38: je 0xc015bc2d journal_start+0x5d: 0xc015bc0a journal_start+0x3a: push $0xc022e920 0xc015bc0f journal_start+0x3f: push $0xe1 0xc015bc14 journal_start+0x44: push $0xc022a62b 0xc015bc19 journal_start+0x49: push $0xc0229f00 0xc015bc1e journal_start+0x4e: push $0xc022c9e0 0xc015bc23 journal_start+0x53: call 0xc0115380 printk: 0xc015bc28 journal_start+0x58: ud2a 0xc015bc2a journal_start+0x5a: add $0x14,%esp 0xc015bc2d journal_start+0x5d: incl 0x8(%ebx) 0xc015bc30 journal_start+0x60: jmp 0xc015bca0 journal_start+0xd0: 0xc015bc32 journal_start+0x62: push $0x1 0xc015bc34 journal_start+0x64: push $0xf0 0xc015bc39 journal_start+0x69: push $0x14 0xc015bc3b journal_start+0x6b: push $0xc0229f00 kdb> go Oops: 0000 CPU: 0 EIP: 0010:[] Not tainted EFLAGS: 00010286 eax: 748b5356 ebx: c019fdf0 ecx: d7894040 edx: 00000000 esi: d5db2000 edi: d7894040 ebp: d7ed4800 esp: d5db3eac ds: 0018 es: 0018 ss: 0018 Process lvcreate (pid: 934, stackpage=d5db3000) Stack: c019fdf0 c019fdf0 ffffffe2 d7894040 00000000 c0156fd8 d7ed4800 00000001 40018000 d5db3f5c 00000002 00000018 d7894040 d7b41000 00000001 c0141b1e d7894040 3c385279 d7757860 d78940f0 c0143001 d7894040 00000001 00000000 Call Trace: [] [] [] [] [] [] [] [] [] [] Code: 39 28 74 23 68 20 e9 22 c0 68 e1 00 00 00 68 2b a6 22 c0 68 On Sat, 5 Jan 2002 12:46, Adrian Head wrote: > This is the full output from kdb when trying to create a snapshot on an XFS > volume for me. > > What I was going to do next was follow Andreas Dilger's sugestion and try > again. > > Entering kdb (current=0xc7228000, pid 1435) Oops: Oops > due to oops @ 0xc015c446 > eax = 0x748b5356 ebx = 0xc01a1550 ecx = 0xd7894040 edx = 0x00000000 > esi = 0xc7228000 edi = 0xd7894040 esp = 0xc7229eac eip = 0xc015c446 > ebp = 0xd7ed4800 xss = 0x00000018 xcs = 0x00000010 eflags = 0x00010286 > xds = 0x00000018 xes = 0x00000018 origeax = 0xffffffff ®s = 0xc7229e78 > kdb> bt > EBP EIP Function(args) > 0xd7ed4800 0xc015c446 journal_start+0x36 (0xd7ed4800, 0x1, 0x40018000, > 0xc7229f5c, 0x2) > kernel .text 0xc0100000 0xc015c410 > 0xc015c4f0 0xc01571a8 ext3_dirty_inode+0x58 (0xd7894040) > kernel .text 0xc0100000 0xc0157150 > 0xc0157250 0xc0141b1e __mark_inode_dirty+0x2e (0xd7894040, 0x1) > kernel .text 0xc0100000 0xc0141af0 > 0xc0141b70 0xc0143001 update_atime+0x51 (0xd7894040, 0x6d6, 0x1, 0x0, > 0x6d6) kernel .text 0xc0100000 0xc0142fb0 0xc0143010 0xc01254ac > do_generic_file_read+0x40c (0xd5fc7740, 0xd5fc7760, 0xc7229f5c, 0xc0125690, > 0x6d6) > kernel .text 0xc0100000 0xc01250a0 > 0xc01254c0 0xc012576a generic_file_read+0x7a (0xd5fc7740, 0x40018000, > 0x1000, 0xd5fc7760, 0x0) > kernel .text 0xc0100000 0xc01256f0 > 0xc0125810 0xc0130cf5 sys_read+0x95 (0x4, 0x40018000, 0x1000, 0x8086ab0, > 0x40018000) > kernel .text 0xc0100000 0xc0130c60 > 0xc0130d30 0xc0106d1b system_call+0x33 > kernel .text 0xc0100000 0xc0106ce8 > 0xc0106d20 kdb> btp 1435 > EBP EIP Function(args) > 0xc01a1550 0xc015c446 journal_start+0x36 (0xd7ed4800, 0x1, 0x40018000, > 0xc7229f5c, 0x2) > kernel .text 0xc0100000 0xc015c410 > 0xc015c4f0 0xc01571a8 ext3_dirty_inode+0x58 (0xd7894040) > kernel .text 0xc0100000 0xc0157150 > 0xc0157250 0xc0141b1e __mark_inode_dirty+0x2e (0xd7894040, 0x1) > kernel .text 0xc0100000 0xc0141af0 > 0xc0141b70 0xc0143001 update_atime+0x51 (0xd7894040, 0x6d6, 0x1, 0x0, > 0x6d6) kernel .text 0xc0100000 0xc0142fb0 0xc0143010 0xc01254ac > do_generic_file_read+0x40c (0xd5fc7740, 0xd5fc7760, 0xc7229f5c, 0xc0125690, > 0x6d6) > kernel .text 0xc0100000 0xc01250a0 > 0xc01254c0 0xc012576a generic_file_read+0x7a (0xd5fc7740, 0x40018000, > 0x1000, 0xd5fc7760, 0x0) > kernel .text 0xc0100000 0xc01256f0 > 0xc0125810 0xc0130cf5 sys_read+0x95 (0x4, 0x40018000, 0x1000, 0x8086ab0, > 0x40018000) > kernel .text 0xc0100000 0xc0130c60 > 0xc0130d30 0xc0106d1b system_call+0x33 > kernel .text 0xc0100000 0xc0106ce8 > 0xc0106d20 kdb> ps > Task Addr Pid Parent [*] cpu State Thread Command > 0xd7fe2000 00000001 00000000 1 000 stop 0xd7fe2270 init > 0xc163c000 00000002 00000001 1 000 stop 0xc163c270 keventd > 0xc1638000 00000003 00000000 1 000 stop 0xc1638270 ksoftirqd_CPU0 > 0xc1636000 00000004 00000000 1 000 stop 0xc1636270 kswapd > 0xc1634000 00000005 00000000 1 000 stop 0xc1634270 bdflush > 0xc1632000 00000006 00000000 1 000 stop 0xc1632270 kupdated > 0xd7ec4000 00000007 00000001 1 000 stop 0xd7ec4270 mdrecoveryd > 0xd7eae000 00000008 00000001 1 000 stop 0xd7eae270 raid5d > 0xd7b32000 00000009 00000001 1 000 stop 0xd7b32270 kjournald > 0xd72a6000 00000153 00000001 1 000 stop 0xd72a6270 kjournald > 0xd729c000 00000154 00000001 1 000 stop 0xd729c270 kjournald > 0xd7292000 00000155 00000001 1 000 stop 0xd7292270 kjournald > 0xd7174000 00000157 00000001 1 000 stop 0xd7174270 kreiserfsd > 0xd70ac000 00000158 00000001 1 000 stop 0xd70ac270 kjournald > 0xd6f68000 00000160 00000001 1 000 stop 0xd6f68270 pagebuf_daemon > 0xd6250000 00000525 00000001 1 000 stop 0xd6250270 dhcpcd > 0xd6c56000 00000661 00000001 1 000 stop 0xd6c56270 syslogd > 0xd623a000 00000666 00000001 1 000 stop 0xd623a270 klogd > 0xd619e000 00000686 00000001 1 000 stop 0xd619e270 portmap > 0xd60ac000 00000714 00000001 1 000 stop 0xd60ac270 rpc.statd > 0xd62d6000 00000827 00000001 1 000 stop 0xd62d6270 crond > more> > 0xd5f3a000 00000863 00000001 1 000 stop 0xd5f3a270 atd > 0xd6a80000 00000870 00000001 1 000 stop 0xd6a80270 login > 0xd5f5a000 00000871 00000001 1 000 stop 0xd5f5a270 login > 0xd5f56000 00000872 00000001 1 000 stop 0xd5f56270 mingetty > 0xd6c9c000 00000873 00000001 1 000 stop 0xd6c9c270 mingetty > 0xd5f6a000 00000874 00000001 1 000 stop 0xd5f6a270 mingetty > 0xd6c9a000 00000875 00000001 1 000 stop 0xd6c9a270 mingetty > 0xd6338000 00000876 00000001 1 000 stop 0xd6338270 login > 0xd739c000 00000879 00000876 1 000 stop 0xd739c270 bash > 0xd5d86000 00000925 00000870 1 000 stop 0xd5d86270 bash > 0xd580c000 00000977 00000871 1 000 stop 0xd580c270 bash > 0xc7228000 00001435 00000925 1 000 run 0xc7228270*lvcreate > kdb> id %eip > 0xc015c446 journal_start+0x36: cmp %ebp,(%eax) > 0xc015c448 journal_start+0x38: je 0xc015c46d journal_start+0x5d: > 0xc015c44a journal_start+0x3a: push $0xc02309e0 > 0xc015c44f journal_start+0x3f: push $0xe1 > 0xc015c454 journal_start+0x44: push $0xc022becf > 0xc015c459 journal_start+0x49: push $0xc022b6a0 > 0xc015c45e journal_start+0x4e: push $0xc022e6a0 > 0xc015c463 journal_start+0x53: call 0xc0115380 printk: > 0xc015c468 journal_start+0x58: ud2a > 0xc015c46a journal_start+0x5a: add $0x14,%esp > 0xc015c46d journal_start+0x5d: incl 0x8(%ebx) > 0xc015c470 journal_start+0x60: jmp 0xc015c4e0 journal_start+0xd0: > 0xc015c472 journal_start+0x62: push $0x1 > 0xc015c474 journal_start+0x64: push $0xf0 > 0xc015c479 journal_start+0x69: push $0x14 > 0xc015c47b journal_start+0x6b: push $0xc022b6a0 > kdb> go > Oops: 0000 > CPU: 0 > EIP: 0010:[] Not tainted > EFLAGS: 00010286 > eax: 748b5356 ebx: c01a1550 ecx: d7894040 edx: 00000000 > esi: c7228000 edi: d7894040 ebp: d7ed4800 esp: c7229eac > ds: 0018 es: 0018 ss: 0018 > Process lvcreate (pid: 1435, stackpage=c7229000) > Stack: c01a1550 c01a1550 ffffffe2 d7894040 00000000 c01571a8 d7ed4800 > 00000001 40018000 c7229f5c 00000002 00000018 d7894040 d7b41000 00000001 > c0141b1e d7894040 3c36dd6f d5fc7760 d78940f0 c0143001 d7894040 00000001 > 00000000 Call Trace: [] [] [] [] > [] [] [] [] [] > [] > > Code: 39 28 74 23 68 e0 09 23 c0 68 e1 00 00 00 68 cf be 22 c0 68 > > On Sat, 5 Jan 2002 09:14, Eric Sandeen wrote: > > On Fri, 2002-01-04 at 16:49, Adrian Head wrote: > > > What does your backtrace look like? Its the ext3_dirt_inode in my > > > backtrace thats got me. I have compiled a kernel without ext3 so will > > > also give it a run later. > > > > No, ext3 functions do not show up for me when it oopses on snapshot > > creation: > > > > kdb> bt > > EBP EIP Function(args) > > 0xc1c2bf78 0xc013649e path_init+0x36 (0xc1c2a000) > > kernel .text 0xc0100000 0xc0136468 > > 0xc013659c 0xc1c2bf90 0xc01366cf __user_walk+0x2f (0xc1c2a000, 0x804f1bc) > > kernel .text 0xc0100000 0xc01366a0 > > 0xc01366f8 0xc1c2bfbc 0xc013381e sys_stat64+0x1a (0x8052474, 0xbfffe980, > > 0x40196154, 0x804f1bc, 0x3) kernel .text 0xc0100000 0xc0133804 0xc0133874 > > 0xc0106c5b system_call+0x33 > > kernel .text 0xc0100000 0xc0106c28 > > 0xc0106c60 > > > > > > It's trying to stat64 /dev/sda2, one of my lvm partitions. I dunno why > > this blows up. :/ > > > > The code has some fastcalls & inlines around here, though, so this may > > not be the most accurate. > > > > Still looking... > > > > -Eric - -- Adrian Head (Public Key available on request.) -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE8N+0o8ZJI8OvSkAcRAgk+AJ4/0P4qg1A2UnABK5O+0kM9jYlYfgCgn+fv GRJHFM6+Mt9CJNg9n13XoEI= =ZVhu -----END PGP SIGNATURE----- From owner-linux-xfs@oss.sgi.com Sun Jan 6 02:56:02 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g06Au2M03885 for linux-xfs-outgoing; Sun, 6 Jan 2002 02:56:02 -0800 Received: from ADSL-Bergs.RZ.RWTH-Aachen.DE (adsl-bergs.rz.RWTH-Aachen.DE [137.226.80.218]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g06Atvg03862 for ; Sun, 6 Jan 2002 02:55:57 -0800 Received: from [192.168.1.2] (helo=ralf) by ADSL-Bergs.RZ.RWTH-Aachen.DE with smtp (Exim 3.12 #1) id 16NA1s-0007TJ-00; Sun, 06 Jan 2002 10:55:48 +0100 From: "Ralf G. R. Bergs" To: "linux-xfs@oss.sgi.com" Cc: "Keith Owens" Date: Sun, 06 Jan 2002 10:55:47 +0100 Reply-To: "Ralf G. R. Bergs" X-Mailer: PMMail 2000 Professional (2.20.2380) For Windows 2000 (5.0.2195;2) In-Reply-To: <18764.1010280192@ocs3.intra.ocs.com.au> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Subject: Re: LVM causing memory corruption Message-Id: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 1173 Lines: 28 On Sun, 06 Jan 2002 12:23:12 +1100, Keith Owens wrote: >This just appeared on linux-kernel. It might throw some light on >recent bug reports about LVM. [...] >> LVM version 1.0.1-rc4(ish)(03/10/2001) > >Ah! You're using LVM! There are known bugs in LVM which cause memory >corruptions.[...] Does anyone know whether this bug also pertains to cases where LVM is compiled as a module, but isn't (actively) used? As (some of) you know, I've strange problems with a hardware RAID and xfs filesystems that are either shut down because of "memory corruption," or that exhibit mysteriously "hidden" files. However, as I just wrote in the previous paragraph, I'm NOT using LVM. The xfs partition in question is just a logical partition with a fixed size. I simply cfdisk'ed the RAID and performed a "mkfs - t xfs" on the logical partition. The LVM module doesn't get loaded therefore. -- Verkaufe Original-BMW-Raeder: L I N U X .~. http://adsl-bergs.rz.rwth-aachen.de/~rabe The Choice /V\ of a GNU /( )\ Generation ^^-^^ From owner-linux-xfs@oss.sgi.com Sun Jan 6 03:52:47 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g06Bqlv04792 for linux-xfs-outgoing; Sun, 6 Jan 2002 03:52:47 -0800 Received: from mail.ocs.com.au (mail.ocs.com.au [203.34.97.2]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g06Bqdg04770 for ; Sun, 6 Jan 2002 03:52:40 -0800 Received: (qmail 5643 invoked from network); 6 Jan 2002 10:52:34 -0000 Received: from ocs3.intra.ocs.com.au (192.168.255.3) by mail.ocs.com.au with SMTP; 6 Jan 2002 10:52:34 -0000 Received: by ocs3.intra.ocs.com.au (Postfix, from userid 16331) id 2D4FC300095; Sun, 6 Jan 2002 21:52:31 +1100 (EST) Received: from ocs3.intra.ocs.com.au (localhost [127.0.0.1]) by ocs3.intra.ocs.com.au (Postfix) with ESMTP id DD88294; Sun, 6 Jan 2002 21:52:31 +1100 (EST) X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 From: Keith Owens To: "Ralf G. R. Bergs" Cc: "linux-xfs@oss.sgi.com" Subject: Re: LVM causing memory corruption In-reply-to: Your message of "Sun, 06 Jan 2002 10:55:47 BST." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sun, 06 Jan 2002 21:52:26 +1100 Message-ID: <20829.1010314346@ocs3.intra.ocs.com.au> Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 827 Lines: 20 On Sun, 06 Jan 2002 10:55:47 +0100, "Ralf G. R. Bergs" wrote: >On Sun, 06 Jan 2002 12:23:12 +1100, Keith Owens wrote: >>This just appeared on linux-kernel. It might throw some light on >>recent bug reports about LVM. >[...] >>> LVM version 1.0.1-rc4(ish)(03/10/2001) >> >>Ah! You're using LVM! There are known bugs in LVM which cause memory >>corruptions.[...] > >Does anyone know whether this bug also pertains to cases where LVM is compiled >as a module, but isn't (actively) used? LVM has no effect when it is a module that has not been loaded. However compiling the kernel for MD (required for LVM) does affect the base kernel. Without going through all the differences between the kernel MD/LVM code and the code in the MD/LVM CVS tree, any statement would be a guess - I don't want to guess. From owner-linux-xfs@oss.sgi.com Sun Jan 6 04:04:28 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g06C4Sd05297 for linux-xfs-outgoing; Sun, 6 Jan 2002 04:04:28 -0800 Received: from ADSL-Bergs.RZ.RWTH-Aachen.DE (adsl-bergs.rz.RWTH-Aachen.DE [137.226.80.218]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g06C4Kg05272 for ; Sun, 6 Jan 2002 04:04:21 -0800 Received: from [192.168.1.2] (helo=ralf) by ADSL-Bergs.RZ.RWTH-Aachen.DE with smtp (Exim 3.12 #1) id 16NB61-0007aC-00; Sun, 06 Jan 2002 12:04:09 +0100 From: "Ralf G. R. Bergs" To: "Keith Owens" Cc: "linux-xfs@oss.sgi.com" Date: Sun, 06 Jan 2002 12:04:09 +0100 Reply-To: "Ralf G. R. Bergs" X-Mailer: PMMail 2000 Professional (2.20.2380) For Windows 2000 (5.0.2195;2) In-Reply-To: <20829.1010314346@ocs3.intra.ocs.com.au> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Subject: Re: LVM causing memory corruption Message-Id: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 1373 Lines: 37 On Sun, 06 Jan 2002 21:52:26 +1100, Keith Owens wrote: >On Sun, 06 Jan 2002 10:55:47 +0100, >"Ralf G. R. Bergs" wrote: >>On Sun, 06 Jan 2002 12:23:12 +1100, Keith Owens wrote: >>>This just appeared on linux-kernel. It might throw some light on >>>recent bug reports about LVM. >>[...] >>>> LVM version 1.0.1-rc4(ish)(03/10/2001) >>> >>>Ah! You're using LVM! There are known bugs in LVM which cause memory >>>corruptions.[...] >> >>Does anyone know whether this bug also pertains to cases where LVM is compiled >>as a module, but isn't (actively) used? > >LVM has no effect when it is a module that has not been loaded. >However compiling the kernel for MD (required for LVM) does affect the >base kernel. Without going through all the differences between the >kernel MD/LVM code and the code in the MD/LVM CVS tree, any statement >would be a guess - I don't want to guess. I *did* compile the kernel for MD (altho I'm not using MD either,) so theoretically I could be affected. I guess I need to recompile the kernel again and have another go... Thanks! -- Verkaufe Original-BMW-Raeder: L I N U X .~. http://adsl-bergs.rz.rwth-aachen.de/~rabe The Choice /V\ of a GNU /( )\ Generation ^^-^^ From owner-linux-xfs@oss.sgi.com Sun Jan 6 07:24:38 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g06FOcE12899 for linux-xfs-outgoing; Sun, 6 Jan 2002 07:24:38 -0800 Received: from mail.linuxone.co.kr ([210.108.91.129]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g06FOXg12873 for ; Sun, 6 Jan 2002 07:24:33 -0800 Received: from windows (unknown [211.216.12.233]) by mail.linuxone.co.kr (Postfix) with SMTP id 2047F5404E for ; Sun, 6 Jan 2002 23:24:23 +0900 (KST) Message-ID: <004901c196bd$95a09900$0601a8c0@diylinux.org> From: "super" To: Subject: Date: Sun, 6 Jan 2002 23:22:34 +0900 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 Content-Disposition: inline Content-Type: text/plain Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 39 Lines: 5 [[HTML alternate version deleted]] From owner-linux-xfs@oss.sgi.com Sun Jan 6 07:24:57 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g06FOv712932 for linux-xfs-outgoing; Sun, 6 Jan 2002 07:24:57 -0800 Received: from ADSL-Bergs.RZ.RWTH-Aachen.DE (adsl-bergs.rz.RWTH-Aachen.DE [137.226.80.218]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g06FOqg12909 for ; Sun, 6 Jan 2002 07:24:52 -0800 Received: from [192.168.1.2] (helo=ralf) by ADSL-Bergs.RZ.RWTH-Aachen.DE with smtp (Exim 3.12 #1) id 16NEE7-0007uh-00; Sun, 06 Jan 2002 15:24:43 +0100 From: "Ralf G. R. Bergs" To: "Keith Owens" Cc: "linux-xfs@oss.sgi.com" Date: Sun, 06 Jan 2002 15:24:42 +0100 Reply-To: "Ralf G. R. Bergs" X-Mailer: PMMail 2000 Professional (2.20.2380) For Windows 2000 (5.0.2195;2) In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Subject: Re: LVM causing memory corruption Message-Id: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 1413 Lines: 37 Talking to myself again... On Sun, 06 Jan 2002 12:04:09 +0100, Ralf G. R. Bergs wrote: [...] >>LVM has no effect when it is a module that has not been loaded. >>However compiling the kernel for MD (required for LVM) does affect the >>base kernel. Without going through all the differences between the >>kernel MD/LVM code and the code in the MD/LVM CVS tree, any statement >>would be a guess - I don't want to guess. > >I *did* compile the kernel for MD (altho I'm not using MD either,) so >theoretically I could be affected. I guess I need to recompile the kernel >again and have another go... After I have excluded MD from the kernel config and booted the new kernel I just received the following message: Jan 6 14:33:07 Fileserver kernel: xfs_force_shutdown(sd(8,37),0x8) called from line 1020 of file xfs_trans.c. Return address = 0xe094c27a Jan 6 14:33:07 Fileserver kernel: Corruption of in-memory data detected. Shutting down filesystem: sd(8,37) Jan 6 14:33:07 Fileserver kernel: Please umount the filesystem, and rectify the problem(s) So my problem definitely isn't MD-related. :-( Any ideas still? -- Verkaufe Original-BMW-Raeder: L I N U X .~. http://adsl-bergs.rz.rwth-aachen.de/~rabe The Choice /V\ of a GNU /( )\ Generation ^^-^^ From owner-linux-xfs@oss.sgi.com Sun Jan 6 08:05:34 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g06G5Yw13717 for linux-xfs-outgoing; Sun, 6 Jan 2002 08:05:34 -0800 Received: from mail.linuxone.co.kr ([210.108.91.129]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g06G5Sg13693 for ; Sun, 6 Jan 2002 08:05:29 -0800 Received: from windows (unknown [211.216.12.233]) by mail.linuxone.co.kr (Postfix) with SMTP id 7AA485404E for ; Sun, 6 Jan 2002 23:32:47 +0900 (KST) Message-ID: <005601c196be$c239b900$0601a8c0@diylinux.org> From: "super" To: Subject: Problem anaconda with xfs Date: Sun, 6 Jan 2002 23:30:58 +0900 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 Content-Disposition: inline Content-Type: text/plain Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 284 Lines: 12 Hello everyone.. I have forced with problem when anaconda using xfs patched. The problem occured fdisk step with expert mode - graphic mode - . There is no error messages when selecting fdisk and only reboot system with "abnormal errors.. " [[HTML alternate version deleted]] From owner-linux-xfs@oss.sgi.com Sun Jan 6 13:03:23 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g06L3Ni17497 for linux-xfs-outgoing; Sun, 6 Jan 2002 13:03:23 -0800 Received: from coredump.sh0n.net (qmailremote@CPEdeadbeef0000.cpe.net.cable.rogers.com [24.100.234.67]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g06L3Jg17475 for ; Sun, 6 Jan 2002 13:03:19 -0800 Received: (qmail 5057 invoked from network); 6 Jan 2002 20:04:04 -0000 Received: from coredump.sh0n.net (sh0n@24.100.234.67) by coredump.sh0n.net with SMTP; 6 Jan 2002 20:04:04 -0000 Date: Sun, 6 Jan 2002 15:04:03 -0500 (EST) From: Shawn Starr To: linux-xfs@oss.sgi.com Subject: XFS fails fsx-linux.c (1 charactor difference) In-Reply-To: <200201062057.g06KvZu17316@oss.sgi.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 695 Lines: 24 With an exaustive test running overnight with the new -mjc branch of 2.4 (I'm working on getting XFS into the branch) I noticed the following fault: truncating to largest ever: 0x3fcb9 READ BAD DATA: offset = 0x53e5, size = 0x9c0a OFFSET GOOD BAD RANGE 0x 9000 0x0000 0x0101 0x 5faa operation# (mod 256) for the bad data may be 1 LOG DUMP (1145 total operations): I have attached the dump of the results run and the binary difference is ONE charactor: cmp boom boom.fsxgood boom boom.fsxgood differ: char 10428, line 18 It would be a good idea to use the fsx-linux.c program to stress test XFS. The fsx-linux program has found several bugs in NFS and other filesystems. Shawn. From owner-linux-xfs@oss.sgi.com Sun Jan 6 13:27:03 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g06LR3C17896 for linux-xfs-outgoing; Sun, 6 Jan 2002 13:27:03 -0800 Received: from sgi.com (sgi-too.SGI.COM [204.94.211.39]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g06LQxg17874 for ; Sun, 6 Jan 2002 13:26:59 -0800 Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id MAA06291 for ; Sun, 6 Jan 2002 12:25:17 -0800 (PST) mail_from (lord@sgi.com) Received: from tulip-e185.americas.sgi.com (tulip-e185.americas.sgi.com [128.162.185.208]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id OAA4019395; Sun, 6 Jan 2002 14:25:40 -0600 (CST) Received: from sgi.com (qosxq5VkS8O6djOOb7ajrsHZFeVQ07nX@lord-h1.americas.sgi.com [206.11.101.42]) by tulip-e185.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.7) with ESMTP id OAA59720; Sun, 6 Jan 2002 14:25:40 -0600 (CST) Message-ID: <3C38B3B7.3070000@sgi.com> Date: Sun, 06 Jan 2002 14:29:43 -0600 From: Stephen Lord User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.6) Gecko/20011120 X-Accept-Language: en-us MIME-Version: 1.0 To: Shawn Starr CC: linux-xfs@oss.sgi.com Subject: Re: XFS fails fsx-linux.c (1 charactor difference) References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 838 Lines: 33 Shawn Starr wrote: >With an exaustive test running overnight with the new -mjc branch of 2.4 >(I'm working on getting XFS into the branch) I noticed the following >fault: > >truncating to largest ever: 0x3fcb9 >READ BAD DATA: offset = 0x53e5, size = 0x9c0a >OFFSET GOOD BAD RANGE >0x 9000 0x0000 0x0101 0x 5faa >operation# (mod 256) for the bad data may be 1 >LOG DUMP (1145 total operations): > >I have attached the dump of the results run and the binary difference is >ONE charactor: > >cmp boom boom.fsxgood >boom boom.fsxgood differ: char 10428, line 18 > >It would be a good idea to use the fsx-linux.c program to stress test XFS. >The fsx-linux program has found several bugs in NFS and other filesystems. > >Shawn. > Google does not have any references to this program - can you provide a pointer? Thanks Steve From owner-linux-xfs@oss.sgi.com Sun Jan 6 13:39:11 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g06LdBp18148 for linux-xfs-outgoing; Sun, 6 Jan 2002 13:39:11 -0800 Received: from coredump.sh0n.net (qmailremote@CPEdeadbeef0000.cpe.net.cable.rogers.com [24.100.234.67]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g06Ld5g18126 for ; Sun, 6 Jan 2002 13:39:05 -0800 Received: (qmail 6862 invoked from network); 6 Jan 2002 20:39:50 -0000 Received: from coredump.sh0n.net (sh0n@24.100.234.67) by coredump.sh0n.net with SMTP; 6 Jan 2002 20:39:50 -0000 Date: Sun, 6 Jan 2002 15:39:49 -0500 (EST) From: Shawn Starr To: Stephen Lord cc: linux-xfs@oss.sgi.com Subject: Re: XFS fails fsx-linux.c (1 charactor difference) In-Reply-To: <3C38B3B7.3070000@sgi.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 1006 Lines: 44 sure: http://www.codemonkey.org.uk/cruft/fsx-linux.c Shawn. On Sun, 6 Jan 2002, Stephen Lord wrote: > Shawn Starr wrote: > > >With an exaustive test running overnight with the new -mjc branch of 2.4 > >(I'm working on getting XFS into the branch) I noticed the following > >fault: > > > >truncating to largest ever: 0x3fcb9 > >READ BAD DATA: offset = 0x53e5, size = 0x9c0a > >OFFSET GOOD BAD RANGE > >0x 9000 0x0000 0x0101 0x 5faa > >operation# (mod 256) for the bad data may be 1 > >LOG DUMP (1145 total operations): > > > >I have attached the dump of the results run and the binary difference is > >ONE charactor: > > > >cmp boom boom.fsxgood > >boom boom.fsxgood differ: char 10428, line 18 > > > >It would be a good idea to use the fsx-linux.c program to stress test XFS. > >The fsx-linux program has found several bugs in NFS and other filesystems. > > > >Shawn. > > > Google does not have any references to this program - can you provide a > pointer? > > Thanks > > Steve > > > > > From owner-linux-xfs@oss.sgi.com Sun Jan 6 13:41:47 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g06Lflh18308 for linux-xfs-outgoing; Sun, 6 Jan 2002 13:41:47 -0800 Received: from rover (rover.mkp.net [209.217.122.9]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g06Lfig18286 for ; Sun, 6 Jan 2002 13:41:44 -0800 Received: from localhost.localdomain ([127.0.0.1] helo=rover.mkp.net) by rover with esmtp (Exim 3.33 #1) id 16NK6p-00032e-00; Sun, 06 Jan 2002 15:41:36 -0500 Received: (from mkp@localhost) by rover.mkp.net (8.11.6/8.9.3) id g06KfGZ03671; Sun, 6 Jan 2002 15:41:16 -0500 X-Authentication-Warning: jaguar.wave.mkp.net: mkp set sender to mkp@mkp.net using -f To: Stephen Lord Cc: Shawn Starr , linux-xfs@oss.sgi.com Subject: Re: XFS fails fsx-linux.c (1 charactor difference) References: <3C38B3B7.3070000@sgi.com> From: "Martin K. Petersen" Organization: Linuxcare, Inc. Date: 06 Jan 2002 15:41:14 -0500 In-Reply-To: <3C38B3B7.3070000@sgi.com> Message-ID: User-Agent: Gnus/5.0808 (Gnus v5.8.8) XEmacs/21.4 (Civil Service) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 524 Lines: 15 >>>>> "Steve" == Stephen Lord writes: >> It would be a good idea to use the fsx-linux.c program to stress >> test XFS. The fsx-linux program has found several bugs in NFS and >> other filesystems. Steve> Google does not have any references to this program - can you Steve> provide a pointer? http://www.codemonkey.org.uk/cruft/ -- Martin K. Petersen, Principal Linux Consultant, Linuxcare, Inc. mkp@linuxcare.com, http://www.linuxcare.com/ SGI XFS for Linux Developer, http://oss.sgi.com/projects/xfs/ From owner-linux-xfs@oss.sgi.com Sun Jan 6 13:43:15 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g06LhFl18450 for linux-xfs-outgoing; Sun, 6 Jan 2002 13:43:15 -0800 Received: from coredump.sh0n.net (qmailremote@CPEdeadbeef0000.cpe.net.cable.rogers.com [24.100.234.67]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g06Lh9g18424 for ; Sun, 6 Jan 2002 13:43:09 -0800 Received: (qmail 6895 invoked from network); 6 Jan 2002 20:43:55 -0000 Received: from coredump.sh0n.net (sh0n@24.100.234.67) by coredump.sh0n.net with SMTP; 6 Jan 2002 20:43:55 -0000 Date: Sun, 6 Jan 2002 15:43:55 -0500 (EST) From: Shawn Starr To: Stephen Lord cc: linux-xfs@oss.sgi.com Subject: Re: XFS fails fsx-linux.c (1 charactor difference) In-Reply-To: <3C38B3B7.3070000@sgi.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 1009 Lines: 41 you may need to #define linux in the sources as it was ported. On Sun, 6 Jan 2002, Stephen Lord wrote: > Shawn Starr wrote: > > >With an exaustive test running overnight with the new -mjc branch of 2.4 > >(I'm working on getting XFS into the branch) I noticed the following > >fault: > > > >truncating to largest ever: 0x3fcb9 > >READ BAD DATA: offset = 0x53e5, size = 0x9c0a > >OFFSET GOOD BAD RANGE > >0x 9000 0x0000 0x0101 0x 5faa > >operation# (mod 256) for the bad data may be 1 > >LOG DUMP (1145 total operations): > > > >I have attached the dump of the results run and the binary difference is > >ONE charactor: > > > >cmp boom boom.fsxgood > >boom boom.fsxgood differ: char 10428, line 18 > > > >It would be a good idea to use the fsx-linux.c program to stress test XFS. > >The fsx-linux program has found several bugs in NFS and other filesystems. > > > >Shawn. > > > Google does not have any references to this program - can you provide a > pointer? > > Thanks > > Steve > > > > > From owner-linux-xfs@oss.sgi.com Sun Jan 6 14:07:10 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g06M7A118951 for linux-xfs-outgoing; Sun, 6 Jan 2002 14:07:10 -0800 Received: from yog-sothoth.sgi.com (eugate.sgi.com [192.48.160.10]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g06M71g18927 for ; Sun, 6 Jan 2002 14:07:02 -0800 Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by yog-sothoth.sgi.com (980305.SGI.8.8.8-aspam-6.2/980304.SGI-aspam-europe) via ESMTP id WAA1347158 for ; Sun, 6 Jan 2002 22:05:18 +0100 (CET) mail_from (lord@sgi.com) Received: from tulip-e185.americas.sgi.com (tulip-e185.americas.sgi.com [128.162.185.208]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id PAA3971539; Sun, 6 Jan 2002 15:05:41 -0600 (CST) Received: from sgi.com (BHKVkGiF7HMe2j17Z987h8qEZLch1cpE@lord-h1.americas.sgi.com [206.11.101.42]) by tulip-e185.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.7) with ESMTP id PAA68897; Sun, 6 Jan 2002 15:05:40 -0600 (CST) Message-ID: <3C38BD16.9020704@sgi.com> Date: Sun, 06 Jan 2002 15:09:42 -0600 From: Stephen Lord User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.6) Gecko/20011120 X-Accept-Language: en-us MIME-Version: 1.0 To: Shawn Starr CC: linux-xfs@oss.sgi.com Subject: Re: XFS fails fsx-linux.c (1 charactor difference) References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 1416 Lines: 58 Shawn Starr wrote: >sure: > >http://www.codemonkey.org.uk/cruft/fsx-linux.c > >Shawn. > >On Sun, 6 Jan 2002, Stephen Lord wrote: > >>Shawn Starr wrote: >> >>>With an exaustive test running overnight with the new -mjc branch of 2.4 >>>(I'm working on getting XFS into the branch) I noticed the following >>>fault: >>> >>>truncating to largest ever: 0x3fcb9 >>>READ BAD DATA: offset = 0x53e5, size = 0x9c0a >>>OFFSET GOOD BAD RANGE >>>0x 9000 0x0000 0x0101 0x 5faa >>>operation# (mod 256) for the bad data may be 1 >>>LOG DUMP (1145 total operations): >>> >>>I have attached the dump of the results run and the binary difference is >>>ONE charactor: >>> >>>cmp boom boom.fsxgood >>>boom boom.fsxgood differ: char 10428, line 18 >>> >>>It would be a good idea to use the fsx-linux.c program to stress test XFS. >>>The fsx-linux program has found several bugs in NFS and other filesystems. >>> >>>Shawn. >>> >>Google does not have any references to this program - can you provide a >>pointer? >> >>Thanks >> >> Steve >> >> >> >> >> Ah ha, I have seen this program before (under a slightly different name) it was running just fine on XFS when I last ran it. On the other hand we appear to be suffering from a regression right now, and if I am correct, the regression happened right around the day I last ran this program, so it is possible the same change broke fsx as well as emacs builds.... Steve From owner-linux-xfs@oss.sgi.com Sun Jan 6 15:09:14 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g06N9EI20077 for linux-xfs-outgoing; Sun, 6 Jan 2002 15:09:14 -0800 Received: from coredump.sh0n.net (qmailremote@CPEdeadbeef0000.cpe.net.cable.rogers.com [24.100.234.67]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g06N93g20054 for ; Sun, 6 Jan 2002 15:09:04 -0800 Received: (qmail 327 invoked from network); 6 Jan 2002 22:09:45 -0000 Received: from coredump.sh0n.net (sh0n@24.100.234.67) by coredump.sh0n.net with SMTP; 6 Jan 2002 22:09:45 -0000 Date: Sun, 6 Jan 2002 17:09:44 -0500 (EST) From: Shawn Starr To: Stephen Lord cc: linux-xfs@oss.sgi.com Subject: Re: XFS fails fsx-linux.c (1 charactor difference) In-Reply-To: <3C38BD16.9020704@sgi.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 2078 Lines: 82 [root@coredump src]# ./blowup-xfs boom truncating to largest ever: 0x13e76 truncating to largest ever: 0x2e52c truncating to largest ever: 0x3c2c2 truncating to largest ever: 0x3f15f truncating to largest ever: 0x3fcb9 truncating to largest ever: 0x3fe96 truncating to largest ever: 0x3ff9d truncating to largest ever: 0x3ffff skipping zero size read skipping zero size write Running the program again, with today's XFS changes my tree was a little out of date.. so far it hasn't blown up yet ;-) Shawn. On Sun, 6 Jan 2002, Stephen Lord wrote: > Shawn Starr wrote: > > >sure: > > > >http://www.codemonkey.org.uk/cruft/fsx-linux.c > > > >Shawn. > > > >On Sun, 6 Jan 2002, Stephen Lord wrote: > > > >>Shawn Starr wrote: > >> > >>>With an exaustive test running overnight with the new -mjc branch of 2.4 > >>>(I'm working on getting XFS into the branch) I noticed the following > >>>fault: > >>> > >>>truncating to largest ever: 0x3fcb9 > >>>READ BAD DATA: offset = 0x53e5, size = 0x9c0a > >>>OFFSET GOOD BAD RANGE > >>>0x 9000 0x0000 0x0101 0x 5faa > >>>operation# (mod 256) for the bad data may be 1 > >>>LOG DUMP (1145 total operations): > >>> > >>>I have attached the dump of the results run and the binary difference is > >>>ONE charactor: > >>> > >>>cmp boom boom.fsxgood > >>>boom boom.fsxgood differ: char 10428, line 18 > >>> > >>>It would be a good idea to use the fsx-linux.c program to stress test XFS. > >>>The fsx-linux program has found several bugs in NFS and other filesystems. > >>> > >>>Shawn. > >>> > >>Google does not have any references to this program - can you provide a > >>pointer? > >> > >>Thanks > >> > >> Steve > >> > >> > >> > >> > >> > Ah ha, I have seen this program before (under a slightly different name) > it was running just fine > on XFS when I last ran it. On the other hand we appear to be suffering > from a regression > right now, and if I am correct, the regression happened right around the > day I last ran > this program, so it is possible the same change broke fsx as well as > emacs builds.... > > Steve > > > > > From owner-linux-xfs@oss.sgi.com Sun Jan 6 15:24:08 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g06NO8W20354 for linux-xfs-outgoing; Sun, 6 Jan 2002 15:24:08 -0800 Received: from mail.ocs.com.au (mail.ocs.com.au [203.34.97.2]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g06NO4g20332 for ; Sun, 6 Jan 2002 15:24:05 -0800 Received: (qmail 16613 invoked from network); 6 Jan 2002 22:24:00 -0000 Received: from ocs3.intra.ocs.com.au (192.168.255.3) by mail.ocs.com.au with SMTP; 6 Jan 2002 22:24:00 -0000 Received: by ocs3.intra.ocs.com.au (Postfix, from userid 16331) id 89103300090; Mon, 7 Jan 2002 09:23:57 +1100 (EST) Received: from ocs3.intra.ocs.com.au (localhost [127.0.0.1]) by ocs3.intra.ocs.com.au (Postfix) with ESMTP id 5A0F494; Mon, 7 Jan 2002 09:23:57 +1100 (EST) X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 From: Keith Owens To: Shawn Starr Cc: linux-xfs@oss.sgi.com Subject: Re: XFS fails fsx-linux.c (1 charactor difference) In-reply-to: Your message of "Sun, 06 Jan 2002 15:04:03 CDT." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 07 Jan 2002 09:23:52 +1100 Message-ID: <23481.1010355832@ocs3.intra.ocs.com.au> Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 365 Lines: 11 On Sun, 6 Jan 2002 15:04:03 -0500 (EST), Shawn Starr wrote: >I have attached the dump of the results run and the binary difference is >ONE charactor: > >cmp boom boom.fsxgood >boom boom.fsxgood differ: char 10428, line 18 cmp stops on the first different character unless you use -l, then it lists all the differences, including their values. From owner-linux-xfs@oss.sgi.com Sun Jan 6 15:26:08 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g06NQ8N20489 for linux-xfs-outgoing; Sun, 6 Jan 2002 15:26:08 -0800 Received: from coredump.sh0n.net (qmailremote@CPEdeadbeef0000.cpe.net.cable.rogers.com [24.100.234.67]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g06NQ5g20467 for ; Sun, 6 Jan 2002 15:26:05 -0800 Received: (qmail 2281 invoked from network); 6 Jan 2002 22:26:49 -0000 Received: from coredump.sh0n.net (sh0n@24.100.234.67) by coredump.sh0n.net with SMTP; 6 Jan 2002 22:26:49 -0000 Date: Sun, 6 Jan 2002 17:26:49 -0500 (EST) From: Shawn Starr To: Keith Owens cc: linux-xfs@oss.sgi.com Subject: Re: XFS fails fsx-linux.c (1 charactor difference) In-Reply-To: <23481.1010355832@ocs3.intra.ocs.com.au> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 488 Lines: 20 I will do this as soon as the new test completes. Shawn. On Mon, 7 Jan 2002, Keith Owens wrote: > On Sun, 6 Jan 2002 15:04:03 -0500 (EST), > Shawn Starr wrote: > >I have attached the dump of the results run and the binary difference is > >ONE charactor: > > > >cmp boom boom.fsxgood > >boom boom.fsxgood differ: char 10428, line 18 > > cmp stops on the first different character unless you use -l, then it > lists all the differences, including their values. > > > From owner-linux-xfs@oss.sgi.com Sun Jan 6 16:43:30 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g070hUs21486 for linux-xfs-outgoing; Sun, 6 Jan 2002 16:43:30 -0800 Received: from pneumatic-tube.sgi.com (pneumatic-tube.sgi.com [204.94.214.22]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g070hPg21464 for ; Sun, 6 Jan 2002 16:43:25 -0800 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via SMTP id PAA04423 for ; Sun, 6 Jan 2002 15:43:58 -0800 (PST) mail_from (nathans@wobbly.melbourne.sgi.com) Received: from wobbly.melbourne.sgi.com (wobbly.melbourne.sgi.com [134.14.55.135]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id KAA26236; Mon, 7 Jan 2002 10:42:02 +1100 Received: (from nathans@localhost) by wobbly.melbourne.sgi.com (SGI-8.9.3/8.9.3) id KAA61225; Mon, 7 Jan 2002 10:42:00 +1100 (AEDT) Date: Mon, 7 Jan 2002 10:42:00 +1100 From: Nathan Scott To: Fabrizio Celli Cc: linux-xfs@oss.sgi.com Subject: Re: SAMBA 2.2.2 AND XFS QUOTA SUPPORT Message-ID: <20020107104200.B161233@wobbly.melbourne.sgi.com> References: <3221.213.82.150.92.1010167924.squirrel@www2.trampi.istruzione.it> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <3221.213.82.150.92.1010167924.squirrel@www2.trampi.istruzione.it>; from fabrizio.celli@istruzione.it on Fri, Jan 04, 2002 at 07:12:04PM -0100 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 1307 Lines: 37 hi, On Fri, Jan 04, 2002 at 07:12:04PM -0100, Fabrizio Celli wrote: > Hi everybody, > > testing the Nathan's "experimental" patch we got samba working on a xfs > filesystem with quota enabled, > Our configuration is: > RH 7.2 with SGI custom kernel 2.4.9-13 > samba 2.2.2 with the xfs quota patch Last I heard, Jeremy had added this patch into Samba CVS and the Mandrake folk that were testing it were saying that it was all working correctly. > The only problem we encountered (by now) is that from a win2k client, when > we access the smb share with quota on, the win2k file manager show us the > whole size of the filesystem instead of the soft limit size. > Naturally we can't write more than the hard limit but it's not nice for our > customers to think of having 100Gb of free space and get the message "DISK FULL" > > Using an ext3 filesystem everything seem working... > We don't know if it's a samba xfs quota implementation problem or not. > > Any suggestion ? Are you sure the new code was compiled into smbd correctly? (check your configure output files - config.* - there should be a #define LINUX_XFS_QUOTA, or somthing similar). You could also strace smbd to check that it is making quotactl syscalls for XFS filesystems, and that these syscalls aren't failing. cheers. -- Nathan From owner-linux-xfs@oss.sgi.com Sun Jan 6 16:49:16 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g070nGr21672 for linux-xfs-outgoing; Sun, 6 Jan 2002 16:49:16 -0800 Received: from yog-sothoth.sgi.com (eugate.sgi.com [192.48.160.10]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g070n2g21649 for ; Sun, 6 Jan 2002 16:49:03 -0800 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by yog-sothoth.sgi.com (980305.SGI.8.8.8-aspam-6.2/980304.SGI-aspam-europe) via SMTP id AAA1340353 for ; Mon, 7 Jan 2002 00:47:16 +0100 (CET) mail_from (nathans@wobbly.melbourne.sgi.com) Received: from wobbly.melbourne.sgi.com (wobbly.melbourne.sgi.com [134.14.55.135]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id KAA26291; Mon, 7 Jan 2002 10:47:38 +1100 Received: (from nathans@localhost) by wobbly.melbourne.sgi.com (SGI-8.9.3/8.9.3) id KAA65088; Mon, 7 Jan 2002 10:47:37 +1100 (AEDT) Date: Mon, 7 Jan 2002 10:47:35 +1100 From: Nathan Scott To: Brian Johnson Cc: Linux XFS Subject: Re: Quota block usage out of date until sync Message-ID: <20020107104735.C161233@wobbly.melbourne.sgi.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from brian@ml1.brianj.com on Fri, Jan 04, 2002 at 03:34:00PM -0600 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 3355 Lines: 83 hi Brian, On Sat, Jan 05, 2002 at 09:23:14PM -0600, Brian Johnson wrote: > > This behavior is different from ext2/ext3. In ext2/3 the data does not > need to be written to disk to be reflected in the quota. I have tested > this and my output is below. I watched vmstat and xfs showed the correct > block quota only after the 1024 kbytes where written to disk while ext2/3 > showed it right after dd was run but before it was written to disk. It > seems that in XFS repquota show only what was written to disk and ext2/3 > shows what was is on the disk plus what is in the buffer so the block > quota number is never out of date. > > ext2 (I think I remember testing this with ext3 and it was the same): > For these filesystems, repquota will do a Q_SYNC (quotactl(2)) before attempting to fetch all of the dquots off the disk. XFS implements this same functionality but quite differently (without sync operations). > > XFS: > > Here repquota shows the block change only after the data is written to > disk. > Not quite - we will only read off the disk if we do not have the dquot incore already. In this case though we're guaranteed to have it in memory because we just created a file as that user. > # /usr/sbin/repquota /users | egrep "^root" ;\ > > dd count=1024 bs=1024 if=/dev/zero of=writetest ;\ > > /usr/sbin/repquota /users | egrep "^root" ;\ > > sleep 30 ;\ > > /usr/sbin/repquota /users | egrep "^root" ;\ > > sleep 10 ;\ > > /usr/sbin/repquota /users | egrep "^root" > root -- 7200 0 0 20 0 0 ^^^^^^ ^^^^ > 1024+0 records in > 1024+0 records out > root -- 7200 0 0 21 0 0 ^^^^^^ ^^^^ I suspect what you're seeing here is the effects of delayed allocation. We can see above that the inode count has been incremented, so we are indeed getting the updated dquot (ie. we're not reading something "old" off the disk - we're not reading off the disk at all in fact). Since space is not allocated for the data until later, the used space for the file is not updated until then (we don't actually know how much space to charge the user until space allocation is done - which sounds counter-intuitive but is quite correct). > root -- 7200 0 0 21 0 0 > root -- 8224 0 0 21 0 0 ^^^^^^ ^^^^ > > So it seems ext2 shows not what is on disk, but what the user has written > and may be in the buffer and XFS just shows what is on the disk. Not really, in fact its more like the other way around just to confuse the matter more. XFS has no Q_SYNC quotactl command, as dquots are journaled along with the associated inode, freespace, superblock,... change (ie. Q_SYNC would == sync(2)), but other filesystems quota use Q_SYNC to get a recent snapshot of the quota file out to disk, and then read off disk - XFS doesn't work that way. [40 seconds does seem excessive to me though, I'm not 100% sure why it takes quite that long. The /proc/sys/vm/pagebuf params might need some tuning here? (i'm guessing). Ask me in a month or so - I have my head buried in pagebuf code at the moment, so I might know the answer then. ;-)] cheers. -- Nathan From owner-linux-xfs@oss.sgi.com Sun Jan 6 17:00:23 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0710Nq21980 for linux-xfs-outgoing; Sun, 6 Jan 2002 17:00:23 -0800 Received: from coredump.sh0n.net (qmailremote@CPEdeadbeef0000.cpe.net.cable.rogers.com [24.100.234.67]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g070vSg21893 for ; Sun, 6 Jan 2002 16:57:29 -0800 Received: (qmail 2437 invoked from network); 6 Jan 2002 23:58:13 -0000 Received: from coredump.sh0n.net (sh0n@24.100.234.67) by coredump.sh0n.net with SMTP; 6 Jan 2002 23:58:13 -0000 Date: Sun, 6 Jan 2002 18:58:13 -0500 (EST) From: Shawn Starr To: Keith Owens cc: linux-xfs@oss.sgi.com Subject: Re: XFS fails fsx-linux.c - log dump In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="1679311850-516486818-1010361493=:2424" Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 88446 Lines: 1462 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. Send mail to mime@docserver.cac.washington.edu for more info. --1679311850-516486818-1010361493=:2424 Content-Type: TEXT/PLAIN; charset=US-ASCII Here's the log dump from the current fault: Shawn. --1679311850-516486818-1010361493=:2424 Content-Type: TEXT/PLAIN; charset=US-ASCII; name="boom.fsxlog" Content-Transfer-Encoding: BASE64 Content-ID: Content-Description: Log Content-Disposition: attachment; filename="boom.fsxlog" dHJ1bmNhdGluZyB0byBsYXJnZXN0IGV2ZXI6IDB4MTNlNzYNCnRydW5jYXRp bmcgdG8gbGFyZ2VzdCBldmVyOiAweDJlNTJjDQp0cnVuY2F0aW5nIHRvIGxh cmdlc3QgZXZlcjogMHgzYzJjMg0KdHJ1bmNhdGluZyB0byBsYXJnZXN0IGV2 ZXI6IDB4M2YxNWYNCnRydW5jYXRpbmcgdG8gbGFyZ2VzdCBldmVyOiAweDNm Y2I5DQp0cnVuY2F0aW5nIHRvIGxhcmdlc3QgZXZlcjogMHgzZmU5Ng0KdHJ1 bmNhdGluZyB0byBsYXJnZXN0IGV2ZXI6IDB4M2ZmOWQNCnRydW5jYXRpbmcg dG8gbGFyZ2VzdCBldmVyOiAweDNmZmZmDQpza2lwcGluZyB6ZXJvIHNpemUg cmVhZA0Kc2tpcHBpbmcgemVybyBzaXplIHdyaXRlDQpza2lwcGluZyB6ZXJv IHNpemUgd3JpdGUNCnNraXBwaW5nIHplcm8gc2l6ZSB3cml0ZQ0Kc2tpcHBp bmcgemVybyBzaXplIHdyaXRlDQpza2lwcGluZyB6ZXJvIHNpemUgd3JpdGUN CnNraXBwaW5nIHplcm8gc2l6ZSB3cml0ZQ0Kc2tpcHBpbmcgemVybyBzaXpl IHdyaXRlDQpza2lwcGluZyB6ZXJvIHNpemUgd3JpdGUNCnNraXBwaW5nIHpl cm8gc2l6ZSByZWFkDQpza2lwcGluZyB6ZXJvIHNpemUgcmVhZA0Kc2tpcHBp bmcgemVybyBzaXplIHJlYWQNCnNraXBwaW5nIHplcm8gc2l6ZSByZWFkDQpz a2lwcGluZyB6ZXJvIHNpemUgd3JpdGUNCnNraXBwaW5nIHplcm8gc2l6ZSBy ZWFkDQpza2lwcGluZyB6ZXJvIHNpemUgd3JpdGUNCnNraXBwaW5nIHplcm8g c2l6ZSByZWFkDQpza2lwcGluZyB6ZXJvIHNpemUgd3JpdGUNCnNraXBwaW5n IHplcm8gc2l6ZSByZWFkDQpza2lwcGluZyB6ZXJvIHNpemUgd3JpdGUNCnNr aXBwaW5nIHplcm8gc2l6ZSByZWFkDQpza2lwcGluZyB6ZXJvIHNpemUgcmVh ZA0KUkVBRCBCQUQgREFUQTogb2Zmc2V0ID0gMHgxLCBzaXplID0gMHg2YjFj DQpPRkZTRVQJR09PRAlCQUQJUkFOR0UNCjB4ICA1MjcJMHhiYTIzCTB4MDAw MAkweCAgMzMwDQpvcGVyYXRpb24jIChtb2QgMjU2KSBmb3IgdGhlIGJhZCBk YXRhIHVua25vd24sIGNoZWNrIEhPTEUgYW5kIEVYVEVORCBvcHMNCkxPRyBE VU1QICg5MDMwNzYgdG90YWwgb3BlcmF0aW9ucyk6DQo5MDMwNzcoMTY1IG1v ZCAyNTYpOiBXUklURQkweDM4MmVjIHRocnUgMHgzOTdiMwkoMHgxNGM4IGJ5 dGVzKSBIT0xFDQo5MDMwNzgoMTY2IG1vZCAyNTYpOiBNQVBSRUFECTB4Nzdi ZiB0aHJ1IDB4MTRlZTMJKDB4ZDcyNSBieXRlcykNCjkwMzA3OSgxNjcgbW9k IDI1Nik6IFdSSVRFCTB4MjFlZGMgdGhydSAweDI0YjFjCSgweDJjNDEgYnl0 ZXMpDQo5MDMwODAoMTY4IG1vZCAyNTYpOiBNQVBXUklURSAweDM2NDI3IHRo cnUgMHgzYmUwZgkoMHg1OWU5IGJ5dGVzKQ0KOTAzMDgxKDE2OSBtb2QgMjU2 KTogTUFQUkVBRAkweDZlZiB0aHJ1IDB4OThiYQkoMHg5MWNjIGJ5dGVzKQkq KipSUlJSKioqDQo5MDMwODIoMTcwIG1vZCAyNTYpOiBNQVBXUklURSAweDI3 MjkzIHRocnUgMHgyOTQ1MwkoMHgyMWMxIGJ5dGVzKQ0KOTAzMDgzKDE3MSBt b2QgMjU2KTogVFJVTkNBVEUgRE9XTglmcm9tIDB4M2JlMTAgdG8gMHg0NDAJ KioqKioqV1dXVw0KOTAzMDg0KDE3MiBtb2QgMjU2KTogTUFQV1JJVEUgMHgy ODBiIHRocnUgMHhiOWNmCSgweDkxYzUgYnl0ZXMpDQo5MDMwODUoMTczIG1v ZCAyNTYpOiBSRUFECTB4MTc5OSB0aHJ1IDB4NTAyMQkoMHgzODg5IGJ5dGVz KQ0KOTAzMDg2KDE3NCBtb2QgMjU2KTogTUFQUkVBRAkweDlhN2EgdGhydSAw eGI5Y2YJKDB4MWY1NiBieXRlcykNCjkwMzA4NygxNzUgbW9kIDI1Nik6IFdS SVRFCTB4MzM4ZWUgdGhydSAweDM5MGRlCSgweDU3ZjEgYnl0ZXMpIEhPTEUN CjkwMzA4OCgxNzYgbW9kIDI1Nik6IFJFQUQJMHhiM2IxIHRocnUgMHgxYWM0 MAkoMHhmODkwIGJ5dGVzKQ0KOTAzMDg5KDE3NyBtb2QgMjU2KTogV1JJVEUJ MHgyNmVkIHRocnUgMHgyZjVmCSgweDg3MyBieXRlcykNCjkwMzA5MCgxNzgg bW9kIDI1Nik6IFRSVU5DQVRFIERPV04JZnJvbSAweDM5MGRmIHRvIDB4Mjc4 ZDANCjkwMzA5MSgxNzkgbW9kIDI1Nik6IE1BUFJFQUQJMHhiOTMzIHRocnUg MHhjZGRiCSgweDE0YTkgYnl0ZXMpDQo5MDMwOTIoMTgwIG1vZCAyNTYpOiBN QVBXUklURSAweDMwOWI4IHRocnUgMHgzNDFlNgkoMHgzODJmIGJ5dGVzKQ0K OTAzMDkzKDE4MSBtb2QgMjU2KTogUkVBRAkweDk5MWUgdGhydSAweDE2MTdi CSgweGM4NWUgYnl0ZXMpDQo5MDMwOTQoMTgyIG1vZCAyNTYpOiBUUlVOQ0FU RSBET1dOCWZyb20gMHgzNDFlNyB0byAweDI3MjVlDQo5MDMwOTUoMTgzIG1v ZCAyNTYpOiBUUlVOQ0FURSBVUAlmcm9tIDB4MjcyNWUgdG8gMHgyZTFjMw0K OTAzMDk2KDE4NCBtb2QgMjU2KTogTUFQV1JJVEUgMHgyYTBkYiB0aHJ1IDB4 MzNiYmYJKDB4OWFlNSBieXRlcykNCjkwMzA5NygxODUgbW9kIDI1Nik6IE1B UFdSSVRFIDB4MjYxZWQgdGhydSAweDJiMjgwCSgweDUwOTQgYnl0ZXMpDQo5 MDMwOTgoMTg2IG1vZCAyNTYpOiBXUklURQkweDE2ZGE1IHRocnUgMHgxYmEw MQkoMHg0YzVkIGJ5dGVzKQ0KOTAzMDk5KDE4NyBtb2QgMjU2KTogTUFQUkVB RAkweDI5MmNhIHRocnUgMHgzM2JiZgkoMHhhOGY2IGJ5dGVzKQ0KOTAzMTAw KDE4OCBtb2QgMjU2KTogTUFQUkVBRAkweDEwZTNiIHRocnUgMHgxZWZjOAko MHhlMThlIGJ5dGVzKQ0KOTAzMTAxKDE4OSBtb2QgMjU2KTogTUFQV1JJVEUg MHhmZDg1IHRocnUgMHgxNmE1NAkoMHg2Y2QwIGJ5dGVzKQ0KOTAzMTAyKDE5 MCBtb2QgMjU2KTogVFJVTkNBVEUgRE9XTglmcm9tIDB4MzNiYzAgdG8gMHgx YzQ1Yg0KOTAzMTAzKDE5MSBtb2QgMjU2KTogUkVBRAkweDEzMWEwIHRocnUg MHgxOWM1YQkoMHg2YWJiIGJ5dGVzKQ0KOTAzMTA0KDE5MiBtb2QgMjU2KTog TUFQUkVBRAkweDExMjk3IHRocnUgMHgxYzQ1YQkoMHhiMWM0IGJ5dGVzKQ0K OTAzMTA1KDE5MyBtb2QgMjU2KTogTUFQUkVBRAkweGFlOGMgdGhydSAweGRj ODUJKDB4MmRmYSBieXRlcykNCjkwMzEwNigxOTQgbW9kIDI1Nik6IE1BUFdS SVRFIDB4MTA4MGYgdGhydSAweDEwZWU0CSgweDZkNiBieXRlcykNCjkwMzEw NygxOTUgbW9kIDI1Nik6IFdSSVRFCTB4MWU1MjAgdGhydSAweDJhYjE1CSgw eGM1ZjYgYnl0ZXMpIEhPTEUNCjkwMzEwOCgxOTYgbW9kIDI1Nik6IE1BUFdS SVRFIDB4MjMwN2IgdGhydSAweDMxNjFiCSgweGU1YTEgYnl0ZXMpDQo5MDMx MDkoMTk3IG1vZCAyNTYpOiBXUklURQkweDRjNzIgdGhydSAweGYwNmEJKDB4 YTNmOSBieXRlcykNCjkwMzExMCgxOTggbW9kIDI1Nik6IFRSVU5DQVRFIERP V04JZnJvbSAweDMxNjFjIHRvIDB4MTc4MzcNCjkwMzExMSgxOTkgbW9kIDI1 Nik6IFJFQUQJMHg4OTc1IHRocnUgMHgxMjE1MAkoMHg5N2RjIGJ5dGVzKQ0K OTAzMTEyKDIwMCBtb2QgMjU2KTogUkVBRAkweGEwNGYgdGhydSAweGVlY2YJ KDB4NGU4MSBieXRlcykNCjkwMzExMygyMDEgbW9kIDI1Nik6IFRSVU5DQVRF IFVQCWZyb20gMHgxNzgzNyB0byAweDM0MjM0DQo5MDMxMTQoMjAyIG1vZCAy NTYpOiBXUklURQkweGRlYjkgdGhydSAweDE4ZWIyCSgweGFmZmEgYnl0ZXMp DQo5MDMxMTUoMjAzIG1vZCAyNTYpOiBNQVBSRUFECTB4MzdlZiB0aHJ1IDB4 OGUyMwkoMHg1NjM1IGJ5dGVzKQ0KOTAzMTE2KDIwNCBtb2QgMjU2KTogV1JJ VEUJMHhiNWM4IHRocnUgMHgxN2U5ZQkoMHhjOGQ3IGJ5dGVzKQ0KOTAzMTE3 KDIwNSBtb2QgMjU2KTogV1JJVEUJMHg0Mjk4IHRocnUgMHgxM2YxOAkoMHhm YzgxIGJ5dGVzKQ0KOTAzMTE4KDIwNiBtb2QgMjU2KTogV1JJVEUJMHgxYjYw NSB0aHJ1IDB4MjVhY2MJKDB4YTRjOCBieXRlcykNCjkwMzExOSgyMDcgbW9k IDI1Nik6IFRSVU5DQVRFIERPV04JZnJvbSAweDM0MjM0IHRvIDB4Zjc1Yw0K OTAzMTIwKDIwOCBtb2QgMjU2KTogVFJVTkNBVEUgVVAJZnJvbSAweGY3NWMg dG8gMHhmYWYxDQo5MDMxMjEoMjA5IG1vZCAyNTYpOiBNQVBXUklURSAweDI5 Zjg2IHRocnUgMHgzNTRkZQkoMHhiNTU5IGJ5dGVzKQ0KOTAzMTIyKDIxMCBt b2QgMjU2KTogTUFQUkVBRAkweDJmMmMxIHRocnUgMHgzNTRkZQkoMHg2MjFl IGJ5dGVzKQ0KOTAzMTIzKDIxMSBtb2QgMjU2KTogVFJVTkNBVEUgRE9XTglm cm9tIDB4MzU0ZGYgdG8gMHgyNzAzDQo5MDMxMjQoMjEyIG1vZCAyNTYpOiBN QVBXUklURSAweDNjZDViIHRocnUgMHgzZmZmZgkoMHgzMmE1IGJ5dGVzKQ0K OTAzMTI1KDIxMyBtb2QgMjU2KTogTUFQV1JJVEUgMHgzZjBmOSB0aHJ1IDB4 M2ZmZmYJKDB4ZjA3IGJ5dGVzKQ0KOTAzMTI2KDIxNCBtb2QgMjU2KTogTUFQ V1JJVEUgMHg1YjhkIHRocnUgMHg4NWNiCSgweDJhM2YgYnl0ZXMpDQo5MDMx MjcoMjE1IG1vZCAyNTYpOiBUUlVOQ0FURSBET1dOCWZyb20gMHg0MDAwMCB0 byAweGJkZTMNCjkwMzEyOCgyMTYgbW9kIDI1Nik6IFJFQUQJMHhiZDkgdGhy dSAweGJkZTIJKDB4YjIwYSBieXRlcykNCjkwMzEyOSgyMTcgbW9kIDI1Nik6 IFJFQUQJMHg4ZmE2IHRocnUgMHhiZGUyCSgweDJlM2QgYnl0ZXMpDQo5MDMx MzAoMjE4IG1vZCAyNTYpOiBNQVBXUklURSAweDM5OTQxIHRocnUgMHgzZmZm ZgkoMHg2NmJmIGJ5dGVzKQ0KOTAzMTMxKDIxOSBtb2QgMjU2KTogVFJVTkNB VEUgRE9XTglmcm9tIDB4NDAwMDAgdG8gMHg2MTBhDQo5MDMxMzIoMjIwIG1v ZCAyNTYpOiBNQVBSRUFECTB4MTBhMSB0aHJ1IDB4NjEwOQkoMHg1MDY5IGJ5 dGVzKQ0KOTAzMTMzKDIyMSBtb2QgMjU2KTogV1JJVEUJMHgzNmMyMSB0aHJ1 IDB4M2ZmZmYJKDB4OTNkZiBieXRlcykgSE9MRQ0KOTAzMTM0KDIyMiBtb2Qg MjU2KTogV1JJVEUJMHgyY2Y2ZCB0aHJ1IDB4MzUzZTIJKDB4ODQ3NiBieXRl cykNCjkwMzEzNSgyMjMgbW9kIDI1Nik6IFJFQUQJMHgzMzM0IHRocnUgMHg0 M2NjCSgweDEwOTkgYnl0ZXMpDQo5MDMxMzYoMjI0IG1vZCAyNTYpOiBUUlVO Q0FURSBET1dOCWZyb20gMHg0MDAwMCB0byAweDIwZmViDQo5MDMxMzcoMjI1 IG1vZCAyNTYpOiBNQVBSRUFECTB4MTgzYTMgdGhydSAweDIwZmVhCSgweDhj NDggYnl0ZXMpDQo5MDMxMzgoMjI2IG1vZCAyNTYpOiBUUlVOQ0FURSBVUAlm cm9tIDB4MjBmZWIgdG8gMHgyZTgzYg0KOTAzMTM5KDIyNyBtb2QgMjU2KTog VFJVTkNBVEUgRE9XTglmcm9tIDB4MmU4M2IgdG8gMHgxNWM3MA0KOTAzMTQw KDIyOCBtb2QgMjU2KTogUkVBRAkweDVlODUgdGhydSAweDEwOGNlCSgweGFh NGEgYnl0ZXMpDQo5MDMxNDEoMjI5IG1vZCAyNTYpOiBNQVBXUklURSAweDNl YWZiIHRocnUgMHgzZmZmZgkoMHgxNTA1IGJ5dGVzKQ0KOTAzMTQyKDIzMCBt b2QgMjU2KTogUkVBRAkweDM1N2E1IHRocnUgMHgzZmZmZgkoMHhhODViIGJ5 dGVzKQ0KOTAzMTQzKDIzMSBtb2QgMjU2KTogTUFQUkVBRAkweGEzM2MgdGhy dSAweDEyNzJiCSgweDgzZjAgYnl0ZXMpDQo5MDMxNDQoMjMyIG1vZCAyNTYp OiBUUlVOQ0FURSBET1dOCWZyb20gMHg0MDAwMCB0byAweDMyYjhiDQo5MDMx NDUoMjMzIG1vZCAyNTYpOiBNQVBXUklURSAweDI1NzExIHRocnUgMHgyNWYw OQkoMHg3ZjkgYnl0ZXMpDQo5MDMxNDYoMjM0IG1vZCAyNTYpOiBNQVBXUklU RSAweGQyYjkgdGhydSAweDEzNDVkCSgweDYxYTUgYnl0ZXMpDQo5MDMxNDco MjM1IG1vZCAyNTYpOiBNQVBSRUFECTB4MzJhZGIgdGhydSAweDMyYjhhCSgw eGIwIGJ5dGVzKQ0KOTAzMTQ4KDIzNiBtb2QgMjU2KTogVFJVTkNBVEUgRE9X Tglmcm9tIDB4MzJiOGIgdG8gMHgxNDJkMA0KOTAzMTQ5KDIzNyBtb2QgMjU2 KTogV1JJVEUJMHgyNTVlNSB0aHJ1IDB4MmU5NzEJKDB4OTM4ZCBieXRlcykg SE9MRQ0KOTAzMTUwKDIzOCBtb2QgMjU2KTogTUFQV1JJVEUgMHgxYTI4NiB0 aHJ1IDB4MjQ0ZWYJKDB4YTI2YSBieXRlcykNCjkwMzE1MSgyMzkgbW9kIDI1 Nik6IFdSSVRFCTB4MjhlMjMgdGhydSAweDJjNzcwCSgweDM5NGUgYnl0ZXMp DQo5MDMxNTIoMjQwIG1vZCAyNTYpOiBNQVBXUklURSAweDEzMDBjIHRocnUg MHgxZDlmNgkoMHhhOWViIGJ5dGVzKQ0KOTAzMTUzKDI0MSBtb2QgMjU2KTog TUFQUkVBRAkweDFlYTEzIHRocnUgMHgyMTE0NgkoMHgyNzM0IGJ5dGVzKQ0K OTAzMTU0KDI0MiBtb2QgMjU2KTogTUFQUkVBRAkweDc5YjIgdGhydSAweGU0 MTcJKDB4NmE2NiBieXRlcykNCjkwMzE1NSgyNDMgbW9kIDI1Nik6IFRSVU5D QVRFIERPV04JZnJvbSAweDJlOTcyIHRvIDB4YzlhYQ0KOTAzMTU2KDI0NCBt b2QgMjU2KTogV1JJVEUJMHg5ODNlIHRocnUgMHgxNzlkNgkoMHhlMTk5IGJ5 dGVzKSBFWFRFTkQNCjkwMzE1NygyNDUgbW9kIDI1Nik6IFJFQUQJMHgxMTY3 OSB0aHJ1IDB4MTM0ODIJKDB4MWUwYSBieXRlcykNCjkwMzE1OCgyNDYgbW9k IDI1Nik6IFRSVU5DQVRFIFVQCWZyb20gMHgxNzlkNyB0byAweDE5NjU0DQo5 MDMxNTkoMjQ3IG1vZCAyNTYpOiBNQVBSRUFECTB4MTY2YWQgdGhydSAweDE5 NjUzCSgweDJmYTcgYnl0ZXMpDQo5MDMxNjAoMjQ4IG1vZCAyNTYpOiBSRUFE CTB4ZWJiOCB0aHJ1IDB4MTA4ZjUJKDB4MWQzZSBieXRlcykNCjkwMzE2MSgy NDkgbW9kIDI1Nik6IE1BUFdSSVRFIDB4MTM2ZjAgdGhydSAweDE2OGU2CSgw eDMxZjcgYnl0ZXMpDQo5MDMxNjIoMjUwIG1vZCAyNTYpOiBUUlVOQ0FURSBV UAlmcm9tIDB4MTk2NTQgdG8gMHgzZTY5Nw0KOTAzMTYzKDI1MSBtb2QgMjU2 KTogTUFQUkVBRAkweGU1NjcgdGhydSAweDFhMmVmCSgweGJkODkgYnl0ZXMp DQo5MDMxNjQoMjUyIG1vZCAyNTYpOiBNQVBXUklURSAweDM3MjZiIHRocnUg MHgzNzY3MwkoMHg0MDkgYnl0ZXMpDQo5MDMxNjUoMjUzIG1vZCAyNTYpOiBS RUFECTB4MTdmY2IgdGhydSAweDE4NmU1CSgweDcxYiBieXRlcykNCjkwMzE2 NigyNTQgbW9kIDI1Nik6IFRSVU5DQVRFIERPV04JZnJvbSAweDNlNjk3IHRv IDB4MWFjNA0KOTAzMTY3KDI1NSBtb2QgMjU2KTogUkVBRAkweDk2MiB0aHJ1 IDB4MWFjMwkoMHgxMTYyIGJ5dGVzKQ0KOTAzMTY4KDAgbW9kIDI1Nik6IE1B UFdSSVRFIDB4MjAwZGMgdGhydSAweDIwZGY2CSgweGQxYiBieXRlcykNCjkw MzE2OSgxIG1vZCAyNTYpOiBSRUFECTB4MTBlYWIgdGhydSAweDE3OTY2CSgw eDZhYmMgYnl0ZXMpDQo5MDMxNzAoMiBtb2QgMjU2KTogUkVBRAkweGI2OWQg dGhydSAweDE2Yzk3CSgweGI1ZmIgYnl0ZXMpDQo5MDMxNzEoMyBtb2QgMjU2 KTogTUFQUkVBRAkweDFiOWExIHRocnUgMHgyMGRmNgkoMHg1NDU2IGJ5dGVz KQ0KOTAzMTcyKDQgbW9kIDI1Nik6IFdSSVRFCTB4MmQ4YzcgdGhydSAweDM3 NWVlCSgweDlkMjggYnl0ZXMpIEhPTEUNCjkwMzE3Myg1IG1vZCAyNTYpOiBS RUFECTB4MWM3NzQgdGhydSAweDI2MjkxCSgweDliMWUgYnl0ZXMpDQo5MDMx NzQoNiBtb2QgMjU2KTogUkVBRAkweDJhNGUxIHRocnUgMHgyZGQ1NQkoMHgz ODc1IGJ5dGVzKQ0KOTAzMTc1KDcgbW9kIDI1Nik6IFdSSVRFCTB4MTk5ODkg dGhydSAweDI4YmEwCSgweGYyMTggYnl0ZXMpDQo5MDMxNzYoOCBtb2QgMjU2 KTogUkVBRAkweDU1YWQgdGhydSAweGFjMzkJKDB4NTY4ZCBieXRlcykNCjkw MzE3Nyg5IG1vZCAyNTYpOiBXUklURQkweDEwOWE2IHRocnUgMHgxMzRhNAko MHgyYWZmIGJ5dGVzKQ0KOTAzMTc4KDEwIG1vZCAyNTYpOiBSRUFECTB4MzM2 NTEgdGhydSAweDMzN2Y5CSgweDFhOSBieXRlcykNCjkwMzE3OSgxMSBtb2Qg MjU2KTogTUFQV1JJVEUgMHgzMWRmYiB0aHJ1IDB4M2ZmZmYJKDB4ZTIwNSBi eXRlcykNCjkwMzE4MCgxMiBtb2QgMjU2KTogUkVBRAkweDJhOSB0aHJ1IDB4 MzRmYgkoMHgzMjUzIGJ5dGVzKQkqKipSUlJSKioqDQo5MDMxODEoMTMgbW9k IDI1Nik6IFJFQUQJMHgzYzliOCB0aHJ1IDB4M2U4MTkJKDB4MWU2MiBieXRl cykNCjkwMzE4MigxNCBtb2QgMjU2KTogTUFQUkVBRAkweDNjMGYgdGhydSAw eDY0ZGYJKDB4MjhkMSBieXRlcykNCjkwMzE4MygxNSBtb2QgMjU2KTogVFJV TkNBVEUgRE9XTglmcm9tIDB4NDAwMDAgdG8gMHgxMDI3Ng0KOTAzMTg0KDE2 IG1vZCAyNTYpOiBNQVBSRUFECTB4MTAxZjUgdGhydSAweDEwMjc1CSgweDgx IGJ5dGVzKQ0KOTAzMTg1KDE3IG1vZCAyNTYpOiBNQVBXUklURSAweDJjNmJm IHRocnUgMHgzOGVlNgkoMHhjODI4IGJ5dGVzKQ0KOTAzMTg2KDE4IG1vZCAy NTYpOiBNQVBXUklURSAweDJkNDA1IHRocnUgMHgzNGQwZQkoMHg3OTBhIGJ5 dGVzKQ0KOTAzMTg3KDE5IG1vZCAyNTYpOiBXUklURQkweDE5YjAzIHRocnUg MHgyNTllOQkoMHhiZWU3IGJ5dGVzKQ0KOTAzMTg4KDIwIG1vZCAyNTYpOiBN QVBXUklURSAweDM3N2ZlIHRocnUgMHgzZmZmZgkoMHg4ODAyIGJ5dGVzKQ0K OTAzMTg5KDIxIG1vZCAyNTYpOiBSRUFECTB4MzgwM2UgdGhydSAweDNkNzQ1 CSgweDU3MDggYnl0ZXMpDQo5MDMxOTAoMjIgbW9kIDI1Nik6IFRSVU5DQVRF IERPV04JZnJvbSAweDQwMDAwIHRvIDB4MmRhZA0KOTAzMTkxKDIzIG1vZCAy NTYpOiBSRUFECTB4OWE0IHRocnUgMHgyNmEyCSgweDFjZmYgYnl0ZXMpDQo5 MDMxOTIoMjQgbW9kIDI1Nik6IFdSSVRFCTB4MzUyMTQgdGhydSAweDM5ZWM4 CSgweDRjYjUgYnl0ZXMpIEhPTEUNCjkwMzE5MygyNSBtb2QgMjU2KTogV1JJ VEUJMHhhMjk3IHRocnUgMHhiMTcxCSgweGVkYiBieXRlcykNCjkwMzE5NCgy NiBtb2QgMjU2KTogV1JJVEUJMHgxZWFkMSB0aHJ1IDB4MmUyMzQJKDB4Zjc2 NCBieXRlcykNCjkwMzE5NSgyNyBtb2QgMjU2KTogTUFQV1JJVEUgMHgyZGRi MyB0aHJ1IDB4MzY4MWIJKDB4OGE2OSBieXRlcykNCjkwMzE5NigyOCBtb2Qg MjU2KTogUkVBRAkweDJhY2IgdGhydSAweGIwYzcJKDB4ODVmZCBieXRlcykN CjkwMzE5NygyOSBtb2QgMjU2KTogUkVBRAkweDJmMjQ3IHRocnUgMHgyZmFj MAkoMHg4N2EgYnl0ZXMpDQo5MDMxOTgoMzAgbW9kIDI1Nik6IFdSSVRFCTB4 MTdmMzggdGhydSAweDIwYTY0CSgweDhiMmQgYnl0ZXMpDQo5MDMxOTkoMzEg bW9kIDI1Nik6IE1BUFJFQUQJMHhkNGRhIHRocnUgMHgxNmRjOQkoMHg5OGYw IGJ5dGVzKQ0KOTAzMjAwKDMyIG1vZCAyNTYpOiBNQVBSRUFECTB4YWYxMyB0 aHJ1IDB4MTE4NWUJKDB4Njk0YyBieXRlcykNCjkwMzIwMSgzMyBtb2QgMjU2 KTogVFJVTkNBVEUgRE9XTglmcm9tIDB4MzllYzkgdG8gMHgzMGM2DQo5MDMy MDIoMzQgbW9kIDI1Nik6IFdSSVRFCTB4MzBmNWYgdGhydSAweDM5ZjU1CSgw eDhmZjcgYnl0ZXMpIEhPTEUNCjkwMzIwMygzNSBtb2QgMjU2KTogUkVBRAkw eDE5ZmYyIHRocnUgMHgyNTBjZgkoMHhiMGRlIGJ5dGVzKQ0KOTAzMjA0KDM2 IG1vZCAyNTYpOiBXUklURQkweGNiMDUgdGhydSAweDEwMzcxCSgweDM4NmQg Ynl0ZXMpDQo5MDMyMDUoMzcgbW9kIDI1Nik6IE1BUFJFQUQJMHgxNzllYiB0 aHJ1IDB4MWU2NzUJKDB4NmM4YiBieXRlcykNCjkwMzIwNigzOCBtb2QgMjU2 KTogTUFQUkVBRAkweDFmOWQ5IHRocnUgMHgyYzlkNwkoMHhjZmZmIGJ5dGVz KQ0KOTAzMjA3KDM5IG1vZCAyNTYpOiBUUlVOQ0FURSBVUAlmcm9tIDB4Mzlm NTYgdG8gMHgzYWEzYw0KOTAzMjA4KDQwIG1vZCAyNTYpOiBXUklURQkweDYy YjYgdGhydSAweGNhODkJKDB4NjdkNCBieXRlcykNCjkwMzIwOSg0MSBtb2Qg MjU2KTogV1JJVEUJMHgyNzU3NiB0aHJ1IDB4MzBkN2YJKDB4OTgwYSBieXRl cykNCjkwMzIxMCg0MiBtb2QgMjU2KTogVFJVTkNBVEUgRE9XTglmcm9tIDB4 M2FhM2MgdG8gMHgzMmM1YQ0KOTAzMjExKDQzIG1vZCAyNTYpOiBXUklURQkw eDNjZmQ4IHRocnUgMHgzZmZmZgkoMHgzMDI4IGJ5dGVzKSBIT0xFDQo5MDMy MTIoNDQgbW9kIDI1Nik6IFdSSVRFCTB4ZmVkZSB0aHJ1IDB4MTU2MGEJKDB4 NTcyZCBieXRlcykNCjkwMzIxMyg0NSBtb2QgMjU2KTogV1JJVEUJMHgxOGFh NyB0aHJ1IDB4MjNkYzgJKDB4YjMyMiBieXRlcykNCjkwMzIxNCg0NiBtb2Qg MjU2KTogTUFQV1JJVEUgMHhmYzBiIHRocnUgMHgxOWQ5YgkoMHhhMTkxIGJ5 dGVzKQ0KOTAzMjE1KDQ3IG1vZCAyNTYpOiBUUlVOQ0FURSBET1dOCWZyb20g MHg0MDAwMCB0byAweDJjZjA2DQo5MDMyMTYoNDggbW9kIDI1Nik6IFRSVU5D QVRFIERPV04JZnJvbSAweDJjZjA2IHRvIDB4MjA4NWENCjkwMzIxNyg0OSBt b2QgMjU2KTogUkVBRAkweDFjZTllIHRocnUgMHgyMDg1OQkoMHgzOWJjIGJ5 dGVzKQ0KOTAzMjE4KDUwIG1vZCAyNTYpOiBNQVBSRUFECTB4MWIyNGQgdGhy dSAweDIwODU5CSgweDU2MGQgYnl0ZXMpDQo5MDMyMTkoNTEgbW9kIDI1Nik6 IFJFQUQJMHgxNmQzOCB0aHJ1IDB4MTliZDMJKDB4MmU5YyBieXRlcykNCjkw MzIyMCg1MiBtb2QgMjU2KTogTUFQUkVBRAkweDZiNSB0aHJ1IDB4YTBhOAko MHg5OWY0IGJ5dGVzKQkqKipSUlJSKioqDQo5MDMyMjEoNTMgbW9kIDI1Nik6 IE1BUFJFQUQJMHgxODJiMiB0aHJ1IDB4MWZlY2IJKDB4N2MxYSBieXRlcykN CjkwMzIyMig1NCBtb2QgMjU2KTogVFJVTkNBVEUgRE9XTglmcm9tIDB4MjA4 NWEgdG8gMHgyOGI0DQo5MDMyMjMoNTUgbW9kIDI1Nik6IE1BUFJFQUQJMHgy N2FmIHRocnUgMHgyOGIzCSgweDEwNSBieXRlcykNCjkwMzIyNCg1NiBtb2Qg MjU2KTogTUFQV1JJVEUgMHgxNTQwNSB0aHJ1IDB4MTgyMjEJKDB4MmUxZCBi eXRlcykNCjkwMzIyNSg1NyBtb2QgMjU2KTogUkVBRAkweDYzZjYgdGhydSAw eDhiM2IJKDB4Mjc0NiBieXRlcykNCjkwMzIyNig1OCBtb2QgMjU2KTogTUFQ V1JJVEUgMHgxYjFlYSB0aHJ1IDB4MWVlMjYJKDB4M2MzZCBieXRlcykNCjkw MzIyNyg1OSBtb2QgMjU2KTogTUFQUkVBRAkweDhkMmQgdGhydSAweDk1ZmEJ KDB4OGNlIGJ5dGVzKQ0KOTAzMjI4KDYwIG1vZCAyNTYpOiBUUlVOQ0FURSBV UAlmcm9tIDB4MWVlMjcgdG8gMHgyNmE0Nw0KOTAzMjI5KDYxIG1vZCAyNTYp OiBNQVBXUklURSAweDNkMGRhIHRocnUgMHgzZmZmZgkoMHgyZjI2IGJ5dGVz KQ0KOTAzMjMwKDYyIG1vZCAyNTYpOiBNQVBXUklURSAweDM0MWQ0IHRocnUg MHgzZmZmZgkoMHhiZTJjIGJ5dGVzKQ0KOTAzMjMxKDYzIG1vZCAyNTYpOiBN QVBXUklURSAweDNlYTMyIHRocnUgMHgzZmZmZgkoMHgxNWNlIGJ5dGVzKQ0K OTAzMjMyKDY0IG1vZCAyNTYpOiBNQVBSRUFECTB4MzY1NTggdGhydSAweDNm ZmZmCSgweDlhYTggYnl0ZXMpDQo5MDMyMzMoNjUgbW9kIDI1Nik6IFRSVU5D QVRFIERPV04JZnJvbSAweDQwMDAwIHRvIDB4MTM2MGINCjkwMzIzNCg2NiBt b2QgMjU2KTogV1JJVEUJMHhiNDQyIHRocnUgMHgxMDM2NAkoMHg0ZjIzIGJ5 dGVzKQ0KOTAzMjM1KDY3IG1vZCAyNTYpOiBNQVBSRUFECTB4MTA2YzggdGhy dSAweDEyZjNmCSgweDI4NzggYnl0ZXMpDQo5MDMyMzYoNjggbW9kIDI1Nik6 IFRSVU5DQVRFIFVQCWZyb20gMHgxMzYwYiB0byAweDNhMGI0DQo5MDMyMzco NjkgbW9kIDI1Nik6IE1BUFJFQUQJMHg0YWZjIHRocnUgMHg5YzI1CSgweDUx MmEgYnl0ZXMpDQo5MDMyMzgoNzAgbW9kIDI1Nik6IE1BUFJFQUQJMHhjMzk1 IHRocnUgMHgxMWQwZgkoMHg1OTdiIGJ5dGVzKQ0KOTAzMjM5KDcxIG1vZCAy NTYpOiBNQVBXUklURSAweDMxZTdjIHRocnUgMHgzOTVkYgkoMHg3NzYwIGJ5 dGVzKQ0KOTAzMjQwKDcyIG1vZCAyNTYpOiBNQVBXUklURSAweDE2YTRmIHRo cnUgMHgxNmQyOQkoMHgyZGIgYnl0ZXMpDQo5MDMyNDEoNzMgbW9kIDI1Nik6 IFdSSVRFCTB4M2RjMyB0aHJ1IDB4YTU5NgkoMHg2N2Q0IGJ5dGVzKQ0KOTAz MjQyKDc0IG1vZCAyNTYpOiBXUklURQkweDNkOTNkIHRocnUgMHgzZmZmZgko MHgyNmMzIGJ5dGVzKSBIT0xFDQo5MDMyNDMoNzUgbW9kIDI1Nik6IFdSSVRF CTB4MmI1ZDMgdGhydSAweDM3ZGNlCSgweGM3ZmMgYnl0ZXMpDQo5MDMyNDQo NzYgbW9kIDI1Nik6IE1BUFJFQUQJMHgyNTFhZSB0aHJ1IDB4MzE2NjIJKDB4 YzRiNSBieXRlcykNCjkwMzI0NSg3NyBtb2QgMjU2KTogTUFQV1JJVEUgMHgx NTAyOCB0aHJ1IDB4MjA0ZDMJKDB4YjRhYyBieXRlcykNCjkwMzI0Nig3OCBt b2QgMjU2KTogV1JJVEUJMHgzNzQ0OCB0aHJ1IDB4M2ZmZmYJKDB4OGJiOCBi eXRlcykNCjkwMzI0Nyg3OSBtb2QgMjU2KTogV1JJVEUJMHgyNWU3ZCB0aHJ1 IDB4MzVlNDIJKDB4ZmZjNiBieXRlcykNCjkwMzI0OCg4MCBtb2QgMjU2KTog UkVBRAkweDJjYmVhIHRocnUgMHgzYWM0YwkoMHhlMDYzIGJ5dGVzKQ0KOTAz MjQ5KDgxIG1vZCAyNTYpOiBNQVBXUklURSAweDNiYjFlIHRocnUgMHgzZmZm ZgkoMHg0NGUyIGJ5dGVzKQ0KOTAzMjUwKDgyIG1vZCAyNTYpOiBUUlVOQ0FU RSBET1dOCWZyb20gMHg0MDAwMCB0byAweDM2MGQ1DQo5MDMyNTEoODMgbW9k IDI1Nik6IFJFQUQJMHgyYjU5YyB0aHJ1IDB4MmZmOGMJKDB4NDlmMSBieXRl cykNCjkwMzI1Mig4NCBtb2QgMjU2KTogUkVBRAkweDI4NzIgdGhydSAweDNl OWEJKDB4MTYyOSBieXRlcykNCjkwMzI1Myg4NSBtb2QgMjU2KTogTUFQUkVB RAkweDE0YWI0IHRocnUgMHgxZDY0NwkoMHg4Yjk0IGJ5dGVzKQ0KOTAzMjU0 KDg2IG1vZCAyNTYpOiBXUklURQkweDExYWQ2IHRocnUgMHgxOTY5MgkoMHg3 YmJkIGJ5dGVzKQ0KOTAzMjU1KDg3IG1vZCAyNTYpOiBUUlVOQ0FURSBET1dO CWZyb20gMHgzNjBkNSB0byAweGUyOTQNCjkwMzI1Nig4OCBtb2QgMjU2KTog VFJVTkNBVEUgVVAJZnJvbSAweGUyOTQgdG8gMHgzZGIxNA0KOTAzMjU3KDg5 IG1vZCAyNTYpOiBNQVBXUklURSAweDk5MWQgdGhydSAweDE5NzM5CSgweGZl MWQgYnl0ZXMpDQo5MDMyNTgoOTAgbW9kIDI1Nik6IE1BUFdSSVRFIDB4MTgw MDcgdGhydSAweDI1NmYwCSgweGQ2ZWEgYnl0ZXMpDQo5MDMyNTkoOTEgbW9k IDI1Nik6IE1BUFdSSVRFIDB4MzgxNmEgdGhydSAweDNmZmZmCSgweDdlOTYg Ynl0ZXMpDQo5MDMyNjAoOTIgbW9kIDI1Nik6IFRSVU5DQVRFIERPV04JZnJv bSAweDQwMDAwIHRvIDB4MjQ2NTMNCjkwMzI2MSg5MyBtb2QgMjU2KTogV1JJ VEUJMHgyODFhNCB0aHJ1IDB4MzBhMWUJKDB4ODg3YiBieXRlcykgSE9MRQ0K OTAzMjYyKDk0IG1vZCAyNTYpOiBXUklURQkweDM0NGEyIHRocnUgMHgzZmU1 MQkoMHhiOWIwIGJ5dGVzKSBIT0xFDQo5MDMyNjMoOTUgbW9kIDI1Nik6IFRS VU5DQVRFIERPV04JZnJvbSAweDNmZTUyIHRvIDB4MTc2NWMNCjkwMzI2NCg5 NiBtb2QgMjU2KTogTUFQUkVBRAkweDE2NDA2IHRocnUgMHgxNzY1YgkoMHgx MjU2IGJ5dGVzKQ0KOTAzMjY1KDk3IG1vZCAyNTYpOiBNQVBSRUFECTB4NDE3 MyB0aHJ1IDB4YzA3ZQkoMHg3ZjBjIGJ5dGVzKQ0KOTAzMjY2KDk4IG1vZCAy NTYpOiBNQVBSRUFECTB4ZGQ2ZCB0aHJ1IDB4MTQxMjcJKDB4NjNiYiBieXRl cykNCjkwMzI2Nyg5OSBtb2QgMjU2KTogTUFQV1JJVEUgMHgxMGI3NyB0aHJ1 IDB4MWY2NGYJKDB4ZWFkOSBieXRlcykNCjkwMzI2OCgxMDAgbW9kIDI1Nik6 IE1BUFJFQUQJMHgyYTFhIHRocnUgMHg2NDc1CSgweDNhNWMgYnl0ZXMpDQo5 MDMyNjkoMTAxIG1vZCAyNTYpOiBXUklURQkweDM3ODQ5IHRocnUgMHgzYTM2 MwkoMHgyYjFiIGJ5dGVzKSBIT0xFDQo5MDMyNzAoMTAyIG1vZCAyNTYpOiBS RUFECTB4ZWJhOSB0aHJ1IDB4MWE4OGYJKDB4YmNlNyBieXRlcykNCjkwMzI3 MSgxMDMgbW9kIDI1Nik6IE1BUFJFQUQJMHgxYWZiNCB0aHJ1IDB4MjlkNWQJ KDB4ZWRhYSBieXRlcykNCjkwMzI3MigxMDQgbW9kIDI1Nik6IE1BUFJFQUQJ MHgxN2UzNCB0aHJ1IDB4MTlhNjMJKDB4MWMzMCBieXRlcykNCjkwMzI3Mygx MDUgbW9kIDI1Nik6IE1BUFdSSVRFIDB4YjU5MyB0aHJ1IDB4YzIxYwkoMHhj OGEgYnl0ZXMpDQo5MDMyNzQoMTA2IG1vZCAyNTYpOiBXUklURQkweGQ5MDEg dGhydSAweDEyNjE0CSgweDRkMTQgYnl0ZXMpDQo5MDMyNzUoMTA3IG1vZCAy NTYpOiBNQVBXUklURSAweDMwN2FlIHRocnUgMHgzYzdlNQkoMHhjMDM4IGJ5 dGVzKQ0KOTAzMjc2KDEwOCBtb2QgMjU2KTogUkVBRAkweDFlNzFlIHRocnUg MHgyMDQ5ZgkoMHgxZDgyIGJ5dGVzKQ0KOTAzMjc3KDEwOSBtb2QgMjU2KTog UkVBRAkweDllMDEgdGhydSAweDEyZGIyCSgweDhmYjIgYnl0ZXMpDQo5MDMy NzgoMTEwIG1vZCAyNTYpOiBUUlVOQ0FURSBET1dOCWZyb20gMHgzYzdlNiB0 byAweGViM2YNCjkwMzI3OSgxMTEgbW9kIDI1Nik6IE1BUFJFQUQJMHhlOGFj IHRocnUgMHhlYjNlCSgweDI5MyBieXRlcykNCjkwMzI4MCgxMTIgbW9kIDI1 Nik6IFJFQUQJMHgzYTU3IHRocnUgMHhjNWQ3CSgweDhiODEgYnl0ZXMpDQo5 MDMyODEoMTEzIG1vZCAyNTYpOiBXUklURQkweDEyZGY4IHRocnUgMHgxN2Vj MwkoMHg1MGNjIGJ5dGVzKSBIT0xFDQo5MDMyODIoMTE0IG1vZCAyNTYpOiBS RUFECTB4MTI0Y2MgdGhydSAweDE3ZWMzCSgweDU5ZjggYnl0ZXMpDQo5MDMy ODMoMTE1IG1vZCAyNTYpOiBUUlVOQ0FURSBVUAlmcm9tIDB4MTdlYzQgdG8g MHgyYmEwYw0KOTAzMjg0KDExNiBtb2QgMjU2KTogVFJVTkNBVEUgRE9XTglm cm9tIDB4MmJhMGMgdG8gMHgyMzkxYQ0KOTAzMjg1KDExNyBtb2QgMjU2KTog V1JJVEUJMHgzYTMwYSB0aHJ1IDB4M2ZmZmYJKDB4NWNmNiBieXRlcykgSE9M RQ0KOTAzMjg2KDExOCBtb2QgMjU2KTogVFJVTkNBVEUgRE9XTglmcm9tIDB4 NDAwMDAgdG8gMHg4OGRmDQo5MDMyODcoMTE5IG1vZCAyNTYpOiBNQVBXUklU RSAweGNjMDMgdGhydSAweDFjMjM2CSgweGY2MzQgYnl0ZXMpDQo5MDMyODgo MTIwIG1vZCAyNTYpOiBUUlVOQ0FURSBVUAlmcm9tIDB4MWMyMzcgdG8gMHgy NjYwYQ0KOTAzMjg5KDEyMSBtb2QgMjU2KTogTUFQUkVBRAkweDE1MjczIHRo cnUgMHgxN2U2NQkoMHgyYmYzIGJ5dGVzKQ0KOTAzMjkwKDEyMiBtb2QgMjU2 KTogV1JJVEUJMHgyOWZmMSB0aHJ1IDB4MmNjZGUJKDB4MmNlZSBieXRlcykg SE9MRQ0KOTAzMjkxKDEyMyBtb2QgMjU2KTogTUFQUkVBRAkweDgzMjIgdGhy dSAweDE1MjI0CSgweGNmMDMgYnl0ZXMpDQo5MDMyOTIoMTI0IG1vZCAyNTYp OiBXUklURQkweDMyNTg3IHRocnUgMHgzZmZmZgkoMHhkYTc5IGJ5dGVzKSBI T0xFDQo5MDMyOTMoMTI1IG1vZCAyNTYpOiBSRUFECTB4NTc5YyB0aHJ1IDB4 ZTRmNQkoMHg4ZDVhIGJ5dGVzKQ0KOTAzMjk0KDEyNiBtb2QgMjU2KTogTUFQ UkVBRAkweDJiNWU2IHRocnUgMHgzOTA4MQkoMHhkYTljIGJ5dGVzKQ0KOTAz Mjk1KDEyNyBtb2QgMjU2KTogTUFQUkVBRAkweDJkMWE3IHRocnUgMHgyZjhj MwkoMHgyNzFkIGJ5dGVzKQ0KOTAzMjk2KDEyOCBtb2QgMjU2KTogV1JJVEUJ MHhjMzNjIHRocnUgMHgxNGFiMAkoMHg4Nzc1IGJ5dGVzKQ0KOTAzMjk3KDEy OSBtb2QgMjU2KTogTUFQUkVBRAkweDI5MDE0IHRocnUgMHgzN2Q5OAkoMHhl ZDg1IGJ5dGVzKQ0KOTAzMjk4KDEzMCBtb2QgMjU2KTogTUFQV1JJVEUgMHgz OTE1MCB0aHJ1IDB4M2YxZDgJKDB4NjA4OSBieXRlcykNCjkwMzI5OSgxMzEg bW9kIDI1Nik6IE1BUFJFQUQJMHgxYzQ5OCB0aHJ1IDB4MjNlYzIJKDB4N2Ey YiBieXRlcykNCjkwMzMwMCgxMzIgbW9kIDI1Nik6IE1BUFdSSVRFIDB4MzI0 YjcgdGhydSAweDNiYWE4CSgweDk1ZjIgYnl0ZXMpDQo5MDMzMDEoMTMzIG1v ZCAyNTYpOiBNQVBSRUFECTB4MTE5ZWQgdGhydSAweDE3YjNmCSgweDYxNTMg Ynl0ZXMpDQo5MDMzMDIoMTM0IG1vZCAyNTYpOiBUUlVOQ0FURSBET1dOCWZy b20gMHg0MDAwMCB0byAweDEzNDJlDQo5MDMzMDMoMTM1IG1vZCAyNTYpOiBS RUFECTB4Mzc1YiB0aHJ1IDB4MTBlMmIJKDB4ZDZkMSBieXRlcykNCjkwMzMw NCgxMzYgbW9kIDI1Nik6IE1BUFJFQUQJMHgxMDIzMCB0aHJ1IDB4MTM0MmQJ KDB4MzFmZSBieXRlcykNCjkwMzMwNSgxMzcgbW9kIDI1Nik6IFdSSVRFCTB4 MzJkY2QgdGhydSAweDNhZDRjCSgweDdmODAgYnl0ZXMpIEhPTEUNCjkwMzMw NigxMzggbW9kIDI1Nik6IFdSSVRFCTB4N2IyMSB0aHJ1IDB4YjA5OAkoMHgz NTc4IGJ5dGVzKQ0KOTAzMzA3KDEzOSBtb2QgMjU2KTogUkVBRAkweGEyZmEg dGhydSAweDFhMmU5CSgweGZmZjAgYnl0ZXMpDQo5MDMzMDgoMTQwIG1vZCAy NTYpOiBUUlVOQ0FURSBET1dOCWZyb20gMHgzYWQ0ZCB0byAweDI0ODg4DQo5 MDMzMDkoMTQxIG1vZCAyNTYpOiBXUklURQkweDI2YTBjIHRocnUgMHgyYTEw ZQkoMHgzNzAzIGJ5dGVzKSBIT0xFDQo5MDMzMTAoMTQyIG1vZCAyNTYpOiBN QVBXUklURSAweDUxZmYgdGhydSAweDEzN2JiCSgweGU1YmQgYnl0ZXMpDQo5 MDMzMTEoMTQzIG1vZCAyNTYpOiBXUklURQkweDNiYjljIHRocnUgMHgzZTll NAkoMHgyZTQ5IGJ5dGVzKSBIT0xFDQo5MDMzMTIoMTQ0IG1vZCAyNTYpOiBU UlVOQ0FURSBET1dOCWZyb20gMHgzZTllNSB0byAweDFkY2JlDQo5MDMzMTMo MTQ1IG1vZCAyNTYpOiBSRUFECTB4Y2FhZSB0aHJ1IDB4MTk1MjYJKDB4Y2E3 OSBieXRlcykNCjkwMzMxNCgxNDYgbW9kIDI1Nik6IFJFQUQJMHhlYzFiIHRo cnUgMHgxNDg1ZgkoMHg1YzQ1IGJ5dGVzKQ0KOTAzMzE1KDE0NyBtb2QgMjU2 KTogTUFQUkVBRAkweDFjNDZiIHRocnUgMHgxZGNiZAkoMHgxODUzIGJ5dGVz KQ0KOTAzMzE2KDE0OCBtb2QgMjU2KTogVFJVTkNBVEUgRE9XTglmcm9tIDB4 MWRjYmUgdG8gMHgxM2QwDQo5MDMzMTcoMTQ5IG1vZCAyNTYpOiBSRUFECTB4 MTA4MCB0aHJ1IDB4MTNjZgkoMHgzNTAgYnl0ZXMpDQo5MDMzMTgoMTUwIG1v ZCAyNTYpOiBSRUFECTB4NzI3IHRocnUgMHgxM2NmCSgweGNhOSBieXRlcykJ KioqUlJSUioqKg0KOTAzMzE5KDE1MSBtb2QgMjU2KTogV1JJVEUJMHgzMGZl ZCB0aHJ1IDB4M2M2ZTMJKDB4YjZmNyBieXRlcykgSE9MRQ0KOTAzMzIwKDE1 MiBtb2QgMjU2KTogTUFQUkVBRAkweDMxZmQyIHRocnUgMHgzMmQ4ZgkoMHhk YmUgYnl0ZXMpDQo5MDMzMjEoMTUzIG1vZCAyNTYpOiBNQVBXUklURSAweDI1 NGZlIHRocnUgMHgyZTc5NwkoMHg5MjlhIGJ5dGVzKQ0KOTAzMzIyKDE1NCBt b2QgMjU2KTogV1JJVEUJMHgxYTk2YSB0aHJ1IDB4MjI4MzUJKDB4N2VjYyBi eXRlcykNCjkwMzMyMygxNTUgbW9kIDI1Nik6IFRSVU5DQVRFIERPV04JZnJv bSAweDNjNmU0IHRvIDB4ZGUxOA0KOTAzMzI0KDE1NiBtb2QgMjU2KTogTUFQ V1JJVEUgMHhjNGZjIHRocnUgMHhkZTlkCSgweDE5YTIgYnl0ZXMpDQo5MDMz MjUoMTU3IG1vZCAyNTYpOiBSRUFECTB4MWE5NiB0aHJ1IDB4YjU5YgkoMHg5 YjA2IGJ5dGVzKQ0KOTAzMzI2KDE1OCBtb2QgMjU2KTogV1JJVEUJMHgzMDNl MiB0aHJ1IDB4M2IwZWIJKDB4YWQwYSBieXRlcykgSE9MRQ0KOTAzMzI3KDE1 OSBtb2QgMjU2KTogTUFQUkVBRAkweDMzODg5IHRocnUgMHgzYjBlYgkoMHg3 ODYzIGJ5dGVzKQ0KOTAzMzI4KDE2MCBtb2QgMjU2KTogUkVBRAkweDk3YzIg dGhydSAweDE3MDc1CSgweGQ4YjQgYnl0ZXMpDQo5MDMzMjkoMTYxIG1vZCAy NTYpOiBNQVBXUklURSAweDFmZjg0IHRocnUgMHgyYmYzYgkoMHhiZmI4IGJ5 dGVzKQ0KOTAzMzMwKDE2MiBtb2QgMjU2KTogV1JJVEUJMHgxZDA0YiB0aHJ1 IDB4MjAzYzIJKDB4MzM3OCBieXRlcykNCjkwMzMzMSgxNjMgbW9kIDI1Nik6 IE1BUFdSSVRFIDB4MzVlNTEgdGhydSAweDNkZWQxCSgweDgwODEgYnl0ZXMp DQo5MDMzMzIoMTY0IG1vZCAyNTYpOiBUUlVOQ0FURSBET1dOCWZyb20gMHgz ZGVkMiB0byAweDNhYWEwDQo5MDMzMzMoMTY1IG1vZCAyNTYpOiBUUlVOQ0FU RSBET1dOCWZyb20gMHgzYWFhMCB0byAweGU1MzINCjkwMzMzNCgxNjYgbW9k IDI1Nik6IFdSSVRFCTB4MTIzN2QgdGhydSAweDFkYWRmCSgweGI3NjMgYnl0 ZXMpIEhPTEUNCjkwMzMzNSgxNjcgbW9kIDI1Nik6IFdSSVRFCTB4MWY0ZmMg dGhydSAweDJhM2VlCSgweGFlZjMgYnl0ZXMpIEhPTEUNCjkwMzMzNigxNjgg bW9kIDI1Nik6IFJFQUQJMHg5NGY5IHRocnUgMHgxMDY2YgkoMHg3MTczIGJ5 dGVzKQ0KOTAzMzM3KDE2OSBtb2QgMjU2KTogTUFQUkVBRAkweDE1NWMyIHRo cnUgMHgxNjcyMQkoMHgxMTYwIGJ5dGVzKQ0KOTAzMzM4KDE3MCBtb2QgMjU2 KTogVFJVTkNBVEUgRE9XTglmcm9tIDB4MmEzZWYgdG8gMHgyMGQzZQ0KOTAz MzM5KDE3MSBtb2QgMjU2KTogTUFQV1JJVEUgMHhhZWZkIHRocnUgMHgxMzJj MQkoMHg4M2M1IGJ5dGVzKQ0KOTAzMzQwKDE3MiBtb2QgMjU2KTogTUFQV1JJ VEUgMHgyMjNmMiB0aHJ1IDB4MjVjZGYJKDB4MzhlZSBieXRlcykNCjkwMzM0 MSgxNzMgbW9kIDI1Nik6IFJFQUQJMHgxYTEwNCB0aHJ1IDB4MWRlMjIJKDB4 M2QxZiBieXRlcykNCjkwMzM0MigxNzQgbW9kIDI1Nik6IFJFQUQJMHgxNWI4 YSB0aHJ1IDB4MTZkMTkJKDB4MTE5MCBieXRlcykNCjkwMzM0MygxNzUgbW9k IDI1Nik6IE1BUFdSSVRFIDB4MzVlNWIgdGhydSAweDNmZmZmCSgweGExYTUg Ynl0ZXMpDQo5MDMzNDQoMTc2IG1vZCAyNTYpOiBUUlVOQ0FURSBET1dOCWZy b20gMHg0MDAwMCB0byAweDFjY2YxDQo5MDMzNDUoMTc3IG1vZCAyNTYpOiBU UlVOQ0FURSBVUAlmcm9tIDB4MWNjZjEgdG8gMHgzMGIzYQ0KOTAzMzQ2KDE3 OCBtb2QgMjU2KTogUkVBRAkweDFkYjQgdGhydSAweGIzN2YJKDB4OTVjYyBi eXRlcykNCjkwMzM0NygxNzkgbW9kIDI1Nik6IFJFQUQJMHgxZWI0IHRocnUg MHg1MGNlCSgweDMyMWIgYnl0ZXMpDQo5MDMzNDgoMTgwIG1vZCAyNTYpOiBN QVBSRUFECTB4M2NmNiB0aHJ1IDB4N2Q0NwkoMHg0MDUyIGJ5dGVzKQ0KOTAz MzQ5KDE4MSBtb2QgMjU2KTogUkVBRAkweDIwZTFlIHRocnUgMHgyZDFkNQko MHhjM2I4IGJ5dGVzKQ0KOTAzMzUwKDE4MiBtb2QgMjU2KTogTUFQUkVBRAkw eDEzNDZjIHRocnUgMHgyMjI0MQkoMHhlZGQ2IGJ5dGVzKQ0KOTAzMzUxKDE4 MyBtb2QgMjU2KTogV1JJVEUJMHgyOWE4OCB0aHJ1IDB4MzMxNzYJKDB4OTZl ZiBieXRlcykgRVhURU5EDQo5MDMzNTIoMTg0IG1vZCAyNTYpOiBNQVBSRUFE CTB4Mjg5NyB0aHJ1IDB4NWIzNgkoMHgzMmEwIGJ5dGVzKQ0KOTAzMzUzKDE4 NSBtb2QgMjU2KTogTUFQUkVBRAkweDJmOTMwIHRocnUgMHgzMzE3NgkoMHgz ODQ3IGJ5dGVzKQ0KOTAzMzU0KDE4NiBtb2QgMjU2KTogV1JJVEUJMHgzOGU3 NSB0aHJ1IDB4M2ZmZmYJKDB4NzE4YiBieXRlcykgSE9MRQ0KOTAzMzU1KDE4 NyBtb2QgMjU2KTogV1JJVEUJMHgxYWU3IHRocnUgMHgxMGQ3MQkoMHhmMjhi IGJ5dGVzKQ0KOTAzMzU2KDE4OCBtb2QgMjU2KTogTUFQUkVBRAkweDE1MDI4 IHRocnUgMHgxNmZhZQkoMHgxZjg3IGJ5dGVzKQ0KOTAzMzU3KDE4OSBtb2Qg MjU2KTogUkVBRAkweDIzMTMyIHRocnUgMHgyZmNlNwkoMHhjYmI2IGJ5dGVz KQ0KOTAzMzU4KDE5MCBtb2QgMjU2KTogTUFQUkVBRAkweDM0YTM5IHRocnUg MHgzZmZmZgkoMHhiNWM3IGJ5dGVzKQ0KOTAzMzU5KDE5MSBtb2QgMjU2KTog V1JJVEUJMHgzN2I3MCB0aHJ1IDB4M2FiYjYJKDB4MzA0NyBieXRlcykNCjkw MzM2MCgxOTIgbW9kIDI1Nik6IFJFQUQJMHgxY2Y5NSB0aHJ1IDB4MjdjYzMJ KDB4YWQyZiBieXRlcykNCjkwMzM2MSgxOTMgbW9kIDI1Nik6IE1BUFJFQUQJ MHgxMjM1IHRocnUgMHgxOGY0CSgweDZjMCBieXRlcykNCjkwMzM2MigxOTQg bW9kIDI1Nik6IFRSVU5DQVRFIERPV04JZnJvbSAweDQwMDAwIHRvIDB4MWFh OGMNCjkwMzM2MygxOTUgbW9kIDI1Nik6IE1BUFdSSVRFIDB4MzJjNDYgdGhy dSAweDM1YzU3CSgweDMwMTIgYnl0ZXMpDQo5MDMzNjQoMTk2IG1vZCAyNTYp OiBNQVBXUklURSAweGQ4YjYgdGhydSAweDFhNmZkCSgweGNlNDggYnl0ZXMp DQo5MDMzNjUoMTk3IG1vZCAyNTYpOiBUUlVOQ0FURSBET1dOCWZyb20gMHgz NWM1OCB0byAweDI5MGU5DQo5MDMzNjYoMTk4IG1vZCAyNTYpOiBNQVBXUklU RSAweDE2ZjkwIHRocnUgMHgxZGE3NwkoMHg2YWU4IGJ5dGVzKQ0KOTAzMzY3 KDE5OSBtb2QgMjU2KTogVFJVTkNBVEUgRE9XTglmcm9tIDB4MjkwZTkgdG8g MHgxZGM5YQ0KOTAzMzY4KDIwMCBtb2QgMjU2KTogV1JJVEUJMHgxOGQ4MyB0 aHJ1IDB4MTlkZGEJKDB4MTA1OCBieXRlcykNCjkwMzM2OSgyMDEgbW9kIDI1 Nik6IFJFQUQJMHgxYmExMyB0aHJ1IDB4MWRjOTkJKDB4MjI4NyBieXRlcykN CjkwMzM3MCgyMDIgbW9kIDI1Nik6IFRSVU5DQVRFIERPV04JZnJvbSAweDFk YzlhIHRvIDB4MTBiZjANCjkwMzM3MSgyMDMgbW9kIDI1Nik6IE1BUFdSSVRF IDB4OGE4MCB0aHJ1IDB4MTZmMjEJKDB4ZTRhMiBieXRlcykNCjkwMzM3Migy MDQgbW9kIDI1Nik6IFRSVU5DQVRFIERPV04JZnJvbSAweDE2ZjIyIHRvIDB4 MTNiYzcNCjkwMzM3MygyMDUgbW9kIDI1Nik6IE1BUFJFQUQJMHg3NGRjIHRo cnUgMHhiMGJiCSgweDNiZTAgYnl0ZXMpDQo5MDMzNzQoMjA2IG1vZCAyNTYp OiBNQVBSRUFECTB4NmZhZCB0aHJ1IDB4ZmU4MAkoMHg4ZWQ0IGJ5dGVzKQ0K OTAzMzc1KDIwNyBtb2QgMjU2KTogTUFQV1JJVEUgMHgxZWU5ZSB0aHJ1IDB4 MWVmNjkJKDB4Y2MgYnl0ZXMpDQo5MDMzNzYoMjA4IG1vZCAyNTYpOiBNQVBX UklURSAweDI0YmVhIHRocnUgMHgyYTcxNgkoMHg1YjJkIGJ5dGVzKQ0KOTAz Mzc3KDIwOSBtb2QgMjU2KTogUkVBRAkweDE2YmUzIHRocnUgMHgyM2UwYQko MHhkMjI4IGJ5dGVzKQ0KOTAzMzc4KDIxMCBtb2QgMjU2KTogV1JJVEUJMHgz ZTcxMCB0aHJ1IDB4M2ZmZmYJKDB4MThmMCBieXRlcykgSE9MRQ0KOTAzMzc5 KDIxMSBtb2QgMjU2KTogTUFQUkVBRAkweDFiNDQ4IHRocnUgMHgyYjBmYgko MHhmY2I0IGJ5dGVzKQ0KOTAzMzgwKDIxMiBtb2QgMjU2KTogTUFQUkVBRAkw eDM5ZDlhIHRocnUgMHgzZmZmZgkoMHg2MjY2IGJ5dGVzKQ0KOTAzMzgxKDIx MyBtb2QgMjU2KTogTUFQV1JJVEUgMHgxNGY4MiB0aHJ1IDB4MWZkNzAJKDB4 YWRlZiBieXRlcykNCjkwMzM4MigyMTQgbW9kIDI1Nik6IFdSSVRFCTB4MWVk OTkgdGhydSAweDIzMWIwCSgweDQ0MTggYnl0ZXMpDQo5MDMzODMoMjE1IG1v ZCAyNTYpOiBNQVBSRUFECTB4MjI2MGYgdGhydSAweDI1Y2RiCSgweDM2Y2Qg Ynl0ZXMpDQo5MDMzODQoMjE2IG1vZCAyNTYpOiBXUklURQkweDEyODM1IHRo cnUgMHgxODVkZQkoMHg1ZGFhIGJ5dGVzKQ0KOTAzMzg1KDIxNyBtb2QgMjU2 KTogV1JJVEUJMHgyN2I4YSB0aHJ1IDB4MmYwMzgJKDB4NzRhZiBieXRlcykN CjkwMzM4NigyMTggbW9kIDI1Nik6IFRSVU5DQVRFIERPV04JZnJvbSAweDQw MDAwIHRvIDB4MjdmMjkNCjkwMzM4NygyMTkgbW9kIDI1Nik6IFJFQUQJMHgx ZTRlNyB0aHJ1IDB4MjI2NjEJKDB4NDE3YiBieXRlcykNCjkwMzM4OCgyMjAg bW9kIDI1Nik6IE1BUFdSSVRFIDB4MTZhMzIgdGhydSAweDFlZDg3CSgweDgz NTYgYnl0ZXMpDQo5MDMzODkoMjIxIG1vZCAyNTYpOiBXUklURQkweDM4N2Jk IHRocnUgMHgzZTA0MQkoMHg1ODg1IGJ5dGVzKSBIT0xFDQo5MDMzOTAoMjIy IG1vZCAyNTYpOiBNQVBSRUFECTB4MTIwOTUgdGhydSAweDE5NmU3CSgweDc2 NTMgYnl0ZXMpDQo5MDMzOTEoMjIzIG1vZCAyNTYpOiBXUklURQkweDFmOTQ0 IHRocnUgMHgyYzA1OAkoMHhjNzE1IGJ5dGVzKQ0KOTAzMzkyKDIyNCBtb2Qg MjU2KTogUkVBRAkweDNiYjk3IHRocnUgMHgzZTA0MQkoMHgyNGFiIGJ5dGVz KQ0KOTAzMzkzKDIyNSBtb2QgMjU2KTogUkVBRAkweDE3YjNmIHRocnUgMHgx Y2IxNQkoMHg0ZmQ3IGJ5dGVzKQ0KOTAzMzk0KDIyNiBtb2QgMjU2KTogVFJV TkNBVEUgRE9XTglmcm9tIDB4M2UwNDIgdG8gMHgyMWZjMA0KOTAzMzk1KDIy NyBtb2QgMjU2KTogTUFQUkVBRAkweGEzNTAgdGhydSAweGM0YzQJKDB4MjE3 NSBieXRlcykNCjkwMzM5NigyMjggbW9kIDI1Nik6IFdSSVRFCTB4MzBiNGYg dGhydSAweDMxOGYzCSgweGRhNSBieXRlcykgSE9MRQ0KOTAzMzk3KDIyOSBt b2QgMjU2KTogVFJVTkNBVEUgVVAJZnJvbSAweDMxOGY0IHRvIDB4MzI0YTcN CjkwMzM5OCgyMzAgbW9kIDI1Nik6IFdSSVRFCTB4MTYwOTkgdGhydSAweDIw ODcwCSgweGE3ZDggYnl0ZXMpDQo5MDMzOTkoMjMxIG1vZCAyNTYpOiBNQVBS RUFECTB4ZTYwOSB0aHJ1IDB4MWJhYWMJKDB4ZDRhNCBieXRlcykNCjkwMzQw MCgyMzIgbW9kIDI1Nik6IE1BUFJFQUQJMHgxNzViMiB0aHJ1IDB4MWNlYTIJ KDB4NThmMSBieXRlcykNCjkwMzQwMSgyMzMgbW9kIDI1Nik6IE1BUFdSSVRF IDB4OGI5YiB0aHJ1IDB4ZTg4ZgkoMHg1Y2Y1IGJ5dGVzKQ0KOTAzNDAyKDIz NCBtb2QgMjU2KTogUkVBRAkweDJjNjMgdGhydSAweGIyNDQJKDB4ODVlMiBi eXRlcykNCjkwMzQwMygyMzUgbW9kIDI1Nik6IFdSSVRFCTB4MjhiZiB0aHJ1 IDB4ZjU5ZAkoMHhjY2RmIGJ5dGVzKQ0KOTAzNDA0KDIzNiBtb2QgMjU2KTog TUFQV1JJVEUgMHgzMzM4OSB0aHJ1IDB4M2ZmZmYJKDB4Y2M3NyBieXRlcykN CjkwMzQwNSgyMzcgbW9kIDI1Nik6IE1BUFJFQUQJMHgyNjE2YyB0aHJ1IDB4 MjhjMWMJKDB4MmFiMSBieXRlcykNCjkwMzQwNigyMzggbW9kIDI1Nik6IFdS SVRFCTB4MmJhYTMgdGhydSAweDJlNjRmCSgweDJiYWQgYnl0ZXMpDQo5MDM0 MDcoMjM5IG1vZCAyNTYpOiBUUlVOQ0FURSBET1dOCWZyb20gMHg0MDAwMCB0 byAweDM3N2NkDQo5MDM0MDgoMjQwIG1vZCAyNTYpOiBNQVBSRUFECTB4MWEy NzQgdGhydSAweDFkMTY5CSgweDJlZjYgYnl0ZXMpDQo5MDM0MDkoMjQxIG1v ZCAyNTYpOiBXUklURQkweDE3ZDk2IHRocnUgMHgyNDc4YgkoMHhjOWY2IGJ5 dGVzKQ0KOTAzNDEwKDI0MiBtb2QgMjU2KTogTUFQUkVBRAkweDRmMGUgdGhy dSAweDUwMGEJKDB4ZmQgYnl0ZXMpDQo5MDM0MTEoMjQzIG1vZCAyNTYpOiBU UlVOQ0FURSBET1dOCWZyb20gMHgzNzdjZCB0byAweDEwYzhmDQo5MDM0MTIo MjQ0IG1vZCAyNTYpOiBSRUFECTB4Y2ZjMSB0aHJ1IDB4MTBjOGUJKDB4M2Nj ZSBieXRlcykNCjkwMzQxMygyNDUgbW9kIDI1Nik6IE1BUFJFQUQJMHhjMGFh IHRocnUgMHhkMjNhCSgweDExOTEgYnl0ZXMpDQo5MDM0MTQoMjQ2IG1vZCAy NTYpOiBXUklURQkweDJjNmFkIHRocnUgMHgzMGEzNwkoMHg0MzhiIGJ5dGVz KSBIT0xFDQo5MDM0MTUoMjQ3IG1vZCAyNTYpOiBNQVBSRUFECTB4MWVjZWEg dGhydSAweDJjZDcxCSgweGUwODggYnl0ZXMpDQo5MDM0MTYoMjQ4IG1vZCAy NTYpOiBNQVBSRUFECTB4MjYxZWQgdGhydSAweDMwYTM3CSgweGE4NGIgYnl0 ZXMpDQo5MDM0MTcoMjQ5IG1vZCAyNTYpOiBNQVBSRUFECTB4MzA0OTcgdGhy dSAweDMwYTM3CSgweDVhMSBieXRlcykNCjkwMzQxOCgyNTAgbW9kIDI1Nik6 IFRSVU5DQVRFIERPV04JZnJvbSAweDMwYTM4IHRvIDB4MTQ2OWYNCjkwMzQx OSgyNTEgbW9kIDI1Nik6IE1BUFdSSVRFIDB4YWNhMCB0aHJ1IDB4MTIzZjIJ KDB4Nzc1MyBieXRlcykNCjkwMzQyMCgyNTIgbW9kIDI1Nik6IE1BUFJFQUQJ MHg1MTBjIHRocnUgMHg4MDYwCSgweDJmNTUgYnl0ZXMpDQo5MDM0MjEoMjUz IG1vZCAyNTYpOiBUUlVOQ0FURSBET1dOCWZyb20gMHgxNDY5ZiB0byAweGIz YzkNCjkwMzQyMigyNTQgbW9kIDI1Nik6IE1BUFJFQUQJMHg3NzY5IHRocnUg MHhiM2M4CSgweDNjNjAgYnl0ZXMpDQo5MDM0MjMoMjU1IG1vZCAyNTYpOiBU UlVOQ0FURSBVUAlmcm9tIDB4YjNjOSB0byAweDMyODc5DQo5MDM0MjQoMCBt b2QgMjU2KTogTUFQV1JJVEUgMHgxMDc3ZiB0aHJ1IDB4MTYxYjcJKDB4NWEz OSBieXRlcykNCjkwMzQyNSgxIG1vZCAyNTYpOiBNQVBSRUFECTB4MjA2MGYg dGhydSAweDJiODQyCSgweGIyMzQgYnl0ZXMpDQo5MDM0MjYoMiBtb2QgMjU2 KTogVFJVTkNBVEUgVVAJZnJvbSAweDMyODc5IHRvIDB4M2M3ZDgNCjkwMzQy NygzIG1vZCAyNTYpOiBXUklURQkweDEzYWYxIHRocnUgMHgxZTQ1YgkoMHhh OTZiIGJ5dGVzKQ0KOTAzNDI4KDQgbW9kIDI1Nik6IE1BUFJFQUQJMHgxOTNm YSB0aHJ1IDB4MWFjYzUJKDB4MThjYyBieXRlcykNCjkwMzQyOSg1IG1vZCAy NTYpOiBNQVBXUklURSAweGU1NDYgdGhydSAweGYwYmEJKDB4Yjc1IGJ5dGVz KQ0KOTAzNDMwKDYgbW9kIDI1Nik6IFRSVU5DQVRFIERPV04JZnJvbSAweDNj N2Q4IHRvIDB4MWVhNzkNCjkwMzQzMSg3IG1vZCAyNTYpOiBNQVBSRUFECTB4 MTJkZGMgdGhydSAweDFlYTc4CSgweGJjOWQgYnl0ZXMpDQo5MDM0MzIoOCBt b2QgMjU2KTogTUFQUkVBRAkweDI4Y2YgdGhydSAweGE5MWMJKDB4ODA0ZSBi eXRlcykNCjkwMzQzMyg5IG1vZCAyNTYpOiBSRUFECTB4YzJiZiB0aHJ1IDB4 Yzg0OAkoMHg1OGEgYnl0ZXMpDQo5MDM0MzQoMTAgbW9kIDI1Nik6IE1BUFJF QUQJMHgxMDc0NiB0aHJ1IDB4MTFlNjkJKDB4MTcyNCBieXRlcykNCjkwMzQz NSgxMSBtb2QgMjU2KTogTUFQV1JJVEUgMHg1MjcgdGhydSAweDE5MzEJKDB4 MTQwYiBieXRlcykJKioqKioqV1dXVw0KOTAzNDM2KDEyIG1vZCAyNTYpOiBN QVBXUklURSAweDViNTQgdGhydSAweDE0YWIxCSgweGVmNWUgYnl0ZXMpDQo5 MDM0MzcoMTMgbW9kIDI1Nik6IE1BUFJFQUQJMHgxMGYyMSB0aHJ1IDB4MTMy MDIJKDB4MjJlMiBieXRlcykNCjkwMzQzOCgxNCBtb2QgMjU2KTogV1JJVEUJ MHgzOGYxOCB0aHJ1IDB4M2ZmZmYJKDB4NzBlOCBieXRlcykgSE9MRQ0KOTAz NDM5KDE1IG1vZCAyNTYpOiBXUklURQkweDFhNDExIHRocnUgMHgyNTJhYQko MHhhZTlhIGJ5dGVzKQ0KOTAzNDQwKDE2IG1vZCAyNTYpOiBNQVBSRUFECTB4 NDE3OCB0aHJ1IDB4ZGY0YQkoMHg5ZGQzIGJ5dGVzKQ0KOTAzNDQxKDE3IG1v ZCAyNTYpOiBNQVBSRUFECTB4MzYxZmYgdGhydSAweDNmZmZmCSgweDllMDEg Ynl0ZXMpDQo5MDM0NDIoMTggbW9kIDI1Nik6IE1BUFJFQUQJMHgxY2I3NyB0 aHJ1IDB4MmFlOGMJKDB4ZTMxNiBieXRlcykNCjkwMzQ0MygxOSBtb2QgMjU2 KTogV1JJVEUJMHgyZmI3ZiB0aHJ1IDB4MzFhMWUJKDB4MWVhMCBieXRlcykN CjkwMzQ0NCgyMCBtb2QgMjU2KTogV1JJVEUJMHgxMzJiNiB0aHJ1IDB4MWUx YzcJKDB4YWYxMiBieXRlcykNCjkwMzQ0NSgyMSBtb2QgMjU2KTogTUFQUkVB RAkweDEwMDYgdGhydSAweGM2NGUJKDB4YjY0OSBieXRlcykNCjkwMzQ0Nigy MiBtb2QgMjU2KTogVFJVTkNBVEUgRE9XTglmcm9tIDB4NDAwMDAgdG8gMHgz YTJlYw0KOTAzNDQ3KDIzIG1vZCAyNTYpOiBSRUFECTB4ZDI2ZSB0aHJ1IDB4 ZWE2ZAkoMHgxODAwIGJ5dGVzKQ0KOTAzNDQ4KDI0IG1vZCAyNTYpOiBXUklU RQkweDIxNzI0IHRocnUgMHgyNTVmZQkoMHgzZWRiIGJ5dGVzKQ0KOTAzNDQ5 KDI1IG1vZCAyNTYpOiBNQVBXUklURSAweDM2NDE2IHRocnUgMHgzOTUxNQko MHgzMTAwIGJ5dGVzKQ0KOTAzNDUwKDI2IG1vZCAyNTYpOiBNQVBXUklURSAw eDJlOWE0IHRocnUgMHgzMzM1MAkoMHg0OWFkIGJ5dGVzKQ0KOTAzNDUxKDI3 IG1vZCAyNTYpOiBNQVBXUklURSAweDZjM2EgdGhydSAweGY3N2UJKDB4OGI0 NSBieXRlcykNCjkwMzQ1MigyOCBtb2QgMjU2KTogTUFQV1JJVEUgMHgxYWQ3 ZiB0aHJ1IDB4MjhhNWEJKDB4ZGNkYyBieXRlcykNCjkwMzQ1MygyOSBtb2Qg MjU2KTogTUFQUkVBRAkweDFmMjRiIHRocnUgMHgyMmNhOAkoMHgzYTVlIGJ5 dGVzKQ0KOTAzNDU0KDMwIG1vZCAyNTYpOiBNQVBSRUFECTB4NWExNiB0aHJ1 IDB4YTAzMwkoMHg0NjFlIGJ5dGVzKQ0KOTAzNDU1KDMxIG1vZCAyNTYpOiBX UklURQkweGIwZmUgdGhydSAweDE4YjFjCSgweGRhMWYgYnl0ZXMpDQo5MDM0 NTYoMzIgbW9kIDI1Nik6IFJFQUQJMHgxMzI1MiB0aHJ1IDB4MTcyNzUJKDB4 NDAyNCBieXRlcykNCjkwMzQ1NygzMyBtb2QgMjU2KTogVFJVTkNBVEUgVVAJ ZnJvbSAweDNhMmVjIHRvIDB4M2ZiZDUNCjkwMzQ1OCgzNCBtb2QgMjU2KTog TUFQUkVBRAkweGViNzkgdGhydSAweDEzNDBlCSgweDQ4OTYgYnl0ZXMpDQo5 MDM0NTkoMzUgbW9kIDI1Nik6IE1BUFJFQUQJMHgzYWVhZSB0aHJ1IDB4M2Zi ZDQJKDB4NGQyNyBieXRlcykNCjkwMzQ2MCgzNiBtb2QgMjU2KTogUkVBRAkw eDFhMDgxIHRocnUgMHgxZDIyYgkoMHgzMWFiIGJ5dGVzKQ0KOTAzNDYxKDM3 IG1vZCAyNTYpOiBXUklURQkweDM2MWFmIHRocnUgMHgzZmJmOAkoMHg5YTRh IGJ5dGVzKSBFWFRFTkQNCjkwMzQ2MigzOCBtb2QgMjU2KTogV1JJVEUJMHgx NDJjZCB0aHJ1IDB4MWMyNjYJKDB4N2Y5YSBieXRlcykNCjkwMzQ2MygzOSBt b2QgMjU2KTogTUFQUkVBRAkweDJkYjk4IHRocnUgMHgzMWE1ZgkoMHgzZWM4 IGJ5dGVzKQ0KOTAzNDY0KDQwIG1vZCAyNTYpOiBUUlVOQ0FURSBET1dOCWZy b20gMHgzZmJmOSB0byAweDNiYjlkDQo5MDM0NjUoNDEgbW9kIDI1Nik6IFdS SVRFCTB4MjkzYTYgdGhydSAweDJkOTY5CSgweDQ1YzQgYnl0ZXMpDQo5MDM0 NjYoNDIgbW9kIDI1Nik6IFJFQUQJMHg4ZThjIHRocnUgMHhhYzNiCSgweDFk YjAgYnl0ZXMpDQo5MDM0NjcoNDMgbW9kIDI1Nik6IFJFQUQJMHgyY2Q0NSB0 aHJ1IDB4MzU5ODAJKDB4OGMzYyBieXRlcykNCjkwMzQ2OCg0NCBtb2QgMjU2 KTogV1JJVEUJMHgxMzJmMiB0aHJ1IDB4MWY3YWUJKDB4YzRiZCBieXRlcykN CjkwMzQ2OSg0NSBtb2QgMjU2KTogTUFQV1JJVEUgMHgxZDg1ZCB0aHJ1IDB4 MjA0MGEJKDB4MmJhZSBieXRlcykNCjkwMzQ3MCg0NiBtb2QgMjU2KTogV1JJ VEUJMHgxNjNiOSB0aHJ1IDB4MjYyYzUJKDB4ZmYwZCBieXRlcykNCjkwMzQ3 MSg0NyBtb2QgMjU2KTogTUFQUkVBRAkweDMyOTc0IHRocnUgMHgzMmY2Mgko MHg1ZWYgYnl0ZXMpDQo5MDM0NzIoNDggbW9kIDI1Nik6IFJFQUQJMHgxYWI2 NyB0aHJ1IDB4MjVjNjAJKDB4YjBmYSBieXRlcykNCjkwMzQ3Myg0OSBtb2Qg MjU2KTogUkVBRAkweDFhM2E1IHRocnUgMHgxYzMwOQkoMHgxZjY1IGJ5dGVz KQ0KOTAzNDc0KDUwIG1vZCAyNTYpOiBUUlVOQ0FURSBET1dOCWZyb20gMHgz YmI5ZCB0byAweDJiOTM1DQo5MDM0NzUoNTEgbW9kIDI1Nik6IFJFQUQJMHgx MDk1YSB0aHJ1IDB4MTJjYTYJKDB4MjM0ZCBieXRlcykNCjkwMzQ3Nig1MiBt b2QgMjU2KTogTUFQV1JJVEUgMHgzMTA4ZSB0aHJ1IDB4M2Y2MzUJKDB4ZTVh OCBieXRlcykNCjkwMzQ3Nyg1MyBtb2QgMjU2KTogTUFQV1JJVEUgMHgxZWMy MCB0aHJ1IDB4MmI3ZjkJKDB4Y2JkYSBieXRlcykNCjkwMzQ3OCg1NCBtb2Qg MjU2KTogV1JJVEUJMHgyZjNmNiB0aHJ1IDB4M2UyN2EJKDB4ZWU4NSBieXRl cykNCjkwMzQ3OSg1NSBtb2QgMjU2KTogTUFQV1JJVEUgMHg2YTQgdGhydSAw eDkyYmEJKDB4OGMxNyBieXRlcykJKioqKioqV1dXVw0KOTAzNDgwKDU2IG1v ZCAyNTYpOiBNQVBSRUFECTB4MjU0NGIgdGhydSAweDJmZGFlCSgweGE5NjQg Ynl0ZXMpDQo5MDM0ODEoNTcgbW9kIDI1Nik6IE1BUFdSSVRFIDB4MTU3MjEg dGhydSAweDIzZDUyCSgweGU2MzIgYnl0ZXMpDQo5MDM0ODIoNTggbW9kIDI1 Nik6IE1BUFdSSVRFIDB4MzYyYzUgdGhydSAweDNmZmZmCSgweDlkM2IgYnl0 ZXMpDQo5MDM0ODMoNTkgbW9kIDI1Nik6IE1BUFJFQUQJMHhmOTkgdGhydSAw eDcyMzMJKDB4NjI5YiBieXRlcykNCjkwMzQ4NCg2MCBtb2QgMjU2KTogV1JJ VEUJMHgyOWVmIHRocnUgMHhmZGJkCSgweGQzY2YgYnl0ZXMpDQo5MDM0ODUo NjEgbW9kIDI1Nik6IE1BUFdSSVRFIDB4MzI2NTggdGhydSAweDNmMTUyCSgw eGNhZmIgYnl0ZXMpDQo5MDM0ODYoNjIgbW9kIDI1Nik6IE1BUFdSSVRFIDB4 M2NhOGQgdGhydSAweDNmZmZmCSgweDM1NzMgYnl0ZXMpDQo5MDM0ODcoNjMg bW9kIDI1Nik6IFdSSVRFCTB4NjQzMCB0aHJ1IDB4ZDg2MAkoMHg3NDMxIGJ5 dGVzKQ0KOTAzNDg4KDY0IG1vZCAyNTYpOiBUUlVOQ0FURSBET1dOCWZyb20g MHg0MDAwMCB0byAweDk0YjkNCjkwMzQ4OSg2NSBtb2QgMjU2KTogTUFQUkVB RAkweGI2YiB0aHJ1IDB4OTRiOAkoMHg4OTRlIGJ5dGVzKQ0KOTAzNDkwKDY2 IG1vZCAyNTYpOiBSRUFECTB4OTQzMSB0aHJ1IDB4OTRiOAkoMHg4OCBieXRl cykNCjkwMzQ5MSg2NyBtb2QgMjU2KTogVFJVTkNBVEUgVVAJZnJvbSAweDk0 YjkgdG8gMHgxYzFiOA0KOTAzNDkyKDY4IG1vZCAyNTYpOiBSRUFECTB4MTc5 MjggdGhydSAweDFjMWI3CSgweDQ4OTAgYnl0ZXMpDQo5MDM0OTMoNjkgbW9k IDI1Nik6IFdSSVRFCTB4NDI4NiB0aHJ1IDB4MTQxYWUJKDB4ZmYyOSBieXRl cykNCjkwMzQ5NCg3MCBtb2QgMjU2KTogV1JJVEUJMHgxODA3MyB0aHJ1IDB4 Mjc1ZWQJKDB4ZjU3YiBieXRlcykgRVhURU5EDQo5MDM0OTUoNzEgbW9kIDI1 Nik6IFdSSVRFCTB4ZWM2NSB0aHJ1IDB4MWQ4NGYJKDB4ZWJlYiBieXRlcykN CjkwMzQ5Nig3MiBtb2QgMjU2KTogTUFQV1JJVEUgMHgyYWI1MiB0aHJ1IDB4 MzNjZDUJKDB4OTE4NCBieXRlcykNCjkwMzQ5Nyg3MyBtb2QgMjU2KTogTUFQ V1JJVEUgMHgxOGM3NiB0aHJ1IDB4MjA4MmUJKDB4N2JiOSBieXRlcykNCjkw MzQ5OCg3NCBtb2QgMjU2KTogUkVBRAkweDE1ZGQxIHRocnUgMHgyMTAwNwko MHhiMjM3IGJ5dGVzKQ0KOTAzNDk5KDc1IG1vZCAyNTYpOiBXUklURQkweDM4 MGNkIHRocnUgMHgzZmZmZgkoMHg3ZjMzIGJ5dGVzKSBIT0xFDQo5MDM1MDAo NzYgbW9kIDI1Nik6IE1BUFJFQUQJMHg2MWQ2IHRocnUgMHhlZTUyCSgweDhj N2QgYnl0ZXMpDQo5MDM1MDEoNzcgbW9kIDI1Nik6IE1BUFJFQUQJMHhkMTE3 IHRocnUgMHhmMTMyCSgweDIwMWMgYnl0ZXMpDQo5MDM1MDIoNzggbW9kIDI1 Nik6IFdSSVRFCTB4MjYxM2UgdGhydSAweDJhMDY0CSgweDNmMjcgYnl0ZXMp DQo5MDM1MDMoNzkgbW9kIDI1Nik6IE1BUFJFQUQJMHgxZjViOSB0aHJ1IDB4 MmQ0NDEJKDB4ZGU4OSBieXRlcykNCjkwMzUwNCg4MCBtb2QgMjU2KTogV1JJ VEUJMHgxYzIxOSB0aHJ1IDB4MWY2Y2MJKDB4MzRiNCBieXRlcykNCjkwMzUw NSg4MSBtb2QgMjU2KTogUkVBRAkweDIzMjVjIHRocnUgMHgzMmNiMwkoMHhm YTU4IGJ5dGVzKQ0KOTAzNTA2KDgyIG1vZCAyNTYpOiBUUlVOQ0FURSBET1dO CWZyb20gMHg0MDAwMCB0byAweDM2OTY2DQo5MDM1MDcoODMgbW9kIDI1Nik6 IE1BUFdSSVRFIDB4MjZlYjMgdGhydSAweDI4OTdhCSgweDFhYzggYnl0ZXMp DQo5MDM1MDgoODQgbW9kIDI1Nik6IFdSSVRFCTB4MTRkOWQgdGhydSAweDE4 ODhhCSgweDNhZWUgYnl0ZXMpDQo5MDM1MDkoODUgbW9kIDI1Nik6IE1BUFdS SVRFIDB4MzAyODQgdGhydSAweDM3YzY1CSgweDc5ZTIgYnl0ZXMpDQo5MDM1 MTAoODYgbW9kIDI1Nik6IFRSVU5DQVRFIERPV04JZnJvbSAweDM3YzY2IHRv IDB4MjlmZDINCjkwMzUxMSg4NyBtb2QgMjU2KTogV1JJVEUJMHhkM2I4IHRo cnUgMHgxODFiMQkoMHhhZGZhIGJ5dGVzKQ0KOTAzNTEyKDg4IG1vZCAyNTYp OiBNQVBSRUFECTB4NDg2ZCB0aHJ1IDB4MTNjZjkJKDB4ZjQ4ZCBieXRlcykN CjkwMzUxMyg4OSBtb2QgMjU2KTogTUFQV1JJVEUgMHg2MDZiIHRocnUgMHg4 NzI0CSgweDI2YmEgYnl0ZXMpDQo5MDM1MTQoOTAgbW9kIDI1Nik6IE1BUFdS SVRFIDB4ODNlMSB0aHJ1IDB4MTc3MTUJKDB4ZjMzNSBieXRlcykNCjkwMzUx NSg5MSBtb2QgMjU2KTogTUFQV1JJVEUgMHgzOWNlMyB0aHJ1IDB4M2M1NzQJ KDB4Mjg5MiBieXRlcykNCjkwMzUxNig5MiBtb2QgMjU2KTogVFJVTkNBVEUg RE9XTglmcm9tIDB4M2M1NzUgdG8gMHg4MzEzDQo5MDM1MTcoOTMgbW9kIDI1 Nik6IFRSVU5DQVRFIERPV04JZnJvbSAweDgzMTMgdG8gMHgyY2ZlDQo5MDM1 MTgoOTQgbW9kIDI1Nik6IE1BUFJFQUQJMHgyNjMwIHRocnUgMHgyY2ZkCSgw eDZjZSBieXRlcykNCjkwMzUxOSg5NSBtb2QgMjU2KTogVFJVTkNBVEUgVVAJ ZnJvbSAweDJjZmUgdG8gMHhhMzczDQo5MDM1MjAoOTYgbW9kIDI1Nik6IFJF QUQJMHg1NjFlIHRocnUgMHg1Nzk0CSgweDE3NyBieXRlcykNCjkwMzUyMSg5 NyBtb2QgMjU2KTogUkVBRAkweDYxMDcgdGhydSAweGEzNzIJKDB4NDI2YyBi eXRlcykNCjkwMzUyMig5OCBtb2QgMjU2KTogVFJVTkNBVEUgVVAJZnJvbSAw eGEzNzMgdG8gMHgzOTdhOA0KOTAzNTIzKDk5IG1vZCAyNTYpOiBUUlVOQ0FU RSBVUAlmcm9tIDB4Mzk3YTggdG8gMHgzY2YyZg0KOTAzNTI0KDEwMCBtb2Qg MjU2KTogTUFQV1JJVEUgMHgyOGIzMCB0aHJ1IDB4MjhmMTQJKDB4M2U1IGJ5 dGVzKQ0KOTAzNTI1KDEwMSBtb2QgMjU2KTogTUFQUkVBRAkweGY4NDEgdGhy dSAweDFlZTBiCSgweGY1Y2IgYnl0ZXMpDQo5MDM1MjYoMTAyIG1vZCAyNTYp OiBNQVBSRUFECTB4MmYwMmUgdGhydSAweDM3NGVmCSgweDg0YzIgYnl0ZXMp DQo5MDM1MjcoMTAzIG1vZCAyNTYpOiBNQVBSRUFECTB4MTE0ZDAgdGhydSAw eDFkNzZiCSgweGMyOWMgYnl0ZXMpDQo5MDM1MjgoMTA0IG1vZCAyNTYpOiBS RUFECTB4OGJmMyB0aHJ1IDB4ZDYxMwkoMHg0YTIxIGJ5dGVzKQ0KOTAzNTI5 KDEwNSBtb2QgMjU2KTogUkVBRAkweDE0ODkyIHRocnUgMHgxOTNmYgkoMHg0 YjZhIGJ5dGVzKQ0KOTAzNTMwKDEwNiBtb2QgMjU2KTogTUFQUkVBRAkweDI1 NjU1IHRocnUgMHgyYWI4NgkoMHg1NTMyIGJ5dGVzKQ0KOTAzNTMxKDEwNyBt b2QgMjU2KTogTUFQUkVBRAkweDJiMmQ1IHRocnUgMHgyZTFhOQkoMHgyZWQ1 IGJ5dGVzKQ0KOTAzNTMyKDEwOCBtb2QgMjU2KTogUkVBRAkweDEwMTljIHRo cnUgMHgxMzAyMgkoMHgyZTg3IGJ5dGVzKQ0KOTAzNTMzKDEwOSBtb2QgMjU2 KTogTUFQUkVBRAkweDM4YWE5IHRocnUgMHgzY2YyZQkoMHg0NDg2IGJ5dGVz KQ0KOTAzNTM0KDExMCBtb2QgMjU2KTogTUFQUkVBRAkweDM4MjMwIHRocnUg MHgzY2YyZQkoMHg0Y2ZmIGJ5dGVzKQ0KOTAzNTM1KDExMSBtb2QgMjU2KTog TUFQUkVBRAkweDM2NGMyIHRocnUgMHgzY2YyZQkoMHg2YTZkIGJ5dGVzKQ0K OTAzNTM2KDExMiBtb2QgMjU2KTogUkVBRAkweDMyYTAyIHRocnUgMHgzYTU4 OQkoMHg3Yjg4IGJ5dGVzKQ0KOTAzNTM3KDExMyBtb2QgMjU2KTogUkVBRAkw eDJmYTYyIHRocnUgMHgzYjY1YQkoMHhiYmY5IGJ5dGVzKQ0KOTAzNTM4KDEx NCBtb2QgMjU2KTogUkVBRAkweDM2N2ZiIHRocnUgMHgzYTUyZAkoMHgzZDMz IGJ5dGVzKQ0KOTAzNTM5KDExNSBtb2QgMjU2KTogTUFQUkVBRAkweDM3NWVk IHRocnUgMHgzY2YyZQkoMHg1OTQyIGJ5dGVzKQ0KOTAzNTQwKDExNiBtb2Qg MjU2KTogUkVBRAkweDIxYzdiIHRocnUgMHgyNGZlNAkoMHgzMzZhIGJ5dGVz KQ0KOTAzNTQxKDExNyBtb2QgMjU2KTogUkVBRAkweDJmYzdhIHRocnUgMHgz Mzk2YQkoMHgzY2YxIGJ5dGVzKQ0KOTAzNTQyKDExOCBtb2QgMjU2KTogTUFQ UkVBRAkweDM3NzA4IHRocnUgMHgzY2YyZQkoMHg1ODI3IGJ5dGVzKQ0KOTAz NTQzKDExOSBtb2QgMjU2KTogV1JJVEUJMHgyYjI4NCB0aHJ1IDB4MzJlZjIJ KDB4N2M2ZiBieXRlcykNCjkwMzU0NCgxMjAgbW9kIDI1Nik6IE1BUFJFQUQJ MHhiMzY0IHRocnUgMHgxMGZjZAkoMHg1YzZhIGJ5dGVzKQ0KOTAzNTQ1KDEy MSBtb2QgMjU2KTogVFJVTkNBVEUgVVAJZnJvbSAweDNjZjJmIHRvIDB4M2Rl OWINCjkwMzU0NigxMjIgbW9kIDI1Nik6IE1BUFdSSVRFIDB4MWYzMTkgdGhy dSAweDI2NWFhCSgweDcyOTIgYnl0ZXMpDQo5MDM1NDcoMTIzIG1vZCAyNTYp OiBSRUFECTB4MjcwMTUgdGhydSAweDMzNzIxCSgweGM3MGQgYnl0ZXMpDQo5 MDM1NDgoMTI0IG1vZCAyNTYpOiBNQVBSRUFECTB4NzBkNSB0aHJ1IDB4MTE2 ZjAJKDB4YTYxYyBieXRlcykNCjkwMzU0OSgxMjUgbW9kIDI1Nik6IE1BUFdS SVRFIDB4MzA5ZGEgdGhydSAweDMxOTQ4CSgweGY2ZiBieXRlcykNCjkwMzU1 MCgxMjYgbW9kIDI1Nik6IFRSVU5DQVRFIERPV04JZnJvbSAweDNkZTliIHRv IDB4MTk4MzUNCjkwMzU1MSgxMjcgbW9kIDI1Nik6IFJFQUQJMHg5Y2IzIHRo cnUgMHgxOGVjOAkoMHhmMjE2IGJ5dGVzKQ0KOTAzNTUyKDEyOCBtb2QgMjU2 KTogTUFQUkVBRAkweDEzNzJmIHRocnUgMHgxNzE0NwkoMHgzYTE5IGJ5dGVz KQ0KOTAzNTUzKDEyOSBtb2QgMjU2KTogV1JJVEUJMHgxZWY2ZCB0aHJ1IDB4 MWZiMzUJKDB4YmM5IGJ5dGVzKSBIT0xFDQo5MDM1NTQoMTMwIG1vZCAyNTYp OiBXUklURQkweDNiOTRlIHRocnUgMHgzZTI4YwkoMHgyOTNmIGJ5dGVzKSBI T0xFDQo5MDM1NTUoMTMxIG1vZCAyNTYpOiBNQVBSRUFECTB4MzY0ODAgdGhy dSAweDM5YjIxCSgweDM2YTIgYnl0ZXMpDQo5MDM1NTYoMTMyIG1vZCAyNTYp OiBSRUFECTB4MmE1YWIgdGhydSAweDM1ZDA1CSgweGI3NWIgYnl0ZXMpDQo5 MDM1NTcoMTMzIG1vZCAyNTYpOiBUUlVOQ0FURSBET1dOCWZyb20gMHgzZTI4 ZCB0byAweDI0MTI1DQo5MDM1NTgoMTM0IG1vZCAyNTYpOiBXUklURQkweDMy MWMzIHRocnUgMHgzYzVmMwkoMHhhNDMxIGJ5dGVzKSBIT0xFDQo5MDM1NTko MTM1IG1vZCAyNTYpOiBSRUFECTB4Mjg1MGYgdGhydSAweDI5MTFhCSgweGMw YyBieXRlcykNCjkwMzU2MCgxMzYgbW9kIDI1Nik6IFRSVU5DQVRFIFVQCWZy b20gMHgzYzVmNCB0byAweDNkNDE3DQo5MDM1NjEoMTM3IG1vZCAyNTYpOiBS RUFECTB4MzhlYzUgdGhydSAweDNjZDFjCSgweDNlNTggYnl0ZXMpDQo5MDM1 NjIoMTM4IG1vZCAyNTYpOiBNQVBXUklURSAweDJhMThiIHRocnUgMHgzOTkx NQkoMHhmNzhiIGJ5dGVzKQ0KOTAzNTYzKDEzOSBtb2QgMjU2KTogTUFQUkVB RAkweDJlOWI5IHRocnUgMHgzNmNkNAkoMHg4MzFjIGJ5dGVzKQ0KOTAzNTY0 KDE0MCBtb2QgMjU2KTogTUFQUkVBRAkweDMxZjJkIHRocnUgMHgzMjZmZgko MHg3ZDMgYnl0ZXMpDQo5MDM1NjUoMTQxIG1vZCAyNTYpOiBNQVBXUklURSAw eDMwNjhiIHRocnUgMHgzNDUwYwkoMHgzZTgyIGJ5dGVzKQ0KOTAzNTY2KDE0 MiBtb2QgMjU2KTogTUFQV1JJVEUgMHg4NmRiIHRocnUgMHgxNzU5NAkoMHhl ZWJhIGJ5dGVzKQ0KOTAzNTY3KDE0MyBtb2QgMjU2KTogTUFQV1JJVEUgMHgx M2MxNyB0aHJ1IDB4MTVjZGMJKDB4MjBjNiBieXRlcykNCjkwMzU2OCgxNDQg bW9kIDI1Nik6IE1BUFJFQUQJMHgxMTcxYyB0aHJ1IDB4MTdiMmIJKDB4NjQx MCBieXRlcykNCjkwMzU2OSgxNDUgbW9kIDI1Nik6IFdSSVRFCTB4MzdhOTcg dGhydSAweDNhYjU5CSgweDMwYzMgYnl0ZXMpDQo5MDM1NzAoMTQ2IG1vZCAy NTYpOiBSRUFECTB4Mzc0YWYgdGhydSAweDNjNjZmCSgweDUxYzEgYnl0ZXMp DQo5MDM1NzEoMTQ3IG1vZCAyNTYpOiBUUlVOQ0FURSBET1dOCWZyb20gMHgz ZDQxNyB0byAweGU2YmINCjkwMzU3MigxNDggbW9kIDI1Nik6IFJFQUQJMHg5 ZmM5IHRocnUgMHhjMTQ3CSgweDIxN2YgYnl0ZXMpDQo5MDM1NzMoMTQ5IG1v ZCAyNTYpOiBXUklURQkweDM5NjkwIHRocnUgMHgzZmZmZgkoMHg2OTcwIGJ5 dGVzKSBIT0xFDQo5MDM1NzQoMTUwIG1vZCAyNTYpOiBNQVBSRUFECTB4OWZh NyB0aHJ1IDB4MTVmMGUJKDB4YmY2OCBieXRlcykNCjkwMzU3NSgxNTEgbW9k IDI1Nik6IFRSVU5DQVRFIERPV04JZnJvbSAweDQwMDAwIHRvIDB4MjRiOGYN CjkwMzU3NigxNTIgbW9kIDI1Nik6IE1BUFJFQUQJMHg3N2Q5IHRocnUgMHg3 ZDQyCSgweDU2YSBieXRlcykNCjkwMzU3NygxNTMgbW9kIDI1Nik6IFJFQUQJ MHg4MzU2IHRocnUgMHgxNTI0YwkoMHhjZWY3IGJ5dGVzKQ0KOTAzNTc4KDE1 NCBtb2QgMjU2KTogVFJVTkNBVEUgVVAJZnJvbSAweDI0YjhmIHRvIDB4MjZh OWYNCjkwMzU3OSgxNTUgbW9kIDI1Nik6IFdSSVRFCTB4MThmOTkgdGhydSAw eDI1MjZjCSgweGMyZDQgYnl0ZXMpDQo5MDM1ODAoMTU2IG1vZCAyNTYpOiBU UlVOQ0FURSBET1dOCWZyb20gMHgyNmE5ZiB0byAweDE0MDA4DQo5MDM1ODEo MTU3IG1vZCAyNTYpOiBXUklURQkweGQzNTQgdGhydSAweGY1YjcJKDB4MjI2 NCBieXRlcykNCjkwMzU4MigxNTggbW9kIDI1Nik6IFRSVU5DQVRFIFVQCWZy b20gMHgxNDAwOCB0byAweDMzNzI4DQo5MDM1ODMoMTU5IG1vZCAyNTYpOiBN QVBXUklURSAweDFiNjBmIHRocnUgMHgyYWNkMAkoMHhmNmMyIGJ5dGVzKQ0K OTAzNTg0KDE2MCBtb2QgMjU2KTogTUFQUkVBRAkweDI4Y2Q4IHRocnUgMHgy YzkwZQkoMHgzYzM3IGJ5dGVzKQ0KOTAzNTg1KDE2MSBtb2QgMjU2KTogTUFQ UkVBRAkweDI4MWQ4IHRocnUgMHgyZTU3NQkoMHg2MzllIGJ5dGVzKQ0KOTAz NTg2KDE2MiBtb2QgMjU2KTogUkVBRAkweDZhZTMgdGhydSAweGMyNTEJKDB4 NTc2ZiBieXRlcykNCjkwMzU4NygxNjMgbW9kIDI1Nik6IFRSVU5DQVRFIERP V04JZnJvbSAweDMzNzI4IHRvIDB4MmRhZGYNCjkwMzU4OCgxNjQgbW9kIDI1 Nik6IE1BUFJFQUQJMHgyZGE5NyB0aHJ1IDB4MmRhZGUJKDB4NDggYnl0ZXMp DQo5MDM1ODkoMTY1IG1vZCAyNTYpOiBXUklURQkweDM5MjI2IHRocnUgMHgz ZmZmZgkoMHg2ZGRhIGJ5dGVzKSBIT0xFDQo5MDM1OTAoMTY2IG1vZCAyNTYp OiBNQVBXUklURSAweDMwNTYxIHRocnUgMHgzNTAwOQkoMHg0YWE5IGJ5dGVz KQ0KOTAzNTkxKDE2NyBtb2QgMjU2KTogTUFQUkVBRAkweDM3NjQ3IHRocnUg MHgzZmZmZgkoMHg4OWI5IGJ5dGVzKQ0KOTAzNTkyKDE2OCBtb2QgMjU2KTog TUFQV1JJVEUgMHgxODk3MiB0aHJ1IDB4Mjg3YWYJKDB4ZmUzZSBieXRlcykN CjkwMzU5MygxNjkgbW9kIDI1Nik6IFdSSVRFCTB4MzhiOTIgdGhydSAweDNm ZmZmCSgweDc0NmUgYnl0ZXMpDQo5MDM1OTQoMTcwIG1vZCAyNTYpOiBNQVBS RUFECTB4NWI1IHRocnUgMHhmY2M1CSgweGY3MTEgYnl0ZXMpCSoqKlJSUlIq KioNCjkwMzU5NSgxNzEgbW9kIDI1Nik6IFdSSVRFCTB4M2U3NzIgdGhydSAw eDNmZmZmCSgweDE4OGUgYnl0ZXMpDQo5MDM1OTYoMTcyIG1vZCAyNTYpOiBN QVBXUklURSAweDEwZWRmIHRocnUgMHgxNDgzNgkoMHgzOTU4IGJ5dGVzKQ0K OTAzNTk3KDE3MyBtb2QgMjU2KTogTUFQUkVBRAkweDI5M2ZlIHRocnUgMHgy ZmY3MQkoMHg2Yjc0IGJ5dGVzKQ0KOTAzNTk4KDE3NCBtb2QgMjU2KTogVFJV TkNBVEUgRE9XTglmcm9tIDB4NDAwMDAgdG8gMHgxMWE4OQ0KOTAzNTk5KDE3 NSBtb2QgMjU2KTogUkVBRAkweDNkYzEgdGhydSAweDkzZmIJKDB4NTYzYiBi eXRlcykNCjkwMzYwMCgxNzYgbW9kIDI1Nik6IFRSVU5DQVRFIFVQCWZyb20g MHgxMWE4OSB0byAweDJiMTcwDQo5MDM2MDEoMTc3IG1vZCAyNTYpOiBNQVBX UklURSAweDEzNzkgdGhydSAweDdkMjcJKDB4NjlhZiBieXRlcykNCjkwMzYw MigxNzggbW9kIDI1Nik6IFRSVU5DQVRFIERPV04JZnJvbSAweDJiMTcwIHRv IDB4YWYwMQ0KOTAzNjAzKDE3OSBtb2QgMjU2KTogVFJVTkNBVEUgVVAJZnJv bSAweGFmMDEgdG8gMHgxYmZjOA0KOTAzNjA0KDE4MCBtb2QgMjU2KTogVFJV TkNBVEUgRE9XTglmcm9tIDB4MWJmYzggdG8gMHgxNWQ0Zg0KOTAzNjA1KDE4 MSBtb2QgMjU2KTogTUFQUkVBRAkweDExNDEwIHRocnUgMHgxNWQ0ZQkoMHg0 OTNmIGJ5dGVzKQ0KOTAzNjA2KDE4MiBtb2QgMjU2KTogTUFQUkVBRAkweGVk OWYgdGhydSAweDE1ZDRlCSgweDZmYjAgYnl0ZXMpDQo5MDM2MDcoMTgzIG1v ZCAyNTYpOiBNQVBSRUFECTB4MTA3MDMgdGhydSAweDE1ZDRlCSgweDU2NGMg Ynl0ZXMpDQo5MDM2MDgoMTg0IG1vZCAyNTYpOiBNQVBXUklURSAweDE0MjBl IHRocnUgMHgxZjc0YwkoMHhiNTNmIGJ5dGVzKQ0KOTAzNjA5KDE4NSBtb2Qg MjU2KTogTUFQV1JJVEUgMHgxMTBhMiB0aHJ1IDB4MWM4ZjgJKDB4Yjg1NyBi eXRlcykNCjkwMzYxMCgxODYgbW9kIDI1Nik6IE1BUFdSSVRFIDB4MmNkM2Mg dGhydSAweDM3M2YzCSgweGE2YjggYnl0ZXMpDQo5MDM2MTEoMTg3IG1vZCAy NTYpOiBUUlVOQ0FURSBET1dOCWZyb20gMHgzNzNmNCB0byAweDI2NGFkDQo5 MDM2MTIoMTg4IG1vZCAyNTYpOiBUUlVOQ0FURSBET1dOCWZyb20gMHgyNjRh ZCB0byAweDc4MDYNCjkwMzYxMygxODkgbW9kIDI1Nik6IE1BUFdSSVRFIDB4 MjNmNDQgdGhydSAweDI0ODk1CSgweDk1MiBieXRlcykNCjkwMzYxNCgxOTAg bW9kIDI1Nik6IE1BUFdSSVRFIDB4NzIyIHRocnUgMHhkMDJmCSgweGM5MGUg Ynl0ZXMpCSoqKioqKldXV1cNCjkwMzYxNSgxOTEgbW9kIDI1Nik6IFJFQUQJ MHgxNGUxYiB0aHJ1IDB4MTVmYmYJKDB4MTFhNSBieXRlcykNCjkwMzYxNigx OTIgbW9kIDI1Nik6IFJFQUQJMHgxMmVjOCB0aHJ1IDB4MWRmZWEJKDB4YjEy MyBieXRlcykNCjkwMzYxNygxOTMgbW9kIDI1Nik6IFdSSVRFCTB4MzcyMjkg dGhydSAweDM5YjRlCSgweDI5MjYgYnl0ZXMpIEhPTEUNCjkwMzYxOCgxOTQg bW9kIDI1Nik6IFJFQUQJMHgxZDA3MCB0aHJ1IDB4MjA3MzcJKDB4MzZjOCBi eXRlcykNCjkwMzYxOSgxOTUgbW9kIDI1Nik6IE1BUFdSSVRFIDB4MjU1OGEg dGhydSAweDI5YTQyCSgweDQ0YjkgYnl0ZXMpDQo5MDM2MjAoMTk2IG1vZCAy NTYpOiBUUlVOQ0FURSBET1dOCWZyb20gMHgzOWI0ZiB0byAweDVkMDcNCjkw MzYyMSgxOTcgbW9kIDI1Nik6IE1BUFJFQUQJMHgyYmY5IHRocnUgMHg1ZDA2 CSgweDMxMGUgYnl0ZXMpDQo5MDM2MjIoMTk4IG1vZCAyNTYpOiBNQVBSRUFE CTB4MTBmMiB0aHJ1IDB4NWQwNgkoMHg0YzE1IGJ5dGVzKQ0KOTAzNjIzKDE5 OSBtb2QgMjU2KTogTUFQV1JJVEUgMHgyMTU3NCB0aHJ1IDB4MjQ1MWYJKDB4 MmZhYyBieXRlcykNCjkwMzYyNCgyMDAgbW9kIDI1Nik6IE1BUFdSSVRFIDB4 MmI3YTYgdGhydSAweDJmYjdjCSgweDQzZDcgYnl0ZXMpDQo5MDM2MjUoMjAx IG1vZCAyNTYpOiBXUklURQkweDMwNWNmIHRocnUgMHgzMTcwNwkoMHgxMTM5 IGJ5dGVzKSBIT0xFDQo5MDM2MjYoMjAyIG1vZCAyNTYpOiBNQVBSRUFECTB4 Mjg1MDAgdGhydSAweDMwOWYwCSgweDg0ZjEgYnl0ZXMpDQo5MDM2MjcoMjAz IG1vZCAyNTYpOiBNQVBSRUFECTB4MWQ2ZDIgdGhydSAweDI1Yjc4CSgweDg0 YTcgYnl0ZXMpDQo5MDM2MjgoMjA0IG1vZCAyNTYpOiBSRUFECTB4MjFkYjAg dGhydSAweDMwYTRlCSgweGVjOWYgYnl0ZXMpDQo5MDM2MjkoMjA1IG1vZCAy NTYpOiBUUlVOQ0FURSBET1dOCWZyb20gMHgzMTcwOCB0byAweDJjMzZkDQo5 MDM2MzAoMjA2IG1vZCAyNTYpOiBNQVBXUklURSAweDE0NWFhIHRocnUgMHgx OTYzOAkoMHg1MDhmIGJ5dGVzKQ0KOTAzNjMxKDIwNyBtb2QgMjU2KTogTUFQ UkVBRAkweDFmNjhlIHRocnUgMHgyYTZjNgkoMHhiMDM5IGJ5dGVzKQ0KOTAz NjMyKDIwOCBtb2QgMjU2KTogVFJVTkNBVEUgVVAJZnJvbSAweDJjMzZkIHRv IDB4MzdiMzINCjkwMzYzMygyMDkgbW9kIDI1Nik6IE1BUFJFQUQJMHgyMzVj MiB0aHJ1IDB4MzBmZDYJKDB4ZGExNSBieXRlcykNCjkwMzYzNCgyMTAgbW9k IDI1Nik6IFdSSVRFCTB4OTczOCB0aHJ1IDB4MTkzMDYJKDB4ZmJjZiBieXRl cykNCjkwMzYzNSgyMTEgbW9kIDI1Nik6IE1BUFdSSVRFIDB4MzU2YTMgdGhy dSAweDNmZmZmCSgweGE5NWQgYnl0ZXMpDQo5MDM2MzYoMjEyIG1vZCAyNTYp OiBUUlVOQ0FURSBET1dOCWZyb20gMHg0MDAwMCB0byAweDhiMzENCjkwMzYz NygyMTMgbW9kIDI1Nik6IFdSSVRFCTB4MzNkOTEgdGhydSAweDNmZDVhCSgw eGJmY2EgYnl0ZXMpIEhPTEUNCjkwMzYzOCgyMTQgbW9kIDI1Nik6IFJFQUQJ MHgyZTIyMiB0aHJ1IDB4M2NlMjEJKDB4ZWMwMCBieXRlcykNCjkwMzYzOSgy MTUgbW9kIDI1Nik6IFRSVU5DQVRFIERPV04JZnJvbSAweDNmZDViIHRvIDB4 MmY2MDINCjkwMzY0MCgyMTYgbW9kIDI1Nik6IE1BUFJFQUQJMHgxMjg0NCB0 aHJ1IDB4MTk0MTcJKDB4NmJkNCBieXRlcykNCjkwMzY0MSgyMTcgbW9kIDI1 Nik6IFRSVU5DQVRFIERPV04JZnJvbSAweDJmNjAyIHRvIDB4Mjc3ZGYNCjkw MzY0MigyMTggbW9kIDI1Nik6IE1BUFdSSVRFIDB4MWU3NDAgdGhydSAweDIy OGFkCSgweDQxNmUgYnl0ZXMpDQo5MDM2NDMoMjE5IG1vZCAyNTYpOiBSRUFE CTB4MTA4MCB0aHJ1IDB4NDc3NwkoMHgzNmY4IGJ5dGVzKQ0KOTAzNjQ0KDIy MCBtb2QgMjU2KTogTUFQV1JJVEUgMHgxMzgyIHRocnUgMHgzNDMxCSgweDIw YjAgYnl0ZXMpDQo5MDM2NDUoMjIxIG1vZCAyNTYpOiBXUklURQkweDFjMDg2 IHRocnUgMHgyMjNkYgkoMHg2MzU2IGJ5dGVzKQ0KOTAzNjQ2KDIyMiBtb2Qg MjU2KTogVFJVTkNBVEUgVVAJZnJvbSAweDI3N2RmIHRvIDB4MzM5ZmUNCjkw MzY0NygyMjMgbW9kIDI1Nik6IE1BUFdSSVRFIDB4MWJkNTIgdGhydSAweDI1 MzQzCSgweDk1ZjIgYnl0ZXMpDQo5MDM2NDgoMjI0IG1vZCAyNTYpOiBSRUFE CTB4Zjc4OSB0aHJ1IDB4MTBkNGEJKDB4MTVjMiBieXRlcykNCjkwMzY0OSgy MjUgbW9kIDI1Nik6IFJFQUQJMHgxZGExYiB0aHJ1IDB4MjZiNmYJKDB4OTE1 NSBieXRlcykNCjkwMzY1MCgyMjYgbW9kIDI1Nik6IE1BUFdSSVRFIDB4MmRj YzMgdGhydSAweDM4YjViCSgweGFlOTkgYnl0ZXMpDQo5MDM2NTEoMjI3IG1v ZCAyNTYpOiBNQVBXUklURSAweGYzZTEgdGhydSAweDFkM2M2CSgweGRmZTYg Ynl0ZXMpDQo5MDM2NTIoMjI4IG1vZCAyNTYpOiBUUlVOQ0FURSBET1dOCWZy b20gMHgzOGI1YyB0byAweDJkZTAzDQo5MDM2NTMoMjI5IG1vZCAyNTYpOiBN QVBXUklURSAweDFkYzJmIHRocnUgMHgyNzIxZgkoMHg5NWYxIGJ5dGVzKQ0K OTAzNjU0KDIzMCBtb2QgMjU2KTogV1JJVEUJMHgzZDgyZCB0aHJ1IDB4M2Yz NzMJKDB4MWI0NyBieXRlcykgSE9MRQ0KOTAzNjU1KDIzMSBtb2QgMjU2KTog UkVBRAkweGU4YTYgdGhydSAweDE1OGY4CSgweDcwNTMgYnl0ZXMpDQo5MDM2 NTYoMjMyIG1vZCAyNTYpOiBNQVBXUklURSAweDM1Y2ZlIHRocnUgMHgzOTVi YwkoMHgzOGJmIGJ5dGVzKQ0KOTAzNjU3KDIzMyBtb2QgMjU2KTogTUFQUkVB RAkweDY2MDQgdGhydSAweDEyMjljCSgweGJjOTkgYnl0ZXMpDQo5MDM2NTgo MjM0IG1vZCAyNTYpOiBNQVBSRUFECTB4Mzc2Y2UgdGhydSAweDNmMzczCSgw eDdjYTYgYnl0ZXMpDQo5MDM2NTkoMjM1IG1vZCAyNTYpOiBXUklURQkweDJl YjU4IHRocnUgMHgzOTRlNAkoMHhhOThkIGJ5dGVzKQ0KOTAzNjYwKDIzNiBt b2QgMjU2KTogV1JJVEUJMHgxZTM4YyB0aHJ1IDB4MjdmOWUJKDB4OWMxMyBi eXRlcykNCjkwMzY2MSgyMzcgbW9kIDI1Nik6IE1BUFdSSVRFIDB4MWM1Mzgg dGhydSAweDIzMGUyCSgweDZiYWIgYnl0ZXMpDQo5MDM2NjIoMjM4IG1vZCAy NTYpOiBXUklURQkweDMxYThkIHRocnUgMHgzZTAyMAkoMHhjNTk0IGJ5dGVz KQ0KOTAzNjYzKDIzOSBtb2QgMjU2KTogV1JJVEUJMHgyNjk5ZCB0aHJ1IDB4 MzYwZDYJKDB4ZjczYSBieXRlcykNCjkwMzY2NCgyNDAgbW9kIDI1Nik6IE1B UFJFQUQJMHgzNjk4MCB0aHJ1IDB4M2RlNWEJKDB4NzRkYiBieXRlcykNCjkw MzY2NSgyNDEgbW9kIDI1Nik6IE1BUFJFQUQJMHhkN2YwIHRocnUgMHhkZDI0 CSgweDUzNSBieXRlcykNCjkwMzY2NigyNDIgbW9kIDI1Nik6IFRSVU5DQVRF IERPV04JZnJvbSAweDNmMzc0IHRvIDB4M2ZkNw0KOTAzNjY3KDI0MyBtb2Qg MjU2KTogV1JJVEUJMHg5MzEwIHRocnUgMHgxNWI5NwkoMHhjODg4IGJ5dGVz KSBIT0xFDQo5MDM2NjgoMjQ0IG1vZCAyNTYpOiBSRUFECTB4YTEzZiB0aHJ1 IDB4MTQwNTYJKDB4OWYxOCBieXRlcykNCjkwMzY2OSgyNDUgbW9kIDI1Nik6 IE1BUFdSSVRFIDB4MWFhNzcgdGhydSAweDI2Y2JmCSgweGMyNDkgYnl0ZXMp DQo5MDM2NzAoMjQ2IG1vZCAyNTYpOiBNQVBXUklURSAweDJjYWZkIHRocnUg MHgzNmI2MwkoMHhhMDY3IGJ5dGVzKQ0KOTAzNjcxKDI0NyBtb2QgMjU2KTog UkVBRAkweDIxZTQzIHRocnUgMHgyNTE2OAkoMHgzMzI2IGJ5dGVzKQ0KOTAz NjcyKDI0OCBtb2QgMjU2KTogTUFQUkVBRAkweDE0NTlkIHRocnUgMHgyMDY2 NQkoMHhjMGM5IGJ5dGVzKQ0KOTAzNjczKDI0OSBtb2QgMjU2KTogUkVBRAkw eDEwZDA2IHRocnUgMHgxNzM1YQkoMHg2NjU1IGJ5dGVzKQ0KOTAzNjc0KDI1 MCBtb2QgMjU2KTogUkVBRAkweDFkN2QzIHRocnUgMHgyYWE3YgkoMHhkMmE5 IGJ5dGVzKQ0KOTAzNjc1KDI1MSBtb2QgMjU2KTogV1JJVEUJMHgzMmEzIHRo cnUgMHhhMjA3CSgweDZmNjUgYnl0ZXMpDQo5MDM2NzYoMjUyIG1vZCAyNTYp OiBNQVBSRUFECTB4NDU0OSB0aHJ1IDB4MTMzMjYJKDB4ZWRkZSBieXRlcykN CjkwMzY3NygyNTMgbW9kIDI1Nik6IE1BUFJFQUQJMHgxY2U3NyB0aHJ1IDB4 MWQ2YmIJKDB4ODQ1IGJ5dGVzKQ0KOTAzNjc4KDI1NCBtb2QgMjU2KTogTUFQ V1JJVEUgMHgzMWJhMSB0aHJ1IDB4M2RhYWYJKDB4YmYwZiBieXRlcykNCjkw MzY3OSgyNTUgbW9kIDI1Nik6IFRSVU5DQVRFIERPV04JZnJvbSAweDNkYWIw IHRvIDB4MTljOTgNCjkwMzY4MCgwIG1vZCAyNTYpOiBNQVBXUklURSAweDJj NmMzIHRocnUgMHgzMzU3OQkoMHg2ZWI3IGJ5dGVzKQ0KOTAzNjgxKDEgbW9k IDI1Nik6IFRSVU5DQVRFIERPV04JZnJvbSAweDMzNTdhIHRvIDB4OGRiNg0K OTAzNjgyKDIgbW9kIDI1Nik6IFRSVU5DQVRFIFVQCWZyb20gMHg4ZGI2IHRv IDB4MTU5YzgNCjkwMzY4MygzIG1vZCAyNTYpOiBNQVBSRUFECTB4ODRhOSB0 aHJ1IDB4Yjg0OQkoMHgzM2ExIGJ5dGVzKQ0KOTAzNjg0KDQgbW9kIDI1Nik6 IE1BUFJFQUQJMHgxNTA0ZiB0aHJ1IDB4MTU5YzcJKDB4OTc5IGJ5dGVzKQ0K OTAzNjg1KDUgbW9kIDI1Nik6IFRSVU5DQVRFIFVQCWZyb20gMHgxNTljOCB0 byAweDNlNzg4DQo5MDM2ODYoNiBtb2QgMjU2KTogUkVBRAkweDFmMmFhIHRo cnUgMHgyODAzOQkoMHg4ZDkwIGJ5dGVzKQ0KOTAzNjg3KDcgbW9kIDI1Nik6 IE1BUFdSSVRFIDB4MWE5YjUgdGhydSAweDI1MjhhCSgweGE4ZDYgYnl0ZXMp DQo5MDM2ODgoOCBtb2QgMjU2KTogV1JJVEUJMHgyZTcyOSB0aHJ1IDB4Mzdi ODIJKDB4OTQ1YSBieXRlcykNCjkwMzY4OSg5IG1vZCAyNTYpOiBUUlVOQ0FU RSBET1dOCWZyb20gMHgzZTc4OCB0byAweDgwOTcNCjkwMzY5MCgxMCBtb2Qg MjU2KTogTUFQUkVBRAkweDExMzkgdGhydSAweDgwOTYJKDB4NmY1ZSBieXRl cykNCjkwMzY5MSgxMSBtb2QgMjU2KTogVFJVTkNBVEUgVVAJZnJvbSAweDgw OTcgdG8gMHgzZTI3Yw0KOTAzNjkyKDEyIG1vZCAyNTYpOiBNQVBSRUFECTB4 OTViNCB0aHJ1IDB4YTEwMgkoMHhiNGYgYnl0ZXMpDQo5MDM2OTMoMTMgbW9k IDI1Nik6IE1BUFdSSVRFIDB4MzcwZDggdGhydSAweDNiZmYyCSgweDRmMWIg Ynl0ZXMpDQo5MDM2OTQoMTQgbW9kIDI1Nik6IE1BUFdSSVRFIDB4MjdiNDEg dGhydSAweDM2ODZjCSgweGVkMmMgYnl0ZXMpDQo5MDM2OTUoMTUgbW9kIDI1 Nik6IE1BUFJFQUQJMHhmOTk1IHRocnUgMHgxMTA0ZgkoMHgxNmJiIGJ5dGVz KQ0KOTAzNjk2KDE2IG1vZCAyNTYpOiBUUlVOQ0FURSBET1dOCWZyb20gMHgz ZTI3YyB0byAweDJmNDI0DQo5MDM2OTcoMTcgbW9kIDI1Nik6IFJFQUQJMHgx YzQ4OSB0aHJ1IDB4MjVkYjIJKDB4OTkyYSBieXRlcykNCjkwMzY5OCgxOCBt b2QgMjU2KTogUkVBRAkweGUxY2YgdGhydSAweDFiYThmCSgweGQ4YzEgYnl0 ZXMpDQo5MDM2OTkoMTkgbW9kIDI1Nik6IE1BUFJFQUQJMHg5ZjA5IHRocnUg MHgxODA1OQkoMHhlMTUxIGJ5dGVzKQ0KOTAzNzAwKDIwIG1vZCAyNTYpOiBX UklURQkweDExYzRlIHRocnUgMHgxNGZkYQkoMHgzMzhkIGJ5dGVzKQ0KOTAz NzAxKDIxIG1vZCAyNTYpOiBXUklURQkweDNkZjlkIHRocnUgMHgzZmZmZgko MHgyMDYzIGJ5dGVzKSBIT0xFDQo5MDM3MDIoMjIgbW9kIDI1Nik6IE1BUFdS SVRFIDB4Njg0NCB0aHJ1IDB4Yjk0OQkoMHg1MTA2IGJ5dGVzKQ0KOTAzNzAz KDIzIG1vZCAyNTYpOiBNQVBSRUFECTB4MjZiZTggdGhydSAweDJhMzIxCSgw eDM3M2EgYnl0ZXMpDQo5MDM3MDQoMjQgbW9kIDI1Nik6IFdSSVRFCTB4MzUy OWIgdGhydSAweDM5YzJlCSgweDQ5OTQgYnl0ZXMpDQo5MDM3MDUoMjUgbW9k IDI1Nik6IE1BUFdSSVRFIDB4MzJlZTQgdGhydSAweDNmNzg4CSgweGM4YTUg Ynl0ZXMpDQo5MDM3MDYoMjYgbW9kIDI1Nik6IFdSSVRFCTB4MTBlYmMgdGhy dSAweDFkN2JhCSgweGM4ZmYgYnl0ZXMpDQo5MDM3MDcoMjcgbW9kIDI1Nik6 IE1BUFdSSVRFIDB4M2FmODAgdGhydSAweDNmZmZmCSgweDUwODAgYnl0ZXMp DQo5MDM3MDgoMjggbW9kIDI1Nik6IE1BUFdSSVRFIDB4Mjk1MmMgdGhydSAw eDMxNDk5CSgweDdmNmUgYnl0ZXMpDQo5MDM3MDkoMjkgbW9kIDI1Nik6IFdS SVRFCTB4YjYzNiB0aHJ1IDB4MTU5MmMJKDB4YTJmNyBieXRlcykNCjkwMzcx MCgzMCBtb2QgMjU2KTogV1JJVEUJMHgyNzZkNSB0aHJ1IDB4MmQ1MTAJKDB4 NWUzYyBieXRlcykNCjkwMzcxMSgzMSBtb2QgMjU2KTogV1JJVEUJMHgxNzE4 ZCB0aHJ1IDB4MjIxYzcJKDB4YjAzYiBieXRlcykNCjkwMzcxMigzMiBtb2Qg MjU2KTogUkVBRAkweDE4NGVmIHRocnUgMHgyMWJhZgkoMHg5NmMxIGJ5dGVz KQ0KOTAzNzEzKDMzIG1vZCAyNTYpOiBUUlVOQ0FURSBET1dOCWZyb20gMHg0 MDAwMCB0byAweDFhMmFiDQo5MDM3MTQoMzQgbW9kIDI1Nik6IFJFQUQJMHhl MGZiIHRocnUgMHgxYTJhYQkoMHhjMWIwIGJ5dGVzKQ0KOTAzNzE1KDM1IG1v ZCAyNTYpOiBUUlVOQ0FURSBVUAlmcm9tIDB4MWEyYWIgdG8gMHgzYzczNA0K OTAzNzE2KDM2IG1vZCAyNTYpOiBNQVBSRUFECTB4MTQxNDEgdGhydSAweDFi MWYxCSgweDcwYjEgYnl0ZXMpDQo5MDM3MTcoMzcgbW9kIDI1Nik6IFJFQUQJ MHg1NjdiIHRocnUgMHg3ZTFhCSgweDI3YTAgYnl0ZXMpDQo5MDM3MTgoMzgg bW9kIDI1Nik6IFJFQUQJMHgxNTdmZCB0aHJ1IDB4MWVlMzMJKDB4OTYzNyBi eXRlcykNCjkwMzcxOSgzOSBtb2QgMjU2KTogTUFQV1JJVEUgMHgyOWNjOSB0 aHJ1IDB4MzQzZGQJKDB4YTcxNSBieXRlcykNCjkwMzcyMCg0MCBtb2QgMjU2 KTogUkVBRAkweDE1MTUxIHRocnUgMHgxZWRiMwkoMHg5YzYzIGJ5dGVzKQ0K OTAzNzIxKDQxIG1vZCAyNTYpOiBXUklURQkweGQxYTMgdGhydSAweGYxNTEJ KDB4MWZhZiBieXRlcykNCjkwMzcyMig0MiBtb2QgMjU2KTogTUFQUkVBRAkw eDMyMDBhIHRocnUgMHgzNWM3MgkoMHgzYzY5IGJ5dGVzKQ0KOTAzNzIzKDQz IG1vZCAyNTYpOiBSRUFECTB4MmI0MTEgdGhydSAweDMyYTQ5CSgweDc2Mzkg Ynl0ZXMpDQo5MDM3MjQoNDQgbW9kIDI1Nik6IFdSSVRFCTB4MmRlZWUgdGhy dSAweDM0YzU3CSgweDZkNmEgYnl0ZXMpDQo5MDM3MjUoNDUgbW9kIDI1Nik6 IFdSSVRFCTB4ZmU0MSB0aHJ1IDB4MWJmNDMJKDB4YzEwMyBieXRlcykNCjkw MzcyNig0NiBtb2QgMjU2KTogUkVBRAkweDM3MGE4IHRocnUgMHgzYzczMwko MHg1NjhjIGJ5dGVzKQ0KOTAzNzI3KDQ3IG1vZCAyNTYpOiBXUklURQkweDFm NTFkIHRocnUgMHgyNGNiYwkoMHg1N2EwIGJ5dGVzKQ0KOTAzNzI4KDQ4IG1v ZCAyNTYpOiBXUklURQkweDJmZWNjIHRocnUgMHgzMGIyNAkoMHhjNTkgYnl0 ZXMpDQo5MDM3MjkoNDkgbW9kIDI1Nik6IE1BUFJFQUQJMHgyNzBhMyB0aHJ1 IDB4MmE3ZjgJKDB4Mzc1NiBieXRlcykNCjkwMzczMCg1MCBtb2QgMjU2KTog VFJVTkNBVEUgRE9XTglmcm9tIDB4M2M3MzQgdG8gMHgyZWIyZA0KOTAzNzMx KDUxIG1vZCAyNTYpOiBXUklURQkweDJlNzlkIHRocnUgMHgyZWZhYwkoMHg4 MTAgYnl0ZXMpIEVYVEVORA0KOTAzNzMyKDUyIG1vZCAyNTYpOiBNQVBSRUFE CTB4ZWM4IHRocnUgMHgzMmM3CSgweDI0MDAgYnl0ZXMpDQo5MDM3MzMoNTMg bW9kIDI1Nik6IFJFQUQJMHgyZTE2ZCB0aHJ1IDB4MmVmYWMJKDB4ZTQwIGJ5 dGVzKQ0KOTAzNzM0KDU0IG1vZCAyNTYpOiBSRUFECTB4MThmZWEgdGhydSAw eDI1YTk1CSgweGNhYWMgYnl0ZXMpDQo5MDM3MzUoNTUgbW9kIDI1Nik6IFdS SVRFCTB4M2MxMTQgdGhydSAweDNmZmZmCSgweDNlZWMgYnl0ZXMpIEhPTEUN CjkwMzczNig1NiBtb2QgMjU2KTogVFJVTkNBVEUgRE9XTglmcm9tIDB4NDAw MDAgdG8gMHgzNjE2Mg0KOTAzNzM3KDU3IG1vZCAyNTYpOiBSRUFECTB4MzQy ODMgdGhydSAweDM2MTYxCSgweDFlZGYgYnl0ZXMpDQo5MDM3MzgoNTggbW9k IDI1Nik6IFRSVU5DQVRFIERPV04JZnJvbSAweDM2MTYyIHRvIDB4MjQzZWUN CjkwMzczOSg1OSBtb2QgMjU2KTogVFJVTkNBVEUgRE9XTglmcm9tIDB4MjQz ZWUgdG8gMHgxNmVlZQ0KOTAzNzQwKDYwIG1vZCAyNTYpOiBNQVBSRUFECTB4 MzgxYSB0aHJ1IDB4MTE0M2QJKDB4ZGMyNCBieXRlcykNCjkwMzc0MSg2MSBt b2QgMjU2KTogTUFQUkVBRAkweGUzYjIgdGhydSAweDEzMzY4CSgweDRmYjcg Ynl0ZXMpDQo5MDM3NDIoNjIgbW9kIDI1Nik6IE1BUFJFQUQJMHgyMTlkIHRo cnUgMHg2ODI2CSgweDQ2OGEgYnl0ZXMpDQo5MDM3NDMoNjMgbW9kIDI1Nik6 IFRSVU5DQVRFIERPV04JZnJvbSAweDE2ZWVlIHRvIDB4MTIyMA0KOTAzNzQ0 KDY0IG1vZCAyNTYpOiBXUklURQkweDFhZWQyIHRocnUgMHgxYmUyYgkoMHhm NWEgYnl0ZXMpIEhPTEUNCjkwMzc0NSg2NSBtb2QgMjU2KTogV1JJVEUJMHgz YWUxZSB0aHJ1IDB4M2IzYjMJKDB4NTk2IGJ5dGVzKSBIT0xFDQo5MDM3NDYo NjYgbW9kIDI1Nik6IE1BUFJFQUQJMHgxMmRkMiB0aHJ1IDB4MTkxYjkJKDB4 NjNlOCBieXRlcykNCjkwMzc0Nyg2NyBtb2QgMjU2KTogUkVBRAkweDU5NjEg dGhydSAweGUxODcJKDB4ODgyNyBieXRlcykNCjkwMzc0OCg2OCBtb2QgMjU2 KTogTUFQUkVBRAkweDJiYWY0IHRocnUgMHgzNGM1MgkoMHg5MTVmIGJ5dGVz KQ0KOTAzNzQ5KDY5IG1vZCAyNTYpOiBNQVBXUklURSAweDFiNDU0IHRocnUg MHgxZDU4YgkoMHgyMTM4IGJ5dGVzKQ0KOTAzNzUwKDcwIG1vZCAyNTYpOiBU UlVOQ0FURSBET1dOCWZyb20gMHgzYjNiNCB0byAweDViNGENCjkwMzc1MSg3 MSBtb2QgMjU2KTogTUFQUkVBRAkweDU1YWEgdGhydSAweDViNDkJKDB4NWEw IGJ5dGVzKQ0KOTAzNzUyKDcyIG1vZCAyNTYpOiBNQVBXUklURSAweDM0Y2E0 IHRocnUgMHgzOWM0MQkoMHg0ZjllIGJ5dGVzKQ0KOTAzNzUzKDczIG1vZCAy NTYpOiBNQVBXUklURSAweDFiMmI3IHRocnUgMHgyM2YyMgkoMHg4YzZjIGJ5 dGVzKQ0KOTAzNzU0KDc0IG1vZCAyNTYpOiBNQVBXUklURSAweDI4ODJmIHRo cnUgMHgyZmRhNwkoMHg3NTc5IGJ5dGVzKQ0KOTAzNzU1KDc1IG1vZCAyNTYp OiBNQVBXUklURSAweDJmODBkIHRocnUgMHgzNGNkOAkoMHg1NGNjIGJ5dGVz KQ0KOTAzNzU2KDc2IG1vZCAyNTYpOiBUUlVOQ0FURSBET1dOCWZyb20gMHgz OWM0MiB0byAweDM2ODA3DQo5MDM3NTcoNzcgbW9kIDI1Nik6IFRSVU5DQVRF IERPV04JZnJvbSAweDM2ODA3IHRvIDB4MmVlOTgNCjkwMzc1OCg3OCBtb2Qg MjU2KTogVFJVTkNBVEUgRE9XTglmcm9tIDB4MmVlOTggdG8gMHgxZGJmZg0K OTAzNzU5KDc5IG1vZCAyNTYpOiBSRUFECTB4NjczYiB0aHJ1IDB4NjgyYwko MHhmMiBieXRlcykNCjkwMzc2MCg4MCBtb2QgMjU2KTogV1JJVEUJMHgzYjMx ZCB0aHJ1IDB4M2QwOGEJKDB4MWQ2ZSBieXRlcykgSE9MRQ0KOTAzNzYxKDgx IG1vZCAyNTYpOiBNQVBXUklURSAweDIxYzAxIHRocnUgMHgyYzNlMAkoMHhh N2UwIGJ5dGVzKQ0KOTAzNzYyKDgyIG1vZCAyNTYpOiBSRUFECTB4MjRlNTcg dGhydSAweDJkZmNmCSgweDkxNzkgYnl0ZXMpDQo5MDM3NjMoODMgbW9kIDI1 Nik6IE1BUFJFQUQJMHhhY2MzIHRocnUgMHgxOTdiNgkoMHhlYWY0IGJ5dGVz KQ0KOTAzNzY0KDg0IG1vZCAyNTYpOiBNQVBSRUFECTB4MjNkMzkgdGhydSAw eDMwMzIyCSgweGM1ZWEgYnl0ZXMpDQo5MDM3NjUoODUgbW9kIDI1Nik6IFJF QUQJMHgzOGE1NiB0aHJ1IDB4M2QwOGEJKDB4NDYzNSBieXRlcykNCjkwMzc2 Nig4NiBtb2QgMjU2KTogV1JJVEUJMHgyODcwNCB0aHJ1IDB4MjlmYmIJKDB4 MThiOCBieXRlcykNCjkwMzc2Nyg4NyBtb2QgMjU2KTogTUFQV1JJVEUgMHgz NzAwOSB0aHJ1IDB4Mzc0NjQJKDB4NDVjIGJ5dGVzKQ0KOTAzNzY4KDg4IG1v ZCAyNTYpOiBNQVBSRUFECTB4MTQ5MTAgdGhydSAweDI0NGQwCSgweGZiYzEg Ynl0ZXMpDQo5MDM3NjkoODkgbW9kIDI1Nik6IE1BUFJFQUQJMHgyZjJhMSB0 aHJ1IDB4Mzg5NTQJKDB4OTZiNCBieXRlcykNCjkwMzc3MCg5MCBtb2QgMjU2 KTogUkVBRAkweDExNzRhIHRocnUgMHgxNjFiZAkoMHg0YTc0IGJ5dGVzKQ0K OTAzNzcxKDkxIG1vZCAyNTYpOiBNQVBSRUFECTB4MTI2OWYgdGhydSAweDFj NmY1CSgweGEwNTcgYnl0ZXMpDQo5MDM3NzIoOTIgbW9kIDI1Nik6IFRSVU5D QVRFIERPV04JZnJvbSAweDNkMDhiIHRvIDB4MTRhZmMNCjkwMzc3Myg5MyBt b2QgMjU2KTogTUFQUkVBRAkweDEyZDk0IHRocnUgMHgxNGFmYgkoMHgxZDY4 IGJ5dGVzKQ0KOTAzNzc0KDk0IG1vZCAyNTYpOiBXUklURQkweDRiYmUgdGhy dSAweDhhNWUJKDB4M2VhMSBieXRlcykNCjkwMzc3NSg5NSBtb2QgMjU2KTog UkVBRAkweDE0MzdkIHRocnUgMHgxNGFmYgkoMHg3N2YgYnl0ZXMpDQo5MDM3 NzYoOTYgbW9kIDI1Nik6IFRSVU5DQVRFIFVQCWZyb20gMHgxNGFmYyB0byAw eDM1ZmFlDQo5MDM3NzcoOTcgbW9kIDI1Nik6IFRSVU5DQVRFIERPV04JZnJv bSAweDM1ZmFlIHRvIDB4YjM5OA0KOTAzNzc4KDk4IG1vZCAyNTYpOiBXUklU RQkweDExNzM3IHRocnUgMHgxMWJmYQkoMHg0YzQgYnl0ZXMpIEhPTEUNCjkw Mzc3OSg5OSBtb2QgMjU2KTogTUFQV1JJVEUgMHhhNzBjIHRocnUgMHgxMmNi MQkoMHg4NWE2IGJ5dGVzKQ0KOTAzNzgwKDEwMCBtb2QgMjU2KTogTUFQV1JJ VEUgMHgxMjMzYSB0aHJ1IDB4MjFlOTIJKDB4ZmI1OSBieXRlcykNCjkwMzc4 MSgxMDEgbW9kIDI1Nik6IFJFQUQJMHgxNmYzZSB0aHJ1IDB4MTg4YTEJKDB4 MTk2NCBieXRlcykNCjkwMzc4MigxMDIgbW9kIDI1Nik6IFdSSVRFCTB4MWI1 MzAgdGhydSAweDIzZTQ1CSgweDg5MTYgYnl0ZXMpIEVYVEVORA0KOTAzNzgz KDEwMyBtb2QgMjU2KTogUkVBRAkweDFiZDYgdGhydSAweDFkZTEJKDB4MjBj IGJ5dGVzKQ0KOTAzNzg0KDEwNCBtb2QgMjU2KTogVFJVTkNBVEUgVVAJZnJv bSAweDIzZTQ2IHRvIDB4MzY1MGUNCjkwMzc4NSgxMDUgbW9kIDI1Nik6IFJF QUQJMHhkOGU2IHRocnUgMHgxODI0YgkoMHhhOTY2IGJ5dGVzKQ0KOTAzNzg2 KDEwNiBtb2QgMjU2KTogTUFQV1JJVEUgMHgxMjY3YiB0aHJ1IDB4MjA5NTcJ KDB4ZTJkZCBieXRlcykNCjkwMzc4NygxMDcgbW9kIDI1Nik6IE1BUFdSSVRF IDB4MmQ2MDAgdGhydSAweDNiNWI4CSgweGRmYjkgYnl0ZXMpDQo5MDM3ODgo MTA4IG1vZCAyNTYpOiBNQVBXUklURSAweDNhMTNhIHRocnUgMHgzZWNjYwko MHg0YjkzIGJ5dGVzKQ0KOTAzNzg5KDEwOSBtb2QgMjU2KTogUkVBRAkweGE4 NWQgdGhydSAweGVjYmEJKDB4NDQ1ZSBieXRlcykNCjkwMzc5MCgxMTAgbW9k IDI1Nik6IFRSVU5DQVRFIERPV04JZnJvbSAweDNlY2NkIHRvIDB4MjU2YWEN CjkwMzc5MSgxMTEgbW9kIDI1Nik6IE1BUFdSSVRFIDB4M2NmNWMgdGhydSAw eDNmZmZmCSgweDMwYTQgYnl0ZXMpDQo5MDM3OTIoMTEyIG1vZCAyNTYpOiBU UlVOQ0FURSBET1dOCWZyb20gMHg0MDAwMCB0byAweDMxYTk5DQo5MDM3OTMo MTEzIG1vZCAyNTYpOiBXUklURQkweDIxOGFlIHRocnUgMHgyNjcxYwkoMHg0 ZTZmIGJ5dGVzKQ0KOTAzNzk0KDExNCBtb2QgMjU2KTogVFJVTkNBVEUgRE9X Tglmcm9tIDB4MzFhOTkgdG8gMHgxN2VjMA0KOTAzNzk1KDExNSBtb2QgMjU2 KTogTUFQUkVBRAkweDEwMzA4IHRocnUgMHgxNWYyMQkoMHg1YzFhIGJ5dGVz KQ0KOTAzNzk2KDExNiBtb2QgMjU2KTogV1JJVEUJMHgyM2E2OCB0aHJ1IDB4 MjVmY2QJKDB4MjU2NiBieXRlcykgSE9MRQ0KOTAzNzk3KDExNyBtb2QgMjU2 KTogV1JJVEUJMHgyMzY2NyB0aHJ1IDB4MmFkZjIJKDB4Nzc4YyBieXRlcykg RVhURU5EDQo5MDM3OTgoMTE4IG1vZCAyNTYpOiBUUlVOQ0FURSBET1dOCWZy b20gMHgyYWRmMyB0byAweDEwOWQwDQo5MDM3OTkoMTE5IG1vZCAyNTYpOiBS RUFECTB4YmM4OCB0aHJ1IDB4Y2QzYgkoMHgxMGI0IGJ5dGVzKQ0KOTAzODAw KDEyMCBtb2QgMjU2KTogV1JJVEUJMHgzMTRkMSB0aHJ1IDB4MzJiYzYJKDB4 MTZmNiBieXRlcykgSE9MRQ0KOTAzODAxKDEyMSBtb2QgMjU2KTogTUFQV1JJ VEUgMHgzZDlhZCB0aHJ1IDB4M2ZmZmYJKDB4MjY1MyBieXRlcykNCjkwMzgw MigxMjIgbW9kIDI1Nik6IE1BUFJFQUQJMHgxMGNlMCB0aHJ1IDB4MTNhZDUJ KDB4MmRmNiBieXRlcykNCjkwMzgwMygxMjMgbW9kIDI1Nik6IFRSVU5DQVRF IERPV04JZnJvbSAweDQwMDAwIHRvIDB4MTc3NTUNCjkwMzgwNCgxMjQgbW9k IDI1Nik6IFRSVU5DQVRFIERPV04JZnJvbSAweDE3NzU1IHRvIDB4N2ExNw0K OTAzODA1KDEyNSBtb2QgMjU2KTogVFJVTkNBVEUgVVAJZnJvbSAweDdhMTcg dG8gMHgzOTk3ZA0KOTAzODA2KDEyNiBtb2QgMjU2KTogVFJVTkNBVEUgRE9X Tglmcm9tIDB4Mzk5N2QgdG8gMHgzNTBjMA0KOTAzODA3KDEyNyBtb2QgMjU2 KTogTUFQV1JJVEUgMHgxZDcwZCB0aHJ1IDB4MWUyNTEJKDB4YjQ1IGJ5dGVz KQ0KOTAzODA4KDEyOCBtb2QgMjU2KTogV1JJVEUJMHgxODVkIHRocnUgMHhj NGQxCSgweGFjNzUgYnl0ZXMpDQo5MDM4MDkoMTI5IG1vZCAyNTYpOiBNQVBX UklURSAweDNmZjlkIHRocnUgMHgzZmZmZgkoMHg2MyBieXRlcykNCjkwMzgx MCgxMzAgbW9kIDI1Nik6IFRSVU5DQVRFIERPV04JZnJvbSAweDQwMDAwIHRv IDB4MTRlOTgNCjkwMzgxMSgxMzEgbW9kIDI1Nik6IFdSSVRFCTB4MTQxOGMg dGhydSAweDIzYzlkCSgweGZiMTIgYnl0ZXMpIEVYVEVORA0KOTAzODEyKDEz MiBtb2QgMjU2KTogTUFQV1JJVEUgMHhkNDFlIHRocnUgMHgxZDE0ZAkoMHhm ZDMwIGJ5dGVzKQ0KOTAzODEzKDEzMyBtb2QgMjU2KTogTUFQUkVBRAkweDE5 YWFhIHRocnUgMHgxY2NkZAkoMHgzMjM0IGJ5dGVzKQ0KOTAzODE0KDEzNCBt b2QgMjU2KTogUkVBRAkweDIzNjI0IHRocnUgMHgyM2M5ZAkoMHg2N2EgYnl0 ZXMpDQo5MDM4MTUoMTM1IG1vZCAyNTYpOiBNQVBXUklURSAweDE4YjAyIHRo cnUgMHgyMzk0MgkoMHhhZTQxIGJ5dGVzKQ0KOTAzODE2KDEzNiBtb2QgMjU2 KTogUkVBRAkweDFhZmY1IHRocnUgMHgyM2M5ZAkoMHg4Y2E5IGJ5dGVzKQ0K OTAzODE3KDEzNyBtb2QgMjU2KTogV1JJVEUJMHgyY2MxYSB0aHJ1IDB4MmYz ZWEJKDB4MjdkMSBieXRlcykgSE9MRQ0KOTAzODE4KDEzOCBtb2QgMjU2KTog V1JJVEUJMHgxZWU2OSB0aHJ1IDB4MmVjYjcJKDB4ZmU0ZiBieXRlcykNCjkw MzgxOSgxMzkgbW9kIDI1Nik6IE1BUFdSSVRFIDB4MjQ2ZmIgdGhydSAweDMy MTNlCSgweGRhNDQgYnl0ZXMpDQo5MDM4MjAoMTQwIG1vZCAyNTYpOiBUUlVO Q0FURSBET1dOCWZyb20gMHgzMjEzZiB0byAweDE5YTY1DQo5MDM4MjEoMTQx IG1vZCAyNTYpOiBXUklURQkweDJhOTY3IHRocnUgMHgyZDk1MwkoMHgyZmVk IGJ5dGVzKSBIT0xFDQo5MDM4MjIoMTQyIG1vZCAyNTYpOiBXUklURQkweDE3 ODMzIHRocnUgMHgxZDg2ZAkoMHg2MDNiIGJ5dGVzKQ0KOTAzODIzKDE0MyBt b2QgMjU2KTogV1JJVEUJMHhmMzQxIHRocnUgMHgxNjE2NgkoMHg2ZTI2IGJ5 dGVzKQ0KOTAzODI0KDE0NCBtb2QgMjU2KTogUkVBRAkweDNiYmMgdGhydSAw eGE1OWUJKDB4NjllMyBieXRlcykNCjkwMzgyNSgxNDUgbW9kIDI1Nik6IE1B UFdSSVRFIDB4M2EwNjcgdGhydSAweDNlNDY2CSgweDQ0MDAgYnl0ZXMpDQo5 MDM4MjYoMTQ2IG1vZCAyNTYpOiBNQVBXUklURSAweDFhZjdhIHRocnUgMHgy YTQ3OQkoMHhmNTAwIGJ5dGVzKQ0KOTAzODI3KDE0NyBtb2QgMjU2KTogTUFQ UkVBRAkweDQ5ZDIgdGhydSAweGUyZTAJKDB4OTkwZiBieXRlcykNCjkwMzgy OCgxNDggbW9kIDI1Nik6IFJFQUQJMHgzOWViYSB0aHJ1IDB4M2U0NjYJKDB4 NDVhZCBieXRlcykNCjkwMzgyOSgxNDkgbW9kIDI1Nik6IFRSVU5DQVRFIERP V04JZnJvbSAweDNlNDY3IHRvIDB4MTg1YmMNCjkwMzgzMCgxNTAgbW9kIDI1 Nik6IFJFQUQJMHg5M2IwIHRocnUgMHgxNzA0ZAkoMHhkYzllIGJ5dGVzKQ0K OTAzODMxKDE1MSBtb2QgMjU2KTogTUFQV1JJVEUgMHgxYWIwMSB0aHJ1IDB4 MjA2ODMJKDB4NWI4MyBieXRlcykNCjkwMzgzMigxNTIgbW9kIDI1Nik6IFJF QUQJMHgxNzI4NiB0aHJ1IDB4MjA2ODMJKDB4OTNmZSBieXRlcykNCjkwMzgz MygxNTMgbW9kIDI1Nik6IE1BUFJFQUQJMHgxMjU3YiB0aHJ1IDB4MWNlOTAJ KDB4YTkxNiBieXRlcykNCjkwMzgzNCgxNTQgbW9kIDI1Nik6IFdSSVRFCTB4 MmQ5NjMgdGhydSAweDM5MmJkCSgweGI5NWIgYnl0ZXMpIEhPTEUNCjkwMzgz NSgxNTUgbW9kIDI1Nik6IFJFQUQJMHgyN2E0NCB0aHJ1IDB4MmNlOTQJKDB4 NTQ1MSBieXRlcykNCjkwMzgzNigxNTYgbW9kIDI1Nik6IFdSSVRFCTB4M2Q3 NmQgdGhydSAweDNmZmZmCSgweDI4OTMgYnl0ZXMpIEhPTEUNCjkwMzgzNygx NTcgbW9kIDI1Nik6IFJFQUQJMHgzZWQ3MCB0aHJ1IDB4M2ZmZmYJKDB4MTI5 MCBieXRlcykNCjkwMzgzOCgxNTggbW9kIDI1Nik6IE1BUFJFQUQJMHhjODMw IHRocnUgMHgxOTU1NgkoMHhjZDI3IGJ5dGVzKQ0KOTAzODM5KDE1OSBtb2Qg MjU2KTogUkVBRAkweDI1Y2ZiIHRocnUgMHgyYzFlYgkoMHg2NGYxIGJ5dGVz KQ0KOTAzODQwKDE2MCBtb2QgMjU2KTogUkVBRAkweDFjZTdlIHRocnUgMHgy YzBhZAkoMHhmMjMwIGJ5dGVzKQ0KOTAzODQxKDE2MSBtb2QgMjU2KTogVFJV TkNBVEUgRE9XTglmcm9tIDB4NDAwMDAgdG8gMHgyMjBkDQo5MDM4NDIoMTYy IG1vZCAyNTYpOiBUUlVOQ0FURSBVUAlmcm9tIDB4MjIwZCB0byAweDE2YzJl DQo5MDM4NDMoMTYzIG1vZCAyNTYpOiBXUklURQkweDE4NWY5IHRocnUgMHgy MGEyYwkoMHg4NDM0IGJ5dGVzKSBIT0xFDQo5MDM4NDQoMTY0IG1vZCAyNTYp OiBSRUFECTB4ZGI2NSB0aHJ1IDB4MTc0OWUJKDB4OTkzYSBieXRlcykNCjkw Mzg0NSgxNjUgbW9kIDI1Nik6IFJFQUQJMHgxN2E5YSB0aHJ1IDB4MWVhMWQJ KDB4NmY4NCBieXRlcykNCjkwMzg0NigxNjYgbW9kIDI1Nik6IFJFQUQJMHg2 ZWRiIHRocnUgMHhmZTFjCSgweDhmNDIgYnl0ZXMpDQo5MDM4NDcoMTY3IG1v ZCAyNTYpOiBNQVBXUklURSAweDI5ZGJjIHRocnUgMHgzODQyYQkoMHhlNjZm IGJ5dGVzKQ0KOTAzODQ4KDE2OCBtb2QgMjU2KTogVFJVTkNBVEUgVVAJZnJv bSAweDM4NDJiIHRvIDB4M2ZlMTcNCjkwMzg0OSgxNjkgbW9kIDI1Nik6IFdS SVRFCTB4M2NjNDkgdGhydSAweDNmZmZmCSgweDMzYjcgYnl0ZXMpIEVYVEVO RA0KOTAzODUwKDE3MCBtb2QgMjU2KTogTUFQUkVBRAkweDEwMDE1IHRocnUg MHgxMzUxYwkoMHgzNTA4IGJ5dGVzKQ0KOTAzODUxKDE3MSBtb2QgMjU2KTog TUFQV1JJVEUgMHgzOTM5NiB0aHJ1IDB4M2ZmZmYJKDB4NmM2YSBieXRlcykN CjkwMzg1MigxNzIgbW9kIDI1Nik6IE1BUFdSSVRFIDB4M2Y0N2UgdGhydSAw eDNmZmZmCSgweGI4MiBieXRlcykNCjkwMzg1MygxNzMgbW9kIDI1Nik6IE1B UFdSSVRFIDB4NDU0NCB0aHJ1IDB4ZGQ5YwkoMHg5ODU5IGJ5dGVzKQ0KOTAz ODU0KDE3NCBtb2QgMjU2KTogVFJVTkNBVEUgRE9XTglmcm9tIDB4NDAwMDAg dG8gMHgxM2ExOQ0KOTAzODU1KDE3NSBtb2QgMjU2KTogUkVBRAkweDEwMmM3 IHRocnUgMHgxM2ExOAkoMHgzNzUyIGJ5dGVzKQ0KOTAzODU2KDE3NiBtb2Qg MjU2KTogTUFQV1JJVEUgMHhmOTYgdGhydSAweGRlMTkJKDB4Y2U4NCBieXRl cykNCjkwMzg1NygxNzcgbW9kIDI1Nik6IE1BUFJFQUQJMHhjOTYyIHRocnUg MHhkMWQzCSgweDg3MiBieXRlcykNCjkwMzg1OCgxNzggbW9kIDI1Nik6IE1B UFdSSVRFIDB4NGI1ZSB0aHJ1IDB4ZDNmNgkoMHg4ODk5IGJ5dGVzKQ0KOTAz ODU5KDE3OSBtb2QgMjU2KTogUkVBRAkweDExYjUwIHRocnUgMHgxM2ExOAko MHgxZWM5IGJ5dGVzKQ0KOTAzODYwKDE4MCBtb2QgMjU2KTogV1JJVEUJMHgy NTRkMiB0aHJ1IDB4MjU5YWIJKDB4NGRhIGJ5dGVzKSBIT0xFDQo5MDM4NjEo MTgxIG1vZCAyNTYpOiBSRUFECTB4ODI3YSB0aHJ1IDB4MTZlMTIJKDB4ZWI5 OSBieXRlcykNCjkwMzg2MigxODIgbW9kIDI1Nik6IFdSSVRFCTB4MTM4NGYg dGhydSAweDIxNTZlCSgweGRkMjAgYnl0ZXMpDQo5MDM4NjMoMTgzIG1vZCAy NTYpOiBNQVBSRUFECTB4MTgyYyB0aHJ1IDB4OGZkNgkoMHg3N2FiIGJ5dGVz KQ0KOTAzODY0KDE4NCBtb2QgMjU2KTogV1JJVEUJMHgzN2VkZiB0aHJ1IDB4 M2E5YzMJKDB4MmFlNSBieXRlcykgSE9MRQ0KOTAzODY1KDE4NSBtb2QgMjU2 KTogUkVBRAkweDE2MGFiIHRocnUgMHgxY2Q4MQkoMHg2Y2Q3IGJ5dGVzKQ0K OTAzODY2KDE4NiBtb2QgMjU2KTogV1JJVEUJMHgzOGE1YSB0aHJ1IDB4M2Zm ZmYJKDB4NzVhNiBieXRlcykgRVhURU5EDQo5MDM4NjcoMTg3IG1vZCAyNTYp OiBXUklURQkweDFmNThiIHRocnUgMHgyZjQ0MgkoMHhmZWI4IGJ5dGVzKQ0K OTAzODY4KDE4OCBtb2QgMjU2KTogTUFQUkVBRAkweGFlNDYgdGhydSAweGVl MDAJKDB4M2ZiYiBieXRlcykNCjkwMzg2OSgxODkgbW9kIDI1Nik6IE1BUFdS SVRFIDB4ZGI5NyB0aHJ1IDB4ZWJiOAkoMHgxMDIyIGJ5dGVzKQ0KOTAzODcw KDE5MCBtb2QgMjU2KTogUkVBRAkweDI1ZTYzIHRocnUgMHgyYTRhYwkoMHg0 NjRhIGJ5dGVzKQ0KOTAzODcxKDE5MSBtb2QgMjU2KTogVFJVTkNBVEUgRE9X Tglmcm9tIDB4NDAwMDAgdG8gMHgxODU5OA0KOTAzODcyKDE5MiBtb2QgMjU2 KTogTUFQV1JJVEUgMHgxNjlmYSB0aHJ1IDB4MjAxYjUJKDB4OTdiYyBieXRl cykNCjkwMzg3MygxOTMgbW9kIDI1Nik6IFJFQUQJMHgxODNiMCB0aHJ1IDB4 MTg5OTcJKDB4NWU4IGJ5dGVzKQ0KOTAzODc0KDE5NCBtb2QgMjU2KTogVFJV TkNBVEUgRE9XTglmcm9tIDB4MjAxYjYgdG8gMHg3NGJhDQo5MDM4NzUoMTk1 IG1vZCAyNTYpOiBNQVBSRUFECTB4NjdkYSB0aHJ1IDB4NzRiOQkoMHhjZTAg Ynl0ZXMpDQo5MDM4NzYoMTk2IG1vZCAyNTYpOiBXUklURQkweDIyNTU4IHRo cnUgMHgyOWFiYwkoMHg3NTY1IGJ5dGVzKSBIT0xFDQo5MDM4NzcoMTk3IG1v ZCAyNTYpOiBXUklURQkweGYzOGQgdGhydSAweDE3ZGY3CSgweDhhNmIgYnl0 ZXMpDQo5MDM4NzgoMTk4IG1vZCAyNTYpOiBNQVBXUklURSAweDFlYWMgdGhy dSAweGY2MWEJKDB4ZDc2ZiBieXRlcykNCjkwMzg3OSgxOTkgbW9kIDI1Nik6 IFRSVU5DQVRFIFVQCWZyb20gMHgyOWFiZCB0byAweDNhZjA0DQo5MDM4ODAo MjAwIG1vZCAyNTYpOiBNQVBXUklURSAweGFhMTUgdGhydSAweDE5ZDBjCSgw eGYyZjggYnl0ZXMpDQo5MDM4ODEoMjAxIG1vZCAyNTYpOiBXUklURQkweDNk M2YzIHRocnUgMHgzZmZmZgkoMHgyYzBkIGJ5dGVzKSBIT0xFDQo5MDM4ODIo MjAyIG1vZCAyNTYpOiBSRUFECTB4MTk4MDIgdGhydSAweDFiZTA1CSgweDI2 MDQgYnl0ZXMpDQo5MDM4ODMoMjAzIG1vZCAyNTYpOiBUUlVOQ0FURSBET1dO CWZyb20gMHg0MDAwMCB0byAweDFlNzkxDQo5MDM4ODQoMjA0IG1vZCAyNTYp OiBUUlVOQ0FURSBET1dOCWZyb20gMHgxZTc5MSB0byAweDZjZjANCjkwMzg4 NSgyMDUgbW9kIDI1Nik6IFRSVU5DQVRFIFVQCWZyb20gMHg2Y2YwIHRvIDB4 MzgyYzkNCjkwMzg4NigyMDYgbW9kIDI1Nik6IE1BUFdSSVRFIDB4NmY2MiB0 aHJ1IDB4YTA4OAkoMHgzMTI3IGJ5dGVzKQ0KOTAzODg3KDIwNyBtb2QgMjU2 KTogVFJVTkNBVEUgVVAJZnJvbSAweDM4MmM5IHRvIDB4Mzg2ZmENCjkwMzg4 OCgyMDggbW9kIDI1Nik6IFRSVU5DQVRFIERPV04JZnJvbSAweDM4NmZhIHRv IDB4MTYxNGENCjkwMzg4OSgyMDkgbW9kIDI1Nik6IFdSSVRFCTB4MWQ1ZWYg dGhydSAweDJhNmIzCSgweGQwYzUgYnl0ZXMpIEhPTEUNCjkwMzg5MCgyMTAg bW9kIDI1Nik6IE1BUFJFQUQJMHgxNTllNiB0aHJ1IDB4MjNkOGYJKDB4ZTNh YSBieXRlcykNCjkwMzg5MSgyMTEgbW9kIDI1Nik6IFdSSVRFCTB4YTY4MCB0 aHJ1IDB4MTA3MTQJKDB4NjA5NSBieXRlcykNCjkwMzg5MigyMTIgbW9kIDI1 Nik6IE1BUFdSSVRFIDB4MTQ0ZGEgdGhydSAweDE3YWFhCSgweDM1ZDEgYnl0 ZXMpDQo5MDM4OTMoMjEzIG1vZCAyNTYpOiBXUklURQkweDE0Mzc4IHRocnUg MHgxYTMzZAkoMHg1ZmM2IGJ5dGVzKQ0KOTAzODk0KDIxNCBtb2QgMjU2KTog TUFQUkVBRAkweDI0MjMzIHRocnUgMHgyYTZiMwkoMHg2NDgxIGJ5dGVzKQ0K OTAzODk1KDIxNSBtb2QgMjU2KTogTUFQUkVBRAkweDI4ZmIzIHRocnUgMHgy YTZiMwkoMHgxNzAxIGJ5dGVzKQ0KOTAzODk2KDIxNiBtb2QgMjU2KTogV1JJ VEUJMHgyZGMyMCB0aHJ1IDB4MzVjY2QJKDB4ODBhZSBieXRlcykgSE9MRQ0K OTAzODk3KDIxNyBtb2QgMjU2KTogUkVBRAkweDI1MTZhIHRocnUgMHgyZjFm MgkoMHhhMDg5IGJ5dGVzKQ0KOTAzODk4KDIxOCBtb2QgMjU2KTogTUFQUkVB RAkweDE3NWUxIHRocnUgMHgyMjdmZQkoMHhiMjFlIGJ5dGVzKQ0KOTAzODk5 KDIxOSBtb2QgMjU2KTogTUFQV1JJVEUgMHg0NmI4IHRocnUgMHhmMTQyCSgw eGFhOGIgYnl0ZXMpDQo5MDM5MDAoMjIwIG1vZCAyNTYpOiBXUklURQkweDE3 YTZkIHRocnUgMHgxOTk3OAkoMHgxZjBjIGJ5dGVzKQ0KOTAzOTAxKDIyMSBt b2QgMjU2KTogTUFQUkVBRAkweDEzNmRmIHRocnUgMHgxZmRmNAkoMHhjNzE2 IGJ5dGVzKQ0KOTAzOTAyKDIyMiBtb2QgMjU2KTogV1JJVEUJMHhiNDIzIHRo cnUgMHgxN2M1MwkoMHhjODMxIGJ5dGVzKQ0KOTAzOTAzKDIyMyBtb2QgMjU2 KTogUkVBRAkweDIzMDVlIHRocnUgMHgyZDk4OAkoMHhhOTJiIGJ5dGVzKQ0K OTAzOTA0KDIyNCBtb2QgMjU2KTogTUFQV1JJVEUgMHgxZjMxYSB0aHJ1IDB4 MjljMDcJKDB4YThlZSBieXRlcykNCjkwMzkwNSgyMjUgbW9kIDI1Nik6IE1B UFJFQUQJMHgxOTQ0MCB0aHJ1IDB4MWZjNjAJKDB4NjgyMSBieXRlcykNCjkw MzkwNigyMjYgbW9kIDI1Nik6IE1BUFJFQUQJMHg3NjlmIHRocnUgMHg4ZjJl CSgweDE4OTAgYnl0ZXMpDQo5MDM5MDcoMjI3IG1vZCAyNTYpOiBSRUFECTB4 MjU5ZDAgdGhydSAweDJjMDA5CSgweDY2M2EgYnl0ZXMpDQo5MDM5MDgoMjI4 IG1vZCAyNTYpOiBNQVBSRUFECTB4MTU5ZjMgdGhydSAweDI0MWM1CSgweGU3 ZDMgYnl0ZXMpDQo5MDM5MDkoMjI5IG1vZCAyNTYpOiBSRUFECTB4MmMxMjUg dGhydSAweDMyZmVhCSgweDZlYzYgYnl0ZXMpDQo5MDM5MTAoMjMwIG1vZCAy NTYpOiBUUlVOQ0FURSBET1dOCWZyb20gMHgzNWNjZSB0byAweGExNWENCjkw MzkxMSgyMzEgbW9kIDI1Nik6IE1BUFdSSVRFIDB4MTk2MjAgdGhydSAweDFj NzkwCSgweDMxNzEgYnl0ZXMpDQo5MDM5MTIoMjMyIG1vZCAyNTYpOiBUUlVO Q0FURSBET1dOCWZyb20gMHgxYzc5MSB0byAweDFhMzhmDQo5MDM5MTMoMjMz IG1vZCAyNTYpOiBNQVBSRUFECTB4NzNiOCB0aHJ1IDB4Zjc5YQkoMHg4M2Uz IGJ5dGVzKQ0KOTAzOTE0KDIzNCBtb2QgMjU2KTogV1JJVEUJMHgxNTBkZSB0 aHJ1IDB4MWRjOWYJKDB4OGJjMiBieXRlcykgRVhURU5EDQo5MDM5MTUoMjM1 IG1vZCAyNTYpOiBNQVBSRUFECTB4OWEzOSB0aHJ1IDB4MTdiNjIJKDB4ZTEy YSBieXRlcykNCjkwMzkxNigyMzYgbW9kIDI1Nik6IE1BUFJFQUQJMHhjNDFj IHRocnUgMHhlZGNlCSgweDI5YjMgYnl0ZXMpDQo5MDM5MTcoMjM3IG1vZCAy NTYpOiBXUklURQkweDI0YWZkIHRocnUgMHgyY2E3MwkoMHg3Zjc3IGJ5dGVz KSBIT0xFDQo5MDM5MTgoMjM4IG1vZCAyNTYpOiBUUlVOQ0FURSBET1dOCWZy b20gMHgyY2E3NCB0byAweGY3ZDMNCjkwMzkxOSgyMzkgbW9kIDI1Nik6IFdS SVRFCTB4MzMxMjggdGhydSAweDM3YjMzCSgweDRhMGMgYnl0ZXMpIEhPTEUN CjkwMzkyMCgyNDAgbW9kIDI1Nik6IFJFQUQJMHgyYmY1NSB0aHJ1IDB4Mzdi MzMJKDB4YmJkZiBieXRlcykNCjkwMzkyMSgyNDEgbW9kIDI1Nik6IFdSSVRF CTB4MzFhZCB0aHJ1IDB4ZGY2NgkoMHhhZGJhIGJ5dGVzKQ0KOTAzOTIyKDI0 MiBtb2QgMjU2KTogTUFQUkVBRAkweDExMGYwIHRocnUgMHgxMTg3ZAkoMHg3 OGUgYnl0ZXMpDQo5MDM5MjMoMjQzIG1vZCAyNTYpOiBXUklURQkweDE1YmE2 IHRocnUgMHgxYmEwOAkoMHg1ZTYzIGJ5dGVzKQ0KOTAzOTI0KDI0NCBtb2Qg MjU2KTogTUFQV1JJVEUgMHgxZjkyIHRocnUgMHg3MDM1CSgweDUwYTQgYnl0 ZXMpDQo5MDM5MjUoMjQ1IG1vZCAyNTYpOiBNQVBXUklURSAweDE3OTJkIHRo cnUgMHgyNGIwZgkoMHhkMWUzIGJ5dGVzKQ0KOTAzOTI2KDI0NiBtb2QgMjU2 KTogUkVBRAkweDM0YzAxIHRocnUgMHgzN2IzMwkoMHgyZjMzIGJ5dGVzKQ0K OTAzOTI3KDI0NyBtb2QgMjU2KTogTUFQV1JJVEUgMHgxMzRiZSB0aHJ1IDB4 MThjNWUJKDB4NTdhMSBieXRlcykNCjkwMzkyOCgyNDggbW9kIDI1Nik6IE1B UFJFQUQJMHhiNmM2IHRocnUgMHgxNmI4NwkoMHhiNGMyIGJ5dGVzKQ0KOTAz OTI5KDI0OSBtb2QgMjU2KTogVFJVTkNBVEUgRE9XTglmcm9tIDB4MzdiMzQg dG8gMHgxOThjMw0KOTAzOTMwKDI1MCBtb2QgMjU2KTogTUFQV1JJVEUgMHgz NWU2MSB0aHJ1IDB4M2ZmZmYJKDB4YTE5ZiBieXRlcykNCjkwMzkzMSgyNTEg bW9kIDI1Nik6IE1BUFdSSVRFIDB4MzUxNGMgdGhydSAweDNjMzhiCSgweDcy NDAgYnl0ZXMpDQo5MDM5MzIoMjUyIG1vZCAyNTYpOiBNQVBSRUFECTB4M2E2 NTYgdGhydSAweDNmZmZmCSgweDU5YWEgYnl0ZXMpDQo5MDM5MzMoMjUzIG1v ZCAyNTYpOiBNQVBXUklURSAweDFmNTQ3IHRocnUgMHgyZWQ1ZQkoMHhmODE4 IGJ5dGVzKQ0KOTAzOTM0KDI1NCBtb2QgMjU2KTogTUFQV1JJVEUgMHhkNTgx IHRocnUgMHgxNDRmNgkoMHg2Zjc2IGJ5dGVzKQ0KOTAzOTM1KDI1NSBtb2Qg MjU2KTogTUFQV1JJVEUgMHgyMzE4MiB0aHJ1IDB4MjZjNTgJKDB4M2FkNyBi eXRlcykNCjkwMzkzNigwIG1vZCAyNTYpOiBSRUFECTB4MmZmYjMgdGhydSAw eDNlZGYxCSgweGVlM2YgYnl0ZXMpDQo5MDM5MzcoMSBtb2QgMjU2KTogV1JJ VEUJMHgxYjhhMSB0aHJ1IDB4MjEwYTUJKDB4NTgwNSBieXRlcykNCjkwMzkz OCgyIG1vZCAyNTYpOiBNQVBXUklURSAweDEyMGFlIHRocnUgMHgxMzUyOAko MHgxNDdiIGJ5dGVzKQ0KOTAzOTM5KDMgbW9kIDI1Nik6IE1BUFJFQUQJMHgz Nzk3YSB0aHJ1IDB4M2JlZWIJKDB4NDU3MiBieXRlcykNCjkwMzk0MCg0IG1v ZCAyNTYpOiBUUlVOQ0FURSBET1dOCWZyb20gMHg0MDAwMCB0byAweDJmZmQ2 DQo5MDM5NDEoNSBtb2QgMjU2KTogUkVBRAkweDljOTEgdGhydSAweDE1Mjcx CSgweGI1ZTEgYnl0ZXMpDQo5MDM5NDIoNiBtb2QgMjU2KTogTUFQV1JJVEUg MHgyMGJkZSB0aHJ1IDB4MmQwZWIJKDB4YzUwZSBieXRlcykNCjkwMzk0Myg3 IG1vZCAyNTYpOiBUUlVOQ0FURSBET1dOCWZyb20gMHgyZmZkNiB0byAweDIy ODgwDQo5MDM5NDQoOCBtb2QgMjU2KTogTUFQV1JJVEUgMHgzN2NhMyB0aHJ1 IDB4M2I2ODgJKDB4MzllNiBieXRlcykNCjkwMzk0NSg5IG1vZCAyNTYpOiBS RUFECTB4MWRiODYgdGhydSAweDIzMmMxCSgweDU3M2MgYnl0ZXMpDQo5MDM5 NDYoMTAgbW9kIDI1Nik6IFRSVU5DQVRFIFVQCWZyb20gMHgzYjY4OSB0byAw eDNjNmZjDQo5MDM5NDcoMTEgbW9kIDI1Nik6IE1BUFdSSVRFIDB4ODU5IHRo cnUgMHgxMDhiCSgweDgzMyBieXRlcykNCjkwMzk0OCgxMiBtb2QgMjU2KTog V1JJVEUJMHgzZWFjMyB0aHJ1IDB4M2ZmZmYJKDB4MTUzZCBieXRlcykgSE9M RQ0KOTAzOTQ5KDEzIG1vZCAyNTYpOiBUUlVOQ0FURSBET1dOCWZyb20gMHg0 MDAwMCB0byAweDdhYmYNCjkwMzk1MCgxNCBtb2QgMjU2KTogVFJVTkNBVEUg VVAJZnJvbSAweDdhYmYgdG8gMHgzNjBlYw0KOTAzOTUxKDE1IG1vZCAyNTYp OiBNQVBXUklURSAweDNlMGFjIHRocnUgMHgzZTFmNgkoMHgxNGIgYnl0ZXMp DQo5MDM5NTIoMTYgbW9kIDI1Nik6IFJFQUQJMHg5Y2MyIHRocnUgMHhmNjgz CSgweDU5YzIgYnl0ZXMpDQo5MDM5NTMoMTcgbW9kIDI1Nik6IFRSVU5DQVRF IFVQCWZyb20gMHgzZTFmNyB0byAweDNlYzA2DQo5MDM5NTQoMTggbW9kIDI1 Nik6IFdSSVRFCTB4MzYwMmMgdGhydSAweDNmZmZmCSgweDlmZDQgYnl0ZXMp IEVYVEVORA0KOTAzOTU1KDE5IG1vZCAyNTYpOiBNQVBXUklURSAweDk1NDgg dGhydSAweDEyNGM1CSgweDhmN2UgYnl0ZXMpDQo5MDM5NTYoMjAgbW9kIDI1 Nik6IE1BUFJFQUQJMHgxMDc1NSB0aHJ1IDB4MWUzZDAJKDB4ZGM3YyBieXRl cykNCjkwMzk1NygyMSBtb2QgMjU2KTogTUFQUkVBRAkweDMzZTExIHRocnUg MHgzNzc0NgkoMHgzOTM2IGJ5dGVzKQ0KOTAzOTU4KDIyIG1vZCAyNTYpOiBU UlVOQ0FURSBET1dOCWZyb20gMHg0MDAwMCB0byAweDNjMGRlDQo5MDM5NTko MjMgbW9kIDI1Nik6IFRSVU5DQVRFIERPV04JZnJvbSAweDNjMGRlIHRvIDB4 MWU2OGUNCjkwMzk2MCgyNCBtb2QgMjU2KTogTUFQUkVBRAkweDE4ZDA1IHRo cnUgMHgxYjY3YgkoMHgyOTc3IGJ5dGVzKQ0KOTAzOTYxKDI1IG1vZCAyNTYp OiBNQVBSRUFECTB4MmFmNyB0aHJ1IDB4YzU0MwkoMHg5YTRkIGJ5dGVzKQ0K OTAzOTYyKDI2IG1vZCAyNTYpOiBNQVBXUklURSAweDNmN2JmIHRocnUgMHgz ZmZmZgkoMHg4NDEgYnl0ZXMpDQo5MDM5NjMoMjcgbW9kIDI1Nik6IE1BUFdS SVRFIDB4MTQwNGUgdGhydSAweDFjZjM2CSgweDhlZTkgYnl0ZXMpDQo5MDM5 NjQoMjggbW9kIDI1Nik6IE1BUFJFQUQJMHgyYmJmMiB0aHJ1IDB4MzZmOTUJ KDB4YjNhNCBieXRlcykNCjkwMzk2NSgyOSBtb2QgMjU2KTogV1JJVEUJMHgx Zjk5ZCB0aHJ1IDB4MjU3ODYJKDB4NWRlYSBieXRlcykNCjkwMzk2NigzMCBt b2QgMjU2KTogV1JJVEUJMHgyNGNmIHRocnUgMHgxMDVmOAkoMHhlMTJhIGJ5 dGVzKQ0KOTAzOTY3KDMxIG1vZCAyNTYpOiBNQVBXUklURSAweDM0NTQ4IHRo cnUgMHgzZGM4NQkoMHg5NzNlIGJ5dGVzKQ0KOTAzOTY4KDMyIG1vZCAyNTYp OiBNQVBXUklURSAweDI5NWNkIHRocnUgMHgyZGVhYgkoMHg0OGRmIGJ5dGVz KQ0KOTAzOTY5KDMzIG1vZCAyNTYpOiBNQVBSRUFECTB4MjllZTYgdGhydSAw eDM1MmUyCSgweGIzZmQgYnl0ZXMpDQo5MDM5NzAoMzQgbW9kIDI1Nik6IE1B UFJFQUQJMHgxNDFjMSB0aHJ1IDB4MWI3ODAJKDB4NzVjMCBieXRlcykNCjkw Mzk3MSgzNSBtb2QgMjU2KTogVFJVTkNBVEUgRE9XTglmcm9tIDB4NDAwMDAg dG8gMHgxNWQ4OA0KOTAzOTcyKDM2IG1vZCAyNTYpOiBSRUFECTB4M2JlMiB0 aHJ1IDB4NmNjYQkoMHgzMGU5IGJ5dGVzKQ0KOTAzOTczKDM3IG1vZCAyNTYp OiBNQVBXUklURSAweDEwNDVjIHRocnUgMHgxOWZkOAkoMHg5YjdkIGJ5dGVz KQ0KOTAzOTc0KDM4IG1vZCAyNTYpOiBSRUFECTB4ZDA3ZiB0aHJ1IDB4MTNm MDIJKDB4NmU4NCBieXRlcykNCjkwMzk3NSgzOSBtb2QgMjU2KTogUkVBRAkw eDE2NTRmIHRocnUgMHgxOWZkOAkoMHgzYThhIGJ5dGVzKQ0KOTAzOTc2KDQw IG1vZCAyNTYpOiBUUlVOQ0FURSBET1dOCWZyb20gMHgxOWZkOSB0byAweDgw ZDQNCjkwMzk3Nyg0MSBtb2QgMjU2KTogVFJVTkNBVEUgVVAJZnJvbSAweDgw ZDQgdG8gMHgxY2FmNg0KOTAzOTc4KDQyIG1vZCAyNTYpOiBSRUFECTB4MTdi ZTEgdGhydSAweDFjYWY1CSgweDRmMTUgYnl0ZXMpDQo5MDM5NzkoNDMgbW9k IDI1Nik6IFJFQUQJMHhlYTQ0IHRocnUgMHgxODk3ZAkoMHg5ZjNhIGJ5dGVz KQ0KOTAzOTgwKDQ0IG1vZCAyNTYpOiBNQVBXUklURSAweGI1NzUgdGhydSAw eGYwNDUJKDB4M2FkMSBieXRlcykNCjkwMzk4MSg0NSBtb2QgMjU2KTogTUFQ V1JJVEUgMHg0ZjQyIHRocnUgMHgxM2JjMAkoMHhlYzdmIGJ5dGVzKQ0KOTAz OTgyKDQ2IG1vZCAyNTYpOiBUUlVOQ0FURSBET1dOCWZyb20gMHgxY2FmNiB0 byAweDFhNjI5DQo5MDM5ODMoNDcgbW9kIDI1Nik6IFdSSVRFCTB4MTY3ODcg dGhydSAweDFjZjcwCSgweDY3ZWEgYnl0ZXMpIEVYVEVORA0KOTAzOTg0KDQ4 IG1vZCAyNTYpOiBNQVBSRUFECTB4ZjIyMiB0aHJ1IDB4MWFmODIJKDB4YmQ2 MSBieXRlcykNCjkwMzk4NSg0OSBtb2QgMjU2KTogTUFQV1JJVEUgMHgxZDNk NyB0aHJ1IDB4MmJiNjQJKDB4ZTc4ZSBieXRlcykNCjkwMzk4Nig1MCBtb2Qg MjU2KTogTUFQUkVBRAkweDFmYTRhIHRocnUgMHgyM2ZiYwkoMHg0NTczIGJ5 dGVzKQ0KOTAzOTg3KDUxIG1vZCAyNTYpOiBUUlVOQ0FURSBET1dOCWZyb20g MHgyYmI2NSB0byAweDJhODhlDQo5MDM5ODgoNTIgbW9kIDI1Nik6IFdSSVRF CTB4MjVlZmEgdGhydSAweDJhOTU5CSgweDRhNjAgYnl0ZXMpIEVYVEVORA0K OTAzOTg5KDUzIG1vZCAyNTYpOiBNQVBSRUFECTB4MjBkNDEgdGhydSAweDI0 ZWZjCSgweDQxYmMgYnl0ZXMpDQo5MDM5OTAoNTQgbW9kIDI1Nik6IFJFQUQJ MHgzNzkyIHRocnUgMHhlNmFjCSgweGFmMWIgYnl0ZXMpDQo5MDM5OTEoNTUg bW9kIDI1Nik6IFJFQUQJMHgxMWJiMyB0aHJ1IDB4MTUxNWMJKDB4MzVhYSBi eXRlcykNCjkwMzk5Mig1NiBtb2QgMjU2KTogTUFQUkVBRAkweGFhMTggdGhy dSAweGZlZTkJKDB4NTRkMiBieXRlcykNCjkwMzk5Myg1NyBtb2QgMjU2KTog VFJVTkNBVEUgRE9XTglmcm9tIDB4MmE5NWEgdG8gMHgxN2FmNA0KOTAzOTk0 KDU4IG1vZCAyNTYpOiBNQVBSRUFECTB4MTYxNDYgdGhydSAweDE2NDJhCSgw eDJlNSBieXRlcykNCjkwMzk5NSg1OSBtb2QgMjU2KTogTUFQV1JJVEUgMHgx NDk1YSB0aHJ1IDB4MjM2OWEJKDB4ZWQ0MSBieXRlcykNCjkwMzk5Nig2MCBt b2QgMjU2KTogV1JJVEUJMHgyMzA0YSB0aHJ1IDB4MzI0YmYJKDB4ZjQ3NiBi eXRlcykgRVhURU5EDQo5MDM5OTcoNjEgbW9kIDI1Nik6IE1BUFdSSVRFIDB4 ODA2NCB0aHJ1IDB4MTJkYjkJKDB4YWQ1NiBieXRlcykNCjkwMzk5OCg2MiBt b2QgMjU2KTogUkVBRAkweDJkYjJmIHRocnUgMHgzMjRiZgkoMHg0OTkxIGJ5 dGVzKQ0KOTAzOTk5KDYzIG1vZCAyNTYpOiBNQVBXUklURSAweDJlZDc5IHRo cnUgMHgzYTIxMwkoMHhiNDliIGJ5dGVzKQ0KOTA0MDAwKDY0IG1vZCAyNTYp OiBUUlVOQ0FURSBET1dOCWZyb20gMHgzYTIxNCB0byAweGY2OTENCjkwMzAw MSg4OSBtb2QgMjU2KTogV1JJVEUJMHgyMjg0YSB0aHJ1IDB4MmZlOGQJKDB4 ZDY0NCBieXRlcykgSE9MRQ0KOTAzMDAyKDkwIG1vZCAyNTYpOiBSRUFECTB4 YjQ2NSB0aHJ1IDB4MTM1MDkJKDB4ODBhNSBieXRlcykNCjkwMzAwMyg5MSBt b2QgMjU2KTogTUFQV1JJVEUgMHhkMGVkIHRocnUgMHgxMzBhYQkoMHg1ZmJl IGJ5dGVzKQ0KOTAzMDA0KDkyIG1vZCAyNTYpOiBSRUFECTB4OTEzZSB0aHJ1 IDB4MTFkNmMJKDB4OGMyZiBieXRlcykNCjkwMzAwNSg5MyBtb2QgMjU2KTog V1JJVEUJMHgzNzFlIHRocnUgMHhmMjJkCSgweGJiMTAgYnl0ZXMpDQo5MDMw MDYoOTQgbW9kIDI1Nik6IFdSSVRFCTB4MWNmOWQgdGhydSAweDFkZmNmCSgw eDEwMzMgYnl0ZXMpDQo5MDMwMDcoOTUgbW9kIDI1Nik6IFdSSVRFCTB4NTc5 YiB0aHJ1IDB4OTk0ZgkoMHg0MWI1IGJ5dGVzKQ0KOTAzMDA4KDk2IG1vZCAy NTYpOiBNQVBXUklURSAweDFmOWNiIHRocnUgMHgyYTlmZQkoMHhiMDM0IGJ5 dGVzKQ0KOTAzMDA5KDk3IG1vZCAyNTYpOiBNQVBXUklURSAweDJmN2VlIHRo cnUgMHgzNGQ0ZgkoMHg1NTYyIGJ5dGVzKQ0KOTAzMDEwKDk4IG1vZCAyNTYp OiBNQVBXUklURSAweGJhZiB0aHJ1IDB4ODg2ZAkoMHg3Y2JmIGJ5dGVzKQ0K OTAzMDExKDk5IG1vZCAyNTYpOiBNQVBSRUFECTB4M2I1YyB0aHJ1IDB4MTJm YTcJKDB4ZjQ0YyBieXRlcykNCjkwMzAxMigxMDAgbW9kIDI1Nik6IFRSVU5D QVRFIERPV04JZnJvbSAweDM0ZDUwIHRvIDB4MWIyZjINCjkwMzAxMygxMDEg bW9kIDI1Nik6IFRSVU5DQVRFIERPV04JZnJvbSAweDFiMmYyIHRvIDB4ZTIx DQo5MDMwMTQoMTAyIG1vZCAyNTYpOiBXUklURQkweDI1YjQwIHRocnUgMHgy YzNiMAkoMHg2ODcxIGJ5dGVzKSBIT0xFDQo5MDMwMTUoMTAzIG1vZCAyNTYp OiBUUlVOQ0FURSBVUAlmcm9tIDB4MmMzYjEgdG8gMHgzMGQ2Yg0KOTAzMDE2 KDEwNCBtb2QgMjU2KTogVFJVTkNBVEUgVVAJZnJvbSAweDMwZDZiIHRvIDB4 Mzc2MTkNCjkwMzAxNygxMDUgbW9kIDI1Nik6IE1BUFJFQUQJMHgyMTQyOCB0 aHJ1IDB4Mjk4ZGEJKDB4ODRiMyBieXRlcykNCjkwMzAxOCgxMDYgbW9kIDI1 Nik6IFRSVU5DQVRFIERPV04JZnJvbSAweDM3NjE5IHRvIDB4MzQ3YzENCjkw MzAxOSgxMDcgbW9kIDI1Nik6IE1BUFdSSVRFIDB4MzBhMzMgdGhydSAweDNk MzFmCSgweGM4ZWQgYnl0ZXMpDQo5MDMwMjAoMTA4IG1vZCAyNTYpOiBXUklU RQkweDM5NTYxIHRocnUgMHgzZmZmZgkoMHg2YTlmIGJ5dGVzKSBFWFRFTkQN CjkwMzAyMSgxMDkgbW9kIDI1Nik6IFRSVU5DQVRFIERPV04JZnJvbSAweDQw MDAwIHRvIDB4MjU1YTgNCjkwMzAyMigxMTAgbW9kIDI1Nik6IFRSVU5DQVRF IERPV04JZnJvbSAweDI1NWE4IHRvIDB4NTdkYg0KOTAzMDIzKDExMSBtb2Qg MjU2KTogTUFQUkVBRAkweDIzMDIgdGhydSAweDRjYWQJKDB4MjlhYyBieXRl cykNCjkwMzAyNCgxMTIgbW9kIDI1Nik6IE1BUFdSSVRFIDB4MjBiNDMgdGhy dSAweDJmMDQxCSgweGU0ZmYgYnl0ZXMpDQo5MDMwMjUoMTEzIG1vZCAyNTYp OiBUUlVOQ0FURSBVUAlmcm9tIDB4MmYwNDIgdG8gMHgzNWQ3Zg0KOTAzMDI2 KDExNCBtb2QgMjU2KTogTUFQV1JJVEUgMHgxMWZmYSB0aHJ1IDB4MWViNDgJ KDB4Y2I0ZiBieXRlcykNCjkwMzAyNygxMTUgbW9kIDI1Nik6IFdSSVRFCTB4 MTc5NGYgdGhydSAweDI2MmNlCSgweGU5ODAgYnl0ZXMpDQo5MDMwMjgoMTE2 IG1vZCAyNTYpOiBNQVBXUklURSAweDY2MGQgdGhydSAweDlkOGYJKDB4Mzc4 MyBieXRlcykNCjkwMzAyOSgxMTcgbW9kIDI1Nik6IFRSVU5DQVRFIFVQCWZy b20gMHgzNWQ3ZiB0byAweDM2Y2MyDQo5MDMwMzAoMTE4IG1vZCAyNTYpOiBS RUFECTB4MjcyY2IgdGhydSAweDJkOGQwCSgweDY2MDYgYnl0ZXMpDQo5MDMw MzEoMTE5IG1vZCAyNTYpOiBSRUFECTB4OGRhZCB0aHJ1IDB4MTFiMDYJKDB4 OGQ1YSBieXRlcykNCjkwMzAzMigxMjAgbW9kIDI1Nik6IFRSVU5DQVRFIERP V04JZnJvbSAweDM2Y2MyIHRvIDB4MTFmZjYNCjkwMzAzMygxMjEgbW9kIDI1 Nik6IFRSVU5DQVRFIFVQCWZyb20gMHgxMWZmNiB0byAweDMwOTQwDQo5MDMw MzQoMTIyIG1vZCAyNTYpOiBSRUFECTB4MjJiMjcgdGhydSAweDI5MmY4CSgw eDY3ZDIgYnl0ZXMpDQo5MDMwMzUoMTIzIG1vZCAyNTYpOiBSRUFECTB4Mjkw ODUgdGhydSAweDJjZmJjCSgweDNmMzggYnl0ZXMpDQo5MDMwMzYoMTI0IG1v ZCAyNTYpOiBNQVBXUklURSAweGRkNzMgdGhydSAweDExMGM5CSgweDMzNTcg Ynl0ZXMpDQo5MDMwMzcoMTI1IG1vZCAyNTYpOiBNQVBXUklURSAweDIzNDI5 IHRocnUgMHgzMWZiYgkoMHhlYjkzIGJ5dGVzKQ0KOTAzMDM4KDEyNiBtb2Qg MjU2KTogVFJVTkNBVEUgVVAJZnJvbSAweDMxZmJjIHRvIDB4MzQ2NGUNCjkw MzAzOSgxMjcgbW9kIDI1Nik6IE1BUFdSSVRFIDB4MzgzMzMgdGhydSAweDNm ZmZmCSgweDdjY2QgYnl0ZXMpDQo5MDMwNDAoMTI4IG1vZCAyNTYpOiBXUklU RQkweDM0MzA3IHRocnUgMHgzOTA1MwkoMHg0ZDRkIGJ5dGVzKQ0KOTAzMDQx KDEyOSBtb2QgMjU2KTogVFJVTkNBVEUgRE9XTglmcm9tIDB4NDAwMDAgdG8g MHgzZjZkMw0KOTAzMDQyKDEzMCBtb2QgMjU2KTogVFJVTkNBVEUgRE9XTglm cm9tIDB4M2Y2ZDMgdG8gMHgxM2NmYw0KOTAzMDQzKDEzMSBtb2QgMjU2KTog UkVBRAkweDVhN2IgdGhydSAweGMxOGQJKDB4NjcxMyBieXRlcykNCjkwMzA0 NCgxMzIgbW9kIDI1Nik6IE1BUFdSSVRFIDB4MzUyM2EgdGhydSAweDNlZjJi CSgweDljZjIgYnl0ZXMpDQo5MDMwNDUoMTMzIG1vZCAyNTYpOiBUUlVOQ0FU RSBET1dOCWZyb20gMHgzZWYyYyB0byAweDNhZWQwDQo5MDMwNDYoMTM0IG1v ZCAyNTYpOiBUUlVOQ0FURSBET1dOCWZyb20gMHgzYWVkMCB0byAweDMxZDAz DQo5MDMwNDcoMTM1IG1vZCAyNTYpOiBNQVBXUklURSAweDMwZTc1IHRocnUg MHgzZDc1YgkoMHhjOGU3IGJ5dGVzKQ0KOTAzMDQ4KDEzNiBtb2QgMjU2KTog TUFQV1JJVEUgMHgyMWRmOCB0aHJ1IDB4MzBjYzkJKDB4ZWVkMiBieXRlcykN CjkwMzA0OSgxMzcgbW9kIDI1Nik6IFJFQUQJMHgyMjk1NCB0aHJ1IDB4Mjkz NTcJKDB4NmEwNCBieXRlcykNCjkwMzA1MCgxMzggbW9kIDI1Nik6IFRSVU5D QVRFIFVQCWZyb20gMHgzZDc1YyB0byAweDNlZWJiDQo5MDMwNTEoMTM5IG1v ZCAyNTYpOiBUUlVOQ0FURSBET1dOCWZyb20gMHgzZWViYiB0byAweDNkMDBk DQo5MDMwNTIoMTQwIG1vZCAyNTYpOiBSRUFECTB4MTdjZWQgdGhydSAweDI3 Y2QxCSgweGZmZTUgYnl0ZXMpDQo5MDMwNTMoMTQxIG1vZCAyNTYpOiBUUlVO Q0FURSBET1dOCWZyb20gMHgzZDAwZCB0byAweDM0ZWY3DQo5MDMwNTQoMTQy IG1vZCAyNTYpOiBNQVBSRUFECTB4MmQwMWIgdGhydSAweDMzMGIzCSgweDYw OTkgYnl0ZXMpDQo5MDMwNTUoMTQzIG1vZCAyNTYpOiBNQVBXUklURSAweDM4 NzZjIHRocnUgMHgzZmZmZgkoMHg3ODk0IGJ5dGVzKQ0KOTAzMDU2KDE0NCBt b2QgMjU2KTogUkVBRAkweDFmYjc4IHRocnUgMHgyODI1OQkoMHg4NmUyIGJ5 dGVzKQ0KOTAzMDU3KDE0NSBtb2QgMjU2KTogTUFQV1JJVEUgMHgxYmZjNiB0 aHJ1IDB4MWM2ODcJKDB4NmMyIGJ5dGVzKQ0KOTAzMDU4KDE0NiBtb2QgMjU2 KTogTUFQV1JJVEUgMHgxZGViNSB0aHJ1IDB4MWU3NGMJKDB4ODk4IGJ5dGVz KQ0KOTAzMDU5KDE0NyBtb2QgMjU2KTogUkVBRAkweDMyNTQgdGhydSAweGJh NGQJKDB4ODdmYSBieXRlcykNCjkwMzA2MCgxNDggbW9kIDI1Nik6IFJFQUQJ MHgxZTcxNSB0aHJ1IDB4MjM4MmQJKDB4NTExOSBieXRlcykNCjkwMzA2MSgx NDkgbW9kIDI1Nik6IE1BUFdSSVRFIDB4M2VkNmEgdGhydSAweDNmZmZmCSgw eDEyOTYgYnl0ZXMpDQo5MDMwNjIoMTUwIG1vZCAyNTYpOiBUUlVOQ0FURSBE T1dOCWZyb20gMHg0MDAwMCB0byAweGQ1NDgNCjkwMzA2MygxNTEgbW9kIDI1 Nik6IFdSSVRFCTB4ZDlkNSB0aHJ1IDB4MTRhMzYJKDB4NzA2MiBieXRlcykg SE9MRQ0KOTAzMDY0KDE1MiBtb2QgMjU2KTogV1JJVEUJMHgxZTM1MiB0aHJ1 IDB4MjNlN2YJKDB4NWIyZSBieXRlcykgSE9MRQ0KOTAzMDY1KDE1MyBtb2Qg MjU2KTogTUFQUkVBRAkweDFkOWRjIHRocnUgMHgyM2U3ZgkoMHg2NGE0IGJ5 dGVzKQ0KOTAzMDY2KDE1NCBtb2QgMjU2KTogTUFQV1JJVEUgMHgyZDRhIHRo cnUgMHg2OTgxCSgweDNjMzggYnl0ZXMpDQo5MDMwNjcoMTU1IG1vZCAyNTYp OiBSRUFECTB4MTJlMzkgdGhydSAweDE3OGZmCSgweDRhYzcgYnl0ZXMpDQo5 MDMwNjgoMTU2IG1vZCAyNTYpOiBXUklURQkweDNiMTU5IHRocnUgMHgzZmZm ZgkoMHg0ZWE3IGJ5dGVzKSBIT0xFDQo5MDMwNjkoMTU3IG1vZCAyNTYpOiBU UlVOQ0FURSBET1dOCWZyb20gMHg0MDAwMCB0byAweDM2NWJmDQo5MDMwNzAo MTU4IG1vZCAyNTYpOiBNQVBXUklURSAweDE4N2FmIHRocnUgMHgxOTVhYQko MHhkZmMgYnl0ZXMpDQo5MDMwNzEoMTU5IG1vZCAyNTYpOiBSRUFECTB4Mjlk NiB0aHJ1IDB4ZGE4NwkoMHhiMGIyIGJ5dGVzKQ0KOTAzMDcyKDE2MCBtb2Qg MjU2KTogVFJVTkNBVEUgRE9XTglmcm9tIDB4MzY1YmYgdG8gMHgzNTk5NQ0K OTAzMDczKDE2MSBtb2QgMjU2KTogVFJVTkNBVEUgRE9XTglmcm9tIDB4MzU5 OTUgdG8gMHgyMTcxMg0KOTAzMDc0KDE2MiBtb2QgMjU2KTogUkVBRAkweDFh NTkyIHRocnUgMHgyMTcxMQkoMHg3MTgwIGJ5dGVzKQ0KOTAzMDc1KDE2MyBt b2QgMjU2KTogV1JJVEUJMHgxZDFiYSB0aHJ1IDB4MjY4MzcJKDB4OTY3ZSBi eXRlcykgRVhURU5EDQo5MDMwNzYoMTY0IG1vZCAyNTYpOiBNQVBSRUFECTB4 MSB0aHJ1IDB4NmIxYwkoMHg2YjFjIGJ5dGVzKQkqKipSUlJSKioqDQpDb3Jy ZWN0IGNvbnRlbnQgc2F2ZWQgZm9yIGNvbXBhcmlzb24NCihtYXliZSBoZXhk dW1wICJib29tIiB2cyAiYm9vbS5mc3hnb29kIikNCg== --1679311850-516486818-1010361493=:2424-- From owner-linux-xfs@oss.sgi.com Sun Jan 6 19:16:18 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g073GIv24464 for linux-xfs-outgoing; Sun, 6 Jan 2002 19:16:18 -0800 Received: from zok.sgi.com (zok.SGI.COM [204.94.215.101]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g073GCg24439 for ; Sun, 6 Jan 2002 19:16:12 -0800 Received: from sherman.melbourne.sgi.com (sherman.melbourne.sgi.com [134.14.55.232]) by zok.sgi.com (8.11.4/8.11.4/linux-outbound_gateway-1.1) with ESMTP id g072G3A06912 for ; Sun, 6 Jan 2002 18:16:04 -0800 Received: (from kaos@localhost) by sherman.melbourne.sgi.com (8.11.6/8.11.6) id g072G2h14740; Mon, 7 Jan 2002 13:16:02 +1100 Date: Mon, 7 Jan 2002 13:16:02 +1100 From: Keith Owens Message-Id: <200201070216.g072G2h14740@sherman.melbourne.sgi.com> Subject: TAKE - Remove dummy kdb files for all architectures except i386 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 1300 Lines: 34 The 2.4.x-xfs tree contains kdb common code plus the arch dependent kdb code for i386 only. For historical reasons it also contained dummy files for other architectures, including ia64. This is now causing problems for ia64, remove all the dummy kdb files, leaving just i386. To get XFS+KDB on another architecture, use this tree and apply the kdb patch for that architecture. The common kdb code is already in the XFS tree, current version is kdb-v2.0-2.4.17-common-2. The XFS tree should compile on architectures without kdb support. Date: Sun Jan 6 18:08:50 PST 2002 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:109148a linux/include/asm-sparc64/fcntl.h - 1.14 linux/include/asm-alpha/kdb.h - 1.3 linux/include/asm-arm/kdb.h - 1.3 linux/include/asm-generic/kdb.h - 1.3 linux/include/asm-ia64/kdb.h - 1.5 linux/include/asm-m68k/kdb.h - 1.3 linux/include/asm-mips/kdb.h - 1.3 linux/include/asm-mips64/kdb.h - 1.3 linux/include/asm-ppc/kdb.h - 1.3 linux/include/asm-s390/kdb.h - 1.3 linux/include/asm-sh/kdb.h - 1.3 linux/include/asm-sparc/kdb.h - 1.3 linux/include/asm-sparc64/kdb.h - 1.3 linux/include/asm-ia64/kdbprivate.h - 1.4 linux/include/asm-um/kdb.h - 1.2 From owner-linux-xfs@oss.sgi.com Sun Jan 6 19:18:07 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g073I7D24615 for linux-xfs-outgoing; Sun, 6 Jan 2002 19:18:07 -0800 Received: from sgi.com (sgi-too.SGI.COM [204.94.211.39]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g073I2g24592 for ; Sun, 6 Jan 2002 19:18:02 -0800 Received: from sherman.melbourne.sgi.com (sherman.melbourne.sgi.com [134.14.55.232]) by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id SAA03793 for ; Sun, 6 Jan 2002 18:16:17 -0800 (PST) mail_from (kaos@sherman.melbourne.sgi.com) Received: (from kaos@localhost) by sherman.melbourne.sgi.com (8.11.6/8.11.6) id g072Htm14818; Mon, 7 Jan 2002 13:17:55 +1100 Date: Mon, 7 Jan 2002 13:17:55 +1100 From: Keith Owens Message-Id: <200201070217.g072Htm14818@sherman.melbourne.sgi.com> Subject: TAKE - Remove patch that overlaps with main kbuild 2.5 patch Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 340 Lines: 13 A fragment of the main kbuild 2.5 patch had crept into XFS, causing duplicate patches. Date: Sun Jan 6 18:15:08 PST 2002 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:109149a linux/include/linux/module.h - 1.30 From owner-linux-xfs@oss.sgi.com Sun Jan 6 19:42:40 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g073geE25098 for linux-xfs-outgoing; Sun, 6 Jan 2002 19:42:40 -0800 Received: from deliverator.sgi.com (deliverator.sgi.com [204.94.214.10]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g073gcg25075 for ; Sun, 6 Jan 2002 19:42:38 -0800 Received: from sherman.melbourne.sgi.com (sherman.melbourne.sgi.com [134.14.55.232]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id SAA19161 for ; Sun, 6 Jan 2002 18:42:19 -0800 (PST) mail_from (kaos@sherman.melbourne.sgi.com) Received: (from kaos@localhost) by sherman.melbourne.sgi.com (8.11.6/8.11.6) id g072gYQ16704; Mon, 7 Jan 2002 13:42:34 +1100 Date: Mon, 7 Jan 2002 13:42:34 +1100 From: Keith Owens Message-Id: <200201070242.g072gYQ16704@sherman.melbourne.sgi.com> Subject: TAKE - Remove RCS identifiers from kallsyms Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 284 Lines: 11 Date: Sun Jan 6 18:40:29 PST 2002 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:109150a linux/kernel/kallsyms.c - 1.12 linux/include/linux/kallsyms.h - 1.9 From owner-linux-xfs@oss.sgi.com Mon Jan 7 01:23:36 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g079NaS29458 for linux-xfs-outgoing; Mon, 7 Jan 2002 01:23:36 -0800 Received: from tiny.int.franksintl.nl (goblin.franksintl.nl [195.193.231.154]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g079NVg29436 for ; Mon, 7 Jan 2002 01:23:32 -0800 Received: from cp35 ([192.168.4.140]) by tiny.int.franksintl.nl (8.11.4/8.11.4/Debian 8.9.3-21) with ESMTP id g078JI911007 for ; Mon, 7 Jan 2002 09:19:18 +0100 From: "Ries van Twisk" To: Date: Mon, 7 Jan 2002 09:19:11 +0100 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Subject: XFS testing on my server Reply-to: ries@franksintl.nl Message-ID: <3C39680F.20748.DD9CEBF@localhost> X-mailer: Pegasus Mail for Win32 (v3.12c) Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 442 Lines: 13 Hi XFS users, I have a XFS enabled kernel (linux 2.4.14, gcc 2.95.2) working on my production server and I'm currently installing almost the same configuration on a new server. That will be Linux 2.4.17 gcc 2.95.2. My production server seems to be stable but it has a low load (25 Samba users) and now I want to stress tes the new server to see if it's stable for production. Is there any tool out there to test stabilty of XFS? Ries From owner-linux-xfs@oss.sgi.com Mon Jan 7 01:33:07 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g079X7H29855 for linux-xfs-outgoing; Mon, 7 Jan 2002 01:33:07 -0800 Received: from quasar.sif.it (IDENT:root@quasar.sif.it [131.154.110.3]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g079X1g29831 for ; Mon, 7 Jan 2002 01:33:01 -0800 Received: from localhost (matteo@localhost) by quasar.sif.it (8.11.6/8.11.6) with ESMTP id g078X8Z28391 for ; Mon, 7 Jan 2002 09:33:08 +0100 Date: Mon, 7 Jan 2002 09:33:08 +0100 (CET) From: Matteo Centonza To: Subject: xfsdump assertion failure Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 1039 Lines: 33 Hi, these are the logs from last incremental dump through amanda: FAIL dumper embeh / 1 [/usr/sbin/xfsdump got signal 6] sendbackup: start [embeh:/ level 1] sendbackup: info BACKUP=/usr/sbin/xfsdump sendbackup: info RECOVER_CMD=/bin/gzip -dc |/usr/sbin/xfsrestore -f... - sendbackup: info COMPRESS_SUFFIX=.gz sendbackup: info end | xfsdump: version 3.0 - Running single-threaded | xfsdump: level 1 incremental dump of embeh.sif.it:/ based on level 0 dump begun Fri Jan 4 23:42:11 2002 | xfsdump: dump date: Sun Jan 6 20:04:26 2002 | xfsdump: session id: 387c506e-593f-471d-a227-53c37f845c94 | xfsdump: session label: "" | xfsdump: ino map phase 1: skipping (no subtrees specified) | xfsdump: ino map phase 2: constructing initial dump list | xfsdump: ino map phase 3: pruning unneeded subtrees ? xfsdump: inomap.c:858: supprt_prune: Assertion `state != 2' failed. sendbackup: error [/usr/sbin/xfsdump got signal 6] 2.4.14-xfs-1 #2 Fri Nov 9 12:10:19 CET 2001 i686 unknown xfsdump-1.1.7-0 HTH, -m From owner-linux-xfs@oss.sgi.com Mon Jan 7 07:08:39 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g07F8dU14965 for linux-xfs-outgoing; Mon, 7 Jan 2002 07:08:39 -0800 Received: from mta06ps.bigpond.com (mta06ps.bigpond.com [144.135.25.138]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g07F8Pg14938 for ; Mon, 7 Jan 2002 07:08:25 -0800 Message-Id: <200201071508.g07F8Pg14938@oss.sgi.com> Received: from there ([144.135.25.87]) by mta06ps.bigpond.com (Netscape Messaging Server 4.15) with SMTP id GPKNLG00.GAV; Tue, 8 Jan 2002 00:15:16 +1000 Received: from CPE-144-137-138-230.qld.bigpond.net.au ([144.137.138.230]) by psmam07.mailsvc.email.bigpond.com(MailRouter V3.0h 125/338000); 08 Jan 2002 00:08:15 Content-Type: text/plain; charset="us-ascii" From: Adrian Head To: Eric Sandeen Subject: Re: Unable to get XFS, ext3, reiserfs & LVM to coexist happily Date: Tue, 8 Jan 2002 00:08:11 +1000 X-Mailer: KMail [version 1.3.1] Cc: Linux XFS Mailing List , References: In-Reply-To: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 5319 Lines: 119 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 This is the kdb output from trying to create a snapshot of an XFS volume when I have removed ext3 from my kernel. (For clarifcation - in all my previous tests ext3 was compiled into my kernel - in this test I did not select ext3 at all in menuconfig) The only other thing I have noticed is that when the original XFS logical volume is unmounted snapshot creation is fine. I'm not sure if this works on the other tests I have tried so I will go back and redo them. id %eip is weird. What does this really mean? looks like the instructions point nowhere. Am I correct? Entering kdb (current=0xd600e000, pid 940) Oops: Oops due to oops @ 0xb800 eax = 0xffffffff ebx = 0xd600e000 ecx = 0x0000b800 edx = 0xc018fd25 esi = 0x00000008 edi = 0xd600e000 esp = 0xd600ff0c eip = 0x0000b800 ebp = 0xd600ff30 xss = 0x00000018 xcs = 0x00000010 eflags = 0x00010086 xds = 0x00000018 xes = 0x00000018 origeax = 0xffffffff ®s = 0xd600fed8 kdb> bt EBP EIP Function(args) 0xd600ff30 0x0000b800 +0xb800 (0x1) kernel 0x0 0x0 0x0 0xc011ce83 dequeue_signal+0x43 (0xd600e560, 0xd600ff30, 0xd600e560, 0xd600ffc4, 0xc01392ff) kernel .text 0xc0100000 0xc011ce40 0xc011cef0 0xc01069b9 do_signal+0x59 (0x11, 0xbfffec40, 0xbfffebb0, 0x8, 0x11) kernel .text 0xc0100000 0xc0106960 0xc0106c00 0xc0106d54 signal_return+0x14 kernel .text 0xc0100000 0xc0106d40 0xc0106d58 kdb> btp 940 EBP EIP Function(args) 0xc011ce83 0x0000b800 +0xb800 (0x1) kernel 0x0 0x0 0x0 0xc011ce83 dequeue_signal+0x43 (0xd600e560, 0xd600ff30, 0xd600e560, 0xd600ffc4, 0xc01392ff) kernel .text 0xc0100000 0xc011ce40 0xc011cef0 0xc01069b9 do_signal+0x59 (0x11, 0xbfffec40, 0xbfffebb0, 0x8, 0x11) kernel .text 0xc0100000 0xc0106960 0xc0106c00 0xc0106d54 signal_return+0x14 kernel .text 0xc0100000 0xc0106d40 0xc0106d58 kdb> ps Task Addr Pid Parent [*] cpu State Thread Command 0xd7fe2000 00000001 00000000 1 000 stop 0xd7fe2270 init 0xc163c000 00000002 00000001 1 000 stop 0xc163c270 keventd 0xc1638000 00000003 00000000 1 000 stop 0xc1638270 ksoftirqd_CPU0 0xc1636000 00000004 00000000 1 000 stop 0xc1636270 kswapd 0xc1634000 00000005 00000000 1 000 stop 0xc1634270 bdflush 0xc1632000 00000006 00000000 1 000 stop 0xc1632270 kupdated 0xd7ec4000 00000007 00000001 1 000 stop 0xd7ec4270 mdrecoveryd 0xd7eae000 00000008 00000001 1 000 stop 0xd7eae270 raid5d 0xd7228000 00000156 00000001 1 000 stop 0xd7228270 kreiserfsd 0xd7022000 00000159 00000001 1 000 stop 0xd7022270 pagebuf_daemon 0xd630c000 00000522 00000001 1 000 stop 0xd630c270 dhcpcd 0xd6fce000 00000658 00000001 1 000 stop 0xd6fce270 syslogd 0xd630a000 00000663 00000001 1 000 stop 0xd630a270 klogd 0xd61a2000 00000683 00000001 1 000 stop 0xd61a2270 portmap 0xd617c000 00000711 00000001 1 000 stop 0xd617c270 rpc.statd 0xd6108000 00000823 00000001 1 000 stop 0xd6108270 crond 0xd651c000 00000860 00000001 1 000 stop 0xd651c270 atd 0xd7986000 00000867 00000001 1 000 stop 0xd7986270 login 0xd627a000 00000868 00000001 1 000 stop 0xd627a270 mingetty 0xd6194000 00000869 00000001 1 000 stop 0xd6194270 mingetty 0xd613e000 00000870 00000001 1 000 stop 0xd613e270 mingetty more> 0xd6400000 00000871 00000001 1 000 stop 0xd6400270 mingetty 0xd60e4000 00000872 00000001 1 000 stop 0xd60e4270 mingetty 0xd6284000 00000873 00000001 1 000 stop 0xd6284270 mgetty 0xd67f2000 00000876 00000867 1 000 stop 0xd67f2270 bash 0xd600e000 00000940 00000876 1 000 run 0xd600e270*lvcreate kdb> id %eip 0xb800: kdb: Bad user address 0xb800 add %al,(%eax) 0xb802: add %al,(%eax) 0xb804: add %al,(%eax) 0xb806: add %al,(%eax) 0xb808: add %al,(%eax) 0xb80a: add %al,(%eax) 0xb80c: add %al,(%eax) 0xb80e: add %al,(%eax) 0xb810: add %al,(%eax) 0xb812: add %al,(%eax) 0xb814: add %al,(%eax) 0xb816: add %al,(%eax) 0xb818: add %al,(%eax) 0xb81a: add %al,(%eax) 0xb81c: add %al,(%eax) 0xb81e: add %al,(%eax) kdb> go Oops: 0000 CPU: 0 EIP: 0010:[<0000b800>] Not tainted EFLAGS: 00010086 eax: ffffffff ebx: d600e000 ecx: 0000b800 edx: c018fd25 esi: 00000008 edi: d600e000 ebp: d600ff30 esp: d600ff0c ds: 0018 es: 0018 ss: 0018 Process lvcreate (pid: 940, stackpage=d600f000) Stack: c011ce83 00000001 00000000 00000008 c01069b9 d600e560 d600ff30 d600e560 d600ffc4 c01392ff 00000282 d604ab40 d600e000 00000011 c1672144 c011de97 00000011 d600e568 00000000 d600ff70 d600ffa4 c011e252 00000011 d600ff90 Call Trace: [] [] [] [] [] [] Code: Bad EIP value. - -- Adrian Head (Public Key available on request.) -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE8OavO8ZJI8OvSkAcRAlktAJ0Uyq3AyRtrrBDkxe5oszt+wrbjAwCfU+wC w9VQ0Hb8tpt8qmCTsM+gJDk= =5Vw0 -----END PGP SIGNATURE----- From owner-linux-xfs@oss.sgi.com Mon Jan 7 07:42:19 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g07FgJc15740 for linux-xfs-outgoing; Mon, 7 Jan 2002 07:42:19 -0800 Received: from mail.ocs.com.au (mail.ocs.com.au [203.34.97.2]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g07Fg8g15713 for ; Mon, 7 Jan 2002 07:42:08 -0800 Received: (qmail 29614 invoked from network); 7 Jan 2002 14:42:03 -0000 Received: from ocs3.intra.ocs.com.au (192.168.255.3) by mail.ocs.com.au with SMTP; 7 Jan 2002 14:42:03 -0000 Received: by ocs3.intra.ocs.com.au (Postfix, from userid 16331) id 9B9D4300090; Tue, 8 Jan 2002 01:42:01 +1100 (EST) Received: from ocs3.intra.ocs.com.au (localhost [127.0.0.1]) by ocs3.intra.ocs.com.au (Postfix) with ESMTP id 3BE8394; Tue, 8 Jan 2002 01:42:00 +1100 (EST) X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 From: Keith Owens To: Adrian Head Cc: Linux XFS Mailing List , linux-lvm@sistina.com Subject: Re: Unable to get XFS, ext3, reiserfs & LVM to coexist happily In-reply-to: Your message of "Tue, 08 Jan 2002 00:08:11 +1000." <200201071508.g07F8Pg14938@oss.sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 08 Jan 2002 01:41:55 +1100 Message-ID: <30503.1010414515@ocs3.intra.ocs.com.au> Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 3648 Lines: 84 On Tue, 8 Jan 2002 00:08:11 +1000, Adrian Head wrote: >This is the kdb output from trying to create a snapshot of an XFS volume when >I have removed ext3 from my kernel. (For clarifcation - in all my previous >tests ext3 was compiled into my kernel - in this test I did not select ext3 >at all in menuconfig) > >The only other thing I have noticed is that when the original XFS logical >volume is unmounted snapshot creation is fine. I'm not sure if this works on >the other tests I have tried so I will go back and redo them. > >id %eip is weird. What does this really mean? looks like the instructions >point nowhere. Am I correct? > >Entering kdb (current=0xd600e000, pid 940) Oops: Oops >due to oops @ 0xb800 >eax = 0xffffffff ebx = 0xd600e000 ecx = 0x0000b800 edx = 0xc018fd25 >esi = 0x00000008 edi = 0xd600e000 esp = 0xd600ff0c eip = 0x0000b800 >ebp = 0xd600ff30 xss = 0x00000018 xcs = 0x00000010 eflags = 0x00010086 >xds = 0x00000018 xes = 0x00000018 origeax = 0xffffffff ®s = 0xd600fed8 >kdb> bt > EBP EIP Function(args) >0xd600ff30 0x0000b800 +0xb800 (0x1) > kernel 0x0 0x0 0x0 > 0xc011ce83 dequeue_signal+0x43 (0xd600e560, 0xd600ff30, >0xd600e560, 0xd600ffc4, 0xc01392ff) > kernel .text 0xc0100000 0xc011ce40 0xc011cef0 > 0xc01069b9 do_signal+0x59 (0x11, 0xbfffec40, 0xbfffebb0, 0x8, 0x11) > kernel .text 0xc0100000 0xc0106960 0xc0106c00 > 0xc0106d54 signal_return+0x14 > kernel .text 0xc0100000 0xc0106d40 0xc0106d58 kdb is correctly reporting the current eip, but the kernel has taken a swan dive into nowhere. It looks like the chunk of code below. To confirm, run objdump --start-addr=0xc011ce40 --stop-address=0xc011ce90 vmlinux I expect to see a call instruction just before 0xc011ce83, probably an indirect call via ecx. dequeue_signal(sigset_t *mask, siginfo_t *info) { int sig = 0; #if DEBUG_SIG printk("SIG dequeue (%s:%d): %d ", current->comm, current->pid, signal_pending(current)); #endif sig = next_signal(current, mask); if (sig) { if (current->notifier) { if (sigismember(current->notifier_mask, sig)) { if (!(current->notifier)(current->notifier_data)) { <=== probably failing here current->sigpending = 0; return 0; } Without seeing the objdump output, I am assuming that it is failing on the call to current->notifier which means that notifier is corrupt. The only place that notifier is set is in block_all_signals() so we need to find who is calling that routine with bad data. With any luck, this (untested) debug patch will catch the offender. Then we start finding out why it is passing a bad pointer. --- kernel/signal.c.orig Wed Dec 5 13:15:50 2001 +++ kernel/signal.c Tue Jan 8 01:28:12 2002 @@ -155,6 +155,8 @@ block_all_signals(int (*notifier)(void * { unsigned long flags; + if (notifier && (unsigned long)notifier < 0xc0000000) + BUG(); spin_lock_irqsave(¤t->sigmask_lock, flags); current->notifier_mask = mask; current->notifier_data = priv; A quick scan through the kernel found only DRM code using block_all_signals. If the bug is a bad notifier then the oops will be timing dependent, the notifier routine is only called if a signal trips between block_all_signals() and unblock_all_signals() and that does not always occur. From owner-linux-xfs@oss.sgi.com Mon Jan 7 08:43:50 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g07Gho817088 for linux-xfs-outgoing; Mon, 7 Jan 2002 08:43:50 -0800 Received: from deliverator.sgi.com (deliverator.sgi.com [204.94.214.10]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g07Ghlg17065 for ; Mon, 7 Jan 2002 08:43:47 -0800 Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id HAA08796 for ; Mon, 7 Jan 2002 07:43:29 -0800 (PST) mail_from (roehrich@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id JAA4024850; Mon, 7 Jan 2002 09:42:28 -0600 (CST) Received: from slobber.americas.sgi.com (slobber.americas.sgi.com [128.162.187.52]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id JAA24978; Mon, 7 Jan 2002 09:42:28 -0600 (CST) Received: from slobber.americas.sgi.com by slobber.americas.sgi.com (SGI-8.9.3/SGI-client-1.7) via ESMTP id JAA48017; Mon, 7 Jan 2002 09:42:27 -0600 (CST) Message-Id: <200201071542.JAA48017@slobber.americas.sgi.com> To: "James A Goodwin" cc: linux-xfs@oss.sgi.com Subject: Re: XFS DMAPI file I/O Date: Mon, 07 Jan 2002 09:42:27 -0600 From: Dean Roehrich Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 423 Lines: 13 >From: "James A Goodwin" >2. I just noticed that the DM_WRITE_SYNC flag is not supported for calls to >dm_write_invis(). This is a fairly critical piece of missing >functionality. Is there any chance this flag may be implemented in the >future? I am currently porting a DMAPI application from another platform, >and this could cause some major problems. I think I fixed that last month. Dean From owner-linux-xfs@oss.sgi.com Mon Jan 7 09:14:42 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g07HEgt17962 for linux-xfs-outgoing; Mon, 7 Jan 2002 09:14:42 -0800 Received: from e31.co.us.ibm.com (e31.co.us.ibm.com [32.97.110.129]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g07HEYg17938 for ; Mon, 7 Jan 2002 09:14:34 -0800 Received: from westrelay03.boulder.ibm.com (westrelay03.boulder.ibm.com [9.99.140.24]) by e31.co.us.ibm.com (8.9.3/8.9.3) with ESMTP id LAA18070; Mon, 7 Jan 2002 11:11:22 -0500 Received: from d03nm800.boulder.ibm.com (avpilot.boulder.ibm.com [9.17.188.135]) by westrelay03.boulder.ibm.com (8.11.1m3/NCO v5.01) with ESMTP id g07GE8B46712; Mon, 7 Jan 2002 09:14:09 -0700 Subject: Re: XFS DMAPI file I/O To: Dean Roehrich Cc: linux-xfs@oss.sgi.com X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 Message-ID: From: "James A Goodwin" Date: Mon, 7 Jan 2002 10:14:08 -0600 X-MIMETrack: Serialize by Router on D03NM800/03/M/IBM(Release 5.0.9 |November 16, 2001) at 01/07/2002 09:14:08 AM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 2510 Lines: 53 Dean, Ah yes, I see the changes. This is very good news. Do you have any idea how long it will be until there is a user release that incorporates the change? Thanks, -James Goodwin Software Engineer IBM Global Services - Federal jagoodwi@us.ibm.com Phone: (281) 336 2578 Fax: (281) 335 4231 T/L 260-2578 Dean Roehrich cc: linux-xfs@oss.sgi.com Sent by: Subject: Re: XFS DMAPI file I/O owner-linux-xfs@o ss.sgi.com 01/07/2002 09:42 AM >From: "James A Goodwin" >2. I just noticed that the DM_WRITE_SYNC flag is not supported for calls to >dm_write_invis(). This is a fairly critical piece of missing >functionality. Is there any chance this flag may be implemented in the >future? I am currently porting a DMAPI application from another platform, >and this could cause some major problems. I think I fixed that last month. Dean From owner-linux-xfs@oss.sgi.com Mon Jan 7 09:39:30 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g07HdUj19138 for linux-xfs-outgoing; Mon, 7 Jan 2002 09:39:30 -0800 Received: from sisko.scot.redhat.com (pc-80-195-34-155-ed.blueyonder.co.uk [80.195.34.155]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g07HdQg19116 for ; Mon, 7 Jan 2002 09:39:26 -0800 Received: (from sct@localhost) by sisko.scot.redhat.com (8.11.6/8.11.2) id g07Gd7T22199; Mon, 7 Jan 2002 16:39:07 GMT Date: Mon, 7 Jan 2002 16:39:07 +0000 From: "Stephen C. Tweedie" To: Adrian Head , Eric Sandeen , Linux XFS Mailing List , linux-lvm@sistina.com, ext2-devel@lists.sourceforge.net Cc: Stephen Tweedie Subject: Re: [Ext2-devel] [ahead@bigpond.net.au: [linux-lvm] Re: Unable to get XFS, ext3, reiserfs & LVM to coexist happily] Message-ID: <20020107163907.J20581@redhat.com> References: <20020105161447.K12868@lynx.no> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20020105161447.K12868@lynx.no>; from adilger@turbolabs.com on Sat, Jan 05, 2002 at 04:14:47PM -0700 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 718 Lines: 19 Hi, On Sat, Jan 05, 2002 at 04:14:47PM -0700, Andreas Dilger wrote: > Adrian Head wrote: > > This is the full output from kdb when trying to create a snapshot on an XFS > > volume for me. > > The system is running 2.4.17 + LVM patch (relatively minor) + VFS-lock > (needed for snapshots) + 2.4.17 XFS patch, IIRC. This has been discussed > on linux-lvm and linux-xfs for a couple of days. What is strange is that > this is happening while doing an XFS snapshot, but the oops is consistently > in ext3. There are several other ext3 filesystems on the system in > question. Is XFS or LVM using current->journal_info for anything, and if so, is it being left non-zero by anyone? --Stephen From owner-linux-xfs@oss.sgi.com Mon Jan 7 09:50:54 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g07Hosl19463 for linux-xfs-outgoing; Mon, 7 Jan 2002 09:50:54 -0800 Received: from mta01ps.bigpond.com (mta01ps.bigpond.com [144.135.25.133]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g07Hogg19441 for ; Mon, 7 Jan 2002 09:50:42 -0800 Message-Id: <200201071750.g07Hogg19441@oss.sgi.com> Received: from there ([144.135.25.87]) by mta01ps.bigpond.com (Netscape Messaging Server 4.15) with SMTP id GPKV3W00.2O3; Tue, 8 Jan 2002 02:57:32 +1000 Received: from CPE-144-137-138-230.qld.bigpond.net.au ([144.137.138.230]) by psmam07.mailsvc.email.bigpond.com(MailRouter V3.0h 125/414519); 08 Jan 2002 02:50:31 Content-Type: text/plain; charset="us-ascii" From: Adrian Head To: Keith Owens Subject: Re: Unable to get XFS, ext3, reiserfs & LVM to coexist happily Date: Tue, 8 Jan 2002 02:50:27 +1000 X-Mailer: KMail [version 1.3.1] Cc: Linux XFS Mailing List , linux-lvm@sistina.com References: <30503.1010414515@ocs3.intra.ocs.com.au> In-Reply-To: <30503.1010414515@ocs3.intra.ocs.com.au> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 3870 Lines: 107 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Keith - just a couple of questions... On Tue, 8 Jan 2002 00:41, Keith Owens wrote: > On Tue, 8 Jan 2002 00:08:11 +1000, > > Adrian Head wrote: > > > >Entering kdb (current=0xd600e000, pid 940) Oops: Oops > >due to oops @ 0xb800 > >eax = 0xffffffff ebx = 0xd600e000 ecx = 0x0000b800 edx = 0xc018fd25 > >esi = 0x00000008 edi = 0xd600e000 esp = 0xd600ff0c eip = 0x0000b800 > >ebp = 0xd600ff30 xss = 0x00000018 xcs = 0x00000010 eflags = 0x00010086 > >xds = 0x00000018 xes = 0x00000018 origeax = 0xffffffff ®s = 0xd600fed8 > >kdb> bt > > EBP EIP Function(args) > >0xd600ff30 0x0000b800 +0xb800 (0x1) > > kernel 0x0 0x0 0x0 > > 0xc011ce83 dequeue_signal+0x43 (0xd600e560, 0xd600ff30, > >0xd600e560, 0xd600ffc4, 0xc01392ff) > > kernel .text 0xc0100000 0xc011ce40 > > 0xc011cef0 0xc01069b9 do_signal+0x59 (0x11, 0xbfffec40, 0xbfffebb0, 0x8, > > 0x11) kernel .text 0xc0100000 0xc0106960 0xc0106c00 0xc0106d54 > > signal_return+0x14 > > kernel .text 0xc0100000 0xc0106d40 > > 0xc0106d58 > > kdb is correctly reporting the current eip, but the kernel has taken a > swan dive into nowhere. It looks like the chunk of code below. To > confirm, run > > objdump --start-addr=0xc011ce40 --stop-address=0xc011ce90 vmlinux How did you get 0xc011ce40 and 0xc011ce90? Do they come from above? How are they derived? Just interested. vmlinux - where does that come from? I assume it is not the compressed kernel found in /boot. > > I expect to see a call instruction just before 0xc011ce83, probably an > indirect call via ecx. As soon as I can get a sucessful objdump I'll send it on. > > dequeue_signal(sigset_t *mask, siginfo_t *info) > { > int sig = 0; > > #if DEBUG_SIG > printk("SIG dequeue (%s:%d): %d ", current->comm, current->pid, > signal_pending(current)); > #endif > > sig = next_signal(current, mask); > if (sig) { > if (current->notifier) { > if (sigismember(current->notifier_mask, sig)) { > if > (!(current->notifier)(current->notifier_data)) { <=== probably failing > here current->sigpending = 0; > return 0; > } > > Without seeing the objdump output, I am assuming that it is failing on > the call to current->notifier which means that notifier is corrupt. > The only place that notifier is set is in block_all_signals() so we > need to find who is calling that routine with bad data. With any luck, > this (untested) debug patch will catch the offender. Then we start > finding out why it is passing a bad pointer. While I wait for more info about objdump I'll do this and see what happens. > --- kernel/signal.c.orig Wed Dec 5 13:15:50 2001 > +++ kernel/signal.c Tue Jan 8 01:28:12 2002 > @@ -155,6 +155,8 @@ block_all_signals(int (*notifier)(void * > { > unsigned long flags; > > + if (notifier && (unsigned long)notifier < 0xc0000000) > + BUG(); > spin_lock_irqsave(¤t->sigmask_lock, flags); > current->notifier_mask = mask; > current->notifier_data = priv; > > A quick scan through the kernel found only DRM code using > block_all_signals. If the bug is a bad notifier then the oops will be > timing dependent, the notifier routine is only called if a signal trips > between block_all_signals() and unblock_all_signals() and that does not > always occur. - -- Adrian Head (Public Key available on request.) -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE8OdHW8ZJI8OvSkAcRAmpQAKCaoO4JuZO+teCW8cUEnDzrNvkjeACeOk9B eZT4hJWVk3xh1BOZnC0o14A= =YOrk -----END PGP SIGNATURE----- From owner-linux-xfs@oss.sgi.com Mon Jan 7 09:54:02 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g07Hs2g19648 for linux-xfs-outgoing; Mon, 7 Jan 2002 09:54:02 -0800 Received: from deliverator.sgi.com (deliverator.sgi.com [204.94.214.10]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g07Hrvg19626 for ; Mon, 7 Jan 2002 09:53:57 -0800 Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id IAA16019 for ; Mon, 7 Jan 2002 08:53:38 -0800 (PST) mail_from (lord@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id KAA4026491; Mon, 7 Jan 2002 10:52:37 -0600 (CST) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id KAA31414; Mon, 7 Jan 2002 10:52:37 -0600 (CST) Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id g07Gpx407239; Mon, 7 Jan 2002 10:51:59 -0600 Subject: Re: [Ext2-devel] [ahead@bigpond.net.au: [linux-lvm] Re: Unable to get XFS, ext3, reiserfs & LVM to coexist happily] From: Steve Lord To: "Stephen C. Tweedie" Cc: Adrian Head , Eric Sandeen , Linux XFS Mailing List , linux-lvm@sistina.com, ext2-devel@lists.sourceforge.net In-Reply-To: <20020107163907.J20581@redhat.com> References: <20020105161447.K12868@lynx.no> <20020107163907.J20581@redhat.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/1.0.0.99+cvs.2001.12.18.08.57 (Preview Release) Date: 07 Jan 2002 10:51:59 -0600 Message-Id: <1010422319.7148.7.camel@jen.americas.sgi.com> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 1431 Lines: 37 On Mon, 2002-01-07 at 10:39, Stephen C. Tweedie wrote: > Hi, > > On Sat, Jan 05, 2002 at 04:14:47PM -0700, Andreas Dilger wrote: > > Adrian Head wrote: > > > This is the full output from kdb when trying to create a snapshot on an XFS > > > volume for me. > > > > The system is running 2.4.17 + LVM patch (relatively minor) + VFS-lock > > (needed for snapshots) + 2.4.17 XFS patch, IIRC. This has been discussed > > on linux-lvm and linux-xfs for a couple of days. What is strange is that > > this is happening while doing an XFS snapshot, but the oops is consistently > > in ext3. There are several other ext3 filesystems on the system in > > question. > > Is XFS or LVM using current->journal_info for anything, and if so, is > it being left non-zero by anyone? We do not touch it, there has subsequently been a crash with ext3 removed from the kernel, so I suspect this is an XFS only issue - probably memory corruption. It appears we are doing a disk write in the unlockfs callout, possibly lvm is not in a coherent state at this point and is trampling on memory it should not be. Eric is going to remove the offending write and see if this clears it up, off the top of my head I cannot see why we need it in the unlockfs path. Steve > > --Stephen -- Steve Lord voice: +1-651-683-3511 Principal Engineer, Filesystem Software email: lord@sgi.com From owner-linux-xfs@oss.sgi.com Mon Jan 7 10:29:27 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g07ITRG20458 for linux-xfs-outgoing; Mon, 7 Jan 2002 10:29:27 -0800 Received: from riv-vwsmtpout1.echostar.com (wks-253.echostar.com [204.76.128.253]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g07ITJg20432 for ; Mon, 7 Jan 2002 10:29:19 -0800 Received: from 10.79.98.140 by riv-vwsmtpout1.echostar.com (InterScan E-Mail VirusWall NT); Mon, 07 Jan 2002 10:29:11 -0700 Message-ID: <3C39DADF.8010700@echostar.com> Date: Mon, 07 Jan 2002 10:29:03 -0700 From: Chris Parrott User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.7) Gecko/20011229 X-Accept-Language: en MIME-Version: 1.0 To: linux-xfs@oss.sgi.com Subject: write-caching with XFS Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 2492 Lines: 57 Greetings: I have noticed a very strange phenomenon involving XFS with hardware write-caching being active on Maxtor hard drives. We have seen this on both 80 GB and 120 GB drives, so it's not limited to any one drive model in particular. Maxtor turns on write-caching by default in their hard drives. We are working on a project which involves streaming live video data to a large (approx. 78-118 GB, depending on the drive) partition formatted with XFS. As the data comes in, it is held in a ring buffer before being dumped to the disk in fixed (approx. 99 KB) chunks. With write-caching turned on, dumping data to the XFS partition causes the ring buffer to eventually overflow, resulting in periodic data loss. However, if we turn off write-caching, the ring buffer never seems to overflow. It seems that the write calls just block longer with write-caching turned on. Unfortunately, the extra blocking time causes us to not be able to process our data promptly enough to prevent buffer overflows. We had an engineer from Maxtor perform some IDE bus traces while data was being spooled to the drive, and he could not find any indication that drive performance itself was the culprit. All of the I/O requests to the drive itself were completed within the usual, expected durations of time, once the corresponding IDE commands had been issued. I tried another experiment, in which I replaced the XFS filesystem with ReiserFS, to determine if the problem with filesystem vs. IDE-driver related. The ring buffer did not overflow when writing to the ReiserFS partition. (We cannot use ReiserFS in production, as we depend on some features only available in XFS.) We are using a 2.4.8 kernel, with the corresponding XFS patch applied. This kernel has been heavily modified to support our product, so we cannot easily upgrade to the very latest kernel revision. Hence, we have not been able to track all the subsequent XFS developments. Does anyone know what might be going on in XFS to cause this sort of behavior? I am curious as to why the write requests to XFS would take longer to complete with write-caching turned on. I would like to keep write-caching on, if at all possible, due to the overall performance gains. Many thanks in advance, +chris Chris Parrott Linux Software Engineer Echostar Technologies Corp. 94 Inverness Terrace East Englewood, CO 80112 phone: 303 706 5383 / fax: 303 799 6222 e-mail: chris.parrott@echostar.com From owner-linux-xfs@oss.sgi.com Mon Jan 7 11:15:39 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g07JFdN21586 for linux-xfs-outgoing; Mon, 7 Jan 2002 11:15:39 -0800 Received: from UberGeek.coremetrics.com ([209.184.141.163]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g07JFXg21562 for ; Mon, 7 Jan 2002 11:15:33 -0800 Received: (from austin@localhost) by UberGeek.coremetrics.com (8.11.6/8.11.6) id g07IErP29299; Mon, 7 Jan 2002 12:14:53 -0600 X-Authentication-Warning: UberGeek.coremetrics.com: austin set sender to austin@coremetrics.com using -f Subject: GRUB + LVM + XFS? From: Austin Gonyou To: linux-xfs@oss.sgi.com Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-YeHOKbixvMB2pUkBqJA+" X-Mailer: Evolution/1.0.0.99+cvs.2001.12.18.08.57 (Preview Release) Date: 07 Jan 2002 12:14:53 -0600 Message-Id: <1010427293.29260.3.camel@UberGeek> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 752 Lines: 30 --=-YeHOKbixvMB2pUkBqJA+ Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Is it possible to boot a LVM XFS root with GRUB? --=20 Austin Gonyou Systems Architect, CCNA Coremetrics, Inc. Phone: 512-698-7250 email: austin@coremetrics.com "It is the part of a good shepherd to shear his flock, not to skin it." Latin Proverb --=-YeHOKbixvMB2pUkBqJA+ Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQA8OeWd94g6ZVmFMoIRAhbMAJ4yIkubaXtsdGDKQRG6ktKYodO1IwCgyRa9 3Mkv6nr8byKf1cVUDCct8r4= =SgaV -----END PGP SIGNATURE----- --=-YeHOKbixvMB2pUkBqJA+-- From owner-linux-xfs@oss.sgi.com Mon Jan 7 11:41:48 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g07Jfm022202 for linux-xfs-outgoing; Mon, 7 Jan 2002 11:41:48 -0800 Received: from yog-sothoth.sgi.com (eugate.sgi.com [192.48.160.10]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g07Jfhg22168 for ; Mon, 7 Jan 2002 11:41:43 -0800 Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by yog-sothoth.sgi.com (980305.SGI.8.8.8-aspam-6.2/980304.SGI-aspam-europe) via ESMTP id TAA1398749 for ; Mon, 7 Jan 2002 19:39:47 +0100 (CET) mail_from (lord@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id MAA4020585; Mon, 7 Jan 2002 12:40:22 -0600 (CST) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id MAA41359; Mon, 7 Jan 2002 12:40:22 -0600 (CST) Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id g07Idhx14602; Mon, 7 Jan 2002 12:39:43 -0600 Subject: Re: GRUB + LVM + XFS? From: Steve Lord To: Austin Gonyou Cc: linux-xfs@oss.sgi.com In-Reply-To: <1010427293.29260.3.camel@UberGeek> References: <1010427293.29260.3.camel@UberGeek> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/1.0.0.99+cvs.2001.12.18.08.57 (Preview Release) Date: 07 Jan 2002 12:39:43 -0600 Message-Id: <1010428783.7137.24.camel@jen.americas.sgi.com> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 789 Lines: 25 On Mon, 2002-01-07 at 12:14, Austin Gonyou wrote: > Is it possible to boot a LVM XFS root with GRUB? I think lvm root will require an initial ram disk to construct the volumes - configuration comes from user space right? Grub reads from the filesystem directly, and I do not know if it can deal with anything other than a basic partition to read data from. You would have to have the boot partition be non-lvm I think. Steve > -- > Austin Gonyou > Systems Architect, CCNA > Coremetrics, Inc. > Phone: 512-698-7250 > email: austin@coremetrics.com > > "It is the part of a good shepherd to shear his flock, not to skin it." > Latin Proverb -- Steve Lord voice: +1-651-683-3511 Principal Engineer, Filesystem Software email: lord@sgi.com From owner-linux-xfs@oss.sgi.com Mon Jan 7 11:52:45 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g07Jqjw22485 for linux-xfs-outgoing; Mon, 7 Jan 2002 11:52:45 -0800 Received: from UberGeek.coremetrics.com ([209.184.141.163]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g07Jqag22458 for ; Mon, 7 Jan 2002 11:52:37 -0800 Received: (from austin@localhost) by UberGeek.coremetrics.com (8.11.6/8.11.6) id g07Ippa29482; Mon, 7 Jan 2002 12:51:51 -0600 X-Authentication-Warning: UberGeek.coremetrics.com: austin set sender to austin@coremetrics.com using -f Subject: Re: GRUB + LVM + XFS? From: Austin Gonyou To: Steve Lord Cc: linux-xfs@oss.sgi.com In-Reply-To: <1010428783.7137.24.camel@jen.americas.sgi.com> References: <1010428783.7137.24.camel@jen.americas.sgi.com> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-HwfkrRq7yUytxpkojwds" X-Mailer: Evolution/1.0.0.99+cvs.2001.12.18.08.57 (Preview Release) Date: 07 Jan 2002 12:51:51 -0600 Message-Id: <1010429511.29450.2.camel@UberGeek> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 1802 Lines: 59 --=-HwfkrRq7yUytxpkojwds Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Thanks. I saw a similar answer to a similar question on the LVM mailing list. Since this list seems to have a few more users, I thought I'd ask here too to see what the consensus was. Thanks much! On Mon, 2002-01-07 at 12:39, Steve Lord wrote: > On Mon, 2002-01-07 at 12:14, Austin Gonyou wrote: > > Is it possible to boot a LVM XFS root with GRUB? >=20 > I think lvm root will require an initial ram disk to construct the > volumes - configuration comes from user space right? Grub reads from=20 > the filesystem directly, and I do not know if it can deal with anything > other than a basic partition to read data from. You would have to have > the boot partition be non-lvm I think. >=20 > Steve >=20 > > --=20 > > Austin Gonyou > > Systems Architect, CCNA > > Coremetrics, Inc. > > Phone: 512-698-7250 > > email: austin@coremetrics.com > >=20 > > "It is the part of a good shepherd to shear his flock, not to skin > it." > > Latin Proverb > --=20 >=20 > Steve Lord voice: +1-651-683-3511 > Principal Engineer, Filesystem Software email: lord@sgi.com --=20 Austin Gonyou Systems Architect, CCNA Coremetrics, Inc. Phone: 512-698-7250 email: austin@coremetrics.com "It is the part of a good shepherd to shear his flock, not to skin it." Latin Proverb --=-HwfkrRq7yUytxpkojwds Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQA8Oe5H94g6ZVmFMoIRAoSAAJ9RDRcs7S74d/zff5J4WHqTSo099ACdEDU7 AbM26WOLX6PdKzyCDZD1klY= =p1nU -----END PGP SIGNATURE----- --=-HwfkrRq7yUytxpkojwds-- From owner-linux-xfs@oss.sgi.com Mon Jan 7 11:54:05 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g07Js5P22635 for linux-xfs-outgoing; Mon, 7 Jan 2002 11:54:05 -0800 Received: from rj.sgi.com (rj.sgi.com [204.94.215.100]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g07Jrug22610 for ; Mon, 7 Jan 2002 11:53:56 -0800 Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by rj.sgi.com (8.11.4/8.11.4/linux-outbound_gateway-1.1) with ESMTP id g07IrnY02882 for ; Mon, 7 Jan 2002 10:53:49 -0800 Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id MAA3955412; Mon, 7 Jan 2002 12:52:33 -0600 (CST) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id MAA41597; Mon, 7 Jan 2002 12:52:32 -0600 (CST) Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id g07IprM14629; Mon, 7 Jan 2002 12:51:53 -0600 Subject: Re: file corruption during emacs build on XFS logical volume From: Steve Lord To: Sean Neakums Cc: Linux XFS In-Reply-To: <6uheq0fsu6.fsf@zork.zork.net> References: <1010174871.30053.6.camel@jen.americas.sgi.com> <1010176193.2938.14.camel@UberGeek> <1010176393.30037.9.camel@jen.americas.sgi.com> <1010179700.30053.13.camel@jen.americas.sgi.com> <1010187371.30053.32.camel@jen.americas.sgi.com> <6uy9jdhdsr.fsf@zork.zork.net> <6upu4ph8c5.fsf@zork.zork.net> <3C37511F.6050809@sgi.com> <6uheq0fsu6.fsf@zork.zork.net> Content-Type: multipart/mixed; boundary="=-25Rb1XxbJy2ZcU8Tijge" X-Mailer: Evolution/1.0.0.99+cvs.2001.12.18.08.57 (Preview Release) Date: 07 Jan 2002 12:51:53 -0600 Message-Id: <1010429513.7120.35.camel@jen.americas.sgi.com> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 2214 Lines: 69 --=-25Rb1XxbJy2ZcU8Tijge Content-Type: text/plain Content-Transfer-Encoding: 7bit On Sat, 2002-01-05 at 14:25, Sean Neakums wrote: > begin Stephen Lord quotation: > > > OK, thanks, this narrows it down even more than I had - I was > > running a kernel from Dec 22nd and recreating the problem. I had > > tried the individual patches to the I/O path and failed to recreate > > it - but maybe I should try that again. > > I just found a kernel from December 8 (I had removed it from > lilo.conf, but forgotten to delete the kernel itself and the modules) > and I cannot recreate on that. > Sean, can you see if the attached patch against the current cvs tree fixes the problem for you? So far I have not been able to reproduce with this change. Steve -- Steve Lord voice: +1-651-683-3511 Principal Engineer, Filesystem Software email: lord@sgi.com --=-25Rb1XxbJy2ZcU8Tijge Content-Disposition: attachment; filename=emacs.patch Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; 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/pagebuf/page_buf_io.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.14614-0/linux/fs/pagebuf/page_buf_io.c_1.104 Mon Jan 7= 12:49:22 2002 +++ linux/fs/pagebuf/page_buf_io.c Mon Jan 7 10:58:43 2002 @@ -1340,6 +1340,7 @@ do { lock_buffer(bh); clear_bit(BH_Delay, &bh->b_state); +/**** if (atomic_set_buffer_clean(bh)) { get_bh(bh); bh->b_end_io =3D end_buffer_io_sync; @@ -1349,6 +1350,12 @@ unlock_buffer(bh); refile_buffer(bh); } +***/ + atomic_set_buffer_clean(bh); + get_bh(bh); + bh->b_end_io =3D end_buffer_io_sync; + refile_buffer(bh); + array[count++] =3D bh; bh =3D bh->b_this_page; } while (bh !=3D head); =20 --=-25Rb1XxbJy2ZcU8Tijge-- From owner-linux-xfs@oss.sgi.com Mon Jan 7 12:02:22 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g07K2MS22990 for linux-xfs-outgoing; Mon, 7 Jan 2002 12:02:22 -0800 Received: from zok.sgi.com (zok.SGI.COM [204.94.215.101]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g07K2Hg22967 for ; Mon, 7 Jan 2002 12:02:17 -0800 Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by zok.sgi.com (8.11.4/8.11.4/linux-outbound_gateway-1.1) with ESMTP id g07J2AA18221 for ; Mon, 7 Jan 2002 11:02:10 -0800 Received: from poppy-e185.americas.sgi.com (poppy-e185.americas.sgi.com [128.162.185.207]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id NAA4025716; Mon, 7 Jan 2002 13:00:54 -0600 (CST) Received: from stout.americas.sgi.com (stout.americas.sgi.com [128.162.187.5]) by poppy-e185.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.7) with ESMTP id NAA25448; Mon, 7 Jan 2002 13:00:53 -0600 (CST) Subject: Re: Unable to get XFS, ext3, reiserfs & LVM to coexist happily From: Eric Sandeen To: Eric Sandeen Cc: Adrian Head , Linux XFS Mailing List , linux-lvm@sistina.com In-Reply-To: References: Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/1.0 (Preview Release) Date: 07 Jan 2002 13:00:53 -0600 Message-Id: <1010430053.14493.9.camel@stout.americas.sgi.com> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 1517 Lines: 33 On Fri, 2002-01-04 at 21:10, Eric Sandeen wrote: > Ok, I've done a bit of kdb sleuthing over here... it looks like it's > blowing up shortly after lvm_snapshot_COW, although for some reason kdb > says the backtrace is from sys_stat64 after the oops. On the other > hand, setting a breakpoint at > lvm_snapshot_COW, it oopses just a couple steps later. Here's the > backtrace out of lvm_snapshot_COW. It gets there from lvm_do_lv_create > via unlockfs; does this make sense? I didn't expect to get into > lvm_snapshot_COW until after the snapshot volume was created... Ok, it looks like that was the problem. XFS wrote the superblock when unfreezing (unlocking) the filesystem, apparently LVM wasn't happy with this I/O on the snapshotted volume before the volume had been created. Something goes quite haywire as a result, but I'm not sure what. We really don't need the superblock write at this point (it was the last thing done prior to the freeze, no need to do it again), and removing it allows the snapshot to be created without error. I was curious, though, to see if reversing the order of unlockfs() & lvm_fs_create_lv() at the end of lvm_do_lv_create() might alleviate this problem (i.e. create the lv, THEN unlock the snapshotted volume) but that didn't work, either. Perhaps the LVM folks can comment on this... Adrian says there's still a problem with overflows; I'll look into that. -Eric -- Eric Sandeen XFS for Linux http://oss.sgi.com/projects/xfs sandeen@sgi.com SGI, Inc. From owner-linux-xfs@oss.sgi.com Mon Jan 7 12:02:27 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g07K2R523001 for linux-xfs-outgoing; Mon, 7 Jan 2002 12:02:27 -0800 Received: from zok.sgi.com (zok.SGI.COM [204.94.215.101]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g07K2Dg22945 for ; Mon, 7 Jan 2002 12:02:13 -0800 Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by zok.sgi.com (8.11.4/8.11.4/linux-outbound_gateway-1.1) with ESMTP id g07J25A18213 for ; Mon, 7 Jan 2002 11:02:05 -0800 Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id NAA4028852; Mon, 7 Jan 2002 13:00:49 -0600 (CST) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id NAA41080; Mon, 7 Jan 2002 13:00:49 -0600 (CST) Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id g07J0AP14637; Mon, 7 Jan 2002 13:00:10 -0600 Subject: Re: write-caching with XFS From: Steve Lord To: Chris Parrott Cc: linux-xfs@oss.sgi.com In-Reply-To: <3C39DADF.8010700@echostar.com> References: <3C39DADF.8010700@echostar.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/1.0.0.99+cvs.2001.12.18.08.57 (Preview Release) Date: 07 Jan 2002 13:00:10 -0600 Message-Id: <1010430010.7120.45.camel@jen.americas.sgi.com> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 4321 Lines: 99 On Mon, 2002-01-07 at 11:29, Chris Parrott wrote: > > Greetings: > > I have noticed a very strange phenomenon involving XFS with hardware > write-caching being active on Maxtor hard drives. We have seen this on > both 80 GB and 120 GB drives, so it's not limited to any one drive model > in particular. Maxtor turns on write-caching by default in their hard > drives. > > We are working on a project which involves streaming live video data to > a large (approx. 78-118 GB, depending on the drive) partition formatted > with XFS. As the data comes in, it is held in a ring buffer before > being dumped to the disk in fixed (approx. 99 KB) chunks. With > write-caching turned on, dumping data to the XFS partition causes the > ring buffer to eventually overflow, resulting in periodic data loss. > However, if we turn off write-caching, the ring buffer never seems to > overflow. It seems that the write calls just block longer with > write-caching turned on. Unfortunately, the extra blocking time causes > us to not be able to process our data promptly enough to prevent buffer > overflows. > > We had an engineer from Maxtor perform some IDE bus traces while data > was being spooled to the drive, and he could not find any indication > that drive performance itself was the culprit. All of the I/O requests > to the drive itself were completed within the usual, expected durations > of time, once the corresponding IDE commands had been issued. > > I tried another experiment, in which I replaced the XFS filesystem with > ReiserFS, to determine if the problem with filesystem vs. IDE-driver > related. The ring buffer did not overflow when writing to the ReiserFS > partition. (We cannot use ReiserFS in production, as we depend on some > features only available in XFS.) > > We are using a 2.4.8 kernel, with the corresponding XFS patch applied. > This kernel has been heavily modified to support our product, so we > cannot easily upgrade to the very latest kernel revision. Hence, we > have not been able to track all the subsequent XFS developments. > > Does anyone know what might be going on in XFS to cause this sort of > behavior? I am curious as to why the write requests to XFS would take > longer to complete with write-caching turned on. I would like to keep > write-caching on, if at all possible, due to the overall performance gains. > > Many thanks in advance, You might consider this: Journaled filesystems rely on controlling the ordering of writes to the disk to maintain integrity. If a log write is reported by the device driver as being on disk, then the filesystem assumes it is free to write out the metadata itself. Lets assume we have an operation which takes a block from the free space and assigns it to a file. We create a transaction to do this and write it to the log. Once the log write is completed, we allow the metadata to go out to disk. There are two chunks of metadata written independently. Lets assume write caching is on. We write the log record into the cache, it returns saying the data is safe, we allow the metadata to go out. For some reason, one of the metadata writes makes it through cache before the log write does. If you crash at this point you have a corrupt filesystem. Unless Maxtor can guarantee that they never lose write cached data in a power failure you are on shaky ground here. As for why you are seeing the behavior you are, I am not sure, but the xfs log is probably being continually written to - a circular buffer in the middle of the partition. If you have a spare spindle to experiment with, create a filesystem with an external log and see how it behaves. mkfs -t xfs -f -l logdev=/dev/xxx,size=16384b /dev/yyy mount -t xfs -o logdev=/dev/xxx /dev/yyy /xfs Where /dev/xxx does not share the write cache with /dev/yyy It is possible the log writes are causing pathalogical behavior in the cache. Steve > > +chris > > > Chris Parrott > Linux Software Engineer > Echostar Technologies Corp. > 94 Inverness Terrace East > Englewood, CO 80112 > phone: 303 706 5383 / fax: 303 799 6222 > e-mail: chris.parrott@echostar.com > -- Steve Lord voice: +1-651-683-3511 Principal Engineer, Filesystem Software email: lord@sgi.com From owner-linux-xfs@oss.sgi.com Mon Jan 7 12:40:57 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g07KevH24025 for linux-xfs-outgoing; Mon, 7 Jan 2002 12:40:57 -0800 Received: from ns.caldera.de (ns.caldera.de [212.34.180.1]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g07Keqg24003 for ; Mon, 7 Jan 2002 12:40:53 -0800 Received: (from hch@localhost) by ns.caldera.de (8.11.6/8.11.6) id g07JedT27372; Mon, 7 Jan 2002 20:40:39 +0100 Date: Mon, 7 Jan 2002 20:40:39 +0100 From: Christoph Hellwig To: Steve Lord Cc: Austin Gonyou , linux-xfs@oss.sgi.com Subject: Re: GRUB + LVM + XFS? Message-ID: <20020107204039.A26831@caldera.de> References: <1010427293.29260.3.camel@UberGeek> <1010428783.7137.24.camel@jen.americas.sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <1010428783.7137.24.camel@jen.americas.sgi.com>; from lord@sgi.com on Mon, Jan 07, 2002 at 12:39:43PM -0600 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 993 Lines: 24 On Mon, Jan 07, 2002 at 12:39:43PM -0600, Steve Lord wrote: > On Mon, 2002-01-07 at 12:14, Austin Gonyou wrote: > > Is it possible to boot a LVM XFS root with GRUB? > > I think lvm root will require an initial ram disk to construct the > volumes - configuration comes from user space right? Grub reads from > the filesystem directly, and I do not know if it can deal with anything > other than a basic partition to read data from. You would have to have > the boot partition be non-lvm I think. On ftp.openlinux.org:/pub/people/hch/lvm I have a patch to support loading kernel from contingous logical volumes against an old version of grub. The grub crew decided to rewrite the part it plugs into just to use GNUc extension (nested functions) very soon after I finished it so it won't apply against current grub versions. If you want to add support for current grub version it might be a good start anyway. Christoph -- Of course it doesn't work. We've performed a software upgrade. From owner-linux-xfs@oss.sgi.com Mon Jan 7 12:54:10 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g07KsAx24362 for linux-xfs-outgoing; Mon, 7 Jan 2002 12:54:10 -0800 Received: from shakti.rupa.com (foobar@cx838204-a.alsv1.occa.home.com [24.16.83.66]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g07Ks4g24340 for ; Mon, 7 Jan 2002 12:54:05 -0800 Received: from shakti.rupa.com (localhost [127.0.0.1]) by localhost.rupa.com (Postfix) with ESMTP id 4D9FC48FC8; Mon, 7 Jan 2002 11:54:02 -0800 (PST) Received: by shakti.rupa.com (Postfix, from userid 9) id D8A3E48D59; Mon, 7 Jan 2002 11:54:01 -0800 (PST) Received: from 192.168.1.20 by 192.168.1.20 with nntp; 7 Jan 2002 11:54:01 PST To: linux-xfs@oss.sgi.com Subject: Re: GRUB + LVM + XFS? References: <1010427293.29260.3.camel@UberGeek> From: Rupa Schomaker Date: Mon, 07 Jan 2002 11:54:01 -0800 Message-Id: User-Agent: Gnus/5.090005 (Oort Gnus v0.05) XEmacs/21.4 (Copyleft, i386-debian-linux) Cancel-Lock: sha1:N9Uet2jd+ykSqMBOQCIWpWaaM2c= MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii NNTP-Posting-Host: 192.168.1.20 X-Spam-Status: No, hits=-99 required=5 tests=SUBJ_ENDS_IN_Q_MARK,USER_IN_W HITELIST Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 1321 Lines: 41 You need a ext2 /boot (or if you've applied the xfs patches to grub you can use that). /boot cannot be in the LVM. You'll need an initrd that initializes the LVM. Your lvm package should come with the command "lvmcreate_initrd" -- this will create a minimal initrd that *only* starts lvm. If you need other things in your initrd then you'll have to "hack" the generated one. I'd recommend compiling in all the other components you need in the kernel rather than using modules. (for example, compile in your scsi drivers) I'm having toubles with the current CVS version of the XFS kernel. I haven't had time to look at it completely, but... it could be: 1) mismatch between userspace and kernel (what LVM is in the XFS kernel? I'm using the debian lvm10 userspace). 2) bad config 3) ??? A quick "bt" at boot in kdb shows that devfs is in the call path. No, I haven't had time to write everything down. :( Man, I wish there was an easy to dump the kdb info or an OOPs to disk... Austin Gonyou writes: > Is it possible to boot a LVM XFS root with GRUB? > -- > Austin Gonyou > Systems Architect, CCNA > Coremetrics, Inc. > Phone: 512-698-7250 > email: austin@coremetrics.com > > "It is the part of a good shepherd to shear his flock, not to skin it." > Latin Proverb -- -rupa From owner-linux-xfs@oss.sgi.com Mon Jan 7 12:58:54 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g07Kws924578 for linux-xfs-outgoing; Mon, 7 Jan 2002 12:58:54 -0800 Received: from palrel12.hp.com (palrel12.hp.com [156.153.255.237]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g07Kwlg24556 for ; Mon, 7 Jan 2002 12:58:47 -0800 Received: from xparelay1.corp.hp.com (xparelay1.corp.hp.com [15.58.136.173]) by palrel12.hp.com (Postfix) with ESMTP id BDA6FE004D2; Mon, 7 Jan 2002 11:58:40 -0800 (PST) Received: from xpabh3.corp.hp.com (xpabh3.corp.hp.com [15.58.136.223]) by xparelay1.corp.hp.com (Postfix) with ESMTP id A4CF0600098; Mon, 7 Jan 2002 11:58:40 -0800 (PST) Received: by xpabh3.corp.hp.com with Internet Mail Service (5.5.2653.19) id ; Mon, 7 Jan 2002 11:58:40 -0800 Message-ID: From: "ZINKEVICIUS,MATT (HP-Loveland,ex1)" To: "'Stephen Lord'" , "ZINKEVICIUS,MATT (HP-Loveland,ex1)" Cc: "'linux-xfs@oss.sgi.com'" Subject: RE: link() messes up file attributes Date: Mon, 7 Jan 2002 11:58:34 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 1452 Lines: 55 Thanks Steve! This fixed it! --Matt > -----Original Message----- > From: Stephen Lord [mailto:lord@sgi.com] > Sent: Saturday, January 05, 2002 12:21 PM > To: ZINKEVICIUS,MATT (HP-Loveland,ex1) > Cc: 'linux-xfs@oss.sgi.com' > Subject: Re: link() messes up file attributes > > > ZINKEVICIUS,MATT (HP-Loveland,ex1) wrote: > > >Hi gang, > > > >We have been running specSFSv2 (NFS benchmark) against a > server running XFS. > >All was well previously (kernel 2.4.14), but we recently > checked out the XFS > >CVS (2002-01-03) and it now fails. The test fails a part of > the validation > >stage which does the following steps: > > > >1) Create a file (file1) with permissions 666 > >2) Create a hardlinked file (file2) to file1 > >3) Check that permissions of file1 are still 666 > > > >Step 3 now fails as file1 now has 644 permissions! Using the > same kernel we > >tried ext2 instead and everything behaved normally. If > anybody wants anymore > >detail just let me know. > > > >Matt Zinkevicius > >Software Engineer > >Network Storage Array Solutions > >Hewlett-Packard > > > Can you try this: > > Edit fs/xfs/linux/xfs_super.c and comment out these lines: > > > fh_to_dentry: linvfs_fh_to_dentry, > dentry_to_fh: linvfs_dentry_to_fh, > > At around line 907 and try again. I doubt it will fix it, but it is > worth a shot. > This will change the calls NFS uses to interact with XFS. > > Steve > > From owner-linux-xfs@oss.sgi.com Mon Jan 7 13:00:31 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g07L0VM24762 for linux-xfs-outgoing; Mon, 7 Jan 2002 13:00:31 -0800 Received: from yog-sothoth.sgi.com (eugate.sgi.com [192.48.160.10]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g07L0Rg24740 for ; Mon, 7 Jan 2002 13:00:27 -0800 Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by yog-sothoth.sgi.com (980305.SGI.8.8.8-aspam-6.2/980304.SGI-aspam-europe) via ESMTP id UAA1396317 for ; Mon, 7 Jan 2002 20:58:31 +0100 (CET) mail_from (lord@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id NAA4000990; Mon, 7 Jan 2002 13:59:07 -0600 (CST) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id NAA48152; Mon, 7 Jan 2002 13:59:07 -0600 (CST) Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id g07JwRc15123; Mon, 7 Jan 2002 13:58:27 -0600 Subject: Re: GRUB + LVM + XFS? From: Steve Lord To: Rupa Schomaker Cc: linux-xfs@oss.sgi.com In-Reply-To: References: <1010427293.29260.3.camel@UberGeek> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/1.0.0.99+cvs.2001.12.18.08.57 (Preview Release) Date: 07 Jan 2002 13:58:27 -0600 Message-Id: <1010433507.7148.48.camel@jen.americas.sgi.com> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 601 Lines: 21 On Mon, 2002-01-07 at 13:54, Rupa Schomaker wrote: > > A quick "bt" at boot in kdb shows that devfs is in the call path. No, > I haven't had time to write everything down. :( Man, I wish there was > an easy to dump the kdb info or an OOPs to disk... > A serial console, a mouse and cut and paste.... Look back in the list archives, there was a post of a mod for a devfs/lvm combo I think. It came via Keith Owens within the last day or two. Steve -- Steve Lord voice: +1-651-683-3511 Principal Engineer, Filesystem Software email: lord@sgi.com From owner-linux-xfs@oss.sgi.com Mon Jan 7 13:02:28 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g07L2Sp24971 for linux-xfs-outgoing; Mon, 7 Jan 2002 13:02:28 -0800 Received: from UberGeek.coremetrics.com ([209.184.141.163]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g07L2Kg24942 for ; Mon, 7 Jan 2002 13:02:20 -0800 Received: (from austin@localhost) by UberGeek.coremetrics.com (8.11.6/8.11.6) id g07K1g330723; Mon, 7 Jan 2002 14:01:42 -0600 X-Authentication-Warning: UberGeek.coremetrics.com: austin set sender to austin@coremetrics.com using -f Subject: Re: GRUB + LVM + XFS? From: Austin Gonyou To: Steve Lord Cc: Rupa Schomaker , linux-xfs@oss.sgi.com In-Reply-To: <1010433507.7148.48.camel@jen.americas.sgi.com> References: <1010433507.7148.48.camel@jen.americas.sgi.com> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-j8QSTbh25QH+I4k8BuXV" X-Mailer: Evolution/1.0.0.99+cvs.2001.12.18.08.57 (Preview Release) Date: 07 Jan 2002 14:01:42 -0600 Message-Id: <1010433702.30716.7.camel@UberGeek> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 1443 Lines: 52 --=-j8QSTbh25QH+I4k8BuXV Content-Type: text/plain Content-Transfer-Encoding: quoted-printable screendump comes to mind as well. On Mon, 2002-01-07 at 13:58, Steve Lord wrote: > On Mon, 2002-01-07 at 13:54, Rupa Schomaker wrote: >=20 > >=20 > > A quick "bt" at boot in kdb shows that devfs is in the call path. No, > > I haven't had time to write everything down. :( Man, I wish there was > > an easy to dump the kdb info or an OOPs to disk... > >=20 >=20 > A serial console, a mouse and cut and paste.... >=20 > Look back in the list archives, there was a post of a mod for a > devfs/lvm combo I think. It came via Keith Owens within the last > day or two. >=20 > Steve >=20 > --=20 >=20 > Steve Lord voice: +1-651-683-3511 > Principal Engineer, Filesystem Software email: lord@sgi.com --=20 Austin Gonyou Systems Architect, CCNA Coremetrics, Inc. Phone: 512-698-7250 email: austin@coremetrics.com "It is the part of a good shepherd to shear his flock, not to skin it." Latin Proverb --=-j8QSTbh25QH+I4k8BuXV Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQA8Of6m94g6ZVmFMoIRAmPaAKDAcI2e+8I3f/00VAkQPb5GT5WizwCfZTId /nyIg0gfpOTty0eD943hFjo= =QSOr -----END PGP SIGNATURE----- --=-j8QSTbh25QH+I4k8BuXV-- From owner-linux-xfs@oss.sgi.com Mon Jan 7 13:10:45 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g07LAjR25281 for linux-xfs-outgoing; Mon, 7 Jan 2002 13:10:45 -0800 Received: from rj.sgi.com (rj.sgi.com [204.94.215.100]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g07LAhg25259 for ; Mon, 7 Jan 2002 13:10:43 -0800 Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by rj.sgi.com (8.11.4/8.11.4/linux-outbound_gateway-1.1) with ESMTP id g07KAaY09209 for ; Mon, 7 Jan 2002 12:10:36 -0800 Received: from poppy-e185.americas.sgi.com (poppy-e185.americas.sgi.com [128.162.185.207]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id OAA4027248; Mon, 7 Jan 2002 14:09:20 -0600 (CST) Received: from stout.americas.sgi.com (stout.americas.sgi.com [128.162.187.5]) by poppy-e185.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.7) with ESMTP id OAA26153; Mon, 7 Jan 2002 14:09:20 -0600 (CST) Subject: Re: GRUB + LVM + XFS? From: Eric Sandeen To: Rupa Schomaker Cc: linux-xfs@oss.sgi.com In-Reply-To: References: <1010427293.29260.3.camel@UberGeek> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/1.0 (Preview Release) Date: 07 Jan 2002 14:09:20 -0600 Message-Id: <1010434160.14493.14.camel@stout.americas.sgi.com> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 464 Lines: 16 On Mon, 2002-01-07 at 13:54, Rupa Schomaker wrote: > I'm having toubles with the current CVS version of the XFS kernel. I > haven't had time to look at it completely, but... it could be: > > 1) mismatch between userspace and kernel (what LVM is in the XFS > kernel? I'm using the debian lvm10 userspace). Same as the stock kernel, "1.0.1rc4(ish)" -Eric -- Eric Sandeen XFS for Linux http://oss.sgi.com/projects/xfs sandeen@sgi.com SGI, Inc. From owner-linux-xfs@oss.sgi.com Mon Jan 7 13:15:51 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g07LFpA25548 for linux-xfs-outgoing; Mon, 7 Jan 2002 13:15:51 -0800 Received: from rj.sgi.com (rj.sgi.com [204.94.215.100]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g07LEwg25491 for ; Mon, 7 Jan 2002 13:14:58 -0800 Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by rj.sgi.com (8.11.4/8.11.4/linux-outbound_gateway-1.1) with ESMTP id g07KEpY09477 for ; Mon, 7 Jan 2002 12:14:51 -0800 Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id OAA4026477 for ; Mon, 7 Jan 2002 14:13:35 -0600 (CST) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id OAA45433 for ; Mon, 7 Jan 2002 14:13:35 -0600 (CST) From: Steve Lord Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id g07KCtW15202; Mon, 7 Jan 2002 14:12:55 -0600 Message-Id: <200201072012.g07KCtW15202@jen.americas.sgi.com> Date: Mon, 7 Jan 2002 14:12:55 -0600 Subject: TAKE - merge up to 2.5.2-pre9 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 19800 Lines: 497 More kdev_t gyrations, just keeping up with Linus here Date: Mon Jan 7 12:06:57 PST 2002 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:109182a linux/arch/arm/mach-iop310/arch.c - 1.1 linux/arch/arm/mm/proc-xscale.S - 1.1 linux/arch/arm/mm/proc-arm922.S - 1.1 linux/fs/freevxfs/vxfs_kcompat.h - 1.1 linux/arch/arm/mm/minicache.c - 1.1 linux/arch/arm/mm/armv5ej-early-abort.S - 1.1 linux/arch/arm/mm/armv4t-late-abort.S - 1.1 linux/arch/arm/mm/armv4t-early-abort.S - 1.1 linux/arch/arm/mm/armv4-early-abort.S - 1.1 linux/arch/arm/boot/compressed/head-xscale.S - 1.1 linux/arch/arm/mm/alignment.c - 1.1 linux/arch/arm/mach-tbox/core.c - 1.1 linux/arch/arm/mach-tbox/Makefile - 1.1 linux/arch/arm/def-configs/adi_evb - 1.1 linux/arch/arm/mach-shark/irq.c - 1.1 linux/arch/arm/def-configs/iq80310 - 1.1 linux/arch/arm/def-configs/shannon - 1.1 linux/arch/arm/def-configs/system3 - 1.1 linux/arch/arm/mach-shark/core.c - 1.1 linux/arch/arm/mach-sa1100/system3.c - 1.1 linux/include/asm-arm/arch-adifcc/adi_evb.h - 1.1 linux/arch/arm/mach-sa1100/shannon.c - 1.1 linux/include/asm-arm/arch-adifcc/dma.h - 1.1 linux/include/asm-arm/arch-adifcc/hardware.h - 1.1 linux/include/asm-arm/arch-adifcc/io.h - 1.1 linux/include/asm-arm/hardware/sa1111.h - 1.1 linux/include/asm-arm/hardware/linkup-l1110.h - 1.1 linux/include/asm-arm/hardware/cs89712.h - 1.1 linux/include/asm-arm/arch-adifcc/irq.h - 1.1 linux/include/asm-arm/arch-adifcc/irqs.h - 1.1 linux/include/asm-arm/arch-adifcc/memory.h - 1.1 linux/include/asm-arm/arch-sa1100/system3.h - 1.1 linux/include/asm-arm/arch-sa1100/shannon.h - 1.1 linux/include/asm-arm/arch-sa1100/h3600_gpio.h - 1.1 linux/include/asm-arm/arch-adifcc/param.h - 1.1 linux/include/asm-arm/arch-adifcc/serial.h - 1.1 linux/include/asm-arm/arch-adifcc/system.h - 1.1 linux/arch/arm/mach-sa1100/leds-system3.c - 1.1 linux/include/asm-arm/arch-adifcc/time.h - 1.1 linux/include/asm-arm/arch-adifcc/timex.h - 1.1 linux/include/asm-arm/arch-iop310/vmalloc.h - 1.1 linux/include/asm-arm/arch-iop310/uncompress.h - 1.1 linux/include/asm-arm/arch-iop310/timex.h - 1.1 linux/arch/arm/lib/copy_page-armv3.S - 1.1 linux/arch/arm/lib/copy_page-armv4.S - 1.1 linux/arch/arm/lib/copy_page-armv4mc.S - 1.1 linux/arch/arm/lib/copy_page-armv5te.S - 1.1 linux/include/asm-arm/arch-iop310/time.h - 1.1 linux/include/asm-arm/arch-iop310/system.h - 1.1 linux/include/asm-arm/arch-iop310/serial.h - 1.1 linux/include/asm-arm/arch-iop310/pmon.h - 1.1 linux/include/asm-arm/arch-iop310/param.h - 1.1 linux/include/asm-arm/arch-iop310/memory.h - 1.1 linux/arch/arm/mach-adifcc/* - 1.1 linux/arch/arm/mach-adifcc/Makefile - 1.1 linux/arch/arm/mach-adifcc/arch.c - 1.1 linux/arch/arm/mach-adifcc/irq.c - 1.1 linux/arch/arm/mach-adifcc/mm.c - 1.1 linux/arch/arm/mach-arc/Makefile - 1.1 linux/arch/arm/mach-arc/arch.c - 1.1 linux/arch/arm/mach-arc/debug.S - 1.1 linux/arch/arm/mach-arc/dma.c - 1.1 linux/arch/arm/mach-arc/fault.c - 1.1 linux/arch/arm/mach-arc/head.S - 1.1 linux/arch/arm/mach-arc/irq.c - 1.1 linux/arch/arm/mach-arc/mm.c - 1.1 linux/arch/arm/mach-arc/oldlatches.c - 1.1 linux/arch/arm/mach-clps711x/Makefile - 1.1 linux/arch/arm/mach-clps711x/autcpu12.c - 1.1 linux/arch/arm/mach-clps711x/cdb89712.c - 1.1 linux/arch/arm/mach-clps711x/clep7312.c - 1.1 linux/arch/arm/mach-clps711x/dma.c - 1.1 linux/arch/arm/mach-clps711x/edb7211-arch.c - 1.1 linux/arch/arm/mach-clps711x/edb7211-mm.c - 1.1 linux/arch/arm/mach-clps711x/irq.c - 1.1 linux/arch/arm/mach-clps711x/mm.c - 1.1 linux/arch/arm/mach-clps711x/p720t-leds.c - 1.1 linux/arch/arm/mach-clps711x/p720t.c - 1.1 linux/arch/arm/mach-clps711x/time.c - 1.1 linux/arch/arm/mach-clps7500/Makefile - 1.1 linux/arch/arm/mach-clps7500/core.c - 1.1 linux/include/asm-arm/arch-iop310/irqs.h - 1.1 linux/include/asm-arm/arch-iop310/irq.h - 1.1 linux/arch/arm/mach-ebsa110/core.c - 1.1 linux/include/asm-arm/arch-iop310/iq80310.h - 1.1 linux/include/asm-arm/arch-iop310/iop310.h - 1.1 linux/include/asm-arm/arch-iop310/io.h - 1.1 linux/include/asm-arm/arch-iop310/ide.h - 1.1 linux/include/asm-arm/arch-iop310/hardware.h - 1.1 linux/include/asm-arm/arch-iop310/dma.h - 1.1 linux/include/asm-arm/arch-epxa10db/tdkphy.h - 1.1 linux/include/asm-arm/arch-epxa10db/ether00.h - 1.1 linux/include/asm-arm/arch-adifcc/uncompress.h - 1.1 linux/include/asm-arm/arch-adifcc/vmalloc.h - 1.1 linux/arch/arm/mach-ftvpci/Makefile - 1.1 linux/arch/arm/mach-ftvpci/core.c - 1.1 linux/include/asm-arm/arch-clps711x/autcpu12.h - 1.1 linux/include/asm-arm/arch-clps711x/dma.h - 1.1 linux/arch/arm/mach-iop310/Makefile - 1.1 linux/include/asm-arm/arch-clps711x/hardware.h - 1.1 linux/arch/arm/mach-iop310/iop310-irq.c - 1.1 linux/arch/arm/mach-iop310/iop310-pci.c - 1.1 linux/arch/arm/mach-iop310/iq80310-irq.c - 1.1 linux/arch/arm/mach-iop310/iq80310-pci.c - 1.1 linux/arch/arm/mach-iop310/iq80310-time.c - 1.1 linux/arch/arm/mach-iop310/mm.c - 1.1 linux/arch/arm/mach-iop310/xs80200-irq.c - 1.1 linux/arch/arm/mach-l7200/Makefile - 1.1 linux/arch/arm/mach-l7200/core.c - 1.1 linux/arch/arm/mach-rpc/Makefile - 1.1 linux/arch/arm/mach-rpc/irq.c - 1.1 linux/arch/arm/mach-rpc/riscpc.c - 1.1 linux/include/asm-arm/arch-clps711x/vmalloc.h - 1.1 linux/include/asm-arm/arch-clps711x/uncompress.h - 1.1 linux/include/asm-arm/arch-clps711x/timex.h - 1.1 linux/include/asm-arm/arch-clps711x/time.h - 1.1 linux/include/asm-arm/arch-clps711x/system.h - 1.1 linux/include/asm-arm/arch-clps711x/syspld.h - 1.1 linux/include/asm-arm/arch-clps711x/param.h - 1.1 linux/include/asm-arm/arch-clps711x/memory.h - 1.1 linux/arch/arm/mach-sa1100/dma.c - 1.1 linux/include/asm-arm/arch-clps711x/keyboard.h - 1.1 linux/include/asm-arm/arch-clps711x/irqs.h - 1.1 linux/include/asm-arm/arch-clps711x/irq.h - 1.1 linux/include/asm-arm/arch-clps711x/io.h - 1.1 linux/net/ipv4/ipconfig.c - 1.26 linux/kernel/sched.c - 1.49 linux/include/linux/tpqic02.h - 1.5 linux/include/linux/hfs_sysdep.h - 1.8 linux/include/linux/fs.h - 1.140 linux/include/asm-arm/vt.h - 1.3 linux/include/asm-arm/unistd.h - 1.18 linux/include/asm-arm/unaligned.h - 1.7 linux/include/asm-arm/types.h - 1.4 linux/include/asm-arm/scatterlist.h - 1.5 linux/include/asm-arm/processor.h - 1.21 linux/include/asm-arm/proc-fns.h - 1.11 linux/include/asm-arm/proc-armv/uaccess.h - 1.11 linux/include/asm-arm/proc-armv/ptrace.h - 1.6 linux/include/asm-arm/proc-armv/pgtable.h - 1.14 linux/include/asm-arm/proc-armv/assembler.h - 1.7 linux/include/asm-arm/proc-armo/ptrace.h - 1.6 linux/include/asm-arm/pgtable.h - 1.21 linux/include/asm-arm/page.h - 1.13 linux/include/asm-arm/io.h - 1.18 linux/include/asm-arm/checksum.h - 1.10 linux/include/asm-arm/bitops.h - 1.9 linux/include/asm-arm/assembler.h - 1.5 linux/include/asm-arm/arch-rpc/time.h - 1.7 linux/include/asm-arm/arch-rpc/irq.h - 1.7 linux/include/asm-arm/arch-rpc/io.h - 1.8 linux/include/asm-arm/arch-nexuspci/time.h - 1.8 linux/include/asm-arm/arch-nexuspci/irq.h - 1.5 linux/include/asm-arm/arch-nexuspci/io.h - 1.8 linux/include/asm-arm/arch-ebsa285/time.h - 1.12 linux/include/asm-arm/arch-ebsa285/io.h - 1.13 linux/include/asm-arm/arch-ebsa110/time.h - 1.9 linux/include/asm-arm/arch-ebsa110/io.h - 1.8 linux/include/asm-arm/arch-arc/time.h - 1.7 linux/include/asm-arm/arch-arc/irq.h - 1.7 linux/include/asm-arm/arch-arc/io.h - 1.8 linux/fs/ufs/super.c - 1.22 linux/fs/sysv/inode.c - 1.27 linux/fs/sysv/ialloc.c - 1.11 linux/fs/super.c - 1.73 linux/fs/romfs/inode.c - 1.29 linux/fs/qnx4/namei.c - 1.11 linux/fs/qnx4/inode.c - 1.28 linux/fs/ntfs/support.c - 1.14 linux/fs/nfsd/vfs.c - 1.41 linux/fs/nfs/write.c - 1.35 linux/fs/nfs/read.c - 1.27 linux/fs/nfs/nfsroot.c - 1.10 linux/fs/nfs/inode.c - 1.34 linux/fs/nfs/file.c - 1.27 linux/fs/nfs/dir.c - 1.31 linux/fs/minix/inode.c - 1.27 linux/fs/minix/bitmap.c - 1.13 linux/fs/isofs/inode.c - 1.30 linux/fs/hfs/super.c - 1.12 linux/fs/hfs/inode.c - 1.15 linux/fs/fat/misc.c - 1.10 linux/fs/fat/inode.c - 1.31 linux/fs/fat/cache.c - 1.15 linux/fs/ext2/super.c - 1.23 linux/fs/ext2/inode.c - 1.38 linux/fs/coda/psdev.c - 1.19 linux/fs/affs/super.c - 1.17 linux/fs/affs/bitmap.c - 1.6 linux/fs/affs/amigaffs.c - 1.9 linux/fs/adfs/super.c - 1.15 linux/drivers/usb/usb.c - 1.62 linux/drivers/scsi/st.c - 1.38 linux/drivers/scsi/pci2000.c - 1.19 linux/drivers/isdn/sc/command.c - 1.4 linux/drivers/char/tpqic02.c - 1.17 linux/drivers/char/synclink.c - 1.20 linux/drivers/char/stallion.c - 1.18 linux/drivers/char/specialix.c - 1.13 linux/drivers/char/serial167.c - 1.12 linux/drivers/char/serial.c - 1.53 linux/drivers/char/riscom8.c - 1.14 linux/drivers/char/pcxx.c - 1.15 linux/drivers/char/n_hdlc.c - 1.13 linux/drivers/char/lp.c - 1.28 linux/drivers/char/istallion.c - 1.19 linux/drivers/char/isicom.c - 1.17 linux/drivers/char/ftape/zftape/zftape-init.c - 1.13 linux/drivers/char/esp.c - 1.15 linux/drivers/char/epca.c - 1.20 linux/drivers/char/dtlk.c - 1.17 linux/drivers/char/dsp56k.c - 1.19 linux/drivers/char/cyclades.c - 1.21 linux/drivers/cdrom/sonycd535.c - 1.16 linux/drivers/cdrom/sjcd.c - 1.13 linux/drivers/cdrom/sbpcd.c - 1.18 linux/drivers/cdrom/optcd.c - 1.14 linux/drivers/cdrom/mcdx.c - 1.11 linux/drivers/cdrom/mcd.c - 1.14 linux/drivers/cdrom/gscd.c - 1.13 linux/drivers/cdrom/cm206.c - 1.15 linux/drivers/cdrom/cdu31a.c - 1.12 linux/drivers/cdrom/aztcd.c - 1.15 linux/drivers/block/xd.c - 1.31 linux/drivers/block/rd.c - 1.45 linux/drivers/block/paride/pt.c - 1.14 linux/drivers/block/paride/pg.c - 1.13 linux/drivers/block/paride/pf.c - 1.19 linux/drivers/block/paride/pd.c - 1.25 linux/drivers/block/paride/pcd.c - 1.16 linux/drivers/block/nbd.c - 1.31 linux/arch/i386/defconfig - 1.87 linux/arch/arm/mm/proc-sa110.S - 1.23 linux/arch/arm/mm/proc-arm6,7.S - 1.19 linux/arch/arm/mm/proc-arm2,3.S - 1.10 linux/arch/arm/mm/mm-tbox.c - 1.6 linux/arch/arm/mm/mm-rpc.c - 1.10 linux/arch/arm/mm/mm-armv.c - 1.23 linux/arch/arm/mm/fault-common.c - 1.18 linux/arch/arm/mm/fault-armv.c - 1.20 linux/arch/arm/mm/fault-armo.c - 1.6 linux/arch/arm/mm/Makefile - 1.14 linux/arch/arm/lib/uaccess.S - 1.8 linux/arch/arm/lib/memcpy.S - 1.8 linux/arch/arm/lib/delay.S - 1.6 linux/arch/arm/lib/Makefile - 1.20 linux/arch/arm/kernel/traps.c - 1.23 linux/arch/arm/kernel/time.c - 1.13 linux/arch/arm/kernel/signal.c - 1.17 linux/arch/arm/kernel/setup.c - 1.24 linux/arch/arm/kernel/process.c - 1.22 linux/arch/arm/kernel/oldlatches.c - 1.10 linux/arch/arm/kernel/irq.c - 1.15 linux/arch/arm/kernel/init_task.c - 1.8 linux/arch/arm/kernel/head-armo.S - 1.8 linux/arch/arm/kernel/fiq.c - 1.12 linux/arch/arm/kernel/entry-common.S - 1.17 linux/arch/arm/kernel/entry-armv.S - 1.23 linux/arch/arm/kernel/entry-armo.S - 1.12 linux/arch/arm/kernel/dma.c - 1.9 linux/arch/arm/kernel/dma-isa.c - 1.8 linux/arch/arm/kernel/dma-arc.c - 1.11 linux/arch/arm/kernel/armksyms.c - 1.21 linux/arch/arm/kernel/Makefile - 1.20 linux/arch/arm/config.in - 1.30 linux/arch/arm/boot/compressed/head.S - 1.15 linux/arch/arm/boot/compressed/Makefile - 1.20 linux/arch/arm/boot/Makefile - 1.10 linux/arch/arm/Makefile - 1.25 linux/Makefile - 1.171 linux/include/asm-arm/hdreg.h - 1.2 linux/fs/hpfs/super.c - 1.12 linux/arch/arm/nwfpe/fpa11.c - 1.7 linux/arch/arm/nwfpe/entry26.S - 1.5 linux/drivers/char/dz.c - 1.15 linux/drivers/char/sx.c - 1.22 linux/fs/partitions/acorn.c - 1.14 linux/drivers/char/ip2main.c - 1.16 linux/arch/arm/vmlinux-armv.lds.in - 1.17 linux/arch/arm/vmlinux-armo.lds.in - 1.15 linux/arch/arm/kernel/semaphore.c - 1.10 linux/arch/arm/kernel/bios32.c - 1.25 linux/include/asm-arm/cpu-single.h - 1.8 linux/include/asm-arm/cpu-multi32.h - 1.8 linux/fs/udf/inode.c - 1.27 linux/fs/udf/super.c - 1.23 linux/arch/arm/mm/mm-armo.c - 1.9 linux/arch/arm/kernel/debug-armo.S - 1.3 linux/include/asm-arm/proc-armv/cache.h - 1.10 linux/include/asm-arm/pci.h - 1.16 linux/include/asm-arm/arch-sa1100/keyboard.h - 1.8 linux/include/asm-arm/arch-sa1100/irqs.h - 1.6 linux/include/asm-arm/arch-sa1100/io.h - 1.6 linux/include/asm-arm/arch-sa1100/hardware.h - 1.12 linux/include/asm-arm/arch-sa1100/dma.h - 1.6 linux/fs/bfs/inode.c - 1.18 linux/fs/bfs/dir.c - 1.15 linux/include/asm-arm/arch-cl7500/time.h - 1.7 linux/include/asm-arm/arch-cl7500/keyboard.h - 1.3 linux/include/asm-arm/arch-cl7500/irq.h - 1.4 linux/drivers/usb/ov511.h - 1.12 linux/drivers/usb/ov511.c - 1.27 linux/Documentation/usb/ov511.txt - 1.15 linux/drivers/usb/devio.c - 1.22 linux/drivers/char/moxa.c - 1.11 linux/drivers/char/mxser.c - 1.14 linux/drivers/char/vme_scc.c - 1.8 linux/arch/alpha/kernel/pci_iommu.c - 1.17 linux/drivers/char/amiserial.c - 1.11 linux/fs/devfs/util.c - 1.11 linux/fs/devfs/base.c - 1.27 linux/arch/arm/mm/mm-clps7500.c - 1.4 linux/drivers/char/sh-sci.c - 1.17 linux/include/linux/usb.h - 1.24 linux/drivers/usb/serial/usb-serial.h - 1.18 linux/arch/arm/lib/io-shark.c - 1.4 linux/arch/arm/kernel/arch.c - 1.10 linux/include/asm-arm/arch-shark/time.h - 1.7 linux/include/asm-arm/arch-ebsa285/vmalloc.h - 1.3 linux/include/asm-arm/arch-ebsa110/vmalloc.h - 1.3 linux/include/asm-arm/arch-shark/irq.h - 1.4 linux/include/asm-arm/arch-shark/io.h - 1.7 linux/drivers/usb/serial/usbserial.c - 1.28 linux/drivers/usb/serial/visor.c - 1.28 linux/drivers/char/rio/linux_compat.h - 1.5 linux/drivers/char/rio/rioctrl.c - 1.6 linux/drivers/char/rio/rio_linux.h - 1.5 linux/drivers/char/rio/rio_linux.c - 1.12 linux/drivers/char/rio/rio.h - 1.4 linux/include/asm-arm/arch-sa1100/time.h - 1.4 linux/include/asm-arm/arch-l7200/time.h - 1.5 linux/include/asm-arm/arch-l7200/irq.h - 1.3 linux/include/asm-arm/arch-l7200/io.h - 1.5 linux/fs/xfs/linux/xfs_super.c - 1.154 linux/drivers/usb/storage/transport.c - 1.15 linux/drivers/char/sbc60xxwdt.c - 1.12 linux/fs/jffs/inode-v23.c - 1.16 linux/arch/arm/mm/mm-l7200.c - 1.6 linux/arch/arm/mm/proc-arm720.S - 1.9 linux/include/asm-arm/arch-sa1100/assabet.h - 1.7 linux/include/asm-arm/arch-sa1100/SA-1111.h - 1.6 linux/include/asm-arm/mach/pci.h - 1.5 linux/drivers/usb/storage/shuttle_usbat.c - 1.7 linux/drivers/usb/storage/sddr09.c - 1.13 linux/drivers/usb/storage/freecom.c - 1.9 linux/drivers/media/video/tvmixer.c - 1.7 linux/drivers/char/serial_21285.c - 1.6 linux/arch/arm/tools/mach-types - 1.12 linux/arch/arm/mach-footbridge/personal-pci.c - 1.3 linux/arch/arm/mach-footbridge/netwinder-pci.c - 1.3 linux/arch/arm/mach-footbridge/ebsa285-pci.c - 1.3 linux/arch/arm/mach-footbridge/cats-pci.c - 1.3 linux/arch/arm/mach-footbridge/Makefile - 1.5 linux/drivers/md/lvm.c - 1.27 linux/drivers/md/raid1.c - 1.17 linux/drivers/md/raid5.c - 1.24 linux/arch/arm/mach-sa1100/Makefile - 1.7 linux/arch/arm/mach-sa1100/leds.c - 1.5 linux/arch/arm/mach-shark/Makefile - 1.4 linux/arch/arm/mach-shark/arch.c - 1.4 linux/arch/arm/mach-shark/mm.c - 1.4 linux/arch/arm/mm/proc-arm920.S - 1.6 linux/drivers/char/serial_amba.c - 1.7 linux/drivers/md/lvm-snap.c - 1.13 linux/drivers/md/md.c - 1.35 linux/drivers/md/xor.c - 1.6 linux/include/asm-arm/arch-tbox/irq.h - 1.2 linux/include/asm-arm/arch-tbox/time.h - 1.4 linux/include/asm-arm/arch-tbox/vmalloc.h - 1.2 linux/include/asm-arm/hardware/ioc.h - 1.3 linux/include/asm-arm/hardware/iomd.h - 1.3 linux/drivers/sound/ymfpci.c - 1.16 linux/fs/reiserfs/stree.c - 1.14 linux/fs/reiserfs/super.c - 1.12 linux/fs/reiserfs/prints.c - 1.9 linux/fs/reiserfs/namei.c - 1.14 linux/fs/reiserfs/journal.c - 1.15 linux/fs/reiserfs/inode.c - 1.21 linux/fs/reiserfs/fix_node.c - 1.13 linux/include/linux/reiserfs_fs.h - 1.15 linux/fs/reiserfs/bitmap.c - 1.9 linux/drivers/usb/storage/unusual_devs.h - 1.7 linux/arch/alpha/kernel/pci-noop.c - 1.5 linux/arch/arm/boot/compressed/head-shark.S - 1.3 linux/arch/arm/boot/compressed/ofw-shark.c - 1.4 linux/drivers/md/lvm-fs.c - 1.5 linux/include/asm-arm/arch-integrator/time.h - 1.3 linux/include/asm-arm/arch-integrator/io.h - 1.3 linux/arch/arm/mach-integrator/pci.c - 1.3 linux/arch/arm/mach-integrator/pci_v3.c - 1.4 linux/arch/arm/tools/Makefile - 1.5 linux/arch/arm/tools/getconstants.c - 1.5 linux/include/asm-arm/arch-l7200/keyboard.h - 1.3 linux/arch/arm/mach-ebsa110/Makefile - 1.2 linux/arch/arm/mach-ebsa110/arch.c - 1.3 linux/arch/arm/mach-ebsa110/io.c - 1.6 linux/arch/arm/mach-ebsa110/irq.c - 1.2 linux/arch/arm/mach-ebsa110/mm.c - 1.2 linux/include/asm-arm/arch-sa1100/pcmcia.h - 1.2 linux/include/asm-arm/hardware/clps7111.h - 1.2 linux/arch/arm/mach-sa1100/dma-sa1100.c - 1.5 linux/arch/arm/mach-sa1100/dma-sa1111.c - 1.5 linux/arch/arm/mach-sa1100/dma.h - 1.4 linux/include/asm-arm/hardware/ep7212.h - 1.3 linux/include/asm-arm/proc-armv/pgalloc.h - 1.2 linux/fs/freevxfs/vxfs_super.c - 1.6 linux/fs/freevxfs/vxfs_subr.c - 1.5 linux/fs/freevxfs/vxfs_olt.c - 1.4 linux/fs/freevxfs/vxfs_lookup.c - 1.3 linux/fs/freevxfs/vxfs_inode.c - 1.8 linux/fs/freevxfs/vxfs_fshead.c - 1.4 linux/fs/freevxfs/vxfs_extern.h - 1.4 linux/fs/freevxfs/vxfs_bmap.c - 1.5 linux/fs/freevxfs/vxfs.h - 1.2 linux/drivers/usb/pwc.h - 1.9 linux/drivers/usb/pwc-ioctl.h - 1.4 linux/drivers/usb/pwc-if.c - 1.9 linux/drivers/usb/pwc-ctrl.c - 1.7 linux/drivers/usb/catc.c - 1.4 linux/arch/arm/mach-ebsa110/hardware.h - 1.2 linux/fs/sysv/super.c - 1.7 linux/drivers/char/ser_a2232.c - 1.4 linux/drivers/char/w83877f_wdt.c - 1.5 linux/drivers/usb/storage/jumpshot.c - 1.5 linux/drivers/usb/storage/datafab.c - 1.5 linux/include/asm-arm/arch-sa1100/flexanet.h - 1.2 linux/arch/arm/def-configs/flexanet - 1.2 linux/arch/arm/mach-sa1100/yopy.c - 1.2 linux/arch/arm/mach-sa1100/xp860.c - 1.3 linux/arch/arm/mach-sa1100/simpad.c - 1.3 linux/arch/arm/mach-sa1100/sherman.c - 1.2 linux/arch/arm/mach-sa1100/sa1111.h - 1.3 linux/arch/arm/mach-sa1100/sa1111.c - 1.3 linux/include/asm-arm/arch-anakin/io.h - 1.2 linux/arch/arm/kernel/compat.c - 1.3 linux/arch/arm/kernel/entry-header.S - 1.3 linux/arch/arm/mach-sa1100/pfs168.c - 1.3 linux/include/asm-arm/arch-anakin/time.h - 1.2 linux/arch/arm/mach-sa1100/pangolin.c - 1.3 linux/arch/arm/mach-sa1100/omnimeter.c - 1.2 linux/arch/arm/mach-sa1100/neponset.c - 1.4 linux/arch/arm/mach-sa1100/leds.h - 1.4 linux/arch/arm/mach-sa1100/leds-flexanet.c - 1.2 linux/arch/arm/mach-sa1100/leds-assabet.c - 1.3 linux/arch/arm/mach-sa1100/lart.c - 1.2 linux/arch/arm/mach-sa1100/jornada720.c - 1.3 linux/arch/arm/mach-sa1100/irq.c - 1.2 linux/include/asm-arm/mach/serial_sa1100.h - 1.2 linux/arch/arm/mach-sa1100/huw_webpanel.c - 1.2 linux/arch/arm/mach-sa1100/graphicsclient.c - 1.4 linux/arch/arm/mach-sa1100/assabet.c - 1.4 linux/arch/arm/mach-sa1100/cerf.c - 1.3 linux/arch/arm/mach-sa1100/cpu-sa1100.c - 1.2 linux/arch/arm/mach-sa1100/cpu-sa1110.c - 1.3 linux/arch/arm/mach-sa1100/generic.h - 1.2 linux/arch/arm/mach-sa1100/generic.c - 1.3 linux/arch/arm/mach-sa1100/freebird.c - 1.3 linux/arch/arm/mach-sa1100/flexanet.c - 1.2 linux/drivers/usb/usbnet.c - 1.10 linux/drivers/char/serial_tx3912.c - 1.4 linux/drivers/char/ite_gpio.c - 1.2 linux/fs/jffs2/super.c - 1.4 linux/drivers/md/multipath.c - 1.4 linux/include/asm-arm/arch-sa1100/graphicsmaster.h - 1.2 linux/include/asm-arm/arch-sa1100/h3600.h - 1.2 linux/arch/arm/mm/mm-ftvpci.c - 1.2 linux/arch/arm/mach-sa1100/h3600.c - 1.3 linux/arch/arm/mach-sa1100/graphicsmaster.c - 1.3 linux/arch/arm/mach-sa1100/adsbitsy.c - 1.2 linux/arch/arm/lib/putuser.S - 1.2 linux/arch/arm/lib/getuser.S - 1.2 linux/drivers/char/shwdt.c - 1.3 linux/arch/arm/mach-epxa10db/mm.c - 1.2 linux/include/asm-arm/arch-epxa10db/io.h - 1.2 linux/arch/arm/mach-sa1100/pm.c - 1.2 linux/arch/arm/mach-sa1100/sleep.S - 1.2 linux/include/asm-arm/arch-epxa10db/time.h - 1.2 linux/arch/alpha/lib/dec_and_lock.c - 1.3 linux/fs/jbd/journal.c - 1.3 linux/arch/arm/mm/proc-arm1020.S - 1.2 linux/arch/arm/mm/proc-arm926.S - 1.2 linux/fs/ext3/ialloc.c - 1.5 linux/fs/ext3/super.c - 1.5 linux/fs/reiserfs/procfs.c - 1.2 linux/fs/sysv/ChangeLog - 1.3 linux/init/do_mounts.c - 1.7 From owner-linux-xfs@oss.sgi.com Mon Jan 7 13:36:59 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g07LaxP26391 for linux-xfs-outgoing; Mon, 7 Jan 2002 13:36:59 -0800 Received: from mail.ocs.com.au (mail.ocs.com.au [203.34.97.2]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g07Lalg26368 for ; Mon, 7 Jan 2002 13:36:47 -0800 Received: (qmail 541 invoked from network); 7 Jan 2002 20:36:43 -0000 Received: from ocs3.intra.ocs.com.au (192.168.255.3) by mail.ocs.com.au with SMTP; 7 Jan 2002 20:36:43 -0000 Received: by ocs3.intra.ocs.com.au (Postfix, from userid 16331) id E91ED300095; Tue, 8 Jan 2002 07:36:41 +1100 (EST) Received: from ocs3.intra.ocs.com.au (localhost [127.0.0.1]) by ocs3.intra.ocs.com.au (Postfix) with ESMTP id CFC5294; Tue, 8 Jan 2002 07:36:41 +1100 (EST) X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 From: Keith Owens To: Adrian Head Cc: Linux XFS Mailing List , linux-lvm@sistina.com Subject: Re: Unable to get XFS, ext3, reiserfs & LVM to coexist happily In-reply-to: Your message of "Tue, 08 Jan 2002 02:50:27 +1000." <200201071648.IAA08511@sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 08 Jan 2002 07:36:36 +1100 Message-ID: <687.1010435796@ocs3.intra.ocs.com.au> Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 2264 Lines: 49 On Tue, 8 Jan 2002 02:50:27 +1000, Adrian Head wrote: >On Tue, 8 Jan 2002 00:41, Keith Owens wrote: >> On Tue, 8 Jan 2002 00:08:11 +1000, >> Adrian Head wrote: >> > >> >Entering kdb (current=0xd600e000, pid 940) Oops: Oops >> >due to oops @ 0xb800 >> >eax = 0xffffffff ebx = 0xd600e000 ecx = 0x0000b800 edx = 0xc018fd25 >> >esi = 0x00000008 edi = 0xd600e000 esp = 0xd600ff0c eip = 0x0000b800 >> >ebp = 0xd600ff30 xss = 0x00000018 xcs = 0x00000010 eflags = 0x00010086 >> >xds = 0x00000018 xes = 0x00000018 origeax = 0xffffffff ®s = 0xd600fed8 >> >kdb> bt >> > EBP EIP Function(args) >> >0xd600ff30 0x0000b800 +0xb800 (0x1) >> > kernel 0x0 0x0 0x0 >> > 0xc011ce83 dequeue_signal+0x43 (0xd600e560, 0xd600ff30, >> >0xd600e560, 0xd600ffc4, 0xc01392ff) >> > kernel .text 0xc0100000 0xc011ce40 >> > 0xc011cef0 0xc01069b9 do_signal+0x59 (0x11, 0xbfffec40, 0xbfffebb0, 0x8, >> > 0x11) kernel .text 0xc0100000 0xc0106960 0xc0106c00 0xc0106d54 >> > signal_return+0x14 >> > kernel .text 0xc0100000 0xc0106d40 >> > 0xc0106d58 >> >> kdb is correctly reporting the current eip, but the kernel has taken a >> swan dive into nowhere. It looks like the chunk of code below. To >> confirm, run >> >> objdump --start-addr=0xc011ce40 --stop-address=0xc011ce90 vmlinux > >How did you get 0xc011ce40 and 0xc011ce90? Do they come from above? How are >they derived? Just interested. The backtrace shows a branch out of the kernel, the last good address is the starting point to find out why we branched to an invalid address. Back trace is listed as 0xc011ce83 dequeue_signal+0x43, subtract 0x43 so dequeue_signal starts at 0xc011ce40. Stop address is the backtrace entry plus a bit to bracket the probable call instruction. >vmlinux - where does that come from? I assume it is not the compressed >kernel found in /boot. The kernel build creates vmlinux under /usr/src/linux or wherever you build your kernel. All architectures build vmlinux then modify it as required for booting. Binutils tools like objdump do not understand bzImage, they need the original ELF kernel, i.e. vmlinux. From owner-linux-xfs@oss.sgi.com Mon Jan 7 13:37:36 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g07Lbar26525 for linux-xfs-outgoing; Mon, 7 Jan 2002 13:37:36 -0800 Received: from sgi.com (sgi-too.SGI.COM [204.94.211.39]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g07LbNg26454 for ; Mon, 7 Jan 2002 13:37:23 -0800 Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id MAA02435 for ; Mon, 7 Jan 2002 12:35:28 -0800 (PST) mail_from (lord@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id OAA4028480; Mon, 7 Jan 2002 14:36:04 -0600 (CST) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id OAA48994; Mon, 7 Jan 2002 14:36:04 -0600 (CST) Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id g07KZO415721; Mon, 7 Jan 2002 14:35:24 -0600 Subject: Re: file corruption during emacs build on XFS logical volume From: Steve Lord To: Sean Neakums Cc: Linux XFS In-Reply-To: <1010429513.7120.35.camel@jen.americas.sgi.com> References: <1010174871.30053.6.camel@jen.americas.sgi.com> <1010176193.2938.14.camel@UberGeek> <1010176393.30037.9.camel@jen.americas.sgi.com> <1010179700.30053.13.camel@jen.americas.sgi.com> <1010187371.30053.32.camel@jen.americas.sgi.com> <6uy9jdhdsr.fsf@zork.zork.net> <6upu4ph8c5.fsf@zork.zork.net> <3C37511F.6050809@sgi.com> <6uheq0fsu6.fsf@zork.zork.net> <1010429513.7120.35.camel@jen.americas.sgi.com> Content-Type: multipart/mixed; boundary="=-rqdlBHSCOowOLYlhgOu5" X-Mailer: Evolution/1.0.0.99+cvs.2001.12.18.08.57 (Preview Release) Date: 07 Jan 2002 14:35:24 -0600 Message-Id: <1010435724.15632.5.camel@jen.americas.sgi.com> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 2160 Lines: 63 --=-rqdlBHSCOowOLYlhgOu5 Content-Type: text/plain Content-Transfer-Encoding: 7bit On Mon, 2002-01-07 at 12:51, Steve Lord wrote: > On Sat, 2002-01-05 at 14:25, Sean Neakums wrote: > > begin Stephen Lord quotation: > > > > > OK, thanks, this narrows it down even more than I had - I was > > > running a kernel from Dec 22nd and recreating the problem. I had > > > tried the individual patches to the I/O path and failed to recreate > > > it - but maybe I should try that again. > > > > I just found a kernel from December 8 (I had removed it from > > lilo.conf, but forgotten to delete the kernel itself and the modules) > > and I cannot recreate on that. > > > > Sean, can you see if the attached patch against the current cvs tree > fixes the problem for you? So far I have not been able to reproduce > with this change. > And here is a patch I prefer you test - since I think this is more like a real fix instead of a go back and mask the original problem again Steve -- Steve Lord voice: +1-651-683-3511 Principal Engineer, Filesystem Software email: lord@sgi.com --=-rqdlBHSCOowOLYlhgOu5 Content-Disposition: attachment; filename=emacs.patch Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; 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/pagebuf/page_buf_io.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.15706-0/linux/fs/pagebuf/page_buf_io.c_1.104 Mon Jan 7= 14:32:15 2002 +++ linux/fs/pagebuf/page_buf_io.c Mon Jan 7 13:56:13 2002 @@ -121,7 +121,9 @@ PAGE_BUG(page); if (!bh || !buffer_delay(bh)) BUG(); + lock_buffer(bh); clear_bit(BH_Delay, &bh->b_state); + unlock_buffer(bh); } =20 static inline int --=-rqdlBHSCOowOLYlhgOu5-- From owner-linux-xfs@oss.sgi.com Mon Jan 7 13:45:18 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g07LjIT26820 for linux-xfs-outgoing; Mon, 7 Jan 2002 13:45:18 -0800 Received: from deliverator.sgi.com (deliverator.sgi.com [204.94.214.10]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g07LjFg26794 for ; Mon, 7 Jan 2002 13:45:15 -0800 Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id MAA09239 for ; Mon, 7 Jan 2002 12:44:56 -0800 (PST) mail_from (lord@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id OAA4027108; Mon, 7 Jan 2002 14:43:56 -0600 (CST) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id OAA49750; Mon, 7 Jan 2002 14:43:55 -0600 (CST) Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id g07KhF615743; Mon, 7 Jan 2002 14:43:15 -0600 Subject: Re: XFS fails fsx-linux.c - log dump From: Steve Lord To: Shawn Starr Cc: Keith Owens , linux-xfs@oss.sgi.com In-Reply-To: References: Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/1.0.0.99+cvs.2001.12.18.08.57 (Preview Release) Date: 07 Jan 2002 14:43:15 -0600 Message-Id: <1010436195.15650.8.camel@jen.americas.sgi.com> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 510 Lines: 22 On Sun, 2002-01-06 at 17:58, Shawn Starr wrote: > > Here's the log dump from the current fault: > > Shawn. > > ---- > Is the point at which this fails deterministic, or does it vary? I am running a kernel with what I think is the fix to the emacs build bug, and so far it is holding up well - a long way past the example failure point in your output. Steve -- Steve Lord voice: +1-651-683-3511 Principal Engineer, Filesystem Software email: lord@sgi.com From owner-linux-xfs@oss.sgi.com Mon Jan 7 14:26:38 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g07MQcR27757 for linux-xfs-outgoing; Mon, 7 Jan 2002 14:26:38 -0800 Received: from shakti.rupa.com (foobar@cx838204-a.alsv1.occa.home.com [24.16.83.66]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g07MQYg27731 for ; Mon, 7 Jan 2002 14:26:34 -0800 Received: from shakti.rupa.com (localhost [127.0.0.1]) by localhost.rupa.com (Postfix) with ESMTP id 1C5EB48FCC; Mon, 7 Jan 2002 13:26:32 -0800 (PST) Received: by shakti.rupa.com (Postfix, from userid 9) id 05DBF48FC8; Mon, 7 Jan 2002 13:26:32 -0800 (PST) Received: from 192.168.1.20 by 192.168.1.20 with nntp; 7 Jan 2002 13:26:31 PST To: linux-xfs@oss.sgi.com Subject: Re: GRUB + LVM + XFS? References: <1010427293.29260.3.camel@UberGeek> <1010434160.14493.14.camel@stout.americas.sgi.com> From: Rupa Schomaker Date: Mon, 07 Jan 2002 13:26:31 -0800 Message-Id: User-Agent: Gnus/5.090005 (Oort Gnus v0.05) XEmacs/21.4 (Copyleft, i386-debian-linux) Cancel-Lock: sha1:ourH/Be1Ql0XDDyh+6HlWLZcZ84= MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii NNTP-Posting-Host: 192.168.1.20 X-Spam-Status: No, hits=-99 required=5 tests=SUBJ_ENDS_IN_Q_MARK,USER_IN_W HITELIST Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 619 Lines: 25 Eric Sandeen writes: > On Mon, 2002-01-07 at 13:54, Rupa Schomaker wrote: > >> I'm having toubles with the current CVS version of the XFS kernel. I >> haven't had time to look at it completely, but... it could be: >> >> 1) mismatch between userspace and kernel (what LVM is in the XFS >> kernel? I'm using the debian lvm10 userspace). > > Same as the stock kernel, "1.0.1rc4(ish)" Userspace in debian is 1.0.1release-1 -- do you think this would cause problems? > -Eric > > -- > Eric Sandeen XFS for Linux http://oss.sgi.com/projects/xfs > sandeen@sgi.com SGI, Inc. > -- -rupa From owner-linux-xfs@oss.sgi.com Mon Jan 7 17:48:52 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g081mqA16482 for linux-xfs-outgoing; Mon, 7 Jan 2002 17:48:52 -0800 Received: from mta05ps.bigpond.com (mta05ps.bigpond.com [144.135.25.137]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g081mjg16459 for ; Mon, 7 Jan 2002 17:48:45 -0800 Message-Id: <200201080148.g081mjg16459@oss.sgi.com> Received: from there ([144.135.25.84]) by mta05ps.bigpond.com (Netscape Messaging Server 4.15) with SMTP id GPLH8P00.7NE; Tue, 8 Jan 2002 10:55:37 +1000 Received: from CPE-144-137-138-230.qld.bigpond.net.au ([144.137.138.230]) by psmam06.mailsvc.email.bigpond.com(MailRouter V3.0h 116/708914); 08 Jan 2002 10:48:36 Content-Type: text/plain; charset="us-ascii" From: Adrian Head To: Rupa Schomaker , linux-xfs@oss.sgi.com Subject: Re: GRUB + LVM + XFS? Date: Tue, 8 Jan 2002 10:48:11 +1000 X-Mailer: KMail [version 1.3.1] References: <1010427293.29260.3.camel@UberGeek> In-Reply-To: Cc: linux-lvm@sistina.com MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 1821 Lines: 49 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Tue, 8 Jan 2002 05:54, Rupa Schomaker wrote: > I'm having toubles with the current CVS version of the XFS kernel. I > haven't had time to look at it completely, but... it could be: > > 1) mismatch between userspace and kernel (what LVM is in the XFS > kernel? I'm using the debian lvm10 userspace). > > 2) bad config > > 3) ??? > > A quick "bt" at boot in kdb shows that devfs is in the call path. No, > I haven't had time to write everything down. :( Man, I wish there was > an easy to dump the kdb info or an OOPs to disk... Well all I do is for getting kdb output is to use a serial console and another computer - then cut and past then send ;-). It is very interesting that devfs is referenced - there was a LVM memory corruption problem and a patch for LVM/devfs - it can be found here: http://marc.theaimsgroup.com/?l=linux-xfs&m=101031443221058&w=2 - From my experience it seems that LVM 1.0.1rc4(ish) is way more robust than the updated LVM 1.0.1 or even CVS LVM 1.0.1 yesterday. However, not everything works as expected with either. You can find a results table for a few tests I have conducted here: (of course YMMV) http://marc.theaimsgroup.com/?l=linux-lvm&m=100994364215110&w=2 I think you would be very interested in the discussions and activity that has been occuring on the linux-xfs & linux-lvm lists at the moment regarding XFS and LVM. If you are seeing problems I would be very interested in finding out how your problems differ from mine. - -- Adrian Head (Public Key available on request.) -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE8OkHO8ZJI8OvSkAcRAsHkAJ9OlEWOQMxiXXsJ0OzsllI7icT8pQCeLfM2 95t821X+y25nYdf3WCDRg9k= =rjIv -----END PGP SIGNATURE----- From owner-linux-xfs@oss.sgi.com Mon Jan 7 18:12:51 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g082CpU17601 for linux-xfs-outgoing; Mon, 7 Jan 2002 18:12:51 -0800 Received: from coredump.sh0n.net (qmailremote@CPEdeadbeef0000.cpe.net.cable.rogers.com [24.100.234.67]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g082Cjg17579 for ; Mon, 7 Jan 2002 18:12:45 -0800 Received: (qmail 7724 invoked from network); 8 Jan 2002 01:13:30 -0000 Received: from coredump.sh0n.net (sh0n@24.100.234.67) by coredump.sh0n.net with SMTP; 8 Jan 2002 01:13:30 -0000 Date: Mon, 7 Jan 2002 20:13:28 -0500 (EST) From: Shawn Starr To: linux-xfs@oss.sgi.com Subject: Re: XFS fails fsx-linux.c - log dump In-Reply-To: <1010436195.15650.8.camel@jen.americas.sgi.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 1077 Lines: 43 Well, it is failing every time. Because both times i ran the utility it generated different failed results. It should be kept in mind that the -mjc branch contains Riel's new VM patches (rmap-10c soon rmap-11). Which might affect somethings but im not able to determine it right now. I do not notice file system corruption with normal/heavy use (dbench 60) on a Pentium 200. There are inconsistancies, I can also check with a 2.4.17 vanilla branch with XFS only applied (from cvs). Shawn. On 7 Jan 2002, Steve Lord wrote: > On Sun, 2002-01-06 at 17:58, Shawn Starr wrote: > > > > Here's the log dump from the current fault: > > > > Shawn. > > > > ---- > > > > Is the point at which this fails deterministic, or does it vary? I am > running a kernel with what I think is the fix to the emacs build bug, > and so far it is holding up well - a long way past the example failure > point in your output. > > Steve > > > -- > > Steve Lord voice: +1-651-683-3511 > Principal Engineer, Filesystem Software email: lord@sgi.com > > > From owner-linux-xfs@oss.sgi.com Mon Jan 7 19:44:52 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g083iqO19101 for linux-xfs-outgoing; Mon, 7 Jan 2002 19:44:52 -0800 Received: from sgi.com (sgi-too.SGI.COM [204.94.211.39]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g083ihg19074 for ; Mon, 7 Jan 2002 19:44:43 -0800 Received: from grucom2.gru.net (grucom2.gru.net [209.251.129.7]) by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id SAA05218 for ; Mon, 7 Jan 2002 18:42:44 -0800 (PST) mail_from (jka@mbi.ufl.edu) Received: from [209.251.150.141] by grucom2.gru.net (NTMail 7.00.0022/NU4112.00.db1c8a4b) with ESMTP id aeersaaa for linux-xfs@oss.sgi.com; Mon, 7 Jan 2002 21:43:43 -0500 Message-ID: <017101c197ef$9f072cb0$0100a8c0@inthewings.inthewings.net> From: "Jon Akers" To: References: Subject: cmpci.c fix in sound drivers Date: Mon, 7 Jan 2002 21:53:15 -0500 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_016E_01C197C5.B59532D0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 1600 Lines: 55 This is a multi-part message in MIME format. ------=_NextPart_000_016E_01C197C5.B59532D0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Was having a problem compiling 2.5.2pre9, and it turns out to be another missed change that was sprinkled throughout the kernel. Only three lines were affected in this file, but it was enough to break my compile if I wanted sound. ------=_NextPart_000_016E_01C197C5.B59532D0 Content-Type: application/octet-stream; name="cmpci.c-patch" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="cmpci.c-patch" diff --unified --recursive --new-file linux/drivers/sound/cmpci.c linux.fix= ed/drivers/sound/cmpci.c --- linux/drivers/sound/cmpci.c Fri Jan 4 20:01:24 2002 +++ linux.fixed/drivers/sound/cmpci.c Mon Jan 7 20:49:50 2002 @@ -1440,7 +1440,7 @@ =20 static int cm_open_mixdev(struct inode *inode, struct file *file) { - int minor =3D MINOR(inode->i_rdev); + int minor =3D minor(inode->i_rdev); struct cm_state *s =3D devs; =20 while (s && s->dev_mixer !=3D minor) @@ -2190,7 +2190,7 @@ =20 static int cm_open(struct inode *inode, struct file *file) { - int minor =3D MINOR(inode->i_rdev); + int minor =3D minor(inode->i_rdev); struct cm_state *s =3D devs; unsigned char fmtm =3D ~0, fmts =3D 0; =20 @@ -2445,7 +2445,7 @@ =20 static int cm_midi_open(struct inode *inode, struct file *file) { - int minor =3D MINOR(inode->i_rdev); + int minor =3D minor(inode->i_rdev); struct cm_state *s =3D devs; unsigned long flags; =20 ------=_NextPart_000_016E_01C197C5.B59532D0-- From owner-linux-xfs@oss.sgi.com Mon Jan 7 20:50:32 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g084oWP20120 for linux-xfs-outgoing; Mon, 7 Jan 2002 20:50:32 -0800 Received: from sgi.com (sgi-too.SGI.COM [204.94.211.39]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g084oPg20095 for ; Mon, 7 Jan 2002 20:50:25 -0800 Received: from boing.melbourne.sgi.com (boing.melbourne.sgi.com [134.14.55.141]) by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id TAA03552 for ; Mon, 7 Jan 2002 19:48:24 -0800 (PST) mail_from (tes@boing.melbourne.sgi.com) Received: (from tes@localhost) by boing.melbourne.sgi.com (SGI-8.9.3/8.9.3) id OAA10716; Tue, 8 Jan 2002 14:48:51 +1100 (AEDT) Date: Tue, 8 Jan 2002 14:48:51 +1100 From: Timothy Shimmin To: niu@mountainviewdata.com Cc: linux-xfs@oss.sgi.com Subject: Re: XFS ACLs Message-ID: <20020108144851.K1500056@boing.melbourne.sgi.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 X-Mailer: Mutt 1.0us In-Reply-To: ; from niu@mountainviewdata.com on Wed, Dec 26, 2001 at 11:01:38AM +0800 X-MIME-Autoconverted: from 8bit to quoted-printable by sgi.com id TAA03552 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id g084oPg20096 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 2008 Lines: 51 Hi John, On Wed, Dec 26, 2001 at 11:01:38AM +0800, niu@mountainviewdata.com wrote: > Hi XFS guys, > > I'm using ACLs of linux XFS to manage my share files. Recently, I > encounter a confused problem: If a user belongs to multiple groups, and > all the groups are set ALCs to a file(directory), then how about the > user's permission to this file(directory)? > > I've do some test, the result looks like that: for file, the user's > permission is the combination(OR operation) of his groups ACLs; but > for directory, the user's permission looks weird, it's neither OR > operation nor AND operation of his groups ACLs. > > Could you explain more details about the rule of XFS ACLs? Thank you. > > John > > XFS ACLs are based on the Posix 1003.1e draft standard 17 (Section 23). This withdrawn Posix ACL standard can be downloaded at: http://wt.xpilot.org/posix.1e/download.html Andreas Grünbacher's site: http://acl.bestbits.at/ is also a useful resource. So if you are going to use ACLs it is worth doing some ACL reading :) I don't fully understand your problem. Perhaps you can list the set of commands that you used and the output from them. Checkout the section 23.1.2 (Relationship with File permission Bits) to see how the ACL ACEs match up with the standard file permission bits. In particular one would note that the group permission bits reflect the Mask permission bits when a Mask ACE exists and Section B.23.3.6 (in Annex B) discusses reasons why this scheme was chosen. (Also worthy of note, is that if you create a file whose parent dir has a default ACL, then it's ACE permissions are set by the _intersection_ of the respective default ACEs permission bits and the mode bits of the parameter to open/creat. If you have a MASK ACE (section 5.3.1.2), then the ACE permissions on the new file will have a MASK ACE equal to the intersection of the default MASK ACE permission bits and the standard group permission bits of the parameter to open/creat.) --Tim From owner-linux-xfs@oss.sgi.com Mon Jan 7 21:18:35 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g085IZL20732 for linux-xfs-outgoing; Mon, 7 Jan 2002 21:18:35 -0800 Received: from shakti.rupa.com (foobar@cx838204-a.alsv1.occa.home.com [24.16.83.66]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g085G2g20695 for ; Mon, 7 Jan 2002 21:16:02 -0800 Received: from shakti.rupa.com (localhost [127.0.0.1]) by localhost.rupa.com (Postfix) with ESMTP id 1AF0E48FE0; Mon, 7 Jan 2002 20:15:59 -0800 (PST) Received: by shakti.rupa.com (Postfix, from userid 9) id 6DE3148FDD; Mon, 7 Jan 2002 20:15:57 -0800 (PST) Received: from 192.168.1.20 by 192.168.1.20 with nntp; 7 Jan 2002 20:15:57 PST To: linux-xfs@oss.sgi.com Subject: Can't boot 2.4.17 (was Re: GRUB + LVM + XFS?) References: <1010427293.29260.3.camel@UberGeek> <200201080148.g081mjg16459@oss.sgi.com> From: Rupa Schomaker Date: Mon, 07 Jan 2002 20:15:56 -0800 Message-Id: User-Agent: Gnus/5.090005 (Oort Gnus v0.05) XEmacs/21.4 (Copyleft, i386-debian-linux) Cancel-Lock: sha1:xdXhuZ0+6cTBjc3VLKpJhgVoIWI= MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="=-=-=" NNTP-Posting-Host: 192.168.1.20 X-Spam-Status: No, hits=-104 required=5 tests=COPYRIGHT_CLAIMED,BALANCE_FO R_LONG,USER_IN_WHITELIST Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 44807 Lines: 1470 --=-=-= With Adrian's prodding, I've gotten a capture of the boot process when I boot a newly built 2.4.17 from CVS (Jan 5 2002ish) at oss.sgi.org. I'm sendign this to the xfs list only -- I can send it to more places if this is not the appropriate place to do so. 2.4.9 is working fine. 2.4.17 fails to bood during the change_root phase. Back trace from kdb: Console just before oops: RAMDISK: Compressed image found at block 0 Freeing initrd memory: 1135k freed VFS: Mounted root (ext2 filesystem). Mounted devfs on /dev LVM version 1.0.1-rc4(ish)(03/10/2001) module loaded cramfs: wrong magic lvm -- lvm_blk_ioctl: unknown command 0x5310 XFS mounting filesystem lvm(58,0) VFS: Mounted root (xfs filesystem) readonly. devfs: devfs_do_symlink(root): could not append to parent, err: -17 change_root: old root has d_count=2 Entering kdb (current=0xc1a08000, pid 1) Oops: invalid operand due to oops @ 0xc0126cda kdb> bt EBP EIP Function(args) 0xc1a09f14 0xc0126cda kmem_cache_create+0x2b6 (0xc02fe1c7, 0x14, 0x20, 0x20000, 0x0) kernel .text 0xc0100000 0xc0126a24 0xc0126d1c 0xc1a09f34 0xc041f9a3 mount_devfs_fs+0x17 (0xc02f4cc0, 0x2, 0xffffff9e, 0xffffff ff, 0x10) kernel .text.init 0xc0418000 0xc041f98c 0xc041fa0 0 0xc1a09fb8 0xc041f1b9 change_root+0xf9 (0x0, 0xc02ed7a3) kernel .text.init 0xc0418000 0xc041f0c0 0xc041f32 0 0xc1a09fdc 0xc0105239 prepare_namespace+0x12d kernel .text 0xc0100000 0xc010510c 0xc0105258 0xc1a09fec 0xc0105267 init+0xf kernel .text 0xc0100000 0xc0105258 0xc0105370 0xc01056e4 kernel_thread+0x28 kernel .text 0xc0100000 0xc01056bc 0xc01056f4 output from ksymoops: ksymoops 2.4.3 on i686 2.4.9-xfs-lvm. Options used -V (specified) -K (specified) -l /proc/modules (default) -o /lib/modules/2.4.17-xfs-lvm (specified) -m /boot/System.map-2.4.17-xfs-lvm (specified) No modules in ksyms, skipping objects No ksyms, skipping lsmod invalid operand: 0000 CPU: 0 EIP: 0010:[] Not tainted Using defaults from ksymoops -t elf32-i386 -a i386 EFLAGS: 00010246 eax: 00000000 ebx: c1a765b0 ecx: c1a76618 edx: c1a765a8 esi: c1a765a1 edi: c02fe1d4 ebp: c1a09f14 esp: c1a09ef4 ds: 0018 es: 0018 ss: 0018 Process swapper (pid: 1, stackpage=c1a09000) Stack: c1a09f64 e7ec2360 c1aaf4ce c1a09f10 c1a765d0 c0464ee8 00000004 0000000c c1a09f34 c041f9a3 c02fe1c7 00000014 00000020 00020000 00000000 00000000 c1a09fb8 c041f1b9 c02f4cc0 00000002 ffffff9e ffffffff 00000010 c1a09fd8 Call Trace: [] [] [] [] [] Code: 0f 0b 8b 12 81 fa 88 92 3f c0 75 da a1 88 92 3f c0 89 48 04 >>EIP; c0126cda <===== Trace; c01169e6 Trace; c0106e32 Trace; c0105238 Trace; c0105266 Trace; c01056e4 Code; c0126cda 00000000 <_EIP>: Code; c0126cda <===== 0: 0f 0b ud2a <===== Code; c0126cdc 2: 8b 12 mov (%edx),%edx Code; c0126cde 4: 81 fa 88 92 3f c0 cmp $0xc03f9288,%edx Code; c0126ce4 a: 75 da jne ffffffe6 <_EIP+0xffffffe6> c0126cc0 Code; c0126ce6 c: a1 88 92 3f c0 mov 0xc03f9288,%eax Code; c0126cea 11: 89 48 04 mov %ecx,0x4(%eax) <0>Kernel panic: Attempted to kill init! Some config info: System (from proc): model name : Pentium III (Katmai) stepping : 2 cpu MHz : 501.149 MemTotal: 640512 kB 2 Promise controllers: Bus 0, device 13, function 0: Unknown mass storage controller: Promise Technology, Inc. 20267 (rev 2). Bus 0, device 15, function 0: Unknown mass storage controller: Promise Technology, Inc. 20267 (#2) (rev 2) 4 Maxtor hard drives: hde: Maxtor 54610H6, ATA DISK drive hdg: Maxtor 54610H6, ATA DISK drive hdi: Maxtor 54610H6, ATA DISK drive hdk: Maxtor 54610H6, ATA DISK drive I'm using MD to get a RAID1 for my maxtor drives: /dev/md1 is a slice from hde and hdg and makes up /boot /dev/md2 is a slice from hde and hdg and makes up a swap partition /dev/md3 is a slice from hde and hdg and makes up one PV for the LVM /dev/md4 is a slice from hdi and hdk and makes up a swap partition /dev/md5 is a slice from hdi and hdk and makes up one PV for the LVM I'm using LVM for all partitions other than /boot. This means that I also use LVM for my root partition. I'm using a initrd made with lvmcreate_initrd from debian's lvm10 package (1.0.1release-1). I have one volume group (shaktivg). Attached are my config and the full capture of the boot process. --=-=-= Content-Disposition: attachment; filename=config-2.4.17-xfs-lvm Content-Description: config # # Automatically generated by make menuconfig: don't edit # CONFIG_X86=y CONFIG_ISA=y # CONFIG_SBUS is not set CONFIG_UID16=y # # Code maturity level options # CONFIG_EXPERIMENTAL=y # # Loadable module support # CONFIG_MODULES=y CONFIG_MODVERSIONS=y CONFIG_KMOD=y # # Processor type and features # # CONFIG_M386 is not set # CONFIG_M486 is not set CONFIG_M586=y # CONFIG_M586TSC is not set # CONFIG_M586MMX is not set # CONFIG_M686 is not set # CONFIG_MPENTIUMIII is not set # CONFIG_MPENTIUM4 is not set # CONFIG_MK6 is not set # CONFIG_MK7 is not set # CONFIG_MCRUSOE is not set # CONFIG_MWINCHIPC6 is not set # CONFIG_MWINCHIP2 is not set # CONFIG_MWINCHIP3D is not set # CONFIG_MCYRIXIII is not set CONFIG_X86_WP_WORKS_OK=y CONFIG_X86_INVLPG=y CONFIG_X86_CMPXCHG=y CONFIG_X86_XADD=y CONFIG_X86_BSWAP=y CONFIG_X86_POPAD_OK=y # CONFIG_RWSEM_GENERIC_SPINLOCK is not set CONFIG_RWSEM_XCHGADD_ALGORITHM=y CONFIG_X86_L1_CACHE_SHIFT=5 CONFIG_X86_USE_STRING_486=y CONFIG_X86_ALIGNMENT_16=y CONFIG_X86_PPRO_FENCE=y # CONFIG_TOSHIBA is not set # CONFIG_I8K is not set # CONFIG_MICROCODE is not set # CONFIG_X86_MSR is not set CONFIG_X86_CPUID=y CONFIG_NOHIGHMEM=y # CONFIG_HIGHMEM4G is not set # CONFIG_HIGHMEM64G is not set # CONFIG_MATH_EMULATION is not set CONFIG_MTRR=y # CONFIG_SMP is not set # CONFIG_X86_UP_APIC is not set # CONFIG_X86_UP_IOAPIC is not set # # General setup # CONFIG_NET=y CONFIG_PCI=y # CONFIG_PCI_GOBIOS is not set # CONFIG_PCI_GODIRECT is not set CONFIG_PCI_GOANY=y CONFIG_PCI_BIOS=y CONFIG_PCI_DIRECT=y CONFIG_PCI_NAMES=y # CONFIG_EISA is not set # CONFIG_MCA is not set CONFIG_HOTPLUG=y # # PCMCIA/CardBus support # CONFIG_PCMCIA=y CONFIG_CARDBUS=y # CONFIG_I82092 is not set # CONFIG_I82365 is not set # CONFIG_TCIC is not set # # PCI Hotplug Support # # CONFIG_HOTPLUG_PCI is not set # CONFIG_HOTPLUG_PCI_COMPAQ is not set # CONFIG_HOTPLUG_PCI_COMPAQ_NVRAM is not set CONFIG_SYSVIPC=y # CONFIG_BSD_PROCESS_ACCT is not set CONFIG_SYSCTL=y CONFIG_KCORE_ELF=y # CONFIG_KCORE_AOUT is not set CONFIG_BINFMT_AOUT=y CONFIG_BINFMT_ELF=y CONFIG_BINFMT_MISC=y CONFIG_PM=y # CONFIG_ACPI is not set # CONFIG_APM is not set # # Memory Technology Devices (MTD) # # CONFIG_MTD is not set # # Parallel port support # CONFIG_PARPORT=y CONFIG_PARPORT_PC=m CONFIG_PARPORT_PC_CML1=m # CONFIG_PARPORT_SERIAL is not set # CONFIG_PARPORT_PC_FIFO is not set # CONFIG_PARPORT_PC_SUPERIO is not set # CONFIG_PARPORT_PC_PCMCIA is not set # CONFIG_PARPORT_AMIGA is not set # CONFIG_PARPORT_MFC3 is not set # CONFIG_PARPORT_ATARI is not set # CONFIG_PARPORT_GSC is not set # CONFIG_PARPORT_SUNBPP is not set # CONFIG_PARPORT_OTHER is not set # CONFIG_PARPORT_1284 is not set # # Plug and Play configuration # CONFIG_PNP=y CONFIG_ISAPNP=y # # Block devices # CONFIG_BLK_DEV_FD=y # CONFIG_BLK_DEV_XD is not set # CONFIG_PARIDE is not set # CONFIG_BLK_CPQ_DA is not set # CONFIG_BLK_CPQ_CISS_DA is not set # CONFIG_BLK_DEV_DAC960 is not set CONFIG_BLK_DEV_LOOP=y # CONFIG_BLK_DEV_NBD is not set CONFIG_BLK_DEV_RAM=y CONFIG_BLK_DEV_RAM_SIZE=4096 CONFIG_BLK_DEV_INITRD=y # # Multi-device support (RAID and LVM) # CONFIG_MD=y CONFIG_BLK_DEV_MD=y CONFIG_MD_LINEAR=m CONFIG_MD_RAID0=m CONFIG_MD_RAID1=y CONFIG_MD_RAID5=m # CONFIG_MD_MULTIPATH is not set CONFIG_BLK_DEV_LVM=m # # Networking options # CONFIG_PACKET=y # CONFIG_PACKET_MMAP is not set CONFIG_NETLINK_DEV=y CONFIG_NETFILTER=y # CONFIG_NETFILTER_DEBUG is not set CONFIG_FILTER=y CONFIG_UNIX=y CONFIG_INET=y CONFIG_IP_MULTICAST=y # CONFIG_IP_ADVANCED_ROUTER is not set # CONFIG_IP_PNP is not set # CONFIG_NET_IPIP is not set # CONFIG_NET_IPGRE is not set # CONFIG_IP_MROUTE is not set # CONFIG_ARPD is not set # CONFIG_INET_ECN is not set # CONFIG_SYN_COOKIES is not set # # IP: Netfilter Configuration # CONFIG_IP_NF_CONNTRACK=m CONFIG_IP_NF_FTP=m CONFIG_IP_NF_IRC=m # CONFIG_IP_NF_QUEUE is not set CONFIG_IP_NF_IPTABLES=m CONFIG_IP_NF_MATCH_LIMIT=m CONFIG_IP_NF_MATCH_MAC=m CONFIG_IP_NF_MATCH_MARK=m CONFIG_IP_NF_MATCH_MULTIPORT=m CONFIG_IP_NF_MATCH_TOS=m # CONFIG_IP_NF_MATCH_LENGTH is not set # CONFIG_IP_NF_MATCH_TTL is not set CONFIG_IP_NF_MATCH_TCPMSS=m CONFIG_IP_NF_MATCH_STATE=m CONFIG_IP_NF_MATCH_UNCLEAN=m CONFIG_IP_NF_MATCH_OWNER=m CONFIG_IP_NF_FILTER=m CONFIG_IP_NF_TARGET_REJECT=m CONFIG_IP_NF_TARGET_MIRROR=m CONFIG_IP_NF_NAT=m CONFIG_IP_NF_NAT_NEEDED=y CONFIG_IP_NF_TARGET_MASQUERADE=m CONFIG_IP_NF_TARGET_REDIRECT=m # CONFIG_IP_NF_NAT_SNMP_BASIC is not set CONFIG_IP_NF_NAT_IRC=m CONFIG_IP_NF_NAT_FTP=m CONFIG_IP_NF_MANGLE=m CONFIG_IP_NF_TARGET_TOS=m CONFIG_IP_NF_TARGET_MARK=m CONFIG_IP_NF_TARGET_LOG=m CONFIG_IP_NF_TARGET_TCPMSS=m # CONFIG_IP_NF_COMPAT_IPCHAINS is not set # CONFIG_IP_NF_COMPAT_IPFWADM is not set # CONFIG_IPV6 is not set # CONFIG_KHTTPD is not set # CONFIG_ATM is not set # CONFIG_VLAN_8021Q is not set CONFIG_IPX=y # CONFIG_IPX_INTERN is not set # CONFIG_ATALK is not set # CONFIG_DECNET is not set # CONFIG_BRIDGE is not set # CONFIG_X25 is not set # CONFIG_LAPB is not set # CONFIG_LLC is not set # CONFIG_NET_DIVERT is not set # CONFIG_ECONET is not set # CONFIG_WAN_ROUTER is not set # CONFIG_NET_FASTROUTE is not set # CONFIG_NET_HW_FLOWCONTROL is not set # # QoS and/or fair queueing # CONFIG_NET_SCHED=y CONFIG_NET_SCH_CBQ=m CONFIG_NET_SCH_CSZ=m CONFIG_NET_SCH_PRIO=m CONFIG_NET_SCH_RED=m CONFIG_NET_SCH_SFQ=m CONFIG_NET_SCH_TEQL=m CONFIG_NET_SCH_TBF=m CONFIG_NET_SCH_GRED=m CONFIG_NET_SCH_DSMARK=m CONFIG_NET_SCH_INGRESS=m CONFIG_NET_QOS=y CONFIG_NET_ESTIMATOR=y CONFIG_NET_CLS=y CONFIG_NET_CLS_TCINDEX=m CONFIG_NET_CLS_ROUTE4=m CONFIG_NET_CLS_ROUTE=y CONFIG_NET_CLS_FW=m CONFIG_NET_CLS_U32=m CONFIG_NET_CLS_RSVP=m CONFIG_NET_CLS_RSVP6=m CONFIG_NET_CLS_POLICE=y # # Telephony Support # # CONFIG_PHONE is not set # CONFIG_PHONE_IXJ is not set # CONFIG_PHONE_IXJ_PCMCIA is not set # # ATA/IDE/MFM/RLL support # CONFIG_IDE=y # # IDE, ATA and ATAPI Block devices # CONFIG_BLK_DEV_IDE=y # CONFIG_BLK_DEV_HD_IDE is not set # CONFIG_BLK_DEV_HD is not set CONFIG_BLK_DEV_IDEDISK=y CONFIG_IDEDISK_MULTI_MODE=y # CONFIG_BLK_DEV_IDEDISK_VENDOR is not set # CONFIG_BLK_DEV_IDEDISK_FUJITSU is not set # CONFIG_BLK_DEV_IDEDISK_IBM is not set # CONFIG_BLK_DEV_IDEDISK_MAXTOR is not set # CONFIG_BLK_DEV_IDEDISK_QUANTUM is not set # CONFIG_BLK_DEV_IDEDISK_SEAGATE is not set # CONFIG_BLK_DEV_IDEDISK_WD is not set # CONFIG_BLK_DEV_COMMERIAL is not set # CONFIG_BLK_DEV_TIVO is not set # CONFIG_BLK_DEV_IDECS is not set CONFIG_BLK_DEV_IDECD=y # CONFIG_BLK_DEV_IDETAPE is not set # CONFIG_BLK_DEV_IDEFLOPPY is not set # CONFIG_BLK_DEV_IDESCSI is not set CONFIG_BLK_DEV_CMD640=y # CONFIG_BLK_DEV_CMD640_ENHANCED is not set # CONFIG_BLK_DEV_ISAPNP is not set CONFIG_BLK_DEV_RZ1000=y CONFIG_BLK_DEV_IDEPCI=y CONFIG_IDEPCI_SHARE_IRQ=y CONFIG_BLK_DEV_IDEDMA_PCI=y CONFIG_BLK_DEV_ADMA=y # CONFIG_BLK_DEV_OFFBOARD is not set CONFIG_IDEDMA_PCI_AUTO=y CONFIG_BLK_DEV_IDEDMA=y # CONFIG_IDEDMA_PCI_WIP is not set # CONFIG_IDEDMA_NEW_DRIVE_LISTINGS is not set CONFIG_BLK_DEV_AEC62XX=y CONFIG_AEC62XX_TUNING=y CONFIG_BLK_DEV_ALI15X3=y CONFIG_WDC_ALI15X3=y # CONFIG_BLK_DEV_AMD74XX is not set # CONFIG_AMD74XX_OVERRIDE is not set CONFIG_BLK_DEV_CMD64X=y CONFIG_BLK_DEV_CY82C693=y CONFIG_BLK_DEV_CS5530=y CONFIG_BLK_DEV_HPT34X=y # CONFIG_HPT34X_AUTODMA is not set CONFIG_BLK_DEV_HPT366=y CONFIG_BLK_DEV_PIIX=y CONFIG_PIIX_TUNING=y CONFIG_BLK_DEV_NS87415=y CONFIG_BLK_DEV_OPTI621=y CONFIG_BLK_DEV_PDC202XX=y # CONFIG_PDC202XX_BURST is not set # CONFIG_PDC202XX_FORCE is not set # CONFIG_BLK_DEV_SVWKS is not set CONFIG_BLK_DEV_SIS5513=y CONFIG_BLK_DEV_SLC90E66=y CONFIG_BLK_DEV_TRM290=y CONFIG_BLK_DEV_VIA82CXXX=y # CONFIG_IDE_CHIPSETS is not set CONFIG_IDEDMA_AUTO=y # CONFIG_IDEDMA_IVB is not set # CONFIG_DMA_NONPCI is not set CONFIG_BLK_DEV_IDE_MODES=y # CONFIG_BLK_DEV_ATARAID is not set # CONFIG_BLK_DEV_ATARAID_PDC is not set # CONFIG_BLK_DEV_ATARAID_HPT is not set # # SCSI support # CONFIG_SCSI=y CONFIG_BLK_DEV_SD=y CONFIG_SD_EXTRA_DEVS=40 CONFIG_CHR_DEV_ST=m CONFIG_CHR_DEV_OSST=m CONFIG_BLK_DEV_SR=m CONFIG_BLK_DEV_SR_VENDOR=y CONFIG_SR_EXTRA_DEVS=2 CONFIG_CHR_DEV_SG=m CONFIG_SCSI_DEBUG_QUEUES=y CONFIG_SCSI_MULTI_LUN=y CONFIG_SCSI_CONSTANTS=y # CONFIG_SCSI_LOGGING is not set # # SCSI low-level drivers # CONFIG_BLK_DEV_3W_XXXX_RAID=m CONFIG_SCSI_7000FASST=m CONFIG_SCSI_ACARD=m CONFIG_SCSI_AHA152X=m CONFIG_SCSI_AHA1542=m CONFIG_SCSI_AHA1740=m # CONFIG_SCSI_AACRAID is not set CONFIG_SCSI_AIC7XXX=m CONFIG_AIC7XXX_CMDS_PER_DEVICE=253 CONFIG_AIC7XXX_RESET_DELAY_MS=15000 # CONFIG_AIC7XXX_BUILD_FIRMWARE is not set # CONFIG_SCSI_AIC7XXX_OLD is not set # CONFIG_SCSI_DPT_I2O is not set CONFIG_SCSI_ADVANSYS=m CONFIG_SCSI_IN2000=m CONFIG_SCSI_AM53C974=m CONFIG_SCSI_MEGARAID=m CONFIG_SCSI_BUSLOGIC=m # CONFIG_SCSI_OMIT_FLASHPOINT is not set CONFIG_SCSI_CPQFCTS=m CONFIG_SCSI_DMX3191D=m CONFIG_SCSI_DTC3280=m # CONFIG_SCSI_EATA is not set # CONFIG_SCSI_EATA_DMA is not set # CONFIG_SCSI_EATA_PIO is not set # CONFIG_SCSI_FUTURE_DOMAIN is not set # CONFIG_SCSI_GDTH is not set CONFIG_SCSI_GENERIC_NCR5380=m # CONFIG_SCSI_GENERIC_NCR53C400 is not set CONFIG_SCSI_G_NCR5380_PORT=y # CONFIG_SCSI_G_NCR5380_MEM is not set # CONFIG_SCSI_IPS is not set CONFIG_SCSI_INITIO=m CONFIG_SCSI_INIA100=m # CONFIG_SCSI_PPA is not set # CONFIG_SCSI_IMM is not set # CONFIG_SCSI_NCR53C406A is not set # CONFIG_SCSI_NCR53C7xx is not set # CONFIG_SCSI_SYM53C8XX_2 is not set # CONFIG_SCSI_NCR53C8XX is not set CONFIG_SCSI_SYM53C8XX=y CONFIG_SCSI_NCR53C8XX_DEFAULT_TAGS=4 CONFIG_SCSI_NCR53C8XX_MAX_TAGS=32 CONFIG_SCSI_NCR53C8XX_SYNC=20 # CONFIG_SCSI_NCR53C8XX_PROFILE is not set # CONFIG_SCSI_NCR53C8XX_IOMAPPED is not set # CONFIG_SCSI_NCR53C8XX_PQS_PDS is not set # CONFIG_SCSI_NCR53C8XX_SYMBIOS_COMPAT is not set # CONFIG_SCSI_PAS16 is not set # CONFIG_SCSI_PCI2000 is not set # CONFIG_SCSI_PCI2220I is not set # CONFIG_SCSI_PSI240I is not set # CONFIG_SCSI_QLOGIC_FAS is not set # CONFIG_SCSI_QLOGIC_ISP is not set # CONFIG_SCSI_QLOGIC_FC is not set # CONFIG_SCSI_QLOGIC_1280 is not set # CONFIG_SCSI_SEAGATE is not set # CONFIG_SCSI_SIM710 is not set CONFIG_SCSI_SYM53C416=m # CONFIG_SCSI_DC390T is not set # CONFIG_SCSI_T128 is not set # CONFIG_SCSI_U14_34F is not set # CONFIG_SCSI_ULTRASTOR is not set # CONFIG_SCSI_DEBUG is not set # # PCMCIA SCSI adapter support # # CONFIG_SCSI_PCMCIA is not set # # Fusion MPT device support # # CONFIG_FUSION is not set # CONFIG_FUSION_BOOT is not set # CONFIG_FUSION_ISENSE is not set # CONFIG_FUSION_CTL is not set # CONFIG_FUSION_LAN is not set # # IEEE 1394 (FireWire) support (EXPERIMENTAL) # # CONFIG_IEEE1394 is not set # # I2O device support # # CONFIG_I2O is not set # CONFIG_I2O_PCI is not set # CONFIG_I2O_BLOCK is not set # CONFIG_I2O_LAN is not set # CONFIG_I2O_SCSI is not set # CONFIG_I2O_PROC is not set # # Network device support # CONFIG_NETDEVICES=y # # ARCnet devices # # CONFIG_ARCNET is not set CONFIG_DUMMY=m # CONFIG_BONDING is not set # CONFIG_EQUALIZER is not set # CONFIG_TUN is not set # CONFIG_ETHERTAP is not set # CONFIG_NET_SB1000 is not set # # Ethernet (10 or 100Mbit) # CONFIG_NET_ETHERNET=y # CONFIG_SUNLANCE is not set # CONFIG_HAPPYMEAL is not set # CONFIG_SUNBMAC is not set # CONFIG_SUNQE is not set # CONFIG_SUNLANCE is not set # CONFIG_SUNGEM is not set CONFIG_NET_VENDOR_3COM=y CONFIG_EL1=m CONFIG_EL2=m CONFIG_ELPLUS=m CONFIG_EL16=m CONFIG_EL3=m CONFIG_3C515=m # CONFIG_ELMC is not set # CONFIG_ELMC_II is not set CONFIG_VORTEX=m CONFIG_LANCE=m # CONFIG_NET_VENDOR_SMC is not set # CONFIG_NET_VENDOR_RACAL is not set CONFIG_AT1700=m CONFIG_DEPCA=m CONFIG_HP100=m # CONFIG_NET_ISA is not set CONFIG_NET_PCI=y # CONFIG_PCNET32 is not set # CONFIG_ADAPTEC_STARFIRE is not set # CONFIG_AC3200 is not set # CONFIG_APRICOT is not set # CONFIG_CS89x0 is not set # CONFIG_TULIP is not set # CONFIG_DE4X5 is not set # CONFIG_DGRS is not set # CONFIG_DM9102 is not set CONFIG_EEPRO100=y # CONFIG_LNE390 is not set # CONFIG_FEALNX is not set # CONFIG_NATSEMI is not set # CONFIG_NE2K_PCI is not set # CONFIG_NE3210 is not set # CONFIG_ES3210 is not set # CONFIG_8139CP is not set # CONFIG_8139TOO is not set # CONFIG_8139TOO_PIO is not set # CONFIG_8139TOO_TUNE_TWISTER is not set # CONFIG_8139TOO_8129 is not set # CONFIG_SIS900 is not set # CONFIG_EPIC100 is not set # CONFIG_SUNDANCE is not set # CONFIG_TLAN is not set # CONFIG_VIA_RHINE is not set # CONFIG_VIA_RHINE_MMIO is not set # CONFIG_WINBOND_840 is not set # CONFIG_NET_POCKET is not set # # Ethernet (1000 Mbit) # # CONFIG_ACENIC is not set # CONFIG_DL2K is not set # CONFIG_MYRI_SBUS is not set # CONFIG_NS83820 is not set # CONFIG_HAMACHI is not set # CONFIG_YELLOWFIN is not set # CONFIG_SK98LIN is not set # CONFIG_FDDI is not set # CONFIG_HIPPI is not set # CONFIG_PLIP is not set # CONFIG_PPP is not set # CONFIG_SLIP is not set # # Wireless LAN (non-hamradio) # CONFIG_NET_RADIO=y CONFIG_STRIP=m CONFIG_WAVELAN=m CONFIG_ARLAN=m # CONFIG_AIRONET4500 is not set # CONFIG_AIRONET4500_NONCS is not set # CONFIG_AIRONET4500_PROC is not set # CONFIG_AIRO is not set # CONFIG_HERMES is not set # CONFIG_PLX_HERMES is not set # CONFIG_PCMCIA_HERMES is not set # CONFIG_AIRO_CS is not set CONFIG_NET_WIRELESS=y # # Token Ring devices # # CONFIG_TR is not set # CONFIG_NET_FC is not set # CONFIG_RCPCI is not set # CONFIG_SHAPER is not set # # Wan interfaces # # CONFIG_WAN is not set # # PCMCIA network device support # CONFIG_NET_PCMCIA=y CONFIG_PCMCIA_3C589=m CONFIG_PCMCIA_3C574=m CONFIG_PCMCIA_FMVJ18X=m CONFIG_PCMCIA_PCNET=m # CONFIG_PCMCIA_AXNET is not set CONFIG_PCMCIA_NMCLAN=m CONFIG_PCMCIA_SMC91C92=m CONFIG_PCMCIA_XIRC2PS=m # CONFIG_ARCNET_COM20020_CS is not set # CONFIG_PCMCIA_IBMTR is not set # CONFIG_PCMCIA_XIRCOM is not set CONFIG_PCMCIA_XIRTULIP=m CONFIG_NET_PCMCIA_RADIO=y CONFIG_PCMCIA_RAYCS=m CONFIG_PCMCIA_NETWAVE=m CONFIG_PCMCIA_WAVELAN=m # CONFIG_AIRONET4500_CS is not set # # Amateur Radio support # # CONFIG_HAMRADIO is not set # # IrDA (infrared) support # # CONFIG_IRDA is not set # # ISDN subsystem # # CONFIG_ISDN is not set # # Old CD-ROM drivers (not SCSI, not IDE) # # CONFIG_CD_NO_IDESCSI is not set # # Input core support # CONFIG_INPUT=m CONFIG_INPUT_KEYBDEV=m CONFIG_INPUT_MOUSEDEV=m CONFIG_INPUT_MOUSEDEV_SCREEN_X=1024 CONFIG_INPUT_MOUSEDEV_SCREEN_Y=768 CONFIG_INPUT_JOYDEV=m CONFIG_INPUT_EVDEV=m # # Character devices # CONFIG_VT=y CONFIG_VT_CONSOLE=y CONFIG_SERIAL=y CONFIG_SERIAL_CONSOLE=y # CONFIG_SERIAL_EXTENDED is not set # CONFIG_SERIAL_NONSTANDARD is not set CONFIG_UNIX98_PTYS=y CONFIG_UNIX98_PTY_COUNT=256 CONFIG_PRINTER=m # CONFIG_LP_CONSOLE is not set # CONFIG_PPDEV is not set # # I2C support # # CONFIG_I2C is not set # # Mice # # CONFIG_BUSMOUSE is not set CONFIG_MOUSE=y CONFIG_PSMOUSE=y # CONFIG_82C710_MOUSE is not set # CONFIG_PC110_PAD is not set # # Joysticks # # CONFIG_INPUT_GAMEPORT is not set # CONFIG_INPUT_NS558 is not set # CONFIG_INPUT_LIGHTNING is not set # CONFIG_INPUT_PCIGAME is not set # CONFIG_INPUT_CS461X is not set # CONFIG_INPUT_EMU10K1 is not set # CONFIG_INPUT_SERIO is not set # CONFIG_INPUT_SERPORT is not set # CONFIG_INPUT_ANALOG is not set # CONFIG_INPUT_A3D is not set # CONFIG_INPUT_ADI is not set # CONFIG_INPUT_COBRA is not set # CONFIG_INPUT_GF2K is not set # CONFIG_INPUT_GRIP is not set # CONFIG_INPUT_INTERACT is not set # CONFIG_INPUT_TMDC is not set # CONFIG_INPUT_SIDEWINDER is not set # CONFIG_INPUT_IFORCE_USB is not set # CONFIG_INPUT_IFORCE_232 is not set # CONFIG_INPUT_WARRIOR is not set # CONFIG_INPUT_MAGELLAN is not set # CONFIG_INPUT_SPACEORB is not set # CONFIG_INPUT_SPACEBALL is not set # CONFIG_INPUT_STINGER is not set # CONFIG_INPUT_DB9 is not set # CONFIG_INPUT_GAMECON is not set # CONFIG_INPUT_TURBOGRAFX is not set # CONFIG_QIC02_TAPE is not set # # Watchdog Cards # # CONFIG_WATCHDOG is not set # CONFIG_INTEL_RNG is not set # CONFIG_NVRAM is not set # CONFIG_RTC is not set # CONFIG_DTLK is not set # CONFIG_R3964 is not set # CONFIG_APPLICOM is not set # CONFIG_SONYPI is not set # # Ftape, the floppy tape device driver # # CONFIG_FTAPE is not set CONFIG_AGP=y CONFIG_AGP_INTEL=y CONFIG_AGP_I810=y CONFIG_AGP_VIA=y CONFIG_AGP_AMD=y CONFIG_AGP_SIS=y CONFIG_AGP_ALI=y # CONFIG_AGP_SWORKS is not set CONFIG_DRM=y CONFIG_DRM_TDFX=y # CONFIG_DRM_GAMMA is not set # CONFIG_DRM_R128 is not set CONFIG_DRM_RADEON=y # CONFIG_DRM_I810 is not set # CONFIG_DRM_MGA is not set # CONFIG_DRM_SIS is not set # # PCMCIA character devices # CONFIG_PCMCIA_SERIAL_CS=m # CONFIG_MWAVE is not set # # Multimedia devices # # CONFIG_VIDEO_DEV is not set # # File systems # CONFIG_QUOTA=y CONFIG_FS_POSIX_ACL=y CONFIG_AUTOFS_FS=m CONFIG_AUTOFS4_FS=y CONFIG_REISERFS_FS=m # CONFIG_REISERFS_CHECK is not set # CONFIG_REISERFS_PROC_INFO is not set # CONFIG_ADFS_FS is not set # CONFIG_ADFS_FS_RW is not set # CONFIG_AFFS_FS is not set # CONFIG_HFS_FS is not set # CONFIG_BFS_FS is not set CONFIG_EXT3_FS=y CONFIG_JBD=y # CONFIG_JBD_DEBUG is not set # CONFIG_FAT_FS is not set # CONFIG_MSDOS_FS is not set # CONFIG_UMSDOS_FS is not set # CONFIG_VFAT_FS is not set # CONFIG_EFS_FS is not set # CONFIG_JFFS_FS is not set # CONFIG_JFFS2_FS is not set CONFIG_CRAMFS=y CONFIG_TMPFS=y # CONFIG_RAMFS is not set CONFIG_ISO9660_FS=y CONFIG_JOLIET=y # CONFIG_ZISOFS is not set # CONFIG_MINIX_FS is not set # CONFIG_VXFS_FS is not set # CONFIG_NTFS_FS is not set # CONFIG_NTFS_RW is not set # CONFIG_HPFS_FS is not set CONFIG_PROC_FS=y CONFIG_DEVFS_FS=y CONFIG_DEVFS_MOUNT=y # CONFIG_DEVFS_DEBUG is not set CONFIG_DEVPTS_FS=y # CONFIG_QNX4FS_FS is not set # CONFIG_QNX4FS_RW is not set # CONFIG_ROMFS_FS is not set CONFIG_EXT2_FS=y # CONFIG_SYSV_FS is not set # CONFIG_UDF_FS is not set # CONFIG_UDF_RW is not set # CONFIG_UFS_FS is not set # CONFIG_UFS_FS_WRITE is not set CONFIG_PAGE_BUF=y CONFIG_XFS_FS=y # CONFIG_XFS_RT is not set CONFIG_XFS_QUOTA=y CONFIG_HAVE_ATTRCTL=y # CONFIG_XFS_DMAPI is not set # # Network File Systems # # CONFIG_CODA_FS is not set # CONFIG_INTERMEZZO_FS is not set CONFIG_NFS_FS=y CONFIG_NFS_V3=y # CONFIG_ROOT_NFS is not set CONFIG_NFSD=y CONFIG_NFSD_V3=y CONFIG_SUNRPC=y CONFIG_LOCKD=y CONFIG_LOCKD_V4=y CONFIG_SMB_FS=m # CONFIG_SMB_NLS_DEFAULT is not set # CONFIG_NCP_FS is not set # CONFIG_NCPFS_PACKET_SIGNING is not set # CONFIG_NCPFS_IOCTL_LOCKING is not set # CONFIG_NCPFS_STRONG is not set # CONFIG_NCPFS_NFS_NS is not set # CONFIG_NCPFS_OS2_NS is not set # CONFIG_NCPFS_SMALLDOS is not set # CONFIG_NCPFS_NLS is not set # CONFIG_NCPFS_EXTRAS is not set # CONFIG_ZISOFS_FS is not set CONFIG_ZLIB_FS_INFLATE=y # # Partition Types # # CONFIG_PARTITION_ADVANCED is not set CONFIG_MSDOS_PARTITION=y CONFIG_SMB_NLS=y CONFIG_NLS=y # # Native Language Support # CONFIG_NLS_DEFAULT="iso8859-1" # CONFIG_NLS_CODEPAGE_437 is not set # CONFIG_NLS_CODEPAGE_737 is not set # CONFIG_NLS_CODEPAGE_775 is not set # CONFIG_NLS_CODEPAGE_850 is not set # CONFIG_NLS_CODEPAGE_852 is not set # CONFIG_NLS_CODEPAGE_855 is not set # CONFIG_NLS_CODEPAGE_857 is not set # CONFIG_NLS_CODEPAGE_860 is not set # CONFIG_NLS_CODEPAGE_861 is not set # CONFIG_NLS_CODEPAGE_862 is not set # CONFIG_NLS_CODEPAGE_863 is not set # CONFIG_NLS_CODEPAGE_864 is not set # CONFIG_NLS_CODEPAGE_865 is not set # CONFIG_NLS_CODEPAGE_866 is not set # CONFIG_NLS_CODEPAGE_869 is not set # CONFIG_NLS_CODEPAGE_936 is not set # CONFIG_NLS_CODEPAGE_950 is not set # CONFIG_NLS_CODEPAGE_932 is not set # CONFIG_NLS_CODEPAGE_949 is not set # CONFIG_NLS_CODEPAGE_874 is not set # CONFIG_NLS_ISO8859_8 is not set # CONFIG_NLS_CODEPAGE_1251 is not set # CONFIG_NLS_ISO8859_1 is not set # CONFIG_NLS_ISO8859_2 is not set # CONFIG_NLS_ISO8859_3 is not set # CONFIG_NLS_ISO8859_4 is not set # CONFIG_NLS_ISO8859_5 is not set # CONFIG_NLS_ISO8859_6 is not set # CONFIG_NLS_ISO8859_7 is not set # CONFIG_NLS_ISO8859_9 is not set # CONFIG_NLS_ISO8859_13 is not set # CONFIG_NLS_ISO8859_14 is not set # CONFIG_NLS_ISO8859_15 is not set # CONFIG_NLS_KOI8_R is not set # CONFIG_NLS_KOI8_U is not set # CONFIG_NLS_UTF8 is not set # # Console drivers # CONFIG_VGA_CONSOLE=y CONFIG_VIDEO_SELECT=y # CONFIG_MDA_CONSOLE is not set # # Frame-buffer support # CONFIG_FB=y CONFIG_DUMMY_CONSOLE=y # CONFIG_FB_RIVA is not set CONFIG_FB_CLGEN=m # CONFIG_FB_PM2 is not set # CONFIG_FB_CYBER2000 is not set CONFIG_FB_VESA=y # CONFIG_FB_VGA16 is not set # CONFIG_FB_HGA is not set CONFIG_VIDEO_SELECT=y # CONFIG_FB_MATROX is not set # CONFIG_FB_ATY is not set # CONFIG_FB_RADEON is not set # CONFIG_FB_ATY128 is not set # CONFIG_FB_SIS is not set # CONFIG_FB_3DFX is not set # CONFIG_FB_VOODOO1 is not set # CONFIG_FB_VIRTUAL is not set # CONFIG_FBCON_ADVANCED is not set CONFIG_FBCON_MFB=m CONFIG_FBCON_CFB8=y CONFIG_FBCON_CFB16=y CONFIG_FBCON_CFB24=y CONFIG_FBCON_CFB32=y # CONFIG_FBCON_FONTWIDTH8_ONLY is not set # CONFIG_FBCON_FONTS is not set CONFIG_FONT_8x8=y CONFIG_FONT_8x16=y # # Sound # # CONFIG_SOUND is not set # # USB support # CONFIG_USB=y # CONFIG_USB_DEBUG is not set # CONFIG_USB_DEVICEFS is not set # CONFIG_USB_BANDWIDTH is not set # CONFIG_USB_LONG_TIMEOUT is not set CONFIG_USB_UHCI_ALT=y # CONFIG_USB_OHCI is not set # CONFIG_USB_AUDIO is not set # CONFIG_USB_BLUETOOTH is not set CONFIG_USB_STORAGE=y # CONFIG_USB_STORAGE_DEBUG is not set # CONFIG_USB_STORAGE_DATAFAB is not set # CONFIG_USB_STORAGE_FREECOM is not set # CONFIG_USB_STORAGE_ISD200 is not set # CONFIG_USB_STORAGE_DPCM is not set # CONFIG_USB_STORAGE_HP8200e is not set # CONFIG_USB_STORAGE_SDDR09 is not set # CONFIG_USB_STORAGE_JUMPSHOT is not set # CONFIG_USB_ACM is not set # CONFIG_USB_PRINTER is not set # CONFIG_USB_HID is not set # CONFIG_USB_HIDDEV is not set # CONFIG_USB_KBD is not set # CONFIG_USB_MOUSE is not set # CONFIG_USB_WACOM is not set # CONFIG_USB_DC2XX is not set # CONFIG_USB_MDC800 is not set # CONFIG_USB_SCANNER is not set # CONFIG_USB_MICROTEK is not set # CONFIG_USB_HPUSBSCSI is not set # CONFIG_USB_PEGASUS is not set # CONFIG_USB_KAWETH is not set # CONFIG_USB_CATC is not set # CONFIG_USB_CDCETHER is not set # CONFIG_USB_USBNET is not set # CONFIG_USB_USS720 is not set # # USB Serial Converter support # # CONFIG_USB_SERIAL is not set # CONFIG_USB_SERIAL_GENERIC is not set # CONFIG_USB_SERIAL_BELKIN is not set # CONFIG_USB_SERIAL_WHITEHEAT is not set # CONFIG_USB_SERIAL_DIGI_ACCELEPORT is not set # CONFIG_USB_SERIAL_EMPEG is not set # CONFIG_USB_SERIAL_FTDI_SIO is not set # CONFIG_USB_SERIAL_VISOR is not set # CONFIG_USB_SERIAL_IR is not set # CONFIG_USB_SERIAL_EDGEPORT is not set # CONFIG_USB_SERIAL_KEYSPAN_PDA is not set # CONFIG_USB_SERIAL_KEYSPAN is not set # CONFIG_USB_SERIAL_KEYSPAN_USA28 is not set # CONFIG_USB_SERIAL_KEYSPAN_USA28X is not set # CONFIG_USB_SERIAL_KEYSPAN_USA28XA is not set # CONFIG_USB_SERIAL_KEYSPAN_USA28XB is not set # CONFIG_USB_SERIAL_KEYSPAN_USA19 is not set # CONFIG_USB_SERIAL_KEYSPAN_USA18X is not set # CONFIG_USB_SERIAL_KEYSPAN_USA19W is not set # CONFIG_USB_SERIAL_KEYSPAN_USA49W is not set # CONFIG_USB_SERIAL_MCT_U232 is not set # CONFIG_USB_SERIAL_PL2303 is not set # CONFIG_USB_SERIAL_CYBERJACK is not set # CONFIG_USB_SERIAL_XIRCOM is not set # CONFIG_USB_SERIAL_OMNINET is not set # CONFIG_USB_RIO500 is not set # # Bluetooth support # # CONFIG_BLUEZ is not set # # Kernel hacking # CONFIG_DEBUG_KERNEL=y # CONFIG_DEBUG_HIGHMEM is not set # CONFIG_DEBUG_SLAB is not set # CONFIG_DEBUG_IOVIRT is not set CONFIG_MAGIC_SYSRQ=y # CONFIG_DEBUG_SPINLOCK is not set # CONFIG_DEBUG_BUGVERBOSE is not set CONFIG_KDB=y CONFIG_KDB_MODULES=m # CONFIG_KDB_OFF is not set CONFIG_KALLSYMS=y CONFIG_FRAME_POINTER=y --=-=-= Content-Disposition: attachment; filename=boot.txt Content-Description: boot log Linux version 2.4.17-xfs-lvm (root@shakti) (gcc version 2.95.4 20011006 (Debian prerelease)) #2 Mon Jan 7 18:43:23 PST 2002 BIOS-provided physical RAM map: BIOS-e820: 0000000000000000 - 00000000000a0000 (usable) BIOS-e820: 00000000000f0000 - 0000000000100000 (reserved) BIOS-e820: 0000000000100000 - 0000000027ff0000 (usable) BIOS-e820: 0000000027ff0000 - 0000000027ff3000 (ACPI NVS) BIOS-e820: 0000000027ff3000 - 0000000028000000 (ACPI data) BIOS-e820: 00000000ffff0000 - 0000000100000000 (reserved) On node 0 totalpages: 163824 zone(0): 4096 pages. zone(1): 159728 pages. zone(2): 0 pages. Kernel command line: root=/dev/shaktivg/rootlv ro devfs=mount console=ttyS0 console=tty0 single mem=655296K Initializing CPU#0 Detected 501.147 MHz processor. Console: colour VGA+ 80x25 Calibrating delay loop... 999.42 BogoMIPS Memory: 639800k/655296k available (1972k kernel code, 15108k reserved, 1186k data, 260k init, 0k highmem) kdb version 1.9 by Scott Lurndal, Keith Owens. Copyright SGI, All Rights Reserved Dentry-cache hash table entries: 131072 (order: 8, 1048576 bytes) Inode-cache hash table entries: 65536 (order: 7, 524288 bytes) Mount-cache hash table entries: 16384 (order: 5, 131072 bytes) Buffer-cache hash table entries: 65536 (order: 6, 262144 bytes) Page-cache hash table entries: 262144 (order: 8, 1048576 bytes) CPU: L1 I cache: 16K, L1 D cache: 16K CPU: L2 cache: 512K Intel machine check architecture supported. Intel machine check reporting enabled on CPU#0. CPU: Intel Pentium III (Katmai) stepping 02 Enabling fast FPU save and restore... done. Enabling unmasked SIMD FPU exception support... done. Checking 'hlt' instruction... OK. POSIX conformance testing by UNIFIX mtrr: v1.40 (20010327) Richard Gooch (rgooch@atnf.csiro.au) mtrr: detected mtrr type: Intel PCI: PCI BIOS revision 2.10 entry at 0xfb3b0, last bus=1 PCI: Using configuration type 1 PCI: Probing PCI hardware Unknown bridge resource 0: assuming transparent Unknown bridge resource 1: assuming transparent Unknown bridge resource 2: assuming transparent PCI: Using IRQ router PIIX [8086/7110] at 00:07.0 Limiting direct PCI/PCI transfers. isapnp: Scanning for PnP cards... isapnp: No Plug & Play device found Linux NET4.0 for Linux 2.4 Based upon Swansea University Computer Society NET3.039 Initializing RT netlink socket Starting kswapd VFS: Diskquotas version dquot_6.4.0 initialized Journalled Block Device driver loaded devfs: v1.7 (20011216) Richard Gooch (rgooch@atnf.csiro.au) devfs: boot_options: 0x1 SGI XFS with ACLs, EAs, quota, no debug enabled Detected PS/2 Mouse Port. pty: 256 Unix98 ptys configured Serial driver version 5.05c (2001-07-08) with MANY_PORTS SHARE_IRQ SERIAL_PCI ISAPNP enabled ttyS00 at 0x03f8 (irq = 4) is a 16550A ttyS01 at 0x02f8 (irq = 3) is a 16550A block: 128 slots per queue, batch=32 RAMDISK driver initialized: 16 RAM disks of 4096K size 1024 blocksize Uniform Multi-Platform E-IDE driver Revision: 6.31 ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx PIIX4: IDE controller on PCI bus 00 dev 39 PIIX4: chipset revision 1 PIIX4: not 100% native mode: will probe irqs later ide0: BM-DMA at 0xf000-0xf007, BIOS settings: hda:pio, hdb:pio ide1: BM-DMA at 0xf008-0xf00f, BIOS settings: hdc:DMA, hdd:pio PDC20267: IDE controller on PCI bus 00 dev 68 PCI: Found IRQ 10 for device 00:0d.0 PDC20267: chipset revision 2 PDC20267: not 100% native mode: will probe irqs later PDC20267: (U)DMA Burst Bit ENABLED Primary PCI Mode Secondary PCI Mode. ide2: BM-DMA at 0xac00-0xac07, BIOS settings: hde:DMA, hdf:DMA ide3: BM-DMA at 0xac08-0xac0f, BIOS settings: hdg:DMA, hdh:DMA PDC20267: IDE controller on PCI bus 00 dev 78 PCI: Found IRQ 11 for device 00:0f.0 PDC20267: chipset revision 2 PDC20267: not 100% native mode: will probe irqs later PDC20267: (U)DMA Burst Bit ENABLED Primary PCI Mode Secondary PCI Mode. ide4: BM-DMA at 0xc000-0xc007, BIOS settings: hdi:DMA, hdj:DMA ide5: BM-DMA at 0xc008-0xc00f, BIOS settings: hdk:DMA, hdl:DMA hdc: CD-ROM Drive/F5D, ATAPI CD/DVD-ROM drive hde: Maxtor 54610H6, ATA DISK drive hdg: Maxtor 54610H6, ATA DISK drive hdi: Maxtor 54610H6, ATA DISK drive hdk: Maxtor 54610H6, ATA DISK drive ide1 at 0x170-0x177,0x376 on irq 15 ide2 at 0x9c00-0x9c07,0xa002 on irq 10 ide3 at 0xa400-0xa407,0xa802 on irq 10 ide4 at 0xb000-0xb007,0xb402 on irq 11 ide5 at 0xb800-0xb807,0xbc02 on irq 11 hde: 90045648 sectors (46103 MB) w/2048KiB Cache, CHS=89331/16/63, UDMA(100) hdg: 90045648 sectors (46103 MB) w/2048KiB Cache, CHS=89331/16/63, UDMA(100) hdi: 90045648 sectors (46103 MB) w/2048KiB Cache, CHS=89331/16/63, UDMA(100) hdk: 90045648 sectors (46103 MB) w/2048KiB Cache, CHS=89331/16/63, UDMA(100) hdc: ATAPI 48X CD-ROM drive, 128kB Cache, UDMA(33) Uniform CD-ROM driver Revision: 3.12 Partition check: /dev/ide/host2/bus0/target0/lun0: [PTBL] [5605/255/63] p1 p2 p3 /dev/ide/host2/bus1/target0/lun0: [PTBL] [5605/255/63] p1 p2 p3 /dev/ide/host4/bus0/target0/lun0: [PTBL] [5605/255/63] p1 p2 p3 /dev/ide/host4/bus1/target0/lun0: [PTBL] [5605/255/63] p1 p2 p3 Floppy drive(s): fd0 is 1.44M FDC 0 is a post-1991 82077 loop: loaded (max 8 devices) eepro100.c:v1.09j-t 9/29/99 Donald Becker http://cesdis.gsfc.nasa.gov/linux/drivers/eepro100.html eepro100.c: $Revision: 1.36 $ 2000/11/17 Modified by Andrey V. Savochkin and others PCI: Found IRQ 12 for device 00:0b.0 eth0: OEM i82557/i82558 10/100 Ethernet, 00:60:B0:3C:DD:62, IRQ 12. Receiver lock-up bug exists -- enabling work-around. Board assembly 661921-004, Physical connectors present: RJ45 Primary interface chip DP83840A PHY #1. DP83840 specific setup, setting register 23 to 8462. General self-test: passed. Serial sub-system self-test: passed. Internal registers self-test: passed. ROM checksum self-test: passed (0x49caa8d6). Receiver lock-up workaround activated. Linux agpgart interface v0.99 (c) Jeff Hartmann agpgart: Maximum main memory to use for agp memory: 564M agpgart: Detected Intel 440BX chipset agpgart: AGP aperture is 64M @ 0xd0000000 [drm] Initialized tdfx 1.0.0 20010216 on minor 0 [drm] AGP 0.99 on Intel 440BX @ 0xd0000000 64MB [drm] Initialized radeon 1.1.1 20010405 on minor 1 SCSI subsystem driver Revision: 1.00 request_module[scsi_hostadapter]: Root fs not mounted Linux Kernel Card Services 3.1.22 options: [pci] [cardbus] [pm] usb.c: registered new driver hub uhci.c: USB Universal Host Controller Interface driver v1.1 PCI: Found IRQ 5 for device 00:07.2 PCI: Sharing IRQ 5 with 00:09.0 uhci.c: USB UHCI at I/O 0x9000, IRQ 5 usb.c: new USB bus registered, assigned bus number 1 hub.c: USB hub found hub.c: 2 ports detected Initializing USB Mass Storage driver... usb.c: registered new driver usb-storage USB Mass Storage support registered. md: raid1 personality registered as nr 3 md: md driver 0.90.0 MAX_MD_DEVS=256, MD_SB_DISKS=27 md: Autodetecting RAID arrays. [events: 000000e4] [events: 000000e4] [events: 000000e0] [events: 000000e4] [events: 000000e4] [events: 000000e0] [events: 00041883] md: invalid raid superblock magic on ide/host4/bus0/target0/lun0/part1 md: ide/host4/bus0/target0/lun0/part1 has invalid sb, not importing! md: could not import ide/host4/bus0/target0/lun0/part1! [events: 000000aa] [events: 000000aa] [events: 00041883] md: invalid raid superblock magic on ide/host4/bus1/target0/lun0/part1 md: ide/host4/bus1/target0/lun0/part1 has invalid sb, not importing! md: could not import ide/host4/bus1/target0/lun0/part1! [events: 000000aa] [events: 000000aa] md: autorun ... md: considering ide/host4/bus1/target0/lun0/part3 ... md: adding ide/host4/bus1/target0/lun0/part3 ... md: adding ide/host4/bus0/target0/lun0/part3 ... md: created md5 md: bind md: bind md: running: md: ide/host4/bus1/target0/lun0/part3's event counter: 000000aa md: ide/host4/bus0/target0/lun0/part3's event counter: 000000aa md: RAID level 1 does not need chunksize! Continuing anyway. md5: max total readahead window set to 124k md5: 1 data-disks, max readahead per data-disk: 124k raid1: device ide/host4/bus1/target0/lun0/part3 operational as mirror 0 raid1: device ide/host4/bus0/target0/lun0/part3 operational as mirror 1 raid1: raid set md5 active with 2 out of 2 mirrors md: updating md5 RAID superblock on device md: ide/host4/bus1/target0/lun0/part3 [events: 000000ab]<6>(write) ide/host4/bus1/target0/lun0/part3's sb offset: 43993920 md: ide/host4/bus0/target0/lun0/part3 [events: 000000ab]<6>(write) ide/host4/bus0/target0/lun0/part3's sb offset: 43993920 md: considering ide/host4/bus1/target0/lun0/part2 ... md: adding ide/host4/bus1/target0/lun0/part2 ... md: adding ide/host4/bus0/target0/lun0/part2 ... md: created md4 md: bind md: bind md: running: md: ide/host4/bus1/target0/lun0/part2's event counter: 000000aa md: ide/host4/bus0/target0/lun0/part2's event counter: 000000aa md: RAID level 1 does not need chunksize! Continuing anyway. md4: max total readahead window set to 124k md4: 1 data-disks, max readahead per data-disk: 124k raid1: device ide/host4/bus1/target0/lun0/part2 operational as mirror 0 raid1: device ide/host4/bus0/target0/lun0/part2 operational as mirror 1 raid1: raid set md4 active with 2 out of 2 mirrors md: updating md4 RAID superblock on device md: ide/host4/bus1/target0/lun0/part2 [events: 000000ab]<6>(write) ide/host4/bus1/target0/lun0/part2's sb offset: 979840 md: ide/host4/bus0/target0/lun0/part2 [events: 000000ab]<6>(write) ide/host4/bus0/target0/lun0/part2's sb offset: 979840 md: considering ide/host2/bus1/target0/lun0/part3 ... md: adding ide/host2/bus1/target0/lun0/part3 ... md: adding ide/host2/bus0/target0/lun0/part3 ... md: created md3 md: bind md: bind md: running: md: ide/host2/bus1/target0/lun0/part3's event counter: 000000e0 md: ide/host2/bus0/target0/lun0/part3's event counter: 000000e0 md: RAID level 1 does not need chunksize! Continuing anyway. md3: max total readahead window set to 124k md3: 1 data-disks, max readahead per data-disk: 124k raid1: device ide/host2/bus1/target0/lun0/part3 operational as mirror 1 raid1: device ide/host2/bus0/target0/lun0/part3 operational as mirror 0 raid1: raid set md3 active with 2 out of 2 mirrors md: updating md3 RAID superblock on device md: ide/host2/bus1/target0/lun0/part3 [events: 000000e1]<6>(write) ide/host2/bus1/target0/lun0/part3's sb offset: 43993920 md: ide/host2/bus0/target0/lun0/part3 [events: 000000e1]<6>(write) ide/host2/bus0/target0/lun0/part3's sb offset: 43993920 md: considering ide/host2/bus1/target0/lun0/part2 ... md: adding ide/host2/bus1/target0/lun0/part2 ... md: adding ide/host2/bus0/target0/lun0/part2 ... md: created md2 md: bind md: bind md: running: md: ide/host2/bus1/target0/lun0/part2's event counter: 000000e4 md: ide/host2/bus0/target0/lun0/part2's event counter: 000000e4 md: RAID level 1 does not need chunksize! Continuing anyway. md2: max total readahead window set to 124k md2: 1 data-disks, max readahead per data-disk: 124k raid1: device ide/host2/bus1/target0/lun0/part2 operational as mirror 1 raid1: device ide/host2/bus0/target0/lun0/part2 operational as mirror 0 raid1: raid set md2 active with 2 out of 2 mirrors md: updating md2 RAID superblock on device md: ide/host2/bus1/target0/lun0/part2 [events: 000000e5]<6>(write) ide/host2/bus1/target0/lun0/part2's sb offset: 979840 md: ide/host2/bus0/target0/lun0/part2 [events: 000000e5]<6>(write) ide/host2/bus0/target0/lun0/part2's sb offset: 979840 md: considering ide/host2/bus1/target0/lun0/part1 ... md: adding ide/host2/bus1/target0/lun0/part1 ... md: adding ide/host2/bus0/target0/lun0/part1 ... md: created md1 md: bind md: bind md: running: md: ide/host2/bus1/target0/lun0/part1's event counter: 000000e4 md: ide/host2/bus0/target0/lun0/part1's event counter: 000000e4 md: RAID level 1 does not need chunksize! Continuing anyway. md1: max total readahead window set to 124k md1: 1 data-disks, max readahead per data-disk: 124k raid1: device ide/host2/bus1/target0/lun0/part1 operational as mirror 1 raid1: device ide/host2/bus0/target0/lun0/part1 operational as mirror 0 raid1: raid set md1 active with 2 out of 2 mirrors md: updating md1 RAID superblock on device md: ide/host2/bus1/target0/lun0/part1 [events: 000000e5]<6>(write) ide/host2/bus1/target0/lun0/part1's sb offset: 48064 md: ide/host2/bus0/target0/lun0/part1 [events: 000000e5]<6>(write) ide/host2/bus0/target0/lun0/part1's sb offset: 48064 md: ... autorun DONE. NET4: Linux TCP/IP 1.0 for NET4.0 IP Protocols: ICMP, UDP, TCP, IGMP IP: routing cache hash table of 8192 buckets, 64Kbytes TCP: Hash tables configured (established 262144 bind 65536) NET4: Unix domain sockets 1.0/SMP for Linux NET4.0. NET4: Linux IPX 0.47 for NET4.0 IPX Portions Copyright (c) 1995 Caldera, Inc. IPX Portions Copyright (c) 2000, 2001 Conectiva, Inc. ds: no socket drivers loaded! RAMDISK: Compressed image found at block 0 Freeing initrd memory: 1135k freed VFS: Mounted root (ext2 filesystem). Mounted devfs on /dev LVM version 1.0.1-rc4(ish)(03/10/2001) module loaded cramfs: wrong magic lvm -- lvm_blk_ioctl: unknown command 0x5310 XFS mounting filesystem lvm(58,0) VFS: Mounted root (xfs filesystem) readonly. devfs: devfs_do_symlink(root): could not append to parent, err: -17 change_root: old root has d_count=2 Entering kdb (current=0xc1a08000, pid 1) Oops: invalid operand due to oops @ 0xc0126cda eax = 0x00000000 ebx = 0xc1a765b0 ecx = 0xc1a76618 edx = 0xc1a765a8 esi = 0xc1a765a1 edi = 0xc02fe1d4 esp = 0xc1a09ef4 eip = 0xc0126cda ebp = 0xc1a09f14 xss = 0x00000018 xcs = 0x00000010 eflags = 0x00010246 xds = 0xc0120018 xes = 0x00000018 origeax = 0xffffffff ®s = 0xc1a09ec0 kdb> bt EBP EIP Function(args) 0xc1a09f14 0xc0126cda kmem_cache_create+0x2b6 (0xc02fe1c7, 0x14, 0x20, 0x20000, 0x0) kernel .text 0xc0100000 0xc0126a24 0xc0126d1c 0xc1a09f34 0xc041f9a3 mount_devfs_fs+0x17 (0xc02f4cc0, 0x2, 0xffffff9e, 0xffffffff, 0x10) kernel .text.init 0xc0418000 0xc041f98c 0xc041fa00 0xc1a09fb8 0xc041f1b9 change_root+0xf9 (0x0, 0xc02ed7a3) kernel .text.init 0xc0418000 0xc041f0c0 0xc041f320 0xc1a09fdc 0xc0105239 prepare_namespace+0x12d kernel .text 0xc0100000 0xc010510c 0xc0105258 0xc1a09fec 0xc0105267 init+0xf kernel .text 0xc0100000 0xc0105258 0xc0105370 0xc01056e4 kernel_thread+0x28 kernel .text 0xc0100000 0xc01056bc 0xc01056f4 kdb> go invalid operand: 0000 CPU: 0 EIP: 0010:[] Not tainted EFLAGS: 00010246 eax: 00000000 ebx: c1a765b0 ecx: c1a76618 edx: c1a765a8 esi: c1a765a1 edi: c02fe1d4 ebp: c1a09f14 esp: c1a09ef4 ds: 0018 es: 0018 ss: 0018 Process swapper (pid: 1, stackpage=c1a09000) Stack: c1a09f64 e7ec2360 c1aaf4ce c1a09f10 c1a765d0 c0464ee8 00000004 0000000c c1a09f34 c041f9a3 c02fe1c7 00000014 00000020 00020000 00000000 00000000 c1a09fb8 c041f1b9 c02f4cc0 00000002 ffffff9e ffffffff 00000010 c1a09fd8 Call Trace: [] [] [] [] [] Code: 0f 0b 8b 12 81 fa 88 92 3f c0 75 da a1 88 92 3f c0 89 48 04 <0>Kernel panic: Attempted to kill init! Entering kdb (current=0xc1a08000, pid 1) due to panic kdb> sr b <6>SysRq : Resetting --=-=-= -- -rupa --=-=-=-- From owner-linux-xfs@oss.sgi.com Mon Jan 7 23:41:50 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g087fot23394 for linux-xfs-outgoing; Mon, 7 Jan 2002 23:41:50 -0800 Received: from srv.dmz.us.mvd (anyhosting.com [209.0.100.50] (may be forged)) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g087fhg23370 for ; Mon, 7 Jan 2002 23:41:43 -0800 Received: from John (unknown [210.72.245.13]) by srv.dmz.us.mvd (Postfix) with ESMTP id 2C741B65F; Mon, 7 Jan 2002 22:41:40 -0800 (PST) Date: Tue, 8 Jan 2002 14:43:51 +0800 (CST) From: John Niu X-X-Sender: To: Timothy Shimmin Cc: Subject: Re: XFS ACLs In-Reply-To: <20020108144851.K1500056@boing.melbourne.sgi.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 Content-Transfer-Encoding: 8BIT Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 2325 Lines: 62 Thank you Tim, I've read some related document and checked the source code. I understand the determining access of posix acl clearly now. :) Thanks for your enthusiastic help. John On Tue, 8 Jan 2002, Timothy Shimmin wrote: > Hi John, > > On Wed, Dec 26, 2001 at 11:01:38AM +0800, niu@mountainviewdata.com wrote: > > Hi XFS guys, > > > > I'm using ACLs of linux XFS to manage my share files. Recently, I > > encounter a confused problem: If a user belongs to multiple groups, and > > all the groups are set ALCs to a file(directory), then how about the > > user's permission to this file(directory)? > > > > I've do some test, the result looks like that: for file, the user's > > permission is the combination(OR operation) of his groups ACLs; but > > for directory, the user's permission looks weird, it's neither OR > > operation nor AND operation of his groups ACLs. > > > > Could you explain more details about the rule of XFS ACLs? Thank you. > > > > John > > > > > XFS ACLs are based on the Posix 1003.1e draft standard 17 (Section 23). > This withdrawn Posix ACL standard can be downloaded at: > http://wt.xpilot.org/posix.1e/download.html > Andreas Grünbacher's site: http://acl.bestbits.at/ > is also a useful resource. > > So if you are going to use ACLs it is worth doing some ACL reading :) > > I don't fully understand your problem. > Perhaps you can list the set of commands that you used > and the output from them. > > Checkout the section 23.1.2 (Relationship with File permission Bits) > to see how the ACL ACEs match up with the standard file permission > bits. > In particular one would note that the group permission bits > reflect the Mask permission bits when a Mask ACE exists > and Section B.23.3.6 (in Annex B) discusses reasons why this > scheme was chosen. > > (Also worthy of note, is that if you create a file whose parent dir > has a default ACL, then it's ACE permissions are set by the > _intersection_ of the respective default ACEs permission bits and > the mode bits of the parameter to open/creat. > If you have a MASK ACE (section 5.3.1.2), then the > ACE permissions on the new file will have a MASK ACE equal to > the intersection of the default MASK ACE permission bits > and the standard group permission bits of the parameter to open/creat.) > > --Tim > From owner-linux-xfs@oss.sgi.com Tue Jan 8 00:14:34 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g088EYN24180 for linux-xfs-outgoing; Tue, 8 Jan 2002 00:14:34 -0800 Received: from relay.xlink.net (relay.xlink.net [193.141.40.5]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g088EIg24150 for ; Tue, 8 Jan 2002 00:14:18 -0800 Received: from lizard.webland.de (lizard.webland.de [194.122.76.201]) by relay.xlink.net (8.9.3/8.8.7) with ESMTP id IAA13837; Tue, 8 Jan 2002 08:14:08 +0100 (MET) Received: (from uucp@localhost) by lizard.webland.de (8.8.8/8.8.7) id IAA01620; Tue, 8 Jan 2002 08:14:07 +0100 (MET) >Received: from mobile.sauter-bc.com (unknown [10.1.6.21]) by basel1.sauter-bc.com (Postfix) with ESMTP id 28D9A57306; Tue, 8 Jan 2002 08:13:55 +0100 (CET) Received: from ch.sauter-bc.com (support.cad.sba [10.1.200.117]) by mobile.sauter-bc.com (Postfix) with ESMTP id 8941125835; Tue, 8 Jan 2002 08:13:54 +0100 (CET) Message-ID: <3C3A9C32.123DA48@ch.sauter-bc.com> Date: Tue, 08 Jan 2002 08:13:54 +0100 From: Simon Matter Organization: Sauter AG, Basel X-Mailer: Mozilla 4.77 [de] (X11; U; Linux 2.2.19-6.2.12 i686) X-Accept-Language: de-CH, en MIME-Version: 1.0 To: Steve Lord Cc: Chris Parrott , linux-xfs@oss.sgi.com Subject: Re: write-caching with XFS References: <3C39DADF.8010700@echostar.com> <1010430010.7120.45.camel@jen.americas.sgi.com> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 6341 Lines: 142 Steve Lord schrieb: > > On Mon, 2002-01-07 at 11:29, Chris Parrott wrote: > > > > Greetings: > > > > I have noticed a very strange phenomenon involving XFS with hardware > > write-caching being active on Maxtor hard drives. We have seen this on > > both 80 GB and 120 GB drives, so it's not limited to any one drive model > > in particular. Maxtor turns on write-caching by default in their hard > > drives. > > > > We are working on a project which involves streaming live video data to > > a large (approx. 78-118 GB, depending on the drive) partition formatted > > with XFS. As the data comes in, it is held in a ring buffer before > > being dumped to the disk in fixed (approx. 99 KB) chunks. With > > write-caching turned on, dumping data to the XFS partition causes the > > ring buffer to eventually overflow, resulting in periodic data loss. > > However, if we turn off write-caching, the ring buffer never seems to > > overflow. It seems that the write calls just block longer with > > write-caching turned on. Unfortunately, the extra blocking time causes > > us to not be able to process our data promptly enough to prevent buffer > > overflows. > > > > We had an engineer from Maxtor perform some IDE bus traces while data > > was being spooled to the drive, and he could not find any indication > > that drive performance itself was the culprit. All of the I/O requests > > to the drive itself were completed within the usual, expected durations > > of time, once the corresponding IDE commands had been issued. > > > > I tried another experiment, in which I replaced the XFS filesystem with > > ReiserFS, to determine if the problem with filesystem vs. IDE-driver > > related. The ring buffer did not overflow when writing to the ReiserFS > > partition. (We cannot use ReiserFS in production, as we depend on some > > features only available in XFS.) > > > > We are using a 2.4.8 kernel, with the corresponding XFS patch applied. > > This kernel has been heavily modified to support our product, so we > > cannot easily upgrade to the very latest kernel revision. Hence, we > > have not been able to track all the subsequent XFS developments. > > > > Does anyone know what might be going on in XFS to cause this sort of > > behavior? I am curious as to why the write requests to XFS would take > > longer to complete with write-caching turned on. I would like to keep > > write-caching on, if at all possible, due to the overall performance gains. > > > > Many thanks in advance, > > You might consider this: > > Journaled filesystems rely on controlling the ordering of writes to the > disk to maintain integrity. If a log write is reported by the device > driver as being on disk, then the filesystem assumes it is free to > write out the metadata itself. Lets assume we have an operation which > takes a block from the free space and assigns it to a file. We create > a transaction to do this and write it to the log. Once the log write > is completed, we allow the metadata to go out to disk. There are two > chunks of metadata written independently. > > Lets assume write caching is on. We write the log record into the > cache, it returns saying the data is safe, we allow the metadata > to go out. For some reason, one of the metadata writes makes it > through cache before the log write does. If you crash at this point > you have a corrupt filesystem. Unless Maxtor can guarantee that they > never lose write cached data in a power failure you are on shaky > ground here. > > As for why you are seeing the behavior you are, I am not sure, but the > xfs log is probably being continually written to - a circular buffer > in the middle of the partition. If you have a spare spindle to experiment > with, create a filesystem with an external log and see how it behaves. > > mkfs -t xfs -f -l logdev=/dev/xxx,size=16384b /dev/yyy > > mount -t xfs -o logdev=/dev/xxx /dev/yyy /xfs > > Where /dev/xxx does not share the write cache with /dev/yyy > > It is possible the log writes are causing pathalogical behavior in > the cache. > > Steve I have made some performance tests in the last days just because I was wondering how bad XFS performs on SoftRAID. You didn't tell us whether you are using some kind of RAID so I expect you don't? The XFS FAQ says that XFS performs slightly worse than ext2 on Soft RAID1 and RAID5. I whish we could update the FAQ (Seth ?) to say it performs really bad (if you don't care about your logdev)! My test program used to run 40 minutes to complete on SoftRAID5 and without RAID or Hardware RAID it was finished in 10 minutes. Ok, my setup was: DELL PowerEdge 1400 with 4 U160 SCSI drives, DELL Raidadapter with 64M cache (Megaraid) and onboard dual U160 Adaptec SCSI, PIII/800, 256MB Ram. My programm is a mix of hd, cpu and network load. Some hundred procs of cp copying large amount of small files while a bonnie is running in background while copying some amount of data via NFS and so on. As I said mixed load. I have made this because when you just compare different bonnie's or other benchmarks then you don't see possible bottlenecks but in a dirty mixed test you may find them. The result, out of my head, where: XFS on Hardware RAID5 w/o write caching : ~10 min XFS on Hardware RAID5 w write caching : ~13 min EXT3 on Hardware RAID5 w/o write caching : ~13 min XFS on Software RAID5 w/o write caching : ~42 min EXT3 on Software RAID5 w/o write caching : ~12 min XFS on Software RAID5 w/o write caching, logdev on SoftRAID1 on the same disks : ~10 min As I understand it we can say: - Write caching does not always boost performance with XFS, and is very dangerous as steve mentioned before. - an external logdev can very much increase performance under some sircumstances. Sorry if my writing was just confusing but I liked to share what I found out after stressing my spindles for many hours. Simon > > > > > +chris > > > > > > Chris Parrott > > Linux Software Engineer > > Echostar Technologies Corp. > > 94 Inverness Terrace East > > Englewood, CO 80112 > > phone: 303 706 5383 / fax: 303 799 6222 > > e-mail: chris.parrott@echostar.com > > > -- > > Steve Lord voice: +1-651-683-3511 > Principal Engineer, Filesystem Software email: lord@sgi.com From owner-linux-xfs@oss.sgi.com Tue Jan 8 01:08:48 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0898ml25200 for linux-xfs-outgoing; Tue, 8 Jan 2002 01:08:48 -0800 Received: from ADSL-Bergs.RZ.RWTH-Aachen.DE (adsl-bergs.rz.RWTH-Aachen.DE [137.226.80.218]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0898hg25177 for ; Tue, 8 Jan 2002 01:08:44 -0800 Received: from [192.168.1.2] (helo=ralf) by ADSL-Bergs.RZ.RWTH-Aachen.DE with smtp (Exim 3.12 #1) id 16NrJD-00037O-00; Tue, 08 Jan 2002 09:08:35 +0100 From: "Ralf G. R. Bergs" To: "Steve Lord" Cc: "Linux XFS" , "Eric Sandeen" Date: Tue, 08 Jan 2002 09:08:34 +0100 Reply-To: "Ralf G. R. Bergs" X-Mailer: PMMail 2000 Professional (2.20.2380) For Windows 2000 (5.0.2195;2) In-Reply-To: <1010435724.15632.5.camel@jen.americas.sgi.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Subject: Re: file corruption during emacs build on XFS logical volume Message-Id: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 1021 Lines: 28 On Mon, 2002-01-07 at 12:51, Steve Lord wrote: [...] > Sean, can you see if the attached patch against the current cvs tree > fixes the problem for you? So far I have not been able to reproduce > with this change. [...] Steve, I tried the first fix (to the "Emacs" problem) you issued to see whether it helps with my problem, but it doesn't. I copied the old RAID over to the new one, got NO "filesystem shutdown" messages, but I still have these strange "hidden" files: Fileserver:/mnt/raidNEU# ls -lahR >/tmp/ls-lahR ls: ./path/to/file/069746IM.Mrw: No such file or directory I'm gonna try the new fix you issued on 07 Jan 2002 14:35:24 -0600 in your message with ID <1010435724.15632.5.camel@jen.americas.sgi.com> Thanks. -- Verkaufe Original-BMW-Raeder: L I N U X .~. http://adsl-bergs.rz.rwth-aachen.de/~rabe The Choice /V\ of a GNU /( )\ Generation ^^-^^ From owner-linux-xfs@oss.sgi.com Tue Jan 8 01:31:21 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g089VLI25640 for linux-xfs-outgoing; Tue, 8 Jan 2002 01:31:21 -0800 Received: from zork.zork.net (zork.zork.net [64.81.65.8]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g089VFg25615 for ; Tue, 8 Jan 2002 01:31:16 -0800 Received: from localhost (zork.zork.net) [127.0.0.1] by zork.zork.net with esmtp (Exim 3.33 #1 (Debian)) id 16Nrf5-00014z-00; Tue, 08 Jan 2002 00:31:11 -0800 To: Linux XFS Subject: Re: file corruption during emacs build on XFS logical volume References: <1010174871.30053.6.camel@jen.americas.sgi.com> <1010176193.2938.14.camel@UberGeek> <1010176393.30037.9.camel@jen.americas.sgi.com> <1010179700.30053.13.camel@jen.americas.sgi.com> <1010187371.30053.32.camel@jen.americas.sgi.com> <6uy9jdhdsr.fsf@zork.zork.net> <6upu4ph8c5.fsf@zork.zork.net> <3C37511F.6050809@sgi.com> <6uheq0fsu6.fsf@zork.zork.net> <1010429513.7120.35.camel@jen.americas.sgi.com> <1010435724.15632.5.camel@jen.americas.sgi.com> From: Sean Neakums X-Message-Flag: Message text advisory: ARGUMENTUM AD BACULUM, DENIAL OF THE ANTECEDENT X-Mailer: Norman Mail-Followup-To: Linux XFS Date: Tue, 08 Jan 2002 08:31:11 +0000 In-Reply-To: <1010435724.15632.5.camel@jen.americas.sgi.com> (Steve Lord's message of "07 Jan 2002 14:35:24 -0600") Message-ID: <6u666dz1kg.fsf@zork.zork.net> User-Agent: Gnus/5.090004 (Oort Gnus v0.04) Emacs/21.1 (i386-debian-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 1289 Lines: 29 begin Steve Lord quotation: > On Mon, 2002-01-07 at 12:51, Steve Lord wrote: >> On Sat, 2002-01-05 at 14:25, Sean Neakums wrote: >> > begin Stephen Lord quotation: >> > > OK, thanks, this narrows it down even more than I had - I was >> > > running a kernel from Dec 22nd and recreating the problem. I had >> > > tried the individual patches to the I/O path and failed to recreate >> > > it - but maybe I should try that again. >> > I just found a kernel from December 8 (I had removed it from >> > lilo.conf, but forgotten to delete the kernel itself and the modules) >> > and I cannot recreate on that. >> Sean, can you see if the attached patch against the current cvs tree >> fixes the problem for you? So far I have not been able to reproduce >> with this change. > > And here is a patch I prefer you test - since I think this is more like > a real fix instead of a go back and mask the original problem again Steve, I'm afraid I've had to travel unexpectedly this week -- I won't be back at my XFS box until Friday. I'll test the patch as soon as I get back Friday. Sean -- ///////////////// | | The spark of a pin | (require 'gnu) | dropping, falling feather-like. \\\\\\\\\\\\\\\\\ | | There is too much noise. From owner-linux-xfs@oss.sgi.com Tue Jan 8 02:28:36 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g08ASav26958 for linux-xfs-outgoing; Tue, 8 Jan 2002 02:28:36 -0800 Received: from hammer.brocade.com (asbestos.brocade.com [63.121.140.244]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g08ASUg26936 for ; Tue, 8 Jan 2002 02:28:30 -0800 Received: (from root@localhost) by hammer.brocade.com (8.11.3/8.11.3) id g089QVJ00669; Tue, 8 Jan 2002 01:27:24 -0800 (PST) Message-Id: <200201080927.g089QVJ00669@hammer.brocade.com> From: Adrian Head To: Rupa Schomaker , linux-xfs@oss.sgi.com Subject: Re: GRUB + LVM + XFS? Date: Tue, 8 Jan 2002 10:48:11 +1000 X-Mailer: KMail [version 1.3.1] References: <1010427293.29260.3.camel@UberGeek> In-Reply-To: Cc: linux-lvm@sistina.com MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 1821 Lines: 49 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Tue, 8 Jan 2002 05:54, Rupa Schomaker wrote: > I'm having toubles with the current CVS version of the XFS kernel. I > haven't had time to look at it completely, but... it could be: > > 1) mismatch between userspace and kernel (what LVM is in the XFS > kernel? I'm using the debian lvm10 userspace). > > 2) bad config > > 3) ??? > > A quick "bt" at boot in kdb shows that devfs is in the call path. No, > I haven't had time to write everything down. :( Man, I wish there was > an easy to dump the kdb info or an OOPs to disk... Well all I do is for getting kdb output is to use a serial console and another computer - then cut and past then send ;-). It is very interesting that devfs is referenced - there was a LVM memory corruption problem and a patch for LVM/devfs - it can be found here: http://marc.theaimsgroup.com/?l=linux-xfs&m=101031443221058&w=2 - From my experience it seems that LVM 1.0.1rc4(ish) is way more robust than the updated LVM 1.0.1 or even CVS LVM 1.0.1 yesterday. However, not everything works as expected with either. You can find a results table for a few tests I have conducted here: (of course YMMV) http://marc.theaimsgroup.com/?l=linux-lvm&m=100994364215110&w=2 I think you would be very interested in the discussions and activity that has been occuring on the linux-xfs & linux-lvm lists at the moment regarding XFS and LVM. If you are seeing problems I would be very interested in finding out how your problems differ from mine. - -- Adrian Head (Public Key available on request.) -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE8OkHO8ZJI8OvSkAcRAsHkAJ9OlEWOQMxiXXsJ0OzsllI7icT8pQCeLfM2 95t821X+y25nYdf3WCDRg9k= =rjIv -----END PGP SIGNATURE----- From owner-linux-xfs@oss.sgi.com Tue Jan 8 04:57:34 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g08CvYA03761 for linux-xfs-outgoing; Tue, 8 Jan 2002 04:57:34 -0800 Received: from e4.eyal.emu.id.au (CPE-203-51-31-41.nsw.bigpond.net.au [203.51.31.41]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g08CvIg03630 for ; Tue, 8 Jan 2002 04:57:18 -0800 Received: from eyal.emu.id.au (eyal.emu.id.au [192.168.2.7]) by e4.eyal.emu.id.au (8.11.6/8.11.6) with ESMTP id g08BvDs19397 for ; Tue, 8 Jan 2002 22:57:13 +1100 Received: from eyal.emu.id.au (really [192.168.2.7]) by eyal.emu.id.au via smail with esmtp id (Debian Smail3.2.0.114) for ; Sat, 5 Jan 2002 11:51:17 +1100 (EST) Message-ID: <3C364E05.C8F79CCB@eyal.emu.id.au> Date: Sat, 05 Jan 2002 11:51:17 +1100 From: Eyal Lebedinsky Organization: Eyal at Home X-Mailer: Mozilla 4.79 [en] (X11; U; Linux 2.4.17 i686) X-Accept-Language: en MIME-Version: 1.0 To: linux-xfs list Subject: Re: TAKE - Sync kdb v2.0-2.4.17 i386 code with xfs References: <200201040426.g044Qv923358@sherman.melbourne.sgi.com> Content-Type: multipart/mixed; boundary="------------09910297B50047CB432F0EB1" Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 1386 Lines: 48 This is a multi-part message in MIME format. --------------09910297B50047CB432F0EB1 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit My first email never showed up on the list, here is another try: =============================== Keith Owens wrote: > > Date: Thu Jan 3 20:24:15 PST 2002 > 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:109106a > linux/arch/i386/kernel/traps.c - 1.41 It does not compile without KDB. This patch protects an unconditional reference to KDB. -- Eyal Lebedinsky (eyal@eyal.emu.id.au) --------------09910297B50047CB432F0EB1 Content-Type: text/plain; charset=us-ascii; name="2.4.17-xfs-traps.diff" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="2.4.17-xfs-traps.diff" --- linux/arch/i386/kernel/traps.c.orig Fri Jan 4 21:13:50 2002 +++ linux/arch/i386/kernel/traps.c Fri Jan 4 21:14:20 2002 @@ -581,7 +581,9 @@ return; } #endif +#ifdef CONFIG_KDB (void)kdb(KDB_REASON_NMI, reason, regs); +#endif printk("Uhhuh. NMI received for unknown reason %02x.\n", reason); printk("Dazed and confused, but trying to continue\n"); printk("Do you have a strange power saving mode enabled?\n"); --------------09910297B50047CB432F0EB1-- From owner-linux-xfs@oss.sgi.com Tue Jan 8 04:57:28 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g08CvSb03723 for linux-xfs-outgoing; Tue, 8 Jan 2002 04:57:28 -0800 Received: from e4.eyal.emu.id.au (CPE-203-51-31-41.nsw.bigpond.net.au [203.51.31.41]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g08CvMg03664 for ; Tue, 8 Jan 2002 04:57:22 -0800 Received: from eyal.emu.id.au (eyal.emu.id.au [192.168.2.7]) by e4.eyal.emu.id.au (8.11.6/8.11.6) with ESMTP id g08BvDs19401; Tue, 8 Jan 2002 22:57:14 +1100 Received: from eyal.emu.id.au (really [192.168.2.7]) by eyal.emu.id.au via smail with esmtp id (Debian Smail3.2.0.114) for ; Fri, 4 Jan 2002 21:13:07 +1100 (EST) Message-ID: <3C358033.2834B90D@eyal.emu.id.au> Date: Fri, 04 Jan 2002 21:13:07 +1100 From: Eyal Lebedinsky Organization: Eyal at Home X-Mailer: Mozilla 4.79 [en] (X11; U; Linux 2.4.17 i686) X-Accept-Language: en MIME-Version: 1.0 To: Keith Owens CC: linux-xfs list Subject: Re: TAKE - Sync kdb v2.0-2.4.17 i386 code with xfs References: <200201040426.g044Qv923358@sherman.melbourne.sgi.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 1474 Lines: 39 Keith Owens wrote: > > Date: Thu Jan 3 20:24:15 PST 2002 > 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:109106a > linux/arch/i386/kdb/ChangeLog - 1.1 > linux/arch/i386/kernel/traps.c - 1.41 > linux/arch/i386/kernel/smp.c - 1.38 > linux/arch/i386/kernel/process.c - 1.37 > linux/arch/i386/kernel/irq.c - 1.38 > linux/arch/i386/kernel/smpboot.c - 1.26 > linux/include/asm-i386/kdb.h - 1.9 > linux/include/asm-i386/kdbprivate.h - 1.14 > linux/arch/i386/kernel/bluesmoke.c - 1.15 gcc -D__KERNEL__ -I/data2/usr/local/src/linux-2.4-xfs/linux/include -Wall -Wstrict-prototypes -Wno-trigraphs -O2 -fno-strict-aliasing -fno-common -fomit-frame-pointer -pipe -mpreferred-stack-boundary=2 -march=i686 -malign-functions=4 -c -o traps.o traps.c traps.c: In function `unknown_nmi_error': traps.c:584: warning: implicit declaration of function `kdb' traps.c:584: `KDB_REASON_NMI' undeclared (first use in this function) traps.c:584: (Each undeclared identifier is reported only once traps.c:584: for each function it appears in.) make[1]: *** [traps.o] Error 1 make[1]: Leaving directory `/data2/usr/local/src/linux-2.4-xfs/linux/arch/i386/kernel' Missing "#ifdef CONFIG_KDB"? My .config did not offer any CONFIG_KDB options since I have "# CONFIG_DEBUG_KERNEL is not set". -- Eyal Lebedinsky (eyal@eyal.emu.id.au) From owner-linux-xfs@oss.sgi.com Tue Jan 8 04:57:25 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g08CvPM03686 for linux-xfs-outgoing; Tue, 8 Jan 2002 04:57:25 -0800 Received: from e4.eyal.emu.id.au (CPE-203-51-31-41.nsw.bigpond.net.au [203.51.31.41]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g08CvIg03629 for ; Tue, 8 Jan 2002 04:57:18 -0800 Received: from eyal.emu.id.au (eyal.emu.id.au [192.168.2.7]) by e4.eyal.emu.id.au (8.11.6/8.11.6) with ESMTP id g08BvEs19405 for ; Tue, 8 Jan 2002 22:57:14 +1100 Received: from eyal.emu.id.au (really [192.168.2.7]) by eyal.emu.id.au via smail with esmtp id (Debian Smail3.2.0.114) for ; Fri, 4 Jan 2002 21:18:17 +1100 (EST) Message-ID: <3C358169.BD73DC7B@eyal.emu.id.au> Date: Fri, 04 Jan 2002 21:18:17 +1100 From: Eyal Lebedinsky Organization: Eyal at Home X-Mailer: Mozilla 4.79 [en] (X11; U; Linux 2.4.17 i686) X-Accept-Language: en MIME-Version: 1.0 CC: linux-xfs list Subject: Re: TAKE - Sync kdb v2.0-2.4.17 i386 code with xfs References: <200201040426.g044Qv923358@sherman.melbourne.sgi.com> Content-Type: multipart/mixed; boundary="------------E633C25B638D91AED2CB7D53" Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 1287 Lines: 44 This is a multi-part message in MIME format. --------------E633C25B638D91AED2CB7D53 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Keith Owens wrote: > > Date: Thu Jan 3 20:24:15 PST 2002 > 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:109106a > linux/arch/i386/kernel/traps.c - 1.41 It does not compile without KDB. This patch protects an unconditional reference to KDB. -- Eyal Lebedinsky (eyal@eyal.emu.id.au) --------------E633C25B638D91AED2CB7D53 Content-Type: text/plain; charset=us-ascii; name="2.4.17-xfs-traps.diff" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="2.4.17-xfs-traps.diff" --- linux/arch/i386/kernel/traps.c.orig Fri Jan 4 21:13:50 2002 +++ linux/arch/i386/kernel/traps.c Fri Jan 4 21:14:20 2002 @@ -581,7 +581,9 @@ return; } #endif +#ifdef CONFIG_KDB (void)kdb(KDB_REASON_NMI, reason, regs); +#endif printk("Uhhuh. NMI received for unknown reason %02x.\n", reason); printk("Dazed and confused, but trying to continue\n"); printk("Do you have a strange power saving mode enabled?\n"); --------------E633C25B638D91AED2CB7D53-- From owner-linux-xfs@oss.sgi.com Tue Jan 8 04:57:09 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g08Cv9l03608 for linux-xfs-outgoing; Tue, 8 Jan 2002 04:57:09 -0800 Received: from server.f1korea.co.kr ([61.79.123.106]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g08Cuxg03584 for ; Tue, 8 Jan 2002 04:57:02 -0800 Received: from mail pickup service by server.f1korea.co.kr with Microsoft SMTPSVC; Tue, 8 Jan 2002 20:58:58 +0900 From: =?euc-kr?B?v6m787+x?= To: Subject: =?euc-kr?B?ILzWwffI9yDCr8b5IL+xseLG+SCxpCCw7cDUtM+02S4g?= Date: Tue, 8 Jan 2002 20:58:55 +0900 MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Message-ID: X-OriginalArrivalTime: 08 Jan 2002 11:58:58.0562 (UTC) FILETIME=[DADEEE20:01C1983B] Content-Disposition: inline Content-Type: text/plain Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id g08Cv9m03608 Status: O Content-Length: 381 Lines: 40 ¸ÞÀÏÀ» ¹Þ±â ¿øÄ¡ ¾ÊÀ¸½Ã¸é ²À! ¼ö½Å°ÅºÎ¸¦ ÇØÁÖ¼¼¿ä. ¼ö½Å °ÅºÎ´Â ÀÌ°÷ À» ´­·¯ÁÖ¼¼¿ä. [[HTML alternate version deleted]] From owner-linux-xfs@oss.sgi.com Tue Jan 8 05:23:03 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g08DN3b04711 for linux-xfs-outgoing; Tue, 8 Jan 2002 05:23:03 -0800 Received: from deliverator.sgi.com (deliverator.sgi.com [204.94.214.10]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g08DMxg04688 for ; Tue, 8 Jan 2002 05:22:59 -0800 Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id EAA03353 for ; Tue, 8 Jan 2002 04:22:41 -0800 (PST) mail_from (lord@sgi.com) Received: from tulip-e185.americas.sgi.com (tulip-e185.americas.sgi.com [128.162.185.208]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id GAA3130272; Tue, 8 Jan 2002 06:21:41 -0600 (CST) Received: from sgi.com (z5TiM8Br+YgDfUD2EMu5JyXj1mHtRNiu@cf-vpn-sw-corp-64-20.corp.sgi.com [134.15.64.20]) by tulip-e185.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.7) with ESMTP id GAA71373; Tue, 8 Jan 2002 06:21:39 -0600 (CST) Message-ID: <3C3AE54D.1070207@sgi.com> Date: Tue, 08 Jan 2002 06:25:49 -0600 From: Stephen Lord User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.6) Gecko/20011120 X-Accept-Language: en-us MIME-Version: 1.0 To: "Ralf G. R. Bergs" CC: Linux XFS , Eric Sandeen Subject: Re: file corruption during emacs build on XFS logical volume References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 916 Lines: 30 Ralf G. R. Bergs wrote: >On Mon, 2002-01-07 at 12:51, Steve Lord wrote: >[...] > >>Sean, can you see if the attached patch against the current cvs tree >>fixes the problem for you? So far I have not been able to reproduce >>with this change. >> >[...] > >Steve, I tried the first fix (to the "Emacs" problem) you issued to see whether >it helps with my problem, but it doesn't. I copied the old RAID over to the new >one, got NO "filesystem shutdown" messages, but I still have these strange >"hidden" files: > >Fileserver:/mnt/raidNEU# ls -lahR >/tmp/ls-lahR >ls: ./path/to/file/069746IM.Mrw: No such file or directory > >I'm gonna try the new fix you issued on 07 Jan 2002 14:35:24 -0600 in your >message with ID <1010435724.15632.5.camel@jen.americas.sgi.com> > Unfortunately, neither of these is going to help you I believe, they are related to a file corruption, not to a metadata corruption. Steve From owner-linux-xfs@oss.sgi.com Tue Jan 8 05:30:32 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g08DUWn04935 for linux-xfs-outgoing; Tue, 8 Jan 2002 05:30:32 -0800 Received: from pneumatic-tube.sgi.com (pneumatic-tube.sgi.com [204.94.214.22]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g08DUNg04913 for ; Tue, 8 Jan 2002 05:30:24 -0800 Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id EAA06319 for ; Tue, 8 Jan 2002 04:30:59 -0800 (PST) mail_from (lord@sgi.com) Received: from tulip-e185.americas.sgi.com (tulip-e185.americas.sgi.com [128.162.185.208]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id GAA4031124; Tue, 8 Jan 2002 06:29:05 -0600 (CST) Received: from sgi.com (4xrKreERWeBw/jdQ9I4HOK1mB8SVMTIs@cf-vpn-sw-corp-64-20.corp.sgi.com [134.15.64.20]) by tulip-e185.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.7) with ESMTP id GAA71247; Tue, 8 Jan 2002 06:29:03 -0600 (CST) Message-ID: <3C3AE709.30701@sgi.com> Date: Tue, 08 Jan 2002 06:33:13 -0600 From: Stephen Lord User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.6) Gecko/20011120 X-Accept-Language: en-us MIME-Version: 1.0 To: Simon Matter CC: Chris Parrott , linux-xfs@oss.sgi.com Subject: Re: write-caching with XFS References: <3C39DADF.8010700@echostar.com> <1010430010.7120.45.camel@jen.americas.sgi.com> <3C3A9C32.123DA48@ch.sauter-bc.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 2485 Lines: 63 Simon Matter wrote > >I have made some performance tests in the last days just because I was >wondering how bad XFS performs on SoftRAID. You didn't tell us whether >you are using some kind of RAID so I expect you don't? > >The XFS FAQ says that XFS performs slightly worse than ext2 on Soft >RAID1 and RAID5. I whish we could update the FAQ (Seth ?) to say it >performs really bad (if you don't care about your logdev)! My test >program used to run 40 minutes to complete on SoftRAID5 and without RAID >or Hardware RAID it was finished in 10 minutes. Ok, my setup was: > >DELL PowerEdge 1400 with 4 U160 SCSI drives, DELL Raidadapter with 64M >cache (Megaraid) and onboard dual U160 Adaptec SCSI, PIII/800, 256MB >Ram. >My programm is a mix of hd, cpu and network load. Some hundred procs of >cp copying large amount of small files while a bonnie is running in >background while copying some amount of data via NFS and so on. As I >said mixed load. I have made this because when you just compare >different bonnie's or other benchmarks then you don't see possible >bottlenecks but in a dirty mixed test you may find them. The result, out >of my head, where: > >XFS on Hardware RAID5 w/o write caching : ~10 min >XFS on Hardware RAID5 w write caching : ~13 min >EXT3 on Hardware RAID5 w/o write caching : ~13 min >XFS on Software RAID5 w/o write caching : ~42 min >EXT3 on Software RAID5 w/o write caching : ~12 min >XFS on Software RAID5 w/o write caching, > logdev on SoftRAID1 on the same disks : ~10 min > >As I understand it we can say: >- Write caching does not always boost performance with XFS, and is very >dangerous as steve mentioned before. >- an external logdev can very much increase performance under some >sircumstances. > >Sorry if my writing was just confusing but I liked to share what I found >out after stressing my spindles for many hours. > >Simon > Ugly, isn't it. The XFS log has the nasty habit of doing unaligned writes on any 512 byte boundary - a 31.5K write is not unusual. I did not realize is was this bad on raid5 though - I knew it was worse, just forgotten how much! I think this is due to the raid code doing cache flushes in this case. We have talked about adding some padding to the log, but it is an on disk format change, so not something to do lightly, if I find time I may do some experiments with it. There may be hope in 2.5, but I do not know if the raid5 code has been converted to bio structures yet. Steve From owner-linux-xfs@oss.sgi.com Tue Jan 8 05:33:18 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g08DXIO05107 for linux-xfs-outgoing; Tue, 8 Jan 2002 05:33:18 -0800 Received: from ADSL-Bergs.RZ.RWTH-Aachen.DE (adsl-bergs.rz.RWTH-Aachen.DE [137.226.80.218]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g08DXDg05085 for ; Tue, 8 Jan 2002 05:33:13 -0800 Received: from [192.168.1.2] (helo=ralf) by ADSL-Bergs.RZ.RWTH-Aachen.DE with smtp (Exim 3.12 #1) id 16NvRB-0003ZS-00; Tue, 08 Jan 2002 13:33:05 +0100 From: "Ralf G. R. Bergs" To: "Stephen Lord" Cc: "Linux XFS" , "Eric Sandeen" Date: Tue, 08 Jan 2002 13:33:04 +0100 Reply-To: "Ralf G. R. Bergs" X-Mailer: PMMail 2000 Professional (2.20.2380) For Windows 2000 (5.0.2195;2) In-Reply-To: <3C3AE54D.1070207@sgi.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Subject: Re: file corruption during emacs build on XFS logical volume Message-Id: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 1137 Lines: 37 On Tue, 08 Jan 2002 06:25:49 -0600, Stephen Lord wrote: [...] >>Steve, I tried the first fix (to the "Emacs" problem) you issued to see whether >>it helps with my problem, but it doesn't. I copied the old RAID over to the new >>one, got NO "filesystem shutdown" messages, but I still have these strange >>"hidden" files: >> >>Fileserver:/mnt/raidNEU# ls -lahR >/tmp/ls-lahR >>ls: ./path/to/file/069746IM.Mrw: No such file or directory >> >>I'm gonna try the new fix you issued on 07 Jan 2002 14:35:24 -0600 in your >>message with ID <1010435724.15632.5.camel@jen.americas.sgi.com> >> > >Unfortunately, neither of these is going to help you I believe, they are >related to >a file corruption, not to a metadata corruption. I see. Sorry, my fault. Do you have any idea what else I could do to further investigate *my* problem? Thanks, Ralf -- Verkaufe Original-BMW-Raeder: L I N U X .~. http://adsl-bergs.rz.rwth-aachen.de/~rabe The Choice /V\ of a GNU /( )\ Generation ^^-^^ From owner-linux-xfs@oss.sgi.com Tue Jan 8 05:52:42 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g08DqgI05546 for linux-xfs-outgoing; Tue, 8 Jan 2002 05:52:42 -0800 Received: from yog-sothoth.sgi.com (eugate.sgi.com [192.48.160.10]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g08DqWg05520 for ; Tue, 8 Jan 2002 05:52:32 -0800 Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by yog-sothoth.sgi.com (980305.SGI.8.8.8-aspam-6.2/980304.SGI-aspam-europe) via ESMTP id NAA1430937 for ; Tue, 8 Jan 2002 13:50:23 +0100 (CET) mail_from (lord@sgi.com) Received: from tulip-e185.americas.sgi.com (tulip-e185.americas.sgi.com [128.162.185.208]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id GAA4019108; Tue, 8 Jan 2002 06:51:04 -0600 (CST) Received: from sgi.com (ksQAwrjDVBZDXToOHcghkkLcZnLG8gV0@cf-vpn-sw-corp-64-20.corp.sgi.com [134.15.64.20]) by tulip-e185.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.7) with ESMTP id GAA68071; Tue, 8 Jan 2002 06:51:03 -0600 (CST) Message-ID: <3C3AEC30.5090201@sgi.com> Date: Tue, 08 Jan 2002 06:55:12 -0600 From: Stephen Lord User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.6) Gecko/20011120 X-Accept-Language: en-us MIME-Version: 1.0 To: "Ralf G. R. Bergs" CC: Linux XFS , Eric Sandeen Subject: Re: file corruption during emacs build on XFS logical volume References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 876 Lines: 49 Ralf G. R. Bergs wrote: > >I see. Sorry, my fault. > >Do you have any idea what else I could do to further investigate *my* problem? > >Thanks, > >Ralf > > You are in the 'queue', unfortunately, there are not many hardware raids accessible around here for linux development, so duplication of your environment is a little tricky from this end We still need to look at the repair output you sent, it should give us some pointers as to what is happening to you. I have passed it on to the developer who knows the most about the directory structures. If you still have the system in this state, could you run xfs_db on the unmounted filesystem: xfs_db /dev/xxxxx Then enter these commands and send the output inode 989855872 p quit This should dump the inode and directory contents of the offending structures and give us some more hints. Thanks Steve Steve From owner-linux-xfs@oss.sgi.com Tue Jan 8 06:35:49 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g08EZnj06582 for linux-xfs-outgoing; Tue, 8 Jan 2002 06:35:49 -0800 Received: from mta04ps.bigpond.com (mta04ps.bigpond.com [144.135.25.136]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g08EZkg06560 for ; Tue, 8 Jan 2002 06:35:46 -0800 Message-Id: <200201081435.g08EZkg06560@oss.sgi.com> Received: from there ([144.135.25.87]) by mta04ps.bigpond.com (Netscape Messaging Server 4.15) with SMTP id GPMGR200.84K; Tue, 8 Jan 2002 23:42:38 +1000 Received: from CPE-144-137-138-230.qld.bigpond.net.au ([144.137.138.230]) by psmam07.mailsvc.email.bigpond.com(MailRouter V3.0h 125/1469567); 08 Jan 2002 23:35:37 Content-Type: text/plain; charset="us-ascii" From: Adrian Head To: linux-lvm@sistina.com, linux-xfs@oss.sgi.com Subject: Re: [linux-lvm] Re: GRUB + LVM + XFS? Date: Tue, 8 Jan 2002 23:35:18 +1000 X-Mailer: KMail [version 1.3.1] MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 460 Lines: 19 To everyone on the lists I appologise and will refrain from using a signature in the future when posting to the lists. On Tue, 8 Jan 2002 21:44, Eric M. Hopper wrote: > On Mon, 2002-01-07 at 18:48, Adrian Head wrote: > > Adrian Head > > > > (Public Key available on request.) > > So, what is it? I'm tired of seeing the message about an unverifiable > signature. :-) > > Have fun (if at all possible), -- Adrian Head (Public Key available on request.) From owner-linux-xfs@oss.sgi.com Tue Jan 8 06:50:41 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g08Eofn06982 for linux-xfs-outgoing; Tue, 8 Jan 2002 06:50:41 -0800 Received: from rover (rover.mkp.net [209.217.122.9]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g08EoZg06960 for ; Tue, 8 Jan 2002 06:50:35 -0800 Received: from localhost.localdomain ([127.0.0.1] helo=rover.mkp.net) by rover with esmtp (Exim 3.33 #1) id 16Nwdh-0006I0-00; Tue, 08 Jan 2002 08:50:05 -0500 Received: (from mkp@localhost) by rover.mkp.net (8.11.6/8.9.3) id g08DndH01583; Tue, 8 Jan 2002 08:49:39 -0500 X-Authentication-Warning: jaguar.wave.mkp.net: mkp set sender to mkp@mkp.net using -f To: Stephen Lord Cc: Simon Matter , Chris Parrott , linux-xfs@oss.sgi.com Subject: Re: write-caching with XFS References: <3C39DADF.8010700@echostar.com> <1010430010.7120.45.camel@jen.americas.sgi.com> <3C3A9C32.123DA48@ch.sauter-bc.com> <3C3AE709.30701@sgi.com> From: "Martin K. Petersen" Organization: Linuxcare, Inc. Date: 08 Jan 2002 08:49:39 -0500 In-Reply-To: <3C3AE709.30701@sgi.com> Message-ID: User-Agent: Gnus/5.0808 (Gnus v5.8.8) XEmacs/21.4 (Civil Service) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 1539 Lines: 40 >>>>> "Steve" == Stephen Lord writes: >> The XFS FAQ says that XFS performs slightly worse than ext2 on Soft >> RAID1 and RAID5. Hrm, I wonder why it says RAID1. RAID1 doesn't have a stripe cache and consequently doesn't suffer. I think the RAID1 comment may be a leftover from when I switched MD from 1K to 512 byte resyncs and had problems with the throttling. In any case, I think we should remove RAID1 from the caveat. >> XFS on Hardware RAID5 w/o write caching : ~10 min XFS on Hardware >> RAID5 w write caching : ~13 min EXT3 on Hardware RAID5 w/o write >> caching : ~13 min XFS on Software RAID5 w/o write caching : ~42 min >> EXT3 on Software RAID5 w/o write caching : ~12 min XFS on Software >> RAID5 w/o write caching, logdev on SoftRAID1 on the same disks : >> ~10 min Simon: Hrm, nasty. Did you let the RAID5 device finish resync before use? With both XFS and the resync messing with the stripe cache, performance is bound to suffer bigtime. Steve> We have talked about adding some padding to the log, but it is Steve> an on disk format change, so not something to do lightly, if I Steve> find time I may do some experiments with it. Another option (which could potentially also help XFS on mainframes with 4K hardware sectors) is to have a slim layer do read-modify-write on fixed size chunks between the fs and RAID5. -- Martin K. Petersen, Principal Linux Consultant, Linuxcare, Inc. mkp@linuxcare.com, http://www.linuxcare.com/ SGI XFS for Linux Developer, http://oss.sgi.com/projects/xfs/ From owner-linux-xfs@oss.sgi.com Tue Jan 8 07:08:27 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g08F8RH07419 for linux-xfs-outgoing; Tue, 8 Jan 2002 07:08:27 -0800 Received: from relay.xlink.net (relay.xlink.net [193.141.40.5]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g08F8Jg07397 for ; Tue, 8 Jan 2002 07:08:19 -0800 Received: from lizard.webland.de (lizard.webland.de [194.122.76.201]) by relay.xlink.net (8.9.3/8.8.7) with ESMTP id PAA01121; Tue, 8 Jan 2002 15:08:13 +0100 (MET) Received: (from uucp@localhost) by lizard.webland.de (8.8.8/8.8.7) id PAA10029; Tue, 8 Jan 2002 15:08:13 +0100 (MET) >Received: from mobile.sauter-bc.com (unknown [10.1.6.21]) by basel1.sauter-bc.com (Postfix) with ESMTP id 37D6A57306; Tue, 8 Jan 2002 15:07:25 +0100 (CET) Received: from ch.sauter-bc.com (support.cad.sba [10.1.200.117]) by mobile.sauter-bc.com (Postfix) with ESMTP id 74CEC25835; Tue, 8 Jan 2002 15:07:24 +0100 (CET) Message-ID: <3C3AFD1C.BAA09FD7@ch.sauter-bc.com> Date: Tue, 08 Jan 2002 15:07:24 +0100 From: Simon Matter Organization: Sauter AG, Basel X-Mailer: Mozilla 4.77 [de] (X11; U; Linux 2.2.19-6.2.12 i686) X-Accept-Language: de-CH, en MIME-Version: 1.0 To: "Martin K. Petersen" Cc: Stephen Lord , Chris Parrott , linux-xfs@oss.sgi.com Subject: Re: write-caching with XFS References: <3C39DADF.8010700@echostar.com> <1010430010.7120.45.camel@jen.americas.sgi.com> <3C3A9C32.123DA48@ch.sauter-bc.com> <3C3AE709.30701@sgi.com> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 1927 Lines: 50 "Martin K. Petersen" schrieb: > > >>>>> "Steve" == Stephen Lord writes: > > >> The XFS FAQ says that XFS performs slightly worse than ext2 on Soft > >> RAID1 and RAID5. > > Hrm, I wonder why it says RAID1. RAID1 doesn't have a stripe cache > and consequently doesn't suffer. > > I think the RAID1 comment may be a leftover from when I switched MD > from 1K to 512 byte resyncs and had problems with the throttling. > > In any case, I think we should remove RAID1 from the caveat. I'd like so see a comment there that using an external log with RAID5 is a solution. > > >> XFS on Hardware RAID5 w/o write caching : ~10 min XFS on Hardware > >> RAID5 w write caching : ~13 min EXT3 on Hardware RAID5 w/o write > >> caching : ~13 min XFS on Software RAID5 w/o write caching : ~42 min > >> EXT3 on Software RAID5 w/o write caching : ~12 min XFS on Software > >> RAID5 w/o write caching, logdev on SoftRAID1 on the same disks : > >> ~10 min > > Simon: > > Hrm, nasty. Did you let the RAID5 device finish resync before use? > With both XFS and the resync messing with the stripe cache, > performance is bound to suffer bigtime. The RAID5 was always synced when I ran the tests (those U160/10000k disks are really fast - and small with 9G). The interesting thing is that with a simple bonnie or handling big files the Soft RAID5 is much faster on this machine than the Hardware RAID5. Streaming Gigabytes from a file (or was it to a file) gave me 112M/sec with Soft RAID5 and 58M/sec with Hardware RAID5. > > Steve> We have talked about adding some padding to the log, but it is > Steve> an on disk format change, so not something to do lightly, if I > Steve> find time I may do some experiments with it. > > Another option (which could potentially also help XFS on mainframes > with 4K hardware sectors) is to have a slim layer do read-modify-write > on fixed size chunks between the fs and RAID5. > From owner-linux-xfs@oss.sgi.com Tue Jan 8 07:17:45 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g08FHjV07727 for linux-xfs-outgoing; Tue, 8 Jan 2002 07:17:45 -0800 Received: from ADSL-Bergs.RZ.RWTH-Aachen.DE (adsl-bergs.rz.RWTH-Aachen.DE [137.226.80.218]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g08FHVg07699 for ; Tue, 8 Jan 2002 07:17:32 -0800 Received: from [192.168.1.2] (helo=ralf) by ADSL-Bergs.RZ.RWTH-Aachen.DE with smtp (Exim 3.12 #1) id 16Nx3y-0003k0-00; Tue, 08 Jan 2002 15:17:14 +0100 From: "Ralf G. R. Bergs" To: "Stephen Lord" Cc: "Linux XFS" , "Eric Sandeen" Date: Tue, 08 Jan 2002 15:17:14 +0100 Reply-To: "Ralf G. R. Bergs" X-Mailer: PMMail 2000 Professional (2.20.2380) For Windows 2000 (5.0.2195;2) In-Reply-To: <3C3AEC30.5090201@sgi.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Subject: "No such file or directory" (still) (was Re: file corruption during emacs build on XFS logical volume Message-Id: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 2087 Lines: 57 Steve, On Tue, 08 Jan 2002 06:55:12 -0600, Stephen Lord wrote: [...] >You are in the 'queue', unfortunately, there are not many hardware raids >accessible around >here for linux development, so duplication of your environment is a >little tricky from this >end I really (REALLY) appreciate all your efforts and the work you're doing -- this goes to the WHOLE team!! Thanks much!! [...] >If you still have the system in this state, could you run xfs_db on the >unmounted filesystem: I wish I still had the system -- the problem is that I wanted to try your "fix" (the "Emacs" fix which I thought could also fix "my" problem,) and since I only have one RAID to play with (the other one is active in production use) I had to reformat the filesystem. :-( But I have a "broken" filesystem again -- I get the infamous "No such file or directory" message again, altho THIS TIME I don't even get a warning from "xfs_repair -n /dev/sdc5." Everything seems fine... :-((( Unfortunately I don't know ANYTHING about the structure of an XFS filesystem. Suppose I have the complete path of a "broken" file (that gives me the "No such file or directory" warning,) could you direct me how to use xfs_db to further narrow down the problem? I've tried understanding the xfs_db manpage but as a layman in XFS structure basics I failed miserably. I've played around with xfs_db a little bit, and received the following output: xfs_db: blockget -n dir 1426370585 block 8388614 extra leaf entry 62b7eea7 2a89 dir ino 1426370585 missing leaf entry for 62bdaea7/2a89 user quota id 232, have/exp bc 0/1 ic 0/1 user quota id 1000, have/exp bc 2521011/2521010 ic 19036/19035 Does this -- as I seem to understand it -- already indicate a problem to you? How would I further investigate it? Thanks, Ralf -- Verkaufe Original-BMW-Raeder: L I N U X .~. http://adsl-bergs.rz.rwth-aachen.de/~rabe The Choice /V\ of a GNU /( )\ Generation ^^-^^ From owner-linux-xfs@oss.sgi.com Tue Jan 8 07:28:52 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g08FSqX07981 for linux-xfs-outgoing; Tue, 8 Jan 2002 07:28:52 -0800 Received: from rover (rover.mkp.net [209.217.122.9]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g08FSmg07959 for ; Tue, 8 Jan 2002 07:28:49 -0800 Received: from localhost.localdomain ([127.0.0.1] helo=rover.mkp.net) by rover with esmtp (Exim 3.33 #1) id 16NxF4-0006Xh-00; Tue, 08 Jan 2002 09:28:42 -0500 Received: (from mkp@localhost) by rover.mkp.net (8.11.6/8.9.3) id g08ESKI01597; Tue, 8 Jan 2002 09:28:20 -0500 X-Authentication-Warning: jaguar.wave.mkp.net: mkp set sender to mkp@mkp.net using -f To: Simon Matter Cc: Stephen Lord , Chris Parrott , linux-xfs@oss.sgi.com Subject: Re: write-caching with XFS References: <3C39DADF.8010700@echostar.com> <1010430010.7120.45.camel@jen.americas.sgi.com> <3C3A9C32.123DA48@ch.sauter-bc.com> <3C3AE709.30701@sgi.com> <3C3AFD1C.BAA09FD7@ch.sauter-bc.com> From: "Martin K. Petersen" Organization: Linuxcare, Inc. Date: 08 Jan 2002 09:28:20 -0500 In-Reply-To: <3C3AFD1C.BAA09FD7@ch.sauter-bc.com> Message-ID: User-Agent: Gnus/5.0808 (Gnus v5.8.8) XEmacs/21.4 (Civil Service) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 541 Lines: 14 >>>>> "Simon" == Simon Matter writes: >> In any case, I think we should remove RAID1 from the caveat. Simon> I'd like so see a comment there that using an external log with Simon> RAID5 is a solution. That can be arranged. I don't think it is mentioned anywhere but in the mailing list archives so it's kind of a public secret. -- Martin K. Petersen, Principal Linux Consultant, Linuxcare, Inc. mkp@linuxcare.com, http://www.linuxcare.com/ SGI XFS for Linux Developer, http://oss.sgi.com/projects/xfs/ From owner-linux-xfs@oss.sgi.com Tue Jan 8 07:37:01 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g08Fb1M08303 for linux-xfs-outgoing; Tue, 8 Jan 2002 07:37:01 -0800 Received: from yog-sothoth.sgi.com (eugate.sgi.com [192.48.160.10]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g08Faqg08276 for ; Tue, 8 Jan 2002 07:36:53 -0800 Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by yog-sothoth.sgi.com (980305.SGI.8.8.8-aspam-6.2/980304.SGI-aspam-europe) via ESMTP id PAA1444677 for ; Tue, 8 Jan 2002 15:34:45 +0100 (CET) mail_from (lord@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id IAA4033145; Tue, 8 Jan 2002 08:35:32 -0600 (CST) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id IAA96390; Tue, 8 Jan 2002 08:35:31 -0600 (CST) Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id g08EYio25209; Tue, 8 Jan 2002 08:34:44 -0600 Subject: Re: "No such file or directory" (still) (was Re: file corruption during emacs build on XFS logical volume From: Steve Lord To: "Ralf G. R. Bergs" Cc: Linux XFS , Eric Sandeen In-Reply-To: References: Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/1.0.0.99+cvs.2001.12.18.08.57 (Preview Release) Date: 08 Jan 2002 08:34:44 -0600 Message-Id: <1010500484.15632.27.camel@jen.americas.sgi.com> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 1099 Lines: 37 On Tue, 2002-01-08 at 08:17, Ralf G. R. Bergs wrote: > > Unfortunately I don't know ANYTHING about the structure of an XFS filesystem. > Suppose I have the complete path of a "broken" file (that gives me the "No > such file or directory" warning,) could you direct me how to use xfs_db to > further narrow down the problem? I've tried understanding the xfs_db manpage > but as a layman in XFS structure basics I failed miserably. I have a hard time understanding xfs_db! > > I've played around with xfs_db a little bit, and received the following > output: > > xfs_db: blockget -n > dir 1426370585 block 8388614 extra leaf entry 62b7eea7 2a89 > dir ino 1426370585 missing leaf entry for 62bdaea7/2a89 > user quota id 232, have/exp bc 0/1 ic 0/1 > user quota id 1000, have/exp bc 2521011/2521010 ic 19036/19035 Can you try the inode 1426370585 p sequence on this fs? It does indeed look like a similar problem to the repair output. Steve -- Steve Lord voice: +1-651-683-3511 Principal Engineer, Filesystem Software email: lord@sgi.com From owner-linux-xfs@oss.sgi.com Tue Jan 8 07:50:51 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g08Fop208662 for linux-xfs-outgoing; Tue, 8 Jan 2002 07:50:51 -0800 Received: from rj.sgi.com (rj.sgi.com [204.94.215.100]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g08Fokg08636 for ; Tue, 8 Jan 2002 07:50:46 -0800 Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by rj.sgi.com (8.11.4/8.11.4/linux-outbound_gateway-1.1) with ESMTP id g08EodY19413 for ; Tue, 8 Jan 2002 06:50:39 -0800 Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id IAA4034761; Tue, 8 Jan 2002 08:49:23 -0600 (CST) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id IAA18914; Tue, 8 Jan 2002 08:49:23 -0600 (CST) Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id g08EmZo25317; Tue, 8 Jan 2002 08:48:35 -0600 Subject: Re: file corruption during emacs build on XFS logical volume From: Steve Lord To: Sean Neakums Cc: Linux XFS In-Reply-To: <6u666dz1kg.fsf@zork.zork.net> References: <1010174871.30053.6.camel@jen.americas.sgi.com> <1010176193.2938.14.camel@UberGeek> <1010176393.30037.9.camel@jen.americas.sgi.com> <1010179700.30053.13.camel@jen.americas.sgi.com> <1010187371.30053.32.camel@jen.americas.sgi.com> <6uy9jdhdsr.fsf@zork.zork.net> <6upu4ph8c5.fsf@zork.zork.net> <3C37511F.6050809@sgi.com> <6uheq0fsu6.fsf@zork.zork.net> <1010429513.7120.35.camel@jen.americas.sgi.com> <1010435724.15632.5.camel@jen.americas.sgi.com> <6u666dz1kg.fsf@zork.zork.net> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/1.0.0.99+cvs.2001.12.18.08.57 (Preview Release) Date: 08 Jan 2002 08:48:35 -0600 Message-Id: <1010501315.25290.0.camel@jen.americas.sgi.com> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 1404 Lines: 35 On Tue, 2002-01-08 at 02:31, Sean Neakums wrote: > begin Steve Lord quotation: > > > On Mon, 2002-01-07 at 12:51, Steve Lord wrote: > >> On Sat, 2002-01-05 at 14:25, Sean Neakums wrote: > >> > begin Stephen Lord quotation: > >> > > OK, thanks, this narrows it down even more than I had - I was > >> > > running a kernel from Dec 22nd and recreating the problem. I had > >> > > tried the individual patches to the I/O path and failed to recreate > >> > > it - but maybe I should try that again. > >> > I just found a kernel from December 8 (I had removed it from > >> > lilo.conf, but forgotten to delete the kernel itself and the modules) > >> > and I cannot recreate on that. > >> Sean, can you see if the attached patch against the current cvs tree > >> fixes the problem for you? So far I have not been able to reproduce > >> with this change. > > > > And here is a patch I prefer you test - since I think this is more like > > a real fix instead of a go back and mask the original problem again > > Steve, I'm afraid I've had to travel unexpectedly this week -- I > won't be back at my XFS box until Friday. I'll test the patch as soon > as I get back Friday. OK, I think I will put the code in and wait to hear back from you on this one. Steve -- Steve Lord voice: +1-651-683-3511 Principal Engineer, Filesystem Software email: lord@sgi.com From owner-linux-xfs@oss.sgi.com Tue Jan 8 07:49:31 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g08FnV708588 for linux-xfs-outgoing; Tue, 8 Jan 2002 07:49:31 -0800 Received: from ADSL-Bergs.RZ.RWTH-Aachen.DE (adsl-bergs.rz.RWTH-Aachen.DE [137.226.80.218]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g08FnGg08562 for ; Tue, 8 Jan 2002 07:49:17 -0800 Received: from [192.168.1.2] (helo=ralf) by ADSL-Bergs.RZ.RWTH-Aachen.DE with smtp (Exim 3.12 #1) id 16NxYk-0003n9-00; Tue, 08 Jan 2002 15:49:02 +0100 From: "Ralf G. R. Bergs" To: "Steve Lord" Cc: "Linux XFS" Date: Tue, 08 Jan 2002 15:49:01 +0100 Reply-To: "Ralf G. R. Bergs" X-Mailer: PMMail 2000 Professional (2.20.2380) For Windows 2000 (5.0.2195;2) In-Reply-To: <1010500484.15632.27.camel@jen.americas.sgi.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Subject: Re: "No such file or directory" (still) (was Re: file corruption during emacs build on XFS logical volume Message-Id: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 2368 Lines: 90 On 08 Jan 2002 08:34:44 -0600, Steve Lord wrote: >On Tue, 2002-01-08 at 08:17, Ralf G. R. Bergs wrote: >> >> Unfortunately I don't know ANYTHING about the structure of an XFS filesystem. >> Suppose I have the complete path of a "broken" file (that gives me the "No >> such file or directory" warning,) could you direct me how to use xfs_db to >> further narrow down the problem? I've tried understanding the xfs_db manpage >> but as a layman in XFS structure basics I failed miserably. > >I have a hard time understanding xfs_db! Well, if even YOU have problems with this... :-) >> I've played around with xfs_db a little bit, and received the following >> output: >> >> xfs_db: blockget -n >> dir 1426370585 block 8388614 extra leaf entry 62b7eea7 2a89 >> dir ino 1426370585 missing leaf entry for 62bdaea7/2a89 >> user quota id 232, have/exp bc 0/1 ic 0/1 >> user quota id 1000, have/exp bc 2521011/2521010 ic 19036/19035 > >Can you try the >inode 1426370585 >p > >sequence on this fs? Sure, here you are: Fileserver:~# xfs_db /dev/sdc5 xfs_db: inode 1426370585 xfs_db: p core.magic = 0x494e core.mode = 040775 core.version = 1 core.format = 3 (btree) core.nlinkv1 = 2 core.uid = 0 core.gid = 71 core.atime.sec = Tue Jan 8 14:40:01 2002 core.atime.nsec = 824812000 core.mtime.sec = Fri Dec 10 12:02:02 1999 core.mtime.nsec = 000000000 core.ctime.sec = Mon Jan 7 21:20:13 2002 core.ctime.nsec = 832196000 core.size = 98304 core.nblocks = 38 core.extsize = 0 core.nextents = 29 core.naextents = 0 core.forkoff = 0 core.aformat = 2 (extents) core.dmevmask = 0 core.dmstate = 0 core.newrtbm = 0 core.prealloc = 0 core.realtime = 0 core.gen = 0 next_unlinked = null u.bmbt.level = 1 u.bmbt.numrecs = 1 u.bmbt.keys[1] = [startoff] 1:[0] u.bmbt.ptrs[1] = 1:89149111 xfs_db: ncheck -i 1426370585 1426370585 daten/[snip]/iGD_8/. This is in fact the directory in which the "damaged" file resides (or is supposed to reside)!! >It does indeed look like a similar problem to the repair output. I sure hope so -- because I'm getting the same error message! Thanks, Ralf -- Verkaufe Original-BMW-Raeder: L I N U X .~. http://adsl-bergs.rz.rwth-aachen.de/~rabe The Choice /V\ of a GNU /( )\ Generation ^^-^^ From owner-linux-xfs@oss.sgi.com Tue Jan 8 08:00:00 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g08G00409043 for linux-xfs-outgoing; Tue, 8 Jan 2002 08:00:00 -0800 Received: from zok.sgi.com (zok.SGI.COM [204.94.215.101]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g08Fxqg09019 for ; Tue, 8 Jan 2002 07:59:52 -0800 Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by zok.sgi.com (8.11.4/8.11.4/linux-outbound_gateway-1.1) with ESMTP id g08ExjA02151 for ; Tue, 8 Jan 2002 06:59:45 -0800 Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id IAA4008637; Tue, 8 Jan 2002 08:58:28 -0600 (CST) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id IAA21083; Tue, 8 Jan 2002 08:58:28 -0600 (CST) Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id g08EveG25344; Tue, 8 Jan 2002 08:57:40 -0600 Subject: Re: "No such file or directory" (still) (was Re: file corruption during emacs build on XFS logical volume From: Steve Lord To: "Ralf G. R. Bergs" Cc: Linux XFS In-Reply-To: References: Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/1.0.0.99+cvs.2001.12.18.08.57 (Preview Release) Date: 08 Jan 2002 08:57:40 -0600 Message-Id: <1010501860.25321.4.camel@jen.americas.sgi.com> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 2853 Lines: 67 OK, so now go into xfs_db again, go back to the same inode and use the bmap command this will print the locations where there are blocks in the directory, it should look a little like this: xfs_db: bmap data offset 0 startblock 196623 (6/15) count 1 flag 0 data offset 1 startblock 196642 (6/34) count 2 flag 0 data offset 3 startblock 196667 (6/59) count 1 flag 0 data offset 4 startblock 196826 (6/218) count 1 flag 0 data offset 5 startblock 196840 (6/232) count 1 flag 0 data offset 6 startblock 196847 (6/239) count 1 flag 0 data offset 7 startblock 196865 (6/257) count 1 flag 0 data offset 8 startblock 196890 (6/282) count 1 flag 0 data offset 9 startblock 196911 (6/303) count 1 flag 0 data offset 10 startblock 196936 (6/328) count 1 flag 0 data offset 11 startblock 196954 (6/346) count 1 flag 0 data offset 12 startblock 196968 (6/360) count 1 flag 0 data offset 13 startblock 196986 (6/378) count 2 flag 0 data offset 15 startblock 197013 (6/405) count 1 flag 0 data offset 16 startblock 197019 (6/411) count 1 flag 0 data offset 17 startblock 197041 (6/433) count 1 flag 0 data offset 18 startblock 197075 (6/467) count 1 flag 0 data offset 19 startblock 197093 (6/485) count 1 flag 0 data offset 20 startblock 197110 (6/502) count 1 flag 0 data offset 21 startblock 197124 (6/516) count 2 flag 0 data offset 23 startblock 197151 (6/543) count 1 flag 0 data offset 24 startblock 197169 (6/561) count 1 flag 0 data offset 8388608 startblock 196629 (6/21) count 1 flag 0 data offset 8388609 startblock 196665 (6/57) count 2 flag 0 data offset 8388611 startblock 196827 (6/219) count 1 flag 0 data offset 8388612 startblock 196841 (6/233) count 1 flag 0 data offset 8388613 startblock 196864 (6/256) count 1 flag 0 data offset 8388614 startblock 196891 (6/283) count 1 flag 0 data offset 8388615 startblock 196937 (6/329) count 1 flag 0 data offset 8388616 startblock 196955 (6/347) count 1 flag 0 data offset 8388617 startblock 196969 (6/361) count 1 flag 0 data offset 8388618 startblock 197012 (6/404) count 1 flag 0 data offset 8388619 startblock 197018 (6/410) count 1 flag 0 data offset 8388620 startblock 197040 (6/432) count 1 flag 0 data offset 8388621 startblock 197050 (6/442) count 1 flag 0 data offset 8388622 startblock 197092 (6/484) count 1 flag 0 data offset 8388623 startblock 197111 (6/503) count 1 flag 0 data offset 8388624 startblock 197150 (6/542) count 1 flag 0 data offset 8388625 startblock 197168 (6/560) count 1 flag 0 data offset 16777216 startblock 196664 (6/56) count 1 flag 0 One of the data offsets will be 8388614 I hope. Use the dblock command on this: dblock 8388614 and then use p to print it. This should be the block it is complaining about. Steve -- Steve Lord voice: +1-651-683-3511 Principal Engineer, Filesystem Software email: lord@sgi.com From owner-linux-xfs@oss.sgi.com Tue Jan 8 08:10:24 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g08GAO009389 for linux-xfs-outgoing; Tue, 8 Jan 2002 08:10:24 -0800 Received: from ADSL-Bergs.RZ.RWTH-Aachen.DE (adsl-bergs.rz.RWTH-Aachen.DE [137.226.80.218]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g08G8ag09324 for ; Tue, 8 Jan 2002 08:08:36 -0800 Received: from [192.168.1.2] (helo=ralf) by ADSL-Bergs.RZ.RWTH-Aachen.DE with smtp (Exim 3.12 #1) id 16NxrX-0003qA-00; Tue, 08 Jan 2002 16:08:28 +0100 From: "Ralf G. R. Bergs" To: "Steve Lord" Cc: "Linux XFS" Date: Tue, 08 Jan 2002 16:08:27 +0100 Reply-To: "Ralf G. R. Bergs" X-Mailer: PMMail 2000 Professional (2.20.2380) For Windows 2000 (5.0.2195;2) In-Reply-To: <1010501860.25321.4.camel@jen.americas.sgi.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Subject: Re: "No such file or directory" (still) (was Re: file corruption during emacs build on XFS logical volume Message-Id: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 30901 Lines: 1022 On Tue, 08 Jan 2002 08:57:40 -0600, Steve Lord wrote: >OK, so now go into xfs_db again, go back to the same inode and >use the bmap command this will print the locations where there >are blocks in the directory, it should look a little like this: Ok, here you are: xfs_db: bmap data offset 0 startblock 89149038 (85/20078) count 1 flag 0 data offset 1 startblock 89149048 (85/20088) count 2 flag 0 data offset 3 startblock 89149071 (85/20111) count 1 flag 0 data offset 4 startblock 89149086 (85/20126) count 1 flag 0 data offset 5 startblock 89149100 (85/20140) count 2 flag 0 data offset 7 startblock 89149124 (85/20164) count 1 flag 0 data offset 8 startblock 89149138 (85/20178) count 2 flag 0 data offset 10 startblock 89149160 (85/20200) count 2 flag 0 data offset 12 startblock 89149182 (85/20222) count 1 flag 0 data offset 13 startblock 89149196 (85/20236) count 2 flag 0 data offset 15 startblock 89149219 (85/20259) count 1 flag 0 data offset 16 startblock 89149225 (85/20265) count 1 flag 0 data offset 17 startblock 89149246 (85/20286) count 1 flag 0 data offset 18 startblock 89149253 (85/20293) count 1 flag 0 data offset 19 startblock 89149270 (85/20310) count 2 flag 0 data offset 21 startblock 89149292 (85/20332) count 2 flag 0 data offset 23 startblock 89149314 (85/20354) count 1 flag 0 data offset 8388608 startblock 89149039 (85/20079) count 1 flag 0 data offset 8388609 startblock 89149072 (85/20112) count 2 flag 0 data offset 8388611 startblock 89149087 (85/20127) count 1 flag 0 data offset 8388612 startblock 89149110 (85/20150) count 1 flag 0 data offset 8388613 startblock 89149125 (85/20165) count 1 flag 0 data offset 8388614 startblock 89149183 (85/20223) count 1 flag 0 data offset 8388615 startblock 89149218 (85/20258) count 1 flag 0 data offset 8388616 startblock 89149224 (85/20264) count 1 flag 0 data offset 8388617 startblock 89149247 (85/20287) count 1 flag 0 data offset 8388618 startblock 89149252 (85/20292) count 1 flag 0 data offset 8388619 startblock 89149315 (85/20355) count 1 flag 0 data offset 16777216 startblock 89149070 (85/20110) count 1 flag 0 >One of the data offsets will be 8388614 I hope. Use the >dblock command on this: > >dblock 8388614 >and then use >p >to print it. Here you are (pretty long output): xfs_db: p lhdr.info.forw = 8388612 lhdr.info.back = 8388610 lhdr.info.magic = 0xd2ff lhdr.count = 475 lhdr.stale = 0 lents[0].hashval = 0x61b1f2a7 lents[0].address = 0x274f lents[1].hashval = 0x61b1f3e0 lents[1].address = 0x883 lents[2].hashval = 0x61b1f6a0 lents[2].address = 0x163b lents[3].hashval = 0x61b1f6a7 lents[3].address = 0x274c lents[4].hashval = 0x61b1f7e0 lents[4].address = 0x880 lents[5].hashval = 0x61b1faa0 lents[5].address = 0x1644 lents[6].hashval = 0x61b1faa7 lents[6].address = 0x2755 lents[7].hashval = 0x61b1fbe0 lents[7].address = 0x889 lents[8].hashval = 0x61b1fea0 lents[8].address = 0x1641 lents[9].hashval = 0x61b1fea7 lents[9].address = 0x2752 lents[10].hashval = 0x61b1ffe0 lents[10].address = 0x886 lents[11].hashval = 0x61b3d2a0 lents[11].address = 0x1638 lents[12].hashval = 0x61b3d2a7 lents[12].address = 0x2749 lents[13].hashval = 0x61b3d3e0 lents[13].address = 0x87d lents[14].hashval = 0x61b3d6a0 lents[14].address = 0x1635 lents[15].hashval = 0x61b3d6a7 lents[15].address = 0x2746 lents[16].hashval = 0x61b3d7e0 lents[16].address = 0x87a lents[17].hashval = 0x61b3e2a0 lents[17].address = 0x162c lents[18].hashval = 0x61b3e2a7 lents[18].address = 0x273d lents[19].hashval = 0x61b3e3e0 lents[19].address = 0x871 lents[20].hashval = 0x61b3e6a0 lents[20].address = 0x1629 lents[21].hashval = 0x61b3e6a7 lents[21].address = 0x273a lents[22].hashval = 0x61b3e7e0 lents[22].address = 0x86e lents[23].hashval = 0x61b3eaa0 lents[23].address = 0x1632 lents[24].hashval = 0x61b3eaa7 lents[24].address = 0x2743 lents[25].hashval = 0x61b3ebe0 lents[25].address = 0x877 lents[26].hashval = 0x61b3eea0 lents[26].address = 0x162f lents[27].hashval = 0x61b3eea7 lents[27].address = 0x2740 lents[28].hashval = 0x61b3efe0 lents[28].address = 0x874 lents[29].hashval = 0x61b3f2a0 lents[29].address = 0x1620 lents[30].hashval = 0x61b3f2a7 lents[30].address = 0x2731 lents[31].hashval = 0x61b3f3e0 lents[31].address = 0x865 lents[32].hashval = 0x61b3f6a0 lents[32].address = 0x161d lents[33].hashval = 0x61b3f6a7 lents[33].address = 0x272e lents[34].hashval = 0x61b3f7e0 lents[34].address = 0x862 lents[35].hashval = 0x61b3faa0 lents[35].address = 0x1626 lents[36].hashval = 0x61b3faa7 lents[36].address = 0x2737 lents[37].hashval = 0x61b3fbe0 lents[37].address = 0x86b lents[38].hashval = 0x61b3fea0 lents[38].address = 0x1623 lents[39].hashval = 0x61b3fea7 lents[39].address = 0x2734 lents[40].hashval = 0x61b3ffe0 lents[40].address = 0x868 lents[41].hashval = 0x61b5d2a0 lents[41].address = 0x161a lents[42].hashval = 0x61b5d2a7 lents[42].address = 0x272b lents[43].hashval = 0x61b5d3e0 lents[43].address = 0x85f lents[44].hashval = 0x61b5d6a0 lents[44].address = 0x1617 lents[45].hashval = 0x61b5d6a7 lents[45].address = 0x2728 lents[46].hashval = 0x61b5d7e0 lents[46].address = 0x85c lents[47].hashval = 0x61b5e2a0 lents[47].address = 0x160e lents[48].hashval = 0x61b5e2a7 lents[48].address = 0x271f lents[49].hashval = 0x61b5e3e0 lents[49].address = 0x853 lents[50].hashval = 0x61b5e6a0 lents[50].address = 0x160b lents[51].hashval = 0x61b5e6a7 lents[51].address = 0x271c lents[52].hashval = 0x61b5e7e0 lents[52].address = 0x850 lents[53].hashval = 0x61b5eaa0 lents[53].address = 0x1614 lents[54].hashval = 0x61b5eaa7 lents[54].address = 0x2725 lents[55].hashval = 0x61b5ebe0 lents[55].address = 0x859 lents[56].hashval = 0x61b5eea0 lents[56].address = 0x1611 lents[57].hashval = 0x61b5eea7 lents[57].address = 0x2722 lents[58].hashval = 0x61b5efe0 lents[58].address = 0x856 lents[59].hashval = 0x61b5f2a0 lents[59].address = 0x1602 lents[60].hashval = 0x61b5f2a7 lents[60].address = 0x2713 lents[61].hashval = 0x61b5f3e0 lents[61].address = 0x847 lents[62].hashval = 0x61b5f6a0 lents[62].address = 0x15fd lents[63].hashval = 0x61b5f6a7 lents[63].address = 0x2710 lents[64].hashval = 0x61b5f7e0 lents[64].address = 0x844 lents[65].hashval = 0x61b5faa0 lents[65].address = 0x1608 lents[66].hashval = 0x61b5faa7 lents[66].address = 0x2719 lents[67].hashval = 0x61b5fbe0 lents[67].address = 0x84d lents[68].hashval = 0x61b5fea0 lents[68].address = 0x1605 lents[69].hashval = 0x61b5fea7 lents[69].address = 0x2716 lents[70].hashval = 0x61b5ffe0 lents[70].address = 0x84a lents[71].hashval = 0x61b7d2a0 lents[71].address = 0x15fa lents[72].hashval = 0x61b7d2a7 lents[72].address = 0x270d lents[73].hashval = 0x61b7d3e0 lents[73].address = 0x841 lents[74].hashval = 0x61b7d6a0 lents[74].address = 0x15f7 lents[75].hashval = 0x61b7d6a7 lents[75].address = 0x270a lents[76].hashval = 0x61b7d7e0 lents[76].address = 0x83e lents[77].hashval = 0x61b7e2a0 lents[77].address = 0x15ee lents[78].hashval = 0x61b7e2a7 lents[78].address = 0x2701 lents[79].hashval = 0x61b7e3e0 lents[79].address = 0x835 lents[80].hashval = 0x61b7e6a0 lents[80].address = 0x15eb lents[81].hashval = 0x61b7e6a7 lents[81].address = 0x26fe lents[82].hashval = 0x61b7e7e0 lents[82].address = 0x832 lents[83].hashval = 0x61b7eaa0 lents[83].address = 0x15f4 lents[84].hashval = 0x61b7eaa7 lents[84].address = 0x2707 lents[85].hashval = 0x61b7ebe0 lents[85].address = 0x83b lents[86].hashval = 0x61b7eea0 lents[86].address = 0x15f1 lents[87].hashval = 0x61b7eea7 lents[87].address = 0x2704 lents[88].hashval = 0x61b7efe0 lents[88].address = 0x838 lents[89].hashval = 0x61b7f2a0 lents[89].address = 0x15e2 lents[90].hashval = 0x61b7f2a7 lents[90].address = 0x26f5 lents[91].hashval = 0x61b7f3e0 lents[91].address = 0x829 lents[92].hashval = 0x61b7f6a0 lents[92].address = 0x15df lents[93].hashval = 0x61b7f6a7 lents[93].address = 0x26f2 lents[94].hashval = 0x61b7f7e0 lents[94].address = 0x826 lents[95].hashval = 0x61b7faa0 lents[95].address = 0x15e8 lents[96].hashval = 0x61b7faa7 lents[96].address = 0x26fb lents[97].hashval = 0x61b7fbe0 lents[97].address = 0x82f lents[98].hashval = 0x61b7fea0 lents[98].address = 0x15e5 lents[99].hashval = 0x61b7fea7 lents[99].address = 0x26f8 lents[100].hashval = 0x61b7ffe0 lents[100].address = 0x82c lents[101].hashval = 0x61b9d2a0 lents[101].address = 0x15dc lents[102].hashval = 0x61b9d2a7 lents[102].address = 0x26ef lents[103].hashval = 0x61b9d3e0 lents[103].address = 0x823 lents[104].hashval = 0x61b9d6a0 lents[104].address = 0x15d9 lents[105].hashval = 0x61b9d6a7 lents[105].address = 0x26ec lents[106].hashval = 0x61b9d7e0 lents[106].address = 0x820 lents[107].hashval = 0x61b9e2a0 lents[107].address = 0x15d0 lents[108].hashval = 0x61b9e2a7 lents[108].address = 0x26e3 lents[109].hashval = 0x61b9e3e0 lents[109].address = 0x817 lents[110].hashval = 0x61b9e6a0 lents[110].address = 0x15cd lents[111].hashval = 0x61b9e6a7 lents[111].address = 0x26e0 lents[112].hashval = 0x61b9e7e0 lents[112].address = 0x814 lents[113].hashval = 0x61b9eaa0 lents[113].address = 0x15d6 lents[114].hashval = 0x61b9eaa7 lents[114].address = 0x26e9 lents[115].hashval = 0x61b9ebe0 lents[115].address = 0x81d lents[116].hashval = 0x61b9eea0 lents[116].address = 0x15d3 lents[117].hashval = 0x61b9eea7 lents[117].address = 0x26e6 lents[118].hashval = 0x61b9efe0 lents[118].address = 0x81a lents[119].hashval = 0x61b9f2a0 lents[119].address = 0x15c4 lents[120].hashval = 0x61b9f2a7 lents[120].address = 0x26d7 lents[121].hashval = 0x61b9f3e0 lents[121].address = 0x80b lents[122].hashval = 0x61b9f6a0 lents[122].address = 0x15c1 lents[123].hashval = 0x61b9f6a7 lents[123].address = 0x26d4 lents[124].hashval = 0x61b9f7e0 lents[124].address = 0x808 lents[125].hashval = 0x61b9faa0 lents[125].address = 0x15ca lents[126].hashval = 0x61b9faa7 lents[126].address = 0x26dd lents[127].hashval = 0x61b9fbe0 lents[127].address = 0x811 lents[128].hashval = 0x61b9fea0 lents[128].address = 0x15c7 lents[129].hashval = 0x61b9fea7 lents[129].address = 0x26da lents[130].hashval = 0x61b9ffe0 lents[130].address = 0x80e lents[131].hashval = 0x61bbd2a0 lents[131].address = 0x15be lents[132].hashval = 0x61bbd2a7 lents[132].address = 0x26d1 lents[133].hashval = 0x61bbd3e0 lents[133].address = 0x805 lents[134].hashval = 0x61bbd6a0 lents[134].address = 0x15bb lents[135].hashval = 0x61bbd6a7 lents[135].address = 0x26ce lents[136].hashval = 0x61bbd7e0 lents[136].address = 0x802 lents[137].hashval = 0x61bbe2a0 lents[137].address = 0x15b2 lents[138].hashval = 0x61bbe2a7 lents[138].address = 0x26c5 lents[139].hashval = 0x61bbe3e0 lents[139].address = 0x7f7 lents[140].hashval = 0x61bbe6a0 lents[140].address = 0x15af lents[141].hashval = 0x61bbe6a7 lents[141].address = 0x26c2 lents[142].hashval = 0x61bbe7e0 lents[142].address = 0x7f4 lents[143].hashval = 0x61bbeaa0 lents[143].address = 0x15b8 lents[144].hashval = 0x61bbeaa7 lents[144].address = 0x26cb lents[145].hashval = 0x61bbebe0 lents[145].address = 0x7fd lents[146].hashval = 0x61bbeea0 lents[146].address = 0x15b5 lents[147].hashval = 0x61bbeea7 lents[147].address = 0x26c8 lents[148].hashval = 0x61bbefe0 lents[148].address = 0x7fa lents[149].hashval = 0x61bbf2a0 lents[149].address = 0x15a6 lents[150].hashval = 0x61bbf2a7 lents[150].address = 0x26b9 lents[151].hashval = 0x61bbf3e0 lents[151].address = 0x7eb lents[152].hashval = 0x61bbf6a0 lents[152].address = 0x15a3 lents[153].hashval = 0x61bbf6a7 lents[153].address = 0x26b6 lents[154].hashval = 0x61bbf7e0 lents[154].address = 0x7e8 lents[155].hashval = 0x61bbfaa0 lents[155].address = 0x15ac lents[156].hashval = 0x61bbfaa7 lents[156].address = 0x26bf lents[157].hashval = 0x61bbfbe0 lents[157].address = 0x7f1 lents[158].hashval = 0x61bbfea0 lents[158].address = 0x15a9 lents[159].hashval = 0x61bbfea7 lents[159].address = 0x26bc lents[160].hashval = 0x61bbffe0 lents[160].address = 0x7ee lents[161].hashval = 0x61bdd2a0 lents[161].address = 0x15a0 lents[162].hashval = 0x61bdd2a7 lents[162].address = 0x26b3 lents[163].hashval = 0x61bdd3e0 lents[163].address = 0x7e5 lents[164].hashval = 0x61bdd6a0 lents[164].address = 0x159d lents[165].hashval = 0x61bdd6a7 lents[165].address = 0x26b0 lents[166].hashval = 0x61bdd7e0 lents[166].address = 0x7e2 lents[167].hashval = 0x61bde2a0 lents[167].address = 0x1594 lents[168].hashval = 0x61bde2a7 lents[168].address = 0x26a7 lents[169].hashval = 0x61bde3e0 lents[169].address = 0x7d9 lents[170].hashval = 0x61bde6a0 lents[170].address = 0x1591 lents[171].hashval = 0x61bde6a7 lents[171].address = 0x26a4 lents[172].hashval = 0x61bde7e0 lents[172].address = 0x7d6 lents[173].hashval = 0x61bdeaa0 lents[173].address = 0x159a lents[174].hashval = 0x61bdeaa7 lents[174].address = 0x26ad lents[175].hashval = 0x61bdebe0 lents[175].address = 0x7df lents[176].hashval = 0x61bdeea0 lents[176].address = 0x1597 lents[177].hashval = 0x61bdeea7 lents[177].address = 0x26aa lents[178].hashval = 0x61bdefe0 lents[178].address = 0x7dc lents[179].hashval = 0x61bdf2a0 lents[179].address = 0x1588 lents[180].hashval = 0x61bdf2a7 lents[180].address = 0x269b lents[181].hashval = 0x61bdf3e0 lents[181].address = 0x7cd lents[182].hashval = 0x61bdf6a0 lents[182].address = 0x1585 lents[183].hashval = 0x61bdf6a7 lents[183].address = 0x2698 lents[184].hashval = 0x61bdf7e0 lents[184].address = 0x7ca lents[185].hashval = 0x61bdfaa0 lents[185].address = 0x158e lents[186].hashval = 0x61bdfaa7 lents[186].address = 0x26a1 lents[187].hashval = 0x61bdfbe0 lents[187].address = 0x7d3 lents[188].hashval = 0x61bdfea0 lents[188].address = 0x158b lents[189].hashval = 0x61bdfea7 lents[189].address = 0x269e lents[190].hashval = 0x61bdffe0 lents[190].address = 0x7d0 lents[191].hashval = 0x61bfd2a0 lents[191].address = 0x1582 lents[192].hashval = 0x61bfd2a7 lents[192].address = 0x2695 lents[193].hashval = 0x61bfd3e0 lents[193].address = 0x7c7 lents[194].hashval = 0x61bfd6a0 lents[194].address = 0x157f lents[195].hashval = 0x61bfd6a7 lents[195].address = 0x2692 lents[196].hashval = 0x61bfd7e0 lents[196].address = 0x7c4 lents[197].hashval = 0x61bfe2a0 lents[197].address = 0x1576 lents[198].hashval = 0x61bfe2a7 lents[198].address = 0x2689 lents[199].hashval = 0x61bfe3e0 lents[199].address = 0x7bb lents[200].hashval = 0x61bfe6a0 lents[200].address = 0x1573 lents[201].hashval = 0x61bfe6a7 lents[201].address = 0x2686 lents[202].hashval = 0x61bfe7e0 lents[202].address = 0x7b8 lents[203].hashval = 0x61bfeaa0 lents[203].address = 0x157c lents[204].hashval = 0x61bfeaa7 lents[204].address = 0x268f lents[205].hashval = 0x61bfebe0 lents[205].address = 0x7c1 lents[206].hashval = 0x61bfeea0 lents[206].address = 0x1579 lents[207].hashval = 0x61bfeea7 lents[207].address = 0x268c lents[208].hashval = 0x61bfefe0 lents[208].address = 0x7be lents[209].hashval = 0x61bff2a0 lents[209].address = 0x156a lents[210].hashval = 0x61bff2a7 lents[210].address = 0x267d lents[211].hashval = 0x61bff3e0 lents[211].address = 0x7af lents[212].hashval = 0x61bff6a0 lents[212].address = 0x1567 lents[213].hashval = 0x61bff6a7 lents[213].address = 0x267a lents[214].hashval = 0x61bff7e0 lents[214].address = 0x7ac lents[215].hashval = 0x61bffaa0 lents[215].address = 0x1570 lents[216].hashval = 0x61bffaa7 lents[216].address = 0x2683 lents[217].hashval = 0x61bffbe0 lents[217].address = 0x7b5 lents[218].hashval = 0x61bffea0 lents[218].address = 0x156d lents[219].hashval = 0x61bffea7 lents[219].address = 0x2680 lents[220].hashval = 0x61bfffe0 lents[220].address = 0x7b2 lents[221].hashval = 0x62add2a0 lents[221].address = 0x1a1a lents[222].hashval = 0x62add2a7 lents[222].address = 0x2b28 lents[223].hashval = 0x62add3e0 lents[223].address = 0xc5c lents[224].hashval = 0x62add6a0 lents[224].address = 0x1a17 lents[225].hashval = 0x62add6a7 lents[225].address = 0x2b25 lents[226].hashval = 0x62add7e0 lents[226].address = 0xc59 lents[227].hashval = 0x62ade2a0 lents[227].address = 0x1a0e lents[228].hashval = 0x62ade2a7 lents[228].address = 0x2b1c lents[229].hashval = 0x62ade3e0 lents[229].address = 0xc50 lents[230].hashval = 0x62ade6a0 lents[230].address = 0x1a0b lents[231].hashval = 0x62ade6a7 lents[231].address = 0x2b19 lents[232].hashval = 0x62ade7e0 lents[232].address = 0xc4d lents[233].hashval = 0x62adeaa0 lents[233].address = 0x1a14 lents[234].hashval = 0x62adeaa7 lents[234].address = 0x2b22 lents[235].hashval = 0x62adebe0 lents[235].address = 0xc56 lents[236].hashval = 0x62adeea0 lents[236].address = 0x1a11 lents[237].hashval = 0x62adeea7 lents[237].address = 0x2b1f lents[238].hashval = 0x62adefe0 lents[238].address = 0xc53 lents[239].hashval = 0x62adf2a0 lents[239].address = 0x1a02 lents[240].hashval = 0x62adf2a7 lents[240].address = 0x2b10 lents[241].hashval = 0x62adf3e0 lents[241].address = 0xc44 lents[242].hashval = 0x62adf6a0 lents[242].address = 0x19fd lents[243].hashval = 0x62adf6a7 lents[243].address = 0x2b0d lents[244].hashval = 0x62adf7e0 lents[244].address = 0xc41 lents[245].hashval = 0x62adfaa0 lents[245].address = 0x1a08 lents[246].hashval = 0x62adfaa7 lents[246].address = 0x2b16 lents[247].hashval = 0x62adfbe0 lents[247].address = 0xc4a lents[248].hashval = 0x62adfea0 lents[248].address = 0x1a05 lents[249].hashval = 0x62adfea7 lents[249].address = 0x2b13 lents[250].hashval = 0x62adffe0 lents[250].address = 0xc47 lents[251].hashval = 0x62afd2a0 lents[251].address = 0x19fa lents[252].hashval = 0x62afd2a7 lents[252].address = 0x2b0a lents[253].hashval = 0x62afd3e0 lents[253].address = 0xc3e lents[254].hashval = 0x62afd6a0 lents[254].address = 0x19f7 lents[255].hashval = 0x62afd6a7 lents[255].address = 0x2b07 lents[256].hashval = 0x62afd7e0 lents[256].address = 0xc3b lents[257].hashval = 0x62afe2a0 lents[257].address = 0x19ee lents[258].hashval = 0x62afe2a7 lents[258].address = 0x2afe lents[259].hashval = 0x62afe3e0 lents[259].address = 0xc32 lents[260].hashval = 0x62afe6a0 lents[260].address = 0x19eb lents[261].hashval = 0x62afe6a7 lents[261].address = 0x2afb lents[262].hashval = 0x62afe7e0 lents[262].address = 0xc2f lents[263].hashval = 0x62afeaa0 lents[263].address = 0x19f4 lents[264].hashval = 0x62afeaa7 lents[264].address = 0x2b04 lents[265].hashval = 0x62afebe0 lents[265].address = 0xc38 lents[266].hashval = 0x62afeea0 lents[266].address = 0x19f1 lents[267].hashval = 0x62afeea7 lents[267].address = 0x2b01 lents[268].hashval = 0x62afefe0 lents[268].address = 0xc35 lents[269].hashval = 0x62aff2a0 lents[269].address = 0x19e2 lents[270].hashval = 0x62aff2a7 lents[270].address = 0x2af2 lents[271].hashval = 0x62aff3e0 lents[271].address = 0xc29 lents[272].hashval = 0x62aff6a0 lents[272].address = 0x19df lents[273].hashval = 0x62aff6a7 lents[273].address = 0x2aef lents[274].hashval = 0x62aff7e0 lents[274].address = 0xc26 lents[275].hashval = 0x62affaa0 lents[275].address = 0x19e8 lents[276].hashval = 0x62affaa7 lents[276].address = 0x2af8 lents[277].hashval = 0x62affea0 lents[277].address = 0x19e5 lents[278].hashval = 0x62affea7 lents[278].address = 0x2af5 lents[279].hashval = 0x62afffe0 lents[279].address = 0xc2c lents[280].hashval = 0x62b1d2a0 lents[280].address = 0x19dc lents[281].hashval = 0x62b1d2a7 lents[281].address = 0x2aec lents[282].hashval = 0x62b1d3e0 lents[282].address = 0xc23 lents[283].hashval = 0x62b1d6a0 lents[283].address = 0x19d9 lents[284].hashval = 0x62b1d6a7 lents[284].address = 0x2ae9 lents[285].hashval = 0x62b1d7e0 lents[285].address = 0xc20 lents[286].hashval = 0x62b1e2a0 lents[286].address = 0x19d0 lents[287].hashval = 0x62b1e2a7 lents[287].address = 0x2ae0 lents[288].hashval = 0x62b1e3e0 lents[288].address = 0xc17 lents[289].hashval = 0x62b1e6a0 lents[289].address = 0x19cd lents[290].hashval = 0x62b1e6a7 lents[290].address = 0x2add lents[291].hashval = 0x62b1e7e0 lents[291].address = 0xc14 lents[292].hashval = 0x62b1eaa0 lents[292].address = 0x19d6 lents[293].hashval = 0x62b1eaa7 lents[293].address = 0x2ae6 lents[294].hashval = 0x62b1ebe0 lents[294].address = 0xc1d lents[295].hashval = 0x62b1eea0 lents[295].address = 0x19d3 lents[296].hashval = 0x62b1eea7 lents[296].address = 0x2ae3 lents[297].hashval = 0x62b1efe0 lents[297].address = 0xc1a lents[298].hashval = 0x62b1f2a0 lents[298].address = 0x19c4 lents[299].hashval = 0x62b1f2a7 lents[299].address = 0x2ad4 lents[300].hashval = 0x62b1f3e0 lents[300].address = 0xc0b lents[301].hashval = 0x62b1f6a0 lents[301].address = 0x19c1 lents[302].hashval = 0x62b1f6a7 lents[302].address = 0x2ad1 lents[303].hashval = 0x62b1f7e0 lents[303].address = 0xc08 lents[304].hashval = 0x62b1faa0 lents[304].address = 0x19ca lents[305].hashval = 0x62b1faa7 lents[305].address = 0x2ada lents[306].hashval = 0x62b1fbe0 lents[306].address = 0xc11 lents[307].hashval = 0x62b1fea0 lents[307].address = 0x19c7 lents[308].hashval = 0x62b1fea7 lents[308].address = 0x2ad7 lents[309].hashval = 0x62b1ffe0 lents[309].address = 0xc0e lents[310].hashval = 0x62b3d2a0 lents[310].address = 0x19be lents[311].hashval = 0x62b3d2a7 lents[311].address = 0x2ace lents[312].hashval = 0x62b3d3e0 lents[312].address = 0xc05 lents[313].hashval = 0x62b3d6a0 lents[313].address = 0x19bb lents[314].hashval = 0x62b3d6a7 lents[314].address = 0x2acb lents[315].hashval = 0x62b3d7e0 lents[315].address = 0xc02 lents[316].hashval = 0x62b3e2a0 lents[316].address = 0x19b2 lents[317].hashval = 0x62b3e2a7 lents[317].address = 0x2ac2 lents[318].hashval = 0x62b3e3e0 lents[318].address = 0xbf7 lents[319].hashval = 0x62b3e6a0 lents[319].address = 0x19af lents[320].hashval = 0x62b3e6a7 lents[320].address = 0x2abf lents[321].hashval = 0x62b3e7e0 lents[321].address = 0xbf4 lents[322].hashval = 0x62b3eaa0 lents[322].address = 0x19b8 lents[323].hashval = 0x62b3eaa7 lents[323].address = 0x2ac8 lents[324].hashval = 0x62b3ebe0 lents[324].address = 0xbfd lents[325].hashval = 0x62b3eea0 lents[325].address = 0x19b5 lents[326].hashval = 0x62b3eea7 lents[326].address = 0x2ac5 lents[327].hashval = 0x62b3efe0 lents[327].address = 0xbfa lents[328].hashval = 0x62b3f2a0 lents[328].address = 0x19a6 lents[329].hashval = 0x62b3f2a7 lents[329].address = 0x2ab6 lents[330].hashval = 0x62b3f3e0 lents[330].address = 0xbeb lents[331].hashval = 0x62b3f6a0 lents[331].address = 0x19a3 lents[332].hashval = 0x62b3f6a7 lents[332].address = 0x2ab3 lents[333].hashval = 0x62b3f7e0 lents[333].address = 0xbe8 lents[334].hashval = 0x62b3faa0 lents[334].address = 0x19ac lents[335].hashval = 0x62b3faa7 lents[335].address = 0x2abc lents[336].hashval = 0x62b3fbe0 lents[336].address = 0xbf1 lents[337].hashval = 0x62b3fea0 lents[337].address = 0x19a9 lents[338].hashval = 0x62b3fea7 lents[338].address = 0x2ab9 lents[339].hashval = 0x62b3ffe0 lents[339].address = 0xbee lents[340].hashval = 0x62b5d2a0 lents[340].address = 0x19a0 lents[341].hashval = 0x62b5d2a7 lents[341].address = 0x2ab0 lents[342].hashval = 0x62b5d3e0 lents[342].address = 0xbe5 lents[343].hashval = 0x62b5d6a0 lents[343].address = 0x199d lents[344].hashval = 0x62b5d6a7 lents[344].address = 0x2aad lents[345].hashval = 0x62b5d7e0 lents[345].address = 0xbe2 lents[346].hashval = 0x62b5e2a0 lents[346].address = 0x1994 lents[347].hashval = 0x62b5e2a7 lents[347].address = 0x2aa4 lents[348].hashval = 0x62b5e3e0 lents[348].address = 0xbd9 lents[349].hashval = 0x62b5e6a0 lents[349].address = 0x1991 lents[350].hashval = 0x62b5e6a7 lents[350].address = 0x2aa1 lents[351].hashval = 0x62b5e7e0 lents[351].address = 0xbd6 lents[352].hashval = 0x62b5eaa0 lents[352].address = 0x199a lents[353].hashval = 0x62b5eaa7 lents[353].address = 0x2aaa lents[354].hashval = 0x62b5ebe0 lents[354].address = 0xbdf lents[355].hashval = 0x62b5eea0 lents[355].address = 0x1997 lents[356].hashval = 0x62b5eea7 lents[356].address = 0x2aa7 lents[357].hashval = 0x62b5efe0 lents[357].address = 0xbdc lents[358].hashval = 0x62b5f2a0 lents[358].address = 0x1988 lents[359].hashval = 0x62b5f2a7 lents[359].address = 0x2a98 lents[360].hashval = 0x62b5f3e0 lents[360].address = 0xbcd lents[361].hashval = 0x62b5f6a0 lents[361].address = 0x1985 lents[362].hashval = 0x62b5f6a7 lents[362].address = 0x2a95 lents[363].hashval = 0x62b5f7e0 lents[363].address = 0xbca lents[364].hashval = 0x62b5faa0 lents[364].address = 0x198e lents[365].hashval = 0x62b5faa7 lents[365].address = 0x2a9e lents[366].hashval = 0x62b5fbe0 lents[366].address = 0xbd3 lents[367].hashval = 0x62b5fea0 lents[367].address = 0x198b lents[368].hashval = 0x62b5fea7 lents[368].address = 0x2a9b lents[369].hashval = 0x62b5ffe0 lents[369].address = 0xbd0 lents[370].hashval = 0x62b7d2a0 lents[370].address = 0x1982 lents[371].hashval = 0x62b7d2a7 lents[371].address = 0x2a92 lents[372].hashval = 0x62b7d3e0 lents[372].address = 0xbc7 lents[373].hashval = 0x62b7d6a0 lents[373].address = 0x197f lents[374].hashval = 0x62b7d6a7 lents[374].address = 0x2a8f lents[375].hashval = 0x62b7d7e0 lents[375].address = 0xbc4 lents[376].hashval = 0x62b7e2a0 lents[376].address = 0x1976 lents[377].hashval = 0x62b7e2a7 lents[377].address = 0x2a86 lents[378].hashval = 0x62b7e3e0 lents[378].address = 0xbbb lents[379].hashval = 0x62b7e6a0 lents[379].address = 0x1973 lents[380].hashval = 0x62b7e6a7 lents[380].address = 0x2a83 lents[381].hashval = 0x62b7e7e0 lents[381].address = 0xbb8 lents[382].hashval = 0x62b7eaa0 lents[382].address = 0x197c lents[383].hashval = 0x62b7eaa7 lents[383].address = 0x2a8c lents[384].hashval = 0x62b7ebe0 lents[384].address = 0xbc1 lents[385].hashval = 0x62b7eea0 lents[385].address = 0x1979 lents[386].hashval = 0x62b7eea7 lents[386].address = 0x2a89 lents[387].hashval = 0x62b7efe0 lents[387].address = 0xbbe lents[388].hashval = 0x62b7f2a0 lents[388].address = 0x196a lents[389].hashval = 0x62b7f2a7 lents[389].address = 0x2a7a lents[390].hashval = 0x62b7f3e0 lents[390].address = 0xbaf lents[391].hashval = 0x62b7f6a0 lents[391].address = 0x1967 lents[392].hashval = 0x62b7f6a7 lents[392].address = 0x2a77 lents[393].hashval = 0x62b7f7e0 lents[393].address = 0xbac lents[394].hashval = 0x62b7faa0 lents[394].address = 0x1970 lents[395].hashval = 0x62b7faa7 lents[395].address = 0x2a80 lents[396].hashval = 0x62b7fbe0 lents[396].address = 0xbb5 lents[397].hashval = 0x62b7fea0 lents[397].address = 0x196d lents[398].hashval = 0x62b7fea7 lents[398].address = 0x2a7d lents[399].hashval = 0x62b7ffe0 lents[399].address = 0xbb2 lents[400].hashval = 0x62b9d2a0 lents[400].address = 0x1964 lents[401].hashval = 0x62b9d2a7 lents[401].address = 0x2a74 lents[402].hashval = 0x62b9d3e0 lents[402].address = 0xba9 lents[403].hashval = 0x62b9d6a0 lents[403].address = 0x1961 lents[404].hashval = 0x62b9d6a7 lents[404].address = 0x2a71 lents[405].hashval = 0x62b9d7e0 lents[405].address = 0xba6 lents[406].hashval = 0x62b9e2a0 lents[406].address = 0x1958 lents[407].hashval = 0x62b9e2a7 lents[407].address = 0x2a68 lents[408].hashval = 0x62b9e3e0 lents[408].address = 0xb9d lents[409].hashval = 0x62b9e6a0 lents[409].address = 0x1955 lents[410].hashval = 0x62b9e6a7 lents[410].address = 0x2a65 lents[411].hashval = 0x62b9e7e0 lents[411].address = 0xb9a lents[412].hashval = 0x62b9eaa0 lents[412].address = 0x195e lents[413].hashval = 0x62b9eaa7 lents[413].address = 0x2a6e lents[414].hashval = 0x62b9ebe0 lents[414].address = 0xba3 lents[415].hashval = 0x62b9eea0 lents[415].address = 0x195b lents[416].hashval = 0x62b9eea7 lents[416].address = 0x2a6b lents[417].hashval = 0x62b9efe0 lents[417].address = 0xba0 lents[418].hashval = 0x62b9f2a0 lents[418].address = 0x194c lents[419].hashval = 0x62b9f2a7 lents[419].address = 0x2a5c lents[420].hashval = 0x62b9f3e0 lents[420].address = 0xb91 lents[421].hashval = 0x62b9f6a0 lents[421].address = 0x1949 lents[422].hashval = 0x62b9f6a7 lents[422].address = 0x2a59 lents[423].hashval = 0x62b9f7e0 lents[423].address = 0xb8e lents[424].hashval = 0x62b9faa0 lents[424].address = 0x1952 lents[425].hashval = 0x62b9faa7 lents[425].address = 0x2a62 lents[426].hashval = 0x62b9fbe0 lents[426].address = 0xb97 lents[427].hashval = 0x62b9fea0 lents[427].address = 0x194f lents[428].hashval = 0x62b9fea7 lents[428].address = 0x2a5f lents[429].hashval = 0x62b9ffe0 lents[429].address = 0xb94 lents[430].hashval = 0x62bbd2a0 lents[430].address = 0x1946 lents[431].hashval = 0x62bbd2a7 lents[431].address = 0x2a56 lents[432].hashval = 0x62bbd3e0 lents[432].address = 0xb8b lents[433].hashval = 0x62bbd6a0 lents[433].address = 0x1943 lents[434].hashval = 0x62bbd6a7 lents[434].address = 0x2a53 lents[435].hashval = 0x62bbd7e0 lents[435].address = 0xb88 lents[436].hashval = 0x62bbe2a0 lents[436].address = 0x193a lents[437].hashval = 0x62bbe2a7 lents[437].address = 0x2a4a lents[438].hashval = 0x62bbe3e0 lents[438].address = 0xb7f lents[439].hashval = 0x62bbe6a0 lents[439].address = 0x1937 lents[440].hashval = 0x62bbe6a7 lents[440].address = 0x2a47 lents[441].hashval = 0x62bbe7e0 lents[441].address = 0xb7c lents[442].hashval = 0x62bbeaa0 lents[442].address = 0x1940 lents[443].hashval = 0x62bbeaa7 lents[443].address = 0x2a50 lents[444].hashval = 0x62bbebe0 lents[444].address = 0xb85 lents[445].hashval = 0x62bbeea0 lents[445].address = 0x193d lents[446].hashval = 0x62bbeea7 lents[446].address = 0x2a4d lents[447].hashval = 0x62bbefe0 lents[447].address = 0xb82 lents[448].hashval = 0x62bbf2a0 lents[448].address = 0x192e lents[449].hashval = 0x62bbf2a7 lents[449].address = 0x2a3e lents[450].hashval = 0x62bbf3e0 lents[450].address = 0xb73 lents[451].hashval = 0x62bbf6a0 lents[451].address = 0x192b lents[452].hashval = 0x62bbf6a7 lents[452].address = 0x2a3b lents[453].hashval = 0x62bbf7e0 lents[453].address = 0xb70 lents[454].hashval = 0x62bbfaa0 lents[454].address = 0x1934 lents[455].hashval = 0x62bbfaa7 lents[455].address = 0x2a44 lents[456].hashval = 0x62bbfbe0 lents[456].address = 0xb79 lents[457].hashval = 0x62bbfea0 lents[457].address = 0x1931 lents[458].hashval = 0x62bbfea7 lents[458].address = 0x2a41 lents[459].hashval = 0x62bbffe0 lents[459].address = 0xb76 lents[460].hashval = 0x62bdd2a0 lents[460].address = 0x1928 lents[461].hashval = 0x62bdd2a7 lents[461].address = 0x2a38 lents[462].hashval = 0x62bdd3e0 lents[462].address = 0xb6d lents[463].hashval = 0x62bdd6a0 lents[463].address = 0x1925 lents[464].hashval = 0x62bdd6a7 lents[464].address = 0x2a35 lents[465].hashval = 0x62bdd7e0 lents[465].address = 0xb6a lents[466].hashval = 0x62bde2a0 lents[466].address = 0x191c lents[467].hashval = 0x62bde2a7 lents[467].address = 0x2a2c lents[468].hashval = 0x62bde3e0 lents[468].address = 0xb61 lents[469].hashval = 0x62bde6a0 lents[469].address = 0x1919 lents[470].hashval = 0x62bde6a7 lents[470].address = 0x2a29 lents[471].hashval = 0x62bde7e0 lents[471].address = 0xb5e lents[472].hashval = 0x62bdeaa0 lents[472].address = 0x1922 lents[473].hashval = 0x62bdeaa7 lents[473].address = 0x2a32 lents[474].hashval = 0x62bdebe0 lents[474].address = 0xb67 >This should be the block it is complaining about. Ok, what do you want me to do now? Thanks, Ralf -- Verkaufe Original-BMW-Raeder: L I N U X .~. http://adsl-bergs.rz.rwth-aachen.de/~rabe The Choice /V\ of a GNU /( )\ Generation ^^-^^ From owner-linux-xfs@oss.sgi.com Tue Jan 8 08:22:03 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g08GM3I09821 for linux-xfs-outgoing; Tue, 8 Jan 2002 08:22:03 -0800 Received: from goliath.sylaba.poznan.pl (root@goliath.sylaba.poznan.pl [195.216.104.3]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g08GLtg09775 for ; Tue, 8 Jan 2002 08:21:57 -0800 Received: from venus.local.navi.pl (ps103.poznan.sdi.tpnet.pl [217.97.72.103]) by goliath.sylaba.poznan.pl (8.11.6/8.10.1) with ESMTP id g08FLob16785 for ; Tue, 8 Jan 2002 16:21:50 +0100 (CET) Received: from venus.local.navi.pl (venus [192.168.1.10]) by venus.local.navi.pl (8.11.6/8.9.3) with ESMTP id g08FHuP02322 for ; Tue, 8 Jan 2002 16:17:56 +0100 Date: Tue, 8 Jan 2002 16:17:56 +0100 From: Olaf =?iso-8859-2?Q?Fr=B1czyk?= To: linux-xfs@oss.sgi.com Subject: vmware+XFS+duron+viakt133 - works? Message-ID: <20020108161756.A2191@venus.local.navi.pl> Mime-Version: 1.0 Content-Type: text/plain; format=flowed; charset=ISO-8859-2 Content-Transfer-Encoding: 8bit X-Mailer: Balsa 1.2.3 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 561 Lines: 15 Hi, I changed my motherboard (I had Abit BP6 -BX440 chipset with Celeron) to Asus A7V-133 (kt133A) with Duron 1000, and I have crashes with VMware. Also checked A7V (kt133) with Duron 700. The system is stable. On abit with celeron I had no problems. I tried kernels 2.4.5 and 2.4.17, both with XFS compiled in. Does somebody has similar configuration? I took a look at vmware newsgroup, but didn't find complaints about duron and via chipsets, so I think, it may be problem with modifications to kernel introduced by XFS support. Regards, Olaf Fraczyk From owner-linux-xfs@oss.sgi.com Tue Jan 8 08:22:04 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g08GM4I09835 for linux-xfs-outgoing; Tue, 8 Jan 2002 08:22:04 -0800 Received: from sgi.com (sgi-too.SGI.COM [204.94.211.39]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g08GLvg09778 for ; Tue, 8 Jan 2002 08:21:57 -0800 Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id HAA06063 for ; Tue, 8 Jan 2002 07:19:50 -0800 (PST) mail_from (lord@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id JAA4035612; Tue, 8 Jan 2002 09:20:38 -0600 (CST) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id JAA17587; Tue, 8 Jan 2002 09:20:38 -0600 (CST) Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id g08FJoI25423; Tue, 8 Jan 2002 09:19:50 -0600 Subject: Re: "No such file or directory" (still) (was Re: file corruption during emacs build on XFS logical volume From: Steve Lord To: "Ralf G. R. Bergs" Cc: Linux XFS In-Reply-To: References: Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/1.0.0.99+cvs.2001.12.18.08.57 (Preview Release) Date: 08 Jan 2002 09:19:50 -0600 Message-Id: <1010503190.25290.12.camel@jen.americas.sgi.com> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 1444 Lines: 50 On Tue, 2002-01-08 at 09:08, Ralf G. R. Bergs wrote: > On Tue, 08 Jan 2002 08:57:40 -0600, Steve Lord wrote: > > >OK, so now go into xfs_db again, go back to the same inode and > >use the bmap command this will print the locations where there > >are blocks in the directory, it should look a little like this: > > Ok, here you are: > ........ > > Ok, what do you want me to do now? > > Thanks, > > Ralf > I think I am starting to get the picture here. The blocks we are looking at here are hash values used to lookup the individual blocks containing the name/inode pairs. A directory search generates a hash from the name and then walks down to the leaf block of the btree which contains it, from here we get an address - which I think is in 8 byte chunks into the start of the directory. This output: dir 1426370585 block 8388614 extra leaf entry 62b7eea7 2a89 dir ino 1426370585 missing leaf entry for 62bdaea7/2a89 Reports that there is a leaf entry 62b7eea7 which has no inode in the directory, and there is an inode with no hash value. They are both at offset 0x2a89. If we multiply this by 8 we get 87112 decimal which should be in block 21 of the directory. If you go back to the inode and do dblock 21 p what do you get, and is your missing name in the output 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 Jan 8 08:30:16 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g08GUG010191 for linux-xfs-outgoing; Tue, 8 Jan 2002 08:30:16 -0800 Received: from ahriman.bucharest.roedu.net (ahriman.bucharest.roedu.net [141.85.128.71]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g08GUAg10162 for ; Tue, 8 Jan 2002 08:30:10 -0800 Received: (qmail 24227 invoked by uid 1000); 8 Jan 2002 15:34:08 -0000 Received: from localhost (sendmail-bs@127.0.0.1) by localhost with SMTP; 8 Jan 2002 15:34:08 -0000 Date: Tue, 8 Jan 2002 17:34:08 +0200 (EET) From: Mihai RUSU X-X-Sender: To: Olaf =?iso-8859-2?Q?Fr=B1czyk?= cc: Subject: Re: vmware+XFS+duron+viakt133 - works? In-Reply-To: <20020108161756.A2191@venus.local.navi.pl> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-2 Content-Transfer-Encoding: 8BIT Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 823 Lines: 29 Hi first you should try a kernel without XFS, better a similar version with the ones with XFS you tried On Tue, 8 Jan 2002, Olaf Fr±czyk wrote: > Hi, > I changed my motherboard (I had Abit BP6 -BX440 chipset with Celeron) to > Asus A7V-133 (kt133A) with Duron 1000, and I have crashes with VMware. > Also checked A7V (kt133) with Duron 700. The system is stable. > On abit with celeron I had no problems. > I tried kernels 2.4.5 and 2.4.17, both with XFS compiled in. > Does somebody has similar configuration? > I took a look at vmware newsgroup, but didn't find complaints about duron > and via chipsets, so I think, it may be problem with modifications to > kernel introduced by XFS support. > > > Regards, > > Olaf Fraczyk > > ---------------------------- Mihai RUSU "... and what if this is as good as it gets ?" From owner-linux-xfs@oss.sgi.com Tue Jan 8 08:36:20 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g08GaKG10414 for linux-xfs-outgoing; Tue, 8 Jan 2002 08:36:20 -0800 Received: from ADSL-Bergs.RZ.RWTH-Aachen.DE (adsl-bergs.rz.RWTH-Aachen.DE [137.226.80.218]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g08GZ2g10386 for ; Tue, 8 Jan 2002 08:35:03 -0800 Received: from [192.168.1.2] (helo=ralf) by ADSL-Bergs.RZ.RWTH-Aachen.DE with smtp (Exim 3.12 #1) id 16NyH9-0003tG-00; Tue, 08 Jan 2002 16:34:55 +0100 From: "Ralf G. R. Bergs" To: "Steve Lord" Cc: "Linux XFS" Date: Tue, 08 Jan 2002 16:34:54 +0100 Reply-To: "Ralf G. R. Bergs" X-Mailer: PMMail 2000 Professional (2.20.2380) For Windows 2000 (5.0.2195;2) In-Reply-To: <1010503190.25290.12.camel@jen.americas.sgi.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Subject: Re: "No such file or directory" (still) (was Re: file corruption during emacs build on XFS logical volume Message-Id: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 18248 Lines: 743 On Tue, 08 Jan 2002 09:19:50 -0600, Steve Lord wrote: [...] >I think I am starting to get the picture here. The blocks we are looking You make a happy man out of me... :-) >at here are hash values used to lookup the individual blocks containing >the name/inode pairs. A directory search generates a hash from the name >and then walks down to the leaf block of the btree which contains it, Up to here I can still (mostly) follow you... >from here we get an address - which I think is in 8 byte chunks into the >start of the directory. > >This output: > >dir 1426370585 block 8388614 extra leaf entry 62b7eea7 2a89 >dir ino 1426370585 missing leaf entry for 62bdaea7/2a89 > >Reports that there is a leaf entry 62b7eea7 which has no inode >in the directory, and there is an inode with no hash value. They I see. >are both at offset 0x2a89. If we multiply this by 8 we get 87112 >decimal which should be in block 21 of the directory. If you go >back to the inode and do > > dblock 21 > p > >what do you get, and is your missing name in the output here? xfs_db: dblock 21 xfs_db: p dhdr.magic = 0x58443244 dhdr.bestfree[0].offset = 0 dhdr.bestfree[0].length = 0 dhdr.bestfree[1].offset = 0 dhdr.bestfree[1].length = 0 dhdr.bestfree[2].offset = 0 dhdr.bestfree[2].length = 0 du[0].inumber = 1426388650 du[0].namelen = 12 du[0].name = "069701IM.drw" du[0].tag = 0x10 du[1].inumber = 1426388651 du[1].namelen = 12 du[1].name = "069702IM.drw" du[1].tag = 0x28 du[2].inumber = 1426388652 du[2].namelen = 12 du[2].name = "069703IM.drw" du[2].tag = 0x40 du[3].inumber = 1426388653 du[3].namelen = 12 du[3].name = "069704IM.drw" du[3].tag = 0x58 du[4].inumber = 1426388654 du[4].namelen = 12 du[4].name = "069705IM.drw" du[4].tag = 0x70 du[5].inumber = 1426388655 du[5].namelen = 12 du[5].name = "069706IM.drw" du[5].tag = 0x88 du[6].inumber = 1426388656 du[6].namelen = 12 du[6].name = "069707IM.drw" du[6].tag = 0xa0 du[7].inumber = 1426388657 du[7].namelen = 12 du[7].name = "069708IM.drw" du[7].tag = 0xb8 du[8].inumber = 1426388658 du[8].namelen = 12 du[8].name = "069709IM.drw" du[8].tag = 0xd0 du[9].inumber = 1426388659 du[9].namelen = 12 du[9].name = "069710IM.drw" du[9].tag = 0xe8 du[10].inumber = 1426388660 du[10].namelen = 12 du[10].name = "069711IM.drw" du[10].tag = 0x100 du[11].inumber = 1426388661 du[11].namelen = 12 du[11].name = "069712IM.drw" du[11].tag = 0x118 du[12].inumber = 1426388662 du[12].namelen = 12 du[12].name = "069713IM.drw" du[12].tag = 0x130 du[13].inumber = 1426388663 du[13].namelen = 12 du[13].name = "069714IM.drw" du[13].tag = 0x148 du[14].inumber = 1426388664 du[14].namelen = 12 du[14].name = "069715IM.drw" du[14].tag = 0x160 du[15].inumber = 1426388665 du[15].namelen = 12 du[15].name = "069716IM.drw" du[15].tag = 0x178 du[16].inumber = 1426388666 du[16].namelen = 12 du[16].name = "069717IM.drw" du[16].tag = 0x190 du[17].inumber = 1426388667 du[17].namelen = 12 du[17].name = "069718IM.drw" du[17].tag = 0x1a8 du[18].inumber = 1426388668 du[18].namelen = 12 du[18].name = "069719IM.drw" du[18].tag = 0x1c0 du[19].inumber = 1426388669 du[19].namelen = 12 du[19].name = "069720IM.drw" du[19].tag = 0x1d8 du[20].inumber = 1426388670 du[20].namelen = 12 du[20].name = "069721IM.drw" du[20].tag = 0x1f0 du[21].inumber = 1426388671 du[21].namelen = 12 du[21].name = "069722IM.drw" du[21].tag = 0x208 du[22].inumber = 1426388704 du[22].namelen = 12 du[22].name = "069723IM.drw" du[22].tag = 0x220 du[23].inumber = 1426388705 du[23].namelen = 12 du[23].name = "069724IM.drw" du[23].tag = 0x238 du[24].inumber = 1426388706 du[24].namelen = 12 du[24].name = "069725IM.drw" du[24].tag = 0x250 du[25].inumber = 1426388707 du[25].namelen = 12 du[25].name = "069726IM.drw" du[25].tag = 0x268 du[26].inumber = 1426388708 du[26].namelen = 12 du[26].name = "069727IM.drw" du[26].tag = 0x280 du[27].inumber = 1426388709 du[27].namelen = 12 du[27].name = "069728IM.drw" du[27].tag = 0x298 du[28].inumber = 1426388710 du[28].namelen = 12 du[28].name = "069729IM.drw" du[28].tag = 0x2b0 du[29].inumber = 1426388711 du[29].namelen = 12 du[29].name = "069730IM.drw" du[29].tag = 0x2c8 du[30].inumber = 1426388712 du[30].namelen = 12 du[30].name = "069731IM.drw" du[30].tag = 0x2e0 du[31].inumber = 1426388713 du[31].namelen = 12 du[31].name = "069732IM.drw" du[31].tag = 0x2f8 du[32].inumber = 1426388714 du[32].namelen = 12 du[32].name = "069733IM.drw" du[32].tag = 0x310 du[33].inumber = 1426388715 du[33].namelen = 12 du[33].name = "069734IM.drw" du[33].tag = 0x328 du[34].inumber = 1426388716 du[34].namelen = 12 du[34].name = "069735IM.drw" du[34].tag = 0x340 du[35].inumber = 1426388717 du[35].namelen = 12 du[35].name = "069736IM.drw" du[35].tag = 0x358 du[36].inumber = 1426388718 du[36].namelen = 12 du[36].name = "069737IM.drw" du[36].tag = 0x370 du[37].inumber = 1426388719 du[37].namelen = 12 du[37].name = "069738IM.drw" du[37].tag = 0x388 du[38].inumber = 1426388720 du[38].namelen = 12 du[38].name = "069739IM.drw" du[38].tag = 0x3a0 du[39].inumber = 1426388721 du[39].namelen = 12 du[39].name = "069740IM.drw" du[39].tag = 0x3b8 du[40].inumber = 1426388722 du[40].namelen = 12 du[40].name = "069741IM.drw" du[40].tag = 0x3d0 du[41].inumber = 1426388723 du[41].namelen = 12 du[41].name = "069742IM.drw" du[41].tag = 0x3e8 du[42].inumber = 1426388724 du[42].namelen = 12 du[42].name = "069743IM.drw" du[42].tag = 0x400 du[43].inumber = 1426388725 du[43].namelen = 12 du[43].name = "069744IM.drw" du[43].tag = 0x418 du[44].inumber = 1426388726 du[44].namelen = 12 du[44].name = "069745IM.drw" du[44].tag = 0x430 du[45].inumber = 1426388727 du[45].namelen = 12 du[45].name = "069746IM.Mrw" du[45].tag = 0x448 du[46].inumber = 1426388728 du[46].namelen = 12 du[46].name = "069747IM.drw" du[46].tag = 0x460 du[47].inumber = 1426388729 du[47].namelen = 12 du[47].name = "069748IM.drw" du[47].tag = 0x478 du[48].inumber = 1426388730 du[48].namelen = 12 du[48].name = "069749IM.drw" du[48].tag = 0x490 du[49].inumber = 1426388731 du[49].namelen = 12 du[49].name = "069750IM.drw" du[49].tag = 0x4a8 du[50].inumber = 1426388732 du[50].namelen = 12 du[50].name = "069751IM.drw" du[50].tag = 0x4c0 du[51].inumber = 1426388733 du[51].namelen = 12 du[51].name = "069752IM.drw" du[51].tag = 0x4d8 du[52].inumber = 1426388734 du[52].namelen = 12 du[52].name = "069753IM.drw" du[52].tag = 0x4f0 du[53].inumber = 1426388735 du[53].namelen = 12 du[53].name = "069754IM.drw" du[53].tag = 0x508 du[54].inumber = 1426388736 du[54].namelen = 12 du[54].name = "069755IM.drw" du[54].tag = 0x520 du[55].inumber = 1426388737 du[55].namelen = 12 du[55].name = "069756IM.drw" du[55].tag = 0x538 du[56].inumber = 1426388738 du[56].namelen = 12 du[56].name = "069757IM.drw" du[56].tag = 0x550 du[57].inumber = 1426388739 du[57].namelen = 12 du[57].name = "069758IM.drw" du[57].tag = 0x568 du[58].inumber = 1426388740 du[58].namelen = 12 du[58].name = "069759IM.drw" du[58].tag = 0x580 du[59].inumber = 1426388741 du[59].namelen = 12 du[59].name = "069760IM.drw" du[59].tag = 0x598 du[60].inumber = 1426388742 du[60].namelen = 12 du[60].name = "069761IM.drw" du[60].tag = 0x5b0 du[61].inumber = 1426388743 du[61].namelen = 12 du[61].name = "069762IM.drw" du[61].tag = 0x5c8 du[62].inumber = 1426388744 du[62].namelen = 12 du[62].name = "069763IM.drw" du[62].tag = 0x5e0 du[63].inumber = 1426388745 du[63].namelen = 12 du[63].name = "069764IM.drw" du[63].tag = 0x5f8 du[64].inumber = 1426388746 du[64].namelen = 12 du[64].name = "069765IM.drw" du[64].tag = 0x610 du[65].inumber = 1426388747 du[65].namelen = 12 du[65].name = "069766IM.drw" du[65].tag = 0x628 du[66].inumber = 1426388748 du[66].namelen = 12 du[66].name = "069767IM.drw" du[66].tag = 0x640 du[67].inumber = 1426388749 du[67].namelen = 12 du[67].name = "069768IM.drw" du[67].tag = 0x658 du[68].inumber = 1426388750 du[68].namelen = 12 du[68].name = "069769IM.drw" du[68].tag = 0x670 du[69].inumber = 1426388751 du[69].namelen = 12 du[69].name = "069770IM.drw" du[69].tag = 0x688 du[70].inumber = 1426388752 du[70].namelen = 12 du[70].name = "069771IM.drw" du[70].tag = 0x6a0 du[71].inumber = 1426388753 du[71].namelen = 12 du[71].name = "069772IM.drw" du[71].tag = 0x6b8 du[72].inumber = 1426388754 du[72].namelen = 12 du[72].name = "069773IM.drw" du[72].tag = 0x6d0 du[73].inumber = 1426388755 du[73].namelen = 12 du[73].name = "069774IM.drw" du[73].tag = 0x6e8 du[74].inumber = 1426388756 du[74].namelen = 12 du[74].name = "069775IM.drw" du[74].tag = 0x700 du[75].inumber = 1426388757 du[75].namelen = 12 du[75].name = "069776IM.drw" du[75].tag = 0x718 du[76].inumber = 1426388758 du[76].namelen = 12 du[76].name = "069777IM.drw" du[76].tag = 0x730 du[77].inumber = 1426388759 du[77].namelen = 12 du[77].name = "069778IM.drw" du[77].tag = 0x748 du[78].inumber = 1426388760 du[78].namelen = 12 du[78].name = "069779IM.drw" du[78].tag = 0x760 du[79].inumber = 1426388761 du[79].namelen = 12 du[79].name = "069780IM.drw" du[79].tag = 0x778 du[80].inumber = 1426388762 du[80].namelen = 12 du[80].name = "069781IM.drw" du[80].tag = 0x790 du[81].inumber = 1426388763 du[81].namelen = 12 du[81].name = "069782IM.drw" du[81].tag = 0x7a8 du[82].inumber = 1426388764 du[82].namelen = 12 du[82].name = "069783IM.drw" du[82].tag = 0x7c0 du[83].inumber = 1426388765 du[83].namelen = 12 du[83].name = "069784IM.drw" du[83].tag = 0x7d8 du[84].inumber = 1426388766 du[84].namelen = 12 du[84].name = "069785IM.drw" du[84].tag = 0x7f0 du[85].inumber = 1426388767 du[85].namelen = 12 du[85].name = "069786IM.drw" du[85].tag = 0x808 du[86].inumber = 1426388768 du[86].namelen = 12 du[86].name = "069787IM.drw" du[86].tag = 0x820 du[87].inumber = 1426388769 du[87].namelen = 12 du[87].name = "069788IM.drw" du[87].tag = 0x838 du[88].inumber = 1426388770 du[88].namelen = 12 du[88].name = "069789IM.drw" du[88].tag = 0x850 du[89].inumber = 1426388771 du[89].namelen = 12 du[89].name = "069790IM.drw" du[89].tag = 0x868 du[90].inumber = 1426388772 du[90].namelen = 12 du[90].name = "069791IM.drw" du[90].tag = 0x880 du[91].inumber = 1426388773 du[91].namelen = 12 du[91].name = "069792IM.drw" du[91].tag = 0x898 du[92].inumber = 1426388774 du[92].namelen = 12 du[92].name = "069793IM.drw" du[92].tag = 0x8b0 du[93].inumber = 1426388775 du[93].namelen = 12 du[93].name = "069794IM.drw" du[93].tag = 0x8c8 du[94].inumber = 1426388776 du[94].namelen = 12 du[94].name = "069795IM.drw" du[94].tag = 0x8e0 du[95].inumber = 1426388777 du[95].namelen = 12 du[95].name = "069796IM.drw" du[95].tag = 0x8f8 du[96].inumber = 1426388778 du[96].namelen = 12 du[96].name = "069797IM.drw" du[96].tag = 0x910 du[97].inumber = 1426388779 du[97].namelen = 12 du[97].name = "069798IM.drw" du[97].tag = 0x928 du[98].inumber = 1426388780 du[98].namelen = 12 du[98].name = "069799IM.drw" du[98].tag = 0x940 du[99].inumber = 1426388781 du[99].namelen = 12 du[99].name = "069800IM.drw" du[99].tag = 0x958 du[100].inumber = 1426388782 du[100].namelen = 12 du[100].name = "069801IM.drw" du[100].tag = 0x970 du[101].inumber = 1426388783 du[101].namelen = 12 du[101].name = "069802IM.drw" du[101].tag = 0x988 du[102].inumber = 1426388784 du[102].namelen = 12 du[102].name = "069803IM.drw" du[102].tag = 0x9a0 du[103].inumber = 1426388785 du[103].namelen = 12 du[103].name = "069804IM.drw" du[103].tag = 0x9b8 du[104].inumber = 1426388786 du[104].namelen = 12 du[104].name = "069805IM.drw" du[104].tag = 0x9d0 du[105].inumber = 1426388787 du[105].namelen = 12 du[105].name = "069806IM.drw" du[105].tag = 0x9e8 du[106].inumber = 1426388788 du[106].namelen = 12 du[106].name = "069807IM.drw" du[106].tag = 0xa00 du[107].inumber = 1426388789 du[107].namelen = 12 du[107].name = "069808IM.drw" du[107].tag = 0xa18 du[108].inumber = 1426388790 du[108].namelen = 12 du[108].name = "069809IM.drw" du[108].tag = 0xa30 du[109].inumber = 1426388791 du[109].namelen = 12 du[109].name = "069810IM.drw" du[109].tag = 0xa48 du[110].inumber = 1426388792 du[110].namelen = 12 du[110].name = "069811IM.drw" du[110].tag = 0xa60 du[111].inumber = 1426388793 du[111].namelen = 12 du[111].name = "069812IM.drw" du[111].tag = 0xa78 du[112].inumber = 1426388794 du[112].namelen = 12 du[112].name = "069813IM.drw" du[112].tag = 0xa90 du[113].inumber = 1426388795 du[113].namelen = 12 du[113].name = "069814IM.drw" du[113].tag = 0xaa8 du[114].inumber = 1426388796 du[114].namelen = 12 du[114].name = "069815IM.drw" du[114].tag = 0xac0 du[115].inumber = 1426388797 du[115].namelen = 12 du[115].name = "069816IM.drw" du[115].tag = 0xad8 du[116].inumber = 1426388798 du[116].namelen = 12 du[116].name = "069817IM.drw" du[116].tag = 0xaf0 du[117].inumber = 1426388799 du[117].namelen = 12 du[117].name = "069818IM.drw" du[117].tag = 0xb08 du[118].inumber = 1426388800 du[118].namelen = 12 du[118].name = "069819IM.drw" du[118].tag = 0xb20 du[119].inumber = 1426388801 du[119].namelen = 12 du[119].name = "069820IM.drw" du[119].tag = 0xb38 du[120].inumber = 1426388802 du[120].namelen = 12 du[120].name = "069821IM.drw" du[120].tag = 0xb50 du[121].inumber = 1426388803 du[121].namelen = 12 du[121].name = "069822IM.drw" du[121].tag = 0xb68 du[122].inumber = 1426388804 du[122].namelen = 12 du[122].name = "069823IM.drw" du[122].tag = 0xb80 du[123].inumber = 1426388805 du[123].namelen = 12 du[123].name = "069824IM.drw" du[123].tag = 0xb98 du[124].inumber = 1426388806 du[124].namelen = 12 du[124].name = "069825IM.drw" du[124].tag = 0xbb0 du[125].inumber = 1426388807 du[125].namelen = 12 du[125].name = "069826IM.drw" du[125].tag = 0xbc8 du[126].inumber = 1426388808 du[126].namelen = 12 du[126].name = "069827IM.drw" du[126].tag = 0xbe0 du[127].inumber = 1426388809 du[127].namelen = 12 du[127].name = "069828IM.drw" du[127].tag = 0xbf8 du[128].inumber = 1426388810 du[128].namelen = 12 du[128].name = "069829IM.drw" du[128].tag = 0xc10 du[129].inumber = 1426388811 du[129].namelen = 12 du[129].name = "069830IM.drw" du[129].tag = 0xc28 du[130].inumber = 1426388812 du[130].namelen = 12 du[130].name = "069831IM.drw" du[130].tag = 0xc40 du[131].inumber = 1426388813 du[131].namelen = 12 du[131].name = "069832IM.drw" du[131].tag = 0xc58 du[132].inumber = 1426388814 du[132].namelen = 12 du[132].name = "069833IM.drw" du[132].tag = 0xc70 du[133].inumber = 1426388815 du[133].namelen = 12 du[133].name = "069834IM.drw" du[133].tag = 0xc88 du[134].inumber = 1426388816 du[134].namelen = 12 du[134].name = "069835IM.drw" du[134].tag = 0xca0 du[135].inumber = 1426388817 du[135].namelen = 12 du[135].name = "069836IM.drw" du[135].tag = 0xcb8 du[136].inumber = 1426388818 du[136].namelen = 12 du[136].name = "069837IM.drw" du[136].tag = 0xcd0 du[137].inumber = 1426388819 du[137].namelen = 12 du[137].name = "069838IM.drw" du[137].tag = 0xce8 du[138].inumber = 1426388820 du[138].namelen = 12 du[138].name = "069839IM.drw" du[138].tag = 0xd00 du[139].inumber = 1426388821 du[139].namelen = 12 du[139].name = "069840IM.drw" du[139].tag = 0xd18 du[140].inumber = 1426388822 du[140].namelen = 12 du[140].name = "069841IM.drw" du[140].tag = 0xd30 du[141].inumber = 1426388823 du[141].namelen = 12 du[141].name = "069842IM.drw" du[141].tag = 0xd48 du[142].inumber = 1426388824 du[142].namelen = 12 du[142].name = "069843IM.drw" du[142].tag = 0xd60 du[143].inumber = 1426388825 du[143].namelen = 12 du[143].name = "069844IM.drw" du[143].tag = 0xd78 du[144].inumber = 1426388826 du[144].namelen = 12 du[144].name = "069845IM.drw" du[144].tag = 0xd90 du[145].inumber = 1426388827 du[145].namelen = 12 du[145].name = "069846IM.drw" du[145].tag = 0xda8 du[146].inumber = 1426388828 du[146].namelen = 12 du[146].name = "069847IM.drw" du[146].tag = 0xdc0 du[147].inumber = 1426388829 du[147].namelen = 12 du[147].name = "069848IM.drw" du[147].tag = 0xdd8 du[148].inumber = 1426388830 du[148].namelen = 12 du[148].name = "069849IM.drw" du[148].tag = 0xdf0 du[149].inumber = 1426388831 du[149].namelen = 12 du[149].name = "069850IM.drw" du[149].tag = 0xe08 du[150].inumber = 1426388832 du[150].namelen = 12 du[150].name = "069851IM.drw" du[150].tag = 0xe20 du[151].inumber = 1426388833 du[151].namelen = 12 du[151].name = "069852IM.drw" du[151].tag = 0xe38 du[152].inumber = 1426388834 du[152].namelen = 12 du[152].name = "069853IM.drw" du[152].tag = 0xe50 du[153].inumber = 1426388835 du[153].namelen = 12 du[153].name = "069854IM.drw" du[153].tag = 0xe68 du[154].inumber = 1426388836 du[154].namelen = 12 du[154].name = "069855IM.drw" du[154].tag = 0xe80 du[155].inumber = 1426388837 du[155].namelen = 12 du[155].name = "069856IM.drw" du[155].tag = 0xe98 du[156].inumber = 1426388838 du[156].namelen = 12 du[156].name = "069857IM.drw" du[156].tag = 0xeb0 du[157].inumber = 1426388839 du[157].namelen = 12 du[157].name = "069858IM.drw" du[157].tag = 0xec8 du[158].inumber = 1426388840 du[158].namelen = 12 du[158].name = "069859IM.drw" du[158].tag = 0xee0 du[159].inumber = 1426388841 du[159].namelen = 12 du[159].name = "069860IM.drw" du[159].tag = 0xef8 du[160].inumber = 1426388842 du[160].namelen = 12 du[160].name = "069861IM.drw" du[160].tag = 0xf10 du[161].inumber = 1426388843 du[161].namelen = 12 du[161].name = "069862IM.drw" du[161].tag = 0xf28 du[162].inumber = 1426388844 du[162].namelen = 12 du[162].name = "069863IM.drw" du[162].tag = 0xf40 du[163].inumber = 1426388845 du[163].namelen = 12 du[163].name = "069864IM.drw" du[163].tag = 0xf58 du[164].inumber = 1426388846 du[164].namelen = 12 du[164].name = "069865IM.drw" du[164].tag = 0xf70 du[165].inumber = 1426388847 du[165].namelen = 12 du[165].name = "069866IM.drw" du[165].tag = 0xf88 du[166].inumber = 1426388848 du[166].namelen = 12 du[166].name = "069867IM.drw" du[166].tag = 0xfa0 du[167].inumber = 1426388849 du[167].namelen = 12 du[167].name = "069868IM.drw" du[167].tag = 0xfb8 du[168].inumber = 1426388850 du[168].namelen = 12 du[168].name = "069869IM.drw" du[168].tag = 0xfd0 du[169].inumber = 1426388851 du[169].namelen = 12 du[169].name = "069870IM.drw" du[169].tag = 0xfe8 Bingo, the missing name is du[45].name = "069746IM.Mrw" This starts to be great fun!! :-) Anything else I should do? Thanks, Ralf -- Verkaufe Original-BMW-Raeder: L I N U X .~. http://adsl-bergs.rz.rwth-aachen.de/~rabe The Choice /V\ of a GNU /( )\ Generation ^^-^^ From owner-linux-xfs@oss.sgi.com Tue Jan 8 08:39:46 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g08GdkT10638 for linux-xfs-outgoing; Tue, 8 Jan 2002 08:39:46 -0800 Received: from smtpzilla1.xs4all.nl (smtpzilla1.xs4all.nl [194.109.127.137]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g08Gdhg10612 for ; Tue, 8 Jan 2002 08:39:43 -0800 Received: from auto-nb1.xs4all.nl (coltex.xs4all.nl [213.84.127.168]) by smtpzilla1.xs4all.nl (8.12.0/8.12.0) with ESMTP id g08FdbJp051048; Tue, 8 Jan 2002 16:39:37 +0100 (CET) Message-Id: <4.3.2.7.2.20020108163819.02b806d0@pop.xs4all.nl> X-Sender: knuffie@pop.xs4all.nl X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 08 Jan 2002 16:39:08 +0100 To: Olaf =?iso-8859-2?Q?Fr=B1czyk?= , linux-xfs@oss.sgi.com From: Seth Mos Subject: Re: vmware+XFS+duron+viakt133 - works? In-Reply-To: <20020108161756.A2191@venus.local.navi.pl> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 528 Lines: 16 At 16:17 8-1-2002 +0100, Olaf =?iso-8859-2?Q?Fr=B1czyk?= wrote: >Hi, >I changed my motherboard (I had Abit BP6 -BX440 chipset with Celeron) to >Asus A7V-133 (kt133A) with Duron 1000, and I have crashes with VMware. >Also checked A7V (kt133) with Duron 700. The system is stable. The Duron 1000 has a newer core then the 700 so I suggest fetching a bios update if you don't have the latest yet. Cheers -- Seth Every program has two purposes one for which it was written and another for which it wasn't I use the last kind. From owner-linux-xfs@oss.sgi.com Tue Jan 8 08:54:47 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g08Gsln13692 for linux-xfs-outgoing; Tue, 8 Jan 2002 08:54:47 -0800 Received: from zok.sgi.com (zok.SGI.COM [204.94.215.101]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g08Gsdg13665 for ; Tue, 8 Jan 2002 08:54:39 -0800 Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by zok.sgi.com (8.11.4/8.11.4/linux-outbound_gateway-1.1) with ESMTP id g08FsVA05888 for ; Tue, 8 Jan 2002 07:54:31 -0800 Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id JAA3895352; Tue, 8 Jan 2002 09:53:15 -0600 (CST) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id JAA39571; Tue, 8 Jan 2002 09:53:15 -0600 (CST) Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id g08FqR525501; Tue, 8 Jan 2002 09:52:27 -0600 Subject: Re: "No such file or directory" (still) (was Re: file corruption during emacs build on XFS logical volume From: Steve Lord To: "Ralf G. R. Bergs" Cc: Linux XFS In-Reply-To: References: Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/1.0.0.99+cvs.2001.12.18.08.57 (Preview Release) Date: 08 Jan 2002 09:52:27 -0600 Message-Id: <1010505147.25321.26.camel@jen.americas.sgi.com> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 1302 Lines: 48 On Tue, 2002-01-08 at 09:34, Ralf G. R. Bergs wrote: > On Tue, 08 Jan 2002 09:19:50 -0600, Steve Lord wrote: > > > >This output: > > > >dir 1426370585 block 8388614 extra leaf entry 62b7eea7 2a89 > >dir ino 1426370585 missing leaf entry for 62bdaea7/2a89 > > > > Bingo, the missing name is du[45].name = "069746IM.Mrw" > > This starts to be great fun!! :-) > > Anything else I should do? Hmm, explain why the correct hash value for this name is 0x62bdaea7, yet we created a leaf entry with the wrong hash value of 0x62b7eea7 Is there any chance you can create another instance of the problem, that version you had repair output for would have been very interesting since it was in a single block directory, not a hulking great beast like this one is in. I presume the name is a legitimate one from the source tree. Steve > > Thanks, > > Ralf > > > -- > Verkaufe Original-BMW-Raeder: L I N U X .~. > http://adsl-bergs.rz.rwth-aachen.de/~rabe The Choice /V\ > of a GNU /( )\ > Generation ^^-^^ > -- Steve Lord voice: +1-651-683-3511 Principal Engineer, Filesystem Software email: lord@sgi.com From owner-linux-xfs@oss.sgi.com Tue Jan 8 09:02:36 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g08H2ad14457 for linux-xfs-outgoing; Tue, 8 Jan 2002 09:02:36 -0800 Received: from ADSL-Bergs.RZ.RWTH-Aachen.DE (adsl-bergs.rz.RWTH-Aachen.DE [137.226.80.218]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g08H2Ug14434 for ; Tue, 8 Jan 2002 09:02:30 -0800 Received: from [192.168.1.2] (helo=ralf) by ADSL-Bergs.RZ.RWTH-Aachen.DE with smtp (Exim 3.12 #1) id 16Nyhi-0003wX-00; Tue, 08 Jan 2002 17:02:22 +0100 From: "Ralf G. R. Bergs" To: "Steve Lord" Cc: "Linux XFS" Date: Tue, 08 Jan 2002 17:02:22 +0100 Reply-To: "Ralf G. R. Bergs" X-Mailer: PMMail 2000 Professional (2.20.2380) For Windows 2000 (5.0.2195;2) In-Reply-To: <1010505147.25321.26.camel@jen.americas.sgi.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Subject: Re: "No such file or directory" (still) (was Re: file corruption during emacs build on XFS logical volume Message-Id: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 1601 Lines: 45 On Tue, 08 Jan 2002 09:52:27 -0600, Steve Lord wrote: >On Tue, 2002-01-08 at 09:34, Ralf G. R. Bergs wrote: >> On Tue, 08 Jan 2002 09:19:50 -0600, Steve Lord wrote: > >> > >> >This output: >> > >> >dir 1426370585 block 8388614 extra leaf entry 62b7eea7 2a89 >> >dir ino 1426370585 missing leaf entry for 62bdaea7/2a89 > >> Bingo, the missing name is du[45].name = "069746IM.Mrw" [...] >> Anything else I should do? > >Hmm, explain why the correct hash value for this name is 0x62bdaea7, >yet we created a leaf entry with the wrong hash value of 0x62b7eea7 A bug in your software? ;-) >Is there any chance you can create another instance of the problem, >that version you had repair output for would have been very interesting >since it was in a single block directory, not a hulking great beast >like this one is in. You mean I should destroy this filesystem, re-create a fresh one, and start the whole copy process again until it finishes without a filesystem shutdown? Of course I can't guarantee that the conditions will be the same as with the case you're referring to. >I presume the name is a legitimate one from the source tree. No -- it's not!! I just noticed that the CORRECT name would have been "069746IM.drw" -- it's a Micrografx Designer file, thus the extension "drw." What does that mean? -- Verkaufe Original-BMW-Raeder: L I N U X .~. http://adsl-bergs.rz.rwth-aachen.de/~rabe The Choice /V\ of a GNU /( )\ Generation ^^-^^ From owner-linux-xfs@oss.sgi.com Tue Jan 8 09:11:29 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g08HBT017069 for linux-xfs-outgoing; Tue, 8 Jan 2002 09:11:29 -0800 Received: from sgi.com (sgi-too.SGI.COM [204.94.211.39]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g08HBLg17044 for ; Tue, 8 Jan 2002 09:11:21 -0800 Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id IAA00357 for ; Tue, 8 Jan 2002 08:09:14 -0800 (PST) mail_from (lord@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id KAA4036862; Tue, 8 Jan 2002 10:10:02 -0600 (CST) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id KAA13635; Tue, 8 Jan 2002 10:10:02 -0600 (CST) Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id g08G9Eo25529; Tue, 8 Jan 2002 10:09:14 -0600 Subject: Re: "No such file or directory" (still) (was Re: file corruption during emacs build on XFS logical volume From: Steve Lord To: "Ralf G. R. Bergs" Cc: Linux XFS In-Reply-To: References: Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/1.0.0.99+cvs.2001.12.18.08.57 (Preview Release) Date: 08 Jan 2002 10:09:14 -0600 Message-Id: <1010506154.25290.32.camel@jen.americas.sgi.com> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 2383 Lines: 68 On Tue, 2002-01-08 at 10:02, Ralf G. R. Bergs wrote: > On Tue, 08 Jan 2002 09:52:27 -0600, Steve Lord wrote: > > >On Tue, 2002-01-08 at 09:34, Ralf G. R. Bergs wrote: > >> On Tue, 08 Jan 2002 09:19:50 -0600, Steve Lord wrote: > > > >> > > >> >This output: > >> > > >> >dir 1426370585 block 8388614 extra leaf entry 62b7eea7 2a89 > >> >dir ino 1426370585 missing leaf entry for 62bdaea7/2a89 > > > >> Bingo, the missing name is du[45].name = "069746IM.Mrw" > [...] > >> Anything else I should do? > > > >Hmm, explain why the correct hash value for this name is 0x62bdaea7, > >yet we created a leaf entry with the wrong hash value of 0x62b7eea7 > > A bug in your software? ;-) > > >Is there any chance you can create another instance of the problem, > >that version you had repair output for would have been very interesting > >since it was in a single block directory, not a hulking great beast > >like this one is in. > > You mean I should destroy this filesystem, re-create a fresh one, and start > the whole copy process again until it finishes without a filesystem shutdown? > Of course I can't guarantee that the conditions will be the same as with the > case you're referring to. That's what I was thinking, but maybe not, lets look at the names some more. > > >I presume the name is a legitimate one from the source tree. > > No -- it's not!! I just noticed that the CORRECT name would have been > "069746IM.drw" -- it's a Micrografx Designer file, thus the extension "drw." > > What does that mean? It means that the thing which is corrupted is the name itself, the hash value in the directory is the correct one for the name you supplied. So somehow a single character in the name got sat on, this is starting to get more interesting. If you look back through the old filenames in previous instances of this, are any of them incorrect too? Everything else in the directory block you sent is a .drw file. Steve > > > -- > Verkaufe Original-BMW-Raeder: L I N U X .~. > http://adsl-bergs.rz.rwth-aachen.de/~rabe The Choice /V\ > of a GNU /( )\ > Generation ^^-^^ > -- Steve Lord voice: +1-651-683-3511 Principal Engineer, Filesystem Software email: lord@sgi.com From owner-linux-xfs@oss.sgi.com Tue Jan 8 09:31:55 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g08HVtX17864 for linux-xfs-outgoing; Tue, 8 Jan 2002 09:31:55 -0800 Received: from ADSL-Bergs.RZ.RWTH-Aachen.DE (adsl-bergs.rz.RWTH-Aachen.DE [137.226.80.218]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g08HVkg17833 for ; Tue, 8 Jan 2002 09:31:46 -0800 Received: from [192.168.1.2] (helo=ralf) by ADSL-Bergs.RZ.RWTH-Aachen.DE with smtp (Exim 3.12 #1) id 16NzA1-000406-00; Tue, 08 Jan 2002 17:31:37 +0100 From: "Ralf G. R. Bergs" To: "Steve Lord" Cc: "Linux XFS" Date: Tue, 08 Jan 2002 17:31:38 +0100 Reply-To: "Ralf G. R. Bergs" X-Mailer: PMMail 2000 Professional (2.20.2380) For Windows 2000 (5.0.2195;2) In-Reply-To: <1010506154.25290.32.camel@jen.americas.sgi.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Subject: Re: "No such file or directory" (still) (was Re: file corruption during emacs build on XFS logical volume Message-Id: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 2112 Lines: 66 On Tue, 08 Jan 2002 10:09:14 -0600, Steve Lord wrote: [...] >> You mean I should destroy this filesystem, re-create a fresh one, and start >> the whole copy process again until it finishes without a filesystem shutdown? >> Of course I can't guarantee that the conditions will be the same as with the >> case you're referring to. > >That's what I was thinking, but maybe not, lets look at the names >some more. It's not a problem at all to destroy the filesystem, but of course then it's gone and I can't do any further inspections. >> >I presume the name is a legitimate one from the source tree. >> >> No -- it's not!! I just noticed that the CORRECT name would have been >> "069746IM.drw" -- it's a Micrografx Designer file, thus the extension "drw." [...] >It means that the thing which is corrupted is the name itself, the hash >value in the directory is the correct one for the name you supplied. Yes, of course, but my question should have read "How could that happen?" >So somehow a single character in the name got sat on, this is starting >to get more interesting. Indeed. :-) >If you look back through the old filenames in previous instances of >this, are any of them incorrect too? Yes, they are!! ls: ./daten/software/win 2000/Standard Fonts/.AppleDouble/M CORSVA.TTF: No such file or directory Here a line-feed has been introduced instead of a "T," the correct version would have been: ls: ./daten/software/win 2000/Standard Fonts/.AppleDouble/MTCORSVA.TTF Another broken filename: ./home/hiwi/willared/Netscapestangdefaultdefault__/Cache/MVDALU23.3IF The correct filename would have been (notice the changed extension): ./home/hiwi/willared/Netscapestangdefaultdefault__/Cache/MVDALU23.GIF Ok, back to you... Ralf -- Verkaufe Original-BMW-Raeder: L I N U X .~. http://adsl-bergs.rz.rwth-aachen.de/~rabe The Choice /V\ of a GNU /( )\ Generation ^^-^^ From owner-linux-xfs@oss.sgi.com Tue Jan 8 09:42:00 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g08Hg0g18330 for linux-xfs-outgoing; Tue, 8 Jan 2002 09:42:00 -0800 Received: from goliath.sylaba.poznan.pl (root@goliath.sylaba.poznan.pl [195.216.104.3]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g08Hftg18301 for ; Tue, 8 Jan 2002 09:41:55 -0800 Received: from venus.local.navi.pl (ps103.poznan.sdi.tpnet.pl [217.97.72.103]) by goliath.sylaba.poznan.pl (8.11.6/8.10.1) with ESMTP id g08Gfob22995 for ; Tue, 8 Jan 2002 17:41:50 +0100 (CET) Received: from venus.local.navi.pl (venus [192.168.1.10]) by venus.local.navi.pl (8.11.6/8.9.3) with ESMTP id g08GcbP03393 for ; Tue, 8 Jan 2002 17:38:37 +0100 Date: Tue, 8 Jan 2002 17:38:36 +0100 From: Olaf =?iso-8859-1?Q?Fr=B1czyk?= To: linux-xfs@oss.sgi.com Subject: Re: vmware+XFS+duron+viakt133 - works? Message-ID: <20020108173836.C2191@venus.local.navi.pl> References: <20020108161756.A2191@venus.local.navi.pl> <4.3.2.7.2.20020108163819.02b806d0@pop.xs4all.nl> Mime-Version: 1.0 Content-Type: text/plain; format=flowed; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit In-Reply-To: <4.3.2.7.2.20020108163819.02b806d0@pop.xs4all.nl>; from knuffie@xs4all.nl on wto, sty 08, 2002 at 16:39:08 +0100 X-Mailer: Balsa 1.2.3 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 721 Lines: 19 On 2002.01.08 16:39:08 +0100 Seth Mos wrote: > At 16:17 8-1-2002 +0100, Olaf =?iso-8859-2?Q?Fr=B1czyk?= wrote: >> Hi, >> I changed my motherboard (I had Abit BP6 -BX440 chipset with Celeron) >> to Asus A7V-133 (kt133A) with Duron 1000, and I have crashes with >> VMware. Also checked A7V (kt133) with Duron 700. The system is stable. I didn't wrote it clear here: On both motherboards (A7V and A7V-133) I have problem with vmware. And on both motherboards the system (linux) is stable. > The Duron 1000 has a newer core then the 700 so I suggest fetching a > bios update if you don't have the latest yet. Yes ;) I tried both BIOSes - the original, and the latest one. On both motherboards. Regards, Olaf Fraczyk From owner-linux-xfs@oss.sgi.com Tue Jan 8 09:47:04 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g08Hl4B18635 for linux-xfs-outgoing; Tue, 8 Jan 2002 09:47:04 -0800 Received: from goliath.sylaba.poznan.pl (root@goliath.sylaba.poznan.pl [195.216.104.3]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g08Hktg18605 for ; Tue, 8 Jan 2002 09:47:00 -0800 Received: from venus.local.navi.pl (ps103.poznan.sdi.tpnet.pl [217.97.72.103]) by goliath.sylaba.poznan.pl (8.11.6/8.10.1) with ESMTP id g08Gkob23234 for ; Tue, 8 Jan 2002 17:46:51 +0100 (CET) Received: from venus.local.navi.pl (venus [192.168.1.10]) by venus.local.navi.pl (8.11.6/8.9.3) with ESMTP id g08GfqP03415 for ; Tue, 8 Jan 2002 17:41:52 +0100 Date: Tue, 8 Jan 2002 17:41:52 +0100 From: Olaf =?iso-8859-2?Q?Fr=B1czyk?= To: linux-xfs@oss.sgi.com Subject: Re: vmware+XFS+duron+viakt133 - works? Message-ID: <20020108174152.E2191@venus.local.navi.pl> References: <20020108161756.A2191@venus.local.navi.pl> Mime-Version: 1.0 Content-Type: text/plain; format=flowed; charset=ISO-8859-2 Content-Transfer-Encoding: 8bit In-Reply-To: ; from dizzy@roedu.net on wto, sty 08, 2002 at 16:34:08 +0100 X-Mailer: Balsa 1.2.3 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 345 Lines: 13 On 2002.01.08 16:34:08 +0100 Mihai RUSU wrote: > Hi > > first you should try a kernel without XFS, better a similar version with > the ones with XFS you tried This is the problem ;) The whole system except root partition is XFS. And I don't have a free disk now :( OK, I try to find one, and check if there is some difference. Regards, Olaf From owner-linux-xfs@oss.sgi.com Tue Jan 8 09:55:55 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g08Httn19060 for linux-xfs-outgoing; Tue, 8 Jan 2002 09:55:55 -0800 Received: from sgi.com (sgi-too.SGI.COM [204.94.211.39]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g08Htpg19038 for ; Tue, 8 Jan 2002 09:55:51 -0800 Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id IAA02666 for ; Tue, 8 Jan 2002 08:53:43 -0800 (PST) mail_from (lord@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id KAA4039227; Tue, 8 Jan 2002 10:54:30 -0600 (CST) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id KAA29170; Tue, 8 Jan 2002 10:54:30 -0600 (CST) Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id g08GrfH25845; Tue, 8 Jan 2002 10:53:41 -0600 Subject: Re: "No such file or directory" (still) (was Re: file corruption during emacs build on XFS logical volume From: Steve Lord To: "Ralf G. R. Bergs" Cc: Linux XFS In-Reply-To: References: Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/1.0.0.99+cvs.2001.12.18.08.57 (Preview Release) Date: 08 Jan 2002 10:53:41 -0600 Message-Id: <1010508821.25799.12.camel@jen.americas.sgi.com> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 866 Lines: 28 On Tue, 2002-01-08 at 10:31, Ralf G. R. Bergs wrote: > > > Ok, back to you... > > Ralf > So all of these are single byte errors in the directory names. From the case we looking into detail on we saw that the name was correct at one point in the code - we managed to create the correct hash, but the directory name block has a single byte error. Once names are layed down into the directory block we never touch them, so there is very little code which has a chance to mess with the bytes. Is is possible to turn your raid into a jbod and do this on software raid instead - I do not think the config is important. I want to see if the error is going to change if we take the hardware raid out of the system. Steve -- Steve Lord voice: +1-651-683-3511 Principal Engineer, Filesystem Software email: lord@sgi.com From owner-linux-xfs@oss.sgi.com Tue Jan 8 09:56:05 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g08Hu5p19153 for linux-xfs-outgoing; Tue, 8 Jan 2002 09:56:05 -0800 Received: from burgers.bubbanfriends.org (IDENT:postfix@burgers.bubbanfriends.org [216.140.122.113]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g08Hu0g19113 for ; Tue, 8 Jan 2002 09:56:01 -0800 Received: by burgers.bubbanfriends.org (Postfix, from userid 500) id 7F8F6401A64; Tue, 8 Jan 2002 11:56:02 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by burgers.bubbanfriends.org (Postfix) with ESMTP id 79E8B2400235; Tue, 8 Jan 2002 11:56:02 -0500 (EST) Date: Tue, 8 Jan 2002 11:56:02 -0500 (EST) From: Mike Burger To: Olaf =?iso-8859-1?Q?Fr=B1czyk?= Cc: Subject: Re: vmware+XFS+duron+viakt133 - works? In-Reply-To: <20020108173836.C2191@venus.local.navi.pl> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 Content-Transfer-Encoding: 8BIT Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 944 Lines: 27 Sounds to me, then, that you might want to contact the makers of VMware to see if there's any known bugs with the Duron 1000 processor. On Tue, 8 Jan 2002, Olaf Fr±czyk wrote: > On 2002.01.08 16:39:08 +0100 Seth Mos wrote: > > At 16:17 8-1-2002 +0100, Olaf =?iso-8859-2?Q?Fr=B1czyk?= wrote: > >> Hi, > >> I changed my motherboard (I had Abit BP6 -BX440 chipset with Celeron) > >> to Asus A7V-133 (kt133A) with Duron 1000, and I have crashes with > >> VMware. Also checked A7V (kt133) with Duron 700. The system is stable. > I didn't wrote it clear here: > On both motherboards (A7V and A7V-133) I have problem with vmware. > And on both motherboards the system (linux) is stable. > > > The Duron 1000 has a newer core then the 700 so I suggest fetching a > > bios update if you don't have the latest yet. > > Yes ;) I tried both BIOSes - the original, and the latest one. On both > motherboards. > > Regards, > > Olaf Fraczyk > > From owner-linux-xfs@oss.sgi.com Tue Jan 8 10:00:04 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g08I04P19485 for linux-xfs-outgoing; Tue, 8 Jan 2002 10:00:04 -0800 Received: from sgi.com (sgi-too.SGI.COM [204.94.211.39]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g08Hxmg19425 for ; Tue, 8 Jan 2002 09:59:48 -0800 Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id IAA00605 for ; Tue, 8 Jan 2002 08:57:40 -0800 (PST) mail_from (lord@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id KAA4015074 for ; Tue, 8 Jan 2002 10:58:29 -0600 (CST) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id KAA50709 for ; Tue, 8 Jan 2002 10:58:29 -0600 (CST) From: Steve Lord Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id g08GveT25926; Tue, 8 Jan 2002 10:57:40 -0600 Message-Id: <200201081657.g08GveT25926@jen.americas.sgi.com> Date: Tue, 8 Jan 2002 10:57:40 -0600 Subject: TAKE - merge up to 2.5.2-pre10 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 5046 Lines: 147 A new scheduler! Date: Tue Jan 8 08:55:05 PST 2002 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:109220a linux/arch/arm/mach-ftvpci/pci.c - 1.1 linux/drivers/usb/auerswald.c - 1.1 linux/Documentation/usb/auerswald.txt - 1.1 linux/arch/arm/mach-ftvpci/leds.c - 1.1 linux/arch/arm/mach-footbridge/dma.c - 1.1 linux/arch/arm/mach-footbridge/dc21285.c - 1.1 linux/arch/arm/kernel/debug.S - 1.1 linux/arch/arm/mach-arc/small_page.c - 1.1 linux/arch/arm/kernel/head.S - 1.1 linux/arch/arm/mach-rpc/dma.c - 1.1 linux/net/unix/af_unix.c - 1.38 linux/net/sunrpc/sched.c - 1.22 linux/net/socket.c - 1.27 linux/net/sched/sch_generic.c - 1.11 linux/net/ipv4/tcp_output.c - 1.26 linux/mm/page_alloc.c - 1.71 linux/kernel/sys.c - 1.26 linux/kernel/softirq.c - 1.17 linux/kernel/signal.c - 1.23 linux/kernel/sched.c - 1.50 linux/kernel/printk.c - 1.16 linux/kernel/ksyms.c - 1.125 linux/kernel/fork.c - 1.41 linux/kernel/exit.c - 1.36 linux/kernel/capability.c - 1.7 linux/init/main.c - 1.67 linux/include/linux/smp.h - 1.9 linux/include/linux/sched.h - 1.52 linux/include/linux/list.h - 1.10 linux/include/linux/kernel_stat.h - 1.8 linux/include/linux/fs.h - 1.141 linux/include/asm-i386/smplock.h - 1.11 linux/include/asm-i386/smp.h - 1.16 linux/include/asm-i386/mmu_context.h - 1.14 linux/include/asm-i386/bitops.h - 1.9 linux/fs/ufs/truncate.c - 1.13 linux/fs/proc/array.c - 1.34 linux/fs/nfs/inode.c - 1.35 linux/fs/locks.c - 1.21 linux/fs/buffer.c - 1.104 linux/fs/block_dev.c - 1.36 linux/fs/binfmt_elf.c - 1.37 linux/drivers/usb/usb.c - 1.63 linux/drivers/usb/uhci.c - 1.56 linux/drivers/usb/Makefile - 1.46 linux/drivers/usb/Config.in - 1.52 linux/drivers/scsi/scsicam.c - 1.7 linux/drivers/net/slip.c - 1.20 linux/drivers/isdn/avmb1/capi.c - 1.28 linux/drivers/isdn/avmb1/b1pci.c - 1.17 linux/drivers/block/loop.c - 1.48 linux/arch/i386/mm/fault.c - 1.21 linux/arch/i386/kernel/smp.c - 1.38 linux/arch/i386/kernel/process.c - 1.38 linux/arch/i386/defconfig - 1.88 linux/arch/arm/mm/small_page.c - 1.10 linux/arch/arm/kernel/head-armv.S - 1.18 linux/arch/arm/kernel/dma-rpc.c - 1.9 linux/arch/arm/kernel/dec21285.c - 1.16 linux/Makefile - 1.172 linux/MAINTAINERS - 1.90 linux/Documentation/Configure.help - 1.122 linux/CREDITS - 1.69 linux/drivers/usb/acm.c - 1.44 linux/arch/arm/kernel/dma-footbridge.c - 1.6 linux/kernel/ptrace.c - 1.18 linux/arch/i386/kernel/smpboot.c - 1.26 linux/arch/arm/kernel/debug-armv.S - 1.11 linux/fs/proc/proc_misc.c - 1.30 linux/drivers/isdn/avmb1/t1pci.c - 1.16 linux/include/asm-i386/pgalloc.h - 1.13 linux/kernel/timer.c - 1.16 linux/drivers/usb/scanner.c - 1.27 linux/drivers/usb/usbkbd.c - 1.20 linux/drivers/usb/hid.h - 1.16 linux/drivers/usb/devio.c - 1.23 linux/arch/i386/kernel/apic.c - 1.24 linux/drivers/usb/usb-uhci.c - 1.34 linux/drivers/usb/usb-ohci.c - 1.32 linux/drivers/usb/scanner.h - 1.20 linux/drivers/isdn/avmb1/c4.c - 1.17 linux/drivers/usb/pegasus.c - 1.23 linux/include/linux/usb.h - 1.25 linux/include/linux/usbdevice_fs.h - 1.7 linux/drivers/usb/serial/keyspan_pda.c - 1.20 linux/drivers/usb/serial/ftdi_sio.c - 1.28 linux/drivers/usb/serial/whiteheat.c - 1.20 linux/drivers/usb/serial/omninet.c - 1.19 linux/drivers/usb/serial/digi_acceleport.c - 1.21 linux/kdb/kdbmain.c - 1.25 linux/drivers/usb/storage/transport.c - 1.16 linux/drivers/usb/serial/keyspan.h - 1.7 linux/drivers/usb/serial/keyspan.c - 1.18 linux/drivers/usb/bluetooth.c - 1.21 linux/drivers/char/joystick/iforce.c - 1.7 linux/arch/arm/kernel/ftv-pci.c - 1.2 linux/arch/arm/kernel/leds-ftvpci.c - 1.2 linux/drivers/md/md.c - 1.36 linux/mm/oom_kill.c - 1.12 linux/drivers/usb/pegasus.h - 1.7 linux/drivers/usb/serial/belkin_sa.c - 1.15 linux/drivers/usb/serial/mct_u232.c - 1.14 linux/drivers/usb/serial/empeg.c - 1.17 linux/fs/reiserfs/stree.c - 1.15 linux/fs/reiserfs/namei.c - 1.15 linux/fs/reiserfs/journal.c - 1.16 linux/fs/reiserfs/buffer2.c - 1.7 linux/drivers/usb/serial/io_tables.h - 1.4 linux/drivers/usb/serial/io_edgeport.c - 1.17 linux/arch/arm/kernel/irq-arch.c - 1.3 linux/arch/cris/drivers/usb-host.c - 1.10 linux/include/net/bluetooth/hci_usb.h - 1.4 linux/drivers/bluetooth/hci_usb.c - 1.5 linux/drivers/usb/catc.c - 1.5 linux/drivers/usb/serial/cyberjack.c - 1.8 linux/drivers/usb/serial/pl2303.c - 1.9 linux/drivers/usb/usb-skeleton.c - 1.6 linux/drivers/usb/kaweth.c - 1.9 linux/drivers/isdn/hisax/st5481.h - 1.3 linux/drivers/isdn/hisax/st5481_usb.c - 1.6 linux/drivers/usb/hid-core.c - 1.4 linux/fs/jffs2/background.c - 1.4 linux/drivers/ide/ataraid.c - 1.5 linux/arch/i386/kernel/nmi.c - 1.3 linux/drivers/char/mwave/mwavedd.c - 1.3 linux/drivers/usb/serial/ir-usb.c - 1.7 linux/fs/jbd/journal.c - 1.4 linux/fs/ext3/super.c - 1.6 linux/include/linux/jbd.h - 1.3 linux/fs/jbd/recovery.c - 1.3 linux/fs/jbd/revoke.c - 1.3 linux/fs/jbd/transaction.c - 1.3 linux/fs/nfs/pagelist.c - 1.2 linux/init/do_mounts.c - 1.8 linux/drivers/usb/hcd.c - 1.2 linux/drivers/usb/hcd/ehci-q.c - 1.2 From owner-linux-xfs@oss.sgi.com Tue Jan 8 10:16:06 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g08IG6020197 for linux-xfs-outgoing; Tue, 8 Jan 2002 10:16:06 -0800 Received: from ADSL-Bergs.RZ.RWTH-Aachen.DE (adsl-bergs.rz.RWTH-Aachen.DE [137.226.80.218]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g08IFvg20175 for ; Tue, 8 Jan 2002 10:15:59 -0800 Received: from [192.168.1.2] (helo=ralf) by ADSL-Bergs.RZ.RWTH-Aachen.DE with smtp (Exim 3.12 #1) id 16Nzqk-000467-00; Tue, 08 Jan 2002 18:15:46 +0100 From: "Ralf G. R. Bergs" To: "Steve Lord" Cc: "Linux XFS" Date: Tue, 08 Jan 2002 18:15:47 +0100 Reply-To: "Ralf G. R. Bergs" X-Mailer: PMMail 2000 Professional (2.20.2380) For Windows 2000 (5.0.2195;2) In-Reply-To: <1010508821.25799.12.camel@jen.americas.sgi.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Subject: Re: "No such file or directory" (still) (was Re: file corruption during emacs build on XFS logical volume Message-Id: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 1332 Lines: 36 On Tue, 08 Jan 2002 10:53:41 -0600, Steve Lord wrote: [...] >So all of these are single byte errors in the directory names. From the Right. >case we looking into detail on we saw that the name was correct at one >point in the code - we managed to create the correct hash, but the >directory name block has a single byte error. Once names are layed >down into the directory block we never touch them, so there is very >little code which has a chance to mess with the bytes. Hmmmm. I don't like what you're suggesting... :-( You think the problem might be within the RAID firmware? >Is is possible to turn your raid into a jbod and do this on software >raid instead - I do not think the config is important. I want to see >if the error is going to change if we take the hardware raid out of >the system. No, I can't reconfigure it as a JBOD. :-( Do you happen to know some sort of tool that might be able to do this kind of "integrity checks?" Or any other idea what I could do to make sure it isn't the RAID that's causing the problems? -- Verkaufe Original-BMW-Raeder: L I N U X .~. http://adsl-bergs.rz.rwth-aachen.de/~rabe The Choice /V\ of a GNU /( )\ Generation ^^-^^ From owner-linux-xfs@oss.sgi.com Tue Jan 8 10:53:22 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g08IrMC24227 for linux-xfs-outgoing; Tue, 8 Jan 2002 10:53:22 -0800 Received: from sgi.com (sgi-too.SGI.COM [204.94.211.39]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g08IrHg24204 for ; Tue, 8 Jan 2002 10:53:17 -0800 Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id JAA01827 for ; Tue, 8 Jan 2002 09:51:08 -0800 (PST) mail_from (lord@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id LAA4036174; Tue, 8 Jan 2002 11:51:56 -0600 (CST) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id LAA42042; Tue, 8 Jan 2002 11:51:56 -0600 (CST) Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id g08Hp7U26613; Tue, 8 Jan 2002 11:51:07 -0600 Subject: Re: "No such file or directory" (still) (was Re: file corruption during emacs build on XFS logical volume From: Steve Lord To: "Ralf G. R. Bergs" Cc: Linux XFS In-Reply-To: References: Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/1.0.0.99+cvs.2001.12.18.08.57 (Preview Release) Date: 08 Jan 2002 11:51:07 -0600 Message-Id: <1010512267.25799.19.camel@jen.americas.sgi.com> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 1133 Lines: 31 On Tue, 2002-01-08 at 11:15, Ralf G. R. Bergs wrote: > On Tue, 08 Jan 2002 10:53:41 -0600, Steve Lord wrote: > > [...] > >So all of these are single byte errors in the directory names. From the > > Right. > > >case we looking into detail on we saw that the name was correct at one > >point in the code - we managed to create the correct hash, but the > >directory name block has a single byte error. Once names are layed > >down into the directory block we never touch them, so there is very > >little code which has a chance to mess with the bytes. > > Hmmmm. I don't like what you're suggesting... :-( Well, if it was a hardware problem, it is hard to see how it would only affect file names, and not trash other parts of the fs as well. I suspect someone is walking on the memory from within XFS, but I do not at the moment have an idea on how to catch it - but then I am sat in a meeting right now. It might be worth getting one more data point we can look at with xfs_db. Steve Steve Lord voice: +1-651-683-3511 Principal Engineer, Filesystem Software email: lord@sgi.com From owner-linux-xfs@oss.sgi.com Tue Jan 8 11:28:26 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g08JSQx24970 for linux-xfs-outgoing; Tue, 8 Jan 2002 11:28:26 -0800 Received: from mail3.caramail.com (mail3.caramail.com [195.68.99.191]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g08JSKg24946 for ; Tue, 8 Jan 2002 11:28:21 -0800 Received: from caramail.com (www23.caramail.com [195.68.99.43]) by mail3.caramail.com (8.8.8/8.8.8) with SMTP id TAA28139; Tue, 8 Jan 2002 19:28:10 +0100 (MET) Posted-Date: Tue, 8 Jan 2002 19:28:10 +0100 (MET) From: LENHOF Jean-Yves To: linux-xfs@oss.sgi.com CC: olaf@cbk.poznan.pl Message-ID: <1010514490029649@caramail.com> X-Mailer: Caramail - www.caramail.com X-Originating-IP: [193.251.35.251] Mime-Version: 1.0 Subject: Re: vmware+XFS+duron+viakt133 - works? Date: Tue, 08 Jan 2002 19:28:10 GMT+1 Content-Type: multipart/mixed; boundary="=_NextPart_Caramail_0296491010514490_ID" Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 580 Lines: 20 This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --=_NextPart_Caramail_0296491010514490_ID Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Have you looked in groups.google.com for something like host.FSSupportLocking1 =3D 0x58465342 in your ~/.vmware... perhaps it may help ? Jyl _________________________________________________________ Le journal des abonn=E9s Caramail - http://www.carazine.com --=_NextPart_Caramail_0296491010514490_ID-- From owner-linux-xfs@oss.sgi.com Tue Jan 8 11:44:52 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g08JiqF25340 for linux-xfs-outgoing; Tue, 8 Jan 2002 11:44:52 -0800 Received: from ADSL-Bergs.RZ.RWTH-Aachen.DE (adsl-bergs.rz.RWTH-Aachen.DE [137.226.80.218]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g08Jikg25315 for ; Tue, 8 Jan 2002 11:44:47 -0800 Received: from [192.168.1.2] (helo=ralf) by ADSL-Bergs.RZ.RWTH-Aachen.DE with smtp (Exim 3.12 #1) id 16O1Eh-0004GP-00; Tue, 08 Jan 2002 19:44:35 +0100 From: "Ralf G. R. Bergs" To: "Steve Lord" Cc: "Linux XFS" Date: Tue, 08 Jan 2002 19:44:34 +0100 Reply-To: "Ralf G. R. Bergs" X-Mailer: PMMail 2000 Professional (2.20.2380) For Windows 2000 (5.0.2195;2) In-Reply-To: <1010512267.25799.19.camel@jen.americas.sgi.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Subject: Re: "No such file or directory" (still) (was Re: file corruption during emacs build on XFS logical volume Message-Id: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 920 Lines: 26 On Tue, 08 Jan 2002 11:51:07 -0600, Steve Lord wrote: [...] >Well, if it was a hardware problem, it is hard to see how it would >only affect file names, and not trash other parts of the fs as well. I agree. >I suspect someone is walking on the memory from within XFS, but I >do not at the moment have an idea on how to catch it - but then I >am sat in a meeting right now. > >It might be worth getting one more data point we can look at with xfs_db. Do I interpret this correctly by assuming that you want me to nuke the partition, create a fresh one, and copy the old RAID again until I get a copy with no filesystem shutdown? -- Verkaufe Original-BMW-Raeder: L I N U X .~. http://adsl-bergs.rz.rwth-aachen.de/~rabe The Choice /V\ of a GNU /( )\ Generation ^^-^^ From owner-linux-xfs@oss.sgi.com Tue Jan 8 12:08:10 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g08K8A025913 for linux-xfs-outgoing; Tue, 8 Jan 2002 12:08:10 -0800 Received: from pneumatic-tube.sgi.com (pneumatic-tube.sgi.com [204.94.214.22]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g08K87g25891 for ; Tue, 8 Jan 2002 12:08:07 -0800 Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id LAA02233 for ; Tue, 8 Jan 2002 11:08:43 -0800 (PST) mail_from (lord@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id NAA3998588 for ; Tue, 8 Jan 2002 13:06:49 -0600 (CST) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id NAA48160 for ; Tue, 8 Jan 2002 13:06:49 -0600 (CST) From: Steve Lord Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id g08J5xs26818; Tue, 8 Jan 2002 13:05:59 -0600 Message-Id: <200201081905.g08J5xs26818@jen.americas.sgi.com> Date: Tue, 8 Jan 2002 13:05:59 -0600 Subject: TAKE - fix emacs build breakage Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 396 Lines: 15 This fixes it at least for me, still waiting for feedback on this one though. Date: Tue Jan 8 11:03:59 PST 2002 Workarea: jen.americas.sgi.com:/src/lord/xfs-linux.2.4 The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:109229a linux/fs/pagebuf/page_buf_io.c - 1.105 - Do not clear BH_Delay on the buffer header without the lock. From owner-linux-xfs@oss.sgi.com Tue Jan 8 12:11:46 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g08KBkN26150 for linux-xfs-outgoing; Tue, 8 Jan 2002 12:11:46 -0800 Received: from sasami.anime.net (anime.net [63.172.78.150]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g08KBig26127 for ; Tue, 8 Jan 2002 12:11:44 -0800 Received: from localhost (goemon@localhost) by sasami.anime.net (8.11.6/8.11.6) with ESMTP id g08JBXh07703; Tue, 8 Jan 2002 11:11:34 -0800 Date: Tue, 8 Jan 2002 11:11:33 -0800 (PST) From: Dan Hollis To: "Ralf G. R. Bergs" cc: Steve Lord , Linux XFS Subject: Re: "No such file or directory" (still) (was Re: file corruption during emacs build on XFS logical volume In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 304 Lines: 11 On Tue, 8 Jan 2002, Ralf G. R. Bergs wrote: > On 08 Jan 2002 08:34:44 -0600, Steve Lord wrote: > >It does indeed look like a similar problem to the repair output. > I sure hope so -- because I'm getting the same error message! I get it too. -Dan -- [-] Omae no subete no kichi wa ore no mono da. [-] From owner-linux-xfs@oss.sgi.com Tue Jan 8 12:25:12 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g08KPCP26458 for linux-xfs-outgoing; Tue, 8 Jan 2002 12:25:12 -0800 Received: from yog-sothoth.sgi.com (eugate.sgi.com [192.48.160.10]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g08KP4g26435 for ; Tue, 8 Jan 2002 12:25:04 -0800 Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by yog-sothoth.sgi.com (980305.SGI.8.8.8-aspam-6.2/980304.SGI-aspam-europe) via ESMTP id UAA1478429 for ; Tue, 8 Jan 2002 20:22:54 +0100 (CET) mail_from (lord@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id NAA4039125; Tue, 8 Jan 2002 13:23:43 -0600 (CST) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id NAA50345; Tue, 8 Jan 2002 13:23:43 -0600 (CST) Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id g08JMsa27215; Tue, 8 Jan 2002 13:22:54 -0600 Subject: Re: "No such file or directory" (still) (was Re: file corruption during emacs build on XFS logical volume From: Steve Lord To: Dan Hollis Cc: "Ralf G. R. Bergs" , Linux XFS In-Reply-To: References: Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/1.0.0.99+cvs.2001.12.18.08.57 (Preview Release) Date: 08 Jan 2002 13:22:53 -0600 Message-Id: <1010517773.26708.4.camel@jen.americas.sgi.com> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 738 Lines: 26 On Tue, 2002-01-08 at 13:11, Dan Hollis wrote: > On Tue, 8 Jan 2002, Ralf G. R. Bergs wrote: > > On 08 Jan 2002 08:34:44 -0600, Steve Lord wrote: > > >It does indeed look like a similar problem to the repair output. > > I sure hope so -- because I'm getting the same error message! > > I get it too. Can you expand on that a little - you are seeing the same problem as Ralf? Can you provide hardware details, what it was you were doing, the exact output you see, and do you still have a filesystem in this state? Steve > > -Dan > -- > [-] Omae no subete no kichi wa ore no mono da. [-] -- Steve Lord voice: +1-651-683-3511 Principal Engineer, Filesystem Software email: lord@sgi.com From owner-linux-xfs@oss.sgi.com Tue Jan 8 13:00:36 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g08L0ap27202 for linux-xfs-outgoing; Tue, 8 Jan 2002 13:00:36 -0800 Received: from sasami.anime.net (anime.net [63.172.78.150]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g08L0Wg27180 for ; Tue, 8 Jan 2002 13:00:32 -0800 Received: from localhost (goemon@localhost) by sasami.anime.net (8.11.6/8.11.6) with ESMTP id g08K0IS08317; Tue, 8 Jan 2002 12:00:18 -0800 Date: Tue, 8 Jan 2002 12:00:17 -0800 (PST) From: Dan Hollis To: Steve Lord cc: "Ralf G. R. Bergs" , Linux XFS Subject: Re: "No such file or directory" (still) (was Re: file corruption during emacs build on XFS logical volume In-Reply-To: <1010517773.26708.4.camel@jen.americas.sgi.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 1187 Lines: 33 On 8 Jan 2002, Steve Lord wrote: > On Tue, 2002-01-08 at 13:11, Dan Hollis wrote: > > On Tue, 8 Jan 2002, Ralf G. R. Bergs wrote: > > > On 08 Jan 2002 08:34:44 -0600, Steve Lord wrote: > > > >It does indeed look like a similar problem to the repair output. > > > I sure hope so -- because I'm getting the same error message! > > I get it too. > Can you expand on that a little - you are seeing the same problem as > Ralf? Yes. Directories that give "No such file or directory" when you ls. For example, in /etc: # ls /etc ls: /etc/cron.weekly: No such file or directory ls: /etc/shadow-: No such file or directory adjtime hosts.allow makedev.d pwdb.conf skel bashrc hosts.deny man.config qpage.cf snmp cron.d hotplug mime.types rc ssh > Can you provide hardware details, what it was you were doing, the > exact output you see, and do you still have a filesystem in this > state? AMD K6/400, on a VIA MVP3 chipset. No raid, not even software raid. I also have a dual athlon system running rh7.2 and xfs, without any apparent corruption. -Dan -- [-] Omae no subete no kichi wa ore no mono da. [-] From owner-linux-xfs@oss.sgi.com Tue Jan 8 13:05:09 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g08L59G27455 for linux-xfs-outgoing; Tue, 8 Jan 2002 13:05:09 -0800 Received: from zok.sgi.com (zok.sgi.com [204.94.215.101]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g08L53g27432 for ; Tue, 8 Jan 2002 13:05:03 -0800 Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by zok.sgi.com (8.11.4/8.11.4/linux-outbound_gateway-1.1) with ESMTP id g08K4uA23798 for ; Tue, 8 Jan 2002 12:04:56 -0800 Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id OAA4035018; Tue, 8 Jan 2002 14:03:40 -0600 (CST) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id OAA54739; Tue, 8 Jan 2002 14:03:40 -0600 (CST) Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id g08K2on27640; Tue, 8 Jan 2002 14:02:50 -0600 Subject: Re: "No such file or directory" (still) (was Re: file corruption during emacs build on XFS logical volume From: Steve Lord To: Dan Hollis Cc: "Ralf G. R. Bergs" , Linux XFS In-Reply-To: References: Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/1.0.0.99+cvs.2001.12.18.08.57 (Preview Release) Date: 08 Jan 2002 14:02:50 -0600 Message-Id: <1010520170.27214.12.camel@jen.americas.sgi.com> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 1711 Lines: 46 On Tue, 2002-01-08 at 14:00, Dan Hollis wrote: > On 8 Jan 2002, Steve Lord wrote: > > On Tue, 2002-01-08 at 13:11, Dan Hollis wrote: > > > On Tue, 8 Jan 2002, Ralf G. R. Bergs wrote: > > > > On 08 Jan 2002 08:34:44 -0600, Steve Lord wrote: > > > > >It does indeed look like a similar problem to the repair output. > > > > I sure hope so -- because I'm getting the same error message! > > > I get it too. > > Can you expand on that a little - you are seeing the same problem as > > Ralf? > > Yes. Directories that give "No such file or directory" when you ls. For > example, in /etc: > > # ls /etc > ls: /etc/cron.weekly: No such file or directory > ls: /etc/shadow-: No such file or directory > adjtime hosts.allow makedev.d pwdb.conf skel > bashrc hosts.deny man.config qpage.cf snmp > cron.d hotplug mime.types rc ssh > > > Can you provide hardware details, what it was you were doing, the > > exact output you see, and do you still have a filesystem in this > > state? > > AMD K6/400, on a VIA MVP3 chipset. No raid, not even software raid. > > I also have a dual athlon system running rh7.2 and xfs, without any > apparent corruption. Hmm, I suspect it is not the same problem - but let me guess, this is the system where you cannot run xfs_repair since there is no other disk, or device present? Could you try what Ralf did, run xfs_db -r on the device (will work on a mounted fs). Then run the blockget -n command - this appears to do some consistency checks. Steve -- Steve Lord voice: +1-651-683-3511 Principal Engineer, Filesystem Software email: lord@sgi.com From owner-linux-xfs@oss.sgi.com Tue Jan 8 13:09:15 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g08L9Fc27642 for linux-xfs-outgoing; Tue, 8 Jan 2002 13:09:15 -0800 Received: from sasami.anime.net (anime.net [63.172.78.150]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g08L92g27615 for ; Tue, 8 Jan 2002 13:09:02 -0800 Received: from localhost (goemon@localhost) by sasami.anime.net (8.11.6/8.11.6) with ESMTP id g08K8ut08456; Tue, 8 Jan 2002 12:08:56 -0800 Date: Tue, 8 Jan 2002 12:08:56 -0800 (PST) From: Dan Hollis To: Steve Lord cc: "Ralf G. R. Bergs" , Linux XFS Subject: Re: "No such file or directory" (still) (was Re: file corruption during emacs build on XFS logical volume In-Reply-To: <1010520170.27214.12.camel@jen.americas.sgi.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 4111 Lines: 115 On 8 Jan 2002, Steve Lord wrote: > Hmm, I suspect it is not the same problem - but let me guess, this is > the system where you cannot run xfs_repair since there is no other > disk, or device present? Yes > Could you try what Ralf did, run xfs_db -r on the device (will work > on a mounted fs). Then run the blockget -n command - this appears to > do some consistency checks. # xfs_db -r /dev/hda2 xfs_db: blockget -n dir 25165952 block 0 bad stale tail count 2 dir ino 25165952 missing leaf entry for 1c9a34eb/16d dir ino 25165952 missing leaf entry for 3366553e/97 dir 46327620 size is 25, should be 24 dir 58771462 bad size in entry at 6 dir 67175607 bad size in entry at 6 block 0/5859 type unknown not expected disconnected inode 176237, nlink 1 block 3/5348 type unknown not expected disconnected inode 25243683, nlink 1 disconnected inode 25243684, nlink 1 disconnected inode 25243685, nlink 1 disconnected inode 29460069, nlink 1 disconnected inode 29460070, nlink 1 disconnected inode 29460071, nlink 1 disconnected inode 42106615, nlink 1 disconnected inode 42106616, nlink 1 disconnected inode 42106617, nlink 1 disconnected inode 46344864, nlink 1 disconnected inode 46344865, nlink 1 disconnected inode 46344866, nlink 1 disconnected inode 46344867, nlink 1 disconnected inode 46344868, nlink 1 disconnected inode 46344869, nlink 1 disconnected inode 46344870, nlink 1 disconnected inode 46344871, nlink 1 disconnected inode 46344872, nlink 1 disconnected inode 46344873, nlink 1 disconnected inode 46344874, nlink 1 disconnected inode 46344875, nlink 1 disconnected inode 46344876, nlink 1 disconnected inode 46344877, nlink 1 disconnected inode 46344878, nlink 1 disconnected inode 46344879, nlink 1 disconnected inode 46344880, nlink 1 disconnected inode 46344881, nlink 1 disconnected inode 46344882, nlink 1 disconnected inode 46344883, nlink 1 disconnected inode 46344884, nlink 1 disconnected inode 46344885, nlink 1 disconnected inode 46344886, nlink 1 disconnected inode 46344887, nlink 1 disconnected inode 46344888, nlink 1 disconnected inode 46344889, nlink 1 disconnected inode 46344890, nlink 1 disconnected inode 46344891, nlink 1 disconnected inode 46344892, nlink 1 disconnected inode 46344893, nlink 1 disconnected inode 46344894, nlink 1 disconnected inode 46344895, nlink 1 disconnected inode 46344896, nlink 1 disconnected inode 46344897, nlink 1 disconnected inode 46344898, nlink 1 disconnected inode 46344899, nlink 1 disconnected inode 46344900, nlink 1 disconnected inode 46344901, nlink 1 disconnected inode 46344902, nlink 1 disconnected inode 46344903, nlink 1 disconnected inode 46344904, nlink 1 disconnected inode 46344905, nlink 1 disconnected inode 46344906, nlink 1 disconnected inode 46344907, nlink 1 disconnected inode 46344910, nlink 1 disconnected inode 46344911, nlink 1 disconnected inode 46344916, nlink 1 disconnected inode 46326464, nlink 1 disconnected inode 46326465, nlink 1 disconnected inode 46205206, nlink 1 disconnected inode 46326513, nlink 1 disconnected inode 46326514, nlink 1 disconnected inode 46326515, nlink 1 disconnected inode 46326517, nlink 1 disconnected inode 46326518, nlink 1 disconnected inode 46326519, nlink 1 disconnected inode 46326520, nlink 1 disconnected inode 46326521, nlink 1 disconnected inode 46326522, nlink 1 disconnected inode 46326525, nlink 1 disconnected inode 46326526, nlink 1 disconnected inode 46326527, nlink 1 disconnected inode 58794944, nlink 1 disconnected inode 58794945, nlink 1 disconnected inode 58794946, nlink 1 disconnected inode 58794947, nlink 1 disconnected inode 58794948, nlink 1 disconnected inode 58794968, nlink 1 disconnected inode 58794969, nlink 1 disconnected inode 58794970, nlink 1 disconnected inode 67174913, nlink 1 disconnected inode 67174914, nlink 1 disconnected inode 67174915, nlink 1 disconnected inode 67174916, nlink 1 disconnected inode 67174917, nlink 1 disconnected inode 71470540, nlink 1 disconnected inode 71470541, nlink 1 disconnected inode 71470542, nlink 1 sb_fdblocks 4808556, counted 4808560 -Dan -- [-] Omae no subete no kichi wa ore no mono da. [-] From owner-linux-xfs@oss.sgi.com Tue Jan 8 13:22:09 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g08LM9s27989 for linux-xfs-outgoing; Tue, 8 Jan 2002 13:22:09 -0800 Received: from deliverator.sgi.com (deliverator.sgi.com [204.94.214.10]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g08LKgg27960 for ; Tue, 8 Jan 2002 13:20:42 -0800 Received: from relay1.corp.sgi.com (spindle.corp.sgi.com [198.29.75.13]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id MAA22596 for ; Tue, 8 Jan 2002 12:20:22 -0800 (PST) mail_from (florin@sgi.com) Received: from stantz.corp.sgi.com (stantz.corp.sgi.com [130.62.4.42]) by relay1.corp.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) via ESMTP id MAA65063 for ; Tue, 8 Jan 2002 12:20:07 -0800 (PST) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by stantz.corp.sgi.com (Postfix) with ESMTP id DD66F13650B for ; Tue, 8 Jan 2002 12:20:06 -0800 (PST) Subject: 1.0.2a anaconda hiccup From: Florin ANDREI To: linux-xfs@oss.sgi.com Content-Type: multipart/mixed; boundary="=-5wJs2MTqXvZlAtEky+OI" X-Mailer: Evolution/1.0 (Preview Release) Date: 08 Jan 2002 12:20:06 -0800 Message-Id: <1010521206.17883.9.camel@stantz.corp.sgi.com> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 34797 Lines: 824 --=-5wJs2MTqXvZlAtEky+OI Content-Type: text/plain Content-Transfer-Encoding: 7bit hardware: SGI1200, 2xPIII/800, Mylex DAC960 RAID controller 100GB software: XFS-1.0.2a (the ISO image) and Red Hat 7.2 The RAID area is a hardware RAID5, on 4x36GB drives What i'm trying to do: The machine was previously installed with XFS-1.0.1 and now i'm trying to reinstall it while preserving the partitioning layout (it's not an upgrade, it's a format/reinstall but the partitions are the same). Partitions: /boot 50MB Ext2 /dev/rd/c0d0p1 swap several hundreds megs /dev/rd/c0d0p2 / 4 GB XFS /dev/rd/c0d0p3 /var 95 GB XFS /dev/rd/c0d0p4 Problem: I select text-mode install (text nofb apic), then Custom install, do not repartition the RAID area (just print the partitions in fdisk, then quit), then i try to assign directories to partitions. Select the first partition, assign it to /boot, then go to Filesystem options. When i hit enter on that button, anaconda crashes. Hint (not sure whether it's useful or not): The fdisk from 1.0.2a complains about the partitions overlapping cylinder boundaries (if i recall correctly the warning). But fdisk from 1.0.1 says everything's fine (except that the number of cylinders is too large). This is what fdisk from 1.0.1 says: ############################################# [root@zoul /root]# fdisk /dev/rd/c0d0 The number of cylinders for this disk is set to 52069. There is nothing wrong with that, but this is larger than 1024, and could in certain setups cause problems with: 1) software that runs at boot time (e.g., old versions of LILO) 2) booting and partitioning software from other OSs (e.g., DOS FDISK, OS/2 FDISK) Command (m for help): p Disk /dev/rd/c0d0: 128 heads, 32 sectors, 52069 cylinders Units = cylinders of 4096 * 512 bytes Device Boot Start End Blocks Id System /dev/rd/c0d0p1 1 26 53232 83 Linux /dev/rd/c0d0p2 27 539 1050624 82 Linux swap /dev/rd/c0d0p3 540 2588 4196352 83 Linux /dev/rd/c0d0p4 2589 52069 101337088 83 Linux ############################################# The anaconda dump file is attached to this message. Is there any quick fix for this? -- Florin Andrei "The fast pace of IRC often prevents deeper thoughts, which is definitely the point for many people who use IRC." - Ingo Molnar --=-5wJs2MTqXvZlAtEky+OI Content-Disposition: attachment; filename=anacdump.txt Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=ISO-8859-2 Traceback (innermost last): File "/usr/bin/anaconda", line 620, in ? intf.run(id, dispatch, configFileData) File "/usr/lib/anaconda/text.py", line 386, in run rc =3D apply(win, (self.screen, ) + args) File "/usr/lib/anaconda/textw/partition_text.py", line 1004, in __call__ self.editCb() File "/usr/lib/anaconda/textw/partition_text.py", line 948, in editCb self.editPartitionRequest(request) File "/usr/lib/anaconda/textw/partition_text.py", line 657, in editPartit= ionRequest (format, migrate, newfstype, badblocks) =3D self.fsOptionsDialog(origre= quest, format, migrate, newfstype, badblocks) File "/usr/lib/anaconda/textw/partition_text.py", line 486, in fsOptionsD= ialog usetypes =3D migtypes) File "/usr/lib/anaconda/textw/partition_text.py", line 251, in makeFsList fstype.setCurrent(fileSystemTypeGetDefault()) File "/usr/lib/python1.5/snack.py", line 100, in setCurrent self.w.listboxSetCurrent(self.item2key[item]) KeyError: Local variables in innermost frame: self: item: Dispatcher instance, containing members: skipSteps: {'reconfigwelcome': 1, 'addswap': 1, 'indivpackage': 1, 'upgrade= migratefs': 1, 'findpackages': 1, 'reconfigkeyboard': 1, 'makebootdisk': 1,= 'autopartitionexecute': 1, 'upgrademount': 1, 'autopartition': 1, 'confirm= upgrade': 1, 'upgradeswapsuggestion': 1, 'upgrademigfind': 1, 'findinstall'= : 1, 'findrootparts': 1, 'reconfigcomplete': 1, 'upgradecontinue': 1} dir: 1 id: InstallData instance, containing members: configFileData: {'Splashscreen': pixmaps/first.png, 'WelcomeScreen': pixm= aps/splash.png, 'TitleBar': pixmaps/anaconda_header.png, 'Title': Red Hat L= inux Beta} upgradeSwapInfo: None langSupport: Language instance, containing members: langList: None allSupportedLangs: None supported: [] langNicks: None default: None langInfoByName: {'Spanish (Colombia)': ('es_CO', 'iso01', 'lat0-sun16')= , 'Spanish (Argentina)': ('es_AR', 'iso01', 'lat0-sun16'), 'Italian (Italy)= ': ('it_IT@euro', 'iso15', 'lat0-sun16'), 'Arabic (Lebanon)': ('ar_LB', 'is= o06', 'LatArCyrHeb-16'), 'Spanish (Guatemala)': ('es_GT', 'iso01', 'lat0-su= n16'), 'Malay (Malaysia)': ('ms_MY', 'iso01', 'lat0-sun16'), 'Arabic (Libya= n Arab Jamahiriya)': ('ar_LY', 'iso06', 'LatArCyrHeb-16'), 'Arabic (Oman)':= ('ar_OM', 'iso06', 'LatArCyrHeb-16'), 'Arabic (Iraq)': ('ar_IQ', 'iso06', = 'LatArCyrHeb-16'), 'Arabic (Kuwait)': ('ar_KW', 'iso06', 'LatArCyrHeb-16'),= 'English (South Africa)': ('en_ZA', 'iso01', 'lat0-sun16'), 'French (Switz= erland)': ('fr_CH', 'iso01', 'lat0-sun16'), 'Arabic (Bahrein)': ('ar_BH', '= iso06', 'LatArCyrHeb-16'), 'Croatian': ('hr_HR', 'iso02', 'lat2-sun16'), 'F= rench (France)': ('fr_FR@euro', 'iso15', 'lat0-sun16'), 'Greenlandic (Green= land)': ('kl_GL', 'iso01', 'lat0-sun16'), 'Korean (Republic of Korea)': ('k= o_KR.eucKR', 'iso01', 'lat0-sun16'), 'Ukrainian': ('uk_UA', 'koi8-u', 'cyr-= sun16'), 'Spanish (Mexico)': ('es_MX', 'iso01', 'lat0-sun16'), 'Greek': ('e= l_GR', 'iso07', 'iso07.16'), 'Spanish (El Salvador)': ('es_SV', 'iso01', 'l= at0-sun16'), 'Spanish (Peru)': ('es_PE', 'iso01', 'lat0-sun16'), 'Spanish (= Honduras)': ('es_HN', 'iso01', 'lat0-sun16'), 'Spanish (Costa Rica)': ('es_= CR', 'iso01', 'lat0-sun16'), 'English (Denmark)': ('en_DK', 'iso01', 'lat0-= sun16'), 'Dutch (Netherlands)': ('nl_NL@euro', 'iso15', 'lat0-sun16'), 'Ser= bian (Yugoslavia)': ('sr_YU@cyrillic', 'iso05', 'cyr-sun16'), 'Bosnian (Bos= nia and Herzegowina)': ('bs_BA', 'iso02', 'lat2-sun16'), 'Russian (Ukraine)= ': ('ru_UA', 'koi8-u', 'cyr-sun16'), 'Portuguese (Portugal)': ('pt_PT@euro'= , 'iso15', 'lat0-sun16'), 'Afrikaans (South Africa)': ('af_ZA', 'iso01', 'l= at0-sun16'), 'Norwegian': ('no_NO', 'iso01', 'lat0-sun16'), 'Arabic (Morocc= o)': ('ar_MA', 'iso06', 'LatArCyrHeb-16'), 'English (Philippines)': ('en_PH= ', 'iso01', 'lat0-sun16'), 'Arabic (Algeria)': ('ar_DZ', 'iso06', 'LatArCyr= Heb-16'), 'Indonesian': ('id_ID', 'iso01', 'lat0-sun16'), 'Danish': ('da_DK= ', 'iso01', 'lat0-sun16'), 'Chinese (Taiwan R.O.C.)': ('zh_TW.Big5', 'iso01= ', 'lat0-sun16'), 'Faroese (Faroe Islands)': ('fo_FO', 'iso01', 'lat0-sun16= '), 'Galician (Spain)': ('gl_ES@euro', 'iso15', 'lat0-sun16'), 'English (Ne= w Zealand)': ('en_NZ', 'iso01', 'lat0-sun16'), 'Spanish (Bolivia)': ('es_BO= ', 'iso01', 'lat0-sun16'), 'Cornish (Britain)': ('kw_GB', 'iso01', 'lat0-su= n16'), 'Arabic (United Arab Emirates)': ('ar_AE', 'iso06', 'LatArCyrHeb-16'= ), 'Spanish (Nicaragua)': ('es_NI', 'iso01', 'lat0-sun16'), 'German (Austri= a)': ('de_AT@euro', 'iso15', 'lat0-sun16'), 'Romanian': ('ro_RO', 'iso02', = 'lat2-sun16'), 'Spanish (Paraguay)': ('es_PY', 'iso01', 'lat0-sun16'), 'Heb= rew (Israel)': ('he_IL', 'iso08', 'LatArCyrHeb-16'), 'German (Luxemburg)': = ('de_LU@euro', 'iso15', 'lat0-sun16'), 'Spanish (USA)': ('es_US', 'iso01', = 'lat0-sun16'), 'Portuguese (Brasil)': ('pt_BR', 'iso01', 'lat0-sun16'), 'Sp= anish (Equador)': ('es_EC', 'iso01', 'lat0-sun16'), 'Polish': ('pl_PL', 'is= o02', 'lat2-sun16'), 'Slovak': ('sk_SK', 'iso02', 'lat2-sun16'), 'Macedonia= n': ('mk_MK', 'iso05', 'cyr-sun16'), 'Spanish (Spain)': ('es_ES@euro', 'iso= 15', 'lat0-sun16'), 'Spanish (Chile)': ('es_CL', 'iso01', 'lat0-sun16'), 'A= rabic (Syrian Arab Republic)': ('ar_SY', 'iso06', 'LatArCyrHeb-16'), 'Czech= ': ('cs_CZ', 'iso02', 'lat2-sun16'), 'Irish': ('ga_IE@euro', 'iso15', 'lat0= -sun16'), 'Arabic (Jordan)': ('ar_JO', 'iso06', 'LatArCyrHeb-16'), 'Italian= (Switzerland)': ('it_CH', 'iso01', 'lat0-sun16'), 'German (Belgium)': ('de= _BE@euro', 'iso15', 'lat0-sun16'), 'Albanian': ('sq_AL', 'iso01', 'lat0-sun= 16'), 'Occitan (France)': ('oc_FR', 'iso01', 'lat0-sun16'), 'Finnish': ('fi= _FI@euro', 'iso15', 'lat0-sun16'), 'Swedish (Sweden)': ('sv_SE', 'iso01', '= lat0-sun16'), 'English (Singapore)': ('en_SG', 'iso01', 'lat0-sun16'), 'Dut= ch (Belgium)': ('nl_BE@euro', 'iso15', 'lat0-sun16'), 'Spanish (Panama)': (= 'es_PA', 'iso01', 'lat0-sun16'), 'Spanish (Venezuela)': ('es_VE', 'iso01', = 'lat0-sun16'), 'English (Great Britain)': ('en_GB', 'iso01', 'lat0-sun16'),= 'Russian': ('ru_RU.koi8r', 'koi8-u', 'cyr-sun16'), 'Norwegian, Nynorsk (No= rway)': ('nn_NO', 'iso01', 'lat0-sun16'), 'English (Zimbabwe)': ('en_ZW', '= iso01', 'lat0-sun16'), 'English (USA)': ('en_US', 'iso01', 'lat0-sun16'), '= Tagalog (Philipines)': ('tl_PH', 'iso01', 'lat0-sun16'), 'Breton (France)':= ('br_FR', 'iso01', 'lat0-sun16'), 'Chinese (P.R. of China)': ('zh_CN.GB231= 2', 'iso01', 'lat0-sun16'), 'Arabic (Yemen)': ('ar_YE', 'iso06', 'LatArCyrH= eb-16'), 'Basque (Spain)': ('eu_ES@euro', 'iso15', 'lat0-sun16'), 'Arabic (= Qatar)': ('ar_QA', 'iso06', 'LatArCyrHeb-16'), 'Arabic (Egypt)': ('ar_EG', = 'iso06', 'LatArCyrHeb-16'), 'French (Belgium)': ('fr_BE@euro', 'iso15', 'la= t0-sun16'), 'English (Ireland)': ('en_IE@euro', 'iso15', 'lat0-sun16'), 'Hu= ngarian': ('hu_HU', 'iso02', 'lat2-sun16'), 'Arabic (Tunisia)': ('ar_TN', '= iso06', 'LatArCyrHeb-16'), 'French (Luxemburg)': ('fr_LU@euro', 'iso15', 'l= at0-sun16'), 'Japanese': ('ja_JP.eucJP', 'iso01', 'lat0-sun16'), 'Uzbek (Uz= bekistan)': ('uz_UZ', 'iso01', 'lat0-sun16'), 'Swedish (Finland)': ('sv_FI@= euro', 'iso15', 'lat0-sun16'), 'Arabic (Saudi Arabia)': ('ar_SA', 'iso06', = 'LatArCyrHeb-16'), 'Spanish (Dominican Republic)': ('es_DO', 'iso01', 'lat0= -sun16'), 'French (Canada)': ('fr_CA', 'iso01', 'lat0-sun16'), 'English (Ca= nada)': ('en_CA', 'iso01', 'lat0-sun16'), 'German (Germany)': ('de_DE@euro'= , 'iso15', 'lat0-sun16'), 'Slovenian (Slovenia)': ('sl_SI', 'iso02', 'lat2-= sun16'), 'Spanish (Uruguay)': ('es_UY', 'iso01', 'lat0-sun16'), 'German (Sw= itzerland)': ('de_CH', 'iso01', 'lat0-sun16'), 'English (Hong Kong)': ('en_= HK', 'iso01', 'lat0-sun16'), 'English (Australia)': ('en_AU', 'iso01', 'lat= 0-sun16'), 'Catalan (Spain)': ('ca_ES@euro', 'iso15', 'lat0-sun16'), 'Spani= sh (Puerto Rico)': ('es_PR', 'iso01', 'lat0-sun16'), 'Turkish': ('tr_TR', '= iso09', 'lat5-sun16'), 'Estonian': ('et_EE', 'iso01', 'lat0-sun16'), 'Arabi= c (Sudan)': ('ar_SD', 'iso06', 'LatArCyrHeb-16'), 'Icelandic': ('is_IS', 'i= so01', 'lat0-sun16'), 'English (Botswana)': ('en_BW', 'iso01', 'lat0-sun16'= ), 'Manx Gaelic (Britain)': ('gv_GB', 'iso01', 'lat0-sun16')} info: {'SUPPORTED': None} rootPassword: None diskset: DiskSet instance, containing members: disks: {'rd/c0d0': } tmpData: {'Splashscreen': pixmaps/first.png, 'WelcomeScreen': pixmaps/spl= ash.png, 'TitleBar': pixmaps/anaconda_header.png, 'Title': Red Hat Linux Be= ta} instLanguage: InstallTimeLanguage instance, containing members: kbd: {'Italian': it, 'Korean': us, 'Russian': ru, 'English': us, 'Norwe= gian': no-latin1, 'Swedish': se-latin1, 'French': fr-latin1, 'Japanese': jp= 106, 'Slovenian': slovene, 'Czech': cz-lat2, 'Ukrainian': ua, 'Spanish': es= , 'German': de-latin1-nodeadkeys, 'Danish': us, 'Icelandic': is-latin1} font: {'Italian': lat0-sun16, 'Korean': None, 'Russian': cyr-sun16, 'En= glish': default8x16, 'Norwegian': lat0-sun16, 'Swedish': lat0-sun16, 'Frenc= h': lat0-sun16, 'Japanese': Kon, 'Slovenian': lat2-sun16, 'Czech': lat2-sun= 16, 'Ukrainian': cyr-sun16, 'Spanish': lat0-sun16, 'German': lat0-16, 'Dani= sh': lat0-sun16, 'Icelandic': lat0-sun16} langNicks: {'Italian': it_IT, 'Korean': ko_KR.eucKR, 'Russian': ru_RU.k= oi8r, 'English': en_US, 'Norwegian': no_NO, 'Swedish': sv_SE, 'French': fr_= FR, 'Japanese': ja_JP.eucJP, 'Slovenian': sl_SI, 'Czech': cs_CZ, 'Ukrainian= ': uk_UA, 'Spanish': es_ES, 'German': de_DE, 'Danish': da_DK, 'Icelandic': = is_IS} langList: [Czech, Danish, English, French, German, Icelandic, Italian, = Japanese, Korean, Norwegian, Russian, Slovenian, Spanish, Swedish, Ukrainia= n] tz: {'Italian': Europe/Rome, 'Korean': Asia/Seoul, 'Russian': Europe/Mo= scow, 'English': America/New_York, 'Norwegian': Europe/Oslo, 'Swedish': Eur= ope/Stockholm, 'French': Europe/Paris, 'Japanese': Asia/Tokyo, 'Slovenian':= Europe/Ljubljana, 'Czech': Europe/Prague, 'Ukrainian': Europe/Kiev, 'Spani= sh': Europe/Madrid, 'German': Europe/Berlin, 'Danish': Europe/Copenhagen, '= Icelandic': Atlantic/Reykjavik} tempDefault:=20 map: {'Italian': iso15, 'Korean': None, 'Russian': koi8-r, 'English': i= so01, 'Norwegian': iso15, 'Swedish': iso15, 'French': iso15, 'Japanese': No= ne, 'Slovenian': iso02, 'Czech': iso02, 'Ukrainian': koi8-u, 'Spanish': iso= 15, 'German': iso09, 'Danish': iso15, 'Icelandic': iso15} current: en_US desktop: Desktop instance, containing members: runlevel: 3 info: {} videocard: primary: 0 vidCards: [] Primary Video Card Info: device: None descr : Cirrus Logic|GD 5480 server: XFree86 cardManf: Cirrus Logic GD-5480 VGA vidRam: 2048 carddata: {'SERVER': 'SVGA', 'NAME': 'Cirrus Logic GD5480', 'DRIVER': 'cirr= us', 'NOCLOCKPROBE': '', 'CHIPSET': 'CL-GD5480', 'VENDOR': 'Cirrus Logic GD= -5480 VGA'} devID: Cirrus Logic GD5480 fbmodes: None fbbpp: None floppyDevice: fd0 xconfig: XF86Config instance, containing members: keyLayout: us manualModes: {} mouse: FULLNAME=3D"None - None" MOUSETYPE=3D"none" XEMU3=3D"no" XMOUSETYPE=3D"none" monlist: {} keyRules: xfree86 keyModel: pc101 device: None monids: {} files:=20 # The location of the RGB database. Note, this is the name of the # file minus the extension (like ".txt" or ".db"). There is normally # no need to change the default. RgbPath "/usr/X11R6/lib/X11/rgb" # Multiple FontPath entries are allowed (they are concatenated together) # By default, Red Hat 6.0 and later now use a font server independent of # the X server to render fonts. FontPath "unix/:7100" keyVariant:=20 videocard: device: None descr : Cirrus Logic|GD 5480 server: XFree86 cardManf: Cirrus Logic GD-5480 VGA vidRam: 2048 carddata: {'SERVER': 'SVGA', 'NAME': 'Cirrus Logic GD5480', 'DRIVER': 'cirr= us', 'NOCLOCKPROBE': '', 'CHIPSET': 'CL-GD5480', 'VENDOR': 'Cirrus Logic GD= -5480 VGA'} devID: Cirrus Logic GD5480 fbmodes: None fbbpp: None keyOptions:=20 modes: {'16': ['800x600']} res: 800x600 monitor: monEisa: None monName: None monID: Unprobed Monitor fbmonSect:=20 monHoriz: 31.5-48.5 monVert: 50-70 skipx: 0 fallbackModes: {'16': ['800x600']} skip: 0 fbDepth: 16 monitor: Already dumped upgrade: Boolean instance, containing members: val: 0 instClass: InstallClass instance, containing members: partitions: Partitions instance, containing members: deletes: [] reinitializeDisks: 0 autoPartitionRequests: [mountpoint: / type: xfs uniqueID:None size: 700M requestSize: 700M grow: 1 max: None start: None end: None partnum: None drive: None primary: None=20=20 format: 1, options: None device: None, currentDrive: None raidlevel: None raidspares: None raidmembers: [] , mountpoint: /boot type: xfs uniqueID:None size: 50M requestSize: 50M grow: 0 max: None start: None end: None partnum: None drive: None primary: None=20=20 format: 1, options: None device: None, currentDrive: None raidlevel: None raidspares: None raidmembers: [] , mountpoint: None type: swap uniqueID:None size: 512M requestSize: 512M grow: 1 max: 1024 start: None end: None partnum: None drive: None primary: None=20=20 format: 1, options: None device: None, currentDrive: None raidlevel: None raidspares: None raidmembers: [] ] nextUniqueID: 9 zeroMbr: 0 autoClearPartType: 1 requests: [mountpoint: None type: xfs uniqueID:7 size: 4098.0M requestSize: 4098.0M grow: 0 max: None start: 2207744L end: 10600447L partnum: None drive: rd/c0d0 primary: None=20=20 format: None, options: None device: rd/c0d0p3, currentDrive: None raidlevel: None raidspares: None raidmembers: [] , mountpoint: None type: swap uniqueID:6 size: 1026.0M requestSize: 1026.0M grow: 0 max: None start: 106496L end: 2207743L partnum: None drive: rd/c0d0 primary: None=20=20 format: 1, options: None device: rd/c0d0p2, currentDrive: None raidlevel: None raidspares: None raidmembers: [] , mountpoint: None type: xfs uniqueID:8 size: 98962.0M requestSize: 98962.0M grow: 0 max: None start: 10600448L end: 213274623L partnum: None drive: rd/c0d0 primary: None=20=20 format: None, options: None device: rd/c0d0p4, currentDrive: None raidlevel: None raidspares: None raidmembers: [] , mountpoint: None type: ext2 uniqueID:5 size: 51.984375M requestSize: 51.984375M grow: 0 max: None start: 32L end: 106495L partnum: None drive: rd/c0d0 primary: None=20=20 format: None, options: None device: rd/c0d0p1, currentDrive: None raidlevel: None raidspares: None raidmembers: [] ] autoClearPartDrives: [] useFdisk: 1 useAutopartitioning: 0 extraModules: [] mouse: Already dumped bootloader: x86BootloaderInfo instance, containing members: useGrubVal: 1 forceLBA32: 0 password: None images: BootImages instance, containing members: images: {} default: None pure: None device: None configfile: /etc/lilo.conf above1024: 0 kernelLocation: /boot/ args: KernelArguments instance, containing members: args:=20 defaultDevice: None useLinear: 1 timezone: Timezone instance, containing members: dst: 0 tz: None arc: 0 utcOffset: 0 utc: 0 keyboard: Keyboard instance, containing members: beenset: 1 layout: None model: None type: PC info: {'KEYBOARDTYPE': pc, 'KEYTABLE': us} accounts: None dependencies: [] comps: None upgradeRoot: None auth: Authentication instance, containing members: useNIS: 0 sambaServer:=20 enableCache: 0 nisServer:=20 useLdap: 0 sambaWorkgroup:=20 krb5Kdc:=20 ldapTLS:=20 useHesiod: 0 ldapServer:=20 nisDomain:=20 krb5Realm:=20 useLdapauth: 0 hesiodRhs:=20 useShadow: 1 nisuseBroadcast: 1 useKrb5: 0 useMD5: 1 ldapBasedn:=20 krb5Admin:=20 hesiodLhs:=20 useSamba: 0 upgradeDeps:=20 firewall: Firewall instance, containing members: ports: [] trustdevs: [] dhcp: 0 policy: 1 ssh: 0 custom: 1 telnet: 0 smtp: 0 enabled: -1 portlist:=20 http: 0 ftp: 0 dbpath: None network: Network instance, containing members: netdevices: {} gateway:=20 secondaryNS:=20 hostname: localhost.localdomain primaryNS:=20 domains: [] isConfigured: 0 readData: 0 ternaryNS:=20 fsset: FileSystemSet instance, containing members: migratedfs: 0 mountcount: 0 entries: [FileSystemSetEntry instance, containing members: origfsystem: None mountcount: 0 options: gid=3D5,mode=3D620 order: 0 mountpoint: /dev/pts device: Device instance, containing members: label: None isSetup: 0 fsoptions: {} device: none label: None fsck: 0 fsystem: DevptsFileSystem instance, containing members: maxLabelChars: 16 partedFileSystemType: None formattable: 0 extraFormatArgs: [] maxSize: 2097152 defaultOptions: gid=3D5,mode=3D620 linuxnativefs: 0 deviceArguments: {} migratetofs: None name: devpts checked: 0 partedPartitionFlags: [] supported: 0 migrate: 0 format: 0 badblocks: 0 , FileSystemSetEntry instance, containing members: origfsystem: None mountcount: 0 options: defaults order: 0 mountpoint: /proc device: Device instance, containing members: label: None isSetup: 0 fsoptions: {} device: none label: None fsck: 0 fsystem: ProcFileSystem instance, containing members: maxLabelChars: 16 partedFileSystemType: None formattable: 0 extraFormatArgs: [] maxSize: 2097152 defaultOptions: defaults linuxnativefs: 0 deviceArguments: {} migratetofs: None name: proc checked: 0 partedPartitionFlags: [] supported: 0 migrate: 0 format: 0 badblocks: 0 ] progressWindow: waitWindow: messageWindow: hdList: None firstStep: 0 method: CdromInstallMethod instance, containing members: progressWindow: device: hdc tree: /mnt/source currentDisc: 3 loopbackFile: None messageWindow: instPath: /mnt/sysimage flags: Flags instance, containing members: flags: {'autostep': 0, 'expert': 0, 'setupFilesystems': 1, 'serial': 0, '= reconfig': 0, 'test': 0} intf: InstallInterface instance, containing members: showingHelpOnHelp: 0 instLanguage: Already dumped welcomeText: Red Hat Linux (C) 2001 Red Hat, Inc. langSearchPath: [en_US, en, C] screen: SnackScreen instance, containing members: height: 25 width: 80 helpCb: step: 16 dispatch: Already dumped /tmp/syslog: <4>Linux version 2.4.7-10SGI_XFS_PR1BOOT (mkp@austin.mkp.net) (gcc version = egcs-2.91.66 19990314/Linux (egcs-1.1.2 release)) #1 Tue Nov 13 15:18:03 ES= T 2001 <6>BIOS-provided physical RAM map: <4> BIOS-e820: 0000000000000000 - 000000000009ec00 (usable) <4> BIOS-e820: 000000000009ec00 - 00000000000a0000 (reserved) <4> BIOS-e820: 00000000000e8000 - 0000000000100000 (reserved) <4> BIOS-e820: 0000000000100000 - 000000001fff0000 (usable) <4> BIOS-e820: 000000001fff0000 - 000000001ffffc00 (ACPI data) <4> BIOS-e820: 000000001ffffc00 - 0000000020000000 (ACPI NVS) <4> BIOS-e820: 00000000fec00000 - 00000000fec10000 (reserved) <4> BIOS-e820: 00000000fee00000 - 00000000fee01000 (reserved) <4> BIOS-e820: 00000000fff80000 - 0000000100000000 (reserved) <4>found SMP MP-table at 000f6ac0 <4>hm, page 000f6000 reserved twice. <4>hm, page 000f7000 reserved twice. <4>hm, page 0009e000 reserved twice. <4>hm, page 0009f000 reserved twice. <4>On node 0 totalpages: 131056 <4>zone(0): 4096 pages. <4>zone(1): 126960 pages. <4>zone(2): 0 pages. <4>Intel MultiProcessor Specification v1.4 <4> Virtual Wire compatibility mode. <4>OEM ID: INTEL Product ID: Lancewood APIC at: 0xFEE00000 <4>Processor #1 Pentium(tm) Pro APIC version 17 <4>Processor #0 Pentium(tm) Pro APIC version 17 <4>I/O APIC #2 Version 17 at 0xFEC00000. <4>Processors: 2 <4>Kernel command line: initrd=3Dinitrd.img lang=3D text devfs=3Dnomount ra= mdisk_size=3D8192 BOOT_IMAGE=3Dvmlinuz nofb apic <6>Initializing CPU#0 <4>Detected 696.425 MHz processor. <4>Console: colour VGA+ 80x25 <4>Calibrating delay loop... 1389.36 BogoMIPS <4>Memory: 509332k/524224k available (1162k kernel code, 12436k reserved, 8= 9k data, 108k init, 0k highmem) <4>Dentry-cache hash table entries: 65536 (order: 7, 524288 bytes) <4>Inode-cache hash table entries: 32768 (order: 6, 262144 bytes) <4>Mount-cache hash table entries: 8192 (order: 4, 65536 bytes) <4>Buffer-cache hash table entries: 32768 (order: 5, 131072 bytes) <4>Page-cache hash table entries: 131072 (order: 8, 1048576 bytes) <7>CPU: Before vendor init, caps: 0387fbff 00000000 00000000, vendor =3D 0 <6>CPU: L1 I cache: 16K, L1 D cache: 16K <6>CPU: L2 cache: 256K <6>Intel machine check architecture supported. <6>Intel machine check reporting enabled on CPU#0. <7>CPU: After vendor init, caps: 0387fbff 00000000 00000000 00000000 <5>CPU serial number disabled. <7>CPU: After generic, caps: 0383fbff 00000000 00000000 00000000 <7>CPU: Common caps: 0383fbff 00000000 00000000 00000000 <4>CPU: Intel Pentium III (Coppermine) stepping 03 <6>Enabling fast FPU save and restore... done. <6>Enabling unmasked SIMD FPU exception support... done. <6>Checking 'hlt' instruction... OK. <6>Checking for popad bug... OK. <4>POSIX conformance testing by UNIFIX <4>enabled ExtINT on CPU#0 <4>ESR value before enabling vector: 00000000 <4>ESR value after enabling vector: 00000000 <4>ENABLING IO-APIC IRQs <6>...changing IO-APIC physical APIC ID to 2 ... ok. <7>init IO_APIC IRQs <7> IO-APIC (apicid-pin) 2-0, 2-9, 2-10, 2-11, 2-16, 2-17, 2-18, 2-20, 2-22= , 2-23 not connected. <6>..TIMER: vector=3D0x31 pin1=3D2 pin2=3D0 <7>number of MP IRQ sources: 18. <7>number of IO-APIC #2 registers: 24. <6>testing the IO APIC....................... <4> <7>IO APIC #2...... <7>.... register #00: 02000000 <7>....... : physical APIC id: 02 <7>.... register #01: 00170011 <7>....... : max redirection entries: 0017 <7>....... : IO APIC version: 0011 <7>.... register #02: 00000000 <7>....... : arbitration: 00 <7>.... IRQ redirection table: <7> NR Log Phy Mask Trig IRR Pol Stat Dest Deli Vect:=20=20=20 <7> 00 000 00 1 0 0 0 0 0 0 00 <7> 01 001 01 0 0 0 0 0 1 1 39 <7> 02 001 01 0 0 0 0 0 1 1 31 <7> 03 001 01 0 0 0 0 0 1 1 41 <7> 04 001 01 0 0 0 0 0 1 1 49 <7> 05 001 01 0 0 0 0 0 1 1 51 <7> 06 001 01 0 0 0 0 0 1 1 59 <7> 07 001 01 0 0 0 0 0 1 1 61 <7> 08 001 01 0 0 0 0 0 1 1 69 <7> 09 000 00 1 0 0 0 0 0 0 00 <7> 0a 000 00 1 0 0 0 0 0 0 00 <7> 0b 000 00 1 0 0 0 0 0 0 00 <7> 0c 001 01 0 0 0 0 0 1 1 71 <7> 0d 001 01 0 0 0 0 0 1 1 79 <7> 0e 001 01 0 0 0 0 0 1 1 81 <7> 0f 001 01 0 0 0 0 0 1 1 89 <7> 10 000 00 1 0 0 0 0 0 0 00 <7> 11 000 00 1 0 0 0 0 0 0 00 <7> 12 000 00 1 0 0 0 0 0 0 00 <7> 13 001 01 1 1 0 1 0 1 1 91 <7> 14 000 00 1 0 0 0 0 0 0 00 <7> 15 001 01 1 1 0 1 0 1 1 99 <7> 16 000 00 1 0 0 0 0 0 0 00 <7> 17 000 00 1 0 0 0 0 0 0 00 <7>IRQ to pin mappings: <7>IRQ0 -> 0:2 <7>IRQ1 -> 0:1 <7>IRQ3 -> 0:3 <7>IRQ4 -> 0:4 <7>IRQ5 -> 0:5 <7>IRQ6 -> 0:6 <7>IRQ7 -> 0:7 <7>IRQ8 -> 0:8 <7>IRQ12 -> 0:12 <7>IRQ13 -> 0:13 <7>IRQ14 -> 0:14 <7>IRQ15 -> 0:15 <7>IRQ19 -> 0:19 <7>IRQ21 -> 0:21 <6>.................................... done. <4>Using local APIC timer interrupts. <4>calibrating APIC timer ... <4>..... CPU clock speed is 696.4176 MHz. <4>..... host bus clock speed is 99.4880 MHz. <4>cpu: 0, clocks: 994880, slice: 497440 <4>CPU0 <4>mtrr: v1.40 (20010327) Richard Gooch (rgooch@atnf.csiro.au) <4>mtrr: detected mtrr type: Intel <4>PCI: PCI BIOS revision 2.10 entry at 0xfdab0, last bus=3D3 <4>PCI: Using configuration type 1 <4>PCI: Probing PCI hardware <3>Unknown bridge resource 0: assuming transparent <3>Unknown bridge resource 1: assuming transparent <3>Unknown bridge resource 2: assuming transparent <3>Unknown bridge resource 0: assuming transparent <3>Unknown bridge resource 1: assuming transparent <3>Unknown bridge resource 2: assuming transparent <3>Unknown bridge resource 0: assuming transparent <3>Unknown bridge resource 1: assuming transparent <3>Unknown bridge resource 2: assuming transparent <6>PCI: Discovered primary peer bus ff [IRQ] <6>PCI: Using IRQ router PIIX [8086/7110] at 00:12.0 <6>PCI->APIC IRQ transform: (B0,I9,P0) -> 19 <6>PCI->APIC IRQ transform: (B0,I12,P0) -> 19 <6>PCI->APIC IRQ transform: (B0,I12,P0) -> 19 <6>PCI->APIC IRQ transform: (B0,I14,P0) -> 21 <6>PCI->APIC IRQ transform: (B0,I18,P3) -> 21 <6>Linux NET4.0 for Linux 2.4 <6>Based upon Swansea University Computer Society NET3.039 <4>Starting kswapd v1.8 <4>pty: 256 Unix98 ptys configured <6>Serial driver version 5.05c (2001-07-08) with MANY_PORTS SHARE_IRQ SERIA= L_PCI enabled <6>ttyS00 at 0x03f8 (irq =3D 4) is a 16550A <6>ttyS01 at 0x02f8 (irq =3D 3) is a 16550A <4>block: queued sectors max/low 338194kB/207122kB, 1024 slots per queue <4>RAMDISK driver initialized: 16 RAM disks of 8192K size 1024 blocksize <6>Uniform Multi-Platform E-IDE driver Revision: 6.31 <6>ide: Assuming 33MHz PCI bus speed for PIO modes; override with idebus=3D= xx <4>PIIX4: IDE controller on PCI bus 00 dev 91 <4>PIIX4: chipset revision 1 <4>PIIX4: not 100% native mode: will probe irqs later <4> ide0: BM-DMA at 0x2860-0x2867, BIOS settings: hda:pio, hdb:pio <4> ide1: BM-DMA at 0x2868-0x286f, BIOS settings: hdc:DMA, hdd:pio <4>hdc: CD-540E, ATAPI CD/DVD-ROM drive <4>ide1 at 0x170-0x177,0x376 on irq 15 <4>hdc: ATAPI 40X CD-ROM drive, 128kB Cache <6>Uniform CD-ROM driver Revision: 3.12 <4>ide-floppy driver 0.97 <6>Floppy drive(s): fd0 is 1.44M <6>FDC 0 is a National Semiconductor PC87306 <6>loop: loaded (max 8 devices) <4>ide-floppy driver 0.97 <6>md: md driver 0.90.0 MAX_MD_DEVS=3D256, MD_SB_DISKS=3D27 <6>md: Autodetecting RAID arrays. <4>md: autorun ... <4>md: ... autorun DONE. <6>NET4: Linux TCP/IP 1.0 for NET4.0 <6>IP Protocols: ICMP, UDP, TCP <4>IP: routing cache hash table of 4096 buckets, 32Kbytes <4>TCP: Hash tables configured (established 32768 bind 32768) <6>NET4: Unix domain sockets 1.0/SMP for Linux NET4.0. <5>RAMDISK: Compressed image found at block 0 <4>Freeing initrd memory: 1932k freed <4>VFS: Mounted root (ext2 filesystem). <6>SCSI subsystem driver Revision: 1.00 <6>usb.c: registered new driver usbdevfs <6>usb.c: registered new driver hub <6>usb-uhci.c: $Revision: 1.259 $ time 15:31:57 Nov 13 2001 <6>usb-uhci.c: High bandwidth mode enabled <6>usb-uhci.c: USB UHCI at I/O 0x2840, IRQ 21 <4>usb-uhci.c: Detected 2 ports <6>usb.c: new USB bus registered, assigned bus number 1 <6>hub.c: USB hub found <6>hub.c: 2 ports detected <6>usb-uhci.c: v1.251:USB Universal Host Controller Interface driver <6>usb.c: registered new driver hid <6>usb.c: registered new driver hiddev <6>hid-core.c: v1.8 Andreas Gal, Vojtech Pavlik <6>hid-core.c: USB HID support drivers <6>Initializing USB Mass Storage driver... <6>usb.c: registered new driver usb-storage <6>USB Mass Storage support registered. <4>eepro100.c:v1.09j-t 9/29/99 Donald Becker http://cesdis.gsfc.nasa.gov/li= nux/drivers/eepro100.html <4>eepro100.c: $Revision: 1.36 $ 2000/11/17 Modified by Andrey V. Savochkin= and others <6>eth0: PCI device 8086:1229, 00:90:27:F6:9F:49, IRQ 21. <6> Receiver lock-up bug exists -- enabling work-around. <6> Board assembly 000000-000, Physical connectors present: RJ45 <6> Primary interface chip i82555 PHY #1. <6> General self-test: passed. <6> Serial sub-system self-test: passed. <6> Internal registers self-test: passed. <6> ROM checksum self-test: passed (0x04f4518b). <6> Receiver lock-up workaround activated. <6>(scsi0) found at PCI 0/12/0 <6>(scsi0) Wide Channel A, SCSI ID=3D7, 32/255 SCBs <6>(scsi0) Downloading sequencer code... 393 instructions downloaded <6>(scsi1) found at PCI 0/12/1 <6>(scsi1) Wide Channel B, SCSI ID=3D7, 32/255 SCBs <6>(scsi1) Downloading sequencer code... 393 instructions downloaded <6>scsi0 : Adaptec AHA274x/284x/294x (EISA/VLB/PCI-Fast SCSI) 5.2.4/5.2.0 <4> <6>scsi1 : Adaptec AHA274x/284x/294x (EISA/VLB/PCI-Fast SCSI) 5.2.4/5.2.0 <4> <5>DAC960: ***** DAC960 RAID Driver Version 2.4.10 of 1 February 2001 ***** <5>DAC960: Copyright 1998-2001 by Leonard N. Zubkoff <5>DAC960#0: Configuring Mylex DAC960PTL1 PCI RAID Controller <5>DAC960#0: Firmware Version: 4.07-0-29, Channels: 1, Memory Size: 16MB <5>DAC960#0: PCI Bus: 0, Device: 9, Function: 1, I/O Address: Unassigned <5>DAC960#0: PCI Address: 0xF4104000 mapped at 0xE0878000, IRQ Channel: 19 <5>DAC960#0: Controller Queue Depth: 124, Maximum Blocks per Command: 128 <5>DAC960#0: Driver Queue Depth: 123, Scatter/Gather Limit: 33 of 33 Segm= ents <5>DAC960#0: Stripe Size: 64KB, Segment Size: 8KB, BIOS Geometry: 128/32 <5>DAC960#0: SAF-TE Enclosure Management Enabled <5>DAC960#0: Physical Devices: <5>DAC960#0: 0:1 Vendor: SGI Model: SEAGATE ST336704 Revision: = 2742 <5>DAC960#0: Serial Number: 3CD1JKBQ000071281PJJ <5>DAC960#0: Disk Status: Online, 71092224 blocks <5>DAC960#0: 0:2 Vendor: SGI Model: SEAGATE ST336704 Revision: = 2742 <5>DAC960#0: Serial Number: 3CD1JQTV00007131HAE6 <5>DAC960#0: Disk Status: Online, 71092224 blocks <5>DAC960#0: 0:3 Vendor: SGI Model: SEAGATE ST336704 Revision: = 2742 <5>DAC960#0: Serial Number: 3CD1JRF3000071281NN6 <5>DAC960#0: Disk Status: Online, 71092224 blocks <5>DAC960#0: 0:4 Vendor: SGI Model: SEAGATE ST336704 Revision: = 2742 <5>DAC960#0: Serial Number: 3CD1JRCM00007131HAFX <5>DAC960#0: Disk Status: Online, 71092224 blocks <5>DAC960#0: 0:9 Vendor: SGI1200 Model: Server Family Revision: = 1.01 <5>DAC960#0: Logical Drives: <5>DAC960#0: /dev/rd/c0d0: RAID-5, Online, 213276672 blocks, Write Thru <6>Partition check: <6> rd/c0d0: rd/c0d0p1 rd/c0d0p2 rd/c0d0p3 rd/c0d0p4 <7>ISO 9660 Extensions: RRIP_1991A <4>Unable to identify CD-ROM format. <4>VFS: Can't find ext2 filesystem on dev loop(7,0). <6>md: raid0 personality registered as nr 2 <6>md: raid1 personality registered as nr 3 <6>raid5: measuring checksumming speed <4> 8regs : 927.200 MB/sec <4> 32regs : 616.800 MB/sec <4> pII_mmx : 1571.600 MB/sec <4> p5_mmx : 1670.800 MB/sec <4>raid5: using function: p5_mmx (1670.800 MB/sec) <6>md: raid5 personality registered as nr 4 <6>Journalled Block Device driver loaded <6>SGI XFS with EAs, no debug enabled --=-5wJs2MTqXvZlAtEky+OI-- From owner-linux-xfs@oss.sgi.com Tue Jan 8 13:56:25 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g08LuP232041 for linux-xfs-outgoing; Tue, 8 Jan 2002 13:56:25 -0800 Received: from sgi.com (sgi-too.SGI.COM [204.94.211.39]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g08Lu9g32018 for ; Tue, 8 Jan 2002 13:56:09 -0800 Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id MAA05183 for ; Tue, 8 Jan 2002 12:53:59 -0800 (PST) mail_from (lord@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id OAA3982042; Tue, 8 Jan 2002 14:54:50 -0600 (CST) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id OAA59677; Tue, 8 Jan 2002 14:54:50 -0600 (CST) Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id g08Ks0b27685; Tue, 8 Jan 2002 14:54:00 -0600 Subject: Re: "No such file or directory" (still) (was Re: file corruption during emacs build on XFS logical volume From: Steve Lord To: Dan Hollis Cc: "Ralf G. R. Bergs" , Linux XFS In-Reply-To: References: Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/1.0.0.99+cvs.2001.12.18.08.57 (Preview Release) Date: 08 Jan 2002 14:54:00 -0600 Message-Id: <1010523240.27214.55.camel@jen.americas.sgi.com> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 4889 Lines: 146 On Tue, 2002-01-08 at 14:08, Dan Hollis wrote: > On 8 Jan 2002, Steve Lord wrote: > > Hmm, I suspect it is not the same problem - but let me guess, this is > > the system where you cannot run xfs_repair since there is no other > > disk, or device present? > > Yes > > > Could you try what Ralf did, run xfs_db -r on the device (will work > > on a mounted fs). Then run the blockget -n command - this appears to > > do some consistency checks. > > # xfs_db -r /dev/hda2 > xfs_db: blockget -n > dir 25165952 block 0 bad stale tail count 2 > dir ino 25165952 missing leaf entry for 1c9a34eb/16d > dir ino 25165952 missing leaf entry for 3366553e/97 > dir 46327620 size is 25, should be 24 > dir 58771462 bad size in entry at 6 > dir 67175607 bad size in entry at 6 > block 0/5859 type unknown not expected > disconnected inode 176237, nlink 1 > block 3/5348 type unknown not expected > disconnected inode 25243683, nlink 1 > disconnected inode 25243684, nlink 1 > disconnected inode 25243685, nlink 1 > disconnected inode 29460069, nlink 1 > disconnected inode 29460070, nlink 1 > disconnected inode 29460071, nlink 1 > disconnected inode 42106615, nlink 1 > disconnected inode 42106616, nlink 1 > disconnected inode 42106617, nlink 1 > disconnected inode 46344864, nlink 1 > disconnected inode 46344865, nlink 1 > disconnected inode 46344866, nlink 1 > disconnected inode 46344867, nlink 1 > disconnected inode 46344868, nlink 1 > disconnected inode 46344869, nlink 1 > disconnected inode 46344870, nlink 1 > disconnected inode 46344871, nlink 1 > disconnected inode 46344872, nlink 1 > disconnected inode 46344873, nlink 1 > disconnected inode 46344874, nlink 1 > disconnected inode 46344875, nlink 1 > disconnected inode 46344876, nlink 1 > disconnected inode 46344877, nlink 1 > disconnected inode 46344878, nlink 1 > disconnected inode 46344879, nlink 1 > disconnected inode 46344880, nlink 1 > disconnected inode 46344881, nlink 1 > disconnected inode 46344882, nlink 1 > disconnected inode 46344883, nlink 1 > disconnected inode 46344884, nlink 1 > disconnected inode 46344885, nlink 1 > disconnected inode 46344886, nlink 1 > disconnected inode 46344887, nlink 1 > disconnected inode 46344888, nlink 1 > disconnected inode 46344889, nlink 1 > disconnected inode 46344890, nlink 1 > disconnected inode 46344891, nlink 1 > disconnected inode 46344892, nlink 1 > disconnected inode 46344893, nlink 1 > disconnected inode 46344894, nlink 1 > disconnected inode 46344895, nlink 1 > disconnected inode 46344896, nlink 1 > disconnected inode 46344897, nlink 1 > disconnected inode 46344898, nlink 1 > disconnected inode 46344899, nlink 1 > disconnected inode 46344900, nlink 1 > disconnected inode 46344901, nlink 1 > disconnected inode 46344902, nlink 1 > disconnected inode 46344903, nlink 1 > disconnected inode 46344904, nlink 1 > disconnected inode 46344905, nlink 1 > disconnected inode 46344906, nlink 1 > disconnected inode 46344907, nlink 1 > disconnected inode 46344910, nlink 1 > disconnected inode 46344911, nlink 1 > disconnected inode 46344916, nlink 1 > disconnected inode 46326464, nlink 1 > disconnected inode 46326465, nlink 1 > disconnected inode 46205206, nlink 1 > disconnected inode 46326513, nlink 1 > disconnected inode 46326514, nlink 1 > disconnected inode 46326515, nlink 1 > disconnected inode 46326517, nlink 1 > disconnected inode 46326518, nlink 1 > disconnected inode 46326519, nlink 1 > disconnected inode 46326520, nlink 1 > disconnected inode 46326521, nlink 1 > disconnected inode 46326522, nlink 1 > disconnected inode 46326525, nlink 1 > disconnected inode 46326526, nlink 1 > disconnected inode 46326527, nlink 1 > disconnected inode 58794944, nlink 1 > disconnected inode 58794945, nlink 1 > disconnected inode 58794946, nlink 1 > disconnected inode 58794947, nlink 1 > disconnected inode 58794948, nlink 1 > disconnected inode 58794968, nlink 1 > disconnected inode 58794969, nlink 1 > disconnected inode 58794970, nlink 1 > disconnected inode 67174913, nlink 1 > disconnected inode 67174914, nlink 1 > disconnected inode 67174915, nlink 1 > disconnected inode 67174916, nlink 1 > disconnected inode 67174917, nlink 1 > disconnected inode 71470540, nlink 1 > disconnected inode 71470541, nlink 1 > disconnected inode 71470542, nlink 1 > sb_fdblocks 4808556, counted 4808560 Ugh, that's one toasty little filesystem you have there, but the corruption is not the same - in Ralf's case there was a single byte changed. If you could run the following I could see more of what has happened, but I am not sure I will be able to deduce the cause: inode 25165952 p bmap dblock 0 p inode 46327620 p inode 58771462 p Thanks Steve > > -Dan > -- > [-] Omae no subete no kichi wa ore no mono da. [-] -- Steve Lord voice: +1-651-683-3511 Principal Engineer, Filesystem Software email: lord@sgi.com From owner-linux-xfs@oss.sgi.com Tue Jan 8 14:49:58 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g08MnwW03611 for linux-xfs-outgoing; Tue, 8 Jan 2002 14:49:58 -0800 Received: from atlrel9.hp.com (atlrel9.hp.com [156.153.255.214]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g08Mnng03586 for ; Tue, 8 Jan 2002 14:49:49 -0800 Received: from xatlrelay2.atl.hp.com (xatlrelay2.atl.hp.com [15.45.89.191]) by atlrel9.hp.com (Postfix) with ESMTP id 956C5E00439; Tue, 8 Jan 2002 16:49:42 -0500 (EST) Received: from xatlbh2.atl.hp.com (xatlbh2.atl.hp.com [15.45.89.187]) by xatlrelay2.atl.hp.com (Postfix) with ESMTP id 8DE4F40009E; Tue, 8 Jan 2002 16:49:42 -0500 (EST) Received: by xatlbh2.atl.hp.com with Internet Mail Service (5.5.2653.19) id ; Tue, 8 Jan 2002 16:49:42 -0500 Message-ID: From: "ZINKEVICIUS,MATT (HP-Loveland,ex1)" To: "ZINKEVICIUS,MATT (HP-Loveland,ex1)" , "'Stephen Lord'" Cc: "'linux-xfs@oss.sgi.com'" Subject: RE: link() messes up file attributes Date: Tue, 8 Jan 2002 16:49:41 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 1884 Lines: 68 Nevermind, the fix didn't help. Occured again today :-( --Matt > -----Original Message----- > From: ZINKEVICIUS,MATT (HP-Loveland,ex1) > Sent: Monday, January 07, 2002 12:59 PM > To: 'Stephen Lord'; ZINKEVICIUS,MATT (HP-Loveland,ex1) > Cc: 'linux-xfs@oss.sgi.com' > Subject: RE: link() messes up file attributes > > > Thanks Steve! This fixed it! > > --Matt > > > -----Original Message----- > > From: Stephen Lord [mailto:lord@sgi.com] > > Sent: Saturday, January 05, 2002 12:21 PM > > To: ZINKEVICIUS,MATT (HP-Loveland,ex1) > > Cc: 'linux-xfs@oss.sgi.com' > > Subject: Re: link() messes up file attributes > > > > > > ZINKEVICIUS,MATT (HP-Loveland,ex1) wrote: > > > > >Hi gang, > > > > > >We have been running specSFSv2 (NFS benchmark) against a > > server running XFS. > > >All was well previously (kernel 2.4.14), but we recently > > checked out the XFS > > >CVS (2002-01-03) and it now fails. The test fails a part of > > the validation > > >stage which does the following steps: > > > > > >1) Create a file (file1) with permissions 666 > > >2) Create a hardlinked file (file2) to file1 > > >3) Check that permissions of file1 are still 666 > > > > > >Step 3 now fails as file1 now has 644 permissions! Using the > > same kernel we > > >tried ext2 instead and everything behaved normally. If > > anybody wants anymore > > >detail just let me know. > > > > > >Matt Zinkevicius > > >Software Engineer > > >Network Storage Array Solutions > > >Hewlett-Packard > > > > > Can you try this: > > > > Edit fs/xfs/linux/xfs_super.c and comment out these lines: > > > > > > fh_to_dentry: linvfs_fh_to_dentry, > > dentry_to_fh: linvfs_dentry_to_fh, > > > > At around line 907 and try again. I doubt it will fix it, but it is > > worth a shot. > > This will change the calls NFS uses to interact with XFS. > > > > Steve > > > > > From owner-linux-xfs@oss.sgi.com Tue Jan 8 14:59:17 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g08MxHX03885 for linux-xfs-outgoing; Tue, 8 Jan 2002 14:59:17 -0800 Received: from zok.sgi.com (zok.sgi.com [204.94.215.101]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g08MxDg03863 for ; Tue, 8 Jan 2002 14:59:13 -0800 Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by zok.sgi.com (8.11.4/8.11.4/linux-outbound_gateway-1.1) with ESMTP id g08Lx6A00364 for ; Tue, 8 Jan 2002 13:59:06 -0800 Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id PAA4037828; Tue, 8 Jan 2002 15:57:50 -0600 (CST) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id PAA32429; Tue, 8 Jan 2002 15:57:49 -0600 (CST) Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id g08Lux928831; Tue, 8 Jan 2002 15:56:59 -0600 Subject: RE: link() messes up file attributes From: Steve Lord To: "ZINKEVICIUS,MATT ""(HP-Loveland,ex1)" Cc: linux-xfs@oss.sgi.com In-Reply-To: References: Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/1.0.0.99+cvs.2001.12.18.08.57 (Preview Release) Date: 08 Jan 2002 15:56:59 -0600 Message-Id: <1010527019.26708.64.camel@jen.americas.sgi.com> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 603 Lines: 19 On Tue, 2002-01-08 at 15:49, ZINKEVICIUS,MATT (HP-Loveland,ex1) wrote: > Nevermind, the fix didn't help. Occured again today :-( Right, I am not totally surprised, the difference between the two code paths should be a noop. This was just the only recent change related to xfs. I suppose you have HP clients on the other end of the wire here? Since this is an intermittent problem, how can you be totally sure it is actually XFS which is at fault? Steve -- Steve Lord voice: +1-651-683-3511 Principal Engineer, Filesystem Software email: lord@sgi.com From owner-linux-xfs@oss.sgi.com Tue Jan 8 15:08:11 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g08N8BL04208 for linux-xfs-outgoing; Tue, 8 Jan 2002 15:08:11 -0800 Received: from sgi.com (sgi-too.SGI.COM [204.94.211.39]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g08N6bg04157 for ; Tue, 8 Jan 2002 15:06:37 -0800 Received: from sasami.anime.net (anime.net [63.172.78.150]) by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id OAA01483 for ; Tue, 8 Jan 2002 14:04:26 -0800 (PST) mail_from (goemon@anime.net) Received: from localhost (goemon@localhost) by sasami.anime.net (8.11.6/8.11.6) with ESMTP id g08LkHD09650; Tue, 8 Jan 2002 13:46:17 -0800 Date: Tue, 8 Jan 2002 13:46:16 -0800 (PST) From: Dan Hollis To: Steve Lord cc: "Ralf G. R. Bergs" , Linux XFS Subject: Re: "No such file or directory" (still) (was Re: file corruption during emacs build on XFS logical volume In-Reply-To: <1010523240.27214.55.camel@jen.americas.sgi.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 21964 Lines: 924 On 8 Jan 2002, Steve Lord wrote: > inode 25165952 > p > bmap > dblock 0 > p # xfs_db -r /dev/hda2 xfs_db: inode 25165952 xfs_db: p core.magic = 0x494e core.mode = 040755 core.version = 1 core.format = 2 (extents) core.nlinkv1 = 28 core.uid = 0 core.gid = 0 core.atime.sec = Tue Jan 8 12:02:19 2002 core.atime.nsec = 231237000 core.mtime.sec = Wed Dec 5 03:47:25 2001 core.mtime.nsec = 000000000 core.ctime.sec = Mon Jan 7 13:13:05 2002 core.ctime.nsec = 241237000 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 = 0 next_unlinked = null u.bmx[0] = [startoff,startblock,blockcount,extentflag] 0:[0,1573061,1,0] xfs_db: bmap data offset 0 startblock 1573061 (6/197) count 1 flag 0 xfs_db: dblock 0 xfs_db: p bhdr.magic = 0x58443242 bhdr.bestfree[0].offset = 0xbc0 bhdr.bestfree[0].length = 0x20 bhdr.bestfree[1].offset = 0x5a8 bhdr.bestfree[1].length = 0x18 bhdr.bestfree[2].offset = 0x6c0 bhdr.bestfree[2].length = 0x18 bu[0].inumber = 25165952 bu[0].namelen = 1 bu[0].name = "." bu[0].tag = 0x10 bu[1].inumber = 128 bu[1].namelen = 2 bu[1].name = ".." bu[1].tag = 0x20 bu[2].inumber = 29360256 bu[2].namelen = 9 bu[2].name = "sysconfig" bu[2].tag = 0x30 bu[3].inumber = 37748864 bu[3].namelen = 3 bu[3].name = "X11" bu[3].tag = 0x48 bu[4].inumber = 25166050 bu[4].namelen = 7 bu[4].name = "mailcap" bu[4].tag = 0x58 bu[5].inumber = 25166051 bu[5].namelen = 10 bu[5].name = "mime.types" bu[5].tag = 0x70 bu[6].inumber = 25166052 bu[6].namelen = 14 bu[6].name = "redhat-release" bu[6].tag = 0x88 bu[7].inumber = 25166053 bu[7].namelen = 9 bu[7].name = "csh.cshrc" bu[7].tag = 0xa8 bu[8].inumber = 25166054 bu[8].namelen = 9 bu[8].name = "csh.login" bu[8].tag = 0xc0 bu[9].inumber = 25166055 bu[9].namelen = 7 bu[9].name = "exports" bu[9].tag = 0xd8 bu[10].inumber = 25166056 bu[10].namelen = 11 bu[10].name = "filesystems" bu[10].tag = 0xf0 bu[11].inumber = 25166063 bu[11].namelen = 5 bu[11].name = "group" bu[11].tag = 0x108 bu[12].inumber = 25166058 bu[12].namelen = 9 bu[12].name = "host.conf" bu[12].tag = 0x118 bu[13].inumber = 25166059 bu[13].namelen = 11 bu[13].name = "hosts.allow" bu[13].tag = 0x130 bu[14].inumber = 25166060 bu[14].namelen = 10 bu[14].name = "hosts.deny" bu[14].tag = 0x148 bu[15].inumber = 25166061 bu[15].namelen = 7 bu[15].name = "inputrc" bu[15].tag = 0x160 bu[16].inumber = 25166062 bu[16].namelen = 4 bu[16].name = "motd" bu[16].tag = 0x178 bu[17].inumber = 25189727 bu[17].namelen = 6 bu[17].name = "passwd" bu[17].tag = 0x188 bu[18].inumber = 25166064 bu[18].namelen = 8 bu[18].name = "printcap" bu[18].tag = 0x1a0 bu[19].inumber = 25166065 bu[19].namelen = 7 bu[19].name = "profile" bu[19].tag = 0x1b8 bu[20].inumber = 4198276 bu[20].namelen = 9 bu[20].name = "profile.d" bu[20].tag = 0x1d0 bu[21].inumber = 25166066 bu[21].namelen = 9 bu[21].name = "protocols" bu[21].tag = 0x1e8 bu[22].inumber = 25166067 bu[22].namelen = 9 bu[22].name = "securetty" bu[22].tag = 0x200 bu[23].inumber = 25166068 bu[23].namelen = 8 bu[23].name = "services" bu[23].tag = 0x218 bu[24].inumber = 25166069 bu[24].namelen = 3 bu[24].name = "opt" bu[24].tag = 0x230 bu[25].inumber = 29361984 bu[25].namelen = 4 bu[25].name = "skel" bu[25].tag = 0x240 bu[26].inumber = 33559972 bu[26].namelen = 8 bu[26].name = "xinetd.d" bu[26].tag = 0x250 bu[27].inumber = 25166073 bu[27].namelen = 10 bu[27].name = "ld.so.conf" bu[27].tag = 0x268 bu[28].inumber = 25166074 bu[28].namelen = 9 bu[28].name = "localtime" bu[28].tag = 0x280 bu[29].inumber = 25166075 bu[29].namelen = 13 bu[29].name = "nsswitch.conf" bu[29].tag = 0x298 bu[30].inumber = 25166076 bu[30].namelen = 3 bu[30].name = "rpc" bu[30].tag = 0x2b0 bu[31].freetag = 0xffff bu[31].length = 0x18 bu[31].tag = 0x2c0 bu[32].inumber = 25178895 bu[32].namelen = 11 bu[32].name = "ld.so.cache" bu[32].tag = 0x2d8 bu[33].inumber = 25166078 bu[33].namelen = 7 bu[33].name = "termcap" bu[33].tag = 0x2f0 bu[34].inumber = 25166079 bu[34].namelen = 6 bu[34].name = "init.d" bu[34].tag = 0x308 bu[35].inumber = 8391433 bu[35].namelen = 4 bu[35].name = "rc.d" bu[35].tag = 0x320 bu[36].inumber = 25169633 bu[36].namelen = 5 bu[36].name = "rc0.d" bu[36].tag = 0x330 bu[37].inumber = 25169634 bu[37].namelen = 5 bu[37].name = "rc1.d" bu[37].tag = 0x340 bu[38].inumber = 25169635 bu[38].namelen = 5 bu[38].name = "rc2.d" bu[38].tag = 0x350 bu[39].inumber = 25169636 bu[39].namelen = 5 bu[39].name = "rc3.d" bu[39].tag = 0x360 bu[40].inumber = 25169637 bu[40].namelen = 5 bu[40].name = "rc4.d" bu[40].tag = 0x370 bu[41].inumber = 25169638 bu[41].namelen = 5 bu[41].name = "rc5.d" bu[41].tag = 0x380 bu[42].inumber = 25169639 bu[42].namelen = 5 bu[42].name = "rc6.d" bu[42].tag = 0x390 bu[43].inumber = 25169640 bu[43].namelen = 7 bu[43].name = "mail.rc" bu[43].tag = 0x3a0 bu[44].inumber = 25169641 bu[44].namelen = 6 bu[44].name = "bashrc" bu[44].tag = 0x3b8 bu[45].inumber = 25169647 bu[45].namelen = 6 bu[45].name = "shells" bu[45].tag = 0x3d0 bu[46].inumber = 54531086 bu[46].namelen = 7 bu[46].name = "hotplug" bu[46].tag = 0x3e8 bu[47].inumber = 4199480 bu[47].namelen = 9 bu[47].name = "makedev.d" bu[47].tag = 0x400 bu[48].inumber = 12586252 bu[48].namelen = 6 bu[48].name = "cron.d" bu[48].tag = 0x418 bu[49].inumber = 25166077 bu[49].namelen = 8 bu[49].name = "info-dir" bu[49].tag = 0x430 bu[50].inumber = 25174371 bu[50].namelen = 10 bu[50].name = "DIR_COLORS" bu[50].tag = 0x448 bu[51].inumber = 25174394 bu[51].namelen = 15 bu[51].name = "pine.conf.fixed" bu[51].tag = 0x460 bu[52].inumber = 25220944 bu[52].namelen = 5 bu[52].name = "zshrc" bu[52].tag = 0x480 bu[53].freetag = 0xffff bu[53].length = 0x10 bu[53].tag = 0x490 bu[54].inumber = 67135760 bu[54].namelen = 10 bu[54].name = "cron.daily" bu[54].tag = 0x4a0 bu[55].inumber = 71313993 bu[55].namelen = 11 bu[55].name = "cron.weekly" bu[55].tag = 0x4b8 bu[56].inumber = 25174377 bu[56].namelen = 10 bu[56].name = "man.config" bu[56].tag = 0x4d0 bu[57].inumber = 25174380 bu[57].namelen = 13 bu[57].name = "minicom.users" bu[57].tag = 0x4e8 bu[58].inumber = 25174370 bu[58].namelen = 14 bu[58].name = "logrotate.conf" bu[58].tag = 0x500 bu[59].inumber = 67135782 bu[59].namelen = 11 bu[59].name = "logrotate.d" bu[59].tag = 0x520 bu[60].inumber = 25174392 bu[60].namelen = 9 bu[60].name = "pwdb.conf" bu[60].tag = 0x538 bu[61].freetag = 0xffff bu[61].length = 0x10 bu[61].tag = 0x550 bu[62].inumber = 29366617 bu[62].namelen = 7 bu[62].name = "default" bu[62].tag = 0x560 bu[63].inumber = 25174400 bu[63].namelen = 10 bu[63].name = "login.defs" bu[63].tag = 0x578 bu[64].inumber = 25220940 bu[64].namelen = 6 bu[64].name = "zlogin" bu[64].tag = 0x590 bu[65].freetag = 0xffff bu[65].length = 0x18 bu[65].tag = 0x5a8 bu[66].inumber = 25174402 bu[66].namelen = 6 bu[66].name = "group-" bu[66].tag = 0x5c0 bu[67].inumber = 25166057 bu[67].namelen = 13 bu[67].name = "updatedb.conf" bu[67].tag = 0x5d8 bu[68].inumber = 25174403 bu[68].namelen = 11 bu[68].name = "syslog.conf" bu[68].tag = 0x5f0 bu[69].inumber = 25174420 bu[69].namelen = 11 bu[69].name = "devfsd.conf" bu[69].tag = 0x608 bu[70].inumber = 25174421 bu[70].namelen = 13 bu[70].name = "modules.devfs" bu[70].tag = 0x620 bu[71].inumber = 54538331 bu[71].namelen = 11 bu[71].name = "cron.hourly" bu[71].tag = 0x638 bu[72].inumber = 58747047 bu[72].namelen = 12 bu[72].name = "cron.monthly" bu[72].tag = 0x650 bu[73].inumber = 25178887 bu[73].namelen = 7 bu[73].name = "crontab" bu[73].tag = 0x668 bu[74].inumber = 25187875 bu[74].namelen = 6 bu[74].name = "wgetrc" bu[74].tag = 0x680 bu[75].inumber = 4221526 bu[75].namelen = 5 bu[75].name = "pam.d" bu[75].tag = 0x698 bu[76].inumber = 8411407 bu[76].namelen = 8 bu[76].name = "security" bu[76].tag = 0x6a8 bu[77].freetag = 0xffff bu[77].length = 0x18 bu[77].tag = 0x6c0 bu[78].inumber = 25187882 bu[78].namelen = 9 bu[78].name = "krb5.conf" bu[78].tag = 0x6d8 bu[79].freetag = 0xffff bu[79].length = 0x18 bu[79].tag = 0x6f0 bu[80].inumber = 25187888 bu[80].namelen = 9 bu[80].name = ".pwd.lock" bu[80].tag = 0x708 bu[81].freetag = 0xffff bu[81].length = 0x18 bu[81].tag = 0x720 bu[82].inumber = 25189711 bu[82].namelen = 7 bu[82].name = "inittab" bu[82].tag = 0x738 bu[83].inumber = 25220941 bu[83].namelen = 7 bu[83].name = "zlogout" bu[83].tag = 0x750 bu[84].freetag = 0xffff bu[84].length = 0x18 bu[84].tag = 0x768 bu[85].inumber = 25187891 bu[85].namelen = 7 bu[85].name = "passwd-" bu[85].tag = 0x780 bu[86].freetag = 0xffff bu[86].length = 0x18 bu[86].tag = 0x798 bu[87].inumber = 25187921 bu[87].namelen = 5 bu[87].name = "issue" bu[87].tag = 0x7b0 bu[88].inumber = 67160737 bu[88].namelen = 4 bu[88].name = "snmp" bu[88].tag = 0x7c0 bu[89].inumber = 67158242 bu[89].namelen = 8 bu[89].name = "qpage.cf" bu[89].tag = 0x7d0 bu[90].freetag = 0xffff bu[90].length = 0x18 bu[90].tag = 0x7e8 bu[91].inumber = 71328747 bu[91].namelen = 3 bu[91].name = "rpm" bu[91].tag = 0x800 bu[92].inumber = 25187894 bu[92].namelen = 5 bu[92].name = "fdprm" bu[92].tag = 0x810 bu[93].inumber = 25187896 bu[93].namelen = 7 bu[93].name = "adjtime" bu[93].tag = 0x820 bu[94].inumber = 25187897 bu[94].namelen = 12 bu[94].name = "initlog.conf" bu[94].tag = 0x838 bu[95].freetag = 0xffff bu[95].length = 0x18 bu[95].tag = 0x850 bu[96].inumber = 25187899 bu[96].namelen = 3 bu[96].name = "ppp" bu[96].tag = 0x868 bu[97].inumber = 25187902 bu[97].namelen = 2 bu[97].name = "rc" bu[97].tag = 0x878 bu[98].inumber = 25187904 bu[98].namelen = 8 bu[98].name = "rc.local" bu[98].tag = 0x888 bu[99].inumber = 25187905 bu[99].namelen = 10 bu[99].name = "rc.sysinit" bu[99].tag = 0x8a0 bu[100].inumber = 25187906 bu[100].namelen = 11 bu[100].name = "sysctl.conf" bu[100].tag = 0x8b8 bu[101].inumber = 71341229 bu[101].namelen = 3 bu[101].name = "ssh" bu[101].tag = 0x8d0 bu[102].freetag = 0xffff bu[102].length = 0x18 bu[102].tag = 0x8e0 bu[103].inumber = 25189682 bu[103].namelen = 11 bu[103].name = "ltrace.conf" bu[103].tag = 0x8f8 bu[104].freetag = 0xffff bu[104].length = 0x18 bu[104].tag = 0x910 bu[105].inumber = 50598261 bu[105].namelen = 8 bu[105].name = "iproute2" bu[105].tag = 0x928 bu[106].inumber = 25189708 bu[106].namelen = 8 bu[106].name = "screenrc" bu[106].tag = 0x940 bu[107].inumber = 25189709 bu[107].namelen = 7 bu[107].name = "sudoers" bu[107].tag = 0x958 bu[108].inumber = 25189724 bu[108].namelen = 5 bu[108].name = "fstab" bu[108].tag = 0x970 bu[109].inumber = 25220950 bu[109].namelen = 4 bu[109].name = "mtab" bu[109].tag = 0x980 bu[110].inumber = 25189712 bu[110].namelen = 5 bu[110].name = "hosts" bu[110].tag = 0x990 bu[111].inumber = 25189713 bu[111].namelen = 11 bu[111].name = "resolv.conf" bu[111].tag = 0x9a0 bu[112].inumber = 25189714 bu[112].namelen = 9 bu[112].name = "ldap.conf" bu[112].tag = 0x9b8 bu[113].inumber = 25189715 bu[113].namelen = 7 bu[113].name = "yp.conf" bu[113].tag = 0x9d0 bu[114].inumber = 25189723 bu[114].namelen = 10 bu[114].name = "passwd.OLD" bu[114].tag = 0x9e8 bu[115].inumber = 25189725 bu[115].namelen = 12 bu[115].name = "fstab.REVOKE" bu[115].tag = 0xa00 bu[116].inumber = 25189710 bu[116].namelen = 9 bu[116].name = "issue.net" bu[116].tag = 0xa18 bu[117].inumber = 25220942 bu[117].namelen = 8 bu[117].name = "zprofile" bu[117].tag = 0xa30 bu[118].freetag = 0xffff bu[118].length = 0x18 bu[118].tag = 0xa48 bu[119].inumber = 25189024 bu[119].namelen = 6 bu[119].name = "shadow" bu[119].tag = 0xa60 bu[120].freetag = 0xffff bu[120].length = 0x18 bu[120].tag = 0xa78 bu[121].inumber = 25189717 bu[121].namelen = 10 bu[121].name = "ioctl.save" bu[121].tag = 0xa90 bu[122].inumber = 37816269 bu[122].namelen = 5 bu[122].name = "zebra" bu[122].tag = 0xaa8 bu[123].inumber = 25220951 bu[123].namelen = 12 bu[123].name = "modules.conf" bu[123].tag = 0xab8 bu[124].inumber = 25220945 bu[124].namelen = 12 bu[124].name = "sensors.conf" bu[124].tag = 0xad0 bu[125].freetag = 0xffff bu[125].length = 0x8 bu[125].tag = 0xae8 bu[126].inumber = 25187890 bu[126].namelen = 7 bu[126].name = "gshadow" bu[126].tag = 0xaf0 bu[127].inumber = 25174372 bu[127].namelen = 10 bu[127].name = "minirc.dfl" bu[127].tag = 0xb08 bu[128].inumber = 25174376 bu[128].namelen = 9 bu[128].name = "pine.conf" bu[128].tag = 0xb20 bu[129].inumber = 25220943 bu[129].namelen = 6 bu[129].name = "zshenv" bu[129].tag = 0xb38 bu[130].freetag = 0xffff bu[130].length = 0x18 bu[130].tag = 0xb50 bu[131].inumber = 25189719 bu[131].namelen = 7 bu[131].name = "shadow-" bu[131].tag = 0xb68 bu[132].inumber = 79789912 bu[132].namelen = 3 bu[132].name = "ntp" bu[132].tag = 0xb80 bu[133].inumber = 25189726 bu[133].namelen = 8 bu[133].name = "ntp.conf" bu[133].tag = 0xb90 bu[134].inumber = 25220936 bu[134].namelen = 10 bu[134].name = "dhcpd.conf" bu[134].tag = 0xba8 bu[135].freetag = 0xffff bu[135].length = 0x20 bu[135].tag = 0xbc0 bu[136].inumber = 25189718 bu[136].namelen = 8 bu[136].name = "gshadow-" bu[136].tag = 0xbe0 bu[137].inumber = 25220952 bu[137].namelen = 9 bu[137].name = "lilo.conf" bu[137].tag = 0xbf8 bu[138].inumber = 33612136 bu[138].namelen = 4 bu[138].name = "uucp" bu[138].tag = 0xc10 bleaf[0].hashval = 0x2e bleaf[0].address = 0x2 bleaf[1].hashval = 0x172e bleaf[1].address = 0x4 bleaf[2].hashval = 0x3963 bleaf[2].address = 0x10f bleaf[3].hashval = 0x1618b1 bleaf[3].address = 0x9 bleaf[4].hashval = 0x1bba70 bleaf[4].address = 0x170 bleaf[5].hashval = 0x1bf874 bleaf[5].address = 0x46 bleaf[6].hashval = 0x1c3870 bleaf[6].address = 0x10d bleaf[7].hashval = 0x1cb863 bleaf[7].address = 0x56 bleaf[8].hashval = 0x1cb86d bleaf[8].address = 0x100 bleaf[9].hashval = 0x1cf9e8 bleaf[9].address = 0x11a bleaf[10].hashval = 0xcbfdb0 bleaf[10].address = 0xca bleaf[11].hashval = 0x1bfa833 bleaf[11].address = 0x152 bleaf[12].hashval = 0x37c04df bleaf[12].address = 0x53 bleaf[13].hashval = 0xc3b5763 bleaf[13].address = 0xd3 bleaf[14].hashval = 0xdbbfa64 bleaf[14].address = 0x2f bleaf[15].hashval = 0xdbd30e2 bleaf[15].address = 0x130 bleaf[16].hashval = 0xdfd2db4 bleaf[16].address = 0x1b bleaf[17].hashval = 0xe58d764 bleaf[17].address = 0x64 bleaf[18].hashval = 0xe7af2ec bleaf[18].address = 0x48 bleaf[19].hashval = 0xe7bb6f0 bleaf[19].address = 0xf8 bleaf[20].hashval = 0xebc9e14 bleaf[20].address = 0x2c bleaf[21].hashval = 0xebd71f0 bleaf[21].address = 0x182 bleaf[22].hashval = 0x12df5221 bleaf[22].address = 0x5b bleaf[23].hashval = 0x18af73e8 bleaf[23].address = 0x107 bleaf[24].hashval = 0x1ab62176 bleaf[24].address = 0xc1 bleaf[25].hashval = 0x1c050fcf bleaf[25].address = 0x9a bleaf[26].hashval = 0x1c5434eb bleaf[26].address = 0x17c bleaf[27].hashval = 0x1c5e2b17 bleaf[27].address = 0 bleaf[28].hashval = 0x1e7a3a75 bleaf[28].address = 0x77 bleaf[29].hashval = 0x1e7cf862 bleaf[29].address = 0x31 bleaf[30].hashval = 0x1fa254a0 bleaf[30].address = 0xbe bleaf[31].hashval = 0x1fa45866 bleaf[31].address = 0x134 bleaf[32].hashval = 0x1fbc38f8 bleaf[32].address = 0x117 bleaf[33].hashval = 0x1fee7d44 bleaf[33].address = 0xbb bleaf[34].hashval = 0x217e384a bleaf[34].address = 0x80 bleaf[35].hashval = 0x243429c2 bleaf[35].address = 0x13d bleaf[36].hashval = 0x2c6c1763 bleaf[36].address = 0x66 bleaf[37].hashval = 0x2c6c5763 bleaf[37].address = 0x68 bleaf[38].hashval = 0x2c6c9763 bleaf[38].address = 0x6a bleaf[39].hashval = 0x2c6cd763 bleaf[39].address = 0x6c bleaf[40].hashval = 0x2c6d1763 bleaf[40].address = 0x6e bleaf[41].hashval = 0x2c6d5763 bleaf[41].address = 0x70 bleaf[42].hashval = 0x2c6d9763 bleaf[42].address = 0x72 bleaf[43].hashval = 0x2db923df bleaf[43].address = 0x5e bleaf[44].hashval = 0x2dfb947b bleaf[44].address = 0x83 bleaf[45].hashval = 0x2dfd7b12 bleaf[45].address = 0xb8 bleaf[46].hashval = 0x2f178bbe bleaf[46].address = 0 bleaf[47].hashval = 0x3b1b83ab bleaf[47].address = 0x140 bleaf[48].hashval = 0x3c3c7d5a bleaf[48].address = 0x143 bleaf[49].hashval = 0x3d1974a1 bleaf[49].address = 0x167 bleaf[50].hashval = 0x3e7c3122 bleaf[50].address = 0xf0 bleaf[51].hashval = 0x4df8b6dd bleaf[51].address = 0x12b bleaf[52].hashval = 0x4e1a9998 bleaf[52].address = 0x7d bleaf[53].hashval = 0x5c5c36f5 bleaf[53].address = 0x128 bleaf[54].hashval = 0x5d9d9815 bleaf[54].address = 0x15 bleaf[55].hashval = 0x5e667b02 bleaf[55].address = 0x114 bleaf[56].hashval = 0x5e68b012 bleaf[56].address = 0x4a bleaf[57].hashval = 0x5ebded66 bleaf[57].address = 0xd5 bleaf[58].hashval = 0x5f76b5d6 bleaf[58].address = 0x40 bleaf[59].hashval = 0x6c3ce55a bleaf[59].address = 0xac bleaf[60].hashval = 0x6c9c396b bleaf[60].address = 0x102 bleaf[61].hashval = 0x6ddf6564 bleaf[61].address = 0x43 bleaf[62].hashval = 0x6e7d30e4 bleaf[62].address = 0x12e bleaf[63].hashval = 0x7c4872e8 bleaf[63].address = 0xfa bleaf[64].hashval = 0x7cbd3add bleaf[64].address = 0xd0 bleaf[65].hashval = 0x7e44d8f8 bleaf[65].address = 0xa0 bleaf[66].hashval = 0x7e5bfaf6 bleaf[66].address = 0x21 bleaf[67].hashval = 0x80a8441c bleaf[67].address = 0x17f bleaf[68].hashval = 0x80b270e4 bleaf[68].address = 0x137 bleaf[69].hashval = 0x8356d437 bleaf[69].address = 0xaf bleaf[70].hashval = 0x837ea4d7 bleaf[70].address = 0x29 bleaf[71].hashval = 0x84a438c4 bleaf[71].address = 0x23 bleaf[72].hashval = 0x84bc3476 bleaf[72].address = 0x175 bleaf[73].hashval = 0x879e7ecc bleaf[73].address = 0xdb bleaf[74].hashval = 0x8826382a bleaf[74].address = 0x4d bleaf[75].hashval = 0x8ba59c24 bleaf[75].address = 0 bleaf[76].hashval = 0x8c38a869 bleaf[76].address = 0x15e bleaf[77].hashval = 0x8c393469 bleaf[77].address = 0x14c bleaf[78].hashval = 0x8c9e49d5 bleaf[78].address = 0x3d bleaf[79].hashval = 0x8cbb35ed bleaf[79].address = 0x7a bleaf[80].hashval = 0x8dfcfa75 bleaf[80].address = 0x132 bleaf[81].hashval = 0x8e2a7bf9 bleaf[81].address = 0x6 bleaf[82].hashval = 0x916015c6 bleaf[82].address = 0xc7 bleaf[83].hashval = 0x99afdb0e bleaf[83].address = 0x157 bleaf[84].hashval = 0x9c946474 bleaf[84].address = 0xa7 bleaf[85].hashval = 0x9ca84c4c bleaf[85].address = 0x164 bleaf[86].hashval = 0x9d8a0e6d bleaf[86].address = 0x74 bleaf[87].hashval = 0x9d9947fe bleaf[87].address = 0xb bleaf[88].hashval = 0x9e7cfae3 bleaf[88].address = 0xf6 bleaf[89].hashval = 0x9e9c9794 bleaf[89].address = 0xe7 bleaf[90].hashval = 0x9eb86376 bleaf[90].address = 0x11f bleaf[91].hashval = 0x9faa458b bleaf[91].address = 0x15a bleaf[92].hashval = 0xa245f9eb bleaf[92].address = 0x50 bleaf[93].hashval = 0xa6ab873f bleaf[93].address = 0xc4 bleaf[94].hashval = 0xa6e7a7b2 bleaf[94].address = 0xe bleaf[95].hashval = 0xacb8b966 bleaf[95].address = 0x155 bleaf[96].hashval = 0xae1e5598 bleaf[96].address = 0x18 bleaf[97].hashval = 0xae7a3964 bleaf[97].address = 0x90 bleaf[98].hashval = 0xae9bf1c3 bleaf[98].address = 0x104 bleaf[99].hashval = 0xaebf28f8 bleaf[99].address = 0x11 bleaf[100].hashval = 0xb036976d bleaf[100].address = 0x89 bleaf[101].hashval = 0xbb7bf7b0 bleaf[101].address = 0x9d bleaf[102].hashval = 0xbee5cf3e bleaf[102].address = 0x94 bleaf[103].hashval = 0xc37a2ec9 bleaf[103].address = 0xe1 bleaf[104].hashval = 0xcc0f01e0 bleaf[104].address = 0x8c bleaf[105].hashval = 0xcd1d7d9a bleaf[105].address = 0x111 bleaf[106].hashval = 0xcdf9f738 bleaf[106].address = 0xb2 bleaf[107].hashval = 0xd252a088 bleaf[107].address = 0x1e bleaf[108].hashval = 0xdc0494cc bleaf[108].address = 0x161 bleaf[109].hashval = 0xde987178 bleaf[109].address = 0 bleaf[110].hashval = 0xec7a10e4 bleaf[110].address = 0x13a bleaf[111].hashval = 0xeca624e4 bleaf[111].address = 0x172 bleaf[112].hashval = 0xed3d142a bleaf[112].address = 0x61 bleaf[113].hashval = 0xed7ce852 bleaf[113].address = 0x3a bleaf[114].hashval = 0xee72e0b6 bleaf[114].address = 0x26 bleaf[115].hashval = 0xee793bbe bleaf[115].address = 0x34 bleaf[116].hashval = 0xf56a8fc4 bleaf[116].address = 0x86 bleaf[117].hashval = 0xf97cf3f5 bleaf[117].address = 0xa4 bleaf[118].hashval = 0xfc2fb5f3 bleaf[118].address = 0x146 bleaf[119].hashval = 0xfcdbb5f3 bleaf[119].address = 0x37 bleaf[120].hashval = 0xfcfa1192 bleaf[120].address = 0xea bleaf[121].hashval = 0xfddcbf74 bleaf[121].address = 0xcd bleaf[122].hashval = 0xfe6ef124 bleaf[122].address = 0x125 btail.count = 123 btail.stale = 2 > inode 46327620 > p xfs_db: inode 46327620 xfs_db: p core.magic = 0x494e core.mode = 040755 core.version = 1 core.format = 1 (local) core.nlinkv1 = 4 core.uid = 500 core.gid = 500 core.atime.sec = Tue Jan 8 11:56:18 2002 core.atime.nsec = 611237000 core.mtime.sec = Wed Dec 5 03:40:56 2001 core.mtime.nsec = 731061000 core.ctime.sec = Wed Dec 5 03:40:56 2001 core.ctime.nsec = 731061000 core.size = 25 core.nblocks = 0 core.extsize = 0 core.nextents = 0 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 = 5 next_unlinked = null u.sfdir2.hdr.count = 2 u.sfdir2.hdr.i8count = 0 u.sfdir2.hdr.parent.i4 = 8391432 u.sfdir2.list[0].namelen = 2 u.sfdir2.list[0].offset = 0x48 u.sfdir2.list[0].name = "fs" u.sfdir2.list[0].inumber.i4 = 50839628 u.sfdir2.list[1].namelen = 2 u.sfdir2.list[1].offset = 0x90 u.sfdir2.list[1].name = "mm" u.sfdir2.list[1].inumber.i4 = 67175607 > inode 58771462 > p xfs_db: inode 58771462 xfs_db: p core.magic = 0x494e core.mode = 040755 core.version = 1 core.format = 1 (local) core.nlinkv1 = 2 core.uid = 500 core.gid = 500 core.atime.sec = Tue Jan 8 11:56:18 2002 core.atime.nsec = 611237000 core.mtime.sec = Wed Dec 5 03:40:56 2001 core.mtime.nsec = 661061000 core.ctime.sec = Wed Dec 5 03:40:56 2001 core.ctime.nsec = 661061000 core.size = 22 core.nblocks = 0 core.extsize = 0 core.nextents = 0 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 = 3 next_unlinked = null u.sfdir2.hdr.count = 1 u.sfdir2.hdr.i8count = 0 u.sfdir2.hdr.parent.i4 = 50839628 u.sfdir2.list[0].namelen = 14 u.sfdir2.list[0].offset = 0x338 u.sfdir2.list[0].name = ".kcore.o.flag\021" u.sfdir2.list[0].inumber.i4 = 234983470 -Dan -- [-] Omae no subete no kichi wa ore no mono da. [-] From owner-linux-xfs@oss.sgi.com Tue Jan 8 15:17:36 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g08NHaf04501 for linux-xfs-outgoing; Tue, 8 Jan 2002 15:17:36 -0800 Received: from palrel13.hp.com (palrel13.hp.com [156.153.255.238]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g08NHVg04478 for ; Tue, 8 Jan 2002 15:17:31 -0800 Received: from xparelay1.corp.hp.com (xparelay1.corp.hp.com [15.58.136.173]) by palrel13.hp.com (Postfix) with ESMTP id ED90CE002DC; Tue, 8 Jan 2002 14:17:24 -0800 (PST) Received: from xpabh3.corp.hp.com (xpabh3.corp.hp.com [15.58.136.223]) by xparelay1.corp.hp.com (Postfix) with ESMTP id D1B7F6000A5; Tue, 8 Jan 2002 14:17:24 -0800 (PST) Received: by xpabh3.corp.hp.com with Internet Mail Service (5.5.2653.19) id ; Tue, 8 Jan 2002 14:17:24 -0800 Message-ID: From: "ZINKEVICIUS,MATT (HP-Loveland,ex1)" To: "'Steve Lord'" Cc: linux-xfs@oss.sgi.com Subject: RE: link() messes up file attributes Date: Tue, 8 Jan 2002 14:17:15 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 1213 Lines: 36 Linux clients. The problem seemed to go away for a while but now it fails everytime in the exact same way, so I wouldn't call it intermittent. Ext2 and older XFS kernels have not a had a failure after hundreds of runs, but we'll keep trying. Maybe this is related to the other metadata corruptions that are being discussed? --Matt > -----Original Message----- > From: Steve Lord [mailto:lord@sgi.com] > Sent: Tuesday, January 08, 2002 2:57 PM > To: ZINKEVICIUS,MATT " "(HP-Loveland,ex1) > Cc: linux-xfs@oss.sgi.com > Subject: RE: link() messes up file attributes > > > On Tue, 2002-01-08 at 15:49, ZINKEVICIUS,MATT (HP-Loveland,ex1) wrote: > > Nevermind, the fix didn't help. Occured again today :-( > > Right, I am not totally surprised, the difference between the two > code paths should be a noop. This was just the only recent change > related to xfs. > > I suppose you have HP clients on the other end of the wire here? > > Since this is an intermittent problem, how can you be totally sure > it is actually XFS which is at fault? > > Steve > > -- > > Steve Lord voice: +1-651-683-3511 > Principal Engineer, Filesystem Software email: lord@sgi.com > From owner-linux-xfs@oss.sgi.com Tue Jan 8 17:40:20 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g091eKo10495 for linux-xfs-outgoing; Tue, 8 Jan 2002 17:40:20 -0800 Received: from sunfish.linuxis.net (sunfish.linuxis.net [64.71.162.66]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g091eEg10466 for ; Tue, 8 Jan 2002 17:40:14 -0800 Received: (qmail 19145 invoked by uid 1000); 9 Jan 2002 00:33:24 -0000 Date: Tue, 8 Jan 2002 16:33:23 -0800 To: linux-xfs@oss.sgi.com Subject: Anyone know what this error means? Message-ID: <20020109003323.GW4511@flounder.net> 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.3.25i X-Delivery-Agent: TMDA v0.42/Python 2.1.1 (sunos5) From: "Adam McKenna" Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 1602 Lines: 48 This is an approx. 270 Gig RAID5 partition on an AMI Megaraid card on 2.2.14-xfs (snapshot).. I get the following error when trying to create the filesystem: adam@braindb:~$ sudo mkfs.xfs -f /dev/sda9 mkfs.xfs: warning - cannot set blocksize on block device /dev/sda9: Invalid argument meta-data=/dev/sda9 isize=256 agcount=65, agsize=1048576 blks data = bsize=4096 blocks=67782243, imaxpct=25 = sunit=0 swidth=0 blks, unwritten=0 naming =version 2 bsize=4096 log =internal log bsize=4096 blocks=8274 realtime =none extsz=65536 blocks=0, rtextents=0 File size limit exceeded The same thing happens if I try ext2: adam@braindb:~$ sudo mke2fs /dev/sda9 mke2fs 1.22, 22-Jun-2001 for EXT2 FS 0.5b, 95/08/09 Filesystem label= OS type: Linux Block size=4096 (log=2) Fragment size=4096 (log=2) 33898496 inodes, 67782243 blocks 3389112 blocks (5.00%) reserved for the super user First data block=0 2069 block groups 32768 blocks per group, 32768 fragments per group 16384 inodes per group Superblock backups stored on blocks: 32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632, 2654208, 4096000, 7962624, 11239424, 20480000, 23887872 File size limit exceeded adam@braindb:~$ uname -a Linux braindb 2.4.14-xfs #3 SMP Fri Nov 30 01:58:14 PST 2001 i686 unknown Anyone know what is going on here? --Adam -- Adam McKenna | GPG: 17A4 11F7 5E7E C2E7 08AA http://flounder.net/publickey.html | 38B0 05D0 8BF7 2C6D 110A From owner-linux-xfs@oss.sgi.com Tue Jan 8 17:46:48 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g091kmf10742 for linux-xfs-outgoing; Tue, 8 Jan 2002 17:46:48 -0800 Received: from palrel11.hp.com (palrel11.hp.com [156.153.255.246]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g091kgg10720 for ; Tue, 8 Jan 2002 17:46:42 -0800 Received: from xparelay2.corp.hp.com (xparelay2.corp.hp.com [15.58.137.112]) by palrel11.hp.com (Postfix) with ESMTP id 06F75E0028F; Tue, 8 Jan 2002 16:46:34 -0800 (PST) Received: from xpabh4.corp.hp.com (xpabh4.corp.hp.com [15.58.136.1]) by xparelay2.corp.hp.com (Postfix) with ESMTP id 12D74400098; Tue, 8 Jan 2002 16:46:00 -0800 (PST) Received: by xpabh4.corp.hp.com with Internet Mail Service (5.5.2653.19) id ; Tue, 8 Jan 2002 16:46:33 -0800 Message-ID: From: "ZINKEVICIUS,MATT (HP-Loveland,ex1)" To: "'Steve Lord'" Cc: linux-xfs@oss.sgi.com Subject: RE: link() messes up file attributes Date: Tue, 8 Jan 2002 16:46:31 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 1213 Lines: 44 Okay here is the current situation... Without your patch: over NFSv2: open new file with 666 permission creates file with 644 permissions over NFSv3: open new file works fine, but hard-linking changes file perm to 644 With your path: over NFSv2: (same as above) over NFSv3: Works fine So you patch does have some affect. --Matt > -----Original Message----- > From: Steve Lord [mailto:lord@sgi.com] > Sent: Tuesday, January 08, 2002 2:57 PM > To: ZINKEVICIUS,MATT " "(HP-Loveland,ex1) > Cc: linux-xfs@oss.sgi.com > Subject: RE: link() messes up file attributes > > > On Tue, 2002-01-08 at 15:49, ZINKEVICIUS,MATT (HP-Loveland,ex1) wrote: > > Nevermind, the fix didn't help. Occured again today :-( > > Right, I am not totally surprised, the difference between the two > code paths should be a noop. This was just the only recent change > related to xfs. > > I suppose you have HP clients on the other end of the wire here? > > Since this is an intermittent problem, how can you be totally sure > it is actually XFS which is at fault? > > Steve > > -- > > Steve Lord voice: +1-651-683-3511 > Principal Engineer, Filesystem Software email: lord@sgi.com > From owner-linux-xfs@oss.sgi.com Tue Jan 8 17:54:34 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g091sYn10944 for linux-xfs-outgoing; Tue, 8 Jan 2002 17:54:34 -0800 Received: from deliverator.sgi.com (deliverator.sgi.com [204.94.214.10]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g091sVg10922 for ; Tue, 8 Jan 2002 17:54:31 -0800 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via SMTP id QAA25819 for ; Tue, 8 Jan 2002 16:54:14 -0800 (PST) mail_from (nathans@wobbly.melbourne.sgi.com) Received: from wobbly.melbourne.sgi.com (wobbly.melbourne.sgi.com [134.14.55.135]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id LAA09638; Wed, 9 Jan 2002 11:53:10 +1100 Received: (from nathans@localhost) by wobbly.melbourne.sgi.com (SGI-8.9.3/8.9.3) id LAA03261; Wed, 9 Jan 2002 11:53:09 +1100 (AEDT) Date: Wed, 9 Jan 2002 11:53:09 +1100 From: Nathan Scott To: Adam McKenna Cc: linux-xfs@oss.sgi.com Subject: Re: Anyone know what this error means? Message-ID: <20020109115309.A3063@wobbly.melbourne.sgi.com> References: <20020109003323.GW4511@flounder.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20020109003323.GW4511@flounder.net>; from adam-dated-1010968404.3db79f@flounder.net on Tue, Jan 08, 2002 at 04:33:23PM -0800 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 426 Lines: 17 On Tue, Jan 08, 2002 at 04:33:23PM -0800, Adam McKenna wrote: > This is an approx. 270 Gig RAID5 partition on an AMI Megaraid card on > 2.2.14-xfs (snapshot).. > > I get the following error when trying to create the filesystem: > ... > File size limit exceeded > [assuming 2.4.14] - sounds familiar, think it was a bug from Linus' kernel; using a more recent kernel version (2.4.16/17) should fix it. cheers. -- Nathan From owner-linux-xfs@oss.sgi.com Tue Jan 8 17:56:28 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g091uS211137 for linux-xfs-outgoing; Tue, 8 Jan 2002 17:56:28 -0800 Received: from sunfish.linuxis.net (sunfish.linuxis.net [64.71.162.66]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g091uLg11115 for ; Tue, 8 Jan 2002 17:56:21 -0800 Received: (qmail 20281 invoked by uid 1000); 9 Jan 2002 00:49:49 -0000 Date: Tue, 8 Jan 2002 16:49:49 -0800 To: linux-xfs@oss.sgi.com Subject: Re: Anyone know what this error means? Message-ID: <20020109004949.GX4511@flounder.net> Mail-Followup-To: linux-xfs@oss.sgi.com References: <20020109003323.GW4511@flounder.net> <20020109115309.A3063@wobbly.melbourne.sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20020109115309.A3063@wobbly.melbourne.sgi.com> User-Agent: Mutt/1.3.25i X-Delivery-Agent: TMDA v0.42/Python 2.1.1 (sunos5) From: "Adam McKenna" Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 1915 Lines: 54 On Wed, Jan 09, 2002 at 11:53:09AM +1100, Nathan Scott wrote: > On Tue, Jan 08, 2002 at 04:33:23PM -0800, Adam McKenna wrote: > > This is an approx. 270 Gig RAID5 partition on an AMI Megaraid card on > > 2.2.14-xfs (snapshot).. > > > > I get the following error when trying to create the filesystem: > > ... > > File size limit exceeded > > > > [assuming 2.4.14] - sounds familiar, think it was a bug from Linus' > kernel; using a more recent kernel version (2.4.16/17) should fix it. Hmm. adam@braindb:~$ uname -a Linux braindb 2.4.16-xfs #1 SMP Tue Dec 18 16:01:35 PST 2001 i686 unknown adam@braindb:~$ sudo mkfs.xfs -f /dev/sda9 mkfs.xfs: warning - cannot set blocksize on block device /dev/sda9: Invalid argument meta-data=/dev/sda9 isize=256 agcount=65, agsize=1048576 blks data = bsize=4096 blocks=67782243, imaxpct=25 = sunit=0 swidth=0 blks, unwritten=0 naming =version 2 bsize=4096 log =internal log bsize=4096 blocks=8274 realtime =none extsz=65536 blocks=0, rtextents=0 File size limit exceeded adam@braindb:~$ sudo mke2fs /dev/sda9 mke2fs 1.22, 22-Jun-2001 for EXT2 FS 0.5b, 95/08/09 Filesystem label= OS type: Linux Block size=4096 (log=2) Fragment size=4096 (log=2) 33898496 inodes, 67782243 blocks 3389112 blocks (5.00%) reserved for the super user First data block=0 2069 block groups 32768 blocks per group, 32768 fragments per group 16384 inodes per group Superblock backups stored on blocks: 32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632, 2654208, 4096000, 7962624, 11239424, 20480000, 23887872 File size limit exceeded Any other ideas? Should I take this to linux-kernel? --Adam -- Adam McKenna | GPG: 17A4 11F7 5E7E C2E7 08AA http://flounder.net/publickey.html | 38B0 05D0 8BF7 2C6D 110A From owner-linux-xfs@oss.sgi.com Tue Jan 8 18:02:21 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0922Ls11396 for linux-xfs-outgoing; Tue, 8 Jan 2002 18:02:21 -0800 Received: from mail.caramail.com (mail.caramail.com [195.68.99.70]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0922Eg11348 for ; Tue, 8 Jan 2002 18:02:15 -0800 Received: from caramail.com (www12.caramail.com [195.68.99.32]) by mail.caramail.com (8.8.8/8.8.8) with SMTP id CAA28282; Wed, 9 Jan 2002 02:02:09 +0100 (MET) Posted-Date: Wed, 9 Jan 2002 02:02:09 +0100 (MET) From: LENHOF Jean-Yves To: Florin ANDREI CC: linux-xfs@oss.sgi.com Message-ID: <1010538129004709@caramail.com> X-Mailer: Caramail - www.caramail.com X-Originating-IP: [193.251.35.251] Mime-Version: 1.0 Subject: Re: 1.0.2a anaconda hiccup Date: Wed, 09 Jan 2002 02:02:09 GMT+1 Content-Type: multipart/mixed; boundary="=_NextPart_Caramail_0047091010538129_ID" Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 846 Lines: 34 This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --=_NextPart_Caramail_0047091010538129_ID Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi all, /tmp/syslog: <4>Linux version 2.4.7-10SGI_XFS_PR1BOOT (mkp@austin.mkp.net) (gcc version egcs-2.91.66 19990314/Linux (egcs-1.1.2 release)) #1 Tue Nov 13 15:18:03 EST 2001 Are you really using 1.0.2a ? It sounds like a 2.4.7-10SGI-XFS_PR1BOOT and not like 2.4.9-13SGI-XFSBOOT (cf the kernel-boot rpm package included in 1.0.2a) ? I will have a look on it tomorrow at work... Have fun, Jyl ______________________________________________________ Bo=EEte aux lettres - Caramail - http://www.caramail.com --=_NextPart_Caramail_0047091010538129_ID-- From owner-linux-xfs@oss.sgi.com Tue Jan 8 18:13:59 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g092DxU11697 for linux-xfs-outgoing; Tue, 8 Jan 2002 18:13:59 -0800 Received: from mail2.caramail.com (mail2.caramail.com [195.68.99.69]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g092Dog11672 for ; Tue, 8 Jan 2002 18:13:50 -0800 Received: from caramail.com (www12.caramail.com [195.68.99.32]) by mail2.caramail.com (8.8.8/8.8.8) with SMTP id CAA22066; Wed, 9 Jan 2002 02:13:45 +0100 (MET) Posted-Date: Wed, 9 Jan 2002 02:13:45 +0100 (MET) From: LENHOF Jean-Yves To: Florin ANDREI CC: linux-xfs@oss.sgi.com Message-ID: <1010538825025994@caramail.com> X-Mailer: Caramail - www.caramail.com X-Originating-IP: [193.251.35.251] Mime-Version: 1.0 Subject: Re[1] 1.0.2a anaconda hiccup Date: Wed, 09 Jan 2002 02:13:45 GMT+1 Content-Type: multipart/mixed; boundary="=_NextPart_Caramail_0259941010538825_ID" Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 1484 Lines: 55 This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --=_NextPart_Caramail_0259941010538825_ID Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi... (again) Just remember that've got a cd here... mounted boot.img loop... and confirm with a strings vmlinuz|grep XFS that's the kernel boot is 2.4.7 and not 2.4.9.... is it normal ??? Florin.... this is not related to your problem...but I don't know exactly how to read the dump...sorry. Eric, Steve... is buildinstall launched just before release of 1.0.2 ? Just to know... Jyl > -------Message d'origine------- > De : LENHOF Jean-Yves > Date : 09/01/2002 02:02:09 > > Hi all, > > /tmp/syslog: > Linux version 2.4.7-10SGI_XFS_PR1BOOT > (mkp@austin.mkp.net) (gcc version egcs-2.91.66 > 19990314/Linux (egcs-1.1.2 release)) #1 Tue Nov 13 15:18:03 > EST 2001 > > > > Are you really using 1.0.2a ? It sounds like a > 2.4.7-10SGI-XFS_PR1BOOT and not like 2.4.9-13SGI-XFSBOOT (cf > the kernel-boot rpm package included in 1.0.2a) ? > > I will have a look on it tomorrow at work... > > Have fun, > > Jyl > ______________________________________________________ > Bo=EEte aux lettres - Caramail - http://www.caramail.com > > > ______________________________________________________ Bo=EEte aux lettres - Caramail - http://www.caramail.com --=_NextPart_Caramail_0259941010538825_ID-- From owner-linux-xfs@oss.sgi.com Tue Jan 8 18:44:48 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g092imW12290 for linux-xfs-outgoing; Tue, 8 Jan 2002 18:44:48 -0800 Received: from rover (rover.mkp.net [209.217.122.9]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g092ihg12267 for ; Tue, 8 Jan 2002 18:44:43 -0800 Received: from localhost.localdomain ([127.0.0.1] helo=rover.mkp.net) by rover with esmtp (Exim 3.33 #1) id 16O7n9-0002Cq-00; Tue, 08 Jan 2002 20:44:35 -0500 Received: (from mkp@localhost) by rover.mkp.net (8.11.6/8.9.3) id g091iAB29796; Tue, 8 Jan 2002 20:44:10 -0500 X-Authentication-Warning: jaguar.wave.mkp.net: mkp set sender to mkp@mkp.net using -f To: LENHOF Jean-Yves Cc: Florin ANDREI , linux-xfs@oss.sgi.com Subject: Re: 1.0.2a anaconda hiccup References: <1010538129004709@caramail.com> From: "Martin K. Petersen" Organization: Linuxcare, Inc. Date: 08 Jan 2002 20:44:09 -0500 In-Reply-To: <1010538129004709@caramail.com> Message-ID: User-Agent: Gnus/5.0808 (Gnus v5.8.8) XEmacs/21.4 (Civil Service) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 936 Lines: 25 >>>>> "Jyl" == LENHOF Jean-Yves writes: Jyl> /tmp/syslog: <4>Linux version 2.4.7-10SGI_XFS_PR1BOOT Jyl> (mkp@austin.mkp.net) (gcc version egcs-2.91.66 19990314/Linux Jyl> (egcs-1.1.2 release)) #1 Tue Nov 13 15:18:03 EST 2001 Jyl> Jyl> Are you really using 1.0.2a ? It sounds like a Jyl> 2.4.7-10SGI-XFS_PR1BOOT and not like 2.4.9-13SGI-XFSBOOT (cf the Jyl> kernel-boot rpm package included in 1.0.2a) ? We've had many problems in the past due to using a different install kernel version than Red Hat. So using 2.4.7 - which is what Red Hat initially shipped and did install QA against - is completely intentional. 2.4.7 is only used during the install phase, however. 2.4.9 is what will be installed on the final system. -- Martin K. Petersen, Principal Linux Consultant, Linuxcare, Inc. mkp@linuxcare.com, http://www.linuxcare.com/ SGI XFS for Linux Developer, http://oss.sgi.com/projects/xfs/ From owner-linux-xfs@oss.sgi.com Tue Jan 8 19:13:40 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g093DeD13063 for linux-xfs-outgoing; Tue, 8 Jan 2002 19:13:40 -0800 Received: from sunfish.linuxis.net (sunfish.linuxis.net [64.71.162.66]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g093Dcg13041 for ; Tue, 8 Jan 2002 19:13:38 -0800 Received: (qmail 25953 invoked by uid 1000); 9 Jan 2002 02:07:05 -0000 Date: Tue, 8 Jan 2002 18:07:05 -0800 To: linux-xfs@oss.sgi.com Subject: Oracle install -- fixed? Message-ID: <20020109020705.GC4511@flounder.net> 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.3.25i X-Delivery-Agent: TMDA v0.42/Python 2.1.1 (sunos5) From: "Adam McKenna" Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 429 Lines: 13 Does anyone know if whatever was causing Oracle not to install correctly on an XFS partition has been fixed? If not, is there a developer willing to work with me on getting it fixed? I really don't like having to use ext2 for one partition on our oracle boxes if I can avoid it. --Adam -- Adam McKenna | GPG: 17A4 11F7 5E7E C2E7 08AA http://flounder.net/publickey.html | 38B0 05D0 8BF7 2C6D 110A From owner-linux-xfs@oss.sgi.com Tue Jan 8 19:44:06 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g093i6413604 for linux-xfs-outgoing; Tue, 8 Jan 2002 19:44:06 -0800 Received: from deliverator.sgi.com (deliverator.sgi.com [204.94.214.10]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g093i2g13581 for ; Tue, 8 Jan 2002 19:44:02 -0800 Received: from relay1.corp.sgi.com (spindle.corp.sgi.com [198.29.75.13]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id SAA03075 for ; Tue, 8 Jan 2002 18:43:47 -0800 (PST) mail_from (sandeen@sgi.com) Received: from chuckle.americas.sgi.com (sandeen@chuckle.americas.sgi.com [128.162.211.44]) by relay1.corp.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) via ESMTP id SAA74612; Tue, 8 Jan 2002 18:43:28 -0800 (PST) Date: Tue, 8 Jan 2002 20:43:26 -0600 (CST) From: Eric Sandeen X-X-Sender: To: Adam McKenna cc: Subject: Re: Oracle install -- fixed? In-Reply-To: <20020109020705.GC4511@flounder.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 616 Lines: 20 Any info on how it fails? I remember this from many months ago... I don't think we made any progress, since we don't have an Oracle for Linux license in this group - is there a demo or something that's freely available, that might exhibit the same problems? -Eric On Tue, 8 Jan 2002, Adam McKenna wrote: > Does anyone know if whatever was causing Oracle not to install correctly on > an XFS partition has been fixed? > > If not, is there a developer willing to work with me on getting it fixed? I > really don't like having to use ext2 for one partition on our oracle boxes if > I can avoid it. > > --Adam > > From owner-linux-xfs@oss.sgi.com Tue Jan 8 19:45:27 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g093jRI13875 for linux-xfs-outgoing; Tue, 8 Jan 2002 19:45:27 -0800 Received: from yog-sothoth.sgi.com (eugate.sgi.com [192.48.160.10]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g093jJg13853 for ; Tue, 8 Jan 2002 19:45:20 -0800 Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by yog-sothoth.sgi.com (980305.SGI.8.8.8-aspam-6.2/980304.SGI-aspam-europe) via ESMTP id DAA1485287 for ; Wed, 9 Jan 2002 03:43:04 +0100 (CET) mail_from (tbd@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id UAA4041991; Tue, 8 Jan 2002 20:43:57 -0600 (CST) Received: from fsgi158.americas.sgi.com (fsgi158.americas.sgi.com [128.162.191.39]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id UAA82679; Tue, 8 Jan 2002 20:43:57 -0600 (CST) From: Tad Dolphay Received: by fsgi158.americas.sgi.com (SGI-8.9.3/SGI-client-1.7) id UAA26977; Tue, 8 Jan 2002 20:43:56 -0600 (CST) Message-Id: <200201090243.UAA26977@fsgi158.americas.sgi.com> Subject: Re: link() messes up file attributes To: matt_zinkevicius@hp.com ("ZINKEVICIUS,MATT (HP-Loveland,ex1)") Date: Tue, 8 Jan 2002 20:43:56 -0600 (CST) Cc: lord@sgi.com ('Steve Lord'), linux-xfs@oss.sgi.com In-Reply-To: from "ZINKEVICIUS,MATT (HP-Loveland,ex1)" at Jan 08, 2002 04:46:31 PM X-Mailer: ELM [version 2.5 PL2] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 1657 Lines: 53 > > Okay here is the current situation... > > Without your patch: > over NFSv2: open new file with 666 permission creates file with 644 > permissions > over NFSv3: open new file works fine, but hard-linking changes file perm to > 644 > > With your path: > over NFSv2: (same as above) > over NFSv3: Works fine > > So you patch does have some affect. > I vaguely remember a similar problem reported before. If I remember correctly, it had something to do with the default acls on the exported directory. Could you do a "chacl -l ." on the exported directory to check the default acls and then possibly do "chacl -d u::rwx,g::rwx,o::rwx ." to set the default acls. Then see if the problem goes away. Tad > --Matt > > > -----Original Message----- > > From: Steve Lord [mailto:lord@sgi.com] > > Sent: Tuesday, January 08, 2002 2:57 PM > > To: ZINKEVICIUS,MATT " "(HP-Loveland,ex1) > > Cc: linux-xfs@oss.sgi.com > > Subject: RE: link() messes up file attributes > > > > > > On Tue, 2002-01-08 at 15:49, ZINKEVICIUS,MATT (HP-Loveland,ex1) wrote: > > > Nevermind, the fix didn't help. Occured again today :-( > > > > Right, I am not totally surprised, the difference between the two > > code paths should be a noop. This was just the only recent change > > related to xfs. > > > > I suppose you have HP clients on the other end of the wire here? > > > > Since this is an intermittent problem, how can you be totally sure > > it is actually XFS which is at fault? > > > > Steve > > > > -- > > > > Steve Lord voice: +1-651-683-3511 > > Principal Engineer, Filesystem Software email: lord@sgi.com > > > From owner-linux-xfs@oss.sgi.com Tue Jan 8 19:49:17 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g093nHC14862 for linux-xfs-outgoing; Tue, 8 Jan 2002 19:49:17 -0800 Received: from sunfish.linuxis.net (sunfish.linuxis.net [64.71.162.66]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g093nEg14840 for ; Tue, 8 Jan 2002 19:49:14 -0800 Received: (qmail 28729 invoked by uid 1000); 9 Jan 2002 02:42:42 -0000 Date: Tue, 8 Jan 2002 18:42:41 -0800 To: linux-xfs@oss.sgi.com Subject: Re: Oracle install -- fixed? Message-ID: <20020109024241.GD4511@flounder.net> Mail-Followup-To: linux-xfs@oss.sgi.com References: <20020109020705.GC4511@flounder.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.3.25i X-Delivery-Agent: TMDA v0.42/Python 2.1.1 (sunos5) From: "Adam McKenna" Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 706 Lines: 18 On Tue, Jan 08, 2002 at 08:43:26PM -0600, Eric Sandeen wrote: > Any info on how it fails? I remember this from many months ago... I don't > think we made any progress, since we don't have an Oracle for Linux > license in this group - is there a demo or something that's freely > available, that might exhibit the same problems? You can download a copy of Oracle 8.1.7 from otn.oracle.com -- you do have to sign away your life of course but it's a full version. If I remember correctly, the error given is something like "A miscellaneous error occured" :) --Adam -- Adam McKenna | GPG: 17A4 11F7 5E7E C2E7 08AA http://flounder.net/publickey.html | 38B0 05D0 8BF7 2C6D 110A From owner-linux-xfs@oss.sgi.com Tue Jan 8 20:02:22 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0942MH15977 for linux-xfs-outgoing; Tue, 8 Jan 2002 20:02:22 -0800 Received: from c000.snv.cp.net (c000-h008.c000.snv.cp.net [209.228.32.72]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0942Hg15922 for ; Tue, 8 Jan 2002 20:02:17 -0800 Received: (cpmta 4930 invoked from network); 8 Jan 2002 19:02:10 -0800 Received: from 66.68.176.103 (HELO ?192.168.2.21?) by smtp.tooley.com (209.228.32.72) with SMTP; 8 Jan 2002 19:02:10 -0800 X-Sent: 9 Jan 2002 03:02:10 GMT Subject: Re: Oracle install -- fixed? From: Chris Tooley To: Eric Sandeen Cc: Adam McKenna , linux-xfs@oss.sgi.com In-Reply-To: References: Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/1.0.0.99+cvs.2001.12.18.08.57 (Preview Release) Date: 08 Jan 2002 15:02:18 -0600 Message-Id: <1010523739.1786.1.camel@itspecmobile> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 953 Lines: 30 Is it possible that Oracle would be willing to work with you on a temporary license to do the installation with and verify a bug or do testing to track down the issue? It would seem like a mutually beneficial thing to have fixed. Chris Tooley On Tue, 2002-01-08 at 20:43, Eric Sandeen wrote: > Any info on how it fails? I remember this from many months ago... I don't > think we made any progress, since we don't have an Oracle for Linux > license in this group - is there a demo or something that's freely > available, that might exhibit the same problems? > > -Eric > > On Tue, 8 Jan 2002, Adam McKenna wrote: > > > Does anyone know if whatever was causing Oracle not to install correctly on > > an XFS partition has been fixed? > > > > If not, is there a developer willing to work with me on getting it fixed? I > > really don't like having to use ext2 for one partition on our oracle boxes if > > I can avoid it. > > > > --Adam > > > > > From owner-linux-xfs@oss.sgi.com Tue Jan 8 20:14:41 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g094EfA16460 for linux-xfs-outgoing; Tue, 8 Jan 2002 20:14:41 -0800 Received: from maynard.mail.mindspring.net (maynard.mail.mindspring.net [207.69.200.243]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g094EWg16436 for ; Tue, 8 Jan 2002 20:14:33 -0800 Received: from user-uini7mt.dialup.mindspring.com ([165.121.30.221] helo=waltsathlon.localhost.net) by maynard.mail.mindspring.net with esmtp (Exim 3.33 #1) id 16O9C8-0002Oc-00 for linux-xfs@oss.sgi.com; Tue, 08 Jan 2002 22:14:28 -0500 Received: from mindspring.com (localhost.localdomain [127.0.0.1]) by waltsathlon.localhost.net (Postfix) with ESMTP id AA31CE01500; Tue, 8 Jan 2002 19:13:41 -0800 (PST) Message-ID: <3C3BB565.6090900@mindspring.com> Date: Tue, 08 Jan 2002 19:13:41 -0800 From: Walt H User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.7+) Gecko/20020107 X-Accept-Language: en-us MIME-Version: 1.0 To: Adam McKenna Cc: linux-xfs@oss.sgi.com Subject: Re: Anyone know what this error means? References: <20020109003323.GW4511@flounder.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 1957 Lines: 65 Hello, Not sure if this is relevant, but it might be. Seems as though there's a kernel bug preventing creation of some large filesystems - See: http://www.geocrawler.com/lists/3/Linux/35/0/7497786/ Also, in the event you can't get though, there's a patch at: http://www.kernel.org/pub/linux/kernel/people/andrea/kernels/v2.4/2.4.18pre2aa1/00_blkdev-ulimit-1 HTH, -Walt Adam McKenna wrote: > This is an approx. 270 Gig RAID5 partition on an AMI Megaraid card on > 2.2.14-xfs (snapshot).. > > I get the following error when trying to create the filesystem: > > adam@braindb:~$ sudo mkfs.xfs -f /dev/sda9 > mkfs.xfs: warning - cannot set blocksize on block device /dev/sda9: Invalid > argument > meta-data=/dev/sda9 isize=256 agcount=65, agsize=1048576 blks > data = bsize=4096 blocks=67782243, imaxpct=25 > = sunit=0 swidth=0 blks, unwritten=0 > naming =version 2 bsize=4096 > log =internal log bsize=4096 blocks=8274 > realtime =none extsz=65536 blocks=0, rtextents=0 > File size limit exceeded > > The same thing happens if I try ext2: > > adam@braindb:~$ sudo mke2fs /dev/sda9 > mke2fs 1.22, 22-Jun-2001 for EXT2 FS 0.5b, 95/08/09 > Filesystem label= > OS type: Linux > Block size=4096 (log=2) > Fragment size=4096 (log=2) > 33898496 inodes, 67782243 blocks > 3389112 blocks (5.00%) reserved for the super user > First data block=0 > 2069 block groups > 32768 blocks per group, 32768 fragments per group > 16384 inodes per group > Superblock backups stored on blocks: > 32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632, > 2654208, > 4096000, 7962624, 11239424, 20480000, 23887872 > > File size limit exceeded > > adam@braindb:~$ uname -a > Linux braindb 2.4.14-xfs #3 SMP Fri Nov 30 01:58:14 PST 2001 i686 unknown > > Anyone know what is going on here? > > --Adam > > From owner-linux-xfs@oss.sgi.com Tue Jan 8 21:46:04 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g095k4n17915 for linux-xfs-outgoing; Tue, 8 Jan 2002 21:46:04 -0800 Received: from sgi.com (sgi-too.SGI.COM [204.94.211.39]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g095jtg17893 for ; Tue, 8 Jan 2002 21:45:55 -0800 Received: from boing.melbourne.sgi.com (boing.melbourne.sgi.com [134.14.55.141]) by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id UAA03866 for ; Tue, 8 Jan 2002 20:43:38 -0800 (PST) mail_from (tes@boing.melbourne.sgi.com) Received: (from tes@localhost) by boing.melbourne.sgi.com (SGI-8.9.3/8.9.3) id PAA77079; Wed, 9 Jan 2002 15:44:30 +1100 (AEDT) Date: Wed, 9 Jan 2002 15:44:30 +1100 From: Timothy Shimmin To: Tad Dolphay Cc: "\"ZINKEVICIUS,MATT (HP-Loveland,ex1)\"" , "'Steve Lord'" , linux-xfs@oss.sgi.com Subject: Re: link() messes up file attributes Message-ID: <20020109154429.X1500056@boing.melbourne.sgi.com> References: <200201090243.UAA26977@fsgi158.americas.sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0us In-Reply-To: <200201090243.UAA26977@fsgi158.americas.sgi.com>; from tbd@sgi.com on Tue, Jan 08, 2002 at 08:43:56PM -0600 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 2373 Lines: 73 On Tue, Jan 08, 2002 at 08:43:56PM -0600, Tad Dolphay wrote: > > > > Okay here is the current situation... > > > > Without your patch: > > over NFSv2: open new file with 666 permission creates file with 644 > > permissions > > over NFSv3: open new file works fine, but hard-linking changes file perm to > > 644 > > > > With your path: > > over NFSv2: (same as above) > > over NFSv3: Works fine > > > > So you patch does have some affect. > > > I vaguely remember a similar problem reported before. If I remember correctly, > it had something to do with the default acls on the exported directory. Could > you do a "chacl -l ." on the exported directory to check the default acls > and then possibly do "chacl -d u::rwx,g::rwx,o::rwx ." to set the default > acls. Then see if the problem goes away. > Yes, I was wondering the same thing. This is filed in pv#843903 (sgi bug#). The umask of nfsd is being applied when it shouldn't be (if we find we don't have a default ACL then we apply the umask). Giving a default mininum ACL with all permissions on as Tad suggests (-d u::rwx,g::rwx,o::rwx) would stop the umask from being applied. (This, of course, is not a fix, but would be good to check :) Are ACLs enabled ? (The fix for pv#843903 was being deferred 'til we had more complete integration with Andreas G's kernel EA/ACL patch) --Tim > Tad > > --Matt > > > > > -----Original Message----- > > > From: Steve Lord [mailto:lord@sgi.com] > > > Sent: Tuesday, January 08, 2002 2:57 PM > > > To: ZINKEVICIUS,MATT " "(HP-Loveland,ex1) > > > Cc: linux-xfs@oss.sgi.com > > > Subject: RE: link() messes up file attributes > > > > > > > > > On Tue, 2002-01-08 at 15:49, ZINKEVICIUS,MATT (HP-Loveland,ex1) wrote: > > > > Nevermind, the fix didn't help. Occured again today :-( > > > > > > Right, I am not totally surprised, the difference between the two > > > code paths should be a noop. This was just the only recent change > > > related to xfs. > > > > > > I suppose you have HP clients on the other end of the wire here? > > > > > > Since this is an intermittent problem, how can you be totally sure > > > it is actually XFS which is at fault? > > > > > > Steve > > > > > > -- > > > > > > Steve Lord voice: +1-651-683-3511 > > > Principal Engineer, Filesystem Software email: lord@sgi.com > > > > > > From owner-linux-xfs@oss.sgi.com Tue Jan 8 23:02:50 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0972oi19078 for linux-xfs-outgoing; Tue, 8 Jan 2002 23:02:50 -0800 Received: from zok.sgi.com (zok.sgi.com [204.94.215.101]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0972dg19054 for ; Tue, 8 Jan 2002 23:02:39 -0800 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.55.149]) by zok.sgi.com (8.11.4/8.11.4/linux-outbound_gateway-1.1) with ESMTP id g0962UA19283 for ; Tue, 8 Jan 2002 22:02:30 -0800 Received: (from nathans@localhost) by snort.melbourne.sgi.com (SGI-8.9.3/8.9.3) id RAA73612 for linux-xfs@oss.sgi.com; Wed, 9 Jan 2002 17:01:12 +1100 (EST) Date: Wed, 9 Jan 2002 17:01:12 +1100 (EST) From: Nathan Scott Message-Id: <200201090601.RAA73612@snort.melbourne.sgi.com> To: linux-xfs@oss.sgi.com Subject: TAKE - minor pagebuf cleanups Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 1693 Lines: 48 Date: Tue Jan 8 21:15:08 PST 2002 Workarea: snort.melbourne.sgi.com:/home/nathans/linux-xfs The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:109271a linux/fs/xfs/xfs_mount.c - 1.265 - if PAGEBUF_DEBUG is defined, allow non-page-size blocksize mounts, simplify my life. linux/fs/xfs/xfs_trans_buf.c - 1.97 - cosmetic change - xfs_buf_t/xfs_daddr_t offsetting fixups only. linux/fs/xfs/linux/xfs_file.c - 1.56 - remove a check which is always done higher up in the VFS code. minor formatting fixup. linux/fs/xfs/xfs_vfsops.c - 1.331 linux/fs/xfs/linux/xfs_super.h - 1.13 linux/fs/xfs/linux/xfs_super.c - 1.152 - add some code to allow blocksize to be passed down to pagebuf. linux/fs/xfs/xfs_buf.h - 1.77 - remove some macros which are no longer used anywhere. linux/include/linux/page_buf.h - 1.102 - mostly cosmetic fixes to no-long-correct comments, duplicate comments, inconsistencies in offsetting in struct fields, etc. added a field to pb_target_t to hold the fs blocksize, and a routine for setting it. fix up debugging macros so that they work again and can be enabled/ disabled via the makefile. linux/fs/pagebuf/page_buf.c - 1.104 linux/fs/pagebuf/page_buf_io.c - 1.106 - cosmetic changes, mainly cleanup debugging code, formatting fixups. linux/fs/pagebuf/page_buf_locking.c - 1.17 - cosmetic changes, mainly cleanup debugging code, formatting fixups. add some code to allow blocksize to be passed in from the filesystem, store in the pb_target structure. linux/fs/pagebuf/Makefile - 1.6 linux/fs/pagebuf/Makefile.in - 1.3 - add in debugging options if debugging enabled. From owner-linux-xfs@oss.sgi.com Tue Jan 8 23:52:35 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g097qZC19863 for linux-xfs-outgoing; Tue, 8 Jan 2002 23:52:35 -0800 Received: from com.esnaola.org (aboukir-101-1-5-ldarnis.adsl.nerim.net [80.65.225.199]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g097qVg19841 for ; Tue, 8 Jan 2002 23:52:31 -0800 Received: from localhost (localhost [127.0.0.1]) by com.esnaola.org (Microsoft Exchange) with ESMTP id A6B45296809 for ; Wed, 9 Jan 2002 07:52:27 +0100 (CET) Received: from localhost (com.esnaola.org [192.168.33.1]) by com.esnaola.org (Microsoft Exchange) with SMTP id 97E1A280292 for ; Wed, 9 Jan 2002 07:52:24 +0100 (CET) To: Subject: BIG PROBLEM : XFS: Bad magic Number ! From: Date: Wed, 9 Jan 2002 07:52:24 CET Reply-To: X-Priority: 2 (High) X-Originating-Ip: [80.65.225.199] X-Mailer: ESNAOLA WEBSITE v1 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit Message-Id: <20020109065224.97E1A280292@com.esnaola.org> X-Virus-Scanned: by AMaViS perl-10 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 503 Lines: 25 Hi everybody, Big problem this morning when I switched on principal PC. I have : XFS: bad magic number XFS: SB validate failed Kernel Panic: VFS: Unable to mount root fs on 03:04 What can I do ?!! I really need to save my mailbox on it and some documents I don't backup yesterday. Thank you...Thank you for your help For information : I use the cvs xfs 2.4.17 with a Debian/Woody update yesterday, on a PIII 650 with 256Mo RAM and 30Go HD ATA33 See ya Lionel ESNAOLA WEBSITE www.esnoala.org From owner-linux-xfs@oss.sgi.com Wed Jan 9 00:00:03 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g09803N20130 for linux-xfs-outgoing; Wed, 9 Jan 2002 00:00:03 -0800 Received: from ADSL-Bergs.RZ.RWTH-Aachen.DE (adsl-bergs.rz.RWTH-Aachen.DE [137.226.80.218]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g097xwg20073 for ; Tue, 8 Jan 2002 23:59:59 -0800 Received: from [192.168.1.2] (helo=ralf) by ADSL-Bergs.RZ.RWTH-Aachen.DE with smtp (Exim 3.12 #1) id 16OCiE-0005A1-00; Wed, 09 Jan 2002 07:59:50 +0100 From: "Ralf G. R. Bergs" To: "Adam McKenna" Cc: "linux-xfs@oss.sgi.com" Date: Wed, 09 Jan 2002 07:59:49 +0100 Reply-To: "Ralf G. R. Bergs" X-Mailer: PMMail 2000 Professional (2.20.2380) For Windows 2000 (5.0.2195;2) In-Reply-To: <20020109003323.GW4511@flounder.net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Subject: Re: Anyone know what this error means? Message-Id: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 726 Lines: 25 On Tue, 8 Jan 2002 16:33:23 -0800, Adam McKenna wrote: [...] >adam@braindb:~$ sudo mkfs.xfs -f /dev/sda9 >mkfs.xfs: warning - cannot set blocksize on block device /dev/sda9: Invalid >argument Are you by chance using an "obsolete" version of mkfs.xfs? [...] >The same thing happens if I try ext2: [...] >File size limit exceeded I'm not so sure that you have the same error here -- anyway, I can tell you anything about THIS message... -- Verkaufe Original-BMW-Raeder: L I N U X .~. http://adsl-bergs.rz.rwth-aachen.de/~rabe The Choice /V\ of a GNU /( )\ Generation ^^-^^ From owner-linux-xfs@oss.sgi.com Wed Jan 9 00:01:03 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g09813s20278 for linux-xfs-outgoing; Wed, 9 Jan 2002 00:01:03 -0800 Received: from rj.sgi.com (rj.sgi.com [204.94.215.100]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0980sg20249 for ; Wed, 9 Jan 2002 00:00:54 -0800 Received: from boing.melbourne.sgi.com (boing.melbourne.sgi.com [134.14.55.141]) by rj.sgi.com (8.11.4/8.11.4/linux-outbound_gateway-1.1) with ESMTP id g0970kY04946 for ; Tue, 8 Jan 2002 23:00:46 -0800 Received: (from tes@localhost) by boing.melbourne.sgi.com (SGI-8.9.3/8.9.3) id RAA80401; Wed, 9 Jan 2002 17:59:27 +1100 (AEDT) Date: Wed, 9 Jan 2002 17:59:27 +1100 From: Timothy Shimmin To: Matteo Centonza Cc: linux-xfs@oss.sgi.com Subject: Re: xfsdump assertion failure Message-ID: <20020109175926.Y1500056@boing.melbourne.sgi.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0us In-Reply-To: ; from matteo@sif.it on Mon, Jan 07, 2002 at 09:33:08AM +0100 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 3133 Lines: 73 Hi Matteo, On Mon, Jan 07, 2002 at 09:33:08AM +0100, Matteo Centonza wrote: > > these are the logs from last incremental dump through amanda: > > FAIL dumper embeh / 1 [/usr/sbin/xfsdump got signal 6] > sendbackup: start [embeh:/ level 1] > sendbackup: info BACKUP=/usr/sbin/xfsdump > sendbackup: info RECOVER_CMD=/bin/gzip -dc |/usr/sbin/xfsrestore -f... - > sendbackup: info COMPRESS_SUFFIX=.gz > sendbackup: info end > | xfsdump: version 3.0 - Running single-threaded > | xfsdump: level 1 incremental dump of embeh.sif.it:/ based on level 0 > dump begun Fri Jan 4 23:42:11 2002 > | xfsdump: dump date: Sun Jan 6 20:04:26 2002 > | xfsdump: session id: 387c506e-593f-471d-a227-53c37f845c94 > | xfsdump: session label: "" > | xfsdump: ino map phase 1: skipping (no subtrees specified) > | xfsdump: ino map phase 2: constructing initial dump list > | xfsdump: ino map phase 3: pruning unneeded subtrees > ? xfsdump: inomap.c:858: supprt_prune: Assertion `state != 2' failed. > sendbackup: error [/usr/sbin/xfsdump got signal 6] > > 2.4.14-xfs-1 #2 Fri Nov 9 12:10:19 CET 2001 i686 unknown > xfsdump-1.1.7-0 > HTH, > -m Was the filesystem busy when the dump was going on; in particular, were files/dirs being created and deleted ? The reason I ask is because the assertion failure indicates that the inode map thinks that the inode in question is an unchanged file, (MAP_NDR_NOCHNG), whereas the recent stat on the file indicates that the inode is a directory. The assertion is saying that it can't be a file since my stat indicates it's a directory. "xfsdump: ino map phase 2: constructing initial dump list" mentioned above, is the phase where the inode map is built. The inode map is a mapping from inode numbers to an 8-value state. The state indicates whether it is a directory or not and whether the inode has changed or not (since the last dump) and a few other things. The state is set after doing a stat on all the inodes (using bulkstat). So at that point in time xfsdump thought the inode was a non-dir. Then in the next phase, "xfsdump: ino map phase 3: pruning unneeded subtrees", it does more stat'ing and directory path walking to mark certain subtrees as MAP_DIR_NOCHNG so that they are not dumped - this can be effected by the -s option and in incremental dumps. It is while doing this step that it looked up the map to see if the directory (indicated by the recent stat data) had changed or not and it found that the inode map reckoned it wasn't a directory. So it makes one wonder if the inode number has been reused when the original file was deleted. The assertion, however, does not seem the right course of action. Basically we've done stat's on inodes and stored them away. Then done stat's again and found that the type of inode has changed and exited (with assertion failure). I think it is reasonable that there is a window for inode#s to be reused and we should handle it gracefully. I'll discuss with colleagues on what the best fix is. Now if there were no deletions going on then I need to look elsewhere. Have you seen this happen before ? Thanks, Tim. From owner-linux-xfs@oss.sgi.com Wed Jan 9 00:10:37 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g098AbL20838 for linux-xfs-outgoing; Wed, 9 Jan 2002 00:10:37 -0800 Received: from relay.xlink.net (relay.xlink.net [193.141.40.4]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g098AWg20816 for ; Wed, 9 Jan 2002 00:10:32 -0800 Received: from lizard.webland.de (lizard.webland.de [194.122.76.201]) by relay.xlink.net (8.9.3/8.8.7) with ESMTP id IAA02625; Wed, 9 Jan 2002 08:10:29 +0100 (MET) Received: (from uucp@localhost) by lizard.webland.de (8.8.8/8.8.7) id IAA23148; Wed, 9 Jan 2002 08:10:28 +0100 (MET) >Received: from mobile.sauter-bc.com (unknown [10.1.6.21]) by basel1.sauter-bc.com (Postfix) with ESMTP id CD22857306; Wed, 9 Jan 2002 08:10:08 +0100 (CET) Received: from ch.sauter-bc.com (support.cad.sba [10.1.200.117]) by mobile.sauter-bc.com (Postfix) with ESMTP id 9219925835; Wed, 9 Jan 2002 08:10:08 +0100 (CET) Message-ID: <3C3BECD0.33EA84F8@ch.sauter-bc.com> Date: Wed, 09 Jan 2002 08:10:08 +0100 From: Simon Matter Organization: Sauter AG, Basel X-Mailer: Mozilla 4.77 [de] (X11; U; Linux 2.2.19-6.2.12 i686) X-Accept-Language: de-CH, en MIME-Version: 1.0 To: Adam McKenna Cc: linux-xfs@oss.sgi.com Subject: Re: Oracle install -- fixed? References: <20020109020705.GC4511@flounder.net> <20020109024241.GD4511@flounder.net> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 1104 Lines: 30 Adam McKenna schrieb: > > On Tue, Jan 08, 2002 at 08:43:26PM -0600, Eric Sandeen wrote: > > Any info on how it fails? I remember this from many months ago... I don't > > think we made any progress, since we don't have an Oracle for Linux > > license in this group - is there a demo or something that's freely > > available, that might exhibit the same problems? > > You can download a copy of Oracle 8.1.7 from otn.oracle.com -- you do have to > sign away your life of course but it's a full version. > > If I remember correctly, the error given is something like "A miscellaneous > error occured" :) I don't know about Oracle but some software tries to set attributes on directories or files on ext2 to let it write synchronously (+S flag?) and refuses to run o other filesystems on Linux. So if a software depends on that kind of operation while installing it should be possible to install on ext2 and then migrate to XFS later. Simon > > --Adam > > -- > Adam McKenna | GPG: 17A4 11F7 5E7E C2E7 08AA > http://flounder.net/publickey.html | 38B0 05D0 8BF7 2C6D 110A From owner-linux-xfs@oss.sgi.com Wed Jan 9 00:24:11 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g098OBA21122 for linux-xfs-outgoing; Wed, 9 Jan 2002 00:24:11 -0800 Received: from mail.tahsda.org.tw (c252.h203149202.is.net.tw [203.149.202.252]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g098O6g21100 for ; Wed, 9 Jan 2002 00:24:07 -0800 Received: from localhost ([127.0.0.1] helo=mail.teatime.com.tw) by mail.tahsda.org.tw with smtp (Exim 3.33 #1) id 16OD5Z-0007I8-00; Wed, 09 Jan 2002 15:23:57 +0800 Received: from p66.n120.tah ([139.168.120.66]) by mail (TeaTime Mail Server 0.6.5) with SMTP id spool/sma.28018.IKaqU2 for ; Wed, 9 Jan 02 15:23:29 +0800 Date: Wed, 09 Jan 2002 15:23:13 +0800 From: Tommy Wu To: "Adam McKenna" Subject: Re: Oracle install -- fixed? Cc: linux-xfs@oss.sgi.com Reply-To: tommy@teatime.com.tw Organization: TeaTime Development In-Reply-To: <20020109020705.GC4511@flounder.net> References: <20020109020705.GC4511@flounder.net> Message-Id: <20020109151750.1C9A.NEWSLETTER@teatime.com.tw> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Becky! ver. 2.00.08 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 584 Lines: 21 "Adam McKenna" wrote: > Does anyone know if whatever was causing Oracle not to install correctly on > an XFS partition has been fixed? What problem ? Oracle version ? We're running Oracle 9i on linux with XFS now.... No any problem during Oracle install (only a binutils problem with "-z defs" during making Oracle client library....) -- Tommy Wu mailto:tommy@teatime.com.tw http://www.teatime.com.tw/~tommy ICQ: 22766091 Mobile Phone: +886 936 909490 TeaTime BBS +886 2 31515964 24Hrs V.Everything From owner-linux-xfs@oss.sgi.com Wed Jan 9 00:26:35 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g098QZQ21263 for linux-xfs-outgoing; Wed, 9 Jan 2002 00:26:35 -0800 Received: from mitta.telekabel.at (212186140225.15.wu-wien.teleweb.at [212.186.140.225]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g098QUg21238 for ; Wed, 9 Jan 2002 00:26:31 -0800 Received: from mitta (localhost [127.0.0.1]) by mitta.telekabel.at (8.12.1/8.12.1) with SMTP id g097QKdG000287; Wed, 9 Jan 2002 08:26:20 +0100 Date: Wed, 9 Jan 2002 08:26:20 +0100 From: Adam Cioccarelli To: "Adam McKenna" Cc: linux-xfs@oss.sgi.com Subject: Re: Oracle install -- fixed? Message-Id: <20020109082620.30a8e047.alciocca@yahoo.com.au> In-Reply-To: <20020109020705.GC4511@flounder.net> References: <20020109020705.GC4511@flounder.net> X-Mailer: Sylpheed version 0.6.6claws (GTK+ 1.2.10; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 755 Lines: 25 Hi Adam, what error do you get? I have Oracle (8.1.7) installed on an XFS partition on at least three boxes and never had any problems. Is the problem with the installation or somewhere else? Adam On Tue, 8 Jan 2002 18:07:05 -0800 "Adam McKenna" wrote: > Does anyone know if whatever was causing Oracle not to install correctly on > an XFS partition has been fixed? > > If not, is there a developer willing to work with me on getting it fixed? I > really don't like having to use ext2 for one partition on our oracle boxes if > I can avoid it. > > --Adam > > -- > Adam McKenna | GPG: 17A4 11F7 5E7E C2E7 08AA > http://flounder.net/publickey.html | 38B0 05D0 8BF7 2C6D 110A From owner-linux-xfs@oss.sgi.com Wed Jan 9 00:33:55 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g098Xtr21653 for linux-xfs-outgoing; Wed, 9 Jan 2002 00:33:55 -0800 Received: from com.esnaola.org (aboukir-101-1-5-ldarnis.adsl.nerim.net [80.65.225.199]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g098Xng21631 for ; Wed, 9 Jan 2002 00:33:49 -0800 Received: from localhost (localhost [127.0.0.1]) by com.esnaola.org (Microsoft Exchange) with ESMTP id 36E80296809 for ; Wed, 9 Jan 2002 08:33:46 +0100 (CET) Received: from localhost (com.esnaola.org [192.168.33.1]) by com.esnaola.org (Microsoft Exchange) with SMTP id 66328280292 for ; Wed, 9 Jan 2002 08:33:43 +0100 (CET) To: Subject: Re: BIG PROBLEM : XFS: Bad magic Number ! From: Date: Wed, 9 Jan 2002 08:33:43 CET Reply-To: X-Priority: 3 (Normal) X-Originating-Ip: [80.65.225.199] X-Mailer: ESNAOLA WEBSITE v1 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit Message-Id: <20020109073343.66328280292@com.esnaola.org> X-Virus-Scanned: by AMaViS perl-10 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 1140 Lines: 42 Xfs@esnaola.org a écrit : > Hi everybody, > > Big problem this morning when I switched on principal PC. > I have : > > XFS: bad magic number > XFS: SB validate failed > Kernel Panic: VFS: Unable to mount root fs on 03:04 > > What can I do ?!! > I really need to save my mailbox on it and some documents I don't backup > yesterday. > > Thank you...Thank you for your help > > For information : I use the cvs xfs 2.4.17 with a Debian/Woody update yesterday, > on a PIII 650 with 256Mo RAM and 30Go HD ATA33 > > See ya > > Lionel > > > ESNAOLA WEBSITE www.esnoala.org In the XFS FAQ I found this : XFS: bad magic number XFS: SB validate failed This means that you can not mount the filesystem due to corruption. You will need to run xfs_repair and hope it can be repaired. If you hit this you have serious problems. It can be anything from the disks have failed in mysterious ways, software raid has gone mad, corruption through bad cables/drivers/DMA etc. BUT How can I use xfs_repair can u help me and give me some informations about this because my XFS Machine worked fine since 2 months ESNAOLA WEBSITE www.esnoala.org From owner-linux-xfs@oss.sgi.com Wed Jan 9 01:09:02 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g09992v27191 for linux-xfs-outgoing; Wed, 9 Jan 2002 01:09:02 -0800 Received: from smtpzilla1.xs4all.nl (smtpzilla1.xs4all.nl [194.109.127.137]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0998vg27168 for ; Wed, 9 Jan 2002 01:08:57 -0800 Received: from auto-nb1.xs4all.nl (coltex.xs4all.nl [213.84.127.168]) by smtpzilla1.xs4all.nl (8.12.0/8.12.0) with ESMTP id g0988rDq052296; Wed, 9 Jan 2002 09:08:53 +0100 (CET) Message-Id: <4.3.2.7.2.20020109090742.02edbf40@pop.xs4all.nl> X-Sender: knuffie@pop.xs4all.nl X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 09 Jan 2002 09:08:22 +0100 To: LENHOF Jean-Yves , Florin ANDREI From: Seth Mos Subject: Re: 1.0.2a anaconda hiccup Cc: linux-xfs@oss.sgi.com In-Reply-To: <1010538129004709@caramail.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 536 Lines: 25 At 02:02 9-1-2002 +0000, LENHOF Jean-Yves wrote: >Hi all, > > > >/tmp/syslog: ><4>Linux version 2.4.7-10SGI_XFS_PR1BOOT >(mkp@austin.mkp.net) (gcc version egcs-2.91.66 >19990314/Linux (egcs-1.1.2 release)) #1 Tue Nov 13 15:18:03 >EST 2001 > > > >Are you really using 1.0.2a ? It sounds like a The installer uses the 2.4.7 kernel and it installs a 2.4.9 kernel on the system you are installing too. -- Seth Every program has two purposes one for which it was written and another for which it wasn't I use the last kind. From owner-linux-xfs@oss.sgi.com Wed Jan 9 01:38:48 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g099cmd28147 for linux-xfs-outgoing; Wed, 9 Jan 2002 01:38:48 -0800 Received: from quasar.sif.it (IDENT:root@quasar.sif.it [131.154.110.3]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g099cag28121 for ; Wed, 9 Jan 2002 01:38:36 -0800 Received: from localhost (matteo@localhost) by quasar.sif.it (8.11.6/8.11.6) with ESMTP id g098cvO21905; Wed, 9 Jan 2002 09:38:57 +0100 Date: Wed, 9 Jan 2002 09:38:57 +0100 (CET) From: Matteo Centonza To: Timothy Shimmin cc: Subject: Re: xfsdump assertion failure In-Reply-To: <20020109175926.Y1500056@boing.melbourne.sgi.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 3562 Lines: 89 Hi Tim, thanks for your response. > > > > these are the logs from last incremental dump through amanda: > > > > FAIL dumper embeh / 1 [/usr/sbin/xfsdump got signal 6] > > sendbackup: start [embeh:/ level 1] > > sendbackup: info BACKUP=/usr/sbin/xfsdump > > sendbackup: info RECOVER_CMD=/bin/gzip -dc |/usr/sbin/xfsrestore -f... - > > sendbackup: info COMPRESS_SUFFIX=.gz > > sendbackup: info end > > | xfsdump: version 3.0 - Running single-threaded > > | xfsdump: level 1 incremental dump of embeh.sif.it:/ based on level 0 > > dump begun Fri Jan 4 23:42:11 2002 > > | xfsdump: dump date: Sun Jan 6 20:04:26 2002 > > | xfsdump: session id: 387c506e-593f-471d-a227-53c37f845c94 > > | xfsdump: session label: "" > > | xfsdump: ino map phase 1: skipping (no subtrees specified) > > | xfsdump: ino map phase 2: constructing initial dump list > > | xfsdump: ino map phase 3: pruning unneeded subtrees > > ? xfsdump: inomap.c:858: supprt_prune: Assertion `state != 2' failed. > > sendbackup: error [/usr/sbin/xfsdump got signal 6] > > > > 2.4.14-xfs-1 #2 Fri Nov 9 12:10:19 CET 2001 i686 unknown > > xfsdump-1.1.7-0 > > HTH, > > -m > > Was the filesystem busy when the dump was going on; in particular, > were files/dirs being created and deleted ? The command was cron issued last sunday around 8 p.m., when there's little or no activity, but it's a root filesystem.... > > The reason I ask is because the assertion failure indicates that > the inode map thinks that the inode in question is an unchanged file, > (MAP_NDR_NOCHNG), whereas the recent stat on the file indicates that > the inode is a directory. > The assertion is saying that it can't be a file since my stat indicates > it's a directory. > > "xfsdump: ino map phase 2: constructing initial dump list" mentioned > above, is the phase where the inode map is built. The inode map is a > mapping from inode numbers to an 8-value state. > The state indicates whether it is a directory or not and whether the > inode has changed or not (since the last dump) and a few other things. > The state is set after doing a stat on all the inodes (using bulkstat). > So at that point in time xfsdump thought the inode was a non-dir. > Then in the next phase, > "xfsdump: ino map phase 3: pruning unneeded subtrees", it > does more stat'ing and directory path walking to mark certain > subtrees as MAP_DIR_NOCHNG so that they are not dumped - this can > be effected by the -s option and in incremental dumps. > It is while doing this step that it looked up the map to see if the > directory (indicated by the recent stat data) had changed or not > and it found that the inode map reckoned it wasn't a directory. > So it makes one wonder if the inode number has been reused when > the original file was deleted. > Yes, it's very unlikely given the very mild load and the mean dump duration (less than 2 mins). > The assertion, however, does not seem the right course of action. > Basically we've done stat's on inodes and stored them away. > Then done stat's again and found that the type of inode has changed > and exited (with assertion failure). > I think it is reasonable that there is a window for inode#s to be > reused and we should handle it gracefully. > > I'll discuss with colleagues on what the best fix is. > > Now if there were no deletions going on then I need to look elsewhere. > > Have you seen this happen before ? No. We've had only annoying bulkstat ever once in a while. The next incremental is scheduled for this evening. Thanks, -m From owner-linux-xfs@oss.sgi.com Wed Jan 9 01:51:37 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g099pb828485 for linux-xfs-outgoing; Wed, 9 Jan 2002 01:51:37 -0800 Received: from com.esnaola.org (aboukir-101-1-5-ldarnis.adsl.nerim.net [80.65.225.199]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g099pWg28462 for ; Wed, 9 Jan 2002 01:51:33 -0800 Received: from localhost (localhost [127.0.0.1]) by com.esnaola.org (Microsoft Exchange) with ESMTP id 96748296809 for ; Wed, 9 Jan 2002 09:51:29 +0100 (CET) Received: from localhost (com.esnaola.org [192.168.33.1]) by com.esnaola.org (Microsoft Exchange) with SMTP id A9E65280292 for ; Wed, 9 Jan 2002 09:51:26 +0100 (CET) To: Subject: xfs_repair + bad magic number From: Date: Wed, 9 Jan 2002 09:51:26 CET Reply-To: X-Priority: 3 (Normal) X-Originating-Ip: [80.65.225.199] X-Mailer: ESNAOLA WEBSITE v1 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit Message-Id: <20020109085126.A9E65280292@com.esnaola.org> X-Virus-Scanned: by AMaViS perl-10 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 495 Lines: 29 Hi, It's my last chance... After a bad magic number I booted on a rescure disk and I lauched xfs_repair, It said me : Phase 1 - Find and verify superblock... Bad primary superblock - bad magic number !! attempting to find secondary superblock................ Sorry, could not find valid secondary superblock Exiting now. Is ther any solutions ? Or must I will format my HD and lose all my datas ? Thanks in advance for your answers . See ya, Lionel ESNAOLA WEBSITE www.esnoala.org From owner-linux-xfs@oss.sgi.com Wed Jan 9 03:08:37 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g09B8b230056 for linux-xfs-outgoing; Wed, 9 Jan 2002 03:08:37 -0800 Received: from smtpzilla5.xs4all.nl (smtpzilla5.xs4all.nl [194.109.127.141]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g09B8Wg30034 for ; Wed, 9 Jan 2002 03:08:32 -0800 Received: from auto-nb1.xs4all.nl (coltex.xs4all.nl [213.84.127.168]) by smtpzilla5.xs4all.nl (8.12.0/8.12.0) with ESMTP id g09A8PJG028797; Wed, 9 Jan 2002 11:08:27 +0100 (CET) Message-Id: <4.3.2.7.2.20020109091900.02ee17d0@pop.xs4all.nl> X-Sender: knuffie@pop.xs4all.nl X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 09 Jan 2002 11:07:55 +0100 To: , From: Seth Mos Subject: Re: BIG PROBLEM : XFS: Bad magic Number ! In-Reply-To: <20020109065224.97E1A280292@com.esnaola.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 738 Lines: 31 At 07:52 9-1-2002 +0100, xfs@esnaola.org wrote: >Hi everybody, > >Big problem this morning when I switched on principal PC. >I have : > >XFS: bad magic number >XFS: SB validate failed >Kernel Panic: VFS: Unable to mount root fs on 03:04 Problems, see FAQ about this. >What can I do ?!! >I really need to save my mailbox on it and some documents I don't backup >yesterday. You can use the installer disk in rescue mode since that one also has the xfs_repair utility. Other options are the Linuxcare Bootable Toolbox http://lbt.linuxcare.com which is 50MB download and has all the utilities you need. Cheers -- Seth Every program has two purposes one for which it was written and another for which it wasn't I use the last kind. From owner-linux-xfs@oss.sgi.com Wed Jan 9 03:50:25 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g09BoP931375 for linux-xfs-outgoing; Wed, 9 Jan 2002 03:50:25 -0800 Received: from com.esnaola.org (aboukir-101-1-5-ldarnis.adsl.nerim.net [80.65.225.199]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g09BoLg31353 for ; Wed, 9 Jan 2002 03:50:22 -0800 Received: from localhost (localhost [127.0.0.1]) by com.esnaola.org (Microsoft Exchange) with ESMTP id 8E346297F15 for ; Wed, 9 Jan 2002 11:50:18 +0100 (CET) Received: from neotrantor.esnaola.org (neotrantor.esnaola.org [192.168.33.18]) by com.esnaola.org (Microsoft Exchange) with ESMTP id D2AD8280292 for ; Wed, 9 Jan 2002 11:50:15 +0100 (CET) Subject: Final : XFS_REPAIR ;-) From: Lionel DARNIS To: linux-xfs Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/1.0.1.99+cvs.2001.12.19.09.00 (Preview Release) Date: 09 Jan 2002 11:50:23 +0100 Message-Id: <1010573423.1660.4.camel@neotrantor> Mime-Version: 1.0 X-Virus-Scanned: by AMaViS perl-10 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 276 Lines: 15 NICE !! It work I repaired my HD and I saved my mailboxes to another machine. I was obliged to do a xfs_repair -L, so I supposed I lose some datas. I think i will rebuild all my Debian/Woody XFS 2.4.17 quickly to be sure not to have again the problem. See ya, Lionel From owner-linux-xfs@oss.sgi.com Wed Jan 9 04:20:55 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g09CKtK02485 for linux-xfs-outgoing; Wed, 9 Jan 2002 04:20:55 -0800 Received: from s1.uklinux.net (mail.uklinux.net [80.84.72.21]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g09CKmg02463 for ; Wed, 9 Jan 2002 04:20:49 -0800 Received: from pyewacket.nic.uklinux.net (host213-122-124-228.btinternet.com [213.122.124.228]) (authenticated) by s1.uklinux.net (8.11.6/8.11.6) with ESMTP id g09BKRo15820; Wed, 9 Jan 2002 11:20:27 GMT Envelope-To: linux-xfs@oss.sgi.com Received: from nic by pyewacket.nic.uklinux.net with local (Exim 3.33 #1) id 16OGlg-0000f8-00; Wed, 09 Jan 2002 11:19:40 +0000 Subject: Re: Can't boot 2.4.17 (was Re: GRUB + LVM + XFS?) From: Nic Doye To: Rupa Schomaker Cc: linux-xfs@oss.sgi.com In-Reply-To: References: <1010427293.29260.3.camel@UberGeek> <200201080148.g081mjg16459@oss.sgi.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/1.0 Date: 09 Jan 2002 11:19:40 +0000 Message-Id: <1010575180.2201.1.camel@pyewacket> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 1441 Lines: 43 On Tue, 2002-01-08 at 04:15, Rupa Schomaker wrote: > With Adrian's prodding, I've gotten a capture of the boot process when > I boot a newly built 2.4.17 from CVS (Jan 5 2002ish) at oss.sgi.org. > > I'm sendign this to the xfs list only -- I can send it to more places > if this is not the appropriate place to do so. > > 2.4.9 is working fine. 2.4.17 fails to bood during the change_root > phase. Back trace from kdb: > > Console just before oops: > > RAMDISK: Compressed image found at block 0 > Freeing initrd memory: 1135k freed > VFS: Mounted root (ext2 filesystem). > Mounted devfs on /dev > LVM version 1.0.1-rc4(ish)(03/10/2001) module loaded > cramfs: wrong magic > lvm -- lvm_blk_ioctl: unknown command 0x5310 > XFS mounting filesystem lvm(58,0) > VFS: Mounted root (xfs filesystem) readonly. > devfs: devfs_do_symlink(root): could not append to parent, err: -17 > change_root: old root has d_count=2 Hi, this _may_ be a devfs config thing. I had similar problems on my home machine (the only box I risk trialing devfs on) when I went from 2.4.9 to 2.4.11. kdb showed the machine looping at a (different) devfs_do_symlink stage. Try getting a newer devfsd (1.3.20 is current - I'm still using 1.3.18). See my message http://marc.theaimsgroup.com/?l=linux-xfs&m=100376435115621&w=2 to see if you tink your config is similarly out of date. My apologies if this isn't devfs related and I'm just adding random noise. nic From owner-linux-xfs@oss.sgi.com Wed Jan 9 04:38:43 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g09Cchi03895 for linux-xfs-outgoing; Wed, 9 Jan 2002 04:38:43 -0800 Received: from mailhost.idcomm.com (mailhost.idcomm.com [207.40.196.14]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g09Ccbg03872 for ; Wed, 9 Jan 2002 04:38:37 -0800 Received: from idcomm.com (IDENT:P32n2h1sn02DfSczj5YIVyP9L4GR81jA@k56-pip12.idcomm.com [209.60.72.139]) by mailhost.idcomm.com (8.10.2/8.10.0) with ESMTP id g09BhIO02541 for ; Wed, 9 Jan 2002 04:43:18 -0700 Message-ID: <3C3C2C54.218C50C0@idcomm.com> Date: Wed, 09 Jan 2002 04:41:08 -0700 From: "D. Stimits" Reply-To: stimits@idcomm.com X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.6-pre1-xfs-4 i686) X-Accept-Language: en MIME-Version: 1.0 CC: linux-xfs@oss.sgi.com Subject: Re: Oracle install -- fixed? References: <20020109020705.GC4511@flounder.net> <20020109151750.1C9A.NEWSLETTER@teatime.com.tw> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 942 Lines: 31 Tommy Wu wrote: > > "Adam McKenna" wrote: > > > Does anyone know if whatever was causing Oracle not to install correctly on > > an XFS partition has been fixed? > > What problem ? Oracle version ? > We're running Oracle 9i on linux with XFS now.... > No any problem during Oracle install (only a binutils problem with "-z defs" during > making Oracle client library....) Perhaps it is mixing up the problem where the Oracle 8i does not like 2.4 kernels (regardless of being xfs or any other). See: http://www.zx81.org.uk/computing/oracle/oracle-howto/redhat7.html It involves adding a compat lib and then specifying: LD_ASSUME_KERNEL=2.2.5 D. Stimits, stimits@idcomm.com > > -- > > Tommy Wu > mailto:tommy@teatime.com.tw > http://www.teatime.com.tw/~tommy > ICQ: 22766091 > Mobile Phone: +886 936 909490 > TeaTime BBS +886 2 31515964 24Hrs V.Everything From owner-linux-xfs@oss.sgi.com Wed Jan 9 06:30:43 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g09EUh906124 for linux-xfs-outgoing; Wed, 9 Jan 2002 06:30:43 -0800 Received: from hotswap.cs.tum.edu (atbode95.informatik.tu-muenchen.de [131.159.32.66]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g09EUcg06102 for ; Wed, 9 Jan 2002 06:30:39 -0800 Received: from localhost (localhost [127.0.0.1]) by hotswap.cs.tum.edu (swapfix) with ESMTP id 1DDB438F95E4 for ; Wed, 9 Jan 2002 16:30:30 +0100 (CET) Received: from cs.tum.edu (kuschel.hotswap [172.16.16.190]) by hotswap.cs.tum.edu (swapfix) with ESMTP id A18EC38F95E0 for ; Wed, 9 Jan 2002 16:30:27 +0100 (CET) Message-ID: <3C3C45F2.D6533E44@cs.tum.edu> Date: Wed, 09 Jan 2002 14:30:26 +0100 From: Deti Fliegl Reply-To: fliegl@cs.tum.edu Organization: Munich University of Technology, CS, LRR X-Mailer: Mozilla 4.79 [en] (X11; U; Linux 2.4.15pre1-xfs i686) MIME-Version: 1.0 To: "linux-xfs@oss.sgi.com" Subject: Partition un(mount|repairable) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Virus-Scanned: by AMaViS perl-11 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 662 Lines: 20 Hi some days ago one of our systems crashed due to a defective CPU cooler. The XFS filesystem on it now is unmountable and unrepairable: .... imap claims in-use inode 686650 is free, correcting imap imap claims in-use inode 686651 is free, correcting imap imap claims in-use inode 686652 is free, correcting imap imap claims in-use inode 686653 is free, correcting imap imap claims in-use inode 686654 is free, correcting imap imap claims in-use inode 686655 is free, correcting imap avl_insert: Warning! duplicate range [0xbee40,0xbee80) fatal error -- xfs_repair: duplicate inode range Is there any chance left to get the filesystem working again? Deti From owner-linux-xfs@oss.sgi.com Wed Jan 9 07:41:06 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g09Ff6j07519 for linux-xfs-outgoing; Wed, 9 Jan 2002 07:41:06 -0800 Received: from rj.sgi.com (rj.sgi.com [204.94.215.100]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g09Ff1g07497 for ; Wed, 9 Jan 2002 07:41:01 -0800 Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by rj.sgi.com (8.11.4/8.11.4/linux-outbound_gateway-1.1) with ESMTP id g09EesY20909 for ; Wed, 9 Jan 2002 06:40:54 -0800 Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id IAA3954458; Wed, 9 Jan 2002 08:39:38 -0600 (CST) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id IAA26725; Wed, 9 Jan 2002 08:39:38 -0600 (CST) Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id g09Ecek29833; Wed, 9 Jan 2002 08:38:40 -0600 Subject: Re: Final : XFS_REPAIR ;-) From: Steve Lord To: Lionel DARNIS Cc: linux-xfs In-Reply-To: <1010573423.1660.4.camel@neotrantor> References: <1010573423.1660.4.camel@neotrantor> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/1.0.0.99+cvs.2001.12.18.08.57 (Preview Release) Date: 09 Jan 2002 08:38:40 -0600 Message-Id: <1010587120.29786.0.camel@jen.americas.sgi.com> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 678 Lines: 27 On Wed, 2002-01-09 at 04:50, Lionel DARNIS wrote: > > NICE !! > > It work I repaired my HD and I saved my mailboxes to another machine. > I was obliged to do a xfs_repair -L, so I supposed I lose some datas. > I think i will rebuild all my Debian/Woody XFS 2.4.17 quickly to be sure > not to have again the problem. Good to hear things got cleaned up - I presume this was all the same system, strange to hear that repair failed one time and worked another, not sure what happened there. Steve > > See ya, > > Lionel > > > -- Steve Lord voice: +1-651-683-3511 Principal Engineer, Filesystem Software email: lord@sgi.com From owner-linux-xfs@oss.sgi.com Wed Jan 9 08:08:53 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g09G8rJ08641 for linux-xfs-outgoing; Wed, 9 Jan 2002 08:08:53 -0800 Received: from zok.sgi.com (zok.sgi.com [204.94.215.101]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g09G8kg08618 for ; Wed, 9 Jan 2002 08:08:46 -0800 Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by zok.sgi.com (8.11.4/8.11.4/linux-outbound_gateway-1.1) with ESMTP id g09F8cA06978 for ; Wed, 9 Jan 2002 07:08:38 -0800 Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id JAA3891088; Wed, 9 Jan 2002 09:07:22 -0600 (CST) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id JAA17906; Wed, 9 Jan 2002 09:07:22 -0600 (CST) Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id g09F6OU04703; Wed, 9 Jan 2002 09:06:24 -0600 Subject: Re: Anyone know what this error means? From: Steve Lord To: Adam McKenna Cc: linux-xfs@oss.sgi.com In-Reply-To: <20020109003323.GW4511@flounder.net> References: <20020109003323.GW4511@flounder.net> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/1.0.0.99+cvs.2001.12.18.08.57 (Preview Release) Date: 09 Jan 2002 09:06:24 -0600 Message-Id: <1010588784.29727.30.camel@jen.americas.sgi.com> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 2156 Lines: 63 On Tue, 2002-01-08 at 18:33, Adam McKenna wrote: > This is an approx. 270 Gig RAID5 partition on an AMI Megaraid card on > 2.2.14-xfs (snapshot).. > > I get the following error when trying to create the filesystem: > > adam@braindb:~$ sudo mkfs.xfs -f /dev/sda9 > mkfs.xfs: warning - cannot set blocksize on block device /dev/sda9: Invalid > argument > meta-data=/dev/sda9 isize=256 agcount=65, agsize=1048576 blks > data = bsize=4096 blocks=67782243, imaxpct=25 > = sunit=0 swidth=0 blks, unwritten=0 > naming =version 2 bsize=4096 > log =internal log bsize=4096 blocks=8274 > realtime =none extsz=65536 blocks=0, rtextents=0 > File size limit exceeded > > The same thing happens if I try ext2: > > adam@braindb:~$ sudo mke2fs /dev/sda9 > mke2fs 1.22, 22-Jun-2001 for EXT2 FS 0.5b, 95/08/09 > Filesystem label= > OS type: Linux > Block size=4096 (log=2) > Fragment size=4096 (log=2) > 33898496 inodes, 67782243 blocks > 3389112 blocks (5.00%) reserved for the super user > First data block=0 > 2069 block groups > 32768 blocks per group, 32768 fragments per group > 16384 inodes per group > Superblock backups stored on blocks: > 32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632, > 2654208, > 4096000, 7962624, 11239424, 20480000, 23887872 > > File size limit exceeded > > adam@braindb:~$ uname -a > Linux braindb 2.4.14-xfs #3 SMP Fri Nov 30 01:58:14 PST 2001 i686 unknown > > Anyone know what is going on here? You are being bitten by O_LARGEFILE - the linux kernel now does not let an application which does not open files with O_LARGEFILE access beyond 2 Gbytes. Lots of applications seem to rely on glibc doing this for them - so it may be you need a newer glibc. Steve > > --Adam > > -- > Adam McKenna | GPG: 17A4 11F7 5E7E C2E7 08AA > http://flounder.net/publickey.html | 38B0 05D0 8BF7 2C6D 110A -- Steve Lord voice: +1-651-683-3511 Principal Engineer, Filesystem Software email: lord@sgi.com From owner-linux-xfs@oss.sgi.com Wed Jan 9 10:21:57 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g09ILvi10731 for linux-xfs-outgoing; Wed, 9 Jan 2002 10:21:57 -0800 Received: from hoju-ext.nks.net (hoju-ext.nks.net [216.139.204.180]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g09ILng10708 for ; Wed, 9 Jan 2002 10:21:51 -0800 Received: from two.nks.net (two.nks.net [192.168.1.22]) by hoju-ext.nks.net (8.9.3/8.9.3/Debian 8.9.3-21) with ESMTP id MAA11798; Wed, 9 Jan 2002 12:21:35 -0500 Subject: Re: Oracle install -- fixed? From: Derek Glidden To: Adam McKenna Cc: linux-xfs@oss.sgi.com In-Reply-To: <20020109020705.GC4511@flounder.net> References: <20020109020705.GC4511@flounder.net> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/1.0 (Preview Release) Date: 09 Jan 2002 12:21:35 -0500 Message-Id: <1010596896.18156.0.camel@two> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 1377 Lines: 31 On Tue, 2002-01-08 at 21:07, Adam McKenna wrote: > Does anyone know if whatever was causing Oracle not to install correctly on > an XFS partition has been fixed? > > If not, is there a developer willing to work with me on getting it fixed? I > really don't like having to use ext2 for one partition on our oracle boxes if > I can avoid it. Err, huh? I have Oracle 8i running on several Linux boxen that are all XFS with no problems. (They must've worked because I wasn't aware there was an issue. Chance are, they'll all break now. ;) -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- #!/usr/bin/perl -w $_='while(read+STDIN,$_,2048){$a=29;$b=73;$c=142;$t=255;@t=map {$_%16or$t^=$c^=($m=(11,10,116,100,11,122,20,100)[$_/16%8])&110; $t^=(72,@z=(64,72,$a^=12*($_%16-2?0:$m&17)),$b^=$_%64?12:0,@z) [$_%8]}(16..271);if((@a=unx"C*",$_)[20]&48){$h=5;$_=unxb24,join "",@b=map{xB8,unxb8,chr($_^$a[--$h+84])}@ARGV;s/...$/1$&/;$d= unxV,xb25,$_;$e=256|(ord$b[4])<<9|ord$b[3];$d=$d>>8^($f=$t&($d >>12^$d>>4^$d^$d/8))<<17,$e=$e>>8^($t&($g=($q=$e>>14&7^$e)^$q* 8^$q<<6))<<9,$_=$t[$_]^(($h>>=8)+=$f+(~$g&$t))for@a[128..$#a]} print+x"C*",@a}';s/x/pack+/g;eval usage: qrpff 153 2 8 105 225 < /mnt/dvd/VOB_FILENAME \ | extract_mpeg2 | mpeg2dec - http://www.cs.cmu.edu/~dst/DeCSS/Gallery/ http://www.eff.org/ http://www.anti-dmca.org/ From owner-linux-xfs@oss.sgi.com Wed Jan 9 10:34:27 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g09IYRc11185 for linux-xfs-outgoing; Wed, 9 Jan 2002 10:34:27 -0800 Received: from hoju-ext.nks.net (hoju-ext.nks.net [216.139.204.180]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g09IYIg11154 for ; Wed, 9 Jan 2002 10:34:19 -0800 Received: from two.nks.net (two.nks.net [192.168.1.22]) by hoju-ext.nks.net (8.9.3/8.9.3/Debian 8.9.3-21) with ESMTP id MAA11926; Wed, 9 Jan 2002 12:33:57 -0500 Subject: Re: Anyone know what this error means? From: Derek Glidden To: Nathan Scott Cc: Adam McKenna , linux-xfs@oss.sgi.com In-Reply-To: <20020109115309.A3063@wobbly.melbourne.sgi.com> References: <20020109003323.GW4511@flounder.net> <20020109115309.A3063@wobbly.melbourne.sgi.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/1.0 (Preview Release) Date: 09 Jan 2002 12:33:57 -0500 Message-Id: <1010597638.18156.2.camel@two> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 2562 Lines: 61 On Tue, 2002-01-08 at 19:53, Nathan Scott wrote: > On Tue, Jan 08, 2002 at 04:33:23PM -0800, Adam McKenna wrote: > > This is an approx. 270 Gig RAID5 partition on an AMI Megaraid card on > > 2.2.14-xfs (snapshot).. > > > > I get the following error when trying to create the filesystem: > > ... > > File size limit exceeded > > > > [assuming 2.4.14] - sounds familiar, think it was a bug from Linus' > kernel; using a more recent kernel version (2.4.16/17) should fix it. I did post this to lkml and got this in response from Andrew Morton: > > > > I've been experiencing random and occasional encounters with "File size > > limit exceeded" errors under 2.4 kernels when trying to make > > filesystems. > > I don't know if anyone has come forth to fix this yet. > > Apparently it's something to do with your shell setting > rlimits, and block devices are (bogusly) honouring those > settings. > > The word is that if you log in as `root' at the login > prompt, rather than using `su', the problem goes away. It apparently *is* a kernel bug, with the basic problem being that for some reason the kernel isn't recognizing ulimits if you 'su' to the root user. (Although in my experience it will also pop up if you "ssh" directly in as root.) If you log into the console as "root" and attempt the "mkfs" you should bypass this bug. I've run into it numerous times and I have been able to "mkfs" when logged in the console where I wasn't able to if logged in remotely. AFAIK, it's *not* fixed in recent kernels, as I've had the problem as recently as 2.4.16+xfs. It seems to have popped in somewhere around 2.4.9 or 2.4.10 or so, as that's the first time I saw people complaining about this problem on this list. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- #!/usr/bin/perl -w $_='while(read+STDIN,$_,2048){$a=29;$b=73;$c=142;$t=255;@t=map {$_%16or$t^=$c^=($m=(11,10,116,100,11,122,20,100)[$_/16%8])&110; $t^=(72,@z=(64,72,$a^=12*($_%16-2?0:$m&17)),$b^=$_%64?12:0,@z) [$_%8]}(16..271);if((@a=unx"C*",$_)[20]&48){$h=5;$_=unxb24,join "",@b=map{xB8,unxb8,chr($_^$a[--$h+84])}@ARGV;s/...$/1$&/;$d= unxV,xb25,$_;$e=256|(ord$b[4])<<9|ord$b[3];$d=$d>>8^($f=$t&($d >>12^$d>>4^$d^$d/8))<<17,$e=$e>>8^($t&($g=($q=$e>>14&7^$e)^$q* 8^$q<<6))<<9,$_=$t[$_]^(($h>>=8)+=$f+(~$g&$t))for@a[128..$#a]} print+x"C*",@a}';s/x/pack+/g;eval usage: qrpff 153 2 8 105 225 < /mnt/dvd/VOB_FILENAME \ | extract_mpeg2 | mpeg2dec - http://www.cs.cmu.edu/~dst/DeCSS/Gallery/ http://www.eff.org/ http://www.anti-dmca.org/ From owner-linux-xfs@oss.sgi.com Wed Jan 9 11:05:38 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g09J5cp12116 for linux-xfs-outgoing; Wed, 9 Jan 2002 11:05:38 -0800 Received: from Cantor.suse.de (ns.suse.de [213.95.15.193]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g09J5Xg12094 for ; Wed, 9 Jan 2002 11:05:33 -0800 Received: from Hermes.suse.de (Hermes.suse.de [213.95.15.136]) by Cantor.suse.de (Postfix) with ESMTP id 282701E7A7; Wed, 9 Jan 2002 19:05:26 +0100 (MET) Date: Wed, 9 Jan 2002 19:05:17 +0100 From: Andi Kleen To: Steve Lord Cc: Adam McKenna , linux-xfs@oss.sgi.com Subject: Re: Anyone know what this error means? Message-ID: <20020109190517.A19543@wotan.suse.de> References: <20020109003323.GW4511@flounder.net> <1010588784.29727.30.camel@jen.americas.sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1010588784.29727.30.camel@jen.americas.sgi.com> User-Agent: Mutt/1.3.22.1i Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 710 Lines: 21 On Wed, Jan 09, 2002 at 09:06:24AM -0600, Steve Lord wrote: > > Anyone know what is going on here? > > You are being bitten by O_LARGEFILE - the linux kernel now does not let > an application which does not open files with O_LARGEFILE access beyond > 2 Gbytes. > > Lots of applications seem to rely on glibc doing this for them - so it > may be you need a newer glibc. glibc alone never sets O_LARGEFILE. It usually needs a recompile of the application with -D_FILE_OFFSET_BITS=64 and some testing because that may break it. Normally O_LARGEFILE shouldn't be checked on block devices like /dev/sda9 though, so it's a bit strange that he gets the error here. strace would probably give clues. -Andi From owner-linux-xfs@oss.sgi.com Wed Jan 9 11:09:34 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g09J9Ye12274 for linux-xfs-outgoing; Wed, 9 Jan 2002 11:09:34 -0800 Received: from Cantor.suse.de (ns.suse.de [213.95.15.193]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g09J9Ug12252 for ; Wed, 9 Jan 2002 11:09:31 -0800 Received: from Hermes.suse.de (Hermes.suse.de [213.95.15.136]) by Cantor.suse.de (Postfix) with ESMTP id 94A151E7A7; Wed, 9 Jan 2002 19:09:23 +0100 (MET) Date: Wed, 9 Jan 2002 19:09:23 +0100 From: Andi Kleen To: Derek Glidden Cc: Nathan Scott , Adam McKenna , linux-xfs@oss.sgi.com Subject: Re: Anyone know what this error means? Message-ID: <20020109190923.B19543@wotan.suse.de> References: <20020109003323.GW4511@flounder.net> <20020109115309.A3063@wobbly.melbourne.sgi.com> <1010597638.18156.2.camel@two> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1010597638.18156.2.camel@two> User-Agent: Mutt/1.3.22.1i Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 686 Lines: 16 On Wed, Jan 09, 2002 at 12:33:57PM -0500, Derek Glidden wrote: > It apparently *is* a kernel bug, with the basic problem being that for > some reason the kernel isn't recognizing ulimits if you 'su' to the root > user. (Although in my experience it will also pop up if you "ssh" The problem is a broken pam_limits. It has nothing to do with the kernel. root, su and sudo have different pam setups. Likely all problems will go away if you comment out pam_limits from all files in /etc/pam.d/* There were historically some problems with quotas because the value meaning unlimited quota was once different in glibc and kernel, which caused and still causes endless confusion -Andi From owner-linux-xfs@oss.sgi.com Wed Jan 9 11:19:38 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g09JJcs12576 for linux-xfs-outgoing; Wed, 9 Jan 2002 11:19:38 -0800 Received: from UberGeek.coremetrics.com ([209.184.141.163]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g09JJUg12545 for ; Wed, 9 Jan 2002 11:19:31 -0800 Received: (from austin@localhost) by UberGeek.coremetrics.com (8.11.6/8.11.6) id g09IILO07001; Wed, 9 Jan 2002 12:18:21 -0600 X-Authentication-Warning: UberGeek.coremetrics.com: austin set sender to austin@coremetrics.com using -f Subject: Re: Anyone know what this error means? From: Austin Gonyou To: Andi Kleen Cc: Derek Glidden , Nathan Scott , Adam McKenna , linux-xfs@oss.sgi.com In-Reply-To: <20020109190923.B19543@wotan.suse.de> References: <20020109190923.B19543@wotan.suse.de> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-VVRFDQZYoIVXPBCK7KYI" X-Mailer: Evolution/1.0.0.99+cvs.2001.12.18.08.57 (Preview Release) Date: 09 Jan 2002 12:18:21 -0600 Message-Id: <1010600301.6904.10.camel@UberGeek> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 1550 Lines: 49 --=-VVRFDQZYoIVXPBCK7KYI Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Does this only affect systems with quota's turned on in the kernel? On Wed, 2002-01-09 at 12:09, Andi Kleen wrote: > On Wed, Jan 09, 2002 at 12:33:57PM -0500, Derek Glidden wrote: > > It apparently *is* a kernel bug, with the basic problem being that for > > some reason the kernel isn't recognizing ulimits if you 'su' to the > root > > user. (Although in my experience it will also pop up if you "ssh" >=20 > The problem is a broken pam_limits. It has nothing to do with the > kernel. >=20 > root, su and sudo have different pam setups. Likely all problems will go > away if you comment out pam_limits from all files in /etc/pam.d/*=20 >=20 > There were historically some problems with quotas because the value=20 > meaning unlimited quota was once different in glibc and kernel, which > caused and still causes endless confusion >=20 > -Andi --=20 Austin Gonyou Systems Architect, CCNA Coremetrics, Inc. Phone: 512-698-7250 email: austin@coremetrics.com "It is the part of a good shepherd to shear his flock, not to skin it." Latin Proverb --=-VVRFDQZYoIVXPBCK7KYI Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQA8PIlt94g6ZVmFMoIRAqvCAKCjTj+W3jfd5Ht2aVHahy+7ttDHGQCfZBJv L/LmzH7+0yFXxKm+8f8qJl0= =8i6E -----END PGP SIGNATURE----- --=-VVRFDQZYoIVXPBCK7KYI-- From owner-linux-xfs@oss.sgi.com Wed Jan 9 11:23:12 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g09JNCv12734 for linux-xfs-outgoing; Wed, 9 Jan 2002 11:23:12 -0800 Received: from zok.sgi.com (zok.sgi.com [204.94.215.101]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g09JN8g12711 for ; Wed, 9 Jan 2002 11:23:08 -0800 Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by zok.sgi.com (8.11.4/8.11.4/linux-outbound_gateway-1.1) with ESMTP id g09IN1A21074 for ; Wed, 9 Jan 2002 10:23:01 -0800 Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id MAA4037940; Wed, 9 Jan 2002 12:21:44 -0600 (CST) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id MAA46904; Wed, 9 Jan 2002 12:21:44 -0600 (CST) Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id g09IKja12438; Wed, 9 Jan 2002 12:20:45 -0600 Subject: Re: Anyone know what this error means? From: Steve Lord To: Andi Kleen Cc: Adam McKenna , linux-xfs@oss.sgi.com In-Reply-To: <20020109190517.A19543@wotan.suse.de> References: <20020109003323.GW4511@flounder.net> <1010588784.29727.30.camel@jen.americas.sgi.com> <20020109190517.A19543@wotan.suse.de> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/1.0.0.99+cvs.2001.12.18.08.57 (Preview Release) Date: 09 Jan 2002 12:20:45 -0600 Message-Id: <1010600445.29786.114.camel@jen.americas.sgi.com> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 1072 Lines: 32 On Wed, 2002-01-09 at 12:05, Andi Kleen wrote: > On Wed, Jan 09, 2002 at 09:06:24AM -0600, Steve Lord wrote: > > > Anyone know what is going on here? > > > > You are being bitten by O_LARGEFILE - the linux kernel now does not let > > an application which does not open files with O_LARGEFILE access beyond > > 2 Gbytes. > > > > Lots of applications seem to rely on glibc doing this for them - so it > > may be you need a newer glibc. > > glibc alone never sets O_LARGEFILE. It usually needs a recompile > of the application with -D_FILE_OFFSET_BITS=64 and some testing because > that may break it. > > Normally O_LARGEFILE shouldn't be checked on block devices like /dev/sda9 > though, so it's a bit strange that he gets the error here. > > strace would probably give clues. The reason I said glibc was I could not find O_LARGEFILE in the xfs user space source I looked at, but I could in strace. Steve > > -Andi -- Steve Lord voice: +1-651-683-3511 Principal Engineer, Filesystem Software email: lord@sgi.com From owner-linux-xfs@oss.sgi.com Wed Jan 9 11:25:36 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g09JPat12886 for linux-xfs-outgoing; Wed, 9 Jan 2002 11:25:36 -0800 Received: from Cantor.suse.de (ns.suse.de [213.95.15.193]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g09JPYg12864 for ; Wed, 9 Jan 2002 11:25:34 -0800 Received: from Hermes.suse.de (Hermes.suse.de [213.95.15.136]) by Cantor.suse.de (Postfix) with ESMTP id BAB061E7A7; Wed, 9 Jan 2002 19:25:26 +0100 (MET) Date: Wed, 9 Jan 2002 19:25:26 +0100 From: Andi Kleen To: Austin Gonyou Cc: Andi Kleen , Derek Glidden , Nathan Scott , Adam McKenna , linux-xfs@oss.sgi.com Subject: Re: Anyone know what this error means? Message-ID: <20020109192526.A27808@wotan.suse.de> References: <20020109190923.B19543@wotan.suse.de> <1010600301.6904.10.camel@UberGeek> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1010600301.6904.10.camel@UberGeek> User-Agent: Mutt/1.3.22.1i Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 257 Lines: 8 On Wed, Jan 09, 2002 at 12:18:21PM -0600, Austin Gonyou wrote: > Does this only affect systems with quota's turned on in the kernel? Sorry it was a typo. I didn't mean quotas, but rlimits. These are always in every kernel and cannot be turned off. -Andi From owner-linux-xfs@oss.sgi.com Wed Jan 9 11:26:46 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g09JQkB13010 for linux-xfs-outgoing; Wed, 9 Jan 2002 11:26:46 -0800 Received: from hoju-ext.nks.net (hoju-ext.nks.net [216.139.204.180]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g09JQeg12981 for ; Wed, 9 Jan 2002 11:26:41 -0800 Received: from two.nks.net (two.nks.net [192.168.1.22]) by hoju-ext.nks.net (8.9.3/8.9.3/Debian 8.9.3-21) with ESMTP id NAA12377; Wed, 9 Jan 2002 13:26:25 -0500 Subject: Re: Anyone know what this error means? From: Derek Glidden To: Andi Kleen Cc: linux-xfs@oss.sgi.com In-Reply-To: <20020109190923.B19543@wotan.suse.de> References: <20020109003323.GW4511@flounder.net> <20020109115309.A3063@wobbly.melbourne.sgi.com> <1010597638.18156.2.camel@two> <20020109190923.B19543@wotan.suse.de> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/1.0 (Preview Release) Date: 09 Jan 2002 13:26:24 -0500 Message-Id: <1010600785.18157.4.camel@two> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 1506 Lines: 33 On Wed, 2002-01-09 at 13:09, Andi Kleen wrote: > On Wed, Jan 09, 2002 at 12:33:57PM -0500, Derek Glidden wrote: > > It apparently *is* a kernel bug, with the basic problem being that for > > some reason the kernel isn't recognizing ulimits if you 'su' to the root > > user. (Although in my experience it will also pop up if you "ssh" > > The problem is a broken pam_limits. It has nothing to do with the kernel. > > root, su and sudo have different pam setups. Likely all problems will go > away if you comment out pam_limits from all files in /etc/pam.d/* Ok, my bad. I was under the impression that it had something to do with the way the kernel handled things. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- #!/usr/bin/perl -w $_='while(read+STDIN,$_,2048){$a=29;$b=73;$c=142;$t=255;@t=map {$_%16or$t^=$c^=($m=(11,10,116,100,11,122,20,100)[$_/16%8])&110; $t^=(72,@z=(64,72,$a^=12*($_%16-2?0:$m&17)),$b^=$_%64?12:0,@z) [$_%8]}(16..271);if((@a=unx"C*",$_)[20]&48){$h=5;$_=unxb24,join "",@b=map{xB8,unxb8,chr($_^$a[--$h+84])}@ARGV;s/...$/1$&/;$d= unxV,xb25,$_;$e=256|(ord$b[4])<<9|ord$b[3];$d=$d>>8^($f=$t&($d >>12^$d>>4^$d^$d/8))<<17,$e=$e>>8^($t&($g=($q=$e>>14&7^$e)^$q* 8^$q<<6))<<9,$_=$t[$_]^(($h>>=8)+=$f+(~$g&$t))for@a[128..$#a]} print+x"C*",@a}';s/x/pack+/g;eval usage: qrpff 153 2 8 105 225 < /mnt/dvd/VOB_FILENAME \ | extract_mpeg2 | mpeg2dec - http://www.cs.cmu.edu/~dst/DeCSS/Gallery/ http://www.eff.org/ http://www.anti-dmca.org/ From owner-linux-xfs@oss.sgi.com Wed Jan 9 12:29:30 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g09KTUc14237 for linux-xfs-outgoing; Wed, 9 Jan 2002 12:29:30 -0800 Received: from pneumatic-tube.sgi.com (pneumatic-tube.sgi.com [204.94.214.22]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g09KTQg14213 for ; Wed, 9 Jan 2002 12:29:26 -0800 Received: from relay1.corp.sgi.com (spindle.corp.sgi.com [198.29.75.13]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id LAA03442 for ; Wed, 9 Jan 2002 11:30:04 -0800 (PST) mail_from (florin@sgi.com) Received: from stantz.corp.sgi.com (stantz.corp.sgi.com [130.62.4.42]) by relay1.corp.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) via ESMTP id LAA49151 for ; Wed, 9 Jan 2002 11:28:53 -0800 (PST) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by stantz.corp.sgi.com (Postfix) with ESMTP id 5C7C713650B for ; Wed, 9 Jan 2002 11:28:53 -0800 (PST) Subject: Re: 1.0.2a anaconda hiccup From: Florin ANDREI To: linux-xfs@oss.sgi.com In-Reply-To: <1010538129004709@caramail.com> References: <1010538129004709@caramail.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/1.0 (Preview Release) Date: 09 Jan 2002 11:28:53 -0800 Message-Id: <1010604533.1782.1.camel@stantz.corp.sgi.com> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 583 Lines: 18 On Tue, 2002-01-08 at 18:02, LENHOF Jean-Yves wrote: > > Are you really using 1.0.2a ? It sounds like a > 2.4.7-10SGI-XFS_PR1BOOT and not like 2.4.9-13SGI-XFSBOOT (cf > the kernel-boot rpm package included in 1.0.2a) ? Well, i'm using whatever is provided in the ISO image. But somehow i don't believe this is the problem. I see that there's an update disk for Anaconda on Red Hat's site. Are these updates included in XFS-1.0.2a? -- Florin Andrei "The fast pace of IRC often prevents deeper thoughts, which is definitely the point for many people who use IRC." - Ingo Molnar From owner-linux-xfs@oss.sgi.com Wed Jan 9 12:33:24 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g09KXOi14443 for linux-xfs-outgoing; Wed, 9 Jan 2002 12:33:24 -0800 Received: from sgi.com (sgi-too.SGI.COM [204.94.211.39]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g09KXKg14421 for ; Wed, 9 Jan 2002 12:33:20 -0800 Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id LAA08694 for ; Wed, 9 Jan 2002 11:30:56 -0800 (PST) mail_from (sandeen@sgi.com) Received: from poppy-e185.americas.sgi.com (poppy-e185.americas.sgi.com [128.162.185.207]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id NAA4048343; Wed, 9 Jan 2002 13:32:01 -0600 (CST) Received: from stout.americas.sgi.com (stout.americas.sgi.com [128.162.187.5]) by poppy-e185.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.7) with ESMTP id NAA34270; Wed, 9 Jan 2002 13:32:00 -0600 (CST) Subject: Re: 1.0.2a anaconda hiccup From: Eric Sandeen To: Florin ANDREI Cc: linux-xfs@oss.sgi.com In-Reply-To: <1010604533.1782.1.camel@stantz.corp.sgi.com> References: <1010538129004709@caramail.com> <1010604533.1782.1.camel@stantz.corp.sgi.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/1.0 (Preview Release) Date: 09 Jan 2002 13:32:00 -0600 Message-Id: <1010604721.17321.0.camel@stout.americas.sgi.com> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 873 Lines: 25 On Wed, 2002-01-09 at 13:28, Florin ANDREI wrote: > On Tue, 2002-01-08 at 18:02, LENHOF Jean-Yves wrote: > > > > Are you really using 1.0.2a ? It sounds like a > > 2.4.7-10SGI-XFS_PR1BOOT and not like 2.4.9-13SGI-XFSBOOT (cf > > the kernel-boot rpm package included in 1.0.2a) ? > > Well, i'm using whatever is provided in the ISO image. But somehow i > don't believe this is the problem. > > I see that there's an update disk for Anaconda on Red Hat's site. Are > these updates included in XFS-1.0.2a? Hm, no, they're not. I'll have to take a look at that. Sorry for no reply on your original message, I took a quick look and didn't see anything obvious... out of curiosity, does it work any better in graphical mode? Or can you only run it in text mode? -Eric -- Eric Sandeen XFS for Linux http://oss.sgi.com/projects/xfs sandeen@sgi.com SGI, Inc. From owner-linux-xfs@oss.sgi.com Wed Jan 9 13:06:31 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g09L6VY15842 for linux-xfs-outgoing; Wed, 9 Jan 2002 13:06:31 -0800 Received: from atlrel8.hp.com (atlrel8.hp.com [156.153.255.206]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g09L6Jg15814 for ; Wed, 9 Jan 2002 13:06:19 -0800 Received: from xatlrelay2.atl.hp.com (xatlrelay2.atl.hp.com [15.45.89.191]) by atlrel8.hp.com (Postfix) with ESMTP id 82ADFE003D5; Wed, 9 Jan 2002 15:06:12 -0500 (EST) Received: from xatlbh4.atl.hp.com (xatlbh4.atl.hp.com [15.45.89.189]) by xatlrelay2.atl.hp.com (Postfix) with ESMTP id 71D86400090; Wed, 9 Jan 2002 15:06:12 -0500 (EST) Received: by xatlbh4.atl.hp.com with Internet Mail Service (5.5.2653.19) id ; Wed, 9 Jan 2002 15:06:12 -0500 Message-ID: From: "ZINKEVICIUS,MATT (HP-Loveland,ex1)" To: "'Timothy Shimmin'" , Tad Dolphay Cc: "ZINKEVICIUS,MATT (HP-Loveland,ex1)" , "'Steve Lord'" , linux-xfs@oss.sgi.com Subject: RE: link() messes up file attributes Date: Wed, 9 Jan 2002 15:06:09 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 2901 Lines: 99 POSIX ACLs are not even compiled into the kernel. --Matt > -----Original Message----- > From: Timothy Shimmin [mailto:tes@boing.melbourne.sgi.com] > Sent: Tuesday, January 08, 2002 9:45 PM > To: Tad Dolphay > Cc: "ZINKEVICIUS,MATT (HP-Loveland,ex1)"; 'Steve Lord'; > linux-xfs@oss.sgi.com > Subject: Re: link() messes up file attributes > > > On Tue, Jan 08, 2002 at 08:43:56PM -0600, Tad Dolphay wrote: > > > > > > Okay here is the current situation... > > > > > > Without your patch: > > > over NFSv2: open new file with 666 permission creates > file with 644 > > > permissions > > > over NFSv3: open new file works fine, but hard-linking > changes file perm to > > > 644 > > > > > > With your path: > > > over NFSv2: (same as above) > > > over NFSv3: Works fine > > > > > > So you patch does have some affect. > > > > > I vaguely remember a similar problem reported before. If I > remember correctly, > > it had something to do with the default acls on the > exported directory. Could > > you do a "chacl -l ." on the exported directory to check > the default acls > > and then possibly do "chacl -d u::rwx,g::rwx,o::rwx ." to > set the default > > acls. Then see if the problem goes away. > > > Yes, I was wondering the same thing. > This is filed in pv#843903 (sgi bug#). > The umask of nfsd is being applied when it shouldn't be > (if we find we don't have a default ACL then we apply the umask). > Giving a default mininum ACL with all permissions on as > Tad suggests (-d u::rwx,g::rwx,o::rwx) > would stop the umask from being applied. > (This, of course, is not a fix, but would be good to check :) > > Are ACLs enabled ? > > > (The fix for pv#843903 was being deferred 'til we had more complete > integration with Andreas G's kernel EA/ACL patch) > > --Tim > > > > Tad > > > --Matt > > > > > > > -----Original Message----- > > > > From: Steve Lord [mailto:lord@sgi.com] > > > > Sent: Tuesday, January 08, 2002 2:57 PM > > > > To: ZINKEVICIUS,MATT " "(HP-Loveland,ex1) > > > > Cc: linux-xfs@oss.sgi.com > > > > Subject: RE: link() messes up file attributes > > > > > > > > > > > > On Tue, 2002-01-08 at 15:49, ZINKEVICIUS,MATT > (HP-Loveland,ex1) wrote: > > > > > Nevermind, the fix didn't help. Occured again today :-( > > > > > > > > Right, I am not totally surprised, the difference > between the two > > > > code paths should be a noop. This was just the only > recent change > > > > related to xfs. > > > > > > > > I suppose you have HP clients on the other end of the wire here? > > > > > > > > Since this is an intermittent problem, how can you be > totally sure > > > > it is actually XFS which is at fault? > > > > > > > > Steve > > > > > > > > -- > > > > > > > > Steve Lord voice: > +1-651-683-3511 > > > > Principal Engineer, Filesystem Software email: > lord@sgi.com > > > > > > > > > > From owner-linux-xfs@oss.sgi.com Wed Jan 9 13:15:50 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g09LFoc16399 for linux-xfs-outgoing; Wed, 9 Jan 2002 13:15:50 -0800 Received: from pneumatic-tube.sgi.com (pneumatic-tube.sgi.com [204.94.214.22]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g09LFig16377 for ; Wed, 9 Jan 2002 13:15:44 -0800 Received: from relay1.corp.sgi.com (spindle.corp.sgi.com [198.29.75.13]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id MAA02326 for ; Wed, 9 Jan 2002 12:16:19 -0800 (PST) mail_from (florin@sgi.com) Received: from stantz.corp.sgi.com (stantz.corp.sgi.com [130.62.4.42]) by relay1.corp.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) via ESMTP id MAA51448 for ; Wed, 9 Jan 2002 12:15:08 -0800 (PST) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by stantz.corp.sgi.com (Postfix) with ESMTP id B21B113650B for ; Wed, 9 Jan 2002 12:15:08 -0800 (PST) Subject: Re: 1.0.2a anaconda hiccup From: Florin ANDREI To: linux-xfs@oss.sgi.com In-Reply-To: <1010604721.17321.0.camel@stout.americas.sgi.com> References: <1010538129004709@caramail.com> <1010604533.1782.1.camel@stantz.corp.sgi.com> <1010604721.17321.0.camel@stout.americas.sgi.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/1.0 (Preview Release) Date: 09 Jan 2002 12:15:08 -0800 Message-Id: <1010607308.1903.3.camel@stantz.corp.sgi.com> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 705 Lines: 20 On Wed, 2002-01-09 at 11:32, Eric Sandeen wrote: > > Sorry for no reply on your original message, I took a quick look and > didn't see anything obvious... out of curiosity, does it work any > better in graphical mode? Or can you only run it in text mode? heh, mouse on the server... :o) But, ok, i tried the graphical install, and i was able to change the Format option of the /boot partition from No to Yes, and it didn't crashed; in text-mode, it was an instant death. ;-) I didn't went beyond that, because i still have to backup the machine, etc. -- Florin Andrei "The fast pace of IRC often prevents deeper thoughts, which is definitely the point for many people who use IRC." - Ingo Molnar From owner-linux-xfs@oss.sgi.com Wed Jan 9 14:23:07 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g09MN7l17789 for linux-xfs-outgoing; Wed, 9 Jan 2002 14:23:07 -0800 Received: from rj.sgi.com (rj.sgi.com [204.94.215.100]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g09MN4g17767 for ; Wed, 9 Jan 2002 14:23:04 -0800 Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by rj.sgi.com (8.11.4/8.11.4/linux-outbound_gateway-1.1) with ESMTP id g09LMuY17007 for ; Wed, 9 Jan 2002 13:22:56 -0800 Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id PAA4036629 for ; Wed, 9 Jan 2002 15:21:40 -0600 (CST) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id PAA57951 for ; Wed, 9 Jan 2002 15:21:40 -0600 (CST) From: Steve Lord Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id g09LKe215482; Wed, 9 Jan 2002 15:20:40 -0600 Message-Id: <200201092120.g09LKe215482@jen.americas.sgi.com> Date: Wed, 9 Jan 2002 15:20:40 -0600 Subject: TAKE - fix mix of buffered and direct I/O to a file in parallel Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 568 Lines: 17 Buffered reads were getting stomped on by direct writes which happened at the same time. I doubt anyone was doing this outside of test programs. Date: Wed Jan 9 13:18:10 PST 2002 Workarea: jen.americas.sgi.com:/src/lord/xfs-linux.2.4 The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:109311a linux/fs/xfs/linux/xfs_lrw.c - 1.119 - Fix parallel direct and buffered I/O on a file, do not allow the page invalidate which comes out of a direct write to happen at the same time as a buffered read. From owner-linux-xfs@oss.sgi.com Wed Jan 9 15:25:28 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g09NPSl18929 for linux-xfs-outgoing; Wed, 9 Jan 2002 15:25:28 -0800 Received: from deliverator.sgi.com (deliverator.sgi.com [204.94.214.10]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g09NPIg18904 for ; Wed, 9 Jan 2002 15:25:18 -0800 Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id OAA18234 for ; Wed, 9 Jan 2002 14:25:02 -0800 (PST) mail_from (sandeen@sgi.com) Received: from poppy-e185.americas.sgi.com (poppy-e185.americas.sgi.com [128.162.185.207]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id QAA4044782; Wed, 9 Jan 2002 16:23:59 -0600 (CST) Received: from stout.americas.sgi.com (stout.americas.sgi.com [128.162.187.5]) by poppy-e185.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.7) with ESMTP id QAA41241; Wed, 9 Jan 2002 16:23:59 -0600 (CST) Subject: Re: Unable to get XFS, ext3, reiserfs & LVM to coexist happily From: Eric Sandeen To: Adrian Head Cc: Linux XFS Mailing List , linux-lvm@sistina.com In-Reply-To: <200201020451.g024pPg00867@oss.sgi.com> References: <200201020451.g024pPg00867@oss.sgi.com> Content-Type: multipart/mixed; boundary="=-3JA8M45IzWcayTxBRmV3" X-Mailer: Evolution/1.0 (Preview Release) Date: 09 Jan 2002 16:23:59 -0600 Message-Id: <1010615039.17321.2.camel@stout.americas.sgi.com> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 2409 Lines: 70 --=-3JA8M45IzWcayTxBRmV3 Content-Type: text/plain Content-Transfer-Encoding: 7bit On Tue, 2002-01-01 at 21:51, Adrian Head wrote: > I'm starting to play around with LVM with the goal of having XFS, ext3, > reiserfs and LVM coexist nicely together. > > Has anyone been able to get , ext3, reiserfs, XFS and LVM running nicely > together? This patch, on top of xfs cvs (2.4.17-xfs), with the LVM 1.0.1 upgrade patch applied, then the VFS lock patch, works for me. Note that this is stolen from the 1.0.1rc4(ish) version of LVM in Linus' kernel. It uses the built-in blocks from lv_snap->lv_iobuf->blocks rather than declaring a new chunk of blocks. I tested snapshot creation & overflow with ext2, ext3, reiser, and xfs. I have not looked closely enough to see why xfs breaks w/o this patch, and why it works with it, but... give it a shot. -Eric -- Eric Sandeen XFS for Linux http://oss.sgi.com/projects/xfs sandeen@sgi.com SGI, Inc. --=-3JA8M45IzWcayTxBRmV3 Content-Disposition: attachment; filename=lvm-1.0.1-xfs-fix.patch Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=ISO-8859-1 --- lvm-snap.c Wed Jan 9 16:10:01 2002 +++ /localhome/eric/lvm-1.0.1-works/lvm-snap.c Wed Jan 9 16:07:52 2002 @@ -349,7 +349,6 @@ unsigned long phys_start; int idx =3D lv_snap->lv_remap_ptr, chunk_size =3D lv_snap->lv_chunk_size; struct kiobuf * iobuf; - unsigned long blocks[KIO_MAX_SECTORS]; int blksize_snap, blksize_org, min_blksize, max_blksize; int max_sectors, nr_sectors; =20 @@ -400,19 +399,19 @@ =20 iobuf->length =3D nr_sectors << 9; =20 - if (!lvm_snapshot_prepare_blocks(blocks, phys_start, + if (!lvm_snapshot_prepare_blocks(iobuf->blocks, phys_start, nr_sectors, blksize_org)) goto fail_prepare; =20 - if (__brw_kiovec(READ, 1, &iobuf, org_phys_dev, blocks, + if (__brw_kiovec(READ, 1, &iobuf, org_phys_dev, iobuf->blocks, blksize_org, lv_snap) !=3D (nr_sectors<<9)) goto fail_raw_read; =20 - if (!lvm_snapshot_prepare_blocks(blocks, snap_start, + if (!lvm_snapshot_prepare_blocks(iobuf->blocks, snap_start, nr_sectors, blksize_snap)) goto fail_prepare; =20 - if (__brw_kiovec(WRITE, 1, &iobuf, snap_phys_dev, blocks, + if (__brw_kiovec(WRITE, 1, &iobuf, snap_phys_dev, iobuf->blocks, blksize_snap, lv_snap) !=3D (nr_sectors<<9)) goto fail_raw_write; =20 --=-3JA8M45IzWcayTxBRmV3-- From owner-linux-xfs@oss.sgi.com Wed Jan 9 15:41:01 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g09Nf1j19380 for linux-xfs-outgoing; Wed, 9 Jan 2002 15:41:01 -0800 Received: from yog-sothoth.sgi.com (eugate.sgi.com [192.48.160.10]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g09Nevg19355 for ; Wed, 9 Jan 2002 15:40:57 -0800 Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by yog-sothoth.sgi.com (980305.SGI.8.8.8-aspam-6.2/980304.SGI-aspam-europe) via ESMTP id XAA1542942 for ; Wed, 9 Jan 2002 23:38:31 +0100 (CET) mail_from (sandeen@sgi.com) Received: from poppy-e185.americas.sgi.com (poppy-e185.americas.sgi.com [128.162.185.207]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id QAA4051358; Wed, 9 Jan 2002 16:39:36 -0600 (CST) Received: from stout.americas.sgi.com (stout.americas.sgi.com [128.162.187.5]) by poppy-e185.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.7) with ESMTP id QAA45230; Wed, 9 Jan 2002 16:39:36 -0600 (CST) Subject: Re: Unable to get XFS, ext3, reiserfs & LVM to coexist happily From: Eric Sandeen To: Eric Sandeen Cc: Adrian Head , Linux XFS Mailing List , linux-lvm@sistina.com In-Reply-To: <1010615039.17321.2.camel@stout.americas.sgi.com> References: <200201020451.g024pPg00867@oss.sgi.com> <1010615039.17321.2.camel@stout.americas.sgi.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/1.0 (Preview Release) Date: 09 Jan 2002 16:39:36 -0600 Message-Id: <1010615976.17321.5.camel@stout.americas.sgi.com> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 638 Lines: 20 On Wed, 2002-01-09 at 16:23, Eric Sandeen wrote: > I tested snapshot creation & overflow with ext2, ext3, reiser, and xfs. > I have not looked closely enough to see why xfs breaks w/o this patch, > and why it works with it, but... give it a shot. Ah, ok. Steve pointed out that in the stock LVM version, unsigned long blocks[KIO_MAX_SECTORS]; plops 4k down on the stack; xfs's stack must be a bit bigger than other filesystems, and it overflows... that's why xfs was failing with that code, and other filesystems survived. -Eric -- Eric Sandeen XFS for Linux http://oss.sgi.com/projects/xfs sandeen@sgi.com SGI, Inc. From owner-linux-xfs@oss.sgi.com Wed Jan 9 17:33:13 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0A1XDC22478 for linux-xfs-outgoing; Wed, 9 Jan 2002 17:33:13 -0800 Received: from deliverator.sgi.com (deliverator.sgi.com [204.94.214.10]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0A1X7g22455 for ; Wed, 9 Jan 2002 17:33:07 -0800 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via SMTP id QAA05036 for ; Wed, 9 Jan 2002 16:32:49 -0800 (PST) mail_from (nathans@wobbly.melbourne.sgi.com) Received: from wobbly.melbourne.sgi.com (wobbly.melbourne.sgi.com [134.14.55.135]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id LAA16516; Thu, 10 Jan 2002 11:31:43 +1100 Received: (from nathans@localhost) by wobbly.melbourne.sgi.com (SGI-8.9.3/8.9.3) id LAA05949; Thu, 10 Jan 2002 11:31:42 +1100 (AEDT) Date: Thu, 10 Jan 2002 11:31:41 +1100 From: Nathan Scott To: Deti Fliegl Cc: "linux-xfs@oss.sgi.com" Subject: Re: Partition un(mount|repairable) Message-ID: <20020110113141.B5679@wobbly.melbourne.sgi.com> References: <3C3C45F2.D6533E44@cs.tum.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <3C3C45F2.D6533E44@cs.tum.edu>; from fliegl@cs.tum.edu on Wed, Jan 09, 2002 at 02:30:26PM +0100 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 1265 Lines: 37 hi there, On Wed, Jan 09, 2002 at 02:30:26PM +0100, Deti Fliegl wrote: > Hi > > some days ago one of our systems crashed due to a defective CPU cooler. > The XFS filesystem on it now is unmountable and unrepairable: > > .... > imap claims in-use inode 686650 is free, correcting imap > imap claims in-use inode 686651 is free, correcting imap > imap claims in-use inode 686652 is free, correcting imap > imap claims in-use inode 686653 is free, correcting imap > imap claims in-use inode 686654 is free, correcting imap > imap claims in-use inode 686655 is free, correcting imap > avl_insert: Warning! duplicate range [0xbee40,0xbee80) > > fatal error -- xfs_repair: duplicate inode range Yes, this one seems to keep reappearing for some reason. I have had a quick look at the repair code - its fairly hairy and I'd really need a filesystem which exhibits the problem to try and fix xfs_repair here. > Is there any chance left to get the filesystem working again? Not with the current version of xfs_repair. I have so far been unable to corrupt a filesystem in this way - is there any chance I could get access to the filesystem image from you? (could you compress it and make it ftp'able for just me or something like that?). many thanks. -- Nathan From owner-linux-xfs@oss.sgi.com Wed Jan 9 19:04:52 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0A34qf25525 for linux-xfs-outgoing; Wed, 9 Jan 2002 19:04:52 -0800 Received: from coredump.sh0n.net (qmailremote@CPEdeadbeef0000.cpe.net.cable.rogers.com [24.100.234.67]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0A34jg25503 for ; Wed, 9 Jan 2002 19:04:45 -0800 Received: (qmail 2601 invoked from network); 10 Jan 2002 02:05:31 -0000 Received: from coredump.sh0n.net (sh0n@24.100.234.67) by coredump.sh0n.net with SMTP; 10 Jan 2002 02:05:31 -0000 Date: Wed, 9 Jan 2002 21:05:30 -0500 (EST) From: Shawn Starr To: linux-xfs@oss.sgi.com Subject: Re: ANNOUCEMENT: XFS support to the -mjc 2.4.17 branch (fwd) In-Reply-To: <200201092120.g09LKe215482@jen.americas.sgi.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 1215 Lines: 48 It should be going in soon, Just trying to keep up to your TAKEs in CVS :) Linux coredump 2.4.18pre1-mjc3-xfs #2 Tue Jan 8 23:54:58 EST 2002 i586 unknown 9:04pm up 20:59, 7 users, load average: 0.38, 0.47, 0.47 (since last TAKE update). I wish there was an easier way to merge the diffs with linux-2.4-xfs/linux with my tree (pre -mjcX-xfs) Shawn. -- List: linux-xfs Subject: Re: ANNOUCEMENT: XFS support to the -mjc 2.4.17 branch (fwd) From: Seth Mos Date: 2002-01-02 22:17:12 [Download message RAW] On Thu, 3 Jan 2002, Keith Owens wrote: > For those not on linux-kernel, the -mjc branch is trying to take up on > 2.4 where -ac left off. > > ------- Forwarded Message > > Return-Path: > Date: Wed, 2 Jan 2002 13:06:41 -0500 (EST) > From: Shawn Starr > To: linux-kernel@vger.kernel.org > Subject: ANNOUCEMENT: XFS support to the -mjc 2.4.17 branch > > > It's been running for 8 hours. There's still a little work to go but so > far It's up. Excellent, our userbase just upped by a couple of thousand :-) That's a nice new year presemt isn't it? Happy new Year everyone. (Yeah I know I'm late). Cheers Seth From owner-linux-xfs@oss.sgi.com Wed Jan 9 19:22:54 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0A3Msw26488 for linux-xfs-outgoing; Wed, 9 Jan 2002 19:22:54 -0800 Received: from coredump.sh0n.net (qmailremote@CPEdeadbeef0000.cpe.net.cable.rogers.com [24.100.234.67]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0A3Mjg26466 for ; Wed, 9 Jan 2002 19:22:46 -0800 Received: (qmail 4071 invoked from network); 10 Jan 2002 02:23:28 -0000 Received: from coredump.sh0n.net (sh0n@24.100.234.67) by coredump.sh0n.net with SMTP; 10 Jan 2002 02:23:28 -0000 Date: Wed, 9 Jan 2002 21:23:28 -0500 (EST) From: Shawn Starr To: linux-xfs@oss.sgi.com Subject: Re: ANNOUCEMENT: XFS support to the -mjc 2.4.17 branch (fwd) In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 1029 Lines: 39 has that been put into the main XFS cvs tree (?) Shawn. On Thu, 10 Jan 2002, Nathan Scott wrote: > > On Wed, Jan 09, 2002 at 09:05:30PM -0500, Shawn Starr wrote: > > > > > > It should be going in soon, Just trying to keep up to your TAKEs in CVS :) > > > > > > Linux coredump 2.4.18pre1-mjc3-xfs #2 Tue Jan 8 23:54:58 EST 2002 i586 > > > unknown > > > 9:04pm up 20:59, 7 users, load average: 0.38, 0.47, 0.47 (since last > > > TAKE update). > > > > > > I wish there was an easier way to merge the diffs with linux-2.4-xfs/linux > > > with my tree (pre -mjcX-xfs) > > > > > > > hi Shawn, > > > > Are you folks going to be using Jan Kara's revised quota code (as Alan > > was)? You should find that the XFS quota code merges better with that, > > as Jan and I did some work awhile ago to get our patches to play nicely > > together. > > > > [Jan's patches fix the 2^16 uid limit from Linus' tree, and provide > > quota code which can work with reiserfs also, I believe]. > > > > cheers. > > > > -- > > Nathan > > > > > > From owner-linux-xfs@oss.sgi.com Wed Jan 9 19:24:16 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0A3OGG26630 for linux-xfs-outgoing; Wed, 9 Jan 2002 19:24:16 -0800 Received: from lips.thebarn.com (lips.borg.umn.edu [160.94.232.50]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0A3O6g26606 for ; Wed, 9 Jan 2002 19:24:06 -0800 Received: from scare.vieo.com ([63.231.179.33]) by lips.thebarn.com (8.12.0/8.12.0) with ESMTP id g0A2Nekl089397 for ; Wed, 9 Jan 2002 20:23:41 -0600 (CST) Subject: Updated TAKE script From: Russell Cattelan To: linux-xfs@oss.sgi.com Content-Type: multipart/mixed; boundary="=-VMQd0ICGd7U9EY3hcB+n" X-Mailer: Evolution/1.0 (Preview Release) Date: 09 Jan 2002 20:15:37 -0600 Message-Id: <1010628938.27465.0.camel@scare> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 1405 Lines: 64 --=-VMQd0ICGd7U9EY3hcB+n Content-Type: text/plain Content-Transfer-Encoding: 7bit I'm not sure how man people use this? but... Here is an update to the script that inserts cvsweb url's into the the TAKE messages. o Detect the 2.4 vs the 2.5 tree o Don't insert a "diff" url if the file is new For anybody who hasn't seen this before here is the procmail rule. :0 Hf * ^Subject.*TAKE | $HOME/bin/take2.pl --=-VMQd0ICGd7U9EY3hcB+n Content-Disposition: attachment; filename=take2.pl Content-Transfer-Encoding: quoted-printable Content-Type: text/x-perl; charset=ISO-8859-1 #!/usr/bin/perl #use Data::Dumper; $baseoss =3D "http://oss.sgi.com/cgi-bin/cvsweb.cgi"; $v24 =3D "/linux-2.4-xfs"; $v25 =3D "/linux-2.5-xfs"; $lver =3D $v24; while(<>){ next if /^http:/; print $_; =20=20 if ($_ =3D~ "2.4.x-xfs"){ $lver =3D $v24;=09 } elsif ($_ =3D~ "2.5.x-xfs"){ $lver =3D $v25;=09 } if ((($file,$revB,$revM) =3D /(.+)\ -\ ([0-9]+)\.([0-9]+)/)){ $revP =3D $revM - 1; # print "$file $revB $revM $revP\n"; $url1 =3D "r1=3Dtext&tr1=3D$revB.$revM&"; $url2 =3D "r2=3Dtext&tr2=3D$revB.$revP&"; # $fullurl =3D $base."/".$file.".diff?".$url1.$url2."f=3Dh"; # print "$fullurl\n"; if ($revM =3D=3D 1){ $fullurl2 =3D $baseoss.$lver."/".$file; } else { $fullurl2 =3D $baseoss.$lver."/".$file.".diff?".$url1.$url2."f=3Dh"; } print "$fullurl2\n"; } } --=-VMQd0ICGd7U9EY3hcB+n-- From owner-linux-xfs@oss.sgi.com Wed Jan 9 19:32:52 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0A3Wqi26862 for linux-xfs-outgoing; Wed, 9 Jan 2002 19:32:52 -0800 Received: from sgi.com (sgi-too.SGI.COM [204.94.211.39]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0A3Wog26839 for ; Wed, 9 Jan 2002 19:32:50 -0800 Received: from relay1.corp.sgi.com (corp.sgi.com [198.29.75.13]) by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id SAA06025 for ; Wed, 9 Jan 2002 18:30:23 -0800 (PST) mail_from (sandeen@sgi.com) Received: from chuckle.americas.sgi.com (sandeen@chuckle.americas.sgi.com [128.162.211.44]) by relay1.corp.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) via ESMTP id SAA46953; Wed, 9 Jan 2002 18:32:16 -0800 (PST) Date: Wed, 9 Jan 2002 20:32:15 -0600 (CST) From: Eric Sandeen X-X-Sender: To: Shawn Starr cc: Subject: Re: ANNOUCEMENT: XFS support to the -mjc 2.4.17 branch (fwd) In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 155 Lines: 9 > I wish there was an easier way to merge the diffs with linux-2.4-xfs/linux > with my tree (pre -mjcX-xfs) Hi Shawn - How are you doing it now? -Eric From owner-linux-xfs@oss.sgi.com Wed Jan 9 19:43:25 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0A3hP527198 for linux-xfs-outgoing; Wed, 9 Jan 2002 19:43:25 -0800 Received: from coredump.sh0n.net (qmailremote@CPEdeadbeef0000.cpe.net.cable.rogers.com [24.100.234.67]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0A3hKg27175 for ; Wed, 9 Jan 2002 19:43:21 -0800 Received: (qmail 4195 invoked from network); 10 Jan 2002 02:44:07 -0000 Received: from coredump.sh0n.net (sh0n@24.100.234.67) by coredump.sh0n.net with SMTP; 10 Jan 2002 02:44:07 -0000 Date: Wed, 9 Jan 2002 21:44:06 -0500 (EST) From: Shawn Starr To: Eric Sandeen cc: linux-xfs@oss.sgi.com Subject: Re: ANNOUCEMENT: XFS support to the -mjc 2.4.17 branch (fwd) In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 574 Lines: 25 Well, i have my 2.4.18-pre1-mjc3p1-xfs branch which contans a whole bunch of other patches (preempting + ide + riel's rmap patch and others). I basically have to manually edit the files to make sure I dont break anything ;) But dont have a complete list of all the TAKEs and how many files got modified (unless i captured a cvs update | tee file). Shawn. On Wed, 9 Jan 2002, Eric Sandeen wrote: > > I wish there was an easier way to merge the diffs with linux-2.4-xfs/linux > > with my tree (pre -mjcX-xfs) > > Hi Shawn - > > How are you doing it now? > > -Eric > > > From owner-linux-xfs@oss.sgi.com Wed Jan 9 19:43:57 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0A3hvP27336 for linux-xfs-outgoing; Wed, 9 Jan 2002 19:43:57 -0800 Received: from coredump.sh0n.net (qmailremote@CPEdeadbeef0000.cpe.net.cable.rogers.com [24.100.234.67]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0A3hqg27304 for ; Wed, 9 Jan 2002 19:43:52 -0800 Received: (qmail 4201 invoked from network); 10 Jan 2002 02:44:37 -0000 Received: from coredump.sh0n.net (sh0n@24.100.234.67) by coredump.sh0n.net with SMTP; 10 Jan 2002 02:44:37 -0000 Date: Wed, 9 Jan 2002 21:44:37 -0500 (EST) From: Shawn Starr To: Eric Sandeen cc: linux-xfs@oss.sgi.com Subject: Re: ANNOUCEMENT: XFS support to the -mjc 2.4.17 branch (fwd) In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 724 Lines: 34 I'd say its a pretty messy MESSY way of doing it :-( Shawn. On Wed, 9 Jan 2002, Shawn Starr wrote: > > Well, i have my 2.4.18-pre1-mjc3p1-xfs branch which contans a whole bunch > of other patches (preempting + ide + riel's rmap patch and others). I > basically have to manually edit the files to make sure I dont break > anything ;) > > But dont have a complete list of all the TAKEs and how many files got > modified (unless i captured a cvs update | tee file). > > Shawn. > > On Wed, 9 Jan 2002, Eric Sandeen wrote: > > > > I wish there was an easier way to merge the diffs with linux-2.4-xfs/linux > > > with my tree (pre -mjcX-xfs) > > > > Hi Shawn - > > > > How are you doing it now? > > > > -Eric > > > > > > > > From owner-linux-xfs@oss.sgi.com Wed Jan 9 19:53:21 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0A3rLX27578 for linux-xfs-outgoing; Wed, 9 Jan 2002 19:53:21 -0800 Received: from rj.sgi.com (rj.sgi.com [204.94.215.100]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0A3rIg27546 for ; Wed, 9 Jan 2002 19:53:18 -0800 Received: from nodin.corp.sgi.com (nodin.corp.sgi.com [192.26.51.193]) by rj.sgi.com (8.11.4/8.11.4/linux-outbound_gateway-1.1) with ESMTP id g0A2rBY00969 for ; Wed, 9 Jan 2002 18:53:11 -0800 Received: from kao2.melbourne.sgi.com (kao2.melbourne.sgi.com [134.14.55.180]) by nodin.corp.sgi.com (8.11.4/8.11.2/nodin-1.0) with ESMTP id g0A2q9422417911; Wed, 9 Jan 2002 18:52:10 -0800 (PST) Received: by kao2.melbourne.sgi.com (Postfix, from userid 16331) id 34040300095; Thu, 10 Jan 2002 13:52:06 +1100 (EST) Received: from kao2.melbourne.sgi.com (localhost [127.0.0.1]) by kao2.melbourne.sgi.com (Postfix) with ESMTP id 9422F94; Thu, 10 Jan 2002 13:52:06 +1100 (EST) X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 From: Keith Owens To: Shawn Starr Cc: linux-xfs@oss.sgi.com Subject: Re: ANNOUCEMENT: XFS support to the -mjc 2.4.17 branch (fwd) In-reply-to: Your message of "Wed, 09 Jan 2002 21:44:06 CDT." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 10 Jan 2002 13:51:59 +1100 Message-ID: <3033.1010631119@kao2.melbourne.sgi.com> Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 618 Lines: 14 On Wed, 9 Jan 2002 21:44:06 -0500 (EST), Shawn Starr wrote: >Well, i have my 2.4.18-pre1-mjc3p1-xfs branch which contans a whole bunch >of other patches (preempting + ide + riel's rmap patch and others). I >basically have to manually edit the files to make sure I dont break >anything ;) > >But dont have a complete list of all the TAKEs and how many files got >modified (unless i captured a cvs update | tee file). Have you looked at ftp://oss.sgi.com/projects/xfs/download/patches? There are XFS split patches there, the split for 2.4.17 is on hold while a few problems are being tracked down. From owner-linux-xfs@oss.sgi.com Wed Jan 9 19:56:31 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0A3uV027814 for linux-xfs-outgoing; Wed, 9 Jan 2002 19:56:31 -0800 Received: from coredump.sh0n.net (qmailremote@CPEdeadbeef0000.cpe.net.cable.rogers.com [24.100.234.67]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0A3uRg27792 for ; Wed, 9 Jan 2002 19:56:27 -0800 Received: (qmail 4267 invoked from network); 10 Jan 2002 02:57:14 -0000 Received: from coredump.sh0n.net (sh0n@24.100.234.67) by coredump.sh0n.net with SMTP; 10 Jan 2002 02:57:14 -0000 Date: Wed, 9 Jan 2002 21:57:13 -0500 (EST) From: Shawn Starr To: Keith Owens cc: linux-xfs@oss.sgi.com Subject: Re: ANNOUCEMENT: XFS support to the -mjc 2.4.17 branch (fwd) In-Reply-To: <3033.1010631119@kao2.melbourne.sgi.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 929 Lines: 25 I'm on a moving target so if things break they break. But i'm not sure. User's using my patch have not had file corruption or such. But aside from that fxc program which seems to cause problems with XFS (unknown reasons). We're doing ok. On Thu, 10 Jan 2002, Keith Owens wrote: > On Wed, 9 Jan 2002 21:44:06 -0500 (EST), > Shawn Starr wrote: > >Well, i have my 2.4.18-pre1-mjc3p1-xfs branch which contans a whole bunch > >of other patches (preempting + ide + riel's rmap patch and others). I > >basically have to manually edit the files to make sure I dont break > >anything ;) > > > >But dont have a complete list of all the TAKEs and how many files got > >modified (unless i captured a cvs update | tee file). > > Have you looked at ftp://oss.sgi.com/projects/xfs/download/patches? > There are XFS split patches there, the split for 2.4.17 is on hold > while a few problems are being tracked down. > > > From owner-linux-xfs@oss.sgi.com Wed Jan 9 21:23:02 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0A5N2O29095 for linux-xfs-outgoing; Wed, 9 Jan 2002 21:23:02 -0800 Received: from sgi.com (sgi-too.SGI.COM [204.94.211.39]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0A5Mwg29073 for ; Wed, 9 Jan 2002 21:22:58 -0800 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.55.149]) by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id UAA02423 for ; Wed, 9 Jan 2002 20:20:28 -0800 (PST) mail_from (tes@snort.melbourne.sgi.com) Received: (from tes@localhost) by snort.melbourne.sgi.com (SGI-8.9.3/8.9.3) id PAA57404 for linux-xfs@oss.sgi.com; Thu, 10 Jan 2002 15:21:26 +1100 (EST) Date: Thu, 10 Jan 2002 15:21:26 +1100 (EST) From: Timothy Shimmin Message-Id: <200201100421.PAA57404@snort.melbourne.sgi.com> To: linux-xfs@oss.sgi.com Subject: TAKE - ACL,umask and xfs_iops.c Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 712 Lines: 25 Matt, although ACLs weren't turned on, I think the nfsd and umask problem may still have been happening. Could you please try with this kernel change and let me know how you go. Thanks muchly. Nathan, if you could merge to 2.5 ... thanks. --Tim Date: Wed Jan 9 20:12:39 PST 2002 Workarea: snort.melbourne.sgi.com:/home/diskb/build4/tes/slinx-xfs desc: don't apply umask in linvfs_common_cr if ACLs aren't switched on The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:109343a linux/fs/xfs/linux/xfs_iops.c - 1.117 - Don't apply the umask if we have a default ACL BUT ALSO if we don't have ACLs switched on then don't apply umask here. From owner-linux-xfs@oss.sgi.com Thu Jan 10 00:31:03 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0A8V3H01145 for linux-xfs-outgoing; Thu, 10 Jan 2002 00:31:03 -0800 Received: from relay.xlink.net (relay.xlink.net [193.141.40.5]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0A8Ucg01122 for ; Thu, 10 Jan 2002 00:30:38 -0800 Received: from lizard.webland.de (lizard.webland.de [194.122.76.201]) by relay.xlink.net (8.9.3/8.8.7) with ESMTP id IAA19588; Thu, 10 Jan 2002 08:30:33 +0100 (MET) Received: (from uucp@localhost) by lizard.webland.de (8.8.8/8.8.7) id IAA14108; Thu, 10 Jan 2002 08:30:31 +0100 (MET) >Received: from mobile.sauter-bc.com (unknown [10.1.6.21]) by basel1.sauter-bc.com (Postfix) with ESMTP id 46CD157306; Thu, 10 Jan 2002 08:29:53 +0100 (CET) Received: from ch.sauter-bc.com (support.cad.sba [10.1.200.117]) by mobile.sauter-bc.com (Postfix) with ESMTP id 97C3925835; Thu, 10 Jan 2002 08:29:51 +0100 (CET) Message-ID: <3C3D42EF.34C12C20@ch.sauter-bc.com> Date: Thu, 10 Jan 2002 08:29:51 +0100 From: Simon Matter Organization: Sauter AG, Basel X-Mailer: Mozilla 4.77 [de] (X11; U; Linux 2.2.19-6.2.12 i686) X-Accept-Language: de-CH, en MIME-Version: 1.0 To: Jano Lukac , linux-xfs , linux-ide-arrays Subject: Re: xfs results question References: <33499.63.204.249.45.1010618787.squirrel@www.portablehole.net> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 6970 Lines: 226 Jano Lukac schrieb: > > Hi, > > In a recent e-mail, you showed some results of using XFS on a software raid5 Hi, Because this is RAID and XFS specific, I'm posting to the ML's too. > setup: > http://marc.theaimsgroup.com/?l=linux-xfs&m=101047412725459&w=2 > > The last test you approximated: > XFS on Software RAID5 w/o write caching, > logdev on SoftRAID1 on the same disks : ~10 min > > So how exactly did this setup look like? soft raid5 on three of the disks, > with the xfs log-dev on the fourth? Or you stuck in an extra pair of disks No, for two reasons: - Waste of disk space since your log does not have to be big. - I want redundancy on all devices, so I need at least two disks for the log as well. > with software raid1 and put the log-dev there? What's confusing me is the > "soft raid1 on the same disks." I was confused too by the results of my first tests, that's why I took the time to find out how it works well. Here we go: [root@client130 root]# fdisk -l /dev/sd[a-d] Disk /dev/sda: 255 heads, 63 sectors, 1106 cylinders Units = cylinders of 16065 * 512 bytes Device Boot Start End Blocks Id System /dev/sda1 * 1 13 104391 fd Linux raid autodetect /dev/sda2 14 141 1028160 fd Linux raid autodetect /dev/sda3 142 1106 7751362+ fd Linux raid autodetect Disk /dev/sdb: 255 heads, 63 sectors, 1106 cylinders Units = cylinders of 16065 * 512 bytes Device Boot Start End Blocks Id System /dev/sdb1 * 1 13 104391 fd Linux raid autodetect /dev/sdb2 14 122 875542+ fd Linux raid autodetect /dev/sdb3 142 1106 7751362+ fd Linux raid autodetect /dev/sdb4 123 141 152617+ fd Linux raid autodetect Partition table entries are not in disk order Disk /dev/sdc: 255 heads, 63 sectors, 1106 cylinders Units = cylinders of 16065 * 512 bytes Device Boot Start End Blocks Id System /dev/sdc1 * 1 13 104391 fd Linux raid autodetect /dev/sdc2 14 141 1028160 fd Linux raid autodetect /dev/sdc3 142 1106 7751362+ fd Linux raid autodetect Disk /dev/sdd: 255 heads, 63 sectors, 1106 cylinders Units = cylinders of 16065 * 512 bytes Device Boot Start End Blocks Id System /dev/sdd1 * 1 13 104391 fd Linux raid autodetect /dev/sdd2 14 122 875542+ fd Linux raid autodetect /dev/sdd3 142 1106 7751362+ fd Linux raid autodetect /dev/sdd4 123 141 152617+ fd Linux raid autodetect Partition table entries are not in disk order [root@client130 root]# cat /etc/raidtab raiddev /dev/md1 raid-level 1 nr-raid-disks 2 chunk-size 64k persistent-superblock 1 nr-spare-disks 0 device /dev/sda2 raid-disk 0 device /dev/sdc2 raid-disk 1 raiddev /dev/md3 raid-level 1 nr-raid-disks 3 chunk-size 64k persistent-superblock 1 nr-spare-disks 1 device /dev/sda1 raid-disk 0 device /dev/sdb1 raid-disk 1 device /dev/sdc1 raid-disk 2 device /dev/sdd1 spare-disk 0 raiddev /dev/md0 raid-level 5 nr-raid-disks 4 chunk-size 64k persistent-superblock 1 nr-spare-disks 0 device /dev/sda3 raid-disk 0 device /dev/sdb3 raid-disk 1 device /dev/sdc3 raid-disk 2 device /dev/sdd3 raid-disk 3 raiddev /dev/md2 raid-level 1 nr-raid-disks 2 chunk-size 64k persistent-superblock 1 nr-spare-disks 0 device /dev/sdb2 raid-disk 0 device /dev/sdd2 raid-disk 1 raiddev /dev/md4 raid-level 1 nr-raid-disks 2 chunk-size 64k persistent-superblock 1 nr-spare-disks 0 device /dev/sdb4 raid-disk 0 device /dev/sdd4 raid-disk 1 [root@client130 root]# cat /etc/fstab /dev/md1 / xfs defaults 1 1 LABEL=/boot /boot xfs defaults 1 2 none /dev/pts devpts gid=5,mode=620 0 0 LABEL=/home /home xfs defaults,logdev=/dev/md4 1 2 none /proc proc defaults 0 0 none /dev/shm tmpfs defaults 0 0 /dev/md2 swap swap defaults 0 0 /dev/cdrom /mnt/cdrom iso9660 noauto,owner,kudzu,ro 0 0 /dev/fd0 /mnt/floppy auto noauto,owner,kudzu 0 0 ftp:/home/ftp/pub /mnt/nfs nfs defaults 0 0 [root@client130 root]# cat /proc/mdstat Personalities : [raid1] [raid5] read_ahead 1024 sectors md1 : active raid1 sdc2[1] sda2[0] 1028096 blocks [2/2] [UU] md3 : active raid1 sdd1[3] sdc1[2] sdb1[1] sda1[0] 104320 blocks [3/3] [UUU] md2 : active raid1 sdd2[1] sdb2[0] 875456 blocks [2/2] [UU] md0 : active raid5 sdd3[3] sdc3[2] sdb3[1] sda3[0] 23253888 blocks level 5, 64k chunk, algorithm 0 [4/4] [UUUU] md4 : active raid1 sdd4[1] sdb4[0] 152512 blocks [2/2] [UU] unused devices: This setup was only for test purposes, that's why it looks somewhat ugly. BTW if you want to build Software RAID10, make shure you do it like this: Two mirrors, and then stripe, NOT two stripe and then mirror. Why? Both of them work but only the first gives you good performance. <--- /etc/raidtab raiddev /dev/md4 raid-level 1 nr-raid-disks 2 chunk-size 64k persistent-superblock 1 #nr-spare-disks 0 device /dev/sda7 raid-disk 0 device /dev/sdb7 raid-disk 1 raiddev /dev/md5 raid-level 1 nr-raid-disks 2 chunk-size 64k persistent-superblock 1 #nr-spare-disks 0 device /dev/sdc7 raid-disk 0 device /dev/sdd7 raid-disk 1 raiddev /dev/md6 raid-level 0 nr-raid-disks 2 chunk-size 64k persistent-superblock 1 #nr-spare-disks 0 device /dev/md4 raid-disk 0 device /dev/md5 raid-disk 1 <--- EOF Simon > > I appreciate your taking the time to read this, look forward to a reply. > Thanks! > > Jano From owner-linux-xfs@oss.sgi.com Thu Jan 10 00:39:32 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0A8dWj01379 for linux-xfs-outgoing; Thu, 10 Jan 2002 00:39:32 -0800 Received: from smtpzilla3.xs4all.nl (smtpzilla3.xs4all.nl [194.109.127.139]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0A8dSg01357 for ; Thu, 10 Jan 2002 00:39:28 -0800 Received: from auto-nb1.xs4all.nl (coltex.xs4all.nl [213.84.127.168]) by smtpzilla3.xs4all.nl (8.12.0/8.12.0) with ESMTP id g0A7dOT4045963; Thu, 10 Jan 2002 08:39:24 +0100 (CET) Message-Id: <4.3.2.7.2.20020110083723.02e0c638@pop.xs4all.nl> X-Sender: knuffie@pop.xs4all.nl X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 10 Jan 2002 08:38:53 +0100 To: Shawn Starr , linux-xfs@oss.sgi.com From: Seth Mos Subject: Re: ANNOUCEMENT: XFS support to the -mjc 2.4.17 branch (fwd) In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 357 Lines: 15 At 21:23 9-1-2002 -0500, Shawn Starr wrote: >has that been put into the main XFS cvs tree (?) No, we normally don't apply outside patches to the CVS tree. It already has the kdb patch in which is as far as they want to go. Cheers -- Seth Every program has two purposes one for which it was written and another for which it wasn't I use the last kind. From owner-linux-xfs@oss.sgi.com Thu Jan 10 01:29:28 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0A9TSh02124 for linux-xfs-outgoing; Thu, 10 Jan 2002 01:29:28 -0800 Received: from yog-sothoth.sgi.com (eugate.sgi.com [192.48.160.10]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0A9THg02101 for ; Thu, 10 Jan 2002 01:29:17 -0800 Received: from sherman.melbourne.sgi.com (sherman.melbourne.sgi.com [134.14.55.232]) by yog-sothoth.sgi.com (980305.SGI.8.8.8-aspam-6.2/980304.SGI-aspam-europe) via ESMTP id JAA1563535 for ; Thu, 10 Jan 2002 09:26:38 +0100 (CET) mail_from (kaos@sherman.melbourne.sgi.com) Received: (from kaos@localhost) by sherman.melbourne.sgi.com (8.11.6/8.11.6) id g0A8SHU24920; Thu, 10 Jan 2002 19:28:17 +1100 Date: Thu, 10 Jan 2002 19:28:17 +1100 From: Keith Owens Message-Id: <200201100828.g0A8SHU24920@sherman.melbourne.sgi.com> Subject: TAKE - Workaround for gcc 2.96 bug Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 2388 Lines: 83 gcc -v Reading specs from /usr/lib/gcc-lib/i386-redhat-linux/2.96/specs gcc version 2.96 20000731 (Red Hat Linux 7.1 2.96-98) breaks on complex expressions involving long long. Swapping two lines in xfs_bmap.c works around the broken gcc. For the record, this test gcc_bug.c file demonstrates the bug. Note that it uses the standard do_div from /usr/include/asm/div64.h and not the xfs version, although both versions of do_div fail with gcc 2.96. I doubt that it is worth opening a bug with gcc, AFAICT they don't want to know about 2.96, even the latest "fixed" RedHat version. #define do_div(n,base) ({ \ unsigned long __upper, __low, __high, __mod; \ asm("":"=a" (__low), "=d" (__high):"A" (n)); \ __upper = __high; \ if (__high) { \ __upper = __high % (base); \ __high = __high / (base); \ } \ asm("divl %2":"=a" (__low), "=d" (__mod):"rm" (base), "0" (__low), "1" (__upper)); \ asm("":"=A" (n):"a" (__low),"d" (__high)); \ __mod; \ }) void gcc_bug(unsigned long long *len_p) { unsigned long long bno; unsigned long long len; bno = 2000; do_div(bno, 12); len = *len_p; do_div(len, 24); printf("%lld %lld\n", bno, len); } gcc -O2 gcc_bug.c gcc_bug.c: In function `gcc_bug': gcc_bug.c:26: Unrecognizable insn: (insn 49 149 143 (parallel[ (set (reg:SI 0 eax) (asm_operands ("") ("=a") 0[ (reg:DI 1 edx) ] [ (asm_input:DI ("A")) ] ("gcc_bug.c") 24)) (set (reg:SI 1 edx) (asm_operands ("") ("=d") 1[ (reg:DI 1 edx) ] [ (asm_input:DI ("A")) ] ("gcc_bug.c") 24)) (clobber (reg:QI 19 dirflag)) (clobber (reg:QI 18 fpsr)) (clobber (reg:QI 17 flags)) ] ) -1 (insn_list 45 (nil)) (nil)) gcc_bug.c:26: confused by earlier errors, bailing out Setting both bno and len before do_div works, i.e. bno = 2000; len = *len_p; do_div(bno, 12); do_div(len, 24); Date: Thu Jan 10 00:03:03 PST 2002 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:109353a linux/fs/xfs/xfs_bmap.c - 1.279 From owner-linux-xfs@oss.sgi.com Thu Jan 10 07:42:18 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0AFgIH13117 for linux-xfs-outgoing; Thu, 10 Jan 2002 07:42:18 -0800 Received: from coredump.sh0n.net (qmailremote@CPEdeadbeef0000.cpe.net.cable.rogers.com [24.100.234.67]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0AFgCg13092 for ; Thu, 10 Jan 2002 07:42:12 -0800 Received: (qmail 2583 invoked from network); 10 Jan 2002 14:42:59 -0000 Received: from unknown (HELO unaropia.datawire.net) (207.61.129.120) by coredump.sh0n.net with SMTP; 10 Jan 2002 14:42:59 -0000 Subject: Re: ANNOUCEMENT: XFS support to the -mjc 2.4.17 (was Quota diff) From: Shawn Starr To: linux-xfs@oss.sgi.com In-Reply-To: <4.3.2.7.2.20020110083723.02e0c638@pop.xs4all.nl> References: <4.3.2.7.2.20020110083723.02e0c638@pop.xs4all.nl> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/1.0.1.99 (Preview Release) Date: 10 Jan 2002 09:43:03 -0500 Message-Id: <1010673813.3546.11.camel@unaropia> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 609 Lines: 26 Oh ok, I'll keep it out side of my branch for now until mjc gives approval and once the tree settles some more :-) It looks interesting though. I have the patch. Shawn. On Thu, 2002-01-10 at 02:38, Seth Mos wrote: > At 21:23 9-1-2002 -0500, Shawn Starr wrote: > > >has that been put into the main XFS cvs tree (?) > > No, we normally don't apply outside patches to the CVS tree. It already has > the kdb patch in which is as far as they want to go. > > Cheers > > -- > Seth > Every program has two purposes one for which > it was written and another for which it wasn't > I use the last kind. > > From owner-linux-xfs@oss.sgi.com Thu Jan 10 07:43:48 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0AFhmj13275 for linux-xfs-outgoing; Thu, 10 Jan 2002 07:43:48 -0800 Received: from coredump.sh0n.net (qmailremote@CPEdeadbeef0000.cpe.net.cable.rogers.com [24.100.234.67]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0AFhVg13227 for ; Thu, 10 Jan 2002 07:43:31 -0800 Received: (qmail 2587 invoked from network); 10 Jan 2002 14:44:20 -0000 Received: from unknown (HELO unaropia.datawire.net) (207.61.129.120) by coredump.sh0n.net with SMTP; 10 Jan 2002 14:44:20 -0000 Subject: Re: ANNOUCEMENT: XFS support to the -mjc 2.4.17 branch (fwd) From: Shawn Starr To: Eric Sandeen Cc: xfs In-Reply-To: References: Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/1.0.1.99 (Preview Release) Date: 10 Jan 2002 09:44:27 -0500 Message-Id: <1010673894.3544.14.camel@unaropia> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 4944 Lines: 151 Yes, But now I have to catch up to his latest tree (mjc3p2) so I have some work to do :-) On Thu, 2002-01-10 at 00:22, Eric Sandeen wrote: > Right... so mergetrees had a conflict here, and you resolved it by moving > VM_MAX_MAP_COUNT - right? > > On Thu, 10 Jan 2002, Shawn Starr wrote: > > > > > Well, one such change happened with riel's rmap: > > > > specifically: > > > > include/linux/sysctrl.h: > > > > #if defined(CONFIG_PAGE_BUF) || defined(CONFIG_PAGE_BUF_MODULE) > > VM_PAGEBUF=11, /* XXX: XFS Requires this -- Shawn Star */ > > #endif > > > > VM_MAX_MAP_COUNT was set to 11 causing a problem ;-) so I moved his to 14. > > > > Shawn. > > > > On Wed, 9 Jan 2002, Eric Sandeen wrote: > > > > > It creates the dest dir... you should not point it anywhere that has > > > existing code, you'd edit it _after_ you run mergetrees. Is that what > > > you're asking? > > > > > > I don't think you'll need to #ifdef out any of the xfs changes - they > > > should coexist happily with any other code, AFAIK... unless you have a > > > specific reason to do a bunch of ifdefs, I wouldn't think it's worth the > > > effort. > > > > > > -Eric > > > > > > On Wed, 9 Jan 2002, Shawn Starr wrote: > > > > > > > > > > > Running it now.. this looks interesting.. > > > > > > > > mergetrees -x CVS linux-2.4-xfs/linux linux-vanilla linux-mjc test-mjc-xfs > > > > > > > > though, in my dest directory i may need to #ifdef XFS code for non-XFS > > > > users. > > > > > > > > will it ignore my changes in the dest dir or overwrite them? > > > > > > > > Shawn. > > > > > > > > On Wed, 9 Jan 2002, Eric Sandeen wrote: > > > > > > > > > Just do a google search for it. > > > > > > > > > > If you have 3 trees, a "parent" tree, and 2 trees that have descended from > > > > > it (like, say, the linux-xfs tree and the linux-jfs tree, for example) you > > > > > do: > > > > > > > > > > mergetrees linux-xfs linux-vanilla linux-jfs linux-xfs-jfs > > > > > > > > > > and it will put together the linux-xfs-jfs tree. you still have to > > > > > hand-edit any merges it can't handle, but it does a pretty good job, and > > > > > all the ocnflicts are _in_ the file, so you can edit fairly easily. > > > > > > > > > > -Eric > > > > > > > > > > On Wed, 9 Jan 2002, Shawn Starr wrote: > > > > > > > > > > > > > > > > > Not heard of that program, I do know that REJECTS would be generated > > > > > > because of the differences in the non 2.4.x vanilla tree vs -mjc. > > > > > > > > > > > > Shawn. > > > > > > > > > > > > On Wed, 9 Jan 2002, Eric Sandeen wrote: > > > > > > > > > > > > > Hm, I don't think that's an option, but you could hook it into the TAKE > > > > > > > emails. > > > > > > > > > > > > > > OTOH, as keith pointed out, you can batch things fairly well with the > > > > > > > split patches. > > > > > > > > > > > > > > Also... have you seen mergetrees? it's an indispensable tool when we do > > > > > > > tree merging. > > > > > > > > > > > > > > -Eric > > > > > > > > > > > > > > On Wed, 9 Jan 2002, Shawn Starr wrote: > > > > > > > > > > > > > > > looking at cvsweb right now ;-) > > > > > > > > > > > > > > > > Is there an option to see the latest changes within cvsweb? > > > > > > > > > > > > > > > > Shawn. > > > > > > > > > > > > > > > > On Wed, 9 Jan 2002, Eric Sandeen wrote: > > > > > > > > > > > > > > > > > Well, it would not be too hard to set things up to mail you a set of diffs > > > > > > > > > each day, if you'd like. cvsweb also makes it easy to get diffs, perhaps > > > > > > > > > you could use Russell's script. > > > > > > > > > > > > > > > > > > -Eric > > > > > > > > > > > > > > > > > > On Wed, 9 Jan 2002, Shawn Starr wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Well, i have my 2.4.18-pre1-mjc3p1-xfs branch which contans a whole bunch > > > > > > > > > > of other patches (preempting + ide + riel's rmap patch and others). I > > > > > > > > > > basically have to manually edit the files to make sure I dont break > > > > > > > > > > anything ;) > > > > > > > > > > > > > > > > > > > > But dont have a complete list of all the TAKEs and how many files got > > > > > > > > > > modified (unless i captured a cvs update | tee file). > > > > > > > > > > > > > > > > > > > > Shawn. > > > > > > > > > > > > > > > > > > > > On Wed, 9 Jan 2002, Eric Sandeen wrote: > > > > > > > > > > > > > > > > > > > > > > I wish there was an easier way to merge the diffs with linux-2.4-xfs/linux > > > > > > > > > > > > with my tree (pre -mjcX-xfs) > > > > > > > > > > > > > > > > > > > > > > Hi Shawn - > > > > > > > > > > > > > > > > > > > > > > How are you doing it now? > > > > > > > > > > > > > > > > > > > > > > -Eric > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > From owner-linux-xfs@oss.sgi.com Thu Jan 10 07:51:15 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0AFpFV14025 for linux-xfs-outgoing; Thu, 10 Jan 2002 07:51:15 -0800 Received: from yog-sothoth.sgi.com (eugate.sgi.com [192.48.160.10]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0AFpBg14002 for ; Thu, 10 Jan 2002 07:51:11 -0800 Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by yog-sothoth.sgi.com (980305.SGI.8.8.8-aspam-6.2/980304.SGI-aspam-europe) via ESMTP id PAA1587871 for ; Thu, 10 Jan 2002 15:48:35 +0100 (CET) mail_from (lord@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id IAA4056812; Thu, 10 Jan 2002 08:49:40 -0600 (CST) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id IAA99893; Thu, 10 Jan 2002 08:49:40 -0600 (CST) Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id g0AEmXO17400; Thu, 10 Jan 2002 08:48:33 -0600 Subject: Re: ANNOUCEMENT: XFS support to the -mjc 2.4.17 branch (fwd) From: Steve Lord To: Shawn Starr Cc: Keith Owens , linux-xfs@oss.sgi.com In-Reply-To: References: Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/1.0.0.99+cvs.2001.12.18.08.57 (Preview Release) Date: 10 Jan 2002 08:48:32 -0600 Message-Id: <1010674112.17381.1.camel@jen.americas.sgi.com> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 626 Lines: 19 On Wed, 2002-01-09 at 20:57, Shawn Starr wrote: > > I'm on a moving target so if things break they break. But i'm not sure. > User's using my patch have not had file corruption or such. But aside from > that fxc program which seems to cause problems with XFS (unknown reasons). > We're doing ok. It does not cause any problems in our tree - it has been running for about 18 hours here without a snag now. Are you saying that the tree it was dying in was the mjc branch? Steve -- Steve Lord voice: +1-651-683-3511 Principal Engineer, Filesystem Software email: lord@sgi.com From owner-linux-xfs@oss.sgi.com Thu Jan 10 08:21:54 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0AGLsD15008 for linux-xfs-outgoing; Thu, 10 Jan 2002 08:21:54 -0800 Received: from oflmta02bw.bigpond.com (oflmta02bw.bigpond.com [139.134.6.23] (may be forged)) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0AGLjg14982 for ; Thu, 10 Jan 2002 08:21:45 -0800 Message-Id: <200201101621.g0AGLjg14982@oss.sgi.com> Received: from there ([144.135.24.87]) by oflmta02bw.bigpond.com (Netscape Messaging Server 4.15) with SMTP id GPQAZO00.DBR; Fri, 11 Jan 2002 01:28:36 +1000 Received: from CPE-144-137-136-173.qld.bigpond.net.au ([144.137.136.173]) by bwmam07.mailsvc.email.bigpond.com(MailRouter V3.0h 62/14948315); 11 Jan 2002 01:21:34 Content-Type: text/plain; charset="us-ascii" From: Adrian Head To: Andreas Dilger , Eric Sandeen Subject: Re: [linux-lvm] Re: Unable to get XFS, ext3, reiserfs & LVM to coexist happily Date: Fri, 11 Jan 2002 01:21:26 +1000 X-Mailer: KMail [version 1.3.1] Cc: Linux XFS Mailing List , linux-lvm@sistina.com, ext2-devel@lists.sourceforge.net References: <200201020451.g024pPg00867@oss.sgi.com> <200201050212.TAA16774@cthulhu.turbolabs.com> <20020105142527.I12868@lynx.no> In-Reply-To: <20020105142527.I12868@lynx.no> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 1549 Lines: 37 In the process of trying to fix this issue I have been playing around with a patch from the great SGI XFS developers. It certainly fixes the problems I was having but I'm now trying to help clean the patch up. The problem now is that when I try to mount a ext3 snapshot using: mount /dev/HDA/SNAP /mnt/snapshot The kernel mounts the snapshot as ext2. Is was not happening before the patch and I was wondering if anyone thinks this is a problem. As ext3 is backward compatible with ext2 there doesn't seem to be any problems during my testing with respect to standard file operations. I can mount the snapshot as ext3 if I use: mount -t ext3 /dev/HDA/SNAP /mnt/snapshot The next problem is that when the ext3 snapshot (mounted as ext3) overflows lvm generates an error in the logs: lvm -- giving up to snapshot /dev/HDA/XFS on /dev/HDA/SNAP: out of space lvm - lvm_map: ll_rw_blk for inactive LV /dev/HDA/SNAP The 1st line I understand but the 2nd I don't. I was hoping that some LVM guru/developer could explain the 2nd line and what it means. The last problem is that in only some of my tests when I "ls" the overflowed snapshot "ls" complains about missing directories and files, "echo *" shows what use to be there and ext3 generates errors in the logs: EXT3-fs error (device lvm(58,5)): ext3_readdir" directory #2 contains a hole at offset 0 I was hoping that a ext2/3 guru/developer could explain this error and what it means. Thanks for everybodies time and effort. -- Adrian Head (Public Key available on request.) From owner-linux-xfs@oss.sgi.com Thu Jan 10 09:17:21 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0AHHL016742 for linux-xfs-outgoing; Thu, 10 Jan 2002 09:17:21 -0800 Received: from deliverator.sgi.com (deliverator.sgi.com [204.94.214.10]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0AHHFg16718 for ; Thu, 10 Jan 2002 09:17:15 -0800 Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id IAA25144 for ; Thu, 10 Jan 2002 08:16:59 -0800 (PST) mail_from (lord@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id KAA4055420 for ; Thu, 10 Jan 2002 10:15:57 -0600 (CST) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id KAA38817 for ; Thu, 10 Jan 2002 10:15:56 -0600 (CST) From: Steve Lord Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id g0AGEmR28894; Thu, 10 Jan 2002 10:14:48 -0600 Message-Id: <200201101614.g0AGEmR28894@jen.americas.sgi.com> Date: Thu, 10 Jan 2002 10:14:48 -0600 Subject: TAKE - merge up to 2.5.2-pre11 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 1308 Lines: 41 Minor tweaking Date: Thu Jan 10 08:12:46 PST 2002 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:109364a linux/net/irda/irlmp_event.c - 1.14 linux/net/irda/irlap_event.c - 1.19 linux/net/irda/irlap.c - 1.16 linux/net/irda/irlan/irlan_eth.c - 1.15 linux/net/irda/irlan/irlan_common.c - 1.17 linux/net/irda/iriap.c - 1.14 linux/net/irda/irda_device.c - 1.23 linux/kernel/sched.c - 1.51 linux/kernel/fork.c - 1.42 linux/init/main.c - 1.68 linux/include/linux/sched.h - 1.53 linux/drivers/net/wavelan.c - 1.24 linux/drivers/net/irda/w83977af_ir.c - 1.21 linux/drivers/net/irda/irport.c - 1.24 linux/drivers/net/eepro100.c - 1.36 linux/Makefile - 1.173 linux/net/irda/ircomm/ircomm_lmp.c - 1.5 linux/net/irda/ircomm/ircomm_core.c - 1.12 linux/drivers/net/pcmcia/ray_cs.c - 1.23 linux/include/linux/pci_ids.h - 1.56 linux/drivers/pci/pci.ids - 1.40 linux/drivers/net/irda/nsc-ircc.c - 1.18 linux/Documentation/DocBook/Makefile - 1.23 linux/Documentation/DocBook/kernel-api.tmpl - 1.14 linux/net/irda/irsyms.c - 1.5 linux/drivers/sound/btaudio.c - 1.6 linux/fs/ext3/super.c - 1.8 linux/drivers/usb/hcd/Makefile - 1.2 linux/drivers/usb/hcd/ehci-q.c - 1.3 linux/drivers/usb/auerswald.c - 1.2 From owner-linux-xfs@oss.sgi.com Thu Jan 10 10:13:02 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0AID2h18138 for linux-xfs-outgoing; Thu, 10 Jan 2002 10:13:02 -0800 Received: from graze.net (graze.net [65.207.24.2]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0AICxg18116 for ; Thu, 10 Jan 2002 10:12:59 -0800 Received: from localhost (sheep@localhost) by graze.net (8.11.2/8.11.2) with ESMTP id g0AHCiu05790 for ; Thu, 10 Jan 2002 12:12:45 -0500 Date: Thu, 10 Jan 2002 12:12:43 -0500 (EST) From: "Brian C. Huffman" To: Subject: 2.4.17-xfs w/ VMWare Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 237 Lines: 9 All, Are there any known issues w/ 2.4.17 w/ XFS and VMWare? I've been trying to get this combo to work (w/ win2k guest) and am having quite a few problems. I keep getting "stack shutdowns" inside the vmware machine. Thanks, Brian From owner-linux-xfs@oss.sgi.com Thu Jan 10 10:22:58 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0AIMwX18372 for linux-xfs-outgoing; Thu, 10 Jan 2002 10:22:58 -0800 Received: from web20302.mail.yahoo.com (web20302.mail.yahoo.com [216.136.226.83]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0AIMqg18350 for ; Thu, 10 Jan 2002 10:22:52 -0800 Message-ID: <20020110172250.93315.qmail@web20302.mail.yahoo.com> Received: from [63.231.84.37] by web20302.mail.yahoo.com via HTTP; Thu, 10 Jan 2002 09:22:50 PST Date: Thu, 10 Jan 2002 09:22:50 -0800 (PST) From: Glenn Meuth Subject: NVidia & XFS To: linux-xfs@oss.sgi.com Cc: atici@math.columbia.edu MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 1826 Lines: 51 Greetings all, I found that I only had this problem when I built the virtual frame buffer support into the kernel. I don't know if that helps, but after removing the virtual frame buffer module (for the console), I did not have any problems with the driver. Glenn vortarian@yahoo.com atici@math.columbia.edu wrote: I wonder whether anyone had the same problem with me. I have a GeForce 3 video card and it works perfectly on a usual 7.2 system with the binaries provided in nvidia.com. However now I'm using a customised kernel (since I'd like to use XFS), therefore I got the SRPMs, rebuilt and installed them. The previous version had slight problems whereas 1.0.1541 simply doesn't work at all. I have no idea how it might clash with XFS resources or XFS capable kernel but I'd appreciate if someone could shed some light. When I observe the XFree86.0.log I see the drivers loaded perfectly and GeForce 3 is recognised at PCI 1:5:0 but then I get the following problem... The final lines in XFree86.0.log is: ----- (==) NVIDIA(0): Write-combining range (0xf0000000,0x4000000) (WW) NVIDIA(0): Failed to allocate a DMA push buffer using AGP memory... (WW) NVIDIA(0): attempting to use PCI memory (EE) NVIDIA(0): Failed to allocate a DMA push buffer context (EE) NVIDIA(0): *** Aborting *** (EE) NVIDIA(0): Failed to allocate DMA push buffer (EE) NVIDIA(0): *** Aborting *** ----- I reported the problem to Nvidia but they didn't even respond. I don't think they care much about linux. Yet if you had the same problem or have an idea on the cause let me know. Alp BTW I think XFS is great and I appreciate your efforts. Looking forward to see the 1.1.0 release... __________________________________________________ Do You Yahoo!? Send FREE video emails in Yahoo! Mail! http://promo.yahoo.com/videomail/ From owner-linux-xfs@oss.sgi.com Thu Jan 10 10:59:35 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0AIxZD19027 for linux-xfs-outgoing; Thu, 10 Jan 2002 10:59:35 -0800 Received: from coredump.sh0n.net (qmailremote@CPEdeadbeef0000.cpe.net.cable.rogers.com [24.100.234.67]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0AIxWg19005 for ; Thu, 10 Jan 2002 10:59:32 -0800 Received: (qmail 3757 invoked from network); 10 Jan 2002 18:00:17 -0000 Received: from unknown (HELO unaropia.datawire.net) (207.61.129.120) by coredump.sh0n.net with SMTP; 10 Jan 2002 18:00:17 -0000 Subject: Strange corruption in XFS-HEAD From: Shawn Starr To: xfs Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/1.0.1.99 (Preview Release) Date: 10 Jan 2002 13:00:23 -0500 Message-Id: <1010685652.25378.4.camel@unaropia> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 386 Lines: 17 I don't know if any of you have seen this but this is what's happening: Example: im rm -rf linux-tree AND tar -zxvf linux-2.4.17.tar.gz When im done i try to apply 2.4.18-pre2 and it fails with a reject. if i do *ONLY* one operation (not deleting files and extracting at same time) the diff works? I've also noticed some files are the wrong data right file name? odd.. Shawn. From owner-linux-xfs@oss.sgi.com Thu Jan 10 11:21:40 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0AJLeG19820 for linux-xfs-outgoing; Thu, 10 Jan 2002 11:21:40 -0800 Received: from yog-sothoth.sgi.com (eugate.sgi.com [192.48.160.10]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0AJLWg19761 for ; Thu, 10 Jan 2002 11:21:32 -0800 Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by yog-sothoth.sgi.com (980305.SGI.8.8.8-aspam-6.2/980304.SGI-aspam-europe) via ESMTP id TAA1611745 for ; Thu, 10 Jan 2002 19:18:55 +0100 (CET) mail_from (sandeen@sgi.com) Received: from poppy-e185.americas.sgi.com (poppy-e185.americas.sgi.com [128.162.185.207]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id MAA3429305; Thu, 10 Jan 2002 12:20:10 -0600 (CST) Received: from stout.americas.sgi.com (stout.americas.sgi.com [128.162.187.5]) by poppy-e185.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.7) with ESMTP id MAA86149; Thu, 10 Jan 2002 12:20:10 -0600 (CST) Subject: Re: NVidia & XFS From: Eric Sandeen To: Glenn Meuth Cc: linux-xfs@oss.sgi.com, atici@math.columbia.edu In-Reply-To: <20020110172250.93315.qmail@web20302.mail.yahoo.com> References: <20020110172250.93315.qmail@web20302.mail.yahoo.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/1.0 (Preview Release) Date: 10 Jan 2002 12:20:10 -0600 Message-Id: <1010686810.2848.6.camel@stout.americas.sgi.com> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 2158 Lines: 60 You'll have to ask NVidia about it, there's no way to debug it on this end. -Eric On Thu, 2002-01-10 at 11:22, Glenn Meuth wrote: > Greetings all, > I found that I only had this problem when I built the virtual frame buffer support into the > kernel. I don't know if that helps, but after removing the virtual frame buffer module (for the > console), I did not have any problems with the driver. > > Glenn > vortarian@yahoo.com > > > > atici@math.columbia.edu wrote: > > I wonder whether anyone had the same problem with me. I have a GeForce 3 > video card and it works perfectly on a usual 7.2 system with the binaries > provided in nvidia.com. However now I'm using a customised kernel (since > I'd like to use XFS), therefore I got the SRPMs, rebuilt and installed > them. The previous version had slight problems whereas 1.0.1541 simply > doesn't work at all. I have no idea how it might clash with XFS resources > or XFS capable kernel but I'd appreciate if someone could shed some light. > > When I observe the XFree86.0.log I see the drivers loaded perfectly and > GeForce 3 is recognised at PCI 1:5:0 but then I get the following > problem... > > The final lines in XFree86.0.log is: > ----- > (==) NVIDIA(0): Write-combining range (0xf0000000,0x4000000) > (WW) NVIDIA(0): Failed to allocate a DMA push buffer using AGP memory... > (WW) NVIDIA(0): attempting to use PCI memory > (EE) NVIDIA(0): Failed to allocate a DMA push buffer context > (EE) NVIDIA(0): *** Aborting *** > (EE) NVIDIA(0): Failed to allocate DMA push buffer > (EE) NVIDIA(0): *** Aborting *** > ----- > > I reported the problem to Nvidia but they didn't even respond. > I don't think they care much about linux. Yet if you had the same > problem or have an idea on the cause let me know. > Alp > > BTW I think XFS is great and I appreciate your efforts. Looking forward > to see the 1.1.0 release... > > > > > __________________________________________________ > Do You Yahoo!? > Send FREE video emails in Yahoo! Mail! > http://promo.yahoo.com/videomail/ -- Eric Sandeen XFS for Linux http://oss.sgi.com/projects/xfs sandeen@sgi.com SGI, Inc. From owner-linux-xfs@oss.sgi.com Thu Jan 10 11:23:11 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0AJNBE19970 for linux-xfs-outgoing; Thu, 10 Jan 2002 11:23:11 -0800 Received: from yog-sothoth.sgi.com (eugate.sgi.com [192.48.160.10]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0AJN6g19943 for ; Thu, 10 Jan 2002 11:23:07 -0800 Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by yog-sothoth.sgi.com (980305.SGI.8.8.8-aspam-6.2/980304.SGI-aspam-europe) via ESMTP id TAA1605782 for ; Thu, 10 Jan 2002 19:20:29 +0100 (CET) mail_from (sandeen@sgi.com) Received: from poppy-e185.americas.sgi.com (poppy-e185.americas.sgi.com [128.162.185.207]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id MAA3975720; Thu, 10 Jan 2002 12:21:45 -0600 (CST) Received: from stout.americas.sgi.com (stout.americas.sgi.com [128.162.187.5]) by poppy-e185.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.7) with ESMTP id MAA85889; Thu, 10 Jan 2002 12:21:45 -0600 (CST) Subject: Re: Strange corruption in XFS-HEAD From: Eric Sandeen To: Shawn Starr Cc: xfs In-Reply-To: <1010685652.25378.4.camel@unaropia> References: <1010685652.25378.4.camel@unaropia> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/1.0 (Preview Release) Date: 10 Jan 2002 12:21:45 -0600 Message-Id: <1010686905.2848.8.camel@stout.americas.sgi.com> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 747 Lines: 29 What kernel is this, stock XFS CVS, or after you merge it w/ the -mjc kernel? Also, can you be a bit more explicit about the steps you're taking when you see this problem? -Eric On Thu, 2002-01-10 at 12:00, Shawn Starr wrote: > I don't know if any of you have seen this but this is what's happening: > > Example: im rm -rf linux-tree AND tar -zxvf linux-2.4.17.tar.gz > > When im done i try to apply 2.4.18-pre2 and it fails with a reject. > > if i do *ONLY* one operation (not deleting files and extracting at same > time) the diff works? > > I've also noticed some files are the wrong data right file name? > > odd.. > > Shawn. > > -- Eric Sandeen XFS for Linux http://oss.sgi.com/projects/xfs sandeen@sgi.com SGI, Inc. From owner-linux-xfs@oss.sgi.com Thu Jan 10 11:31:28 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0AJVS520428 for linux-xfs-outgoing; Thu, 10 Jan 2002 11:31:28 -0800 Received: from rj.sgi.com (rj.sgi.com [204.94.215.100]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0AJVLg20406 for ; Thu, 10 Jan 2002 11:31:21 -0800 Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by rj.sgi.com (8.11.4/8.11.4/linux-outbound_gateway-1.1) with ESMTP id g0AIVDY06341 for ; Thu, 10 Jan 2002 10:31:14 -0800 Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id MAA4026175; Thu, 10 Jan 2002 12:29:58 -0600 (CST) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id MAA53573; Thu, 10 Jan 2002 12:29:58 -0600 (CST) Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id g0AISnP01668; Thu, 10 Jan 2002 12:28:49 -0600 Subject: Re: Strange corruption in XFS-HEAD From: Steve Lord To: Eric Sandeen Cc: Shawn Starr , xfs In-Reply-To: <1010686905.2848.8.camel@stout.americas.sgi.com> References: <1010685652.25378.4.camel@unaropia> <1010686905.2848.8.camel@stout.americas.sgi.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/1.0.0.99+cvs.2001.12.18.08.57 (Preview Release) Date: 10 Jan 2002 12:28:48 -0600 Message-Id: <1010687328.676.102.camel@jen.americas.sgi.com> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 471 Lines: 18 On Thu, 2002-01-10 at 12:21, Eric Sandeen wrote: > What kernel is this, stock XFS CVS, or after you merge it w/ the -mjc > kernel? > > Also, can you be a bit more explicit about the steps you're taking when > you see this problem? I fairly regularly do things like this - and I just did it again, no problems here. Steve -- Steve Lord voice: +1-651-683-3511 Principal Engineer, Filesystem Software email: lord@sgi.com From owner-linux-xfs@oss.sgi.com Thu Jan 10 11:34:43 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0AJYhr20674 for linux-xfs-outgoing; Thu, 10 Jan 2002 11:34:43 -0800 Received: from goliath.sylaba.poznan.pl (root@goliath.sylaba.poznan.pl [195.216.104.3]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0AJYdg20648 for ; Thu, 10 Jan 2002 11:34:40 -0800 Received: from venus.local.navi.pl (ps103.poznan.sdi.tpnet.pl [217.97.72.103]) by goliath.sylaba.poznan.pl (8.11.6/8.10.1) with ESMTP id g0AIYYG16875 for ; Thu, 10 Jan 2002 19:34:35 +0100 (CET) Received: from venus.local.navi.pl (venus [192.168.1.10]) by venus.local.navi.pl (8.11.6/8.9.3) with ESMTP id g0AHUq201730 for ; Thu, 10 Jan 2002 18:30:52 +0100 Date: Thu, 10 Jan 2002 18:30:51 +0100 From: Olaf =?iso-8859-2?Q?Fr=B1czyk?= To: linux-xfs@oss.sgi.com Subject: XFS is innocent - was: vmware+XFS+duron+viakt133 - works? Message-ID: <20020110183051.A1483@venus.local.navi.pl> Mime-Version: 1.0 Content-Type: text/plain; format=flowed; charset=ISO-8859-2 Content-Transfer-Encoding: 8bit X-Mailer: Balsa 1.2.3 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 622 Lines: 15 Hi, I have installed clean RH7.2 on one free partition on my machine. Removed RH gcc, installed compat-egcs, compiled new kernel (2.4.17) with xfs (using the same sources as previous) and ... no problems. So I moved kernel, modules to my working system, and ... it works. So something with my system is wrong, and the problems are not XFS related. Now, I have to find what :(( Or compiler, or glibc I suppose. I have RH 7.1, with updated glibc to 2.2.4-14 (on the new installed 7.2 is 2.2.4-13), and I use egcs from RH 6.x. And on the new I installed compat-egcs and compat-glibc-6.2-2.1.3.2. Regards, Olaf Fraczyk From owner-linux-xfs@oss.sgi.com Thu Jan 10 11:39:51 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0AJdpl20960 for linux-xfs-outgoing; Thu, 10 Jan 2002 11:39:51 -0800 Received: from coredump.sh0n.net (qmailremote@CPEdeadbeef0000.cpe.net.cable.rogers.com [24.100.234.67]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0AJdeg20930 for ; Thu, 10 Jan 2002 11:39:42 -0800 Received: (qmail 3849 invoked from network); 10 Jan 2002 18:40:21 -0000 Received: from unknown (HELO unaropia.datawire.net) (207.61.129.120) by coredump.sh0n.net with SMTP; 10 Jan 2002 18:40:21 -0000 Subject: Re: Strange corruption in XFS-HEAD From: Shawn Starr To: Steve Lord Cc: Eric Sandeen , xfs In-Reply-To: <1010687328.676.102.camel@jen.americas.sgi.com> References: <1010685652.25378.4.camel@unaropia> <1010686905.2848.8.camel@stout.americas.sgi.com> <1010687328.676.102.camel@jen.americas.sgi.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/1.0.1.99 (Preview Release) Date: 10 Jan 2002 13:40:18 -0500 Message-Id: <1010688057.25378.13.camel@unaropia> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 608 Lines: 23 Unsure as of yet. I need to see why that happened. On Thu, 2002-01-10 at 13:28, Steve Lord wrote: > On Thu, 2002-01-10 at 12:21, Eric Sandeen wrote: > > What kernel is this, stock XFS CVS, or after you merge it w/ the -mjc > > kernel? > > > > Also, can you be a bit more explicit about the steps you're taking when > > you see this problem? > > I fairly regularly do things like this - and I just did it again, no > problems here. > > Steve > > > -- > > Steve Lord voice: +1-651-683-3511 > Principal Engineer, Filesystem Software email: lord@sgi.com > From owner-linux-xfs@oss.sgi.com Thu Jan 10 11:44:39 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0AJidx21363 for linux-xfs-outgoing; Thu, 10 Jan 2002 11:44:39 -0800 Received: from zok.sgi.com (zok.sgi.com [204.94.215.101]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0AJiZg21341 for ; Thu, 10 Jan 2002 11:44:35 -0800 Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by zok.sgi.com (8.11.4/8.11.4/linux-outbound_gateway-1.1) with ESMTP id g0AIiRo25224 for ; Thu, 10 Jan 2002 10:44:27 -0800 Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id MAA4032707; Thu, 10 Jan 2002 12:43:10 -0600 (CST) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id MAA56082; Thu, 10 Jan 2002 12:43:10 -0600 (CST) Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id g0AIg1h01714; Thu, 10 Jan 2002 12:42:01 -0600 Subject: Re: XFS is innocent - was: vmware+XFS+duron+viakt133 - works? From: Steve Lord To: Olaf =?iso-8859-2?Q?Fr=B1czyk?= Cc: linux-xfs@oss.sgi.com In-Reply-To: <20020110183051.A1483@venus.local.navi.pl> References: <20020110183051.A1483@venus.local.navi.pl> Content-Type: text/plain; charset=iso-8859-2 X-Mailer: Evolution/1.0.0.99+cvs.2001.12.18.08.57 (Preview Release) Date: 10 Jan 2002 12:42:01 -0600 Message-Id: <1010688121.676.111.camel@jen.americas.sgi.com> Mime-Version: 1.0 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id g0AJiZg21342 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 983 Lines: 28 On Thu, 2002-01-10 at 11:30, Olaf Fr±czyk wrote: > Hi, > I have installed clean RH7.2 on one free partition on my machine. Removed > RH gcc, installed compat-egcs, compiled new kernel (2.4.17) with xfs > (using the same sources as previous) and ... no problems. > So I moved kernel, modules to my working system, and ... it works. > So something with my system is wrong, and the problems are not XFS related. > Now, I have to find what :(( > Or compiler, or glibc I suppose. > I have RH 7.1, with updated glibc to 2.2.4-14 (on the new installed 7.2 is > 2.2.4-13), and I use egcs from RH 6.x. And on the new I installed > compat-egcs and compat-glibc-6.2-2.1.3.2. I have pretty good luck with the compiler from redhat rawhide, gcc-2.96-101 I have plain old PIII chips in all my boxes though. Steve > > Regards, > > Olaf Fraczyk -- Steve Lord voice: +1-651-683-3511 Principal Engineer, Filesystem Software email: lord@sgi.com From owner-linux-xfs@oss.sgi.com Thu Jan 10 12:19:05 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0AKJ5a22380 for linux-xfs-outgoing; Thu, 10 Jan 2002 12:19:05 -0800 Received: from web20307.mail.yahoo.com (web20307.mail.yahoo.com [216.136.226.88]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0AKJ0g22351 for ; Thu, 10 Jan 2002 12:19:00 -0800 Message-ID: <20020110191858.2729.qmail@web20307.mail.yahoo.com> Received: from [63.113.218.19] by web20307.mail.yahoo.com via HTTP; Thu, 10 Jan 2002 11:18:58 PST Date: Thu, 10 Jan 2002 11:18:58 -0800 (PST) From: Q A Subject: Partition gone on XFS system (I'm not on the mailing list) To: linux-xfs@oss.sgi.com Cc: qarce_mail_lists@yahoo.com MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 832 Lines: 32 Hello, I have a build system which has been up running RH-SGI 7.1 with the 2.4.9-13 smp xfs kernel for about 45 days. Wednesday morning the system went down and would not come up. Using the install CD I was able to access the drive. The partitions are: hda1 - /boot hda2 - Extended hda5 - /root hda6 - swap hda7 - /build running xfs_check/repair on the drive... hda1 no problems, hda5 no data found!!!! (this is my problem), hda6 (who cares), hda7 check found errors, and repair took some time. Looks like it fixed a lot. I need to know how to determine if the problem was physical or fs related. xfs_repair just spun for a while on hda5. Any tools, ideas, help... Thanks, Quentin __________________________________________________ Do You Yahoo!? Send FREE video emails in Yahoo! Mail! http://promo.yahoo.com/videomail/ From owner-linux-xfs@oss.sgi.com Thu Jan 10 13:13:46 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0ALDkv23769 for linux-xfs-outgoing; Thu, 10 Jan 2002 13:13:46 -0800 Received: from lynx.adilger.int (h24-64-71-161.cg.shawcable.net [24.64.71.161]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0ALDgg23747 for ; Thu, 10 Jan 2002 13:13:42 -0800 Received: (from adilger@localhost) by lynx.adilger.int (8.11.2/8.11.2) id g0AKCvc26277; Thu, 10 Jan 2002 13:12:57 -0700 Date: Thu, 10 Jan 2002 13:12:57 -0700 From: Andreas Dilger To: Adrian Head Cc: Eric Sandeen , Linux XFS Mailing List , linux-lvm@sistina.com, ext2-devel@lists.sourceforge.net Subject: Re: [linux-lvm] Re: Unable to get XFS, ext3, reiserfs & LVM to coexist happily Message-ID: <20020110131257.E771@lynx.adilger.int> Mail-Followup-To: Adrian Head , Eric Sandeen , Linux XFS Mailing List , linux-lvm@sistina.com, ext2-devel@lists.sourceforge.net References: <200201020451.g024pPg00867@oss.sgi.com> <200201050212.TAA16774@cthulhu.turbolabs.com> <20020105142527.I12868@lynx.no> <200201101521.IAA17651@cthulhu.turbolabs.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: <200201101521.IAA17651@cthulhu.turbolabs.com>; from ahead@bigpond.net.au on Fri, Jan 11, 2002 at 01:21:26AM +1000 X-GPG-Key: 1024D/0D35BED6 X-GPG-Fingerprint: 7A37 5D79 BF1B CECA D44F 8A29 A488 39F5 0D35 BED6 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 1285 Lines: 28 On Jan 11, 2002 01:21 +1000, Adrian Head wrote: > The last problem is that in only some of my tests when I "ls" the overflowed > snapshot "ls" complains about missing directories and files, "echo *" shows > what use to be there and ext3 generates errors in the logs: > EXT3-fs error (device lvm(58,5)): ext3_readdir" directory #2 contains a hole > at offset 0 Well, given that the snapshot is now broken and LVM is refusing I/O on it, what do you expect the filesystem to do? This is what LVM _intends_ to happen, because the snapshot can no longer hold all of the data to keep it consistent. The ext3 error is reporting that it tried to read the directory (root = #2) and it got nothing back. The reason you see some files and not others is because those blocks happen to still be in the cache, and it does not go to LVM to try and re-read them. Eventually, as the memory is needed for other things, you will no longer be able to read anything. I suppose it would be possible to have LVM do an "unmount" of any fs using a bad snapshot device from within the kernel, but whether people actually want that to happen is another question entirely. Cheers, Andreas -- Andreas Dilger http://sourceforge.net/projects/ext2resize/ http://www-mddsp.enel.ucalgary.ca/People/adilger/ From owner-linux-xfs@oss.sgi.com Thu Jan 10 13:47:31 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0ALlVd24826 for linux-xfs-outgoing; Thu, 10 Jan 2002 13:47:31 -0800 Received: from blipvert.blank.org (blipvert.blank.org [216.112.239.86]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0ALlRg24804 for ; Thu, 10 Jan 2002 13:47:27 -0800 Received: (qmail 16057 invoked by uid 500); 10 Jan 2002 20:47:22 -0000 Date: Thu, 10 Jan 2002 15:47:22 -0500 From: "Nathan J. Mehl" To: Eric Sandeen Cc: Glenn Meuth , linux-xfs@oss.sgi.com, atici@math.columbia.edu Subject: Re: NVidia & XFS Message-ID: <20020110154722.X15376@blank.org> Mail-Followup-To: Eric Sandeen , Glenn Meuth , linux-xfs@oss.sgi.com, atici@math.columbia.edu References: <20020110172250.93315.qmail@web20302.mail.yahoo.com> <1010686810.2848.6.camel@stout.americas.sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit User-Agent: Mutt/1.2.5.1i In-Reply-To: <1010686810.2848.6.camel@stout.americas.sgi.com>; from sandeen@sgi.com on Thu, Jan 10, 2002 at 12:20:10PM -0600 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 726 Lines: 17 In the immortal words of Eric Sandeen (sandeen@sgi.com): > You'll have to ask NVidia about it, there's no way to debug it on this > end. This is actually a FAQ in the docs for nvidia's drivers. Short form: why would you _expect_ using two completely different drivers to control the same piece of hardware to work? :) -n ------------------------------------------------------------- "Many argue that it is an outrage to expect Elián González to live in a place that tolerates no dissent or freedom of political expression. But I don't think Miami is so bad." (--Maureen Dowd) ----------------------------------------------------- From owner-linux-xfs@oss.sgi.com Thu Jan 10 13:56:27 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0ALuRd25118 for linux-xfs-outgoing; Thu, 10 Jan 2002 13:56:27 -0800 Received: from palrel10.hp.com (palrel10.hp.com [156.153.255.245]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0ALuPg25095 for ; Thu, 10 Jan 2002 13:56:25 -0800 Received: from xparelay1.corp.hp.com (xparelay1.corp.hp.com [15.58.136.173]) by palrel10.hp.com (Postfix) with ESMTP id 2F7BD400092 for ; Thu, 10 Jan 2002 12:56:16 -0800 (PST) Received: from xpabh4.corp.hp.com (xpabh4.corp.hp.com [15.58.136.1]) by xparelay1.corp.hp.com (Postfix) with ESMTP id 1D75E804C32 for ; Thu, 10 Jan 2002 12:56:16 -0800 (PST) Received: by xpabh4.corp.hp.com with Internet Mail Service (5.5.2653.19) id ; Thu, 10 Jan 2002 12:56:15 -0800 Message-ID: From: "ZINKEVICIUS,MATT (HP-Loveland,ex1)" To: "'linux-xfs@oss.sgi.com'" Subject: attr_multi() Date: Thu, 10 Jan 2002 12:56:12 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 314 Lines: 10 Hi all, The attr_multi() function bombs out if we try to deal with more than one attribute at a time. Is this a know bug? I saw that there was a bug fixed (462005 - attr_multi broken) on IRIX. Is this related? Thanks in advance! Matt Zinkevicius Software Engineer Network Storage Array Solutions Hewlett-Packard From owner-linux-xfs@oss.sgi.com Thu Jan 10 14:02:04 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0AM24A25379 for linux-xfs-outgoing; Thu, 10 Jan 2002 14:02:04 -0800 Received: from oflmta02bw.bigpond.com (oflmta02bw.bigpond.com [139.134.6.23] (may be forged)) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0AM1wg25357 for ; Thu, 10 Jan 2002 14:01:59 -0800 Message-Id: <200201102201.g0AM1wg25357@oss.sgi.com> Received: from there ([144.135.24.87]) by oflmta02bw.bigpond.com (Netscape Messaging Server 4.15) with SMTP id GPQQQR00.049; Fri, 11 Jan 2002 07:08:51 +1000 Received: from CPE-144-137-136-173.qld.bigpond.net.au ([144.137.136.173]) by bwmam07.mailsvc.email.bigpond.com(MailRouter V3.0h 62/15186499); 11 Jan 2002 07:01:49 Content-Type: text/plain; charset="us-ascii" From: Adrian Head To: Andreas Dilger Subject: Re: [linux-lvm] Re: Unable to get XFS, ext3, reiserfs & LVM to coexist happily Date: Fri, 11 Jan 2002 07:01:43 +1000 X-Mailer: KMail [version 1.3.1] Cc: Eric Sandeen , Linux XFS Mailing List , linux-lvm@sistina.com, ext2-devel@lists.sourceforge.net References: <200201020451.g024pPg00867@oss.sgi.com> <200201101521.IAA17651@cthulhu.turbolabs.com> <20020110131257.E771@lynx.adilger.int> In-Reply-To: <20020110131257.E771@lynx.adilger.int> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 1305 Lines: 31 On Fri, 11 Jan 2002 06:12, Andreas Dilger wrote: > > Well, given that the snapshot is now broken and LVM is refusing I/O on it, > what do you expect the filesystem to do? This is what LVM _intends_ to > happen, because the snapshot can no longer hold all of the data to keep > it consistent. > > The ext3 error is reporting that it tried to read the directory (root = #2) > and it got nothing back. The reason you see some files and not others is > because those blocks happen to still be in the cache, and it does not go > to LVM to try and re-read them. Eventually, as the memory is needed for > other things, you will no longer be able to read anything. > > I suppose it would be possible to have LVM do an "unmount" of any fs > using a bad snapshot device from within the kernel, but whether people > actually want that to happen is another question entirely. If this is what is considered normal operation then everything is fine. Thats why I decided to ask - to find out :-). >From my previous tests the behaviour I was observing was that once the snapshot had overflowed a "ls" on the snapshot showed nothing. This still appears to be the behaviour of resierfs. Cool - if this is standard behaviour then everything seems fixed :-) -- Adrian Head (Public Key available on request.) From owner-linux-xfs@oss.sgi.com Thu Jan 10 14:12:09 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0AMC9x25682 for linux-xfs-outgoing; Thu, 10 Jan 2002 14:12:09 -0800 Received: from awacs.dhs.org (node10450.a2000.nl [24.132.4.80]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0AMBwg25655 for ; Thu, 10 Jan 2002 14:11:59 -0800 Received: (from p@localhost) by awacs.dhs.org (8.11.0/8.9.3) id g0ALBtn00937 for linux-xfs@oss.sgi.com; Thu, 10 Jan 2002 22:11:55 +0100 Date: Thu, 10 Jan 2002 22:11:55 +0100 From: Pascal Haakmat To: linux-xfs@oss.sgi.com Subject: Oops with 2.4.16 Message-ID: <20020110221155.A912@awacs.dhs.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 3617 Lines: 74 Another Oops today. Background: these oopses always happen when I am about to write to a file; usually when I'm about to record audio. Kernel version: 2.4.16 GCC version: gcc version egcs-2.91.66 19990314/Linux (egcs-1.1.2 release) Hardware: Dual PIII at 600MHz, 440GX SuperMicro P6DGU mainboard, 2 IDE disks mounted as XFS volumes, SCSI CDROM & CDRW on built-in AIC7890 (not in use at the time), 512MB of RAM. I can reproduce Oopses like this quite reliably. They usually occur after a day or so but sometimes they happen earlier. They happen with or without low-latency patches, and have also occurred with kernel 2.4.5/XFS release 1.0.1, and kernel 2.4.14/XFS release 1.0.2. After this Oops has occurred, the machine usually continues to be somewhat usable, but data can no longer be written; that is, logging in or executing 'sync' or rebooting properly are not possible. ksymoops output: ksymoops 2.3.4 on i686 2.4.16-xfs-ll. Options used -V (default) -k /proc/ksyms (default) -l /proc/modules (default) -o /lib/modules/2.4.16-xfs-ll/ (default) -m /usr/src/linux/System.map (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. Jan 10 21:41:38 awacs kernel: Unable to handle kernel NULL pointer dereference at virtual address 00000008 Jan 10 21:41:38 awacs kernel: c01ccb41 Jan 10 21:41:38 awacs kernel: *pde = 00000000 Jan 10 21:41:38 awacs kernel: Oops: 0000 Jan 10 21:41:38 awacs kernel: CPU: 0 Jan 10 21:41:38 awacs kernel: EIP: 0010:[xfs_syncsub+2393/3112] Not tainted Jan 10 21:41:38 awacs kernel: EFLAGS: 00010246 Jan 10 21:41:38 awacs kernel: eax: 00000000 ebx: 00000008 ecx: dffdac00 edx: d5ff6a24 Jan 10 21:41:38 awacs kernel: esi: 00000000 edi: d2eaaec0 ebp: c03201e0 esp: c1955f30 Jan 10 21:41:38 awacs kernel: ds: 0018 es: 0018 ss: 0018 Jan 10 21:41:38 awacs kernel: Process kupdated (pid: 7, stackpage=c1955000) Jan 10 21:41:38 awacs kernel: Stack: dffea000 dffea044 c1954660 0008e000 00000001 00000010 00000001 dffdad18 Jan 10 21:41:38 awacs kernel: dffdad18 00000000 00000010 00000001 00000001 00000000 00000008 00000008 Jan 10 21:41:38 awacs kernel: 00000040 00000000 00000000 00000000 00000026 ffffff00 c1954000 00000000 Jan 10 21:41:38 awacs kernel: Call Trace: [xfs_sync+21/28] [linvfs_write_super+43/48] [sync_supers+220/272] [sync_old_buffers+47/144] [kupdate+297/304] Jan 10 21:41:38 awacs kernel: Code: 39 56 08 74 10 8b 5c 24 38 89 5c 24 3c 85 f6 0f 85 fa f7 ff Using defaults from ksymoops -t elf32-i386 -a i386 Code; 00000000 Before first symbol 00000000 <_EIP>: Code; 00000000 Before first symbol 0: 39 56 08 cmp %edx,0x8(%esi) Code; 00000003 Before first symbol 3: 74 10 je 15 <_EIP+0x15> 00000015 Before first symbol Code; 00000005 Before first symbol 5: 8b 5c 24 38 mov 0x38(%esp,1),%ebx Code; 00000009 Before first symbol 9: 89 5c 24 3c mov %ebx,0x3c(%esp,1) Code; 0000000d Before first symbol d: 85 f6 test %esi,%esi Code; 0000000f Before first symbol f: 0f 85 fa f7 ff 00 jne fff80f <_EIP+0xfff80f> 00fff80f Before first symbol 1 warning issued. Results may not be reliable. From owner-linux-xfs@oss.sgi.com Thu Jan 10 14:14:03 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0AME3k25864 for linux-xfs-outgoing; Thu, 10 Jan 2002 14:14:03 -0800 Received: from pneumatic-tube.sgi.com (pneumatic-tube.sgi.com [204.94.214.22]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0AMDvg25835 for ; Thu, 10 Jan 2002 14:13:57 -0800 Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id NAA09417 for ; Thu, 10 Jan 2002 13:14:36 -0800 (PST) mail_from (lord@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id PAA4055926; Thu, 10 Jan 2002 15:12:38 -0600 (CST) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id PAA81055; Thu, 10 Jan 2002 15:12:38 -0600 (CST) Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id g0ALBSw09647; Thu, 10 Jan 2002 15:11:28 -0600 Subject: Re: attr_multi() From: Steve Lord To: "ZINKEVICIUS,MATT ""(HP-Loveland,ex1)" Cc: "'linux-xfs@oss.sgi.com'" In-Reply-To: References: Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/1.0.0.99+cvs.2001.12.18.08.57 (Preview Release) Date: 10 Jan 2002 15:11:28 -0600 Message-Id: <1010697088.1772.10.camel@jen.americas.sgi.com> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 1087 Lines: 41 On Thu, 2002-01-10 at 14:56, ZINKEVICIUS,MATT (HP-Loveland,ex1) wrote: > Hi all, > The attr_multi() function bombs out if we try to deal with more than one > attribute at a time. Is this a know bug? I saw that there was a bug fixed > (462005 - attr_multi broken) on IRIX. Is this related? Thanks in advance! > > Matt Zinkevicius > Software Engineer > Network Storage Array Solutions > Hewlett-Packard Take a look in cmd/attr/libattr/attr.c In the _attr_multif() function, there is a call to attrctl, the last argument is 1, I suspect it should be count instead. if (attrctl(obj, type, ops, 1) < 0) { error = -1; goto free_mem; } becomes if (attrctl(obj, type, ops, count) < 0) { error = -1; goto free_mem; } Just a guess and I have not tried it. So just what is HP doing with an SGI filesystem and what do we get in return ;-) Steve -- Steve Lord voice: +1-651-683-3511 Principal Engineer, Filesystem Software email: lord@sgi.com From owner-linux-xfs@oss.sgi.com Thu Jan 10 14:24:26 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0AMOQf26103 for linux-xfs-outgoing; Thu, 10 Jan 2002 14:24:26 -0800 Received: from mta04bw.bigpond.com (mta04bw.bigpond.com [139.134.6.87]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0AMOFg26080 for ; Thu, 10 Jan 2002 14:24:15 -0800 Message-Id: <200201102224.g0AMOFg26080@oss.sgi.com> Received: from there ([144.135.24.72]) by mta04bw.bigpond.com (Netscape Messaging Server 4.15) with SMTP id GPQRRW00.FZY; Fri, 11 Jan 2002 07:31:08 +1000 Received: from CPE-144-137-136-173.qld.bigpond.net.au ([144.137.136.173]) by bwmam02.mailsvc.email.bigpond.com(MailRouter V3.0h 17/1158577); 11 Jan 2002 07:24:06 Content-Type: text/plain; charset="us-ascii" From: Adrian Head To: Pascal Haakmat , linux-xfs@oss.sgi.com Subject: Re: Oops with 2.4.16 Date: Fri, 11 Jan 2002 07:24:00 +1000 X-Mailer: KMail [version 1.3.1] References: <20020110221155.A912@awacs.dhs.org> In-Reply-To: <20020110221155.A912@awacs.dhs.org> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 4028 Lines: 90 This looks very simular to the other problem I'm having. You can find more info in a mail thread called "XFS dying when many processes copy many files/directories." On Fri, 11 Jan 2002 07:11, Pascal Haakmat wrote: > Another Oops today. > > Background: these oopses always happen when I am about to write to a file; > usually when I'm about to record audio. > > Kernel version: 2.4.16 > > GCC version: gcc version egcs-2.91.66 19990314/Linux (egcs-1.1.2 release) > > Hardware: Dual PIII at 600MHz, 440GX SuperMicro P6DGU mainboard, 2 IDE > disks mounted as XFS volumes, SCSI CDROM & CDRW on built-in AIC7890 (not in > use at the time), 512MB of RAM. > > I can reproduce Oopses like this quite reliably. They usually occur after a > day or so but sometimes they happen earlier. They happen with or without > low-latency patches, and have also occurred with kernel 2.4.5/XFS release > 1.0.1, and kernel 2.4.14/XFS release 1.0.2. > > After this Oops has occurred, the machine usually continues to be > somewhat usable, but data can no longer be written; that is, logging in or > executing 'sync' or rebooting properly are not possible. > > ksymoops output: > > ksymoops 2.3.4 on i686 2.4.16-xfs-ll. Options used > -V (default) > -k /proc/ksyms (default) > -l /proc/modules (default) > -o /lib/modules/2.4.16-xfs-ll/ (default) > -m /usr/src/linux/System.map (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. > > Jan 10 21:41:38 awacs kernel: Unable to handle kernel NULL pointer > dereference at virtual address 00000008 Jan 10 21:41:38 awacs kernel: > c01ccb41 > Jan 10 21:41:38 awacs kernel: *pde = 00000000 > Jan 10 21:41:38 awacs kernel: Oops: 0000 > Jan 10 21:41:38 awacs kernel: CPU: 0 > Jan 10 21:41:38 awacs kernel: EIP: 0010:[xfs_syncsub+2393/3112] Not > tainted Jan 10 21:41:38 awacs kernel: EFLAGS: 00010246 > Jan 10 21:41:38 awacs kernel: eax: 00000000 ebx: 00000008 ecx: dffdac00 > edx: d5ff6a24 Jan 10 21:41:38 awacs kernel: esi: 00000000 edi: d2eaaec0 > ebp: c03201e0 esp: c1955f30 Jan 10 21:41:38 awacs kernel: ds: 0018 > es: 0018 ss: 0018 > Jan 10 21:41:38 awacs kernel: Process kupdated (pid: 7, stackpage=c1955000) > Jan 10 21:41:38 awacs kernel: Stack: dffea000 dffea044 c1954660 0008e000 > 00000001 00000010 00000001 dffdad18 Jan 10 21:41:38 awacs kernel: > dffdad18 00000000 00000010 00000001 00000001 00000000 00000008 00000008 Jan > 10 21:41:38 awacs kernel: 00000040 00000000 00000000 00000000 > 00000026 ffffff00 c1954000 00000000 Jan 10 21:41:38 awacs kernel: Call > Trace: [xfs_sync+21/28] [linvfs_write_super+43/48] [sync_supers+220/272] > [sync_old_buffers+47/144] [kupdate+297/304] Jan 10 21:41:38 awacs kernel: > Code: 39 56 08 74 10 8b 5c 24 38 89 5c 24 3c 85 f6 0f 85 fa f7 ff Using > defaults from ksymoops -t elf32-i386 -a i386 > > Code; 00000000 Before first symbol > 00000000 <_EIP>: > Code; 00000000 Before first symbol > 0: 39 56 08 cmp %edx,0x8(%esi) > Code; 00000003 Before first symbol > 3: 74 10 je 15 <_EIP+0x15> 00000015 Before > first symbol Code; 00000005 Before first symbol > 5: 8b 5c 24 38 mov 0x38(%esp,1),%ebx > Code; 00000009 Before first symbol > 9: 89 5c 24 3c mov %ebx,0x3c(%esp,1) > Code; 0000000d Before first symbol > d: 85 f6 test %esi,%esi > Code; 0000000f Before first symbol > f: 0f 85 fa f7 ff 00 jne fff80f <_EIP+0xfff80f> 00fff80f > Before first symbol > > > 1 warning issued. Results may not be reliable. -- Adrian Head (Public Key available on request.) From owner-linux-xfs@oss.sgi.com Thu Jan 10 14:25:27 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0AMPRF26250 for linux-xfs-outgoing; Thu, 10 Jan 2002 14:25:27 -0800 Received: from www.fortuitous.com (cs6625128-203.austin.rr.com [66.25.128.203]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0AMPNg26228 for ; Thu, 10 Jan 2002 14:25:23 -0800 Received: by www.fortuitous.com (Postfix, from userid 500) id 867FC503; Thu, 10 Jan 2002 15:23:58 -0600 (CST) Date: Thu, 10 Jan 2002 15:23:58 -0600 From: pac@fortuitous.com To: linux-xfs@oss.sgi.com Subject: Disc Cloning, partitioning. Message-ID: <20020110152358.A15395@bistro.marx> Reply-To: pac@fortuitous.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.23i Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 691 Lines: 19 Is there a tool that I can use to grab the partition table from One disc and flash it on a Second disk? I didnt see anything like that from gpart or partimage. I basically want to be able to automatically clone an entire disk, with all of the data, but not by using 'dd' or ghost. Hopefully something that is smart enough to forget all the empty zeros. Thanks, -Phil Carinhas -- .--------------------------------------------------------. | Dr. Philip A. Carinhas | pac@fortuitous.com | | Fortuitous Technologies Inc. | http://fortuitous.com | | Linux Consulting & Training | Tel : 1-512-467-2154 | `--------------------------------------------------------' From owner-linux-xfs@oss.sgi.com Thu Jan 10 14:28:33 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0AMSXN26410 for linux-xfs-outgoing; Thu, 10 Jan 2002 14:28:33 -0800 Received: from sto-vo-kor.koschikode.com (sto-vo-kor.koschikode.com [195.124.129.42]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0AMSKg26388 for ; Thu, 10 Jan 2002 14:28:20 -0800 Received: from warp9.koschikode.com (pD9E0E09A.dip.t-dialin.net [217.224.224.154]) by sto-vo-kor.koschikode.com (Postfix) with ESMTP id 7E73FF48C; Thu, 10 Jan 2002 22:28:09 +0100 (CET) Received: from koschikode.com (pktomo.koschikode.com [192.168.200.10]) by warp9.koschikode.com (Postfix) with ESMTP id E1AECCED6; Thu, 10 Jan 2002 22:27:56 +0100 (CET) Message-ID: <3C3E075C.4DC13D5@koschikode.com> Date: Thu, 10 Jan 2002 22:27:56 +0100 From: Juri Haberland X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.17-xfs i686) X-Accept-Language: en MIME-Version: 1.0 To: "Brian C. Huffman" Cc: linux-xfs@oss.sgi.com Subject: Re: 2.4.17-xfs w/ VMWare References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 362 Lines: 13 "Brian C. Huffman" wrote: > > All, > > Are there any known issues w/ 2.4.17 w/ XFS and VMWare? I've been > trying to get this combo to work (w/ win2k guest) and am having quite a > few problems. I keep getting "stack shutdowns" inside the vmware machine. I'm running exactly this combination at work and have never seen this error message... Juri From owner-linux-xfs@oss.sgi.com Thu Jan 10 14:28:40 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0AMSev26587 for linux-xfs-outgoing; Thu, 10 Jan 2002 14:28:40 -0800 Received: from awacs.dhs.org (node10450.a2000.nl [24.132.4.80]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0AMSbg26461 for ; Thu, 10 Jan 2002 14:28:37 -0800 Received: (from p@localhost) by awacs.dhs.org (8.11.0/8.9.3) id g0ALSYr01044 for linux-xfs@oss.sgi.com; Thu, 10 Jan 2002 22:28:34 +0100 Date: Thu, 10 Jan 2002 22:28:34 +0100 From: Pascal Haakmat To: linux-xfs@oss.sgi.com Subject: Mailing list archive links broken Message-ID: <20020110222834.A1041@awacs.dhs.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 301 Lines: 9 By the way, the mailing list archive links at http://oss.sgi.com/projects/xfs/ml.html are broken, they are missing a closing quote here: | v May 2000 From owner-linux-xfs@oss.sgi.com Thu Jan 10 14:31:58 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0AMVw926907 for linux-xfs-outgoing; Thu, 10 Jan 2002 14:31:58 -0800 Received: from yog-sothoth.sgi.com (eugate.sgi.com [192.48.160.10]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0AMVkg26885 for ; Thu, 10 Jan 2002 14:31:47 -0800 Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by yog-sothoth.sgi.com (980305.SGI.8.8.8-aspam-6.2/980304.SGI-aspam-europe) via ESMTP id WAA1602597 for ; Thu, 10 Jan 2002 22:29:08 +0100 (CET) mail_from (lord@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id PAA4061960; Thu, 10 Jan 2002 15:30:25 -0600 (CST) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id PAA83927; Thu, 10 Jan 2002 15:30:25 -0600 (CST) Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id g0ALTFt10863; Thu, 10 Jan 2002 15:29:15 -0600 Subject: Re: Oops with 2.4.16 From: Steve Lord To: Pascal Haakmat Cc: linux-xfs@oss.sgi.com In-Reply-To: <20020110221155.A912@awacs.dhs.org> References: <20020110221155.A912@awacs.dhs.org> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/1.0.0.99+cvs.2001.12.18.08.57 (Preview Release) Date: 10 Jan 2002 15:29:14 -0600 Message-Id: <1010698155.1829.24.camel@jen.americas.sgi.com> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 4356 Lines: 93 Could you do this please: cd linux rm fs/xfs/xfs_vfsops.o make CFLAGS_xfs_vfsops.o=-g vmlinux s=$(sed -ne '/xfs_syncsub/s/ .*//p' System.map | tr '[a-z]' '[A-Z]') e=$(echo -e "obase=16\nibase=16\n$s+3112" | bc) objdump -S --start-address=0x$s --stop-address=0x$e vmlinux And send me the output, if I got that right it will generate a mixed source and disassembly listing of the function. Steve On Thu, 2002-01-10 at 15:11, Pascal Haakmat wrote: > Another Oops today. > > Background: these oopses always happen when I am about to write to a file; > usually when I'm about to record audio. > > Kernel version: 2.4.16 > > GCC version: gcc version egcs-2.91.66 19990314/Linux (egcs-1.1.2 release) > > Hardware: Dual PIII at 600MHz, 440GX SuperMicro P6DGU mainboard, 2 IDE disks > mounted as XFS volumes, SCSI CDROM & CDRW on built-in AIC7890 (not in use at > the time), 512MB of RAM. > > I can reproduce Oopses like this quite reliably. They usually occur after a > day or so but sometimes they happen earlier. They happen with or without > low-latency patches, and have also occurred with kernel 2.4.5/XFS release > 1.0.1, and kernel 2.4.14/XFS release 1.0.2. > > After this Oops has occurred, the machine usually continues to be > somewhat usable, but data can no longer be written; that is, logging in or > executing 'sync' or rebooting properly are not possible. > > ksymoops output: > > ksymoops 2.3.4 on i686 2.4.16-xfs-ll. Options used > -V (default) > -k /proc/ksyms (default) > -l /proc/modules (default) > -o /lib/modules/2.4.16-xfs-ll/ (default) > -m /usr/src/linux/System.map (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. > > Jan 10 21:41:38 awacs kernel: Unable to handle kernel NULL pointer dereference at virtual address 00000008 > Jan 10 21:41:38 awacs kernel: c01ccb41 > Jan 10 21:41:38 awacs kernel: *pde = 00000000 > Jan 10 21:41:38 awacs kernel: Oops: 0000 > Jan 10 21:41:38 awacs kernel: CPU: 0 > Jan 10 21:41:38 awacs kernel: EIP: 0010:[xfs_syncsub+2393/3112] Not tainted > Jan 10 21:41:38 awacs kernel: EFLAGS: 00010246 > Jan 10 21:41:38 awacs kernel: eax: 00000000 ebx: 00000008 ecx: dffdac00 edx: d5ff6a24 > Jan 10 21:41:38 awacs kernel: esi: 00000000 edi: d2eaaec0 ebp: c03201e0 esp: c1955f30 > Jan 10 21:41:38 awacs kernel: ds: 0018 es: 0018 ss: 0018 > Jan 10 21:41:38 awacs kernel: Process kupdated (pid: 7, stackpage=c1955000) > Jan 10 21:41:38 awacs kernel: Stack: dffea000 dffea044 c1954660 0008e000 00000001 00000010 00000001 dffdad18 > Jan 10 21:41:38 awacs kernel: dffdad18 00000000 00000010 00000001 00000001 00000000 00000008 00000008 > Jan 10 21:41:38 awacs kernel: 00000040 00000000 00000000 00000000 00000026 ffffff00 c1954000 00000000 > Jan 10 21:41:38 awacs kernel: Call Trace: [xfs_sync+21/28] [linvfs_write_super+43/48] [sync_supers+220/272] [sync_old_buffers+47/144] [kupdate+297/304] > Jan 10 21:41:38 awacs kernel: Code: 39 56 08 74 10 8b 5c 24 38 89 5c 24 3c 85 f6 0f 85 fa f7 ff > Using defaults from ksymoops -t elf32-i386 -a i386 > > Code; 00000000 Before first symbol > 00000000 <_EIP>: > Code; 00000000 Before first symbol > 0: 39 56 08 cmp %edx,0x8(%esi) > Code; 00000003 Before first symbol > 3: 74 10 je 15 <_EIP+0x15> 00000015 Before first symbol > Code; 00000005 Before first symbol > 5: 8b 5c 24 38 mov 0x38(%esp,1),%ebx > Code; 00000009 Before first symbol > 9: 89 5c 24 3c mov %ebx,0x3c(%esp,1) > Code; 0000000d Before first symbol > d: 85 f6 test %esi,%esi > Code; 0000000f Before first symbol > f: 0f 85 fa f7 ff 00 jne fff80f <_EIP+0xfff80f> 00fff80f Before first symbol > > > 1 warning issued. Results may not be reliable. -- Steve Lord voice: +1-651-683-3511 Principal Engineer, Filesystem Software email: lord@sgi.com From owner-linux-xfs@oss.sgi.com Thu Jan 10 14:33:51 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0AMXpv27077 for linux-xfs-outgoing; Thu, 10 Jan 2002 14:33:51 -0800 Received: from sgi.com (sgi-too.SGI.COM [204.94.211.39]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0AMXlg27055 for ; Thu, 10 Jan 2002 14:33:47 -0800 Received: from ledzep.americas.sgi.com (relay.sgi.com [137.38.226.97] (may be forged)) by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id NAA09129 for ; Thu, 10 Jan 2002 13:31:09 -0800 (PST) mail_from (nstraz@sgi.com) Received: from maine.americas.sgi.com (maine.americas.sgi.com [128.162.191.42]) by ledzep.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id PAA06519; Thu, 10 Jan 2002 15:32:17 -0600 (CST) Received: from nstraz by maine.americas.sgi.com with local (Exim 3.33 #1 (Debian)) id 16Omo2-0004vF-00; Thu, 10 Jan 2002 15:32:14 -0600 Date: Thu, 10 Jan 2002 15:32:14 -0600 From: Nathan Straz To: pac@fortuitous.com Cc: linux-xfs@oss.sgi.com Subject: Re: Disc Cloning, partitioning. Message-ID: <20020110213214.GH13972@sgi.com> Mail-Followup-To: pac@fortuitous.com, linux-xfs@oss.sgi.com References: <20020110152358.A15395@bistro.marx> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20020110152358.A15395@bistro.marx> User-Agent: Mutt/1.3.25i Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 893 Lines: 22 On Thu, Jan 10, 2002 at 03:23:58PM -0600, pac@fortuitous.com wrote: > Is there a tool that I can use to grab the partition table from > One disc and flash it on a Second disk? I didnt see anything like > that from gpart or partimage. Take a look at sfdisk. It's a script driven version of fdisk. It's in util-linux >= 2.7. >From the sfdisk(8) man page: -d Dump the partitions of a device in a format useful as input to sfdisk. For example, % sfdisk -d /dev/hda > hda.out % sfdisk /dev/hda < hda.out will correct the bad last extended partition that the OS/2 fdisk creates. -- 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 Thu Jan 10 14:44:43 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0AMih727361 for linux-xfs-outgoing; Thu, 10 Jan 2002 14:44:43 -0800 Received: from mail.ocs.com.au (mail.ocs.com.au [203.34.97.2]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0AMicg27336 for ; Thu, 10 Jan 2002 14:44:38 -0800 Received: (qmail 29734 invoked from network); 10 Jan 2002 21:44:34 -0000 Received: from ocs3.intra.ocs.com.au (192.168.255.3) by mail.ocs.com.au with SMTP; 10 Jan 2002 21:44:34 -0000 Received: by ocs3.intra.ocs.com.au (Postfix, from userid 16331) id 20EFC300095; Fri, 11 Jan 2002 08:44:32 +1100 (EST) Received: from ocs3.intra.ocs.com.au (localhost [127.0.0.1]) by ocs3.intra.ocs.com.au (Postfix) with ESMTP id 08DFC94; Fri, 11 Jan 2002 08:44:31 +1100 (EST) X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 From: Keith Owens To: Steve Lord Cc: Pascal Haakmat , linux-xfs@oss.sgi.com Subject: Re: Oops with 2.4.16 In-reply-to: Your message of "10 Jan 2002 15:29:14 MDT." <1010698155.1829.24.camel@jen.americas.sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 11 Jan 2002 08:44:26 +1100 Message-ID: <30631.1010699066@ocs3.intra.ocs.com.au> Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 788 Lines: 20 On 10 Jan 2002 15:29:14 -0600, Steve Lord wrote: >cd linux >rm fs/xfs/xfs_vfsops.o >make CFLAGS_xfs_vfsops.o=-g vmlinux >s=$(sed -ne '/xfs_syncsub/s/ .*//p' System.map | tr '[a-z]' '[A-Z]') >e=$(echo -e "obase=16\nibase=16\n$s+3112" | bc) >objdump -S --start-address=0x$s --stop-address=0x$e vmlinux Hey, no fair pinching my debugging tools :). The assignment for s and e should be s=$(sed -ne '/ xfs_syncsub$/s/ .*//p' System.map | tr '[a-z]' '[A-Z]') e=$(echo -e "obase=16\nibase=16\n$s+C28" | bc) klogd decoded the oops using decimal, objdump needs hex. I never trust the klogd decode, it has too many bugs. Can you change /etc/rc.d/init.d/syslog to start klogd as "klogd -x", restart syslog, reproduce the problem and decode the untouched log, just to be sure. From owner-linux-xfs@oss.sgi.com Thu Jan 10 14:49:44 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0AMnia27567 for linux-xfs-outgoing; Thu, 10 Jan 2002 14:49:44 -0800 Received: from palrel12.hp.com (palrel12.hp.com [156.153.255.237]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0AMneg27545 for ; Thu, 10 Jan 2002 14:49:40 -0800 Received: from xparelay2.corp.hp.com (xparelay2.corp.hp.com [15.58.137.112]) by palrel12.hp.com (Postfix) with ESMTP id 71833E003B8; Thu, 10 Jan 2002 13:49:33 -0800 (PST) Received: from xpabh3.corp.hp.com (xpabh3.corp.hp.com [15.58.136.223]) by xparelay2.corp.hp.com (Postfix) with ESMTP id 1C5ED4000ED; Thu, 10 Jan 2002 13:48:57 -0800 (PST) Received: by xpabh3.corp.hp.com with Internet Mail Service (5.5.2653.19) id ; Thu, 10 Jan 2002 13:49:33 -0800 Message-ID: From: "ZINKEVICIUS,MATT (HP-Loveland,ex1)" To: "'Steve Lord'" , "ZINKEVICIUS,MATT (HP-Loveland,ex1)" Cc: "'linux-xfs@oss.sgi.com'" Subject: RE: attr_multi() Date: Thu, 10 Jan 2002 13:49:31 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 739 Lines: 32 Steve, > Take a look in cmd/attr/libattr/attr.c > > In the _attr_multif() function, there is a call to attrctl, the > last argument is 1, I suspect it should be count instead. > > if (attrctl(obj, type, ops, 1) < 0) { > error = -1; > goto free_mem; > } > > becomes > > if (attrctl(obj, type, ops, count) < 0) { > error = -1; > goto free_mem; > } > > Just a guess and I have not tried it. I just saw this too. Trying it now... > > So just what is HP doing with an SGI filesystem and what do we get in > return ;-) NAS stuff. Storing NT ACLs as extended attributes. How about we send you a printer for every bug you fix ;-) --Matt From owner-linux-xfs@oss.sgi.com Thu Jan 10 14:55:12 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0AMtCw27856 for linux-xfs-outgoing; Thu, 10 Jan 2002 14:55:12 -0800 Received: from rj.sgi.com (rj.sgi.com [204.94.215.100]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0AMt8g27834 for ; Thu, 10 Jan 2002 14:55:08 -0800 Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by rj.sgi.com (8.11.4/8.11.4/linux-outbound_gateway-1.1) with ESMTP id g0ALt0Y20097 for ; Thu, 10 Jan 2002 13:55:00 -0800 Received: from poppy-e185.americas.sgi.com (poppy-e185.americas.sgi.com [128.162.185.207]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id PAA4010192 for ; Thu, 10 Jan 2002 15:53:44 -0600 (CST) Received: from stout.americas.sgi.com (stout.americas.sgi.com [128.162.187.5]) by poppy-e185.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.7) with ESMTP id PAA96800 for ; Thu, 10 Jan 2002 15:53:44 -0600 (CST) Subject: Re: Mailing list archive links broken From: Eric Sandeen Cc: linux-xfs@oss.sgi.com In-Reply-To: <20020110222834.A1041@awacs.dhs.org> References: <20020110222834.A1041@awacs.dhs.org> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/1.0 (Preview Release) Date: 10 Jan 2002 15:53:44 -0600 Message-Id: <1010699624.10050.26.camel@stout.americas.sgi.com> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 743 Lines: 22 Hm, are you sure you didn't lose something between the server and your computer? [eric@stout cvs]$ lynx -source http://oss.sgi.com/projects/xfs/ml.html | grep -A 1 0005 May 2000 -Eric On Thu, 2002-01-10 at 15:28, Pascal Haakmat wrote: > By the way, the mailing list archive links at > > http://oss.sgi.com/projects/xfs/ml.html > > are broken, they are missing a closing quote here: | > v > > May 2000 -- Eric Sandeen XFS for Linux http://oss.sgi.com/projects/xfs sandeen@sgi.com SGI, Inc. From owner-linux-xfs@oss.sgi.com Thu Jan 10 14:57:38 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0AMvcN28027 for linux-xfs-outgoing; Thu, 10 Jan 2002 14:57:38 -0800 Received: from awacs.dhs.org (node10450.a2000.nl [24.132.4.80]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0AMvIg28005 for ; Thu, 10 Jan 2002 14:57:18 -0800 Received: (from p@localhost) by awacs.dhs.org (8.11.0/8.9.3) id g0ALvBc01833; Thu, 10 Jan 2002 22:57:11 +0100 Date: Thu, 10 Jan 2002 22:57:11 +0100 From: Pascal Haakmat To: Eric Sandeen Cc: linux-xfs@oss.sgi.com Subject: Re: Oops with 2.4.16 Message-ID: <20020110225711.A1259@awacs.dhs.org> References: <20020110221155.A912@awacs.dhs.org> <1010697908.2812.22.camel@stout.americas.sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <1010697908.2812.22.camel@stout.americas.sgi.com>; from sandeen@sgi.com on Thu, Jan 10, 2002 at 03:25:08PM -0600 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 7195 Lines: 184 10/01/02 15:25, Eric Sandeen wrote: > Can you do a bit more work? > > Assuming your kernel has xfs built in, and you have a source tree that > can rebuild this exact kernel, try: > > cd /usr/src/linux > rm fs/xfs/xfs_vfsops.o > > then rebuild the kernel: > > make CFLAGS_xfs_vfsops.o=-g vmlinux [root@awacs linux]$ make CFLAGS_xfs_vfsops.o=-g vmlinux . scripts/mkversion > .tmpversion /bin/sh: invalid character 46 in exportstr for CFLAGS_xfs_vfsops.o /bin/sh: invalid character 46 in exportstr for CFLAGS_xfs_vfsops.o /bin/sh: invalid character 46 in exportstr for CFLAGS_xfs_vfsops.o /bin/sh: invalid character 46 in exportstr for CFLAGS_xfs_vfsops.o /bin/sh: invalid character 46 in exportstr for CFLAGS_xfs_vfsops.o /bin/sh: invalid character 46 in exportstr for CFLAGS_xfs_vfsops.o /bin/sh: invalid character 46 in exportstr for CFLAGS_xfs_vfsops.o /bin/sh: invalid character 46 in exportstr for CFLAGS_xfs_vfsops.o kgcc -D__KERNEL__ -I/usr/src/linux-2.4.16-xfs-ll/include -Wall -Wstrict-prototypes -Wno-trigraphs -O2 -fno-strict-aliasing -fno-common -fomit-frame-pointer -pi [Hmm..] > Then run objdump on /usr/src/vmlinux: > > objdump -S --start-address=c01ccb00 --stop-address=c01ccbff vmlinux > > (you can expand/contract --start-address and stop-address, just need > enough to contain your oops point (c01ccb41) and some surrounding code). [root@awacs linux]$ objdump -S --start-address=c01ccb00 --stop-address=c01ccbff vmlinux objdump: --start-address: bad number: c01ccb00 [Just read Keith's post, apparently the numbers should be 0x...] [root@awacs linux]$ objdump -S --start-address=0xc01ccb00 --stop-address=0xc01ccbff vmlinux [Wow, what a nice tool!] vmlinux: file format elf32-i386 Disassembly of section .text: c01ccb00 : if (mount_locked == B_FALSE) { XFS_MOUNT_ILOCK(mp); mount_locked = B_TRUE; IPOINTER_REMOVE(ip, mp); c01ccb00: 0c 89 or $0x89,%al c01ccb02: 70 08 jo c01ccb0c c01ccb04: 8b 4c 24 70 mov 0x70(%esp,1),%ecx c01ccb08: 8b 91 14 01 00 00 mov 0x114(%ecx),%edx c01ccb0e: 39 fa cmp %edi,%edx c01ccb10: 75 2f jne c01ccb41 c01ccb12: 89 b1 14 01 00 00 mov %esi,0x114(%ecx) c01ccb18: 89 f2 mov %esi,%edx c01ccb1a: eb 25 jmp c01ccb41 c01ccb1c: 8d 74 26 00 lea 0x0(%esi,1),%esi c01ccb20: 8b 5c 24 70 mov 0x70(%esp,1),%ebx c01ccb24: c7 83 14 01 00 00 00 movl $0x0,0x114(%ebx) c01ccb2b: 00 00 00 c01ccb2e: 31 f6 xor %esi,%esi continue; c01ccb30: 31 d2 xor %edx,%edx c01ccb32: eb 0d jmp c01ccb41 } ASSERT(ipointer_in == B_FALSE); ip = ip->i_mnext; c01ccb34: 8b 4c 24 70 mov 0x70(%esp,1),%ecx c01ccb38: 8b 76 08 mov 0x8(%esi),%esi c01ccb3b: 8b 91 14 01 00 00 mov 0x114(%ecx),%edx } while (ip->i_mnext != mp->m_inodes); [*ksymoops disassembly matches here*] c01ccb41: 39 56 08 cmp %edx,0x8(%esi) c01ccb44: 74 10 je c01ccb56 c01ccb46: 8b 5c 24 38 mov 0x38(%esp,1),%ebx c01ccb4a: 89 5c 24 3c mov %ebx,0x3c(%esp,1) c01ccb4e: 85 f6 test %esi,%esi c01ccb50: 0f 85 fa f7 ff ff jne c01cc350 XFS_MOUNT_IUNLOCK(mp); c01ccb56: 8b 4c 24 20 mov 0x20(%esp,1),%ecx c01ccb5a: 51 push %ecx c01ccb5b: e8 30 33 01 00 call c01dfe90 <_mutex_unlock> ASSERT(ipointer_in == B_FALSE); /* * Get the Quota Manager to flush the dquots in a similar manner. */ if (XFS_IS_QUOTA_ON(mp)) { c01ccb60: 83 c4 04 add $0x4,%esp c01ccb63: 8b 5c 24 70 mov 0x70(%esp,1),%ebx c01ccb67: f7 83 50 02 00 00 80 testl $0x180,0x250(%ebx) c01ccb6e: 01 00 00 c01ccb71: 74 3d je c01ccbb0 if ((error = xfs_qm_sync(mp, flags))) { c01ccb73: 0f bf 44 24 74 movswl 0x74(%esp,1),%eax c01ccb78: 50 push %eax c01ccb79: 53 push %ebx c01ccb7a: e8 01 d0 fa ff call c0179b80 c01ccb7f: 89 44 24 54 mov %eax,0x54(%esp,1) c01ccb83: 83 c4 08 add $0x8,%esp c01ccb86: 83 7c 24 4c 00 cmpl $0x0,0x4c(%esp,1) c01ccb8b: 74 23 je c01ccbb0 /* * If we got an IO error, we will be shutting down. * So, there's nothing more for us to do here. */ ASSERT(error != EIO || XFS_FORCED_SHUTDOWN(mp)); if (XFS_FORCED_SHUTDOWN(mp)) { c01ccb8d: f6 83 34 02 00 00 10 testb $0x10,0x234(%ebx) c01ccb94: 74 1a je c01ccbb0 kmem_free(ipointer, sizeof(xfs_iptr_t)); c01ccb96: 6a 18 push $0x18 c01ccb98: 57 push %edi c01ccb99: e8 16 2a 01 00 call c01df5b4 return XFS_ERROR(error); c01ccb9e: 8b 44 24 54 mov 0x54(%esp,1),%eax c01ccba2: 83 c4 08 add $0x8,%esp c01ccba5: e9 5d 02 00 00 jmp c01cce07 c01ccbaa: 8d b6 00 00 00 00 lea 0x0(%esi),%esi } } } /* * Flushing out dirty data above probably generated more * log activity, so if this isn't vfs_sync() then flush * the log again. If SYNC_WAIT is set then do it synchronously. */ if (!(flags & SYNC_BDFLUSH)) { c01ccbb0: 83 7c 24 28 00 cmpl $0x0,0x28(%esp,1) c01ccbb5: 75 24 jne c01ccbdb log_flags = XFS_LOG_FORCE; c01ccbb7: b8 02 00 00 00 mov $0x2,%eax if (flags & SYNC_WAIT) { c01ccbbc: ba 03 00 00 00 mov $0x3,%edx c01ccbc1: 83 7c 24 24 00 cmpl $0x0,0x24(%esp,1) c01ccbc6: 0f 45 c2 cmovne %edx,%eax log_flags |= XFS_LOG_SYNC; } xfs_log_force(mp, (xfs_lsn_t)0, log_flags); c01ccbc9: 50 push %eax c01ccbca: 6a 00 push $0x0 c01ccbcc: 6a 00 push $0x0 c01ccbce: 8b 4c 24 7c mov 0x7c(%esp,1),%ecx c01ccbd2: 51 push %ecx c01ccbd3: e8 08 f6 fe ff call c01bc1e0 } c01ccbd8: 83 c4 10 add $0x10,%esp if (flags & SYNC_FSDATA) { c01ccbdb: 8b 5c 24 74 mov 0x74(%esp,1),%ebx c01ccbdf: f6 c3 20 test $0x20,%bl c01ccbe2: 0f 84 db 00 00 00 je c01cccc3 /* * If this is vfs_sync() then only sync the superblock * if we can lock it without sleeping and it is not pinned. */ if (flags & SYNC_BDFLUSH) { c01ccbe8: 83 7c 24 14 00 cmpl $0x0,0x14(%esp,1) c01ccbed: 74 71 je c01ccc60 bp = xfs_getsb(mp, XFS_BUF_TRYLOCK); c01ccbef: 68 00 40 00 00 push $0x4000 c01ccbf4: 8b 4c 24 74 mov 0x74(%esp,1),%ecx c01ccbf8: 51 push %ecx c01ccbf9: e8 6a 82 ff ff call c01c4e68 c01ccbfe: 89 44 24 5c mov %eax,0x5c(%esp,1) Disassembly of section .text.lock: Disassembly of section .text.init: From owner-linux-xfs@oss.sgi.com Thu Jan 10 14:58:21 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0AMwLj28162 for linux-xfs-outgoing; Thu, 10 Jan 2002 14:58:21 -0800 Received: from awacs.dhs.org (node10450.a2000.nl [24.132.4.80]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0AMwIg28140 for ; Thu, 10 Jan 2002 14:58:18 -0800 Received: (from p@localhost) by awacs.dhs.org (8.11.0/8.9.3) id g0ALwAu01838; Thu, 10 Jan 2002 22:58:10 +0100 Date: Thu, 10 Jan 2002 22:58:10 +0100 From: Pascal Haakmat To: Eric Sandeen Cc: linux-xfs@oss.sgi.com Subject: Re: Mailing list archive links broken Message-ID: <20020110225810.B1259@awacs.dhs.org> References: <20020110222834.A1041@awacs.dhs.org> <1010699119.2812.24.camel@stout.americas.sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <1010699119.2812.24.camel@stout.americas.sgi.com>; from sandeen@sgi.com on Thu, Jan 10, 2002 at 03:45:19PM -0600 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 341 Lines: 11 10/01/02 15:45, Eric Sandeen wrote: > Hm, are you sure you didn't lose something between the server and your > computer? > > [eric@stout cvs]$ lynx -source http://oss.sgi.com/projects/xfs/ml.html | grep -A 1 0005 > > May 2000 Argh, I meant a closing thingie: > From owner-linux-xfs@oss.sgi.com Thu Jan 10 15:02:12 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0AN2CH28374 for linux-xfs-outgoing; Thu, 10 Jan 2002 15:02:12 -0800 Received: from zok.sgi.com (zok.sgi.com [204.94.215.101]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0AN28g28351 for ; Thu, 10 Jan 2002 15:02:08 -0800 Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by zok.sgi.com (8.11.4/8.11.4/linux-outbound_gateway-1.1) with ESMTP id g0AM21o06238 for ; Thu, 10 Jan 2002 14:02:01 -0800 Received: from poppy-e185.americas.sgi.com (poppy-e185.americas.sgi.com [128.162.185.207]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id QAA4066099; Thu, 10 Jan 2002 16:00:45 -0600 (CST) Received: from stout.americas.sgi.com (stout.americas.sgi.com [128.162.187.5]) by poppy-e185.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.7) with ESMTP id QAA94264; Thu, 10 Jan 2002 16:00:45 -0600 (CST) Subject: Re: Mailing list archive links broken From: Eric Sandeen To: Pascal Haakmat Cc: linux-xfs@oss.sgi.com In-Reply-To: <20020110225810.B1259@awacs.dhs.org> References: <20020110222834.A1041@awacs.dhs.org> <1010699119.2812.24.camel@stout.americas.sgi.com> <20020110225810.B1259@awacs.dhs.org> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/1.0 (Preview Release) Date: 10 Jan 2002 16:00:45 -0600 Message-Id: <1010700045.10049.32.camel@stout.americas.sgi.com> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 618 Lines: 24 On Thu, 2002-01-10 at 15:58, Pascal Haakmat wrote: > 10/01/02 15:45, Eric Sandeen wrote: > > > Hm, are you sure you didn't lose something between the server and your > > computer? > > > > [eric@stout cvs]$ lynx -source http://oss.sgi.com/projects/xfs/ml.html | grep -A 1 0005 > > > > May 2000 > > Argh, I meant a closing thingie: > Ehh.... right. Funny what you don't see when you're not looking for it. :) I'll fix that. :) -Eric -- Eric Sandeen XFS for Linux http://oss.sgi.com/projects/xfs sandeen@sgi.com SGI, Inc. From owner-linux-xfs@oss.sgi.com Thu Jan 10 15:39:24 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0ANdOD30890 for linux-xfs-outgoing; Thu, 10 Jan 2002 15:39:24 -0800 Received: from pneumatic-tube.sgi.com (pneumatic-tube.sgi.com [204.94.214.22]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0ANdJg30868 for ; Thu, 10 Jan 2002 15:39:19 -0800 Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id OAA01820 for ; Thu, 10 Jan 2002 14:39:57 -0800 (PST) mail_from (lord@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id QAA4054187; Thu, 10 Jan 2002 16:37:59 -0600 (CST) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id QAA90128; Thu, 10 Jan 2002 16:37:59 -0600 (CST) Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id g0AMamG11917; Thu, 10 Jan 2002 16:36:48 -0600 Subject: Re: Oops with 2.4.16 From: Steve Lord To: Pascal Haakmat Cc: Eric Sandeen , linux-xfs@oss.sgi.com In-Reply-To: <20020110225711.A1259@awacs.dhs.org> References: <20020110221155.A912@awacs.dhs.org> <1010697908.2812.22.camel@stout.americas.sgi.com> <20020110225711.A1259@awacs.dhs.org> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/1.0.0.99+cvs.2001.12.18.08.57 (Preview Release) Date: 10 Jan 2002 16:36:48 -0600 Message-Id: <1010702208.1772.98.camel@jen.americas.sgi.com> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 609 Lines: 25 On Thu, 2002-01-10 at 15:57, Pascal Haakmat wrote: > > ASSERT(ipointer_in == B_FALSE); > ip = ip->i_mnext; > c01ccb34: 8b 4c 24 70 mov 0x70(%esp,1),%ecx > c01ccb38: 8b 76 08 mov 0x8(%esi),%esi > c01ccb3b: 8b 91 14 01 00 00 mov 0x114(%ecx),%edx > > } while (ip->i_mnext != mp->m_inodes); > > [*ksymoops disassembly matches here*] > ip->i_mnext is NULL which is never supposed to happen, next question is why? Steve -- Steve Lord voice: +1-651-683-3511 Principal Engineer, Filesystem Software email: lord@sgi.com From owner-linux-xfs@oss.sgi.com Thu Jan 10 15:54:50 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0ANsoU31477 for linux-xfs-outgoing; Thu, 10 Jan 2002 15:54:50 -0800 Received: from Cantor.suse.de (ns.suse.de [213.95.15.193]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0ANsjg31453 for ; Thu, 10 Jan 2002 15:54:46 -0800 Received: from Hermes.suse.de (Hermes.suse.de [213.95.15.136]) by Cantor.suse.de (Postfix) with ESMTP id 7B4C11EB82; Thu, 10 Jan 2002 23:54:38 +0100 (MET) Date: Thu, 10 Jan 2002 23:54:38 +0100 From: Andi Kleen To: Steve Lord Cc: Pascal Haakmat , linux-xfs@oss.sgi.com Subject: Re: Oops with 2.4.16 Message-ID: <20020110235438.A8327@wotan.suse.de> References: <20020110221155.A912@awacs.dhs.org> <1010698155.1829.24.camel@jen.americas.sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1010698155.1829.24.camel@jen.americas.sgi.com> User-Agent: Mutt/1.3.22.1i Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 950 Lines: 26 On Thu, Jan 10, 2002 at 03:29:14PM -0600, Steve Lord wrote: > Could you do this please: > > cd linux > rm fs/xfs/xfs_vfsops.o > make CFLAGS_xfs_vfsops.o=-g vmlinux > s=$(sed -ne '/xfs_syncsub/s/ .*//p' System.map | tr '[a-z]' '[A-Z]') > e=$(echo -e "obase=16\nibase=16\n$s+3112" | bc) > objdump -S --start-address=0x$s --stop-address=0x$e vmlinux > > And send me the output, if I got that right it will generate a mixed > source and disassembly listing of the function. In theory "make fs/xfs/xfs_vfsops.lst" should also work. It works for most of kernel, unfortunately not for XFS because it does too many special things with EXTRA_CFLAGS in its Makefile. make EXTRA_CFLAGS="-I`pwd`/fs/xfs -I`pwd`/fs -funsigned-char" fs/xfs/xfs_vnodeops.lst seems to work for XFS also. You usually have to do chmod a+x scripts/makelst first because the Makefiles don't do that. It also does only work properly for compiled in objects, not modules. -Andi From owner-linux-xfs@oss.sgi.com Thu Jan 10 15:58:56 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0ANwuT31841 for linux-xfs-outgoing; Thu, 10 Jan 2002 15:58:56 -0800 Received: from hoju-ext.nks.net (hoju-ext.nks.net [216.139.204.180]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0ANwng31816 for ; Thu, 10 Jan 2002 15:58:50 -0800 Received: from two.nks.net (two.nks.net [192.168.1.22]) by hoju-ext.nks.net (8.9.3/8.9.3/Debian 8.9.3-21) with ESMTP id RAA26400 for ; Thu, 10 Jan 2002 17:58:40 -0500 Subject: Re: Disc Cloning, partitioning. From: Derek Glidden To: linux-xfs@oss.sgi.com In-Reply-To: <20020110152358.A15395@bistro.marx> References: <20020110152358.A15395@bistro.marx> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/1.0 (Preview Release) Date: 10 Jan 2002 17:58:40 -0500 Message-Id: <1010703521.982.4.camel@two> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 1665 Lines: 38 On Thu, 2002-01-10 at 16:23, pac@fortuitous.com wrote: > > Is there a tool that I can use to grab the partition table from > One disc and flash it on a Second disk? I didnt see anything like > that from gpart or partimage. > > I basically want to be able to automatically clone an entire disk, > with all of the data, but not by using 'dd' or ghost. Hopefully > something that is smart enough to forget all the empty zeros. sfdisk and rsync or dump/xfsdump. You could probably script it by looking at /etc/fstab or /proc/partitions or something, although disks with different geometries will catch you. If they're IDE, you run into situations where a lot of systems, even with identical disks, can ID the geometry differently depending on what controller they're plugged into and how the BIOS settings are configured. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- #!/usr/bin/perl -w $_='while(read+STDIN,$_,2048){$a=29;$b=73;$c=142;$t=255;@t=map {$_%16or$t^=$c^=($m=(11,10,116,100,11,122,20,100)[$_/16%8])&110; $t^=(72,@z=(64,72,$a^=12*($_%16-2?0:$m&17)),$b^=$_%64?12:0,@z) [$_%8]}(16..271);if((@a=unx"C*",$_)[20]&48){$h=5;$_=unxb24,join "",@b=map{xB8,unxb8,chr($_^$a[--$h+84])}@ARGV;s/...$/1$&/;$d= unxV,xb25,$_;$e=256|(ord$b[4])<<9|ord$b[3];$d=$d>>8^($f=$t&($d >>12^$d>>4^$d^$d/8))<<17,$e=$e>>8^($t&($g=($q=$e>>14&7^$e)^$q* 8^$q<<6))<<9,$_=$t[$_]^(($h>>=8)+=$f+(~$g&$t))for@a[128..$#a]} print+x"C*",@a}';s/x/pack+/g;eval usage: qrpff 153 2 8 105 225 < /mnt/dvd/VOB_FILENAME \ | extract_mpeg2 | mpeg2dec - http://www.cs.cmu.edu/~dst/DeCSS/Gallery/ http://www.eff.org/ http://www.anti-dmca.org/ From owner-linux-xfs@oss.sgi.com Thu Jan 10 16:07:08 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0B078P32438 for linux-xfs-outgoing; Thu, 10 Jan 2002 16:07:08 -0800 Received: from UberGeek.coremetrics.com ([209.184.141.163]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0B06vg32410 for ; Thu, 10 Jan 2002 16:06:57 -0800 Received: (from austin@localhost) by UberGeek.coremetrics.com (8.11.6/8.11.6) id g0AN6I813237; Thu, 10 Jan 2002 17:06:18 -0600 X-Authentication-Warning: UberGeek.coremetrics.com: austin set sender to austin@coremetrics.com using -f Subject: Re: Disc Cloning, partitioning. From: Austin Gonyou To: Derek Glidden Cc: linux-xfs@oss.sgi.com In-Reply-To: <1010703521.982.4.camel@two> References: <1010703521.982.4.camel@two> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-WXxFCWFapBaJK6Y9RxCh" X-Mailer: Evolution/1.0.0.99+cvs.2001.12.18.08.57 (Preview Release) Date: 10 Jan 2002 17:06:18 -0600 Message-Id: <1010703978.13205.3.camel@UberGeek> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 2805 Lines: 72 --=-WXxFCWFapBaJK6Y9RxCh Content-Type: text/plain Content-Transfer-Encoding: quoted-printable System Imager or System Congifurator may eventually support this. I've made patches for SI to enable XFS support. I use it often. Please see freshmeat for the link. On Thu, 2002-01-10 at 16:58, Derek Glidden wrote: > On Thu, 2002-01-10 at 16:23, pac@fortuitous.com wrote: > >=20=20 > > Is there a tool that I can use to grab the partition table from > > One disc and flash it on a Second disk? I didnt see anything like=20 > > that from gpart or partimage.=20 > >=20 > > I basically want to be able to automatically clone an entire disk,=20 > > with all of the data, but not by using 'dd' or ghost. Hopefully=20 > > something that is smart enough to forget all the empty zeros. >=20 > sfdisk and rsync or dump/xfsdump. >=20 > You could probably script it by looking at /etc/fstab or > /proc/partitions or something, although disks with different geometries > will catch you. If they're IDE, you run into situations where a lot of > systems, even with identical disks, can ID the geometry differently > depending on what controller they're plugged into and how the BIOS > settings are configured. >=20 > --=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- > #!/usr/bin/perl -w > $_=3D'while(read+STDIN,$_,2048){$a=3D29;$b=3D73;$c=3D142;$t=3D255;@t=3Dmap > {$_%16or$t^=3D$c^=3D($m=3D(11,10,116,100,11,122,20,100)[$_/16%8])&110; > $t^=3D(72,@z=3D(64,72,$a^=3D12*($_%16-2?0:$m&17)),$b^=3D$_%64?12:0,@z) > [$_%8]}(16..271);if((@a=3Dunx"C*",$_)[20]&48){$h=3D5;$_=3Dunxb24,join > "",@b=3Dmap{xB8,unxb8,chr($_^$a[--$h+84])}@ARGV;s/...$/1$&/;$d=3D > unxV,xb25,$_;$e=3D256|(ord$b[4])<<9|ord$b[3];$d=3D$d>>8^($f=3D$t&($d > >>12^$d>>4^$d^$d/8))<<17,$e=3D$e>>8^($t&($g=3D($q=3D$e>>14&7^$e)^$q* > 8^$q<<6))<<9,$_=3D$t[$_]^(($h>>=3D8)+=3D$f+(~$g&$t))for@a[128..$#a]} > print+x"C*",@a}';s/x/pack+/g;eval=20 >=20 > usage: qrpff 153 2 8 105 225 < /mnt/dvd/VOB_FILENAME \ > | extract_mpeg2 | mpeg2dec -=20 >=20 > http://www.cs.cmu.edu/~dst/DeCSS/Gallery/ > http://www.eff.org/ http://www.anti-dmca.org/ --=20 Austin Gonyou Systems Architect, CCNA Coremetrics, Inc. Phone: 512-698-7250 email: austin@coremetrics.com "It is the part of a good shepherd to shear his flock, not to skin it." Latin Proverb --=-WXxFCWFapBaJK6Y9RxCh Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQA8Ph5q94g6ZVmFMoIRAuJ4AKDCma1FWw0tyPsFyHqTnZyh2bclOwCfZLzF /Vs9o8bfupLfrx7y8OXlYeI= =CyRY -----END PGP SIGNATURE----- --=-WXxFCWFapBaJK6Y9RxCh-- From owner-linux-xfs@oss.sgi.com Thu Jan 10 16:36:38 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0B0acf00691 for linux-xfs-outgoing; Thu, 10 Jan 2002 16:36:38 -0800 Received: from UberGeek.coremetrics.com ([209.184.141.163]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0B0aWg00666 for ; Thu, 10 Jan 2002 16:36:32 -0800 Received: (from austin@localhost) by UberGeek.coremetrics.com (8.11.6/8.11.6) id g0ANZpd13561; Thu, 10 Jan 2002 17:35:51 -0600 X-Authentication-Warning: UberGeek.coremetrics.com: austin set sender to austin@coremetrics.com using -f Subject: [OT] FAKE, HA Tools, LVM, and Oracle. From: Austin Gonyou To: linux-xfs@oss.sgi.com Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-SRK2wPikPZGHH11uI0wA" X-Mailer: Evolution/1.0.0.99+cvs.2001.12.18.08.57 (Preview Release) Date: 10 Jan 2002 17:35:51 -0600 Message-Id: <1010705751.13538.7.camel@UberGeek> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 945 Lines: 34 --=-SRK2wPikPZGHH11uI0wA Content-Type: text/plain Content-Transfer-Encoding: quoted-printable I'm looking for a way to do active/passive failover with Oracle on XFS + LVM. I think FAKE and HA tools would be the best bet, does anyone have any other suggestions? I'd sure appreciate them. BTW, connecting by fibre to EMC 3630.=20 Thanks. --=20 Austin Gonyou Systems Architect, CCNA Coremetrics, Inc. Phone: 512-698-7250 email: austin@coremetrics.com "It is the part of a good shepherd to shear his flock, not to skin it." Latin Proverb --=-SRK2wPikPZGHH11uI0wA Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQA8PiVX94g6ZVmFMoIRAkkLAJ9RM3zFoDdLsJtFajmxIlj41aQVHACg1mmI DeYdL4vBoy7q48KATRUERZI= =Vc0H -----END PGP SIGNATURE----- --=-SRK2wPikPZGHH11uI0wA-- From owner-linux-xfs@oss.sgi.com Thu Jan 10 16:40:34 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0B0eYb01072 for linux-xfs-outgoing; Thu, 10 Jan 2002 16:40:34 -0800 Received: from hoju-ext.nks.net (hoju-ext.nks.net [216.139.204.180]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0B0eNg00967 for ; Thu, 10 Jan 2002 16:40:23 -0800 Received: from two.nks.net (two.nks.net [192.168.1.22]) by hoju-ext.nks.net (8.9.3/8.9.3/Debian 8.9.3-21) with ESMTP id SAA26724 for ; Thu, 10 Jan 2002 18:40:15 -0500 Subject: Re: Disc Cloning, partitioning. From: Derek Glidden To: linux-xfs@oss.sgi.com In-Reply-To: <1010703978.13205.3.camel@UberGeek> References: <1010703521.982.4.camel@two> <1010703978.13205.3.camel@UberGeek> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/1.0 (Preview Release) Date: 10 Jan 2002 18:40:14 -0500 Message-Id: <1010706014.982.14.camel@two> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 3467 Lines: 79 We use systemimager here all day long. It's bloody wonderful! I'm happy to hear you're getting XFS support in - I can stop mucking about with getting it to work now. :) I was assuming though that he wanted to "image" a live system directly to a backup disk, which I didn't think either of those tools would handle directly. On Thu, 2002-01-10 at 18:06, Austin Gonyou wrote: > System Imager or System Congifurator may eventually support this. I've > made patches for SI to enable XFS support. I use it often. Please see > freshmeat for the link. > > On Thu, 2002-01-10 at 16:58, Derek Glidden wrote: > > On Thu, 2002-01-10 at 16:23, pac@fortuitous.com wrote: > > > > > > Is there a tool that I can use to grab the partition table from > > > One disc and flash it on a Second disk? I didnt see anything like > > > that from gpart or partimage. > > > > > > I basically want to be able to automatically clone an entire disk, > > > with all of the data, but not by using 'dd' or ghost. Hopefully > > > something that is smart enough to forget all the empty zeros. > > > > sfdisk and rsync or dump/xfsdump. > > > > You could probably script it by looking at /etc/fstab or > > /proc/partitions or something, although disks with different geometries > > will catch you. If they're IDE, you run into situations where a lot of > > systems, even with identical disks, can ID the geometry differently > > depending on what controller they're plugged into and how the BIOS > > settings are configured. > > > > -- > > -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- > > #!/usr/bin/perl -w > > $_='while(read+STDIN,$_,2048){$a=29;$b=73;$c=142;$t=255;@t=map > > {$_%16or$t^=$c^=($m=(11,10,116,100,11,122,20,100)[$_/16%8])&110; > > $t^=(72,@z=(64,72,$a^=12*($_%16-2?0:$m&17)),$b^=$_%64?12:0,@z) > > [$_%8]}(16..271);if((@a=unx"C*",$_)[20]&48){$h=5;$_=unxb24,join > > "",@b=map{xB8,unxb8,chr($_^$a[--$h+84])}@ARGV;s/...$/1$&/;$d= > > unxV,xb25,$_;$e=256|(ord$b[4])<<9|ord$b[3];$d=$d>>8^($f=$t&($d > > >>12^$d>>4^$d^$d/8))<<17,$e=$e>>8^($t&($g=($q=$e>>14&7^$e)^$q* > > 8^$q<<6))<<9,$_=$t[$_]^(($h>>=8)+=$f+(~$g&$t))for@a[128..$#a]} > > print+x"C*",@a}';s/x/pack+/g;eval > > > > usage: qrpff 153 2 8 105 225 < /mnt/dvd/VOB_FILENAME \ > > | extract_mpeg2 | mpeg2dec - > > > > http://www.cs.cmu.edu/~dst/DeCSS/Gallery/ > > http://www.eff.org/ http://www.anti-dmca.org/ > -- > Austin Gonyou > Systems Architect, CCNA > Coremetrics, Inc. > Phone: 512-698-7250 > email: austin@coremetrics.com > > "It is the part of a good shepherd to shear his flock, not to skin it." > Latin Proverb -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- #!/usr/bin/perl -w $_='while(read+STDIN,$_,2048){$a=29;$b=73;$c=142;$t=255;@t=map {$_%16or$t^=$c^=($m=(11,10,116,100,11,122,20,100)[$_/16%8])&110; $t^=(72,@z=(64,72,$a^=12*($_%16-2?0:$m&17)),$b^=$_%64?12:0,@z) [$_%8]}(16..271);if((@a=unx"C*",$_)[20]&48){$h=5;$_=unxb24,join "",@b=map{xB8,unxb8,chr($_^$a[--$h+84])}@ARGV;s/...$/1$&/;$d= unxV,xb25,$_;$e=256|(ord$b[4])<<9|ord$b[3];$d=$d>>8^($f=$t&($d >>12^$d>>4^$d^$d/8))<<17,$e=$e>>8^($t&($g=($q=$e>>14&7^$e)^$q* 8^$q<<6))<<9,$_=$t[$_]^(($h>>=8)+=$f+(~$g&$t))for@a[128..$#a]} print+x"C*",@a}';s/x/pack+/g;eval usage: qrpff 153 2 8 105 225 < /mnt/dvd/VOB_FILENAME \ | extract_mpeg2 | mpeg2dec - http://www.cs.cmu.edu/~dst/DeCSS/Gallery/ http://www.eff.org/ http://www.anti-dmca.org/ From owner-linux-xfs@oss.sgi.com Thu Jan 10 16:52:04 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0B0q4d03212 for linux-xfs-outgoing; Thu, 10 Jan 2002 16:52:04 -0800 Received: from UberGeek.coremetrics.com ([209.184.141.163]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0B0plg03188 for ; Thu, 10 Jan 2002 16:51:47 -0800 Received: (from austin@localhost) by UberGeek.coremetrics.com (8.11.6/8.11.6) id g0ANp8E13593; Thu, 10 Jan 2002 17:51:08 -0600 X-Authentication-Warning: UberGeek.coremetrics.com: austin set sender to austin@coremetrics.com using -f Subject: Re: Disc Cloning, partitioning. From: Austin Gonyou To: linux-xfs@oss.sgi.com In-Reply-To: <1010706014.982.14.camel@two> References: <1010706014.982.14.camel@two> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-WoWJDSpxQmkDacVhWbIr" X-Mailer: Evolution/1.0.0.99+cvs.2001.12.18.08.57 (Preview Release) Date: 10 Jan 2002 17:51:08 -0600 Message-Id: <1010706668.13538.16.camel@UberGeek> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 4798 Lines: 119 --=-WoWJDSpxQmkDacVhWbIr Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Ahh..yes..I don't see why you couldn't just do it with SI, as long as the fs you wanted to muck with weren't mounted. :)=20 On Thu, 2002-01-10 at 17:40, Derek Glidden wrote: > We use systemimager here all day long. It's bloody wonderful! I'm > happy to hear you're getting XFS support in - I can stop mucking about > with getting it to work now. :) >=20 > I was assuming though that he wanted to "image" a live system directly > to a backup disk, which I didn't think either of those tools would > handle directly. >=20 > On Thu, 2002-01-10 at 18:06, Austin Gonyou wrote: > > System Imager or System Congifurator may eventually support this. I've > > made patches for SI to enable XFS support. I use it often. Please see > > freshmeat for the link. > >=20 > > On Thu, 2002-01-10 at 16:58, Derek Glidden wrote: > > > On Thu, 2002-01-10 at 16:23, pac@fortuitous.com wrote: > > > >=20=20 > > > > Is there a tool that I can use to grab the partition table from > > > > One disc and flash it on a Second disk? I didnt see anything like= =20 > > > > that from gpart or partimage.=20 > > > >=20 > > > > I basically want to be able to automatically clone an entire > disk,=20 > > > > with all of the data, but not by using 'dd' or ghost. Hopefully=20 > > > > something that is smart enough to forget all the empty zeros. > > >=20 > > > sfdisk and rsync or dump/xfsdump. > > >=20 > > > You could probably script it by looking at /etc/fstab or > > > /proc/partitions or something, although disks with different > geometries > > > will catch you. If they're IDE, you run into situations where a lot > of > > > systems, even with identical disks, can ID the geometry differently > > > depending on what controller they're plugged into and how the BIOS > > > settings are configured. > > >=20 > > > --=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- > > > #!/usr/bin/perl -w > > > $_=3D'while(read+STDIN,$_,2048){$a=3D29;$b=3D73;$c=3D142;$t=3D255;@t= =3Dmap > > > {$_%16or$t^=3D$c^=3D($m=3D(11,10,116,100,11,122,20,100)[$_/16%8])&110; > > > $t^=3D(72,@z=3D(64,72,$a^=3D12*($_%16-2?0:$m&17)),$b^=3D$_%64?12:0,@z) > > > [$_%8]}(16..271);if((@a=3Dunx"C*",$_)[20]&48){$h=3D5;$_=3Dunxb24,join > > > "",@b=3Dmap{xB8,unxb8,chr($_^$a[--$h+84])}@ARGV;s/...$/1$&/;$d=3D > > > unxV,xb25,$_;$e=3D256|(ord$b[4])<<9|ord$b[3];$d=3D$d>>8^($f=3D$t&($d > > > >>12^$d>>4^$d^$d/8))<<17,$e=3D$e>>8^($t&($g=3D($q=3D$e>>14&7^$e)^$q* > > > 8^$q<<6))<<9,$_=3D$t[$_]^(($h>>=3D8)+=3D$f+(~$g&$t))for@a[128..$#a]} > > > print+x"C*",@a}';s/x/pack+/g;eval=20 > > >=20 > > > usage: qrpff 153 2 8 105 225 < /mnt/dvd/VOB_FILENAME \ > > > | extract_mpeg2 | mpeg2dec -=20 > > >=20 > > > http://www.cs.cmu.edu/~dst/DeCSS/Gallery/ > > > http://www.eff.org/ http://www.anti-dmca.org/ > > --=20 > > Austin Gonyou > > Systems Architect, CCNA > > Coremetrics, Inc. > > Phone: 512-698-7250 > > email: austin@coremetrics.com > >=20 > > "It is the part of a good shepherd to shear his flock, not to skin > it." > > Latin Proverb > --=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- > #!/usr/bin/perl -w > $_=3D'while(read+STDIN,$_,2048){$a=3D29;$b=3D73;$c=3D142;$t=3D255;@t=3Dmap > {$_%16or$t^=3D$c^=3D($m=3D(11,10,116,100,11,122,20,100)[$_/16%8])&110; > $t^=3D(72,@z=3D(64,72,$a^=3D12*($_%16-2?0:$m&17)),$b^=3D$_%64?12:0,@z) > [$_%8]}(16..271);if((@a=3Dunx"C*",$_)[20]&48){$h=3D5;$_=3Dunxb24,join > "",@b=3Dmap{xB8,unxb8,chr($_^$a[--$h+84])}@ARGV;s/...$/1$&/;$d=3D > unxV,xb25,$_;$e=3D256|(ord$b[4])<<9|ord$b[3];$d=3D$d>>8^($f=3D$t&($d > >>12^$d>>4^$d^$d/8))<<17,$e=3D$e>>8^($t&($g=3D($q=3D$e>>14&7^$e)^$q* > 8^$q<<6))<<9,$_=3D$t[$_]^(($h>>=3D8)+=3D$f+(~$g&$t))for@a[128..$#a]} > print+x"C*",@a}';s/x/pack+/g;eval=20 >=20 > usage: qrpff 153 2 8 105 225 < /mnt/dvd/VOB_FILENAME \ > | extract_mpeg2 | mpeg2dec -=20 >=20 > http://www.cs.cmu.edu/~dst/DeCSS/Gallery/ > http://www.eff.org/ http://www.anti-dmca.org/ --=20 Austin Gonyou Systems Architect, CCNA Coremetrics, Inc. Phone: 512-698-7250 email: austin@coremetrics.com "It is the part of a good shepherd to shear his flock, not to skin it." Latin Proverb --=-WoWJDSpxQmkDacVhWbIr Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQA8Pijs94g6ZVmFMoIRAjH9AKCMU/d88KMlCo7h3w7PfnzpeEGyBwCeIOCV VKgH50EIGoedlP9se/8nmCI= =1kJh -----END PGP SIGNATURE----- --=-WoWJDSpxQmkDacVhWbIr-- From owner-linux-xfs@oss.sgi.com Thu Jan 10 17:24:03 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0B1O3D03957 for linux-xfs-outgoing; Thu, 10 Jan 2002 17:24:03 -0800 Received: from yog-sothoth.sgi.com (eugate.sgi.com [192.48.160.10]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0B1O0g03932 for ; Thu, 10 Jan 2002 17:24:00 -0800 Received: from nodin.corp.sgi.com (fddi-nodin.corp.sgi.com [198.29.75.193]) by yog-sothoth.sgi.com (980305.SGI.8.8.8-aspam-6.2/980304.SGI-aspam-europe) via ESMTP id BAA1632429 for ; Fri, 11 Jan 2002 01:21:20 +0100 (CET) mail_from (kaos@sgi.com) Received: from kao2.melbourne.sgi.com (kao2.melbourne.sgi.com [134.14.55.180]) by nodin.corp.sgi.com (8.11.4/8.11.2/nodin-1.0) with ESMTP id g0B0Ms422483245 for ; Thu, 10 Jan 2002 16:22:55 -0800 (PST) Received: by kao2.melbourne.sgi.com (Postfix, from userid 16331) id 0D9DB300095; Fri, 11 Jan 2002 11:22:51 +1100 (EST) Received: from kao2.melbourne.sgi.com (localhost [127.0.0.1]) by kao2.melbourne.sgi.com (Postfix) with ESMTP id A947794 for ; Fri, 11 Jan 2002 11:22:51 +1100 (EST) X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 From: Keith Owens To: linux-xfs@oss.sgi.com Subject: Re: TAKE - Workaround for gcc 2.96 bug In-reply-to: Your message of "Thu, 10 Jan 2002 19:28:17 +1100." <200201100828.g0A8SHU24920@sherman.melbourne.sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 11 Jan 2002 11:22:46 +1100 Message-ID: <1045.1010708566@kao2.melbourne.sgi.com> Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 371 Lines: 11 On Thu, 10 Jan 2002 19:28:17 +1100, Keith Owens wrote: >gcc -v >Reading specs from /usr/lib/gcc-lib/i386-redhat-linux/2.96/specs >gcc version 2.96 20000731 (Red Hat Linux 7.1 2.96-98) > >breaks on complex expressions involving long long. Swapping two lines >in xfs_bmap.c works around the broken gcc. Logged with Redhat as bug 58204. From owner-linux-xfs@oss.sgi.com Thu Jan 10 17:42:34 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0B1gYh04316 for linux-xfs-outgoing; Thu, 10 Jan 2002 17:42:34 -0800 Received: from zok.sgi.com (zok.sgi.com [204.94.215.101]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0B1gWg04294 for ; Thu, 10 Jan 2002 17:42:32 -0800 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.55.149]) by zok.sgi.com (8.11.4/8.11.4/linux-outbound_gateway-1.1) with ESMTP id g0B0gOo16292 for ; Thu, 10 Jan 2002 16:42:24 -0800 Received: (from nathans@localhost) by snort.melbourne.sgi.com (SGI-8.9.3/8.9.3) id LAA13831 for linux-xfs@oss.sgi.com; Fri, 11 Jan 2002 11:41:06 +1100 (EST) Date: Fri, 11 Jan 2002 11:41:06 +1100 (EST) From: Nathan Scott Message-Id: <200201110041.LAA13831@snort.melbourne.sgi.com> To: linux-xfs@oss.sgi.com Subject: TAKE - libattr Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 404 Lines: 16 Date: Thu Jan 10 16:37:54 PST 2002 Workarea: snort.melbourne.sgi.com:/home/nathans/xfs-cmds The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/xfs-cmds Modid: xfs-cmds:slinx:109420a attr/VERSION - 1.10 attr/doc/CHANGES - 1.11 attr/debian/changelog - 1.10 - bump to 1.1.4, document change. attr/libattr/attr.c - 1.9 - bug fix in attr_multi(3), use of "count" was broken. From owner-linux-xfs@oss.sgi.com Thu Jan 10 18:39:07 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0B2d7o05303 for linux-xfs-outgoing; Thu, 10 Jan 2002 18:39:07 -0800 Received: from awacs.dhs.org (node10450.a2000.nl [24.132.4.80]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0B2d2g05281 for ; Thu, 10 Jan 2002 18:39:02 -0800 Received: (from p@localhost) by awacs.dhs.org (8.11.0/8.9.3) id g0B1cxe02416 for linux-xfs@oss.sgi.com; Fri, 11 Jan 2002 02:38:59 +0100 Date: Fri, 11 Jan 2002 02:38:59 +0100 From: Pascal Haakmat To: linux-xfs@oss.sgi.com Subject: Re: Oops with 2.4.16 Message-ID: <20020111023859.A2413@awacs.dhs.org> References: <20020110221155.A912@awacs.dhs.org> <1010697908.2812.22.camel@stout.americas.sgi.com> <20020110225711.A1259@awacs.dhs.org> <1010702208.1772.98.camel@jen.americas.sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 716 Lines: 24 10/01/02 16:36, Steve Lord wrote: > On Thu, 2002-01-10 at 15:57, Pascal Haakmat wrote: > > > > > ASSERT(ipointer_in == B_FALSE); > > ip = ip->i_mnext; > > c01ccb34: 8b 4c 24 70 mov 0x70(%esp,1),%ecx > > c01ccb38: 8b 76 08 mov 0x8(%esi),%esi > > c01ccb3b: 8b 91 14 01 00 00 mov 0x114(%ecx),%edx > > > > } while (ip->i_mnext != mp->m_inodes); > > > > [*ksymoops disassembly matches here*] > > > > > ip->i_mnext is NULL which is never supposed to happen, next question is > why? FWIW, this happened just after rebooting using the XFS 1.01/RedHat boot CD and running xfs_repair on the filesystem, which hopefully rules out an inconsistent filesystem/filesystem errors. From owner-linux-xfs@oss.sgi.com Thu Jan 10 18:43:27 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0B2hRo05477 for linux-xfs-outgoing; Thu, 10 Jan 2002 18:43:27 -0800 Received: from sunny.pacific.net.au (sunny-legacy.pacific.net.au [210.23.129.40]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0B2hHg05454 for ; Thu, 10 Jan 2002 18:43:18 -0800 Received: from wisma.pacific.net.au (wisma.pacific.net.au [210.23.129.72]) by sunny.pacific.net.au with ESMTP id g0B1hDZM014579 for ; Fri, 11 Jan 2002 12:43:13 +1100 (EST) Received: from jpc.local (ppp113.dyn225.pacific.net.au [203.100.225.113]) by wisma.pacific.net.au with ESMTP id MAA21072 for ; Fri, 11 Jan 2002 12:43:12 +1100 (EST) Received: (from jason@localhost) by jpc.local (8.9.3/8.9.3/Debian 8.9.3-21) id MAA00699; Fri, 11 Jan 2002 12:43:10 +1100 From: Jason White MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15422.17196.469756.949891@jpc.local> Date: Fri, 11 Jan 2002 12:43:08 +1100 To: linux-xfs@oss.sgi.com Subject: Re: Partition un(mount|repairable) In-Reply-To: <3C3C45F2.D6533E44@cs.tum.edu> References: <3C3C45F2.D6533E44@cs.tum.edu> X-Mailer: VM 6.76 under Emacs 20.7.2 Reply-To: Jason White Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 1089 Lines: 27 Deti Fliegl writes: > Hi > > some days ago one of our systems crashed due to a defective CPU cooler. > The XFS filesystem on it now is unmountable and unrepairable: > > .... > imap claims in-use inode 686650 is free, correcting imap > imap claims in-use inode 686651 is free, correcting imap > imap claims in-use inode 686652 is free, correcting imap > imap claims in-use inode 686653 is free, correcting imap > imap claims in-use inode 686654 is free, correcting imap > imap claims in-use inode 686655 is free, correcting imap > avl_insert: Warning! duplicate range [0xbee40,0xbee80) > > fatal error -- xfs_repair: duplicate inode range Any suggestions as to how the damage was done in the first place - what the bug is? There have been worrying reports of data corruption over the last few weeks, and I am sure the developers are trying to track them down. My own system hasn't been used much recently as I have been away on holiday, but I booted it this morning and everything seemed fine (running Linux 2.4.17-xfs as downloaded from CVS at the end of last year). From owner-linux-xfs@oss.sgi.com Thu Jan 10 19:54:57 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0B3svd06889 for linux-xfs-outgoing; Thu, 10 Jan 2002 19:54:57 -0800 Received: from deliverator.sgi.com (deliverator.sgi.com [204.94.214.10]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0B3stg06866 for ; Thu, 10 Jan 2002 19:54:55 -0800 Received: from sherman.melbourne.sgi.com (sherman.melbourne.sgi.com [134.14.55.232]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id SAA05518 for ; Thu, 10 Jan 2002 18:54:38 -0800 (PST) mail_from (kaos@sherman.melbourne.sgi.com) Received: (from kaos@localhost) by sherman.melbourne.sgi.com (8.11.6/8.11.6) id g0B2snl09048; Fri, 11 Jan 2002 13:54:49 +1100 Date: Fri, 11 Jan 2002 13:54:49 +1100 From: Keith Owens Message-Id: <200201110254.g0B2snl09048@sherman.melbourne.sgi.com> Subject: TAKE - Allow core XFS to build without ACL code Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 386 Lines: 13 The core XFS code must compile even without the acl-extattr patch. If that means some extra #ifdef CONFIG_FS_POSIX_ACL, so be it. Date: Thu Jan 10 18:49:24 PST 2002 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:109422a linux/fs/xfs/linux/xfs_iops.c - 1.118 From owner-linux-xfs@oss.sgi.com Thu Jan 10 20:07:10 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0B47AM07285 for linux-xfs-outgoing; Thu, 10 Jan 2002 20:07:10 -0800 Received: from zok.sgi.com (zok.sgi.com [204.94.215.101]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0B474g07263 for ; Thu, 10 Jan 2002 20:07:04 -0800 Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by zok.sgi.com (8.11.4/8.11.4/linux-outbound_gateway-1.1) with ESMTP id g0B36vo25831 for ; Thu, 10 Jan 2002 19:06:57 -0800 Received: from tulip-e185.americas.sgi.com (tulip-e185.americas.sgi.com [128.162.185.208]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id VAA4065976; Thu, 10 Jan 2002 21:05:41 -0600 (CST) Received: from sgi.com (9gIK9Rw04kdVlSMKZqfZi+Wg30ZG7e1t@lord-h1.americas.sgi.com [206.11.101.42]) by tulip-e185.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.7) with ESMTP id VAA63332; Thu, 10 Jan 2002 21:05:40 -0600 (CST) Message-ID: <3C3E578B.7090309@sgi.com> Date: Thu, 10 Jan 2002 21:10:03 -0600 From: Stephen Lord User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.6) Gecko/20011120 X-Accept-Language: en-us MIME-Version: 1.0 To: Pascal Haakmat CC: linux-xfs@oss.sgi.com Subject: Re: Oops with 2.4.16 References: <20020110221155.A912@awacs.dhs.org> <1010697908.2812.22.camel@stout.americas.sgi.com> <20020110225711.A1259@awacs.dhs.org> <1010702208.1772.98.camel@jen.americas.sgi.com> <20020111023859.A2413@awacs.dhs.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 1288 Lines: 43 Pascal Haakmat wrote: >10/01/02 16:36, Steve Lord wrote: > >>On Thu, 2002-01-10 at 15:57, Pascal Haakmat wrote: >> >>> ASSERT(ipointer_in == B_FALSE); >>> ip = ip->i_mnext; >>>c01ccb34: 8b 4c 24 70 mov 0x70(%esp,1),%ecx >>>c01ccb38: 8b 76 08 mov 0x8(%esi),%esi >>>c01ccb3b: 8b 91 14 01 00 00 mov 0x114(%ecx),%edx >>> >>> } while (ip->i_mnext != mp->m_inodes); >>> >>>[*ksymoops disassembly matches here*] >>> >> >>ip->i_mnext is NULL which is never supposed to happen, next question is >>why? >> > >FWIW, this happened just after rebooting using the XFS 1.01/RedHat boot CD >and running xfs_repair on the filesystem, which hopefully rules out an >inconsistent filesystem/filesystem errors. > I don't think fs corruption would have much to do with this one, it is a purely in memory circular list. So far as I can see it is always manipulated under the correct locking. I have a box running a debug kernel sitting in a loop doing the test which Adrian says makes this happen for him. It has been going for a few hours, so far no problems. Would you be willing turn on kdb? It only really makes sense if you are able to setup a serial console. There is a debugger command which will walk the complete list of inodes in the filesystem. Steve From owner-linux-xfs@oss.sgi.com Thu Jan 10 20:23:10 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0B4NAb07644 for linux-xfs-outgoing; Thu, 10 Jan 2002 20:23:10 -0800 Received: from sgi.com (sgi-too.SGI.COM [204.94.211.39]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0B4N2g07622 for ; Thu, 10 Jan 2002 20:23:03 -0800 Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id TAA03863 for ; Thu, 10 Jan 2002 19:20:21 -0800 (PST) mail_from (lord@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id VAA4061816 for ; Thu, 10 Jan 2002 21:21:33 -0600 (CST) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id VAA77281 for ; Thu, 10 Jan 2002 21:21:33 -0600 (CST) From: Steve Lord Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id g0B3KLP13739; Thu, 10 Jan 2002 21:20:21 -0600 Message-Id: <200201110320.g0B3KLP13739@jen.americas.sgi.com> Date: Thu, 10 Jan 2002 21:20:21 -0600 Subject: TAKE - change some pagebuf debug code Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 489 Lines: 16 Last time I used the lock tracking code in pagebuf it was much better to track it based on pid rather than task address. Date: Thu Jan 10 19:18:03 PST 2002 Workarea: jen.americas.sgi.com:/src/lord/xfs-linux.2.4 The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:109423a linux/include/linux/page_buf.h - 1.103 linux/kdb/modules/kdbm_pg.c - 1.46 - Change pagebuf lock tracking to be pid based rather than task pointer based From owner-linux-xfs@oss.sgi.com Thu Jan 10 20:34:35 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0B4YZg07877 for linux-xfs-outgoing; Thu, 10 Jan 2002 20:34:35 -0800 Received: from deliverator.sgi.com (deliverator.sgi.com [204.94.214.10]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0B4YTg07854 for ; Thu, 10 Jan 2002 20:34:29 -0800 Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id TAA19497 for ; Thu, 10 Jan 2002 19:34:13 -0800 (PST) mail_from (lord@sgi.com) Received: from tulip-e185.americas.sgi.com (tulip-e185.americas.sgi.com [128.162.185.208]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id VAA4061208; Thu, 10 Jan 2002 21:33:11 -0600 (CST) Received: from sgi.com (EK+hK3xii9eOu61RlUsYrCKepvRaz3pZ@lord-h1.americas.sgi.com [206.11.101.42]) by tulip-e185.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.7) with ESMTP id VAA64741; Thu, 10 Jan 2002 21:33:10 -0600 (CST) Message-ID: <3C3E5DFD.1060902@sgi.com> Date: Thu, 10 Jan 2002 21:37:33 -0600 From: Stephen Lord User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.6) Gecko/20011120 X-Accept-Language: en-us MIME-Version: 1.0 To: Jason White CC: linux-xfs@oss.sgi.com Subject: Re: Partition un(mount|repairable) References: <3C3C45F2.D6533E44@cs.tum.edu> <15422.17196.469756.949891@jpc.local> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 1729 Lines: 47 Jason White wrote: >Deti Fliegl writes: > > Hi > > > > some days ago one of our systems crashed due to a defective CPU cooler. > > The XFS filesystem on it now is unmountable and unrepairable: > > > > .... > > imap claims in-use inode 686650 is free, correcting imap > > imap claims in-use inode 686651 is free, correcting imap > > imap claims in-use inode 686652 is free, correcting imap > > imap claims in-use inode 686653 is free, correcting imap > > imap claims in-use inode 686654 is free, correcting imap > > imap claims in-use inode 686655 is free, correcting imap > > avl_insert: Warning! duplicate range [0xbee40,0xbee80) > > > > fatal error -- xfs_repair: duplicate inode range > >Any suggestions as to how the damage was done in the first place - >what the bug is? > Not as yet, but there have now been two cases of filesystems ending up confusing repair like this. > > >There have been worrying reports of data corruption over the last few >weeks, and I am sure the developers are trying to track them down. My >own system hasn't been used much recently as I have been away on >holiday, but I booted it this morning and everything seemed fine >(running Linux 2.4.17-xfs as downloaded from CVS at the end of last >year). > I would say it is partially as xfs gets more exposure it gets tried on more combinations of hardware and software (compilers). I am not aware of any 'data corruption' issues remaining (emacs builds should be fixed, and the fsx-linux program runs fine for me for 24 hours - I believe it was been run in a patched kernel). The directory corruption issues do concern me, and I have to admit to being baffled right now, but the vast majority of users do not see any problems at all. Steve From owner-linux-xfs@oss.sgi.com Thu Jan 10 20:36:46 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0B4akt08019 for linux-xfs-outgoing; Thu, 10 Jan 2002 20:36:46 -0800 Received: from awacs.dhs.org (node10450.a2000.nl [24.132.4.80]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0B4acg07997 for ; Thu, 10 Jan 2002 20:36:39 -0800 Received: (from p@localhost) by awacs.dhs.org (8.11.0/8.9.3) id g0B3aXU00809; Fri, 11 Jan 2002 04:36:33 +0100 Date: Fri, 11 Jan 2002 04:36:33 +0100 From: Pascal Haakmat To: Stephen Lord Cc: linux-xfs@oss.sgi.com Subject: Re: Oops with 2.4.16 Message-ID: <20020111043633.A791@awacs.dhs.org> References: <20020110221155.A912@awacs.dhs.org> <1010697908.2812.22.camel@stout.americas.sgi.com> <20020110225711.A1259@awacs.dhs.org> <1010702208.1772.98.camel@jen.americas.sgi.com> <20020111023859.A2413@awacs.dhs.org> <3C3E578B.7090309@sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <3C3E578B.7090309@sgi.com>; from lord@sgi.com on Thu, Jan 10, 2002 at 09:10:03PM -0600 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 1802 Lines: 53 10/01/02 21:10, Stephen Lord wrote: > Pascal Haakmat wrote: > > >10/01/02 16:36, Steve Lord wrote: > > > >>On Thu, 2002-01-10 at 15:57, Pascal Haakmat wrote: > >> > >>> ASSERT(ipointer_in == B_FALSE); > >>> ip = ip->i_mnext; > >>>c01ccb34: 8b 4c 24 70 mov 0x70(%esp,1),%ecx > >>>c01ccb38: 8b 76 08 mov 0x8(%esi),%esi > >>>c01ccb3b: 8b 91 14 01 00 00 mov 0x114(%ecx),%edx > >>> > >>> } while (ip->i_mnext != mp->m_inodes); > >>> > >>>[*ksymoops disassembly matches here*] > >>> > >> > >>ip->i_mnext is NULL which is never supposed to happen, next question is > >>why? > >> > > > >FWIW, this happened just after rebooting using the XFS 1.01/RedHat boot CD > >and running xfs_repair on the filesystem, which hopefully rules out an > >inconsistent filesystem/filesystem errors. > > > I don't think fs corruption would have much to do with this one, it is a > purely in memory > circular list. So far as I can see it is always manipulated under the > correct locking. I have > a box running a debug kernel sitting in a loop doing the test which > Adrian says makes > this happen for him. It has been going for a few hours, so far no problems. Well, I've been doing the same, and after 68 iterations of his script I got this pair of messages, repeating every three seconds or so (no Oops or anything else): ide_dmaproc: chipset supported ide_dma_lostirq func only: 13 hdc: lost interrupt Looks like a kernel problem or bad hardware? > Would you be willing turn on kdb? It only really makes sense if you are > able to setup > a serial console. There is a debugger command which will walk the > complete list of > inodes in the filesystem. The serial console won't happen, but I think it's no longer necessary either. This is probably not an XFS bug, right? From owner-linux-xfs@oss.sgi.com Thu Jan 10 20:42:57 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0B4gvk08242 for linux-xfs-outgoing; Thu, 10 Jan 2002 20:42:57 -0800 Received: from pneumatic-tube.sgi.com (pneumatic-tube.sgi.com [204.94.214.22]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0B4gmg08220 for ; Thu, 10 Jan 2002 20:42:48 -0800 Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id TAA07951 for ; Thu, 10 Jan 2002 19:43:26 -0800 (PST) mail_from (lord@sgi.com) Received: from tulip-e185.americas.sgi.com (tulip-e185.americas.sgi.com [128.162.185.208]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id VAA4061992; Thu, 10 Jan 2002 21:41:29 -0600 (CST) Received: from sgi.com (GWEWgJVtjm8KshTkZDciyiKKkmxTJtbv@lord-h1.americas.sgi.com [206.11.101.42]) by tulip-e185.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.7) with ESMTP id VAA68238; Thu, 10 Jan 2002 21:41:28 -0600 (CST) Message-ID: <3C3E5FEF.40509@sgi.com> Date: Thu, 10 Jan 2002 21:45:51 -0600 From: Stephen Lord User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.6) Gecko/20011120 X-Accept-Language: en-us MIME-Version: 1.0 To: Pascal Haakmat CC: linux-xfs@oss.sgi.com Subject: Re: Oops with 2.4.16 References: <20020110221155.A912@awacs.dhs.org> <1010697908.2812.22.camel@stout.americas.sgi.com> <20020110225711.A1259@awacs.dhs.org> <1010702208.1772.98.camel@jen.americas.sgi.com> <20020111023859.A2413@awacs.dhs.org> <3C3E578B.7090309@sgi.com> <20020111043633.A791@awacs.dhs.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 2363 Lines: 74 Pascal Haakmat wrote: >10/01/02 21:10, Stephen Lord wrote: > >>Pascal Haakmat wrote: >> >>>10/01/02 16:36, Steve Lord wrote: >>> >>>>On Thu, 2002-01-10 at 15:57, Pascal Haakmat wrote: >>>> >>>>> ASSERT(ipointer_in == B_FALSE); >>>>> ip = ip->i_mnext; >>>>>c01ccb34: 8b 4c 24 70 mov 0x70(%esp,1),%ecx >>>>>c01ccb38: 8b 76 08 mov 0x8(%esi),%esi >>>>>c01ccb3b: 8b 91 14 01 00 00 mov 0x114(%ecx),%edx >>>>> >>>>> } while (ip->i_mnext != mp->m_inodes); >>>>> >>>>>[*ksymoops disassembly matches here*] >>>>> >>>>ip->i_mnext is NULL which is never supposed to happen, next question is >>>>why? >>>> >>>FWIW, this happened just after rebooting using the XFS 1.01/RedHat boot CD >>>and running xfs_repair on the filesystem, which hopefully rules out an >>>inconsistent filesystem/filesystem errors. >>> >>I don't think fs corruption would have much to do with this one, it is a >>purely in memory >>circular list. So far as I can see it is always manipulated under the >>correct locking. I have >>a box running a debug kernel sitting in a loop doing the test which >>Adrian says makes >>this happen for him. It has been going for a few hours, so far no problems. >> > >Well, I've been doing the same, and after 68 iterations of his script I got >this pair of messages, repeating every three seconds or so (no Oops or >anything else): > >ide_dmaproc: chipset supported ide_dma_lostirq func only: 13 >hdc: lost interrupt > >Looks like a kernel problem or bad hardware? > >>Would you be willing turn on kdb? It only really makes sense if you are >>able to setup >>a serial console. There is a debugger command which will walk the >>complete list of >>inodes in the filesystem. >> > >The serial console won't happen, but I think it's no longer necessary >either. This is probably not an XFS bug, right? > Well, in memory corruption of xfs data structures should not be triggerable by losing an interrupt, I would like to track it down some more. Forget kdb if you cannot do the console - we were talking a lot of output here. I may ask you to run some sanity check code in the sync path - you said your oops was repeatable, correct? Steve p.s. can you send me the script, I could look back in the xfs maillist, but I am feeling lazy, I am currently using something I wrote based on the brief description in this thread. From owner-linux-xfs@oss.sgi.com Thu Jan 10 20:54:12 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0B4sCf08481 for linux-xfs-outgoing; Thu, 10 Jan 2002 20:54:12 -0800 Received: from awacs.dhs.org (node10450.a2000.nl [24.132.4.80]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0B4s3g08459 for ; Thu, 10 Jan 2002 20:54:03 -0800 Received: (from p@localhost) by awacs.dhs.org (8.11.0/8.9.3) id g0B3rvh00872; Fri, 11 Jan 2002 04:53:57 +0100 Date: Fri, 11 Jan 2002 04:53:57 +0100 From: Pascal Haakmat To: Stephen Lord Cc: linux-xfs@oss.sgi.com Subject: Re: Oops with 2.4.16 Message-ID: <20020111045357.A864@awacs.dhs.org> References: <20020110221155.A912@awacs.dhs.org> <1010697908.2812.22.camel@stout.americas.sgi.com> <20020110225711.A1259@awacs.dhs.org> <1010702208.1772.98.camel@jen.americas.sgi.com> <20020111023859.A2413@awacs.dhs.org> <3C3E578B.7090309@sgi.com> <20020111043633.A791@awacs.dhs.org> <3C3E5FEF.40509@sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <3C3E5FEF.40509@sgi.com>; from lord@sgi.com on Thu, Jan 10, 2002 at 09:45:51PM -0600 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 2370 Lines: 75 10/01/02 21:45, Stephen Lord wrote: > Pascal Haakmat wrote: > > >10/01/02 21:10, Stephen Lord wrote: > > > >>Pascal Haakmat wrote: > >> > >>>10/01/02 16:36, Steve Lord wrote: [snip] > >>I don't think fs corruption would have much to do with this one, it is a > >>purely in memory > >>circular list. So far as I can see it is always manipulated under the > >>correct locking. I have > >>a box running a debug kernel sitting in a loop doing the test which > >>Adrian says makes > >>this happen for him. It has been going for a few hours, so far no problems. > >> > > > >Well, I've been doing the same, and after 68 iterations of his script I got > >this pair of messages, repeating every three seconds or so (no Oops or > >anything else): > > > >ide_dmaproc: chipset supported ide_dma_lostirq func only: 13 > >hdc: lost interrupt > > > >Looks like a kernel problem or bad hardware? > > > >>Would you be willing turn on kdb? It only really makes sense if you are > >>able to setup > >>a serial console. There is a debugger command which will walk the > >>complete list of > >>inodes in the filesystem. > >> > > > >The serial console won't happen, but I think it's no longer necessary > >either. This is probably not an XFS bug, right? > > > Well, in memory corruption of xfs data structures should not be > triggerable by > losing an interrupt, I would like to track it down some more. Forget kdb > if you > cannot do the console - we were talking a lot of output here. I may ask you > to run some sanity check code in the sync path - you said your oops was > repeatable, correct? Yes, it is, although it takes some time. I suppose if I had waited to reboot the machine when it gave me the "hdc: lost interrupt" it might have turned into an Oops eventually. Right now I have printk's everywhere that I think m_inext gets set and I didn't see it getting any strange values up to and until the "lost interrupt" message. Perhaps I should have waited a bit longer before rebooting. What other code would you like me to add? > Steve > > p.s. can you send me the script, I could look back in the xfs maillist, > but I am feeling > lazy, I am currently using something I wrote based on the brief > description in this > thread. dd if=/dev/urandom of=01 bs=1024 count=8192 #!/bin/bash cp -fr 01 2 for (( i=80; i!=2; i-- )) ; do cp -fr 01 $i & # echo $i done From owner-linux-xfs@oss.sgi.com Thu Jan 10 21:11:27 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0B5BRg08914 for linux-xfs-outgoing; Thu, 10 Jan 2002 21:11:27 -0800 Received: from pneumatic-tube.sgi.com (pneumatic-tube.sgi.com [204.94.214.22]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0B5BLg08892 for ; Thu, 10 Jan 2002 21:11:22 -0800 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.55.149]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id UAA04942 for ; Thu, 10 Jan 2002 20:12:00 -0800 (PST) mail_from (nathans@snort.melbourne.sgi.com) Received: (from nathans@localhost) by snort.melbourne.sgi.com (SGI-8.9.3/8.9.3) id PAA51964 for linux-xfs@oss.sgi.com; Fri, 11 Jan 2002 15:10:01 +1100 (EST) Date: Fri, 11 Jan 2002 15:10:01 +1100 (EST) From: Nathan Scott Message-Id: <200201110410.PAA51964@snort.melbourne.sgi.com> To: linux-xfs@oss.sgi.com Subject: TAKE - xfs_repair Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 1424 Lines: 43 xfs_repair now runs to completion on Deti Fliegl's trashed filesystem, and hopefully others exhibiting those symptoms (ie. "avl_insert: Warning! duplicate range"). Date: Thu Jan 10 20:01:45 PST 2002 Workarea: snort.melbourne.sgi.com:/home/nathans/xfs-cmds The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/xfs-cmds Modid: xfs-cmds:slinx:109424a xfsprogs/doc/CHANGES - 1.48 - add a note about changes so far, don't bother bumping version yet as there's one/two more changes on the way. xfsprogs/repair/dino_chunks.c - 1.3 - make sure that the uncertain_inode_rec tree doesn't already have the given inode range already, otherwise we end up tripping the AVL tree "duplicate insert" and xfs_repair aborts prematurely. xfsprogs/repair/incore.h - 1.2 xfsprogs/repair/incore_ino.c - 1.3 - add find_uncertain_inode_rec routine to cross-check that the inode range given doesn't already exist in the uncertain_inode_rec tree. xfsprogs/repair/avl.c - 1.4 xfsprogs/repair/avl.h - 1.2 xfsprogs/repair/avl64.c - 1.4 xfsprogs/repair/avl64.h - 1.2 xfsprogs/repair/Makefile - 1.6 - improve diagnostic messages in a couple of spots, remove some dead code. xfsprogs/db/print.c - 1.2 xfsprogs/db/check.c - 1.5 xfsprogs/db/io.c - 1.5 xfsprogs/bmap/xfs_bmap.c - 1.5 xfsprogs/rtcp/xfs_rtcp.c - 1.3 xfsprogs/repair/phase6.c - 1.6 - use snprintf instead of sprintf, to be sure, to be sure. From owner-linux-xfs@oss.sgi.com Thu Jan 10 21:17:51 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0B5Hp909136 for linux-xfs-outgoing; Thu, 10 Jan 2002 21:17:51 -0800 Received: from coredump.sh0n.net (qmailremote@CPEdeadbeef0000.cpe.net.cable.rogers.com [24.100.234.67]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0B5Hhg09114 for ; Thu, 10 Jan 2002 21:17:44 -0800 Received: (qmail 29368 invoked from network); 11 Jan 2002 04:18:31 -0000 Received: from coredump.sh0n.net (sh0n@24.100.234.67) by coredump.sh0n.net with SMTP; 11 Jan 2002 04:18:31 -0000 Date: Thu, 10 Jan 2002 23:18:30 -0500 (EST) From: Shawn Starr To: Steve Lord cc: Keith Owens , Subject: Re: ANNOUCEMENT: XFS support to the -mjc 2.4.17 branch (fwd) In-Reply-To: <1010674112.17381.1.camel@jen.americas.sgi.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 1012 Lines: 33 Another person and I have decided to stop -mjc porting for now. because we dont know what will break XFS. so we're forming out own branch and using some patches from -mjc but at a slower pace (first patch is riel's rmap-11a which im suspicous of) but once we can isolate it down. The next step is to fix :) Shawn. On 10 Jan 2002, Steve Lord wrote: > On Wed, 2002-01-09 at 20:57, Shawn Starr wrote: > > > > I'm on a moving target so if things break they break. But i'm not sure. > > User's using my patch have not had file corruption or such. But aside from > > that fxc program which seems to cause problems with XFS (unknown reasons). > > We're doing ok. > > It does not cause any problems in our tree - it has been running for > about 18 hours here without a snag now. Are you saying that the tree > it was dying in was the mjc branch? > > Steve > > > -- > > Steve Lord voice: +1-651-683-3511 > Principal Engineer, Filesystem Software email: lord@sgi.com > > From owner-linux-xfs@oss.sgi.com Thu Jan 10 21:52:33 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0B5qX809769 for linux-xfs-outgoing; Thu, 10 Jan 2002 21:52:33 -0800 Received: from yog-sothoth.sgi.com (eugate.sgi.com [192.48.160.10]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0B5qTg09747 for ; Thu, 10 Jan 2002 21:52:29 -0800 Received: from nodin.corp.sgi.com (fddi-nodin.corp.sgi.com [198.29.75.193]) by yog-sothoth.sgi.com (980305.SGI.8.8.8-aspam-6.2/980304.SGI-aspam-europe) via ESMTP id FAA1635721 for ; Fri, 11 Jan 2002 05:49:47 +0100 (CET) mail_from (kaos@sgi.com) Received: from kao2.melbourne.sgi.com (kao2.melbourne.sgi.com [134.14.55.180]) by nodin.corp.sgi.com (8.11.4/8.11.2/nodin-1.0) with ESMTP id g0B4pN422700064; Thu, 10 Jan 2002 20:51:24 -0800 (PST) Received: by kao2.melbourne.sgi.com (Postfix, from userid 16331) id E996A300095; Fri, 11 Jan 2002 15:51:21 +1100 (EST) Received: from kao2.melbourne.sgi.com (localhost [127.0.0.1]) by kao2.melbourne.sgi.com (Postfix) with ESMTP id 5185D94; Fri, 11 Jan 2002 15:51:21 +1100 (EST) X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 From: Keith Owens To: Shawn Starr Cc: linux-xfs@oss.sgi.com Subject: Re: ANNOUCEMENT: XFS support to the -mjc 2.4.17 branch (fwd) In-reply-to: Your message of "Thu, 10 Jan 2002 23:18:30 CDT." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 11 Jan 2002 15:51:15 +1100 Message-ID: <2879.1010724675@kao2.melbourne.sgi.com> Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 521 Lines: 12 On Thu, 10 Jan 2002 23:18:30 -0500 (EST), Shawn Starr wrote: >Another person and I have decided to stop -mjc porting for now. because we >dont know what will break XFS. > >so we're forming out own branch and using some patches from -mjc but at a >slower pace (first patch is riel's rmap-11a which im suspicous of) but >once we can isolate it down. The next step is to fix :) The XFS split patches for 2.4.17 are now available, they might help. ftp://oss.sgi.com/projects/xfs/download/patches/2.4.17 From owner-linux-xfs@oss.sgi.com Fri Jan 11 01:00:37 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0B90bf13091 for linux-xfs-outgoing; Fri, 11 Jan 2002 01:00:37 -0800 Received: from sgi.com (sgi-too.SGI.COM [204.94.211.39]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0B90Vg13068 for ; Fri, 11 Jan 2002 01:00:31 -0800 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.55.149]) by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id XAA04961 for ; Thu, 10 Jan 2002 23:57:47 -0800 (PST) mail_from (tes@snort.melbourne.sgi.com) Received: (from tes@localhost) by snort.melbourne.sgi.com (SGI-8.9.3/8.9.3) id SAA39838 for linux-xfs@oss.sgi.com; Fri, 11 Jan 2002 18:58:54 +1100 (EST) Date: Fri, 11 Jan 2002 18:58:54 +1100 (EST) From: Timothy Shimmin Message-Id: <200201110758.SAA39838@snort.melbourne.sgi.com> To: linux-xfs@oss.sgi.com Subject: TAKE - xfsdump inomap supprt_prune assertion fix Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 1284 Lines: 39 Matteo, this should stop the assertion failure in xfsdump: "xfsdump: inomap.c:858: supprt_prune: Assertion `state != 2' failed" that you got. I was able to reproduce this once by writing a script which did many file creations, rm's, mkdir's, rmdir's while the dump was going on. For the assertion to fire, one needed to have the inode# reused durint the interval between building the inode map and pruning it. The fix now updates the inodemap with the latest info and does not abort :). (If the inodemap get's out of date again, then it should just mean that the inode might not get dumped this time but will on next incremental.) --Tim Date: Thu Jan 10 23:51:08 PST 2002 Workarea: snort.melbourne.sgi.com:/home/diskb/build4/tes/slinx-xfs desc: xfsdump inomap supprt_prune assertion fix The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: xfs-cmds:slinx:109430a cmd/xfsdump/VERSION - 1.26 - Update for xfsdump inomap supprt_prune assertion fix. cmd/xfsdump/doc/CHANGES - 1.30 - Update for xfsdump inomap supprt_prune assertion fix. cmd/xfsdump/dump/inomap.c - 1.11 - If inomap is obviously out of date during supprt_prune(), then don't cause an assertion failure, just update the inode map to the latest stat info. From owner-linux-xfs@oss.sgi.com Fri Jan 11 02:25:15 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0BAPFG14981 for linux-xfs-outgoing; Fri, 11 Jan 2002 02:25:15 -0800 Received: from goliath.sylaba.poznan.pl (root@goliath.sylaba.poznan.pl [195.216.104.3]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0BAP7g14959 for ; Fri, 11 Jan 2002 02:25:07 -0800 Received: from venus.local.navi.pl (ps103.poznan.sdi.tpnet.pl [217.97.72.103]) by goliath.sylaba.poznan.pl (8.11.6/8.10.1) with ESMTP id g0B9P1c16134 for ; Fri, 11 Jan 2002 10:25:01 +0100 (CET) Received: from venus.local.navi.pl (venus [192.168.1.10]) by venus.local.navi.pl (8.11.6/8.9.3) with ESMTP id g0B9OSr06949 for ; Fri, 11 Jan 2002 10:24:28 +0100 Date: Fri, 11 Jan 2002 10:24:28 +0100 From: Olaf =?iso-8859-2?Q?Fr=B1czyk?= To: linux-xfs@oss.sgi.com Subject: Re: XFS is innocent - was: vmware+XFS+duron+viakt133 - works? Message-ID: <20020111102428.A6873@venus.local.navi.pl> References: <20020110183051.A1483@venus.local.navi.pl> Mime-Version: 1.0 Content-Type: text/plain; format=flowed; charset=ISO-8859-2 In-Reply-To: <20020110183051.A1483@venus.local.navi.pl>; from olaf@cbk.poznan.pl on czw, sty 10, 2002 at 18:30:51 +0100 X-Mailer: Balsa 1.2.3 X-MIME-Autoconverted: from 8bit to quoted-printable by goliath.sylaba.poznan.pl id g0B9P1c16134 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id g0BAP9g14960 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 816 Lines: 20 On 2002.01.10 18:30:51 +0100 Olaf Fr±czyk wrote: > Hi, > I have installed clean RH7.2 on one free partition on my machine. > Removed RH gcc, installed compat-egcs, compiled new kernel (2.4.17) with > xfs (using the same sources as previous) and ... no problems. > So I moved kernel, modules to my working system, and ... it works. Oops, Sorry, I was too fast. The problems were probably masked out by decrease of memory used by VMware for guest OS. The more memory is used, then faster it crashes. So I still don't know if it is XFS related or not. I can't switch system down today, to get clean 2.4.17 kernel, so I'll make some test at Saturday (tomorrow). The problems I have are similar to those described by: Brian C. Huffman in message "2.4.17-xfs w/ VMWare" from 10 Jan 2002. Regards, Olaf Fraczyk From owner-linux-xfs@oss.sgi.com Fri Jan 11 02:30:10 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0BAUAL15195 for linux-xfs-outgoing; Fri, 11 Jan 2002 02:30:10 -0800 Received: from goliath.sylaba.poznan.pl (root@goliath.sylaba.poznan.pl [195.216.104.3]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0BAU5g15172 for ; Fri, 11 Jan 2002 02:30:05 -0800 Received: from venus.local.navi.pl (ps103.poznan.sdi.tpnet.pl [217.97.72.103]) by goliath.sylaba.poznan.pl (8.11.6/8.10.1) with ESMTP id g0B9U0c16962; Fri, 11 Jan 2002 10:30:00 +0100 (CET) Received: from venus.local.navi.pl (venus [192.168.1.10]) by venus.local.navi.pl (8.11.6/8.9.3) with ESMTP id g0B9TUr06994; Fri, 11 Jan 2002 10:29:30 +0100 Date: Fri, 11 Jan 2002 10:29:30 +0100 From: Olaf =?iso-8859-1?Q?Fr=B1czyk?= To: "Brian C . Huffman" Cc: linux-xfs@oss.sgi.com Subject: Re: 2.4.17-xfs w/ VMWare Message-ID: <20020111102930.C6873@venus.local.navi.pl> References: Mime-Version: 1.0 Content-Type: text/plain; format=flowed; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit In-Reply-To: ; from sheep@graze.net on czw, sty 10, 2002 at 18:12:43 +0100 X-Mailer: Balsa 1.2.3 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 718 Lines: 22 On 2002.01.10 18:12:43 +0100 Brian C. Huffman wrote: > All, > > Are there any known issues w/ 2.4.17 w/ XFS and VMWare? I've > been > trying to get this combo to work (w/ win2k guest) and am having quite a > few problems. I keep getting "stack shutdowns" inside the vmware > machine. Hi, Do you have non-Intel processor, or VIA chipset? As you will find in the list, I have similar problems. Subjects: 1. vmware+XFS+duron+viakt133 - works? 2. XFS is innocent - was: vmware+XFS+duron+viakt133 - works? Last time I thought everything is OK, but it wasn't true. I have to test it more. I still don't know if it is XFS related or not. Could you tell what you have tested and when it crashes? Regards, Olaf Fraczyk From owner-linux-xfs@oss.sgi.com Fri Jan 11 02:50:52 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0BAoq215673 for linux-xfs-outgoing; Fri, 11 Jan 2002 02:50:52 -0800 Received: from mta03bw.bigpond.com (mta03bw.bigpond.com [139.134.6.86]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0BAojg15647 for ; Fri, 11 Jan 2002 02:50:46 -0800 Message-Id: <200201111050.g0BAojg15647@oss.sgi.com> Received: from there ([144.135.24.81]) by mta03bw.bigpond.com (Netscape Messaging Server 4.15) with SMTP id GPRQC200.FHH; Fri, 11 Jan 2002 19:57:38 +1000 Received: from CPE-144-137-136-173.qld.bigpond.net.au ([144.137.136.173]) by bwmam05.mailsvc.email.bigpond.com(MailRouter V3.0h 44/2010760); 11 Jan 2002 19:50:36 Content-Type: text/plain; charset="us-ascii" From: Adrian Head To: Stephen Lord , Jason White Subject: Re: Partition un(mount|repairable) Date: Fri, 11 Jan 2002 19:50:32 +1000 X-Mailer: KMail [version 1.3.1] Cc: linux-xfs@oss.sgi.com References: <3C3C45F2.D6533E44@cs.tum.edu> <15422.17196.469756.949891@jpc.local> <3C3E5DFD.1060902@sgi.com> In-Reply-To: <3C3E5DFD.1060902@sgi.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 1967 Lines: 48 On Fri, 11 Jan 2002 13:37, Stephen Lord wrote: > >Any suggestions as to how the damage was done in the first place - > >what the bug is? > > Not as yet, but there have now been two cases of filesystems ending up > confusing repair like this. > > >There have been worrying reports of data corruption over the last few > >weeks, and I am sure the developers are trying to track them down. In my time running Linux/Win? I have had corruption or major issues with most of the filesystems at some time or other. I still trust XFS as I know where it falls down for me. Of course YMMV. My > >own system hasn't been used much recently as I have been away on > >holiday, but I booted it this morning and everything seemed fine > >(running Linux 2.4.17-xfs as downloaded from CVS at the end of last > >year). > > I would say it is partially as xfs gets more exposure it gets tried on more > combinations of hardware and software (compilers). This is very true and something that I'm very happy about. The more people that run XFS the better chance of catching every little issue; which results in a great stable filesystem very suitable for fileservers. Just look at where all the operation time has put ext2. I am not aware of > any 'data corruption' issues remaining (emacs builds should be fixed, > and the fsx-linux program runs fine for me for 24 hours - I believe it > was been run in a patched kernel). > > The directory corruption issues do concern me, and I have to admit to being > baffled right now, but the vast majority of users do not see any problems > at all. Under my normal operational use of XFS, workstations & a 20client fileserver XFS is as stable as they come. I have not had any issues with these setups at all. All issues that I have encounted have occured when I have been stress testing the system way past where it would normally run in an attempt to find the limitations. -- Adrian Head (Public Key available on request.) From owner-linux-xfs@oss.sgi.com Fri Jan 11 02:54:28 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0BAsSn15854 for linux-xfs-outgoing; Fri, 11 Jan 2002 02:54:28 -0800 Received: from mta04bw.bigpond.com (mta04bw.bigpond.com [139.134.6.87]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0BAsMg15831 for ; Fri, 11 Jan 2002 02:54:22 -0800 Message-Id: <200201111054.g0BAsMg15831@oss.sgi.com> Received: from there ([144.135.24.87]) by mta04bw.bigpond.com (Netscape Messaging Server 4.15) with SMTP id GPRQI100.9U8; Fri, 11 Jan 2002 20:01:13 +1000 Received: from CPE-144-137-136-173.qld.bigpond.net.au ([144.137.136.173]) by bwmam07.mailsvc.email.bigpond.com(MailRouter V3.0h 62/15995927); 11 Jan 2002 19:54:11 Content-Type: text/plain; charset="us-ascii" From: Adrian Head To: Pascal Haakmat , Stephen Lord Subject: Re: Oops with 2.4.16 Date: Fri, 11 Jan 2002 19:54:02 +1000 X-Mailer: KMail [version 1.3.1] Cc: linux-xfs@oss.sgi.com References: <20020110221155.A912@awacs.dhs.org> <3C3E5FEF.40509@sgi.com> <20020111045357.A864@awacs.dhs.org> In-Reply-To: <20020111045357.A864@awacs.dhs.org> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 1410 Lines: 44 On Fri, 11 Jan 2002 13:53, Pascal Haakmat wrote: > > Steve > > > > p.s. can you send me the script, I could look back in the xfs maillist, > > but I am feeling > > lazy, I am currently using something I wrote based on the brief > > description in this > > thread. > > dd if=/dev/urandom of=01 bs=1024 count=8192 > > #!/bin/bash > cp -fr 01 2 > > for (( i=80; i!=2; i-- )) ; do > cp -fr 01 $i & > # echo $i > done Back around the 18/12/2001 the 2.4.16-xfs kernel would die for me when running the test above (80 cp processes). Eric sugested that I go with the CVS at the time which was 2.4.17-xfs and the fixes that Steve checked into the CVS helped a lot. http://marc.theaimsgroup.com/?t=100819465500006&r=1&w=2 http://marc.theaimsgroup.com/?t=100810400700001&r=1&w=2 Using the 2.4.17-xfs CVS kernel it would survive the 80 cp process test but would die at 160 cp processes whereas ext2/3 and resierfs would chug away until finished. The test on my box takes forever (8hr+) but I intend to start testing the current CVS tonight. The composition of the file sizes seem to make an issue as I have done the same test with a single 650M iso image and it was fine. Pascal - what type and make are your drives? and what brand & make of controllers are you using? I have never got an interrupt error but was wondering if the hardware was simular. -- Adrian Head (Public Key available on request.) From owner-linux-xfs@oss.sgi.com Fri Jan 11 03:44:14 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0BBiEr16773 for linux-xfs-outgoing; Fri, 11 Jan 2002 03:44:14 -0800 Received: from quasar.sif.it (IDENT:root@quasar.sif.it [131.154.110.3]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0BBi9g16748 for ; Fri, 11 Jan 2002 03:44:09 -0800 Received: from localhost (matteo@localhost) by quasar.sif.it (8.11.6/8.11.6) with ESMTP id g0BAipW13531; Fri, 11 Jan 2002 11:44:51 +0100 Date: Fri, 11 Jan 2002 11:44:51 +0100 (CET) From: Matteo Centonza To: Timothy Shimmin cc: Subject: Re: TAKE - xfsdump inomap supprt_prune assertion fix In-Reply-To: <200201110758.SAA39838@snort.melbourne.sgi.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 769 Lines: 28 Hi Tim, > this should stop the assertion failure in xfsdump: > "xfsdump: inomap.c:858: supprt_prune: Assertion `state != 2' failed" > that you got. > I was able to reproduce this once > by writing a script which did many file creations, rm's, mkdir's, rmdir's > while the dump was going on. > For the assertion to fire, one needed to have the inode# reused > durint the interval between building the inode map and pruning it. (see 4th Murphy's law ;-) > The fix now updates the inodemap with the latest info and > does not abort :). > (If the inodemap get's out of date again, then it should just mean > that the inode might not get dumped this time but will on next > incremental.) thanks for the very quick fix. I'll upgrade my xfsdump ASAP. Ciao, -m From owner-linux-xfs@oss.sgi.com Fri Jan 11 06:16:07 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0BEG7G20173 for linux-xfs-outgoing; Fri, 11 Jan 2002 06:16:07 -0800 Received: from zok.sgi.com (zok.sgi.com [204.94.215.101]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0BEFvg20149 for ; Fri, 11 Jan 2002 06:15:57 -0800 Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by zok.sgi.com (8.11.4/8.11.4/linux-outbound_gateway-1.1) with ESMTP id g0BDFoo29410 for ; Fri, 11 Jan 2002 05:15:50 -0800 Received: from tulip-e185.americas.sgi.com (tulip-e185.americas.sgi.com [128.162.185.208]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id HAA4065055; Fri, 11 Jan 2002 07:14:34 -0600 (CST) Received: from sgi.com (qonCbCefMHRTlKDQd9XobdpEngqip3P7@cf-vpn-sw-corp-64-10.corp.sgi.com [134.15.64.10]) by tulip-e185.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.7) with ESMTP id HAA89120; Fri, 11 Jan 2002 07:14:33 -0600 (CST) Message-ID: <3C3EE642.8060109@sgi.com> Date: Fri, 11 Jan 2002 07:18:58 -0600 From: Stephen Lord User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.6) Gecko/20011120 X-Accept-Language: en-us MIME-Version: 1.0 To: Adrian Head CC: Jason White , linux-xfs@oss.sgi.com Subject: Re: Partition un(mount|repairable) References: <3C3C45F2.D6533E44@cs.tum.edu> <15422.17196.469756.949891@jpc.local> <3C3E5DFD.1060902@sgi.com> <200201110947.BAA02530@sgi.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 2808 Lines: 80 Adrian Head wrote: >On Fri, 11 Jan 2002 13:37, Stephen Lord wrote: > >>>Any suggestions as to how the damage was done in the first place - >>>what the bug is? >>> >>Not as yet, but there have now been two cases of filesystems ending up >>confusing repair like this. >> >>>There have been worrying reports of data corruption over the last few >>>weeks, and I am sure the developers are trying to track them down. >>> > >In my time running Linux/Win? I have had corruption or major issues with most >of the filesystems at some time or other. I still trust XFS as I know where >it falls down for me. Of course YMMV. > >My > >>>own system hasn't been used much recently as I have been away on >>>holiday, but I booted it this morning and everything seemed fine >>>(running Linux 2.4.17-xfs as downloaded from CVS at the end of last >>>year). >>> >>I would say it is partially as xfs gets more exposure it gets tried on more >>combinations of hardware and software (compilers). >> > >This is very true and something that I'm very happy about. The more people >that run XFS the better chance of catching every little issue; which results >in a great stable filesystem very suitable for fileservers. Just look at >where all the operation time has put ext2. > >I am not aware of > >>any 'data corruption' issues remaining (emacs builds should be fixed, >>and the fsx-linux program runs fine for me for 24 hours - I believe it >>was been run in a patched kernel). >> >>The directory corruption issues do concern me, and I have to admit to being >>baffled right now, but the vast majority of users do not see any problems >>at all. >> > >Under my normal operational use of XFS, workstations & a 20client fileserver >XFS is as stable as they come. I have not had any issues with these setups >at all. All issues that I have encounted have occured when I have >been stress testing the system way past where it would normally run in an >attempt to find the limitations. > Just an update here, some things which happened overnight: o The directory corruption which Ralf Bergs has been fighting turns out to be hardware, they reproduced corruption under ext2 o xfs_repair has been fixed to deal with the avl insert case o Finally the thing I forgot to mention, fs corruption which happens due to hard machine failure (not a software crash) and is on an IDE drive with write caching turned on is to be expected. The write caching will break the ordering constraints expected by journalling filesystems, this will probably be true of ext3, jfs and reiserfs too. If you are worried about this sort of corruption then hdparm -W0 /dev/hdX is your friend. Of course it will also tell you how slow ide drives really are. So I think we are down to oopses now. Steve From owner-linux-xfs@oss.sgi.com Fri Jan 11 07:33:46 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0BFXk625291 for linux-xfs-outgoing; Fri, 11 Jan 2002 07:33:46 -0800 Received: from coredump.sh0n.net (qmailremote@CPEdeadbeef0000.cpe.net.cable.rogers.com [24.100.234.67]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0BFXhg25266 for ; Fri, 11 Jan 2002 07:33:44 -0800 Received: (qmail 513 invoked from network); 11 Jan 2002 14:34:30 -0000 Received: from unknown (HELO unaropia.datawire.net) (207.61.129.120) by coredump.sh0n.net with SMTP; 11 Jan 2002 14:34:30 -0000 Subject: XFS not corrupting file system with 2.4.18-pre3 + XFS-CVS-HEAD From: Shawn Starr To: xfs Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/1.0.1.99 (Preview Release) Date: 11 Jan 2002 09:34:46 -0500 Message-Id: <1010759714.25378.1014.camel@unaropia> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 283 Lines: 12 278 root 19 0 1036 1036 364 R 93.2 1.6 378:43 blowup-xfs It's still running since 3AM EST this morning. Stephen, looks like -mjc was causing it. But we are about to test riel's rmap-11a to see if that is causing the XFS blowups/corruption :) Looks good! Shawn. From owner-linux-xfs@oss.sgi.com Fri Jan 11 07:52:05 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0BFq5o25796 for linux-xfs-outgoing; Fri, 11 Jan 2002 07:52:05 -0800 Received: from coredump.sh0n.net (qmailremote@CPEdeadbeef0000.cpe.net.cable.rogers.com [24.100.234.67]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0BFq0g25773 for ; Fri, 11 Jan 2002 07:52:00 -0800 Received: (qmail 530 invoked from network); 11 Jan 2002 14:52:48 -0000 Received: from unknown (HELO unaropia.datawire.net) (207.61.129.120) by coredump.sh0n.net with SMTP; 11 Jan 2002 14:52:48 -0000 Subject: ANNOUCEMENT: XFS support to 2.4 Kernel branch -sfx From: Shawn Starr To: xfs In-Reply-To: <2879.1010724675@kao2.melbourne.sgi.com> References: <2879.1010724675@kao2.melbourne.sgi.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/1.0.1.99 (Preview Release) Date: 11 Jan 2002 09:53:05 -0500 Message-Id: <1010760812.25378.1036.camel@unaropia> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 961 Lines: 25 We've formed a new branch separate of -mjc for ovious reasons namely, we want to check how each patch might affect XFS and such and we're going in a different direction but maintaining 2.4.XX-pre# patches and keeping up to pace with the vanilla kernel series as well as XFS's cvs tree. More details coming, we've just setup a cvs server for our branch. Shawn. On Thu, 2002-01-10 at 23:51, Keith Owens wrote: > On Thu, 10 Jan 2002 23:18:30 -0500 (EST), > Shawn Starr wrote: > >Another person and I have decided to stop -mjc porting for now. because we > >dont know what will break XFS. > > > >so we're forming out own branch and using some patches from -mjc but at a > >slower pace (first patch is riel's rmap-11a which im suspicous of) but > >once we can isolate it down. The next step is to fix :) > > The XFS split patches for 2.4.17 are now available, they might help. > ftp://oss.sgi.com/projects/xfs/download/patches/2.4.17 > > From owner-linux-xfs@oss.sgi.com Fri Jan 11 08:59:19 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0BGxJi27231 for linux-xfs-outgoing; Fri, 11 Jan 2002 08:59:19 -0800 Received: from deliverator.sgi.com (deliverator.sgi.com [204.94.214.10]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0BGxFg27209 for ; Fri, 11 Jan 2002 08:59:16 -0800 Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id HAA03594 for ; Fri, 11 Jan 2002 07:54:53 -0800 (PST) mail_from (eric@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id JAA4057183 for ; Fri, 11 Jan 2002 09:57:57 -0600 (CST) Received: from stout.americas.sgi.com (stout.americas.sgi.com [128.162.187.5]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id JAA68885 for ; Fri, 11 Jan 2002 09:57:57 -0600 (CST) Received: by stout.americas.sgi.com (8.11.6/SGI-client-1.7) id g0BFvvG14241; Fri, 11 Jan 2002 09:57:57 -0600 Message-Id: <200201111557.g0BFvvG14241@stout.americas.sgi.com> Date: Fri, 11 Jan 2002 09:57:57 -0600 From: Eric Sandeen Subject: TAKE - Make mkfs.xfs remove prior fs signatures Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 839 Lines: 26 Even after a mkfs.xfs, old filesystem signatures could still be on the disk, and mount or parted's heuristics could fail when determining fs type. This change zeros the first 68k and last 64k on the device, which should remove all known traces of prior filesystems. o Swap signature, ext[2,3], reiserfs, and ext2 in first 64k o MD superblock in last 64k Date: Fri Jan 11 07:47:53 PST 2002 Workarea: stout.americas.sgi.com:/localhome/eric/2.4.x-xfs/workarea-reallyclean The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: xfs-cmds:slinx:109443a cmd/xfsprogs/doc/CHANGES - 1.49 - Update changelog for old fs signature removal. cmd/xfsprogs/mkfs/xfs_mkfs.c - 1.20 - Remove all traces of prior filesystems by zeroing out first 68k and last 64k of device. (Last 64k == MD superblock) From owner-linux-xfs@oss.sgi.com Fri Jan 11 14:59:57 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0BMxvI03592 for linux-xfs-outgoing; Fri, 11 Jan 2002 14:59:57 -0800 Received: from svelte (node10450.a2000.nl [24.132.4.80]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0BMxPg03542 for ; Fri, 11 Jan 2002 14:59:25 -0800 Received: (from p@localhost) by svelte (8.11.2/8.11.6) id g0BLxHx10718 for linux-xfs@oss.sgi.com; Fri, 11 Jan 2002 22:59:17 +0100 Date: Fri, 11 Jan 2002 22:58:16 +0100 From: Pascal Haakmat To: linux-xfs@oss.sgi.com Subject: Oops with 2.4.16 [update] Message-ID: <20020111225816.A10689@svelte.dhs.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 14184 Lines: 300 It seems I hit the jackpot. I've been running Andre's script overnight. When I woke up to look at the machine this morning, the entire disk had gone south. xfs_repair finds something resembling a secondary superblock, but then gives up with a fatal error. The machine did not crash. /var/log/messages says: Jan 11 06:55:10 awacs syslogd 1.3-3: restart. .... Jan 11 11:03:53 awacs kernel: xfs_iunlink_remove: XFS_TEST_ERROR() returned an error on ide1(22,1). Returning EFSCORRUPTED. Jan 11 11:03:53 awacs kernel: xfs_inactive: xfs_ifree() returned an error = 990 on ide1(22,1) Jan 11 11:03:53 awacs kernel: xfs_force_shutdown(ide1(22,1),0x1) called from line 1952 of file xfs_vnodeops.c. Return address = 0xc01cf942 Jan 11 11:03:53 awacs kernel: I/O Error Detected. Shutting down filesystem: ide1(22,1) Jan 11 11:03:53 awacs kernel: Please umount the filesystem, and rectify the problem(s) So it took approx. three hours for the error to occur with 80 simultaneous cp processes. I turned off the sound drivers during this run, because with the sound drivers enabled, trying to record audio while the test was running would cause the kernel to Oops: Jan 11 06:53:34 awacs kernel: Unable to handle kernel paging request at virtual address 01dae918 Jan 11 06:53:34 awacs kernel: printing eip: Jan 11 06:53:34 awacs kernel: c01792d9 Jan 11 06:53:34 awacs kernel: *pde = 00000000 Jan 11 06:53:34 awacs kernel: Oops: 0002 Jan 11 06:53:34 awacs kernel: CPU: 0 Jan 11 06:53:34 awacs kernel: EIP: 0010:[convert_page+65/160] Not tainted Jan 11 06:53:34 awacs kernel: EFLAGS: 00010203 Jan 11 06:53:34 awacs kernel: eax: 0000000a ebx: 01dae900 ecx: 005ae3b8 edx: c0328f80 Jan 11 06:53:34 awacs kernel: esi: c0328f80 edi: 00000002 ebp: c100ca80 esp: d9fb5be4 Jan 11 06:53:34 awacs kernel: ds: 0018 es: 0018 ss: 0018 Jan 11 06:53:34 awacs kernel: Process cp (pid: 2506, stackpage=d9fb5000) Jan 11 06:53:34 awacs kernel: Stack: 00000065 d9fb5c40 00000065 ddb04080 c01793fa ddb04080 c100ca80 d9fb5c40 Jan 11 06:53:34 awacs kernel: 00000000 00000000 c100f640 d9fb5c40 00000800 c01794d1 ddb04080 c100f640 Jan 11 06:53:34 awacs kernel: d9fb5c40 00000000 00010002 ddb04080 c100f640 d9fb5c3c 00000001 005ae3b8 Jan 11 06:53:34 awacs kernel: Call Trace: [cluster_write+194/216] [pagebuf_delalloc_convert+193/208] [pagebuf_write_full_page+107/372] [linvfs_read_full_page+4/24] [xfs_read+443/556] Jan 11 06:53:34 awacs kernel: [linvfs_read_full_page+4/24] [_write_buffer+85/112] [write_some_buffers+121/300] [] [kmem_cache_alloc+93/260] [get_unused_buffer_head+78/156] Jan 11 06:53:34 awacs kernel: [create_buffers+93/236] [__refile_buffer+84/92] [balance_dirty_state+15/68] [balance_dirty+32/56] [hook_buffers_to_page_delay+63/72] [__pb_block_commit_write_async+71/76] Jan 11 06:53:34 awacs kernel: [__pagebuf_do_delwri+342/496] [_pagebuf_file_write+365/552] [pagebuf_generic_file_write+179/776] [linvfs_read_full_page+4/24] [xfs_write+1231/1344] [linvfs_read_full_page+4/24] Jan 11 06:53:34 awacs kernel: [xfs_ilock_nowait+30/196] [linvfs_readdir+252/596] [sys_write+146/200] [system_call+51/56] So I upgraded the sound drivers (from OSS 3.9.5f to 3.9.6b) and applied Andre Hedrick's IDE patch for 2.4.16, available at http://www.linuxdiskcert.org/. This configuration (i.e. 2.4.16+lowlatency+ide+xfs) has now successfully been running the cp script for a couple of hours. The last two hours I have been running it with 160 cp processes, and although the machine is very slow, it seems to chug along. Both upgrades (sound & IDE patch) solve separate parts of the problem: with the new sound drivers I can record while running the test; with the older sound drivers this causes an Oops. In both cases, there are no longer any "hdc: lost interrupt" messages and there is no filesystem corruption yet (well, the filesystem is now completely empty, that might make a difference). In any case the problem does not seem to be with XFS; also, Andre Hedrick has been quite vocal on lkml about problems with the block layer/IDE/ATA (I think) support in the 2.4 kernel. I will see if the machine survives the 160 cp processes test tonight. If it does, then I would consider the problem solved. Meanwhile thanks for all your help. (I am typing this message from another machine that might be misconfigured for sending mail, so I hope this message gets through. I can't read mail yet until I've restored from backups, probably tomorrow.) Attaching dmesg output for Andre who wanted to know my hardware configuration: Linux version 2.4.16-xfs-ll (root@awacs.dhs.org) (gcc version egcs-2.91.66 19990314/Linux (egcs-1.1.2 release)) #20 SMP Fri Jan 11 16:17:01 CET 2002 BIOS-provided physical RAM map: BIOS-e820: 0000000000000000 - 000000000009fc00 (usable) BIOS-e820: 000000000009fc00 - 00000000000a0000 (reserved) BIOS-e820: 00000000000e0000 - 0000000000100000 (reserved) BIOS-e820: 0000000000100000 - 0000000020000000 (usable) BIOS-e820: 00000000fec00000 - 00000000fec01000 (reserved) BIOS-e820: 00000000fee00000 - 00000000fee01000 (reserved) BIOS-e820: 00000000fffc0000 - 0000000100000000 (reserved) found SMP MP-table at 000fb4c0 hm, page 000fb000 reserved twice. hm, page 000fc000 reserved twice. hm, page 000f2000 reserved twice. hm, page 000f3000 reserved twice. On node 0 totalpages: 131072 zone(0): 4096 pages. zone(1): 126976 pages. zone(2): 0 pages. Intel MultiProcessor Specification v1.1 Virtual Wire compatibility mode. OEM ID: INTEL Product ID: 440BX APIC at: 0xFEE00000 Processor #0 Pentium(tm) Pro APIC version 17 Processor #1 Pentium(tm) Pro APIC version 17 I/O APIC #2 Version 17 at 0xFEC00000. Processors: 2 Kernel command line: auto BOOT_IMAGE=linux-ll-ide ro root=301 BOOT_FILE=/boot/vmlinuz-2.4.16-xfs-ll-ide Initializing CPU#0 Detected 601.380 MHz processor. Console: colour VGA+ 80x25 Calibrating delay loop... 1199.30 BogoMIPS Memory: 513048k/524288k available (1636k kernel code, 10852k reserved, 363k data, 224k init, 0k highmem) Dentry-cache hash table entries: 65536 (order: 7, 524288 bytes) Inode-cache hash table entries: 32768 (order: 6, 262144 bytes) Mount-cache hash table entries: 8192 (order: 4, 65536 bytes) Buffer-cache hash table entries: 32768 (order: 5, 131072 bytes) Page-cache hash table entries: 131072 (order: 7, 524288 bytes) CPU: Before vendor init, caps: 0383fbff 00000000 00000000, vendor = 0 CPU: L1 I cache: 16K, L1 D cache: 16K CPU: L2 cache: 256K Intel machine check architecture supported. Intel machine check reporting enabled on CPU#0. CPU: After vendor init, caps: 0383fbff 00000000 00000000 00000000 CPU: After generic, caps: 0383fbff 00000000 00000000 00000000 CPU: Common caps: 0383fbff 00000000 00000000 00000000 Enabling fast FPU save and restore... done. Enabling unmasked SIMD FPU exception support... done. Checking 'hlt' instruction... OK. POSIX conformance testing by UNIFIX mtrr: v1.40 (20010327) Richard Gooch (rgooch@atnf.csiro.au) mtrr: detected mtrr type: Intel CPU: Before vendor init, caps: 0383fbff 00000000 00000000, vendor = 0 CPU: L1 I cache: 16K, L1 D cache: 16K CPU: L2 cache: 256K Intel machine check reporting enabled on CPU#0. CPU: After vendor init, caps: 0383fbff 00000000 00000000 00000000 CPU: After generic, caps: 0383fbff 00000000 00000000 00000000 CPU: Common caps: 0383fbff 00000000 00000000 00000000 CPU0: Intel Pentium III (Coppermine) stepping 06 per-CPU timeslice cutoff: 731.53 usecs. enabled ExtINT on CPU#0 ESR value before enabling vector: 00000004 ESR value after enabling vector: 00000000 Booting processor 1/1 eip 2000 Initializing CPU#1 masked ExtINT on CPU#1 ESR value before enabling vector: 00000000 ESR value after enabling vector: 00000000 Calibrating delay loop... 1202.58 BogoMIPS CPU: Before vendor init, caps: 0383fbff 00000000 00000000, vendor = 0 CPU: L1 I cache: 16K, L1 D cache: 16K CPU: L2 cache: 256K Intel machine check reporting enabled on CPU#1. CPU: After vendor init, caps: 0383fbff 00000000 00000000 00000000 CPU: After generic, caps: 0383fbff 00000000 00000000 00000000 CPU: Common caps: 0383fbff 00000000 00000000 00000000 CPU1: Intel Pentium III (Coppermine) stepping 06 Total of 2 processors activated (2401.89 BogoMIPS). ENABLING IO-APIC IRQs Setting 2 in the phys_id_present_map ...changing IO-APIC physical APIC ID to 2 ... ok. init IO_APIC IRQs IO-APIC (apicid-pin) 2-0, 2-5, 2-9, 2-10, 2-11, 2-20, 2-21, 2-22, 2-23 not connected. ..TIMER: vector=0x31 pin1=2 pin2=0 number of MP IRQ sources: 17. number of IO-APIC #2 registers: 24. testing the IO APIC....................... IO APIC #2...... .... register #00: 02000000 ....... : physical APIC id: 02 .... register #01: 00170011 ....... : max redirection entries: 0017 ....... : PRQ implemented: 0 ....... : IO APIC version: 0011 .... register #02: 00000000 ....... : arbitration: 00 .... IRQ redirection table: NR Log Phy Mask Trig IRR Pol Stat Dest Deli Vect: 00 000 00 1 0 0 0 0 0 0 00 01 003 03 0 0 0 0 0 1 1 39 02 003 03 0 0 0 0 0 1 1 31 03 003 03 0 0 0 0 0 1 1 41 04 003 03 0 0 0 0 0 1 1 49 05 000 00 1 0 0 0 0 0 0 00 06 003 03 0 0 0 0 0 1 1 51 07 003 03 0 0 0 0 0 1 1 59 08 003 03 0 0 0 0 0 1 1 61 09 000 00 1 0 0 0 0 0 0 00 0a 000 00 1 0 0 0 0 0 0 00 0b 000 00 1 0 0 0 0 0 0 00 0c 003 03 0 0 0 0 0 1 1 69 0d 003 03 0 0 0 0 0 1 1 71 0e 003 03 0 0 0 0 0 1 1 79 0f 003 03 0 0 0 0 0 1 1 81 10 003 03 1 1 0 1 0 1 1 89 11 003 03 1 1 0 1 0 1 1 91 12 003 03 1 1 0 1 0 1 1 99 13 003 03 1 1 0 1 0 1 1 A1 14 000 00 1 0 0 0 0 0 0 00 15 000 00 1 0 0 0 0 0 0 00 16 000 00 1 0 0 0 0 0 0 00 17 000 00 1 0 0 0 0 0 0 00 IRQ to pin mappings: IRQ0 -> 0:2 IRQ1 -> 0:1 IRQ3 -> 0:3 IRQ4 -> 0:4 IRQ5 -> 0:19 IRQ6 -> 0:6 IRQ7 -> 0:7 IRQ8 -> 0:8 IRQ9 -> 0:18 IRQ10 -> 0:16 IRQ11 -> 0:17 IRQ12 -> 0:12 IRQ13 -> 0:13 IRQ14 -> 0:14 IRQ15 -> 0:15 .................................... done. Using local APIC timer interrupts. calibrating APIC timer ... ..... CPU clock speed is 601.3388 MHz. ..... host bus clock speed is 100.2228 MHz. cpu: 0, clocks: 1002228, slice: 334076 CPU0 cpu: 1, clocks: 1002228, slice: 334076 CPU1 checking TSC synchronization across CPUs: passed. Waiting on wait_init_idle (map = 0x2) All processors have done init_idle PCI: PCI BIOS revision 2.10 entry at 0xfdb81, last bus=1 PCI: Using configuration type 1 PCI: Probing PCI hardware Linux NET4.0 for Linux 2.4 Based upon Swansea University Computer Society NET3.039 Starting kswapd SGI XFS with ACLs, EAs, no debug enabled pty: 256 Unix98 ptys configured Serial driver version 5.05c (2001-07-08) with MANY_PORTS SHARE_IRQ SERIAL_PCI enabled ttyS00 at 0x03f8 (irq = 4) is a 16550A Real Time Clock Driver v1.10e block: 128 slots per queue, batch=32 Uniform Multi-Platform E-IDE driver Revision: 6.31 ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx PIIX4: IDE controller on PCI bus 00 dev 39 PIIX4: chipset revision 1 PIIX4: not 100% native mode: will probe irqs later ide0: BM-DMA at 0xffa0-0xffa7, BIOS settings: hda:DMA, hdb:DMA ide1: BM-DMA at 0xffa8-0xffaf, BIOS settings: hdc:DMA, hdd:pio hda: MAXTOR 4K060H3, ATA DISK drive hdb: QUANTUM FIREBALL EX6.4A, ATA DISK drive hdc: Maxtor 91531U3, ATA DISK drive ide0 at 0x1f0-0x1f7,0x3f6 on irq 14 ide1 at 0x170-0x177,0x376 on irq 15 hda: 117266688 sectors (60041 MB) w/2000KiB Cache, CHS=7299/255/63, UDMA(33) hdb: 12594960 sectors (6449 MB) w/418KiB Cache, CHS=784/255/63, UDMA(33) hdc: 30015216 sectors (15368 MB) w/512KiB Cache, CHS=29777/16/63, UDMA(33) Partition check: hda: hda1 hdb: hdb1 hdb2 hdb3 hdc: unknown partition table Floppy drive(s): fd0 is 1.44M FDC 0 is a post-1991 82077 8139too Fast Ethernet driver 0.9.22 eth0: RealTek RTL8139 Fast Ethernet at 0xe0800f00, 00:30:ab:02:fd:e7, IRQ 9 eth0: Identified 8139 chip type 'RTL-8139C' eth1: RealTek RTL8139 Fast Ethernet at 0xe0802e00, 00:50:fc:0e:22:4d, IRQ 9 eth1: Identified 8139 chip type 'RTL-8139C' Linux agpgart interface v0.99 (c) Jeff Hartmann agpgart: Maximum main memory to use for agp memory: 440M agpgart: Detected Intel 440GX chipset agpgart: AGP aperture is 64M @ 0xf8000000 SCSI subsystem driver Revision: 1.00 (scsi0) found at PCI 0/14/0 (scsi0) Wide Channel, SCSI ID=7, 32/255 SCBs (scsi0) Downloading sequencer code... 398 instructions downloaded scsi0 : Adaptec AHA274x/284x/294x (EISA/VLB/PCI-Fast SCSI) 5.2.4/5.2.0 Vendor: PLEXTOR Model: CD-ROM PX-40TS Rev: 1.10 Type: CD-ROM ANSI SCSI revision: 02 Vendor: PLEXTOR Model: CD-R PX-W8220T Rev: 1.03 Type: CD-ROM ANSI SCSI revision: 02 Attached scsi CD-ROM sr0 at scsi0, channel 0, id 3, lun 0 Attached scsi CD-ROM sr1 at scsi0, channel 0, id 4, lun 0 (scsi0:0:3:0) Synchronous at 20.0 Mbyte/sec, offset 15. sr0: scsi-1 drive Uniform CD-ROM driver Revision: 3.12 (scsi0:0:4:0) Synchronous at 10.0 Mbyte/sec, offset 8. sr1: scsi3-mmc drive: 20x/20x writer cd/rw xa/form2 cdda tray NET4: Linux TCP/IP 1.0 for NET4.0 IP Protocols: ICMP, UDP, TCP IP: routing cache hash table of 4096 buckets, 32Kbytes TCP: Hash tables configured (established 131072 bind 65536) NET4: Unix domain sockets 1.0/SMP for Linux NET4.0. XFS mounting filesystem ide0(3,1) XFS: WARNING: recovery required on readonly filesystem. XFS: write access will be enabled during mount. Starting XFS recovery on filesystem: ide0(3,1) (dev: 3/1) Ending XFS recovery on filesystem: ide0(3,1) (dev: 3/1) VFS: Mounted root (xfs filesystem) readonly. From owner-linux-xfs@oss.sgi.com Fri Jan 11 14:58:46 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0BMwkJ03497 for linux-xfs-outgoing; Fri, 11 Jan 2002 14:58:46 -0800 Received: from pneumatic-tube.sgi.com (pneumatic-tube.sgi.com [204.94.214.22]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0BMwgg03475 for ; Fri, 11 Jan 2002 14:58:42 -0800 Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id NAA00046 for ; Fri, 11 Jan 2002 13:59:21 -0800 (PST) mail_from (lord@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id PAA4072430 for ; Fri, 11 Jan 2002 15:57:23 -0600 (CST) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id PAA99521 for ; Fri, 11 Jan 2002 15:57:23 -0600 (CST) From: Steve Lord Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id g0BLu3L14694; Fri, 11 Jan 2002 15:56:03 -0600 Message-Id: <200201112156.g0BLu3L14694@jen.americas.sgi.com> Date: Fri, 11 Jan 2002 15:56:03 -0600 Subject: TAKE - break dependency between xfs_support and pagebuf modules Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 827 Lines: 28 xfs_support called a pagebuf function directly, this breaks the link Date: Fri Jan 11 13:53:02 PST 2002 Workarea: jen.americas.sgi.com:/src/lord/reorg The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:109469a linux/include/linux/page_buf.h - 1.104 - remove pagebuf_daemon_wakeup linux/fs/pagebuf/page_buf.c - 1.105 - use kmem_shake_register to tell the xfs memory interface how to free memory from the pagebuf module linux/fs/pagebuf/Makefile - 1.7 - Temporary extra -I directive, will go away with next mod linux/fs/xfs_support/kmem.h - 1.6 - export kmem_shake_register and kmem_shake_deregister linux/fs/xfs_support/kmem.c - 1.14 - add kmem_shake_register and kmem_shake_deregister to register memory freeing functions we can call from here. From owner-linux-xfs@oss.sgi.com Fri Jan 11 15:14:24 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0BNEOM04092 for linux-xfs-outgoing; Fri, 11 Jan 2002 15:14:24 -0800 Received: from yog-sothoth.sgi.com (eugate.sgi.com [192.48.160.10]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0BNEJg04066 for ; Fri, 11 Jan 2002 15:14:20 -0800 Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by yog-sothoth.sgi.com (980305.SGI.8.8.8-aspam-6.2/980304.SGI-aspam-europe) via ESMTP id XAA1677679 for ; Fri, 11 Jan 2002 23:11:27 +0100 (CET) mail_from (lord@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id QAA4062710 for ; Fri, 11 Jan 2002 16:12:57 -0600 (CST) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id QAA03488 for ; Fri, 11 Jan 2002 16:12:57 -0600 (CST) From: Steve Lord Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id g0BMBbt15828; Fri, 11 Jan 2002 16:11:37 -0600 Message-Id: <200201112211.g0BMBbt15828@jen.americas.sgi.com> Date: Fri, 11 Jan 2002 16:11:37 -0600 Subject: TAKE - header file sanitization in xfs_support module Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 637 Lines: 23 More to follow. Date: Fri Jan 11 14:06:39 PST 2002 Workarea: jen.americas.sgi.com:/src/lord/reorg The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:109470a linux/fs/xfs_support/uuid.c - 1.5 linux/fs/xfs_support/uuid.h - 1.4 linux/fs/xfs_support/sv.c - 1.3 linux/fs/xfs_support/mutex.c - 1.3 linux/fs/xfs_support/mrlock.c - 1.3 linux/fs/xfs_support/move.h - 1.4 linux/fs/xfs_support/move.c - 1.3 linux/fs/xfs_support/ktrace.h - 1.3 linux/fs/xfs_support/ktrace.c - 1.3 linux/fs/xfs_support/kmem.h - 1.7 linux/fs/xfs_support/kmem.c - 1.15 linux/fs/xfs_support/debug.c - 1.4 From owner-linux-xfs@oss.sgi.com Fri Jan 11 15:36:25 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0BNaPw04483 for linux-xfs-outgoing; Fri, 11 Jan 2002 15:36:25 -0800 Received: from rj.sgi.com (rj.sgi.com [204.94.215.100]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0BNaMg04461 for ; Fri, 11 Jan 2002 15:36:22 -0800 Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by rj.sgi.com (8.11.4/8.11.4/linux-outbound_gateway-1.1) with ESMTP id g0BMaEY14894 for ; Fri, 11 Jan 2002 14:36:14 -0800 Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id QAA3987128 for ; Fri, 11 Jan 2002 16:34:58 -0600 (CST) Received: from stout.americas.sgi.com (stout.americas.sgi.com [128.162.187.5]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id QAA68961 for ; Fri, 11 Jan 2002 16:34:57 -0600 (CST) Received: by stout.americas.sgi.com (8.11.6/SGI-client-1.7) id g0BMYvZ25309; Fri, 11 Jan 2002 16:34:57 -0600 Message-Id: <200201112234.g0BMYvZ25309@stout.americas.sgi.com> Date: Fri, 11 Jan 2002 16:34:57 -0600 From: Eric Sandeen Subject: TAKE - Merge irix6.5f:irix:103241a Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 713 Lines: 18 Date: Fri Jan 11 14:31:20 PST 2002 Workarea: stout.americas.sgi.com:/localhome/eric/2.4.x-xfs/workarea-reallyclean The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:109472a linux/fs/xfs/xfs_log_recover.c - 1.217 - Merge irix6.5f:irix:103241a In xlog_recover_process_iunlinks(), use the on disk inode to explicitly find the next inode in the unlinked list instead of relying on VN_RELE() to remove the current inode from the head of the agi_unlinked bucket. The VN_RELE() method does not work in CXFS recovery because zero link count files will show up in the unlink list, but have more than one reference. Fix for bug 826858. From owner-linux-xfs@oss.sgi.com Fri Jan 11 15:41:28 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0BNfST04660 for linux-xfs-outgoing; Fri, 11 Jan 2002 15:41:28 -0800 Received: from zok.sgi.com (zok.sgi.com [204.94.215.101]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0BNfPg04638 for ; Fri, 11 Jan 2002 15:41:25 -0800 Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by zok.sgi.com (8.11.4/8.11.4/linux-outbound_gateway-1.1) with ESMTP id g0BMfIo01810 for ; Fri, 11 Jan 2002 14:41:18 -0800 Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id QAA4025490 for ; Fri, 11 Jan 2002 16:40:02 -0600 (CST) Received: from stout.americas.sgi.com (stout.americas.sgi.com [128.162.187.5]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id QAA01795 for ; Fri, 11 Jan 2002 16:40:02 -0600 (CST) Received: by stout.americas.sgi.com (8.11.6/SGI-client-1.7) id g0BMe1f25395; Fri, 11 Jan 2002 16:40:01 -0600 Message-Id: <200201112240.g0BMe1f25395@stout.americas.sgi.com> Date: Fri, 11 Jan 2002 16:40:01 -0600 From: Eric Sandeen Subject: TAKE - irix6.5f:irix:103987b Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 375 Lines: 13 Date: Fri Jan 11 14:36:26 PST 2002 Workarea: stout.americas.sgi.com:/localhome/eric/2.4.x-xfs/workarea-reallyclean The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:109475a linux/fs/xfs/xfs_inode.h - 1.151 - Merge irix6.5f:irix:103987b Move the dmi attributes into a structure. This ensures portability. From owner-linux-xfs@oss.sgi.com Fri Jan 11 15:46:21 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0BNkLB04851 for linux-xfs-outgoing; Fri, 11 Jan 2002 15:46:21 -0800 Received: from zok.sgi.com (zok.sgi.com [204.94.215.101]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0BNkDg04827 for ; Fri, 11 Jan 2002 15:46:13 -0800 Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by zok.sgi.com (8.11.4/8.11.4/linux-outbound_gateway-1.1) with ESMTP id g0BMk5o02010 for ; Fri, 11 Jan 2002 14:46:05 -0800 Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id QAA3959979 for ; Fri, 11 Jan 2002 16:44:49 -0600 (CST) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id QAA63095 for ; Fri, 11 Jan 2002 16:44:49 -0600 (CST) From: Steve Lord Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id g0BMhSr21099; Fri, 11 Jan 2002 16:43:28 -0600 Message-Id: <200201112243.g0BMhSr21099@jen.americas.sgi.com> Date: Fri, 11 Jan 2002 16:43:28 -0600 Subject: TAKE - relocate xfs_support header files Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 3613 Lines: 75 Move the xfs_support header files out to include/linux/xfs_support/ and remove the -I $TOPDIR/fs which was being used to find them before. Date: Fri Jan 11 14:40:48 PST 2002 Workarea: jen.americas.sgi.com:/src/lord/reorg The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:109476a linux/fs/xfs/Makefile - 1.131 linux/fs/xfs/linux/Makefile - 1.46 linux/fs/pagebuf/page_buf.c - 1.106 linux/fs/pagebuf/Makefile - 1.8 linux/fs/xfs/xfs.h - 1.19 linux/fs/xfs_support/uuid.c - 1.6 linux/fs/xfs_support/uuid.h 1.5 renamed to linux/include/linux/xfs_support/uuid.h 1.1 - linux/fs/xfs_support/uuid.h 1.4 Renamed to linux/include/linux/xfs_support/uuid.h linux/fs/xfs_support/types.h 1.4 renamed to linux/include/linux/xfs_support/types.h 1.1 - linux/fs/xfs_support/types.h 1.3 Renamed to linux/include/linux/xfs_support/types.h linux/fs/xfs_support/time.h 1.2 renamed to linux/include/linux/xfs_support/time.h 1.1 - linux/fs/xfs_support/time.h 1.1 Renamed to linux/include/linux/xfs_support/time.h linux/fs/xfs_support/sv.h 1.2 renamed to linux/include/linux/xfs_support/sv.h 1.1 - linux/fs/xfs_support/sv.h 1.1 Renamed to linux/include/linux/xfs_support/sv.h linux/fs/xfs_support/sv.c - 1.4 linux/fs/xfs_support/support.h 1.3 renamed to linux/include/linux/xfs_support/support.h 1.1 - linux/fs/xfs_support/support.h 1.2 Renamed to linux/include/linux/xfs_support/support.h linux/fs/xfs_support/spin.h 1.2 renamed to linux/include/linux/xfs_support/spin.h 1.1 - linux/fs/xfs_support/spin.h 1.1 Renamed to linux/include/linux/xfs_support/spin.h linux/fs/xfs_support/sema.h 1.2 renamed to linux/include/linux/xfs_support/sema.h 1.1 - linux/fs/xfs_support/sema.h 1.1 Renamed to linux/include/linux/xfs_support/sema.h linux/fs/xfs_support/qsort.h 1.2 renamed to linux/include/linux/xfs_support/qsort.h 1.1 - linux/fs/xfs_support/qsort.h 1.1 Renamed to linux/include/linux/xfs_support/qsort.h linux/fs/xfs_support/mutex.h 1.3 renamed to linux/include/linux/xfs_support/mutex.h 1.1 - linux/fs/xfs_support/mutex.h 1.2 Renamed to linux/include/linux/xfs_support/mutex.h linux/fs/xfs_support/mutex.c - 1.4 linux/fs/xfs_support/mrlock.h 1.2 renamed to linux/include/linux/xfs_support/mrlock.h 1.1 - linux/fs/xfs_support/mrlock.h 1.1 Renamed to linux/include/linux/xfs_support/mrlock.h linux/fs/xfs_support/mrlock.c - 1.4 linux/fs/xfs_support/move.h 1.5 renamed to linux/include/linux/xfs_support/move.h 1.1 - linux/fs/xfs_support/move.h 1.4 Renamed to linux/include/linux/xfs_support/move.h linux/fs/xfs_support/move.c - 1.4 linux/fs/xfs_support/ktrace.h 1.4 renamed to linux/include/linux/xfs_support/ktrace.h 1.1 - linux/fs/xfs_support/ktrace.h 1.3 Renamed to linux/include/linux/xfs_support/ktrace.h linux/fs/xfs_support/ktrace.c - 1.4 linux/fs/xfs_support/kmem.h 1.8 renamed to linux/include/linux/xfs_support/kmem.h 1.1 - linux/fs/xfs_support/kmem.h 1.7 Renamed to linux/include/linux/xfs_support/kmem.h linux/fs/xfs_support/kmem.c - 1.16 linux/fs/xfs_support/debug.h 1.2 renamed to linux/include/linux/xfs_support/debug.h 1.1 - linux/fs/xfs_support/debug.h 1.1 Renamed to linux/include/linux/xfs_support/debug.h linux/fs/xfs_support/debug.c - 1.5 linux/fs/xfs_support/atomic.h 1.3 renamed to linux/include/linux/xfs_support/atomic.h 1.1 - linux/fs/xfs_support/atomic.h 1.2 Renamed to linux/include/linux/xfs_support/atomic.h linux/fs/xfs_support/arch.h 1.4 renamed to linux/include/linux/xfs_support/arch.h 1.1 - linux/fs/xfs_support/arch.h 1.3 Renamed to linux/include/linux/xfs_support/arch.h linux/fs/xfs_support/Makefile - 1.4 From owner-linux-xfs@oss.sgi.com Fri Jan 11 16:38:53 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0C0crb05850 for linux-xfs-outgoing; Fri, 11 Jan 2002 16:38:53 -0800 Received: from rj.sgi.com (rj.sgi.com [204.94.215.100]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0C0ckg05828 for ; Fri, 11 Jan 2002 16:38:46 -0800 Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by rj.sgi.com (8.11.4/8.11.4/linux-outbound_gateway-1.1) with ESMTP id g0BNcdY18040 for ; Fri, 11 Jan 2002 15:38:39 -0800 Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id RAA4071286 for ; Fri, 11 Jan 2002 17:37:23 -0600 (CST) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id RAA02945 for ; Fri, 11 Jan 2002 17:37:23 -0600 (CST) From: Steve Lord Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id g0BNa2W05290; Fri, 11 Jan 2002 17:36:02 -0600 Message-Id: <200201112336.g0BNa2W05290@jen.americas.sgi.com> Date: Fri, 11 Jan 2002 17:36:02 -0600 Subject: TAKE - Merge pagebuf module into XFS Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 2221 Lines: 54 Pagebuf is no longer a distinct module, it is built into xfs itself. The pagebuf config option is gone. All kdb commands related to pagebuf are now in the xfsidbg module. I am done moving files around for now. If you update a tree with this do a make oldconfig ; make clean; make dep It will show up in the 2.5 tree at somepoint. Steve Date: Fri Jan 11 15:31:51 PST 2002 Workarea: jen.americas.sgi.com:/src/lord/reorg The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:109482a linux/include/linux/sysctl.h - 1.45 linux/fs/Makefile - 1.44 linux/fs/Config.in - 1.73 linux/Documentation/Configure.help - 1.122 linux/fs/xfs/xfsidbg.c - 1.167 linux/fs/xfs/Makefile - 1.132 linux/fs/xfs/linux/xfs_lrw.c - 1.120 linux/fs/xfs/linux/xfs_linux.h - 1.58 linux/fs/xfs/linux/xfs_super.c - 1.153 linux/include/linux/page_buf.h 1.105 renamed to linux/fs/xfs/pagebuf/page_buf.h 1.1 - linux/include/linux/page_buf.h 1.104 Renamed to linux/fs/xfs/pagebuf/page_buf.h linux/include/linux/page_buf_trace.h 1.11 renamed to linux/fs/xfs/pagebuf/page_buf_trace.h 1.1 - linux/include/linux/page_buf_trace.h 1.10 Renamed to linux/fs/xfs/pagebuf/page_buf_trace.h linux/kdb/modules/kdbm_pg.c - 1.47 linux/fs/pagebuf/page_buf.c 1.107 renamed to linux/fs/xfs/pagebuf/page_buf.c 1.1 - linux/fs/pagebuf/page_buf.c 1.106 Renamed to linux/fs/xfs/pagebuf/page_buf.c linux/fs/pagebuf/page_buf_locking.c 1.18 renamed to linux/fs/xfs/pagebuf/page_buf_locking.c 1.1 - linux/fs/pagebuf/page_buf_locking.c 1.17 Renamed to linux/fs/xfs/pagebuf/page_buf_locking.c linux/fs/pagebuf/avl.c 1.6 renamed to linux/fs/xfs/pagebuf/avl.c 1.1 - linux/fs/pagebuf/avl.c 1.5 Renamed to linux/fs/xfs/pagebuf/avl.c linux/fs/pagebuf/Makefile 1.9 renamed to linux/fs/xfs/pagebuf/Makefile 1.1 - linux/fs/pagebuf/Makefile 1.8 Renamed to linux/fs/xfs/pagebuf/Makefile linux/fs/pagebuf/page_buf_io.c 1.107 renamed to linux/fs/xfs/pagebuf/page_buf_io.c 1.1 - linux/fs/pagebuf/page_buf_io.c 1.106 Renamed to linux/fs/xfs/pagebuf/page_buf_io.c linux/fs/pagebuf/Makefile.in 1.4 renamed to linux/fs/xfs/pagebuf/Makefile.in 1.1 - linux/fs/pagebuf/Makefile.in 1.3 Renamed to linux/fs/xfs/pagebuf/Makefile.in From owner-linux-xfs@oss.sgi.com Fri Jan 11 16:48:54 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0C0ms906109 for linux-xfs-outgoing; Fri, 11 Jan 2002 16:48:54 -0800 Received: from zok.sgi.com (zok.sgi.com [204.94.215.101]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0C0mpg06087 for ; Fri, 11 Jan 2002 16:48:51 -0800 Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by zok.sgi.com (8.11.4/8.11.4/linux-outbound_gateway-1.1) with ESMTP id g0BNmio05051 for ; Fri, 11 Jan 2002 15:48:44 -0800 Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id RAA4069250 for ; Fri, 11 Jan 2002 17:47:28 -0600 (CST) Received: from stout.americas.sgi.com (stout.americas.sgi.com [128.162.187.5]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id RAA09435 for ; Fri, 11 Jan 2002 17:47:28 -0600 (CST) Received: by stout.americas.sgi.com (8.11.6/SGI-client-1.7) id g0BNlSq26652; Fri, 11 Jan 2002 17:47:28 -0600 Message-Id: <200201112347.g0BNlSq26652@stout.americas.sgi.com> Date: Fri, 11 Jan 2002 17:47:28 -0600 From: Eric Sandeen Subject: TAKE - Merge irix6.5f:irix:106406b Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 482 Lines: 16 Date: Fri Jan 11 15:43:26 PST 2002 Workarea: stout.americas.sgi.com:/localhome/eric/2.4.x-xfs/workarea-reallyclean The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:109484a linux/fs/xfs/xfs_ialloc.c - 1.151 linux/fs/xfs/xfs_inode.c - 1.323 - Merge irix6.5f:irix:106406b Add detailed messages to error cases that will likely result in the shutdown of the filesystem. Debug builds only. Fix for bug 805830. From owner-linux-xfs@oss.sgi.com Fri Jan 11 17:33:08 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0C1X8j06779 for linux-xfs-outgoing; Fri, 11 Jan 2002 17:33:08 -0800 Received: from coredump.sh0n.net (qmailremote@CPEdeadbeef0000.cpe.net.cable.rogers.com [24.100.234.67]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0C1X6g06757 for ; Fri, 11 Jan 2002 17:33:06 -0800 Received: (qmail 1010 invoked from network); 12 Jan 2002 00:33:51 -0000 Received: from coredump.sh0n.net (sh0n@24.100.234.67) by coredump.sh0n.net with SMTP; 12 Jan 2002 00:33:51 -0000 Subject: XFS Testing ongoing... From: Shawn Starr To: linux-xfs@oss.sgi.com Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/1.0.1.99 (Preview Release) Date: 11 Jan 2002 19:33:49 -0500 Message-Id: <1010795631.972.1.camel@coredump> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 237 Lines: 9 blowup-xfs still reunning (since 3AM now 7:30PM) 278 root 18 0 1024 996 372 R 32.3 1.6 953:15 blowup-xfs I dont think it will find any corruption :-) We can now move on with applying riel's rmap-11a to our -sfx tree. From owner-linux-xfs@oss.sgi.com Fri Jan 11 22:47:37 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0C6lbB11137 for linux-xfs-outgoing; Fri, 11 Jan 2002 22:47:37 -0800 Received: from pinga.salk.edu (pinga.salk.edu [192.31.153.187]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0C6lUg11115 for ; Fri, 11 Jan 2002 22:47:30 -0800 Received: from muk (muk.dyndns.org [24.30.128.214]) by pinga.salk.edu (8.11.6/8.11.6) with SMTP id g0C5lQd01203; Fri, 11 Jan 2002 21:47:26 -0800 Date: Fri, 11 Jan 2002 21:47:15 -0800 From: David Chambers To: linux-xfs@oss.sgi.com Subject: Possible problem: 2.4.17cvs oops. Message-Id: <20020111214715.4e67c0f9.davidc@ccmi.salk.edu> X-Mailer: Sylpheed version 0.6.6claws45 (GTK+ 1.2.10; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 3603 Lines: 55 Hi! I do not know whether any of the following is of any use, and no core file was generated, but here goes: System is a Tyan motherboard, dual PIII, VIA chipset. Running 1 x Seagate disk on hda, 8 x Maxtor Diamondmax 80Gb as RAID 5 controlled by a 3ware 7850 card. NIC is 3com 3C905B. 1Gb RAM. All partitions are XFS. Red Hat 7.2, Kernel 2.4.17 from the XFS 2.4.17-cvs tree on Jan. 9th. 3c905 is a module, 3w-xxxx is also a module. During testing, copying about 60GB from an NFS mounted filesystem to the 3ware array I get the messages appended below. I am a total newbie at kernel diagnostics. I do not know what to do to proceed with this! Is this report of any use?? What can/should I do to be more helpful? - David In syslog: (the "memory shortage" occurs whether 3c905 is compiled into the kernel or is a module. I'm a little suspicious of it!) Jan 11 15:51:20 kehaar kernel: eth0: memory shortage Jan 11 16:02:41 kehaar kernel: Unable to handle kernel NULL pointer dereference at virtual address 00000008 Jan 11 16:02:41 kehaar kernel: printing eip: Jan 11 16:02:41 kehaar kernel: c01a0014 Jan 11 16:02:41 kehaar kernel: *pde = 00000000 Jan 11 16:02:41 kehaar kernel: Oops: 0000 Jan 11 16:02:41 kehaar kernel: CPU: 0 Jan 11 16:02:41 kehaar kernel: EIP: 0010:[xfs_da_do_buf+1476/1808] Not tainted Jan 11 16:02:41 kehaar kernel: EIP: 0010:[] Not tainted Jan 11 16:02:41 kehaar kernel: EFLAGS: 00010046 Jan 11 16:02:41 kehaar kernel: eax: 00000000 ebx: 00000000 ecx: e2ea2ec0 edx: 00000000 Jan 11 16:02:41 kehaar kernel: esi: 00000000 edi: 00000001 ebp: 00000000 esp: f6ed1a68 Jan 11 16:02:41 kehaar kernel: ds: 0018 es: 0018 ss: 0018 Jan 11 16:02:41 kehaar kernel: Process cp (pid: 1470, stackpage=f6ed1000) Jan 11 16:02:41 kehaar kernel: Stack: 00000035 00000000 0000001c 00000000 00000000 00000000 00000001 00000001 Jan 11 16:02:41 kehaar kernel: 00000000 f7765000 1a88fc28 00000000 f6ed1ad8 00000000 00000000 00000000 Jan 11 16:02:41 kehaar kernel: 00000000 00000001 03511f85 00000000 c36eb740 e16815dc c01b4dab c36eb740 Jan 11 16:02:41 kehaar kernel: Call Trace: [xfs_iget_core+1595/1616] [xfs_da_read_buf+62/80] [xfs_dir2_block_addname+93/2160] [xfs_dir2_block_addname+93/2160] [xfs_trans_iget+215/288] Jan 11 16:02:41 kehaar kernel: Call Trace: [] [] [] [] [] Jan 11 16:02:41 kehaar kernel: [xfs_dir2_isblock+30/112] [xfs_dir2_createname+242/304] [xfs_create+1159/2720] [avl_delete+114/128] [pagebuf_rele+101/128] [linvfs_common_cr+186/592] Jan 11 16:02:41 kehaar kernel: [] [] [] [] [] [] Jan 11 16:02:41 kehaar kernel: [xfs_dir2_block_lookup_int+399/416] [xfs_dir2_block_lookup+27/176] [xfs_dir2_lookup+217/320] [] [xfs_dir_lookup_int+186/704] [linvfs_create+24/32] Jan 11 16:02:41 kehaar kernel: [] [] [] [] [] [] Jan 11 16:02:41 kehaar kernel: [vfs_create+266/352] [lookup_hash+141/192] [open_namei+351/1600] [dentry_open+230/400] [dput+65/336] [filp_open+54/96] Jan 11 16:02:41 kehaar kernel: [] [] [] [] [] [] Jan 11 16:02:41 kehaar kernel: [sys_open+52/192] [system_call+51/56] Jan 11 16:02:41 kehaar kernel: [] [] Jan 11 16:02:41 kehaar kernel: Jan 11 16:02:41 kehaar kernel: Code: 8b 53 08 0f b7 42 08 86 c4 0f b7 c0 3d be fe 00 00 74 59 3d Jan 11 21:27:15 kehaar sshd(pam_unix)[3210]: session opened for user davidc by (uid=0) From owner-linux-xfs@oss.sgi.com Sat Jan 12 10:21:54 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0CILs820517 for linux-xfs-outgoing; Sat, 12 Jan 2002 10:21:54 -0800 Received: from blipvert.blank.org (blipvert.blank.org [216.112.239.86]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0CILjg20494 for ; Sat, 12 Jan 2002 10:21:45 -0800 Received: (qmail 7825 invoked by uid 500); 12 Jan 2002 17:21:44 -0000 Date: Sat, 12 Jan 2002 12:21:44 -0500 From: "Nathan J. Mehl" To: linux-xfs@oss.sgi.com Subject: things to do in brooklyn when your filesystem is dead Message-ID: <20020112122144.R15376@blank.org> 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.2.5.1i Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 3010 Lines: 66 This may fall under the heading of "Doctor, it hurts when I do this", but here's trying... Per Eric Sandeen's take a few days ago, mkfs.xfs was failing to properly clear the signatures of any underlying filesystems on the partition being mkfs'ed, causing gnu parted to fail to recognize an XFS partition as such, in turn causing Anaconda's upgrader to fail. The primary partition on my workstation was in exactly that state: parted was recognizing it as a linux swap partition, due to the signature of a swap file ("SWAPSPACE2" at offset 4086) still being there. In an attempt to clear this, I did the following: dd if=/dev/hda5 of=outfile bs=4096 count=1 I then ran ghex (the gnome hex editor) on "outfile", and changed "SWAPSPACE2" to "SW4PSP4C32". I then saved the file to a floppy, booted off of the xfs linux rescue cdrom, mounted the floppy, and wrote those four kilobytes back to the partition: dd if=outfile of=/tmp/hda5 bs=4096 This appeared to work, and the partition survived an xfs_repair with only a few small errors. Unfortunatly, parted still believed the partition to be swap, so I repeated the process again, this time zeroing out the last 10 bytes completely. After that was done, parted recognized the partition as XFS, and an xfs_repair run on the partition completely cleanly, with only one notice about rebuilding the inode for directory 128. I then rebooted into the XFS installer, and attempted an upgrade, which failed with a "partition out of space" error when it tried to rebuild the RPM database. As the partition was a 70gb one at less than 50% utilization, this seemed unlikely, so I rebooted back into the rescue image and tried to run xfs_repair on it again. At this point, all hell broke loose: xfs_repair could not find the first superblock, and after finding the second superblock, it failed at the step of trying to zero out the log, claiming that it could not find the log header, or words to that effect. At this point, I am stymied. xfs_repair will not progress beyond the log-clearing step. "xfs_repair -n" reveals thousands of inode errors; enough that I haven't had the patience to let it scroll through to the end. (I gave up after about 4 minutes.) I'm prepared to assume that this FS is a total loss, and I expext that I've broken something badly by restoring an out-of-date (even if only by minutes) first 4k of the partition. But just in case, I'm throwing it to the list -- does anybody know any tricks for persuading xfs_repair to cope with these sorts of situations? The manpage makes tantalizing reference to "subopts", but the only one mentioned is "assume_xfs", which probably isn't helpful in this case. Many thanks in advance, -n ------------------------------------------------------------ "You don't qualify as the typical male snakebite victim: you weren't drinking, you don't have any tattoos, and you have all your teeth." ---------------------------------------------------- From owner-linux-xfs@oss.sgi.com Sat Jan 12 14:31:26 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0CMVQd23518 for linux-xfs-outgoing; Sat, 12 Jan 2002 14:31:26 -0800 Received: from awacs.dhs.org (node10450.a2000.nl [24.132.4.80]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0CMVLg23496 for ; Sat, 12 Jan 2002 14:31:22 -0800 Received: (from p@localhost) by awacs.dhs.org (8.11.0/8.9.3) id g0CLVG619517 for linux-xfs@oss.sgi.com; Sat, 12 Jan 2002 22:31:16 +0100 Date: Sat, 12 Jan 2002 22:31:16 +0100 From: Pascal Haakmat To: linux-xfs@oss.sgi.com Subject: Re: Oops with 2.4.16 [update] Message-ID: <20020112223116.A19511@awacs.dhs.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 963 Lines: 24 Pascal Haakmat wrote: [snip] > In any case the problem does not seem to be with XFS; also, Andre Hedrick > has been quite vocal on lkml about problems with the block layer/IDE/ATA > (I think) support in the 2.4 kernel. > > I will see if the machine survives the 160 cp processes test tonight. If > it does, then I would consider the problem solved. Meanwhile thanks for all > your help. The machine passed the test with flying colors. It went through 987 iterations of Adrian's script with 160 cp processes for a period of 24 hours without a single error. These results, again, after applying Andre Hedrick's IDE patch: without this patch I get "lost interrupt" messages, severe filesystem corruption, and eventually the entire machine goes down. So I've restored from backups. Next thing: to vote for the inclusion of Andre's patches into 2.4 on lkml... PS: In my last mail I referred to "Andre's script" when I meant "Adrian's script". Sorry about that. From owner-linux-xfs@oss.sgi.com Sat Jan 12 16:45:25 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0D0jPn25597 for linux-xfs-outgoing; Sat, 12 Jan 2002 16:45:25 -0800 Received: from mailout05.sul.t-online.com (mailout05.sul.t-online.com [194.25.134.82]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0D0jLg25571 for ; Sat, 12 Jan 2002 16:45:22 -0800 Received: from fwd04.sul.t-online.de by mailout05.sul.t-online.com with smtp id 16PXd4-0006s0-09; Sun, 13 Jan 2002 00:32:02 +0100 Received: from tower (340024412816-0001@[217.230.3.184]) by fwd04.sul.t-online.com with esmtp id 16PXd3-0zh0IiC; Sun, 13 Jan 2002 00:32:01 +0100 Content-Type: text/plain; charset="iso-8859-1" From: Hasch@t-online.de (Juergen Hasch) To: Steve Lord Subject: Re: TAKE - Merge pagebuf module into XFS Date: Sun, 13 Jan 2002 00:33:06 +0100 X-Mailer: KMail [version 1.3.8] References: <200201112336.g0BNa2W05290@jen.americas.sgi.com> In-Reply-To: <200201112336.g0BNa2W05290@jen.americas.sgi.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Cc: linux-xfs@oss.sgi.com Message-Id: <200201130033.06345.hasch@t-online.de> X-Sender: 340024412816-0001@t-dialin.net Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 575 Lines: 18 Hi Steve, Am Samstag, 12. Januar 2002 00:36 schrieb Steve Lord: > Pagebuf is no longer a distinct module, it is built into xfs itself. The > pagebuf config option is gone. All kdb commands related to pagebuf are > now in the xfsidbg module. XFS won't build as a module on my machine after the change. Adding "obj-m := $(O_TARGET)" to the Makefile in fs/xfs/pagebuf fixes this for me. However I still get the file /lib/modules/2.4.17-xfs/kernel/fs/xfs/pagebuf/pagebuf.o after "make modules_install", which isn't used afterwards (at least lsmod doesn't show). ...Juergen From owner-linux-xfs@oss.sgi.com Sun Jan 13 05:48:05 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0DDm5508331 for linux-xfs-outgoing; Sun, 13 Jan 2002 05:48:05 -0800 Received: from deliverator.sgi.com (deliverator.sgi.com [204.94.214.10]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0DDlsg08304 for ; Sun, 13 Jan 2002 05:47:54 -0800 Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id EAA23804 for ; Sun, 13 Jan 2002 04:43:31 -0800 (PST) mail_from (lord@sgi.com) Received: from tulip-e185.americas.sgi.com (tulip-e185.americas.sgi.com [128.162.185.208]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id GAA4047928; Sun, 13 Jan 2002 06:46:35 -0600 (CST) Received: from sgi.com (VcH3JichYRs3xBGyi9TrInFos0IAOKiz@cf-vpn-sw-corp-64-12.corp.sgi.com [134.15.64.12]) by tulip-e185.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.7) with ESMTP id GAA03062; Sun, 13 Jan 2002 06:46:33 -0600 (CST) Message-ID: <3C4182B8.8070700@sgi.com> Date: Sun, 13 Jan 2002 06:51:04 -0600 From: Stephen Lord User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.6) Gecko/20011120 X-Accept-Language: en-us MIME-Version: 1.0 To: "Nathan J. Mehl" CC: linux-xfs@oss.sgi.com Subject: Re: things to do in brooklyn when your filesystem is dead References: <20020112122144.R15376@blank.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 3806 Lines: 90 Nathan J. Mehl wrote: >This may fall under the heading of "Doctor, it hurts when I do this", >but here's trying... > > >Per Eric Sandeen's take a few days ago, mkfs.xfs was failing to >properly clear the signatures of any underlying filesystems on the >partition being mkfs'ed, causing gnu parted to fail to recognize an >XFS partition as such, in turn causing Anaconda's upgrader to fail. > >The primary partition on my workstation was in exactly that state: >parted was recognizing it as a linux swap partition, due to the >signature of a swap file ("SWAPSPACE2" at offset 4086) still being >there. > >In an attempt to clear this, I did the following: > > dd if=/dev/hda5 of=outfile bs=4096 count=1 > >I then ran ghex (the gnome hex editor) on "outfile", and changed >"SWAPSPACE2" to "SW4PSP4C32". I then saved the file to a floppy, >booted off of the xfs linux rescue cdrom, mounted the floppy, and >wrote those four kilobytes back to the partition: > > dd if=outfile of=/tmp/hda5 bs=4096 > >This appeared to work, and the partition survived an xfs_repair with >only a few small errors. Unfortunatly, parted still believed the >partition to be swap, so I repeated the process again, this time >zeroing out the last 10 bytes completely. After that was done, parted >recognized the partition as XFS, and an xfs_repair run on the >partition completely cleanly, with only one notice about rebuilding >the inode for directory 128. > Well, this is the root inode, and if it had to do surgery on it, repair may have disconnected all your other inodes. Now, it should put them in lost+found, and in theory you can work out which one is which and rename them back again. Unless repair is nice and gives you whole subtrees in there this is not exactly a workable solution. What did repair say about your inode? Also, I assume all the editing of the first 4K was done with the filesystem offline, in which case if you did really just overwrite those 10 bytes, all should have been well. I cannot see how XFS can be using that part of the disk. If you wrote the 4K whilst the filesystem was online then yes, it is probably toast. Steve > > >I then rebooted into the XFS installer, and attempted an upgrade, >which failed with a "partition out of space" error when it tried to >rebuild the RPM database. As the partition was a 70gb one at less >than 50% utilization, this seemed unlikely, so I rebooted back into >the rescue image and tried to run xfs_repair on it again. At this >point, all hell broke loose: xfs_repair could not find the first >superblock, and after finding the second superblock, it failed at the >step of trying to zero out the log, claiming that it could not find >the log header, or words to that effect. > >At this point, I am stymied. xfs_repair will not progress beyond the >log-clearing step. "xfs_repair -n" reveals thousands of inode errors; >enough that I haven't had the patience to let it scroll through to the >end. (I gave up after about 4 minutes.) > >I'm prepared to assume that this FS is a total loss, and I expext that >I've broken something badly by restoring an out-of-date (even if only >by minutes) first 4k of the partition. But just in case, I'm throwing >it to the list -- does anybody know any tricks for persuading >xfs_repair to cope with these sorts of situations? The manpage makes >tantalizing reference to "subopts", but the only one mentioned is >"assume_xfs", which probably isn't helpful in this case. > >Many thanks in advance, > >-n > >------------------------------------------------------------ >"You don't qualify as the typical male snakebite victim: you weren't drinking, >you don't have any tattoos, and you have all your teeth." >---------------------------------------------------- > From owner-linux-xfs@oss.sgi.com Sun Jan 13 06:01:08 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0DE18D08676 for linux-xfs-outgoing; Sun, 13 Jan 2002 06:01:08 -0800 Received: from pneumatic-tube.sgi.com (pneumatic-tube.sgi.com [204.94.214.22]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0DE15g08653 for ; Sun, 13 Jan 2002 06:01:05 -0800 Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id FAA07961 for ; Sun, 13 Jan 2002 05:01:46 -0800 (PST) mail_from (lord@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id GAA4051382 for ; Sun, 13 Jan 2002 06:59:45 -0600 (CST) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id GAA30387 for ; Sun, 13 Jan 2002 06:59:45 -0600 (CST) From: Steve Lord Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id g0DCw9w28666; Sun, 13 Jan 2002 06:58:09 -0600 Message-Id: <200201131258.g0DCw9w28666@jen.americas.sgi.com> Date: Sun, 13 Jan 2002 06:58:09 -0600 Subject: TAKE - fix xfs module build Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 306 Lines: 12 Date: Sun Jan 13 04:56:17 PST 2002 Workarea: jen.americas.sgi.com:/src/lord/xfs-linux.2.4 The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:109501a linux/fs/xfs/pagebuf/Makefile - 1.2 - fix xfs module build now that pagebuf is compiled in From owner-linux-xfs@oss.sgi.com Sun Jan 13 11:08:01 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0DJ81m12886 for linux-xfs-outgoing; Sun, 13 Jan 2002 11:08:01 -0800 Received: from ADSL-Bergs.RZ.RWTH-Aachen.DE (adsl-bergs.rz.RWTH-Aachen.DE [137.226.80.218]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0DJ7vg12864 for ; Sun, 13 Jan 2002 11:07:57 -0800 Received: from [192.168.1.2] (helo=ralf) by ADSL-Bergs.RZ.RWTH-Aachen.DE with smtp (Exim 3.12 #1) id 16Pp2q-0006Yc-00; Sun, 13 Jan 2002 19:07:48 +0100 From: "Ralf G. R. Bergs" To: "linux-xfs@oss.sgi.com" Cc: "Stephen Lord" Date: Sun, 13 Jan 2002 19:07:47 +0100 Reply-To: "Ralf G. R. Bergs" X-Mailer: PMMail 2000 Professional (2.20.2380) For Windows 2000 (5.0.2195;2) In-Reply-To: <3C3EE642.8060109@sgi.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Subject: Re: Partition un(mount|repairable) Message-Id: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 845 Lines: 21 On Fri, 11 Jan 2002 07:18:58 -0600, Stephen Lord wrote: > o The directory corruption which Ralf Bergs has been fighting turns out >to be hardware, > they reproduced corruption under ext2 Yup, unfortunately I must confirm this. It turned out that the RAID itself delivers corrupt data, and that it's not a filesystem issue. We've already ordered a new cable to make sure it's not a cabling issue. As soon as we have working hardware we will have another go at migrating to XFS. Thanks to Steve, Eric, and the others for their great work and support. -- Verkaufe Original-BMW-Raeder: L I N U X .~. http://adsl-bergs.rz.rwth-aachen.de/~rabe The Choice /V\ of a GNU /( )\ Generation ^^-^^ From owner-linux-xfs@oss.sgi.com Sun Jan 13 12:17:11 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0DKHB813942 for linux-xfs-outgoing; Sun, 13 Jan 2002 12:17:11 -0800 Received: from blipvert.blank.org (blipvert.blank.org [216.112.239.86]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0DKH5g13919 for ; Sun, 13 Jan 2002 12:17:05 -0800 Received: (qmail 17701 invoked by uid 500); 13 Jan 2002 19:17:00 -0000 Date: Sun, 13 Jan 2002 14:17:00 -0500 From: "Nathan J. Mehl" To: Stephen Lord Cc: linux-xfs@oss.sgi.com Subject: Re: things to do in brooklyn when your filesystem is dead Message-ID: <20020113141700.W15376@blank.org> Mail-Followup-To: Stephen Lord , linux-xfs@oss.sgi.com References: <20020112122144.R15376@blank.org> <3C4182B8.8070700@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: <3C4182B8.8070700@sgi.com>; from lord@sgi.com on Sun, Jan 13, 2002 at 06:51:04AM -0600 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 1561 Lines: 34 In the immortal words of Stephen Lord (lord@sgi.com): > >recognized the partition as XFS, and an xfs_repair run on the > >partition completely cleanly, with only one notice about rebuilding > >the inode for directory 128. > > > > Well, this is the root inode, and if it had to do surgery on it, > repair may have disconnected all your other inodes. Now, it should > put them in lost+found, and in theory you can work out which one is > which and rename them back again. Unless repair is nice and gives > you whole subtrees in there this is not exactly a workable solution. > > What did repair say about your inode? Hm, unfortunatly I did not keep a log of xfs_repair's output at that time. I'll see if I can regenerate it. > Also, I assume all the editing of the first 4K was done with the > filesystem offline, in which case if you did really just overwrite > those 10 bytes, all should have been well. I cannot see how XFS can > be using that part of the disk. If you wrote the 4K whilst the > filesystem was online then yes, it is probably toast. The chunk was _written_ while the fs was offline, but it was _read_ while the fs was online, which in crystal hindsight means that offset 0 through 4085 was restored to an earlier and probably inconsistant state. ------------------------------------------------------ "Television is going to change the world; it's got everything you need: sight, sound, motion and stupid white men." (--Nolanda Hill) ---------------------------------------------- From owner-linux-xfs@oss.sgi.com Sun Jan 13 17:36:14 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0E1aEl20310 for linux-xfs-outgoing; Sun, 13 Jan 2002 17:36:14 -0800 Received: from pneumatic-tube.sgi.com (pneumatic-tube.sgi.com [204.94.214.22]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0E1a8g20288 for ; Sun, 13 Jan 2002 17:36:08 -0800 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via SMTP id QAA05550 for ; Sun, 13 Jan 2002 16:36:48 -0800 (PST) mail_from (nathans@wobbly.melbourne.sgi.com) Received: from wobbly.melbourne.sgi.com (wobbly.melbourne.sgi.com [134.14.55.135]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id LAA07610; Mon, 14 Jan 2002 11:34:47 +1100 Received: (from nathans@localhost) by wobbly.melbourne.sgi.com (SGI-8.9.3/8.9.3) id LAA25256; Mon, 14 Jan 2002 11:34:45 +1100 (AEDT) Date: Mon, 14 Jan 2002 11:34:45 +1100 From: Nathan Scott To: "Nathan J. Mehl" Cc: linux-xfs@oss.sgi.com Subject: Re: things to do in brooklyn when your filesystem is dead Message-ID: <20020114113445.D24972@wobbly.melbourne.sgi.com> References: <20020112122144.R15376@blank.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20020112122144.R15376@blank.org>; from memory-xfs@blank.org on Sat, Jan 12, 2002 at 12:21:44PM -0500 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 1425 Lines: 44 hi, On Sat, Jan 12, 2002 at 12:21:44PM -0500, Nathan J. Mehl wrote: > ... > At this point, I am stymied. xfs_repair will not progress beyond the > log-clearing step. Can you tell me the exact error message you see? Is it: "xlog_find_tail returned error X"? If so, I think this is a recently-introduced repair bug - I'll check in a fix shortly & you should be able to proceed on with xfs_repair. thanks. > "xfs_repair -n" reveals thousands of inode errors; > enough that I haven't had the patience to let it scroll through to the > end. (I gave up after about 4 minutes.) > > I'm prepared to assume that this FS is a total loss, and I expext that > I've broken something badly by restoring an out-of-date (even if only > by minutes) first 4k of the partition. But just in case, I'm throwing > it to the list -- does anybody know any tricks for persuading > xfs_repair to cope with these sorts of situations? The manpage makes > tantalizing reference to "subopts", but the only one mentioned is > "assume_xfs", which probably isn't helpful in this case. > > Many thanks in advance, > > -n > > ------------------------------------------------------------ > "You don't qualify as the typical male snakebite victim: you weren't drinking, > you don't have any tattoos, and you have all your teeth." > ---------------------------------------------------- > -- Nathan From owner-linux-xfs@oss.sgi.com Sun Jan 13 19:07:16 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0E37GI21684 for linux-xfs-outgoing; Sun, 13 Jan 2002 19:07:16 -0800 Received: from 213.160.207.130 ([213.160.207.130]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0E37Cg21662 for ; Sun, 13 Jan 2002 19:07:13 -0800 Received: (qmail 1683 invoked from network); 13 Jan 2002 20:58:26 -0000 Received: from 213-97-238-169.uc.nombres.ttd.es (HELO none) (213.97.238.169) by dtu.co.uk with SMTP; 13 Jan 2002 20:58:26 -0000 Message-ID: <94942212104$83490544$20357775@helmut> From: "schneckchen@brisant-mail.com" To: "linux-xfs@oss.sgi.com" Subject: Ich bin's Date: Sun, 13 Jan 2002 21:03:50 +0000 Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 767 Lines: 22 Hallo, ....danke für Dein Mail. Ist schon `ne Weile her. Nun ja, bist Du immer noch allein? Einsam? Ich auch. Obwohl Freunde von mir sagen, dass ich recht gut aussehe, fehlt mir doch noch ein netter Partner zum Reden, Lieben und Kuscheln. Vielleicht bist Du es. Dein Alter und Dein Aussehen ist für mich nicht so wichtig. Im Moment spanne ich einige Tage aus, lasse die Seele baumeln-, versuche nach Enttäuschungen mein Leben neu zu ordnen. Ich habe mich bei www.fairway-contacts.com eingetragen. Du findest ein Foto und meine Wohnungsanschrift mit normaler Telefonnummer unter der Rubrik "Sie sucht Ihn". Wenn ich Dir gefallen sollte, rufe mich doch einfach einmal an. Ich freue mich auf ein Gespräch mit Dir. Bis bald Dein Schneckchen From owner-linux-xfs@oss.sgi.com Sun Jan 13 19:22:43 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0E3Mhi22025 for linux-xfs-outgoing; Sun, 13 Jan 2002 19:22:43 -0800 Received: from deliverator.sgi.com (deliverator.sgi.com [204.94.214.10]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0E3Mdg22003 for ; Sun, 13 Jan 2002 19:22:39 -0800 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.55.149]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id SAA24260 for ; Sun, 13 Jan 2002 18:18:15 -0800 (PST) mail_from (nathans@snort.melbourne.sgi.com) Received: (from nathans@localhost) by snort.melbourne.sgi.com (SGI-8.9.3/8.9.3) id NAA21965 for linux-xfs@oss.sgi.com; Mon, 14 Jan 2002 13:21:18 +1100 (EST) Date: Mon, 14 Jan 2002 13:21:18 +1100 (EST) From: Nathan Scott Message-Id: <200201140221.NAA21965@snort.melbourne.sgi.com> To: linux-xfs@oss.sgi.com Subject: TAKE - repair Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 906 Lines: 31 This should fix the problem with repair exiting when unable to find the log head/tail. Nathan J. Mehl wrote: >... all hell broke loose: xfs_repair could not find the first >superblock, and after finding the second superblock, it failed at the >step of trying to zero out the log, claiming that it could not find >the log header, or words to that effect. Date: Sun Jan 13 18:14:31 PST 2002 Workarea: snort.melbourne.sgi.com:/home/nathans/xfs-cmds The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/xfs-cmds Modid: xfs-cmds:slinx:109505a xfsprogs/doc/CHANGES - 1.51 - document change to log zeroing logic in xfs_repair. xfsprogs/repair/phase2.c - 1.3 - if the log is corrupted and we can't find the head, don't exit - just proceed on with zeroing it. xfstests/tools/README.auto-qa - 1.5 xfstests/tools/auto-qa - 1.19 - pagebuf is no longer a separate module. From owner-linux-xfs@oss.sgi.com Sun Jan 13 23:03:03 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0E733v24970 for linux-xfs-outgoing; Sun, 13 Jan 2002 23:03:03 -0800 Received: from coredump.sh0n.net (qmailremote@CPEdeadbeef0000.cpe.net.cable.rogers.com [24.100.234.67]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0E72Wg24941 for ; Sun, 13 Jan 2002 23:02:50 -0800 Received: (qmail 678 invoked from network); 14 Jan 2002 06:03:19 -0000 Received: from coredump.sh0n.net (sh0n@24.100.234.67) by coredump.sh0n.net with SMTP; 14 Jan 2002 06:03:19 -0000 Date: Mon, 14 Jan 2002 01:03:18 -0500 (EST) From: Shawn To: Nathan Scott cc: linux-xfs@oss.sgi.com Subject: XFS CVS Server.... In-Reply-To: <200201140221.NAA21965@snort.melbourne.sgi.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 34 Lines: 6 Uhm... CVS is dead ;-) Shawn. From owner-linux-xfs@oss.sgi.com Sun Jan 13 23:18:13 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0E7IDA25359 for linux-xfs-outgoing; Sun, 13 Jan 2002 23:18:13 -0800 Received: from mx0.gmx.net (mx0.gmx.net [213.165.64.100]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0E7I0g25332 for ; Sun, 13 Jan 2002 23:18:00 -0800 Received: (qmail 8006 invoked by uid 0); 14 Jan 2002 06:17:52 -0000 Date: Mon, 14 Jan 2002 07:17:52 +0100 (MET) From: Adam Hunt To: linux-xfs@oss.sgi.com MIME-Version: 1.0 Subject: secure delete X-Authenticated-Sender: #0008562179@gmx.net X-Authenticated-IP: [12.224.84.102] Message-ID: <8692.1010989072@www25.gmx.net> X-Mailer: WWW-Mail 1.5 (Global Message Exchange) X-Flags: 0001 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 571 Lines: 22 How difficult would it be to add some form of secure deletion to XFS? What I would like to have is the ability to mark a file or directory for secure deletion via a attribute. Three levels of security would be nice. 1) None, just your usual unlink. 2) Simple, unlink and one time overwrite (with zeros or random data). 3) Ultraparanoid DoD certified secure delete, unlink and multipass overwrite. Any thoughts? More info on secure deletion can be found at www.cs.auckland.ac.nz/~pgut001/secure_del.html --adam -- Sent through GMX FreeMail - http://www.gmx.net From owner-linux-xfs@oss.sgi.com Sun Jan 13 23:32:54 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0E7Wsi25712 for linux-xfs-outgoing; Sun, 13 Jan 2002 23:32:54 -0800 Received: from sunny.pacific.net.au (sunny-legacy.pacific.net.au [210.23.129.40]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0E7Wjg25690 for ; Sun, 13 Jan 2002 23:32:46 -0800 Received: from wisma.pacific.net.au (wisma.pacific.net.au [210.23.129.72]) by sunny.pacific.net.au with ESMTP id g0E6WfZM017401 for ; Mon, 14 Jan 2002 17:32:41 +1100 (EST) Received: from jpc.local (ppp3.dyn148.pacific.net.au [210.23.148.3]) by wisma.pacific.net.au with ESMTP id RAA19996 for ; Mon, 14 Jan 2002 17:32:40 +1100 (EST) Received: (from jason@localhost) by jpc.local (8.9.3/8.9.3/Debian 8.9.3-21) id RAA02761; Mon, 14 Jan 2002 17:32:38 +1100 From: Jason White MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15426.31621.557586.351483@jpc.local> Date: Mon, 14 Jan 2002 17:32:37 +1100 To: linux-xfs@oss.sgi.com Subject: Re: secure delete In-Reply-To: <8692.1010989072@www25.gmx.net> References: <8692.1010989072@www25.gmx.net> X-Mailer: VM 6.76 under Emacs 20.7.2 Reply-To: Jason White Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 299 Lines: 6 For the moment you could probably achieve it with a small script to test the attribute on each specified file, and if secure deletion is required, it could perform the overwrite operations. The main problem is how to ensure that the data are actually written to disk the specified number of times. From owner-linux-xfs@oss.sgi.com Mon Jan 14 00:20:09 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0E8K9i26508 for linux-xfs-outgoing; Mon, 14 Jan 2002 00:20:09 -0800 Received: from zok.sgi.com (zok.sgi.com [204.94.215.101]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0E8Jmg26471 for ; Mon, 14 Jan 2002 00:19:51 -0800 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.55.149]) by zok.sgi.com (8.11.4/8.11.4/linux-outbound_gateway-1.1) with ESMTP id g0E7Jeo24396 for ; Sun, 13 Jan 2002 23:19:40 -0800 Received: (from nathans@localhost) by snort.melbourne.sgi.com (SGI-8.9.3/8.9.3) id SAA76460 for linux-xfs@oss.sgi.com; Mon, 14 Jan 2002 18:18:22 +1100 (EST) Date: Mon, 14 Jan 2002 18:18:22 +1100 (EST) From: Nathan Scott Message-Id: <200201140718.SAA76460@snort.melbourne.sgi.com> To: linux-xfs@oss.sgi.com Subject: TAKE - kmem fixups Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 1398 Lines: 44 Tidy up the XFS quota manager low memory handling using Steve's shiny new kmem_shake_register/kmem_shake_deregister interfaces. [Shaun - not sure what the CVS problem is. One of the guys in the states will look at it once they're up & about I'm sure - I'm about to head home for the day & don't know much about the oss CVS tree setup anyways]. cheers. Date: Sun Jan 13 23:08:16 PST 2002 Workarea: snort.melbourne.sgi.com:/home/nathans/linux-xfs The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: xfs-cmds:slinx:109509a cmd/xfsprogs/include/xfs_inode.h - 1.10 cmd/xfsprogs/libxfs/xfs_ialloc.c - 1.6 cmd/xfsprogs/libxfs/xfs_inode.c - 1.4 - sync with recent kernel source changes (benign for userspace). cmd/xfstests/tools/srcdiff - 1.10 - update location of the xfs_support directory. Modid: 2.4.x-xfs:slinx:109509b linux/fs/xfs/xfs_qm.c - 1.71 - switch to the kmem_shake_register/kmem_shake_deregister interface which Steve has recently added. much cleaner than our old way and has more of a chance of shaking memory when the rest of XFS needs it. linux/fs/xfs_support/kmem.c - 1.17 - fix several buglets in the kmem_shake_register/kmem_shake_deregister routines. added a couple of BUG() calls in case these situations arise, and simplify body of the shake loop itself. linux/fs/quota.c - 1.4 - fix compiler warning. From owner-linux-xfs@oss.sgi.com Mon Jan 14 01:16:47 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0E9Glc27778 for linux-xfs-outgoing; Mon, 14 Jan 2002 01:16:47 -0800 Received: from sunny.pacific.net.au (sunny-legacy.pacific.net.au [210.23.129.40]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0E9Gig27756 for ; Mon, 14 Jan 2002 01:16:44 -0800 Received: from wisma.pacific.net.au (wisma.pacific.net.au [210.23.129.72]) by sunny.pacific.net.au with ESMTP id g0E8GeZM026744; Mon, 14 Jan 2002 19:16:40 +1100 (EST) Received: from jpc.local (ppp65.dyn225.pacific.net.au [203.100.225.65]) by wisma.pacific.net.au with ESMTP id TAA02263; Mon, 14 Jan 2002 19:16:20 +1100 (EST) Received: (from jason@localhost) by jpc.local (8.9.3/8.9.3/Debian 8.9.3-21) id TAA00903; Mon, 14 Jan 2002 19:16:17 +1100 From: Jason White MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15426.37839.891998.804320@jpc.local> Date: Mon, 14 Jan 2002 19:16:15 +1100 To: Shawn CC: linux-xfs@oss.sgi.com Subject: Re: XFS CVS Server.... In-Reply-To: References: <200201140221.NAA21965@snort.melbourne.sgi.com> X-Mailer: VM 6.76 under Emacs 20.7.2 Reply-To: Jason White Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 95 Lines: 5 Shawn writes: > > Uhm... CVS is dead ;-) I just ran cvs update -dP with no trouble at all. From owner-linux-xfs@oss.sgi.com Mon Jan 14 02:04:11 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0EA4Bl31363 for linux-xfs-outgoing; Mon, 14 Jan 2002 02:04:11 -0800 Received: from zork.zork.net (dsl-64149187165.internetconnect.net [64.149.187.165] (may be forged)) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0EA48g31341 for ; Mon, 14 Jan 2002 02:04:08 -0800 Received: from localhost (zork.zork.net) [127.0.0.1] by zork.zork.net with esmtp (Exim 3.33 #1 (Debian)) id 16Q32D-0007e4-00; Mon, 14 Jan 2002 01:04:05 -0800 To: Linux XFS Subject: Re: secure delete References: <8692.1010989072@www25.gmx.net> <15426.31621.557586.351483@jpc.local> From: Sean Neakums X-Message-Flag: Message text advisory: SLOTHFUL INDUCTION, HATE SPEECH X-Mailer: Norman Mail-Followup-To: Linux XFS Date: Mon, 14 Jan 2002 09:04:05 +0000 In-Reply-To: <15426.31621.557586.351483@jpc.local> (Jason White's message of "Mon, 14 Jan 2002 17:32:37 +1100") Message-ID: <6uheppnw1m.fsf@zork.zork.net> User-Agent: Gnus/5.090004 (Oort Gnus v0.04) Emacs/21.1 (i386-debian-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 455 Lines: 12 begin Jason White quotation: > The main problem is how to ensure that the data are actually written > to disk the specified number of times. O_DIRECT, perhaps? If you do lot of deletes it'll probably bog down your disk subsystem majorly, though. -- ///////////////// | | The spark of a pin | (require 'gnu) | dropping, falling feather-like. \\\\\\\\\\\\\\\\\ | | There is too much noise. From owner-linux-xfs@oss.sgi.com Mon Jan 14 03:08:23 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0EB8NH00601 for linux-xfs-outgoing; Mon, 14 Jan 2002 03:08:23 -0800 Received: from maggie.one-2-one.net (maggie.one-2-one.net [217.115.142.82] (may be forged)) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0EB8Jg00570 for ; Mon, 14 Jan 2002 03:08:19 -0800 Received: from PowerBox.MysticWorld.de (hagn-3e36933a.pool.mediaWays.net [62.54.147.58]) by maggie.one-2-one.net (8.11.0/8.11.0) with ESMTP id g0EADjn07322 for ; Mon, 14 Jan 2002 11:13:46 +0100 Received: from PowerBox.MysticWorld.de (PowerBox.MysticWorld.de [192.168.1.1]) by PowerBox.MysticWorld.de (8.12.1/8.12.1) with ESMTP id g0EA74e9013200 for ; Mon, 14 Jan 2002 11:07:04 +0100 Content-Type: text/plain; charset="iso-8859-15" From: Alexander Feigl To: linux-xfs@oss.sgi.com Subject: IMAP crashing with 2.4.17-xfs Date: Mon, 14 Jan 2002 11:06:56 +0100 X-Mailer: KMail [version 1.3.8] MIME-Version: 1.0 Message-Id: <200201141107.03837.moondream@moondream.de> X-Virus-Scanned: by amavisd-milter (http://amavis.org/ Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id g0EB8Kg00571 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 416 Lines: 12 Hi! Since kernel 2.4.17 - which I updated with cvsup shortly after 2.4.17 became available - cyrus imapd is regularly crashing on my machine (SIGSEGV) if /var is located on xfs. If I move /var to reiserfs the problem seems to be fixed. I tried to run xfs_repair but it didn't find any errors. I didn't try to update to the latest HEAD. Is there any bug fixed which could cause the crashes? Alexander Feigl From owner-linux-xfs@oss.sgi.com Mon Jan 14 03:18:20 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0EBIKY00903 for linux-xfs-outgoing; Mon, 14 Jan 2002 03:18:20 -0800 Received: from deliverator.sgi.com (deliverator.sgi.com [204.94.214.10]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0EBIHg00881 for ; Mon, 14 Jan 2002 03:18:17 -0800 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via SMTP id CAA15160 for ; Mon, 14 Jan 2002 02:13:51 -0800 (PST) mail_from (nathans@wobbly.melbourne.sgi.com) Received: from wobbly.melbourne.sgi.com (wobbly.melbourne.sgi.com [134.14.55.135]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id VAA09676; Mon, 14 Jan 2002 21:16:52 +1100 Received: (from nathans@localhost) by wobbly.melbourne.sgi.com (SGI-8.9.3/8.9.3) id VAA26260; Mon, 14 Jan 2002 21:16:51 +1100 (AEDT) Date: Mon, 14 Jan 2002 21:16:51 +1100 From: Nathan Scott To: Alexander Feigl Cc: linux-xfs@oss.sgi.com Subject: Re: IMAP crashing with 2.4.17-xfs Message-ID: <20020114211651.A26435@wobbly.melbourne.sgi.com> References: <200201141107.03837.moondream@moondream.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200201141107.03837.moondream@moondream.de>; from moondream@moondream.de on Mon, Jan 14, 2002 at 11:06:56AM +0100 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 689 Lines: 21 On Mon, Jan 14, 2002 at 11:06:56AM +0100, Alexander Feigl wrote: > Hi! > > Since kernel 2.4.17 - which I updated with cvsup shortly after 2.4.17 became > available - cyrus imapd is regularly crashing on my machine (SIGSEGV) if /var > is located on xfs. If I move /var to reiserfs the problem seems to be fixed. > I tried to run xfs_repair but it didn't find any errors. > > I didn't try to update to the latest HEAD. Is there any bug fixed which could > cause the crashes? > Yes, you will likely have more luck with current CVS kernel - there were some pagebuf fixes at the end of last week which might fix this issue. Let us know if the problem persists. cheers. -- Nathan From owner-linux-xfs@oss.sgi.com Mon Jan 14 07:32:09 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0EFW9B14131 for linux-xfs-outgoing; Mon, 14 Jan 2002 07:32:09 -0800 Received: from sgi.com (sgi-too.SGI.COM [204.94.211.39]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0EFW7g14108 for ; Mon, 14 Jan 2002 07:32:07 -0800 Received: from yourwebsite.com (adsl-63-205-10-74.dsl.scrm01.pacbell.net [63.205.10.74]) by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via SMTP id GAA04421 for ; Mon, 14 Jan 2002 06:28:42 -0800 (PST) mail_from (semiller@pacbell.net) From: semiller@pacbell.net Message-Id: <200201141428.GAA04421@sgi.com> Reply-To: semiller@pacbell.net To: xfs@oss.sgi.com Subject: SCIENCE REPORT: Learn how parents can stop family violence. Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Date: Mon, 14 Jan 2002 06:37:07 -0800 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 243 Lines: 4 SCIENCE REPORT: Learn how parents can effectively and peacefully work together to save themselves and their children from abuse and violence. --For information, click on http://sallykillsviolence.com ... Thank you, Sally Ellen Miller, ACAG From owner-linux-xfs@oss.sgi.com Mon Jan 14 08:43:07 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0EGh7u15138 for linux-xfs-outgoing; Mon, 14 Jan 2002 08:43:07 -0800 Received: from zok.sgi.com (zok.sgi.com [204.94.215.101]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0EGh0g15114 for ; Mon, 14 Jan 2002 08:43:00 -0800 Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by zok.sgi.com (8.11.4/8.11.4/linux-outbound_gateway-1.1) with ESMTP id g0EFgqo11325 for ; Mon, 14 Jan 2002 07:42:52 -0800 Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id JAA4087640; Mon, 14 Jan 2002 09:41:35 -0600 (CST) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id JAA15962; Mon, 14 Jan 2002 09:41:35 -0600 (CST) Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id g0EFdlq12526; Mon, 14 Jan 2002 09:39:47 -0600 Subject: Re: Partition extension From: Steve Lord To: linux-xfs@oss.sgi.com, cpringle@latrigg.demon.co.uk In-Reply-To: <200201132213.g0DMD3Y15749@oss.sgi.com> References: <200201132213.g0DMD3Y15749@oss.sgi.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/1.0.0.99+cvs.2001.12.18.08.57 (Preview Release) Date: 14 Jan 2002 09:39:47 -0600 Message-Id: <1011022787.12239.18.camel@jen.americas.sgi.com> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 929 Lines: 29 This message was bounced because it included a hotmail email address in the body - do we have nice email filters or what! Anyway, the answer here is you have to use lvm to manage the disk space, it supports on line extension. XFS can then use xfs_growfs to expand the filesystem - again whilst it is running, XFS does not support offline resizing! Any other partition management mechanism which allows expansion of a partition or logical volume would work too. Steve > > Hi All, > I'm looking for a feature currently offered by AdvFS on UNIX that allows you > to extend partitions onto another disk. When a partition becomes full, you > insert another disk, and tell XFS to extend a given partition by using that > disk. Does XFS have this? > > --- > Regards, > Chris Pringle -- Steve Lord voice: +1-651-683-3511 Principal Engineer, Filesystem Software email: lord@sgi.com From owner-linux-xfs@oss.sgi.com Mon Jan 14 09:23:21 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0EHNLd16120 for linux-xfs-outgoing; Mon, 14 Jan 2002 09:23:21 -0800 Received: from smtpgate.pcquote.com (smtpgate.hyperfeed.com [206.217.179.196]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0EHNGg16097 for ; Mon, 14 Jan 2002 09:23:16 -0800 Received: by smtpgate.hyperfeed.com with Internet Mail Service (5.5.2653.19) id ; Mon, 14 Jan 2002 10:21:15 -0600 Received: from coredump.pcqt.com (198.206.236.19 [198.206.236.19]) by smtpgate.pcquote.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id C43P32AF; Mon, 14 Jan 2002 10:21:14 -0600 Received: (qmail 22466 invoked by uid 1006); 14 Jan 2002 16:21:09 -0000 From: John Palkovic To: linux-xfs@oss.sgi.com Subject: 2.5.2-pre11-xfs build error Date: 14 Jan 2002 10:21:09 -0600 Message-ID: <81d70cq4y2.fsf@coredump.pcqt.com> User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.1 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 1814 Lines: 33 I just pulled the tree with 'cvz -z3 update -C -d'. I do a 'make mrproper' for good measure, then copy my .config file into place and issue 'make oldconfig dep bzImage'. The build hums along until make[4]: Entering directory `/u/palkovic/linux-2.5-xfs/linux/fs/xfs/linux' gcc -D__KERNEL__ -I/u/palkovic/linux-2.5-xfs/linux/include -Wall -Wstrict-prototypes -Wno-trigraphs -O2 -fno-strict-aliasing -fno-common -fomit-frame-pointer -pipe -mpreferred-stack-boundary=2 -march=i686 -nostdinc -I /usr/lib/gcc-lib/i386-linux/2.95.4/include -I .. -funsigned-char -c -o xfs_griostubs.o xfs_griostubs.c In file included from ../linux/xfs_linux.h:43, from ../xfs.h:39, from xfs_griostubs.c:36: ../pagebuf/page_buf.h:206: parse error before `avl_handle_t' ../pagebuf/page_buf.h:206: warning: no semicolon at end of struct or union ../pagebuf/page_buf.h:208: parse error before `}' ../pagebuf/page_buf.h:208: warning: type defaults to `int' in declaration of `pb_target_t' ../pagebuf/page_buf.h:208: warning: data definition has no type or storage class ../pagebuf/page_buf.h:456: parse error before `*' ../pagebuf/page_buf.h:457: warning: function declaration isn't a prototype ../xfs_log.h:60: warning: `_lsn_cmp' defined but not used make[4]: *** [xfs_griostubs.o] Error 1 make[4]: Leaving directory `/u/palkovic/linux-2.5-xfs/linux/fs/xfs/linux' make[3]: *** [first_rule] Error 2 make[3]: Leaving directory `/u/palkovic/linux-2.5-xfs/linux/fs/xfs/linux' make[2]: *** [_subdir_linux] Error 2 make[2]: Leaving directory `/u/palkovic/linux-2.5-xfs/linux/fs/xfs' make[1]: *** [_subdir_xfs] Error 2 make[1]: Leaving directory `/u/palkovic/linux-2.5-xfs/linux/fs' make: *** [_dir_fs] Error 2 -John -- HyperFeed Technologies Unix Development From owner-linux-xfs@oss.sgi.com Mon Jan 14 10:36:34 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0EIaYD17124 for linux-xfs-outgoing; Mon, 14 Jan 2002 10:36:34 -0800 Received: from sgi.com (sgi-too.SGI.COM [204.94.211.39]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0EIaRg17102 for ; Mon, 14 Jan 2002 10:36:27 -0800 Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id JAA05894 for ; Mon, 14 Jan 2002 09:33:01 -0800 (PST) mail_from (lord@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id LAA4088158; Mon, 14 Jan 2002 11:35:09 -0600 (CST) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id LAA05707; Mon, 14 Jan 2002 11:35:08 -0600 (CST) Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id g0EHXKJ12734; Mon, 14 Jan 2002 11:33:20 -0600 Subject: Re: 2.5.2-pre11-xfs build error From: Steve Lord To: John Palkovic Cc: linux-xfs@oss.sgi.com In-Reply-To: <81d70cq4y2.fsf@coredump.pcqt.com> References: <81d70cq4y2.fsf@coredump.pcqt.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/1.0.1 Date: 14 Jan 2002 11:33:20 -0600 Message-Id: <1011029600.12718.0.camel@jen.americas.sgi.com> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 2152 Lines: 45 On Mon, 2002-01-14 at 10:21, John Palkovic wrote: > I just pulled the tree with 'cvz -z3 update -C -d'. I do a 'make > mrproper' for good measure, then copy my .config file into place and > issue 'make oldconfig dep bzImage'. The build hums along until > > > make[4]: Entering directory `/u/palkovic/linux-2.5-xfs/linux/fs/xfs/linux' > gcc -D__KERNEL__ -I/u/palkovic/linux-2.5-xfs/linux/include -Wall -Wstrict-prototypes -Wno-trigraphs -O2 -fno-strict-aliasing -fno-common -fomit-frame-pointer -pipe -mpreferred-stack-boundary=2 -march=i686 -nostdinc -I /usr/lib/gcc-lib/i386-linux/2.95.4/include -I .. -funsigned-char -c -o xfs_griostubs.o xfs_griostubs.c > In file included from ../linux/xfs_linux.h:43, > from ../xfs.h:39, > from xfs_griostubs.c:36: > ../pagebuf/page_buf.h:206: parse error before `avl_handle_t' > ../pagebuf/page_buf.h:206: warning: no semicolon at end of struct or union > ../pagebuf/page_buf.h:208: parse error before `}' > ../pagebuf/page_buf.h:208: warning: type defaults to `int' in declaration of `pb_target_t' > ../pagebuf/page_buf.h:208: warning: data definition has no type or storage class > ../pagebuf/page_buf.h:456: parse error before `*' > ../pagebuf/page_buf.h:457: warning: function declaration isn't a prototype > ../xfs_log.h:60: warning: `_lsn_cmp' defined but not used > make[4]: *** [xfs_griostubs.o] Error 1 > make[4]: Leaving directory `/u/palkovic/linux-2.5-xfs/linux/fs/xfs/linux' > make[3]: *** [first_rule] Error 2 > make[3]: Leaving directory `/u/palkovic/linux-2.5-xfs/linux/fs/xfs/linux' > make[2]: *** [_subdir_linux] Error 2 > make[2]: Leaving directory `/u/palkovic/linux-2.5-xfs/linux/fs/xfs' > make[1]: *** [_subdir_xfs] Error 2 > make[1]: Leaving directory `/u/palkovic/linux-2.5-xfs/linux/fs' > make: *** [_dir_fs] Error 2 > > -John > > -- > HyperFeed Technologies > Unix Development I think you have some corruption in your tree, the code is OK here. Steve -- Steve Lord voice: +1-651-683-3511 Principal Engineer, Filesystem Software email: lord@sgi.com From owner-linux-xfs@oss.sgi.com Mon Jan 14 11:38:13 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0EJcD118913 for linux-xfs-outgoing; Mon, 14 Jan 2002 11:38:13 -0800 Received: from zok.sgi.com (zok.sgi.com [204.94.215.101]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0EJcAg18891 for ; Mon, 14 Jan 2002 11:38:10 -0800 Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by zok.sgi.com (8.11.4/8.11.4/linux-outbound_gateway-1.1) with ESMTP id g0EIc2o27045 for ; Mon, 14 Jan 2002 10:38:02 -0800 Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id MAA4089676 for ; Mon, 14 Jan 2002 12:36:46 -0600 (CST) Received: from stout.americas.sgi.com (stout.americas.sgi.com [128.162.187.5]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id MAA50681 for ; Mon, 14 Jan 2002 12:36:45 -0600 (CST) Received: by stout.americas.sgi.com (8.11.6/SGI-client-1.7) id g0EIajs14726; Mon, 14 Jan 2002 12:36:45 -0600 Message-Id: <200201141836.g0EIajs14726@stout.americas.sgi.com> Date: Mon, 14 Jan 2002 12:36:45 -0600 From: Eric Sandeen Subject: TAKE - fix previous mkfs.xfs fix Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 516 Lines: 16 My previous TAKE, which zeroed out other FS signatures, broke if you tried to make a filesystem on a file (as opposed to a block device). This fixes it. Date: Mon Jan 14 10:31:28 PST 2002 Workarea: stout.americas.sgi.com:/localhome/eric/2.4.x-xfs/workarea-reallyclean The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: xfs-cmds:slinx:109530a cmd/xfsprogs/mkfs/xfs_mkfs.c - 1.21 - Don't try to zero last 64k on the device if the filesystem is in a regular file. From owner-linux-xfs@oss.sgi.com Mon Jan 14 13:22:27 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0ELMR222090 for linux-xfs-outgoing; Mon, 14 Jan 2002 13:22:27 -0800 Received: from mail.empexis.com ([208.46.240.239]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0ELMNg22068 for ; Mon, 14 Jan 2002 13:22:23 -0800 Received: from empexis.com ([208.46.240.243]) by mail.empexis.com (8.11.6/8.11.6) with ESMTP id g0EKHnl31636 for ; Mon, 14 Jan 2002 15:17:49 -0500 Message-ID: <3C43317C.80802@empexis.com> Date: Mon, 14 Jan 2002 14:29:00 -0500 From: Joy Almacen User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.4) Gecko/20011126 Netscape6/6.2.1 X-Accept-Language: en-us MIME-Version: 1.0 To: linux-xfs@oss.sgi.com Subject: System Hard Crash and Recovery Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 635 Lines: 20 Hello, Just inherited an XFS-enabled system (RH7.1 Linux version 2.4.2-SGI_XFS_1.0smp). A few days ago the server locked up and we had to do a hard reboot. Everything rebooted just fine except for some weird things about some files. They reverted back to old versions ( a few days back). I do not know if this has something to do with disk allocation and writing (caching?). My question is how can I check what has caused this weird reversion to the old versions of our production scripts? Also, is there a way to recover data, backup was not enabled on prior to system crash, thru xfs utilties? Thanks a lot, Joy From owner-linux-xfs@oss.sgi.com Mon Jan 14 13:37:53 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0ELbre22448 for linux-xfs-outgoing; Mon, 14 Jan 2002 13:37:53 -0800 Received: from zok.sgi.com (zok.sgi.com [204.94.215.101]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0ELbmg22425 for ; Mon, 14 Jan 2002 13:37:48 -0800 Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by zok.sgi.com (8.11.4/8.11.4/linux-outbound_gateway-1.1) with ESMTP id g0EKbfo05088 for ; Mon, 14 Jan 2002 12:37:41 -0800 Received: from poppy-e185.americas.sgi.com (poppy-e185.americas.sgi.com [128.162.185.207]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id OAA4070372; Mon, 14 Jan 2002 14:36:25 -0600 (CST) Received: from stout.americas.sgi.com (stout.americas.sgi.com [128.162.187.5]) by poppy-e185.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.7) with ESMTP id OAA87994; Mon, 14 Jan 2002 14:36:25 -0600 (CST) Subject: Re: System Hard Crash and Recovery From: Eric Sandeen To: Joy Almacen Cc: linux-xfs@oss.sgi.com In-Reply-To: <3C43317C.80802@empexis.com> References: <3C43317C.80802@empexis.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/1.0 (Preview Release) Date: 14 Jan 2002 14:36:25 -0600 Message-Id: <1011040585.13215.6.camel@stout.americas.sgi.com> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 1401 Lines: 40 Hi Joy - Hm, I have never seen file versions from "a few days back" - usually on a lock-up, you only have problems with files written in the last ~30 seconds - and then, you don't get the old version back, anyway. 1.0 is pretty ancient these days, if you're going to continue using the machine I would strongly recommend upgrading to XFS release 1.0.2. There is probably no way to recover data that you have lost through a crash, it looks in your case like it never even hit the disk. Are you _certain_ that the newer versions were ever really there on this machine? -Eric On Mon, 2002-01-14 at 13:29, Joy Almacen wrote: > Hello, > > Just inherited an XFS-enabled system (RH7.1 Linux version > 2.4.2-SGI_XFS_1.0smp). A few days ago the server locked up and we had to do > a hard reboot. Everything rebooted just fine except for some weird > things about > some files. They reverted back to old versions ( a few days back). I do > not know if this has something to do with disk allocation and writing > (caching?). > > My question is how can I check what has caused this weird reversion to > the old versions of our production scripts? Also, is there a way to > recover data, backup was not enabled on prior to system crash, thru xfs > utilties? > > Thanks a lot, > > Joy > -- Eric Sandeen XFS for Linux http://oss.sgi.com/projects/xfs sandeen@sgi.com SGI, Inc. From owner-linux-xfs@oss.sgi.com Mon Jan 14 14:19:15 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0EMJFv23306 for linux-xfs-outgoing; Mon, 14 Jan 2002 14:19:15 -0800 Received: from sgi.com (sgi-too.SGI.COM [204.94.211.39]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0EMJCg23280 for ; Mon, 14 Jan 2002 14:19:12 -0800 Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id NAA01102 for ; Mon, 14 Jan 2002 13:15:44 -0800 (PST) mail_from (eric@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id PAA4093168 for ; Mon, 14 Jan 2002 15:17:54 -0600 (CST) Received: from stout.americas.sgi.com (stout.americas.sgi.com [128.162.187.5]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id PAA66070 for ; Mon, 14 Jan 2002 15:17:54 -0600 (CST) Received: by stout.americas.sgi.com (8.11.6/SGI-client-1.7) id g0ELHrD17474; Mon, 14 Jan 2002 15:17:54 -0600 Message-Id: <200201142117.g0ELHrD17474@stout.americas.sgi.com> Date: Mon, 14 Jan 2002 15:17:54 -0600 From: Eric Sandeen Subject: TAKE - Merge irix6.5f:irix:106773b Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 418 Lines: 15 This won't have any effect in Linux-land, but it keeps code in sync... Date: Mon Jan 14 13:13:12 PST 2002 Workarea: stout.americas.sgi.com:/localhome/eric/2.4.x-xfs/workarea-reallyclean The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:109545a linux/fs/xfs/xfs_rw.c - 1.348 - Change so CXFS clients do not forward a forced shutdown to other cells From owner-linux-xfs@oss.sgi.com Mon Jan 14 14:34:20 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0EMYKi24464 for linux-xfs-outgoing; Mon, 14 Jan 2002 14:34:20 -0800 Received: from smtpzilla2.xs4all.nl (smtpzilla2.xs4all.nl [194.109.127.138]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0EMYFg24441 for ; Mon, 14 Jan 2002 14:34:15 -0800 Received: from auto-nb1.xs4all.nl (qn-212-58-167-191.quicknet.nl [212.58.167.191]) by smtpzilla2.xs4all.nl (8.12.0/8.12.0) with ESMTP id g0ELY1ov063563; Mon, 14 Jan 2002 22:34:02 +0100 (CET) Message-Id: <4.3.2.7.2.20020114223022.02b1ec80@pop.xs4all.nl> X-Sender: knuffie@pop.xs4all.nl X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 14 Jan 2002 22:33:18 +0100 To: Eric Sandeen , Joy Almacen From: Seth Mos Subject: Re: System Hard Crash and Recovery Cc: linux-xfs@oss.sgi.com In-Reply-To: <1011040585.13215.6.camel@stout.americas.sgi.com> References: <3C43317C.80802@empexis.com> <3C43317C.80802@empexis.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 1142 Lines: 31 At 14:36 14-1-2002 -0600, Eric Sandeen wrote: >Hi Joy - > >Hm, I have never seen file versions from "a few days back" - usually on >a lock-up, you only have problems with files written in the last ~30 >seconds - and then, you don't get the old version back, anyway. > >1.0 is pretty ancient these days, if you're going to continue using the >machine I would strongly recommend upgrading to XFS release 1.0.2. > >There is probably no way to recover data that you have lost through a >crash, it looks in your case like it never even hit the disk. Are you >_certain_ that the newer versions were ever really there on this >machine? I have seen this happen when kswapd or kupdated hangs. This sounds a bit like it. Sync hangs the box and I think the box locked because off the amount of processes waiting to get data written. I have seen this happen myself. If this happens sync/mount and some other utilities won't work and you can't get that data back. Upgrading to a newer version is indeed a smart idea. Cheers -- Seth Every program has two purposes one for which it was written and another for which it wasn't I use the last kind. From owner-linux-xfs@oss.sgi.com Mon Jan 14 14:47:29 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0EMlT424758 for linux-xfs-outgoing; Mon, 14 Jan 2002 14:47:29 -0800 Received: from atlrel6.hp.com (atlrel6.hp.com [156.153.255.205]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0EMlRg24736 for ; Mon, 14 Jan 2002 14:47:27 -0800 Received: from xatlrelay1.atl.hp.com (xatlrelay1.atl.hp.com [15.45.89.190]) by atlrel6.hp.com (Postfix) with ESMTP id 505D8600374 for ; Mon, 14 Jan 2002 16:47:20 -0500 (EST) Received: from xatlbh3.atl.hp.com (xatlbh3.atl.hp.com [15.45.89.188]) by xatlrelay1.atl.hp.com (Postfix) with ESMTP id 4447720014E for ; Mon, 14 Jan 2002 16:47:20 -0500 (EST) Received: by xatlbh3.atl.hp.com with Internet Mail Service (5.5.2653.19) id ; Mon, 14 Jan 2002 16:47:20 -0500 Message-ID: From: "ZINKEVICIUS,MATT (HP-Loveland,ex1)" To: "'linux-xfs@oss.sgi.com'" Subject: attr_get() limited to 3061 bytes Date: Mon, 14 Jan 2002 16:47:15 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 345 Lines: 12 Howdy... More opportunities for printers :-) The attr_get() call returns a zero filled buffer if the size value is greater than 3061 bytes. The name and size are reported correctly, but not the value data. The max attribute size is supposed to be 64k right? Matt Zinkevicius Software Engineer Network Storage Array Solutions Hewlett-Packard From owner-linux-xfs@oss.sgi.com Mon Jan 14 15:05:54 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0EN5sE25270 for linux-xfs-outgoing; Mon, 14 Jan 2002 15:05:54 -0800 Received: from pneumatic-tube.sgi.com (pneumatic-tube.sgi.com [204.94.214.22]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0EN5og25247 for ; Mon, 14 Jan 2002 15:05:50 -0800 Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id OAA02510 for ; Mon, 14 Jan 2002 14:06:32 -0800 (PST) mail_from (sandeen@sgi.com) Received: from poppy-e185.americas.sgi.com (poppy-e185.americas.sgi.com [128.162.185.207]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id QAA4070591; Mon, 14 Jan 2002 16:04:31 -0600 (CST) Received: from stout.americas.sgi.com (stout.americas.sgi.com [128.162.187.5]) by poppy-e185.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.7) with ESMTP id QAA91732; Mon, 14 Jan 2002 16:04:31 -0600 (CST) Subject: Re: attr_get() limited to 3061 bytes From: Eric Sandeen To: "ZINKEVICIUS,MATT ""(HP-Loveland,ex1)" Cc: "'linux-xfs@oss.sgi.com'" In-Reply-To: References: Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/1.0 (Preview Release) Date: 14 Jan 2002 16:04:31 -0600 Message-Id: <1011045871.14477.10.camel@stout.americas.sgi.com> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 554 Lines: 18 On Mon, 2002-01-14 at 15:47, ZINKEVICIUS,MATT (HP-Loveland,ex1) wrote: > Howdy... More opportunities for printers :-) > > The attr_get() call returns a zero filled buffer if the size value is > greater than 3061 bytes. The name and size are reported correctly, but not > the value data. The max attribute size is supposed to be 64k right? Yep, I see it. Please get a shiny new 600dpi laserjet off the shelf, for when I find the problem. ;-) -Eric -- Eric Sandeen XFS for Linux http://oss.sgi.com/projects/xfs sandeen@sgi.com SGI, Inc. From owner-linux-xfs@oss.sgi.com Mon Jan 14 15:25:07 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0ENP7x25712 for linux-xfs-outgoing; Mon, 14 Jan 2002 15:25:07 -0800 Received: from eelwing.arda (postfix@md4691249.utfors.se [212.105.18.73]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0ENP0g25690 for ; Mon, 14 Jan 2002 15:25:00 -0800 Received: from unx.nu (eelwing.arda [172.16.0.1]) by eelwing.arda (Postfix) with ESMTP id 2F039100E for ; Mon, 14 Jan 2002 22:39:00 +0100 (CET) Date: Mon, 14 Jan 2002 22:38:57 +0100 (CET) From: wiss@unx.nu Subject: Re: System Hard Crash and Recovery To: linux-xfs@oss.sgi.com In-Reply-To: <1011040585.13215.6.camel@stout.americas.sgi.com> MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Message-Id: <20020114213900.2F039100E@eelwing.arda> Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 923 Lines: 34 On 14 Jan, Eric Sandeen wrote: > Hi Joy - > > Hm, I have never seen file versions from "a few days back" - usually on > a lock-up, you only have problems with files written in the last ~30 > seconds - and then, you don't get the old version back, anyway. If a hd/fs-driver locks up, write() might return and data stays in cache, after some time the machine runs out of memory/buffer space and alla processes that tryes to write() hangs in a syscall (non killable). I have seen this on a e2fs system that had a broken filesystem-struckture. Jonas -- http://wiss.unx.nu http://linux.unx.nu Another Glitch in the Call We don't need no indirection We don't need no flow control No data typing or declarations Did you leave the lists alone? Hey! Hacker! Leave those lists alone! Chorus: All in all, it's just a pure-LISP function call. All in all, it's just a pure-LISP function call. From owner-linux-xfs@oss.sgi.com Mon Jan 14 15:42:22 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0ENgMh26174 for linux-xfs-outgoing; Mon, 14 Jan 2002 15:42:22 -0800 Received: from pneumatic-tube.sgi.com (pneumatic-tube.sgi.com [204.94.214.22]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0ENgJg26152 for ; Mon, 14 Jan 2002 15:42:19 -0800 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.55.149]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id OAA09775 for ; Mon, 14 Jan 2002 14:43:02 -0800 (PST) mail_from (nathans@snort.melbourne.sgi.com) Received: (from nathans@localhost) by snort.melbourne.sgi.com (SGI-8.9.3/8.9.3) id JAA17137; Tue, 15 Jan 2002 09:40:58 +1100 (EST) Date: Tue, 15 Jan 2002 09:40:58 +1100 (EST) From: Nathan Scott Message-Id: <200201142240.JAA17137@snort.melbourne.sgi.com> To: jpalkovic@hyperfeed.com, linux-xfs@oss.sgi.com Subject: TAKE - avl.h Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 397 Lines: 16 This will probably fix that 2.5 build failure... Date: Mon Jan 14 14:35:24 PST 2002 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: 2.5.x-xfs:slinx:109555a linux/include/linux/avl.h - 1.6 - sync up with the 2.4 tree - we still had some remnants of the pagebuf config options here. From owner-linux-xfs@oss.sgi.com Mon Jan 14 16:42:42 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0F0ggv27692 for linux-xfs-outgoing; Mon, 14 Jan 2002 16:42:42 -0800 Received: from rj.sgi.com (rj.SGI.COM [204.94.215.100]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0F0gVg27670 for ; Mon, 14 Jan 2002 16:42:32 -0800 Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by rj.sgi.com (8.11.4/8.11.4/linux-outbound_gateway-1.1) with ESMTP id g0ENgOY30790 for ; Mon, 14 Jan 2002 15:42:24 -0800 Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id RAA4092306; Mon, 14 Jan 2002 17:41:07 -0600 (CST) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id RAA80600; Mon, 14 Jan 2002 17:41:07 -0600 (CST) Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id g0ENdGC13781; Mon, 14 Jan 2002 17:39:16 -0600 Subject: Re: Possible problem: 2.4.17cvs oops. From: Steve Lord To: David Chambers Cc: linux-xfs@oss.sgi.com In-Reply-To: <20020111214715.4e67c0f9.davidc@ccmi.salk.edu> References: <20020111214715.4e67c0f9.davidc@ccmi.salk.edu> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/1.0.1 Date: 14 Jan 2002 17:39:16 -0600 Message-Id: <1011051556.13534.19.camel@jen.americas.sgi.com> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 1401 Lines: 40 On Fri, 2002-01-11 at 23:47, David Chambers wrote: > Hi! > > I do not know whether any of the following is of any use, and no core file > was generated, but here goes: > > System is a Tyan motherboard, dual PIII, VIA chipset. Running 1 x Seagate > disk on hda, 8 x Maxtor Diamondmax 80Gb as RAID 5 controlled by a 3ware > 7850 card. NIC is 3com 3C905B. 1Gb RAM. All partitions are XFS. > > Red Hat 7.2, Kernel 2.4.17 from the XFS 2.4.17-cvs tree on Jan. 9th. > 3c905 is a module, 3w-xxxx is also a module. > > During testing, copying about 60GB from an NFS mounted filesystem to the > 3ware array I get the messages appended below. > > I am a total newbie at kernel diagnostics. I do not know what to do > to proceed with this! Is this report of any use?? What can/should I do > to be more helpful? > > - David > > In syslog: (the "memory shortage" occurs whether 3c905 is compiled > into the kernel or is a module. I'm a little suspicious of it!) If an XFS memory allocation failed, then it is possible it was the root cause of the oops here. XFS comes from an environment where a memory allocation does not fail as it can on Linux. Not sure I have a fix for you right now, but it does tell me this type of thing can still happen. Steve -- Steve Lord voice: +1-651-683-3511 Principal Engineer, Filesystem Software email: lord@sgi.com From owner-linux-xfs@oss.sgi.com Mon Jan 14 16:54:21 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0F0sLj28219 for linux-xfs-outgoing; Mon, 14 Jan 2002 16:54:21 -0800 Received: from pneumatic-tube.sgi.com (pneumatic-tube.sgi.com [204.94.214.22]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0F0sHg28195 for ; Mon, 14 Jan 2002 16:54:17 -0800 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.55.149]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id PAA03691 for ; Mon, 14 Jan 2002 15:55:00 -0800 (PST) mail_from (nathans@snort.melbourne.sgi.com) Received: (from nathans@localhost) by snort.melbourne.sgi.com (SGI-8.9.3/8.9.3) id KAA78476 for linux-xfs@oss.sgi.com; Tue, 15 Jan 2002 10:52:57 +1100 (EST) Date: Tue, 15 Jan 2002 10:52:57 +1100 (EST) From: Nathan Scott Message-Id: <200201142352.KAA78476@snort.melbourne.sgi.com> To: linux-xfs@oss.sgi.com Subject: TAKE - avl.h Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 959 Lines: 27 avl.h was missed in earlier header file movement, finish off the pagebuf relocation program. Date: Mon Jan 14 15:45:40 PST 2002 Workarea: snort.melbourne.sgi.com:/home/nathans/pagebuf The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:109560a linux/include/linux/avl.h 1.7 renamed to linux/fs/xfs/pagebuf/avl.h 1.1 - linux/include/linux/avl.h 1.6 Renamed to linux/fs/xfs/pagebuf/avl.hrenamed linux/include/linux/avl.h => linux/fs/xfs/pagebuf/avl.h. linux/fs/xfs/linux/xfs_linux.h - 1.59 linux/fs/xfs/pagebuf/page_buf_io.c - 1.2 linux/fs/xfs/pagebuf/avl.c - 1.2 linux/fs/xfs/pagebuf/page_buf_locking.c - 1.2 linux/fs/xfs/pagebuf/page_buf.c - 1.2 linux/fs/xfs/pagebuf/page_buf.h - 1.2 - renamed linux/include/linux/avl.h => linux/fs/xfs/pagebuf/avl.h. linux/fs/xfs/pagebuf/Makefile - 1.3 linux/fs/xfs/pagebuf/Makefile.in - 1.2 - add a comment about a pagebuf debug option I missed earlier. From owner-linux-xfs@oss.sgi.com Mon Jan 14 19:01:47 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0F31ll30566 for linux-xfs-outgoing; Mon, 14 Jan 2002 19:01:47 -0800 Received: from zok.sgi.com (zok.sgi.com [204.94.215.101]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0F31ig30544 for ; Mon, 14 Jan 2002 19:01:44 -0800 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.55.149]) by zok.sgi.com (8.11.4/8.11.4/linux-outbound_gateway-1.1) with ESMTP id g0F21ao24386 for ; Mon, 14 Jan 2002 18:01:36 -0800 Received: (from nathans@localhost) by snort.melbourne.sgi.com (SGI-8.9.3/8.9.3) id NAA98764 for linux-xfs@oss.sgi.com; Tue, 15 Jan 2002 13:00:17 +1100 (EST) Date: Tue, 15 Jan 2002 13:00:17 +1100 (EST) From: Nathan Scott Message-Id: <200201150200.NAA98764@snort.melbourne.sgi.com> To: linux-xfs@oss.sgi.com Subject: TAKE - debug builds Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 344 Lines: 13 Date: Mon Jan 14 17:56:30 PST 2002 Workarea: snort.melbourne.sgi.com:/home/nathans/linux-xfs The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:109571a linux/fs/xfs/xfsidbg.c - 1.168 linux/fs/xfs/xfs_buf.h - 1.78 - fix a bit more build fallout from the pagebuf code relocation. From owner-linux-xfs@oss.sgi.com Tue Jan 15 05:30:59 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0FDUxX16008 for linux-xfs-outgoing; Tue, 15 Jan 2002 05:30:59 -0800 Received: from goliath.sylaba.poznan.pl (root@goliath.sylaba.poznan.pl [195.216.104.3]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0FDUoP15984 for ; Tue, 15 Jan 2002 05:30:51 -0800 Received: from venus.local.navi.pl (ps103.poznan.sdi.tpnet.pl [217.97.72.103]) by goliath.sylaba.poznan.pl (8.11.6/8.10.1) with ESMTP id g0FCUg216231 for ; Tue, 15 Jan 2002 13:30:42 +0100 (CET) Received: from venus.local.navi.pl (venus.local.navi.pl [192.168.1.10]) by venus.local.navi.pl (8.11.6/8.9.3) with ESMTP id g0FCQpN02212 for ; Tue, 15 Jan 2002 13:26:51 +0100 Date: Tue, 15 Jan 2002 13:26:51 +0100 From: Olaf =?iso-8859-1?Q?Fr=B1czyk?= To: linux-xfs@oss.sgi.com Subject: problem with VMware -XFS guilty one - was: Re: XFS is innocent Message-ID: <20020115132651.E1593@venus.local.navi.pl> Mime-Version: 1.0 Content-Type: text/plain; format=flowed; charset=ISO-8859-1 X-Mailer: Balsa 1.2.3 X-MIME-Autoconverted: from 8bit to quoted-printable by goliath.sylaba.poznan.pl id g0FCUg216231 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id g0FDUrP15986 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 1012 Lines: 29 On 2002.01.10 19:42:01 +0100 Steve Lord wrote: > On Thu, 2002-01-10 at 11:30, Olaf Fr±czyk wrote: > > Hi, > > I have installed clean RH7.2 on one free partition on my machine. > Removed > > RH gcc, installed compat-egcs, compiled new kernel (2.4.17) with xfs > > (using the same sources as previous) and ... no problems. > > So I moved kernel, modules to my working system, and ... it works. > > So something with my system is wrong, and the problems are not XFS > related. > > Now, I have to find what :(( Hi, Found what's wrong (in my case): if on /tmp partition I have XFS filesystem then VMware crashes if on /tmp is ext2 then everything is OK The only thing VMware does on it, is to place /tmp/ram0 file (found it in vmware.log). But it does _not_ appear in ls output, nor in mc (midnight commander). And I suppose, that if I have low memory, it puts them part of guest OS memory. I think so, because the less memory I have, then I have crashes earlier. I use VMware 3.0.0 build 1455. Regards, Olaf From owner-linux-xfs@oss.sgi.com Tue Jan 15 05:46:21 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0FDkLW16446 for linux-xfs-outgoing; Tue, 15 Jan 2002 05:46:21 -0800 Received: from rj.sgi.com (rj.sgi.com [204.94.215.100]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0FDkEP16423 for ; Tue, 15 Jan 2002 05:46:14 -0800 Received: from zeus-e8.americas.sgi.com (zeus-e8.americas.sgi.com [128.162.8.103]) by rj.sgi.com (8.11.4/8.11.4/linux-outbound_gateway-1.1) with ESMTP id g0FCk7Y27804 for ; Tue, 15 Jan 2002 04:46:07 -0800 Received: from tulip-e185.americas.sgi.com (tulip-e185.americas.sgi.com [128.162.185.208]) by zeus-e8.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id GAA04628; Tue, 15 Jan 2002 06:44:52 -0600 (CST) Received: from sgi.com (5HBp5ys9Qu8ugUdFrKYdjh/DwhFIbA6Y@cf-vpn-sw-corp-64-28.corp.sgi.com [134.15.64.28]) by tulip-e185.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.7) with ESMTP id GAA19601; Tue, 15 Jan 2002 06:44:51 -0600 (CST) Message-ID: <3C44255B.8090008@sgi.com> Date: Tue, 15 Jan 2002 06:49:31 -0600 From: Stephen Lord User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.6) Gecko/20011120 X-Accept-Language: en-us MIME-Version: 1.0 To: Olaf =?ISO-8859-2?Q?Fr=B1czyk?= CC: linux-xfs@oss.sgi.com Subject: Re: problem with VMware -XFS guilty one - was: Re: XFS is innocent References: <20020110183051.A1483@venus.local.navi.pl> <1010688121.676.111.camel@jen.americas.sgi.com> <20020115132520.C1593@venus.local.navi.pl> Content-Type: text/plain; charset=ISO-8859-2; format=flowed Content-Transfer-Encoding: 8bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 1293 Lines: 45 Olaf Fr1czyk wrote: > On 2002.01.10 19:42:01 +0100 Steve Lord wrote: > >> On Thu, 2002-01-10 at 11:30, Olaf Fr1czyk wrote: >> > Hi, >> > I have installed clean RH7.2 on one free partition on my machine. >> Removed >> > RH gcc, installed compat-egcs, compiled new kernel (2.4.17) with xfs >> > (using the same sources as previous) and ... no problems. >> > So I moved kernel, modules to my working system, and ... it works. >> > So something with my system is wrong, and the problems are not XFS >> related. >> > Now, I have to find what :(( > > Hi, > > Found what's wrong (in my case): > if on /tmp partition I have XFS filesystem then VMware crashes > if on /tmp is ext2 then everything is OK > > The only thing VMware does on it, is to place /tmp/ram0 file (found it > in vmware.log). > But it does _not_ appear in ls output, nor in mc (midnight commander). > And I suppose, that if I have low memory, it puts them part of guest > OS memory. > I think so, because the less memory I have, then I have crashes earlier. > > I use VMware 3.0.0 build 1455. > > Regards, > > Olaf Please try this with the current cvs tree - there was a change in the last week which fixed some problems with mmapped I/O under heavy memory pressure (the emacs build problem mentioned on the list). Steve From owner-linux-xfs@oss.sgi.com Tue Jan 15 06:20:53 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0FEKrS20448 for linux-xfs-outgoing; Tue, 15 Jan 2002 06:20:53 -0800 Received: from goliath.sylaba.poznan.pl (root@goliath.sylaba.poznan.pl [195.216.104.3]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0FEKnP20426 for ; Tue, 15 Jan 2002 06:20:49 -0800 Received: from venus.local.navi.pl (ps103.poznan.sdi.tpnet.pl [217.97.72.103]) by goliath.sylaba.poznan.pl (8.11.6/8.10.1) with ESMTP id g0FDKfL23253; Tue, 15 Jan 2002 14:20:41 +0100 (CET) Received: from venus.local.navi.pl (venus.local.navi.pl [192.168.1.10]) by venus.local.navi.pl (8.11.6/8.9.3) with ESMTP id g0FDEHN02556; Tue, 15 Jan 2002 14:14:17 +0100 Date: Tue, 15 Jan 2002 14:14:17 +0100 From: Olaf =?iso-8859-2?Q?Fr=B1czyk?= To: Stephen Lord Cc: Olaf =?iso-8859-2?Q?Fr=B1czyk?= , linux-xfs@oss.sgi.com Subject: Re: problem with VMware -XFS guilty one - was: Re: XFS is innocent Message-ID: <20020115141417.A2276@venus.local.navi.pl> References: <20020110183051.A1483@venus.local.navi.pl> <1010688121.676.111.camel@jen.americas.sgi.com> <20020115132520.C1593@venus.local.navi.pl> <3C44255B.8090008@sgi.com> Mime-Version: 1.0 Content-Type: text/plain; format=flowed; charset=ISO-8859-2 Content-Transfer-Encoding: 8bit In-Reply-To: <3C44255B.8090008@sgi.com>; from lord@sgi.com on Tue, Jan 15, 2002 at 13:49:31 +0100 X-Mailer: Balsa 1.2.3 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 340 Lines: 12 On 2002.01.15 13:49:31 +0100 Stephen Lord wrote: > Please try this with the current cvs tree - there was a change in the > last week which fixed > some problems with mmapped I/O under heavy memory pressure (the emacs > build problem > mentioned on the list). > Which branch: 2.4 or 2.5? I would prefer 2.4 if possible :) Regards, Olaf From owner-linux-xfs@oss.sgi.com Tue Jan 15 06:42:42 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0FEggU20977 for linux-xfs-outgoing; Tue, 15 Jan 2002 06:42:42 -0800 Received: from a.mx.spoiled.org (babel.spoiled.org [217.13.197.48]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0FEgVP20954 for ; Tue, 15 Jan 2002 06:42:31 -0800 Received: by a.mx.spoiled.org (Postfix, from userid 8) id 3DAFD1195E; Tue, 15 Jan 2002 14:42:27 +0100 (CET) From: Juri Haberland Reply-To: Juri Haberland X-Newsgroups: spoiled.linux.sgi.xfs Subject: Oops with 2.4.17 (CVS from today) Date: Tue, 15 Jan 2002 13:42:27 +0000 (UTC) Organization: spoiled dot org Distribution: local Message-ID: X-Complaints-To: newsmaster@spoiled.org User-Agent: tin/1.4.5-20010409 ("One More Nightmare") (UNIX) (OpenBSD/2.9 (i386)) To: linux-xfs@oss.sgi.com Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 3294 Lines: 85 Hi list, today I tried to update the kernel on a little workgroup server from 2.4.13-xfs to 2.4.17-xfs and I got an Oops when ever I tried to boot 2.4.17. Actually it booted fine until one of the last services was started. It always oopsed somewhere between starting innd and netsaintd. The machine in question is a dual PIII-750 with two IDE-disks. It also serves the home dirs via NFS to a couple of workstations. The NFS daemons where always stuck in D-state... If you need any additional informations feel free to ask ;) TIA, Juri Here is one of the decoded oopses: ksymoops 2.4.0 on i686 2.4.13-xfs. Options used -V (default) -K (specified) -l /proc/modules (default) -o /lib/modules/2.4.17-xfs/ (specified) -m /boot/System.map (specified) No modules in ksyms, skipping objects No ksyms, skipping lsmod Unable to handle kernel NULL pointer dereference at virtual address 0000009c c021fdb8 *pde = 00000000 Oops: 0002 CPU: 0 EIP: 0010:[mraccessf+8/112] Not tainted EIP: 0010:[] Not tainted Using defaults from ksymoops -t elf32-i386 -a i386 EFLAGS: 00010002 eax: 00000074 ebx: 00000074 ecx: 00000008 edx: ffffffe8 esi: c03de7a0 edi: 00000001 ebp: ced47d90 esp: ced47d8c ds: 0018 es: 0018 ss: 0018 Process nfsd (pid: 685, stackpage=ced47000) Stack: ffffffe8 ced47da4 c01eb0b4 00000074 00000288 c01eab59 ced47dcc c01eab59 ffffffe8 00000008 cd9cf1a0 00000000 00000000 cff4ec60 ced47e18 00000000 ced47e04 c0202079 cf9ce400 00000000 04400094 00000001 00000008 ced47df4 Call Trace: [xfs_ilock+20/32] [xfs_iget+265/352] [xfs_iget+265/352] [xfs_vget+73/224] [linvfs_fh_to_dentry+109/256] Call Trace: [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] Code: f0 fe 4b 28 0f 88 7d 24 0b 00 8b 43 08 85 c0 74 18 ff 43 04 >>EIP; c021fdb8 <===== Trace; c01eb0b4 Trace; c01eab59 Trace; c01eab59 Trace; c0202079 Trace; c021700d Trace; c01842e6 Trace; c018471c Trace; c0184c59 Trace; c01855c0 Trace; c018b4f9 Trace; c0182a78 Trace; c02c1014 Trace; c0182894 Trace; c0105676 Trace; c01826a0 Trace; c01826a0 Code; c021fdb8 00000000 <_EIP>: Code; c021fdb8 <===== 0: f0 fe 4b 28 lock decb 0x28(%ebx) <===== Code; c021fdbc 4: 0f 88 7d 24 0b 00 js b2487 <_EIP+0xb2487> c02d223f Code; c021fdc2 a: 8b 43 08 mov 0x8(%ebx),%eax Code; c021fdc5 d: 85 c0 test %eax,%eax Code; c021fdc7 f: 74 18 je 29 <_EIP+0x29> c021fde1 Code; c021fdc9 11: ff 43 04 incl 0x4(%ebx) -- Juri Haberland From owner-linux-xfs@oss.sgi.com Tue Jan 15 07:37:40 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0FFbeW22287 for linux-xfs-outgoing; Tue, 15 Jan 2002 07:37:40 -0800 Received: from coredump.sh0n.net (qmailremote@CPEdeadbeef0000.cpe.net.cable.rogers.com [24.100.234.67]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0FFbXP22265 for ; Tue, 15 Jan 2002 07:37:33 -0800 Received: (qmail 619 invoked from network); 15 Jan 2002 14:38:21 -0000 Received: from unknown (HELO unaropia.datawire.net) (207.61.129.120) by coredump.sh0n.net with SMTP; 15 Jan 2002 14:38:21 -0000 Subject: rmap-11b + XFS.. From: Shawn Starr To: Stephen Lord Cc: xfs In-Reply-To: <3C44255B.8090008@sgi.com> References: <20020110183051.A1483@venus.local.navi.pl> <1010688121.676.111.camel@jen.americas.sgi.com> <20020115132520.C1593@venus.local.navi.pl> <3C44255B.8090008@sgi.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/1.0.1.99 (Preview Release) Date: 15 Jan 2002 09:39:15 -0500 Message-Id: <1011105582.25395.6906.camel@unaropia> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 1593 Lines: 56 422 root 17 0 1032 1032 360 R 82.2 1.6 409:33 blowup-xfs Looks good, I believe it was some other patch that caused corruptions. Shawn. On Tue, 2002-01-15 at 07:49, Stephen Lord wrote: > Olaf Fr1czyk wrote: > > > On 2002.01.10 19:42:01 +0100 Steve Lord wrote: > > > >> On Thu, 2002-01-10 at 11:30, Olaf Fr1czyk wrote: > >> > Hi, > >> > I have installed clean RH7.2 on one free partition on my machine. > >> Removed > >> > RH gcc, installed compat-egcs, compiled new kernel (2.4.17) with xfs > >> > (using the same sources as previous) and ... no problems. > >> > So I moved kernel, modules to my working system, and ... it works. > >> > So something with my system is wrong, and the problems are not XFS > >> related. > >> > Now, I have to find what :(( > > > > Hi, > > > > Found what's wrong (in my case): > > if on /tmp partition I have XFS filesystem then VMware crashes > > if on /tmp is ext2 then everything is OK > > > > The only thing VMware does on it, is to place /tmp/ram0 file (found it > > in vmware.log). > > But it does _not_ appear in ls output, nor in mc (midnight commander). > > And I suppose, that if I have low memory, it puts them part of guest > > OS memory. > > I think so, because the less memory I have, then I have crashes earlier. > > > > I use VMware 3.0.0 build 1455. > > > > Regards, > > > > Olaf > > Please try this with the current cvs tree - there was a change in the > last week which fixed > some problems with mmapped I/O under heavy memory pressure (the emacs > build problem > mentioned on the list). > > Steve > > > > > From owner-linux-xfs@oss.sgi.com Tue Jan 15 07:47:40 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0FFleH22569 for linux-xfs-outgoing; Tue, 15 Jan 2002 07:47:40 -0800 Received: from deliverator.sgi.com (deliverator.sgi.com [204.94.214.10]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0FFlbP22546 for ; Tue, 15 Jan 2002 07:47:37 -0800 Received: from relay1.corp.sgi.com (spindle.corp.sgi.com [198.29.75.13]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id GAA25457 for ; Tue, 15 Jan 2002 06:43:14 -0800 (PST) mail_from (sandeen@sgi.com) Received: from chuckle.americas.sgi.com (sandeen@chuckle.americas.sgi.com [128.162.211.44]) by relay1.corp.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) via ESMTP id GAA88810; Tue, 15 Jan 2002 06:47:03 -0800 (PST) Date: Tue, 15 Jan 2002 08:47:02 -0600 (CST) From: Eric Sandeen X-X-Sender: To: Olaf =?iso-8859-2?Q?Fr=B1czyk?= cc: Stephen Lord , Subject: Re: problem with VMware -XFS guilty one - was: Re: XFS is innocent In-Reply-To: <20020115141417.A2276@venus.local.navi.pl> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 X-MIME-Autoconverted: from 8bit to quoted-printable by deliverator.sgi.com id GAA25457 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id g0FFlbP22547 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 141 Lines: 8 On Tue, 15 Jan 2002, Olaf [iso-8859-2] Fr±czyk wrote: > Which branch: 2.4 or 2.5? > I would prefer 2.4 if possible :) Yes, 2.4. :) -Eric From owner-linux-xfs@oss.sgi.com Tue Jan 15 08:12:33 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0FGCXA23191 for linux-xfs-outgoing; Tue, 15 Jan 2002 08:12:33 -0800 Received: from tiny.int.franksintl.nl (goblin.franksintl.nl [195.193.231.154]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0FGCTP23168 for ; Tue, 15 Jan 2002 08:12:29 -0800 Received: from cp35 ([192.168.4.140]) by tiny.int.franksintl.nl (8.11.4/8.11.4/Debian 8.9.3-21) with ESMTP id g0FF7f901605 for ; Tue, 15 Jan 2002 16:07:41 +0100 From: "Ries van Twisk" To: linux-xfs@oss.sgi.com Date: Tue, 15 Jan 2002 16:07:39 +0100 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Subject: [FYI] XFS and 2.4.17 Reply-to: ries@franksintl.nl Message-ID: <3C4453CB.1269.8B9B34@localhost> X-mailer: Pegasus Mail for Win32 (v3.12c) Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 227 Lines: 11 Hi All, I'm running a PE2550 with a 2.4.17 kernel XFS enabled (ofcource). Everything runs off XFS except the root file system. All is compiled with gcc 2.95.2. I have just ine thing to say... The system works great! Ries From owner-linux-xfs@oss.sgi.com Tue Jan 15 08:39:18 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0FGdIs23943 for linux-xfs-outgoing; Tue, 15 Jan 2002 08:39:18 -0800 Received: from pneumatic-tube.sgi.com (pneumatic-tube.sgi.com [204.94.214.22]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0FGd5P23919 for ; Tue, 15 Jan 2002 08:39:06 -0800 Received: from zeus-e8.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id HAA01458 for ; Tue, 15 Jan 2002 07:39:48 -0800 (PST) mail_from (lord@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by zeus-e8.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id JAA06774; Tue, 15 Jan 2002 09:37:45 -0600 (CST) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id JAA27655; Tue, 15 Jan 2002 09:37:44 -0600 (CST) Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id g0FFZla22203; Tue, 15 Jan 2002 09:35:47 -0600 Subject: Re: Oops with 2.4.17 (CVS from today) From: Steve Lord To: Juri Haberland Cc: linux-xfs@oss.sgi.com In-Reply-To: References: Content-Type: multipart/mixed; boundary="=-UaMaiIU9JMXfqBaRpRD2" X-Mailer: Evolution/1.0.1 Date: 15 Jan 2002 09:35:47 -0600 Message-Id: <1011108947.13545.31.camel@jen.americas.sgi.com> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 1999 Lines: 61 --=-UaMaiIU9JMXfqBaRpRD2 Content-Type: text/plain Content-Transfer-Encoding: 7bit On Tue, 2002-01-15 at 07:42, Juri Haberland wrote: > Hi list, > > today I tried to update the kernel on a little workgroup server from > 2.4.13-xfs to 2.4.17-xfs and I got an Oops when ever I tried to boot > 2.4.17. Actually it booted fine until one of the last services was > started. It always oopsed somewhere between starting innd and netsaintd. > The machine in question is a dual PIII-750 with two IDE-disks. > It also serves the home dirs via NFS to a couple of workstations. > The NFS daemons where always stuck in D-state... > > If you need any additional informations feel free to ask ;) > > TIA, > Juri > Try the attached patch and see if it goes away. Steve -- Steve Lord voice: +1-651-683-3511 Principal Engineer, Filesystem Software email: lord@sgi.com --=-UaMaiIU9JMXfqBaRpRD2 Content-Disposition: attachment; filename=nfs.patch Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; 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_super.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.22191-0/linux/fs/xfs/linux/xfs_super.c_1.153 Tue Jan 15= 09:37:00 2002 +++ linux/fs/xfs/linux/xfs_super.c Tue Jan 15 09:34:44 2002 @@ -911,8 +911,10 @@ statfs: linvfs_statfs, remount_fs: linvfs_remount, =20 +#if 0 fh_to_dentry: linvfs_fh_to_dentry, dentry_to_fh: linvfs_dentry_to_fh, +#endif }; =20 DECLARE_FSTYPE_DEV(xfs_fs_type, XFS_NAME, linvfs_read_super); --=-UaMaiIU9JMXfqBaRpRD2-- From owner-linux-xfs@oss.sgi.com Tue Jan 15 09:14:55 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0FHEto26519 for linux-xfs-outgoing; Tue, 15 Jan 2002 09:14:55 -0800 Received: from sto-vo-kor.koschikode.com (sto-vo-kor.koschikode.com [195.124.129.42]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0FHEdP26493 for ; Tue, 15 Jan 2002 09:14:39 -0800 Received: from koschikode.com (pktomo.altus.de [192.168.0.62]) by sto-vo-kor.koschikode.com (Postfix) with ESMTP id 2D828F491; Tue, 15 Jan 2002 17:14:29 +0100 (CET) Message-ID: <3C445563.7070305@koschikode.com> Date: Tue, 15 Jan 2002 17:14:27 +0100 From: Juri Haberland User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.7) Gecko/20011226 X-Accept-Language: en-us MIME-Version: 1.0 To: Steve Lord Cc: linux-xfs@oss.sgi.com Subject: Re: Oops with 2.4.17 (CVS from today) References: <1011108947.13545.31.camel@jen.americas.sgi.com> Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 928 Lines: 34 Steve Lord wrote: > On Tue, 2002-01-15 at 07:42, Juri Haberland wrote: > >>Hi list, >> >>today I tried to update the kernel on a little workgroup server from >>2.4.13-xfs to 2.4.17-xfs and I got an Oops when ever I tried to boot >>2.4.17. Actually it booted fine until one of the last services was >>started. It always oopsed somewhere between starting innd and netsaintd. >>The machine in question is a dual PIII-750 with two IDE-disks. >>It also serves the home dirs via NFS to a couple of workstations. >>The NFS daemons where always stuck in D-state... >> >>If you need any additional informations feel free to ask ;) > Try the attached patch and see if it goes away. > > Steve Yes, it does! Thanks a lot, Juri -- If each of us have one object, and we exchange them, then each of us still has one object. If each of us have one idea, and we exchange them, then each of us now has two ideas. From owner-linux-xfs@oss.sgi.com Tue Jan 15 09:52:46 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0FHqk127379 for linux-xfs-outgoing; Tue, 15 Jan 2002 09:52:46 -0800 Received: from pneumatic-tube.sgi.com (pneumatic-tube.sgi.com [204.94.214.22]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0FHqCP27350 for ; Tue, 15 Jan 2002 09:52:12 -0800 Received: from zeus-e8.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id IAA04103 for ; Tue, 15 Jan 2002 08:52:55 -0800 (PST) mail_from (lord@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by zeus-e8.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id KAA07874 for ; Tue, 15 Jan 2002 10:50:53 -0600 (CST) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id KAA56517 for ; Tue, 15 Jan 2002 10:50:53 -0600 (CST) From: Steve Lord Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id g0FGmtx22426; Tue, 15 Jan 2002 10:48:55 -0600 Message-Id: <200201151648.g0FGmtx22426@jen.americas.sgi.com> Date: Tue, 15 Jan 2002 10:48:55 -0600 Subject: TAKE - merge up to 2.5.2 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 11986 Lines: 327 Date: Tue Jan 15 08:45:42 PST 2002 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:109600a linux/drivers/block/cciss_scsi.c - 1.1 linux/Documentation/block/request.txt - 1.1 linux/drivers/block/cciss_scsi.h - 1.1 linux/drivers/net/Makefile.lib - 1.1 linux/drivers/usb/Makefile.lib - 1.1 linux/fs/Makefile.lib - 1.1 linux/include/linux/crc32.h - 1.1 linux/lib/Config.in - 1.1 linux/lib/crc32.c - 1.1 linux/net/sunrpc/xprt.c - 1.21 linux/net/sunrpc/sched.c - 1.23 linux/net/ipv6/tcp_ipv6.c - 1.32 linux/net/ipv4/icmp.c - 1.25 linux/net/bridge/br.c - 1.21 linux/net/README - 1.10 linux/net/Config.in - 1.19 linux/mm/swapfile.c - 1.48 linux/mm/page_io.c - 1.22 linux/lib/Makefile - 1.9 linux/kernel/sched.c - 1.52 linux/kernel/ksyms.c - 1.126 linux/include/linux/swap.h - 1.51 linux/include/linux/sunrpc/clnt.h - 1.8 linux/include/linux/socket.h - 1.10 linux/include/linux/sched.h - 1.54 linux/include/linux/limits.h - 1.4 linux/include/linux/kbd_kern.h - 1.9 linux/include/linux/if_arp.h - 1.13 linux/include/linux/fs.h - 1.142 linux/include/linux/blkdev.h - 1.51 linux/include/asm-sparc64/ttable.h - 1.8 linux/include/asm-sparc64/system.h - 1.15 linux/include/asm-sparc64/spitfire.h - 1.7 linux/include/asm-sparc64/spinlock.h - 1.10 linux/include/asm-sparc64/smplock.h - 1.5 linux/include/asm-sparc64/smp.h - 1.12 linux/include/asm-sparc64/semaphore.h - 1.9 linux/include/asm-sparc64/processor.h - 1.22 linux/include/asm-sparc64/page.h - 1.12 linux/include/asm-sparc64/oplib.h - 1.7 linux/include/asm-sparc64/mmu_context.h - 1.14 linux/include/asm-sparc64/keyboard.h - 1.6 linux/include/asm-sparc64/io.h - 1.19 linux/include/asm-sparc64/elf.h - 1.11 linux/include/asm-sparc64/bitops.h - 1.11 linux/include/asm-sparc/types.h - 1.4 linux/include/asm-sparc/string.h - 1.4 linux/include/asm-sparc/smplock.h - 1.5 linux/include/asm-sparc/smp.h - 1.11 linux/include/asm-sparc/oplib.h - 1.4 linux/include/asm-sparc/mmu_context.h - 1.6 linux/include/asm-sparc/keyboard.h - 1.7 linux/include/asm-sparc/io.h - 1.10 linux/include/asm-sparc/bitops.h - 1.14 linux/fs/namei.c - 1.45 linux/fs/inode.c - 1.62 linux/fs/fat/inode.c - 1.32 linux/fs/fat/cache.c - 1.16 linux/fs/devpts/root.c - 1.13 linux/fs/dcache.c - 1.31 linux/fs/coda/pioctl.c - 1.12 linux/fs/coda/inode.c - 1.17 linux/fs/buffer.c - 1.105 linux/fs/block_dev.c - 1.37 linux/fs/affs/file.c - 1.22 linux/drivers/video/sbusfb.c - 1.19 linux/drivers/scsi/sym53c8xx.c - 1.31 linux/drivers/scsi/scsicam.c - 1.8 linux/drivers/scsi/scsi_syms.c - 1.16 linux/drivers/scsi/scsi_queue.c - 1.12 linux/drivers/scsi/scsi_proc.c - 1.11 linux/drivers/scsi/scsi_ioctl.c - 1.22 linux/drivers/scsi/scsi_error.c - 1.23 linux/drivers/scsi/scsi.c - 1.50 linux/drivers/scsi/ide-scsi.c - 1.23 linux/drivers/scsi/hosts.h - 1.21 linux/drivers/scsi/hosts.c - 1.29 linux/drivers/scsi/constants.c - 1.9 linux/drivers/scsi/advansys.c - 1.22 linux/drivers/sbus/sbus.c - 1.13 linux/drivers/sbus/char/zs.c - 1.22 linux/drivers/sbus/char/sunserial.c - 1.9 linux/drivers/sbus/char/su.c - 1.22 linux/drivers/sbus/char/sab82532.c - 1.25 linux/drivers/sbus/audio/audio.c - 1.17 linux/drivers/net/yellowfin.c - 1.28 linux/drivers/net/via-rhine.c - 1.31 linux/drivers/net/sunqe.c - 1.20 linux/drivers/net/sunlance.c - 1.25 linux/drivers/net/sunhme.c - 1.33 linux/drivers/net/sunbmac.c - 1.21 linux/drivers/net/smc9194.c - 1.18 linux/drivers/net/shaper.c - 1.20 linux/drivers/net/pcnet32.c - 1.29 linux/drivers/net/myri_sbus.c - 1.14 linux/drivers/net/myri_code.h - 1.3 linux/drivers/net/mace.c - 1.16 linux/drivers/net/ewrk3.c - 1.20 linux/drivers/net/epic100.c - 1.26 linux/drivers/net/depca.c - 1.18 linux/drivers/net/de4x5.c - 1.23 linux/drivers/net/bmac.c - 1.18 linux/drivers/net/atp.c - 1.17 linux/drivers/net/at1700.c - 1.16 linux/drivers/net/am79c961a.c - 1.13 linux/drivers/net/a2065.h - 1.5 linux/drivers/net/a2065.c - 1.15 linux/drivers/net/8390.c - 1.24 linux/drivers/net/7990.h - 1.5 linux/drivers/net/7990.c - 1.6 linux/drivers/char/rtc.c - 1.25 linux/drivers/block/nbd.c - 1.32 linux/drivers/block/ll_rw_blk.c - 1.90 linux/drivers/block/Config.in - 1.35 linux/arch/sparc64/solaris/timod.c - 1.17 linux/arch/sparc64/solaris/socksys.c - 1.14 linux/arch/sparc64/solaris/misc.c - 1.21 linux/arch/sparc64/solaris/fs.c - 1.15 linux/arch/sparc64/mm/ultra.S - 1.23 linux/arch/sparc64/mm/init.c - 1.37 linux/arch/sparc64/mm/extable.c - 1.5 linux/arch/sparc64/lib/debuglocks.c - 1.8 linux/arch/sparc64/lib/blockops.S - 1.15 linux/arch/sparc64/kernel/ttable.S - 1.11 linux/arch/sparc64/kernel/traps.c - 1.16 linux/arch/sparc64/kernel/trampoline.S - 1.9 linux/arch/sparc64/kernel/time.c - 1.16 linux/arch/sparc64/kernel/sys_sunos32.c - 1.33 linux/arch/sparc64/kernel/sys_sparc.c - 1.22 linux/arch/sparc64/kernel/sparc64_ksyms.c - 1.37 linux/arch/sparc64/kernel/smp.c - 1.34 linux/arch/sparc64/kernel/signal32.c - 1.18 linux/arch/sparc64/kernel/signal.c - 1.16 linux/arch/sparc64/kernel/rtrap.S - 1.11 linux/arch/sparc64/kernel/process.c - 1.26 linux/arch/sparc64/kernel/irq.c - 1.22 linux/arch/sparc64/kernel/ioctl32.c - 1.48 linux/arch/sparc64/kernel/entry.S - 1.18 linux/arch/sparc64/kernel/check_asm.sh - 1.6 linux/arch/sparc64/kernel/central.c - 1.5 linux/arch/sparc64/kernel/Makefile - 1.20 linux/arch/sparc64/defconfig - 1.55 linux/arch/sparc64/config.in - 1.47 linux/arch/sparc64/Makefile - 1.15 linux/arch/sparc/prom/ranges.c - 1.5 linux/arch/sparc/mm/iommu.c - 1.11 linux/arch/sparc/mm/io-unit.c - 1.12 linux/arch/sparc/mm/init.c - 1.28 linux/arch/sparc/mm/fault.c - 1.18 linux/arch/sparc/mm/extable.c - 1.6 linux/arch/sparc/kernel/unaligned.c - 1.7 linux/arch/sparc/kernel/trampoline.S - 1.4 linux/arch/sparc/kernel/sys_sunos.c - 1.32 linux/arch/sparc/kernel/sun4m_smp.c - 1.18 linux/arch/sparc/kernel/sun4d_smp.c - 1.18 linux/arch/sparc/kernel/sun4d_irq.c - 1.13 linux/arch/sparc/kernel/signal.c - 1.19 linux/arch/sparc/kernel/process.c - 1.23 linux/arch/sparc/kernel/irq.c - 1.19 linux/arch/sparc/kernel/init_task.c - 1.5 linux/arch/sparc/kernel/ebus.c - 1.13 linux/arch/sparc/kernel/devices.c - 1.4 linux/arch/sparc/kernel/check_asm.sh - 1.6 linux/arch/sparc/config.in - 1.31 linux/arch/ppc/config.in - 1.42 linux/arch/mips/config.in - 1.25 linux/arch/m68k/config.in - 1.24 linux/arch/i386/kernel/setup.c - 1.65 linux/arch/i386/defconfig - 1.89 linux/arch/i386/config.in - 1.70 linux/arch/arm/config.in - 1.31 linux/arch/alpha/config.in - 1.39 linux/Makefile - 1.174 linux/Documentation/networking/ip-sysctl.txt - 1.10 linux/Documentation/Configure.help - 1.125 linux/drivers/sbus/char/aurora.c - 1.18 linux/drivers/net/declance.c - 1.13 linux/drivers/block/cpqarray.c - 1.40 linux/arch/sparc64/lib/atomic.S - 1.4 linux/fs/partitions/msdos.c - 1.17 linux/drivers/net/sis900.c - 1.29 linux/arch/sparc64/kernel/semaphore.c - 1.8 linux/arch/sparc64/kernel/power.c - 1.7 linux/arch/sparc64/kernel/pci_sabre.c - 1.27 linux/arch/sparc64/kernel/pci_psycho.c - 1.24 linux/arch/sparc64/kernel/pci_iommu.c - 1.14 linux/arch/sh/config.in - 1.21 linux/include/math-emu/soft-fp.h - 1.3 linux/include/math-emu/single.h - 1.3 linux/include/math-emu/quad.h - 1.3 linux/include/math-emu/op-common.h - 1.3 linux/include/math-emu/op-8.h - 1.2 linux/include/math-emu/op-4.h - 1.2 linux/include/math-emu/op-2.h - 1.4 linux/include/math-emu/op-1.h - 1.3 linux/include/math-emu/extended.h - 1.3 linux/include/math-emu/double.h - 1.3 linux/include/asm-sparc/pci.h - 1.11 linux/drivers/net/starfire.c - 1.22 linux/drivers/net/dmfe.c - 1.22 linux/drivers/net/pcmcia/fmvj18x_cs.c - 1.15 linux/drivers/net/pcmcia/smc91c92_cs.c - 1.15 linux/mm/highmem.c - 1.34 linux/mm/bootmem.c - 1.18 linux/drivers/net/sk98lin/h/skdrv1st.h - 1.7 linux/drivers/net/sk98lin/skaddr.c - 1.5 linux/drivers/sound/trident.c - 1.31 linux/drivers/scsi/scsi_merge.c - 1.36 linux/drivers/scsi/scsi_lib.c - 1.42 linux/arch/sparc64/kernel/sbus.c - 1.14 linux/arch/sparc64/kernel/iommu_common.c - 1.9 linux/fs/openpromfs/inode.c - 1.15 linux/drivers/telephony/phonedev.c - 1.8 linux/drivers/scsi/scsi_scan.c - 1.22 linux/drivers/net/macmace.c - 1.5 linux/arch/ia64/config.in - 1.21 linux/drivers/net/gmac.c - 1.12 linux/drivers/net/8139too.c - 1.32 linux/Documentation/filesystems/devfs/ChangeLog - 1.17 linux/fs/devfs/base.c - 1.28 linux/net/bridge/br_device.c - 1.6 linux/net/bridge/br_private.h - 1.7 linux/net/bridge/br_input.c - 1.9 linux/net/bridge/br_if.c - 1.6 linux/drivers/net/tulip/tulip_core.c - 1.36 linux/drivers/net/ioc3-eth.c - 1.16 linux/arch/mips64/config.in - 1.16 linux/drivers/net/bonding.c - 1.9 linux/include/linux/if_bonding.h - 1.4 linux/drivers/block/elevator.c - 1.15 linux/net/ipv4/netfilter/ipt_unclean.c - 1.7 linux/net/ipv4/netfilter/ipt_TOS.c - 1.8 linux/net/ipv4/netfilter/ipt_MIRROR.c - 1.8 linux/net/ipv4/netfilter/ip_nat_core.c - 1.9 linux/net/ipv4/netfilter/ip_fw_compat_redir.c - 1.3 linux/net/ipv4/netfilter/ip_fw_compat.c - 1.11 linux/net/ipv4/netfilter/ip_conntrack_standalone.c - 1.11 linux/include/linux/netfilter_ipv4/ip_conntrack_tuple.h - 1.5 linux/include/linux/netfilter_ipv4/ip_conntrack.h - 1.9 linux/drivers/net/pcmcia/xircom_tulip_cb.c - 1.19 linux/arch/sparc64/lib/bitops.S - 1.3 linux/arch/s390/config.in - 1.10 linux/kdb/modules/kdbm_vm.c - 1.18 linux/arch/sparc64/lib/dec_and_lock.S - 1.3 linux/drivers/sbus/char/display7seg.c - 1.4 linux/drivers/net/natsemi.c - 1.18 linux/drivers/md/raid5.c - 1.25 linux/Documentation/cciss.txt - 1.4 linux/drivers/block/cciss.c - 1.27 linux/drivers/block/cciss.h - 1.8 linux/drivers/block/cciss_cmd.h - 1.7 linux/drivers/md/md.c - 1.37 linux/drivers/net/sundance.c - 1.12 linux/drivers/net/winbond-840.c - 1.14 linux/drivers/sound/ymfpci.h - 1.6 linux/drivers/sound/ymfpci.c - 1.17 linux/arch/parisc/config.in - 1.3 linux/include/linux/shmem_fs.h - 1.4 linux/fs/reiserfs/tail_conversion.c - 1.9 linux/arch/sparc64/kernel/pci_schizo.c - 1.12 linux/fs/reiserfs/journal.c - 1.17 linux/include/linux/reiserfs_fs.h - 1.16 linux/include/linux/reiserfs_fs_sb.h - 1.6 linux/fs/reiserfs/bitmap.c - 1.10 linux/drivers/sbus/char/cpwatchdog.c - 1.5 linux/arch/cris/config.in - 1.8 linux/drivers/s390/char/tapedefs.h - 1.4 linux/arch/s390x/config.in - 1.5 linux/drivers/s390/block/xpram.c - 1.10 linux/drivers/net/pci-skeleton.c - 1.9 linux/net/ipv4/netfilter/ipt_TCPMSS.c - 1.5 linux/drivers/scsi/aic7xxx/aic7xxx_osm.h - 1.8 linux/drivers/scsi/aic7xxx/aic7xxx_linux.c - 1.12 linux/drivers/net/sungem.h - 1.4 linux/drivers/net/sungem.c - 1.12 linux/arch/sparc64/kernel/chmc.c - 1.2 linux/net/ipv4/netfilter/ip_nat_helper.c - 1.3 linux/include/asm-sparc64/rwsem.h - 1.2 linux/drivers/net/fealnx.c - 1.9 linux/drivers/usb/catc.c - 1.6 linux/drivers/net/au1000_eth.c - 1.3 linux/drivers/net/dl2k.h - 1.5 linux/drivers/net/dl2k.c - 1.7 linux/drivers/video/aty/mach64_accel.c - 1.2 linux/drivers/s390/block/dasd_int.h - 1.4 linux/fs/jffs2/Makefile - 1.3 linux/fs/jffs2/crc32.c - 1.2 linux/fs/jffs2/crc32.h - 1.2 linux/fs/jffs2/dir.c - 1.3 linux/fs/jffs2/erase.c - 1.3 linux/fs/jffs2/file.c - 1.4 linux/fs/jffs2/gc.c - 1.4 linux/fs/jffs2/read.c - 1.2 linux/fs/jffs2/readinode.c - 1.2 linux/fs/jffs2/scan.c - 1.3 linux/fs/jffs2/write.c - 1.4 linux/drivers/md/multipath.c - 1.5 linux/drivers/message/i2o/i2o_block.c - 1.8 linux/drivers/net/8139cp.c - 1.4 linux/net/ipv4/netfilter/ip_nat_irc.c - 1.2 linux/net/ipv4/netfilter/ip_conntrack_irc.c - 1.2 linux/net/8021q/vlanproc.c - 1.4 linux/net/8021q/vlan_dev.c - 1.2 linux/net/8021q/vlan.c - 1.2 linux/fs/jbd/journal.c - 1.5 linux/drivers/scsi/sym53c8xx_2/sym_glue.c - 1.4 linux/fs/intermezzo/presto.c - 1.4 linux/fs/intermezzo/psdev.c - 1.4 linux/fs/intermezzo/sysctl.c - 1.3 linux/fs/intermezzo/vfs.c - 1.3 linux/fs/jbd/revoke.c - 1.4 linux/fs/jbd/transaction.c - 1.4 linux/fs/intermezzo/cache.c - 1.2 linux/fs/driverfs/inode.c - 1.2 linux/drivers/net/de2104x.c - 1.3 linux/drivers/usb/hcd.c - 1.3 linux/drivers/usb/hcd/ehci-hcd.c - 1.2 linux/drivers/usb/hcd/ehci-sched.c - 1.2 From owner-linux-xfs@oss.sgi.com Tue Jan 15 11:27:32 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0FJRW729830 for linux-xfs-outgoing; Tue, 15 Jan 2002 11:27:32 -0800 Received: from ahriman.bucharest.roedu.net (ahriman.bucharest.roedu.net [141.85.128.71]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0FJRQP29808 for ; Tue, 15 Jan 2002 11:27:26 -0800 Received: (qmail 16810 invoked by uid 1000); 15 Jan 2002 18:31:57 -0000 Received: from localhost (sendmail-bs@127.0.0.1) by localhost with SMTP; 15 Jan 2002 18:31:57 -0000 Date: Tue, 15 Jan 2002 20:31:57 +0200 (EET) From: Mihai RUSU X-X-Sender: To: Linux XFS List Subject: problems with 2.4.9-13SGI_XFS_1.0.2custom Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 719 Lines: 23 hi i had experienced some compilation problems with subject. i used the kernel-source rpm from /projects/xfs/download/Release-1.0.2/ kernel_rpms/i386/2.4.9-13RH7.2/ i tried to compile a costum kernel using egcs 2.91.66 (comes with slackware 8) and the compilation fails while compiling the tulip.c eth driver i cant paste a error output or a .config file right now couse that was on a client machine and we dont use tulip eth cards. i thought maybe someone has some time to ckeck it out. PS: no modules, no apm/pm, no incomplete code/drivers, XFS (without ACL/quota/realtime/DMAPI), tulip.c builtin kernel eth driver thanks ---------------------------- Mihai RUSU "... and what if this is as good as it gets ?" From owner-linux-xfs@oss.sgi.com Tue Jan 15 12:34:05 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0FKY5Z31203 for linux-xfs-outgoing; Tue, 15 Jan 2002 12:34:05 -0800 Received: from maple.sucs.soton.ac.uk (maple.sucs.soton.ac.uk [152.78.128.16]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0FKXoP31181 for ; Tue, 15 Jan 2002 12:33:51 -0800 Received: from poplar.sucs.soton.ac.uk (poplar.sucs.soton.ac.uk [152.78.128.30]) by maple.sucs.soton.ac.uk (8.10.0/8.10.0) with ESMTP id g0FJXkH28796 for ; Tue, 15 Jan 2002 19:33:46 GMT Received: from soton.ac.uk (pluto.sucs.soton.ac.uk [152.78.128.80]) (authenticated as idh) by poplar.sucs.soton.ac.uk (8.10.0/8.10.0) with ESMTP id g0FJXd224697; Tue, 15 Jan 2002 19:33:39 GMT Message-ID: <3C448413.3FF98CB1@soton.ac.uk> Date: Tue, 15 Jan 2002 19:33:39 +0000 From: "Ian D. Hardy" Organization: University of Southampton X-Mailer: Mozilla 4.7C-SGI [en] (X11; I; IRIX 6.5 IP32) X-Accept-Language: en MIME-Version: 1.0 To: linux-xfs@oss.sgi.com Subject: XFS/NFS server oops ..... any ideas. Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-MailScanner: Believed to be clean Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 4923 Lines: 112 Hi, For some time we've been having problem with a server, which is acting as a master/control node and NFS server for a computational cluster (~180 client nodes). The server will crash after anywhere between a few hours and 10 days operation. We've tried various kernels and XFS patch versions from 2.4.9 kernel with XFS patch-2.4.9-xfs-2001-08-17 up to and including 2.4.16 kernel with the xfs-2.4.16-all-i386 patch, if anything the 2.4.9 kernel has proved the most reliable (it normally lasts between 4 and 10 days! - 2.4.16 lasted less than 24hrs). I've just recovered and processed the following Oops from the most recent crash (running 2.4.9 kernel), ksymoops output below which would appear to point to a problem in the XFS kernel code as called from the nfsd daemon process. The server is a dual (1Ghz PIII) based on a SuperMicro ServerWorks LE motherboard with 1Gbyte RAM, 40Gbyte Maxtor system disk and a QLogic QLA2200 FC card connecting an external HW (IDE) RAID array. Its got a RedHat 6.2 based distro but with the 2.4.x series kernel and XFS patches. (We're just starting to run some controlled tests with a similar server with a RH 7.2 distro and 2.4.14 kernel/XFS 1.0.2 release and or 2.4.17 and latest XFS patch release). Anyone any ideas what is causing this? or better still how to fix it? Thanks Ian - Unable to handle kernel NULL pointer dereference at virtual address 00000030 c0192c29 *pde = 00000000 Oops: 0000 CPU: 0 EIP: 0010:[] Using defaults from ksymoops -t elf32-i386 -a i386 EFLAGS: 00010246 eax: 00000000 ebx: 0000000a ecx: 00000000 edx: 00000000 esi: 00000000 edi: 00002001 ebp: 00000000 esp: f527fb6c ds: 0018 es: 0018 ss: 0018 Process nfsd (pid: 592, stackpage=f527f000) Stack: d604fe4c 00000000 00000000 f527fc54 00025960 00000010 d7625912 f70e7964 d7625980 00000000 00000001 00027961 f527fbd0 f70e7800 00000286 109ae350 00000000 00000000 e935d010 00000000 00000085 f70e7800 e935d000 00000757 Call Trace: [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] Code: 8b 52 30 89 54 24 58 51 55 8b 44 24 60 50 8b 54 24 78 52 e8 >>EIP; c0192c28 <===== Trace; c01947d0 Trace; c01905ee Trace; c01dd9aa Trace; c0191786 Trace; c01ded2e Trace; c01a3a08 Trace; c01cb172 Trace; c01e27c2 Trace; c01e1cb0 Trace; f8d6831a <[sunrpc]svc_udp_data_ready+5e/bc> Trace; c0280f8c Trace; c01ee286 Trace; f8da0dda <[nfsd]nfsd_iget+f6/110> Trace; c01e1cb0 Trace; c014d6f0 Trace; f8da291e <[nfsd]nfsd_setattr+426/564> Trace; f8da7dea <[nfsd]nfsd3_proc_setattr+b6/c4> Trace; f8db0320 <[nfsd]nfsd_procedures3+40/2c0> Trace; f8d9f5a2 <[nfsd]nfsd_dispatch+ca/168> Trace; f8db0320 <[nfsd]nfsd_procedures3+40/2c0> Trace; f8d67c88 <[sunrpc]svc_process+2ac/544> Trace; f8db0280 <[nfsd]nfsd_svcstats+0/40> Trace; f8dafd78 <[nfsd]nfsd_version3+0/10> Trace; f8d9f348 <[nfsd]nfsd+1b8/348> Trace; c010576e Code; c0192c28 00000000 <_EIP>: Code; c0192c28 <===== 0: 8b 52 30 mov 0x30(%edx),%edx <===== Code; c0192c2a 3: 89 54 24 58 mov %edx,0x58(%esp,1) Code; c0192c2e 7: 51 push %ecx Code; c0192c30 8: 55 push %ebp Code; c0192c30 9: 8b 44 24 60 mov 0x60(%esp,1),%eax Code; c0192c34 d: 50 push %eax Code; c0192c36 e: 8b 54 24 78 mov 0x78(%esp,1),%edx Code; c0192c3a 12: 52 push %edx Code; c0192c3a 13: e8 00 00 00 00 call 18 <_EIP+0x18> c0192c40 -- /////////////Technical Coordination, Research Services//////////////////// Ian Hardy Tel: 023 80 593577 Computing Services Southampton University email: idh@soton.ac.uk Southampton S017 1BJ, UK. i.d.hardy@soton.ac.uk \\'BUGS: The notion of errors is ill-defined' (IRIX man page for netstat)\ From owner-linux-xfs@oss.sgi.com Tue Jan 15 12:56:02 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0FKu2m31808 for linux-xfs-outgoing; Tue, 15 Jan 2002 12:56:02 -0800 Received: from woody.fsl.noaa.gov (woody.fsl.noaa.gov [137.75.132.225]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0FKtlP31785 for ; Tue, 15 Jan 2002 12:55:47 -0800 Received: (from tierney@localhost) by woody.fsl.noaa.gov (8.11.6/8.11.6) id g0FJrwP17541; Tue, 15 Jan 2002 12:53:58 -0700 Date: Tue, 15 Jan 2002 12:53:58 -0700 From: Craig Tierney To: "Ian D. Hardy" Cc: linux-xfs@oss.sgi.com Subject: Re: XFS/NFS server oops ..... any ideas. Message-ID: <20020115125358.H17367@hpti.com> References: <3C448413.3FF98CB1@soton.ac.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <3C448413.3FF98CB1@soton.ac.uk>; from i.d.hardy@soton.ac.uk on Tue, Jan 15, 2002 at 07:33:39PM +0000 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 5364 Lines: 122 Can you trigger the problem easily if you startup a dd process writing to the disk over nfs from twenty different nodes simultaneously (different files, same filesystem)? Craig > Hi, > > For some time we've been having problem with a server, which is acting > as a master/control node and NFS server for a computational cluster > (~180 client nodes). The server will crash after anywhere between > a few hours and 10 days operation. We've tried various kernels and > XFS patch versions from 2.4.9 kernel with XFS patch-2.4.9-xfs-2001-08-17 > up to and including 2.4.16 kernel with the xfs-2.4.16-all-i386 patch, > if anything the 2.4.9 kernel has proved the most reliable (it normally > lasts between 4 and 10 days! - 2.4.16 lasted less than 24hrs). > > I've just recovered and processed the following Oops from the most > recent crash (running 2.4.9 kernel), ksymoops output below which would > appear to point to a problem in the XFS kernel code as called from the > nfsd daemon process. > > The server is a dual (1Ghz PIII) based on a SuperMicro ServerWorks LE > motherboard with 1Gbyte RAM, 40Gbyte Maxtor system disk and a QLogic > QLA2200 FC card connecting an external HW (IDE) RAID array. Its got > a RedHat 6.2 based distro but with the 2.4.x series kernel and XFS > patches. (We're just starting to run some controlled tests with a similar > server with a RH 7.2 distro and 2.4.14 kernel/XFS 1.0.2 release and or > 2.4.17 and latest XFS patch release). > > Anyone any ideas what is causing this? or better still how to fix it? > > Thanks > > Ian > > - > > Unable to handle kernel NULL pointer dereference at virtual address 00000030 > c0192c29 > *pde = 00000000 > Oops: 0000 > CPU: 0 > EIP: 0010:[] > Using defaults from ksymoops -t elf32-i386 -a i386 > EFLAGS: 00010246 > eax: 00000000 ebx: 0000000a ecx: 00000000 edx: 00000000 > esi: 00000000 edi: 00002001 ebp: 00000000 esp: f527fb6c > ds: 0018 es: 0018 ss: 0018 > Process nfsd (pid: 592, stackpage=f527f000) > Stack: d604fe4c 00000000 00000000 f527fc54 00025960 00000010 d7625912 f70e7964 > d7625980 00000000 00000001 00027961 f527fbd0 f70e7800 00000286 109ae350 > 00000000 00000000 e935d010 00000000 00000085 f70e7800 e935d000 00000757 > Call Trace: [] [] [] [] [] > [] [] [] [] [] [] > [] [] [] [] [] [] > [] [] [] [] [] [] > [] [] > Code: 8b 52 30 89 54 24 58 51 55 8b 44 24 60 50 8b 54 24 78 52 e8 > > >>EIP; c0192c28 <===== > Trace; c01947d0 > Trace; c01905ee > Trace; c01dd9aa > Trace; c0191786 > Trace; c01ded2e > Trace; c01a3a08 > Trace; c01cb172 > Trace; c01e27c2 > Trace; c01e1cb0 > Trace; f8d6831a <[sunrpc]svc_udp_data_ready+5e/bc> > Trace; c0280f8c > Trace; c01ee286 > Trace; f8da0dda <[nfsd]nfsd_iget+f6/110> > Trace; c01e1cb0 > Trace; c014d6f0 > Trace; f8da291e <[nfsd]nfsd_setattr+426/564> > Trace; f8da7dea <[nfsd]nfsd3_proc_setattr+b6/c4> > Trace; f8db0320 <[nfsd]nfsd_procedures3+40/2c0> > Trace; f8d9f5a2 <[nfsd]nfsd_dispatch+ca/168> > Trace; f8db0320 <[nfsd]nfsd_procedures3+40/2c0> > Trace; f8d67c88 <[sunrpc]svc_process+2ac/544> > Trace; f8db0280 <[nfsd]nfsd_svcstats+0/40> > Trace; f8dafd78 <[nfsd]nfsd_version3+0/10> > Trace; f8d9f348 <[nfsd]nfsd+1b8/348> > Trace; c010576e > Code; c0192c28 > 00000000 <_EIP>: > Code; c0192c28 <===== > 0: 8b 52 30 mov 0x30(%edx),%edx <===== > Code; c0192c2a > 3: 89 54 24 58 mov %edx,0x58(%esp,1) > Code; c0192c2e > 7: 51 push %ecx > Code; c0192c30 > 8: 55 push %ebp > Code; c0192c30 > 9: 8b 44 24 60 mov 0x60(%esp,1),%eax > Code; c0192c34 > d: 50 push %eax > Code; c0192c36 > e: 8b 54 24 78 mov 0x78(%esp,1),%edx > Code; c0192c3a > 12: 52 push %edx > Code; c0192c3a > 13: e8 00 00 00 00 call 18 <_EIP+0x18> c0192c40 > > > > -- > > /////////////Technical Coordination, Research Services//////////////////// > Ian Hardy Tel: 023 80 593577 > Computing Services > Southampton University email: idh@soton.ac.uk > Southampton S017 1BJ, UK. i.d.hardy@soton.ac.uk > \\'BUGS: The notion of errors is ill-defined' (IRIX man page for netstat)\ -- Craig Tierney (ctierney@hpti.com) From owner-linux-xfs@oss.sgi.com Tue Jan 15 13:27:10 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0FLRAT02064 for linux-xfs-outgoing; Tue, 15 Jan 2002 13:27:10 -0800 Received: from deliverator.sgi.com (deliverator.sgi.com [204.94.214.10]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0FLR4P02041 for ; Tue, 15 Jan 2002 13:27:04 -0800 Received: from zeus-e8.americas.sgi.com (zeus-e8.americas.sgi.com [128.162.8.103]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id MAA09218 for ; Tue, 15 Jan 2002 12:22:40 -0800 (PST) mail_from (sandeen@sgi.com) Received: from poppy-e185.americas.sgi.com (poppy-e185.americas.sgi.com [128.162.185.207]) by zeus-e8.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id OAA11146; Tue, 15 Jan 2002 14:25:39 -0600 (CST) Received: from stout.americas.sgi.com (stout.americas.sgi.com [128.162.187.5]) by poppy-e185.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.7) with ESMTP id OAA38693; Tue, 15 Jan 2002 14:25:38 -0600 (CST) Subject: Re: attr_get() limited to 3061 bytes From: Eric Sandeen To: "ZINKEVICIUS,MATT ""(HP-Loveland,ex1)" Cc: "'linux-xfs@oss.sgi.com'" In-Reply-To: References: Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/1.0 (Preview Release) Date: 15 Jan 2002 14:25:38 -0600 Message-Id: <1011126338.31670.14.camel@stout.americas.sgi.com> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 1055 Lines: 34 On Mon, 2002-01-14 at 15:47, ZINKEVICIUS,MATT (HP-Loveland,ex1) wrote: > Howdy... More opportunities for printers :-) > > The attr_get() call returns a zero filled buffer if the size value is > greater than 3061 bytes. Hm, perhaps this has something to do with the fact that we were reading memory into the attribute data when we were setting the attribute, and reading the data into memory when we were getting the attribute... which is quite backwards! See if this does the trick for you... --- /usr/tmp/TmpDir.1648-0/linux/fs/xfs/xfs_buf.h Tue Jan 15 14:22:53 2002 +++ linux/fs/xfs/xfs_buf.h Tue Jan 15 14:10:10 2002 @@ -252,7 +252,7 @@ #define xfs_biomove(pb, off, len, data, rw) \ pagebuf_iomove((pb), (off), (len), (data), \ - ((rw) == XFS_B_WRITE) ? PBRW_READ : PBRW_WRITE) + ((rw) == XFS_B_WRITE) ? PBRW_WRITE : PBRW_READ) #define xfs_biozero(pb, off, len) \ pagebuf_iomove((pb), (off), (len), NULL, PBRW_ZERO) -Eric -- Eric Sandeen XFS for Linux http://oss.sgi.com/projects/xfs sandeen@sgi.com SGI, Inc. From owner-linux-xfs@oss.sgi.com Tue Jan 15 13:45:31 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0FLjVl03321 for linux-xfs-outgoing; Tue, 15 Jan 2002 13:45:31 -0800 Received: from pneumatic-tube.sgi.com (pneumatic-tube.sgi.com [204.94.214.22]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0FLjRP03299 for ; Tue, 15 Jan 2002 13:45:27 -0800 Received: from zeus-e8.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103] (may be forged)) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id MAA05573 for ; Tue, 15 Jan 2002 12:46:10 -0800 (PST) mail_from (sandeen@sgi.com) Received: from poppy-e185.americas.sgi.com (poppy-e185.americas.sgi.com [128.162.185.207]) by zeus-e8.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id OAA11382; Tue, 15 Jan 2002 14:44:07 -0600 (CST) Received: from stout.americas.sgi.com (stout.americas.sgi.com [128.162.187.5]) by poppy-e185.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.7) with ESMTP id OAA45227; Tue, 15 Jan 2002 14:44:06 -0600 (CST) Subject: Re: attr_get() limited to 3061 bytes From: Eric Sandeen To: Eric Sandeen Cc: "ZINKEVICIUS,MATT ""(HP-Loveland,ex1)" , "'linux-xfs@oss.sgi.com'" In-Reply-To: <1011126338.31670.14.camel@stout.americas.sgi.com> References: <1011126338.31670.14.camel@stout.americas.sgi.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/1.0 (Preview Release) Date: 15 Jan 2002 14:44:06 -0600 Message-Id: <1011127446.31670.17.camel@stout.americas.sgi.com> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 670 Lines: 20 On Tue, 2002-01-15 at 14:25, I wrote: > Hm, perhaps this has something to do with the fact that we were reading > memory into the attribute data when we were setting the attribute, and > reading the data into memory when we were getting the attribute... which > is quite backwards! Hm, that didn't make any sense, did it! Just trust that we had some read/write inversion going on. :) And the reason this got hit at 3061 bytes is that that's the crossover point for 2 different methods of storing attribute data. Smaller attributes would not hit this bug. -Eric -- Eric Sandeen XFS for Linux http://oss.sgi.com/projects/xfs sandeen@sgi.com SGI, Inc. From owner-linux-xfs@oss.sgi.com Tue Jan 15 13:54:17 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0FLsHG03641 for linux-xfs-outgoing; Tue, 15 Jan 2002 13:54:17 -0800 Received: from yog-sothoth.sgi.com (eugate.sgi.com [192.48.160.10]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0FLsBP03618 for ; Tue, 15 Jan 2002 13:54:11 -0800 Received: from zeus-e8.americas.sgi.com (zeus-e8.americas.sgi.com [128.162.8.103]) by yog-sothoth.sgi.com (980305.SGI.8.8.8-aspam-6.2/980304.SGI-aspam-europe) via ESMTP id VAA2077693 for ; Tue, 15 Jan 2002 21:54:22 +0100 (CET) mail_from (eric@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by zeus-e8.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id OAA11497 for ; Tue, 15 Jan 2002 14:52:49 -0600 (CST) Received: from stout.americas.sgi.com (stout.americas.sgi.com [128.162.187.5]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id OAA13134 for ; Tue, 15 Jan 2002 14:52:49 -0600 (CST) Received: by stout.americas.sgi.com (8.11.6/SGI-client-1.7) id g0FKqnN01797; Tue, 15 Jan 2002 14:52:49 -0600 Message-Id: <200201152052.g0FKqnN01797@stout.americas.sgi.com> Date: Tue, 15 Jan 2002 14:52:49 -0600 From: Eric Sandeen Subject: TAKE - fix out-of-line attribute data Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 471 Lines: 16 xfs_biomove was incorrectly #defined, it was mixing up the read and write flags passed to pagebuf_iomove. Date: Tue Jan 15 12:47:45 PST 2002 Workarea: stout.americas.sgi.com:/localhome/eric/2.4.x-xfs/workarea-reallyclean The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:109643a linux/fs/xfs/xfs_buf.h - 1.79 - We had some read/write inversion going on - this would mess up out-of-line attribute data. From owner-linux-xfs@oss.sgi.com Tue Jan 15 13:58:15 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0FLwFD04124 for linux-xfs-outgoing; Tue, 15 Jan 2002 13:58:15 -0800 Received: from yog-sothoth.sgi.com (eugate.sgi.com [192.48.160.10]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0FLvxP04027 for ; Tue, 15 Jan 2002 13:57:59 -0800 Received: from zeus-e8.americas.sgi.com (zeus-e8.americas.sgi.com [128.162.8.103]) by yog-sothoth.sgi.com (980305.SGI.8.8.8-aspam-6.2/980304.SGI-aspam-europe) via ESMTP id VAA2062709 for ; Tue, 15 Jan 2002 21:58:09 +0100 (CET) mail_from (lord@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by zeus-e8.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id OAA11541; Tue, 15 Jan 2002 14:56:35 -0600 (CST) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id OAA90123; Tue, 15 Jan 2002 14:56:31 -0600 (CST) Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id g0FKsVm28731; Tue, 15 Jan 2002 14:54:31 -0600 Subject: Re: XFS/NFS server oops ..... any ideas. From: Steve Lord To: "Ian D. Hardy" Cc: linux-xfs@oss.sgi.com In-Reply-To: <3C448413.3FF98CB1@soton.ac.uk> References: <3C448413.3FF98CB1@soton.ac.uk> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/1.0.1 Date: 15 Jan 2002 14:54:31 -0600 Message-Id: <1011128071.13534.127.camel@jen.americas.sgi.com> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 1772 Lines: 44 On Tue, 2002-01-15 at 13:33, Ian D. Hardy wrote: > Hi, > > For some time we've been having problem with a server, which is acting > as a master/control node and NFS server for a computational cluster > (~180 client nodes). The server will crash after anywhere between > a few hours and 10 days operation. We've tried various kernels and > XFS patch versions from 2.4.9 kernel with XFS patch-2.4.9-xfs-2001-08-17 > up to and including 2.4.16 kernel with the xfs-2.4.16-all-i386 patch, > if anything the 2.4.9 kernel has proved the most reliable (it normally > lasts between 4 and 10 days! - 2.4.16 lasted less than 24hrs). > > I've just recovered and processed the following Oops from the most > recent crash (running 2.4.9 kernel), ksymoops output below which would > appear to point to a problem in the XFS kernel code as called from the > nfsd daemon process. > > The server is a dual (1Ghz PIII) based on a SuperMicro ServerWorks LE > motherboard with 1Gbyte RAM, 40Gbyte Maxtor system disk and a QLogic > QLA2200 FC card connecting an external HW (IDE) RAID array. Its got > a RedHat 6.2 based distro but with the 2.4.x series kernel and XFS > patches. (We're just starting to run some controlled tests with a similar > server with a RH 7.2 distro and 2.4.14 kernel/XFS 1.0.2 release and or > 2.4.17 and latest XFS patch release). > > Anyone any ideas what is causing this? or better still how to fix it? > > Thanks > > Ian > Almost certainly this is an out of memory condition, just from looking at the code in the function you oopsed in. Would you say your system is stressed when it comes to memory? Steve -- Steve Lord voice: +1-651-683-3511 Principal Engineer, Filesystem Software email: lord@sgi.com From owner-linux-xfs@oss.sgi.com Tue Jan 15 15:29:46 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0FNTkG07890 for linux-xfs-outgoing; Tue, 15 Jan 2002 15:29:46 -0800 Received: from maple.sucs.soton.ac.uk (maple.sucs.soton.ac.uk [152.78.128.16]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0FNTcP07868 for ; Tue, 15 Jan 2002 15:29:38 -0800 Received: from plum.sucs.soton.ac.uk (plum.sucs.soton.ac.uk [152.78.128.10]) by maple.sucs.soton.ac.uk (8.10.0/8.10.0) with ESMTP id g0FMTYH07204; Tue, 15 Jan 2002 22:29:34 GMT From: "Ian D. Hardy" Received: (from idh@localhost) by plum.sucs.soton.ac.uk (8.9.3/8.9.3) id WAA440925; Tue, 15 Jan 2002 22:29:34 GMT Message-Id: <200201152229.WAA440925@plum.sucs.soton.ac.uk> Subject: Re: XFS/NFS server oops ..... any ideas. To: lord@sgi.com (Steve Lord) Date: Tue, 15 Jan 2002 22:29:33 +0000 (GMT) Cc: i.d.hardy@soton.ac.uk (Ian D. Hardy), linux-xfs@oss.sgi.com In-Reply-To: <1011128071.13534.127.camel@jen.americas.sgi.com> from "Steve Lord" at Jan 15, 2002 02:54:31 PM X-Mailer: ELM [version 2.5 PL2] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 2483 Lines: 57 > > On Tue, 2002-01-15 at 13:33, Ian D. Hardy wrote: > > Hi, > > > > For some time we've been having problem with a server, which is acting > > as a master/control node and NFS server for a computational cluster > > (~180 client nodes). The server will crash after anywhere between > > a few hours and 10 days operation. We've tried various kernels and > > XFS patch versions from 2.4.9 kernel with XFS patch-2.4.9-xfs-2001-08-17 > > up to and including 2.4.16 kernel with the xfs-2.4.16-all-i386 patch, > > if anything the 2.4.9 kernel has proved the most reliable (it normally > > lasts between 4 and 10 days! - 2.4.16 lasted less than 24hrs). .... more details deleted > > > > Almost certainly this is an out of memory condition, just from looking > at the code in the function you oopsed in. Would you say your system is > stressed when it comes to memory? > > Steve > > Steve Lord voice: +1-651-683-3511 > Principal Engineer, Filesystem Software email: lord@sgi.com > I'd not regard the server as short of memory as its using ~660Mbytes as file system cache, though interestingly it does appear to be using some swap space. Is it possible that XFS is having problems when there is not memory immediately available, I've included some 'vmstat' output: vmstat 10 10 procs memory swap io system cpu r b w swpd free buff cache si so bi bo in cs us sy id 0 1 28 11116 3784 42300 674656 0 0 37 35 19 3 0 2 23 0 1 28 11116 3480 42300 674960 0 0 0 0 167 194 0 0 100 0 1 28 11116 3176 42300 675264 0 0 0 0 139 107 0 0 100 0 1 28 11116 3056 42300 675380 0 0 0 2 152 142 0 0 100 In Irix I'd tune the kernel parameters 'min_free_pages'... to ensure that there was always physical memory available, is there any equivalent in Linux (sorry if this is a silly/obvious question). Many thanks. Ian -- //////////////////////////////////////////////////////////////////////////// Ian Hardy Tel: 023 80593577 Research Services Fax: 023 80593131 Computing Services email: idh@soton.ac.uk Southampton University i.d.hardy@soton.ac.uk Southampton S017 1BJ, UK. \\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\ From owner-linux-xfs@oss.sgi.com Tue Jan 15 16:12:56 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0G0Cuu09084 for linux-xfs-outgoing; Tue, 15 Jan 2002 16:12:56 -0800 Received: from stumpy.chowhouse.com (root@stumpy.chowhouse.com [209.180.91.165]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0G0CrP09062 for ; Tue, 15 Jan 2002 16:12:53 -0800 Received: from localhost (james@localhost) by stumpy.chowhouse.com (8.11.6/8.11.3) with ESMTP id g0FNEr101801 for ; Tue, 15 Jan 2002 16:14:53 -0700 Date: Tue, 15 Jan 2002 16:14:53 -0700 (MST) From: James Rich To: linux-xfs@oss.sgi.com Subject: OOM difference on IRIX vs. linux Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 520 Lines: 12 Steve, I think you mentioned on this list a while ago that XFS comes from an environment (IRIX) where allocating memory could not fail. At least that is what I understood you to say. Since hardware resources are limited on every platform I'm stumped on how this could be. Could you give a basic explanation of why this works on IRIX but not on linux (without giving away any company secrets :) )? I realize this may be somewhat demanding so you could also tell me to take a hike :) James Rich james@chowhouse.com From owner-linux-xfs@oss.sgi.com Tue Jan 15 16:21:58 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0G0Lwb09473 for linux-xfs-outgoing; Tue, 15 Jan 2002 16:21:58 -0800 Received: from yog-sothoth.sgi.com (eugate.sgi.com [192.48.160.10]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0G0LrP09451 for ; Tue, 15 Jan 2002 16:21:54 -0800 Received: from zeus-e8.americas.sgi.com (zeus-e8.americas.sgi.com [128.162.8.103]) by yog-sothoth.sgi.com (980305.SGI.8.8.8-aspam-6.2/980304.SGI-aspam-europe) via ESMTP id AAA366477 for ; Wed, 16 Jan 2002 00:21:40 +0100 (CET) mail_from (lord@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by zeus-e8.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id RAA13615; Tue, 15 Jan 2002 17:20:28 -0600 (CST) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id RAA16155; Tue, 15 Jan 2002 17:20:28 -0600 (CST) Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id g0FNIRB29009; Tue, 15 Jan 2002 17:18:27 -0600 Subject: Re: OOM difference on IRIX vs. linux From: Steve Lord To: James Rich Cc: linux-xfs@oss.sgi.com In-Reply-To: References: Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/1.0.1 Date: 15 Jan 2002 17:18:27 -0600 Message-Id: <1011136707.13548.249.camel@jen.americas.sgi.com> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 1101 Lines: 27 On Tue, 2002-01-15 at 17:14, James Rich wrote: > Steve, > I think you mentioned on this list a while ago that XFS comes from > an environment (IRIX) where allocating memory could not fail. At least > that is what I understood you to say. Since hardware resources are > limited on every platform I'm stumped on how this could be. Could you > give a basic explanation of why this works on IRIX but not on linux > (without giving away any company secrets :) )? I realize this may be > somewhat demanding so you could also tell me to take a hike :) Does not fail can also mean does not return for a VERY long time. Plus the memory system on Irix has a mechanism where various subsystems which consume memory can register callouts which the memory system can call to ask them to release memory. Linux does not have the latter except for the explicit calls in page_launder or what ever it is called this week. Steve > > James Rich > james@chowhouse.com -- Steve Lord voice: +1-651-683-3511 Principal Engineer, Filesystem Software email: lord@sgi.com From owner-linux-xfs@oss.sgi.com Tue Jan 15 17:02:45 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0G12jL10610 for linux-xfs-outgoing; Tue, 15 Jan 2002 17:02:45 -0800 Received: from sasami.anime.net (anime.net [63.172.78.150]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0G12gP10572 for ; Tue, 15 Jan 2002 17:02:42 -0800 Received: from localhost (goemon@localhost) by sasami.anime.net (8.11.6/8.11.6) with ESMTP id g0G01SL16176; Tue, 15 Jan 2002 16:01:28 -0800 Date: Tue, 15 Jan 2002 16:01:28 -0800 (PST) From: Dan Hollis To: Steve Lord cc: James Rich , Subject: Re: OOM difference on IRIX vs. linux In-Reply-To: <1011136707.13548.249.camel@jen.americas.sgi.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 633 Lines: 16 On 15 Jan 2002, Steve Lord wrote: > Does not fail can also mean does not return for a VERY long time. Plus > the memory system on Irix has a mechanism where various subsystems which > consume memory can register callouts which the memory system can call > to ask them to release memory. Linux does not have the latter except > for the explicit calls in page_launder or what ever it is called this > week. Its too bad theres no signal mechanism for userspace for 'memory low', eg SIGLOWMEM so userspace apps could voluntarily release resources to ease memory pressure. -Dan -- [-] Omae no subete no kichi wa ore no mono da. [-] From owner-linux-xfs@oss.sgi.com Tue Jan 15 17:02:29 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0G12TO10536 for linux-xfs-outgoing; Tue, 15 Jan 2002 17:02:29 -0800 Received: from zok.sgi.com (zok.sgi.com [204.94.215.101]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0G12PP10514 for ; Tue, 15 Jan 2002 17:02:25 -0800 Received: from zeus-e8.americas.sgi.com (zeus-e8.americas.sgi.com [128.162.8.103]) by zok.sgi.com (8.11.4/8.11.4/linux-outbound_gateway-1.1) with ESMTP id g0G02Io30641 for ; Tue, 15 Jan 2002 16:02:18 -0800 Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by zeus-e8.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id SAA14003 for ; Tue, 15 Jan 2002 18:01:02 -0600 (CST) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id SAA59910 for ; Tue, 15 Jan 2002 18:01:02 -0600 (CST) From: Steve Lord Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id g0FNx1h02555; Tue, 15 Jan 2002 17:59:01 -0600 Message-Id: <200201152359.g0FNx1h02555@jen.americas.sgi.com> Date: Tue, 15 Jan 2002 17:59:01 -0600 Subject: TAKE - cleanup xfs default config options Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 745 Lines: 26 Pagebuf was still lurking in here Date: Tue Jan 15 16:00:05 PST 2002 Workarea: jen.americas.sgi.com:/src/lord/xfs-linux.2.4 The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:109662a linux/arch/sparc64/defconfig - 1.56 linux/arch/sparc/defconfig - 1.29 linux/arch/ppc/defconfig - 1.36 linux/arch/mips/defconfig - 1.21 linux/arch/m68k/defconfig - 1.12 linux/arch/i386/defconfig - 1.84 linux/arch/arm/defconfig - 1.19 linux/arch/alpha/defconfig - 1.21 linux/arch/sh/defconfig - 1.18 linux/arch/ia64/defconfig - 1.11 linux/arch/mips64/defconfig - 1.17 linux/arch/s390/defconfig - 1.9 linux/arch/parisc/defconfig - 1.4 linux/arch/cris/defconfig - 1.9 linux/arch/s390x/defconfig - 1.8 From owner-linux-xfs@oss.sgi.com Tue Jan 15 20:33:25 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0G4XPA14257 for linux-xfs-outgoing; Tue, 15 Jan 2002 20:33:25 -0800 Received: from blipvert.blank.org (blipvert.blank.org [216.112.239.86]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0G4XCP14235 for ; Tue, 15 Jan 2002 20:33:13 -0800 Received: (qmail 13932 invoked by uid 500); 16 Jan 2002 03:33:12 -0000 Date: Tue, 15 Jan 2002 22:33:12 -0500 From: "Nathan J. Mehl" To: Nathan Scott Cc: linux-xfs@oss.sgi.com Subject: Re: things to do in brooklyn when your filesystem is dead Message-ID: <20020115223312.G15376@blank.org> Mail-Followup-To: Nathan Scott , linux-xfs@oss.sgi.com References: <20020112122144.R15376@blank.org> <20020114113445.D24972@wobbly.melbourne.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: <20020114113445.D24972@wobbly.melbourne.sgi.com>; from nathans@sgi.com on Mon, Jan 14, 2002 at 11:34:45AM +1100 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 3816 Lines: 86 In the immortal words of Nathan Scott (nathans@sgi.com): > > On Sat, Jan 12, 2002 at 12:21:44PM -0500, Nathan J. Mehl wrote: > > ... > > At this point, I am stymied. xfs_repair will not progress beyond the > > log-clearing step. > > Can you tell me the exact error message you see? > > Is it: > "xlog_find_tail returned error X"? Yup! The error was, and is: Phase 1 - find and verify superblock... sb root inode value 18446744073709551615 inconsistent with calculated value 13835051870529257600 resetting superblock root inode pointer to 18446744069414584448 sb realtime bitmap inode 18446744073709551615 inconsistent with calculated value 13835051870529257601 resetting superblock realtime bitmap ino pointer to 18446744069414584449 sb realtime summary inode 18446744073709551615 inconsistent with calculated value 13835051870529257602 resetting superblock realtime summary ino pointer to 18446744069414584450 Phase 2 - using internal log - zero log... XFS: Log inconsistent (didn't find previous header) XFS: failed to find log head fatal error -- xlog_find_tail returned error 5 > If so, I think this is a recently-introduced repair bug - I'll > check in a fix shortly & you should be able to proceed on with > xfs_repair. Okay, I am a touch frightened to do just that. The output from xfs_repair -n is, uh, copious. At ~600k, I won't spam the list with it, but it can be perused here: http://blank.org/memory/xfs_repair.out.txt I'm especially worried about: entry "tmp" at block 0 offset 96 in directory inode 128 references non-existent inode 20971648 would clear inode number in entry at offset 96... entry "dev" at block 0 offset 112 in directory inode 128 references non-existent inode 25165952 would clear inode number in entry at offset 112... entry "bin" at block 0 offset 160 in directory inode 128 references non-existent inode 67109191 would clear inode number in entry at offset 160... entry "home" at block 0 offset 176 in directory inode 128 references non-existent inode 83886263 would clear inode number in entry at offset 176... entry "lib" at block 0 offset 192 in directory inode 128 references non-existent inode 88080769 would clear inode number in entry at offset 192... entry "mnt" at block 0 offset 208 in directory inode 128 references non-existent inode 96469292 would clear inode number in entry at offset 208... entry "opt" at block 0 offset 224 in directory inode 128 references non-existent inode 109052059 would clear inode number in entry at offset 224... entry "root" at block 0 offset 240 in directory inode 128 references non-existent inode 113246387 would clear inode number in entry at offset 240... entry "sbin" at block 0 offset 256 in directory inode 128 references non-existent inode 117440698 would clear inode number in entry at offset 256... entry "misc" at block 0 offset 272 in directory inode 128 references non-existent inode 75508160 There are quite a lot of errors of that sort, but right there it looks like my entire root directory is toast. Is there anything that can be done manually to avoid this, or should I just let xfs_repair do its job and salvage what I can from lost+found? -n ------------------------------------------------------------ SENDING JUNK EMAIL TO MY ADDRESS CONSTITUTES YOUR LEGALLY-BINDING ACCEPTANCE OF MY OFFER TO REMOVE BOTH OF YOUR NIPPLES WITH AN ORBITAL SANDER. (--Andy Ihnatko) ---------------------------------------------------- From owner-linux-xfs@oss.sgi.com Tue Jan 15 21:27:06 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0G5R6L15136 for linux-xfs-outgoing; Tue, 15 Jan 2002 21:27:06 -0800 Received: from porsta.cs.Helsinki.FI (root@porsta.cs.Helsinki.FI [128.214.48.124]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0G5R1P15114 for ; Tue, 15 Jan 2002 21:27:02 -0800 Received: from melkki.cs.Helsinki.FI (sslwrap@localhost [127.0.0.1]) by porsta.cs.Helsinki.FI (8.11.6/8.11.6) with ESMTP id g0G4Qvp20354 for ; Wed, 16 Jan 2002 06:26:58 +0200 Received: (from hhaataja@localhost) by melkki.cs.Helsinki.FI (8.11.6/8.11.2) id g0G4QuP07351 for linux-xfs@oss.sgi.com; Wed, 16 Jan 2002 06:26:56 +0200 Date: Wed, 16 Jan 2002 06:26:56 +0200 From: Harri Haataja Cc: linux-xfs@oss.sgi.com Subject: Re: XFS/NFS server oops ..... any ideas. Message-ID: <20020116062656.A6524@cs.helsinki.fi> References: <1011128071.13534.127.camel@jen.americas.sgi.com> <200201152229.WAA440925@plum.sucs.soton.ac.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200201152229.WAA440925@plum.sucs.soton.ac.uk>; from I.D.Hardy@soton.ac.uk on Tue, Jan 15, 2002 at 10:29:33PM +0000 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 602 Lines: 17 On Tue, Jan 15, 2002 at 10:29:33PM +0000, Ian D. Hardy wrote: > > On Tue, 2002-01-15 at 13:33, Ian D. Hardy wrote: > > In Irix I'd tune the kernel parameters 'min_free_pages'... to ensure that > there was always physical memory available, is there any equivalent in > Linux (sorry if this is a silly/obvious question). Documentation/sysctl/vm.txt On my 2.4.14 sources that seems to talk about 2.2 and the freepages file doesn't show up in proc at all. But that's where it used to be =) -- If USENET is anarchy, IRC is a paranoid schizophrenic after 6 days on speed. -- Chris "Saundo" Saunderson From owner-linux-xfs@oss.sgi.com Wed Jan 16 00:25:49 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0G8Pnl18089 for linux-xfs-outgoing; Wed, 16 Jan 2002 00:25:49 -0800 Received: from rj.sgi.com (rj.sgi.com [204.94.215.100]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0G8PjP18066 for ; Wed, 16 Jan 2002 00:25:45 -0800 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by rj.sgi.com (8.11.4/8.11.4/linux-outbound_gateway-1.1) with SMTP id g0G7PbY25721 for ; Tue, 15 Jan 2002 23:25:37 -0800 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 SAA21561 for ; Wed, 16 Jan 2002 18:24:21 +1100 Received: (from nathans@localhost) by wobbly.melbourne.sgi.com (SGI-8.9.3/8.9.3) id SAA31004 for linux-xfs@oss.sgi.com; Wed, 16 Jan 2002 18:24:21 +1100 (AEDT) Date: Wed, 16 Jan 2002 18:24:20 +1100 From: Nathan Scott To: linux-xfs@oss.sgi.com Subject: Re: things to do in brooklyn when your filesystem is dead Message-ID: <20020116182420.F30220@wobbly.melbourne.sgi.com> References: <20020112122144.R15376@blank.org> <20020114113445.D24972@wobbly.melbourne.sgi.com> <20020115223312.G15376@blank.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20020115223312.G15376@blank.org>; from memory@blank.org on Tue, Jan 15, 2002 at 10:33:12PM -0500 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 682 Lines: 28 On Tue, Jan 15, 2002 at 10:33:12PM -0500, Nathan J. Mehl wrote: > In the immortal words of Nathan Scott (nathans@sgi.com): > > > > Is it: > > "xlog_find_tail returned error X"? > > Yup! > OK, thanks. > ... > There are quite a lot of errors of that sort, but right there it looks > like my entire root directory is toast. > > Is there anything that can be done manually to avoid this, or should I > just let xfs_repair do its job and salvage what I can from lost+found? > That's pretty much the only option available at this point (unless you've used xfsdump/some other backup utility to keep a recent backup, and can use that in conjunction/instead). cheers. -- Nathan From owner-linux-xfs@oss.sgi.com Wed Jan 16 00:56:06 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0G8u6p18750 for linux-xfs-outgoing; Wed, 16 Jan 2002 00:56:06 -0800 Received: from TYO201.gate.nec.co.jp (TYO201.gate.nec.co.jp [202.32.8.214]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0G8tuP18725 for ; Wed, 16 Jan 2002 00:55:56 -0800 Received: from mailgate4.nec.co.jp ([10.7.69.193]) by TYO201.gate.nec.co.jp (8.11.6/3.7W01080315) with ESMTP id g0G7tjf13771 for ; Wed, 16 Jan 2002 16:55:46 +0900 (JST) Received: from mailsv4.nec.co.jp (mailgate51.nec.co.jp [10.7.69.196]) by mailgate4.nec.co.jp (8.11.6/3.7W-MAILGATE-NEC) with ESMTP id g0G7tiC13437 for ; Wed, 16 Jan 2002 16:55:44 +0900 (JST) Received: from thktnes98740.tnes.nec.co.jp (THKTNES98740.tnes.nec.co.jp [10.1.101.4]) by mailsv4.nec.co.jp (8.11.6/3.7W-MAILSV4-NEC) with ESMTP id g0G7thG26294 for ; Wed, 16 Jan 2002 16:55:44 +0900 (JST) Received: from thktnes98740.tnes.nec.co.jp ([10.1.101.4]) by thktnes98740.tnes.nec.co.jp (Post.Office MTA v3.1.2J release 205-101A-J ID# 0-0U10L2S100) with SMTP id AAA354 for ; Wed, 16 Jan 2002 16:55:41 +0900 Received: FROM noshiro.bsd.tnes.nec.co.jp BY thktnes98740.tnes.nec.co.jp ; Wed Jan 16 16:55:40 2002 +0900 Received: from localhost (localhost [127.0.0.1]) by noshiro.bsd.tnes.nec.co.jp (Postfix) with ESMTP id E142B6619 for ; Wed, 16 Jan 2002 16:55:41 +0900 (JST) To: linux-xfs@oss.sgi.com Subject: bomb and force shutdown X-Mailer: Mew version 1.94.2 on XEmacs 21.4 (Common Lisp) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <20020116165541J.masano@tnes.nec.co.jp> Date: Wed, 16 Jan 2002 16:55:41 +0900 (JST) From: ASANO Masahiro X-Dispatcher: imput version 20000228(IM140) Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 1999 Lines: 59 Hi, I made a simple "bomb" function which generated SCSI disk error periodically. When I carried out "cvs checkout linux-2.4-xfs" on xfs using this bomb, "Scheduling in interrupt" occurred. The kernel back trace was the same as the reported previously on this list. Date: 30 Oct 2001 16:09:13 -0500 Subject: Kernel OOPS 2.4.5-XFS-1.0.1 w/Feral FC drivers Message-Id: <1004476153.21484.32.camel@wmery000.ca.nortel.com> So I removed xfs_incore_relse() from _xfs_force_shutdown() function in linux/fs/xfs/xfs_rw.c according to the mail: Date: 30 Oct 2001 15:23:05 -0600 Subject: Re: Kernel OOPS 2.4.5-XFS-1.0.1 w/Feral FC drivers Message-Id: <1004476985.28795.46.camel@jen.americas.sgi.com> Then the "Scheduling in interrupt" went away. But I got another problem. After filesystem shutting down by the bomb, the super-block (and/or AGF,AGI) was overwritten by file data. Does anyone know the cause of these problems? Any help or suggestions would be appreciated. The bomb patch for linux-2.4-xfs is here. 8<----8<----8<----8<----8<----8<----8<---- --- linux/drivers/scsi/sd.c.orig Sun Jan 13 20:00:21 2002 +++ linux/drivers/scsi/sd.c Thu Jan 13 20:00:21 2002 @@ -77,6 +77,10 @@ #define MAX_RETRIES 5 +kdev_t bomb_dev; /*BOMB*/ /* Patch me to test dev# */ +unsigned int bomb_count; /*BOMB*/ +unsigned int bomb_limit = 0x3ff; /*BOMB*/ + /* * Time out in seconds for disks and Magneto-opticals (which are slower). */ @@ -654,6 +658,14 @@ SCpnt->cmnd[0] == WRITE_10) SCpnt->device->ten = 0; } + } + } else { /*BOMB*/ + struct buffer_head *bh = SCpnt->request.bh; + if (bh && bh->b_dev == bomb_dev && (++bomb_count & bomb_limit) == 0) { + SCpnt->result = result = DRIVER_SOFT << 24; + SCpnt->sense_buffer[2] = MEDIUM_ERROR; + good_sectors = 0; + printk("bomb: blocknr=%x size=%x state=%lx reqnext=%p\n", bh->b_blocknr, bh->b_size, bh->b_state, bh->b_reqnext); } } /* 8<----8<----8<----8<----8<----8<----8<---- -- Masano From owner-linux-xfs@oss.sgi.com Wed Jan 16 01:15:11 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0G9FBw19251 for linux-xfs-outgoing; Wed, 16 Jan 2002 01:15:11 -0800 Received: from mxzilla4.xs4all.nl (mxzilla4.xs4all.nl [194.109.6.48]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0G9F7P19229 for ; Wed, 16 Jan 2002 01:15:07 -0800 Received: from xs4.xs4all.nl (knuffie@xs4.xs4all.nl [194.109.6.45]) by mxzilla4.xs4all.nl (8.12.0/8.12.0) with ESMTP id g0G8F37d098163 for ; Wed, 16 Jan 2002 09:15:04 +0100 (CET) Received: from localhost (knuffie@localhost) by xs4.xs4all.nl (8.9.0/8.9.0) with ESMTP id JAA06946 for ; Wed, 16 Jan 2002 09:14:58 +0100 (CET) Date: Wed, 16 Jan 2002 09:14:58 +0100 (CET) From: Seth Mos To: linux-xfs@oss.sgi.com Subject: Developerworks XFS introduction. Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 260 Lines: 11 As linked to from http://linuxtoday.com/ http://linuxtoday.com/news_story.php3?ltsn=2002-01-16-003-20-PS-KN IBM developerWorks: Introducing XFS http://www-106.ibm.com/developerworks/library/l-fs9.html Cheers Seth Note that I have not read the article yet. From owner-linux-xfs@oss.sgi.com Wed Jan 16 01:19:11 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0G9JBL19416 for linux-xfs-outgoing; Wed, 16 Jan 2002 01:19:11 -0800 Received: from deliverator.sgi.com (deliverator.sgi.com [204.94.214.10]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0G9J4P19391 for ; Wed, 16 Jan 2002 01:19:04 -0800 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.55.149]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id AAA07221 for ; Wed, 16 Jan 2002 00:14:40 -0800 (PST) mail_from (tes@snort.melbourne.sgi.com) Received: (from tes@localhost) by snort.melbourne.sgi.com (SGI-8.9.3/8.9.3) id TAA10063 for linux-xfs@oss.sgi.com; Wed, 16 Jan 2002 19:17:43 +1100 (EST) Date: Wed, 16 Jan 2002 19:17:43 +1100 (EST) From: Timothy Shimmin Message-Id: <200201160817.TAA10063@snort.melbourne.sgi.com> To: linux-xfs@oss.sgi.com Subject: TAKE - xfsrestore Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 1521 Lines: 56 This fixes a bug in cumulative restore "xfsrestore -r" (found by xfstests/065), where if dirA and dirA/fileB were deleted between incremental dumps, it would fail to delete dirA because it wouldn't have yet deleted fileB - due to the way the code was written. It now ensures that fileB will be deleted first. The bug just meant that the directory would not be deleted until the next cumulative restore. --Tim Date: Wed Jan 16 00:12:04 PST 2002 Workarea: snort.melbourne.sgi.com:/home/diskb/build4/tes/slinx-xfs desc: cumulative restore fix for pv#844219 The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: xfs-cmds:slinx:109674a cmd/xfstests/065 - 1.1 - Do more testing on cumulative restores. It found bug pv#844219. cmd/xfstests/065.out - 1.1 - Output of cumulative restores and diffs of file listings for verification. cmd/xfsdump/VERSION - 1.27 - bump for cumulative restore fix cmd/xfsdump/doc/CHANGES - 1.31 - cumulative restore fix for deletion of dir/file cmd/xfsdump/restore/tree.c - 1.12 - Add explanatory comments for tree postprocessing functions. Fix noref_elim_recurse() to remove non-dirs which are really deleted and not just renamed. See pv#844219. cmd/xfstests/common.dump - 1.28 - Small change to ensure that our cwd is not in the fs that we are unmounting. cmd/xfstests/group - 1.18 - Add 065. cmd/xfsdump/doc/xfsdump.html - 1.2 - Add notes about the steps in dirent tree postprocessing for cumulative restores. From owner-linux-xfs@oss.sgi.com Wed Jan 16 02:33:56 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0GAXuf21773 for linux-xfs-outgoing; Wed, 16 Jan 2002 02:33:56 -0800 Received: from zork.zork.net (dsl-64149187165.internetconnect.net [64.149.187.165] (may be forged)) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0GAXnP21751 for ; Wed, 16 Jan 2002 02:33:49 -0800 Received: from localhost (zork.zork.net) [127.0.0.1] by zork.zork.net with esmtp (Exim 3.33 #1 (Debian)) id 16QmRy-0007de-00; Wed, 16 Jan 2002 01:33:42 -0800 To: Linux XFS Subject: Re: OOM difference on IRIX vs. linux References: From: Sean Neakums X-Message-Flag: Message text advisory: HACKING, HATE SPEECH X-Mailer: Norman Mail-Followup-To: Linux XFS Date: Wed, 16 Jan 2002 09:33:42 +0000 In-Reply-To: (Dan Hollis's message of "Tue, 15 Jan 2002 16:01:28 -0800 (PST)") Message-ID: <6ulmeymyh5.fsf@zork.zork.net> User-Agent: Gnus/5.090004 (Oort Gnus v0.04) Emacs/21.1 (i386-debian-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 500 Lines: 13 begin Dan Hollis quotation: > Its too bad theres no signal mechanism for userspace for 'memory >low', eg SIGLOWMEM so userspace apps could voluntarily release >resources to ease memory pressure. There was a big discussion on LKML about that a few months back. I forget what the outcome was. -- ///////////////// | | The spark of a pin | (require 'gnu) | dropping, falling feather-like. \\\\\\\\\\\\\\\\\ | | There is too much noise. From owner-linux-xfs@oss.sgi.com Wed Jan 16 03:00:43 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0GB0hD22619 for linux-xfs-outgoing; Wed, 16 Jan 2002 03:00:43 -0800 Received: from pneumatic-tube.sgi.com (pneumatic-tube.sgi.com [204.94.214.22]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0GB0cP22596 for ; Wed, 16 Jan 2002 03:00:38 -0800 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.55.149]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id CAA09551 for ; Wed, 16 Jan 2002 02:01:22 -0800 (PST) mail_from (nathans@snort.melbourne.sgi.com) Received: (from nathans@localhost) by snort.melbourne.sgi.com (SGI-8.9.3/8.9.3) id UAA02023 for linux-xfs@oss.sgi.com; Wed, 16 Jan 2002 20:59:17 +1100 (EST) Date: Wed, 16 Jan 2002 20:59:17 +1100 (EST) From: Nathan Scott Message-Id: <200201160959.UAA02023@snort.melbourne.sgi.com> To: linux-xfs@oss.sgi.com Subject: TAKE - pagebuf Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 457 Lines: 14 Date: Wed Jan 16 01:55:00 PST 2002 Workarea: snort.melbourne.sgi.com:/home/nathans/linux-xfs The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:109677a linux/fs/xfs/pagebuf/page_buf.c - 1.3 - fix for multiple blocksize support only, noop for normal case of bsize == page size. allows directory blocks to successfully be vmalloc'd if they span multiple pages and are not page-aligned. From owner-linux-xfs@oss.sgi.com Wed Jan 16 04:17:27 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0GCHRo24359 for linux-xfs-outgoing; Wed, 16 Jan 2002 04:17:27 -0800 Received: from mailgw2a.lmco.com (mailgw2a.lmco.com [192.91.147.7]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0GCHNP24336 for ; Wed, 16 Jan 2002 04:17:23 -0800 Received: from emss03g01.ems.lmco.com (emss03g01.ems.lmco.com [141.240.4.144]) by mailgw2a.lmco.com (8.8.8/8.8.8) with ESMTP id GAA32673 for ; Wed, 16 Jan 2002 06:17:20 -0500 (EST) Received: from CONVERSION-DAEMON by lmco.com (PMDF V5.2-33 #40646) id <0GQ1003013CUQ1@lmco.com> for linux-xfs@oss.sgi.com; Wed, 16 Jan 2002 06:17:20 -0500 (EST) Received: from lmco.com ([134.5.193.209]) by lmco.com (PMDF V5.2-33 #40646) with ESMTP id <0GQ1009I43COU8@lmco.com> for linux-xfs@oss.sgi.com; Wed, 16 Jan 2002 06:17:13 -0500 (EST) Date: Wed, 16 Jan 2002 07:40:06 -0500 From: Jeff Layton Subject: Re: Developerworks XFS introduction. To: linux-xfs@oss.sgi.com Message-id: <3C4574A6.2E6A46C1@lmco.com> MIME-version: 1.0 X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.4.16smp i686) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT X-Accept-Language: en References: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 368 Lines: 22 Seth Mos wrote: > As linked to from http://linuxtoday.com/ > http://linuxtoday.com/news_story.php3?ltsn=2002-01-16-003-20-PS-KN > > IBM developerWorks: Introducing XFS > http://www-106.ibm.com/developerworks/library/l-fs9.html Would anyone like to comment on the article? Steve L? Thanks! Jeff > > > Cheers > Seth > > Note that I have not read the article yet. From owner-linux-xfs@oss.sgi.com Wed Jan 16 05:20:56 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0GDKuS25569 for linux-xfs-outgoing; Wed, 16 Jan 2002 05:20:56 -0800 Received: from gusi.leathercollection.ph (gusi.leathercollection.ph [202.163.192.10]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0GDKqP25547 for ; Wed, 16 Jan 2002 05:20:52 -0800 Received: from localhost (localhost [127.0.0.1]) by gusi.leathercollection.ph (Postfix) with ESMTP id 8A525C00B5D for ; Wed, 16 Jan 2002 20:20:47 +0800 (PHT) Received: from mail.leathercollection.ph (gusi.leathercollection.ph [192.168.0.1]) by gusi.leathercollection.ph (Postfix) with ESMTP id 2E1BAC00B5B for ; Wed, 16 Jan 2002 20:20:46 +0800 (PHT) Date: Wed, 16 Jan 2002 20:20:46 +0800 (PHT) From: Federico Sevilla III To: Linux XFS Mailing List Subject: Re: Developerworks XFS introduction. In-Reply-To: <3C4574A6.2E6A46C1@lmco.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by AMaViS perl-11 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 760 Lines: 19 On Wed, 16 Jan 2002 at 07:40, Jeff Layton wrote: > > IBM developerWorks: Introducing XFS > > http://www-106.ibm.com/developerworks/library/l-fs9.html > Would anyone like to comment on the article? Steve L? (I'm not Steve Lord but ...) I just read the article and everything seems to be in order. Nothing quite new (since I've been using XFS for awhile). However I really like how the NULL issue was explained. I never really looked at it that way (always saw it as a ... problem). And that bit quoting Steve Lord on a "coming soon" patch to improve delete performance was exciting. :) --> Jijo -- Federico Sevilla III :: jijo@leathercollection.ph Network Administrator :: The Leather Collection, Inc. GnuPG Key: http://jijo.leathercollection.ph/jijo.gpg From owner-linux-xfs@oss.sgi.com Wed Jan 16 05:56:11 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0GDuB626394 for linux-xfs-outgoing; Wed, 16 Jan 2002 05:56:11 -0800 Received: from mxzilla1.xs4all.nl (mxzilla1.xs4all.nl [194.109.6.54]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0GDu6P26369 for ; Wed, 16 Jan 2002 05:56:07 -0800 Received: from xs3.xs4all.nl (knuffie@xs3.xs4all.nl [194.109.6.44]) by mxzilla1.xs4all.nl (8.12.0/8.12.0) with ESMTP id g0GCtuap098132; Wed, 16 Jan 2002 13:55:56 +0100 (CET) Received: from localhost (knuffie@localhost) by xs3.xs4all.nl (8.9.0/8.9.0) with ESMTP id NAA00267; Wed, 16 Jan 2002 13:55:56 +0100 (CET) Date: Wed, 16 Jan 2002 13:55:56 +0100 (CET) From: Seth Mos To: Federico Sevilla III cc: Linux XFS Mailing List Subject: Re: Developerworks XFS introduction. In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 1369 Lines: 31 On Wed, 16 Jan 2002, Federico Sevilla III wrote: > On Wed, 16 Jan 2002 at 07:40, Jeff Layton wrote: > > > IBM developerWorks: Introducing XFS > > > http://www-106.ibm.com/developerworks/library/l-fs9.html > > Would anyone like to comment on the article? Steve L? > > (I'm not Steve Lord but ...) I just read the article and everything seems > to be in order. Nothing quite new (since I've been using XFS for awhile). > However I really like how the NULL issue was explained. I never really > looked at it that way (always saw it as a ... problem). And that bit > quoting Steve Lord on a "coming soon" patch to improve delete performance > was exciting. :) Which will probably also fix the null issues. If you opened a file in vi and then save the file it will create a new file with the contents and delete the old file. Deletes are synchronous and _will_ erase the old file and update the metadata. Thus when power off occurs the data points to the new inode of which the data was still in ram at that time. So when deletes are asynchronous the delete will be commited at the same time the new file data is written. This has the advantage that when the box is powered off you loose the new data which is still in ram and the delete is not commited. Thus preserving your old file. Or that is my thought up theory based on previous posts on the list. Cheers Seth From owner-linux-xfs@oss.sgi.com Wed Jan 16 06:02:41 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0GE2fi26713 for linux-xfs-outgoing; Wed, 16 Jan 2002 06:02:41 -0800 Received: from deliverator.sgi.com (deliverator.sgi.com [204.94.214.10]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0GE24P26687 for ; Wed, 16 Jan 2002 06:02:04 -0800 Received: from zeus-e8.americas.sgi.com (zeus-e8.americas.sgi.com [128.162.8.103]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id EAA17309 for ; Wed, 16 Jan 2002 04:57:40 -0800 (PST) mail_from (lord@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by zeus-e8.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id HAA20181 for ; Wed, 16 Jan 2002 07:00:45 -0600 (CST) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id HAA12800 for ; Wed, 16 Jan 2002 07:00:45 -0600 (CST) From: Steve Lord Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id g0GCwc903166; Wed, 16 Jan 2002 06:58:38 -0600 Message-Id: <200201161258.g0GCwc903166@jen.americas.sgi.com> Date: Wed, 16 Jan 2002 06:58:38 -0600 Subject: TAKE - merge up to 2.5.3-pre1 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 12779 Lines: 361 A shiny new IDE subsystem - well not that new actually, but certainly faster than the old one. Date: Wed Jan 16 04:56:29 PST 2002 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:109680a linux/include/linux/tcp_diag.h - 1.1 linux/include/linux/init_task.h - 1.1 linux/drivers/ide/ide-taskfile.c - 1.1 linux/drivers/ide/pdcadma.c - 1.1 linux/net/ipv4/tcp_diag.c - 1.1 linux/net/unix/garbage.c - 1.10 linux/net/unix/af_unix.c - 1.39 linux/net/socket.c - 1.28 linux/net/sched/sch_tbf.c - 1.11 linux/net/sched/sch_sfq.c - 1.5 linux/net/sched/sch_red.c - 1.9 linux/net/sched/sch_prio.c - 1.6 linux/net/sched/sch_fifo.c - 1.4 linux/net/sched/sch_csz.c - 1.5 linux/net/sched/sch_cbq.c - 1.13 linux/net/sched/sch_api.c - 1.12 linux/net/sched/police.c - 1.4 linux/net/sched/cls_u32.c - 1.8 linux/net/sched/cls_rsvp.h - 1.3 linux/net/sched/cls_route.c - 1.7 linux/net/sched/cls_fw.c - 1.6 linux/net/sched/cls_api.c - 1.7 linux/net/sched/Config.in - 1.8 linux/net/packet/af_packet.c - 1.28 linux/net/netsyms.c - 1.40 linux/net/netlink/netlink_dev.c - 1.13 linux/net/ipv6/route.c - 1.21 linux/net/ipv6/ndisc.c - 1.16 linux/net/ipv6/ip6_fw.c - 1.6 linux/net/ipv6/ip6_fib.c - 1.10 linux/net/ipv6/addrconf.c - 1.22 linux/net/ipv6/Config.in - 1.7 linux/net/ipv4/udp.c - 1.28 linux/net/ipv4/tcp_output.c - 1.27 linux/net/ipv4/tcp_ipv4.c - 1.40 linux/net/ipv4/tcp_input.c - 1.34 linux/net/ipv4/tcp.c - 1.36 linux/net/ipv4/route.c - 1.30 linux/net/ipv4/ipmr.c - 1.20 linux/net/ipv4/ipconfig.c - 1.27 linux/net/ipv4/ip_input.c - 1.14 linux/net/ipv4/ip_fragment.c - 1.16 linux/net/ipv4/fib_semantics.c - 1.7 linux/net/ipv4/fib_rules.c - 1.8 linux/net/ipv4/fib_hash.c - 1.5 linux/net/ipv4/fib_frontend.c - 1.11 linux/net/ipv4/devinet.c - 1.14 linux/net/ipv4/af_inet.c - 1.31 linux/net/ipv4/Makefile - 1.8 linux/net/ipv4/Config.in - 1.11 linux/net/decnet/README - 1.3 linux/net/core/sock.c - 1.23 linux/net/core/skbuff.c - 1.23 linux/net/core/scm.c - 1.7 linux/net/core/rtnetlink.c - 1.10 linux/net/core/neighbour.c - 1.13 linux/net/core/datagram.c - 1.11 linux/net/Makefile - 1.17 linux/net/Config.in - 1.20 linux/mm/swapfile.c - 1.49 linux/mm/mremap.c - 1.26 linux/mm/mprotect.c - 1.21 linux/mm/mmap.c - 1.45 linux/mm/memory.c - 1.74 linux/mm/filemap.c - 1.106 linux/lib/vsprintf.c - 1.15 linux/kernel/sched.c - 1.53 linux/kernel/ksyms.c - 1.127 linux/kernel/kmod.c - 1.17 linux/kernel/fork.c - 1.43 linux/kernel/exit.c - 1.37 linux/include/net/sock.h - 1.26 linux/include/linux/videodev.h - 1.20 linux/include/linux/sched.h - 1.55 linux/include/linux/rtnetlink.h - 1.10 linux/include/linux/netlink.h - 1.7 linux/include/linux/msdos_fs.h - 1.14 linux/include/linux/mm.h - 1.77 linux/include/linux/hdreg.h - 1.14 linux/include/linux/file.h - 1.12 linux/include/linux/blkdev.h - 1.52 linux/include/asm-sparc64/pgtable.h - 1.29 linux/include/asm-sparc64/ide.h - 1.10 linux/include/asm-sparc/pgtable.h - 1.22 linux/include/asm-ppc/pgtable.h - 1.29 linux/include/asm-ppc/ide.h - 1.14 linux/include/asm-mips/pgtable.h - 1.15 linux/include/asm-mips/pci.h - 1.13 linux/include/asm-mips/ide.h - 1.10 linux/include/asm-mips/gfx.h - 1.5 linux/include/asm-m68k/ide.h - 1.6 linux/include/asm-i386/pgtable.h - 1.28 linux/include/asm-i386/ide.h - 1.7 linux/include/asm-arm/pgtable.h - 1.22 linux/include/asm-arm/ide.h - 1.3 linux/include/asm-alpha/pgtable.h - 1.31 linux/include/asm-alpha/pci.h - 1.15 linux/include/asm-alpha/ide.h - 1.6 linux/fs/vfat/namei.c - 1.22 linux/fs/proc/array.c - 1.35 linux/fs/open.c - 1.34 linux/fs/nfsd/vfs.c - 1.42 linux/fs/fcntl.c - 1.17 linux/fs/fat/misc.c - 1.11 linux/fs/fat/inode.c - 1.33 linux/fs/fat/dir.c - 1.14 linux/drivers/video/vesafb.c - 1.19 linux/drivers/video/sgivwfb.c - 1.13 linux/drivers/video/sbusfb.c - 1.20 linux/drivers/video/igafb.c - 1.16 linux/drivers/video/fbmem.c - 1.43 linux/drivers/video/controlfb.c - 1.19 linux/drivers/video/acornfb.c - 1.22 linux/drivers/usb/audio.c - 1.36 linux/drivers/sound/soundcard.c - 1.23 linux/drivers/sound/sonicvibes.c - 1.36 linux/drivers/sound/es1371.c - 1.37 linux/drivers/sound/es1370.c - 1.36 linux/drivers/sgi/char/shmiq.c - 1.18 linux/drivers/sgi/char/graphics.c - 1.18 linux/drivers/scsi/qlogicpti.c - 1.18 linux/drivers/scsi/qlogicisp.c - 1.27 linux/drivers/scsi/qlogicfc.c - 1.27 linux/drivers/scsi/ide-scsi.c - 1.24 linux/drivers/scsi/esp.c - 1.18 linux/drivers/sbus/char/zs.c - 1.23 linux/drivers/sbus/char/vfc_dev.c - 1.14 linux/drivers/sbus/char/flash.c - 1.14 linux/drivers/sbus/char/envctrl.c - 1.15 linux/drivers/net/sunqe.c - 1.21 linux/drivers/net/sunlance.c - 1.26 linux/drivers/net/sunhme.c - 1.34 linux/drivers/net/sunbmac.c - 1.22 linux/drivers/net/acenic.c - 1.36 linux/drivers/net/Config.in - 1.54 linux/drivers/fc4/fc.c - 1.9 linux/drivers/char/mem.c - 1.41 linux/drivers/char/ftape/lowlevel/ftape-ctl.c - 1.7 linux/drivers/block/paride/pt.c - 1.15 linux/drivers/block/paride/pseudo.h - 1.6 linux/drivers/block/paride/pg.c - 1.14 linux/drivers/block/paride/pf.c - 1.20 linux/drivers/block/loop.c - 1.50 linux/arch/sparc64/mm/modutil.c - 1.10 linux/arch/sparc64/mm/init.c - 1.38 linux/arch/sparc64/mm/generic.c - 1.9 linux/arch/sparc64/kernel/sparc64_ksyms.c - 1.38 linux/arch/sparc64/kernel/smp.c - 1.35 linux/arch/sparc64/kernel/ioctl32.c - 1.49 linux/arch/sparc64/kernel/init_task.c - 1.7 linux/arch/sparc64/kernel/head.S - 1.14 linux/arch/sparc64/defconfig - 1.56 linux/arch/sparc64/config.in - 1.48 linux/arch/sparc/mm/viking.S - 1.8 linux/arch/sparc/mm/tsunami.S - 1.8 linux/arch/sparc/mm/sun4c.c - 1.30 linux/arch/sparc/mm/srmmu.c - 1.29 linux/arch/sparc/mm/hypersparc.S - 1.7 linux/arch/sparc/mm/generic.c - 1.9 linux/arch/sparc/kernel/smp.c - 1.16 linux/arch/sparc/kernel/init_task.c - 1.6 linux/arch/sparc/defconfig - 1.28 linux/arch/sparc/config.in - 1.32 linux/arch/ppc/kernel/setup.c - 1.39 linux/arch/ppc/kernel/pci.c - 1.24 linux/arch/mips/mm/umap.c - 1.8 linux/arch/mips/mm/r4xx0.c - 1.11 linux/arch/mips/mm/r2300.c - 1.12 linux/arch/mips/mm/loadmmu.c - 1.10 linux/arch/mips/mm/andes.c - 1.10 linux/arch/mips/kernel/init_task.c - 1.6 linux/arch/i386/kernel/init_task.c - 1.7 linux/arch/i386/defconfig - 1.90 linux/arch/arm/kernel/init_task.c - 1.9 linux/arch/arm/kernel/ecard.c - 1.15 linux/arch/alpha/kernel/smp.c - 1.30 linux/Makefile - 1.175 linux/MAINTAINERS - 1.91 linux/Documentation/Configure.help - 1.126 linux/CREDITS - 1.70 linux/net/decnet/dn_route.c - 1.19 linux/net/decnet/dn_fib.c - 1.10 linux/net/decnet/dn_dev.c - 1.13 linux/net/decnet/af_decnet.c - 1.28 linux/include/net/dn_fib.h - 1.5 linux/include/linux/ide.h - 1.36 linux/drivers/sound/cmpci.c - 1.30 linux/Documentation/networking/decnet.txt - 1.9 linux/include/asm-mips/umap.h - 1.2 linux/drivers/parport/ieee1284_ops.c - 1.15 linux/drivers/parport/Config.in - 1.15 linux/fs/file.c - 1.8 linux/drivers/sound/esssolo1.c - 1.34 linux/fs/partitions/msdos.c - 1.18 linux/fs/partitions/Makefile - 1.7 linux/net/sched/sch_atm.c - 1.7 linux/arch/sparc64/kernel/pci_common.c - 1.15 linux/arch/sparc64/kernel/pci.c - 1.23 linux/arch/sh/mm/fault.c - 1.19 linux/arch/sh/kernel/init_task.c - 1.3 linux/drivers/sound/maestro.c - 1.27 linux/include/asm-sh/pgtable.h - 1.21 linux/include/asm-i386/pci.h - 1.13 linux/include/asm-sparc64/pci.h - 1.11 linux/include/asm-sparc/pci.h - 1.12 linux/include/asm-ppc/pci.h - 1.14 linux/arch/i386/kernel/pci-i386.c - 1.18 linux/include/linux/highmem.h - 1.17 linux/include/asm-sh/ide.h - 1.10 linux/include/asm-arm/proc-armv/cache.h - 1.11 linux/include/asm-arm/proc-armo/cache.h - 1.8 linux/include/asm-arm/pci.h - 1.17 linux/include/asm-i386/pgalloc.h - 1.14 linux/include/asm-alpha/pgalloc.h - 1.11 linux/drivers/sound/trident.c - 1.32 linux/drivers/char/agp/agpgart_fe.c - 1.15 linux/arch/sparc/mm/swift.S - 1.6 linux/include/asm-sparc64/pgalloc.h - 1.16 linux/include/asm-sparc/pgalloc.h - 1.12 linux/drivers/usb/ov511.c - 1.28 linux/include/net/inetpeer.h - 1.2 linux/net/sched/sch_ingress.c - 1.7 linux/net/sched/sch_gred.c - 1.8 linux/net/sched/sch_dsmark.c - 1.8 linux/net/sched/cls_tcindex.c - 1.6 linux/net/decnet/dn_table.c - 1.6 linux/net/decnet/dn_rules.c - 1.3 linux/drivers/ieee1394/raw1394.c - 1.15 linux/Documentation/DMA-mapping.txt - 1.12 linux/include/asm-sparc/ide.h - 1.7 linux/include/asm-m68k/pgalloc.h - 1.7 linux/arch/ia64/kernel/init_task.c - 1.3 linux/arch/ia64/kernel/pci.c - 1.10 linux/arch/ia64/kernel/perfmon.c - 1.9 linux/arch/ia64/mm/tlb.c - 1.10 linux/include/asm-ia64/ide.h - 1.6 linux/include/asm-ia64/pgalloc.h - 1.9 linux/include/asm-ia64/pci.h - 1.11 linux/drivers/video/matrox/matroxfb_base.h - 1.10 linux/include/asm-mips64/ide.h - 1.7 linux/include/asm-mips64/gfx.h - 1.4 linux/include/asm-mips/pgalloc.h - 1.6 linux/include/asm-mips64/pgtable.h - 1.10 linux/include/asm-mips64/pgalloc.h - 1.8 linux/include/asm-mips64/pci.h - 1.9 linux/arch/mips64/mm/umap.c - 1.7 linux/arch/mips64/mm/andes.c - 1.9 linux/arch/mips64/mm/r4xx0.c - 1.10 linux/arch/mips64/mm/loadmmu.c - 1.6 linux/arch/mips64/kernel/init_task.c - 1.3 linux/include/asm-sh/pgalloc.h - 1.6 linux/include/asm-sh/pci.h - 1.12 linux/drivers/parport/ChangeLog - 1.25 linux/drivers/ide/piix.c - 1.15 linux/drivers/ide/pdc4030.c - 1.8 linux/drivers/ide/pdc202xx.c - 1.14 linux/drivers/ide/ide.c - 1.41 linux/drivers/ide/ide-tape.c - 1.17 linux/drivers/ide/ide-proc.c - 1.9 linux/drivers/ide/ide-probe.c - 1.23 linux/drivers/ide/ide-pmac.c - 1.8 linux/drivers/ide/ide-pci.c - 1.20 linux/drivers/ide/ide-geometry.c - 1.9 linux/drivers/ide/ide-floppy.c - 1.14 linux/drivers/ide/ide-features.c - 1.9 linux/drivers/ide/ide-dma.c - 1.16 linux/drivers/ide/ide-disk.c - 1.21 linux/drivers/ide/ide-cs.c - 1.8 linux/drivers/ide/ide-cd.h - 1.11 linux/drivers/ide/ide-cd.c - 1.25 linux/drivers/ide/hpt366.c - 1.12 linux/drivers/ide/cmd64x.c - 1.8 linux/drivers/ide/alim15x3.c - 1.11 linux/drivers/ide/Makefile - 1.14 linux/drivers/ide/Config.in - 1.16 linux/net/ipv4/netfilter/ip_nat_standalone.c - 1.12 linux/net/ipv4/netfilter/ip_fw_compat_redir.c - 1.4 linux/net/ipv4/netfilter/Config.in - 1.6 linux/drivers/sound/i810_audio.c - 1.20 linux/include/asm-s390/ide.h - 1.2 linux/arch/s390/kernel/init_task.c - 1.4 linux/include/asm-s390/pgtable.h - 1.9 linux/include/asm-s390/pgalloc.h - 1.5 linux/net/ipv6/netfilter/Config.in - 1.4 linux/arch/mips64/kernel/smp.c - 1.9 linux/drivers/char/drm/i810_dma.c - 1.9 linux/drivers/usb/storage/usb.c - 1.15 linux/drivers/mtd/mtdblock.c - 1.11 linux/Documentation/cachetlb.txt - 1.8 linux/drivers/sound/cs46xx.c - 1.17 linux/drivers/media/video/zr36120.c - 1.12 linux/drivers/media/video/videodev.c - 1.11 linux/drivers/media/video/planb.c - 1.10 linux/drivers/media/video/cpia.c - 1.9 linux/drivers/media/video/bttv-driver.c - 1.16 linux/drivers/ide/slc90e66.c - 1.6 linux/drivers/video/sis/sis_main.c - 1.9 linux/arch/sparc64/lib/U3copy_from_user.S - 1.2 linux/include/asm-m68k/motorola_pgalloc.h - 1.4 linux/include/asm-parisc/ide.h - 1.2 linux/arch/parisc/mm/pa20.c - 1.3 linux/arch/parisc/mm/pa11.c - 1.3 linux/arch/parisc/mm/kmap.c - 1.3 linux/include/asm-parisc/pci.h - 1.4 linux/include/asm-parisc/pgalloc.h - 1.3 linux/include/asm-parisc/pgtable.h - 1.3 linux/include/asm-m68k/sun3_pgalloc.h - 1.4 linux/drivers/sound/ymfpci.c - 1.18 linux/arch/parisc/kernel/init_task.c - 1.3 linux/include/asm-s390x/pgtable.h - 1.5 linux/include/asm-s390x/pgalloc.h - 1.4 linux/include/asm-s390x/ide.h - 1.2 linux/drivers/sound/maestro3.c - 1.11 linux/drivers/sound/cs4281/cs4281m.c - 1.9 linux/arch/s390x/kernel/init_task.c - 1.4 linux/arch/cris/mm/tlb.c - 1.5 linux/drivers/pcmcia/hd64465_ss.c - 1.4 linux/include/asm-cris/pgtable.h - 1.5 linux/include/asm-cris/ide.h - 1.2 linux/drivers/scsi/aic7xxx_old.c - 1.15 linux/drivers/net/sungem.h - 1.5 linux/drivers/net/sungem.c - 1.13 linux/drivers/usb/pwc-if.c - 1.10 linux/drivers/usb/se401.c - 1.6 linux/arch/mips/mm/sb1.c - 1.2 linux/arch/mips/mm/rm7k.c - 1.3 linux/arch/mips/mm/r5432.c - 1.4 linux/arch/mips/mm/mips32.c - 1.4 linux/drivers/media/video/meye.c - 1.5 linux/drivers/media/video/zr36067.c - 1.7 linux/drivers/message/fusion/mptscsih.c - 1.6 linux/drivers/video/aty/atyfb_base.c - 1.8 linux/drivers/char/drm/drm_vm.h - 1.9 linux/drivers/sound/rme96xx.c - 1.4 linux/drivers/ide/serverworks.c - 1.4 linux/arch/ppc/mm/tlb.c - 1.2 linux/drivers/usb/usbvideo.h - 1.4 linux/drivers/usb/usbvideo.c - 1.4 linux/drivers/sound/ite8172.c - 1.4 linux/drivers/ide/qd65xx.h - 1.2 linux/drivers/ide/qd65xx.c - 1.2 linux/arch/sh/mm/cache-sh4.c - 1.4 linux/include/asm-generic/tlb.h - 1.2 linux/drivers/mtd/devices/blkmtd.c - 1.4 linux/drivers/net/de2104x.c - 1.4 linux/drivers/usb/stv680.c - 1.2 linux/drivers/usb/vicam.c - 1.2 linux/drivers/block/cciss_scsi.c - 1.2 linux/lib/crc32.c - 1.2 From owner-linux-xfs@oss.sgi.com Wed Jan 16 09:35:03 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0GHZ3800872 for linux-xfs-outgoing; Wed, 16 Jan 2002 09:35:03 -0800 Received: from Tink.ijs.si (IDENT:qs5oyCpgbb/c0ZASKgoCLhcQe/uxXRnM@Tink.ijs.si [193.2.4.243]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0GHYtP00850 for ; Wed, 16 Jan 2002 09:34:56 -0800 Received: from localhost (localhost [127.0.0.1]) by Tink.ijs.si (Postfix) with ESMTP id 7BADA47FD4 for ; Wed, 16 Jan 2002 17:34:49 +0100 (CET) Received: from brenta.ijs.si (brenta.ijs.si [194.249.156.1]) by Tink.ijs.si (Postfix) with ESMTP id EB84B47FA7 for ; Wed, 16 Jan 2002 17:34:45 +0100 (CET) Received: from f9pc02.ijs.si (f9pc02.ijs.si [194.249.156.2]) by brenta.ijs.si (8.11.2/8.11.2) with ESMTP id g0GGYj411729 for ; Wed, 16 Jan 2002 17:34:45 +0100 Received: from localhost (andrej@localhost) by f9pc02.ijs.si (8.11.6/8.11.0) with ESMTP id g0GGYj503811 for ; Wed, 16 Jan 2002 17:34:45 +0100 Date: Wed, 16 Jan 2002 17:34:44 +0100 (CET) From: Andrej Filipcic Reply-To: To: Subject: bsdlabel and xfs on alpha Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by AMaViS snapshot-20011031 / Sophos+sophie Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 879 Lines: 27 Hi, I am trying to use xfs on alpha, however there are some problems with lost disklabel. I have created a disklabel with one partition for entire disk. Then I formatted the drive and mount it. However in this case the disklabel is lost. I have to recreate it and then restore xfs with xfs_repair. xfs_repair destroys the disklabel, but I can still mount the partition. Is there something overlaping between the label and partition? I run 2.4.17 on RH7.1 with xfsprogs-1.2.7 Thanks, Andrej -- _____________________________________________________________ doc. dr. Andrej Filipcic, E-mail: Andrej.Filipcic@ijs.si Department of Experimental High Energy Physics - F9 Jozef Stefan Institute, Jamova 39, P.o.Box 3000 SI-1001 Ljubljana, Slovenia Tel.: +386-1-477-3674 Fax: +386-1-425-7074 ------------------------------------------------------------- From owner-linux-xfs@oss.sgi.com Wed Jan 16 10:11:57 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0GIBvn01467 for linux-xfs-outgoing; Wed, 16 Jan 2002 10:11:57 -0800 Received: from eelwing.arda (postfix@md4690a14.utfors.se [212.105.10.20]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0GIBnP01445 for ; Wed, 16 Jan 2002 10:11:50 -0800 Received: from unx.nu (eelwing.arda [172.16.0.1]) by eelwing.arda (Postfix) with ESMTP id AA4C0EFB; Wed, 16 Jan 2002 18:11:39 +0100 (CET) Date: Wed, 16 Jan 2002 18:11:36 +0100 (CET) From: wiss@unx.nu Subject: Bug? linux-2.4.17-xfs-ix86 To: andrej.filipcic@ijs.si Cc: linux-xfs@oss.sgi.com In-Reply-To: MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Message-Id: <20020116171139.AA4C0EFB@eelwing.arda> Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 616 Lines: 35 Example: pub1 is xfs on /dev/hda3 cp -a /home/arkiv /mounts/pub1 umount /mounts/pub1 mount /dev/hda3 /home/arkiv ls /home/arkiv => empty df => /dev/hda3 empty ??? umount /home/arkiv mount /dev/hda3 /home/arkiv Everything is there ??? Jonas -- http://wiss.unx.nu http://linux.unx.nu Another Glitch in the Call We don't need no indirection We don't need no flow control No data typing or declarations Did you leave the lists alone? Hey! Hacker! Leave those lists alone! Chorus: All in all, it's just a pure-LISP function call. All in all, it's just a pure-LISP function call. From owner-linux-xfs@oss.sgi.com Wed Jan 16 10:24:31 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0GIOVr03162 for linux-xfs-outgoing; Wed, 16 Jan 2002 10:24:31 -0800 Received: from deliverator.sgi.com (deliverator.sgi.com [204.94.214.10]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0GIOQP03139 for ; Wed, 16 Jan 2002 10:24:27 -0800 Received: from zeus-e8.americas.sgi.com (zeus-e8.americas.sgi.com [128.162.8.103]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id JAA26007 for ; Wed, 16 Jan 2002 09:20:02 -0800 (PST) mail_from (sandeen@sgi.com) Received: from poppy-e185.americas.sgi.com (poppy-e185.americas.sgi.com [128.162.185.207]) by zeus-e8.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id LAA23967 for ; Wed, 16 Jan 2002 11:23:07 -0600 (CST) Received: from stout.americas.sgi.com (stout.americas.sgi.com [128.162.187.5]) by poppy-e185.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.7) with ESMTP id LAA88899 for ; Wed, 16 Jan 2002 11:23:07 -0600 (CST) Subject: Re: bomb and force shutdown From: Eric Sandeen Cc: linux-xfs@oss.sgi.com In-Reply-To: <20020116165541J.masano@tnes.nec.co.jp> References: <20020116165541J.masano@tnes.nec.co.jp> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/1.0 (Preview Release) Date: 16 Jan 2002 11:23:07 -0600 Message-Id: <1011201787.3647.5.camel@stout.americas.sgi.com> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 434 Lines: 20 On Wed, 2002-01-16 at 01:55, ASANO Masahiro wrote: > Hi, > > I made a simple "bomb" function which generated SCSI disk error > periodically. > ... > But I got another > problem. After filesystem shutting down by the bomb, the super-block > (and/or AGF,AGI) was overwritten by file data. Thanks, I'll take a look at this. -Eric -- Eric Sandeen XFS for Linux http://oss.sgi.com/projects/xfs sandeen@sgi.com SGI, Inc. From owner-linux-xfs@oss.sgi.com Wed Jan 16 10:44:12 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0GIiCk04037 for linux-xfs-outgoing; Wed, 16 Jan 2002 10:44:12 -0800 Received: from rover (rover.mkp.net [209.217.122.9]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0GIi7P04011 for ; Wed, 16 Jan 2002 10:44:07 -0800 Received: from localhost.localdomain ([127.0.0.1] helo=rover.mkp.net) by rover with esmtp (Exim 3.33 #1) id 16Qu6T-0000G7-00; Wed, 16 Jan 2002 12:44:03 -0500 Received: (from mkp@localhost) by rover.mkp.net (8.11.6/8.9.3) id g0GHhsr01725; Wed, 16 Jan 2002 12:43:54 -0500 X-Authentication-Warning: jaguar.wave.mkp.net: mkp set sender to mkp@mkp.net using -f To: Cc: Subject: Re: bsdlabel and xfs on alpha References: From: "Martin K. Petersen" Organization: Linuxcare, Inc. Date: 16 Jan 2002 12:43:53 -0500 In-Reply-To: Message-ID: User-Agent: Gnus/5.0808 (Gnus v5.8.8) XEmacs/21.4 (Civil Service) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 999 Lines: 23 >>>>> "Andrej" == Andrej Filipcic writes: Andrej> I am trying to use xfs on alpha, however there are some Andrej> problems with lost disklabel. I have created a disklabel with Andrej> one partition for entire disk. Then I formatted the drive and Andrej> mount it. However in this case the disklabel is lost. I have Andrej> to recreate it and then restore xfs with Andrej> xfs_repair. xfs_repair destroys the disklabel, but I can still Andrej> mount the partition. Is there something overlaping between Andrej> the label and partition? Yep. Avoid using the first cylinder on the disk for XFS filesystems. Unlike ext2, XFS places its superblock right at the beginning of the partition. My Red Hat/Alpha XFS installer should warn you about this. Don't know if you used that to do the install. -- Martin K. Petersen, Principal Linux Consultant, Linuxcare, Inc. mkp@linuxcare.com, http://www.linuxcare.com/ SGI XFS for Linux Developer, http://oss.sgi.com/projects/xfs/ From owner-linux-xfs@oss.sgi.com Wed Jan 16 11:00:31 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0GJ0VQ04898 for linux-xfs-outgoing; Wed, 16 Jan 2002 11:00:31 -0800 Received: from Tink.ijs.si (IDENT:CjgEJ6h3+oxRUHu2b/cxjvI+U2aiZmog@Tink.ijs.si [193.2.4.243]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0GJ0LP04449 for ; Wed, 16 Jan 2002 11:00:22 -0800 Received: from localhost (localhost [127.0.0.1]) by Tink.ijs.si (Postfix) with ESMTP id 8ED8147FE3; Wed, 16 Jan 2002 19:00:15 +0100 (CET) Received: from brenta.ijs.si (brenta.ijs.si [194.249.156.1]) by Tink.ijs.si (Postfix) with ESMTP id C3BEC47FDE; Wed, 16 Jan 2002 19:00:12 +0100 (CET) Received: from f9pc02.ijs.si (f9pc02.ijs.si [194.249.156.2]) by brenta.ijs.si (8.11.2/8.11.2) with ESMTP id g0GI0C412246; Wed, 16 Jan 2002 19:00:12 +0100 Received: from localhost (andrej@localhost) by f9pc02.ijs.si (8.11.6/8.11.0) with ESMTP id g0GI0Cv04064; Wed, 16 Jan 2002 19:00:12 +0100 Date: Wed, 16 Jan 2002 19:00:12 +0100 (CET) From: Andrej Filipcic Reply-To: To: "Martin K. Petersen" Cc: , Subject: Re: bsdlabel and xfs on alpha In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by AMaViS snapshot-20011031 / Sophos+sophie Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 984 Lines: 26 On 16 Jan 2002, Martin K. Petersen wrote: > >>>>> "Andrej" == Andrej Filipcic writes: > > Andrej> I am trying to use xfs on alpha, however there are some > Andrej> problems with lost disklabel. I have created a disklabel with > Andrej> one partition for entire disk. Then I formatted the drive and > Andrej> mount it. However in this case the disklabel is lost. I have > Andrej> to recreate it and then restore xfs with > Andrej> xfs_repair. xfs_repair destroys the disklabel, but I can still > Andrej> mount the partition. Is there something overlaping between > Andrej> the label and partition? > > Yep. Avoid using the first cylinder on the disk for XFS filesystems. > > Unlike ext2, XFS places its superblock right at the beginning of the > partition. > > My Red Hat/Alpha XFS installer should warn you about this. Don't know > if you used that to do the install. ------------------- No, I have installed it by hand. Thanks, it works... Andrej From owner-linux-xfs@oss.sgi.com Wed Jan 16 11:01:07 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0GJ17m05063 for linux-xfs-outgoing; Wed, 16 Jan 2002 11:01:07 -0800 Received: from anchor-post-34.mail.demon.net (anchor-post-34.mail.demon.net [194.217.242.92]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0GJ11P05031 for ; Wed, 16 Jan 2002 11:01:02 -0800 Received: from sweeney.demon.co.uk ([158.152.71.87] helo=pereskia.sweeney.demon.co.uk) by anchor-post-34.mail.demon.net with esmtp (Exim 2.12 #1) id 16QuMs-0002EY-0Y for linux-xfs@oss.sgi.com; Wed, 16 Jan 2002 18:00:58 +0000 Received: from rebutia.sweeney.demon.co.uk (rebutia.sweeney.demon.co.uk [10.0.0.3]) by pereskia.sweeney.demon.co.uk (Postfix) with ESMTP id DC46F1F58 for ; Wed, 16 Jan 2002 12:31:45 +0000 (GMT) Received: by rebutia.sweeney.demon.co.uk (Postfix, from userid 1001) id 80E7E125E6; Wed, 16 Jan 2002 12:27:43 +0000 (GMT) Date: Wed, 16 Jan 2002 12:27:43 +0000 (GMT) From: Keith Matthews Subject: Re[2]: OOM difference on IRIX vs. linux To: linux-xfs@oss.sgi.com In-Reply-To: <6ulmeymyh5.fsf@zork.zork.net> References: , <6ulmeymyh5.fsf@zork.zork.net> X-Mailer: Mahogany, 0.60 'Redmond', compiled for Linux 2.2.13 i686 MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=ISO-8859-1 Content-Disposition: INLINE Message-Id: <20020116122743.80E7E125E6@rebutia.sweeney.demon.co.uk> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from QUOTED-PRINTABLE to 8bit by oss.sgi.com id g0GJ12P05032 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 916 Lines: 26 On Wed, 16 Jan 2002 09:33:42 +0000 Sean Neakums > wrote: > begin Dan Hollis quotation: > > Its too bad theres no signal mechanism for userspace for 'memory > >low', eg SIGLOWMEM so userspace apps could voluntarily release > >resources to ease memory pressure. > There was a big discussion on LKML about that a few months back. I > forget what the outcome was. Implementation on these things can be crucial. A few years ago I was having trouble with Oracle on an ICL Unix box (though I think the vendor was immateriel). periodically when it tried to get extra resources it would go into a tight loop, grabbing all available CPU. We eventually concluded it was calling malloc, not getting as much as it wanted, calling malloc........ . I'm sure you get the picture. -- Keith Matthews Frequentous Consultants - Linux Services, Oracle development & database administration From owner-linux-xfs@oss.sgi.com Wed Jan 16 11:10:52 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0GJAq005865 for linux-xfs-outgoing; Wed, 16 Jan 2002 11:10:52 -0800 Received: from fep06-app.kolumbus.fi (fep06-0.kolumbus.fi [193.229.0.57]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0GJAmP05840 for ; Wed, 16 Jan 2002 11:10:48 -0800 Received: from there ([62.248.178.141]) by fep06-app.kolumbus.fi (InterMail vM.5.01.03.15 201-253-122-118-115-20011108) with SMTP id <20020116181033.NSND7081.fep06-app.kolumbus.fi@there> for ; Wed, 16 Jan 2002 20:10:33 +0200 Content-Type: text/plain; charset="iso-8859-1" From: Hristo Grigorov To: linux-xfs@oss.sgi.com Subject: Re: Developerworks XFS introduction. Date: Wed, 16 Jan 2002 20:07:10 +0200 X-Mailer: KMail [version 1.3.2] References: In-Reply-To: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Message-Id: <20020116181033.NSND7081.fep06-app.kolumbus.fi@there> Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 394 Lines: 17 On Wednesday 16 January 2002 10:14, Seth Mos wrote: > As linked to from http://linuxtoday.com/ > http://linuxtoday.com/news_story.php3?ltsn=2002-01-16-003-20-PS-KN > > IBM developerWorks: Introducing XFS > http://www-106.ibm.com/developerworks/library/l-fs9.html > > Cheers > Seth > > Note that I have not read the article yet. Hmm, why presented by IBM and not SGI ? :) -- Cheers, Hristo. From owner-linux-xfs@oss.sgi.com Wed Jan 16 12:00:45 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0GK0jg15546 for linux-xfs-outgoing; Wed, 16 Jan 2002 12:00:45 -0800 Received: from pneumatic-tube.sgi.com (pneumatic-tube.sgi.com [204.94.214.22]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0GK0dP15520 for ; Wed, 16 Jan 2002 12:00:39 -0800 Received: from zeus-e8.americas.sgi.com (zeus-e8.americas.sgi.com [128.162.8.103]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id LAA01978 for ; Wed, 16 Jan 2002 11:01:23 -0800 (PST) mail_from (lord@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by zeus-e8.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id MAA25144; Wed, 16 Jan 2002 12:59:18 -0600 (CST) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id MAA40792; Wed, 16 Jan 2002 12:59:18 -0600 (CST) Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id g0GIv9R09269; Wed, 16 Jan 2002 12:57:09 -0600 Subject: Re: Developerworks XFS introduction. From: Steve Lord To: Hristo Grigorov Cc: linux-xfs@oss.sgi.com In-Reply-To: <20020116181033.NSND7081.fep06-app.kolumbus.fi@there> References: <20020116181033.NSND7081.fep06-app.kolumbus.fi@there> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/1.0.1 Date: 16 Jan 2002 12:57:09 -0600 Message-Id: <1011207429.13534.278.camel@jen.americas.sgi.com> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 826 Lines: 30 On Wed, 2002-01-16 at 12:07, Hristo Grigorov wrote: > On Wednesday 16 January 2002 10:14, Seth Mos wrote: > > As linked to from http://linuxtoday.com/ > > http://linuxtoday.com/news_story.php3?ltsn=2002-01-16-003-20-PS-KN > > > > IBM developerWorks: Introducing XFS > > http://www-106.ibm.com/developerworks/library/l-fs9.html > > > > Cheers > > Seth > > > > Note that I have not read the article yet. > > Hmm, why presented by IBM and not SGI ? :) Because IBM is sponsoring (I do not know details) lots of people to write articles about linux things, this is part of a large series on different filestsystems - and it was not written by IBM. Steve > > -- > Cheers, Hristo. -- Steve Lord voice: +1-651-683-3511 Principal Engineer, Filesystem Software email: lord@sgi.com From owner-linux-xfs@oss.sgi.com Wed Jan 16 12:09:50 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0GK9oE16051 for linux-xfs-outgoing; Wed, 16 Jan 2002 12:09:50 -0800 Received: from UberGeek.coremetrics.com ([209.184.141.163]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0GK9eP16027 for ; Wed, 16 Jan 2002 12:09:40 -0800 Received: (from austin@localhost) by UberGeek.coremetrics.com (8.11.6/8.11.6) id g0GJ6lP19071; Wed, 16 Jan 2002 13:06:47 -0600 X-Authentication-Warning: UberGeek.coremetrics.com: austin set sender to austin@coremetrics.com using -f Subject: Re: Developerworks XFS introduction. From: Austin Gonyou To: Steve Lord Cc: Hristo Grigorov , linux-xfs@oss.sgi.com In-Reply-To: <1011207429.13534.278.camel@jen.americas.sgi.com> References: <1011207429.13534.278.camel@jen.americas.sgi.com> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-llKd8zdSZt42O8dOYhVo" X-Mailer: Evolution/1.0.1 Date: 16 Jan 2002 13:06:47 -0600 Message-Id: <1011208007.18951.1.camel@UberGeek> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 1824 Lines: 63 --=-llKd8zdSZt42O8dOYhVo Content-Type: text/plain Content-Transfer-Encoding: quoted-printable It is a very good article, and actually I had a question about it. In the part which talks about file delete times, what is the fix for this or what kernel will have it? On Wed, 2002-01-16 at 12:57, Steve Lord wrote: > On Wed, 2002-01-16 at 12:07, Hristo Grigorov wrote: > > On Wednesday 16 January 2002 10:14, Seth Mos wrote: > > > As linked to from http://linuxtoday.com/ > > > http://linuxtoday.com/news_story.php3?ltsn=3D2002-01-16-003-20-PS-KN > > > > > > IBM developerWorks: Introducing XFS > > > http://www-106.ibm.com/developerworks/library/l-fs9.html > > > > > > Cheers > > > Seth > > > > > > Note that I have not read the article yet. > >=20 > > Hmm, why presented by IBM and not SGI ? :) >=20 > Because IBM is sponsoring (I do not know details) lots of people to > write articles about linux things, this is part of a large series on > different filestsystems - and it was not written by IBM. >=20 > Steve >=20 >=20 > >=20 > > --=20 > > Cheers, Hristo. > --=20 >=20 > Steve Lord voice: +1-651-683-3511 > Principal Engineer, Filesystem Software email: lord@sgi.com --=20 Austin Gonyou Systems Architect, CCNA Coremetrics, Inc. Phone: 512-698-7250 email: austin@coremetrics.com "It is the part of a good shepherd to shear his flock, not to skin it." Latin Proverb --=-llKd8zdSZt42O8dOYhVo Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQA8Rc9H94g6ZVmFMoIRAibUAKDLzyPp0KLr9m5xbNH+XSZBl+ehkwCgmwpI xq/fMU+kbgDxRELXb6C1yFk= =oysD -----END PGP SIGNATURE----- --=-llKd8zdSZt42O8dOYhVo-- From owner-linux-xfs@oss.sgi.com Wed Jan 16 13:27:48 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0GLRmm23000 for linux-xfs-outgoing; Wed, 16 Jan 2002 13:27:48 -0800 Received: from maple.sucs.soton.ac.uk (maple.sucs.soton.ac.uk [152.78.128.16]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0GLRRP22975 for ; Wed, 16 Jan 2002 13:27:28 -0800 Received: from poplar.sucs.soton.ac.uk (poplar.sucs.soton.ac.uk [152.78.128.30]) by maple.sucs.soton.ac.uk (8.10.0/8.10.0) with ESMTP id g0GKRNH02274 for ; Wed, 16 Jan 2002 20:27:23 GMT Received: from soton.ac.uk (pluto.sucs.soton.ac.uk [152.78.128.80]) (authenticated as idh) by poplar.sucs.soton.ac.uk (8.10.0/8.10.0) with ESMTP id g0GKRC200468; Wed, 16 Jan 2002 20:27:12 GMT Message-ID: <3C45E220.B8CE3257@soton.ac.uk> Date: Wed, 16 Jan 2002 20:27:12 +0000 From: "Ian D. Hardy" Organization: University of Southampton X-Mailer: Mozilla 4.7C-SGI [en] (X11; I; IRIX 6.5 IP32) X-Accept-Language: en MIME-Version: 1.0 To: linux-xfs@oss.sgi.com CC: "Ian D. Hardy" Subject: Re: XFS/NFS server oops ..... any ideas. References: <200201152229.WAA440925@plum.sucs.soton.ac.uk> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-MailScanner: Believed to be clean Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 7114 Lines: 150 Hi, I've been looking at this further today. If Steve Lord is correct in his assessment that my Oops was due to a 'out of memory condition' (I'm sure he is, looks sensible) and I've correctly interpreted memory usage (via 'vmstat') then it would appear that the kernel is running out of available memory, with resultant problems for XFS because all of the memory is been used, most of it to cache filesystem data. Currently 'top' is showing: 7:03pm up 7:19, 2 users, load average: 0.00, 0.00, 0.00 108 processes: 107 sleeping, 1 running, 0 zombie, 0 stopped CPU states: 0.1% user, 0.5% system, 0.0% nice, 99.2% idle Mem: 898848K av, 895792K used, 3056K free, 0K shrd, 13392K buff Swap: 1028120K av, 4780K used, 1023340K free 820396K cached Confirming that the majority of the memory is been used for cache and that there is currently just under 3Mbytes of RAM free, so I can see how a sudden kernel demand for memory may result in a failure before 'kswapd' has chance to free some memory up. Isn't this a common problem? wouldn't this be the normal state for a fileserver with more 'active' data than memory - filesystem cache will (under Linux) grow to use as much memory as possible, hence 'free' memory will be at a minimum? From this reasoning adding more memory is unlikely to help - as the system will just use more cache until there is the same minimum amount of memory? It would appear that XFS has the potential to make heavier demands on kernel memory and/or does not check that memory was allocated (I assume that its memory allocation calls are such that it expects memory to be allocated from immediately available physical memory?), hence this problem (I believe a number of people have reported problems that have been attributed to memory allocation errors?). ..... have I missed something? I then looked to try to find out how to decrease the maximum amount of memory that the kernel would use as FS cache (or increase the minimum amount of memory that the kernel would try to keep free). Thanks to harri.haataja@cs.Helsinki.FI for pointing me in the direction of 'Documentation/sysctl/vm.txt' in the kernel. Though as was noted this document is out of date referring to the 2.2 series kernels. It does however point to '/proc/sys/vm/feepages' as giving the number of pages at which 'kswapd' will start to free pages. This seems to exist in the 2.4 series kernels upto 2.4.9 (it may be 10 or 11?) after that the VM changed and this parameter went away (though the documentation hasn't changed...... So I'm completely lost with the later kernels!). Anyway back to 2.4.9: # cat /proc/sys/vm/freepages 383 766 1149 Which means that the kernel will try to maintain 1149 pages (~4.5Mbytes) free memory, will try even harder to free memory at 766 pages and will stop allocating memory other than to root if free memory falls below 383 pages (~1.5Mbytes). This would seem to agree with 'vmstat'/'top' which tend to show ~3Mbytes free memory. I then tried to increase these values, however these appear to be read only values (tried by writing directly to the file and using 'sysctl'. Indeed a comment in the kernel file 'mm/page_alloc.c' confirms that the 'freepages' array is not writable due to potential conflicts with different memory zones. So I'm stuck again. I've not been able to find any obvious place in the kernel source to change these values at kernel compilation time either. Any ideas? (either for 2.4.9 or ideally in latter/current kernels, I have reproduced what looked like a similar failure with 2.4.16 and 2.4.17 but unfortunately did not get the Oops details to confirm that it was the same problem, I'll try to setup a test to get this info, is there any more info that would help). FYI: test environment is a server and a number (~6) client machines running a mixture of 'bonnie' runs and back-to-back tar's copying the local /usr to the shared filesystem from the server (last time I looked at this it lasted ~ 24hours). Many thanks for your time. Ian "Ian D. Hardy" wrote: > > > > > On Tue, 2002-01-15 at 13:33, Ian D. Hardy wrote: > > > Hi, > > > > > > For some time we've been having problem with a server, which is acting > > > as a master/control node and NFS server for a computational cluster > > > (~180 client nodes). The server will crash after anywhere between > > > a few hours and 10 days operation. We've tried various kernels and > > > XFS patch versions from 2.4.9 kernel with XFS patch-2.4.9-xfs-2001-08-17 > > > up to and including 2.4.16 kernel with the xfs-2.4.16-all-i386 patch, > > > if anything the 2.4.9 kernel has proved the most reliable (it normally > > > lasts between 4 and 10 days! - 2.4.16 lasted less than 24hrs). > .... more details deleted > > > > > > > Almost certainly this is an out of memory condition, just from looking > > at the code in the function you oopsed in. Would you say your system is > > stressed when it comes to memory? > > > > Steve > > > > Steve Lord voice: +1-651-683-3511 > > Principal Engineer, Filesystem Software email: lord@sgi.com > > > > I'd not regard the server as short of memory as its using ~660Mbytes as > file system cache, though interestingly it does appear to be using some > swap space. Is it possible that XFS is having problems when there is not > memory immediately available, I've included some 'vmstat' output: > > vmstat 10 10 > procs memory swap io system cpu > r b w swpd free buff cache si so bi bo in cs us sy id > 0 1 28 11116 3784 42300 674656 0 0 37 35 19 3 0 2 23 > 0 1 28 11116 3480 42300 674960 0 0 0 0 167 194 0 0 100 > 0 1 28 11116 3176 42300 675264 0 0 0 0 139 107 0 0 100 > 0 1 28 11116 3056 42300 675380 0 0 0 2 152 142 0 0 100 > > In Irix I'd tune the kernel parameters 'min_free_pages'... to ensure that > there was always physical memory available, is there any equivalent in > Linux (sorry if this is a silly/obvious question). > > Many thanks. > > Ian > > -- > > //////////////////////////////////////////////////////////////////////////// > Ian Hardy Tel: 023 80593577 > Research Services Fax: 023 80593131 > Computing Services email: idh@soton.ac.uk > Southampton University i.d.hardy@soton.ac.uk > Southampton S017 1BJ, UK. > \\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\ -- /////////////Technical Coordination, Research Services//////////////////// Ian Hardy Tel: 023 80 593577 Computing Services Mobile: 0709 2127503 Southampton University email: idh@soton.ac.uk Southampton S017 1BJ, UK. i.d.hardy@soton.ac.uk \\'BUGS: The notion of errors is ill-defined' (IRIX man page for netstat)\ From owner-linux-xfs@oss.sgi.com Wed Jan 16 13:37:01 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0GLb1l23295 for linux-xfs-outgoing; Wed, 16 Jan 2002 13:37:01 -0800 Received: from zok.sgi.com (zok.sgi.com [204.94.215.101]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0GLagP23263 for ; Wed, 16 Jan 2002 13:36:42 -0800 Received: from zeus-e8.americas.sgi.com (zeus-e8.americas.sgi.com [128.162.8.103]) by zok.sgi.com (8.11.4/8.11.4/linux-outbound_gateway-1.1) with ESMTP id g0GKaYo01150 for ; Wed, 16 Jan 2002 12:36:34 -0800 Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by zeus-e8.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id OAA26789; Wed, 16 Jan 2002 14:35:17 -0600 (CST) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id OAA38540; Wed, 16 Jan 2002 14:35:17 -0600 (CST) Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id g0GKX7Z09325; Wed, 16 Jan 2002 14:33:07 -0600 Subject: Re: XFS/NFS server oops ..... any ideas. From: Steve Lord To: "Ian D. Hardy" Cc: linux-xfs@oss.sgi.com In-Reply-To: <3C45E220.B8CE3257@soton.ac.uk> References: <200201152229.WAA440925@plum.sucs.soton.ac.uk> <3C45E220.B8CE3257@soton.ac.uk> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/1.0.1 Date: 16 Jan 2002 14:33:07 -0600 Message-Id: <1011213187.13548.368.camel@jen.americas.sgi.com> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 7823 Lines: 162 Please try the current cvs tree, the 2.4.17 split patches may be close enough, anything prior to that has problems with a memory leak under pressure. Lets then take a closer look at the oops output from that. Steve On Wed, 2002-01-16 at 14:27, Ian D. Hardy wrote: > Hi, > > I've been looking at this further today. > > If Steve Lord is correct in his assessment that my Oops was due to a 'out of > memory condition' (I'm sure he is, looks sensible) and I've correctly > interpreted memory usage (via 'vmstat') then it would appear that the > kernel is running out of available memory, with resultant problems for > XFS because all of the memory is been used, most of it to cache filesystem > data. Currently 'top' is showing: > > 7:03pm up 7:19, 2 users, load average: 0.00, 0.00, 0.00 > 108 processes: 107 sleeping, 1 running, 0 zombie, 0 stopped > CPU states: 0.1% user, 0.5% system, 0.0% nice, 99.2% idle > Mem: 898848K av, 895792K used, 3056K free, 0K shrd, 13392K buff > Swap: 1028120K av, 4780K used, 1023340K free 820396K cached > > Confirming that the majority of the memory is been used for cache and that > there is currently just under 3Mbytes of RAM free, so I can see how a sudden > kernel demand for memory may result in a failure before 'kswapd' has chance > to free some memory up. > > Isn't this a common problem? wouldn't this be the normal state for > a fileserver with more 'active' data than memory - filesystem cache will > (under Linux) grow to use as much memory as possible, hence 'free' memory > will be at a minimum? From this reasoning adding more memory is unlikely > to help - as the system will just use more cache until there is the same > minimum amount of memory? > > It would appear that XFS has the potential to make heavier demands > on kernel memory and/or does not check that memory was allocated (I > assume that its memory allocation calls are such that it expects memory > to be allocated from immediately available physical memory?), hence > this problem (I believe a number of people have reported problems that > have been attributed to memory allocation errors?). > > ..... have I missed something? > > I then looked to try to find out how to decrease the maximum amount of > memory that the kernel would use as FS cache (or increase the minimum > amount of memory that the kernel would try to keep free). Thanks to > harri.haataja@cs.Helsinki.FI for pointing me in the direction of > 'Documentation/sysctl/vm.txt' in the kernel. Though as was noted this > document is out of date referring to the 2.2 series kernels. It does > however point to '/proc/sys/vm/feepages' as giving the number of pages > at which 'kswapd' will start to free pages. This seems to exist in the > 2.4 series kernels upto 2.4.9 (it may be 10 or 11?) after that the VM > changed and this parameter went away (though the documentation hasn't > changed...... So I'm completely lost with the later kernels!). Anyway > back to 2.4.9: > > # cat /proc/sys/vm/freepages > 383 766 1149 > > Which means that the kernel will try to maintain 1149 pages (~4.5Mbytes) > free memory, will try even harder to free memory at 766 pages and will > stop allocating memory other than to root if free memory falls below > 383 pages (~1.5Mbytes). This would seem to agree with 'vmstat'/'top' > which tend to show ~3Mbytes free memory. I then tried to increase > these values, however these appear to be read only values (tried by > writing directly to the file and using 'sysctl'. Indeed a comment > in the kernel file 'mm/page_alloc.c' confirms that the 'freepages' > array is not writable due to potential conflicts with different memory > zones. So I'm stuck again. I've not been able to find any obvious > place in the kernel source to change these values at kernel compilation > time either. > > Any ideas? (either for 2.4.9 or ideally in latter/current > kernels, I have reproduced what looked like a similar failure with > 2.4.16 and 2.4.17 but unfortunately did not get the Oops details to > confirm that it was the same problem, I'll try to setup a test to > get this info, is there any more info that would help). FYI: test > environment is a server and a number (~6) client machines running > a mixture of 'bonnie' runs and back-to-back tar's copying the local > /usr to the shared filesystem from the server (last time I looked > at this it lasted ~ 24hours). > > Many thanks for your time. > > Ian > > > > "Ian D. Hardy" wrote: > > > > > > > > On Tue, 2002-01-15 at 13:33, Ian D. Hardy wrote: > > > > Hi, > > > > > > > > For some time we've been having problem with a server, which is acting > > > > as a master/control node and NFS server for a computational cluster > > > > (~180 client nodes). The server will crash after anywhere between > > > > a few hours and 10 days operation. We've tried various kernels and > > > > XFS patch versions from 2.4.9 kernel with XFS patch-2.4.9-xfs-2001-08-17 > > > > up to and including 2.4.16 kernel with the xfs-2.4.16-all-i386 patch, > > > > if anything the 2.4.9 kernel has proved the most reliable (it normally > > > > lasts between 4 and 10 days! - 2.4.16 lasted less than 24hrs). > > .... more details deleted > > > > > > > > > > Almost certainly this is an out of memory condition, just from looking > > > at the code in the function you oopsed in. Would you say your system is > > > stressed when it comes to memory? > > > > > > Steve > > > > > > Steve Lord voice: +1-651-683-3511 > > > Principal Engineer, Filesystem Software email: lord@sgi.com > > > > > > > I'd not regard the server as short of memory as its using ~660Mbytes as > > file system cache, though interestingly it does appear to be using some > > swap space. Is it possible that XFS is having problems when there is not > > memory immediately available, I've included some 'vmstat' output: > > > > vmstat 10 10 > > procs memory swap io system cpu > > r b w swpd free buff cache si so bi bo in cs us sy id > > 0 1 28 11116 3784 42300 674656 0 0 37 35 19 3 0 2 23 > > 0 1 28 11116 3480 42300 674960 0 0 0 0 167 194 0 0 100 > > 0 1 28 11116 3176 42300 675264 0 0 0 0 139 107 0 0 100 > > 0 1 28 11116 3056 42300 675380 0 0 0 2 152 142 0 0 100 > > > > In Irix I'd tune the kernel parameters 'min_free_pages'... to ensure that > > there was always physical memory available, is there any equivalent in > > Linux (sorry if this is a silly/obvious question). > > > > Many thanks. > > > > Ian > > > > -- > > > > //////////////////////////////////////////////////////////////////////////// > > Ian Hardy Tel: 023 80593577 > > Research Services Fax: 023 80593131 > > Computing Services email: idh@soton.ac.uk > > Southampton University i.d.hardy@soton.ac.uk > > Southampton S017 1BJ, UK. > > \\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\ > > -- > > /////////////Technical Coordination, Research Services//////////////////// > Ian Hardy Tel: 023 80 593577 > Computing Services Mobile: 0709 2127503 > Southampton University email: idh@soton.ac.uk > Southampton S017 1BJ, UK. i.d.hardy@soton.ac.uk > \\'BUGS: The notion of errors is ill-defined' (IRIX man page for netstat)\ -- Steve Lord voice: +1-651-683-3511 Principal Engineer, Filesystem Software email: lord@sgi.com From owner-linux-xfs@oss.sgi.com Wed Jan 16 13:39:59 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0GLdxs23523 for linux-xfs-outgoing; Wed, 16 Jan 2002 13:39:59 -0800 Received: from zok.sgi.com (zok.sgi.com [204.94.215.101]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0GLduP23477 for ; Wed, 16 Jan 2002 13:39:56 -0800 Received: from zeus-e8.americas.sgi.com (zeus-e8.americas.sgi.com [128.162.8.103]) by zok.sgi.com (8.11.4/8.11.4/linux-outbound_gateway-1.1) with ESMTP id g0GKdmo01596 for ; Wed, 16 Jan 2002 12:39:48 -0800 Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by zeus-e8.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id OAA26846 for ; Wed, 16 Jan 2002 14:38:32 -0600 (CST) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id OAA46978 for ; Wed, 16 Jan 2002 14:38:32 -0600 (CST) From: Steve Lord Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id g0GKaNT09407; Wed, 16 Jan 2002 14:36:23 -0600 Message-Id: <200201162036.g0GKaNT09407@jen.americas.sgi.com> Date: Wed, 16 Jan 2002 14:36:23 -0600 Subject: TAKE - backout an nfs change Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 553 Lines: 17 A couple of new operations where being used by the nfs server, at least two people have reported problems with these, so fall back to the old code path until we can make them work properly. Date: Wed Jan 16 12:36:29 PST 2002 Workarea: jen.americas.sgi.com:/src/lord/xfs-linux.2.4 The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:109726a linux/fs/xfs/linux/xfs_super.c - 1.154 - Turn off the fhandle to dentry and dentry to fhandle calls, they appear to cause some people problems. From owner-linux-xfs@oss.sgi.com Wed Jan 16 13:40:21 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0GLeL523608 for linux-xfs-outgoing; Wed, 16 Jan 2002 13:40:21 -0800 Received: from UberGeek.coremetrics.com ([209.184.141.163]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0GLdtP23476 for ; Wed, 16 Jan 2002 13:39:55 -0800 Received: (from austin@localhost) by UberGeek.coremetrics.com (8.11.6/8.11.6) id g0GKdAe19629; Wed, 16 Jan 2002 14:39:10 -0600 X-Authentication-Warning: UberGeek.coremetrics.com: austin set sender to austin@coremetrics.com using -f Subject: Re: XFS/NFS server oops ..... any ideas. From: Austin Gonyou To: "Ian D. Hardy" Cc: linux-xfs@oss.sgi.com In-Reply-To: <3C45E220.B8CE3257@soton.ac.uk> References: <3C45E220.B8CE3257@soton.ac.uk> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-tEYc4LG/qL1cWYbe7Xag" X-Mailer: Evolution/1.0.1 Date: 16 Jan 2002 14:39:10 -0600 Message-Id: <1011213550.19615.1.camel@UberGeek> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 8469 Lines: 220 --=-tEYc4LG/qL1cWYbe7Xag Content-Type: text/plain Content-Transfer-Encoding: quoted-printable What disks are you using? What is your subsystem like? e.g. MegaRAID 500 attatched to 12 SCSI disks. 5 LVM Volumes + XFS.=20 And then what applications is your system running. Something sounds odd here.=20 On Wed, 2002-01-16 at 14:27, Ian D. Hardy wrote: > Hi, >=20 > I've been looking at this further today. >=20 > If Steve Lord is correct in his assessment that my Oops was due to a > 'out of > memory condition' (I'm sure he is, looks sensible) and I've correctly > interpreted memory usage (via 'vmstat') then it would appear that the > kernel is running out of available memory, with resultant problems for > XFS because all of the memory is been used, most of it to cache > filesystem > data. Currently 'top' is showing: >=20 > 7:03pm up 7:19, 2 users, load average: 0.00, 0.00, 0.00 > 108 processes: 107 sleeping, 1 running, 0 zombie, 0 stopped > CPU states: 0.1% user, 0.5% system, 0.0% nice, 99.2% idle > Mem: 898848K av, 895792K used, 3056K free, 0K shrd, 13392K > buff > Swap: 1028120K av, 4780K used, 1023340K free 820396K > cached >=20 > Confirming that the majority of the memory is been used for cache and > that > there is currently just under 3Mbytes of RAM free, so I can see how a > sudden > kernel demand for memory may result in a failure before 'kswapd' has > chance > to free some memory up. >=20 > Isn't this a common problem? wouldn't this be the normal state for=20 > a fileserver with more 'active' data than memory - filesystem cache will > (under Linux) grow to use as much memory as possible, hence 'free' > memory > will be at a minimum? From this reasoning adding more memory is unlikely > to help - as the system will just use more cache until there is the same > minimum amount of memory? >=20 > It would appear that XFS has the potential to make heavier demands > on kernel memory and/or does not check that memory was allocated (I > assume that its memory allocation calls are such that it expects memory > to be allocated from immediately available physical memory?), hence > this problem (I believe a number of people have reported problems that > have been attributed to memory allocation errors?). >=20 > ..... have I missed something? >=20 > I then looked to try to find out how to decrease the maximum amount of > memory that the kernel would use as FS cache (or increase the minimum > amount of memory that the kernel would try to keep free). Thanks to=20 > harri.haataja@cs.Helsinki.FI for pointing me in the direction of > 'Documentation/sysctl/vm.txt' in the kernel. Though as was noted this > document is out of date referring to the 2.2 series kernels. It does > however point to '/proc/sys/vm/feepages' as giving the number of pages > at which 'kswapd' will start to free pages. This seems to exist in the > 2.4 series kernels upto 2.4.9 (it may be 10 or 11?) after that the VM > changed and this parameter went away (though the documentation hasn't=20 > changed...... So I'm completely lost with the later kernels!). Anyway > back to 2.4.9: >=20 > # cat /proc/sys/vm/freepages > 383 766 1149 >=20 > Which means that the kernel will try to maintain 1149 pages (~4.5Mbytes) > free memory, will try even harder to free memory at 766 pages and will > stop allocating memory other than to root if free memory falls below > 383 pages (~1.5Mbytes). This would seem to agree with 'vmstat'/'top' > which tend to show ~3Mbytes free memory. I then tried to increase > these values, however these appear to be read only values (tried by > writing directly to the file and using 'sysctl'. Indeed a comment > in the kernel file 'mm/page_alloc.c' confirms that the 'freepages' > array is not writable due to potential conflicts with different memory > zones. So I'm stuck again. I've not been able to find any obvious > place in the kernel source to change these values at kernel compilation > time either. >=20 > Any ideas? (either for 2.4.9 or ideally in latter/current > kernels, I have reproduced what looked like a similar failure with > 2.4.16 and 2.4.17 but unfortunately did not get the Oops details to > confirm that it was the same problem, I'll try to setup a test to > get this info, is there any more info that would help). FYI: test > environment is a server and a number (~6) client machines running > a mixture of 'bonnie' runs and back-to-back tar's copying the local > /usr to the shared filesystem from the server (last time I looked > at this it lasted ~ 24hours). >=20 > Many thanks for your time. >=20 > Ian >=20 >=20=20=20 >=20 > "Ian D. Hardy" wrote: > >=20 > > > > > > On Tue, 2002-01-15 at 13:33, Ian D. Hardy wrote: > > > > Hi, > > > > > > > > For some time we've been having problem with a server, which is > acting > > > > as a master/control node and NFS server for a computational > cluster > > > > (~180 client nodes). The server will crash after anywhere between > > > > a few hours and 10 days operation. We've tried various kernels and > > > > XFS patch versions from 2.4.9 kernel with XFS > patch-2.4.9-xfs-2001-08-17 > > > > up to and including 2.4.16 kernel with the xfs-2.4.16-all-i386 > patch, > > > > if anything the 2.4.9 kernel has proved the most reliable (it > normally > > > > lasts between 4 and 10 days! - 2.4.16 lasted less than 24hrs). > > .... more details deleted > > > > > > > > > > Almost certainly this is an out of memory condition, just from > looking > > > at the code in the function you oopsed in. Would you say your system > is > > > stressed when it comes to memory? > > > > > > Steve > > > > > > Steve Lord voice: > +1-651-683-3511 > > > Principal Engineer, Filesystem Software email: lord@sgi.com > > > > >=20 > > I'd not regard the server as short of memory as its using ~660Mbytes > as > > file system cache, though interestingly it does appear to be using > some > > swap space. Is it possible that XFS is having problems when there is > not > > memory immediately available, I've included some 'vmstat' output: > >=20 > > vmstat 10 10 > > procs memory swap io system > cpu > > r b w swpd free buff cache si so bi bo in cs > us sy id > > 0 1 28 11116 3784 42300 674656 0 0 37 35 19 3 > 0 2 23 > > 0 1 28 11116 3480 42300 674960 0 0 0 0 167 194 > 0 0 100 > > 0 1 28 11116 3176 42300 675264 0 0 0 0 139 107 > 0 0 100 > > 0 1 28 11116 3056 42300 675380 0 0 0 2 152 142 > 0 0 100 > >=20 > > In Irix I'd tune the kernel parameters 'min_free_pages'... to ensure > that > > there was always physical memory available, is there any equivalent in > > Linux (sorry if this is a silly/obvious question). > >=20 > > Many thanks. > >=20 > > Ian > >=20 > > -- > >=20 > > > //////////////////////////////////////////////////////////////////////// > //// > > Ian Hardy Tel: 023 80593577 > > Research Services Fax: 023 80593131 > > Computing Services email: idh@soton.ac.uk > > Southampton University > i.d.hardy@soton.ac.uk > > Southampton S017 1BJ, UK. > > > \\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\ > \\\\ >=20 > --=20 >=20 > /////////////Technical Coordination, Research > Services//////////////////// > Ian Hardy Tel: 023 80 593577 > Computing Services Mobile: 0709 2127503=20=20=20= =20 > Southampton University email: idh@soton.ac.uk > Southampton S017 1BJ, UK. i.d.hardy@soton.ac.uk > \\'BUGS: The notion of errors is ill-defined' (IRIX man page for > netstat)\ --=20 Austin Gonyou Systems Architect, CCNA Coremetrics, Inc. Phone: 512-698-7250 email: austin@coremetrics.com "It is the part of a good shepherd to shear his flock, not to skin it." Latin Proverb --=-tEYc4LG/qL1cWYbe7Xag Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQA8ReTu94g6ZVmFMoIRAr8XAKCSg0vPCxzsaznn2ntSwwNHmx6jjgCg3HVD sRHH1GBnCG8Q/teRW9nnPHs= =cIDK -----END PGP SIGNATURE----- --=-tEYc4LG/qL1cWYbe7Xag-- From owner-linux-xfs@oss.sgi.com Wed Jan 16 15:53:59 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0GNrxx26987 for linux-xfs-outgoing; Wed, 16 Jan 2002 15:53:59 -0800 Received: from mail.merlinsoftech.com (www.merlinsoftech.com [207.219.3.100]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0GNrqP26962 for ; Wed, 16 Jan 2002 15:53:52 -0800 Received: from philip (philip.merlinsoftech.com [192.168.1.23]) by mail.merlinsoftech.com (8.11.6/8.11.6) with SMTP id g0GMroa22249 for ; Wed, 16 Jan 2002 14:53:50 -0800 Message-ID: <006001c19ee0$aa218170$1701a8c0@win2kserver.win2kdomain.com> From: "Philip Chiang" To: Subject: Question: why does dbench take so much longer to run on XFS then ext2 file system Date: Wed, 16 Jan 2002 14:53:50 -0800 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Content-Disposition: inline Content-Type: text/plain Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 699 Lines: 36 Hi, I am trying to make comparisons between ext2 and xfs file system. I ran dbench on my system with 150 clients on the ext2 file system and on the xfs file system. I ran this test several times, but the results are similar. On xfs, dbench takes 211 mins to finish. Where on ext2, it takes 60 mins. I want to ask "why it has such a big difference on the two file system?" One more note, when dbench is running on xfs, the whole system tag downs, CPU usage is at 99% all the time, is this normal? I am using: 2.4.17 kernel xfs patches for 2.4.17 128 M RAM P3 850 40 GB IDE hard drives Thanks Philip Chiang (pchiang@merlinsoftech.com) [[HTML alternate version deleted]] From owner-linux-xfs@oss.sgi.com Wed Jan 16 16:23:40 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0H0Ne527680 for linux-xfs-outgoing; Wed, 16 Jan 2002 16:23:40 -0800 Received: from mail.merlinsoftech.com (www.merlinsoftech.com [207.219.3.100]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0H0NYP27658 for ; Wed, 16 Jan 2002 16:23:34 -0800 Received: from philip (philip.merlinsoftech.com [192.168.1.23]) by mail.merlinsoftech.com (8.11.6/8.11.6) with SMTP id g0GNNWa27499 for ; Wed, 16 Jan 2002 15:23:32 -0800 Message-ID: <000801c19ee4$d012ce30$1701a8c0@win2kserver.win2kdomain.com> From: "Philip Chiang" To: References: <006001c19ee0$aa218170$1701a8c0@win2kserver.win2kdomain.com> <1011222311.3602.10.camel@stout.americas.sgi.com> Subject: Re: Question: why does dbench take so much longer to run on XFSthen ext2 file system Date: Wed, 16 Jan 2002 15:23:32 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 1229 Lines: 37 sorry, forgot to mention. it not in a raid. the test was done on a single 40 GB IDE hard drive. Thanks ----- Original Message ----- From: "Eric Sandeen" To: "Philip Chiang" Sent: Wednesday, January 16, 2002 3:05 PM Subject: Re: Question: why does dbench take so much longer to run on XFSthen ext2 file system > hi Philip, I should have asked - are you using raid? If so, make an > external log that's not part of the raid, and see how that goes. > > -Eric > > On Wed, 2002-01-16 at 16:53, Philip Chiang wrote: > > Hi, I am trying to make comparisons between ext2 and xfs file system. > I ran dbench on my system with 150 clients on the ext2 file system and > on the xfs file system. I ran this test several times, but the results > are similar. On xfs, dbench takes 211 mins to finish. Where on ext2, it > takes 60 mins. I want to ask "why it has such a big difference on the > two file system?" One more note, when dbench is running on xfs, the > whole system tag downs, CPU usage is at 99% all the time, is this > normal? > > > I am using: > > 40 GB IDE hard drives > -- > Eric Sandeen XFS for Linux http://oss.sgi.com/projects/xfs > sandeen@sgi.com SGI, Inc. > From owner-linux-xfs@oss.sgi.com Wed Jan 16 19:17:29 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0H3HTA31770 for linux-xfs-outgoing; Wed, 16 Jan 2002 19:17:29 -0800 Received: from gusi.leathercollection.ph (gusi.leathercollection.ph [202.163.192.10]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0H3HMP31748 for ; Wed, 16 Jan 2002 19:17:23 -0800 Received: from localhost (localhost [127.0.0.1]) by gusi.leathercollection.ph (Postfix) with ESMTP id 82DF3C00B5E for ; Thu, 17 Jan 2002 10:17:17 +0800 (PHT) Received: from mail.leathercollection.ph (gusi.leathercollection.ph [192.168.0.1]) by gusi.leathercollection.ph (Postfix) with ESMTP id 59845C00B5D for ; Thu, 17 Jan 2002 10:17:16 +0800 (PHT) Date: Thu, 17 Jan 2002 10:17:16 +0800 (PHT) From: Federico Sevilla III To: Linux XFS Mailing List Subject: Re: Developerworks XFS introduction. In-Reply-To: <20020116181033.NSND7081.fep06-app.kolumbus.fi@there> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by AMaViS perl-11 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 601 Lines: 21 On Wed, 16 Jan 2002 at 20:07, Hristo Grigorov wrote: > Hmm, why presented by IBM and not SGI ? :) I don't think it's "presented" by IBM. IBM merely hosts that DeveloperWorks site, where various people contribute various articles about various aspects of Linux. The article about XFS is the 9th article in a thread about advanced filesystems for Linux. Previously the author wrote about ReiserFS, tmpfs, DevFS, and Ext3. :) --> Jijo -- Federico Sevilla III :: jijo@leathercollection.ph Network Administrator :: The Leather Collection, Inc. GnuPG Key: http://jijo.leathercollection.ph/jijo.gpg From owner-linux-xfs@oss.sgi.com Wed Jan 16 20:32:15 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0H4WFf00545 for linux-xfs-outgoing; Wed, 16 Jan 2002 20:32:15 -0800 Received: from sgi.com (sgi.SGI.COM [192.48.153.1]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0H4WAP00518 for ; Wed, 16 Jan 2002 20:32:10 -0800 Received: from zeus-e8.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id TAA08063 for ; Wed, 16 Jan 2002 19:31:35 -0800 (PST) mail_from (lord@sgi.com) Received: from tulip-e185.americas.sgi.com (tulip-e185.americas.sgi.com [128.162.185.208]) by zeus-e8.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id VAA31176; Wed, 16 Jan 2002 21:30:52 -0600 (CST) Received: from sgi.com (yTPUM8JTbvDWVXxWokIZ/9Hbft/ulkDt@lord-h1.americas.sgi.com [206.11.101.42]) by tulip-e185.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.7) with ESMTP id VAA39375; Wed, 16 Jan 2002 21:30:51 -0600 (CST) Message-ID: <3C46468C.3050702@sgi.com> Date: Wed, 16 Jan 2002 21:35:40 -0600 From: Stephen Lord User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.6) Gecko/20011120 X-Accept-Language: en-us MIME-Version: 1.0 To: Philip Chiang CC: linux-xfs@oss.sgi.com Subject: Re: Question: why does dbench take so much longer to run on XFS then ext2 file system References: <006001c19ee0$aa218170$1701a8c0@win2kserver.win2kdomain.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 1414 Lines: 29 Philip Chiang wrote: >Hi, I am trying to make comparisons between ext2 and xfs file system. I ran dbench on my system with 150 clients on the ext2 file system and on the xfs file system. I ran this test several times, but the results are similar. On xfs, dbench takes 211 mins to finish. Where on ext2, it takes 60 mins. I want to ask "why it has such a big difference on the two file system?" One more note, when dbench is running on xfs, the whole system tag downs, CPU usage is at 99% all the time, is this normal? > Such a discrepency does not seem right, although at dbench 150 on a 128M box you are severely overdriving the memory. Anyone who runs hardware at this load level in a production environment is not going to get much out of it. It's a bit like running a news feed on your palm pilot. If you are trying to compare performance then compare loads which are realistic. I am doing some comparison runs here, but I have a question and a comment. o first, which xfs options do you have turned on? Did you enable extended attributes and dmapi? if you did then you really need to turn it off in a comparison - or get the ext2 equivalent code going. This would not however account for such a large difference. o A more apples with apples comparison would be ext3 (without data journalling) vs xfs. XFS is going to add the cost of journalling to operations, ext2 is not. Steve From owner-linux-xfs@oss.sgi.com Wed Jan 16 21:38:04 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0H5c4K01435 for linux-xfs-outgoing; Wed, 16 Jan 2002 21:38:04 -0800 Received: from blipvert.blank.org (blipvert.blank.org [216.112.239.86]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0H5bxP01413 for ; Wed, 16 Jan 2002 21:37:59 -0800 Received: (qmail 27890 invoked by uid 500); 17 Jan 2002 04:37:58 -0000 Date: Wed, 16 Jan 2002 23:37:58 -0500 From: "Nathan J. Mehl" To: Nathan Scott Cc: linux-xfs@oss.sgi.com Subject: Re: things to do in brooklyn when your filesystem is dead Message-ID: <20020116233758.X15376@blank.org> Mail-Followup-To: Nathan Scott , linux-xfs@oss.sgi.com References: <20020112122144.R15376@blank.org> <20020114113445.D24972@wobbly.melbourne.sgi.com> <20020115223312.G15376@blank.org> <20020116182420.F30220@wobbly.melbourne.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: <20020116182420.F30220@wobbly.melbourne.sgi.com>; from nathans@sgi.com on Wed, Jan 16, 2002 at 06:24:20PM +1100 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 1230 Lines: 29 In the immortal words of Nathan Scott (nathans@sgi.com): > > > > Is there anything that can be done manually to avoid this, or should I > > just let xfs_repair do its job and salvage what I can from lost+found? > > That's pretty much the only option available at this point > (unless you've used xfsdump/some other backup utility to keep > a recent backup, and can use that in conjunction/instead). Hm. Okay, I seem to have run into another xfs_repair issue. The cvs code pushes past the log error, but there are a number of inodes that it seems unable to properly clear/repair. Every run of xfs_repair on this fs since the first one produces the following output: http://blank.org/memory/repair.out Subsequent iterations produce exactly the same output, referencing exactly the same inodes. Any notion why xfs_repair might be claiming to move directories and files into lost+found but not actually doing it? -n ----------------------------------------------------------- "`G.I. Jane' is a demeaning, violent, bloody workout video. Some brief nudity, bad language and a false sense of human resilience. Rated R." (--CNN) --------------------------------------------------- From owner-linux-xfs@oss.sgi.com Thu Jan 17 00:33:09 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0H8X9i03808 for linux-xfs-outgoing; Thu, 17 Jan 2002 00:33:09 -0800 Received: from yog-sothoth.sgi.com (eugate.sgi.com [192.48.160.10]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0H8X5P03786 for ; Thu, 17 Jan 2002 00:33:05 -0800 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.55.149]) by yog-sothoth.sgi.com (980305.SGI.8.8.8-aspam-6.2/980304.SGI-aspam-europe) via ESMTP id IAA2329661 for ; Thu, 17 Jan 2002 08:32:24 +0100 (CET) mail_from (tes@snort.melbourne.sgi.com) Received: (from tes@localhost) by snort.melbourne.sgi.com (SGI-8.9.3/8.9.3) id SAA27169 for linux-xfs@oss.sgi.com; Thu, 17 Jan 2002 18:31:42 +1100 (EST) Date: Thu, 17 Jan 2002 18:31:42 +1100 (EST) From: Timothy Shimmin Message-Id: <200201170731.SAA27169@snort.melbourne.sgi.com> To: linux-xfs@oss.sgi.com Subject: TAKE - xfstests/065 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 415 Lines: 13 Date: Wed Jan 16 23:30:09 PST 2002 Workarea: snort.melbourne.sgi.com:/home/diskb/build4/tes/slinx-xfs The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: xfs-cmds:slinx:109787a cmd/xfstests/065 - 1.2 - Don't run with quotas enabled. Did some fixes to do filtering to get it to work but there is more stuff to do and it's all too much hassle and not worth it. From owner-linux-xfs@oss.sgi.com Thu Jan 17 00:35:24 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0H8ZOE03955 for linux-xfs-outgoing; Thu, 17 Jan 2002 00:35:24 -0800 Received: from mxzilla4.xs4all.nl (mxzilla4.xs4all.nl [194.109.6.48]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0H8ZKP03926 for ; Thu, 17 Jan 2002 00:35:21 -0800 Received: from xs3.xs4all.nl (knuffie@xs3.xs4all.nl [194.109.6.44]) by mxzilla4.xs4all.nl (8.12.0/8.12.0) with ESMTP id g0H7ZGsr049185; Thu, 17 Jan 2002 08:35:16 +0100 (CET) Received: from localhost (knuffie@localhost) by xs3.xs4all.nl (8.9.0/8.9.0) with ESMTP id IAA22189; Thu, 17 Jan 2002 08:35:16 +0100 (CET) Date: Thu, 17 Jan 2002 08:35:16 +0100 (CET) From: Seth Mos To: Hristo Grigorov cc: linux-xfs@oss.sgi.com Subject: Re: Developerworks XFS introduction. In-Reply-To: <20020116181033.NSND7081.fep06-app.kolumbus.fi@there> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 519 Lines: 21 On Wed, 16 Jan 2002, Hristo Grigorov wrote: > On Wednesday 16 January 2002 10:14, Seth Mos wrote: > > As linked to from http://linuxtoday.com/ > > http://linuxtoday.com/news_story.php3?ltsn=2002-01-16-003-20-PS-KN > > > > IBM developerWorks: Introducing XFS > > http://www-106.ibm.com/developerworks/library/l-fs9.html > > > > Cheers > > Seth > > > > Note that I have not read the article yet. > > Hmm, why presented by IBM and not SGI ? :) IBM was reviewing all the available journaling file systems. Cheers Seth From owner-linux-xfs@oss.sgi.com Thu Jan 17 09:27:12 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0HHRCI24422 for linux-xfs-outgoing; Thu, 17 Jan 2002 09:27:12 -0800 Received: from mail.loewe-komp.de (mail.loewe-komp.de [62.156.155.230]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0HHR7P24400 for ; Thu, 17 Jan 2002 09:27:07 -0800 Received: from loewe-komp.de (pippin [192.168.169.19]) by mail.loewe-komp.de (8.11.0/8.11.0/SuSE Linux 8.11.0-0.4) with ESMTP id g0HGRM319576; Thu, 17 Jan 2002 17:27:23 +0100 X-Authentication-Warning: mail.loewe-komp.de: Host pippin [192.168.169.19] claimed to be loewe-komp.de Message-ID: <3C46FC4C.85356D61@loewe-komp.de> Date: Thu, 17 Jan 2002 17:31:08 +0100 From: Peter =?iso-8859-1?Q?W=E4chtler?= Organization: LOEWE. Hannover X-Mailer: Mozilla 4.78 [de] (X11; U; Linux 2.4.16 i686) X-Accept-Language: de, en MIME-Version: 1.0 To: Harri Haataja CC: linux-xfs@oss.sgi.com Subject: Re: XFS/NFS server oops ..... any ideas. References: <1011128071.13534.127.camel@jen.americas.sgi.com> <200201152229.WAA440925@plum.sucs.soton.ac.uk> <20020116062656.A6524@cs.helsinki.fi> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 689 Lines: 21 Harri Haataja schrieb: > > On Tue, Jan 15, 2002 at 10:29:33PM +0000, Ian D. Hardy wrote: > > > On Tue, 2002-01-15 at 13:33, Ian D. Hardy wrote: > > > > In Irix I'd tune the kernel parameters 'min_free_pages'... to ensure that > > there was always physical memory available, is there any equivalent in > > Linux (sorry if this is a silly/obvious question). > > Documentation/sysctl/vm.txt > > On my 2.4.14 sources that seems to talk about 2.2 and the freepages file > doesn't show up in proc at all. > But that's where it used to be =) > The VM was changed with 2.4.10 In 2.4.9 there is still /proc/sys/freepages because Rik van Riels VM offers this tweak. It went away with -aa VM. From owner-linux-xfs@oss.sgi.com Thu Jan 17 09:31:44 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0HHViK24598 for linux-xfs-outgoing; Thu, 17 Jan 2002 09:31:44 -0800 Received: from zok.sgi.com (zok.sgi.com [204.94.215.101]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0HHVVP24573 for ; Thu, 17 Jan 2002 09:31:31 -0800 Received: from zeus-e8.americas.sgi.com (zeus-e8.americas.sgi.com [128.162.8.103]) by zok.sgi.com (8.11.4/8.11.4/linux-outbound_gateway-1.1) with ESMTP id g0HGVOo30005 for ; Thu, 17 Jan 2002 08:31:24 -0800 Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by zeus-e8.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id KAA38110; Thu, 17 Jan 2002 10:30:08 -0600 (CST) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id KAA92289; Thu, 17 Jan 2002 10:30:08 -0600 (CST) Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id g0HGRp315205; Thu, 17 Jan 2002 10:27:51 -0600 Subject: Re: Question: why does dbench take so much longer to run on XFSthen ext2 file system From: Steve Lord To: Philip Chiang Cc: linux-xfs@oss.sgi.com In-Reply-To: <000801c19ee4$d012ce30$1701a8c0@win2kserver.win2kdomain.com> References: <006001c19ee0$aa218170$1701a8c0@win2kserver.win2kdomain.com> <1011222311.3602.10.camel@stout.americas.sgi.com> <000801c19ee4$d012ce30$1701a8c0@win2kserver.win2kdomain.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/1.0.1 Date: 17 Jan 2002 10:27:50 -0600 Message-Id: <1011284870.13548.632.camel@jen.americas.sgi.com> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 3774 Lines: 110 I ran a test here, dbench 150 on this hardware: Main memory size: 128 Mbytes 2 GenuineIntel Pentium III (Katmai) processors 2 16550A serial ports 1 vga+ graphics device 2 IDE devices: /dev/hda: 20005650 sectors (10243 MB) w/512KiB Cache, CHS=1245/255/63, UDMA(33) /dev/hdb: ATAPI 11X CD-ROM drive, 128kB Cache, UDMA(33) PCI bus devices: Host bridge: Intel Corp. 440BX/ZX - 82443BX/ZX Host bridge (rev 3). PCI bridge: Intel Corp. 440BX/ZX - 82443BX/ZX AGP bridge (rev 3). ISA bridge: Intel Corp. 82371AB PIIX4 ISA (rev 2). IDE interface: Intel Corp. 82371AB PIIX4 IDE (rev 1). USB Controller: Intel Corp. 82371AB PIIX4 USB (rev 1). Bridge: Intel Corp. 82371AB PIIX4 ACPI (rev 2). SCSI storage controller: Adaptec 7896 (#2) (rev 0). SCSI storage controller: Adaptec 7896 (rev 0). Ethernet controller: Intel Corp. 82557 [Ethernet Pro 100] (rev 8). VGA compatible controller: ATI Technologies Inc 3D Rage Pro AGP 1X/2X (rev 92). Note 2 cpus not 1, plus I was running on a scsi partition, not ide. For completeness here is my scsi setup: SCSI subsystem driver Revision: 1.00 scsi0 : Adaptec AIC7XXX EISA/VLB/PCI SCSI HBA DRIVER, Rev 6.2.4 aic7896/97: Ultra2 Wide Channel A, SCSI Id=7, 32/253 SCBs scsi1 : Adaptec AIC7XXX EISA/VLB/PCI SCSI HBA DRIVER, Rev 6.2.4 aic7896/97: Ultra2 Wide Channel B, SCSI Id=7, 32/253 SCBs Vendor: SEAGATE Model: ST39175LW Rev: 0001 Type: Direct-Access ANSI SCSI revision: 02 scsi0:A:1:0: Tagged Queuing enabled. Depth 253 Attached scsi disk sda at scsi0, channel 0, id 1, lun 0 (scsi0:A:1): 80.000MB/s transfers (40.000MHz, offset 15, 16bit) SCSI device sda: 17783240 512-byte hdwr sectors (9105 MB) sda: sda1 sda2 sda3 sda4 < sda5 sda6 > This is not a very fast disk. No quotas or posix acl code in the kernel, using 2.4.17 from the cvs tree yesterday. I did a clean mkfs on the xfs filesystem mkfs -t xfs -f -l size=16384b /dev/sda4 mount -t xfs -o logbufs=8,osyncisdsync /dev/sda4 /xfs dbench 150 ...... Throughput 5.61891 MB/sec (NB=7.02364 MB/sec 56.1891 MBit/sec) real 58m44.971s user 3m29.210s sys 6m59.870s I then remade the same filesystem using ext2 mkfs -t ext2 /dev/sda5 mke2fs 1.19, 13-Jul-2000 for EXT2 FS 0.5b, 95/08/09 Filesystem label= OS type: Linux Block size=4096 (log=2) Fragment size=4096 (log=2) 490560 inodes, 979957 blocks 48997 blocks (5.00%) reserved for the super user First data block=0 30 block groups 32768 blocks per group, 32768 fragments per group 16352 inodes per group Superblock backups stored on blocks: 32768, 98304, 163840, 229376, 294912, 819200, 884736 Throughput 4.05627 MB/sec (NB=5.07034 MB/sec 40.5627 MBit/sec) real 81m22.488s user 3m24.930s sys 6m38.850s So a little less system time, but 22 and a half minutes more elapsed time for ext2. Possibly the dual cpu is the reason here, not immediately sure why though. Possibly different behavior between ide and scsi, but it is a very large difference. Note that osyncisdsync on the xfs mount options gives xfs the same behavior on O_SYNC I/O as ext2. aim9 numbers show a significant difference on some benchmarks with and without this mount option. My leaning is towards a problem with your build of xfs, or the parameters used. You did not by any chance turn on the debug parameters in xfs did you? Having a CONFIG_XFS_DEBUG=y in your .config options will turn xfs into a dog with 2400 ASSERTS and a lot of other checking addded to the filesystem. Steve -- Steve Lord voice: +1-651-683-3511 Principal Engineer, Filesystem Software email: lord@sgi.com From owner-linux-xfs@oss.sgi.com Thu Jan 17 10:27:15 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0HIRFG25452 for linux-xfs-outgoing; Thu, 17 Jan 2002 10:27:15 -0800 Received: from Cantor.suse.de (ns.suse.de [213.95.15.193]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0HIR6P25427 for ; Thu, 17 Jan 2002 10:27:06 -0800 Received: from Hermes.suse.de (Hermes.suse.de [213.95.15.136]) by Cantor.suse.de (Postfix) with ESMTP id 9DA2A1E736; Thu, 17 Jan 2002 18:26:58 +0100 (MET) Date: Thu, 17 Jan 2002 18:26:57 +0100 From: Andi Kleen To: Steve Lord Cc: Philip Chiang , linux-xfs@oss.sgi.com Subject: Re: Question: why does dbench take so much longer to run on XFSthen ext2 file system Message-ID: <20020117182657.A25540@wotan.suse.de> References: <006001c19ee0$aa218170$1701a8c0@win2kserver.win2kdomain.com> <1011222311.3602.10.camel@stout.americas.sgi.com> <000801c19ee4$d012ce30$1701a8c0@win2kserver.win2kdomain.com> <1011284870.13548.632.camel@jen.americas.sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1011284870.13548.632.camel@jen.americas.sgi.com> User-Agent: Mutt/1.3.22.1i Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 665 Lines: 13 On Thu, Jan 17, 2002 at 10:27:50AM -0600, Steve Lord wrote: > My leaning is towards a problem with your build of xfs, or the parameters > used. You did not by any chance turn on the debug parameters in xfs did > you? Having a CONFIG_XFS_DEBUG=y in your .config options will turn xfs into > a dog with 2400 ASSERTS and a lot of other checking addded to the filesystem. Assuming XFS is compiled in, not built as a module, just booting with profile=2, running the test and then afterwards running /usr/sbin/readprofile with the right System.map should show very quickly where the CPU is wasted. (the simple profiler unfortunately cannot deal with modules) -Andi From owner-linux-xfs@oss.sgi.com Thu Jan 17 11:52:05 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0HJq5h28118 for linux-xfs-outgoing; Thu, 17 Jan 2002 11:52:05 -0800 Received: from goliath.sylaba.poznan.pl (root@goliath.sylaba.poznan.pl [195.216.104.3]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0HJpxP28095 for ; Thu, 17 Jan 2002 11:51:59 -0800 Received: from venus.local.navi.pl (ps103.poznan.sdi.tpnet.pl [217.97.72.103]) by goliath.sylaba.poznan.pl (8.11.6/8.10.1) with ESMTP id g0HIpqR22102; Thu, 17 Jan 2002 19:51:52 +0100 (CET) Received: from venus.local.navi.pl (venus.local.navi.pl [192.168.1.10]) by venus.local.navi.pl (8.11.6/8.9.3) with ESMTP id g0HImLg03940; Thu, 17 Jan 2002 19:48:21 +0100 Date: Thu, 17 Jan 2002 19:48:21 +0100 From: Olaf =?iso-8859-2?Q?Fr=B1czyk?= To: Stephen Lord Cc: Olaf =?iso-8859-2?Q?Fr=B1czyk?= , linux-xfs@oss.sgi.com Subject: Re: problem with VMware -XFS guilty one - was: Re: XFS is innocent Message-ID: <20020117194821.A3800@venus.local.navi.pl> References: <20020110183051.A1483@venus.local.navi.pl> <1010688121.676.111.camel@jen.americas.sgi.com> <20020115132520.C1593@venus.local.navi.pl> <3C44255B.8090008@sgi.com> Mime-Version: 1.0 Content-Type: text/plain; format=flowed; charset=ISO-8859-2 Content-Transfer-Encoding: 8bit In-Reply-To: <3C44255B.8090008@sgi.com>; from lord@sgi.com on Tue, Jan 15, 2002 at 13:49:31 +0100 X-Mailer: Balsa 1.2.3 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 926 Lines: 31 On 2002.01.15 13:49:31 +0100 Stephen Lord wrote: > > Please try this with the current cvs tree - there was a change in the > last week which fixed > some problems with mmapped I/O under heavy memory pressure (the emacs > build problem > mentioned on the list). Hi, It started to looks ugly :( Still problem, but ... I have 2 SCSI drives, and 1 IDE. The system is on sda and sdb drives, hda is for storage of unfrequently needed things. So, my /tmp is on /sdb3. And, as I said, xfs on sdb3 + vmware = vmware crash ext2 on sdb3 + vmware = OK but I tried to put it on another partition, the only free I have is sda4, and: both xfs and ext2 on sda4 + vmware = OK. So I supposed, there is some problem with the drive, so I ran badblocks -v -w, but it didn't found any errors. And the only thing which crashes is vmware, all other stuff works perfectly. So I think, that drive is OK. Anyone has any ideas? Regards, Olaf From owner-linux-xfs@oss.sgi.com Thu Jan 17 11:58:54 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0HJwsa28453 for linux-xfs-outgoing; Thu, 17 Jan 2002 11:58:54 -0800 Received: from UberGeek.coremetrics.com ([209.184.141.163]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0HJwaP28425 for ; Thu, 17 Jan 2002 11:58:36 -0800 Received: (from austin@localhost) by UberGeek.coremetrics.com (8.11.6/8.11.6) id g0HIvC726714; Thu, 17 Jan 2002 12:57:12 -0600 X-Authentication-Warning: UberGeek.coremetrics.com: austin set sender to austin@coremetrics.com using -f Subject: Re: problem with VMware -XFS guilty one - was: Re: XFS is innocen t From: Austin Gonyou To: Olaf =?iso-8859-2?Q?Fr=B1czyk?= Cc: Stephen Lord , linux-xfs@oss.sgi.com In-Reply-To: <20020117194821.A3800@venus.local.navi.pl> References: <20020117194821.A3800@venus.local.navi.pl> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-+e5rSfV6JN6po7bq07eB" X-Mailer: Evolution/1.0.1 Date: 17 Jan 2002 12:57:12 -0600 Message-Id: <1011293832.26356.13.camel@UberGeek> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 2009 Lines: 70 --=-+e5rSfV6JN6po7bq07eB Content-Type: text/plain; charset=iso-8859-2 Content-Transfer-Encoding: quoted-printable Go the drive maker's web site and see if they have a diagnostic utility you boot from a floppy(will probably be dos based, so be prepared), and run that. That is the ONLY way to tell if it's truly bad or not. On Thu, 2002-01-17 at 12:48, Olaf Fr=B1czyk wrote: > On 2002.01.15 13:49:31 +0100 Stephen Lord wrote: > >=20 > > Please try this with the current cvs tree - there was a change in the= =20 > > last week which fixed > > some problems with mmapped I/O under heavy memory pressure (the emacs= =20 > > build problem > > mentioned on the list). > Hi, > It started to looks ugly :( > Still problem, but ... > I have 2 SCSI drives, and 1 IDE. > The system is on sda and sdb drives, hda is for storage of unfrequently= =20 > needed things. > So, my /tmp is on /sdb3. > And, as I said, > xfs on sdb3 + vmware =3D vmware crash > ext2 on sdb3 + vmware =3D OK > but I tried to put it on another partition, the only free I have is > sda4,=20 > and: > both xfs and ext2 on sda4 + vmware =3D OK. > So I supposed, there is some problem with the drive, so I ran badblocks > -v=20 > -w, but it didn't found any errors. > And the only thing which crashes is vmware, all other stuff works=20 > perfectly. > So I think, that drive is OK. >=20 > Anyone has any ideas? >=20 > Regards, >=20 > Olaf=20 --=20 Austin Gonyou Systems Architect, CCNA Coremetrics, Inc. Phone: 512-698-7250 email: austin@coremetrics.com "It is the part of a good shepherd to shear his flock, not to skin it." Latin Proverb --=-+e5rSfV6JN6po7bq07eB Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQA8Rx6H94g6ZVmFMoIRAqFEAJ0VtX8PI4Zi2Du4HjHTfOb+cl0PRwCdHOh3 d6HMc/6FnZDstUkG+WuGN3A= =tz3z -----END PGP SIGNATURE----- --=-+e5rSfV6JN6po7bq07eB-- From owner-linux-xfs@oss.sgi.com Thu Jan 17 12:06:54 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0HK6s428742 for linux-xfs-outgoing; Thu, 17 Jan 2002 12:06:54 -0800 Received: from maple.sucs.soton.ac.uk (maple.sucs.soton.ac.uk [152.78.128.16]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0HK6QP28718 for ; Thu, 17 Jan 2002 12:06:27 -0800 Received: from whitebeam.sucs.soton.ac.uk (whitebeam.sucs.soton.ac.uk [152.78.128.4]) by maple.sucs.soton.ac.uk (8.10.0/8.10.0) with ESMTP id g0HJ6NH29442; Thu, 17 Jan 2002 19:06:23 GMT Received: (from nobody@localhost) by whitebeam.sucs.soton.ac.uk (8.10.0/8.10.0) id g0HJB3r12277; Thu, 17 Jan 2002 19:11:03 GMT To: Steve Lord Subject: Re: XFS/NFS server oops ..... any ideas. Message-ID: <1011294663.3c4721c77b818@webmail.soton.ac.uk> Date: Thu, 17 Jan 2002 19:11:03 +0000 (GMT) From: Ian Hardy Cc: "Ian D. Hardy" , linux-xfs@oss.sgi.com References: <200201152229.WAA440925@plum.sucs.soton.ac.uk> <3C45E220.B8CE3257@soton.ac.uk> <1011213187.13548.368.camel@jen.americas.sgi.com> In-Reply-To: <1011213187.13548.368.camel@jen.americas.sgi.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit User-Agent: IMP/PHP IMAP webmail program 2.2.4 X-Originating-IP: 172.188.180.151 X-MailScanner: Believed to be clean Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 9218 Lines: 244 FYI: I downloaded the cvs tree last night and installed it on a test server, now been running for ~ 20hrs with a heavy load (back-to-back tar's and bonnie) from between 8 and 30 NFS clients. So far looks OK but its a bit early to tell yet. Interestingly this kernel/xfs seems to be maintaining between ~7 and 10Mbytes of free memory (ie, 2 to 4 times the amount that my previous kernel was maintaining). Will update when/if I get a failure or when I've upgraded the production server. Thanks Ian Quoting Steve Lord : > Please try the current cvs tree, the 2.4.17 split patches may be close > enough, anything prior to that has problems with a memory leak under > pressure. Lets then take a closer look at the oops output from that. > > Steve > > > On Wed, 2002-01-16 at 14:27, Ian D. Hardy wrote: > > Hi, > > > > I've been looking at this further today. > > > > If Steve Lord is correct in his assessment that my Oops was due to a > 'out of > > memory condition' (I'm sure he is, looks sensible) and I've > correctly > > interpreted memory usage (via 'vmstat') then it would appear that > the > > kernel is running out of available memory, with resultant problems > for > > XFS because all of the memory is been used, most of it to cache > filesystem > > data. Currently 'top' is showing: > > > > 7:03pm up 7:19, 2 users, load average: 0.00, 0.00, 0.00 > > 108 processes: 107 sleeping, 1 running, 0 zombie, 0 stopped > > CPU states: 0.1% user, 0.5% system, 0.0% nice, 99.2% idle > > Mem: 898848K av, 895792K used, 3056K free, 0K shrd, > 13392K buff > > Swap: 1028120K av, 4780K used, 1023340K free > 820396K cached > > > > Confirming that the majority of the memory is been used for cache and > that > > there is currently just under 3Mbytes of RAM free, so I can see how a > sudden > > kernel demand for memory may result in a failure before 'kswapd' has > chance > > to free some memory up. > > > > Isn't this a common problem? wouldn't this be the normal state for > > a fileserver with more 'active' data than memory - filesystem cache > will > > (under Linux) grow to use as much memory as possible, hence 'free' > memory > > will be at a minimum? From this reasoning adding more memory is > unlikely > > to help - as the system will just use more cache until there is the > same > > minimum amount of memory? > > > > It would appear that XFS has the potential to make heavier demands > > on kernel memory and/or does not check that memory was allocated (I > > assume that its memory allocation calls are such that it expects > memory > > to be allocated from immediately available physical memory?), hence > > this problem (I believe a number of people have reported problems > that > > have been attributed to memory allocation errors?). > > > > ..... have I missed something? > > > > I then looked to try to find out how to decrease the maximum amount > of > > memory that the kernel would use as FS cache (or increase the > minimum > > amount of memory that the kernel would try to keep free). Thanks to > > harri.haataja@cs.Helsinki.FI for pointing me in the direction of > > 'Documentation/sysctl/vm.txt' in the kernel. Though as was noted > this > > document is out of date referring to the 2.2 series kernels. It does > > however point to '/proc/sys/vm/feepages' as giving the number of > pages > > at which 'kswapd' will start to free pages. This seems to exist in > the > > 2.4 series kernels upto 2.4.9 (it may be 10 or 11?) after that the > VM > > changed and this parameter went away (though the documentation hasn't > > > changed...... So I'm completely lost with the later kernels!). > Anyway > > back to 2.4.9: > > > > # cat /proc/sys/vm/freepages > > 383 766 1149 > > > > Which means that the kernel will try to maintain 1149 pages > (~4.5Mbytes) > > free memory, will try even harder to free memory at 766 pages and > will > > stop allocating memory other than to root if free memory falls below > > 383 pages (~1.5Mbytes). This would seem to agree with 'vmstat'/'top' > > which tend to show ~3Mbytes free memory. I then tried to increase > > these values, however these appear to be read only values (tried by > > writing directly to the file and using 'sysctl'. Indeed a comment > > in the kernel file 'mm/page_alloc.c' confirms that the 'freepages' > > array is not writable due to potential conflicts with different > memory > > zones. So I'm stuck again. I've not been able to find any obvious > > place in the kernel source to change these values at kernel > compilation > > time either. > > > > Any ideas? (either for 2.4.9 or ideally in latter/current > > kernels, I have reproduced what looked like a similar failure with > > 2.4.16 and 2.4.17 but unfortunately did not get the Oops details to > > confirm that it was the same problem, I'll try to setup a test to > > get this info, is there any more info that would help). FYI: test > > environment is a server and a number (~6) client machines running > > a mixture of 'bonnie' runs and back-to-back tar's copying the local > > /usr to the shared filesystem from the server (last time I looked > > at this it lasted ~ 24hours). > > > > Many thanks for your time. > > > > Ian > > > > > > > > "Ian D. Hardy" wrote: > > > > > > > > > > > On Tue, 2002-01-15 at 13:33, Ian D. Hardy wrote: > > > > > Hi, > > > > > > > > > > For some time we've been having problem with a server, which is > acting > > > > > as a master/control node and NFS server for a computational > cluster > > > > > (~180 client nodes). The server will crash after anywhere > between > > > > > a few hours and 10 days operation. We've tried various kernels > and > > > > > XFS patch versions from 2.4.9 kernel with XFS > patch-2.4.9-xfs-2001-08-17 > > > > > up to and including 2.4.16 kernel with the xfs-2.4.16-all-i386 > patch, > > > > > if anything the 2.4.9 kernel has proved the most reliable (it > normally > > > > > lasts between 4 and 10 days! - 2.4.16 lasted less than 24hrs). > > > .... more details deleted > > > > > > > > > > > > > Almost certainly this is an out of memory condition, just from > looking > > > > at the code in the function you oopsed in. Would you say your > system is > > > > stressed when it comes to memory? > > > > > > > > Steve > > > > > > > > Steve Lord voice: > +1-651-683-3511 > > > > Principal Engineer, Filesystem Software email: > lord@sgi.com > > > > > > > > > > I'd not regard the server as short of memory as its using ~660Mbytes > as > > > file system cache, though interestingly it does appear to be using > some > > > swap space. Is it possible that XFS is having problems when there is > not > > > memory immediately available, I've included some 'vmstat' output: > > > > > > vmstat 10 10 > > > procs memory swap io system > cpu > > > r b w swpd free buff cache si so bi bo in cs > us sy id > > > 0 1 28 11116 3784 42300 674656 0 0 37 35 19 3 > 0 2 23 > > > 0 1 28 11116 3480 42300 674960 0 0 0 0 167 194 > 0 0 100 > > > 0 1 28 11116 3176 42300 675264 0 0 0 0 139 107 > 0 0 100 > > > 0 1 28 11116 3056 42300 675380 0 0 0 2 152 142 > 0 0 100 > > > > > > In Irix I'd tune the kernel parameters 'min_free_pages'... to ensure > that > > > there was always physical memory available, is there any equivalent > in > > > Linux (sorry if this is a silly/obvious question). > > > > > > Many thanks. > > > > > > Ian > > > > > > -- > > > > > > > //////////////////////////////////////////////////////////////////////////// > > > Ian Hardy Tel: 023 80593577 > > > Research Services Fax: 023 80593131 > > > Computing Services email: idh@soton.ac.uk > > > Southampton University > i.d.hardy@soton.ac.uk > > > Southampton S017 1BJ, UK. > > > > \\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\ > > > > -- > > > > /////////////Technical Coordination, Research > Services//////////////////// > > Ian Hardy Tel: 023 80 593577 > > Computing Services Mobile: 0709 2127503 > > Southampton University email: idh@soton.ac.uk > > Southampton S017 1BJ, UK. > i.d.hardy@soton.ac.uk > > \\'BUGS: The notion of errors is ill-defined' (IRIX man page for > netstat)\ > -- > > Steve Lord voice: +1-651-683-3511 > Principal Engineer, Filesystem Software email: lord@sgi.com > /////////////Technical Coordination, Research Services//////////////////// Ian Hardy Tel: 023 80 593577 Computing Services Mobile: 0709 2127503 Southampton University email: idh@soton.ac.uk Southampton S017 1BJ, UK. i.d.hardy@soton.ac.uk \\'BUGS: The notion of errors is ill-defined' (IRIX man page for netstat)\ From owner-linux-xfs@oss.sgi.com Thu Jan 17 12:08:51 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0HK8pT28934 for linux-xfs-outgoing; Thu, 17 Jan 2002 12:08:51 -0800 Received: from fruit.eu.org (qmailr@34dyn8.com21.casema.net [212.64.15.8]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0HK8lP28912 for ; Thu, 17 Jan 2002 12:08:47 -0800 Received: (qmail 25777 invoked by uid 500); 17 Jan 2002 19:08:44 -0000 Date: Thu, 17 Jan 2002 20:08:44 +0100 From: Wessel Dankers To: linux-xfs@oss.sgi.com Subject: Large file I/O error Message-ID: <20020117200844.A25522@fruit.eu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i X-oi: oi Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 983 Lines: 26 oi! I think tripped over a nice, juicy bug here. I used ftruncate64() to create a sparse file of 2^63 bytes. Then I run mkfs.xfs on it (without any options). The filesystem on which the large file resides goes belly-up and refuses to perform any operation at all, returning EIO on even an ls. I can umount it (although running a sync hangs for a while) but xfs_check fails because the superblock is overwritten (!). After xfs_repair, mount, xfs_repair -L, everything is OK again and I don't seem to have lost any files (I didn't look very closely though, it was just my /tmp). This is in dmesg: xfs_force_shutdown(ide0(3,6),0x8) called from line 1020 of file xfs_trans.c. Return address = 0xc01bdfc7 Corruption of in-memory data detected. Shutting down filesystem: ide0(3,6) Please umount the filesystem, and rectify the problem(s) I hope it's not a known bug, I'd hate to waste your time. Regards, -- Wessel Dankers Telecommunications is downshifting. From owner-linux-xfs@oss.sgi.com Thu Jan 17 12:09:55 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0HK9tl29082 for linux-xfs-outgoing; Thu, 17 Jan 2002 12:09:55 -0800 Received: from fruit.eu.org (qmailr@34dyn8.com21.casema.net [212.64.15.8]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0HK9qP29059 for ; Thu, 17 Jan 2002 12:09:53 -0800 Received: (qmail 25792 invoked by uid 500); 17 Jan 2002 19:09:49 -0000 Date: Thu, 17 Jan 2002 20:09:49 +0100 From: Wessel Dankers To: linux-xfs@oss.sgi.com Subject: Re: Large file I/O error Message-ID: <20020117200949.B25522@fruit.eu.org> References: <20020117200844.A25522@fruit.eu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20020117200844.A25522@fruit.eu.org>; from wsl@fruit.eu.org on Thu, Jan 17, 2002 at 08:08:44PM +0100 X-oi: oi Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 250 Lines: 14 On 2002-01-17 20:08:44+0100, Wessel Dankers wrote: > oi! > > I think tripped over a nice, juicy bug here. I forgot to mention: Linux bzzrt 2.4.17-xfs #1 Fri Jan 11 16:48:32 CET 2002 i686 unknown -- Wessel Dankers Budget cuts From owner-linux-xfs@oss.sgi.com Thu Jan 17 12:17:00 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0HKH0g29361 for linux-xfs-outgoing; Thu, 17 Jan 2002 12:17:00 -0800 Received: from yog-sothoth.sgi.com (eugate.sgi.com [192.48.160.10]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0HKGsP29339 for ; Thu, 17 Jan 2002 12:16:55 -0800 Received: from zeus-e8.americas.sgi.com (zeus-e8.americas.sgi.com [128.162.8.103]) by yog-sothoth.sgi.com (980305.SGI.8.8.8-aspam-6.2/980304.SGI-aspam-europe) via ESMTP id UAA30395 for ; Thu, 17 Jan 2002 20:15:54 +0100 (CET) mail_from (lord@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by zeus-e8.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id NAA40489; Thu, 17 Jan 2002 13:15:23 -0600 (CST) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id NAA07846; Thu, 17 Jan 2002 13:15:23 -0600 (CST) Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id g0HJD5416252; Thu, 17 Jan 2002 13:13:05 -0600 Subject: Re: Large file I/O error From: Steve Lord To: Wessel Dankers Cc: linux-xfs@oss.sgi.com In-Reply-To: <20020117200844.A25522@fruit.eu.org> References: <20020117200844.A25522@fruit.eu.org> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/1.0.1 Date: 17 Jan 2002 13:13:04 -0600 Message-Id: <1011294784.13534.695.camel@jen.americas.sgi.com> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 1453 Lines: 39 On Thu, 2002-01-17 at 13:08, Wessel Dankers wrote: > oi! > > I think tripped over a nice, juicy bug here. I used ftruncate64() to create > a sparse file of 2^63 bytes. Then I run mkfs.xfs on it (without any options). > > The filesystem on which the large file resides goes belly-up and refuses > to perform any operation at all, returning EIO on even an ls. > > I can umount it (although running a sync hangs for a while) but xfs_check > fails because the superblock is overwritten (!). After xfs_repair, mount, > xfs_repair -L, everything is OK again and I don't seem to have lost any > files (I didn't look very closely though, it was just my /tmp). This is > in dmesg: > > xfs_force_shutdown(ide0(3,6),0x8) called from line 1020 of file xfs_trans.c. Return address = 0xc01bdfc7 > Corruption of in-memory data detected. Shutting down filesystem: ide0(3,6) Please umount the filesystem, and rectify the problem(s) > > I hope it's not a known bug, I'd hate to waste your time. Someone else just pointed out that forced shutdown is overwriting the super block - which is not good. There appear to be a bunch of dirty buffers with a zero disk address in them left behind. It is being worked on. Steve > > Regards, > > -- > Wessel Dankers > > Telecommunications is downshifting. -- Steve Lord voice: +1-651-683-3511 Principal Engineer, Filesystem Software email: lord@sgi.com From owner-linux-xfs@oss.sgi.com Thu Jan 17 12:31:53 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0HKVrw29763 for linux-xfs-outgoing; Thu, 17 Jan 2002 12:31:53 -0800 Received: from fruit.eu.org (qmailr@34dyn8.com21.casema.net [212.64.15.8]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0HKVnP29740 for ; Thu, 17 Jan 2002 12:31:49 -0800 Received: (qmail 25929 invoked by uid 500); 17 Jan 2002 19:31:46 -0000 Date: Thu, 17 Jan 2002 20:31:46 +0100 From: Wessel Dankers To: linux-xfs@oss.sgi.com Subject: Re: Large file I/O error Message-ID: <20020117203146.C25522@fruit.eu.org> Mail-Followup-To: linux-xfs@oss.sgi.com References: <20020117200844.A25522@fruit.eu.org> <1011294784.13534.695.camel@jen.americas.sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <1011294784.13534.695.camel@jen.americas.sgi.com>; from lord@sgi.com on Thu, Jan 17, 2002 at 01:13:04PM -0600 X-oi: oi Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 434 Lines: 15 On 2002-01-17 13:13:04-0600, Steve Lord wrote: > Someone else just pointed out that forced shutdown is overwriting the > super block - which is not good. There appear to be a bunch of dirty > buffers with a zero disk address in them left behind. It is being > worked on. Ok, great! Any idea what's causing the forced shutdown in the first place, though? -- Wessel Dankers Borg nanites have infested the server From owner-linux-xfs@oss.sgi.com Thu Jan 17 12:39:02 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0HKd2x30016 for linux-xfs-outgoing; Thu, 17 Jan 2002 12:39:02 -0800 Received: from rj.sgi.com (rj.SGI.COM [204.94.215.100]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0HKcsP29976 for ; Thu, 17 Jan 2002 12:38:55 -0800 Received: from zeus-e8.americas.sgi.com (zeus-e8.americas.sgi.com [128.162.8.103]) by rj.sgi.com (8.11.4/8.11.4/linux-outbound_gateway-1.1) with ESMTP id g0HJckY20440 for ; Thu, 17 Jan 2002 11:38:46 -0800 Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by zeus-e8.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id NAA40233; Thu, 17 Jan 2002 13:37:29 -0600 (CST) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id NAA12358; Thu, 17 Jan 2002 13:37:29 -0600 (CST) Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id g0HJZBm16267; Thu, 17 Jan 2002 13:35:11 -0600 Subject: Re: Large file I/O error From: Steve Lord To: Wessel Dankers Cc: linux-xfs@oss.sgi.com In-Reply-To: <20020117203146.C25522@fruit.eu.org> References: <20020117200844.A25522@fruit.eu.org> <1011294784.13534.695.camel@jen.americas.sgi.com> <20020117203146.C25522@fruit.eu.org> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/1.0.1 Date: 17 Jan 2002 13:35:10 -0600 Message-Id: <1011296110.13545.725.camel@jen.americas.sgi.com> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 946 Lines: 29 On Thu, 2002-01-17 at 13:31, Wessel Dankers wrote: > On 2002-01-17 13:13:04-0600, Steve Lord wrote: > > Someone else just pointed out that forced shutdown is overwriting the > > super block - which is not good. There appear to be a bunch of dirty > > buffers with a zero disk address in them left behind. It is being > > worked on. > > Ok, great! > > Any idea what's causing the forced shutdown in the first place, though? Buffered I/O beyond 2^44 bytes into the sparse file probably. There is a hole in the code here. The linux VM uses a 32 bit page number index to index cache data. So 2^32 * 4096 is as bit as you can go. XFS is letting file offsets bigger than this in and not handling the results. Steve > > -- > Wessel Dankers > > Borg nanites have infested the server -- Steve Lord voice: +1-651-683-3511 Principal Engineer, Filesystem Software email: lord@sgi.com From owner-linux-xfs@oss.sgi.com Thu Jan 17 12:43:45 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0HKhj230208 for linux-xfs-outgoing; Thu, 17 Jan 2002 12:43:45 -0800 Received: from pneumatic-tube.sgi.com (pneumatic-tube.sgi.com [204.94.214.22]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0HKhgP30184 for ; Thu, 17 Jan 2002 12:43:42 -0800 Received: from relay1.corp.sgi.com (spindle.corp.sgi.com [198.29.75.13]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id LAA07073 for ; Thu, 17 Jan 2002 11:44:28 -0800 (PST) mail_from (florin@sgi.com) Received: from stantz.corp.sgi.com (stantz.corp.sgi.com [130.62.4.42]) by relay1.corp.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) via ESMTP id LAA09438 for ; Thu, 17 Jan 2002 11:43:09 -0800 (PST) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by stantz.corp.sgi.com (Postfix) with ESMTP id 1A2FA13650B for ; Thu, 17 Jan 2002 11:43:09 -0800 (PST) Subject: Re: Developerworks XFS introduction. From: Florin Andrei To: Linux XFS Mailing List In-Reply-To: References: Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/1.0.1 Date: 17 Jan 2002 11:43:09 -0800 Message-Id: <1011296589.14331.82.camel@stantz.corp.sgi.com> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 772 Lines: 21 On Wed, 2002-01-16 at 04:20, Federico Sevilla III wrote: > > (I'm not Steve Lord but ...) I just read the article and everything seems > to be in order. Nothing quite new (since I've been using XFS for awhile). > However I really like how the NULL issue was explained. I never really > looked at it that way (always saw it as a ... problem). And that bit Yeah, Daniel Robbins rockzz! :o) > quoting Steve Lord on a "coming soon" patch to improve delete performance > was exciting. :) Indeed, that would be a big thing. Very, very nice. -- Florin Andrei "The same thing could happen to the computer as what happened to the TV, hardly any interesting programs left and programs designed to make the viewers sit through the commercials more willingly." - Rik van Riel From owner-linux-xfs@oss.sgi.com Thu Jan 17 13:09:46 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0HL9k231746 for linux-xfs-outgoing; Thu, 17 Jan 2002 13:09:46 -0800 Received: from tux.rsn.bth.se (tux.rsn.bth.se [194.47.143.135]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0HL9eP31724 for ; Thu, 17 Jan 2002 13:09:41 -0800 Received: from localhost (gandalf@localhost [127.0.0.1]) by tux.rsn.bth.se (8.12.1/8.12.1/Debian -5) with ESMTP id g0HK90lx026649; Thu, 17 Jan 2002 21:09:00 +0100 Date: Thu, 17 Jan 2002 21:09:00 +0100 (CET) From: Martin Josefsson X-Sender: gandalf@tux.rsn.bth.se To: Steve Lord cc: Wessel Dankers , linux-xfs@oss.sgi.com Subject: Re: Large file I/O error In-Reply-To: <1011294784.13534.695.camel@jen.americas.sgi.com> Message-ID: X-message-flag: Get yourself a real mail client! http://www.washington.edu/pine/ MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 963 Lines: 22 On 17 Jan 2002, Steve Lord wrote: > Someone else just pointed out that forced shutdown is overwriting the > super block - which is not good. There appear to be a bunch of dirty > buffers with a zero disk address in them left behind. It is being > worked on. Just have to say that I can confirm this, I had to run xfs_repair after a forced shutdown because of major interruptproblems in the machine so the promise ata-driver complained about irq timeouts all the time... The superblock was overwritten. xfs_repair also complained about other files which were ok before the forced shutdown, and after the shutdown and running xfs_repair they became corrupt. I don't know if this is an possible XFS problem or something caused by the interrupt problems. Those files were written some time before and were possible read from when the forced shutdown occured. /Martin Never argue with an idiot. They drag you down to their level, then beat you with experience. From owner-linux-xfs@oss.sgi.com Thu Jan 17 13:16:48 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0HLGmX31985 for linux-xfs-outgoing; Thu, 17 Jan 2002 13:16:48 -0800 Received: from pneumatic-tube.sgi.com (pneumatic-tube.sgi.com [204.94.214.22]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0HLGiP31963 for ; Thu, 17 Jan 2002 13:16:44 -0800 Received: from zeus-e8.americas.sgi.com (zeus-e8.americas.sgi.com [128.162.8.103]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id MAA08826 for ; Thu, 17 Jan 2002 12:17:30 -0800 (PST) mail_from (sandeen@sgi.com) Received: from poppy-e185.americas.sgi.com (poppy-e185.americas.sgi.com [128.162.185.207]) by zeus-e8.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id OAA41403; Thu, 17 Jan 2002 14:15:25 -0600 (CST) Received: from stout.americas.sgi.com (stout.americas.sgi.com [128.162.187.5]) by poppy-e185.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.7) with ESMTP id OAA56722; Thu, 17 Jan 2002 14:15:25 -0600 (CST) Subject: Re: Large file I/O error From: Eric Sandeen To: Martin Josefsson Cc: Steve Lord , Wessel Dankers , linux-xfs@oss.sgi.com In-Reply-To: References: Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/1.0 (Preview Release) Date: 17 Jan 2002 14:15:24 -0600 Message-Id: <1011298525.4041.2.camel@stout.americas.sgi.com> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 885 Lines: 21 On Thu, 2002-01-17 at 14:09, Martin Josefsson wrote: > xfs_repair also complained about other files which were ok before the > forced shutdown, and after the shutdown and running xfs_repair they became > corrupt. I don't know if this is an possible XFS problem or something > caused by the interrupt problems. Those files were written some time > before and were possible read from when the forced shutdown occured. The problem we have found would probably only affect the superblock. Delalloc buffer heads have bh->b_blocknr==0, (since no disk block has yet been assigned) but we were incorrectly clearing the delay flag at one point after the filesystem shutdown, and so all delalloc buffers were lining up to clobber block zero... I'll check in a fix for this shortly. -Eric -- Eric Sandeen XFS for Linux http://oss.sgi.com/projects/xfs sandeen@sgi.com SGI, Inc. From owner-linux-xfs@oss.sgi.com Thu Jan 17 13:35:29 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0HLZT532298 for linux-xfs-outgoing; Thu, 17 Jan 2002 13:35:29 -0800 Received: from fruit.eu.org (qmailr@34dyn8.com21.casema.net [212.64.15.8]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0HLZOP32276 for ; Thu, 17 Jan 2002 13:35:24 -0800 Received: (qmail 26194 invoked by uid 500); 17 Jan 2002 20:35:21 -0000 Date: Thu, 17 Jan 2002 21:35:03 +0100 From: Wessel Dankers To: Steve Lord Subject: Re: Large file I/O error Message-ID: <20020117213503.D25522@fruit.eu.org> References: <20020117200844.A25522@fruit.eu.org> <1011294784.13534.695.camel@jen.americas.sgi.com> <20020117203146.C25522@fruit.eu.org> <1011296110.13545.725.camel@jen.americas.sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <1011296110.13545.725.camel@jen.americas.sgi.com>; from lord@sgi.com on Thu, Jan 17, 2002 at 01:35:10PM -0600 X-oi: oi Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 1122 Lines: 31 On 2002-01-17 13:35:10-0600, Steve Lord wrote: > On Thu, 2002-01-17 at 13:31, Wessel Dankers wrote: > > On 2002-01-17 13:13:04-0600, Steve Lord wrote: > > > Someone else just pointed out that forced shutdown is overwriting the > > > super block - which is not good. There appear to be a bunch of dirty > > > buffers with a zero disk address in them left behind. It is being > > > worked on. > > > > Ok, great! > > > > Any idea what's causing the forced shutdown in the first place, though? > > Buffered I/O beyond 2^44 bytes into the sparse file probably. There is > a hole in the code here. The linux VM uses a 32 bit page number > index to index cache data. So 2^32 * 4096 is as bit as you can go. > XFS is letting file offsets bigger than this in and not handling the > results. Ack. If I create the file to be exactly 2^44 bytes the problem goes away. (mkfs fails though, ENOSPC ;) The downside is that any user can cause a forced shutdown which is a bit worrisome from a security perspective. =( Kind regards, -- Wessel Dankers We had to turn off that service to comply with the CDA Bill. From owner-linux-xfs@oss.sgi.com Thu Jan 17 14:55:01 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0HMt1I01312 for linux-xfs-outgoing; Thu, 17 Jan 2002 14:55:01 -0800 Received: from deliverator.sgi.com (deliverator.sgi.com [204.94.214.10]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0HMsvP01280 for ; Thu, 17 Jan 2002 14:54:57 -0800 Received: from zeus-e8.americas.sgi.com (zeus-e8.americas.sgi.com [128.162.8.103]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id NAA22222 for ; Thu, 17 Jan 2002 13:50:32 -0800 (PST) mail_from (eric@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by zeus-e8.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id PAA42940 for ; Thu, 17 Jan 2002 15:53:36 -0600 (CST) Received: from stout.americas.sgi.com (stout.americas.sgi.com [128.162.187.5]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id PAA92115 for ; Thu, 17 Jan 2002 15:53:36 -0600 (CST) Received: by stout.americas.sgi.com (8.11.6/SGI-client-1.7) id g0HLraV06109; Thu, 17 Jan 2002 15:53:36 -0600 Message-Id: <200201172153.g0HLraV06109@stout.americas.sgi.com> Date: Thu, 17 Jan 2002 15:53:36 -0600 From: Eric Sandeen Subject: TAKE - Fix forced shutdown problems Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 1034 Lines: 27 As _xfs_force_shutdown was written, it tried to schedule in an interrupt context and caused a BUG() to be thrown. Also, even if we didn't try to deal with leftover buffers in the interrupt, they subsequently had their delalloc flags removed, and thus queued up to clobber block 0 (1,2,3) on the disk, thus corrupting the filesystem. So, remove the in-interrupt activity, and if we later get a dellalloc buffer that bmap can't find a home for, just throw it away. Date: Thu Jan 17 13:43:10 PST 2002 Workarea: stout.americas.sgi.com:/localhome/eric/2.4.x-xfs/workarea-reallyclean The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:109821a linux/fs/xfs/xfs_rw.c - 1.349 - Don't try to clear out remaining delwri buffers in _xfs_force_shutdown, we are in an interrupt context and can't sleep, just let the buffers get caught as they try to get on-disk. linux/fs/xfs/pagebuf/page_buf_io.c - 1.3 - Don't just clear delay flag on bmap failure, wipe out the buffer From owner-linux-xfs@oss.sgi.com Thu Jan 17 14:59:01 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0HMx1601576 for linux-xfs-outgoing; Thu, 17 Jan 2002 14:59:01 -0800 Received: from local.iboats.com ([204.246.129.200]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0HMwuP01554 for ; Thu, 17 Jan 2002 14:58:56 -0800 Received: (qmail 1230 invoked by uid 82); 17 Jan 2002 21:58:18 -0000 Received: from nw@codon.com by local with qmail-scanner-0.96 (. Clean. Processed in 0.431299 secs); 17 Jan 2002 21:58:18 -0000 Received: from weasel.local.iboats.com (HELO weasel) (204.246.129.210) by 204.246.129.200 with SMTP; 17 Jan 2002 21:58:17 -0000 Message-ID: <004c01c19fa2$af0f0500$d281f6cc@iboats.com> From: "Steve Wolfe" To: Subject: XFSdump / shell scripting Date: Thu, 17 Jan 2002 15:02:36 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 932 Lines: 37 OK, I'm lost, and obviously clueless. As part of a backup script that I'm writing to replace our current backup solution, I'm doing this: DEVICE=/dev/st0 NR_DEVICE=/dev/nst0 DUMP=/sbin/dump XFSDUMP=/usr/sbin/xfsdump (snip) then CMD="$XFSDUMP -m -o -l 0 -F -f $NR_DEVICE $FS" [ $DEBUG !=0 ] && echo "$$: Executing \"$CMD\"..." `$CMD` fi Alrighty, then. Whenever it runs from a cron job, I get: ------ 10488: Executing "/usr/sbin/xfsdump -m -o -l 0 -F -f /dev/nst0 /home"... /root/sys_backup.sh: /usr/sbin/xfsdump:: No such file or directory ------ What? Yes, /usr/sbin/xfsdump exists: ---- # ls -al /usr/sbin/xfsdump -rwxr-xr-x 1 root root 939348 Oct 18 15:29 /usr/sbin/xfsdump ---- But... if I simply cut and past the line into a shell,"/usr/sbin/xfsdump -m -o -l 0 -F -f /dev/nst0 /home", it works just fine and dandy. What, exactly, could I be doing wrong? steve From owner-linux-xfs@oss.sgi.com Thu Jan 17 15:06:48 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0HN6mr02008 for linux-xfs-outgoing; Thu, 17 Jan 2002 15:06:48 -0800 Received: from burgers.bubbanfriends.org (IDENT:postfix@burgers.bubbanfriends.org [216.140.122.113]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0HN6eP01986 for ; Thu, 17 Jan 2002 15:06:40 -0800 Received: by burgers.bubbanfriends.org (Postfix, from userid 500) id 9B61A835FEA; Thu, 17 Jan 2002 17:06:43 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by burgers.bubbanfriends.org (Postfix) with ESMTP id 95025280045D; Thu, 17 Jan 2002 17:06:43 -0500 (EST) Date: Thu, 17 Jan 2002 17:06:43 -0500 (EST) From: Mike Burger To: Steve Wolfe Cc: Subject: Re: XFSdump / shell scripting In-Reply-To: <004c01c19fa2$af0f0500$d281f6cc@iboats.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 1087 Lines: 43 On my system, xfsdump is in /sbin. On Thu, 17 Jan 2002, Steve Wolfe wrote: > > OK, I'm lost, and obviously clueless. As part of a backup script that > I'm writing to replace our current backup solution, I'm doing this: > > DEVICE=/dev/st0 > NR_DEVICE=/dev/nst0 > DUMP=/sbin/dump > XFSDUMP=/usr/sbin/xfsdump > > (snip) > > then > CMD="$XFSDUMP -m -o -l 0 -F -f $NR_DEVICE $FS" > [ $DEBUG !=0 ] && echo "$$: Executing \"$CMD\"..." > `$CMD` > fi > > Alrighty, then. Whenever it runs from a cron job, I get: > ------ > 10488: Executing "/usr/sbin/xfsdump -m -o -l 0 -F -f /dev/nst0 /home"... > /root/sys_backup.sh: /usr/sbin/xfsdump:: No such file or directory > ------ > > What? Yes, /usr/sbin/xfsdump exists: > ---- > # ls -al /usr/sbin/xfsdump > -rwxr-xr-x 1 root root 939348 Oct 18 15:29 /usr/sbin/xfsdump > ---- > > But... if I simply cut and past the line into a > shell,"/usr/sbin/xfsdump -m -o -l 0 -F -f /dev/nst0 /home", it works just > fine and dandy. What, exactly, could I be doing wrong? > > steve > > > > From owner-linux-xfs@oss.sgi.com Thu Jan 17 15:11:41 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0HNBfq02219 for linux-xfs-outgoing; Thu, 17 Jan 2002 15:11:41 -0800 Received: from pneumatic-tube.sgi.com (pneumatic-tube.sgi.com [204.94.214.22]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0HNBbP02194 for ; Thu, 17 Jan 2002 15:11:37 -0800 Received: from zeus-e8.americas.sgi.com (zeus-e8.americas.sgi.com [128.162.8.103]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id OAA08613 for ; Thu, 17 Jan 2002 14:12:23 -0800 (PST) mail_from (lord@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by zeus-e8.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id QAA43119; Thu, 17 Jan 2002 16:10:17 -0600 (CST) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id QAA64813; Thu, 17 Jan 2002 16:10:17 -0600 (CST) Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id g0HM7vQ16690; Thu, 17 Jan 2002 16:07:57 -0600 Subject: Re: XFSdump / shell scripting From: Steve Lord To: Mike Burger Cc: Steve Wolfe , linux-xfs@oss.sgi.com In-Reply-To: References: Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/1.0.1 Date: 17 Jan 2002 16:07:57 -0600 Message-Id: <1011305277.13547.754.camel@jen.americas.sgi.com> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 682 Lines: 25 On Thu, 2002-01-17 at 16:06, Mike Burger wrote: > On my system, xfsdump is in /sbin. > > On Thu, 17 Jan 2002, Steve Wolfe wrote: > > > > > OK, I'm lost, and obviously clueless. As part of a backup script that > > I'm writing to replace our current backup solution, I'm doing this: > > > > DEVICE=/dev/st0 > > NR_DEVICE=/dev/nst0 > > DUMP=/sbin/dump > > XFSDUMP=/usr/sbin/xfsdump > > xfsdump moved in later packages, the fact that yours is in /usr/sbin suggests it is rather dated. You might benefit from a newer version. Steve -- Steve Lord voice: +1-651-683-3511 Principal Engineer, Filesystem Software email: lord@sgi.com From owner-linux-xfs@oss.sgi.com Thu Jan 17 15:17:21 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0HNHLk02423 for linux-xfs-outgoing; Thu, 17 Jan 2002 15:17:21 -0800 Received: from zok.sgi.com (zok.sgi.com [204.94.215.101]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0HNHFP02388 for ; Thu, 17 Jan 2002 15:17:15 -0800 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by zok.sgi.com (8.11.4/8.11.4/linux-outbound_gateway-1.1) with SMTP id g0HMH7o21594 for ; Thu, 17 Jan 2002 14:17:07 -0800 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 JAA02608; Fri, 18 Jan 2002 09:15:51 +1100 Received: (from nathans@localhost) by wobbly.melbourne.sgi.com (SGI-8.9.3/8.9.3) id JAA35524; Fri, 18 Jan 2002 09:15:50 +1100 (AEDT) Date: Fri, 18 Jan 2002 09:15:50 +1100 From: Nathan Scott To: Steve Wolfe Cc: linux-xfs@oss.sgi.com Subject: Re: XFSdump / shell scripting Message-ID: <20020118091550.B34302@wobbly.melbourne.sgi.com> References: <004c01c19fa2$af0f0500$d281f6cc@iboats.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <004c01c19fa2$af0f0500$d281f6cc@iboats.com>; from nw@codon.com on Thu, Jan 17, 2002 at 03:02:36PM -0700 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 1300 Lines: 55 hi, On Thu, Jan 17, 2002 at 03:02:36PM -0700, Steve Wolfe wrote: > > OK, I'm lost, and obviously clueless. As part of a backup script that > I'm writing to replace our current backup solution, I'm doing this: > > DEVICE=/dev/st0 > NR_DEVICE=/dev/nst0 > DUMP=/sbin/dump > XFSDUMP=/usr/sbin/xfsdump > > (snip) > > then > CMD="$XFSDUMP -m -o -l 0 -F -f $NR_DEVICE $FS" > [ $DEBUG !=0 ] && echo "$$: Executing \"$CMD\"..." > `$CMD` ^^^^^^ Try it without the quotes (``) around $CMD, or use: eval "$CMD" instead. /usr/sbin/xfsdump should always exist (it is a symlink to the /sbin/xfsdump binary in recent xfsdump packages). cheers. > fi > > Alrighty, then. Whenever it runs from a cron job, I get: > ------ > 10488: Executing "/usr/sbin/xfsdump -m -o -l 0 -F -f /dev/nst0 /home"... > /root/sys_backup.sh: /usr/sbin/xfsdump:: No such file or directory > ------ > > What? Yes, /usr/sbin/xfsdump exists: > ---- > # ls -al /usr/sbin/xfsdump > -rwxr-xr-x 1 root root 939348 Oct 18 15:29 /usr/sbin/xfsdump > ---- > > But... if I simply cut and past the line into a > shell,"/usr/sbin/xfsdump -m -o -l 0 -F -f /dev/nst0 /home", it works just > fine and dandy. What, exactly, could I be doing wrong? > > steve > > > -- Nathan From owner-linux-xfs@oss.sgi.com Thu Jan 17 15:25:42 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0HNPgs02662 for linux-xfs-outgoing; Thu, 17 Jan 2002 15:25:42 -0800 Received: from sgi.com (sgi.SGI.COM [192.48.153.1]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0HNPaP02639 for ; Thu, 17 Jan 2002 15:25:36 -0800 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via SMTP id OAA00006 for ; Thu, 17 Jan 2002 14:24:36 -0800 (PST) mail_from (nathans@wobbly.melbourne.sgi.com) Received: from wobbly.melbourne.sgi.com (wobbly.melbourne.sgi.com [134.14.55.135]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id JAA02670 for ; Fri, 18 Jan 2002 09:24:17 +1100 Received: (from nathans@localhost) by wobbly.melbourne.sgi.com (SGI-8.9.3/8.9.3) id JAA35509 for linux-xfs@oss.sgi.com; Fri, 18 Jan 2002 09:24:16 +1100 (AEDT) Date: Fri, 18 Jan 2002 09:24:16 +1100 From: Nathan Scott To: linux-xfs@oss.sgi.com Subject: Re: things to do in brooklyn when your filesystem is dead Message-ID: <20020118092416.C34302@wobbly.melbourne.sgi.com> References: <20020112122144.R15376@blank.org> <20020114113445.D24972@wobbly.melbourne.sgi.com> <20020115223312.G15376@blank.org> <20020116182420.F30220@wobbly.melbourne.sgi.com> <20020116233758.X15376@blank.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20020116233758.X15376@blank.org>; from memory-xfs@blank.org on Wed, Jan 16, 2002 at 11:37:58PM -0500 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 1862 Lines: 50 hi, On Wed, Jan 16, 2002 at 11:37:58PM -0500, Nathan J. Mehl wrote: > In the immortal words of Nathan Scott (nathans@sgi.com): > > > > > > Is there anything that can be done manually to avoid this, or should I > > > just let xfs_repair do its job and salvage what I can from lost+found? > > > > That's pretty much the only option available at this point > > (unless you've used xfsdump/some other backup utility to keep > > a recent backup, and can use that in conjunction/instead). > > Hm. Okay, I seem to have run into another xfs_repair issue. The cvs > code pushes past the log error, but there are a number of inodes that > it seems unable to properly clear/repair. Every run of xfs_repair on > this fs since the first one produces the following output: > > http://blank.org/memory/repair.out > ugh, that looks nasty - inode 448 seems to be a recuring theme. can you send me output from: # xfs_db -r -c 'inode 448' -c p /dev/XXX [at a guess I'd say 448 is a directory inode, something in repair thinks its free, and some other part of repair doesn't, and all the other inodes are direct children of 448] it would also help greatly if I could get access to the filesystem, eg. by ssh or by downloading the compressed image (probably way too big in your case by the look of it). cheers. > Subsequent iterations produce exactly the same output, referencing > exactly the same inodes. > > Any notion why xfs_repair might be claiming to move directories and > files into lost+found but not actually doing it? > > -n > > ----------------------------------------------------------- > "`G.I. Jane' is a demeaning, violent, bloody workout video. Some brief > nudity, bad language and a false sense of human resilience. Rated R." (--CNN) > --------------------------------------------------- -- Nathan From owner-linux-xfs@oss.sgi.com Thu Jan 17 15:26:38 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0HNQcK02795 for linux-xfs-outgoing; Thu, 17 Jan 2002 15:26:38 -0800 Received: from burgers.bubbanfriends.org (IDENT:postfix@burgers.bubbanfriends.org [216.140.122.113]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0HNQWP02771 for ; Thu, 17 Jan 2002 15:26:32 -0800 Received: by burgers.bubbanfriends.org (Postfix, from userid 500) id E8C50835FEA; Thu, 17 Jan 2002 17:26:35 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by burgers.bubbanfriends.org (Postfix) with ESMTP id E728E280045D for ; Thu, 17 Jan 2002 17:26:35 -0500 (EST) Date: Thu, 17 Jan 2002 17:26:35 -0500 (EST) From: Mike Burger To: Subject: xfsdump dumps core? Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 1893 Lines: 48 Pentium II 300MHz, 256MB RAM, /home is approximately a 14GB partition, but with only 2.4GB used. Running the kernel-2.4.14-SGI_XFS_1.0.2 rpm downloaded from SGI. xfsprogs-1.3.13-0, xfsdump-1.1.7-0. The tape drive is an HP Colorado 8GB IDE drive, being accessed via the ide-scsi module. I can "mt -f /dev/nst0 erase" without any errors. I'm running the following command (please note that "slide" is an sudo like utility), and getting the following output: [mburger@burgers mburger]$ slide xfsdump -m -b 4096 -o -l 0 -F -f /dev/nst0 /home xfsdump: version 3.0 - Running single-threaded xfsdump: WARNING: no session label specified xfsdump: saving user quota information for: /home xfsdump: WARNING: overwriting: /home/xfsdump_quotas xfsdump: WARNING: most recent level 0 dump was interrupted, but not resuming that dump since resume (-R) option not specified xfsdump: level 0 dump of burgers.bubbanfriends.org:/home xfsdump: dump date: Thu Jan 17 17:21:49 2002 xfsdump: session id: c941cbfd-b628-403d-819d-b9f1ee1796a5 xfsdump: session label: "" xfsdump: ino map phase 1: skipping (no subtrees specified) xfsdump: ino map phase 2: constructing initial dump list xfsdump: ino map phase 3: skipping (no pruning necessary) xfsdump: ino map phase 4: skipping (size estimated in phase 2) xfsdump: ino map phase 5: skipping (only one dump stream) xfsdump: ino map construction complete xfsdump: estimated dump size: 2570099456 bytes xfsdump: preparing drive xfsdump: WARNING: media may contain data. Overwrite option specified xfsdump: WARNING: no media label specified xfsdump: creating dump session media file 0 (media 0, file 0) xfsdump: dumping ino map xfsdump: drive_minrmt.c:1862: do_get_write_buf: Assertion `contextp->dc_nextp < contextp->dc_recendp' failed. Aborted (core dumped) I'll be more than happy to send the core file if you folks want to look at it. Thanks. --Mike From owner-linux-xfs@oss.sgi.com Thu Jan 17 16:04:36 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0I04aq03924 for linux-xfs-outgoing; Thu, 17 Jan 2002 16:04:36 -0800 Received: from pneumatic-tube.sgi.com (pneumatic-tube.sgi.com [204.94.214.22]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0I04WP03893 for ; Thu, 17 Jan 2002 16:04:32 -0800 Received: from zeus-e8.americas.sgi.com (zeus-e8.americas.sgi.com [128.162.8.103]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id PAA09019 for ; Thu, 17 Jan 2002 15:05:18 -0800 (PST) mail_from (lord@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by zeus-e8.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id RAA43697; Thu, 17 Jan 2002 17:03:13 -0600 (CST) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id RAA90545; Thu, 17 Jan 2002 17:03:13 -0600 (CST) Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id g0HN3CR22435; Thu, 17 Jan 2002 17:03:12 -0600 Subject: Re: xfsdump dumps core? From: Steve Lord To: Mike Burger Cc: linux-xfs@oss.sgi.com In-Reply-To: References: Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/1.0.1 Date: 17 Jan 2002 17:03:12 -0600 Message-Id: <1011308592.13547.791.camel@jen.americas.sgi.com> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 481 Lines: 17 On Thu, 2002-01-17 at 16:26, Mike Burger wrote: > Pentium II 300MHz, 256MB RAM, /home is approximately a 14GB partition, but > with only 2.4GB used. Running the kernel-2.4.14-SGI_XFS_1.0.2 rpm > downloaded from SGI. > > xfsprogs-1.3.13-0, xfsdump-1.1.7-0. The tree here is up to xfsdump-1.1.14, you might want to upgrade. Steve -- Steve Lord voice: +1-651-683-3511 Principal Engineer, Filesystem Software email: lord@sgi.com From owner-linux-xfs@oss.sgi.com Thu Jan 17 16:31:48 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0I0Vmu04521 for linux-xfs-outgoing; Thu, 17 Jan 2002 16:31:48 -0800 Received: from burgers.bubbanfriends.org (IDENT:postfix@burgers.bubbanfriends.org [216.140.122.113]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0I0ViP04499 for ; Thu, 17 Jan 2002 16:31:44 -0800 Received: by burgers.bubbanfriends.org (Postfix, from userid 500) id E4E84835FEA; Thu, 17 Jan 2002 18:31:41 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by burgers.bubbanfriends.org (Postfix) with ESMTP id D941D280045C; Thu, 17 Jan 2002 18:31:41 -0500 (EST) Date: Thu, 17 Jan 2002 18:31:41 -0500 (EST) From: Mike Burger To: Steve Lord Cc: Subject: Re: xfsdump dumps core? In-Reply-To: <1011308592.13547.791.camel@jen.americas.sgi.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 724 Lines: 23 Aaahhh...I guess I live by the RPM, since I'm running a Red Hat system (7.1 on this particular box). Is there an easy tarball, or is CVS the only way to get it...I don't have CVS configured (I don't even know if it's installed, to tell the truth) on this system, and wouldn't really know how to use it properly, anyhow. On 17 Jan 2002, Steve Lord wrote: > On Thu, 2002-01-17 at 16:26, Mike Burger wrote: > > Pentium II 300MHz, 256MB RAM, /home is approximately a 14GB partition, but > > with only 2.4GB used. Running the kernel-2.4.14-SGI_XFS_1.0.2 rpm > > downloaded from SGI. > > > > xfsprogs-1.3.13-0, xfsdump-1.1.7-0. > > The tree here is up to xfsdump-1.1.14, you might want to upgrade. > > Steve > > > From owner-linux-xfs@oss.sgi.com Thu Jan 17 16:35:04 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0I0Z4K04674 for linux-xfs-outgoing; Thu, 17 Jan 2002 16:35:04 -0800 Received: from roper.uwyo.edu (pmdf@roper.uwyo.edu [129.72.10.8] (may be forged)) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0I0YtP04651 for ; Thu, 17 Jan 2002 16:34:55 -0800 Received: from CONVERSION-DAEMON by ROPER.UWYO.EDU (PMDF V5.2-32 #33749) id <0GQ300501VMI6Z@ROPER.UWYO.EDU> for linux-xfs@oss.sgi.com; Thu, 17 Jan 2002 16:34:49 -0700 (MST) Received: from asuwlink.uwyo.edu (asuwlink.uwyo.edu [129.72.60.2]) by ROPER.UWYO.EDU (PMDF V5.2-32 #33749) with ESMTP id <0GQ30049SVM591@ROPER.UWYO.EDU> for linux-xfs@oss.sgi.com; Thu, 17 Jan 2002 16:22:53 -0700 (MST) Received: from uwyo.edu (ringram@ross226.uwyo.edu [129.72.51.220]) by asuwlink.uwyo.edu (8.8.8/8.8.7) with ESMTP id QAA11755 for ; Thu, 17 Jan 2002 16:22:53 -0700 (MST) Date: Thu, 17 Jan 2002 16:36:04 +0000 From: ringram@uwyo.edu Subject: Re: xfsdump dumps core? To: linux-xfs@oss.sgi.com Reply-to: ringram@acpl.lib.wy.us Message-id: <3C46FD74.3ACCE332@uwyo.edu> Organization: UW Math Dept/Institute for Scientific Computation MIME-version: 1.0 X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.16-xfs i686) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7bit X-Accept-Language: en References: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 2616 Lines: 68 Mike Burger wrote: > > Pentium II 300MHz, 256MB RAM, /home is approximately a 14GB partition, but > with only 2.4GB used. Running the kernel-2.4.14-SGI_XFS_1.0.2 rpm > downloaded from SGI. > > xfsprogs-1.3.13-0, xfsdump-1.1.7-0. > > The tape drive is an HP Colorado 8GB IDE drive, being accessed via the > ide-scsi module. > > I can "mt -f /dev/nst0 erase" without any errors. > > I'm running the following command (please note that "slide" is an sudo > like utility), and getting the following output: > > [mburger@burgers mburger]$ slide xfsdump -m -b 4096 -o -l 0 -F -f /dev/nst0 /home > xfsdump: version 3.0 - Running single-threaded > xfsdump: WARNING: no session label specified > xfsdump: saving user quota information for: /home > xfsdump: WARNING: overwriting: /home/xfsdump_quotas > xfsdump: WARNING: most recent level 0 dump was interrupted, but not > resuming that dump since resume (-R) option not specified > xfsdump: level 0 dump of burgers.bubbanfriends.org:/home > xfsdump: dump date: Thu Jan 17 17:21:49 2002 > xfsdump: session id: c941cbfd-b628-403d-819d-b9f1ee1796a5 > xfsdump: session label: "" > xfsdump: ino map phase 1: skipping (no subtrees specified) > xfsdump: ino map phase 2: constructing initial dump list > xfsdump: ino map phase 3: skipping (no pruning necessary) > xfsdump: ino map phase 4: skipping (size estimated in phase 2) > xfsdump: ino map phase 5: skipping (only one dump stream) > xfsdump: ino map construction complete > xfsdump: estimated dump size: 2570099456 bytes > xfsdump: preparing drive > xfsdump: WARNING: media may contain data. Overwrite option specified > xfsdump: WARNING: no media label specified > xfsdump: creating dump session media file 0 (media 0, file 0) > xfsdump: dumping ino map > xfsdump: drive_minrmt.c:1862: do_get_write_buf: Assertion > `contextp->dc_nextp < contextp->dc_recendp' failed. > Aborted (core dumped) > > I'll be more than happy to send the core file if you folks want to look at > it. > > Thanks. > > --Mike I had a very similar error with xfsdump with a HP Colorado 8GB parallel tape drive that turned out to be a problem with the driver. Basically the weof ioctl was broken. I don't know if that is also your problem but the problem I posted (http://marc.theaimsgroup.com/?l=linux-xfs&m=99535721114946&w=2) did at least prompt an upgrade to the xfsdump code so that it doesn't core dump when it hits that problem. You should definitely upgrade. Russ -- Russel H. Ingram Unix Systems Administrator Institute for Scientific Computation University of Wyoming/Math Dept. Phone: (307)766-6546 E-Mail: ringram@uwyo.edu From owner-linux-xfs@oss.sgi.com Thu Jan 17 16:35:29 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0I0ZTG04797 for linux-xfs-outgoing; Thu, 17 Jan 2002 16:35:29 -0800 Received: from deliverator.sgi.com (deliverator.sgi.com [204.94.214.10]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0I0ZNP04752 for ; Thu, 17 Jan 2002 16:35:23 -0800 Received: from mailhost.idcomm.com (mailhost.idcomm.com [207.40.196.14]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id OAA20529 for ; Thu, 17 Jan 2002 14:55:46 -0800 (PST) mail_from (stimits@idcomm.com) Received: from idcomm.com (IDENT:0ioI8wvfQTiC8YA5uGFY4XTRIICUYwrP@k56-pip80.idcomm.com [209.60.72.207] (may be forged)) by mailhost.idcomm.com (8.10.2/8.10.0) with ESMTP id g0HMxDx21791 for ; Thu, 17 Jan 2002 15:59:13 -0700 Message-ID: <3C475605.4FA7A8B5@idcomm.com> Date: Thu, 17 Jan 2002 15:53:57 -0700 From: "D. Stimits" Reply-To: stimits@idcomm.com X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.6-pre1-xfs-4 i686) X-Accept-Language: en MIME-Version: 1.0 To: "XFS: linux-xfs@oss.sgi.com" Subject: Re: TAKE - Fix forced shutdown problems References: <200201172153.g0HLraV06109@stout.americas.sgi.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 1482 Lines: 35 I am curious if checkins of these fixes also result in patches to the latest 2.4.x diff also getting updated? E.G., if the ftp site has patches to go from stock 2.4.17, and this is the most currently available non-2.5.x kernel, do the 2.4.17 patches get updated at the same time as cvs? Or within a short time period? D. Stimits, stimits@idcomm.com Eric Sandeen wrote: > > As _xfs_force_shutdown was written, it tried to schedule in an interrupt context > and caused a BUG() to be thrown. > > Also, even if we didn't try to deal with leftover buffers in the interrupt, > they subsequently had their delalloc flags removed, and thus queued up > to clobber block 0 (1,2,3) on the disk, thus corrupting the filesystem. > > So, remove the in-interrupt activity, and if we later get a dellalloc buffer > that bmap can't find a home for, just throw it away. > > Date: Thu Jan 17 13:43:10 PST 2002 > Workarea: stout.americas.sgi.com:/localhome/eric/2.4.x-xfs/workarea-reallyclean > > The following file(s) were checked into: > bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs > > Modid: 2.4.x-xfs:slinx:109821a > linux/fs/xfs/xfs_rw.c - 1.349 > - Don't try to clear out remaining delwri buffers in _xfs_force_shutdown, > we are in an interrupt context and can't sleep, just let the > buffers get caught as they try to get on-disk. > > linux/fs/xfs/pagebuf/page_buf_io.c - 1.3 > - Don't just clear delay flag on bmap failure, wipe out the buffer From owner-linux-xfs@oss.sgi.com Thu Jan 17 16:49:37 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0I0nb305098 for linux-xfs-outgoing; Thu, 17 Jan 2002 16:49:37 -0800 Received: from hob.slb.nwc.acsalaska.net (hob.slb.nwc.acsalaska.net [209.112.155.42]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0I0nTP05074 for ; Thu, 17 Jan 2002 16:49:29 -0800 Received: from erbenson.alaska.net (180-pm11.nwc.alaska.net [209.112.140.180]) by hob.slb.nwc.acsalaska.net (8.11.6/8.11.6) with ESMTP id g0HNnQs85289 for ; Thu, 17 Jan 2002 14:49:26 -0900 (AKST) (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 C3AC93927 for ; Thu, 17 Jan 2002 14:49:24 -0900 (AKST) Received: by plato.local.lan (Postfix, from userid 1000) id C3D5B10238; Thu, 17 Jan 2002 14:49:24 -0900 (AKST) Date: Thu, 17 Jan 2002 14:49:24 -0900 From: Ethan Benson To: linux-xfs@oss.sgi.com Subject: Re: XFSdump / shell scripting Message-ID: <20020117144924.O3026@plato.local.lan> Mail-Followup-To: linux-xfs@oss.sgi.com References: <004c01c19fa2$af0f0500$d281f6cc@iboats.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="p/1JFEOz/hVXxMAZ" Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <004c01c19fa2$af0f0500$d281f6cc@iboats.com>; from nw@codon.com on Thu, Jan 17, 2002 at 03:02:36PM -0700 X-OS: Debian GNU Mail-Copies-To: nobody X-No-CC: I subscribe to this list; do not CC me on replies. Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 1318 Lines: 49 --p/1JFEOz/hVXxMAZ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Jan 17, 2002 at 03:02:36PM -0700, Steve Wolfe wrote: >=20 > OK, I'm lost, and obviously clueless. As part of a backup script that > I'm writing to replace our current backup solution, I'm doing this: >=20 > DEVICE=3D/dev/st0 > NR_DEVICE=3D/dev/nst0 > DUMP=3D/sbin/dump > XFSDUMP=3D/usr/sbin/xfsdump >=20 > (snip) >=20 > then > CMD=3D"$XFSDUMP -m -o -l 0 -F -f $NR_DEVICE $FS" > [ $DEBUG !=3D0 ] && echo "$$: Executing \"$CMD\"..." > `$CMD` > fi >=20 > Alrighty, then. Whenever it runs from a cron job, I get: > ------ > 10488: Executing "/usr/sbin/xfsdump -m -o -l 0 -F -f /dev/nst0 /home"... > /root/sys_backup.sh: /usr/sbin/xfsdump:: No such file or directory you need to start your script with #!/bin/sh as the very first line. --=20 Ethan Benson http://www.alaska.net/~erbenson/ --p/1JFEOz/hVXxMAZ 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 iEYEARECAAYFAjxHYwQACgkQJKx7GixEevwX0gCfQKiYXi5R8u2ZdAIeOhRgFYdP B6QAniinF4/yaVkbiePHDcT/Kex5MgJg =cGJz -----END PGP SIGNATURE----- --p/1JFEOz/hVXxMAZ-- From owner-linux-xfs@oss.sgi.com Thu Jan 17 16:50:52 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0I0oqd05228 for linux-xfs-outgoing; Thu, 17 Jan 2002 16:50:52 -0800 Received: from yog-sothoth.sgi.com (eugate.sgi.com [192.48.160.10]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0I0onP05206 for ; Thu, 17 Jan 2002 16:50:49 -0800 Received: from nodin.corp.sgi.com (fddi-nodin.corp.sgi.com [198.29.75.193]) by yog-sothoth.sgi.com (980305.SGI.8.8.8-aspam-6.2/980304.SGI-aspam-europe) via ESMTP id AAA62781 for ; Fri, 18 Jan 2002 00:49:46 +0100 (CET) mail_from (kaos@sgi.com) Received: from kao2.melbourne.sgi.com (kao2.melbourne.sgi.com [134.14.55.180]) by nodin.corp.sgi.com (8.11.4/8.11.2/nodin-1.0) with ESMTP id g0HNni424551337; Thu, 17 Jan 2002 15:49:44 -0800 (PST) Received: by kao2.melbourne.sgi.com (Postfix, from userid 16331) id 85C883000AD; Fri, 18 Jan 2002 10:49:42 +1100 (EST) Received: from kao2.melbourne.sgi.com (localhost [127.0.0.1]) by kao2.melbourne.sgi.com (Postfix) with ESMTP id 2C4CF94; Fri, 18 Jan 2002 10:49:42 +1100 (EST) X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 From: Keith Owens To: stimits@idcomm.com Cc: "XFS: linux-xfs@oss.sgi.com" Subject: Re: TAKE - Fix forced shutdown problems In-reply-to: Your message of "Thu, 17 Jan 2002 15:53:57 PDT." <3C475605.4FA7A8B5@idcomm.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 18 Jan 2002 10:49:35 +1100 Message-ID: <5669.1011311375@kao2.melbourne.sgi.com> Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 482 Lines: 11 On Thu, 17 Jan 2002 15:53:57 -0700, "D. Stimits" wrote: >I am curious if checkins of these fixes also result in patches to the >latest 2.4.x diff also getting updated? E.G., if the ftp site has >patches to go from stock 2.4.17, and this is the most currently >available non-2.5.x kernel, do the 2.4.17 patches get updated at the >same time as cvs? Or within a short time period? ftp://oss.sgi.com/projects/xfs/download/patches/2.4.17/README third paragraph. From owner-linux-xfs@oss.sgi.com Thu Jan 17 17:07:04 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0I174B05643 for linux-xfs-outgoing; Thu, 17 Jan 2002 17:07:04 -0800 Received: from local.iboats.com ([204.246.129.200]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0I16xP05618 for ; Thu, 17 Jan 2002 17:06:59 -0800 Received: (qmail 10383 invoked by uid 82); 18 Jan 2002 00:06:25 -0000 Received: from nw@codon.com by local with qmail-scanner-0.96 (. Clean. Processed in 0.307207 secs); 18 Jan 2002 00:06:25 -0000 Received: from weasel.local.iboats.com (HELO weasel) (204.246.129.210) by 204.246.129.200 with SMTP; 18 Jan 2002 00:06:23 -0000 Message-ID: <004a01c19fb4$9423fa40$d281f6cc@iboats.com> From: "Steve Wolfe" To: References: <1011305277.13547.754.camel@jen.americas.sgi.com> Subject: Re: XFSdump / shell scripting Date: Thu, 17 Jan 2002 17:10:43 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 886 Lines: 30 Various replies.... > xfsdump moved in later packages, the fact that yours is in /usr/sbin > suggests it is rather dated. You might benefit from a newer version. Thanks for the tip. : ) > seems like a path issue at runtime. Does your .bash_profile have pathing > that differs from /etc/profile? I would have thought that, except I'm calling it with a fully qualified path, I'm not depending on $PATH - and I explicitly set $PATH to include the directory where xfsdump is located, just in case. > Try it without the quotes (``) around $CMD, or use: > eval "$CMD" > instead. Will do. I'll report tomorrow after it runs. > you need to start your script with #!/bin/sh as the very first line. Yes, I am, I had just omitted that and other stuff that doesn't affect the performance, and probably wouldn't interest anybody. ; ) Thanks again to all for the replies. steve From owner-linux-xfs@oss.sgi.com Thu Jan 17 17:14:58 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0I1EwF05891 for linux-xfs-outgoing; Thu, 17 Jan 2002 17:14:58 -0800 Received: from yog-sothoth.sgi.com (eugate.sgi.com [192.48.160.10]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0I1EsP05869 for ; Thu, 17 Jan 2002 17:14:55 -0800 Received: from nodin.corp.sgi.com (fddi-nodin.corp.sgi.com [198.29.75.193]) by yog-sothoth.sgi.com (980305.SGI.8.8.8-aspam-6.2/980304.SGI-aspam-europe) via ESMTP id BAA66767 for ; Fri, 18 Jan 2002 01:13:25 +0100 (CET) mail_from (kaos@sgi.com) Received: from kao2.melbourne.sgi.com (kao2.melbourne.sgi.com [134.14.55.180]) by nodin.corp.sgi.com (8.11.4/8.11.2/nodin-1.0) with ESMTP id g0I0DA424611884; Thu, 17 Jan 2002 16:13:10 -0800 (PST) Received: by kao2.melbourne.sgi.com (Postfix, from userid 16331) id 4AE4D3000AD; Fri, 18 Jan 2002 11:13:07 +1100 (EST) Received: from kao2.melbourne.sgi.com (localhost [127.0.0.1]) by kao2.melbourne.sgi.com (Postfix) with ESMTP id C9D6394; Fri, 18 Jan 2002 11:13:07 +1100 (EST) X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 From: Keith Owens To: "Steve Wolfe" Cc: linux-xfs@oss.sgi.com Subject: Re: XFSdump / shell scripting In-reply-to: Your message of "Thu, 17 Jan 2002 17:10:43 PDT." <004a01c19fb4$9423fa40$d281f6cc@iboats.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 18 Jan 2002 11:13:02 +1100 Message-ID: <5947.1011312782@kao2.melbourne.sgi.com> Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 442 Lines: 13 On Thu, 17 Jan 2002 17:10:43 -0700, "Steve Wolfe" wrote: >> Try it without the quotes (``) around $CMD, or use: >> eval "$CMD" >> instead. The problem is the backticks. You are executing $CMD, taking the output from xfsdump then trying to execute the output. That is why it says xfsdump:: with two ':', the output starts with 'xfsdump:' and it is not surprising that the shell cannot find that command. $CMD, not `$CMD`. From owner-linux-xfs@oss.sgi.com Thu Jan 17 18:06:44 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0I26iB06677 for linux-xfs-outgoing; Thu, 17 Jan 2002 18:06:44 -0800 Received: from UberGeek.coremetrics.com ([209.184.141.163]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0I26bP06652 for ; Thu, 17 Jan 2002 18:06:38 -0800 Received: (from austin@localhost) by UberGeek.coremetrics.com (8.11.6/8.11.6) id g0I160A28266; Thu, 17 Jan 2002 19:06:00 -0600 X-Authentication-Warning: UberGeek.coremetrics.com: austin set sender to austin@coremetrics.com using -f Subject: [OT] Graphing with GNUPlot From: Austin Gonyou To: linux-xfs@oss.sgi.com Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-q4KlVEimzTc1/bCEaOeI" X-Mailer: Evolution/1.0.1 Date: 17 Jan 2002 19:06:00 -0600 Message-Id: <1011315960.28114.8.camel@UberGeek> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 1064 Lines: 37 --=-q4KlVEimzTc1/bCEaOeI Content-Type: text/plain Content-Transfer-Encoding: quoted-printable I'm about ready to give up. I'm doing some benchmarking of XFS+LVM Striping v. XFS+HW RAID0 to determine the differences, if any, of our setup. I don't fully understand how gnuplot works. Can anyone give me some kind of idea if I can use CSV input, etc? I can't seem to find any of this info in the man pages or google etc. Sorry for the inconvenience.=20 =20 --=20 Austin Gonyou Systems Architect, CCNA Coremetrics, Inc. Phone: 512-698-7250 email: austin@coremetrics.com "It is the part of a good shepherd to shear his flock, not to skin it." Latin Proverb --=-q4KlVEimzTc1/bCEaOeI Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD4DBQA8R3T494g6ZVmFMoIRAk0qAJY8qZjxmkYwaagSqcU0YVJsVjwcAJ9eMjac 8t+C2FS7sb35kI55E45P8Q== =iBVG -----END PGP SIGNATURE----- --=-q4KlVEimzTc1/bCEaOeI-- From owner-linux-xfs@oss.sgi.com Thu Jan 17 18:08:47 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0I28lA06827 for linux-xfs-outgoing; Thu, 17 Jan 2002 18:08:47 -0800 Received: from burgers.bubbanfriends.org (IDENT:postfix@burgers.bubbanfriends.org [216.140.122.113]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0I28gP06803 for ; Thu, 17 Jan 2002 18:08:42 -0800 Received: by burgers.bubbanfriends.org (Postfix, from userid 500) id EBE82835FE7; Thu, 17 Jan 2002 20:08:40 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by burgers.bubbanfriends.org (Postfix) with ESMTP id EA5B7280045C for ; Thu, 17 Jan 2002 20:08:40 -0500 (EST) Date: Thu, 17 Jan 2002 20:08:40 -0500 (EST) From: Mike Burger To: Subject: Re: xfsdump dumps core? In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 985 Lines: 31 Never mind...I followed the CVS instructions on the web site, and am running a "make install-dev" right now, so that I can compile the xfsdump and xfsprogs utilities. On Thu, 17 Jan 2002, Mike Burger wrote: > Aaahhh...I guess I live by the RPM, since I'm running a Red Hat system > (7.1 on this particular box). > > Is there an easy tarball, or is CVS the only way to get it...I don't have > CVS configured (I don't even know if it's installed, to tell the truth) on > this system, and wouldn't really know how to use it properly, anyhow. > > On 17 Jan 2002, Steve Lord wrote: > > > On Thu, 2002-01-17 at 16:26, Mike Burger wrote: > > > Pentium II 300MHz, 256MB RAM, /home is approximately a 14GB partition, but > > > with only 2.4GB used. Running the kernel-2.4.14-SGI_XFS_1.0.2 rpm > > > downloaded from SGI. > > > > > > xfsprogs-1.3.13-0, xfsdump-1.1.7-0. > > > > The tree here is up to xfsdump-1.1.14, you might want to upgrade. > > > > Steve > > > > > > > > From owner-linux-xfs@oss.sgi.com Thu Jan 17 18:21:05 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0I2L5E07164 for linux-xfs-outgoing; Thu, 17 Jan 2002 18:21:05 -0800 Received: from UberGeek.coremetrics.com ([209.184.141.163]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0I2KvP07139 for ; Thu, 17 Jan 2002 18:20:58 -0800 Received: (from austin@localhost) by UberGeek.coremetrics.com (8.11.6/8.11.6) id g0I1KL228586; Thu, 17 Jan 2002 19:20:21 -0600 X-Authentication-Warning: UberGeek.coremetrics.com: austin set sender to austin@coremetrics.com using -f Subject: Re: [OT] Graphing with GNUPlot From: Austin Gonyou To: linux-xfs@oss.sgi.com In-Reply-To: <1011315960.28114.8.camel@UberGeek> References: <1011315960.28114.8.camel@UberGeek> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-g6I4aOWIojpn6nQ1xg/j" X-Mailer: Evolution/1.0.1 Date: 17 Jan 2002 19:20:21 -0600 Message-Id: <1011316821.28112.10.camel@UberGeek> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 1516 Lines: 51 --=-g6I4aOWIojpn6nQ1xg/j Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Ok..well I found some info. Sorry to bother all of you. I'd still be interested in any tips, but I think I "might" be able to make it work with what I've got.=20 On Thu, 2002-01-17 at 19:06, Austin Gonyou wrote: > I'm about ready to give up. I'm doing some benchmarking of XFS+LVM > Striping v. XFS+HW RAID0 to determine the differences, if any, of our > setup. I don't fully understand how gnuplot works. Can anyone give me > some kind of idea if I can use CSV input, etc? I can't seem to find any > of this info in the man pages or google etc. Sorry for the > inconvenience.=20 >=20 >=20=20 > --=20 > Austin Gonyou > Systems Architect, CCNA > Coremetrics, Inc. > Phone: 512-698-7250 > email: austin@coremetrics.com >=20 > "It is the part of a good shepherd to shear his flock, not to skin it." > Latin Proverb --=20 Austin Gonyou Systems Architect, CCNA Coremetrics, Inc. Phone: 512-698-7250 email: austin@coremetrics.com "It is the part of a good shepherd to shear his flock, not to skin it." Latin Proverb --=-g6I4aOWIojpn6nQ1xg/j Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQA8R3hV94g6ZVmFMoIRApWpAKCruyNCo1MZA4byWYtyOfiJNkLGygCgjJ54 fO1LxMSsvm5XThz+yYV1kQA= =avwQ -----END PGP SIGNATURE----- --=-g6I4aOWIojpn6nQ1xg/j-- From owner-linux-xfs@oss.sgi.com Thu Jan 17 18:34:59 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0I2YxM07405 for linux-xfs-outgoing; Thu, 17 Jan 2002 18:34:59 -0800 Received: from rogue.tripp.org (fdsl9.slkc.uswest.net [209.181.83.9]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0I2YnP07383 for ; Thu, 17 Jan 2002 18:34:49 -0800 Received: from localhost (justin@localhost) by rogue.tripp.org (8.11.1/8.11.1) with ESMTP id g0I1Yj782256; Thu, 17 Jan 2002 18:34:45 -0700 (MST) (envelope-from jtripp@ieee.org) X-Authentication-Warning: rogue.tripp.org: justin owned process doing -bs Date: Thu, 17 Jan 2002 18:34:44 -0700 (MST) From: jtripp@ieee.org X-X-Sender: justin@rogue.tripp.org To: Austin Gonyou cc: linux-xfs@oss.sgi.com Subject: Re: [OT] Graphing with GNUPlot In-Reply-To: <1011315960.28114.8.camel@UberGeek> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 1950 Lines: 82 You can use CSV, but possibly not in the way you want to. It looks like there must be spaces after the commas as well. Gnuplot wants there to be a single point per line of the data file. Examples are: # Gnu population in Antarctica since 1965 1965 103 1970 55 1975 34 1980 24 1985 10 which is to be plotted with: pop(x) = 103*exp((1965-x)/10) plot [1960:1990] 'population.dat', pop(x) You can easily add commas to the above data and still plot it. (e.g. 1965, 103 1970, 55 ... etc) In the case of 1965, 103, 110, 34, 1970, 55, 75, 23, 1975, 34, 22, 10 You can using some thing like the using option. plot [1960:1990] 'population.dat' using 1:2, 'population.dat' using 1:3, 'population.dat' using 1:4 This will pick of the first column and the second or the first and the third, etc. Gnuplot is not going to let you use CSV without doing a little work. > gnuplot gnuplot> help plot datafile # for 3-d stuff. gnuplot> help splot datafile and http://www.uni-karlsruhe.de/~ig25/gnuplot-faq/ .justin. ------------------------------------------------------------------------ Justin Leonard Tripp justin@ee.byu.edu Configurable Computing Laboratory Research Assistant CB 461 x8-7206 Electrical and Computer Engineering Department Brigham Young University On 17 Jan 2002, Austin Gonyou wrote: > I'm about ready to give up. I'm doing some benchmarking of XFS+LVM > Striping v. XFS+HW RAID0 to determine the differences, if any, of our > setup. I don't fully understand how gnuplot works. Can anyone give me > some kind of idea if I can use CSV input, etc? I can't seem to find any > of this info in the man pages or google etc. Sorry for the > inconvenience. > > > -- > Austin Gonyou > Systems Architect, CCNA > Coremetrics, Inc. > Phone: 512-698-7250 > email: austin@coremetrics.com > > "It is the part of a good shepherd to shear his flock, not to skin it." > Latin Proverb > From owner-linux-xfs@oss.sgi.com Thu Jan 17 19:02:58 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0I32wD07961 for linux-xfs-outgoing; Thu, 17 Jan 2002 19:02:58 -0800 Received: from data.upl.cs.wisc.edu (IDENT:root@data.upl.cs.wisc.edu [128.105.45.42]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0I32nP07935 for ; Thu, 17 Jan 2002 19:02:50 -0800 Received: (from hupp@localhost) by data.upl.cs.wisc.edu (8.10.2/8.10.2) id g0I22kV03298; Thu, 17 Jan 2002 20:02:46 -0600 Date: Thu, 17 Jan 2002 20:02:46 -0600 From: Adam Hupp To: linux-xfs@oss.sgi.com Cc: Adrian Pederson Subject: Frequent hangs with 2.4.9-xfs-1.0.2 Message-ID: <20020117200246.B1859@upl.cs.wisc.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2i Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 1080 Lines: 33 We have been experiencing frequent hangs with our Redhat 7.2 system running the 2.4.9 RH7.2 XFS 1.0.2 kernel rpm. There is nothing in the logs, and the machine usually stops dead in it's tracks. No console access, no ping, nothing. One time we still had NFS access while the rest of the machine (console, ssh, etc ) was inaccessable. I seem to be able to trigger it by running lots of fs load, but have not been able to reliably track it down to a single cause. While trying parrallel cp -r (local) and grep'ing through the fs (over nfs) it eventually hung. Is there anything I can do to narrow down the source of the problem? We will be trying the 2.4.14 XFS 1.0.2 kernel. Hardware: 2 X GenuineIntel Pentium III (Coppermine) 996MHz 1Gb Memory Tyan Thunder HEs1 Motherboard 3 X 3ware Escalade 7850 IDE RAID Controller Intel Pro/1000 F ethernet Software: Redhat 7.2 w/ kernel-smp-2.4.9-13SGI_XFS_1.0.2 Setup: Single 2TB XFS Volume, served via NFS No special options to mkfs.xfs. software RAID 0 array on top of 3 RAID 5 hardware arrays Thanks for any advice, -Adam From owner-linux-xfs@oss.sgi.com Thu Jan 17 19:11:06 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0I3B6008189 for linux-xfs-outgoing; Thu, 17 Jan 2002 19:11:06 -0800 Received: from sgi.com (sgi.SGI.COM [192.48.153.1]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0I3B2P08161 for ; Thu, 17 Jan 2002 19:11:02 -0800 Received: from relay1.corp.sgi.com (corp.sgi.com [198.29.75.13]) by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id SAA06370 for ; Thu, 17 Jan 2002 18:09:57 -0800 (PST) mail_from (sandeen@sgi.com) Received: from chuckle.americas.sgi.com (sandeen@chuckle.americas.sgi.com [128.162.211.44]) by relay1.corp.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) via ESMTP id SAA48535; Thu, 17 Jan 2002 18:10:28 -0800 (PST) Date: Thu, 17 Jan 2002 20:10:27 -0600 (CST) From: Eric Sandeen X-X-Sender: To: Mike Burger cc: Subject: Re: xfsdump dumps core? In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 571 Lines: 22 FWIW, I'll get updated userspace RPMs at ftp://oss.sgi.com/projects/xfs/command_rpms in the next few minutes... but what's there now is pretty up to date (xfsprogs 1.3.13, for example). -Eric On Thu, 17 Jan 2002, Mike Burger wrote: > Never mind...I followed the CVS instructions on the web site, and am > running a "make install-dev" right now, so that I can compile the xfsdump > and xfsprogs utilities. > > On Thu, 17 Jan 2002, Mike Burger wrote: > > > Aaahhh...I guess I live by the RPM, since I'm running a Red Hat system > > (7.1 on this particular box). > > From owner-linux-xfs@oss.sgi.com Thu Jan 17 19:15:08 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0I3F8X08431 for linux-xfs-outgoing; Thu, 17 Jan 2002 19:15:08 -0800 Received: from burgers.bubbanfriends.org (IDENT:postfix@burgers.bubbanfriends.org [216.140.122.113]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0I3F2P08394 for ; Thu, 17 Jan 2002 19:15:02 -0800 Received: by burgers.bubbanfriends.org (Postfix, from userid 500) id D8337835FEA; Thu, 17 Jan 2002 21:15:00 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by burgers.bubbanfriends.org (Postfix) with ESMTP id C8742280045C; Thu, 17 Jan 2002 21:15:00 -0500 (EST) Date: Thu, 17 Jan 2002 21:15:00 -0500 (EST) From: Mike Burger To: Eric Sandeen Cc: Subject: Re: xfsdump dumps core? In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 731 Lines: 28 Well, I just compiled xfsdump from the latest CVS, and still dumped. On Thu, 17 Jan 2002, Eric Sandeen wrote: > FWIW, I'll get updated userspace RPMs at > ftp://oss.sgi.com/projects/xfs/command_rpms > > in the next few minutes... > > but what's there now is pretty up to date (xfsprogs 1.3.13, for example). > > -Eric > > > On Thu, 17 Jan 2002, Mike Burger wrote: > > > Never mind...I followed the CVS instructions on the web site, and am > > running a "make install-dev" right now, so that I can compile the xfsdump > > and xfsprogs utilities. > > > > On Thu, 17 Jan 2002, Mike Burger wrote: > > > > > Aaahhh...I guess I live by the RPM, since I'm running a Red Hat system > > > (7.1 on this particular box). > > > > > From owner-linux-xfs@oss.sgi.com Thu Jan 17 19:23:51 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0I3NpT08784 for linux-xfs-outgoing; Thu, 17 Jan 2002 19:23:51 -0800 Received: from zok.sgi.com (zok.sgi.com [204.94.215.101]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0I3NmP08762 for ; Thu, 17 Jan 2002 19:23:48 -0800 Received: from zeus-e8.americas.sgi.com (zeus-e8.americas.sgi.com [128.162.8.103]) by zok.sgi.com (8.11.4/8.11.4/linux-outbound_gateway-1.1) with ESMTP id g0I2Neo01326 for ; Thu, 17 Jan 2002 18:23:41 -0800 Received: from tulip-e185.americas.sgi.com (tulip-e185.americas.sgi.com [128.162.185.208]) by zeus-e8.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id UAA45464; Thu, 17 Jan 2002 20:22:25 -0600 (CST) Received: from sgi.com (usKa48zdf3YYr/PctoIXV1lgEWElBVwj@lord-h1.americas.sgi.com [206.11.101.42]) by tulip-e185.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.7) with ESMTP id UAA01658; Thu, 17 Jan 2002 20:22:24 -0600 (CST) Message-ID: <3C478805.4070008@sgi.com> Date: Thu, 17 Jan 2002 20:27:17 -0600 From: Stephen Lord User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.6) Gecko/20011120 X-Accept-Language: en-us MIME-Version: 1.0 To: Mike Burger CC: Eric Sandeen , linux-xfs@oss.sgi.com Subject: Re: xfsdump dumps core? References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 198 Lines: 14 Mike Burger wrote: >Well, I just compiled xfsdump from the latest CVS, and still dumped. > So a stack trace would help next, one of the folks in Australia may be interested in this. Steve From owner-linux-xfs@oss.sgi.com Thu Jan 17 21:09:59 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0I59x210608 for linux-xfs-outgoing; Thu, 17 Jan 2002 21:09:59 -0800 Received: from pneumatic-tube.sgi.com (pneumatic-tube.sgi.com [204.94.214.22]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0I59qP10586 for ; Thu, 17 Jan 2002 21:09:52 -0800 Received: from relay1.corp.sgi.com (spindle.corp.sgi.com [198.29.75.13]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id UAA06076 for ; Thu, 17 Jan 2002 20:10:39 -0800 (PST) mail_from (sandeen@sgi.com) Received: from chuckle.americas.sgi.com (sandeen@chuckle.americas.sgi.com [128.162.211.44]) by relay1.corp.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) via ESMTP id UAA74620; Thu, 17 Jan 2002 20:09:18 -0800 (PST) Date: Thu, 17 Jan 2002 22:09:17 -0600 (CST) From: Eric Sandeen X-X-Sender: To: Adam Hupp cc: , Adrian Pederson Subject: Re: Frequent hangs with 2.4.9-xfs-1.0.2 In-Reply-To: <20020117200246.B1859@upl.cs.wisc.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 1457 Lines: 45 Hi Adam - There were some fixes that went into CVS around the end of the year that may well fix your problem. Unfortunately, neither of the 1.0.2 kernels have these fixes. If you can, I'd suggest testing either the 2.4.17 snapshot patch, or doing a fresh CVS checkout. -Eric On Thu, 17 Jan 2002, Adam Hupp wrote: > We have been experiencing frequent hangs with our Redhat 7.2 system > running the 2.4.9 RH7.2 XFS 1.0.2 kernel rpm. There is nothing in the > logs, and the machine usually stops dead in it's tracks. No console > access, no ping, nothing. One time we still had NFS access while the > rest of the machine (console, ssh, etc ) was inaccessable. I seem to be > able to trigger it by running lots of fs load, but have not been able to > reliably track it down to a single cause. While trying parrallel cp -r > (local) and grep'ing through the fs (over nfs) it eventually hung. > > Is there anything I can do to narrow down the source of the problem? We > will be trying the 2.4.14 XFS 1.0.2 kernel. > > > Hardware: > 2 X GenuineIntel Pentium III (Coppermine) 996MHz > 1Gb Memory > Tyan Thunder HEs1 Motherboard > 3 X 3ware Escalade 7850 IDE RAID Controller > Intel Pro/1000 F ethernet > > Software: > Redhat 7.2 w/ kernel-smp-2.4.9-13SGI_XFS_1.0.2 > > Setup: > Single 2TB XFS Volume, served via NFS > No special options to mkfs.xfs. > software RAID 0 array on top of 3 RAID 5 hardware arrays > > > Thanks for any advice, > > -Adam > From owner-linux-xfs@oss.sgi.com Thu Jan 17 21:16:16 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0I5GGQ10887 for linux-xfs-outgoing; Thu, 17 Jan 2002 21:16:16 -0800 Received: from deliverator.sgi.com (deliverator.sgi.com [204.94.214.10]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0I5GBP10865 for ; Thu, 17 Jan 2002 21:16:11 -0800 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via SMTP id UAA09299 for ; Thu, 17 Jan 2002 20:11:46 -0800 (PST) mail_from (ivanr@sgi.com) From: ivanr@sgi.com Received: from omen.melbourne.sgi.com (omen.melbourne.sgi.com [134.14.55.139]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id PAA04901; Fri, 18 Jan 2002 15:14:51 +1100 Received: from localhost (ivanr@localhost) by omen.melbourne.sgi.com (SGI-8.9.3/8.9.3) with ESMTP id PAA04000; Fri, 18 Jan 2002 15:14:51 +1100 (EST) X-Authentication-Warning: omen.melbourne.sgi.com: ivanr owned process doing -bs Date: Fri, 18 Jan 2002 15:14:50 +1100 X-X-Sender: ivanr@omen.melbourne.sgi.com To: Mike Burger cc: linux-xfs@oss.sgi.com Subject: Re: xfsdump dumps core? In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 909 Lines: 37 On Thu, 17 Jan 2002, Mike Burger wrote: > Well, I just compiled xfsdump from the latest CVS, and still dumped. If you could send the core file to me, I'll take a look at it. Thanks, Ivan > On Thu, 17 Jan 2002, Eric Sandeen wrote: > > > FWIW, I'll get updated userspace RPMs at > > ftp://oss.sgi.com/projects/xfs/command_rpms > > > > in the next few minutes... > > > > but what's there now is pretty up to date (xfsprogs 1.3.13, for example). > > > > -Eric > > > > > > On Thu, 17 Jan 2002, Mike Burger wrote: > > > > > Never mind...I followed the CVS instructions on the web site, and am > > > running a "make install-dev" right now, so that I can compile the xfsdump > > > and xfsprogs utilities. > > > > > > On Thu, 17 Jan 2002, Mike Burger wrote: > > > > > > > Aaahhh...I guess I live by the RPM, since I'm running a Red Hat system > > > > (7.1 on this particular box). -- Ivan Rayner ivanr@sgi.com From owner-linux-xfs@oss.sgi.com Fri Jan 18 01:03:25 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0I93PC14555 for linux-xfs-outgoing; Fri, 18 Jan 2002 01:03:25 -0800 Received: from burgers.bubbanfriends.org (IDENT:postfix@burgers.bubbanfriends.org [216.140.122.113]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0I93JP14533 for ; Fri, 18 Jan 2002 01:03:19 -0800 Received: by burgers.bubbanfriends.org (Postfix, from userid 500) id 0B6A5835FE9; Fri, 18 Jan 2002 03:03:18 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by burgers.bubbanfriends.org (Postfix) with ESMTP id 08CCC280045C; Fri, 18 Jan 2002 03:03:18 -0500 (EST) Date: Fri, 18 Jan 2002 03:03:17 -0500 (EST) From: Mike Burger To: Cc: Subject: Re: xfsdump dumps core? In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 1012 Lines: 39 On its way...thanks. On Fri, 18 Jan 2002 ivanr@sgi.com wrote: > On Thu, 17 Jan 2002, Mike Burger wrote: > > > Well, I just compiled xfsdump from the latest CVS, and still dumped. > > If you could send the core file to me, I'll take a look at it. > > Thanks, > Ivan > > > > On Thu, 17 Jan 2002, Eric Sandeen wrote: > > > > > FWIW, I'll get updated userspace RPMs at > > > ftp://oss.sgi.com/projects/xfs/command_rpms > > > > > > in the next few minutes... > > > > > > but what's there now is pretty up to date (xfsprogs 1.3.13, for example). > > > > > > -Eric > > > > > > > > > On Thu, 17 Jan 2002, Mike Burger wrote: > > > > > > > Never mind...I followed the CVS instructions on the web site, and am > > > > running a "make install-dev" right now, so that I can compile the xfsdump > > > > and xfsprogs utilities. > > > > > > > > On Thu, 17 Jan 2002, Mike Burger wrote: > > > > > > > > > Aaahhh...I guess I live by the RPM, since I'm running a Red Hat system > > > > > (7.1 on this particular box). > > From owner-linux-xfs@oss.sgi.com Fri Jan 18 01:41:13 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0I9fDd15193 for linux-xfs-outgoing; Fri, 18 Jan 2002 01:41:13 -0800 Received: from mxzilla2.xs4all.nl (mxzilla2.xs4all.nl [194.109.6.50]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0I9f9P15171 for ; Fri, 18 Jan 2002 01:41:09 -0800 Received: from xs4.xs4all.nl (knuffie@xs4.xs4all.nl [194.109.6.45]) by mxzilla2.xs4all.nl (8.12.0/8.12.0) with ESMTP id g0I8f5SP059945; Fri, 18 Jan 2002 09:41:06 +0100 (CET) Received: from localhost (knuffie@localhost) by xs4.xs4all.nl (8.9.0/8.9.0) with ESMTP id JAA27523; Fri, 18 Jan 2002 09:41:05 +0100 (CET) Date: Fri, 18 Jan 2002 09:41:05 +0100 (CET) From: Seth Mos To: Florin Andrei cc: Linux XFS Mailing List Subject: Re: Developerworks XFS introduction. In-Reply-To: <1011296589.14331.82.camel@stantz.corp.sgi.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 653 Lines: 21 On 17 Jan 2002, Florin Andrei wrote: > On Wed, 2002-01-16 at 04:20, Federico Sevilla III wrote: > > > > (I'm not Steve Lord but ...) I just read the article and everything seems > > to be in order. Nothing quite new (since I've been using XFS for awhile). > > However I really like how the NULL issue was explained. I never really > > looked at it that way (always saw it as a ... problem). And that bit > > Yeah, Daniel Robbins rockzz! :o) > > > quoting Steve Lord on a "coming soon" patch to improve delete performance > > was exciting. :) > > Indeed, that would be a big thing. Very, very nice. My squid cache looks forward to it :-) Cheers From owner-linux-xfs@oss.sgi.com Fri Jan 18 02:15:12 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0IAFCA16018 for linux-xfs-outgoing; Fri, 18 Jan 2002 02:15:12 -0800 Received: from mxzilla2.xs4all.nl (mxzilla2.xs4all.nl [194.109.6.50]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0IAF7P15996 for ; Fri, 18 Jan 2002 02:15:07 -0800 Received: from xs4.xs4all.nl (knuffie@xs4.xs4all.nl [194.109.6.45]) by mxzilla2.xs4all.nl (8.12.0/8.12.0) with ESMTP id g0I9F1RZ076081; Fri, 18 Jan 2002 10:15:01 +0100 (CET) Received: from localhost (knuffie@localhost) by xs4.xs4all.nl (8.9.0/8.9.0) with ESMTP id KAA29559; Fri, 18 Jan 2002 10:15:00 +0100 (CET) Date: Fri, 18 Jan 2002 10:15:00 +0100 (CET) From: Seth Mos To: Adam Hupp cc: linux-xfs@oss.sgi.com, Adrian Pederson Subject: Re: Frequent hangs with 2.4.9-xfs-1.0.2 In-Reply-To: <20020117200246.B1859@upl.cs.wisc.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 1007 Lines: 24 On Thu, 17 Jan 2002, Adam Hupp wrote: > We have been experiencing frequent hangs with our Redhat 7.2 system > running the 2.4.9 RH7.2 XFS 1.0.2 kernel rpm. There is nothing in the > logs, and the machine usually stops dead in it's tracks. No console > access, no ping, nothing. One time we still had NFS access while the > rest of the machine (console, ssh, etc ) was inaccessable. I seem to be > able to trigger it by running lots of fs load, but have not been able to > reliably track it down to a single cause. While trying parrallel cp -r > (local) and grep'ing through the fs (over nfs) it eventually hung. > > Is there anything I can do to narrow down the source of the problem? We > will be trying the 2.4.14 XFS 1.0.2 kernel. I suspect the 3ware controllers are the possible problem factor here. Hardware raid 5 on the 3ware cards was not always the strongest point of the card although the newer 7xxx series is reported to be much better. Have you tried using a newer driver?0 Cheers From owner-linux-xfs@oss.sgi.com Fri Jan 18 04:20:02 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0ICK2019853 for linux-xfs-outgoing; Fri, 18 Jan 2002 04:20:02 -0800 Received: from schritz.de (mail@schritz.de [62.208.140.31]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0ICJtP19829 for ; Fri, 18 Jan 2002 04:19:55 -0800 Received: from gate-spg.netbeat.de ([62.208.140.34] helo=skeletor) by schritz.de with asmtp (Exim 3.33 #1 (Debian)) id 16RX7a-000697-00 for ; Fri, 18 Jan 2002 12:23:46 +0100 From: "Johannes Schritz" To: Subject: kernel oops with linux 2.4.17-xfs Date: Fri, 18 Jan 2002 12:19:36 +0100 Message-ID: <000501c1a012$03562fc0$0264a8c0@skeletor> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2616 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 1847 Lines: 44 Hello, I experienced the following kernel oops today, which seems to be related to the XFS file system. I upgraded to kernel 2.4.17-xfs from 2.4.16-xfs yesterday, before, we did not have any crashes due to a kernel oops (coincidence?). Here's the entry from messages: Jan 18 04:22:04 jules kernel: printing eip: Jan 18 04:22:04 jules kernel: c012d0af Jan 18 04:22:04 jules kernel: Oops: 0000 Jan 18 04:22:04 jules kernel: CPU: 0 Jan 18 04:22:04 jules kernel: EIP: 0010:[kfree+63/144] Not tainted Jan 18 04:22:04 jules kernel: EFLAGS: 00010002 Jan 18 04:22:04 jules kernel: eax: 00000000 ebx: 00000001 ecx: d87c6830 edx: c1000000 Jan 18 04:22:04 jules kernel: esi: f889a000 edi: 00000286 ebp: 00000000 esp: f7be5ecc Jan 18 04:22:04 jules kernel: ds: 0018 es: 0018 ss: 0018 Jan 18 04:22:04 jules kernel: Process kupdated (pid: 6, stackpage=f7be5000) Jan 18 04:22:04 jules kernel: Stack: c30dfc44 c30dfbf8 00000000 f889a000 c01f327e f889a000 c01c777e f889a000 Jan 18 04:22:04 jules kernel: 00020000 c30dfbf8 c30dfbf8 00000001 c01c77f5 c30dfbf8 00000000 c30dfbf8 Jan 18 04:22:04 jules kernel: c01c4552 c30dfbf8 00000001 c01e1e0a c30dfbf8 f6f359c0 c30dfbf8 f23fdb40 Jan 18 04:22:04 jules kernel: Call Trace: [kmem_free+30/48] [xfs_idestroy_fork+126/192] [xfs_idestroy+53/144] [xfs_ireclaim+98/112] [xfs_finish_reclaim+282/304] Jan 18 04:22:04 jules kernel: [xfs_syncsub+498/3056] [xfs_sync+21/32] [linvfs_write_super+43/48] [sync_supers+216/272] [sync_old_buffers+47/144] [kupdate+282/288] Jan 18 04:22:04 jules kernel: [kernel_thread+40/64] Jan 18 04:22:04 jules kernel: Jan 18 04:22:04 jules kernel: Code: 8b 13 89 d0 3b 43 04 73 08 89 74 83 08 ff 03 eb 36 8b 41 28 I don't know which other information might be helpful, if there's anything else I could supply to help, please tell me. -- Johannes From owner-linux-xfs@oss.sgi.com Fri Jan 18 04:36:17 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0ICaH920193 for linux-xfs-outgoing; Fri, 18 Jan 2002 04:36:17 -0800 Received: from localhost.localdomain (mail.sgo.es [195.235.172.6]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0ICaCP20171 for ; Fri, 18 Jan 2002 04:36:13 -0800 Received: from there (nuko [127.0.0.1]) by localhost.localdomain (8.11.6/8.11.6) with SMTP id g0IBa5M11461 for ; Fri, 18 Jan 2002 12:36:06 +0100 Message-Id: <200201181136.g0IBa5M11461@localhost.localdomain> Content-Type: text/plain; charset="iso-8859-15" From: Miguel Angel de Vega To: linux-xfs@oss.sgi.com Subject: problems with 2.4.14 rpms instalation Date: Fri, 18 Jan 2002 12:36:05 +0100 X-Mailer: KMail [version 1.3.1] MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 549 Lines: 20 Hi! I've tried to update my 2.4.9-XFS kernel to 2.4.14-XFS. But when I make a rpm -ihv kernel-2.4.14-SGI_XFS_1.0.2.i686.rpm i don't get an initrd-xxxxx.img to be done. I tried with mkinitrd and I got a .img, so I edited my grub.conf to get it to use both 2.4.14 files (vmlinuz & .img). When I rebooted the computer I got this error: Kernel Panic No init found. Try passing init=option to kernel. I'm almost sure that I made the initrd file badly, or something like that. I did't get such problems with 2.4.9-XFS. ?Any suggestions? Thanks From owner-linux-xfs@oss.sgi.com Fri Jan 18 04:56:15 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0ICuFm20729 for linux-xfs-outgoing; Fri, 18 Jan 2002 04:56:15 -0800 Received: from gk.hm.epigenomics.net (qmailr@gk.hm.epigenomics.net [212.121.137.90]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0ICuBP20706 for ; Fri, 18 Jan 2002 04:56:11 -0800 Received: (qmail 25674 invoked from network); 18 Jan 2002 11:56:07 -0000 Received: from raman.epigenomics.epi (qmailr@192.168.2.2) by salam.epigenomics.epi with SMTP; 18 Jan 2002 11:56:07 -0000 Received: (qmail 27266 invoked from network); 18 Jan 2002 11:56:05 -0000 Received: from broglie.epigenomics.epi (qmailr@192.168.1.5) by raman.epigenomics.epi with SMTP; 18 Jan 2002 11:56:05 -0000 Received: (qmail 12164 invoked by uid 9); 18 Jan 2002 11:56:05 -0000 From: Robert Sander Reply-To: Robert Sander X-Newsgroups: epi.ml.linux.xfs Subject: Re: kernel oops with linux 2.4.17-xfs Date: Fri, 18 Jan 2002 11:56:05 +0000 (UTC) Organization: Epigenomics AG Message-ID: References: <000501c1a012$03562fc0$0264a8c0@skeletor> X-Complaints-To: usenet@epigenomics.com User-Agent: slrn/0.9.7.3 (Linux) To: linux-xfs@oss.sgi.com Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 720 Lines: 19 On Fri, 18 Jan 2002 11:21:18 +0000 (UTC), "Johannes Schritz" wrote: > Hello, > > I experienced the following kernel oops today, which seems to be related > to the XFS file system. I upgraded to kernel 2.4.17-xfs from 2.4.16-xfs > yesterday, before, we did not have any crashes due to a kernel oops Have you used the patch for 2.4.17 or the CVS? The patch is out of date, there are some problems fixed in the CVS. Maybe the patch should be removed? Greetings -- Robert Sander Computer Scientist Epigenomics AG Bioinformatics R&D www.epigenomics.com Kastanienallee 24 +493024345330 10435 Berlin From owner-linux-xfs@oss.sgi.com Fri Jan 18 04:59:01 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0ICx1i20974 for linux-xfs-outgoing; Fri, 18 Jan 2002 04:59:01 -0800 Received: from stine.vestdata.no (IDENT:0@stine.vestdata.no [195.204.68.10]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0ICwvP20952 for ; Fri, 18 Jan 2002 04:58:57 -0800 Received: (from ragnark@localhost) by stine.vestdata.no (8.11.6/8.11.2) id g0IBwmr09910; Fri, 18 Jan 2002 12:58:48 +0100 Date: Fri, 18 Jan 2002 12:58:48 +0100 From: =?iso-8859-1?Q?Ragnar_Kj=F8rstad?= To: Miguel Angel de Vega Cc: linux-xfs@oss.sgi.com Subject: Re: problems with 2.4.14 rpms instalation Message-ID: <20020118125848.A3522@vestdata.no> References: <200201181136.g0IBa5M11461@localhost.localdomain> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <200201181136.g0IBa5M11461@localhost.localdomain>; from mvega@sgo.es on Fri, Jan 18, 2002 at 12:36:05PM +0100 X-MIME-Autoconverted: from 8bit to quoted-printable by stine.vestdata.no id g0IBwmr09910 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id g0ICwwP20953 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 513 Lines: 18 On Fri, Jan 18, 2002 at 12:36:05PM +0100, Miguel Angel de Vega wrote: > Kernel Panic > No init found. Try passing init=option to kernel. > > I'm almost sure that I made the initrd file badly, or something like that. > I did't get such problems with 2.4.9-XFS. init is not the same as initrd. Init is the first process to be started by the kernel, normally /sbin/init. The message indicates that you used the wrong root-filesystem, so the kernel is unable to find /sbin/init. -- Ragnar Kjørstad Big Storage From owner-linux-xfs@oss.sgi.com Fri Jan 18 05:05:19 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0ID5JO21286 for linux-xfs-outgoing; Fri, 18 Jan 2002 05:05:19 -0800 Received: from schritz.de (mail@schritz.de [62.208.140.31]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0ID5HP21264 for ; Fri, 18 Jan 2002 05:05:17 -0800 Received: from gate-spg.netbeat.de ([62.208.140.34] helo=skeletor) by schritz.de with asmtp (Exim 3.33 #1 (Debian)) id 16RXpk-0006Gs-00 for ; Fri, 18 Jan 2002 13:09:24 +0100 From: "Johannes Schritz" To: Subject: Re: kernel oops with linux 2.4.17-xfs Date: Fri, 18 Jan 2002 13:05:13 +0100 Message-ID: <000601c1a018$62cf0c00$0264a8c0@skeletor> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2616 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 42 Lines: 5 No, I used the CVS source. -- Johannes From owner-linux-xfs@oss.sgi.com Fri Jan 18 05:12:11 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0IDCB821543 for linux-xfs-outgoing; Fri, 18 Jan 2002 05:12:11 -0800 Received: from mail.broadpark.no (217-13-4-9.dd.nextgentel.com [217.13.4.9]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0IDC9P21521 for ; Fri, 18 Jan 2002 05:12:09 -0800 Received: from online.no (213-187-164-240.dd.nextgentel.com [213.187.164.240]) by mail.broadpark.no (Postfix) with ESMTP id 6CCC77F91 for ; Fri, 18 Jan 2002 13:11:58 +0100 (MET) Message-ID: <3C480F6D.C278596C@online.no> Date: Fri, 18 Jan 2002 13:05:01 +0100 From: Knut J Bjuland X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.4.17-xfs i686) X-Accept-Language: en MIME-Version: 1.0 To: linux-xfs@oss.sgi.com Subject: XFS in redhat, mainstream linux 2.5.X Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 81 Lines: 3 How far is XFS from being part of Linux 2.5.X tree, or Redhat 8.x distribution. From owner-linux-xfs@oss.sgi.com Fri Jan 18 05:32:31 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0IDWVd23232 for linux-xfs-outgoing; Fri, 18 Jan 2002 05:32:31 -0800 Received: from rj.sgi.com (rj.SGI.COM [204.94.215.100]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0IDWRP23191 for ; Fri, 18 Jan 2002 05:32:27 -0800 Received: from zeus-e8.americas.sgi.com (zeus-e8.americas.sgi.com [128.162.8.103]) by rj.sgi.com (8.11.4/8.11.4/linux-outbound_gateway-1.1) with ESMTP id g0ICWKY02583 for ; Fri, 18 Jan 2002 04:32:20 -0800 Received: from tulip-e185.americas.sgi.com (tulip-e185.americas.sgi.com [128.162.185.208]) by zeus-e8.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id GAA48477; Fri, 18 Jan 2002 06:31:04 -0600 (CST) Received: from sgi.com (gzxyh2uIv19DL2mbNZb+fxrZe9K2yxfW@lord-h1.americas.sgi.com [206.11.101.42]) by tulip-e185.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.7) with ESMTP id GAA26944; Fri, 18 Jan 2002 06:31:04 -0600 (CST) Message-ID: <3C4816AF.3060807@sgi.com> Date: Fri, 18 Jan 2002 06:35:59 -0600 From: Stephen Lord User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.6) Gecko/20011120 X-Accept-Language: en-us MIME-Version: 1.0 To: Knut J Bjuland CC: linux-xfs@oss.sgi.com Subject: Re: XFS in redhat, mainstream linux 2.5.X References: <3C480F6D.C278596C@online.no> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 499 Lines: 17 Knut J Bjuland wrote: >How far is XFS from being part of Linux 2.5.X tree, or Redhat 8.x >distribution. > Right now it is a matter of finding the time to engage Linus, I am working flat out on about five other different things right now. If I can see a stretch of time where I am not totally overloaded then we can try the process again, I expect the process to take a fair amount of interaction - Linus will probably ask for changes, and I need to be prepared to react fairly quickly. Steve From owner-linux-xfs@oss.sgi.com Fri Jan 18 05:48:22 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0IDmM623705 for linux-xfs-outgoing; Fri, 18 Jan 2002 05:48:22 -0800 Received: from porsta.cs.Helsinki.FI (root@porsta.cs.Helsinki.FI [128.214.48.124]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0IDmHP23683 for ; Fri, 18 Jan 2002 05:48:17 -0800 Received: from melkki.cs.Helsinki.FI (sslwrap@localhost [127.0.0.1]) by porsta.cs.Helsinki.FI (8.11.6/8.11.6) with ESMTP id g0ICmDp08783; Fri, 18 Jan 2002 14:48:13 +0200 Received: (from hhaataja@localhost) by melkki.cs.Helsinki.FI (8.11.6/8.11.2) id g0ICm8G03447; Fri, 18 Jan 2002 14:48:08 +0200 Date: Fri, 18 Jan 2002 14:48:08 +0200 From: Harri Haataja To: Miguel Angel de Vega Cc: linux-xfs@oss.sgi.com Subject: Re: problems with 2.4.14 rpms instalation Message-ID: <20020118144808.G20212@cs.helsinki.fi> Mail-Followup-To: Miguel Angel de Vega , linux-xfs@oss.sgi.com References: <200201181136.g0IBa5M11461@localhost.localdomain> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200201181136.g0IBa5M11461@localhost.localdomain>; from mvega@sgo.es on Fri, Jan 18, 2002 at 12:36:05PM +0100 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 1062 Lines: 28 On Fri, Jan 18, 2002 at 12:36:05PM +0100, Miguel Angel de Vega wrote: > I've tried to update my 2.4.9-XFS kernel to 2.4.14-XFS. But when I make a > > rpm -ihv kernel-2.4.14-SGI_XFS_1.0.2.i686.rpm > > i don't get an initrd-xxxxx.img to be done. I tried with mkinitrd and I got a > .img, so I edited my grub.conf to get it to use both 2.4.14 files (vmlinuz & > .img). When I rebooted the computer I got this error: > > Kernel Panic > No init found. Try passing init=option to kernel. > > I'm almost sure that I made the initrd file badly, or something like that. > I did't get such problems with 2.4.9-XFS. any other errors above that? About pivot root and, for me, "cannot mount root ext3" something? The new one doesn't have ext3 module and that's a major pain for me (as not all my systems are all-XFS but many are migrated and ext2 has turned into ext3 nicely). Just a guess. -- Hey, you're right. I don't want to call a destructor on my objects, I want to call a *destroyer*. Gozer has come for your memory, little PersistentNode! -- Joel Gluth From owner-linux-xfs@oss.sgi.com Fri Jan 18 05:57:59 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0IDvxN23993 for linux-xfs-outgoing; Fri, 18 Jan 2002 05:57:59 -0800 Received: from zok.sgi.com (zok.sgi.com [204.94.215.101]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0IDvsP23969 for ; Fri, 18 Jan 2002 05:57:54 -0800 Received: from zeus-e8.americas.sgi.com (zeus-e8.americas.sgi.com [128.162.8.103]) by zok.sgi.com (8.11.4/8.11.4/linux-outbound_gateway-1.1) with ESMTP id g0ICvlo27459 for ; Fri, 18 Jan 2002 04:57:47 -0800 Received: from tulip-e185.americas.sgi.com (tulip-e185.americas.sgi.com [128.162.185.208]) by zeus-e8.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id GAA50188; Fri, 18 Jan 2002 06:56:31 -0600 (CST) Received: from sgi.com (YqTD1R80mvCQLGFR3AmWr8lM18IHWGC6@lord-h1.americas.sgi.com [206.11.101.42]) by tulip-e185.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.7) with ESMTP id GAA26364; Fri, 18 Jan 2002 06:56:30 -0600 (CST) Message-ID: <3C481CA5.9030607@sgi.com> Date: Fri, 18 Jan 2002 07:01:25 -0600 From: Stephen Lord User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.6) Gecko/20011120 X-Accept-Language: en-us MIME-Version: 1.0 To: Miguel Angel de Vega CC: linux-xfs@oss.sgi.com Subject: Re: problems with 2.4.14 rpms instalation References: <200201181136.g0IBa5M11461@localhost.localdomain> Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 875 Lines: 32 Miguel Angel de Vega wrote: >Hi! > >I've tried to update my 2.4.9-XFS kernel to 2.4.14-XFS. But when I make a > >rpm -ihv kernel-2.4.14-SGI_XFS_1.0.2.i686.rpm > >i don't get an initrd-xxxxx.img to be done. I tried with mkinitrd and I got a >.img, so I edited my grub.conf to get it to use both 2.4.14 files (vmlinuz & >.img). When I rebooted the computer I got this error: > >Kernel Panic >No init found. Try passing init=option to kernel. > >I'm almost sure that I made the initrd file badly, or something like that. >I did't get such problems with 2.4.9-XFS. > >?Any suggestions? > >Thanks > Any XFS filesystems involved in the boot process? Unless you have a special version of grub that is not going to work. Also, if this is related to your LVM striping performance, try using the cvs kernel and building your own, these rpms are now really out of date. Steve From owner-linux-xfs@oss.sgi.com Fri Jan 18 07:41:37 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0IFfbF29743 for linux-xfs-outgoing; Fri, 18 Jan 2002 07:41:37 -0800 Received: from rover (rover.mkp.net [209.217.122.9]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0IFfXP29721 for ; Fri, 18 Jan 2002 07:41:33 -0800 Received: from localhost.localdomain ([127.0.0.1] helo=rover.mkp.net) by rover with esmtp (Exim 3.33 #1) id 16RaCt-00075B-00; Fri, 18 Jan 2002 09:41:28 -0500 Received: (from mkp@localhost) by rover.mkp.net (8.11.6/8.9.3) id g0IEfG205903; Fri, 18 Jan 2002 09:41:16 -0500 X-Authentication-Warning: jaguar.wave.mkp.net: mkp set sender to mkp@mkp.net using -f To: Miguel Angel de Vega Cc: linux-xfs@oss.sgi.com Subject: Re: problems with 2.4.14 rpms instalation References: <200201181136.g0IBa5M11461@localhost.localdomain> From: "Martin K. Petersen" Organization: Linuxcare, Inc. Date: 18 Jan 2002 09:41:14 -0500 In-Reply-To: <200201181136.g0IBa5M11461@localhost.localdomain> Message-ID: User-Agent: Gnus/5.0808 (Gnus v5.8.8) XEmacs/21.4 (Civil Service) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 408 Lines: 12 >>>>> "Miguel" == Miguel Angel de Vega writes: Miguel> When I rebooted the computer I got this error: Miguel> Kernel Panic No init found. Try passing init=option to kernel. Make sure you have a /initrd directory. -- Martin K. Petersen, Principal Linux Consultant, Linuxcare, Inc. mkp@linuxcare.com, http://www.linuxcare.com/ SGI XFS for Linux Developer, http://oss.sgi.com/projects/xfs/ From owner-linux-xfs@oss.sgi.com Fri Jan 18 10:48:54 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0IImst04971 for linux-xfs-outgoing; Fri, 18 Jan 2002 10:48:54 -0800 Received: from data.upl.cs.wisc.edu (IDENT:root@data.upl.cs.wisc.edu [128.105.45.42]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0IImlP04948 for ; Fri, 18 Jan 2002 10:48:48 -0800 Received: (from hupp@localhost) by data.upl.cs.wisc.edu (8.10.2/8.10.2) id g0IHmf419682; Fri, 18 Jan 2002 11:48:41 -0600 Date: Fri, 18 Jan 2002 11:48:40 -0600 From: Adam Hupp To: Seth Mos Cc: linux-xfs@oss.sgi.com, Adrian Pederson Subject: Re: Frequent hangs with 2.4.9-xfs-1.0.2 Message-ID: <20020118114840.B19451@upl.cs.wisc.edu> References: <20020117200246.B1859@upl.cs.wisc.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2i In-Reply-To: ; from Seth Mos on Fri, Jan 18, 2002 at 10:15:00AM +0100 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 563 Lines: 19 On Fri, Jan 18, 2002 at 10:15:00AM +0100, Seth Mos wrote: > I suspect the 3ware controllers are the possible problem factor here. This is appearing in the logs after the last crash: kernel: XFS: SB read failed kernel: I/O error in filesystem ("md(9,0)") meta-data dev 0x900 block 0x0 kernel: ("xfs_readsb") error 5 buf count 512 That would point to a problem with the 3ware driver or cards, correct? > Have you tried using a newer driver? We are running the most recent available driver but I am not sure if the firmware has been updated. -Adam From owner-linux-xfs@oss.sgi.com Fri Jan 18 11:34:00 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0IJY0v06093 for linux-xfs-outgoing; Fri, 18 Jan 2002 11:34:00 -0800 Received: from angelica.keck.waisman.wisc.edu (angelica.keck.waisman.wisc.edu [128.104.232.125]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0IJXtP06065 for ; Fri, 18 Jan 2002 11:33:55 -0800 Received: (from pederson@localhost) by angelica.keck.waisman.wisc.edu (8.11.6/8.11.6) id g0IIXaG03921; Fri, 18 Jan 2002 12:33:36 -0600 Date: Fri, 18 Jan 2002 12:33:36 -0600 From: Adrian Pederson To: Adam Hupp Cc: Seth Mos , linux-xfs@oss.sgi.com Subject: Re: Frequent hangs with 2.4.9-xfs-1.0.2 Message-ID: <20020118123336.C2514@angelica.keck.waisman.wisc.edu> References: <20020117200246.B1859@upl.cs.wisc.edu> <20020118114840.B19451@upl.cs.wisc.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20020118114840.B19451@upl.cs.wisc.edu>; from Adam Hupp on Fri, Jan 18, 2002 at 11:48:40AM -0600 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 1457 Lines: 36 On Fri, Jan 18, 2002 at 11:48:40AM -0600, Adam Hupp wrote: >On Fri, Jan 18, 2002 at 10:15:00AM +0100, Seth Mos wrote: > >> I suspect the 3ware controllers are the possible problem factor here. > >This is appearing in the logs after the last crash: > >kernel: XFS: SB read failed >kernel: I/O error in filesystem ("md(9,0)") meta-data dev 0x900 block 0x0 >kernel: ("xfs_readsb") error 5 buf count 512 > >That would point to a problem with the 3ware driver or cards, correct? Ignore these messages, they were from my messing with one of the arrays, it changed around the /dev/sd*1 naming and broke the raidtab. >> Have you tried using a newer driver? > >We are running the most recent available driver but I am not sure if the >firmware has been updated. The 3ware driver is 1.02.00.008, firmware is 1.03.09.027, both are the latest. A couple other data points, it only crashes during business hours, when the load tends to be higher. I ran the machine for a week on 100 Mb Ethernet without a single crash doing benchmarks and copying ~400 GB of data, only since moving to the e1000 NIC has it been locking up. I just moved the interface back to 100 Mb, wait and see what happens... -- Adrian Pederson Voice: 608-265-6608 System Administrator FAX: 608-265-8737 W. M. Keck Laboratory for Functional Brain Imaging and Behavior Waisman Center University of Wisconsin - Madison From owner-linux-xfs@oss.sgi.com Fri Jan 18 11:54:54 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0IJssG06515 for linux-xfs-outgoing; Fri, 18 Jan 2002 11:54:54 -0800 Received: from microsharp.com (mail.microsharp.com [206.190.130.135]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0IJsoP06492 for ; Fri, 18 Jan 2002 11:54:51 -0800 Received: from juniper.intra.microsharp.com (asl.microsharp.com [206.190.130.132]) by microsharp.com (8.11.2/8.11.2) with ESMTP id g0IIt1131596 for ; Fri, 18 Jan 2002 10:55:01 -0800 Received: from juniper.intra.microsharp.com (karlheg@localhost [127.0.0.1]) by juniper.intra.microsharp.com (8.12.1/8.12.1/Debian -5) with ESMTP id g0IIshVT025308 for ; Fri, 18 Jan 2002 10:54:43 -0800 Received: (from karlheg@localhost) by juniper.intra.microsharp.com (8.12.1/8.12.1/Debian -5) id g0IIshN4025304; Fri, 18 Jan 2002 10:54:43 -0800 To: linux-xfs@oss.sgi.com Subject: Shrink an XFS filesystem? (LVM) X-Face: 1v=v?=]<7%cW&OL:Z"GCcdmIN&wp)w|1EKzyC6?qaX;55wwjPfKTm\'7x-gd+KEd`(o&(EQ%(B4]6sZ$|e_FBGTJOvJtHUM>flSNQqfdw.jYZ$jnCERoAX*{4lEJm?EB#V_<2\-#5%#Du/ExQR)juedX>!Cq#;UoAo?|Oo~BX@!fwIX From: karlheg@microsharp.com (Karl M. Hegbloom) Date: 18 Jan 2002 10:54:42 -0800 Message-ID: <871ygn8p71.fsf@juniper.intra.microsharp.com> User-Agent: Gnus/5.0808 (Gnus v5.8.8) XEmacs/21.4 (Artificial Intelligence) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 226 Lines: 7 Is it possible (now or ever) to shrink an XFS filesystem? -- mailto: (Karl M. Hegbloom) karlheg@microsharp.com Free the Software http://www.debian.org/social_contract http://www.microsharp.com phone://USA/WA/360-260-2066 From owner-linux-xfs@oss.sgi.com Fri Jan 18 11:59:54 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0IJxs906756 for linux-xfs-outgoing; Fri, 18 Jan 2002 11:59:54 -0800 Received: from chaos.egr.duke.edu (chaos.egr.duke.edu [152.3.195.82]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0IJxoP06733 for ; Fri, 18 Jan 2002 11:59:50 -0800 Received: from localhost (jlb@localhost) by chaos.egr.duke.edu (8.11.6/8.11.6) with ESMTP id g0IIxft08596; Fri, 18 Jan 2002 13:59:45 -0500 X-Authentication-Warning: chaos.egr.duke.edu: jlb owned process doing -bs Date: Fri, 18 Jan 2002 13:59:41 -0500 (EST) From: Joshua Baker-LePain X-X-Sender: jlb@chaos.egr.duke.edu To: "Karl M. Hegbloom" cc: linux-xfs@oss.sgi.com Subject: Re: Shrink an XFS filesystem? (LVM) In-Reply-To: <871ygn8p71.fsf@juniper.intra.microsharp.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 254 Lines: 11 On 18 Jan 2002 at 10:54am, Karl M. Hegbloom wrote > Is it possible (now or ever) to shrink an XFS filesystem? > http://oss.sgi.com/projects/xfs/faq.html#resizexfspartition -- Joshua Baker-LePain Department of Biomedical Engineering Duke University From owner-linux-xfs@oss.sgi.com Fri Jan 18 12:02:44 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0IK2if06978 for linux-xfs-outgoing; Fri, 18 Jan 2002 12:02:44 -0800 Received: from Cantor.suse.de (ns.suse.de [213.95.15.193]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0IK2fP06955 for ; Fri, 18 Jan 2002 12:02:41 -0800 Received: from Hermes.suse.de (Hermes.suse.de [213.95.15.136]) by Cantor.suse.de (Postfix) with ESMTP id 1E4CE1E734; Fri, 18 Jan 2002 20:02:34 +0100 (MET) Date: Fri, 18 Jan 2002 20:02:22 +0100 From: Andi Kleen To: "Karl M. Hegbloom" Cc: linux-xfs@oss.sgi.com Subject: Re: Shrink an XFS filesystem? (LVM) Message-ID: <20020118200222.A26255@wotan.suse.de> References: <871ygn8p71.fsf@juniper.intra.microsharp.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <871ygn8p71.fsf@juniper.intra.microsharp.com> User-Agent: Mutt/1.3.22.1i Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 317 Lines: 9 On Fri, Jan 18, 2002 at 10:54:42AM -0800, Karl M. Hegbloom wrote: > Is it possible (now or ever) to shrink an XFS filesystem? Currently it isn't, other than dump/mkfs/restore Ever only if someone implements it. AFAIK there are no plans for it, but of course the source is available if someone is motivated. -Andi From owner-linux-xfs@oss.sgi.com Fri Jan 18 12:09:52 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0IK9qr07280 for linux-xfs-outgoing; Fri, 18 Jan 2002 12:09:52 -0800 Received: from rj.sgi.com (rj.SGI.COM [204.94.215.100]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0IK9mP07254 for ; Fri, 18 Jan 2002 12:09:48 -0800 Received: from zeus-e8.americas.sgi.com (zeus-e8.americas.sgi.com [128.162.8.103]) by rj.sgi.com (8.11.4/8.11.4/linux-outbound_gateway-1.1) with ESMTP id g0IJ9fY31576 for ; Fri, 18 Jan 2002 11:09:41 -0800 Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by zeus-e8.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id NAA55048; Fri, 18 Jan 2002 13:08:24 -0600 (CST) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id NAA59291; Fri, 18 Jan 2002 13:08:24 -0600 (CST) Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id g0IJ8Fd24406; Fri, 18 Jan 2002 13:08:15 -0600 Subject: Re: Shrink an XFS filesystem? (LVM) From: Steve Lord To: Andi Kleen Cc: "Karl M. Hegbloom" , linux-xfs@oss.sgi.com In-Reply-To: <20020118200222.A26255@wotan.suse.de> References: <871ygn8p71.fsf@juniper.intra.microsharp.com> <20020118200222.A26255@wotan.suse.de> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/1.0.1 Date: 18 Jan 2002 13:08:15 -0600 Message-Id: <1011380895.23885.7.camel@jen.americas.sgi.com> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 590 Lines: 19 On Fri, 2002-01-18 at 13:02, Andi Kleen wrote: > On Fri, Jan 18, 2002 at 10:54:42AM -0800, Karl M. Hegbloom wrote: > > Is it possible (now or ever) to shrink an XFS filesystem? > > Currently it isn't, other than dump/mkfs/restore > Ever only if someone implements it. AFAIK there are no plans for it, > but of course the source is available if someone is motivated. Might that in place filesystem converter work for this? Steve > > -Andi -- Steve Lord voice: +1-651-683-3511 Principal Engineer, Filesystem Software email: lord@sgi.com From owner-linux-xfs@oss.sgi.com Fri Jan 18 12:20:43 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0IKKhW07624 for linux-xfs-outgoing; Fri, 18 Jan 2002 12:20:43 -0800 Received: from zok.sgi.com (zok.sgi.com [204.94.215.101]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0IKKdP07594 for ; Fri, 18 Jan 2002 12:20:39 -0800 Received: from zeus-e8.americas.sgi.com (zeus-e8.americas.sgi.com [128.162.8.103]) by zok.sgi.com (8.11.4/8.11.4/linux-outbound_gateway-1.1) with ESMTP id g0IJKWo24094 for ; Fri, 18 Jan 2002 11:20:32 -0800 Received: from poppy-e185.americas.sgi.com (poppy-e185.americas.sgi.com [128.162.185.207]) by zeus-e8.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id NAA55194; Fri, 18 Jan 2002 13:19:16 -0600 (CST) Received: from stout.americas.sgi.com (stout.americas.sgi.com [128.162.187.5]) by poppy-e185.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.7) with ESMTP id NAA08475; Fri, 18 Jan 2002 13:19:15 -0600 (CST) Subject: Re: Shrink an XFS filesystem? (LVM) From: Eric Sandeen To: Steve Lord Cc: linux-xfs@oss.sgi.com, karlheg@microsharp.com, ak@suse.de In-Reply-To: <1011380895.23885.7.camel@jen.americas.sgi.com> References: <871ygn8p71.fsf@juniper.intra.microsharp.com> <20020118200222.A26255@wotan.suse.de> <1011380895.23885.7.camel@jen.americas.sgi.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/1.0 (Preview Release) Date: 18 Jan 2002 13:19:15 -0600 Message-Id: <1011381555.2106.6.camel@stout.americas.sgi.com> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 453 Lines: 17 On Fri, 2002-01-18 at 13:08, Steve Lord wrote: > Might that in place filesystem converter work for this? Hm, maybe. Convert from XFS to XFS, but make the loopback filesystem the size of your new, smaller filesystem. And before you map the loopback filesystem down to the block device, shrink the block device by removing a volume. Maybe? -Eric -- Eric Sandeen XFS for Linux http://oss.sgi.com/projects/xfs sandeen@sgi.com SGI, Inc. From owner-linux-xfs@oss.sgi.com Fri Jan 18 12:21:36 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0IKLao07796 for linux-xfs-outgoing; Fri, 18 Jan 2002 12:21:36 -0800 Received: from zorak.illusionary.lan (653231hfc40.tampabay.rr.com [65.32.31.40]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0IKLWP07774 for ; Fri, 18 Jan 2002 12:21:33 -0800 Received: from yog-sothoth (yog-sothoth [192.168.10.9]) by zorak.illusionary.lan (8.9.3/8.9.3/Debian 8.9.3-21) with ESMTP id OAA17769 for ; Fri, 18 Jan 2002 14:21:24 -0500 Subject: Re: Shrink an XFS filesystem? (LVM) From: Derek Glidden To: linux-xfs@oss.sgi.com In-Reply-To: <20020118200222.A26255@wotan.suse.de> References: <871ygn8p71.fsf@juniper.intra.microsharp.com> <20020118200222.A26255@wotan.suse.de> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/1.0.1 Date: 18 Jan 2002 14:21:18 -0500 Message-Id: <1011381678.2614.40.camel@yog-sothoth> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 944 Lines: 20 On Fri, 2002-01-18 at 14:02, Andi Kleen wrote: > On Fri, Jan 18, 2002 at 10:54:42AM -0800, Karl M. Hegbloom wrote: > > Is it possible (now or ever) to shrink an XFS filesystem? > > Currently it isn't, other than dump/mkfs/restore > Ever only if someone implements it. AFAIK there are no plans for it, > but of course the source is available if someone is motivated. I brought the same question up some time ago, and, after Steve Lord explained everything that would be involved in making an xfs_shrinkfs work, I pleaded that anyone with the skill and knowhow to do such a thing please just work on improving the core XFS code instead. :) -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- With Microsoft products, failure is not Derek Glidden an option - it's a standard component. Choose your life. Choose your http://www.tbcpc.org/ future. Choose Linux. http://www.illusionary.com/ From owner-linux-xfs@oss.sgi.com Fri Jan 18 13:26:02 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0ILQ2a10179 for linux-xfs-outgoing; Fri, 18 Jan 2002 13:26:02 -0800 Received: from yog-sothoth.sgi.com (eugate.sgi.com [192.48.160.10]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0ILPnP10154 for ; Fri, 18 Jan 2002 13:25:50 -0800 Received: from zeus-e8.americas.sgi.com (zeus-e8.americas.sgi.com [128.162.8.103]) by yog-sothoth.sgi.com (980305.SGI.8.8.8-aspam-6.2/980304.SGI-aspam-europe) via ESMTP id VAA232688 for ; Fri, 18 Jan 2002 21:24:40 +0100 (CET) mail_from (sandeen@sgi.com) Received: from poppy-e185.americas.sgi.com (poppy-e185.americas.sgi.com [128.162.185.207]) by zeus-e8.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id OAA56013 for ; Fri, 18 Jan 2002 14:24:27 -0600 (CST) Received: from stout.americas.sgi.com (stout.americas.sgi.com [128.162.187.5]) by poppy-e185.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.7) with ESMTP id OAA15086 for ; Fri, 18 Jan 2002 14:24:26 -0600 (CST) Subject: Re: Shrink an XFS filesystem? (LVM) From: Eric Sandeen Cc: linux-xfs@oss.sgi.com In-Reply-To: <1011381555.2106.6.camel@stout.americas.sgi.com> References: <871ygn8p71.fsf@juniper.intra.microsharp.com> <20020118200222.A26255@wotan.suse.de> <1011380895.23885.7.camel@jen.americas.sgi.com> <1011381555.2106.6.camel@stout.americas.sgi.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/1.0 (Preview Release) Date: 18 Jan 2002 14:24:26 -0600 Message-Id: <1011385466.2128.10.camel@stout.americas.sgi.com> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 3303 Lines: 97 On Fri, 2002-01-18 at 13:19, Eric Sandeen wrote: > On Fri, 2002-01-18 at 13:08, Steve Lord wrote: > > Might that in place filesystem converter work for this? > > Hm, maybe. Convert from XFS to XFS, but make the loopback filesystem > the size of your new, smaller filesystem. And before you map the > loopback filesystem down to the block device, shrink the block device by > removing a volume. Actually, this will work! (Except that convertfs seems to have trouble converting _to_ xfs, let alone shrinking, I'll have to look at this...) However, behold this example of using secret Russian technology* to shrink an ext2 filesystem from 197 megs to 95 megs: *http://tzukanov.narod. ru/convertfs/ -=BEFORE=- [root@lite convertfs]# mke2fs -q /dev/sda1 mke2fs 1.23, 15-Aug-2001 for EXT2 FS 0.5b, 95/08/09 [root@lite convertfs]# mount /dev/sda1 /mnt/sda1/ [root@lite convertfs]# cp -aR /mnt/sda2/sda1/* /mnt/sda1/ [root@lite convertfs]# df -h /dev/sda1 Filesystem Size Used Avail Use% Mounted on /dev/sda1 197M 32M 155M 17% /mnt/sda1 [root@lite convertfs]# umount /dev/sda1 -=DURING=- Run convertfs, with slight modifications: (mkfs of new filesystem restricts size to new, smaller size) (100000 blocks) [root@lite convertfs]# ./shrinkfs == Creating clone of filesystem's device == ===== Creating destination filesystem ===== mke2fs 1.23, 15-Aug-2001 for EXT2 FS 0.5b, 95/08/09 Filesystem label= OS type: Linux Block size=1024 (log=0) Fragment size=1024 (log=0) 25064 inodes, 100000 blocks 5000 blocks (5.00%) reserved for the super user First data block=1 13 block groups 8192 blocks per group, 8192 fragments per group 1928 inodes per group Superblock backups stored on blocks: 8193, 24577, 40961, 57345, 73729 Writing inode tables: done Writing superblocks and filesystem accounting information: done This filesystem will be automatically checked every 35 mounts or 180 days, whichever comes first. Use tune2fs -c or -i to override. ============== Copying files ============== total 18 drwxr-xr-x 3 root root 1024 Jan 16 10:35 foo drwxr-xr-x 2 nfsnobod nfsnobod 1024 Jan 15 16:31 linktest drwxr-xr-x 2 root root 12288 Jan 18 13:26 lost+found drwxr-xr-x 10 root root 2048 Jan 17 14:10 root drwxr-xr-x 3 root root 1024 Jan 15 13:37 testing drwxr-xr-x 2 root root 1024 Jan 17 14:12 tmp Filesystem Size Used Avail Use% Mounted on /dev/loop7 95M 32M 58M 36% /usr/convertfs/fs2root === Preparing info for block relocation === 0+1 records in 0+1 records out ============ Relocating blocks ============ Loading indexblocks... done. Relocating blocks... done. -=AFTER=- [root@lite convertfs]# e2fsck /dev/sda1 e2fsck 1.23, 15-Aug-2001 for EXT2 FS 0.5b, 95/08/09 /dev/sda1: clean, 1475/25064 files, 35350/100000 blocks [root@lite convertfs]# mount /dev/sda1 /mnt/sda1/ [root@lite convertfs]# df -h /dev/sda1 Filesystem Size Used Avail Use% Mounted on /dev/sda1 95M 32M 58M 36% /mnt/sda1 Ta-Da! Um, don't try this with data that _matters_ - ok? -Eric -- Eric Sandeen XFS for Linux http://oss.sgi.com/projects/xfs sandeen@sgi.com SGI, Inc. From owner-linux-xfs@oss.sgi.com Fri Jan 18 13:30:56 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0ILUuK10591 for linux-xfs-outgoing; Fri, 18 Jan 2002 13:30:56 -0800 Received: from Cantor.suse.de (ns.suse.de [213.95.15.193]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0ILUrP10547 for ; Fri, 18 Jan 2002 13:30:53 -0800 Received: from Hermes.suse.de (Hermes.suse.de [213.95.15.136]) by Cantor.suse.de (Postfix) with ESMTP id 329DB1E798; Fri, 18 Jan 2002 21:30:46 +0100 (MET) Date: Fri, 18 Jan 2002 21:30:46 +0100 From: Andi Kleen To: Eric Sandeen Cc: Steve Lord , linux-xfs@oss.sgi.com, karlheg@microsharp.com, ak@suse.de Subject: Re: Shrink an XFS filesystem? (LVM) Message-ID: <20020118213046.A12253@wotan.suse.de> References: <871ygn8p71.fsf@juniper.intra.microsharp.com> <20020118200222.A26255@wotan.suse.de> <1011380895.23885.7.camel@jen.americas.sgi.com> <1011381555.2106.6.camel@stout.americas.sgi.com> <1011385085.2128.8.camel@stout.americas.sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1011385085.2128.8.camel@stout.americas.sgi.com> User-Agent: Mutt/1.3.22.1i Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 218 Lines: 11 > Ta-Da! > > Um, don't try this with data that _matter_ - ok? Cool :-) Perhaps it could be even made crash safe with one of the existing generic user mode journaling layers, like the one from sleepycat db. -Andi From owner-linux-xfs@oss.sgi.com Fri Jan 18 13:30:57 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0ILUvD10599 for linux-xfs-outgoing; Fri, 18 Jan 2002 13:30:57 -0800 Received: from tide.yandex.ru (tide.yandex.ru [213.180.193.107]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0ILUpP10539 for ; Fri, 18 Jan 2002 13:30:54 -0800 Received: from YAMAIL (tide.yandex.ru) by mail.yandex.ru id ; Fri, 18 Jan 2002 23:30:24 +0300 Subject: Re: Shrink an XFS filesystem? (LVM) To: linux-xfs@oss.sgi.com Date: Fri, 18 Jan 2002 23:30:24 +0300 (MSK) From: "Serguei Tzukanov" Reply-To: tzukanov@narod.ru Message-Id: <3C4885E0.000034.06087@tide.yandex.ru> MIME-Version: 1.0 X-Mailer: Yamail [ http://yandex.ru ] X-source-ip: 193.232.112.69 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 510 Lines: 9 > Hm, maybe. Convert from XFS to XFS, but make the loopback filesystem > the size of your new, smaller filesystem. And before you map the > loopback filesystem down to the block device, shrink the block device by > removing a volume. Yes, you are right, but not with current code (I don't have the time/proper linux machine to fix this now. Maybe next week). P.S. Some discussion about using of convertfs was on GNU Parted mailing list - http://mail.gnu.org/pipermail/bug-parted/2002-January/thread.html. From owner-linux-xfs@oss.sgi.com Fri Jan 18 16:08:36 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0J08aJ14448 for linux-xfs-outgoing; Fri, 18 Jan 2002 16:08:36 -0800 Received: from microsharp.com (mail.microsharp.com [206.190.130.135]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0J08VP14426 for ; Fri, 18 Jan 2002 16:08:31 -0800 Received: from juniper.intra.microsharp.com (asl.microsharp.com [206.190.130.132]) by microsharp.com (8.11.2/8.11.2) with ESMTP id g0IN8f108205 for ; Fri, 18 Jan 2002 15:08:41 -0800 Received: from juniper.intra.microsharp.com (karlheg@localhost [127.0.0.1]) by juniper.intra.microsharp.com (8.12.1/8.12.1/Debian -5) with ESMTP id g0IN8NVT023466 for ; Fri, 18 Jan 2002 15:08:24 -0800 Received: (from karlheg@localhost) by juniper.intra.microsharp.com (8.12.1/8.12.1/Debian -5) id g0IN8NKg023459; Fri, 18 Jan 2002 15:08:23 -0800 To: linux-xfs@oss.sgi.com Subject: Shrinking an XFS filesystem is a crucial feature! X-Face: 1v=v?=]<7%cW&OL:Z"GCcdmIN&wp)w|1EKzyC6?qaX;55wwjPfKTm\'7x-gd+KEd`(o&(EQ%(B4]6sZ$|e_FBGTJOvJtHUM>flSNQqfdw.jYZ$jnCERoAX*{4lEJm?EB#V_<2\-#5%#Du/ExQR)juedX>!Cq#;UoAo?|Oo~BX@!fwIX From: karlheg@microsharp.com (Karl M. Hegbloom) Date: 18 Jan 2002 15:08:23 -0800 Message-ID: <87wuyf5kbc.fsf@juniper.intra.microsharp.com> User-Agent: Gnus/5.0808 (Gnus v5.8.8) XEmacs/21.4 (Artificial Intelligence) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 859 Lines: 20 I think that the ability to shrink an XFS filesystem is a crucial feature that really should be implemented. I wish I was capable of doing so. If I dedicated myself to just that task, I estimate it would be two years before I can code that. I'm just not that good yet. The other thing that XFS desparetly needs is a "fsck" or "xfs_repair" that can be run on a read-only mounted filesystem. I had visions of using XFS on LVM volumes for our product. I would like to start with some default LV sizes, and have the ability to shrink and grow them as needed to meet individual requirements. For this, I will need to use ext3fs. (and very stable LVM; still learning about it.) -- mailto: (Karl M. Hegbloom) karlheg@microsharp.com Free the Software http://www.debian.org/social_contract http://www.microsharp.com phone://USA/WA/360-260-2066 From owner-linux-xfs@oss.sgi.com Fri Jan 18 17:29:36 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0J1TaU16120 for linux-xfs-outgoing; Fri, 18 Jan 2002 17:29:36 -0800 Received: from eclectic.kluge.net (dsl092-071-242.bos1.dsl.speakeasy.net [66.92.71.242]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0J1TUP16097 for ; Fri, 18 Jan 2002 17:29:31 -0800 Received: (from felicity@localhost) by eclectic.kluge.net (8.11.6/8.11.6) id g0J0TPo17086; Fri, 18 Jan 2002 19:29:25 -0500 Date: Fri, 18 Jan 2002 19:29:25 -0500 From: Theo Van Dinter To: "Karl M. Hegbloom" Cc: linux-xfs@oss.sgi.com Subject: Re: Shrinking an XFS filesystem is a crucial feature! Message-ID: <20020118192925.A16986@kluge.net> References: <87wuyf5kbc.fsf@juniper.intra.microsharp.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: <87wuyf5kbc.fsf@juniper.intra.microsharp.com>; from karlheg@microsharp.com on Fri, Jan 18, 2002 at 03:08:23PM -0800 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 1300 Lines: 31 On Fri, Jan 18, 2002 at 03:08:23PM -0800, Karl M. Hegbloom wrote: > I think that the ability to shrink an XFS filesystem is a crucial > feature that really should be implemented. I wish I was capable of I don't think shrinking can really be considered "crucial". Are there times that shrinking would be nice? Absolutely. How often is that? Not very. I'd much rather have folks spending their time on making XFS a super stable/scalable/etc FS and leave shrinking as a "feature request" for some time in the future. Being "crucial" translates into "needs to be done immediately", which most people probably wouldn't say of shrinking. > I had visions of using XFS on LVM volumes for our product. I would > like to start with some default LV sizes, and have the ability to > shrink and grow them as needed to meet individual requirements. For > this, I will need to use ext3fs. (and very stable LVM; still > learning about it.) You could either 1) figure out the requirements ahead of time and make the LVs the correct size to start, or 2) make the LVs a minimum size to start and grow the ones you need to as necessary. -- Randomly Generated Tagline: The weak and nerdy are admired for their computer-programming abilities. -- Homer Simpson Bart vs. Australia From owner-linux-xfs@oss.sgi.com Fri Jan 18 17:42:44 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0J1giN16517 for linux-xfs-outgoing; Fri, 18 Jan 2002 17:42:44 -0800 Received: from gusi.leathercollection.ph (gusi.leathercollection.ph [202.163.192.10]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0J1gcP16493 for ; Fri, 18 Jan 2002 17:42:38 -0800 Received: from localhost (localhost [127.0.0.1]) by gusi.leathercollection.ph (Postfix) with ESMTP id 33A08C00B6E for ; Sat, 19 Jan 2002 08:42:34 +0800 (PHT) Received: from mail.leathercollection.ph (gusi.leathercollection.ph [192.168.0.1]) by gusi.leathercollection.ph (Postfix) with ESMTP id 0E634C00B6A for ; Sat, 19 Jan 2002 08:42:33 +0800 (PHT) Date: Sat, 19 Jan 2002 08:42:33 +0800 (PHT) From: Federico Sevilla III To: Linux XFS Mailing List Subject: Re: Frequent hangs with 2.4.9-xfs-1.0.2 In-Reply-To: <20020118123336.C2514@angelica.keck.waisman.wisc.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by AMaViS perl-11 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 1870 Lines: 40 On Fri, 18 Jan 2002 at 12:33, Adrian Pederson wrote: > The 3ware driver is 1.02.00.008, firmware is 1.03.09.027, both are the > latest. This might be a little off-topic here, but anyway: as of Linux kernel 2.4.16, the 3ware driver being used in the kernel is v1.02.00.010. This doesn't work with the .20 3dm, though. A new one is scheduled to be released on Feb 7. If you're willing to try things out, you might be interested in doing a fresh CVS checkout. The various changes that have gone into both the core kernel as well as the XFS portion may somehow fix your problems. > A couple other data points, it only crashes during business hours, when > the load tends to be higher. I ran the machine for a week on 100 Mb > Ethernet without a single crash doing benchmarks and copying ~400 GB of > data, only since moving to the e1000 NIC has it been locking up. I just > moved the interface back to 100 Mb, wait and see what happens... I wonder if it's XFS locking up because of the strain that high loads on GbE can cause, or if it's a problem with the kernel and your e1000 NIC (somehow?). As I've never gone beyond 100Mbps, I wouldn't know how "life on the truly fast lane" feels like. But my 3ware 6400 running RAID5 (I know, slow, bad choice, but it's a tad too late to take things apart to go RAID10) has been quite stable. It's been regularly updated and is running a CVS checkout done 20020112 (PHT) with RML's preempt-1 patch. Loads vary, but the most "intensive" part is when I do snapshots of the home and data shares using tar, storing the data on same array (to prevent against user error more than system failure). If that's indicative of anything, anyway. I'm not sure it is. --> Jijo -- Federico Sevilla III :: jijo@leathercollection.ph Network Administrator :: The Leather Collection, Inc. GnuPG Key: http://jijo.leathercollection.ph/jijo.gpg From owner-linux-xfs@oss.sgi.com Sat Jan 19 00:54:04 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0J8s4825184 for linux-xfs-outgoing; Sat, 19 Jan 2002 00:54:04 -0800 Received: from zorak.illusionary.lan (653231hfc40.tampabay.rr.com [65.32.31.40]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0J8rwP25161 for ; Sat, 19 Jan 2002 00:53:59 -0800 Received: from yog-sothoth (yog-sothoth [192.168.10.9]) by zorak.illusionary.lan (8.9.3/8.9.3/Debian 8.9.3-21) with ESMTP id CAA18411 for ; Sat, 19 Jan 2002 02:53:50 -0500 Subject: Re: Shrinking an XFS filesystem is a crucial feature! From: Derek Glidden To: linux-xfs@oss.sgi.com In-Reply-To: <87wuyf5kbc.fsf@juniper.intra.microsharp.com> References: <87wuyf5kbc.fsf@juniper.intra.microsharp.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/1.0.1 Date: 19 Jan 2002 02:53:43 -0500 Message-Id: <1011426823.895.6.camel@yog-sothoth> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 1129 Lines: 25 On Fri, 2002-01-18 at 18:08, Karl M. Hegbloom wrote: > I think that the ability to shrink an XFS filesystem is a crucial > feature that really should be implemented. I wish I was capable of > doing so. If I dedicated myself to just that task, I estimate it > would be two years before I can code that. I'm just not that good > yet. Occasionally useful, sure, but crucial, no. Without meaning to be rude, what in the world are you using "Enterprise-class" file systems and volume managers on systems that don't have enough disk space such that you are forced to shrink volumes? Alternatively, who in the world is managing and enterprise server that they didn't plan volume sizes appropriately? If you're just playing around with it at home, then, well, NO feature other than "it works" is really "crucial" IMNSHO. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- With Microsoft products, failure is not Derek Glidden an option - it's a standard component. Choose your life. Choose your http://www.tbcpc.org/ future. Choose Linux. http://www.illusionary.com/ From owner-linux-xfs@oss.sgi.com Sat Jan 19 01:09:22 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0J99Ms25616 for linux-xfs-outgoing; Sat, 19 Jan 2002 01:09:22 -0800 Received: from UberGeek.coremetrics.com ([209.184.141.163]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0J99AP25589 for ; Sat, 19 Jan 2002 01:09:11 -0800 Received: (from austin@localhost) by UberGeek.coremetrics.com (8.11.6/8.11.6) id g0J880x04414; Sat, 19 Jan 2002 02:08:00 -0600 X-Authentication-Warning: UberGeek.coremetrics.com: austin set sender to austin@coremetrics.com using -f Subject: Re: Shrinking an XFS filesystem is a crucial feature! From: Austin Gonyou To: Derek Glidden Cc: linux-xfs@oss.sgi.com In-Reply-To: <1011426823.895.6.camel@yog-sothoth> References: <1011426823.895.6.camel@yog-sothoth> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-/xb3GCKWwB2V0jUyoqMT" X-Mailer: Evolution/1.0.1 Date: 19 Jan 2002 02:08:00 -0600 Message-Id: <1011427680.3142.39.camel@UberGeek> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 3216 Lines: 79 --=-/xb3GCKWwB2V0jUyoqMT Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Think of it like this. For those who use Veritas, there are quite a few, and manage "enterprise class" systems, Veritas HAS shrink and grow, despite how well people planned.=20 The need is more along the lines that if you have a highly dynamic environment which you must tailor to fit a rapid growth pattern, regardless if you tried to plan for it or how well, sometimes the need arises to resize file systems. Regardless of which direction + or -.=20 That said, for those wishing to change from Veritas and use something "free" or Open Source, or cheap, whatever, they'll be looking for the same things they can get out of whatever they're trying to replace.=20 If you're looking to switch from Veritas or whatever else, then most likely you'll want to be able to shrink and grow FS. Not to mention not all people who use Veritas are running "enterprise class" systems. They may not want to PAY for the extra disk space, or may want to shrink a volume which will be recycled for a different purpose. Rather than re-striping, or relaying the FS, one could merely shrink it and just migrate data off of that volume, rather than looking at "down time" or "service outages".=20 Think of those things too. On Sat, 2002-01-19 at 01:53, Derek Glidden wrote: > On Fri, 2002-01-18 at 18:08, Karl M. Hegbloom wrote: > > I think that the ability to shrink an XFS filesystem is a crucial > > feature that really should be implemented. I wish I was capable of > > doing so. If I dedicated myself to just that task, I estimate it > > would be two years before I can code that. I'm just not that good > > yet. >=20 > Occasionally useful, sure, but crucial, no.=20=20 >=20 > Without meaning to be rude, what in the world are you using > "Enterprise-class" file systems and volume managers on systems that > don't have enough disk space such that you are forced to shrink > volumes? Alternatively, who in the world is managing and enterprise > server that they didn't plan volume sizes appropriately? >=20 > If you're just playing around with it at home, then, well, NO feature > other than "it works" is really "crucial" IMNSHO. >=20 > --=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- > With Microsoft products, failure is not Derek Glidden > an option - it's a standard component.=20 > Choose your life. Choose your http://www.tbcpc.org/ > future. Choose Linux. http://www.illusionary.com/ --=20 Austin Gonyou Systems Architect, CCNA Coremetrics, Inc. Phone: 512-698-7250 email: austin@coremetrics.com "It is the part of a good shepherd to shear his flock, not to skin it." Latin Proverb --=-/xb3GCKWwB2V0jUyoqMT Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQA8SSlf94g6ZVmFMoIRAm24AKCkJ6ctz0o7y6qbB6kEix5CDDJtZgCdEHWx CDA66+01KdZU22WLAuTCbxo= =Noj4 -----END PGP SIGNATURE----- --=-/xb3GCKWwB2V0jUyoqMT-- From owner-linux-xfs@oss.sgi.com Sat Jan 19 04:20:30 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0JCKUx30936 for linux-xfs-outgoing; Sat, 19 Jan 2002 04:20:30 -0800 Received: from mail.broadpark.no (217-13-4-9.dd.nextgentel.com [217.13.4.9]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0JCKRP30908 for ; Sat, 19 Jan 2002 04:20:27 -0800 Received: from online.no (213-187-164-240.dd.nextgentel.com [213.187.164.240]) by mail.broadpark.no (Postfix) with ESMTP id E9EAC8093 for ; Sat, 19 Jan 2002 12:20:18 +0100 (MET) Message-ID: <3C4954CF.3FA4705@online.no> Date: Sat, 19 Jan 2002 12:13:20 +0100 From: Knut J Bjuland X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.4.9-13SGI_XFS_1.0.2custom i686) X-Accept-Language: en MIME-Version: 1.0 To: linux-xfs@oss.sgi.com Subject: strange bug in linux-2.4.9-13-xfs Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 356 Lines: 7 XFS seem to have problem when shutdown/loginout from gnome. XFS seems to mess up .ICEauthority and ~/.gnome/panel.d in a manner that make it impossible to login in gnome from GDM. There are a workaround by deleting .ICEauthority and restore these file from a backup. I then get my settings back. This problem does not affect latest CVS in linux-2.4-xfs. From owner-linux-xfs@oss.sgi.com Sat Jan 19 05:51:31 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0JDpVj02277 for linux-xfs-outgoing; Sat, 19 Jan 2002 05:51:31 -0800 Received: from yog-sothoth.sgi.com (eugate.sgi.com [192.48.160.10]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0JDpLP02253 for ; Sat, 19 Jan 2002 05:51:22 -0800 Received: from zeus-e8.americas.sgi.com (zeus-e8.americas.sgi.com [128.162.8.103]) by yog-sothoth.sgi.com (980305.SGI.8.8.8-aspam-6.2/980304.SGI-aspam-europe) via ESMTP id NAA236382 for ; Sat, 19 Jan 2002 13:50:11 +0100 (CET) mail_from (lord@sgi.com) Received: from tulip-e185.americas.sgi.com (tulip-e185.americas.sgi.com [128.162.185.208]) by zeus-e8.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id GAA65487; Sat, 19 Jan 2002 06:49:52 -0600 (CST) Received: from sgi.com (jcL2cceVO9+R1rJ/9nrgb0LmBAELHiFU@cf-vpn-sw-corp-64-24.corp.sgi.com [134.15.64.24]) by tulip-e185.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.7) with ESMTP id GAA90565; Sat, 19 Jan 2002 06:49:50 -0600 (CST) Message-ID: <3C496C9A.8030204@sgi.com> Date: Sat, 19 Jan 2002 06:54:50 -0600 From: Stephen Lord User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.6) Gecko/20011120 X-Accept-Language: en-us MIME-Version: 1.0 To: Austin Gonyou CC: Derek Glidden , linux-xfs@oss.sgi.com, "Karl M. Hegbloom" Subject: Re: Shrinking an XFS filesystem is a crucial feature! References: <1011426823.895.6.camel@yog-sothoth> <1011427680.3142.39.camel@UberGeek> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 2934 Lines: 66 Austin Gonyou wrote: >Think of it like this. For those who use Veritas, there are quite a few, >and manage "enterprise class" systems, Veritas HAS shrink and grow, >despite how well people planned. > >The need is more along the lines that if you have a highly dynamic >environment which you must tailor to fit a rapid growth pattern, >regardless if you tried to plan for it or how well, sometimes the need >arises to resize file systems. Regardless of which direction + or -. > >That said, for those wishing to change from Veritas and use something >"free" or Open Source, or cheap, whatever, they'll be looking for the >same things they can get out of whatever they're trying to replace. > >If you're looking to switch from Veritas or whatever else, then most >likely you'll want to be able to shrink and grow FS. Not to mention not >all people who use Veritas are running "enterprise class" systems. They >may not want to PAY for the extra disk space, or may want to shrink a >volume which will be recycled for a different purpose. Rather than >re-striping, or relaying the FS, one could merely shrink it and just >migrate data off of that volume, rather than looking at "down time" or >"service outages". > They also appear to want us to write more code for them, which they also do not pay for so that they do not have to pay for disk drives. Something is wrong with this model I think. Oh, and in this case it is 'for use in a product', so add not pay for something they want to make money off...... Sorry, but this rubbed me up the wrong way. Of the two thinks Karl asked for, the repair change is probably about a days work for someone who does not know the code. And then some very careful init script work to make sure the only way you ever use it is in single user mode followed by an immediate shutdown. Online repair is the equivalent of pulling the table cloth out from under the bone china dishes without anyone noticing. With ext2 its a tea party for 4, with xfs it is a banquet for 100 people. With vxfs it was designed in from the start. As for shrinking a filesystem, there may be a feasable solution people can work on without major knowledge of xfs internals. This is the in place filesystem converter already mentioned on the list. I have not used it, but it sounds like it is fairly slow, and needs some packaging work. This would only work offline since you basically move the data from one volume to another. A technique like this is about the only way in place shrinking is ever going to happen with xfs - at least as far as SGI is concerned. To do it within xfs itself, go put a dollar figure on several months work by a highly paid engineer (add in a couple of months tester time), then add in the fact that all the engineers are already at least 100% committed to things. And Karl, please read the part in the debian contract in your sig about contributing back to the community. Steve From owner-linux-xfs@oss.sgi.com Sat Jan 19 06:32:51 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0JEWpY02953 for linux-xfs-outgoing; Sat, 19 Jan 2002 06:32:51 -0800 Received: from porsta.cs.Helsinki.FI (root@porsta.cs.Helsinki.FI [128.214.48.124]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0JEWiP02927 for ; Sat, 19 Jan 2002 06:32:45 -0800 Received: from melkki.cs.Helsinki.FI (sslwrap@localhost [127.0.0.1]) by porsta.cs.Helsinki.FI (8.11.6/8.11.6) with ESMTP id g0JDWep00598 for ; Sat, 19 Jan 2002 15:32:40 +0200 Received: (from hhaataja@localhost) by melkki.cs.Helsinki.FI (8.11.6/8.11.2) id g0JDWaR28357 for linux-xfs@oss.sgi.com; Sat, 19 Jan 2002 15:32:36 +0200 Date: Sat, 19 Jan 2002 15:32:35 +0200 From: Harri Haataja Cc: linux-xfs@oss.sgi.com Subject: Re: Shrinking an XFS filesystem is a crucial feature! Message-ID: <20020119153235.A27897@cs.helsinki.fi> References: <87wuyf5kbc.fsf@juniper.intra.microsharp.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-md5; protocol="application/pgp-signature"; boundary="YiEDa0DAkWCtVeE4" Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <87wuyf5kbc.fsf@juniper.intra.microsharp.com>; from karlheg@microsharp.com on Fri, Jan 18, 2002 at 03:08:23PM -0800 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 984 Lines: 31 --YiEDa0DAkWCtVeE4 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Fri, Jan 18, 2002 at 03:08:23PM -0800, Karl M. Hegbloom wrote: > I had visions of using XFS on LVM volumes for our product. I would > like to start with some default LV sizes, and have the ability to > shrink and grow them as needed to meet individual requirements. For > this, I will need to use ext3fs. (and very stable LVM; still > learning about it.) I believe reiserfs shrinks as well. Havent tried. Yet. I'm shuffling filesystems soon, so I might since I'm at a bit tight space (backups on tape, no room for moving there either). --YiEDa0DAkWCtVeE4 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 iD8DBQE8SXVyQF8Oi9XNck4RAseAAKC1E0DCtfdm5JDep0JsRHlm4O7zwQCgq4+t vcFsXEZQzjuFpuDE4fce9RI= =vNL/ -----END PGP SIGNATURE----- --YiEDa0DAkWCtVeE4-- From owner-linux-xfs@oss.sgi.com Sat Jan 19 09:02:18 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0JH2I006571 for linux-xfs-outgoing; Sat, 19 Jan 2002 09:02:18 -0800 Received: from yog-sothoth.sgi.com (eugate.sgi.com [192.48.160.10]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0JH2BP06548 for ; Sat, 19 Jan 2002 09:02:12 -0800 Received: from relay1.corp.sgi.com (spindle.corp.sgi.com [198.29.75.13]) by yog-sothoth.sgi.com (980305.SGI.8.8.8-aspam-6.2/980304.SGI-aspam-europe) via ESMTP id RAA282033 for ; Sat, 19 Jan 2002 17:00:56 +0100 (CET) mail_from (sandeen@sgi.com) Received: from chuckle.americas.sgi.com (sandeen@chuckle.americas.sgi.com [128.162.211.44]) by relay1.corp.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) via ESMTP id IAA83004; Sat, 19 Jan 2002 08:01:29 -0800 (PST) Date: Sat, 19 Jan 2002 10:01:28 -0600 (CST) From: Eric Sandeen X-X-Sender: To: Knut J Bjuland cc: Subject: Re: strange bug in linux-2.4.9-13-xfs In-Reply-To: <3C4954CF.3FA4705@online.no> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 357 Lines: 11 On Sat, 19 Jan 2002, Knut J Bjuland wrote: > XFS seem to have problem when shutdown/loginout from gnome. XFS seems > to mess up .ICEauthority and ~/.gnome/panel.d in a manner that make it > impossible to login in gnome from GDM. Are these files full of null characters? And did this happen after a system crash, or otherwise non-clean shutdown? -Eric From owner-linux-xfs@oss.sgi.com Sat Jan 19 09:49:40 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0JHnej07227 for linux-xfs-outgoing; Sat, 19 Jan 2002 09:49:40 -0800 Received: from Cantor.suse.de (ns.suse.de [213.95.15.193]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0JHnaP07205 for ; Sat, 19 Jan 2002 09:49:36 -0800 Received: from Hermes.suse.de (Hermes.suse.de [213.95.15.136]) by Cantor.suse.de (Postfix) with ESMTP id 161C01EA6A; Sat, 19 Jan 2002 17:49:29 +0100 (MET) Date: Sat, 19 Jan 2002 17:49:26 +0100 From: Andi Kleen To: Stephen Lord Cc: Austin Gonyou , Derek Glidden , linux-xfs@oss.sgi.com, "Karl M. Hegbloom" Subject: Re: Shrinking an XFS filesystem is a crucial feature! Message-ID: <20020119174926.A4394@wotan.suse.de> References: <1011426823.895.6.camel@yog-sothoth> <1011427680.3142.39.camel@UberGeek> <3C496C9A.8030204@sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3C496C9A.8030204@sgi.com> User-Agent: Mutt/1.3.22.1i Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 889 Lines: 19 On Sat, Jan 19, 2002 at 06:54:50AM -0600, Steve Lord wrote: > Of the two thinks Karl asked for, the repair change is probably > about a days work for someone who does not know the code. And then > some very careful init script work to make sure the only way you ever > use it is in single user mode followed by an immediate shutdown. Online > repair is the equivalent of pulling the table cloth out from under the > bone china dishes without anyone noticing. With ext2 its a tea party for > 4, with xfs it is a banquet for 100 people. With vxfs it was designed > in from the start. About online fsck: what could work is to use a writable LVM[1] or EVMS snapshot of the filesystem and fsck the snapshot. When you detect an error unmount the main file system (it is unsafe to use now anyways) and fsck it again. -Andi [1] Current LVM needs a small patch to make snapshots writable. From owner-linux-xfs@oss.sgi.com Sat Jan 19 14:43:33 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0JMhXN11337 for linux-xfs-outgoing; Sat, 19 Jan 2002 14:43:33 -0800 Received: from UberGeek.coremetrics.com ([209.184.141.163]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0JMhIP11310 for ; Sat, 19 Jan 2002 14:43:18 -0800 Received: (from austin@localhost) by UberGeek.coremetrics.com (8.11.6/8.11.6) id g0JLfHc05728; Sat, 19 Jan 2002 15:41:17 -0600 X-Authentication-Warning: UberGeek.coremetrics.com: austin set sender to austin@coremetrics.com using -f Subject: Re: Shrinking an XFS filesystem is a crucial feature! From: Austin Gonyou To: Stephen Lord Cc: Derek Glidden , linux-xfs@oss.sgi.com, "Karl M. Hegbloom" In-Reply-To: <3C496C9A.8030204@sgi.com> References: <3C496C9A.8030204@sgi.com> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-BGG1lUnoV6jum+WwnRNY" X-Mailer: Evolution/1.0.1 Date: 19 Jan 2002 15:41:17 -0600 Message-Id: <1011476477.5714.3.camel@UberGeek> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 4369 Lines: 112 --=-BGG1lUnoV6jum+WwnRNY Content-Type: text/plain Content-Transfer-Encoding: quoted-printable No offense meant Steve. I was not trying to say anything about compensation here. Although people using it "in a product" that would expect this kind of thing and do not contribute and expect someone else to do it is missing the point of the OSI.=20 That said, I was merely trying to offer what I believe the target audience will want. It seems that the target audience would be those using Veritas and the like. Sorry for rubbing you the wrong way, I don't think I meant it in the manner you though.=20 On Sat, 2002-01-19 at 06:54, Stephen Lord wrote: > Austin Gonyou wrote: >=20 > >Think of it like this. For those who use Veritas, there are quite a > few, > >and manage "enterprise class" systems, Veritas HAS shrink and grow, > >despite how well people planned.=20 > > > >The need is more along the lines that if you have a highly dynamic > >environment which you must tailor to fit a rapid growth pattern, > >regardless if you tried to plan for it or how well, sometimes the need > >arises to resize file systems. Regardless of which direction + or -.=20 > > > >That said, for those wishing to change from Veritas and use something > >"free" or Open Source, or cheap, whatever, they'll be looking for the > >same things they can get out of whatever they're trying to replace.=20 > > > >If you're looking to switch from Veritas or whatever else, then most > >likely you'll want to be able to shrink and grow FS. Not to mention not > >all people who use Veritas are running "enterprise class" systems. They > >may not want to PAY for the extra disk space, or may want to shrink a > >volume which will be recycled for a different purpose. Rather than > >re-striping, or relaying the FS, one could merely shrink it and just > >migrate data off of that volume, rather than looking at "down time" or > >"service outages".=20 > > >=20 > They also appear to want us to write more code for them, which they also > do not pay for so that they do not have to pay for disk drives. > Something > is wrong with this model I think. >=20 > Oh, and in this case it is 'for use in a product', so add not pay for=20 > something > they want to make money off...... >=20 > Sorry, but this rubbed me up the wrong way. >=20 > Of the two thinks Karl asked for, the repair change is probably > about a days work for someone who does not know the code. And then > some very careful init script work to make sure the only way you ever > use it is in single user mode followed by an immediate shutdown. Online > repair is the equivalent of pulling the table cloth out from under the > bone china dishes without anyone noticing. With ext2 its a tea party for > 4, with xfs it is a banquet for 100 people. With vxfs it was designed > in from the start. >=20 > As for shrinking a filesystem, there may be a feasable solution people > can > work on without major knowledge of xfs internals. This is the in place > filesystem converter already mentioned on the list. I have not used it, > but it sounds like it is fairly slow, and needs some packaging work. > This > would only work offline since you basically move the data from one > volume to another. A technique like this is about the only way in place > shrinking is ever going to happen with xfs - at least as far as SGI is > concerned. To do it within xfs itself, go put a dollar figure on several > months work by a highly paid engineer (add in a couple of months tester > time), then add in the fact that all the engineers are already at least= =20 > 100% > committed to things. >=20 > And Karl, please read the part in the debian contract in your sig about > contributing back to the community. >=20 > Steve >=20 >=20 >=20 >=20 --=20 Austin Gonyou Systems Architect, CCNA Coremetrics, Inc. Phone: 512-698-7250 email: austin@coremetrics.com "It is the part of a good shepherd to shear his flock, not to skin it." Latin Proverb --=-BGG1lUnoV6jum+WwnRNY Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQA8Sef994g6ZVmFMoIRAj/eAJ9Cy4ZKvOs5SiBtrCuwPhu1RZH/UwCgijCF 0/UCL+ZlCJFmLpyivwwcJM8= =Lzwu -----END PGP SIGNATURE----- --=-BGG1lUnoV6jum+WwnRNY-- From owner-linux-xfs@oss.sgi.com Sat Jan 19 16:00:58 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0K00wP12814 for linux-xfs-outgoing; Sat, 19 Jan 2002 16:00:58 -0800 Received: from mail.ocs.com.au (mail.ocs.com.au [203.34.97.2]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0K00pP12790 for ; Sat, 19 Jan 2002 16:00:51 -0800 Received: (qmail 13381 invoked from network); 19 Jan 2002 23:00:44 -0000 Received: from ocs3.intra.ocs.com.au (192.168.255.3) by mail.ocs.com.au with SMTP; 19 Jan 2002 23:00:44 -0000 Received: by ocs3.intra.ocs.com.au (Postfix, from userid 16331) id A02C93000AD; Sun, 20 Jan 2002 10:00:41 +1100 (EST) Received: from ocs3.intra.ocs.com.au (localhost [127.0.0.1]) by ocs3.intra.ocs.com.au (Postfix) with ESMTP id 2046594; Sun, 20 Jan 2002 10:00:41 +1100 (EST) X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 From: Keith Owens To: Knut J Bjuland Cc: linux-xfs@oss.sgi.com Subject: Re: strange bug in linux-2.4.9-13-xfs In-reply-to: Your message of "Sat, 19 Jan 2002 12:13:20 BST." <3C4954CF.3FA4705@online.no> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sun, 20 Jan 2002 10:00:35 +1100 Message-ID: <25214.1011481235@ocs3.intra.ocs.com.au> Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 1041 Lines: 23 On Sat, 19 Jan 2002 12:13:20 +0100, Knut J Bjuland wrote: >XFS seem to have problem when shutdown/loginout from gnome. XFS seems >to mess up .ICEauthority and ~/.gnome/panel.d in a manner that make it >impossible to login in gnome from GDM. There are a workaround by >deleting .ICEauthority and restore these file from a backup. I then get >my settings back. This problem does not affect latest CVS in >linux-2.4-xfs. If the system is crashing then you can get null data in recently changed files, this is in the XFS FAQ. There is a completely unrelated problem in flushing IDE drives before suspend/shutdown that can give the same symptoms, even on a clean shutdown. Andre Hendrick has been trying to get patches into the kernel to ensure that IDE drives are flushed on shutdown. http://marc.theaimsgroup.com/?l=linux-kernel&m=101005576629982&w=2 People have reported similar symptoms with several filesystems when the init scripts fail to flush the IDE caches on shutdown. hdparm -f on each device might help. From owner-linux-xfs@oss.sgi.com Sat Jan 19 22:16:20 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0K6GKx16250 for linux-xfs-outgoing; Sat, 19 Jan 2002 22:16:20 -0800 Received: from mail.pangeatech.com (pxofc151-phx1.pangeatech.com [63.110.32.151]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0K6GGP16228 for ; Sat, 19 Jan 2002 22:16:16 -0800 Received: from [65.192.22.133] by mail.pangeatech.com (NTMail 7.00.0018/NU8172.00.e2123c13) with ESMTP id xpvwkaaa for linux-xfs@oss.sgi.com; Sat, 19 Jan 2002 22:16:19 -0700 Received: from randolph by gandalf.tausq.org with local (Exim 3.12 #1 (Debian)) id 16SAKg-0006hs-00; Sat, 19 Jan 2002 21:15:54 -0800 Date: Sat, 19 Jan 2002 21:15:54 -0800 From: Randolph Chung To: linux-xfs@oss.sgi.com Subject: xfs for parisc-linux Message-ID: <20020120051554.GL21816@tausq.org> Reply-To: Randolph Chung Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.25i X-PGP: for PGP key, see http://www.tausq.org/pgp.txt X-GPG: for GPG key, see http://www.tausq.org/gpg.txt Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 564 Lines: 21 Greetings, FYI I got xfs working on parisc-linux (http://www.parisc-linux.org/). There is a patch against current parisc cvs at ftp://ftp.parisc-linux.org/patches/xfs-1.0.2-hppa-2.4.17-pa11.diff.gz I've used it to build a few kernels and run bonnie++. Seems to work ok. If someone wants to add parisc as a "supported platform" to the web page that'll be great :-) I'm not on the list, so please mail me if you have any questions about the patch. randolph -- @..@ http://www.TauSq.org/ (----) ( >__< ) ^^ ~~ ^^ From owner-linux-xfs@oss.sgi.com Sat Jan 19 22:46:48 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0K6kmJ16496 for linux-xfs-outgoing; Sat, 19 Jan 2002 22:46:48 -0800 Received: from mail.ocs.com.au (mail.ocs.com.au [203.34.97.2]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0K6kgP16472 for ; Sat, 19 Jan 2002 22:46:42 -0800 Received: (qmail 15278 invoked from network); 20 Jan 2002 05:46:37 -0000 Received: from ocs3.intra.ocs.com.au (192.168.255.3) by mail.ocs.com.au with SMTP; 20 Jan 2002 05:46:37 -0000 Received: by ocs3.intra.ocs.com.au (Postfix, from userid 16331) id 078183000AD; Sun, 20 Jan 2002 16:46:33 +1100 (EST) Received: from ocs3.intra.ocs.com.au (localhost [127.0.0.1]) by ocs3.intra.ocs.com.au (Postfix) with ESMTP id 16B6F94; Sun, 20 Jan 2002 16:46:32 +1100 (EST) X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 From: Keith Owens To: Randolph Chung Cc: linux-xfs@oss.sgi.com Subject: Re: xfs for parisc-linux In-reply-to: Your message of "Sat, 19 Jan 2002 21:15:54 -0800." <20020120051554.GL21816@tausq.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sun, 20 Jan 2002 16:46:27 +1100 Message-ID: <27820.1011505587@ocs3.intra.ocs.com.au> Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 1344 Lines: 32 On Sat, 19 Jan 2002 21:15:54 -0800, Randolph Chung wrote: >Greetings, > >FYI I got xfs working on parisc-linux (http://www.parisc-linux.org/). >There is a patch against current parisc cvs at > >ftp://ftp.parisc-linux.org/patches/xfs-1.0.2-hppa-2.4.17-pa11.diff.gz It looks like you started from an old XFS patch, XFS 2.4.17 has changed since 1.0.2. The changes to Configure.help, Makefile, arch/i386/kernel/entry.S and arch/ia64/kernel/entry.S are from an older XFS patch. Also your patch contains changes which do not appear to be XFS related, lclear_user is added to parisc_ksyms.c, pdc_cons.c has changes to EARLY_BOOTUP_DEBUG, AFAICT neither are used by XFS. I suggest you start with a clean hppa for 2.4.17 tree. Get these patches from ftp://oss.sgi.com/projects/xfs/download/patches/2.4.17 and apply them in this order. xfs-2.4.17-split-only.bz2 xfs-2.4.17-split-kernel.bz2 xfs-2.4.17-split-misc.bz2 xfs-2.4.17-split-acl-extattr.bz2 That is all of XFS without kdb or kbuild. Save this patched version of hppa 2.4.17 then make any changes that are required to get XFS working on hppa. A diff of the saved version against the working version will show what you had to change to get XFS working on hppa. It should be very little, ideally the only changes will be for system calls and defconfigs. From owner-linux-xfs@oss.sgi.com Sat Jan 19 23:18:11 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0K7IBX16900 for linux-xfs-outgoing; Sat, 19 Jan 2002 23:18:11 -0800 Received: from mail.pangeatech.com (pxofc151-phx1.pangeatech.com [63.110.32.151]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0K7I3P16878 for ; Sat, 19 Jan 2002 23:18:04 -0800 Received: from [65.192.22.133] by mail.pangeatech.com (NTMail 7.00.0018/NU8172.00.e2123c13) with ESMTP id sbwwkaaa for linux-xfs@oss.sgi.com; Sat, 19 Jan 2002 23:18:00 -0700 Received: from randolph by gandalf.tausq.org with local (Exim 3.12 #1 (Debian)) id 16SBIO-0006kO-00; Sat, 19 Jan 2002 22:17:36 -0800 Date: Sat, 19 Jan 2002 22:17:36 -0800 From: Randolph Chung To: Keith Owens Cc: linux-xfs@oss.sgi.com Subject: Re: xfs for parisc-linux Message-ID: <20020120061736.GM21816@tausq.org> Reply-To: Randolph Chung References: <20020120051554.GL21816@tausq.org> <27820.1011505587@ocs3.intra.ocs.com.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <27820.1011505587@ocs3.intra.ocs.com.au> User-Agent: Mutt/1.3.25i X-PGP: for PGP key, see http://www.tausq.org/pgp.txt X-GPG: for GPG key, see http://www.tausq.org/gpg.txt Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 1797 Lines: 41 > It looks like you started from an old XFS patch, XFS 2.4.17 has changed > since 1.0.2. The changes to Configure.help, Makefile, > arch/i386/kernel/entry.S and arch/ia64/kernel/entry.S are from an older > XFS patch. Yes, it's possibly old, but that's all I could find from the xfs web page... http://oss.sgi.com/projects/xfs/102_release.html. Thanks for the pointer to the other location for downloading the patch. > Also your patch contains changes which do not appear to be > XFS related, lclear_user is added to parisc_ksyms.c, pdc_cons.c has > changes to EARLY_BOOTUP_DEBUG, AFAICT neither are used by XFS. the patch is against current parisc-linux cvs. The changes are needed to get xfs to compile. The unrelated fixes (lclear_user) is a bug with the current kernel tree and is being reviewed for inclusion. EARLY_BOOTUP_DEBUG is, well, just a debug option.. :) > That is all of XFS without kdb or kbuild. Save this patched version of > hppa 2.4.17 then make any changes that are required to get XFS working > on hppa. A diff of the saved version against the working version will > show what you had to change to get XFS working on hppa. It should be > very little, ideally the only changes will be for system calls and > defconfigs. yes, that is right. there are only three changes needed for hppa for syscalls and the fcntl constant. defconfig is already updated in the sgi patch i believe. I hope to check the syscall/fcntl changes into our parisc-linux cvs RSN so that the patch will work as is... but for now, for people who want to test xfs on parisc, you need the whole thing... I'll check out the newer patchset and see if there are any differences. thanks, randolph -- @..@ http://www.TauSq.org/ (----) ( >__< ) ^^ ~~ ^^ From owner-linux-xfs@oss.sgi.com Sun Jan 20 09:57:09 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0KHv9f27168 for linux-xfs-outgoing; Sun, 20 Jan 2002 09:57:09 -0800 Received: from vortex.xnote.com ([65.105.237.130]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0KHv4P27146 for ; Sun, 20 Jan 2002 09:57:04 -0800 Received: from xnote.com (slccheck01.firsthealth.com [209.180.88.28]) by vortex.xnote.com (8.11.0/8.8.7) with ESMTP id g0KGv3W29765 for ; Sun, 20 Jan 2002 09:57:03 -0700 Message-ID: <3C4AF6E5.1090604@xnote.com> Date: Sun, 20 Jan 2002 10:57:09 -0600 From: Vernon McPherron User-Agent: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:0.9.7) Gecko/20011221 X-Accept-Language: en-us MIME-Version: 1.0 To: linux-xfs@oss.sgi.com Subject: Re: strange bug in linux-2.4.9-13-xfs References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 828 Lines: 30 Eric Sandeen wrote: > On Sat, 19 Jan 2002, Knut J Bjuland wrote: > > >>XFS seem to have problem when shutdown/loginout from gnome. XFS seems >>to mess up .ICEauthority and ~/.gnome/panel.d in a manner that make it >>impossible to login in gnome from GDM. >> > > Are these files full of null characters? And did this happen after a > system crash, or otherwise non-clean shutdown? > > -Eric > Ah, so I wasn't the only one! My .ICEauthority file was 0 length, and the .gnome dir had many files that was messed up. It MIGHT have been null chars, I don't quite remember. But this would happen after a CLEAN shutdown. I even tried a few syncs then shutdown, still had the same problem. But as Knut Bjuland said, the problem goes away using the CVS kernel. (2.4.17 about 2 weeks ago) -- -=/Vernon McPherron/=- From owner-linux-xfs@oss.sgi.com Sun Jan 20 10:47:08 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0KIl8H27793 for linux-xfs-outgoing; Sun, 20 Jan 2002 10:47:08 -0800 Received: from mail.pangeatech.com (pxofc151-phx1.pangeatech.com [63.110.32.151]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0KIl3P27771 for ; Sun, 20 Jan 2002 10:47:03 -0800 Received: from [65.192.22.133] by mail.pangeatech.com (NTMail 7.00.0018/NU8172.00.e2123c13) with ESMTP id mqzwkaaa for linux-xfs@oss.sgi.com; Sun, 20 Jan 2002 10:47:05 -0700 Received: from randolph by gandalf.tausq.org with local (Exim 3.12 #1 (Debian)) id 16SM3G-0007s4-00; Sun, 20 Jan 2002 09:46:42 -0800 Date: Sun, 20 Jan 2002 09:46:41 -0800 From: Randolph Chung To: Keith Owens Cc: linux-xfs@oss.sgi.com Subject: Re: xfs for parisc-linux Message-ID: <20020120174641.GP21816@tausq.org> Reply-To: Randolph Chung References: <20020120051554.GL21816@tausq.org> <27820.1011505587@ocs3.intra.ocs.com.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <27820.1011505587@ocs3.intra.ocs.com.au> User-Agent: Mutt/1.3.25i X-PGP: for PGP key, see http://www.tausq.org/pgp.txt X-GPG: for GPG key, see http://www.tausq.org/gpg.txt Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 963 Lines: 24 > That is all of XFS without kdb or kbuild. Save this patched version of > hppa 2.4.17 then make any changes that are required to get XFS working > on hppa. A diff of the saved version against the working version will > show what you had to change to get XFS working on hppa. It should be > very little, ideally the only changes will be for system calls and > defconfigs. ok, basically the same changes as before are sufficient. I will check those into our kernel tree so xfs should work more or less as-is on parisc-linux. one thing I did find but haven't investigated completely is that i got an undefined ref to generic_ffs in page_buf_locking.c ... adding a #include fixes it, but I'm not sure why this is only (?) broken on parisc. Perhaps on other platforms it is included via other files. I will look into this some more. randolph -- @..@ http://www.TauSq.org/ (----) ( >__< ) ^^ ~~ ^^ From owner-linux-xfs@oss.sgi.com Mon Jan 21 10:54:18 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0LIsIw03144 for linux-xfs-outgoing; Mon, 21 Jan 2002 10:54:18 -0800 Received: from musuko.uchicago.edu (musuko.uchicago.edu [128.135.39.147]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0LIsCP03120 for ; Mon, 21 Jan 2002 10:54:12 -0800 Received: (from sl70@localhost) by musuko.uchicago.edu (8.11.6/8.11.2) id g0LHs9904847; Mon, 21 Jan 2002 11:54:09 -0600 X-Authentication-Warning: musuko.uchicago.edu: sl70 set sender to s-luppescu@uchicago.edu using -f Subject: How to use Michael Cohen's kernel From: Stuart Luppescu To: Linux XFS List Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-2ainDYFzFkBK8ni4wQ/V" X-Mailer: Evolution/1.0.1 Date: 21 Jan 2002 11:54:08 -0600 Message-Id: <1011635648.4096.6.camel@musuko.uchicago.edu> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 1338 Lines: 38 --=-2ainDYFzFkBK8ni4wQ/V Content-Type: text/plain Content-Transfer-Encoding: quoted-printable I read on the Gentoo web site (http://www.gentoo.org/) that they are using Michael Cohen's new kernel with XFS and it is tremendously fast and stable. However, there is no indication on how to patch the thing. In the mjc section of kernel.org there is a patch, 2.4.17-2.4.18-pre3-mjc3.patch which appears to be against a plain 2.4.17 kernel. And we can get xfs patches from oss.sgi.com. But in what order do we apply the patches? Do we apply the mjc patch first and then the 2.4.18 xfs patch, or the 2.4.17 xfs patch and the the mjc patch? --=20 Stuart Luppescu -=3D- s-luppescu@uchicago.edu=20=20=20=20=20=20=20=20 University of Chicago -=3D- CCSR=20 =1B$B:MJ8$HCRF`H~$NIc=1B(B -=3D- Kernel 2.4.14-xfs=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20 Conscience is what hurts when everything else feels so good.=20 =20 --=-2ainDYFzFkBK8ni4wQ/V Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iEYEABECAAYFAjxMVcAACgkQDBHcBS0tWxNGUgCfU0Jz8u2F/OeFjaNN3eDQLPvo PIoAnjelC3e4t9jTtIpoLFxjyZ3y6rg/ =BwkZ -----END PGP SIGNATURE----- --=-2ainDYFzFkBK8ni4wQ/V-- From owner-linux-xfs@oss.sgi.com Mon Jan 21 11:09:48 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0LJ9m803460 for linux-xfs-outgoing; Mon, 21 Jan 2002 11:09:48 -0800 Received: from deliverator.sgi.com (deliverator.sgi.com [204.94.214.10]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0LJ9iP03438 for ; Mon, 21 Jan 2002 11:09:44 -0800 Received: from relay1.corp.sgi.com (spindle.corp.sgi.com [198.29.75.13]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id KAA14796 for ; Mon, 21 Jan 2002 10:05:20 -0800 (PST) mail_from (sandeen@sgi.com) Received: from chuckle.americas.sgi.com (sandeen@chuckle.americas.sgi.com [128.162.211.44]) by relay1.corp.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) via ESMTP id KAA33138; Mon, 21 Jan 2002 10:09:10 -0800 (PST) Date: Mon, 21 Jan 2002 12:09:09 -0600 (CST) From: Eric Sandeen X-X-Sender: To: Stuart Luppescu cc: Linux XFS List Subject: Re: How to use Michael Cohen's kernel In-Reply-To: <1011635648.4096.6.camel@musuko.uchicago.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 834 Lines: 20 I don't know how cleanly the XFS patch will apply against the -mjc tree, my only suggestion would be to try it and see, and if you have problems with conflicts that you can't resolve, someone on the list may be able to help. -Eric On 21 Jan 2002, Stuart Luppescu wrote: > I read on the Gentoo web site (http://www.gentoo.org/) that they are > using Michael Cohen's new kernel with XFS and it is tremendously fast > and stable. However, there is no indication on how to patch the thing. > In the mjc section of kernel.org there is a patch, > 2.4.17-2.4.18-pre3-mjc3.patch > which appears to be against a plain 2.4.17 kernel. And we can get xfs > patches from oss.sgi.com. But in what order do we apply the patches? Do > we apply the mjc patch first and then the 2.4.18 xfs patch, or the > 2.4.17 xfs patch and the the mjc patch? > From owner-linux-xfs@oss.sgi.com Mon Jan 21 11:17:08 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0LJH8w03803 for linux-xfs-outgoing; Mon, 21 Jan 2002 11:17:08 -0800 Received: from UberGeek.coremetrics.com ([209.184.141.163]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0LJH2P03779 for ; Mon, 21 Jan 2002 11:17:02 -0800 Received: (from austin@localhost) by UberGeek.coremetrics.com (8.11.6/8.11.6) id g0LIG4u20362; Mon, 21 Jan 2002 12:16:04 -0600 X-Authentication-Warning: UberGeek.coremetrics.com: austin set sender to austin@coremetrics.com using -f Subject: XFS Inode Size question. From: Austin Gonyou To: Linux XFS List Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-dq105TKlxMD086b+7Qyh" X-Mailer: Evolution/1.0.1 Date: 21 Jan 2002 12:16:04 -0600 Message-Id: <1011636964.19837.9.camel@UberGeek> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 1017 Lines: 34 --=-dq105TKlxMD086b+7Qyh Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Using isag, I can go look at what the system history is. One thing I've seen is that under inode status, the inode size is very high. I'm not sure what this means particularly. Could somone offer information around this? I start to see this behaviour after about 1-2 hours of running the AIM DB benchmark test.=20 --=20 Austin Gonyou Systems Architect, CCNA Coremetrics, Inc. Phone: 512-698-7250 email: austin@coremetrics.com "It is the part of a good shepherd to shear his flock, not to skin it." Latin Proverb --=-dq105TKlxMD086b+7Qyh Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQA8TFrk94g6ZVmFMoIRAkmvAJ9Hhj+qo/cb08bF48VK7tcgdZ3npwCggn7I 2NJH24zFGuxf8ogN0BliLGk= =yKUD -----END PGP SIGNATURE----- --=-dq105TKlxMD086b+7Qyh-- From owner-linux-xfs@oss.sgi.com Mon Jan 21 11:18:15 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0LJIFO03934 for linux-xfs-outgoing; Mon, 21 Jan 2002 11:18:15 -0800 Received: from qdusa.com ([204.94.79.2]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0LJI8P03911 for ; Mon, 21 Jan 2002 11:18:09 -0800 Received: (from root@localhost) by qdusa.com (8.8.7/8.8.7) id KAA28743 for linux-xfs@oss.sgi.com; Mon, 21 Jan 2002 10:18:04 -0800 Message-Id: <200201211818.KAA28743@qdusa.com> From: Luis Montes To: linux-xfs@oss.sgi.com Date: Mon, 21 Jan 2002 10:17:24 -0800 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Subject: XFS kernel crash and corrupted FS X-mailer: Pegasus Mail for Windows (v2.54) Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 2330 Lines: 51 Hi there, First of all I want to say that the following problem notwithstanding, I have been very happy with linux XFS. I've been using it successfully for a while now. But I've recently upgraded some of my hardware, and there might be some issues that cause the the whole system to crash and burn in the most awful way: My system is as follows: Hardware: AMD Athlon XP 1700 @ 1.4 something GHz ECS K7S5A Motherboard with the SIS 735 chipset 128 MB of PC133 SDRAM memory ATI all-in-wonder Rage 128 agp Two caviar IDE HD CDROM, DVD,SBLive! sound card. Sofware: Linux Slackware 8 2.4.17 kernel with the xfs-2.4.17-all-i386.bz2 and the 2.4.17-1 rml patch gcc 2.95.3, used for all compilations There are 6 different partitions all with XFS installed. xfree86 4.1.99-5 from cvs with DRI enabled and latest ATI-gatos drivers except for some other user software everything else is from the standard Slackware install. The problem: I was just finished installing DRI, and was running glxgears to test it. Then when I tried to list a directory in one of the xfs partitions it reported input/output error. I rebooted and the root filesystem was corrupted beyond repair with the wnsuing kernel panic. I rebooted using other slackware install on the other disk (this one very standard, on an ext2 fs, but with the same xfs-capable kernel) and tried mounting the xfs filesystems on the xfs disk. Three are damaged beyond repair (one actually seems to appear as an ext3! filesystem) and the other three are fine. I would chalk this corruption to some bad interaction between my chipset and the HD's (I had another XFS corruption trying to set the DMA mode on this same HD). But trying to mount one of the damaged fs's actually produces a couple of "unable to handle kernel paging request" errors and the system just freezes. It seems repeatable, three times I tried mounting that filesystem and thre three times I got thar fault. Is this something you guys might want to look more closely? It's been a long long while since I had any kernel problems, and I just read in the FAQ that I might first run ksymoops. I will need to fix it some time soon, though, my wife isn't thrilled that nothing at home seems to be working these days ;) How should I gather info on this error before I go and reformat this HD? From owner-linux-xfs@oss.sgi.com Mon Jan 21 11:31:30 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0LJVUL04278 for linux-xfs-outgoing; Mon, 21 Jan 2002 11:31:30 -0800 Received: from deliverator.sgi.com (deliverator.sgi.com [204.94.214.10]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0LJVSP04256 for ; Mon, 21 Jan 2002 11:31:28 -0800 Received: from relay1.corp.sgi.com (spindle.corp.sgi.com [198.29.75.13]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id KAA16104 for ; Mon, 21 Jan 2002 10:27:04 -0800 (PST) mail_from (sandeen@sgi.com) Received: from chuckle.americas.sgi.com (sandeen@chuckle.americas.sgi.com [128.162.211.44]) by relay1.corp.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) via ESMTP id KAA58243; Mon, 21 Jan 2002 10:30:53 -0800 (PST) Date: Mon, 21 Jan 2002 12:30:52 -0600 (CST) From: Eric Sandeen X-X-Sender: To: Austin Gonyou cc: Linux XFS List Subject: Re: XFS Inode Size question. In-Reply-To: <1011636964.19837.9.camel@UberGeek> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 569 Lines: 15 Can you be a little more specific? I'm not sure what you mean by "the inode size is very high." What does isag mean by "inode size" (xfs inode size is fixed at mkfs time) and what are the numbers? -Eric On 21 Jan 2002, Austin Gonyou wrote: > Using isag, I can go look at what the system history is. One thing I've > seen is that under inode status, the inode size is very high. I'm not > sure what this means particularly. Could somone offer information around > this? I start to see this behaviour after about 1-2 hours of running the > AIM DB benchmark test. > From owner-linux-xfs@oss.sgi.com Mon Jan 21 11:35:16 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0LJZGd04448 for linux-xfs-outgoing; Mon, 21 Jan 2002 11:35:16 -0800 Received: from UberGeek.coremetrics.com ([209.184.141.163]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0LJZ9P04424 for ; Mon, 21 Jan 2002 11:35:09 -0800 Received: (from austin@localhost) by UberGeek.coremetrics.com (8.11.6/8.11.6) id g0LIYKR20477; Mon, 21 Jan 2002 12:34:20 -0600 X-Authentication-Warning: UberGeek.coremetrics.com: austin set sender to austin@coremetrics.com using -f Subject: Re: XFS Inode Size question. From: Austin Gonyou To: Eric Sandeen Cc: Linux XFS List In-Reply-To: References: Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-R7JDS9tN6kpG4AAFMuHP" X-Mailer: Evolution/1.0.1 Date: 21 Jan 2002 12:34:20 -0600 Message-Id: <1011638060.19837.11.camel@UberGeek> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 1506 Lines: 51 --=-R7JDS9tN6kpG4AAFMuHP Content-Type: text/plain Content-Transfer-Encoding: quoted-printable I was hoping someone could run isag real quick and see what I'm talking about. I'm not sure what it means, and the man page isn't the best.=20 On Mon, 2002-01-21 at 12:30, Eric Sandeen wrote: > Can you be a little more specific? I'm not sure what you mean by "the > inode size is very high." What does isag mean by "inode size" (xfs > inode > size is fixed at mkfs time) and what are the numbers? >=20 > -Eric >=20 > On 21 Jan 2002, Austin Gonyou wrote: >=20 > > Using isag, I can go look at what the system history is. One thing > I've > > seen is that under inode status, the inode size is very high. I'm not > > sure what this means particularly. Could somone offer information > around > > this? I start to see this behaviour after about 1-2 hours of running > the > > AIM DB benchmark test. > > --=20 Austin Gonyou Systems Architect, CCNA Coremetrics, Inc. Phone: 512-698-7250 email: austin@coremetrics.com "It is the part of a good shepherd to shear his flock, not to skin it." Latin Proverb --=-R7JDS9tN6kpG4AAFMuHP Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQA8TF8s94g6ZVmFMoIRAvNpAKDM6I74M2L8acTEv6TMP1cXAB/xIwCZAdWE ZpG+nZBckXhRfHI4cP4HUIE= =/tGV -----END PGP SIGNATURE----- --=-R7JDS9tN6kpG4AAFMuHP-- From owner-linux-xfs@oss.sgi.com Mon Jan 21 11:37:44 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0LJbiV04598 for linux-xfs-outgoing; Mon, 21 Jan 2002 11:37:44 -0800 Received: from deliverator.sgi.com (deliverator.sgi.com [204.94.214.10]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0LJbcP04576 for ; Mon, 21 Jan 2002 11:37:38 -0800 Received: from relay1.corp.sgi.com (spindle.corp.sgi.com [198.29.75.13]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id KAA16442 for ; Mon, 21 Jan 2002 10:33:15 -0800 (PST) mail_from (sandeen@sgi.com) Received: from chuckle.americas.sgi.com (sandeen@chuckle.americas.sgi.com [128.162.211.44]) by relay1.corp.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) via ESMTP id KAA62471; Mon, 21 Jan 2002 10:37:05 -0800 (PST) Date: Mon, 21 Jan 2002 12:37:05 -0600 (CST) From: Eric Sandeen X-X-Sender: To: Luis Montes cc: Subject: Re: XFS kernel crash and corrupted FS In-Reply-To: <200201211818.KAA28743@qdusa.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 1305 Lines: 34 On Mon, 21 Jan 2002, Luis Montes wrote: > The problem: > I was just finished installing DRI, and was running glxgears to test > it. Then when I tried to list a directory in one of the xfs > partitions it reported input/output error. I rebooted and the root > filesystem was corrupted beyond repair with the wnsuing kernel panic. How was this determined? Did you try xfs_repair on the filesystem? What was the output? Can you send the output from xfs_repair, if it's failing? Also, are there any messages in your logs concerning a forced shutdown of the filesystem? > Three are > damaged beyond repair (one actually seems to appear as an ext3! > filesystem) This probably means that the xfs superblock is damaged, and mount is finding an old ext3 signature from a previous mkfs. > But trying to mount one of the damaged fs's actually produces a > couple of "unable to handle kernel paging request" errors and the > system just freezes. It seems repeatable, three times I tried > mounting that filesystem and thre three times I got thar fault. Is > this something you guys might want to look more closely? It's been a > long long while since I had any kernel problems, and I just read in > the FAQ that I might first run ksymoops. Yes, the ksymoops output might shed more light on this. -Eric From owner-linux-xfs@oss.sgi.com Mon Jan 21 12:11:20 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0LKBKq10593 for linux-xfs-outgoing; Mon, 21 Jan 2002 12:11:20 -0800 Received: from mailout03.sul.t-online.com (mailout03.sul.t-online.com [194.25.134.81]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0LKBGP10571 for ; Mon, 21 Jan 2002 12:11:16 -0800 Received: from fwd00.sul.t-online.de by mailout03.sul.t-online.com with smtp id 16Sjqa-0004zB-0N; Mon, 21 Jan 2002 20:11:12 +0100 Received: from maryland.danieljust.de (340064116990-0001@[217.227.144.68]) by fmrl00.sul.t-online.com with esmtp id 16SjqX-12rcGmC; Mon, 21 Jan 2002 20:11:09 +0100 Received: by maryland.danieljust.de (Postfix, from userid 1000) id D66C744DF2; Mon, 21 Jan 2002 20:11:08 +0100 (CET) Date: Mon, 21 Jan 2002 20:11:08 +0100 From: Daniel Just To: linux-xfs@oss.sgi.com Subject: Problems after creating a big file with dd Message-ID: <20020121191108.GA1448@maryland.danieljust.de> Mail-Followup-To: Daniel Just , linux-xfs@oss.sgi.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.25i (Linux/2.4.17-xfs (i686)) X-URL: http://www.danieljust.de X-I-live-in: http://www.kronau.de X-Sender: 340064116990-0001@t-dialin.net Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 1052 Lines: 28 Hello list, today I wanted to try what happens if I create a file bigger than 2GB on my debian woody box with 2.4.17-xfs (xfs-2.4.17-all-i386.bz2, should be of 01/10/01, also with preempt-patch 2.4.17-1, compiled with gcc 2.95.4). So I tried as a "normal user" $ dd if=/dev/zero of=bigone bs=1M count=3000 Some time later, dd apparently got stuck at 1.4G, I pressed CTRL-C and it stopped. Having a look at /var/log/messages I found tons of these: Jan 21 14:55:42 maryland kernel: xfs_alloc_read_agf: error in AG 0 Jan 21 14:55:42 maryland kernel: bad agf_magicnum 0x0 Jan 21 14:55:42 maryland kernel: Bad version number 0x0 After umounting that partition, I ran xfs_check and xfs_repair which brought some messages I unfortunately didn't keep. Afterwards I had some stuff in lost+found, also some files got lost. (But I had a backup handy, so... :->) What happened here? XFS-Problem? Hardware-Problem? Compiler-Issue? User-Failure? Please ask, if you need more information. Best regards and thanks in advance, Daniel From owner-linux-xfs@oss.sgi.com Mon Jan 21 12:59:38 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0LKxcL11543 for linux-xfs-outgoing; Mon, 21 Jan 2002 12:59:38 -0800 Received: from UberGeek.coremetrics.com ([209.184.141.163]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0LKxSP11517 for ; Mon, 21 Jan 2002 12:59:28 -0800 Received: (from austin@localhost) by UberGeek.coremetrics.com (8.11.6/8.11.6) id g0LJvrZ20793; Mon, 21 Jan 2002 13:57:53 -0600 X-Authentication-Warning: UberGeek.coremetrics.com: austin set sender to austin@coremetrics.com using -f Subject: Re: Problems after creating a big file with dd From: Austin Gonyou To: Daniel Just Cc: linux-xfs@oss.sgi.com In-Reply-To: <20020121191108.GA1448@maryland.danieljust.de> References: <20020121191108.GA1448@maryland.danieljust.de> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-OyHiS4vGOpG9HA27a6D4" X-Mailer: Evolution/1.0.1 Date: 21 Jan 2002 13:57:53 -0600 Message-Id: <1011643073.19837.14.camel@UberGeek> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 2311 Lines: 69 --=-OyHiS4vGOpG9HA27a6D4 Content-Type: text/plain Content-Transfer-Encoding: quoted-printable It sounds like a possible HW issue. Could also be your partition setup too. You don't have overlapping partitions do you? Just curious.=20=20 In regards to 2.4.17, I'm running it on my 1550 at my desk, but I have problems with that kernel corrupting files from time to time. I'm not sure what the deal is but 2.4.14 was the last kernel I could run without ANY problems what so ever. I'm hoping 2.4.18 will be better.=20 On Mon, 2002-01-21 at 13:11, Daniel Just wrote: > Hello list, >=20 > today I wanted to try what happens if I create a file bigger than 2GB > on my debian woody box with 2.4.17-xfs (xfs-2.4.17-all-i386.bz2, > should be of 01/10/01, also with preempt-patch 2.4.17-1, compiled with > gcc 2.95.4). So I tried as a "normal user"=20 >=20 > $ dd if=3D/dev/zero of=3Dbigone bs=3D1M count=3D3000 >=20 > Some time later, dd apparently got stuck at 1.4G, I pressed CTRL-C and > it stopped. Having a look at /var/log/messages I found tons of these: >=20 > Jan 21 14:55:42 maryland kernel: xfs_alloc_read_agf: error in > AG 0 > Jan 21 14:55:42=20 maryland kernel: bad agf_magicnum 0x0 > Jan 21 14:55:42 maryland kernel: Bad version number 0x0 >=20 > After umounting that partition, I ran xfs_check and xfs_repair > which brought some messages I unfortunately didn't keep. > Afterwards I had some stuff in lost+found, also some files got lost. > (But I had a backup handy, so... :->) >=20 > What happened here? XFS-Problem? Hardware-Problem? Compiler-Issue? > User-Failure? Please ask, if you need more information. >=20 > Best regards and thanks in advance, >=20 > Daniel --=20 Austin Gonyou Systems Architect, CCNA Coremetrics, Inc. Phone: 512-698-7250 email: austin@coremetrics.com "It is the part of a good shepherd to shear his flock, not to skin it." Latin Proverb --=-OyHiS4vGOpG9HA27a6D4 Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQA8THLB94g6ZVmFMoIRAnILAJ95H2ZlP+wlPLs8W6b8efiMMMRRYACgjzJl EJ3rHZQHMXVPen7G0NPHTas= =uBRe -----END PGP SIGNATURE----- --=-OyHiS4vGOpG9HA27a6D4-- From owner-linux-xfs@oss.sgi.com Mon Jan 21 14:16:45 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0LMGjA15928 for linux-xfs-outgoing; Mon, 21 Jan 2002 14:16:45 -0800 Received: from musuko.uchicago.edu (musuko.uchicago.edu [128.135.39.147]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0LMGQP15903 for ; Mon, 21 Jan 2002 14:16:27 -0800 Received: (from sl70@localhost) by musuko.uchicago.edu (8.11.6/8.11.2) id g0LLGMr05842; Mon, 21 Jan 2002 15:16:22 -0600 X-Authentication-Warning: musuko.uchicago.edu: sl70 set sender to s-luppescu@uchicago.edu using -f Subject: Re: How to use Michael Cohen's kernel From: Stuart Luppescu To: Eric Sandeen Cc: Linux XFS List In-Reply-To: References: Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-NDYc10Pqlgb1jMUiYbXQ" X-Mailer: Evolution/1.0.1 Date: 21 Jan 2002 15:16:21 -0600 Message-Id: <1011647781.4096.24.camel@musuko.uchicago.edu> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 3310 Lines: 90 --=-NDYc10Pqlgb1jMUiYbXQ Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: quoted-printable On =1B$B7n=1B(B, 2002-01-21 at 12:09, Eric Sandeen wrote: > I don't know how cleanly the XFS patch will apply against the -mjc tree, > my only suggestion would be to try it and see, and if you have problems > with conflicts that you can't resolve, someone on the list may be able to > help. I applied the xfs patch to the 2.4.17 kernel source, and then applied the mjc patches. I only got 4 rejected hunks, all but one of which was very easy to patch by hand. I just have one question: Here's the original section of code in include/linux/sysctl.h: #if defined(CONFIG_PAGE_BUF) || defined(CONFIG_PAGE_BUF_MODULE) VM_PAGEBUF=3D11, /* struct: Control pagebuf parameters */ #endif VM_MIN_READAHEAD=3D12, /* Min file readahead */ VM_MAX_READAHEAD=3D13 /* Max file readahead */ }; And here's the rejected hunk: --- 140,146 ---- VM_PAGERDAEMON=3D8, /* struct: Control kswapd behaviour */ VM_PGT_CACHE=3D9, /* struct: Set page table cache parameters */ VM_PAGE_CLUSTER=3D10, /* int: set number of pages to swap together */ + VM_MAX_MAP_COUNT=3D11, /* int: Maximum number of active map areas */ VM_MIN_READAHEAD=3D12, /* Min file readahead */ VM_MAX_READAHEAD=3D13 /* Max file readahead */ }; Here's what I have after I patched it by hand: #if defined(CONFIG_PAGE_BUF) || defined(CONFIG_PAGE_BUF_MODULE) VM_PAGEBUF=3D11, /* struct: Control pagebuf parameters */ #endif VM_MIN_READAHEAD=3D12, /* Min file readahead */ VM_MAX_READAHEAD=3D13, /* Max file readahead */ VM_MAX_MAP_COUNT=3D14 /* int: Maximum number of active map areas */ }; The question is, is there anything sacred about the number 11? Can't I just assign it any unused number? Or am I going to make my system go up in smoke? > On 21 Jan 2002, Stuart Luppescu wrote: >=20 > > I read on the Gentoo web site (http://www.gentoo.org/) that they are > > using Michael Cohen's new kernel with XFS and it is tremendously fast > > and stable. However, there is no indication on how to patch the thing. > > In the mjc section of kernel.org there is a patch, > > 2.4.17-2.4.18-pre3-mjc3.patch > > which appears to be against a plain 2.4.17 kernel. And we can get xfs > > patches from oss.sgi.com. But in what order do we apply the patches? Do > > we apply the mjc patch first and then the 2.4.18 xfs patch, or the > > 2.4.17 xfs patch and the the mjc patch? > > --=20 Stuart Luppescu -=3D- s-luppescu@uchicago.edu=20=20=20=20=20=20=20=20 University of Chicago -=3D- CCSR=20 =1B$B:MJ8$HCRF`H~$NIc=1B(B -=3D- Kernel 2.4.14-xfs=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20 The idea is to die young as late as possible. --=20 Ashley Montague=20 =20 --=-NDYc10Pqlgb1jMUiYbXQ Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iEYEABECAAYFAjxMhSUACgkQDBHcBS0tWxNfoQCdF+ki5Uk4lbs2NphN/40jfD4h F2gAoLSUFo86d8BPydjGdXx3BwXtnn2Y =rTkR -----END PGP SIGNATURE----- --=-NDYc10Pqlgb1jMUiYbXQ-- From owner-linux-xfs@oss.sgi.com Mon Jan 21 14:27:48 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0LMRm916210 for linux-xfs-outgoing; Mon, 21 Jan 2002 14:27:48 -0800 Received: from sgi.com (sgi-too.SGI.COM [204.94.211.39]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0LMRiP16184 for ; Mon, 21 Jan 2002 14:27:44 -0800 Received: from relay1.corp.sgi.com (corp.sgi.com [198.29.75.13]) by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id NAA08864 for ; Mon, 21 Jan 2002 13:26:32 -0800 (PST) mail_from (sandeen@sgi.com) Received: from chuckle.americas.sgi.com (sandeen@chuckle.americas.sgi.com [128.162.211.44]) by relay1.corp.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) via ESMTP id NAA43321; Mon, 21 Jan 2002 13:27:10 -0800 (PST) Date: Mon, 21 Jan 2002 15:27:09 -0600 (CST) From: Eric Sandeen X-X-Sender: To: Stuart Luppescu cc: Linux XFS List Subject: Re: How to use Michael Cohen's kernel In-Reply-To: <1011647781.4096.24.camel@musuko.uchicago.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 387 Lines: 12 On 21 Jan 2002, Stuart Luppescu wrote: > The question is, is there anything sacred about the number 11? Can't I > just assign it any unused number? Or am I going to make my system go up > in smoke? Nothing sacred about the number 11, no. What you did is fine, as far as that goes. But per Steve's email, there may be other reasons for your filesystem to go up in smoke... :) -Eric From owner-linux-xfs@oss.sgi.com Mon Jan 21 14:49:06 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0LMn6d16515 for linux-xfs-outgoing; Mon, 21 Jan 2002 14:49:06 -0800 Received: from sgi.com (sgi-too.SGI.COM [204.94.211.39]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0LMn1P16491 for ; Mon, 21 Jan 2002 14:49:01 -0800 Received: from zeus-e8.americas.sgi.com (zeus-e8.americas.sgi.com [128.162.8.103]) by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id NAA01609 for ; Mon, 21 Jan 2002 13:08:48 -0800 (PST) mail_from (lord@sgi.com) Received: from tulip-e185.americas.sgi.com (tulip-e185.americas.sgi.com [128.162.185.208]) by zeus-e8.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id PAA90752; Mon, 21 Jan 2002 15:08:44 -0600 (CST) Received: from sgi.com (Usx0FCjWC8878cl2+GRVJ28FatupddaR@lord-h1.americas.sgi.com [206.11.101.42]) by tulip-e185.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.7) with ESMTP id PAA30878; Mon, 21 Jan 2002 15:08:43 -0600 (CST) Message-ID: <3C4C8362.3040102@sgi.com> Date: Mon, 21 Jan 2002 15:08:50 -0600 From: Stephen Lord User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.7) Gecko/20011226 X-Accept-Language: en-us MIME-Version: 1.0 To: Eric Sandeen CC: Stuart Luppescu , Linux XFS List Subject: Re: How to use Michael Cohen's kernel References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 1098 Lines: 30 Eric Sandeen wrote: >I don't know how cleanly the XFS patch will apply against the -mjc tree, >my only suggestion would be to try it and see, and if you have problems >with conflicts that you can't resolve, someone on the list may be able to >help. > >-Eric > >On 21 Jan 2002, Stuart Luppescu wrote: > >>I read on the Gentoo web site (http://www.gentoo.org/) that they are >>using Michael Cohen's new kernel with XFS and it is tremendously fast >>and stable. However, there is no indication on how to patch the thing. >>In the mjc section of kernel.org there is a patch, >>2.4.17-2.4.18-pre3-mjc3.patch >>which appears to be against a plain 2.4.17 kernel. And we can get xfs >>patches from oss.sgi.com. But in what order do we apply the patches? Do >>we apply the mjc patch first and then the 2.4.18 xfs patch, or the >>2.4.17 xfs patch and the the mjc patch? >> Daniel Robbins of gentoo has been in touch with me separately about problems they are having with xfs in this tree - filesystem corruption. So I would hold off for a while. We are attempting to workout what is going wrong. Steve From owner-linux-xfs@oss.sgi.com Mon Jan 21 15:06:06 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0LN66417093 for linux-xfs-outgoing; Mon, 21 Jan 2002 15:06:06 -0800 Received: from e31.co.us.ibm.com (e31.co.us.ibm.com [32.97.110.129]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0LN61P17071 for ; Mon, 21 Jan 2002 15:06:01 -0800 Received: from westrelay01.boulder.ibm.com (westrelay01.boulder.ibm.com [9.99.140.22]) by e31.co.us.ibm.com (8.9.3/8.9.3) with ESMTP id RAA21090 for ; Mon, 21 Jan 2002 17:02:56 -0500 Received: from d03nm800.boulder.ibm.com (avpilot.boulder.ibm.com [9.17.188.135]) by westrelay01.boulder.ibm.com (8.11.1m3/NCO v5.01) with ESMTP id g0LM5wO38754 for ; Mon, 21 Jan 2002 15:05:58 -0700 Subject: DMAPI and dm_set_return_on_destroy To: linux-xfs@oss.sgi.com X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 Message-ID: From: "James A Goodwin" Date: Mon, 21 Jan 2002 16:05:55 -0600 X-MIMETrack: Serialize by Router on D03NM800/03/M/IBM(Release 5.0.9 |November 16, 2001) at 01/21/2002 03:05:57 PM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 1209 Lines: 31 Hello, I'm still porting a DMAPI application from a DFS environment. Currently, we store some information in a special DM attribute on every file, and when that file is destroyed the attribute is returned with the destroy event. This is set up when the mount event comes in for the file system. Before replying to the event, we use dm_set_return_on_destroy() to tell DMAPI we want that DM attribute returned when objects are destroyed in the file system. However, with XFS I'm getting an EBADF (9). The DMAPI spec says that this indicates that the DM handle "does not refer to an existing or accessible object," but I know the handle is good. I'm using DM_NO_TOKEN as the token, so I tried using the token passed in the mount event and I get an EACCES, which is even worse. I even tried simply using DM_RIGHT_EXCL, but then I get an ESRCH. I find all this confusing especially since rights are supposedly not implemented by the XFS version of DMAPI. Can anyone give me a clue as to what's going on and what I can do to get this call to work properly? Thanks, -James Goodwin Software Engineer IBM Global Services - Federal jagoodwi@us.ibm.com Phone: (281) 336 2578 Fax: (281) 335 4231 T/L 260-2578 From owner-linux-xfs@oss.sgi.com Mon Jan 21 15:17:21 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0LNHLD17433 for linux-xfs-outgoing; Mon, 21 Jan 2002 15:17:21 -0800 Received: from Cantor.suse.de (ns.suse.de [213.95.15.193]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0LNHHP17409 for ; Mon, 21 Jan 2002 15:17:17 -0800 Received: from Hermes.suse.de (Hermes.suse.de [213.95.15.136]) by Cantor.suse.de (Postfix) with ESMTP id 23BCD1EB59; Mon, 21 Jan 2002 23:17:09 +0100 (MET) Date: Mon, 21 Jan 2002 23:17:06 +0100 From: Andi Kleen To: Stuart Luppescu Cc: Eric Sandeen , Linux XFS List Subject: Re: How to use Michael Cohen's kernel Message-ID: <20020121231706.A30684@wotan.suse.de> References: <1011647781.4096.24.camel@musuko.uchicago.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1011647781.4096.24.camel@musuko.uchicago.edu> User-Agent: Mutt/1.3.22.1i Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 556 Lines: 13 > The question is, is there anything sacred about the number 11? Can't I > just assign it any unused number? Or am I going to make my system go up > in smoke? In theory the numbers are an fixed/published ABI (arguments of the sysctl(2) system call). In practice near everybody uses /proc/sys/ and names instead of specifying integer numbers, so it's usually not a problem to change the number of an sysctl arbitarily. In fact the numbering may go away in 2.5, because most people agree it was a mistake to support numbers instead of names only. -Andi From owner-linux-xfs@oss.sgi.com Mon Jan 21 16:47:10 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0M0lAU19329 for linux-xfs-outgoing; Mon, 21 Jan 2002 16:47:10 -0800 Received: from smtpzilla3.xs4all.nl (smtpzilla3.xs4all.nl [194.109.127.139]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0M0l5P19306 for ; Mon, 21 Jan 2002 16:47:05 -0800 Received: from auto-nb1.xs4all.nl (qn-212-58-167-191.quicknet.nl [212.58.167.191]) by smtpzilla3.xs4all.nl (8.12.0/8.12.0) with ESMTP id g0LNl0Xx024740; Tue, 22 Jan 2002 00:47:01 +0100 (CET) Message-Id: <4.3.2.7.2.20020122004128.034dd258@pop.xs4all.nl> X-Sender: knuffie@pop.xs4all.nl X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 22 Jan 2002 00:45:53 +0100 To: Stuart Luppescu , Linux XFS List From: Seth Mos Subject: Re: How to use Michael Cohen's kernel In-Reply-To: <3C4C8362.3040102@sgi.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 976 Lines: 28 At 15:08 21-1-2002 -0600, Stephen Lord wrote: >Eric Sandeen wrote: > >Daniel Robbins of gentoo has been in touch with me separately about problems >they are having with xfs in this tree - filesystem corruption. So I would >hold off >for a while. We are attempting to workout what is going wrong. I suggest that people test a 2.4.17 release well before using it in production. This is the first time that I see a lot off people with filesystem corruption (not to be confused with oopses). 2.4.17 _is_ working alright for a lot of people as well but it is not safe perse. And looking from the gentoo page there are no fixes in 18-pre3 that help out XFS since this probably means they are still seeing problems. People who want to be absolutely safe might better well use 2.4.16. At least that one didn't make filesystem corruption afaik. Cheers -- Seth Every program has two purposes one for which it was written and another for which it wasn't I use the last kind. From owner-linux-xfs@oss.sgi.com Mon Jan 21 20:16:07 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0M4G7023164 for linux-xfs-outgoing; Mon, 21 Jan 2002 20:16:07 -0800 Received: from zok.sgi.com (zok.sgi.com [204.94.215.101]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0M4G1P23138 for ; Mon, 21 Jan 2002 20:16:01 -0800 Received: from zeus-e8.americas.sgi.com (zeus-e8.americas.sgi.com [128.162.8.103]) by zok.sgi.com (8.11.4/8.11.4/linux-outbound_gateway-1.1) with ESMTP id g0M3Fro21802 for ; Mon, 21 Jan 2002 19:15:53 -0800 Received: from tulip-e185.americas.sgi.com (tulip-e185.americas.sgi.com [128.162.185.208]) by zeus-e8.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id VAA93429; Mon, 21 Jan 2002 21:14:37 -0600 (CST) Received: from sgi.com (ToMurTtcvk6wSb1qypvsyNy3gyvNyseD@lord-h1.americas.sgi.com [206.11.101.42]) by tulip-e185.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.7) with ESMTP id VAA43663; Mon, 21 Jan 2002 21:14:37 -0600 (CST) Message-ID: <3C4CD923.80402@sgi.com> Date: Mon, 21 Jan 2002 21:14:43 -0600 From: Stephen Lord User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.7) Gecko/20011226 X-Accept-Language: en-us MIME-Version: 1.0 To: Seth Mos CC: Stuart Luppescu , Linux XFS List Subject: Re: How to use Michael Cohen's kernel References: <4.3.2.7.2.20020122004128.034dd258@pop.xs4all.nl> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 1371 Lines: 39 Seth Mos wrote: > At 15:08 21-1-2002 -0600, Stephen Lord wrote: > >> Eric Sandeen wrote: >> >> Daniel Robbins of gentoo has been in touch with me separately about >> problems >> they are having with xfs in this tree - filesystem corruption. So I >> would hold off >> for a while. We are attempting to workout what is going wrong. > > > I suggest that people test a 2.4.17 release well before using it in > production. This is the first time that I see a lot off people with > filesystem corruption (not to be confused with oopses). > > 2.4.17 _is_ working alright for a lot of people as well but it is not > safe perse. > And looking from the gentoo page there are no fixes in 18-pre3 that > help out XFS since this probably means they are still seeing problems. > > People who want to be absolutely safe might better well use 2.4.16. At > least that one didn't make filesystem corruption afaik. Filesystem corruption at the start of the fs should be gone now in the cvs code, and this was happening after forced shutdown. If someone thinks they have an open corruption issue with 2.4.17 please tell us about it, nothing I have seen so far has been caused by 2.4.17, rather people seem to be doing more things and pushing more problems out into the open. The mjc kernel is a different matter - but then the patch from 2.4.17 is 5.3Mbytes in size. Steve From owner-linux-xfs@oss.sgi.com Tue Jan 22 07:56:57 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0MFuvf11393 for linux-xfs-outgoing; Tue, 22 Jan 2002 07:56:57 -0800 Received: from mailout07.sul.t-online.com (mailout07.sul.t-online.com [194.25.134.83]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0MFunP11369 for ; Tue, 22 Jan 2002 07:56:49 -0800 Received: from fwd04.sul.t-online.de by mailout07.sul.t-online.com with smtp id 16T2Lr-0008LI-06; Tue, 22 Jan 2002 15:56:43 +0100 Received: from maryland.danieljust.de (340064116990-0001@[80.131.153.1]) by fmrl04.sul.t-online.com with esmtp id 16T2Lf-0oQp7oC; Tue, 22 Jan 2002 15:56:31 +0100 Received: by maryland.danieljust.de (Postfix, from userid 1000) id C3EEA44DF2; Tue, 22 Jan 2002 15:56:29 +0100 (CET) Date: Tue, 22 Jan 2002 15:56:29 +0100 From: Daniel Just To: Austin Gonyou Cc: linux-xfs@oss.sgi.com Subject: Re: Problems after creating a big file with dd Message-ID: <20020122145629.GA6280@maryland.danieljust.de> Mail-Followup-To: Daniel Just , Austin Gonyou , linux-xfs@oss.sgi.com References: <20020121191108.GA1448@maryland.danieljust.de> <1011643073.19837.14.camel@UberGeek> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1011643073.19837.14.camel@UberGeek> X-whatever: klar! Organization: WTF? X-URL: http://www.danieljust.de X-I-live-in: http://www.kronau.de X-Sender: 340064116990-0001@t-dialin.net Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 1843 Lines: 57 Hello Austin, thanks for your reply. * Austin Gonyou [21-01-02 20:57]: > It sounds like a possible HW issue. Could also be your partition setup > too. You don't have overlapping partitions do you? Just curious. No. > In regards to 2.4.17, I'm running it on my 1550 at my desk, but I have > problems with that kernel corrupting files from time to time. I'm not I haven't experienced anything like that before, I'm using xfs since 2.4.9 without any trouble. I didn't post about my hardware-setup as suggested in the FAQ: Intel LX Chipset, WDC WD300BB-00AUA1 ATA DISK drive I repeated that test I did yesterday once again and that is what xfs_check told me afterwards: (the first error-entries in /var/log/messages occured when the file had approximately 1GB) (shortened) bad agf magic # 0 in ag 0 bad agf version # 0 in ag 0 block 0/0 expected type unknown got sb bad agi magic # 0 in ag 0 bad agi version # 0 in ag 0 bad magic # 0x58465342 in btbno block 0/0 bad magic # 0x58465342 in btcnt block 0/0 bad magic # 0x58465342 in inobt block 0/0 agi unlinked bucket 0 is 0 in ag 0 (inode=0) agi unlinked bucket 1 is 0 in ag 0 (inode=0) [...] agi unlinked bucket 62 is 0 in ag 0 (inode=0) agi unlinked bucket 63 is 0 in ag 0 (inode=0) block 0/6491 expected type unknown got missing block 0/6492 expected type unknown got missing [...] block 0/814 expected type unknown got missing block 0/815 expected type unknown got missing Doing 'cat file-with-700MB >> otherfile' repeatedly let me produce a file with 9GB without any problems on this partition. [time passes] Finally, I grabbed a kernel from cvs today, and all I can say is that all works fine right now. I've just dd'ed a file with 3GB without any problem. Best Regards, Daniel From owner-linux-xfs@oss.sgi.com Tue Jan 22 08:18:57 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0MGIvI12747 for linux-xfs-outgoing; Tue, 22 Jan 2002 08:18:57 -0800 Received: from zok.sgi.com (zok.sgi.com [204.94.215.101]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0MGImP12725 for ; Tue, 22 Jan 2002 08:18:48 -0800 Received: from zeus-e8.americas.sgi.com (zeus-e8.americas.sgi.com [128.162.8.103]) by zok.sgi.com (8.11.4/8.11.4/linux-outbound_gateway-1.1) with ESMTP id g0MFIfo02509 for ; Tue, 22 Jan 2002 07:18:41 -0800 Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by zeus-e8.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id JAA99587; Tue, 22 Jan 2002 09:17:25 -0600 (CST) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id JAA30070; Tue, 22 Jan 2002 09:17:24 -0600 (CST) Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id g0MFGck01488; Tue, 22 Jan 2002 09:16:38 -0600 Subject: Re: Problems after creating a big file with dd From: Steve Lord To: Daniel Just Cc: Austin Gonyou , linux-xfs@oss.sgi.com In-Reply-To: <20020122145629.GA6280@maryland.danieljust.de> References: <20020121191108.GA1448@maryland.danieljust.de> <1011643073.19837.14.camel@UberGeek> <20020122145629.GA6280@maryland.danieljust.de> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/1.0.1 Date: 22 Jan 2002 09:16:38 -0600 Message-Id: <1011712598.1281.2.camel@jen.americas.sgi.com> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 2635 Lines: 73 On Tue, 2002-01-22 at 08:56, Daniel Just wrote: > Hello Austin, > > thanks for your reply. > > * Austin Gonyou [21-01-02 20:57]: > > > It sounds like a possible HW issue. Could also be your partition setup > > too. You don't have overlapping partitions do you? Just curious. > > No. > > > In regards to 2.4.17, I'm running it on my 1550 at my desk, but I have > > problems with that kernel corrupting files from time to time. I'm not > > I haven't experienced anything like that before, I'm using xfs since > 2.4.9 without any trouble. > > I didn't post about my hardware-setup as suggested in the FAQ: Intel > LX Chipset, WDC WD300BB-00AUA1 ATA DISK drive > > I repeated that test I did yesterday once again and that is what > xfs_check told me afterwards: (the first error-entries in > /var/log/messages occured when the file had approximately 1GB) > (shortened) > > bad agf magic # 0 in ag 0 > bad agf version # 0 in ag 0 > block 0/0 expected type unknown got sb > bad agi magic # 0 in ag 0 > bad agi version # 0 in ag 0 > bad magic # 0x58465342 in btbno block 0/0 > bad magic # 0x58465342 in btcnt block 0/0 > bad magic # 0x58465342 in inobt block 0/0 > agi unlinked bucket 0 is 0 in ag 0 (inode=0) > agi unlinked bucket 1 is 0 in ag 0 (inode=0) > [...] > agi unlinked bucket 62 is 0 in ag 0 (inode=0) > agi unlinked bucket 63 is 0 in ag 0 (inode=0) > block 0/6491 expected type unknown got missing > block 0/6492 expected type unknown got missing > [...] > block 0/814 expected type unknown got missing > block 0/815 expected type unknown got missing > > Doing 'cat file-with-700MB >> otherfile' repeatedly let me produce a > file with 9GB without any problems on this partition. > > [time passes] > > Finally, I grabbed a kernel from cvs today, and all I can say is that > all works fine right now. I've just dd'ed a file with 3GB without any > problem. A change went in late last week which was to fix forced shutdown corrupting the filesystem. However, what it really did was correctly discard a delayed allocate buffer which we had failed to allocate space for on disk for some reason. End result prior to this was a buffer with filedata in it landing on block zero of the partition - which is the superblock. Since you were writing zeros this ties in with what you saw, the data being complained about by xfs_repair is within the first 4K of the partition. Steve -- Steve Lord voice: +1-651-683-3511 Principal Engineer, Filesystem Software email: lord@sgi.com From owner-linux-xfs@oss.sgi.com Tue Jan 22 08:23:24 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0MGNO112977 for linux-xfs-outgoing; Tue, 22 Jan 2002 08:23:24 -0800 Received: from zok.sgi.com (zok.sgi.com [204.94.215.101]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0MGNGP12954 for ; Tue, 22 Jan 2002 08:23:16 -0800 Received: from zeus-e8.americas.sgi.com (zeus-e8.americas.sgi.com [128.162.8.103]) by zok.sgi.com (8.11.4/8.11.4/linux-outbound_gateway-1.1) with ESMTP id g0MFN8o03049 for ; Tue, 22 Jan 2002 07:23:08 -0800 Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by zeus-e8.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id JAA99540; Tue, 22 Jan 2002 09:21:52 -0600 (CST) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id JAA78106; Tue, 22 Jan 2002 09:21:52 -0600 (CST) Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id g0MFL6h01519; Tue, 22 Jan 2002 09:21:06 -0600 Subject: Re: XFS kernel crash and corrupted FS From: Steve Lord To: Luis Montes Cc: linux-xfs@oss.sgi.com In-Reply-To: <200201211818.KAA28743@qdusa.com> References: <200201211818.KAA28743@qdusa.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/1.0.1 Date: 22 Jan 2002 09:21:06 -0600 Message-Id: <1011712866.1281.6.camel@jen.americas.sgi.com> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 2937 Lines: 67 Please take a look on linux kernel, there is a kernel bug which triggers when you use DRI on an AMD processor. There is a good chance you hit this. The problem is related to large page support being incorrectly enabled on these processors. Take a look at this article: http://www.vnunet.com/News/1128504 Steve On Mon, 2002-01-21 at 12:17, Luis Montes wrote: > Hi there, > First of all I want to say that the following problem > notwithstanding, I have been very happy with linux XFS. I've been > using it successfully for a while now. But I've recently upgraded > some of my hardware, and there might be some issues that cause the > the whole system to crash and burn in the most awful way: > > My system is as follows: > > Hardware: > AMD Athlon XP 1700 @ 1.4 something GHz > ECS K7S5A Motherboard with the SIS 735 chipset > 128 MB of PC133 SDRAM memory > ATI all-in-wonder Rage 128 agp > Two caviar IDE HD > CDROM, DVD,SBLive! sound card. > > Sofware: > Linux Slackware 8 > 2.4.17 kernel with the xfs-2.4.17-all-i386.bz2 and the 2.4.17-1 rml > patch > gcc 2.95.3, used for all compilations > There are 6 different partitions all with XFS installed. > xfree86 4.1.99-5 from cvs with DRI enabled and latest ATI-gatos > drivers > except for some other user software everything else is from the > standard Slackware install. > > The problem: > I was just finished installing DRI, and was running glxgears to test > it. Then when I tried to list a directory in one of the xfs > partitions it reported input/output error. I rebooted and the root > filesystem was corrupted beyond repair with the wnsuing kernel panic. > I rebooted using other slackware install on the other disk (this one > very standard, on an ext2 fs, but with the same xfs-capable kernel) > and tried mounting the xfs filesystems on the xfs disk. Three are > damaged beyond repair (one actually seems to appear as an ext3! > filesystem) and the other three are fine. I would chalk this > corruption to some bad interaction between my chipset and the HD's > (I had another XFS corruption trying to set the DMA mode on this same > HD). But trying to mount one of the damaged fs's actually produces a > couple of "unable to handle kernel paging request" errors and the > system just freezes. It seems repeatable, three times I tried > mounting that filesystem and thre three times I got thar fault. Is > this something you guys might want to look more closely? It's been a > long long while since I had any kernel problems, and I just read in > the FAQ that I might first run ksymoops. I will need to fix it some > time soon, though, my wife isn't thrilled that nothing at home seems > to be working these days ;) How should I gather info on this error > before I go and reformat this HD? -- Steve Lord voice: +1-651-683-3511 Principal Engineer, Filesystem Software email: lord@sgi.com From owner-linux-xfs@oss.sgi.com Tue Jan 22 09:19:10 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0MHJAD14454 for linux-xfs-outgoing; Tue, 22 Jan 2002 09:19:10 -0800 Received: from sgi.com (sgi-too.SGI.COM [204.94.211.39]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0MHJ7P14432 for ; Tue, 22 Jan 2002 09:19:07 -0800 Received: from zeus-e8.americas.sgi.com (zeus-e8.americas.sgi.com [128.162.8.103]) by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id IAA06638 for ; Tue, 22 Jan 2002 08:18:59 -0800 (PST) mail_from (lord@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by zeus-e8.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id KAA100077 for ; Tue, 22 Jan 2002 10:14:17 -0600 (CST) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id KAA85513 for ; Tue, 22 Jan 2002 10:14:17 -0600 (CST) From: Steve Lord Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id g0MGDU805791; Tue, 22 Jan 2002 10:13:30 -0600 Message-Id: <200201221613.g0MGDU805791@jen.americas.sgi.com> Date: Tue, 22 Jan 2002 10:13:30 -0600 Subject: TAKE - pagebuf code simplification Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 404 Lines: 15 Fixes a deadlock in some development code. Date: Tue Jan 22 08:12:32 PST 2002 Workarea: jen.americas.sgi.com:/src/lord/xfs-linux.2.4 The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:109977a linux/fs/xfs/pagebuf/page_buf.c - 1.4 - Simplyfy code for reading in a pagebuf, and remove a deadlock from the fs blocksize != pagesize case. From owner-linux-xfs@oss.sgi.com Tue Jan 22 10:31:18 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0MIVI320283 for linux-xfs-outgoing; Tue, 22 Jan 2002 10:31:18 -0800 Received: from sgi.com (sgi-too.SGI.COM [204.94.211.39]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0MIUUP20234 for ; Tue, 22 Jan 2002 10:30:30 -0800 Received: from zeus-e8.americas.sgi.com (zeus-e8.americas.sgi.com [128.162.8.103]) by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id JAA06266 for ; Tue, 22 Jan 2002 09:29:16 -0800 (PST) mail_from (lord@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by zeus-e8.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id LAA101707 for ; Tue, 22 Jan 2002 11:29:11 -0600 (CST) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id LAA88358 for ; Tue, 22 Jan 2002 11:29:11 -0600 (CST) From: Steve Lord Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id g0MHSOZ06059; Tue, 22 Jan 2002 11:28:24 -0600 Message-Id: <200201221728.g0MHSOZ06059@jen.americas.sgi.com> Date: Tue, 22 Jan 2002 11:28:24 -0600 Subject: TAKE - merge up to 2.5.3-pre3 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 16380 Lines: 446 Date: Tue Jan 22 09:24:38 PST 2002 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:109985a linux/drivers/ieee1394/dv1394-private.h - 1.1 linux/drivers/net/wireless/i82586.h - 1.1 linux/drivers/net/wireless/i82593.h - 1.1 linux/drivers/ieee1394/dv1394.c - 1.1 linux/drivers/ieee1394/dv1394.h - 1.1 linux/net/core/wireless.c - 1.1 linux/fs/ext2/ext2.h - 1.1 linux/drivers/usb/hcd/ohci.h - 1.1 linux/drivers/usb/hcd/ohci-q.c - 1.1 linux/drivers/net/wireless/netwave_cs.c - 1.1 linux/drivers/usb/hcd/ohci-mem.c - 1.1 linux/drivers/net/wireless/wavelan.c - 1.1 linux/drivers/net/wireless/wavelan.h - 1.1 linux/drivers/net/wireless/wavelan.p.h - 1.1 linux/drivers/net/wireless/wavelan_cs.c - 1.1 linux/drivers/usb/hcd/ohci-hub.c - 1.1 linux/drivers/usb/hcd/ohci-hcd.c - 1.1 linux/drivers/isdn/hisax/hisax_fcclassic.c - 1.1 linux/drivers/isdn/hisax/hisax_fcclassic.h - 1.1 linux/drivers/isdn/hisax/hisax_hscx.c - 1.1 linux/drivers/isdn/hisax/hisax_hscx.h - 1.1 linux/drivers/usb/hcd/ohci-dbg.c - 1.1 linux/drivers/net/wireless/wavelan_cs.p.h - 1.1 linux/include/net/iw_handler.h - 1.1 linux/drivers/net/wireless/wavelan_cs.h - 1.1 linux/arch/cris/drivers/bluetooth/Makefile - 1.1 linux/include/asm-cris/ethernet.h - 1.1 linux/include/asm-cris/scatterlist.h - 1.1 linux/net/sunrpc/sched.c - 1.24 linux/net/socket.c - 1.29 linux/net/netlink/af_netlink.c - 1.16 linux/net/core/dev.c - 1.49 linux/net/core/Makefile - 1.7 linux/mm/vmscan.c - 1.93 linux/mm/swapfile.c - 1.50 linux/mm/filemap.c - 1.107 linux/kernel/softirq.c - 1.18 linux/kernel/sched.c - 1.54 linux/kernel/printk.c - 1.17 linux/kernel/ksyms.c - 1.128 linux/kernel/fork.c - 1.44 linux/init/main.c - 1.70 linux/include/scsi/sg.h - 1.12 linux/include/linux/wireless.h - 1.8 linux/include/linux/umsdos_fs.p - 1.6 linux/include/linux/ufs_fs_sb.h - 1.5 linux/include/linux/ufs_fs_i.h - 1.5 linux/include/linux/ufs_fs.h - 1.13 linux/include/linux/sched.h - 1.56 linux/include/linux/qnx4_fs_i.h - 1.6 linux/include/linux/qnx4_fs.h - 1.11 linux/include/linux/nfs_fs_i.h - 1.10 linux/include/linux/nfs_fs.h - 1.18 linux/include/linux/netdevice.h - 1.31 linux/include/linux/isdn.h - 1.21 linux/include/linux/hpfs_fs_i.h - 1.4 linux/include/linux/fs.h - 1.143 linux/include/linux/file.h - 1.13 linux/include/linux/ext2_fs_i.h - 1.5 linux/include/linux/ext2_fs.h - 1.19 linux/include/linux/coda_linux.h - 1.13 linux/include/linux/coda_fs_i.h - 1.7 linux/include/linux/coda.h - 1.9 linux/include/linux/blk.h - 1.29 linux/include/linux/amigaffs.h - 1.8 linux/include/linux/affs_fs_i.h - 1.5 linux/include/linux/affs_fs.h - 1.9 linux/include/asm-i386/smplock.h - 1.12 linux/include/asm-i386/mmu_context.h - 1.15 linux/include/asm-arm/arch-rpc/system.h - 1.13 linux/include/asm-arm/arch-nexuspci/system.h - 1.9 linux/include/asm-arm/arch-ebsa285/system.h - 1.13 linux/include/asm-arm/arch-ebsa110/system.h - 1.10 linux/include/asm-arm/arch-arc/system.h - 1.12 linux/fs/vfat/namei.c - 1.23 linux/fs/umsdos/rdir.c - 1.14 linux/fs/umsdos/namei.c - 1.12 linux/fs/umsdos/inode.c - 1.22 linux/fs/umsdos/dir.c - 1.18 linux/fs/ufs/util.c - 1.9 linux/fs/ufs/truncate.c - 1.14 linux/fs/ufs/symlink.c - 1.8 linux/fs/ufs/super.c - 1.23 linux/fs/ufs/namei.c - 1.12 linux/fs/ufs/inode.c - 1.20 linux/fs/ufs/ialloc.c - 1.12 linux/fs/ufs/balloc.c - 1.12 linux/fs/qnx4/inode.c - 1.29 linux/fs/qnx4/fsync.c - 1.8 linux/fs/qnx4/bitmap.c - 1.10 linux/fs/pipe.c - 1.24 linux/fs/nfs/write.c - 1.36 linux/fs/nfs/read.c - 1.28 linux/fs/nfs/inode.c - 1.36 linux/fs/namei.c - 1.46 linux/fs/msdos/namei.c - 1.22 linux/fs/msdos/msdosfs_syms.c - 1.7 linux/fs/inode.c - 1.63 linux/fs/fat/misc.c - 1.12 linux/fs/fat/inode.c - 1.34 linux/fs/fat/file.c - 1.17 linux/fs/fat/dir.c - 1.15 linux/fs/ext2/symlink.c - 1.10 linux/fs/ext2/super.c - 1.24 linux/fs/ext2/namei.c - 1.21 linux/fs/ext2/ioctl.c - 1.9 linux/fs/ext2/inode.c - 1.39 linux/fs/ext2/ialloc.c - 1.22 linux/fs/ext2/fsync.c - 1.12 linux/fs/ext2/file.c - 1.18 linux/fs/ext2/dir.c - 1.18 linux/fs/ext2/bitmap.c - 1.6 linux/fs/ext2/balloc.c - 1.16 linux/fs/devpts/inode.c - 1.12 linux/fs/coda/psdev.c - 1.20 linux/fs/coda/inode.c - 1.18 linux/fs/buffer.c - 1.106 linux/fs/block_dev.c - 1.38 linux/fs/binfmt_misc.c - 1.17 linux/fs/affs/super.c - 1.18 linux/fs/affs/inode.c - 1.16 linux/fs/affs/file.c - 1.23 linux/fs/affs/bitmap.c - 1.7 linux/fs/affs/amigaffs.c - 1.10 linux/drivers/video/vesafb.c - 1.20 linux/drivers/usb/usb.c - 1.64 linux/drivers/usb/uhci.c - 1.57 linux/drivers/usb/hub.c - 1.42 linux/drivers/usb/audio.c - 1.37 linux/drivers/usb/Makefile - 1.47 linux/drivers/scsi/sr.c - 1.37 linux/drivers/scsi/sg.c - 1.28 linux/drivers/scsi/scsi_debug.h - 1.6 linux/drivers/scsi/scsi_debug.c - 1.17 linux/drivers/scsi/advansys.c - 1.23 linux/drivers/net/wavelan.p.h - 1.14 linux/drivers/net/wavelan.h - 1.6 linux/drivers/net/wavelan.c - 1.25 linux/drivers/net/i82586.h - 1.4 linux/drivers/net/acenic.h - 1.18 linux/drivers/net/Makefile - 1.50 linux/drivers/net/Config.in - 1.55 linux/drivers/isdn/isdn_ppp.h - 1.8 linux/drivers/isdn/isdn_ppp.c - 1.22 linux/drivers/isdn/isdn_common.h - 1.9 linux/drivers/isdn/isdn_common.c - 1.32 linux/drivers/isdn/hisax/tei.c - 1.10 linux/drivers/isdn/hisax/netjet.c - 1.18 linux/drivers/isdn/hisax/l3dss1.c - 1.14 linux/drivers/isdn/hisax/l3_1tr6.c - 1.10 linux/drivers/isdn/hisax/isdnl3.c - 1.14 linux/drivers/isdn/hisax/isdnl2.h - 1.6 linux/drivers/isdn/hisax/isdnl2.c - 1.13 linux/drivers/isdn/hisax/isdnl1.c - 1.15 linux/drivers/isdn/hisax/isac.c - 1.12 linux/drivers/isdn/hisax/hscx.c - 1.11 linux/drivers/isdn/hisax/hisax.h - 1.25 linux/drivers/isdn/hisax/hfc_2bs0.c - 1.14 linux/drivers/isdn/hisax/hfc_2bds0.c - 1.14 linux/drivers/isdn/hisax/config.c - 1.27 linux/drivers/isdn/hisax/callc.c - 1.16 linux/drivers/isdn/hisax/Makefile - 1.16 linux/drivers/isdn/avmb1/b1pci.c - 1.18 linux/drivers/isdn/Config.in - 1.22 linux/drivers/char/tty_io.c - 1.41 linux/drivers/char/random.c - 1.24 linux/drivers/char/mem.c - 1.42 linux/drivers/char/lp.c - 1.29 linux/drivers/block/ps2esdi.c - 1.32 linux/drivers/block/ll_rw_blk.c - 1.91 linux/arch/sparc64/kernel/process.c - 1.27 linux/arch/sparc/kernel/process.c - 1.24 linux/arch/ppc/kernel/idle.c - 1.20 linux/arch/mips/kernel/process.c - 1.14 linux/arch/m68k/kernel/process.c - 1.15 linux/arch/i386/math-emu/fpu_entry.c - 1.6 linux/arch/i386/kernel/smp.c - 1.40 linux/arch/i386/kernel/process.c - 1.40 linux/arch/i386/kernel/apm.c - 1.38 linux/arch/i386/defconfig - 1.92 linux/arch/arm/kernel/process.c - 1.23 linux/Makefile - 1.176 linux/MAINTAINERS - 1.92 linux/Documentation/pci.txt - 1.17 linux/Documentation/ioctl-number.txt - 1.19 linux/Documentation/Configure.help - 1.127 linux/Documentation/Changes - 1.43 linux/CREDITS - 1.71 linux/include/linux/ide.h - 1.37 linux/include/linux/efs_fs_i.h - 1.2 linux/include/linux/efs_fs.h - 1.6 linux/fs/hpfs/super.c - 1.13 linux/fs/hpfs/namei.c - 1.13 linux/fs/hpfs/name.c - 1.2 linux/fs/hpfs/inode.c - 1.15 linux/fs/hpfs/hpfs_fn.h - 1.15 linux/fs/hpfs/file.c - 1.17 linux/fs/hpfs/ea.c - 1.5 linux/fs/hpfs/dnode.c - 1.4 linux/fs/hpfs/dir.c - 1.9 linux/fs/hpfs/buffer.c - 1.8 linux/fs/hpfs/anode.c - 1.6 linux/fs/efs/super.c - 1.11 linux/drivers/isdn/hisax/isar.c - 1.16 linux/drivers/isdn/hisax/elsa_ser.c - 1.11 linux/drivers/isdn/hisax/avm_pci.c - 1.13 linux/Documentation/kernel-parameters.txt - 1.14 linux/drivers/char/ppdev.c - 1.28 linux/drivers/parport/parport_pc.c - 1.44 linux/drivers/parport/ieee1284_ops.c - 1.16 linux/drivers/parport/ieee1284.c - 1.13 linux/net/khttpd/main.c - 1.9 linux/include/asm-i386/hw_irq.h - 1.21 linux/drivers/isdn/hisax/jade.c - 1.9 linux/drivers/isdn/hisax/hfc_pci.c - 1.21 linux/arch/i386/kernel/i8259.c - 1.24 linux/arch/sh/kernel/process.c - 1.18 linux/drivers/net/pcmcia/Makefile - 1.20 linux/drivers/net/pcmcia/Config.in - 1.26 linux/arch/i386/kernel/smpboot.c - 1.28 linux/drivers/net/pcmcia/netwave_cs.c - 1.17 linux/drivers/net/pcmcia/i82593.h - 1.3 linux/drivers/net/pcmcia/wavelan_cs.h - 1.10 linux/drivers/net/pcmcia/wavelan_cs.c - 1.13 linux/drivers/net/pcmcia/wavelan.h - 1.3 linux/mm/highmem.c - 1.35 linux/include/asm-arm/arch-sa1100/system.h - 1.14 linux/drivers/isdn/avmb1/t1pci.c - 1.17 linux/drivers/isdn/hisax/w6692.c - 1.11 linux/include/asm-arm/arch-cl7500/system.h - 1.11 linux/kernel/timer.c - 1.17 linux/drivers/i2c/i2c-algo-bit.c - 1.10 linux/drivers/usb/ov511.h - 1.13 linux/drivers/usb/ov511.c - 1.29 linux/include/linux/usbdev_fs_sb.h - 1.3 linux/include/linux/usbdev_fs_i.h - 1.2 linux/drivers/usb/devio.c - 1.24 linux/drivers/ieee1394/raw1394.c - 1.16 linux/drivers/ieee1394/ieee1394_core.h - 1.11 linux/drivers/ieee1394/pcilynx.h - 1.8 linux/drivers/ieee1394/pcilynx.c - 1.16 linux/drivers/ieee1394/ieee1394_core.c - 1.17 linux/drivers/ieee1394/ohci1394.h - 1.13 linux/drivers/ieee1394/ohci1394.c - 1.20 linux/drivers/ieee1394/ieee1394_types.h - 1.11 linux/drivers/ieee1394/ieee1394_transactions.c - 1.9 linux/drivers/ieee1394/ieee1394_syms.c - 1.13 linux/drivers/ieee1394/ieee1394.h - 1.4 linux/drivers/ieee1394/hosts.h - 1.8 linux/drivers/ieee1394/hosts.c - 1.10 linux/drivers/ieee1394/highlevel.h - 1.4 linux/drivers/ieee1394/Config.in - 1.6 linux/drivers/ieee1394/csr.c - 1.7 linux/drivers/ieee1394/Makefile - 1.10 linux/drivers/ieee1394/highlevel.c - 1.7 linux/drivers/usb/usb-uhci.h - 1.10 linux/drivers/usb/usb-uhci.c - 1.35 linux/drivers/usb/usb-ohci.h - 1.16 linux/drivers/usb/usb-ohci.c - 1.33 linux/drivers/usb/ibmcam.h - 1.4 linux/arch/ia64/kernel/process.c - 1.13 linux/drivers/sound/via82cxxx_audio.c - 1.24 linux/drivers/isdn/hisax/hfc_sx.c - 1.11 linux/drivers/isdn/avmb1/c4.c - 1.18 linux/Documentation/filesystems/devfs/README - 1.12 linux/Documentation/filesystems/devfs/ChangeLog - 1.18 linux/fs/devfs/base.c - 1.29 linux/Documentation/IRQ-affinity.txt - 1.2 linux/arch/mips64/kernel/process.c - 1.8 linux/drivers/usb/pegasus.c - 1.24 linux/include/linux/usb.h - 1.26 linux/drivers/usb/serial/ftdi_sio.h - 1.5 linux/drivers/parport/ChangeLog - 1.26 linux/drivers/ide/ide.c - 1.42 linux/drivers/ide/ide-tape.c - 1.18 linux/drivers/ide/ide-floppy.c - 1.15 linux/drivers/ide/ide-disk.c - 1.22 linux/Documentation/DocBook/Makefile - 1.24 linux/Documentation/DocBook/kernel-api.tmpl - 1.15 linux/net/ipv4/netfilter/ip_fw_compat_redir.c - 1.5 linux/drivers/usb/serial/ftdi_sio.c - 1.29 linux/drivers/sound/emu10k1/mixer.c - 1.7 linux/drivers/sound/emu10k1/midi.c - 1.10 linux/drivers/sound/emu10k1/audio.c - 1.14 linux/arch/s390/kernel/process.c - 1.11 linux/Documentation/DocBook/kernel-hacking.tmpl - 1.8 linux/drivers/usb/storage/usb.c - 1.16 linux/drivers/usb/storage/transport.c - 1.17 linux/drivers/usb/storage/protocol.c - 1.7 linux/drivers/usb/serial/keyspan.h - 1.8 linux/drivers/usb/serial/keyspan.c - 1.19 linux/drivers/usb/microtek.c - 1.14 linux/drivers/ieee1394/video1394.c - 1.14 linux/drivers/ieee1394/video1394.h - 1.6 linux/include/linux/mtd/cfi.h - 1.8 linux/drivers/media/video/saa5249.c - 1.6 linux/drivers/media/video/cpia_usb.c - 1.8 linux/drivers/media/video/cpia_pp.c - 1.4 linux/drivers/media/video/cpia.c - 1.10 linux/drivers/media/video/c-qcam.c - 1.8 linux/drivers/media/radio/radio-sf16fmi.c - 1.9 linux/drivers/isdn/hisax/l3ni1.c - 1.7 linux/drivers/isdn/hisax/icc.c - 1.6 linux/drivers/block/cciss.c - 1.28 linux/drivers/block/cciss.h - 1.9 linux/drivers/block/cciss_cmd.h - 1.8 linux/drivers/md/md.c - 1.38 linux/include/asm-arm/arch-tbox/system.h - 1.2 linux/include/linux/cciss_ioctl.h - 1.3 linux/include/linux/dnotify.h - 1.2 linux/mm/oom_kill.c - 1.13 linux/arch/parisc/kernel/process.c - 1.4 linux/include/linux/shmem_fs.h - 1.5 linux/mm/shmem.c - 1.27 linux/fs/reiserfs/journal.c - 1.18 linux/fs/reiserfs/inode.c - 1.22 linux/include/linux/reiserfs_fs_sb.h - 1.7 linux/drivers/usb/storage/unusual_devs.h - 1.8 linux/arch/s390x/kernel/process.c - 1.8 linux/arch/cris/Makefile - 1.9 linux/arch/cris/README.mm - 1.2 linux/arch/cris/boot/compressed/README - 1.2 linux/arch/cris/boot/compressed/misc.c - 1.4 linux/arch/cris/config.in - 1.9 linux/arch/cris/drivers/Config.in - 1.7 linux/arch/cris/drivers/axisflashmap.c - 1.7 linux/arch/cris/drivers/ethernet.c - 1.8 linux/arch/cris/drivers/ide.c - 1.6 linux/arch/cris/drivers/serial.c - 1.10 linux/arch/cris/drivers/serial.h - 1.6 linux/arch/cris/kernel/Makefile - 1.9 linux/arch/cris/kernel/debugport.c - 1.3 linux/arch/cris/kernel/entry.S - 1.11 linux/arch/cris/kernel/head.S - 1.10 linux/arch/cris/kernel/irq.c - 1.8 linux/arch/cris/kernel/kgdb.c - 1.5 linux/arch/cris/kernel/ksyms.c - 1.4 linux/arch/cris/kernel/process.c - 1.12 linux/arch/cris/kernel/ptrace.c - 1.8 linux/arch/cris/kernel/setup.c - 1.10 linux/arch/cris/kernel/shadows.c - 1.3 linux/arch/cris/kernel/sys_cris.c - 1.7 linux/arch/cris/kernel/time.c - 1.6 linux/arch/cris/kernel/traps.c - 1.8 linux/arch/cris/lib/checksum.S - 1.7 linux/arch/cris/lib/checksumcopy.S - 1.8 linux/arch/cris/lib/dmacopy.c - 1.2 linux/arch/cris/lib/old_checksum.c - 1.2 linux/arch/cris/mm/extable.c - 1.4 linux/arch/cris/mm/fault.c - 1.7 linux/arch/cris/mm/init.c - 1.6 linux/include/asm-cris/user.h - 1.2 linux/include/asm-cris/unistd.h - 1.5 linux/include/asm-cris/bitops.h - 1.5 linux/include/asm-cris/elf.h - 1.3 linux/include/asm-cris/processor.h - 1.8 linux/include/asm-cris/pgtable.h - 1.6 linux/include/asm-cris/pgalloc.h - 1.4 linux/include/asm-cris/page.h - 1.2 linux/include/asm-cris/irq.h - 1.8 linux/drivers/usb/serial/io_edgeport.c - 1.18 linux/drivers/scsi/aic7xxx/aic7xxx_linux.c - 1.13 linux/arch/cris/boot/rescue/head.S - 1.5 linux/arch/cris/boot/rescue/kimagerescue.S - 1.5 linux/arch/cris/boot/rescue/testrescue.S - 1.5 linux/arch/cris/drivers/examples/kiobuftest.c - 1.2 linux/arch/cris/drivers/gpio.c - 1.6 linux/arch/cris/drivers/i2c.c - 1.3 linux/arch/cris/drivers/i2c.h - 1.3 linux/arch/cris/drivers/sync_serial.c - 1.3 linux/arch/cris/drivers/usb-host.c - 1.11 linux/arch/cris/lib/dram_init.S - 1.7 linux/arch/mips/math-emu/cp1emu.c - 1.4 linux/drivers/net/wireless/Config.in - 1.4 linux/drivers/net/wireless/Makefile - 1.4 linux/drivers/net/wireless/todo.txt - 1.2 linux/arch/cris/drivers/ds1302.c - 1.4 linux/arch/cris/drivers/eeprom.c - 1.4 linux/arch/cris/drivers/parport.c - 1.7 linux/arch/cris/lib/hw_settings.S - 1.3 linux/drivers/mtd/devices/doc2000.c - 1.3 linux/drivers/mtd/chips/amd_flash.c - 1.4 linux/drivers/usb/se401.c - 1.7 linux/drivers/usb/se401.h - 1.3 linux/arch/mips64/math-emu/cp1emu.c - 1.3 linux/arch/cris/drivers/lpslave/bintocarr.pl - 1.5 linux/arch/cris/drivers/lpslave/e100lpslave.S - 1.4 linux/arch/cris/drivers/lpslave/e100lpslavenet.c - 1.4 linux/drivers/net/au1000_eth.c - 1.4 linux/drivers/net/dl2k.c - 1.8 linux/drivers/ieee1394/sbp2.c - 1.6 linux/drivers/ieee1394/sbp2.h - 1.5 linux/drivers/ieee1394/nodemgr.c - 1.8 linux/drivers/ieee1394/nodemgr.h - 1.5 linux/drivers/usb/kaweth.c - 1.10 linux/drivers/usb/usbvideo.h - 1.5 linux/drivers/usb/usbvideo.c - 1.5 linux/drivers/isdn/hisax/st5481.h - 1.4 linux/drivers/isdn/hisax/st5481_d.c - 1.6 linux/drivers/isdn/hisax/st5481_usb.c - 1.7 linux/drivers/i2c/i2c-algo-ite.c - 1.4 linux/fs/jffs2/background.c - 1.5 linux/fs/jffs2/erase.c - 1.4 linux/fs/jffs2/nodemgmt.c - 1.3 linux/drivers/char/mwave/3780i.c - 1.2 linux/drivers/usb/hpusbscsi.c - 1.4 linux/drivers/usb/serial/ir-usb.c - 1.8 linux/fs/ext3/ialloc.c - 1.6 linux/fs/ext3/inode.c - 1.5 linux/fs/ext3/ioctl.c - 1.2 linux/fs/ext3/namei.c - 1.2 linux/fs/ext3/super.c - 1.9 linux/fs/ext3/symlink.c - 1.2 linux/drivers/hotplug/cpqphp_core.c - 1.2 linux/fs/intermezzo/journal_ext3.c - 1.3 linux/fs/intermezzo/journal_obdfs.c - 1.3 linux/fs/intermezzo/journal_reiserfs.c - 1.3 linux/fs/intermezzo/kml_reint.c - 1.2 linux/include/linux/ext3_jbd.h - 1.3 linux/include/linux/ext3_fs_i.h - 1.2 linux/include/linux/ext3_fs.h - 1.3 linux/fs/jbd/commit.c - 1.3 linux/drivers/usb/hcd.c - 1.4 linux/drivers/usb/hcd/Config.in - 1.3 linux/drivers/usb/hcd/Makefile - 1.3 linux/drivers/usb/hcd/ehci-hcd.c - 1.3 linux/drivers/usb/hcd/ehci-hub.c - 1.2 linux/drivers/usb/hcd/ehci-q.c - 1.4 linux/drivers/usb/hcd/ehci-sched.c - 1.3 linux/drivers/usb/stv680.h - 1.2 linux/drivers/usb/stv680.c - 1.3 linux/drivers/usb/vicam.c - 1.3 linux/drivers/usb/vicam.h - 1.2 linux/drivers/usb/auerswald.c - 1.3 linux/fs/Makefile.lib - 1.2 linux/include/linux/init_task.h - 1.2 linux/drivers/ide/ide-taskfile.c - 1.2 From owner-linux-xfs@oss.sgi.com Tue Jan 22 11:02:11 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0MJ2Bq27387 for linux-xfs-outgoing; Tue, 22 Jan 2002 11:02:11 -0800 Received: from goliath.sylaba.poznan.pl (root@goliath.sylaba.poznan.pl [195.216.104.3]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0MJ1wP27365 for ; Tue, 22 Jan 2002 11:02:00 -0800 Received: from venus.local.navi.pl (ps103.poznan.sdi.tpnet.pl [217.97.72.103]) by goliath.sylaba.poznan.pl (8.11.6/8.10.1) with ESMTP id g0MI1p902158; Tue, 22 Jan 2002 19:01:51 +0100 (CET) Received: from venus.local.navi.pl (venus.local.navi.pl [192.168.1.10]) by venus.local.navi.pl (8.11.6/8.9.3) with ESMTP id g0MHpUR01773; Tue, 22 Jan 2002 18:51:31 +0100 Date: Tue, 22 Jan 2002 18:51:30 +0100 From: Olaf =?iso-8859-2?Q?Fr=B1czyk?= To: Austin Gonyou Cc: Olaf =?iso-8859-2?Q?Fr=B1czyk?= , Stephen Lord , linux-xfs@oss.sgi.com Subject: Re: problem with VMware -XFS guilty one - was: Re: XFS is innocen t Message-ID: <20020122185130.A1579@venus.local.navi.pl> References: <20020117194821.A3800@venus.local.navi.pl> <1011293832.26356.13.camel@UberGeek> Mime-Version: 1.0 Content-Type: text/plain; format=flowed; charset=ISO-8859-2 Content-Transfer-Encoding: 8bit In-Reply-To: <1011293832.26356.13.camel@UberGeek>; from austin@coremetrics.com on Thu, Jan 17, 2002 at 19:57:12 +0100 X-Mailer: Balsa 1.2.4 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 1210 Lines: 31 On 2002.01.17 19:57:12 +0100 Austin Gonyou wrote: > Go the drive maker's web site and see if they have a diagnostic utility > you boot from a floppy(will probably be dos based, so be prepared), and > run that. That is the ONLY way to tell if it's truly bad or not. > Hi, So I summarize a little below: 1. I took DFT (Drive fitness test) from IBM and tested these disks. The tests took several hours, but no error was found. 2. I putted my old mb (intel 440BX + celeron) And .. crash. So I was wrong, and it is not related to VIA or AMD chips. 3. About the time I changed my motherboard I also changed vmware version. So Vmware 2.0 worked OK, 3.0-beta- 99% OK (AFAIR), 3.0 - crashes. 4. If I use ext2 filesystem for /tmp all things (including vmware) work perfectly. 5. If I use xfs for /tmp, then vmware on some partitons works OK (sda4), on some other crashes (sdb3 and sdb6). It crashes in less than 1 minute (about 20-30 seconds). 6. All other things work OK regardless if I use xfs or ext2. I also played quite hard with the /tmp partition - tarring and untarring big things under load (about 3). 7. It all happens on kernels 2.4.5 and 2.4.17. So, what do you suggest to try next? Regards, Olaf From owner-linux-xfs@oss.sgi.com Tue Jan 22 11:35:45 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0MJZjX28059 for linux-xfs-outgoing; Tue, 22 Jan 2002 11:35:45 -0800 Received: from pneumatic-tube.sgi.com (pneumatic-tube.sgi.com [204.94.214.22]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0MJZXP28037 for ; Tue, 22 Jan 2002 11:35:34 -0800 Received: from zeus-e8.americas.sgi.com (zeus-e8.americas.sgi.com [128.162.8.103]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id KAA09004 for ; Tue, 22 Jan 2002 10:36:23 -0800 (PST) mail_from (lord@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by zeus-e8.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id MAA102514; Tue, 22 Jan 2002 12:34:13 -0600 (CST) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id MAA89923; Tue, 22 Jan 2002 12:34:13 -0600 (CST) Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id g0MIXPP06153; Tue, 22 Jan 2002 12:33:25 -0600 Subject: Re: problem with VMware -XFS guilty one - was: Re: XFS is innocen t From: Steve Lord To: Olaf =?iso-8859-2?Q?Fr=B1czyk?= Cc: Austin Gonyou , linux-xfs@oss.sgi.com In-Reply-To: <20020122185130.A1579@venus.local.navi.pl> References: <20020117194821.A3800@venus.local.navi.pl> <1011293832.26356.13.camel@UberGeek> <20020122185130.A1579@venus.local.navi.pl> Content-Type: text/plain; charset=iso-8859-2 X-Mailer: Evolution/1.0.1 Date: 22 Jan 2002 12:33:25 -0600 Message-Id: <1011724405.1281.46.camel@jen.americas.sgi.com> Mime-Version: 1.0 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id g0MJZZP28038 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 1528 Lines: 42 On Tue, 2002-01-22 at 11:51, Olaf Fr±czyk wrote: > On 2002.01.17 19:57:12 +0100 Austin Gonyou wrote: > > Go the drive maker's web site and see if they have a diagnostic utility > > you boot from a floppy(will probably be dos based, so be prepared), and > > run that. That is the ONLY way to tell if it's truly bad or not. > > > Hi, > > So I summarize a little below: > > 1. I took DFT (Drive fitness test) from IBM and tested these disks. > The tests took several hours, but no error was found. > 2. I putted my old mb (intel 440BX + celeron) > And .. crash. > So I was wrong, and it is not related to VIA or AMD chips. > 3. About the time I changed my motherboard I also changed vmware version. > So Vmware 2.0 worked OK, 3.0-beta- 99% OK (AFAIR), 3.0 - crashes. > 4. If I use ext2 filesystem for /tmp all things (including vmware) work > perfectly. > 5. If I use xfs for /tmp, then vmware on some partitons works OK (sda4), > on some other crashes (sdb3 and sdb6). It crashes in less than 1 minute > (about 20-30 seconds). > 6. All other things work OK regardless if I use xfs or ext2. I also played > quite hard with the /tmp partition - tarring and untarring big things > under load (about 3). > 7. It all happens on kernels 2.4.5 and 2.4.17. > > So, what do you suggest to try next? Have you tried a current cvs kernel from oss.sgi.com? Steve > > Regards, > > Olaf -- Steve Lord voice: +1-651-683-3511 Principal Engineer, Filesystem Software email: lord@sgi.com From owner-linux-xfs@oss.sgi.com Tue Jan 22 12:08:06 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0MK86K28694 for linux-xfs-outgoing; Tue, 22 Jan 2002 12:08:06 -0800 Received: from yog-sothoth.sgi.com (eugate.sgi.com [192.48.160.10]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0MK82P28672 for ; Tue, 22 Jan 2002 12:08:03 -0800 Received: from zeus-e8.americas.sgi.com (zeus-e8.americas.sgi.com [128.162.8.103]) by yog-sothoth.sgi.com (980305.SGI.8.8.8-aspam-6.2/980304.SGI-aspam-europe) via ESMTP id UAA493635 for ; Tue, 22 Jan 2002 20:06:53 +0100 (CET) mail_from (roehrich@sgi.com) Received: from thistle-e185.americas.sgi.com (thistle-e185.americas.sgi.com [128.162.185.204]) by zeus-e8.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id NAA103138 for ; Tue, 22 Jan 2002 13:06:34 -0600 (CST) Received: from clink.americas.sgi.com (clink-eth.americas.sgi.com [128.162.2.8]) by thistle-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id NAA56943 for ; Tue, 22 Jan 2002 13:06:34 -0600 (CST) Received: (from roehrich@localhost) by clink.americas.sgi.com (SGI-8.9.3/8.9.3/erikj-IRIX) id NAA12503 for linux-xfs@oss.sgi.com; Tue, 22 Jan 2002 13:06:34 -0600 (CST) Date: Tue, 22 Jan 2002 13:06:34 -0600 (CST) From: Dean Roehrich Message-Id: <200201221906.NAA12503@clink.americas.sgi.com> To: linux-xfs@oss.sgi.com Subject: TAKE - Change dmapi test tool, set_return_on_destroy, to take fshandle Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 350 Lines: 12 Date: Tue Jan 22 11:05:08 PST 2002 Workarea: clink-eth.americas.sgi.com:/data/clink/a67/roehrich/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:109993a cmd/xfstests/dmapi/src/common/cmd/set_return_on_destroy.c - 1.5 - change set_return_on_destroy tool to take a fshandle From owner-linux-xfs@oss.sgi.com Tue Jan 22 12:10:57 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0MKAvu28919 for linux-xfs-outgoing; Tue, 22 Jan 2002 12:10:57 -0800 Received: from yog-sothoth.sgi.com (eugate.sgi.com [192.48.160.10]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0MKApP28897 for ; Tue, 22 Jan 2002 12:10:52 -0800 Received: from zeus-e8.americas.sgi.com (zeus-e8.americas.sgi.com [128.162.8.103]) by yog-sothoth.sgi.com (980305.SGI.8.8.8-aspam-6.2/980304.SGI-aspam-europe) via ESMTP id UAA489142 for ; Tue, 22 Jan 2002 20:09:47 +0100 (CET) mail_from (eric@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by zeus-e8.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id NAA103081 for ; Tue, 22 Jan 2002 13:09:31 -0600 (CST) Received: from stout.americas.sgi.com (stout.americas.sgi.com [128.162.187.5]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id NAA01789 for ; Tue, 22 Jan 2002 13:09:30 -0600 (CST) Received: by stout.americas.sgi.com (8.11.6/SGI-client-1.7) id g0MJ9Ux19774; Tue, 22 Jan 2002 13:09:30 -0600 Message-Id: <200201221909.g0MJ9Ux19774@stout.americas.sgi.com> Date: Tue, 22 Jan 2002 13:09:30 -0600 From: Eric Sandeen Subject: TAKE - Clean up large file handling. Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 1147 Lines: 37 Although XFS can handle (2^63-1) file sizes, Linux can't. The Linux VM uses a 32 bit page number index to index cache data, so 2^32 * PAGE_SIZE is as big as you can go. Define XFS_MAX_FILE_OFFSET accordingly. Having done that, XFS would still happily seek & truncate to greater than that value; seek was fixed by using generic_file_llseek for XFS's seek: method, and truncate was fixed by checking for an error from inode_setattr() in linvfs_notify_change. Date: Tue Jan 22 11:03:35 PST 2002 Workarea: stout.americas.sgi.com:/localhome/eric/2.4.x-xfs/workarea-reallyclean The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: xfs-cmds:slinx:109992a cmd/xfsprogs/include/xfs_inode.h - 1.11 - Reduce XFS_MAX_FILE_OFFSET to something Linux can handle Modid: 2.4.x-xfs:slinx:109992b linux/fs/xfs/xfs_inode.h - 1.152 - Reduce XFS_MAX_FILE_OFFSET to something Linux can handle linux/fs/xfs/linux/xfs_file.c - 1.57 - Use generic_file_llseek for the seek: method (default_llseek doesn't do size checking) linux/fs/xfs/linux/xfs_iops.c - 1.119 - Do error checking on inode_setattr() return From owner-linux-xfs@oss.sgi.com Tue Jan 22 12:31:30 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0MKVUe29426 for linux-xfs-outgoing; Tue, 22 Jan 2002 12:31:30 -0800 Received: from justice.loyola.edu (root@justice.loyola.edu [144.126.178.227]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0MKVRP29404 for ; Tue, 22 Jan 2002 12:31:27 -0800 Received: (from mstone@localhost) by justice.loyola.edu (8.9.3/8.9.3/Debian 8.9.3-21) id OAA04029 for linux-xfs@oss.sgi.com; Tue, 22 Jan 2002 14:31:20 -0500 Date: Tue, 22 Jan 2002 14:31:20 -0500 From: Michael Stone To: linux-xfs@oss.sgi.com Subject: Re: Shrinking an XFS filesystem is a crucial feature! Message-ID: <20020122143120.G19778@justice.loyola.edu> Mail-Followup-To: linux-xfs@oss.sgi.com References: <3C496C9A.8030204@sgi.com> <1011476477.5714.3.camel@UberGeek> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <1011476477.5714.3.camel@UberGeek>; from austin@coremetrics.com on Sat, Jan 19, 2002 at 03:41:17PM -0600 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 739 Lines: 16 On Sat, Jan 19, 2002 at 03:41:17PM -0600, Austin Gonyou wrote: > That said, I was merely trying to offer what I believe the target > audience will want. It seems that the target audience would be those > using Veritas and the like. Sorry for rubbing you the wrong way, I don't As a counterpoint, I'd consider at least part of the target audience to be people who need really big, really fast filesystems. In that audience there's not a lot of demand for shrinking: people want as much space as possible, usually in really big chunks. The space is allocated carefully so partitions are aligned across very large disk arrays in order to maximize performance. If you shrink your volume you're going to lose that alignment. -- Mike Stone From owner-linux-xfs@oss.sgi.com Tue Jan 22 12:36:16 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0MKaGA29641 for linux-xfs-outgoing; Tue, 22 Jan 2002 12:36:16 -0800 Received: from angelica.keck.waisman.wisc.edu (angelica.keck.waisman.wisc.edu [128.104.232.125]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0MKa7P29619 for ; Tue, 22 Jan 2002 12:36:07 -0800 Received: (from pederson@localhost) by angelica.keck.waisman.wisc.edu (8.11.6/8.11.6) id g0MJZwC12433; Tue, 22 Jan 2002 13:35:58 -0600 Date: Tue, 22 Jan 2002 13:35:58 -0600 From: Adrian Pederson To: Eric Sandeen , Adam Hupp , linux-xfs@oss.sgi.com Subject: lockup with 2.4.17-xfs (Was: Frequent hangs with 2.4.9-xfs-1.0.2) Message-ID: <20020122133557.C9758@angelica.keck.waisman.wisc.edu> References: <20020117200246.B1859@upl.cs.wisc.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from Eric Sandeen on Thu, Jan 17, 2002 at 10:09:17PM -0600 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 4030 Lines: 65 On Thu, Jan 17, 2002 at 10:09:17PM -0600, Eric Sandeen wrote: >There were some fixes that went into CVS around the end of the year that >may well fix your problem. Unfortunately, neither of the 1.0.2 kernels >have these fixes. If you can, I'd suggest testing either the 2.4.17 >snapshot patch, or doing a fresh CVS checkout. On Saturday I dl'ed and built the CVS kernel, it was running fine until I logged a few minutes ago and started rebuilding the kernel to add ipchains, then it locked up. The console would still let me type in the username but wouldn't bring up the password prompt. Anyway, it seems to be a problem with nfsd and xfs. Here's the dump, any ideas? kernel: Unable to handle kernel NULL pointer dereference at virtual address 00000030 kernel: printing eip: kernel: c0191419 kernel: *pde = 00000000 kernel: Oops: 0000 kernel: CPU: 1 kernel: EIP: 0010:[xfs_alloc_lookup+329/916] Not tainted kernel: EIP: 0010:[] Not tainted kernel: EFLAGS: 00010246 kernel: eax: 00000000 ebx: 00000000 ecx: 00000000 edx: 00000000 kernel: esi: 00000000 edi: 00000001 ebp: 00000001 esp: f739f5a0 kernel: ds: 0018 es: 0018 ss: 0018 kernel: Process nfsd (pid: 1048, stackpage=f739f000) kernel: Stack: dc6480a0 00000001 00000000 f739f648 0007e600 f739f648 0000058e ea8b87e8 kernel: ed3676a0 00000000 00000000 ddcbb200 f739f604 00000018 ffffff14 98800038 kernel: 00000000 00000246 f739f6e4 00000004 00000131 f7978800 00000000 00000007 kernel: Call Trace: [xfs_alloc_lookup_eq+32/40] [xfs_alloc_fixup_trees+109/516] [xfs_alloc _ag_vextent_near+828/2628] [xfs_alloc_ag_vextent+54/200] [xfs_alloc_vextent+918/1092] kernel: Call Trace: [] [] [] [] [] kernel: [ip_rcv+802/920] [xfs_bmap_alloc+8066/8960] [do_softirq+131/224] [kmem_alloc+12 2/304] [kmem_free+34/40] [xfs_mod_incore_sb+43/60] kernel: [] [] [] [] [] [] kernel: [xfs_bmbt_get_state+51/60] [xfs_bmbt_get_state+51/60] [xfs_bmap_do_search_exten ts+923/964] [xfs_bmapi+2241/4892] [scsi_queue_next_request+79/288] [__scsi_end_request+296 /308] kernel: [] [] [] [] [] [] kernel: [xlog_grant_push_ail+71/376] [xlog_grant_log_space+190/640] [xfs_strategy+1608/ 2268] [__make_request+438/1604] [generic_make_request+158/292] [submit_bh+64/92] kernel: [] [] [] [] [] [] kernel: [convert_page+182/224] [convert_page+214/224] [linvfs_pb_bmap+123/196] [pagebuf _delalloc_convert+68/208] [pagebuf_write_full_page+107/420] [linvfs_pb_bmap+0/196] kernel: [] [] [] [] [] [] kernel: [linvfs_write_full_page+15/32] [linvfs_pb_bmap+0/196] [shrink_cache+480/888] [s hrink_caches+97/136] [try_to_free_pages+53/84] [balance_classzone+104/388] kernel: [] [] [] [] [] [] kernel: [__alloc_pages+289/380] [_alloc_pages+24/28] [do_generic_file_read+852/1108] [g eneric_file_read+146/396] [file_read_actor+0/224] [xfs_read+325/552] kernel: [] [] [] [] [] [] kernel: [xfs_ilock_ra+76/148] [xfs_read+453/552] [linvfs_read+127/176] [nfsd_read+531/6 92] [linvfs_read+0/176] [nfsd3_proc_read+294/404] kernel: [] [] [] [] [] [] kernel: [nfsd_dispatch+203/408] [svc_process+653/1316] [nfsd+427/856] [kernel_thread+35 /48] kernel: [] [] [] [] kernel: kernel: Code: 8b 52 30 89 54 24 58 51 55 8b 44 24 60 50 8b 54 24 78 52 e8 -- Adrian Pederson Voice: 608-265-6608 System Administrator FAX: 608-265-8737 W. M. Keck Laboratory for Functional Brain Imaging and Behavior Waisman Center University of Wisconsin - Madison From owner-linux-xfs@oss.sgi.com Tue Jan 22 12:48:15 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0MKmF429888 for linux-xfs-outgoing; Tue, 22 Jan 2002 12:48:15 -0800 Received: from moutvdom01.kundenserver.de (moutvdom01.kundenserver.de [195.20.224.200]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0MKm7P29866 for ; Tue, 22 Jan 2002 12:48:07 -0800 Received: from [172.19.20.61] (helo=mrvdomng0.kundenserver.de) by moutvdom01.kundenserver.de with esmtp (Exim 2.12 #2) id 16T6tl-0002lC-00; Tue, 22 Jan 2002 20:48:01 +0100 Received: from [217.228.146.82] (helo=kernelpanix.aura.of.mankind) by mrvdomng0.kundenserver.de with esmtp (Exim 3.22 #2) id 16T6tk-0007Nu-00; Tue, 22 Jan 2002 20:48:00 +0100 Received: (from utz@localhost) by kernelpanix.aura.of.mankind (8.11.2/8.11.2) id g0MJihg12633; Tue, 22 Jan 2002 20:44:43 +0100 X-Authentication-Warning: kernelpanix.aura.of.mankind: utz set sender to xfs@s2y4n2c.de using -f Date: Tue, 22 Jan 2002 20:44:43 +0100 From: utz lehmann To: Eric Sandeen Cc: linux-xfs@oss.sgi.com Subject: Re: TAKE - Clean up large file handling. Message-ID: <20020122204443.A12581@s2y4n2c.de> References: <200201221909.g0MJ9Ux19774@stout.americas.sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200201221909.g0MJ9Ux19774@stout.americas.sgi.com> Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 1398 Lines: 48 Hi Eric Will this fix the fs corruption with 8exabyte sized files? http://oss.sgi.com/projects/xfs/mail_archive/0110/msg00522.html utz Eric Sandeen [sandeen@sgi.com] wrote: > Although XFS can handle (2^63-1) file sizes, Linux can't. > The Linux VM uses a 32 bit page number index to index cache data, so > 2^32 * PAGE_SIZE is as big as you can go. Define XFS_MAX_FILE_OFFSET > accordingly. > > Having done that, XFS would still happily seek & truncate to greater > than that value; seek was fixed by using generic_file_llseek for > XFS's seek: method, and truncate was fixed by checking for an error > from inode_setattr() in linvfs_notify_change. > > > Date: Tue Jan 22 11:03:35 PST 2002 > Workarea: stout.americas.sgi.com:/localhome/eric/2.4.x-xfs/workarea-reallyclean > > The following file(s) were checked into: > bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs > > > Modid: xfs-cmds:slinx:109992a > cmd/xfsprogs/include/xfs_inode.h - 1.11 > - Reduce XFS_MAX_FILE_OFFSET to something Linux can handle > > > > > Modid: 2.4.x-xfs:slinx:109992b > linux/fs/xfs/xfs_inode.h - 1.152 > - Reduce XFS_MAX_FILE_OFFSET to something Linux can handle > > linux/fs/xfs/linux/xfs_file.c - 1.57 > - Use generic_file_llseek for the seek: method > (default_llseek doesn't do size checking) > > linux/fs/xfs/linux/xfs_iops.c - 1.119 > - Do error checking on inode_setattr() return > From owner-linux-xfs@oss.sgi.com Tue Jan 22 13:06:13 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0ML6DQ30463 for linux-xfs-outgoing; Tue, 22 Jan 2002 13:06:13 -0800 Received: from fruit.eu.org (qmailr@34dyn8.com21.casema.net [212.64.15.8]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0ML66P30439 for ; Tue, 22 Jan 2002 13:06:06 -0800 Received: (qmail 58951 invoked by uid 500); 22 Jan 2002 20:06:02 -0000 Date: Tue, 22 Jan 2002 21:06:02 +0100 From: Wessel Dankers To: linux-xfs@oss.sgi.com Subject: Re: TAKE - Clean up large file handling. Message-ID: <20020122210601.O25522@fruit.eu.org> Mail-Followup-To: linux-xfs@oss.sgi.com References: <200201221909.g0MJ9Ux19774@stout.americas.sgi.com> <20020122204443.A12581@s2y4n2c.de> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-md5; protocol="application/pgp-signature"; boundary="GBuTPvBEOL0MYPgd" Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20020122204443.A12581@s2y4n2c.de>; from xfs@s2y4n2c.de on Tue, Jan 22, 2002 at 08:44:43PM +0100 X-oi: oi Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 843 Lines: 37 --GBuTPvBEOL0MYPgd Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On 2002-01-22 20:44:43+0100, utz lehmann wrote: > Hi Eric >=20 > Will this fix the fs corruption with 8exabyte sized files? >=20 > http://oss.sgi.com/projects/xfs/mail_archive/0110/msg00522.html That problem was caused by two problems in tandem, both of which are fixed in CVS, AFAICT. Regards, -- Wessel Dankers Sysadmins busy fighting SPAM. --GBuTPvBEOL0MYPgd Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (FreeBSD) Comment: For info see http://www.gnupg.org iD8DBQE8TcYpwSIMlSIEfyYRAgsXAJ4zM8yh548xGbN3RQcTmwYDYAdAywCgiRIX Cp9GTc6ztMw4OKSZpi4D9os= =m+bR -----END PGP SIGNATURE----- --GBuTPvBEOL0MYPgd-- From owner-linux-xfs@oss.sgi.com Tue Jan 22 13:37:02 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0MLb2o31035 for linux-xfs-outgoing; Tue, 22 Jan 2002 13:37:02 -0800 Received: from pneumatic-tube.sgi.com (pneumatic-tube.sgi.com [204.94.214.22]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0MLavP31010 for ; Tue, 22 Jan 2002 13:36:57 -0800 Received: from ledzep.americas.sgi.com (ledzep.americas.sgi.com [137.38.226.97]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id MAA09806 for ; Tue, 22 Jan 2002 12:37:48 -0800 (PST) mail_from (nstraz@sgi.com) Received: from maine.americas.sgi.com (maine.americas.sgi.com [128.162.191.42]) by ledzep.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id OAA51105 for ; Tue, 22 Jan 2002 14:35:39 -0600 (CST) Received: from nstraz by maine.americas.sgi.com with local (Exim 3.33 #1 (Debian)) id 16T7dq-0006hz-00 for ; Tue, 22 Jan 2002 14:35:38 -0600 Date: Tue, 22 Jan 2002 14:35:38 -0600 From: Nathan Straz To: Linux XFS List Subject: Re: XFS Inode Size question. Message-ID: <20020122203538.GC17521@sgi.com> Mail-Followup-To: Linux XFS List References: <1011638060.19837.11.camel@UberGeek> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1011638060.19837.11.camel@UberGeek> User-Agent: Mutt/1.3.25i Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 1658 Lines: 36 On Mon, Jan 21, 2002 at 12:34:20PM -0600, Austin Gonyou wrote: > On Mon, 2002-01-21 at 12:30, Eric Sandeen wrote: > > On 21 Jan 2002, Austin Gonyou wrote: > > > Using isag, I can go look at what the system history is. One thing > > > I've seen is that under inode status, the inode size is very high. > > > I'm not sure what this means particularly. Could somone offer > > > information around this? I start to see this behaviour after about > > > 1-2 hours of running the AIM DB benchmark test. > > > > Can you be a little more specific? I'm not sure what you mean by > > "the inode size is very high." What does isag mean by "inode size" > > (xfs inode size is fixed at mkfs time) and what are the numbers? > > > I was hoping someone could run isag real quick and see what I'm talking > about. I'm not sure what it means, and the man page isn't the best. I installed it and took a look at it. I think it's a matter of poorly chosen labels. Here's the trip... inode-sz (label in inode status graph of isag) inode_used (field stored by sysstat) field 1 from /proc/sys/fs/inode-state (as seen in sadc.c:1165) inodes_stat (from linux/kernel/sysctl.c:295) inodes_stat_t.nr_inodes (from linux/include/linux/fs.h:57) I'm not too familiar with the places that inodes_stat is used. It appears more like the in-kernel inodes that are available. I'll let someone with more understanding of the kernel internals finish the answer. -- 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 Jan 22 13:47:01 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0MLl1A31235 for linux-xfs-outgoing; Tue, 22 Jan 2002 13:47:01 -0800 Received: from zok.sgi.com (zok.sgi.com [204.94.215.101]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0MLkuP31213 for ; Tue, 22 Jan 2002 13:46:56 -0800 Received: from zeus-e8.americas.sgi.com (zeus-e8.americas.sgi.com [128.162.8.103]) by zok.sgi.com (8.11.4/8.11.4/linux-outbound_gateway-1.1) with ESMTP id g0MKkno04843 for ; Tue, 22 Jan 2002 12:46:49 -0800 Received: from poppy-e185.americas.sgi.com (poppy-e185.americas.sgi.com [128.162.185.207]) by zeus-e8.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id OAA104497; Tue, 22 Jan 2002 14:45:33 -0600 (CST) Received: from stout.americas.sgi.com (stout.americas.sgi.com [128.162.187.5]) by poppy-e185.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.7) with ESMTP id OAA02277; Tue, 22 Jan 2002 14:45:33 -0600 (CST) Subject: Re: TAKE - Clean up large file handling. From: Eric Sandeen To: Wessel Dankers Cc: linux-xfs@oss.sgi.com In-Reply-To: <20020122210601.O25522@fruit.eu.org> References: <200201221909.g0MJ9Ux19774@stout.americas.sgi.com> <20020122204443.A12581@s2y4n2c.de> <20020122210601.O25522@fruit.eu.org> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/1.0 (Preview Release) Date: 22 Jan 2002 14:45:33 -0600 Message-Id: <1011732333.20441.2.camel@stout.americas.sgi.com> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 1174 Lines: 35 On Tue, 2002-01-22 at 14:06, Wessel Dankers wrote: > On 2002-01-22 20:44:43+0100, utz lehmann wrote: > > Hi Eric > > > > Will this fix the fs corruption with 8exabyte sized files? Yes, because you can no longer make 8exabyte sized files. :) [root@lite sda2]# seq 1 100 | dd of=BIG1 bs=1024 seek=9007199254740991 dd: advancing past 9223372036854774784 bytes in output file `BIG1': File too large However, "seq 1 100 | dd of=BIG1 bs=1024 seek=17179869185" will bump you right up against the max file size limit; my filesystem is perfectly happy after this. > That problem was caused by two problems in tandem, both of which are fixed > in CVS, AFAICT. That's also correct; XFS was allowing too-large file sizes. This was causing errors and a filesystem shutdown, shutdown was causing corruption. (aiee!) Shutdown no longer causes corruption*, and XFS won't allow too-large files anymore. -Eric *It seems that some recent change exposed this bug, if forced_shutdown had been corrupting filesystems all along, we would probably have known about it a lot sooner... -- Eric Sandeen XFS for Linux http://oss.sgi.com/projects/xfs sandeen@sgi.com SGI, Inc. From owner-linux-xfs@oss.sgi.com Tue Jan 22 13:50:39 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0MLodi31376 for linux-xfs-outgoing; Tue, 22 Jan 2002 13:50:39 -0800 Received: from UberGeek.coremetrics.com ([209.184.141.163]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0MLoTP31352 for ; Tue, 22 Jan 2002 13:50:29 -0800 Received: (from austin@localhost) by UberGeek.coremetrics.com (8.11.6/8.11.6) id g0MKnhU02462; Tue, 22 Jan 2002 14:49:43 -0600 X-Authentication-Warning: UberGeek.coremetrics.com: austin set sender to austin@coremetrics.com using -f Subject: Re: XFS Inode Size question. From: Austin Gonyou To: Nathan Straz Cc: Linux XFS List In-Reply-To: <20020122203538.GC17521@sgi.com> References: <20020122203538.GC17521@sgi.com> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-k5pj4niL23i/1zkfTHJ/" X-Mailer: Evolution/1.0.1 Date: 22 Jan 2002 14:49:43 -0600 Message-Id: <1011732583.2182.2.camel@UberGeek> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 2885 Lines: 73 --=-k5pj4niL23i/1zkfTHJ/ Content-Type: text/plain Content-Transfer-Encoding: quoted-printable That's what it looked like to me as well, but df -i still shows a decent percentage of inodes free. That's what I'm getting wrapped around right now. I wasn't sure if it was relating to how many inodes are/were used, or if data extending to a certain number of blocks was making the other inodes unuseable. I've never heard of that happening, but I was curious just the same.=20 On Tue, 2002-01-22 at 14:35, Nathan Straz wrote: > On Mon, Jan 21, 2002 at 12:34:20PM -0600, Austin Gonyou wrote: > > On Mon, 2002-01-21 at 12:30, Eric Sandeen wrote: > > > On 21 Jan 2002, Austin Gonyou wrote: > > > > Using isag, I can go look at what the system history is. One thing > > > > I've seen is that under inode status, the inode size is very high. > > > > I'm not sure what this means particularly. Could somone offer > > > > information around this? I start to see this behaviour after about > > > > 1-2 hours of running the AIM DB benchmark test. > > >=20 > > > Can you be a little more specific? I'm not sure what you mean by > > > "the inode size is very high." What does isag mean by "inode size" > > > (xfs inode size is fixed at mkfs time) and what are the numbers? > > >=20 > > I was hoping someone could run isag real quick and see what I'm > talking > > about. I'm not sure what it means, and the man page isn't the best.=20 >=20 > I installed it and took a look at it. I think it's a matter of poorly > chosen labels. Here's the trip... >=20 > inode-sz (label in inode status graph of isag) > inode_used (field stored by sysstat) > field 1 from /proc/sys/fs/inode-state (as seen in sadc.c:1165) > inodes_stat (from linux/kernel/sysctl.c:295) > inodes_stat_t.nr_inodes (from linux/include/linux/fs.h:57) >=20 > I'm not too familiar with the places that inodes_stat is used. It > appears more like the in-kernel inodes that are available.=20=20 >=20 > I'll let someone with more understanding of the kernel internals finish > the answer.=20 >=20 > --=20 > Nate Straz nstraz@sgi.com > sgi, inc http://www.sgi.com/ > Linux Test Project http://ltp.sf.net/ --=20 Austin Gonyou Systems Architect, CCNA Coremetrics, Inc. Phone: 512-698-7250 email: austin@coremetrics.com "It is the part of a good shepherd to shear his flock, not to skin it." Latin Proverb --=-k5pj4niL23i/1zkfTHJ/ Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQA8TdBn94g6ZVmFMoIRAlUZAKCJmz0PfTLWHvF4rVQ6o8cssWkkigCgqdxt GLTxzwYUhHpjWlhj8t6ukJ4= =+Py8 -----END PGP SIGNATURE----- --=-k5pj4niL23i/1zkfTHJ/-- From owner-linux-xfs@oss.sgi.com Tue Jan 22 13:56:07 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0MLu7631559 for linux-xfs-outgoing; Tue, 22 Jan 2002 13:56:07 -0800 Received: from sgi.com (sgi-too.SGI.COM [204.94.211.39]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0MLu4P31537 for ; Tue, 22 Jan 2002 13:56:04 -0800 Received: from zeus-e8.americas.sgi.com (zeus-e8.americas.sgi.com [128.162.8.103]) by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id MAA04259 for ; Tue, 22 Jan 2002 12:54:52 -0800 (PST) mail_from (lord@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by zeus-e8.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id OAA104460; Tue, 22 Jan 2002 14:54:45 -0600 (CST) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id OAA91760; Tue, 22 Jan 2002 14:54:45 -0600 (CST) Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id g0MKrv807304; Tue, 22 Jan 2002 14:53:57 -0600 Subject: Re: XFS Inode Size question. From: Steve Lord To: Austin Gonyou Cc: Nathan Straz , Linux XFS List In-Reply-To: <1011732583.2182.2.camel@UberGeek> References: <20020122203538.GC17521@sgi.com> <1011732583.2182.2.camel@UberGeek> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/1.0.1 Date: 22 Jan 2002 14:53:56 -0600 Message-Id: <1011732836.1281.118.camel@jen.americas.sgi.com> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 865 Lines: 21 On Tue, 2002-01-22 at 14:49, Austin Gonyou wrote: > That's what it looked like to me as well, but df -i still shows a decent > percentage of inodes free. That's what I'm getting wrapped around right > now. I wasn't sure if it was relating to how many inodes are/were used, > or if data extending to a certain number of blocks was making the other > inodes unuseable. I've never heard of that happening, but I was curious > just the same. I am pretty sure these numbers refer to in memory inode pools, not to on disk inode availability. Besides which when xfs reports how many inodes are free, it is reporting how many inodes could be created in the filesystem - which at 256 bytes per inode is usually a lot. Steve -- Steve Lord voice: +1-651-683-3511 Principal Engineer, Filesystem Software email: lord@sgi.com From owner-linux-xfs@oss.sgi.com Tue Jan 22 14:04:20 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0MM4KM31833 for linux-xfs-outgoing; Tue, 22 Jan 2002 14:04:20 -0800 Received: from UberGeek.coremetrics.com ([209.184.141.163]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0MM4BP31808 for ; Tue, 22 Jan 2002 14:04:12 -0800 Received: (from austin@localhost) by UberGeek.coremetrics.com (8.11.6/8.11.6) id g0ML3US13115; Tue, 22 Jan 2002 15:03:30 -0600 X-Authentication-Warning: UberGeek.coremetrics.com: austin set sender to austin@coremetrics.com using -f Subject: Re: XFS Inode Size question. From: Austin Gonyou To: Steve Lord Cc: Nathan Straz , Linux XFS List In-Reply-To: <1011732836.1281.118.camel@jen.americas.sgi.com> References: <1011732836.1281.118.camel@jen.americas.sgi.com> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-fkj2kZgbyqHwCwkKe92o" X-Mailer: Evolution/1.0.1 Date: 22 Jan 2002 15:03:30 -0600 Message-Id: <1011733410.2180.16.camel@UberGeek> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 1945 Lines: 60 --=-fkj2kZgbyqHwCwkKe92o Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Does this mean then that the "inode_sz" measurement shown is the amount of references or some such thing in memory? If so, it never seems to decrease. I don't notice a whole lot of memory in use though, even now. I've not rebooted the machine for a while either.=20 On Tue, 2002-01-22 at 14:53, Steve Lord wrote: > On Tue, 2002-01-22 at 14:49, Austin Gonyou wrote: > > That's what it looked like to me as well, but df -i still shows a > decent > > percentage of inodes free. That's what I'm getting wrapped around > right > > now. I wasn't sure if it was relating to how many inodes are/were > used, > > or if data extending to a certain number of blocks was making the > other > > inodes unuseable. I've never heard of that happening, but I was > curious > > just the same.=20 >=20 > I am pretty sure these numbers refer to in memory inode pools, not to > on disk inode availability. Besides which when xfs reports how many > inodes are free, it is reporting how many inodes could be created in > the filesystem - which at 256 bytes per inode is usually a lot. >=20 > Steve >=20 >=20 > --=20 >=20 > Steve Lord voice: +1-651-683-3511 > Principal Engineer, Filesystem Software email: lord@sgi.com --=20 Austin Gonyou Systems Architect, CCNA Coremetrics, Inc. Phone: 512-698-7250 email: austin@coremetrics.com "It is the part of a good shepherd to shear his flock, not to skin it." Latin Proverb --=-fkj2kZgbyqHwCwkKe92o Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQA8TdOi94g6ZVmFMoIRApnGAJ479zs2tY0TWRVB8DqBLjoi6I7KnACggYgt k4ZG48LF422AsxIu0/MXOqc= =aFKz -----END PGP SIGNATURE----- --=-fkj2kZgbyqHwCwkKe92o-- From owner-linux-xfs@oss.sgi.com Tue Jan 22 14:05:47 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0MM5lt31989 for linux-xfs-outgoing; Tue, 22 Jan 2002 14:05:47 -0800 Received: from UberGeek.coremetrics.com ([209.184.141.163]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0MM5dP31949 for ; Tue, 22 Jan 2002 14:05:39 -0800 Received: (from austin@localhost) by UberGeek.coremetrics.com (8.11.6/8.11.6) id g0ML4pO14072; Tue, 22 Jan 2002 15:04:51 -0600 X-Authentication-Warning: UberGeek.coremetrics.com: austin set sender to austin@coremetrics.com using -f Subject: Re: XFS Inode Size question. From: Austin Gonyou To: Steve Lord Cc: Nathan Straz , Linux XFS List In-Reply-To: <1011732836.1281.118.camel@jen.americas.sgi.com> References: <1011732836.1281.118.camel@jen.americas.sgi.com> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-ke4/JqtrAZNULx8cSoim" X-Mailer: Evolution/1.0.1 Date: 22 Jan 2002 15:04:51 -0600 Message-Id: <1011733491.2172.18.camel@UberGeek> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 1854 Lines: 59 --=-ke4/JqtrAZNULx8cSoim Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Scratch that...it just dropped back down about an hour ago. I wonder why that would be? I mounted a loopback device around that time. Could that have anything to do with it? On Tue, 2002-01-22 at 14:53, Steve Lord wrote: > On Tue, 2002-01-22 at 14:49, Austin Gonyou wrote: > > That's what it looked like to me as well, but df -i still shows a > decent > > percentage of inodes free. That's what I'm getting wrapped around > right > > now. I wasn't sure if it was relating to how many inodes are/were > used, > > or if data extending to a certain number of blocks was making the > other > > inodes unuseable. I've never heard of that happening, but I was > curious > > just the same.=20 >=20 > I am pretty sure these numbers refer to in memory inode pools, not to > on disk inode availability. Besides which when xfs reports how many > inodes are free, it is reporting how many inodes could be created in > the filesystem - which at 256 bytes per inode is usually a lot. >=20 > Steve >=20 >=20 > --=20 >=20 > Steve Lord voice: +1-651-683-3511 > Principal Engineer, Filesystem Software email: lord@sgi.com --=20 Austin Gonyou Systems Architect, CCNA Coremetrics, Inc. Phone: 512-698-7250 email: austin@coremetrics.com "It is the part of a good shepherd to shear his flock, not to skin it." Latin Proverb --=-ke4/JqtrAZNULx8cSoim Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQA8TdPz94g6ZVmFMoIRAo1aAJoCOXa52p1zatIlkaYXZEiwSFnEkQCfZfAP NioQRTFYDoJURMSDlbPlXF4= =6kqJ -----END PGP SIGNATURE----- --=-ke4/JqtrAZNULx8cSoim-- From owner-linux-xfs@oss.sgi.com Tue Jan 22 14:08:09 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0MM89C32193 for linux-xfs-outgoing; Tue, 22 Jan 2002 14:08:09 -0800 Received: from deliverator.sgi.com (deliverator.sgi.com [204.94.214.10]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0MM82P32171 for ; Tue, 22 Jan 2002 14:08:02 -0800 Received: from zeus-e8.americas.sgi.com (zeus-e8.americas.sgi.com [128.162.8.103]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id NAA23755 for ; Tue, 22 Jan 2002 13:03:38 -0800 (PST) mail_from (lord@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by zeus-e8.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id PAA105056; Tue, 22 Jan 2002 15:06:44 -0600 (CST) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id PAA53488; Tue, 22 Jan 2002 15:06:43 -0600 (CST) Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id g0ML5tZ07319; Tue, 22 Jan 2002 15:05:55 -0600 Subject: Re: XFS Inode Size question. From: Steve Lord To: Austin Gonyou Cc: Nathan Straz , Linux XFS List In-Reply-To: <1011733491.2172.18.camel@UberGeek> References: <1011732836.1281.118.camel@jen.americas.sgi.com> <1011733491.2172.18.camel@UberGeek> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/1.0.1 Date: 22 Jan 2002 15:05:55 -0600 Message-Id: <1011733555.1279.120.camel@jen.americas.sgi.com> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 1746 Lines: 51 On Tue, 2002-01-22 at 15:04, Austin Gonyou wrote: > Scratch that...it just dropped back down about an hour ago. I wonder why > that would be? I mounted a loopback device around that time. Could that > have anything to do with it? About the only thing which would shrink it is a memory shortage, one of the things this can cause is a shrink of the inode cache. Steve > > On Tue, 2002-01-22 at 14:53, Steve Lord wrote: > > On Tue, 2002-01-22 at 14:49, Austin Gonyou wrote: > > > That's what it looked like to me as well, but df -i still shows a > > decent > > > percentage of inodes free. That's what I'm getting wrapped around > > right > > > now. I wasn't sure if it was relating to how many inodes are/were > > used, > > > or if data extending to a certain number of blocks was making the > > other > > > inodes unuseable. I've never heard of that happening, but I was > > curious > > > just the same. > > > > I am pretty sure these numbers refer to in memory inode pools, not to > > on disk inode availability. Besides which when xfs reports how many > > inodes are free, it is reporting how many inodes could be created in > > the filesystem - which at 256 bytes per inode is usually a lot. > > > > Steve > > > > > > -- > > > > Steve Lord voice: +1-651-683-3511 > > Principal Engineer, Filesystem Software email: lord@sgi.com > -- > Austin Gonyou > Systems Architect, CCNA > Coremetrics, Inc. > Phone: 512-698-7250 > email: austin@coremetrics.com > > "It is the part of a good shepherd to shear his flock, not to skin it." > Latin Proverb -- Steve Lord voice: +1-651-683-3511 Principal Engineer, Filesystem Software email: lord@sgi.com From owner-linux-xfs@oss.sgi.com Tue Jan 22 14:23:11 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0MMNBj32554 for linux-xfs-outgoing; Tue, 22 Jan 2002 14:23:11 -0800 Received: from UberGeek.coremetrics.com ([209.184.141.163]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0MMN0P32530 for ; Tue, 22 Jan 2002 14:23:00 -0800 Received: (from austin@localhost) by UberGeek.coremetrics.com (8.11.6/8.11.6) id g0MLMAh18560; Tue, 22 Jan 2002 15:22:10 -0600 X-Authentication-Warning: UberGeek.coremetrics.com: austin set sender to austin@coremetrics.com using -f Subject: Re: XFS Inode Size question. From: Austin Gonyou To: Steve Lord Cc: Nathan Straz , Linux XFS List In-Reply-To: <1011733555.1279.120.camel@jen.americas.sgi.com> References: <1011733555.1279.120.camel@jen.americas.sgi.com> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-QCHfJxDNJqwzkfzxSZyj" X-Mailer: Evolution/1.0.1 Date: 22 Jan 2002 15:22:10 -0600 Message-Id: <1011734530.18360.0.camel@UberGeek> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 2831 Lines: 89 --=-QCHfJxDNJqwzkfzxSZyj Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Interesting you'd say that cause my DBA is creating the oracle instance on that machine right now, and we're swapping. His SGA is only about 2GB though, the rest is in cached when I look at top. On Tue, 2002-01-22 at 15:05, Steve Lord wrote: > On Tue, 2002-01-22 at 15:04, Austin Gonyou wrote: > > Scratch that...it just dropped back down about an hour ago. I wonder > why > > that would be? I mounted a loopback device around that time. Could > that > > have anything to do with it? >=20 > About the only thing which would shrink it is a memory shortage, one > of the things this can cause is a shrink of the inode cache. >=20 > Steve >=20 > >=20 > > On Tue, 2002-01-22 at 14:53, Steve Lord wrote: > > > On Tue, 2002-01-22 at 14:49, Austin Gonyou wrote: > > > > That's what it looked like to me as well, but df -i still shows a > > > decent > > > > percentage of inodes free. That's what I'm getting wrapped around > > > right > > > > now. I wasn't sure if it was relating to how many inodes are/were > > > used, > > > > or if data extending to a certain number of blocks was making the > > > other > > > > inodes unuseable. I've never heard of that happening, but I was > > > curious > > > > just the same.=20 > > >=20 > > > I am pretty sure these numbers refer to in memory inode pools, not > to > > > on disk inode availability. Besides which when xfs reports how many > > > inodes are free, it is reporting how many inodes could be created in > > > the filesystem - which at 256 bytes per inode is usually a lot. > > >=20 > > > Steve > > >=20 > > >=20 > > > --=20 > > >=20 > > > Steve Lord voice: > +1-651-683-3511 > > > Principal Engineer, Filesystem Software email: lord@sgi.com > > --=20 > > Austin Gonyou > > Systems Architect, CCNA > > Coremetrics, Inc. > > Phone: 512-698-7250 > > email: austin@coremetrics.com > >=20 > > "It is the part of a good shepherd to shear his flock, not to skin > it." > > Latin Proverb > --=20 >=20 > Steve Lord voice: +1-651-683-3511 > Principal Engineer, Filesystem Software email: lord@sgi.com --=20 Austin Gonyou Systems Architect, CCNA Coremetrics, Inc. Phone: 512-698-7250 email: austin@coremetrics.com "It is the part of a good shepherd to shear his flock, not to skin it." Latin Proverb --=-QCHfJxDNJqwzkfzxSZyj Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQA8TdgC94g6ZVmFMoIRAiZXAJ9lDlECfi4Dwm4XNioeiixw6WH2wQCg2bm9 3CnanqkaZ6zrjR4FX60SpHI= =jCEY -----END PGP SIGNATURE----- --=-QCHfJxDNJqwzkfzxSZyj-- From owner-linux-xfs@oss.sgi.com Tue Jan 22 14:34:14 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0MMYEx32749 for linux-xfs-outgoing; Tue, 22 Jan 2002 14:34:14 -0800 Received: from pneumatic-tube.sgi.com (pneumatic-tube.sgi.com [204.94.214.22]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0MMY5P32725 for ; Tue, 22 Jan 2002 14:34:05 -0800 Received: from zeus-e8.americas.sgi.com (zeus-e8.americas.sgi.com [128.162.8.103]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id NAA05907 for ; Tue, 22 Jan 2002 13:34:56 -0800 (PST) mail_from (roehrich@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by zeus-e8.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id PAA105348; Tue, 22 Jan 2002 15:32:46 -0600 (CST) Received: from slobber.americas.sgi.com (slobber.americas.sgi.com [128.162.187.52]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id PAA24896; Tue, 22 Jan 2002 15:32:46 -0600 (CST) Received: from slobber.americas.sgi.com by slobber.americas.sgi.com (SGI-8.9.3/SGI-client-1.7) via ESMTP id PAA72435; Tue, 22 Jan 2002 15:32:46 -0600 (CST) Message-Id: <200201222132.PAA72435@slobber.americas.sgi.com> To: "James A Goodwin" cc: linux-xfs@oss.sgi.com Subject: Re: DMAPI and dm_set_return_on_destroy Date: Tue, 22 Jan 2002 15:32:45 -0600 From: Dean Roehrich Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 2298 Lines: 70 James, I verified that dm_set_return_on_destroy() does work, if the filesystem is already mounted. However, it doesn't work in mid-mount, as you are trying to do. This behavior matches what you will see on Irix. In dm_handle_to_vp() we are making sure that nothing happens until a filesystem's state has been changed from DM_STATE_MOUNTING to DM_STATE_MOUNTED. I thought maybe it was too early for the VFS_ROOT() to succeed, but I tried it anyway on Linux and it worked in the one simple case that I gave it. Because this restriction exists on both Irix and Linux, and because this function is downwind of 30 or 40 or more other functions (only a few of which I have examined), I'm not going to give much priority to changing it. I will try the fix shown below in my Irix and Linux kernels for a while and maybe someday I'll have a chance to give it a decent beating on Irix; I'll sit on this until then. Dean *** /usr/tmp/TmpDir.908390-0/linux/fs/xfs_dmapi/dmapi_register.c_1.2 Tue Jan 22 15:19:44 2002 --- linux/fs/xfs_dmapi/dmapi_register.c Tue Jan 22 15:15:40 2002 *************** *** 466,477 **** if ((fsrp = dm_find_fsreg_and_lock((fsid_t*)&handlep->ha_fsid, &lc)) == NULL) return(NULL); ! if (fsrp->fr_state == DM_STATE_MOUNTING) { mutex_spinunlock(&fsrp->fr_lock, lc); return(NULL); } for (;;) { if (fsrp->fr_state == DM_STATE_MOUNTED) break; if (fsrp->fr_state == DM_STATE_UNMOUNTED) { --- 466,484 ---- if ((fsrp = dm_find_fsreg_and_lock((fsid_t*)&handlep->ha_fsid, &lc)) == NULL) return(NULL); ! fidp = (fid_t*)&handlep->ha_fid; ! /* If mounting, and we are not asking for a filesystem handle, ! * then fail the request. (fid_len==0 for fshandle) ! */ ! if ((fsrp->fr_state == DM_STATE_MOUNTING) && ! (fidp->fid_len != 0)) { mutex_spinunlock(&fsrp->fr_lock, lc); return(NULL); } for (;;) { + if (fsrp->fr_state == DM_STATE_MOUNTING) + break; if (fsrp->fr_state == DM_STATE_MOUNTED) break; if (fsrp->fr_state == DM_STATE_UNMOUNTED) { *************** *** 496,502 **** vnode. */ - fidp = (fid_t*)&handlep->ha_fid; if (fidp->fid_len == 0) { /* filesystem handle */ VFS_ROOT(fsrp->fr_vfsp, &vp, error); } else { /* file object handle */ --- 503,508 ---- From owner-linux-xfs@oss.sgi.com Tue Jan 22 14:45:16 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0MMjGC00603 for linux-xfs-outgoing; Tue, 22 Jan 2002 14:45:16 -0800 Received: from qdusa.com ([204.94.79.2]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0MMj6P00572 for ; Tue, 22 Jan 2002 14:45:06 -0800 Received: (from root@localhost) by qdusa.com (8.8.7/8.8.7) id NAA18464; Tue, 22 Jan 2002 13:45:02 -0800 Message-Id: <200201222145.NAA18464@qdusa.com> From: Luis Montes To: Luis Montes , Eric Sandeen Date: Tue, 22 Jan 2002 13:36:32 -0800 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Subject: Re: XFS kernel crash and corrupted FS CC: References: <200201211818.KAA28743@qdusa.com> In-reply-to: X-mailer: Pegasus Mail for Windows (v2.54) Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 3740 Lines: 82 > Date: Mon, 21 Jan 2002 12:37:05 -0600 (CST) > From: Eric Sandeen > To: Luis Montes > Cc: > Subject: Re: XFS kernel crash and corrupted FS > On Mon, 21 Jan 2002, Luis Montes wrote: > > > The problem: > > I was just finished installing DRI, and was running glxgears to test > > it. Then when I tried to list a directory in one of the xfs > > partitions it reported input/output error. I rebooted and the root > > filesystem was corrupted beyond repair with the wnsuing kernel panic. > > How was this determined? Did you try xfs_repair on the filesystem? What > was the output? Can you send the output from xfs_repair, if it's > failing? Yes I did try to repair it with xfs_repair. Checking some filesystems it told me that there was valuable metadata and that I had to replay it by mounting it, but then I couldn't and running xfs_repair -L in some of them produced a HUGE amount of messages, that translated into most of my files being scrambled into the repaired lost+found directory. In one instance xfs just aborted with an assertion (I had it saved, but then I also lost the second HD. As a result I lost all the logs from xfs_repair, arrgh....) I was able to recover one filesystem and dump a tar.gz to a zipdrive, all the rest were lost :-( > > Also, are there any messages in your logs concerning a forced shutdown of > the filesystem? > No, there are no messages in the log file ( and there is no log file now anyway ;-) > > Three are > > damaged beyond repair (one actually seems to appear as an ext3! > > filesystem) > > This probably means that the xfs superblock is damaged, and mount is > finding an old ext3 signature from a previous mkfs. > > > But trying to mount one of the damaged fs's actually produces a > > couple of "unable to handle kernel paging request" errors and the > > system just freezes. It seems repeatable, three times I tried > > mounting that filesystem and thre three times I got thar fault. Is > > this something you guys might want to look more closely? It's been a > > long long while since I had any kernel problems, and I just read in > > the FAQ that I might first run ksymoops. > > Yes, the ksymoops output might shed more light on this. > > -Eric > > Sorry, it just seems that the whole system was getting worst and worst everytime I rebooted. Nothing ever appeard on syslog, and mounting the filesystem that caused a kernel panic the day before was now causing the machine to just reboot . One thing makes me feel better, and it is that I had done a good backup to CD just the day before. I'll just have to fix the hardware now, running a bios update, one of those HD repair utilities from WD, check and double check the DMA settings. Caviar drives have a rather spotty history and maybe the bios isn't setting conservative enough timings? What I don't understand is why I was able to get the system up an running for some days, compile XFree86, mozilla, galeon, browse the net, compile drivers... and then all of a sudden all hell broke loose, and no amount of reformatting/reinstalling has been able to produce a stable system ... I reinstalled from scratch repartitioning and mkfs.xfs -ing all the partitions fresh, and even though the installation itself went smooth, once I booted up the system went immediately belly up and now (today in the early ours ...) the machine wouldn't boot any partition on any disk! Lilo starts and loads the kernel, but then no root filesystem is usable ... Oh well, sorry for the ranting. Back to square one. Thanks Luis A. Montes Physicist/Programmer Quantum Design e-mail: luis.montes@qdusa.com From owner-linux-xfs@oss.sgi.com Tue Jan 22 14:54:12 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0MMsCT00885 for linux-xfs-outgoing; Tue, 22 Jan 2002 14:54:12 -0800 Received: from qdusa.com ([204.94.79.2]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0MMs9P00863 for ; Tue, 22 Jan 2002 14:54:09 -0800 Received: (from root@localhost) by qdusa.com (8.8.7/8.8.7) id NAA18606; Tue, 22 Jan 2002 13:54:05 -0800 Message-Id: <200201222154.NAA18606@qdusa.com> From: Luis Montes To: Steve Lord Date: Tue, 22 Jan 2002 13:51:24 -0800 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Subject: Re: XFS kernel crash and corrupted FS CC: linux-xfs@oss.sgi.com References: <200201211818.KAA28743@qdusa.com> In-reply-to: <1011712866.1281.6.camel@jen.americas.sgi.com> X-mailer: Pegasus Mail for Windows (v2.54) Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 791 Lines: 20 > Subject: Re: XFS kernel crash and corrupted FS > From: Steve Lord > To: Luis Montes > Cc: linux-xfs@oss.sgi.com > Date: 22 Jan 2002 09:21:06 -0600 > http://www.vnunet.com/News/1128504 > Thanks, that sure should have hit me. Funny thing is that there is something else too, because the system was working fine, then I tried glxgears, and crashed. Fine, memory corruption. But then something else got screwed (maybe because of my "corrective measures", something in the bios?) because now after several reinstalls it isn't stable as it used to be before. But thanks, I'll make sure I disable it. that's gotta help Luis A. Montes Physicist/Programmer Quantum Design e-mail: luis.montes@qdusa.com From owner-linux-xfs@oss.sgi.com Tue Jan 22 14:56:50 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0MMuoi01088 for linux-xfs-outgoing; Tue, 22 Jan 2002 14:56:50 -0800 Received: from Cantor.suse.de (ns.suse.de [213.95.15.193]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0MMukP01066 for ; Tue, 22 Jan 2002 14:56:46 -0800 Received: from Hermes.suse.de (Hermes.suse.de [213.95.15.136]) by Cantor.suse.de (Postfix) with ESMTP id 116891EC64; Tue, 22 Jan 2002 22:56:39 +0100 (MET) Date: Tue, 22 Jan 2002 22:56:38 +0100 From: Andi Kleen To: Steve Lord Cc: Austin Gonyou , Nathan Straz , Linux XFS List Subject: Re: XFS Inode Size question. Message-ID: <20020122225638.A21260@wotan.suse.de> References: <1011732836.1281.118.camel@jen.americas.sgi.com> <1011733491.2172.18.camel@UberGeek> <1011733555.1279.120.camel@jen.americas.sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1011733555.1279.120.camel@jen.americas.sgi.com> User-Agent: Mutt/1.3.22.1i Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 832 Lines: 18 On Tue, Jan 22, 2002 at 03:05:55PM -0600, Steve Lord wrote: > On Tue, 2002-01-22 at 15:04, Austin Gonyou wrote: > > Scratch that...it just dropped back down about an hour ago. I wonder why > > that would be? I mounted a loopback device around that time. Could that > > have anything to do with it? > > About the only thing which would shrink it is a memory shortage, one > of the things this can cause is a shrink of the inode cache. It's a known problem in 2.4 that it keeps too many dentries/inodes in memory around. It shouldn't keep more inodes than dentries for example, but it does after some stress. It's one of the things that didn't get fixed in t he VM rewrite. Fortunately it doesn't have too many bad effects except for some wasted memory and longer lookup times for inodes due to overlong hash chains. -Andi From owner-linux-xfs@oss.sgi.com Tue Jan 22 15:26:32 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0MNQWZ01723 for linux-xfs-outgoing; Tue, 22 Jan 2002 15:26:32 -0800 Received: from UberGeek.coremetrics.com ([209.184.141.163]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0MNQNP01699 for ; Tue, 22 Jan 2002 15:26:23 -0800 Received: (from austin@localhost) by UberGeek.coremetrics.com (8.11.6/8.11.6) id g0MMPVA03782; Tue, 22 Jan 2002 16:25:31 -0600 X-Authentication-Warning: UberGeek.coremetrics.com: austin set sender to austin@coremetrics.com using -f Subject: Re: XFS Inode Size question. From: Austin Gonyou To: Andi Kleen Cc: Steve Lord , Nathan Straz , Linux XFS List In-Reply-To: <20020122225638.A21260@wotan.suse.de> References: <20020122225638.A21260@wotan.suse.de> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-vn4dkQPhhqCy8NaP/9H8" X-Mailer: Evolution/1.0.1 Date: 22 Jan 2002 16:25:31 -0600 Message-Id: <1011738331.31585.2.camel@UberGeek> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 1793 Lines: 57 --=-vn4dkQPhhqCy8NaP/9H8 Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Andi, Thanks for this note. This will help greatly. Is there anything that I can do to resolve this issue? A patch or something in /proc perhaps?=20 On Tue, 2002-01-22 at 15:56, Andi Kleen wrote: > On Tue, Jan 22, 2002 at 03:05:55PM -0600, Steve Lord wrote: > > On Tue, 2002-01-22 at 15:04, Austin Gonyou wrote: > > > Scratch that...it just dropped back down about an hour ago. I wonder > why > > > that would be? I mounted a loopback device around that time. Could > that > > > have anything to do with it? > >=20 > > About the only thing which would shrink it is a memory shortage, one > > of the things this can cause is a shrink of the inode cache. >=20 > It's a known problem in 2.4 that it keeps too many dentries/inodes in > memory=20 > around. It shouldn't keep more inodes than dentries for example, but=20 > it does after some stress. It's one of the things that didn't get fixed > in t > he VM rewrite. Fortunately it doesn't have too many bad effects except > for > some wasted memory and longer lookup times for inodes due to overlong > hash=20 > chains.=20 >=20 > -Andi --=20 Austin Gonyou Systems Architect, CCNA Coremetrics, Inc. Phone: 512-698-7250 email: austin@coremetrics.com "It is the part of a good shepherd to shear his flock, not to skin it." Latin Proverb --=-vn4dkQPhhqCy8NaP/9H8 Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQA8Tebb94g6ZVmFMoIRAl8rAJ0XJQNFODqfumhm1o20HSXN4v8/KQCfQX4E sY6HrkLknLNnH5w4/dpQZNo= =aPlH -----END PGP SIGNATURE----- --=-vn4dkQPhhqCy8NaP/9H8-- From owner-linux-xfs@oss.sgi.com Tue Jan 22 15:32:02 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0MNW2301887 for linux-xfs-outgoing; Tue, 22 Jan 2002 15:32:02 -0800 Received: from Cantor.suse.de (ns.suse.de [213.95.15.193]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0MNVxP01864 for ; Tue, 22 Jan 2002 15:31:59 -0800 Received: from Hermes.suse.de (Hermes.suse.de [213.95.15.136]) by Cantor.suse.de (Postfix) with ESMTP id 3309E1EC6C; Tue, 22 Jan 2002 23:31:52 +0100 (MET) Date: Tue, 22 Jan 2002 23:31:52 +0100 From: Andi Kleen To: Austin Gonyou Cc: Andi Kleen , Steve Lord , Nathan Straz , Linux XFS List Subject: Re: XFS Inode Size question. Message-ID: <20020122233152.B2756@wotan.suse.de> References: <20020122225638.A21260@wotan.suse.de> <1011738331.31585.2.camel@UberGeek> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1011738331.31585.2.camel@UberGeek> User-Agent: Mutt/1.3.22.1i Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 265 Lines: 9 On Tue, Jan 22, 2002 at 04:25:31PM -0600, Austin Gonyou wrote: > Andi, > Thanks for this note. This will help greatly. Is there anything that I > can do to resolve this issue? A patch or something in /proc perhaps? Not really. Just ignore it for now. -Andi From owner-linux-xfs@oss.sgi.com Tue Jan 22 15:52:40 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0MNqe902279 for linux-xfs-outgoing; Tue, 22 Jan 2002 15:52:40 -0800 Received: from UberGeek.coremetrics.com ([209.184.141.163]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0MNqVP02253 for ; Tue, 22 Jan 2002 15:52:31 -0800 Received: (from austin@localhost) by UberGeek.coremetrics.com (8.11.6/8.11.6) id g0MMpkw03859; Tue, 22 Jan 2002 16:51:46 -0600 X-Authentication-Warning: UberGeek.coremetrics.com: austin set sender to austin@coremetrics.com using -f Subject: Re: XFS Inode Size question. From: Austin Gonyou To: Andi Kleen Cc: Steve Lord , Nathan Straz , Linux XFS List In-Reply-To: <20020122233152.B2756@wotan.suse.de> References: <20020122233152.B2756@wotan.suse.de> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-3amSgvH3YRfTIUpK6Ulr" X-Mailer: Evolution/1.0.1 Date: 22 Jan 2002 16:51:46 -0600 Message-Id: <1011739906.31579.13.camel@UberGeek> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 1418 Lines: 46 --=-3amSgvH3YRfTIUpK6Ulr Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Ok. As a close to this, I'd like to inquire if this will adversely affect a 300GB database running on this machine?=20 Once the File's have been created, the Inodes are taken already, so I don't see that as being a problem, but if memory consumption is an issue, I wanted to ask so I know if it will become unstable after 30 days, 90 days, etc of constant use and data influx. On Tue, 2002-01-22 at 16:31, Andi Kleen wrote: > On Tue, Jan 22, 2002 at 04:25:31PM -0600, Austin Gonyou wrote: > > Andi, > > Thanks for this note. This will help greatly. Is there anything that > I > > can do to resolve this issue? A patch or something in /proc perhaps?=20 >=20 > Not really. Just ignore it for now.=20 >=20 > -Andi --=20 Austin Gonyou Systems Architect, CCNA Coremetrics, Inc. Phone: 512-698-7250 email: austin@coremetrics.com "It is the part of a good shepherd to shear his flock, not to skin it." Latin Proverb --=-3amSgvH3YRfTIUpK6Ulr Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQA8Te0C94g6ZVmFMoIRAlBdAJ97St4irA/saG8jNsuk7uRf2Q1MvQCgyJ0V 6fmpZjKJDcooNyq3rA4mBAo= =0wcs -----END PGP SIGNATURE----- --=-3amSgvH3YRfTIUpK6Ulr-- From owner-linux-xfs@oss.sgi.com Tue Jan 22 16:06:58 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0N06wT02579 for linux-xfs-outgoing; Tue, 22 Jan 2002 16:06:58 -0800 Received: from Cantor.suse.de (ns.suse.de [213.95.15.193]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0N06tP02557 for ; Tue, 22 Jan 2002 16:06:56 -0800 Received: from Hermes.suse.de (Hermes.suse.de [213.95.15.136]) by Cantor.suse.de (Postfix) with ESMTP id 5BA821EC80; Wed, 23 Jan 2002 00:06:48 +0100 (MET) Date: Wed, 23 Jan 2002 00:06:48 +0100 From: Andi Kleen To: Austin Gonyou Cc: Andi Kleen , Steve Lord , Nathan Straz , Linux XFS List Subject: Re: XFS Inode Size question. Message-ID: <20020123000648.A16467@wotan.suse.de> References: <20020122233152.B2756@wotan.suse.de> <1011739906.31579.13.camel@UberGeek> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1011739906.31579.13.camel@UberGeek> User-Agent: Mutt/1.3.22.1i Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 512 Lines: 12 On Tue, Jan 22, 2002 at 04:51:46PM -0600, Austin Gonyou wrote: > Ok. As a close to this, I'd like to inquire if this will adversely > affect a 300GB database running on this machine? > Once the File's have been created, the Inodes are taken already, so I > don't see that as being a problem, but if memory consumption is an > issue, I wanted to ask so I know if it will become unstable after 30 > days, 90 days, etc of constant use and data influx. I don't think it'll be a problem for database load. -Andi From owner-linux-xfs@oss.sgi.com Tue Jan 22 16:46:07 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0N0k7k03050 for linux-xfs-outgoing; Tue, 22 Jan 2002 16:46:07 -0800 Received: from UberGeek.coremetrics.com ([209.184.141.163]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0N0k0P03025 for ; Tue, 22 Jan 2002 16:46:00 -0800 Received: (from austin@localhost) by UberGeek.coremetrics.com (8.11.6/8.11.6) id g0MNjHS04439; Tue, 22 Jan 2002 17:45:17 -0600 X-Authentication-Warning: UberGeek.coremetrics.com: austin set sender to austin@coremetrics.com using -f Subject: Re: XFS Inode Size question. From: Austin Gonyou To: Andi Kleen Cc: Steve Lord , Nathan Straz , Linux XFS List In-Reply-To: <20020123000648.A16467@wotan.suse.de> References: <20020123000648.A16467@wotan.suse.de> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-brEvQuq9OvrHS2xS29Kr" X-Mailer: Evolution/1.0.1 Date: 22 Jan 2002 17:45:17 -0600 Message-Id: <1011743117.4396.0.camel@UberGeek> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 1367 Lines: 44 --=-brEvQuq9OvrHS2xS29Kr Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Thanks much. We now return you to your regularly scheduled mailing list... On Tue, 2002-01-22 at 17:06, Andi Kleen wrote: > On Tue, Jan 22, 2002 at 04:51:46PM -0600, Austin Gonyou wrote: > > Ok. As a close to this, I'd like to inquire if this will adversely > > affect a 300GB database running on this machine?=20 > > Once the File's have been created, the Inodes are taken already, so I > > don't see that as being a problem, but if memory consumption is an > > issue, I wanted to ask so I know if it will become unstable after 30 > > days, 90 days, etc of constant use and data influx. >=20 > I don't think it'll be a problem for database load.=20 >=20 > -Andi --=20 Austin Gonyou Systems Architect, CCNA Coremetrics, Inc. Phone: 512-698-7250 email: austin@coremetrics.com "It is the part of a good shepherd to shear his flock, not to skin it." Latin Proverb --=-brEvQuq9OvrHS2xS29Kr Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQA8TfmN94g6ZVmFMoIRAuvQAJ9bKCFWwWrCRD6GbL44zm4lvi59zACg7RPm /Q7c2QnL8sp5630t5AoAKfw= =tVy6 -----END PGP SIGNATURE----- --=-brEvQuq9OvrHS2xS29Kr-- From owner-linux-xfs@oss.sgi.com Tue Jan 22 18:09:30 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0N29UE08631 for linux-xfs-outgoing; Tue, 22 Jan 2002 18:09:30 -0800 Received: from trillium-hollow.org (trillium-hollow.org [209.180.166.89]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0N29NP08608 for ; Tue, 22 Jan 2002 18:09:24 -0800 Received: from erich (helo=trillium) by trillium-hollow.org with local-esmtp (Exim 3.33 #1) id 16TBuj-00052F-00 for linux-xfs@oss.sgi.com; Tue, 22 Jan 2002 17:09:21 -0800 To: linux-xfs@oss.sgi.com Subject: Re: Shrinking an XFS filesystem is a crucial feature! In-Reply-To: Your message of "Tue, 22 Jan 2002 14:31:20 EST." <20020122143120.G19778@justice.loyola.edu> Date: Tue, 22 Jan 2002 17:09:21 -0800 From: erich@uruk.org Message-Id: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 1492 Lines: 34 Michael Stone wrote: > On Sat, Jan 19, 2002 at 03:41:17PM -0600, Austin Gonyou wrote: > > That said, I was merely trying to offer what I believe the target > > audience will want. It seems that the target audience would be those > > using Veritas and the like. Sorry for rubbing you the wrong way, I don't > > As a counterpoint, I'd consider at least part of the target audience to > be people who need really big, really fast filesystems. In that audience > there's not a lot of demand for shrinking: people want as much space as > possible, usually in really big chunks. The space is allocated carefully > so partitions are aligned across very large disk arrays in order to > maximize performance. If you shrink your volume you're going to lose > that alignment. I would have to agree with Austin in the general sense that, to be a viable long-term solution, filesystems (especially clustered ones like XFS claims to have a mode for in it's commercial form... I've never seen it so can't comment) will have to run on systems that are/have: -- meant to be easily reconfigured with only a short reboot or -- hot-swap hardware allowing addition and removal of parts over time If your system requirements go down over time, then rebuilding everything from scratch/backup/restore is a major pain. -- Erich Stefan Boleyn http://www.uruk.org/ "Reality is truly stranger than fiction; Probably why fiction is so popular" From owner-linux-xfs@oss.sgi.com Tue Jan 22 18:33:54 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0N2Xsr09289 for linux-xfs-outgoing; Tue, 22 Jan 2002 18:33:54 -0800 Received: from deliverator.sgi.com (deliverator.sgi.com [204.94.214.10]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0N2XlP09267 for ; Tue, 22 Jan 2002 18:33:47 -0800 Received: from sherman.melbourne.sgi.com (sherman.melbourne.sgi.com [134.14.55.232]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id RAA26131 for ; Tue, 22 Jan 2002 17:29:21 -0800 (PST) mail_from (kaos@sherman.melbourne.sgi.com) Received: (from kaos@localhost) by sherman.melbourne.sgi.com (8.11.6/8.11.6) id g0N1XTt02650; Wed, 23 Jan 2002 12:33:29 +1100 Date: Wed, 23 Jan 2002 12:33:29 +1100 From: Keith Owens Message-Id: <200201230133.g0N1XTt02650@sherman.melbourne.sgi.com> Subject: TAKE - Upgrade XFS to kdb v2.1 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 1497 Lines: 46 Upgrade XFS to kdb-v2.1-2.4.17-common-2 + kdb-v2.1-2.4.17-i386-1. Date: Tue Jan 22 17:29:15 PST 2002 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:110037a linux/mm/vmalloc.c - 1.34 linux/arch/ppc/vmlinux.lds - 1.11 linux/arch/m68k/vmlinux.lds - 1.10 linux/arch/i386/kernel/traps.c - 1.43 linux/Makefile - 1.163 linux/arch/arm/vmlinux-armv.lds.in - 1.17 linux/arch/arm/vmlinux-armo.lds.in - 1.15 linux/arch/m68k/vmlinux-sun3.lds - 1.7 linux/fs/xfs/xfsidbg.c - 1.169 linux/Documentation/kdb/kdb_rd.man - 1.6 linux/kdb/kdb_bt.c - 1.9 linux/kdb/kdb_bp.c - 1.9 linux/kdb/modules/kdbm_vm.c - 1.16 linux/include/linux/kdbprivate.h - 1.17 linux/include/linux/kdb.h - 1.20 linux/kdb/kdbsupport.c - 1.11 linux/kdb/kdbmain.c - 1.25 linux/include/linux/dis-asm.h - 1.11 linux/include/asm-i386/kdb.h - 1.10 linux/kdb/kdb_io.c - 1.12 linux/Documentation/kdb/kdb_ss.man - 1.5 linux/arch/i386/kdb/kdba_id.c - 1.10 linux/Documentation/kdb/kdb.mm - 1.13 linux/Documentation/kdb/kdb_bp.man - 1.6 linux/Documentation/kdb/kdb_bt.man - 1.7 linux/kdb/kdb_id.c - 1.12 linux/arch/i386/kdb/kdbasupport.c - 1.18 linux/arch/i386/kdb/kdba_io.c - 1.14 linux/arch/i386/kdb/kdba_bt.c - 1.12 linux/arch/i386/kdb/kdba_bp.c - 1.11 linux/kdb/modules/kdbm_pg.c - 1.48 linux/arch/alpha/vmlinux.lds.in - 1.6 linux/kdb/ChangeLog - 1.15 linux/arch/i386/kdb/ansidecl.h - 1.2 linux/arch/i386/kdb/ChangeLog - 1.2 From owner-linux-xfs@oss.sgi.com Tue Jan 22 20:17:23 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0N4HN210771 for linux-xfs-outgoing; Tue, 22 Jan 2002 20:17:23 -0800 Received: from pneumatic-tube.sgi.com (pneumatic-tube.sgi.com [204.94.214.22]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0N4HKP10749 for ; Tue, 22 Jan 2002 20:17:20 -0800 Received: from sherman.melbourne.sgi.com (sherman.melbourne.sgi.com [134.14.55.232]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id TAA06994 for ; Tue, 22 Jan 2002 19:18:10 -0800 (PST) mail_from (kaos@sherman.melbourne.sgi.com) Received: (from kaos@localhost) by sherman.melbourne.sgi.com (8.11.6/8.11.6) id g0N3HEW13569; Wed, 23 Jan 2002 14:17:14 +1100 Date: Wed, 23 Jan 2002 14:17:14 +1100 From: Keith Owens Message-Id: <200201230317.g0N3HEW13569@sherman.melbourne.sgi.com> Subject: TAKE - kbuild 2.5 changes for pagebuf reorganization Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 485 Lines: 17 The recent pagebuf reorganization needed to be reflected in the kbuild 2.5 files for XFS. Date: Tue Jan 22 19:13:56 PST 2002 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:110043a linux/include/linux/module.h - 1.31 linux/fs/Makefile.in.append - 1.6 linux/fs/xfs/Makefile.in - 1.11 linux/fs/xfs_dmapi/Makefile.in - 1.3 linux/fs/xfs/pagebuf/Makefile.in - 1.3 From owner-linux-xfs@oss.sgi.com Tue Jan 22 21:42:23 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0N5gNM11626 for linux-xfs-outgoing; Tue, 22 Jan 2002 21:42:23 -0800 Received: from yog-sothoth.sgi.com (eugate.sgi.com [192.48.160.10]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0N5gKP11604 for ; Tue, 22 Jan 2002 21:42:20 -0800 Received: from nodin.corp.sgi.com (fddi-nodin.corp.sgi.com [198.29.75.193]) by yog-sothoth.sgi.com (980305.SGI.8.8.8-aspam-6.2/980304.SGI-aspam-europe) via ESMTP id FAA530631 for ; Wed, 23 Jan 2002 05:41:42 +0100 (CET) mail_from (kaos@sgi.com) Received: from kao2.melbourne.sgi.com (kao2.melbourne.sgi.com [134.14.55.180]) by nodin.corp.sgi.com (8.11.4/8.11.2/nodin-1.0) with ESMTP id g0N4fE425711285 for ; Tue, 22 Jan 2002 20:41:14 -0800 (PST) Received: by kao2.melbourne.sgi.com (Postfix, from userid 16331) id B21583000B8; Wed, 23 Jan 2002 15:41:12 +1100 (EST) Received: from kao2.melbourne.sgi.com (localhost [127.0.0.1]) by kao2.melbourne.sgi.com (Postfix) with ESMTP id 71A94BB for ; Wed, 23 Jan 2002 15:41:12 +1100 (EST) X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 From: Keith Owens To: linux-xfs@oss.sgi.com Subject: Updated XFS split patches for 2.4.17 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 23 Jan 2002 15:41:07 +1100 Message-ID: <24011.1011760867@kao2.melbourne.sgi.com> Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 214 Lines: 5 ftp://oss.sgi.com/projects/xfs/download/patches/2.4.17 has been regenerated to pick up some important XFS bug fixes and upgrade to kdb v2.1. The split patches are in sync with XFS CVS as of 2002-01-23 04:32 UTC. From owner-linux-xfs@oss.sgi.com Wed Jan 23 01:46:06 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0N9k6727686 for linux-xfs-outgoing; Wed, 23 Jan 2002 01:46:06 -0800 Received: from goliath.sylaba.poznan.pl (root@goliath.sylaba.poznan.pl [195.216.104.3]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0N9k0P27637 for ; Wed, 23 Jan 2002 01:46:02 -0800 Received: from venus.local.navi.pl (ps103.poznan.sdi.tpnet.pl [217.97.72.103]) by goliath.sylaba.poznan.pl (8.11.6/8.10.1) with ESMTP id g0N8jt924621; Wed, 23 Jan 2002 09:45:55 +0100 (CET) Received: from venus.local.navi.pl (venus.local.navi.pl [192.168.1.10]) by venus.local.navi.pl (8.11.6/8.9.3) with ESMTP id g0N8a8V02503; Wed, 23 Jan 2002 09:36:08 +0100 Date: Wed, 23 Jan 2002 09:36:08 +0100 From: Olaf =?iso-8859-2?Q?Fr=B1czyk?= To: Steve Lord Cc: Austin Gonyou , linux-xfs@oss.sgi.com Subject: Re: problem with VMware -XFS guilty one - was: Re: XFS is innocen t Message-ID: <20020123093608.A2386@venus.local.navi.pl> References: <20020117194821.A3800@venus.local.navi.pl> <1011293832.26356.13.camel@UberGeek> <20020122185130.A1579@venus.local.navi.pl> <1011724405.1281.46.camel@jen.americas.sgi.com> Mime-Version: 1.0 Content-Type: text/plain; format=flowed; charset=ISO-8859-2 In-Reply-To: <1011724405.1281.46.camel@jen.americas.sgi.com>; from lord@sgi.com on Tue, Jan 22, 2002 at 19:33:25 +0100 X-Mailer: Balsa 1.2.4 X-MIME-Autoconverted: from 8bit to quoted-printable by goliath.sylaba.poznan.pl id g0N8jt924621 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id g0N9k3P27653 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 314 Lines: 12 On 2002.01.22 19:33:25 +0100 Steve Lord wrote: > On Tue, 2002-01-22 at 11:51, Olaf Fr±czyk wrote: > > So, what do you suggest to try next? > > Have you tried a current cvs kernel from oss.sgi.com? > I use kernel from 16 Jan from cvs. OK. I will do update, and let you know if something changes. Regards, Olaf From owner-linux-xfs@oss.sgi.com Wed Jan 23 03:16:01 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0NBG1G17756 for linux-xfs-outgoing; Wed, 23 Jan 2002 03:16:01 -0800 Received: from sgi.com (sgi-too.SGI.COM [204.94.211.39]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0NBFtP17719 for ; Wed, 23 Jan 2002 03:15:55 -0800 Received: from zeus-e8.americas.sgi.com (zeus-e8.americas.sgi.com [128.162.8.103]) by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id CAA01615 for ; Wed, 23 Jan 2002 02:14:43 -0800 (PST) mail_from (lord@sgi.com) Received: from tulip-e185.americas.sgi.com (tulip-e185.americas.sgi.com [128.162.185.208]) by zeus-e8.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id EAA111888; Wed, 23 Jan 2002 04:14:37 -0600 (CST) Received: from sgi.com (4ERI6tWAElSpq4b1+mpN+pGIEuzOdhth@lord-h1.americas.sgi.com [206.11.101.42]) by tulip-e185.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.7) with ESMTP id EAA92684; Wed, 23 Jan 2002 04:14:36 -0600 (CST) Message-ID: <3C4E8D15.6070504@sgi.com> Date: Wed, 23 Jan 2002 04:14:45 -0600 From: Stephen Lord User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.7) Gecko/20011226 X-Accept-Language: en-us MIME-Version: 1.0 To: Olaf =?ISO-8859-2?Q?Fr=B1czyk?= CC: Austin Gonyou , linux-xfs@oss.sgi.com Subject: Re: problem with VMware -XFS guilty one - was: Re: XFS is innocen t References: <20020117194821.A3800@venus.local.navi.pl> <1011293832.26356.13.camel@UberGeek> <20020122185130.A1579@venus.local.navi.pl> <1011724405.1281.46.camel@jen.americas.sgi.com> <20020123093608.A2386@venus.local.navi.pl> Content-Type: text/plain; charset=ISO-8859-2; format=flowed Content-Transfer-Encoding: 8bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 480 Lines: 24 Olaf Fr1czyk wrote: > On 2002.01.22 19:33:25 +0100 Steve Lord wrote: > >> On Tue, 2002-01-22 at 11:51, Olaf Fr1czyk wrote: >> > So, what do you suggest to try next? >> >> Have you tried a current cvs kernel from oss.sgi.com? >> > I use kernel from 16 Jan from cvs. > OK. I will do update, and let you know if something changes. > > Regards, > > Olaf Ouch! Any chance you could update that past 17th Jan? There was a major bug fix the day after you picked up the code. Steve From owner-linux-xfs@oss.sgi.com Wed Jan 23 07:15:08 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0NFF8d21672 for linux-xfs-outgoing; Wed, 23 Jan 2002 07:15:08 -0800 Received: from cheetah.mail.utk.edu (IDENT:root@cheetah.mail.utk.edu [160.36.178.61]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0NFF2P21623 for ; Wed, 23 Jan 2002 07:15:02 -0800 Received: from there (daryl.ag.utk.edu [160.36.6.89]) by cheetah.mail.utk.edu (8.12.1/8.12.1) with SMTP id g0NEEvxs006567 for ; Wed, 23 Jan 2002 09:14:58 -0500 Message-Id: <200201231414.g0NEEvxs006567@cheetah.mail.utk.edu> Content-Type: text/plain; charset="iso-8859-15" From: Jochen Weiss Reply-To: jweiss1@utk.edu Organization: University of Tennessee To: linux-xfs@oss.sgi.com Subject: Onstream Tape Driver Kernel Bug???? Date: Wed, 23 Jan 2002 09:07:54 -0500 X-Mailer: KMail [version 1.3.2] MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Virus-Scanned: by amavisd-milter (http://amavis.org/) Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 494 Lines: 17 Hello: I am getting a complete crash of my server system after my just recent upgrade to the 1.0.2 release using the 2.4.9-13 kernel as soon as I try to access the Onstream Tape (using the osst driver). Is that problem known and do you recommend a kernel upgrade? Thanks Jochen Weiss -- ------------------------------------------------------------ Jochen Weiss, Assistant Prof. Dept. of Food Science and Technology, UT Knoxville, TN 37996, USA Phone: (865) 974 2753 Fax: (865) 974 2750 From owner-linux-xfs@oss.sgi.com Wed Jan 23 07:55:06 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0NFt6M01202 for linux-xfs-outgoing; Wed, 23 Jan 2002 07:55:06 -0800 Received: from gk.hm.epigenomics.net (qmailr@gk.hm.epigenomics.net [212.121.137.90]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0NFsvP01117 for ; Wed, 23 Jan 2002 07:54:57 -0800 Received: (qmail 30342 invoked from network); 23 Jan 2002 14:54:54 -0000 Received: from raman.epigenomics.epi (qmailr@192.168.2.2) by salam.epigenomics.epi with SMTP; 23 Jan 2002 14:54:54 -0000 Received: (qmail 30678 invoked from network); 23 Jan 2002 14:54:51 -0000 Received: from broglie.epigenomics.epi (qmailr@192.168.1.5) by raman.epigenomics.epi with SMTP; 23 Jan 2002 14:54:51 -0000 Received: (qmail 31536 invoked by uid 9); 23 Jan 2002 14:54:50 -0000 From: Robert Sander Reply-To: Robert Sander X-Newsgroups: epi.ml.linux.xfs Subject: Re: kernel oops with linux 2.4.17-xfs Date: Wed, 23 Jan 2002 14:54:50 +0000 (UTC) Organization: Epigenomics AG Message-ID: References: <000601c1a018$62cf0c00$0264a8c0@skeletor> X-Complaints-To: usenet@epigenomics.com User-Agent: slrn/0.9.7.3 (Linux) To: linux-xfs@oss.sgi.com Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 3232 Lines: 64 On Fri, 18 Jan 2002 12:05:47 +0000 (UTC), "Johannes Schritz" wrote: > > No, I used the CVS source. And I got the same oops right now: kernel BUG at /mnt/raid/1/src/linux-2.4.17-xfs-new/include/asm/spinlock.h:86! invalid operand: 0000 CPU: 0 EIP: 0010:[] Tainted: P EFLAGS: 00010002 eax: 0000004e ebx: 00000086 ecx: c02d81c4 edx: 00002fce esi: 00000001 edi: f7c69414 ebp: f7db9ec0 esp: f7db9e8c ds: 0018 es: 0018 ss: 0018 Process kupdated (pid: 7, stackpage=f7db9000) Stack: f89134a0 00000056 f1923e24 f16eecfc f78f5a4c 00000000 00000082 f7db9ec0 00000000 00000000 00000002 f7c69400 f1923e24 f7db9ef8 f88dff01 f16eecfc f7292e10 f7c69520 f1228d7c f766a58c 00000282 00000003 f78f5a48 00000000 Call Trace: [] [] [] [] [] [] [] [] [] [] Code: 0f 0b 83 c4 08 90 8d 74 26 00 8b 55 f8 c6 42 14 01 53 9d 8b Entering kdb (current=0xf7db8000, pid 7) on processor 0 Oops: invalid operand due to oops @ 0xf88e04d6 eax = 0x0000004e ebx = 0x00000086 ecx = 0xc02d81c4 edx = 0x00002fce esi = 0x00000001 edi = 0xf7c69414 esp = 0xf7db9e8c eip = 0xf88e04d6 ebp = 0xf7db9ec0 xss = 0x00000018 xcs = 0x00000010 eflags = 0x00010002 xds = 0x00000018 xes = 0x00000018 origeax = 0xffffffff ®s = 0xf7db9e58 Using kdb I got this backtrace: [0]kdb> bt EBP EIP Function(args) 0xf7db9ec0 0xf88e04d6 [xfs]xfs_iflush_int+0x32a (0xf16eecfc, 0xf7292e10, 0xf7c69520, 0xf1228d7c, 0xf766a58c) xfs .text 0xf889e060 0xf88e01ac 0xf88e0520 0xf7db9ef8 0xf88dff01 [xfs]xfs_iflush+0x229 (0xf1228d7c, 0x1, 0xf7c69520, 0xf7c69800, 0xf7c69848) xfs .text 0xf889e060 0xf88dfcd8 0xf88e01ac 0xf7db9f78 0xf88f5e4c [xfs]xfs_syncsub+0x7ac (0xf7c69400, 0x31, 0x0, 0x0) xfs .text 0xf889e060 0xf88f56a0 0xf88f627c 0xf7db9f90 0xf88f569a [xfs]xfs_sync+0x16 (0xf7c69400, 0x31, 0xf89261e0) xfs .text 0xf889e060 0xf88f5684 0xf88f56a0 0xf7db9fa4 0xf890cc11 [xfs]linvfs_write_super+0x2d (0xf7c69800, 0xf7db8000, 0xf7db8000) xfs .text 0xf889e060 0xf890cbe4 0xf890cc18 0xf7db9fb8 0xc014904f sync_supers+0x14f (0x0, 0xf7db8000, 0xc022d517) kernel .text 0xc0100000 0xc0148f00 0xc01490c8 0xf7db9fcc 0xc014823b sync_old_buffers+0x67 (0x10f00, 0xc2113f98, 0xc2112000, 0xf7db87f4, 0xf7db87e4) kernel .text 0xc0100000 0xc01481d4 0xc014836c 0xf7db9fec 0xc0148845 kupdate+0x25d kernel .text 0xc0100000 0xc01485e8 0xc014884c 0xc0105787 kernel_thread+0x23 kernel .text 0xc0100000 0xc0105764 0xc010579c I was running dbench on an NFSv3 (read kernel nfsd) exported filesystem and am able to reproduce the problem. It bugs out in spinlock.h, spinlock debugging is enabled. Greetings -- Robert Sander Computer Scientist Epigenomics AG Bioinformatics R&D www.epigenomics.com Kastanienallee 24 +493024345330 10435 Berlin From owner-linux-xfs@oss.sgi.com Wed Jan 23 08:11:48 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0NGBm705246 for linux-xfs-outgoing; Wed, 23 Jan 2002 08:11:48 -0800 Received: from sgi.com (sgi-too.SGI.COM [204.94.211.39]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0NGBjP05211 for ; Wed, 23 Jan 2002 08:11:45 -0800 Received: from zeus-e8.americas.sgi.com (zeus-e8.americas.sgi.com [128.162.8.103]) by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id HAA02442 for ; Wed, 23 Jan 2002 07:11:42 -0800 (PST) mail_from (lord@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by zeus-e8.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id JAA114700; Wed, 23 Jan 2002 09:10:25 -0600 (CST) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id JAA98035; Wed, 23 Jan 2002 09:10:25 -0600 (CST) Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id g0NF9TA18766; Wed, 23 Jan 2002 09:09:29 -0600 Subject: Re: kernel oops with linux 2.4.17-xfs From: Steve Lord To: Robert Sander Cc: linux-xfs@oss.sgi.com In-Reply-To: References: <000601c1a018$62cf0c00$0264a8c0@skeletor> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/1.0.1 Date: 23 Jan 2002 09:09:29 -0600 Message-Id: <1011798569.1279.1202.camel@jen.americas.sgi.com> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 352 Lines: 11 Please turn off spinlock debugging, it does not work in the xfs code, we compile with -f unsignedchar and this breaks the check in the spinlock debug where it does a signed comparison on a spinlock. Steve -- Steve Lord voice: +1-651-683-3511 Principal Engineer, Filesystem Software email: lord@sgi.com From owner-linux-xfs@oss.sgi.com Wed Jan 23 08:13:13 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0NGDDI05733 for linux-xfs-outgoing; Wed, 23 Jan 2002 08:13:13 -0800 Received: from gk.hm.epigenomics.net (qmailr@gk.hm.epigenomics.net [212.121.137.90]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0NGD3P05672 for ; Wed, 23 Jan 2002 08:13:03 -0800 Received: (qmail 30527 invoked from network); 23 Jan 2002 15:13:02 -0000 Received: from raman.epigenomics.epi (qmailr@192.168.2.2) by salam.epigenomics.epi with SMTP; 23 Jan 2002 15:13:02 -0000 Received: (qmail 13821 invoked from network); 23 Jan 2002 15:12:59 -0000 Received: from broglie.epigenomics.epi (qmailr@192.168.1.5) by raman.epigenomics.epi with SMTP; 23 Jan 2002 15:12:59 -0000 Received: (qmail 32698 invoked by uid 9); 23 Jan 2002 15:12:58 -0000 From: Robert Sander Reply-To: Robert Sander X-Newsgroups: epi.ml.linux.xfs Subject: Re: kernel oops with linux 2.4.17-xfs Date: Wed, 23 Jan 2002 15:12:58 +0000 (UTC) Organization: Epigenomics AG Message-ID: References: <000601c1a018$62cf0c00$0264a8c0@skeletor> X-Complaints-To: usenet@epigenomics.com User-Agent: slrn/0.9.7.3 (Linux) To: linux-xfs@oss.sgi.com Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 4483 Lines: 73 On Wed, 23 Jan 2002 14:55:46 +0000 (UTC), Robert Sander wrote: > I was running dbench on an NFSv3 (read kernel nfsd) exported filesystem > and am able to reproduce the problem. It bugs out in spinlock.h, > spinlock debugging is enabled. When using the userspace nfsd I get this oops: kernel BUG at /mnt/raid/1/src/linux-2.4.17-xfs-new/include/asm/spinlock.h:86! invalid operand: 0000 CPU: 0 EIP: 0010:[] Tainted: P EFLAGS: 00010002 eax: 0000004e ebx: 00000000 ecx: c02d81c4 edx: 00003042 esi: f0ae0450 edi: f7d4bcc4 ebp: f7db9bc8 esp: f7db9bac ds: 0018 es: 0018 ss: 0018 Process kupdated (pid: 7, stackpage=f7db9000) Stack: f89144c0 00000056 f7d4bcc4 f0ae0450 f7d4bd70 f7d4bd70 00000202 f7db9bf0 f88e69b8 f7994400 00000001 00000000 f0ae0450 f7d4bcc4 00000001 00000202 00000202 f7db9c14 f88e39a9 f7d4bcc4 f0ae0450 f7994400 00000001 f7db9df8 Call Trace: [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] Code: 0f 0b 8d 74 26 00 c6 87 ac 00 00 00 01 ff 75 fc 9d 8d 65 ec Entering kdb (current=0xf7db8000, pid 7) on processor 0 Oops: invalid operand due to oops @ 0xf88e422a eax = 0x0000004e ebx = 0x00000000 ecx = 0xc02d81c4 edx = 0x00003042 esi = 0xf0ae0450 edi = 0xf7d4bcc4 esp = 0xf7db9bac eip = 0xf88e422a ebp = 0xf7db9bc8 xss = 0x00000018 xcs = 0x00000010 eflags = 0x00010002 xds = 0x00000018 xes = 0x00000018 origeax = 0xffffffff ®s = 0xf7db9b78 [0]kdb> bt EBP EIP Function(args) 0xf7db9bc8 0xf88e422a [xfs]xfs_log_move_tail+0x1ea (0xf7994400, 0x1, 0x0, 0xf0ae0450, 0xf7d4bcc4) xfs .text 0xf889e060 0xf88e4040 0xf88e4248 0xf7db9bf0 0xf88e69b8 [xfs]xlog_ungrant_log_space+0x164 (0xf7d4bcc4, 0xf0ae0450, 0xf7994400, 0x1, 0xf7db9df8) xfs .text 0xf889e060 0xf88e6854 0xf88e69c4 0xf7db9c14 0xf88e39a9 [xfs]xfs_log_done+0x79 (0xf7994400, 0xf0ae0450, 0x1, 0xf7994400, 0xf7db9c6c) xfs .text 0xf889e060 0xf88e3930 0xf88e39e0 0xf7db9cec 0xf88f1e4b [xfs]xfs_trans_commit+0x233 (0xf09af6e0, 0x4, 0x0, 0x10002, 0xf7db9e84) xfs .text 0xf889e060 0xf88f1c18 0xf88f1f6c 0xf7db9e04 0xf890a218 [xfs]xfs_strategy+0x6a8 (0xf7de7de8, 0x1, 0xf037dd00, 0xf037dd00, 0x8) xfs .text 0xf889e060 0xf8909b70 0xf890a474 0xf7db9ddc 0xc01a0520 generic_make_request+0xa4 (0x1, 0xf037dd00, 0x0, 0x1, 0xf7db9e18) kernel .text 0xc0100000 0xc01a047c 0xc01a05a4 0xf7db9df8 0xc01a05f8 submit_bh+0x54 (0xf04c14c4, 0xf000, 0x0, 0x1000, 0x10002) kernel .text 0xc0100000 0xc01a05a4 0xc01a0618 0xf7db9e44 0xf89085f4 [xfs]linvfs_pb_bmap+0x80 (0xf066662c, 0xf000, 0x0, 0x1000, 0xf7db9e84) xfs .text 0xf889e060 0xf8908574 0xf89086a4 0xf7db9ea4 0xf89038b0 [xfs]pagebuf_delalloc_convert+0x44 (0xf066662c, 0xc208a6a4, 0x10002, 0xf8908574, 0xc208a6a4) xfs .text 0xf889e060 0xf890386c 0xf8903950 0xf7db9ee8 0xf89028cc [xfs]pagebuf_write_full_page+0x6c (0xc208a6a4, 0xf8908574) xfs .text 0xf889e060 0xf8902860 0xf8902a20 0xf7db9ef8 0xf89087f1 [xfs]linvfs_write_full_page+0x11 (0xc208a6a4, 0xf03873b8, 0x0, 0xf0387718) xfs .text 0xf889e060 0xf89087e0 0xf8908800 0xf7db9f10 0xc0143b48 _write_buffer+0x68 (0xf03873b8, 0x0, 0xc03258e0, 0xc03258e0, 0xc03258e0) kernel .text 0xc0100000 0xc0143ae0 0xc0143b64 0xf7db9fb8 0xc0143d60 write_some_buffers+0xb8 (0xf7994400, 0x31, 0xf7994800, 0xf7db9fb8, 0xc0149064) kernel .text 0xc0100000 0xc0143ca8 0xc0143e84 0xf7db9fa4 0xf890cc11 [xfs]linvfs_write_super+0x2d xfs .text 0xf889e060 0xf890cbe4 0xf890cc18 0xc0105787 kernel_thread+0x23 kernel .text 0xc0100000 0xc0105764 0xc010579c Greetings -- Robert Sander Computer Scientist Epigenomics AG Bioinformatics R&D www.epigenomics.com Kastanienallee 24 +493024345330 10435 Berlin From owner-linux-xfs@oss.sgi.com Wed Jan 23 08:18:54 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0NGIsj07025 for linux-xfs-outgoing; Wed, 23 Jan 2002 08:18:54 -0800 Received: from deliverator.sgi.com (deliverator.sgi.com [204.94.214.10]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0NGIiP06986 for ; Wed, 23 Jan 2002 08:18:44 -0800 Received: from zeus-e8.americas.sgi.com (zeus-e8.americas.sgi.com [128.162.8.103]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id HAA01029 for ; Wed, 23 Jan 2002 07:14:19 -0800 (PST) mail_from (lord@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by zeus-e8.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id JAA114696; Wed, 23 Jan 2002 09:17:25 -0600 (CST) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id JAA73814; Wed, 23 Jan 2002 09:17:25 -0600 (CST) Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id g0NFGTN18807; Wed, 23 Jan 2002 09:16:29 -0600 Subject: Re: kernel oops with linux 2.4.17-xfs From: Steve Lord To: Robert Sander Cc: linux-xfs@oss.sgi.com In-Reply-To: References: <000601c1a018$62cf0c00$0264a8c0@skeletor> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/1.0.1 Date: 23 Jan 2002 09:16:29 -0600 Message-Id: <1011798989.1281.1206.camel@jen.americas.sgi.com> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 4910 Lines: 86 On Wed, 2002-01-23 at 09:12, Robert Sander wrote: > On Wed, 23 Jan 2002 14:55:46 +0000 (UTC), > Robert Sander wrote: > > I was running dbench on an NFSv3 (read kernel nfsd) exported filesystem > > and am able to reproduce the problem. It bugs out in spinlock.h, > > spinlock debugging is enabled. Same as the last one, turn off spinlock debugging, it does not mix with xfs. Steve > > When using the userspace nfsd I get this oops: > > kernel BUG at /mnt/raid/1/src/linux-2.4.17-xfs-new/include/asm/spinlock.h:86! > invalid operand: 0000 > CPU: 0 > EIP: 0010:[] Tainted: P > EFLAGS: 00010002 > eax: 0000004e ebx: 00000000 ecx: c02d81c4 edx: 00003042 > esi: f0ae0450 edi: f7d4bcc4 ebp: f7db9bc8 esp: f7db9bac > ds: 0018 es: 0018 ss: 0018 > Process kupdated (pid: 7, stackpage=f7db9000) > Stack: f89144c0 00000056 f7d4bcc4 f0ae0450 f7d4bd70 f7d4bd70 00000202 f7db9bf0 > f88e69b8 f7994400 00000001 00000000 f0ae0450 f7d4bcc4 00000001 00000202 > 00000202 f7db9c14 f88e39a9 f7d4bcc4 f0ae0450 f7994400 00000001 f7db9df8 > Call Trace: [] [] [] [] [] > [] [] [] [] [] [] > [] [] [] [] [] [] > [] [] [] [] [] [] > [] [] > > Code: 0f 0b 8d 74 26 00 c6 87 ac 00 00 00 01 ff 75 fc 9d 8d 65 ec > > Entering kdb (current=0xf7db8000, pid 7) on processor 0 Oops: invalid operand > due to oops @ 0xf88e422a > eax = 0x0000004e ebx = 0x00000000 ecx = 0xc02d81c4 edx = 0x00003042 > esi = 0xf0ae0450 edi = 0xf7d4bcc4 esp = 0xf7db9bac eip = 0xf88e422a > ebp = 0xf7db9bc8 xss = 0x00000018 xcs = 0x00000010 eflags = 0x00010002 > xds = 0x00000018 xes = 0x00000018 origeax = 0xffffffff ®s = 0xf7db9b78 > [0]kdb> bt > EBP EIP Function(args) > 0xf7db9bc8 0xf88e422a [xfs]xfs_log_move_tail+0x1ea (0xf7994400, 0x1, 0x0, 0xf0ae0450, 0xf7d4bcc4) > xfs .text 0xf889e060 0xf88e4040 0xf88e4248 > 0xf7db9bf0 0xf88e69b8 [xfs]xlog_ungrant_log_space+0x164 (0xf7d4bcc4, 0xf0ae0450, 0xf7994400, 0x1, 0xf7db9df8) > xfs .text 0xf889e060 0xf88e6854 0xf88e69c4 > 0xf7db9c14 0xf88e39a9 [xfs]xfs_log_done+0x79 (0xf7994400, 0xf0ae0450, 0x1, 0xf7994400, 0xf7db9c6c) > xfs .text 0xf889e060 0xf88e3930 0xf88e39e0 > 0xf7db9cec 0xf88f1e4b [xfs]xfs_trans_commit+0x233 (0xf09af6e0, 0x4, 0x0, 0x10002, 0xf7db9e84) > xfs .text 0xf889e060 0xf88f1c18 0xf88f1f6c > 0xf7db9e04 0xf890a218 [xfs]xfs_strategy+0x6a8 (0xf7de7de8, 0x1, 0xf037dd00, 0xf037dd00, 0x8) > xfs .text 0xf889e060 0xf8909b70 0xf890a474 > 0xf7db9ddc 0xc01a0520 generic_make_request+0xa4 (0x1, 0xf037dd00, 0x0, 0x1, 0xf7db9e18) > kernel .text 0xc0100000 0xc01a047c 0xc01a05a4 > 0xf7db9df8 0xc01a05f8 submit_bh+0x54 (0xf04c14c4, 0xf000, 0x0, 0x1000, 0x10002) > kernel .text 0xc0100000 0xc01a05a4 0xc01a0618 > 0xf7db9e44 0xf89085f4 [xfs]linvfs_pb_bmap+0x80 (0xf066662c, 0xf000, 0x0, 0x1000, 0xf7db9e84) > xfs .text 0xf889e060 0xf8908574 0xf89086a4 > 0xf7db9ea4 0xf89038b0 [xfs]pagebuf_delalloc_convert+0x44 (0xf066662c, 0xc208a6a4, 0x10002, 0xf8908574, 0xc208a6a4) > xfs .text 0xf889e060 0xf890386c 0xf8903950 > 0xf7db9ee8 0xf89028cc [xfs]pagebuf_write_full_page+0x6c (0xc208a6a4, 0xf8908574) > xfs .text 0xf889e060 0xf8902860 0xf8902a20 > 0xf7db9ef8 0xf89087f1 [xfs]linvfs_write_full_page+0x11 (0xc208a6a4, 0xf03873b8, 0x0, 0xf0387718) > xfs .text 0xf889e060 0xf89087e0 0xf8908800 > 0xf7db9f10 0xc0143b48 _write_buffer+0x68 (0xf03873b8, 0x0, 0xc03258e0, 0xc03258e0, 0xc03258e0) > kernel .text 0xc0100000 0xc0143ae0 0xc0143b64 > 0xf7db9fb8 0xc0143d60 write_some_buffers+0xb8 (0xf7994400, 0x31, 0xf7994800, 0xf7db9fb8, 0xc0149064) > kernel .text 0xc0100000 0xc0143ca8 0xc0143e84 > 0xf7db9fa4 0xf890cc11 [xfs]linvfs_write_super+0x2d > xfs .text 0xf889e060 0xf890cbe4 0xf890cc18 > 0xc0105787 kernel_thread+0x23 > kernel .text 0xc0100000 0xc0105764 0xc010579c > > Greetings > -- > Robert Sander > Computer Scientist Epigenomics AG > Bioinformatics R&D www.epigenomics.com Kastanienallee 24 > +493024345330 10435 Berlin -- Steve Lord voice: +1-651-683-3511 Principal Engineer, Filesystem Software email: lord@sgi.com From owner-linux-xfs@oss.sgi.com Wed Jan 23 08:36:47 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0NGalN11693 for linux-xfs-outgoing; Wed, 23 Jan 2002 08:36:47 -0800 Received: from gk.hm.epigenomics.net (qmailr@gk.hm.epigenomics.net [212.121.137.90]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0NGahP11649 for ; Wed, 23 Jan 2002 08:36:43 -0800 Received: (qmail 30651 invoked from network); 23 Jan 2002 15:36:41 -0000 Received: from raman.epigenomics.epi (qmailr@192.168.2.2) by salam.epigenomics.epi with SMTP; 23 Jan 2002 15:36:41 -0000 Received: (qmail 26891 invoked from network); 23 Jan 2002 15:36:37 -0000 Received: from broglie.epigenomics.epi (qmailr@192.168.1.5) by raman.epigenomics.epi with SMTP; 23 Jan 2002 15:36:37 -0000 Received: (qmail 1645 invoked by uid 9); 23 Jan 2002 15:36:37 -0000 From: Robert Sander Reply-To: Robert Sander X-Newsgroups: epi.ml.linux.xfs Subject: Re: kernel oops with linux 2.4.17-xfs Date: Wed, 23 Jan 2002 15:36:37 +0000 (UTC) Organization: Epigenomics AG Message-ID: References: <000601c1a018$62cf0c00$0264a8c0@skeletor> <1011798569.1279.1202.camel@jen.americas.sgi.com> X-Complaints-To: usenet@epigenomics.com User-Agent: slrn/0.9.7.3 (Linux) To: linux-xfs@oss.sgi.com Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 623 Lines: 15 On Wed, 23 Jan 2002 15:12:25 +0000 (UTC), Steve Lord wrote: > Please turn off spinlock debugging, it does not work in the xfs code, > we compile with -f unsignedchar and this breaks the check in the > spinlock debug where it does a signed comparison on a spinlock. I see, I thought of that, I will try again. Should be stated somewhere in big red letters. ;-) Greetings -- Robert Sander Computer Scientist Epigenomics AG Bioinformatics R&D www.epigenomics.com Kastanienallee 24 +493024345330 10435 Berlin From owner-linux-xfs@oss.sgi.com Wed Jan 23 08:41:52 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0NGfqg12820 for linux-xfs-outgoing; Wed, 23 Jan 2002 08:41:52 -0800 Received: from yog-sothoth.sgi.com (eugate.sgi.com [192.48.160.10]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0NGfjP12774 for ; Wed, 23 Jan 2002 08:41:46 -0800 Received: from zeus-e8.americas.sgi.com (zeus-e8.americas.sgi.com [128.162.8.103]) by yog-sothoth.sgi.com (980305.SGI.8.8.8-aspam-6.2/980304.SGI-aspam-europe) via ESMTP id QAA564618 for ; Wed, 23 Jan 2002 16:41:21 +0100 (CET) mail_from (lord@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by zeus-e8.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id JAA114920; Wed, 23 Jan 2002 09:40:21 -0600 (CST) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id JAA99731; Wed, 23 Jan 2002 09:40:21 -0600 (CST) Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id g0NFdOr18845; Wed, 23 Jan 2002 09:39:24 -0600 Subject: Re: kernel oops with linux 2.4.17-xfs From: Steve Lord To: Robert Sander Cc: linux-xfs@oss.sgi.com In-Reply-To: References: <000601c1a018$62cf0c00$0264a8c0@skeletor> <1011798569.1279.1202.camel@jen.americas.sgi.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/1.0.1 Date: 23 Jan 2002 09:39:24 -0600 Message-Id: <1011800364.7250.1210.camel@jen.americas.sgi.com> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 1044 Lines: 28 On Wed, 2002-01-23 at 09:36, Robert Sander wrote: > On Wed, 23 Jan 2002 15:12:25 +0000 (UTC), > Steve Lord wrote: > > Please turn off spinlock debugging, it does not work in the xfs code, > > we compile with -f unsignedchar and this breaks the check in the > > spinlock debug where it does a signed comparison on a spinlock. > > I see, I thought of that, I will try again. Should be stated somewhere > in big red letters. ;-) Yes, I was thinking of a #error somewhere in xfs if this option is turned on. Ideally xfs should use unsigned char explicitly rather than assuming it. Yet another thing for the todo list. Steve > > Greetings > -- > Robert Sander > Computer Scientist Epigenomics AG > Bioinformatics R&D www.epigenomics.com Kastanienallee 24 > +493024345330 10435 Berlin -- Steve Lord voice: +1-651-683-3511 Principal Engineer, Filesystem Software email: lord@sgi.com From owner-linux-xfs@oss.sgi.com Wed Jan 23 08:56:57 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0NGuvl16716 for linux-xfs-outgoing; Wed, 23 Jan 2002 08:56:57 -0800 Received: from d06lmsgate-4.uk.ibm.COM (d06lmsgate-4.uk.ibm.com [195.212.29.4]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0NGurP16673 for ; Wed, 23 Jan 2002 08:56:54 -0800 Received: from d06relay02.portsmouth.uk.ibm.com (d06relay02.portsmouth.uk.ibm.com [9.166.84.148]) by d06lmsgate-4.uk.ibm.COM (1.0.0) with ESMTP id PAA44130 for ; Wed, 23 Jan 2002 15:43:49 GMT Received: from d06ml039.portsmouth.uk.ibm.com (d06ml039_cs0 [9.180.35.44]) by d06relay02.portsmouth.uk.ibm.com (8.11.1m3/NCO v5.01) with ESMTP id g0NFs5O108104 for ; Wed, 23 Jan 2002 15:54:09 GMT Importance: Normal Subject: xfs web site To: linux-xfs@oss.sgi.com X-Mailer: Lotus Notes Release 5.0.5 September 22, 2000 Message-ID: From: "Andrew Turnbull" Date: Wed, 23 Jan 2002 15:41:54 +0000 X-MIMETrack: Serialize by Router on D06ML039/06/M/IBM(Release 5.0.8 |June 18, 2001) at 23/01/2002 15:56:17 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 255 Lines: 9 I have been trying to fing out more information about xfs, but your web site doesn't seem to work trying any of the links results in the same page being loaded. I have tried Netscape and IE, is this supposed to be happening ? Regards Andrew Turnbull From owner-linux-xfs@oss.sgi.com Wed Jan 23 09:08:26 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0NH8Qr19617 for linux-xfs-outgoing; Wed, 23 Jan 2002 09:08:26 -0800 Received: from smtpzilla1.xs4all.nl (smtpzilla1.xs4all.nl [194.109.127.137]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0NH8IP19582 for ; Wed, 23 Jan 2002 09:08:18 -0800 Received: from auto-nb1.xs4all.nl (qn-212-58-167-191.quicknet.nl [212.58.167.191]) by smtpzilla1.xs4all.nl (8.12.0/8.12.0) with ESMTP id g0NG8D69042865; Wed, 23 Jan 2002 17:08:13 +0100 (CET) Message-Id: <4.3.2.7.2.20020123170600.0384a7b8@pop.xs4all.nl> X-Sender: knuffie@pop.xs4all.nl X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 23 Jan 2002 17:07:00 +0100 To: "Andrew Turnbull" , linux-xfs@oss.sgi.com From: Seth Mos Subject: Re: xfs web site In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 498 Lines: 18 At 15:41 23-1-2002 +0000, Andrew Turnbull wrote: >I have been trying to fing out more information about xfs, but your web >site doesn't seem to work trying any of the links results in the same page >being loaded. I have tried Netscape and IE, is this supposed to be >happening ? Can you give a url or the page which contains that link? It works just fine for me. Cheers -- Seth Every program has two purposes one for which it was written and another for which it wasn't I use the last kind. From owner-linux-xfs@oss.sgi.com Wed Jan 23 10:44:20 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0NIiKv09819 for linux-xfs-outgoing; Wed, 23 Jan 2002 10:44:20 -0800 Received: from mel-rto4.wanadoo.fr (smtp-out-4.wanadoo.fr [193.252.19.23]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0NIiDP09775 for ; Wed, 23 Jan 2002 10:44:14 -0800 Received: from mel-rta6.wanadoo.fr (193.252.19.222) by mel-rto4.wanadoo.fr; 23 Jan 2002 18:44:02 +0100 Received: from AMontsouris-103-1-4-64.abo.wanadoo.fr (80.13.155.64) by mel-rta6.wanadoo.fr; 23 Jan 2002 18:43:42 +0100 Subject: Various anaconda installer fixes From: angus To: linux-xfs@oss.sgi.com Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/1.0.1 Date: 23 Jan 2002 18:43:42 +0100 Message-Id: <1011807822.12843.8.camel@localhost.localdomain> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 836 Lines: 24 Red Hat has just provided erratas boot disk image and update disk image. Will you provide similar errata images and update disk with xfs support ? Here it is: Advisory ID:RHBA-2002:016-06 This bug fix advisory corrects several issues in the Red Hat Linux 7.2 installer. - The installer would not set up SCSI modules to load in the same module post-install as they did during the install process in some cases. - Using a driver disk with a newer version of a SCSI driver than the one shipped in Red Hat Linux would not have the newer drive in the initrd used for booting the machine post-install. - Some machines with 3ware controllers would freeze at the partitioning screen and were unable to install to disks connected to the 3ware controller. - Some cases where the installer would traceback incorrectly have been resolved. TIA From owner-linux-xfs@oss.sgi.com Wed Jan 23 10:53:58 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0NIrwB12073 for linux-xfs-outgoing; Wed, 23 Jan 2002 10:53:58 -0800 Received: from deliverator.sgi.com (deliverator.sgi.com [204.94.214.10]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0NIrrP12039 for ; Wed, 23 Jan 2002 10:53:53 -0800 Received: from zeus-e8.americas.sgi.com (zeus-e8.americas.sgi.com [128.162.8.103]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id JAA15179 for ; Wed, 23 Jan 2002 09:49:28 -0800 (PST) mail_from (sandeen@sgi.com) Received: from poppy-e185.americas.sgi.com (poppy-e185.americas.sgi.com [128.162.185.207]) by zeus-e8.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id LAA116989; Wed, 23 Jan 2002 11:52:34 -0600 (CST) Received: from stout.americas.sgi.com (stout.americas.sgi.com [128.162.187.5]) by poppy-e185.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.7) with ESMTP id LAA47161; Wed, 23 Jan 2002 11:52:34 -0600 (CST) Subject: Re: Various anaconda installer fixes From: Eric Sandeen To: angus Cc: linux-xfs@oss.sgi.com In-Reply-To: <1011807822.12843.8.camel@localhost.localdomain> References: <1011807822.12843.8.camel@localhost.localdomain> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/1.0 (Preview Release) Date: 23 Jan 2002 11:52:34 -0600 Message-Id: <1011808354.32690.2.camel@stout.americas.sgi.com> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 1150 Lines: 34 I'll take a look and see what all is on the updates disk. Are you hitting any of these problems, or just asking? :) -Eric On Wed, 2002-01-23 at 11:43, angus wrote: > Red Hat has just provided erratas boot disk image and update disk image. > > Will you provide similar errata images and update disk with xfs support > ? > > Here it is: > Advisory ID:RHBA-2002:016-06 > This bug fix advisory corrects several issues in the Red Hat Linux 7.2 > installer. > > - The installer would not set up SCSI modules to load in the same module > post-install as they did during the install process in some cases. > - Using a driver disk with a newer version of a SCSI driver than the one > shipped in Red Hat Linux would not have the newer drive in the initrd > used > for booting the machine post-install. > - Some machines with 3ware controllers would freeze at the partitioning > screen and were unable to install to disks connected to the 3ware > controller. > - Some cases where the installer would traceback incorrectly have been > resolved. > > TIA -- Eric Sandeen XFS for Linux http://oss.sgi.com/projects/xfs sandeen@sgi.com SGI, Inc. From owner-linux-xfs@oss.sgi.com Wed Jan 23 13:13:19 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0NLDJ212492 for linux-xfs-outgoing; Wed, 23 Jan 2002 13:13:19 -0800 Received: from mail.dbaseiv.net (host93.summitmedianetwork.com [216.208.216.93] (may be forged)) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0NLDEP12455 for ; Wed, 23 Jan 2002 13:13:15 -0800 Received: (from matheny@localhost) by mail.dbaseiv.net (8.11.3/8.11.3) id g0NJcmb43074 for linux-xfs@oss.sgi.com; Wed, 23 Jan 2002 14:38:48 -0500 (EST) (envelope-from matheny) Date: Wed, 23 Jan 2002 14:38:47 -0500 From: Blake Matheny To: linux-xfs@oss.sgi.com Subject: Kernel OOPS and several filed nullified Message-ID: <20020123193846.GA43044@mail.dbaseiv.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.25i Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 713 Lines: 13 I am using the latest XFS from CVS with kernel version 2.4.17. I'm also using the rmap and preempt patches. Recently I had a kernel oops when I was in single user mode, kdb reported it being at line 812 in page_buf_io.c from the xfs source. When this happened several files got hosed, including my /etc/fstab. First, is this a known problem or is there something I can do to fix it? Looking at the source there didn't appear to be a blatently obvious fix. Second, is there some way to see which file were filled with null bytes? Several applications are no longer able to run, it appears that a few different libraries were also hosed. I'm not on the list so please CC me if you have any answers. Thanks. -Blake From owner-linux-xfs@oss.sgi.com Wed Jan 23 13:27:08 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0NLR8015023 for linux-xfs-outgoing; Wed, 23 Jan 2002 13:27:08 -0800 Received: from zok.sgi.com (zok.sgi.com [204.94.215.101]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0NLQwP14999 for ; Wed, 23 Jan 2002 13:26:58 -0800 Received: from zeus-e8.americas.sgi.com (zeus-e8.americas.sgi.com [128.162.8.103]) by zok.sgi.com (8.11.4/8.11.4/linux-outbound_gateway-1.1) with ESMTP id g0NKQoo28132 for ; Wed, 23 Jan 2002 12:26:50 -0800 Received: from poppy-e185.americas.sgi.com (poppy-e185.americas.sgi.com [128.162.185.207]) by zeus-e8.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id OAA119452; Wed, 23 Jan 2002 14:25:34 -0600 (CST) Received: from stout.americas.sgi.com (stout.americas.sgi.com [128.162.187.5]) by poppy-e185.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.7) with ESMTP id OAA61706; Wed, 23 Jan 2002 14:25:25 -0600 (CST) Subject: Re: Kernel OOPS and several filed nullified From: Eric Sandeen To: Blake Matheny Cc: linux-xfs@oss.sgi.com In-Reply-To: <20020123193846.GA43044@mail.dbaseiv.net> References: <20020123193846.GA43044@mail.dbaseiv.net> Content-Type: multipart/mixed; boundary="=-VacoF6so6uVvo463G1Mo" X-Mailer: Evolution/1.0 (Preview Release) Date: 23 Jan 2002 14:25:25 -0600 Message-Id: <1011817525.32690.10.camel@stout.americas.sgi.com> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 3281 Lines: 71 --=-VacoF6so6uVvo463G1Mo Content-Type: text/plain Content-Transfer-Encoding: 7bit On Wed, 2002-01-23 at 13:38, Blake Matheny wrote: > I am using the latest XFS from CVS with kernel version 2.4.17. I'm > also using the rmap and preempt patches. Recently I had a kernel oops > when I was in single user mode, kdb reported it being at line 812 in > page_buf_io.c from the xfs source. When this happened several files > got hosed, including my /etc/fstab. > First, is this a known problem or is there something I can do to fix > it? The "null" files issue is in the faq; you can search for these files with the attached C program (someone posted it to the list quite a while ago, read the source & use at your own risk). The only files that should be affected are ones that were being written at the time of the crash. For the oops, running it through ksymoops, or sending a KDB backtrace will be necessary to figure out what's going on. -Eric -- Eric Sandeen XFS for Linux http://oss.sgi.com/projects/xfs sandeen@sgi.com SGI, Inc. --=-VacoF6so6uVvo463G1Mo Content-Type: application/x-bzip Content-Disposition: attachment; filename=findnull.c.bz2 Content-Transfer-Encoding: base64 QlpoOTFBWSZTWQgZHEoAAqrfgFgwe//4f0+nno6/79/+YAZ8H2e943d5u9nB oAkKkDTKSepqb1Tam0ExMmmQyaA9QMI0AybSAIp5GkNTIAA0DQAAAAAAANT0 FNTRo1NAyZMTEAAyMjJoANNMQSaiIhU9kxUep6Tamh6hoNGCADIA0NGhzTIy GTBDRhMEaaNGIGmTIwABBIoJoaTEaBNU9oEyQDQDRpoHqaepoYmQJMyTLJDj 2f6nFeq/us63fpQma5tjC03Nh/HqoVXd8V2wX4EOWsJixbqhQ6VW9yyxzWNK lD20U8qNlXcpLdYqYw06QG/wKD0BRksrdQbgwGkISXBAk4SgVisARiwBESqF KQRIsaqFME0fjM858DegPbmHlj7/GZypceIEV22xFY20GdNwGKug/MkWFv2h 7yybgtzAuZiAQ5FSJQ16o6QYXzrBepXvc7ZHadRqlXBJAlpR0zWmmmrB0sc9 Owdd5S2KE7Qgb/6Jt6QC6IxdgwKF0EriRXgK1VqruoIQKiCarAgwCIAsMSxB YCKpgtNm9AW+4BGNBtxSzMYJpJDJrwyYwvW7yysXCi3nnTbgywPogxQYm3m+ D079d23Hf0cTVBFm0NyAwWJ1yD5dSgpih3TylaHkKIdXGAlB0wYPwl8fN8um DU0U7eBAqpLSYRYCQW9pXQtQioi5AUmMoAUQkJm4wsJ7MkQlOMhnhRL0EVAG iLlxw4dCG0c+SFSldeKxBspkrjIZvPgC2jYWolCBCiGQNWkmKQIBEBfJ116E 5IphNQb2DaXQsun0S254bSAYCYRM0+cYptsWyekcIXRsZd6CqoVR4LHjaQfF NlD6K2XfVe+UXGWvJbjBnZcapzgtv3rrmadJhFoshxFBMD5JG/ghXa60C0Vl AmCFTBjC0YRdA5FloqFuOoqWkrYXUXLM6zThLZNbdnIA7fH4LAp9xsZD/PSw KA7oHDs8OJ6Pm8OIhn+9OkIPGr6FFskIhEk87YfONhXHlGC6CRmFcBFsWDgx LnKUJRVvCMDiZv1FixIUCzYUB6oSMKiAqrgQnEsNWhMumnO1Hgf7RFEqSb93 v9GQkprwQs+kyG9IFfaMMAeSTFBGw42/HiB+99Wpp4w/P1Fy9Q0yFaWBkxQ9 R7ryS1vaI6UIzIA42pP/NmQ1Ja3MbewfrlYjAV7MxkWG4YLyRCVRG0YI/6SV sYaYkuxdFYRl5UjGE9OyfaoXCGfBqTOr+9NmO87H3SmGWSeYYdDyTE6DfCo9 Bsh+2CiNNBf22R5dpG/043NiWkCfOoSIKPOJJGS5+AGvJK4ONToQ2YBuWKHB GBvggmrRpsyahkHJjyAXSXppgcREZza3nZwh4kqowMIkBwIQgyIP4ncy1hNu y2Iy7e6Sp3HaslwqrKvhU60dr3BCemeO6lBdQjrQsmXeCjT4cp62fwc6DaqW ihqsMWMYcYkBpqHKnWvOjahpBWkSwPAR6bDl58R1r2BswDJkwClloKDJEd+X E7vZ2KAt+2gwoMBgd+zmBNNGTSDGt2/vEVCoZ3netsyKSUbCLN13fbiDRYJJ 1LbknSyd+MXP2AMrOlVnvWF62UaGU2lFRi0VSoJWhCgbjhA3mIXsgYDIrIkE AqpKvjrwLoLyBqXBbwtb1h8hYVWru8wsvXnSu0RXgb50iVEmGrgKjH3FtbLD amG9xIDfiZB1HdkdDZCHMtAgcacUzoXQwMHLNzENDByk9qT2UAtC8vvco3KY azlY+euOcPNFZCLTR0AHrDMSgGuGEk6Qk1wTRC8PA9XNrkUSy69ZvSpM6Ale F4mMIoNP26d2mw3PYYa6AdSqXUK6vL6eU2rz5uEiNcSsw4GawCHQXwDs7/K9 kTFsnbYxOS9W+zBmtGYOuzRmILMiDKkYEeZ7XDMhVQJo5X22HEs6pAiQrUED r54hqSSs7BDEtCyC1himkcMTidSzLEdZDkh8C1EcJLcjRCOka2GmmkUaiW2W 8WFezr1ozD3kyMmSJygRIf+LuSKcKEgEDI4lAA== --=-VacoF6so6uVvo463G1Mo-- From owner-linux-xfs@oss.sgi.com Wed Jan 23 14:39:23 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0NMdNr32548 for linux-xfs-outgoing; Wed, 23 Jan 2002 14:39:23 -0800 Received: from mailfast.internal.ima.pl (ip222ds.ima.pl [62.89.65.222]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0NMdGP32502 for ; Wed, 23 Jan 2002 14:39:17 -0800 Received: from mailhub.internal.ima.pl by mailfast.internal.ima.pl with ESMTP id g0NLZDX01262; Wed, 23 Jan 2002 22:35:13 +0100 Received: from mail.ima.pl by mailhub.internal.ima.pl with ESMTP id g0NLZCT01258; Wed, 23 Jan 2002 22:35:12 +0100 Received: from ima.pl (gw.ima.pl [195.117.13.12]) by mail.ima.pl with ESMTP id g0NLcxa26209; Wed, 23 Jan 2002 22:38:59 +0100 Message-ID: <3C4F2C4D.7090206@ima.pl> Date: Wed, 23 Jan 2002 22:34:05 +0100 From: Blizbor User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:0.9.6) Gecko/20011120 X-Accept-Language: en-us MIME-Version: 1.0 To: Eric Sandeen CC: angus , linux-xfs@oss.sgi.com Subject: Re: Various anaconda installer fixes References: <1011807822.12843.8.camel@localhost.localdomain> <1011808354.32690.2.camel@stout.americas.sgi.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 1100 Lines: 35 Hi, Eric, is it possible to correct one big mistake in the anaconda ? During install process on i686 instaler chooses binaries compiled fir i686 platform which makes such a instal unusable on Pentium MMX, K6, Cyrix etc. I'm administering one network in wchich such a "weak" machines exists but they have old 4x cdroms (CDRW and many CDR reading problems) or have no CD at all. They should be switched off as short as possible so I'm instaling and configuring system for them on spare disc in the other machine. There was no problem when I was working on the old Pentium but now I have p3 and this makes a problem. Ideal way to correct instaler is to add one check box to disable installation of i686 specific binaries. BTW, ISO images are clled "i386" so such a "optimization" is a big mistake. Regards, Blizbor Eric Sandeen wrote: > I'll take a look and see what all is on the updates disk. > > Are you hitting any of these problems, or just asking? :) > > -Eric > > On Wed, 2002-01-23 at 11:43, angus wrote: > >>Red Hat has just provided erratas boot disk image and update disk image. From owner-linux-xfs@oss.sgi.com Wed Jan 23 14:45:07 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0NMj7Y01133 for linux-xfs-outgoing; Wed, 23 Jan 2002 14:45:07 -0800 Received: from yog-sothoth.sgi.com (eugate.sgi.com [192.48.160.10]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0NMj1P01083 for ; Wed, 23 Jan 2002 14:45:01 -0800 Received: from zeus-e8.americas.sgi.com (zeus-e8.americas.sgi.com [128.162.8.103]) by yog-sothoth.sgi.com (980305.SGI.8.8.8-aspam-6.2/980304.SGI-aspam-europe) via ESMTP id WAA582330 for ; Wed, 23 Jan 2002 22:44:51 +0100 (CET) mail_from (sandeen@sgi.com) Received: from poppy-e185.americas.sgi.com (poppy-e185.americas.sgi.com [128.162.185.207]) by zeus-e8.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id PAA120795; Wed, 23 Jan 2002 15:43:32 -0600 (CST) Received: from stout.americas.sgi.com (stout.americas.sgi.com [128.162.187.5]) by poppy-e185.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.7) with ESMTP id PAA56884; Wed, 23 Jan 2002 15:43:32 -0600 (CST) Subject: Re: Various anaconda installer fixes From: Eric Sandeen To: Blizbor Cc: angus , linux-xfs@oss.sgi.com In-Reply-To: <3C4F2C4D.7090206@ima.pl> References: <1011807822.12843.8.camel@localhost.localdomain> <1011808354.32690.2.camel@stout.americas.sgi.com> <3C4F2C4D.7090206@ima.pl> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/1.0 (Preview Release) Date: 23 Jan 2002 15:43:32 -0600 Message-Id: <1011822212.12300.0.camel@stout.americas.sgi.com> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 614 Lines: 18 Hm, I assume this is the same behavior as the standard Red Hat 7.2? I don't think anything we did should have changed this behavior... and unfortunately I don't think we have the bandwidth to fix problems not related to XFS.... -Eric On Wed, 2002-01-23 at 15:34, Blizbor wrote: > Hi, > > Eric, is it possible to correct one big mistake in the anaconda ? > During install process on i686 instaler chooses binaries compiled > fir i686 platform which makes such a instal unusable on Pentium MMX, > K6, Cyrix etc. -- Eric Sandeen XFS for Linux http://oss.sgi.com/projects/xfs sandeen@sgi.com SGI, Inc. From owner-linux-xfs@oss.sgi.com Wed Jan 23 16:13:39 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0O0DdL20871 for linux-xfs-outgoing; Wed, 23 Jan 2002 16:13:39 -0800 Received: from smtpzilla1.xs4all.nl (smtpzilla1.xs4all.nl [194.109.127.137]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0O0DXP20829 for ; Wed, 23 Jan 2002 16:13:34 -0800 Received: from auto-nb1.xs4all.nl (qn-212-58-167-191.quicknet.nl [212.58.167.191]) by smtpzilla1.xs4all.nl (8.12.0/8.12.0) with ESMTP id g0NNDMft037112; Thu, 24 Jan 2002 00:13:28 +0100 (CET) Message-Id: <4.3.2.7.2.20020124001056.02b721b0@pop.xs4all.nl> X-Sender: knuffie@pop.xs4all.nl X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 24 Jan 2002 00:12:06 +0100 To: Blake Matheny , linux-xfs@oss.sgi.com From: Seth Mos Subject: Re: Kernel OOPS and several filed nullified In-Reply-To: <20020123193846.GA43044@mail.dbaseiv.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 1074 Lines: 30 At 14:38 23-1-2002 -0500, Blake Matheny wrote: >I am using the latest XFS from CVS with kernel version 2.4.17. I'm >also using the rmap and preempt patches. Recently I had a kernel oops >when I was in single user mode, kdb reported it being at line 812 in >page_buf_io.c from the xfs source. When this happened several files >got hosed, including my /etc/fstab. >First, is this a known problem or is there something I can do to fix >it? Looking at the source there didn't appear to be a blatently >obvious fix. Second, is there some way to see which file were filled >with null bytes? Several applications are no longer able to run, it >appears that a few different libraries were also hosed. I'm not on the >list so please CC me if you have any answers. Thanks. >-Blake Did you edit some files with vi? Yes? See FAQ No? What were you busy with doing in single user mode? Did recovery take place after a reboot or did the fs need fixing? Cheers -- Seth Every program has two purposes one for which it was written and another for which it wasn't I use the last kind. From owner-linux-xfs@oss.sgi.com Wed Jan 23 16:32:57 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0O0Wve26972 for linux-xfs-outgoing; Wed, 23 Jan 2002 16:32:57 -0800 Received: from mail.dbaseiv.net (host93.summitmedianetwork.com [216.208.216.93] (may be forged)) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0O0WoP26922 for ; Wed, 23 Jan 2002 16:32:50 -0800 Received: (from matheny@localhost) by mail.dbaseiv.net (8.11.3/8.11.3) id g0NMwHZ43848; Wed, 23 Jan 2002 17:58:17 -0500 (EST) (envelope-from matheny) Date: Wed, 23 Jan 2002 17:58:16 -0500 From: Blake Matheny To: Seth Mos Cc: Blake Matheny , linux-xfs@oss.sgi.com Subject: Re: Kernel OOPS and several filed nullified Message-ID: <20020123225816.GA43826@mail.dbaseiv.net> References: <20020123193846.GA43044@mail.dbaseiv.net> <4.3.2.7.2.20020124001056.02b721b0@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.20020124001056.02b721b0@pop.xs4all.nl> User-Agent: Mutt/1.3.25i Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 1800 Lines: 43 Eric Sandeen was good enough to email me a utility which looks for null'd files. That found a few of them. Most of /usr/local/lib (anything that had been open ~30 seconds before going to single user mode) got the whack. When the system oops'd I didn't have any files open. But it seems like anything that had been open up to 30 seconds before the crash was corrupted. 'Recovery' took place after reboot. Is there any chance that rmap11c, preempt or some of the hash patches I'm using is causing this behaviour? I was running XFS for months with no lost files. Recently any time my system crashes though I lose something. Thanks. -Blake Whatchu talkin' 'bout, Willis? > At 14:38 23-1-2002 -0500, Blake Matheny wrote: > >I am using the latest XFS from CVS with kernel version 2.4.17. I'm > >also using the rmap and preempt patches. Recently I had a kernel oops > >when I was in single user mode, kdb reported it being at line 812 in > >page_buf_io.c from the xfs source. When this happened several files > >got hosed, including my /etc/fstab. > >First, is this a known problem or is there something I can do to fix > >it? Looking at the source there didn't appear to be a blatently > >obvious fix. Second, is there some way to see which file were filled > >with null bytes? Several applications are no longer able to run, it > >appears that a few different libraries were also hosed. I'm not on the > >list so please CC me if you have any answers. Thanks. > >-Blake > > Did you edit some files with vi? > > Yes? See FAQ > No? What were you busy with doing in single user mode? Did recovery take > place after a reboot or did the fs need fixing? > > Cheers > > > > -- > Seth > Every program has two purposes one for which > it was written and another for which it wasn't > I use the last kind. From owner-linux-xfs@oss.sgi.com Wed Jan 23 16:52:31 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0O0qVe00637 for linux-xfs-outgoing; Wed, 23 Jan 2002 16:52:31 -0800 Received: from Cantor.suse.de (ns.suse.de [213.95.15.193]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0O0qLP00562 for ; Wed, 23 Jan 2002 16:52:22 -0800 Received: from Hermes.suse.de (Hermes.suse.de [213.95.15.136]) by Cantor.suse.de (Postfix) with ESMTP id 2C09E1ED2E; Thu, 24 Jan 2002 00:52:11 +0100 (MET) Date: Thu, 24 Jan 2002 00:52:08 +0100 From: Andi Kleen To: Blake Matheny Cc: Seth Mos , linux-xfs@oss.sgi.com Subject: Re: Kernel OOPS and several filed nullified Message-ID: <20020124005208.A13230@wotan.suse.de> References: <20020123193846.GA43044@mail.dbaseiv.net> <4.3.2.7.2.20020124001056.02b721b0@pop.xs4all.nl> <20020123225816.GA43826@mail.dbaseiv.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20020123225816.GA43826@mail.dbaseiv.net> User-Agent: Mutt/1.3.22.1i Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 2221 Lines: 40 On Wed, Jan 23, 2002 at 05:58:16PM -0500, Blake Matheny wrote: > Eric Sandeen was good enough to email me a utility which looks for > null'd files. That found a few of them. Most of /usr/local/lib > (anything that had been open ~30 seconds before going to single user > mode) got the whack. When the system oops'd I didn't have any files > open. But it seems like anything that had been open up to 30 seconds > before the crash was corrupted. 'Recovery' took place after reboot. Is > there any chance that rmap11c, preempt or some of the hash patches I'm > using is causing this behaviour? I was running XFS for months with no The behaviour is 'designed' into XFS. XFS does very aggressive delayed flushing of file data to get good extent allocation. On the other hand file system metadata like the file size is logged to a log on disk. When a file is opened for rewrite e.g. by an editor it is first truncated (file size set to 0, data discarded) and then when the editor writes it it a file size update is put into the log. The data is not flushed yet, but only later (this is needed to get very good IO performance) Now when the log is flushed earlier than the data you have a file with old data discarded, size already set to new size, but data not flushed to disk. The result is a file with a 'hole' over the whole file size. A whole is returned to you as zeroes. Log flushes usually happen a lot more often then data flushes; it can be triggered by an delete or rename, which data flush is only triggered after 30seconds (default buffer flush time). Basically it's the price you have to pay for the high performance with bulk IO in XFS. One way to make the problem likely less visible is to change the buffer flush delay. As you discovered it is 30seconds by default. It can be changed via the /proc/sys/vm/bdflush sysctl; the 6th number there is the buffer flush delay in jiffies (on i386 a jiffie is 10ms). For example you could set a buffer flush time of 5 seconds, this would force earlier file data flushing. Of course it could also have some bad impact on your IO performance, if you rely on fast IO you should probably better benchmark it first if it doesn't cause too big a slowdown. -Andi From owner-linux-xfs@oss.sgi.com Wed Jan 23 16:53:03 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0O0r3d00900 for linux-xfs-outgoing; Wed, 23 Jan 2002 16:53:03 -0800 Received: from rj.sgi.com (rj.SGI.COM [204.94.215.100]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0O0qwP00858 for ; Wed, 23 Jan 2002 16:52:59 -0800 Received: from zeus-e8.americas.sgi.com (zeus-e8.americas.sgi.com [128.162.8.103]) by rj.sgi.com (8.11.4/8.11.4/linux-outbound_gateway-1.1) with ESMTP id g0NNqpY12433 for ; Wed, 23 Jan 2002 15:52:51 -0800 Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by zeus-e8.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id RAA122335 for ; Wed, 23 Jan 2002 17:51:35 -0600 (CST) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id RAA55608 for ; Wed, 23 Jan 2002 17:51:35 -0600 (CST) From: Steve Lord Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id g0NNoaR30144; Wed, 23 Jan 2002 17:50:36 -0600 Message-Id: <200201232350.g0NNoaR30144@jen.americas.sgi.com> Date: Wed, 23 Jan 2002 17:50:36 -0600 Subject: TAKE - remove use of -funsigned-char from xfs Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 705 Lines: 22 This makes xfs and spinlock debugging in the same kernel possible. I have run some fairly heavy stress on this and it all works for me. I found the spots in xfs which were using just char as a data type which appear to matter. Date: Wed Jan 23 15:48:25 PST 2002 Workarea: jen.americas.sgi.com:/src/lord/xfs-linux.2.4 The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:110094a linux/fs/xfs/xfs_log_priv.h - 1.78 - Stop using char as the type for some fields in here, go to explicit use of a __uint8_t. linux/fs/xfs/Makefile - 1.133 linux/fs/xfs/linux/Makefile - 1.47 - Remove the explicit setting of -funsigned-char from the makefile From owner-linux-xfs@oss.sgi.com Wed Jan 23 17:19:31 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0O1JVj06050 for linux-xfs-outgoing; Wed, 23 Jan 2002 17:19:31 -0800 Received: from UberGeek.coremetrics.com ([209.184.141.163]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0O1JJP05992 for ; Wed, 23 Jan 2002 17:19:19 -0800 Received: (from austin@localhost) by UberGeek.coremetrics.com (8.11.6/8.11.6) id g0O0IYd24966; Wed, 23 Jan 2002 18:18:34 -0600 X-Authentication-Warning: UberGeek.coremetrics.com: austin set sender to austin@coremetrics.com using -f Subject: Re: Kernel OOPS and several filed nullified From: Austin Gonyou To: Blake Matheny Cc: Seth Mos , linux-xfs@oss.sgi.com In-Reply-To: <20020123225816.GA43826@mail.dbaseiv.net> References: <20020123225816.GA43826@mail.dbaseiv.net> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-qC9yPtKAsgEO/dcFL/7y" X-Mailer: Evolution/1.0.1 Date: 23 Jan 2002 18:18:34 -0600 Message-Id: <1011831514.24888.5.camel@UberGeek> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 2829 Lines: 78 --=-qC9yPtKAsgEO/dcFL/7y Content-Type: text/plain Content-Transfer-Encoding: quoted-printable I had similar issues when using the preempt. I stopped using it. Can't say much more than that, other than many apps I used actually had problems running under preempt.=20 On Wed, 2002-01-23 at 16:58, Blake Matheny wrote: > Eric Sandeen was good enough to email me a utility which looks for > null'd files. That found a few of them. Most of /usr/local/lib > (anything that had been open ~30 seconds before going to single user > mode) got the whack. When the system oops'd I didn't have any files > open. But it seems like anything that had been open up to 30 seconds > before the crash was corrupted. 'Recovery' took place after reboot. Is > there any chance that rmap11c, preempt or some of the hash patches I'm > using is causing this behaviour? I was running XFS for months with no > lost files. Recently any time my system crashes though I lose > something. Thanks. > -Blake >=20 > Whatchu talkin' 'bout, Willis? > > At 14:38 23-1-2002 -0500, Blake Matheny wrote: > > >I am using the latest XFS from CVS with kernel version 2.4.17. I'm > > >also using the rmap and preempt patches. Recently I had a kernel oops > > >when I was in single user mode, kdb reported it being at line 812 in > > >page_buf_io.c from the xfs source. When this happened several files > > >got hosed, including my /etc/fstab. > > >First, is this a known problem or is there something I can do to fix > > >it? Looking at the source there didn't appear to be a blatently > > >obvious fix. Second, is there some way to see which file were filled > > >with null bytes? Several applications are no longer able to run, it > > >appears that a few different libraries were also hosed. I'm not on > the > > >list so please CC me if you have any answers. Thanks. > > >-Blake > >=20 > > Did you edit some files with vi? > >=20 > > Yes? See FAQ > > No? What were you busy with doing in single user mode? Did recovery > take=20 > > place after a reboot or did the fs need fixing? > >=20 > > Cheers > >=20 > >=20 > >=20 > > -- > > Seth > > Every program has two purposes one for which > > it was written and another for which it wasn't > > I use the last kind. --=20 Austin Gonyou Systems Architect, CCNA Coremetrics, Inc. Phone: 512-698-7250 email: austin@coremetrics.com "It is the part of a good shepherd to shear his flock, not to skin it." Latin Proverb --=-qC9yPtKAsgEO/dcFL/7y Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQA8T1La94g6ZVmFMoIRAqh0AJ9PCor+l9a404ATILJ6T0OvaSiGPgCfbRJ4 QI+6KivkeyeEQFJaTKbm+Bw= =6b/s -----END PGP SIGNATURE----- --=-qC9yPtKAsgEO/dcFL/7y-- From owner-linux-xfs@oss.sgi.com Wed Jan 23 18:01:51 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0O21pW13218 for linux-xfs-outgoing; Wed, 23 Jan 2002 18:01:51 -0800 Received: from yog-sothoth.sgi.com (eugate.sgi.com [192.48.160.10]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0O21jP13170 for ; Wed, 23 Jan 2002 18:01:46 -0800 Received: from nodin.corp.sgi.com (fddi-nodin.corp.sgi.com [198.29.75.193]) by yog-sothoth.sgi.com (980305.SGI.8.8.8-aspam-6.2/980304.SGI-aspam-europe) via ESMTP id CAA593781 for ; Thu, 24 Jan 2002 02:01:12 +0100 (CET) mail_from (kaos@sgi.com) Received: from kao2.melbourne.sgi.com (kao2.melbourne.sgi.com [134.14.55.180]) by nodin.corp.sgi.com (8.11.4/8.11.2/nodin-1.0) with ESMTP id g0O10N425918051; Wed, 23 Jan 2002 17:00:23 -0800 (PST) Received: by kao2.melbourne.sgi.com (Postfix, from userid 16331) id 4C2D93000B8; Thu, 24 Jan 2002 12:00:19 +1100 (EST) Received: from kao2.melbourne.sgi.com (localhost [127.0.0.1]) by kao2.melbourne.sgi.com (Postfix) with ESMTP id CF21EBB; Thu, 24 Jan 2002 12:00:19 +1100 (EST) X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 From: Keith Owens To: Steve Lord Cc: linux-xfs@oss.sgi.com Subject: Re: TAKE - remove use of -funsigned-char from xfs In-reply-to: Your message of "Wed, 23 Jan 2002 17:50:36 MDT." <200201232350.g0NNoaR30144@jen.americas.sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 24 Jan 2002 12:00:14 +1100 Message-ID: <32687.1011834014@kao2.melbourne.sgi.com> Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 420 Lines: 10 On Wed, 23 Jan 2002 17:50:36 -0600, Steve Lord wrote: >This makes xfs and spinlock debugging in the same kernel possible. >linux/fs/xfs/Makefile - 1.133 >linux/fs/xfs/linux/Makefile - 1.47 > - Remove the explicit setting of -funsigned-char from the makefile fs/xfs_dmapi/Makefile still uses -funsigned-char. Deliberate? Also all the fs/xfs*/Makefile.in files need to be changed to keep them in sync. From owner-linux-xfs@oss.sgi.com Wed Jan 23 18:54:29 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0O2sTL25790 for linux-xfs-outgoing; Wed, 23 Jan 2002 18:54:29 -0800 Received: from qdusa.com ([204.94.79.2]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0O2sGP25703 for ; Wed, 23 Jan 2002 18:54:16 -0800 Received: (from root@localhost) by qdusa.com (8.8.7/8.8.7) id RAA08584 for linux-xfs@oss.sgi.com; Wed, 23 Jan 2002 17:54:08 -0800 Message-Id: <200201240154.RAA08584@qdusa.com> From: Luis Montes To: linux-xfs@oss.sgi.com Date: Wed, 23 Jan 2002 17:53:23 -0800 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Subject: Re: XFS kernel crash and corrupted FS References: <200201211818.KAA28743@qdusa.com> In-reply-to: <1011712866.1281.6.camel@jen.americas.sgi.com> X-mailer: Pegasus Mail for Windows (v2.54) Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 3871 Lines: 91 Hi there, Just for the record now, it seems that I had two possible causes of memory corruption: The Athlon-AGP bug mentioned (although it still seems far from clear that it will cause problems) and, more likely, I had my swap partition on one of the "blacklisted" hard-drives and udma was activated (blushing). I took it out of the system and is been up for one whole day! AGP is compiled as module and I haven't loaded it yet, though ... Anyway, thanks for your time > Subject: Re: XFS kernel crash and corrupted FS > From: Steve Lord > To: Luis Montes > Cc: linux-xfs@oss.sgi.com > Date: 22 Jan 2002 09:21:06 -0600 > Please take a look on linux kernel, there is a kernel bug which triggers > when you use DRI on an AMD processor. There is a good chance you hit this. > The problem is related to large page support being incorrectly enabled on > these processors. > > Take a look at this article: > > http://www.vnunet.com/News/1128504 > > Steve > > On Mon, 2002-01-21 at 12:17, Luis Montes wrote: > > Hi there, > > First of all I want to say that the following problem > > notwithstanding, I have been very happy with linux XFS. I've been > > using it successfully for a while now. But I've recently upgraded > > some of my hardware, and there might be some issues that cause the > > the whole system to crash and burn in the most awful way: > > > > My system is as follows: > > > > Hardware: > > AMD Athlon XP 1700 @ 1.4 something GHz > > ECS K7S5A Motherboard with the SIS 735 chipset > > 128 MB of PC133 SDRAM memory > > ATI all-in-wonder Rage 128 agp > > Two caviar IDE HD > > CDROM, DVD,SBLive! sound card. > > > > Sofware: > > Linux Slackware 8 > > 2.4.17 kernel with the xfs-2.4.17-all-i386.bz2 and the 2.4.17-1 rml > > patch > > gcc 2.95.3, used for all compilations > > There are 6 different partitions all with XFS installed. > > xfree86 4.1.99-5 from cvs with DRI enabled and latest ATI-gatos > > drivers > > except for some other user software everything else is from the > > standard Slackware install. > > > > The problem: > > I was just finished installing DRI, and was running glxgears to test > > it. Then when I tried to list a directory in one of the xfs > > partitions it reported input/output error. I rebooted and the root > > filesystem was corrupted beyond repair with the wnsuing kernel panic. > > I rebooted using other slackware install on the other disk (this one > > very standard, on an ext2 fs, but with the same xfs-capable kernel) > > and tried mounting the xfs filesystems on the xfs disk. Three are > > damaged beyond repair (one actually seems to appear as an ext3! > > filesystem) and the other three are fine. I would chalk this > > corruption to some bad interaction between my chipset and the HD's > > (I had another XFS corruption trying to set the DMA mode on this same > > HD). But trying to mount one of the damaged fs's actually produces a > > couple of "unable to handle kernel paging request" errors and the > > system just freezes. It seems repeatable, three times I tried > > mounting that filesystem and thre three times I got thar fault. Is > > this something you guys might want to look more closely? It's been a > > long long while since I had any kernel problems, and I just read in > > the FAQ that I might first run ksymoops. I will need to fix it some > > time soon, though, my wife isn't thrilled that nothing at home seems > > to be working these days ;) How should I gather info on this error > > before I go and reformat this HD? > -- > > Steve Lord voice: +1-651-683-3511 > Principal Engineer, Filesystem Software email: lord@sgi.com > > Luis A. Montes Physicist/Programmer Quantum Design e-mail: luis.montes@qdusa.com From owner-linux-xfs@oss.sgi.com Wed Jan 23 19:21:14 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0O3LE701346 for linux-xfs-outgoing; Wed, 23 Jan 2002 19:21:14 -0800 Received: from rj.sgi.com (rj.SGI.COM [204.94.215.100]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0O3LAP01315 for ; Wed, 23 Jan 2002 19:21:10 -0800 Received: from zeus-e8.americas.sgi.com (zeus-e8.americas.sgi.com [128.162.8.103]) by rj.sgi.com (8.11.4/8.11.4/linux-outbound_gateway-1.1) with ESMTP id g0O2L2Y19856 for ; Wed, 23 Jan 2002 18:21:02 -0800 Received: from tulip-e185.americas.sgi.com (tulip-e185.americas.sgi.com [128.162.185.208]) by zeus-e8.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id UAA123586; Wed, 23 Jan 2002 20:19:46 -0600 (CST) Received: from sgi.com (LfSi80McO6kyu4NMysWcq5d/lt4eVlmS@lord-h1.americas.sgi.com [206.11.101.42]) by tulip-e185.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.7) with ESMTP id UAA66486; Wed, 23 Jan 2002 20:19:46 -0600 (CST) Message-ID: <3C4F6F4C.9040607@sgi.com> Date: Wed, 23 Jan 2002 20:19:56 -0600 From: Stephen Lord User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.7) Gecko/20011226 X-Accept-Language: en-us MIME-Version: 1.0 To: Keith Owens CC: linux-xfs@oss.sgi.com Subject: Re: TAKE - remove use of -funsigned-char from xfs References: <32687.1011834014@kao2.melbourne.sgi.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 666 Lines: 24 Keith Owens wrote: >On Wed, 23 Jan 2002 17:50:36 -0600, >Steve Lord wrote: > >>This makes xfs and spinlock debugging in the same kernel possible. >>linux/fs/xfs/Makefile - 1.133 >>linux/fs/xfs/linux/Makefile - 1.47 >> - Remove the explicit setting of -funsigned-char from the makefile >> > >fs/xfs_dmapi/Makefile still uses -funsigned-char. Deliberate? Also all >the fs/xfs*/Makefile.in files need to be changed to keep them in sync. > Woops, no, I was building dmapi, but I did not spot that one. I will take a look at removing it too, although it looks like the whole header file cleanup job still needs to happen in the dmapi code. Steve From owner-linux-xfs@oss.sgi.com Wed Jan 23 20:33:06 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0O4X6920552 for linux-xfs-outgoing; Wed, 23 Jan 2002 20:33:06 -0800 Received: from zok.sgi.com (zok.sgi.com [204.94.215.101]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0O4WxP20512 for ; Wed, 23 Jan 2002 20:32:59 -0800 Received: from relay1.corp.sgi.com (spindle.corp.sgi.com [198.29.75.13]) by zok.sgi.com (8.11.4/8.11.4/linux-outbound_gateway-1.1) with ESMTP id g0O3Wqo20341 for ; Wed, 23 Jan 2002 19:32:52 -0800 Received: from chuckle.americas.sgi.com (sandeen@chuckle.americas.sgi.com [128.162.211.44]) by relay1.corp.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) via ESMTP id TAA20665; Wed, 23 Jan 2002 19:32:21 -0800 (PST) Date: Wed, 23 Jan 2002 21:32:20 -0600 (CST) From: Eric Sandeen X-X-Sender: To: Stephen Lord cc: Keith Owens , Subject: Re: TAKE - remove use of -funsigned-char from xfs In-Reply-To: <3C4F6F4C.9040607@sgi.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 1293 Lines: 45 Keith, I'd like your input on this, since you're the guru. :) I took care of your(?) comment in the makefiles: # This needs -I. because everything does #include instead of "xfs.h". # The code is wrong, local files should be included using "xfs.h", not # but I am not going to change every file at the moment. and changed all the xfs #includes to local includes, but for some of the files in fs/xfs/linux, we need to include files from fs/xfs. It looks a bit ugly to do: #include "../xfs.h" Is there a better way? -Eric On Wed, 23 Jan 2002, Stephen Lord wrote: > Keith Owens wrote: > > >On Wed, 23 Jan 2002 17:50:36 -0600, > >Steve Lord wrote: > > > >>This makes xfs and spinlock debugging in the same kernel possible. > >>linux/fs/xfs/Makefile - 1.133 > >>linux/fs/xfs/linux/Makefile - 1.47 > >> - Remove the explicit setting of -funsigned-char from the makefile > >> > > > >fs/xfs_dmapi/Makefile still uses -funsigned-char. Deliberate? Also all > >the fs/xfs*/Makefile.in files need to be changed to keep them in sync. > > > Woops, no, I was building dmapi, but I did not spot that one. I will take a > look at removing it too, although it looks like the whole header > file cleanup job still needs to happen in the dmapi code. > > Steve > > > > > From owner-linux-xfs@oss.sgi.com Wed Jan 23 20:51:01 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0O4p1u24148 for linux-xfs-outgoing; Wed, 23 Jan 2002 20:51:01 -0800 Received: from rj.sgi.com (rj.SGI.COM [204.94.215.100]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0O4owP24120 for ; Wed, 23 Jan 2002 20:50:58 -0800 Received: from zeus-e8.americas.sgi.com (zeus-e8.americas.sgi.com [128.162.8.103]) by rj.sgi.com (8.11.4/8.11.4/linux-outbound_gateway-1.1) with ESMTP id g0O3ooY23717 for ; Wed, 23 Jan 2002 19:50:50 -0800 Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by zeus-e8.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id VAA124191 for ; Wed, 23 Jan 2002 21:49:35 -0600 (CST) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id VAA56594 for ; Wed, 23 Jan 2002 21:49:34 -0600 (CST) From: Steve Lord Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id g0O3mXe02546; Wed, 23 Jan 2002 21:48:33 -0600 Message-Id: <200201240348.g0O3mXe02546@jen.americas.sgi.com> Date: Wed, 23 Jan 2002 21:48:33 -0600 Subject: TAKE - fix xfs debug build Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 463 Lines: 19 The -f unsigned-char removal broke the debug build, this fixes it again. Date: Wed Jan 23 19:47:42 PST 2002 Workarea: jen.americas.sgi.com:/src/lord/xfs-linux.2.4 The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:110107a linux/fs/xfs/xfs_log.h - 1.57 linux/fs/xfs/xfs_log.c - 1.243 linux/fs/xfs/xfs_log_priv.h - 1.79 - fix debug build linux/fs/xfs/Makefile.in - 1.12 - remove -f unsigned-char From owner-linux-xfs@oss.sgi.com Wed Jan 23 22:35:23 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0O6ZNN13023 for linux-xfs-outgoing; Wed, 23 Jan 2002 22:35:23 -0800 Received: from rj.sgi.com (rj.SGI.COM [204.94.215.100]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0O6ZJP12985 for ; Wed, 23 Jan 2002 22:35:19 -0800 Received: from nodin.corp.sgi.com (fddi-nodin.corp.sgi.com [198.29.75.193]) by rj.sgi.com (8.11.4/8.11.4/linux-outbound_gateway-1.1) with ESMTP id g0O5ZCY28042 for ; Wed, 23 Jan 2002 21:35:12 -0800 Received: from kao2.melbourne.sgi.com (kao2.melbourne.sgi.com [134.14.55.180]) by nodin.corp.sgi.com (8.11.4/8.11.2/nodin-1.0) with ESMTP id g0O5YB426008486; Wed, 23 Jan 2002 21:34:11 -0800 (PST) Received: by kao2.melbourne.sgi.com (Postfix, from userid 16331) id 20D9E3000B8; Thu, 24 Jan 2002 16:34:08 +1100 (EST) Received: from kao2.melbourne.sgi.com (localhost [127.0.0.1]) by kao2.melbourne.sgi.com (Postfix) with ESMTP id E715FBB; Thu, 24 Jan 2002 16:34:08 +1100 (EST) X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 From: Keith Owens To: Eric Sandeen Cc: Stephen Lord , linux-xfs@oss.sgi.com Subject: Re: TAKE - remove use of -funsigned-char from xfs In-reply-to: Your message of "Wed, 23 Jan 2002 21:32:20 MDT." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 24 Jan 2002 16:34:03 +1100 Message-ID: <2293.1011850443@kao2.melbourne.sgi.com> Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 837 Lines: 22 On Wed, 23 Jan 2002 21:32:20 -0600 (CST), Eric Sandeen wrote: >Keith, I'd like your input on this, since you're the guru. :) > >I took care of your(?) comment in the makefiles: > ># This needs -I. because everything does #include instead of "xfs.h". ># The code is wrong, local files should be included using "xfs.h", not ># but I am not going to change every file at the moment. > >and changed all the xfs #includes to local includes, but for some of the >files in fs/xfs/linux, we need to include files from fs/xfs. It looks a bit >ugly to do: > >#include "../xfs.h" > >Is there a better way? In the source, always do #include "xfs.h". Then you can rearrange directories, move source between directories etc. without changing the code. In the Makefile, use EXTRA_CFLAGS += -I $(TOPDIR)/fs/xfs. From owner-linux-xfs@oss.sgi.com Thu Jan 24 00:06:36 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0O86ab04692 for linux-xfs-outgoing; Thu, 24 Jan 2002 00:06:36 -0800 Received: from relay.xlink.net (relay.xlink.net [193.141.40.4]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0O86KP04604 for ; Thu, 24 Jan 2002 00:06:21 -0800 Received: from lizard.webland.de (lizard.webland.de [194.122.76.201]) by relay.xlink.net (8.9.3/8.8.7) with ESMTP id IAA05383; Thu, 24 Jan 2002 08:06:12 +0100 (MET) Received: (from uucp@localhost) by lizard.webland.de (8.8.8/8.8.7) id IAA23443; Thu, 24 Jan 2002 08:06:12 +0100 (MET) >Received: from mobile.sauter-bc.com (unknown [10.1.6.21]) by basel1.sauter-bc.com (Postfix) with ESMTP id CB11257306; Thu, 24 Jan 2002 08:05:16 +0100 (CET) Received: from ch.sauter-bc.com (support.cad.sba [10.1.200.117]) by mobile.sauter-bc.com (Postfix) with ESMTP id 20C6525835; Thu, 24 Jan 2002 08:05:16 +0100 (CET) Message-ID: <3C4FB22C.7E038E9B@ch.sauter-bc.com> Date: Thu, 24 Jan 2002 08:05:16 +0100 From: Simon Matter Organization: Sauter AG, Basel X-Mailer: Mozilla 4.77 [de] (X11; U; Linux 2.2.19-6.2.12 i686) X-Accept-Language: de-CH, en MIME-Version: 1.0 To: Eric Sandeen Cc: angus , linux-xfs@oss.sgi.com Subject: Re: Various anaconda installer fixes References: <1011807822.12843.8.camel@localhost.localdomain> <1011808354.32690.2.camel@stout.americas.sgi.com> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 1533 Lines: 44 Eric Sandeen schrieb: > > I'll take a look and see what all is on the updates disk. > > Are you hitting any of these problems, or just asking? :) > > -Eric > > On Wed, 2002-01-23 at 11:43, angus wrote: > > Red Hat has just provided erratas boot disk image and update disk image. > > > > Will you provide similar errata images and update disk with xfs support > > ? > > > > Here it is: > > Advisory ID:RHBA-2002:016-06 > > This bug fix advisory corrects several issues in the Red Hat Linux 7.2 > > installer. > > > > - The installer would not set up SCSI modules to load in the same module > > post-install as they did during the install process in some cases. > > - Using a driver disk with a newer version of a SCSI driver than the one > > shipped in Red Hat Linux would not have the newer drive in the initrd > > used I tried to install 7.2-XFS on a IBM Netfinity last week and ended up with unbootable installation (can not mount root dev). IIRC the modules for RAID were not correctly installed but unfortunately there was absolutely no time to investigate. Maybe this has been corrected in the new installer. > > for booting the machine post-install. > > - Some machines with 3ware controllers would freeze at the partitioning > > screen and were unable to install to disks connected to the 3ware > > controller. > > - Some cases where the installer would traceback incorrectly have been > > resolved. > > > > TIA > -- > Eric Sandeen XFS for Linux http://oss.sgi.com/projects/xfs > sandeen@sgi.com SGI, Inc. From owner-linux-xfs@oss.sgi.com Thu Jan 24 00:53:26 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0O8rQP18668 for linux-xfs-outgoing; Thu, 24 Jan 2002 00:53:26 -0800 Received: from mel-rto3.wanadoo.fr (smtp-out-3.wanadoo.fr [193.252.19.233]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0O8rLP18619 for ; Thu, 24 Jan 2002 00:53:21 -0800 Received: from mel-rta8.wanadoo.fr (193.252.19.79) by mel-rto3.wanadoo.fr; 24 Jan 2002 08:53:12 +0100 Received: from AMontsouris-103-1-4-153.abo.wanadoo.fr (80.13.155.153) by mel-rta8.wanadoo.fr; 24 Jan 2002 08:53:04 +0100 Subject: Re: Various anaconda installer fixes From: angus To: Simon Matter Cc: linux-xfs@oss.sgi.com In-Reply-To: <3C4FB22C.7E038E9B@ch.sauter-bc.com> References: <1011807822.12843.8.camel@localhost.localdomain> <1011808354.32690.2.camel@stout.americas.sgi.com> <3C4FB22C.7E038E9B@ch.sauter-bc.com> Content-Type: text/plain; charset=ISO-8859-15 X-Mailer: Evolution/1.0.1 Date: 24 Jan 2002 08:53:04 +0100 Message-Id: <1011858784.1214.14.camel@localhost.localdomain> Mime-Version: 1.0 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id g0O8rLP18625 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 1173 Lines: 31 le jeu 24-01-2002 à 08:05, Simon Matter a écrit : > I tried to install 7.2-XFS on a IBM Netfinity last week and ended up > with unbootable installation (can not mount root dev). IIRC the modules > for RAID were not correctly installed but unfortunately there was > absolutely no time to investigate. Maybe this has been corrected in the > new installer. Probably not. See the list of the corrected bugs. You can nevertheless submit a bugzilla report to Red Hat if you reproduce the same problem with an original Red Hat distribution (i.e. without xFS). Bug IDs fixed (http://bugzilla.redhat.com/bugzilla for more info): 57864 - Anaconda crashed on attempt to modify auto-created partitions via Disk Druid 54947 - Installers hangs after hiding help 56692 - drive buttons falling off "fdisk screen" 55373 - Install kickstart with --onpart 53923 - kickstart: lba32 and onprimary option is broken 57600 - kickstart lilocheck command broken - was Syntax error in /usr/lib/anaconda/kickstart.py 55037 - Anaconda does not include updated driver in the initrd image 55310 - Problem with Kickstart and Software RAID? 57175 - post-install cannot modify /etc/X11/XF86Config-4 From owner-linux-xfs@oss.sgi.com Thu Jan 24 01:05:15 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0O95FY23972 for linux-xfs-outgoing; Thu, 24 Jan 2002 01:05:15 -0800 Received: from relay.xlink.net (relay.xlink.net [193.141.40.5]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0O95CP23939 for ; Thu, 24 Jan 2002 01:05:12 -0800 Received: from lizard.webland.de (lizard.webland.de [194.122.76.201]) by relay.xlink.net (8.9.3/8.8.7) with ESMTP id JAA02756 for ; Thu, 24 Jan 2002 09:05:08 +0100 (MET) Received: (from uucp@localhost) by lizard.webland.de (8.8.8/8.8.7) id JAA28205 for linux-xfs@oss.sgi.com; Thu, 24 Jan 2002 09:05:08 +0100 (MET) >Received: from mobile.sauter-bc.com (unknown [10.1.6.21]) by basel1.sauter-bc.com (Postfix) with ESMTP id 1043A57306 for ; Thu, 24 Jan 2002 09:04:21 +0100 (CET) Received: from ch.sauter-bc.com (support.cad.sba [10.1.200.117]) by mobile.sauter-bc.com (Postfix) with ESMTP id EE7CC25835 for ; Thu, 24 Jan 2002 09:04:20 +0100 (CET) Message-ID: <3C4FC004.5691665E@ch.sauter-bc.com> Date: Thu, 24 Jan 2002 09:04:20 +0100 From: Simon Matter Organization: Sauter AG, Basel X-Mailer: Mozilla 4.77 [de] (X11; U; Linux 2.2.19-6.2.12 i686) X-Accept-Language: de-CH, en MIME-Version: 1.0 To: linux-xfs Subject: New Kernel RPMs Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 188 Lines: 7 RedHat has just released new Kernel RPMs for 7.1 and 7.2. Are there any chances to get updates of the SGI XFS Kernel RPMs too? Otherwise I'll try it myself but I'm not a guru :) -Simon From owner-linux-xfs@oss.sgi.com Thu Jan 24 01:58:59 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0O9wxL07529 for linux-xfs-outgoing; Thu, 24 Jan 2002 01:58:59 -0800 Received: from gum.csee.uq.edu.au (gum.csee.uq.edu.au [130.102.66.1]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0O9wsP07482 for ; Thu, 24 Jan 2002 01:58:54 -0800 Received: from nut.csee.uq.edu.au (nut.csee.uq.edu.au [130.102.66.13]) by gum.csee.uq.edu.au (8.11.6/8.11.6) with ESMTP id g0O8wl617206 for ; Thu, 24 Jan 2002 18:58:47 +1000 (EST) Received: from SPIKE (spike.csee.uq.edu.au [130.102.66.71]) by nut.csee.uq.edu.au (8.11.6/8.11.6) with SMTP id g0O8wlU26482 for ; Thu, 24 Jan 2002 18:58:47 +1000 (EST) Message-ID: <056601c1a4b5$556bd290$47426682@csee.uq.edu.au> From: "Chris Pascoe" To: Subject: Mounting snapshots w/duplicate UUIDs Date: Thu, 24 Jan 2002 18:57:16 +1000 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.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-Scanned-By: MIMEDefang 1.3 (www dot roaringpenguin dot com slash mimedefang) Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 770 Lines: 20 Hello, I recall seeing something about this and/or a solution for this a while ago, but a quick google and search of my local mail archives didn't reveal anything obvious. How does one avoid the: "XFS: Filesystem has duplicate UUID - can't mount" when trying to mount a snapshot volume? I can't change the uuid on the snapshot, as it is read-only. I'm using the 2.4.17 CVS tree from yesterday, with LVM-1.0.1, VFS-lock and the patch from Eric to make LVM not allocate the huge array on the stack, as per some other threads here. I seem to have created a snapshot ok (although I deadlocked the machine the first time I tried - I got some traces from kdb, but then it turned out that my serial console wasn't logging, ho hum), I just can't mount it! Thanks, Chris From owner-linux-xfs@oss.sgi.com Thu Jan 24 02:05:42 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0OA5gi09596 for linux-xfs-outgoing; Thu, 24 Jan 2002 02:05:42 -0800 Received: from gum.csee.uq.edu.au (gum.csee.uq.edu.au [130.102.66.1]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0OA5bP09545 for ; Thu, 24 Jan 2002 02:05:38 -0800 Received: from nut.csee.uq.edu.au (nut.csee.uq.edu.au [130.102.66.13]) by gum.csee.uq.edu.au (8.11.6/8.11.6) with ESMTP id g0O95W617792 for ; Thu, 24 Jan 2002 19:05:32 +1000 (EST) Received: from SPIKE (spike.csee.uq.edu.au [130.102.66.71]) by nut.csee.uq.edu.au (8.11.6/8.11.6) with SMTP id g0O95WU26691 for ; Thu, 24 Jan 2002 19:05:32 +1000 (EST) Message-ID: <057801c1a4b6$470b2380$47426682@csee.uq.edu.au> From: "Chris Pascoe" To: Subject: Re: Mounting snapshots w/duplicate UUIDs Date: Thu, 24 Jan 2002 19:05:32 +1000 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.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-Scanned-By: MIMEDefang 1.3 (www dot roaringpenguin dot com slash mimedefang) Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 403 Lines: 14 A few minutes ago, I wrote: > How does one avoid the: "XFS: Filesystem has duplicate UUID - can't mount" > when trying to mount a snapshot volume? I can't change the uuid on the > snapshot, as it is read-only. Of course, I just did a grep of the XFS source after writing, and found the nouuid mount option, which lets me mount the volume happily. Thanks to those who ESP'd their answers :) Chris From owner-linux-xfs@oss.sgi.com Thu Jan 24 08:09:01 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0OG91R10024 for linux-xfs-outgoing; Thu, 24 Jan 2002 08:09:01 -0800 Received: from yog-sothoth.sgi.com (eugate.sgi.com [192.48.160.10]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0OG8uP09995 for ; Thu, 24 Jan 2002 08:08:56 -0800 Received: from relay1.corp.sgi.com (spindle.corp.sgi.com [198.29.75.13]) by yog-sothoth.sgi.com (980305.SGI.8.8.8-aspam-6.2/980304.SGI-aspam-europe) via ESMTP id QAA664127 for ; Thu, 24 Jan 2002 16:07:39 +0100 (CET) mail_from (sandeen@sgi.com) Received: from chuckle.americas.sgi.com (sandeen@chuckle.americas.sgi.com [128.162.211.44]) by relay1.corp.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) via ESMTP id HAA11115; Thu, 24 Jan 2002 07:08:20 -0800 (PST) Date: Thu, 24 Jan 2002 09:08:19 -0600 (CST) From: Eric Sandeen X-X-Sender: To: Simon Matter cc: linux-xfs Subject: Re: New Kernel RPMs In-Reply-To: <3C4FC004.5691665E@ch.sauter-bc.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 339 Lines: 15 Hm, still 2.4.9! The update might not be too difficult, I'll take a look sometime soon. -Eric On Thu, 24 Jan 2002, Simon Matter wrote: > RedHat has just released new Kernel RPMs for 7.1 and 7.2. Are there any > chances to get updates of the SGI XFS Kernel RPMs too? Otherwise I'll > try it myself but I'm not a guru :) > > -Simon > > From owner-linux-xfs@oss.sgi.com Thu Jan 24 08:19:32 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0OGJW710784 for linux-xfs-outgoing; Thu, 24 Jan 2002 08:19:32 -0800 Received: from relay.xlink.net (relay.xlink.net [193.141.40.4]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0OGJQP10759 for ; Thu, 24 Jan 2002 08:19:26 -0800 Received: from lizard.webland.de (lizard.webland.de [194.122.76.201]) by relay.xlink.net (8.9.3/8.8.7) with ESMTP id QAA07554; Thu, 24 Jan 2002 16:19:18 +0100 (MET) Received: (from uucp@localhost) by lizard.webland.de (8.8.8/8.8.7) id QAA11978; Thu, 24 Jan 2002 16:19:17 +0100 (MET) >Received: from mobile.sauter-bc.com (unknown [10.1.6.21]) by basel1.sauter-bc.com (Postfix) with ESMTP id 8FCFE57306; Thu, 24 Jan 2002 16:18:26 +0100 (CET) Received: from ch.sauter-bc.com (support.cad.sba [10.1.200.117]) by mobile.sauter-bc.com (Postfix) with ESMTP id 7F28825835; Thu, 24 Jan 2002 16:18:26 +0100 (CET) Message-ID: <3C5025C2.BE55815A@ch.sauter-bc.com> Date: Thu, 24 Jan 2002 16:18:26 +0100 From: Simon Matter Organization: Sauter AG, Basel X-Mailer: Mozilla 4.77 [de] (X11; U; Linux 2.2.19-6.2.12 i686) X-Accept-Language: de-CH, en MIME-Version: 1.0 To: Eric Sandeen Cc: linux-xfs Subject: Re: New Kernel RPMs References: Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 933 Lines: 33 Eric Sandeen schrieb: > > Hm, still 2.4.9! The update might not be too difficult, I'll take It's more like 2.4.9+++++++ > a look sometime soon. I'm currently compiling the 7.1 RPM but got some problems. Some patches like nfs-lockd are now included in stock RH and I removed them from the spec. I have also modified the .config files. Now while compiling I got an error related to kdb. It was complaining that it tried to apply a patch which was already applied. I have removed the kdb patch an try (and error) again. One thing I saw is that RedHat has enabled to build debug kernel while you disabled this in the spec. Was it causing problems? -Simon > > -Eric > > On Thu, 24 Jan 2002, Simon Matter wrote: > > > RedHat has just released new Kernel RPMs for 7.1 and 7.2. Are there any > > chances to get updates of the SGI XFS Kernel RPMs too? Otherwise I'll > > try it myself but I'm not a guru :) > > > > -Simon > > > > From owner-linux-xfs@oss.sgi.com Thu Jan 24 08:22:45 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0OGMj511092 for linux-xfs-outgoing; Thu, 24 Jan 2002 08:22:45 -0800 Received: from pneumatic-tube.sgi.com (pneumatic-tube.sgi.com [204.94.214.22]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0OGMgP11068 for ; Thu, 24 Jan 2002 08:22:42 -0800 Received: from zeus-e8.americas.sgi.com (zeus-e8.americas.sgi.com [128.162.8.103]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id HAA06035 for ; Thu, 24 Jan 2002 07:23:35 -0800 (PST) mail_from (roehrich@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by zeus-e8.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id JAA130316; Thu, 24 Jan 2002 09:21:21 -0600 (CST) Received: from slobber.americas.sgi.com (slobber.americas.sgi.com [128.162.187.52]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id JAA98283; Thu, 24 Jan 2002 09:21:21 -0600 (CST) Received: from slobber.americas.sgi.com by slobber.americas.sgi.com (SGI-8.9.3/SGI-client-1.7) via ESMTP id JAA75494; Thu, 24 Jan 2002 09:21:21 -0600 (CST) Message-Id: <200201241521.JAA75494@slobber.americas.sgi.com> To: Stephen Lord cc: Keith Owens , linux-xfs@oss.sgi.com Subject: Re: TAKE - remove use of -funsigned-char from xfs Date: Thu, 24 Jan 2002 09:21:20 -0600 From: Dean Roehrich Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 450 Lines: 13 >From: Stephen Lord >>fs/xfs_dmapi/Makefile still uses -funsigned-char. Deliberate? Also all >>the fs/xfs*/Makefile.in files need to be changed to keep them in sync. >> >Woops, no, I was building dmapi, but I did not spot that one. I will take a >look at removing it too, although it looks like the whole header >file cleanup job still needs to happen in the dmapi code. Sorry, what is the "whole header file cleanup job"? Dean From owner-linux-xfs@oss.sgi.com Thu Jan 24 08:23:57 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0OGNvN11277 for linux-xfs-outgoing; Thu, 24 Jan 2002 08:23:57 -0800 Received: from minnie.omroep.nl (minnie.omroep.nl [145.58.30.4]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0OGNqP11248 for ; Thu, 24 Jan 2002 08:23:52 -0800 Received: (from smap@localhost) by minnie.omroep.nl (SGI-8.9.3/8.9.3) id QAA96873 for ; Thu, 24 Jan 2002 16:23:38 +0100 (CET) Received: from nos-smtp.nos.nl (145.58.12.125 "HELO nos-smtp.nos.nl") by minnie.omroep.nl with SMTP (smap v3.0 nederlandse publieke omroep) id xma1300864; Thu, 24 Jan 02 16:23:36 +0100 Received: FROM exchange.nos.nl BY nos-smtp.nos.nl ; Thu Jan 24 16:37:59 2002 +0100 Received: by EXCHANGE with Internet Mail Service (5.5.2650.21) id ; Thu, 24 Jan 2002 16:24:26 +0100 Message-ID: <35F87783B600D411A1430060943F469A589754@EXCHANGE> From: Matthijs van der Klip To: "'Eric Sandeen'" , Simon Matter Cc: linux-xfs Subject: RE: New Kernel RPMs Date: Thu, 24 Jan 2002 16:24:25 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Disposition: inline Content-Type: text/plain Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 575 Lines: 23 > Hm, still 2.4.9! The update might not be too difficult, I'll take > a look sometime soon. Hi Eric, Just to let you know: I just grabbed the xfs patches (20000 and up) from the 2.4.9-12 SRPM and put them in the 2.4.9-21 source. I haven't tested it yet, but I have successfully built 2.4.9-21SGI_XFS_1.0.2 RPM's. So it seems very easy indeed. I need 2.4.9-21 badly as it fixes a lot of troubles I have been having with IBM machines and their RAID controllers. Regards, Matthijs van der Klip Dutch Public Broadcasting Organisation [[HTML alternate version deleted]] From owner-linux-xfs@oss.sgi.com Thu Jan 24 08:25:25 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0OGPPY11501 for linux-xfs-outgoing; Thu, 24 Jan 2002 08:25:25 -0800 Received: from rj.sgi.com (rj.SGI.COM [204.94.215.100]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0OGPLP11467 for ; Thu, 24 Jan 2002 08:25:21 -0800 Received: from relay1.corp.sgi.com (spindle.corp.sgi.com [198.29.75.13]) by rj.sgi.com (8.11.4/8.11.4/linux-outbound_gateway-1.1) with ESMTP id g0OFPEY27338 for ; Thu, 24 Jan 2002 07:25:14 -0800 Received: from chuckle.americas.sgi.com (sandeen@chuckle.americas.sgi.com [128.162.211.44]) by relay1.corp.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) via ESMTP id HAA59492; Thu, 24 Jan 2002 07:24:42 -0800 (PST) Date: Thu, 24 Jan 2002 09:24:42 -0600 (CST) From: Eric Sandeen X-X-Sender: To: Simon Matter cc: linux-xfs Subject: Re: New Kernel RPMs In-Reply-To: <3C5025C2.BE55815A@ch.sauter-bc.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 966 Lines: 29 On Thu, 24 Jan 2002, Simon Matter wrote: > Eric Sandeen schrieb: > > > > Hm, still 2.4.9! The update might not be too difficult, I'll take > > It's more like 2.4.9+++++++ ;-) > I'm currently compiling the 7.1 RPM but got some problems. Some patches > like nfs-lockd are now included in stock RH and I removed them from the > spec. That sounds correct. > I have also modified the .config files. > Now while compiling I got an error related to kdb. It was complaining > that it tried to apply a patch which was already applied. I have removed > the kdb patch an try (and error) again. One thing I saw is that RedHat > has enabled to build debug kernel while you disabled this in the spec. > Was it causing problems? Red Hat has something called "ikd" (integrated kernel debugger) which is a superset of what's in KDB, I think... although ikd used to have much older kdb code. IIRC, I took the "ikd" patch out of the previous RPMs, and just applied kdb. -Eric From owner-linux-xfs@oss.sgi.com Thu Jan 24 08:28:21 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0OGSLw11794 for linux-xfs-outgoing; Thu, 24 Jan 2002 08:28:21 -0800 Received: from eclectic.kluge.net (IDENT:pNgXJW4xO7jNWHrjwV8wr/gWm8NB5eqU@dsl092-071-242.bos1.dsl.speakeasy.net [66.92.71.242]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0OGSIP11764 for ; Thu, 24 Jan 2002 08:28:18 -0800 Received: (from felicity@localhost) by eclectic.kluge.net (8.11.6/8.11.6) id g0OFSFv11117 for linux-xfs@oss.sgi.com; Thu, 24 Jan 2002 10:28:15 -0500 Date: Thu, 24 Jan 2002 10:28:14 -0500 From: Theo Van Dinter To: linux-xfs Subject: Re: New Kernel RPMs Message-ID: <20020124102814.K10233@kluge.net> References: <35F87783B600D411A1430060943F469A589754@EXCHANGE> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <35F87783B600D411A1430060943F469A589754@EXCHANGE>; from matthijs.van.der.klip@nos.nl on Thu, Jan 24, 2002 at 04:24:25PM +0100 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 828 Lines: 20 On Thu, Jan 24, 2002 at 04:24:25PM +0100, Matthijs van der Klip wrote: > Just to let you know: I just grabbed the xfs patches (20000 and up) from the > 2.4.9-12 SRPM and put them in the 2.4.9-21 source. I haven't tested it yet, > but > I have successfully built 2.4.9-21SGI_XFS_1.0.2 RPM's. So it seems very easy > indeed. If we're talking about making a new XFS/RH kernel RPM, can we also look at upgrading the LVM code from 1.0.1-rc4 to 1.0.1 or 1.0.2 (released today -- 1/24/2002 ...) There've been a decent number of bug fixes that would be nice to get fixed. :) -- Randomly Generated Tagline: I'm serious about thinking through all the possibilities before we settle on anything. All things have the advantages of their disadvantages, and vice versa. -- Larry Wall in <199709032332.QAA21669@wall.org> From owner-linux-xfs@oss.sgi.com Thu Jan 24 08:29:24 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0OGTOF12010 for linux-xfs-outgoing; Thu, 24 Jan 2002 08:29:24 -0800 Received: from rj.sgi.com (rj.SGI.COM [204.94.215.100]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0OGTKP11984 for ; Thu, 24 Jan 2002 08:29:20 -0800 Received: from relay1.corp.sgi.com (spindle.corp.sgi.com [198.29.75.13]) by rj.sgi.com (8.11.4/8.11.4/linux-outbound_gateway-1.1) with ESMTP id g0OFTDY27714 for ; Thu, 24 Jan 2002 07:29:13 -0800 Received: from chuckle.americas.sgi.com (sandeen@chuckle.americas.sgi.com [128.162.211.44]) by relay1.corp.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) via ESMTP id HAA23487; Thu, 24 Jan 2002 07:28:42 -0800 (PST) Date: Thu, 24 Jan 2002 09:28:41 -0600 (CST) From: Eric Sandeen X-X-Sender: To: Matthijs van der Klip cc: Simon Matter , linux-xfs Subject: RE: New Kernel RPMs In-Reply-To: <35F87783B600D411A1430060943F469A589754@EXCHANGE> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 688 Lines: 27 Sounds great. Would you mind sending your updated spec? -Eric On Thu, 24 Jan 2002, Matthijs van der Klip wrote: > > Hm, still 2.4.9! The update might not be too difficult, I'll take > > a look sometime soon. > > Hi Eric, > > Just to let you know: I just grabbed the xfs patches (20000 and up) from the > 2.4.9-12 SRPM and put them in the 2.4.9-21 source. I haven't tested it yet, > but > I have successfully built 2.4.9-21SGI_XFS_1.0.2 RPM's. So it seems very easy > indeed. > > I need 2.4.9-21 badly as it fixes a lot of troubles I have been having with > IBM machines and their RAID controllers. > > > Regards, > > Matthijs van der Klip > Dutch Public Broadcasting Organisation > From owner-linux-xfs@oss.sgi.com Thu Jan 24 08:33:08 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0OGX8w12376 for linux-xfs-outgoing; Thu, 24 Jan 2002 08:33:08 -0800 Received: from deliverator.sgi.com (deliverator.sgi.com [204.94.214.10]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0OGX4P12348 for ; Thu, 24 Jan 2002 08:33:04 -0800 Received: from zeus-e8.americas.sgi.com (zeus-e8.americas.sgi.com [128.162.8.103]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id HAA13476 for ; Thu, 24 Jan 2002 07:28:39 -0800 (PST) mail_from (lord@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by zeus-e8.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id JAA130637; Thu, 24 Jan 2002 09:31:45 -0600 (CST) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id JAA05587; Thu, 24 Jan 2002 09:31:44 -0600 (CST) Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id g0OFUd614089; Thu, 24 Jan 2002 09:30:39 -0600 Subject: RE: New Kernel RPMs From: Steve Lord To: Matthijs van der Klip Cc: "'Eric Sandeen'" , Simon Matter , linux-xfs In-Reply-To: <35F87783B600D411A1430060943F469A589754@EXCHANGE> References: <35F87783B600D411A1430060943F469A589754@EXCHANGE> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/1.0.1 Date: 24 Jan 2002 09:30:38 -0600 Message-Id: <1011886238.23153.11.camel@jen.americas.sgi.com> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 954 Lines: 34 On Thu, 2002-01-24 at 09:24, Matthijs van der Klip wrote: > > Hm, still 2.4.9! The update might not be too difficult, I'll take > > a look sometime soon. > > Hi Eric, > > Just to let you know: I just grabbed the xfs patches (20000 and up) from the > 2.4.9-12 SRPM and put them in the 2.4.9-21 source. I haven't tested it yet, > but > I have successfully built 2.4.9-21SGI_XFS_1.0.2 RPM's. So it seems very easy > indeed. > > I need 2.4.9-21 badly as it fixes a lot of troubles I have been having with > IBM machines and their RAID controllers. > > > Regards, > > Matthijs van der Klip > Dutch Public Broadcasting Organisation > The tricky part with all of this is we probably should to fold in the appropriate xfs fixes from the cvs tree, there are a lot of them since these rpms were spun. Steve -- Steve Lord voice: +1-651-683-3511 Principal Engineer, Filesystem Software email: lord@sgi.com From owner-linux-xfs@oss.sgi.com Thu Jan 24 08:40:40 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0OGee114491 for linux-xfs-outgoing; Thu, 24 Jan 2002 08:40:40 -0800 Received: from pneumatic-tube.sgi.com (pneumatic-tube.sgi.com [204.94.214.22]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0OGeZP14466 for ; Thu, 24 Jan 2002 08:40:35 -0800 Received: from zeus-e8.americas.sgi.com (zeus-e8.americas.sgi.com [128.162.8.103]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id HAA09001 for ; Thu, 24 Jan 2002 07:41:28 -0800 (PST) mail_from (lord@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by zeus-e8.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id JAA130739; Thu, 24 Jan 2002 09:39:16 -0600 (CST) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id JAA69509; Thu, 24 Jan 2002 09:39:16 -0600 (CST) Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id g0OFcAS14105; Thu, 24 Jan 2002 09:38:10 -0600 Subject: Re: New Kernel RPMs From: Steve Lord To: Theo Van Dinter Cc: linux-xfs In-Reply-To: <20020124102814.K10233@kluge.net> References: <35F87783B600D411A1430060943F469A589754@EXCHANGE> <20020124102814.K10233@kluge.net> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/1.0.1 Date: 24 Jan 2002 09:38:10 -0600 Message-Id: <1011886690.23153.14.camel@jen.americas.sgi.com> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 1319 Lines: 34 On Thu, 2002-01-24 at 09:28, Theo Van Dinter wrote: > On Thu, Jan 24, 2002 at 04:24:25PM +0100, Matthijs van der Klip wrote: > > Just to let you know: I just grabbed the xfs patches (20000 and up) from the > > 2.4.9-12 SRPM and put them in the 2.4.9-21 source. I haven't tested it yet, > > but > > I have successfully built 2.4.9-21SGI_XFS_1.0.2 RPM's. So it seems very easy > > indeed. > > If we're talking about making a new XFS/RH kernel RPM, can we also look at > upgrading the LVM code from 1.0.1-rc4 to 1.0.1 or 1.0.2 (released today -- > 1/24/2002 ...) > > There've been a decent number of bug fixes that would be nice to get fixed. :) I really think a new lvm needs a lot of soak time before we spin it into a package. The 1.0.1 code has stack overflows with xfs, I have no idea about the new code at all, I thought it was going to be a 2.0 release, or is that something different. Steve > > -- > Randomly Generated Tagline: > I'm serious about thinking through all the possibilities before we > settle on anything. All things have the advantages of their > disadvantages, and vice versa. > -- Larry Wall in <199709032332.QAA21669@wall.org> -- Steve Lord voice: +1-651-683-3511 Principal Engineer, Filesystem Software email: lord@sgi.com From owner-linux-xfs@oss.sgi.com Thu Jan 24 08:48:17 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0OGmHm15061 for linux-xfs-outgoing; Thu, 24 Jan 2002 08:48:17 -0800 Received: from rj.sgi.com (rj.SGI.COM [204.94.215.100]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0OGmEP15035 for ; Thu, 24 Jan 2002 08:48:14 -0800 Received: from relay1.corp.sgi.com (spindle.corp.sgi.com [198.29.75.13]) by rj.sgi.com (8.11.4/8.11.4/linux-outbound_gateway-1.1) with ESMTP id g0OFm7Y29557 for ; Thu, 24 Jan 2002 07:48:07 -0800 Received: from chuckle.americas.sgi.com (sandeen@chuckle.americas.sgi.com [128.162.211.44]) by relay1.corp.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) via ESMTP id HAA88191; Thu, 24 Jan 2002 07:47:36 -0800 (PST) Date: Thu, 24 Jan 2002 09:47:35 -0600 (CST) From: Eric Sandeen X-X-Sender: To: Steve Lord cc: Theo Van Dinter , linux-xfs Subject: Re: New Kernel RPMs In-Reply-To: <1011886690.23153.14.camel@jen.americas.sgi.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 472 Lines: 15 On 24 Jan 2002, Steve Lord wrote: > I really think a new lvm needs a lot of soak time before we spin it > into a package. The 1.0.1 code has stack overflows with xfs, I have > no idea about the new code at all, I thought it was going to be a 2.0 > release, or is that something different. The new 1.0.2 LVM code does fix the stack overflow we saw (for 2.4.4+, anyway). LVM 2.0 is a complete rewrite, probably a while yet until it's released in any stable form. -Eric From owner-linux-xfs@oss.sgi.com Thu Jan 24 08:49:09 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0OGn9t15314 for linux-xfs-outgoing; Thu, 24 Jan 2002 08:49:09 -0800 Received: from yog-sothoth.sgi.com (eugate.sgi.com [192.48.160.10]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0OGn3P15249 for ; Thu, 24 Jan 2002 08:49:03 -0800 Received: from zeus-e8.americas.sgi.com (zeus-e8.americas.sgi.com [128.162.8.103]) by yog-sothoth.sgi.com (980305.SGI.8.8.8-aspam-6.2/980304.SGI-aspam-europe) via ESMTP id QAA662265 for ; Thu, 24 Jan 2002 16:47:48 +0100 (CET) mail_from (lord@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by zeus-e8.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id JAA130730; Thu, 24 Jan 2002 09:47:33 -0600 (CST) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id JAA91747; Thu, 24 Jan 2002 09:47:33 -0600 (CST) Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id g0OFkRi14154; Thu, 24 Jan 2002 09:46:27 -0600 Subject: RE: New Kernel RPMs From: Steve Lord To: Matthijs van der Klip Cc: "'Eric Sandeen'" , Simon Matter , linux-xfs In-Reply-To: <35F87783B600D411A1430060943F469A589756@EXCHANGE> References: <35F87783B600D411A1430060943F469A589756@EXCHANGE> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/1.0.1 Date: 24 Jan 2002 09:46:27 -0600 Message-Id: <1011887187.23167.24.camel@jen.americas.sgi.com> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 603 Lines: 22 On Thu, 2002-01-24 at 09:44, Matthijs van der Klip wrote: > > The tricky part with all of this is we probably should to fold in the > > appropriate xfs fixes from the cvs tree, there are a lot of them since > > these rpms were spun. > > But then it wouldn't be an 'official' release (1.0.2) anymore, would it? But then why would we bother with the redhat update at all? Same argument applies in my mind. Steve > > > Regards, > > Matthijs van der Klip -- Steve Lord voice: +1-651-683-3511 Principal Engineer, Filesystem Software email: lord@sgi.com From owner-linux-xfs@oss.sgi.com Thu Jan 24 08:49:11 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0OGnBf15339 for linux-xfs-outgoing; Thu, 24 Jan 2002 08:49:11 -0800 Received: from sgi.com (sgi-too.SGI.COM [204.94.211.39]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0OGn4P15257 for ; Thu, 24 Jan 2002 08:49:04 -0800 Received: from minnie.omroep.nl (minnie.omroep.nl [145.58.30.4]) by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id HAA08014 for ; Thu, 24 Jan 2002 07:49:01 -0800 (PST) mail_from (matthijs.van.der.klip@nos.nl) Received: (from smap@localhost) by minnie.omroep.nl (SGI-8.9.3/8.9.3) id QAA02850 for ; Thu, 24 Jan 2002 16:43:47 +0100 (CET) Received: from nos-smtp.nos.nl (145.58.12.125 "HELO nos-smtp.nos.nl") by minnie.omroep.nl with SMTP (smap v3.0 nederlandse publieke omroep) id xma1294685; Thu, 24 Jan 02 16:43:45 +0100 Received: FROM exchange.nos.nl BY nos-smtp.nos.nl ; Thu Jan 24 16:58:23 2002 +0100 Received: by EXCHANGE with Internet Mail Service (5.5.2650.21) id ; Thu, 24 Jan 2002 16:44:50 +0100 Message-ID: <35F87783B600D411A1430060943F469A589756@EXCHANGE> From: Matthijs van der Klip To: "'Steve Lord'" , Matthijs van der Klip Cc: "'Eric Sandeen'" , Simon Matter , linux-xfs Subject: RE: New Kernel RPMs Date: Thu, 24 Jan 2002 16:44:40 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Disposition: inline Content-Type: text/plain Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 315 Lines: 14 > The tricky part with all of this is we probably should to fold in the > appropriate xfs fixes from the cvs tree, there are a lot of them since > these rpms were spun. But then it wouldn't be an 'official' release (1.0.2) anymore, would it? Regards, Matthijs van der Klip [[HTML alternate version deleted]] From owner-linux-xfs@oss.sgi.com Thu Jan 24 09:02:05 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0OH25316589 for linux-xfs-outgoing; Thu, 24 Jan 2002 09:02:05 -0800 Received: from smtpzilla1.xs4all.nl (smtpzilla1.xs4all.nl [194.109.127.137]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0OH20P16548 for ; Thu, 24 Jan 2002 09:02:00 -0800 Received: from auto-nb1.xs4all.nl (213-84-100-130.adsl.xs4all.nl [213.84.100.130]) by smtpzilla1.xs4all.nl (8.12.0/8.12.0) with ESMTP id g0OG1jcl047175; Thu, 24 Jan 2002 17:01:45 +0100 (CET) Message-Id: <4.3.2.7.2.20020124165641.03b93300@pop.xs4all.nl> X-Sender: knuffie@pop.xs4all.nl X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 24 Jan 2002 17:00:30 +0100 To: Matthijs van der Klip , "'Steve Lord'" , Matthijs van der Klip From: Seth Mos Subject: RE: New Kernel RPMs Cc: "'Eric Sandeen'" , Simon Matter , linux-xfs In-Reply-To: <35F87783B600D411A1430060943F469A589756@EXCHANGE> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 785 Lines: 24 At 16:44 24-1-2002 +0100, Matthijs van der Klip wrote: > > The tricky part with all of this is we probably should to fold in the > > appropriate xfs fixes from the cvs tree, there are a lot of them since > > these rpms were spun. > >But then it wouldn't be an 'official' release (1.0.2) anymore, would it? Then why not call it 1.0.3 The only part that needs to be exchanged would be the kernel on the install disk and may-be xfsprogs. The installer uses 2.4.7 anyway so the installer would not be lost. Although wrapping all this up would still mean a significant amount of time. By the way, what is the exact problem this kernel is supposed to fix? Cheers -- Seth Every program has two purposes one for which it was written and another for which it wasn't I use the last kind. From owner-linux-xfs@oss.sgi.com Thu Jan 24 09:02:03 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0OH23616574 for linux-xfs-outgoing; Thu, 24 Jan 2002 09:02:03 -0800 Received: from minnie.omroep.nl (minnie.omroep.nl [145.58.30.4]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0OH1mP16489 for ; Thu, 24 Jan 2002 09:01:48 -0800 Received: (from smap@localhost) by minnie.omroep.nl (SGI-8.9.3/8.9.3) id RAA11697 for ; Thu, 24 Jan 2002 17:01:39 +0100 (CET) Received: from nos-smtp.nos.nl (145.58.12.125 "HELO nos-smtp.nos.nl") by minnie.omroep.nl with SMTP (smap v3.0 nederlandse publieke omroep) id xma1306634; Thu, 24 Jan 02 17:01:36 +0100 Received: FROM exchange.nos.nl BY nos-smtp.nos.nl ; Thu Jan 24 17:16:15 2002 +0100 Received: by EXCHANGE with Internet Mail Service (5.5.2650.21) id ; Thu, 24 Jan 2002 17:02:41 +0100 Message-ID: <35F87783B600D411A1430060943F469A589757@EXCHANGE> From: Matthijs van der Klip To: "'Steve Lord'" , Matthijs van der Klip Cc: "'Eric Sandeen'" , Simon Matter , linux-xfs Subject: RE: New Kernel RPMs Date: Thu, 24 Jan 2002 17:02:33 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Disposition: inline Content-Type: text/plain Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 510 Lines: 18 >> But then it wouldn't be an 'official' release (1.0.2) anymore, would it? > > But then why would we bother with the redhat update at all? Same > argument applies in my mind. OK, you're right, but what I was trying to say is that I (and most others) have been using the code from rel 1.0.2 without any troubles, so I prefer to use that 'proven' code. From _your_ point of view though I can imagine you would like to include the fixes. Regards, Matthijs van der Klip [[HTML alternate version deleted]] From owner-linux-xfs@oss.sgi.com Thu Jan 24 09:09:41 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0OH9fk17271 for linux-xfs-outgoing; Thu, 24 Jan 2002 09:09:41 -0800 Received: from deliverator.sgi.com (deliverator.sgi.com [204.94.214.10]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0OH9ZP17249 for ; Thu, 24 Jan 2002 09:09:35 -0800 Received: from zeus-e8.americas.sgi.com (zeus-e8.americas.sgi.com [128.162.8.103]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id IAA16190 for ; Thu, 24 Jan 2002 08:05:11 -0800 (PST) mail_from (lord@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by zeus-e8.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id KAA131265; Thu, 24 Jan 2002 10:08:16 -0600 (CST) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id KAA97845; Thu, 24 Jan 2002 10:08:16 -0600 (CST) Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id g0OG7Ah14227; Thu, 24 Jan 2002 10:07:10 -0600 Subject: RE: New Kernel RPMs From: Steve Lord To: Seth Mos Cc: Matthijs van der Klip , "'Eric Sandeen'" , Simon Matter , linux-xfs In-Reply-To: <4.3.2.7.2.20020124165641.03b93300@pop.xs4all.nl> References: <4.3.2.7.2.20020124165641.03b93300@pop.xs4all.nl> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/1.0.1 Date: 24 Jan 2002 10:07:10 -0600 Message-Id: <1011888430.23153.33.camel@jen.americas.sgi.com> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 334 Lines: 16 On Thu, 2002-01-24 at 10:00, Seth Mos wrote: > > By the way, what is the exact problem this kernel is supposed to fix? https://www.redhat.com/support/errata/RHSA-2002-007.html Steve -- Steve Lord voice: +1-651-683-3511 Principal Engineer, Filesystem Software email: lord@sgi.com From owner-linux-xfs@oss.sgi.com Thu Jan 24 09:43:39 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0OHhdO19519 for linux-xfs-outgoing; Thu, 24 Jan 2002 09:43:39 -0800 Received: from minnie.omroep.nl (minnie.omroep.nl [145.58.30.4]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0OHhXP19495 for ; Thu, 24 Jan 2002 09:43:33 -0800 Received: (from smap@localhost) by minnie.omroep.nl (SGI-8.9.3/8.9.3) id RAA17141 for ; Thu, 24 Jan 2002 17:43:24 +0100 (CET) Received: from nos-smtp.nos.nl (145.58.12.125 "HELO nos-smtp.nos.nl") by minnie.omroep.nl with SMTP (smap v3.0 nederlandse publieke omroep) id xma1310129; Thu, 24 Jan 02 17:43:19 +0100 Received: FROM exchange.nos.nl BY nos-smtp.nos.nl ; Thu Jan 24 17:57:57 2002 +0100 Received: by EXCHANGE with Internet Mail Service (5.5.2650.21) id ; Thu, 24 Jan 2002 17:44:24 +0100 Message-ID: <35F87783B600D411A1430060943F469A589758@EXCHANGE> From: Matthijs van der Klip To: Matthijs van der Klip , "'Eric Sandeen'" , Simon Matter Cc: linux-xfs Subject: RE: New Kernel RPMs Date: Thu, 24 Jan 2002 17:44:21 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Disposition: inline Content-Type: text/plain Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 496 Lines: 23 > I need 2.4.9-21 badly as it fixes a lot of troubles I have been having with > IBM machines and their RAID controllers. Not tested extensively, but the kernel boots and runs: [matthijs@daphne ~]$ uname -a Linux daphne 2.4.9-21SGI_XFS_1.0.2smp #1 SMP Thu Jan 24 16:03:30 CET 2002 i686 unknown This is good news for me as 2.4.9-12 refuses to boot on this same (IBM) machine... Best regards, Matthijs van der Klip Dutch Public Broadcasting Organisation [[HTML alternate version deleted]] From owner-linux-xfs@oss.sgi.com Thu Jan 24 09:58:26 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0OHwQj21008 for linux-xfs-outgoing; Thu, 24 Jan 2002 09:58:26 -0800 Received: from pneumatic-tube.sgi.com (pneumatic-tube.sgi.com [204.94.214.22]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0OHvuP20929 for ; Thu, 24 Jan 2002 09:57:56 -0800 Received: from zeus-e8.americas.sgi.com (zeus-e8.americas.sgi.com [128.162.8.103]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id IAA02748 for ; Thu, 24 Jan 2002 08:58:49 -0800 (PST) mail_from (lord@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by zeus-e8.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id KAA131735 for ; Thu, 24 Jan 2002 10:56:37 -0600 (CST) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id KAA12724 for ; Thu, 24 Jan 2002 10:56:37 -0600 (CST) From: Steve Lord Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id g0OGtVJ14339; Thu, 24 Jan 2002 10:55:31 -0600 Message-Id: <200201241655.g0OGtVJ14339@jen.americas.sgi.com> Date: Thu, 24 Jan 2002 10:55:31 -0600 Subject: TAKE - merge up to 2.5.3-pre4 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 8425 Lines: 235 Following Al Viro through every filesystem in Linux...... Date: Thu Jan 24 08:52:40 PST 2002 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:110143a linux/drivers/video/neofb.c - 1.1 linux/net/ipv6/netfilter/ip6_queue.c - 1.1 linux/net/ipv4/netfilter/ipt_esp.c - 1.1 linux/net/ipv4/netfilter/ipt_ah.c - 1.1 linux/net/ipv4/netfilter/ipt_ULOG.c - 1.1 linux/include/linux/netfilter_ipv4/ipt_esp.h - 1.1 linux/include/linux/netfilter_ipv4/ipt_ah.h - 1.1 linux/include/linux/netfilter_ipv4/ipt_ULOG.h - 1.1 linux/include/asm-sparc64/pil.h - 1.1 linux/drivers/video/neofb.h - 1.1 linux/net/netsyms.c - 1.41 linux/net/netlink/af_netlink.c - 1.17 linux/net/irda/af_irda.c - 1.31 linux/net/ipv6/ndisc.c - 1.17 linux/net/core/dev.c - 1.50 linux/kernel/time.c - 1.7 linux/kernel/ksyms.c - 1.129 linux/init/main.c - 1.71 linux/include/linux/time.h - 1.5 linux/include/linux/sysv_fs_i.h - 1.5 linux/include/linux/sysv_fs.h - 1.13 linux/include/linux/rtnetlink.h - 1.11 linux/include/linux/pci.h - 1.54 linux/include/linux/netlink.h - 1.8 linux/include/linux/ncp_fs_i.h - 1.5 linux/include/linux/ncp_fs.h - 1.12 linux/include/linux/minix_fs_i.h - 1.3 linux/include/linux/minix_fs.h - 1.11 linux/include/linux/init.h - 1.15 linux/include/linux/fs.h - 1.144 linux/include/linux/fb.h - 1.21 linux/include/asm-sparc64/irq.h - 1.10 linux/include/asm-sparc64/ide.h - 1.11 linux/fs/sysv/symlink.c - 1.8 linux/fs/sysv/inode.c - 1.28 linux/fs/sysv/ialloc.c - 1.12 linux/fs/sysv/dir.c - 1.13 linux/fs/super.c - 1.74 linux/fs/nfsd/nfssvc.c - 1.17 linux/fs/ncpfs/inode.c - 1.24 linux/fs/minix/inode.c - 1.28 linux/fs/minix/bitmap.c - 1.14 linux/fs/coda/inode.c - 1.19 linux/fs/Config.in - 1.75 linux/drivers/zorro/zorro.c - 1.9 linux/drivers/video/virgefb.c - 1.15 linux/drivers/video/vfb.c - 1.13 linux/drivers/video/valkyriefb.c - 1.15 linux/drivers/video/tgafb.c - 1.18 linux/drivers/video/skeletonfb.c - 1.9 linux/drivers/video/sgivwfb.c - 1.14 linux/drivers/video/retz3fb.c - 1.15 linux/drivers/video/q40fb.c - 1.11 linux/drivers/video/platinumfb.c - 1.14 linux/drivers/video/offb.c - 1.19 linux/drivers/video/macfb.c - 1.13 linux/drivers/video/imsttfb.c - 1.20 linux/drivers/video/igafb.c - 1.17 linux/drivers/video/hpfb.c - 1.12 linux/drivers/video/g364fb.c - 1.11 linux/drivers/video/fm2fb.c - 1.12 linux/drivers/video/fbmem.c - 1.44 linux/drivers/video/dnfb.c - 1.13 linux/drivers/video/cyberfb.c - 1.15 linux/drivers/video/controlfb.c - 1.20 linux/drivers/video/clgenfb.c - 1.24 linux/drivers/video/chipsfb.c - 1.16 linux/drivers/video/atafb.c - 1.13 linux/drivers/video/amifb.c - 1.21 linux/drivers/video/acornfb.c - 1.23 linux/drivers/video/S3triofb.c - 1.11 linux/drivers/video/Makefile - 1.35 linux/drivers/video/Config.in - 1.31 linux/drivers/usb/audio.c - 1.38 linux/drivers/scsi/st_options.h - 1.7 linux/drivers/scsi/st.h - 1.13 linux/drivers/scsi/st.c - 1.39 linux/drivers/scsi/README.st - 1.8 linux/drivers/sbus/sbus.c - 1.14 linux/drivers/pci/pci.c - 1.49 linux/drivers/nubus/nubus.c - 1.8 linux/drivers/dio/dio.c - 1.5 linux/arch/sparc64/vmlinux.lds - 1.11 linux/arch/sparc64/mm/ultra.S - 1.24 linux/arch/sparc64/kernel/ttable.S - 1.12 linux/arch/sparc64/kernel/time.c - 1.17 linux/arch/sparc64/kernel/smp.c - 1.36 linux/arch/sparc64/kernel/process.c - 1.28 linux/arch/sparc64/defconfig - 1.58 linux/arch/sparc/vmlinux.lds - 1.10 linux/arch/sparc/kernel/time.c - 1.15 linux/arch/sparc/kernel/process.c - 1.25 linux/arch/sparc/kernel/pcic.c - 1.17 linux/arch/ppc/vmlinux.lds - 1.12 linux/arch/ppc/kernel/time.c - 1.17 linux/arch/ppc/kernel/setup.c - 1.40 linux/arch/m68k/vmlinux.lds - 1.11 linux/arch/i386/vmlinux.lds - 1.14 linux/arch/i386/kernel/time.c - 1.19 linux/arch/i386/kernel/mca.c - 1.12 linux/arch/arm/kernel/ecard.c - 1.16 linux/arch/alpha/kernel/time.c - 1.21 linux/Makefile - 1.178 linux/Documentation/Configure.help - 1.128 linux/drivers/video/vga16fb.c - 1.14 linux/drivers/sound/cmpci.c - 1.31 linux/drivers/tc/tc.c - 1.7 linux/drivers/pnp/isapnp.c - 1.24 linux/arch/arm/vmlinux-armv.lds.in - 1.19 linux/arch/arm/vmlinux-armo.lds.in - 1.17 linux/arch/sparc64/kernel/pci_sabre.c - 1.28 linux/arch/sparc64/kernel/pci_psycho.c - 1.25 linux/arch/sh/vmlinux.lds.S - 1.13 linux/drivers/pcmcia/ds.c - 1.20 linux/arch/m68k/vmlinux-sun3.lds - 1.8 linux/fs/udf/ialloc.c - 1.13 linux/fs/udf/inode.c - 1.28 linux/include/linux/udf_fs_i.h - 1.6 linux/fs/udf/super.c - 1.24 linux/fs/udf/udf_i.h - 1.6 linux/drivers/video/tdfxfb.c - 1.17 linux/drivers/video/aty128fb.c - 1.24 linux/arch/sparc64/kernel/sbus.c - 1.15 linux/drivers/usb/scanner.c - 1.28 linux/drivers/usb/usbmouse.c - 1.15 linux/drivers/usb/usbkbd.c - 1.21 linux/drivers/usb/devio.c - 1.25 linux/drivers/usb/inode.c - 1.19 linux/include/asm-sparc/ide.h - 1.8 linux/drivers/usb/usb-uhci.c - 1.36 linux/drivers/usb/scanner.h - 1.21 linux/drivers/video/dn_cfb8.c - 1.8 linux/drivers/video/dn_cfb4.c - 1.7 linux/drivers/net/irda/nsc-ircc.c - 1.19 linux/arch/ia64/vmlinux.lds.S - 1.8 linux/arch/ia64/kernel/time.c - 1.12 linux/drivers/video/sun3fb.c - 1.8 linux/net/bridge/br_fdb.c - 1.4 linux/arch/mips64/ld.script.elf64 - 1.5 linux/drivers/usb/wacom.c - 1.15 linux/drivers/usb/pegasus.c - 1.25 linux/drivers/video/hgafb.c - 1.13 linux/drivers/usb/dsbr100.c - 1.13 linux/net/ipv4/netfilter/iptable_mangle.c - 1.8 linux/net/ipv4/netfilter/iptable_filter.c - 1.5 linux/net/ipv4/netfilter/ipt_REDIRECT.c - 1.6 linux/net/ipv4/netfilter/ipt_LOG.c - 1.9 linux/net/ipv4/netfilter/ipfwadm_core.c - 1.9 linux/net/ipv4/netfilter/ipchains_core.c - 1.9 linux/net/ipv4/netfilter/ip_tables.c - 1.13 linux/net/ipv4/netfilter/ip_nat_rule.c - 1.5 linux/net/ipv4/netfilter/ip_fw_compat_masq.c - 1.7 linux/net/ipv4/netfilter/Makefile - 1.10 linux/net/ipv4/netfilter/Config.in - 1.7 linux/include/linux/netfilter_ipv4/ip_tables.h - 1.7 linux/arch/s390/vmlinux.lds - 1.4 linux/arch/s390/kernel/time.c - 1.5 linux/net/ipv6/netfilter/ip6table_filter.c - 1.4 linux/net/ipv6/netfilter/ip6t_MARK.c - 1.4 linux/net/ipv6/netfilter/ip6_tables.c - 1.10 linux/net/ipv6/netfilter/Makefile - 1.9 linux/net/ipv6/netfilter/Config.in - 1.5 linux/include/linux/netfilter_ipv6/ip6_tables.h - 1.4 linux/drivers/video/hitfb.c - 1.6 linux/arch/alpha/vmlinux.lds.in - 1.7 linux/drivers/usb/microtek.h - 1.3 linux/drivers/usb/microtek.c - 1.15 linux/drivers/ieee1394/video1394.c - 1.15 linux/drivers/input/evdev.c - 1.8 linux/drivers/char/joystick/iforce.c - 1.8 linux/fs/minix/itree_v1.c - 1.3 linux/fs/minix/itree_v2.c - 1.3 linux/drivers/usb/pegasus.h - 1.8 linux/drivers/video/stifb.c - 1.3 linux/arch/parisc/vmlinux.lds - 1.3 linux/drivers/sound/ymfpci.c - 1.19 linux/arch/mips64/ld.script.elf32.S - 1.3 linux/fs/reiserfs/stree.c - 1.16 linux/fs/reiserfs/super.c - 1.13 linux/fs/reiserfs/tail_conversion.c - 1.10 linux/arch/sparc64/kernel/pci_schizo.c - 1.13 linux/fs/reiserfs/journal.c - 1.19 linux/fs/reiserfs/ioctl.c - 1.4 linux/fs/reiserfs/inode.c - 1.23 linux/fs/reiserfs/file.c - 1.6 linux/fs/reiserfs/buffer2.c - 1.8 linux/include/linux/reiserfs_fs.h - 1.17 linux/include/linux/reiserfs_fs_i.h - 1.5 linux/fs/reiserfs/bitmap.c - 1.11 linux/net/ipv6/netfilter/ip6table_mangle.c - 1.3 linux/arch/s390x/kernel/time.c - 1.4 linux/arch/cris/cris.ld - 1.7 linux/arch/s390x/vmlinux.lds - 1.4 linux/drivers/net/sungem.h - 1.6 linux/drivers/net/sungem.c - 1.14 linux/drivers/video/epson1355fb.c - 1.4 linux/drivers/video/maxinefb.c - 1.4 linux/drivers/video/pmag-ba-fb.c - 1.3 linux/drivers/video/pmagb-b-fb.c - 1.3 linux/drivers/net/irda/irda-usb.c - 1.12 linux/drivers/usb/catc.c - 1.7 linux/arch/mips/ld.script.in - 1.2 linux/fs/sysv/itree.c - 1.4 linux/fs/sysv/super.c - 1.8 linux/drivers/net/irda/ali-ircc.c - 1.6 linux/drivers/media/video/zr36067.c - 1.8 linux/drivers/video/pvr2fb.c - 1.4 linux/drivers/usb/CDCEther.c - 1.6 linux/drivers/usb/CDCEther.h - 1.3 linux/arch/s390x/vmlinux-shared.lds - 1.2 linux/arch/s390/vmlinux-shared.lds - 1.2 linux/drivers/video/tx3912fb.c - 1.2 linux/drivers/video/sstfb.c - 1.5 linux/drivers/video/radeonfb.c - 1.7 linux/fs/namespace.c - 1.12 linux/drivers/usb/hpusbscsi.h - 1.3 linux/drivers/usb/hpusbscsi.c - 1.5 linux/fs/sysv/ChangeLog - 1.4 linux/fs/driverfs/inode.c - 1.3 linux/kernel/device.c - 1.5 linux/include/linux/driverfs_fs.h - 1.2 linux/include/linux/device.h - 1.3 linux/drivers/usb/vicam.c - 1.4 linux/drivers/usb/vicam.h - 1.3 From owner-linux-xfs@oss.sgi.com Thu Jan 24 09:58:48 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0OHwmC21094 for linux-xfs-outgoing; Thu, 24 Jan 2002 09:58:48 -0800 Received: from relay.xlink.net (relay.xlink.net [193.141.40.4]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0OHs2P20469 for ; Thu, 24 Jan 2002 09:54:02 -0800 Received: from lizard.webland.de (lizard.webland.de [194.122.76.201]) by relay.xlink.net (8.9.3/8.8.7) with ESMTP id RAA26112; Thu, 24 Jan 2002 17:53:50 +0100 (MET) Received: (from uucp@localhost) by lizard.webland.de (8.8.8/8.8.7) id RAA21025; Thu, 24 Jan 2002 17:53:49 +0100 (MET) >Received: from mobile.sauter-bc.com (unknown [10.1.6.21]) by basel1.sauter-bc.com (Postfix) with ESMTP id 1F56857306; Thu, 24 Jan 2002 17:51:09 +0100 (CET) Received: from ch.sauter-bc.com (support.cad.sba [10.1.200.117]) by mobile.sauter-bc.com (Postfix) with ESMTP id CF49925835; Thu, 24 Jan 2002 17:51:08 +0100 (CET) Message-ID: <3C503B7C.DB0ECCDC@ch.sauter-bc.com> Date: Thu, 24 Jan 2002 17:51:08 +0100 From: Simon Matter Organization: Sauter AG, Basel X-Mailer: Mozilla 4.77 [de] (X11; U; Linux 2.2.19-6.2.12 i686) X-Accept-Language: de-CH, en MIME-Version: 1.0 To: Eric Sandeen Cc: Matthijs van der Klip , linux-xfs Subject: Re: New Kernel RPMs References: Content-Type: multipart/mixed; boundary="------------64A01D39608411EAE632E459" Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 185505 Lines: 2623 Dies ist eine mehrteilige Nachricht im MIME-Format. --------------64A01D39608411EAE632E459 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Eric Sandeen schrieb: > > Sounds great. Would you mind sending your updated spec? Okay, the 7.1 seems to need few more changes. This is what I'm currently building. I hope it will end up in something bootable. -Simon [root@monster SPECS]# diff kernel-2.4.9-21-RH-xfs.spec kernel-2.4.spec 10c10 < %define builddebug 0 --- > %define builddebug 1 14d13 < %define extra_release SGI_XFS_1.0.2 169c168 < Release: %{release}%{?debuglevel_1:.dbg}%{extra_release} --- > Release: %{release}%{?debuglevel_1:.dbg} 179,182d177 < Vendor: SGI < Packager: Eric Sandeen < Distribution: SGI XFS < Url: http://oss.sgi.com/projects/xfs 578,589c573 < # SGI XFS Filesystem < Patch20000: linux-2.4.9-RH7.2-xfs.patch.bz2 < Patch20001: linux-2.4.9-RH7.2-xfs-lvm.patch.bz2 < Patch20002: linux-2.4.9-RH7.2-xfs-pagecache.patch.bz2 < Patch20003: linux-2.4.9-RH7.2-xfs-no-intermezzo.patch.bz2 < Patch20004: kdb-v1.9-2.4.9-13.bz2 < < # Fix silliness in bcm driver, exposed by xfs for some unknown reason < Patch20005: linux-2.4.9-bcm-bzero.patch < < # misc nfsd fixes from neil brown < Patch20006: linux-2.4.9-nb-nfsd.patch --- > 1318,1341d1301 < # Finally... XFS < # No lvm changes here < %patch20000 -p1 < < # Bring lvm up to 1.0.1rc4 w/ xfs hooks < %patch20001 -p1 < < # Fix up xfs if tux futzed with the pagecache < %if %{tux} < %patch20002 -p1 < %endif < < # intermezzo < %patch20003 -p1 < < #kdb < %patch20004 -p1 < < #bcm bzero problems < %patch20005 -p1 < < #misc nfsd fixes < %patch20006 -p0 < 1672,1675c1632,1635 < #AddPatches debug < #DependKernel i686 debug < #SaveHeaders debug i686 < #RemovePatches debug --- > AddPatches debug > DependKernel i686 debug > SaveHeaders debug i686 > RemovePatches debug 2206,2208d2165 < %endif < %ifarch %{all_x86} < /usr/src/linux-%{KVERREL}/kdb > > -Eric > > On Thu, 24 Jan 2002, Matthijs van der Klip wrote: > > > > Hm, still 2.4.9! The update might not be too difficult, I'll take > > > a look sometime soon. > > > > Hi Eric, > > > > Just to let you know: I just grabbed the xfs patches (20000 and up) from the > > 2.4.9-12 SRPM and put them in the 2.4.9-21 source. I haven't tested it yet, > > but > > I have successfully built 2.4.9-21SGI_XFS_1.0.2 RPM's. So it seems very easy > > indeed. > > > > I need 2.4.9-21 badly as it fixes a lot of troubles I have been having with > > IBM machines and their RAID controllers. > > > > > > Regards, > > > > Matthijs van der Klip > > Dutch Public Broadcasting Organisation > > --------------64A01D39608411EAE632E459 Content-Type: application/octet-stream; name="kernel-2.4.9-21-RH-xfs.spec" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="kernel-2.4.9-21-RH-xfs.spec" U3VtbWFyeTogVGhlIExpbnV4IGtlcm5lbCAodGhlIGNvcmUgb2YgdGhlIExpbnV4IG9wZXJh dGluZyBzeXN0ZW0pCgojIFdoYXQgcGFydHMgZG8gd2Ugd2FudCB0byBidWlsZD8gIFdlIG11 c3QgYnVpbGQgYXQgbGVhc3Qgb25lIGtlcm5lbC4KIyBUaGVzZSBhcmUgdGhlIGtlcm5lbHMg dGhhdCBhcmUgYnVpbHQgSUYgdGhlIGFyY2hpdGVjdHVyZSBhbGxvd3MgYW5kCiMgbm8gY29u dHJhcnkgLS13aXRoLy0td2l0aG91dCBhcmd1bWVudHMgYXJlIGdpdmVuIG9uIHRoZSBjb21t YW5kIGxpbmUuCiVkZWZpbmUgYnVpbGR1cCAxCiVkZWZpbmUgYnVpbGRzbXAgMQolZGVmaW5l IGJ1aWxkQk9PVCAxCiVkZWZpbmUgYnVpbGRlbnRlcnByaXNlIDEKJWRlZmluZSBidWlsZGRl YnVnIDAKJWRlZmluZSBidWlsZGplbnNlbiAwCiVkZWZpbmUgYnVpbGR0YXBlIDEKJWRlZmlu ZSBidWlsZEJPT1R0YXBlIDEKJWRlZmluZSBleHRyYV9yZWxlYXNlIFNHSV9YRlNfMS4wLjIK CiMgVmVyc2lvbnMgb2YgdmFyaW91cyBwYXJ0cwolZGVmaW5lIHJlbGVhc2UgMjEKJWRlZmlu ZSBzdWJsZXZlbCA5CiVkZWZpbmUga3ZlcnNpb24gMi40LiV7c3VibGV2ZWx9CiMgL3Vzci9z cmMvJXtrc2xua30gLT4gL3Vzci9zcmMvbGludXgtJXtLVkVSUkVMfQolZGVmaW5lIGtzbG5r IGxpbnV4LTIuNAojIGZpcnN0IFhGcmVlODYgdmVyIHRoYXQgcmVxdWlyZXMgdGhlIGRybSBp biB0aGlzIGtlcm5lbAolZGVmaW5lIGRybXZlciA0LjEuMAoKIyBncm91cHMgb2YgcmVsYXRl ZCBhcmNocwolZGVmaW5lIGFsbF9wcGMgcHBjIHBwY2lzZXJpZXMgcHBjcHNlcmllcyBwcGM2 NAojZGVmaW5lIGFsbF94ODYgaTM4NiBpNjg2CiVkZWZpbmUgYWxsX3g4NiBpNjg2IGkzODYg aTU4NiBhdGhsb24KCiMgZmVhdHVyZXMKJWRlZmluZSB0dXggMQojIG5vdGU6IGRvIG5vdCBl bmFibGUgYm90aCBkZWJ1Z2dpbmcgYW5kIGlrZCwgYXMgaWtkIGluY2x1ZGVzIGRlYnVnZ2lu ZyBhbHJlYWR5CiVkZWZpbmUgZGVidWdnaW5nIDAKJWRlZmluZSBpa2QgMAolZGVmaW5lIGli Y3MgMQoKIyBkaXNrIHNwYWNlIHJlcXVpcmVtZW50cyB0byB0ZXN0IGJlZm9yZSBidWlsZCwg aW4gbWVnYWJ5dGVzCiMgfjMwTSBwZXIga2VybmVsICsgfjEwME0gZm9yIHNvdXJjZSBwbHVz IGZ1ZGdlIGZhY3RvcgolZGVmaW5lIFJQTV9CVUlMRF9ST09UX3NwYWNlIDQwMAojIH4yMDBN IGZvciBidWlsZCBrZXJuZWwgc291cmNlIHRyZWUgcGx1cyBmdWRnZSBmYWN0b3IKJWRlZmlu ZSBSUE1fQlVJTERfRElSX3NwYWNlIDMwMAoKIyBkaXNhYmxlIGJ1aWxkIHJvb3Qgc3RyaXAg cG9saWN5CiVkZWZpbmUgX19zcGVjX2luc3RhbGxfcG9zdCAvdXNyL2xpYi9ycG0vYnJwLWNv bXByZXNzIHx8IDoKCiMgbm93IHdlIG5lZWQgYSAle19teXN0cmlwfSBtYWNybyB0byBhbGxv dyBjcm9zcy1jb21waWxpbmcKJXtleHBhbmQ6ICUlZGVmaW5lIGdvX2Zvcl8le190YXJnZXRf Y3B1fV8le19hcmNofSB5YWRkYX0KJXtleHBhbmQ6ICUlZGVmaW5lIF9teXN0cmlwICV7P2dv X2Zvcl9pYTY0X2kzODY6aWE2NC1saW51eC1zdHJpcH0leyE/Z29fZm9yX2lhNjRfaTM4Njpz dHJpcH19CgoKIyBPdmVycmlkZSBnZW5lcmljIGRlZmF1bHRzIHdpdGggcGVyLWFyY2ggZGVm YXVsdHMgKHdoaWNoIGNhbgojIHRoZW1zZWx2ZXMgYmUgb3ZlcnJpZGRlbiB3aXRoIC0td2l0 aC8tLXdpdGhvdXQpLiAgVGhlc2UgbXVzdAojIE9OTFkgYmUgIjAiLCBuZXZlciAiMSIKCiMg Rmlyc3QsIGFyY2hpdGVjdHVyZS1zcGVjaWZpYyBrZXJuZWxzIG9mZiBvbiBhbGwgb3RoZXIg YXJjaHMgKGlmbmFyY2gpCiVpZm5hcmNoIGk2ODYKJWRlZmluZSBidWlsZGVudGVycHJpc2Ug MAolZGVmaW5lIGJ1aWxkZGVidWcgMAolZW5kaWYKJWlmbmFyY2ggczM5MCBzMzkweAolZGVm aW5lIGJ1aWxkQk9PVHRhcGUgMAolZGVmaW5lIGJ1aWxkdGFwZSAwCiVlbmRpZgolaWZuYXJj aCBhbHBoYQojIGplbnNlbiBrZXJuZWwsIG9ubHkgZm9yIGFscGhhLiAgT2xkLCBicm9rZW4g YnJva2VuIGFscGhhLgolZGVmaW5lIGJ1aWxkamVuc2VuIDAKJWVuZGlmCiVpZm5hcmNoIGkz ODYgczM5MCBzMzkweCBhbHBoYSBwcGNwc2VyaWVzCiVkZWZpbmUgYnVpbGRCT09UIDAKJWVu ZGlmCgojIFNlY29uZCwgcGVyLWFyY2hpdGVjdHVyZSBleGNsdXNpb25zIChpZmFyY2gpCiVp ZmFyY2ggaTM4NgolZGVmaW5lIGJ1aWxkc21wIDAKJWVuZGlmCiVpZmFyY2ggaTU4NgolZGVm aW5lIGJ1aWxkdXAgMQolZW5kaWYKJWlmYXJjaCBzMzkwIHMzOTB4CiVkZWZpbmUgYnVpbGRz bXAgMAolZW5kaWYKJWlmYXJjaCBpYTY0CiVkZWZpbmUgYnVpbGRCT09UIDAKJWVuZGlmCiVp ZmFyY2ggcHBjCiVkZWZpbmUgYnVpbGRCT09UIDAKJWRlZmluZSBidWlsZHNtcCAwCiVlbmRp ZgoKCiMgYWxsb3cgLS13aXRoW291dF0gPGZlYXR1cmV8a2VybmVsPiBhdCBycG0gY29tbWFu ZCBsaW5lIGJ1aWxkCiMgZS5nLiAtLXdpdGggc21wIC0td2l0aG91dCBzbXAgLS13aXRob3V0 IEJPT1QgLS13aXRob3V0IGVudGVycHJpc2UgLS13aXRoIGliY3MKIyAtLXdpdGggb3ZlcnJp ZGVzIC0td2l0aG91dAolez9fd2l0aG91dF91cDogJXtleHBhbmQ6ICUlZGVmaW5lIGJ1aWxk dXAgMH19CiV7P193aXRob3V0X3NtcDogJXtleHBhbmQ6ICUlZGVmaW5lIGJ1aWxkc21wIDB9 fQolez9fd2l0aG91dF9CT09UOiAle2V4cGFuZDogJSVkZWZpbmUgYnVpbGRCT09UIDB9fQol ez9fd2l0aG91dF9lbnRlcnByaXNlOiAle2V4cGFuZDogJSVkZWZpbmUgYnVpbGRlbnRlcnBy aXNlIDB9fQolez9fd2l0aG91dF9kZWJ1ZzogJXtleHBhbmQ6ICUlZGVmaW5lIGJ1aWxkZGVi dWcgMH19CiV7P193aXRob3V0X2plbnNlbjogJXtleHBhbmQ6ICUlZGVmaW5lIGJ1aWxkamVu c2VuIDB9fQolez9fd2l0aG91dF90YXBlOiAle2V4cGFuZDogJSVkZWZpbmUgYnVpbGR0YXBl IDB9fQolez9fd2l0aG91dF9CT09UdGFwZTogJXtleHBhbmQ6ICUlZGVmaW5lIGJ1aWxkQk9P VHRhcGUgMH19CiV7P193aXRob3V0X3R1eDogJXtleHBhbmQ6ICUlZGVmaW5lIHR1eCAwfX0K JXs/X3dpdGhvdXRfZGVidWdnaW5nOiAle2V4cGFuZDogJSVkZWZpbmUgZGVidWdnaW5nIDB9 fQolez9fd2l0aG91dF9pa2Q6ICV7ZXhwYW5kOiAlJWRlZmluZSBpa2QgMH19CiV7P193aXRo b3V0X2liY3M6ICV7ZXhwYW5kOiAlJWRlZmluZSBpYmNzIDB9fQolez9fd2l0aF91cDogJXtl eHBhbmQ6ICUlZGVmaW5lIGJ1aWxkdXAgMX19CiV7P193aXRoX3NtcDogJXtleHBhbmQ6ICUl ZGVmaW5lIGJ1aWxkc21wIDF9fQolez9fd2l0aF9CT09UOiAle2V4cGFuZDogJSVkZWZpbmUg YnVpbGRCT09UIDF9fQolez9fd2l0aF9lbnRlcnByaXNlOiAle2V4cGFuZDogJSVkZWZpbmUg YnVpbGRlbnRlcnByaXNlIDF9fQolez9fd2l0aF9kZWJ1ZzogJXtleHBhbmQ6ICUlZGVmaW5l IGJ1aWxkZGVidWcgMX19CiV7P193aXRoX2plbnNlbjogJXtleHBhbmQ6ICUlZGVmaW5lIGJ1 aWxkamVuc2VuIDF9fQolez9fd2l0aF90YXBlOiAle2V4cGFuZDogJSVkZWZpbmUgYnVpbGR0 YXBlIDF9fQolez9fd2l0aF9CT09UdGFwZTogJXtleHBhbmQ6ICUlZGVmaW5lIGJ1aWxkQk9P VHRhcGUgMX19CiV7P193aXRoX3R1eDogJXtleHBhbmQ6ICUlZGVmaW5lIHR1eCAxfX0KJXs/ X3dpdGhfZGVidWdnaW5nOiAle2V4cGFuZDogJSVkZWZpbmUgZGVidWdnaW5nIDF9fQolez9f d2l0aF9pa2Q6ICV7ZXhwYW5kOiAlJWRlZmluZSBpa2QgMX19CiV7P193aXRoX2liY3M6ICV7 ZXhwYW5kOiAlJWRlZmluZSBpYmNzIDF9fQoKIyB3ZSBjYW4ndCB0ZXN0IHZhbHVlcyBpbmxp bmUsIG9ubHkgd2hldGhlciBhIG1hY3JvIGV4aXN0cwole2V4cGFuZDogJSVkZWZpbmUgYnVp bGR1cF8le2J1aWxkdXB9IHlhZGRhfQole2V4cGFuZDogJSVkZWZpbmUgYnVpbGRzbXBfJXti dWlsZHNtcH0geWFkZGF9CiV7ZXhwYW5kOiAlJWRlZmluZSBidWlsZEJPT1RfJXtidWlsZEJP T1R9IHlhZGRhfQole2V4cGFuZDogJSVkZWZpbmUgYnVpbGRlbnRlcnByaXNlXyV7YnVpbGRl bnRlcnByaXNlfSB5YWRkYX0KJXtleHBhbmQ6ICUlZGVmaW5lIGJ1aWxkZGVidWdfJXtidWls ZGRlYnVnfSB5YWRkYX0KJXtleHBhbmQ6ICUlZGVmaW5lIGJ1aWxkamVuc2VuXyV7YnVpbGRq ZW5zZW59IHlhZGRhfQole2V4cGFuZDogJSVkZWZpbmUgYnVpbGR0YXBlXyV7YnVpbGR0YXBl fSB5YWRkYX0KJXtleHBhbmQ6ICUlZGVmaW5lIGJ1aWxkQk9PVHRhcGVfJXtidWlsZEJPT1R0 YXBlfSB5YWRkYX0KJXtleHBhbmQ6ICUlZGVmaW5lIHR1eF8le3R1eH0geWFkZGF9CiV7ZXhw YW5kOiAlJWRlZmluZSBpa2RfJXtpa2R9IHlhZGRhfQole2V4cGFuZDogJSVkZWZpbmUgaWJj c18le2liY3N9IHlhZGRhfQole2V4cGFuZDogJSVkZWZpbmUgZGVidWdsZXZlbF8le2RlYnVn Z2luZ30geWFkZGF9Cgole2V4cGFuZDogJSVkZWZpbmUga2VybmVsX2NvbmZsaWN0cyAgcHBw IDw9IDIuMy4xNSwgZTJmc3Byb2dzIDw9IDEuMTgsIHBjbWNpYS1jcyA8PSAzLjEuMjAsIGlz ZG40ay11dGlscyA8PSAzLjAsIG1vdW50IDwgMi4xMHItNSwgbmZzLXV0aWxzIDwgMC4zLjEs IGNpcGUgPCAxLjQuNSwgdHV4IDwgMi4xLjEtMTAsIGt1ZHp1IDw9IDAuOTIsIGUyZnNwcm9n cyA8IDEuMjIgfQoKJWRlZmluZSBCT09UX2tlcm5lbF9wcmVyZXEgZmlsZXV0aWxzLCBtb2R1 dGlscyA+PSAyLjQuMTAKJWRlZmluZSBrZXJuZWxfcHJlcmVxICV7Qk9PVF9rZXJuZWxfcHJl cmVxfSwgaW5pdHNjcmlwdHMgPj0gNS44MywgbWtpbml0cmQgPj0gMy4yLjIKJWlmYXJjaCBp YTY0CiVkZWZpbmUgaW5pdHJkX2RpciAvYm9vdC9lZmkKJWVsc2UKJWRlZmluZSBpbml0cmRf ZGlyIC9ib290CiVlbmRpZgoKJWRlZmluZSBLVkVSUkVMICV7UEFDS0FHRV9WRVJTSU9OfS0l e1BBQ0tBR0VfUkVMRUFTRX0KCiVpZmFyY2ggJXthbGxfeDg2fQolZGVmaW5lIGtlcm5lbF9n bG9iIHZtbGludXotJXtLVkVSUkVMfQolZGVmaW5lIGRlYnVnX2tlcm5lbF9nbG9iIHZtbGlu dT8tJXtLVkVSUkVMfQolZW5kaWYKJWlmYXJjaCAle2FsbF9wcGN9CiVkZWZpbmUga2VybmVs X2dsb2Igdm1saW51Py0le0tWRVJSRUx9CiVkZWZpbmUgZGVidWdfa2VybmVsX2dsb2Igdm1s aW51Py0le0tWRVJSRUx9CiVlbmRpZgolaWZhcmNoIGlhNjQKIyA8c2lnaD4sIG5vIEdMT0Jf QlJBQ0UgZm9yIGZpbGVsaXN0cywgZWZpIG5lZWRzIHRvIGJlIGRvbmUgc2VwYXJhdGVseQol ZGVmaW5lIGtlcm5lbF9nbG9iIHZtbGludXotJXtLVkVSUkVMfQolZGVmaW5lIGRlYnVnX2tl cm5lbF9nbG9iIHZtbGludT8tJXtLVkVSUkVMfQolZW5kaWYKJWlmYXJjaCBhbHBoYQolZGVm aW5lIGtlcm5lbF9nbG9iIHZtbGludT8tJXtLVkVSUkVMfQolZGVmaW5lIGRlYnVnX2tlcm5l bF9nbG9iIHZtbGludT8tJXtLVkVSUkVMfQolZW5kaWYKJWlmYXJjaCBzMzkwIHMzOTB4CiVk ZWZpbmUga2VybmVsX2dsb2Igdm1saW51Py0le0tWRVJSRUx9CiVkZWZpbmUgZGVidWdfa2Vy bmVsX2dsb2Igdm1saW51Py0le0tWRVJSRUx9CiVlbmRpZgoKTmFtZToga2VybmVsClZlcnNp b246ICV7a3ZlcnNpb259ClJlbGVhc2U6ICV7cmVsZWFzZX0lez9kZWJ1Z2xldmVsXzE6LmRi Z30le2V4dHJhX3JlbGVhc2V9CkxpY2Vuc2U6IEdQTApHcm91cDogU3lzdGVtIEVudmlyb25t ZW50L0tlcm5lbApFeGNsdXNpdmVBcmNoOiAle2FsbF94ODZ9IHMzOTAgJXthbGxfcHBjfSBp YTY0IGFscGhhCkV4Y2x1c2l2ZU9TOiBMaW51eApPYnNvbGV0ZXM6IGtlcm5lbC1tb2R1bGVz LCBrZXJuZWwtc3BhcmMKUHJvdmlkZXM6IG1vZHVsZS1pbmZvLCBrZXJuZWwgPSAle3ZlcnNp b259LCBrZXJuZWwtZHJtID0gJXtkcm12ZXJ9CkF1dG9yZXFwcm92OiBubwpQcmVyZXE6ICV7 a2VybmVsX3ByZXJlcX0KQ29uZmxpY3RzOiAle2tlcm5lbF9jb25mbGljdHN9ClZlbmRvcjog U0dJClBhY2thZ2VyOiBFcmljIFNhbmRlZW4gPHNhbmRlZW5Ac2dpLmNvbT4KRGlzdHJpYnV0 aW9uOiBTR0kgWEZTClVybDogaHR0cDovL29zcy5zZ2kuY29tL3Byb2plY3RzL3hmcwoKQnVp bGRQcmVSZXE6IG1vZHV0aWxzID49IDIuNC4yLCBwYXRjaCA+PSAyLjUuNCwgYmFzaCA+PSAy LjAzLCBzaC11dGlscywgZ251cGcKJWlmYXJjaCBzMzkwIHMzOTB4CkJ1aWxkUmVxdWlyZXM6 IGdjYyA+PSAyLjk1LjMKJWVsc2UKJWlmYXJjaCAle2FsbF9wcGN9CkJ1aWxkUmVxdWlyZXM6 IGdjYyA+PSAyLjk2LTc1CiVlbHNlCkJ1aWxkUmVxdWlyZXM6IGdjYyA+PSAyLjk2LTg1CiVl bmRpZgolZW5kaWYKClNvdXJjZTA6IGZ0cDovL2Z0cC5rZXJuZWwub3JnL3B1Yi9saW51eC9r ZXJuZWwvdjIuNC9saW51eC0le2t2ZXJzaW9ufS50YXIuYnoyClNvdXJjZTQ6IFJFQURNRS5r ZXJuZWwtc291cmNlcwoKU291cmNlMTE6IG1vZHVsZS1pbmZvClNvdXJjZTE0OiBrZXJuZWwt Mi40LUJ1aWxkQVNNLnNoClNvdXJjZTE1OiBsaW51eC1yaGNvbmZpZy5oClNvdXJjZTE2OiBs aW51eC1tZXJnZS1jb25maWcuYXdrClNvdXJjZTE3OiBsaW51eC1tZXJnZS1tb2R1bGVzLmF3 awpTb3VyY2UxODogZ2Vua2V5CgpTb3VyY2UyMDoga2VybmVsLSV7a3ZlcnNpb259LWkzODYu Y29uZmlnClNvdXJjZTIxOiBrZXJuZWwtJXtrdmVyc2lvbn0taTM4Ni1zbXAuY29uZmlnClNv dXJjZTIyOiBrZXJuZWwtJXtrdmVyc2lvbn0taTM4Ni1CT09ULmNvbmZpZwpTb3VyY2UyMzog a2VybmVsLSV7a3ZlcnNpb259LWFscGhhLmNvbmZpZwpTb3VyY2UyNDoga2VybmVsLSV7a3Zl cnNpb259LWFscGhhLXNtcC5jb25maWcKU291cmNlMjU6IGtlcm5lbC0le2t2ZXJzaW9ufS1z cGFyYy5jb25maWcKU291cmNlMjY6IGtlcm5lbC0le2t2ZXJzaW9ufS1zcGFyYy1zbXAuY29u ZmlnClNvdXJjZTI3OiBrZXJuZWwtJXtrdmVyc2lvbn0tc3BhcmM2NC5jb25maWcKU291cmNl Mjg6IGtlcm5lbC0le2t2ZXJzaW9ufS1zcGFyYzY0LXNtcC5jb25maWcKU291cmNlMjk6IGtl cm5lbC0le2t2ZXJzaW9ufS1pNjg2LmNvbmZpZwpTb3VyY2UzMDoga2VybmVsLSV7a3ZlcnNp b259LWk2ODYtc21wLmNvbmZpZwpTb3VyY2UzMToga2VybmVsLSV7a3ZlcnNpb259LWFscGhh LUJPT1QuY29uZmlnClNvdXJjZTMyOiBrZXJuZWwtJXtrdmVyc2lvbn0tc3BhcmMtQk9PVC5j b25maWcKU291cmNlMzM6IGtlcm5lbC0le2t2ZXJzaW9ufS1zcGFyYzY0LUJPT1QuY29uZmln ClNvdXJjZTM0OiBrZXJuZWwtJXtrdmVyc2lvbn0taTU4Ni5jb25maWcKU291cmNlMzU6IGtl cm5lbC0le2t2ZXJzaW9ufS1pNTg2LXNtcC5jb25maWcKIyBzaW5jZSB0aGVyZSBhcmUgbm8g c3BhY2UgaXNzdWVzLCBhIC1CT09UIGlzIHJhdGhlciBwb2ludGxlc3MKU291cmNlMzY6IGtl cm5lbC0le2t2ZXJzaW9ufS1pYTY0LmNvbmZpZwpTb3VyY2UzNzoga2VybmVsLSV7a3ZlcnNp b259LWlhNjQtc21wLmNvbmZpZwpTb3VyY2UzODoga2VybmVsLSV7a3ZlcnNpb259LWk2ODYt ZW50ZXJwcmlzZS5jb25maWcKU291cmNlMzk6IGtlcm5lbC0le2t2ZXJzaW9ufS1pNjg2LWRl YnVnLmNvbmZpZwpTb3VyY2U0MDoga2VybmVsLSV7a3ZlcnNpb259LWF0aGxvbi5jb25maWcK U291cmNlNDE6IGtlcm5lbC0le2t2ZXJzaW9ufS1hdGhsb24tc21wLmNvbmZpZwpTb3VyY2U0 Mjoga2VybmVsLSV7a3ZlcnNpb259LWFscGhhLWplbnNlbi5jb25maWcKU291cmNlNDM6IGtl cm5lbC0le2t2ZXJzaW9ufS1zMzkwLUJPT1R0YXBlLmNvbmZpZwpTb3VyY2U0NDoga2VybmVs LSV7a3ZlcnNpb259LXMzOTAtQk9PVC5jb25maWcKU291cmNlNDU6IGtlcm5lbC0le2t2ZXJz aW9ufS1zMzkwLXRhcGUuY29uZmlnClNvdXJjZTQ2OiBrZXJuZWwtJXtrdmVyc2lvbn0tczM5 MC1kZWJ1Zy5jb25maWcKU291cmNlNDY6IGtlcm5lbC0le2t2ZXJzaW9ufS1zMzkwLmNvbmZp ZwpTb3VyY2U0Nzoga2VybmVsLSV7a3ZlcnNpb259LWlhNjQtQk9PVC5jb25maWcKU291cmNl NTA6IGluc3RhbGxrZXJuZWwuaVNlcmllcwpTb3VyY2U1MTogaW5zdGFsbGNtZGxpbmUuaVNl cmllcwpTb3VyY2U1Mjoga2VybmVsLSV7a3ZlcnNpb259LXBwYy5jb25maWcKU291cmNlNTM6 IGtlcm5lbC0le2t2ZXJzaW9ufS1wcGNwc2VyaWVzLmNvbmZpZwpTb3VyY2U1NDoga2VybmVs LSV7a3ZlcnNpb259LXBwY3BzZXJpZXMtc21wLmNvbmZpZwpTb3VyY2U1NToga2VybmVsLSV7 a3ZlcnNpb259LXBwY3BzZXJpZXMtQk9PVC5jb25maWcKU291cmNlNTY6IGtlcm5lbC0le2t2 ZXJzaW9ufS1zMzkweC1CT09UdGFwZS5jb25maWcKU291cmNlNTc6IGtlcm5lbC0le2t2ZXJz aW9ufS1zMzkweC1CT09ULmNvbmZpZwpTb3VyY2U1ODoga2VybmVsLSV7a3ZlcnNpb259LXMz OTB4LXRhcGUuY29uZmlnClNvdXJjZTU5OiBrZXJuZWwtJXtrdmVyc2lvbn0tczM5MHguY29u ZmlnClNvdXJjZTYwOiBrZXJuZWwtJXtrdmVyc2lvbn0tcHBjNjQtc21wLmNvbmZpZwpTb3Vy Y2U2MToga2VybmVsLSV7a3ZlcnNpb259LXBwYzY0LUJPT1QuY29uZmlnCgpTb3VyY2U4MDog bGludXgtMi40LjctaWtkLnBhdGNoCgojCiMgUGF0Y2hlcyAwIHRocm91Z2ggMTAwIGFyZSBt ZWFudCBmb3IgY29yZSBzdWJzeXN0ZW0gdXBncmFkZXMKIwpQYXRjaDE6IGZ0cDovL2Z0cC5r ZXJuZWwub3JnL3B1Yi9saW51eC9rZXJuZWwvcGVvcGxlL2FsYW4vMi40L3BhdGNoLTIuNC45 LWFjMTAuYnoyCgoKCiMgCiMgUGF0Y2hlcyAxMDAgdGhyb3VnaCA0MDAgYXJlIGFyY2hpdGVj dHVyZSBzcGVjaWZpYyBwYXRjaGVzCiMgRWFjaCBhcmNoaXRlY3R1cmUgaGFzIDIwIHNsb3Rz IHJlc2VydmVkLgojCgojIElBNjQKUGF0Y2gxMDA6IGxpbnV4LTIuNC45LWlhNjQtY29yZS5w YXRjaApQYXRjaDEwMTogbGludXgtMi40LjktaWE2NC1qdW5rLnBhdGNoClBhdGNoMTAyOiBs aW51eC0yLjQuOS1pYTY0LWNzNDI4MS5wYXRjaApQYXRjaDEwMzogbGludXgtMi40LjktaWE2 NC10aW1lci5wYXRjaApQYXRjaDEwNDogbGludXgtMi40LjEwLWlhNjQtZHJtLnBhdGNoClBh dGNoMTA1OiBsaW51eC0yLjQuOS1pYTY0LWNvbXBpbGUucGF0Y2gKUGF0Y2gxMDY6IGxpbnV4 LTIuNC4xLWlhNjQtc3dpb3RsYi5wYXRjaApQYXRjaDEwNzogbGludXgtMi40LjUtaWE2NC11 bmFsaWduZWQucGF0Y2gKUGF0Y2gxMDg6IGxpbnV4LTIuNC45LWlhNjQtZWVwcm8xMDAucGF0 Y2gKUGF0Y2gxMDk6IGxpbnV4LTIuNC45LWlhNjQtdW53aW5kLnBhdGNoClBhdGNoMTEwOiBs aW51eC0yLjQuOS1pYTY0LXRyYXBpbmZvLnBhdGNoClBhdGNoMTExOiBsaW51eC0yLjQuMy1p YTY0LXBwcC5wYXRjaApQYXRjaDExMjogbGludXgtMi40LjktaWE2NC11cGRhdGVzLnBhdGNo ClBhdGNoMTEzOiBsaW51eC0yLjQuMTAtZ3B0LTIwMDEwOTI4LnBhdGNoClBhdGNoMTE0OiBs aW51eC0yLjQuOS1pYTY0LWZhbmN5c3dpb21tdS5wYXRjaAoKCiMgQWxwaGEKUGF0Y2gxMjA6 IGxpbnV4LTIuMy45OS1hbHBoYS5wYXRjaApQYXRjaDEyMTogbGludXgtMi40LjEtYWxwaGFr c3ltcy5wYXRjaApQYXRjaDEyMjogbGludXgtMi40LjAtYWxwaGEucGF0Y2gKUGF0Y2gxMjM6 IGxpbnV4LTIuNC4zLWFscGhha3N5bXMucGF0Y2gKUGF0Y2gxMjQ6IGxpbnV4LTIuNC4zLW5h dXRpbHVzLnBhdGNoClBhdGNoMTI1OiBsaW51eC0yLjQuNS1hbHBoYWV4cG9ydHMucGF0Y2gK CiMgU3BhcmMgLyBTcGFyYzY0ClBhdGNoMTQwOiBsaW51eC0yLjMuOTlwM3A2LXNwYXJjLnBh dGNoCgojIHg4NgpQYXRjaDE2MDogbGludXgtMi40LjEtYnJva2VubXB0YWJsZS5wYXRjaAoK IyBwcGMKUGF0Y2gxODE6IGxpbnV4LTIuNC42LXBwYy1jb21waWxlLnBhdGNoClBhdGNoMTgz OiBsaW51eC0yLjQuNi1wcGMtcGNuZXQzMi5wYXRjaApQYXRjaDE4NDogbGludXgtMi40Ljkt cHBjLWFjMTAucGF0Y2gKUGF0Y2gxODU6IGxpbnV4LTIuNC45LXBwYzY0LWFjMTAucGF0Y2gK UGF0Y2gxODY6IGxpbnV4LTIuNC45LXBwYzY0LXJoLnBhdGNoCgojIHMzOTAgLyBzMzkweApQ YXRjaDIwMDogbGludXgtMi40LjktczM5MC1hYzE0LnBhdGNoClBhdGNoMjA1OiBsaW51eC0y LjQuOS1zMzkwLXJoLnBhdGNoClBhdGNoMjA2OiBsaW51eC0yLjQuOS1zMzkwLWRhc2QucGF0 Y2gKUGF0Y2gyMDc6IGxpbnV4LTIuNC45LXMzOTAtcmgyLnBhdGNoClBhdGNoMjA4OiBsaW51 eC0yLjQuOS1zMzkwLTU0MzkwLnBhdGNoClBhdGNoMjA5OiBsaW51eC0yLjQuOS1zMzkwLWRh c2Rtc2cucGF0Y2gKUGF0Y2gyMTA6IGxpbnV4LTIuNC4xMy1zMzkwLWFjNy5wYXRjaAojUGF0 Y2gyMTE6IGxpbnV4LTIuNC45LXMzOTAtcmVhbHJvb3RkZXYucGF0Y2ggaXMgbm93IDkyNQpQ YXRjaDIxMjogbGludXgtMi40LjktczM5MC1mcy5wYXRjaApQYXRjaDIxMzogbGludXgtMi40 LjctczM5MC0zLnBhdGNoClBhdGNoMjE0OiBsaW51eC0yLjQuOS1zMzkwLWZzbS5wYXRjaApQ YXRjaDIxNTogbGludXgtMi40LjktczM5MC1yYWlkLnBhdGNoClBhdGNoMjE2OiBsaW51eC0y LjQuNy11bmJsYW5rLnBhdGNoClBhdGNoMjE3OiBsaW51eC0yLjQuNy1zeXNpbmZvLnBhdGNo ClBhdGNoMjE4OiBsaW51eC0yLjQuNy1zMzkwLTQucGF0Y2gKI1BhdGNoMjE5OiBsaW51eC0y LjQuMTAtczM5MC1wcm9jZnMucGF0Y2ggaXMgbm93IDIzMzAKUGF0Y2gyMjA6IGxpbnV4LTIu NC45LXMzOTAtcmFtZGlzay5wYXRjaApQYXRjaDIyMTogbGludXgtMi40LjktczM5MC1rZXJu dHlwZXMucGF0Y2gKUGF0Y2gyMjI6IGxpbnV4LTIuNC45LXMzOTAtbWF0aGVtdS5wYXRjaAoj UGF0Y2gyMjM6IGxpbnV4LTIuNC45LWNyYW1mcy5wYXRjaCBpcyBub3cgMjM0MApQYXRjaDIy NDogbGludXgtMi40LjktczM5MC1jcGludC5wYXRjaAoKCiMKIyBQYXRjaGVzIDQwMCB0aHJv dWdoIDU5OSBhcmUgdGhlIFRVWCBwYXRjaGVzCiMKClBhdGNoNDAwOiBsaW51eC0yLjQuMi1i eXRlcHJvZmlsaW5nLnBhdGNoClBhdGNoNDEwOiBsaW51eC0yLjQuMi1waWQtcHJvZmlsaW5n LnBhdGNoClBhdGNoNDIwOiBsaW51eC0yLjQuMi1zbXB0aW1lcnMucGF0Y2gKUGF0Y2g0MzA6 IGxpbnV4LTIuNC4yLXBhZ2VjYWNoZS5wYXRjaApQYXRjaDQ0MDogbGludXgtMi40LjItYXRv bWljLWxvb2t1cC5wYXRjaApQYXRjaDQ1MDogbGludXgtMi40LjItaXB1dC1mcmVlLnBhdGNo ClBhdGNoNDYwOiBsaW51eC0yLjQuMi1leHBvcnRzLWNsZWFudXAucGF0Y2gKUGF0Y2g0NzA6 IGxpbnV4LTIuNC4yLXR1eC12ZnMucGF0Y2gKUGF0Y2g0ODA6IGxpbnV4LTIuNC4yLWF0b21p Y2FsbG9jLnBhdGNoClBhdGNoNDkwOiBsaW51eC0yLjQuMi1wZXItY3B1LXBhZ2VzLnBhdGNo ClBhdGNoNTAwOiBsaW51eC0yLjQuMi10dXgtcHJvY2Vzcy5wYXRjaApQYXRjaDUxMDogbGlu dXgtMi40LjItdm0tMS0yLTMtZ2J5dGUucGF0Y2gKUGF0Y2g1MzA6IGxpbnV4LTIuNC4yLXR1 eC1zeXNjdGwucGF0Y2gKUGF0Y2g1NDA6IGxpbnV4LTIuNC4yLXR1eC1rc3RhdC5wYXRjaApQ YXRjaDU1MDogbGludXgtMi40LjItbmV0LWV4cG9ydHMucGF0Y2gKUGF0Y2g1NjA6IGxpbnV4 LTIuNC4yLXR1eC1zeXNjYWxsLnBhdGNoClBhdGNoNTcwOiBsaW51eC0yLjQuMy1idXN0c3Bp bmxvY2tzLnBhdGNoClBhdGNoNTgwOiBsaW51eC0yLjQuOS10dXgyLnBhdGNoClBhdGNoNTgx OiBsaW51eC0yLjQuOS10dXgyLWZpeGVzLnBhdGNoCgojCiMgUGF0Y2hlcyA2MDAgdGhyb3Vn aCAxMDAwIGFyZSByZXNlcnZlZCBmb3IgYnVnZml4ZXMgdG8gdGhlIGNvcmUgc3lzdGVtCiMg YW5kIHBhdGNoZXMgcmVsYXRlZCB0byBob3cgUlBNcyBhcmUgYnVpbGQKIwoKUGF0Y2g2MDA6 IGxpbnV4LTIuNC4wLW5vbmludGNvbmZpZy5wYXRjaApQYXRjaDYxMDogbGludXgtMi40LjMt bWF4c2VjdG9ycy5wYXRjaApQYXRjaDYyMDogbGludXgtMi40LjEtcXVpZXQucGF0Y2gKcGF0 Y2g2MzA6IGxpbnV4LTIuNC43LXF1b3RhcmV0dXJuLnBhdGNoClBhdGNoNjQwOiBsaW51eC0y LjIuMTYtcmhjb25maWcucGF0Y2gKUGF0Y2g2NTA6IGxpbnV4LTIuNC4yLWNoYW5nZWxvb3Au cGF0Y2gKUGF0Y2g2NjA6IGxpbnV4LTIuNC4xLXByaW50a2J1ZmZlci5wYXRjaApQYXRjaDY3 MDogbGludXgtMi40LjUtY29uZmlnLXNtYWxsLnBhdGNoClBhdGNoNjkwOiBsaW51eC0yLjQu Ni1tdWx0aXBhdGgucGF0Y2gKUGF0Y2g3MDA6IGxpbnV4LTIuNC4yLWJsa2lvY3RsLXNlY3Rv ci5wYXRjaApQYXRjaDcxMDogbGludXgtMi40LjUtaG90cGx1Zy5wYXRjaApQYXRjaDcxMTog bGludXgtMi40LjktaG90cGx1Zy5wYXRjaApQYXRjaDcyMDogbGludXgtMi40LjUtaTM4Nmk1 ODYucGF0Y2gKUGF0Y2g3MzA6IGxpbnV4LTIuNC4xLXNjc2ktcmVzZXQucGF0Y2gKUGF0Y2g3 NDA6IGxpbnV4LTIuNC4yLXBnZS5wYXRjaApQYXRjaDc1MDogbGludXgtMi40LjMtaXJpeG5m cy5wYXRjaApQYXRjaDc2MDogbGludXgtMi40LjItc2NzaV9zY2FuLnBhdGNoClBhdGNoNzcw OiBsaW51eC0yLjQuMC1jaXBlLTEuNC41LnBhdGNoClBhdGNoNzcxOiBsaW51eC0yLjQuMi1j aXBlLnBhdGNoClBhdGNoNzgwOiBsaW51eC0yLjQuMi1ib290bWVtX29vbS5wYXRjaApQYXRj aDc5MDogbGludXgtMi40LjktbG1fc2Vuc29ycy5wYXRjaApQYXRjaDc5MTogbGludXgtMi40 LjktaTJjLnBhdGNoClBhdGNoODAwOiBsaW51eC0yLjQuNS1jYWRwaWQucGF0Y2gKUGF0Y2g4 MTA6IGxpbnV4LTIuNC4zLXNtcF9jYWxsX2Z1bmN0aW9uLnBhdGNoClBhdGNoODIwOiBsaW51 eC0yLjQuNS1zd2FwaW5mby5wYXRjaApQYXRjaDgzMDogbGludXgtMi40LjYtbm9oaWdobWVt LnBhdGNoClBhdGNoODQxOiBsaW51eC0yLjQuNi1wYXJwb3J0cG5wLnBhdGNoClBhdGNoODUw OiBsaW51eC0yLjQuNi1tb3Jlc3dhcC5wYXRjaApQYXRjaDg2MDogbGludXgtMi40LjYtb29t LW1vZGVyYXRlLnBhdGNoClBhdGNoODcwOiBsaW51eC0yLjQuOS1ibG9ja2hpZ2htZW0ucGF0 Y2gKUGF0Y2g4ODA6IGxpbnV4LTIuNC42LXRyaXBsZWxvY2sucGF0Y2gKUGF0Y2g4OTA6IGxp bnV4LTIuNC42LW9vbWF2b2lkYW5jZS5wYXRjaApQYXRjaDkwMDogbGludXgtMi40LjktZ2Vu ZGlza2JhY2tvdXQucGF0Y2gKUGF0Y2g5MTA6IGxpbnV4LTIuNC45LWtrc3ltb29wcy5wYXRj aApQYXRjaDkxMTogbGludXgtMi40Ljkta2FsbHN5bXMucGF0Y2gKUGF0Y2g5MjA6IGxpbnV4 LTIuNC43LWlvcXVldWUucGF0Y2gKUGF0Y2g5MjU6IGxpbnV4LTIuNC45LXMzOTAtcmVhbHJv b3RkZXYucGF0Y2gKUGF0Y2g5MzA6IGxpbnV4LTIuNC45LXRhaW50ZWQucGF0Y2gKUGF0Y2g5 NDA6IGxpbnV4LTIuNC43LXZtdHVuaW5nLnBhdGNoClBhdGNoOTUwOiBsaW51eC0yLjQuOS1h Z2luZy5wYXRjaApQYXRjaDk2MDogbGludXgtMi40LjctaGlnaG1lbXNwZWVkLnBhdGNoClBh dGNoOTcwOiBsaW51eC0yLjQuOS1yc3MucGF0Y2gKUGF0Y2g5ODA6IGxpbnV4LTIuNC45LXNt cHNjaGVkLnBhdGNoClBhdGNoOTkwOiBsaW51eC0yLjQuOS1wYWdlX2RpcnR5LnBhdGNoCgoj CiMgUGF0Y2hlcyAxMDAwIHRvIDUwMDAgYXJlIHJlc2VydmVkIGZvciBidWdmaXhlcyB0byBk cml2ZXJzIGFuZCBmaWxlc3lzdGVtcwojCgpQYXRjaDEwMDA6IGtlcm5lbC0yLjQtc3RyaW5n LnBhdGNoClBhdGNoMTAxMDogbGludXgtMi40LjYtY3JhbWZzLnBhdGNoClBhdGNoMTAyMDog bGludXgtMi40LjItcmVxX2ZpbmlzaGVkX2lvLnBhdGNoClBhdGNoMTAzMDogbGludXgtMi40 LjktcWxhZHJpdmVycy5wYXRjaApQYXRjaDEwNDA6IGxpbnV4LTIuNC4wLXN5bTUzLTY0Yml0 LnBhdGNoClBhdGNoMTA4MDogbGludXgtMi40LjAtdGVzdDExLXZpZGZhaWwucGF0Y2gKUGF0 Y2gxMDkwOiBsaW51eC0yLjQuMC1lODIwLnBhdGNoClBhdGNoMTEwMDogbGludXgtMi40LjAt cmFpZDV4b3IucGF0Y2gKUGF0Y2gxMTEwOiBsaW51eC0yLjQuMi1tZW0tc2V0dXAtZml4LnBh dGNoClBhdGNoMTEyMDogbGludXgtMi40LjItcGFnZV9iaXRtYXAucGF0Y2gKUGF0Y2gxMTMw OiBsaW51eC0yLjQuMC1hcGljLXF1aWV0LnBhdGNoClBhdGNoMTE0MDogbGludXgtMi40LjEt c2V0dXBfZGVsYXkucGF0Y2gKUGF0Y2gxMTUwOiBsaW51eC0yLjQuMS11aGNpLXNsYWIucGF0 Y2gKUGF0Y2gxMTYwOiBsaW51eC0yLjQuNy1pODEwLnBhdGNoClBhdGNoMTE3MDogbGludXgt Mi40LjMtcmF3aW8ucGF0Y2gKUGF0Y2gxMTgwOiBsaW51eC0yLjQuMy1pODIzNjUucGF0Y2gK UGF0Y2gxMjAwOiBsaW51eC0yLjQuMy1kZWxsbXB0YWJsZS5wYXRjaApQYXRjaDEyMjA6IGxp bnV4LTIuNC4xLW5ldGRlYnVnLnBhdGNoClBhdGNoMTIzMDogbGludXgtMi40LjMtNDUwZ3gu cGF0Y2gKUGF0Y2gxMjUwOiBsaW51eC0yLjQuMi1lZXBybzEwMC1hbHBoYS5wYXRjaApQYXRj aDEyNjA6IGxpbnV4LTIuNC4zLXBjaXBlbmFsdHkucGF0Y2gKUGF0Y2gxMjcwOiBsaW51eC0y LjQuMy13YWtldXBzcGVlZC5wYXRjaApQYXRjaDEyODA6IGxpbnV4LTIuNC4zLWVjbi5wYXRj aApQYXRjaDEyOTA6IGxpbnV4LTIuNC4yLWlkZWJsYWNrbGlzdC5wYXRjaApQYXRjaDEzMTA6 IGxpbnV4LTIuNC43LXVzYi1idWc1MTE0Mi5wYXRjaApQYXRjaDEzMjA6IGxpbnV4LTIuNC43 LXVzYi1idWc1MDIxOC5wYXRjaApQYXRjaDEzMzA6IGxpbnV4LTIuNC4yLXVzYi1zY3NpZ2x1 ZS5wYXRjaApQYXRjaDEzNDA6IGxpbnV4LTIuNC4yLWtleWJvYXJkc2lsZW5jZS5wYXRjaApQ YXRjaDEzNTA6IGxpbnV4LTIuNC4zLXVwYXBpYy5wYXRjaApQYXRjaDEzNjA6IGxpbnV4LTIu NC4yLXZpYWRtYTY2LnBhdGNoClBhdGNoMTM3MDogbGludXgtMi40LjMtcGNuZXQzMi5wYXRj aApQYXRjaDEzOTA6IGxpbnV4LTIuNC4yLXVzYnRocm90dGxlLnBhdGNoClBhdGNoMTM5MTog bGludXgtMi40LjktYWMxMC11c2ItdG1wLnBhdGNoClBhdGNoMTM5NTogbGludXgtMi40Ljkt dXNiLWJ1ZzU3NTMxLnBhdGNoClBhdGNoMTQwMDogbGludXgtMi40LjMtc2IucGF0Y2gKUGF0 Y2gxNDEwOiBsaW51eC0yLjQuMi1vaGNpLWlycS5wYXRjaApQYXRjaDE0NDA6IGxpbnV4LTIu NC4zLXN5c3JxVC1jcHUucGF0Y2gKUGF0Y2gxNDUwOiBsaW51eC0yLjQuNS14aXJjb20tY2Iu cGF0Y2gKUGF0Y2gxNDcwOiBsaW51eC0yLjQuNi1zYl9pZC5wYXRjaApQYXRjaDE0ODA6IGxp bnV4LTIuNC43LWRlbGxyZWJvb3QucGF0Y2gKUGF0Y2gxNTAwOiBsaW51eC0yLjQuNi1jY2lz cy5wYXRjaApQYXRjaDE2ODA6IGxpbnV4LTIuNC43LXNjc2l0aW1lb3V0LnBhdGNoClBhdGNo MTc1MDogbGludXgtMi40LjctcGRjcmFpZC5wYXRjaApQYXRjaDE4NzA6IGxpbnV4LTIuNC43 LW5vYXRobG9uLnBhdGNoClBhdGNoMTg4MDogbGludXgtMi40LjktYXRhcmFpZC5wYXRjaApQ YXRjaDE4OTA6IGxpbnV4LTIuNC43LWNvbXBhcWlvY3RsLnBhdGNoClBhdGNoMTkwMDogbGlu dXgtMi40Ljktcm9kZW50LnBhdGNoClBhdGNoMTkxMDogbGludXgtMi40LjctbmZzb29wcy5w YXRjaApQYXRjaDE5MjA6IGxpbnV4LTIuNC45LWZyZWV2eGZzLnBhdGNoClBhdGNoMTkzMDog bGludXgtMi40LjktaWRlLWxiYTQ4LnBhdGNoClBhdGNoMTk0MDogbGludXgtMi40LjktbWF4 c2VjdG9ycy5wYXRjaApQYXRjaDE5NTA6IGxpbnV4LTIuNC43LW5hdHNlbWkucGF0Y2gKUGF0 Y2gxOTYwOiBsaW51eC0yLjQuOS1pcHMucGF0Y2gKUGF0Y2gxOTcwOiBsaW51eC0yLjQuNy1h aWM3eHh4LnBhdGNoClBhdGNoMTk4MDogbGludXgtMi40LjctZXdyazMucGF0Y2gKUGF0Y2gx OTkwOiBsaW51eC0yLjQuNy1kaXNrZG1hLnBhdGNoClBhdGNoMjAwMDogbGludXgtMi40Ljkt Y2Npc3MucGF0Y2gKUGF0Y2gyMDEwOiBsaW51eC0yLjQuOS1tb2R1bGVfZ3BsLnBhdGNoClBh dGNoMjAyMDogbGludXgtMi40LjktcWxhMTI4MC5wYXRjaApQYXRjaDIwMzA6IGxpbnV4LTIu NC45LWFwbS5wYXRjaApQYXRjaDIwNDA6IGxpbnV4LTIuNC45LW5pY3VwZGF0ZXMucGF0Y2gK UGF0Y2gyMDUwOiBsaW51eC0yLjQuOS1lbGZidWcucGF0Y2gKUGF0Y2gyMDYwOiBsaW51eC0y LjQuOS1pcGMucGF0Y2gKUGF0Y2gyMDcwOiBsaW51eC0yLjQuOS1sb29wZml4LnBhdGNoClBh dGNoMjA4MDogbGludXgtMi40LjktcmFkZW9uLnBhdGNoClBhdGNoMjA5MDogbGludXgtMi40 LjktZW11MTBrLnBhdGNoClBhdGNoMjEwMDogbGludXgtMi40LjctZmluZGdldHBhZ2UucGF0 Y2gKUGF0Y2gyMTEwOiBsaW51eC0yLjQuOS1wdHJhY2UucGF0Y2gKUGF0Y2gyMTIwOiBsaW51 eC0yLjQuOS1uZnMucGF0Y2gKUGF0Y2gyMTMwOiBsaW51eC0yLjQuOS1xdW90YS5wYXRjaApQ YXRjaDIxNDA6IGxpbnV4LTIuNC45LWlkZS10YXBlLnBhdGNoClBhdGNoMjE2MDogbGludXgt Mi40LjktNDQwZ3gtYXBpYy5wYXRjaApQYXRjaDIxNzA6IGxpbnV4LTIuNC45LW1lZ2FyYWlk LnBhdGNoClBhdGNoMjE3MTogbGludXgtMi40LjktbWVnYXJhaWQtMi5wYXRjaApQYXRjaDIx ODA6IGxpbnV4LTIuNC45LW1jZS5wYXRjaApQYXRjaDIxOTA6IGxpbnV4LTIuNC45LWNvbXBh cWRyaXZlcnMucGF0Y2gKUGF0Y2gyMjAwOiBsaW51eC0yLjQuOS10dHkucGF0Y2gKUGF0Y2gy MjEwOiBsaW51eC0yLjQuOS1kZXZsb2NrLnBhdGNoClBhdGNoMjIyMDogbGludXgtMi40Ljkt dGlkLnBhdGNoClBhdGNoMjIzMDogbGludXgtMi40LjktcHJvY21vdW50cy5wYXRjaApQYXRj aDIyNDA6IGxpbnV4LTIuNC45LWNwdW1lbHRpbmcucGF0Y2gKUGF0Y2gyMjUwOiBsaW51eC0y LjQuOS1hdGhsb25idWcucGF0Y2gKUGF0Y2gyMjYwOiBsaW51eC0yLjQuOS1tZWdhcmFpZHZv bGF0aWxlLnBhdGNoClBhdGNoMjI3MDogbGludXgtMi40LjktaHlwZXJ0aHJlYWRpbmcucGF0 Y2gKUGF0Y2gyMjgwOiBsaW51eC0yLjQuOS1wY21jaWEtdm9sdGFnZS5wYXRjaApQYXRjaDIy OTA6IGxpbnV4LTIuNC45LWFjcGkucGF0Y2gKUGF0Y2gyMjkxOiBsaW51eC0yLjQuOS1zdW1t aXQucGF0Y2gKUGF0Y2gyMzAwOiBsaW51eC0yLjQuOS1pZGVmbG9wcHkucGF0Y2gKUGF0Y2gy MzEwOiBsaW51eC0yLjQuOS11ZGYucGF0Y2gKUGF0Y2gyMzIwOiBsaW51eC0yLjQuOS1kYWM5 NjAucGF0Y2gKUGF0Y2gyMzMwOiBsaW51eC0yLjQuOS10b3BkZWFkbG9jay5wYXRjaApQYXRj aDIzNDA6IGxpbnV4LTIuNC45LWNyYW1mcy5wYXRjaApQYXRjaDIzNTA6IGxpbnV4LTIuNC45 LXNjc2lmaXhlcy5wYXRjaApQYXRjaDIzNjA6IGxpbnV4LTIuNC45LW5mc19zdmNfcXVpZXQu cGF0Y2gKUGF0Y2gyMzcwOiBsaW51eC0yLjQuOS1pODEwLnBhdGNoClBhdGNoMjM3MTogbGlu dXgtMi40LjktaTgxMC0yLnBhdGNoClBhdGNoMjM4MDogbGludXgtMi40Ljktd2F0Y2hkb2ct bm93YXlvdXQucGF0Y2gKUGF0Y2gyMzkwOiBsaW51eC0yLjQuOS1zY3NpbWFzay5wYXRjaApQ YXRjaDI0MDA6IGxpbnV4LTIuNC45LWlwY2hhaW5zbW9kY291bnQucGF0Y2gKCiMKIyBQYXRj aGVzIDUwMDAgdG8gNTgwMCBhcmUgcmVzZXJ2ZWQgZm9yIG5ldyBkcml2ZXJzCiMKUGF0Y2g1 MDAwOiBsaW51eC0yLjQuOS1hZGRvbi5wYXRjaApQYXRjaDUwMTA6IGxpbnV4LTIuNC4xNi1h YWNyYWlkLnBhdGNoClBhdGNoNTAyMDogbGludXgtMi40LjktYmNtNTcwMC5wYXRjaCAgClBh dGNoNTAyMTogbGludXgtMi40LjktYmNtNTcwMC0yOC5wYXRjaApQYXRjaDUwMzA6IGxpbnV4 LTIuNC4wLXd2bGFuLWNzLnBhdGNoClBhdGNoNTAzMTogbGludXgtMi40Ljctd3ZsYW5fY3Mu cGF0Y2gKUGF0Y2g1MDQwOiBsaW51eC0yLjQuMS1uZXRmaWx0ZXItYWRkb25zLnBhdGNoClBh dGNoNTA1MDogbGludXgtMi40LjMtZWNjLnBhdGNoClBhdGNoNTA2MDogbGludXgtMi40Ljkt ZXh0My0wLjkuMTEucGF0Y2gKUGF0Y2g1MDYxOiBsaW51eC0yLjQuOS1leHQzLXVwZGF0ZXMu cGF0Y2gKUGF0Y2g1MDYyOiBsaW51eC0yLjQuOS13cml0ZS1lZmF1bHQucGF0Y2gKUGF0Y2g1 MDcwOiBsaW51eC0yLjQuMi1hbHRlcm5hdGVhaXJvLnBhdGNoClBhdGNoNTA4MDogbGludXgt Mi40LjUtbXh0LnBhdGNoCQpQYXRjaDUwODE6IGxpbnV4LTIuNC42LW14dGZpeC5wYXRjaApQ YXRjaDUwODI6IGxpbnV4LTIuNC42LW14dGJpb3MucGF0Y2gKUGF0Y2g1MDkwOiBsaW51eC0y LjQuNi1iY201ODIwLnBhdGNoClBhdGNoNTA5MTogbGludXgtMi40LjYtYmNtNTgyMC0yLnBh dGNoClBhdGNoNTA5MjogbGludXgtMi40LjctYmNtNTgyMC0xNi5wYXRjaApQYXRjaDUwOTM6 IGxpbnV4LTIuNC43LWJjbTU4MjAtMTcucGF0Y2gKUGF0Y2g1MTAwOiBsaW51eC0yLjQuOS1l MTAwLnBhdGNoClBhdGNoNTExMDogbGludXgtMi40LjktZTEwMDAucGF0Y2gKUGF0Y2g1MTIw OiBsaW51eC0yLjQuNi1pc2NzaS5wYXRjaApQYXRjaDUxMjE6IGxpbnV4LTIuNC43LWlzY3Np LXVwZGF0ZS5wYXRjaApQYXRjaDUxMjI6IGxpbnV4LTIuNC45LWlzY3NpLnBhdGNoClBhdGNo NTEzMDogbGludXgtMi40LjctZXRodG9vbC5wYXRjaApQYXRjaDUxNTA6IGxpbnV4LTIuNC43 LWF4bmV0LWNzLnBhdGNoClBhdGNoNTE2MDogbGludXgtMi40Ljctc3VzcGVuZC5wYXRjaApQ YXRjaDUxNzA6IGxpbnV4LTIuNC43LWF2bV9jcy5wYXRjaApQYXRjaDUxODA6IGxpbnV4LTIu NC43LXR1bGlwLnBhdGNoClBhdGNoNTE5MDogbGludXgtMi40LjktcHBwb2F0bS5wYXRjaApQ YXRjaDUyMDA6IGxpbnV4LTIuNC45LWFlcC5wYXRjaApQYXRjaDUyMTA6IGxpbnV4LTIuNC45 LXFsYTIyMDAucGF0Y2gKUGF0Y2g1MjExOiBsaW51eC0yLjQuOS1xbGEyMjAwLXNjc2ltYXNr LnBhdGNoClBhdGNoNTIyMDogbGludXgtMi40LjktZW11MTBrMV9uZXcucGF0Y2gKCgoKIwoj IFBhdGNoZXMgNTgwMCB0byA2MDAwIGFyZSB0aGUgSEEvSVBWUyBwYXRjaGVzCiMKUGF0Y2g1 ODAwOiBsaW51eC0yLjQuMi1pcHZzLnBhdGNoClBhdGNoNTgxMDogbGludXgtMi40LjUtaXB2 c2ZpeC5wYXRjaApQYXRjaDU4MjA6IGxpbnV4LTIuNC41LWlwdnMtMC44LjEucGF0Y2gKCiMK IyBQYXRjaGVzIDYwMDAgYW5kIGxhdGVyIGFyZSByZXNlcnZlZCBmb3IgJWlmIHtzb21ldGhp bmd9IHBhdGNoZXMKIwpQYXRjaDYwMDA6IGxpbnV4LTIuNC45LWxpbnV4LWFiaS5wYXRjaAoK CiMgZGVidWdnaW5nClBhdGNoNzAwMDogbGludXgtMi40LjItYXZpcm8tYnVmZmVyLmMucGF0 Y2gKUGF0Y2g3MDEwOiBsaW51eC0yLjQuMC1ub2hpZ2htZW1kZWJ1Zy5wYXRjaApQYXRjaDcw MjA6IGxpbnV4LTIuNC4yLWhleGJsb2NrbnVtYmVycy5wYXRjaApQYXRjaDcwMzA6IGxpbnV4 LTIuNC4yLXZtcG9pc29uLnBhdGNoClBhdGNoNzA0MDogbGludXgtMi40LjEtZGVidWdnaW5n LnBhdGNoClBhdGNoNzA1MDogbGludXgtMi40LjItc21iZGVidWcucGF0Y2gKCgoKIwojIDEw MDAwIGFuZCBsYXRlciBpcyBmb3Igc3R1ZmYgdGhhdCBoYXMgdG8gY29tZSBsYXN0IGR1ZSB0 byB0aGUKIyBhbW91bnQgb2YgZHJpdmVycyB0aGV5IHRvdWNoCiMKUGF0Y2gxMDAwMDogbGlu dXgtMi40LjAtc2FyZC5wYXRjaApQYXRjaDEwMDAxOiBsaW51eC0yLjQuOS1zYXJkLWdlbmRp c2sucGF0Y2gKIyBmaXggYSBsb3Qgb2Ygd2FybmluZ3MgaW4gdGhlIHBsYWluIGtlcm5lbCBh bmQgcHJldmlvdXMgcGF0Y2hlcwpQYXRjaDEwMDEwOiBsaW51eC0yLjQuMS1jb21waWxlZmFp bHVyZS5wYXRjaApQYXRjaDEwMDIwOiBsaW51eC0yLjQuOS1tb2R1bGVfbGljZW5zZS5wYXRj aApQYXRjaDEwMDIxOiBsaW51eC0yLjQuOS1tb2R1bGVfbGljZW5zZV9pMzg2LnBhdGNoClBh dGNoMTAwMzA6IGxpbnV4LTIuNC45LW5zODM4MjAtMC4xNS5wYXRjaAoKIyBTR0kgWEZTIEZp bGVzeXN0ZW0KUGF0Y2gyMDAwMDogbGludXgtMi40LjktUkg3LjIteGZzLnBhdGNoLmJ6MgpQ YXRjaDIwMDAxOiBsaW51eC0yLjQuOS1SSDcuMi14ZnMtbHZtLnBhdGNoLmJ6MgpQYXRjaDIw MDAyOiBsaW51eC0yLjQuOS1SSDcuMi14ZnMtcGFnZWNhY2hlLnBhdGNoLmJ6MgpQYXRjaDIw MDAzOiBsaW51eC0yLjQuOS1SSDcuMi14ZnMtbm8taW50ZXJtZXp6by5wYXRjaC5iejIKUGF0 Y2gyMDAwNDoga2RiLXYxLjktMi40LjktMTMuYnoyCiAKIyBGaXggc2lsbGluZXNzIGluIGJj bSBkcml2ZXIsIGV4cG9zZWQgYnkgeGZzIGZvciBzb21lIHVua25vd24gcmVhc29uClBhdGNo MjAwMDU6IGxpbnV4LTIuNC45LWJjbS1iemVyby5wYXRjaAogCiMgbWlzYyBuZnNkIGZpeGVz IGZyb20gbmVpbCBicm93bgpQYXRjaDIwMDA2OiBsaW51eC0yLjQuOS1uYi1uZnNkLnBhdGNo CgpCdWlsZFJvb3Q6ICV7X3RtcHBhdGh9L2tlcm5lbC0le0tWRVJSRUx9LXJvb3QKCiVwYWNr YWdlIHNvdXJjZQpTdW1tYXJ5OiBUaGUgc291cmNlIGNvZGUgZm9yIHRoZSBMaW51eCBrZXJu ZWwuCkdyb3VwOiBEZXZlbG9wbWVudC9TeXN0ZW0KUHJlcmVxOiBmaWxldXRpbHMKUmVxdWly ZXM6IGdhd2sKJWlmYXJjaCBzMzkwIHMzOTB4ClJlcXVpcmVzOiBnY2MgPj0gMi45NS4zCiVl bHNlCiVpZmFyY2ggJXthbGxfcHBjfQpSZXF1aXJlczogZ2NjID49IDIuOTYtNzUKJWVsc2UK UmVxdWlyZXM6IGdjYyA+PSAyLjk2LTg1CiVlbmRpZgolZW5kaWYKCiVwYWNrYWdlIGhlYWRl cnMKU3VtbWFyeTogSGVhZGVyIGZpbGVzIGZvciB0aGUgTGludXgga2VybmVsLgpHcm91cDog RGV2ZWxvcG1lbnQvU3lzdGVtClByZXJlcTogZmlsZXV0aWxzIGluaXRzY3JpcHRzID49IDUu ODMKUmVxdWlyZXM6IGdhd2sKCiVwYWNrYWdlIGRvYwpTdW1tYXJ5OiBWYXJpb3VzIGRvY3Vt ZW50YXRpb24gYml0cyBmb3VuZCBpbiB0aGUga2VybmVsIHNvdXJjZS4KR3JvdXA6IERvY3Vt ZW50YXRpb24KCiVkZXNjcmlwdGlvbiAKVGhlIGtlcm5lbCBwYWNrYWdlIGNvbnRhaW5zIHRo ZSBMaW51eCBrZXJuZWwgKHZtbGludXopLCB0aGUgY29yZSBvZiB5b3VyClJlZCBIYXQgTGlu dXggb3BlcmF0aW5nIHN5c3RlbS4gIFRoZSBrZXJuZWwgaGFuZGxlcyB0aGUgYmFzaWMgZnVu Y3Rpb25zCm9mIHRoZSBvcGVyYXRpbmcgc3lzdGVtOiAgbWVtb3J5IGFsbG9jYXRpb24sIHBy b2Nlc3MgYWxsb2NhdGlvbiwgZGV2aWNlCmlucHV0IGFuZCBvdXRwdXQsIGV0Yy4KCiVkZXNj cmlwdGlvbiBzb3VyY2UKVGhlIGtlcm5lbC1zb3VyY2UgcGFja2FnZSBjb250YWlucyB0aGUg c291cmNlIGNvZGUgZmlsZXMgZm9yIHRoZSBMaW51eAprZXJuZWwuIFRoZXNlIHNvdXJjZSBm aWxlcyBhcmUgbmVlZGVkIHRvIGJ1aWxkIG1vc3QgQyBwcm9ncmFtcywgc2luY2UKdGhleSBk ZXBlbmQgb24gdGhlIGNvbnN0YW50cyBkZWZpbmVkIGluIHRoZSBzb3VyY2UgY29kZS4gVGhl IHNvdXJjZQpmaWxlcyBjYW4gYWxzbyBiZSB1c2VkIHRvIGJ1aWxkIGEgY3VzdG9tIGtlcm5l bCB0aGF0IGlzIGJldHRlciB0dW5lZAp0byB5b3VyIHBhcnRpY3VsYXIgaGFyZHdhcmUsIGlm IHlvdSBhcmUgc28gaW5jbGluZWQgKGFuZCB5b3Uga25vdyB3aGF0CnlvdSdyZSBkb2luZyku CgolZGVzY3JpcHRpb24gaGVhZGVycwpLZXJuZWwtaGVhZGVycyBpbmNsdWRlcyB0aGUgQyBo ZWFkZXIgZmlsZXMgZm9yIHRoZSBMaW51eCBrZXJuZWwuICBUaGUKaGVhZGVyIGZpbGVzIGRl ZmluZSBzdHJ1Y3R1cmVzIGFuZCBjb25zdGFudHMgdGhhdCBhcmUgbmVlZGVkIGZvcgpidWls ZGluZyBtb3N0IHN0YW5kYXJkIHByb2dyYW1zIGFuZCBhcmUgYWxzbyBuZWVkZWQgZm9yIHJl YnVpbGRpbmcgdGhlCmtlcm5lbC4KCiVkZXNjcmlwdGlvbiBkb2MKVGhpcyBwYWNrYWdlIGNv bnRhaW5zIGRvY3VtZW50YXRpb24gZmlsZXMgZm9ybSB0aGUga2VybmVsCnNvdXJjZS4gVmFy aW91cyBiaXRzIG9mIGluZm9ybWF0aW9uIGFib3V0IHRoZSBMaW51eCBrZXJuZWwgYW5kIHRo ZQpkZXZpY2UgZHJpdmVycyBzaGlwcGVkIHdpdGggaXQgYXJlIGRvY3VtZW50ZWQgaW4gdGhl c2UgZmlsZXMuIAoKWW91J2xsIHdhbnQgdG8gaW5zdGFsbCB0aGlzIHBhY2thZ2UgaWYgeW91 IG5lZWQgYSByZWZlcmVuY2UgdG8gdGhlCm9wdGlvbnMgdGhhdCBjYW4gYmUgcGFzc2VkIHRv IExpbnV4IGtlcm5lbCBtb2R1bGVzIGF0IGxvYWQgdGltZS4KCiVwYWNrYWdlIHNtcApTdW1t YXJ5OiBUaGUgTGludXgga2VybmVsIGNvbXBpbGVkIGZvciBTTVAgbWFjaGluZXMuCkdyb3Vw OiBTeXN0ZW0gRW52aXJvbm1lbnQvS2VybmVsClByb3ZpZGVzOiBtb2R1bGUtaW5mbywga2Vy bmVsID0gJXt2ZXJzaW9ufSwga2VybmVsLWRybSA9ICV7ZHJtdmVyfQpQcmVyZXE6ICV7a2Vy bmVsX3ByZXJlcX0KQ29uZmxpY3RzOiAle2tlcm5lbF9jb25mbGljdHN9CgolZGVzY3JpcHRp b24gc21wClRoaXMgcGFja2FnZSBpbmNsdWRlcyBhIFNNUCB2ZXJzaW9uIG9mIHRoZSBMaW51 eCBrZXJuZWwuIEl0IGlzCnJlcXVpcmVkIG9ubHkgb24gbWFjaGluZXMgd2l0aCB0d28gb3Ig bW9yZSBDUFVzLCBhbHRob3VnaCBpdCBzaG91bGQKd29yayBmaW5lIG9uIHNpbmdsZS1DUFUg Ym94ZXMuCgpJbnN0YWxsIHRoZSBrZXJuZWwtc21wIHBhY2thZ2UgaWYgeW91ciBtYWNoaW5l IHVzZXMgdHdvIG9yIG1vcmUgQ1BVcy4KCiVwYWNrYWdlIGVudGVycHJpc2UKU3VtbWFyeTog VGhlIExpbnV4IEtlcm5lbCBjb21waWxlZCB3aXRoIG9wdGlvbnMgZm9yIG1hY2hpbmVzIHdp dGggbW9yZSB0aGFuIDQgR2lnYWJ5dGUgb2YgbWVtb3J5LgpHcm91cDogU3lzdGVtIEVudmly b25tZW50L0tlcm5lbApQcm92aWRlczogbW9kdWxlLWluZm8sIGtlcm5lbCA9ICV7dmVyc2lv bn0sIGtlcm5lbC1kcm0gPSAle2RybXZlcn0KUHJlcmVxOiAle2tlcm5lbF9wcmVyZXF9CkNv bmZsaWN0czogJXtrZXJuZWxfY29uZmxpY3RzfQoKCiVkZXNjcmlwdGlvbiBlbnRlcnByaXNl ClRoaXMgcGFja2FnZSBpbmNsdWRlcyBhIGtlcm5lbCB0aGF0IGhhcyBhcHByb3ByaWF0ZSBj b25maWd1cmF0aW9uIG9wdGlvbnMKZW5hYmxlZCBmb3IgUGVudGl1bSBJSUkgbWFjaGluZXMg d2l0aCA0IEdpZ2FieXRlIG9mIG1lbW9yeSBvciBtb3JlLgoKJXBhY2thZ2UgZGVidWcKU3Vt bWFyeTogVGhlIExpbnV4IEtlcm5lbCBjb21waWxlZCB3aXRoIG9wdGlvbnMgZm9yIGtlcm5l bCBkZWJ1Z2dpbmcKR3JvdXA6IFN5c3RlbSBFbnZpcm9ubWVudC9LZXJuZWwKUHJvdmlkZXM6 IG1vZHVsZS1pbmZvLCBrZXJuZWwgPSAle3ZlcnNpb259LCBrZXJuZWwtZHJtID0gJXtkcm12 ZXJ9ClByZXJlcTogJXtrZXJuZWxfcHJlcmVxfQpDb25mbGljdHM6ICV7a2VybmVsX2NvbmZs aWN0c30KCgolZGVzY3JpcHRpb24gZGVidWcgClRoaXMgcGFja2FnZSBpbmNsdWRlcyBhIGtl cm5lbCB0aGF0IGhhcyB0aGUgSUtECmtlcm5lbCBwYXRjaCBidWlsdCBpbiBhbmQgaGFzIHNl dmVyYWwgb3RoZXIga2VybmVsIGRlYnVnZ2luZwpzZXR0aW5ncyBlbmFibGVkLgoKJXBhY2th Z2UgQk9PVApTdW1tYXJ5OiBUaGUgdmVyc2lvbiBvZiB0aGUgTGludXgga2VybmVsIHVzZWQg b24gaW5zdGFsbGF0aW9uIGJvb3QgZGlza3MuCkdyb3VwOiBTeXN0ZW0gRW52aXJvbm1lbnQv S2VybmVsClByb3ZpZGVzOiBrZXJuZWwgPSAle3ZlcnNpb259ClByZXJlcTogJXtCT09UX2tl cm5lbF9wcmVyZXF9CkNvbmZsaWN0czogJXtrZXJuZWxfY29uZmxpY3RzfQoKJWRlc2NyaXB0 aW9uIEJPT1QKVGhpcyBwYWNrYWdlIGluY2x1ZGVzIGEgdHJpbW1lZCBkb3duIHZlcnNpb24g b2YgdGhlIExpbnV4IGtlcm5lbC4KVGhpcyBrZXJuZWwgaXMgdXNlZCBvbiB0aGUgaW5zdGFs bGF0aW9uIGJvb3QgZGlza3Mgb25seSBhbmQgc2hvdWxkIG5vdApiZSB1c2VkIGZvciBhbiBp bnN0YWxsZWQgc3lzdGVtLCBhcyBtYW55IGZlYXR1cmVzIGluIHRoaXMga2VybmVsIGFyZQp0 dXJuZWQgb2ZmIGJlY2F1c2Ugb2YgdGhlIHNpemUgY29uc3RyYWludHMuCgolcGFja2FnZSBC T09Uc21wClN1bW1hcnk6IFRoZSBMaW51eCBrZXJuZWwgdXNlZCBvbiBpbnN0YWxsYXRpb24g Ym9vdCBkaXNrcyBmb3IgU01QIG1hY2hpbmVzLgpHcm91cDogU3lzdGVtIEVudmlyb25tZW50 L0tlcm5lbApQcm92aWRlczoga2VybmVsID0gJXt2ZXJzaW9ufQpQcmVyZXE6ICV7Qk9PVF9r ZXJuZWxfcHJlcmVxfQpDb25mbGljdHM6ICV7a2VybmVsX2NvbmZsaWN0c30KCiVkZXNjcmlw dGlvbiBCT09Uc21wClRoaXMgcGFja2FnZSBpbmNsdWRlcyBhIHRyaW1tZWQgZG93biB2ZXJz aW9uIG9mIHRoZSBMaW51eCBrZXJuZWwuIFRoaXMKa2VybmVsIGlzIHVzZWQgb24gdGhlIGlu c3RhbGxhdGlvbiBib290IGRpc2tzIG9ubHkgYW5kIHNob3VsZCBub3QgYmUgdXNlZApmb3Ig YW4gaW5zdGFsbGVkIHN5c3RlbSwgYXMgbWFueSBmZWF0dXJlcyBpbiB0aGlzIGtlcm5lbCBh cmUgdHVybmVkIG9mZgpiZWNhdXNlIG9mIHRoZSBzaXplIGNvbnN0cmFpbnRzLiBUaGlzIGtl cm5lbCBpcyB1c2VkIHdoZW4gYm9vdGluZyBTTVAKbWFjaGluZXMgdGhhdCBoYXZlIHRyb3Vi bGUgY29taW5nIHVwIHRvIGxpZmUgd2l0aCB0aGUgdW5pcHJvY2Vzc29yIGtlcm5lbC4KCiVw YWNrYWdlIGplbnNlbgpTdW1tYXJ5OiBUaGUgTGludXggS2VybmVsIGNvbXBpbGVkIGZvciB0 aGUgQWxwaGEgSmVuc2VuIHBsYXRmb3JtLgpHcm91cDogU3lzdGVtIEVudmlyb25tZW50L0tl cm5lbApQcm92aWRlczoga2VybmVsID0gJXt2ZXJzaW9ufQpQcmVyZXE6ICV7a2VybmVsX3By ZXJlcX0KQ29uZmxpY3RzOiAle2tlcm5lbF9jb25mbGljdHN9CgolZGVzY3JpcHRpb24gamVu c2VuClRoaXMgcGFja2FnZSBpbmNsdWRlcyBhIGtlcm5lbCB0aGF0IGhhcyBhcHByb3ByaWF0 ZSBjb25maWd1cmF0aW9uCm9wdGlvbnMgZW5hYmxlZCBmb3IgdXNlIG9uIHRoZSBBbHBoYSBK ZW5zZW4gcGxhdGZvcm0uICBUaGUgSmVuc2VuCnBsYXRmb3JtIGlzIG5vdCBzdXBwb3J0ZWQg aW4gdGhlIG5vcm1hbCBnZW5lcmljIGFscGhhIGtlcm5lbCBzdXBwb3J0LgoKJXBhY2thZ2Ug dGFwZQpTdW1tYXJ5OiBUaGUgTGludXggS2VybmVsIGNvbXBpbGVkIGZvciBib290aW5nIGZy b20gdGFwZQpHcm91cDogU3lzdGVtIEVudmlyb25tZW50L0tlcm5lbApQcm92aWRlczoga2Vy bmVsID0gJXt2ZXJzaW9ufQpQcmVyZXE6ICV7a2VybmVsX3ByZXJlcX0KQ29uZmxpY3RzOiAl e2tlcm5lbF9jb25mbGljdHN9CgolZGVzY3JpcHRpb24gdGFwZQpUaGlzIHBhY2thZ2UgaW5j bHVkZXMgYSBrZXJuZWwgdGhhdCBoYXMgYXBwcm9wcmlhdGUgY29uZmlndXJhdGlvbgpvcHRp b25zIGVuYWJsZWQgZm9yIGJvb3RpbmcgZnJvbSB0YXBlLgoKJXBhY2thZ2UgQk9PVHRhcGUK U3VtbWFyeTogVGhlIHZlcnNpb24gb2YgdGhlIExpbnV4IGtlcm5lbCB1c2VkIG9uIGluc3Rh bGxhdGlvbiBib290IHRhcGVzLgpHcm91cDogU3lzdGVtIEVudmlyb25tZW50L0tlcm5lbApQ cm92aWRlczoga2VybmVsID0gJXt2ZXJzaW9ufQpQcmVyZXE6ICV7Qk9PVF9rZXJuZWxfcHJl cmVxfQpDb25mbGljdHM6ICV7a2VybmVsX2NvbmZsaWN0c30KCiVkZXNjcmlwdGlvbiBCT09U dGFwZQpUaGlzIHBhY2thZ2UgaW5jbHVkZXMgYSBrZXJuZWwgdGhhdCBoYXMgYXBwcm9wcmlh dGUgY29uZmlndXJhdGlvbgpvcHRpb25zIGVuYWJsZWQgZm9yIGJvb3RpbmcgZnJvbSB0YXBl LgoKCiVwcmVwCgolc2V0dXAgLXEgLW4gJXtuYW1lfS0le3ZlcnNpb259IC1jCmNkIGxpbnV4 CgojCiMgUGF0Y2hlcyAwIHRocm91Z2ggMTAwIGFyZSBtZWFudCBmb3IgY29yZSBzdWJzeXN0 ZW0gdXBncmFkZXMKIyAKCiMgLWFjWCBwYXRjaAolcGF0Y2gxIC1wMQoKCiMgCiMgUGF0Y2hl cyAxMDAgdGhyb3VnaCA0MDAgYXJlIGFyY2hpdGVjdHVyZSBzcGVjaWZpYyBwYXRjaGVzCiMg RWFjaCBhcmNoaXRlY3R1cmUgaGFzIDIwIHNsb3RzIHJlc2VydmVkLgojCgojIElBNjQKJWlm YXJjaCBpYTY0CiMgYmFzZSBpYTY0IHBhdGNoIGZyb20gRGF2aWQgTW9zYmVyZ2VyCiVwYXRj aDEwMCAtcDEKJXBhdGNoMTAxIC1wMQolcGF0Y2gxMDIgLXAxCiVwYXRjaDEwNCAtcDEKJXBh dGNoMTA1IC1wMQolcGF0Y2gxMDYgLXAxCiVwYXRjaDEwNyAtcDEKJXBhdGNoMTA4IC1wMQol cGF0Y2gxMDkgLXAxCiVwYXRjaDExMCAtcDEKJXBhdGNoMTExIC1wMQolcGF0Y2gxMTIgLXAx CiVwYXRjaDExMyAtcDEKJWVuZGlmCgojIEFscGhhCgojIGZpeCBzb21lIGluY2x1ZGUgZmls ZXMKJXBhdGNoMTIwIC1wMQolcGF0Y2gxMjEgLXAxCiVwYXRjaDEyMiAtcDEKIyBNaXNzaW5n IHNtcF9jYWxsX2Z1bmN0aW9uIEVYUE9SVCBmb3IgYWxwaGEKJXBhdGNoMTIzIC1wMQojIEFs cGhhIE5hdXRpbHVzIHBhdGNoCiVwYXRjaDEyNCAtcDEKIyBleHBvcnRzIHJldmlzdGVkCiVw YXRjaDEyNSAtcDEKCgojIFNwYXJjIC8gU3BhcmM2NAoKJXBhdGNoMTQwIC1wMQoKIyB4ODYK IyB3b3JrIGFyb3VuZCBicm9rZW4gTVAgdGFibGVzIGZyb20gYmlvc2VzCiVwYXRjaDE2MCAt cDEKCiMgcHBjCiMgbWFrZSB0aGUgcHBjIHRyZWUgYnVpbGQKJXBhdGNoMTgxIC1wMQojIGZp eCBwY25ldDMyIHByb2JsZW0gc2VlbiBvbiBwU2VyaWVzCiVwYXRjaDE4MyAtcDEKIyBtYWtl IHRoZSAyLjQuOS1hYzEwIHBhdGNoIGJ1aWxkCiVwYXRjaDE4NCAtcDEKJWlmYXJjaCAle2Fs bF9wcGN9CiVwYXRjaDE4NSAtcDEKIyBtYWtlIHRoZSBwcGM2NCBwYXRjaCBidWlsZCB3aXRo IFJlZCBIYXQgTGludXggc3BlY2lmaWMgbW9kcwolcGF0Y2gxODYgLXAxCiVlbmRpZgoKIyBz MzkwCiMKJWlmYXJjaCBzMzkwIHMzOTB4CiMgbW9kaWZpY2F0aW9ucyBiYWNrcG9ydGVkIGZy b20gMi40LjlhYzE0CiVwYXRjaDIwMCAtcDEKIyBtb2RpZmljYXRpb25zIHRoYXQgYXJlIFJl ZCBIYXQgTGludXggc3BlY2lmaWMgb3IgZnJvbSBzMzkwLTEKJXBhdGNoMjA1IC1wMQojIG5v bi13b3JraW5nIHBhdGNoCiMlcGF0Y2gyMDYgLXAxCiVwYXRjaDIwNyAtcDEKIyBpbnRlZ3Jh dGVkIGluIG9mZmljaWFsIElCTS0zCiMgJXBhdGNoMjA4IC1wMQolcGF0Y2gyMDkgLXAxCiVw YXRjaDIxMCAtcDEKIyVwYXRjaDIxMSAtcDEgaXMgbm93IDkyNQolcGF0Y2gyMTIgLXAxCiVw YXRjaDIxMyAtcDEKJXBhdGNoMjE0IC1wMQojIHRoZXJlIGlzIGlzZG4vZnNtLmMgYWxyZWFk eQpbIC1mIGRyaXZlcnMvczM5MC9uZXQvZnNtLmMgXSAmJiBtdiBkcml2ZXJzL3MzOTAvbmV0 L2ZzbS5jIGRyaXZlcnMvczM5MC9uZXQvZnNtLXMzOTAuYwolcGF0Y2gyMTUgLXAxCiVwYXRj aDIxNiAtcDEKIyAyMTcgaXMgaW4gMjE4CiMlcGF0Y2gyMTcgLXAxCiVwYXRjaDIxOCAtcDEK IyAlcGF0Y2gyMTkgLXAxICBpcyBub3cgMjMzMCAKJXBhdGNoMjIwIC1wMSAtYiAucmFtCiVw YXRjaDIyMSAtcDEgLWIgLmtlcm50eXBlcwpbIC1mIGluY2x1ZGUvYXNtLXMzOTAvZHVtcC5o IF0gfHwgZWNobyAnLyogZHVtbXkgKi8nID4gaW5jbHVkZS9hc20tczM5MC9kdW1wLmgKJXBh dGNoMjIyIC1wMSAtYiAubWVtdQojICVwYXRjaDIyMyAtcDEgLWIgLmNyYW1mcyBpcyBub3cg MjM0MAolcGF0Y2gyMjQgLXAxIC1iIC5jcGludCAKJWVuZGlmCgojCiMgUGF0Y2hlcyA0MDAg dGhyb3VnaCA1MDAgYXJlIHRoZSBUVVggcGF0Y2hlcwojCgolcGF0Y2g0MDAgLXAxCiVwYXRj aDQxMCAtcDEKJXBhdGNoNDIwIC1wMQolcGF0Y2g1NzAgLXAxCiVpZiAle3R1eH0KJXBhdGNo NDMwIC1wMQolcGF0Y2g0NDAgLXAxCiVwYXRjaDQ1MCAtcDEKJXBhdGNoNDYwIC1wMQolcGF0 Y2g0NzAgLXAxCiVwYXRjaDQ4MCAtcDEKJXBhdGNoNDkwIC1wMQolcGF0Y2g1MDAgLXAxCiVw YXRjaDUxMCAtcDEKJXBhdGNoNTMwIC1wMQolcGF0Y2g1NDAgLXAxCiVwYXRjaDU1MCAtcDEK JXBhdGNoNTYwIC1wMQolcGF0Y2g1ODAgLXAxCiVwYXRjaDU4MSAtcDEKJWVuZGlmCgoKCiMK IyBQYXRjaGVzIDYwMCB0aHJvdWdoIDEwMDAgYXJlIHJlc2VydmVkIGZvciBidWdmaXhlcyB0 byB0aGUgY29yZSBzeXN0ZW0KIyBhbmQgcGF0Y2hlcyByZWxhdGVkIHRvIGhvdyBSUE1zIGFy ZSBidWlsZAojCgoKIyBUaGlzIHBhdGNoIGFkZHMgYSAibWFrZSBvbGRjb25maWdfbm9uaW50 IiB3aGljaCBpcyBub24taW50ZXJhY3RpdmUgYW5kCiMgYWxzbyBnaXZlcyBhIGxpc3Qgb2Yg bWlzc2luZyBvcHRpb25zIGF0IHRoZSBlbmQuIFVzZWZ1bCBmb3IgYXV0b21hdGVkCiMgYnVp bGRzLgolcGF0Y2g2MDAgLXAxCiMgVGhpcyBwYXRjaCBtYWtlcyBhbGwgc2NzaSBhZGFwdGVy cyBkZWZhdWx0IHRvIDY0IHNlY3RvcnMgbWF4IHVubGVzcwojIG92ZXJyaWRlbiBieSB0aGUg YWRhcHRlciBpdHNlbGYKJXBhdGNoNjEwIC1wMQojIHByZXZlbnQgdGhlIGNkcm9tIHN1YnN5 c3RlbSBmcm9tIHByaW50aydpbmcgY2F1c2VkIGJ5IGJyb2tlbiBhdXRvcnVuIHByb2dyYW1z CiVwYXRjaDYyMCAtcDEKIyB0dHlfd3JpdGVfbWVzc2FnZSBuZWVkcyBcclxuIC0tIG1ha2Vz IHF1b3RhIG1lc3NhZ2VzIGxvb2sgbmljZXIKJXBhdGNoNjMwIC1wMQojIHNtYXJ0ZW4gbWFr ZSBvbGRjb25maWcgdG8gdXNlIHRoZSBjdXJyZW50IGtlcm5lbCBhcyBkZWZhdWx0CiVwYXRj aDY0MCAtcDEKIyBBbCBWaXJvJ3MgbG9vcGJhY2sgcGF0Y2ggCiVwYXRjaDY1MCAtcDEKIyBJ bmNyZWFzZSBwcmluayBidWZmZXIgc2l6ZSAoZHJpdmVycyBhcmUgZ2V0dGluZyBub2lzaWVy IGF0IHN0YXJ0dXApCiVwYXRjaDY2MCAtcDEKIyBDT05GSUdfU01BTEwKJXBhdGNoNjcwIC1w MQojIG11bHRpcGF0aCBSQUlECiVwYXRjaDY5MCAtcDEKIyBBZGQgYW4gaW9jdGwgdG8gdGhl IGJsb2NrIGxheWVyIHNvIHdlIGNhbiBiZSBFRkkgY29tcGxpYW50CiVwYXRjaDcwMCAtcDEK IyBBZGQgSG90cGx1ZyBQQ0kgc3VwcG9ydAolcGF0Y2g3MTAgLXAxCiVwYXRjaDcxMSAtcDEK IyBNYWtlIGkzODYgdXNlIC1tY3B1PTU4NiBmb3Igb3B0aW1pemluZwojICVwYXRjaDcyMCAt cDEKIyBTQ1NJIFJlc2V0IHBhdGNoIGZvciBjbHVzdGVyaW5nIHN0dWZmCiVwYXRjaDczMCAt cDIKIyBtYWtlIFBHRSBhbiBvcHRpb24gc28gQ3lyaXggY2hpcHMgd29yayBvbiBvdXIgNjg2 IGtlcm5lbHMKJXBhdGNoNzQwIC1wMQojIGZpeCBORlMgdG8gSVJJWCBzZXJ2ZXJzCiVwYXRj aDc1MCAtcDEKIyBmaXggbHVuIHByb2Jpbmcgb24gbXVsdGlsdW4gUkFJRCBjaGFzc2lzCiVw YXRjaDc2MCAtcDEKIyBjaXBlIDEuNC41CiVwYXRjaDc3MCAtcDEKJXBhdGNoNzcxIC1wMQoj IGlmIE9PTSBkdXJpbmcgZWFybHkgYm9vdCwgcHJpbnQgYSBoZWxwZnVsIG1lc3NhZ2UKJXBh dGNoNzgwIC1wMQojIExNLVNlbnNvcnMKJXBhdGNoNzkxIC1wMQolcGF0Y2g3OTAgLXAxCiMg YWRkIHN5c2N0bCBmb3IgdGhlIHBpZCB0byBub3RpZnkgb24gY2FkCiVwYXRjaDgwMCAtcDEK IyBGaXggcmFjZXMgaW4gc21wX2NhbGxfZnVuY3Rpb24gaWYgd2UgZ2V0IGR1cGxpY2F0ZSBJ UElzCiVwYXRjaDgxMCAtcDEKIyBzaG93IGluZm8gYWJvdXQgc3dhcCBhbGxvY2F0ZWQgYW5k IHN3YXAgdXNlZCBpbiAvcHJvYwojIyVwYXRjaDgyMCAtcDEKIyBkb24ndCBhbGxvY2F0ZSBo aWdobWVtIHBhZ2VzIG9uIG5vbi1oaWdobWVtIG1hY2hpbmVzCiVwYXRjaDgzMCAtcDEKIyBw YXJwb3J0IHBucCBtaXNzaW5nIGlmZGVmCiVwYXRjaDg0MSAtcDEKIyBjaGFuZ2UgZnJvbSA4 IHRvIDMyIGF2YWlsYWJsZSBzd2FwIGFyZWFzCiVwYXRjaDg1MCAtcDEKIyB3b3JrYXJvdW5k IHRyaWdnZXJoYXBweSBPT00ga2lsbGVyCiMlcGF0Y2g4NjAgLXAxCiMgSmVucyBBeGJvZXMg aGlnaG1lbSBJTyBwYXRjaAolaWZhcmNoICV7YWxsX3g4Nn0gaWE2NCAle2FsbF9wcGN9CiVw YXRjaDg3MCAtcDEKJWVuZGlmCiMgcGF0Y2ggdG8gdHJpcGxlX2Rvd24KJXBhdGNoODgwIC1w MQojIG1ha2Ugb29tIGtpbGxlciBsZXNzIHRyaWdnZXIgaGFwcHkgKGhhY2spCiVwYXRjaDg5 MCAtcDEKIyBiYWNrb3V0IHRoZSAtYWMxMCBnZW5kaXNrIGNoYW5nZXM7IHRoZXkganVzdCBk b24ndCB3b3JrIHJpZ2h0CiVwYXRjaDkwMCAtcDEKIyBra3N5bW9vcHMgCiVwYXRjaDkxMCAt cDEKJWlmYXJjaCAle2FsbF94ODZ9CiVwYXRjaDkxMSAtcDEKJWVuZGlmCiMgZml4IGVsZXZh dG9yIGhhbmcKJXBhdGNoOTIwIC1wMQojIHJlYWwtcm9vdC1kZXYgZm9yIGluaXRyZCAobm90 IHMzOTAgYW55bW9yZSkKJXBhdGNoOTI1IC1wMQojIEFkZCAvcHJvYy9zeXMva2VybmVsL3Rh aW50ZWQgKEtlaXRoIE93ZW5zKQolcGF0Y2g5MzAgLXAxCiMgZml4IHNvbWUgb2YgdGhlIDIu NC43IFZNIHVwCiVwYXRjaDk0MCAtcDEKIyBSaWsncyBWTSB0dW5pbmcKJXBhdGNoOTUwIC1w MQojIGltcHJvdmUgSU8gcGVyZm9ybWFuY2Ugb24gaGlnaG1lbSBtYWNoaW5lcwolcGF0Y2g5 NjAgLXAxCiMgZml4IHJzcyBhY2NvdW50aW5nCiVwYXRjaDk3MCAtcDEKIyBpbXByb3ZlcyBT TVAgYWZmaW5pdHkgc2NoZWR1bGVyCiVwYXRjaDk4MCAtcDEKIyBmaXhlcyBhIHJhY2Ugd2l0 aCBwYWdlX2RpcnR5KCkgaW4gcGFnZV9sYXVuZGVyCiVwYXRjaDk5MCAtcDEKCgoKCgojCiMg UGF0Y2hlcyAxMDAwIHRvIDUwMDAgYXJlIHJlc2VydmVkIGZvciBidWdmaXhlcyB0byBkcml2 ZXJzIGFuZCBmaWxlc3lzdGVtcwojCiMgYWRkICNpZmRlZiBfX0tFUk5FTF9fIGFyb3VuZCBp bmNsdWRlZmlsZXMgZm9yIGRpZXRsaWJjCiVwYXRjaDEwMDAgLXAxCiMgYWRkIHNwaW5sb2Nr cyB0byBjcmFtZnMgZGVjb21wcmVzc2lvbiBmb3IgU01QIG9wZXJhdGlvbgolcGF0Y2gxMDEw IC1wMQojIGFkZCBtaXNzaW5nIHN5bWJvbCBleHBvcnQKJXBhdGNoMTAyMCAtcDEgCiMgcWxh MTI4MCB1cGRhdGUgdG8gMy4yM0JldGEKJXBhdGNoMTAzMCAtcDEKIyBzeW1iaW9zIDUzYzd4 eHggNjQtYml0IHBhdGNoCiMgb2Jzb2xldGVkIGJ5IEplbnMgcGF0Y2gKIyMlcGF0Y2gxMDQw IC1wMQojIGFkZCB2aWRmYWlsIGNhcGFiaWxpdHkKJXBhdGNoMTA4MCAtcDEKIyBhZGQgZTgy MCByZXBvcnRpbmcKJXBhdGNoMTA5MCAtcDEKIyByYWlkNSB4b3IgZml4IGZvciBQSUlJL1A0 LCBzaG91bGQgZ28gYXdheSBzaG9ydGx5CiVwYXRjaDExMDAgLXAxCiMgbWVtPSBjb21tYW5k LWxpbmUgYWRhcHRzIGl0c2VsZiB0byBleGlzdGluZyBlODIwIHZhbHVlcy4KIyBQcmV2aW91 cyB2ZXJzaW9uIGZhaWxlZCBvbiBjb21wYXFzIHdpdGggYnJva2VuIGJpb3NlcywgbmVlZHMg dGVzdGluZyBub3cKJXBhdGNoMTExMCAtcDEKIyBjb25zZXJ2YXRpdmUgem9uZSBiaXRtYXBz IHRvIHByZXZlbnQgbWVtb3J5IGNvcnJ1cHRpb24KJXBhdGNoMTEyMCAtcDEKIyBTaWxlbmNl IHRoZSBBUElDIGVycm9ycyBhIGJpdAolcGF0Y2gxMTMwIC1wMQojIExvbmdlciBzZXR1cF9k ZWxheSBmb3IgY2FyZGJ1cwolcGF0Y2gxMTQwIC1wMQojIFVTQiB1aGNpIHNsYWIgZml4CiVw YXRjaDExNTAgLXAxCiMgbG90cyBvZiBmaXhlcyB0byB0aGUgaTgxMF9hdWRpbyBkcml2ZXIK IyVwYXRjaDExNjAgLXAxCiMgZml4IHJhd2lvCiVwYXRjaDExNzAgLXAxCiMgZml4IGk4MjM2 NCBkZWxheQolcGF0Y2gxMTgwIC1wMQojIGZvcmNlIE1QVEFCTEUgcGFyc2luZyBvbiBkZWZl Y3RpdmUgSW50ZWwgYmlvc2VzCiVwYXRjaDEyMDAgLXAxCiMgZGlzYWJsZSBzb21lIG5ldHdv cmtpbmcgcHJpbnRrJ3MKJXBhdGNoMTIyMCAtcDEKIyBmaXggZm9yIG5vbi1hdG9taWMgYml0 IGNsZWFyIGluIGVlcHJvMTAwIGRyaXZlciBvbiBhbHBoYQolcGF0Y2gxMjUwIC1wMQojIGNo YW5nZSBJUlEgcGVuYWx0eSBmb3IgSVJRIDEyCiVwYXRjaDEyNjAgLXAxCiMgaW1wcm92ZSB3 YWtlX3VwKCkgcGVyZm9ybWFuY2UKJXBhdGNoMTI3MCAtcDEKIyBNYWtlIEVDTiBkZWZhdWx0 IHRvIG9mZgolcGF0Y2gxMjgwIC1wMQojIGFkZCBrbm93biBicm9rZW4gZHJpdmVzIHRvIHRo ZSBETUEgYmxhY2tsaXN0CiMjJXBhdGNoMTI5MCAtcDEKIyBCdWcgNTExNDIgLSBKYXBhbmVz ZSBVU0Iga2V5Ym9hcmQuCiVwYXRjaDEzMTAgLXAxCiMgQnVnIDUwMjE4IC0gVVNCIHByaW50 ZXIgcHJvYmluZyBmb3IgSFAtMTIwMC4KJXBhdGNoMTMyMCAtcDEKIyBFbmhhbmNlbWVudCBm b3IgdGhlIHVzYiBzY3NpZ2x1ZSBmb3Igb290J3MgaW5zdGFsbGVyIG1hZ2ljCiVwYXRjaDEz MzAgLXAxCiMgU2lsZW5jZSB0aGUgUFMvMiBjb2RlIGZvciBVU0Iga2V5Ym9hcmRzCiVwYXRj aDEzNDAgLXAxCiMgZml4IGJyb2tlbiA0NDBHWCBjaGlwc2V0IGJvYXJkcy9iaW9zZXMKJXBh dGNoMTM1MCAtcDEKIyBkaXNhYmxlIHVkbWE2NiBmb3IgdmlhIGNoaXBzZXRzCiVwYXRjaDEz NjAgLXAxCiMgZml4IHBjbmV0MzIgbmV0d29ya2RyaXZlciBsb2FkIHZzIGlmY29uZmlnIHJh Y2VzCiVwYXRjaDEzNzAgLXAxCiMgQnVnIDMzNjY4CiVwYXRjaDEzOTAgLXAxCiMgUHJldmVu dCBvb3BzIGluIElTTyBVUkJzCiVwYXRjaDEzOTEgLXAxCiMgT25lIG1vcmUgUGVnYXN1cy4g NTc1MzEuCiVwYXRjaDEzOTUgLXAxCiMgZXh0cmEgUG5QIGlkIGZvciBzYjMyYXdlCiVwYXRj aDE0MDAgLXAxCiMgT0hDSSBJUlEgc2FuaXR5IGNoZWNrCiVwYXRjaDE0MTAgLXAxCiMgYWRk IENQVSBudW1iZXIgdG8gc3lzcnEKJXBhdGNoMTQ0MCAtcDEKIyByZXZlcnQgeGlyY29tX2Ni IHRvIG9sZCBkcml2ZXIKJXBhdGNoMTQ1MCAtcDEKIyBhbm90aGVyIHNiMTYgcG5wIGlkCiVw YXRjaDE0NzAgLXAxCiMgbW9yZSBETUkgZW50cmllcyBmb3IgcmVib290aW5nCiVwYXRjaDE0 ODAgLXAxCiMgdXBkYXRlZCBjY2lzcyBkcml2ZXIKJXBhdGNoMTUwMCAtcDEKIyBtYWtlIHRo ZSBzY3NpIHRpbWVvdXQgbG9uZ2VyIAolcGF0Y2gxNjgwIC1wMQojIGJlIG1vcmUgc3RyaWN0 IGFib3V0IHRoZSBwZGNyYWlkIHNpZ25hdHVyZQolcGF0Y2gxNzUwIC1wMQojIGFkZCBub2F0 aGxvbiBmbGFnIHRvIGJvb3Qgb24gYnJva2VuIGF0aGxvbiBtYWNoaW5lcwolcGF0Y2gxODcw IC1wMQojIHVwZGF0ZSBhdGFyYWlkIHRvIGxhdGVzdCB2ZXJzaW9uCiVwYXRjaDE4ODAgLXAx CiMgYWRkIGVsZXZhdG9yIGlvY3RscyB0byBjb21wYXEgcmFpZCBjb250cm9sbGVycwolcGF0 Y2gxODkwIC1wMQojIGZpeCBtb3VzZXR5cGUgcmVwb3J0aW5nIHRvIHVzZXJzcGFjZSAoVm9q dGVjaCBQYXZsaWspCiVwYXRjaDE5MDAgLXAxCiMgZml4IG9vcHMgaW4gbmZzCiVwYXRjaDE5 MTAgLXAxCiMgbWFrZSBmcmVldnhmcyBhdXRvbG9hZAolcGF0Y2gxOTIwIC1wMQojIDQ4Yml0 IElERSBMQkEgYWRkcmVzc2luZyBmb3IgPiAxMzZHYiBJREUgZGlza3MKIyVwYXRjaDE5MzAg LXAxCiMgYWxsb3cgc2NzaSB0byBkbyBsYXJnZSByZXF1ZXN0cwolcGF0Y2gxOTQwIC1wMQoj IGFsc28gcHJvdmlkZSB0aGUgNy4xIG5hdHNlbWkgZHJpdmVyCiVwYXRjaDE5NTAgLXAxCiMg dXBkYXRlIFNlcnZlclJBSUQgdG8gdmVyc2lvbiA0LjgwIChJQk0pCiVwYXRjaDE5NjAgLXAx CiMgZml4IGFpYzd4eHggQ09ORklHIG5hbWUgYnVncwolcGF0Y2gxOTcwIC1wMQojIGJhY2sg b3V0IGV3cmszIGRyaXZlciB0byB0aGUgMi40LjIgdmVyc2luCiVwYXRjaDE5ODAgLXAxCiMg ZGlzYWJsZSBETUEgb24gZXZlcnl0aGluZyBub3QtYS1kaXNrCiVwYXRjaDE5OTAgLXAxCiMg Zml4IGNjaXNzIGlvY3RsCiVwYXRjaDIwMDAgLXAxCiMgYWRkIEVYUE9SVF9TWU1CT0xfR1BM ICgyLjQuOS1hYzE2KQolcGF0Y2gyMDEwIC1wMQojIHVwZGF0ZSBxbGExMjgwIGRyaXZlcgol cGF0Y2gyMDIwIC1wMQojIGZpeCBBUE0gdHlwbwolcGF0Y2gyMDMwIC1wMQojIHNvbWUgbmV0 d29ya2RyaXZlciB1cGRhdGVzIGZyb20gMi40LjEwLWFjMgolcGF0Y2gyMDQwIC1wMQojIHRo aXMgcHJldmVudHMgZXhlY3V0aW5nIHZtbGludXggZnJvbSByZWJvb3RpbmcgdGhlIG1hY2hp bmUKJXBhdGNoMjA1MCAtcDEKIyBpcGMgY29kZSB1cGRhdGVzIGZyb20gMi40LjktYWMxOAol cGF0Y2gyMDYwIC1wMQojIGxvb3AgaXNlbSBidWdmaXggZnJvbSAyLjQuOS1hYzE4CiVwYXRj aDIwNzAgLXAxCiMgZml4IHdlaXJkIHJhZGVvbiBoYW5nIChmcm9tIDIuNC45LWFjMTgpCiVw YXRjaDIwODAgLXAxCiMgYmFjayBvdXQgdG8gb2xkIGVtdTEwayBkcml2ZXI7IG5ldyBvbmUg aGFzIHRvbyBtYW55IHByb2JsZW1zCiVwYXRjaDIwOTAgLXAxCiMgdmVyaXRhcyBtaWdodCBz dGlsbCBuZWVkIHRoaXMgcGF0Y2ggZm9yIHRoZWlyIGZpbGVzeXN0ZW0KJXBhdGNoMjEwMCAt cDEKIyBtYWtlIHB0cmFjZSB3b3JrIGFnYWluICgyLjQuMTAtYWM3KQolcGF0Y2gyMTEwIC1w MQojIHVwZGF0ZWQgTkZTIGNvZGUgKDIuNC4xMC1hYzcpCiVwYXRjaDIxMjAgLXAxCiMgcXVv dGEncyBvbiBxdW90YSBmaWxlcyBhcmUgYmFkIHZvb2RvbyAoMi40LjE5LWFjOCkKJXBhdGNo MjEzMCAtcDEKIyAzNjYyOCBJL08gZXJyb3IgcmVhZGluZyBIUCBDb2xvcmFkbyA1R0IgdGFw ZSBkcml2ZQolcGF0Y2gyMTQwIC1wMQojIDQ0MEdYIGFwaWMga2VybmVsIGJ1ZyBmaXhlZAol cGF0Y2gyMTYwIC1wMQolaWZhcmNoICV7YWxsX3g4Nn0gaWE2NAojIG5ldyBtZWdhcmFpZCBk cml2ZXIgKDEuMTgpIGZyb20gTFNJCiVwYXRjaDIxNzAgLXAxCiVlbHNlCiMlcGF0Y2gyMTcx IC1wMQolZW5kaWYKJWlmYXJjaCAle2FsbF94ODZ9IGlhNjQgJXthbGxfcHBjfQojIHVwZGF0 ZWQgY29tcGFxIGNjaXNzIGFuZCBjcHFhcnJheSBkcml2ZXJzCiVwYXRjaDIxOTAgLXAxCiVl bmRpZgojIGRpc2FibGUgbWNlIG9uIHBlbnRpdW0gY2xhc3MgbWFjaGluZXMgKDIuNC4xMi1h YykKJXBhdGNoMjE4MCAtcDEKIyBmaXggcmFjZSBpbiB0dHkgc3dpdGNoaW5nIGNvZGUKJXBh dGNoMjIwMCAtcDEKIyBmaXggZGV2aWNlIGxvY2tpbmcgKDIuNC4xMikKJXBhdGNoMjIxMCAt cDEKIyBleHBvcnQgVGlkIHRvIHVzZXJzcGFjZQolcGF0Y2gyMjIwIC1wMQojIGZpeCAvcHJv Yy9tb3VudHMgb3ZlcmZsb3cgZm9yIGxvdHMgb2YgbW91bnRzCiMlcGF0Y2gyMjMwIC1wMQoj IGRvbid0IG1lbHQgUGVudGl1bSBJViBjcHUncyB3aXRoIGJ1c3kgd2FpdGluZyBsb29wcwol aWZhcmNoICV7YWxsX3g4Nn0KJXBhdGNoMjI0MCAtcDEKJWVuZGlmCiMgZml4IHVwIGFmdGVy IGJ1Z2d5IGF0aGxvbiBiaW9zZXMgdGhhdCBtYWtlIHRoZSBhdGhsb24ga2VybmVsIGNyYXNo CiVwYXRjaDIyNTAgLXAxCiMgc29tZSBtaXNzaW5nIHZvbGF0aWxlcyBpbiB0aGUgbWVnYXJh aWQgZHJpdmVyCiVwYXRjaDIyNjAgLXAxCiMgcGF0Y2hlcyBmb3IgSW50ZWwncyBIeXBlcnRo cmVhZGluZyB0ZWNobm9sb2d5CiVwYXRjaDIyNzAgLXAxCiMgcG93ZXIgZG93biB0aGUgcGNt Y2lhIHNvY2tldCBvbiByZW1vdmUKJXBhdGNoMjI4MCAtcDEKIyBhY3BpIHRhYmxlIHJlYWRl ciBhbmQgSUJNIFN1bW1pdCBwYXRjaGVzCiVwYXRjaDIyOTAgLXAxCiMjJXBhdGNoMjI5MSAt cDEKIyBpZGUgZmxvcHB5IGZpeCBmb3IgdmlhICgjNTY2MTMpCiVwYXRjaDIzMDAgLXAxCiMg VURGIHVwZGF0ZSB0byAwLjkuNSAKIyMlcGF0Y2gyMzEwIC1wMQojIERBQzk2MCB1cGRhdGUg dG8gMi40LjExCiVpZmFyY2ggJXthbGxfeDg2fSBpYTY0ICV7YWxsX3BwY30KJXBhdGNoMjMy MCAtcDEKJWVuZGlmCiMgZml4IGRlYWRsb2NrIGluICJ0b3AiCiVwYXRjaDIzMzAgLXAxCiMg Zml4IGNyYW1mcyB0byBiZSBTTVAgc2FmZQolcGF0Y2gyMzQwIC1wMQojIGZpeCBvb3BzZXMg aW4gdGhlIHNjc2kgY29kZQolcGF0Y2gyMzUwIC1wMQojIHNodXQgbmZzIHVwIGFib3V0IHN2 YyB1bmtub3duIHZlcnNpb24gKDApID09IG5mcyBwaW5nLgolcGF0Y2gyMzYwIC1wMQojIGZp eCBpODEwIHNvdW5kIG9vcHNlcwolcGF0Y2gyMzcwIC1wMQolcGF0Y2gyMzcxIC1wMQojIHdh dGNoZG9nIG5vd2F5b3V0IG1hZGUgcnVudGltZS1jb25maWd1cmFibGUKJXBhdGNoMjM4MCAt cDEKIyBmaXggc2lnbmVkbmVzcyBtYXNrIHByb2JsZW0KJWlmYXJjaCAle2FsbF94ODZ9IGlh NjQgJXthbGxfcHBjfQolcGF0Y2gyMzkwIC1wMQolZW5kaWYKIyBmaXggcm1tb2QgaGFuZyB3 aXRoIGlwY2hhaW5zIG1vZHVsZQolcGF0Y2gyNDAwIC1wMQoKIwoKIwojIFBhdGNoZXMgNTAw MCB0byA2MDAwIGFyZSByZXNlcnZlZCBmb3IgbmV3IGRyaXZlcnMKIwojIGdlbmVyaWMgZHJp dmVycy9hZGRvbiBpbmZyYXN0cnVjdHVyZQolcGF0Y2g1MDAwIC1wMQojIGFhY3JhaWQgZHJp dmVyCiVwYXRjaDUwMTAgLXAxCiMgQnJvYWRjb20gQkNNNTcwMC81NzAxIEdpZ2FiaXQgZHJp dmVyIAolcGF0Y2g1MDIwIC1wMQolcGF0Y2g1MDIxIC1wMQojIHd2bGFuX2NzIGRyaXZlcgol cGF0Y2g1MDMwIC1wMQolcGF0Y2g1MDMxIC1wMQojIElSQy1EQ0MgbmF0IGFuZCBvdGhlciBu ZXRmaWx0ZXIgYWRkb25zCiVwYXRjaDUwNDAgLXAxCiMgRUNDIHJlcG9ydGluZyBtb2R1bGUK JXBhdGNoNTA1MCAtcDEKIyBleHQzIHVwZGF0ZQolcGF0Y2g1MDYwIC1wMQolcGF0Y2g1MDYx IC1wMQolcGF0Y2g1MDYyIC1wMQojIGFpcm9fY3MKJXBhdGNoNTA3MCAtcDEKIyBJQk0gTVhU IG1lbW9yeSBjb21wcmVzc2lvbiBzdXBwb3J0CiVwYXRjaDUwODAgLXAxCiMgZml4ZXMgLyB1 cGRhdGVzIHRvIHRoZSBNWFQgZHJpdmVyCiVwYXRjaDUwODEgLXAxCiVwYXRjaDUwODIgLXAx CiMgQnJvYWRjb20gNTgyMCBkcml2ZXIKJXBhdGNoNTA5MCAtcDEKJXBhdGNoNTA5MSAtcDEK JXBhdGNoNTA5MiAtcDEKJXBhdGNoNTA5MyAtcDEKIyBJbnRlbCBlMTAwIGRyaXZlcgolcGF0 Y2g1MTAwIC1wMQojIEludGVsIGUxMDAwIGRyaXZlcgolcGF0Y2g1MTEwIC1wMQojIGlTQ1NJ IGRyaXZlcgolcGF0Y2g1MTIwIC1wMQolcGF0Y2g1MTIxIC1wMQolcGF0Y2g1MTIyIC1wMQoj IGFkZCBldGh0b29sIHN1cHBvcnQgdG8gYSBidW5jaCBvZiB0aGUgTkVXIGRyaXZlcnMKJXBh dGNoNTEzMCAtcDEKIyBheG5ldF9jcyBmcm9tIHBjbWNpYS1jcyAzLjEuMjcKJXBhdGNoNTE1 MCAtcDEKIyBQQ0kgYnJpZGdlIGRyaXZlciBmb3Igc3VzcGVuZAolcGF0Y2g1MTYwIC1wMQoj IGFkZCBtaXNzaW5nIGF2bWExX2NzIGRyaXZlcgolcGF0Y2g1MTcwIC1wMQojIGFkZCB0dWxp cF9vbGQgZHJpdmVyICgyLjQuMyB2ZXJzaW9uKQolcGF0Y2g1MTgwIC1wMQojIFBQUCBvdmVy IEFUTSAoRFNMKSBmcm9tIEplbnMgQXhib2UKJXBhdGNoNTE5MCAtcDEKIyBBRVAgU1NMIGFj Y2VsZXJhdG9yIGRyaXZlcgolcGF0Y2g1MjAwIC1wMQojIFFMQTIyMDAvMjMwMCBkcml2ZXIK JXBhdGNoNTIxMCAtcDEKJXBhdGNoNTIxMSAtcDEKIyBVcGRhdGVkIGJ1dCBleHBlcmltZW50 YWwgZW11MTBrMSBkcml2ZXIKJXBhdGNoNTIyMCAtcDEKCgojCiMgUGF0Y2hlcyA1ODAwIHRv IDYwMDAgYXJlIHRoZSBIQS9JUFZTIHBhdGNoZXMKIwolcGF0Y2g1ODAwIC1wMQolcGF0Y2g1 ODEwIC1wMQolcGF0Y2g1ODIwIC1wMQoKIwojIFBhdGNoZXMgNjAwMCBhbmQgbGF0ZXIgYXJl IHJlc2VydmVkIGZvciAlaWYge3NvbWV0aGluZ30gcGF0Y2hlcwojCgoKIyBpYmNzCiMgTk9U RTogSUJDUyBpcyBub3Qgc3VwcG9ydGVkLCBtaWdodCBub3Qgd29yayBhdCBhbGwgCiMgYW5k IG1pZ2h0IGdvIGF3YXkgYXQgYW55IHRpbWUuCiVpZiAle2liY3N9CiVpZmFyY2ggJXthbGxf eDg2fQolcGF0Y2g2MDAwIC1wMQolZW5kaWYKJWVuZGlmCgojIGRlYnVnZ2luZyBwYXRjaGVz CiMgZXh0cmEgc2FuaXR5Y2hlY2tzIGluIGJ1ZmZlcmhhbmRsaW5nCiVpZiAle2RlYnVnZ2lu Z30KJXBhdGNoNzAwMCAtcDEKJXBhdGNoNzAyMCAtcDEKJXBhdGNoNzAzMCAtcDEKJXBhdGNo NzA0MCAtcDEKIyBEaXNhYmxlIGFuIHNtYiBkZWJ1Z2dpbmcgY2hlY2sgd2hpY2ggY29uZmxp Y3RzIHdpdGggc2xhYiBwb2lzb25pbmcKJXBhdGNoNzA1MCAtcDEKJWVsc2UKJXBhdGNoNzAx MCAtcDEKJWVuZGlmCgoKCiMKIyBmaW5hbCBzdHVmZgojCiMgU0FSRCBwYXRjaGVzIChuZWVk cyB0byBiZSBsYXRlIGJlY2F1c2UgaXQgdG91Y2hlcyBsb3RzIG9mIGRyaXZlcnMpCiVwYXRj aDEwMDAwIC1wMQolcGF0Y2gxMDAwMSAtcDEKCiMgbG90cyBvZiBzbWFsbCBmaXhlcyB0byB3 YXJuaW5ncyBhbmQgb3RoZXIgc2lsbHkgYnVncwolcGF0Y2gxMDAxMCAtcDEKCiMgR1JSUlIK JWlmYXJjaCBpYTY0CiVwYXRjaDEwMyAtcDEKJXBhdGNoMTE0IC1wMQolZW5kaWYKCgojIGFk ZCBNT0RVTEVfTElDRU5TRSB0byBhbGwgbW9kdWxlcwolcGF0Y2gxMDAyMCAtcDEKJWlmYXJj aCAle2FsbF94ODZ9CiVwYXRjaDEwMDIxIC1wMQolZW5kaWYKCiMgbnM4MzgyMCAwLjE1IHVw ZGF0ZQolcGF0Y2gxMDAzMCAtcDEKCiMgRmluYWxseS4uLiBYRlMKIyBObyBsdm0gY2hhbmdl cyBoZXJlCiVwYXRjaDIwMDAwIC1wMQogCiMgQnJpbmcgbHZtIHVwIHRvIDEuMC4xcmM0IHcv IHhmcyBob29rcwolcGF0Y2gyMDAwMSAtcDEKIAojIEZpeCB1cCB4ZnMgaWYgdHV4IGZ1dHpl ZCB3aXRoIHRoZSBwYWdlY2FjaGUKJWlmICV7dHV4fQolcGF0Y2gyMDAwMiAtcDEKJWVuZGlm CiAKIyBpbnRlcm1lenpvCiVwYXRjaDIwMDAzIC1wMQogCiNrZGIKJXBhdGNoMjAwMDQgLXAx CiAKI2JjbSBiemVybyBwcm9ibGVtcwolcGF0Y2gyMDAwNSAtcDEKIAojbWlzYyBuZnNkIGZp eGVzCiVwYXRjaDIwMDA2IC1wMAoKY2htb2QgK3ggYXJjaC9zcGFyYyova2VybmVsL2NoZWNr X2FzbS5zaAoKbWtkaXIgY29uZmlncwolaWZhcmNoICV7YWxsX3g4Nn0KY3AgLWZ2ICRSUE1f U09VUkNFX0RJUi9rZXJuZWwtJXtrdmVyc2lvbn0taT84NiouY29uZmlnIGNvbmZpZ3MKY3Ag LWZ2ICRSUE1fU09VUkNFX0RJUi9rZXJuZWwtJXtrdmVyc2lvbn0tYXRobG9uKi5jb25maWcg Y29uZmlncwolZWxzZQolaWZhcmNoIHNwYXJjIHNwYXJjNjQKY3AgLWZ2ICRSUE1fU09VUkNF X0RJUi9rZXJuZWwtJXtrdmVyc2lvbn0tc3BhcmMqLmNvbmZpZyBjb25maWdzCiVlbHNlCiVp ZmFyY2ggJXthbGxfcHBjfQpjcCAtZnYgJFJQTV9TT1VSQ0VfRElSL2tlcm5lbC0le2t2ZXJz aW9ufS1wcGMqLmNvbmZpZyBjb25maWdzCiVlbHNlCmNwIC1mdiAkUlBNX1NPVVJDRV9ESVIv a2VybmVsLSV7a3ZlcnNpb259LSV7X3RhcmdldF9jcHV9Ki5jb25maWcgY29uZmlncwolZW5k aWYKJWVuZGlmCiVlbmRpZgoKIyBtYWtlIHN1cmUgdGhlIGtlcm5lbCBoYXMgdGhlIHN1Ymxl dmVsIHdlIGtub3cgaXQgaGFzLi4uCnBlcmwgLXAgLWkgLWUgInMvXlNVQkxFVkVMLiovU1VC TEVWRUwgPSAle3N1YmxldmVsfS8iIE1ha2VmaWxlCgojIGdldCByaWQgb2YgdW53YW50ZWQg ZmlsZXMKZmluZCAuIC1uYW1lICIqLm9yaWciIC1leGVjIHJtIC1mdiB7fSBcOwpmaW5kIC4g LW5hbWUgIip+IiAtZXhlYyBybSAtZnYge30gXDsKCmNobW9kIDc1NSBhcmNoLyova2VybmVs L2NoZWNrX2FzbS5zaAoKIyMjCiMjIyBidWlsZAojIyMKJWJ1aWxkCgojIGRmIGhhcyBhIGZl dyBwZWN1bGlhcml0aWVzIHdlIGhhdmUgdG8gZGVhbCB3aXRoIGhlcmU6CiMgIG8gIElmIGl0 IGNhbid0IGZpbmQgdGhlIHBhcnRpdGlvbiwgaXQgY2FsbHMgaXQgIi0iCiMgIG8gIElmIHRo ZSBkZXZpY2UgbmFtZSBpcyB0b28gbG9uZyAoZS5nLiBsb29wYmFjayBmaWxlKQojICAgICBp dCBwdXRzIGl0IG9uIGEgc2VwYXJhdGUgbGluZSBmcm9tIHRoZSBkYXRhCnBhcnRpdGlvbm9m ICgpCnsKICAgICMgZmluZCB0aGUgZGlyZWN0b3J5IHRoYXQgZXhpc3RzCiAgICBpZiBbIC1k ICIkMSIgXSA7IHRoZW4KCWRmICIkMSIgfCBhd2sgJy9eXC8vIHtwcmludCAkMX0nCiAgICBl bHNlCglwYXJ0aXRpb25vZiAkKGRpcm5hbWUgLyQxKQogICAgZmkKfQpzcGFjZW9mICgpCnsK ICAgIGVjaG8gJCgoJChkZiAkKHBhcnRpdGlvbm9mICQxKSB8IGF3ayAnL15cLy8ge2lmICgk NCkge3ByaW50ICQ0fX0KICAgICAgICAgICAgICAvXlsgXHRdLyB7cHJpbnQgJDN9JykgLyAx MDI0KSkKfQojIElmIGRmIGV4aXN0cyBhbmQgZGYgdW5kZXJzdGFuZHMgdGhlIGN1cnJlbnQg cm9vdCBkaXJlY3RvcnksIGNoZWNrCiMgc3BhY2UgZ3Vlc3RpbWF0ZXMuICAoZGYgbWF5IG5v dCBncm9rIC8gZm9yIHNvbWUgY2hyb290ZWQgYnVpbGQgZW52cykKaWYgWyAteCAvYmluL2Rm IF0gJiYgWyAkKHBhcnRpdGlvbm9mIC8pICE9IC0gXSA7IHRoZW4KICAgIGlmIFsgIiQocGFy dGl0aW9ub2YgJFJQTV9CVUlMRF9ST09UKSIgPSAiJChwYXJ0aXRpb25vZiAkUlBNX0JVSUxE X0RJUikiIF0gOyB0aGVuCgkjIFRoZSBidWlsZCByb290IGFuZCBidWlsZCBkaXIgYXJlIG9u IG9uZSBwYXJ0aXRpb247IG5lZWQgdG8gY2hlY2sKCSMgdGhlbSB0b2dldGhlcgoJWyAiJCgo JChzcGFjZW9mICRSUE1fQlVJTERfUk9PVCkpKSIgLWx0IFwKCSAgIiQoKCV7UlBNX0JVSUxE X1JPT1Rfc3BhY2V9ICsgJXtSUE1fQlVJTERfRElSX3NwYWNlfSkpIiBdICYmIHsKCSAgICBl Y2hvICJpbnN1ZmZpY2llbnQgZnJlZSBkaXNrIHNwYWNlIHRvIGJ1aWxkIiA+JjIgOwoJICAg IGV4aXQgMSA7Cgl9CiAgICBlbHNlCgkjIFRoZSBidWlsZCByb290IGFuZCBidWlsZCBkaXIg YXJlIG9uIHNlcGFyYXRlIHBhcnRpdGlvbnM7IG5lZWQgdG8KCSMgY2hlY2sgdGhlbSBzZXBh cmF0ZWx5CglbICIkKHNwYWNlb2YgJFJQTV9CVUlMRF9ST09UKSIgLWx0ICIle1JQTV9CVUlM RF9ST09UX3NwYWNlfSIgXSAmJiB7CgkgICAgZWNobyAiYnVpbGQgcm9vdCAkUlBNX0JVSUxE X1JPT1QgaGFzIGluc3VmZmljaWVudCBmcmVlIGRpc2sgc3BhY2UiID4mMiA7CgkgICAgZXhp dCAxIDsKCX0KCVsgIiQoc3BhY2VvZiAkUlBNX0JVSUxEX0RJUikiIC1sdCAiJXtSUE1fQlVJ TERfRElSX3NwYWNlfSIgXSAmJiB7CgkgICAgZWNobyAiYnVpbGQgZGlyICRSUE1fQlVJTERf RElSIGhhcyBpbnN1ZmZpY2llbnQgZnJlZSBkaXNrIHNwYWNlIiA+JjIgOwoJICAgIGV4aXQg MSA7Cgl9CiAgICBmaQpmaQoKIyBpZiBSUE1fQlVJTERfTkNQVVMgdW5zZXQsIHNldCBpdApp ZiBbIC16ICIkUlBNX0JVSUxEX05DUFVTIiBdIDsgdGhlbgogICAgUlBNX0JVSUxEX05DUFVT PWBlZ3JlcCAtYyAiXmNwdVswLTldKyIgL3Byb2Mvc3RhdCB8fCA6YCAKICAgIGlmIFsgJFJQ TV9CVUlMRF9OQ1BVUyAtZXEgMCBdIDsgdGhlbgoJUlBNX0JVSUxEX05DUFVTPTEKICAgIGZp CiAgICBpZiBbICRSUE1fQlVJTERfTkNQVVMgLWd0IDQgXSA7IHRoZW4KCVJQTV9CVUlMRF9O Q1BVUz00CiAgICBmaQpmaQoKCmNkIGxpbnV4CgpjYXQgPiBnZW5rZXkgPDxFT0YKJXB1YnJp bmcgYHB3ZGAva2VybmVsLnB1Ygolc2VjcmluZyBgcHdkYC9rZXJuZWwuc2VjCktleS1UeXBl OiBEU0EKS2V5LUxlbmd0aDogNTEyCk5hbWUtUmVhbDogUmVkIEhhdCwgSW5jLgpOYW1lLUNv bW1lbnQ6IEtlcm5lbCBNb2R1bGUgR1BHIGtleQolY29tbWl0CkVPRgoKQWRkUGF0Y2hlcyAo KSB7CiAgICAjICQxIGlzIEJPT1QvZW50ZXJwcmlzZS9kZWJ1Zy9mb28KICAgIGNhc2UgIiQx IiBpbgogICAgZGVidWcpIHBhdGNoIC1wMSA8ICRSUE1fU09VUkNFX0RJUi9saW51eC0yLjQu Ny1pa2QucGF0Y2ggOzsKICAgIGVzYWMKICAgICMgcmVtb3ZlIGFueSBiYWNrdXAgZmlsZXMg dGhhdCB3ZXJlIGNyZWF0ZWQKICAgIGZpbmQgLiAtbmFtZSAiKi5vcmlnIiAtZXhlYyBybSAt ZnYge30gXDsKICAgIGZpbmQgLiAtbmFtZSAiKn4iIC1leGVjIHJtIC1mdiB7fSBcOwp9CgpS ZW1vdmVQYXRjaGVzICgpIHsKICAgICMgJDEgaXMgQk9PVC9lbnRlcnByaXNlL2RlYnVnL2Zv bwogICAgY2FzZSAiJDEiIGluCiAgICBkZWJ1ZykgcGF0Y2ggLXAxIC1SIDwgJFJQTV9TT1VS Q0VfRElSL2xpbnV4LTIuNC43LWlrZC5wYXRjaCA7OwogICAgZXNhYwogICAgIyByZW1vdmUg YW55IGJhY2t1cCBmaWxlcyB0aGF0IHdlcmUgY3JlYXRlZAogICAgZmluZCAuIC1uYW1lICIq Lm9yaWciIC1leGVjIHJtIC1mdiB7fSBcOwogICAgZmluZCAuIC1uYW1lICIqfiIgLWV4ZWMg cm0gLWZ2IHt9IFw7Cn0KCkRlcGVuZEtlcm5lbCgpIHsKICAgICMgaXMgdGhpcyBhIHNwZWNp YWwga2VybmVsIHdlIHdhbnQgdG8gYnVpbGQ/CiAgICBpZiBbIC1uICIkMiIgXSA7IHRoZW4K CUNvbmZpZz0kMS0kMgoJS2VybmVsVmVyPSV7dmVyc2lvbn0tJXtyZWxlYXNlfSQyCgllY2hv IE1BS0UgREVQRU5EIEZPUiAkMiAkMSBLRVJORUwuLi4KICAgIGVsc2UKCUNvbmZpZz0kMQoJ S2VybmVsVmVyPSV7dmVyc2lvbn0tJXtyZWxlYXNlfQoJZWNobyBNQUtFIERFUEVORCBGT1Ig dXAgJDEgS0VSTkVMLi4uCiAgICBmaQogICAgbWFrZSAtcyBtcnByb3BlcgojIFdlIHVzZWQg dG8gY29weSB0aGUgY29uZmlnIGZpbGUgdG8gYXJjaC8uLi4vZGVmY29uZmlnLCBidXQgZm9y IHNvbWUgdGltZSBub3cKIyB0aGUgQ29uZmlndXJlIHNjcmlwdCBoYXMgYmVlbiBzbWFydCBl bm91Z2ggdG8gb3ZlcnJpZGUgdGhpcyB3aXRoIHRoZQojIGNvbmZpZyBmaWxlIGZvdW5kIGlu IGNvbmZpZ3Mva2VybmVsLSV7a3ZlcnNpb259LSR7Y29uZmlnfS5jb25maWcgd2hlbiBpdAoj IGZpbmRzIGEgdmFsaWQgL2Jvb3Qva2VybmVsLmggZmlsZS4gIEFzIGEgcmVzdWx0LCBtYWtp bmcgYW4gUlBNIG9uIGEKIyBtYWNoaW5lIHRoYXQgaGFzIGEgdmFsaWQga2VybmVsLmggZmls ZSB3aWxsIHJlc3VsdCBpbiBzY3JpcHRzL0NvbmZpZ3VyZQojIG92ZXJyaWRpbmcgb3VyIGNv bmZpZyBlbnRyaWVzIHdpdGggd2hhdGV2ZXIgaXQgdGhpbmtzIGlzIGFwcHJvcHJpYXRlCiMg KGFrYSwgaWYgeW91IHRyeSBhbiBpMzg2IGJ1aWxkIG9uIGEgbWFjaGluZSB3aXRoIGFuIGk2 ODYgc21wIGtlcm5lbC5oIGZpbGUKIyB0aGVuIHlvdSB3aWxsIGdldCBhbiBpNjg2IHNtcCBr ZXJuZWwgaW4gYW4gaTM4NiBwYWNrYWdlKS4gIFNvLCBpbnN0ZWFkIHdlCiMgcHV0IG91ciBj b25maWcgZmlsZSBpbiAuY29uZmlnLCB3aGljaCBpcyBjb25zaWRlcmVkIHRoZSB1bHRpbWF0 ZSBzb3VyY2UKIyBvZiBkZWZhdWx0IGNvbmZpZyBpbmZvcm1hdGlvbiBieSBtYWtlIG9sZGNv bmZpZy4gIEFsc28sIGNvcHkgdGhlIGNvbmZpZwojIGZpbGVzIG91dCBvZiB0aGUgY29uZmln cyBkaXJlY3RvcnkgaW5zdGVhZCBvZiB0aGUgUlBNX1NPVVJDRV9ESVIuICBJdAojIGRvZXNu J3QgbWFrZSBhbnkgc2Vuc2UgdG8gcHV0IHRoZW0gaW4gdGhlcmUgYW5kIHRoZW4gbm90IHVz ZSB0aGVtLAojIGVzcGVjaWFsbHkgd2hlbiB3ZSBjb3VsZCBoYXZlIGEgcGF0Y2ggdGhhdCBt b2RpZmllcyB0aGUgY29uZmlnIGZpbGVzCiMgYXMgcGFydCBvZiB0aGUgZW50ZXJwcmlzZSBw YXRjaCBzZXQgKG9yIGFueSBvdGhlciBwYXRjaCwgaXQganVzdCBtYWtlcwojIHVzIG1vcmUg ZmxleGlibGUgdG8gdXNlIHRoZSBjb25maWdzIGZyb20gdGhlIGNvbmZpZ3MgZGlyZWN0b3J5 KS4gIEZpbmFsbHksCiMgc2luY2UgbWFrZSBtcnByb3BlciB3YW50cyB0byB3aXBlIG91dCAu Y29uZmlnIGZpbGVzLCB3ZSBtb3ZlIG91ciBtcnByb3BlcgojIHVwIGJlZm9yZSB3ZSBjb3B5 IHRoZSBjb25maWcgZmlsZXMgYXJvdW5kLgolaWZhcmNoICV7YWxsX3g4Nn0KICAgIGNwIGNv bmZpZ3Mva2VybmVsLSV7a3ZlcnNpb259LSRDb25maWcuY29uZmlnIC5jb25maWcKJWVsc2UK JWlmYXJjaCBzcGFyYyBzcGFyYzY0CiAgICBjcCBjb25maWdzL2tlcm5lbC0le2t2ZXJzaW9u fS0kQ29uZmlnLmNvbmZpZyAuY29uZmlnCiVlbHNlCiAgICBjcCBjb25maWdzL2tlcm5lbC0l e2t2ZXJzaW9ufS0kQ29uZmlnLmNvbmZpZyAuY29uZmlnCiVlbmRpZgolZW5kaWYKICAgICMg bWFrZSBzdXJlIEVYVFJBVkVSU0lPTiBzYXlzIHdoYXQgd2Ugd2FudCBpdCB0byBzYXkKICAg IHBlcmwgLXAgLWkgLWUgInMvXkVYVFJBVkVSU0lPTi4qL0VYVFJBVkVSU0lPTiA9IC0le3Jl bGVhc2V9JDIvIiBNYWtlZmlsZQolaWZhcmNoIHNwYXJjIHNwYXJjNjQgICAgIAogICAgbWFr ZSAtcyBBUkNIPSQxIG9sZGNvbmZpZ19ub25pbnQKICAgIG1ha2UgLXMgQVJDSD0kMSBkZXAK ICAgIG1ha2UgLXMgQVJDSD0kMSBpbmNsdWRlL2xpbnV4L3ZlcnNpb24uaCAKJWVsc2UKICAg IG1ha2UgLXMgb2xkY29uZmlnX25vbmludAogICAgbWFrZSAtcyBkZXAKICAgIG1ha2UgLXMg aW5jbHVkZS9saW51eC92ZXJzaW9uLmggCiVlbmRpZgp9CgpCdWlsZEtlcm5lbCgpIHsKICAg IGlmIFsgLW4gIiQxIiBdIDsgdGhlbgoJQ29uZmlnPSV7X3RhcmdldF9jcHV9LSQxCglLZXJu ZWxWZXI9JXt2ZXJzaW9ufS0le3JlbGVhc2V9JDEKCURlcGVuZEtlcm5lbCAle190YXJnZXRf Y3B1fSAkMQoJZWNobyBCVUlMRElORyBBIEtFUk5FTCBGT1IgJDEgJXtfdGFyZ2V0X2NwdX0u Li4KICAgIGVsc2UKCUNvbmZpZz0le190YXJnZXRfY3B1fQoJS2VybmVsVmVyPSV7dmVyc2lv bn0tJXtyZWxlYXNlfQoJRGVwZW5kS2VybmVsICV7X3RhcmdldF9jcHV9CgllY2hvIEJVSUxE SU5HIFRIRSBOT1JNQUwgS0VSTkVMIGZvciAle190YXJnZXRfY3B1fS4uLgogICAgZmkKCiVp ZmFyY2ggJXthbGxfeDg2fQogICAgbWFrZSAtcyAtaiAkUlBNX0JVSUxEX05DUFVTIGJ6SW1h Z2UgCiVlbHNlCiVpZmFyY2ggJXthbGxfcHBjfQogICAgbWFrZSAtcyAtaiAkUlBNX0JVSUxE X05DUFVTIHZtbGludXgKJWVsc2UKJWlmYXJjaCBzMzkwIHMzOTB4CiAgICBbICIkMSIgPSAi ZGVidWciIF0gJiYgZXhwb3J0IEVYVFJBX0NGTEFHUz0iLWdzdGFicyIKICAgIG1ha2UgLXMg Q0ZMQUdTX0tFUk5FTD0iJEVYVFJBX0NGTEFHUyIgLWogJFJQTV9CVUlMRF9OQ1BVUyBpbWFn ZSAgICAKJWVsc2UKICAgIG1ha2UgLXMgLWogJFJQTV9CVUlMRF9OQ1BVUyBib290IAolZW5k aWYKJWVuZGlmCiVlbmRpZgogICAgbWFrZSAtcyBDRkxBR1NfS0VSTkVMPSIkRVhUUkFfQ0ZM QUdTIiAtaiAkUlBNX0JVSUxEX05DUFVTIG1vZHVsZXMKICAgICMgZmlyc3QgbWFrZSBzdXJl IHdlIGFyZSBub3QgbG9vc2luZyBhbnkgLnZlciBmaWxlcyB0byBtYWtlIG1ycG9ycGVyJ3MK ICAgICMgcmVtb3ZhbCBvZiB6ZXJvIHNpemVkIGZpbGVzLgogICAgZmluZCBpbmNsdWRlL2xp bnV4L21vZHVsZXMgLXNpemUgMCB8IHdoaWxlIHJlYWQgZmlsZSA7IGRvIFwKCWVjaG8gPiAk ZmlsZQogICAgZG9uZQogICAgIyBTdGFydCBpbnN0YWxsaW5nIHN0dWZmCiAgICBta2RpciAt cCAkUlBNX0JVSUxEX1JPT1QvYm9vdAogICAgaW5zdGFsbCAtbSA2NDQgU3lzdGVtLm1hcCAk UlBNX0JVSUxEX1JPT1QvYm9vdC9TeXN0ZW0ubWFwLSRLZXJuZWxWZXIKICAgIGluc3RhbGwg LW0gNjQ0ICRSUE1fU09VUkNFX0RJUi9tb2R1bGUtaW5mbyAkUlBNX0JVSUxEX1JPT1QvYm9v dC9tb2R1bGUtaW5mby0kS2VybmVsVmVyCiAgICBta2RpciAtcCAkUlBNX0JVSUxEX1JPT1Qv ZGV2L3NobQolaWZhcmNoIGlhNjQKICAgICV7X215c3RyaXB9IC0tc3RyaXAtZGVidWcgdm1s aW51eAolZW5kaWYKJWlmYXJjaCAle2FsbF94ODZ9CiAgICBjcCBhcmNoL2kzODYvYm9vdC9i ekltYWdlICRSUE1fQlVJTERfUk9PVC9ib290L3ZtbGludXotJEtlcm5lbFZlcgogICAgY3Ag dm1saW51eCAkUlBNX0JVSUxEX1JPT1QvYm9vdC92bWxpbnV4LSRLZXJuZWxWZXIKJWVsc2UK JWlmYXJjaCBpYTY0CiAgICBnemlwIC1jZnYgdm1saW51eCA+IHZtbGludXoKICAgIG1rZGly IC1wICRSUE1fQlVJTERfUk9PVC9ib290L2VmaQogICAgaW5zdGFsbCAtbSA3NTUgdm1saW51 eCAkUlBNX0JVSUxEX1JPT1QvYm9vdC9lZmkvdm1saW51eC0kS2VybmVsVmVyCiAgICBpbnN0 YWxsIC1tIDc1NSB2bWxpbnV6ICRSUE1fQlVJTERfUk9PVC9ib290L2VmaS92bWxpbnV6LSRL ZXJuZWxWZXIKICAgIGxuIC1zIGVmaS92bWxpbnV4LSRLZXJuZWxWZXIgJFJQTV9CVUlMRF9S T09UL2Jvb3Qvdm1saW51eC0kS2VybmVsVmVyCiAgICBsbiAtcyBlZmkvdm1saW51ei0kS2Vy bmVsVmVyICRSUE1fQlVJTERfUk9PVC9ib290L3ZtbGludXotJEtlcm5lbFZlcgolZWxzZQol aWZhcmNoIHMzOTAgczM5MHgKICAgIGluc3RhbGwgLW0gNzU1IEtlcm50eXBlcyAkUlBNX0JV SUxEX1JPT1QvYm9vdC9LZXJudHlwZXMtJEtlcm5lbFZlcgogICAgaW5zdGFsbCAtbSA3NTUg YXJjaC8le190YXJnZXRfY3B1fS9ib290L2ltYWdlICRSUE1fQlVJTERfUk9PVC9ib290L3Zt bGludXotJEtlcm5lbFZlcgogICAgaW5zdGFsbCAtbSA3NTUgYXJjaC8le190YXJnZXRfY3B1 fS9ib290LyouYm9vdCAkUlBNX0JVSUxEX1JPT1QvYm9vdC8KJWVsc2UKJWlmbmFyY2ggJXth bGxfcHBjfQogICAgZ3ppcCAtY2Z2IHZtbGludXggPiB2bWxpbnV6CiAgICBpbnN0YWxsIC1t IDY0NCB2bWxpbnV6ICRSUE1fQlVJTERfUk9PVC9ib290L3ZtbGludXotJEtlcm5lbFZlcgol ZW5kaWYKJWVuZGlmCiAgICBpbnN0YWxsIC1tIDc1NSB2bWxpbnV4ICRSUE1fQlVJTERfUk9P VC9ib290L3ZtbGludXgtJEtlcm5lbFZlcgolZW5kaWYKJWVuZGlmCiAgICBta2RpciAtcCAk UlBNX0JVSUxEX1JPT1QvbGliL21vZHVsZXMvJEtlcm5lbFZlcgogICAgbWFrZSAtcyBJTlNU QUxMX01PRF9QQVRIPSRSUE1fQlVJTERfUk9PVCBtb2R1bGVzX2luc3RhbGwgS0VSTkVMUkVM RUFTRT0kS2VybmVsVmVyCiAgICBybSAtZiAkUlBNX0JVSUxEX1JPT1QvbGliL21vZHVsZXMv JEtlcm5lbFZlci9tb2R1bGVzLioKJWlmbmFyY2ggYWxwaGEgczM5MCBzMzkweCAle2FsbF9w cGN9CiAgICBtdiAkUlBNX0JVSUxEX1JPT1QvbGliL21vZHVsZXMvJEtlcm5lbFZlci9rZXJu ZWwvZHJpdmVycy9zY3NpL2FpYzd4eHhfb2xkLm8gJFJQTV9CVUlMRF9ST09UL2xpYi9tb2R1 bGVzLyRLZXJuZWxWZXIva2VybmVsL2RyaXZlcnMvc2NzaS9haWM3eHh4Lm8KICAgIG12ICRS UE1fQlVJTERfUk9PVC9saWIvbW9kdWxlcy8kS2VybmVsVmVyL2tlcm5lbC9kcml2ZXJzL3Nj c2kvYWljN3h4eC9haWM3eHh4Lm8gJFJQTV9CVUlMRF9ST09UL2xpYi9tb2R1bGVzLyRLZXJu ZWxWZXIva2VybmVsL2RyaXZlcnMvc2NzaS9haWM3eHh4X21vZC5vCiVlbmRpZgoKJWlmYXJj aCBpYTY0IGFscGhhCiAgICAle19teXN0cmlwfSAtLXN0cmlwLWRlYnVnIGBmaW5kICRSUE1f QlVJTERfUk9PVC9saWIvbW9kdWxlcy8kS2VybmVsVmVyIC10eXBlIGZgIHx8IDoKJWVuZGlm Cgp9CgpTYXZlSGVhZGVycygpIHsKICAgIGVjaG8gIlNBVklORyBIRUFERVJTIGZvciAkMSAk MiIKICAgICMgZGVhbCB3aXRoIHRoZSBrZXJuZWwgaGVhZGVycyB0aGF0IGFyZSB2ZXJzaW9u IHNwZWNpZmljCiAgICBta2RpciAtcCAkUlBNX0JVSUxEX1JPT1QvdXNyL3NyYy9saW51eC0l e0tWRVJSRUx9L3NhdmVkaGVhZGVycy8kMi8kMQogICAgaW5zdGFsbCAtbSA2NDQgaW5jbHVk ZS9saW51eC9hdXRvY29uZi5oIFwKCSRSUE1fQlVJTERfUk9PVC91c3Ivc3JjL2xpbnV4LSV7 S1ZFUlJFTH0vc2F2ZWRoZWFkZXJzLyQyLyQxL2F1dG9jb25mLmgKICAgIGluc3RhbGwgLW0g NjQ0IGluY2x1ZGUvbGludXgvdmVyc2lvbi5oIFwKCSRSUE1fQlVJTERfUk9PVC91c3Ivc3Jj L2xpbnV4LSV7S1ZFUlJFTH0vc2F2ZWRoZWFkZXJzLyQyLyQxL3ZlcnNpb24uaAogICAgbXYg aW5jbHVkZS9saW51eC9tb2R1bGVzIFwKCSRSUE1fQlVJTERfUk9PVC91c3Ivc3JjL2xpbnV4 LSV7S1ZFUlJFTH0vc2F2ZWRoZWFkZXJzLyQyLyQxLwogICAgZWNobyAkMiAkMSAuLi8uLi9z YXZlZGhlYWRlcnMvJDIvJDEvID4+ICRSUE1fQlVJTERfUk9PVC91c3Ivc3JjL2xpbnV4LSV7 S1ZFUlJFTH0vc2F2ZWRoZWFkZXJzL2xpc3QKfQoKIyMjCiMgRE8gaXQuLi4KIyMjCgpybSAt cmYgJFJQTV9CVUlMRF9ST09UCgolaWYgJXtidWlsZGplbnNlbn0KQnVpbGRLZXJuZWwgamVu c2VuCiVlbmRpZgoKJWlmICV7YnVpbGR0YXBlfQpCdWlsZEtlcm5lbCB0YXBlClNhdmVIZWFk ZXJzIHRhcGUgJXtfdGFyZ2V0X2NwdX0KJWVuZGlmCgolaWYgJXtidWlsZEJPT1R0YXBlfQpC dWlsZEtlcm5lbCBCT09UdGFwZQpTYXZlSGVhZGVycyBCT09UdGFwZSAle190YXJnZXRfY3B1 fQolZW5kaWYKCiVpZiAle2J1aWxkZGVidWd9CiVpZmFyY2ggczM5MCBzMzkweApCdWlsZEtl cm5lbCBkZWJ1ZwpTYXZlSGVhZGVycyBkZWJ1ZyAle190YXJnZXRfY3B1fQolZWxzZQpBZGRQ YXRjaGVzIGRlYnVnCkJ1aWxkS2VybmVsIGRlYnVnClNhdmVIZWFkZXJzIGRlYnVnICV7X3Rh cmdldF9jcHV9ClJlbW92ZVBhdGNoZXMgZGVidWcKJWVuZGlmCiVlbmRpZgoKJWlmICV7YnVp bGRlbnRlcnByaXNlfQpCdWlsZEtlcm5lbCBlbnRlcnByaXNlClNhdmVIZWFkZXJzIGVudGVy cHJpc2UgJXtfdGFyZ2V0X2NwdX0KJWVuZGlmCgolaWYgJXtidWlsZHNtcH0KQnVpbGRLZXJu ZWwgc21wClNhdmVIZWFkZXJzIHNtcCAle190YXJnZXRfY3B1fQolZW5kaWYKCiVpZiAle2J1 aWxkQk9PVH0KQnVpbGRLZXJuZWwgQk9PVApTYXZlSGVhZGVycyBCT09UICV7X3RhcmdldF9j cHV9CiVlbmRpZgoKJWlmYXJjaCBpMzg2CkRlcGVuZEtlcm5lbCBpNTg2ClNhdmVIZWFkZXJz IHVwIGk1ODYKRGVwZW5kS2VybmVsIGk2ODYKU2F2ZUhlYWRlcnMgdXAgaTY4NgpEZXBlbmRL ZXJuZWwgYXRobG9uClNhdmVIZWFkZXJzIHVwIGF0aGxvbgolZW5kaWYKJWlmYXJjaCBzcGFy YwpEZXBlbmRLZXJuZWwgc3BhcmM2NApTYXZlSGVhZGVycyB1cCBzcGFyYzY0CiVlbmRpZgoK JWlmYXJjaCBpMzg2IApEZXBlbmRLZXJuZWwgaTU4NiBzbXAKU2F2ZUhlYWRlcnMgc21wIGk1 ODYKRGVwZW5kS2VybmVsIGk2ODYgc21wClNhdmVIZWFkZXJzIHNtcCBpNjg2CkRlcGVuZEtl cm5lbCBpNjg2IGVudGVycHJpc2UKU2F2ZUhlYWRlcnMgZW50ZXJwcmlzZSBpNjg2CiNBZGRQ YXRjaGVzIGRlYnVnCiNEZXBlbmRLZXJuZWwgaTY4NiBkZWJ1ZwojU2F2ZUhlYWRlcnMgZGVi dWcgaTY4NgojUmVtb3ZlUGF0Y2hlcyBkZWJ1ZwpEZXBlbmRLZXJuZWwgYXRobG9uIHNtcApT YXZlSGVhZGVycyBzbXAgYXRobG9uCiVlbmRpZgolaWZhcmNoIHNwYXJjCkRlcGVuZEtlcm5l bCBzcGFyYzY0IHNtcApTYXZlSGVhZGVycyBzbXAgc3BhcmM2NAolZW5kaWYKCiMgVU5JUFJP Q0VTU09SIEtFUk5FTAolaWYgJXtidWlsZHVwfQpCdWlsZEtlcm5lbAolaWZhcmNoIGkzODYg YXRobG9uIGFscGhhIHNwYXJjIGlhNjQgczM5MCBzMzkweCAle2FsbF9wcGN9ClNhdmVIZWFk ZXJzIHVwICV7X3RhcmdldF9jcHV9CiVlbmRpZgolZW5kaWYKCgojIyMKIyMjIGluc3RhbGwK IyMjCgolaW5zdGFsbAoKY2QgbGludXgKbWtkaXIgLXAgJFJQTV9CVUlMRF9ST09UL3tib290 LHNiaW59CiVpZmFyY2ggcHBjaXNlcmllcwppbnN0YWxsIC1tIDc1NSAkUlBNX1NPVVJDRV9E SVIvaW5zdGFsbGtlcm5lbC5pU2VyaWVzICRSUE1fQlVJTERfUk9PVC9zYmluL2luc3RhbGxr ZXJuZWwKaW5zdGFsbCAtbSA3NTUgJFJQTV9TT1VSQ0VfRElSL2luc3RhbGxjbWRsaW5lLmlT ZXJpZXMgJFJQTV9CVUlMRF9ST09UL3NiaW4vaW5zdGFsbGNtZGxpbmUKJWVuZGlmCgpmb3Ig aSBpbiAkUlBNX0JVSUxEX1JPT1QvbGliL21vZHVsZXMvKjsgZG8KICBybSAtZiAkaS9idWls ZCAKICBsbiAtc2YgLi4vLi4vLi4vdXNyL3NyYy9saW51eC0le0tWRVJSRUx9ICRpL2J1aWxk CmRvbmUKCiVpZmFyY2ggaTU4NiBpNjg2IHNwYXJjNjQKIyB0aGVzZSBkb24ndCBuZWVkIG11 Y2gKZXhpdCAwCiVlbmRpZgoKbWtkaXIgLXAgJFJQTV9CVUlMRF9ST09UL3Vzci9pbmNsdWRl CmxuIC1zZiAuLi9zcmMvbGludXgvaW5jbHVkZS9saW51eCAkUlBNX0JVSUxEX1JPT1QvdXNy L2luY2x1ZGUvbGludXgKCm1rZGlyIC1wICRSUE1fQlVJTERfUk9PVC91c3Ivc3JjL2xpbnV4 LSV7S1ZFUlJFTH0KdGFyIGNmIC0gLiB8IHRhciB4ZiAtIC1DICRSUE1fQlVJTERfUk9PVC91 c3Ivc3JjL2xpbnV4LSV7S1ZFUlJFTH0KcGVybCAtcCAtaSAtZSAicy9eRVhUUkFWRVJTSU9O LiovRVhUUkFWRVJTSU9OID0gLSV7cmVsZWFzZX1jdXN0b20vIiAkUlBNX0JVSUxEX1JPT1Qv dXNyL3NyYy9saW51eC0le0tWRVJSRUx9L01ha2VmaWxlCmxuIC1zZiBsaW51eC0le0tWRVJS RUx9ICRSUE1fQlVJTERfUk9PVC91c3Ivc3JjL2xpbnV4Cmluc3RhbGwgLW0gNjQ0ICV7U09V UkNFNH0gICRSUE1fQlVJTERfUk9PVC91c3Ivc3JjL2xpbnV4LSV7S1ZFUlJFTH0KCiVpZmFy Y2ggc3BhcmMKbG4gLXMgLi4vc3JjL2xpbnV4L2luY2x1ZGUvYXNtLXNwYXJjICRSUE1fQlVJ TERfUk9PVC91c3IvaW5jbHVkZS9hc20tc3BhcmMKbG4gLXMgLi4vc3JjL2xpbnV4L2luY2x1 ZGUvYXNtLXNwYXJjNjQgJFJQTV9CVUlMRF9ST09UL3Vzci9pbmNsdWRlL2FzbS1zcGFyYzY0 Cm1rZGlyICRSUE1fQlVJTERfUk9PVC91c3IvaW5jbHVkZS9hc20KY3AgLWEgJFJQTV9TT1VS Q0VfRElSL2tlcm5lbC0yLjQtQnVpbGRBU00uc2ggJFJQTV9CVUlMRF9ST09UL3Vzci9zcmMv bGludXgvaW5jbHVkZS9hc20tc3BhcmMvQnVpbGRBU00KJFJQTV9CVUlMRF9ST09UL3Vzci9p bmNsdWRlL2FzbS1zcGFyYy9CdWlsZEFTTSAkUlBNX0JVSUxEX1JPT1QvdXNyL2luY2x1ZGUK JWVsc2UKbG4gLXNmIC4uL3NyYy9saW51eC9pbmNsdWRlL2FzbSAkUlBNX0JVSUxEX1JPT1Qv dXNyL2luY2x1ZGUvYXNtCiVlbmRpZgoKI2NsZWFuIHVwIHRoZSBkZXN0aW5hdGlvbgptYWtl IC1zIG1ycHJvcGVyIC1DICRSUE1fQlVJTERfUk9PVC91c3Ivc3JjL2xpbnV4LSV7S1ZFUlJF TH0KY3AgY29uZmlncy9rZXJuZWwtJXtrdmVyc2lvbn0tJXtfdGFyZ2V0X2NwdX0uY29uZmln ICRSUE1fQlVJTERfUk9PVC91c3Ivc3JjL2xpbnV4LSV7S1ZFUlJFTH0vLmNvbmZpZwptYWtl IC1zIG9sZGNvbmZpZ19ub25pbnQgLUMgJFJQTV9CVUlMRF9ST09UL3Vzci9zcmMvbGludXgt JXtLVkVSUkVMfQptYWtlIC1zIHN5bWxpbmtzIC1DICRSUE1fQlVJTERfUk9PVC91c3Ivc3Jj L2xpbnV4LSV7S1ZFUlJFTH0KbWFrZSAtcyBpbmNsdWRlL2xpbnV4L3ZlcnNpb24uaCAtQyAk UlBNX0JVSUxEX1JPT1QvdXNyL3NyYy9saW51eC0le0tWRVJSRUx9CgojdGhpcyBnZW5lcmF0 ZXMgbW9kdmVyc2lvbnMgaW5mbyB3aGljaCB3ZSB3YW50IHRvIGluY2x1ZGUgYW5kIHdlIG1h eSBhcwojd2VsbCBpbmNsdWRlIHRoZSBkZXBlbmRzIHN0dWZmIGFzIHdlbGwsIGFmdGVyIHdl IGZpeCB0aGUgcGF0aHMKbWFrZSAtcyBkZXBlbmQgLUMgJFJQTV9CVUlMRF9ST09UL3Vzci9z cmMvbGludXgtJXtLVkVSUkVMfQpmaW5kICRSUE1fQlVJTERfUk9PVC91c3Ivc3JjL2xpbnV4 LSV7S1ZFUlJFTH0gLW5hbWUgIi4qZGVwZW5kIiB8IFwKd2hpbGUgcmVhZCBmaWxlIDsgZG8K ICAgIG12ICRmaWxlICRmaWxlLm9sZAogICAgc2VkIC1lICJzfFteIF0qXCgvdXNyL3NyYy9s aW51eFwpfFwxfGciIDwgJGZpbGUub2xkID4gJGZpbGUKICAgIHJtIC1mICRmaWxlLm9sZApk b25lCgojIFRyeSB0byBwdXQgc29tZSBzbWFydGVyIGF1dG9jb25mLmggYW5kIHZlcnNpb24u aCBmaWxlcyBpbiBwbGFjZQpwdXNoZCAkUlBNX0JVSUxEX1JPT1QvdXNyL3NyYy9saW51eC0l e0tWRVJSRUx9L2luY2x1ZGUvbGludXggOyB7CnJtIC1yZiBtb2R1bGVzIG1vZHZlcnNpb25z LmggYXV0b2NvbmYuaCB2ZXJzaW9uLmgKY2F0ID4gbW9kdmVyc2lvbnMuaCA8PEVPRgojaWZu ZGVmIF9MSU5VWF9NT0RWRVJTSU9OU19ICiNkZWZpbmUgX0xJTlVYX01PRFZFUlNJT05TX0gK I2luY2x1ZGUgPGxpbnV4L3JoY29uZmlnLmg+CiNpbmNsdWRlIDxsaW51eC9tb2RzZXR2ZXIu aD4KRU9GCmVjaG8gJyNpbmNsdWRlIDxsaW51eC9yaGNvbmZpZy5oPicgPiBhdXRvY29uZi5o Cmxpc3Q9YGZpbmQgLi4vLi4vc2F2ZWRoZWFkZXJzLyovKi9tb2R1bGVzLyoudmVyIC1leGVj IGJhc2VuYW1lICd7fScgXDsgfCBzb3J0IC11YApta2RpciBtb2R1bGVzCmZvciBsIGluICRs aXN0OyBkbwogICAgc2VkICdzLCQsbW9kdWxlcy8nJGwsIC4uLy4uL3NhdmVkaGVhZGVycy9s aXN0IHwgYXdrIC1mICV7U09VUkNFMTd9ID4gbW9kdWxlcy8kbAogICAgdG91Y2ggLXIgbW9k dWxlcy8kbCBtb2R1bGVzL2BiYXNlbmFtZSAkbCAudmVyYC5zdGFtcAogICAgZWNobyAnI2lu Y2x1ZGUgPGxpbnV4L21vZHVsZXMvJyRsJz4nID4+IG1vZHZlcnNpb25zLmgKZG9uZQplY2hv ICcjZW5kaWYnID4+IG1vZHZlcnNpb25zLmgKc2VkICdzLCQsYXV0b2NvbmYuaCwnIC4uLy4u L3NhdmVkaGVhZGVycy9saXN0IHwgYXdrIC1mICV7U09VUkNFMTZ9ID4+IGF1dG9jb25mLmgK aW5zdGFsbCAtbSA2NDQgJXtTT1VSQ0UxNX0gcmhjb25maWcuaAplY2hvICIjaW5jbHVkZSA8 bGludXgvcmhjb25maWcuaD4iID4+IHZlcnNpb24uaAprZXl3b3JkPWlmCmZvciBpIGluIHNt cCBCT09UIEJPT1RzbXAgZW50ZXJwcmlzZSBkZWJ1ZyB0YXBlIEJPT1R0YXBlIHVwIDsgZG8K IyBXaGVuIHdlIGJ1aWxkIGluIGFuIGkzODYsIHdlIGRvbid0IGhhdmUgYW4gZW50ZXJwcmlz ZSBoZWFkZXIgZGlyZWN0b3J5CiMgaW4gc2F2ZWRoZWFkZXJzL2kzODYvZW50ZXJwcmlzZS4g IFdlIGFsc28gZG9uJ3QgaGF2ZSBhIEJPT1QgZGlyZWN0b3J5CiMgYW55d2hlcmUgZXhjZXB0 IGluIHNhdmVkaGVhZGVycy9pMzg2LiAgU28sIHdlIG5lZWQgdG8gdXNlIHRoaXMgbWV0aG9k CiMgb2YgZGV0ZXJtaW5pbmcgaWYgYSBrZXJuZWwgdmVyc2lvbiBzdHJpbmcgbmVlZHMgdG8g YmUgaW5jbHVkZWQgaW4gdGhlCiMgdmVyc2lvbi5oIGZpbGUKICAgIHZlcmg9YGVjaG8gLi4v Li4vc2F2ZWRoZWFkZXJzLyovJGkvdmVyc2lvbi5oIHwgYXdrICcgeyBwcmludCAkMSB9ICdg CiAgICBpZiBbIC1uICIkdmVyaCIgLWEgLWYgIiR2ZXJoIiBdOyB0aGVuCglpZiBbICIkaSIg PSB1cCBdOyB0aGVuCgkgICAgaWYgWyAiJGtleXdvcmQiID0gaWYgXTsgdGhlbgoJCWVjaG8g IiNpZiAwIiA+PiB2ZXJzaW9uLmgKCSAgICBmaQogIAkgICAgZWNobyAiI2Vsc2UiID4+IHZl cnNpb24uaAoJZWxzZQoJICAgIGVjaG8gIiMka2V5d29yZCBkZWZpbmVkKF9fbW9kdWxlX18k aSkiID4+IHZlcnNpb24uaAoJICAgIGtleXdvcmQ9ZWxpZgoJZmkKCWdyZXAgVVRTX1JFTEVB U0UgJHZlcmggPj4gdmVyc2lvbi5oCiAgICBmaQpkb25lCmVjaG8gIiNlbmRpZiIgPj4gdmVy c2lvbi5oCmlmIFsgLWYgLi4vLi4vc2F2ZWRoZWFkZXJzLyV7X3RhcmdldF9jcHV9L3VwL3Zl cnNpb24uaCBdIDsgdGhlbgogICAgIyBrZWVwIHRvIGEgc3RhbmRhcmQgbm9ybWFsbHkKICAg IEhFQURFUl9GSUxFPS4uLy4uL3NhdmVkaGVhZGVycy8le190YXJnZXRfY3B1fS91cC92ZXJz aW9uLmgKZWxzZQogICAgIyB0ZXN0IGJ1aWxkIG5vdCBpbmNsdWRpbmcgdW5pcHJvY2Vzc29y LCBtdXN0IGdldCBpbmZvIGZyb20gc29tZXdoZXJlCiAgICBIRUFERVJfRklMRT0kKGxzIC4u Ly4uL3NhdmVkaGVhZGVycy8le190YXJnZXRfY3B1fS8qL3ZlcnNpb24uaCB8IGhlYWQgLTEp CmZpCmdyZXAgLXYgVVRTX1JFTEVBU0UgJEhFQURFUl9GSUxFID4+IHZlcnNpb24uaApybSAt cmYgLi4vLi4vc2F2ZWRoZWFkZXJzCn0gOyBwb3BkCnRvdWNoICRSUE1fQlVJTERfUk9PVC9i b290L2tlcm5lbC5oLSV7a3ZlcnNpb259CgpybSAtZiAkUlBNX0JVSUxEX1JPT1QvdXNyL2lu Y2x1ZGUvbGludXgKbWtkaXIgLXAgJFJQTV9CVUlMRF9ST09UL3Vzci9pbmNsdWRlL2xpbnV4 CmNwIC1hICRSUE1fQlVJTERfUk9PVC91c3Ivc3JjL2xpbnV4L2luY2x1ZGUvbGludXgvKiAk UlBNX0JVSUxEX1JPT1QvdXNyL2luY2x1ZGUvbGludXgvCnJtIC1yZiAkUlBNX0JVSUxEX1JP T1QvdXNyL2luY2x1ZGUvbGludXgvbW9kdWxlcwplY2hvICIjZXJyb3IgTW9kdWxlcyBzaG91 bGQgbmV2ZXIgdXNlIGtlcm5lbC1oZWFkZXJzIHN5c3RlbSBoZWFkZXJzLCIgPiAkUlBNX0JV SUxEX1JPT1QvdXNyL2luY2x1ZGUvbGludXgvbW9kdmVyc2lvbnMuaAplY2hvICIjZXJyb3Ig YnV0IHJhdGhlciBoZWFkZXJzIGZyb20gYW4gYXBwcm9wcmlhdGUga2VybmVsLXNvdXJjZSBw YWNrYWdlLiIgPj4gJFJQTV9CVUlMRF9ST09UL3Vzci9pbmNsdWRlL2xpbnV4L21vZHZlcnNp b25zLmgKZWNobyAiI2Vycm9yIENoYW5nZSAtSS91c3Ivc3JjL2xpbnV4L2luY2x1ZGUgKG9y IHNpbWlsYXIpIHRvIiA+PiAkUlBNX0JVSUxEX1JPT1QvdXNyL2luY2x1ZGUvbGludXgvbW9k dmVyc2lvbnMuaAplY2hvICIjZXJyb3IgLUkvbGliL21vZHVsZXMvXCQodW5hbWUgLXIpL2J1 aWxkL2luY2x1ZGUiID4+ICRSUE1fQlVJTERfUk9PVC91c3IvaW5jbHVkZS9saW51eC9tb2R2 ZXJzaW9ucy5oCmVjaG8gIiNlcnJvciB0byBidWlsZCBhZ2FpbnN0IHRoZSBjdXJyZW50bHkt cnVubmluZyBrZXJuZWwuIiA+PiAkUlBNX0JVSUxEX1JPT1QvdXNyL2luY2x1ZGUvbGludXgv bW9kdmVyc2lvbnMuaAolaWZhcmNoIHNwYXJjCnJtIC1mICRSUE1fQlVJTERfUk9PVC91c3Iv aW5jbHVkZS9hc20tc3BhcmMKbWtkaXIgLXAgJFJQTV9CVUlMRF9ST09UL3Vzci9pbmNsdWRl L2FzbS1zcGFyYwpjcCAtYSAkUlBNX0JVSUxEX1JPT1QvdXNyL3NyYy9saW51eC9pbmNsdWRl L2FzbS1zcGFyYy8qICRSUE1fQlVJTERfUk9PVC91c3IvaW5jbHVkZS9hc20tc3BhcmMvCnJt IC1mICRSUE1fQlVJTERfUk9PVC91c3IvaW5jbHVkZS9hc20tc3BhcmM2NApta2RpciAtcCAk UlBNX0JVSUxEX1JPT1QvdXNyL2luY2x1ZGUvYXNtLXNwYXJjNjQKY3AgLWEgJFJQTV9CVUlM RF9ST09UL3Vzci9zcmMvbGludXgvaW5jbHVkZS9hc20tc3BhcmM2NC8qICRSUE1fQlVJTERf Uk9PVC91c3IvaW5jbHVkZS9hc20tc3BhcmM2NC8KJWVsc2UKcm0gLWYgJFJQTV9CVUlMRF9S T09UL3Vzci9pbmNsdWRlL2FzbQpta2RpciAtcCAkUlBNX0JVSUxEX1JPT1QvdXNyL2luY2x1 ZGUvYXNtCmNwIC1hICRSUE1fQlVJTERfUk9PVC91c3Ivc3JjL2xpbnV4L2luY2x1ZGUvYXNt LyogJFJQTV9CVUlMRF9ST09UL3Vzci9pbmNsdWRlL2FzbS8KJWVuZGlmCgpmb3IgaSBpbiAk UlBNX0JVSUxEX1JPT1QvbGliL21vZHVsZXMvKjsgZG8KICBybSAtZiAkaS9tb2R1bGVzLioK ZG9uZQoKIyMjCiMjIyBjbGVhbgojIyMKCiVjbGVhbgpybSAtcmYgJFJQTV9CVUlMRF9ST09U CgojIyMKIyMjIHNjcmlwdHMKIyMjCgojIGRvIHRoaXMgZm9yIHVwZ3JhZGVzLi4uaW4gY2Fz ZSB0aGUgb2xkIG1vZHVsZXMgZ2V0IHJlbW92ZWQgd2UgaGF2ZQojIGxvb3BiYWNrIGluIHRo ZSBrZXJuZWwgc28gdGhhdCBta2luaXRyZCB3aWxsIHdvcmsuCiVwcmUgCi9zYmluL21vZHBy b2JlIGxvb3AgMj4gL2Rldi9udWxsID4gL2Rldi9udWxsICB8fCA6CmV4aXQgMAoKJXByZSBz bXAKL3NiaW4vbW9kcHJvYmUgbG9vcCAyPiAvZGV2L251bGwgPiAvZGV2L251bGwgIHx8IDoK ZXhpdCAwCgolcHJlIGVudGVycHJpc2UKL3NiaW4vbW9kcHJvYmUgbG9vcCAyPiAvZGV2L251 bGwgPiAvZGV2L251bGwgIHx8IDoKZXhpdCAwCgolcHJlIGRlYnVnCi9zYmluL21vZHByb2Jl IGxvb3AgMj4gL2Rldi9udWxsID4gL2Rldi9udWxsICB8fCA6CmV4aXQgMAoKJXByZSB0YXBl Ci9zYmluL21vZHByb2JlIGxvb3AgMj4gL2Rldi9udWxsID4gL2Rldi9udWxsICB8fCA6CmV4 aXQgMAoKJXBvc3QgCmNkIC9ib290CiVpZm5hcmNoIGlhNjQgJXthbGxfcHBjfQpsbiAtc2Yg dm1saW51ei0le0tWRVJSRUx9IHZtbGludXoKJWVuZGlmCiVpZmFyY2ggJXthbGxfcHBjfQps biAtc2Ygdm1saW51eC0le0tWRVJSRUx9IHZtbGludXgKJWVuZGlmCmxuIC1zZiBTeXN0ZW0u bWFwLSV7S1ZFUlJFTH0gU3lzdGVtLm1hcApsbiAtc2YgbW9kdWxlLWluZm8tJXtLVkVSUkVM fSBtb2R1bGUtaW5mbwpbIC14IC91c3Ivc2Jpbi9tb2R1bGVfdXBncmFkZSBdICYmIC91c3Iv c2Jpbi9tb2R1bGVfdXBncmFkZQpkZXBtb2QgLWFlIC1GIC9ib290L1N5c3RlbS5tYXAtJXtL VkVSUkVMfSAle0tWRVJSRUx9ClsgLXggL3NiaW4vbWtrZXJuZWxkb3RoIF0gJiYgL3NiaW4v bWtrZXJuZWxkb3RoCmlmIFsgLXggL3NiaW4vbmV3LWtlcm5lbC1wa2cgXSA7IHRoZW4KICAg ICAgICAvc2Jpbi9uZXcta2VybmVsLXBrZyAtLW1raW5pdHJkIC0tZGVwbW9kIC0taW5zdGFs bCAle0tWRVJSRUx9CmZpCgoKJXBvc3Qgc21wClsgLXggL3Vzci9zYmluL21vZHVsZV91cGdy YWRlIF0gJiYgL3Vzci9zYmluL21vZHVsZV91cGdyYWRlCmRlcG1vZCAtYWUgLUYgL2Jvb3Qv U3lzdGVtLm1hcC0le0tWRVJSRUx9c21wICV7S1ZFUlJFTH1zbXAKWyAteCAvc2Jpbi9ta2tl cm5lbGRvdGggXSAmJiAvc2Jpbi9ta2tlcm5lbGRvdGgKaWYgWyAteCAvc2Jpbi9uZXcta2Vy bmVsLXBrZyBdIDsgdGhlbgogICAgICAgIC9zYmluL25ldy1rZXJuZWwtcGtnIC0tbWtpbml0 cmQgLS1kZXBtb2QgLS1pbnN0YWxsICV7S1ZFUlJFTH1zbXAKZmkKCiVwb3N0IGVudGVycHJp c2UKWyAteCAvdXNyL3NiaW4vbW9kdWxlX3VwZ3JhZGUgXSAmJiAvdXNyL3NiaW4vbW9kdWxl X3VwZ3JhZGUKZGVwbW9kIC1hZSAtRiAvYm9vdC9TeXN0ZW0ubWFwLSV7S1ZFUlJFTH1lbnRl cnByaXNlICV7S1ZFUlJFTH1lbnRlcnByaXNlClsgLXggL3NiaW4vbWtrZXJuZWxkb3RoIF0g JiYgL3NiaW4vbWtrZXJuZWxkb3RoCmlmIFsgLXggL3NiaW4vbmV3LWtlcm5lbC1wa2cgXSA7 IHRoZW4KICAgICAgICAvc2Jpbi9uZXcta2VybmVsLXBrZyAtLW1raW5pdHJkIC0tZGVwbW9k IC0taW5zdGFsbCAle0tWRVJSRUx9ZW50ZXJwcmlzZQpmaQoKJXBvc3QgZGVidWcKWyAteCAv dXNyL3NiaW4vbW9kdWxlX3VwZ3JhZGUgXSAmJiAvdXNyL3NiaW4vbW9kdWxlX3VwZ3JhZGUK ZGVwbW9kIC1hZSAtRiAvYm9vdC9TeXN0ZW0ubWFwLSV7S1ZFUlJFTH1kZWJ1ZyAle0tWRVJS RUx9ZGVidWcKWyAteCAvc2Jpbi9ta2tlcm5lbGRvdGggXSAmJiAvc2Jpbi9ta2tlcm5lbGRv dGgKaWYgWyAteCAvc2Jpbi9uZXcta2VybmVsLXBrZyBdIDsgdGhlbgogICAgICAgIC9zYmlu L25ldy1rZXJuZWwtcGtnIC0tbWtpbml0cmQgLS1kZXBtb2QgLS1pbnN0YWxsICV7S1ZFUlJF TH1kZWJ1ZwpmaQoKJXBvc3QgamVuc2VuClsgLXggL3Vzci9zYmluL21vZHVsZV91cGdyYWRl IF0gJiYgL3Vzci9zYmluL21vZHVsZV91cGdyYWRlCmRlcG1vZCAtYWUgLWkgLW0gL2Jvb3Qv U3lzdGVtLm1hcC0le0tWRVJSRUx9amVuc2VuICV7S1ZFUlJFTH1qZW5zZW4KWyAteCAvc2Jp bi9ta2tlcm5lbGRvdGggXSAmJiAvc2Jpbi9ta2tlcm5lbGRvdGgKaWYgWyAteCAvc2Jpbi9u ZXcta2VybmVsLXBrZyBdIDsgdGhlbgogICAgICAgIC9zYmluL25ldy1rZXJuZWwtcGtnIC0t bWtpbml0cmQgLS1kZXBtb2QgLS1pbnN0YWxsICV7S1ZFUlJFTH1kZWJ1ZwpmaQoKJXBvc3Qg dGFwZQpbIC14IC91c3Ivc2Jpbi9tb2R1bGVfdXBncmFkZSBdICYmIC91c3Ivc2Jpbi9tb2R1 bGVfdXBncmFkZQpkZXBtb2QgLWFlIC1pIC1tIC9ib290L1N5c3RlbS5tYXAtJXtLVkVSUkVM fXRhcGUgJXtLVkVSUkVMfXRhcGUKWyAteCAvc2Jpbi9ta2tlcm5lbGRvdGggXSAmJiAvc2Jp bi9ta2tlcm5lbGRvdGgKaWYgWyAteCAvc2Jpbi9uZXcta2VybmVsLXBrZyBdIDsgdGhlbgog ICAgICAgIC9zYmluL25ldy1rZXJuZWwtcGtnIC0tbWtpbml0cmQgLS1kZXBtb2QgLS1pbnN0 YWxsICV7S1ZFUlJFTH10YXBlCmZpCgolaWZuYXJjaCBpYTY0CiVwb3N0IEJPT1QKWyAteCAv dXNyL3NiaW4vbW9kdWxlX3VwZ3JhZGUgXSAmJiAvdXNyL3NiaW4vbW9kdWxlX3VwZ3JhZGUK ZGVwbW9kIC1hZSAtRiAvYm9vdC9TeXN0ZW0ubWFwLSV7S1ZFUlJFTH1CT09UICV7S1ZFUlJF TH1CT09UClsgLXggL3NiaW4vbWtrZXJuZWxkb3RoIF0gJiYgL3NiaW4vbWtrZXJuZWxkb3Ro CmlmIFsgLXggL3NiaW4vbmV3LWtlcm5lbC1wa2cgXSA7IHRoZW4KICAgICAgICAvc2Jpbi9u ZXcta2VybmVsLXBrZyAtLW1raW5pdHJkIC0tZGVwbW9kIC0taW5zdGFsbCAle0tWRVJSRUx9 Qk9PVApmaQoKJWVuZGlmCgojIEFsbG93IGNsZWFuIHJlbW92YWwgb2YgbW9kdWxlcyBkaXJl Y3RvcnkKJXByZXVuIAovc2Jpbi9tb2Rwcm9iZSBsb29wIDI+IC9kZXYvbnVsbCA+IC9kZXYv bnVsbCAgfHwgOgojcm0gLWYgL2xpYi9tb2R1bGVzLyV7S1ZFUlJFTH0vbW9kdWxlcy4qCmlm IFsgLXggL3NiaW4vbmV3LWtlcm5lbC1wa2cgXSA7IHRoZW4KIC9zYmluL25ldy1rZXJuZWwt cGtnIC0tcm1pbml0cmQgLS1ybW1vZGRlcCAtLXJlbW92ZSAle0tWRVJSRUx9CmZpCgoKJXBy ZXVuIHNtcAovc2Jpbi9tb2Rwcm9iZSBsb29wIDI+IC9kZXYvbnVsbCA+IC9kZXYvbnVsbCAg fHwgOgpybSAtZiAvbGliL21vZHVsZXMvJXtLVkVSUkVMfXNtcC9tb2R1bGVzLioKaWYgWyAt eCAvc2Jpbi9uZXcta2VybmVsLXBrZyBdIDsgdGhlbgogL3NiaW4vbmV3LWtlcm5lbC1wa2cg LS1ybWluaXRyZCAtLXJtbW9kZGVwIC0tcmVtb3ZlICV7S1ZFUlJFTH1zbXAKZmkKCgolcHJl dW4gZW50ZXJwcmlzZQovc2Jpbi9tb2Rwcm9iZSBsb29wIDI+IC9kZXYvbnVsbCA+IC9kZXYv bnVsbCAgfHwgOgpybSAtZiAvbGliL21vZHVsZXMvJXtLVkVSUkVMfWVudGVycHJpc2UvbW9k dWxlcy4qCmlmIFsgLXggL3NiaW4vbmV3LWtlcm5lbC1wa2cgXSA7IHRoZW4KIC9zYmluL25l dy1rZXJuZWwtcGtnIC0tcm1pbml0cmQgLS1ybW1vZGRlcCAtLXJlbW92ZSAle0tWRVJSRUx9 ZW50ZXJwcmlzZQpmaQoKCiVwcmV1biBkZWJ1Zwovc2Jpbi9tb2Rwcm9iZSBsb29wIDI+IC9k ZXYvbnVsbCA+IC9kZXYvbnVsbCAgfHwgOgpybSAtZiAvbGliL21vZHVsZXMvJXtLVkVSUkVM fWRlYnVnL21vZHVsZXMuKgppZiBbIC14IC9zYmluL25ldy1rZXJuZWwtcGtnIF0gOyB0aGVu CiAvc2Jpbi9uZXcta2VybmVsLXBrZyAtLXJtaW5pdHJkIC0tcm1tb2RkZXAgLS1yZW1vdmUg JXtLVkVSUkVMfWRlYnVnCmZpCgolcHJldW4gQk9PVAovc2Jpbi9tb2Rwcm9iZSBsb29wIDI+ IC9kZXYvbnVsbCA+IC9kZXYvbnVsbCAgfHwgOgojcm0gLWYgL2xpYi9tb2R1bGVzLyV7S1ZF UlJFTH1CT09UL21vZHVsZXMuKgppZiBbIC14IC9zYmluL25ldy1rZXJuZWwtcGtnIF0gOyB0 aGVuCiAvc2Jpbi9uZXcta2VybmVsLXBrZyAtLXJtaW5pdHJkIC0tcm1tb2RkZXAgLS1yZW1v dmUgJXtLVkVSUkVMfUJPT1QKZmkKCgolcHJldW4gamVuc2VuCi9zYmluL21vZHByb2JlIGxv b3AgMj4gL2Rldi9udWxsID4gL2Rldi9udWxsICB8fCA6CiNybSAtZiAvbGliL21vZHVsZXMv JXtLVkVSUkVMfWplbnNlbi9tb2R1bGVzLioKCiVwcmV1biB0YXBlCi9zYmluL21vZHByb2Jl IGxvb3AgMj4gL2Rldi9udWxsID4gL2Rldi9udWxsICAgfHwgOgojcm0gLWYgL2xpYi9tb2R1 bGVzLyV7S1ZFUlJFTH10YXBlL21vZHVsZXMuKgppZiBbIC14IC9zYmluL25ldy1rZXJuZWwt cGtnIF0gOyB0aGVuCiAvc2Jpbi9uZXcta2VybmVsLXBrZyAtLXJtaW5pdHJkIC0tcm1tb2Rk ZXAgLS1yZW1vdmUgJXtLVkVSUkVMfXRhcGUKZmkKCiVwcmV1biBCT09UdGFwZQovc2Jpbi9t b2Rwcm9iZSBsb29wIDI+IC9kZXYvbnVsbCA+IC9kZXYvbnVsbCB8fCA6CiNybSAtZiAvbGli L21vZHVsZXMvJXtLVkVSUkVMfUJPT1R0YXBlL21vZHVsZXMuKgoKJXByZSBoZWFkZXJzClsg LUwgL3Vzci9pbmNsdWRlL2xpbnV4IF0gJiYgcm0gLWYgL3Vzci9pbmNsdWRlL2xpbnV4IHx8 IDoKWyAtTCAvdXNyL2luY2x1ZGUvYXNtIF0gJiYgcm0gLWYgL3Vzci9pbmNsdWRlL2FzbSB8 fCA6CiVpZmFyY2ggc3BhcmMKWyAtTCAvdXNyL2luY2x1ZGUvYXNtLXNwYXJjIF0gJiYgcm0g LWYgL3Vzci9pbmNsdWRlL2FzbS1zcGFyYwpbIC1MIC91c3IvaW5jbHVkZS9hc20tc3BhcmM2 NCBdICYmIHJtIC1mIC91c3IvaW5jbHVkZS9hc20tc3BhcmM2NAolZW5kaWYKZXhpdCAwCgol cG9zdCBoZWFkZXJzCmNkIC9ib290CnJtIC1mIGtlcm5lbC5oCmxuIC1zbmYga2VybmVsLmgt JXtrdmVyc2lvbn0ga2VybmVsLmgKWyAteCAvc2Jpbi9ta2tlcm5lbGRvdGggXSAmJiAvc2Jp bi9ta2tlcm5lbGRvdGgKZXhpdCAwCgoKIyBXZSBuZWVkIHRoaXMgaGVyZSBiZWNhdXNlIHdl IGRvbid0IHByZXJlcSBrdWR6dTsgaXQgY291bGQgYmUKIyBpbnN0YWxsZWQgYWZ0ZXIgdGhl IGtlcm5lbAoldHJpZ2dlcmluIC0tIGt1ZHp1ClsgLXggL3Vzci9zYmluL21vZHVsZV91cGdy YWRlIF0gJiYgL3Vzci9zYmluL21vZHVsZV91cGdyYWRlIHx8IDoKCiV0cmlnZ2VyaW4gc21w IC0tIGt1ZHp1ClsgLXggL3Vzci9zYmluL21vZHVsZV91cGdyYWRlIF0gJiYgL3Vzci9zYmlu L21vZHVsZV91cGdyYWRlIHx8IDoKCiV0cmlnZ2VyaW4gZW50ZXJwcmlzZSAtLSBrdWR6dQpb IC14IC91c3Ivc2Jpbi9tb2R1bGVfdXBncmFkZSBdICYmIC91c3Ivc2Jpbi9tb2R1bGVfdXBn cmFkZSB8fCA6CgoldHJpZ2dlcmluIEJPT1QgLS0ga3VkenUKWyAteCAvdXNyL3NiaW4vbW9k dWxlX3VwZ3JhZGUgXSAmJiAvdXNyL3NiaW4vbW9kdWxlX3VwZ3JhZGUgfHwgOgoKJXRyaWdn ZXJpbiB0YXBlIC0tIGt1ZHp1ClsgLXggL3Vzci9zYmluL21vZHVsZV91cGdyYWRlIF0gJiYg L3Vzci9zYmluL21vZHVsZV91cGdyYWRlIHx8IDoKCiV0cmlnZ2VyaW4gamVuc2VuIC0tIGt1 ZHp1ClsgLXggL3Vzci9zYmluL21vZHVsZV91cGdyYWRlIF0gJiYgL3Vzci9zYmluL21vZHVs ZV91cGdyYWRlIHx8IDoKCgojIE9sZCBrZXJuZWwtaGVhZGVycyBwYWNrYWdlcyBvd25lZCBp bmNsdWRlIHN5bWxpbmtzOyBuZXcKIyBvbmVzIGp1c3QgbWFrZSB0aGVtIHNvIHRoYXQgd2Ug Y2FuIGhhdmUgbXVsdGlwbGUga2VybmVsLWhlYWRlcnMKIyBwYWNrYWdlcyBpbnN0YWxsZWQu CiV0cmlnZ2VycG9zdHVuIGhlYWRlcnMgLS0ga2VybmVsLWhlYWRlcnMgPCAyLjIuMTYKY2Qg L2Jvb3QKcm0gLWYga2VybmVsLmgKbG4gLXNuZiBrZXJuZWwuaC0le2t2ZXJzaW9ufSBrZXJu ZWwuaApleGl0IDAKCiV0cmlnZ2VycG9zdHVuIHNvdXJjZSAtLSBrZXJuZWwtaGVhZGVycyA8 IDIuMi4xNgpjZCAvdXNyL3NyYwpybSAtZiAle2tzbG5rfQpsbiAtc25mIGxpbnV4LSV7S1ZF UlJFTH0gJXtrc2xua30KZXhpdCAwCgolcG9zdCBzb3VyY2UKY2QgL3Vzci9zcmMKcm0gLWYg JXtrc2xua30KbG4gLXNuZiBsaW51eC0le0tWRVJSRUx9ICV7a3Nsbmt9CgolcG9zdHVuIGhl YWRlcnMKaWYgWyAkMSA9IDAgXTsgdGhlbgogICAgaWYgWyAtTCAvYm9vdC9rZXJuZWwuaCAt YSBgbHMgLWwgL2Jvb3Qva2VybmVsLmggMj4vZGV2L251bGx8IGF3ayAneyBwcmludCAkMTEg fSdgID0gImtlcm5lbC5oLSV7a3ZlcnNpb259IiBdOyB0aGVuCglybSAtZiAvYm9vdC9rZXJu ZWwuaAogICAgZmkKZmkKZXhpdCAwCgolcG9zdHVuIHNvdXJjZQppZiBbIC1MIC91c3Ivc3Jj LyV7a3Nsbmt9IF07IHRoZW4gCiAgICBpZiBbIC1MIC91c3Ivc3JjLyV7a3Nsbmt9IC1hIGBs cyAtbCAvdXNyL3NyYy8le2tzbG5rfSAyPi9kZXYvbnVsbHwgYXdrICd7IHByaW50ICQxMSB9 J2AgPSAibGludXgtJXtLVkVSUkVMfSIgXTsgdGhlbgoJWyAkMSA9IDAgXSAmJiBybSAtZiAv dXNyL3NyYy8le2tzbG5rfQogICAgZmkKZmkKZXhpdCAwCgojIyMKIyMjIGZpbGUgbGlzdHMK IyMjCgolaWYgJXtidWlsZHVwfQolZmlsZXMgCiVkZWZhdHRyKC0scm9vdCxyb290KQovYm9v dC8le2tlcm5lbF9nbG9ifQolaWZhcmNoIGlhNjQKL2Jvb3QvZWZpLyV7a2VybmVsX2dsb2J9 CiVlbmRpZgolaWZhcmNoIHMzOTAgczM5MHgKL2Jvb3QvKi5ib290Ci9ib290L0tlcm50eXBl cy0le0tWRVJSRUx9CiVlbmRpZgovYm9vdC9tb2R1bGUtaW5mby0le0tWRVJSRUx9Ci9ib290 L1N5c3RlbS5tYXAtJXtLVkVSUkVMfQolaWZhcmNoIHBwY2lzZXJpZXMKJWNvbmZpZyAvc2Jp bi9pbnN0YWxsY21kbGluZQolZW5kaWYKJWRpciAvZGV2L3NobQovbGliL21vZHVsZXMvJXtL VkVSUkVMfQolZW5kaWYKCiVpZiAle2J1aWxkc21wfQolaWZuYXJjaCBpMzg2IHMzOTAgczM5 MHgKJWZpbGVzIHNtcAolZGVmYXR0cigtLHJvb3Qscm9vdCkKL2Jvb3QvJXtrZXJuZWxfZ2xv Yn1zbXAKJWlmYXJjaCBpYTY0Ci9ib290L2VmaS8le2tlcm5lbF9nbG9ifXNtcAolZW5kaWYK L2Jvb3QvbW9kdWxlLWluZm8tJXtLVkVSUkVMfXNtcAovYm9vdC9TeXN0ZW0ubWFwLSV7S1ZF UlJFTH1zbXAKJWlmYXJjaCBwcGNpc2VyaWVzCiVjb25maWcgL3NiaW4vaW5zdGFsbGNtZGxp bmUKJWVuZGlmCiVkaXIgL2Rldi9zaG0KL2xpYi9tb2R1bGVzLyV7S1ZFUlJFTH1zbXAKJWVu ZGlmCiVlbmRpZgoKJWlmICV7YnVpbGRlbnRlcnByaXNlfQolZmlsZXMgZW50ZXJwcmlzZQol ZGVmYXR0cigtLHJvb3Qscm9vdCkKL2Jvb3QvJXtrZXJuZWxfZ2xvYn1lbnRlcnByaXNlCi9i b290L21vZHVsZS1pbmZvLSV7S1ZFUlJFTH1lbnRlcnByaXNlCi9ib290L1N5c3RlbS5tYXAt JXtLVkVSUkVMfWVudGVycHJpc2UKJWRpciAvZGV2L3NobQovbGliL21vZHVsZXMvJXtLVkVS UkVMfWVudGVycHJpc2UKJWVuZGlmCgolaWYgJXtidWlsZGRlYnVnfQolZmlsZXMgZGVidWcK JWRlZmF0dHIoLSxyb290LHJvb3QpCi9ib290LyV7ZGVidWdfa2VybmVsX2dsb2J9ZGVidWcK L2Jvb3QvbW9kdWxlLWluZm8tJXtLVkVSUkVMfWRlYnVnCi9ib290L1N5c3RlbS5tYXAtJXtL VkVSUkVMfWRlYnVnCiVkaXIgL2Rldi9zaG0KL2xpYi9tb2R1bGVzLyV7S1ZFUlJFTH1kZWJ1 ZwolZW5kaWYKCiVpZiAle2J1aWxkamVuc2VufQolZmlsZXMgamVuc2VuCiVkZWZhdHRyKC0s cm9vdCxyb290KQovYm9vdC8le2tlcm5lbF9nbG9ifWplbnNlbgovYm9vdC9TeXN0ZW0ubWFw LSV7S1ZFUlJFTH1qZW5zZW4KJWRpciAvZGV2L3NobQovbGliL21vZHVsZXMvJXtLVkVSUkVM fWplbnNlbgolZW5kaWYKCiVpZiAle2J1aWxkdGFwZX0KJWZpbGVzIHRhcGUKJWRlZmF0dHIo LSxyb290LHJvb3QpCi9ib290LyV7a2VybmVsX2dsb2J9dGFwZQovYm9vdC9LZXJudHlwZXMt JXtLVkVSUkVMfQovYm9vdC9tb2R1bGUtaW5mby0le0tWRVJSRUx9dGFwZQovYm9vdC9TeXN0 ZW0ubWFwLSV7S1ZFUlJFTH10YXBlCiVpZmFyY2ggczM5MCBzMzkweAovYm9vdC8qLmJvb3QK JWVuZGlmCiVkaXIgL2Rldi9zaG0KL2xpYi9tb2R1bGVzLyV7S1ZFUlJFTH10YXBlCiVlbmRp ZgoKJWlmICV7YnVpbGRCT09UdGFwZX0KJWZpbGVzIEJPT1R0YXBlCiVkZWZhdHRyKC0scm9v dCxyb290KQovYm9vdC8le2tlcm5lbF9nbG9ifUJPT1R0YXBlCi9ib290L0tlcm50eXBlcy0l e0tWRVJSRUx9Ci9ib290L1N5c3RlbS5tYXAtJXtLVkVSUkVMfUJPT1R0YXBlCiVkaXIgL2Rl di9zaG0KL2xpYi9tb2R1bGVzLyV7S1ZFUlJFTH1CT09UdGFwZQolZW5kaWYKCiVpZiAle2J1 aWxkQk9PVH0KJWZpbGVzIEJPT1QKJWRlZmF0dHIoLSxyb290LHJvb3QpCi9ib290LyV7a2Vy bmVsX2dsb2J9Qk9PVAovYm9vdC9TeXN0ZW0ubWFwLSV7S1ZFUlJFTH1CT09UCiVkaXIgL2Rl di9zaG0KL2xpYi9tb2R1bGVzLyV7S1ZFUlJFTH1CT09UCiVlbmRpZgoKJWlmbmFyY2ggaTU4 NiBpNjg2IHNwYXJjNjQgYXRobG9uCiMgU1RBUlQgQkFTRSBBUkNIRVMgT05MWQolaWZhcmNo IGkzODYgYWxwaGEgc3BhcmMgaWE2NCBzMzkwIHMzOTB4ICV7YWxsX3BwY30KCiVmaWxlcyBz b3VyY2UKJWRlZmF0dHIoLSxyb290LHJvb3QpCiVkaXIgL3Vzci9zcmMvbGludXgtJXtLVkVS UkVMfQovdXNyL3NyYy9saW51eC0le0tWRVJSRUx9L0NPUFlJTkcKL3Vzci9zcmMvbGludXgt JXtLVkVSUkVMfS9DUkVESVRTCi91c3Ivc3JjL2xpbnV4LSV7S1ZFUlJFTH0vRG9jdW1lbnRh dGlvbgovdXNyL3NyYy9saW51eC0le0tWRVJSRUx9L01BSU5UQUlORVJTCi91c3Ivc3JjL2xp bnV4LSV7S1ZFUlJFTH0vTWFrZWZpbGUKL3Vzci9zcmMvbGludXgtJXtLVkVSUkVMfS9SRUFE TUUKL3Vzci9zcmMvbGludXgtJXtLVkVSUkVMfS9SRVBPUlRJTkctQlVHUwovdXNyL3NyYy9s aW51eC0le0tWRVJSRUx9L1J1bGVzLm1ha2UKJWlmYXJjaCAle2FsbF94ODZ9Ci91c3Ivc3Jj L2xpbnV4LSV7S1ZFUlJFTH0vYXJjaC9pMzg2CiVlbHNlCiVpZmFyY2ggJXthbGxfcHBjfQov dXNyL3NyYy9saW51eC0le0tWRVJSRUx9L2FyY2gvcHBjCiVlbHNlCi91c3Ivc3JjL2xpbnV4 LSV7S1ZFUlJFTH0vYXJjaC8le190YXJnZXRfY3B1fQolZW5kaWYKJWVuZGlmCiVpZmFyY2gg c3BhcmMKL3Vzci9zcmMvbGludXgtJXtLVkVSUkVMfS9hcmNoL3NwYXJjNjQKJWVuZGlmCi91 c3Ivc3JjL2xpbnV4LSV7S1ZFUlJFTH0vZHJpdmVycwovdXNyL3NyYy9saW51eC0le0tWRVJS RUx9L2ZzCi91c3Ivc3JjL2xpbnV4LSV7S1ZFUlJFTH0vaW5pdAovdXNyL3NyYy9saW51eC0l e0tWRVJSRUx9L2lwYwovdXNyL3NyYy9saW51eC0le0tWRVJSRUx9L2tlcm5lbAovdXNyL3Ny Yy9saW51eC0le0tWRVJSRUx9L2xpYgovdXNyL3NyYy9saW51eC0le0tWRVJSRUx9L21tCi91 c3Ivc3JjL2xpbnV4LSV7S1ZFUlJFTH0vbmV0Ci91c3Ivc3JjL2xpbnV4LSV7S1ZFUlJFTH0v c2NyaXB0cwolaWZhcmNoICV7YWxsX3g4Nn0KJXs/aWJjc18xOi91c3Ivc3JjL2xpbnV4LSV7 S1ZFUlJFTH0vYWJpfQolZW5kaWYKJWlmYXJjaCAle2FsbF94ODZ9Ci91c3Ivc3JjL2xpbnV4 LSV7S1ZFUlJFTH0va2RiCiVlbmRpZgovdXNyL3NyYy9saW51eC0le0tWRVJSRUx9L2NvbmZp Z3MKJWlmYXJjaCBzcGFyYwovdXNyL3NyYy9saW51eC0le0tWRVJSRUx9L2luY2x1ZGUvYXNt LXNwYXJjCi91c3Ivc3JjL2xpbnV4LSV7S1ZFUlJFTH0vaW5jbHVkZS9hc20tc3BhcmM2NAol ZWxzZQolaWZhcmNoICV7YWxsX3g4Nn0KL3Vzci9zcmMvbGludXgtJXtLVkVSUkVMfS9pbmNs dWRlL2FzbS1pMzg2CiVlbHNlCiVpZmFyY2ggJXthbGxfcHBjfQovdXNyL3NyYy9saW51eC0l e0tWRVJSRUx9L2luY2x1ZGUvYXNtLXBwYwolZWxzZQovdXNyL3NyYy9saW51eC0le0tWRVJS RUx9L2luY2x1ZGUvYXNtLSV7X3RhcmdldF9jcHV9CiVlbmRpZgolZW5kaWYKJWVuZGlmCiVp ZmFyY2ggJXthbGxfcHBjfQojIGJlY2F1c2Ugc29tZSBwcGMgQW1pZ2Egc3R1ZmYgcmVmZXJl bmNlcyBzb21lIDY4MDAwIEFtaWdhIHN0dWZmCi91c3Ivc3JjL2xpbnV4LSV7S1ZFUlJFTH0v aW5jbHVkZS9hc20tbTY4awolZW5kaWYKL3Vzci9zcmMvbGludXgtJXtLVkVSUkVMfS9pbmNs dWRlL2FzbQovdXNyL3NyYy9saW51eC0le0tWRVJSRUx9L2luY2x1ZGUvYXNtLWdlbmVyaWMK JWlmYXJjaCAle2FsbF94ODZ9CiV7P2liY3NfMTovdXNyL3NyYy9saW51eC0le0tWRVJSRUx9 L2luY2x1ZGUvYWJpfQolZW5kaWYKL3Vzci9zcmMvbGludXgtJXtLVkVSUkVMfS9pbmNsdWRl L2xpbnV4Ci91c3Ivc3JjL2xpbnV4LSV7S1ZFUlJFTH0vaW5jbHVkZS9uZXQKL3Vzci9zcmMv bGludXgtJXtLVkVSUkVMfS9pbmNsdWRlL3BjbWNpYQovdXNyL3NyYy9saW51eC0le0tWRVJS RUx9L2luY2x1ZGUvc2NzaQovdXNyL3NyYy9saW51eC0le0tWRVJSRUx9L2luY2x1ZGUvdmlk ZW8KJWRpciAvdXNyL3NyYy9saW51eC0le0tWRVJSRUx9L2luY2x1ZGUKJWRpciAvdXNyL3Ny Yy9saW51eC0le0tWRVJSRUx9L2FyY2gKJWlmYXJjaCBhbHBoYSBzcGFyYyBzMzkwIHMzOTB4 Ci91c3Ivc3JjL2xpbnV4LSV7S1ZFUlJFTH0vaW5jbHVkZS9tYXRoLWVtdQolZW5kaWYgIAoK JWZpbGVzIGhlYWRlcnMKJWRlZmF0dHIoLSxyb290LHJvb3QpCi91c3IvaW5jbHVkZS9saW51 eAovdXNyL2luY2x1ZGUvYXNtCiVpZmFyY2ggc3BhcmMKL3Vzci9pbmNsdWRlL2FzbS1zcGFy YwovdXNyL2luY2x1ZGUvYXNtLXNwYXJjNjQKJWVuZGlmCi9ib290L2tlcm5lbC5oLSV7a3Zl cnNpb259CgolZmlsZXMgZG9jCiVkZWZhdHRyKC0scm9vdCxyb290KQolZG9jIGxpbnV4L0Rv Y3VtZW50YXRpb24vKgoKJWVuZGlmCiMgRU5EIEJBU0UgQVJDSEVTIE9OTFkKJWVuZGlmCgol Y2hhbmdlbG9nCiogVHVlIEphbiA4IDIwMDIgQXJqYW4gdmFuIGRlIFZlbiA8YXJqYW52QHJl ZGhhdC5jb20+Ci0gYWRkZWQgZXhwZXJpbWVudGFsIGVtdTEwayBkcml2ZXIgCgoqIEZyaSBK YW4gNCAyMDAyIEJlbmphbWluIExhSGFpc2UgPGJjcmxAcmVkaGF0LmNvbT4KLSBmaXggYnVn IGluIHBhZ2VfbGF1bmRlcgoKKiBUaHUgRGVjIDIwIDIwMDEgTWljaGFlbCBLLiBKb2huc29u IDxqb2huc29ubUByZWRoYXQuY29tPgotIEZpeCBzdGF0aWMgYnVpbGQgb2YgREFDOTYwIChl dmVuIHRob3VnaCB3ZSBkb24ndCBidWlsZCBpdCBzdGF0aWMuLi4pCgoqIFR1ZSBEZWMgMTgg MjAwMSBNaWNoYWVsIEsuIEpvaG5zb24gPGpvaG5zb25tQHJlZGhhdC5jb20+Ci0gQWRkZWQg d2F0Y2hkb2cgcGF0Y2gKLSBGaXhlZCBkbWEgbWFzayBzaWduZWRuZXNzIHByb2JsZW0KCiog TW9uIERlYyAxNyAyMDAxIEhhcmFsZCBIb3llciA8aGFyYWxkQHJlZGhhdC5kZT4gMi40Ljkt MTcuMy1zMzkwCi0gSUJNIHBhdGNoc2V0IG5vLiA0IGFkZGVkCi0gcHJvY2ZzIHBhdGNoCi0g bGludXgga2VybmVsIGNyYXNoIGR1bXAgc3VwcG9ydAotIC9ib290L0tlcm50eXBlcy0ke3Zl cnNpb259IHdpdGggLWdzdGFicwotIG1hdGhlbXUgcGF0Y2gKLSBJUFY2IGVuYWJsZWQKLSBz ZWNvbmQgcmFtZGlzawoKKiBTYXQgRGVjIDE1IDIwMDEgUGV0ZSBaYWl0Y2V2IDx6YWl0Y2V2 QHJlZGhhdC5jb20+Ci0gdXBkYXRlIHVzYi9wZWdhc3VzLCAjNTc1MzEgLSBkb3ducG9ydCBm cm9tIDIuNC4xNgoKKiBXZWQgRGVjIDEzIDIwMDEgQmVuamFtaW4gTGFIYWlzZSA8YmNybEBy ZWRoYXQuY29tPgotIHVwZGF0ZSBuczgzODIwLmMgdG8gMC4xNQoKKiBUaHUgRGVjIDEzIDIw MDEgQXJqYW4gdmFuIGRlIFZlbiA8YXJqYW52QHJlZGhhdC5jb20+Ci0gYWRkZWQgRG91Zydz IHBhdGNoIGZvciBpODEwCgoqIFdlZCBEZWMgMTIgMjAwMSBBcmphbiB2YW4gZGUgVmVuIDxh cmphbnZAcmVkaGF0LmNvbT4KLSB1cGRhdGVkIHFsYTIyMDAvMjMwMCBkcml2ZXIKCiogVHVl IERlYyAxMSAyMDAxIEJlbmphbWluIExhSGFpc2UgPGJjcmxAcmVkaGF0LmNvbT4KLSBhZGQg bGludXgtMi40LjktbmZzX3N2Y19xdWlldC5wYXRjaCB0byBzaWxlbmNlIGxvZ2dpbmcgb2Yg bmZzIHBpbmdzCgoqIE1vbiBEZWMgMTAgMjAwMSBTdGVwaGVuIEMuIFR3ZWVkaWUgPHNjdEBy ZWRoYXQuY29tPgotIE1lcmdlIGluIGltcG9ydGFudCBleHQzIGZpeGVzIGJldHdlZW4gZXh0 My0wLjkuMTEgYW5kIDAuOS4xNjoKICogUmVtb3ZlIHJlZHVuZGFudCBNT0RVTEVfTElDRU5T RSgpCiAqIERvbid0IGRvIHNob3dfc3RhY2soKSBvbiBhcmNocyB3aGljaCBkb24ndCBoYXZl IGl0CiAqIEZpeCBhIHJhcmUgRUZBVUxUIGhpbWVtIGhhbmRsaW5nIGNhc2UKICogRml4IGEg cmFyZSByYWNlIGJldHdlZW4gdHJ1bmNhdGUgYW5kIHdyaXRlCiAqIERvbid0IHVzZSBhdG9t aWMgYml0b3BzIG9uIGludCB2YWx1ZXMgKGNhbiBicmVhayBvbiA2NC1iaXQpCgotIEFsc28g bW92ZSB0aGUgZGlyIHJlYWRhaGVhZCBmaXggaW50byB0aGUgZ2VuZXJhbCBleHQzLXVwZGF0 ZXMgcGF0Y2guCgoqIFRodSBEZWMgMDYgMjAwMSBQZXRlIFphaXRjZXYgPHphaXRjZXZAcmVk aGF0LmNvbT4KLSBGaXggZm9yICM1NTQyMCAoc2NzaSBvb3BzZXMpCgoqIFRodSBEZWMgMDYg MjAwMSBBcmphbiB2YW4gZGUgVmVuIDxhcmphbnZAcmVkaGF0LmNvbT4KLSBlbmFibGUgaGln aG1lbSBmb3IgbWVnYXJhaWQKLSBmaXggY3JhbWZzIFNNUCBpc3N1ZXMKCiogVHVlIERlYyAw NCAyMDAxIE1pY2hhZWwgSy4gSm9obnNvbiA8am9obnNvbm1AcmVkaGF0LmNvbT4KLSB1cGRh dGUgdG8gdWRmIDAuOS41IGZvciB0ZXN0aW5nCi0gdXBkYXRlIHRvIERBQzk2MCAyLjQuMTEK CiogVHVlIERlYyAwNCAyMDAxIEFyamFuIHZhbiBkZSBWZW4gPGFyamFudkByZWRoYXQuY29t PgotIHVwZGF0ZWQgcWxvZ2ljIGRyaXZlcgotIHVwZGF0ZWQgaG90cGx1ZyBwY2kKCiogTW9u IERlYyAwMyAyMDAxIFBldGUgWmFpdGNldiA8emFpdGNldkByZWRoYXQuY29tPgotIG1hZGUg bGludXgtMi40LjktczM5MC1yZWFscm9vdGRldi5wYXRjaCBhcmNoaXRlY3R1cmUgbmV1dHJh bC4KCiogVHVlIE5vdiAyNyAyMDAxIEFyamFuIHZhbiBkZSBWZW4gPGFyamFudkByZWRoYXQu Y29tPgotIHVwZGF0ZWQgcWxvZ2ljIGRyaXZlcgoKKiBNb24gTm92IDI2IDIwMDEgQXJqYW4g dmFuIGRlIFZlbiA8YXJqYW52QHJlZGhhdC5jb20+Ci0gZml4IGhhbmcgd2l0aCBpZGVmbG9w cHkgb24gdmlhICgjNTY2MTMpCgoqIEZyaSBOb3YgMDkgMjAwMSBBcmphbiB2YW4gZGUgVmVu IDxhcmphbnZAcmVkaGF0LmNvbT4KLSBhZGRlZCBvZmZpY2lhbCBWSUEgZml4IGZvciB0aGUg YXRobG9uIGNyYXNoIGJ1ZwoKKiBUaHUgTm92IDA4IDIwMDEgQXJqYW4gdmFuIGRlIFZlbiA8 YXJqYW52QHJlZGhhdC5jb20+Ci0gYWRkZWQgSW5nbydzIHNtcCBzY2hlZHVsZXIgaW1wcm92 ZW1lbnQKLSBhZGRlZCBjcHVfcmVsYXgoKSBwYXRjaAoKKiBUdWUgTm92IDA2IDIwMDEgQXJq YW4gdmFuIGRlIFZlbiA8YXJqYW52QHJlZGhhdC5jb20+Ci0gZml4ZWQgYW5vdGhlciBzL1VM T05HL3Vuc2lnbmVkIGxvbmcvIHRvIHUzMiBidWcgaW4gZTEwMDAgCi0gYWRkZWQgQWwgVmly bydzIC9wcm9jL21vdW50cyBvdmVyZmxvdyBmaXgKLSBhZGQgZmFuY3kgc3cgaW8gbW11IHNw ZWVkIHdvcmthcm91bmQKCiogTW9uIE5vdiAwNSAyMDAxIEhhcmFsZCBIb3llciA8aGFyYWxk QHJlZGhhdC5kZT4gMi40LjktMTMtczM5MAotIHNwZWNmaWxlIGZpeGVzIGZvciB0YXBlIGtl cm5lbAoKKiBXZWQgT2N0IDMxIDIwMDEgSGFyYWxkIEhveWVyIDxoYXJhbGRAcmVkaGF0LmRl PiAyLjQuOS05LjEtczM5MAotIGNvbXBpbGVkIGluIGV4dDMgYW5kIGRhc2QgaW4gbm9ybWFs IGtlcm5lbAoKKiBUdWUgT2N0IDMwIDIwMDEgSGFyYWxkIEhveWVyIDxoYXJhbGRAcmVkaGF0 LmRlPiAyLjQuOS05LjEtczM5MAotIHMzOTAgdmVyc2lvbgotIHBvcnRlZCBJQk0gMi40Ljcg cGF0Y2ggMgotIGludGVncmF0ZWQgREFTRCBwYXRjaCBmcm9tIHphaXRjZXZAcmVkaGF0LmNv bQoKKiBNb24gT2N0IDI5IDIwMDEgQXJqYW4gdmFuIGRlIFZlbiA8YXJqYW52QHJlZGhhdC5j b20+Ci0gYWRkIGZpeCBmb3IgcmFjZSBpbiB0dHkgc3dpdGNoaW5nIGNvZGUKCiogV2VkIE9j dCAyNCAyMDAxIFN0ZXBoZW4gQy4gVHdlZWRpZSA8c2N0QHJlZGhhdC5jb20+Ci0gR2V0IHBh Z2UgbWFwcGluZ3MgcmlnaHQgYWZ0ZXIgRUZBVUxUIG9uIGhpZ2htZW0gcGFnZSBjYWNoZSB3 cml0ZXMKCiogVHVlIE9jdCAyMyAyMDAxIEJpbGwgTm90dGluZ2hhbSA8bm90dGluZ0ByZWRo YXQuY29tPgotIGZpeCBzaG9ydCByZWFkKCkgaW4gR1BUIGNvZGUKCiogVHVlIE9jdCAxNiAy MDAxIFBldGUgWmFpdGNldiA8emFpdGNldkByZWRoYXQuY29tPgotIEtpbGxlZCBwb3J0LXNw ZWNpZmljIF9fY3B1X3JhaXNlX3NvZnRpcnEgb24gczM5MCBhbmQgczM5MHggKHdhcm5pbmcg Zmxvb2QpCi0gUmVtb3ZlZCBsb29wZml4IHBhcnQgZnJvbSBsaW51eC0yLjQuOS1zMzkwLWFj MTEucGF0Y2gsIG5vdyBnZW5lcmljLgoKKiBTYXQgT2N0IDEzIDIwMDEgUGV0ZSBaYWl0Y2V2 IDx6YWl0Y2V2QHJlZGhhdC5jb20+Ci0gdXNiLXVoY2kgYnVnZml4IGZyb20gbWFpbnN0cmVh bSwgdW50aWwgaXQgcmVhY2hlcyB1cyBkb3duIHRoZSBsaW5lCgoqIFdlZCBPY3QgMTAgMjAw MSBQZXRlIFphaXRjZXYgPHphaXRjZXZAcmVkaGF0LmNvbT4KLSBpZGUtdGFwZSBmaXggZm9y IEhQIENvbG9yYWRvLCAjMzY2MjgKCiogTW9uIE9jdCA4IDIwMDEgQXJqYW4gdmFuIGRlIFZl biA8YXJqYW52QHJlZGhhdC5jb20+Ci0gTmV3IEJyb2FkY29tIDU3MDAvNTcwMSBkcml2ZXIg dmVyc2lvbgotIHB0cmFjZSBwYXRjaGVzCgoqIE1vbiBPY3QgOCAyMDAxIFN0ZXBoZW4gVHdl ZWRpZSA8c2N0QHJlZGhhdC5jb20+Ci0gRml4IGV4dDMgZGlyZWN0b3J5IHJlYWRhaGVhZCBi dWcgb24gZW1wdHkgKGRlbGV0ZWQpIGRpcmVjdG9yaWVzCgoqIFN1biBPY3QgNyAyMDAxIEFy amFuIHZhbiBkZSBWZW4gPGFyamFudkByZWRoYXQuY29tPgotIG1lcmdlIDIuNC4xMC1hYzcg YnVnZml4ZXMKLSBtYWtlIGFscGhhIGNvbXBpbGUgYWdhaW4KCiogRnJpIE9jdCA1IDIwMDEg U3RlcGhlbiBUd2VlZGllIDxzY3RAcmVkaGF0LmNvbT4KLSBCcmluZyBleHQzIHVwIHRvIHZl cnNpb24gMC45LjExCgoqIEZyaSBPY3QgNSAyMDAxIEFyamFuIHZhbiBkZSBWZW4gPGFyamFu dkByZWRoYXQuY29tPgotIHdlbnQgYmFjayB0byBvbGQgZW11MTBrIGRyaXZlcjsgdGhlIG5l dyBvbmUgaGFzIHRvbyBtYW55IHByb2JsZW1zCi0gYWRkZWQgUFBQIG92ZXIgQVRNIHBhdGNo CgoqIFRodSBPY3QgNCAyMDAxIEFyamFuIHZhbiBkZSBWZW4gPGFyamFudkByZWRoYXQuY29t PgotIG1lcmdlZCBhIGZldyAyLjQuOS1hYzE4IGJ1Z2ZpeGVzCgoqIFdlZCBPY3QgMyAyMDAx IEFyamFuIHZhbiBkZSBWZW4gPGFyamFudkByZWRoYXQuY29tPgotIGZpeGVkIGhvdHBsdWcg ZHJpdmVyIHRvIG1ha2Ugc3lzdGVtIGxvYWQgbm90IDEuMDAKCiogTW9uIE9jdCAxIDIwMDEg QXJqYW4gdmFuIGRlIFZlbiA8YXJqYW52QHJlZGhhdC5jb20+Ci0gdXBkYXRlIHFsYTEyODAg ZHJpdmVyCgoqIFdlZCBTZXAgMjUgMjAwMSBBcmphbiB2YW4gZGUgVmVuIDxhcmphbnZAcmVk aGF0LmNvbT4KLSB1cGRhdGUgU2VydmVycmFpZCBkcml2ZXIKLSBhZGQgcXVpdGUgYSBmZXcg TU9EVUxFX0xJQ0VOU0UoKSB0YWdzCi0gcmV2ZXJ0IGdlbmRpc2sgcGF0Y2ggZnJvbSAtYWMx MAotIGFkZCAidGFpbnRlZCIgcGF0Y2ggZnJvbSBLZWl0aCBPd2VucwoKKiBNb24gU2VwIDIz IDIwMDEgQXJqYW4gdmFuIGRlIFZlbiA8YXJqYW52QHJlZGhhdC5jb20+Ci0gdXBkYXRlZCBh dGFyYWlkIHRvIGxhdGVzdCB2ZXJzaW9ucwotIHVwZGF0ZWQgdG8gYmxvY2sgaGlnaG1lbSBw YXRjaCB2ZXJzaW9uIDE1IAotIHVwZGF0ZWQgaG90cGx1Z3BjaSBwYXRjaAoKKiBTdW4gU2Vw IDIzIDIwMDEgQXJqYW4gdmFuIGRlIFZlbiA8YXJqYW52QHJlZGhhdC5jb20+Ci0gQWRkIFJp ayB2YW4gUmllbHMgVk0gdHVuaW5nIHBhdGNoCgoqIFN1biBTZXAgMjMgMjAwMSBGbG9yaWFu IExhIFJvY2hlIDxGbG9yaWFuLkxhUm9jaGVAcmVkaGF0LmRlPgotIHVwZGF0ZSBzMzkwIHBh dGNoZXMgdG8gMi40LjlhYzE0Ci0gc3RhcnQgczM5MHggc3VwcG9ydAotIGFkZCBwcmludGsg cGF0Y2ggYWdhaW4KCiogRnJpIFNlcCAyMSAyMDAxIEluZ28gTW9sbmFyIDxtaW5nb0ByZWRo YXQuY29tPgotIHVwZGF0ZSBUVVgKCiogRnJpIFNlcCAyMSAyMDAxIEFyamFuIHZhbiBkZSBW ZW4gPGFyamFudkByZWRoYXQuY29tPgotIGFkZGVkIGFpYzd4eHhfb2xkIHRvIHRoZSAiaGln aG1lbSBjYXBhYmxlIiBkZXZpY2VsaXN0CgoqIE1vbiBTZXAgMTcgMjAwMSBBcmphbiB2YW4g ZGUgVmVuIDxhcmphbnZAcmVkaGF0LmNvbT4KLSB1cGRhdGUgSmVucycgYmxvY2sgaGlnaG1l bSBwYXRjaAotIGFkZCBwYXRjaCBmb3IgNDhiaXQgSURFIExCQSAKLSB1cGRhdGVkIGUxMDAv ZTEwMDAgZHJpdmVycwotIGFkZGVkIHNkIG1heHNlY3RvcnMgcGF0Y2gKCiogU2F0IFNlcCAx NSAyMDAxIEZsb3JpYW4gTGEgUm9jaGUgPEZsb3JpYW4uTGFSb2NoZUByZWRoYXQuZGU+Ci0g cHV0IGFsbCBSZWQgSGF0IHNwZWNpZmljIHMzOTAgcGF0Y2hlcyBpbiBvbmUgZmlsZQoKKiBU aHUgU2VwIDEzIDIwMDEgQXJqYW4gdmFuIGRlIFZlbiA8YXJqYW52QHJlZGhhdC5jb20+Ci0g bWFrZSBmcmVldnhmcyBhdXRvbG9hZAoKKiBNb24gU2VwIDEwIDIwMDEgQXJqYW4gdmFuIGRl IFZlbiA8YXJqYW52QHJlZGhhdC5jb20+Ci0gZ28gdG8gMi40LjktYWMxMAotIHVwZGF0ZSBs aW51eC1hYmkgdG8gdXBzdHJlYW0gMi40LjktMCB2ZXJzaW9uCgoqIFRodSBTZXAgMDYgMjAw MSBBcmphbiB2YW4gZGUgVmVuIDxhcmphbnZAcmVkaGF0LmNvbT4KLSBmaXggb29wcyBpbiBp YTY0IHVud2luZCAoIzUyNDg2KQotIGFkZGVkIC9wcm9jL3VuYWxpZ25lZGluZm8gZm9yIGlh NjQgKCM0MjMxMCkgd2hpbGUKICBkaXNhYmxpbmcgdGhlIGV2aWwgcHJpbnRrJ3MKCiogV2Vk IFNlcCAwNSAyMDAxIEFyamFuIHZhbiBkZSBWZW4gPGFyamFudkByZWRoYXQuY29tPgotIGdv IHRvIDIuNC45LWFjNwoKKiBGcmkgQXVnIDMxIDIwMDEgTWljaGFlbCBLLiBKb2huc29uIDxq b2huc29ubUByZWRoYXQuY29tPgotIG1ha2UgcXVvdGEgbWVzc2FnZXMgbG9vayBzYW5lcgot IHBjaSBob3RwbHVnIG1vZHVsYXIKCiogVHVlIEF1ZyAyOCAyMDAxIEFyamFuIHZhbiBkZSBW ZW4gPGFyamFudkByZWRoYXQuY29tPgotIGZpeGVkIG9vcHMgb24gaWVlZTEzOTQgZGlzY29u bmVjdAoKKiBNb24gQXVnIDI3IDIwMDEgQXJqYW4gdmFuIGRlIFZlbiA8YXJqYW52QHJlZGhh dC5jb20+Ci0gYWRkIGdydWJieSB0byAlcG9zdCBhbmQgJXByZXVuIHRvIGF1dG9tYXRpY2Fs bHkgY2hhbmdlIGdydWIuY29uZgotIGFkZGVkIHBhdGNoIHRvIGZpeCAjNTA3ODUgKGNpcGUg ZG9lc24ndCByZWxvYWQpCi0gbWlub3IgdXBkYXRlcyBmcm9tIDIuNC45LWFjMQoKKiBNb24g QXVnIDI3IDIwMDEgU3RlcGhlbiBDLiBUd2VlZGllIDxzY3RAcmVkaGF0LmNvbT4KLSBCcmlu ZyBleHQzIHVwIHRvIHZlcnNpb24gMC45Ljg6IGZpeGVzIGFuIE5GUyBvb3BzLCBjbGVhbnMg dXAgc29tZQogIHByaW50ayBsb2cgbGV2ZWxzLCB1cGRhdGVzIGVycm9yIHN0YXRlIG9uIGRp c2sgbW9yZSByaWdvcm91c2x5IGFuZAogIGFkZHMgYSAiZG9fc3luY19zdXBlcnMiIG1vZHVs ZSBwYXJhbWV0ZXIgdG8gYWxsb3cgdGhlICBzeWNocm9ub3VzCiAgc3VwZXJibG9jayBmbHVz aCBiZWhhdmlvdXIgb2YgZXh0My0wLjkuNiB0byBiZSByZXN0b3JlZCBvbiBkZW1hbmQuIAoK KiBTYXQgQXVnIDI1IDIwMDEgSW5nbyBNb2xuYXIgPG1pbmdvQHJlZGhhdC5jb20+Ci0gZml4 IHRoZSBhY2VuaWMgZHJpdmVyIGJ1ZyB0aGF0IGNhdXNlZCByYW5kb20ga2VybmVsIG1lbW9y eSBiZWluZwogIHNlbnQgb3V0IG9uIHRoZSB3aXJlLCBvbiB4ODYgc3lzdGVtcyB3aXRoIG1v cmUgdGhhbiA0IEdCIFJBTS4KCiogU2F0IEF1ZyAyNSAyMDAxIEFyamFuIHZhbiBkZSBWZW4g PGFyamFudkByZWRoYXQuY29tPgotIGJhY2tvdXQgb3V0IHRoZSBld3JrMyBkcml2ZXIgdG8g dGhlIDIuNC4yIHZlcnNpb24gKCM1MTk2MSkKICBhcyB0aGF0IG9uZSB3b3JrZWQuCi0gZGlz YWJsZWQgb29tIG1vZGVyYXRpb24KLSBhZGRlZCB0dWxpcF9vbGQgZHJpdmVyICh0aGUgMi40 LjIvMi40LjMgdmVyc2lvbikgKCM0OTk2NiwgIzUxNjIyKQotIGFkZGVkIERvdWcncyBsYXRl c3QgaTgxMCBkcml2ZXIgKCM0OTg3NikKLSBmaXhlZCBVU0IgZGV2aWNlIHRhYmxlICgjNTEy MjkpCgoqIEZyaSBBdWcgMjQgMjAwMSBCZW5qYW1pbiBMYUhhaXNlIDxiY3JsQHJlZGhhdC5j b20+Ci0gdXBkYXRlIG5zODM4MjAgdG8gdjAuMTAKCiogRnJpIEF1ZyAyNCAyMDAxIFBldGUg WmFpdGNldiA8emFpdGNldkByZWRoYXQuY29tPgotIEZpeCBmb3IgNTIyMjkKCiogRnJpIEF1 ZyAyMyAyMDAxIEFyamFuIHZhbiBkZSBWZW4gPGFyamFudkByZWRoYXQuY29tPgotIHVwZGF0 ZWQgZTEwMDAgZHJpdmVyICgjNTIxNTQpCi0gcmVtb3ZlZCAvc2Jpbi9pbnN0YWxsa2VybmVs IGZyb20gdGhlIGtlcm5lbCBycG0gKG1vdmVkIAogIHRvIHRoZSBpbml0c2NyaXB0cyBycG0p Ci0gY3JlYXRlZCAnbm9hdGhsb24nIERNSSBibGFja2xpc3QgZW50cnkgZm9yIE1TSSBNUy02 MzMwIG1vdGhlcmJvYXJkcwotIGZpeGVkIHRhc2tsZXQgYnVnIHJlcG9ydGVkIGJ5IGJvdGgg QnJvYWRjb20gYW5kIEludGVsCi0gYmFja291dCBhIHNlZ21lbnQgcmVsb2FkIG9wdGltaXNh dGlvbiwgbGttbCBoYXMgYmFkIGJ1Z3JlcG9ydHMgYWJvdXQgaXQKLSBhZGRlZCBhaWM3eHh4 IGNvbmZpZyBvcHRpb24gcGF0Y2ggKERvdWcpCgoqIEZyaSBBdWcgMjMgMjAwMSBTdGVwaGVu IEMuIFR3ZWVkaWUgPHNjdEByZWRoYXQuY29tPgotIGFkZGVkIHVwdG9kYXRlIGV4dDMgY29k ZSBmcm9tIHRoZSBleHQzIGFib3J0LWhhbmRsZS1icmFuY2gKICB0byBoYW5kbGUgdGFraW5n IHRoZSBmaWxlc3lzdGVtIG9mZmxpbmUvcmVhZG9ubHkgb24gZmF0YWwgZXJyb3IKICBjbGVh bmx5LgoKKiBUaHUgQXVnIDIyIDIwMDEgQmVuamFtaW4gTGFIYWlzZSA8YmNybEByZWRoYXQu Y29tPgotIGFkZGVkIGNsZWFyX3BhZ2VfdGFibGVzIGxvY2sgcGF0Y2gKCiogVGh1IEF1ZyAy MiAyMDAxIEFyamFuIHZhbiBkZSBWZW4gPGFyamFudkByZWRoYXQuY29tPgotIGFkZGVkIHBl cmlvZGljIHNocmluayBvZiBpY2FjaGUgKCM1MjM3NCkKLSBtZXJnZWQgdHJpdmlhbCBWTSB0 dW5pbmcgcGF0Y2ggZnJvbSAyLjQuOC1hYzkKLSBhZGRlZCBtb3JlIHJlc2VydmF0aW9uIGJv dW5jZWJ1ZmZlcnMgCiAgZm9yIGhpZ2htZW0gcGVyZm9ybWFuY2UgKCM1MjM0MCkKLSB1cGRh dGVkIGUxMDAgZHJpdmVyIHRvIGxhdGVzdCB2ZXJzaW9uCgoqIFdlZCBBdWcgMjIgMjAwMSBB cmphbiB2YW4gZGUgVmVuIDxhcmphbnZAcmVkaGF0LmNvbT4KLSBtZXJnZWQgUzM5MCBwYXRj aGVzIGZyb20gYmVybwotIHJlbW92ZWQgZG1pIGNodW5rICgjNTE0NTgpCi0gbWVyZ2VkIGJ1 Z2ZpeGVzIGZyb20gMi40LjgtYWM5IAotICogcG9zaXh0aHJlYWRzIHRpZCE9cGlkIHBhdGNo Ci0gKiBzY3NpIHRhcGUgYnVnZml4ZXMKCiogVHVlIEF1ZyAyMSAyMDAxIEFyamFuIHZhbiBk ZSBWZW4gPGFyamFudkByZWRoYXQuY29tPgotIGFkZCBzY3NpIGhhbmcgZml4IGFuZCBVU0Ig bmV0IGhhbmcgZml4IGZyb20gMi40LjgtYWM4CgoqIE1vbiBBdWcgMjAgMjAwMSBNaWNoYWVs IEsuIEpvaG5zb24gPGpvaG5zb25tQHJlZGhhdC5jb20+Ci0gbW9kaWZpY2F0aW9uIHRvIGUx MDAwIGRyaXZlciBhdCBJbnRlbCdzIHJlcXVlc3QgKCM0OTU3MSkKCiogTW9uIEF1ZyAyMCAy MDAxIEFyamFuIHZhbiBkZSBWZW4gPGFyamFudkByZWRoYXQuY29tPgotIGFkZGVkIFBDSSBJ RCdzIGZvciBLVDEzM0EgY2hpcHNldCB0byBBR1AvRFJNCi0gYWRkZWQgUzM5MCB0YXBlIHBh dGNoIChiZXJvKQotIGFkZCBtaXNzaW5nIEZyaXR6IFBDTUNJQSBkcml2ZXIgKCM1MDk5OSkK LSByZW1vdmVkIENPTkZJR19CTEtfREVWX09GRkJPQVJEICgjNTIwNzMpIGFzIGl0IHdhcyBi b2d1cwotIG1lcmdlZCBzZXZlcmFsIERSTSBmaXhlcyBmcm9tIDIuNC43LWFjNwoKKiBTYXQg QXVnIDE4IDIwMDEgQXJqYW4gdmFuIGRlIFZlbiA8YXJqYW52QHJlZGhhdC5jb20+Ci0gZml4 IG9vcHMgaW4gTkZTIGNvZGUKLSBtZXJnZWQgIkRSTSBzY3JpYmJsZXMgbWVtb3J5IiBwYXRj aCBmcm9tIFN1U0UKCiogRnJpIEF1ZyAxNyAyMDAxIEFyamFuIHZhbiBkZSBWZW4gPGFyamFu dkByZWRoYXQuY29tPgotIGZpeCBjcml0aWNhbCBidWdmaXhlcyBmcm9tIDIuNC44LWFjNjoK LSAgKiBjcHUgZmxhZ3MgYXJlIHVuc2lnbmVkIGxvbmcsIG5vdCBpbnQgKDY0IGJpdCBpc3N1 ZSkKCiogVGh1IEF1ZyAxNiAyMDAxIEJlbmphbWluIExhSGFpc2UgPGJjcmxAcmVkaGF0LmNv bT4KLSBhZGRlZCBsaW51eC0yLjQuOS12bWFfbWVyZ2VfZnVsbC5wYXRjaCB2bWEgbWVyZ2lu ZyBwYXRjaCB0aGF0CiAgc3BlZWRzIHVwIG1vemlsbGEgYW5kIGdjYyBxdWl0ZSBhIGJpdAoK KiBUaHUgQXVnIDE1IDIwMDEgQXJqYW4gdmFuIGRlIFZlbiA8YXJqYW52QHJlZGhhdC5jb20+ Ci0gSUtEIGluY2x1ZGVkIGZvciB0aGUgZGVidWcga2VybmVsCi0gYWRkIGJjbTU3MDAgYnVn Zml4ZXMgKFBDSSBhY2Nlc3MgZnVuY3Rpb25zKQotIHVwZ3JhZGVkIHd2bGFuX2NzIHRvIG5v dCBzbGVlcCB3aXRoIHNwaW5sb2NrcyBoZWx0ICgjNTE1MDcpCi0gYWRkZWQgIm5vYXRobG9u IiBib290ZmxhZyAoIzUwOTI2KQotIHVwZGF0ZWQgaWE2NCBkcm0gdG8gdXBzdHJlYW0gdmVy c2lvbiwgaWZhcmNoIGlhNjQgb25seQoKKiBXZWQgQXVnIDE1IDIwMDEgTWljaGFlbCBLLiBK b2huc29uIDxqb2huc29ubUByZWRoYXQuY29tPgotIGNsZWFuIHVwIGZpbGVsaXN0cyBhIGJp dCwgYWRkIGFsbF94ODYKCiogV2VkIEF1ZyAxNSAyMDAxIEFyamFuIHZhbiBkZSBWZW4gPGFy amFudkByZWRoYXQuY29tPgotIGZpeCAiY2FyZGJ1cyBoYXMgSVJRIDAgYW5kIGNyYXNoZXMi IGJ1ZyAoIzUxNzA2KQotIHVwZGF0ZSBpODEwIGRyaXZlciB0byBmaXggb29wc2VzIChEb3Vn KQotIGFkZCBwYXRjaCBmcm9tIDIuNC43LWFjNSB0byBmaXggYSB0aGlua28gaW4gdGhlIFZN CgoqIFdlZCBBdWcgMTUgMjAwMSBQZXRlIFphaXRjZXYgPHphaXRjZXZAcmVkaGF0LmNvbT4K LSBQYXRjaCB0aGF0IGFsbG93cyB0byBjaGFuZ2UgVVNCIHByaW50ZXIgcHJvYmluZyBvcmRl ciAoIzUwMjE4KQoKKiBUdWUgQXVnIDE0IDIwMDEgQXJqYW4gdmFuIGRlIFZlbiA8YXJqYW52 QHJlZGhhdC5jb20+Ci0gTWFkZSB0aGUgVVNCIGtleWJvYXJkIHBhdGNoIG5vdCBwcmludGsg b24gZXZlcnkga2V5cHJlc3MKLSBhZGRlZCB1ZGVsYXkoMSkgdG8gdGhlIGVlcHJvMTAwIGRy aXZlcgotIG1lcmdlZCBidWdmaXhlcyBmcm9tIDIuNC44LWFjNQotIGFkZGVkIGFyY2gvcHBj NjQgY29kZSwgZG9lc24ndCB0b3VjaCBub24tcHBjCgoqIE1vbiBBdWcgMTMgMjAwMSBQZXRl IFphaXRjZXYgPHphaXRjZXZAcmVkaGF0LmNvbT4KLSBBZGQgZml4IGZvciAjNTExNDIgKEph cGFuZXNlIFVTQiBrZXlib2FyZCkuCgoqIE1vbiBBdWcgMTMgMjAwMSBTdGVwaGVuIEMuIFR3 ZWVkaWUgPHNjdEByZWRoYXQuY29tPgotIE1lcmdlIGV4dDMtMC45LjYKCiogTW9uIEF1ZyAx MyAyMDAxIEJlbmphbWluIEMuUi4gTGFIYWlzZSA8YmNybEByZWRoYXQuY29tPgotIHVwZGF0 ZWQgbGludXgtMi40LjctcGFnZV90YWJsZV9yYWNlcy5wYXRjaCBzZWUgYnVnICM1MTY1Mgot IHJlbW92ZSBjb21tZW50cyBhYm91dCBzZXRfcGFnZV9kaXJ0eSAoaXQncyBhY3R1YWxseSBv a2F5KQoKKiBNb24gQXVnIDEzIDIwMDEgTWljaGFlbCBLLiBKb2huc29uIDxqb2huc29ubUBy ZWRoYXQuY29tPgotIE1pbm9yIHNwZWNmaWxlIGNsZWFudXBzCgoqIE1vbiBBdWcgMTMgMjAw MSBBcmphbiB2YW4gZGUgVmVuIDxhcmphbnZAcmVkaGF0LmNvbT4KLSBjcml0aWNhbCBidWdm aXhlcyBmcm9tIDIuNC44LWFjMgotIG1vcmUgZWVwcm8xMDAgUENJIElEJ3MgKG5vdHRpbmcp Ci0gbW9yZSBhYWNyYWlkIFBDSSBJRCdzIChhZGFwdGVjKQotIGFkZCBwYXRjaCB0byBmaXgg cGFycG9ydCBjb25zb2xlIHBpbm5pbmcgbHAgbW9kdWxlICgjNTEzODcpCi0gYWRkZWQgTERU IGJ1Z2ZpeCAoZnJvbSAyLjQuOC1hYzIpIG5lZWRlZCBmb3IgZ2xpYmMKCiogU3VuIEF1ZyAx MiAyMDAxIEFyamFuIHZhbiBkZSBWZW4gPGFyamFudkByZWRoYXQuY29tPgotIFMvMzkwIHVw ZGF0ZXMgKEZsb3JpYW4pCgoqIEZyaSBBdWcgMTAgMjAwMSBCZW5qYW1pbiBMYUhhaXNlIDxi Y3JsQHJlZGhhdC5jb20+Ci0gdXBkYXRlIG5zODM4MjAuYyB0byB2MC42CgoqIEZyaSBBdWcg MTAgMjAwMSBBcmphbiB2YW4gZGUgVmVuIDxhcmphbnZAcmVkaGF0LmNvbT4KLSBBZGRlZCBi aWdlbmRpYW4gcGF0Y2ggZm9yIGV4dDMgKHNjdCkKLSBmaXggcmVzdW1lIG9uIERlbGwgSW5z cGlyb24gODAwMCAoIzUxNDA3KQotIGZpeCBvb3BzIGluIHBhcnBvcnQgY29kZSAoIzUxMTk0 KQotIGFkZGVkIGJ1Z2ZpeGVzIGZyb20gMi40LjctYWMxMSwgaW5jbHVkaW5nIGZpeCBmb3Ig IzQ5Mjg3Ci0gQWRkZWQgTVhUIGJ1Z2ZpeCAoSUJNIENSSVQpCi0gcmVtb3ZlZCBmcy9uYW1l aSBwYXRjaCBhcyBpdCBicmVha3MgdG9vIG11Y2gKCiogVGh1IEF1ZyA5IDIwMDEgQXJqYW4g dmFuIGRlIFZlbiA8YXJqYW52QHJlZGhhdC5jb20+Ci0gYWRkZWQgcGF0Y2ggZnJvbSBCcm9h ZGNvbSB0byBmaXggY3Jhc2ggdW5kZXIgaGlnaCBsb2FkICgjNTEyNzIsICM1MTA0MSkgCi0g bWVyZ2VkIGJ1Z2ZpeGVzIGZyb20gMi40LjctYWMxMDsgaW5jbHVkaW5nIHN3aXRjaGluZyB0 byBEUk00LjEgZnJvbSAtYWMxMAotIGFkZGVkIERlbGwgRE1JIGVudHJpZXMgZm9yIHJlYm9v dGluZy9zdXNwZW5kICgjNTEyNjksICM1MTIwMikKLSBhZGRlZCBhYWNyYWlkIFBDSSBJRCdz ICgjNTEyNDYpCi0gc3luY2VkIFMzOTAgdHJlZSAoYmVybykKLSBuZXcgaXNjc2kgZHJvcCBm cm9tIENpc2NvIHRvIGNvbXBseSB3aXRoIGxhdGVzdCBpZXRmIHN0YW5kYXJkCgoqIFdlZCBB dWcgOCAyMDAxIEFyamFuIHZhbiBkZSBWZW4gPGFyamFudkByZWRoYXQuY29tPgotIGFkZGVk IGlhNjQgVExCIHBhdGNoIGZyb20gQmVuICgjNDUyMDQpCi0gYWRkZWQgaW8gZWxldmF0b3Ig c3RhbGwgcGF0Y2ggZnJvbSBCZW4KLSBtZXJnZSBidWdmaXhlcyBmcm9tIDIuNC43LWFjOQot IGFkZCBJREUgYmxhY2tsaXN0IGVudHJpZXMgKCM1MDc3NSkKCiogVHVlIEF1ZyA3IDIwMDEg QXJqYW4gdmFuIGRlIFZlbiA8YXJqYW52QHJlZGhhdC5jb20+Ci0gbWVyZ2VkIGJ1Z2ZpeGVz IGZyb20gMi40LjctYWM4Ci0gaW5jcmVhc2VkIFNDU0kgdGltZW91dCAoIzUwODUzKQotIHVw ZGF0ZWQgaG90cGx1ZyBQQ0kgcGF0Y2ggKCM1MDg1NikKLSB1cGRhdGVkIGNwcWZjIGRyaXZl ciAoQ29tcGFxIENSSVQpCi0gYWRkZWQgdmZhdC1uZnMgcGF0Y2ggKCM1MDgyMCwgIzUwODIy LCAjNDU1MjUsICMzNzAzMSkKCiogTW9uIEF1ZyA2IDIwMDEgQXJqYW4gdmFuIGRlIFZlbiA8 YXJqYW52QHJlZGhhdC5jb20+Ci0gbWVyZ2VkIGJ1Z2ZpeGVzIGZyb20gMi40LjctYWM3Ci0g dXBkYXRlZCBiY201ODIwIGRyaXZlcgotIHVwZGF0ZWQgbGludXgtYWJpIHBhdGNoCgoqIEZy aSBBdWcgMyAyMDAxIEFyamFuIHZhbiBkZSBWZW4gPGFyamFudkByZWRoYXQuY29tPgotIEFk ZGVkIERSSSBmb3IgWEZyZWUgNC4xCgoqIFRodSBBdWcgMiAyMDAxIEFyamFuIHZhbiBkZSBW ZW4gPGFyamFudkByZWRoYXQuY29tPgotIGZpeGVkIGJ1ZyB3aGVyZSBpbm9kZXMgd2VyZSBj YWNoZWQgV0FBWSB0b28gbG9uZyAodm0gYnVnKQotIEFkZGVkIGV0aHRvb2wgc3VwcG9ydCB0 byBzZXZlcmFsIGRyaXZlcnMgKERlbGwpCi0gVXBkYXRlZCBiY201ODIwIGRyaXZlcgoKKiBX ZWQgQXVnIDAxIDIwMDEgTWljaGFlbCBLLiBKb2huc29uIDxqb2huc29ubUByZWRoYXQuY29t PgotIGV4dDMgbm8gbG9uZ2VyIG9wdGlvbmFsCgoqIFdlZCBBdWcgMSAyMDAxIEFyamFuIHZh biBkZSBWZW4gPGFyamFudkByZWRoYXQuY29tPgotIHVwZGF0ZWQgdG8gMi40LjctYWMzCgoq IFR1ZSBKdWwgMzEgMjAwMSBBcmphbiB2YW4gZGUgVmVuIDxhcmphbnZAcmVkaGF0LmNvbT4K LSBBZGRlZCBEYXZlTSdzIGZpeCBmb3IgdGhlIGV0aHRvb2wgaW9jdGwKCiogV2VkIEp1bCAy NSAyMDAxIEd1eSBTdHJlZXRlciA8c3RyZWV0ZXJAcmVkaGF0LmNvbT4KLSBwcGMgYnVpbGQg Zml4ZXMKLSBtYWMgYW5kIHBTZXJpZXMgcnBtIGFuZCBNYWtlZmlsZSBzdXBwb3J0CgoqIFdl ZCBKdWwgMjUgMjAwMSBNaWNoYWVsIEsuIEpvaG5zb24gPGpvaG5zb25tQHJlZGhhdC5jb20+ Ci0gdXBkYXRlIHRvIGNwcWFycmF5IDIuNC41CgoqIFR1ZSBKdWwgMjQgMjAwMSBNaWNoYWVs IEsuIEpvaG5zb24gPGpvaG5zb25tQHJlZGhhdC5jb20+Ci0gYWRkIHNwaW5sb2NrcyB0byBj cmFtZnMgZGVjb21wcmVzc2lvbiBmb3IgU01QIG9wZXJhdGlvbgoKKiBUdWUgSnVsIDI0IDIw MDEgSW5nbyBNb2xuYXIgPG1pbmdvQHJlZGhhdC5jb20+Ci0gZml4ZWQgcmFyZSBCVUcgaW4g cmVjbGFpbV9wYWdlCgoqIE1vbiBKdWwgMjMgMjAwMSBNaWNoYWVsIEsuIEpvaG5zb24gPGpv aG5zb25tQHJlZGhhdC5jb20+Ci0gcmVtb3ZlZCBhY2NpZGVudGFsbHkgYWRkZWQgYW5kIHVu bmVlZGVkIGlhNjQgQk9PVCBrZXJuZWwKCiogTW9uIEp1bCAyMyAyMDAxIEJlbmphbWluIExh SGFpc2UgPGJjcmxAcmVkaGF0LmNvbT4KLSB1cGRhdGUgbnM4MzgyMCBkcml2ZXIgdG8gdjAu NQoKKiBNb24gSnVsIDIzIDIwMDEgQXJqYW4gdmFuIGRlIFZlbiA8YXJqYW52QHJlZGhhdC5j b20+Ci0gVXBkYXRlIE1YVCBwYXRjaAotIFVwZGF0ZWQgR0RUSCBkcml2ZXIKLSBNYWRlIEVY VDMgYSBtb2R1bGUgYWdhaW4KLSBGaXhlZCBtb2R1bGUgb29wcyBkdW1wcwotIEZpZGRsZWQg d2l0aCBWTSBzb21lIG1vcmUKLSBVcGRhdGVkIEJDTTU4MjAgZHJpdmVyCgoqIFNhdCBKdWwg MjEgMjAwMSBBcmphbiB2YW4gZGUgVmVuIDxhcmphbnZAcmVkaGF0LmNvbT4KLSBtYWRlIG9v bSBraWxsZXIgbGVzcyB0cmlnZ2VyLWhhcHB5CgoqIEZyaSBKdWwgMjAgMjAwMSBTdGVwaGVu IEMuIFR3ZWVkaWUgPHNjdEByZWRoYXQuY29tPgotIEZpeCBzbGFiLXBvaXNvbiBvb3BzIGlu IGV4dDMgY2hlY2twb2ludCBjbGVhbnVwIGNvZGUKCiogRnJpIEp1bCAyMCAyMDAxIEFyamFu IHZhbiBkZSBWZW4gPGFyamFudkByZWRoYXQuY29tPgotIG1hZGUgRVhUMyBub25tb2R1bGFy IHRvIGFsbG93IGZvciBiZXR0ZXIgZGVidWdnaW5nL29vcHN0cmFjaW5nCi0gdXBkYXRlZCBl MTAwMCBkcml2ZXIgdG8gbmV3IHZlcnNpb24gZnJvbSBJbnRlbAoKKiBUaHUgSnVsIDE5IDIw MDEgU3RlcGhlbiBDLiBUd2VlZGllIDxzY3RAcmVkaGF0LmNvbT4KLSBNZXJnZSBpbiBleHQz LTAuOS4zCgoqIFRodSBKdWwgMTkgMjAwMSBBcmphbiB2YW4gZGUgVmVuIDxhcmphbnZAcmVk aGF0LmNvbT4KLSB1cGRhdGVkIHRvIDIuNC42LWFjNQotIHVwZGF0ZWQgY2Npc3MgZHJpdmVy Ci0gcmVuYWJsZWQgdHV4Ci0gYWRkZWQgRmxvcmlhbidzIHMzOTAgcGF0Y2gKCiogTW9uIEp1 bCAxNiAyMDAxIFN0ZXBoZW4gQy4gVHdlZWRpZSA8c2N0QHJlZGhhdC5jb20+Ci0gQWRkZWQg ZXh0MyBmaXggZm9yIGJsb2NrIGFsbG9jYXRpb24gcmFjZQoKKiBGcmkgSnVsIDEzIDIwMDEg UGhpbGlwIENvcGVsYW5kIDxicnljZUByZWRoYXQuY29tPgotIFJlbW92ZWQgZXh0cmEgc2hv d19zdGFjaygpIGZ1bmN0aW9uIG9uIHRoZSBlbmQgb2YgdGhlIHR1eDIgcGF0Y2gKICBhcmNo L2FscGhhL2tlcm5lbC90cmFwcy5jICsxMDMgYW5kICsxMjkKCiogRnJpIEp1bCAxMyAyMDAx IE1pY2hhZWwgSy4gSm9obnNvbiA8am9obnNvbm1AcmVkaGF0LmNvbT4KLSBBZGRlZCByYWlk MSB3YWl0X2V2ZW50IHBhdGNoCgoqIFRodSBKdWwgMTIgMjAwMSBBcmphbiB2YW4gZGUgVmVu IDxhcmphbnZAcmVkaGF0LmNvbT4KLSBhZGRlZCB1cGRhdGVkIGNwcWZjIGRyaXZlcgoKKiBU dWUgSnVsIDEwIDIwMDEgSW5nbyBNb2xuYXIgPG1pbmdvQHJlZGhhdC5jb20+Ci0gbWVyZ2Ug bXVsdGlwYXRoIHBhdGNoCgoqIE1vbiBKdWwgMDkgMjAwMSBNaWNoYWVsIEsuIEpvaG5zb24g PGpvaG5zb25tQHJlZGhhdC5jb20+Ci0gY2hhbmdlIGZyb20gOCB0byAzMiBhdmFpbGFibGUg c3dhcCBhcmVhcyAofjFrIG1lbW9yeSBjb3N0KQoKKiBTdW4gSnVsIDA4IDIwMDEgQXJqYW4g dmFuIGRlIFZlbiA8YXJqYW52QHJlZGhhdC5jb20+Ci0gQWRkZWQgUGV0ZSdzIHBhdGNoIHRv IGZpeCB0aGUgSURFIHRhcGUKCiogU2F0IEp1bCAwNyAyMDAxIEFyamFuIHZhbiBkZSBWZW4g PGFyamFudkByZWRoYXQuY29tPgotIEFkZGVkIHBhdGNoIHRvIG5vdCBhbGxvY2F0ZSBoaWdo bWVtIGJvdW5jZXBhZ2VzIG9uIG5vbi1oaWdobWVtIG1hY2hpbmVzCi0gZml4ZWQgaWE2NCBi b290CgoqIEZyaSBKdWwgMDYgMjAwMSBBcmphbiB2YW4gZGUgVmVuIDxhcmphbnZAcmVkaGF0 LmNvbT4KLSBVcGRhdGVkIEJyb2FkY29tIGJjbTU3MDAgZHJpdmVyCgoqIFRodSBKdWwgMDUg MjAwMSBBcmphbiB2YW4gZGUgVmVuIDxhcmphbnZAcmVkaGF0LmNvbT4KLSB1cGRhdGVkIGFp cm9fY3MgZHJpdmVyCgoqIFRodSBKdWwgMDUgMjAwMSBNaWNoYWVsIEsuIEpvaG5zb24gPGpv aG5zb25tQHJlZGhhdC5jb20+Ci0gaW5pdHJkX2RpciBiZWNhdXNlIGlhNjQgdXNlcyAvYm9v dC9lZmkKCiogTW9uIEp1bCAwMyAyMDAxIEFyamFuIHZhbiBkZSBWZW4gPGFyamFudkByZWRo YXQuY29tPgotIFVwZGF0ZSBocHQvcGRjcmFpZCBzdXBwb3J0Ci0gdXBkYXRlZCB0byAyLjQu NS1hYzIzCgoqIE1vbiBKdWwgMDIgMjAwMSBNaWNoYWVsIEsuIEpvaG5zb24gPGpvaG5zb25t QHJlZGhhdC5jb20+Ci0gUmVtb3ZlZCBuZXN0ZWQgaWZhcmNoJ3MgZnJvbSAlYnVpbGQvJWZp bGVzIGJ5IGFkZGluZyBhcmNoIGV4Y2x1c2lvbnMKCiogVGh1IEp1biAyOCAyMDAxIEFyamFu IHZhbiBkZSBWZW4gPGFyamFudkByZWRoYXQuY29tPgotIEFkZCBwcmVmZXRjaCgpIHN1cHBv cnQgdG8gaWE2NAoKKiBXZWQgSnVuIDI3IDIwMDEgQXJqYW4gdmFuIGRlIFZlbiA8YXJqYW52 QHJlZGhhdC5jb20+Ci0gMi40LjUtYWMxOQotIGZpeGVkIE8oTl4yKSBhbGdvcml0aG0gaW4g YnVmZmVyY2FjaGUgc3luYyBjb2RlCgoqIFR1ZSBKdW4gMjYgMjAwMSBQaGlsaXAgQ29wZWxh bmQgPGJyeWNlQHJlZGhhdC5jb20+Ci0gdXBkYXRlZCBJUFZTCgoqIFR1ZSBKdW4gMjYgMjAw MSBBcmphbiB2YW4gZGUgVmVuIDxhcmphbnZAcmVkaGF0LmNvbT4KLSBBZGRlZCBwYXRjaCBm b20gSmFrdWIgdG8gZml4IHNlY3Rpb25zCgoqIE1vbiBKdW4gMjUgMjAwMSBBcmphbiB2YW4g ZGUgVmVuIDxhcmphbnZAcmVkaGF0LmNvbT4KLSBBZGRlZCBwYXRjaCBmcm9tIG1hcmNlbG9A Y29uZWN0aXZhLmNvbS5iciB0byBzaG93IGJldHRlciBzd2FwaW5mbwoKKiBTdW4gSnVuIDI0 IDIwMDEgQXJqYW4gdmFuIGRlIFZlbiA8YXJqYW52QHJlZGhhdC5jb20+Ci0gVXBkYXRlZCBI UFQzNzAgZHJpdmVyCgoqIEZyaSBKdW4gMjIgMjAwMSBBcmphbiB2YW4gZGUgVmVuIDxhcmph bnZAcmVkaGF0LmNvbT4KLSBhZGRlZCBIUFQzNzAgZHJpdmVyCi0gcmV2ZXJ0ZWQgeGlyY29t X2NiIHRvIG9sZGVyIHZlcnNpb24KCiogRnJpIEp1biAyMiAyMDAxIE1pY2hhZWwgSy4gSm9o bnNvbiA8am9obnNvbm1AcmVkaGF0LmNvbT4KLSBhIGJpdCBtb3JlIFJQTSBmbGV4aWJpbGl0 eSB3aXRoIG1vcmUgZXhpc3RlbmNlIG1hY3JvcwotIGNvbmRpdGlvbmFsaXplIHRhcGUgYW5k IEJPT1R0YXBlIGtlcm5lbHMKCiogVGh1IEp1biAyMSAyMDAxIEFyamFuIHZhbiBkZSBWZW4g PGFyamFudkByZWRoYXQuY29tPgotIHJldmVydGVkIGJvcmtlbiBleHQzIGJpdAotIDIuNC41 LWFjMTcKLSBhZGRlZCAvcHJvYy9zeXMva2VybmVsL2NhZF9waWQgcGF0Y2gKCiogV2VkIEp1 biAyMCAyMDAxIEFyamFuIHZhbiBkZSBWZW4gPGFyamFudkByZWRoYXQuY29tPgotIHJlbnVt YmVyZWQgYWxsIHRoZSBwYXRjaGVzIGZvciBmdXR1cmUgZXhwYW5zaW9uIC8gYmV0dGVyIHNl cGFyYXRpb24KLSBuZXcgaG90cGx1ZyBwYXRjaAotIE1YVCBwYXRjaAoKKiBXZWQgSnVuIDIw IDIwMDEgTWljaGFlbCBLLiBKb2huc29uIDxqb2huc29ubUByZWRoYXQuY29tPgotIHNwZWVk IHRoaW5ncyB1cCBhIGJpdCBtb3JlIGZvciB0ZXN0IGJ1aWxkczoKICBvIGJ1aWxkdXAgZGVm aW5lIGZvciBjaG9vc2luZyB3aGV0aGVyIHRvIGJ1aWxkIHRoZSB1bmlwcm9jZXNzb3Iga2Vy bmVsCiAgbyBidWlsZGRldmZzZCBkZWZpbmUgZGl0dG8gZm9yIGRldmZzZCAoZGV2ZnMgaXRz ZWxmIHN0aWxsIG9mZikKCiogVHVlIEp1biAxOSAyMDAxIEFyamFuIHZhbiBkZSBWZW4gPGFy amFudkByZWRoYXQuY29tPgotIHVwZGF0ZWQgdG8gMi40LjUtYWMxNgoKKiBNb24gSnVuIDE4 IDIwMDEgQXJqYW4gdmFuIGRlIFZlbiA8YXJqYW52QHJlZGhhdC5jb20+Ci0gYWRkZWQgdXBk YXRlZCBwZGNyYWlkIGRyaXZlcgoKKiBTdW4gSnVuIDE3IDIwMDEgQXJqYW4gdmFuIGRlIFZl biA8YXJqYW52QHJlZGhhdC5jb20+Ci0gYWRkZWQgQ09ORklHX1NNQUxMLCB3aWxsIG5lZWQg bW9yZSB0d2Vha3MgZm9yIHRoZSBCT09UIGtlcm5lbCBzdGlsbAoKKiBTYXQgSnVuIDE2IDIw MDEgQXJqYW4gdmFuIGRlIFZlbiA8YXJqYW52QHJlZGhhdC5jb20+Ci0gMi40LjUtYWMxNQoK KiBGcmkgSnVuIDE1IDIwMDEgQXJqYW4gdmFuIGRlIFZlbiA8YXJqYW52QHJlZGhhdC5jb20+ Ci0gbW92ZWQgdG8gMi40LjUtYWMxNAotIG1hZGUgaTM4NiBvcHRpbWl6ZSBmb3IgY3B1PTU4 NgotIGRpc2FibGVkIFRVWCBmb3IgVk0gdGVzdGluZwotIHVwZGF0ZWQgZXh0MwoKCiogTW9u IEp1biAxMSAyMDAxIE1pY2hhZWwgSy4gSm9obnNvbiA8am9obnNvbm1AcmVkaGF0LmNvbT4K LSBraWxsZWQgc29tZSBzcGVjIGZpbGUgY3J1ZnQsIG1hZGUgdGhlIHNwZWMgZmlsZSBlYXNp ZXIgdG8gbWFpbnRhaW4KCiogU2F0IEp1biAwOSAyMDAxIEFyamFuIHZhbiBkZSBWZW4gPGFy amFudkByZWRoYXQuY29tPgotIDIuNC41LWFjMTIKLSBOZXcgYWFjcmFpZCBkcml2ZXIKCiog U2F0IEp1biAwOSAyMDAxIE1pY2hhZWwgSy4gSm9obnNvbiA8am9obnNvbm1AcmVkaGF0LmNv bT4KLSBpZWVlMTM5NCB1cGRhdGUKCiogRnJpIEp1biAgOCAyMDAxIEJpbGwgTm90dGluZ2hh bSA8bm90dGluZ0ByZWRoYXQuY29tPgotIGFkZCAwNTMwIGlhNjQgcGF0Y2gsIG1ha2UgaXQg YXBwbHksIGV0Yy4KCiogVGh1IEp1biAwNyAyMDAxIEFyamFuIHZhbiBkZSBWZW4gPGFyamFu dkByZWRoYXQuY29tPgotIEFkZGVkIE1hcmNlbG8ncyBzd2FwIHBhdGNoCi0gYWRkZWQgYnV0 IGRpc2FibGVkIG5ldyBEUk0gY29kZQoKKiBNb24gSnVuICA0IDIwMDEgQmlsbCBOb3R0aW5n aGFtIDxub3R0aW5nQHJlZGhhdC5jb20+Ci0gYWRkIGxvY2tpbmcgZml4IGZvciB1c2ItdWhj aSBmcm9tIFBldGUgWmFpdGNldiB0byBsaW51eC0yLjQuMy11c2IucGF0Y2gKCiogVHVlIE1h eSAyOSAyMDAxIFBldGUgWmFpdGNldiA8emFpdGNldkByZWRoYXQuY29tPgotIHJlLWVuYWJs ZSB1c2IgcGF0Y2hlcyAyNjMsIDI3MS4gVGhlIGxhdHRlciBpcyBvbiBpdHMgd2F5IG91dCBi dXQKICB3ZSBuZWVkIGl0IHN0aWxsLgoKKiBUdWUgTWF5IDI5IDIwMDEgQmlsbCBOb3R0aW5n aGFtIDxub3R0aW5nQHJlZGhhdC5jb20+Ci0gcmVnZW4gaWE2NCBwYXRjaAoKKiBUdWUgTWF5 IDI5IDIwMDEgQXJqYW4gdmFuIGRlIFZlbiA8YXJqYW52QHJlZGhhdC5jb20+Ci0gMi40LjUt YWMzCi0gdXBkYXRlZCBFWFQzCi0gQWRkZWQgaG90cGx1ZyBwY2kgZm9yIHRlc3QKLSBBZGRl ZCBWTSBwYXRjaCBieSBBbmRyZWEKCiogTW9uIE1heSAyOCAyMDAxIEFyamFuIHZhbiBkZSBW ZW4gPGFyamFudkByZWRoYXQuY29tPgotIGdvIHRvIDIuNC41LWFjMgoKKiBTYXQgTWF5IDI2 IDIwMDEgQXJqYW4gdmFuIGRlIFZlbiA8YXJqYW52QHJlZGhhdC5jb20+Ci0gbWVyZ2UgYmFz ZSB0byAyLjQuNS1hYzEKCiogRnJpIE1heSAyNSAyMDAxIEFyamFuIHZhbiBkZSBWZW4gPGFy amFudkByZWRoYXQuY29tPgotIDIuNC40LWFjMTcgKG1vc3RseSBudWxsIHBvaW50ZXIgZml4 ZXMpCi0gTmV3IHZlcnNpb24gb2YgM3dhcmUgZHJpdmVyCi0gTmV3IHZlcnNpb24gb2Ygc3lt YmlvcyBkcml2ZXIKLSBOZXcgdmVyc2lvbiBvZiBGcmVlVnhGUyAKLSBBZGRlZCBFQ0MgbW9k dWxlCi0gbWVyZ2UgYmFzZSB0byAyLjQuNC1hYzE3CgoqIFRodSBNYXkgMjQgMjAwMSBBcmph biB2YW4gZGUgVmVuIDxhcmphbnZAcmVkaGF0LmNvbT4KLSBBZGRlZCByYXdpbyBmaXggZnJv bSBTaGlueWEgTmFyYWhhcmEKLSBOZXcgdmVyc2lvbiBvZiBFWFQzCgoqIFRodSBNYXkgMjQg MjAwMSBNaWNoYWVsIEsuIEpvaG5zb24gPGpvaG5zb25tQHJlZGhhdC5jb20+Ci0gbW9kcHJv YmUgbG9vcCBvbiBwcmV1biBhcyB3ZWxsCgoqIFdlZCBNYXkgMjMgMjAwMSBBcmphbiB2YW4g ZGUgVmVuIDxhcmphbnZAcmVkaGF0LmNvbT4KLSAyLjQuNC1hYzE0CgoqIFR1ZSBNYXkgMjIg MjAwMSBBcmphbiB2YW4gZGUgVmVuIDxhcmphbnZAcmVkaGF0LmNvbT4KLSBBZGRlZCBmaXhl cyBmcm9tIDIuNC40LWFjMTIgYW5kIGFjMTMKCiogTW9uIE1heSAyMSAyMDAxIEFyamFuIHZh biBkZSBWZW4gPGFyamFudkByZWRoYXQuY29tPgotIEFkZGVkIEpha3ViJ3MgRUxGIGxvYWRl ciBwYXRjaAotIEFkZGVkIGk4MjM2NSBwYXRjaAotIFVwZGF0ZWQgVFVYMiBwYXRjaCB0byAy LjQuNCBFNCBsZXZlbAoKKiAgRnJpIE1heSAxOCAyMDAxIFBoaWxpcCBDb3BlbGFuZCA8YnJ5 Y2VAcmVkaGF0LmNvbT4KLSBhZGRlZCBleHQzIHN1cHBvcnQgZm9yIDIuNCAoRVhQRVJJTUVO VEFMIEFORCAqKk5PVCoqIEZPUiBQUk9EVUNUSU9OKQoKKiAgRnJpIE1heSAxOCAyMDAxIFBo aWxpcCBDb3BlbGFuZCA8YnJ5Y2VAcmVkaGF0LmNvbT4KLSBBZGRlZCBpbiB0aGUgcHlyaXhz IGNoaXBzZXQgZml4IGZvciBzdGFibGUgUENJIERNQSB4ZmVyCiAgc28gdGhpbmdzIGxpa2Ug dWRtYTUgYnVyc3QgeGZlcnMgYWNyb3NzIGJ1cyBtYXN0ZXJzIHdpbGwKICB3b3JrIHdpdGhv dXQgbG9ja2luZyB1cCBzeC9seCAxNjQgYWxwaGEncwoKKiBGcmkgTWF5IDE4IDIwMDEgQXJq YW4gdmFuIGRlIFZlbiA8YXJqYW52QHJlZGhhdC5jb20+Ci0gYnVnZml4ZXMgZnJvbSAyLjQu NC1hYzEwCgoqIFRodSBNYXkgMTcgMjAwMSBCaWxsIE5vdHRpbmdoYW0gPG5vdHRpbmdAcmVk aGF0LmNvbT4KLSBhZGQgcWxhMngwMCB2NC4yOAotIHJldmVydCB0bGItc2hvb3Rkb3duIHBv cnRpb24gb2YgLWFjIHBhdGNoIGZvciBpYTY0CgoqIFRodSBNYXkgMTcgMjAwMSBBcmphbiB2 YW4gZGUgVmVuIDxhcmphbnZAcmVkaGF0LmNvbT4KLSBjb21wYXEgcmFpZCB1cGRhdGUgbm93 IGZvciBhbGwgYXJjaHMKLSBuZXcgZTEwMCAvIGUxMDAwIC8gbWVnYXJhaWQgZHJpdmVycwoK CiogV2VkIE1heSAxNiAyMDAxIEFyamFuIHZhbiBkZSBWZW4gPGFyamFudkByZWRoYXQuY29t PgotIEZpeCBEZWxsIFBvd2VyZWRnZSA4NDUwIHBhdGNoCgoqIFR1ZSBNYXkgMTUgMjAwMSBC ZW5qYW1pbiBMYUhhaXNlIDxiY3JsQHJlZGhhdC5jb20+Ci0gcmVwbGFjZSByZXNlcnZhdGlv biBwYXRjaCB3aXRoIHZtZml4ZXMgZm9yIGEgZmV3IHZtIGRlYWRsb2NrcyB3aXRoIGhpZ2ht ZW0KCiogVHVlIE1heSAxNSAyMDAxIEFyamFuIHZhbiBkZSBWZW4gPGFyamFudkByZWRoYXQu Y29tPgotIEFkZGVkIERlbGwgUG93ZXJlZGdlIDg0NTAgcGF0Y2gKLSBEaXNhYmxlIHdlaXJk IGZpeHVwIGZvciBpbnRlbCA0NTBueCBjaGlwc2V0CgoqIE1vbiBNYXkgMTQgMjAwMSBBcmph biB2YW4gZGUgVmVuIDxhcmphbnZAcmVkaGF0LmNvbT4KLSBmaXhlZCBidWdmaXhlcyBmcm9t IDIuNC40LWFjOQotIGRpc2NvdXJhZ2UgSVJRIDEyIGZvciB5ZW50YV9zb2NrZXQKCiogRnJp IE1heSAxMSAyMDAxIEFyamFuIHZhbiBkZSBWZW4gPGFyamFudkByZWRoYXQuY29tPgotIE1h ZGUgRUNOIGRlZmF1bHQgdG8gb2ZmIGFuZCBlbmFibGVkIENPTkZJR19JTkVUX0VDTgoKKiBG cmkgTWF5IDExIDIwMDEgUGhpbGlwIENvcGVsYW5kIDxicnljZUByZWRoYXQuY29tPgotIG5v IG5lZWQgZm9yICVpZmRlZidpbmcgaXB2cyBhbnltb3JlCgoqIFRodSBNYXkgMTAgMjAwMSBC aWxsIE5vdHRpbmdoYW0gPG5vdHRpbmdAcmVkaGF0LmNvbT4KLSBhZGQgdXBkYXRlIGZvciB1 aGNpIGRyaXZlciBvbiBpYTY0CgoqIFRodSBNYXkgMTAgMjAwMSBNaWNoYWVsIEsuIEpvaG5z b24gPGpvaG5zb25tQHJlZGhhdC5jb20+Ci0gZGlzYWJsZSByZXNlcnZhdGlvbiBwYXRjaCBm b3Igbm93LCBub3QgcXVpdGUgY29va2VkIHlldC4KCiogVGh1IE1heSAxMCAyMDAxIEJlbmph bWluIExhSGFpc2UgPGJjcmxAcmVkaGF0LmNvbT4KLSB1cGRhdGVkIHJlc2VydmF0aW9uIHBh dGNoLiAgc2hvdWxkIHdvcmsgbm93LgoKKiBUaHUgTWF5IDEwIDIwMDEgQXJqYW4gdmFuIGRl IFZlbiA8YXJqYW52QHJlZGhhdC5jb20+Ci0gQWRkZWQgQWwgVmlybydzIGF1ZGl0IHBhdGNo ZXMKLSBNb3JlIGRyaXZlcyBmb3IgdGhlIGJsYWNrbGlzdCAKLSByZW1vdmVkIGZpbmVyLWZs dXNoIHBhdGNoCgoqIFRodSBNYXkgMTAgMjAwMSBNaWNoYWVsIEsuIEpvaG5zb24gPGpvaG5z b25tQHJlZGhhdC5jb20+Ci0gQWRkZWQgQ0QtNTMyRS1BIHRvIHRoZSBpZGUgZG1hIGJsYWNr bGlzdAoKKiBXZWQgTWF5IDA5IDIwMDEgQmVuamFtaW4gTGFIYWlzZSA8YmNybEByZWRoYXQu Y29tPgotIGFkZGVkIG1lbW9yeSByZXNlcnZhdGlvbgoKKiBXZWQgTWF5IDA5IDIwMDEgQmls bCBOb3R0aW5naGFtIDxub3R0aW5nQHJlZGhhdC5jb20+Ci0gbmV3IGlhNjQgcGF0Y2ggKGJh c2VkIG9uIDIuNC40LCBzbyBiYWNrIGEgY291cGxlIGJpdHMgb3V0KQoKKiBXZWQgTWF5IDA5 IDIwMDEgQXJqYW4gdmFuIGRlIFZlbiA8YXJqYW52QHJlZGhhdC5jb20+Ci0gQWRkZWQgcGF0 Y2ggZm9yIHNlcmlhbHBvcnQgb24geGlyY29tIGNhcmRidXMKLSBNZXJnZWQgYnVnZml4ZXMg ZnJvbSAyLjQuNC1hYzYKCiogVHVlIE1heSAwOCAyMDAxIE1pY2hhZWwgSy4gSm9obnNvbiA8 am9obnNvbm1AcmVkaGF0LmNvbT4KLSBBZGQgaGVhZGVycyBmb3IgYXRobG9uIHNtcCB0byBt ZXJnZWQgc3ltYm9sIHNldAotIFJldmVydCB0aGUgZGVhZCBzd2FwIHBhdGNoIGZyb20gLWFj MTIKCiogVHVlIE1heSAwOCAyMDAxIEJpbGwgTm90dGluZ2hhbSA8bm90dGluZ0ByZWRoYXQu Y29tPgotIG5ldyBzbWFydGFycmF5IHN0dWZmIGZyb20gQ29tcGFxIChpYTY0LW9ubHkgQVRN KQoKKiBUdWUgTWF5IDA4IDIwMDEgQXJqYW4gdmFuIGRlIFZlbiA8YXJqYW52QHJlZGhhdC5j b20+Ci0gQnVnZml4ZXMgZnJvbSAyLjQuNC1hYzQgYW5kIDIuNC40LWFjNQotIFVwZGF0ZWQg ODEzOXRvbwotIEZpeGVkIDh4IHJlZ2lzdHJhdGlvbiBidWcgaW4gZWVwcm8KLSBVcGRhdGUg Z2R0aCBkcml2ZXIKLSBhZGRlZCBmaXggZm9yIGJybG9ja3MKCiogTW9uIE1heSAwNyAyMDAx IE1pY2hhZWwgSy4gSm9obnNvbiA8am9obnNvbm1AcmVkaGF0LmNvbT4KLSBhZGRlZCBsaW51 eC0yLjQuMy1yMTI4LWRybS1kby13YWl0LWZvci1maWZvLnBhdGNoCgoqIEZyaSBNYXkgMDQg MjAwMSBNaWNoYWVsIEsuIEpvaG5zb24gPGpvaG5zb25tQHJlZGhhdC5jb20+Ci0gQWRkZWQg RGVsbCBwYXRjaCB0byBiZSBhYmxlIHRvIHNwZWNpZnkgcmVib290aW5nIGZyb20gYm9vdCBj cHUgd2l0aCAicyIgZmxhZwotIHVwZGF0ZWQgbGludXgtMi40LjMteW1mcGNpLnBhdGNoIHRv IGluY2x1ZGUgbmlwaCBwYXRjaCBmcm9tIFBldGUgWmFpdGNldgotIHVwZGF0ZWQgbGludXgt Mi40LjMtdXNiLnBhdGNoIHRvIGluY2x1ZGUgZGVyZWcgcGF0Y2ggZnJvbSBQZXRlIFphaXRj ZXYKCiogRnJpIE1heSA0IDIwMDEgQmVuamFtaW4gTGFIYWlzZSA8YmNybEByZWRoYXQuY29t PgotIHJlbW92ZSBsaW51eC0yLjQuMy1zbXBjYWxsLWZpeC5wYXRjaAoKKiBGcmkgTWF5IDQg MjAwMSBTdGVwaGVuIEMuIFR3ZWVkaWUgPHNjdEByZWRoYXQuY29tPgotIEZpeCByYWNlIGlu IHNtcF9jYWxsX2Z1bmN0aW9uCgoqIFRodSBNYXkgMyAyMDAxIFN0ZXBoZW4gQy4gVHdlZWRp ZSA8c2N0QHJlZGhhdC5jb20+Ci0gYnVtcCB2ZXJzaW9uIG51bWJlcgoKKiBUaHUgTWF5IDMg MjAwMSBQaGlsaXAgQ29wZWxhbmQgPGJyeWNlQHJlZGhhdC5jb20+Ci0gQWRkZWQgaW4gc3Vi bWl0dGVkIHBhdGNoIGZvciB0aGUgbmF1dGlsdXMgYWxwaGEgc3lzdGVtCiAgZnJvbSBIeXVu ZyBNaW4gU0VPIDxITVNFT0BzZWMuc2Ftc3VuZy5jb20+CgoqIFRodSBNYXkgMyAyMDAxIFN0 ZXBoZW4gQy4gVHdlZWRpZSA8c2N0QHJlZGhhdC5jb20+Ci0gYWxsb3cgdXJnZW50IFZNIHBh Z2UgYWxsb2NhdGlvbiByZXF1ZXN0cyB0byBiZSBzYXRpc2ZpZWQgbW9yZQogIGVhc2lseQoK KiBUaHUgTWF5IDMgMjAwMSBTdGVwaGVuIEMuIFR3ZWVkaWUgPHNjdEByZWRoYXQuY29tPgot IGFkZGVkIHNpZ25pZmljYW50IHNwZWVkdXAgZm9yIHNjYW5uaW5nIGZ1bGwgc3dhcCBtYXBz CgoqIFdlZCBNYXkgMiAyMDAxIFN0ZXBoZW4gQy4gVHdlZWRpZSA8c2N0QHJlZGhhdC5jb20+ Ci0gYWRkZWQgdHJpdmlhbCBob3N0LWNwdSBzeXNycS1UIGRlYnVnIG91dHB1dAoKKiBXZWQg TWF5IDIgMjAwMSBCZW5qYW1pbiBMYUhhaXNlIDxiY3JsQHJlZGhhdC5jb20+Ci0gYWRkZWQg bGludXgtMi40LjMtcGFnZV90YWJsZV9yYWNlcy5wYXRjaCB2bSBmaXh1cHMKCiogV2VkIE1h eSAgMiAyMDAxIEJpbGwgTm90dGluZ2hhbSA8bm90dGluZ0ByZWRoYXQuY29tPgotIGRvbid0 IGNhbGwgdHR5X3dyaXRlX21lc3NhZ2Ugb24gdW5hbGlnbmVkIHRyYXBzIG9uIGlhNjQKCiog V2VkIE1heSAyIDIwMDEgQXJqYW4gdmFuIGRlIFZlbiA8YXJqYW52QHJlZGhhdC5jb20+Ci0g QWRkZWQgaXJxLWZhdWx0IGxvY2t1cCBwYXRjaCAKLSBNZXJnZWQgMi40LjQtYWMzIGJ1Z2Zp eGVzOgogIC0gVVNCIGFjbQogIC0gQVBNIGFsbG93X2ludHMgb3B0aW9uCiAgLSBEZXNjcmlw dG9ydGFibGUgY29ycnVwdGlvbgogIC0gRE1GRSBkcml2ZXIgc2tiIGFsbG9jICAKICAtIHR5 cG8gaW4gSURFIGNvZGUKICAtIG5ldGZpbHRlciB1cGRhdGVzCiAgLSBjb3JlIG5ldHdvcmsg dXBkYXRlcwogIC0gdmlhIHdvcmthcmFvdW5kIDY4NmEgZml4CiAgLSBBbHBoYSBmaXhlcwoK CiogV2VkIE1heSAyIDIwMDEgUGhpbGlwIENvcGVsYW5kIDxicnljZUByZWRoYXQuY29tPgot IGFkZGVkIGluIERhdmVNJ3MgQUxJIHBhdGNoIGZvciB0aGUgc3BhcmMsIHdpdGggbHVjayBp dCBtYXkKICBldmVuIHdvcmsgZm9yIHRoZSBhbHBoYQoKKiBUdWUgTWF5IDEgMjAwMSBCZW5q YW1pbiBMYUhhaXNlIDxiY3JsQHJlZGhhdC5jb20+Ci0gYWRkZWQgbGludXgtMi40LjMtc21w Y2FsbC1maXgucGF0Y2ggdG8gZml4IGEgcmFyZSBkZWFkbG9jawoKKiBUdWUgTWF5IDEgMjAw MSBBcmphbiB2YW4gZGUgVmVuIDxhcmphbnZAcmVkaGF0LmNvbT4KLSBhdHRlbXB0IERNQSBs aXZlbG9jayBmaXgKCiogTW9uIEFwciAzMCAyMDAxIEFyamFuIHZhbiBkZSBWZW4gPGFyamFu dkByZWRoYXQuY29tPgotIEFkZCBwYXRjaCB0byByZXZlcnQgdGhlICJzY2hlZHVsZSBmb3Jr J2QgZmlyc3QiIHBhdGNoIGluCiAgbWFpbnN0cmVhbSB0cmVlLiBJdCBtYWtlcyBicm9rZW4g dXNlcnNwYWNlIHNob3cgdXAgdG9vIG11Y2guCiAgQWxzbyBjYXVzZXMgcGVyZm9ybWFuY2Ug cHJvYmxlbXMgaW4gc29tZSBub3JtYWwgY2FzZXMuCi0gZml4IHZpYSBhdWRpbyBwY2lfZW5h YmxlX2RldmljZQotIGFkZGVkIHNjdCdzIGZpeCB0byB0aGUgcGVyLWNwdS1wYWdlcyBwYXRj aAoKKiBTdW4gQXByIDI5IDIwMDEgQXJqYW4gdmFuIGRlIFZlbiA8YXJqYW52QHJlZGhhdC5j b20+Ci0gUHJldmVudCBuZWdhdGl2ZSBpbm9kZS11c2VkIGNvdW50cyAoYXZpcm8pCgoqIFNh dCBBcHIgMjggMjAwMSBBcmphbiB2YW4gZGUgVmVuIDxhcmphbnZAcmVkaGF0LmNvbT4KLSBh ZGRlZCBwYXRjaCB0byBhdm9pZCByZWN1cnNpbmcgaW4gZGVhZGxvY2tzIGluIGNyZWF0ZV9i b3VuY2UKCiogRnJpIEFwciAyNyAyMDAxIEJlbmphbWluIExhSGFpc2UgPGJjcmxAcmVkaGF0 LmNvbT4KLSBhZGRlZCBsaW51eC0yLjQuMy12bWxvY2t1cC5wYXRjaCBmb3IgdGVzdGluZwoK KiBGcmkgQXByIDI3IDIwMDEgQXJqYW4gdmFuIGRlIFZlbiA8YXJqYW52QHJlZGhhdC5jb20+ Ci0gQWRkZWQgYmNybCdzIGhpZ2htZW0gcGF0Y2gKLSBSZW1vdmVkIGJjcmwncyBoaWdobWVt IHBhdGNoCi0gQWRkZWQgQWwgVmlybydzIHN5bmNfb25lIHBhdGNoCi0gQWRkZWQgYSBwYXRj aCB0byBhZGQgdGhlICJhcGljIiBjb21tYW5kbGluZSBvcHRpb24gZm9yCiAgc29tZSBicm9r ZW4gbW90aGVyYm9hcmRzCgoqIFRodSBBcHIgMjYgMjAwMSBNaWNoYWVsIEsuIEpvaG5zb24g PGpvaG5zb25tQHJlZGhhdC5jb20+Ci0gQWRkZWQgbGludXgtMi40LjMtaGlnaG1lbXRocm90 dGxlLnBhdGNoCgoqIFRodSBBcHIgMjYgMjAwMSBBcmphbiB2YW4gZGUgVmVuIDxhcmphbnZA cmVkaGF0LmNvbT4KLSBmaXhlZCBidWcgIzM3NzU5Ci0gdXBkYXRlZCBpcHMgKFNlcnZlclJB SUQpIHRvIDQuNzIKLSBBZGRlZCBBbCBWaXJvJ3MgYnVmZmVycmFjZSBwYXRjaAoKKiBXZWQg QXByIDI1IDIwMDEgQmlsbCBOb3R0aW5naGFtIDxub3R0aW5nQHJlZGhhdC5jb20+Ci0gYWRk IHFsYTEyODAgY2xlYW51cCBwYXRjaAoKKiBXZWQgQXByIDI1IDIwMDEgQXJqYW4gdmFuIGRl IFZlbiA8YXJqYW52QHJlZGhhdC5jb20+Ci0gTWVyZ2VkIHRvIGFjMTQKLSBBZGRlZCBJUHY2 IHBhdGNoIChEYXZlTSkKCiogTW9uIEFwciAyMyAyMDAxIEFyamFuIHZhbiBkZSBWZW4gPGFy amFudkByZWRoYXQuY29tPgotIEFkZGVkIElSSVggTkZTIFBhdGNoCi0gQWRkZWQgSW5nbydz IHN3YXAgcGF0Y2gKCiogU3VuIEFwciAyMiAyMDAxIFBldGUgWmFpdGNldiA8emFpdGNldkBy ZWRoYXQuY29tPgotIEFkZGVkIGEgcGF0Y2ggdG8gcmVzdG9yZSBteSBraHViZCBmaXggb3Zl ciB0aGF0IG9mZmljaWFsIG9uZS4KICBJIHRoaW5rIHRoZSBvZmZpY2lhbCBmaXggaXMgbm8g Z29vZCwgd2hpbGUgb3VycyBpcyB0ZXN0ZWQuCi0gQXBwbGllZCBwYXRjaCAyNzEgYWdhaW4g KHdpdGggZHVwbGljYXRlZCBwaWVjZXMgcmVtb3ZlZCkuCi0gQWRkZWQgYSBwYXRjaCBmb3Ig aUZvcmNlIGpveXN0aWNrICgjMzcwNzUpLgoKKiBTdW4gQXByIDIyIDIwMDEgQXJqYW4gdmFu IGRlIFZlbiA8YXJqYW52QHJlZGhhdC5jb20+Ci0gMi40LjMtYWMxMiAoZm9yIHRoZSBQREMg b29wcyBhbmQgdGhlIERWRCBidWdmaXhlcykKLSBhZGRlZCAiYXBtPWFsbG93aW50cyIga2Vy bmVsIG9wdGlvbiBmb3Igc3VzcGVuZCBwcm9ibGVtcywKICBtYWRlIHRoaXMgdGhlIGRlZmF1 bHQgZm9yIElCTSBsYXB0b3BzCgoqIFNhdCBBcHIgMjEgMjAwMSBBcmphbiB2YW4gZGUgVmVu IDxhcmphbnZAcmVkaGF0LmNvbT4KLSAyLjQuMy1hYzExCgoqIEZyaSBBcHIgMjAgMjAwMSBC aWxsIE5vdHRpbmdoYW0gPG5vdHRpbmdAcmVkaGF0LmNvbT4KLSByZXZlcnQgQ0RST00gY2hh bmdlcyBmcm9tIGFjMTAKCiogRnJpIEFwciAyMCAyMDAxIEFyamFuIHZhbiBkZSBWZW4gPGFy amFudkByZWRoYXQuY29tPgotIGZpeGVkIChob3BlZnVsbHkpIGJvdW5jZWJ1ZmZlcmhlYWRz IGRlYWRsb2NrCi0gY2hhbmdlIHJlYm9vdC1iZWhhdmlvciBvZiBEZWxsIFBFMTMwMCdzCgoq IFRodSBBcHIgMTkgMjAwMSBQZXRlIFphaXRjZXYgPHphaXRjZXZAcmVkaGF0LmNvbT4KLSBm aXggZm9yIHltZnBjaSBidXp6aW5nICgjMjk1NjIpLgoKKiBUaHUgQXByIDE5IDIwMDEgUGhp bGlwIENvcGVsYW5kIDxicnljZUByZWRoYXQuY29tPgotIGFkZGVkIGluIHBhdGNoIHRvIGZp eCBhIHN1YnRsZSAyMTE0MyBhdXRvbmVnb3RpYXRpb24gcHJvYmxlbQogIFRoZSBkcml2ZXIg d291bGQgY2xhaW0gdG8gbmVnb3RpYXRlIDEwMC1GRCwgYnV0IHdvdWxkIHJlcG9ydAogIGxh dGUgY29sbGlzaW9ucyBhbmQgYmFkIHRyYW5zbWl0IHRocm91Z2hwdXQuCgoqIFRodSBBcHIg MTkgMjAwMSBNaWNoYWVsIEsuIEpvaG5zb24gPGpvaG5zb25tQHJlZGhhdC5jb20+Ci0gY2xl YW5lZCB1cCBzcGVjIGZpbGUgYSBiaXQKCiogVGh1IEFwciAxOSAyMDAxIEFyamFuIHZhbiBk ZSBWZW4gPGFyamFudkByZWRoYXQuY29tPgotIGFkZGVkIGZpeCBmb3IgRlRQIGV4cGxvaXQK LSBtZXJnZWQgdG8gLWFjMTAKCiogV2VkIEFwciAxOCAyMDAxIEFyamFuIHZhbiBkZSBWZW4g PGFyamFudkByZWRoYXQuY29tPgotIHVwZ3JhZGVkIHRvIDIuNC4zLWFjOQoKKiBUdWUgQXBy IDE3IDIwMDEgQmlsbCBOb3R0aW5naGFtIDxub3R0aW5nQHJlZGhhdC5jb20+Ci0gdXBkYXRl IGlhNjQgdG8gMDEwNDA1ICYgc3luYwoKKiBUdWUgQXByIDE3IDIwMDEgQXJqYW4gdmFuIGRl IFZlbiA8YXJqYW52QHJlZGhhdC5jb20+Ci0gVXBkYXRlZCB0byAyLjQuMy1hYzcKLSBtZXJn ZWQgUGV0ZSBaYWl0Y2V2J3MgVVNCIGJ1Z2ZpeC1wYXRjaGVzCgoqIE1vbiBBcHIgMDkgMjAw MSBBcmphbiB2YW4gZGUgVmVuIDxhcmphbnZAcmVkaGF0LmNvbT4KLSBBZGRlZCBJREUgY29y cnVwdGlvbiBmaXgKCiogU3VuIEFwciAwOCAyMDAxIE1pY2hhZWwgSy4gSm9obnNvbiA8am9o bnNvbm1AcmVkaGF0LmNvbT4KLSBVcGRhdGUgcmVsZWFzZSB0byAyLjQuMi0yCi0gQ2xlYW4g dXAgc29tZSBjcnVmdCBpbiBzcGVjIGZpbGUKLSBSZWxheCBvcmRlcmluZyByZXF1aXJlbWVu dHM6IGdhd2sgdXNlZCBpbiBwb3N0dW4KLSBTdHJlbmd0aGVuIG9yZGVyaW5nIHJlcXVpcmVt ZW50czogbm93IHByZXJlcSBjb3JyZWN0IGluaXRzY3JpcHRzCiAgZm9yIG1ra2VybmVsZG90 aCAocmVhZDogIm1ha2Uga2VybmVsIGRvdCBoIikKCiogU3VuIEFwciAwOCAyMDAxIERvdWcg TGVkZm9yZCA8ZGxlZGZvcmRAcmVkaGF0LmNvbT4KLSBGaXggc29tZSBtdWx0aXBhdGggaXNz dWVzIChtdWx0aXBhdGgtZml4ZXMtNCkKCiogU3VuIEFwciAwOCAyMDAxIEFyamFuIHZhbiBk ZSBWZW4gPGFyamFudkByZWRoYXQuY29tPgotIFVwZGF0ZWQgWGlyY29tIG5vdC1hLVR1bGlw IGRyaXZlcgoKKiBTYXQgQXByIDA3IDIwMDEgRG91ZyBMZWRmb3JkIDxkbGVkZm9yZEByZWRo YXQuY29tPgotIEhvcGVmdWxseSB0aGUgZmluYWwgcm91bmQgb2YgaTgxMCBhdWRpbyBmaXhl cwoKKiBTYXQgQXByIDA3IDIwMDEgQmVuamFtaW4gTGFIYWlzZSA8YmNybEByZWRoYXQuY29t PgotIGV4dHJhY3RlZCBsaW51eC0yLjQuMi1wYWdlX2JpdG1hcC5wYXRjaCBmcm9tIHZtcG9p c29uCiAgYW5kIGFkZGVkIHRvIGFsbCBidWlsZHMuCgoqIFNhdCBBcHIgMDcgMjAwMSBBcmph biB2YW4gZGUgVmVuIDxhcmphbnZAcmVkaGF0LmNvbT4KLSBIb3BlZnVsbHkgZml4ZWQgdGhl IC9ib290L2tlcm5lbC5oIGlzc3VlIGZvcmV2ZXIKLSBTaWxlbmNlIGEgZmV3IG1vcmUgcHJp bnRrJ3MgdG8gYmUgc3lzbG9nIG9ubHkKCiogU2F0IEFwciAgNyAyMDAxIE1hdHQgV2lsc29u IDxtc3dAcmVkaGF0LmNvbT4KLSBkaXNhYmxlIGRlYnVnZ2luZwotIDAuMS41MQoKKiBTYXQg QXByICA3IDIwMDEgSW5nbyBNb2xuYXIgPG1pbmdvQHJlZGhhdC5jb20+Ci0gYWRkZWQgc3dh cCBmaXhlcwoKKiBTYXQgQXByICA3IDIwMDEgSW5nbyBNb2xuYXIgPG1pbmdvQHJlZGhhdC5j b20+Ci0gZXh0MmZzIGNvcnJ1cHRpb24gZml4ZXMKCiogRnJpIEFwciAwNiAyMDAxIEJpbGwg Tm90dGluZ2hhbSA8bm90dGluZ0ByZWRoYXQuY29tPgotIG1vcmUgaWE2NCBjc3VtIHR3ZWFr cwoKKiBGcmkgQXByIDA2IDIwMDEgRG91ZyBMZWRmb3JkIDxkbGVkZm9yZEByZWRoYXQuY29t PgotIGZpeCB0aGUgbXVsdGlwYXRoIGNvZGUgYW5kIHJlLWVuYWJsZQoKKiBUaHUgQXByIDA1 IDIwMDEgTWljaGFlbCBLLiBKb2huc29uIDxqb2huc29ubUByZWRoYXQuY29tPgotIENvbmRp dGlvbmFsaXplIG11bHRpcGF0aCwgZGlzYWJsZWQgZm9yIG5vdwoKKiBUaHUgQXByIDA1IDIw MDEgQXJqYW4gdmFuIGRlIFZlbiA8YXJqYW52QHJlZGhhdC5jb20+Ci0gQWRkZWQgYmNybCdz IHBhdGNoIHRvIGZpeCBTTVAgc3dhcCBjb3JydXB0aW9uCgoqIFRodSBBcHIgMDUgMjAwMSBE b3VnIExlZGZvcmQgPGRsZWRmb3JkQHJlZGhhdC5jb20+Ci0gZml4IGk4MTAgc291bmQgZHJp dmVyIHRvIHdvcmsgYXJvdW5kIGJyb2tlbiBhcnRzZCBhbmQgYSBrZXJuZWwgYnVnCgoqIFdl ZCBBcHIgMDQgMjAwMSBBcmphbiB2YW4gZGUgVmVuIDxhcmphbnZAcmVkaGF0LmNvbT4KLSBB ZGRlZCBmaXhlcyBmb3IgY29ycnVwdGlvbiBpbiBidWZmZXIuYyBhbmQgc2NzaV9tZXJnZQoK KiBXZWQgQXByIDA0IDIwMDEgTWljaGFlbCBLLiBKb2huc29uIDxqb2huc29ubUByZWRoYXQu Y29tPgotIGNvbmZsaWN0IHdpdGggb2xkIHZlcnNpb25zIG9mIG1vdW50IGFuZCBuZnMtdXRp bHMKCiogVHVlIEFwciAwMyAyMDAxIEFyamFuIHZhbiBkZSBWZW4gPGFyamFudkByZWRoYXQu Y29tPgotIGFkZGVkIG9oY2kgcGF0Y2gKCiogVHVlIEFwciAwMyAyMDAxIEluZ28gTW9sbmFy IDxtaW5nb0ByZWRoYXQuY29tPgotIFRVWC1maXhlcyBwYXRjaCwgdXBkYXRlIHRvIC1YNCB2 ZXJzaW9uLgoKKiBGcmkgTWFyIDMwIDIwMDEgQmlsbCBOb3R0aW5naGFtIDxub3R0aW5nQHJl ZGhhdC5jb20+Ci0gZml4IGlhNjQgYnVpbGQKCiogVGh1IE1hciAyOSAyMDAxIEJpbGwgTm90 dGluZ2hhbSA8bm90dGluZ0ByZWRoYXQuY29tPgotIGFkZCBwYXRjaCB0byBmaXggbWFjaGlu ZSBjaGVja3Mgb24gaWE2NCAoPGFzaXQuay5tYWxsaWNrQGludGVsLmNvbT4pCgoqIFdlZCBN YXIgMjggMjAwMSBCZW5qYW1pbiBMYUhhaXNlIDxiY3JsQHJlZGhhdC5jb20+Ci0gYWRkZWQg bGludXgtMi40LjItZG1hLWxpdmVsb2NrLWZpeAoKKiBXZWQgTWFyIDI4IDIwMDEgQmVuamFt aW4gTGFIYWlzZSA8YmNybEByZWRoYXQuY29tPgotIGFkZGVkIGxpbnV4LTIuNC4yLXZtdHJ1 bmNhdGUucGF0Y2gKCiogV2VkIE1hciAyOCAyMDAxIFN0ZXBoZW4gQy4gVHdlZWRpZSA8c2N0 QHJlZGhhdC5jb20+Ci0gQWRkZWQgYWdncmVzc2l2ZSByZWNsYWltIG9mIG9ycGhhbmVkIHN3 YXAgKGlmIHZtYmFsYW5jZSBlbmFibGVkKQoKKiBXZWQgTWFyIDI4IDIwMDEgQXJqYW4gdmFu IGRlIFZlbiA8YXJqYW52QHJlZGhhdC5jb20+Ci0gQWRkZWQgQWxhbidzIGNhcmRidXMgcGF0 Y2gKLSBBZGRlZCB6YWl0Y2V2J3MgVVNCIG1lc3NhZ2UgdGhyb3R0bGluZwoKKiBXZWQgTWFy IDI4IDIwMDEgQmVuamFtaW4gTGFIYWlzZSA8YmNybEByZWRoYXQuY29tPgotIGFkZGVkIEJV RygpIGlmIGJ1ZmZlciB1bmxvY2tlZCBpbiBlbmRfaW8gY2FsbCB0byB2bXBvaXNvbiBwYXRj aAotIGFkZGVkIGxpbnV4LTIuNC4yLXJxZGVidWcucGF0Y2ggZnJvbSBzY3QuCgoqIFdlZCBN YXIgMjggMjAwMSBJbmdvIE1vbG5hciA8bWluZ29AcmVkaGF0LmNvbT4KLSBhbm90aGVyIGJh dGNoIG9mIG11bHRpcGF0aC1maXhlcywgc2VwYXJhdGUgcGF0Y2ggc28gdGhhdAogIHdlIGhh dmUgYW4gZWFzeSB3YXkgYmFjay4KCiogVHVlIE1hciAyNyAyMDAxIEJlbmphbWluIExhSGFp c2UgPGJjcmxAcmVkaGF0LmNvbT4KLSBhZGRlZCBCVUcoKSBpZiBidWZmZXIgdW5sb2NrZWQg aW4gZW5kX2lvIGNhbGwgdG8gdm1wb2lzb24gcGF0Y2gKCiogVHVlIE1hciAyNyAyMDAxIFN0 ZXBoZW4gQy4gVHdlZWRpZSA8c2N0QHJlZGhhdC5jb20+Ci0gZml4IGRlYnVnZ2luZyBjb25m bGljdCB3aXRoIHNtYmZzIGludGVybmFsIGRlYnVnZ2luZwoKKiBUdWUgTWFyIDI3IDIwMDEg VGltIFdhdWdoIDx0d2F1Z2hAcmVkaGF0LmNvbT4KLSBhZGRlZCBsaW51eC0yLjQuMi1yZXN0 b3Jlc3RhdGUucGF0Y2g6IGZpeCBidWcgIzMxMTcwCgoqIFR1ZSBNYXIgMjcgMjAwMSBCZW5q YW1pbiBMYUhhaXNlIDxiY3JsQHJlZGhhdC5jb20+Ci0gZml4IGRlYnVnZ2luZyBidWcgd2l0 aCByZWNsYWltX3BhZ2UKCiogVHVlIE1hciAyNyAyMDAxIEFyamFuIHZhbiBkZSBWZW4gPGFy amFudkByZWRoYXQuY29tPgotIEFkZGVkIEFsYW4ncyAiYmxhY2tsaXN0IEtUN1JBSUQgZm9y IElERSBETUEiIHBhdGNoCgoqIFR1ZSBNYXIgMjcgMjAwMSBCZW5qYW1pbiBMYUhhaXNlIDxi Y3JsQHJlZGhhdC5jb20+Ci0gdXBkYXRlZCBsaW51eC0yLjQuMi1ub19wcm9maWxlLnBhdGNo IHRvIGNvcnJlY3QgcGF0Y2gKLSB1cGRhdGVkIGxpbnV4LTIuNC4yLXZtcG9pc29uLnBhdGNo IHRvIGZpeCBhIGJ1ZwoKKiBNb24gTWFyIDI2IDIwMDEgQmVuamFtaW4gTGFIYWlzZSA8YmNy bEByZWRoYXQuY29tPgotIGFkZGVkIGxpbnV4LTIuNC4yLWZpbmRfcGFnZS5wYXRjaDogcG90 ZW50aWFsIGNvcnJ1cHRpb24gZml4Ci0gYWRkZWQgbGludXgtMi40LjItbm9fcHJvZmlsZS5w YXRjaCByZWdhaW4gNk1CIG9mIG1lbW9yeSBvbiBib290Ci0gYWRkZWQgbGludXgtMi40LjIt Ym9vdG1lbV9vb20ucGF0Y2ggdG8gcGFuaWMgb24gb29tIGR1cmluZyBib290Ci0gdXBkYXRl ZCBsaW51eC0yLjQuMi12bXBvaXNvbi5wYXRjaCB3aXRoIG1vcmUgcG9pc29uLCByZW1vdmVk CiAgbGludXgtMi40LjItdXB0b2RhdGUucGF0Y2gKLSBhZGRlZCBsaW51eC0yLjQuMi1pMm9p bml0LnBhdGNoIGZyb20gQXJqYW4KCiogTW9uIE1hciAyNiAyMDAxIEJpbGwgTm90dGluZ2hh bSA8bm90dGluZ0ByZWRoYXQuY29tPgotIHBhdGNoIGZyb20gRGF2aWQgTW9zYmVyZ2VyIHRv IGZpeCBuZXR3b3JraW5nIGlzc3VlcyBvbiBpYTY0CgoqIE1vbiBNYXIgMjYgMjAwMSBBcmph biB2YW4gZGUgVmVuIDxhcmphbnZAcmVkaGF0LmNvbT4KLSBNYXJrIE9TQjQgZHJpdmVyIGV4 cGVyaW1lbnRhbAotIFVwZGF0ZSBUVVgyCi0gbWVyZ2VkIHphaXRjZXYncyBPVjUxMSBmaXgK LSBkaXNhYmxlZCBkbWE2NiBmb3IgYWxsIHZpYSBJREUgY2hpcHNldHMKCiogU3VuIE1hciAy NSAyMDAxIEJlbmphbWluIExhSGFpc2UgPGJjcmxAcmVkaGF0LmNvbT4KLSBBZGRlZCBsaW51 eC0yLjQuMi11cHRvZGF0ZS5kaWZmIHRvIEJVRygpIG91dCBvbiBwYWdlIGNhY2hlIG1pc3Vz ZTsKICBhbHNvIGluY2x1ZGVzIGEgcG90ZW50aWFsIGZpeCBmb3IgdGhlIGNvcnJ1cHRpb24g cHJvYmxlbS4KCiogU3VuIE1hciAyNSAyMDAxIEluZ28gTW9sbmFyIDxtaW5nb0ByZWRoYXQu Y29tPgotIFVwZGF0ZSB0aGUgbXVsdGlwYXRoLWZpeGVzIHBhdGNoIHRvIHRoZSBtdWNoIGxl c3MKICByYWRpY2FsIEMwIHZlcnNpb24sIEIxIHdhcyBuZXZlciBtZWFudCB0byBiZSBjb21t aXR0ZWQsCiAgaXQgd2FzIGEgRGVsbC1vbmx5IHRlc3QtcGF0Y2ghCgoqIFNhdCBNYXIgMjQg MjAwMSBTdGVwaGVuIEMuIFR3ZWVkaWUgPHNjdEByZWRoYXQuY29tPgotIEFkZGVkIGJ1ZmZl cl9oZWFkIGhpZ2htZW0gZml4CgoqIEZyaSBNYXIgMjMgMjAwMSBCZW5qYW1pbiBMYUhhaXNl IDxiY3JsQHJlZGhhdC5jb20+Ci0gYWRkZWQgbGludXgtMi40LjItYXZpcm8tYnVmZmVyLmMu cGF0Y2gKLSB1cGRhdGVkIGxpbnV4LTIuNC4yLXZtcG9pc29uLnBhdGNoCgoqIEZyaSBNYXIg MjMgMjAwMSBEb3VnIExlZGZvcmQgPGRsZWRmb3JkQHJlZGhhdC5jb20+Ci0gVXBkYXRlIHRo ZSBtdWx0aXBhdGgtZml4ZXMgcGF0Y2ggdG8gdGhlIEIxIHZlcnNpb24gZnJvbSBJbmdvCgoq IEZyaSBNYXIgMjMgMjAwMSBBcmphbiB2YW4gZGUgVmVuIDxhcmphbnZAcmVkaGF0LmNvbT4K LSBNZXJnZWQgYnVnZml4ZXMgZnJvbSAyLjQuMi1hYzIzCiAgKiBpc2FwbnAgZml4CiAgKiBy ZWlzZXJmcyBjb3JydXB0aW9uCiAgKiBzb3VuZCBsb2NrX2tlcm5lbCB0aGlua29zCiAgKiBh bGxvdyBzbGVlcGluZyBpbiBDLUEtRCBoYW5kbGVycwogICogc21hbGwgUFBQIHJhY2UKCgoq IFRodSBNYXIgMjIgMjAwMSBCaWxsIE5vdHRpbmdoYW0gPG5vdHRpbmdAcmVkaGF0LmNvbT4K LSBtZXJnZSBpbiAwMTAzMjEgaWE2NCBwYXRjaCBmcm9tIERhdmlkIE1vc2JlcmdlcgotIGRv bid0IGFwcGx5IHZtcG9pc29uLnBhdGNoIG9uIGlhNjQgKGl0IHJlbGllcyBvbiBwZXItY3B1 LXBhZ2VzKQoKKiBUaHUgTWFyIDIyIDIwMDEgQmVuamFtaW4gTGFIYWlzZSA8YmNybEByZWRo YXQuY29tPgotIGFkZGVkIGxpbnV4LTIuNC4yLXJlcV9maW5pc2hlZF9pby5wYXRjaCBmb3Ig cmVxX2ZpbmlzaGVkX2lvCi0gdXBkYXRlZCB2bXBvaXNvbi5wYXRjaCB0byBmaXggYSBrbWFw IHByb2JsZW0KLSBhZGRlZCBsaW51eC0yLjQuMi1pcF9jb25udHJhY2sucGF0Y2ggdG8gZml4 IGEgaGFzaCB0YWJsZQogIHNpemUgb2YgMCB3aGljaCByZXN1bHRzIGluIGFuIE9vcHMgb24g c3RhcnR1cAotIGFkZGVkIGxpbnV4LTIuNC4yLXBtZF9hbGxvY19maXgucGF0Y2gKLSBhZGRl ZCBsaW51eC0yLjQuMi1ib290bWVtLnBhdGNoIHRvIGZpeCBhbiBvZmYgYnkgb25lIGVycm9y CiAgdGhhdCByZXN1bHRzIGluIG1lbW9yeSBvdmVyd3JpdGVzCgoqIFRodSBNYXIgMjIgMjAw MSBBcmphbiB2YW4gZGUgVmVuIDxhcmphbnZAcmVkaGF0LmNvbT4KLSBBZGRlZCBwYXRjaCBm cm9tIERhdmVNIHRvIGZpeCBJUHY2IHR1bm5lbHMuCi0gTWVyZ2VkIHR1eCBWMQotIERpc2Fi bGVkIHRoZSBTZXJ2ZXJ3b3JrcyBVRE1BIHN1cHBvcnQKLSBBZGRlZCBJQk0ncyBuZXcgU2Vy dmVyUkFJRCBkcml2ZXIuIFRoaXMgb25lIGhhcyBzdXJ2aXZlZCBsb3RzIG9mIHRlc3RpbmcK ICAgIGJ5IElCTQotIEFkZGVkIHB0cmFjZSBwYXRjaAoKKiBXZWQgTWFyIDIxIDIwMDEgUGhp bGlwIENvcGVsYW5kIDxicnljZUByZWRoYXQuY29tPgotIFVwZGF0ZWQgY29uZmlnIGZpbGVz IHRvIHRha2UgYWNjb3VudCBvZiB0d28gbmV3IGNvbmZpZyBvcHRpb25zCiAgQ09ORklHX0lQ X1ZTX0RFQlVHIChuKQogIENPTkZJR19JUF9WU19UQUJfQklUUyAoMTYpCi0gTW9kaWZpZWQg dGhlIDIuNC4yLWNpcGUucGF0Y2ggdG8gYWNvbW9kYXRlIHRoZSBjaGFuZ2Ugb2YgbG9jYXRp b24KICBvZiBpcHZzCgoqIFdlZCBNYXIgMjEgMjAwMSBQaGlsaXAgQ29wZWxhbmQgPGJyeWNl QHJlZGhhdC5jb20+Ci0gcmV0aXJlZCBQYXRjaDI3NSBhbmQgcmVwbGFjZWQgaXQgd2l0aCAy NzYgb24gdGhlIHJlY29tZW5kYXRpb24gb2YKICBXZW5zb25nIHdoaWNoIG1vdmVzIGlwdnMg ZnJvbSAwLjEuMiAtPiAwLjIuNAogIFN0cnVjdHVyYWxseSByZW1vdmVzIG5ldC9pcHY0L25l dGZpbHRlci9pcF92cyBhbmQgbW92ZXMgaXQgdG8KICBuZXQvaXB2NC9pcHZzCgoqIFdlZCBN YXIgMjEgMjAwMSBEb3VnIExlZGZvcmQgPGRsZWRmb3JkQHJlZGhhdC5jb20+Ci0gZml4IG1l bW9yeSBsZWFrIGluIGk4MTAgc291bmQgZHJpdmVyCi0gdXBkYXRlIHNjc2ktcmVzZXQgcGF0 Y2ggdG8gY29ycmVjdCBzb21lIGxvY2tpbmcgaXNzdWVzIHVuZGVyIGhlYXZ5IHJlc2V0CiAg Y29uZGl0aW9ucyAoSmFtZXMgQm90dG9tbGV5KQoKKiBXZWQgTWFyIDIxIDIwMDEgU3RlcGhl biBDLiBUd2VlZGllIDxzY3RAcmVkaGF0LmNvbT4KLSBBZGRlZCBzaGFyZWQgbWVtb3J5IGxv Y2tpbmcgZml4CgoqIFdlZCBNYXIgMjEgMjAwMSBBcmphbiB2YW4gZGUgVmVuIDxhcmphbnZA cmVkaGF0LmNvbT4KLSBzaWxlbmNlZCBEUkkgZGVidWdnaW5nIG1lc3NhZ2VzCi0gbWVyZ2Vk IEluZ28ncyBwYXRjaCBmb3Igc3BpbmxvY2tzIGFyb3VuZCBhcGljIG9wZXJhdGlvbnMKCiog V2VkIE1hciAyMSAyMDAxIERvdWcgTGVkZm9yZCA8ZGxlZGZvcmRAcmVkaGF0LmNvbT4KLSB1 cGRhdGUgaTgxMCBzb3VuZCBkcml2ZXIgdG8gc29sdmUgYXJ0c2Qgb3V0cHV0IHByb2JsZW1z Ci0gYWRkZWQgc2NzaV9zY2FuIHBhdGNoIHRvIG1ha2Ugc2Nhbm5pbmcgb2Ygc3BhcnNlbHVu IGRldmljZXMgd29yayBhZ2FpbgotIHVwZGF0ZSBvbGQgYWljN3h4eCBkcml2ZXIgdG8gcG9z c2libHkgZml4IDc4OTYgbG9ja3VwIHByb2JsZW1zCi0gdXBkYXRlZCBuZXcgYWljN3h4eCBk cml2ZXIgdG8gdmVyc2lvbiA2LjEuNwoKKiBUdWUgTWFyIDIwIDIwMDEgQXJqYW4gdmFuIGRl IFZlbiA8YXJqYW52QHJlZGhhdC5jb20+Ci0gQWRkZWQgcGF0Y2ggZm9yIG5ldGdlYXIgZmEz MXggYm9hcmRzIHBvd2Vyc3RhdGUKLSBBZGRlZCBwYXRjaCB0byBzaWxlbmNlIFBTLzIgY29k ZSAobm8ga2V5Ym9hcmQgdGhlcmUgaWYKICB0aGVyZSBpcyBhIFVTQiBrZXlib2FyZCkKCiog TW9uIE1hciAxOSAyMDAxIEFyamFuIHZhbiBkZSBWZW4gPGFyamFudkByZWRoYXQuY29tPgot IEFkZGVkIFphaXRjZXYncyBwYXRjaCBmb3IgVVNCIG1pY2UgKCMyMzY3MCkKCgoqIFN1biBN YXIgMTggMjAwMSBBcmphbiB2YW4gZGUgVmVuIDxhcmphbnZAcmVkaGF0LmNvbT4KLSBBZGRl ZCBmaXggZm9yIEhQVDM3MCBVRE1BIHByb2JsZW0KCiogRnJpIE1hciAxNiAyMDAxIE1pY2hh ZWwgSy4gSm9obnNvbiA8am9obnNvbm1AcmVkaGF0LmNvbT4KLSBBZGRlZCBxbG9naWNmYyB0 byB0aGUgbGlzdCBvZiBjb250cm9sbGVycyB3aXRoIGxpbWl0ZWQgc2NzaSByZXF1ZXN0IHNp emVzCgoqIFRodSBNYXIgMTUgMjAwMSBNaWNoYWVsIEsuIEpvaG5zb24gPGpvaG5zb25tQHJl ZGhhdC5jb20+Ci0gdXBkYXRlZCBiaW5mbXRfbWlzYyBwYXRjaCB0byBjcmVhdGUgZGlyZWN0 b3J5CgoqIFRodSBNYXIgMTUgMjAwMSBCZW5qYW1pbiBMYUhhaXNlIDxiY3JsQHJlZGhhdC5j b20+Ci0gYWRkZWQgbGludXgtMi40LjItYWMyMC1wbWRfYWxsb2MuZGlmZiBmaXggZm9yIFBB RQoKKiBUaHUgTWFyIDE1IDIwMDEgQXJqYW4gdmFuIGRlIFZlbiA8YXJqYW52QHJlZGhhdC5j b20+Ci0gQWRkZWQgQWwgVmlybydzIHBhdGNoIHRvIGZzL25hbWVpLmMKLSBBZGRlZCB0aGUg QktMIHBhdGNoIGZvciB0cnVuY2F0ZSAoMi40LjItYWMpCi0gYWRkZWQgVk0gcG9pc29uCgoq IFdlZCBNYXIgMTQgMjAwMSBBcmphbiB2YW4gZGUgVmVuIDxhcmphbnZAcmVkaGF0LmNvbT4K LSBBZGRlZCAyLjQuMi1hYzIwIEkyTyBwYXRjaGVzCi0gTWFkZSBQQ0kgcHJpbnRrJ3MgS0VS Tl9JTkZPCgoqIFRodSBNYXIgMTMgMjAwMSBTdGVwaGVuIEMuIFR3ZWVkaWUgPHNjdEByZWRo YXQuY29tPgotIG1lcmdlIGluIFZNIHBlcmZvcm1hbmNlIGNoYW5nZXMgdXAgdG8gMi40LjIt YWMxOAoKKiBUdWUgTWFyIDEzIDIwMDEgQXJqYW4gdmFuIGRlIFZlbiA8YXJqYW52QHJlZGhh dC5jb20+Ci0gZml4IGJ1ZyAzMDUxMyAoaW9zdGF0IHZzIHByb21pc2UgSURFIGJvYXJkcykK LSBUVVggMi40LjItUzQKLSBtZXJnZWQgbWQgZml4ZXMKCiogTW9uIE1hciAxMiAyMDAxIEJp bGwgTm90dGluZ2hhbSA8bm90dGluZ0ByZWRoYXQuY29tPgotIHJ1biAvdXNyL3NiaW4vbW9k dWxlX3VwZ3JhZGUgaW4gYSBrdWR6dSB0cmlnZ2VyIGFzIHdlbGwKCiogTW9uIE1hciAxMiAy MDAxIEFyamFuIHZhbiBkZSBWZW4gPGFyamFudkByZWRoYXQuY29tPgotIG1lcmdlZCBidWdm aXhlcyBmcm9tIDIuNC4yLWFjMTg6CiAgLSByZWlzZXJmcyBjbGVhbnVwCiAgLSB6ZXJvY29w eSBidWdmaXhlcwogIC0gemVyb2NvcHkgbmJkCiAgLSBzbWJmcyBmaXhlcwogIC0gY3lyaXgg SUlJIE1UUlIgY2hlY2tzCiAgLSB2bWFsbG9jIHJhY2UgZml4CiAgLSBwY21jaWEgcmVzb3Vy Y2UgZml4Ci0gbWVyZ2VkIFRVWCAyLjQuMi1QMwotIG5ldyB2ZXJzaW9uIG9mIHRoZSB4aXJj b20gZHJpdmVyCi0gZGVmYXVsdCBsaW1pdCBvZiA2NCBzZWN0b3JzIGluIGEgc2NzaSByZXF1 ZXN0Ci0gZW5hYmxlZCBzbGFiIHBvaXNvbgotIGZpeGVkIDI4NDg5CgoqIEZyaSBNYXIgMDkg MjAwMSBNaWNoYWVsIEsuIEpvaG5zb24gPGpvaG5zb25tQHJlZGhhdC5jb20+Ci0gQWRkZWQg YW5vdGhlciByZXF1ZXN0LXNpemUgbGltaXRpbmcgcGF0Y2ggZm9yIFFsb2dpYyBzYnVzIGFu ZCBCdXNMb2dpYywKICBtYXkgbmVlZCB0byBhZGQgbW9yZSBhZGFwdGVycyB0byB0aGlzIHBh dGNoIG92ZXIgdGltZQoKKiBGcmkgTWFyIDA5IDIwMDEgQXJqYW4gdmFuIGRlIFZlbiA8YXJq YW52QHJlZGhhdC5jb20+Ci0gQWRkZWQgUUxvZ2ljIElTUCByZXF1ZXN0LXNpemUgbGltaXRp bmcgcGF0Y2gKLSBVcGRhdGVkIHhpcmNvbV9jYiBkcml2ZXIgdG8gbmV3ZXIgdmVyc2lvbgot IFBvdGVudGlhbCB3b3JrYXJvdW5kIGZvciBBYml0IEtUN0FSQUlEIGJvYXJkIGJ1Z3MgaW4g dmlhLWNvcnJ1cHRpb24gcGF0Y2gKCiogVGh1IE1hciAwOCAyMDAxIE1pY2hhZWwgSy4gSm9o bnNvbiA8am9obnNvbm1AcmVkaGF0LmNvbT4KLSBBZGRlZCBjaXBlZml4IHBhdGNoIGZyb20g RGF2aWQgTWlsbGVyCgoqIFRodSBNYXIgMDggMjAwMSBTdGVwaGVuIEMuIFR3ZWVkaWUgPHNj dEByZWRoYXQuY29tPgotIGFkZCBjdXJyZW50IHJhdyBJTyBmaXhlcwoKKiBUaHUgTWFyIDA4 IDIwMDEgUGV0ZSBaYWl0Y2V2IDx6YWl0Y2V2QHJlZGhhdC5jb20+Ci0gQWRkaW5nIGEgZml4 IGZvciB1c2ItdWhjaSB0byB3b3JrIHdoZW4gU0xBQiBpcyBub3QgYWxpZ25lZCAocG9pc29u ZWQpLgoKKiBUaHUgTWFyIDA4IDIwMDEgTWljaGFlbCBLLiBKb2huc29uIDxqb2huc29ubUBy ZWRoYXQuY29tPgotIG5vdyBwcmVyZXEgbW9kdXRpbHMgMi40LjItNSBmb3IgbmV3IGJpbmZt dF9taXNjIHN1cHBvcnQKCiogVGh1IE1hciAwOCAyMDAxIEFyamFuIHZhbiBkZSBWZW4gPGFy amFudkByZWRoYXQuY29tPgotIGFkZGVkIEluZ28ncyBib3VuY2VidWZmZXIgcGF0Y2gKLSBh ZGRlZCBUaW0gV2F1Z2hzIHBhcnBvcnQgZml4ZXMKLSBzd2l0Y2hlZCB0byBBbGFuJ3MgY2xl YW5lZCB1cCBtZWdhcmFpZAotIGFkZGVkIHphaXRjZXYncyBwYXRjaCB0byBwcmV2ZW50IExW TSBvb3BzCi0gYWRkZWQgVGhhbiBOZ28ncyBwYXRjaCBmb3IgcGNtY2lhIElTRE4KLSBmb3J3 YXJkLXBvcnRlZCAyLjIuMTlwcmUxIHZpYSB0aW1lcmJ1ZyB3b3JrYXJvdW5kCi0gYWRkZWQg QWwgVmlybydzIGJpbmZtdF9taXNjCgoqIFdlZCBNYXIgMDcgMjAwMSBBcmphbiB2YW4gZGUg VmVuIDxhcmphbnZAcmVkaGF0LmNvbT4KLSBhZGRlZCBlcGNhIHBhdGNoIGFuZCBtb3JlIFVT QiBzY2FubmVyIElEJ3MgZnJvbSAyLjQuMi1hYzEzCi0gYWRkZWQgdGhlIElERSBkbWEgYmxh Y2tsaXN0CgoqIFR1ZSBNYXIgMDYgMjAwMSBEb3VnIExlZGZvcmQgPGRsZWRmb3JkQHJlZGhh dC5jb20+Ci0gaGVhdmlseSBwYXRjaGVkL21vZGlmaWVkIHZlcnNpb24gb2YgdGhlIGk4MTAg YXVkaW8gZHJpdmVyCgoqIFR1ZSBNYXIgMDYgMjAwMSBBcmphbiB2YW4gZGUgVmVuIDxhcmph bnZAcmVkaGF0LmNvbT4KLSBhZGRlZCBwZ2UgcGF0Y2ggZm9yIEN5cml4IDY4NiBrZXJuZWxz IGZyb20gQXJqYW4KCiogVHVlIE1hciAwNiAyMDAxIE1pY2hhZWwgSy4gSm9obnNvbiA8am9o bnNvbm1AcmVkaGF0LmNvbT4KLSBkZXBtb2QgLWFlCgoqIFR1ZSBNYXIgMDYgMjAwMSBBcmph biB2YW4gZGUgVmVuIDxhcmphbnZAcmVkaGF0LmNvbT4KLSAyIG1vcmUgcGF0Y2hlcyBmcm9t IDIuNC4yLWFjMTEvMTIgKDgxMzl0b28gYW5kIHRoZSBwY2kgcmVzb3VyY2VzIEFQSSBjaGFu Z2UgKQotIHdvcmthcm91bmQgZm9yIHRoZSB0b2tlbnJpbmcgaW5pdCBtZXNzCi0gYWRkZWQg cGF0Y2ggdG8gZW5hYmxlIHRoZSBzZWNvbmQgSURFIGNoYW5uZWwgb24gUERDMjAyNjUncwoK KiBUdWUgTWFyICA2IDIwMDEgTWF0dCBXaWxzb24gPG1zd0ByZWRoYXQuY29tPgotIGFkZGVk IGxpbnV4LTIuNC4yLWkyby1ibG9ja3NpemUucGF0Y2ggKFBhdGNoMjI1KSB0byBmaXggaTJv IC9wcm9jL3BhcnRpdGlvbnMKICBlbnRyaWVzCgoqIE1vbiBNYXIgMDUgMjAwMSBNaWNoYWVs IEsuIEpvaG5zb24gPGpvaG5zb25tQHJlZGhhdC5jb20+Ci0gVHVybmVkIG9mZiBDT05GSUdf VVNCX01PVVNFIGJlY2F1c2UgdGhlIEhJRCBjb2RlIGhhbmRsZXMgYWxsIG1pY2Ugd2Uga25v dwoKKiBNb24gTWFyIDA1IDIwMDEgQXJqYW4gdmFuIGRlIFZlbiA8YXJqYW52QHJlZGhhdC5j b20+Ci0gQWRkZWQgdGhlIHBhdGNoIGZyb20gREhpbmRzIHRvIGZpeCBjYXJkYnVzIGlycXMK LSBlbmFibGVkIG11bHRpY2FzdCByb3V0aW5nLCBicmlkZ2luZyBhbmQgUU9TCi0gbWVyZ2Vk IHBhdGNoZXMgMjE0IHRvIDIyNCBmcm9tIDIuNC4yLWFjMTEKCgoqIFN1biBNYXIgNCAyMDAx IFBoaWxpcCBDb3BlbGFuZCA8YnJ5Y2VAcmVkaGF0LmNvbT4KLSBSZXZlcnRlZCB0aGUgcGFy cG9ydF9kZXZpY2VfaWQgY2hhbmdlcyB0aGF0IGFyZSBpbiBhYzMKICB3aGljaCBwcmV2ZW50 IHRoZSBrZXJuZWwtc291cmNlcy14Lnkuei5zcmMucnBtIGZyb20KICBiZWluZyByZWNvbXBp bGVkCgoqIEZyaSBNYXIgMDIgMjAwMSBJbmdvIE1vbG5hciA8bWluZ29AcmVkaGF0LmNvbT4K LSBsaW51eC0yLjQuMi1ubWktbG9ja3VwLXdvcmthcm91bmQucGF0Y2ggdGVtcG9yYXJpbHkg ZGVmYXVsdHMgbm1pIHdhdGNoZG9nIG9mZgoKKiBGcmkgTWFyIDAyIDIwMDEgUGhpbGlwIENv cGVsYW5kIDxicnljZUByZWRoYXQuY29tPgotIGFkZGVkIGxpbnV4LTIuNC4yLWFscGhhLWly b25nYXRlLnBhdGNoIGZyb20gQ29tcGFxCgoqIEZyaSBNYXIgMDIgMjAwMSBNaWNoYWVsIEsu IEpvaG5zb24gPGpvaG5zb25tQHJlZGhhdC5jb20+Ci0gYWRkZWQgQXJqYW4ncyBsaW51eC0y LjQuMi12aWEtY29ycnVwdGlvbi5wYXRjaCB0byBmaXggZGlzayBjb3JydXB0aW9uCiAgcHJv YmxlbXMgd2lkZWx5IHJlcG9ydGVkIG9uIEtUMTMzIG1hY2hpbmVzCi0gU3RlcGhlbi9UaW0g Zml4ZWQgbGludXgtMi40LjEtYXhib2Utc2NzaS1tYXgtc2VjLnBhdGNoIGZpeGluZyBzY3Np IHBlcmZvcm1hbmNlCgoqIFRodSBNYXIgMDEgMjAwMSBEb3VnIExlZGZvcmQgPGRsZWRmb3Jk QHJlZGhhdC5jb20+Ci0gQWRkZWQgdGhlIHNjc2ktcmVzZXQgcGF0Y2ggc28gdGhhdCB5b3Ug Y2FuIHJlc2V0IGRldmljZXMgdGhyb3VnaCB0aGVpcgogIHNnIGVudHJ5CgoqIFRodSBNYXIg MDEgMjAwMSBBcmphbiB2YW4gZGUgVmVuIDxhcmphbnZAcmVkaGF0LmNvbT4KLSB1cGRhdGVk IHJlaXNlcmZzIHRvIGxhdGVzdCB2ZXJzaW9uCi0gcHJldmVudCByYWlkIGZyb20gb29wc2lu ZwotIGxvY2tkIHBhdGNoCi0gYWRkZWQgYWx0ZXJuYXRlIGFpcm9fY3MgZHJpdmVyCi0gYWRk ZWQgemFpdGNldidzIFVTQiBhbGxvYyBmaXgKCiogV2VkIEZlYiAyOCAyMDAxIE1pY2hhZWwg Sy4gSm9obnNvbiA8am9obnNvbm1AcmVkaGF0LmNvbT4KLSBhdHAuYyB3b3VsZCBub3QgY29t cGlsZSBhcyBhIG1vZHVsZSwgZml4ZWQKCiogV2VkIEZlYiAyOCAyMDAxIEFyamFuIHZhbiBk ZSBWZW4gPGFyamFudkByZWRoYXQuY29tPgotIEFkZGVkIGV4dHJhIFRvc2hvYm9lIFBDSSBJ RCAoMjk5OTMpCi0gYWRkZWQgImZpeCBoYW5nIGluIHBhcnBvcnQiIHBhdGNoICh0d2F1Z2gp Ci0gbWFlc3RybzMgRE1BIGZpeAotIGZpeGVkIDI5OTA4IChsb29wZGV2aWNlIG9vcHMpCgoq IFR1ZSBGZWIgMjcgMjAwMSBNYXR0IFdpbHNvbiA8bXN3QHJlZGhhdC5jb20+Ci0gYWRkZWQg YSBwYXRjaCB0byBmaXggZm9yIG5vbi1hdG9taWMgYml0IGNsZWFyIGluIGVlcHJvMTAwIGRy aXZlciBvbiBhbHBoYQogIChsaW51eC0yLjQuMi1lZXBybzEwMC1hbHBoYS5wYXRjaCkKCiog VHVlIEZlYiAyNyAyMDAxIEFyamFuIHZhbiBkZSBWZW4gPGFyamFudkByZWRoYXQuY29tPgot IHVwZGF0ZWQgaWtkIHRvIDIuNC4yCi0gYWRkZWQgb2x5bXBpYyBkcml2ZXIgZml4Ci0gbWFr ZSBBbHBoYSBoYXBweQotIGFkZGVkIG9wbDNzYSBwYXRjaAotIGFkZGVkIG5ldGRldmljZSBz ZXR1cCBwYXRjaAotIGFkZGVkIDN3YXJlIHBhdGNoCi0gbWVyZ2VkIFRVWCB2ZXJzaW9uIEc5 CiAKKiBNb24gRmViIDI2IDIwMDEgRG91ZyBMZWRmb3JkIDxkbGVkZm9yZEByZWRoYXQuY29t PgotIGJ1ZyBmaXggdG8gdGhlIGFpYzd4eHgtNS4yLjMgZHJpdmVyCi0gQWRkZWQgTWljaGFl bCBFLiBCcm93biA8bWljaGFlbF9lX2Jyb3duQGRlbGwuY29tPiBwYXRjaCB0byBhZGQgYW4g aW9jdGwgdG8KICB0aGUgYmxvY2sgZGV2aWNlIGxheWVyIHRvIGFsbG93IGFjY2Vzc2luZyB0 aGUgbGFzdCBzZWN0b3JzIGluIGEgYmxvY2sKICBkZXZpY2UgdGhhdCBoYXMgYW4gb2RkIG51 bWJlciBvZiBzZWN0b3JzIChuZWVkZWQgZm9yIEVGSSBjb21wbGlhbmNlKQotIEFkZGVkIElu Z28ncyBtdWx0aXBhdGggSS9PIHN1cHBvcnQgZm9yIHRoZSBtZCByYWlkIGxheWVyCgoqIE1v biBGZWIgMjYgMjAwMSBCaWxsIE5vdHRpbmdoYW0gPG5vdHRpbmdAcmVkaGF0LmNvbT4KLSBm aXggYSBjYXNlIHdoZXJlIHRoZSBpYTY0IGNsb2NrIGNhbiBnbyBiYWNrd2FyZHMgKGZyb20g PHN0ZWluZXJAc2dpLmNvbT4pCgoqIE1vbiBGZWIgMjYgMjAwMSBBcmphbiB2YW4gZGUgVmVu IDxhcmphbnZAcmVkaGF0LmNvbT4KLSBBZGRlZCBuZXRkZWJ1ZyBwYXRjaCBvbiBEYXZlTSdz IHJlcXVlc3QKLSBBZGRlZCBzdXBwb3J0IGZvciB0aGUgRXBzb24gMTI0MFUgdXNiIHNjYW5u ZXIKLSByZW1vdmVkIHdhdmVsYW4gdWRlbGF5IHBhdGNoIChubyBsb25nZXIgbmVlZGVkIGZv ciBnY2MgMi45Ni03NCkKLSBkZXJhY2UgdGhlIHdha2luZyBvZiB0aGUgdXNiIHN0b3JhZ2Ug dGhyZWFkCi0gbWVyZ2VkIHRvIDIuNC4yLWFjMywgYnVtcGVkIHZlcnNpb24gdG8gMC4xLjE1 Ci0gcHV0IGluIHRoZSBuZXcsIGV4cGVyaW1lbnRhbCB4aXJjb21fY2IgZHJpdmVyCi0gdXBn cmFkZWQgdG8gdHV4IDIuNC4yLUY4CgoqIEZyaSBGZWIgMjMgMjAwMSBNaWNoYWVsIEsuIEpv aG5zb24gPGpvaG5zb25tQHJlZGhhdC5jb20+Ci0gYWRkZWQgcHJlaW5zdGFsbHMgZm9yIHNt cCBhbmQgZW50ZXJwcmlzZSB0byBtb2Rwcm9iZSBsb29wIGxpa2UgdW5pcHJvY2Vzc29yCi0g ZGlzYWJsZWQgM2M5MHggZHJpdmVyIGJlY2F1c2UgaXQgZG9lcyBub3Qgd29yayBjb3JyZWN0 bHkuCgoqIEZyaSBGZWIgMjMgMjAwMSBCaWxsIE5vdHRpbmdoYW0gPG5vdHRpbmdAcmVkaGF0 LmNvbT4KLSBqdXN0IHJlbW92ZSBtb2R1bGVzLiogaW4gJXByZXVuOyBjYXRjaGVzIGFueXRo aW5nIG5ldywgYW5kCiAgYXZvaWRzIGVycm9ycyBpZiBjZXJ0YWluIGZpbGVzIGFyZW4ndCB0 aGVyZQoKKiBGcmkgRmViIDIzIDIwMDEgQXJqYW4gdmFuIGRlIFZlbiA8YXJqYW52QHJlZGhh dC5jb20+Ci0gVXBkYXRlZCAzYzU5eCBkcml2ZXIgdG8gdmVyc2lvbiAxLjEuMTQgZnJvbSBB bmRyZXcgTW9ydG9uCi0gZW5hYmxlZCBIZXdsZXR0LVBhY2thcmQgODIwMGUvODIxMGUgQ0Qt V3JpdGVyIFBsdXMKLSBlbmFibGVkIEFkdmFuY2VkIHJvdXRpbmcgKCMyOTA4NykKCiogVHVl IEZlYiAyMiAyMDAxIE1hdHQgV2lsc29uIDxtc3dAcmVkaGF0LmNvbT4KLSB1cGRhdGVkIG1v ZHVsZS1pbmZvIHRvIHRoZSBjb3B5IGZyb20gYW5hY29uZGEgQ1ZTCgoqIFRodSBGZWIgMjIg MjAwMSBBcmphbiB2YW4gZGUgVmVuIDxhcmphbnZAcmVkaGF0LmNvbT4KLSBhZGRlZCAzd2Fy ZSBwYXRjaAotIHJlLWVuYWJsZWQgM3dhcmUgYWdhaW4KCiogVGh1IEZlYiAyMiAyMDAxIE1p Y2hhZWwgSy4gSm9obnNvbiA8am9obnNvbm1AcmVkaGF0LmNvbT4KLSBhZGRlZCBsaW51eC0y LjQuMS1mbHVzaF90bGJfZXhwb3J0LnBhdGNoCi0gdXBkYXRlZCB0byBlMTAwIDEuNS41Cgoq IFdlZCBGZWIgMjEgMjAwMSBEb3VnIExlZGZvcmQgPGRsZWRmb3JkQHJlZGhhdC5jb20+Ci0g dXBkYXRlIEp1c3RpbiBHaWJicycgYWljN3h4eCBkcml2ZXIgdG8gdmVyc2lvbiA2LjEuNAoK KiBXZWQgRmViIDIxIDIwMDEgQmlsbCBOb3R0aW5naGFtIDxub3R0aW5nQHJlZGhhdC5jb20+ Ci0gZXhwb3J0IGEgY291cGxlIG1vcmUgc3ltYm9scyBvbiBpYTY0Ci0gaW5jcmVhc2UgZGVm YXVsdCBzaXplIG9mIHN3aW90bGIgb24gaWE2NAoKKiBXZWQgRmViIDIxIDIwMDEgTWljaGFl bCBLLiBKb2huc29uIDxqb2huc29ubUByZWRoYXQuY29tPgotIGRpc2FibGUgM3dhcmUgZHJp dmVyIG9uIFNNUCB1bnRpbCBhIGJ1Z2ZpeCBpcyBmb3VuZAotIHVwZGF0ZWQgdG8gdHV4Mi0y LjQuMS1QNSB0byBmaXggZGNhY2hlIGJ1ZwoKKiBXZWQgRmViIDIxIDIwMDEgQXJqYW4gdmFu IGRlIFZlbiA8YXJqYW52QHJlZGhhdC5jb20+Ci0gTWVyZ2VkIGJ1Z2ZpeGVzIGZyb20gYWMy MDoKICAtIG5vbi1QTlAgQVdFMzIgZml4CiAgLSB1cGRhdGVzIHRvIHZhcmlvdXMgcGNtY2lh IG5ldHdvcmsgZHJpdmVycwotIEFkZGVkICJpZGVYPW5vZG1hIiBjb21tYW5kbGluZSBvcHRp b24KCiogVHVlIEZlYiAyMCAyMDAxIEFyamFuIHZhbiBkZSBWZW4gPGFyamFudkByZWRoYXQu Y29tPgotIFJlb3JkZXJlZCBzZXZlcmFsIHBhdGNoZXMgdG8gdGhlIHByb3BlciBzZWN0aW9u Ci0gTWVyZ2VkIHRoZSBmb2xsb3dpbmcgcGF0Y2hlcyBmcm9tIGFjMTctMTgtMTk6CiAgLSBq Z2FyemlrJ3MgbmV0d29yayBkcml2ZXIgY2xlYW51cHMKICAtIHJlaXNlcmZzIHRhaWxwYWNr aW5nIGRhdGFjb3JydXB0aW9uCiAgLSBzbWJmcyBvZmYtYnktb25lIGZpeGVzCiAgLSBVU0Ig Mi4wLCBVU0IgSHViIGRldmljZSBjbGFpbSByYWNlLCBVU0IgbmV0IHJlY292ZXJ5IAogIC0g U09fU05EVElNRU8gYnVncwotIEZpeGVkIENJUEUgb24gU01QIG1hY2hpbmVzICgjMjgzODYp Ci0gbmV3IHR1bGlwIGRyaXZlcgotIG5ldyB2ZXJzaW9uIG9mIHRoZSBMb29wIGZpeGVzIChB bCBWaXJvKQotIGJhY2tlZCBvdXQgdm0tcmViYWxhbmNlOyBiZSBjYXJlZnVsIHdpdGggZXh0 MgogIAoqIE1vbiBGZWIgMTkgMjAwMSBCaWxsIE5vdHRpbmdoYW0gPG5vdHRpbmdAcmVkaGF0 LmNvbT4KLSBtaW5vciBpYTY0IHR3ZWFrcwoKKiBNb24gRmViIDE5IDIwMDEgTWljaGFlbCBL LiBKb2huc29uIDxqb2huc29ubUByZWRoYXQuY29tPgotIHJlbW92ZWQgZHVwbGljYXRlIGtz eW1zIGV4cG9ydHMgZm9yIGFscGhhCi0gYWRkZWQgYnJva2VubXB0YWJsZSBwYXRjaCBmcm9t IEluZ28KLSBUdXJuZWQgb24gQ09ORklHX1VTQl9NT1VTRSBhbmQgQ09ORklHX1VTQl9LQkQg YmVjYXVzZSB0aGV5CiAgYXJlIG5lZWRlZCBhZnRlciBhbGwgd2l0aCBzb21lIGhhcmR3YXJl IGFuZCB0aGUgY29uZmxpY3RzIHdpdGggCiAgQ09ORklHX1VTQl9ISUQgYXJlIG5vbi1mYXRh bC4KCiogTW9uIEZlYiAxOSAyMDAxIEFyamFuIHZhbiBkZSBWZW4gPGFyamFudkByZWRoYXQu Y29tPgotIE1lcmdlZCB0dWxpcCBQTklDIHVwZGF0ZXMgZnJvbSAyLjQuMS1hYzE4Ci0gcmVt b3ZlZCBleHRyYSBEU0NDND1tIGNvbmZpZyBvcHRpb24KLSBjaGFuZ2VkIHRvIHRoZSBFVUk2 NCBmb3JtYXQgZm9yIElQdjYKLSBlbmxhcmdlZCBwcmludGsgYnVmZmVyICgjMjgyODgpCi0g dXBncmFkZWQgdG8gYWMxNiwgYnVtcCB0byAwLjEuMTEKCiogRnJpIEZlYiAxNiAyMDAxIEFy amFuIHZhbiBkZSBWZW4gPGFyamFudkByZWRoYXQuY29tPgotIGFjdHVhbGx5IGNvbW1pdGVk IE5GUyBwYXRjaAotIHVwZGF0ZWQgaW50ZWwgZTEwMDAgdG8gdmVyc2lvbiAzLjAuNwotIHJl dmVydGVkIHRoZSBrdWR6dSBjaGFuZ2UKLSBhY3R1YWxseSBidWlsZCB0aGUgSFA1MzAwIG1v ZHVsZQotIHByb3Zpc2lvbmFsIFdpbkNoaXAgcGF0Y2gKLSBtYWRlIHRoZSAyLjQga2VybmVs IGNvbmZsaWN0IHdpdGggaXNhcG5wdG9vbHMgYXMgdGhhdCBjb25mbGljdAogIGJyZWFrcyB0 aGUgYWN0dWFsIFBOUCBpbiB0aGUgMi40IGtlcm5lbC4KCgoqIFRodSBGZWIgMTUgMjAwMSBB cmphbiB2YW4gZGUgVmVuIDxhcmphbnZAcmVkaGF0LmNvbT4KLSBORlMgbWVtY21wIGJ1Zwot IGNoYW5nZWQgcmVxdWlyZXMga3VkenUgPj0gMC45MyB0byBjb25mbGljdHMga3VkenUgPD0g MC45MgotIG1hZGUgdGhlIGtlcm5lbCBjb25mbGljdCB3aXRoIHByb2dyYW0gdG9vIG9sZCBh Y2NvcmRpbmcKICB0byBEb2N1bWVudGF0aW9uL0NoYW5nZXMKCiogVGh1IEZlYiAxNSAyMDAx IEJpbGwgTm90dGluZ2hhbSA8bm90dGluZ0ByZWRoYXQuY29tPgotIGNoYW5nZSB3dmxhbl9j cyBDb25maWcuaW4gZGVzY3JpcHRpb24gdG8gc29tZXRoaW5nIG1vcmUgYXBwcm9wcmlhdGUK CiogVGh1IEZlYiAxNSAyMDAxIE1pY2hhZWwgSy4gSm9obnNvbiA8am9obnNvbm1AcmVkaGF0 LmNvbT4KLSBUdXJuZWQgb2ZmIENPTkZJR19VU0JfTU9VU0UgYW5kIENPTkZJR19VU0JfS0JE IGJlY2F1c2UgdGhleQogIGNvbmZsaWN0IHdpdGggdXNpbmcgQ09ORklHX1VTQl9ISUQgKGhv dHBsdWcgbG9hZHMgYm90aC4uLikKLSBidWlsZCB0b3NoaWJhIG1vZHVsZQoKKiBUaHUgRmVi IDE1IDIwMDEgS2Fyc3RlbiBIb3BwIDxrYXJzdGVuQHJlZGhhdC5kZT4KLSBzZWFyY2ggZm9y IGFsbCBMVU5zIG9uIENSMzUwMCBzaGFyZWQgU0NTSSBjb250cm9sbGVyCgoqIFdlZCBGZWIg MTQgMjAwMSBEb3VnIExlZGZvcmQgPGRsZWRmb3JkQHJlZGhhdC5jb20+Ci0gQWRkIEp1c3Rp biBHaWJicycgYWljN3h4eCBkcml2ZXIgdmVyc2lvbiA2LjEuMSBhcyBhaWM3eHh4X25ldwoK KiBXZWQgRmViIDE0IDIwMDEgTWljaGFlbCBLLiBKb2huc29uIDxqb2huc29ubUByZWRoYXQu Y29tPgotIGFkZGVkIHF1aWV0IHBhdGNoIHNvIHRoYXQgYXV0b3J1biBhbmQgbWFnaWNkZXYg ZG9uJ3QgbWFuZ2xlIGxvZ3MKCiogV2VkIEZlYiAxNCAyMDAxIEFyamFuIHZhbiBkZSBWZW4g PGFyamFudkByZWRoYXQuY29tPgotIE1hZGUgQ3lyaXggQ1BVJ3Mgd29yayBhZ2FpbgotIEFk ZGVkIGlkZXByb2JlIHBhdGNoIHRvIGF2b2lkIGhvdHByb2JlIGxvY2t1cHMKLSBmaXhlZCB0 dWxpcCB4aXJjb20gcGhhc2UgMgotIGlrZCAoa2RiKQotIHJlbW92ZSAqfiBmaWxlcyAoIzE4 NzUxKQotIGZpeCBwb2xsKCkgb24gdXNiIHByaW50ZXJzICgjMjY5MDkpCi0gZml4ZWQgYXJn dW1lbnQgcGFyc2luZyBmb3Igc3ltNjNjNDE2IGRyaXZlcgotIG1lcmdlZCBhYzEzIHBhdGNo IHRvIHByZXZlbnQgcGFycG9ydCBmcm9tIGNvcnJ1cHRpbmcgdGhlIHBjaSBkZXYgbGlzdAot IGZpeGVkIHNicGNkIChhYzEzKQotIGZpeGVkIHVzYmh1YiAoYWMxMywgbWlzc2luZyB1bmxv Y2tfa2VybmVsKQotIGZpeGVkIHZtYWxsb2MgcmFjZSAoYWMxMykKLSBwb3RlbnRpYWwgdWhj aSBzbGFiIGludGVyYWN0aW9uIGZpeAotIHNtYmZzIGZpeGVzIChhYzEzKQotIHRtcGZzIG5s aW5rIGZpeCBmb3IgcGVybCAoYWMxMykKLSBhcmNuZXQgaW5pdCBmaXhlcyAoYWMxMykKCgoq IFdlZCBGZWIgMTQgMjAwMSBNYXR0IFdpbHNvbiA8bXN3QHJlZGhhdC5jb20+Ci0gMC4xLjgK LSB0dXJuIG9mZiB0dXgKCiogVHVlIEZlYiAxMyAyMDAxIEJpbGwgTm90dGluZ2hhbSA8bm90 dGluZ0ByZWRoYXQuY29tPgotIGZpeCB0eXBvcyBpbiBkZWJ1Z2dpbmcgcGF0Y2gKCiogVHVl IEZlYiAxMyAyMDAxIE1pY2hhZWwgSy4gSm9obnNvbiA8am9obnNvbm1AcmVkaGF0LmNvbT4K LSB0dXJuZWQgb2ZmIENPTkZJR19CTEtfREVWX0FMSTE1WDMgZm9yIGFscGhhCi0gdXBkYXRl ZCB0byB0dXgyLTIuNC4xLUw0LCBtZXJnZSB3aXRoIGRlYnVnZ2luZyBhbmQgaGlnaG1lbSBw YXRjaGVzCi0gYWRkZWQgJWRlYnVnZ2luZyBtYWNybyBmb3IgdHVybmluZyBkZWJ1Z2dpbmcg b24gYW5kIG9mZgotIHVwZGF0ZWQgdG8gc2NzaS1tYXgtc2VjLTIKCiogVHVlIEZlYiAxMyAy MDAxIE1hdHQgV2lsc29uIDxtc3dAcmVkaGF0LmNvbT4KLSAwLjEuNgotIHR1cm5lZCBvZmYg Q09ORklHX05FVEZJTFRFUiBhbmQgQ09ORklHX0ZJTFRFUiBpbiBpMzg2IEJPT1QgY29uZmln Ci0gbW9kaWZpZWQgbGludXgtMi40LjEtaWE2NC0wMTAxMzEtMi5kaWZmIHRvIHVzZSB0aGUg bmV3IFBDSV9ST1VUSU5HX1RBQkxFCiAgc3RydWN0dXJlIGluIGFjcGljb25mLmMKCiogVHVl IEZlYiAxMyAyMDAxIEFyamFuIHZhbiBkZSBWZW4gPGFyamFudkByZWRoYXQuY29tPgotIE1h ZGUgInJlYWxtb2RlIHBvd2Vyb2ZmIiBhIGNvbW1hbmRsaW5lIG9wdGlvbiBkaXNhYmxlZCBi eSBkZWZhdWx0LgogIChiZWxpZXZlZCB0byBmaXggIzI2MjYxLCAjMjY3NjAsICMyNDE5OCwg IzIzMzIyKQotIGRpc2FibGVkIG5ldGZpbHRlciBhbmQgc3VjaCBpbiB0aGUgLUJPT1Qgb3B0 aW9uCi0gbWFkZSB0aGUga2VybmVsIHNsYWIgcGF0Y2ggYSBjb25maWctb3B0aW9uIGRpc2Fi bGVkIGZvciBCT09UCi0gU2VydmVyUkFJRCA0LjUwCgoqIFR1ZSBGZWIgMTMgMjAwMSBNYXR0 IFdpbHNvbiA8bXN3QHJlZGhhdC5jb20+Ci0gMC4xLjUKLSByZWdlbmVyYXRlZCBsaW51eC0y LjQuMS1pYTY0LTAxMDEzMS0yLmRpZmYgc28gaXQgd2lsbCBwYXRjaAotIHNwZWNpZnkgQVJD SD0gd2hlbiBidWlsZGluZyB0aGUgY29tbW9uIHNwYXJjL3NwYXJjNjQgaGVhZGVycwoKKiBN b24gRmViIDEyIDIwMDEgTWljaGFlbCBLLiBKb2huc29uIDxqb2huc29ubUByZWRoYXQuY29t PgotIGFkZGVkIEplbnMgQXhib2UncyBzY3NpLW1heC1zZWMtMSBhcyBsaW51eC0yLjQuMS1h eGJvZS1zY3NpLW1heC1zZWMucGF0Y2gKLSB1cGRhdGVkIHRvIG5ldyBhYWNyYWlkIGRyaXZl ciAoZGVwZW5kcyBvbiBKZW5zJ3MgcGF0Y2gpIHBsdXMgTWF0dCBEb21zY2gncyBmaXgKLSBh ZGRlZCBjaGFuZ2Vsb29wLWZpeGVzLTIgZnJvbSBBbAoKKiBNb24gRmViIDEyIDIwMDEgQXJq YW4gdmFuIGRlIFZlbiA8YXJqYW52QHJlZGhhdC5jb20+Ci0gdXBncmFkZWQgdG8gMi40LjEt YWMxMAotIG1lcmdlZCBuZXcgZTEwMC9lMTAwMCBkcml2ZXJzCgoqIFNhdCBGZWIgMTAgMjAw MSBNYXR0IFdpbHNvbiA8bXN3QHJlZGhhdC5jb20+Ci0gZGlzYWJsZSBicm9rZW4gc3BhcmNh dWRpbyBkcml2ZXJzIG9uIHN1bjRbY2RtXQotIGRpc2FibGUgcmVpc2VyZnMgb24gYWxsIHNw YXJjCi0gYWRkZWQgbGludXgtMi40LjFhYzgtbm9wY2kucGF0Y2ggdG8gY29ycmVjdCBidWls ZHMgaWYgbm90IHVzaW5nIENPTkZJR19QQ0kKLSBhZGRlZCBsaW51eC0yLjQuMWFjOC16YXBf cGFnZV9yYW5nZS5wYXRjaAoKKiBGcmkgRmViIDA5IDIwMDEgTWljaGFlbCBLLiBKb2huc29u IDxqb2huc29ubUByZWRoYXQuY29tPgotIHVwZGF0ZWQgdG8gQWwncyBsYXRlc3QgbG9vcCBm aXhlcwoKKiBGcmkgRmViIDkgMjAwMSBBcmphbiB2YW4gZGUgVmVuIDxhcmphbnZAcmVkaGF0 LmNvbT4KLSB1cGRhdGVkIHRvIDIuNC4xLWFjOCwgY2hhbmdlZCB2ZXJzaW9uIG51bWJlciB0 byAwLjEuMQotIGFkZGVkIEluZ28ncyBoaWdobWVtIHBhdGNoCi0gYWRkZWQgSVJDIG5ldGZp bHRlciBhZGRvbiBmb3IgRENDIG92ZXIgTkFUCi0gbmV3IG1lZ2FyYWlkIGRyaXZlciAoMS4x NGcpCi0gRml4IGZvciBidWcgMjY2OTYgKGNvbXBhcSB2cyBpcnEgMTMpCgoqIFRodSBGZWIg IDggMjAwMSBCaWxsIE5vdHRpbmdoYW0gPG5vdHRpbmdAcmVkaGF0LmNvbT4KLSBzeW5jIHVw IGlhNjQgd2l0aCBEYXZpZCBNb3NiZXJnZXIncyAyMDAxMDEzMSBwYXRjaAotIGFkZCB4ODYt Y29tcGF0aWJpbGl0eSBpYTY0IGJ1Z2ZpeCBwYXRjaCBmcm9tIERvbiBEdWdnZXIKCiogVGh1 IEZlYiAgOCAyMDAxIE1hdHQgV2lsc29uIDxtc3dAcmVkaGF0LmNvbT4KLSBhZGRlZCBsaW51 eC0yLjQuMS1pMm8tbG9ja3VwLnBhdGNoIGZvciBzb21lIGJ1cy9jYXJkIGNvbWJvcwoKKiBU aHUgRmViICA4IDIwMDEgQmlsbCBOb3R0aW5naGFtIDxub3R0aW5nQHJlZGhhdC5jb20+Ci0g ZG9uJ3QgYnVpbGRwcmVyZXEgZ2NjLTIuOTYtNzQgb24gaWE2NAoKKiBUaHUgRmViIDggMjAw MSBBcmphbiB2YW4gZGUgVmVuIDxhcmphbnZAcmVkaGF0LmNvbT4KLSB1cGRhdGVkIHRvIDIu NC4xLWFjNiwgY2hhbmdlZCB2ZXJzaW9uIG51bWJlcgotIG5ldyBicm9hZGNvbSBkcml2ZXIK LSBzZXJ2ZXJ3b3JrcyB3b3JrYXJvdW5kCgoqIFdlZCBGZWIgNyAyMDAxIEFyamFuIHZhbiBk ZSBWZW4gPGFyamFudkByZWRoYXQuY29tPgotIGNvcnJ1cHRpb24gZml4Ci0gbWVyZ2VkIHhp cmNvbV90dWxpcCBpbnRvIHJlYWwgdHVsaXAKLSByZXF1aXJlIGdjYyAyLjk2LTc0IG9yIGxh dGVyIGZvciBidWlsZGluZwotIG1lcmdlZCBhaWM3eHh4IGZyb20gSEVBRAotIGFkZGVkIERB Qzk2MCB2ZXJzaW9uIDIuNC4xMAoKKiBXZWQgRmViIDA3IDIwMDEgTWljaGFlbCBLLiBKb2hu c29uIDxqb2huc29ubUByZWRoYXQuY29tPgotIHVzZSBtb2R1bGVfdXBncmFkZSBmcm9tIGt1 ZHp1IHBhY2thZ2UsIHByZXJlcXVpcmUga3VkenUgPj0gMC45MwoKKiBXZWQgRmViICA3IDIw MDEgRG91ZyBMZWRmb3JkIDxkbGVkZm9yZEByZWRoYXQuY29tPgotIGZpeCB0aGUgYWljN3h4 eF9uZXctNi4xLjAgcGF0Y2ggOi0oCi0gZml4IHRoZSBhaWM3eHh4X25ldy02LjEuMCBwYXRj aCBhZ2FpbiA6LSgKCiogV2VkIEZlYiAgNyAyMDAxIE1hdHQgV2lsc29uIDxtc3dAcmVkaGF0 LmNvbT4KLSBhZGRlZCBsaW51eC0yLjQuMS1pMm8ucGF0Y2guICBUaGlzIHJlZ2lzdGVycyBp Mm8gYmxvY2sgZGV2aWNlcyBpbgogIC9wcm9jL3BhcnRpdGlvbnMgYW5kIGZpeGVzIHNvbWUg b3RoZXIgaTJvIGJ1Z3MuCgoqIFR1ZSBGZWIgMDYgMjAwMSBNaWNoYWVsIEsuIEpvaG5zb24g PGpvaG5zb25tQHJlZGhhdC5jb20+Ci0gcmVxdWlyZSBtb2R1dGlscyAyLjQuMiBvciBncmVh dGVyCgoqIFR1ZSBGZWIgIDYgMjAwMSBCZXJuaGFyZCBSb3NlbmtyYWVuemVyIDxiZXJvQHJl ZGhhdC5jb20+Ci0gVXBkYXRlIGRldmZzZCB0byAxLjMuMTEsIGZpeGVzIHNvbWUgZ2xpYmMg Mi4yIGlzc3VlcwoKKiBUdWUgRmViICA2IDIwMDEgRG91ZyBMZWRmb3JkIDxkbGVkZm9yZEBy ZWRoYXQuY29tPgotIHVwZGF0ZSB0aGUgYWljN3h4eCBkcml2ZXIgdG8gNS4yLjIKLSBtb3Zl IHRoZSBuZXcgQWRhcHRlYyBhaWM3eHh4IGRyaXZlciB0byBhaWM3eHh4X25ldwoKKiBUdWUg RmViICA2IDIwMDEgTWF0dCBXaWxzb24gPG1zd0ByZWRoYXQuY29tPgotIGFkZCBhIGJ1aWxk amVuc2VuIG1hY3JvLCBzZXQgaXQgdG8gMCAoYXMgamVuc2VuIHNlZW1zIGJyb2tlbikKCiog TW9uIEZlYiAgNSAyMDAxIE1hdHQgV2lsc29uIDxtc3dAcmVkaGF0LmNvbT4KLSAwLjk5LjIz Ci0gbWFrZSBqZW5zZW4gc3VicGFja2FnZSBvbiBhbHBoYSAoYWdhaW4sIHl1Y2spCgoqIE1v biBGZWIgIDUgMjAwMSBNYXR0IFdpbHNvbiA8bXN3QHJlZGhhdC5jb20+Ci0gMC45OS4yMgot IHR1cm4gb24gZW50ZXJwcmlzZSBrZXJuZWwKLSBzZXQgQ09ORklHX0ZJTFRFUiBhbmQgQ09O RklHX05FVEZJTFRFUiB0byBvZmYgaW4gaTM4NiBCT09UIGtlcm5lbAoKKiBNb24gRmViICA1 IDIwMDEgQXJqYW4gdmFuIGRlIFZlbiA8YXJqYW52QHJlZGhhdC5jb20+Ci0gR3JvdW5kd29y ayBmb3IgdGhlIDIuNC4xLWFjMiBtZXJnZQotIHR1cm5lZCBvZiBBQ1BJCiAKCiogTW9uIEZl YiA1IDIwMDEgQXJqYW4gdmFuIGRlIFZlbiA8YXJqYW52QHJlZGhhdC5jb20+Ci0gYWRkZWQg TWF0cm94IEc0NTAgcGF0Y2gKLSB1cGRhdGVkIGZyb20gMi40LjEtYWMxIHRvIDIuNC4xLWFj MgoKKiBGcmkgRmViICAyIDIwMDEgTWF0dCBXaWxzb24gPG1zd0ByZWRoYXQuY29tPgotIHR3 ZWFrZWQgdGhlIGFscGhhIGJvb3Qga2VybmVsIHRvIGJlIGEgbGl0dGxlIHNtYWxsZXIKLSBt b3ZlZCB0aGUgYWxwaGEgaGVhZGVyIHBhdGNoIHRvIGlmICUldHV4Ci0gdHVybiBvZmYgdHV4 Ci0gYWRkZWQgbGludXgtMi40LjAtYWxwaGEtaGVhZGVyLWNvbmZsaWN0LnBhdGNoCiAgKG5v IG1vcmUgTkZTIHJvb3QgaW5zdGFsbHMpCgoqIEZyaSBGZWIgMiAyMDAxIEFyamFuIHZhbiBk ZSBWZW4gPGFyamFudkByZWRoYXQuY29tPgotIFNvY2tldCBEb1MgZml4IGZyb20gQWxleGV5 L0RhdmVNCgoqIFRodSBGZWIgIDEgMjAwMSBCZXJuaGFyZCBSb3NlbmtyYWVuemVyIDxiZXJv QHJlZGhhdC5jb20+Ci0gQWRkIG1pc3NpbmcgL2V0Yy9tb2R1bGVzLmRldmZzIHRvIGRldmZz ZCBwYWNrYWdlCgoqIFRodSBGZWIgMDEgMjAwMSBNaWNoYWVsIEsuIEpvaG5zb24gPGpvaG5z b25tQHJlZGhhdC5jb20+Ci0gY2Npc3MgMi40LjIKLSBpbnRlZ3JhdGVkIHRlc3RlZCBsb29w IHBhdGNoZXMgZnJvbSBBbAoKKiBXZWQgSmFuIDMxIDIwMDEgRG91ZyBMZWRmb3JkIDxkbGVk Zm9yZEByZWRoYXQuY29tPgotIGFkZGVkIGEgZml4IGZvciBhIFBJSUkgc2VjdXJpdHkgaG9s ZQoKKiBXZWQgSmFuIDMxIDIwMDEgQmVuamFtaW4gTGFIYWlzZSA8YmNybEByZWRoYXQuY29t PgotIGFkZGVkIGxpbnV4LTIuNC4xLXphcF9wYWdlX3JhbmdlX2ZpeC5wYXRjaAoKKiBXZWQg SmFuIDMxIDIwMDEgTWljaGFlbCBLLiBKb2huc29uIDxqb2huc29ubUByZWRoYXQuY29tPgot IG5ldyB0dXggcGF0Y2ggdHV4Mi0yLjQuMC1maW5hbC1TOQoKKiBXZWQgSmFuIDMxIDIwMDEg QXJqYW4gdmFuIGRlIFZlbiA8YXJqYW52QHJlZGhhdC5jb20+Ci0gRml4ZWQzYzU3NSBkcml2 ZXIgbG9hZCB0eXBvLWJ1ZyAoMjM4MjApCi0gZml4ZWQgYXRobG9uIGJ1aWxkIGZvciB0dXgK LSBhZGRlZCBwcm92aXNpb25hbCBpZGUtZmxvcHB5IHBhdGNoCi0gc2lsZW5jZWQgdGhlIGlk ZS1jcyBkcml2ZXIgYSBiaXQgKHJlc291cmNlIG1hbmFnZW1lbnQgY29uZmxpY3QgYmV0d2Vl biBJREUKICBhbmQgUENNQ0lBIHN1YnN5c3RlbXMpCi0gbWFkZSBpYTY0IGFsbW9zdCBidWls ZAoKKiBXZWQgSmFuIDMxIDIwMDEgQmlsbCBOb3R0aW5naGFtIDxub3R0aW5nQHJlZGhhdC5j b20+Ci0gaW5jbHVkZSBpbmNsdWRlL3BjbWNpYSBpbiBrZXJuZWwtc291cmNlIHNvIHBjbWNp YSBkcml2ZXJzIGNhbiBidWlsZCAKCiogVHVlIEphbiAzMCAyMDAxIE1pY2hhZWwgSy4gSm9o bnNvbiA8am9obnNvbm1AcmVkaGF0LmNvbT4KLSB0ZW1wb3JhcmlseSBkaXNhYmxlZCBBbCdz IGxvb3BiYWNrIHBhdGNoZXMgd2hpbGUgaGUgZml4ZXMgdGhlbQoKKiBUdWUgSmFuIDMwIDIw MDEgQXJqYW4gdmFuIGRlIFZlbiA8YXJqYW52QHJlZGhhdC5jb20+Ci0gRml4ZWQgaTgyMzY1 IGRyaXZlciAoYnVnIDI0ODA0KQotIGFkZGVkICJhdGhsb24iIGFyY2hpdGVjdHVyZQotIFBo YXNlIDEgb2YgaWRlLWNzIGZpeAotIG1hZXN0cm8zIHBhdGNoIGZyb20gWmFjaCBCcm93bgoK KiBNb24gSmFuIDI5IDIwMDEgRG91ZyBMZWRmb3JkIDxkbGVkZm9yZEByZWRoYXQuY29tPgot IFVwZGF0ZWQgYWljN3h4eCBkcml2ZXIgdG8gNi4xLjAKLSBDb3JyZWN0ZWQgYSBidWcgaW4g dGhlIHJoY29uZmlnLmggZmlsZSB3ZSBpbnN0YWxsCi0gQ29ycmVjdGVkIGEgYnVnIGluIHRo ZSBidWlsZCBwcm9jZXNzIGluIHRoZSBzcGVjIGZpbGUKCiogTW9uIEphbiAyOSAyMDAxIE1p Y2hhZWwgSy4gSm9obnNvbiA8am9obnNvbm1AcmVkaGF0LmNvbT4KLSBuZXcgdHV4MiBwYXRj aCB0dXgyLTIuNC4wLWZpbmFsLVI5Ci0gaW50ZWdyYXRlZCBBbCdzIGxvb3BiYWNrIGRldmlj ZSBmaXhlcwotIHNpbmNlIGVudGVycHJpc2Uga2VybmVsIGhhcyBvbmx5IGhpZ2htZW0tNjRH QiBzdXBwb3J0LCBsaW1pdCB0byA+PSBQSUlJCgoqIFN1biBKYW4gMjggMjAwMSBNaWNoYWVs IEsuIEpvaG5zb24gPGpvaG5zb25tQHJlZGhhdC5jb20+Ci0gaW50ZWdyYXRlZCBMaW51cydz IHNoYXJlZCBtZW1vcnkgc3dhcCBwYXRjaAotIGludGVncmF0ZWQgQW5kcmV5J3MgMS4zNiBl ZXBybzEwMCBkcml2ZXIKLSBpbnRlZ3JhdGVkIGJsb2NrIHNjaGVkdWxlciBmaXggZnJvbSBw cmUxMQotIHVwZGF0ZWQgdG8gbmV3IHR1eDIgcGF0Y2gsIG5vdyBtb2R1bGFyCgoqIEZyaSBK YW4gMjYgMjAwMSBNaWNoYWVsIEsuIEpvaG5zb24gPGpvaG5zb25tQHJlZGhhdC5jb20+Ci0g YWRkZWQgSmVucyBBeGJvZSdzIGxvb3AgcGF0Y2ggKGRpc2FibGVkLCBBbCBmaXhpbmcgaXQg YW5kIGNoYW5nZWxvb3AgYm90aCkKCiogRnJpIEphbiAyNiAyMDAxIEFyamFuIHZhbiBkZSBW ZW4gPGFyamFudkByZWRoYXQuY29tPgotIEZpeGVkIHBhcnBvcnRfY3MgdW5yZXNvbHZlZCBz eW1ib2wKLSByZXZlcnRlZCBuZXcgd3ZsYW4gcG9ydCwgdGhlIG9sZCBvbmUgX2RpZF8gd29y awoKKiBGcmkgSmFuIDI2IDIwMDEgRG91ZyBMZWRmb3JkIDxkbGVkZm9yZEByZWRoYXQuY29t PgotIGFkZGVkIHRoZSB4bW0gcGF0Y2ggdG8ga2VlcCB0aGUgc3lzdGVtIGZyb20gdG91Y2hp bmcgbm9uLWV4aXN0ZW50IG14Y3NyCiAgcmVnaXN0ZXJzCi0gdmVyaWZpZWQgdGhhdCB0aGUg dHdvIGxpbnV4LW1lcmdlLSouYXdrIHNjcmlwdHMgZG8gaW5kZWVkIHVzZSB0aGUgcmlnaHQK ICBzeW1ib2wgbmFtZXMgc28gdGhhdCB0aGV5IHNob3VsZCB3b3JrIHByb3Blcmx5CgoqIFRo dSBKYW4gMjUgMjAwMSBCaWxsIE5vdHRpbmdoYW0gPG5vdHRpbmdAcmVkaGF0LmNvbT4KLSBy ZW1vdmUgL2xpYi9tb2R1bGVzLzx3aGF0ZXZlcj4vbW9kdWxlcy5nZW5lcmljX3N0cmluZyBh cyB3ZWxsICgjMjQ5OTEpCgoqIFRodSBKYW4gMjUgMjAwMSBNaWNoYWVsIEsuIEpvaG5zb24g PGpvaG5zb25tQHJlZGhhdC5jb20+Ci0gaW50ZWdyYXRlZCBuZXcgdHV4MiBwYXRjaAotIHJl cXVpcmUgbmV3IG1raW5pdHJkIGZvciBSQUlEIG1vZHVsZXMKCiogVGh1IEphbiAyNSAyMDAx IEFyamFuIHZhbiBkZSBWZW4gPGFyamFudkByZWRoYXQuY29tPgotIEFkZGVkIHBhcnBvcnRf Y3MgcG9ydCBmcm9tIHBjbWNpYS1jcyBwYWNrYWdlCi0gYmFja2VkIG91dCB0byBhYzEwCi0g bmV3IHd2bGFuIHBvcnQsIHRoaXMgb25lIGlzIHJlcG9ydGVkIHRvIHdvcmsgZXZlbgoKKiBX ZWQgSmFuIDI0IDIwMDEgRXJpayBUcm9hbiA8ZXd0QHJlZGhhdC5jb20+Ci0gdXBkYXRlZCBS QUlEX0FVVE9SVU4gcGF0Y2gKCiogV2VkIEphbiAyNCAyMDAxIEFyamFuIHZhbiBkZSBWZW4g PGFyamFudkByZWRoYXQuY29tPgotIEZpeCBmb3IgYnVnIDI0Njk4IChpbmNvcnJlY3QgImJ1 aWxkIiBsaW5rKQotIFVwZGF0ZWQgdG8gMi40LjAtYWMxMSAoc3RpbGwgcHJlOSBiYXNlZCks IGJ1bXBlZCB2ZXJzaW9uIHRvIDAuOTkuMTEKLSBhZGRlZCBwYXRjaCB0byBmaXggbW9zdCB3 YXJuaW5ncyBwZW9wbGUgd2lsbCBzZWUKLSBjaGFuZ2VzIHd2bGFuLm8gdG8gd3ZsYW5fY3Mu bwoKKiBUdWUgSmFuIDIzIDIwMDEgTWF0dCBXaWxzb24gPG1zd0ByZWRoYXQuY29tPgotIDIu NC4wLTAuOTkuMTAsIGFjMTAgYmFzZQotIHJlYnVpbGQgd2l0aCBtb2R1dGlscyAyLjQuMiBp biBwbGFjZQoKKiBUdWUgSmFuIDIzIDIwMDEgTWF0dCBXaWxzb24gPG1zd0ByZWRoYXQuY29t PgotIGFkZGVkIFJBSURfQVVUT1JVTiBpb2N0bCB0byByYWlkIGRyaXZlciBmcm9tIEluZ28K LSBmaXhlZCB0aGUgYXV0b3J1biBwYXRjaAoKKiBUdWUgSmFuIDIzIDIwMDEgQmVuamFtaW4g TGFIYWlzZSA8YmNybEByZWRoYXQuY29tPgotIElERSBETUEgYnkgZGVmYXVsdCBlbmFibGVk Ci0gYWRkIGxtX3NlbnNvcnMgYnVpbHQgYXMgbW9kdWxlcwotIGVuYWJsZSByZWlzZXJmcwoK KiBUdWUgSmFuIDIzIDIwMDEgQXJqYW4gdmFuIGRlIFZlbiA8YXJqYW52QHJlZGhhdC5jb20+ Ci0gYmxhY2tsaXN0ZWQgSUJNIGRlc2tzdGFyIGRpc2tzIGZvciBVRE1BIG9uIGhwdDM2NiBj b250cm9sbGVycyAoZHdtdzIpCi0gYWRkZWQgUkFJRDUgY29ycnVwdGlvbiBmaXggZnJvbSAy LjQuMS1wcmUxMAotIGFkZGVkIGZpeCBmb3IgRkQgcHJvYmxlbSBmcm9tIDIuNC4xLXByZTEw Ci0gYWRkZWQgREFDOTYwIGZpeCBmcm9tIDIuNC4xLXByZTEwIChKZW5zIEF4Ym9lJ3MgcGF0 Y2gpCi0gYWRkZWQgZml4IHdyb25nIF9faW5pdCBpbiBpby1hcGljLmMgZnJvbSAyLjQuMS1w cmUxMAotIHJlbW92ZWQgYnJvYWRjb20gZHJpdmVyIHRlbXBvcmFyaWx5CgoqIE1vbiBKYW4g MjIgMjAwMSBNYXR0IFdpbHNvbiA8bXN3QHJlZGhhdC5jb20+Ci0gdW5jb21tZW50IHJtIC1y ZiAkUlBNX0JVSUxEX1JPT1QgZnJvbSAlY2xlYW4KLSBtb2RpZmllZCB0aGUgZHJpdmVycy91 c2IvdWhjaS5jIHBhdGNoIG9mIHRoZSBpYTY0IHBhdGNoIHRvIHBhdGNoIGFnYWluc3QgYWMx MAotIHJlc3luY2VkIGtlcm5lbC0yLjQuMC1pMzg2LUJPT1QuY29uZmlnIHdpdGggYXZhaWxh YmxlIG9wdGlvbnMKLSBhZGRlZCBsaW51eC0yLjQuMC10Z2FmYi11bnJlZ2lzdGVyLWZyYW1l YnVmZmVyLnBhdGNoIHRvIHBhc3MgY29ycmVjdAogIHZhbHVlIGludG8gdW5yZWdpc3Rlcl9m cmFtZWJ1ZmZlcgotIHVwZGF0ZWQga2VybmVsLTIuNC4wLWlhNjQtc21wLmNvbmZpZyBhbmQg a2VybmVsLTIuNC4wLWlhNjQuY29uZmlnIGZvcgogIGF2YWlsYWJsZSBvcHRpb25zCgoqIE1v biBKYW4gMjIgMjAwMSBCZW5qYW1pbiBMYUhhaXNlIDxiY3JsQHJlZGhhdC5jb20+Ci0gYWRk ZWQgbGludXgtMi40LjAtc3lzY3RsLnBhdGNoCi0gYWRkZWQgbGludXgtMi40LjAtbWFwX3Vz ZXJfa2lvYnVmLWZpeC5wYXRjaAoKKiBNb24gSmFuIDIyIDIwMDEgTWF0dCBXaWxzb24gPG1z d0ByZWRoYXQuY29tPgotIGluY3JlYXNlZCByYW1kaXNrIHNpemUgb2Yga2VybmVsLUJPT1Qg ZnJvbSA0MDk2IHRvIDQ2MDgKCiogTW9uIEphbiAyMiAyMDAxIEFyamFuIHZhbiBkZSBWZW4g PGFyamFudkByZWRoYXQuY29tPgotIHVwZGF0ZWQgdG8gYWMxMCwgd2hpY2ggYWxyZWFkeSBj b250YWlucyB0aGUgd2FpdHBpZCBwYXRjaAoKKiBNb24gSmFuIDIyIDIwMDEgQmVuamFtaW4g TGFIYWlzZSA8YmNybEByZWRoYXQuY29tPgotIGFkZGVkIGxpbnV4LTIuNC4wLXdhaXRwaWQu cGF0Y2ggdG8gZml4IGluaXQvY29udGV4dGQgU0lHQ0hMRCByYWNlCgoqIE1vbiBKYW4gMjIg MjAwMSBBcmphbiB2YW4gZGUgVmVuIDxhcmphbnZAcmVkaGF0LmNvbT4KLSBhZGRlZCBmaXJz dCBkcmFmdCBvZiB3dmxhbiBkcml2ZXIKLSB0b3VjaGVkIHRoZSBpZGUtY3MgdGhpbmcuIFBs ZWFzZSB0ZXN0CgoqIE1vbiBKYW4gMjIgMjAwMSBNaWNoYWVsIEsuIEpvaG5zb24gPGpvaG5z b25tQHJlZGhhdC5jb20+Ci0gdHVybmVkIG9uIGUxMDAwIGRyaXZlciBhZ2FpbgotIGUxMDAg dXBkYXRlZCB0byAxLjUuMCBhcyBsaW51eC0yLjQuMC1lMTAwLnBhdGNoCgoqIE1vbiBKYW4g MjIgMjAwMSBFcmlrIFRyb2FuIDxld3RAcmVkaGF0LmNvbT4KLSBzd2l0Y2hlZCBpZGUtY2Qg YmFjayB0byBhIG1vZHVsZSBpbiBhbGwgeDg2IGtlcm5lbHMKCiogRnJpIEphbiAxOSAyMDAx IEFyamFuIHZhbiBkZSBWZW4gPGFyamFudkByZWRoYXQuY29tPgotIGFkZGVkIEJyb2FkY29t IDU3MDAgZHJpdmVyCi0gYWRkZWQgcGF0Y2ggdG8gd29ya2Fyb3VuZCBncm9zcyBtaXN1c2Ug b2YgQVNTRVJUIGluIElyREEKCiogRnJpIEphbiAxOSAyMDAxIE1pY2hhZWwgSy4gSm9obnNv biA8am9obnNvbm1AcmVkaGF0LmNvbT4KLSBBZGRlZCBhYWNyYWlkIGRyaXZlciAoYnJva2Vu IHNvIGFkZGVkIGFzIGEgbm9uLWJ1aWxkaW5nIHBsYWNlaG9sZGVyKQotIFR1cm4gb2ZmIG1v ZHVsZXMgb24gQWxwaGEgdGhhdCBhcmUgbm90IGJ1aWxkaW5nIGNvcnJlY3RseQotIFR1cm4g b2ZmIGUxMDAgZHJpdmVyIG9uIElBNjQgYmVjYXVzZSBpdCBkb2Vzbid0IGJ1aWxkIHRoZXJl Ci0gQWRkZWQgbGludXgtMi40LjAtaWVlZTEzOTQtcXVldWVmaXgucGF0Y2ggZm9yIHRhc2sg cXVldWUgY2hhbmdlcwotIEFkZGVkIGxpbnV4LTIuNC4wLTN4OTB4LnBhdGNoIDNjOTB4IGRy aXZlciBmcm9tIDNjb20KCiogRnJpIEphbiAxOSAyMDAxIEFyamFuIHZhbiBkZSBWZW4gPGFy amFudkByZWRoYXQuY29tPgotIHVwZGF0ZWQgbWVnYXJhaWQgdG8gMS4xNGIKLSBtYWRlIHRo ZSBub24tc21wIGtlcm5lbCBwcm92aWRlICJrZXJuZWwgPSAyLjQiCi0gbWFkZSB0aGUgc21w IGtlcm5lbHMgcHJvdmlkZSAibW9kdWxlLWluZm8iCgoqIFRodSBKYW4gMTggMjAwMSBQaGls aXAgQ29wZWxhbmQgPGJyeWNlQHJlZGhhdC5jb20+Ci0gYWRkZWQgaW4gdGhlIFNBUkQgcGF0 Y2gKCiogVGh1IEphbiAxOCAyMDAxIEVyaWsgVHJvYW4gPGV3dEByZWRoYXQuY29tPgotIHN3 aXRjaGVkIGlkZWZsb3BweSB0byBidWlsZCBpbgotIHVwZGF0ZWQgZTEwMCwgZTEwMDAgZHJp dmVyCi0gZW5hYmxlZCBuYXRzZW1pIG1vZHVsZSBpbiBpMzg2IEJPT1Qga2VybmVsCgoqIFRo dSBKYW4gMTggMjAwMSBNaWNoYWVsIEsuIEpvaG5zb24gPGpvaG5zb25tQHJlZGhhdC5jb20+ Ci0gbmV3IHR1eCBwYXRjaAotIHR1cm5lZCBvbiBDT05GSUdfSVBfTkZfSVJDIGFzIG1vZHVs ZQoKKiBXZWQgSmFuIDE3IDIwMDEgTWF0dCBXaWxzb24gPG1zd0ByZWRoYXQuY29tPgotIGZp eGVkIHR5cG8gaW4gbGludXgtMi40LjAtYWljN3h4eC02LjAuOEJFVEEucGF0Y2ggZm9yICFp Mzg2ICFhbHBoYQoKKiBXZWQgSmFuIDE3IDIwMDEgQmlsbCBOb3R0aW5naGFtIDxub3R0aW5n QHJlZGhhdC5jb20+Ci0gdXBkYXRlIHRvIGNpcGUtMS40LjUsIG1ha2UgaXQgb25lIHBhdGNo CgoqIFdlZCBKYW4gMTcgMjAwMSBBcmphbiB2YW4gZGUgVmVuIDxhcmphbnZAcmVkaGF0LmNv bT4KLSB1cGRhdGUgdG8gMi40LjAtYWM5CgoqIFR1ZSBKYW4gMTYgMjAwMSBCaWxsIE5vdHRp bmdoYW0gPG5vdHRpbmdAcmVkaGF0LmNvbT4KLSBmaXggdGhlIGFpYzd4eHggcGF0Y2hlcyB0 byBub3QgcGF0Y2ggYmFja3VwIGZpbGVzCi0gZml4IHRoZSBjaXBlIG1ha2VmaWxlIHNvIHRo YXQgaXQgYnVpbGRzCgoqIE1vbiBKYW4gMTUgMjAwMSBEb3VnIExlZGZvcmQgPGRsZWRmb3Jk QHJlZGhhdC5jb20+Ci0gbW92ZSB0aGUgY3VycmVudCBhaWM3eHh4IGRyaXZlciBhaWM3eHh4 X29sZAotIGFkZCBKdXN0aW4gR2liYnMnIG5ldyBhaWM3eHh4IGRyaXZlcgotIGFkZCBhIGZp eCBzbyB0aGF0IHRoZSBjczQyODEgbW9kdWxlIHdpbGwgYnVpbGQKCiogRnJpIEphbiAxMiAy MDAxIEthcnN0ZW4gSG9wcCA8a2Fyc3RlbkByZWRoYXQuZGU+Ci0gYWRkZWQgc3RhcmZpcmUg bW1pbyBwYXRjaCB0byBhbGxvdyByZWxvYWQgb2YgdGhpcyBtb2R1bGUKCiogRnJpIEphbiAx MiAyMDAxIFBoaWxpcCBDb3BlbGFuZCA8YnJ5Y2VAcmVkaGF0LmNvbT4KLSBBZGRlZCBpbiBo b29rcyBmb3IgdGhlIGlwdnMgMC4xLjIgcHJvZHVjdGlvbiBraXRzIHRvIGtzeW1zLmMKLSBB ZGRlZCBpbiBwYXRjaDI1MCB0byB0aGUgc3BlYyBmaWxlIHJlZmVyYW5jaW5nIGxpbnV4LTIu NC4wLWlwdnMucGF0Y2gKLSBhZGRlZCBzdWJkaXIgaXB2cyBpbiBrZXJuZWwgdHJlZSB3aGlj aCBob2xkcyBpcHZzIG1vZHVsZSBjb2RlCi0gYWM0IHR5cG8gZml4CgoqIEZyaSBKYW4gMTIg MjAwMSBNaWNoYWVsIEsuIEpvaG5zb24gPGpvaG5zb25tQHJlZGhhdC5jb20+Ci0gbWFkZSBi dWlsZCBzeW1saW5rIHJlbGF0aXZlCi0gcWxhMXgxNjBzcmMtMy4yM0JldGEgYXMgbGludXgt Mi40LjAtcWxhMTI4MC5wYXRjaAotIG1ha2Ugb2xkY29uZmlnX25vbmludCBzbyB0aGF0IGJ1 aWxkcyByZWxpYWJseSBmYWlsIHdoZW4gY29uZmlnIGZpbGVzIG5lZWQgbW9kcwoKKiBUaHUg SmFuIDExIDIwMDEgQmlsbCBOb3R0aW5naGFtIDxub3R0aW5nQHJlZGhhdC5jb20+Ci0gdHVy biBvZmYgQ09ORklHX0RJU0FCTEVfVkhQVCBvbiBpYTY0LCBpdCdzIGJyb2tlbgotIGZpeCBj czQyODEgbWFrZWZpbGUgb29wcwotIGFkZCBuZXcgcGF0Y2ggdG8gcG9zc2libHkgZml4IGJy b2tlbiBDT05GSUdfRElTQUJMRV9WSFBUCgoqIFRodSBKYW4gMTEgMjAwMSBLYXJzdGVuIEhv cHAgPGthcnN0ZW5AcmVkaGF0LmRlPgotIG1vdmVkIGUxMDAwLTIuNS4xMS5wYXRjaCBhbmQg dGhlIHVwZGF0ZSB0byAyLjUuMTQgaW50byBvbmUgcGF0Y2gKCiogVGh1IEphbiAxMSAyMDAx IE1pY2hhZWwgSy4gSm9obnNvbiA8am9obnNvbm1AcmVkaGF0LmNvbT4KLSBNb3ZlZCBiYWNr IHRvIHN0YXRpYyBJREUgZm9yIG5vdyBiZWNhdXNlIGEgY291cGxlIG1hY2hpbmVzIGhhZCBw cm9ibGVtcy4KLSBxbGExeDE2MHNyYy0zLjIyQmV0YSBhcyBsaW51eC0yLjQuMC1xbGExMjgw LnBhdGNoCi0gbWVnYXJhaWQgMS4xM3MgYXMgbGludXgtMi40LjAtbWVnYXJhaWQucGF0Y2gK CiogV2VkIEphbiAxMCAyMDAxIE1hdHQgV2lsc29uIDxtc3dAcmVkaGF0LmNvbT4KLSBhZGQg ZnJlZV9kbWEgYW5kIHJlcXVlc3RfZG1hIHByb3RvdHlwZSBpbiBhc20taWE2NC9kbWEuaCBh cwogIFBhdGNoNTg6IGxpbnV4LTIuNC4wLWlhNjQtZnJlZV9kbWEucGF0Y2gKLSByZW1vdmUg UGF0Y2g1NDogbGludXgtMi40LjAtdGVzdDExLWlhNjQta3N5bXMucGF0Y2gKLSByZW1vdmUg UGF0Y2g1NTogbGludXgtMi40LjAtdGVzdDEyLWlhNjQtaWRlc3ltLnBhdGNoCgoqIFdlZCBK YW4gMTAgMjAwMSBCaWxsIE5vdHRpbmdoYW0gPG5vdHRpbmdAcmVkaGF0LmNvbT4KLSBzeW5j IGlhNjQgKDAxMDEwOSBwYXRjaCkKCiogV2VkIEphbiAxMCAyMDAxIE1hdHQgV2lsc29uIDxt c3dAcmVkaGF0LmNvbT4KLSBtZXJnZWQgYWxwaGEgLmNvbmZpZyBmaWxlcyBiYWNrIHRvIHRo ZSB3YXkgdGhleSBuZWVkIHRvIGJlCi0gdHVybiBhbHBoYSBiYWNrIG9uCgoqIFdlZCBKYW4g MTAgMjAwMSBNaWNoYWVsIEsuIEpvaG5zb24gPGpvaG5zb25tQHJlZGhhdC5jb20+Ci0gdXBk YXRlIHRvIDIuNC4wLWFjNAotIHBjbWNpYSBtb3ZlZCB0byBpdHMgb3duIHBhY2thZ2UKLSB1 cGRhdGUgdG8gbmV3IHR1eCBwYXRjaAotIGU4MjAgcmVwb3J0aW5nIGZyb20gQXJqYW4KLSBB bmRpJ3MgUkFJRDUgeG9yIGZpeAotIEluZ28ncyBBdGhsb24gQVBJQyBmaXgKCiogTW9uIEph biAgOCAyMDAxIEJpbGwgTm90dGluZ2hhbSA8bm90dGluZ0ByZWRoYXQuY29tPgotIHJlbW92 ZSBrc3ltb29wcy9rZXJuZWwtdXRpbHMKCiogRnJpIERlYyAyOSAyMDAwIEJpbGwgTm90dGlu Z2hhbSA8bm90dGluZ0ByZWRoYXQuY29tPgotIGZpeCB1cCBwcmVyZXFzCgoqIFdlZCBEZWMg MjcgMjAwMCBCaWxsIE5vdHRpbmdoYW0gPG5vdHRpbmdAcmVkaGF0LmNvbT4KLSBzb21ldGhp bmcgaXMgaG9ycmlibHksIGhvcnJpYmx5IHdyb25nIHdpdGggbW9kdWxhciBTQ1NJIG9uIGlh NjQ7IHR1cm4gaXQgb2ZmCi0gcmVuYW1lIHNvdXJjZSBSUE0gYmFjayB0byAna2VybmVsJwoK KiBGcmkgRGVjIDIyIDIwMDAgRXJpayBUcm9hbiA8ZXd0QHJlZGhhdC5jb20+Ci0gdXBkYXRl ZCBwY21jaWEgY29uZmlnIGZpbGUgZm9yIDIuNCBjYXJkYnVzIHN1cHBvcnQKCiogVGh1IERl YyAyMSAyMDAwIEVyaWsgVHJvYW4gPGV3dEByZWRoYXQuY29tPgotIHR1cm5lZCBIT1RQTFVH IG9uIGZvciBpMzg2IEJPT1Qga2VybmVsIChQQ01DSUEgZG9lc24ndCBidWlsZCB3L28gaXQp CgoqIFR1ZSBEZWMgMTkgMjAwMCBNaWNoYWVsIEsuIEpvaG5zb24gPGpvaG5zb25tQHJlZGhh dC5jb20+Ci0gQWRkZWQgbGludXgtMi40LjAtdGVzdDExLXZpZGZhaWwucGF0Y2ggYW5kIGVu YWJsZWQgaXQgZm9yIHRoZSB4ODYgQk9PVCBrZXJuZWwKLSBNb3JlIFVTQiBzdXBwb3J0IGlu IHg4NiBCT09UIGtlcm5lbAotIFJlcXVpcmUgbmV3IG1raW5pdHJkIGZvciBJREUgbW9kdWxl cwotIFNDU0kgZW50aXJlbHkgbW9kdWxhcgoKKiBGcmkgRGVjIDE1IDIwMDAgQmlsbCBOb3R0 aW5naGFtIDxub3R0aW5nQHJlZGhhdC5jb20+Ci0gYWRkIHBhdGNoIHRvIGZpeCB1bnJlc29s dmVkIHN5bWJvbCBvbiBpYTY0IGluIGlkZS1wcm9iZS1tb2QKCiogV2VkIERlYyAxMyAyMDAw IE1pY2hhZWwgSy4gSm9obnNvbiA8am9obnNvbm1AcmVkaGF0LmNvbT4KLSBDT05GSUdfUEFS UE9SVF9QQ19GSUZPIG9mZiwgYmFkIGRlZmF1bHQgYXQgdGhpcyB0aW1lCgoqIFR1ZSBEZWMg MTIgMjAwMCBNYXR0IFdpbHNvbiA8bXN3QHJlZGhhdC5jb20+Ci0gc3dpdGNoIHRvIHVuLVRV WGlmaWVkIGtlcm5lbAotIHR1cm4gb24gZnJhbWVidWZmZXIgaW4gdGhlIEJPT1Qga2VybmVs CgoqIFR1ZSBEZWMgMTIgMjAwMCBNaWNoYWVsIEsuIEpvaG5zb24gPGpvaG5zb25tQHJlZGhh dC5jb20+Ci0gTmV3IFJDIG9mIFRVWC0xLjAxIHBhdGNoCgoqIEZyaSBEZWMgMDggMjAwMCBN aWNoYWVsIEsuIEpvaG5zb24gPGpvaG5zb25tQHJlZGhhdC5jb20+Ci0gQ09ORklHX0hBUFBZ TUVBTCB0dXJuZWQgb24gZm9yIGFsbCBhcmNoaXRlY3R1cmVzCgoqIFRodSBEZWMgIDcgMjAw MCBCaWxsIE5vdHRpbmdoYW0gPG5vdHRpbmdAcmVkaGF0LmNvbT4KLSB1cGRhdGUgaWE2NCBw YXRjaCB0byB0aGUgMTIwNiB2ZXJzaW9uCi0gdXBkYXRlIGUxMDAsIGUxMDAwIGRyaXZlcnMK CiogV2VkIERlYyAwNiAyMDAwIE1pY2hhZWwgSy4gSm9obnNvbiA8am9obnNvbm1AcmVkaGF0 LmNvbT4KLSBSZXF1aXJlIGZpbGV1dGlscyBmb3IgbG4gdXNlIGluICVwb3N0IHNjcmlwdHMK LSBNb2R1bGFyIElERQoKKiBUdWUgRGVjIDA1IDIwMDAgTWljaGFlbCBLLiBKb2huc29uIDxq b2huc29ubUByZWRoYXQuY29tPgotIFJlbW92ZSBhcGExNDgwIGRyaXZlciB0ZW1wb3Jhcmls eSBmb3IgVFVYIGJ1aWxkCgoqIE1vbiBEZWMgIDQgMjAwMCBCaWxsIE5vdHRpbmdoYW0gPG5v dHRpbmdAcmVkaGF0LmNvbT4KLSBhZGQgcGF0Y2ggdG8gZml4IFNXSU9UTEIgZnJvbSBBc2l0 IE1hbGxpY2sKCiogU3VuIERlYyAgMyAyMDAwIEJpbGwgTm90dGluZ2hhbSA8bm90dGluZ0By ZWRoYXQuY29tPgotIHR1cm4gb24gdXNiLXVoY2kgYXMgd2VsbCBhcyB1aGNpCi0gdXBkYXRl IG1lZ2FyYWlkIHRvIDEuMTNiZXRhCgoqIFRodSBOb3YgMzAgMjAwMCBNaWNoYWVsIEsuIEpv aG5zb24gPGpvaG5zb25tQHJlZGhhdC5jb20+Ci0gVFVYIDEuMDEgUkMKCiogV2VkIE5vdiAy OSAyMDAwIEJpbGwgTm90dGluZ2hhbSA8bm90dGluZ0ByZWRoYXQuY29tPgotIGZpeCBpYTY0 IHNlbWFwaG9yZSBzeW1ib2wgcHJvYmxlbXMKLSBmaXggY2lwZSBzeW1ib2wgcHJvYmxlbXMK CiogV2VkIE5vdiAyOSAyMDAwIE1pY2hhZWwgSy4gSm9obnNvbiA8am9obnNvbm1AcmVkaGF0 LmNvbT4KLSBUVVggMS4wMSBpbnRlZ3JhdGVkIHdpdGggdGVzdDExCgoqIFR1ZSBOb3YgMjgg MjAwMCBCaWxsIE5vdHRpbmdoYW0gPG5vdHRpbmdAcmVkaGF0LmNvbT4KLSBtYWtlIGlhNjQg cGF0Y2ggcGF0Y2ggY2xlYW5seSB3aXRoIHRlc3QxMQoKKiBNb24gTm92IDI3IDIwMDAgQmls bCBOb3R0aW5naGFtIDxub3R0aW5nQHJlZGhhdC5jb20+Ci0gcmVtb3ZlIGFsbCBtb2R1bGVz Ljxmb28+bWFwIGZpbGVzIG9uIHBhY2thZ2UgcmVtb3ZhbAoKKiBGcmkgTm92IDI0IDIwMDAg QmlsbCBOb3R0aW5naGFtIDxub3R0aW5nQHJlZGhhdC5jb20+Ci0gYWRkIHBhdGNoIHRvIGZp eCBGQVQzMiwgcGF0Y2ggZm9yIGFsaWdubWVudCBvZiB1bndpbmQgZGF0YQoKKiBNb24gTm92 IDIwIDIwMDAgQmlsbCBOb3R0aW5naGFtIDxub3R0aW5nQHJlZGhhdC5jb20+Ci0gbWFrZSBu ZnMgYSBtb2R1bGUKCiogVGh1IE5vdiAxNiAyMDAwIEJpbGwgTm90dGluZ2hhbSA8bm90dGlu Z0ByZWRoYXQuY29tPgotIG5ldyBpYTY0IHBhdGNoIGZyb20gRGF2aWQgTW9zYmVyZ2VyCi0g bWFrZSBwcHAgYSBtb2R1bGUKLSBhbGxvdyBnbGliYyB0byBidWlsZCBmb3IgdGhlIG1vbWVu dAoKKiBGcmkgTm92IDEwIDIwMDAgQmlsbCBOb3R0aW5naGFtIDxub3R0aW5nQHJlZGhhdC5j b20+Ci0gZml4IGFscGhhIGJ1aWxkCgoqIFRodSBOb3YgIDkgMjAwMCBCaWxsIE5vdHRpbmdo YW0gPG5vdHRpbmdAcmVkaGF0LmNvbT4KLSBhZGQgcGF0Y2ggZnJvbSBBc2l0IE1hbGxpY2sg dG8gZml4IGlhNjQgVkhQVCBkaXNhYmxpbmcKCiogV2VkIE5vdiAgOCAyMDAwIEJpbGwgTm90 dGluZ2hhbSA8bm90dGluZ0ByZWRoYXQuY29tPgotIGFkZCBpYTY0IG1vZHVsZSBwYXRjaAoK KiBXZWQgTm92IDA4IDIwMDAgRXJpayBUcm9hbiA8ZXd0QHJlZGhhdC5jb20+Ci0gdXBkYXRl ZCB0byB0ZXN0MTAsIGJ1aWxkcyBvbiBpeDg2CgoqIFdlZCBOb3YgIDEgMjAwMCBCaWxsIE5v dHRpbmdoYW0gPG5vdHRpbmdAcmVkaGF0LmNvbT4KLSBidWlsZCBzb21lIHN0dWZmIHN0YXRp Y2FsbHkgKGJsZWFoKQoKKiBUdWUgT2N0IDMxIDIwMDAgQmlsbCBOb3R0aW5naGFtIDxub3R0 aW5nQHJlZGhhdC5jb20+Ci0gbmV3IGlhNjQgZGlmZiBmcm9tIERhdmlkIE1vc2JlcmdlcgoK KiBUaHUgT2N0IDI2IDIwMDAgQmlsbCBOb3R0aW5naGFtIDxub3R0aW5nQHJlZGhhdC5jb20+ Ci0gdHVybiBvZmYgcHRjLmcsIGFnYWluIChvb3BzKQoKKiBXZWQgT2N0IDI1IDIwMDAgQmls bCBOb3R0aW5naGFtIDxub3R0aW5nQHJlZGhhdC5jb20+Ci0gRUZJIEdVSUQgcGFydGl0aW9u IHN1cHBvcnQgZnJvbSBNYXR0IERvbXNjaCAoTWF0dF9Eb21zY2hAZGVsbC5jb20pCgoqIFR1 ZSBPY3QgMjQgMjAwMCBCaWxsIE5vdHRpbmdoYW0gPG5vdHRpbmdAcmVkaGF0LmNvbT4KLSBx bG9naWMgMXgxNjAgdmVyc2lvbiAzLjE5YmV0YQotIHFsb2dpYyAyeDAwIHZlcnNpb24gNC4x NWJldGEKLSBlMTAwMCB2Mi41LjExCi0gZTEwMCB2MS4zLjE0Ci0gbWFrZSBuZXRmaWx0ZXIg YnVpbGQgb24gaWE2NCAoY3JpbmdlKQoKKiBNb24gT2N0IDIzIDIwMDAgQmlsbCBOb3R0aW5n aGFtIDxub3R0aW5nQHJlZGhhdC5jb20+Ci0gdXBkYXRlIHRvIHRlc3Q5IGZpbmFsCi0gaWE2 NCB1cGRhdGVzCgoqIEZyaSBTZXAgMjkgMjAwMCBCaWxsIE5vdHRpbmdoYW0gPG5vdHRpbmdA cmVkaGF0LmNvbT4KLSBjbGVhbiB1cCByZXF1aXJlbWVudHMgKGtpbGwgZGV2ZnNkLCBpbml0 c2NyaXB0cykKCiogRnJpIFNlcCAyOSAyMDAwIE1pY2hhZWwgSy4gSm9obnNvbiA8am9obnNv bm1AcmVkaGF0LmNvbT4KLSB1cGRhdGVkIHRvIHR1eC0yLjQuMC10ZXN0OS1IOC1ub2RlYnVn CgoqIFRodSBTZXAgMjggMjAwMCBNaWNoYWVsIEsuIEpvaG5zb24gPGpvaG5zb25tQHJlZGhh dC5jb20+Ci0gdXBkYXRlZCB0byB0dXgtMi40LjAtdGVzdDktRzktbm9kZWJ1ZwoKKiBUdWUg U2VwIDI2IDIwMDAgTWljaGFlbCBLLiBKb2huc29uIDxqb2huc29ubUByZWRoYXQuY29tPgot IHVwZGF0ZWQgdG8gdHV4LTIuNC4wLXRlc3Q5LUc0LW5vZGVidWcgYW5kIHRlc3Q5LXByZTcg a2VybmVsCi0gdHVybmVkIG9mZiBxbGEyeDAwIGJlY2F1c2UgaXQgZG9lcyBub3Qga25vdyBh Ym91dCBuZXcgc2NzaSBpbml0IGFyY2gKLSB0dXJuZWQgb2ZmIGNjaXNzIGJlY2F1c2Ugb2Yg cGFyc2UgZXJyb3IKCiogVGh1IFNlcCAyMSAyMDAwIEJpbGwgTm90dGluZ2hhbSA8bm90dGlu Z0ByZWRoYXQuY29tPgotIHJldmVydCB0aGUgcGFydCBvZiB0aGUgaWE2NCBwYXRjaCB0aGF0 IHJlcXVpcmVzIG5ldyBtb2R1dGlscyBmb3Igbm93Ci0gdHVybiBvZmYgZTEwMDAgb24gaXg4 Ni9hbHBoYSBjb25maWdzCgoqIFR1ZSBTZXAgMTkgMjAwMCBCaWxsIE5vdHRpbmdoYW0gPG5v dHRpbmdAcmVkaGF0LmNvbT4KLSBtZXJnZSBpbiBzdHVmZiBmcm9tIE1hdHQgRG9tc2NoCi0g dXBncmFkZSBpYTY0IHBhdGNoIGZyb20gRGF2aWQgTW9zYmVyZ2VyCgoqIFR1ZSBTZXAgMTkg MjAwMCBNYXR0X0RvbXNjaCA8TWF0dF9Eb21zY2hAZGVsbC5jb20+Ci0ga2VybmVsIDIuNC4w LTAuMjguNAotIFVwZ3JhZGVkIGFjZW5pYyB0byB2MC40NwoKKiBUaHUgU2VwIDE0IDIwMDAg TWF0dF9Eb21zY2ggPE1hdHRfRG9tc2NoQGRlbGwuY29tPgotIGtlcm5lbCAyLjQuMC0wLjI4 LjMKLSBSZW1vdmVkIEkyTyBhZ2FpbgotIEFkZGVkIGlhNjQtMDAwOTEzIHBhdGNoCgotIGtl cm5lbC0yLjQuMC0wLjI4LjIKLSByZW1vdmVkIGtlcm4wOTA2LnBhdGNoCi0gYWRkZWQgMi40 LjAtdGVzdDgtMDAwOTA4IElBLTY0IHBhdGNoCi0gYWRkZWQgMi40LjAtdGVzdDgtaWE2NCBp cnFmaXggcGF0Y2ggKGZpeGVzIGJpZ3N1ciBpbmZpbml0ZSBJUlEwcykKLSBlbmFibGUgaTJv Ci0gYWRkZWQgaWE2NF9pb2Jhc2UgZXhwb3J0IHRvIGFyY2gvaWE2NC9rZXJuZWwvaWE2NF9r c3ltcy5jCgoqIFR1ZSBTZXAgMTIgMjAwMCBNaWNoYWVsIEsuIEpvaG5zb24gPGpvaG5zb25t QHJlZGhhdC5jb20+Ci0gcWxhMngwMCBkcml2ZXIgcmV2IDQuMTAKLSBtb3ZlZCBzb21lIHRo aW5ncyBmcm9tIG1vZHVsZXMgdG8gc3RhdGljIGJ1aWxkcwotIHN5bTUzYzh4eCA2NC1iaXQg cGF0Y2gKCiogVHVlIFNlcCAxMiAyMDAwIEJpbGwgTm90dGluZ2hhbSA8bm90dGluZ0ByZWRo YXQuY29tPgotIG1ha2UgaXNvOTY2MCAmIGVlcHJvMTAwIHN0YXRpYyBmb3Igbm93Ci0gbmV3 IGlhNjQgcGF0Y2hlcyBmcm9tIERhdmlkIE1vc2JlcmdlcgoKKiBGcmkgU2VwICA4IDIwMDAg QmlsbCBOb3R0aW5naGFtIDxub3R0aW5nQHJlZGhhdC5jb20+Ci0gbWFrZSBuZnMgJiBsb2Nr ZCBzdGF0aWMgb24gaWE2NDsgYmFkIHRoaW5ncyBoYXBwZW4gb3RoZXJ3aXNlCi0gdXBkYXRl IHRvIHRlc3Q4ICh0dXJuIG9mZiBzaXNmYiwgaXQgZG9lc24ndCBidWlsZCkKCiogVGh1IFNl cCAgNyAyMDAwIEJpbGwgTm90dGluZ2hhbSA8bm90dGluZ0ByZWRoYXQuY29tPgotIGJpZyBw aWxlcyBvZiBpYTY0IHVwZGF0ZXMKLSBhZGQgaW4gZTEwMDAgZHJpdmVyLCBmaXggbW9kdWxh ciBidWlsZAotIHVwZGF0ZSBhY2VuaWMgdG8gMC40NiBmb3IgdGhlIG5vbi10dXggY2FzZQot IHVwZGF0ZSBtZWdhcmFpZCB0byAxLjEwYwotIHVwZGF0ZSBxbGExMjgwIHRvIDMuMTZiCi0g YnVpbGQgYWdhaW5zdCB0ZXN0Ny1maW5hbCAobm90IHRlc3Q4LXByZTEpIGZvciBub3cKCiog VHVlIFNlcCAgNSAyMDAwIEZsb3JpYW4gTGEgUm9jaGUgPEZsb3JpYW4uTGFSb2NoZUByZWRo YXQuY29tPgotIHVwZGF0ZSB0byBwY21jaWEtY3MgMy4xLjIwCi0gcmVtb3ZlIG9ic29sZXRl IHBjbWNpYS1jcy0zLjEuMy0zY29tLnBhdGNoCgoqIFRodSBBdWcgMzEgMjAwMCBNaWNoYWVs IEsuIEpvaG5zb24gPGpvaG5zb25tQHJlZGhhdC5jb20+Ci0gTW9yZSB3b3JrIG9uIFRVWDog bmV3IHZlcnNpb24sIGJldHRlciBpbnRlZ3JhdGlvbiwgc3RpbGwgaW5jb21wbGV0ZQotIHVw ZGF0ZWQgdG8gMi40LjAtdGVzdDgtcHJlMQotIHRlbXBvcmFyaWx5IGRpc2FibGVkIG1hdHJv eCBtYXZlbiBkcml2ZXIgYmVjYXVzZSBvZiBJQ0UKCiogVGh1IEF1ZyAyNCAyMDAwIE1pY2hh ZWwgSy4gSm9obnNvbiA8am9obnNvbm1AcmVkaGF0LmNvbT4KLSBBZGRlZCBUVVggKGJ1dCBj dXJyZW50bHkgY29tbWVudGVkIG91dCBiZWNhdXNlIG9mIGluc3VmZmljaWVudCBnZW5lcmFs aXR5KQotIENvbmZpZyBmaWxlcyBtZW50aW9uIHR1eCBzbyB0aGF0IHRoZSBTUlBNIHdpbGwg c3RpbGwgYnVpbGQgaWYgeW91IGFkZAogIHRoZSBwYXRjaC4gIEhvd2V2ZXIsIHRoZXkgd2ls bCBub3QgYnVpbGQgVFVYIGluIHdpdGhvdXQgY2hhbmdlcy4KCiogV2VkIEF1ZyAxNiAyMDAw IE1pY2hhZWwgSy4gSm9obnNvbiA8am9obnNvbm1AcmVkaGF0LmNvbT4KLSBkcm9wcGVkIHBj bWNpYS1jcyBjb3B5IC1mIGZpeCBpbiBmcm9tIDIuMgoKKiBUdWUgQXVnIDE1IDIwMDAgQmls bCBOb3R0aW5naGFtIDxub3R0aW5nQHJlZGhhdC5jb20+Ci0gdXBkYXRlIGlhNjQgc3R1ZmYK CiogVHVlIEF1ZyAxNSAyMDAwIEpha3ViIEplbGluZWsgPGpha3ViQHJlZGhhdC5jb20+Ci0g dXBkYXRlIHRvIHRlc3Q3LXByZTQKLSBmaXggZW11MTBrMSBidWlsZCBvbiBhbHBoYQotIC5j b25maWcgdXBkYXRlcwoKKiBNb24gQXVnIDE0IDIwMDAgSmFrdWIgSmVsaW5layA8amFrdWJA cmVkaGF0LmNvbT4KLSBmaXggbGludXgtbWVyZ2UtY29uZmlnLmF3awotIHJlbW92ZSAvdXNy L2luY2x1ZGUve2xpbnV4LGFzbSp9IGluIGtlcm5lbC1oZWFkZXJzICVwcmUKCiogVGh1IEF1 ZyAxMCAyMDAwIEJpbGwgTm90dGluZ2hhbSA8bm90dGluZ0ByZWRoYXQuY29tPgotIHVwZGF0 ZSB0byB0ZXN0Ni1maW5hbCAodmdlciBwYXRjaCBpcyBtZXJnZWQpCgoqIFdlZCBBdWcgIDkg MjAwMCBKYWt1YiBKZWxpbmVrIDxqYWt1YkByZWRoYXQuY29tPgotIHVwZGF0ZSB0byB0ZXN0 Ni9wcmU5Ci0gYXBwbHkgdmdlciBwYXRjaGVzCi0gbWFrZSBpdCBidWlsZCBvbiBzcGFyYzMy CgoqIFR1ZSBBdWcgIDggMjAwMCBCaWxsIE5vdHRpbmdoYW0gPG5vdHRpbmdAcmVkaGF0LmNv bT4KLSBtYWtlIGl0IGJ1aWxkIG9uIGlhNjQKCiogVHVlIEF1ZyAgOCAyMDAwIEpha3ViIEpl bGluZWsgPGpha3ViQHJlZGhhdC5jb20+Ci0gL3Vzci9pbmNsdWRlL3tsaW51eCxhc219IGFy ZSBkaXJlY3RvcmllcwotIGZpeCBoZWFkZXIgbWVyZ2luZwotIHVwZGF0ZSB0byB0ZXN0Ni9w cmU4CgoqIFdlZCBBdWcgIDIgMjAwMCBCaWxsIE5vdHRpbmdoYW0gPG5vdHRpbmdAcmVkaGF0 LmNvbT4KLSBhZGQgaWEzMiBzaWduYWwgcGF0Y2ggZm9yIGlhNjQKCiogVHVlIEF1ZyAgMSAy MDAwIEJpbGwgTm90dGluZ2hhbSA8bm90dGluZ0ByZWRoYXQuY29tPgotIHVwZGF0ZSB0byBw cmU1L2lhNjQtNzI4IChhcmdoKQotIHVwZGF0ZSBxbGEyeDAwIHNjc2kgZHJpdmVyIHRvIDQu MCAoZnJvbSBRbG9naWMpCgoqIFdlZCBKdWwgMjYgMjAwMCBCaWxsIE5vdHRpbmdoYW0gPG5v dHRpbmdAcmVkaGF0LmNvbT4KLSBjbGVhbiB1cCB0aGUgJXBvc3RzIHNvbWUKCiogV2VkIEp1 bCAyNiAyMDAwIEpha3ViIEplbGluZWsgPGpha3ViQHJlZGhhdC5jb20+Ci0gUmVuYW1lIGtl cm5lbDI0IHN1YnBhY2thZ2VzIGJhY2sKLSBwYXJwb3J0IGZpeCBmcm9tIFRpbSBXYXVnaAot IG1ha2UgaXQgYnVpbGQgb24gQWxwaGEgKGhvcGVmdWxseSkKCiogV2VkIEp1bCAyNiAyMDAw IEpha3ViIEplbGluZWsgPGpha3ViQHJlZGhhdC5jb20+Ci0ga2lsbCBzb21lIG9mIHRoZSB1 Z2x5IGhhY2tzLCByZXBsYWNlIHRoZW0gd2l0aCBvdGhlciB1Z2x5CiAgaGFja3Mgc28gdGhh dCB0aGUgcGFja2FnZSBjYW4gYmUgYnVpbHQgYXMgdGhlIG1haW4gZGlzdHJpYnV0aW9uCiAg a2VybmVsIG9yIGFuIGV4cGVyaW1lbnRhbCBvbmUuCi0gZml4IHRoZSBleHBvcnQgbWVtY3B5 L21lbXNldCBwYXRjaAotIGFkZCBlbnRlcnByaXNlIGtlcm5lbCAoNjRHQiBrZXJuZWwpIG9u IGk2ODYKCiogVHVlIEp1bCAyNSAyMDAwIEJpbGwgTm90dGluZ2hhbSA8bm90dGluZ0ByZWRo YXQuY29tPgotIHVnbHkgaGFja3MgdG8gZ2V0IGp1c3QgdGhlIGhlYWRlcnMgb3V0CgoqIFR1 ZSBKdWwgMjUgMjAwMCBKYWt1YiBKZWxpbmVrIDxqYWt1YkByZWRoYXQuY29tPgotIGtpbGwg c2V2ZXJhbCB1bnJlc29sdmVkIHN5bWJvbHMgZnJvbSBtb2R1bGVzCgoqIEZyaSBKdWwgMjEg MjAwMCBCaWxsIE5vdHRpbmdoYW0gPG5vdHRpbmdAcmVkaGF0LmNvbT4KLSBtb3JlIHR3ZWFr cwoKKiBUaHUgSnVsIDIwIDIwMDAgSmFrdWIgSmVsaW5layA8amFrdWJAcmVkaGF0LmNvbT4K LSBzb21lIG1vcmUgdHdlYWtzCgoqIFR1ZSBKdWwgMTggMjAwMCBKYWt1YiBKZWxpbmVrIDxq YWt1YkByZWRoYXQuY29tPgotIENJUEUKLSBhIGNvdXBsZSBvZiBwYXRjaGxldHMKLSBGSFMg dHdlYWtzCgoqIFdlZCBKdW4gMjEgMjAwMCBCaWxsIE5vdHRpbmdoYW0gPG5vdHRpbmdAcmVk aGF0LmNvbT4KLSB1cGRhdGUgYWNlbmljLCBtZWdhcmFpZCwgcWxhMTI4MCBkcml2ZXJzCi0g bWlub3Iga2VybmVsIGhlYWRlciB0d2VhayBmb3IgdXNlcmxhbmQKCiogU2F0IEp1biAxNyAy MDAwIEJpbGwgTm90dGluZ2hhbSA8bm90dGluZ0ByZWRoYXQuY29tPgotIGJ1bXAgdXAgcmFt ZGlzayBzaXplIG9uIGlhNjQgJiBhbHBoYQotIGNvbXBpbGUgbW9yZSBzdHVmZiBpbnRvIHRo ZSBrZXJuZWwgdW50aWwgbW9kdWxlcyB3b3JrIGJldHRlcgoKKiBGcmkgSnVuIDE2IDIwMDAg QmlsbCBOb3R0aW5naGFtIDxub3R0aW5nQHJlZGhhdC5jb20+Ci0gYWRkIGlhMzIgc2lnbmFs IGhhbmRsaW5nIHBhdGNoIGZvciBpYTY0CgoqIFRodSBKdW4gMTUgMjAwMCBKYWt1YiBKZWxp bmVrIDxqYWt1YkByZWRoYXQuY29tPgotIHJlZW5hYmxlIGNoYW5nZWxvb3AgcGF0Y2gKCiog V2VkIEp1biAxNCAyMDAwIEJpbGwgTm90dGluZ2hhbSA8bm90dGluZ0ByZWRoYXQuY29tPgot IG1lcmdlIGluIGxvb3BiYWNrIGZpeGVzIGZyb20gLWFjIHNlcmllcwoKKiBUdWUgSnVuIDEz IDIwMDAgQmlsbCBOb3R0aW5naGFtIDxub3R0aW5nQHJlZGhhdC5jb20+Ci0gaWE2NCB1cGRh dGVzICgwNjA5IHBhdGNoKQotIG1vZHVsZSBjb25maWcvdmVyc2lvbmluZyB1cGRhdGVzCgoq IE1vbiBKdW4gIDUgMjAwMCBCaWxsIE5vdHRpbmdoYW0gPG5vdHRpbmdAcmVkaGF0LmNvbT4K LSBtZXJnZSBpbiB0aGUgaWE2NCBzdHVmZgotIG1vdmUgdG8gL2Rldi9zaG0KCiogU2F0IEp1 biAgMyAyMDAwIEpha3ViIEplbGluZWsgPGpha3ViQHJlZGhhdC5jb20+Ci0gZml4IHJoY29u ZmlnLmggKGZyb20gQmVybykKCiogTW9uIE1heSAyOSAyMDAwIEpha3ViIEplbGluZWsgPGph a3ViQHJlZGhhdC5jb20+Ci0gMi40LjAtdGVzdDEKLSBjaGFuZ2Vsb29wIHBhdGNoCi0gZml4 IEJ1aWxkQVNNCi0gZml4IGNvbXBpbGF0aW9uIHdpdGggZ2NjIDIuOTYKLSBmaXggZGV2ZnNk IGNvbXBpbGF0aW9uCgoqIFNhdCBNYXkgIDYgMjAwMCBCZXJuaGFyZCBSb3NlbmtyYWVuemVy IDxiZXJvQHJlZGhhdC5jb20+Ci0gcHJlNy02Ci0gZGV2ZnNkIDEuMy44Ci0gYWRkIGV2ZW4g bW9yZSBjb25mdXNpb24gdG8gdGhlIHZlcnNpb25pbmcgaGVsbCA7KQogIChzbyB3ZSBjYW4g ZGVhbCB3aXRoIHByZS1wcmUgdmVyc2lvbnMpCgoqIEZyaSBBcHIgMjggMjAwMCBCaWxsIE5v dHRpbmdoYW0gPG5vdHRpbmdAcmVkaGF0LmNvbT4KLSB1cGRhdGUgZm9yIGlhNjQKLSBwcmU2 LWZpbmFsCi0gZG9uJ3QgYXBwbHkgYWJpIHBhdGNoIHVudGlsIGl0IHN0b3BzIGltcGxvZGlu ZyBvbiBib290CgoqIE1vbiBBcHIgMTcgMjAwMCBCZXJuaGFyZCBSb3NlbmtyYWVuemVyIDxi ZXJvQHJlZGhhdC5jb20+Ci0gMi4zLjk5cHJlNi1wcmUzCi0gdXBkYXRlIGtzeW1vb3BzIHRv IDIuMy40Ci0gdXBkYXRlIHBjbWNpYSB0byAzLjEuMTQKLSBkZXZmc2QgMS4zLjQsIGRldmZz IDE2MgotIGxpbmsga3N5bW9vcHMgc3RhdGljYWxseSB0byBnZXQgcmlkIG9mIHRoZSBkZXBl bmRlbmN5IG9uIGEgcGFydGljdWxhcgogIHZlcnNpb24gb2YgYmludXRpbHMKLSBhZGFwdCBh YmkgcGF0Y2ggdG8gbmV3IGtlcm5lbCBpbnRlcmZhY2VzCi0gbWlub3IgZml4ZXMgdG8gc3Bl YyBmaWxlCgoqIFdlZCBNYXIgMjIgMjAwMCBCZXJuaGFyZCBSb3NlbmtyYWVuemVyIDxiZXJv QHJlZGhhdC5jb20+Ci0gMi4zLjk5cHJlMy03Ci0gcmVtb3ZlIHNvbWUgZml4ZXMgKHRoZXkn cmUgbm93IGluIHRoZSBiYXNlIHZlcnNpb24pCgoqIFR1ZSBNYXIgMjEgMjAwMCBCZXJuaGFy ZCBSb3NlbmtyYWVuemVyIDxiZXJvQHJlZGhhdC5jb20+Ci0gQWRkIC92YXIvc2htIGRpcgot IHJlcXVpcmUgaW5pdHNjcmlwdHMgPj0gNS4wMyBzbyB3ZSBtb3VudCAvdmFyL3NobQotIDIu My45OXByZTMtMwotIGZpeCBjb21waWxhdGlvbiBvZiBzb21lIGJ1Z2d5IGRyaXZlcnMKLSBm aXggYnVpbGQgb24gc3BhcmM2NAoKKiBUaHUgTWFyIDE2IDIwMDAgQmVybmhhcmQgUm9zZW5r cmFlbnplciA8YmVyb0ByZWRoYXQuY29tPgotIDIuMy45OXByZTItMwotIHJlcGxhY2UgaUJD UyB3aXRoIGFiaSwgcmVtb3ZlIHBhdGNoZXMKLSBwb3J0IGFiaSB0byAyLjMuOTlwcmUyLTMK LSBmaXggcGFja2FnaW5nIGJ1ZyAoa3N5bW9vcHMuOCogd2FzIGluY2x1ZGVkIGluIGtlcm5l bC11dGlscyBBTkQKICBrZXJuZWwtcGNtY2lhLWNzKQotIGFkZCBkZXZmc2QKLSBmaXggY29t cGlsYXRpb24gb24gYWxwaGEgKGZpeCB2YXJpb3VzIGtlcm5lbCBidWdzIGFuZCB3b3JrCiAg YXJvdW5kIGEgY29tcGlsZXIgYnVnKQo= --------------64A01D39608411EAE632E459-- From owner-linux-xfs@oss.sgi.com Thu Jan 24 10:05:14 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0OI5EV22592 for linux-xfs-outgoing; Thu, 24 Jan 2002 10:05:14 -0800 Received: from pneumatic-tube.sgi.com (pneumatic-tube.sgi.com [204.94.214.22]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0OI5AP22559 for ; Thu, 24 Jan 2002 10:05:10 -0800 Received: from zeus-e8.americas.sgi.com (zeus-e8.americas.sgi.com [128.162.8.103]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id JAA03980 for ; Thu, 24 Jan 2002 09:06:04 -0800 (PST) mail_from (roehrich@sgi.com) Received: from thistle-e185.americas.sgi.com (thistle-e185.americas.sgi.com [128.162.185.204]) by zeus-e8.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id LAA131623 for ; Thu, 24 Jan 2002 11:03:52 -0600 (CST) Received: from clink.americas.sgi.com (clink-eth.americas.sgi.com [128.162.2.8]) by thistle-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id LAA42309 for ; Thu, 24 Jan 2002 11:03:52 -0600 (CST) Received: (from roehrich@localhost) by clink.americas.sgi.com (SGI-8.9.3/8.9.3/erikj-IRIX) id LAA57424 for linux-xfs@oss.sgi.com; Thu, 24 Jan 2002 11:03:52 -0600 (CST) Date: Thu, 24 Jan 2002 11:03:52 -0600 (CST) From: Dean Roehrich Message-Id: <200201241703.LAA57424@clink.americas.sgi.com> To: linux-xfs@oss.sgi.com Subject: TAKE - cleanup dmapi cflags and header usage Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 563 Lines: 19 Date: Thu Jan 24 09:02:18 PST 2002 Workarea: clink-eth.americas.sgi.com:/data/clink/a67/roehrich/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:110146a linux/fs/xfs_dmapi/xfsjunk.c - 1.2 - No Message Supplied linux/fs/xfs_dmapi/Makefile.in - 1.4 linux/fs/xfs_dmapi/dmapi_session.c - 1.3 linux/fs/xfs_dmapi/dmapi_register.c - 1.3 linux/fs/xfs_dmapi/dmapi_private.h - 1.3 linux/fs/xfs_dmapi/dmapi_event.c - 1.3 linux/fs/xfs_dmapi/Makefile - 1.2 linux/fs/xfs_dmapi/dmapi_sysent.c - 1.2 From owner-linux-xfs@oss.sgi.com Thu Jan 24 10:44:04 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0OIi4802707 for linux-xfs-outgoing; Thu, 24 Jan 2002 10:44:04 -0800 Received: from yog-sothoth.sgi.com (eugate.sgi.com [192.48.160.10]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0OIi0P02008 for ; Thu, 24 Jan 2002 10:44:00 -0800 Received: from zeus-e8.americas.sgi.com (zeus-e8.americas.sgi.com [128.162.8.103]) by yog-sothoth.sgi.com (980305.SGI.8.8.8-aspam-6.2/980304.SGI-aspam-europe) via ESMTP id SAA571428 for ; Thu, 24 Jan 2002 18:43:45 +0100 (CET) mail_from (lord@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by zeus-e8.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id LAA132918 for ; Thu, 24 Jan 2002 11:42:40 -0600 (CST) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id LAA66240 for ; Thu, 24 Jan 2002 11:42:40 -0600 (CST) From: Steve Lord Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id g0OHfXP18882; Thu, 24 Jan 2002 11:41:33 -0600 Message-Id: <200201241741.g0OHfXP18882@jen.americas.sgi.com> Date: Thu, 24 Jan 2002 11:41:33 -0600 Subject: TAKE - fix 2.5 smp boot bug which bites some folks Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 298 Lines: 12 Date: Thu Jan 24 09:41:03 PST 2002 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:110154a linux/arch/i386/kernel/smpboot.c - 1.29 - fix smp boot bug which bites some people From owner-linux-xfs@oss.sgi.com Thu Jan 24 12:29:33 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0OKTXa31074 for linux-xfs-outgoing; Thu, 24 Jan 2002 12:29:33 -0800 Received: from rj.sgi.com (rj.SGI.COM [204.94.215.100]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0OKTTP31037 for ; Thu, 24 Jan 2002 12:29:30 -0800 Received: from relay1.corp.sgi.com (spindle.corp.sgi.com [198.29.75.13]) by rj.sgi.com (8.11.4/8.11.4/linux-outbound_gateway-1.1) with ESMTP id g0OJTMY20118 for ; Thu, 24 Jan 2002 11:29:22 -0800 Received: from stantz.corp.sgi.com (stantz.corp.sgi.com [130.62.4.42]) by relay1.corp.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) via ESMTP id LAA65615 for ; Thu, 24 Jan 2002 11:28:51 -0800 (PST) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by stantz.corp.sgi.com (Postfix) with ESMTP id 206D2136714 for ; Thu, 24 Jan 2002 11:28:51 -0800 (PST) Subject: XFS and TUX From: Florin Andrei To: linux-xfs@oss.sgi.com Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/1.0.1 Date: 24 Jan 2002 11:28:51 -0800 Message-Id: <1011900531.8719.11.camel@stantz.corp.sgi.com> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 412 Lines: 13 I see that, together with the new kernel RPMs, Red Hat also updated TUX. Anyone using TUX on XFS machines (especially under heavy load)? Positive feedback? Negative? If new XFS RPMs will be released, will they work well with TUX-2.2.0? -- Florin Andrei "The security of any corporate network is inversely proportional to the number of systems administrators on the network." - - Petreley's law of sysadmins From owner-linux-xfs@oss.sgi.com Thu Jan 24 12:33:16 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0OKXGY31929 for linux-xfs-outgoing; Thu, 24 Jan 2002 12:33:16 -0800 Received: from pneumatic-tube.sgi.com (pneumatic-tube.sgi.com [204.94.214.22]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0OKXDP31904 for ; Thu, 24 Jan 2002 12:33:13 -0800 Received: from zeus-e8.americas.sgi.com (zeus-e8.americas.sgi.com [128.162.8.103]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id LAA01860 for ; Thu, 24 Jan 2002 11:34:05 -0800 (PST) mail_from (lord@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by zeus-e8.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id NAA133943; Thu, 24 Jan 2002 13:31:51 -0600 (CST) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id NAA29319; Thu, 24 Jan 2002 13:31:50 -0600 (CST) Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id g0OJUhd23046; Thu, 24 Jan 2002 13:30:43 -0600 Subject: Re: XFS and TUX From: Steve Lord To: Florin Andrei Cc: linux-xfs@oss.sgi.com In-Reply-To: <1011900531.8719.11.camel@stantz.corp.sgi.com> References: <1011900531.8719.11.camel@stantz.corp.sgi.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/1.0.1 Date: 24 Jan 2002 13:30:43 -0600 Message-Id: <1011900643.18897.0.camel@jen.americas.sgi.com> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 519 Lines: 16 On Thu, 2002-01-24 at 13:28, Florin Andrei wrote: > I see that, together with the new kernel RPMs, Red Hat also updated TUX. > Anyone using TUX on XFS machines (especially under heavy load)? Positive > feedback? Negative? > > If new XFS RPMs will be released, will they work well with TUX-2.2.0? Now is your chance, as an SGI employee, to help the project out ;-) Steve -- Steve Lord voice: +1-651-683-3511 Principal Engineer, Filesystem Software email: lord@sgi.com From owner-linux-xfs@oss.sgi.com Thu Jan 24 12:41:45 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0OKfjJ01514 for linux-xfs-outgoing; Thu, 24 Jan 2002 12:41:45 -0800 Received: from UberGeek.coremetrics.com ([209.184.141.163]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0OKfcP01451 for ; Thu, 24 Jan 2002 12:41:38 -0800 Received: (from austin@localhost) by UberGeek.coremetrics.com (8.11.6/8.11.6) id g0OJf0328370; Thu, 24 Jan 2002 13:41:00 -0600 X-Authentication-Warning: UberGeek.coremetrics.com: austin set sender to austin@coremetrics.com using -f Subject: Memory Issues with 2.4.14-xfs From: Austin Gonyou To: linux-xfs@oss.sgi.com Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-5g4TFAQ6s3cDTPXCyoxg" X-Mailer: Evolution/1.0.1 Date: 24 Jan 2002 13:41:00 -0600 Message-Id: <1011901260.28034.7.camel@UberGeek> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 1551 Lines: 44 --=-5g4TFAQ6s3cDTPXCyoxg Content-Type: text/plain Content-Transfer-Encoding: quoted-printable I'm having some pretty bad issues with memory being put into cache, and then not being released. This is causing me to have lots of networking problems because my eepro100 keeps having issues and reporting "no resources". When I get on the system locally, I can see that there is a large amount of swap in use, and almost all of the 8GB of ram I have is in cache.=20 My DBA's have been setting up an oracle instance on that server, but they're running into problems because cached ram isn't being released.=20 I seem to recall something about this being fixed, but I don't remember what kernel version, etc. Could someone lend a suggestion or two? I'd like to use 2.4.17, but I'm kind of put-off with all the data corruption issues I've seen on the list lately. Is 2.4.17 ok to use with the patches on oss.sgi.com/projects/xfs/downloads/patches? --=20 Austin Gonyou Systems Architect, CCNA Coremetrics, Inc. Phone: 512-698-7250 email: austin@coremetrics.com "It is the part of a good shepherd to shear his flock, not to skin it." Latin Proverb --=-5g4TFAQ6s3cDTPXCyoxg Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQA8UGNM94g6ZVmFMoIRAlmSAJ40Xg2xoROfEAo06QVoJ4pvI56cjwCgqXiJ OwrvFWrhOGyuEIcZmx80znQ= =apwb -----END PGP SIGNATURE----- --=-5g4TFAQ6s3cDTPXCyoxg-- From owner-linux-xfs@oss.sgi.com Thu Jan 24 12:46:29 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0OKkTY02919 for linux-xfs-outgoing; Thu, 24 Jan 2002 12:46:29 -0800 Received: from ente.berdmann.de (frnk-d514e1d8.dsl.mediaWays.net [213.20.225.216]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0OKkMP02869 for ; Thu, 24 Jan 2002 12:46:22 -0800 Received: from apollo.berdmann.de ([192.168.1.2] helo=berdmann.de) by ente.berdmann.de with esmtp (Exim 3.22 #1) id 16Tpp4-0006VJ-00 for linux-xfs@oss.sgi.com; Thu, 24 Jan 2002 20:46:10 +0100 Message-ID: <3C506482.5AFB7F22@berdmann.de> Date: Thu, 24 Jan 2002 20:46:10 +0100 From: "Bernhard R. Erdmann" X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.4.17-xfs i586) X-Accept-Language: de, en, fr MIME-Version: 1.0 To: Linux XFS Mailing List Subject: [Fwd: [linux-lvm] *** ANNOUNCEMENT *** LVM 1.0.2 available at www.sistina.com] Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 1252 Lines: 49 -------- Original Message -------- Subject: [linux-lvm] *** ANNOUNCEMENT *** LVM 1.0.2 available at www.sistina.com Date: Thu, 24 Jan 2002 17:01:28 +0100 From: "Heinz J . Mauelshagen" Reply-To: linux-lvm@sistina.com To: linux-lvm@sistina.com *** ANNOUNCEMENT *** LVM 1.0.2 available at www.sistina.com Hi all, LVM 1.0.2 supports both version 1 and 2 of the metadata. There's *no* need to run any metadata update tools. A tarball is available now at for download (Follow the "LVM 1.0" link). This release contains minor changes to LVM 1.0.1 including: o Linux 2.4.17 support o sparc 64 fixes (tests needed!) o persistent LV device minors to support client recovery after a NFS server reboot/failover o ataraid device support o support loop devices (they do not show up in /proc/partitions) See the CHANGELOG file contained in the tarball for further information. Feed back LVM related information to . Thanks a lot for your support of LVM. _______________________________________________ linux-lvm mailing list linux-lvm@sistina.com http://lists.sistina.com/mailman/listinfo/linux-lvm read the LVM HOW-TO at http://www.sistina.com/lvm/Pages/howto.html From owner-linux-xfs@oss.sgi.com Thu Jan 24 12:46:58 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0OKkwQ03172 for linux-xfs-outgoing; Thu, 24 Jan 2002 12:46:58 -0800 Received: from rj.sgi.com (rj.SGI.COM [204.94.215.100]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0OKksP03133 for ; Thu, 24 Jan 2002 12:46:54 -0800 Received: from relay1.corp.sgi.com (spindle.corp.sgi.com [198.29.75.13]) by rj.sgi.com (8.11.4/8.11.4/linux-outbound_gateway-1.1) with ESMTP id g0OJklY21875 for ; Thu, 24 Jan 2002 11:46:47 -0800 Received: from stantz.corp.sgi.com (stantz.corp.sgi.com [130.62.4.42]) by relay1.corp.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) via ESMTP id LAA73283 for ; Thu, 24 Jan 2002 11:46:16 -0800 (PST) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by stantz.corp.sgi.com (Postfix) with ESMTP id B4E42136714 for ; Thu, 24 Jan 2002 11:46:16 -0800 (PST) Subject: Re: XFS and TUX From: Florin Andrei To: linux-xfs@oss.sgi.com In-Reply-To: <1011900643.18897.0.camel@jen.americas.sgi.com> References: <1011900531.8719.11.camel@stantz.corp.sgi.com> <1011900643.18897.0.camel@jen.americas.sgi.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/1.0.1 Date: 24 Jan 2002 11:46:16 -0800 Message-Id: <1011901576.8711.18.camel@stantz.corp.sgi.com> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 992 Lines: 27 On Thu, 2002-01-24 at 11:30, Steve Lord wrote: > On Thu, 2002-01-24 at 13:28, Florin Andrei wrote: > > I see that, together with the new kernel RPMs, Red Hat also updated TUX. > > Anyone using TUX on XFS machines (especially under heavy load)? Positive > > feedback? Negative? > > > > If new XFS RPMs will be released, will they work well with TUX-2.2.0? > > Now is your chance, as an SGI employee, to help the project out ;-) Heh, ok, i got it. :-) I was actually thinking of the ENO mirror server, linux-dist.corp, who's been installed long time ago, never been really used, and now is in process of being revamped (to make it really useful). TUX looks like a good choice to serve the HTTP part of it. Ok, i'll wait for you guys to release the XFS kernel updates and then i'll apply them to the mirror server. -- Florin Andrei "The security of any corporate network is inversely proportional to the number of systems administrators on the network." - - Petreley's law of sysadmins From owner-linux-xfs@oss.sgi.com Thu Jan 24 12:47:06 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0OKl6303319 for linux-xfs-outgoing; Thu, 24 Jan 2002 12:47:06 -0800 Received: from clubphoto.com (mail-gw.clubphoto.com [64.124.34.66]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0OKl3P03263 for ; Thu, 24 Jan 2002 12:47:03 -0800 Received: from [192.168.168.136] ([192.168.168.136]) by clubphoto.com (8.9.3/8.9.3) with ESMTP id LAA01242 for ; Thu, 24 Jan 2002 11:47:01 -0800 User-Agent: Microsoft-Entourage/10.0.0.1309 Date: Thu, 24 Jan 2002 11:47:09 -0800 Subject: Iostat. Something in the kernel? From: "Gabe E. Nydick" To: Message-ID: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 218 Lines: 9 Hey folks, I have a software raid machine that under a 2.4.16 kernel doesn't show any of the raid'd drives in iostat? Is there anything I have to compile in to make sure that disk I/O is reported? Thanks, Gabe From owner-linux-xfs@oss.sgi.com Thu Jan 24 12:53:47 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0OKrld05141 for linux-xfs-outgoing; Thu, 24 Jan 2002 12:53:47 -0800 Received: from sgi.com (sgi-too.SGI.COM [204.94.211.39]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0OKrdP05086 for ; Thu, 24 Jan 2002 12:53:39 -0800 Received: from zeus-e8.americas.sgi.com (zeus-e8.americas.sgi.com [128.162.8.103]) by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id LAA07668 for ; Thu, 24 Jan 2002 11:53:36 -0800 (PST) mail_from (lord@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by zeus-e8.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id NAA134628; Thu, 24 Jan 2002 13:52:18 -0600 (CST) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id NAA26537; Thu, 24 Jan 2002 13:52:18 -0600 (CST) Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id g0OJpAp23065; Thu, 24 Jan 2002 13:51:10 -0600 Subject: Re: Memory Issues with 2.4.14-xfs From: Steve Lord To: Austin Gonyou Cc: linux-xfs@oss.sgi.com In-Reply-To: <1011901260.28034.7.camel@UberGeek> References: <1011901260.28034.7.camel@UberGeek> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/1.0.1 Date: 24 Jan 2002 13:51:10 -0600 Message-Id: <1011901870.18897.10.camel@jen.americas.sgi.com> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 2769 Lines: 65 On Thu, 2002-01-24 at 13:41, Austin Gonyou wrote: > I'm having some pretty bad issues with memory being put into cache, and > then not being released. This is causing me to have lots of networking > problems because my eepro100 keeps having issues and reporting "no > resources". When I get on the system locally, I can see that there is a > large amount of swap in use, and almost all of the 8GB of ram I have is > in cache. > > My DBA's have been setting up an oracle instance on that server, but > they're running into problems because cached ram isn't being released. > > I seem to recall something about this being fixed, but I don't remember > what kernel version, etc. Could someone lend a suggestion or two? I'd > like to use 2.4.17, but I'm kind of put-off with all the data corruption > issues I've seen on the list lately. Is 2.4.17 ok to use with the > patches on oss.sgi.com/projects/xfs/downloads/patches? The patches were updated yesterday, hopefully we have shot all the problems which emerged with 2.4.17 - they were not actually new problems, but something in 2.4.17 seemed to make them happen more. Of the top of my head, major things which have been fixed are: o a page leak which occurred under heavy memory load, someone who had reported this problem was able to run the dbench load which originally triggered it for several days non stop afterwards. This has been around since the new VM in 2.4.10. o overwriting the start of a partition with file data, this has also been there for ever, I think it used to oops on the shutdown, something changed to remove the oops, and we wrote data instead. A few people who lost filesystems in the last year or so were probably seeing a variant of this. o corruption of the emacs binary during the build process - this was a memory mapped I/O under heavy memory pressure issue. This also has been present for a long time, it probably just took the right circumstances for someone to find it. I cannot speak for people running athlon processors with DRI in the kernel, looks like there is definitely a memory corruption issue on that configuration which has the potential for having eaten a couple of filesystems. We cannot really offer backports of individual fixes to specific kernel versions, it is just too much work. Hopefully 2.4.17 is beaten into shape now and can be used without fear. Steve > -- > Austin Gonyou > Systems Architect, CCNA > Coremetrics, Inc. > Phone: 512-698-7250 > email: austin@coremetrics.com > > "It is the part of a good shepherd to shear his flock, not to skin it." > Latin Proverb -- Steve Lord voice: +1-651-683-3511 Principal Engineer, Filesystem Software email: lord@sgi.com From owner-linux-xfs@oss.sgi.com Thu Jan 24 13:01:49 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0OL1nG07249 for linux-xfs-outgoing; Thu, 24 Jan 2002 13:01:49 -0800 Received: from UberGeek.coremetrics.com ([209.184.141.163]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0OL1YP07165 for ; Thu, 24 Jan 2002 13:01:35 -0800 Received: (from austin@localhost) by UberGeek.coremetrics.com (8.11.6/8.11.6) id g0OK0rf30771; Thu, 24 Jan 2002 14:00:53 -0600 X-Authentication-Warning: UberGeek.coremetrics.com: austin set sender to austin@coremetrics.com using -f Subject: Re: Memory Issues with 2.4.14-xfs From: Austin Gonyou To: Steve Lord Cc: linux-xfs@oss.sgi.com In-Reply-To: <1011901870.18897.10.camel@jen.americas.sgi.com> References: <1011901870.18897.10.camel@jen.americas.sgi.com> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-uCN/OInxRCee0b19QaOy" X-Mailer: Evolution/1.0.1 Date: 24 Jan 2002 14:00:53 -0600 Message-Id: <1011902453.30740.0.camel@UberGeek> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 3875 Lines: 111 --=-uCN/OInxRCee0b19QaOy Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Thanks. I'll try it and see what happens. :) Are the latest patches available, or have they not been pulled from the cvs tree yet? Either way, I'll go look. :)=20 On Thu, 2002-01-24 at 13:51, Steve Lord wrote: > On Thu, 2002-01-24 at 13:41, Austin Gonyou wrote: > > I'm having some pretty bad issues with memory being put into cache, > and > > then not being released. This is causing me to have lots of networking > > problems because my eepro100 keeps having issues and reporting "no > > resources". When I get on the system locally, I can see that there is > a > > large amount of swap in use, and almost all of the 8GB of ram I have > is > > in cache.=20 > >=20 > > My DBA's have been setting up an oracle instance on that server, but > > they're running into problems because cached ram isn't being released. >=20 > >=20 > > I seem to recall something about this being fixed, but I don't > remember > > what kernel version, etc. Could someone lend a suggestion or two? I'd > > like to use 2.4.17, but I'm kind of put-off with all the data > corruption > > issues I've seen on the list lately. Is 2.4.17 ok to use with the > > patches on oss.sgi.com/projects/xfs/downloads/patches? >=20 > The patches were updated yesterday, hopefully we have shot all the > problems which emerged with 2.4.17 - they were not actually new > problems, but something in 2.4.17 seemed to make them happen more. >=20 > Of the top of my head, major things which have been fixed are: >=20 > o a page leak which occurred under heavy memory load, someone who had > reported this problem was able to run the dbench load which > originally > triggered it for several days non stop afterwards. This has been > around > since the new VM in 2.4.10. >=20 > o overwriting the start of a partition with file data, this has also > been > there for ever, I think it used to oops on the shutdown, something=20 > changed to remove the oops, and we wrote data instead. A few people > who lost filesystems in the last year or so were probably seeing a > variant of this. >=20 > o corruption of the emacs binary during the build process - this was a > memory mapped I/O under heavy memory pressure issue. This also has > been present for a long time, it probably just took the right > circumstances > for someone to find it. >=20 > I cannot speak for people running athlon processors with DRI in the=20 > kernel, looks like there is definitely a memory corruption issue on that > configuration which has the potential for having eaten a couple of > filesystems. >=20 > We cannot really offer backports of individual fixes to specific kernel > versions, it is just too much work. Hopefully 2.4.17 is beaten into > shape > now and can be used without fear. >=20 > Steve >=20 >=20 > > --=20 > > Austin Gonyou > > Systems Architect, CCNA > > Coremetrics, Inc. > > Phone: 512-698-7250 > > email: austin@coremetrics.com > >=20 > > "It is the part of a good shepherd to shear his flock, not to skin > it." > > Latin Proverb > --=20 >=20 > Steve Lord voice: +1-651-683-3511 > Principal Engineer, Filesystem Software email: lord@sgi.com --=20 Austin Gonyou Systems Architect, CCNA Coremetrics, Inc. Phone: 512-698-7250 email: austin@coremetrics.com "It is the part of a good shepherd to shear his flock, not to skin it." Latin Proverb --=-uCN/OInxRCee0b19QaOy Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQA8UGf194g6ZVmFMoIRAk24AKDk94ZDFLjqS9c8qeHTbTGXZc9rJACgwiBG FuMgdv3OBYJlKVXz7HJ2QEU= =jReW -----END PGP SIGNATURE----- --=-uCN/OInxRCee0b19QaOy-- From owner-linux-xfs@oss.sgi.com Thu Jan 24 13:02:56 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0OL2ur07637 for linux-xfs-outgoing; Thu, 24 Jan 2002 13:02:56 -0800 Received: from UberGeek.coremetrics.com ([209.184.141.163]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0OL2nP07586 for ; Thu, 24 Jan 2002 13:02:50 -0800 Received: (from austin@localhost) by UberGeek.coremetrics.com (8.11.6/8.11.6) id g0OK1NB30788; Thu, 24 Jan 2002 14:01:23 -0600 X-Authentication-Warning: UberGeek.coremetrics.com: austin set sender to austin@coremetrics.com using -f Subject: Re: Iostat. Something in the kernel? From: Austin Gonyou To: "Gabe E. Nydick" Cc: linux-xfs@oss.sgi.com In-Reply-To: References: Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-hA8PkxRALzlOl1kGS9Ot" X-Mailer: Evolution/1.0.1 Date: 24 Jan 2002 14:01:22 -0600 Message-Id: <1011902483.30744.2.camel@UberGeek> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 1019 Lines: 42 --=-hA8PkxRALzlOl1kGS9Ot Content-Type: text/plain Content-Transfer-Encoding: quoted-printable MD Devices or HW Raid? On Thu, 2002-01-24 at 13:47, Gabe E. Nydick wrote: > Hey folks, >=20 > I have a software raid machine that under a 2.4.16 kernel doesn't > show > any of the raid'd drives in iostat? Is there anything I have to compile > in > to make sure that disk I/O is reported? >=20 > Thanks, > Gabe --=20 Austin Gonyou Systems Architect, CCNA Coremetrics, Inc. Phone: 512-698-7250 email: austin@coremetrics.com "It is the part of a good shepherd to shear his flock, not to skin it." Latin Proverb --=-hA8PkxRALzlOl1kGS9Ot Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQA8UGgS94g6ZVmFMoIRAmoDAJ9BFW7NBAQck++4/x+vtMxTKv3ImwCgjvYT yn75MB5mjjNiuRXJdofExwc= =2iSl -----END PGP SIGNATURE----- --=-hA8PkxRALzlOl1kGS9Ot-- From owner-linux-xfs@oss.sgi.com Thu Jan 24 13:14:48 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0OLEmx10276 for linux-xfs-outgoing; Thu, 24 Jan 2002 13:14:48 -0800 Received: from mail.ocs.com.au (mail.ocs.com.au [203.34.97.2]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0OLEjP10242 for ; Thu, 24 Jan 2002 13:14:45 -0800 Received: (qmail 10290 invoked from network); 24 Jan 2002 20:14:40 -0000 Received: from ocs3.intra.ocs.com.au (192.168.255.3) by mail.ocs.com.au with SMTP; 24 Jan 2002 20:14:40 -0000 Received: by ocs3.intra.ocs.com.au (Postfix, from userid 16331) id CD49A3000BF; Fri, 25 Jan 2002 07:14:37 +1100 (EST) Received: from ocs3.intra.ocs.com.au (localhost [127.0.0.1]) by ocs3.intra.ocs.com.au (Postfix) with ESMTP id 93D68BB; Fri, 25 Jan 2002 07:14:37 +1100 (EST) X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 From: Keith Owens To: Austin Gonyou Cc: linux-xfs@oss.sgi.com Subject: Re: Memory Issues with 2.4.14-xfs In-reply-to: Your message of "24 Jan 2002 14:00:53 MDT." <1011902453.30740.0.camel@UberGeek> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 25 Jan 2002 07:14:32 +1100 Message-ID: <7594.1011903272@ocs3.intra.ocs.com.au> Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 282 Lines: 7 On 24 Jan 2002 14:00:53 -0600, Austin Gonyou wrote: >Thanks. I'll try it and see what happens. :) Are the latest patches >available, or have they not been pulled from the cvs tree yet? Patches regenerated, up to date with CVS as of 2002-01-23 04:32 UTC. From owner-linux-xfs@oss.sgi.com Thu Jan 24 13:14:38 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0OLEc810208 for linux-xfs-outgoing; Thu, 24 Jan 2002 13:14:38 -0800 Received: from zok.sgi.com (zok.sgi.com [204.94.215.101]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0OLEZP10176 for ; Thu, 24 Jan 2002 13:14:35 -0800 Received: from zeus-e8.americas.sgi.com (zeus-e8.americas.sgi.com [128.162.8.103]) by zok.sgi.com (8.11.4/8.11.4/linux-outbound_gateway-1.1) with ESMTP id g0OKERo23447 for ; Thu, 24 Jan 2002 12:14:27 -0800 Received: from poppy-e185.americas.sgi.com (poppy-e185.americas.sgi.com [128.162.185.207]) by zeus-e8.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id OAA134580; Thu, 24 Jan 2002 14:13:10 -0600 (CST) Received: from stout.americas.sgi.com (stout.americas.sgi.com [128.162.187.5]) by poppy-e185.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.7) with ESMTP id OAA14376; Thu, 24 Jan 2002 14:13:10 -0600 (CST) Subject: Re: Memory Issues with 2.4.14-xfs From: Eric Sandeen To: Austin Gonyou Cc: Steve Lord , linux-xfs@oss.sgi.com In-Reply-To: <1011902453.30740.0.camel@UberGeek> References: <1011901870.18897.10.camel@jen.americas.sgi.com> <1011902453.30740.0.camel@UberGeek> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/1.0 (Preview Release) Date: 24 Jan 2002 14:13:10 -0600 Message-Id: <1011903190.10231.3.camel@stout.americas.sgi.com> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 408 Lines: 13 On Thu, 2002-01-24 at 14:00, Austin Gonyou wrote: > Thanks. I'll try it and see what happens. :) Are the latest patches > available, or have they not been pulled from the cvs tree yet? The 2.4.17 patches were updated yesterday or the day before; details are in a previous email message from keith. -Eric -- Eric Sandeen XFS for Linux http://oss.sgi.com/projects/xfs sandeen@sgi.com SGI, Inc. From owner-linux-xfs@oss.sgi.com Thu Jan 24 13:16:02 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0OLG2710700 for linux-xfs-outgoing; Thu, 24 Jan 2002 13:16:02 -0800 Received: from UberGeek.coremetrics.com ([209.184.141.163]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0OLFsP10595 for ; Thu, 24 Jan 2002 13:15:54 -0800 Received: (from austin@localhost) by UberGeek.coremetrics.com (8.11.6/8.11.6) id g0OKFGq31005; Thu, 24 Jan 2002 14:15:16 -0600 X-Authentication-Warning: UberGeek.coremetrics.com: austin set sender to austin@coremetrics.com using -f Subject: Re: Memory Issues with 2.4.14-xfs From: Austin Gonyou To: Eric Sandeen Cc: Steve Lord , linux-xfs@oss.sgi.com In-Reply-To: <1011903190.10231.3.camel@stout.americas.sgi.com> References: <1011903190.10231.3.camel@stout.americas.sgi.com> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-px1JL9whtKrPkj0/LhEg" X-Mailer: Evolution/1.0.1 Date: 24 Jan 2002 14:15:16 -0600 Message-Id: <1011903316.30740.14.camel@UberGeek> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 1295 Lines: 45 --=-px1JL9whtKrPkj0/LhEg Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Thanks guys. I'm really tired and having some trouble today. It's all I can do to ask questions. :)=20 On Thu, 2002-01-24 at 14:13, Eric Sandeen wrote: > On Thu, 2002-01-24 at 14:00, Austin Gonyou wrote: > > Thanks. I'll try it and see what happens. :) Are the latest patches > > available, or have they not been pulled from the cvs tree yet? >=20 > The 2.4.17 patches were updated yesterday or the day before; details are > in a previous email message from keith. >=20 > -Eric >=20 > --=20 > Eric Sandeen XFS for Linux http://oss.sgi.com/projects/xfs > sandeen@sgi.com SGI, Inc. --=20 Austin Gonyou Systems Architect, CCNA Coremetrics, Inc. Phone: 512-698-7250 email: austin@coremetrics.com "It is the part of a good shepherd to shear his flock, not to skin it." Latin Proverb --=-px1JL9whtKrPkj0/LhEg Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQA8UGtU94g6ZVmFMoIRAqr1AJ9TFviw1cnadSGt3vQUxmF2bmkXIACeM3oq FcdW2jGaKz8C9XAXWww0/Vs= =0a0F -----END PGP SIGNATURE----- --=-px1JL9whtKrPkj0/LhEg-- From owner-linux-xfs@oss.sgi.com Thu Jan 24 14:32:49 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0OMWnx29786 for linux-xfs-outgoing; Thu, 24 Jan 2002 14:32:49 -0800 Received: from UberGeek.coremetrics.com ([209.184.141.163]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0OMWXP29696 for ; Thu, 24 Jan 2002 14:32:33 -0800 Received: (from austin@localhost) by UberGeek.coremetrics.com (8.11.6/8.11.6) id g0OLVqs04006; Thu, 24 Jan 2002 15:31:52 -0600 X-Authentication-Warning: UberGeek.coremetrics.com: austin set sender to austin@coremetrics.com using -f Subject: Re: Memory Issues with 2.4.14-xfs From: Austin Gonyou To: Austin Gonyou Cc: Steve Lord , linux-xfs@oss.sgi.com In-Reply-To: <1011902453.30740.0.camel@UberGeek> References: <1011902453.30740.0.camel@UberGeek> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-W2p4WncDu0B7TFrGr5A4" X-Mailer: Evolution/1.0.1 Date: 24 Jan 2002 15:31:51 -0600 Message-Id: <1011907911.3954.8.camel@UberGeek> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 4450 Lines: 132 --=-W2p4WncDu0B7TFrGr5A4 Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Another thought around this too..could frame buffer devices cause this issue as well, or contribute to it? just curious. On Thu, 2002-01-24 at 14:00, Austin Gonyou wrote: > Thanks. I'll try it and see what happens. :) Are the latest patches > available, or have they not been pulled from the cvs tree yet? >=20 > Either way, I'll go look. :)=20 >=20 > On Thu, 2002-01-24 at 13:51, Steve Lord wrote: > > On Thu, 2002-01-24 at 13:41, Austin Gonyou wrote: > > > I'm having some pretty bad issues with memory being put into cache, > > and > > > then not being released. This is causing me to have lots of > networking > > > problems because my eepro100 keeps having issues and reporting "no > > > resources". When I get on the system locally, I can see that there > is > > a > > > large amount of swap in use, and almost all of the 8GB of ram I have > > is > > > in cache.=20 > > >=20 > > > My DBA's have been setting up an oracle instance on that server, but > > > they're running into problems because cached ram isn't being > released. > >=20 > > >=20 > > > I seem to recall something about this being fixed, but I don't > > remember > > > what kernel version, etc. Could someone lend a suggestion or two? > I'd > > > like to use 2.4.17, but I'm kind of put-off with all the data > > corruption > > > issues I've seen on the list lately. Is 2.4.17 ok to use with the > > > patches on oss.sgi.com/projects/xfs/downloads/patches? > >=20 > > The patches were updated yesterday, hopefully we have shot all the > > problems which emerged with 2.4.17 - they were not actually new > > problems, but something in 2.4.17 seemed to make them happen more. > >=20 > > Of the top of my head, major things which have been fixed are: > >=20 > > o a page leak which occurred under heavy memory load, someone who had > > reported this problem was able to run the dbench load which > > originally > > triggered it for several days non stop afterwards. This has been > > around > > since the new VM in 2.4.10. > >=20 > > o overwriting the start of a partition with file data, this has also > > been > > there for ever, I think it used to oops on the shutdown, something= =20 > > changed to remove the oops, and we wrote data instead. A few people > > who lost filesystems in the last year or so were probably seeing a > > variant of this. > >=20 > > o corruption of the emacs binary during the build process - this was > a > > memory mapped I/O under heavy memory pressure issue. This also has > > been present for a long time, it probably just took the right > > circumstances > > for someone to find it. > >=20 > > I cannot speak for people running athlon processors with DRI in the=20 > > kernel, looks like there is definitely a memory corruption issue on > that > > configuration which has the potential for having eaten a couple of > > filesystems. > >=20 > > We cannot really offer backports of individual fixes to specific > kernel > > versions, it is just too much work. Hopefully 2.4.17 is beaten into > > shape > > now and can be used without fear. > >=20 > > Steve > >=20 > >=20 > > > --=20 > > > Austin Gonyou > > > Systems Architect, CCNA > > > Coremetrics, Inc. > > > Phone: 512-698-7250 > > > email: austin@coremetrics.com > > >=20 > > > "It is the part of a good shepherd to shear his flock, not to skin > > it." > > > Latin Proverb > > --=20 > >=20 > > Steve Lord voice: +1-651-683-3511 > > Principal Engineer, Filesystem Software email: lord@sgi.com > --=20 > Austin Gonyou > Systems Architect, CCNA > Coremetrics, Inc. > Phone: 512-698-7250 > email: austin@coremetrics.com >=20 > "It is the part of a good shepherd to shear his flock, not to skin it." > Latin Proverb --=20 Austin Gonyou Systems Architect, CCNA Coremetrics, Inc. Phone: 512-698-7250 email: austin@coremetrics.com "It is the part of a good shepherd to shear his flock, not to skin it." Latin Proverb --=-W2p4WncDu0B7TFrGr5A4 Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQA8UH1H94g6ZVmFMoIRAsjkAJ9u3mI2dOcTK8pkIzGAiFeA7Lo+9QCg1wcd vtZO+qMD/+3AOc/h8mVInBE= =+hl2 -----END PGP SIGNATURE----- --=-W2p4WncDu0B7TFrGr5A4-- From owner-linux-xfs@oss.sgi.com Thu Jan 24 15:39:04 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0ONd4p14488 for linux-xfs-outgoing; Thu, 24 Jan 2002 15:39:04 -0800 Received: from UberGeek.coremetrics.com ([209.184.141.163]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0ONcsP14441 for ; Thu, 24 Jan 2002 15:38:54 -0800 Received: (from austin@localhost) by UberGeek.coremetrics.com (8.11.6/8.11.6) id g0OMcGB04316; Thu, 24 Jan 2002 16:38:16 -0600 X-Authentication-Warning: UberGeek.coremetrics.com: austin set sender to austin@coremetrics.com using -f Subject: [OT] best way to define SHMMAX in shm.h? From: Austin Gonyou To: linux-xfs@oss.sgi.com Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-wQ6xTtTPFnnVlBfxa8m6" X-Mailer: Evolution/1.0.1 Date: 24 Jan 2002 16:38:16 -0600 Message-Id: <1011911896.3953.12.camel@UberGeek> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 859 Lines: 34 --=-wQ6xTtTPFnnVlBfxa8m6 Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Any pointers on this? I just put the bytes, but by default, it is something in the form of 0x2000000(where this is 32MB I think?)=20 Thanks for the help. --=20 Austin Gonyou Systems Architect, CCNA Coremetrics, Inc. Phone: 512-698-7250 email: austin@coremetrics.com "It is the part of a good shepherd to shear his flock, not to skin it." Latin Proverb --=-wQ6xTtTPFnnVlBfxa8m6 Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQA8UIzY94g6ZVmFMoIRAjKHAJ9nMbo9Xa/wiGvjlBVnK8YpGuv7VACfZq0j Cimtd1l3pDkdbXzLKPQv5zk= =dXtr -----END PGP SIGNATURE----- --=-wQ6xTtTPFnnVlBfxa8m6-- From owner-linux-xfs@oss.sgi.com Thu Jan 24 16:28:20 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0P0SKH25323 for linux-xfs-outgoing; Thu, 24 Jan 2002 16:28:20 -0800 Received: from zok.sgi.com (zok.sgi.com [204.94.215.101]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0P0RxP25232 for ; Thu, 24 Jan 2002 16:27:59 -0800 Received: from zeus-e8.americas.sgi.com (zeus-e8.americas.sgi.com [128.162.8.103]) by zok.sgi.com (8.11.4/8.11.4/linux-outbound_gateway-1.1) with ESMTP id g0ONRqo08216 for ; Thu, 24 Jan 2002 15:27:52 -0800 Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by zeus-e8.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id RAA137801 for ; Thu, 24 Jan 2002 17:26:36 -0600 (CST) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id RAA50099 for ; Thu, 24 Jan 2002 17:26:36 -0600 (CST) From: Steve Lord Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id g0ONPRQ28454; Thu, 24 Jan 2002 17:25:27 -0600 Message-Id: <200201242325.g0ONPRQ28454@jen.americas.sgi.com> Date: Thu, 24 Jan 2002 17:25:27 -0600 Subject: TAKE - merge up to 2.5.3-pre5 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 6193 Lines: 173 Configure.help is dead, long like Config.help But in the meantime, the config tools cannot find help text. Steve Date: Thu Jan 24 15:23:21 PST 2002 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:110210a linux/drivers/media/video/Config.help - 1.1 linux/net/sched/Config.help - 1.1 linux/net/khttpd/Config.help - 1.1 linux/net/irda/irnet/Config.help - 1.1 linux/arch/alpha/Config.help - 1.1 linux/net/irda/irlan/Config.help - 1.1 linux/arch/arm/Config.help - 1.1 linux/net/irda/ircomm/Config.help - 1.1 linux/arch/cris/Config.help - 1.1 linux/net/irda/Config.help - 1.1 linux/arch/cris/drivers/Config.help - 1.1 linux/arch/i386/Config.help - 1.1 linux/net/ipx/Config.help - 1.1 linux/net/ipv6/netfilter/Config.help - 1.1 linux/net/ipv4/netfilter/Config.help - 1.1 linux/net/ipv4/Config.help - 1.1 linux/net/decnet/Config.help - 1.1 linux/net/bluetooth/Config.help - 1.1 linux/net/ax25/Config.help - 1.1 linux/arch/ia64/Config.help - 1.1 linux/net/Config.help - 1.1 linux/arch/m68k/Config.help - 1.1 linux/lib/Config.help - 1.1 linux/arch/mips/Config.help - 1.1 linux/init/Config.in - 1.1 linux/arch/mips64/Config.help - 1.1 linux/init/Config.help - 1.1 linux/arch/parisc/Config.help - 1.1 linux/fs/partitions/Config.help - 1.1 linux/arch/ppc/8260_io/Config.help - 1.1 linux/arch/ppc/8xx_io/Config.help - 1.1 linux/arch/ppc/Config.help - 1.1 linux/fs/nls/Config.help - 1.1 linux/arch/s390/Config.help - 1.1 linux/fs/ncpfs/Config.help - 1.1 linux/arch/s390x/Config.help - 1.1 linux/fs/Config.help - 1.1 linux/arch/sh/Config.help - 1.1 linux/drivers/zorro/Config.help - 1.1 linux/drivers/video/Config.help - 1.1 linux/drivers/usb/serial/Config.help - 1.1 linux/drivers/usb/hcd/Config.help - 1.1 linux/drivers/usb/Config.help - 1.1 linux/drivers/telephony/Config.help - 1.1 linux/drivers/sound/dmasound/Config.help - 1.1 linux/drivers/sound/Config.help - 1.1 linux/drivers/sgi/Config.help - 1.1 linux/drivers/scsi/pcmcia/Config.help - 1.1 linux/drivers/scsi/aic7xxx/Config.help - 1.1 linux/arch/sparc/Config.help - 1.1 linux/drivers/scsi/Config.help - 1.1 linux/arch/sparc64/Config.help - 1.1 linux/drivers/sbus/char/Config.help - 1.1 linux/drivers/acorn/block/Config.help - 1.1 linux/drivers/acorn/net/Config.help - 1.1 linux/drivers/acorn/scsi/Config.help - 1.1 linux/drivers/acpi/Config.help - 1.1 linux/drivers/atm/Config.help - 1.1 linux/drivers/block/Config.help - 1.1 linux/drivers/sbus/audio/Config.help - 1.1 linux/drivers/block/paride/Config.help - 1.1 linux/drivers/bluetooth/Config.help - 1.1 linux/drivers/cdrom/Config.help - 1.1 linux/drivers/char/Config.help - 1.1 linux/drivers/char/drm/Config.help - 1.1 linux/drivers/char/ftape/Config.help - 1.1 linux/drivers/char/joystick/Config.help - 1.1 linux/drivers/char/pcmcia/Config.help - 1.1 linux/drivers/s390/Config.help - 1.1 linux/drivers/fc4/Config.help - 1.1 linux/drivers/hotplug/Config.help - 1.1 linux/drivers/i2c/Config.help - 1.1 linux/drivers/ide/Config.help - 1.1 linux/drivers/ieee1394/Config.help - 1.1 linux/drivers/input/Config.help - 1.1 linux/drivers/isdn/Config.help - 1.1 linux/drivers/md/Config.help - 1.1 linux/drivers/media/Config.help - 1.1 linux/drivers/media/radio/Config.help - 1.1 linux/drivers/pnp/Config.help - 1.1 linux/drivers/message/fusion/Config.help - 1.1 linux/drivers/message/i2o/Config.help - 1.1 linux/drivers/mtd/Config.help - 1.1 linux/drivers/mtd/chips/Config.help - 1.1 linux/drivers/mtd/devices/Config.help - 1.1 linux/drivers/mtd/maps/Config.help - 1.1 linux/drivers/mtd/nand/Config.help - 1.1 linux/drivers/pcmcia/Config.help - 1.1 linux/drivers/pci/Config.help - 1.1 linux/drivers/net/Config.help - 1.1 linux/drivers/parport/Config.help - 1.1 linux/drivers/net/appletalk/Config.help - 1.1 linux/drivers/net/arcnet/Config.help - 1.1 linux/drivers/net/wireless/Config.help - 1.1 linux/drivers/net/wan/Config.help - 1.1 linux/drivers/net/hamradio/Config.help - 1.1 linux/drivers/net/irda/Config.help - 1.1 linux/drivers/net/mii.c - 1.1 linux/drivers/net/pcmcia/Config.help - 1.1 linux/drivers/net/tokenring/Config.help - 1.1 linux/scripts/Configure - 1.13 linux/include/asm-i386/page.h - 1.23 linux/drivers/video/clgenfb.c - 1.25 linux/drivers/pci/pci.c - 1.50 linux/drivers/net/cs89x0.c - 1.21 linux/drivers/net/Makefile - 1.51 linux/drivers/block/loop.c - 1.51 linux/arch/sparc64/config.in - 1.49 linux/arch/sparc/config.in - 1.33 linux/arch/ppc/config.in - 1.43 linux/arch/mips/config.in - 1.26 linux/arch/m68k/config.in - 1.25 linux/arch/i386/kernel/setup.c - 1.66 linux/arch/i386/defconfig - 1.93 linux/arch/i386/config.in - 1.71 linux/arch/i386/boot/setup.S - 1.25 linux/arch/arm/config.in - 1.32 linux/arch/alpha/config.in - 1.40 linux/Makefile - 1.179 linux/Documentation/Configure.help - 1.129 linux/Documentation/Changes - 1.44 linux/include/asm-i386/hw_irq.h - 1.22 linux/arch/i386/kernel/i8259.c - 1.25 linux/arch/sh/mm/fault.c - 1.20 linux/arch/sh/kernel/traps.c - 1.12 linux/arch/sh/kernel/signal.c - 1.13 linux/arch/sh/kernel/setup.c - 1.19 linux/arch/sh/kernel/process.c - 1.19 linux/arch/sh/kernel/irq.c - 1.14 linux/arch/sh/kernel/head.S - 1.9 linux/arch/sh/kernel/entry.S - 1.20 linux/arch/sh/config.in - 1.22 linux/include/asm-sh/processor.h - 1.17 linux/include/asm-sh/pgtable.h - 1.22 linux/include/asm-sh/mmu_context.h - 1.11 linux/arch/i386/kernel/smpboot.c - 1.30 linux/arch/i386/kernel/apic.c - 1.25 linux/arch/ia64/config.in - 1.22 linux/drivers/sound/via82cxxx_audio.c - 1.25 linux/drivers/net/8139too.c - 1.33 linux/arch/mips64/config.in - 1.17 linux/include/asm-sh/scatterlist.h - 1.3 linux/arch/sh/kernel/fpu.c - 1.5 linux/net/ipv4/netfilter/ipfwadm_core.c - 1.10 linux/arch/s390/config.in - 1.11 linux/Documentation/i386/boot.txt - 1.4 linux/drivers/net/sundance.c - 1.13 linux/arch/parisc/config.in - 1.4 linux/arch/sh/kernel/rtc.c - 1.5 linux/arch/cris/config.in - 1.10 linux/arch/s390x/config.in - 1.6 linux/drivers/net/fealnx.c - 1.10 linux/include/linux/mii.h - 1.4 linux/drivers/char/shwdt.c - 1.4 linux/drivers/net/8139cp.c - 1.5 linux/fs/driverfs/inode.c - 1.4 linux/kernel/device.c - 1.6 linux/include/linux/device.h - 1.4 From owner-linux-xfs@oss.sgi.com Thu Jan 24 16:56:53 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0P0uri31417 for linux-xfs-outgoing; Thu, 24 Jan 2002 16:56:53 -0800 Received: from localhost.localdomain (ip68-2-174-192.ph.ph.cox.net [68.2.174.192]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0P0unP31374 for ; Thu, 24 Jan 2002 16:56:49 -0800 Received: from localhost (gustavo@localhost) by localhost.localdomain (8.11.6/8.11.6) with ESMTP id g0ONuka24998 for ; Thu, 24 Jan 2002 16:56:46 -0700 X-Authentication-Warning: localhost.localdomain: gustavo owned process doing -bs Date: Thu, 24 Jan 2002 16:56:46 -0700 (MST) From: Gustavo Vegas X-X-Sender: gustavo@localhost.localdomain To: linux-xfs@oss.sgi.com Subject: Upgrade Question Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 499 Lines: 16 Hello, I am currently running a system loaded with the 1.0.2 XFS CD (RedHat 7.2). I would like to upgrade to the latest stable kernel and XFS facilities. I have looked around in your web site, and I do not see any specific instructions on how to do this; Should I just download the RPM packages available? Please let me know. Thanks, -- Gustavo Vegas P.S. the output of uname -a is, Linux thunder 2.4.9-13SGI_XFS_1.0.2 #1 Thu Nov 15 11:38:50 CST 2001 i686 unknown if this info might help. From owner-linux-xfs@oss.sgi.com Thu Jan 24 19:02:32 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0P32W625444 for linux-xfs-outgoing; Thu, 24 Jan 2002 19:02:32 -0800 Received: from sunny.pacific.net.au (sunny-legacy.pacific.net.au [210.23.129.40]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0P32RP25402 for ; Thu, 24 Jan 2002 19:02:28 -0800 Received: from wisma.pacific.net.au (wisma.pacific.net.au [210.23.129.72]) by sunny.pacific.net.au with ESMTP id g0P22L0Z022725; Fri, 25 Jan 2002 13:02:21 +1100 (EST) Received: from jpc.local (ppp228.dyn225.pacific.net.au [203.100.225.228]) by wisma.pacific.net.au with ESMTP id NAA12644; Fri, 25 Jan 2002 13:02:20 +1100 (EST) Received: (from jason@localhost) by jpc.local (8.9.3/8.9.3/Debian 8.9.3-21) id NAA00671; Fri, 25 Jan 2002 13:02:17 +1100 From: Jason White MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15440.48296.109229.561049@jpc.local> Date: Fri, 25 Jan 2002 13:02:16 +1100 To: Gustavo Vegas Cc: linux-xfs@oss.sgi.com Subject: Re: Upgrade Question In-Reply-To: References: X-Mailer: VM 6.76 under Emacs 20.7.2 Reply-To: jasonw@ariel.ucs.unimelb.edu.au Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 444 Lines: 9 There are details on the web site of the XFS kernel patches which you can obtain for recent kernels. Also, instructions for getting the latest stable kernel (currently 2.4.17) from SGI's CVS server are provided; this is what most subscribers to this list tend to do. If you are not experienced at kernel compilation I would suggest reading the kernel HOWTO and other relevant documents: see http://www.linuxdoc.org/ as a good starting point. From owner-linux-xfs@oss.sgi.com Thu Jan 24 19:20:29 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0P3KTj29341 for linux-xfs-outgoing; Thu, 24 Jan 2002 19:20:29 -0800 Received: from deliverator.sgi.com (deliverator.sgi.com [204.94.214.10]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0P3KLP29288 for ; Thu, 24 Jan 2002 19:20:22 -0800 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.55.149]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id SAA16888 for ; Thu, 24 Jan 2002 18:15:54 -0800 (PST) mail_from (nathans@snort.melbourne.sgi.com) Received: (from nathans@localhost) by snort.melbourne.sgi.com (SGI-8.9.3/8.9.3) id NAA59870 for linux-xfs@oss.sgi.com; Fri, 25 Jan 2002 13:18:59 +1100 (EST) Date: Fri, 25 Jan 2002 13:18:59 +1100 (EST) From: Nathan Scott Message-Id: <200201250218.NAA59870@snort.melbourne.sgi.com> To: linux-xfs@oss.sgi.com Subject: TAKE - write checks Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 913 Lines: 27 Date: Thu Jan 24 18:16:52 PST 2002 Workarea: snort.melbourne.sgi.com:/home/nathans/linux-xfs The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:110226b linux/fs/xfs/linux/xfs_file.c - 1.58 - a couple of additional checks are now made on the generic file write path which we didn't have in the XFS write code - add em, and make the function declarations consistent across the file. Modid: xfs-cmds:slinx:110226a cmd/xfsprogs/include/xfs_log.h - 1.4 cmd/xfsprogs/include/xfs_log_priv.h - 1.3 - sync with recent kernel header change. cmd/xfsprogs/include/xfs_fs.h - 1.11 cmd/xfsdump/doc/CHANGES - 1.32 cmd/xfsdump/common/fs.c - 1.2 - effectively no-op change (cleanup) - switch over to using XFS_IOC_FSGEOMETRY instead of XFS_IOC_GETFSUUID ioctl, so we can deprecate that "special" UUID ioctl at some point in the distant future. From owner-linux-xfs@oss.sgi.com Thu Jan 24 21:10:00 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0P5A0f19376 for linux-xfs-outgoing; Thu, 24 Jan 2002 21:10:00 -0800 Received: from sgi.com (sgi-too.SGI.COM [204.94.211.39]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0P59sP19338 for ; Thu, 24 Jan 2002 21:09:54 -0800 Received: from relay1.corp.sgi.com (corp.sgi.com [198.29.75.13]) by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id UAA05305 for ; Thu, 24 Jan 2002 20:09:42 -0800 (PST) mail_from (sandeen@sgi.com) Received: from chuckle.americas.sgi.com (sandeen@chuckle.americas.sgi.com [128.162.211.44]) by relay1.corp.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) via ESMTP id UAA52438; Thu, 24 Jan 2002 20:09:09 -0800 (PST) Date: Thu, 24 Jan 2002 22:09:08 -0600 (CST) From: Eric Sandeen X-X-Sender: To: Gustavo Vegas cc: Subject: Re: Upgrade Question In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 1099 Lines: 33 Hi Gustavo - The latest "official" stable kernel is what you have, 2.4.9/1.0.2. This is the last kernel package that has been through any sort of rigorous testing at SGI. As others have pointed out on the list, either a CVS update or getting the 2.4.17 snapshot patches from the patches/ directory is a way to get more recent code. This code has not been through rigorous testing, but it seems pretty stable at this point. However, if you require pre-packaged, binary, tested kernels, then you have the latest available. -Eric On Thu, 24 Jan 2002, Gustavo Vegas wrote: > Hello, > I am currently running a system loaded with the 1.0.2 XFS CD > (RedHat 7.2). I would like to upgrade to the latest stable kernel and XFS > facilities. I have looked around in your web site, and I do not see any > specific instructions on how to do this; Should I just download the RPM > packages available? Please let me know. > > Thanks, > > -- Gustavo Vegas > P.S. the output of uname -a is, > Linux thunder 2.4.9-13SGI_XFS_1.0.2 #1 Thu Nov 15 11:38:50 CST 2001 i686 > unknown > if this info might help. > > From owner-linux-xfs@oss.sgi.com Fri Jan 25 00:24:17 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0P8OHE26952 for linux-xfs-outgoing; Fri, 25 Jan 2002 00:24:17 -0800 Received: from relay.xlink.net (relay.xlink.net [193.141.40.4]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0P8OBP26915 for ; Fri, 25 Jan 2002 00:24:11 -0800 Received: from lizard.webland.de (lizard.webland.de [194.122.76.201]) by relay.xlink.net (8.9.3/8.8.7) with ESMTP id IAA14823; Fri, 25 Jan 2002 08:24:08 +0100 (MET) Received: (from uucp@localhost) by lizard.webland.de (8.8.8/8.8.7) id IAA22636; Fri, 25 Jan 2002 08:24:07 +0100 (MET) >Received: from mobile.sauter-bc.com (unknown [10.1.6.21]) by basel1.sauter-bc.com (Postfix) with ESMTP id 59CBC57306; Fri, 25 Jan 2002 08:23:10 +0100 (CET) Received: from ch.sauter-bc.com (support.cad.sba [10.1.200.117]) by mobile.sauter-bc.com (Postfix) with ESMTP id 1221C25835; Fri, 25 Jan 2002 08:23:10 +0100 (CET) Message-ID: <3C5107DE.FFD6F71F@ch.sauter-bc.com> Date: Fri, 25 Jan 2002 08:23:10 +0100 From: Simon Matter Organization: Sauter AG, Basel X-Mailer: Mozilla 4.77 [de] (X11; U; Linux 2.2.19-6.2.12 i686) X-Accept-Language: de-CH, en MIME-Version: 1.0 To: Matthijs van der Klip Cc: linux-xfs Subject: Re: New Kernel RPMs References: <35F87783B600D411A1430060943F469A589755@EXCHANGE> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 701 Lines: 26 > Matthijs van der Klip schrieb: > > > Sounds great. Would you mind sending your updated spec? > > This is the spec I'm using. I just took the RH spec and copied some > basic stuff from yours. I have not tested the resulting kernel yet, > but I will install the resulting RPM's later today or tomorrow. Hmm, I'm wondering how it works for you. Some things seems missing in your spec. -Simon > > Regards, > > Matthijs van der Klip > > > > Name: kernel-2.4.9-21-RH-xfs.spec > kernel-2.4.9-21-RH-xfs.spec Type: Ohne Angabe > (application/octet-stream) > Encoding: quoted-printable From owner-linux-xfs@oss.sgi.com Fri Jan 25 01:06:06 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0P966E03887 for linux-xfs-outgoing; Fri, 25 Jan 2002 01:06:06 -0800 Received: from minnie.omroep.nl (minnie.omroep.nl [145.58.30.4]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0P961P03851 for ; Fri, 25 Jan 2002 01:06:01 -0800 Received: (from smap@localhost) by minnie.omroep.nl (SGI-8.9.3/8.9.3) id JAA97763 for ; Fri, 25 Jan 2002 09:05:52 +0100 (CET) Received: from nos-smtp.nos.nl (145.58.12.125 "HELO nos-smtp.nos.nl") by minnie.omroep.nl with SMTP (smap v3.0 nederlandse publieke omroep) id xma1391617; Fri, 25 Jan 02 09:05:48 +0100 Received: FROM exchange.nos.nl BY nos-smtp.nos.nl ; Fri Jan 25 09:21:27 2002 +0100 Received: by EXCHANGE with Internet Mail Service (5.5.2650.21) id ; Fri, 25 Jan 2002 09:06:53 +0100 Message-ID: <35F87783B600D411A1430060943F469A58975A@EXCHANGE> From: Matthijs van der Klip To: "'Simon Matter'" , Eric Sandeen Cc: Matthijs van der Klip , linux-xfs Subject: RE: New Kernel RPMs Date: Fri, 25 Jan 2002 09:06:52 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Disposition: inline Content-Type: text/plain Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 301 Lines: 14 > Okay, the 7.1 seems to need few more changes. This is what I'm currently > building. I hope it will end up in something bootable. It _is_ 7.1 I built and the spec I sent is also for 7.1. Regards, Matthijs van der Klip Dutch Public Broadcasting Organisation [[HTML alternate version deleted]] From owner-linux-xfs@oss.sgi.com Fri Jan 25 01:20:06 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0P9K6i07155 for linux-xfs-outgoing; Fri, 25 Jan 2002 01:20:06 -0800 Received: from minnie.omroep.nl (minnie.omroep.nl [145.58.30.4]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0P9JsP07086 for ; Fri, 25 Jan 2002 01:19:55 -0800 Received: (from smap@localhost) by minnie.omroep.nl (SGI-8.9.3/8.9.3) id JAA87134 for ; Fri, 25 Jan 2002 09:19:43 +0100 (CET) Received: from nos-smtp.nos.nl (145.58.12.125 "HELO nos-smtp.nos.nl") by minnie.omroep.nl with SMTP (smap v3.0 nederlandse publieke omroep) id xma1402197; Fri, 25 Jan 02 09:19:39 +0100 Received: FROM exchange.nos.nl BY nos-smtp.nos.nl ; Fri Jan 25 09:35:18 2002 +0100 Received: by EXCHANGE with Internet Mail Service (5.5.2650.21) id ; Fri, 25 Jan 2002 09:20:44 +0100 Message-ID: <35F87783B600D411A1430060943F469A58975B@EXCHANGE> From: Matthijs van der Klip To: "'Simon Matter'" , Matthijs van der Klip Cc: linux-xfs Subject: RE: New Kernel RPMs Date: Fri, 25 Jan 2002 09:20:43 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Disposition: inline Content-Type: text/plain Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 567 Lines: 20 > Hmm, I'm wondering how it works for you. Some things seems missing in > your spec. I think you're right. I am not an rpm wizard at all (not even a developer :) I copied the xfs patches, put them in the spec but forgot to add lines so they would really be applied. So that's why it seemed so easy: the XFS patches have never been applied... :( If anyone else (with more rpm skills) manages to get a working version with XFS support, please let me know. Regards, Matthijs van der Klip Dutch Public Broadcasting Organisation [[HTML alternate version deleted]] From owner-linux-xfs@oss.sgi.com Fri Jan 25 02:28:27 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0PASRQ22056 for linux-xfs-outgoing; Fri, 25 Jan 2002 02:28:27 -0800 Received: from relay.xlink.net (relay.xlink.net [193.141.40.5]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0PASMP22011 for ; Fri, 25 Jan 2002 02:28:22 -0800 Received: from lizard.webland.de (lizard.webland.de [194.122.76.201]) by relay.xlink.net (8.9.3/8.8.7) with ESMTP id KAA13299; Fri, 25 Jan 2002 10:28:17 +0100 (MET) Received: (from uucp@localhost) by lizard.webland.de (8.8.8/8.8.7) id KAA04805; Fri, 25 Jan 2002 10:28:16 +0100 (MET) >Received: from mobile.sauter-bc.com (unknown [10.1.6.21]) by basel1.sauter-bc.com (Postfix) with ESMTP id 68C4057306; Fri, 25 Jan 2002 10:27:53 +0100 (CET) Received: from ch.sauter-bc.com (support.cad.sba [10.1.200.117]) by mobile.sauter-bc.com (Postfix) with ESMTP id 572E325835; Fri, 25 Jan 2002 10:27:53 +0100 (CET) Message-ID: <3C512519.4D0F52C8@ch.sauter-bc.com> Date: Fri, 25 Jan 2002 10:27:53 +0100 From: Simon Matter Organization: Sauter AG, Basel X-Mailer: Mozilla 4.77 [de] (X11; U; Linux 2.2.19-6.2.12 i686) X-Accept-Language: de-CH, en MIME-Version: 1.0 To: Matthijs van der Klip Cc: linux-xfs Subject: Re: New Kernel RPMs References: <35F87783B600D411A1430060943F469A58975B@EXCHANGE> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 1168 Lines: 32 Matthijs van der Klip schrieb: > > > Hmm, I'm wondering how it works for you. Some things seems missing in > > your spec. > > I think you're right. I am not an rpm wizard at all (not even a developer :) > I copied the xfs patches, put them in the spec but forgot to add lines so > they would really be applied. So that's why it seemed so easy: the XFS > patches have never been applied... :( Okay, I have successfully built the 7.1 RPMS and am now building for 7.2. I have not tested yet but I guess it should be okay. If the SGI people were interested I could upload the SRPMs somewhere since I have no space to make them available. BTW: What do the gurus say about compiling the 7.2 RPMS on a 7.1 system. Usually I like to build on the target system but my 7.2 is very slow. So will the 7.2 built on 7.1 be the same? since it is using the compat-* packages on both 7.1 and 7.2 I guess it should be okay but I'm not sure. > > If anyone else (with more rpm skills) manages to get a working version with > XFS support, please let me know. > > Regards, > > Matthijs van der Klip > Dutch Public Broadcasting Organisation > > [[HTML alternate version deleted]] From owner-linux-xfs@oss.sgi.com Fri Jan 25 04:42:25 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0PCgPH14864 for linux-xfs-outgoing; Fri, 25 Jan 2002 04:42:25 -0800 Received: from gk.hm.epigenomics.net (qmailr@gk.hm.epigenomics.net [212.121.137.90]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0PCgLP14834 for ; Fri, 25 Jan 2002 04:42:21 -0800 Received: (qmail 12875 invoked from network); 25 Jan 2002 11:42:04 -0000 Received: from raman.epigenomics.epi (qmailr@192.168.2.2) by salam.epigenomics.epi with SMTP; 25 Jan 2002 11:42:04 -0000 Received: (qmail 29583 invoked from network); 25 Jan 2002 11:41:59 -0000 Received: from broglie.epigenomics.epi (qmailr@192.168.1.5) by raman.epigenomics.epi with SMTP; 25 Jan 2002 11:41:59 -0000 Received: (qmail 29566 invoked by uid 9); 25 Jan 2002 11:41:59 -0000 From: Robert Sander Reply-To: Robert Sander X-Newsgroups: epi.ml.linux.xfs Subject: Re: Memory Issues with 2.4.14-xfs Date: Fri, 25 Jan 2002 11:41:59 +0000 (UTC) Organization: Epigenomics AG Message-ID: References: <1011901260.28034.7.camel@UberGeek> <1011901870.18897.10.camel@jen.americas.sgi.com> X-Complaints-To: usenet@epigenomics.com User-Agent: slrn/0.9.7.3 (Linux) To: linux-xfs@oss.sgi.com Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 736 Lines: 17 On Thu, 24 Jan 2002 19:54:14 +0000 (UTC), Steve Lord wrote: > I cannot speak for people running athlon processors with DRI in the > kernel, looks like there is definitely a memory corruption issue on that > configuration which has the potential for having eaten a couple of > filesystems. This could be the AMD Athlon CPU bug recently "discovered". Adding "mem=nopentium" to the kernel commandline should help. See also http://slashdot.org/article.pl?sid=02/01/24/1910227 Greetings -- Robert Sander Computer Scientist Epigenomics AG Bioinformatics R&D www.epigenomics.com Kastanienallee 24 +493024345330 10435 Berlin From owner-linux-xfs@oss.sgi.com Fri Jan 25 05:03:00 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0PD30Y19190 for linux-xfs-outgoing; Fri, 25 Jan 2002 05:03:00 -0800 Received: from UberGeek.coremetrics.com ([209.184.141.163]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0PD2pP19132 for ; Fri, 25 Jan 2002 05:02:51 -0800 Received: (from austin@localhost) by UberGeek.coremetrics.com (8.11.6/8.11.6) id g0PBxtG28984; Fri, 25 Jan 2002 05:59:55 -0600 X-Authentication-Warning: UberGeek.coremetrics.com: austin set sender to austin@coremetrics.com using -f Subject: Re: Memory Issues with 2.4.14-xfs From: Austin Gonyou To: Robert Sander Cc: linux-xfs@oss.sgi.com In-Reply-To: References: Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-tGUwZqOULWH9KBWdt2lJ" X-Mailer: Evolution/1.0.1 Date: 25 Jan 2002 05:59:55 -0600 Message-Id: <1011959995.28814.19.camel@UberGeek> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 1950 Lines: 56 --=-tGUwZqOULWH9KBWdt2lJ Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Unfortunately this is a specific issue which a patch and email I just sent out fixes. Andrea Arcangeli has a fix for this problem in that series, so I got a 2.4.17-RC2aa2 and patch worked a 2.4.17-xfs kernel into shape. Now I need some people to test and fix. If someone could do that I'd really really appreciate the help. I've been working with it all night. I'll be up as long as it takes. to fix this thing. On Fri, 2002-01-25 at 05:41, Robert Sander wrote: > On Thu, 24 Jan 2002 19:54:14 +0000 (UTC), > Steve Lord wrote: > > I cannot speak for people running athlon processors with DRI in the=20 > > kernel, looks like there is definitely a memory corruption issue on > that > > configuration which has the potential for having eaten a couple of > > filesystems. >=20 > This could be the AMD Athlon CPU bug recently "discovered". Adding > "mem=3Dnopentium" to the kernel commandline should help. > See also http://slashdot.org/article.pl?sid=3D02/01/24/1910227 >=20 > Greetings > --=20 > Robert Sander > Computer Scientist Epigenomics AG > Bioinformatics R&D www.epigenomics.com Kastanienallee 24 > +493024345330 10435 Berlin --=20 Austin Gonyou Systems Architect, CCNA Coremetrics, Inc. Phone: 512-698-7250 email: austin@coremetrics.com "It is the part of a good shepherd to shear his flock, not to skin it." Latin Proverb --=-tGUwZqOULWH9KBWdt2lJ Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQA8UUi794g6ZVmFMoIRAqmGAKDoRNO6W+Hy/wz4LgJToM8HVWEbcgCeNZV5 jagL1jd5BZM1frqEKvRQF5c= =jIvu -----END PGP SIGNATURE----- --=-tGUwZqOULWH9KBWdt2lJ-- From owner-linux-xfs@oss.sgi.com Fri Jan 25 06:41:00 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0PEf0f09438 for linux-xfs-outgoing; Fri, 25 Jan 2002 06:41:00 -0800 Received: from rj.sgi.com (rj.SGI.COM [204.94.215.100]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0PEetP09396 for ; Fri, 25 Jan 2002 06:40:55 -0800 Received: from zeus-e8.americas.sgi.com (zeus-e8.americas.sgi.com [128.162.8.103]) by rj.sgi.com (8.11.4/8.11.4/linux-outbound_gateway-1.1) with ESMTP id g0PDemY21918 for ; Fri, 25 Jan 2002 05:40:48 -0800 Received: from tulip-e185.americas.sgi.com (tulip-e185.americas.sgi.com [128.162.185.208]) by zeus-e8.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id HAA144451; Fri, 25 Jan 2002 07:39:33 -0600 (CST) Received: from sgi.com (Y7LjIQqVErDvTvInks98I1YtFyPo46cU@lord-h1.americas.sgi.com [206.11.101.42]) by tulip-e185.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.7) with ESMTP id HAA51769; Fri, 25 Jan 2002 07:39:32 -0600 (CST) Message-ID: <3C51601D.7040704@sgi.com> Date: Fri, 25 Jan 2002 07:39:41 -0600 From: Stephen Lord User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.7) Gecko/20011226 X-Accept-Language: en-us MIME-Version: 1.0 To: Austin Gonyou CC: Robert Sander , linux-xfs@oss.sgi.com Subject: Re: Memory Issues with 2.4.14-xfs References: <1011959995.28814.19.camel@UberGeek> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 950 Lines: 29 Austin Gonyou wrote: >Unfortunately this is a specific issue which a patch and email I just >sent out fixes. Andrea Arcangeli has a fix for this problem in that >series, so I got a 2.4.17-RC2aa2 and patch worked a 2.4.17-xfs kernel >into shape. Now I need some people to test and fix. If someone could do >that I'd really really appreciate the help. I've been working with it >all night. I'll be up as long as it takes. to fix this thing. > > Austin, your patch was too big for the list, it was bounced, 400000 bytes is as large as the list will allow. Also since this list goes out to over 700 people, it is probably best not to post something this large to the list, but to put it on an ftp site somewhere. I suspect your patch included a lot of stuff from XFS and Andrea, it is probably simpler to point people at the relevant patches and then add in your changes as a distinct patch on top of that. Steve p.s. it is still only Friday! From owner-linux-xfs@oss.sgi.com Fri Jan 25 07:07:29 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0PF7TM20161 for linux-xfs-outgoing; Fri, 25 Jan 2002 07:07:29 -0800 Received: from UberGeek.coremetrics.com ([209.184.141.163]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0PF7JP20108 for ; Fri, 25 Jan 2002 07:07:19 -0800 Received: (from austin@localhost) by UberGeek.coremetrics.com (8.11.6/8.11.6) id g0PE66601802; Fri, 25 Jan 2002 08:06:06 -0600 X-Authentication-Warning: UberGeek.coremetrics.com: austin set sender to austin@coremetrics.com using -f Subject: Re: Memory Issues with 2.4.14-xfs From: Austin Gonyou To: Stephen Lord Cc: Robert Sander , linux-xfs@oss.sgi.com In-Reply-To: <3C51601D.7040704@sgi.com> References: <3C51601D.7040704@sgi.com> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-D01xePpQngNNMtfJ384A" X-Mailer: Evolution/1.0.1 Date: 25 Jan 2002 08:06:05 -0600 Message-Id: <1011967566.1758.7.camel@UberGeek> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 1553 Lines: 62 --=-D01xePpQngNNMtfJ384A Content-Type: text/plain Content-Transfer-Encoding: quoted-printable I see. Sorry about that. The patch is available from http://www.digitalroadkill.net/Patches/2.4.17-xfs-aa.patch.bz2 I'm not sure how to split it out into just my changes right now..but I can do it later today.=20 On Fri, 2002-01-25 at 07:39, Stephen Lord wrote: > Austin, your patch was too big for the list, it was bounced, 400000 > bytes is > as large as the list will allow. Also since this list goes out to over=20 > 700 people, > it is probably best not to post something this large to the list, but to >=20 > put it on > an ftp site somewhere. >=20 > I suspect your patch included a lot of stuff from XFS and Andrea, it is= =20 > probably > simpler to point people at the relevant patches and then add in your=20 > changes as > a distinct patch on top of that. >=20 > Steve >=20 > p.s. it is still only Friday! Even in Germany? >=20 >=20 --=20 Austin Gonyou Systems Architect, CCNA Coremetrics, Inc. Phone: 512-698-7250 email: austin@coremetrics.com "It is the part of a good shepherd to shear his flock, not to skin it." Latin Proverb --=-D01xePpQngNNMtfJ384A Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQA8UWZN94g6ZVmFMoIRAvisAJ945tfoGi8TtHkrKBjAk6wVqD6pDACgq9Fb IqjVCt0j2TmMVlY3PK6kL4A= =4IWQ -----END PGP SIGNATURE----- --=-D01xePpQngNNMtfJ384A-- From owner-linux-xfs@oss.sgi.com Fri Jan 25 08:39:20 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0PGdKj31006 for linux-xfs-outgoing; Fri, 25 Jan 2002 08:39:20 -0800 Received: from uwast.astro.wisc.edu (uwast.astro.wisc.edu [144.92.179.130]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0PGd7P30811 for ; Fri, 25 Jan 2002 08:39:08 -0800 Received: from astro.wisc.edu (premo.astro.wisc.edu [144.92.179.236]) by uwast.astro.wisc.edu (8.12.1/8.12.1) with ESMTP id g0PFcx0I1725649 for ; Fri, 25 Jan 2002 09:39:00 -0600 (CST) Message-ID: <3C517C13.30602@astro.wisc.edu> Date: Fri, 25 Jan 2002 09:38:59 -0600 From: jansen User-Agent: Mozilla/5.0 (X11; U; Linux i586; en-US; rv:0.9.7) Gecko/20011226 X-Accept-Language: en-us MIME-Version: 1.0 To: linux-xfs@oss.sgi.com Subject: xfsdump/xfsrestore problem - unable to restore entire backup Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 4122 Lines: 107 Hi, I recently needed to restore some data from an old backup and ran into two problems. One problem was annoying but no big deal, the other is a real problem. First problem: I started an interactive restore from a linux machine using a remote tape drive hooked to an O2 using the session id, xfsrestore found the dump and gave the normal interactive command line. I found the file I wanted to restore and "add"ed it and then did "extract". xfsrestore then immediately returned with a status of SUCCESS after only having created the directories and not restoring the file I had selected. Second problem: I started a non-interactive xfsrestore session in the same way I did the above and it once again found the xfsdump session and it extracted a couple gigs of data before it gave this error: xfsrestore: restoring non-directory files xfsrestore: examining media file 1 xfsrestore: seeking past media file directory dump xfsrestore: drive_scsitape.c:1463: do_next_mark: Assertion `rechdrp->first_mark_ offset - rechdrp->file_offset <= ( off64_t )( contextp->dc_recsz )' failed. Aborted (core dumped) I also tried restoring this dump session directly from the O2 that has the tape drive and it also failed with a SEGV but without the assert error message (sorry I don't have the exact output). I had the same problem with an earlier backup of the same machine. I did the non-interactive restore above again with "-v drive=debug,media=debug" added to the command line and here is the last 30 or so lines of the debug output: xfsrestore: drive op: return read buf: sz 73728 (0x12000) xfsrestore: drive op: read: wanted 32 (0x20) xfsrestore: drive op: return read buf: sz 32 (0x20) xfsrestore: drive op: get mark xfsrestore: drive op: read: wanted 256 (0x100) xfsrestore: drive op: return read buf: sz 256 (0x100) xfsrestore: Media_end: pos==3 xfsrestore: drive op: end read xfsrestore: tape op: get status xfsrestore: tape status = fmk,wprot,onl xfsrestore: encountered EOF attempting to read record 8849 xfsrestore: Media_mfile_next: purp==2 pos==0 xfsrestore: drive op: begin read xfsrestore: tape op: get status xfsrestore: tape status = fmk,wprot,onl xfsrestore: tape op: reading 245760 bytes xfsrestore: validating media file header xfsrestore: media file header valid: media file ix 1 xfsrestore: examining media file 1 xfsrestore: file 1 in object 1 of stream 0 xfsrestore: file 10 in stream, file 1 of dump 0 on object xfsrestore: dump session label: "joe" xfsrestore: dump session id: a28f36fb-8d12-44a9-8df1-657ca2dc62af xfsrestore: stream 0, object 1, file 1 xfsrestore: drive op: read: wanted 131072 (0x20000) xfsrestore: tape op: reading 245760 bytes xfsrestore: tape op: reading 245760 bytes xfsrestore: drive op: return read buf: sz 4736 (0x1280) xfsrestore: drive op: read: wanted 126336 (0x1ed80) xfsrestore: tape op: get status xfsrestore: tape status = fmk,wprot,onl xfsrestore: encountered EOF attempting to read record 2 xfsrestore: using on-media session inventory xfsrestore: drive op: end read xfsrestore: drive op: get device class xfsrestore: drive op: eject media xfsrestore: tape op: closing drive The Linux machine is currently running the stock XFS 1.0.2 install with the (non-kernel) RedHat updates. The Linux machine was most likely running the XFS 1.0.1 version when it was backed up. The O2 is running IRIX 6.5.14m. The Linux machine is a VA Linux with (if I recall correctly) a TYAN Thunder 2500 motherboard, 3GB of SDRAM and Seagate disks on the integrated Symbios SCSI controllers. The tape drive is a four tape Seagate AIT jukebox. The backup that created this dump did not have any error messages but was split between two tapes. The command line I used to backup the drive is: /usr/sbin/xfsdump -l 0 -T -d 2048 -o -L joe -Y 7 -f guest@O2:/dev/rmt/tps2d6nrvc /dev/sdc1 The command line I used to do the interactive restore is: xfsrestore -i -S 87020d4e-4b28-4ddb-ab0a-54bd071d50c3 -f guest@O2:/dev/rmt/tps2d6nrvc . I have the xfsrestore core file if it is useful. I can supply any other information needed. Thanks for any assistance. -- ------- Stephan From owner-linux-xfs@oss.sgi.com Fri Jan 25 10:51:33 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0PIpXN26917 for linux-xfs-outgoing; Fri, 25 Jan 2002 10:51:33 -0800 Received: from zok.sgi.com (zok.sgi.com [204.94.215.101]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0PIpTP26878 for ; Fri, 25 Jan 2002 10:51:29 -0800 Received: from zeus-e8.americas.sgi.com (zeus-e8.americas.sgi.com [128.162.8.103]) by zok.sgi.com (8.11.4/8.11.4/linux-outbound_gateway-1.1) with ESMTP id g0PHpLo15453 for ; Fri, 25 Jan 2002 09:51:21 -0800 Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by zeus-e8.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id LAA147935 for ; Fri, 25 Jan 2002 11:50:06 -0600 (CST) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id LAA87499 for ; Fri, 25 Jan 2002 11:50:06 -0600 (CST) From: Steve Lord Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id g0PHmnQ00799; Fri, 25 Jan 2002 11:48:49 -0600 Message-Id: <200201251748.g0PHmnQ00799@jen.americas.sgi.com> Date: Fri, 25 Jan 2002 11:48:49 -0600 Subject: TAKE - make xfs use GFP_KERNEL in more places Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 824 Lines: 23 This adds information on if xfs is in a transaction or not, and if it is not, allows us to allocate with GFP_KERNEL. This improves the chances of not getting an error back from the memory allocator. Date: Fri Jan 25 09:47:08 PST 2002 Workarea: jen.americas.sgi.com:/src/lord/xfs-linux.2.4 The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:110277a linux/fs/xfs/xfs_trans.c - 1.125 - Maintain the current transaction in the current->journal_info pointer, this will allow us to always tell if code is being called from within a transaction or not. linux/fs/xfs_support/kmem.c - 1.18 - If there is no xfs transaction pointer in the journal_info field for the current task then it is safe to allocate memory using GFP_KERNEL rather than GFP_NOFS. From owner-linux-xfs@oss.sgi.com Fri Jan 25 14:06:34 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0PM6Yk32513 for linux-xfs-outgoing; Fri, 25 Jan 2002 14:06:34 -0800 Received: from hansol.gso.uri.edu (hansol.gso.uri.edu [131.128.102.140]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0PM6SP32475 for ; Fri, 25 Jan 2002 14:06:28 -0800 Received: from localhost (wchang@localhost) by hansol.gso.uri.edu (8.11.6/8.8.7) with ESMTP id g0PL6OT13504 for ; Fri, 25 Jan 2002 16:06:24 -0500 Date: Fri, 25 Jan 2002 16:06:24 -0500 (EST) From: Wonil Chang To: linux-xfs@oss.sgi.com Subject: Q: XFS Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 910 Lines: 24 Dear XFS experts, I successfully installed the XFS version of redhat 7.1 together with win98 on my laptop. I am very satisfied with XFS, because I don't have to worry about crashes, which hardly occur, unless I screw up. I formatted all the partitions in the XFS file system, including the root partition. In addition, I made a boot partition (also a XFS partition) separately. I have noticed two minor problems using XFS. 1. During booting time, right after the initial lilo screen, loading linux kernel (i.e., "LILO .......................") takes about 30 seconds. For comparison, when I used ext2 file system, it took a few seconds. What cause this and how can I resolve? 2. Compared to on ext2 and windows98, I could hear more frequent harddrive activities. Is it normal and is there any way to calm down the activities? If you can answer these questions, I'd appreciate it. Wonil From owner-linux-xfs@oss.sgi.com Fri Jan 25 15:17:14 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0PNHE115549 for linux-xfs-outgoing; Fri, 25 Jan 2002 15:17:14 -0800 Received: from relay.xlink.net (relay.xlink.net [193.141.40.4]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0PNHBP15519 for ; Fri, 25 Jan 2002 15:17:11 -0800 Received: from lizard.webland.de (lizard.webland.de [194.122.76.201]) by relay.xlink.net (8.9.3/8.8.7) with ESMTP id XAA15257 for ; Fri, 25 Jan 2002 23:17:08 +0100 (MET) Received: (from uucp@localhost) by lizard.webland.de (8.8.8/8.8.7) id XAA12204 for linux-xfs@oss.sgi.com; Fri, 25 Jan 2002 23:17:06 +0100 (MET) >Received: from mobile.sauter-bc.com (unknown [10.1.6.21]) by basel1.sauter-bc.com (Postfix) with ESMTP id 5D09B57306 for ; Fri, 25 Jan 2002 23:16:58 +0100 (CET) Received: from ch.sauter-bc.com (ppp02.cad.sba [10.1.249.2]) by mobile.sauter-bc.com (Postfix) with ESMTP id C5D5225835 for ; Fri, 25 Jan 2002 23:16:56 +0100 (CET) Message-ID: <3C51D958.B368AEB9@ch.sauter-bc.com> Date: Fri, 25 Jan 2002 23:16:56 +0100 From: Simon Matter X-Mailer: Mozilla 4.77 [de] (X11; U; Linux 2.2.19-6.2.12 i586) X-Accept-Language: en MIME-Version: 1.0 To: linux-xfs@oss.sgi.com Subject: New RPMs 2.4.9-21SGI_XFS_1.0.2 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by oss.sgi.com id g0PNHCP15523 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 275 Lines: 8 I have created new Kernel RPMS based on RedHat 2.4.9-21 with XFS patches. I have built RedHat 7.1 and 7.2 packages. I have tested the 7.2 and it seems to be fine. If anybody of the XFS maintainers is interested in the source RPM's then I could upload them somwhere. -Simon From owner-linux-xfs@oss.sgi.com Fri Jan 25 15:22:36 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0PNMai16757 for linux-xfs-outgoing; Fri, 25 Jan 2002 15:22:36 -0800 Received: from pneumatic-tube.sgi.com (pneumatic-tube.sgi.com [204.94.214.22]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0PNMXP16717 for ; Fri, 25 Jan 2002 15:22:33 -0800 Received: from zeus-e8.americas.sgi.com (zeus-e8.americas.sgi.com [128.162.8.103]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id OAA07361 for ; Fri, 25 Jan 2002 14:23:26 -0800 (PST) mail_from (lord@sgi.com) Received: from tulip-e185.americas.sgi.com (tulip-e185.americas.sgi.com [128.162.185.208]) by zeus-e8.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id QAA153032; Fri, 25 Jan 2002 16:21:12 -0600 (CST) Received: from sgi.com (S1NyYiHq9CAW0g30eXzMdBuzLbgLOjxC@lord-h1.americas.sgi.com [206.11.101.42]) by tulip-e185.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.7) with ESMTP id QAA87702; Fri, 25 Jan 2002 16:21:12 -0600 (CST) Message-ID: <3C51DA5D.3000209@sgi.com> Date: Fri, 25 Jan 2002 16:21:17 -0600 From: Stephen Lord User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.7) Gecko/20011226 X-Accept-Language: en-us MIME-Version: 1.0 To: Simon Matter CC: linux-xfs@oss.sgi.com Subject: Re: New RPMs 2.4.9-21SGI_XFS_1.0.2 References: <3C51D958.B368AEB9@ch.sauter-bc.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 398 Lines: 21 Simon Matter wrote: >I have created new Kernel RPMS based on RedHat 2.4.9-21 with XFS >patches. I have built RedHat 7.1 and 7.2 packages. I have tested the 7.2 >and it seems to be fine. >If anybody of the XFS maintainers is interested in the source RPM's then >I could upload them somwhere. > Thanks, I am sure Eric will be interested, he is out until Tuesday right now. Steve > > >-Simon > From owner-linux-xfs@oss.sgi.com Fri Jan 25 16:02:27 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0Q02Re24934 for linux-xfs-outgoing; Fri, 25 Jan 2002 16:02:27 -0800 Received: from deliverator.sgi.com (deliverator.sgi.com [204.94.214.10]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0Q02OP24902 for ; Fri, 25 Jan 2002 16:02:24 -0800 Received: from zeus-e8.americas.sgi.com (zeus-e8.americas.sgi.com [128.162.8.103]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id OAA16756 for ; Fri, 25 Jan 2002 14:57:58 -0800 (PST) mail_from (lord@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by zeus-e8.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id RAA153504 for ; Fri, 25 Jan 2002 17:01:04 -0600 (CST) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id RAA34289 for ; Fri, 25 Jan 2002 17:01:04 -0600 (CST) From: Steve Lord Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id g0PMxjv23762; Fri, 25 Jan 2002 16:59:45 -0600 Message-Id: <200201252259.g0PMxjv23762@jen.americas.sgi.com> Date: Fri, 25 Jan 2002 16:59:45 -0600 Subject: TAKE - fix xfs module build in 2.5 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 279 Lines: 12 Date: Fri Jan 25 14:56:50 PST 2002 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:110313a linux/fs/xfs/pagebuf/page_buf.c - 1.4 - Fix module build of xfs From owner-linux-xfs@oss.sgi.com Fri Jan 25 16:29:45 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0Q0Tj130403 for linux-xfs-outgoing; Fri, 25 Jan 2002 16:29:45 -0800 Received: from UberGeek.coremetrics.com ([209.184.141.163]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0Q0TRP30337 for ; Fri, 25 Jan 2002 16:29:27 -0800 Received: (from austin@localhost) by UberGeek.coremetrics.com (8.11.6/8.11.6) id g0PNSnM04447; Fri, 25 Jan 2002 17:28:49 -0600 X-Authentication-Warning: UberGeek.coremetrics.com: austin set sender to austin@coremetrics.com using -f Subject: -aa series compatibility From: Austin Gonyou To: linux-xfs@oss.sgi.com Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-VcqAgeI6oJXhRFQqmJIs" X-Mailer: Evolution/1.0.1 Date: 25 Jan 2002 17:28:49 -0600 Message-Id: <1012001329.4278.10.camel@UberGeek> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 2133 Lines: 59 --=-VcqAgeI6oJXhRFQqmJIs Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Given that I spent a lot of time getting a XFS enabled kernel merged with -aa series kernel, I'd like to ask if anyone else has tried out the -aa series without XFS? If so, and you have liked what you see/use/whatever, I'd like to ask SGI if there is a way to work-out between the XFS tree and -AA tree a possibly easier migration path.=20 I found a lot of things in the -AA patch I applied directly to a the most recent XFS patched 2.4.17 kernel was that many parts of the -AA patch that was rejected were in fact already in the XFS kernel to begin with.=20 The biggest point here is that there were only about 12 reject files. Some were very large >200 lines of replaced code(it was getting harry at that point lemme tell you), but for the most part I found that many of the VM functions which were changed were just that. Simple changes that make a function or set of functions within the code do things in a different order, rather than just raw rip-and-replace actions. So, is it possible to do anything around this? The main reason I ask is even though I'm not 100% sure I did everything 100% right, the kernel has performed very well from a stability/memory usage standpoint. It still uses a lot, but not ALL available RAM goes to cache now. This was causing my eepro100 to throw console messages(card reports no resources).=20 Problem was though, is it was all memory related. Now those problems have gone away.=20 --=20 Austin Gonyou Systems Architect, CCNA Coremetrics, Inc. Phone: 512-698-7250 email: austin@coremetrics.com "It is the part of a good shepherd to shear his flock, not to skin it." Latin Proverb --=-VcqAgeI6oJXhRFQqmJIs Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQA8Ueox94g6ZVmFMoIRAm3RAKCJNJlxWcCl/jL6k+ZZhJ5fenmBIQCbBV+J 56ZNi/RYTDZfwHrpEHAUqIg= =If/b -----END PGP SIGNATURE----- --=-VcqAgeI6oJXhRFQqmJIs-- From owner-linux-xfs@oss.sgi.com Fri Jan 25 16:35:32 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0Q0ZWk31550 for linux-xfs-outgoing; Fri, 25 Jan 2002 16:35:32 -0800 Received: from deliverator.sgi.com (deliverator.sgi.com [204.94.214.10]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0Q0ZQP31514 for ; Fri, 25 Jan 2002 16:35:26 -0800 Received: from zeus-e8.americas.sgi.com (zeus-e8.americas.sgi.com [128.162.8.103]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id PAA27497 for ; Fri, 25 Jan 2002 15:31:00 -0800 (PST) mail_from (lord@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by zeus-e8.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id RAA152122 for ; Fri, 25 Jan 2002 17:34:06 -0600 (CST) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id RAA42575 for ; Fri, 25 Jan 2002 17:34:06 -0600 (CST) From: Steve Lord Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id g0PNWlX24479; Fri, 25 Jan 2002 17:32:47 -0600 Message-Id: <200201252332.g0PNWlX24479@jen.americas.sgi.com> Date: Fri, 25 Jan 2002 17:32:47 -0600 Subject: TAKE - use new inode allocation methods for xfs Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 1195 Lines: 41 Take xfs info out of the inode structure and switch to the new mechanism. Date: Fri Jan 25 15:31:26 PST 2002 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:110319a linux/include/linux/fs.h - 1.145 - Remove xfs inode info from inode structure linux/fs/inode.c - 1.64 - No longer need to pass gfp flags into icreate and friends for xfs, new inode allocate methods take care of this. linux/fs/xfs/xfsidbg.c - 1.171 linux/fs/xfs/xfs_rw.c - 1.352 linux/fs/xfs/xfs_vnodeops.c - 1.515 linux/fs/xfs/xfs_vfsops.c - 1.333 linux/fs/xfs/xfs_iget.c - 1.149 linux/fs/xfs/xfs_inode.c - 1.325 linux/fs/xfs/linux/xfs_lrw.c - 1.121 linux/fs/xfs/linux/xfs_linux.h - 1.61 linux/fs/xfs/linux/xfs_vnode.c - 1.70 linux/fs/xfs/linux/xfs_fs_subr.c - 1.28 linux/fs/xfs/linux/xfs_super.c - 1.158 linux/fs/xfs/linux/xfs_iops.c - 1.120 - vnode/inode layout and allocation changed linux/include/linux/xfs_fs_i.h - 1.7 - remove this file linux/include/linux/vnode.h - 1.5 linux/fs/xfs/linux/xfs_vnode.h - 1.25 linux/fs/xfs_dmapi/xfsjunk.c - 1.2 - vnode/inode layout and allocation changed From owner-linux-xfs@oss.sgi.com Fri Jan 25 17:08:13 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0Q18DE04419 for linux-xfs-outgoing; Fri, 25 Jan 2002 17:08:13 -0800 Received: from sgi.com (sgi-too.SGI.COM [204.94.211.39]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0Q188P04387 for ; Fri, 25 Jan 2002 17:08:08 -0800 Received: from imnetworks.com (mail2.imnetworks.com [208.184.122.59]) by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via SMTP id QAA01803 for ; Fri, 25 Jan 2002 16:08:05 -0800 (PST) mail_from (tvickers@imnetworks.com) Received: from [66.123.14.2] (HELO tonylaptop.imnetworks.com) by imnetworks.com (CommuniGate Pro SMTP 3.4.7) with ESMTP id 1497163 for linux-xfs@oss.sgi.com; Fri, 25 Jan 2002 16:08:01 -0800 Message-Id: <5.1.0.14.0.20020125155858.052a6b40@mail2.imnetworks.com> X-Sender: tvickers@mail2.imnetworks.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Fri, 25 Jan 2002 16:06:33 -0800 To: linux-xfs@oss.sgi.com From: Tony Vickers Subject: Ks.cfg and XFS Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 894 Lines: 28 I have a kickstart file (ks.cfg) that works just fine for ext2 or ext3, when making partitions on the hard drive. I have just moved over to using XFS as the main file system of choice and now I get KeyError: xfs. All I did was change /var from ext3 to xfs. Is there a fix for this? part / --size 1000 --fstype ext3 --ondisk=hda part /boot --size 500 --fstype ext3 --ondisk=hda part /usr --size 2000 --fstype ext3 --grow --ondisk=hda part /var --size 1500 --fstype xfs --ondisk=hda part swap --size 1000 --ondisk=hda Tony Tony Vickers Unix-Linux Systems Administrator (oo) iM Networks Inc. Work - 650.230.0449 / \/ \ 305 West Evelyn Ave. Cell - 650.580.3542 /( )\ Mountain View, CA 94041 Fax - 650.967.3924 ~^--^~ http://www.imnetworks.com The Linux revolution has started! From owner-linux-xfs@oss.sgi.com Fri Jan 25 17:12:39 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0Q1CdZ05285 for linux-xfs-outgoing; Fri, 25 Jan 2002 17:12:39 -0800 Received: from UberGeek.coremetrics.com ([209.184.141.163]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0Q1CUP05232 for ; Fri, 25 Jan 2002 17:12:30 -0800 Received: (from austin@localhost) by UberGeek.coremetrics.com (8.11.6/8.11.6) id g0Q0BQh05719; Fri, 25 Jan 2002 18:11:26 -0600 X-Authentication-Warning: UberGeek.coremetrics.com: austin set sender to austin@coremetrics.com using -f Subject: Re: Ks.cfg and XFS From: Austin Gonyou To: Tony Vickers Cc: linux-xfs@oss.sgi.com In-Reply-To: <5.1.0.14.0.20020125155858.052a6b40@mail2.imnetworks.com> References: <5.1.0.14.0.20020125155858.052a6b40@mail2.imnetworks.com> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-6KsatYdr6TjhIT9s1Csd" X-Mailer: Evolution/1.0.1 Date: 25 Jan 2002 18:11:26 -0600 Message-Id: <1012003886.4278.12.camel@UberGeek> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 1804 Lines: 63 --=-6KsatYdr6TjhIT9s1Csd Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Sounds like the kickstart doesn't know about xfs.=20 my $0.02 On Fri, 2002-01-25 at 18:06, Tony Vickers wrote: > I have a kickstart file (ks.cfg) that works just fine for ext2 or ext3,= =20 > when making partitions on the hard drive. I have just moved over to > using=20 > XFS as the main file system of choice and now I get KeyError: xfs. All I >=20 > did was change /var from ext3 to xfs. Is there a fix for this? >=20 > part / --size 1000 --fstype ext3 --ondisk=3Dhda > part /boot --size 500 --fstype ext3 --ondisk=3Dhda > part /usr --size 2000 --fstype ext3 --grow --ondisk=3Dhda > part /var --size 1500 --fstype xfs --ondisk=3Dhda > part swap --size 1000 --ondisk=3Dhda >=20 >=20 >=20 >=20 > Tony >=20 > Tony Vickers > Unix-Linux Systems Administrator > (oo) iM Networks Inc. Work - 650.230.0449 > / \/ \ 305 West Evelyn Ave. Cell - 650.580.3542 > /( )\ Mountain View, CA 94041 Fax - 650.967.3924 > ~^--^~ http://www.imnetworks.com > The Linux revolution has started! >=20 >=20 >=20 >=20 --=20 Austin Gonyou Systems Architect, CCNA Coremetrics, Inc. Phone: 512-698-7250 email: austin@coremetrics.com "It is the part of a good shepherd to shear his flock, not to skin it." Latin Proverb --=-6KsatYdr6TjhIT9s1Csd Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQA8UfQu94g6ZVmFMoIRAtiuAKC5khUW4pODJr0Ci58rn8bOaw26gwCfe6bJ xIpyoPps3xr8hMUkbG3FD3U= =J6GE -----END PGP SIGNATURE----- --=-6KsatYdr6TjhIT9s1Csd-- From owner-linux-xfs@oss.sgi.com Fri Jan 25 17:55:18 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0Q1tI912229 for linux-xfs-outgoing; Fri, 25 Jan 2002 17:55:18 -0800 Received: from smtpzilla3.xs4all.nl (smtpzilla3.xs4all.nl [194.109.127.139]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0Q1tEP12190 for ; Fri, 25 Jan 2002 17:55:14 -0800 Received: from auto-nb1.xs4all.nl (qn-212-58-167-191.quicknet.nl [212.58.167.191]) by smtpzilla3.xs4all.nl (8.12.0/8.12.0) with ESMTP id g0Q0tATN015628 for ; Sat, 26 Jan 2002 01:55:10 +0100 (CET) Message-Id: <4.3.2.7.2.20020126014818.02ac9098@pop.xs4all.nl> X-Sender: knuffie@pop.xs4all.nl X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Sat, 26 Jan 2002 01:53:42 +0100 To: Linux XFS List From: Seth Mos Subject: Journaling filesystems article Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 469 Lines: 20 Hi, The BulmaLUG has a nice article explaining some differences and gives some information about XFS in general. A short intro can be found on linuxtoday.com http://linuxtoday.com/news_story.php3?ltsn=2002-01-25-014-20-RV The article itself can be found here http://bulmalug.net/body.phtml?nIdNoticia=1154 It's a nice read at 1 AM. Cheers -- Seth Every program has two purposes one for which it was written and another for which it wasn't I use the last kind. From owner-linux-xfs@oss.sgi.com Fri Jan 25 19:46:19 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0Q3kJo30321 for linux-xfs-outgoing; Fri, 25 Jan 2002 19:46:19 -0800 Received: from deliverator.sgi.com (deliverator.sgi.com [204.94.214.10]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0Q3kEP30285 for ; Fri, 25 Jan 2002 19:46:14 -0800 Received: from zeus-e8.americas.sgi.com (zeus-e8.americas.sgi.com [128.162.8.103]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id SAA19533 for ; Fri, 25 Jan 2002 18:41:46 -0800 (PST) mail_from (lord@sgi.com) Received: from tulip-e185.americas.sgi.com (tulip-e185.americas.sgi.com [128.162.185.208]) by zeus-e8.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id UAA155411; Fri, 25 Jan 2002 20:43:20 -0600 (CST) Received: from sgi.com (HtW6ed/zItZLm3nBBvaq9jidTd2bGilO@lord-h1.americas.sgi.com [206.11.101.42]) by tulip-e185.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.7) with ESMTP id UAA86380; Fri, 25 Jan 2002 20:43:20 -0600 (CST) Message-ID: <3C5217CB.9030908@sgi.com> Date: Fri, 25 Jan 2002 20:43:23 -0600 From: Stephen Lord User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.7) Gecko/20011226 X-Accept-Language: en-us MIME-Version: 1.0 To: Tony Vickers CC: linux-xfs@oss.sgi.com Subject: Re: Ks.cfg and XFS References: <5.1.0.14.0.20020125155858.052a6b40@mail2.imnetworks.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 1093 Lines: 37 Tony Vickers wrote: > I have a kickstart file (ks.cfg) that works just fine for ext2 or > ext3, when making partitions on the hard drive. I have just moved > over to using XFS as the main file system of choice and now I get > KeyError: xfs. All I did was change /var from ext3 to xfs. Is there a > fix for this? > > part / --size 1000 --fstype ext3 --ondisk=hda > part /boot --size 500 --fstype ext3 --ondisk=hda > part /usr --size 2000 --fstype ext3 --grow --ondisk=hda > part /var --size 1500 --fstype xfs --ondisk=hda > part swap --size 1000 --ondisk=hda > > > > > Tony > > Tony Vickers > Unix-Linux Systems Administrator > (oo) iM Networks Inc. Work - 650.230.0449 > / \/ \ 305 West Evelyn Ave. Cell - 650.580.3542 > /( )\ Mountain View, CA 94041 Fax - 650.967.3924 > ~^--^~ http://www.imnetworks.com > The Linux revolution has started! > > > > Eric understands the kickstart stuff, but he is gone until Tuesday, it is possible to use it with XFS, but that is all I know. Steve From owner-linux-xfs@oss.sgi.com Fri Jan 25 19:52:44 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0Q3qi931476 for linux-xfs-outgoing; Fri, 25 Jan 2002 19:52:44 -0800 Received: from sgi.com (sgi-too.SGI.COM [204.94.211.39]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0Q3qeP31446 for ; Fri, 25 Jan 2002 19:52:40 -0800 Received: from relay1.corp.sgi.com (corp.sgi.com [198.29.75.13]) by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id SAA07387 for ; Fri, 25 Jan 2002 18:52:38 -0800 (PST) mail_from (sandeen@sgi.com) Received: from chuckle.americas.sgi.com (sandeen@chuckle.americas.sgi.com [128.162.211.44]) by relay1.corp.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) via ESMTP id SAA69813; Fri, 25 Jan 2002 18:52:06 -0800 (PST) Date: Fri, 25 Jan 2002 20:52:04 -0600 (CST) From: Eric Sandeen X-X-Sender: To: Simon Matter cc: Subject: Re: New RPMs 2.4.9-21SGI_XFS_1.0.2 In-Reply-To: <3C51D958.B368AEB9@ch.sauter-bc.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 602 Lines: 20 Hi Simon, great! If you can put them somewhere I can get to them, I'll give them a quick sanity check (next week) and put them in a contributed/ directory on oss. If you don't have a server that can handle a pounding, you might just reply to me in private. :) -Eric On Fri, 25 Jan 2002, Simon Matter wrote: > I have created new Kernel RPMS based on RedHat 2.4.9-21 with XFS > patches. I have built RedHat 7.1 and 7.2 packages. I have tested the 7.2 > and it seems to be fine. > If anybody of the XFS maintainers is interested in the source RPM's then > I could upload them somwhere. > > -Simon > From owner-linux-xfs@oss.sgi.com Fri Jan 25 19:58:47 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0Q3wl432651 for linux-xfs-outgoing; Fri, 25 Jan 2002 19:58:47 -0800 Received: from zok.sgi.com (zok.sgi.com [204.94.215.101]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0Q3whP32616 for ; Fri, 25 Jan 2002 19:58:43 -0800 Received: from relay1.corp.sgi.com (spindle.corp.sgi.com [198.29.75.13]) by zok.sgi.com (8.11.4/8.11.4/linux-outbound_gateway-1.1) with ESMTP id g0Q2wao32644 for ; Fri, 25 Jan 2002 18:58:36 -0800 Received: from chuckle.americas.sgi.com (sandeen@chuckle.americas.sgi.com [128.162.211.44]) by relay1.corp.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) via ESMTP id SAA49256; Fri, 25 Jan 2002 18:58:02 -0800 (PST) Date: Fri, 25 Jan 2002 20:58:01 -0600 (CST) From: Eric Sandeen X-X-Sender: To: Austin Gonyou cc: Subject: Re: -aa series compatibility In-Reply-To: <1012001329.4278.10.camel@UberGeek> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 926 Lines: 24 On 25 Jan 2002, Austin Gonyou wrote: > Given that I spent a lot of time getting a XFS enabled kernel merged > with -aa series kernel, I'd like to ask if anyone else has tried out the > -aa series without XFS? If so, and you have liked what you > see/use/whatever, I'd like to ask SGI if there is a way to work-out > between the XFS tree and -AA tree a possibly easier migration path. Austin - Rather than just applying the patch directly and dealing with the rejects, you might try the "mergetrees" tool to do this, you just do: mergetrees linux-aa/ linux-linus/ linux-xfs/ linux-aa-xfs/ and it will merge your aa tree with the xfs tree and produce an aa-xfs tree ("linux-aa,", "linux-linus,", and "linux-xfs" are all the same base kernel - say, 2.4.17 - with the -aa or -xfs (or no) patches.) You'll get a list of conflicts, and the conflicts are marked _in_ the source files, making it much easier to resolve. -Eric From owner-linux-xfs@oss.sgi.com Fri Jan 25 20:01:58 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0Q41wQ00941 for linux-xfs-outgoing; Fri, 25 Jan 2002 20:01:58 -0800 Received: from zok.sgi.com (zok.sgi.com [204.94.215.101]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0Q41sP00908 for ; Fri, 25 Jan 2002 20:01:54 -0800 Received: from relay1.corp.sgi.com (spindle.corp.sgi.com [198.29.75.13]) by zok.sgi.com (8.11.4/8.11.4/linux-outbound_gateway-1.1) with ESMTP id g0Q31lo00304 for ; Fri, 25 Jan 2002 19:01:47 -0800 Received: from chuckle.americas.sgi.com (sandeen@chuckle.americas.sgi.com [128.162.211.44]) by relay1.corp.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) via ESMTP id TAA33799; Fri, 25 Jan 2002 19:01:15 -0800 (PST) Date: Fri, 25 Jan 2002 21:01:14 -0600 (CST) From: Eric Sandeen X-X-Sender: To: Stephen Lord cc: Tony Vickers , Subject: Re: Ks.cfg and XFS In-Reply-To: <3C5217CB.9030908@sgi.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 720 Lines: 25 Obvious questions first... are you using the xfs installer? Are you sure? If you're using a network install source, make sure you copy the XFS CDROM files last, overwriting any Red Hat files. -Eric On Fri, 25 Jan 2002, Stephen Lord wrote: > Tony Vickers wrote: > > > I have a kickstart file (ks.cfg) that works just fine for ext2 or > > ext3, when making partitions on the hard drive. I have just moved > > over to using XFS as the main file system of choice and now I get > > KeyError: xfs. All I did was change /var from ext3 to xfs. Is there a > > fix for this? > Eric understands the kickstart stuff, but he is gone until Tuesday, > it is possible to use it with XFS, but that is all I know. > > Steve > > > From owner-linux-xfs@oss.sgi.com Fri Jan 25 20:03:05 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0Q435x01240 for linux-xfs-outgoing; Fri, 25 Jan 2002 20:03:05 -0800 Received: from deliverator.sgi.com (deliverator.sgi.com [204.94.214.10]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0Q430P01206 for ; Fri, 25 Jan 2002 20:03:00 -0800 Received: from zeus-e8.americas.sgi.com (zeus-e8.americas.sgi.com [128.162.8.103]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id SAA21077 for ; Fri, 25 Jan 2002 18:58:35 -0800 (PST) mail_from (lord@sgi.com) Received: from tulip-e185.americas.sgi.com (tulip-e185.americas.sgi.com [128.162.185.208]) by zeus-e8.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id VAA155331; Fri, 25 Jan 2002 21:01:40 -0600 (CST) Received: from sgi.com (cMcBzyn/llxauurZ8BqsO5yBqJQiEGic@lord-h1.americas.sgi.com [206.11.101.42]) by tulip-e185.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.7) with ESMTP id VAA94359; Fri, 25 Jan 2002 21:01:40 -0600 (CST) Message-ID: <3C521C17.9030108@sgi.com> Date: Fri, 25 Jan 2002 21:01:43 -0600 From: Stephen Lord User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.7) Gecko/20011226 X-Accept-Language: en-us MIME-Version: 1.0 To: Austin Gonyou CC: linux-xfs@oss.sgi.com Subject: Re: -aa series compatibility References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 1043 Lines: 35 Eric Sandeen wrote: >On 25 Jan 2002, Austin Gonyou wrote: > >>Given that I spent a lot of time getting a XFS enabled kernel merged >>with -aa series kernel, I'd like to ask if anyone else has tried out the >>-aa series without XFS? If so, and you have liked what you >>see/use/whatever, I'd like to ask SGI if there is a way to work-out >>between the XFS tree and -AA tree a possibly easier migration path. >> > >Austin - > >Rather than just applying the patch directly and dealing with the rejects, >you might try the "mergetrees" tool to do this, you just do: > >mergetrees linux-aa/ linux-linus/ linux-xfs/ linux-aa-xfs/ > >and it will merge your aa tree with the xfs tree and produce an aa-xfs >tree ("linux-aa,", "linux-linus,", and "linux-xfs" are all the same base >kernel - say, 2.4.17 - with the -aa or -xfs (or no) patches.) > >You'll get a list of conflicts, and the conflicts are marked _in_ the >source files, making it much easier to resolve. > >-Eric > Mergetrees comes from here: http://cvs.bofh.asn.au/mergetrees/ Steve From owner-linux-xfs@oss.sgi.com Fri Jan 25 20:26:00 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0Q4Q0t05346 for linux-xfs-outgoing; Fri, 25 Jan 2002 20:26:00 -0800 Received: from smtp013.mail.yahoo.com (smtp013.mail.yahoo.com [216.136.173.57]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0Q4PvP05312 for ; Fri, 25 Jan 2002 20:25:57 -0800 Received: from aegis.cs.princeton.edu (HELO divine) (128.112.152.6) by smtp.mail.vip.sc5.yahoo.com with SMTP; 26 Jan 2002 03:25:55 -0000 Message-ID: <001901c1a619$22df0940$906a7080@divine> From: "Zhifeng F. Chen" To: Subject: NFS and XFS Date: Fri, 25 Jan 2002 22:25:42 -0500 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.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 501 Lines: 17 Hi, In NFS-HOWTO: "... as of this writing, ext3 (ftp://ftp.uk.linux.org/pub/linux/sct/fs/jfs/) was the only journalling filesystem that worked correctly with NFS version 3, but no doubt that will change soon. In particular, it looks like Reiserfs should work with NFS version 3 on 2.4 kernels, ... " Could anyone tell me if XFS works correctly with NFS ? Zhifeng _________________________________________________________ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com From owner-linux-xfs@oss.sgi.com Fri Jan 25 20:30:46 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0Q4Ukb06236 for linux-xfs-outgoing; Fri, 25 Jan 2002 20:30:46 -0800 Received: from zok.sgi.com (zok.sgi.com [204.94.215.101]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0Q4UgP06206 for ; Fri, 25 Jan 2002 20:30:43 -0800 Received: from zeus-e8.americas.sgi.com (zeus-e8.americas.sgi.com [128.162.8.103]) by zok.sgi.com (8.11.4/8.11.4/linux-outbound_gateway-1.1) with ESMTP id g0Q3UZo01414 for ; Fri, 25 Jan 2002 19:30:35 -0800 Received: from tulip-e185.americas.sgi.com (tulip-e185.americas.sgi.com [128.162.185.208]) by zeus-e8.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id VAA155480; Fri, 25 Jan 2002 21:29:19 -0600 (CST) Received: from sgi.com (cJ7ZCO/znuKOyC+cpT+9jEI0YO289G4E@lord-h1.americas.sgi.com [206.11.101.42]) by tulip-e185.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.7) with ESMTP id VAA95923; Fri, 25 Jan 2002 21:29:19 -0600 (CST) Message-ID: <3C522292.9090902@sgi.com> Date: Fri, 25 Jan 2002 21:29:22 -0600 From: Stephen Lord User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.7) Gecko/20011226 X-Accept-Language: en-us MIME-Version: 1.0 To: "Zhifeng F. Chen" CC: linux-xfs@oss.sgi.com Subject: Re: NFS and XFS References: <001901c1a619$22df0940$906a7080@divine> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 468 Lines: 20 Zhifeng F. Chen wrote: >Hi, > >In NFS-HOWTO: "... as of this writing, ext3 >(ftp://ftp.uk.linux.org/pub/linux/sct/fs/jfs/) was the only journalling >filesystem that worked correctly with NFS version 3, but no doubt that will >change soon. In particular, it looks like Reiserfs should work with NFS >version 3 on 2.4 kernels, ... " Could anyone tell me if XFS works correctly >with NFS ? > Works just fine, and has done for quite a while, NFS V2 and V3. Steve From owner-linux-xfs@oss.sgi.com Fri Jan 25 21:06:04 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0Q564t12174 for linux-xfs-outgoing; Fri, 25 Jan 2002 21:06:04 -0800 Received: from sgi.com (sgi-too.SGI.COM [204.94.211.39]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0Q560P12144 for ; Fri, 25 Jan 2002 21:06:01 -0800 Received: from zeus-e8.americas.sgi.com (zeus-e8.americas.sgi.com [128.162.8.103]) by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id UAA07258 for ; Fri, 25 Jan 2002 20:05:47 -0800 (PST) mail_from (lord@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by zeus-e8.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id WAA156259 for ; Fri, 25 Jan 2002 22:04:32 -0600 (CST) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id WAA35078 for ; Fri, 25 Jan 2002 22:04:32 -0600 (CST) From: Steve Lord Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id g0Q43Bn01735; Fri, 25 Jan 2002 22:03:11 -0600 Message-Id: <200201260403.g0Q43Bn01735@jen.americas.sgi.com> Date: Fri, 25 Jan 2002 22:03:11 -0600 Subject: TAKE - remove extra call from pagebuf daemon startup Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 393 Lines: 16 Date: Fri Jan 25 20:02:47 PST 2002 Workarea: jen.americas.sgi.com:/src/lord/xfs-linux.2.4 Author: lord Merged by: lord Merged mods: 2.5.x-xfs:slinx:110313a The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:110313a linux/fs/xfs/pagebuf/page_buf.c - 1.5 - Merge of 2.5.x-xfs:slinx:110313a by lord. Fix module build of xfs From owner-linux-xfs@oss.sgi.com Fri Jan 25 22:00:46 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0Q60k021594 for linux-xfs-outgoing; Fri, 25 Jan 2002 22:00:46 -0800 Received: from rj.sgi.com (rj.SGI.COM [204.94.215.100]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0Q60eP21554 for ; Fri, 25 Jan 2002 22:00:40 -0800 Received: from zeus-e8.americas.sgi.com (zeus-e8.americas.sgi.com [128.162.8.103]) by rj.sgi.com (8.11.4/8.11.4/linux-outbound_gateway-1.1) with ESMTP id g0Q50WY05074 for ; Fri, 25 Jan 2002 21:00:32 -0800 Received: from tulip-e185.americas.sgi.com (tulip-e185.americas.sgi.com [128.162.185.208]) by zeus-e8.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id WAA156326 for ; Fri, 25 Jan 2002 22:59:17 -0600 (CST) Received: from sgi.com (D022hzY9XRE3LYA05MiE2XPfe57SM8Nf@lord-h1.americas.sgi.com [206.11.101.42]) by tulip-e185.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.7) with ESMTP id WAA99255 for ; Fri, 25 Jan 2002 22:59:17 -0600 (CST) Message-ID: <3C5237A7.4060507@sgi.com> Date: Fri, 25 Jan 2002 22:59:19 -0600 From: Stephen Lord User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.7) Gecko/20011226 X-Accept-Language: en-us MIME-Version: 1.0 To: linux-xfs@oss.sgi.com Subject: Problem with recent checkin Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 959 Lines: 31 The change made to use the journal_info field has problems on systems which use a mix of ext3 and xfs. If ext3 needs to allocate memory and ends up going into xfs which does a transaction, then ext3 gets trampled on by the xfs code. I am backing this code out until a safer version can be implemented. So there is a window where recent cvs kernel will cause problems if you mix the two filesystem types. The 2.5 tree has the same code in it. This was the offending code: Modid: 2.4.x-xfs:slinx:110277a linux/fs/xfs/xfs_trans.c - 1.125 - Maintain the current transaction in the current->journal_info pointer, this will allow us to always tell if code is being called from within a transaction or not. linux/fs/xfs_support/kmem.c - 1.18 - If there is no xfs transaction pointer in the journal_info field for the current task then it is safe to allocate memory using GFP_KERNEL rather than GFP_NOFS. Which went in this morning. Steve From owner-linux-xfs@oss.sgi.com Fri Jan 25 22:01:32 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0Q61Wm21877 for linux-xfs-outgoing; Fri, 25 Jan 2002 22:01:32 -0800 Received: from rj.sgi.com (rj.SGI.COM [204.94.215.100]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0Q61TP21851 for ; Fri, 25 Jan 2002 22:01:29 -0800 Received: from zeus-e8.americas.sgi.com (zeus-e8.americas.sgi.com [128.162.8.103]) by rj.sgi.com (8.11.4/8.11.4/linux-outbound_gateway-1.1) with ESMTP id g0Q51MY05120 for ; Fri, 25 Jan 2002 21:01:22 -0800 Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by zeus-e8.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id XAA156559 for ; Fri, 25 Jan 2002 23:00:06 -0600 (CST) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id XAA27109 for ; Fri, 25 Jan 2002 23:00:06 -0600 (CST) From: Steve Lord Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id g0Q4wjt07291; Fri, 25 Jan 2002 22:58:45 -0600 Message-Id: <200201260458.g0Q4wjt07291@jen.americas.sgi.com> Date: Fri, 25 Jan 2002 22:58:45 -0600 Subject: TAKE - backout memory allocation change Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 362 Lines: 14 Causes problems when you mix ext3 and xfs. Date: Fri Jan 25 20:58:11 PST 2002 Workarea: jen.americas.sgi.com:/src/lord/xfs-linux.2.4 Undoes mod: 2.4.x-xfs:slinx:110277a The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:110332a linux/fs/xfs/xfs_trans.c - 1.126 linux/fs/xfs_support/kmem.c - 1.19 From owner-linux-xfs@oss.sgi.com Fri Jan 25 22:34:03 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0Q6Y3U27508 for linux-xfs-outgoing; Fri, 25 Jan 2002 22:34:03 -0800 Received: from imnetworks.com (mail2.imnetworks.com [208.184.122.59]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0Q6XvP27466 for ; Fri, 25 Jan 2002 22:33:57 -0800 Received: from [66.123.14.2] (HELO tonylaptop.imnetworks.com) by imnetworks.com (CommuniGate Pro SMTP 3.4.7) with ESMTP id 1497315; Fri, 25 Jan 2002 21:33:58 -0800 Message-Id: <5.1.0.14.0.20020125205820.0281a8c8@mail2.imnetworks.com> X-Sender: tvickers@mail2.imnetworks.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Fri, 25 Jan 2002 21:19:11 -0800 To: Eric Sandeen , Stephen Lord From: Tony Vickers Subject: Re: Ks.cfg and XFS Cc: Tony Vickers , In-Reply-To: References: <3C5217CB.9030908@sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 1374 Lines: 45 I had to reinstall the build system. So I used SGI's XFS installer along with RH 7.2's disc #1,#2. So Yes I do have the full XFS stuff. As far as coping the XFS CD-ROM files last how can you make sure this happens? I looked at the Rev number on the XFS files and they are newer. So if I were to assume that the system is smart to use the latest file would I be right? Is it also possible that I got by chance a ISO file when I downloaded it from SGI? This is off topic, but, is there a doc on how to make the same type of BOOT CD that SGI uses? -Tony At 09:01 PM 1/25/2002 -0600, Eric Sandeen wrote: >Obvious questions first... are you using the xfs installer? > >Are you sure? If you're using a network install source, make sure you >copy the XFS CDROM files last, overwriting any Red Hat files. > >-Eric > >On Fri, 25 Jan 2002, Stephen Lord wrote: > > > Tony Vickers wrote: > > > > > I have a kickstart file (ks.cfg) that works just fine for ext2 or > > > ext3, when making partitions on the hard drive. I have just moved > > > over to using XFS as the main file system of choice and now I get > > > KeyError: xfs. All I did was change /var from ext3 to xfs. Is there a > > > fix for this? > > > Eric understands the kickstart stuff, but he is gone until Tuesday, > > it is possible to use it with XFS, but that is all I know. > > > > Steve > > > > > > From owner-linux-xfs@oss.sgi.com Sat Jan 26 02:03:34 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0QA3Yl28418 for linux-xfs-outgoing; Sat, 26 Jan 2002 02:03:34 -0800 Received: from ahriman.bucharest.roedu.net (ahriman.bucharest.roedu.net [141.85.128.71]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0QA3SP28377 for ; Sat, 26 Jan 2002 02:03:28 -0800 Received: (qmail 4321 invoked by uid 1000); 26 Jan 2002 09:08:29 -0000 Received: from localhost (sendmail-bs@127.0.0.1) by localhost with SMTP; 26 Jan 2002 09:08:29 -0000 Date: Sat, 26 Jan 2002 11:08:29 +0200 (EET) From: Mihai RUSU X-X-Sender: To: Florin Andrei cc: Subject: Re: XFS and TUX In-Reply-To: <1011901576.8711.18.camel@stantz.corp.sgi.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 1442 Lines: 38 On 24 Jan 2002, Florin Andrei wrote: > Heh, ok, i got it. :-) > > I was actually thinking of the ENO mirror server, linux-dist.corp, who's > been installed long time ago, never been really used, and now is in > process of being revamped (to make it really useful). TUX looks like a > good choice to serve the HTTP part of it. > > Ok, i'll wait for you guys to release the XFS kernel updates and then > i'll apply them to the mirror server. > Hi Florin last time ive asked Ingo about this he told me that you can get the last XFS_RedHat kernel merge and just replace the tux related files with the new ones. it didnt worked for me for xfs 1.0.2 2.4.9-13 and TUX patch 2.4.16-C9. Ingo also told me to try patch the linus tree with last XFS linus patch and apply the TUX patch on it. that worked for me (at least at the time 2.4.16 was latest linus, TUX was 2.4.16-C9) ive tried/tested the first option, to upgrade the TUX version from 2.4.9-13SGI_XFS_1.0.2custom . i wanted a stable/tested XFS release to base on. i received some errors on compiling. i had to port some functions introduced in later kernels but the kernel i got wasnt stable (it didnt crashed without tux compiled but it crashed in 2 hours of testing with tux compiled , even that i didnt enabled it) you could try the second option or wait for the last redhat kernel xfs merge :) ---------------------------- Mihai RUSU "... and what if this is as good as it gets ?" From owner-linux-xfs@oss.sgi.com Sat Jan 26 05:23:35 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0QDNZT25176 for linux-xfs-outgoing; Sat, 26 Jan 2002 05:23:35 -0800 Received: from smtpzilla5.xs4all.nl (smtpzilla5.xs4all.nl [194.109.127.141]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0QDNVP25135 for ; Sat, 26 Jan 2002 05:23:31 -0800 Received: from auto-nb1.xs4all.nl (qn-212-58-167-191.quicknet.nl [212.58.167.191]) by smtpzilla5.xs4all.nl (8.12.0/8.12.0) with ESMTP id g0QCNRYX081180; Sat, 26 Jan 2002 13:23:27 +0100 (CET) Message-Id: <4.3.2.7.2.20020126132119.02c514c8@pop.xs4all.nl> X-Sender: knuffie@pop.xs4all.nl X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Sat, 26 Jan 2002 13:21:57 +0100 To: "Zhifeng F. Chen" , From: Seth Mos Subject: Re: NFS and XFS In-Reply-To: <001901c1a619$22df0940$906a7080@divine> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 598 Lines: 19 At 22:25 25-1-2002 -0500, Zhifeng F. Chen wrote: >Hi, > >In NFS-HOWTO: "... as of this writing, ext3 >(ftp://ftp.uk.linux.org/pub/linux/sct/fs/jfs/) was the only journalling >filesystem that worked correctly with NFS version 3, but no doubt that will >change soon. In particular, it looks like Reiserfs should work with NFS >version 3 on 2.4 kernels, ... " Could anyone tell me if XFS works correctly >with NFS ? Yes. I have 4 servers using NFS on top of a XFS filesystem. -- Seth Every program has two purposes one for which it was written and another for which it wasn't I use the last kind. From owner-linux-xfs@oss.sgi.com Sat Jan 26 05:39:08 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0QDd8G27353 for linux-xfs-outgoing; Sat, 26 Jan 2002 05:39:08 -0800 Received: from smtpzilla5.xs4all.nl (smtpzilla5.xs4all.nl [194.109.127.141]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0QDd2P27318 for ; Sat, 26 Jan 2002 05:39:03 -0800 Received: from auto-nb1.xs4all.nl (qn-212-58-167-191.quicknet.nl [212.58.167.191]) by smtpzilla5.xs4all.nl (8.12.0/8.12.0) with ESMTP id g0QCcruM083034; Sat, 26 Jan 2002 13:38:55 +0100 (CET) Message-Id: <4.3.2.7.2.20020126132345.02c62470@pop.xs4all.nl> X-Sender: knuffie@pop.xs4all.nl X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Sat, 26 Jan 2002 13:37:24 +0100 To: Tony Vickers From: Seth Mos Subject: Re: Ks.cfg and XFS Cc: Tony Vickers , In-Reply-To: <5.1.0.14.0.20020125205820.0281a8c8@mail2.imnetworks.com> References: <3C5217CB.9030908@sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 1287 Lines: 32 At 21:19 25-1-2002 -0800, Tony Vickers wrote: >I had to reinstall the build system. So I used SGI's XFS installer along >with RH 7.2's disc #1,#2. So Yes I do have the full XFS stuff. As far as >coping the XFS CD-ROM files last how can you make sure this happens? I >looked at the Rev number on the XFS files and they are newer. So if I were >to assume that the system is smart to use the latest file would I be >right? Is it also possible that I got by chance a ISO file when I >downloaded it from SGI? Last file copied wins. Copy the XFS installer CDROM to that directory last. The following order would be correct RH CD1, RH CD2, XFS installer. >This is off topic, but, is there a doc on how to make the same type of >BOOT CD that SGI uses? Good question but maybe someone has a small howto on doing that sort of thing. The reiserfs folks made a lot of adapted Red Hat installer over the years and I guess most information is available for building your own installer is available. I could find some info on the linuxdoc site with regard to modifying a installer. Myabe this is of help. http://www.linuxdoc.org/HOWTO/KickStart-HOWTO.html Cheers -- Seth Every program has two purposes one for which it was written and another for which it wasn't I use the last kind. From owner-linux-xfs@oss.sgi.com Sat Jan 26 06:36:17 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0QEaHw03028 for linux-xfs-outgoing; Sat, 26 Jan 2002 06:36:17 -0800 Received: from pneumatic-tube.sgi.com (pneumatic-tube.sgi.com [204.94.214.22]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0QEaDP02994 for ; Sat, 26 Jan 2002 06:36:13 -0800 Received: from zeus-e8.americas.sgi.com (zeus-e8.americas.sgi.com [128.162.8.103]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id FAA03065 for ; Sat, 26 Jan 2002 05:37:08 -0800 (PST) mail_from (lord@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by zeus-e8.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id HAA160962 for ; Sat, 26 Jan 2002 07:34:54 -0600 (CST) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id HAA13451 for ; Sat, 26 Jan 2002 07:34:54 -0600 (CST) From: Steve Lord Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id g0QDXT810420; Sat, 26 Jan 2002 07:33:29 -0600 Message-Id: <200201261333.g0QDXT810420@jen.americas.sgi.com> Date: Sat, 26 Jan 2002 07:33:29 -0600 Subject: TAKE - remove a function xfs added to filemap.c Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 615 Lines: 21 There is now a function in the regular kernel which does what we need, so use it instead of our own and reduce the xfs footprint in the mainline kernel code. Date: Sat Jan 26 05:32:00 PST 2002 Workarea: jen.americas.sgi.com:/src/lord/xfs-linux.2.4 The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:110335a linux/mm/filemap.c - 1.104 linux/kernel/ksyms.c - 1.123 linux/include/linux/pagemap.h - 1.38 - Remove find_get_page_simple linux/fs/xfs/pagebuf/page_buf_io.c - 1.4 - Remove find_get_page_simple, there is an official function for this now. From owner-linux-xfs@oss.sgi.com Sat Jan 26 06:58:59 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0QEwxq06349 for linux-xfs-outgoing; Sat, 26 Jan 2002 06:58:59 -0800 Received: from ADSL-Bergs.RZ.RWTH-Aachen.DE (adsl-bergs.rz.RWTH-Aachen.DE [137.226.80.218]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0QEwsP06312 for ; Sat, 26 Jan 2002 06:58:54 -0800 Received: from [192.168.1.2] (helo=ralf) by ADSL-Bergs.RZ.RWTH-Aachen.DE with smtp (Exim 3.12 #1) id 16UTLx-000773-00; Sat, 26 Jan 2002 14:58:45 +0100 From: "Ralf G. R. Bergs" To: "Linux XFS Mailing List" Cc: "Steve Lord" Date: Sat, 26 Jan 2002 14:58:45 +0100 Reply-To: "Ralf G. R. Bergs" X-Mailer: PMMail 2000 Professional (2.20.2380) For Windows 2000 (5.0.2195;2) In-Reply-To: <200201261333.g0QDXT810420@jen.americas.sgi.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Subject: Reduce XFS footprint (was Re: TAKE - remove a function xfs added to filemap.c Message-Id: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 854 Lines: 22 On Sat, 26 Jan 2002 07:33:29 -0600, Steve Lord wrote: >There is now a function in the regular kernel which does what >we need, so use it instead of our own and reduce the xfs footprint >in the mainline kernel code. Apropos -- is it possible to reduce the XFS footprint (as a module) by throwing in some magic compiler options? I already compile it without debugging option, still it's about 500K in size. Of course I do realize XFS is an extremely powerful (and therefore non-trivial) filesystem but if I remember correctly reiser is only 200K in size. Thanks! -- Verkaufe Original-BMW-Raeder: L I N U X .~. http://adsl-bergs.rz.rwth-aachen.de/~rabe The Choice /V\ of a GNU /( )\ Generation ^^-^^ From owner-linux-xfs@oss.sgi.com Sat Jan 26 09:40:56 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0QHeu732498 for linux-xfs-outgoing; Sat, 26 Jan 2002 09:40:56 -0800 Received: from yog-sothoth.sgi.com (eugate.sgi.com [192.48.160.10]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0QHenP32457 for ; Sat, 26 Jan 2002 09:40:49 -0800 Received: from zeus-e8.americas.sgi.com (zeus-e8.americas.sgi.com [128.162.8.103]) by yog-sothoth.sgi.com (980305.SGI.8.8.8-aspam-6.2/980304.SGI-aspam-europe) via ESMTP id RAA904501 for ; Sat, 26 Jan 2002 17:40:26 +0100 (CET) mail_from (lord@sgi.com) Received: from tulip-e185.americas.sgi.com (tulip-e185.americas.sgi.com [128.162.185.208]) by zeus-e8.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id KAA162423; Sat, 26 Jan 2002 10:39:28 -0600 (CST) Received: from sgi.com (3KldNlyp+LPr/DR/uM8ieHQ9NQw0ar3T@lord-h1.americas.sgi.com [206.11.101.42]) by tulip-e185.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.7) with ESMTP id KAA21537; Sat, 26 Jan 2002 10:39:27 -0600 (CST) Message-ID: <3C52DBBC.2060500@sgi.com> Date: Sat, 26 Jan 2002 10:39:24 -0600 From: Stephen Lord User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.7) Gecko/20011226 X-Accept-Language: en-us MIME-Version: 1.0 To: "Ralf G. R. Bergs" CC: Linux XFS Mailing List Subject: Re: Reduce XFS footprint (was Re: TAKE - remove a function xfs added to filemap.c References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 1419 Lines: 45 Ralf G. R. Bergs wrote: >On Sat, 26 Jan 2002 07:33:29 -0600, Steve Lord wrote: > >>There is now a function in the regular kernel which does what >>we need, so use it instead of our own and reduce the xfs footprint >>in the mainline kernel code. >> > >Apropos -- is it possible to reduce the XFS footprint (as a module) by throwing >in some magic compiler options? I already compile it without debugging option, >still it's about 500K in size. Of course I do realize XFS is an extremely >powerful (and therefore non-trivial) filesystem but if I remember correctly >reiser is only 200K in size. > >Thanks! > > If you turn off quotas, posix acls, dmapi and realtime (you probably already did these) then it gets a bit smaller. There are definitely other code paths you cannot get to in there which we could cut out - just a matter of finding them. You could try editing xfs_types.h and changing #define XFS_BIG_FILES 1 #define XFS_BIG_FILESYSTEMS 1 to #define XFS_BIG_FILES 0 #define XFS_BIG_FILESYSTEMS 0 There is no guarantee this will even build on linux to be honest though. XFS's idea of not supporting BIG_FILES is still large by linux standards I think. This will get rid of a lot of 64 bit math, but I suspect the places where we had to work around 64 bit divides and modulo operations will break. From what I hear, gcc is not known for optimizing code for size. Steve From owner-linux-xfs@oss.sgi.com Sat Jan 26 09:55:12 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0QHtCS02661 for linux-xfs-outgoing; Sat, 26 Jan 2002 09:55:12 -0800 Received: from ADSL-Bergs.RZ.RWTH-Aachen.DE (adsl-bergs.rz.RWTH-Aachen.DE [137.226.80.218]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0QHt4P02624 for ; Sat, 26 Jan 2002 09:55:05 -0800 Received: from [192.168.1.2] (helo=ralf) by ADSL-Bergs.RZ.RWTH-Aachen.DE with smtp (Exim 3.12 #1) id 16UW6R-0007K6-00; Sat, 26 Jan 2002 17:54:55 +0100 From: "Ralf G. R. Bergs" To: "Linux XFS Mailing List" Cc: "Stephen Lord" Date: Sat, 26 Jan 2002 17:54:55 +0100 Reply-To: "Ralf G. R. Bergs" X-Mailer: PMMail 2000 Professional (2.20.2380) For Windows 2000 (5.0.2195;2) In-Reply-To: <3C52DBBC.2060500@sgi.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Subject: Re: Reduce XFS footprint (was Re: TAKE - remove a function xfs added to filemap.c Message-Id: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 1882 Lines: 56 On Sat, 26 Jan 2002 10:39:24 -0600, Stephen Lord wrote: [...] >>Apropos -- is it possible to reduce the XFS footprint (as a module) by throwing >>in some magic compiler options? I already compile it without debugging option, >>still it's about 500K in size. Of course I do realize XFS is an extremely >>powerful (and therefore non-trivial) filesystem but if I remember correctly >>reiser is only 200K in size. >> >If you turn off quotas, posix acls, dmapi and realtime (you probably >already did these) I need quotas and ACLs, so I cannot turn'em off. I HAVE turned off DMAPI and realtime support, tho. >then it gets a bit smaller. There are definitely other code paths you >cannot get to in there >which we could cut out - just a matter of finding them. That reminds me of another question I'm asking myself since a while: It seems as if you're developing XFS for Linux from scratch instead of "just" porting it from SGI. Is that right? Or why do you seem to change even fundamental code pieces? Or does porting to Linux mean you have to rewrite it because it's so different from IRIX? >You could try editing xfs_types.h and changing > >#define XFS_BIG_FILES 1 >#define XFS_BIG_FILESYSTEMS 1 > >to > >#define XFS_BIG_FILES 0 >#define XFS_BIG_FILESYSTEMS 0 I probably can't do that since as you know I use hardware RAIDs so I probably need "big" filesystems, and I also need "big" files. > From what I hear, gcc is not known for optimizing code for size. Hehehe, this is what I also hear sometimes. ;-) Thanks, and keep up the good work!! Ralf -- Verkaufe Original-BMW-Raeder: L I N U X .~. http://adsl-bergs.rz.rwth-aachen.de/~rabe The Choice /V\ of a GNU /( )\ Generation ^^-^^ From owner-linux-xfs@oss.sgi.com Sat Jan 26 10:15:31 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0QIFVt05851 for linux-xfs-outgoing; Sat, 26 Jan 2002 10:15:31 -0800 Received: from www.fortuitous.com (cs6625128-203.austin.rr.com [66.25.128.203]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0QIFSP05829 for ; Sat, 26 Jan 2002 10:15:29 -0800 Received: by www.fortuitous.com (Postfix, from userid 500) id 763412D1; Sat, 26 Jan 2002 11:13:31 -0600 (CST) Date: Sat, 26 Jan 2002 11:13:31 -0600 From: pac@fortuitous.com To: linux-xfs@oss.sgi.com Subject: How to create a separate log Message-ID: <20020126111331.A5571@bistro.marx> Reply-To: pac@fortuitous.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.23i Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 555 Lines: 14 What do i need to do to create a separate log file? Does the log live in a partition unto itself or can I make a log file on another filesystem that has other data in it? Is there a document that describes in detail how this goes? -Phil Carinhas -- .--------------------------------------------------------. | Dr. Philip A. Carinhas | pac@fortuitous.com | | Fortuitous Technologies Inc. | http://fortuitous.com | | Linux Consulting & Training | Tel : 1-512-467-2154 | `--------------------------------------------------------' From owner-linux-xfs@oss.sgi.com Sat Jan 26 10:54:13 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0QIsDc10991 for linux-xfs-outgoing; Sat, 26 Jan 2002 10:54:13 -0800 Received: from smtpzilla2.xs4all.nl (smtpzilla2.xs4all.nl [194.109.127.138]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0QIs8P10969 for ; Sat, 26 Jan 2002 10:54:09 -0800 Received: from auto-nb1.xs4all.nl (qn-212-58-167-191.quicknet.nl [212.58.167.191]) by smtpzilla2.xs4all.nl (8.12.0/8.12.0) with ESMTP id g0QHs2Ed032771; Sat, 26 Jan 2002 18:54:02 +0100 (CET) Message-Id: <4.3.2.7.2.20020126184721.034f2338@pop.xs4all.nl> X-Sender: knuffie@pop.xs4all.nl X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Sat, 26 Jan 2002 18:52:30 +0100 To: "Ralf G. R. Bergs" , "Linux XFS Mailing List" From: Seth Mos Subject: Re: Reduce XFS footprint (was Re: TAKE - remove a function xfs added to filemap.c Cc: "Stephen Lord" In-Reply-To: References: <3C52DBBC.2060500@sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 1122 Lines: 29 At 17:54 26-1-2002 +0100, Ralf G. R. Bergs wrote: >That reminds me of another question I'm asking myself since a while: It seems >as if you're developing XFS for Linux from scratch instead of "just" porting >it from SGI. Is that right? Or why do you seem to change even fundamental >code >pieces? Or does porting to Linux mean you have to rewrite it because it's so >different from IRIX? Irix looks a lot like BSD which means that a lot of interfaces are completely different from linux. The algorithms are mostly the same but the kernel is sufficiently different that it needs a lot of work to make them play together. It is absolutely not a drop-in kernel mod. >I probably can't do that since as you know I use hardware RAIDs so I probably >need "big" filesystems, and I also need "big" files. What steve meant was big from a linux standpoint. XFS bigfiles are 2^63. I don't how large files will become without this option though. You can't get further that 2TB anyways on linux. Cheers -- Seth Every program has two purposes one for which it was written and another for which it wasn't I use the last kind. From owner-linux-xfs@oss.sgi.com Sat Jan 26 11:39:09 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0QJd9U16979 for linux-xfs-outgoing; Sat, 26 Jan 2002 11:39:09 -0800 Received: from ares (adsl-96951.turboline.skynet.be [217.136.250.183] (may be forged)) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0QJd2P16915 for ; Sat, 26 Jan 2002 11:39:02 -0800 Received: from takis by ares with local (Exim 3.22 #1 (Debian)) id 16UXj8-00015b-00 for ; Sat, 26 Jan 2002 19:38:58 +0100 Date: Sat, 26 Jan 2002 19:38:58 +0100 To: linux-xfs@oss.sgi.com Subject: Possible error in buildscript Message-ID: <20020126183856.GA3415@skynet.be> Reply-To: takis@lumumba.luc.ac.be Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="M9NhX3UHpAaciwkO" Content-Disposition: inline User-Agent: Mutt/1.3.25i From: Panagiotis Issaris Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 1584 Lines: 50 --M9NhX3UHpAaciwkO Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Dear, When building the xfsdump-1.1.13 package, everything compiled smoothly, expect for the linking with the libattr.so and libdm.so libraries. The makefile executed "/lib/libattr.so" and "/lib/libdm.so" on the GCC=20 commandline instead of "-lattr" and "-ldm". Simply replacing the incorrect values on the GCC commandline enabled me to finish the build correctly. This error occured in the "fsr", "dump" and "restore" subdirectories. I did not yet write a little fix for it, neither have I looked at the possi= ble reason for this little problem, but if no-one would have the time to look a= t it, I will try to fix it next weekend. I'm using Debian Linux (Sid) with 2.4.17-xfs kernel on a AMD K6/2. With friendly regards, Panagiotis Issaris --=20 .-. | lumumba.luc.ac.be/takis/takis_public_key.txt /v\ L I N U X | panagiotis.issaris@advalvas.be=20 // \\ >Phear the Penguin< | ICQ: 12764288 /( )\=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20 ^^-^^=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20 --M9NhX3UHpAaciwkO 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 iD8DBQE8UvfA9vBikIT5nMwRAge+AJ96KdeOVZVcGGnlO4p9QpRvLb58ggCgtS7C kiA0XZkdny5bgfL3VQPKkrE= =Lncv -----END PGP SIGNATURE----- --M9NhX3UHpAaciwkO-- From owner-linux-xfs@oss.sgi.com Sat Jan 26 12:27:57 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0QKRvb23709 for linux-xfs-outgoing; Sat, 26 Jan 2002 12:27:57 -0800 Received: from ADSL-Bergs.RZ.RWTH-Aachen.DE (adsl-bergs.rz.RWTH-Aachen.DE [137.226.80.218]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0QKRpP23666 for ; Sat, 26 Jan 2002 12:27:51 -0800 Received: from [192.168.1.2] (helo=ralf) by ADSL-Bergs.RZ.RWTH-Aachen.DE with smtp (Exim 3.12 #1) id 16UYUJ-0007XM-00; Sat, 26 Jan 2002 20:27:43 +0100 From: "Ralf G. R. Bergs" To: "Linux XFS Mailing List" Cc: "Seth Mos" , "Stephen Lord" Date: Sat, 26 Jan 2002 20:27:42 +0100 Reply-To: "Ralf G. R. Bergs" X-Mailer: PMMail 2000 Professional (2.20.2380) For Windows 2000 (5.0.2195;2) In-Reply-To: <4.3.2.7.2.20020126184721.034f2338@pop.xs4all.nl> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Subject: Re: Reduce XFS footprint (was Re: TAKE - remove a function xfs added to filemap.c Message-Id: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 1113 Lines: 33 On Sat, 26 Jan 2002 18:52:30 +0100, Seth Mos wrote: [...] >Irix looks a lot like BSD which means that a lot of interfaces are >completely different from linux. >The algorithms are mostly the same but the kernel is sufficiently different >that it needs a lot of work to make them play together. It is absolutely >not a drop-in kernel mod. I see. Sorry, but I don't have any IRIX experience, so I was pretty clueless about that. Thanks for explaining! >>I probably can't do that since as you know I use hardware RAIDs so I probably >>need "big" filesystems, and I also need "big" files. > >What steve meant was big from a linux standpoint. XFS bigfiles are 2^63. I >don't how large files will become without this option though. You can't get >further that 2TB anyways on linux. That will do for now. :-) Thanks, Ralf -- Verkaufe Original-BMW-Raeder: L I N U X .~. http://adsl-bergs.rz.rwth-aachen.de/~rabe The Choice /V\ of a GNU /( )\ Generation ^^-^^ From owner-linux-xfs@oss.sgi.com Sat Jan 26 12:45:00 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0QKj0S26036 for linux-xfs-outgoing; Sat, 26 Jan 2002 12:45:00 -0800 Received: from yog-sothoth.sgi.com (eugate.sgi.com [192.48.160.10]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0QKisP25996 for ; Sat, 26 Jan 2002 12:44:54 -0800 Received: from zeus-e8.americas.sgi.com (zeus-e8.americas.sgi.com [128.162.8.103]) by yog-sothoth.sgi.com (980305.SGI.8.8.8-aspam-6.2/980304.SGI-aspam-europe) via ESMTP id UAA899550 for ; Sat, 26 Jan 2002 20:44:10 +0100 (CET) mail_from (lord@sgi.com) Received: from tulip-e185.americas.sgi.com (tulip-e185.americas.sgi.com [128.162.185.208]) by zeus-e8.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id NAA164230; Sat, 26 Jan 2002 13:43:33 -0600 (CST) Received: from sgi.com (nzGTI1jG8r5fsPptQRihfzA4gSWRklXO@lord-h1.americas.sgi.com [206.11.101.42]) by tulip-e185.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.7) with ESMTP id NAA75372; Sat, 26 Jan 2002 13:43:33 -0600 (CST) Message-ID: <3C5306E1.8040408@sgi.com> Date: Sat, 26 Jan 2002 13:43:29 -0600 From: Stephen Lord User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.7) Gecko/20011226 X-Accept-Language: en-us MIME-Version: 1.0 To: pac@fortuitous.com CC: linux-xfs@oss.sgi.com Subject: Re: How to create a separate log References: <20020126111331.A5571@bistro.marx> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 926 Lines: 32 pac@fortuitous.com wrote: > What do i need to do to create a separate log file? > > Does the log live in a partition unto itself or can I make a log file >on another filesystem that has other data in it? Is there a document >that describes in detail how this goes? > >-Phil Carinhas >-- > .--------------------------------------------------------. > | Dr. Philip A. Carinhas | pac@fortuitous.com | > | Fortuitous Technologies Inc. | http://fortuitous.com | > | Linux Consulting & Training | Tel : 1-512-467-2154 | > `--------------------------------------------------------' > Default log location is in the middle of the partition/volume you run mkfs on. If you want an external log then you need to dedicate a partition to it, it cannot be in a file. These are the options for an external log: mkfs -t xfs -l logdev=/dev/xxx,size=XXXb /dev/yyy mount -t xfs -o logdev=/dev/xxx /dev/yyy /mnt Steve From owner-linux-xfs@oss.sgi.com Sat Jan 26 13:00:49 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0QL0nh28338 for linux-xfs-outgoing; Sat, 26 Jan 2002 13:00:49 -0800 Received: from sgi.com (sgi-too.SGI.COM [204.94.211.39]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0QL0cP28300 for ; Sat, 26 Jan 2002 13:00:38 -0800 Received: from zeus-e8.americas.sgi.com (zeus-e8.americas.sgi.com [128.162.8.103]) by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id MAA06162 for ; Sat, 26 Jan 2002 12:00:01 -0800 (PST) mail_from (lord@sgi.com) Received: from tulip-e185.americas.sgi.com (tulip-e185.americas.sgi.com [128.162.185.208]) by zeus-e8.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id NAA164333; Sat, 26 Jan 2002 13:59:20 -0600 (CST) Received: from sgi.com (lcWKz3plqFlAMhIri2iTCjHTiRFqY21I@lord-h1.americas.sgi.com [206.11.101.42]) by tulip-e185.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.7) with ESMTP id NAA07475; Sat, 26 Jan 2002 13:59:19 -0600 (CST) Message-ID: <3C530A93.60105@sgi.com> Date: Sat, 26 Jan 2002 13:59:15 -0600 From: Stephen Lord User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.7) Gecko/20011226 X-Accept-Language: en-us MIME-Version: 1.0 To: "Ralf G. R. Bergs" CC: Linux XFS Mailing List Subject: Re: Reduce XFS footprint (was Re: TAKE - remove a function xfs added to filemap.c References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 2071 Lines: 68 Ralf G. R. Bergs wrote: >>then it gets a bit smaller. There are definitely other code paths you >>cannot get to in there >>which we could cut out - just a matter of finding them. >> > >That reminds me of another question I'm asking myself since a while: It seems >as if you're developing XFS for Linux from scratch instead of "just" porting >it from SGI. Is that right? Or why do you seem to change even fundamental code >pieces? Or does porting to Linux mean you have to rewrite it because it's so >different from IRIX? > I would say 95% of the code is untouched, except for the endian conversion work which was neccessary for a little endian implementation. The interfaces between the vfs and the filesystem and between the filesystem and the block layer are where all the changes have happened. We did need to do a lot of work for data caching since the Irix model and the linux model were not at all close. The vfs layer has some major differences too. >>You could try editing xfs_types.h and changing >> >>#define XFS_BIG_FILES 1 >>#define XFS_BIG_FILESYSTEMS 1 >> >>to >> >>#define XFS_BIG_FILES 0 >>#define XFS_BIG_FILESYSTEMS 0 >> > >I probably can't do that since as you know I use hardware RAIDs so I probably >need "big" filesystems, and I also need "big" files. > The limits in xfs if you turn these off are: Max file size 2^40 bytes Max filesystem size is 2 Tbytes I think (not sure without some research). It does compile and run, and you save about 45K in code size by doing it, so not too much. You can also edit xfs_macros.h and define WANT_SPACE_C to 1 (replace the existing definition). This turns a lot of inline macros into function calls - it will be slower, but it is another 10K less code - again, not very much. So and smp build (in 2.5) went from text data bss dec hex filename 520994 4896 2080 527970 80e62 fs/xfs/xfs.o to text data bss dec hex filename 487334 4896 2080 494310 78ae6 fs/xfs/xfs.o with these two build changes. Steve From owner-linux-xfs@oss.sgi.com Sat Jan 26 13:24:08 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0QLO8o31613 for linux-xfs-outgoing; Sat, 26 Jan 2002 13:24:08 -0800 Received: from burns.luca.2y.net (OL46-90.fibertel.com.ar [24.232.90.46]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0QLO1P31570 for ; Sat, 26 Jan 2002 13:24:01 -0800 Message-Id: <200201262124.g0QLO1P31570@oss.sgi.com> Received: (qmail 723 invoked from network); 26 Jan 2002 20:44:46 -0000 Received: from homero.luca.2y.net (luca@192.168.10.2) by luca.2y.net with SMTP; 26 Jan 2002 20:44:46 -0000 Date: Sat, 26 Jan 2002 17:20:19 -0300 (ART) From: Leandro Lucarella Subject: Problems with yesterday CVS and international characters To: linux-xfs@oss.sgi.com MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=ISO-8859-1 Content-Disposition: INLINE X-Mailer: Mahogany, 0.64 'Sparc', compiled for Linux 2.4.10 i686 Reply-To: luca@luca.2y.net X-Face: )P)-C|VHyQI40EG:0=clcMc(wsbgD>'RgcKqwBP!KJ.i1f=6$#ymCSSP*S?y:;`cHb?\tKI BSwBdo#}C4a&R>k&W7fpk9GsT2LM/\VL17I>I55~(vL/ {P:;; Sat, 26 Jan 2002 13:55:15 -0800 Received: from zeus-e8.americas.sgi.com (zeus-e8.americas.sgi.com [128.162.8.103]) by zok.sgi.com (8.11.4/8.11.4/linux-outbound_gateway-1.1) with ESMTP id g0QKt7o17039 for ; Sat, 26 Jan 2002 12:55:07 -0800 Received: from tulip-e185.americas.sgi.com (tulip-e185.americas.sgi.com [128.162.185.208]) by zeus-e8.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id OAA164402; Sat, 26 Jan 2002 14:53:51 -0600 (CST) Received: from sgi.com (BKXakHeqjwqUrskcVoOnj8HfFnArejWG@lord-h1.americas.sgi.com [206.11.101.42]) by tulip-e185.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.7) with ESMTP id OAA25354; Sat, 26 Jan 2002 14:53:51 -0600 (CST) Message-ID: <3C53175A.9030105@sgi.com> Date: Sat, 26 Jan 2002 14:53:46 -0600 From: Stephen Lord User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.7) Gecko/20011226 X-Accept-Language: en-us MIME-Version: 1.0 To: luca@luca.2y.net CC: linux-xfs@oss.sgi.com Subject: Re: Problems with yesterday CVS and international characters References: <200201262124.g0QLO1P31570@oss.sgi.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 1866 Lines: 57 Leandro Lucarella wrote: >Hi! I'm starting to use XFS not for so long. First with kernel 2.4.14-xfs >without any problems... I have some files with international characters >(since I'm an spanish speaker) like a ( á :P ), or q (ñ) and >so... With XFS enabled kernel 2.4.14 I have no problems with this files, >but yesterday I've tried to update to kernel 2.4.17-xfs (from XFS CVS) and >all the files that hace this characters appears with strange characters so >"ls" and other program (or maybe directly the kernel?) can't find them: >kernel 2.4.14-xfs: > $ ls > lo que vendra (cd 1) > cd lo\ que\ vendra\ \(cd\ 1\)/ > lo que vendra (cd 1)$ ls > adiss nonino.mp3 > >kernel 2.4.17-xfs: > $ ls > lo que vendr? (cd 1) > cd lo\ que\ vendra\ \(cd\ 1\)/ > lo que vendra (cd 1)$ ls > ls: adiss nonino.mp3: No existe el fichero o el directorio (*) > >(*) means "File or directory does not exists" > >I've seen and compared both 2.4.14 and 2.4.17 kernel config files and there >are no significant defferences. I have compile Native languaje support in >both kernels (with iso8859-1 as default). >A weird thing is that kernel 2.4.17 shows the directories with >international character bad, but it find them anyway. With files, this is >not true... it can't find them. > >Well I hope this information is enoght so you can help me, and if is not, >please tell me what extra information do you need... > >Thanks a lot!!! > >-- >LUCA - Leandro Lucarella >------------------------ >MAIL: luca@lucarella.com.ar >HTTP: www.luca.2y.net >UIN: 2847576 >JID: luca@jabber.linuxmendoza.org.ar >------------------------ >Usando Debian GNU/Linux > I do not think this can have anything to do with xfs, it does not manipulate character strings in any way. All it does it copy them and compare them. Someone on the list may be able to help you though. Steve From owner-linux-xfs@oss.sgi.com Sat Jan 26 17:37:14 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0R1bEG02483 for linux-xfs-outgoing; Sat, 26 Jan 2002 17:37:14 -0800 Received: from UberGeek.coremetrics.com ([209.184.141.163]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0R1b4P02433 for ; Sat, 26 Jan 2002 17:37:04 -0800 Received: (from austin@localhost) by UberGeek.coremetrics.com (8.11.6/8.11.6) id g0R0aMX13865; Sat, 26 Jan 2002 18:36:22 -0600 X-Authentication-Warning: UberGeek.coremetrics.com: austin set sender to austin@coremetrics.com using -f Subject: Re: -aa series compatibility From: Austin Gonyou To: Stephen Lord Cc: linux-xfs@oss.sgi.com In-Reply-To: <3C521C17.9030108@sgi.com> References: <3C521C17.9030108@sgi.com> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-MEHmkNd9oDb+7tUkpKR9" X-Mailer: Evolution/1.0.1 Date: 26 Jan 2002 18:36:22 -0600 Message-Id: <1012091782.13841.0.camel@UberGeek> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 2037 Lines: 71 --=-MEHmkNd9oDb+7tUkpKR9 Content-Type: text/plain Content-Transfer-Encoding: quoted-printable DOH! Silly me. :) Thanks for the help. I'll try it out next week and see what it gets me. Thanks for putting up with me. I'm just trying to do my part. :)=20 On Fri, 2002-01-25 at 21:01, Stephen Lord wrote: > Eric Sandeen wrote: >=20 > >On 25 Jan 2002, Austin Gonyou wrote: > > > >>Given that I spent a lot of time getting a XFS enabled kernel merged > >>with -aa series kernel, I'd like to ask if anyone else has tried out > the > >>-aa series without XFS? If so, and you have liked what you > >>see/use/whatever, I'd like to ask SGI if there is a way to work-out > >>between the XFS tree and -AA tree a possibly easier migration path. > >> > > > >Austin - > > > >Rather than just applying the patch directly and dealing with the > rejects, > >you might try the "mergetrees" tool to do this, you just do: > > > >mergetrees linux-aa/ linux-linus/ linux-xfs/ linux-aa-xfs/ > > > >and it will merge your aa tree with the xfs tree and produce an aa-xfs > >tree ("linux-aa,", "linux-linus,", and "linux-xfs" are all the same > base > >kernel - say, 2.4.17 - with the -aa or -xfs (or no) patches.) > > > >You'll get a list of conflicts, and the conflicts are marked _in_ the > >source files, making it much easier to resolve. > > > >-Eric > > > Mergetrees comes from here: >=20 > http://cvs.bofh.asn.au/mergetrees/ >=20 > Steve >=20 >=20 --=20 Austin Gonyou Systems Architect, CCNA Coremetrics, Inc. Phone: 512-698-7250 email: austin@coremetrics.com "It is the part of a good shepherd to shear his flock, not to skin it." Latin Proverb --=-MEHmkNd9oDb+7tUkpKR9 Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQA8U0uG94g6ZVmFMoIRAumAAJ9UIzrWfe+9XL43YKGJ5UlnxfPeOACgvMIn zmDWWtsrGuIkWwWo3GX46Fg= =gnAy -----END PGP SIGNATURE----- --=-MEHmkNd9oDb+7tUkpKR9-- From owner-linux-xfs@oss.sgi.com Sat Jan 26 19:23:31 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0R3NVD16550 for linux-xfs-outgoing; Sat, 26 Jan 2002 19:23:31 -0800 Received: from steelnest.at.home (qmailr@as1-6-7.lio.s.bonet.se [217.215.28.251]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0R3NPP16515 for ; Sat, 26 Jan 2002 19:23:26 -0800 Received: (qmail 1099 invoked from network); 27 Jan 2002 03:23:23 -0000 Received: from unknown (HELO localhost.localdomain) (127.0.0.1) by 0 with SMTP; 27 Jan 2002 03:23:23 -0000 Subject: Linux 2.4.17-xfs vs previous XFS versions and certain non-us characters in filenames From: =?ISO-8859-1?Q?H=E5kan?= Lindqvist To: Linux XFS Mailing List Content-Type: text/plain; charset=ISO-8859-1 X-Mailer: Evolution/1.0.1 Date: 27 Jan 2002 04:23:23 +0100 Message-Id: <1012101803.1045.28.camel@steelnest> Mime-Version: 1.0 X-AntiVirus: scanned for viruses by AMaViS 0.2.1 (http://amavis.org/) Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id g0R3NQP16516 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 1164 Lines: 28 The current (as of today) CVS version of linux-2.4-xfs (2.4.17) does not seem to be able to handle files created under earlier versions of XFS which have filenames containing certain (latin1) characters (Swedish characters å,ä,ö (a with ring on top, a with dots on top and o with dots on top) for example). The kind of errors I get is that if I run ls so that it finds these files it spits out "ls: : No such file or directory" (the filename can be a match of a wildcard or tabcompletion - so it can't be a case of bad typing). Going back to my previous kernel (2.4.16-xfs) makes things work again. However if I create a new file with a å (for example) in the filename under 2.4.17-xfs, that file causes the same kind of problem under 2.4.16-xfs. It seems that stat:ing the file fails eventhough the file exists and can be found. (This output from "strace ls -l janneååå" seems to point in that direction too: 'lstat64("janneååå", 0x80548bc) = -1 ENOENT (No such file or directory)') This does not seem to affect other filesystems (at least not ext2), therefore I assume the issue is with some new XFS code. Best regards, Håkan Lindqvist From owner-linux-xfs@oss.sgi.com Sat Jan 26 19:33:03 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0R3X3q17920 for linux-xfs-outgoing; Sat, 26 Jan 2002 19:33:03 -0800 Received: from steelnest.at.home (qmailr@as1-6-7.lio.s.bonet.se [217.215.28.251]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0R3WuP17880 for ; Sat, 26 Jan 2002 19:32:56 -0800 Received: (qmail 1251 invoked from network); 27 Jan 2002 03:32:54 -0000 Received: from unknown (HELO localhost.localdomain) (127.0.0.1) by 0 with SMTP; 27 Jan 2002 03:32:54 -0000 Subject: Re: Linux 2.4.17-xfs vs previous XFS versions and certain non-us characters in filenames From: =?ISO-8859-1?Q?H=E5kan?= Lindqvist To: lord@sgi.com Cc: Linux XFS Mailing List In-Reply-To: <1012101803.1045.28.camel@steelnest> References: <1012101803.1045.28.camel@steelnest> Content-Type: text/plain; charset=ISO-8859-1 X-Mailer: Evolution/1.0.1 Date: 27 Jan 2002 04:32:53 +0100 Message-Id: <1012102374.1045.35.camel@steelnest> Mime-Version: 1.0 X-AntiVirus: scanned for viruses by AMaViS 0.2.1 (http://amavis.org/) Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id g0R3WvP17886 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 1753 Lines: 44 I just noticed this seems to be the same problem as mentioned in the "Problems with yesterday CVS and international characters"-thread which I failed to find before sending "my problem" to the list. Are you sure that XFS can't have to do with this? (What baffles me is how this can avoid affecting ext2, and clearly depends on whether I use 2.4.16-xfs or 2.4.17-xfs (I change obsolutely nothing else between my tests) if it is not XFS-related.) Best regards, Håkan Lindqvist On Sun, 2002-01-27 at 04:23, Håkan Lindqvist wrote: > The current (as of today) CVS version of linux-2.4-xfs (2.4.17) does not > seem to be able to handle files created under earlier versions of XFS > which have filenames containing certain (latin1) characters (Swedish > characters å,ä,ö (a with ring on top, a with dots on top and o with dots > on top) for example). > > The kind of errors I get is that if I run ls so that it finds these > files it spits out "ls: : No such file or directory" (the > filename can be a match of a wildcard or tabcompletion - so it can't be > a case of bad typing). > Going back to my previous kernel (2.4.16-xfs) makes things work again. > However if I create a new file with a å (for example) in the filename > under 2.4.17-xfs, that file causes the same kind of problem under > 2.4.16-xfs. > > It seems that stat:ing the file fails eventhough the file exists and can > be found. (This output from "strace ls -l janneååå" seems to point in > that direction too: 'lstat64("janneååå", 0x80548bc) = -1 ENOENT > (No such file or directory)') > > This does not seem to affect other filesystems (at least not ext2), > therefore I assume the issue is with some new XFS code. > > > Best regards, > Håkan Lindqvist > > From owner-linux-xfs@oss.sgi.com Sat Jan 26 20:10:47 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0R4Al223250 for linux-xfs-outgoing; Sat, 26 Jan 2002 20:10:47 -0800 Received: from zok.sgi.com (zok.SGI.COM [204.94.215.101]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0R4ANP23168 for ; Sat, 26 Jan 2002 20:10:24 -0800 Received: from zeus-e8.americas.sgi.com (zeus-e8.americas.sgi.com [128.162.8.103]) by zok.sgi.com (8.11.4/8.11.4/linux-outbound_gateway-1.1) with ESMTP id g0R3AGo04342 for ; Sat, 26 Jan 2002 19:10:16 -0800 Received: from tulip-e185.americas.sgi.com (tulip-e185.americas.sgi.com [128.162.185.208]) by zeus-e8.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id VAA167724; Sat, 26 Jan 2002 21:09:00 -0600 (CST) Received: from sgi.com (aLKRrFInGaZui6wqAPS1NuYXbKGoRFAM@lord-h1.americas.sgi.com [206.11.101.42]) by tulip-e185.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.7) with ESMTP id VAA36192; Sat, 26 Jan 2002 21:08:59 -0600 (CST) Message-ID: <3C536F44.1020301@sgi.com> Date: Sat, 26 Jan 2002 21:08:52 -0600 From: Stephen Lord User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.7) Gecko/20011226 X-Accept-Language: en-us MIME-Version: 1.0 To: =?ISO-8859-1?Q?H=E5kan?= Lindqvist CC: Linux XFS Mailing List Subject: Re: Linux 2.4.17-xfs vs previous XFS versions and certain non-us characters in filenames References: <1012101803.1045.28.camel@steelnest> <1012102374.1045.35.camel@steelnest> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 5588 Lines: 214 Hekan Lindqvist wrote: >I just noticed this seems to be the same problem as mentioned in the >"Problems with yesterday CVS and international characters"-thread which >I failed to find before sending "my problem" to the list. > >Are you sure that XFS can't have to do with this? (What baffles me is >how this can avoid affecting ext2, and clearly depends on whether I use >2.4.16-xfs or 2.4.17-xfs (I change obsolutely nothing else between my >tests) if it is not XFS-related.) > >Best regards, >Hekan Lindqvist > > >On Sun, 2002-01-27 at 04:23, Hekan Lindqvist wrote: > >>The current (as of today) CVS version of linux-2.4-xfs (2.4.17) does not >>seem to be able to handle files created under earlier versions of XFS >>which have filenames containing certain (latin1) characters (Swedish >>characters e,d,v (a with ring on top, a with dots on top and o with dots >>on top) for example). >> >>The kind of errors I get is that if I run ls so that it finds these >>files it spits out "ls: : No such file or directory" (the >>filename can be a match of a wildcard or tabcompletion - so it can't be >>a case of bad typing). >>Going back to my previous kernel (2.4.16-xfs) makes things work again. >>However if I create a new file with a e (for example) in the filename >>under 2.4.17-xfs, that file causes the same kind of problem under >>2.4.16-xfs. >> >>It seems that stat:ing the file fails eventhough the file exists and can >>be found. (This output from "strace ls -l janneeee" seems to point in >>that direction too: 'lstat64("janneeee", 0x80548bc) = -1 ENOENT >>(No such file or directory)') >> >>This does not seem to affect other filesystems (at least not ext2), >>therefore I assume the issue is with some new XFS code. >> There really is no new xfs code in 2.4.17, just some I/O related bug fixes, nothing at all to do with directories. Did you switch compilers between building these kernel versions? The fact that files created on one kernel cause problems for the other is strange, it suggests the hash calculations are coming out different between the kernels. >> >> >>Best regards, >>Hekan Lindqvist >> > > OK, do this. First find the inode number of the containing directory using ls -lid pathname of dir [root@burst xfs]# ls -lid . 128 drwxr-xr-x 5 root root 70 Jan 26 14:26 . It would work best if you could find a small directory with this problem, one whose size in ls shows up as less than 4K. Then as root run xfs_db -r /dev/xxx on the device - preferably when it is not mounted. Enter inode xxxx p where xxxx is the number in the first column of ls output (128 above). This will dump out the condents of the inode, so for my example: [root@burst xfs]# xfs_db -r /dev/hda3 xfs_db: inode 128 xfs_db: p core.magic = 0x494e core.mode = 040755 core.version = 1 core.format = 1 (local) core.nlinkv1 = 5 core.uid = 0 core.gid = 0 core.atime.sec = Sat Jan 26 13:35:15 2002 core.atime.nsec = 021650000 core.mtime.sec = Sat Jan 26 14:26:02 2002 core.mtime.nsec = 451650000 core.ctime.sec = Sat Jan 26 14:26:02 2002 core.ctime.nsec = 451650000 core.size = 70 core.nblocks = 0 core.extsize = 0 core.nextents = 0 core.naextents = 0 core.forkoff = 0 core.aformat = 2 (extents) core.dmevmask = 0 core.dmstate = 0 core.newrtbm = 0 core.prealloc = 0 core.realtime = 0 core.gen = 0 next_unlinked = null u.sfdir2.hdr.count = 5 u.sfdir2.hdr.i8count = 0 u.sfdir2.hdr.parent.i4 = 128 u.sfdir2.list[0].namelen = 3 u.sfdir2.list[0].offset = 0x30 u.sfdir2.list[0].name = "tmp" u.sfdir2.list[0].inumber.i4 = 131 u.sfdir2.list[1].namelen = 10 u.sfdir2.list[1].offset = 0x50 u.sfdir2.list[1].name = "client.txt" u.sfdir2.list[1].inumber.i4 = 133 u.sfdir2.list[2].namelen = 8 u.sfdir2.list[2].offset = 0x80 u.sfdir2.list[2].name = "NBSIMULD" u.sfdir2.list[2].inumber.i4 = 6292640 u.sfdir2.list[3].namelen = 4 u.sfdir2.list[3].offset = 0xd8 u.sfdir2.list[3].name = "doio" u.sfdir2.list[3].inumber.i4 = 136 u.sfdir2.list[4].namelen = 4 u.sfdir2.list[4].offset = 0xe8 u.sfdir2.list[4].name = "lord" u.sfdir2.list[4].inumber.i4 = 132 If your directory is 4K in length then you would get output like this; xfs_db: inode 6292640 xfs_db: p core.magic = 0x494e core.mode = 040700 core.version = 1 core.format = 2 (extents) core.nlinkv1 = 3 core.uid = 0 core.gid = 0 core.atime.sec = Sat Jan 26 04:02:53 2002 core.atime.nsec = 588413000 core.mtime.sec = Tue Jan 15 05:19:26 2002 core.mtime.nsec = 427555000 core.ctime.sec = Tue Jan 15 05:19:26 2002 core.ctime.nsec = 427555000 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 = 8 next_unlinked = null u.bmx[0] = [startoff,startblock,blockcount,extentflag] 0:[0,796416,1,0] Use the commands dblock 0 p And will dump the directory contents: xfs_db: p bhdr.magic = 0x58443242 bhdr.bestfree[0].offset = 0x108 bhdr.bestfree[0].length = 0xe98 bhdr.bestfree[1].offset = 0 bhdr.bestfree[1].length = 0 bhdr.bestfree[2].offset = 0 bhdr.bestfree[2].length = 0 bu[0].inumber = 6292640 bu[0].namelen = 1 bu[0].name = "." bu[0].tag = 0x10 bu[1].inumber = 128 bu[1].namelen = 2 bu[1].name = ".." bu[1].tag = 0x20 bu[2].inumber = 8651008 bu[2].namelen = 6 bu[2].name = "CLIENT" bu[2].tag = 0x30 ..... For the name you cannot find run hash xxxx where xxxx is the name. Finally from within xfsdb (you must be unmounted for this) blockget -n Send all the output to me and I will see if there is anything odd looking. Steve From owner-linux-xfs@oss.sgi.com Sat Jan 26 20:12:32 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0R4CWP23626 for linux-xfs-outgoing; Sat, 26 Jan 2002 20:12:32 -0800 Received: from mailhost.idcomm.com (mailhost.idcomm.com [207.40.196.14]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0R4CPP23586 for ; Sat, 26 Jan 2002 20:12:25 -0800 Received: from idcomm.com (IDENT:huPZuUj/arn0Hb/OOTPjGihhlee7WsuN@k56-pip11.idcomm.com [209.60.72.138]) by mailhost.idcomm.com (8.10.2/8.10.0) with ESMTP id g0R3Ifx17725 for ; Sat, 26 Jan 2002 20:18:41 -0700 Message-ID: <3C537029.E9639405@idcomm.com> Date: Sat, 26 Jan 2002 20:12:41 -0700 From: "D. Stimits" Reply-To: stimits@idcomm.com X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.6-pre1-xfs-4 i686) X-Accept-Language: en MIME-Version: 1.0 CC: Linux XFS Mailing List Subject: Re: Linux 2.4.17-xfs vs previous XFS versions and certain non-uscharacters in filenames References: <1012101803.1045.28.camel@steelnest> <1012102374.1045.35.camel@steelnest> Content-Type: text/plain; charset=iso-8859-1 X-MIME-Autoconverted: from 8bit to quoted-printable by mailhost.idcomm.com id g0R3Ifx17725 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id g0R4CPP23587 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 2206 Lines: 53 Håkan Lindqvist wrote: > > I just noticed this seems to be the same problem as mentioned in the > "Problems with yesterday CVS and international characters"-thread which > I failed to find before sending "my problem" to the list. > > Are you sure that XFS can't have to do with this? (What baffles me is > how this can avoid affecting ext2, and clearly depends on whether I use > 2.4.16-xfs or 2.4.17-xfs (I change obsolutely nothing else between my > tests) if it is not XFS-related.) I vaguely recall seeing character set options (or codeset) in the kernel config (been a while since I looked). The basic latin-1 being something like iso8859-1 (that could be way off, going by memory). Could it be that the failure is due to having chosen different character sets in the different kernel configurations? D. Stimits, stimits@idcomm.com > > Best regards, > Håkan Lindqvist > > On Sun, 2002-01-27 at 04:23, Håkan Lindqvist wrote: > > The current (as of today) CVS version of linux-2.4-xfs (2.4.17) does not > > seem to be able to handle files created under earlier versions of XFS > > which have filenames containing certain (latin1) characters (Swedish > > characters å,ä,ö (a with ring on top, a with dots on top and o with dots > > on top) for example). > > > > The kind of errors I get is that if I run ls so that it finds these > > files it spits out "ls: : No such file or directory" (the > > filename can be a match of a wildcard or tabcompletion - so it can't be > > a case of bad typing). > > Going back to my previous kernel (2.4.16-xfs) makes things work again. > > However if I create a new file with a å (for example) in the filename > > under 2.4.17-xfs, that file causes the same kind of problem under > > 2.4.16-xfs. > > > > It seems that stat:ing the file fails eventhough the file exists and can > > be found. (This output from "strace ls -l janneååå" seems to point in > > that direction too: 'lstat64("janneååå", 0x80548bc) = -1 ENOENT > > (No such file or directory)') > > > > This does not seem to affect other filesystems (at least not ext2), > > therefore I assume the issue is with some new XFS code. > > > > > > Best regards, > > Håkan Lindqvist > > > > From owner-linux-xfs@oss.sgi.com Sat Jan 26 23:21:52 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0R7LqJ16798 for linux-xfs-outgoing; Sat, 26 Jan 2002 23:21:52 -0800 Received: from www.fortuitous.com (cs6625128-203.austin.rr.com [66.25.128.203]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0R7LjP16761 for ; Sat, 26 Jan 2002 23:21:45 -0800 Received: by www.fortuitous.com (Postfix, from userid 500) id 2232A2D1; Sun, 27 Jan 2002 00:19:47 -0600 (CST) Date: Sun, 27 Jan 2002 00:19:47 -0600 From: pac@fortuitous.com To: linux-xfs@oss.sgi.com Subject: double mounting and other strangeness. Message-ID: <20020127001947.A6688@bistro.marx> Reply-To: pac@fortuitous.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.23i Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 2318 Lines: 52 I get some strange ability to mount 2 devices on one partition: I've done this twice with the same kernel.. Filesystem Type 1k-blocks Used Available Use% Mounted on /dev/hda2 reiserfs 610444 150288 460156 25% / /dev/hda1 reiserfs 152572 42128 110444 28% /boot /dev/hda3 reiserfs 2048216 1336208 712008 66% /usr /dev/hda5 reiserfs 1228896 217656 1011240 18% /var /dev/hda6 reiserfs 1020060 235516 784544 24% /tmp /dev/hda7 reiserfs 1228896 848224 380672 70% /home /dev/hda10 xfs 718092 144 717948 1% /alt /dev/hda9 xfs 718092 144 717948 1% /alt Linux bart.marx 2.4.17-preempt-fspatch-alsa #1 Fri Jan 25 21:45:36 CST 2002 i686 unknown THe patch i used on a kernel.org 2.4.17 kernel: ftp://ftp.uni-duisburg.de:/Linux/filesys/linux-2.4.17-fspatch.gz Here is the patch list: -p1 preempt-kernel-rml-2.4.17-1.patch -p1 lock-break-rml-2.4.17-2.patch -p1 cpu-affinity-rml-2.4.16-1.patch -p1 netdev-random-core-rml-2.4.17-1.patch -p1 netdev-random-drivers-rml-2.4.17-1.patch -p1 ide.2.4.17.01192002.patch -p1 linux-2.4.17-xfs-2002-01-23.patch -p1 jfs-2.4.common-1.0.12-patch -p1 jfs-2.4.7-1.0.12-patch -p1 alsa-0.9.0beta9-k2.4.15-3271042.diff I also get some errors when I try to make a new xfs filesystem on either /dev/hda10 and /dev/hda9: ------------------------------------------------------------------------ mkfs.xfs -f /dev/hda10 mkfs.xfs: warning - cannot set blocksize on block device /dev/hda10: Input/output error meta-data=/dev/hda10 isize=256 agcount=8, agsize=16064 blks data = bsize=4096 blocks=128512, imaxpct=25 = sunit=0 swidth=0 blks, unwritten=0 naming =version 2 bsize=4096 log =internal log bsize=4096 blocks=1200 realtime =none extsz=65536 blocks=0, rtextents=0 ------------------------------------------------------------------ System Information: dell laptop c500, celeron 700. -Phil Carinhas -- .--------------------------------------------------------. | Dr. Philip A. Carinhas | pac@fortuitous.com | | Fortuitous Technologies Inc. | http://fortuitous.com | `--------------------------------------------------------' From owner-linux-xfs@oss.sgi.com Sun Jan 27 00:20:32 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0R8KWs23824 for linux-xfs-outgoing; Sun, 27 Jan 2002 00:20:32 -0800 Received: from mail.ocs.com.au (mail.ocs.com.au [203.34.97.2]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0R8KRP23799 for ; Sun, 27 Jan 2002 00:20:28 -0800 Received: (qmail 23884 invoked from network); 27 Jan 2002 07:20:22 -0000 Received: from ocs3.intra.ocs.com.au (192.168.255.3) by mail.ocs.com.au with SMTP; 27 Jan 2002 07:20:22 -0000 Received: by ocs3.intra.ocs.com.au (Postfix, from userid 16331) id B1AC03000BF; Sun, 27 Jan 2002 18:20:20 +1100 (EST) Received: from ocs3.intra.ocs.com.au (localhost [127.0.0.1]) by ocs3.intra.ocs.com.au (Postfix) with ESMTP id 72520168; Sun, 27 Jan 2002 18:20:20 +1100 (EST) X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 From: Keith Owens To: pac@fortuitous.com Cc: linux-xfs@oss.sgi.com Subject: Re: double mounting and other strangeness. In-reply-to: Your message of "Sun, 27 Jan 2002 00:19:47 MDT." <20020127001947.A6688@bistro.marx> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sun, 27 Jan 2002 18:20:14 +1100 Message-ID: <24489.1012116014@ocs3.intra.ocs.com.au> Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 444 Lines: 12 On Sun, 27 Jan 2002 00:19:47 -0600, pac@fortuitous.com wrote: > I get some strange ability to mount 2 devices on one partition: > I've done this twice with the same kernel.. That is normal with any recent 2.4 kernel, it applies to all filesystems, not just XFS. You can even mount different file system types. /dev/scsi/host0/bus0/target4/lun0/part2 on /build type xfs (rw) /dev/ide/host0/bus0/target0/lun0/part1 on /build type ext2 (rw) From owner-linux-xfs@oss.sgi.com Sun Jan 27 02:16:31 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0RAGVE06719 for linux-xfs-outgoing; Sun, 27 Jan 2002 02:16:31 -0800 Received: from mfive.engr.matrixsemi.com ([64.3.134.227]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0RAGLP06664 for ; Sun, 27 Jan 2002 02:16:27 -0800 Received: from matrixsemi.com (starve-2.engr.matrixsemi.com [192.168.128.56]) by mfive.engr.matrixsemi.com (Postfix) with ESMTP id 050ACB134B1; Sun, 27 Jan 2002 01:16:14 -0800 (PST) Message-ID: <3C53C4D0.9000902@matrixsemi.com> Date: Sun, 27 Jan 2002 01:13:52 -0800 From: Shiv Sikand User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.4) Gecko/20010914 X-Accept-Language: en-us MIME-Version: 1.0 To: linux-xfs@oss.sgi.com Cc: chmouel@mandrakesoft.com Subject: Mandrake 8.1 exhibits xfs/nfs umask problem Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 601 Lines: 14 We have observed that the Mandrake 8.1 kernel exhibits a umask problem when xfs volumes are exported with nfs. If a new directory is created via nfs on an xfs volume, the umask from the current process is not inherited. Reading the mail archive, it looks like this problem or something extremely similar was fixed in the XFS tree a long time ago. We do not observe this problem with 2.4.5-xfs-1.0.1 which has been our production kernel prior to the arrival of XFS support in Mandrake. Can someone please take a look at the xfs code in the Mandrake build and confirm the problem. Thanks, Shiv From owner-linux-xfs@oss.sgi.com Sun Jan 27 04:00:00 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0RC00t22039 for linux-xfs-outgoing; Sun, 27 Jan 2002 04:00:00 -0800 Received: from ADSL-Bergs.RZ.RWTH-Aachen.DE (adsl-bergs.rz.RWTH-Aachen.DE [137.226.80.218]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0RBxsP21986 for ; Sun, 27 Jan 2002 03:59:54 -0800 Received: from [192.168.1.2] (helo=ralf) by ADSL-Bergs.RZ.RWTH-Aachen.DE with smtp (Exim 3.12 #1) id 16Un2I-0001kg-00; Sun, 27 Jan 2002 11:59:46 +0100 From: "Ralf G. R. Bergs" To: "Linux XFS Mailing List" Cc: "Stephen Lord" Date: Sun, 27 Jan 2002 11:59:45 +0100 Reply-To: "Ralf G. R. Bergs" X-Mailer: PMMail 2000 Professional (2.20.2380) For Windows 2000 (5.0.2195;2) In-Reply-To: <3C530A93.60105@sgi.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Subject: Why porting XFS to Linux means much work (was Re: Reduce XFS footprint (was Re: TAKE - remove a function xfs added to filemap.c Message-Id: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 1350 Lines: 44 On Sat, 26 Jan 2002 13:59:15 -0600, Stephen Lord wrote: [...] >I would say 95% of the code is untouched, except for the endian >conversion work which >was neccessary for a little endian implementation. The interfaces >between the vfs and >the filesystem and between the filesystem and the block layer are where >all the >changes have happened. We did need to do a lot of work for data caching >since the >Irix model and the linux model were not at all close. The vfs layer has >some major >differences too. I understand. Thanks for explaining! >>>#define XFS_BIG_FILES 0 >>>#define XFS_BIG_FILESYSTEMS 0 [...] >The limits in xfs if you turn these off are: > >Max file size 2^40 bytes >Max filesystem size is 2 Tbytes I think (not sure without some research). I guess that would still be plenty. :-) >It does compile and run, and you save about 45K in code size by doing it, Well, indeed 45K isn't too much so I spare myself the trouble of running not- so-well-tested code (if I understood you correctly.) Thank you for your efforts, Ralf -- Verkaufe Original-BMW-Raeder: L I N U X .~. http://adsl-bergs.rz.rwth-aachen.de/~rabe The Choice /V\ of a GNU /( )\ Generation ^^-^^ From owner-linux-xfs@oss.sgi.com Sun Jan 27 04:02:31 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0RC2Vd22881 for linux-xfs-outgoing; Sun, 27 Jan 2002 04:02:31 -0800 Received: from ADSL-Bergs.RZ.RWTH-Aachen.DE (adsl-bergs.rz.RWTH-Aachen.DE [137.226.80.218]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0RC2QP22849 for ; Sun, 27 Jan 2002 04:02:27 -0800 Received: from [192.168.1.2] (helo=ralf) by ADSL-Bergs.RZ.RWTH-Aachen.DE with smtp (Exim 3.12 #1) id 16Un4j-0001lB-00; Sun, 27 Jan 2002 12:02:17 +0100 From: "Ralf G. R. Bergs" To: "linux-xfs@oss.sgi.com" Cc: "luca@luca.2y.net" , "Leandro Lucarella" Date: Sun, 27 Jan 2002 12:02:17 +0100 Reply-To: "Ralf G. R. Bergs" X-Mailer: PMMail 2000 Professional (2.20.2380) For Windows 2000 (5.0.2195;2) In-Reply-To: <200201262124.g0QLO1P31570@oss.sgi.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: Re: Problems with yesterday CVS and international characters Message-Id: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id g0RC2RP22854 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 681 Lines: 19 On Sat, 26 Jan 2002 17:20:19 -0300 (ART), Leandro Lucarella wrote: [...] > ls: adi¢s nonino.mp3: No existe el fichero o el directorio (*) > >(*) means "File or directory does not exists" This looks like a problem we were having with one of our RAIDs -- but it turned out that the RAID (a hardware RAID) had a problem, so we returned it for exchange. Are you sure that your hardware is ok?! -- Verkaufe Original-BMW-Raeder: L I N U X .~. http://adsl-bergs.rz.rwth-aachen.de/~rabe The Choice /V\ of a GNU /( )\ Generation ^^-^^ From owner-linux-xfs@oss.sgi.com Sun Jan 27 04:06:11 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0RC6B023684 for linux-xfs-outgoing; Sun, 27 Jan 2002 04:06:11 -0800 Received: from ADSL-Bergs.RZ.RWTH-Aachen.DE (adsl-bergs.rz.RWTH-Aachen.DE [137.226.80.218]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0RC63P23633 for ; Sun, 27 Jan 2002 04:06:05 -0800 Received: from [192.168.1.2] (helo=ralf) by ADSL-Bergs.RZ.RWTH-Aachen.DE with smtp (Exim 3.12 #1) id 16Un8E-0001ls-00; Sun, 27 Jan 2002 12:05:54 +0100 From: "Ralf G. R. Bergs" To: "linux-xfs@oss.sgi.com" Cc: "pac@fortuitous.com" Date: Sun, 27 Jan 2002 12:05:54 +0100 Reply-To: "Ralf G. R. Bergs" X-Mailer: PMMail 2000 Professional (2.20.2380) For Windows 2000 (5.0.2195;2) In-Reply-To: <20020127001947.A6688@bistro.marx> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Subject: Re: double mounting and other strangeness. Message-Id: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 690 Lines: 19 On Sun, 27 Jan 2002 00:19:47 -0600, pac@fortuitous.com wrote: > I also get some errors when I try to make a new xfs filesystem on either >/dev/hda10 and /dev/hda9: >------------------------------------------------------------------------ >mkfs.xfs -f /dev/hda10 >mkfs.xfs: warning - cannot set blocksize on block device /dev/hda10: Input/output error Try to upgrade your xfsprogs and see if it helps. -- Verkaufe Original-BMW-Raeder: L I N U X .~. http://adsl-bergs.rz.rwth-aachen.de/~rabe The Choice /V\ of a GNU /( )\ Generation ^^-^^ From owner-linux-xfs@oss.sgi.com Sun Jan 27 05:30:45 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0RDUjf11493 for linux-xfs-outgoing; Sun, 27 Jan 2002 05:30:45 -0800 Received: from steelnest.at.home (qmailr@as1-6-7.lio.s.bonet.se [217.215.28.251]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0RDUIP11388 for ; Sun, 27 Jan 2002 05:30:18 -0800 Received: (qmail 1195 invoked from network); 27 Jan 2002 12:30:12 -0000 Received: from unknown (HELO localhost.localdomain) (127.0.0.1) by 0 with SMTP; 27 Jan 2002 12:30:12 -0000 Subject: Re: Linux 2.4.17-xfs vs previous XFS versions and certain non-us characters in filenames From: =?ISO-8859-1?Q?H=E5kan?= Lindqvist To: Stephen Lord Cc: Linux XFS Mailing List In-Reply-To: <3C536F44.1020301@sgi.com> References: <1012101803.1045.28.camel@steelnest> <1012102374.1045.35.camel@steelnest> <3C536F44.1020301@sgi.com> Content-Type: text/plain; charset=ISO-8859-1 X-Mailer: Evolution/1.0.1 Date: 27 Jan 2002 13:30:12 +0100 Message-Id: <1012134612.1011.16.camel@steelnest> Mime-Version: 1.0 X-AntiVirus: scanned for viruses by AMaViS 0.2.1 (http://amavis.org/) Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id g0RDUKP11395 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 6639 Lines: 235 Thanks for your prompt reply! Okay, I will first of all recompile my 2.4.16-xfs kernel now to make sure that this is not caused by the compiler (or rather a change of compiler versions). If my new 2.4.16-xfs kernel (which is for sure compiled using the same tools as my 2.4.17-xfs kernel was) still works together with the earlier 2.4.16-xfs kernel, then it must have to do with some change in the kernel, right? (Not necessarily in the XFS code, but that would have made sense as it doesn't affect all filesystems.) I will also do what you said, of course. /Håkan On Sun, 2002-01-27 at 04:08, Stephen Lord wrote: > Hekan Lindqvist wrote: > > >I just noticed this seems to be the same problem as mentioned in the > >"Problems with yesterday CVS and international characters"-thread which > >I failed to find before sending "my problem" to the list. > > > >Are you sure that XFS can't have to do with this? (What baffles me is > >how this can avoid affecting ext2, and clearly depends on whether I use > >2.4.16-xfs or 2.4.17-xfs (I change obsolutely nothing else between my > >tests) if it is not XFS-related.) > > > >Best regards, > >Hekan Lindqvist > > > > > >On Sun, 2002-01-27 at 04:23, Hekan Lindqvist wrote: > > > >>The current (as of today) CVS version of linux-2.4-xfs (2.4.17) does not > >>seem to be able to handle files created under earlier versions of XFS > >>which have filenames containing certain (latin1) characters (Swedish > >>characters e,d,v (a with ring on top, a with dots on top and o with dots > >>on top) for example). > >> > >>The kind of errors I get is that if I run ls so that it finds these > >>files it spits out "ls: : No such file or directory" (the > >>filename can be a match of a wildcard or tabcompletion - so it can't be > >>a case of bad typing). > >>Going back to my previous kernel (2.4.16-xfs) makes things work again. > >>However if I create a new file with a e (for example) in the filename > >>under 2.4.17-xfs, that file causes the same kind of problem under > >>2.4.16-xfs. > >> > >>It seems that stat:ing the file fails eventhough the file exists and can > >>be found. (This output from "strace ls -l janneeee" seems to point in > >>that direction too: 'lstat64("janneeee", 0x80548bc) = -1 ENOENT > >>(No such file or directory)') > >> > >>This does not seem to affect other filesystems (at least not ext2), > >>therefore I assume the issue is with some new XFS code. > >> > There really is no new xfs code in 2.4.17, just some I/O related bug > fixes, nothing > at all to do with directories. Did you switch compilers between building > these > kernel versions? The fact that files created on one kernel cause > problems for the > other is strange, it suggests the hash calculations are coming out > different between > the kernels. > > >> > >> > >>Best regards, > >>Hekan Lindqvist > >> > > > > > OK, do this. First find the inode number of the containing directory using > ls -lid pathname of dir > [root@burst xfs]# ls -lid . > 128 drwxr-xr-x 5 root root 70 Jan 26 14:26 . > > > It would work best if you could find a small directory with this problem, > one whose size in ls shows up as less than 4K. > > Then as root run > > xfs_db -r /dev/xxx > > on the device - preferably when it is not mounted. > > Enter > > inode xxxx > p > > where xxxx is the number in the first column of ls output (128 above). > > This will dump out the condents of the inode, so for my example: > [root@burst xfs]# xfs_db -r /dev/hda3 > xfs_db: inode 128 > xfs_db: p > core.magic = 0x494e > core.mode = 040755 > core.version = 1 > core.format = 1 (local) > core.nlinkv1 = 5 > core.uid = 0 > core.gid = 0 > core.atime.sec = Sat Jan 26 13:35:15 2002 > core.atime.nsec = 021650000 > core.mtime.sec = Sat Jan 26 14:26:02 2002 > core.mtime.nsec = 451650000 > core.ctime.sec = Sat Jan 26 14:26:02 2002 > core.ctime.nsec = 451650000 > core.size = 70 > core.nblocks = 0 > core.extsize = 0 > core.nextents = 0 > core.naextents = 0 > core.forkoff = 0 > core.aformat = 2 (extents) > core.dmevmask = 0 > core.dmstate = 0 > core.newrtbm = 0 > core.prealloc = 0 > core.realtime = 0 > core.gen = 0 > next_unlinked = null > u.sfdir2.hdr.count = 5 > u.sfdir2.hdr.i8count = 0 > u.sfdir2.hdr.parent.i4 = 128 > u.sfdir2.list[0].namelen = 3 > u.sfdir2.list[0].offset = 0x30 > u.sfdir2.list[0].name = "tmp" > u.sfdir2.list[0].inumber.i4 = 131 > u.sfdir2.list[1].namelen = 10 > u.sfdir2.list[1].offset = 0x50 > u.sfdir2.list[1].name = "client.txt" > u.sfdir2.list[1].inumber.i4 = 133 > u.sfdir2.list[2].namelen = 8 > u.sfdir2.list[2].offset = 0x80 > u.sfdir2.list[2].name = "NBSIMULD" > u.sfdir2.list[2].inumber.i4 = 6292640 > u.sfdir2.list[3].namelen = 4 > u.sfdir2.list[3].offset = 0xd8 > u.sfdir2.list[3].name = "doio" > u.sfdir2.list[3].inumber.i4 = 136 > u.sfdir2.list[4].namelen = 4 > u.sfdir2.list[4].offset = 0xe8 > u.sfdir2.list[4].name = "lord" > u.sfdir2.list[4].inumber.i4 = 132 > > If your directory is 4K in length then you would get output like this; > > xfs_db: inode 6292640 > xfs_db: p > core.magic = 0x494e > core.mode = 040700 > core.version = 1 > core.format = 2 (extents) > core.nlinkv1 = 3 > core.uid = 0 > core.gid = 0 > core.atime.sec = Sat Jan 26 04:02:53 2002 > core.atime.nsec = 588413000 > core.mtime.sec = Tue Jan 15 05:19:26 2002 > core.mtime.nsec = 427555000 > core.ctime.sec = Tue Jan 15 05:19:26 2002 > core.ctime.nsec = 427555000 > 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 = 8 > next_unlinked = null > u.bmx[0] = [startoff,startblock,blockcount,extentflag] 0:[0,796416,1,0] > > Use the commands > dblock 0 > p > > And will dump the directory contents: > xfs_db: p > bhdr.magic = 0x58443242 > bhdr.bestfree[0].offset = 0x108 > bhdr.bestfree[0].length = 0xe98 > bhdr.bestfree[1].offset = 0 > bhdr.bestfree[1].length = 0 > bhdr.bestfree[2].offset = 0 > bhdr.bestfree[2].length = 0 > bu[0].inumber = 6292640 > bu[0].namelen = 1 > bu[0].name = "." > bu[0].tag = 0x10 > bu[1].inumber = 128 > bu[1].namelen = 2 > bu[1].name = ".." > bu[1].tag = 0x20 > bu[2].inumber = 8651008 > bu[2].namelen = 6 > bu[2].name = "CLIENT" > bu[2].tag = 0x30 > ..... > > For the name you cannot find run > > hash xxxx > > where xxxx is the name. > > Finally from within xfsdb (you must be unmounted for this) > > blockget -n > > Send all the output to me and I will see if there is anything odd looking. > > Steve > > > > > > > From owner-linux-xfs@oss.sgi.com Sun Jan 27 06:51:57 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0REpv725373 for linux-xfs-outgoing; Sun, 27 Jan 2002 06:51:57 -0800 Received: from steelnest.at.home (qmailr@as1-6-7.lio.s.bonet.se [217.215.28.251]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0REpVP25282 for ; Sun, 27 Jan 2002 06:51:31 -0800 Received: (qmail 1002 invoked from network); 27 Jan 2002 13:51:29 -0000 Received: from unknown (HELO localhost.localdomain) (127.0.0.1) by 0 with SMTP; 27 Jan 2002 13:51:29 -0000 Subject: Re: Linux 2.4.17-xfs vs previous XFS versions and certain non-us characters in filenames From: =?ISO-8859-1?Q?H=E5kan?= Lindqvist To: Stephen Lord Cc: Linux XFS Mailing List In-Reply-To: <3C536F44.1020301@sgi.com> References: <1012101803.1045.28.camel@steelnest> <1012102374.1045.35.camel@steelnest> <3C536F44.1020301@sgi.com> Content-Type: text/plain; charset=ISO-8859-1 X-Mailer: Evolution/1.0.1 Date: 27 Jan 2002 14:51:28 +0100 Message-Id: <1012139489.925.15.camel@steelnest> Mime-Version: 1.0 X-AntiVirus: scanned for viruses by AMaViS 0.2.1 (http://amavis.org/) Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id g0REpWP25283 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 6669 Lines: 234 I've found that this does not seem to affect files that were actually created under 2.4.16. However it affects files created under some version(s) <2.4.16. (These files work just fine in <=2.4.16, but not in 2.4.17.) (I created some new files under 2.4.16, and they worked alright in 2.4.17... However, as I said, it seems that files created under 2.4.17 do not work under 2.4.16 (as well as that files created somewhere in the <2.4.16 versions do not work in 2.4.17), and well, this is just confusing me.) I have done what you suggested and will send the output of that to you in private. /Håkan On Sun, 2002-01-27 at 04:08, Stephen Lord wrote: > Hekan Lindqvist wrote: > > >I just noticed this seems to be the same problem as mentioned in the > >"Problems with yesterday CVS and international characters"-thread which > >I failed to find before sending "my problem" to the list. > > > >Are you sure that XFS can't have to do with this? (What baffles me is > >how this can avoid affecting ext2, and clearly depends on whether I use > >2.4.16-xfs or 2.4.17-xfs (I change obsolutely nothing else between my > >tests) if it is not XFS-related.) > > > >Best regards, > >Hekan Lindqvist > > > > > >On Sun, 2002-01-27 at 04:23, Hekan Lindqvist wrote: > > > >>The current (as of today) CVS version of linux-2.4-xfs (2.4.17) does not > >>seem to be able to handle files created under earlier versions of XFS > >>which have filenames containing certain (latin1) characters (Swedish > >>characters e,d,v (a with ring on top, a with dots on top and o with dots > >>on top) for example). > >> > >>The kind of errors I get is that if I run ls so that it finds these > >>files it spits out "ls: : No such file or directory" (the > >>filename can be a match of a wildcard or tabcompletion - so it can't be > >>a case of bad typing). > >>Going back to my previous kernel (2.4.16-xfs) makes things work again. > >>However if I create a new file with a e (for example) in the filename > >>under 2.4.17-xfs, that file causes the same kind of problem under > >>2.4.16-xfs. > >> > >>It seems that stat:ing the file fails eventhough the file exists and can > >>be found. (This output from "strace ls -l janneeee" seems to point in > >>that direction too: 'lstat64("janneeee", 0x80548bc) = -1 ENOENT > >>(No such file or directory)') > >> > >>This does not seem to affect other filesystems (at least not ext2), > >>therefore I assume the issue is with some new XFS code. > >> > There really is no new xfs code in 2.4.17, just some I/O related bug > fixes, nothing > at all to do with directories. Did you switch compilers between building > these > kernel versions? The fact that files created on one kernel cause > problems for the > other is strange, it suggests the hash calculations are coming out > different between > the kernels. > > >> > >> > >>Best regards, > >>Hekan Lindqvist > >> > > > > > OK, do this. First find the inode number of the containing directory using > ls -lid pathname of dir > [root@burst xfs]# ls -lid . > 128 drwxr-xr-x 5 root root 70 Jan 26 14:26 . > > > It would work best if you could find a small directory with this problem, > one whose size in ls shows up as less than 4K. > > Then as root run > > xfs_db -r /dev/xxx > > on the device - preferably when it is not mounted. > > Enter > > inode xxxx > p > > where xxxx is the number in the first column of ls output (128 above). > > This will dump out the condents of the inode, so for my example: > [root@burst xfs]# xfs_db -r /dev/hda3 > xfs_db: inode 128 > xfs_db: p > core.magic = 0x494e > core.mode = 040755 > core.version = 1 > core.format = 1 (local) > core.nlinkv1 = 5 > core.uid = 0 > core.gid = 0 > core.atime.sec = Sat Jan 26 13:35:15 2002 > core.atime.nsec = 021650000 > core.mtime.sec = Sat Jan 26 14:26:02 2002 > core.mtime.nsec = 451650000 > core.ctime.sec = Sat Jan 26 14:26:02 2002 > core.ctime.nsec = 451650000 > core.size = 70 > core.nblocks = 0 > core.extsize = 0 > core.nextents = 0 > core.naextents = 0 > core.forkoff = 0 > core.aformat = 2 (extents) > core.dmevmask = 0 > core.dmstate = 0 > core.newrtbm = 0 > core.prealloc = 0 > core.realtime = 0 > core.gen = 0 > next_unlinked = null > u.sfdir2.hdr.count = 5 > u.sfdir2.hdr.i8count = 0 > u.sfdir2.hdr.parent.i4 = 128 > u.sfdir2.list[0].namelen = 3 > u.sfdir2.list[0].offset = 0x30 > u.sfdir2.list[0].name = "tmp" > u.sfdir2.list[0].inumber.i4 = 131 > u.sfdir2.list[1].namelen = 10 > u.sfdir2.list[1].offset = 0x50 > u.sfdir2.list[1].name = "client.txt" > u.sfdir2.list[1].inumber.i4 = 133 > u.sfdir2.list[2].namelen = 8 > u.sfdir2.list[2].offset = 0x80 > u.sfdir2.list[2].name = "NBSIMULD" > u.sfdir2.list[2].inumber.i4 = 6292640 > u.sfdir2.list[3].namelen = 4 > u.sfdir2.list[3].offset = 0xd8 > u.sfdir2.list[3].name = "doio" > u.sfdir2.list[3].inumber.i4 = 136 > u.sfdir2.list[4].namelen = 4 > u.sfdir2.list[4].offset = 0xe8 > u.sfdir2.list[4].name = "lord" > u.sfdir2.list[4].inumber.i4 = 132 > > If your directory is 4K in length then you would get output like this; > > xfs_db: inode 6292640 > xfs_db: p > core.magic = 0x494e > core.mode = 040700 > core.version = 1 > core.format = 2 (extents) > core.nlinkv1 = 3 > core.uid = 0 > core.gid = 0 > core.atime.sec = Sat Jan 26 04:02:53 2002 > core.atime.nsec = 588413000 > core.mtime.sec = Tue Jan 15 05:19:26 2002 > core.mtime.nsec = 427555000 > core.ctime.sec = Tue Jan 15 05:19:26 2002 > core.ctime.nsec = 427555000 > 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 = 8 > next_unlinked = null > u.bmx[0] = [startoff,startblock,blockcount,extentflag] 0:[0,796416,1,0] > > Use the commands > dblock 0 > p > > And will dump the directory contents: > xfs_db: p > bhdr.magic = 0x58443242 > bhdr.bestfree[0].offset = 0x108 > bhdr.bestfree[0].length = 0xe98 > bhdr.bestfree[1].offset = 0 > bhdr.bestfree[1].length = 0 > bhdr.bestfree[2].offset = 0 > bhdr.bestfree[2].length = 0 > bu[0].inumber = 6292640 > bu[0].namelen = 1 > bu[0].name = "." > bu[0].tag = 0x10 > bu[1].inumber = 128 > bu[1].namelen = 2 > bu[1].name = ".." > bu[1].tag = 0x20 > bu[2].inumber = 8651008 > bu[2].namelen = 6 > bu[2].name = "CLIENT" > bu[2].tag = 0x30 > ..... > > For the name you cannot find run > > hash xxxx > > where xxxx is the name. > > Finally from within xfsdb (you must be unmounted for this) > > blockget -n > > Send all the output to me and I will see if there is anything odd looking. > > Steve > > > > > > > From owner-linux-xfs@oss.sgi.com Sun Jan 27 07:25:13 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0RFPDe31131 for linux-xfs-outgoing; Sun, 27 Jan 2002 07:25:13 -0800 Received: from moutvdom00.kundenserver.de (moutvdom00.kundenserver.de [195.20.224.149]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0RFP8P31094 for ; Sun, 27 Jan 2002 07:25:09 -0800 Received: from [195.20.224.204] (helo=mrvdom00.kundenserver.de) by moutvdom00.kundenserver.de with esmtp (Exim 2.12 #2) id 16UqEy-0002gX-00; Sun, 27 Jan 2002 15:25:04 +0100 Received: from [217.228.147.128] (helo=kernelpanix.aura.of.mankind) by mrvdom00.kundenserver.de with esmtp (Exim 2.12 #2) id 16UqEy-0002mq-00; Sun, 27 Jan 2002 15:25:04 +0100 Received: (from utz@localhost) by kernelpanix.aura.of.mankind (8.11.2/8.11.2) id g0RELKg01683; Sun, 27 Jan 2002 15:21:20 +0100 X-Authentication-Warning: kernelpanix.aura.of.mankind: utz set sender to xfs@s2y4n2c.de using -f Date: Sun, 27 Jan 2002 15:21:20 +0100 From: utz lehmann To: Stephen Lord Cc: =?iso-8859-1?Q?H=E5kan_Lindqvist?= , Linux XFS Mailing List Subject: Re: Linux 2.4.17-xfs vs previous XFS versions and certain non-us characters in filenames Message-ID: <20020127152120.A1490@s2y4n2c.de> References: <1012101803.1045.28.camel@steelnest> <1012102374.1045.35.camel@steelnest> <3C536F44.1020301@sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <3C536F44.1020301@sgi.com> Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 648 Lines: 24 Hi for your information. I just upgraded my server from 2.4.9-xfs to 2.4.17 CVS. I had this problems too. Stephen Lord [lord@sgi.com] wrote: > There really is no new xfs code in 2.4.17, just some I/O related bug > fixes, nothing > at all to do with directories. Did you switch compilers between building > these > kernel versions? The fact that files created on one kernel cause > problems for the > other is strange, it suggests the hash calculations are coming out > different between > the kernels. Maybe this cause it? TAKE - remove use of -funsigned-char from xfs http://oss.sgi.com/projects/xfs/mail_archive/0201/msg00611.html utz From owner-linux-xfs@oss.sgi.com Sun Jan 27 07:48:00 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0RFm0202565 for linux-xfs-outgoing; Sun, 27 Jan 2002 07:48:00 -0800 Received: from Cantor.suse.de (ns.suse.de [213.95.15.193]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0RFlrP02528 for ; Sun, 27 Jan 2002 07:47:53 -0800 Received: from Hermes.suse.de (Hermes.suse.de [213.95.15.136]) by Cantor.suse.de (Postfix) with ESMTP id 064A31E5F4; Sun, 27 Jan 2002 15:47:46 +0100 (MET) Date: Sun, 27 Jan 2002 15:47:45 +0100 From: Andi Kleen To: utz lehmann Cc: Stephen Lord , H?kan Lindqvist , Linux XFS Mailing List Subject: Re: Linux 2.4.17-xfs vs previous XFS versions and certain non-us characters in filenames Message-ID: <20020127154745.A20990@wotan.suse.de> References: <1012101803.1045.28.camel@steelnest> <1012102374.1045.35.camel@steelnest> <3C536F44.1020301@sgi.com> <20020127152120.A1490@s2y4n2c.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20020127152120.A1490@s2y4n2c.de> User-Agent: Mutt/1.3.22.1i Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 1512 Lines: 46 On Sun, Jan 27, 2002 at 03:21:20PM +0100, utz lehmann wrote: > Maybe this cause it? > > TAKE - remove use of -funsigned-char from xfs > http://oss.sgi.com/projects/xfs/mail_archive/0201/msg00611.html Looks very likely. Try this patch: Index: linux/fs/xfs/xfs_da_btree.c =================================================================== RCS file: /cvs/linux-2.4-xfs/linux/fs/xfs/xfs_da_btree.c,v retrieving revision 1.119 diff -u -u -r1.119 xfs_da_btree.c --- linux/fs/xfs/xfs_da_btree.c 2001/07/02 18:15:34 1.119 +++ linux/fs/xfs/xfs_da_btree.c 2002/01/27 15:44:38 @@ -1592,7 +1592,7 @@ * This is implemented with some source-level loop unrolling. */ xfs_dahash_t -xfs_da_hashname(char *name, int namelen) +xfs_da_hashname(unsigned char *name, int namelen) { xfs_dahash_t hash; Index: linux/fs/xfs/xfs_da_btree.h =================================================================== RCS file: /cvs/linux-2.4-xfs/linux/fs/xfs/xfs_da_btree.h,v retrieving revision 1.40 diff -u -u -r1.40 xfs_da_btree.h --- linux/fs/xfs/xfs_da_btree.h 2000/09/25 05:42:07 1.40 +++ linux/fs/xfs/xfs_da_btree.h 2002/01/27 15:44:38 @@ -322,7 +322,7 @@ int xfs_da_shrink_inode(xfs_da_args_t *args, xfs_dablk_t dead_blkno, xfs_dabuf_t *dead_buf); -uint xfs_da_hashname(char *name_string, int name_length); +uint xfs_da_hashname(unsigned char *name_string, int name_length); uint xfs_da_log2_roundup(uint i); xfs_da_state_t *xfs_da_state_alloc(void); void xfs_da_state_free(xfs_da_state_t *state); -Andi From owner-linux-xfs@oss.sgi.com Sun Jan 27 08:05:15 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0RG5FU05651 for linux-xfs-outgoing; Sun, 27 Jan 2002 08:05:15 -0800 Received: from steelnest.at.home (qmailr@as1-6-7.lio.s.bonet.se [217.215.28.251]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0RG53P05602 for ; Sun, 27 Jan 2002 08:05:05 -0800 Received: (qmail 950 invoked from network); 27 Jan 2002 15:04:58 -0000 Received: from unknown (HELO localhost.localdomain) (127.0.0.1) by 0 with SMTP; 27 Jan 2002 15:04:58 -0000 Subject: Re: Linux 2.4.17-xfs vs previous XFS versions and certain non-us characters in filenames From: =?ISO-8859-1?Q?H=E5kan?= Lindqvist To: Andi Kleen Cc: utz lehmann , Stephen Lord , Linux XFS Mailing List In-Reply-To: <20020127154745.A20990@wotan.suse.de> References: <1012101803.1045.28.camel@steelnest> <1012102374.1045.35.camel@steelnest> <3C536F44.1020301@sgi.com> <20020127152120.A1490@s2y4n2c.de> <20020127154745.A20990@wotan.suse.de> Content-Type: text/plain; charset=ISO-8859-1 X-Mailer: Evolution/1.0.1 Date: 27 Jan 2002 16:04:58 +0100 Message-Id: <1012143898.923.1.camel@steelnest> Mime-Version: 1.0 X-AntiVirus: scanned for viruses by AMaViS 0.2.1 (http://amavis.org/) Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id g0RG56P05607 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 1782 Lines: 59 Andi and Utz, I love you guys! :) (This patch made things work just fine again! *hint hint*) Thanks a lot everyone! /Håkan On Sun, 2002-01-27 at 15:47, Andi Kleen wrote: > On Sun, Jan 27, 2002 at 03:21:20PM +0100, utz lehmann wrote: > > Maybe this cause it? > > > > TAKE - remove use of -funsigned-char from xfs > > http://oss.sgi.com/projects/xfs/mail_archive/0201/msg00611.html > > Looks very likely. Try this patch: > > > Index: linux/fs/xfs/xfs_da_btree.c > =================================================================== > RCS file: /cvs/linux-2.4-xfs/linux/fs/xfs/xfs_da_btree.c,v > retrieving revision 1.119 > diff -u -u -r1.119 xfs_da_btree.c > --- linux/fs/xfs/xfs_da_btree.c 2001/07/02 18:15:34 1.119 > +++ linux/fs/xfs/xfs_da_btree.c 2002/01/27 15:44:38 > @@ -1592,7 +1592,7 @@ > * This is implemented with some source-level loop unrolling. > */ > xfs_dahash_t > -xfs_da_hashname(char *name, int namelen) > +xfs_da_hashname(unsigned char *name, int namelen) > { > xfs_dahash_t hash; > > Index: linux/fs/xfs/xfs_da_btree.h > =================================================================== > RCS file: /cvs/linux-2.4-xfs/linux/fs/xfs/xfs_da_btree.h,v > retrieving revision 1.40 > diff -u -u -r1.40 xfs_da_btree.h > --- linux/fs/xfs/xfs_da_btree.h 2000/09/25 05:42:07 1.40 > +++ linux/fs/xfs/xfs_da_btree.h 2002/01/27 15:44:38 > @@ -322,7 +322,7 @@ > int xfs_da_shrink_inode(xfs_da_args_t *args, xfs_dablk_t dead_blkno, > xfs_dabuf_t *dead_buf); > > -uint xfs_da_hashname(char *name_string, int name_length); > +uint xfs_da_hashname(unsigned char *name_string, int name_length); > uint xfs_da_log2_roundup(uint i); > xfs_da_state_t *xfs_da_state_alloc(void); > void xfs_da_state_free(xfs_da_state_t *state); > > > > -Andi > From owner-linux-xfs@oss.sgi.com Sun Jan 27 08:54:31 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0RGsV914071 for linux-xfs-outgoing; Sun, 27 Jan 2002 08:54:31 -0800 Received: from steelnest.at.home (qmailr@as1-6-7.lio.s.bonet.se [217.215.28.251]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0RGsLP14027 for ; Sun, 27 Jan 2002 08:54:22 -0800 Received: (qmail 1709 invoked from network); 27 Jan 2002 15:54:18 -0000 Received: from unknown (HELO localhost.localdomain) (127.0.0.1) by 0 with SMTP; 27 Jan 2002 15:54:18 -0000 Subject: Re: Linux 2.4.17-xfs vs previous XFS versions and certain non-us characters in filenames From: =?ISO-8859-1?Q?H=E5kan?= Lindqvist To: Stephen Lord Cc: Andi Kleen , utz lehmann , Linux XFS Mailing List In-Reply-To: <1012143898.923.1.camel@steelnest> References: <1012101803.1045.28.camel@steelnest> <1012102374.1045.35.camel@steelnest> <3C536F44.1020301@sgi.com> <20020127152120.A1490@s2y4n2c.de> <20020127154745.A20990@wotan.suse.de> <1012143898.923.1.camel@steelnest> Content-Type: text/plain; charset=ISO-8859-1 X-Mailer: Evolution/1.0.1 Date: 27 Jan 2002 16:54:18 +0100 Message-Id: <1012146858.923.6.camel@steelnest> Mime-Version: 1.0 X-AntiVirus: scanned for viruses by AMaViS 0.2.1 (http://amavis.org/) Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id g0RGsMP14028 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 2219 Lines: 73 There is, however, another (perhaps also related) issue! If I create a file named "å" I can't remove it afterwards. touch å ls -lid å 85391093 -rw-r--r-- 1 hawk hawk 6 Jan 27 16:49 å rm å rm: cannot unlink `å': No such file or directory /Håkan On Sun, 2002-01-27 at 16:04, Håkan Lindqvist wrote: > Andi and Utz, I love you guys! :) > > (This patch made things work just fine again! *hint hint*) > > > Thanks a lot everyone! > > /Håkan > > > On Sun, 2002-01-27 at 15:47, Andi Kleen wrote: > > On Sun, Jan 27, 2002 at 03:21:20PM +0100, utz lehmann wrote: > > > Maybe this cause it? > > > > > > TAKE - remove use of -funsigned-char from xfs > > > http://oss.sgi.com/projects/xfs/mail_archive/0201/msg00611.html > > > > Looks very likely. Try this patch: > > > > > > Index: linux/fs/xfs/xfs_da_btree.c > > =================================================================== > > RCS file: /cvs/linux-2.4-xfs/linux/fs/xfs/xfs_da_btree.c,v > > retrieving revision 1.119 > > diff -u -u -r1.119 xfs_da_btree.c > > --- linux/fs/xfs/xfs_da_btree.c 2001/07/02 18:15:34 1.119 > > +++ linux/fs/xfs/xfs_da_btree.c 2002/01/27 15:44:38 > > @@ -1592,7 +1592,7 @@ > > * This is implemented with some source-level loop unrolling. > > */ > > xfs_dahash_t > > -xfs_da_hashname(char *name, int namelen) > > +xfs_da_hashname(unsigned char *name, int namelen) > > { > > xfs_dahash_t hash; > > > > Index: linux/fs/xfs/xfs_da_btree.h > > =================================================================== > > RCS file: /cvs/linux-2.4-xfs/linux/fs/xfs/xfs_da_btree.h,v > > retrieving revision 1.40 > > diff -u -u -r1.40 xfs_da_btree.h > > --- linux/fs/xfs/xfs_da_btree.h 2000/09/25 05:42:07 1.40 > > +++ linux/fs/xfs/xfs_da_btree.h 2002/01/27 15:44:38 > > @@ -322,7 +322,7 @@ > > int xfs_da_shrink_inode(xfs_da_args_t *args, xfs_dablk_t dead_blkno, > > xfs_dabuf_t *dead_buf); > > > > -uint xfs_da_hashname(char *name_string, int name_length); > > +uint xfs_da_hashname(unsigned char *name_string, int name_length); > > uint xfs_da_log2_roundup(uint i); > > xfs_da_state_t *xfs_da_state_alloc(void); > > void xfs_da_state_free(xfs_da_state_t *state); > > > > > > > > -Andi > > > > From owner-linux-xfs@oss.sgi.com Sun Jan 27 09:05:41 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0RH5fH16111 for linux-xfs-outgoing; Sun, 27 Jan 2002 09:05:41 -0800 Received: from moutvdom01.kundenserver.de (moutvdom01.kundenserver.de [195.20.224.200]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0RH5TP16062 for ; Sun, 27 Jan 2002 09:05:30 -0800 Received: from [195.20.224.204] (helo=mrvdom00.kundenserver.de) by moutvdom01.kundenserver.de with esmtp (Exim 2.12 #2) id 16Uro6-0000xK-00; Sun, 27 Jan 2002 17:05:26 +0100 Received: from [80.129.53.145] (helo=kernelpanix.aura.of.mankind) by mrvdom00.kundenserver.de with esmtp (Exim 2.12 #2) id 16Uro6-0008A2-00; Sun, 27 Jan 2002 17:05:26 +0100 Received: (from utz@localhost) by kernelpanix.aura.of.mankind (8.11.2/8.11.2) id g0RG1o200995; Sun, 27 Jan 2002 17:01:50 +0100 X-Authentication-Warning: kernelpanix.aura.of.mankind: utz set sender to xfs@s2y4n2c.de using -f Date: Sun, 27 Jan 2002 17:01:50 +0100 From: utz lehmann To: =?iso-8859-1?Q?H=E5kan_Lindqvist?= Cc: Stephen Lord , Andi Kleen , utz lehmann , Linux XFS Mailing List Subject: Re: Linux 2.4.17-xfs vs previous XFS versions and certain non-us characters in filenames Message-ID: <20020127170149.A975@s2y4n2c.de> References: <1012101803.1045.28.camel@steelnest> <1012102374.1045.35.camel@steelnest> <3C536F44.1020301@sgi.com> <20020127152120.A1490@s2y4n2c.de> <20020127154745.A20990@wotan.suse.de> <1012143898.923.1.camel@steelnest> <1012146858.923.6.camel@steelnest> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit User-Agent: Mutt/1.2.5i In-Reply-To: <1012146858.923.6.camel@steelnest> Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 2751 Lines: 91 Hi The patch fix it not completly. Filenames beginning with an umlaut are still broken. ls: ümläüté-sucken: No such file or directory ls: äääaaa: No such file or directory 2.4.9-ümläüté-sucken aaaäää All file were created with 2.4.9 and listed with 2.4.17 + Andi's patch. Håkan, can you test a file named "aå". I think it will ok. utz Håkan Lindqvist [lindqvist@netstar.se] wrote: > There is, however, another (perhaps also related) issue! > If I create a file named "å" I can't remove it afterwards. > > touch å > ls -lid å > 85391093 -rw-r--r-- 1 hawk hawk 6 Jan 27 16:49 å > rm å > rm: cannot unlink `å': No such file or directory > > /Håkan > > On Sun, 2002-01-27 at 16:04, Håkan Lindqvist wrote: > > Andi and Utz, I love you guys! :) > > > > (This patch made things work just fine again! *hint hint*) > > > > > > Thanks a lot everyone! > > > > /Håkan > > > > > > On Sun, 2002-01-27 at 15:47, Andi Kleen wrote: > > > On Sun, Jan 27, 2002 at 03:21:20PM +0100, utz lehmann wrote: > > > > Maybe this cause it? > > > > > > > > TAKE - remove use of -funsigned-char from xfs > > > > http://oss.sgi.com/projects/xfs/mail_archive/0201/msg00611.html > > > > > > Looks very likely. Try this patch: > > > > > > > > > Index: linux/fs/xfs/xfs_da_btree.c > > > =================================================================== > > > RCS file: /cvs/linux-2.4-xfs/linux/fs/xfs/xfs_da_btree.c,v > > > retrieving revision 1.119 > > > diff -u -u -r1.119 xfs_da_btree.c > > > --- linux/fs/xfs/xfs_da_btree.c 2001/07/02 18:15:34 1.119 > > > +++ linux/fs/xfs/xfs_da_btree.c 2002/01/27 15:44:38 > > > @@ -1592,7 +1592,7 @@ > > > * This is implemented with some source-level loop unrolling. > > > */ > > > xfs_dahash_t > > > -xfs_da_hashname(char *name, int namelen) > > > +xfs_da_hashname(unsigned char *name, int namelen) > > > { > > > xfs_dahash_t hash; > > > > > > Index: linux/fs/xfs/xfs_da_btree.h > > > =================================================================== > > > RCS file: /cvs/linux-2.4-xfs/linux/fs/xfs/xfs_da_btree.h,v > > > retrieving revision 1.40 > > > diff -u -u -r1.40 xfs_da_btree.h > > > --- linux/fs/xfs/xfs_da_btree.h 2000/09/25 05:42:07 1.40 > > > +++ linux/fs/xfs/xfs_da_btree.h 2002/01/27 15:44:38 > > > @@ -322,7 +322,7 @@ > > > int xfs_da_shrink_inode(xfs_da_args_t *args, xfs_dablk_t dead_blkno, > > > xfs_dabuf_t *dead_buf); > > > > > > -uint xfs_da_hashname(char *name_string, int name_length); > > > +uint xfs_da_hashname(unsigned char *name_string, int name_length); > > > uint xfs_da_log2_roundup(uint i); > > > xfs_da_state_t *xfs_da_state_alloc(void); > > > void xfs_da_state_free(xfs_da_state_t *state); > > > > > > > > > > > > -Andi > > > > > > > > From owner-linux-xfs@oss.sgi.com Sun Jan 27 09:09:55 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0RH9tw16842 for linux-xfs-outgoing; Sun, 27 Jan 2002 09:09:55 -0800 Received: from steelnest.at.home (qmailr@as1-6-7.lio.s.bonet.se [217.215.28.251]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0RH9hP16796 for ; Sun, 27 Jan 2002 09:09:43 -0800 Received: (qmail 1027 invoked from network); 27 Jan 2002 16:09:39 -0000 Received: from unknown (HELO localhost.localdomain) (127.0.0.1) by 0 with SMTP; 27 Jan 2002 16:09:39 -0000 Subject: Re: Linux 2.4.17-xfs vs previous XFS versions and certain non-us characters in filenames From: =?ISO-8859-1?Q?H=E5kan?= Lindqvist To: utz lehmann Cc: Stephen Lord , Andi Kleen , Linux XFS Mailing List In-Reply-To: <20020127170149.A975@s2y4n2c.de> References: <1012101803.1045.28.camel@steelnest> <1012102374.1045.35.camel@steelnest> <3C536F44.1020301@sgi.com> <20020127152120.A1490@s2y4n2c.de> <20020127154745.A20990@wotan.suse.de> <1012143898.923.1.camel@steelnest> <1012146858.923.6.camel@steelnest> <20020127170149.A975@s2y4n2c.de> Content-Type: text/plain; charset=ISO-8859-1 X-Mailer: Evolution/1.0.1 Date: 27 Jan 2002 17:09:39 +0100 Message-Id: <1012147779.988.4.camel@steelnest> Mime-Version: 1.0 X-AntiVirus: scanned for viruses by AMaViS 0.2.1 (http://amavis.org/) Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id g0RH9iP16801 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 3386 Lines: 106 Hi! Well... that's one of the things I tested first, and I found that to work... (and mailed those good results to the list). Also, when I switch back to 2.4.16-xfs _again_ I could remove the "å"-file I had just created under 2.4.17-xfs, which made me feel a little bit better... as that showed that at least the FS integrity was ok, eventhough 2.4.17-xfs even after that patch is a bit shaky. /Håkan On Sun, 2002-01-27 at 17:01, utz lehmann wrote: > Hi > > The patch fix it not completly. Filenames beginning with an umlaut are still > broken. > > ls: ümläüté-sucken: No such file or directory > ls: äääaaa: No such file or directory > 2.4.9-ümläüté-sucken > aaaäää > > All file were created with 2.4.9 and listed with 2.4.17 + Andi's patch. > > Håkan, can you test a file named "aå". I think it will ok. > > > utz > > Håkan Lindqvist [lindqvist@netstar.se] wrote: > > There is, however, another (perhaps also related) issue! > > If I create a file named "å" I can't remove it afterwards. > > > > touch å > > ls -lid å > > 85391093 -rw-r--r-- 1 hawk hawk 6 Jan 27 16:49 å > > rm å > > rm: cannot unlink `å': No such file or directory > > > > /Håkan > > > > On Sun, 2002-01-27 at 16:04, Håkan Lindqvist wrote: > > > Andi and Utz, I love you guys! :) > > > > > > (This patch made things work just fine again! *hint hint*) > > > > > > > > > Thanks a lot everyone! > > > > > > /Håkan > > > > > > > > > On Sun, 2002-01-27 at 15:47, Andi Kleen wrote: > > > > On Sun, Jan 27, 2002 at 03:21:20PM +0100, utz lehmann wrote: > > > > > Maybe this cause it? > > > > > > > > > > TAKE - remove use of -funsigned-char from xfs > > > > > http://oss.sgi.com/projects/xfs/mail_archive/0201/msg00611.html > > > > > > > > Looks very likely. Try this patch: > > > > > > > > > > > > Index: linux/fs/xfs/xfs_da_btree.c > > > > =================================================================== > > > > RCS file: /cvs/linux-2.4-xfs/linux/fs/xfs/xfs_da_btree.c,v > > > > retrieving revision 1.119 > > > > diff -u -u -r1.119 xfs_da_btree.c > > > > --- linux/fs/xfs/xfs_da_btree.c 2001/07/02 18:15:34 1.119 > > > > +++ linux/fs/xfs/xfs_da_btree.c 2002/01/27 15:44:38 > > > > @@ -1592,7 +1592,7 @@ > > > > * This is implemented with some source-level loop unrolling. > > > > */ > > > > xfs_dahash_t > > > > -xfs_da_hashname(char *name, int namelen) > > > > +xfs_da_hashname(unsigned char *name, int namelen) > > > > { > > > > xfs_dahash_t hash; > > > > > > > > Index: linux/fs/xfs/xfs_da_btree.h > > > > =================================================================== > > > > RCS file: /cvs/linux-2.4-xfs/linux/fs/xfs/xfs_da_btree.h,v > > > > retrieving revision 1.40 > > > > diff -u -u -r1.40 xfs_da_btree.h > > > > --- linux/fs/xfs/xfs_da_btree.h 2000/09/25 05:42:07 1.40 > > > > +++ linux/fs/xfs/xfs_da_btree.h 2002/01/27 15:44:38 > > > > @@ -322,7 +322,7 @@ > > > > int xfs_da_shrink_inode(xfs_da_args_t *args, xfs_dablk_t dead_blkno, > > > > xfs_dabuf_t *dead_buf); > > > > > > > > -uint xfs_da_hashname(char *name_string, int name_length); > > > > +uint xfs_da_hashname(unsigned char *name_string, int name_length); > > > > uint xfs_da_log2_roundup(uint i); > > > > xfs_da_state_t *xfs_da_state_alloc(void); > > > > void xfs_da_state_free(xfs_da_state_t *state); > > > > > > > > > > > > > > > > -Andi > > > > > > > > > > > > From owner-linux-xfs@oss.sgi.com Sun Jan 27 09:27:19 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0RHRJH19426 for linux-xfs-outgoing; Sun, 27 Jan 2002 09:27:19 -0800 Received: from ente.berdmann.de (frnk-d514e107.dsl.mediaWays.net [213.20.225.7]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0RHR9P19377 for ; Sun, 27 Jan 2002 09:27:09 -0800 Received: from apollo.berdmann.de ([192.168.1.2] helo=berdmann.de) by ente.berdmann.de with esmtp (Exim 3.22 #1) id 16Us8x-0000cO-00; Sun, 27 Jan 2002 17:26:59 +0100 Message-ID: <3C542A26.F204520C@berdmann.de> Date: Sun, 27 Jan 2002 17:26:14 +0100 From: "Bernhard R. Erdmann" X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.4.17-xfs i586) X-Accept-Language: de, en, fr MIME-Version: 1.0 To: "amanda-users@amanda.org" , Linux XFS Mailing List Subject: Using Amanda with Linux/XFS: "failed to get (valid) bulkstat information" Content-Type: multipart/mixed; boundary="------------06CCED7E3468A8B3C5CF2613" Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 1987 Lines: 56 This is a multi-part message in MIME format. --------------06CCED7E3468A8B3C5CF2613 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi, here's a patch for Amanda 2.4.2p2 to ignore xfsdump's occasionally output on busy filesystems "WARNING: failed to get bulkstat information for inode ..." and "WARNING: failed to get valid bulkstat information for inode ...". --------------06CCED7E3468A8B3C5CF2613 Content-Type: text/plain; charset=us-ascii; name="amanda-sendbackup-xfs-bulkstat.diff" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="amanda-sendbackup-xfs-bulkstat.diff" --- amanda-2.4.2p2-20011020.orig/client-src/sendbackup-dump.c Sat Oct 20 15:59:20 2001 +++ amanda-2.4.2p2-20011020/client-src/sendbackup-dump.c Sun Jan 27 11:56:18 2002 @@ -97,6 +97,10 @@ { DMP_SIZE, "xfsdump: media file size [0-9][0-9]* bytes", 1}, /* Irix 6.2 xfs dump */ + /* warnings to be ignored */ + { DMP_WARNING, "^xfsdump: WARNING: failed to get valid bulkstat information for inode" }, /* Linux xfsdump */ + { DMP_WARNING, "^xfsdump: WARNING: failed to get bulkstat information for inode" }, /* Linux xfsdump */ + /* strange dump lines */ { DMP_STRANGE, "should not happen" }, { DMP_STRANGE, "Cannot open" }, --- amanda-2.4.2p2-20011020.orig/client-src/sendbackup.c Sat Oct 20 15:59:20 2001 +++ amanda-2.4.2p2-20011020/client-src/sendbackup.c Sun Jan 27 11:51:50 2002 @@ -755,6 +755,7 @@ switch(typ) { case DMP_NORMAL: case DMP_SIZE: + case DMP_WARNING: startchr = '|'; break; default: --- amanda-2.4.2p2-20011020.orig/client-src/sendbackup.h Sat May 27 23:20:32 2000 +++ amanda-2.4.2p2-20011020/client-src/sendbackup.h Sun Jan 27 11:51:50 2002 @@ -53,7 +53,7 @@ */ typedef enum { - DMP_NORMAL, DMP_STRANGE, DMP_SIZE, DMP_ERROR + DMP_NORMAL, DMP_WARNING, DMP_STRANGE, DMP_SIZE, DMP_ERROR } dmpline_t; typedef struct regex_s { --------------06CCED7E3468A8B3C5CF2613-- From owner-linux-xfs@oss.sgi.com Sun Jan 27 09:30:12 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0RHUCN19937 for linux-xfs-outgoing; Sun, 27 Jan 2002 09:30:12 -0800 Received: from Cantor.suse.de (ns.suse.de [213.95.15.193]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0RHU9P19910 for ; Sun, 27 Jan 2002 09:30:09 -0800 Received: from Hermes.suse.de (Hermes.suse.de [213.95.15.136]) by Cantor.suse.de (Postfix) with ESMTP id D54D11E6C7; Sun, 27 Jan 2002 17:29:58 +0100 (MET) Date: Sun, 27 Jan 2002 17:29:58 +0100 From: Andi Kleen To: H?kan Lindqvist Cc: Stephen Lord , Andi Kleen , utz lehmann , Linux XFS Mailing List Subject: Re: Linux 2.4.17-xfs vs previous XFS versions and certain non-us characters in filenames Message-ID: <20020127172958.A8796@wotan.suse.de> References: <1012101803.1045.28.camel@steelnest> <1012102374.1045.35.camel@steelnest> <3C536F44.1020301@sgi.com> <20020127152120.A1490@s2y4n2c.de> <20020127154745.A20990@wotan.suse.de> <1012143898.923.1.camel@steelnest> <1012146858.923.6.camel@steelnest> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1012146858.923.6.camel@steelnest> User-Agent: Mutt/1.3.22.1i Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 252 Lines: 8 On Sun, Jan 27, 2002 at 04:54:18PM +0100, H?kan Lindqvist wrote: > There is, however, another (perhaps also related) issue! > If I create a file named "?" I can't remove it afterwards. Is this a real ? or a ascii unprintable character >127 ? -Andi From owner-linux-xfs@oss.sgi.com Sun Jan 27 10:15:01 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0RIF1T26549 for linux-xfs-outgoing; Sun, 27 Jan 2002 10:15:01 -0800 Received: from yog-sothoth.sgi.com (eugate.sgi.com [192.48.160.10]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0RIEpP26496 for ; Sun, 27 Jan 2002 10:14:51 -0800 Received: from zeus-e8.americas.sgi.com (zeus-e8.americas.sgi.com [128.162.8.103]) by yog-sothoth.sgi.com (980305.SGI.8.8.8-aspam-6.2/980304.SGI-aspam-europe) via ESMTP id SAA961015 for ; Sun, 27 Jan 2002 18:14:33 +0100 (CET) mail_from (lord@sgi.com) Received: from tulip-e185.americas.sgi.com (tulip-e185.americas.sgi.com [128.162.185.208]) by zeus-e8.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id LAA174291; Sun, 27 Jan 2002 11:13:29 -0600 (CST) Received: from sgi.com (BixBYgxVDSmVLhwF9n2FZBEBTTdLPRz3@lord-h1.americas.sgi.com [206.11.101.42]) by tulip-e185.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.7) with ESMTP id LAA65282; Sun, 27 Jan 2002 11:13:29 -0600 (CST) Message-ID: <3C54352B.60505@sgi.com> Date: Sun, 27 Jan 2002 11:13:15 -0600 From: Stephen Lord User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.7) Gecko/20011226 X-Accept-Language: en-us MIME-Version: 1.0 To: =?ISO-8859-1?Q?H=E5kan?= Lindqvist CC: Andi Kleen , utz lehmann , Linux XFS Mailing List Subject: Re: Linux 2.4.17-xfs vs previous XFS versions and certain non-us characters in filenames References: <1012101803.1045.28.camel@steelnest> <1012102374.1045.35.camel@steelnest> <3C536F44.1020301@sgi.com> <20020127152120.A1490@s2y4n2c.de> <20020127154745.A20990@wotan.suse.de> <1012143898.923.1.camel@steelnest> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 2203 Lines: 76 Hekan Lindqvist wrote: >Andi and Utz, I love you guys! :) > >(This patch made things work just fine again! *hint hint*) > > >Thanks a lot everyone! > >/Hekan > > >On Sun, 2002-01-27 at 15:47, Andi Kleen wrote: > >>On Sun, Jan 27, 2002 at 03:21:20PM +0100, utz lehmann wrote: >> >>>Maybe this cause it? >>> >>>TAKE - remove use of -funsigned-char from xfs >>>http://oss.sgi.com/projects/xfs/mail_archive/0201/msg00611.html >>> >>Looks very likely. Try this patch: >> >> >>Index: linux/fs/xfs/xfs_da_btree.c >>=================================================================== >>RCS file: /cvs/linux-2.4-xfs/linux/fs/xfs/xfs_da_btree.c,v >>retrieving revision 1.119 >>diff -u -u -r1.119 xfs_da_btree.c >>--- linux/fs/xfs/xfs_da_btree.c 2001/07/02 18:15:34 1.119 >>+++ linux/fs/xfs/xfs_da_btree.c 2002/01/27 15:44:38 >>@@ -1592,7 +1592,7 @@ >> * This is implemented with some source-level loop unrolling. >> */ >> xfs_dahash_t >>-xfs_da_hashname(char *name, int namelen) >>+xfs_da_hashname(unsigned char *name, int namelen) >> { >> xfs_dahash_t hash; >> >>Index: linux/fs/xfs/xfs_da_btree.h >>=================================================================== >>RCS file: /cvs/linux-2.4-xfs/linux/fs/xfs/xfs_da_btree.h,v >>retrieving revision 1.40 >>diff -u -u -r1.40 xfs_da_btree.h >>--- linux/fs/xfs/xfs_da_btree.h 2000/09/25 05:42:07 1.40 >>+++ linux/fs/xfs/xfs_da_btree.h 2002/01/27 15:44:38 >>@@ -322,7 +322,7 @@ >> int xfs_da_shrink_inode(xfs_da_args_t *args, xfs_dablk_t dead_blkno, >> xfs_dabuf_t *dead_buf); >> >>-uint xfs_da_hashname(char *name_string, int name_length); >>+uint xfs_da_hashname(unsigned char *name_string, int name_length); >> uint xfs_da_log2_roundup(uint i); >> xfs_da_state_t *xfs_da_state_alloc(void); >> void xfs_da_state_free(xfs_da_state_t *state); >> >> >> >>-Andi >> > > Woops, sorry, I forgot about the unsigned char change, since I use English characters with the top bit set did not occur to me. I will take a look through the other obvious places and see what else I can come up with. You can work around this by putting -f unsigned-char back into the Makefiles in fs/xfs and fs/xfs/linux, just add it to the EXTRA_CFLAGS definition. Steve From owner-linux-xfs@oss.sgi.com Sun Jan 27 10:18:24 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0RIIOa27186 for linux-xfs-outgoing; Sun, 27 Jan 2002 10:18:24 -0800 Received: from steelnest.at.home (qmailr@as1-6-7.lio.s.bonet.se [217.215.28.251]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0RIIDP27135 for ; Sun, 27 Jan 2002 10:18:13 -0800 Received: (qmail 1922 invoked from network); 27 Jan 2002 17:18:08 -0000 Received: from unknown (HELO localhost.localdomain) (127.0.0.1) by 0 with SMTP; 27 Jan 2002 17:18:08 -0000 Subject: Re: Linux 2.4.17-xfs vs previous XFS versions and certain non-us characters in filenames From: =?ISO-8859-1?Q?H=E5kan?= Lindqvist To: Stephen Lord Cc: Andi Kleen , utz lehmann , Linux XFS Mailing List In-Reply-To: <3C54352B.60505@sgi.com> References: <1012101803.1045.28.camel@steelnest> <1012102374.1045.35.camel@steelnest> <3C536F44.1020301@sgi.com> <20020127152120.A1490@s2y4n2c.de> <20020127154745.A20990@wotan.suse.de> <1012143898.923.1.camel@steelnest> <3C54352B.60505@sgi.com> Content-Type: text/plain; charset=ISO-8859-1 X-Mailer: Evolution/1.0.1 Date: 27 Jan 2002 18:18:08 +0100 Message-Id: <1012151888.988.11.camel@steelnest> Mime-Version: 1.0 X-AntiVirus: scanned for viruses by AMaViS 0.2.1 (http://amavis.org/) Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id g0RIIEP27139 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 2599 Lines: 88 Thanks Stephen, I'm not sure about your policy about the CVS repository, but maybe you ought to make this change in the CVS repository until the code has been somewhat more audited? /Håkan On Sun, 2002-01-27 at 18:13, Stephen Lord wrote: > Hekan Lindqvist wrote: > > >Andi and Utz, I love you guys! :) > > > >(This patch made things work just fine again! *hint hint*) > > > > > >Thanks a lot everyone! > > > >/Hekan > > > > > >On Sun, 2002-01-27 at 15:47, Andi Kleen wrote: > > > >>On Sun, Jan 27, 2002 at 03:21:20PM +0100, utz lehmann wrote: > >> > >>>Maybe this cause it? > >>> > >>>TAKE - remove use of -funsigned-char from xfs > >>>http://oss.sgi.com/projects/xfs/mail_archive/0201/msg00611.html > >>> > >>Looks very likely. Try this patch: > >> > >> > >>Index: linux/fs/xfs/xfs_da_btree.c > >>=================================================================== > >>RCS file: /cvs/linux-2.4-xfs/linux/fs/xfs/xfs_da_btree.c,v > >>retrieving revision 1.119 > >>diff -u -u -r1.119 xfs_da_btree.c > >>--- linux/fs/xfs/xfs_da_btree.c 2001/07/02 18:15:34 1.119 > >>+++ linux/fs/xfs/xfs_da_btree.c 2002/01/27 15:44:38 > >>@@ -1592,7 +1592,7 @@ > >> * This is implemented with some source-level loop unrolling. > >> */ > >> xfs_dahash_t > >>-xfs_da_hashname(char *name, int namelen) > >>+xfs_da_hashname(unsigned char *name, int namelen) > >> { > >> xfs_dahash_t hash; > >> > >>Index: linux/fs/xfs/xfs_da_btree.h > >>=================================================================== > >>RCS file: /cvs/linux-2.4-xfs/linux/fs/xfs/xfs_da_btree.h,v > >>retrieving revision 1.40 > >>diff -u -u -r1.40 xfs_da_btree.h > >>--- linux/fs/xfs/xfs_da_btree.h 2000/09/25 05:42:07 1.40 > >>+++ linux/fs/xfs/xfs_da_btree.h 2002/01/27 15:44:38 > >>@@ -322,7 +322,7 @@ > >> int xfs_da_shrink_inode(xfs_da_args_t *args, xfs_dablk_t dead_blkno, > >> xfs_dabuf_t *dead_buf); > >> > >>-uint xfs_da_hashname(char *name_string, int name_length); > >>+uint xfs_da_hashname(unsigned char *name_string, int name_length); > >> uint xfs_da_log2_roundup(uint i); > >> xfs_da_state_t *xfs_da_state_alloc(void); > >> void xfs_da_state_free(xfs_da_state_t *state); > >> > >> > >> > >>-Andi > >> > > > > > Woops, sorry, I forgot about the unsigned char change, since I use English > characters with the top bit set did not occur to me. I will take a look > through the > other obvious places and see what else I can come up with. You can work > around > this by putting -f unsigned-char back into the Makefiles in fs/xfs and > fs/xfs/linux, > just add it to the EXTRA_CFLAGS definition. > > Steve > > > From owner-linux-xfs@oss.sgi.com Sun Jan 27 10:23:02 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0RIN2q27921 for linux-xfs-outgoing; Sun, 27 Jan 2002 10:23:02 -0800 Received: from zok.sgi.com (zok.SGI.COM [204.94.215.101]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0RIMwP27886 for ; Sun, 27 Jan 2002 10:22:58 -0800 Received: from zeus-e8.americas.sgi.com (zeus-e8.americas.sgi.com [128.162.8.103]) by zok.sgi.com (8.11.4/8.11.4/linux-outbound_gateway-1.1) with ESMTP id g0RHMpo21457 for ; Sun, 27 Jan 2002 09:22:51 -0800 Received: from tulip-e185.americas.sgi.com (tulip-e185.americas.sgi.com [128.162.185.208]) by zeus-e8.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id LAA174339; Sun, 27 Jan 2002 11:21:35 -0600 (CST) Received: from sgi.com (IJLoMYPygk4H8niYClzmt4B3dj9RtoQc@lord-h1.americas.sgi.com [206.11.101.42]) by tulip-e185.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.7) with ESMTP id LAA68809; Sun, 27 Jan 2002 11:21:34 -0600 (CST) Message-ID: <3C543711.5030704@sgi.com> Date: Sun, 27 Jan 2002 11:21:21 -0600 From: Stephen Lord User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.7) Gecko/20011226 X-Accept-Language: en-us MIME-Version: 1.0 To: =?ISO-8859-1?Q?H=E5kan?= Lindqvist CC: Andi Kleen , utz lehmann , Linux XFS Mailing List Subject: Re: Linux 2.4.17-xfs vs previous XFS versions and certain non-us characters in filenames References: <1012101803.1045.28.camel@steelnest> <1012102374.1045.35.camel@steelnest> <3C536F44.1020301@sgi.com> <20020127152120.A1490@s2y4n2c.de> <20020127154745.A20990@wotan.suse.de> <1012143898.923.1.camel@steelnest> <3C54352B.60505@sgi.com> <1012151888.988.11.camel@steelnest> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 639 Lines: 30 Hekan Lindqvist wrote: >Thanks Stephen, > >I'm not sure about your policy about the CVS repository, but maybe you >ought to make this change in the CVS repository until the code has been >somewhat more audited? > >/Hekan > > I suppose so, but we would never have found this internally, so putting it out there was beneficial - the reason for doing this was because spinlock debugging and xfs were totally incompatible and people kept turning it on, and generating oopses we could not understand (since they did not always mention spinlock debugging was on....). Ho hum, not been a good week for me breaking things.... Steve > > From owner-linux-xfs@oss.sgi.com Sun Jan 27 10:24:55 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0RIOtQ28331 for linux-xfs-outgoing; Sun, 27 Jan 2002 10:24:55 -0800 Received: from mailhost.idcomm.com (mailhost.idcomm.com [207.40.196.14]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0RIOqP28303 for ; Sun, 27 Jan 2002 10:24:52 -0800 Received: from idcomm.com (IDENT:3vruKkAt7hTQPEMzAVutZ0h4frUdeJAz@k56-pip27.idcomm.com [209.60.72.154]) by mailhost.idcomm.com (8.10.2/8.10.0) with ESMTP id g0RHVBx20669 for ; Sun, 27 Jan 2002 10:31:11 -0700 Message-ID: <3C5437F5.3553AAC5@idcomm.com> Date: Sun, 27 Jan 2002 10:25:09 -0700 From: "D. Stimits" Reply-To: stimits@idcomm.com X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.6-pre1-xfs-4 i686) X-Accept-Language: en MIME-Version: 1.0 CC: Linux XFS Mailing List Subject: Re: Linux 2.4.17-xfs vs previous XFS versions and certain non-us characters in filenames References: <1012101803.1045.28.camel@steelnest> <1012102374.1045.35.camel@steelnest> <3C536F44.1020301@sgi.com> <20020127152120.A1490@s2y4n2c.de> <20020127154745.A20990@wotan.suse.de> <1012143898.923.1.camel@steelnest> <1012146858.923.6.camel@steelnest> <20020127172958.A8796@wotan.suse.de> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 748 Lines: 20 Andi Kleen wrote: > > On Sun, Jan 27, 2002 at 04:54:18PM +0100, H?kan Lindqvist wrote: > > There is, however, another (perhaps also related) issue! > > If I create a file named "?" I can't remove it afterwards. > > Is this a real ? or a ascii unprintable character >127 ? > > -Andi I'm curious if the extended characters over 127 from the Latin-1 character set require support at the filesystem level? I imagine that some of the wide character requirements of Japanese kanji would make it rather "interesting" if the filesystem has to actually deal with it. I'm beginning to discover the pain of trying to internationalize software on X11, and curious about how far character sets actually "invade" the system. D. Stimits, stimits@idcomm.com From owner-linux-xfs@oss.sgi.com Sun Jan 27 10:27:40 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0RIReO28871 for linux-xfs-outgoing; Sun, 27 Jan 2002 10:27:40 -0800 Received: from imnetworks.com (mail2.imnetworks.com [208.184.122.59]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0RIRXP28837 for ; Sun, 27 Jan 2002 10:27:33 -0800 Received: from [12.81.3.32] (account ) by imnetworks.com (CommuniGate Pro WebUser 3.4.7) with HTTP id 1498132; Sun, 27 Jan 2002 09:27:31 -0800 From: "Tony Vickers" Subject: Re: Ks.cfg and XFS To: Seth Mos , Tony Vickers Cc: Tony Vickers , X-Mailer: CommuniGate Pro Web Mailer v.3.4.7 Date: Sun, 27 Jan 2002 09:27:31 -0800 Message-ID: In-Reply-To: <4.3.2.7.2.20020126132345.02c62470@pop.xs4all.nl> MIME-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 1988 Lines: 58 I used the XFS installer to install RedHat. And have been using the XFS installer to start my ks.cfg installs. After all the XFS installer asks for the RedHat CD-ROM when installing. So I'm still not clear on what you mean by copying the XFS CD-ROM to a directory last. --Tony On Sat, 26 Jan 2002 13:37:24 +0100 Seth Mos wrote: > At 21:19 25-1-2002 -0800, Tony Vickers wrote: > >I had to reinstall the build system. So I used SGI's XFS installer along > >with RH 7.2's disc #1,#2. So Yes I do have the full XFS stuff. As far as > >coping the XFS CD-ROM files last how can you make sure this happens? I > >looked at the Rev number on the XFS files and they are newer. So if I were > >to assume that the system is smart to use the latest file would I be > >right? Is it also possible that I got by chance a ISO file when I > >downloaded it from SGI? > > Last file copied wins. Copy the XFS installer CDROM to that directory last. > The following order would be correct RH CD1, RH CD2, XFS installer. > > >This is off topic, but, is there a doc on how to make the same type of > >BOOT CD that SGI uses? > > Good question but maybe someone has a small howto on doing that sort of > thing. The reiserfs folks made a lot of adapted Red Hat installer over the > years and I guess most information is available for building your own > installer is available. > > I could find some info on the linuxdoc site with regard to modifying a > installer. Myabe this is of help. > http://www.linuxdoc.org/HOWTO/KickStart-HOWTO.html > > Cheers > > -- > Seth > Every program has two purposes one for which > it was written and another for which it wasn't > I use the last kind. > Tony Tony Vickers Unix-Linux Systems Administrator iM Networks Inc. Work - 650-230-0449 241 Polaris Ave. Cell - 650-580-3542 Mountain View, CA 94043 Fax - 650-967-3924 http://www.imnetworks.com The Linux revolution has started! What side are you on? From owner-linux-xfs@oss.sgi.com Sun Jan 27 10:27:51 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0RIRpq29021 for linux-xfs-outgoing; Sun, 27 Jan 2002 10:27:51 -0800 Received: from steelnest.at.home (qmailr@as1-6-7.lio.s.bonet.se [217.215.28.251]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0RIRiP28937 for ; Sun, 27 Jan 2002 10:27:44 -0800 Received: (qmail 2321 invoked from network); 27 Jan 2002 17:27:40 -0000 Received: from unknown (HELO localhost.localdomain) (127.0.0.1) by 0 with SMTP; 27 Jan 2002 17:27:40 -0000 Subject: Re: Linux 2.4.17-xfs vs previous XFS versions and certain non-us characters in filenames From: =?ISO-8859-1?Q?H=E5kan?= Lindqvist To: Stephen Lord Cc: Andi Kleen , utz lehmann , Linux XFS Mailing List In-Reply-To: <3C543711.5030704@sgi.com> References: <1012101803.1045.28.camel@steelnest> <1012102374.1045.35.camel@steelnest> <3 C536F44.1020301@sgi.com> <20020127152120.A1490@s2y4n2c.de> <20020127154745.A20990@wotan.suse.de> <1012143898.923.1.camel@steelnest> <3C54352B.60505@sgi.com> <1012151888.988.11.camel@steelnest> <3C543711.5030704@sgi.com> Content-Type: text/plain; charset=ISO-8859-1 X-Mailer: Evolution/1.0.1 Date: 27 Jan 2002 18:27:40 +0100 Message-Id: <1012152460.988.17.camel@steelnest> Mime-Version: 1.0 X-AntiVirus: scanned for viruses by AMaViS 0.2.1 (http://amavis.org/) Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id g0RIRjP28949 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 1162 Lines: 42 Well, I agree that this was benifical if you do not test with non-us-ascii characters internally... But now that the problem has been found I have this feeling that it is pointless to let even more people find the same problem if it can be worked around that easily. (Especially as I'm not 100% sure that this does not let you create files that you will have problems with after the fix has been made.) /Håkan On Sun, 2002-01-27 at 18:21, Stephen Lord wrote: > Hekan Lindqvist wrote: > > >Thanks Stephen, > > > >I'm not sure about your policy about the CVS repository, but maybe you > >ought to make this change in the CVS repository until the code has been > >somewhat more audited? > > > >/Hekan > > > > > > I suppose so, but we would never have found this internally, so putting > it out > there was beneficial - the reason for doing this was because spinlock > debugging > and xfs were totally incompatible and people kept turning it on, and > generating > oopses we could not understand (since they did not always mention spinlock > debugging was on....). > > Ho hum, not been a good week for me breaking things.... > > Steve > > > > > > > > From owner-linux-xfs@oss.sgi.com Sun Jan 27 10:36:46 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0RIakF30515 for linux-xfs-outgoing; Sun, 27 Jan 2002 10:36:46 -0800 Received: from sgi.com (sgi-too.SGI.COM [204.94.211.39]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0RIahP30486 for ; Sun, 27 Jan 2002 10:36:43 -0800 Received: from zeus-e8.americas.sgi.com (zeus-e8.americas.sgi.com [128.162.8.103]) by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id JAA08791 for ; Sun, 27 Jan 2002 09:35:32 -0800 (PST) mail_from (lord@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by zeus-e8.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id LAA174488 for ; Sun, 27 Jan 2002 11:35:25 -0600 (CST) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id LAA83927 for ; Sun, 27 Jan 2002 11:35:24 -0600 (CST) From: Steve Lord Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id g0RHXmb01560; Sun, 27 Jan 2002 11:33:48 -0600 Message-Id: <200201271733.g0RHXmb01560@jen.americas.sgi.com> Date: Sun, 27 Jan 2002 11:33:48 -0600 Subject: TAKE - go back to explicit setting of -funsigned-char Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 411 Lines: 18 With apologies to those folks who use more than 7 bits in their file names. Steve Date: Sun Jan 27 09:32:55 PST 2002 Workarea: jen.americas.sgi.com:/src/lord/xfs-linux.2.4 The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:110350a linux/fs/xfs/Makefile - 1.134 linux/fs/xfs/linux/Makefile - 1.48 - Put back explicit setting of -funsigned-char From owner-linux-xfs@oss.sgi.com Sun Jan 27 10:40:53 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0RIerX31364 for linux-xfs-outgoing; Sun, 27 Jan 2002 10:40:53 -0800 Received: from sgi.com (sgi-too.SGI.COM [204.94.211.39]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0RIenP31329 for ; Sun, 27 Jan 2002 10:40:49 -0800 Received: from zeus-e8.americas.sgi.com (zeus-e8.americas.sgi.com [128.162.8.103]) by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id JAB05011 for ; Sun, 27 Jan 2002 09:39:38 -0800 (PST) mail_from (lord@sgi.com) Received: from tulip-e185.americas.sgi.com (tulip-e185.americas.sgi.com [128.162.185.208]) by zeus-e8.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id LAA174072; Sun, 27 Jan 2002 11:39:31 -0600 (CST) Received: from sgi.com (ARTBwq35R7eKclUX4grO5sIuzpnQ97BQ@lord-h1.americas.sgi.com [206.11.101.42]) by tulip-e185.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.7) with ESMTP id LAA65750; Sun, 27 Jan 2002 11:39:30 -0600 (CST) Message-ID: <3C543B45.3000308@sgi.com> Date: Sun, 27 Jan 2002 11:39:17 -0600 From: Stephen Lord User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.7) Gecko/20011226 X-Accept-Language: en-us MIME-Version: 1.0 To: stimits@idcomm.com CC: Linux XFS Mailing List Subject: Re: Linux 2.4.17-xfs vs previous XFS versions and certain non-us characters in filenames References: <1012101803.1045.28.camel@steelnest> <1012102374.1045.35.camel@steelnest> <3C536F44.1020301@sgi.com> <20020127152120.A1490@s2y4n2c.de> <20020127154745.A20990@wotan.suse.de> <1012143898.923.1.camel@steelnest> <1012146858.923.6.camel@steelnest> <20020127172958.A8796@wotan.suse.de> <3C5437F5.3553AAC5@idcomm.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 988 Lines: 33 D. Stimits wrote: >Andi Kleen wrote: > >>On Sun, Jan 27, 2002 at 04:54:18PM +0100, H?kan Lindqvist wrote: >> >>>There is, however, another (perhaps also related) issue! >>>If I create a file named "?" I can't remove it afterwards. >>> >>Is this a real ? or a ascii unprintable character >127 ? >> >>-Andi >> > >I'm curious if the extended characters over 127 from the Latin-1 >character set require support at the filesystem level? I imagine that >some of the wide character requirements of Japanese kanji would make it >rather "interesting" if the filesystem has to actually deal with it. I'm >beginning to discover the pain of trying to internationalize software on >X11, and curious about how far character sets actually "invade" the >system. > >D. Stimits, stimits@idcomm.com > This is something of an xfs special in this case, the hash algorithm used in xfs directories does math on the names, and in removing the -funsigned-char from the Makefiles, I forgot about this. Steve From owner-linux-xfs@oss.sgi.com Sun Jan 27 11:25:57 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0RJPvf05315 for linux-xfs-outgoing; Sun, 27 Jan 2002 11:25:57 -0800 Received: from mailhost.idcomm.com (mailhost.idcomm.com [207.40.196.14]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0RJPnP05272 for ; Sun, 27 Jan 2002 11:25:49 -0800 Received: from idcomm.com (IDENT:BgjN2WY2OqpuKGJzNI562ioRbFtTh+X6@k56-pip62.idcomm.com [209.60.72.189]) by mailhost.idcomm.com (8.10.2/8.10.0) with ESMTP id g0RIW8x27175 for ; Sun, 27 Jan 2002 11:32:08 -0700 Message-ID: <3C54463E.EE19BF02@idcomm.com> Date: Sun, 27 Jan 2002 11:26:06 -0700 From: "D. Stimits" Reply-To: stimits@idcomm.com X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.6-pre1-xfs-4 i686) X-Accept-Language: en MIME-Version: 1.0 CC: Linux XFS Mailing List Subject: Re: Linux 2.4.17-xfs vs previous XFS versions and certain non-us characters in filenames References: <1012101803.1045.28.camel@steelnest> <1012102374.1045.35.camel@steelnest> <3C536F44.1020301@sgi.com> <20020127152120.A1490@s2y4n2c.de> <20020127154745.A20990@wotan.suse.de> <1012143898.923.1.camel@steelnest> <1012146858.923.6.camel@steelnest> <20020127172958.A8796@wotan.suse.de> <3C5437F5.3553AAC5@idcomm.com> <3C543B45.3000308@sgi.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 2747 Lines: 65 Stephen Lord wrote: > > D. Stimits wrote: > > >Andi Kleen wrote: > > > >>On Sun, Jan 27, 2002 at 04:54:18PM +0100, H?kan Lindqvist wrote: > >> > >>>There is, however, another (perhaps also related) issue! > >>>If I create a file named "?" I can't remove it afterwards. > >>> > >>Is this a real ? or a ascii unprintable character >127 ? > >> > >>-Andi > >> > > > >I'm curious if the extended characters over 127 from the Latin-1 > >character set require support at the filesystem level? I imagine that > >some of the wide character requirements of Japanese kanji would make it > >rather "interesting" if the filesystem has to actually deal with it. I'm > >beginning to discover the pain of trying to internationalize software on > >X11, and curious about how far character sets actually "invade" the > >system. > > > >D. Stimits, stimits@idcomm.com > > > > This is something of an xfs special in this case, the hash algorithm > used in xfs > directories does math on the names, and in removing the -funsigned-char from > the Makefiles, I forgot about this. To some degree it reminds me of PostegreSQL. Somewhere in the docs I recall seeing it mention that it works with non-C locales (non-english basically), but that it would then run slower due to no hashing. I guess instead of trying to support other locales at full performance, PostgreSQL (at least the version I read docs on a year or so ago) completely eliminated hashing if different character sets were used. With all the internationalizing going on, and the "world economy" being so much more important in the tech industry, I have to wonder how long it will be before hash routines for all these different character sets becomes common. I tend to do more C++ these days than C, I love the STL containers; hashed versions are common, even if not officially part of any standard, but they lack built-in hash functions for anything but fundamental types and char*. It's hard to realize how important hash functions are until you use a non-ASCII character set. Some of the wide character sets that use 16 bits, also use forms of shifting on top of that (check out kanji). Then there are mixed uses, where more than one character set must be displayed at the same time in the same application, so one has to mark attributes on all the characters for which character set, and switch on the fly; worse, the mix often requires a special scheme not only for mixing character sets, but also to require mixing 7 bit, 8 bit, and 16 bit sets without losing the boundary between characters. I am very curious if anyone running a Japanese locale machine has reported using XFS? I shudder to think about the difficulty. D. Stimits, stimits@idcomm.com D. Stimits, stimits@idcomm.com > > Steve From owner-linux-xfs@oss.sgi.com Sun Jan 27 11:48:05 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0RJm5L08520 for linux-xfs-outgoing; Sun, 27 Jan 2002 11:48:05 -0800 Received: from coredump.sh0n.net (qmailremote@CPEdeadbeef0000.cpe.net.cable.rogers.com [24.100.234.67]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0RJm0P08489 for ; Sun, 27 Jan 2002 11:48:01 -0800 Received: (qmail 3910 invoked from network); 27 Jan 2002 18:49:13 -0000 Received: from coredump.sh0n.net (sh0n@24.100.234.67) by coredump.sh0n.net with SMTP; 27 Jan 2002 18:49:13 -0000 Subject: XFS and Kernel intregration and other things From: Shawn Starr To: Stephen Lord Cc: Linux XFS Mailing List In-Reply-To: <3C543711.5030704@sgi.com> References: <1012101803.1045.28.camel@steelnest> <1012102374.1045.35.camel@steelnest> <3 C536F44.1020301@sgi.com> <20020127152120.A1490@s2y4n2c.de> <20020127154745.A20990@wotan.suse.de> <1012143898.923.1.camel@steelnest> <3C54352B.60505@sgi.com> <1012151888.988.11.camel@steelnest> <3C543711.5030704@sgi.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/1.0.1.99 (Preview Release) Date: 27 Jan 2002 13:49:11 -0500 Message-Id: <1012157353.3745.5.camel@coredump> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 587 Lines: 17 Does anyone know when/how XFS will go into 2.4/2.5? A lot of kernel developers tell me that XFS needs to dump the pagebuf and other layers on top of the VM and VFS layers. I've gotten XFS to work with 2.4.18-pre7 w/ rml's preempt and lockbreak patch and the O(1) new scheduler + wli's patch cluster. XFS runs fine without errors. I have not seen corruption yet. I removed riel's rmap patch because it seems to break XFS somehow. rmap12a completely changes vmscan.c which blows up XFS ;/ I'm going to be using XFS's testing programs from the CVS tree and report the results. Shawn From owner-linux-xfs@oss.sgi.com Sun Jan 27 12:32:53 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0RKWrj15046 for linux-xfs-outgoing; Sun, 27 Jan 2002 12:32:53 -0800 Received: from finch-post-11.mail.demon.net (finch-post-11.mail.demon.net [194.217.242.39]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0RKWkP15006 for ; Sun, 27 Jan 2002 12:32:47 -0800 Received: from sweeney.demon.co.uk ([158.152.71.87] helo=pereskia.sweeney.demon.co.uk) by finch-post-11.mail.demon.net with esmtp (Exim 2.12 #1) id 16Uv2g-0002hG-0B for linux-xfs@oss.sgi.com; Sun, 27 Jan 2002 19:32:43 +0000 Received: from rebutia.sweeney.demon.co.uk (rebutia.sweeney.demon.co.uk [10.0.0.3]) by pereskia.sweeney.demon.co.uk (Postfix) with ESMTP id 1C7111F58 for ; Sun, 27 Jan 2002 19:38:17 +0000 (GMT) Received: by rebutia.sweeney.demon.co.uk (Postfix, from userid 1001) id C086A125E6; Sun, 27 Jan 2002 19:32:05 +0000 (GMT) Date: Sun, 27 Jan 2002 19:32:05 +0000 (GMT) From: Keith Matthews Subject: Re[2]: Linux 2.4.17-xfs vs previous XFS versions and certain non-us characters in filenames To: linux-xfs@oss.sgi.com In-Reply-To: <3C54463E.EE19BF02@idcomm.com> References: <1012101803.1045.28.camel@steelnest> <1012102374.1045.35.camel@steelnest> <3C536F44.1020301@sgi.com> <20020127152120.A1490@s2y4n2c.de> <20020127154745.A20990@wotan.suse.de> <1012143898.923.1.camel@steelnest> <1012146858.923.6.camel@steelnest> <20020127172958.A8796@wotan.suse.de> <3C5437F5.3553AAC5@idcomm.com> <3C543B45.3000308@sgi.com>, <3C54463E.EE19BF02@idcomm.com> X-Mailer: Mahogany, 0.60 'Redmond', compiled for Linux 2.2.13 i686 MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=ISO-8859-1 Content-Disposition: INLINE Message-Id: <20020127193205.C086A125E6@rebutia.sweeney.demon.co.uk> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from QUOTED-PRINTABLE to 8bit by oss.sgi.com id g0RKWlP15011 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 1822 Lines: 44 On Sun, 27 Jan 2002 11:26:06 -0700 D. Stimits > wrote: > Stephen Lord wrote: > > > > D. Stimits wrote: > > [SNIP] > To some degree it reminds me of PostegreSQL. Somewhere in the docs I > recall seeing it mention that it works with non-C locales (non-english > basically), but that it would then run slower due to no hashing. I guess > instead of trying to support other locales at full performance, > PostgreSQL (at least the version I read docs on a year or so ago) > completely eliminated hashing if different character sets were used. > With all the internationalizing going on, and the "world economy" being > so much more important in the tech industry, I have to wonder how long > it will be before hash routines for all these different character sets One of the problems of designing hashing routines for different character sets is that different languages use different character frequencies (even when they use the same character set). I discovered this some years ago when looking into the problems of producing Arabic language applications on systems whose hashing algorithms had been desigend for English. While the hashing worked it caused some nasty performance problems due to bunching, which did not occur with English language data (after all the algorithm had been designed to give an even distribution with English words). I would imagine that heavy use of German/French/Dutch names for files/directories would have similar effects, but possibly not so marked. Eastern European languages with the greater incidence of the letter 'z' would be another problem area. Hence I suspect that the universal optimal hashing algorithm may never be found. -- Keith Matthews Frequentous Consultants - Linux Services, Oracle development & database administration From owner-linux-xfs@oss.sgi.com Sun Jan 27 12:44:12 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0RKiCo16619 for linux-xfs-outgoing; Sun, 27 Jan 2002 12:44:12 -0800 Received: from pneumatic-tube.sgi.com (pneumatic-tube.sgi.com [204.94.214.22]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0RKi5P16563 for ; Sun, 27 Jan 2002 12:44:05 -0800 Received: from zeus-e8.americas.sgi.com (zeus-e8.americas.sgi.com [128.162.8.103]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id LAA03604 for ; Sun, 27 Jan 2002 11:45:01 -0800 (PST) mail_from (lord@sgi.com) Received: from tulip-e185.americas.sgi.com (tulip-e185.americas.sgi.com [128.162.185.208]) by zeus-e8.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id NAA175738; Sun, 27 Jan 2002 13:42:46 -0600 (CST) Received: from sgi.com (VLMsxs1YwzXG16vg65WDeyox0qyL/Dua@lord-h1.americas.sgi.com [206.11.101.42]) by tulip-e185.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.7) with ESMTP id NAA65247; Sun, 27 Jan 2002 13:42:45 -0600 (CST) Message-ID: <3C545827.8040900@sgi.com> Date: Sun, 27 Jan 2002 13:42:31 -0600 From: Stephen Lord User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.7) Gecko/20011226 X-Accept-Language: en-us MIME-Version: 1.0 To: Shawn Starr CC: linux-xfs@oss.sgi.com Subject: Re: XFS and Kernel intregration and other things References: <1012101803.1045.28.camel@steelnest> <1012102374.1045.35.camel@steelnest> <3 C536F44.1020301@sgi.com> <20020127152120.A1490@s2y4n2c.de> <20020127154745.A20990@wotan.suse.de> <1012143898.923.1.camel@steelnest> <3C54352B.60505@sgi.com> <1012151888.988.11.camel@steelnest> <3C543711.5030704@sgi.com> <1012157353.3745.5.camel@coredump> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 1579 Lines: 49 Shawn Starr wrote: >Does anyone know when/how XFS will go into 2.4/2.5? > When I have the time to attempt it - which is not now, nor probably for a while. Linux XFS represents about 20% of what I am working on right now. > > >A lot of kernel developers tell me that XFS needs to dump the pagebuf >and other layers on top of the VM and VFS layers. > Well, that might be their opinion, unfortunately, the linux buffer cache does not do anything near what xfs requires when it comes to data caching. And one of the reasons I am not submitting code to Linus right now is that I do not have the time to respond to all of the pushback there will be from people. XFS represents many man years of development, and you do not just turn it around and make it use new caches or vfs interfaces overnight. > > > >I've gotten XFS to work with 2.4.18-pre7 w/ rml's preempt and lockbreak >patch and the O(1) new scheduler + wli's patch cluster. XFS runs fine >without errors. I have not seen corruption yet. I removed riel's rmap >patch because it seems to break XFS somehow. rmap12a completely changes >vmscan.c which blows up XFS ;/ > There always needs to be a chunk of code in vmscan.c for dealing with delayed allocate data. Without this functioning correctly you will almost certainly trash filesystems. Look at the diff against a baseline tree, somewhere in Rick's code there will be something for dealing with dirty pages, this also needs to apply to Delalloc pages. > >I'm going to be using XFS's testing programs from the CVS tree and >report the results. > >Shawn > Steve From owner-linux-xfs@oss.sgi.com Sun Jan 27 13:42:59 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0RLgxe21331 for linux-xfs-outgoing; Sun, 27 Jan 2002 13:42:59 -0800 Received: from mailhost.idcomm.com (mailhost.idcomm.com [207.40.196.14]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0RLgoP21293 for ; Sun, 27 Jan 2002 13:42:50 -0800 Received: from idcomm.com (IDENT:csaxCSTDa70eW4QymBBq0dm3maH0GEfL@k56-pip62.idcomm.com [209.60.72.189]) by mailhost.idcomm.com (8.10.2/8.10.0) with ESMTP id g0RKn9x08704 for ; Sun, 27 Jan 2002 13:49:10 -0700 Message-ID: <3C54665C.EAAAD249@idcomm.com> Date: Sun, 27 Jan 2002 13:43:08 -0700 From: "D. Stimits" Reply-To: stimits@idcomm.com X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.6-pre1-xfs-4 i686) X-Accept-Language: en MIME-Version: 1.0 To: "XFS: linux-xfs@oss.sgi.com" Subject: Re: Linux 2.4.17-xfs vs previous XFS versions and certain non-us characters in filenames References: <1012101803.1045.28.camel@steelnest> <1012102374.1045.35.camel@steelnest> <3C536F44.1020301@sgi.com> <20020127152120.A1490@s2y4n2c.de> <20020127154745.A20990@wotan.suse.de> <1012143898.923.1.camel@steelnest> <1012146858.923.6.camel@steelnest> <20020127172958.A8796@wotan.suse.de> <3C5437F5.3553AAC5@idcomm.com> <3C543B45.3000308@sgi.com>, <3C54463E.EE19BF02@idcomm.com> <20020127193205.C086A125E6@rebutia.sweeney.demon.co.uk> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 3750 Lines: 75 Keith Matthews wrote: > > On Sun, 27 Jan 2002 11:26:06 -0700 D. Stimits > wrote: > > > Stephen Lord wrote: > > > > > > D. Stimits wrote: > > > > [SNIP] > > > To some degree it reminds me of PostegreSQL. Somewhere in the docs I > > recall seeing it mention that it works with non-C locales (non-english > > basically), but that it would then run slower due to no hashing. I guess > > instead of trying to support other locales at full performance, > > PostgreSQL (at least the version I read docs on a year or so ago) > > completely eliminated hashing if different character sets were used. > > > With all the internationalizing going on, and the "world economy" being > > so much more important in the tech industry, I have to wonder how long > > it will be before hash routines for all these different character sets > > One of the problems of designing hashing routines for different > character sets is that different languages use different character > frequencies (even when they use the same character set). > > I discovered this some years ago when looking into the problems of > producing Arabic language applications on systems whose hashing > algorithms had been desigend for English. While the hashing worked it > caused some nasty performance problems due to bunching, which did not > occur with English language data (after all the algorithm had been > designed to give an even distribution with English words). > > I would imagine that heavy use of German/French/Dutch names for > files/directories would have similar effects, but possibly not so > marked. Eastern European languages with the greater incidence of the > letter 'z' would be another problem area. > > Hence I suspect that the universal optimal hashing algorithm may never > be found. Without a doubt, no hash routine will fit all languages. Even within the same language there are specific areas that might end up being a problem. If I were to use a basic hashing routine for a fiction novel, it would probably work well; the same hash for a manual on Qt widget set or Xlib would have problems, since so many things start with Q or X in those cases, but not in the general language. I am thinking in terms of two areas, one would be to take existing language hashing that is commonly available for 7 bit ASCII, and expand it to versions that are similar for 8 bit Latin-1, and for 16 bit wide characters. That could be "breadth" of support across a single language, english. The other side would be to add hash routines that are effective for various non-english languages in wide character format; this would be adding "depth" of support for a single encoding to work for more languages (my description could easily have the naming turned around). If one were to look at commonly available hash schemes for string data, almost all of them would be intended for use with the english language; if more were available as a common and stadard library, it would be easier to design software various languages and encoding schemes. I am still curious how much of a penalty something like a Japanese encoding would be for XFS...obviously, the same hashing can't be used, the characters are not even 7 or 8 bit (until you consider that the Japanese usually embed a mix of character sets, e.g., the ability to use ordinary ASCII/english characters embedded directly into kanji pages). I wonder if anyone with a Japanese or wide character format has even used XFS? I'm very curious about the difficulties of using these more complicated (especially mixed) character sets. D. Stimits, stimits@idcomm.com > > -- > Keith Matthews > Frequentous Consultants - Linux Services, > Oracle development & database administration From owner-linux-xfs@oss.sgi.com Sun Jan 27 14:44:15 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0RMiFk28642 for linux-xfs-outgoing; Sun, 27 Jan 2002 14:44:15 -0800 Received: from www.fortuitous.com (cs6625128-203.austin.rr.com [66.25.128.203]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0RMiBP28611 for ; Sun, 27 Jan 2002 14:44:11 -0800 Received: by www.fortuitous.com (Postfix, from userid 500) id 90C022DC; Sun, 27 Jan 2002 11:35:53 -0600 (CST) Date: Sun, 27 Jan 2002 11:35:53 -0600 From: pac@fortuitous.com To: linux-xfs@oss.sgi.com Subject: Re: double mounting and other strangeness. Message-ID: <20020127113553.A13031@bistro.marx> Reply-To: pac@fortuitous.com References: <20020127001947.A6688@bistro.marx> <24489.1012116014@ocs3.intra.ocs.com.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <24489.1012116014@ocs3.intra.ocs.com.au> User-Agent: Mutt/1.3.23i Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 813 Lines: 20 On Sun, Jan 27, 2002 at 06:20:14PM +1100, Keith Owens wrote: > pac@fortuitous.com wrote: > > I get some strange ability to mount 2 devices on one partition: > > That is normal with any recent 2.4 kernel, it applies to all > filesystems, not just XFS. You can even mount different file system Doesn't this seem BAD for an OS to allow? BTW. I did update the tools as suggested, and all I was able to successfully get all my partitions mounted. Thanks again to all. I owe you all a beer. -Phil Carinhas -- .--------------------------------------------------------. | Dr. Philip A. Carinhas | pac@fortuitous.com | | Fortuitous Technologies Inc. | http://fortuitous.com | | Linux Consulting & Training | Tel : 1-512-467-2154 | `--------------------------------------------------------' From owner-linux-xfs@oss.sgi.com Sun Jan 27 15:31:55 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0RNVtE01915 for linux-xfs-outgoing; Sun, 27 Jan 2002 15:31:55 -0800 Received: from borg-cube.no-ip.com (IDENT:root@adsl-46021.turboline.skynet.be [217.136.51.197]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0RNVlP01869 for ; Sun, 27 Jan 2002 15:31:47 -0800 Received: from skynet.be (IDENT:kris@borg-cube.no-ip.com [127.0.0.1]) by borg-cube.no-ip.com (8.11.2/8.11.2) with ESMTP id g0RMK6J14080 for ; Sun, 27 Jan 2002 23:20:10 +0100 Message-ID: <3C547D16.63C7E0A0@skynet.be> Date: Sun, 27 Jan 2002 23:20:06 +0100 From: kris buggenhout X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.15-pre7-xfs i686) X-Accept-Language: en MIME-Version: 1.0 To: "linux-xfs@oss.sgi.com" Subject: Success on Sparc32 build Content-Disposition: inline Content-Type: text/plain Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 912 Lines: 32 Hi guy's just wanted to let ya all know... done a succesfull build on a sparc system (32bit) and mounted a disk from my intel box then hooked it up shared between my Indigo2 and the SS20, (4 cpu SMP ) They took each other disks without any problem... ( hmm ... without major problems , i couldnt deal with .. ;-) .... ) :) this is fun ! -- --------------------------------------------------------------- SUN MICROSYSTEMS BELGIUM "Take it to the nth" --------------------------------------------------------------- Kris Buggenhout Project engineer Profesional services Sun Microsystems Belgium Phone (32)2 70 480 12 Lozenberg 15 Fax (32)2 70 488 80 B-1932 Zaventem Mobile (32)474 09 18 43 http://www.sun.be --------------------------------------------------------------- [[HTML alternate version deleted]] From owner-linux-xfs@oss.sgi.com Sun Jan 27 15:38:42 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0RNcgv02761 for linux-xfs-outgoing; Sun, 27 Jan 2002 15:38:42 -0800 Received: from borg-cube.no-ip.com (IDENT:root@adsl-46021.turboline.skynet.be [217.136.51.197]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0RNcVP02714 for ; Sun, 27 Jan 2002 15:38:31 -0800 Received: from skynet.be (IDENT:kris@borg-cube.no-ip.com [127.0.0.1]) by borg-cube.no-ip.com (8.11.2/8.11.2) with ESMTP id g0RMR0J14114 for ; Sun, 27 Jan 2002 23:27:00 +0100 Message-ID: <3C547EB4.6402144F@skynet.be> Date: Sun, 27 Jan 2002 23:27:00 +0100 From: kris buggenhout X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.15-pre7-xfs i686) X-Accept-Language: en MIME-Version: 1.0 To: "linux-xfs@oss.sgi.com" Subject: more details on success on Sparc32 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 2756 Lines: 84 Guy's some details : started out with vanilla 2.4.17 ( compiled fine on the SS20 ) applied patch XFS-20011214.patch, specific for the 2.4.17 kernel (from gentoo dld-ed) part of dmesg : sparcy:~ # dmesg PROMLIB: Sun Boot Prom Version 3 Revision 2 Linux version 2.4.17 (root@sparcy) (gcc version 2.95.3 20010315 (SuSE)) #3 SMP Sun Jan 27 21:39:56 CET 2002 ARCH: SUN4M TYPE: Sun4m SparcStation10/20 Ethernet address: 8:0:20:71:1d:d8 Boot time fixup v1.6. 4/Mar/98 Jakub Jelinek (jj@ultra.linux.cz). Patching kernel for srmmu[TI Viking/MXCC]/iommu 40779MB HIGHMEM available. On node 0 totalpages: 89346 zone(0): 49152 pages. zone(1): 0 pages. zone(2): 69452 pages. Found CPU 0 Found CPU 1 Found CPU 2 Found CPU 3 Found 4 CPU prom device tree node(s). Power off control detected. Kernel command line: root=/dev/sda4 ro Calibrating delay loop... 49.76 BogoMIPS Memory: 347432k available (1516k kernel code, 332k data, 120k init, 163116k highmem) [f0000000,1cf4c000] Dentry-cache hash table entries: 32768 (order: 6, 262144 bytes) Inode-cache hash table entries: 16384 (order: 5, 131072 bytes) Mount-cache hash table entries: 4096 (order: 3, 32768 bytes) Buffer-cache hash table entries: 8192 (order: 3, 32768 bytes) Page-cache hash table entries: 65536 (order: 6, 262144 bytes) POSIX conformance testing by UNIFIX Entering SMP Mode... Starting CPU 1 at f01dac50 Calibrating delay loop... 49.97 BogoMIPS Starting CPU 2 at f01dac5c Calibrating delay loop... 49.97 BogoMIPS Starting CPU 3 at f01dac68 Calibrating delay loop... 49.97 BogoMIPS Total of 4 Processors activated (199.68 BogoMIPS). Waiting on wait_init_idle (map = 0xe) All processors have done init_idle IOMMU: impl 1 vers 3 page table at f0dc0000 of size 262144 bytes lol that to get 200 BogoMips ... good to know that my meager Athlon 500 has almost 1k Bogomips Jan 27 10:14:16 borg-cube kernel: Initializing CPU#0 Jan 27 10:14:16 borg-cube kernel: Detected 499.050 MHz processor. Jan 27 10:14:16 borg-cube kernel: Console: colour VGA+ 80x25 Jan 27 10:14:16 borg-cube kernel: Calibrating delay loop... 996.14 BogoMIPS And my laptop (Piii 850Mhz) 1697.38 BogoMips ---- --------------------------------------------------------------- SUN MICROSYSTEMS BELGIUM "Take it to the nth" --------------------------------------------------------------- Kris Buggenhout Project engineer Profesional services Sun Microsystems Belgium Phone (32)2 70 480 12 Lozenberg 15 Fax (32)2 70 488 80 B-1932 Zaventem Mobile (32)474 09 18 43 http://www.sun.be --------------------------------------------------------------- From owner-linux-xfs@oss.sgi.com Sun Jan 27 16:19:14 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0S0JEP07444 for linux-xfs-outgoing; Sun, 27 Jan 2002 16:19:14 -0800 Received: from mail.ocs.com.au (mail.ocs.com.au [203.34.97.2]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0S0J9P07415 for ; Sun, 27 Jan 2002 16:19:09 -0800 Received: (qmail 1823 invoked from network); 27 Jan 2002 23:19:05 -0000 Received: from ocs3.intra.ocs.com.au (192.168.255.3) by mail.ocs.com.au with SMTP; 27 Jan 2002 23:19:05 -0000 Received: by ocs3.intra.ocs.com.au (Postfix, from userid 16331) id 686743000B8; Mon, 28 Jan 2002 10:19:03 +1100 (EST) Received: from ocs3.intra.ocs.com.au (localhost [127.0.0.1]) by ocs3.intra.ocs.com.au (Postfix) with ESMTP id 3CDDF168; Mon, 28 Jan 2002 10:19:03 +1100 (EST) X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 From: Keith Owens To: pac@fortuitous.com Cc: linux-xfs@oss.sgi.com Subject: Re: double mounting and other strangeness. In-reply-to: Your message of "Sun, 27 Jan 2002 11:35:53 MDT." <20020127113553.A13031@bistro.marx> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 28 Jan 2002 10:18:57 +1100 Message-ID: <27476.1012173537@ocs3.intra.ocs.com.au> Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 558 Lines: 15 On Sun, 27 Jan 2002 11:35:53 -0600, pac@fortuitous.com wrote: >On Sun, Jan 27, 2002 at 06:20:14PM +1100, Keith Owens wrote: >> pac@fortuitous.com wrote: >> > I get some strange ability to mount 2 devices on one partition: >> >> That is normal with any recent 2.4 kernel, it applies to all >> filesystems, not just XFS. You can even mount different file system > > Doesn't this seem BAD for an OS to allow? The Linux VFS gurus have said they want this. If you disagree, please take it up on the vfs or kernel mailing lists, it is out of our control. From owner-linux-xfs@oss.sgi.com Sun Jan 27 16:36:49 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0S0anZ09495 for linux-xfs-outgoing; Sun, 27 Jan 2002 16:36:49 -0800 Received: from UberGeek.coremetrics.com ([209.184.141.163]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0S0agP09463 for ; Sun, 27 Jan 2002 16:36:42 -0800 Received: (from austin@localhost) by UberGeek.coremetrics.com (8.11.6/8.11.6) id g0RNZwB23332; Sun, 27 Jan 2002 17:35:58 -0600 X-Authentication-Warning: UberGeek.coremetrics.com: austin set sender to austin@coremetrics.com using -f Subject: Re: double mounting and other strangeness. From: Austin Gonyou To: Keith Owens Cc: pac@fortuitous.com, linux-xfs@oss.sgi.com In-Reply-To: <27476.1012173537@ocs3.intra.ocs.com.au> References: <27476.1012173537@ocs3.intra.ocs.com.au> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-g+dvd6cZroOoQc7OHOc1" X-Mailer: Evolution/1.0.1 Date: 27 Jan 2002 17:35:58 -0600 Message-Id: <1012174558.23239.1.camel@UberGeek> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 1565 Lines: 50 --=-g+dvd6cZroOoQc7OHOc1 Content-Type: text/plain Content-Transfer-Encoding: quoted-printable This would be correct. If you go look at the LKML, there is a faq about the list itself, 2.4 kernel series, and language.=20 The feature you are referring to is the FIRST part of the FAQ on the 2.4 kernel series. :)=20 On Sun, 2002-01-27 at 17:18, Keith Owens wrote: > On Sun, 27 Jan 2002 11:35:53 -0600,=20 > pac@fortuitous.com wrote: > >On Sun, Jan 27, 2002 at 06:20:14PM +1100, Keith Owens wrote: > >> pac@fortuitous.com wrote: > >> > I get some strange ability to mount 2 devices on one partition: > >>=20 > >> That is normal with any recent 2.4 kernel, it applies to all > >> filesystems, not just XFS. You can even mount different file system > > > > Doesn't this seem BAD for an OS to allow?=20 >=20 > The Linux VFS gurus have said they want this. If you disagree, please > take it up on the vfs or kernel mailing lists, it is out of our > control. --=20 Austin Gonyou Systems Architect, CCNA Coremetrics, Inc. Phone: 512-698-7250 email: austin@coremetrics.com "It is the part of a good shepherd to shear his flock, not to skin it." Latin Proverb --=-g+dvd6cZroOoQc7OHOc1 Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQA8VI7d94g6ZVmFMoIRApl9AJ41gQ1GFaVFWg+DpOLKK83SXU74mgCfcn7W K3qnWzY/LvJw+IsFvSaEsKc= =f++D -----END PGP SIGNATURE----- --=-g+dvd6cZroOoQc7OHOc1-- From owner-linux-xfs@oss.sgi.com Sun Jan 27 17:14:15 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0S1EF213739 for linux-xfs-outgoing; Sun, 27 Jan 2002 17:14:15 -0800 Received: from www.fortuitous.com (cs6625128-203.austin.rr.com [66.25.128.203]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0S1EBP13707 for ; Sun, 27 Jan 2002 17:14:12 -0800 Received: by www.fortuitous.com (Postfix, from userid 500) id CC61D2DC; Sun, 27 Jan 2002 17:38:52 -0600 (CST) Date: Sun, 27 Jan 2002 17:38:52 -0600 From: pac@fortuitous.com To: linux-xfs@oss.sgi.com Subject: Re: double mounting and other strangeness. Message-ID: <20020127173852.A14538@bistro.marx> Reply-To: pac@fortuitous.com References: <20020127113553.A13031@bistro.marx> <27476.1012173537@ocs3.intra.ocs.com.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <27476.1012173537@ocs3.intra.ocs.com.au> User-Agent: Mutt/1.3.23i Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 831 Lines: 19 On Mon, Jan 28, 2002 at 10:18:57AM +1100, Keith Owens wrote: > >> That is normal with any recent 2.4 kernel, it applies to all > >> filesystems, not just XFS. You can even mount different file system > > Doesn't this seem BAD for an OS to allow? > The Linux VFS gurus have said they want this. If you disagree, please > take it up on the vfs or kernel mailing lists, it is out of our > control. Is there any legitimate reason you would want to do this? I dont want to scream at them if there is a good reason for it. What is the opinion of the FS developers here? -Phil Carinhas -- .--------------------------------------------------------. | Dr. Philip A. Carinhas | pac@fortuitous.com | | Fortuitous Technologies Inc. | http://fortuitous.com | `--------------------------------------------------------' From owner-linux-xfs@oss.sgi.com Sun Jan 27 17:44:05 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0S1i5h17733 for linux-xfs-outgoing; Sun, 27 Jan 2002 17:44:05 -0800 Received: from UberGeek.coremetrics.com ([209.184.141.163]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0S1hvP17691 for ; Sun, 27 Jan 2002 17:43:57 -0800 Received: (from austin@localhost) by UberGeek.coremetrics.com (8.11.6/8.11.6) id g0S0gnr24616; Sun, 27 Jan 2002 18:42:49 -0600 X-Authentication-Warning: UberGeek.coremetrics.com: austin set sender to austin@coremetrics.com using -f Subject: Re: double mounting and other strangeness. From: Austin Gonyou To: pac@fortuitous.com Cc: linux-xfs@oss.sgi.com In-Reply-To: <20020127173852.A14538@bistro.marx> References: <20020127173852.A14538@bistro.marx> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-nazFgVKA1XST8CGGzb8d" X-Mailer: Evolution/1.0.1 Date: 27 Jan 2002 18:42:49 -0600 Message-Id: <1012178569.23483.0.camel@UberGeek> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 1720 Lines: 52 --=-nazFgVKA1XST8CGGzb8d Content-Type: text/plain Content-Transfer-Encoding: quoted-printable I believe the main reason is for snapshotting purposes, backup, RO file usage, etc.=20 On Sun, 2002-01-27 at 17:38, pac@fortuitous.com wrote: > On Mon, Jan 28, 2002 at 10:18:57AM +1100, Keith Owens wrote: > > >> That is normal with any recent 2.4 kernel, it applies to all > > >> filesystems, not just XFS. You can even mount different file > system > > > Doesn't this seem BAD for an OS to allow?=20 > > The Linux VFS gurus have said they want this. If you disagree, please > > take it up on the vfs or kernel mailing lists, it is out of our > > control. >=20 > Is there any legitimate reason you would want to do this? I dont > want to scream at them if there is a good reason for it. What is the > opinion of the FS developers here? >=20 > -Phil Carinhas > -- > .--------------------------------------------------------. > | Dr. Philip A. Carinhas | pac@fortuitous.com | > | Fortuitous Technologies Inc. | http://fortuitous.com | > `--------------------------------------------------------' --=20 Austin Gonyou Systems Architect, CCNA Coremetrics, Inc. Phone: 512-698-7250 email: austin@coremetrics.com "It is the part of a good shepherd to shear his flock, not to skin it." Latin Proverb --=-nazFgVKA1XST8CGGzb8d Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQA8VJ6I94g6ZVmFMoIRApdWAKCEg74MP5oGtFjqhimM971f6WL9rwCfadgh Ua3VVU3S5fF5glqTH52OwzM= =+OSy -----END PGP SIGNATURE----- --=-nazFgVKA1XST8CGGzb8d-- From owner-linux-xfs@oss.sgi.com Sun Jan 27 17:57:08 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0S1v8J19370 for linux-xfs-outgoing; Sun, 27 Jan 2002 17:57:08 -0800 Received: from Cantor.suse.de (ns.suse.de [213.95.15.193]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0S1v4P19345 for ; Sun, 27 Jan 2002 17:57:04 -0800 Received: from Hermes.suse.de (Hermes.suse.de [213.95.15.136]) by Cantor.suse.de (Postfix) with ESMTP id F14231E828; Mon, 28 Jan 2002 01:56:56 +0100 (MET) Date: Mon, 28 Jan 2002 01:56:56 +0100 From: Andi Kleen To: pac@fortuitous.com Cc: linux-xfs@oss.sgi.com Subject: Re: double mounting and other strangeness. Message-ID: <20020128015656.A4541@wotan.suse.de> References: <20020127113553.A13031@bistro.marx> <27476.1012173537@ocs3.intra.ocs.com.au> <20020127173852.A14538@bistro.marx> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20020127173852.A14538@bistro.marx> User-Agent: Mutt/1.3.22.1i Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 1041 Lines: 22 On Sun, Jan 27, 2002 at 05:38:52PM -0600, pac@fortuitous.com wrote: > On Mon, Jan 28, 2002 at 10:18:57AM +1100, Keith Owens wrote: > > >> That is normal with any recent 2.4 kernel, it applies to all > > >> filesystems, not just XFS. You can even mount different file system > > > Doesn't this seem BAD for an OS to allow? > > The Linux VFS gurus have said they want this. If you disagree, please > > take it up on the vfs or kernel mailing lists, it is out of our > > control. > > Is there any legitimate reason you would want to do this? I dont > want to scream at them if there is a good reason for it. What is the > opinion of the FS developers here? It's for example useful for chroot. You can mount a single file system in multiple chroots. There is also the related feature of mount --bind which allows to do the same thing for directories and files. Again it is useful for chroots. 2.5 also allows you to change that "namespace" per process, extending the usage outside chroots (that is a feature inspired by plan9) -Andi From owner-linux-xfs@oss.sgi.com Sun Jan 27 18:01:38 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0S21ci20158 for linux-xfs-outgoing; Sun, 27 Jan 2002 18:01:38 -0800 Received: from UberGeek.coremetrics.com ([209.184.141.163]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0S21UP20124 for ; Sun, 27 Jan 2002 18:01:30 -0800 Received: (from austin@localhost) by UberGeek.coremetrics.com (8.11.6/8.11.6) id g0S10eK25071; Sun, 27 Jan 2002 19:00:40 -0600 X-Authentication-Warning: UberGeek.coremetrics.com: austin set sender to austin@coremetrics.com using -f Subject: Re: double mounting and other strangeness. From: Austin Gonyou To: Andi Kleen Cc: pac@fortuitous.com, linux-xfs@oss.sgi.com In-Reply-To: <20020128015656.A4541@wotan.suse.de> References: <20020128015656.A4541@wotan.suse.de> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-Svsur3mPzKTIDIXUfE4U" X-Mailer: Evolution/1.0.1 Date: 27 Jan 2002 19:00:40 -0600 Message-Id: <1012179640.23484.12.camel@UberGeek> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 1971 Lines: 57 --=-Svsur3mPzKTIDIXUfE4U Content-Type: text/plain Content-Transfer-Encoding: quoted-printable I'd assume then that the multiple chroot thing, aside from helpful projects, would be mostly useful for embedded systems? On Sun, 2002-01-27 at 18:56, Andi Kleen wrote: > On Sun, Jan 27, 2002 at 05:38:52PM -0600, pac@fortuitous.com wrote: > > On Mon, Jan 28, 2002 at 10:18:57AM +1100, Keith Owens wrote: > > > >> That is normal with any recent 2.4 kernel, it applies to all > > > >> filesystems, not just XFS. You can even mount different file > system > > > > Doesn't this seem BAD for an OS to allow?=20 > > > The Linux VFS gurus have said they want this. If you disagree, > please > > > take it up on the vfs or kernel mailing lists, it is out of our > > > control. > >=20 > > Is there any legitimate reason you would want to do this? I dont > > want to scream at them if there is a good reason for it. What is the > > opinion of the FS developers here? >=20 > It's for example useful for chroot. You can mount a single file system > in multiple chroots. There is also the related feature of mount --bind > which allows to do the same thing for directories and files. Again > it is useful for chroots. > 2.5 also allows you to change that "namespace" per process, extending > the > usage outside chroots (that is a feature inspired by plan9)=20 >=20 > -Andi --=20 Austin Gonyou Systems Architect, CCNA Coremetrics, Inc. Phone: 512-698-7250 email: austin@coremetrics.com "It is the part of a good shepherd to shear his flock, not to skin it." Latin Proverb --=-Svsur3mPzKTIDIXUfE4U Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQA8VKK494g6ZVmFMoIRAllmAJ4lBGwoZhn8Df8+RbpTuIZQ/gODcwCgg+0y HXg33ayhpT3a+h/0nOBw+eQ= =JSAh -----END PGP SIGNATURE----- --=-Svsur3mPzKTIDIXUfE4U-- From owner-linux-xfs@oss.sgi.com Sun Jan 27 18:02:32 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0S22Wo20332 for linux-xfs-outgoing; Sun, 27 Jan 2002 18:02:32 -0800 Received: from Cantor.suse.de (ns.suse.de [213.95.15.193]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0S22UP20304 for ; Sun, 27 Jan 2002 18:02:30 -0800 Received: from Hermes.suse.de (Hermes.suse.de [213.95.15.136]) by Cantor.suse.de (Postfix) with ESMTP id A926C1E82D; Mon, 28 Jan 2002 02:02:22 +0100 (MET) Date: Mon, 28 Jan 2002 02:02:22 +0100 From: Andi Kleen To: Austin Gonyou Cc: Andi Kleen , pac@fortuitous.com, linux-xfs@oss.sgi.com Subject: Re: double mounting and other strangeness. Message-ID: <20020128020222.A6332@wotan.suse.de> References: <20020128015656.A4541@wotan.suse.de> <1012179640.23484.12.camel@UberGeek> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1012179640.23484.12.camel@UberGeek> User-Agent: Mutt/1.3.22.1i Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 337 Lines: 9 On Sun, Jan 27, 2002 at 07:00:40PM -0600, Austin Gonyou wrote: > I'd assume then that the multiple chroot thing, aside from helpful > projects, would be mostly useful for embedded systems? I don't think it makes much sense in embedded systems. The main application is likely security partitioned internet servers and firewalls. -Andi From owner-linux-xfs@oss.sgi.com Sun Jan 27 19:04:47 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0S34l126756 for linux-xfs-outgoing; Sun, 27 Jan 2002 19:04:47 -0800 Received: from iris.slb.nwc.acsalaska.net (iris.slb.nwc.acsalaska.net [209.112.155.43]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0S34eP26714 for ; Sun, 27 Jan 2002 19:04:40 -0800 Received: from erbenson.alaska.net (133-pm15.nwc.alaska.net [209.112.141.133]) by iris.slb.nwc.acsalaska.net (8.11.6/8.11.6) with ESMTP id g0S24aa67885 for ; Sun, 27 Jan 2002 17:04:36 -0900 (AKST) (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 723663938 for ; Sun, 27 Jan 2002 17:04:35 -0900 (AKST) Received: by plato.local.lan (Postfix, from userid 1000) id 21A651023C; Sun, 27 Jan 2002 17:04:35 -0900 (AKST) Date: Sun, 27 Jan 2002 17:04:35 -0900 From: Ethan Benson To: linux-xfs@oss.sgi.com Subject: extended attributes support on powerpc Message-ID: <20020127170434.K14742@plato.local.lan> Mail-Followup-To: linux-xfs@oss.sgi.com Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="8kI7hWEHMS8Z+7/0" Content-Disposition: inline User-Agent: Mutt/1.2.5i X-OS: Debian GNU Mail-Copies-To: nobody X-No-CC: I subscribe to this list; do not CC me on replies. Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 1127 Lines: 38 --8kI7hWEHMS8Z+7/0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi, extended attributes (and thus acls) do not appear to be supported on powerpc, as far as i can tell this is because the acl-xattr patches do not add the syscall and unistd.h defines for the powerpc arch (only i386 and ia64). is there any more to it then that? and if not how difficult is it to do so? (it looks trivial, but a kernel hacker i am not...)=20 btw, somewhat related but i noticed that the -misc patch adds the syscall defines to ia64's unistd.h, but the -acl-extattr patch adds it to i386's any reason for this inconsistency? or a bug in the patch generation scripts? --=20 Ethan Benson http://www.alaska.net/~erbenson/ --8kI7hWEHMS8Z+7/0 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 iEYEARECAAYFAjxUsbIACgkQJKx7GixEevw9PACfbJG81MZ7ma7txKVzfTaT50m/ RWIAnjggabSU0BbK96UPt2TVSRqMZpgS =Jsvs -----END PGP SIGNATURE----- --8kI7hWEHMS8Z+7/0-- From owner-linux-xfs@oss.sgi.com Sun Jan 27 19:24:49 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0S3OnA28841 for linux-xfs-outgoing; Sun, 27 Jan 2002 19:24:49 -0800 Received: from mail.ocs.com.au (mail.ocs.com.au [203.34.97.2]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0S3OgP28800 for ; Sun, 27 Jan 2002 19:24:42 -0800 Received: (qmail 2909 invoked from network); 28 Jan 2002 02:24:35 -0000 Received: from ocs3.intra.ocs.com.au (192.168.255.3) by mail.ocs.com.au with SMTP; 28 Jan 2002 02:24:35 -0000 Received: by ocs3.intra.ocs.com.au (Postfix, from userid 16331) id E3E993000B8; Mon, 28 Jan 2002 13:24:32 +1100 (EST) Received: from ocs3.intra.ocs.com.au (localhost [127.0.0.1]) by ocs3.intra.ocs.com.au (Postfix) with ESMTP id 545E6168; Mon, 28 Jan 2002 13:24:32 +1100 (EST) X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 From: Keith Owens To: Ethan Benson Cc: linux-xfs@oss.sgi.com Subject: Re: extended attributes support on powerpc In-reply-to: Your message of "Sun, 27 Jan 2002 17:04:35 -0900." <20020127170434.K14742@plato.local.lan> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 28 Jan 2002 13:24:26 +1100 Message-ID: <2576.1012184666@ocs3.intra.ocs.com.au> Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 1370 Lines: 37 On Sun, 27 Jan 2002 17:04:35 -0900, Ethan Benson wrote: >extended attributes (and thus acls) do not appear to be supported on >powerpc, as far as i can tell this is because the acl-xattr patches do >not add the syscall and unistd.h defines for the powerpc arch (only >i386 and ia64). is there any more to it then that? and if not how >difficult is it to do so? (it looks trivial, but a kernel hacker i am >not...) It should be that simple. Find 3 unused syscall numbers in sys_call_table in arch/ppc/kernel/misc.S, in 2.4.17 the next 3 are 208-210. Add these lines after sys_gettid, adjusting to fit current ppc syscall usage. #ifdef CONFIG_HAVE_ATTRCTL .long SYMBOL_NAME(sys_attrctl) .long SYMBOL_NAME(sys_acl_get) .long SYMBOL_NAME(sys_acl_set) /* 210 */ #else .long SYMBOL_NAME(sys_ni_syscall) .long SYMBOL_NAME(sys_ni_syscall) .long SYMBOL_NAME(sys_ni_syscall) /* 210 */ #endif /* CONFIG_HAVE_ATTRCTL */ Add these to include/asm-ppc/unistd.h, adjusting as required. #define __NR__attrctl 208 #define __NR__acl_get 209 #define __NR__acl_set 210 >btw, somewhat related but i noticed that the -misc patch adds the >syscall defines to ia64's unistd.h, but the -acl-extattr patch adds it >to i386's any reason for this inconsistency? or a bug in the patch >generation scripts? Human error, I will fix it in the next patch set. From owner-linux-xfs@oss.sgi.com Sun Jan 27 19:28:50 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0S3SoB29408 for linux-xfs-outgoing; Sun, 27 Jan 2002 19:28:50 -0800 Received: from malik.slb.nwc.acsalaska.net (malik.slb.nwc.acsalaska.net [209.112.155.41]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0S3SfP29371 for ; Sun, 27 Jan 2002 19:28:41 -0800 Received: from erbenson.alaska.net (133-pm15.nwc.alaska.net [209.112.141.133]) by malik.slb.nwc.acsalaska.net (8.11.6/8.11.6) with ESMTP id g0S2SbO43421 for ; Sun, 27 Jan 2002 17:28:37 -0900 (AKST) (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 0F16A3938 for ; Sun, 27 Jan 2002 17:28:36 -0900 (AKST) Received: by plato.local.lan (Postfix, from userid 1000) id 18F4A1023C; Sun, 27 Jan 2002 17:28:36 -0900 (AKST) Date: Sun, 27 Jan 2002 17:28:36 -0900 From: Ethan Benson To: linux-xfs@oss.sgi.com Subject: Re: extended attributes support on powerpc Message-ID: <20020127172836.A17042@plato.local.lan> Mail-Followup-To: linux-xfs@oss.sgi.com References: <20020127170434.K14742@plato.local.lan> <2576.1012184666@ocs3.intra.ocs.com.au> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="KsGdsel6WgEHnImy" Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <2576.1012184666@ocs3.intra.ocs.com.au>; from kaos@sgi.com on Mon, Jan 28, 2002 at 01:24:26PM +1100 X-OS: Debian GNU Mail-Copies-To: nobody X-No-CC: I subscribe to this list; do not CC me on replies. Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 2284 Lines: 68 --KsGdsel6WgEHnImy Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Jan 28, 2002 at 01:24:26PM +1100, Keith Owens wrote: > On Sun, 27 Jan 2002 17:04:35 -0900,=20 > Ethan Benson wrote: > >extended attributes (and thus acls) do not appear to be supported on > >powerpc, as far as i can tell this is because the acl-xattr patches do > >not add the syscall and unistd.h defines for the powerpc arch (only > >i386 and ia64). is there any more to it then that? and if not how > >difficult is it to do so? (it looks trivial, but a kernel hacker i am > >not...) >=20 > It should be that simple. Find 3 unused syscall numbers in > sys_call_table in arch/ppc/kernel/misc.S, in 2.4.17 the next 3 are > 208-210. Add these lines after sys_gettid, adjusting to fit current > ppc syscall usage. in the i386 version you seem to be adding about 25 dummy syscalls, am i correct in assuming this is just `padding' to avoid conflicts if Linus allocates some new syscalls? is the same necessary/wise to do on powerpc as well? > #ifdef CONFIG_HAVE_ATTRCTL > .long SYMBOL_NAME(sys_attrctl) > .long SYMBOL_NAME(sys_acl_get) > .long SYMBOL_NAME(sys_acl_set) /* 210 */ > #else > .long SYMBOL_NAME(sys_ni_syscall) > .long SYMBOL_NAME(sys_ni_syscall) > .long SYMBOL_NAME(sys_ni_syscall) /* 210 */ > #endif /* CONFIG_HAVE_ATTRCTL */ >=20 > Add these to include/asm-ppc/unistd.h, adjusting as required. >=20 > #define __NR__attrctl 208 > #define __NR__acl_get 209 > #define __NR__acl_set 210 >=20 > >btw, somewhat related but i noticed that the -misc patch adds the > >syscall defines to ia64's unistd.h, but the -acl-extattr patch adds it > >to i386's any reason for this inconsistency? or a bug in the patch > >generation scripts? >=20 > Human error, I will fix it in the next patch set. >=20 --=20 Ethan Benson http://www.alaska.net/~erbenson/ --KsGdsel6WgEHnImy 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 iEYEARECAAYFAjxUt1MACgkQJKx7GixEevw4BwCeNrD+TZo3rykdnUvo025Ipo4m wD8An3wf1gznStq1RZqjfSVjAuphi1br =2Txe -----END PGP SIGNATURE----- --KsGdsel6WgEHnImy-- From owner-linux-xfs@oss.sgi.com Sun Jan 27 19:36:00 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0S3a0F30213 for linux-xfs-outgoing; Sun, 27 Jan 2002 19:36:00 -0800 Received: from mail.ocs.com.au (mail.ocs.com.au [203.34.97.2]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0S3ZuP30185 for ; Sun, 27 Jan 2002 19:35:57 -0800 Received: (qmail 2968 invoked from network); 28 Jan 2002 02:35:52 -0000 Received: from ocs3.intra.ocs.com.au (192.168.255.3) by mail.ocs.com.au with SMTP; 28 Jan 2002 02:35:52 -0000 Received: by ocs3.intra.ocs.com.au (Postfix, from userid 16331) id 83DEA3000B8; Mon, 28 Jan 2002 13:35:51 +1100 (EST) Received: from ocs3.intra.ocs.com.au (localhost [127.0.0.1]) by ocs3.intra.ocs.com.au (Postfix) with ESMTP id 75365168; Mon, 28 Jan 2002 13:35:51 +1100 (EST) X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 From: Keith Owens To: Ethan Benson Cc: linux-xfs@oss.sgi.com Subject: Re: extended attributes support on powerpc In-reply-to: Your message of "Sun, 27 Jan 2002 17:28:36 -0900." <20020127172836.A17042@plato.local.lan> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 28 Jan 2002 13:35:46 +1100 Message-ID: <2690.1012185346@ocs3.intra.ocs.com.au> Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 602 Lines: 13 On Sun, 27 Jan 2002 17:28:36 -0900, Ethan Benson wrote: >in the i386 version you seem to be adding about 25 dummy syscalls, am >i correct in assuming this is just `padding' to avoid conflicts if >Linus allocates some new syscalls? is the same necessary/wise to do >on powerpc as well? For initial testing it is easier to use the next 3 free entries. We added the padding to avoid having to renumber each time Linus used another syscall number. I wish Linus would take the patch for assigning dynamic syscall numbers, alas he has ignored the last 5 times I sent the patch :( From owner-linux-xfs@oss.sgi.com Sun Jan 27 20:47:36 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0S4laP05091 for linux-xfs-outgoing; Sun, 27 Jan 2002 20:47:36 -0800 Received: from hob.slb.nwc.acsalaska.net (hob.slb.nwc.acsalaska.net [209.112.155.42]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0S4lTP05059 for ; Sun, 27 Jan 2002 20:47:29 -0800 Received: from erbenson.alaska.net (133-pm15.nwc.alaska.net [209.112.141.133]) by hob.slb.nwc.acsalaska.net (8.11.6/8.11.6) with ESMTP id g0S3lPs94508 for ; Sun, 27 Jan 2002 18:47:25 -0900 (AKST) (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 8F2283938 for ; Sun, 27 Jan 2002 18:47:24 -0900 (AKST) Received: by plato.local.lan (Postfix, from userid 1000) id 900821023C; Sun, 27 Jan 2002 18:47:24 -0900 (AKST) Date: Sun, 27 Jan 2002 18:47:24 -0900 From: Ethan Benson To: linux-xfs@oss.sgi.com Subject: Re: extended attributes support on powerpc Message-ID: <20020127184724.L14742@plato.local.lan> Mail-Followup-To: linux-xfs@oss.sgi.com References: <20020127172836.A17042@plato.local.lan> <2690.1012185346@ocs3.intra.ocs.com.au> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="pFej7zHSL6C5fFIz" Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <2690.1012185346@ocs3.intra.ocs.com.au>; from kaos@sgi.com on Mon, Jan 28, 2002 at 01:35:46PM +1100 X-OS: Debian GNU Mail-Copies-To: nobody X-No-CC: I subscribe to this list; do not CC me on replies. Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 1457 Lines: 48 --pFej7zHSL6C5fFIz Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Jan 28, 2002 at 01:35:46PM +1100, Keith Owens wrote: > On Sun, 27 Jan 2002 17:28:36 -0900,=20 > Ethan Benson wrote: > >in the i386 version you seem to be adding about 25 dummy syscalls, am > >i correct in assuming this is just `padding' to avoid conflicts if > >Linus allocates some new syscalls? is the same necessary/wise to do > >on powerpc as well? >=20 > For initial testing it is easier to use the next 3 free entries. We > added the padding to avoid having to renumber each time Linus used > another syscall number. I wish Linus would take the patch for i assume the numbering doesn't affect userland at all, its only used for internal compilation of the kernel correct?=20=20 > assigning dynamic syscall numbers, alas he has ignored the last 5 times > I sent the patch :( $ ls -l /dev/Linus lrwxr-xr-x 1 root root 4 Jan 27 2002 /dev/Linus -> /dev/null $ ;-) --=20 Ethan Benson http://www.alaska.net/~erbenson/ --pFej7zHSL6C5fFIz 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 iEYEARECAAYFAjxUycwACgkQJKx7GixEevxBVQCfWf2PfvbUtv161Z3N9YP7mrWh FmEAnA4LNfVm4HyDNeDyf7g1HSycJoJf =cJCn -----END PGP SIGNATURE----- --pFej7zHSL6C5fFIz-- From owner-linux-xfs@oss.sgi.com Sun Jan 27 21:03:28 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0S53SB06911 for linux-xfs-outgoing; Sun, 27 Jan 2002 21:03:28 -0800 Received: from mail.ocs.com.au (mail.ocs.com.au [203.34.97.2]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0S53OP06886 for ; Sun, 27 Jan 2002 21:03:24 -0800 Received: (qmail 3517 invoked from network); 28 Jan 2002 04:03:20 -0000 Received: from ocs3.intra.ocs.com.au (192.168.255.3) by mail.ocs.com.au with SMTP; 28 Jan 2002 04:03:19 -0000 Received: by ocs3.intra.ocs.com.au (Postfix, from userid 16331) id 5DA413000B8; Mon, 28 Jan 2002 15:03:17 +1100 (EST) Received: from ocs3.intra.ocs.com.au (localhost [127.0.0.1]) by ocs3.intra.ocs.com.au (Postfix) with ESMTP id DE1F7168; Mon, 28 Jan 2002 15:03:17 +1100 (EST) X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 From: Keith Owens To: Ethan Benson Cc: linux-xfs@oss.sgi.com Subject: Re: extended attributes support on powerpc In-reply-to: Your message of "Sun, 27 Jan 2002 18:47:24 -0900." <20020127184724.L14742@plato.local.lan> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 28 Jan 2002 15:03:11 +1100 Message-ID: <3368.1012190591@ocs3.intra.ocs.com.au> Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 379 Lines: 9 On Sun, 27 Jan 2002 18:47:24 -0900, Ethan Benson wrote: >i assume the numbering doesn't affect userland at all, its only used >for internal compilation of the kernel correct? The syscall numbers are also used by the ACL programs. In XFS CVS theye are in cmd/attr/libattr/attr.c at line 292. Forgot about those, I don't work on the user space commands. From owner-linux-xfs@oss.sgi.com Sun Jan 27 21:29:12 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0S5TCc09530 for linux-xfs-outgoing; Sun, 27 Jan 2002 21:29:12 -0800 Received: from mail.ocs.com.au (mail.ocs.com.au [203.34.97.2]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0S5STP09442 for ; Sun, 27 Jan 2002 21:28:34 -0800 Received: (qmail 3625 invoked from network); 28 Jan 2002 04:28:07 -0000 Received: from ocs3.intra.ocs.com.au (192.168.255.3) by mail.ocs.com.au with SMTP; 28 Jan 2002 04:28:07 -0000 Received: by ocs3.intra.ocs.com.au (Postfix, from userid 16331) id E70CF3000B8; Mon, 28 Jan 2002 15:27:59 +1100 (EST) Received: from ocs3.intra.ocs.com.au (localhost [127.0.0.1]) by ocs3.intra.ocs.com.au (Postfix) with ESMTP id B2232168; Mon, 28 Jan 2002 15:27:59 +1100 (EST) X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 From: Keith Owens To: linux-xfs@oss.sgi.com Cc: lm@bitmover.com Subject: XFS bug with ftruncate, mmap and holes. Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 28 Jan 2002 15:27:54 +1100 Message-ID: <3615.1012192074@ocs3.intra.ocs.com.au> Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 2230 Lines: 71 2.4.17-xfs t-o-t ptools (Mon Jan 28 04:15:18 UTC 2002). gcc version 2.96 20000731 (Red Hat Linux 7.1 2.96-81) glibc-2.2.2-10 This program mimics the behaviour of BitKeeper mdbm code when expanding the database, it hits a bug on XFS. == xfs-bug.c #include #include #include #include #include #define size 4096 static const char name[] = "db_main"; int main(void) { int fd; void *m; time_t t; struct tm tm; fd = open(name, O_RDWR|O_CREAT|O_TRUNC, 0666); // write(fd, name, 1); /* 1 */ // lseek(fd, size, SEEK_SET); /* 2 */ // write(fd, name, 1); /* 3 */ ftruncate(fd, size); m = mmap(NULL, size, PROT_READ|PROT_WRITE, MAP_SHARED, fd, 0); memset(m, 'A', size); t = time(NULL); tm = *localtime(&t); strcpy(m, asctime(&tm)); fsync(fd); munmap(m, size); close(fd); return(0); } gcc xfs-bug.c -o xfs-bug ../xfs-bug cat db_main Make a note of the timestamp then do a clean shutdown and reboot. cat db_main, it will be garbage or it will contain data from a previous run. Expanding a file with ftruncate is undefined behaviour, http://www.db.opengroup.org/cgi-bin/dbcgi?TPL=sd_fileframe&dir=xsh&file=ftruncate&TOKEN=EWJO&vendor1=1&EWJO=1. "If the file previously was larger than length, the extra data is discarded. If it was previously shorter than length, some systems that conform to the Single UNIX Specification, Version 2 may change the file or increase its size. If the file is extended, the extended area appears as if it were zero-filled." Note "may change the file or increase its size", ftruncate upwards is not guaranteed to work. The mdbm code is violating standards. Uncomment lines 2 and 3 so the file is extended first then truncated down. The code now conforms to standards but XFS still has a bug. The file on disk is valid but after a clean shutdown and reboot it contains other data (check the timestamp). Only after uncommenting line 1 as well as 2,3 does XFS generate clean data after a reboot. Looks like a nasty interaction between mmap and files with holes in them. What is strange is that without lines 1,2,3 the code writes valid data. After a long delay or a clean shutdown the data suddenly gets changed. From owner-linux-xfs@oss.sgi.com Sun Jan 27 22:36:42 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0S6ag716350 for linux-xfs-outgoing; Sun, 27 Jan 2002 22:36:42 -0800 Received: from iris.slb.nwc.acsalaska.net (iris.slb.nwc.acsalaska.net [209.112.155.43]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0S6aTP16306 for ; Sun, 27 Jan 2002 22:36:29 -0800 Received: from erbenson.alaska.net (133-pm15.nwc.alaska.net [209.112.141.133]) by iris.slb.nwc.acsalaska.net (8.11.6/8.11.6) with ESMTP id g0S5aPa49780 for ; Sun, 27 Jan 2002 20:36:25 -0900 (AKST) (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 379E339E4 for ; Sun, 27 Jan 2002 20:36:24 -0900 (AKST) Received: by plato.local.lan (Postfix, from userid 1000) id 6DC5C1023C; Sun, 27 Jan 2002 20:36:24 -0900 (AKST) Date: Sun, 27 Jan 2002 20:36:24 -0900 From: Ethan Benson To: linux-xfs@oss.sgi.com Subject: Re: extended attributes support on powerpc Message-ID: <20020127203624.M14742@plato.local.lan> Mail-Followup-To: linux-xfs@oss.sgi.com References: <20020127184724.L14742@plato.local.lan> <3368.1012190591@ocs3.intra.ocs.com.au> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="YS7t75H5cNTCpbja" Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <3368.1012190591@ocs3.intra.ocs.com.au>; from kaos@sgi.com on Mon, Jan 28, 2002 at 03:03:11PM +1100 X-OS: Debian GNU Mail-Copies-To: nobody X-No-CC: I subscribe to this list; do not CC me on replies. Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 2915 Lines: 100 --YS7t75H5cNTCpbja Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Jan 28, 2002 at 03:03:11PM +1100, Keith Owens wrote: > On Sun, 27 Jan 2002 18:47:24 -0900,=20 > Ethan Benson wrote: > >i assume the numbering doesn't affect userland at all, its only used > >for internal compilation of the kernel correct? >=20 > The syscall numbers are also used by the ACL programs. In XFS CVS > theye are in cmd/attr/libattr/attr.c at line 292. Forgot about those, > I don't work on the user space commands. OK, i patched the kernel and attr, rebuilt the attr package and things appear to be working properly. my patches don't include the extra empty `placeholder' syscalls to avoid conflicts with future syscall additions.=20=20 would you be willing to add the necessary syscalls to powerpc in the xfs CVS tree?=20 here are the patches (i haven't checked if the acl package needs patching too yet): diff -urN linux-2.4.17.orig/arch/ppc/kernel/misc.S linux-2.4.17/arch/ppc/ke= rnel/misc.S --- linux-2.4.17.orig/arch/ppc/kernel/misc.S Sat Jan 26 01:53:59 2002 +++ linux-2.4.17/arch/ppc/kernel/misc.S Sun Jan 27 18:55:09 2002 @@ -1122,6 +1122,15 @@ .long sys_madvise /* 205 */ .long sys_mincore .long sys_gettid +#ifdef CONFIG_HAVE_ATTRCTL + .long sys_attrctl + .long sys_acl_get + .long sys_acl_set /* 210 */ +#else + .long sys_ni_syscall + .long sys_ni_syscall + .long sys_ni_syscall /* 210 */ +#endif /* CONFIG_HAVE_ATTRCTL */=09 .rept NR_syscalls-(.-sys_call_table)/4 .long sys_ni_syscall .endr diff -urN linux-2.4.17.orig/include/asm-ppc/unistd.h linux-2.4.17/include/a= sm-ppc/unistd.h --- linux-2.4.17.orig/include/asm-ppc/unistd.h Fri Nov 2 16:43:54 2001 +++ linux-2.4.17/include/asm-ppc/unistd.h Sun Jan 27 19:33:57 2002 @@ -215,6 +215,9 @@ #define __NR_madvise 205 #define __NR_mincore 206 #define __NR_gettid 207 +#define __NR__attrctl 208 +#define __NR__acl_get 209 +#define __NR__acl_set 210 =20 #define __NR(n) #n =20 and the libattr patch: diff -urN attr-1.1.4.orig/libattr/attr.c attr-1.1.4/libattr/attr.c --- attr-1.1.4.orig/libattr/attr.c Thu Jan 10 12:40:29 2002 +++ attr-1.1.4/libattr/attr.c Sun Jan 27 19:30:36 2002 @@ -303,6 +303,11 @@ # ifndef SYS__attrctl # define SYS__attrctl 1260 # endif +#elif __powerpc__ +# define HAVE_ACL_SYSCALL 1 +# ifndef SYS__attrctl +# define SYS__attrctl 208 +# endif #else # define HAVE_ACL_SYSCALL 0 #endif --=20 Ethan Benson http://www.alaska.net/~erbenson/ --YS7t75H5cNTCpbja 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 iEYEARECAAYFAjxU41gACgkQJKx7GixEevxbnQCdGt4nvqJbZTEiMpB8Y7NdpVwl 8LwAmwYtl70DBPMXE9I02g3phkwoFZnf =XYij -----END PGP SIGNATURE----- --YS7t75H5cNTCpbja-- From owner-linux-xfs@oss.sgi.com Mon Jan 28 03:12:49 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0SBCnt13410 for linux-xfs-outgoing; Mon, 28 Jan 2002 03:12:49 -0800 Received: from host0.o-e-p.co.uk (host217-35-80-213.in-addr.btopenworld.com [217.35.80.213]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0SBChP13380 for ; Mon, 28 Jan 2002 03:12:44 -0800 Received: from [213.122.72.49] (helo=pyewacket.nic.uklinux.net) by host0.o-e-p.co.uk with asmtp (TLSv1:DES-CBC3-SHA:168) (Exim 3.34 #1) id 16V8mP-0006Y6-00 for linux-xfs@oss.sgi.com; Mon, 28 Jan 2002 10:12:50 +0000 Received: from nic by pyewacket.nic.uklinux.net with local (Exim 3.34 #1) id 16V8Wp-0002da-00 for linux-xfs@oss.sgi.com; Mon, 28 Jan 2002 09:56:43 +0000 Subject: Seperate log location [Was: Re: How to create a separate log] From: Nic Doye To: linux-xfs@oss.sgi.com In-Reply-To: <3C5306E1.8040408@sgi.com> References: <20020126111331.A5571@bistro.marx> <3C5306E1.8040408@sgi.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/1.0.1 (1.0.1-2) Date: 28 Jan 2002 09:56:43 +0000 Message-Id: <1012211803.2094.8.camel@pyewacket> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 902 Lines: 29 On Sat, 2002-01-26 at 19:43, Stephen Lord wrote: > Default log location is in the middle of the partition/volume you run > mkfs on. > If you want an external log then you need to dedicate a partition to it, > it cannot > be in a file. > > These are the options for an external log: > > mkfs -t xfs -l logdev=/dev/xxx,size=XXXb /dev/yyy > mount -t xfs -o logdev=/dev/xxx /dev/yyy /mnt Just a small question for those people who use external logs. Do you put them on the same disk (or disk set) or do you put them on a seperate disk (and indeed, seperate controller). If you do put them on a seperate disk, is it mirrored? To a seperate controller? I'm just thinking, that to build a fault tolerant, yet high throughput server could start costing a lot of cash... On the otherhand, does (hardware) RAID5 push the performance down so low, that an external log won't improve things anyway. nic From owner-linux-xfs@oss.sgi.com Mon Jan 28 03:38:27 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0SBcRU17074 for linux-xfs-outgoing; Mon, 28 Jan 2002 03:38:27 -0800 Received: from relay.xlink.net (relay.xlink.net [193.141.40.5]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0SBcKP17043 for ; Mon, 28 Jan 2002 03:38:21 -0800 Received: from lizard.webland.de (lizard.webland.de [194.122.76.201]) by relay.xlink.net (8.9.3/8.8.7) with ESMTP id LAA24653; Mon, 28 Jan 2002 11:38:07 +0100 (MET) Received: (from uucp@localhost) by lizard.webland.de (8.8.8/8.8.7) id LAA06207; Mon, 28 Jan 2002 11:38:07 +0100 (MET) >Received: from mobile.sauter-bc.com (unknown [10.1.6.21]) by basel1.sauter-bc.com (Postfix) with ESMTP id 025B557306; Mon, 28 Jan 2002 11:37:38 +0100 (CET) Received: from ch.sauter-bc.com (support.cad.sba [10.1.200.117]) by mobile.sauter-bc.com (Postfix) with ESMTP id B863F25835; Mon, 28 Jan 2002 11:37:37 +0100 (CET) Message-ID: <3C5529F1.1C911083@ch.sauter-bc.com> Date: Mon, 28 Jan 2002 11:37:37 +0100 From: Simon Matter Organization: Sauter AG, Basel X-Mailer: Mozilla 4.77 [de] (X11; U; Linux 2.2.19-6.2.12 i686) X-Accept-Language: de-CH, en MIME-Version: 1.0 To: Nic Doye Cc: linux-xfs@oss.sgi.com Subject: Re: Seperate log location [Was: Re: How to create a separate log] References: <20020126111331.A5571@bistro.marx> <3C5306E1.8040408@sgi.com> <1012211803.2094.8.camel@pyewacket> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 1248 Lines: 39 Nic Doye schrieb: > > On Sat, 2002-01-26 at 19:43, Stephen Lord wrote: > > > Default log location is in the middle of the partition/volume you run > > mkfs on. > > If you want an external log then you need to dedicate a partition to it, > > it cannot > > be in a file. > > > > These are the options for an external log: > > > > mkfs -t xfs -l logdev=/dev/xxx,size=XXXb /dev/yyy > > mount -t xfs -o logdev=/dev/xxx /dev/yyy /mnt > > Just a small question for those people who use external logs. Do you put > them on the same disk (or disk set) or do you put them on a seperate > disk (and indeed, seperate controller). > > If you do put them on a seperate disk, is it mirrored? To a seperate > controller? > > I'm just thinking, that to build a fault tolerant, yet high throughput > server could start costing a lot of cash... On the otherhand, does > (hardware) RAID5 push the performance down so low, that an external log > won't improve things anyway. > > nic Software RAID5 and the log on Software RAID1 on the same disks works very fine for me. You'll need a really expensive Hardware RAID controller to get better performance! I think it's very important to put the log on RAID too otherwise your RAID5 is useless, isn't it? -Simon From owner-linux-xfs@oss.sgi.com Mon Jan 28 03:58:29 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0SBwT219432 for linux-xfs-outgoing; Mon, 28 Jan 2002 03:58:29 -0800 Received: from ADSL-Bergs.RZ.RWTH-Aachen.DE (adsl-bergs.rz.RWTH-Aachen.DE [137.226.80.218]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0SBwPP19405 for ; Mon, 28 Jan 2002 03:58:25 -0800 Received: from [192.168.1.2] (helo=ralf) by ADSL-Bergs.RZ.RWTH-Aachen.DE with smtp (Exim 3.12 #1) id 16V9UP-0003kg-00 for linux-xfs@oss.sgi.com; Mon, 28 Jan 2002 11:58:17 +0100 From: "Ralf G. R. Bergs" To: "Linux XFS Mailing List" Date: Mon, 28 Jan 2002 11:58:17 +0100 Reply-To: "Ralf G. R. Bergs" X-Mailer: PMMail 2000 Professional (2.20.2380) For Windows 2000 (5.0.2195;2) MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Subject: Contradiction of "recommended compiler" in kernel-ML and XFS FAQ? Message-Id: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 975 Lines: 24 Hi there, I just read the following in the linux-kernel mailing list FAQ: >What are the recommended compiler/binutils for building kernels? > >(REG) This depends on the kernel version. Until 26-OCT-2000, gcc 2.7.2.3 was >the recommended compiler for all kernels. On this date, Linus announced that >gcc 2.91.66 (aka egcs 1.1.2) is the recommended compiler for 2.4.x kernels up >to version 2.4.9. Gcc 2.95.3 is the recommended compiler for kernel 2.4.10 and >later. In the XFS FAQ it says "use egcs 1.1.2." But what if I would like to use recent 2.4.x kernels with XFS? I guess you don't want me to compile the XFS stuff with egcs-1.1.2 and the rest of the kernel with gcc-2.95.3? ;-) -- Verkaufe Original-BMW-Raeder: L I N U X .~. http://adsl-bergs.rz.rwth-aachen.de/~rabe The Choice /V\ of a GNU /( )\ Generation ^^-^^ From owner-linux-xfs@oss.sgi.com Mon Jan 28 04:45:28 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0SCjSg25039 for linux-xfs-outgoing; Mon, 28 Jan 2002 04:45:28 -0800 Received: from smtpzilla1.xs4all.nl (smtpzilla1.xs4all.nl [194.109.127.137]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0SCjNP25012 for ; Mon, 28 Jan 2002 04:45:23 -0800 Received: from auto-nb1.xs4all.nl (qn-212-58-167-191.quicknet.nl [212.58.167.191]) by smtpzilla1.xs4all.nl (8.12.0/8.12.0) with ESMTP id g0SBjJAv046014; Mon, 28 Jan 2002 12:45:19 +0100 (CET) Message-Id: <4.3.2.7.2.20020128124020.034fc5e8@pop.xs4all.nl> X-Sender: knuffie@pop.xs4all.nl X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 28 Jan 2002 12:43:39 +0100 To: "Ralf G. R. Bergs" , "Linux XFS Mailing List" From: Seth Mos Subject: Re: Contradiction of "recommended compiler" in kernel-ML and XFS FAQ? In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 1250 Lines: 35 At 11:58 28-1-2002 +0100, Ralf G. R. Bergs wrote: >Hi there, > >I just read the following in the linux-kernel mailing list FAQ: > > >What are the recommended compiler/binutils for building kernels? > > > >(REG) This depends on the kernel version. Until 26-OCT-2000, gcc 2.7.2.3 was > >the recommended compiler for all kernels. On this date, Linus announced that > >gcc 2.91.66 (aka egcs 1.1.2) is the recommended compiler for 2.4.x > kernels up > >to version 2.4.9. Gcc 2.95.3 is the recommended compiler for kernel > 2.4.10 and > >later. > >In the XFS FAQ it says "use egcs 1.1.2." But what if I would like to use >recent >2.4.x kernels with XFS? I guess you don't want me to compile the XFS stuff >with >egcs-1.1.2 and the rest of the kernel with gcc-2.95.3? ;-) Use egcs 1.1.2 for production systems. This is the most tested compiler with XFS. This was because the early gcc-2.96 version was problematic. It's a lot better nowadays and XFS is a bit more friendly to other compilers without eating your filesystem. But egcs 1.1.2 is still the most tested and is what I still use for my production machines. Cheers -- Seth Every program has two purposes one for which it was written and another for which it wasn't I use the last kind. From owner-linux-xfs@oss.sgi.com Mon Jan 28 04:57:06 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0SCv6V26412 for linux-xfs-outgoing; Mon, 28 Jan 2002 04:57:06 -0800 Received: from ADSL-Bergs.RZ.RWTH-Aachen.DE (adsl-bergs.rz.RWTH-Aachen.DE [137.226.80.218]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0SCv0P26376 for ; Mon, 28 Jan 2002 04:57:00 -0800 Received: from [192.168.1.2] (helo=ralf) by ADSL-Bergs.RZ.RWTH-Aachen.DE with smtp (Exim 3.12 #1) id 16VAP6-0003qi-00; Mon, 28 Jan 2002 12:56:52 +0100 From: "Ralf G. R. Bergs" To: "Linux XFS Mailing List" Cc: "Seth Mos" Date: Mon, 28 Jan 2002 12:56:51 +0100 Reply-To: "Ralf G. R. Bergs" X-Mailer: PMMail 2000 Professional (2.20.2380) For Windows 2000 (5.0.2195;2) In-Reply-To: <4.3.2.7.2.20020128124020.034fc5e8@pop.xs4all.nl> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Subject: Re: Contradiction of "recommended compiler" in kernel-ML and XFS FAQ? Message-Id: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 977 Lines: 27 On Mon, 28 Jan 2002 12:43:39 +0100, Seth Mos wrote: [...] >>In the XFS FAQ it says "use egcs 1.1.2." But what if I would like to use >>recent >>2.4.x kernels with XFS? I guess you don't want me to compile the XFS stuff >>with >>egcs-1.1.2 and the rest of the kernel with gcc-2.95.3? ;-) > >Use egcs 1.1.2 for production systems. This is the most tested compiler >with XFS. This was because the early gcc-2.96 version was problematic. It's >a lot better nowadays and XFS is a bit more friendly to other compilers >without eating your filesystem. But egcs 1.1.2 is still the most tested and >is what I still use for my production machines. Ok, will do. Thanks for your comment. Ralf -- Verkaufe Original-BMW-Raeder: L I N U X .~. http://adsl-bergs.rz.rwth-aachen.de/~rabe The Choice /V\ of a GNU /( )\ Generation ^^-^^ From owner-linux-xfs@oss.sgi.com Mon Jan 28 06:00:57 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0SE0vw04017 for linux-xfs-outgoing; Mon, 28 Jan 2002 06:00:57 -0800 Received: from www.fortuitous.com (cs6625128-203.austin.rr.com [66.25.128.203]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0SE0rP03983 for ; Mon, 28 Jan 2002 06:00:53 -0800 Received: by www.fortuitous.com (Postfix, from userid 500) id 2A62B2DC; Sun, 27 Jan 2002 20:50:23 -0600 (CST) Date: Sun, 27 Jan 2002 20:50:23 -0600 From: pac@fortuitous.com To: linux-xfs@oss.sgi.com Subject: Re: double mounting and other strangeness. Message-ID: <20020127205023.A14726@bistro.marx> Reply-To: pac@fortuitous.com References: <20020127113553.A13031@bistro.marx> <27476.1012173537@ocs3.intra.ocs.com.au> <20020127173852.A14538@bistro.marx> <20020128015656.A4541@wotan.suse.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20020128015656.A4541@wotan.suse.de> User-Agent: Mutt/1.3.23i Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 972 Lines: 22 On Mon, Jan 28, 2002 at 01:56:56AM +0100, Andi Kleen wrote: > > Is there any legitimate reason you would want to do this? I dont > > want to scream at them if there is a good reason for it. What is the > > opinion of the FS developers here? > > It's for example useful for chroot. You can mount a single file system > in multiple chroots. There is also the related feature of mount --bind > which allows to do the same thing for directories and files. Again > it is useful for chroots. Yes, but in my case, i had 2 filesystems mounted on the SAMe mount point. Here is an inherent ambiguity in which filesystem i am actually write/reading from. -Phil Carinhas -- .--------------------------------------------------------. | Dr. Philip A. Carinhas | pac@fortuitous.com | | Fortuitous Technologies Inc. | http://fortuitous.com | | Linux Consulting & Training | Tel : 1-512-467-2154 | `--------------------------------------------------------' From owner-linux-xfs@oss.sgi.com Mon Jan 28 06:08:00 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0SE80804918 for linux-xfs-outgoing; Mon, 28 Jan 2002 06:08:00 -0800 Received: from sgi.com (sgi-too.SGI.COM [204.94.211.39]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0SE7uP04892 for ; Mon, 28 Jan 2002 06:07:56 -0800 Received: from zeus-e8.americas.sgi.com (zeus-e8.americas.sgi.com [128.162.8.103]) by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id FAA09367 for ; Mon, 28 Jan 2002 05:07:53 -0800 (PST) mail_from (lord@sgi.com) Received: from tulip-e185.americas.sgi.com (tulip-e185.americas.sgi.com [128.162.185.208]) by zeus-e8.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id HAA177635; Mon, 28 Jan 2002 07:06:37 -0600 (CST) Received: from sgi.com (/Pw2PRVN6KSTUquHsRpsf+RXVbWxbLgx@lord-h1.americas.sgi.com [206.11.101.42]) by tulip-e185.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.7) with ESMTP id HAA82154; Mon, 28 Jan 2002 07:06:37 -0600 (CST) Message-ID: <3C554CD0.9040105@sgi.com> Date: Mon, 28 Jan 2002 07:06:24 -0600 From: Stephen Lord User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.7) Gecko/20011226 X-Accept-Language: en-us MIME-Version: 1.0 To: pac@fortuitous.com CC: linux-xfs@oss.sgi.com Subject: Re: double mounting and other strangeness. References: <20020127113553.A13031@bistro.marx> <27476.1012173537@ocs3.intra.ocs.com.au> <20020127173852.A14538@bistro.marx> <20020128015656.A4541@wotan.suse.de> <20020127205023.A14726@bistro.marx> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 906 Lines: 29 pac@fortuitous.com wrote: >On Mon, Jan 28, 2002 at 01:56:56AM +0100, Andi Kleen wrote: > >>> Is there any legitimate reason you would want to do this? I dont >>>want to scream at them if there is a good reason for it. What is the >>>opinion of the FS developers here? >>> >>It's for example useful for chroot. You can mount a single file system >>in multiple chroots. There is also the related feature of mount --bind >>which allows to do the same thing for directories and files. Again >>it is useful for chroots. >> > > Yes, but in my case, i had 2 filesystems mounted on the SAMe mount point. >Here is an inherent ambiguity in which filesystem i am actually write/reading >from. > But mount in unix allows you to mount a filesystem within another filesystem, otherwise you could not have nested filesystems. Mounting on top of the root of a filesystem is just a special case of this. Steve From owner-linux-xfs@oss.sgi.com Mon Jan 28 06:13:01 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0SED1m05566 for linux-xfs-outgoing; Mon, 28 Jan 2002 06:13:01 -0800 Received: from sgi.com (sgi-too.SGI.COM [204.94.211.39]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0SECoP05524 for ; Mon, 28 Jan 2002 06:12:50 -0800 Received: from zeus-e8.americas.sgi.com (zeus-e8.americas.sgi.com [128.162.8.103]) by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id FAA01750 for ; Mon, 28 Jan 2002 05:12:48 -0800 (PST) mail_from (lord@sgi.com) Received: from tulip-e185.americas.sgi.com (tulip-e185.americas.sgi.com [128.162.185.208]) by zeus-e8.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id HAA183531; Mon, 28 Jan 2002 07:11:32 -0600 (CST) Received: from sgi.com (k/meUa1O9bJeJuGOu9lhLSRRHv0jOpli@lord-h1.americas.sgi.com [206.11.101.42]) by tulip-e185.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.7) with ESMTP id HAA97601; Mon, 28 Jan 2002 07:11:30 -0600 (CST) Message-ID: <3C554DF5.80701@sgi.com> Date: Mon, 28 Jan 2002 07:11:17 -0600 From: Stephen Lord User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.7) Gecko/20011226 X-Accept-Language: en-us MIME-Version: 1.0 To: Keith Owens CC: linux-xfs@oss.sgi.com, lm@bitmover.com Subject: Re: XFS bug with ftruncate, mmap and holes. References: <3615.1012192074@ocs3.intra.ocs.com.au> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 2711 Lines: 88 Keith Owens wrote: >2.4.17-xfs t-o-t ptools (Mon Jan 28 04:15:18 UTC 2002). >gcc version 2.96 20000731 (Red Hat Linux 7.1 2.96-81) >glibc-2.2.2-10 > >This program mimics the behaviour of BitKeeper mdbm code when expanding >the database, it hits a bug on XFS. > >== xfs-bug.c > >#include >#include >#include >#include >#include > >#define size 4096 >static const char name[] = "db_main"; > >int main(void) >{ > int fd; > void *m; > time_t t; > struct tm tm; > fd = open(name, O_RDWR|O_CREAT|O_TRUNC, 0666); > // write(fd, name, 1); /* 1 */ > // lseek(fd, size, SEEK_SET); /* 2 */ > // write(fd, name, 1); /* 3 */ > ftruncate(fd, size); > m = mmap(NULL, size, PROT_READ|PROT_WRITE, MAP_SHARED, fd, 0); > memset(m, 'A', size); > t = time(NULL); > tm = *localtime(&t); > strcpy(m, asctime(&tm)); > fsync(fd); > munmap(m, size); > close(fd); > return(0); >} > >gcc xfs-bug.c -o xfs-bug >../xfs-bug >cat db_main > >Make a note of the timestamp then do a clean shutdown and reboot. cat >db_main, it will be garbage or it will contain data from a previous >run. > >Expanding a file with ftruncate is undefined behaviour, >http://www.db.opengroup.org/cgi-bin/dbcgi?TPL=sd_fileframe&dir=xsh&file=ftruncate&TOKEN=EWJO&vendor1=1&EWJO=1. > > "If the file previously was larger than length, the extra data is > discarded. If it was previously shorter than length, some systems > that conform to the Single UNIX Specification, Version 2 may change > the file or increase its size. If the file is extended, the extended > area appears as if it were zero-filled." > >Note "may change the file or increase its size", ftruncate upwards is >not guaranteed to work. The mdbm code is violating standards. > >Uncomment lines 2 and 3 so the file is extended first then truncated >down. The code now conforms to standards but XFS still has a bug. The >file on disk is valid but after a clean shutdown and reboot it contains >other data (check the timestamp). > >Only after uncommenting line 1 as well as 2,3 does XFS generate clean >data after a reboot. Looks like a nasty interaction between mmap and >files with holes in them. What is strange is that without lines 1,2,3 >the code writes valid data. After a long delay or a clean shutdown the >data suddenly gets changed. > Do we have any indication if this is something which has 'appeared' at some point, or has been around for a while? Looks like a page dirtied only by mmap is not getting flushed by this code. Other user's of mmap (such as the loader) appear not to have problems like this. I will take a look, but I suspect an msync before unmap will work around this for now (not tested yet). Steve From owner-linux-xfs@oss.sgi.com Mon Jan 28 06:23:43 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0SENhI06845 for linux-xfs-outgoing; Mon, 28 Jan 2002 06:23:43 -0800 Received: from mail.ocs.com.au (mail.ocs.com.au [203.34.97.2]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0SENbP06816 for ; Mon, 28 Jan 2002 06:23:38 -0800 Received: (qmail 12880 invoked from network); 28 Jan 2002 13:23:32 -0000 Received: from ocs3.intra.ocs.com.au (192.168.255.3) by mail.ocs.com.au with SMTP; 28 Jan 2002 13:23:32 -0000 Received: by ocs3.intra.ocs.com.au (Postfix, from userid 16331) id E94B43000AD; Tue, 29 Jan 2002 00:23:31 +1100 (EST) Received: from ocs3.intra.ocs.com.au (localhost [127.0.0.1]) by ocs3.intra.ocs.com.au (Postfix) with ESMTP id E60628E; Tue, 29 Jan 2002 00:23:31 +1100 (EST) X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 From: Keith Owens To: Stephen Lord Cc: linux-xfs@oss.sgi.com, lm@bitmover.com Subject: Re: XFS bug with ftruncate, mmap and holes. In-reply-to: Your message of "Mon, 28 Jan 2002 07:11:17 MDT." <3C554DF5.80701@sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 29 Jan 2002 00:23:26 +1100 Message-ID: <6928.1012224206@ocs3.intra.ocs.com.au> Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 953 Lines: 27 On Mon, 28 Jan 2002 07:11:17 -0600, Stephen Lord wrote: >Do we have any indication if this is something which has 'appeared' at >some point, >or has been around for a while? No idea, I have only just started using mdbm on 2.4.17-xfs. >Looks like a page dirtied only by mmap >is not >getting flushed by this code. Other user's of mmap (such as the loader) >appear not >to have problems like this. > >I will take a look, but I suspect an msync before unmap will work around >this for >now (not tested yet). I thought about adding msync but the strange thing is the data is available in the file after the program has exited but that data is later corrupted. The corruption does not appear immediately, only if the file is left alone for a long time or the system is rebooted does the corruption appear. Makes me think something is overwriting the pages later. Just added msync(m, size, MS_SYNC) before munmap, bug still exists. From owner-linux-xfs@oss.sgi.com Mon Jan 28 07:06:40 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0SF6eB11410 for linux-xfs-outgoing; Mon, 28 Jan 2002 07:06:40 -0800 Received: from iris.slb.nwc.acsalaska.net (iris.slb.nwc.acsalaska.net [209.112.155.43]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0SF6TP11375 for ; Mon, 28 Jan 2002 07:06:29 -0800 Received: from erbenson.alaska.net (150-pm19.nwc.alaska.net [209.112.142.150]) by iris.slb.nwc.acsalaska.net (8.11.6/8.11.6) with ESMTP id g0SE6Pa20755; Mon, 28 Jan 2002 05:06:25 -0900 (AKST) (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 A4C803938; Mon, 28 Jan 2002 05:06:24 -0900 (AKST) Received: by plato.local.lan (Postfix, from userid 1000) id 9EECE1023C; Mon, 28 Jan 2002 05:06:23 -0900 (AKST) Date: Mon, 28 Jan 2002 05:06:23 -0900 From: Ethan Benson To: Stephen Lord , linux-xfs@oss.sgi.com Subject: Re: XFS bug with ftruncate, mmap and holes. Message-ID: <20020128050623.N14742@plato.local.lan> Mail-Followup-To: Stephen Lord , linux-xfs@oss.sgi.com References: <3C554DF5.80701@sgi.com> <6928.1012224206@ocs3.intra.ocs.com.au> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="QQNwO3VdVfodZayb" Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <6928.1012224206@ocs3.intra.ocs.com.au>; from kaos@sgi.com on Tue, Jan 29, 2002 at 12:23:26AM +1100 X-OS: Debian GNU Mail-Copies-To: nobody X-No-CC: I subscribe to this list; do not CC me on replies. Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 2669 Lines: 77 --QQNwO3VdVfodZayb Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Jan 29, 2002 at 12:23:26AM +1100, Keith Owens wrote: > On Mon, 28 Jan 2002 07:11:17 -0600,=20 > Stephen Lord wrote: > >Do we have any indication if this is something which has 'appeared' at= =20 > >some point, > >or has been around for a while? >=20 > No idea, I have only just started using mdbm on 2.4.17-xfs. >=20 > >Looks like a page dirtied only by mmap=20 > >is not > >getting flushed by this code. Other user's of mmap (such as the loader)= =20 > >appear not > >to have problems like this. > > > >I will take a look, but I suspect an msync before unmap will work around= =20 > >this for > >now (not tested yet). >=20 > I thought about adding msync but the strange thing is the data is > available in the file after the program has exited but that data is > later corrupted. The corruption does not appear immediately, only if > the file is left alone for a long time or the system is rebooted does > the corruption appear. Makes me think something is overwriting the > pages later. >=20 > Just added msync(m, size, MS_SYNC) before munmap, bug still exists. >=20 this sounds as if it could be related to a obscure problem ive been observing in apt-get since 2.4.17 (more so with the Dec 23 cvs patch, and less so with both split patches).=20 apt-get starts segfaulting on all operations when it reads /var/cache/apt/pkgcache.bin and cannot be used until this file is removed and apt-get update is rerun, then it will function properly, until it happens all over again.=20=20 someone i was talking to recently has been using the 2.4.17 xfs patches with 2.4.18pre kernels and found apt-get failed due to errors returned by msync() (which appears to be returning 1 (not -1)). msync is involved in writing these apt binary cache files.=20=20 i have also had apt function fine for some time, then all of the sudden start segfaulting, even when no operation which rewrites the cache file was run for quite some time, this seems quite consistent with the above description. i haven't reported this yet since its been so inconclusive and difficult to reproduce as to not be a very helpful bug report. --=20 Ethan Benson http://www.alaska.net/~erbenson/ --QQNwO3VdVfodZayb 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 iEYEARECAAYFAjxVWt8ACgkQJKx7GixEevx7KQCfVgUDIwTuqzRMSaTBKEIjnC8a 21QAoIanys6gl8w+5K9NMCX2CUlu0e2m =+5gE -----END PGP SIGNATURE----- --QQNwO3VdVfodZayb-- From owner-linux-xfs@oss.sgi.com Mon Jan 28 07:48:18 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0SFmIM16378 for linux-xfs-outgoing; Mon, 28 Jan 2002 07:48:18 -0800 Received: from posti.pp.htv.fi (posti.pp.htv.fi [212.90.64.50]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0SFmDP16344 for ; Mon, 28 Jan 2002 07:48:13 -0800 Received: from kitsune (cs189114.pp.htv.fi [213.243.189.114]) by posti.pp.htv.fi (8.9.3/8.9.3) with ESMTP id QAA28648 for ; Mon, 28 Jan 2002 16:52:47 +0200 (EET) Received: by kitsune (Postfix, from userid 1000) id B4796C000AE; Mon, 28 Jan 2002 16:47:58 +0200 (EET) To: linux-xfs@oss.sgi.com Subject: Re: XFS bug with ftruncate, mmap and holes. References: <3C554DF5.80701@sgi.com> <6928.1012224206@ocs3.intra.ocs.com.au> <20020128050623.N14742@plato.local.lan> From: Arto Jantunen Date: 28 Jan 2002 16:47:58 +0200 In-Reply-To: <20020128050623.N14742@plato.local.lan> Message-ID: <87r8oabkgx.fsf@welho.com> User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.1 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 1279 Lines: 28 Ethan Benson writes: > this sounds as if it could be related to a obscure problem ive been > observing in apt-get since 2.4.17 (more so with the Dec 23 cvs patch, > and less so with both split patches). > > apt-get starts segfaulting on all operations when it reads > /var/cache/apt/pkgcache.bin and cannot be used until this file is > removed and apt-get update is rerun, then it will function properly, > until it happens all over again. > > someone i was talking to recently has been using the 2.4.17 xfs > patches with 2.4.18pre kernels and found apt-get failed due to errors > returned by msync() (which appears to be returning 1 (not -1)). > msync is involved in writing these apt binary cache files. > > i have also had apt function fine for some time, then all of the > sudden start segfaulting, even when no operation which rewrites the > cache file was run for quite some time, this seems quite consistent > with the above description. i haven't reported this yet since its > been so inconclusive and difficult to reproduce as to not be a very > helpful bug report. Happens for me, too. Begun when I first updated to 2.4.17-xfs from 2.4.16-xfs. I have not reported this either, because I can't reproduce it reliably. -- Arto Jantunen From owner-linux-xfs@oss.sgi.com Mon Jan 28 09:55:34 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0SHtYv05298 for linux-xfs-outgoing; Mon, 28 Jan 2002 09:55:34 -0800 Received: from sgi.com (sgi-too.SGI.COM [204.94.211.39]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0SHtOP05262 for ; Mon, 28 Jan 2002 09:55:24 -0800 Received: from zeus-e8.americas.sgi.com (zeus-e8.americas.sgi.com [128.162.8.103]) by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id IAA00482 for ; Mon, 28 Jan 2002 08:54:09 -0800 (PST) mail_from (lord@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by zeus-e8.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id KAA185934; Mon, 28 Jan 2002 10:54:02 -0600 (CST) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id KAA85937; Mon, 28 Jan 2002 10:54:02 -0600 (CST) Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id g0SGqFX14446; Mon, 28 Jan 2002 10:52:15 -0600 Subject: Re: XFS bug with ftruncate, mmap and holes. From: Steve Lord To: Keith Owens , nnerbenson@alaska.net, viiru@debian.org Cc: linux-xfs@oss.sgi.com In-Reply-To: <6928.1012224206@ocs3.intra.ocs.com.au> References: <6928.1012224206@ocs3.intra.ocs.com.au> Content-Type: multipart/mixed; boundary="=-tFpyrYiipPYfZB5bFJ1V" X-Mailer: Evolution/1.0.1 Date: 28 Jan 2002 10:52:15 -0600 Message-Id: <1012236735.14586.149.camel@jen.americas.sgi.com> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 1661 Lines: 47 --=-tFpyrYiipPYfZB5bFJ1V Content-Type: text/plain Content-Transfer-Encoding: 7bit Can you please try the attached patch and see if it fixes your problems, it makes the test program (unmodified) function for me (the data survives unmount). I need to think harder about the code before I put this or a different version into the tree. Steve -- Steve Lord voice: +1-651-683-3511 Principal Engineer, Filesystem Software email: lord@sgi.com --=-tFpyrYiipPYfZB5bFJ1V Content-Disposition: attachment; filename=pagebuf.patch Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; 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/pagebuf/page_buf_io.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.14380-0/linux/fs/xfs/pagebuf/page_buf_io.c_1.4 Mon Jan = 28 09:34:10 2002 +++ linux/fs/xfs/pagebuf/page_buf_io.c Mon Jan 28 09:26:08 2002 @@ -1336,8 +1336,8 @@ head =3D bh; do { lock_buffer(bh); - clear_bit(BH_Delay, &bh->b_state); - if (atomic_set_buffer_clean(bh)) { + if (!test_and_clear_bit(BH_Delay, &bh->b_state) || + atomic_set_buffer_clean(bh)) { get_bh(bh); bh->b_end_io =3D end_buffer_io_sync; refile_buffer(bh); --=-tFpyrYiipPYfZB5bFJ1V-- From owner-linux-xfs@oss.sgi.com Mon Jan 28 10:00:29 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0SI0Tr06004 for linux-xfs-outgoing; Mon, 28 Jan 2002 10:00:29 -0800 Received: from UberGeek.coremetrics.com ([209.184.141.163]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0SI0LP05962 for ; Mon, 28 Jan 2002 10:00:21 -0800 Received: (from austin@localhost) by UberGeek.coremetrics.com (8.11.6/8.11.6) id g0SGxAY22171; Mon, 28 Jan 2002 10:59:10 -0600 X-Authentication-Warning: UberGeek.coremetrics.com: austin set sender to austin@coremetrics.com using -f Subject: Re: double mounting and other strangeness. From: Austin Gonyou To: pac@fortuitous.com Cc: linux-xfs@oss.sgi.com In-Reply-To: <20020127205023.A14726@bistro.marx> References: <20020127205023.A14726@bistro.marx> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-c7BYfhWUL0Bs8wabXeKj" X-Mailer: Evolution/1.0.1.99+cvs.2002.01.14.17.03 (Preview Release) Date: 28 Jan 2002 10:59:10 -0600 Message-Id: <1012237150.22013.6.camel@UberGeek> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 1850 Lines: 56 --=-c7BYfhWUL0Bs8wabXeKj Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Ahh...that's not good, but yes, it is from the same feature.=20 On Sun, 2002-01-27 at 20:50, pac@fortuitous.com wrote: > On Mon, Jan 28, 2002 at 01:56:56AM +0100, Andi Kleen wrote: > > > Is there any legitimate reason you would want to do this? I dont > > > want to scream at them if there is a good reason for it. What is the > > > opinion of the FS developers here? > >=20 > > It's for example useful for chroot. You can mount a single file system > > in multiple chroots. There is also the related feature of mount > --bind > > which allows to do the same thing for directories and files. Again > > it is useful for chroots. >=20 > Yes, but in my case, i had 2 filesystems mounted on the SAMe mount > point. > Here is an inherent ambiguity in which filesystem i am actually > write/reading > from.=20 >=20 > -Phil Carinhas > -- > .--------------------------------------------------------. > | Dr. Philip A. Carinhas | pac@fortuitous.com | > | Fortuitous Technologies Inc. | http://fortuitous.com | > | Linux Consulting & Training | Tel : 1-512-467-2154 | > `--------------------------------------------------------' --=20 Austin Gonyou Systems Architect, CCNA Coremetrics, Inc. Phone: 512-698-7250 email: austin@coremetrics.com "It is the part of a good shepherd to shear his flock, not to skin it." Latin Proverb --=-c7BYfhWUL0Bs8wabXeKj Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQA8VYNe94g6ZVmFMoIRAsW2AJ0YpW+JbnAw/62ctUBqzlZ6l60TjgCfdHP1 uUFSQkMwh3iwst9AHlsPTmc= =jkNn -----END PGP SIGNATURE----- --=-c7BYfhWUL0Bs8wabXeKj-- From owner-linux-xfs@oss.sgi.com Mon Jan 28 10:03:06 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0SI36106430 for linux-xfs-outgoing; Mon, 28 Jan 2002 10:03:06 -0800 Received: from sws5.ctd.ornl.gov (sws5.ctd.ornl.gov [160.91.20.105]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0SI32P06402 for ; Mon, 28 Jan 2002 10:03:02 -0800 Received: (qmail 18168 invoked by uid 3995); 28 Jan 2002 17:02:59 -0000 Mail-Followup-To: linux-xfs@oss.sgi.com To: linux-xfs@oss.sgi.com Subject: mkfs on large h/w RAID fails Date: 28 Jan 2002 12:02:59 -0500 In-Reply-To: Message-ID: User-Agent: Gnus/5.0808 (Gnus v5.8.8) XEmacs/21.4 (Academic Rigor) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii From: "Dave Sill" X-Delivery-Agent: TMDA/0.44 (Python 1.5.2; linux-i386) X-TMDA-Fingerprint: pqkms8nc5jrrKsoG0G345nJEhS4 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 1075 Lines: 31 I've got a terabyte RAID that I'm trying to set up as a single XFS filesystem. mkfs fails with: [root@malachite root]# mkfs.xfs -f /dev/sdb1 meta-data=/dev/sdb1 isize=256 agcount=224, agsize=1048576 blks data = bsize=4096 blocks=234870292, imaxpct=25 = sunit=0 swidth=0 blks, unwritten=0 = imaxbits=32 naming =version 2 bsize=4096 log =internal log bsize=4096 blocks=28670 realtime =none extsz=65536 blocks=0, rtextents=0 mkfs.xfs: read failed: Input/output error mkfs.xfs: data size check failed mkfs.xfs: mount initialization failed [root@malachite root]# I had no problems mkfs'ing it as e2fs, e3fs, and reiserfs. I'm running under the 1.02a installer on an Athlon: [root@malachite root]# uname -a Linux malachite 2.4.9-13SGI_XFS_1.0.2 #1 Thu Nov 15 14:28:44 CST 2001 i686 unknown [root@malachite root]# I installed the xfs programs from the RPM: xfsprogs-1.3.13-0.i386.rpm Any ideas? -Dave From owner-linux-xfs@oss.sgi.com Mon Jan 28 10:07:11 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0SI7Bq06992 for linux-xfs-outgoing; Mon, 28 Jan 2002 10:07:11 -0800 Received: from atlrel6.hp.com (atlrel6.hp.com [156.153.255.205]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0SI77P06967 for ; Mon, 28 Jan 2002 10:07:07 -0800 Received: from xatlrelay2.atl.hp.com (xatlrelay2.atl.hp.com [15.45.89.191]) by atlrel6.hp.com (Postfix) with ESMTP id 008C860074A; Mon, 28 Jan 2002 12:06:59 -0500 (EST) Received: from sa-bwmail1.esr.hp.com (sa-bwmail1.esr.hp.com [15.1.192.32]) by xatlrelay2.atl.hp.com (Postfix) with ESMTP id 666F240010C; Mon, 28 Jan 2002 12:06:59 -0500 (EST) Received: by sa-bwmail1.esr.hp.com with Internet Mail Service (5.5.2653.19) id ; Mon, 28 Jan 2002 12:04:04 -0500 Message-ID: <23D04BDBA646D411BDDD00D0B774B53904602B45@sa-bwmail1.esr.hp.com> From: "Christian, Chip" To: "'Shiv Sikand'" , linux-xfs@oss.sgi.com Cc: chmouel@mandrakesoft.com Subject: RE: Mandrake 8.1 exhibits xfs/nfs umask problem Date: Mon, 28 Jan 2002 12:03:57 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 1205 Lines: 30 This sounds like it could, maybe, possibly, be related to what I encountered some time back. Bottom line is that the permission bits of a newly created file are a logical and of the default acl of the containing directory and the bits passed to creat. Do you have a default acl set on the directory involved, and does it have the bits masked off that you see as missing? -Chip -----Original Message----- From: Shiv Sikand [mailto:sikand@matrixsemi.com] Sent: Sunday, January 27, 2002 4:14 To: linux-xfs@oss.sgi.com Cc: chmouel@mandrakesoft.com Subject: Mandrake 8.1 exhibits xfs/nfs umask problem We have observed that the Mandrake 8.1 kernel exhibits a umask problem when xfs volumes are exported with nfs. If a new directory is created via nfs on an xfs volume, the umask from the current process is not inherited. Reading the mail archive, it looks like this problem or something extremely similar was fixed in the XFS tree a long time ago. We do not observe this problem with 2.4.5-xfs-1.0.1 which has been our production kernel prior to the arrival of XFS support in Mandrake. Can someone please take a look at the xfs code in the Mandrake build and confirm the problem. Thanks, Shiv From owner-linux-xfs@oss.sgi.com Mon Jan 28 10:13:52 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0SIDqu07794 for linux-xfs-outgoing; Mon, 28 Jan 2002 10:13:52 -0800 Received: from mfive.engr.matrixsemi.com ([64.3.134.227]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0SIDkP07766 for ; Mon, 28 Jan 2002 10:13:46 -0800 Received: from matrixsemi.com (starve-2.engr.matrixsemi.com [192.168.128.56]) by mfive.engr.matrixsemi.com (Postfix) with ESMTP id 252C7B134B1 for ; Mon, 28 Jan 2002 09:13:30 -0800 (PST) Message-ID: <3C55862A.5040709@matrixsemi.com> Date: Mon, 28 Jan 2002 09:11:06 -0800 From: Shiv Sikand User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.4) Gecko/20010914 X-Accept-Language: en-us MIME-Version: 1.0 To: linux-xfs@oss.sgi.com Subject: Re: Mandrake 8.1 exhibits xfs/nfs umask problem References: <23D04BDBA646D411BDDD00D0B774B53904602B45@sa-bwmail1.esr.hp.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 1758 Lines: 54 What I discovered last night is that there is no default ACL set. When a default acl is set, everything works ok. What I am trying to understand is the change in behaviour between our original setup and the Mandrake 8.1 setup. In both setups, there is no default ACL set, yet only the systems running 8.1 exhibit the umask 022 problem when exporting an xfs file system with nfs. Newly created files do not appear to exhibit the problem - only newly created directories. Thanks, Shiv Christian, Chip wrote: >This sounds like it could, maybe, possibly, be related to what I >encountered some time back. Bottom line is that the permission >bits of a newly created file are a logical and of the default acl >of the containing directory and the bits passed to creat. Do you >have a default acl set on the directory involved, and does it have >the bits masked off that you see as missing? > > -Chip > >-----Original Message----- >From: Shiv Sikand [mailto:sikand@matrixsemi.com] >Sent: Sunday, January 27, 2002 4:14 >To: linux-xfs@oss.sgi.com >Cc: chmouel@mandrakesoft.com >Subject: Mandrake 8.1 exhibits xfs/nfs umask problem > > >We have observed that the Mandrake 8.1 kernel exhibits a umask problem when xfs volumes are exported with nfs. > >If a new directory is created via nfs on an xfs volume, the umask from the current process is not inherited. > >Reading the mail archive, it looks like this problem or something extremely similar was fixed in the XFS tree a long time ago. > >We do not observe this problem with 2.4.5-xfs-1.0.1 which has been our production kernel prior to the arrival of XFS support in Mandrake. > >Can someone please take a look at the xfs code in the Mandrake build and confirm the problem. > >Thanks, >Shiv > From owner-linux-xfs@oss.sgi.com Mon Jan 28 10:28:14 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0SISEk09941 for linux-xfs-outgoing; Mon, 28 Jan 2002 10:28:14 -0800 Received: from UberGeek.coremetrics.com ([209.184.141.163]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0SIS3P09461 for ; Mon, 28 Jan 2002 10:28:03 -0800 Received: (from austin@localhost) by UberGeek.coremetrics.com (8.11.6/8.11.6) id g0SHRMA22232; Mon, 28 Jan 2002 11:27:22 -0600 X-Authentication-Warning: UberGeek.coremetrics.com: austin set sender to austin@coremetrics.com using -f Subject: Re: mkfs on large h/w RAID fails From: Austin Gonyou To: Dave Sill Cc: linux-xfs@oss.sgi.com In-Reply-To: References: Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-l+d5SqF9qbOOGPz2tzaT" X-Mailer: Evolution/1.0.1.99+cvs.2002.01.14.17.03 (Preview Release) Date: 28 Jan 2002 11:27:22 -0600 Message-Id: <1012238842.22013.8.camel@UberGeek> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 2038 Lines: 68 --=-l+d5SqF9qbOOGPz2tzaT Content-Type: text/plain Content-Transfer-Encoding: quoted-printable can you try 2.4.14 or 2.4.17 and also upgrade to the new tools? On Mon, 2002-01-28 at 11:02, Dave Sill wrote: > I've got a terabyte RAID that I'm trying to set up as a single XFS > filesystem. mkfs fails with: >=20 > [root@malachite root]# mkfs.xfs -f /dev/sdb1 > meta-data=3D/dev/sdb1 isize=3D256 agcount=3D224, > agsize=3D1048576 blks > data =3D bsize=3D4096 blocks=3D234870292, > imaxpct=3D25 > =3D sunit=3D0 swidth=3D0 blks, unwrit= ten=3D0 > =3D imaxbits=3D32=20=20=20=20 > naming =3Dversion 2 bsize=3D4096=20=20 > log =3Dinternal log bsize=3D4096 blocks=3D28670 > realtime =3Dnone extsz=3D65536 blocks=3D0, rtextents= =3D0 > mkfs.xfs: read failed: Input/output error > mkfs.xfs: data size check failed > mkfs.xfs: mount initialization failed > [root@malachite root]#=20 >=20 > I had no problems mkfs'ing it as e2fs, e3fs, and reiserfs. >=20 > I'm running under the 1.02a installer on an Athlon: >=20 > [root@malachite root]# uname -a > Linux malachite 2.4.9-13SGI_XFS_1.0.2 #1 Thu Nov 15 14:28:44 CST 2001 > i686 unknown > [root@malachite root]#=20 >=20 > I installed the xfs programs from the RPM: >=20 > xfsprogs-1.3.13-0.i386.rpm >=20 > Any ideas? >=20 > -Dave --=20 Austin Gonyou Systems Architect, CCNA Coremetrics, Inc. Phone: 512-698-7250 email: austin@coremetrics.com "It is the part of a good shepherd to shear his flock, not to skin it." Latin Proverb --=-l+d5SqF9qbOOGPz2tzaT Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQA8VYn594g6ZVmFMoIRAoNHAKDGdpVRFy4Oicj2A6B8LNpHALznMACcD5G7 cSbcqAPjvMlcSp1g2q84t8g= =SXQ+ -----END PGP SIGNATURE----- --=-l+d5SqF9qbOOGPz2tzaT-- From owner-linux-xfs@oss.sgi.com Mon Jan 28 11:00:42 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0SJ0gc15723 for linux-xfs-outgoing; Mon, 28 Jan 2002 11:00:42 -0800 Received: from sws5.ctd.ornl.gov (sws5.ctd.ornl.gov [160.91.20.105]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0SJ0bP15693 for ; Mon, 28 Jan 2002 11:00:38 -0800 Received: (qmail 19534 invoked by uid 3995); 28 Jan 2002 18:00:33 -0000 Mail-Followup-To: linux-xfs@oss.sgi.com To: linux-xfs@oss.sgi.com Subject: Re: mkfs on large h/w RAID fails References: <1012238842.22013.8.camel@UberGeek> Date: 28 Jan 2002 13:00:33 -0500 In-Reply-To: <1012238842.22013.8.camel@UberGeek> Message-ID: User-Agent: Gnus/5.0808 (Gnus v5.8.8) XEmacs/21.4 (Academic Rigor) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii From: "Dave Sill" X-Delivery-Agent: TMDA/0.44 (Python 1.5.2; linux-i386) X-TMDA-Fingerprint: hKstYF+6f8YLjU0aYmZeUkbRrqI Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 201 Lines: 8 Austin Gonyou writes: > can you try 2.4.14 or 2.4.17 and also upgrade to the new tools? Do I need the XFS kernel to run mkfs.xfs or can I just install the new tools? -Dave From owner-linux-xfs@oss.sgi.com Mon Jan 28 11:27:01 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0SJR1U18592 for linux-xfs-outgoing; Mon, 28 Jan 2002 11:27:01 -0800 Received: from rj.sgi.com (rj.SGI.COM [204.94.215.100]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0SJQvP18558 for ; Mon, 28 Jan 2002 11:26:58 -0800 Received: from zeus-e8.americas.sgi.com (zeus-e8.americas.sgi.com [128.162.8.103]) by rj.sgi.com (8.11.4/8.11.4/linux-outbound_gateway-1.1) with ESMTP id g0SIQoY25220 for ; Mon, 28 Jan 2002 10:26:50 -0800 Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by zeus-e8.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id MAA187193; Mon, 28 Jan 2002 12:25:33 -0600 (CST) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id MAA15899; Mon, 28 Jan 2002 12:25:10 -0600 (CST) Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id g0SINNE15186; Mon, 28 Jan 2002 12:23:23 -0600 Subject: Re: mkfs on large h/w RAID fails From: Steve Lord To: Dave Sill Cc: linux-xfs@oss.sgi.com In-Reply-To: References: <1012238842.22013.8.camel@UberGeek> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/1.0.1 Date: 28 Jan 2002 12:23:23 -0600 Message-Id: <1012242203.15145.3.camel@jen.americas.sgi.com> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 432 Lines: 18 On Mon, 2002-01-28 at 12:00, Dave Sill wrote: > Austin Gonyou writes: > > > can you try 2.4.14 or 2.4.17 and also upgrade to the new tools? > > Do I need the XFS kernel to run mkfs.xfs or can I just install the new > tools? Any old kernel should do. Steve -- Steve Lord voice: +1-651-683-3511 Principal Engineer, Filesystem Software email: lord@sgi.com From owner-linux-xfs@oss.sgi.com Mon Jan 28 12:06:37 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0SK6bX27875 for linux-xfs-outgoing; Mon, 28 Jan 2002 12:06:37 -0800 Received: from chmls20.mediaone.net (chmls20.mediaone.net [24.147.1.156]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0SK5RP27718 for ; Mon, 28 Jan 2002 12:05:27 -0800 Received: from HOST (h0010b55a3e40.ne.mediaone.net [24.128.234.127]) by chmls20.mediaone.net (8.11.1/8.11.1) with SMTP id g0SJ7Ix17856 for ; Mon, 28 Jan 2002 14:07:18 -0500 (EST) Date: Mon, 28 Jan 2002 14:07:18 -0500 (EST) From: skhyberts@mediaone.net Message-Id: <200201281907.g0SJ7Ix17856@chmls20.mediaone.net> To: linux-xfs@oss.sgi.com Subject: new photos from my party! Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 41105 Lines: 670 Hello! My party... It was absolutely amazing! I have attached my web page with new photos! If you can please make color prints of my photos. Thanks! begin 666 www.myparty.yahoo.com M35J0``,````$````__\``+@`````````0``````````````````````````` M````````````````````@`````X?N@X`M`G-(;@!3,TA5&AIP$`0``BT4,4U97BP"CH`%!`.@0!!2_^V?W!&0)`<#XA;?>2;.S5P]1E>!\CY#;?OQR$3'(/$$%H2P5[#PU%MV1*V M43W4&#W^?MFUFX)J`FJS-Q;<#(U%^%`>L+;%#.I9%AC_=?C-_37L"A7\4:-H M=#Y6$G;]]NYCC;R+3?AT,]([P;`[5?QT""?[OHO/%8T$"8D-H%`]Q/E&&Q9[ MUB"E\VJ%V&$AH@`9IF6Y+=O+`/TSV\8'_VX4Q`9+LS5;#`%A!@)P`[-U#S=S M:-A5_\E0$01+LS1;=`8%909R!R=;LS1`"&=""0I;<[)T#6P+#"YK#>;O9#L^ M#@],B)T0/&+?=J@8#.(4OL@&FP'W9L]D)0!0L08O[K\-/QL-CC_ MT/?Q.<;&_S?2!9P7?'0,COUAK003*T.#QP0[+W+6]]L1-@M;%8/L(E=J9(`E M-T-C8^$`7Y_\91G!FM']2W=H`,GW`8")??C'1?0)`.Z&6[EZE"%8=5/(BS68 M#!]==VN0&FCX/%`R]`9U9,R9[OS_UB(G.1^0F\T-&>`$2YSK#C<6C&0*HY91 MB/[#>P0`&FQ9DQ]\@4`4;`??_0N[+5`4;A"+\/"-KYU?5MR24R"* MPX!EFJYSO_P$,8A%_LG-C`/P_MW)YMA`4*(SF!X::-AWLKI`45`;=`H@UH>' M,?:%?/L#?+(/6Y"47ZQ9<'//;,<%#U"]>\EL4,"I@[U\$@(/E,#U36B#P61P M$&`=>1O(KTP%G%"!G&AX2>J:!AVF%!!0EB62(>P#SJ?135Z23#$CSV%=7\5EN1P;8.\G80/$$/@D$E/%H/ASDWG&W`H7;R_8NLP>OR\N)5?0"[`C> M+E&V=SA%"83`,XB$%8OM;K\00D$?=NDA@*0/NCW^[&^]!C!\#0@Y#XYH`CV% MO^;K#"D>C0Q)28`$,,+);N:$21YJ+MS<9U]@9ZXQ-H/I`S<10IX<81\$\0$J M)3D9!='V"ME"0@UYMCI82');I2P5AZ!N4/N^BS7)&2YV2HJ$-14\]&6S\$*A M.7X@J7Q^&`NW%G8'6GZQ0-X\+C$\P=G9VRUT#U]U%$-&6CL<9I:^@7*_ZP?8 M"%[V+Y=,LO\P"G\&1_8D5_:#_P5_1-DY70C"X"#0W/,(1'4NOB.;#G9TT?\V M]X.,#GPC"VQ,QFH]X$#L"`?^[#6)7>1V;:T*'ORW3SP*68AFWHL-%DZ)!(V3=!7_2;$-!B?448-99_A& MN-W4Y3MU@I/\%[O(#^CTA5S:R_B&>0&-#!CFR0.Y@QC^20%!`=GT+;1YTT@'P#"`T@\#X>`KY!GD$3"@(==?@-+MQ@4YR".]I<"(O#=A?_ MEVW;=3#=!S\P=`=(.\)W[NL#C3YA_]-X`I?#`\H[V7,8(4`[P7*M,[U=!$BK M"(7_B\B#2-]J'VYZA*79]CL+Q?2+SW=\>0ZD&)(U1DT(=N@Y\A$KEPT%/2^[ MHB6)`S-\/5#N,!BD`Z25@R5>\V=;%9==4ZEYD2KE+W!)JQ:T\`4 M'CP@OVNF`&CG`\O4/=+9>,2'@+AW?ES0GIJ]P@UHJ(*6622A9:V"?(`5F;5* M7V34#A^2S:_-MJD+`71&%^B[F/WL<&K85U/%,RHU&]G1Q3KP*2!,"C)4XNPV M+>O0%R'EK$:`(:$B5D5J!M1<2N0Q6K9*#J34Q M+?ZQ52);MA>;4=,Y58$M2I?3""O85`RH-VJ/]0PMV0QT"WM*X3_XMW3K@\$@ M3FI@FA5&B`P00.NVS;45'BT00;VS4(3`QY-LX),_Z]8H'.5BVD>@P,M6^$)-Z<("A1`.04@Z2%\CYG^'6B$ MRI`(3LF!T#KK((>".&LP$!X<4W%E#1O;C##:;'4-"F8$G5M]_6#K4+Z&4_`$ M_.=HD8T:6@Y9!\Q3#]A41FB($[O(LI7@D33_)9@3!9PR,C(RI*B@M#,R,C*\ MN*RP7>@/6,P`5XM\)`CK/8O`<$/AGP*+3"0$5_=,]G0/BO_/.B@H&SL.=?&+ M`;K__OY^`Y=>V.#0@_`"PG$$J0`X@73KYG[WZ(M!_"8CA.1T&JFD.`ZI@''1=BVPD%(7M M="[]@\D<_U]HA!@3\J[WT4F%THOQ=$'[_B4^]A,1.\YV%7T6/74/5E52F7AG M^D>L]U,1BU,$%'O[0KLP==$ILUU;PXO_1`8!"FBX-1<$%`:0D`X(/F4H&#\) MAU1IBHG?W95=WT^+]QD4B@=&.-`BAR@0<*W^4C,"..!UQ(H.,5OJ"K>@9O\W$'1\L2^;>\==-(K"Z;_B MC4?_#(W'HY=V?P56BW2`@\\/1@RH;'_[Q78-QP8`+LC_HL.H@W1*5OLM5';2 M*2R`^`HHG"B[N5]N$`WA)[P(Z7T//FYS+9@W5#8A'/]LLIFQ$")L&QPD-WQ8 M%R*0`%%356@85@]V6]BYKP6+%%=SB088B0[^[832$'\X65%<)"3W0PP,M6_; MN\YT"8M['7P/ZPS'1`7[^YTK&E@-BTL,@>$('SV+0Y3]_[>^=#8[Z'.CQ8L[ MB\B+T2OHP>D"\Z6+RL8-VV\]`_.DBW/,$UX8*_!A_07S]@/(B0Z)$XG9ZW<[ M[W)(!\,66L>\4_81;-6ZW(NTS`Q.TO<3W+8OF/TK^NM:_6<05[_W;9/A*USQ M]W1+9P/P.\>_]C7=_W(_ZRL/O@Y344_[Q_",*VU]9> ME_1E-;8/(.T7W,'R4PP,:LH@*\6)"];>;'-X-AP:%P\6V9'LLA&0`,@O3/A; M^K$!PUF+5,U0+E!14NDM,YL)+7PL`!5G=NW3\VI`(LH4;"$-7PF$GRP8GWP3 MLEPD)4=H6>*N0GD$$(XWZ?P.:-ATP M/X]$M_4\*WFX%/3_`71NW06V!00"3B3O"XD==156!=/]MCXL5!366>W[6[@D_"OK%*@^$*@(;Z%"7;7V%6!&S5_/A^HM.ZZ8]0)IZ MP_;WV!O``T@!7\<%Z'X6=!H(L[D1`?YCT.`))V`\BP(Z`74N"OX"MS%I=NK&101`QUM;H%M"Y8$&G7KP.WPT-JWD&71X$##"T.= M=,_6[2Z5`D)$Z4$PX!,"J'F:K[5F6#-;TLK)'TALH,&`ZXQO@^P@/]?5=
$R##C:P-J]#A4LEG&!7HX!=&7SX`?00"P_\+7QK`2@8]@/0-?F8]?PO\ M?WU?^UYCJ2L+["M:>U!R[EGNLE%\H004_X29]_UHL`^J36P0B+H-"&#=R],V MBU0KP5)!##PX'!"!].=96\">'T!1?/!#A'3<[8VU!GA!#7X_N3PNK_TE_H69 M]_DTB19]#@/1!5_M]L-K&Q;%N(F(`/?I&+7PC1H)A+9J)%A!]32UJS24+V`@'+RQ0#?LK MF_A_'X/`'S5L`3U&%$@-1`+`!3@PT]B4JV6\5Q0#^_:63K@B,P+\MKP MUVP%AUE^"NQF8G-[-WT*9CL5XBIU/V9$#07@^9[+RS%,)`8-WB,I`OMIGJ?: M%0#8!Z'0!AXP3;?K9E<@Z%DF#;F_U`1"'6:#O"2Z?YB+'ALPQ(0D0)$'N`A, MC1JM>(``G?V](^!:$(D53_6)#=S;:Z_K"6^C6QB2%.3X@P=G'AP+Q!Z!XF=S MWRV2`"4$4A@/X;"!=6,:420@'QM3[J5I44!2C"3L@KC@<*L)V@+1@<0DJS]& M3Y_T&P$"_]!H$+`0?)M-K@@$2QR\:`01`&NHAX!Y!-10$;-72.(,+&\?,!N$ MD`$/,"Q\%Y%3,0%6=0Y50_PF3J;!K?CH3$>X+1TNX=*`EU/BCP MJ\$BBS7LE:[T=PF#[@0[\7(52;X(@7P?FQX4<^MH',L4WB@@WR01(.1U$54C MLP799C"`])SJB93!G_<0-\7AW09S#VLJ^?=R\72;P8Q?B=X_!"+-P&Q?)`@) M`+,>F$T;45#T4\PU#8&0T!(/#T++(;!"*`^-+%<-@1:O5+0'%P@TT0<4HW\/ M1,L)-"W&O\8/3%&M^DLA*Z.PRPYX@R\(CPN-2XT4B+_42@W&T@3NT(V$D,,? MMGWLGB8`)\'X$"5W`"^-0O\=)`$*("T?BL&AMW*#5=C!X&V#A?^#9W03B@I" M.-ETT82M47K6X(4'[0O81\/!X_0(Z%)C]8L*O^'!YC/+./BKWS(#^8/Q_^K/ M,\9Y?EN]:KOKG24&=-,OU5UX`56!YD6`W5Y?6YLJ]`U%BT+\.-A&Y^\XFLYL M\-QT)X3'YQ(5W+98NVD&U.N6+;$$_@_.2>"P) MD,C@M"14^$(%Z`^!&]3WV1O)J".6.\X0(\@.HXQK6,M]`D8$G(,/^AJ(-=H3 MG0^?C2?<`Y8=/`\;V,,7V`$6*_G2$(U6%.(8%<[HB_K?R/[AV[9AAGN#C2_( M<`/(9C.?!X4``P$#6@@+>0*0+V=".'EU#%DK-R"$Y,A8,4@Q*I)!N[)BT@$37(A,]W#ZT@8=&)Y7%(3%(^Z1R=.M[$2 MA0`9::O]N>4VZD\$6DQ90(1B9KLZ"'QM0AE+BO5-=`!@_!J^X*Q:VC5=9 M=06+?0AV&_1O!-$#QCO^=@@[^WCZ]\>_%(:1C!08;H/Y"'(I;T,;"B#4:#,Y MQ[H<*VRP4;5R3.`#5==]N%7,@#+SC7@>D`>_Z;IF_#*0!+P#X"/1B@:(![(U MM_V*1@&(1P$%`E8(6<:9*\G8QUS,W2MYEF4L)0$"`J;DZ\XFD"-&(4<_C)JF MZPY?!DP#1#PT@;^F:2PD'+]$CN3!TS1-=X_D!^CH[.Q-TS1-\/#T]/CXX-78 M-/S\C5B:Z;Y#:#?X"<#P@`.,O<+&KZ`110@]R6*=N&"S@0OY$:-]F"$A#0HK MC70Q>\D@O&=\.?Q_)`W]X[R5SF[\=P`U!^^-L#2?DT.(C_DK"#1,U_TB+)`8 M"S@#8+[N5MAM`SIO`TY83U:V)0Q[2TL?HVQ`OMON`N\"*8R0)\J6A+3W-)<<'$W3-$T8&!04$!`T3=,T M#`P("`2Z$Q;2!!\0!1CGEK#I`R@\-9>WM0MAM@2'#X,`"6%@$[C8J`&SR"`3U%P`-G*F)I#(HB!D M_'&V!FW!X=\*^#<+X2Y#H_0'1C,*:ASMWD]7OB;'1?Q3#EVL^-C-]@2<5!RC MZ!LN66RC-(NQ=ZQ,":$2//_[^.UVIQL'5KP$510.NLA\@\Q.D9?<0J)3>#,5#R%X&QL:](7X"+L MFO\^4FR[P4WP^`UA6XOE7?T@NK]@@ST\6`):87P4F*9X_;EA>("%X.^)R^?# MZC%B$C\,/@U,"H&VV4Z>40I04%*EW#O7K]';AV.>CA$!+L%&_&'6[#%P]C%M$,R$*XS5=D%HQ>6>T04JYL8E"D(1*O/?YW#N`;51!7._`/@V#$++#'9#SO#=!XQ4-(LUU2;G`HI2ML?^$^PT6KZ59/;QD0Z!`!% M2%*OI5L+M->H1E"7W M^_L*5Y5MPL2)!LG@7L,_E!_1B+FK*:QP$R@2\3OVMDMTAH],]LET$ET0S#7$ M>VNRO5ZP4(YH$2Y3O^Y2`UTX%@>`^39&J=E&?./=/YR+/BOX*WXTBU8*Q.X@ MT%)\.\!+$KLHL)AW;VF_$,((/+_Q+'P`C9X;!M&5\: M7@N$MRR`><+#[\`:@@B^%8(O\U'$7K&545'K$?V%)P$!EU`@OX66@KW(U&0GRS.,("G3$2 MFBM=CVH4\R[@C_YN$*B"#X08J$`/A<"]%`47&A6H$.+0+7"-I,C')/X&^FZL M@-P,%23O#`*I:"T!WQ1S)H'^:/!B"",+<;,'B'4-57]M=8S0'MX)5@SC]RI> M;$(++8B;88WH0F3A_TD[^XD6B4X$?AAG57*IAJZV'MCM('"(YUFZ-7U3@_W_ M3M7*P?H*X+=O5:25"P6XH.]O]D""%*WQ!"!T#/'2L3Z"7>=!/Q0\%K^R3*[P M-^OI45T>V#O?-\B^AN$*L+[2="5H;HN]J@T:7QL)999>P\K1O."7&C8L%1S; M.\%!5Z:1`484C3R-;^BB(^8#0(EGBDP6!!I]"PNM`4QA+YR> M=`ZZX$+U.]W>`R#[&DTJ,U&'7,,J%9KD6-%54`>N/.#/UN>`0%&L)#0$K(C? M*$=/18O]#X:#VL;_1X\HB\\KS3O+MU[H!WRNQRO%6W*!48Y'#8^Y]FV?Q2SK]8TYE05U M':,9*5L2+#MR[+@6%5IC`WP1YSC-0L(OT!.`?0`:(TYECB5#\0PK+1K8PG(O M:126(=:5.ROQB:-E++@BT_#5$$)55SB$5TK6B_(%[FEU84\W,!"%/X6AQ(Y( M7Q&*`?S76[_I4E4]>,<\870=/'*-/%RK0>!W=`UU*+U/NA:-^`L,&Q#KOK65MQ1%$'4-"0H= M=00,0"=KB@XD]BI!KX50T#W&%Q1,%11HI#A1K9J!(S)MG%D]^]3;\+!]_J%T M%D"C!3`"#S<&B7@,H$`KQQWA;(NC#`@&'&]($--UAC9]]SUP[$T#0$W3-$U: M"AXO%&S8$%8P\0`!#R\[(4\"`P0%!@L'">#`"3P('S5).+#$3YS)._5^S16= M(=R7%U:+`CL9A%@,QT;H?P)_.\Y\[>LSN3R(ZREJ((TT`]Y9Q*!U#1BT;J!] MM@0Q0(LT,DV6_CO];5"V-UV);P0"#$0O!")THP1G1Q!@L1=8%JW_JM4`LC9X M)\T'`@O'`I/`UK;5U[(^O- M^P[I$U=!H_6`2^J`EE*E@:VT`ZCC(.#B2]/+TH`_"G$$)/N(`0>-I;J^`X[W M>S`]X]U"&`WU:HH'/!H./`W[C;N^+H@&1D>.,K5-67,;@'\!/=N^EV`+2<8& M"A6T!PT?=A4>!.H0\A!5;-%0!>-6,)Y2$RC9"^@+4D??7+;@0->+Z`M8TYU0 M@U+!?0'VI3?Z:_WO;JX\GW7K.EJ+"4:(1`L%ZR\[=5O[5NMU#(!\'1P%>^LQ MN!5\%B#E_U+-`-[-=3?%60W MM)<+0(U^^CU$P`1V'P0Z<+5KZ"3_U[\']%:`R&<9$.(8 MP'O@B8S/O_U;]]JIM[NA!LOV"0-]D.7LH=02)]3K&\=%;^O7B@B5$HE-?"T( M'_C?RXM5*HV&=8U-&(V5F'M%%%$'6^V)=1`B.%6OO](O1>D%R/,/G<)*@^,= MB[_T(]=*SE'XB7G\/4?CN?3^EL$\"-;SJXM%$`6G[H"V:(2&N>.P_XWBA0RU M>.3IB(;X\-CO!^D0@<;.@<(G\G+?FB*WC<_#WH#JET`XG'!6W'1J5318-44' M-'M=7[-3P08]_4!LKMOP.37PZQT)BWH-"E'^"^!JC2#JD(:)T`#<`H8."WK! MQ0&&SI5!OW@PZ\"+C@]%!3Z8U2N#?Z/M#9MBJ$*W$*V[`/`_6>YA@;\^Z'5' MB\)H"0/+"/PQ<^"(:2W'!ML!+;;C%4AY2HD&+'&C$M0K!!4I=PSJ]UWT[D5K M%'0-@>L]@^Y;P8T7/7VDBP=_!",N2QVC\(-Z&/_K:HU*'SE[)QAN#`M`BX'P M!NP;,Q>@4NXT_*]T5X:!VQ$OCT)^6-LE'C[VN`L[8G8%!!0+/$+I<@N+G!PZ MZ^O##U`-6_%U,XO160^C^KNYI]JWJ#3!6K] MD`$(.%K`0TL?$U:JK56WUF$?,W3(C`-DX!=P%&X1`_*),(%DP6&BW/Q9/?D% M[^UP&J$5TO@@HP@RP#2UV1"T-0\\P*$5M\]!#"_B)J#DBT$0[\+=6\N%`'G6 MJ1@@"/<:3U.@9>961`1E=!7OMM1I;&Q_4)H:,[ MR)T_%MOP=#)J-88%E"L(#<6B7$\_EK1;LTY34-B M;1&+;<5#6Y`;[>#TXS]:"`S?;OB1*_UH6;:%BPCO\O_G_H6W@`6'T6O^$'WA M;WV[Q%`(:0A&#W3PB\90P>`,-AO=&:-7-B"H1#O'$;2')1K+0%1(*/%2\&G) M!\I^,A7]0RM1X5;:IHE0_,:`O!%^?Y/_QP$/QT'#!4MH'7YWC4YUU3V-A7]? M-]<<3P)S#JV_'@MR]%RWEV@#]B/!B;2(7UXMU?878`HKRXD*BV(K51\PX?&M M$0B)#XV'=0([N/$@-ENQFVTL7A&#P$ MC8$]A3%"++=9/^<(3H_&TTIXXMT1P&V;23=%R1_`H!10J2M<$$(3+W"77:`MC7T@#@` MW_`:%D#;2\0;97-UB@90/(!^E(W^N\'I1@&YOQ5`02?Y.\IS.6BIX2(#,;J) M<5=;55ATS=#9.]H!VSLL$\*(E>P'X%_A]IH#4RP6&:$[Z'*JW7>7),<1:D MMDS/'+W`;T,0M@2V+Q$/(B"T6X@@%(!9#X"449,W7X8O&3Z>$(-?B]4KUXK0 MC=;P','Z##`@+P?1&*/_0"Q'%Y'R._-V&XB'(O#!>`$K\VL#QHD!!MLC;\=A MCVPK?C-51YDK\!O*#]$=NF^HEKC(\2OWJ`-'$%VQG2U% M.Q?3,>*`QD+G'XL$K-"@Z$*%W\3'.\%S#^22`48_`[R&M?4RKMD+T#FLL%$7 MQFUX]@[QT50]UGQ%PFM+/0/V/21K`6%?1<**FW2+^Y)1M:]HHY4/;:X$R9*J M],KV:KAN5'$I.QE]0+I+/Q&+0L@,!I8+O7XI6A3`('1$ZT%"5<+-3GA!/;I* MD`-^8G<7.`!KO$,@M[X6K6.U=QN;%G$K5?(7!`1T4('3'R(YN,Z#V`#<'.N= M,-!?#U[;FTK"1D834'B%ZI:D*D"PRAE21H:&D%V1/2/:`2,/4U:X"*#)`'*- M`!P56')9KS)K4)0$KG@9K`O`0&47[L%6E%'X.$@B"PMX013J-Q4+JQ!'\(I, M,`$O0!.!,);]B`@()-#)/G::96.LV*\(`ABO1D5JDI->1E.K:W#XH-#>R3P] M;#7(\A&:"$8/)2L!6TE.9!@\S1L+36Z4T2O55!B,7/*<^^?XQ:,))Y-"5)S' M9_EPP"B."$8\1GB>P$85V-"4P\;##*0EC3R:RWS(":T#_?-F?2P>W0B&CH`& MHE%!D=@[D$#X2EHN+(%3.@C<0V3$1**A#F\>PS<`V],7+&\)&0*\+L+E5#M MB8"*'T>$VXAX`_#$7Q[6P^$P1"@BY^J0;RA!V`\#X>]/*9K:+=? M7%@6GD0#-"-3')HH)*X9UENX7=T++")(%E-CX#?W]U4S(!BT!NV7VNVP MCQA-TXVB>4K07)9+>"8`MRZ!!F6'G)R\J!#$7J,E^#\V=2"I-/H902A%":VY MR3?"NV0DGSRAX/*`+-7*C=)40)<`T5`!N<(L-+P"8,".QA'">MI);!:HX!98 ML$=)(B`)+2&79B"$9R>796S/O367!#"]>)"16>RI,`A$0-AU@S3W`Q`0=#F< MO`UZU'%D8'L6W%1=7^AA[7TN?.]U*'_KVQI>\ORB\8?>YV*TY%1$`Q#9/HUB:IRB^D:KGI(V>/ZOI!(V"$#QNFP")]S.07#D%NI"J]'N]HZE-$- M_+.\"Q08]M9.A=*30=!F<&RAH8-^"F8"&77P.8L5+E#1^")\.?BS#W4#,0VO M"$`N!B/AE?,L$A/PVD6QA4L59JL+LQ:'9V;$UWL@QL9^V>>$,O6E0F:?[YHB0WKL.`.2/BZ M\E!(0**AE>E0@W/+9)?C@ZZ%6.K(W:WP4+P+)12!YH#8A9S9=FSV#K%<41W4 MR;(LS?9J%O944LPS9WP+;5PM=1.W`;9"!$/D7_;."=K-Q"W#5ME`#5>.,8/(C!U!2[H@,%1@?2(9B>' MO1,CZQLI"`N9M@U'L=?+W\:?"N^55U@'7F"/`D`&1; MJO\C5W1LM-=_!HO."\_A&[M"P_8PF9A255=6]/%WQZYHAW,\5%B+V!*#PS!I M^[MTQ7+[.71^!`-<.#@3?(C?=H@8!NNK%?$0?VR-K&,KZ$#VQ0(=$OU=-KK] M,'69[4A%$,8`,!U<4]0Y-$(.K&3[8:'VZRK)<@>C+>L6$/>\/%@+*^L*`G0- M(,?LJ!.B"BC\*_H$&MA:/QT,C;0R`K:`Y410*2`W,V$61DG>&2V80/>!4%%6 M(RI2B^9RA71X=@0.NB';;!$=.S"C+'>DJ"FWEHB.CGAW+.V@MEW_GP;42%!2 M`1%H!?P@#`0$?H!^(KFV75LDZVE4:.U+&\:6L"UF[&48*K%E$2P"+R=(]1$] MA=[WC!PXO3O0BUYPAQQ25E4MU`:39^MZ47]0:99-LP.)\CQ118K3=,VV6E(3 MQ=0#MJ>??0=-XQH;``4%`04``@4#:[I+;00$-?^W,SNH!S>1#;9*4B<$``$. M/=M]20(#D'@W1U0#7%/M.G.YCU!5\U(#*@M25'1=TYP'!HQ(`VXG/B_[9M=: M`P!7$`$0`A```Q!W>9`W!!`%$`8'"!`)"F#`\O8*"PP$#1`.#[]LC49T"*NF M`W@3M%]MLA$.B`(',P+UJ_A"B1'K+%%0E=K#7UUUH@R)`60,)FH2A(3@"V`` M7E@23?97?B6TQ(:+3`_]0E-M`M6(KR+^2`3V@+?-) M;0;(A9S=05!&0P?C:+#%:L^FP;3)0K:+'$#\GA\VL@V:"$&;42`_J'!E$V9` MH4U`O;^^5PN.O/\%#J,;@H'_!O9HR'UMJ'>`FHDU4`=3J.Q`D"T"A0F8T16M M`[95WNZ"W":HPU]H6"IQMDO#(5Y7`A.A[%C<+3:L!3/_OCH$0%0#\2_$L,'@ M`F8Y/9X;VPTZ(A-T4!1)`I+XIHMM&9`/&_)T(J$`"$0+T:81=!F9-=3:D'.G M1.[!X8;4WL)'E.O./18%`?/N1V`5D#QJ0&A%5]K*29J`X6D8J0H52-GO[=$+`VF0'1"(SR[(SP`0`+2O;LA70NBD'`S#N.$6S=_,Z M=6-%,Z79EAUV9SF!-C(,D+';K0@*`44+??0W*Z2P`Y7R,%J:O4"M"/?9'A1% M88L.AM2]#161\"0/V_Y5M73&0`,S9D^8E;'&`0W/=Z(V?3E6:W4%&_5`*7JT M)J1%%34\;E,,.[M?IZ-UU>/">'Y<#5X*I89Y@SWP":V-I,)L/Z#)9B#^R"*V MQ]@/^D,?^(PHR6:M'?1PIS._[FHFTB@5]B_R&VN7B%$TZTD,5=(&O9(MVQ:3RRRG%.AJ%M;K,(X1]R;;&!,4!BU84'S:`,NH)FM4<-HH/'B_9:6D9UJ MP3L-L!'L"7@!E`^*'M#8W!_@()@L(& M)9PO&(-:4[XD_C,7^C=%*>@[UGT/P>4#=ROJP,F^Q0/N5BGYZPL.`\T[@!<= M^4`^+(N_XK_;OO!R!@Q3M-J7`R"8#(V3HGV?8@OX#)6- M`Q<]VC)5&:#'1RFNUJ'4&32:@'(LZ\:Z45L=F`F*&3@3)+3@!0W/3P81"K31 MF$O&E2VY+$:L0-<+^\`5K`/"2`3!#3VS_%VP?7T5!?];)@6H$?;>6IQ;/6D4 M?`HM&Q6((#$+(H)16@J>RE89"^:%_Y?B#X"X>2T#$5?WZ<'Z%]'M_I.H5?@#B)5&P;[_1_>`,^$!?"R!Z0=`#IYM>9(=`(7B"0CIZWT#1ZJVHR2X MN`=%+L*MZ`BM6U!Y`\$^BMS="]+!ZA_7T*,L(-L/2MUE*]#;UA32#`?`$4S5 M`\KWGXMOM*XHL5IW/D3N[\7M1BV3;K8$0@]\]5N[5;U#E_Q*<14@06<<&`O' M-HLS:5WW\M8B"I19MLT07]&.0F/E'P1$GCF+,EO[N,6SHI'W/"C\J&91FRH+ MP%KCS78/&!AITO#Q;8TG;D'.(`4;%`B:%HW=HE(\N!"^`EXXC$3?#0K#7R1B MX;+)72CK;(4$^T:,O4).:@/Q^XHFC['&/(\Q;AC7ES2]8O&!/:JWJ@8A?@%& MDZ5<=;%AVUXLR+QMH2WU#,.-0P#1USL"#-1>=86*0SE$P(-;Q\'0M]%.0E1( M#9"J`NTE3$\?_J[BFS[*?&"L`H"!5?!B\-"F4)=T'^@@'*J&8`N.%V)1"WA\ M,HQT!@,M?+LCA:$&)!OP)')11T)/5+G!NUL&M2:XN#,[$'1%>/NW+U-!/2#N M#'+Q@_H3U-9BW806W%PI<<3OR6W)V*]8$C2@%M^IU$<=. M.PQ*+[LF&B\NI!,]CL"+\9V[`VY=N8-_4CV0#PV!)S\G/T0]D80V/9.%)S\G M/R@]C8(:/8^&Q#X^/PP]D@NY,XEG5\C4&S<(_].BX0T7;+#8B;_04>T?!29* MV`09I9OP2K2!3)0.K[XJ/"<^PUT%>?E"[X\6_8W;7,$.1!U M]101=`*@PH55H%$J)<)%F.92;T5;1(N$9TH]@2\KP-01BD0*S;2Q5&U4`\_C MHK74)=JX8I4'>?K5IVA;D2\ M20JC!0Z:`#CBXD&B"@H1+X\(45,-&YUH.&9JT%"9S05U_CWC-""@YRKU%X`G MQ`E(T(F3=@CWNX<(]^!77%V;>9)T`^$,@E$+QPC]6`?E-E-20Q2.4%)6:A;. M@C\[2#0(7[Q(U#4=!5Z,\H"'"@)C-'P\JMB&T<<'R=>$^T,3.[N#=`F)=?N_ M1.$-I8`X(G7`@EUO#EYD8M="59:1O]^-=-1,]5@M0-3!6/;]RT%*0-P M\1?K5D\$[+KAW?^/C@-=JDN`^Z-KJ_AVVXI8N$$.=/:L)?>-]P=Q=1[.>`$B M2M#M:J:`[%2\UAZ M=2>!!N5L]FL:)/\'''(`KT7H"BS00<,=&@"S`+A&:<0`;D?[I+:+"%LZ$*%` M2B`3CAT0+6"E]Q`C1+M)/3Q/)6@P`"*WD!'$YH&-AMA$%[@"9@$'[\$\+AJ7 MJR40'9P,Z1\JP(6H/OET$MUO?-@.%W7W".XKQNG1^$#:>FP%X>CT&VH;T:M& M*"0GV3[2A^B,5_+8NW0O&:D)!C93)H%3BYZM$`WL/%S#)"!8+.,-ZEM0$\!H M:&4('@WM9[YT7(H+)XP0E\`-FMP'=?BLPT!L?[Y#+4W&A3$BX>",X"44H5Q3# MX@>L@7KN=0\L;!32N`FSL(&P7SDH5?,[MY%H?C!"/:#O[955?V@B:T0S"(6Q MN1.O\AW=L+](FO.KJID0`79QBMU=6]46?S-WG^"%^ZO`[A^+]=HPBD[=NTFZ`=H(PAO+_BPD-/UBD9J MT]!'@W8%O-#%"%$$ MQL"CQ_"EX5Z!)>_FT0`+(&9N:OC^#C+(A8WP)7"J_11L+',+Q?R*F!,9UJ`. M1L\%7*X@[9X=]1)W)[1<;4@&N!%Q]MT%`[@$"`42"P0T73="]RT>,P,Y/P=D MK-A%;9\!`@,[&$+&D%\$Q.8L+ M`:W@C:!\SFJ@HV;+1KORQ4BK2[R'VN8+!'@$8A/=1*X(8V8L#WS7$-D"7A`0 MWA!&R]P;]FF^Y%ZJRP318G9)'R3=Q3NV)HD*C8@BT!S&0+;2,M*=`%@6>YG" M$QV@1\)RY-G7WNR;*W0K?*CK"DB#&L$#]78(2=[>BNZ`@S2*!XDNJ`@(Q4:U MM@=X20,K*O`?B]8?#+T`+P3UB13!Q(H/B('J^!IT14:F!`05^EI@MZ%DB-M/ MH?74CR@$VHTTVJ14TD/0SMVH@1BX]J:$PT@8`MGKD&Y4W'0BM4CAC:I1 M)4\RZ(IH%-,5;U0+0:C^J5VI'P(F4B]!!`9K<`HH#>PHD6"]P6O[(+&P;H"Z3="CY=B^SN'!;,F>(2!=\ MLZ-U$NW?]HB2+;-]8(+_5`B3&Z/ZZ\-DCP75#(P41;R_0F2@#X%Y!&CW%KZT M9E'L4@PY490%FXH(5C!P4;NH640(]DO;5KQA2P)#^6L,65O"9SQ#[O_,S%9# M,C!80S`P]^KZ!6+O:O$S10CW0.2$T4P4AX)@&N%E:ZU!]P@^(7.B-E/?>PC! M83"QC]#=VM^+1595C6L0J`M=7D$+S!+5O9LS>#PE4U]?VQD:ZQU6#.ZY-FH! MWG7;PF2/_8]5##L(D_C]SC`:BS2/ZZ&XV^LH;'PAT"_-%/>86WLU(\#L,[1LJFB9P)IU; M&LM.#70-NKV2Z1`]UWD+;P'%2+FGI+0,75!:?'CR"5`6N>>^I(Y@+Q'9(KR= M9J6D"[V*':GKC9P+'QVK92^./'8M&S)J`_=OJPJ#E[@2Z3MHH$E\.PYT`]E3 M1#VY!EZ$=J\5XN=,73F+^U;M%8-FHCY!G<6NOA+Z5,M/'\NB$.WB&")H$`>Y MWL7A]. M]>L&@<.A*FC`-!FH/Q"3](AME5DT9*D47$"``KU")(TL!M5J444T2#Y<%@7_ M>@2\T]!.*_#8($8`8$2)VYUH=P;J M`SAU!M."0[$U$V!B(_M<2A:C1O>1[#V>`]FV)GX1`?X#F-Q00)D445,KNF&N M5Q?52RLU+!>V`G,OBAK)&E`#RD(6'M&C_X6BI=`8.LMR!#K*=FFBA'5D:@(\ MI.(V"^2PA@9;3@$UJ(>3(1H/BN9+V"2#41??.>D&P%8)"%B+3M%V83]J"<[7 M1>!1&\G,J"T>D2L$D6,2Z08]W)+,'E50H5:Y:7`%N#DGDD#@J\FO/%!14EY) M)MV`W>\V4$:\%,69&'B@?K+H7JU$9 M/E%2)A8,*S%KFI\J3H`"/!@7NRJ:^*VU/5?'>^*K9WG<",J8[_X'T04Z8)!* M5H0-%*H05#C/5(5OH5Q@S)8G#L$8U/">:*,1"G=43P:!XG0;-!)T6`KP@D?; M+Y=)]S`B$VH$014L1J=I%AU(0SG(@!UU'248]P#HUNHE..3H*\?7P[XG"QB3 M?,F,W]XY$M#`.TS6N(3&P"#<1$F-/+,Q!Z$7XI_8$XO'BU`$!8D71EV%V"A` MDB;OF%AWFIH`4W%X)P6I3M9@ASWK9T9!49*]`P'"3B0SW26^=9_C MZGT"]]X6M0BO4;'1=B#0)K`9L`!CL4<Z4E:MU@R* MV%?WJA"U$;>H!`0XQR&%SD%W>!V+1G<6VG@H5*!G/"O&BH5S#>^CTA40D<(2 M$*@U=]DC7Q$0)F#C,1`QBQ+)@GY[K33L+1=6A=)3"PP7VK1TV!!!D4$D12M@ M]C(O>X0>U$1K]N%"#QRUZC-O9QXA&9Z7I(;);7B7X*VI?#X/-__AT MM_'!_[DML^`!.T2-D$RTX&?G+K5][$4U5/,786[E]@7P/@E56_[.#D5OG4AMQ()%F;N%@Q0F0H%]>L$G!%V6$C] M,$F@JG6U+)__'IRP03#GFYV:5\(N=,,$_7W"=#``P]T5%L)03S_LT#1R"3K6 M#(W1+BG@!DXG4,PHJ`:0(!426$9`RIM_K\)5`[__M>"=?HD*W!1]"K@4X1JJ MFET%.@!ZW*.]=GODM-43:A1*'6^DC^PF'@]J&D:A#[$??1!ON;;K!1!T0#3@ MB0P0)W3Y!'?;1.M\ZIZZ6![&&F";!=D&\?@$]]OA!CL&QP*'-"!`@?JX+,3= MD&A\T2-J*9R@Y*XN%[!*!8][?,,K>@`,:=W4I`?`;DZ]$1SIOE*)0<4,=!EJ M:Q5;R0A1"MH#&!T%>4%((IPWR"0$Q#K#1C^]H7W MT0[GQ8!U%01`=0R!/:C;!1?EQN`;"%0:BT:+AH+!^L;WRQ^<6^@12'+MK#F8 MP.L`!GFP$@E`ZPB``'^K91L0\_@P#X?!`KC;SE]'F""!6D`.ZQ.[AX[1!P$, MNW8%NS"O#3)1Z.(]1>\-V])_$C0[;SQK<.V]!"0_-FJV51@#%;`]1'1`6K,\ M9QL".044V+[-]J*6H4N]`QH>/)NA6`;A&` M".L+V$6]UPP7#$UI;"$G/=5QU!Z&&*1H2#$+1QPR013H*$&'@VR(%C!3DM@A M&=A#B"**"\\U,6- M/XH=6Q%M5I4\`+Y4G*0&=2I],!IU(SNY0337ZGOL%$%1I!8VZQ!T*2P(0R79 M*+H%WU9F%JX(]0N-K:A`*U-`5V]&K8#)O8LGVTJ(WHDUKSH:/[%INHU^T$,# M2E'Q@#)D4Q9C`0\"A)"B0P.0[Y:BI1:^\E;QM`H#.4`\;SA2="CDUQQ0%1F@ MA7L,0BV!QH`%%7.?1CGJ0/YQHXIV$544+ MEPT]%S$R;(R8;!`R.@P<6@*#PVR"/9,*DL4?[Y]X8.&!B-_)K68^9E"LVA>_ M_P!W1%/^)@!'T*9<6$,=KLAL*)BY*QA6X2HV:""N*;G2L&A_ED9E<-8$I`V# M*OSM0G1V]'J MT=@+J/3W\]5DOO`$&7*(]XK1<@X[4+2[[R=W"'('.RMV`4Y,=QA!+Z];PA"C M4RKN\&:S;E!N-P7V#F.WP@OK4&X0115N!NLV0\@4D000:PPZ`Y%I#@^[&X`V MT[E,!PB]VE&]@5UXV@!\?VU1'YZ+@SU0`7Z3:JUE.FX8!U`I?<5ZU`8YHA4" MR0_:GRJP0TK[EP-'Z\\G%13ZVB5'T2W?P/9*-/PKT2,2\O*#F44IVY*PW6'7Q;BAH^&5[5Z5E--=+49 M0!M6Q@-"<$;0C5R+R^LA*7O6Q-N(BTET)9(I'W7K+;M9X5\=48/C`_$@'2]+ M%\2IPW7STTKY9Y:>@PTZ+HH1VN9.NCKN;!@N^BI.09&"6+=!1@K:8Z^Z!D>6 MY>06@\;>+!YT#!"W!3)?QCGK&$6DZ6)<"0X`$K1"S*A32%6&PK#=[XD'7W7X ML'6%HY\>$"R@G_,%:&8+^_\O-\H2S(`&D@=;(S9@DB\W*88%EBA+DS8<.7F, MT5:0"0ME`M;JI0:`3E'^9I8U!&'VS81`.\5RVTBTL+DH!7490W8U%Z(!WLIW M3.A2G2HF9';_;4B3VE<:9%Q,?[>(LRIP$&R%'FU,./]#"&JZA`L?2$2M.,O8 M'*%&5%+P>&<+8D<2)/<^4+DM81%1]HU&8((W"7@0,\!L@Q7]>@ZX229K"1M: M"A`/K`MVIR12R&JBAP"BPO\A=7^-%#`[U7<>@K_Q!ZT. MH15K4Q'0#(H#3%NKUP)3HQ]0WY:#`S!XU8*XR(%C"/XPI+(/;R(D0 M+"O`:2Y$TCV>V%I25LFQLU*)4%=1,"*@W2GH=2*MRAE56M66I&2`SWUF!=H0 M4`>#"83M=#Q-+TPE5IL,,,)#&PP4'8*X*1X8QIC&9@^V,(+VYFA99K,$I6RI MV(H_'HI*`4+909$Y^+?9&M4("\$[\'0R%=>Z7?4M_SQT*D1"*T;ZVZ1B=;N^ M(P^5P4DCRE6X1[40$03?-YDK[@4>7A];(,/4<0D17U?+/V1`CVBWP($D6M9@ M)QFFG&@2/8O'H,KW+(AEH*\/K^-TM*\@QA%:;<:MP^>RY@6^BQVR2FS5CW<> M=T([-4AW*"CHI6".!\HJ=@C-8T"WSE&+Z>"KB\VJ-4@139LMG`@A=*6BK!\1 M&ZI%'P>=24&"2+0%+%P/L=)B#C4-C;-[F$OHEOS;[@$\A"Q(G8P?MPY M2`5W6U,,$54S[2M1,P+`/G?+X3XZ`<"<=\J2(IVSNH&N`553`?C/9J)4P,D: M$0(/6Y(ZIA3\7(R@!>`:]E]O`9J(CJ>.:+G71&"H@DG;X(-?X7A+-GY"'`<-]/YF'@DN(4P^\7ECVU?;WW1OM`TWB%5\I[!`SOAM9 MV`1:4B(M%_-`,2%_8"8"#X(S$%'L[1R$/L$!*W<5KQVE*A@ M/TG;D7\,N5>O61@#6Z!H(!1M(Y%>;EE_^U6`&&8Z=0DNQJ!U]/?A@U,%'@A& M2[./P@,)$-.>\8`%0\SO5G-@GVX7&.!4!G1$^(K!UPD3:D+ M+02%`1=S["O7Q$*%K6T,B\OE0/VP\@G"]%&AL$?%-")(M>.FD\=U(X424'0@ M)A5\5__61HXZJ4Z6L`4J_7"B7G0O!7'I!G`1#8Y27H\^U2R:(-8N$X<`(-5F M>BA#-M\-*O3%B2Z65Z8:Y!*&M=Y8(DNI3J?88P(^?#%<"7AQ=#K1$YLC'7S- M)W0E3R105',7@E?*M"'&/MD'+2&5@,!7%!M6;1@G$E$X.W'V>#'^2>;I@)9$ MT#U%&1/((3(?B)&@UWTCGY"8D1P'L!/<`[P``V@`D1^(D19"#H"(D3\T3=<- M?P9L`V1<5`R@3=-,1#R1'_>-$`()P/"@`X`,H$VLP)$?CY"''""3T)(HDJ!= M]SLLD#@+6`.`DA#(*PP?(),W6"CD()-;U']-TS1=W`/D[/3\!`@P@'8>%Y,? M-EUW0A\P!3@#2%R3:RHP@!__[Y$&1E3Q3[]:2Z=34$V-_UAX"):*V@N_.[#_ M8[DN"_Q_"0J*)TBM0A(.9DP0]NYX'[QGTL03$6/.0!4PNA0%AG+5RT M7`%!9S<5,*,S!MW#>K`5@W3=2A"X$73@DG3=$F7=$:JQSX0#'%"L4L"RIGL& M4-*%'&@=B%/U^>`2_041VX$[225!H;A2'M"="WJP(4U)(A."V`P+ M:GP'9+"S!Z`E'L`5N`3<"14&PP]+:FD(W%9W(!<*'(+V[%I9IT4'.,1P+0.& M@(,>M4[30M">@K]1+5\=F#,(2-(V+%@`LQ0T(&T,&FU%)$PY++/)!C&`MTQ5 MQQJ8BO2D/HT4!`L8P#]2.19S`2T>5]],,CQ@]@6][V40/)B=52)1VYWA?>A) M$/?%W71)LQ21[>VJ)`"/MS>[)`#N$KI2-5`1FQN%0?=B;N&"49/ELH"WH`PV M4:P@A#5%H6H$=59*W,60D<&:1%`,H&Y9=4((8X<4\';25[&-2O]B^<`MN(9)9/,, M4BO*@`#;&IG",@``KD6;H?]!-A0#_?+V?0`&`@$'$``#!@(0!$7^5^JS``4U M,%,@("@X4%@'N];]K9(W,#!74``@'%0<+_7.N M`!H!#@`H`&X,`"?TQ[IL`2EK*&YU;&PI$%-_\___=6Y-;VY4=6579614:'5& M0IS=&0UVUK[[7!U M%PO6`;)?,3GW M;W!E8-ONYE@QZ[/4QI8K1R>2<*+18`9]O# M10XA$5#4.KDV[-;*+@``/.7@)?QE];8L:VQW;CY(1V5T3&&Q"W=L.D$*=F50 MMG5P$_^M;6 M[`WL;$`0!P8`@4K@MT]T`1>;$B9SVY`"7^`GY,K.+@#_%"=`E(W-#A#3(Q8G MV_]_R,`A#`D""+6'`2N?)C1^Y"4M0RWB\H82#"@``";!PX`=`2\%,.@B0I8H M_Q]`M$`X?3!0:!@+[=_:__]"H_@D(05(V&O1$`YT#FH0:/!_J?Z$%PK_]E_W MO(PUH1M>PVH!6`3_%Z(&^=J-V[:UVT44!1!0IP+^[4X%#'$FT+M]_Y+"CB:%PC M(,U]M_)%R6A82E#G\F^VSIEX-Q\45\SHOO___V__N+N%AO\E&D3\#KN($YW" M]\\N-^BG%@-3Z_(Y7_C__SUC5SEW^X>U0TAJ`^L$5U>F:$@1+R\V5?#GP?__ M__`[]P^$:`*]X$+[[KN_0*](55"#%'J+'60?_[^P0#33ELXBN*Y5&53'@8X4 MR\_____VMOLL5_)62_3H.^\OQ@ZM,QDDP!3<5>5R.Q==_.#_"_\B'?(!BUPS M=%A4D"WX%(E!`^_=[:;B_W^I8]5)U8L,,_:`H#C?N_]M2(`&____C;*^0/\A M*`^.%T#&_]_^_6ICF5V-CAOW_3+_-Z+^5!_____W2`I#13$>_LZ0Y6'$@XW1CV?WNW M;:M925%KC7X!Z08#[?___T6+[BOOCO;K&C!)AT.+O-\0,-Z[V%!72T.`9/K_ M____*QPA4W;WZVF`('4Q-E2%W(P<(#(<=2R#O&S#4$\\4#/_____+#,;C`A;C0=MKUI"'!IP.CN(O[_`QM9-U#O=@&;1B`PHQ1%(%W)/0O_MR@W M4WQ;1C08M`ON2``YCT3\_Q!.S_RC^MU6:(":`XL9P&VCV?___\9X5HWX5V96 M`JQD.F"LZ\BT<=9;XS/:3I5]#/__QO]9':;_A6=O^WXL.E_RM,`;@%D(](4# M^UE]#____^UHL!(=]WS96_WL+[?."&\$N!S,ZXR-A>1V;ZZQ^!>"^)G_O00M MAD,`J=D-[5___YN`:^AU!Z;V!\"WT`MEKW<;\ MC/+=QUKD)^/]"-LI#+[H50R*C#T17(7___]\H?U8!H@,$T.#8Q4C@#@J'VO[ M+0JI,4O^G$L%-/Y)3?2+36;9\\,'__^-_^QTIB(LAC?;;I_L@V4T*_A%!:QF M&.\P2OO"_____ST,P@/V";,6DHOX62:&S98-=[#D5U8.!"!6$L+L6ZMN^___ M__Y<]%8#P4K0`F^W[C_\1BLI`]@7\$@Y)MW;;^!]6__"!D`I+,OJ1SM]]/PR M@O]?^MR5&V?"KCT3W;8X%,I!L=I![CQ^9FP-^^^\?_K M<6C(%/-<:,29D)\`1VC`]@?Y,FB\______@=:+BPG?"9]0A6;UG^P_WH%G@: MB^0-OZZ]_'6!"-PN__]+!#/2EXO8HYVLM,)7B`]J9!'C`K\0_/\'N@?F:.`J M:KT_MO%9^S0+&QE7Z_C_E_[E^M`;?QU_GT%U*:'<0ML%!3@=,/"6>___%R!O M+(6X!F>)+2AG-_S;0\8%%`'K_?___R)310;*64!3VMKL8#]T"Q8)PN5N@W1P M?M8,:M`U&/]_@2^%LQER>Q?6K:;KV*TD6ZZ)7&J;QF]0_?^>C5N`K!.)P(O% M1-@N\,8\9$S^____A=1!O#A;*POQ!$LIA`=).'&[W#>*Z<0#0AA%#8D=Q?__ M_[=\8V]]U4K30S___^%@&BU'"CF>QT$S1PX#^"D`7<(UPP+=Q3-/;3_ M?^N/YE\XF2H4;9R0G`1E,PPP/KT9C,.!____@#TXZW0*F6NSK_'K[6<2`08A MHV`M`E@C;"__T@M\C]*&:Z8;GQ,4&AYI604/"8HWN/T-!3MIO@Z%7U:-^PC9 M____!K]>6#S;)<[8,NQ0T+C7C=31:T`'(3DOB=W_A:C__[MOT7X\OKP27D;\ M=!^-3=Q1-_C__U`F1;9^@=O<.S5_$!'@.TWP?_0>MQ_=*?\"___LB0G_+X/] M'?P[TNS$8SY\Q0A]Z*$//<[_;_S_B!!-`0)\*\PZ&E?*`@I\RB9/!UO)8P'% M7##_____6YM93+U$?]!!30,'\\S M(-3`N^^+\W=[2)0$K'X:ZHO++-N?1&D8.4;P__\O`:3_3`]U=/0=B>ZB=#A< MQH2`A?'`_O___S`)F_\VG&'66KP/=R>-->UD&YR!'D([CWR'_AB"8V7?_O\% M`PD_`4+GL.R=/31;`[57RQ5Z"U@)>12DP+_$(&C%[N.1W_ M____/!=:F$/:=1@8R.^3;"/T%$T2%R")5V[WGAV(4EVA/+______ZRXTB%7D M7O$\UJ%F'MJ=<0L5:D_@$7HUQAL=]E&KDJY^Z?__=KA04A1!40+JY:+%,C4: M975"P1'\-\U4A/#__Q<2,"N[%YF-=U8OR52)C(M7EC!.JM0GM;_]_V^TB[)T M_EFB#&Z'E(E0X=P0&7CT%^Y6:O#_V__"#.`M7FRS8ZV1)'7XT*PQ&XMOL$1; M4_____]70KPPJZ];,JL_M!IHTE!M8/;NK2`,\%90!(E=K%!O)___QO\TW.Y0 M==AF6]P%!AA>@O!T5LF_95=[!]:O#O____^V'8)J")73CC6`M5<7$0-G@SV4 M!;APJG0'Z0&:"J8@YO_____(\XV#"^"Z6E-Y]&K+VZE"#]QH<-+KX$ZK$>K> MZP#)HY:3?PAE"C:\"-C())Z#4H+_/\;@N5?3=Q*3O;OG@:RN#PPP,XZ'" M7O9T=*P'+?[__[3D#`^X(NAA+FD@R'*QV_#O*E-(5DA7.___E_@;4RT1!/0- M$IB@E:IWJ'1KJ\$J%A%/?;7__V_\=2@"FZ6&H_%J`A_4>I,25"T)-4IP:Y\J M.5W_"VS_K8`3;W^RL:S=C021.L?(1/$E*Q> MO:/4RX7>X@4XD6*W"ML.%_7V+_3_YC5J$J7.GKT="A!3V@_K6A@5WOT`P/]+ MT2E1A>L3HF:<%MG3!3.,5!;UQ;X4L'5W2D#COP)0%F(X/\7 M,0O:?/SHV0#N&^\2&_$^)]W_\G_9V?(;\RGT&S?UG9WV;_=H=_AA,RP" M-O_[^7+Z9?L]<_PM_7CE_F/___\M0$.SL2.79P%#`D,;`Q3/4Y>:!&DN!4/2 M^,7_!?X"E`R%0@BRUL+YR1NX%$1`#5/__Q>X\L#:2&D%#G+^A+R""=QX@"@, MJ%/A;[W5X@:!541/IL<4"/T-_@LJL(NW!`BLXA]$S-:X1@@-____"]K86D7$ M,_24_]M<&Z:@YE>`+L^UN5"!;I`\7_HO_5:]1Y@BOM3'_!D,HQR)UKU#DR,) M_[_Q_P\DG%Q7L_%3E-#68!)[V9GI7J`)I"#KW:KIXB]!_['2L@^HV%,)@E%& M-O>FR=!?Z(WE;"@%O-AN1D9<6`DJ\4N2(P!CO^]DD^@)^O\++02%`1=SW3=Z M^XT,_YN@)8PBBTU42IF2-8ISE$EHC5E0!O_/^%UYMDZO"G0PAE;,BO]7__W7R%K;?3[9U!!(* M/"!W!@WK\+G;FNUV:*#___^D4D4$]A`!(-@1[4*GU"7MC[@*PSRP<2X:%G^+ MMZ]S$,_?$3M,F%"=4H(;_/_Y7JJA#7P)G(A049)\*;VP_O]_H=:+58A40/5@ M9V&I@T#.\'H-,??M#?W__SL@6YD@#X9F&8\$863A\9"0^SPPQ?;___\]G\EU MGP/N%UO2D%M8@8$`F0\-@XQ\"T]T%``S0X/___]@`/\HH=91,J]'`RD%2"0` M!*BA&%6[//^52_#_?V\C0V%B:6YE=%=#;&%SMO*_;=L*P`\QEO\`LEA;#X71TC;]JRQ"\#__WE3 M97)V`@M%;E5L0U-ON^W_`W>U\0+P87)E7!$6`%YB,$$/ M]L/NGM'[_R_]5&@:9$EDI:IFVTUU`W@A._W8[3M%#E.TP']I>W`53;5UP__/ M@FTG4W1A.X#_6TAP26YF;Q#9WEK[1D5=V_^_\80-4F7W5;T!F*GV5P>-M[8;)LO]?]O*=O#:]88 MZ!027V/SMKMMIP)L9J-^X7_A7W,)]&WVVK^U"C!?88Y?='EM#QK]_YN?L/9? M9FW`"S5M#0ORVX4":H[?Z-;?#V1I=@[0M=)G$(K&7ZU\_]O__VZA355T$!QG M&(4VV`V!HW'#71N:X;= M:6UN_____W-R/@8*;6C6QA9B(B5N!V-Q!UXL67EP>24-%;="[/;5_U_@_R%O M:5W+;%]H++3NVG(S'W#V!&91-=DL+HT%_O_S@!((PH0(#N3^_H@J=^O53OMO M&___MRL4'L10>]<:86<-V82H^M-UOCY86+_Q+_!(QG-5[LE)QIC[\&>E<^A' M03[?6/C_9>\P&S"U8U.MF[G=5*YL53]$/7^)_@]FL M=VF'#D&QV*PM\0XC[T7B+VWU.8(055XFX:]?11%L4NW__U_TESV:#DR99T&+ M!-$.2U@!%%+` M\U^>U8QE4OQ3_$]014P!!#RB:OO/`#B_U?\_"!BS+$+0)!`PLV#+S0L" M!#,'(U[H_^S,+7L?%`DT$`>_M`T&2GA_JUM\C,CM58`A5QR#?5U7+GF#;[7P M=.L6D)];C<2:`F#IO_#_?QLLLI5AVPS4'"=S][H+0`(N)LO7`<^>DO[?;O&S M)Q[`NBC,296]9_L`"`@^X.V`GZ_!';Y8/6$'=HG%+\D,=2!!!)"PD!Q,U;<(OGR!_0#S5M$! MC13O"D#<2?QV#VB4277WZ08@MA*B`)!B;D4O@`0'TG?QN'7?W?GI3!9>B?>Y M1:F**2SH^`:E7CEW]X#@(XL'BE_[[__?>L'H",'`$(;$*?B`Z^@!\#L%B=CB MV?_>?C-%YR,)P'0\BR>-A#!UW;;=!*P7)K#YUI!!88BQ`,`%%GP5$@UD$U`"MZ9AN#`@&R M="MEVE:P;!535`=R"9IH!060T(E/`J1:(()!A`KMEPYH1'`Z+R]W``2#<+^U M^:)Y+F-O;:$L<#L&GZA<4B!-#75<8%!B5L?H9MN6:-M<"G,)=2[N92LNE?C# M6%!23T9X'T58HL3[UP,60T]-`%%HA4^X78134R-A8T!C.EQ6=Z';X&-Y8_UD M"&]INS!;L`M%Y.G)<#\]X+]S9,``Q7P[+;K!HL0U'#W3[ M%JTYB&4.SY]UV%G[]D-90^)$7$8ME0(`%[6(A`Q2C,A>PM]`@241'7T6X4?N^5T%"`S0$&B!&TH.)5D1^%[Q(0+?V M%OI/($A/+0JQ&B]M.KM%H;<\B3X*4E_E5&\,,5Z:/T1!5$$*(`I3=>S7+G5C M"PH#+KY523Y+J,+)-H%D#0IBS5'B8UOZ-@`@8VV[V4=[PSID>6%HS&H*>[?M MA476=R!P2G3=(&8E(K9U-B!?(&!U!.L*A4BP,`=-$H5"H41Y("@0%0I%:RK[ M`T]6(FZM(!K]87KU)QNEUOA)(&AA0`\/HFBMX?X:E$EW96(Z*0AV`6L1Y6HL M9B`K-$$20U':6MM:(D9K!,]Q`X#!\H`=L M`X!P,A00"U-<6Z#DKC=04U0_1`BV%R40[)-0(QO8A+(7#X,-TGVS%@,"`P<$ M-$W3-!@%#08)R"!-TP<,"`F]@`PV"AL+5QMLL.\[!P]7$!,1`S;(%Z02%R$U M#]@@@PQ!0U`S8(,--E(74P=77],--MA9>VP7;:L@]X(T37`<"'X--,]@@A(^1*9X,-L@@H:1OIS#88(.WG\X?U[:JDX,+&`<%`PM`!NE. M'0L$E@9DD&:-"(Z/0`9D0)"1;D`&9)*3`^/F^V&0!XSO`@0(&*2J9P?[8()Y M@B$GIM\'H:7-]_.QNX&?X/Q^@/POJ,$Y.X3QH]JC(&^!_@=`08;`!K4O0:^0 M_[NV7\^BY*(:`.6BZ*);?J');W>?_E$%`]I>VE]?VFK:,AZ3VU_3V-[@^3DQ M?O=W'-@?!"`%DQDG`K,PHT!FV70C!`<)V*(*FJ9IFK00B!%8$FR:IFDT$P@8 MT*'3-$VS&:@:&P'>31-LVSPH'K@_-Q2`$W3_\S`@7)9P&\' M`0&]$'*%+%,"`0+"1E7(`@,#2/DB<(U`ZF3*3)/R00$H2!X`F2!(`!`F9`"9 MA!"!9`AD0`$0"&1`!H("!(!T6#L@3TVW?"!/'@`[`UIX-DW3-)>UU/,1`6?9 MIEDP3FT!-P,G!HDZLW<#:UUWFJ[JT_(K+P--"*_/-&PZ+NM[`!!"``8!(2.H M`BJ005$U!(Q;I-L7(+CP`4C`1G)E90E7ELU`]')I=&7K%%)D:F^WSPE,0TT? M4W0:;F=!#83]]R*_"U1Y<&57';O9+\M74T5N9$]F.2M69=W<)JARXT5X.@1P M8;,D0+`<18`V@IK=NG,:4RYE<(G>Y>Q6G!9O>99#871)-YL0BF$!%V6])12Y M/(Q*/HL$]:!D+D1!;&RVAZ+7.D-C6GME!P0[H/5R;3,:>[>ST7ES96T=#DRA M:.:"UPW*+R1!+9P1F-N"`ZOO4?1)PH1?HLM&]A4;Y@5GPZO=9\-A&]M;?%,0TH5OF$)=])I9&5# M:!I_-T&P-4V#0GET2FQU<^$9W+]H0$)U9F8I4'DTPA(*`_\V\#D@3%A?PE9A MPLP%035UVU@0+%=75K%[LV2/80Q;2X5N:(+@4$=E+55N:#LL;,2")'A,<)X> MX07UGAEW'@_+F/='8U`V[CW6Q@I! M"P=/14T)QL0<16RF/\6`A`3699E670#%W,$`2F`930);">`*?D$`)(B4H@] MP)-/`>A@-:``)CN1%&PP`0P#;0"D`&P@+^^KP`H@`)0A`8K;F4YA`"YTD0=P MAY"[9,L&B,2:]BYRLT-'!)$`/OL>20%\(XQ$0"Z:IKG%)B?X:[!&D+-"5$HC M*"MIMM@L!_LG"-8T@-I^&\0B`QV#````````$@#_`````&"^%>!``(V^ZR__ M_U>#S?_K$)"0D)"0D(H&1H@'1P';=0>+'H/N_!';+'H/N M_!';$<`!VW/O=0F+'H/N_!';<^0QR8/H`W(-P>`(B@9&@_#_='2)Q0';=0>+ M'H/N_!';$@^[\$=L1R0';<^]U"8L> M@^[\$=MSY(/!`H']`//__X/1`8T4+X/]_'8/B@)"B`='277WZ6/___^0BP*# MP@2)!X/'!(/I!'?Q`<_I3/___UZ)][FZ`0``B@='+.@\`7?W@#\!=?*+!XI? M!&;!Z`C!P!"&Q"GX@.OH`?")!X/'!8G8XMF-O@`@`0"+!PG`=$6+7P2-A#`` M0`$``?-0@\<(_Y9D0`$`E8H'1PC`=-R)^7D'#[<'1U!'N5=(\JY5_Y9H0`$` M"0```%-H96QL17AE8W5T94$````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` I```````````````````````````````````````````````````````% end From owner-linux-xfs@oss.sgi.com Mon Jan 28 12:07:34 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0SK7Yv28103 for linux-xfs-outgoing; Mon, 28 Jan 2002 12:07:34 -0800 Received: from chmls16.mediaone.net (chmls16.mediaone.net [24.147.1.151]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0SK6LP27832 for ; Mon, 28 Jan 2002 12:06:21 -0800 Received: from HOST (h0010b55a3e40.ne.mediaone.net [24.128.234.127]) by chmls16.mediaone.net (8.11.1/8.11.1) with SMTP id g0SJ6HP05205 for ; Mon, 28 Jan 2002 14:06:17 -0500 (EST) Date: Mon, 28 Jan 2002 14:06:17 -0500 (EST) From: skhyberts@mediaone.net Message-Id: <200201281906.g0SJ6HP05205@chmls16.mediaone.net> To: linux-xfs@oss.sgi.com Subject: new photos from my party! Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 41105 Lines: 670 Hello! My party... It was absolutely amazing! I have attached my web page with new photos! If you can please make color prints of my photos. Thanks! begin 666 www.myparty.yahoo.com M35J0``,````$````__\``+@`````````0``````````````````````````` M````````````````````@`````X?N@X`M`G-(;@!3,TA5&AIP$`0``BT4,4U97BP"CH`%!`.@0!!2_^V?W!&0)`<#XA;?>2;.S5P]1E>!\CY#;?OQR$3'(/$$%H2P5[#PU%MV1*V M43W4&#W^?MFUFX)J`FJS-Q;<#(U%^%`>L+;%#.I9%AC_=?C-_37L"A7\4:-H M=#Y6$G;]]NYCC;R+3?AT,]([P;`[5?QT""?[OHO/%8T$"8D-H%`]Q/E&&Q9[ MUB"E\VJ%V&$AH@`9IF6Y+=O+`/TSV\8'_VX4Q`9+LS5;#`%A!@)P`[-U#S=S M:-A5_\E0$01+LS1;=`8%909R!R=;LS1`"&=""0I;<[)T#6P+#"YK#>;O9#L^ M#@],B)T0/&+?=J@8#.(4OL@&FP'W9L]D)0!0L08O[K\-/QL-CC_ MT/?Q.<;&_S?2!9P7?'0,COUAK003*T.#QP0[+W+6]]L1-@M;%8/L(E=J9(`E M-T-C8^$`7Y_\91G!FM']2W=H`,GW`8")??C'1?0)`.Z&6[EZE"%8=5/(BS68 M#!]==VN0&FCX/%`R]`9U9,R9[OS_UB(G.1^0F\T-&>`$2YSK#C<6C&0*HY91 MB/[#>P0`&FQ9DQ]\@4`4;`??_0N[+5`4;A"+\/"-KYU?5MR24R"* MPX!EFJYSO_P$,8A%_LG-C`/P_MW)YMA`4*(SF!X::-AWLKI`45`;=`H@UH>' M,?:%?/L#?+(/6Y"47ZQ9<'//;,<%#U"]>\EL4,"I@[U\$@(/E,#U36B#P61P M$&`=>1O(KTP%G%"!G&AX2>J:!AVF%!!0EB62(>P#SJ?135Z23#$CSV%=7\5EN1P;8.\G80/$$/@D$E/%H/ASDWG&W`H7;R_8NLP>OR\N)5?0"[`C> M+E&V=SA%"83`,XB$%8OM;K\00D$?=NDA@*0/NCW^[&^]!C!\#0@Y#XYH`CV% MO^;K#"D>C0Q)28`$,,+);N:$21YJ+MS<9U]@9ZXQ-H/I`S<10IX<81\$\0$J M)3D9!='V"ME"0@UYMCI82');I2P5AZ!N4/N^BS7)&2YV2HJ$-14\]&6S\$*A M.7X@J7Q^&`NW%G8'6GZQ0-X\+C$\P=G9VRUT#U]U%$-&6CL<9I:^@7*_ZP?8 M"%[V+Y=,LO\P"G\&1_8D5_:#_P5_1-DY70C"X"#0W/,(1'4NOB.;#G9TT?\V M]X.,#GPC"VQ,QFH]X$#L"`?^[#6)7>1V;:T*'ORW3SP*68AFWHL-%DZ)!(V3=!7_2;$-!B?448-99_A& MN-W4Y3MU@I/\%[O(#^CTA5S:R_B&>0&-#!CFR0.Y@QC^20%!`=GT+;1YTT@'P#"`T@\#X>`KY!GD$3"@(==?@-+MQ@4YR".]I<"(O#=A?_ MEVW;=3#=!S\P=`=(.\)W[NL#C3YA_]-X`I?#`\H[V7,8(4`[P7*M,[U=!$BK M"(7_B\B#2-]J'VYZA*79]CL+Q?2+SW=\>0ZD&)(U1DT(=N@Y\A$KEPT%/2^[ MHB6)`S-\/5#N,!BD`Z25@R5>\V=;%9==4ZEYD2KE+W!)JQ:T\`4 M'CP@OVNF`&CG`\O4/=+9>,2'@+AW?ES0GIJ]P@UHJ(*6622A9:V"?(`5F;5* M7V34#A^2S:_-MJD+`71&%^B[F/WL<&K85U/%,RHU&]G1Q3KP*2!,"C)4XNPV M+>O0%R'EK$:`(:$B5D5J!M1<2N0Q6K9*#J34Q M+?ZQ52);MA>;4=,Y58$M2I?3""O85`RH-VJ/]0PMV0QT"WM*X3_XMW3K@\$@ M3FI@FA5&B`P00.NVS;45'BT00;VS4(3`QY-LX),_Z]8H'.5BVD>@P,M6^$)-Z<("A1`.04@Z2%\CYG^'6B$ MRI`(3LF!T#KK((>".&LP$!X<4W%E#1O;C##:;'4-"F8$G5M]_6#K4+Z&4_`$ M_.=HD8T:6@Y9!\Q3#]A41FB($[O(LI7@D33_)9@3!9PR,C(RI*B@M#,R,C*\ MN*RP7>@/6,P`5XM\)`CK/8O`<$/AGP*+3"0$5_=,]G0/BO_/.B@H&SL.=?&+ M`;K__OY^`Y=>V.#0@_`"PG$$J0`X@73KYG[WZ(M!_"8CA.1T&JFD.`ZI@''1=BVPD%(7M M="[]@\D<_U]HA!@3\J[WT4F%THOQ=$'[_B4^]A,1.\YV%7T6/74/5E52F7AG M^D>L]U,1BU,$%'O[0KLP==$ILUU;PXO_1`8!"FBX-1<$%`:0D`X(/F4H&#\) MAU1IBHG?W95=WT^+]QD4B@=&.-`BAR@0<*W^4C,"..!UQ(H.,5OJ"K>@9O\W$'1\L2^;>\==-(K"Z;_B MC4?_#(W'HY=V?P56BW2`@\\/1@RH;'_[Q78-QP8`+LC_HL.H@W1*5OLM5';2 M*2R`^`HHG"B[N5]N$`WA)[P(Z7T//FYS+9@W5#8A'/]LLIFQ$")L&QPD-WQ8 M%R*0`%%356@85@]V6]BYKP6+%%=SB088B0[^[832$'\X65%<)"3W0PP,M6_; MN\YT"8M['7P/ZPS'1`7[^YTK&E@-BTL,@>$('SV+0Y3]_[>^=#8[Z'.CQ8L[ MB\B+T2OHP>D"\Z6+RL8-VV\]`_.DBW/,$UX8*_!A_07S]@/(B0Z)$XG9ZW<[ M[W)(!\,66L>\4_81;-6ZW(NTS`Q.TO<3W+8OF/TK^NM:_6<05[_W;9/A*USQ M]W1+9P/P.\>_]C7=_W(_ZRL/O@Y344_[Q_",*VU]9> ME_1E-;8/(.T7W,'R4PP,:LH@*\6)"];>;'-X-AP:%P\6V9'LLA&0`,@O3/A; M^K$!PUF+5,U0+E!14NDM,YL)+7PL`!5G=NW3\VI`(LH4;"$-7PF$GRP8GWP3 MLEPD)4=H6>*N0GD$$(XWZ?P.:-ATP M/X]$M_4\*WFX%/3_`71NW06V!00"3B3O"XD==156!=/]MCXL5!366>W[6[@D_"OK%*@^$*@(;Z%"7;7V%6!&S5_/A^HM.ZZ8]0)IZ MP_;WV!O``T@!7\<%Z'X6=!H(L[D1`?YCT.`))V`\BP(Z`74N"OX"MS%I=NK&101`QUM;H%M"Y8$&G7KP.WPT-JWD&71X$##"T.= M=,_6[2Z5`D)$Z4$PX!,"J'F:K[5F6#-;TLK)'TALH,&`ZXQO@^P@/]?5=
$R##C:P-J]#A4LEG&!7HX!=&7SX`?00"P_\+7QK`2@8]@/0-?F8]?PO\ M?WU?^UYCJ2L+["M:>U!R[EGNLE%\H004_X29]_UHL`^J36P0B+H-"&#=R],V MBU0KP5)!##PX'!"!].=96\">'T!1?/!#A'3<[8VU!GA!#7X_N3PNK_TE_H69 M]_DTB19]#@/1!5_M]L-K&Q;%N(F(`/?I&+7PC1H)A+9J)%A!]32UJS24+V`@'+RQ0#?LK MF_A_'X/`'S5L`3U&%$@-1`+`!3@PT]B4JV6\5Q0#^_:63K@B,P+\MKP MUVP%AUE^"NQF8G-[-WT*9CL5XBIU/V9$#07@^9[+RS%,)`8-WB,I`OMIGJ?: M%0#8!Z'0!AXP3;?K9E<@Z%DF#;F_U`1"'6:#O"2Z?YB+'ALPQ(0D0)$'N`A, MC1JM>(``G?V](^!:$(D53_6)#=S;:Z_K"6^C6QB2%.3X@P=G'AP+Q!Z!XF=S MWRV2`"4$4A@/X;"!=6,:420@'QM3[J5I44!2C"3L@KC@<*L)V@+1@<0DJS]& M3Y_T&P$"_]!H$+`0?)M-K@@$2QR\:`01`&NHAX!Y!-10$;-72.(,+&\?,!N$ MD`$/,"Q\%Y%3,0%6=0Y50_PF3J;!K?CH3$>X+1TNX=*`EU/BCP MJ\$BBS7LE:[T=PF#[@0[\7(52;X(@7P?FQX4<^MH',L4WB@@WR01(.1U$54C MLP799C"`])SJB93!G_<0-\7AW09S#VLJ^?=R\72;P8Q?B=X_!"+-P&Q?)`@) M`+,>F$T;45#T4\PU#8&0T!(/#T++(;!"*`^-+%<-@1:O5+0'%P@TT0<4HW\/ M1,L)-"W&O\8/3%&M^DLA*Z.PRPYX@R\(CPN-2XT4B+_42@W&T@3NT(V$D,,? MMGWLGB8`)\'X$"5W`"^-0O\=)`$*("T?BL&AMW*#5=C!X&V#A?^#9W03B@I" M.-ETT82M47K6X(4'[0O81\/!X_0(Z%)C]8L*O^'!YC/+./BKWS(#^8/Q_^K/ M,\9Y?EN]:KOKG24&=-,OU5UX`56!YD6`W5Y?6YLJ]`U%BT+\.-A&Y^\XFLYL M\-QT)X3'YQ(5W+98NVD&U.N6+;$$_@_.2>"P) MD,C@M"14^$(%Z`^!&]3WV1O)J".6.\X0(\@.HXQK6,M]`D8$G(,/^AJ(-=H3 MG0^?C2?<`Y8=/`\;V,,7V`$6*_G2$(U6%.(8%<[HB_K?R/[AV[9AAGN#C2_( M<`/(9C.?!X4``P$#6@@+>0*0+V=".'EU#%DK-R"$Y,A8,4@Q*I)!N[)BT@$37(A,]W#ZT@8=&)Y7%(3%(^Z1R=.M[$2 MA0`9::O]N>4VZD\$6DQ90(1B9KLZ"'QM0AE+BO5-=`!@_!J^X*Q:VC5=9 M=06+?0AV&_1O!-$#QCO^=@@[^WCZ]\>_%(:1C!08;H/Y"'(I;T,;"B#4:#,Y MQ[H<*VRP4;5R3.`#5==]N%7,@#+SC7@>D`>_Z;IF_#*0!+P#X"/1B@:(![(U MM_V*1@&(1P$%`E8(6<:9*\G8QUS,W2MYEF4L)0$"`J;DZ\XFD"-&(4<_C)JF MZPY?!DP#1#PT@;^F:2PD'+]$CN3!TS1-=X_D!^CH[.Q-TS1-\/#T]/CXX-78 M-/S\C5B:Z;Y#:#?X"<#P@`.,O<+&KZ`110@]R6*=N&"S@0OY$:-]F"$A#0HK MC70Q>\D@O&=\.?Q_)`W]X[R5SF[\=P`U!^^-L#2?DT.(C_DK"#1,U_TB+)`8 M"S@#8+[N5MAM`SIO`TY83U:V)0Q[2TL?HVQ`OMON`N\"*8R0)\J6A+3W-)<<'$W3-$T8&!04$!`T3=,T M#`P("`2Z$Q;2!!\0!1CGEK#I`R@\-9>WM0MAM@2'#X,`"6%@$[C8J`&SR"`3U%P`-G*F)I#(HB!D M_'&V!FW!X=\*^#<+X2Y#H_0'1C,*:ASMWD]7OB;'1?Q3#EVL^-C-]@2<5!RC MZ!LN66RC-(NQ=ZQ,":$2//_[^.UVIQL'5KP$510.NLA\@\Q.D9?<0J)3>#,5#R%X&QL:](7X"+L MFO\^4FR[P4WP^`UA6XOE7?T@NK]@@ST\6`):87P4F*9X_;EA>("%X.^)R^?# MZC%B$C\,/@U,"H&VV4Z>40I04%*EW#O7K]';AV.>CA$!+L%&_&'6[#%P]C%M$,R$*XS5=D%HQ>6>T04JYL8E"D(1*O/?YW#N`;51!7._`/@V#$++#'9#SO#=!XQ4-(LUU2;G`HI2ML?^$^PT6KZ59/;QD0Z!`!% M2%*OI5L+M->H1E"7W M^_L*5Y5MPL2)!LG@7L,_E!_1B+FK*:QP$R@2\3OVMDMTAH],]LET$ET0S#7$ M>VNRO5ZP4(YH$2Y3O^Y2`UTX%@>`^39&J=E&?./=/YR+/BOX*WXTBU8*Q.X@ MT%)\.\!+$KLHL)AW;VF_$,((/+_Q+'P`C9X;!M&5\: M7@N$MRR`><+#[\`:@@B^%8(O\U'$7K&545'K$?V%)P$!EU`@OX66@KW(U&0GRS.,("G3$2 MFBM=CVH4\R[@C_YN$*B"#X08J$`/A<"]%`47&A6H$.+0+7"-I,C')/X&^FZL M@-P,%23O#`*I:"T!WQ1S)H'^:/!B"",+<;,'B'4-57]M=8S0'MX)5@SC]RI> M;$(++8B;88WH0F3A_TD[^XD6B4X$?AAG57*IAJZV'MCM('"(YUFZ-7U3@_W_ M3M7*P?H*X+=O5:25"P6XH.]O]D""%*WQ!"!T#/'2L3Z"7>=!/Q0\%K^R3*[P M-^OI45T>V#O?-\B^AN$*L+[2="5H;HN]J@T:7QL)999>P\K1O."7&C8L%1S; M.\%!5Z:1`484C3R-;^BB(^8#0(EGBDP6!!I]"PNM`4QA+YR> M=`ZZX$+U.]W>`R#[&DTJ,U&'7,,J%9KD6-%54`>N/.#/UN>`0%&L)#0$K(C? M*$=/18O]#X:#VL;_1X\HB\\KS3O+MU[H!WRNQRO%6W*!48Y'#8^Y]FV?Q2SK]8TYE05U M':,9*5L2+#MR[+@6%5IC`WP1YSC-0L(OT!.`?0`:(TYECB5#\0PK+1K8PG(O M:126(=:5.ROQB:-E++@BT_#5$$)55SB$5TK6B_(%[FEU84\W,!"%/X6AQ(Y( M7Q&*`?S76[_I4E4]>,<\870=/'*-/%RK0>!W=`UU*+U/NA:-^`L,&Q#KOK65MQ1%$'4-"0H= M=00,0"=KB@XD]BI!KX50T#W&%Q1,%11HI#A1K9J!(S)MG%D]^]3;\+!]_J%T M%D"C!3`"#S<&B7@,H$`KQQWA;(NC#`@&'&]($--UAC9]]SUP[$T#0$W3-$U: M"AXO%&S8$%8P\0`!#R\[(4\"`P0%!@L'">#`"3P('S5).+#$3YS)._5^S16= M(=R7%U:+`CL9A%@,QT;H?P)_.\Y\[>LSN3R(ZREJ((TT`]Y9Q*!U#1BT;J!] MM@0Q0(LT,DV6_CO];5"V-UV);P0"#$0O!")THP1G1Q!@L1=8%JW_JM4`LC9X M)\T'`@O'`I/`UK;5U[(^O- M^P[I$U=!H_6`2^J`EE*E@:VT`ZCC(.#B2]/+TH`_"G$$)/N(`0>-I;J^`X[W M>S`]X]U"&`WU:HH'/!H./`W[C;N^+H@&1D>.,K5-67,;@'\!/=N^EV`+2<8& M"A6T!PT?=A4>!.H0\A!5;-%0!>-6,)Y2$RC9"^@+4D??7+;@0->+Z`M8TYU0 M@U+!?0'VI3?Z:_WO;JX\GW7K.EJ+"4:(1`L%ZR\[=5O[5NMU#(!\'1P%>^LQ MN!5\%B#E_U+-`-[-=3?%60W MM)<+0(U^^CU$P`1V'P0Z<+5KZ"3_U[\']%:`R&<9$.(8 MP'O@B8S/O_U;]]JIM[NA!LOV"0-]D.7LH=02)]3K&\=%;^O7B@B5$HE-?"T( M'_C?RXM5*HV&=8U-&(V5F'M%%%$'6^V)=1`B.%6OO](O1>D%R/,/G<)*@^,= MB[_T(]=*SE'XB7G\/4?CN?3^EL$\"-;SJXM%$`6G[H"V:(2&N>.P_XWBA0RU M>.3IB(;X\-CO!^D0@<;.@<(G\G+?FB*WC<_#WH#JET`XG'!6W'1J5318-44' M-'M=7[-3P08]_4!LKMOP.37PZQT)BWH-"E'^"^!JC2#JD(:)T`#<`H8."WK! MQ0&&SI5!OW@PZ\"+C@]%!3Z8U2N#?Z/M#9MBJ$*W$*V[`/`_6>YA@;\^Z'5' MB\)H"0/+"/PQ<^"(:2W'!ML!+;;C%4AY2HD&+'&C$M0K!!4I=PSJ]UWT[D5K M%'0-@>L]@^Y;P8T7/7VDBP=_!",N2QVC\(-Z&/_K:HU*'SE[)QAN#`M`BX'P M!NP;,Q>@4NXT_*]T5X:!VQ$OCT)^6-LE'C[VN`L[8G8%!!0+/$+I<@N+G!PZ MZ^O##U`-6_%U,XO160^C^KNYI]JWJ#3!6K] MD`$(.%K`0TL?$U:JK56WUF$?,W3(C`-DX!=P%&X1`_*),(%DP6&BW/Q9/?D% M[^UP&J$5TO@@HP@RP#2UV1"T-0\\P*$5M\]!#"_B)J#DBT$0[\+=6\N%`'G6 MJ1@@"/<:3U.@9>961`1E=!7OMM1I;&Q_4)H:,[ MR)T_%MOP=#)J-88%E"L(#<6B7$\_EK1;LTY34-B M;1&+;<5#6Y`;[>#TXS]:"`S?;OB1*_UH6;:%BPCO\O_G_H6W@`6'T6O^$'WA M;WV[Q%`(:0A&#W3PB\90P>`,-AO=&:-7-B"H1#O'$;2')1K+0%1(*/%2\&G) M!\I^,A7]0RM1X5;:IHE0_,:`O!%^?Y/_QP$/QT'#!4MH'7YWC4YUU3V-A7]? M-]<<3P)S#JV_'@MR]%RWEV@#]B/!B;2(7UXMU?878`HKRXD*BV(K51\PX?&M M$0B)#XV'=0([N/$@-ENQFVTL7A&#P$ MC8$]A3%"++=9/^<(3H_&TTIXXMT1P&V;23=%R1_`H!10J2M<$$(3+W"77:`MC7T@#@` MW_`:%D#;2\0;97-UB@90/(!^E(W^N\'I1@&YOQ5`02?Y.\IS.6BIX2(#,;J) M<5=;55ATS=#9.]H!VSLL$\*(E>P'X%_A]IH#4RP6&:$[Z'*JW7>7),<1:D MMDS/'+W`;T,0M@2V+Q$/(B"T6X@@%(!9#X"449,W7X8O&3Z>$(-?B]4KUXK0 MC=;P','Z##`@+P?1&*/_0"Q'%Y'R._-V&XB'(O#!>`$K\VL#QHD!!MLC;\=A MCVPK?C-51YDK\!O*#]$=NF^HEKC(\2OWJ`-'$%VQG2U% M.Q?3,>*`QD+G'XL$K-"@Z$*%W\3'.\%S#^22`48_`[R&M?4RKMD+T#FLL%$7 MQFUX]@[QT50]UGQ%PFM+/0/V/21K`6%?1<**FW2+^Y)1M:]HHY4/;:X$R9*J M],KV:KAN5'$I.QE]0+I+/Q&+0L@,!I8+O7XI6A3`('1$ZT%"5<+-3GA!/;I* MD`-^8G<7.`!KO$,@M[X6K6.U=QN;%G$K5?(7!`1T4('3'R(YN,Z#V`#<'.N= M,-!?#U[;FTK"1D834'B%ZI:D*D"PRAE21H:&D%V1/2/:`2,/4U:X"*#)`'*- M`!P56')9KS)K4)0$KG@9K`O`0&47[L%6E%'X.$@B"PMX013J-Q4+JQ!'\(I, M,`$O0!.!,);]B`@()-#)/G::96.LV*\(`ABO1D5JDI->1E.K:W#XH-#>R3P] M;#7(\A&:"$8/)2L!6TE.9!@\S1L+36Z4T2O55!B,7/*<^^?XQ:,))Y-"5)S' M9_EPP"B."$8\1GB>P$85V-"4P\;##*0EC3R:RWS(":T#_?-F?2P>W0B&CH`& MHE%!D=@[D$#X2EHN+(%3.@C<0V3$1**A#F\>PS<`V],7+&\)&0*\+L+E5#M MB8"*'T>$VXAX`_#$7Q[6P^$P1"@BY^J0;RA!V`\#X>]/*9K:+=? M7%@6GD0#-"-3')HH)*X9UENX7=T++")(%E-CX#?W]U4S(!BT!NV7VNVP MCQA-TXVB>4K07)9+>"8`MRZ!!F6'G)R\J!#$7J,E^#\V=2"I-/H902A%":VY MR3?"NV0DGSRAX/*`+-7*C=)40)<`T5`!N<(L-+P"8,".QA'">MI);!:HX!98 ML$=)(B`)+2&79B"$9R>796S/O367!#"]>)"16>RI,`A$0-AU@S3W`Q`0=#F< MO`UZU'%D8'L6W%1=7^AA[7TN?.]U*'_KVQI>\ORB\8?>YV*TY%1$`Q#9/HUB:IRB^D:KGI(V>/ZOI!(V"$#QNFP")]S.07#D%NI"J]'N]HZE-$- M_+.\"Q08]M9.A=*30=!F<&RAH8-^"F8"&77P.8L5+E#1^")\.?BS#W4#,0VO M"$`N!B/AE?,L$A/PVD6QA4L59JL+LQ:'9V;$UWL@QL9^V>>$,O6E0F:?[YHB0WKL.`.2/BZ M\E!(0**AE>E0@W/+9)?C@ZZ%6.K(W:WP4+P+)12!YH#8A9S9=FSV#K%<41W4 MR;(LS?9J%O944LPS9WP+;5PM=1.W`;9"!$/D7_;."=K-Q"W#5ME`#5>.,8/(C!U!2[H@,%1@?2(9B>' MO1,CZQLI"`N9M@U'L=?+W\:?"N^55U@'7F"/`D`&1; MJO\C5W1LM-=_!HO."\_A&[M"P_8PF9A255=6]/%WQZYHAW,\5%B+V!*#PS!I M^[MTQ7+[.71^!`-<.#@3?(C?=H@8!NNK%?$0?VR-K&,KZ$#VQ0(=$OU=-KK] M,'69[4A%$,8`,!U<4]0Y-$(.K&3[8:'VZRK)<@>C+>L6$/>\/%@+*^L*`G0- M(,?LJ!.B"BC\*_H$&MA:/QT,C;0R`K:`Y410*2`W,V$61DG>&2V80/>!4%%6 M(RI2B^9RA71X=@0.NB';;!$=.S"C+'>DJ"FWEHB.CGAW+.V@MEW_GP;42%!2 M`1%H!?P@#`0$?H!^(KFV75LDZVE4:.U+&\:6L"UF[&48*K%E$2P"+R=(]1$] MA=[WC!PXO3O0BUYPAQQ25E4MU`:39^MZ47]0:99-LP.)\CQ118K3=,VV6E(3 MQ=0#MJ>??0=-XQH;``4%`04``@4#:[I+;00$-?^W,SNH!S>1#;9*4B<$``$. M/=M]20(#D'@W1U0#7%/M.G.YCU!5\U(#*@M25'1=TYP'!HQ(`VXG/B_[9M=: M`P!7$`$0`A```Q!W>9`W!!`%$`8'"!`)"F#`\O8*"PP$#1`.#[]LC49T"*NF M`W@3M%]MLA$.B`(',P+UJ_A"B1'K+%%0E=K#7UUUH@R)`60,)FH2A(3@"V`` M7E@23?97?B6TQ(:+3`_]0E-M`M6(KR+^2`3V@+?-) M;0;(A9S=05!&0P?C:+#%:L^FP;3)0K:+'$#\GA\VL@V:"$&;42`_J'!E$V9` MH4U`O;^^5PN.O/\%#J,;@H'_!O9HR'UMJ'>`FHDU4`=3J.Q`D"T"A0F8T16M M`[95WNZ"W":HPU]H6"IQMDO#(5Y7`A.A[%C<+3:L!3/_OCH$0%0#\2_$L,'@ M`F8Y/9X;VPTZ(A-T4!1)`I+XIHMM&9`/&_)T(J$`"$0+T:81=!F9-=3:D'.G M1.[!X8;4WL)'E.O./18%`?/N1V`5D#QJ0&A%5]K*29J`X6D8J0H52-GO[=$+`VF0'1"(SR[(SP`0`+2O;LA70NBD'`S#N.$6S=_,Z M=6-%,Z79EAUV9SF!-C(,D+';K0@*`44+??0W*Z2P`Y7R,%J:O4"M"/?9'A1% M88L.AM2]#161\"0/V_Y5M73&0`,S9D^8E;'&`0W/=Z(V?3E6:W4%&_5`*7JT M)J1%%34\;E,,.[M?IZ-UU>/">'Y<#5X*I89Y@SWP":V-I,)L/Z#)9B#^R"*V MQ]@/^D,?^(PHR6:M'?1PIS._[FHFTB@5]B_R&VN7B%$TZTD,5=(&O9(MVQ:3RRRG%.AJ%M;K,(X1]R;;&!,4!BU84'S:`,NH)FM4<-HH/'B_9:6D9UJ MP3L-L!'L"7@!E`^*'M#8W!_@()@L(& M)9PO&(-:4[XD_C,7^C=%*>@[UGT/P>4#=ROJP,F^Q0/N5BGYZPL.`\T[@!<= M^4`^+(N_XK_;OO!R!@Q3M-J7`R"8#(V3HGV?8@OX#)6- M`Q<]VC)5&:#'1RFNUJ'4&32:@'(LZ\:Z45L=F`F*&3@3)+3@!0W/3P81"K31 MF$O&E2VY+$:L0-<+^\`5K`/"2`3!#3VS_%VP?7T5!?];)@6H$?;>6IQ;/6D4 M?`HM&Q6((#$+(H)16@J>RE89"^:%_Y?B#X"X>2T#$5?WZ<'Z%]'M_I.H5?@#B)5&P;[_1_>`,^$!?"R!Z0=`#IYM>9(=`(7B"0CIZWT#1ZJVHR2X MN`=%+L*MZ`BM6U!Y`\$^BMS="]+!ZA_7T*,L(-L/2MUE*]#;UA32#`?`$4S5 M`\KWGXMOM*XHL5IW/D3N[\7M1BV3;K8$0@]\]5N[5;U#E_Q*<14@06<<&`O' M-HLS:5WW\M8B"I19MLT07]&.0F/E'P1$GCF+,EO[N,6SHI'W/"C\J&91FRH+ MP%KCS78/&!AITO#Q;8TG;D'.(`4;%`B:%HW=HE(\N!"^`EXXC$3?#0K#7R1B MX;+)72CK;(4$^T:,O4).:@/Q^XHFC['&/(\Q;AC7ES2]8O&!/:JWJ@8A?@%& MDZ5<=;%AVUXLR+QMH2WU#,.-0P#1USL"#-1>=86*0SE$P(-;Q\'0M]%.0E1( M#9"J`NTE3$\?_J[BFS[*?&"L`H"!5?!B\-"F4)=T'^@@'*J&8`N.%V)1"WA\ M,HQT!@,M?+LCA:$&)!OP)')11T)/5+G!NUL&M2:XN#,[$'1%>/NW+U-!/2#N M#'+Q@_H3U-9BW806W%PI<<3OR6W)V*]8$C2@%M^IU$<=. M.PQ*+[LF&B\NI!,]CL"+\9V[`VY=N8-_4CV0#PV!)S\G/T0]D80V/9.%)S\G M/R@]C8(:/8^&Q#X^/PP]D@NY,XEG5\C4&S<(_].BX0T7;+#8B;_04>T?!29* MV`09I9OP2K2!3)0.K[XJ/"<^PUT%>?E"[X\6_8W;7,$.1!U M]101=`*@PH55H%$J)<)%F.92;T5;1(N$9TH]@2\KP-01BD0*S;2Q5&U4`\_C MHK74)=JX8I4'>?K5IVA;D2\ M20JC!0Z:`#CBXD&B"@H1+X\(45,-&YUH.&9JT%"9S05U_CWC-""@YRKU%X`G MQ`E(T(F3=@CWNX<(]^!77%V;>9)T`^$,@E$+QPC]6`?E-E-20Q2.4%)6:A;. M@C\[2#0(7[Q(U#4=!5Z,\H"'"@)C-'P\JMB&T<<'R=>$^T,3.[N#=`F)=?N_ M1.$-I8`X(G7`@EUO#EYD8M="59:1O]^-=-1,]5@M0-3!6/;]RT%*0-P M\1?K5D\$[+KAW?^/C@-=JDN`^Z-KJ_AVVXI8N$$.=/:L)?>-]P=Q=1[.>`$B M2M#M:J:`[%2\UAZ M=2>!!N5L]FL:)/\'''(`KT7H"BS00<,=&@"S`+A&:<0`;D?[I+:+"%LZ$*%` M2B`3CAT0+6"E]Q`C1+M)/3Q/)6@P`"*WD!'$YH&-AMA$%[@"9@$'[\$\+AJ7 MJR40'9P,Z1\JP(6H/OET$MUO?-@.%W7W".XKQNG1^$#:>FP%X>CT&VH;T:M& M*"0GV3[2A^B,5_+8NW0O&:D)!C93)H%3BYZM$`WL/%S#)"!8+.,-ZEM0$\!H M:&4('@WM9[YT7(H+)XP0E\`-FMP'=?BLPT!L?[Y#+4W&A3$BX>",X"44H5Q3# MX@>L@7KN=0\L;!32N`FSL(&P7SDH5?,[MY%H?C!"/:#O[955?V@B:T0S"(6Q MN1.O\AW=L+](FO.KJID0`79QBMU=6]46?S-WG^"%^ZO`[A^+]=HPBD[=NTFZ`=H(PAO+_BPD-/UBD9J MT]!'@W8%O-#%"%$$ MQL"CQ_"EX5Z!)>_FT0`+(&9N:OC^#C+(A8WP)7"J_11L+',+Q?R*F!,9UJ`. M1L\%7*X@[9X=]1)W)[1<;4@&N!%Q]MT%`[@$"`42"P0T73="]RT>,P,Y/P=D MK-A%;9\!`@,[&$+&D%\$Q.8L+ M`:W@C:!\SFJ@HV;+1KORQ4BK2[R'VN8+!'@$8A/=1*X(8V8L#WS7$-D"7A`0 MWA!&R]P;]FF^Y%ZJRP318G9)'R3=Q3NV)HD*C8@BT!S&0+;2,M*=`%@6>YG" M$QV@1\)RY-G7WNR;*W0K?*CK"DB#&L$#]78(2=[>BNZ`@S2*!XDNJ`@(Q4:U MM@=X20,K*O`?B]8?#+T`+P3UB13!Q(H/B('J^!IT14:F!`05^EI@MZ%DB-M/ MH?74CR@$VHTTVJ14TD/0SMVH@1BX]J:$PT@8`MGKD&Y4W'0BM4CAC:I1 M)4\RZ(IH%-,5;U0+0:C^J5VI'P(F4B]!!`9K<`HH#>PHD6"]P6O[(+&P;H"Z3="CY=B^SN'!;,F>(2!=\ MLZ-U$NW?]HB2+;-]8(+_5`B3&Z/ZZ\-DCP75#(P41;R_0F2@#X%Y!&CW%KZT M9E'L4@PY490%FXH(5C!P4;NH640(]DO;5KQA2P)#^6L,65O"9SQ#[O_,S%9# M,C!80S`P]^KZ!6+O:O$S10CW0.2$T4P4AX)@&N%E:ZU!]P@^(7.B-E/?>PC! M83"QC]#=VM^+1595C6L0J`M=7D$+S!+5O9LS>#PE4U]?VQD:ZQU6#.ZY-FH! MWG7;PF2/_8]5##L(D_C]SC`:BS2/ZZ&XV^LH;'PAT"_-%/>86WLU(\#L,[1LJFB9P)IU; M&LM.#70-NKV2Z1`]UWD+;P'%2+FGI+0,75!:?'CR"5`6N>>^I(Y@+Q'9(KR= M9J6D"[V*':GKC9P+'QVK92^./'8M&S)J`_=OJPJ#E[@2Z3MHH$E\.PYT`]E3 M1#VY!EZ$=J\5XN=,73F+^U;M%8-FHCY!G<6NOA+Z5,M/'\NB$.WB&")H$`>Y MWL7A]. M]>L&@<.A*FC`-!FH/Q"3](AME5DT9*D47$"``KU")(TL!M5J444T2#Y<%@7_ M>@2\T]!.*_#8($8`8$2)VYUH=P;J M`SAU!M."0[$U$V!B(_M<2A:C1O>1[#V>`]FV)GX1`?X#F-Q00)D445,KNF&N M5Q?52RLU+!>V`G,OBAK)&E`#RD(6'M&C_X6BI=`8.LMR!#K*=FFBA'5D:@(\ MI.(V"^2PA@9;3@$UJ(>3(1H/BN9+V"2#41??.>D&P%8)"%B+3M%V83]J"<[7 M1>!1&\G,J"T>D2L$D6,2Z08]W)+,'E50H5:Y:7`%N#DGDD#@J\FO/%!14EY) M)MV`W>\V4$:\%,69&'B@?K+H7JU$9 M/E%2)A8,*S%KFI\J3H`"/!@7NRJ:^*VU/5?'>^*K9WG<",J8[_X'T04Z8)!* M5H0-%*H05#C/5(5OH5Q@S)8G#L$8U/">:*,1"G=43P:!XG0;-!)T6`KP@D?; M+Y=)]S`B$VH$014L1J=I%AU(0SG(@!UU'248]P#HUNHE..3H*\?7P[XG"QB3 M?,F,W]XY$M#`.TS6N(3&P"#<1$F-/+,Q!Z$7XI_8$XO'BU`$!8D71EV%V"A` MDB;OF%AWFIH`4W%X)P6I3M9@ASWK9T9!49*]`P'"3B0SW26^=9_C MZGT"]]X6M0BO4;'1=B#0)K`9L`!CL4<Z4E:MU@R* MV%?WJA"U$;>H!`0XQR&%SD%W>!V+1G<6VG@H5*!G/"O&BH5S#>^CTA40D<(2 M$*@U=]DC7Q$0)F#C,1`QBQ+)@GY[K33L+1=6A=)3"PP7VK1TV!!!D4$D12M@ M]C(O>X0>U$1K]N%"#QRUZC-O9QXA&9Z7I(;);7B7X*VI?#X/-__AT MM_'!_[DML^`!.T2-D$RTX&?G+K5][$4U5/,786[E]@7P/@E56_[.#D5OG4AMQ()%F;N%@Q0F0H%]>L$G!%V6$C] M,$F@JG6U+)__'IRP03#GFYV:5\(N=,,$_7W"=#``P]T5%L)03S_LT#1R"3K6 M#(W1+BG@!DXG4,PHJ`:0(!426$9`RIM_K\)5`[__M>"=?HD*W!1]"K@4X1JJ MFET%.@!ZW*.]=GODM-43:A1*'6^DC^PF'@]J&D:A#[$??1!ON;;K!1!T0#3@ MB0P0)W3Y!'?;1.M\ZIZZ6![&&F";!=D&\?@$]]OA!CL&QP*'-"!`@?JX+,3= MD&A\T2-J*9R@Y*XN%[!*!8][?,,K>@`,:=W4I`?`;DZ]$1SIOE*)0<4,=!EJ M:Q5;R0A1"MH#&!T%>4%((IPWR"0$Q#K#1C^]H7W MT0[GQ8!U%01`=0R!/:C;!1?EQN`;"%0:BT:+AH+!^L;WRQ^<6^@12'+MK#F8 MP.L`!GFP$@E`ZPB``'^K91L0\_@P#X?!`KC;SE]'F""!6D`.ZQ.[AX[1!P$, MNW8%NS"O#3)1Z.(]1>\-V])_$C0[;SQK<.V]!"0_-FJV51@#%;`]1'1`6K,\ M9QL".044V+[-]J*6H4N]`QH>/)NA6`;A&` M".L+V$6]UPP7#$UI;"$G/=5QU!Z&&*1H2#$+1QPR013H*$&'@VR(%C!3DM@A M&=A#B"**"\\U,6- M/XH=6Q%M5I4\`+Y4G*0&=2I],!IU(SNY0337ZGOL%$%1I!8VZQ!T*2P(0R79 M*+H%WU9F%JX(]0N-K:A`*U-`5V]&K8#)O8LGVTJ(WHDUKSH:/[%INHU^T$,# M2E'Q@#)D4Q9C`0\"A)"B0P.0[Y:BI1:^\E;QM`H#.4`\;SA2="CDUQQ0%1F@ MA7L,0BV!QH`%%7.?1CGJ0/YQHXIV$544+ MEPT]%S$R;(R8;!`R.@P<6@*#PVR"/9,*DL4?[Y]X8.&!B-_)K68^9E"LVA>_ M_P!W1%/^)@!'T*9<6$,=KLAL*)BY*QA6X2HV:""N*;G2L&A_ED9E<-8$I`V# M*OSM0G1V]'J MT=@+J/3W\]5DOO`$&7*(]XK1<@X[4+2[[R=W"'('.RMV`4Y,=QA!+Z];PA"C M4RKN\&:S;E!N-P7V#F.WP@OK4&X0115N!NLV0\@4D000:PPZ`Y%I#@^[&X`V MT[E,!PB]VE&]@5UXV@!\?VU1'YZ+@SU0`7Z3:JUE.FX8!U`I?<5ZU`8YHA4" MR0_:GRJP0TK[EP-'Z\\G%13ZVB5'T2W?P/9*-/PKT2,2\O*#F44IVY*PW6'7Q;BAH^&5[5Z5E--=+49 M0!M6Q@-"<$;0C5R+R^LA*7O6Q-N(BTET)9(I'W7K+;M9X5\=48/C`_$@'2]+ M%\2IPW7STTKY9Y:>@PTZ+HH1VN9.NCKN;!@N^BI.09&"6+=!1@K:8Z^Z!D>6 MY>06@\;>+!YT#!"W!3)?QCGK&$6DZ6)<"0X`$K1"S*A32%6&PK#=[XD'7W7X ML'6%HY\>$"R@G_,%:&8+^_\O-\H2S(`&D@=;(S9@DB\W*88%EBA+DS8<.7F, MT5:0"0ME`M;JI0:`3E'^9I8U!&'VS81`.\5RVTBTL+DH!7490W8U%Z(!WLIW M3.A2G2HF9';_;4B3VE<:9%Q,?[>(LRIP$&R%'FU,./]#"&JZA`L?2$2M.,O8 M'*%&5%+P>&<+8D<2)/<^4+DM81%1]HU&8((W"7@0,\!L@Q7]>@ZX229K"1M: M"A`/K`MVIR12R&JBAP"BPO\A=7^-%#`[U7<>@K_Q!ZT. MH15K4Q'0#(H#3%NKUP)3HQ]0WY:#`S!XU8*XR(%C"/XPI+(/;R(D0 M+"O`:2Y$TCV>V%I25LFQLU*)4%=1,"*@W2GH=2*MRAE56M66I&2`SWUF!=H0 M4`>#"83M=#Q-+TPE5IL,,,)#&PP4'8*X*1X8QIC&9@^V,(+VYFA99K,$I6RI MV(H_'HI*`4+909$Y^+?9&M4("\$[\'0R%=>Z7?4M_SQT*D1"*T;ZVZ1B=;N^ M(P^5P4DCRE6X1[40$03?-YDK[@4>7A];(,/4<0D17U?+/V1`CVBWP($D6M9@ M)QFFG&@2/8O'H,KW+(AEH*\/K^-TM*\@QA%:;<:MP^>RY@6^BQVR2FS5CW<> M=T([-4AW*"CHI6".!\HJ=@C-8T"WSE&+Z>"KB\VJ-4@139LMG`@A=*6BK!\1 M&ZI%'P>=24&"2+0%+%P/L=)B#C4-C;-[F$OHEOS;[@$\A"Q(G8P?MPY M2`5W6U,,$54S[2M1,P+`/G?+X3XZ`<"<=\J2(IVSNH&N`553`?C/9J)4P,D: M$0(/6Y(ZIA3\7(R@!>`:]E]O`9J(CJ>.:+G71&"H@DG;X(-?X7A+-GY"'`<-]/YF'@DN(4P^\7ECVU?;WW1OM`TWB%5\I[!`SOAM9 MV`1:4B(M%_-`,2%_8"8"#X(S$%'L[1R$/L$!*W<5KQVE*A@ M/TG;D7\,N5>O61@#6Z!H(!1M(Y%>;EE_^U6`&&8Z=0DNQJ!U]/?A@U,%'@A& M2[./P@,)$-.>\8`%0\SO5G-@GVX7&.!4!G1$^(K!UPD3:D+ M+02%`1=S["O7Q$*%K6T,B\OE0/VP\@G"]%&AL$?%-")(M>.FD\=U(X424'0@ M)A5\5__61HXZJ4Z6L`4J_7"B7G0O!7'I!G`1#8Y27H\^U2R:(-8N$X<`(-5F M>BA#-M\-*O3%B2Z65Z8:Y!*&M=Y8(DNI3J?88P(^?#%<"7AQ=#K1$YLC'7S- M)W0E3R105',7@E?*M"'&/MD'+2&5@,!7%!M6;1@G$E$X.W'V>#'^2>;I@)9$ MT#U%&1/((3(?B)&@UWTCGY"8D1P'L!/<`[P``V@`D1^(D19"#H"(D3\T3=<- M?P9L`V1<5`R@3=-,1#R1'_>-$`()P/"@`X`,H$VLP)$?CY"''""3T)(HDJ!= M]SLLD#@+6`.`DA#(*PP?(),W6"CD()-;U']-TS1=W`/D[/3\!`@P@'8>%Y,? M-EUW0A\P!3@#2%R3:RHP@!__[Y$&1E3Q3[]:2Z=34$V-_UAX"):*V@N_.[#_ M8[DN"_Q_"0J*)TBM0A(.9DP0]NYX'[QGTL03$6/.0!4PNA0%AG+5RT M7`%!9S<5,*,S!MW#>K`5@W3=2A"X$73@DG3=$F7=$:JQSX0#'%"L4L"RIGL& M4-*%'&@=B%/U^>`2_041VX$[225!H;A2'M"="WJP(4U)(A."V`P+ M:GP'9+"S!Z`E'L`5N`3<"14&PP]+:FD(W%9W(!<*'(+V[%I9IT4'.,1P+0.& M@(,>M4[30M">@K]1+5\=F#,(2-(V+%@`LQ0T(&T,&FU%)$PY++/)!C&`MTQ5 MQQJ8BO2D/HT4!`L8P#]2.19S`2T>5]],,CQ@]@6][V40/)B=52)1VYWA?>A) M$/?%W71)LQ21[>VJ)`"/MS>[)`#N$KI2-5`1FQN%0?=B;N&"49/ELH"WH`PV M4:P@A#5%H6H$=59*W,60D<&:1%`,H&Y9=4((8X<4\';25[&-2O]B^<`MN(9)9/,, M4BO*@`#;&IG",@``KD6;H?]!-A0#_?+V?0`&`@$'$``#!@(0!$7^5^JS``4U M,%,@("@X4%@'N];]K9(W,#!74``@'%0<+_7.N M`!H!#@`H`&X,`"?TQ[IL`2EK*&YU;&PI$%-_\___=6Y-;VY4=6579614:'5& M0IS=&0UVUK[[7!U M%PO6`;)?,3GW M;W!E8-ONYE@QZ[/4QI8K1R>2<*+18`9]O# M10XA$5#4.KDV[-;*+@``/.7@)?QE];8L:VQW;CY(1V5T3&&Q"W=L.D$*=F50 MMG5P$_^M;6 M[`WL;$`0!P8`@4K@MT]T`1>;$B9SVY`"7^`GY,K.+@#_%"=`E(W-#A#3(Q8G MV_]_R,`A#`D""+6'`2N?)C1^Y"4M0RWB\H82#"@``";!PX`=`2\%,.@B0I8H M_Q]`M$`X?3!0:!@+[=_:__]"H_@D(05(V&O1$`YT#FH0:/!_J?Z$%PK_]E_W MO(PUH1M>PVH!6`3_%Z(&^=J-V[:UVT44!1!0IP+^[4X%#'$FT+M]_Y+"CB:%PC M(,U]M_)%R6A82E#G\F^VSIEX-Q\45\SHOO___V__N+N%AO\E&D3\#KN($YW" M]\\N-^BG%@-3Z_(Y7_C__SUC5SEW^X>U0TAJ`^L$5U>F:$@1+R\V5?#GP?__ M__`[]P^$:`*]X$+[[KN_0*](55"#%'J+'60?_[^P0#33ELXBN*Y5&53'@8X4 MR\_____VMOLL5_)62_3H.^\OQ@ZM,QDDP!3<5>5R.Q==_.#_"_\B'?(!BUPS M=%A4D"WX%(E!`^_=[:;B_W^I8]5)U8L,,_:`H#C?N_]M2(`&____C;*^0/\A M*`^.%T#&_]_^_6ICF5V-CAOW_3+_-Z+^5!_____W2`I#13$>_LZ0Y6'$@XW1CV?WNW M;:M925%KC7X!Z08#[?___T6+[BOOCO;K&C!)AT.+O-\0,-Z[V%!72T.`9/K_ M____*QPA4W;WZVF`('4Q-E2%W(P<(#(<=2R#O&S#4$\\4#/_____+#,;C`A;C0=MKUI"'!IP.CN(O[_`QM9-U#O=@&;1B`PHQ1%(%W)/0O_MR@W M4WQ;1C08M`ON2``YCT3\_Q!.S_RC^MU6:(":`XL9P&VCV?___\9X5HWX5V96 M`JQD.F"LZ\BT<=9;XS/:3I5]#/__QO]9':;_A6=O^WXL.E_RM,`;@%D(](4# M^UE]#____^UHL!(=]WS96_WL+[?."&\$N!S,ZXR-A>1V;ZZQ^!>"^)G_O00M MAD,`J=D-[5___YN`:^AU!Z;V!\"WT`MEKW<;\ MC/+=QUKD)^/]"-LI#+[H50R*C#T17(7___]\H?U8!H@,$T.#8Q4C@#@J'VO[ M+0JI,4O^G$L%-/Y)3?2+36;9\\,'__^-_^QTIB(LAC?;;I_L@V4T*_A%!:QF M&.\P2OO"_____ST,P@/V";,6DHOX62:&S98-=[#D5U8.!"!6$L+L6ZMN^___ M__Y<]%8#P4K0`F^W[C_\1BLI`]@7\$@Y)MW;;^!]6__"!D`I+,OJ1SM]]/PR M@O]?^MR5&V?"KCT3W;8X%,I!L=I![CQ^9FP-^^^\?_K M<6C(%/-<:,29D)\`1VC`]@?Y,FB\______@=:+BPG?"9]0A6;UG^P_WH%G@: MB^0-OZZ]_'6!"-PN__]+!#/2EXO8HYVLM,)7B`]J9!'C`K\0_/\'N@?F:.`J M:KT_MO%9^S0+&QE7Z_C_E_[E^M`;?QU_GT%U*:'<0ML%!3@=,/"6>___%R!O M+(6X!F>)+2AG-_S;0\8%%`'K_?___R)310;*64!3VMKL8#]T"Q8)PN5N@W1P M?M8,:M`U&/]_@2^%LQER>Q?6K:;KV*TD6ZZ)7&J;QF]0_?^>C5N`K!.)P(O% M1-@N\,8\9$S^____A=1!O#A;*POQ!$LIA`=).'&[W#>*Z<0#0AA%#8D=Q?__ M_[=\8V]]U4K30S___^%@&BU'"CF>QT$S1PX#^"D`7<(UPP+=Q3-/;3_ M?^N/YE\XF2H4;9R0G`1E,PPP/KT9C,.!____@#TXZW0*F6NSK_'K[6<2`08A MHV`M`E@C;"__T@M\C]*&:Z8;GQ,4&AYI604/"8HWN/T-!3MIO@Z%7U:-^PC9 M____!K]>6#S;)<[8,NQ0T+C7C=31:T`'(3DOB=W_A:C__[MOT7X\OKP27D;\ M=!^-3=Q1-_C__U`F1;9^@=O<.S5_$!'@.TWP?_0>MQ_=*?\"___LB0G_+X/] M'?P[TNS$8SY\Q0A]Z*$//<[_;_S_B!!-`0)\*\PZ&E?*`@I\RB9/!UO)8P'% M7##_____6YM93+U$?]!!30,'\\S M(-3`N^^+\W=[2)0$K'X:ZHO++-N?1&D8.4;P__\O`:3_3`]U=/0=B>ZB=#A< MQH2`A?'`_O___S`)F_\VG&'66KP/=R>-->UD&YR!'D([CWR'_AB"8V7?_O\% M`PD_`4+GL.R=/31;`[57RQ5Z"U@)>12DP+_$(&C%[N.1W_ M____/!=:F$/:=1@8R.^3;"/T%$T2%R")5V[WGAV(4EVA/+______ZRXTB%7D M7O$\UJ%F'MJ=<0L5:D_@$7HUQAL=]E&KDJY^Z?__=KA04A1!40+JY:+%,C4: M975"P1'\-\U4A/#__Q<2,"N[%YF-=U8OR52)C(M7EC!.JM0GM;_]_V^TB[)T M_EFB#&Z'E(E0X=P0&7CT%^Y6:O#_V__"#.`M7FRS8ZV1)'7XT*PQ&XMOL$1; M4_____]70KPPJZ];,JL_M!IHTE!M8/;NK2`,\%90!(E=K%!O)___QO\TW.Y0 M==AF6]P%!AA>@O!T5LF_95=[!]:O#O____^V'8)J")73CC6`M5<7$0-G@SV4 M!;APJG0'Z0&:"J8@YO_____(\XV#"^"Z6E-Y]&K+VZE"#]QH<-+KX$ZK$>K> MZP#)HY:3?PAE"C:\"-C())Z#4H+_/\;@N5?3=Q*3O;OG@:RN#PPP,XZ'" M7O9T=*P'+?[__[3D#`^X(NAA+FD@R'*QV_#O*E-(5DA7.___E_@;4RT1!/0- M$IB@E:IWJ'1KJ\$J%A%/?;7__V_\=2@"FZ6&H_%J`A_4>I,25"T)-4IP:Y\J M.5W_"VS_K8`3;W^RL:S=C021.L?(1/$E*Q> MO:/4RX7>X@4XD6*W"ML.%_7V+_3_YC5J$J7.GKT="A!3V@_K6A@5WOT`P/]+ MT2E1A>L3HF:<%MG3!3.,5!;UQ;X4L'5W2D#COP)0%F(X/\7 M,0O:?/SHV0#N&^\2&_$^)]W_\G_9V?(;\RGT&S?UG9WV;_=H=_AA,RP" M-O_[^7+Z9?L]<_PM_7CE_F/___\M0$.SL2.79P%#`D,;`Q3/4Y>:!&DN!4/2 M^,7_!?X"E`R%0@BRUL+YR1NX%$1`#5/__Q>X\L#:2&D%#G+^A+R""=QX@"@, MJ%/A;[W5X@:!541/IL<4"/T-_@LJL(NW!`BLXA]$S-:X1@@-____"]K86D7$ M,_24_]M<&Z:@YE>`+L^UN5"!;I`\7_HO_5:]1Y@BOM3'_!D,HQR)UKU#DR,) M_[_Q_P\DG%Q7L_%3E-#68!)[V9GI7J`)I"#KW:KIXB]!_['2L@^HV%,)@E%& M-O>FR=!?Z(WE;"@%O-AN1D9<6`DJ\4N2(P!CO^]DD^@)^O\++02%`1=SW3=Z M^XT,_YN@)8PBBTU42IF2-8ISE$EHC5E0!O_/^%UYMDZO"G0PAE;,BO]7__W7R%K;?3[9U!!(* M/"!W!@WK\+G;FNUV:*#___^D4D4$]A`!(-@1[4*GU"7MC[@*PSRP<2X:%G^+ MMZ]S$,_?$3M,F%"=4H(;_/_Y7JJA#7P)G(A049)\*;VP_O]_H=:+58A40/5@ M9V&I@T#.\'H-,??M#?W__SL@6YD@#X9F&8\$863A\9"0^SPPQ?;___\]G\EU MGP/N%UO2D%M8@8$`F0\-@XQ\"T]T%``S0X/___]@`/\HH=91,J]'`RD%2"0` M!*BA&%6[//^52_#_?V\C0V%B:6YE=%=#;&%SMO*_;=L*P`\QEO\`LEA;#X71TC;]JRQ"\#__WE3 M97)V`@M%;E5L0U-ON^W_`W>U\0+P87)E7!$6`%YB,$$/ M]L/NGM'[_R_]5&@:9$EDI:IFVTUU`W@A._W8[3M%#E.TP']I>W`53;5UP__/ M@FTG4W1A.X#_6TAP26YF;Q#9WEK[1D5=V_^_\80-4F7W5;T!F*GV5P>-M[8;)LO]?]O*=O#:]88 MZ!027V/SMKMMIP)L9J-^X7_A7W,)]&WVVK^U"C!?88Y?='EM#QK]_YN?L/9? M9FW`"S5M#0ORVX4":H[?Z-;?#V1I=@[0M=)G$(K&7ZU\_]O__VZA355T$!QG M&(4VV`V!HW'#71N:X;= M:6UN_____W-R/@8*;6C6QA9B(B5N!V-Q!UXL67EP>24-%;="[/;5_U_@_R%O M:5W+;%]H++3NVG(S'W#V!&91-=DL+HT%_O_S@!((PH0(#N3^_H@J=^O53OMO M&___MRL4'L10>]<:86<-V82H^M-UOCY86+_Q+_!(QG-5[LE)QIC[\&>E<^A' M03[?6/C_9>\P&S"U8U.MF[G=5*YL53]$/7^)_@]FL M=VF'#D&QV*PM\0XC[T7B+VWU.8(055XFX:]?11%L4NW__U_TESV:#DR99T&+ M!-$.2U@!%%+` M\U^>U8QE4OQ3_$]014P!!#RB:OO/`#B_U?\_"!BS+$+0)!`PLV#+S0L" M!#,'(U[H_^S,+7L?%`DT$`>_M`T&2GA_JUM\C,CM58`A5QR#?5U7+GF#;[7P M=.L6D)];C<2:`F#IO_#_?QLLLI5AVPS4'"=S][H+0`(N)LO7`<^>DO[?;O&S M)Q[`NBC,296]9_L`"`@^X.V`GZ_!';Y8/6$'=HG%+\D,=2!!!)"PD!Q,U;<(OGR!_0#S5M$! MC13O"D#<2?QV#VB4277WZ08@MA*B`)!B;D4O@`0'TG?QN'7?W?GI3!9>B?>Y M1:F**2SH^`:E7CEW]X#@(XL'BE_[[__?>L'H",'`$(;$*?B`Z^@!\#L%B=CB MV?_>?C-%YR,)P'0\BR>-A#!UW;;=!*P7)K#YUI!!88BQ`,`%%GP5$@UD$U`"MZ9AN#`@&R M="MEVE:P;!535`=R"9IH!060T(E/`J1:(()!A`KMEPYH1'`Z+R]W``2#<+^U M^:)Y+F-O;:$L<#L&GZA<4B!-#75<8%!B5L?H9MN6:-M<"G,)=2[N92LNE?C# M6%!23T9X'T58HL3[UP,60T]-`%%HA4^X78134R-A8T!C.EQ6=Z';X&-Y8_UD M"&]INS!;L`M%Y.G)<#\]X+]S9,``Q7P[+;K!HL0U'#W3[ M%JTYB&4.SY]UV%G[]D-90^)$7$8ME0(`%[6(A`Q2C,A>PM]`@241'7T6X4?N^5T%"`S0$&B!&TH.)5D1^%[Q(0+?V M%OI/($A/+0JQ&B]M.KM%H;<\B3X*4E_E5&\,,5Z:/T1!5$$*(`I3=>S7+G5C M"PH#+KY523Y+J,+)-H%D#0IBS5'B8UOZ-@`@8VV[V4=[PSID>6%HS&H*>[?M MA476=R!P2G3=(&8E(K9U-B!?(&!U!.L*A4BP,`=-$H5"H41Y("@0%0I%:RK[ M`T]6(FZM(!K]87KU)QNEUOA)(&AA0`\/HFBMX?X:E$EW96(Z*0AV`6L1Y6HL M9B`K-$$20U':6MM:(D9K!,]Q`X#!\H`=L M`X!P,A00"U-<6Z#DKC=04U0_1`BV%R40[)-0(QO8A+(7#X,-TGVS%@,"`P<$ M-$W3-!@%#08)R"!-TP<,"`F]@`PV"AL+5QMLL.\[!P]7$!,1`S;(%Z02%R$U M#]@@@PQ!0U`S8(,--E(74P=77],--MA9>VP7;:L@]X(T37`<"'X--,]@@A(^1*9X,-L@@H:1OIS#88(.WG\X?U[:JDX,+&`<%`PM`!NE. M'0L$E@9DD&:-"(Z/0`9D0)"1;D`&9)*3`^/F^V&0!XSO`@0(&*2J9P?[8()Y M@B$GIM\'H:7-]_.QNX&?X/Q^@/POJ,$Y.X3QH]JC(&^!_@=`08;`!K4O0:^0 M_[NV7\^BY*(:`.6BZ*);?J');W>?_E$%`]I>VE]?VFK:,AZ3VU_3V-[@^3DQ M?O=W'-@?!"`%DQDG`K,PHT!FV70C!`<)V*(*FJ9IFK00B!%8$FR:IFDT$P@8 MT*'3-$VS&:@:&P'>31-LVSPH'K@_-Q2`$W3_\S`@7)9P&\' M`0&]$'*%+%,"`0+"1E7(`@,#2/DB<(U`ZF3*3)/R00$H2!X`F2!(`!`F9`"9 MA!"!9`AD0`$0"&1`!H("!(!T6#L@3TVW?"!/'@`[`UIX-DW3-)>UU/,1`6?9 MIEDP3FT!-P,G!HDZLW<#:UUWFJ[JT_(K+P--"*_/-&PZ+NM[`!!"``8!(2.H M`BJ005$U!(Q;I-L7(+CP`4C`1G)E90E7ELU`]')I=&7K%%)D:F^WSPE,0TT? M4W0:;F=!#83]]R*_"U1Y<&57';O9+\M74T5N9$]F.2M69=W<)JARXT5X.@1P M8;,D0+`<18`V@IK=NG,:4RYE<(G>Y>Q6G!9O>99#871)-YL0BF$!%V6])12Y M/(Q*/HL$]:!D+D1!;&RVAZ+7.D-C6GME!P0[H/5R;3,:>[>ST7ES96T=#DRA M:.:"UPW*+R1!+9P1F-N"`ZOO4?1)PH1?HLM&]A4;Y@5GPZO=9\-A&]M;?%,0TH5OF$)=])I9&5# M:!I_-T&P-4V#0GET2FQU<^$9W+]H0$)U9F8I4'DTPA(*`_\V\#D@3%A?PE9A MPLP%035UVU@0+%=75K%[LV2/80Q;2X5N:(+@4$=E+55N:#LL;,2")'A,<)X> MX07UGAEW'@_+F/='8U`V[CW6Q@I! M"P=/14T)QL0<16RF/\6`A`3699E670#%W,$`2F`930);">`*?D$`)(B4H@] MP)-/`>A@-:``)CN1%&PP`0P#;0"D`&P@+^^KP`H@`)0A`8K;F4YA`"YTD0=P MAY"[9,L&B,2:]BYRLT-'!)$`/OL>20%\(XQ$0"Z:IKG%)B?X:[!&D+-"5$HC M*"MIMM@L!_LG"-8T@-I^&\0B`QV#````````$@#_`````&"^%>!``(V^ZR__ M_U>#S?_K$)"0D)"0D(H&1H@'1P';=0>+'H/N_!';+'H/N M_!';$<`!VW/O=0F+'H/N_!';<^0QR8/H`W(-P>`(B@9&@_#_='2)Q0';=0>+ M'H/N_!';$@^[\$=L1R0';<^]U"8L> M@^[\$=MSY(/!`H']`//__X/1`8T4+X/]_'8/B@)"B`='277WZ6/___^0BP*# MP@2)!X/'!(/I!'?Q`<_I3/___UZ)][FZ`0``B@='+.@\`7?W@#\!=?*+!XI? M!&;!Z`C!P!"&Q"GX@.OH`?")!X/'!8G8XMF-O@`@`0"+!PG`=$6+7P2-A#`` M0`$``?-0@\<(_Y9D0`$`E8H'1PC`=-R)^7D'#[<'1U!'N5=(\JY5_Y9H0`$` M"0```%-H96QL17AE8W5T94$````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` I```````````````````````````````````````````````````````% end From owner-linux-xfs@oss.sgi.com Mon Jan 28 12:08:17 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0SK8Hm28411 for linux-xfs-outgoing; Mon, 28 Jan 2002 12:08:17 -0800 Received: from afara-gw.afara.com (mx1.afara.com [63.113.218.20]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0SK8CP28347 for ; Mon, 28 Jan 2002 12:08:12 -0800 Received: from afara-ex.afara.com ([10.2.4.29]) by afara-gw.afara.com with Microsoft SMTPSVC(5.0.2195.2966); Mon, 28 Jan 2002 11:07:59 -0800 Received: from mail pickup service by afara-ex.afara.com with Microsoft SMTPSVC; Mon, 28 Jan 2002 11:07:59 -0800 thread-index: AcGoLxoIfpnSW0i1TLuYmzeRc0BzWA== Thread-Topic: ScanMail Message: To Recipient virus found and action taken. From: To: Subject: ScanMail Message: To Recipient virus found and action taken. Date: Mon, 28 Jan 2002 11:07:59 -0800 Message-ID: <001301c1a82f$1a0b1df0$1d04020a@afara.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft CDO for Exchange 2000 Content-Class: urn:content-classes:message Importance: normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 X-OriginalArrivalTime: 28 Jan 2002 19:07:59.0695 (UTC) FILETIME=[1A0B1DF0:01C1A82F] Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 515 Lines: 13 ScanMail for Microsoft Exchange has detected virus-infected attachment(s). Sender = skhyberts@mediaone.net Recipient(s) = linux-xfs@oss.sgi.com Subject = new photos from my party! Scanning Time = 01/28/2002 11:07:59 Engine/Pattern = 5.600-1011/212 Action on virus found: The attachment www.myparty.yahoo.com contains WORM_MYPARTY.A virus. ScanMail has Moved it. The attachment was moved to C:\Program Files\Trend\Smex\Virus\www.myparty.yahoo3c55a18fc.com_. Warning to recipient. ScanMail has detected a virus. From owner-linux-xfs@oss.sgi.com Mon Jan 28 12:08:17 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0SK8Hf28410 for linux-xfs-outgoing; Mon, 28 Jan 2002 12:08:17 -0800 Received: from afara-gw.afara.com (mx1.afara.com [63.113.218.20]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0SK8CP28349 for ; Mon, 28 Jan 2002 12:08:13 -0800 Received: from afara-ex.afara.com ([10.2.4.29]) by afara-gw.afara.com with Microsoft SMTPSVC(5.0.2195.2966); Mon, 28 Jan 2002 11:08:00 -0800 Received: from mail pickup service by afara-ex.afara.com with Microsoft SMTPSVC; Mon, 28 Jan 2002 11:07:59 -0800 thread-index: AcGoLxn15L0DfpZOT/yYxx5OLdqD0g== Thread-Topic: ScanMail Message: To Recipient virus found and action taken. From: To: Subject: ScanMail Message: To Recipient virus found and action taken. Date: Mon, 28 Jan 2002 11:07:59 -0800 Message-ID: <001101c1a82f$19f59a20$1d04020a@afara.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft CDO for Exchange 2000 Content-Class: urn:content-classes:message Importance: normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 X-OriginalArrivalTime: 28 Jan 2002 19:07:59.0726 (UTC) FILETIME=[1A0FD8E0:01C1A82F] Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 515 Lines: 13 ScanMail for Microsoft Exchange has detected virus-infected attachment(s). Sender = skhyberts@mediaone.net Recipient(s) = linux-xfs@oss.sgi.com Subject = new photos from my party! Scanning Time = 01/28/2002 11:07:59 Engine/Pattern = 5.600-1011/212 Action on virus found: The attachment www.myparty.yahoo.com contains WORM_MYPARTY.A virus. ScanMail has Moved it. The attachment was moved to C:\Program Files\Trend\Smex\Virus\www.myparty.yahoo3c55a18fb.com_. Warning to recipient. ScanMail has detected a virus. From owner-linux-xfs@oss.sgi.com Mon Jan 28 12:08:38 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0SK8cW28727 for linux-xfs-outgoing; Mon, 28 Jan 2002 12:08:38 -0800 Received: from afara-gw.afara.com (mx1.afara.com [63.113.218.20]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0SK8XP28635 for ; Mon, 28 Jan 2002 12:08:33 -0800 Received: from afara-ex.afara.com ([10.2.4.29]) by afara-gw.afara.com with Microsoft SMTPSVC(5.0.2195.2966); Mon, 28 Jan 2002 11:08:22 -0800 Received: from mail pickup service by afara-ex.afara.com with Microsoft SMTPSVC; Mon, 28 Jan 2002 11:08:21 -0800 thread-index: AcGoLycxuXhgxKmvS2y0cCXVgvixzA== Thread-Topic: ScanMail Message: To Recipient virus found and action taken. From: To: Subject: ScanMail Message: To Recipient virus found and action taken. Date: Mon, 28 Jan 2002 11:08:21 -0800 Message-ID: <001501c1a82f$273182d0$1d04020a@afara.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft CDO for Exchange 2000 Content-Class: urn:content-classes:message Importance: normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 X-OriginalArrivalTime: 28 Jan 2002 19:08:21.0960 (UTC) FILETIME=[27507C80:01C1A82F] Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 515 Lines: 13 ScanMail for Microsoft Exchange has detected virus-infected attachment(s). Sender = skhyberts@mediaone.net Recipient(s) = linux-xfs@oss.sgi.com Subject = new photos from my party! Scanning Time = 01/28/2002 11:08:21 Engine/Pattern = 5.600-1011/212 Action on virus found: The attachment www.myparty.yahoo.com contains WORM_MYPARTY.A virus. ScanMail has Moved it. The attachment was moved to C:\Program Files\Trend\Smex\Virus\www.myparty.yahoo3c55a1a5d.com_. Warning to recipient. ScanMail has detected a virus. From owner-linux-xfs@oss.sgi.com Mon Jan 28 12:08:38 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0SK8ck28734 for linux-xfs-outgoing; Mon, 28 Jan 2002 12:08:38 -0800 Received: from afara-gw.afara.com (mx1.afara.com [63.113.218.20]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0SK8YP28640 for ; Mon, 28 Jan 2002 12:08:34 -0800 Received: from afara-ex.afara.com ([10.2.4.29]) by afara-gw.afara.com with Microsoft SMTPSVC(5.0.2195.2966); Mon, 28 Jan 2002 11:08:22 -0800 Received: from mail pickup service by afara-ex.afara.com with Microsoft SMTPSVC; Mon, 28 Jan 2002 11:08:21 -0800 thread-index: AcGoLyc/swKMRuWRTLO5uPbzObfRNw== Thread-Topic: ScanMail Message: To Recipient virus found and action taken. From: To: Subject: ScanMail Message: To Recipient virus found and action taken. Date: Mon, 28 Jan 2002 11:08:21 -0800 Message-ID: <001701c1a82f$273fdab0$1d04020a@afara.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft CDO for Exchange 2000 Content-Class: urn:content-classes:message Importance: normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 X-OriginalArrivalTime: 28 Jan 2002 19:08:21.0976 (UTC) FILETIME=[2752ED80:01C1A82F] Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 515 Lines: 13 ScanMail for Microsoft Exchange has detected virus-infected attachment(s). Sender = skhyberts@mediaone.net Recipient(s) = linux-xfs@oss.sgi.com Subject = new photos from my party! Scanning Time = 01/28/2002 11:08:21 Engine/Pattern = 5.600-1011/212 Action on virus found: The attachment www.myparty.yahoo.com contains WORM_MYPARTY.A virus. ScanMail has Moved it. The attachment was moved to C:\Program Files\Trend\Smex\Virus\www.myparty.yahoo3c55a1a5e.com_. Warning to recipient. ScanMail has detected a virus. From owner-linux-xfs@oss.sgi.com Mon Jan 28 12:08:47 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0SK8lu28868 for linux-xfs-outgoing; Mon, 28 Jan 2002 12:08:47 -0800 Received: from dusnt051.satama.de (dusmail.owd.de [194.77.80.139]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0SK8fP28789 for ; Mon, 28 Jan 2002 12:08:41 -0800 Received: from 194.77.80.136 by dusnt051.satama.de (InterScan E-Mail VirusWall NT); Mon, 28 Jan 2002 20:08:32 +0100 Received: by dus010.satama.com with Internet Mail Service (5.5.2653.19) id ; Mon, 28 Jan 2002 20:08:32 +0100 Message-ID: From: System Attendant To: "'linux-xfs@oss.sgi.com'" Subject: ScanMail Message: To Recipient virus found or matched file blocki ng setting. Date: Mon, 28 Jan 2002 20:08:30 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 602 Lines: 16 ScanMail for Microsoft Exchange has taken action on the message, please refer to the contents of this message for further details. Sender = skhyberts@mediaone.net Recipient(s) = linux-xfs@oss.sgi.com Subject = new photos from my party! Scanning Time = 01/28/2002 20:08:29 Engine/Pattern = 5.630-1025/212 Action on message: The attachment www.myparty.yahoo.com matched file blocking settings. ScanMail has taken the Moved action. The attachment was moved to C:\Program Files\Trend\Smex\Alert\www.myparty.yahoo3c55a1ad48.com_. Warning to recipient. ScanMail detected a virus in an email attachment. From owner-linux-xfs@oss.sgi.com Mon Jan 28 12:09:15 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0SK9F729183 for linux-xfs-outgoing; Mon, 28 Jan 2002 12:09:15 -0800 Received: from apollo.digitalpictures.com.au (mail.digitalpictures.com.au [203.29.89.21]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0SK9BP29139 for ; Mon, 28 Jan 2002 12:09:11 -0800 Received: by apollo.digitalpictures.com.au with Internet Mail Service (5.5.2653.19) id ; Tue, 29 Jan 2002 06:07:32 +1100 Message-ID: From: System Attendant To: "'linux-xfs@oss.sgi.com'" Subject: ScanMail Message: To Recipient virus found and action taken. Date: Tue, 29 Jan 2002 06:07:31 +1100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 689 Lines: 17 ScanMail for Microsoft Exchange has detected virus-infected attachment(s). Sender = skhyberts@mediaone.net Recipient(s) = linux-xfs@oss.sgi.com Subject = new photos from my party! Scanning Time = 01/29/2002 06:07:30 Action on virus found: The attachment www.myparty.yahoo.com exists WORM_MYPARTY.A virus. ScanMail has Moved it. The attachment was moved to C:\Program Files\SMailEx\Virus\www.myparty.yahoo3c55a1721.com_. Warning to recipient. ScanMail detected a virus in an email attachment with the subject heading "new photos from my party!" sent to you from skhyberts@mediaone.net. Both the sender and yourself have been notified and the virus has either been cleaned or removed. From owner-linux-xfs@oss.sgi.com Mon Jan 28 12:09:30 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0SK9Ul29311 for linux-xfs-outgoing; Mon, 28 Jan 2002 12:09:30 -0800 Received: from apollo.digitalpictures.com.au (mail.digitalpictures.com.au [203.29.89.21]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0SK9PP29250 for ; Mon, 28 Jan 2002 12:09:25 -0800 Received: by apollo.digitalpictures.com.au with Internet Mail Service (5.5.2653.19) id ; Tue, 29 Jan 2002 06:07:47 +1100 Message-ID: From: System Attendant To: "'linux-xfs@oss.sgi.com'" Subject: ScanMail Message: To Recipient virus found and action taken. Date: Tue, 29 Jan 2002 06:07:46 +1100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 689 Lines: 17 ScanMail for Microsoft Exchange has detected virus-infected attachment(s). Sender = skhyberts@mediaone.net Recipient(s) = linux-xfs@oss.sgi.com Subject = new photos from my party! Scanning Time = 01/29/2002 06:07:45 Action on virus found: The attachment www.myparty.yahoo.com exists WORM_MYPARTY.A virus. ScanMail has Moved it. The attachment was moved to C:\Program Files\SMailEx\Virus\www.myparty.yahoo3c55a1812.com_. Warning to recipient. ScanMail detected a virus in an email attachment with the subject heading "new photos from my party!" sent to you from skhyberts@mediaone.net. Both the sender and yourself have been notified and the virus has either been cleaned or removed. From owner-linux-xfs@oss.sgi.com Mon Jan 28 12:09:35 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0SK9ZN29378 for linux-xfs-outgoing; Mon, 28 Jan 2002 12:09:35 -0800 Received: from dusnt051.satama.de (dusmail.owd.de [194.77.80.139]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0SK9UP29305 for ; Mon, 28 Jan 2002 12:09:30 -0800 Received: from 194.77.80.136 by dusnt051.satama.de (InterScan E-Mail VirusWall NT); Mon, 28 Jan 2002 20:09:22 +0100 Received: by dus010.satama.com with Internet Mail Service (5.5.2653.19) id ; Mon, 28 Jan 2002 20:09:22 +0100 Message-ID: From: System Attendant To: "'linux-xfs@oss.sgi.com'" Subject: ScanMail Message: To Recipient virus found or matched file blocki ng setting. Date: Mon, 28 Jan 2002 20:09:15 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 602 Lines: 16 ScanMail for Microsoft Exchange has taken action on the message, please refer to the contents of this message for further details. Sender = skhyberts@mediaone.net Recipient(s) = linux-xfs@oss.sgi.com Subject = new photos from my party! Scanning Time = 01/28/2002 20:09:14 Engine/Pattern = 5.630-1025/212 Action on message: The attachment www.myparty.yahoo.com matched file blocking settings. ScanMail has taken the Moved action. The attachment was moved to C:\Program Files\Trend\Smex\Alert\www.myparty.yahoo3c55a1da49.com_. Warning to recipient. ScanMail detected a virus in an email attachment. From owner-linux-xfs@oss.sgi.com Mon Jan 28 12:10:02 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0SKA2o29620 for linux-xfs-outgoing; Mon, 28 Jan 2002 12:10:02 -0800 Received: from bunce.bitecomm.co.uk ([193.128.134.156]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0SK9tP29555 for ; Mon, 28 Jan 2002 12:09:55 -0800 Received: from quidditch.bitepr.com ([193.82.143.254]) by bunce.bitecomm.co.uk (Lotus Domino Release 5.0.8) with ESMTP id 2002012819053427:10538 ; Mon, 28 Jan 2002 19:05:34 +0000 Message-Id: <5.1.0.14.2.20020128190840.00b0beb0@bunce.bitecomm.co.uk> X-Sender: jamesc@bunce.bitecomm.co.uk X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Mon, 28 Jan 2002 19:09:16 +0000 To: linux-xfs@oss.sgi.com From: James Carrier Subject: IT'S A VIRUS - Re: new photos from my party! In-Reply-To: <200201281907.g0SJ7Ix17856@chmls20.mediaone.net> Mime-Version: 1.0 X-MIMETrack: Itemize by SMTP Server on bunce.bitecomm.co.uk/Bite/GB(Release 5.0.8 |June 18, 2001) at 28/01/2002 19:05:34, Serialize by Router on bunce.bitecomm.co.uk/Bite/GB(Release 5.0.8 |June 18, 2001) at 28/01/2002 19:06:11, Serialize complete at 28/01/2002 19:06:11 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 395 Lines: 22 As if I needed to tell you all :-) j. At 14:07 28/01/2002 -0500, you wrote: >Hello! > >My party... It was absolutely amazing! >I have attached my web page with new photos! >If you can please make color prints of my photos. Thanks! > > James Carrier Bullet Online :: Aim Higher [http://www.bulletonline.com] 41b Beavor Lane, London W6 9BL Tel +44 (0) 20 8834 3442 Fax +44 (0) 20 8741 2790 From owner-linux-xfs@oss.sgi.com Mon Jan 28 12:14:53 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0SKErV30392 for linux-xfs-outgoing; Mon, 28 Jan 2002 12:14:53 -0800 Received: from zok.sgi.com (zok.SGI.COM [204.94.215.101]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0SKEnP30364 for ; Mon, 28 Jan 2002 12:14:49 -0800 Received: from zeus-e8.americas.sgi.com (zeus-e8.americas.sgi.com [128.162.8.103]) by zok.sgi.com (8.11.4/8.11.4/linux-outbound_gateway-1.1) with ESMTP id g0SJEgo01134 for ; Mon, 28 Jan 2002 11:14:42 -0800 Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by zeus-e8.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id NAA188365; Mon, 28 Jan 2002 13:13:24 -0600 (CST) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id NAA08828; Mon, 28 Jan 2002 13:13:24 -0600 (CST) Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id g0SJBau15275; Mon, 28 Jan 2002 13:11:36 -0600 Subject: Re: IT'S A VIRUS - Re: new photos from my party! From: Steve Lord To: James Carrier Cc: linux-xfs@oss.sgi.com In-Reply-To: <5.1.0.14.2.20020128190840.00b0beb0@bunce.bitecomm.co.uk> References: <5.1.0.14.2.20020128190840.00b0beb0@bunce.bitecomm.co.uk> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/1.0.1 Date: 28 Jan 2002 13:11:36 -0600 Message-Id: <1012245096.15147.53.camel@jen.americas.sgi.com> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 435 Lines: 18 On Mon, 2002-01-28 at 13:09, James Carrier wrote: > As if I needed to tell you all :-) > > j. > > Yep, this one appears to have pushed through the mail filters on the list - I am being bombarded with stuff right now. I am trying to see if I can get the hole closed on this end. Steve -- Steve Lord voice: +1-651-683-3511 Principal Engineer, Filesystem Software email: lord@sgi.com From owner-linux-xfs@oss.sgi.com Mon Jan 28 12:21:11 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0SKLBp31304 for linux-xfs-outgoing; Mon, 28 Jan 2002 12:21:11 -0800 Received: from rj.sgi.com (rj.SGI.COM [204.94.215.100]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0SKL9P31281 for ; Mon, 28 Jan 2002 12:21:09 -0800 Received: from zeus-e8.americas.sgi.com (zeus-e8.americas.sgi.com [128.162.8.103]) by rj.sgi.com (8.11.4/8.11.4/linux-outbound_gateway-1.1) with ESMTP id g0SJL2Y32376 for ; Mon, 28 Jan 2002 11:21:02 -0800 Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by zeus-e8.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id NAA188423 for ; Mon, 28 Jan 2002 13:19:46 -0600 (CST) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id NAA21282 for ; Mon, 28 Jan 2002 13:19:46 -0600 (CST) Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id g0SJHxn15284; Mon, 28 Jan 2002 13:17:59 -0600 Subject: That Virus on the list From: Steve Lord To: linux-xfs@oss.sgi.com Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/1.0.1 Date: 28 Jan 2002 13:17:58 -0600 Message-Id: <1012245478.15147.63.camel@jen.americas.sgi.com> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 319 Lines: 11 So I got several hundred messages saying we sent out a virus, sorry about that, the sysadmin is off to go close the hole on oss so at least it will not happen again. Steve -- Steve Lord voice: +1-651-683-3511 Principal Engineer, Filesystem Software email: lord@sgi.com From owner-linux-xfs@oss.sgi.com Mon Jan 28 12:39:51 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0SKdpb01354 for linux-xfs-outgoing; Mon, 28 Jan 2002 12:39:51 -0800 Received: from sws5.ctd.ornl.gov (sws5.ctd.ornl.gov [160.91.20.105]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0SKdkP01327 for ; Mon, 28 Jan 2002 12:39:47 -0800 Received: (qmail 21933 invoked by uid 3995); 28 Jan 2002 19:39:44 -0000 Mail-Followup-To: linux-xfs@oss.sgi.com To: linux-xfs@oss.sgi.com Subject: Re: mkfs on large h/w RAID fails References: <1012238842.22013.8.camel@UberGeek> <1012242203.15145.3.camel@jen.americas.sgi.com> Date: 28 Jan 2002 14:39:44 -0500 In-Reply-To: <1012242203.15145.3.camel@jen.americas.sgi.com> Message-ID: User-Agent: Gnus/5.0808 (Gnus v5.8.8) XEmacs/21.4 (Academic Rigor) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii From: "Dave Sill" X-Delivery-Agent: TMDA/0.44 (Python 1.5.2; linux-i386) X-TMDA-Fingerprint: WQvJQcxNepEQStvcZCHiavJvJ70 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 1056 Lines: 29 [Please reply only to the mailing list.] Steve Lord wrote: > On Mon, 2002-01-28 at 12:00, Dave Sill wrote: > > Austin Gonyou writes: > > > > > can you try 2.4.14 or 2.4.17 and also upgrade to the new tools? > > > > Do I need the XFS kernel to run mkfs.xfs or can I just install the new > > tools? > > Any old kernel should do. Thought so. Unfortunately, I'm still seeing the same problem after installing xfsprogs-1.3.17: [root@malachite rpm]# mkfs.xfs -f /dev/sdb1 meta-data=/dev/sdb1 isize=256 agcount=224, agsize=1048576 blks data = bsize=4096 blocks=234870292, imaxpct=25 = sunit=0 swidth=0 blks, unwritten=0 naming =version 2 bsize=4096 log =internal log bsize=4096 blocks=28670 realtime =none extsz=65536 blocks=0, rtextents=0 mkfs.xfs: read failed: Input/output error mkfs.xfs: data size check failed mkfs.xfs: mount initialization failed [root@malachite rpm]# -Dave From owner-linux-xfs@oss.sgi.com Tue Jan 29 08:49:30 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0TGnU413637 for linux-xfs-outgoing; Tue, 29 Jan 2002 08:49:30 -0800 Received: from lips.thebarn.com (lips.borg.umn.edu [160.94.232.50]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0TGnRP13615 for ; Tue, 29 Jan 2002 08:49:28 -0800 Received: (from cattelan@localhost) by lips.thebarn.com (8.12.0/8.12.0) id g0TFpTpW012868 for linux-xfs@oss.sgi.com; Tue, 29 Jan 2002 09:51:29 -0600 (CST) Date: Tue, 29 Jan 2002 09:51:29 -0600 (CST) From: Russell Cattelan Message-Id: <200201291551.g0TFpTpW012868@lips.thebarn.com> Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 22 Lines: 2 list test ... ignore From owner-linux-xfs@oss.sgi.com Tue Jan 29 09:19:35 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0THJZ314404 for linux-xfs-outgoing; Tue, 29 Jan 2002 09:19:35 -0800 Received: from r63h110.res.gatech.edu (root@r63h110.res.gatech.edu [128.61.63.110]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0THJUP14372 for ; Tue, 29 Jan 2002 09:19:30 -0800 Received: (from nullset@localhost) by r63h110.res.gatech.edu (8.9.3/8.9.3) id LAA02400 for linux-xfs@oss.sgi.com; Tue, 29 Jan 2002 11:07:24 -0500 Date: Tue, 29 Jan 2002 11:07:22 -0500 From: Buddy Smith To: linux-xfs@oss.sgi.com Subject: 2.4.14-xfs and real-time subvolumes? Message-ID: <20020129110722.A2137@dookie.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 651 Lines: 21 Hi, I'm just curious as to whether real-time subvolumes are working on the latest release. I tried mkfs -r rtdev=/dev/hda3 /dev/hda4, where hda3 is a ~1GB partition, hda4 is ~26GB. When i try to mount either /dev/hda3 or /dev/hda4 (-o rtdev w/ hda4), i get a kernel oops. I'm also trying to figure out if i even need a real-time subvolume. I wanted to try it to see if i can squeeze a small amount of extra performance out of my disk solely for video capture. Should i not worry about it and just use XFS? just use ext2? I'm looking for suggestions here! :) Please CC: me on any responses, as I am not subscribed to this list. thanks, --buddy From owner-linux-xfs@oss.sgi.com Tue Jan 29 09:33:10 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0THXAQ14809 for linux-xfs-outgoing; Tue, 29 Jan 2002 09:33:10 -0800 Received: from rj.sgi.com (rj.SGI.COM [204.94.215.100]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0THX6P14756 for ; Tue, 29 Jan 2002 09:33:06 -0800 Received: from ledzep.americas.sgi.com (ledzep.americas.sgi.com [137.38.226.97]) by rj.sgi.com (8.11.4/8.11.4/linux-outbound_gateway-1.1) with ESMTP id g0TGWxY14542 for ; Tue, 29 Jan 2002 08:32:59 -0800 Received: from maine.americas.sgi.com (maine.americas.sgi.com [128.162.191.42]) by ledzep.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id KAA00614; Tue, 29 Jan 2002 10:31:42 -0600 (CST) Received: from nstraz by maine.americas.sgi.com with local (Exim 3.34 #1 (Debian)) id 16VbAc-00078j-00; Tue, 29 Jan 2002 10:31:42 -0600 Date: Tue, 29 Jan 2002 10:31:42 -0600 From: Nathan Straz To: Buddy Smith Cc: linux-xfs@oss.sgi.com Subject: Re: 2.4.14-xfs and real-time subvolumes? Message-ID: <20020129163141.GA23781@sgi.com> Mail-Followup-To: Buddy Smith , linux-xfs@oss.sgi.com References: <20020129110722.A2137@dookie.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20020129110722.A2137@dookie.net> User-Agent: Mutt/1.3.27i Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 1075 Lines: 26 On Tue, Jan 29, 2002 at 11:07:22AM -0500, Buddy Smith wrote: > I'm just curious as to whether real-time subvolumes are working on the > latest release. Testing realtime subvolumes is on my list of things to do. > I'm also trying to figure out if i even need a real-time subvolume. I > wanted to try it to see if i can squeeze a small amount of extra > performance out of my disk solely for video capture. To use realtime subvolumes, you need to call an ioctl after you open the file. This is tell XFS to write the the realtime subvolume instead of the regular data subvolumes. i.e. you'll probably need to make a change to your video capture app. > Should i not worry about it and just use XFS? just use ext2? I'm looking > for suggestions here! :) Test your application to see if XFS without realtime subvolumes gives you enough bandwidth. -- 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 Jan 29 09:36:14 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0THaE715024 for linux-xfs-outgoing; Tue, 29 Jan 2002 09:36:14 -0800 Received: from rj.sgi.com (rj.SGI.COM [204.94.215.100]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0THa9P15002 for ; Tue, 29 Jan 2002 09:36:09 -0800 Received: from zeus-e8.americas.sgi.com (zeus-e8.americas.sgi.com [128.162.8.103]) by rj.sgi.com (8.11.4/8.11.4/linux-outbound_gateway-1.1) with ESMTP id g0TGa2Y14903 for ; Tue, 29 Jan 2002 08:36:02 -0800 Received: from poppy-e185.americas.sgi.com (poppy-e185.americas.sgi.com [128.162.185.207]) by zeus-e8.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id KAA201057; Tue, 29 Jan 2002 10:34:47 -0600 (CST) Received: from stout.americas.sgi.com (stout.americas.sgi.com [128.162.187.5]) by poppy-e185.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.7) with ESMTP id KAA41773; Tue, 29 Jan 2002 10:34:46 -0600 (CST) Subject: Re: 2.4.14-xfs and real-time subvolumes? From: Eric Sandeen To: Buddy Smith Cc: linux-xfs@oss.sgi.com In-Reply-To: <20020129110722.A2137@dookie.net> References: <20020129110722.A2137@dookie.net> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/1.0 (Preview Release) Date: 29 Jan 2002 10:34:46 -0600 Message-Id: <1012322086.30169.9.camel@stout.americas.sgi.com> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 1214 Lines: 35 On Tue, 2002-01-29 at 10:07, Buddy Smith wrote: > Hi, > > I'm just curious as to whether real-time subvolumes are working on the > latest release. I tried mkfs -r rtdev=/dev/hda3 /dev/hda4, where hda3 is > a ~1GB partition, hda4 is ~26GB. > > When i try to mount either /dev/hda3 or /dev/hda4 (-o rtdev w/ hda4), i > get a kernel oops. Hi Buddy - RT subvolumes are "sort of" implemented, but not at all well tested. It's on the todo list. If you can run your oops through ksymoops it would be more helpful, or I'll test it out here when I get a moment. > I'm also trying to figure out if i even need a real-time subvolume. I > wanted to try it to see if i can squeeze a small amount of extra > performance out of my disk solely for video capture. > > Should i not worry about it and just use XFS? just use ext2? I'm looking > for suggestions here! :) XFS without RT has worked just fine for me for video capture (from a miniDV camera, to a 10k RPM scsi disk). I'd suggest a larger-than-normal log (mkfs option) and "logbufs=8" as a mount option. See if that will keep up with your needs... -Eric -- Eric Sandeen XFS for Linux http://oss.sgi.com/projects/xfs sandeen@sgi.com SGI, Inc. From owner-linux-xfs@oss.sgi.com Tue Jan 29 09:49:36 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0THnaa15591 for linux-xfs-outgoing; Tue, 29 Jan 2002 09:49:36 -0800 Received: from scare.vieo.com ([63.231.179.33]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0THnVP15505 for ; Tue, 29 Jan 2002 09:49:31 -0800 Received: from scare.vieo.com (localhost [127.0.0.1]) by scare.vieo.com (8.12.1/8.12.1) with ESMTP id g0TGcHKu003349 for ; Tue, 29 Jan 2002 10:38:17 -0600 Received: (from cattelan@localhost) by scare.vieo.com (8.12.1/8.12.1/Submit) id g0TGcGLe003348 for linux-xfs@oss.sgi.com; Tue, 29 Jan 2002 10:38:16 -0600 Message-Id: <200201291638.g0TGcGLe003348@scare.vieo.com> From: Keith Owens Subject: Re: XFS bug with ftruncate, mmap and holes. Date: Tue, 29 Jan 2002 08:02:49 +1100 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 372 Lines: 10 On 28 Jan 2002 10:52:15 -0600, Steve Lord wrote: >Can you please try the attached patch and see if it fixes your problems, >it makes the test program (unmodified) function for me (the data survives >unmount). Works for me. I backed out my XFS workaround patches to mdbm and the database now survives reboot, even with the non-standard truncate upwards. From owner-linux-xfs@oss.sgi.com Tue Jan 29 09:49:39 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0THndM15638 for linux-xfs-outgoing; Tue, 29 Jan 2002 09:49:39 -0800 Received: from scare.vieo.com ([63.231.179.33]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0THnVP15507 for ; Tue, 29 Jan 2002 09:49:31 -0800 Received: from scare.vieo.com (localhost [127.0.0.1]) by scare.vieo.com (8.12.1/8.12.1) with ESMTP id g0TGcHKu003353 for ; Tue, 29 Jan 2002 10:38:17 -0600 Received: (from cattelan@localhost) by scare.vieo.com (8.12.1/8.12.1/Submit) id g0TGcHg8003352 for linux-xfs@oss.sgi.com; Tue, 29 Jan 2002 10:38:17 -0600 Message-Id: <200201291638.g0TGcHg8003352@scare.vieo.com> Subject: Re: XFS bug with ftruncate, mmap and holes. From: Steve Lord Date: 28 Jan 2002 15:07:25 -0600 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 773 Lines: 22 On Mon, 2002-01-28 at 15:02, Keith Owens wrote: > On 28 Jan 2002 10:52:15 -0600, > Steve Lord wrote: > >Can you please try the attached patch and see if it fixes your problems, > >it makes the test program (unmodified) function for me (the data survives > >unmount). > > Works for me. I backed out my XFS workaround patches to mdbm and the > database now survives reboot, even with the non-standard truncate > upwards. Thanks Keith, now I need to figure out if I should just put this code in or clean up the code again..... probably both, too much going on right now in other places to do it all now. Steve -- Steve Lord voice: +1-651-683-3511 Principal Engineer, Filesystem Software email: lord@sgi.com From owner-linux-xfs@oss.sgi.com Tue Jan 29 09:49:41 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0THnf315710 for linux-xfs-outgoing; Tue, 29 Jan 2002 09:49:41 -0800 Received: from scare.vieo.com ([63.231.179.33]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0THnVP15504 for ; Tue, 29 Jan 2002 09:49:31 -0800 Received: from scare.vieo.com (localhost [127.0.0.1]) by scare.vieo.com (8.12.1/8.12.1) with ESMTP id g0TGcGKu003345 for ; Tue, 29 Jan 2002 10:38:16 -0600 Received: (from cattelan@localhost) by scare.vieo.com (8.12.1/8.12.1/Submit) id g0TGcGZj003344 for linux-xfs@oss.sgi.com; Tue, 29 Jan 2002 10:38:16 -0600 Message-Id: <200201291638.g0TGcGZj003344@scare.vieo.com> Subject: Re: mkfs on large h/w RAID fails Date: 28 Jan 2002 15:23:22 -0500 From: "Dave Sill" Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 731 Lines: 27 Steve Lord wrote: > OK, something is lying about the size of your device, it is coming in > at 234870292 4K blocks. The data size check failed means it attempted to > read the last block of the device and the read got an error. > > You could try > > mkfs -t xfs -f -d size=234870290b /dev/sdb1 Using a binary search, I found that the largest size that works is 201318712. > An strace -v output of the failure would also be useful It's 72k, so I'll send it to you off list. Also, fdisk says: Disk /dev/sdb: 255 heads, 63 sectors, 116960 cylinders Units = cylinders of 16065 * 512 bytes Device Boot Start End Blocks Id System /dev/sdb1 1 116960 939481168+ 83 Linux -Dave From owner-linux-xfs@oss.sgi.com Tue Jan 29 09:50:09 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0THo9c16312 for linux-xfs-outgoing; Tue, 29 Jan 2002 09:50:09 -0800 Received: from scare.vieo.com ([63.231.179.33]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0THnUP15500 for ; Tue, 29 Jan 2002 09:49:30 -0800 Received: from scare.vieo.com (localhost [127.0.0.1]) by scare.vieo.com (8.12.1/8.12.1) with ESMTP id g0TGcGKu003341 for ; Tue, 29 Jan 2002 10:38:16 -0600 Received: (from cattelan@localhost) by scare.vieo.com (8.12.1/8.12.1/Submit) id g0TGcGbY003340 for linux-xfs@oss.sgi.com; Tue, 29 Jan 2002 10:38:16 -0600 Message-Id: <200201291638.g0TGcGbY003340@scare.vieo.com> Subject: Re: mkfs on large h/w RAID fails From: Steve Lord Date: 28 Jan 2002 13:46:32 -0600 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 1717 Lines: 52 On Mon, 2002-01-28 at 13:39, Dave Sill wrote: > [Please reply only to the mailing list.] > > Steve Lord wrote: > > On Mon, 2002-01-28 at 12:00, Dave Sill wrote: > > > Austin Gonyou writes: > > > > > > > can you try 2.4.14 or 2.4.17 and also upgrade to the new tools? > > > > > > Do I need the XFS kernel to run mkfs.xfs or can I just install the new > > > tools? > > > > Any old kernel should do. > > Thought so. Unfortunately, I'm still seeing the same problem after > installing xfsprogs-1.3.17: > > [root@malachite rpm]# mkfs.xfs -f /dev/sdb1 > meta-data=/dev/sdb1 isize=256 agcount=224, agsize=1048576 blks > data = bsize=4096 blocks=234870292, imaxpct=25 > = sunit=0 swidth=0 blks, unwritten=0 > naming =version 2 bsize=4096 > log =internal log bsize=4096 blocks=28670 > realtime =none extsz=65536 blocks=0, rtextents=0 > mkfs.xfs: read failed: Input/output error > mkfs.xfs: data size check failed > mkfs.xfs: mount initialization failed > [root@malachite rpm]# OK, something is lying about the size of your device, it is coming in at 234870292 4K blocks. The data size check failed means it attempted to read the last block of the device and the read got an error. You could try mkfs -t xfs -f -d size=234870290b /dev/sdb1 or some other number smaller than the actual device size and see if that works. An strace -v output of the failure would also be useful Steve > > -Dave -- Steve Lord voice: +1-651-683-3511 Principal Engineer, Filesystem Software email: lord@sgi.com From owner-linux-xfs@oss.sgi.com Tue Jan 29 09:50:02 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0THo2716224 for linux-xfs-outgoing; Tue, 29 Jan 2002 09:50:02 -0800 Received: from scare.vieo.com ([63.231.179.33]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0THndP15614 for ; Tue, 29 Jan 2002 09:49:39 -0800 Received: from scare.vieo.com (localhost [127.0.0.1]) by scare.vieo.com (8.12.1/8.12.1) with ESMTP id g0TGcOKu003367 for ; Tue, 29 Jan 2002 10:38:24 -0600 Received: (from cattelan@localhost) by scare.vieo.com (8.12.1/8.12.1/Submit) id g0TGcOQw003366 for linux-xfs@oss.sgi.com; Tue, 29 Jan 2002 10:38:24 -0600 Message-Id: <200201291638.g0TGcOQw003366@scare.vieo.com> Date: Mon, 28 Jan 2002 17:38:02 -0500 From: "Bryan J. Smith" Subject: Re: ScanMail Message: To Recipient virus found or matched file blocking setting. Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 560 Lines: 17 System Attendant wrote: > ScanMail for Microsoft Exchange has taken action on the message, > please refer to the contents of this message for further details. You gotta love Microsoft crap. They have no concept of "bulk E-mail" nor do they understand half of the other RFC822 fields. I take it most everything else when to just the admin, right? -- Bryan -- Bryan J. Smith mailto:b.j.smith@ieee.org chat:thebs413 Engineer AbsoluteValue Systems, Inc. http://www.linux-wlan.org President SmithConcepts, Inc. http://www.SmithConcepts.com From owner-linux-xfs@oss.sgi.com Tue Jan 29 09:50:45 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0THojw16556 for linux-xfs-outgoing; Tue, 29 Jan 2002 09:50:45 -0800 Received: from scare.vieo.com ([63.231.179.33]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0THnkP15828 for ; Tue, 29 Jan 2002 09:49:46 -0800 Received: from scare.vieo.com (localhost [127.0.0.1]) by scare.vieo.com (8.12.1/8.12.1) with ESMTP id g0TGcVKu003391 for ; Tue, 29 Jan 2002 10:38:31 -0600 Received: (from cattelan@localhost) by scare.vieo.com (8.12.1/8.12.1/Submit) id g0TGcVOE003390 for linux-xfs@oss.sgi.com; Tue, 29 Jan 2002 10:38:31 -0600 Message-Id: <200201291638.g0TGcVOE003390@scare.vieo.com> Date: Tue, 29 Jan 2002 12:07:32 +1100 From: Nathan Scott Subject: Re: mkfs on large h/w RAID fails Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 1932 Lines: 60 hi, On Mon, Jan 28, 2002 at 12:02:59PM -0500, Dave Sill wrote: > I've got a terabyte RAID that I'm trying to set up as a single XFS > filesystem. mkfs fails with: > > [root@malachite root]# mkfs.xfs -f /dev/sdb1 > meta-data=/dev/sdb1 isize=256 agcount=224, agsize=1048576 blks > data = bsize=4096 blocks=234870292, imaxpct=25 > = sunit=0 swidth=0 blks, unwritten=0 > = imaxbits=32 > naming =version 2 bsize=4096 > log =internal log bsize=4096 blocks=28670 > realtime =none extsz=65536 blocks=0, rtextents=0 > mkfs.xfs: read failed: Input/output error > mkfs.xfs: data size check failed > mkfs.xfs: mount initialization failed > [root@malachite root]# Basically, what happens here is mkfs.xfs asks the device how big it is (using the BLKGETSIZE ioctl) and before starting to write to the disk, mkfs seeks to 4K from the end of the device and issues a read (to validate the size which the device driver gave it). It looks like for your terabyte RAID, this read is failing (the driver is giving EIO), hence the message "data size check failed". mkfs.xfs will refuse to run on a device which exhibits this anti- social behavior. > I had no problems mkfs'ing it as e2fs, e3fs, and reiserfs. These programs are not doing this lseek/read check to validate the size of the device. > I'm running under the 1.02a installer on an Athlon: > > [root@malachite root]# uname -a > Linux malachite 2.4.9-13SGI_XFS_1.0.2 #1 Thu Nov 15 14:28:44 CST 2001 i686 unknown > [root@malachite root]# > > I installed the xfs programs from the RPM: > > xfsprogs-1.3.13-0.i386.rpm > > Any ideas? > Your terabyte RAID device driver seems to have a bug in either the code which reports its size, or in reading near the end of the device. Hope this helps. cheers. -- Nathan From owner-linux-xfs@oss.sgi.com Tue Jan 29 09:50:35 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0THoZX16502 for linux-xfs-outgoing; Tue, 29 Jan 2002 09:50:35 -0800 Received: from scare.vieo.com ([63.231.179.33]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0THo1P16215 for ; Tue, 29 Jan 2002 09:50:01 -0800 Received: from scare.vieo.com (localhost [127.0.0.1]) by scare.vieo.com (8.12.1/8.12.1) with ESMTP id g0TGcgKu003437 for ; Tue, 29 Jan 2002 10:38:42 -0600 Received: (from cattelan@localhost) by scare.vieo.com (8.12.1/8.12.1/Submit) id g0TGcgBf003436 for linux-xfs@oss.sgi.com; Tue, 29 Jan 2002 10:38:42 -0600 Message-Id: <200201291638.g0TGcgBf003436@scare.vieo.com> Date: Tue, 29 Jan 2002 17:39:20 +0200 From: henka Subject: Excellent job SGI Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 755 Lines: 19 I have to congratulate SGI on a bloody excellent product. XFS has really delivered (and saved data on two occasions already - and that after only 3 weeks of use) as expected. We considered using reiserfs, but decided against it after doing searches at google.com to see what the 'hit-rate' was regarding problems, stability, etc. We have nothing against reiserfs per se (if we didn't have XFS as a choice, it would have been reiserfs by default), but XFS has been around for some time and is in use world-wide (and we had experience with it on SGI servers). We look forward to the day when it's an integral part of the kernel and not a seperate patch. Brilliant job and thanks for contributing it to open source. Henry Combrinck www.metroweb.co.za From owner-linux-xfs@oss.sgi.com Tue Jan 29 09:50:48 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0THoma16572 for linux-xfs-outgoing; Tue, 29 Jan 2002 09:50:48 -0800 Received: from scare.vieo.com ([63.231.179.33]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0THnmP15902 for ; Tue, 29 Jan 2002 09:49:48 -0800 Received: from scare.vieo.com (localhost [127.0.0.1]) by scare.vieo.com (8.12.1/8.12.1) with ESMTP id g0TGcXKu003416 for ; Tue, 29 Jan 2002 10:38:33 -0600 Received: (from cattelan@localhost) by scare.vieo.com (8.12.1/8.12.1/Submit) id g0TGcXl1003415 for linux-xfs@oss.sgi.com; Tue, 29 Jan 2002 10:38:33 -0600 Message-Id: <200201291638.g0TGcXl1003415@scare.vieo.com> From: "Chris Pascoe" Subject: How long should an xfs_freeze take? Date: Tue, 29 Jan 2002 15:26:30 +1000 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 2891 Lines: 73 Hi, I'm guessing an xfs_freeze shouldn't take this long, am I correct? # time xfs_freeze -f /tst1 real 344m40.434s user 0m0.000s sys 340m40.810s The system is a Dual CPU P3 Xeon with 1GB RAM (highmem enabled), running 2.4.17 CVS, taken on 2002/01/23 (just before the -funsigned-char changes went through), with LVM 1.0.2 added (I see the same behaviour with 1.0.1, though). During the time that passed I broke into kdb a dozen or so times - often the running process on one CPU was the automounter: 0xf71d2000 00000604 00000001 1 001 run 0xf71d2370*automount [0]kdb> btp 604 EBP EIP Function(args) 0xc0252221 stext_lock+0x2fcd kernel .text.lock 0xc024f254 0xc024f254 0xc02576c0 0xf71d2000 0xc01447d2 sys_ioctl+0x42 (0x5, 0x810c9365, 0xbffff7b0, 0xbffffae0, 0x4) kernel .text 0xc0100000 0xc0144790 0xc01449d0 0xc010713b system_call+0x33 kernel .text 0xc0100000 0xc0107108 0xc0107140 whilst the rest of the time it was the xfs_freeze process, sample backtrace: 0xe95c2000 00001062 00000904 1 000 run 0xe95c2370*xfs_freeze Entering kdb (current=0xe95c2000, pid 1062) on processor 0 due to Keyboard Entry [0]kdb> bt EBP EIP Function(args) 0xe95c3b4c 0xc01cb1a7 vn_count+0xb (0xf3d0bcc0, 0xf7e89560, 0xf6d1f000, 0xf6d1f000, 0xf6d1f118) kernel .text 0xc0100000 0xc01cb19c 0xc01cb1ac 0xe95c3b88 0xc01a19f6 xfs_iflush_all+0x56 (0xf6d1f000, 0x1, 0xf6d1f000, 0xc, 0xc039ce80) kernel .text 0xc0100000 0xc01a19a0 0xc01a1b1c 0xe95c3bb8 0xc01995f0 xfs_fs_freeze+0x38 (0xf6d1f000, 0xbffffbac, 0xf6d094a0, 0xf6d095c0, 0x18) kernel .text 0xc0100000 0xc01995b8 0xc0199670 0xe95c3f54 0xc01c5104 xfs_ioctl+0x1650 (0xe95c3c18, 0x2, 0x3b0, 0xec, 0xec) kernel .text 0xc0100000 0xc01c3ab4 0xc01c51f0 0xc010722c error_code+0x34 kernel .text 0xc0100000 0xc01071f8 0xc0107234 Interrupt registers: eax = 0x08049c50 ebx = 0xe95c3c18 ecx = 0x00000002 edx = 0x000003b0 esi = 0x000000ec edi = 0x000000ec esp = 0x00000010 eip = 0xf6d095c0 ebp = 0x00000000 xss = 0x00010246 xcs = 0xffffffff eflags = 0xc02475db xds = 0xe95c3c5c xes = 0xf6d1f000 origeax = 0xf6cfcb38 ®s = 0xe95c3c10 Interrupt from user space, end of kernel trace Alternatively, I'd see a slightly different location in vn_count: Entering kdb (current=0xe95c2000, pid 1062) on processor 0 due to Keyboard Entry [0]kdb> bt EBP EIP Function(args) 0xe95c3b88 0xc01cb1ab vn_count+0xf (0xe9e811e0, 0xf7e89560, 0xf6d1f000, 0xf6d1f000, 0xf6d1f118) kernel .text 0xc0100000 0xc01cb19c 0xc01cb1ac Anything that I should try to help figure out what's going on? Chris From owner-linux-xfs@oss.sgi.com Tue Jan 29 09:50:33 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0THoXY16483 for linux-xfs-outgoing; Tue, 29 Jan 2002 09:50:33 -0800 Received: from scare.vieo.com ([63.231.179.33]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0THneP15672 for ; Tue, 29 Jan 2002 09:49:40 -0800 Received: from scare.vieo.com (localhost [127.0.0.1]) by scare.vieo.com (8.12.1/8.12.1) with ESMTP id g0TGcQKu003379 for ; Tue, 29 Jan 2002 10:38:26 -0600 Received: (from cattelan@localhost) by scare.vieo.com (8.12.1/8.12.1/Submit) id g0TGcQR5003378 for linux-xfs@oss.sgi.com; Tue, 29 Jan 2002 10:38:26 -0600 Message-Id: <200201291638.g0TGcQR5003378@scare.vieo.com> Subject: Re: XFS bug with ftruncate, mmap and holes. From: Steve Lord Date: 28 Jan 2002 16:58:32 -0600 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 1305 Lines: 38 On Mon, 2002-01-28 at 16:49, Andrew Morton wrote: > Ethan Benson wrote: > > > > someone i was talking to recently has been using the 2.4.17 xfs > > patches with 2.4.18pre kernels and found apt-get failed due to errors > > returned by msync() (which appears to be returning 1 (not -1)). > > msync is involved in writing these apt binary cache files. > > > > Interesting. > > In 2.4.18-pre3 I changed msync. Previously, it was ignoring things > like EIO and ENOSPC on writepage() operations. The change was to > correctly propagate these error codes all the way back to the > caller, all over the place. > > The raw diff is at > http://www.zip.com.au/~akpm/linux/2.4/2.4.18-pre3/msync-ret.patch > > If someone is returning `1' from msync() then probably an > underlying filesystem is returning `1' from its get_block() > or writepage() method. It shouldn't. It should return > either zero or a negative errno. Bingo, there used to be some code where we did return a value to indicate how much got flushed when we did a clustered write, I don't think we use that anymore. So I will go revert the writepage output to what it should be. Thanks, Steve -- Steve Lord voice: +1-651-683-3511 Principal Engineer, Filesystem Software email: lord@sgi.com From owner-linux-xfs@oss.sgi.com Tue Jan 29 09:50:16 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0THoGn16368 for linux-xfs-outgoing; Tue, 29 Jan 2002 09:50:16 -0800 Received: from scare.vieo.com ([63.231.179.33]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0THneP15666 for ; Tue, 29 Jan 2002 09:49:40 -0800 Received: from scare.vieo.com (localhost [127.0.0.1]) by scare.vieo.com (8.12.1/8.12.1) with ESMTP id g0TGcPKu003375 for ; Tue, 29 Jan 2002 10:38:25 -0600 Received: (from cattelan@localhost) by scare.vieo.com (8.12.1/8.12.1/Submit) id g0TGcPh5003374 for linux-xfs@oss.sgi.com; Tue, 29 Jan 2002 10:38:25 -0600 Message-Id: <200201291638.g0TGcPh5003374@scare.vieo.com> Date: Mon, 28 Jan 2002 14:49:13 -0800 From: Andrew Morton Subject: Re: XFS bug with ftruncate, mmap and holes. Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 825 Lines: 23 Ethan Benson wrote: > > someone i was talking to recently has been using the 2.4.17 xfs > patches with 2.4.18pre kernels and found apt-get failed due to errors > returned by msync() (which appears to be returning 1 (not -1)). > msync is involved in writing these apt binary cache files. > Interesting. In 2.4.18-pre3 I changed msync. Previously, it was ignoring things like EIO and ENOSPC on writepage() operations. The change was to correctly propagate these error codes all the way back to the caller, all over the place. The raw diff is at http://www.zip.com.au/~akpm/linux/2.4/2.4.18-pre3/msync-ret.patch If someone is returning `1' from msync() then probably an underlying filesystem is returning `1' from its get_block() or writepage() method. It shouldn't. It should return either zero or a negative errno. From owner-linux-xfs@oss.sgi.com Tue Jan 29 09:50:12 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0THoCp16341 for linux-xfs-outgoing; Tue, 29 Jan 2002 09:50:12 -0800 Received: from scare.vieo.com ([63.231.179.33]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0THncP15606 for ; Tue, 29 Jan 2002 09:49:38 -0800 Received: from scare.vieo.com (localhost [127.0.0.1]) by scare.vieo.com (8.12.1/8.12.1) with ESMTP id g0TGcHKu003357 for ; Tue, 29 Jan 2002 10:38:17 -0600 Received: (from cattelan@localhost) by scare.vieo.com (8.12.1/8.12.1/Submit) id g0TGcHhN003356 for linux-xfs@oss.sgi.com; Tue, 29 Jan 2002 10:38:17 -0600 Message-Id: <200201291638.g0TGcHhN003356@scare.vieo.com> Date: Mon, 28 Jan 2002 22:37:27 +0100 From: Wessel Dankers Subject: Re: mkfs on large h/w RAID fails Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 287 Lines: 13 On 2002-01-28 14:39:44-0500, Dave Sill wrote: > Thought so. Unfortunately, I'm still seeing the same problem after > installing xfsprogs-1.3.17: > mkfs.xfs: read failed: Input/output error Does your kernel log anything? -- Wessel Dankers system has been recalled From owner-linux-xfs@oss.sgi.com Tue Jan 29 09:50:19 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0THoJV16391 for linux-xfs-outgoing; Tue, 29 Jan 2002 09:50:19 -0800 Received: from scare.vieo.com ([63.231.179.33]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0THo2P16222 for ; Tue, 29 Jan 2002 09:50:02 -0800 Received: from scare.vieo.com (localhost [127.0.0.1]) by scare.vieo.com (8.12.1/8.12.1) with ESMTP id g0TGclKu003441 for ; Tue, 29 Jan 2002 10:38:47 -0600 Received: (from cattelan@localhost) by scare.vieo.com (8.12.1/8.12.1/Submit) id g0TGclX6003440 for linux-xfs@oss.sgi.com; Tue, 29 Jan 2002 10:38:47 -0600 Message-Id: <200201291638.g0TGclX6003440@scare.vieo.com> Date: Tue, 29 Jan 2002 09:49:31 -0600 (CST) From: Russell Cattelan Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 22 Lines: 2 list test ... ignore From owner-linux-xfs@oss.sgi.com Tue Jan 29 09:50:31 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0THoVJ16471 for linux-xfs-outgoing; Tue, 29 Jan 2002 09:50:31 -0800 Received: from scare.vieo.com ([63.231.179.33]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0THnoP15989 for ; Tue, 29 Jan 2002 09:49:50 -0800 Received: from scare.vieo.com (localhost [127.0.0.1]) by scare.vieo.com (8.12.1/8.12.1) with ESMTP id g0TGcYKu003424 for ; Tue, 29 Jan 2002 10:38:34 -0600 Received: (from cattelan@localhost) by scare.vieo.com (8.12.1/8.12.1/Submit) id g0TGcYX7003423 for linux-xfs@oss.sgi.com; Tue, 29 Jan 2002 10:38:34 -0600 Message-Id: <200201291638.g0TGcYX7003423@scare.vieo.com> From: "Ralf G. R. Bergs" Date: Tue, 29 Jan 2002 09:12:36 +0100 Subject: Re: Reduce XFS footprint (was Re: TAKE - remove a function xfs added to filemap.c Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 850 Lines: 21 On Tue, 29 Jan 2002 12:53:54 +1100, Nathan Scott wrote: [...] >Another thing we could try is to make support for v1 dirs >compile-time conditional (since noone/very few people will >be using this), this might save a bit more space. I think >the code is all accessed via function pointers already, so >the points of abstraction should be clearly defined. I don't think that it's worth that you waste your time with this. I just thought I was using "wrong" options or something like that to compile XFS, or that there was a "plug'n'go" way of shrinking it. :-) -- Verkaufe Original-BMW-Raeder: L I N U X .~. http://adsl-bergs.rz.rwth-aachen.de/~rabe The Choice /V\ of a GNU /( )\ Generation ^^-^^ From owner-linux-xfs@oss.sgi.com Tue Jan 29 09:50:32 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0THoWs16477 for linux-xfs-outgoing; Tue, 29 Jan 2002 09:50:32 -0800 Received: from scare.vieo.com ([63.231.179.33]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0THnlP15853 for ; Tue, 29 Jan 2002 09:49:47 -0800 Received: from scare.vieo.com (localhost [127.0.0.1]) by scare.vieo.com (8.12.1/8.12.1) with ESMTP id g0TGcWKu003408 for ; Tue, 29 Jan 2002 10:38:32 -0600 Received: (from cattelan@localhost) by scare.vieo.com (8.12.1/8.12.1/Submit) id g0TGcWBk003406 for linux-xfs@oss.sgi.com; Tue, 29 Jan 2002 10:38:32 -0600 Message-Id: <200201291638.g0TGcWBk003406@scare.vieo.com> Date: Tue, 29 Jan 2002 16:02:34 +1100 From: Nathan Scott Subject: Re: extended attributes support on powerpc Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 932 Lines: 27 On Mon, Jan 28, 2002 at 03:03:11PM +1100, Keith Owens wrote: > On Sun, 27 Jan 2002 18:47:24 -0900, > Ethan Benson wrote: > >i assume the numbering doesn't affect userland at all, its only used > >for internal compilation of the kernel correct? > > The syscall numbers are also used by the ACL programs. In XFS CVS > theye are in cmd/attr/libattr/attr.c at line 292. Forgot about those, > I don't work on the user space commands. > The ACL userspace will also need updating - see the end of cmd/acl/libacl/acl.c In terms of including these changes, we're looking at ways to consolidate the different ACL/EA userspace packages at the moment (between XFS and ext2/3) and these syscalls will likely be reworked at some point in the future, so I'm a bit hesitant to go extending this code to new platforms in the interim (would equate to more places where it may break down the track). cheers. -- Nathan From owner-linux-xfs@oss.sgi.com Tue Jan 29 10:46:37 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0THoR416454 for linux-xfs-outgoing; Tue, 29 Jan 2002 09:50:27 -0800 Received: from scare.vieo.com ([63.231.179.33]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0THnuP16136 for ; Tue, 29 Jan 2002 09:49:57 -0800 Received: from scare.vieo.com (localhost [127.0.0.1]) by scare.vieo.com (8.12.1/8.12.1) with ESMTP id g0TGcfKu003433 for ; Tue, 29 Jan 2002 10:38:42 -0600 Received: (from cattelan@localhost) by scare.vieo.com (8.12.1/8.12.1/Submit) id g0TGcf3I003432 for linux-xfs@oss.sgi.com; Tue, 29 Jan 2002 10:38:41 -0600 Message-Id: <200201291638.g0TGcf3I003432@scare.vieo.com> Date: Tue, 29 Jan 2002 15:04:36 +0100 From: Wessel Dankers Subject: Sharing a log Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 216 Lines: 13 oi, Quick question (sorry if I missed it in the FAQ): Can XFS share a log partition between XFS partitions? Regards, -- Wessel Dankers Your parity check is overdrawn and you're out of cache. From owner-linux-xfs@oss.sgi.com Tue Jan 29 10:46:38 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0THoNW16424 for linux-xfs-outgoing; Tue, 29 Jan 2002 09:50:23 -0800 Received: from scare.vieo.com ([63.231.179.33]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0THnlP15854 for ; Tue, 29 Jan 2002 09:49:47 -0800 Received: from scare.vieo.com (localhost [127.0.0.1]) by scare.vieo.com (8.12.1/8.12.1) with ESMTP id g0TGcXKu003412 for ; Tue, 29 Jan 2002 10:38:33 -0600 Received: (from cattelan@localhost) by scare.vieo.com (8.12.1/8.12.1/Submit) id g0TGcXWt003411 for linux-xfs@oss.sgi.com; Tue, 29 Jan 2002 10:38:33 -0600 Message-Id: <200201291638.g0TGcXWt003411@scare.vieo.com> Subject: Re: NFS and XFS From: Florin Andrei Date: 28 Jan 2002 21:16:21 -0800 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 401 Lines: 15 On Fri, 2002-01-25 at 19:25, Zhifeng F. Chen wrote: > > version 3 on 2.4 kernels, ... " Could anyone tell me if XFS works correctly > with NFS ? Not only works, but is in fact one of the finest choices for a NFS server. ;-) -- Florin Andrei "The security of any corporate network is inversely proportional to the number of systems administrators on the network." - - Petreley's law of sysadmins From owner-linux-xfs@oss.sgi.com Tue Jan 29 10:46:42 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0THoPo16443 for linux-xfs-outgoing; Tue, 29 Jan 2002 09:50:25 -0800 Received: from scare.vieo.com ([63.231.179.33]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0THnuP16130 for ; Tue, 29 Jan 2002 09:49:56 -0800 Received: from scare.vieo.com (localhost [127.0.0.1]) by scare.vieo.com (8.12.1/8.12.1) with ESMTP id g0TGcZKu003429 for ; Tue, 29 Jan 2002 10:38:35 -0600 Received: (from cattelan@localhost) by scare.vieo.com (8.12.1/8.12.1/Submit) id g0TGcZ2t003428 for linux-xfs@oss.sgi.com; Tue, 29 Jan 2002 10:38:35 -0600 Message-Id: <200201291638.g0TGcZ2t003428@scare.vieo.com> Subject: Which gcc ? From: Vincent Bernat Date: Tue, 29 Jan 2002 10:59:39 +0100 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 443 Lines: 14 Hello ! It seems that the official gcc for the kernel is now 2.95.3 : http://www.atnf.csiro.au/~rgooch/linux/docs/kernel-newsflash.html/ However, on lkml, some people seem to prefer 2.96 from Redhat (latest version). And the XFS project seems to recommend egcs-1.1.2. WHat is the best choice now ? egcs, 2.95.3 or 2.96 from Redhat ? -- Document your data layouts. - The Elements of Programming Style (Kernighan & Plaugher) From owner-linux-xfs@oss.sgi.com Tue Jan 29 10:49:05 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0THoda16535 for linux-xfs-outgoing; Tue, 29 Jan 2002 09:50:39 -0800 Received: from scare.vieo.com ([63.231.179.33]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0THnkP15836 for ; Tue, 29 Jan 2002 09:49:46 -0800 Received: from scare.vieo.com (localhost [127.0.0.1]) by scare.vieo.com (8.12.1/8.12.1) with ESMTP id g0TGcWKu003399 for ; Tue, 29 Jan 2002 10:38:32 -0600 Received: (from cattelan@localhost) by scare.vieo.com (8.12.1/8.12.1/Submit) id g0TGcW5P003398 for linux-xfs@oss.sgi.com; Tue, 29 Jan 2002 10:38:32 -0600 Message-Id: <200201291638.g0TGcW5P003398@scare.vieo.com> Date: Tue, 29 Jan 2002 12:53:54 +1100 From: Nathan Scott Subject: Re: Reduce XFS footprint (was Re: TAKE - remove a function xfs added to filemap.c Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 1102 Lines: 38 On Sat, Jan 26, 2002 at 01:59:15PM -0600, Stephen Lord wrote: > Ralf G. R. Bergs wrote: > > >>You could try editing xfs_types.h and changing > ... > It does compile and run, and you save about 45K in code size by doing it, > so not too much. You can also edit xfs_macros.h and define WANT_SPACE_C > to 1 (replace the existing definition). This turns a lot of inline > macros into > function calls - it will be slower, but it is another 10K less code - > again, not > very much. > Another thing we could try is to make support for v1 dirs compile-time conditional (since noone/very few people will be using this), this might save a bit more space. I think the code is all accessed via function pointers already, so the points of abstraction should be clearly defined. > So and smp build (in 2.5) went from > > text data bss dec hex filename > 520994 4896 2080 527970 80e62 fs/xfs/xfs.o > > to > text data bss dec hex filename > 487334 4896 2080 494310 78ae6 fs/xfs/xfs.o > > with these two build changes. > > Steve > > -- Nathan From owner-linux-xfs@oss.sgi.com Tue Jan 29 10:49:05 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0THoXc16492 for linux-xfs-outgoing; Tue, 29 Jan 2002 09:50:33 -0800 Received: from scare.vieo.com ([63.231.179.33]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0THnkP15825 for ; Tue, 29 Jan 2002 09:49:46 -0800 Received: from scare.vieo.com (localhost [127.0.0.1]) by scare.vieo.com (8.12.1/8.12.1) with ESMTP id g0TGcVKu003387 for ; Tue, 29 Jan 2002 10:38:31 -0600 Received: (from cattelan@localhost) by scare.vieo.com (8.12.1/8.12.1/Submit) id g0TGcV7W003386 for linux-xfs@oss.sgi.com; Tue, 29 Jan 2002 10:38:31 -0600 Message-Id: <200201291638.g0TGcV7W003386@scare.vieo.com> Date: Tue, 29 Jan 2002 11:55:57 +1100 From: Nathan Scott Subject: Re: double mounting and other strangeness. Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 1183 Lines: 31 hi, On Sun, Jan 27, 2002 at 12:19:47AM -0600, pac@fortuitous.com wrote: > ... > Linux bart.marx 2.4.17-preempt-fspatch-alsa #1 Fri Jan 25 21:45:36 CST 2002 i686 unknown > ... > > I also get some errors when I try to make a new xfs filesystem on either > /dev/hda10 and /dev/hda9: > ------------------------------------------------------------------------ > mkfs.xfs -f /dev/hda10 > mkfs.xfs: warning - cannot set blocksize on block device /dev/hda10: Input/output error > meta-data=/dev/hda10 isize=256 agcount=8, agsize=16064 blks > data = bsize=4096 blocks=128512, imaxpct=25 > = sunit=0 swidth=0 blks, unwritten=0 > naming =version 2 bsize=4096 > log =internal log bsize=4096 blocks=1200 > realtime =none extsz=65536 blocks=0, rtextents=0 > ------------------------------------------------------------------ > The device driver you're using (for /dev/hda10) doesn't support the BLKBSZSET ioctl. This ioctl was introduced in 2.4.10-pre3 & should be supported now - so this is a device driver problem, not an XFS problem. cheers. -- Nathan From owner-linux-xfs@oss.sgi.com Tue Jan 29 10:49:46 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0THoel16545 for linux-xfs-outgoing; Tue, 29 Jan 2002 09:50:40 -0800 Received: from scare.vieo.com ([63.231.179.33]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0THnnP15964 for ; Tue, 29 Jan 2002 09:49:49 -0800 Received: from scare.vieo.com (localhost [127.0.0.1]) by scare.vieo.com (8.12.1/8.12.1) with ESMTP id g0TGcXKu003420 for ; Tue, 29 Jan 2002 10:38:33 -0600 Received: (from cattelan@localhost) by scare.vieo.com (8.12.1/8.12.1/Submit) id g0TGcXLX003419 for linux-xfs@oss.sgi.com; Tue, 29 Jan 2002 10:38:33 -0600 Message-Id: <200201291638.g0TGcXLX003419@scare.vieo.com> Date: Tue, 29 Jan 2002 09:00:48 +0100 From: Simon Matter Subject: Re: mkfs on large h/w RAID fails Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 1338 Lines: 40 Dave Sill schrieb: > [Please reply only to the mailing list.] > > Steve Lord wrote: > > On Mon, 2002-01-28 at 12:00, Dave Sill wrote: > > > Austin Gonyou writes: > > > > > > > can you try 2.4.14 or 2.4.17 and also upgrade to the new tools? > > > > > > Do I need the XFS kernel to run mkfs.xfs or can I just install the new > > > tools? > > > > Any old kernel should do. > > Thought so. Unfortunately, I'm still seeing the same problem after > installing xfsprogs-1.3.17: > > [root@malachite rpm]# mkfs.xfs -f /dev/sdb1 > meta-data=/dev/sdb1 isize=256 agcount=224, agsize=1048576 blks > data = bsize=4096 blocks=234870292, imaxpct=25 > = sunit=0 swidth=0 blks, unwritten=0 > naming =version 2 bsize=4096 > log =internal log bsize=4096 blocks=28670 > realtime =none extsz=65536 blocks=0, rtextents=0 > mkfs.xfs: read failed: Input/output error > mkfs.xfs: data size check failed > mkfs.xfs: mount initialization failed > [root@malachite rpm]# The message says 'data size check failed', can to try to specify data size by hand and maybe other parameters too. I guess the size detection algorythm ran into a problem with your tera size partition. -Simon > > > -Dave From owner-linux-xfs@oss.sgi.com Tue Jan 29 10:50:02 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0THocu16530 for linux-xfs-outgoing; Tue, 29 Jan 2002 09:50:38 -0800 Received: from scare.vieo.com ([63.231.179.33]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0THnkP15831 for ; Tue, 29 Jan 2002 09:49:46 -0800 Received: from scare.vieo.com (localhost [127.0.0.1]) by scare.vieo.com (8.12.1/8.12.1) with ESMTP id g0TGcWKu003395 for ; Tue, 29 Jan 2002 10:38:32 -0600 Received: (from cattelan@localhost) by scare.vieo.com (8.12.1/8.12.1/Submit) id g0TGcWpl003394 for linux-xfs@oss.sgi.com; Tue, 29 Jan 2002 10:38:32 -0600 Message-Id: <200201291638.g0TGcWpl003394@scare.vieo.com> Date: Mon, 28 Jan 2002 19:11:49 -0600 (CST) From: Eric Sandeen Subject: Re: mkfs on large h/w RAID fails Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 1429 Lines: 38 Hi Dave - Can you run this through strace, to see where things go wrong? All mkfs.xfs is doing when it failes, is trying to read the last block on the device. Since I don't have 1T laying around, I tried it on a file: [root@lite sda2]# mkfs.xfs -d file,name=new-filesystem,size=234870292b meta-data=new-filesystem isize=256 agcount=224, agsize=1048576 blks data = bsize=4096 blocks=234870292, imaxpct=25 = sunit=0 swidth=0 blks, unwritten=0 naming =version 2 bsize=4096 log =internal log bsize=4096 blocks=28670 realtime =none extsz=65536 blocks=0, rtextents=0 it also works via the loop device (so mkfs.xfs thinks it's talking to a real device): [root@lite sda2]# losetup /dev/loop0 new-filesystem [root@lite sda2]# mkfs.xfs -f /dev/loop0 Invalid argument meta-data=/dev/loop0 isize=256 agcount=224, agsize=1048576 blks data = bsize=4096 blocks=234870292, imaxpct=25 = sunit=0 swidth=0 blks, unwritten=0 naming =version 2 bsize=4096 log =internal log bsize=4096 blocks=28670 realtime =none extsz=65536 blocks=0, rtextents=0 -Eric On 28 Jan 2002, Dave Sill wrote: > Thought so. Unfortunately, I'm still seeing the same problem after > installing xfsprogs-1.3.17: From owner-linux-xfs@oss.sgi.com Tue Jan 29 10:50:11 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0THoax16515 for linux-xfs-outgoing; Tue, 29 Jan 2002 09:50:36 -0800 Received: from scare.vieo.com ([63.231.179.33]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0THndP15616 for ; Tue, 29 Jan 2002 09:49:39 -0800 Received: from scare.vieo.com (localhost [127.0.0.1]) by scare.vieo.com (8.12.1/8.12.1) with ESMTP id g0TGcOKu003371 for ; Tue, 29 Jan 2002 10:38:24 -0600 Received: (from cattelan@localhost) by scare.vieo.com (8.12.1/8.12.1/Submit) id g0TGcOHN003370 for linux-xfs@oss.sgi.com; Tue, 29 Jan 2002 10:38:24 -0600 Message-Id: <200201291638.g0TGcOHN003370@scare.vieo.com> Date: Mon, 28 Jan 2002 14:52:58 -0800 From: Tony Vickers Subject: Re: Ks.cfg and XFS Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 1670 Lines: 44 Thanks guys, I GOT IT! I over looked a small part. You know how it goes when you're set on getting something down and you forget to do the littlest thing. When I made my RedHat source dir from the CD-ROMs I forgot to copy the XFS cd. Thanks for all the help! --Tony At 04:06 PM 1/28/2002 -0600, Eric Sandeen wrote: >On Fri, 25 Jan 2002, Tony Vickers wrote: > > > I had to reinstall the build system. So I used SGI's XFS installer along > > with RH 7.2's disc #1,#2. So Yes I do have the full XFS stuff. As far as > > coping the XFS CD-ROM files last how can you make sure this happens? > >How to make sure? Just copy the files off the XFS cd last. I >don't know what kind of setup you have for your kickstart source - is it a >network source, or are you using local CDs, or...? > > > looked at the Rev number on the XFS files and they are newer. So if I were > >It's not the RPM files that matter so much as the install run-time files. >You can have extra RPMs lying around, as long as you have the xfs >installer bits, it will use the right RPMs. > > > to assume that the system is smart to use the latest file would I be right? > > Is it also possible that I got by chance a ISO file when I downloaded it > > from SGI? > >I'm not sure what you mean by this. > > > This is off topic, but, is there a doc on how to make the same type of BOOT > > CD that SGI uses? > >Not really. We had to dig around in the anaconda source to figure it out. >There was a thread on the red hat kickstart-list a while ago that might >help, if you check the archives. > >-Eric > >p.s. the reiser folks had an easier time of it since reiserfs support is >already in the kernel... From owner-linux-xfs@oss.sgi.com Tue Jan 29 11:00:13 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0TJ0DC19280 for linux-xfs-outgoing; Tue, 29 Jan 2002 11:00:13 -0800 Received: from chef.cc.absoval.com (cpe-66-1-218-101.fl.sprintbbd.net [66.1.218.101]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0TJ06P19258 for ; Tue, 29 Jan 2002 11:00:06 -0800 Received: from ieee.org (bs@thebs.cc.absoval.com [192.168.100.89]) by chef.cc.absoval.com (8.9.3/8.9.3) with ESMTP id MAA01762; Tue, 29 Jan 2002 12:59:53 -0500 Message-ID: <3C56E322.5DFE92C2@ieee.org> Date: Tue, 29 Jan 2002 13:00:02 -0500 From: "Bryan J. Smith" Organization: SmithConcepts/AbsoluteValueSystems X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.2.18pre21 i686) X-Accept-Language: en MIME-Version: 1.0 To: Vincent Bernat , linux-xfs@oss.sgi.com Subject: Re: Which gcc? -- 2.91.66, 2.95.x, 2.96, 3.0x References: <200201291638.g0TGcZ2t003428@scare.vieo.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 1969 Lines: 49 Vincent Bernat wrote: > Hello ! > It seems that the official gcc for the kernel is now 2.95.3 : http://www.atnf.csiro.au/~rgooch/linux/docs/kernel-newsflash.html/ > However, on lkml, some people seem to prefer 2.96 from Redhat > (latest version). And the XFS project seems to recommend > egcs-1.1.2. > WHat is the best choice now ? egcs, 2.95.3 or 2.96 from Redhat ? "Bryan J. Smith" wrote: [ I believe egcs-1.1.2 = gcc 2.91.66 ] I know RedHat is compiling its kernels with 2.96, although it did use the "kgcc" wrapper to 2.91.66 in RedHat 7.0. Most other distros are using 2.95.3, although a few _ignorant_ ones *COUGH*Mandrake*COUGH* were using the "not recommended" 2.95.4. SGI and a number of others have stuck with 2.91.66 period. All I know is that I run RedHat and have compiled mine with 2.91.66 with *NO*PROBLEMS*. RedHat Rawhide kernels are now being compiled with gcc 3.0x (3.02?) as RedHat 8.0 enters alpha-testing. GCC 2.96 was actually a "private designation" of the GCC 3.0x development branch in CVS, which RedHat used. The Cygnus/gcc team then "post-designated" the 3.0x development branch in CVS to 2.97 to differentiate from RedHat 7.x. So 2.96 and 3.0x release actually have a lot more in common than 2.91 and 2.95.x. If anything, 3.0x should be considered a more "backward compatible/complete" version of what 2.96 is. RedHat moved to the 3.0x development branch early because it needed Itanium and other support, hence 2.96. I, for one, am glad to see the GCC 2.96 bastard go. I hope we all get to 3.0x shortly. -- Bryan P.S. Please correct any inaccurate statements above. -- Bryan J. Smith, Engineer mailto:b.j.smith@ieee.org AbsoluteValue Systems, Inc. http://www.linux-wlan.org SmithConcepts, Inc. http://www.SmithConcepts.com --------------------------------------------------------- 1999 IRS Data: The top 1% of income earners pay over 36% of the taxes, but have less than 20% of the total income. From owner-linux-xfs@oss.sgi.com Tue Jan 29 11:03:16 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0TJ3Gx20414 for linux-xfs-outgoing; Tue, 29 Jan 2002 11:03:16 -0800 Received: from scare.vieo.com ([63.231.179.33]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0TJ2LY19501 for ; Tue, 29 Jan 2002 11:02:21 -0800 Received: from scare.vieo.com (localhost [127.0.0.1]) by scare.vieo.com (8.12.1/8.12.1) with ESMTP id g0THp7Ku004715 for ; Tue, 29 Jan 2002 11:51:07 -0600 Received: (from cattelan@localhost) by scare.vieo.com (8.12.1/8.12.1/Submit) id g0THp70D004714 for linux-xfs@oss.sgi.com; Tue, 29 Jan 2002 11:51:07 -0600 Message-Id: <200201291751.g0THp70D004714@scare.vieo.com> Date: Mon, 28 Jan 2002 16:06:22 -0600 (CST) From: Eric Sandeen Subject: Re: Ks.cfg and XFS Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 1306 Lines: 34 On Fri, 25 Jan 2002, Tony Vickers wrote: > I had to reinstall the build system. So I used SGI's XFS installer along > with RH 7.2's disc #1,#2. So Yes I do have the full XFS stuff. As far as > coping the XFS CD-ROM files last how can you make sure this happens? How to make sure? Just copy the files off the XFS cd last. I don't know what kind of setup you have for your kickstart source - is it a network source, or are you using local CDs, or...? > looked at the Rev number on the XFS files and they are newer. So if I were It's not the RPM files that matter so much as the install run-time files. You can have extra RPMs lying around, as long as you have the xfs installer bits, it will use the right RPMs. > to assume that the system is smart to use the latest file would I be right? > Is it also possible that I got by chance a ISO file when I downloaded it > from SGI? I'm not sure what you mean by this. > This is off topic, but, is there a doc on how to make the same type of BOOT > CD that SGI uses? Not really. We had to dig around in the anaconda source to figure it out. There was a thread on the red hat kickstart-list a while ago that might help, if you check the archives. -Eric p.s. the reiser folks had an easier time of it since reiserfs support is already in the kernel... From owner-linux-xfs@oss.sgi.com Tue Jan 29 11:03:07 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0TJ37L20283 for linux-xfs-outgoing; Tue, 29 Jan 2002 11:03:07 -0800 Received: from scare.vieo.com ([63.231.179.33]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0TJ2OY19765 for ; Tue, 29 Jan 2002 11:02:25 -0800 Received: from scare.vieo.com (localhost [127.0.0.1]) by scare.vieo.com (8.12.1/8.12.1) with ESMTP id g0THp9Ku004775 for ; Tue, 29 Jan 2002 11:51:09 -0600 Received: (from cattelan@localhost) by scare.vieo.com (8.12.1/8.12.1/Submit) id g0THp9kF004774 for linux-xfs@oss.sgi.com; Tue, 29 Jan 2002 11:51:09 -0600 Message-Id: <200201291751.g0THp9kF004774@scare.vieo.com> From: "Ralf G. R. Bergs" Date: Tue, 29 Jan 2002 09:12:36 +0100 Subject: Re: Reduce XFS footprint (was Re: TAKE - remove a function xfs added to filemap.c Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 850 Lines: 21 On Tue, 29 Jan 2002 12:53:54 +1100, Nathan Scott wrote: [...] >Another thing we could try is to make support for v1 dirs >compile-time conditional (since noone/very few people will >be using this), this might save a bit more space. I think >the code is all accessed via function pointers already, so >the points of abstraction should be clearly defined. I don't think that it's worth that you waste your time with this. I just thought I was using "wrong" options or something like that to compile XFS, or that there was a "plug'n'go" way of shrinking it. :-) -- Verkaufe Original-BMW-Raeder: L I N U X .~. http://adsl-bergs.rz.rwth-aachen.de/~rabe The Choice /V\ of a GNU /( )\ Generation ^^-^^ From owner-linux-xfs@oss.sgi.com Tue Jan 29 11:03:04 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0TJ34c20228 for linux-xfs-outgoing; Tue, 29 Jan 2002 11:03:04 -0800 Received: from scare.vieo.com ([63.231.179.33]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0TJ2KY19451 for ; Tue, 29 Jan 2002 11:02:20 -0800 Received: from scare.vieo.com (localhost [127.0.0.1]) by scare.vieo.com (8.12.1/8.12.1) with ESMTP id g0THp6Ku004699 for ; Tue, 29 Jan 2002 11:51:06 -0600 Received: (from cattelan@localhost) by scare.vieo.com (8.12.1/8.12.1/Submit) id g0THp6qB004698 for linux-xfs@oss.sgi.com; Tue, 29 Jan 2002 11:51:06 -0600 Message-Id: <200201291751.g0THp6qB004698@scare.vieo.com> Subject: Re: mkfs on large h/w RAID fails Date: 28 Jan 2002 15:23:22 -0500 From: "Dave Sill" Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 731 Lines: 27 Steve Lord wrote: > OK, something is lying about the size of your device, it is coming in > at 234870292 4K blocks. The data size check failed means it attempted to > read the last block of the device and the read got an error. > > You could try > > mkfs -t xfs -f -d size=234870290b /dev/sdb1 Using a binary search, I found that the largest size that works is 201318712. > An strace -v output of the failure would also be useful It's 72k, so I'll send it to you off list. Also, fdisk says: Disk /dev/sdb: 255 heads, 63 sectors, 116960 cylinders Units = cylinders of 16065 * 512 bytes Device Boot Start End Blocks Id System /dev/sdb1 1 116960 939481168+ 83 Linux -Dave From owner-linux-xfs@oss.sgi.com Tue Jan 29 11:03:03 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0TJ33C20223 for linux-xfs-outgoing; Tue, 29 Jan 2002 11:03:03 -0800 Received: from scare.vieo.com ([63.231.179.33]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0TJ2PY19778 for ; Tue, 29 Jan 2002 11:02:25 -0800 Received: from scare.vieo.com (localhost [127.0.0.1]) by scare.vieo.com (8.12.1/8.12.1) with ESMTP id g0THpAKu004783 for ; Tue, 29 Jan 2002 11:51:10 -0600 Received: (from cattelan@localhost) by scare.vieo.com (8.12.1/8.12.1/Submit) id g0THpAxQ004782 for linux-xfs@oss.sgi.com; Tue, 29 Jan 2002 11:51:10 -0600 Message-Id: <200201291751.g0THpAxQ004782@scare.vieo.com> Date: Tue, 29 Jan 2002 15:04:36 +0100 From: Wessel Dankers Subject: Sharing a log Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 216 Lines: 13 oi, Quick question (sorry if I missed it in the FAQ): Can XFS share a log partition between XFS partitions? Regards, -- Wessel Dankers Your parity check is overdrawn and you're out of cache. From owner-linux-xfs@oss.sgi.com Tue Jan 29 11:03:37 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0TJ3b420693 for linux-xfs-outgoing; Tue, 29 Jan 2002 11:03:37 -0800 Received: from scare.vieo.com ([63.231.179.33]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0TJ2MY19628 for ; Tue, 29 Jan 2002 11:02:23 -0800 Received: from scare.vieo.com (localhost [127.0.0.1]) by scare.vieo.com (8.12.1/8.12.1) with ESMTP id g0THp8Ku004743 for ; Tue, 29 Jan 2002 11:51:08 -0600 Received: (from cattelan@localhost) by scare.vieo.com (8.12.1/8.12.1/Submit) id g0THp8v7004742 for linux-xfs@oss.sgi.com; Tue, 29 Jan 2002 11:51:08 -0600 Message-Id: <200201291751.g0THp8v7004742@scare.vieo.com> Date: Tue, 29 Jan 2002 12:07:32 +1100 From: Nathan Scott Subject: Re: mkfs on large h/w RAID fails Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 1932 Lines: 60 hi, On Mon, Jan 28, 2002 at 12:02:59PM -0500, Dave Sill wrote: > I've got a terabyte RAID that I'm trying to set up as a single XFS > filesystem. mkfs fails with: > > [root@malachite root]# mkfs.xfs -f /dev/sdb1 > meta-data=/dev/sdb1 isize=256 agcount=224, agsize=1048576 blks > data = bsize=4096 blocks=234870292, imaxpct=25 > = sunit=0 swidth=0 blks, unwritten=0 > = imaxbits=32 > naming =version 2 bsize=4096 > log =internal log bsize=4096 blocks=28670 > realtime =none extsz=65536 blocks=0, rtextents=0 > mkfs.xfs: read failed: Input/output error > mkfs.xfs: data size check failed > mkfs.xfs: mount initialization failed > [root@malachite root]# Basically, what happens here is mkfs.xfs asks the device how big it is (using the BLKGETSIZE ioctl) and before starting to write to the disk, mkfs seeks to 4K from the end of the device and issues a read (to validate the size which the device driver gave it). It looks like for your terabyte RAID, this read is failing (the driver is giving EIO), hence the message "data size check failed". mkfs.xfs will refuse to run on a device which exhibits this anti- social behavior. > I had no problems mkfs'ing it as e2fs, e3fs, and reiserfs. These programs are not doing this lseek/read check to validate the size of the device. > I'm running under the 1.02a installer on an Athlon: > > [root@malachite root]# uname -a > Linux malachite 2.4.9-13SGI_XFS_1.0.2 #1 Thu Nov 15 14:28:44 CST 2001 i686 unknown > [root@malachite root]# > > I installed the xfs programs from the RPM: > > xfsprogs-1.3.13-0.i386.rpm > > Any ideas? > Your terabyte RAID device driver seems to have a bug in either the code which reports its size, or in reading near the end of the device. Hope this helps. cheers. -- Nathan From owner-linux-xfs@oss.sgi.com Tue Jan 29 11:02:48 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0TJ2m620078 for linux-xfs-outgoing; Tue, 29 Jan 2002 11:02:48 -0800 Received: from scare.vieo.com ([63.231.179.33]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0TJ2LY19477 for ; Tue, 29 Jan 2002 11:02:21 -0800 Received: from scare.vieo.com (localhost [127.0.0.1]) by scare.vieo.com (8.12.1/8.12.1) with ESMTP id g0THp6Ku004711 for ; Tue, 29 Jan 2002 11:51:06 -0600 Received: (from cattelan@localhost) by scare.vieo.com (8.12.1/8.12.1/Submit) id g0THp6ET004710 for linux-xfs@oss.sgi.com; Tue, 29 Jan 2002 11:51:06 -0600 Message-Id: <200201291751.g0THp6ET004710@scare.vieo.com> Date: Mon, 28 Jan 2002 22:37:27 +0100 From: Wessel Dankers Subject: Re: mkfs on large h/w RAID fails Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 287 Lines: 13 On 2002-01-28 14:39:44-0500, Dave Sill wrote: > Thought so. Unfortunately, I'm still seeing the same problem after > installing xfsprogs-1.3.17: > mkfs.xfs: read failed: Input/output error Does your kernel log anything? -- Wessel Dankers system has been recalled From owner-linux-xfs@oss.sgi.com Tue Jan 29 11:02:37 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0TJ2bx20032 for linux-xfs-outgoing; Tue, 29 Jan 2002 11:02:37 -0800 Received: from scare.vieo.com ([63.231.179.33]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0TJ2PY19811 for ; Tue, 29 Jan 2002 11:02:25 -0800 Received: from scare.vieo.com (localhost [127.0.0.1]) by scare.vieo.com (8.12.1/8.12.1) with ESMTP id g0THpAKu004791 for ; Tue, 29 Jan 2002 11:51:10 -0600 Received: (from cattelan@localhost) by scare.vieo.com (8.12.1/8.12.1/Submit) id g0THpAxu004790 for linux-xfs@oss.sgi.com; Tue, 29 Jan 2002 11:51:10 -0600 Message-Id: <200201291751.g0THpAxu004790@scare.vieo.com> Date: Tue, 29 Jan 2002 09:49:31 -0600 (CST) From: Russell Cattelan Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 22 Lines: 2 list test ... ignore From owner-linux-xfs@oss.sgi.com Tue Jan 29 11:02:55 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0TJ2tq20121 for linux-xfs-outgoing; Tue, 29 Jan 2002 11:02:55 -0800 Received: from scare.vieo.com ([63.231.179.33]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0TJ2LY19549 for ; Tue, 29 Jan 2002 11:02:21 -0800 Received: from scare.vieo.com (localhost [127.0.0.1]) by scare.vieo.com (8.12.1/8.12.1) with ESMTP id g0THp7Ku004719 for ; Tue, 29 Jan 2002 11:51:07 -0600 Received: (from cattelan@localhost) by scare.vieo.com (8.12.1/8.12.1/Submit) id g0THp7xB004718 for linux-xfs@oss.sgi.com; Tue, 29 Jan 2002 11:51:07 -0600 Message-Id: <200201291751.g0THp7xB004718@scare.vieo.com> Date: Mon, 28 Jan 2002 17:38:02 -0500 From: "Bryan J. Smith" Subject: Re: ScanMail Message: To Recipient virus found or matched file blocking setting. Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 560 Lines: 17 System Attendant wrote: > ScanMail for Microsoft Exchange has taken action on the message, > please refer to the contents of this message for further details. You gotta love Microsoft crap. They have no concept of "bulk E-mail" nor do they understand half of the other RFC822 fields. I take it most everything else when to just the admin, right? -- Bryan -- Bryan J. Smith mailto:b.j.smith@ieee.org chat:thebs413 Engineer AbsoluteValue Systems, Inc. http://www.linux-wlan.org President SmithConcepts, Inc. http://www.SmithConcepts.com From owner-linux-xfs@oss.sgi.com Tue Jan 29 11:02:55 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0TJ2ti20120 for linux-xfs-outgoing; Tue, 29 Jan 2002 11:02:55 -0800 Received: from scare.vieo.com ([63.231.179.33]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0TJ2OY19769 for ; Tue, 29 Jan 2002 11:02:25 -0800 Received: from scare.vieo.com (localhost [127.0.0.1]) by scare.vieo.com (8.12.1/8.12.1) with ESMTP id g0THpAKu004779 for ; Tue, 29 Jan 2002 11:51:10 -0600 Received: (from cattelan@localhost) by scare.vieo.com (8.12.1/8.12.1/Submit) id g0THpADN004778 for linux-xfs@oss.sgi.com; Tue, 29 Jan 2002 11:51:10 -0600 Message-Id: <200201291751.g0THpADN004778@scare.vieo.com> Subject: Which gcc ? From: Vincent Bernat Date: Tue, 29 Jan 2002 10:59:39 +0100 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 443 Lines: 14 Hello ! It seems that the official gcc for the kernel is now 2.95.3 : http://www.atnf.csiro.au/~rgooch/linux/docs/kernel-newsflash.html/ However, on lkml, some people seem to prefer 2.96 from Redhat (latest version). And the XFS project seems to recommend egcs-1.1.2. WHat is the best choice now ? egcs, 2.95.3 or 2.96 from Redhat ? -- Document your data layouts. - The Elements of Programming Style (Kernighan & Plaugher) From owner-linux-xfs@oss.sgi.com Tue Jan 29 11:03:14 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0TJ3Ei20404 for linux-xfs-outgoing; Tue, 29 Jan 2002 11:03:14 -0800 Received: from scare.vieo.com ([63.231.179.33]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0TJ2NY19659 for ; Tue, 29 Jan 2002 11:02:23 -0800 Received: from scare.vieo.com (localhost [127.0.0.1]) by scare.vieo.com (8.12.1/8.12.1) with ESMTP id g0THp9Ku004759 for ; Tue, 29 Jan 2002 11:51:09 -0600 Received: (from cattelan@localhost) by scare.vieo.com (8.12.1/8.12.1/Submit) id g0THp9cK004758 for linux-xfs@oss.sgi.com; Tue, 29 Jan 2002 11:51:09 -0600 Message-Id: <200201291751.g0THp9cK004758@scare.vieo.com> Date: Tue, 29 Jan 2002 16:02:34 +1100 From: Nathan Scott Subject: Re: extended attributes support on powerpc Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 932 Lines: 27 On Mon, Jan 28, 2002 at 03:03:11PM +1100, Keith Owens wrote: > On Sun, 27 Jan 2002 18:47:24 -0900, > Ethan Benson wrote: > >i assume the numbering doesn't affect userland at all, its only used > >for internal compilation of the kernel correct? > > The syscall numbers are also used by the ACL programs. In XFS CVS > theye are in cmd/attr/libattr/attr.c at line 292. Forgot about those, > I don't work on the user space commands. > The ACL userspace will also need updating - see the end of cmd/acl/libacl/acl.c In terms of including these changes, we're looking at ways to consolidate the different ACL/EA userspace packages at the moment (between XFS and ext2/3) and these syscalls will likely be reworked at some point in the future, so I'm a bit hesitant to go extending this code to new platforms in the interim (would equate to more places where it may break down the track). cheers. -- Nathan From owner-linux-xfs@oss.sgi.com Tue Jan 29 11:03:05 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0TJ35A20266 for linux-xfs-outgoing; Tue, 29 Jan 2002 11:03:05 -0800 Received: from scare.vieo.com ([63.231.179.33]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0TJ2MY19588 for ; Tue, 29 Jan 2002 11:02:22 -0800 Received: from scare.vieo.com (localhost [127.0.0.1]) by scare.vieo.com (8.12.1/8.12.1) with ESMTP id g0THp7Ku004727 for ; Tue, 29 Jan 2002 11:51:07 -0600 Received: (from cattelan@localhost) by scare.vieo.com (8.12.1/8.12.1/Submit) id g0THp7ke004726 for linux-xfs@oss.sgi.com; Tue, 29 Jan 2002 11:51:07 -0600 Message-Id: <200201291751.g0THp7ke004726@scare.vieo.com> Date: Mon, 28 Jan 2002 14:49:13 -0800 From: Andrew Morton Subject: Re: XFS bug with ftruncate, mmap and holes. Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 825 Lines: 23 Ethan Benson wrote: > > someone i was talking to recently has been using the 2.4.17 xfs > patches with 2.4.18pre kernels and found apt-get failed due to errors > returned by msync() (which appears to be returning 1 (not -1)). > msync is involved in writing these apt binary cache files. > Interesting. In 2.4.18-pre3 I changed msync. Previously, it was ignoring things like EIO and ENOSPC on writepage() operations. The change was to correctly propagate these error codes all the way back to the caller, all over the place. The raw diff is at http://www.zip.com.au/~akpm/linux/2.4/2.4.18-pre3/msync-ret.patch If someone is returning `1' from msync() then probably an underlying filesystem is returning `1' from its get_block() or writepage() method. It shouldn't. It should return either zero or a negative errno. From owner-linux-xfs@oss.sgi.com Tue Jan 29 11:03:39 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0TJ3dN20709 for linux-xfs-outgoing; Tue, 29 Jan 2002 11:03:39 -0800 Date: Tue, 29 Jan 2002 11:03:39 -0800 From: owner-linux-xfs@oss.sgi.com Message-Id: <200201291903.g0TJ3dN20709@oss.sgi.com> Status: O Content-Length: 0 Lines: 0 From owner-linux-xfs@oss.sgi.com Tue Jan 29 11:06:19 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0TJ2sI20119 for linux-xfs-outgoing; Tue, 29 Jan 2002 11:02:54 -0800 Received: from scare.vieo.com ([63.231.179.33]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0TJ2NY19674 for ; Tue, 29 Jan 2002 11:02:23 -0800 Received: from scare.vieo.com (localhost [127.0.0.1]) by scare.vieo.com (8.12.1/8.12.1) with ESMTP id g0THp9Ku004763 for ; Tue, 29 Jan 2002 11:51:09 -0600 Received: (from cattelan@localhost) by scare.vieo.com (8.12.1/8.12.1/Submit) id g0THp9Aj004762 for linux-xfs@oss.sgi.com; Tue, 29 Jan 2002 11:51:09 -0600 Message-Id: <200201291751.g0THp9Aj004762@scare.vieo.com> Subject: Re: NFS and XFS From: Florin Andrei Date: 28 Jan 2002 21:16:21 -0800 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 401 Lines: 15 On Fri, 2002-01-25 at 19:25, Zhifeng F. Chen wrote: > > version 3 on 2.4 kernels, ... " Could anyone tell me if XFS works correctly > with NFS ? Not only works, but is in fact one of the finest choices for a NFS server. ;-) -- Florin Andrei "The security of any corporate network is inversely proportional to the number of systems administrators on the network." - - Petreley's law of sysadmins From owner-linux-xfs@oss.sgi.com Tue Jan 29 11:06:25 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0TJ2dM20040 for linux-xfs-outgoing; Tue, 29 Jan 2002 11:02:39 -0800 Received: from scare.vieo.com ([63.231.179.33]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0TJ2KY19452 for ; Tue, 29 Jan 2002 11:02:20 -0800 Received: from scare.vieo.com (localhost [127.0.0.1]) by scare.vieo.com (8.12.1/8.12.1) with ESMTP id g0THp6Ku004703 for ; Tue, 29 Jan 2002 11:51:06 -0600 Received: (from cattelan@localhost) by scare.vieo.com (8.12.1/8.12.1/Submit) id g0THp6N9004702 for linux-xfs@oss.sgi.com; Tue, 29 Jan 2002 11:51:06 -0600 Message-Id: <200201291751.g0THp6N9004702@scare.vieo.com> From: Keith Owens Subject: Re: XFS bug with ftruncate, mmap and holes. Date: Tue, 29 Jan 2002 08:02:49 +1100 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 372 Lines: 10 On 28 Jan 2002 10:52:15 -0600, Steve Lord wrote: >Can you please try the attached patch and see if it fixes your problems, >it makes the test program (unmodified) function for me (the data survives >unmount). Works for me. I backed out my XFS workaround patches to mdbm and the database now survives reboot, even with the non-standard truncate upwards. From owner-linux-xfs@oss.sgi.com Tue Jan 29 11:06:41 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0TJ2vn20154 for linux-xfs-outgoing; Tue, 29 Jan 2002 11:02:57 -0800 Received: from scare.vieo.com ([63.231.179.33]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0TJ2KY19454 for ; Tue, 29 Jan 2002 11:02:20 -0800 Received: from scare.vieo.com (localhost [127.0.0.1]) by scare.vieo.com (8.12.1/8.12.1) with ESMTP id g0THp6Ku004707 for ; Tue, 29 Jan 2002 11:51:06 -0600 Received: (from cattelan@localhost) by scare.vieo.com (8.12.1/8.12.1/Submit) id g0THp6Kf004706 for linux-xfs@oss.sgi.com; Tue, 29 Jan 2002 11:51:06 -0600 Message-Id: <200201291751.g0THp6Kf004706@scare.vieo.com> Subject: Re: XFS bug with ftruncate, mmap and holes. From: Steve Lord Date: 28 Jan 2002 15:07:25 -0600 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 773 Lines: 22 On Mon, 2002-01-28 at 15:02, Keith Owens wrote: > On 28 Jan 2002 10:52:15 -0600, > Steve Lord wrote: > >Can you please try the attached patch and see if it fixes your problems, > >it makes the test program (unmodified) function for me (the data survives > >unmount). > > Works for me. I backed out my XFS workaround patches to mdbm and the > database now survives reboot, even with the non-standard truncate > upwards. Thanks Keith, now I need to figure out if I should just put this code in or clean up the code again..... probably both, too much going on right now in other places to do it all now. Steve -- Steve Lord voice: +1-651-683-3511 Principal Engineer, Filesystem Software email: lord@sgi.com From owner-linux-xfs@oss.sgi.com Tue Jan 29 11:06:41 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0TJ37L20283 for linux-xfs-outgoing; Tue, 29 Jan 2002 11:03:07 -0800 Received: from scare.vieo.com ([63.231.179.33]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0TJ2OY19765 for ; Tue, 29 Jan 2002 11:02:25 -0800 Received: from scare.vieo.com (localhost [127.0.0.1]) by scare.vieo.com (8.12.1/8.12.1) with ESMTP id g0THp9Ku004775 for ; Tue, 29 Jan 2002 11:51:09 -0600 Received: (from cattelan@localhost) by scare.vieo.com (8.12.1/8.12.1/Submit) id g0THp9kF004774 for linux-xfs@oss.sgi.com; Tue, 29 Jan 2002 11:51:09 -0600 Message-Id: <200201291751.g0THp9kF004774@scare.vieo.com> From: "Ralf G. R. Bergs" Date: Tue, 29 Jan 2002 09:12:36 +0100 Subject: Re: Reduce XFS footprint (was Re: TAKE - remove a function xfs added to filemap.c Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 850 Lines: 21 On Tue, 29 Jan 2002 12:53:54 +1100, Nathan Scott wrote: [...] >Another thing we could try is to make support for v1 dirs >compile-time conditional (since noone/very few people will >be using this), this might save a bit more space. I think >the code is all accessed via function pointers already, so >the points of abstraction should be clearly defined. I don't think that it's worth that you waste your time with this. I just thought I was using "wrong" options or something like that to compile XFS, or that there was a "plug'n'go" way of shrinking it. :-) -- Verkaufe Original-BMW-Raeder: L I N U X .~. http://adsl-bergs.rz.rwth-aachen.de/~rabe The Choice /V\ of a GNU /( )\ Generation ^^-^^ From owner-linux-xfs@oss.sgi.com Tue Jan 29 11:06:56 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0TJ3TW20618 for linux-xfs-outgoing; Tue, 29 Jan 2002 11:03:29 -0800 Received: from scare.vieo.com ([63.231.179.33]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0TJ2NY19650 for ; Tue, 29 Jan 2002 11:02:23 -0800 Received: from scare.vieo.com (localhost [127.0.0.1]) by scare.vieo.com (8.12.1/8.12.1) with ESMTP id g0THp8Ku004751 for ; Tue, 29 Jan 2002 11:51:08 -0600 Received: (from cattelan@localhost) by scare.vieo.com (8.12.1/8.12.1/Submit) id g0THp897004750 for linux-xfs@oss.sgi.com; Tue, 29 Jan 2002 11:51:08 -0600 Message-Id: <200201291751.g0THp897004750@scare.vieo.com> Date: Tue, 29 Jan 2002 12:53:54 +1100 From: Nathan Scott Subject: Re: Reduce XFS footprint (was Re: TAKE - remove a function xfs added to filemap.c Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 1102 Lines: 38 On Sat, Jan 26, 2002 at 01:59:15PM -0600, Stephen Lord wrote: > Ralf G. R. Bergs wrote: > > >>You could try editing xfs_types.h and changing > ... > It does compile and run, and you save about 45K in code size by doing it, > so not too much. You can also edit xfs_macros.h and define WANT_SPACE_C > to 1 (replace the existing definition). This turns a lot of inline > macros into > function calls - it will be slower, but it is another 10K less code - > again, not > very much. > Another thing we could try is to make support for v1 dirs compile-time conditional (since noone/very few people will be using this), this might save a bit more space. I think the code is all accessed via function pointers already, so the points of abstraction should be clearly defined. > So and smp build (in 2.5) went from > > text data bss dec hex filename > 520994 4896 2080 527970 80e62 fs/xfs/xfs.o > > to > text data bss dec hex filename > 487334 4896 2080 494310 78ae6 fs/xfs/xfs.o > > with these two build changes. > > Steve > > -- Nathan From owner-linux-xfs@oss.sgi.com Tue Jan 29 11:07:11 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0TJ3IJ20463 for linux-xfs-outgoing; Tue, 29 Jan 2002 11:03:18 -0800 Received: from scare.vieo.com ([63.231.179.33]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0TJ2MY19627 for ; Tue, 29 Jan 2002 11:02:22 -0800 Received: from scare.vieo.com (localhost [127.0.0.1]) by scare.vieo.com (8.12.1/8.12.1) with ESMTP id g0THp8Ku004739 for ; Tue, 29 Jan 2002 11:51:08 -0600 Received: (from cattelan@localhost) by scare.vieo.com (8.12.1/8.12.1/Submit) id g0THp85E004738 for linux-xfs@oss.sgi.com; Tue, 29 Jan 2002 11:51:08 -0600 Message-Id: <200201291751.g0THp85E004738@scare.vieo.com> Date: Tue, 29 Jan 2002 11:55:57 +1100 From: Nathan Scott Subject: Re: double mounting and other strangeness. Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 1183 Lines: 31 hi, On Sun, Jan 27, 2002 at 12:19:47AM -0600, pac@fortuitous.com wrote: > ... > Linux bart.marx 2.4.17-preempt-fspatch-alsa #1 Fri Jan 25 21:45:36 CST 2002 i686 unknown > ... > > I also get some errors when I try to make a new xfs filesystem on either > /dev/hda10 and /dev/hda9: > ------------------------------------------------------------------------ > mkfs.xfs -f /dev/hda10 > mkfs.xfs: warning - cannot set blocksize on block device /dev/hda10: Input/output error > meta-data=/dev/hda10 isize=256 agcount=8, agsize=16064 blks > data = bsize=4096 blocks=128512, imaxpct=25 > = sunit=0 swidth=0 blks, unwritten=0 > naming =version 2 bsize=4096 > log =internal log bsize=4096 blocks=1200 > realtime =none extsz=65536 blocks=0, rtextents=0 > ------------------------------------------------------------------ > The device driver you're using (for /dev/hda10) doesn't support the BLKBSZSET ioctl. This ioctl was introduced in 2.4.10-pre3 & should be supported now - so this is a device driver problem, not an XFS problem. cheers. -- Nathan From owner-linux-xfs@oss.sgi.com Tue Jan 29 11:07:37 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0TJ3TM20628 for linux-xfs-outgoing; Tue, 29 Jan 2002 11:03:29 -0800 Received: from scare.vieo.com ([63.231.179.33]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0TJ2MY19592 for ; Tue, 29 Jan 2002 11:02:22 -0800 Received: from scare.vieo.com (localhost [127.0.0.1]) by scare.vieo.com (8.12.1/8.12.1) with ESMTP id g0THp8Ku004731 for ; Tue, 29 Jan 2002 11:51:08 -0600 Received: (from cattelan@localhost) by scare.vieo.com (8.12.1/8.12.1/Submit) id g0THp8ru004730 for linux-xfs@oss.sgi.com; Tue, 29 Jan 2002 11:51:08 -0600 Message-Id: <200201291751.g0THp8ru004730@scare.vieo.com> Subject: Re: XFS bug with ftruncate, mmap and holes. From: Steve Lord Date: 28 Jan 2002 16:58:32 -0600 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 1305 Lines: 38 On Mon, 2002-01-28 at 16:49, Andrew Morton wrote: > Ethan Benson wrote: > > > > someone i was talking to recently has been using the 2.4.17 xfs > > patches with 2.4.18pre kernels and found apt-get failed due to errors > > returned by msync() (which appears to be returning 1 (not -1)). > > msync is involved in writing these apt binary cache files. > > > > Interesting. > > In 2.4.18-pre3 I changed msync. Previously, it was ignoring things > like EIO and ENOSPC on writepage() operations. The change was to > correctly propagate these error codes all the way back to the > caller, all over the place. > > The raw diff is at > http://www.zip.com.au/~akpm/linux/2.4/2.4.18-pre3/msync-ret.patch > > If someone is returning `1' from msync() then probably an > underlying filesystem is returning `1' from its get_block() > or writepage() method. It shouldn't. It should return > either zero or a negative errno. Bingo, there used to be some code where we did return a value to indicate how much got flushed when we did a clustered write, I don't think we use that anymore. So I will go revert the writepage output to what it should be. Thanks, Steve -- Steve Lord voice: +1-651-683-3511 Principal Engineer, Filesystem Software email: lord@sgi.com From owner-linux-xfs@oss.sgi.com Tue Jan 29 11:07:50 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0TJ3dl20704 for linux-xfs-outgoing; Tue, 29 Jan 2002 11:03:39 -0800 Received: from scare.vieo.com ([63.231.179.33]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0TJ2MY19625 for ; Tue, 29 Jan 2002 11:02:23 -0800 Received: from scare.vieo.com (localhost [127.0.0.1]) by scare.vieo.com (8.12.1/8.12.1) with ESMTP id g0THp8Ku004735 for ; Tue, 29 Jan 2002 11:51:08 -0600 Received: (from cattelan@localhost) by scare.vieo.com (8.12.1/8.12.1/Submit) id g0THp8Tx004734 for linux-xfs@oss.sgi.com; Tue, 29 Jan 2002 11:51:08 -0600 Message-Id: <200201291751.g0THp8Tx004734@scare.vieo.com> Subject: Re: mkfs on large h/w RAID fails From: Austin Gonyou Date: 28 Jan 2002 17:20:59 -0600 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 2035 Lines: 68 --=-g/TZnHIZn94r4/alyU/k Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Fancy that. :) Well, what Controller are you using? Can you strace the mkfs to see what's happening? On Mon, 2002-01-28 at 13:39, Dave Sill wrote: > [Please reply only to the mailing list.] >=20 > Steve Lord wrote: > > On Mon, 2002-01-28 at 12:00, Dave Sill wrote: > > > Austin Gonyou writes: > > >=20 > > > > can you try 2.4.14 or 2.4.17 and also upgrade to the new tools? > > >=20 > > > Do I need the XFS kernel to run mkfs.xfs or can I just install the > new > > > tools? > >=20 > > Any old kernel should do. >=20 > Thought so. Unfortunately, I'm still seeing the same problem after > installing xfsprogs-1.3.17: >=20 > [root@malachite rpm]# mkfs.xfs -f /dev/sdb1 > meta-data=3D/dev/sdb1 isize=3D256 agcount=3D224, > agsize=3D1048576 blks > data =3D bsize=3D4096 blocks=3D234870292, > imaxpct=3D25 > =3D sunit=3D0 swidth=3D0 blks, unwrit= ten=3D0 > naming =3Dversion 2 bsize=3D4096 =20 > log =3Dinternal log bsize=3D4096 blocks=3D28670 > realtime =3Dnone extsz=3D65536 blocks=3D0, rtextents= =3D0 > mkfs.xfs: read failed: Input/output error > mkfs.xfs: data size check failed > mkfs.xfs: mount initialization failed > [root@malachite rpm]#=20 >=20 > -Dave --=20 Austin Gonyou Systems Architect, CCNA Coremetrics, Inc. Phone: 512-698-7250 email: austin@coremetrics.com "It is the part of a good shepherd to shear his flock, not to skin it." Latin Proverb --=-g/TZnHIZn94r4/alyU/k Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQA8Vdzb94g6ZVmFMoIRAnbtAJ9EXCu5KbZmWqWlqlrlOhEYG3/G0QCgmNJi aeRxxTD9O6OnNB3I7t5AHBQ= =CbyR -----END PGP SIGNATURE----- --=-g/TZnHIZn94r4/alyU/k-- From owner-linux-xfs@oss.sgi.com Tue Jan 29 11:40:27 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0TJeRo22857 for linux-xfs-outgoing; Tue, 29 Jan 2002 11:40:27 -0800 Received: from Cantor.suse.de (ns.suse.de [213.95.15.193]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0TJeAd22835 for ; Tue, 29 Jan 2002 11:40:11 -0800 Received: from Hermes.suse.de (Hermes.suse.de [213.95.15.136]) by Cantor.suse.de (Postfix) with ESMTP id 48A0B1E905; Tue, 29 Jan 2002 19:40:03 +0100 (MET) Date: Tue, 29 Jan 2002 19:40:01 +0100 From: Andi Kleen To: Nathan Scott Cc: linux-xfs@oss.sgi.com Subject: [PATCH] Re: Reduce XFS footprint (was Re: TAKE - remove a function xfs added to filemap.c Message-ID: <20020129194001.A16401@wotan.suse.de> References: <200201291751.g0THp897004750@scare.vieo.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200201291751.g0THp897004750@scare.vieo.com> User-Agent: Mutt/1.3.22.1i Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 5038 Lines: 151 On Tue, Jan 29, 2002 at 12:53:54PM +1100, Nathan Scott wrote: > On Sat, Jan 26, 2002 at 01:59:15PM -0600, Stephen Lord wrote: > > Ralf G. R. Bergs wrote: > > > > >>You could try editing xfs_types.h and changing > > ... > > It does compile and run, and you save about 45K in code size by doing it, > > so not too much. You can also edit xfs_macros.h and define WANT_SPACE_C > > to 1 (replace the existing definition). This turns a lot of inline > > macros into > > function calls - it will be slower, but it is another 10K less code - > > again, not > > very much. > > > > Another thing we could try is to make support for v1 dirs > compile-time conditional (since noone/very few people will > be using this), this might save a bit more space. I think > the code is all accessed via function pointers already, so > the points of abstraction should be clearly defined. This patch does it. It's very simple and clean. Saves another 18K on a xfs with BIG_FILESYSTEMS and BIG_FILES disabled. For completeness I also added BIG_FILES and BIG_FILESYSTEMS as visible CONFIG options. BIG_FILES does not seem to be that useful (except perhaps for some embedded apps or people with bad compiler problems with long long), but having BIG_FILESYSTEMS is probably a good idea because linux 2.4 doesn't support block devices >2TB anyways and there is also the 64bit inode number support missing for it. I don't see much reason currently in 2.4 to enable it. -Andi --- linux/fs/xfs/xfs_types.h-V1 Wed Aug 8 16:08:34 2001 +++ linux/fs/xfs/xfs_types.h Tue Jan 29 18:57:17 2002 @@ -43,8 +43,17 @@ * defs files for the normal case. */ +#ifdef CONFIG_XFS_BIG_FILES #define XFS_BIG_FILES 1 +#else +#define XFS_BIG_FILES 0 +#endif + +#ifdef CONFIG_XFS_BIG_FILESYSTEMS #define XFS_BIG_FILESYSTEMS 1 +#else +#define XFS_BIG_FILESYSTEMS 0 +#endif typedef __uint32_t xfs_agblock_t; /* blockno in alloc. group */ typedef __uint32_t xfs_extlen_t; /* extent length in blocks */ --- linux/fs/xfs/xfsidbg.c-V1 Sun Jan 27 15:42:22 2002 +++ linux/fs/xfs/xfsidbg.c Tue Jan 29 19:23:47 2002 @@ -2475,7 +2475,7 @@ #else kdb_printf(" blk %d bp 0x%p blkno 0x%Lx", #endif - i, p->blk[i].bp, p->blk[i].blkno); + i, p->blk[i].bp, (unsigned long long)p->blk[i].blkno); kdb_printf(" index %d hashval 0x%x ", p->blk[i].index, (uint_t)p->blk[i].hashval); switch(p->blk[i].magic) { @@ -2579,7 +2579,7 @@ if (bno == NULLFSBLOCK) sprintf(rval, "NULLFSBLOCK"); else if (ISNULLSTARTBLOCK(bno)) - sprintf(rval, "NULLSTARTBLOCK(%Ld)", STARTBLOCKVAL(bno)); + sprintf(rval, "NULLSTARTBLOCK(%Ld)", (unsigned long long)STARTBLOCKVAL(bno)); else if (mp) sprintf(rval, "%Ld[%x:%x]", (xfs_dfsbno_t)bno, XFS_FSB_TO_AGNO(mp, bno), XFS_FSB_TO_AGBNO(mp, bno)); @@ -3545,7 +3545,7 @@ #if XFS_BIG_FILES kdb_printf(" bp 0x%p blkno 0x%x ", eblk->bp, eblk->blkno); #else - kdb_printf(" bp 0x%x blkno 0x%x ", eblk->bp, eblk->blkno); + kdb_printf(" bp 0x%p blkno 0x%x ", eblk->bp, eblk->blkno); #endif kdb_printf("index %d hashval 0x%x\n", eblk->index, (uint_t)eblk->hashval); } --- linux/fs/xfs/xfs_mount.c-V1 Sun Jan 27 15:42:22 2002 +++ linux/fs/xfs/xfs_mount.c Tue Jan 29 18:46:06 2002 @@ -846,10 +846,18 @@ /* * Select the right directory manager. */ - mp->m_dirops = - XFS_SB_VERSION_HASDIRV2(&mp->m_sb) ? - xfsv2_dirops : - xfsv1_dirops; + + if (!XFS_SB_VERSION_HASDIRV2(&mp->m_sb)) { +#ifdef CONFIG_XFS_V1_DIR + mp->m_dirops = xfsv1_dirops; +#else + cmn_err(CE_WARN, "XFS: v1 directories not compiled in"); + goto error1; +#endif + } else { + mp->m_dirops = xfsv2_dirops; + } + /* * Initialize directory manager's entries. --- linux/fs/xfs/Makefile-V1 Tue Jan 29 18:47:03 2002 +++ linux/fs/xfs/Makefile Tue Jan 29 19:33:41 2002 @@ -73,6 +73,10 @@ obj-y += xfs_grio.o endif +ifneq ($(CONFIG_XFS_V1_DIR),) + obj-y += xfs_dir.o xfs_dir_leaf.o +endif + ifeq ($(CONFIG_HAVE_XFS_DMAPI),) obj-y += xfsdmapistubs.o else @@ -100,7 +104,6 @@ xfs_btree.o \ xfs_buf_item.o \ xfs_da_btree.o \ - xfs_dir.o \ xfs_dir2.o \ xfs_dir2_block.o \ xfs_dir2_data.o \ @@ -108,7 +111,6 @@ xfs_dir2_node.o \ xfs_dir2_sf.o \ xfs_dir2_trace.o \ - xfs_dir_leaf.o \ xfs_error.o \ xfs_extfree_item.o \ xfs_fsops.o \ --- linux/fs/Config.in-V1 Sun Jan 27 15:42:16 2002 +++ linux/fs/Config.in Tue Jan 29 18:59:47 2002 @@ -90,6 +90,9 @@ tristate 'SGI XFS filesystem support' CONFIG_XFS_FS dep_mbool ' Enable XFS Realtime support' CONFIG_XFS_RT $CONFIG_XFS_FS dep_mbool ' Enable XFS Quota' CONFIG_XFS_QUOTA $CONFIG_XFS_FS +dep_mbool ' Enable XFSv1 directories' CONFIG_XFS_V1_DIR +dep_mbool ' Enable XFS filesystems greater than 2TB' CONFIG_XFS_BIG_FILESYSTEMS +dep_mbool ' Enable XFS files greater than 2GB' CONFIG_XFS_BIG_FILES if [ "$CONFIG_XFS_FS" != "n" ]; then define_bool CONFIG_HAVE_ATTRCTL y dep_tristate ' Enable XFS DMAPI' CONFIG_XFS_DMAPI $CONFIG_XFS_FS From owner-linux-xfs@oss.sgi.com Tue Jan 29 11:41:27 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0TJfR822989 for linux-xfs-outgoing; Tue, 29 Jan 2002 11:41:27 -0800 Received: from zok.sgi.com (zok.SGI.COM [204.94.215.101]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0TJfOd22967 for ; Tue, 29 Jan 2002 11:41:24 -0800 Received: from zeus-e8.americas.sgi.com (zeus-e8.americas.sgi.com [128.162.8.103]) by zok.sgi.com (8.11.4/8.11.4/linux-outbound_gateway-1.1) with ESMTP id g0TIfHo31843 for ; Tue, 29 Jan 2002 10:41:17 -0800 Received: from poppy-e185.americas.sgi.com (poppy-e185.americas.sgi.com [128.162.185.207]) by zeus-e8.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id MAA202688; Tue, 29 Jan 2002 12:40:01 -0600 (CST) Received: from stout.americas.sgi.com (stout.americas.sgi.com [128.162.187.5]) by poppy-e185.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.7) with ESMTP id MAA45910; Tue, 29 Jan 2002 12:40:01 -0600 (CST) Subject: Re: Sharing a log From: Eric Sandeen To: Wessel Dankers Cc: linux-xfs@oss.sgi.com In-Reply-To: <200201291751.g0THpAxQ004782@scare.vieo.com> References: <200201291751.g0THpAxQ004782@scare.vieo.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/1.0 (Preview Release) Date: 29 Jan 2002 12:40:01 -0600 Message-Id: <1012329601.30169.19.camel@stout.americas.sgi.com> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 295 Lines: 14 On Tue, 2002-01-29 at 08:04, Wessel Dankers wrote: > Quick question (sorry if I missed it in the FAQ): > > Can XFS share a log partition between XFS partitions? Quick answer - nope! -Eric -- Eric Sandeen XFS for Linux http://oss.sgi.com/projects/xfs sandeen@sgi.com SGI, Inc. From owner-linux-xfs@oss.sgi.com Tue Jan 29 11:51:03 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0TJp3m23244 for linux-xfs-outgoing; Tue, 29 Jan 2002 11:51:03 -0800 Received: from ADSL-Bergs.RZ.RWTH-Aachen.DE (adsl-bergs.rz.RWTH-Aachen.DE [137.226.80.218]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0TJoxd23220 for ; Tue, 29 Jan 2002 11:50:59 -0800 Received: from [192.168.1.2] (helo=ralf) by ADSL-Bergs.RZ.RWTH-Aachen.DE with smtp (Exim 3.12 #1) id 16VdLH-0006jp-00; Tue, 29 Jan 2002 19:50:51 +0100 From: "Ralf G. R. Bergs" To: "linux-xfs@oss.sgi.com" Cc: "Andi Kleen" Date: Tue, 29 Jan 2002 19:50:50 +0100 Reply-To: "Ralf G. R. Bergs" X-Mailer: PMMail 2000 Professional (2.20.2380) For Windows 2000 (5.0.2195;2) In-Reply-To: <20020129194001.A16401@wotan.suse.de> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Subject: Re: [PATCH] Re: Reduce XFS footprint (was Re: TAKE - remove a function xfs added to filemap.c Message-Id: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 537 Lines: 17 On Tue, 29 Jan 2002 19:40:01 +0100, Andi Kleen wrote: >+dep_mbool ' Enable XFSv1 directories' CONFIG_XFS_V1_DIR Could you please elaborate on what exactly it means to enable/disable this item? (Other than possibly making XFS smaller.) Thanks. -- Verkaufe Original-BMW-Raeder: L I N U X .~. http://adsl-bergs.rz.rwth-aachen.de/~rabe The Choice /V\ of a GNU /( )\ Generation ^^-^^ From owner-linux-xfs@oss.sgi.com Tue Jan 29 12:12:44 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0TKCix23683 for linux-xfs-outgoing; Tue, 29 Jan 2002 12:12:44 -0800 Received: from rj.sgi.com (rj.SGI.COM [204.94.215.100]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0TKCdd23661 for ; Tue, 29 Jan 2002 12:12:39 -0800 Received: from zeus-e8.americas.sgi.com (zeus-e8.americas.sgi.com [128.162.8.103]) by rj.sgi.com (8.11.4/8.11.4/linux-outbound_gateway-1.1) with ESMTP id g0TJCVY32280 for ; Tue, 29 Jan 2002 11:12:31 -0800 Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by zeus-e8.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id NAA202416; Tue, 29 Jan 2002 13:11:15 -0600 (CST) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id NAA07110; Tue, 29 Jan 2002 13:11:15 -0600 (CST) Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id g0TJ9If25889; Tue, 29 Jan 2002 13:09:18 -0600 Subject: Re: [PATCH] Re: Reduce XFS footprint (was Re: TAKE - remove a function xfs added to filemap.c From: Steve Lord To: "Ralf G. R. Bergs" Cc: "linux-xfs@oss.sgi.com" , Andi Kleen In-Reply-To: References: Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/1.0.1 Date: 29 Jan 2002 13:09:17 -0600 Message-Id: <1012331357.24486.67.camel@jen.americas.sgi.com> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 1107 Lines: 33 On Tue, 2002-01-29 at 12:50, Ralf G. R. Bergs wrote: > On Tue, 29 Jan 2002 19:40:01 +0100, Andi Kleen wrote: > > >+dep_mbool ' Enable XFSv1 directories' CONFIG_XFS_V1_DIR > > Could you please elaborate on what exactly it means to enable/disable this item? > (Other than possibly making XFS smaller.) XFS has two directory formats, V1 directories were the original, V2 was a new version written to fix problems with NFS and a few other apps. Linux always uses V2, the V1 is there for Irix compatibility - but it can get into loops or miss entries in readdir on linux. Steve p.s. Thanks for the patch Andi, we will discuss it internally. > > Thanks. > > > -- > Verkaufe Original-BMW-Raeder: L I N U X .~. > http://adsl-bergs.rz.rwth-aachen.de/~rabe The Choice /V\ > of a GNU /( )\ > Generation ^^-^^ > -- Steve Lord voice: +1-651-683-3511 Principal Engineer, Filesystem Software email: lord@sgi.com From owner-linux-xfs@oss.sgi.com Tue Jan 29 12:13:43 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0TKDhu23806 for linux-xfs-outgoing; Tue, 29 Jan 2002 12:13:43 -0800 Received: from tele-post-20.mail.demon.net (tele-post-20.mail.demon.net [194.217.242.20]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0TKDad23783 for ; Tue, 29 Jan 2002 12:13:36 -0800 Received: from sweeney.demon.co.uk ([158.152.71.87] helo=pereskia.sweeney.demon.co.uk) by tele-post-20.mail.demon.net with esmtp (Exim 2.12 #2) id 16VdhE-00038Q-0K for linux-xfs@oss.sgi.com; Tue, 29 Jan 2002 19:13:32 +0000 Received: from rebutia.sweeney.demon.co.uk (rebutia.sweeney.demon.co.uk [10.0.0.3]) by pereskia.sweeney.demon.co.uk (Postfix) with ESMTP id 750AB1F58 for ; Tue, 29 Jan 2002 19:19:58 +0000 (GMT) Received: by rebutia.sweeney.demon.co.uk (Postfix, from userid 1001) id E6892125E6; Tue, 29 Jan 2002 19:13:20 +0000 (GMT) Date: Tue, 29 Jan 2002 19:13:20 +0000 (GMT) From: Keith Matthews Subject: Re[2]: mkfs on large h/w RAID fails To: linux-xfs@oss.sgi.com Message-Id: <20020129191320.E6892125E6@rebutia.sweeney.demon.co.uk> Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 1408 Lines: 56 In-Reply-To: <200201291751.g0THp6qB004698@scare.vieo.com> References: <200201291751.g0THp6qB004698@scare.vieo.com> X-Mailer: Mahogany, 0.60 'Redmond', compiled for Linux 2.2.13 i686 MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=ISO-8859-1 Content-Transfer-Encoding: QUOTED-PRINTABLE Content-Disposition: INLINE I'm getting this and a number of other posts to the list twice. Anyone else seeing that ? On 28 Jan 2002 15:23:22 -0500 Dave Sill > wrote: > Steve Lord wrote: > > OK, something is lying about the size of your device, it is coming in > > at 234870292 4K blocks. The data size check failed means it attempted t= o > > read the last block of the device and the read got an error.=20 > >=20 > > You could try > >=20 > > mkfs -t xfs -f -d size=3D234870290b /dev/sdb1 > Using a binary search, I found that the largest size that works is > 201318712. > > An strace -v output of the failure would also be useful > It's 72k, so I'll send it to you off list. > Also, fdisk says: > Disk /dev/sdb: 255 heads, 63 sectors, 116960 cylinders > Units =3D cylinders of 16065 * 512 bytes > Device Boot Start End Blocks Id System > /dev/sdb1 1 116960 939481168+ 83 Linux > -Dave -- Keith Matthews Frequentous Consultants - Linux Services,=20 =09=09Oracle development & database administration From owner-linux-xfs@oss.sgi.com Tue Jan 29 12:25:34 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0TKPYg24580 for linux-xfs-outgoing; Tue, 29 Jan 2002 12:25:34 -0800 Received: from Cantor.suse.de (ns.suse.de [213.95.15.193]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0TKPHd24074 for ; Tue, 29 Jan 2002 12:25:18 -0800 Received: from Hermes.suse.de (Hermes.suse.de [213.95.15.136]) by Cantor.suse.de (Postfix) with ESMTP id 2216A1E938; Tue, 29 Jan 2002 20:25:10 +0100 (MET) Date: Tue, 29 Jan 2002 20:25:09 +0100 From: Andi Kleen To: Andi Kleen Cc: Nathan Scott , linux-xfs@oss.sgi.com Subject: Re: [PATCH] Re: Reduce XFS footprint (was Re: TAKE - remove a function xfs added to filemap.c Message-ID: <20020129202509.A31370@wotan.suse.de> References: <200201291751.g0THp897004750@scare.vieo.com> <20020129194001.A16401@wotan.suse.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20020129194001.A16401@wotan.suse.de> User-Agent: Mutt/1.3.22.1i Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 4117 Lines: 130 On Tue, Jan 29, 2002 at 07:40:01PM +0100, Andi Kleen wrote: > This patch does it. It's very simple and clean. > Saves another 18K on a xfs with BIG_FILESYSTEMS and BIG_FILES disabled. Oops. The patch had a silly mistake. The dep_mbools were missing the third parameter. It wasn't noticed by make oldconfig, but the more advanced configurators notice. Here is an update. Should probably also write some help text. -Andi --- linux/fs/xfs/xfs_types.h-V1 Wed Aug 8 16:08:34 2001 +++ linux/fs/xfs/xfs_types.h Tue Jan 29 18:57:17 2002 @@ -43,8 +43,17 @@ * defs files for the normal case. */ +#ifdef CONFIG_XFS_BIG_FILES #define XFS_BIG_FILES 1 +#else +#define XFS_BIG_FILES 0 +#endif + +#ifdef CONFIG_XFS_BIG_FILESYSTEMS #define XFS_BIG_FILESYSTEMS 1 +#else +#define XFS_BIG_FILESYSTEMS 0 +#endif typedef __uint32_t xfs_agblock_t; /* blockno in alloc. group */ typedef __uint32_t xfs_extlen_t; /* extent length in blocks */ --- linux/fs/xfs/xfsidbg.c-V1 Sun Jan 27 15:42:22 2002 +++ linux/fs/xfs/xfsidbg.c Tue Jan 29 19:23:47 2002 @@ -2475,7 +2475,7 @@ #else kdb_printf(" blk %d bp 0x%p blkno 0x%Lx", #endif - i, p->blk[i].bp, p->blk[i].blkno); + i, p->blk[i].bp, (unsigned long long)p->blk[i].blkno); kdb_printf(" index %d hashval 0x%x ", p->blk[i].index, (uint_t)p->blk[i].hashval); switch(p->blk[i].magic) { @@ -2579,7 +2579,7 @@ if (bno == NULLFSBLOCK) sprintf(rval, "NULLFSBLOCK"); else if (ISNULLSTARTBLOCK(bno)) - sprintf(rval, "NULLSTARTBLOCK(%Ld)", STARTBLOCKVAL(bno)); + sprintf(rval, "NULLSTARTBLOCK(%Ld)", (unsigned long long)STARTBLOCKVAL(bno)); else if (mp) sprintf(rval, "%Ld[%x:%x]", (xfs_dfsbno_t)bno, XFS_FSB_TO_AGNO(mp, bno), XFS_FSB_TO_AGBNO(mp, bno)); @@ -3545,7 +3545,7 @@ #if XFS_BIG_FILES kdb_printf(" bp 0x%p blkno 0x%x ", eblk->bp, eblk->blkno); #else - kdb_printf(" bp 0x%x blkno 0x%x ", eblk->bp, eblk->blkno); + kdb_printf(" bp 0x%p blkno 0x%x ", eblk->bp, eblk->blkno); #endif kdb_printf("index %d hashval 0x%x\n", eblk->index, (uint_t)eblk->hashval); } --- linux/fs/xfs/xfs_mount.c-V1 Sun Jan 27 15:42:22 2002 +++ linux/fs/xfs/xfs_mount.c Tue Jan 29 18:46:06 2002 @@ -846,10 +846,18 @@ /* * Select the right directory manager. */ - mp->m_dirops = - XFS_SB_VERSION_HASDIRV2(&mp->m_sb) ? - xfsv2_dirops : - xfsv1_dirops; + + if (!XFS_SB_VERSION_HASDIRV2(&mp->m_sb)) { +#ifdef CONFIG_XFS_V1_DIR + mp->m_dirops = xfsv1_dirops; +#else + cmn_err(CE_WARN, "XFS: v1 directories not compiled in"); + goto error1; +#endif + } else { + mp->m_dirops = xfsv2_dirops; + } + /* * Initialize directory manager's entries. --- linux/fs/xfs/Makefile-V1 Tue Jan 29 18:47:03 2002 +++ linux/fs/xfs/Makefile Tue Jan 29 19:33:41 2002 @@ -73,6 +73,10 @@ obj-y += xfs_grio.o endif +ifneq ($(CONFIG_XFS_V1_DIR),) + obj-y += xfs_dir.o xfs_dir_leaf.o +endif + ifeq ($(CONFIG_HAVE_XFS_DMAPI),) obj-y += xfsdmapistubs.o else @@ -100,7 +104,6 @@ xfs_btree.o \ xfs_buf_item.o \ xfs_da_btree.o \ - xfs_dir.o \ xfs_dir2.o \ xfs_dir2_block.o \ xfs_dir2_data.o \ @@ -108,7 +111,6 @@ xfs_dir2_node.o \ xfs_dir2_sf.o \ xfs_dir2_trace.o \ - xfs_dir_leaf.o \ xfs_error.o \ xfs_extfree_item.o \ xfs_fsops.o \ --- linux/fs/Config.in-V1 Sun Jan 27 15:42:16 2002 +++ linux/fs/Config.in Tue Jan 29 20:22:16 2002 @@ -89,7 +89,10 @@ tristate 'SGI XFS filesystem support' CONFIG_XFS_FS dep_mbool ' Enable XFS Realtime support' CONFIG_XFS_RT $CONFIG_XFS_FS -dep_mbool ' Enable XFS Quota' CONFIG_XFS_QUOTA $CONFIG_XFS_FS +dep_mbool ' Enable XFS Quota' CONFIG_XFS_QUOTA $CONFIG_XFS_FS +dep_mbool ' Enable XFSv1 directories' CONFIG_XFS_V1_DIR $CONFIG_XFS_FS +dep_mbool ' Enable XFS filesystems greater than 2TB' CONFIG_XFS_BIG_FILESYSTEMS $CONFIG_XFS_FS +dep_mbool ' Enable XFS files greater than 2GB' CONFIG_XFS_BIG_FILES $CONFIG_XFS_FS if [ "$CONFIG_XFS_FS" != "n" ]; then define_bool CONFIG_HAVE_ATTRCTL y dep_tristate ' Enable XFS DMAPI' CONFIG_XFS_DMAPI $CONFIG_XFS_FS From owner-linux-xfs@oss.sgi.com Tue Jan 29 12:36:43 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0TKahF24889 for linux-xfs-outgoing; Tue, 29 Jan 2002 12:36:43 -0800 Received: from clubphoto.com (mail-gw.clubphoto.com [64.124.34.66]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0TKaed24867 for ; Tue, 29 Jan 2002 12:36:40 -0800 Received: from [192.168.168.136] ([192.168.168.136]) by clubphoto.com (8.9.3/8.9.3) with ESMTP id LAA27985 for ; Tue, 29 Jan 2002 11:36:36 -0800 User-Agent: Microsoft-Entourage/10.0.0.1309 Date: Tue, 29 Jan 2002 11:36:47 -0800 Subject: 2.4.5 vs. 2.4.16 From: "Gabe E. Nydick" To: Message-ID: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 793 Lines: 17 Hey folks, I've been using xfs since 1.0 was released and many of my machines have 2.4.5 on them and I get weirdnesses. So as new patches come out, I've been upgrading to a new kernel version. The latest one I'm using is a 2.4.16 w/XFS+EXT3. I've started migrating away from xfs because of problems like, under heavy load, my entire file system got corrupt, missing files on non-busy machines, etc. Given the advantages XFS has over EXT3, performance, and file size, I would like to know first of all, what kernel version w/which patch w/which compiler makes a stable 2.4.x xfs kernel that won't trash my filesystem. Second, I would like to know, in what way I can beat up my machine to test for these sort of failures that plagued previous versions of xfs? Thanks, Gabe E. Nydick From owner-linux-xfs@oss.sgi.com Tue Jan 29 12:58:11 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0TKwB125414 for linux-xfs-outgoing; Tue, 29 Jan 2002 12:58:11 -0800 Received: from pneumatic-tube.sgi.com (pneumatic-tube.sgi.com [204.94.214.22]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0TKw6d25392 for ; Tue, 29 Jan 2002 12:58:06 -0800 Received: from zeus-e8.americas.sgi.com (zeus-e8.americas.sgi.com [128.162.8.103]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id LAA02146 for ; Tue, 29 Jan 2002 11:59:04 -0800 (PST) mail_from (sandeen@sgi.com) Received: from poppy-e185.americas.sgi.com (poppy-e185.americas.sgi.com [128.162.185.207]) by zeus-e8.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id NAA204283; Tue, 29 Jan 2002 13:56:47 -0600 (CST) Received: from stout.americas.sgi.com (stout.americas.sgi.com [128.162.187.5]) by poppy-e185.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.7) with ESMTP id NAA50771; Tue, 29 Jan 2002 13:56:41 -0600 (CST) Subject: Re: [PATCH] Re: Reduce XFS footprint (was Re: TAKE - remove a function xfs added to filemap.c From: Eric Sandeen To: Andi Kleen Cc: Nathan Scott , linux-xfs@oss.sgi.com In-Reply-To: <20020129202509.A31370@wotan.suse.de> References: <200201291751.g0THp897004750@scare.vieo.com> <20020129194001.A16401@wotan.suse.de> <20020129202509.A31370@wotan.suse.de> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/1.0 (Preview Release) Date: 29 Jan 2002 13:56:41 -0600 Message-Id: <1012334201.5905.25.camel@stout.americas.sgi.com> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 1450 Lines: 39 On Tue, 2002-01-29 at 13:25, Andi Kleen wrote: > On Tue, Jan 29, 2002 at 07:40:01PM +0100, Andi Kleen wrote: > > This patch does it. It's very simple and clean. > > Saves another 18K on a xfs with BIG_FILESYSTEMS and BIG_FILES disabled. > > Oops. The patch had a silly mistake. The dep_mbools were missing the third > parameter. It wasn't noticed by make oldconfig, but the more advanced > configurators notice. > > Here is an update. Should probably also write some help text. Yep, I just saw that. And FWIW, the stated limit for the filesystem size w/o XFS_BIG_FILESYSTEMS isn't quite right*. I think these are correct (these are internal XFS limitations): File size: o Without XFS_BIG_FILES, the max filesize is 1<<40, or 2TiB. o With XFS_BIG_FILES, the max filesize is 1<<63-1. However, Linux can only handle 1<<(32+PAGE_SHIFT), or (2GiB * PAGE_SIZE), or 16TiB for machines w/ 4k pages. This limit has been added to the current Linux XFS code as well. Filesystem size: o Without XFS_BIG_FILESYSTEMS, the max filesystem size is the (filesystem block size * INT_MAX), or on x86 w/ 4k block sizes, 2^43, or about 8 TiB (which is bigger than Linux can handle). o With XFS_BIG_FILESYSTEMS, it's 9 exabytes, I believe. (again, larger than Linux can handle). -Eric *Not that it matters, since Linux can't do > 2T anyway... -- Eric Sandeen XFS for Linux http://oss.sgi.com/projects/xfs sandeen@sgi.com SGI, Inc. From owner-linux-xfs@oss.sgi.com Tue Jan 29 13:01:06 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0TL16g25607 for linux-xfs-outgoing; Tue, 29 Jan 2002 13:01:06 -0800 Received: from moutng1.schlund.de (moutng1.kundenserver.de [212.227.126.171]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0TL0md25580 for ; Tue, 29 Jan 2002 13:00:48 -0800 Received: from [195.20.224.220] (helo=mrvdom04.kundenserver.de) by moutng1.schlund.de with esmtp (Exim 3.22 #2) id 16VeQr-00085F-00; Tue, 29 Jan 2002 21:00:41 +0100 Received: from [80.129.49.43] (helo=kernelpanix.aura.of.mankind) by mrvdom04.kundenserver.de with esmtp (Exim 2.12 #2) id 16VeQq-0007NU-00; Tue, 29 Jan 2002 21:00:41 +0100 Received: (from utz@localhost) by kernelpanix.aura.of.mankind (8.11.2/8.11.2) id g0TJurE13563; Tue, 29 Jan 2002 20:56:53 +0100 X-Authentication-Warning: kernelpanix.aura.of.mankind: utz set sender to xfs@s2y4n2c.de using -f Date: Tue, 29 Jan 2002 20:56:53 +0100 From: utz lehmann To: Andi Kleen Cc: linux-xfs@oss.sgi.com Subject: Re: [PATCH] Re: Reduce XFS footprint (was Re: TAKE - remove a function xfs added to filemap.c Message-ID: <20020129205653.A13502@s2y4n2c.de> References: <200201291751.g0THp897004750@scare.vieo.com> <20020129194001.A16401@wotan.suse.de> <20020129202509.A31370@wotan.suse.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20020129202509.A31370@wotan.suse.de> Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 4680 Lines: 145 Hi I have a few questions. Is xfs using less 64bit arithmetics when compiled without XFS_BIG_FILESYSTEMS and/or XFS_BIG_FILES? I think this will save some cpu cyles on x86. What happends with old files larger than 2GB, when a kernel without XFS_BIG_FILES is used? utz Andi Kleen [ak@suse.de] wrote: > On Tue, Jan 29, 2002 at 07:40:01PM +0100, Andi Kleen wrote: > > This patch does it. It's very simple and clean. > > Saves another 18K on a xfs with BIG_FILESYSTEMS and BIG_FILES disabled. > > Oops. The patch had a silly mistake. The dep_mbools were missing the third > parameter. It wasn't noticed by make oldconfig, but the more advanced > configurators notice. > > Here is an update. Should probably also write some help text. > > -Andi > > --- linux/fs/xfs/xfs_types.h-V1 Wed Aug 8 16:08:34 2001 > +++ linux/fs/xfs/xfs_types.h Tue Jan 29 18:57:17 2002 > @@ -43,8 +43,17 @@ > * defs files for the normal case. > */ > > +#ifdef CONFIG_XFS_BIG_FILES > #define XFS_BIG_FILES 1 > +#else > +#define XFS_BIG_FILES 0 > +#endif > + > +#ifdef CONFIG_XFS_BIG_FILESYSTEMS > #define XFS_BIG_FILESYSTEMS 1 > +#else > +#define XFS_BIG_FILESYSTEMS 0 > +#endif > > typedef __uint32_t xfs_agblock_t; /* blockno in alloc. group */ > typedef __uint32_t xfs_extlen_t; /* extent length in blocks */ > --- linux/fs/xfs/xfsidbg.c-V1 Sun Jan 27 15:42:22 2002 > +++ linux/fs/xfs/xfsidbg.c Tue Jan 29 19:23:47 2002 > @@ -2475,7 +2475,7 @@ > #else > kdb_printf(" blk %d bp 0x%p blkno 0x%Lx", > #endif > - i, p->blk[i].bp, p->blk[i].blkno); > + i, p->blk[i].bp, (unsigned long long)p->blk[i].blkno); > kdb_printf(" index %d hashval 0x%x ", > p->blk[i].index, (uint_t)p->blk[i].hashval); > switch(p->blk[i].magic) { > @@ -2579,7 +2579,7 @@ > if (bno == NULLFSBLOCK) > sprintf(rval, "NULLFSBLOCK"); > else if (ISNULLSTARTBLOCK(bno)) > - sprintf(rval, "NULLSTARTBLOCK(%Ld)", STARTBLOCKVAL(bno)); > + sprintf(rval, "NULLSTARTBLOCK(%Ld)", (unsigned long long)STARTBLOCKVAL(bno)); > else if (mp) > sprintf(rval, "%Ld[%x:%x]", (xfs_dfsbno_t)bno, > XFS_FSB_TO_AGNO(mp, bno), XFS_FSB_TO_AGBNO(mp, bno)); > @@ -3545,7 +3545,7 @@ > #if XFS_BIG_FILES > kdb_printf(" bp 0x%p blkno 0x%x ", eblk->bp, eblk->blkno); > #else > - kdb_printf(" bp 0x%x blkno 0x%x ", eblk->bp, eblk->blkno); > + kdb_printf(" bp 0x%p blkno 0x%x ", eblk->bp, eblk->blkno); > #endif > kdb_printf("index %d hashval 0x%x\n", eblk->index, (uint_t)eblk->hashval); > } > --- linux/fs/xfs/xfs_mount.c-V1 Sun Jan 27 15:42:22 2002 > +++ linux/fs/xfs/xfs_mount.c Tue Jan 29 18:46:06 2002 > @@ -846,10 +846,18 @@ > /* > * Select the right directory manager. > */ > - mp->m_dirops = > - XFS_SB_VERSION_HASDIRV2(&mp->m_sb) ? > - xfsv2_dirops : > - xfsv1_dirops; > + > + if (!XFS_SB_VERSION_HASDIRV2(&mp->m_sb)) { > +#ifdef CONFIG_XFS_V1_DIR > + mp->m_dirops = xfsv1_dirops; > +#else > + cmn_err(CE_WARN, "XFS: v1 directories not compiled in"); > + goto error1; > +#endif > + } else { > + mp->m_dirops = xfsv2_dirops; > + } > + > > /* > * Initialize directory manager's entries. > --- linux/fs/xfs/Makefile-V1 Tue Jan 29 18:47:03 2002 > +++ linux/fs/xfs/Makefile Tue Jan 29 19:33:41 2002 > @@ -73,6 +73,10 @@ > obj-y += xfs_grio.o > endif > > +ifneq ($(CONFIG_XFS_V1_DIR),) > + obj-y += xfs_dir.o xfs_dir_leaf.o > +endif > + > ifeq ($(CONFIG_HAVE_XFS_DMAPI),) > obj-y += xfsdmapistubs.o > else > @@ -100,7 +104,6 @@ > xfs_btree.o \ > xfs_buf_item.o \ > xfs_da_btree.o \ > - xfs_dir.o \ > xfs_dir2.o \ > xfs_dir2_block.o \ > xfs_dir2_data.o \ > @@ -108,7 +111,6 @@ > xfs_dir2_node.o \ > xfs_dir2_sf.o \ > xfs_dir2_trace.o \ > - xfs_dir_leaf.o \ > xfs_error.o \ > xfs_extfree_item.o \ > xfs_fsops.o \ > --- linux/fs/Config.in-V1 Sun Jan 27 15:42:16 2002 > +++ linux/fs/Config.in Tue Jan 29 20:22:16 2002 > @@ -89,7 +89,10 @@ > > tristate 'SGI XFS filesystem support' CONFIG_XFS_FS > dep_mbool ' Enable XFS Realtime support' CONFIG_XFS_RT $CONFIG_XFS_FS > -dep_mbool ' Enable XFS Quota' CONFIG_XFS_QUOTA $CONFIG_XFS_FS > +dep_mbool ' Enable XFS Quota' CONFIG_XFS_QUOTA $CONFIG_XFS_FS > +dep_mbool ' Enable XFSv1 directories' CONFIG_XFS_V1_DIR $CONFIG_XFS_FS > +dep_mbool ' Enable XFS filesystems greater than 2TB' CONFIG_XFS_BIG_FILESYSTEMS $CONFIG_XFS_FS > +dep_mbool ' Enable XFS files greater than 2GB' CONFIG_XFS_BIG_FILES $CONFIG_XFS_FS > if [ "$CONFIG_XFS_FS" != "n" ]; then > define_bool CONFIG_HAVE_ATTRCTL y > dep_tristate ' Enable XFS DMAPI' CONFIG_XFS_DMAPI $CONFIG_XFS_FS From owner-linux-xfs@oss.sgi.com Tue Jan 29 13:11:22 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0TLBM625918 for linux-xfs-outgoing; Tue, 29 Jan 2002 13:11:22 -0800 Received: from zok.sgi.com (zok.SGI.COM [204.94.215.101]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0TLBHd25895 for ; Tue, 29 Jan 2002 13:11:17 -0800 Received: from zeus-e8.americas.sgi.com (zeus-e8.americas.sgi.com [128.162.8.103]) by zok.sgi.com (8.11.4/8.11.4/linux-outbound_gateway-1.1) with ESMTP id g0TKB9o13579 for ; Tue, 29 Jan 2002 12:11:09 -0800 Received: from poppy-e185.americas.sgi.com (poppy-e185.americas.sgi.com [128.162.185.207]) by zeus-e8.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id OAA204477; Tue, 29 Jan 2002 14:09:54 -0600 (CST) Received: from stout.americas.sgi.com (stout.americas.sgi.com [128.162.187.5]) by poppy-e185.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.7) with ESMTP id OAA44770; Tue, 29 Jan 2002 14:09:53 -0600 (CST) Subject: Re: [PATCH] Re: Reduce XFS footprint (was Re: TAKE - remove a function xfs added to filemap.c From: Eric Sandeen To: utz lehmann Cc: Andi Kleen , linux-xfs@oss.sgi.com In-Reply-To: <20020129205653.A13502@s2y4n2c.de> References: <200201291751.g0THp897004750@scare.vieo.com> <20020129194001.A16401@wotan.suse.de> <20020129202509.A31370@wotan.suse.de> <20020129205653.A13502@s2y4n2c.de> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/1.0 (Preview Release) Date: 29 Jan 2002 14:09:53 -0600 Message-Id: <1012334993.5905.30.camel@stout.americas.sgi.com> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 675 Lines: 24 On Tue, 2002-01-29 at 13:56, utz lehmann wrote: > Hi > > I have a few questions. > > Is xfs using less 64bit arithmetics when compiled without > XFS_BIG_FILESYSTEMS and/or XFS_BIG_FILES? I think this will save some cpu > cyles on x86. I have this same question, I'll do some benchmarking to find out. > What happends with old files larger than 2GB, when a kernel without > XFS_BIG_FILES is used? sb->s_maxbytes gets set to a smaller value, so all the normal kernel size checks kick in, and you won't be able to seek/truncate/read/write past the smaller value. -Eric -- Eric Sandeen XFS for Linux http://oss.sgi.com/projects/xfs sandeen@sgi.com SGI, Inc. From owner-linux-xfs@oss.sgi.com Tue Jan 29 13:18:24 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0TLIOE27040 for linux-xfs-outgoing; Tue, 29 Jan 2002 13:18:24 -0800 Received: from Cantor.suse.de (ns.suse.de [213.95.15.193]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0TLI6d27018 for ; Tue, 29 Jan 2002 13:18:06 -0800 Received: from Hermes.suse.de (Hermes.suse.de [213.95.15.136]) by Cantor.suse.de (Postfix) with ESMTP id B960F1E781; Tue, 29 Jan 2002 21:17:58 +0100 (MET) Date: Tue, 29 Jan 2002 21:17:58 +0100 From: Andi Kleen To: Eric Sandeen Cc: Andi Kleen , Nathan Scott , linux-xfs@oss.sgi.com Subject: Re: [PATCH] Re: Reduce XFS footprint (was Re: TAKE - remove a function xfs added to filemap.c Message-ID: <20020129211758.A8117@wotan.suse.de> References: <200201291751.g0THp897004750@scare.vieo.com> <20020129194001.A16401@wotan.suse.de> <20020129202509.A31370@wotan.suse.de> <1012334201.5905.25.camel@stout.americas.sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1012334201.5905.25.camel@stout.americas.sgi.com> User-Agent: Mutt/1.3.22.1i Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 5157 Lines: 165 On Tue, Jan 29, 2002 at 01:56:41PM -0600, Eric Sandeen wrote: > Yep, I just saw that. And FWIW, the stated limit for the filesystem > size w/o XFS_BIG_FILESYSTEMS isn't quite right*. I think these are > correct (these are internal XFS limitations): > > File size: > o Without XFS_BIG_FILES, the max filesize is 1<<40, or 2TiB. I misread blockno in xfs_types.h as byteno. It should be 2^31 * blocksize, which would be 2^43 with 4K blocks or more with bigger block size. I don't see any other limit. How do you get to 2^40 ? Also Linux/32bit is VM limited to 2^31 * PAGE_SIZE, so assuming PAGE_SIZE== blocksize XFS_BIG_FILES should not be needed at all on 32bit linux. On 64bit it probably makes sense to hardcode them both to 1. Where I am wrong ? > o With XFS_BIG_FILES, the max filesize is 1<<63-1. > However, Linux can only handle 1<<(32+PAGE_SHIFT), or 2^(31+PAGE_SHIFT) > (2GiB * PAGE_SIZE), or 16TiB for machines w/ 4k pages. I come to 8TB, which would be the same limit as I get to for !XFS_BIG_FILES above for 4K fs. The only special case where XFS_BIG_FILES would be needed again would be PAGE_SIZE *Not that it matters, since Linux can't do > 2T anyway... 2.5 should handle it soon. In summary I think: - XFS_BIG_FILES and XFS_BIG_FILESYSTEMS should be both be set to 0 on 32bit, but can be set to 1 on 64bit systems because it shouldn't make much difference there anyways except some more cache footprint. - In 2.5 as soon as sector_t becomes 64bit XFS_BIG_FILESYSTEMS should be set to one unconditional. This revised patch implements this. -Andi --- linux/fs/xfs/xfs_types.h-V1 Wed Aug 8 16:08:34 2001 +++ linux/fs/xfs/xfs_types.h Tue Jan 29 21:15:22 2002 @@ -43,8 +43,17 @@ * defs files for the normal case. */ +#if BITS_PER_LONG==64 #define XFS_BIG_FILES 1 +#else +#define XFS_BIG_FILES 0 +#endif + +#if BITS_PER_LONG==64 || defined(BLK_64BIT_SECTOR) #define XFS_BIG_FILESYSTEMS 1 +#else +#define XFS_BIG_FILESYSTEMS 0 +#endif typedef __uint32_t xfs_agblock_t; /* blockno in alloc. group */ typedef __uint32_t xfs_extlen_t; /* extent length in blocks */ --- linux/fs/xfs/xfsidbg.c-V1 Sun Jan 27 15:42:22 2002 +++ linux/fs/xfs/xfsidbg.c Tue Jan 29 19:23:47 2002 @@ -2475,7 +2475,7 @@ #else kdb_printf(" blk %d bp 0x%p blkno 0x%Lx", #endif - i, p->blk[i].bp, p->blk[i].blkno); + i, p->blk[i].bp, (unsigned long long)p->blk[i].blkno); kdb_printf(" index %d hashval 0x%x ", p->blk[i].index, (uint_t)p->blk[i].hashval); switch(p->blk[i].magic) { @@ -2579,7 +2579,7 @@ if (bno == NULLFSBLOCK) sprintf(rval, "NULLFSBLOCK"); else if (ISNULLSTARTBLOCK(bno)) - sprintf(rval, "NULLSTARTBLOCK(%Ld)", STARTBLOCKVAL(bno)); + sprintf(rval, "NULLSTARTBLOCK(%Ld)", (unsigned long long)STARTBLOCKVAL(bno)); else if (mp) sprintf(rval, "%Ld[%x:%x]", (xfs_dfsbno_t)bno, XFS_FSB_TO_AGNO(mp, bno), XFS_FSB_TO_AGBNO(mp, bno)); @@ -3545,7 +3545,7 @@ #if XFS_BIG_FILES kdb_printf(" bp 0x%p blkno 0x%x ", eblk->bp, eblk->blkno); #else - kdb_printf(" bp 0x%x blkno 0x%x ", eblk->bp, eblk->blkno); + kdb_printf(" bp 0x%p blkno 0x%x ", eblk->bp, eblk->blkno); #endif kdb_printf("index %d hashval 0x%x\n", eblk->index, (uint_t)eblk->hashval); } --- linux/fs/xfs/xfs_mount.c-V1 Sun Jan 27 15:42:22 2002 +++ linux/fs/xfs/xfs_mount.c Tue Jan 29 18:46:06 2002 @@ -846,10 +846,18 @@ /* * Select the right directory manager. */ - mp->m_dirops = - XFS_SB_VERSION_HASDIRV2(&mp->m_sb) ? - xfsv2_dirops : - xfsv1_dirops; + + if (!XFS_SB_VERSION_HASDIRV2(&mp->m_sb)) { +#ifdef CONFIG_XFS_V1_DIR + mp->m_dirops = xfsv1_dirops; +#else + cmn_err(CE_WARN, "XFS: v1 directories not compiled in"); + goto error1; +#endif + } else { + mp->m_dirops = xfsv2_dirops; + } + /* * Initialize directory manager's entries. --- linux/fs/xfs/Makefile-V1 Tue Jan 29 18:47:03 2002 +++ linux/fs/xfs/Makefile Tue Jan 29 19:33:41 2002 @@ -73,6 +73,10 @@ obj-y += xfs_grio.o endif +ifneq ($(CONFIG_XFS_V1_DIR),) + obj-y += xfs_dir.o xfs_dir_leaf.o +endif + ifeq ($(CONFIG_HAVE_XFS_DMAPI),) obj-y += xfsdmapistubs.o else @@ -100,7 +104,6 @@ xfs_btree.o \ xfs_buf_item.o \ xfs_da_btree.o \ - xfs_dir.o \ xfs_dir2.o \ xfs_dir2_block.o \ xfs_dir2_data.o \ @@ -108,7 +111,6 @@ xfs_dir2_node.o \ xfs_dir2_sf.o \ xfs_dir2_trace.o \ - xfs_dir_leaf.o \ xfs_error.o \ xfs_extfree_item.o \ xfs_fsops.o \ --- linux/fs/Config.in-V1 Sun Jan 27 15:42:16 2002 +++ linux/fs/Config.in Tue Jan 29 21:13:02 2002 @@ -89,7 +89,8 @@ tristate 'SGI XFS filesystem support' CONFIG_XFS_FS dep_mbool ' Enable XFS Realtime support' CONFIG_XFS_RT $CONFIG_XFS_FS -dep_mbool ' Enable XFS Quota' CONFIG_XFS_QUOTA $CONFIG_XFS_FS +dep_mbool ' Enable XFS Quota' CONFIG_XFS_QUOTA $CONFIG_XFS_FS +dep_mbool ' Enable XFSv1 directories' CONFIG_XFS_V1_DIR $CONFIG_XFS_FS if [ "$CONFIG_XFS_FS" != "n" ]; then define_bool CONFIG_HAVE_ATTRCTL y dep_tristate ' Enable XFS DMAPI' CONFIG_XFS_DMAPI $CONFIG_XFS_FS From owner-linux-xfs@oss.sgi.com Tue Jan 29 13:28:17 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0TLSHr27279 for linux-xfs-outgoing; Tue, 29 Jan 2002 13:28:17 -0800 Received: from ADSL-Bergs.RZ.RWTH-Aachen.DE (adsl-bergs.rz.RWTH-Aachen.DE [137.226.80.218]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0TLSDd27249 for ; Tue, 29 Jan 2002 13:28:13 -0800 Received: from [192.168.1.2] (helo=ralf) by ADSL-Bergs.RZ.RWTH-Aachen.DE with smtp (Exim 3.12 #1) id 16VerN-0006ud-00; Tue, 29 Jan 2002 21:28:05 +0100 From: "Ralf G. R. Bergs" To: "linux-xfs@oss.sgi.com" Cc: "Steve Lord" Date: Tue, 29 Jan 2002 21:28:04 +0100 Reply-To: "Ralf G. R. Bergs" X-Mailer: PMMail 2000 Professional (2.20.2380) For Windows 2000 (5.0.2195;2) In-Reply-To: <1012331357.24486.67.camel@jen.americas.sgi.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Subject: Re: [PATCH] Re: Reduce XFS footprint (was Re: TAKE - remove a function xfs added to filemap.c Message-Id: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 773 Lines: 21 On Tue, 29 Jan 2002 13:09:17 -0600, Steve Lord wrote: [...] >XFS has two directory formats, V1 directories were the original, V2 was >a new version written to fix problems with NFS and a few other apps. >Linux always uses V2, the V1 is there for Irix compatibility - but it >can get into loops or miss entries in readdir on linux. So with Andi's patch one should NOT enable V1 directories, or otherwise the XFS code can't read existing V2 filesystems anymore? Is that right? Thanks. -- Verkaufe Original-BMW-Raeder: L I N U X .~. http://adsl-bergs.rz.rwth-aachen.de/~rabe The Choice /V\ of a GNU /( )\ Generation ^^-^^ From owner-linux-xfs@oss.sgi.com Tue Jan 29 13:29:12 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0TLTC927413 for linux-xfs-outgoing; Tue, 29 Jan 2002 13:29:12 -0800 Received: from ADSL-Bergs.RZ.RWTH-Aachen.DE (adsl-bergs.rz.RWTH-Aachen.DE [137.226.80.218]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0TLT9d27391 for ; Tue, 29 Jan 2002 13:29:09 -0800 Received: from [192.168.1.2] (helo=ralf) by ADSL-Bergs.RZ.RWTH-Aachen.DE with smtp (Exim 3.12 #1) id 16VesG-0006um-00; Tue, 29 Jan 2002 21:29:00 +0100 From: "Ralf G. R. Bergs" To: "linux-xfs@oss.sgi.com" Cc: "Keith Matthews" Date: Tue, 29 Jan 2002 21:28:59 +0100 Reply-To: "Ralf G. R. Bergs" X-Mailer: PMMail 2000 Professional (2.20.2380) For Windows 2000 (5.0.2195;2) In-Reply-To: <20020129191320.E6892125E6@rebutia.sweeney.demon.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Subject: Mailing list hic-ups (was Re: Re[2]: mkfs on large h/w RAID fails Message-Id: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 462 Lines: 16 On Tue, 29 Jan 2002 19:13:20 +0000 (GMT), Keith Matthews wrote: [...] >I'm getting this and a number of other posts to the list twice. Anyone >else seeing that ? Me too. :-) -- Verkaufe Original-BMW-Raeder: L I N U X .~. http://adsl-bergs.rz.rwth-aachen.de/~rabe The Choice /V\ of a GNU /( )\ Generation ^^-^^ From owner-linux-xfs@oss.sgi.com Tue Jan 29 13:33:44 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0TLXiS27809 for linux-xfs-outgoing; Tue, 29 Jan 2002 13:33:44 -0800 Received: from yog-sothoth.sgi.com (eugate.sgi.com [192.48.160.10]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0TLXbd27787 for ; Tue, 29 Jan 2002 13:33:38 -0800 Received: from zeus-e8.americas.sgi.com (zeus-e8.americas.sgi.com [128.162.8.103]) by yog-sothoth.sgi.com (980305.SGI.8.8.8-aspam-6.2/980304.SGI-aspam-europe) via ESMTP id VAA13625 for ; Tue, 29 Jan 2002 21:31:49 +0100 (CET) mail_from (sandeen@sgi.com) Received: from poppy-e185.americas.sgi.com (poppy-e185.americas.sgi.com [128.162.185.207]) by zeus-e8.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id OAA204094; Tue, 29 Jan 2002 14:32:16 -0600 (CST) Received: from stout.americas.sgi.com (stout.americas.sgi.com [128.162.187.5]) by poppy-e185.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.7) with ESMTP id OAA55547; Tue, 29 Jan 2002 14:32:16 -0600 (CST) Subject: Re: Mailing list hic-ups (was Re: Re[2]: mkfs on large h/w RAID fails From: Eric Sandeen To: "Ralf G. R. Bergs" Cc: "linux-xfs@oss.sgi.com" , Keith Matthews In-Reply-To: References: Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/1.0 (Preview Release) Date: 29 Jan 2002 14:32:16 -0600 Message-Id: <1012336336.30127.34.camel@stout.americas.sgi.com> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 540 Lines: 19 Russell re-sent things that got inadvertantly filtered yesterday, please bear with us as we resolve these technical difficulties and return you to your regularly scheduled programming... -Eric On Tue, 2002-01-29 at 14:28, Ralf G. R. Bergs wrote: > On Tue, 29 Jan 2002 19:13:20 +0000 (GMT), Keith Matthews wrote: > > [...] > >I'm getting this and a number of other posts to the list twice. Anyone > >else seeing that ? > > Me too. :-) -- Eric Sandeen XFS for Linux http://oss.sgi.com/projects/xfs sandeen@sgi.com SGI, Inc. From owner-linux-xfs@oss.sgi.com Tue Jan 29 13:43:41 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0TLhfr28042 for linux-xfs-outgoing; Tue, 29 Jan 2002 13:43:41 -0800 Received: from yog-sothoth.sgi.com (eugate.sgi.com [192.48.160.10]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0TLhXd28020 for ; Tue, 29 Jan 2002 13:43:33 -0800 Received: from zeus-e8.americas.sgi.com (zeus-e8.americas.sgi.com [128.162.8.103]) by yog-sothoth.sgi.com (980305.SGI.8.8.8-aspam-6.2/980304.SGI-aspam-europe) via ESMTP id VAA13787 for ; Tue, 29 Jan 2002 21:41:44 +0100 (CET) mail_from (sandeen@sgi.com) Received: from poppy-e185.americas.sgi.com (poppy-e185.americas.sgi.com [128.162.185.207]) by zeus-e8.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id OAA204975; Tue, 29 Jan 2002 14:42:12 -0600 (CST) Received: from stout.americas.sgi.com (stout.americas.sgi.com [128.162.187.5]) by poppy-e185.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.7) with ESMTP id OAA91098; Tue, 29 Jan 2002 14:42:12 -0600 (CST) Subject: Re: [PATCH] Re: Reduce XFS footprint (was Re: TAKE - remove a function xfs added to filemap.c From: Eric Sandeen To: Andi Kleen Cc: Nathan Scott , linux-xfs@oss.sgi.com In-Reply-To: <20020129211758.A8117@wotan.suse.de> References: <200201291751.g0THp897004750@scare.vieo.com> <20020129194001.A16401@wotan.suse.de> <20020129202509.A31370@wotan.suse.de> <1012334201.5905.25.camel@stout.americas.sgi.com> <20020129211758.A8117@wotan.suse.de> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/1.0 (Preview Release) Date: 29 Jan 2002 14:42:12 -0600 Message-Id: <1012336932.30169.36.camel@stout.americas.sgi.com> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 1837 Lines: 58 On Tue, 2002-01-29 at 14:17, Andi Kleen wrote: > On Tue, Jan 29, 2002 at 01:56:41PM -0600, Eric Sandeen wrote: > > Yep, I just saw that. And FWIW, the stated limit for the filesystem > > size w/o XFS_BIG_FILESYSTEMS isn't quite right*. I think these are > > correct (these are internal XFS limitations): > > > > File size: > > o Without XFS_BIG_FILES, the max filesize is 1<<40, or 2TiB. > > I misread blockno in xfs_types.h as byteno. It should be 2^31 * blocksize, > which would be 2^43 with 4K blocks or more with bigger block size. > I don't see any other limit. > > How do you get to 2^40 ? in xfs_inode.h: #if XFS_BIG_FILES #define XFS_MAX_FILE_OFFSET ((long long)((1ULL<<(32+PAGE_SHIFT))-1ULL)) #else #define XFS_MAX_FILE_OFFSET ((1LL<<40)-1LL) #endif and XFS_MAX_FILE_OFFSET is used to set sb->s_maxbytes (the latter case is stock XFS, the former is something I changed, might be off by a factor of 2? hm....) The comment blurb says * if XFS_BIG_FILES [...] * else 2^40 - 1 (40=31+9) (might be an int holding a block #) Not quite sure where this comes from, actually. > Also Linux/32bit is VM limited to 2^31 * PAGE_SIZE, so assuming PAGE_SIZE== > blocksize XFS_BIG_FILES should not be needed at all on 32bit linux. Does the VM actually enforce this limit? I thought I had a case where I could create a too-large file if XFS allowed it. Also I thought the limit was 2^32 * PAGE_SIZE... /me goes back to look. > On 64bit it probably makes sense to hardcode them both to 1. > > Where I am wrong ? > > > o With XFS_BIG_FILES, the max filesize is 1<<63-1. > > However, Linux can only handle 1<<(32+PAGE_SHIFT), or > > 2^(31+PAGE_SHIFT) Whoops... so the page cache index is signed...? -Eric -- Eric Sandeen XFS for Linux http://oss.sgi.com/projects/xfs sandeen@sgi.com SGI, Inc. From owner-linux-xfs@oss.sgi.com Tue Jan 29 13:44:36 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0TLiaB28176 for linux-xfs-outgoing; Tue, 29 Jan 2002 13:44:36 -0800 Received: from yog-sothoth.sgi.com (eugate.sgi.com [192.48.160.10]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0TLiTd28154 for ; Tue, 29 Jan 2002 13:44:29 -0800 Received: from zeus-e8.americas.sgi.com (zeus-e8.americas.sgi.com [128.162.8.103]) by yog-sothoth.sgi.com (980305.SGI.8.8.8-aspam-6.2/980304.SGI-aspam-europe) via ESMTP id VAA14056 for ; Tue, 29 Jan 2002 21:42:40 +0100 (CET) mail_from (lord@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by zeus-e8.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id OAA197360; Tue, 29 Jan 2002 14:43:08 -0600 (CST) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id OAA96541; Tue, 29 Jan 2002 14:43:08 -0600 (CST) Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id g0TKfAt26423; Tue, 29 Jan 2002 14:41:10 -0600 Subject: Re: [PATCH] Re: Reduce XFS footprint (was Re: TAKE - remove a function xfs added to filemap.c From: Steve Lord To: "Ralf G. R. Bergs" Cc: "linux-xfs@oss.sgi.com" In-Reply-To: References: Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/1.0.2 Date: 29 Jan 2002 14:41:10 -0600 Message-Id: <1012336870.26363.14.camel@jen.americas.sgi.com> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 1568 Lines: 41 On Tue, 2002-01-29 at 14:28, Ralf G. R. Bergs wrote: > On Tue, 29 Jan 2002 13:09:17 -0600, Steve Lord wrote: > > [...] > >XFS has two directory formats, V1 directories were the original, V2 was > >a new version written to fix problems with NFS and a few other apps. > >Linux always uses V2, the V1 is there for Irix compatibility - but it > >can get into loops or miss entries in readdir on linux. > > So with Andi's patch one should NOT enable V1 directories, or otherwise the XFS > code can't read existing V2 filesystems anymore? Is that right? Noooo, I think you got your 1s and 2s crossed in there. Andi was turning off the backwards compatibility with old irix filesystems (V1) in the patch. It is not exactly a huge win spacewise, but every little helps. This will not affect any existing filesystem made on linux since they all use the V2 code. Right now we are not sure Andi's patch really works for removal of the directory code, since the file he is removing contains functions which are called from V2 code. I would hold off using any of this stuff until we have sorted it all out. Steve > > Thanks. > > > -- > Verkaufe Original-BMW-Raeder: L I N U X .~. > http://adsl-bergs.rz.rwth-aachen.de/~rabe The Choice /V\ > of a GNU /( )\ > Generation ^^-^^ > -- Steve Lord voice: +1-651-683-3511 Principal Engineer, Filesystem Software email: lord@sgi.com From owner-linux-xfs@oss.sgi.com Tue Jan 29 13:47:36 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0TLla228333 for linux-xfs-outgoing; Tue, 29 Jan 2002 13:47:36 -0800 Received: from yog-sothoth.sgi.com (eugate.sgi.com [192.48.160.10]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0TLlWd28311 for ; Tue, 29 Jan 2002 13:47:33 -0800 Received: from zeus-e8.americas.sgi.com (zeus-e8.americas.sgi.com [128.162.8.103]) by yog-sothoth.sgi.com (980305.SGI.8.8.8-aspam-6.2/980304.SGI-aspam-europe) via ESMTP id VAA14217 for ; Tue, 29 Jan 2002 21:45:44 +0100 (CET) mail_from (sandeen@sgi.com) Received: from poppy-e185.americas.sgi.com (poppy-e185.americas.sgi.com [128.162.185.207]) by zeus-e8.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id OAA204834; Tue, 29 Jan 2002 14:46:12 -0600 (CST) Received: from stout.americas.sgi.com (stout.americas.sgi.com [128.162.187.5]) by poppy-e185.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.7) with ESMTP id OAA51217; Tue, 29 Jan 2002 14:46:11 -0600 (CST) Subject: Re: [PATCH] Re: Reduce XFS footprint (was Re: TAKE - remove a function xfs added to filemap.c From: Eric Sandeen To: "Ralf G. R. Bergs" Cc: "linux-xfs@oss.sgi.com" , Steve Lord In-Reply-To: References: Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/1.0 (Preview Release) Date: 29 Jan 2002 14:46:11 -0600 Message-Id: <1012337171.30169.38.camel@stout.americas.sgi.com> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 573 Lines: 19 On Tue, 2002-01-29 at 14:28, Ralf G. R. Bergs wrote: > So with Andi's patch one should NOT enable V1 directories, or otherwise the XFS > code can't read existing V2 filesystems anymore? Is that right? No, with Andi's patch, you can turn V1 on and off, but V2 is always there. Oh, also, I don't think Andi's patch quite works. There are dir2 functions that call code in xfs_dir.c - which is not linked in w/ Andi's patch. Andi, did you load your module? :) -Eric -- Eric Sandeen XFS for Linux http://oss.sgi.com/projects/xfs sandeen@sgi.com SGI, Inc. From owner-linux-xfs@oss.sgi.com Tue Jan 29 13:56:37 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0TLub929716 for linux-xfs-outgoing; Tue, 29 Jan 2002 13:56:37 -0800 Received: from Cantor.suse.de (ns.suse.de [213.95.15.193]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0TLuRd29694 for ; Tue, 29 Jan 2002 13:56:27 -0800 Received: from Hermes.suse.de (Hermes.suse.de [213.95.15.136]) by Cantor.suse.de (Postfix) with ESMTP id 0FE1C1E91A; Tue, 29 Jan 2002 21:56:20 +0100 (MET) Date: Tue, 29 Jan 2002 21:56:19 +0100 From: Andi Kleen To: Eric Sandeen Cc: Andi Kleen , Nathan Scott , linux-xfs@oss.sgi.com Subject: Re: [PATCH] Re: Reduce XFS footprint (was Re: TAKE - remove a function xfs added to filemap.c Message-ID: <20020129215619.A22732@wotan.suse.de> References: <200201291751.g0THp897004750@scare.vieo.com> <20020129194001.A16401@wotan.suse.de> <20020129202509.A31370@wotan.suse.de> <1012334201.5905.25.camel@stout.americas.sgi.com> <20020129211758.A8117@wotan.suse.de> <1012336932.30169.36.camel@stout.americas.sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1012336932.30169.36.camel@stout.americas.sgi.com> User-Agent: Mutt/1.3.22.1i Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 2931 Lines: 79 On Tue, Jan 29, 2002 at 02:42:12PM -0600, Eric Sandeen wrote: > On Tue, 2002-01-29 at 14:17, Andi Kleen wrote: > > On Tue, Jan 29, 2002 at 01:56:41PM -0600, Eric Sandeen wrote: > > > Yep, I just saw that. And FWIW, the stated limit for the filesystem > > > size w/o XFS_BIG_FILESYSTEMS isn't quite right*. I think these are > > > correct (these are internal XFS limitations): > > > > > > File size: > > > o Without XFS_BIG_FILES, the max filesize is 1<<40, or 2TiB. > > > > I misread blockno in xfs_types.h as byteno. It should be 2^31 * blocksize, > > which would be 2^43 with 4K blocks or more with bigger block size. > > I don't see any other limit. > > > > How do you get to 2^40 ? > > in xfs_inode.h: > > #if XFS_BIG_FILES > #define XFS_MAX_FILE_OFFSET ((long long)((1ULL<<(32+PAGE_SHIFT))-1ULL)) > #else > #define XFS_MAX_FILE_OFFSET ((1LL<<40)-1LL) > #endif > > and XFS_MAX_FILE_OFFSET is used to set sb->s_maxbytes > (the latter case is stock XFS, the former is something I changed, might > be off by a factor of 2? hm....) > > The comment blurb says > * if XFS_BIG_FILES [...] > * else 2^40 - 1 (40=31+9) (might be an int holding a block #) > > Not quite sure where this comes from, actually. The 'int' is embedded in the block device interface in 2.4. It applies to the filesystem, not the files (but will hopefully change with the 64bit sector_t in 2.5/bio) If you're sure that XFS doesn't use ints then it would be safe. But anyways 2^40 < 2^43. It makes no sense to support files > the maximum allowed size of block devices right now. So in general my logic should be right and you could just drop a lot of long long usage on 32bit linux (probably saving you a lot of headache with compiler bugs and some binary bloat too :) > > Also Linux/32bit is VM limited to 2^31 * PAGE_SIZE, so assuming PAGE_SIZE== > > blocksize XFS_BIG_FILES should not be needed at all on 32bit linux. > > Does the VM actually enforce this limit? I thought I had a case where I > could create a too-large file if XFS allowed it. Also I thought the > limit was 2^32 * PAGE_SIZE... /me goes back to look. llseek doesn't enforce it, but the VM only uses 32bit page index variables, so it would wrap if it didn't enforce it. The checking has to be done in generic_file_write, but of course in XFS you had to check yourself because you don't use that. > > > On 64bit it probably makes sense to hardcode them both to 1. > > > > Where I am wrong ? > > > > > o With XFS_BIG_FILES, the max filesize is 1<<63-1. > > > However, Linux can only handle 1<<(32+PAGE_SHIFT), or > > > > 2^(31+PAGE_SHIFT) > > Whoops... so the page cache index is signed...? The page index in kernel is not, but some of the ABI. e.g. the mmap64 passes its signed offset argument as PAGE_INDEX, which limits it to LLONG_MAX instead of ULONG_MAX. Also it's generally safe to not challenge the mighty sign extension @) -Andi From owner-linux-xfs@oss.sgi.com Tue Jan 29 14:40:13 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0TMeDo01763 for linux-xfs-outgoing; Tue, 29 Jan 2002 14:40:13 -0800 Received: from zok.sgi.com (zok.SGI.COM [204.94.215.101]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0TMdvd01738 for ; Tue, 29 Jan 2002 14:39:57 -0800 Received: from zeus-e8.americas.sgi.com (zeus-e8.americas.sgi.com [128.162.8.103]) by zok.sgi.com (8.11.4/8.11.4/linux-outbound_gateway-1.1) with ESMTP id g0TLdoo23043 for ; Tue, 29 Jan 2002 13:39:50 -0800 Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by zeus-e8.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id PAA206030 for ; Tue, 29 Jan 2002 15:38:34 -0600 (CST) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id PAA52655 for ; Tue, 29 Jan 2002 15:38:34 -0600 (CST) From: Steve Lord Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id g0TLaai30124; Tue, 29 Jan 2002 15:36:36 -0600 Message-Id: <200201292136.g0TLaai30124@jen.americas.sgi.com> Date: Tue, 29 Jan 2002 15:36:36 -0600 Subject: TAKE - merge up to 2.5.3-pre6 To: linux-xfs@oss.sgi.com Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 4775 Lines: 145 Hey, maybe I got a to: line into this message! Date: Tue Jan 29 13:35:17 PST 2002 Workarea: jen.americas.sgi.com:/src/lord/xfs-merge The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.5.x-xfs Modid: 2.5.x-xfs:slinx:110539a linux/drivers/hotplug/pcihp_skeleton.c - 1.1 linux/Documentation/DocBook/writing_usb_driver.tmpl - 1.1 linux/drivers/base/interface.c - 1.1 linux/drivers/base/fs.c - 1.1 linux/drivers/base/core.c - 1.1 linux/drivers/base/Makefile - 1.1 linux/drivers/pci/pci-driver.c - 1.1 linux/net/ipv6/proc.c - 1.9 linux/net/ipv4/tcp_ipv4.c - 1.41 linux/net/ipv4/icmp.c - 1.26 linux/mm/page_alloc.c - 1.72 linux/kernel/sched.c - 1.55 linux/kernel/fork.c - 1.45 linux/kernel/exit.c - 1.38 linux/kernel/Makefile - 1.27 linux/init/main.c - 1.72 linux/include/net/route.h - 1.15 linux/include/linux/smb_fs_i.h - 1.7 linux/include/linux/smb_fs.h - 1.16 linux/include/linux/sched.h - 1.57 linux/include/linux/ntfs_fs_i.h - 1.9 linux/include/linux/msdos_fs_i.h - 1.5 linux/include/linux/msdos_fs.h - 1.15 linux/include/linux/iso_fs_i.h - 1.4 linux/include/linux/iso_fs.h - 1.14 linux/include/linux/isdn.h - 1.22 linux/include/linux/hfs_fs_i.h - 1.5 linux/include/linux/hfs_fs.h - 1.8 linux/include/linux/fs.h - 1.146 linux/include/linux/adfs_fs_i.h - 1.5 linux/include/linux/adfs_fs.h - 1.6 linux/include/asm-i386/mmu_context.h - 1.16 linux/include/asm-i386/bitops.h - 1.10 linux/fs/vfat/namei.c - 1.24 linux/fs/ufs/super.c - 1.24 linux/fs/sysv/inode.c - 1.29 linux/fs/smbfs/proc.c - 1.14 linux/fs/smbfs/inode.c - 1.27 linux/fs/smbfs/file.c - 1.24 linux/fs/smbfs/dir.c - 1.16 linux/fs/ntfs/macros.h - 1.7 linux/fs/ntfs/fs.c - 1.37 linux/fs/msdos/namei.c - 1.23 linux/fs/isofs/util.c - 1.7 linux/fs/isofs/rock.c - 1.18 linux/fs/isofs/namei.c - 1.8 linux/fs/isofs/inode.c - 1.31 linux/fs/hfs/super.c - 1.13 linux/fs/hfs/inode.c - 1.16 linux/fs/fat/misc.c - 1.13 linux/fs/fat/inode.c - 1.35 linux/fs/fat/file.c - 1.18 linux/fs/fat/fatfs_syms.c - 1.11 linux/fs/fat/dir.c - 1.16 linux/fs/fat/cvf.c - 1.7 linux/fs/fat/cache.c - 1.17 linux/fs/fat/buffer.c - 1.9 linux/fs/ext2/inode.c - 1.40 linux/fs/ext2/ialloc.c - 1.23 linux/fs/buffer.c - 1.107 linux/fs/adfs/super.c - 1.16 linux/fs/adfs/inode.c - 1.21 linux/fs/adfs/dir.c - 1.14 linux/drivers/usb/usb.c - 1.65 linux/drivers/usb/uhci.c - 1.58 linux/drivers/sbus/sbus.c - 1.15 linux/drivers/pci/pci.c - 1.51 linux/drivers/pci/Makefile - 1.18 linux/drivers/isdn/isdn_common.c - 1.33 linux/drivers/char/console.c - 1.27 linux/drivers/Makefile - 1.27 linux/arch/sparc64/defconfig - 1.59 linux/arch/sparc64/config.in - 1.50 linux/arch/sparc/defconfig - 1.30 linux/arch/sparc/config.in - 1.34 linux/arch/i386/kernel/setup.c - 1.67 linux/arch/i386/kernel/process.c - 1.41 linux/arch/i386/kernel/mtrr.c - 1.34 linux/arch/i386/kernel/entry.S - 1.44 linux/arch/i386/defconfig - 1.94 linux/Makefile - 1.180 linux/Documentation/scsi.txt - 1.3 linux/Documentation/scsi-generic.txt - 1.9 linux/include/asm-i386/apic.h - 1.15 linux/include/linux/netfilter_ipv4.h - 1.6 linux/arch/i386/kernel/smpboot.c - 1.31 linux/include/linux/bfs_fs_i.h - 1.4 linux/include/linux/bfs_fs.h - 1.7 linux/fs/bfs/inode.c - 1.19 linux/fs/bfs/file.c - 1.18 linux/fs/bfs/dir.c - 1.16 linux/fs/bfs/bfs_defs.h - 1.4 linux/arch/i386/kernel/apic.c - 1.26 linux/drivers/usb/usb-uhci.c - 1.37 linux/drivers/usb/usb-ohci.c - 1.34 linux/include/linux/usb.h - 1.27 linux/Documentation/DocBook/Makefile - 1.25 linux/net/ipv4/netfilter/iptable_mangle.c - 1.9 linux/net/ipv4/netfilter/ipfwadm_core.c - 1.11 linux/net/ipv4/netfilter/ip_queue.c - 1.12 linux/net/ipv4/netfilter/ip_nat_standalone.c - 1.13 linux/fs/jffs/inode-v23.c - 1.17 linux/fs/jffs/jffs_fm.c - 1.7 linux/drivers/ieee1394/video1394.c - 1.16 linux/fs/reiserfs/super.c - 1.14 linux/fs/ntfs/unistr.c - 1.5 linux/fs/jffs2/dir.c - 1.4 linux/fs/jffs2/malloc.c - 1.2 linux/fs/jffs2/readinode.c - 1.3 linux/fs/jffs2/super.c - 1.5 linux/fs/jffs2/write.c - 1.5 linux/include/linux/jffs2_fs_i.h - 1.2 linux/fs/isofs/compress.c - 1.3 linux/fs/sysv/ChangeLog - 1.5 linux/kernel/device.c - 1.7 linux/drivers/usb/hcd.c - 1.5 linux/drivers/usb/hcd/ehci-hcd.c - 1.4 linux/include/linux/init_task.h - 1.3 linux/drivers/net/wireless/wavelan_cs.c - 1.2 linux/arch/alpha/Config.help - 1.2 linux/arch/arm/Config.help - 1.2 linux/arch/cris/Config.help - 1.2 linux/arch/i386/Config.help - 1.2 linux/arch/ia64/Config.help - 1.2 linux/arch/m68k/Config.help - 1.2 linux/arch/ppc/8xx_io/Config.help - 1.2 linux/arch/ppc/Config.help - 1.2 linux/arch/sh/Config.help - 1.2 linux/drivers/usb/hcd/Config.help - 1.2 linux/drivers/char/Config.help - 1.2 linux/drivers/char/ftape/Config.help - 1.2 linux/drivers/ide/Config.help - 1.2 linux/drivers/isdn/Config.help - 1.2 linux/drivers/mtd/chips/Config.help - 1.2 From owner-linux-xfs@oss.sgi.com Tue Jan 29 15:39:08 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0TNd8Q03110 for linux-xfs-outgoing; Tue, 29 Jan 2002 15:39:08 -0800 Received: from gandalf.cc.purdue.edu (root@gandalf.cc.purdue.edu [128.210.135.25]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0TNd4d03088 for ; Tue, 29 Jan 2002 15:39:04 -0800 Received: from gandalf.cc.purdue.edu (jrj@localhost [127.0.0.1]) by gandalf.cc.purdue.edu (8.9.1/8.9.1) with ESMTP id RAA28586; Tue, 29 Jan 2002 17:38:55 -0500 (EST) Message-Id: <200201292238.RAA28586@gandalf.cc.purdue.edu> To: "Bernhard R. Erdmann" cc: "amanda-users@amanda.org" , Linux XFS Mailing List Subject: Re: Using Amanda with Linux/XFS: "failed to get (valid) bulkstat information" In-reply-to: Your message of "Sun, 27 Jan 2002 17:26:14 +0100." <3C542A26.F204520C@berdmann.de> Reply-to: jrj@cc.purdue.edu Date: Tue, 29 Jan 2002 17:38:55 -0500 From: "John R. Jackson" Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 302 Lines: 10 >here's a patch for Amanda 2.4.2p2 to ignore xfsdump's occasionally >output on busy filesystems ... Thanks. Before I put this in, is there any particular reason you're adding DMP_WARNING? Why not just add these entries as DMP_NORMAL? John R. Jackson, Technical Software Specialist, jrj@purdue.edu From owner-linux-xfs@oss.sgi.com Tue Jan 29 16:30:03 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0U0U3Y04090 for linux-xfs-outgoing; Tue, 29 Jan 2002 16:30:03 -0800 Received: from smtpzilla1.xs4all.nl (smtpzilla1.xs4all.nl [194.109.127.137]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0U0Tsd04065 for ; Tue, 29 Jan 2002 16:29:55 -0800 Received: from auto-nb1.xs4all.nl (qn-212-58-167-191.quicknet.nl [212.58.167.191]) by smtpzilla1.xs4all.nl (8.12.0/8.12.0) with ESMTP id g0TNTgN0037935; Wed, 30 Jan 2002 00:29:48 +0100 (CET) Message-Id: <4.3.2.7.2.20020130001758.02b14100@pop.xs4all.nl> X-Sender: knuffie@pop.xs4all.nl X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 30 Jan 2002 00:28:12 +0100 To: "Gabe E. Nydick" , From: Seth Mos Subject: Re: 2.4.5 vs. 2.4.16 In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 1967 Lines: 44 At 11:36 29-1-2002 -0800, Gabe E. Nydick wrote: >Hey folks, > > I've been using xfs since 1.0 was released and many of my machines have >2.4.5 on them and I get weirdnesses. So as new patches come out, I've been >upgrading to a new kernel version. The latest one I'm using is a 2.4.16 >w/XFS+EXT3. I've started migrating away from xfs because of problems like, >under heavy load, my entire file system got corrupt, missing files on >non-busy machines, etc. Given the advantages XFS has over EXT3, And you made comment of this on the list? Including the specs. Most problems I hit with different 2.4 kernels were problems with 2.4 itself. At work we have a database box with 10GB+ Progres 9 databases on it which has been running just fine. I have also experienced one corrupted fs on a squid cache which caused recovery to cease after a crash. That was fixed with xfs_repair and I have seen problems with squid caches before. The production boxes are all running the 1.0.2 release kernel. Those kernels are originally Red Hat kernels which include fixes for a lot of known bugs which have not been fixed in -linus and also include a whole bunch of drivers for otherwise unsupported but neccesary hardware. They have also been heavily regression tested. >performance, and file size, I would like to know first of all, what kernel >version w/which patch w/which compiler makes a stable 2.4.x xfs kernel that >won't trash my filesystem. Second, I would like to know, in what way I can >beat up my machine to test for these sort of failures that plagued previous >versions of xfs? Most stuff I just think up myself. I look around what programs I have and just run a lot of them simultaneously. The amount of damage I have personally seen on a XFS fs was caused by something between the keyboard and chair. (eg. me) Cheers -- Seth Every program has two purposes one for which it was written and another for which it wasn't I use the last kind. From owner-linux-xfs@oss.sgi.com Tue Jan 29 17:09:26 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0U19Q804707 for linux-xfs-outgoing; Tue, 29 Jan 2002 17:09:26 -0800 Received: from Cantor.suse.de (ns.suse.de [213.95.15.193]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0U196d04685 for ; Tue, 29 Jan 2002 17:09:06 -0800 Received: from Hermes.suse.de (Hermes.suse.de [213.95.15.136]) by Cantor.suse.de (Postfix) with ESMTP id 4E1AB1EABF; Wed, 30 Jan 2002 01:08:58 +0100 (MET) Date: Wed, 30 Jan 2002 01:08:58 +0100 From: Andi Kleen To: Eric Sandeen Cc: "Ralf G. R. Bergs" , "linux-xfs@oss.sgi.com" , Steve Lord Subject: Re: [PATCH] Re: Reduce XFS footprint (was Re: TAKE - remove a function xfs added to filemap.c Message-ID: <20020130010858.A9046@wotan.suse.de> References: <1012337171.30169.38.camel@stout.americas.sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1012337171.30169.38.camel@stout.americas.sgi.com> User-Agent: Mutt/1.3.22.1i Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 5341 Lines: 184 On Tue, Jan 29, 2002 at 02:46:11PM -0600, Eric Sandeen wrote: > On Tue, 2002-01-29 at 14:28, Ralf G. R. Bergs wrote: > > > So with Andi's patch one should NOT enable V1 directories, or otherwise the XFS > > code can't read existing V2 filesystems anymore? Is that right? > > No, with Andi's patch, you can turn V1 on and off, but V2 is always > there. > > Oh, also, I don't think Andi's patch quite works. There are dir2 > functions that call code in xfs_dir.c - which is not linked in w/ Andi's > patch. Andi, did you load your module? :) I loaded a module, but it looks it was the old module. I see I missed xfs_dir_startup. Oops. Here is the updated patch. I think it's not my day today, too many mistakes. Please double check it that I didn't do another one.. -Andi --- linux/fs/xfs/xfs_dir.c-V1 Thu Aug 23 11:58:14 2001 +++ linux/fs/xfs/xfs_dir.c Wed Jan 30 00:58:47 2002 @@ -147,18 +147,6 @@ * Overall external interface routines. *========================================================================*/ -xfs_dahash_t xfs_dir_hash_dot, xfs_dir_hash_dotdot; - -/* - * One-time startup routine called from xfs_init(). - */ -void -xfs_dir_startup(void) -{ - xfs_dir_hash_dot = xfs_da_hashname(".", 1); - xfs_dir_hash_dotdot = xfs_da_hashname("..", 2); -} - /* * Initialize directory-related fields in the mount structure. */ --- linux/fs/xfs/xfs_types.h-V1 Wed Aug 8 16:08:34 2001 +++ linux/fs/xfs/xfs_types.h Tue Jan 29 21:15:22 2002 @@ -43,8 +43,17 @@ * defs files for the normal case. */ +#if BITS_PER_LONG==64 #define XFS_BIG_FILES 1 +#else +#define XFS_BIG_FILES 0 +#endif + +#if BITS_PER_LONG==64 || defined(BLK_64BIT_SECTOR) #define XFS_BIG_FILESYSTEMS 1 +#else +#define XFS_BIG_FILESYSTEMS 0 +#endif typedef __uint32_t xfs_agblock_t; /* blockno in alloc. group */ typedef __uint32_t xfs_extlen_t; /* extent length in blocks */ --- linux/fs/xfs/xfs_dir2.c-V1 Mon Apr 23 21:52:01 2001 +++ linux/fs/xfs/xfs_dir2.c Wed Jan 30 00:58:44 2002 @@ -90,6 +90,20 @@ xd_shortform_to_single: xfs_dir2_sf_to_block, }; + +xfs_dahash_t xfs_dir_hash_dot, xfs_dir_hash_dotdot; + +/* + * One-time startup routine called from xfs_init(). + */ +void +xfs_dir_startup(void) +{ + xfs_dir_hash_dot = xfs_da_hashname(".", 1); + xfs_dir_hash_dotdot = xfs_da_hashname("..", 2); +} + + /* * Interface routines. */ --- linux/fs/xfs/xfsidbg.c-V1 Sun Jan 27 15:42:22 2002 +++ linux/fs/xfs/xfsidbg.c Tue Jan 29 19:23:47 2002 @@ -2475,7 +2475,7 @@ #else kdb_printf(" blk %d bp 0x%p blkno 0x%Lx", #endif - i, p->blk[i].bp, p->blk[i].blkno); + i, p->blk[i].bp, (unsigned long long)p->blk[i].blkno); kdb_printf(" index %d hashval 0x%x ", p->blk[i].index, (uint_t)p->blk[i].hashval); switch(p->blk[i].magic) { @@ -2579,7 +2579,7 @@ if (bno == NULLFSBLOCK) sprintf(rval, "NULLFSBLOCK"); else if (ISNULLSTARTBLOCK(bno)) - sprintf(rval, "NULLSTARTBLOCK(%Ld)", STARTBLOCKVAL(bno)); + sprintf(rval, "NULLSTARTBLOCK(%Ld)", (unsigned long long)STARTBLOCKVAL(bno)); else if (mp) sprintf(rval, "%Ld[%x:%x]", (xfs_dfsbno_t)bno, XFS_FSB_TO_AGNO(mp, bno), XFS_FSB_TO_AGBNO(mp, bno)); @@ -3545,7 +3545,7 @@ #if XFS_BIG_FILES kdb_printf(" bp 0x%p blkno 0x%x ", eblk->bp, eblk->blkno); #else - kdb_printf(" bp 0x%x blkno 0x%x ", eblk->bp, eblk->blkno); + kdb_printf(" bp 0x%p blkno 0x%x ", eblk->bp, eblk->blkno); #endif kdb_printf("index %d hashval 0x%x\n", eblk->index, (uint_t)eblk->hashval); } --- linux/fs/xfs/xfs_mount.c-V1 Sun Jan 27 15:42:22 2002 +++ linux/fs/xfs/xfs_mount.c Tue Jan 29 18:46:06 2002 @@ -846,10 +846,18 @@ /* * Select the right directory manager. */ - mp->m_dirops = - XFS_SB_VERSION_HASDIRV2(&mp->m_sb) ? - xfsv2_dirops : - xfsv1_dirops; + + if (!XFS_SB_VERSION_HASDIRV2(&mp->m_sb)) { +#ifdef CONFIG_XFS_V1_DIR + mp->m_dirops = xfsv1_dirops; +#else + cmn_err(CE_WARN, "XFS: v1 directories not compiled in"); + goto error1; +#endif + } else { + mp->m_dirops = xfsv2_dirops; + } + /* * Initialize directory manager's entries. --- linux/fs/xfs/Makefile-V1 Tue Jan 29 18:47:03 2002 +++ linux/fs/xfs/Makefile Tue Jan 29 19:33:41 2002 @@ -73,6 +73,10 @@ obj-y += xfs_grio.o endif +ifneq ($(CONFIG_XFS_V1_DIR),) + obj-y += xfs_dir.o xfs_dir_leaf.o +endif + ifeq ($(CONFIG_HAVE_XFS_DMAPI),) obj-y += xfsdmapistubs.o else @@ -100,7 +104,6 @@ xfs_btree.o \ xfs_buf_item.o \ xfs_da_btree.o \ - xfs_dir.o \ xfs_dir2.o \ xfs_dir2_block.o \ xfs_dir2_data.o \ @@ -108,7 +111,6 @@ xfs_dir2_node.o \ xfs_dir2_sf.o \ xfs_dir2_trace.o \ - xfs_dir_leaf.o \ xfs_error.o \ xfs_extfree_item.o \ xfs_fsops.o \ --- linux/fs/Config.in-V1 Sun Jan 27 15:42:16 2002 +++ linux/fs/Config.in Tue Jan 29 21:13:02 2002 @@ -89,7 +89,8 @@ tristate 'SGI XFS filesystem support' CONFIG_XFS_FS dep_mbool ' Enable XFS Realtime support' CONFIG_XFS_RT $CONFIG_XFS_FS -dep_mbool ' Enable XFS Quota' CONFIG_XFS_QUOTA $CONFIG_XFS_FS +dep_mbool ' Enable XFS Quota' CONFIG_XFS_QUOTA $CONFIG_XFS_FS +dep_mbool ' Enable XFSv1 directories' CONFIG_XFS_V1_DIR $CONFIG_XFS_FS if [ "$CONFIG_XFS_FS" != "n" ]; then define_bool CONFIG_HAVE_ATTRCTL y dep_tristate ' Enable XFS DMAPI' CONFIG_XFS_DMAPI $CONFIG_XFS_FS From owner-linux-xfs@oss.sgi.com Tue Jan 29 17:24:54 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0U1Osm07350 for linux-xfs-outgoing; Tue, 29 Jan 2002 17:24:54 -0800 Received: from ente.berdmann.de (frnk-d514e173.dsl.mediaWays.net [213.20.225.115]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0U1Okd07328 for ; Tue, 29 Jan 2002 17:24:47 -0800 Received: from apollo.berdmann.de ([192.168.1.2] helo=berdmann.de) by ente.berdmann.de with esmtp (Exim 3.22 #1) id 16ViYC-000844-00; Wed, 30 Jan 2002 01:24:32 +0100 Message-ID: <3C573D40.A36C9083@berdmann.de> Date: Wed, 30 Jan 2002 01:24:32 +0100 From: "Bernhard R. Erdmann" X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.4.17-xfs i586) X-Accept-Language: de, en, fr MIME-Version: 1.0 To: jrj@cc.purdue.edu CC: "amanda-users@amanda.org" , Linux XFS Mailing List Subject: Re: Using Amanda with Linux/XFS: "failed to get (valid) bulkstat information" References: <200201292238.RAA28586@gandalf.cc.purdue.edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 2412 Lines: 59 > Before I put this in, is there any particular reason you're adding > DMP_WARNING? Why not just add these entries as DMP_NORMAL? First reason (beauty): I decided to put the warnings into a different group than the normal output, just to be ready for further additions of warnings of other dump programs and to have the ability to treat them differently in the future. In this case, the warnings seem to be quite normal for busy XFS filesystems. But xfsdump prints a warning and hopefully the xfsdump developers will have had their reasons for it: why don't recognize it as a warning but continue as you would do on the command line? ("A warning? I've got the backups - who cares if I can recover?" ;-)) Second reason (technical nature): the dmpline_t/regex pairs in the array re_table (client-src/sendbackup-dump.c, line 44) are matched against dump's output in order of array index in parse_dumpline(). client-src/sendbackup.c: 729 dmpline_t parse_dumpline(str) 730 char *str; 731 /* 732 * Checks the dump output line in str against the regex table. 733 */ 734 { 735 regex_t *rp; 736 737 /* check for error match */ 738 for(rp = program->re_table; rp->regex != NULL; rp++) { 739 if(match(rp->regex, str)) 740 break; 741 } The array re_table is initialized with pairs in order of DMP_SIZE, DMP_STRANGE, DMP_NORMAL and DMP_STRANGE (for all other lines). One of the regexps of dmpline_t DMP_STRANGE is "[Ff]ail". client-src/sendbackup-dump.c: 100 /* strange dump lines */ 101 { DMP_STRANGE, "should not happen" }, 102 { DMP_STRANGE, "Cannot open" }, 103 { DMP_STRANGE, "[Ee]rror" }, 104 { DMP_STRANGE, "[Ff]ail" }, 105 /* XXX add more ERROR entries here by scanning dump sources? */ 106 107 /* any blank or non-strange DUMP: lines are marked as normal */ 108 { DMP_NORMAL, "^ *DUMP:" }, If you added "failed to get bulkstat" to DMP_NORMAL, you would never match DMP_NORMAL because DMP_STRANGE would have been matched first. So I inserted DMP_WARNING between DMP_SIZE and DMP_STRANGE. The XFS boys of SGI told me not to bang my head on these warnings. Bulkstat is a special XFS feature to get lots of inodes in a single rush. Sometimes an inode cannot be caught by bulkstat due to filesystem activity; instead, xfsdump will do a single stat call later on it. From owner-linux-xfs@oss.sgi.com Tue Jan 29 22:27:04 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0U6R4m12667 for linux-xfs-outgoing; Tue, 29 Jan 2002 22:27:04 -0800 Received: from yog-sothoth.sgi.com (eugate.sgi.com [192.48.160.10]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0U6R0d12637 for ; Tue, 29 Jan 2002 22:27:00 -0800 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.55.149]) by yog-sothoth.sgi.com (980305.SGI.8.8.8-aspam-6.2/980304.SGI-aspam-europe) via ESMTP id GAA32089 for ; Wed, 30 Jan 2002 06:25:00 +0100 (CET) mail_from (nathans@snort.melbourne.sgi.com) Received: (from nathans@localhost) by snort.melbourne.sgi.com (SGI-8.9.3/8.9.3) id QAA05876 for linux-xfs@oss.sgi.com; Wed, 30 Jan 2002 16:25:35 +1100 (EST) Date: Wed, 30 Jan 2002 16:25:35 +1100 (EST) From: Nathan Scott Message-Id: <200201300525.QAA05876@snort.melbourne.sgi.com> To: linux-xfs@oss.sgi.com Subject: TAKE - xattr patches Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 335 Lines: 13 Date: Tue Jan 29 21:22:58 PST 2002 Workarea: snort.melbourne.sgi.com:/home/nathans/linux-xfs The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: xfs-cmds:slinx:110594a cmd/xfsmisc/reserved.patch - 1.3 cmd/xfsmisc/xattr.patch - 1.4 - update for changes in 2.5.3-pre6, resubmit to Linus. From owner-linux-xfs@oss.sgi.com Tue Jan 29 23:04:35 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0U74ZO13401 for linux-xfs-outgoing; Tue, 29 Jan 2002 23:04:35 -0800 Received: from gum.csee.uq.edu.au (gum.csee.uq.edu.au [130.102.66.1]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0U74Kd13379 for ; Tue, 29 Jan 2002 23:04:21 -0800 Received: from nut.csee.uq.edu.au (nut.csee.uq.edu.au [130.102.66.13]) by gum.csee.uq.edu.au (8.11.6/8.11.6) with ESMTP id g0U64CH29291 for ; Wed, 30 Jan 2002 16:04:12 +1000 (EST) Received: from SPIKE (spike.csee.uq.edu.au [130.102.66.71]) by nut.csee.uq.edu.au (8.11.6/8.11.6) with SMTP id g0U64C425109 for ; Wed, 30 Jan 2002 16:04:12 +1000 (EST) Message-ID: <023501c1a953$f059a0f0$47426682@csee.uq.edu.au> From: "Chris Pascoe" To: Subject: How long should an xfs_freeze take? Date: Wed, 30 Jan 2002 16:03:19 +1000 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.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-Scanned-By: MIMEDefang 1.3 (www dot roaringpenguin dot com slash mimedefang) Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 2892 Lines: 74 Hi, I'm guessing an xfs_freeze shouldn't take this long, am I correct? # time xfs_freeze -f /tst1 real 344m40.434s user 0m0.000s sys 340m40.810s The system is a Dual CPU P3 Xeon with 1GB RAM (highmem enabled), running 2.4.17 CVS, taken on 2002/01/23 (just before the -funsigned-char changes went through), with LVM 1.0.2 added (I see the same behaviour with 1.0.1, though). During the time that passed I broke into kdb a dozen or so times - often the running process on one CPU was the automounter: 0xf71d2000 00000604 00000001 1 001 run 0xf71d2370*automount [0]kdb> btp 604 EBP EIP Function(args) 0xc0252221 stext_lock+0x2fcd kernel .text.lock 0xc024f254 0xc024f254 0xc02576c0 0xf71d2000 0xc01447d2 sys_ioctl+0x42 (0x5, 0x810c9365, 0xbffff7b0, 0xbffffae0, 0x4) kernel .text 0xc0100000 0xc0144790 0xc01449d0 0xc010713b system_call+0x33 kernel .text 0xc0100000 0xc0107108 0xc0107140 whilst the rest of the time it was the xfs_freeze process, sample backtrace: 0xe95c2000 00001062 00000904 1 000 run 0xe95c2370*xfs_freeze Entering kdb (current=0xe95c2000, pid 1062) on processor 0 due to Keyboard Entry [0]kdb> bt EBP EIP Function(args) 0xe95c3b4c 0xc01cb1a7 vn_count+0xb (0xf3d0bcc0, 0xf7e89560, 0xf6d1f000, 0xf6d1f000, 0xf6d1f118) kernel .text 0xc0100000 0xc01cb19c 0xc01cb1ac 0xe95c3b88 0xc01a19f6 xfs_iflush_all+0x56 (0xf6d1f000, 0x1, 0xf6d1f000, 0xc, 0xc039ce80) kernel .text 0xc0100000 0xc01a19a0 0xc01a1b1c 0xe95c3bb8 0xc01995f0 xfs_fs_freeze+0x38 (0xf6d1f000, 0xbffffbac, 0xf6d094a0, 0xf6d095c0, 0x18) kernel .text 0xc0100000 0xc01995b8 0xc0199670 0xe95c3f54 0xc01c5104 xfs_ioctl+0x1650 (0xe95c3c18, 0x2, 0x3b0, 0xec, 0xec) kernel .text 0xc0100000 0xc01c3ab4 0xc01c51f0 0xc010722c error_code+0x34 kernel .text 0xc0100000 0xc01071f8 0xc0107234 Interrupt registers: eax = 0x08049c50 ebx = 0xe95c3c18 ecx = 0x00000002 edx = 0x000003b0 esi = 0x000000ec edi = 0x000000ec esp = 0x00000010 eip = 0xf6d095c0 ebp = 0x00000000 xss = 0x00010246 xcs = 0xffffffff eflags = 0xc02475db xds = 0xe95c3c5c xes = 0xf6d1f000 origeax = 0xf6cfcb38 ®s = 0xe95c3c10 Interrupt from user space, end of kernel trace Alternatively, I'd see a slightly different location in vn_count: Entering kdb (current=0xe95c2000, pid 1062) on processor 0 due to Keyboard Entry [0]kdb> bt EBP EIP Function(args) 0xe95c3b88 0xc01cb1ab vn_count+0xf (0xe9e811e0, 0xf7e89560, 0xf6d1f000, 0xf6d1f000, 0xf6d1f118) kernel .text 0xc0100000 0xc01cb19c 0xc01cb1ac Anything that I should try to help figure out what's going on? Chris From owner-linux-xfs@oss.sgi.com Wed Jan 30 00:20:14 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0U8KEf17090 for linux-xfs-outgoing; Wed, 30 Jan 2002 00:20:14 -0800 Received: from ADSL-Bergs.RZ.RWTH-Aachen.DE (adsl-bergs.rz.RWTH-Aachen.DE [137.226.80.218]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0U8K5d17067 for ; Wed, 30 Jan 2002 00:20:06 -0800 Received: from [192.168.1.2] (helo=ralf) by ADSL-Bergs.RZ.RWTH-Aachen.DE with smtp (Exim 3.12 #1) id 16Vp28-0007ch-00; Wed, 30 Jan 2002 08:19:52 +0100 From: "Ralf G. R. Bergs" To: "linux-xfs@oss.sgi.com" Cc: "Steve Lord" Date: Wed, 30 Jan 2002 08:19:51 +0100 Reply-To: "Ralf G. R. Bergs" X-Mailer: PMMail 2000 Professional (2.20.2380) For Windows 2000 (5.0.2195;2) In-Reply-To: <1012336870.26363.14.camel@jen.americas.sgi.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Subject: Re: [PATCH] Re: Reduce XFS footprint (was Re: TAKE - remove a function xfs added to filemap.c Message-Id: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 876 Lines: 26 On Tue, 29 Jan 2002 14:41:10 -0600, Steve Lord wrote: [...] >> So with Andi's patch one should NOT enable V1 directories, or otherwise the XFS >> code can't read existing V2 filesystems anymore? Is that right? > > >Noooo, I think you got your 1s and 2s crossed in there. Andi was turning >off the backwards compatibility with old irix filesystems (V1) in the >patch. It is not exactly a huge win spacewise, but every little helps. >This will not affect any existing filesystem made on linux since they >all use the V2 code. Oh, sorry, stupid me. :-) Thanks for setting this straight. -- Verkaufe Original-BMW-Raeder: L I N U X .~. http://adsl-bergs.rz.rwth-aachen.de/~rabe The Choice /V\ of a GNU /( )\ Generation ^^-^^ From owner-linux-xfs@oss.sgi.com Wed Jan 30 06:49:24 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0UEnOD26401 for linux-xfs-outgoing; Wed, 30 Jan 2002 06:49:24 -0800 Received: from zok.sgi.com (zok.SGI.COM [204.94.215.101]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0UEnId26376 for ; Wed, 30 Jan 2002 06:49:19 -0800 Received: from zeus-e8.americas.sgi.com (zeus-e8.americas.sgi.com [128.162.8.103]) by zok.sgi.com (8.11.4/8.11.4/linux-outbound_gateway-1.1) with ESMTP id g0UDnBo11736 for ; Wed, 30 Jan 2002 05:49:11 -0800 Received: from tulip-e185.americas.sgi.com (tulip-e185.americas.sgi.com [128.162.185.208]) by zeus-e8.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id HAA05977; Wed, 30 Jan 2002 07:47:55 -0600 (CST) Received: from sgi.com (Mydvy1I9dZwt7gSgDcYIVLFbqQZWdvFB@lord-h1.americas.sgi.com [206.11.101.42]) by tulip-e185.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.7) with ESMTP id HAA21840; Wed, 30 Jan 2002 07:47:55 -0600 (CST) Message-ID: <3C57F97A.7000400@sgi.com> Date: Wed, 30 Jan 2002 07:47:38 -0600 From: Stephen Lord User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.7) Gecko/20011226 X-Accept-Language: en-us MIME-Version: 1.0 To: Chris Pascoe CC: linux-xfs@oss.sgi.com Subject: Re: How long should an xfs_freeze take? References: <023501c1a953$f059a0f0$47426682@csee.uq.edu.au> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 835 Lines: 33 Chris Pascoe wrote: >Hi, > >I'm guessing an xfs_freeze shouldn't take this long, am I correct? > ># time xfs_freeze -f /tst1 > >real 344m40.434s >user 0m0.000s >sys 340m40.810s > >The system is a Dual CPU P3 Xeon with 1GB RAM (highmem enabled), running >2.4.17 CVS, taken on 2002/01/23 (just before the -funsigned-char changes >went through), with LVM 1.0.2 added (I see the same behaviour with 1.0.1, >though). > How long freeze takes depends on how much data is dirty in the filesystem, it should take a similar time to an unmount. However, unless this was a very large and dirty filesystem this feels like a long time - although it was all system time, so something was going on. The spot you kept seeing on the stack does not make much sense, vn_count is basically an atomic_read. How repeatable is this? Steve From owner-linux-xfs@oss.sgi.com Wed Jan 30 10:07:54 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0UI7st14168 for linux-xfs-outgoing; Wed, 30 Jan 2002 10:07:54 -0800 Received: from cycos.com (mrs.backbone.cycos.com [194.77.158.3]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0UI7hd14135 for ; Wed, 30 Jan 2002 10:07:43 -0800 Date: Wed, 30 Jan 2002 18:07:30 +0100 From: "Eitzenberger, Holger" To: "linux-xfs@oss.sgi.com" NvsRef: PPCOM/2770726 Message-Id: <002a4726@cycos.com> Subject: XFS will 'taint' kernel sources X-Mailer: MRS Internet Mail APL Version 5.00.98 (WIN-NT) Release Build 2804 Mime-Version: 1.0 Content-Type: multipart/alternative; Boundary="======_316560014449_======" Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 2810 Lines: 73 --======_316560014449_====== Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit * Debian 'woody' * linux-2.4.17-xfs * modutils 2.4.12-1 Hallo, after upgrading the modutils package i noticed that the XFS patch makes the kernel tainted. Module Size Used by Tainted: P xfs 397312 2 (autoclean) xfs_support 6168 0 (autoclean) [xfs] pagebuf 20864 2 (autoclean) [xfs xfs_support] serial 42688 0 (autoclean) via-rhine 10308 1 rtc 5400 0 (autoclean) The reason might be that the 'pagebuf.o' kernel module does not contain MODULE_LICENSE("GPL"); 'xfs.o' and 'xfs_support.o' do contain this statement. Is this a bug? Thx in advance. Holger -- ++ GnuPG PubKey: http://www.t-online.de/~holger.eitzenberger ++ +++ Debian GNU/Linux +++ ICQ# 2882018 +++ --======_316560014449_====== Content-Type: application/rtf Content-Transfer-Encoding: base64 e1xydGYxXGFuc2lcYW5zaWNwZzEyNTJcZnJvbXRleHQgXGRlZmYwe1xmb250 dGJsDQp7XGYwXGZzd2lzcyBBcmlhbDt9DQp7XGYxXGZtb2Rlcm4gQ291cmll ciBOZXc7fQ0Ke1xmMlxmbmlsXGZjaGFyc2V0MiBTeW1ib2w7fQ0Ke1xmM1xm bW9kZXJuXGZjaGFyc2V0MCBDb3VyaWVyIE5ldzt9fQ0Ke1xjb2xvcnRibFxy ZWQwXGdyZWVuMFxibHVlMDtccmVkMFxncmVlbjBcYmx1ZTI1NTt9DQpcdWMx XHBhcmRccGxhaW5cZGVmdGFiMzYwIFxmMFxmczIwICAgKiBEZWJpYW4gJ3dv b2R5J1xwYXINCiAgKiBsaW51eC0yLjQuMTcteGZzXHBhcg0KICAqIG1vZHV0 aWxzIDIuNC4xMi0xXHBhcg0KXHBhcg0KSGFsbG8sXHBhcg0KXHBhcg0KYWZ0 ZXIgdXBncmFkaW5nIHRoZSBtb2R1dGlscyBwYWNrYWdlIGkgbm90aWNlZCB0 aGF0IHRoZVxwYXINClhGUyBwYXRjaCBtYWtlcyB0aGUga2VybmVsIHRhaW50 ZWQuXHBhcg0KXHBhcg0KXHRhYiBNb2R1bGUgICAgICAgICAgICAgICAgICBT aXplICBVc2VkIGJ5ICAgIFRhaW50ZWQ6IFBccGFyDQpcdGFiIHhmcyAgICAg ICAgICAgICAgICAgICAzOTczMTIgICAyIChhdXRvY2xlYW4pXHBhcg0KXHRh YiB4ZnNfc3VwcG9ydCAgICAgICAgICAgICA2MTY4ICAgMCAoYXV0b2NsZWFu KSBbeGZzXVxwYXINClx0YWIgcGFnZWJ1ZiAgICAgICAgICAgICAgICAyMDg2 NCAgIDIgKGF1dG9jbGVhbikgW3hmcyB4ZnNfc3VwcG9ydF1ccGFyDQpcdGFi IHNlcmlhbCAgICAgICAgICAgICAgICAgNDI2ODggICAwIChhdXRvY2xlYW4p XHBhcg0KXHRhYiB2aWEtcmhpbmUgICAgICAgICAgICAgIDEwMzA4ICAgMVxw YXINClx0YWIgcnRjICAgICAgICAgICAgICAgICAgICAgNTQwMCAgIDAgKGF1 dG9jbGVhbilccGFyDQpccGFyDQpUaGUgcmVhc29uIG1pZ2h0IGJlIHRoYXQg dGhlICdwYWdlYnVmLm8nIGtlcm5lbCBtb2R1bGUgZG9lcyBub3RccGFyDQpj b250YWluXHBhcg0KXHBhcg0KICAgIE1PRFVMRV9MSUNFTlNFKCJHUEwiKTtc cGFyDQpccGFyDQoneGZzLm8nIGFuZCAneGZzX3N1cHBvcnQubycgZG8gY29u dGFpbiB0aGlzIHN0YXRlbWVudC4gIElzIHRoaXNccGFyDQphIGJ1Zz9ccGFy DQpccGFyDQpUaHggaW4gYWR2YW5jZS5ccGFyDQpccGFyDQpIb2xnZXJccGFy DQpccGFyDQotLSBccGFyDQorKyBHbnVQRyBQdWJLZXk6IGh0dHA6Ly93d3cu dC1vbmxpbmUuZGUvfmhvbGdlci5laXR6ZW5iZXJnZXIgKytccGFyDQorKysg RGViaWFuIEdOVS9MaW51eCA8b2N0YXZpYW5AZGViaWFuLm9yZz4gKysrIElD USMgMjg4MjAxOCArKytccGFyDQp9 --======_316560014449_======-- From owner-linux-xfs@oss.sgi.com Wed Jan 30 10:24:26 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0UIOQU15019 for linux-xfs-outgoing; Wed, 30 Jan 2002 10:24:26 -0800 Received: from rj.sgi.com (rj.SGI.COM [204.94.215.100]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0UIOLd14997 for ; Wed, 30 Jan 2002 10:24:21 -0800 Received: from zeus-e8.americas.sgi.com (zeus-e8.americas.sgi.com [128.162.8.103]) by rj.sgi.com (8.11.4/8.11.4/linux-outbound_gateway-1.1) with ESMTP id g0UHODY28382 for ; Wed, 30 Jan 2002 09:24:13 -0800 Received: from poppy-e185.americas.sgi.com (poppy-e185.americas.sgi.com [128.162.185.207]) by zeus-e8.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id LAA08950; Wed, 30 Jan 2002 11:22:57 -0600 (CST) Received: from stout.americas.sgi.com (stout.americas.sgi.com [128.162.187.5]) by poppy-e185.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.7) with ESMTP id LAA99508; Wed, 30 Jan 2002 11:22:57 -0600 (CST) Subject: Re: XFS will 'taint' kernel sources From: Eric Sandeen To: "Eitzenberger, Holger" Cc: "linux-xfs@oss.sgi.com" In-Reply-To: <002a4726@cycos.com> References: <002a4726@cycos.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/1.0 (Preview Release) Date: 30 Jan 2002 11:22:57 -0600 Message-Id: <1012411377.849.0.camel@stout.americas.sgi.com> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 705 Lines: 33 hi Holger - On Wed, 2002-01-30 at 11:07, Eitzenberger, Holger wrote: > * Debian 'woody' > * linux-2.4.17-xfs > * modutils 2.4.12-1 > > Hallo, > > after upgrading the modutils package i noticed that the > XFS patch makes the kernel tainted. [snip] > The reason might be that the 'pagebuf.o' kernel module does not > contain > > MODULE_LICENSE("GPL"); After Jan 11, 2002, the pagebuf module no longer exists, it has been rolled into xfs. I didn't think MODULE_LICENSE was a problem before, but now that the pagebuf module is gone, it's certainly not a problem now. :) Thanks, -Eric -- Eric Sandeen XFS for Linux http://oss.sgi.com/projects/xfs sandeen@sgi.com SGI, Inc. From owner-linux-xfs@oss.sgi.com Wed Jan 30 10:31:17 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0UIVHi16956 for linux-xfs-outgoing; Wed, 30 Jan 2002 10:31:17 -0800 Received: from sgi.com (sgi-too.SGI.COM [204.94.211.39]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0UIVDd16934 for ; Wed, 30 Jan 2002 10:31:13 -0800 Received: from zeus-e8.americas.sgi.com (zeus-e8.americas.sgi.com [128.162.8.103]) by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id JAA08986 for ; Wed, 30 Jan 2002 09:29:01 -0800 (PST) mail_from (eric@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by zeus-e8.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id LAA09261 for ; Wed, 30 Jan 2002 11:29:54 -0600 (CST) Received: from stout.americas.sgi.com (stout.americas.sgi.com [128.162.187.5]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id LAA48694 for ; Wed, 30 Jan 2002 11:29:54 -0600 (CST) Received: by stout.americas.sgi.com (8.11.6/SGI-client-1.7) id g0UHTss08279; Wed, 30 Jan 2002 11:29:54 -0600 Message-Id: <200201301729.g0UHTss08279@stout.americas.sgi.com> Date: Wed, 30 Jan 2002 11:29:54 -0600 From: Eric Sandeen Subject: TAKE - More conservative max file size. Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 547 Lines: 19 As Andi says, "it's generally safe to not challenge the mighty sign extension." :) So it's down to 8TiB files now on 4k page machines. (Again, this is a _Linux_ limitation, not XFS per se.) Date: Wed Jan 30 09:24:49 PST 2002 Workarea: stout.americas.sgi.com:/localhome/eric/2.4.x-xfs/workarea-reallyclean The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:110614a linux/fs/xfs/xfs_inode.h - 1.153 - More conservative value for XFS_MAX_FILE_OFFSET - beware the sign extension From owner-linux-xfs@oss.sgi.com Wed Jan 30 13:38:22 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0ULcMj23148 for linux-xfs-outgoing; Wed, 30 Jan 2002 13:38:22 -0800 Received: from mail.ocs.com.au (mail.ocs.com.au [203.34.97.2]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0ULcJd23126 for ; Wed, 30 Jan 2002 13:38:19 -0800 Received: (qmail 25105 invoked from network); 30 Jan 2002 20:38:14 -0000 Received: from ocs3.intra.ocs.com.au (192.168.255.3) by mail.ocs.com.au with SMTP; 30 Jan 2002 20:38:14 -0000 Received: by ocs3.intra.ocs.com.au (Postfix, from userid 16331) id E7CF43000B8; Thu, 31 Jan 2002 07:38:12 +1100 (EST) Received: from ocs3.intra.ocs.com.au (localhost [127.0.0.1]) by ocs3.intra.ocs.com.au (Postfix) with ESMTP id 9CE628E for ; Thu, 31 Jan 2002 07:38:12 +1100 (EST) X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 From: Keith Owens To: "linux-xfs@oss.sgi.com" Subject: 2.5.3 assigns ACL syscalls Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 31 Jan 2002 07:38:07 +1100 Message-ID: <2100.1012423087@ocs3.intra.ocs.com.au> Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 162 Lines: 4 Kernel 2.5.3 is out. It contains fs/xattr.c and i386 syscalls for ACLs. Now would be a good time to reserve corresponding syscalls on the other architectures. From owner-linux-xfs@oss.sgi.com Wed Jan 30 13:59:21 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0ULxLd23854 for linux-xfs-outgoing; Wed, 30 Jan 2002 13:59:21 -0800 Received: from yog-sothoth.sgi.com (eugate.sgi.com [192.48.160.10]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0ULxHd23830 for ; Wed, 30 Jan 2002 13:59:17 -0800 Received: from zeus-e8.americas.sgi.com (zeus-e8.americas.sgi.com [128.162.8.103]) by yog-sothoth.sgi.com (980305.SGI.8.8.8-aspam-6.2/980304.SGI-aspam-europe) via ESMTP id VAA106723 for ; Wed, 30 Jan 2002 21:56:59 +0100 (CET) mail_from (lord@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by zeus-e8.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id OAA12536 for ; Wed, 30 Jan 2002 14:57:56 -0600 (CST) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id OAA03601 for ; Wed, 30 Jan 2002 14:57:56 -0600 (CST) From: Steve Lord Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id g0UKtmd17041; Wed, 30 Jan 2002 14:55:48 -0600 Message-Id: <200201302055.g0UKtmd17041@jen.americas.sgi.com> Date: Wed, 30 Jan 2002 14:55:48 -0600 Subject: TAKE - fix bitkeeper on xfs To: linux-xfs@oss.sgi.com Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 610 Lines: 21 Date: Wed Jan 30 12:55:07 PST 2002 Workarea: jen.americas.sgi.com:/src/lord/xfs-linux.2.4 The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:110651a linux/fs/buffer.c - 1.100 - Fix up return values used in xfs writepage call, plus a couple of other tweaks. linux/fs/xfs/linux/xfs_iops.c - 1.120 - Fix up return values used in xfs writepage linux/fs/xfs/pagebuf/page_buf_io.c - 1.5 - No longer return a count of pages written in the write full page path, and ensure that we write out pages passed into writepage from the mmap path. From owner-linux-xfs@oss.sgi.com Wed Jan 30 14:03:12 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0UM3CJ24150 for linux-xfs-outgoing; Wed, 30 Jan 2002 14:03:12 -0800 Received: from smtp016.mail.yahoo.com (smtp016.mail.yahoo.com [216.136.174.113]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0UM38d24126 for ; Wed, 30 Jan 2002 14:03:08 -0800 Received: from aegis.cs.princeton.edu (HELO divine) (128.112.152.6) by smtp.mail.vip.sc5.yahoo.com with SMTP; 30 Jan 2002 20:26:10 -0000 Message-ID: <011101c1a9cc$53acf170$906a7080@divine> From: "Zhifeng F. Chen" To: Subject: NFS and XFS again. Date: Wed, 30 Jan 2002 15:25:57 -0500 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Content-Disposition: inline Content-Type: text/plain Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 208 Lines: 10 Hi, I've met a problem with NFS and XFS combo. When I make a symbolic link on /home/user/.../..., sometimes I met "File name too long" error. What's wrong with it? ZF [[HTML alternate version deleted]] From owner-linux-xfs@oss.sgi.com Wed Jan 30 14:41:27 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0UMfR525074 for linux-xfs-outgoing; Wed, 30 Jan 2002 14:41:27 -0800 Received: from mail.conwaycorp.net (mail.conwaycorp.net [24.144.1.33]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0UMfFd25050 for ; Wed, 30 Jan 2002 14:41:15 -0800 Received: (qmail 15926 invoked from network); 30 Jan 2002 21:30:18 -0000 Received: from unknown (HELO tao.wang-fu.org) (24.144.32.127) by mail.conwaycorp.net with SMTP; 30 Jan 2002 21:30:18 -0000 Received: from kraken by tao.wang-fu.org with local (Exim 3.34 #1 (Debian)) id 16W2Td-0006nb-00; Wed, 30 Jan 2002 15:41:09 -0600 Date: Wed, 30 Jan 2002 15:41:08 -0600 From: Nathan Poznick To: linux-xfs@oss.sgi.com, linux-kernel@vger.kernel.org Subject: Oops in bdflush with 2.4.1[4|7]-xfs Message-ID: <20020130214108.GA25792@conwaycorp.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.27i Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 4407 Lines: 104 We've got a couple of development machines with hardware raid sets that we use XFS on. A few weeks ago, while running 2.4.14-xfs, there was an Oops in bdflush, which caused bdflush to go defunct, and kupdated to go into some sort of loop, chewing one of the CPUs. I upgraded the machine to 2.4.17-xfs, and for a few weeks it's been fine, but then this afternoon there was again an oops in bdflush, which again caused bdflush to go defunct, and kupdated to chew a CPU (along with an attempted sync, the shutdown process, etc). Below is the decoded oops. Any help is appreciated. Thanks. ksymoops 0.7c on i686 2.4.17-xfs. Options used -V (default) -k /proc/ksyms (default) -l /proc/modules (default) -o /lib/modules/2.4.17-xfs/ (default) -m /boot/System.map-2.4.17-xfs (specified) Unable to handle kernel NULL pointer dereference at virtual address 00000030 c0192fe9 *pde = 00000000 Oops: 0000 CPU: 0 EIP: 0010:[] Not tainted Using defaults from ksymoops -t elf32-i386 -a i386 EFLAGS: 00010046 eax: 00000000 ebx: 00000000 ecx: 00000000 edx: 00000000 esi: 00000000 edi: 00000001 ebp: 00000000 esp: c4c49864 ds: 0018 es: 0018 ss: 0018 Process bdflush (pid: 6, stackpage=c4c49000) Stack: e5187ed8 00000000 00000000 c4c4996c c4c4996c c4c49b68 c4c49b68 0b000003 f3242be0 00000000 00000004 cbf27200 c4c498c8 f3242be0 00000046 0b000010 00000000 00000001 f79fd8f4 00000000 00000016 f71a5400 00000000 00000002 Call Trace: [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] Code: 8b 52 30 89 54 24 58 51 55 8b 44 24 60 50 8b 54 24 78 52 e8 >>EIP; c0192fe9 <===== Trace; c0194b68 <_pagebuf_handle_iovecs+dc/f0> Trace; c018f9ad Trace; c018f746 Trace; c01919ce Trace; c01a103e Trace; c021a41e Trace; c02208d2 Trace; c022004a Trace; c0220244 Trace; c02204b1 Trace; c0238573 Trace; c01ad063 Trace; c01ad063 Trace; c01a34b3 Trace; c01a515f Trace; c0238573 Trace; c01d12fb Trace; c01d23a6 Trace; c01efd74 Trace; c012b965 Trace; c012b9ac Trace; c012c270 Trace; c01edcf3 Trace; c0182854 Trace; c018188b Trace; c01edc78 Trace; c01ede8b Trace; c01edc78 Trace; c0133745 Trace; c0133909 Trace; c01369a4 Trace; c0105000 <_stext+0/0> Trace; c01055db Code; c0192fe9 00000000 <_EIP>: Code; c0192fe9 <===== 0: 8b 52 30 mov 0x30(%edx),%edx <===== Code; c0192fec 3: 89 54 24 58 mov %edx,0x58(%esp,1) Code; c0192ff0 7: 51 push %ecx Code; c0192ff1 8: 55 push %ebp Code; c0192ff2 9: 8b 44 24 60 mov 0x60(%esp,1),%eax Code; c0192ff6 d: 50 push %eax Code; c0192ff7 e: 8b 54 24 78 mov 0x78(%esp,1),%edx Code; c0192ffb 12: 52 push %edx Code; c0192ffc 13: e8 00 00 00 00 call 18 <_EIP+0x18> c0193001 From owner-linux-xfs@oss.sgi.com Wed Jan 30 15:10:35 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0UNAZT26016 for linux-xfs-outgoing; Wed, 30 Jan 2002 15:10:35 -0800 Received: from UberGeek.coremetrics.com ([209.184.141.163]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0UNAEd25986 for ; Wed, 30 Jan 2002 15:10:14 -0800 Received: (from austin@localhost) by UberGeek.coremetrics.com (8.11.6/8.11.6) id g0UM95014877; Wed, 30 Jan 2002 16:09:05 -0600 X-Authentication-Warning: UberGeek.coremetrics.com: austin set sender to austin@coremetrics.com using -f Subject: Re: Oops in bdflush with 2.4.1[4|7]-xfs From: Austin Gonyou To: Nathan Poznick Cc: linux-xfs@oss.sgi.com, linux-kernel@vger.kernel.org In-Reply-To: <20020130214108.GA25792@conwaycorp.net> References: <20020130214108.GA25792@conwaycorp.net> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-XB4IKG+6EgVjle8B6lmm" X-Mailer: Evolution/1.0.2 Date: 30 Jan 2002 16:09:05 -0600 Message-Id: <1012428545.12420.29.camel@UberGeek> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 5642 Lines: 143 --=-XB4IKG+6EgVjle8B6lmm Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Could you see if my XFS-AA patch does anything for you? There are changes to bdflush in it and I'd be interested to see if they go away.=20 http://www.digitalroadkill.net/Patches/2.4.17-xfs-aa.patch.bz2 On Wed, 2002-01-30 at 15:41, Nathan Poznick wrote: >=20 > We've got a couple of development machines with hardware raid sets > that we use XFS on. A few weeks ago, while running 2.4.14-xfs, there > was an Oops in bdflush, which caused bdflush to go defunct, and > kupdated to go into some sort of loop, chewing one of the CPUs. I > upgraded the machine to 2.4.17-xfs, and for a few weeks it's been > fine, but then this afternoon there was again an oops in bdflush, > which again caused bdflush to go defunct, and kupdated to chew a CPU > (along with an attempted sync, the shutdown process, etc). Below is > the decoded oops. Any help is appreciated. Thanks. >=20 >=20 > ksymoops 0.7c on i686 2.4.17-xfs. Options used > -V (default) > -k /proc/ksyms (default) > -l /proc/modules (default) > -o /lib/modules/2.4.17-xfs/ (default) > -m /boot/System.map-2.4.17-xfs (specified) >=20 > Unable to handle kernel NULL pointer dereference at virtual address > 00000030 > c0192fe9 > *pde =3D 00000000 > Oops: 0000 > CPU: 0 > EIP: 0010:[] Not tainted > Using defaults from ksymoops -t elf32-i386 -a i386 > EFLAGS: 00010046 > eax: 00000000 ebx: 00000000 ecx: 00000000 edx: 00000000 > esi: 00000000 edi: 00000001 ebp: 00000000 esp: c4c49864 > ds: 0018 es: 0018 ss: 0018 > Process bdflush (pid: 6, stackpage=3Dc4c49000) > Stack: e5187ed8 00000000 00000000 c4c4996c c4c4996c c4c49b68 c4c49b68 > 0b000003=20 > f3242be0 00000000 00000004 cbf27200 c4c498c8 f3242be0 00000046 > 0b000010=20 > 00000000 00000001 f79fd8f4 00000000 00000016 f71a5400 00000000 > 00000002=20 > Call Trace: [] [] [] [] > [] > [] [] [] [] [] > []=20 > [] [] [] [] [] > []=20 > [] [] [] [] [] > []=20 > [] [] [] [] [] > []=20 > [] [] [] []=20 > Code: 8b 52 30 89 54 24 58 51 55 8b 44 24 60 50 8b 54 24 78 52 e8=20 >=20 > >>EIP; c0192fe9 <=3D=3D=3D=3D=3D > Trace; c0194b68 <_pagebuf_handle_iovecs+dc/f0> > Trace; c018f9ad > Trace; c018f746 > Trace; c01919ce > Trace; c01a103e > Trace; c021a41e > Trace; c02208d2 > Trace; c022004a > Trace; c0220244 > Trace; c02204b1 > Trace; c0238573 > Trace; c01ad063 > Trace; c01ad063 > Trace; c01a34b3 > Trace; c01a515f > Trace; c0238573 > Trace; c01d12fb > Trace; c01d23a6 > Trace; c01efd74 > Trace; c012b965 > Trace; c012b9ac > Trace; c012c270 > Trace; c01edcf3 > Trace; c0182854 > Trace; c018188b > Trace; c01edc78 > Trace; c01ede8b > Trace; c01edc78 > Trace; c0133745 > Trace; c0133909 > Trace; c01369a4 > Trace; c0105000 <_stext+0/0> > Trace; c01055db > Code; c0192fe9 > 00000000 <_EIP>: > Code; c0192fe9 <=3D=3D=3D=3D=3D > 0: 8b 52 30 mov 0x30(%edx),%edx <=3D=3D=3D=3D= =3D > Code; c0192fec > 3: 89 54 24 58 mov %edx,0x58(%esp,1) > Code; c0192ff0 > 7: 51 push %ecx > Code; c0192ff1 > 8: 55 push %ebp > Code; c0192ff2 > 9: 8b 44 24 60 mov 0x60(%esp,1),%eax > Code; c0192ff6 > d: 50 push %eax > Code; c0192ff7 > e: 8b 54 24 78 mov 0x78(%esp,1),%edx > Code; c0192ffb > 12: 52 push %edx > Code; c0192ffc > 13: e8 00 00 00 00 call 18 <_EIP+0x18> c0193001 > --=20 Austin Gonyou Systems Architect, CCNA Coremetrics, Inc. Phone: 512-698-7250 email: austin@coremetrics.com "It is the part of a good shepherd to shear his flock, not to skin it." Latin Proverb --=-XB4IKG+6EgVjle8B6lmm Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQA8WG8B94g6ZVmFMoIRAoM1AJ97bjd1FmZI4HOsvl4qilygZAK+4wCeKySK Q0RTVd8JHQJsYH65QHgbdq8= =y6UR -----END PGP SIGNATURE----- --=-XB4IKG+6EgVjle8B6lmm-- From owner-linux-xfs@oss.sgi.com Wed Jan 30 15:11:16 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0UNBG026142 for linux-xfs-outgoing; Wed, 30 Jan 2002 15:11:16 -0800 Received: from yog-sothoth.sgi.com (eugate.sgi.com [192.48.160.10]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0UNBCd26119 for ; Wed, 30 Jan 2002 15:11:13 -0800 Received: from zeus-e8.americas.sgi.com (zeus-e8.americas.sgi.com [128.162.8.103]) by yog-sothoth.sgi.com (980305.SGI.8.8.8-aspam-6.2/980304.SGI-aspam-europe) via ESMTP id XAA113738 for ; Wed, 30 Jan 2002 23:08:53 +0100 (CET) mail_from (sandeen@sgi.com) Received: from poppy-e185.americas.sgi.com (poppy-e185.americas.sgi.com [128.162.185.207]) by zeus-e8.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id QAA13633; Wed, 30 Jan 2002 16:09:52 -0600 (CST) Received: from stout.americas.sgi.com (stout.americas.sgi.com [128.162.187.5]) by poppy-e185.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.7) with ESMTP id QAA13286; Wed, 30 Jan 2002 16:09:51 -0600 (CST) Subject: Re: Oops in bdflush with 2.4.1[4|7]-xfs From: Eric Sandeen To: Nathan Poznick Cc: linux-xfs@oss.sgi.com In-Reply-To: <20020130214108.GA25792@conwaycorp.net> References: <20020130214108.GA25792@conwaycorp.net> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/1.0 (Preview Release) Date: 30 Jan 2002 16:09:51 -0600 Message-Id: <1012428591.4291.15.camel@stout.americas.sgi.com> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 242 Lines: 12 Hi Nathan - Out of curiosity.... do you have DMAPI turned on? (it looks like you do, from the xfs_dm_punch_hole in the stack). -Eric -- Eric Sandeen XFS for Linux http://oss.sgi.com/projects/xfs sandeen@sgi.com SGI, Inc. From owner-linux-xfs@oss.sgi.com Wed Jan 30 15:15:48 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0UNFms26346 for linux-xfs-outgoing; Wed, 30 Jan 2002 15:15:48 -0800 Received: from yog-sothoth.sgi.com (eugate.sgi.com [192.48.160.10]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0UNFid26324 for ; Wed, 30 Jan 2002 15:15:44 -0800 Received: from zeus-e8.americas.sgi.com (zeus-e8.americas.sgi.com [128.162.8.103]) by yog-sothoth.sgi.com (980305.SGI.8.8.8-aspam-6.2/980304.SGI-aspam-europe) via ESMTP id XAA115042 for ; Wed, 30 Jan 2002 23:13:25 +0100 (CET) mail_from (sandeen@sgi.com) Received: from poppy-e185.americas.sgi.com (poppy-e185.americas.sgi.com [128.162.185.207]) by zeus-e8.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id QAA13789; Wed, 30 Jan 2002 16:14:23 -0600 (CST) Received: from stout.americas.sgi.com (stout.americas.sgi.com [128.162.187.5]) by poppy-e185.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.7) with ESMTP id QAA13289; Wed, 30 Jan 2002 16:14:23 -0600 (CST) Subject: Re: NFS and XFS again. From: Eric Sandeen To: "Zhifeng F. Chen" Cc: linux-xfs@oss.sgi.com In-Reply-To: <011101c1a9cc$53acf170$906a7080@divine> References: <011101c1a9cc$53acf170$906a7080@divine> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/1.0 (Preview Release) Date: 30 Jan 2002 16:14:23 -0600 Message-Id: <1012428863.399.17.camel@stout.americas.sgi.com> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 524 Lines: 18 What exactly are you doing? (linking what to what?) ENAMETOOLONG can arise when namelen >= MAXNAMELEN, which is #defined as 256... Can you show me the steps to duplicate the problem here? -Eric On Wed, 2002-01-30 at 14:25, Zhifeng F. Chen wrote: > Hi, > > I've met a problem with NFS and XFS combo. When I make a symbolic link on /home/user/.../..., sometimes I met "File name too long" error. What's wrong with it? -- Eric Sandeen XFS for Linux http://oss.sgi.com/projects/xfs sandeen@sgi.com SGI, Inc. From owner-linux-xfs@oss.sgi.com Wed Jan 30 15:22:15 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0UNMFL26565 for linux-xfs-outgoing; Wed, 30 Jan 2002 15:22:15 -0800 Received: from mail.conwaycorp.net (mail.conwaycorp.net [24.144.1.33]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0UNMAd26542 for ; Wed, 30 Jan 2002 15:22:10 -0800 Received: (qmail 6980 invoked from network); 30 Jan 2002 22:11:17 -0000 Received: from unknown (HELO tao.wang-fu.org) (24.144.32.127) by mail.conwaycorp.net with SMTP; 30 Jan 2002 22:11:17 -0000 Received: from kraken by tao.wang-fu.org with local (Exim 3.34 #1 (Debian)) id 16W37H-0006v4-00; Wed, 30 Jan 2002 16:22:07 -0600 Date: Wed, 30 Jan 2002 16:22:07 -0600 From: Nathan Poznick To: Eric Sandeen Cc: linux-xfs@oss.sgi.com Subject: Re: Oops in bdflush with 2.4.1[4|7]-xfs Message-ID: <20020130222207.GA26516@conwaycorp.net> References: <20020130214108.GA25792@conwaycorp.net> <1012428591.4291.15.camel@stout.americas.sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1012428591.4291.15.camel@stout.americas.sgi.com> User-Agent: Mutt/1.3.27i Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 577 Lines: 27 Thus spake Eric Sandeen: > Hi Nathan - > > Out of curiosity.... do you have DMAPI turned on? (it looks like you > do, from the xfs_dm_punch_hole in the stack). Yes, DMAPI is turned on. (from the kernel config) CONFIG_PAGE_BUF=y CONFIG_XFS_FS=y # CONFIG_XFS_RT is not set # CONFIG_XFS_QUOTA is not set CONFIG_HAVE_ATTRCTL=y CONFIG_XFS_DMAPI=y CONFIG_HAVE_XFS_DMAPI=y -Nathan -- Nathan Poznick PGP Key: http://drunkmonkey.org/pgpkey.txt "Either get busy living or get busy dying." -- Stephen King, Rita Hayworth and the Shawshank Redemption From owner-linux-xfs@oss.sgi.com Wed Jan 30 15:23:12 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0UNNCK26701 for linux-xfs-outgoing; Wed, 30 Jan 2002 15:23:12 -0800 Received: from pneumatic-tube.sgi.com (pneumatic-tube.sgi.com [204.94.214.22]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0UNN8d26679 for ; Wed, 30 Jan 2002 15:23:08 -0800 Received: from zeus-e8.americas.sgi.com (zeus-e8.americas.sgi.com [128.162.8.103]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id OAA06253 for ; Wed, 30 Jan 2002 14:24:08 -0800 (PST) mail_from (eric@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by zeus-e8.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id QAA13842 for ; Wed, 30 Jan 2002 16:21:50 -0600 (CST) Received: from stout.americas.sgi.com (stout.americas.sgi.com [128.162.187.5]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id QAA24172 for ; Wed, 30 Jan 2002 16:21:50 -0600 (CST) Received: by stout.americas.sgi.com (8.11.6/SGI-client-1.7) id g0UMLnn12879; Wed, 30 Jan 2002 16:21:49 -0600 Message-Id: <200201302221.g0UMLnn12879@stout.americas.sgi.com> Date: Wed, 30 Jan 2002 16:21:49 -0600 From: Eric Sandeen Subject: TAKE - 1 step closer to removing -funsigned-char Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 986 Lines: 26 XFS on Irix gets to assume chars are unsigned, which is not true on Linux, so we use the -funsigned-char option when we build it. Getting rid of this would be nice; we can explicitly define unsigned chars when we need them. The trick is figuring out when we need them. :) These changes should fix the international character problems some were seeing when -funsigned-char was turned off; if some of those brave souls could turn off -funsigned-char on their machines and give it another go, reports of success or failure would be welcome. :) Thanks to Andi Kleen for the first part of this change. Date: Wed Jan 30 14:16:11 PST 2002 Workarea: stout.americas.sgi.com:/localhome/eric/2.4.x-xfs/workarea-reallyclean The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:110658a linux/fs/xfs/xfs_da_btree.c - 1.120 linux/fs/xfs/xfs_da_btree.h - 1.41 - Explicitly set uchar_t when we need it (rather than -funsigned-char) From owner-linux-xfs@oss.sgi.com Wed Jan 30 15:27:10 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0UNRAS26885 for linux-xfs-outgoing; Wed, 30 Jan 2002 15:27:10 -0800 Received: from pneumatic-tube.sgi.com (pneumatic-tube.sgi.com [204.94.214.22]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0UNR5d26863 for ; Wed, 30 Jan 2002 15:27:05 -0800 Received: from zeus-e8.americas.sgi.com (zeus-e8.americas.sgi.com [128.162.8.103]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id OAA00529 for ; Wed, 30 Jan 2002 14:28:04 -0800 (PST) mail_from (sandeen@sgi.com) Received: from poppy-e185.americas.sgi.com (poppy-e185.americas.sgi.com [128.162.185.207]) by zeus-e8.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id QAA13925; Wed, 30 Jan 2002 16:25:46 -0600 (CST) Received: from stout.americas.sgi.com (stout.americas.sgi.com [128.162.187.5]) by poppy-e185.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.7) with ESMTP id QAA17193; Wed, 30 Jan 2002 16:25:46 -0600 (CST) Subject: Re: Oops in bdflush with 2.4.1[4|7]-xfs From: Eric Sandeen To: Nathan Poznick Cc: linux-xfs@oss.sgi.com In-Reply-To: <20020130222207.GA26516@conwaycorp.net> References: <20020130214108.GA25792@conwaycorp.net> <1012428591.4291.15.camel@stout.americas.sgi.com> <20020130222207.GA26516@conwaycorp.net> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/1.0 (Preview Release) Date: 30 Jan 2002 16:25:46 -0600 Message-Id: <1012429546.4291.19.camel@stout.americas.sgi.com> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 752 Lines: 32 If you're not using it, try turning it off. DMAPI-enabled kernels don't get as much testing as non-DMAPI, it could be causing the problem. Just a guess at this point. -Eric On Wed, 2002-01-30 at 16:22, Nathan Poznick wrote: > Thus spake Eric Sandeen: > > Hi Nathan - > > > > Out of curiosity.... do you have DMAPI turned on? (it looks like you > > do, from the xfs_dm_punch_hole in the stack). > > Yes, DMAPI is turned on. > > (from the kernel config) > > CONFIG_PAGE_BUF=y > CONFIG_XFS_FS=y > # CONFIG_XFS_RT is not set > # CONFIG_XFS_QUOTA is not set > CONFIG_HAVE_ATTRCTL=y > CONFIG_XFS_DMAPI=y > CONFIG_HAVE_XFS_DMAPI=y > > -Nathan -- Eric Sandeen XFS for Linux http://oss.sgi.com/projects/xfs sandeen@sgi.com SGI, Inc. From owner-linux-xfs@oss.sgi.com Wed Jan 30 15:45:35 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0UNjZZ27506 for linux-xfs-outgoing; Wed, 30 Jan 2002 15:45:35 -0800 Received: from mail.conwaycorp.net (mail.conwaycorp.net [24.144.1.33]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0UNjRd27481 for ; Wed, 30 Jan 2002 15:45:27 -0800 Received: (qmail 6777 invoked from network); 30 Jan 2002 22:34:33 -0000 Received: from unknown (HELO tao.wang-fu.org) (24.144.32.127) by mail.conwaycorp.net with SMTP; 30 Jan 2002 22:34:33 -0000 Received: from kraken by tao.wang-fu.org with local (Exim 3.34 #1 (Debian)) id 16W3Tn-0006zx-00; Wed, 30 Jan 2002 16:45:23 -0600 Date: Wed, 30 Jan 2002 16:45:23 -0600 From: Nathan Poznick To: Austin Gonyou Cc: linux-xfs@oss.sgi.com, linux-kernel@vger.kernel.org Subject: Re: Oops in bdflush with 2.4.1[4|7]-xfs Message-ID: <20020130224523.GA26824@conwaycorp.net> References: <20020130214108.GA25792@conwaycorp.net> <1012428545.12420.29.camel@UberGeek> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="WIyZ46R2i8wDzkSu" Content-Disposition: inline In-Reply-To: <1012428545.12420.29.camel@UberGeek> User-Agent: Mutt/1.3.27i Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 1566 Lines: 46 --WIyZ46R2i8wDzkSu Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Thus spake Austin Gonyou: > Could you see if my XFS-AA patch does anything for you? There are > changes to bdflush in it and I'd be interested to see if they go away.=20 >=20 > http://www.digitalroadkill.net/Patches/2.4.17-xfs-aa.patch.bz2 Unfortunately I can't really do to much messing around with this machine right now, it's being used pretty heavily. Even after bdflush died and I needed to bounce the machine, I just about had to beat the developers off the machine with a stick. :-) Eric Sandeen suggested turning off DMAPI support, so I'm going to give that a try first. I'll go ahead and grab a copy of your patch, and give it a try if the problem still resurfaces. --=20 Nathan Poznick PGP Key: http://drunkmonkey.org/pgpkey.txt Boss: You forgot to assign the result of your map! Hacker: Dang, I'm always forgetting my assignations... Boss: And what's that "goto" doing there?!? Hacker: Er, I guess my finger slipped when I was typing "getservbyport"... Boss: Ah well, accidents will happen. Maybe we should have picked APL. -- Larry Wall --WIyZ46R2i8wDzkSu 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 iD8DBQE8WHeDYOn9JTETs+URAkd/AKCIelsMjVEWbL1053/kSuQKf0xhEQCgpFOo SLJcvipfJ3FPvE1sefbA69w= =v08z -----END PGP SIGNATURE----- --WIyZ46R2i8wDzkSu-- From owner-linux-xfs@oss.sgi.com Wed Jan 30 15:48:24 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0UNmOc27688 for linux-xfs-outgoing; Wed, 30 Jan 2002 15:48:24 -0800 Received: from pizda.ninka.net (IDENT:root@pizda.ninka.net [216.101.162.242]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0UNmLd27666 for ; Wed, 30 Jan 2002 15:48:21 -0800 Received: from localhost (IDENT:davem@localhost.localdomain [127.0.0.1]) by pizda.ninka.net (8.9.3/8.9.3) with ESMTP id OAA16792; Wed, 30 Jan 2002 14:46:47 -0800 Date: Wed, 30 Jan 2002 14:46:47 -0800 (PST) Message-Id: <20020130.144647.21928212.davem@redhat.com> To: a.gruenbacher@computer.org CC: linux-xfs@oss.sgi.com Subject: extended attributes interface From: "David S. Miller" X-Mailer: Mew version 2.1 on Emacs 21.1 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 636 Lines: 15 All the values that go through these syscalls seem to be opaque and filesystem specific. Therefore can I ask the filesystems that use these things use fixed sized types such as "u32" "u16" et al. instead of things such as "long" or "int"? The reason I ask is, unless strict sized types are used it is going to be a real pain in the ass to translate the types passed to these system calls in mixed 32-bit/64-bit environments. This is thus going to be a mess on sparc64, ppc64, mips64, ia64, and probably others I have forgotten :-) If strict sized types are used for the attributes, then no translations will need to occur at all. From owner-linux-xfs@oss.sgi.com Wed Jan 30 15:53:39 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0UNrdB27920 for linux-xfs-outgoing; Wed, 30 Jan 2002 15:53:39 -0800 Received: from sgi.com (sgi-too.SGI.COM [204.94.211.39]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0UNrWd27898 for ; Wed, 30 Jan 2002 15:53:32 -0800 Received: from zeus-e8.americas.sgi.com (zeus-e8.americas.sgi.com [128.162.8.103]) by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id OAA05674 for ; Wed, 30 Jan 2002 14:51:09 -0800 (PST) mail_from (sandeen@sgi.com) Received: from poppy-e185.americas.sgi.com (poppy-e185.americas.sgi.com [128.162.185.207]) by zeus-e8.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id QAA14189; Wed, 30 Jan 2002 16:52:09 -0600 (CST) Received: from stout.americas.sgi.com (stout.americas.sgi.com [128.162.187.5]) by poppy-e185.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.7) with ESMTP id QAA20550; Wed, 30 Jan 2002 16:52:09 -0600 (CST) Subject: Re: Oops in bdflush with 2.4.1[4|7]-xfs From: Eric Sandeen To: Eric Sandeen Cc: Nathan Poznick , linux-xfs@oss.sgi.com In-Reply-To: <1012429546.4291.19.camel@stout.americas.sgi.com> References: <20020130214108.GA25792@conwaycorp.net> <1012428591.4291.15.camel@stout.americas.sgi.com> <20020130222207.GA26516@conwaycorp.net> <1012429546.4291.19.camel@stout.americas.sgi.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/1.0 (Preview Release) Date: 30 Jan 2002 16:52:08 -0600 Message-Id: <1012431129.4291.23.camel@stout.americas.sgi.com> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 964 Lines: 37 The other thing you can do is disassemble the code it oopsed in, so we can see where it was when it went belly up... I'm not sure where pagebuf lives in your current kernel tree... Can you try commenting out the last line of page_buf.c*, then chmod +x /localhome/eric/2.4.x-xfs/workarea-reallyclean/linux/scripts/makelst and make fs/xfs/pagebuf/page_buf.lst or make fs/pagebuf/page_buf.lst then send the resulting page_buf.lst to me, off-list? (don't forget to un-comment the last line when you're done). That way we can see where things go wrong. -Eric *(it doesn't deal with the EXPORT_SYMBOL() for some reason) On Wed, 2002-01-30 at 16:25, Eric Sandeen wrote: > If you're not using it, try turning it off. DMAPI-enabled kernels don't > get as much testing as non-DMAPI, it could be causing the problem. Just > a guess at this point. > > -Eric -- Eric Sandeen XFS for Linux http://oss.sgi.com/projects/xfs sandeen@sgi.com SGI, Inc. From owner-linux-xfs@oss.sgi.com Wed Jan 30 15:53:58 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0UNrwL28044 for linux-xfs-outgoing; Wed, 30 Jan 2002 15:53:58 -0800 Received: from gum.csee.uq.edu.au (gum.csee.uq.edu.au [130.102.66.1]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0UNrod28006 for ; Wed, 30 Jan 2002 15:53:50 -0800 Received: from nut.csee.uq.edu.au (nut.csee.uq.edu.au [130.102.66.13]) by gum.csee.uq.edu.au (8.11.6/8.11.6) with ESMTP id g0UMrbH13565; Thu, 31 Jan 2002 08:53:37 +1000 (EST) Received: from SPIKE (spike.csee.uq.edu.au [130.102.66.71]) by nut.csee.uq.edu.au (8.11.6/8.11.6) with SMTP id g0UMrb411071; Thu, 31 Jan 2002 08:53:37 +1000 (EST) Message-ID: <010601c1a9e0$f4210e20$47426682@csee.uq.edu.au> From: "Chris Pascoe" To: "Stephen Lord" Cc: References: <023501c1a953$f059a0f0$47426682@csee.uq.edu.au> <3C57F97A.7000400@sgi.com> Subject: Re: How long should an xfs_freeze take? Date: Thu, 31 Jan 2002 08:51:50 +1000 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.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-Scanned-By: MIMEDefang 1.3 (www dot roaringpenguin dot com slash mimedefang) Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 1557 Lines: 36 > How long freeze takes depends on how much data is dirty in the > filesystem, it should take a similar time to an unmount. However, > unless this was a very large and dirty filesystem this feels > like a long time - although it was all system time, > so something was going on. 6 hours is a long time for an unmount! The volume is ~70GB, and had no activity on it before I tried to create the snapshots - the machine had just been rebooted before some attempts. > The spot you kept seeing on the stack does not make much sense, vn_count is > basically an atomic_read. It just seems that's the place I've hit the break key the most. A closer examination of my console log suggests it isn't stuck in vn_count, there are a few occurances of it being somewhere else in xfs_iflush_all - so maybe it's got itself tangled in a loop for a few hours? 0xe95c3b88 0xc01a1a63 xfs_iflush_all+0xc3 (0xf6d1f000, 0x1, 0xf6d1f000, 0xc, 0xc039ce80) 0xe95c3b88 0xc01a1ab9 xfs_iflush_all+0x119 (0xf6d1f000, 0x1, 0xf6d1f000, 0xc, 0xc039ce80) 0xe95c3b88 0xc01a1ac3 xfs_iflush_all+0x123 (0xf6d1f000, 0x1, 0xf6d1f000, 0xc, 0xc039ce80) > How repeatable is this? The problem was persistent across reboots - I rebooted to install a different LVM version at some stage (move to 1.0.2, from 1.0.1), and it occurred five times in a row after that. I just rebooted now to say that it still happens - but, alas - it doesn't want to any more. I'll try again at some random times throughout the day. Chris From owner-linux-xfs@oss.sgi.com Wed Jan 30 16:12:13 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0V0CDY28733 for linux-xfs-outgoing; Wed, 30 Jan 2002 16:12:13 -0800 Received: from deliverator.sgi.com (deliverator.sgi.com [204.94.214.10]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0V0C8d28711 for ; Wed, 30 Jan 2002 16:12:08 -0800 Received: from nodin.corp.sgi.com (nodin.corp.sgi.com [192.26.51.193]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id PAA15814 for ; Wed, 30 Jan 2002 15:07:42 -0800 (PST) mail_from (kaos@sgi.com) Received: from kao2.melbourne.sgi.com (kao2.melbourne.sgi.com [134.14.55.180]) by nodin.corp.sgi.com (8.11.4/8.11.2/nodin-1.0) with ESMTP id g0UNB2827341730; Wed, 30 Jan 2002 15:11:03 -0800 (PST) Received: by kao2.melbourne.sgi.com (Postfix, from userid 16331) id 0992D3000B8; Thu, 31 Jan 2002 10:11:00 +1100 (EST) Received: from kao2.melbourne.sgi.com (localhost [127.0.0.1]) by kao2.melbourne.sgi.com (Postfix) with ESMTP id EF7898E; Thu, 31 Jan 2002 10:11:00 +1100 (EST) X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 From: Keith Owens To: "David S. Miller" Cc: a.gruenbacher@computer.org, linux-xfs@oss.sgi.com Subject: Re: extended attributes interface In-reply-to: Your message of "Wed, 30 Jan 2002 14:46:47 -0800." <20020130.144647.21928212.davem@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 31 Jan 2002 10:10:55 +1100 Message-ID: <5366.1012432255@kao2.melbourne.sgi.com> Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 1324 Lines: 27 On Wed, 30 Jan 2002 14:46:47 -0800 (PST), "David S. Miller" wrote: >All the values that go through these syscalls seem to be >opaque and filesystem specific. Therefore can I ask the filesystems >that use these things use fixed sized types such as "u32" "u16" et al. >instead of things such as "long" or "int"? Absolutely agree. >The reason I ask is, unless strict sized types are used it is going >to be a real pain in the ass to translate the types passed to these >system calls in mixed 32-bit/64-bit environments. This is thus going >to be a mess on sparc64, ppc64, mips64, ia64, and probably others I >have forgotten :-) Hopefully not for ia64. The ia32 compatibility mode syscall table is a subset of the i386 table, in particular new syscalls and Linux specific ones tend not to be in arch/ia64/ia32. ia32 mode on ia64 is not a long term compatibility aim, it is intended for running existing binaries that cannot be recompiled for native ia64 mode. I strongly recommend that the ACL syscalls are NOT added to arch/ia64/ia32. We have the source, compile the ACL programs in native ia64 mode. Sparc64 and mips64 are a problem as long as the kernel is 64 bit and userspace is 32 bit. I don't know if the kernel/userspace size mismatch applies to ppc64 as well or if it is more like ia64. From owner-linux-xfs@oss.sgi.com Wed Jan 30 16:13:52 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0V0Dq328882 for linux-xfs-outgoing; Wed, 30 Jan 2002 16:13:52 -0800 Received: from pizda.ninka.net (IDENT:root@pizda.ninka.net [216.101.162.242]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0V0Dnd28859 for ; Wed, 30 Jan 2002 16:13:49 -0800 Received: from localhost (IDENT:davem@localhost.localdomain [127.0.0.1]) by pizda.ninka.net (8.9.3/8.9.3) with ESMTP id PAA25333; Wed, 30 Jan 2002 15:12:17 -0800 Date: Wed, 30 Jan 2002 15:12:17 -0800 (PST) Message-Id: <20020130.151217.102576862.davem@redhat.com> To: kaos@sgi.com Cc: a.gruenbacher@computer.org, linux-xfs@oss.sgi.com Subject: Re: extended attributes interface From: "David S. Miller" In-Reply-To: <5366.1012432255@kao2.melbourne.sgi.com> References: <20020130.144647.21928212.davem@redhat.com> <5366.1012432255@kao2.melbourne.sgi.com> X-Mailer: Mew version 2.1 on Emacs 21.1 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 389 Lines: 12 From: Keith Owens Date: Thu, 31 Jan 2002 10:10:55 +1100 Sparc64 and mips64 are a problem as long as the kernel is 64 bit and userspace is 32 bit. Read this as: forever. Because we have several years worth of users with 32-bit userland distributions on at least sparc64. These people (including me, I have to test it :-) are not going away any time soon. From owner-linux-xfs@oss.sgi.com Wed Jan 30 16:15:24 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0V0FOv29038 for linux-xfs-outgoing; Wed, 30 Jan 2002 16:15:24 -0800 Received: from sgi.com (sgi-too.SGI.COM [204.94.211.39]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0V0FHd29009 for ; Wed, 30 Jan 2002 16:15:17 -0800 Received: from zeus-e8.americas.sgi.com (zeus-e8.americas.sgi.com [128.162.8.103]) by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id PAA07835 for ; Wed, 30 Jan 2002 15:12:58 -0800 (PST) mail_from (lord@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by zeus-e8.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id RAA14486; Wed, 30 Jan 2002 17:13:57 -0600 (CST) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id RAA16054; Wed, 30 Jan 2002 17:13:57 -0600 (CST) Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id g0UNBnG27522; Wed, 30 Jan 2002 17:11:49 -0600 Subject: Re: How long should an xfs_freeze take? From: Steve Lord To: Chris Pascoe Cc: linux-xfs@oss.sgi.com In-Reply-To: <010601c1a9e0$f4210e20$47426682@csee.uq.edu.au> References: <023501c1a953$f059a0f0$47426682@csee.uq.edu.au> <3C57F97A.7000400@sgi.com> <010601c1a9e0$f4210e20$47426682@csee.uq.edu.au> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/1.0.2 Date: 30 Jan 2002 17:11:49 -0600 Message-Id: <1012432309.26380.415.camel@jen.americas.sgi.com> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 2050 Lines: 50 On Wed, 2002-01-30 at 16:51, Chris Pascoe wrote: > > How long freeze takes depends on how much data is dirty in the > > filesystem, it should take a similar time to an unmount. However, > > unless this was a very large and dirty filesystem this feels > > like a long time - although it was all system time, > > so something was going on. > > 6 hours is a long time for an unmount! The volume is ~70GB, and had no > activity on it before I tried to create the snapshots - the machine had just > been rebooted before some attempts. Whoa! it was early this morning, I missed a few digits when I read the elapsed time! Yes, that is a leetle on the long side. There is a complex loop in the xfs_syncsub function, not sure yet how it can get stuck though. Steve > > > The spot you kept seeing on the stack does not make much sense, vn_count > is > > basically an atomic_read. > > It just seems that's the place I've hit the break key the most. A closer > examination of my console log suggests it isn't stuck in vn_count, there are > a few occurances of it being somewhere else in xfs_iflush_all - so maybe > it's got itself tangled in a loop for a few hours? > > 0xe95c3b88 0xc01a1a63 xfs_iflush_all+0xc3 > (0xf6d1f000, 0x1, 0xf6d1f000, 0xc, 0xc039ce80) > 0xe95c3b88 0xc01a1ab9 xfs_iflush_all+0x119 > (0xf6d1f000, 0x1, 0xf6d1f000, 0xc, 0xc039ce80) > 0xe95c3b88 0xc01a1ac3 xfs_iflush_all+0x123 > (0xf6d1f000, 0x1, 0xf6d1f000, 0xc, 0xc039ce80) > > > How repeatable is this? > > The problem was persistent across reboots - I rebooted to install a > different LVM version at some stage (move to 1.0.2, from 1.0.1), and it > occurred five times in a row after that. I just rebooted now to say that it > still happens - but, alas - it doesn't want to any more. I'll try again at > some random times throughout the day. > > Chris -- Steve Lord voice: +1-651-683-3511 Principal Engineer, Filesystem Software email: lord@sgi.com From owner-linux-xfs@oss.sgi.com Wed Jan 30 16:18:49 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0V0In929221 for linux-xfs-outgoing; Wed, 30 Jan 2002 16:18:49 -0800 Received: from pneumatic-tube.sgi.com (pneumatic-tube.sgi.com [204.94.214.22]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0V0Iid29196 for ; Wed, 30 Jan 2002 16:18:44 -0800 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via SMTP id PAA05699 for ; Wed, 30 Jan 2002 15:19:43 -0800 (PST) mail_from (nathans@wobbly.melbourne.sgi.com) Received: from wobbly.melbourne.sgi.com (wobbly.melbourne.sgi.com [134.14.55.135]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id KAA18221; Thu, 31 Jan 2002 10:17:24 +1100 Received: (from nathans@localhost) by wobbly.melbourne.sgi.com (SGI-8.9.3/8.9.3) id KAA86032; Thu, 31 Jan 2002 10:17:23 +1100 (AEDT) Date: Thu, 31 Jan 2002 10:17:23 +1100 From: Nathan Scott To: "David S. Miller" Cc: a.gruenbacher@computer.org, linux-xfs@oss.sgi.com Subject: Re: extended attributes interface Message-ID: <20020131101723.E82500@wobbly.melbourne.sgi.com> References: <20020130.144647.21928212.davem@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20020130.144647.21928212.davem@redhat.com>; from davem@redhat.com on Wed, Jan 30, 2002 at 02:46:47PM -0800 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 1012 Lines: 28 On Wed, Jan 30, 2002 at 02:46:47PM -0800, David S. Miller wrote: > > All the values that go through these syscalls seem to be > opaque and filesystem specific. Therefore can I ask the filesystems > that use these things use fixed sized types such as "u32" "u16" et al. > instead of things such as "long" or "int"? Yes, agreed. The main consumer of this interface currently is Andreas' POSIX ACL code, and IIRC he does use fixed size types for his ACL attributes. The man pages do refer to this issue, I will flesh out the wording to be a bit more explicit in this regard. thanks. > The reason I ask is, unless strict sized types are used it is going > to be a real pain in the ass to translate the types passed to these > system calls in mixed 32-bit/64-bit environments. This is thus going > to be a mess on sparc64, ppc64, mips64, ia64, and probably others I > have forgotten :-) > > If strict sized types are used for the attributes, then no > translations will need to occur at all. > -- Nathan From owner-linux-xfs@oss.sgi.com Wed Jan 30 18:20:33 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0V2KXY31991 for linux-xfs-outgoing; Wed, 30 Jan 2002 18:20:33 -0800 Received: from moutvdom01.kundenserver.de (moutvdom01.kundenserver.de [195.20.224.200]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0V2KQd31967 for ; Wed, 30 Jan 2002 18:20:27 -0800 Received: from [172.19.20.61] (helo=mrvdomng0.kundenserver.de) by moutvdom01.kundenserver.de with esmtp (Exim 2.12 #2) id 16W5tk-0002oL-00; Thu, 31 Jan 2002 02:20:20 +0100 Received: from [217.228.157.228] (helo=kernelpanix.aura.of.mankind) by mrvdomng0.kundenserver.de with esmtp (Exim 3.22 #2) id 16W5tj-0001jY-00; Thu, 31 Jan 2002 02:20:19 +0100 Received: (from utz@localhost) by kernelpanix.aura.of.mankind (8.11.2/8.11.2) id g0V1GSO01249; Thu, 31 Jan 2002 02:16:28 +0100 X-Authentication-Warning: kernelpanix.aura.of.mankind: utz set sender to xfs@s2y4n2c.de using -f Date: Thu, 31 Jan 2002 02:16:28 +0100 From: utz lehmann To: Eric Sandeen Cc: linux-xfs@oss.sgi.com Subject: Re: TAKE - 1 step closer to removing -funsigned-char Message-ID: <20020131021628.A1035@s2y4n2c.de> References: <200201302221.g0UMLnn12879@stout.americas.sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200201302221.g0UMLnn12879@stout.americas.sgi.com> Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 1197 Lines: 40 Hi Eric Eric Sandeen [sandeen@sgi.com] wrote: > XFS on Irix gets to assume chars are unsigned, which is not true > on Linux, so we use the -funsigned-char option when we build it. > Getting rid of this would be nice; we can explicitly define unsigned > chars when we need them. The trick is figuring out when we need them. :) > > These changes should fix the international character problems some were > seeing when -funsigned-char was turned off; if some of those brave souls > could turn off -funsigned-char on their machines and give it another go, > reports of success or failure would be welcome. :) Ok, here is my report of success.-) I wrote a perl script that touches 96 files. Each file begins with a different 8bit character (160 - 255) and have a random filename length. I removed -funsigned-char from linux/fs/xfs/Makefile and linux/fs/xfs/linux/Makefile. I created files with 2.4.9 and checkt it with 2.4.17 and vice versa. "ls -l" and removing works. No Problems. utz Here is the script: foreach $c0 (0 .. 95) { $f = ""; foreach $c1 ($c0 .. ($c0 + int( rand(17) + 5))) { $c = ($c1 % 96) + 160; $f .= sprintf("%c", $c); } # print "$f\n"; system ("touch $f"); } From owner-linux-xfs@oss.sgi.com Wed Jan 30 18:31:31 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0V2VVN32315 for linux-xfs-outgoing; Wed, 30 Jan 2002 18:31:31 -0800 Received: from UberGeek.coremetrics.com ([209.184.141.163]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0V2VMd32287 for ; Wed, 30 Jan 2002 18:31:22 -0800 Received: (from austin@localhost) by UberGeek.coremetrics.com (8.11.6/8.11.6) id g0V1UXl15634; Wed, 30 Jan 2002 19:30:33 -0600 X-Authentication-Warning: UberGeek.coremetrics.com: austin set sender to austin@coremetrics.com using -f Subject: Re: Oops in bdflush with 2.4.1[4|7]-xfs From: Austin Gonyou To: Nathan Poznick Cc: linux-xfs@oss.sgi.com, linux-kernel@vger.kernel.org In-Reply-To: <20020130224523.GA26824@conwaycorp.net> References: <20020130224523.GA26824@conwaycorp.net> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-AcpOTpv27WMptG5MMvfV" X-Mailer: Evolution/1.0.2 Date: 30 Jan 2002 19:30:33 -0600 Message-Id: <1012440633.15133.9.camel@UberGeek> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 2000 Lines: 61 --=-AcpOTpv27WMptG5MMvfV Content-Type: text/plain Content-Transfer-Encoding: quoted-printable I'd agree with Eric that DMAPI could be causing you a problem. I don't have it on in general. On Wed, 2002-01-30 at 16:45, Nathan Poznick wrote: > Thus spake Austin Gonyou: > > Could you see if my XFS-AA patch does anything for you? There are > > changes to bdflush in it and I'd be interested to see if they go away. >=20 > >=20 > > http://www.digitalroadkill.net/Patches/2.4.17-xfs-aa.patch.bz2 >=20 > Unfortunately I can't really do to much messing around with this > machine right now, it's being used pretty heavily. Even after bdflush > died and I needed to bounce the machine, I just about had to beat the > developers off the machine with a stick. :-) >=20 > Eric Sandeen suggested turning off DMAPI support, so I'm going to give > that a try first. I'll go ahead and grab a copy of your patch, and > give it a try if the problem still resurfaces. >=20 > --=20 > Nathan Poznick > PGP Key: http://drunkmonkey.org/pgpkey.txt >=20 > Boss: You forgot to assign the result of your map! > Hacker: Dang, I'm always forgetting my assignations... > Boss: And what's that "goto" doing there?!? > Hacker: Er, I guess my finger slipped when I was typing > "getservbyport"... > Boss: Ah well, accidents will happen. Maybe we should have picked > APL. > -- Larry Wall --=20 Austin Gonyou Systems Architect, CCNA Coremetrics, Inc. Phone: 512-698-7250 email: austin@coremetrics.com "It is the part of a good shepherd to shear his flock, not to skin it." Latin Proverb --=-AcpOTpv27WMptG5MMvfV Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQA8WJ4594g6ZVmFMoIRAlWkAKC5WmGEmmyepaF4cWu9xF+eRWoAgACgpao1 P3LP7PWxJX3SQ7Vxh08bsuo= =6dUF -----END PGP SIGNATURE----- --=-AcpOTpv27WMptG5MMvfV-- From owner-linux-xfs@oss.sgi.com Wed Jan 30 23:37:18 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0V7bIi06361 for linux-xfs-outgoing; Wed, 30 Jan 2002 23:37:18 -0800 Received: from methyl.vcp.monash.edu.au (methyl.vcp.monash.edu.au [130.194.217.45]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0V7bDd06339 for ; Wed, 30 Jan 2002 23:37:13 -0800 Received: from localhost (david@localhost) by methyl.vcp.monash.edu.au (SGI-8.9.3/8.9.3) with ESMTP id RAA29184 for ; Thu, 31 Jan 2002 17:46:27 +1100 (EDT) X-Authentication-Warning: methyl.vcp.monash.edu.au: david owned process doing -bs Date: Thu, 31 Jan 2002 17:46:27 +1100 From: David Chalmers X-Sender: To: Subject: Kernel panic during reboot Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 955 Lines: 26 Hi After some trouble with a machine running Redhat 7.1 with SGI-XFS-1.01 we get the following message. Is all lost? Can I recover this? (This is retyped from the screen so the case may not be right). XFS: Warning: recovery required on readonly filesystem XFS: Write access will be enabled during mount Starting XFS recovery on filesystem: ide0(3,6) (dev: 3/6) XFS: xlog_recover_process_data: bad transaction XFS: log mount/recovery failed XFS: log mount failed Kernel panic: VFS: unable to mount root fs on 03:06 Thanks for any help that anyone can offer. David _____________________________________________________________________________ David Chalmers Lab: 9903 9110 Victorian College of Pharmacy Fax: 9903 9582 381 Royal Pde, Parkville, Vic 3053 http://synapse.vcp.monash.edu.au Australia David.Chalmers@vcp.monash.edu.au _____________________________________________________________________________ From owner-linux-xfs@oss.sgi.com Wed Jan 30 23:43:40 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0V7hem06697 for linux-xfs-outgoing; Wed, 30 Jan 2002 23:43:40 -0800 Received: from UberGeek.coremetrics.com ([209.184.141.163]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0V7hVd06672 for ; Wed, 30 Jan 2002 23:43:31 -0800 Received: (from austin@localhost) by UberGeek.coremetrics.com (8.11.6/8.11.6) id g0V6gsD17193; Thu, 31 Jan 2002 00:42:54 -0600 X-Authentication-Warning: UberGeek.coremetrics.com: austin set sender to austin@coremetrics.com using -f Subject: [OT] Request for assistance. Please reply off-list. From: Austin Gonyou To: linux-xfs@oss.sgi.com Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-byS4qoYVHEdpERYEh5N+" X-Mailer: Evolution/1.0.2 Date: 31 Jan 2002 00:42:53 -0600 Message-Id: <1012459373.17154.10.camel@UberGeek> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 2046 Lines: 64 --=-byS4qoYVHEdpERYEh5N+ Content-Type: text/plain Content-Transfer-Encoding: quoted-printable I've got a major Oracle problem and I'm not sure what to do. I can't figure it out and I need some ideas on how to go about trouble shooting/fixing this problem. If you've got oracle+linux+XFS experience, I can REALLY use your help.=20 Problem: sqlplus segfaults when trying to compile packages. (stored procedures) Linux Distro: RH 7.1/7.2 SGI XFS installed Kernels: 2.4.10 ->2.4.17 Glibc 2.2.2-10 -> 2.2.5 compiled gcc 2.96-81 -> 3.0.3 compiled.=20 I've got several systems that work without much issue.=20 They are dual PIII 550. 2GB ram. 45GB hdd(9+36) The server I'm trying to get going is a Dell 6450 8GB RAM, 4P 700Mhz Xeon. 204GB Disk space 8x36.=20 the re-linked binaries on the target platform are larger than on the servers that are currently working and don't display the issue.=20 I've tried to use gdb and strace to figure out what's going on, but there is never any descriptive info when this occurrs. Core files are found, but do not yeild any information as there are no symbols and the segfault I get is a "generic error".=20 There's been info about eval.c:36 in relation to the dumps, but that's usually about it.=20 Thanks for you time and sorry for the bother. This project is VERY important, and I'm getting short on time. Yes, we've opened a TAR with Oracle already, but they're not very quick to respond.=20 --=20 Austin Gonyou Systems Architect, CCNA Coremetrics, Inc. Phone: 512-698-7250 email: austin@coremetrics.com "It is the part of a good shepherd to shear his flock, not to skin it." Latin Proverb --=-byS4qoYVHEdpERYEh5N+ Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQA8WOdt94g6ZVmFMoIRAuADAJ9lWxPt10pxU31f6JQCrZ9oC9MsUQCfQ2t0 JdCLnqqeF9/RvfndlYkfS6Y= =6rgF -----END PGP SIGNATURE----- --=-byS4qoYVHEdpERYEh5N+-- From owner-linux-xfs@oss.sgi.com Thu Jan 31 01:00:47 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0V90lE08644 for linux-xfs-outgoing; Thu, 31 Jan 2002 01:00:47 -0800 Received: from mailout03.sul.t-online.com (mailout03.sul.t-online.com [194.25.134.81]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0V90gd08622 for ; Thu, 31 Jan 2002 01:00:42 -0800 Received: from fwd00.sul.t-online.de by mailout03.sul.t-online.com with smtp id 16WC98-0004pQ-03; Thu, 31 Jan 2002 09:00:38 +0100 Received: from Deimos (520094219231-0001@[217.86.168.73]) by fmrl00.sul.t-online.com with esmtp id 16WC8p-2Bs5HEC; Thu, 31 Jan 2002 09:00:19 +0100 Received: by triffnix.de via sendmail from stdin id (Debian Smail3.2.0.111) for linux-xfs@oss.sgi.com; Thu, 31 Jan 2002 09:00:18 +0100 (CET) Message-ID: X-Mailer: XFMail 1.4.7p2 on Linux X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 Date: Thu, 31 Jan 2002 09:00:18 +0100 (CET) From: unruh@elvis.informatik.uni-freiburg.de To: linux-xfs@oss.sgi.com Subject: xfsrestore fails: assertion failure in do_next_mark X-Sender: 520094219231-0001@t-dialin.net Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 879 Lines: 25 Hello! On a Linux-i386 system I have created a tape backup with xfsdump 1.1.3. When trying to restore the backup, xfsdump 1.1.14 segfaults. I have then upgraded to the latest CVS version, which fails as well with the following output. xfsrestore: using online session inventory xfsrestore: searching media for directory dump xfsrestore: reading directories xfsrestore: 27137 directories and 942280 entries processed xfsrestore: directory post-processing xfsrestore: restoring non-directory files xfsrestore: examining media file 1 xfsrestore: examining media file 2 xfsrestore: examining media file 3 xfsrestore: seeking past media file directory dump xfsrestore: drive_scsitape.c:1507: do_next_mark: Assertion `rechdrp->first_mark_offset - rechdrp->file_offset <= ( off64_t )( contextp->dc_recsz )' failed. Aborted Any help to restore this backup would be appreciated. From owner-linux-xfs@oss.sgi.com Thu Jan 31 01:06:24 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0V96OR08880 for linux-xfs-outgoing; Thu, 31 Jan 2002 01:06:24 -0800 Received: from relay.xlink.net (relay.xlink.net [193.141.40.4]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0V96Id08857 for ; Thu, 31 Jan 2002 01:06:18 -0800 Received: from lizard.webland.de (lizard.webland.de [194.122.76.201]) by relay.xlink.net (8.9.3/8.8.7) with ESMTP id JAA16114; Thu, 31 Jan 2002 09:06:14 +0100 (MET) Received: (from uucp@localhost) by lizard.webland.de (8.8.8/8.8.7) id JAA13663; Thu, 31 Jan 2002 09:06:13 +0100 (MET) >Received: from mobile.sauter-bc.com (unknown [10.1.6.21]) by basel1.sauter-bc.com (Postfix) with ESMTP id 4824257306; Thu, 31 Jan 2002 09:05:14 +0100 (CET) Received: from ch.sauter-bc.com (support.cad.sba [10.1.200.117]) by mobile.sauter-bc.com (Postfix) with ESMTP id BA15D25835; Thu, 31 Jan 2002 09:05:13 +0100 (CET) Message-ID: <3C58FAB9.D940E9B8@ch.sauter-bc.com> Date: Thu, 31 Jan 2002 09:05:13 +0100 From: Simon Matter Organization: Sauter AG, Basel X-Mailer: Mozilla 4.77 [de] (X11; U; Linux 2.2.19-6.2.12 i686) X-Accept-Language: de-CH, en MIME-Version: 1.0 To: unruh@elvis.informatik.uni-freiburg.de Cc: linux-xfs@oss.sgi.com Subject: Re: xfsrestore fails: assertion failure in do_next_mark References: Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 1184 Lines: 33 unruh@elvis.informatik.uni-freiburg.de schrieb: > > Hello! > > On a Linux-i386 system I have created a tape backup with xfsdump 1.1.3. > When trying to restore the backup, xfsdump 1.1.14 segfaults. I have then > upgraded to the latest CVS version, which fails as well with the following > output. > > xfsrestore: using online session inventory > xfsrestore: searching media for directory dump > xfsrestore: reading directories > xfsrestore: 27137 directories and 942280 entries processed > xfsrestore: directory post-processing > xfsrestore: restoring non-directory files > xfsrestore: examining media file 1 > xfsrestore: examining media file 2 > xfsrestore: examining media file 3 > xfsrestore: seeking past media file directory dump > xfsrestore: drive_scsitape.c:1507: do_next_mark: Assertion > `rechdrp->first_mark_offset - rechdrp->file_offset <= ( off64_t )( > contextp->dc_recsz )' failed. > Aborted > > Any help to restore this backup would be appreciated. IIRC I got the same error some months ago when trying to restore from a DDS2 DAT drive. On the same system restoring from DLT was okay. I didn't try again but I guess this bug is still not fixed :-( -Simon From owner-linux-xfs@oss.sgi.com Thu Jan 31 02:29:25 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0VATP512101 for linux-xfs-outgoing; Thu, 31 Jan 2002 02:29:25 -0800 Received: from dialsav.com ([211.238.96.132]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0VATHd12066 for ; Thu, 31 Jan 2002 02:29:17 -0800 Received: from ns3.dialsav.com (unverified [211.238.96.132]) by dialsav.com (EMWAC SMTPRS 0.83) with SMTP id ; Thu, 31 Jan 2002 02:02:13 -0500 Received: from mail pickup service by ns3.dialsav.com with Microsoft SMTPSVC; Thu, 31 Jan 2002 02:02:13 -0500 From: To: Subject: =?euc-kr?B?WyC3r7rqvK3HwbimIMPfw7XH1bTPtNkuIF0=?= Date: Thu, 31 Jan 2002 02:02:12 -0500 MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Message-ID: X-OriginalArrivalTime: 31 Jan 2002 07:02:13.0070 (UTC) FILETIME=[3578B6E0:01C1AA25] Content-Disposition: inline Content-Type: text/plain Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id g0VATP612101 Status: O Content-Length: 981 Lines: 29 ´Ô.. ¾È³çÇϼ¼¿ä? [click to see ] "»ç¶û Çϸ鼭 Ä£±¸·Î ¸¸³ª´Â°Ô ¹«½¼ Àǹ̰¡ ÀÖÁÒ?" "¹Ù¶ó¸¸ º¸´Â »ç¶ûµµ ÀÖ¾î¿ä." "¿Ö ±×·± »ç¶ûÀ» ÇÏÁÒ? °ÅºÎ´çÇÒ°¡ µÎ·Á¿ö¿ä?" "³­ ±× »ç¶÷À» »ç¶ûÇϴ°ÅÁö, »ç¶û¹Þ±â¸¦ ¿øÇÏ´Â°Ç ¾Æ³×¿ä..." www.Lovesurf.co.kr * ÇѱÛÆÇÀº ÃÑ 29,000 ÆäÀÌÁö·Î ´ÜÀϱâ´É À¥ »çÀÌÆ®·Î´Â Çѱ¹Àº ¹°·Ð ¼¼°è ÃÖ´ë±Ô¸ðÀÇ »çÀÌÆ®·Î ¼ºÀÎ [³²°ú¿©], [³²°ú³²], [¿©¿Í¿©], û¼Ò³â[³²°ú¿©]ÀÇ 4 °³ÀÇ Ä¿¹Â´ÏƼ¸¦ ¸ðµÎ ¼ö¿ëÇÑ »çÀÌÆ®·Î ½Ì±Û ¶óÀÌÇÁÀÇ »ç»ýÈ°±ÇÀÇ º¸È£¿Í ½ºÅäÄ¿ÀÇ ¹æÁö¸¦ ÃÖ¿ì¼±À¸·Î Á¶Á÷µÈ À¥ »çÀÌÆ® ÀÔ´Ï´Ù. û¼Ò³âÀ» À§ÇÑ »çÀÌÆ®´Â www.mygal.co.kr ÀÔ´Ï´Ù. ÃßõÀÎ - ÀÌ ¸ÞÀÏÀ» ¾ÕÀ¸·Î ¹Þ°í ½ÍÁö ¾ÊÀ¸½Ã´Ù¸é ¸ÞÀϼö½Å°ÅÀý À» Å©¸¯ Çϼ¼¿ä. [[HTML alternate version deleted]] From owner-linux-xfs@oss.sgi.com Thu Jan 31 03:30:01 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0VBU1d13396 for linux-xfs-outgoing; Thu, 31 Jan 2002 03:30:01 -0800 Received: from yog-sothoth.sgi.com (eugate.sgi.com [192.48.160.10]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0VBTYd13365 for ; Thu, 31 Jan 2002 03:29:35 -0800 Received: from zeus-e8.americas.sgi.com (zeus-e8.americas.sgi.com [128.162.8.103]) by yog-sothoth.sgi.com (980305.SGI.8.8.8-aspam-6.2/980304.SGI-aspam-europe) via ESMTP id LAA161924 for ; Thu, 31 Jan 2002 11:28:06 +0100 (CET) mail_from (lord@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by zeus-e8.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id EAA19904 for ; Thu, 31 Jan 2002 04:28:13 -0600 (CST) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id EAA13622 for ; Thu, 31 Jan 2002 04:28:13 -0600 (CST) From: Steve Lord Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id g0VAPxE05531; Thu, 31 Jan 2002 04:25:59 -0600 Message-Id: <200201311025.g0VAPxE05531@jen.americas.sgi.com> Date: Thu, 31 Jan 2002 04:25:59 -0600 Subject: TAKE - merge up to 2.5.3 To: linux-xfs@oss.sgi.com Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 7836 Lines: 223 New system calls for acls - not being used yet though, we need to sync lots of things up before switching over. Date: Thu Jan 31 02:24:34 PST 2002 Workarea: jen.americas.sgi.com:/src/lord/xfs-merge The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.5.x-xfs Modid: 2.5.x-xfs:slinx:110678a linux/fs/xattr.c - 1.1 linux/lib/zlib_inflate/infblock.c - 1.1 linux/lib/zlib_inflate/Makefile - 1.1 linux/linux/zutil.h - 1.1 linux/linux/zconf.h - 1.1 linux/lib/zlib_inflate/infutil.h - 1.1 linux/lib/zlib_inflate/infutil.c - 1.1 linux/lib/zlib_inflate/inftrees.h - 1.1 linux/lib/zlib_inflate/inftrees.c - 1.1 linux/lib/zlib_inflate/inflate_syms.c - 1.1 linux/lib/zlib_inflate/inflate.c - 1.1 linux/lib/zlib_inflate/inffixed.h - 1.1 linux/lib/zlib_inflate/inffast.h - 1.1 linux/lib/zlib_inflate/inffast.c - 1.1 linux/lib/zlib_inflate/infcodes.h - 1.1 linux/lib/zlib_inflate/infcodes.c - 1.1 linux/lib/zlib_inflate/infblock.h - 1.1 linux/lib/zlib_deflate/deflate.c - 1.1 linux/drivers/pnp/pnpbios_core.c - 1.1 linux/lib/zlib_deflate/defutil.h - 1.1 linux/lib/zlib_deflate/deftree.c - 1.1 linux/lib/zlib_deflate/deflate_syms.c - 1.1 linux/lib/zlib_deflate/Makefile - 1.1 linux/drivers/pnp/pnpbios_proc.c - 1.1 linux/include/linux/pnpbios.h - 1.1 linux/include/linux/xattr.h - 1.1 linux/include/linux/zlib.h - 1.1 linux/scripts/Menuconfig - 1.14 linux/net/sunrpc/svc.c - 1.9 linux/net/sunrpc/sched.c - 1.25 linux/lib/Makefile - 1.10 linux/kernel/signal.c - 1.24 linux/kernel/sched.c - 1.56 linux/kernel/ksyms.c - 1.131 linux/kernel/fork.c - 1.46 linux/include/linux/sched.h - 1.58 linux/include/linux/limits.h - 1.5 linux/include/linux/fs.h - 1.147 linux/include/asm-i386/unistd.h - 1.19 linux/include/asm-i386/signal.h - 1.6 linux/include/asm-i386/desc.h - 1.8 linux/fs/ufs/file.c - 1.9 linux/fs/read_write.c - 1.16 linux/fs/proc/generic.c - 1.24 linux/fs/nfsd/export.c - 1.23 linux/fs/lockd/svc.c - 1.14 linux/fs/isofs/Makefile - 1.7 linux/fs/hfs/file_hdr.c - 1.12 linux/fs/hfs/file_cap.c - 1.12 linux/fs/buffer.c - 1.109 linux/fs/block_dev.c - 1.39 linux/fs/Makefile - 1.46 linux/fs/Config.in - 1.76 linux/drivers/usb/usb.c - 1.66 linux/drivers/scsi/wd7000.c - 1.14 linux/drivers/scsi/ultrastor.c - 1.11 linux/drivers/scsi/u14-34f.c - 1.20 linux/drivers/scsi/tmscsim.c - 1.15 linux/drivers/scsi/t128.c - 1.9 linux/drivers/scsi/sym53c416.c - 1.11 linux/drivers/scsi/sgiwd93.c - 1.12 linux/drivers/scsi/seagate.c - 1.15 linux/drivers/scsi/qlogicfas.c - 1.12 linux/drivers/scsi/psi240i.c - 1.8 linux/drivers/scsi/ppa.c - 1.13 linux/drivers/scsi/pci2220i.c - 1.22 linux/drivers/scsi/pci2000.c - 1.20 linux/drivers/scsi/pas16.c - 1.10 linux/drivers/scsi/mesh.c - 1.11 linux/drivers/scsi/megaraid.c - 1.32 linux/drivers/scsi/mca_53c9x.c - 1.9 linux/drivers/scsi/mac_esp.c - 1.11 linux/drivers/scsi/mac53c94.c - 1.9 linux/drivers/scsi/jazz_esp.c - 1.7 linux/drivers/scsi/inia100.c - 1.17 linux/drivers/scsi/ini9100u.c - 1.16 linux/drivers/scsi/in2000.h - 1.9 linux/drivers/scsi/imm.c - 1.14 linux/drivers/scsi/ibmmca.c - 1.15 linux/drivers/scsi/gvp11.c - 1.12 linux/drivers/scsi/gdth.c - 1.19 linux/drivers/scsi/fdomain.c - 1.19 linux/drivers/scsi/fd_mcs.c - 1.7 linux/drivers/scsi/fastlane.c - 1.10 linux/drivers/scsi/esp.c - 1.19 linux/drivers/scsi/eata_pio.c - 1.15 linux/drivers/scsi/eata_dma.c - 1.18 linux/drivers/scsi/eata.c - 1.21 linux/drivers/scsi/dtc.c - 1.9 linux/drivers/scsi/cyberstormII.c - 1.10 linux/drivers/scsi/cyberstorm.c - 1.10 linux/drivers/scsi/blz2060.c - 1.10 linux/drivers/scsi/blz1230.c - 1.10 linux/drivers/scsi/atp870u.c - 1.19 linux/drivers/scsi/aha1740.c - 1.9 linux/drivers/scsi/aha1542.c - 1.21 linux/drivers/scsi/aha152x.c - 1.27 linux/drivers/scsi/advansys.c - 1.24 linux/drivers/scsi/a3000.c - 1.11 linux/drivers/scsi/a2091.c - 1.13 linux/drivers/scsi/NCR53c406a.c - 1.12 linux/drivers/scsi/NCR53C9x.c - 1.12 linux/drivers/scsi/NCR5380.c - 1.8 linux/drivers/scsi/BusLogic.h - 1.8 linux/drivers/scsi/AM53C974.c - 1.13 linux/drivers/scsi/53c7,8xx.c - 1.17 linux/drivers/pnp/Makefile - 1.11 linux/drivers/pnp/Config.in - 1.8 linux/drivers/net/zlib.h - 1.3 linux/drivers/net/zlib.c - 1.6 linux/drivers/net/ppp_deflate.c - 1.7 linux/arch/sparc64/kernel/rtrap.S - 1.12 linux/arch/sparc64/kernel/process.c - 1.29 linux/arch/sparc/kernel/smp.c - 1.17 linux/arch/sparc/kernel/rtrap.S - 1.9 linux/arch/ppc/kernel/smp.c - 1.31 linux/arch/ppc/kernel/mk_defs.c - 1.14 linux/arch/mips/tools/offset.c - 1.8 linux/arch/mips/kernel/scall_o32.S - 1.10 linux/arch/mips/kernel/entry.S - 1.9 linux/arch/m68k/kernel/m68k_defs.c - 1.5 linux/arch/i386/kernel/vm86.c - 1.11 linux/arch/i386/kernel/traps.c - 1.45 linux/arch/i386/kernel/signal.c - 1.21 linux/arch/i386/kernel/ptrace.c - 1.19 linux/arch/i386/kernel/process.c - 1.42 linux/arch/i386/kernel/head.S - 1.20 linux/arch/i386/kernel/entry.S - 1.45 linux/arch/i386/defconfig - 1.95 linux/arch/arm/kernel/entry-common.S - 1.18 linux/arch/alpha/kernel/process.c - 1.21 linux/arch/alpha/kernel/entry.S - 1.23 linux/arch/alpha/kernel/check_asm.c - 1.3 linux/Makefile - 1.181 linux/MAINTAINERS - 1.93 linux/fs/hpfs/dir.c - 1.10 linux/drivers/scsi/sun3x_esp.c - 1.6 linux/drivers/scsi/oktagon_esp.c - 1.7 linux/drivers/pnp/isapnp.c - 1.25 linux/arch/ppc/kernel/entry.S - 1.23 linux/arch/sh/kernel/entry.S - 1.21 linux/drivers/scsi/ips.c - 1.22 linux/drivers/scsi/sim710.c - 1.10 linux/drivers/scsi/dec_esp.c - 1.7 linux/fs/cramfs/Makefile - 1.5 linux/drivers/usb/ov511.c - 1.30 linux/drivers/scsi/3w-xxxx.c - 1.15 linux/arch/ia64/kernel/entry.S - 1.18 linux/arch/ia64/tools/print_offsets.c - 1.9 linux/drivers/scsi/qla1280.c - 1.13 linux/Documentation/filesystems/devfs/README - 1.13 linux/Documentation/filesystems/devfs/ChangeLog - 1.19 linux/fs/devfs/base.c - 1.30 linux/arch/mips64/tools/offset.c - 1.5 linux/arch/mips64/kernel/scall_o32.S - 1.8 linux/arch/mips64/kernel/scall_64.S - 1.10 linux/arch/mips64/kernel/entry.S - 1.7 linux/include/linux/usb.h - 1.28 linux/drivers/scsi/sym53c8xx_comm.h - 1.12 linux/drivers/sound/i810_audio.c - 1.21 linux/arch/s390/kernel/entry.S - 1.15 linux/Documentation/filesystems/Locking - 1.4 linux/arch/i386/kernel/bluesmoke.c - 1.16 linux/drivers/scsi/cpqfcTSinit.c - 1.14 linux/drivers/scsi/cpqfcTSworker.c - 1.10 linux/arch/parisc/kernel/entry.S - 1.2 linux/arch/parisc/tools/offset.c - 1.2 linux/fs/reiserfs/stree.c - 1.17 linux/fs/reiserfs/super.c - 1.15 linux/fs/reiserfs/tail_conversion.c - 1.11 linux/fs/reiserfs/version.c - 1.2 linux/fs/reiserfs/resize.c - 1.5 linux/fs/reiserfs/prints.c - 1.10 linux/fs/reiserfs/objectid.c - 1.8 linux/fs/reiserfs/namei.c - 1.16 linux/fs/reiserfs/lbalance.c - 1.6 linux/fs/reiserfs/journal.c - 1.20 linux/fs/reiserfs/ioctl.c - 1.5 linux/fs/reiserfs/inode.c - 1.24 linux/fs/reiserfs/fix_node.c - 1.14 linux/fs/reiserfs/file.c - 1.7 linux/fs/reiserfs/do_balan.c - 1.8 linux/fs/reiserfs/dir.c - 1.9 linux/fs/reiserfs/buffer2.c - 1.9 linux/include/linux/reiserfs_fs.h - 1.18 linux/include/linux/reiserfs_fs_i.h - 1.6 linux/include/linux/reiserfs_fs_sb.h - 1.8 linux/fs/reiserfs/bitmap.c - 1.12 linux/fs/reiserfs/Makefile - 1.5 linux/arch/s390x/kernel/entry.S - 1.10 linux/arch/arm/tools/getconstants.c - 1.6 linux/drivers/net/wan/dscc4.c - 1.6 linux/arch/mips/kernel/smp.c - 1.4 linux/arch/cris/kernel/entryoffsets.c - 1.3 linux/drivers/scsi/dpt_i2o.c - 1.9 linux/drivers/scsi/53c700.c - 1.5 linux/fs/jffs2/Makefile - 1.4 linux/fs/jffs2/compr_zlib.c - 1.3 linux/fs/jffs2/zlib.c - 1.2 linux/fs/jffs2/zlib.h - 1.2 linux/include/linux/zlib_fs.h - 1.2 linux/fs/ext3/ialloc.c - 1.7 linux/include/linux/ext3_fs_i.h - 1.3 linux/fs/reiserfs/procfs.c - 1.3 linux/fs/driverfs/inode.c - 1.5 linux/drivers/usb/hcd.c - 1.6 linux/lib/Config.in - 1.2 linux/include/linux/init_task.h - 1.4 linux/drivers/pnp/Config.help - 1.2 linux/drivers/base/interface.c - 1.2 linux/drivers/base/core.c - 1.2 From owner-linux-xfs@oss.sgi.com Thu Jan 31 04:14:13 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0VCED914643 for linux-xfs-outgoing; Thu, 31 Jan 2002 04:14:13 -0800 Received: from pneumatic-tube.sgi.com (pneumatic-tube.sgi.com [204.94.214.22]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0VCE9d14620 for ; Thu, 31 Jan 2002 04:14:09 -0800 Received: from zeus-e8.americas.sgi.com (zeus-e8.americas.sgi.com [128.162.8.103]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id DAA04874 for ; Thu, 31 Jan 2002 03:15:09 -0800 (PST) mail_from (lord@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by zeus-e8.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id FAA20324 for ; Thu, 31 Jan 2002 05:12:50 -0600 (CST) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id FAA50474 for ; Thu, 31 Jan 2002 05:12:50 -0600 (CST) From: Steve Lord Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id g0VBAah18415; Thu, 31 Jan 2002 05:10:36 -0600 Message-Id: <200201311110.g0VBAah18415@jen.americas.sgi.com> Date: Thu, 31 Jan 2002 05:10:36 -0600 Subject: TAKE - xfs memory allocation, use GFP_KERNEL more Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 743 Lines: 25 This is a reworking of a previous mod which was withdrawn due to bad interactions with ext3. We now use a different mechanism to record being in a transaction or not. Date: Thu Jan 31 03:10:15 PST 2002 Workarea: jen.americas.sgi.com:/src/lord/xfs-linux.2.4 The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:110679a linux/include/linux/sched.h - 1.50 - Add new PF flag for transaction state linux/fs/xfs/xfs_trans.c - 1.127 - keep track of if we are in a transaction or not. linux/fs/xfs/linux/xfs_iops.c - 1.121 - Bounce delalloc writepage calls during transactions linux/fs/xfs_support/kmem.c - 1.20 - Make allocation flags dependent on being in a transaction or not. From owner-linux-xfs@oss.sgi.com Thu Jan 31 09:08:18 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0VH8Im26455 for linux-xfs-outgoing; Thu, 31 Jan 2002 09:08:18 -0800 Received: from yog-sothoth.sgi.com (eugate.sgi.com [192.48.160.10]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0VH8Cd26433 for ; Thu, 31 Jan 2002 09:08:13 -0800 Received: from zeus-e8.americas.sgi.com (zeus-e8.americas.sgi.com [128.162.8.103]) by yog-sothoth.sgi.com (980305.SGI.8.8.8-aspam-6.2/980304.SGI-aspam-europe) via ESMTP id RAA180276 for ; Thu, 31 Jan 2002 17:07:05 +0100 (CET) mail_from (sandeen@sgi.com) Received: from poppy-e185.americas.sgi.com (poppy-e185.americas.sgi.com [128.162.185.207]) by zeus-e8.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id KAA23677; Thu, 31 Jan 2002 10:06:51 -0600 (CST) Received: from stout.americas.sgi.com (stout.americas.sgi.com [128.162.187.5]) by poppy-e185.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.7) with ESMTP id KAA49770; Thu, 31 Jan 2002 10:06:51 -0600 (CST) Subject: Re: Kernel panic during reboot (recovery) From: Eric Sandeen To: David Chalmers Cc: linux-xfs@oss.sgi.com In-Reply-To: References: Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/1.0 (Preview Release) Date: 31 Jan 2002 10:06:51 -0600 Message-Id: <1012493211.20484.6.camel@stout.americas.sgi.com> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 900 Lines: 29 On Thu, 2002-01-31 at 00:46, David Chalmers wrote: > Hi > > After some trouble with a machine running Redhat 7.1 with SGI-XFS-1.01 > we get the following message. Is all lost? Can I recover this? > XFS: log mount/recovery failed Hi David - I don't recall offhand what type of recovery changes have been made since 1.0.1... that was quite a while ago. You might try a more recent kernel*, and see if recovery goes better. As a last resort, you could use a rescue disk and a recent xfs_repair with the "-L" option to zero the log - of course you will lose anything in the log, which could cause file/data loss. Let's see if anyone else has better suggestions before you try that drastic step... -Eric *booting the 1.0.2 installer in "rescue" mode will get you a 2.4.7 kernel, for example. -- Eric Sandeen XFS for Linux http://oss.sgi.com/projects/xfs sandeen@sgi.com SGI, Inc. From owner-linux-xfs@oss.sgi.com Thu Jan 31 09:14:27 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0VHER526659 for linux-xfs-outgoing; Thu, 31 Jan 2002 09:14:27 -0800 Received: from Cantor.suse.de (ns.suse.de [213.95.15.193]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0VHENd26637 for ; Thu, 31 Jan 2002 09:14:23 -0800 Received: from Hermes.suse.de (Hermes.suse.de [213.95.15.136]) by Cantor.suse.de (Postfix) with ESMTP id 83D8E1E2E3; Thu, 31 Jan 2002 17:14:15 +0100 (MET) Date: Thu, 31 Jan 2002 17:14:15 +0100 From: Andi Kleen To: "David S. Miller" Cc: kaos@sgi.com, a.gruenbacher@computer.org, linux-xfs@oss.sgi.com Subject: Re: extended attributes interface Message-ID: <20020131171415.A22647@wotan.suse.de> References: <20020130.144647.21928212.davem@redhat.com> <5366.1012432255@kao2.melbourne.sgi.com> <20020130.151217.102576862.davem@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20020130.151217.102576862.davem@redhat.com> User-Agent: Mutt/1.3.22.1i Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 481 Lines: 16 On Wed, Jan 30, 2002 at 03:12:17PM -0800, David S. Miller wrote: > From: Keith Owens > Date: Thu, 31 Jan 2002 10:10:55 +1100 > > Sparc64 and mips64 are a problem as long as the kernel is 64 bit and > userspace is 32 bit. > > Read this as: forever. Because we have several years worth of users > with 32-bit userland distributions on at least sparc64. The x86-64 project will maintain/extend it "forever" at least if nobody else will do. -Andi From owner-linux-xfs@oss.sgi.com Thu Jan 31 11:37:30 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0VJbUG02704 for linux-xfs-outgoing; Thu, 31 Jan 2002 11:37:30 -0800 Received: from atlrel6.hp.com (atlrel6.hp.com [156.153.255.205]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0VJbId02682 for ; Thu, 31 Jan 2002 11:37:19 -0800 Received: from xatlrelay2.atl.hp.com (xatlrelay2.atl.hp.com [15.45.89.191]) by atlrel6.hp.com (Postfix) with ESMTP id AF098909 for ; Thu, 31 Jan 2002 12:59:05 -0500 (EST) Received: from xatlbh4.atl.hp.com (xatlbh4.atl.hp.com [15.45.89.189]) by xatlrelay2.atl.hp.com (Postfix) with ESMTP id A49A840009A for ; Thu, 31 Jan 2002 12:59:05 -0500 (EST) Received: by xatlbh4.atl.hp.com with Internet Mail Service (5.5.2653.19) id ; Thu, 31 Jan 2002 12:59:05 -0500 Message-ID: From: "HABBINGA,ERIK (HP-Loveland,ex1)" To: "'linux-xfs@oss.sgi.com'" Subject: nfsd lockups with xfs during SPEC SFS testing Date: Thu, 31 Jan 2002 12:59:03 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 3620 Lines: 91 I'm running linux 2.4.17 with a version of XFS downloaded via CVS on Jan 30th. When I run the SPEC SFS NFS test against this kernel, nfsd stops responding after awhile. I captured the state of all of the system processes via magic sysrq, and found 24 nfsd processes locked up in various stages of the nfsd_lookup code: - 20 of them were locked up in the fh_lock call before lookup_one_len in nfsd_lookup(). - 2 processes were locked up in the _pagebuf_grab_lock call inside _pagebuf_find_lockable_buffer(). - 2 processes were locked up in the pagebuf_iowait() call in pagebuf_iostart() Any ideas on what may be wrong, and how I can help debug and solve this problem? I've attached the call traces for the locked up nfsd processes. I can provide vmlinux and System.map for this kernel to help debugging. Thanks, Erik Habbinga Hewlett Packard nfsd processes locked up in nfsd_lookup()->fh_lock() task: nfsd c0105ab4: c0105a48 T __down c0105c50: c0105c48 T __down_failed c02c9bab: c02c6214 T stext_lock c0168048: c0167f74 t nfsd3_proc_lookup c015fa13: c015f940 t nfsd_dispatch c02bd775: c02bd4e8 T svc_process c015f80f: c015f618 t nfsd c0105594: c010556c T kernel_thread nfsd processes locked up in _pagebuf_find_lockable_buffer()->_pagebuf_grab_lock call() task: nfsd c0105ab4: c0105a48 T __down c0105c50: c0105c48 T __down_failed c02ca95c: c02c6214 T stext_lock c01db8e6: c01db7e4 T _pagebuf_find_lockable_buffer c01e5d92: c01e5d58 T kmem_zone_alloc c01a7545: c01a7510 t xfs_dir2_block_lookup_int c01a7545: c01a7510 t xfs_dir2_block_lookup_int c01dba19: c01db9e4 T _pagebuf_get_lockable_buffer c01d829f: c01d8268 T pagebuf_get c01cc374: c01cc338 T xfs_trans_read_buf c01b9078: c01b8f78 T xfs_itobp c01ba0cc: c01ba05c T xfs_iread c01b80c2: c01b7ebc T xfs_iget_core c0147ebe: c0147df0 T icreate c01b8488: c01b8404 T xfs_iget c01cd61c: c01cd4f8 T xfs_dir_lookup_int c01d1c07: c01d1b78 t xfs_lookup c01df729: c01df6c4 T linvfs_lookup c013df41: c013dea8 T lookup_hash c013dfd7: c013df80 T lookup_one_len c016263d: c0162370 T nfsd_lookup c0168048: c0167f74 t nfsd3_proc_lookup c015fa13: c015f940 t nfsd_dispatch c02bd775: c02bd4e8 T svc_process c015f80f: c015f618 t nfsd c0105594: c010556c T kernel_thread 0xc02ca95c : jmp 0xc01db7e1 <_pagebuf_grab_lock+17> nfsd processes locked up in pagebuf_iostart()->pagebuf_iowait() task: nfsd c0105ab4: c0105a48 T __down c0105c50: c0105c48 T __down_failed c02ca8b3: c02c6214 T stext_lock c01d88cd: c01d8844 T pagebuf_iostart c01d830d: c01d8268 T pagebuf_get c01cc374: c01cc338 T xfs_trans_read_buf c01b9078: c01b8f78 T xfs_itobp c01ba0cc: c01ba05c T xfs_iread c01b80c2: c01b7ebc T xfs_iget_core c0147ebe: c0147df0 T icreate c01b8488: c01b8404 T xfs_iget c01cd61c: c01cd4f8 T xfs_dir_lookup_int c01d1c07: c01d1b78 t xfs_lookup c01df729: c01df6c4 T linvfs_lookup c013df41: c013dea8 T lookup_hash c013dfd7: c013df80 T lookup_one_len c016263d: c0162370 T nfsd_lookup c0168048: c0167f74 t nfsd3_proc_lookup c015fa13: c015f940 t nfsd_dispatch c02bd775: c02bd4e8 T svc_process c015f80f: c015f618 t nfsd c0105594: c010556c T kernel_thread 0xc02ca8b3 : jmp 0xc01d9109 From owner-linux-xfs@oss.sgi.com Thu Jan 31 11:38:12 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0VJcC802742 for linux-xfs-outgoing; Thu, 31 Jan 2002 11:38:12 -0800 Received: from sgi.com (sgi-too.SGI.COM [204.94.211.39]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0VJc9d02719 for ; Thu, 31 Jan 2002 11:38:09 -0800 Received: from zeus-e8.americas.sgi.com (zeus-e8.americas.sgi.com [128.162.8.103]) by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id KAA02045 for ; Thu, 31 Jan 2002 10:37:00 -0800 (PST) mail_from (sandeen@sgi.com) Received: from poppy-e185.americas.sgi.com (poppy-e185.americas.sgi.com [128.162.185.207]) by zeus-e8.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id MAA25830 for ; Thu, 31 Jan 2002 12:36:51 -0600 (CST) Received: from stout.americas.sgi.com (stout.americas.sgi.com [128.162.187.5]) by poppy-e185.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.7) with ESMTP id MAA59883 for ; Thu, 31 Jan 2002 12:36:50 -0600 (CST) Subject: [Announce] Updated XFS 1.0.2 kernel RPMs for Red Hat systems From: Eric Sandeen To: linux-xfs@oss.sgi.com Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/1.0 (Preview Release) Date: 31 Jan 2002 12:36:50 -0600 Message-Id: <1012502210.21398.22.camel@stout.americas.sgi.com> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 532 Lines: 16 Thanks to Simon Matter, XFS-capable versions of Red Hat's latest x86 kernel RPMs are available at ftp://oss.sgi.com/projects/xfs/download/Release-1.0.2/kernel_rpms/i386/contributed-RH-updates/ These updated kernels contain exactly the same XFS bits as the original 1.0.2 release - only the underlying kernel has been updated. These are contributed RPMs; They have been sanity-checked, but not rigorously tested, by SGI. -Eric -- Eric Sandeen XFS for Linux http://oss.sgi.com/projects/xfs sandeen@sgi.com SGI, Inc. From owner-linux-xfs@oss.sgi.com Thu Jan 31 11:58:25 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0VJwPx03426 for linux-xfs-outgoing; Thu, 31 Jan 2002 11:58:25 -0800 Received: from mailout10.sul.t-online.com (mailout10.sul.t-online.com [194.25.134.21]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0VJwLd03403 for ; Thu, 31 Jan 2002 11:58:21 -0800 Received: from fwd00.sul.t-online.de by mailout10.sul.t-online.com with smtp id 16WMPX-0006Lr-0C; Thu, 31 Jan 2002 19:58:15 +0100 Received: from Deimos (520094219231-0001@[217.86.168.16]) by fmrl00.sul.t-online.com with esmtp id 16WMPT-2FL7WSC; Thu, 31 Jan 2002 19:58:11 +0100 Received: by triffnix.de via sendmail from stdin id (Debian Smail3.2.0.111) for linux-xfs@oss.sgi.com; Thu, 31 Jan 2002 19:58:02 +0100 (CET) Message-ID: X-Mailer: XFMail 1.4.7p2 on Linux X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: <3C58FAB9.D940E9B8@ch.sauter-bc.com> Date: Thu, 31 Jan 2002 19:58:02 +0100 (CET) From: unruh@acm.org To: Simon Matter Subject: Re: xfsrestore fails: assertion failure in do_next_mark Cc: linux-xfs@oss.sgi.com X-Sender: 520094219231-0001@t-dialin.net Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 807 Lines: 24 On 31-Jan-2002 Simon Matter wrote: > IIRC I got the same error some months ago when trying to restore from a > DDS2 DAT drive. On the same system restoring from DLT was okay. I didn't > try again but I guess this bug is still not fixed :-( After some reading of the mailing list archives, I added the following at line 1481 in drive_scsitape.c (version 1.5): rechdrp->first_mark_offset = INT_GET(rechdrp->first_mark_offset,ARCH_CONVERT); The patched xfsrestore can read the damaged backup, but will probably be unable to read backups from newer versions of xfsdump. -------------------------------------- Daniel Unruh unruh@acm.org http://www.freiburg.linux.de/~unruh/ -------------------------------------- "We are the most ripped-off company around..." - Bill Gates, 1980 From owner-linux-xfs@oss.sgi.com Thu Jan 31 12:03:36 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0VK3ao03706 for linux-xfs-outgoing; Thu, 31 Jan 2002 12:03:36 -0800 Received: from yog-sothoth.sgi.com (eugate.sgi.com [192.48.160.10]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0VK3Vd03683 for ; Thu, 31 Jan 2002 12:03:31 -0800 Received: from zeus-e8.americas.sgi.com (zeus-e8.americas.sgi.com [128.162.8.103]) by yog-sothoth.sgi.com (980305.SGI.8.8.8-aspam-6.2/980304.SGI-aspam-europe) via ESMTP id UAA190744 for ; Thu, 31 Jan 2002 20:02:21 +0100 (CET) mail_from (lord@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by zeus-e8.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id NAA26308; Thu, 31 Jan 2002 13:02:10 -0600 (CST) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id NAA55717; Thu, 31 Jan 2002 13:02:10 -0600 (CST) Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id g0VIxrO05411; Thu, 31 Jan 2002 12:59:53 -0600 Subject: Re: xfsrestore fails: assertion failure in do_next_mark From: Steve Lord To: unruh@acm.org Cc: Simon Matter , linux-xfs@oss.sgi.com In-Reply-To: References: Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/1.0.2 Date: 31 Jan 2002 12:59:53 -0600 Message-Id: <1012503593.26397.164.camel@jen.americas.sgi.com> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 995 Lines: 30 On Thu, 2002-01-31 at 12:58, unruh@acm.org wrote: > On 31-Jan-2002 Simon Matter wrote: > > > IIRC I got the same error some months ago when trying to restore from a > > DDS2 DAT drive. On the same system restoring from DLT was okay. I didn't > > try again but I guess this bug is still not fixed :-( > > After some reading of the mailing list archives, I added the following at > line 1481 in drive_scsitape.c (version 1.5): > > rechdrp->first_mark_offset = > INT_GET(rechdrp->first_mark_offset,ARCH_CONVERT); > > > The patched xfsrestore can read the damaged backup, but will probably be unable > to read backups from newer versions of xfsdump. > I think, (but do not know since he is in Australia) that our dump/restore expert is out on vacation right now, so you may have to wait a while for a response on this one. Steve -- Steve Lord voice: +1-651-683-3511 Principal Engineer, Filesystem Software email: lord@sgi.com From owner-linux-xfs@oss.sgi.com Thu Jan 31 12:18:44 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0VKIiC04184 for linux-xfs-outgoing; Thu, 31 Jan 2002 12:18:44 -0800 Received: from mailb.hrz.uni-siegen.de (mailb.hrz.uni-siegen.de [141.99.11.2]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0VKIfd04157 for ; Thu, 31 Jan 2002 12:18:41 -0800 Received: by mailb.hrz.Uni-Siegen.DE with Internet Mail Service (5.5.2653.19) id ; Thu, 31 Jan 2002 20:21:52 +0100 Message-ID: <20020131201829.798ef3e1.Dominik.Thinay@unix-ag.org> From: Dominik.Thinay@unix-ag.org To: linux-xfs@oss.sgi.com Subject: Filesystem Corruption on cvs kernel 2.4.17-xfs ? Date: Thu, 31 Jan 2002 20:18:29 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id g0VKIfd04159 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 335 Lines: 12 ls -la |more ls: FRESH - Sex With ér Ex (Original Mix).MP3: No such file or directory ls: kov cs nagyember l szl¢ - the mix 2000.mp3: No such file or directory ls: MISS JANE - Lalal  (Extended Mix).MP3: No such file or directory ls |grep MISS MISS JANE - Lalal  (Extended Mix).MP3 xfs_repair reports no errors :( regards dominik From owner-linux-xfs@oss.sgi.com Thu Jan 31 12:28:34 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0VKSY404550 for linux-xfs-outgoing; Thu, 31 Jan 2002 12:28:34 -0800 Received: from zok.sgi.com (zok.SGI.COM [204.94.215.101]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0VKSUd04521 for ; Thu, 31 Jan 2002 12:28:30 -0800 Received: from zeus-e8.americas.sgi.com (zeus-e8.americas.sgi.com [128.162.8.103]) by zok.sgi.com (8.11.4/8.11.4/linux-outbound_gateway-1.1) with ESMTP id g0VJSLo01116 for ; Thu, 31 Jan 2002 11:28:21 -0800 Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by zeus-e8.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id NAA26823; Thu, 31 Jan 2002 13:27:04 -0600 (CST) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id NAA78899; Thu, 31 Jan 2002 13:27:04 -0600 (CST) Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id g0VJOl606089; Thu, 31 Jan 2002 13:24:47 -0600 Subject: Re: Filesystem Corruption on cvs kernel 2.4.17-xfs ? From: Steve Lord To: Dominik.Thinay@unix-ag.org Cc: linux-xfs@oss.sgi.com In-Reply-To: <20020131201829.798ef3e1.Dominik.Thinay@unix-ag.org> References: <20020131201829.798ef3e1.Dominik.Thinay@unix-ag.org> Content-Type: text/plain; charset=ISO-8859-1 X-Mailer: Evolution/1.0.2 Date: 31 Jan 2002 13:24:47 -0600 Message-Id: <1012505087.26396.174.camel@jen.americas.sgi.com> Mime-Version: 1.0 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id g0VKSUd04522 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 704 Lines: 23 On Thu, 2002-01-31 at 13:18, Dominik.Thinay@unix-ag.org wrote: > ls -la |more > ls: FRESH - Sex With ér Ex (Original Mix).MP3: No such file or directory > ls: kov cs nagyember l szl¢ - the mix 2000.mp3: No such file or directory > ls: MISS JANE - Lalal (Extended Mix).MP3: No such file or directory > > ls |grep MISS > MISS JANE - Lalal (Extended Mix).MP3 > > xfs_repair reports no errors :( > > regards dominik I think you got bitten by the removal of the -f unsigned-char in the xfs makefiles, try a new cvs kernel and it should work again. Steve -- Steve Lord voice: +1-651-683-3511 Principal Engineer, Filesystem Software email: lord@sgi.com From owner-linux-xfs@oss.sgi.com Thu Jan 31 12:28:43 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0VKShw04666 for linux-xfs-outgoing; Thu, 31 Jan 2002 12:28:43 -0800 Received: from zok.sgi.com (zok.SGI.COM [204.94.215.101]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0VKSdd04604 for ; Thu, 31 Jan 2002 12:28:39 -0800 Received: from zeus-e8.americas.sgi.com (zeus-e8.americas.sgi.com [128.162.8.103]) by zok.sgi.com (8.11.4/8.11.4/linux-outbound_gateway-1.1) with ESMTP id g0VJSUo01154 for ; Thu, 31 Jan 2002 11:28:30 -0800 Received: from poppy-e185.americas.sgi.com (poppy-e185.americas.sgi.com [128.162.185.207]) by zeus-e8.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id NAA26642; Thu, 31 Jan 2002 13:27:14 -0600 (CST) Received: from stout.americas.sgi.com (stout.americas.sgi.com [128.162.187.5]) by poppy-e185.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.7) with ESMTP id NAA61498; Thu, 31 Jan 2002 13:27:14 -0600 (CST) Subject: Re: Filesystem Corruption on cvs kernel 2.4.17-xfs ? From: Eric Sandeen To: Dominik.Thinay@unix-ag.org Cc: linux-xfs@oss.sgi.com In-Reply-To: <20020131201829.798ef3e1.Dominik.Thinay@unix-ag.org> References: <20020131201829.798ef3e1.Dominik.Thinay@unix-ag.org> Content-Type: text/plain; charset=ISO-8859-1 X-Mailer: Evolution/1.0 (Preview Release) Date: 31 Jan 2002 13:27:14 -0600 Message-Id: <1012505234.21399.24.camel@stout.americas.sgi.com> Mime-Version: 1.0 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id g0VKSdd04605 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 724 Lines: 23 Looks like you did a cvs checkout when the -funsigned-char was temporarily removed; the characters "é" and "¢" are causing problems. For starters, get a newer cvs checkout and see how things go. -Eric On Thu, 2002-01-31 at 13:18, Dominik.Thinay@unix-ag.org wrote: > ls -la |more > ls: FRESH - Sex With ér Ex (Original Mix).MP3: No such file or directory > ls: kov cs nagyember l szl¢ - the mix 2000.mp3: No such file or directory > ls: MISS JANE - Lalal (Extended Mix).MP3: No such file or directory > > ls |grep MISS > MISS JANE - Lalal (Extended Mix).MP3 > > xfs_repair reports no errors :( > > regards dominik -- Eric Sandeen XFS for Linux http://oss.sgi.com/projects/xfs sandeen@sgi.com SGI, Inc. From owner-linux-xfs@oss.sgi.com Thu Jan 31 13:49:08 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0VLn8Y09901 for linux-xfs-outgoing; Thu, 31 Jan 2002 13:49:08 -0800 Received: from imf15bis.bellsouth.net (mail315.mail.bellsouth.net [205.152.58.175]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0VLn4d09879 for ; Thu, 31 Jan 2002 13:49:04 -0800 Received: from bellsouth.net ([65.80.92.251]) by imf15bis.bellsouth.net (InterMail vM.5.01.04.00 201-253-122-122-20010827) with ESMTP id <20020131205013.HSRJ12767.imf15bis.bellsouth.net@bellsouth.net> for ; Thu, 31 Jan 2002 15:50:13 -0500 Message-ID: <3C59AE0F.62BAD274@bellsouth.net> Date: Thu, 31 Jan 2002 15:50:23 -0500 From: Jeff Layton X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.4.17 i686) X-Accept-Language: en MIME-Version: 1.0 To: linux-xfs@oss.sgi.com Subject: Newbie Patch/CVS question Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 681 Lines: 21 Hello, I'm sorry about the newbie question, but I don't have any experience with using CVS and creating patches. What I want to do is download the latest XFS for 2.4 from CVS. I managed to do that just fine, resulting in a massive directory called linux-2.4-xfs. If I want to create a patch file from this directory versus, say, linux-2.4.17, what diff options do I use? (I experimented with some, searched on google fairly quickly, and punted to this mailing-list when I didn't have any luck). After I get the patch I know what to do (some friends with even less experience than me want the latest patch from the CVS and sort of appointed me to do it :). TIA, Jeff From owner-linux-xfs@oss.sgi.com Thu Jan 31 13:53:12 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0VLrCg10078 for linux-xfs-outgoing; Thu, 31 Jan 2002 13:53:12 -0800 Received: from smtpzilla2.xs4all.nl (smtpzilla2.xs4all.nl [194.109.127.138]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0VLr7d10056 for ; Thu, 31 Jan 2002 13:53:08 -0800 Received: from auto-nb1.xs4all.nl (213-84-100-130.adsl.xs4all.nl [213.84.100.130]) by smtpzilla2.xs4all.nl (8.12.0/8.12.0) with ESMTP id g0VKr0hX031982; Thu, 31 Jan 2002 21:53:00 +0100 (CET) Message-Id: <4.3.2.7.2.20020131215034.035273e0@pop.xs4all.nl> X-Sender: knuffie@pop.xs4all.nl X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 31 Jan 2002 21:51:25 +0100 To: Jeff Layton , linux-xfs@oss.sgi.com From: Seth Mos Subject: Re: Newbie Patch/CVS question In-Reply-To: <3C59AE0F.62BAD274@bellsouth.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 978 Lines: 28 At 15:50 31-1-2002 -0500, Jeff Layton wrote: >Hello, > > I'm sorry about the newbie question, but I don't have >any experience with using CVS and creating patches. > What I want to do is download the latest XFS for 2.4 >from CVS. I managed to do that just fine, resulting in >a massive directory called linux-2.4-xfs. If I want to >create a patch file from this directory versus, say, >linux-2.4.17, what diff options do I use? (I experimented >with some, searched on google fairly quickly, and >punted to this mailing-list when I didn't have any luck). > After I get the patch I know what to do (some friends >with even less experience than me want the latest >patch from the CVS and sort of appointed me to do it :). diff -urN is good one but you will need to get rid off the CVS dirs as well. See the -X option off the diff manpage. Cheers -- Seth Every program has two purposes one for which it was written and another for which it wasn't I use the last kind. From owner-linux-xfs@oss.sgi.com Thu Jan 31 13:54:42 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0VLsgV10213 for linux-xfs-outgoing; Thu, 31 Jan 2002 13:54:42 -0800 Received: from sgi.com (sgi-too.SGI.COM [204.94.211.39]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0VLsdd10189 for ; Thu, 31 Jan 2002 13:54:39 -0800 Received: from zeus-e8.americas.sgi.com (zeus-e8.americas.sgi.com [128.162.8.103]) by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id MAA04894 for ; Thu, 31 Jan 2002 12:54:35 -0800 (PST) mail_from (sandeen@sgi.com) Received: from poppy-e185.americas.sgi.com (poppy-e185.americas.sgi.com [128.162.185.207]) by zeus-e8.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id OAA28076; Thu, 31 Jan 2002 14:53:19 -0600 (CST) Received: from stout.americas.sgi.com (stout.americas.sgi.com [128.162.187.5]) by poppy-e185.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.7) with ESMTP id OAA58146; Thu, 31 Jan 2002 14:53:19 -0600 (CST) Subject: Re: Newbie Patch/CVS question From: Eric Sandeen To: Jeff Layton Cc: linux-xfs@oss.sgi.com In-Reply-To: <3C59AE0F.62BAD274@bellsouth.net> References: <3C59AE0F.62BAD274@bellsouth.net> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/1.0 (Preview Release) Date: 31 Jan 2002 14:53:19 -0600 Message-Id: <1012510399.20433.37.camel@stout.americas.sgi.com> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 645 Lines: 21 On Thu, 2002-01-31 at 14:50, Jeff Layton wrote: > What I want to do is download the latest XFS for 2.4 > from CVS. I managed to do that just fine, resulting in > a massive directory called linux-2.4-xfs. If I want to > create a patch file from this directory versus, say, > linux-2.4.17, what diff options do I use? diff -Nur /path/to/vanilla/linux /path/to/cvs/linux-2.4.x-xfs/linux (obviously replacing paths correctly, above...) OTOH, there are ready-made patches on ftp://oss.sgi.com/projects/xfs/download/patches/2.4.17... -Eric -- Eric Sandeen XFS for Linux http://oss.sgi.com/projects/xfs sandeen@sgi.com SGI, Inc. From owner-linux-xfs@oss.sgi.com Thu Jan 31 14:00:42 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0VM0gi10508 for linux-xfs-outgoing; Thu, 31 Jan 2002 14:00:42 -0800 Received: from zok.sgi.com (zok.SGI.COM [204.94.215.101]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0VM0dd10477 for ; Thu, 31 Jan 2002 14:00:39 -0800 Received: from zeus-e8.americas.sgi.com (zeus-e8.americas.sgi.com [128.162.8.103]) by zok.sgi.com (8.11.4/8.11.4/linux-outbound_gateway-1.1) with ESMTP id g0VL0Wo10447 for ; Thu, 31 Jan 2002 13:00:32 -0800 Received: from poppy-e185.americas.sgi.com (poppy-e185.americas.sgi.com [128.162.185.207]) by zeus-e8.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id OAA28101; Thu, 31 Jan 2002 14:59:16 -0600 (CST) Received: from stout.americas.sgi.com (stout.americas.sgi.com [128.162.187.5]) by poppy-e185.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.7) with ESMTP id OAA65726; Thu, 31 Jan 2002 14:59:16 -0600 (CST) Subject: Re: Newbie Patch/CVS question From: Eric Sandeen To: Seth Mos Cc: Jeff Layton , linux-xfs@oss.sgi.com In-Reply-To: <4.3.2.7.2.20020131215034.035273e0@pop.xs4all.nl> References: <4.3.2.7.2.20020131215034.035273e0@pop.xs4all.nl> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/1.0 (Preview Release) Date: 31 Jan 2002 14:59:15 -0600 Message-Id: <1012510756.21398.39.camel@stout.americas.sgi.com> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 280 Lines: 14 On Thu, 2002-01-31 at 14:51, Seth Mos wrote: > diff -urN is good one but you will need to get rid off the CVS dirs as well. Oh right... add "--exclude=CVS" or "-x CVS" -Eric -- Eric Sandeen XFS for Linux http://oss.sgi.com/projects/xfs sandeen@sgi.com SGI, Inc. From owner-linux-xfs@oss.sgi.com Thu Jan 31 14:21:25 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0VMLPk10977 for linux-xfs-outgoing; Thu, 31 Jan 2002 14:21:25 -0800 Received: from imf18bis.bellsouth.net (mail118.mail.bellsouth.net [205.152.58.58]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0VMLKd10955 for ; Thu, 31 Jan 2002 14:21:20 -0800 Received: from bellsouth.net ([65.80.92.251]) by imf18bis.bellsouth.net (InterMail vM.5.01.04.00 201-253-122-122-20010827) with ESMTP id <20020131212230.UDGT23623.imf18bis.bellsouth.net@bellsouth.net> for ; Thu, 31 Jan 2002 16:22:30 -0500 Message-ID: <3C59B59F.88298482@bellsouth.net> Date: Thu, 31 Jan 2002 16:22:39 -0500 From: Jeff Layton X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.4.17 i686) X-Accept-Language: en MIME-Version: 1.0 To: linux-xfs@oss.sgi.com Subject: Re: Newbie Patch/CVS question References: <4.3.2.7.2.20020131215034.035273e0@pop.xs4all.nl> <1012510756.21398.39.camel@stout.americas.sgi.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 618 Lines: 34 Eric Sandeen wrote: > On Thu, 2002-01-31 at 14:51, Seth Mos wrote: > > > diff -urN is good one but you will need to get rid off the CVS dirs as well. > > Oh right... > > add "--exclude=CVS" or "-x CVS" OK, here's what I did: (1) got CVS directory following instructions on web page (2) made a patch with diff using the following: diff -urN --exclude=CVS /usr/src/linux-2.4.17/ /usr/src/linux-2.4-xfs/linux/ > /tmp/patch BINGO - fresh patch! Very nice. Thanks for the help everyone! Jeff > > > -Eric > > -- > Eric Sandeen XFS for Linux http://oss.sgi.com/projects/xfs > sandeen@sgi.com SGI, Inc. From owner-linux-xfs@oss.sgi.com Thu Jan 31 14:46:14 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0VMkEO11414 for linux-xfs-outgoing; Thu, 31 Jan 2002 14:46:14 -0800 Received: from deliverator.sgi.com (deliverator.sgi.com [204.94.214.10]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0VMkBd11392 for ; Thu, 31 Jan 2002 14:46:11 -0800 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via SMTP id NAA00531 for ; Thu, 31 Jan 2002 13:41:44 -0800 (PST) mail_from (nathans@wobbly.melbourne.sgi.com) Received: from wobbly.melbourne.sgi.com (wobbly.melbourne.sgi.com [134.14.55.135]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id IAA25058; Fri, 1 Feb 2002 08:44:50 +1100 Received: (from nathans@localhost) by wobbly.melbourne.sgi.com (SGI-8.9.3/8.9.3) id IAA88555; Fri, 1 Feb 2002 08:44:49 +1100 (AEDT) Date: Fri, 1 Feb 2002 08:44:49 +1100 From: Nathan Scott To: Steve Lord Cc: unruh@acm.org, Simon Matter , linux-xfs@oss.sgi.com Subject: Re: xfsrestore fails: assertion failure in do_next_mark Message-ID: <20020201084449.A88469@wobbly.melbourne.sgi.com> References: <1012503593.26397.164.camel@jen.americas.sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <1012503593.26397.164.camel@jen.americas.sgi.com>; from lord@sgi.com on Thu, Jan 31, 2002 at 12:59:53PM -0600 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 360 Lines: 15 On Thu, Jan 31, 2002 at 12:59:53PM -0600, Steve Lord wrote: > > I think, (but do not know since he is in Australia) that our dump/restore > expert is out on vacation right now, so you may have to wait a while for > a response on this one. > Tim is busy coming to grips with being a dad at the moment, he's expected back mid-February. cheers. -- Nathan From owner-linux-xfs@oss.sgi.com Thu Jan 31 15:04:47 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0VN4ls11920 for linux-xfs-outgoing; Thu, 31 Jan 2002 15:04:47 -0800 Received: from gum.csee.uq.edu.au (gum.csee.uq.edu.au [130.102.66.1]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0VN4dd11898 for ; Thu, 31 Jan 2002 15:04:40 -0800 Received: from nut.csee.uq.edu.au (nut.csee.uq.edu.au [130.102.66.13]) by gum.csee.uq.edu.au (8.11.6/8.11.6) with ESMTP id g0VM4XH03590 for ; Fri, 1 Feb 2002 08:04:33 +1000 (EST) Received: from mango.csee.uq.edu.au (mango.csee.uq.edu.au [130.102.66.4]) by nut.csee.uq.edu.au (8.11.6/8.11.6) with ESMTP id g0VM4W401669 for ; Fri, 1 Feb 2002 08:04:32 +1000 (EST) Date: Fri, 1 Feb 2002 08:04:32 +1000 (EST) From: Chris Pascoe X-X-Sender: chrisp@mango.csee.uq.edu.au To: linux-xfs@oss.sgi.com Subject: Re: How long should an xfs_freeze take? Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Scanned-By: MIMEDefang 1.3 (www dot roaringpenguin dot com slash mimedefang) Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 1755 Lines: 51 Hi Steve, > > How repeatable is this? > > > > The problem was persistent across reboots - I rebooted to install a > > different LVM version at some stage (move to 1.0.2, from 1.0.1), and it > > occurred five times in a row after that. I just rebooted now to say that it > > still happens - but, alas - it doesn't want to any more. I'll try again at > > some random times throughout the day. I can repeat this fairly reliably now - do a meaningless rsync across the disk (i.e. rsync itself to itself - makes it stat every file on the disk, I guess), then try an xfs_freeze after the rsync completes: rsync -aH /tst1/ /tst1/ time xfs_freeze -f /tst1 It's been hung there for ~10 minutes now, I've repeated this twice.... rebooting - will try again... This time it doesn't want to do it.. :( This time I've done a rsync with real data: testbox# time rsync -e ssh -avH --stats root@fs:/home/01/ /tst1/ ; time xfs_freeze -f /tst1 ; time xfs_freeze -u /tst1 Number of files: 602545 Number of files transferred: 292 Total file size: 62690390294 bytes Total transferred file size: 1728372390 bytes Literal data: 177119547 bytes Matched data: 1551577350 bytes File list size: 15575582 Total bytes written: 4690480 Total bytes read: 195767044 wrote 4690480 bytes read 195767044 bytes 100808.41 bytes/sec total size is 62690390294 speedup is 312.74 real 33m7.243s user 1m34.200s sys 2m8.250s I'm sitting waiting for the xfs_freeze again - so I can replicate the problem, yes. It takes at least 40 minutes to complete xfs_freeze's after this point (i.e. you can go xfs_freeze -f ; xfs_freeze -u ; xfs_freeze -f ; xfs_freeze -u, and the second freeze still takes forever!), during which time the machine is completely unresponsive. Chris From owner-linux-xfs@oss.sgi.com Thu Jan 31 15:10:56 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0VNAuP12153 for linux-xfs-outgoing; Thu, 31 Jan 2002 15:10:56 -0800 Received: from yog-sothoth.sgi.com (eugate.sgi.com [192.48.160.10]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0VNAld12131 for ; Thu, 31 Jan 2002 15:10:48 -0800 Received: from zeus-e8.americas.sgi.com (zeus-e8.americas.sgi.com [128.162.8.103]) by yog-sothoth.sgi.com (980305.SGI.8.8.8-aspam-6.2/980304.SGI-aspam-europe) via ESMTP id XAA193416 for ; Thu, 31 Jan 2002 23:10:49 +0100 (CET) mail_from (lord@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by zeus-e8.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id QAA29255; Thu, 31 Jan 2002 16:09:26 -0600 (CST) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id QAA22274; Thu, 31 Jan 2002 16:09:26 -0600 (CST) Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id g0VM77911103; Thu, 31 Jan 2002 16:07:07 -0600 Subject: Re: How long should an xfs_freeze take? From: Steve Lord To: Chris Pascoe Cc: linux-xfs@oss.sgi.com In-Reply-To: References: Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/1.0.2 Date: 31 Jan 2002 16:07:07 -0600 Message-Id: <1012514827.26397.257.camel@jen.americas.sgi.com> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 2098 Lines: 61 On Thu, 2002-01-31 at 16:04, Chris Pascoe wrote: > Hi Steve, > > > > How repeatable is this? > > > > > > The problem was persistent across reboots - I rebooted to install a > > > different LVM version at some stage (move to 1.0.2, from 1.0.1), and it > > > occurred five times in a row after that. I just rebooted now to say > that it > > > still happens - but, alas - it doesn't want to any more. I'll try again > at > > > some random times throughout the day. > > I can repeat this fairly reliably now - do a meaningless rsync across the > disk (i.e. rsync itself to itself - makes it stat every file on the disk, I > guess), then try an xfs_freeze after the rsync completes: > > rsync -aH /tst1/ /tst1/ > time xfs_freeze -f /tst1 > > It's been hung there for ~10 minutes now, I've repeated this twice.... > rebooting - will try again... This time it doesn't want to do it.. :( > > This time I've done a rsync with real data: > > testbox# time rsync -e ssh -avH --stats root@fs:/home/01/ /tst1/ ; time xfs_freeze -f /tst1 ; time xfs_freeze -u /tst1 > > Number of files: 602545 > Number of files transferred: 292 > Total file size: 62690390294 bytes > Total transferred file size: 1728372390 bytes > Literal data: 177119547 bytes > Matched data: 1551577350 bytes > File list size: 15575582 > Total bytes written: 4690480 > Total bytes read: 195767044 > > wrote 4690480 bytes read 195767044 bytes 100808.41 bytes/sec > total size is 62690390294 speedup is 312.74 > > real 33m7.243s > user 1m34.200s > sys 2m8.250s > > I'm sitting waiting for the xfs_freeze again - so I can replicate > the problem, yes. It takes at least 40 minutes to complete xfs_freeze's > after this point (i.e. you can go xfs_freeze -f ; xfs_freeze -u ; > xfs_freeze -f ; xfs_freeze -u, and the second freeze still takes > forever!), during which time the machine is completely unresponsive. > > Chris We are looking - or at least Eric is.... Steve -- Steve Lord voice: +1-651-683-3511 Principal Engineer, Filesystem Software email: lord@sgi.com From owner-linux-xfs@oss.sgi.com Thu Jan 31 15:13:01 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0VND1p12302 for linux-xfs-outgoing; Thu, 31 Jan 2002 15:13:01 -0800 Received: from yog-sothoth.sgi.com (eugate.sgi.com [192.48.160.10]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0VNCud12278 for ; Thu, 31 Jan 2002 15:12:56 -0800 Received: from zeus-e8.americas.sgi.com (zeus-e8.americas.sgi.com [128.162.8.103]) by yog-sothoth.sgi.com (980305.SGI.8.8.8-aspam-6.2/980304.SGI-aspam-europe) via ESMTP id XAA210093 for ; Thu, 31 Jan 2002 23:12:57 +0100 (CET) mail_from (sandeen@sgi.com) Received: from poppy-e185.americas.sgi.com (poppy-e185.americas.sgi.com [128.162.185.207]) by zeus-e8.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id QAA25423; Thu, 31 Jan 2002 16:11:34 -0600 (CST) Received: from stout.americas.sgi.com (stout.americas.sgi.com [128.162.187.5]) by poppy-e185.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.7) with ESMTP id QAA75184; Thu, 31 Jan 2002 16:11:34 -0600 (CST) Subject: Re: How long should an xfs_freeze take? From: Eric Sandeen To: Chris Pascoe Cc: linux-xfs@oss.sgi.com In-Reply-To: References: Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/1.0 (Preview Release) Date: 31 Jan 2002 16:11:34 -0600 Message-Id: <1012515094.20484.41.camel@stout.americas.sgi.com> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 1109 Lines: 34 On Thu, 2002-01-31 at 16:04, Chris Pascoe wrote: > I can repeat this fairly reliably now - do a meaningless rsync across the > disk (i.e. rsync itself to itself - makes it stat every file on the disk, I > guess), then try an xfs_freeze after the rsync completes: > > rsync -aH /tst1/ /tst1/ > time xfs_freeze -f /tst1 > > It's been hung there for ~10 minutes now, I've repeated this twice.... > rebooting - will try again... This time it doesn't want to do it.. :( > > This time I've done a rsync with real data: > > testbox# time rsync -e ssh -avH --stats root@fs:/home/01/ /tst1/ ; time xfs_freeze -f /tst1 ; time xfs_freeze -u /tst1 > > Number of files: 602545 > Number of files transferred: 292 > Total file size: 62690390294 bytes Ok, so the device you're freezing has about 60G in about 600,000 files? And freeze only takes a very long time if you've poked at each file w/ rsync first? i.e. if you unmount, then remount, xfs_freeze happens quickly? (sorry if I'm being pedantic...) -Eric -- Eric Sandeen XFS for Linux http://oss.sgi.com/projects/xfs sandeen@sgi.com SGI, Inc. From owner-linux-xfs@oss.sgi.com Thu Jan 31 15:19:57 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0VNJvq12638 for linux-xfs-outgoing; Thu, 31 Jan 2002 15:19:57 -0800 Received: from rj.sgi.com (rj.sgi.com [204.94.215.100]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0VNJod12613 for ; Thu, 31 Jan 2002 15:19:50 -0800 Received: from zeus-e8.americas.sgi.com (zeus-e8.americas.sgi.com [128.162.8.103]) by rj.sgi.com (8.11.4/8.11.4/linux-outbound_gateway-1.1) with ESMTP id g0VMJeY15453 for ; Thu, 31 Jan 2002 14:19:40 -0800 Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by zeus-e8.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id QAA29362; Thu, 31 Jan 2002 16:18:24 -0600 (CST) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id QAA44982; Thu, 31 Jan 2002 16:18:24 -0600 (CST) Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id g0VMG6r13622; Thu, 31 Jan 2002 16:16:06 -0600 Subject: Re: nfsd lockups with xfs during SPEC SFS testing 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 X-Mailer: Evolution/1.0.2 Date: 31 Jan 2002 16:16:05 -0600 Message-Id: <1012515365.26363.274.camel@jen.americas.sgi.com> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 1159 Lines: 31 On Thu, 2002-01-31 at 11:59, HABBINGA,ERIK (HP-Loveland,ex1) wrote: > I'm running linux 2.4.17 with a version of XFS downloaded via CVS on Jan > 30th. When I run the SPEC SFS NFS test against this kernel, nfsd stops > responding after awhile. I captured the state of all of the system > processes via magic sysrq, and found 24 nfsd processes locked up in various > stages of the nfsd_lookup code: > > - 20 of them were locked up in the fh_lock call before lookup_one_len in > nfsd_lookup(). > - 2 processes were locked up in the _pagebuf_grab_lock call inside > _pagebuf_find_lockable_buffer(). > - 2 processes were locked up in the pagebuf_iowait() call in > pagebuf_iostart() > > Any ideas on what may be wrong, and how I can help debug and solve this > problem? I've attached the call traces for the locked up nfsd processes. I > can provide vmlinux and System.map for this kernel to help debugging. Is this a regression, i.e. did it used to work? And can you say when on the 30th? Thanks Steve -- Steve Lord voice: +1-651-683-3511 Principal Engineer, Filesystem Software email: lord@sgi.com From owner-linux-xfs@oss.sgi.com Thu Jan 31 15:53:49 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0VNrnd13456 for linux-xfs-outgoing; Thu, 31 Jan 2002 15:53:49 -0800 Received: from sgi.com (sgi-too.SGI.COM [204.94.211.39]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0VNrfd13434 for ; Thu, 31 Jan 2002 15:53:41 -0800 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via SMTP id OAA05125 for ; Thu, 31 Jan 2002 14:53:38 -0800 (PST) mail_from (nathans@wobbly.melbourne.sgi.com) Received: from wobbly.melbourne.sgi.com (wobbly.melbourne.sgi.com [134.14.55.135]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id JAA25483; Fri, 1 Feb 2002 09:52:19 +1100 Received: (from nathans@localhost) by wobbly.melbourne.sgi.com (SGI-8.9.3/8.9.3) id JAA83453; Fri, 1 Feb 2002 09:52:17 +1100 (AEDT) Date: Fri, 1 Feb 2002 09:52:17 +1100 From: Nathan Scott To: linux-xfs@oss.sgi.com Cc: Andreas Gruenbacher , Dominik Kubla Subject: [NEWS] Extended attributes interface changes Message-ID: <20020201095217.F88469@wobbly.melbourne.sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 1998 Lines: 44 Hi folks, As you may have heard, Linus has accepted the revised extended attributes interfaces which several projects have been working on during the past few months, including ours, into 2.5.3. >From an XFS development point of view, this is great news and will result in a significant decrease in the overlap which the XFS patches have with the rest of the kernel, and also means that we will no longer need to use unreserved system calls. Inclusion of XFS in certain distributions has been held up due to this, and once the transition to these interfaces is complete, I understand these will be able to proceed. We will also be able to converge on a single set of user tools for EAs and POSIX ACLs that other filesystems will be using as well (which is good news for Samba and any other upstream libacl.so users). >From an end-user point of view, we will need to make a transition from using our current system call interfaces for EAs and ACLs to the new interfaces. This affects both the kernel and a number of the userspace tools and libraries. We've considered attempting to keep compatibility with the existing interfaces too, but ultimately have discarded that option and will instead make a clean break from one interface to the other (this applies to both the 2.4.x kernels and the 2.5.x kernels). This means that with a future kernel merge we will also release new userspace packages (I expect to move all our packages up to version 2.0.0) and I also expect responsibility for the ACL package we use to be taken over by Andreas Gruenbacher - the author/maintainer of the [http://acl.bestbits.at/] ext2/ext3 ACL implementation - at some point in the not-too-distant-future. XFS 1.1 is scheduled for this quarter, I plan on having this all integrated for that release for those who track the official SGI releases rather than CVS or patches. Further details will follow later, this is just a heads-up that a significant interface change is in the pipeline. cheers. -- Nathan From owner-linux-xfs@oss.sgi.com Thu Jan 31 15:57:59 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0VNvxT13679 for linux-xfs-outgoing; Thu, 31 Jan 2002 15:57:59 -0800 Received: from mail.ocs.com.au (mail.ocs.com.au [203.34.97.2]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0VNvtd13656 for ; Thu, 31 Jan 2002 15:57:55 -0800 Received: (qmail 12376 invoked from network); 31 Jan 2002 22:57:50 -0000 Received: from ocs3.intra.ocs.com.au (192.168.255.3) by mail.ocs.com.au with SMTP; 31 Jan 2002 22:57:49 -0000 Received: by ocs3.intra.ocs.com.au (Postfix, from userid 16331) id 30C7C3000AD; Fri, 1 Feb 2002 09:57:48 +1100 (EST) Received: from ocs3.intra.ocs.com.au (localhost [127.0.0.1]) by ocs3.intra.ocs.com.au (Postfix) with ESMTP id 080CE8E; Fri, 1 Feb 2002 09:57:47 +1100 (EST) X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 From: Keith Owens To: Jeff Layton , linux-xfs@oss.sgi.com Subject: Re: Newbie Patch/CVS question In-reply-to: Your message of "31 Jan 2002 14:53:19 MDT." <1012510399.20433.37.camel@stout.americas.sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 01 Feb 2002 09:57:42 +1100 Message-ID: <18757.1012517862@ocs3.intra.ocs.com.au> Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 571 Lines: 13 On 31 Jan 2002 14:53:19 -0600, Eric Sandeen wrote: >On Thu, 2002-01-31 at 14:50, Jeff Layton wrote: >> What I want to do is download the latest XFS for 2.4 >> from CVS. I managed to do that just fine, resulting in >> a massive directory called linux-2.4-xfs. If I want to >> create a patch file from this directory versus, say, >> linux-2.4.17, what diff options do I use? >OTOH, there are ready-made patches on >ftp://oss.sgi.com/projects/xfs/download/patches/2.4.17... But not current with CVS. They are a snapshot as of 2002-01-23 04:32 UTC. From owner-linux-xfs@oss.sgi.com Thu Jan 31 16:08:18 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1108Ig14052 for linux-xfs-outgoing; Thu, 31 Jan 2002 16:08:18 -0800 Received: from mailhost.idcomm.com (mailhost.idcomm.com [207.40.196.14]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1108Ad14030 for ; Thu, 31 Jan 2002 16:08:10 -0800 Received: from idcomm.com (IDENT:KEM/0AZVL9AF7Kc4zKqEQLB73Y0Rb9J9@k56-pip83.idcomm.com [209.60.72.210] (may be forged)) by mailhost.idcomm.com (8.10.2/8.10.0) with ESMTP id g0VNEmx31090 for ; Thu, 31 Jan 2002 16:14:48 -0700 Message-ID: <3C59CE74.E5D20B9D@idcomm.com> Date: Thu, 31 Jan 2002 16:08:36 -0700 From: "D. Stimits" Reply-To: stimits@idcomm.com X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.6-pre1-xfs-4 i686) X-Accept-Language: en MIME-Version: 1.0 To: "XFS: linux-xfs@oss.sgi.com" Subject: Re: [NEWS] Extended attributes interface changes References: <20020201095217.F88469@wobbly.melbourne.sgi.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 2339 Lines: 53 Nathan Scott wrote: > > Hi folks, > > As you may have heard, Linus has accepted the revised extended > attributes interfaces which several projects have been working > on during the past few months, including ours, into 2.5.3. > > >From an XFS development point of view, this is great news and > will result in a significant decrease in the overlap which the > XFS patches have with the rest of the kernel, and also means > that we will no longer need to use unreserved system calls. > > Inclusion of XFS in certain distributions has been held up due > to this, and once the transition to these interfaces is complete, > I understand these will be able to proceed. We will also be able > to converge on a single set of user tools for EAs and POSIX ACLs > that other filesystems will be using as well (which is good news > for Samba and any other upstream libacl.so users). > > >From an end-user point of view, we will need to make a transition > from using our current system call interfaces for EAs and ACLs to > the new interfaces. This affects both the kernel and a number of > the userspace tools and libraries. We've considered attempting to Do I read this correctly, it appears that only tools and kernels change, current XFS filesystems themselves will remain unchanged for this purpose, and fully compatible with newer tools and kernels? D. Stimits, stimits@idcomm.com > keep compatibility with the existing interfaces too, but ultimately > have discarded that option and will instead make a clean break from > one interface to the other (this applies to both the 2.4.x kernels > and the 2.5.x kernels). This means that with a future kernel merge > we will also release new userspace packages (I expect to move all > our packages up to version 2.0.0) and I also expect responsibility > for the ACL package we use to be taken over by Andreas Gruenbacher > - the author/maintainer of the [http://acl.bestbits.at/] ext2/ext3 > ACL implementation - at some point in the not-too-distant-future. > > XFS 1.1 is scheduled for this quarter, I plan on having this all > integrated for that release for those who track the official SGI > releases rather than CVS or patches. > > Further details will follow later, this is just a heads-up that a > significant interface change is in the pipeline. > > cheers. > > -- > Nathan From owner-linux-xfs@oss.sgi.com Thu Jan 31 16:10:38 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g110Aca14197 for linux-xfs-outgoing; Thu, 31 Jan 2002 16:10:38 -0800 Received: from palrel11.hp.com (palrel11.hp.com [156.153.255.246]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g11065d13991 for ; Thu, 31 Jan 2002 16:06:05 -0800 Received: from xparelay1.corp.hp.com (xparelay1.corp.hp.com [15.58.136.173]) by palrel11.hp.com (Postfix) with ESMTP id 53643602915 for ; Thu, 31 Jan 2002 14:39:20 -0800 (PST) Received: from xpabh1.corp.hp.com (xpabh1.corp.hp.com [15.58.136.191]) by xparelay1.corp.hp.com (Postfix) with ESMTP id 09D87E0009D for ; Thu, 31 Jan 2002 14:38:50 -0800 (PST) Received: by xpabh1.corp.hp.com with Internet Mail Service (5.5.2653.19) id ; Thu, 31 Jan 2002 14:38:49 -0800 Message-ID: From: "HABBINGA,ERIK (HP-Loveland,ex1)" To: "'Steve Lord'" , "HABBINGA,ERIK (HP-Loveland,ex1)" Cc: "'linux-xfs@oss.sgi.com'" Subject: RE: nfsd lockups with xfs during SPEC SFS testing Date: Thu, 31 Jan 2002 14:38:46 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/mixed; boundary="----_=_NextPart_000_01C1AAA8.0BA847D0" Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 85376 Lines: 2609 This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_000_01C1AAA8.0BA847D0 Content-Type: text/plain; charset="iso-8859-1" Steve, A co-worker of mine sent me a patch containing the CVS bits at 3:21pm Mountain time 1/30/02, he started the CVS download at 2:37pm Mountain time 1/30/02 and ended it at 2:38pm Mountain time 1/30/02. I've been working on a patch to remove the BKL from the nfsd process, and have been seeing lockups in the xfs code. I saw these lockups with XFS CVS downloads from 1/10/02 and 1/18/02. I finally started running SPEC tests with out my nfsd-BKL-removal patch and still got lockups in the XFS code. So, I don't think this is a regression. I ran another test this morning, and got a different profile of lockups. I've attached the decoded output from alt-sysrq. kupdated is locked up in xlog_grant_log_space, and all the nfsd processes are locked up either in: - fh_lock (all the nfsd3_proc_create->stext_lock->__down_failed->__down cases) - nfsd_sync (the nfsd_commit->stext_lock->__down_failed->__down cases) - pagebuf_grab_lock (the _pagebuf_find_lockable_buffer->stext_lock->__down_failed->__down cases) - lock_wait (the xfs_access->mraccessf->lock_wait cases) - xlog_grant_log_space I'll help anyway I can to track this problem down. Erik > -----Original Message----- > From: Steve Lord [mailto:lord@sgi.com] > Sent: Thursday, January 31, 2002 3:16 PM > To: HABBINGA,ERIK " "(HP-Loveland,ex1) > Cc: 'linux-xfs@oss.sgi.com' > Subject: Re: nfsd lockups with xfs during SPEC SFS testing > > > On Thu, 2002-01-31 at 11:59, HABBINGA,ERIK (HP-Loveland,ex1) wrote: > > I'm running linux 2.4.17 with a version of XFS downloaded > via CVS on Jan > > 30th. When I run the SPEC SFS NFS test against this > kernel, nfsd stops > > responding after awhile. I captured the state of all of the system > > processes via magic sysrq, and found 24 nfsd processes > locked up in various > > stages of the nfsd_lookup code: > > > > - 20 of them were locked up in the fh_lock call before > lookup_one_len in > > nfsd_lookup(). > > - 2 processes were locked up in the _pagebuf_grab_lock call inside > > _pagebuf_find_lockable_buffer(). > > - 2 processes were locked up in the pagebuf_iowait() call in > > pagebuf_iostart() > > > > Any ideas on what may be wrong, and how I can help debug > and solve this > > problem? I've attached the call traces for the locked up > nfsd processes. I > > can provide vmlinux and System.map for this kernel to help > debugging. > > Is this a regression, i.e. did it used to work? And can you > say when on > the 30th? > > Thanks > > Steve > > > -- > > Steve Lord voice: +1-651-683-3511 > Principal Engineer, Filesystem Software email: lord@sgi.com > ------_=_NextPart_000_01C1AAA8.0BA847D0 Content-Type: application/octet-stream; name="sysrq_log.txt.out" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="sysrq_log.txt.out" task: init c0112f8a: c0112f10 T schedule_timeout c0112eb0: c0112eb0 t process_timeout c014255e: c0142394 T do_select c0142900: c01425c0 T sys_select c0106d6f: c0106d3c T system_call task: keventd c0121905: c01217f0 t context_thread c0105594: c010556c T kernel_thread task: ksoftirqd_CPU c011a28f: c011a220 T do_softirq c011a78c: c011a6fc t ksoftirqd c0105594: c010556c T kernel_thread task: ksoftirqd_CPU c011a28f: c011a220 T do_softirq c011a78c: c011a6fc t ksoftirqd c0105594: c010556c T kernel_thread task: ksoftirqd_CPU c011a28f: c011a220 T do_softirq c011a78c: c011a6fc t ksoftirqd c0105594: c010556c T kernel_thread task: ksoftirqd_CPU c011a28f: c011a220 T do_softirq c011a78c: c011a6fc t ksoftirqd c0105594: c010556c T kernel_thread task: kswapd c012d3f6: c012d374 T kswapd c0105594: c010556c T kernel_thread task: bdflush c01138fa: c01138b0 T interruptible_sleep_on c0138199: c01380d0 T bdflush c0105594: c010556c T kernel_thread task: kupdated c01e710a: c01e702c T _sv_wait c01c1e6d: c01c1df8 t xlog_grant_log_space c01c04c9: c01c0448 T xfs_log_reserve c01cb8df: c01cb860 T xfs_trans_reserve c01e27a1: c01e23e0 T xfs_strategy f8890469: c042b620 B ___strtok f88a7c4f: c042b620 B ___strtok f88b3df0: c042b620 B ___strtok c01e0c91: c01e0c0c T linvfs_pb_bmap c01dc212: c01dc1d0 t pagebuf_delalloc_convert c011d4f4: c011d4d4 T update_process_times c01db2e0: c01db270 T pagebuf_write_full_page c01e0c0c: c01e0c0c T linvfs_pb_bmap c010b06d: c010b068 t call_apic_timer_interrupt c01e0e0b: c01e0dfc t linvfs_write_full_page c01e0c0c: c01e0c0c T linvfs_pb_bmap c0134e25: c0134dd0 T _write_buffer c0134fe6: c0134f70 t write_some_buffers c01cf71d: c01cf708 t xfs_sync c01e51b3: c01e5188 T linvfs_write_super c01387dd: c01386ec T sync_supers c0137fdb: c0137f84 t sync_old_buffers c01382b5: c013819c T kupdate c0105594: c010556c T kernel_thread task: pagebuf_daemo c01138fa: c01138b0 T interruptible_sleep_on c01da16a: c01da08c t pagebuf_daemon c01da060: c01da060 t pagebuf_daemon_wakeup c0105594: c010556c T kernel_thread task: lpfc_do_dpc_0 c0105b7b: c0105b10 T __down_interruptible c0105c5b: c0105c54 T __down_failed_interruptible f88c45a0: c042b620 B ___strtok f88b81d5: c042b620 B ___strtok f88c45a0: c042b620 B ___strtok c010558b: c010556c T kernel_thread c0105594: c010556c T kernel_thread task: lpfc_do_dpc_1 c0105b7b: c0105b10 T __down_interruptible c0105c5b: c0105c54 T __down_failed_interruptible f88c45c8: c042b620 B ___strtok f88b81d5: c042b620 B ___strtok f88c45c8: c042b620 B ___strtok c010558b: c010556c T kernel_thread c0105594: c010556c T kernel_thread task: scsi_eh_9 c0105b7b: c0105b10 T __down_interruptible c0105c5b: c0105c54 T __down_failed_interruptible c02cd0bb: c02c76a4 T stext_lock c0105594: c010556c T kernel_thread task: scsi_eh_10 c0105b7b: c0105b10 T __down_interruptible c0105c5b: c0105c54 T __down_failed_interruptible c02cd0bb: c02c76a4 T stext_lock c0105594: c010556c T kernel_thread task: syslogd c0112f27: c0112f10 T schedule_timeout c014255e: c0142394 T do_select c0142900: c01425c0 T sys_select c0106d6f: c0106d3c T system_call task: klogd c0115cb4: c0115bf0 T do_syslog c01535a5: c0153594 t kmsg_read c0133f97: c0133f08 T sys_read c0106d6f: c0106d3c T system_call task: pump c01422ec: c0142264 T __pollwait c0112f8a: c0112f10 T schedule_timeout c0112eb0: c0112eb0 t process_timeout c014255e: c0142394 T do_select c0142900: c01425c0 T sys_select c0106d6f: c0106d3c T system_call task: portmap c027a1ff: c027a1dc t sock_poll c0112f27: c0112f10 T schedule_timeout c0142b4a: c0142ac4 t do_poll c0142b7f: c0142ac4 t do_poll c0142d7d: c0142ba0 T sys_poll c027b51c: c027b338 T sys_socketcall c0106d6f: c0106d3c T system_call task: inetd c0112f27: c0112f10 T schedule_timeout c014255e: c0142394 T do_select c0142900: c01425c0 T sys_select c0106d6f: c0106d3c T system_call task: cron c0112f8a: c0112f10 T schedule_timeout c0112eb0: c0112eb0 t process_timeout c011da9c: c011d98c T sys_nanosleep c0106d6f: c0106d3c T system_call task: atd c0112f8a: c0112f10 T schedule_timeout c0112eb0: c0112eb0 t process_timeout c011da9c: c011d98c T sys_nanosleep c0106d6f: c0106d3c T system_call task: nmbd c0112f8a: c0112f10 T schedule_timeout c0112eb0: c0112eb0 t process_timeout c014255e: c0142394 T do_select c0142900: c01425c0 T sys_select c0106d6f: c0106d3c T system_call task: smbd c01422ec: c0142264 T __pollwait c0112f27: c0112f10 T schedule_timeout c014255e: c0142394 T do_select c0142900: c01425c0 T sys_select c0106d6f: c0106d3c T system_call task: httpd c0112f8a: c0112f10 T schedule_timeout c0112eb0: c0112eb0 t process_timeout c014255e: c0142394 T do_select c0142900: c01425c0 T sys_select c0106d6f: c0106d3c T system_call task: httpd c01422ec: c0142264 T __pollwait c0112f27: c0112f10 T schedule_timeout c014255e: c0142394 T do_select c0142900: c01425c0 T sys_select c0106d6f: c0106d3c T system_call task: httpd c01ea400: c01ea034 T sys_semop c012dbaf: c012db7c T __alloc_pages c01236c1: c012344c t do_wp_page c01236e6: c012344c t do_wp_page c0123f1c: c0123e5c T handle_mm_fault c01b968b: c01b962c T xfs_iunlock c01d14fb: c01d14cc t xfs_access c0145a69: c0145a50 T dput c013d1ed: c013d1e0 T path_release c013dc50: c013d480 T link_path_walk c011f547: c011f4a8 T sys_rt_sigaction c010c2a6: c010c26c T sys_ipc c0106d6f: c0106d3c T system_call task: httpd c01ea302: c01ea034 T sys_semop c01ea400: c01ea034 T sys_semop c012dbaf: c012db7c T __alloc_pages c01236c1: c012344c t do_wp_page c01236e6: c012344c t do_wp_page c0123f1c: c0123e5c T handle_mm_fault c01b968b: c01b962c T xfs_iunlock c01d14fb: c01d14cc t xfs_access c0145a69: c0145a50 T dput c013d1ed: c013d1e0 T path_release c013dc50: c013d480 T link_path_walk c011f547: c011f4a8 T sys_rt_sigaction c010c2a6: c010c26c T sys_ipc c0106d6f: c0106d3c T system_call task: snmpd c0112f27: c0112f10 T schedule_timeout c014255e: c0142394 T do_select c0142900: c01425c0 T sys_select c0106d6f: c0106d3c T system_call task: snmptrapd c0112f27: c0112f10 T schedule_timeout c014255e: c0142394 T do_select c0142900: c01425c0 T sys_select c0106d6f: c0106d3c T system_call task: rpc.rquotad c027a1ff: c027a1dc t sock_poll c0112f27: c0112f10 T schedule_timeout c0142b4a: c0142ac4 t do_poll c0142b7f: c0142ac4 t do_poll c0142d7d: c0142ba0 T sys_poll c0106d6f: c0106d3c T system_call task: rpc.mountd c027a1ff: c027a1dc t sock_poll c0112f27: c0112f10 T schedule_timeout c0142b4a: c0142ac4 t do_poll c0142b7f: c0142ac4 t do_poll c0142d7d: c0142ba0 T sys_poll c027b51c: c027b338 T sys_socketcall c0106d6f: c0106d3c T system_call task: rpc.statd c01422ec: c0142264 T __pollwait c0112f27: c0112f10 T schedule_timeout c014255e: c0142394 T do_select c0142900: c01425c0 T sys_select c0106d6f: c0106d3c T system_call task: nfsd c0105ab4: c0105a48 T __down c0105c50: c0105c48 T __down_failed c02cb097: c02c76a4 T stext_lock c0168df4: c0168c68 t nfsd3_proc_create c015fae3: c015fa10 t nfsd_dispatch c02be9e5: c02be758 T svc_process c015f8df: c015f6e8 t nfsd c0105594: c010556c T kernel_thread task: nfsd c0105ab4: c0105a48 T __down c0105c50: c0105c48 T __down_failed c02cb097: c02c76a4 T stext_lock c0168df4: c0168c68 t nfsd3_proc_create c015fae3: c015fa10 t nfsd_dispatch c02be9e5: c02be758 T svc_process c015f8df: c015f6e8 t nfsd c0105594: c010556c T kernel_thread task: nfsd c0105ab4: c0105a48 T __down c0105c50: c0105c48 T __down_failed c02cb079: c02c76a4 T stext_lock c0163b62: c0163b18 T nfsd_commit c0169f59: c0169e34 t nfsd3_proc_commit c015fae3: c015fa10 t nfsd_dispatch c02be9e5: c02be758 T svc_process c015f8df: c015f6e8 t nfsd c0105594: c010556c T kernel_thread task: nfsd c0105ab4: c0105a48 T __down c0105c50: c0105c48 T __down_failed c02cb079: c02c76a4 T stext_lock c0163b62: c0163b18 T nfsd_commit c0169f59: c0169e34 t nfsd3_proc_commit c015fae3: c015fa10 t nfsd_dispatch c02be9e5: c02be758 T svc_process c015f8df: c015f6e8 t nfsd c0105594: c010556c T kernel_thread task: nfsd c0105ab4: c0105a48 T __down c0105c50: c0105c48 T __down_failed c02cb097: c02c76a4 T stext_lock c0168df4: c0168c68 t nfsd3_proc_create c015fae3: c015fa10 t nfsd_dispatch c02be9e5: c02be758 T svc_process c015f8df: c015f6e8 t nfsd c0105594: c010556c T kernel_thread task: nfsd c0105ab4: c0105a48 T __down c0105c50: c0105c48 T __down_failed c02cbdec: c02c76a4 T stext_lock c01dc486: c01dc384 T _pagebuf_find_lockable_buffer c019732f: c01972e4 t xfs_bmap_search_extents c01d8e3f: c01d8e08 T pagebuf_get c01d8e6e: c01d8e08 T pagebuf_get c01dc5b9: c01dc584 T _pagebuf_get_lockable_buffer c01a4ab6: c01a4a98 t xfs_da_buf_make c01d8e3f: c01d8e08 T pagebuf_get c01cd09e: c01cced8 T xfs_trans_read_buf c01b696f: c01b6914 T xfs_ialloc_read_agi c01b5941: c01b5730 t xfs_ialloc_ag_select c01b5a12: c01b59dc T xfs_dialloc c01a820f: c01a80b0 t xfs_dir2_block_lookup_int c01a800f: c01a7ff4 T xfs_dir2_block_lookup c01baee7: c01bae88 T xfs_ialloc c01ce3a0: c01ce328 T xfs_dir_ialloc c01d2c2c: c01d2814 t xfs_create c01e0119: c01dfff8 T linvfs_common_cr c01b968b: c01b962c T xfs_iunlock c01cc976: c01cc954 T xfs_trans_unlocked_item f88d02f2: c042b620 B ___strtok c01e60f9: c01e60ec T vn_rele c01d59c6: c01d5974 T xfs_rwunlock c027e868: c027e6d4 T csum_partial_copy_fromiovecend c0286343: c0286330 T qdisc_restart c02801ed: c02800ac T dev_queue_xmit c028eefe: c028ee10 T ip_output c02a8a28: c02a8a28 t udp_getfrag c01cc976: c01cc954 T xfs_trans_unlocked_item c01cc976: c01cc954 T xfs_trans_unlocked_item c01e0260: c01e0248 T linvfs_create c013e22a: c013e10c T vfs_create c0164194: c0163f00 T nfsd_create_v3 c0168df4: c0168c68 t nfsd3_proc_create c015fae3: c015fa10 t nfsd_dispatch c02be9e5: c02be758 T svc_process c015f8df: c015f6e8 t nfsd c0105594: c010556c T kernel_thread task: nfsd c01e6ccd: c01e6c20 T lock_wait c01e6d7c: c01e6d2c T mraccessf c01d14e6: c01d14cc t xfs_access c01b9546: c01b94c0 T xfs_ilock_ra c01b9563: c01b9550 T xfs_ilock c01d14e6: c01d14cc t xfs_access c01d14e6: c01d14cc t xfs_access c01e0a71: c01e0a54 T linvfs_permission c013d125: c013d0dc T permission c0165480: c01653d0 T nfsd_permission c0162116: c0161d4c T fh_verify c02bf5f6: c02bf084 t svc_udp_recvfrom c0121b4f: c0121b28 T nfstrace_event f896d320: c042b620 B ___strtok c0168d88: c0168c68 t nfsd3_proc_create c015fae3: c015fa10 t nfsd_dispatch c02be9e5: c02be758 T svc_process c015f8df: c015f6e8 t nfsd c0105594: c010556c T kernel_thread task: nfsd c0105ab4: c0105a48 T __down c0105c50: c0105c48 T __down_failed c02cb079: c02c76a4 T stext_lock c0163b62: c0163b18 T nfsd_commit c0169f59: c0169e34 t nfsd3_proc_commit c015fae3: c015fa10 t nfsd_dispatch c02be9e5: c02be758 T svc_process c015f8df: c015f6e8 t nfsd c0105594: c010556c T kernel_thread task: nfsd c01e6ccd: c01e6c20 T lock_wait c01e6d7c: c01e6d2c T mraccessf c01d14e6: c01d14cc t xfs_access c01b9546: c01b94c0 T xfs_ilock_ra c01b9563: c01b9550 T xfs_ilock c01d14e6: c01d14cc t xfs_access c01d14e6: c01d14cc t xfs_access c01e0a71: c01e0a54 T linvfs_permission c013d125: c013d0dc T permission c0165480: c01653d0 T nfsd_permission c0162116: c0161d4c T fh_verify c02bf5f6: c02bf084 t svc_udp_recvfrom c0121b4f: c0121b28 T nfstrace_event f896d320: c042b620 B ___strtok c0168d88: c0168c68 t nfsd3_proc_create c015fae3: c015fa10 t nfsd_dispatch c02be9e5: c02be758 T svc_process c015f8df: c015f6e8 t nfsd c0105594: c010556c T kernel_thread task: nfsd c0105ab4: c0105a48 T __down c0105c50: c0105c48 T __down_failed c02cb097: c02c76a4 T stext_lock c0168df4: c0168c68 t nfsd3_proc_create c015fae3: c015fa10 t nfsd_dispatch c02be9e5: c02be758 T svc_process c015f8df: c015f6e8 t nfsd c0105594: c010556c T kernel_thread task: nfsd c0105ab4: c0105a48 T __down c0105c50: c0105c48 T __down_failed c02cb079: c02c76a4 T stext_lock c0163b62: c0163b18 T nfsd_commit c0169f59: c0169e34 t nfsd3_proc_commit c015fae3: c015fa10 t nfsd_dispatch c02be9e5: c02be758 T svc_process c015f8df: c015f6e8 t nfsd c0105594: c010556c T kernel_thread task: nfsd c01e6ccd: c01e6c20 T lock_wait c01e6d7c: c01e6d2c T mraccessf c01d14e6: c01d14cc t xfs_access c01b9546: c01b94c0 T xfs_ilock_ra c01b9563: c01b9550 T xfs_ilock c01d14e6: c01d14cc t xfs_access c01d14e6: c01d14cc t xfs_access c01e0a71: c01e0a54 T linvfs_permission c013d125: c013d0dc T permission c0165480: c01653d0 T nfsd_permission c0162116: c0161d4c T fh_verify c02bf5f6: c02bf084 t svc_udp_recvfrom c0121b4f: c0121b28 T nfstrace_event f896d320: c042b620 B ___strtok c0168d88: c0168c68 t nfsd3_proc_create c015fae3: c015fa10 t nfsd_dispatch c02be9e5: c02be758 T svc_process c015f8df: c015f6e8 t nfsd c0105594: c010556c T kernel_thread task: nfsd c0105ab4: c0105a48 T __down c0105c50: c0105c48 T __down_failed c02cb079: c02c76a4 T stext_lock c0163b62: c0163b18 T nfsd_commit c0169f59: c0169e34 t nfsd3_proc_commit c015fae3: c015fa10 t nfsd_dispatch c02be9e5: c02be758 T svc_process c015f8df: c015f6e8 t nfsd c0105594: c010556c T kernel_thread task: nfsd c01e6ccd: c01e6c20 T lock_wait c01e6d7c: c01e6d2c T mraccessf c01d14e6: c01d14cc t xfs_access c01b9546: c01b94c0 T xfs_ilock_ra c01b9563: c01b9550 T xfs_ilock c01d14e6: c01d14cc t xfs_access c01d14e6: c01d14cc t xfs_access c01e0a71: c01e0a54 T linvfs_permission c013d125: c013d0dc T permission c0165480: c01653d0 T nfsd_permission c0162116: c0161d4c T fh_verify c02bf5f6: c02bf084 t svc_udp_recvfrom c0121b4f: c0121b28 T nfstrace_event f896d320: c042b620 B ___strtok c0168d88: c0168c68 t nfsd3_proc_create c015fae3: c015fa10 t nfsd_dispatch c02be9e5: c02be758 T svc_process c015f8df: c015f6e8 t nfsd c0105594: c010556c T kernel_thread task: nfsd c0105ab4: c0105a48 T __down c0105c50: c0105c48 T __down_failed c02cb097: c02c76a4 T stext_lock c0168df4: c0168c68 t nfsd3_proc_create c015fae3: c015fa10 t nfsd_dispatch c02be9e5: c02be758 T svc_process c015f8df: c015f6e8 t nfsd c0105594: c010556c T kernel_thread task: nfsd c0105ab4: c0105a48 T __down c0105c50: c0105c48 T __down_failed c02cb097: c02c76a4 T stext_lock c0168df4: c0168c68 t nfsd3_proc_create c015fae3: c015fa10 t nfsd_dispatch c02be9e5: c02be758 T svc_process c015f8df: c015f6e8 t nfsd c0105594: c010556c T kernel_thread task: nfsd c0105ab4: c0105a48 T __down c0105c50: c0105c48 T __down_failed c02cb097: c02c76a4 T stext_lock c0168df4: c0168c68 t nfsd3_proc_create c015fae3: c015fa10 t nfsd_dispatch c02be9e5: c02be758 T svc_process c015f8df: c015f6e8 t nfsd c0105594: c010556c T kernel_thread task: nfsd c0105ab4: c0105a48 T __down c0105c50: c0105c48 T __down_failed c02cb097: c02c76a4 T stext_lock c0168df4: c0168c68 t nfsd3_proc_create c015fae3: c015fa10 t nfsd_dispatch c02be9e5: c02be758 T svc_process c015f8df: c015f6e8 t nfsd c0105594: c010556c T kernel_thread task: nfsd c0105ab4: c0105a48 T __down c0105c50: c0105c48 T __down_failed c02cb079: c02c76a4 T stext_lock c0163b62: c0163b18 T nfsd_commit c0169f59: c0169e34 t nfsd3_proc_commit c015fae3: c015fa10 t nfsd_dispatch c02be9e5: c02be758 T svc_process c015f8df: c015f6e8 t nfsd c0105594: c010556c T kernel_thread task: nfsd c01e6ccd: c01e6c20 T lock_wait c01e6d7c: c01e6d2c T mraccessf c01d14e6: c01d14cc t xfs_access c01b9546: c01b94c0 T xfs_ilock_ra c01b9563: c01b9550 T xfs_ilock c01d14e6: c01d14cc t xfs_access c01d14e6: c01d14cc t xfs_access c01e0a71: c01e0a54 T linvfs_permission c013d125: c013d0dc T permission c0165480: c01653d0 T nfsd_permission c0162116: c0161d4c T fh_verify c02bf5f6: c02bf084 t svc_udp_recvfrom c0121b4f: c0121b28 T nfstrace_event f896d320: c042b620 B ___strtok c0168d88: c0168c68 t nfsd3_proc_create c015fae3: c015fa10 t nfsd_dispatch c02be9e5: c02be758 T svc_process c015f8df: c015f6e8 t nfsd c0105594: c010556c T kernel_thread task: nfsd c01e6ccd: c01e6c20 T lock_wait c01e6d7c: c01e6d2c T mraccessf c01d14e6: c01d14cc t xfs_access c01b9546: c01b94c0 T xfs_ilock_ra c01b9563: c01b9550 T xfs_ilock c01d14e6: c01d14cc t xfs_access c01d14e6: c01d14cc t xfs_access c01e0a71: c01e0a54 T linvfs_permission c013d125: c013d0dc T permission c0165480: c01653d0 T nfsd_permission c0162116: c0161d4c T fh_verify c02bf5f6: c02bf084 t svc_udp_recvfrom c0121b4f: c0121b28 T nfstrace_event f896d320: c042b620 B ___strtok c0168d88: c0168c68 t nfsd3_proc_create c015fae3: c015fa10 t nfsd_dispatch c02be9e5: c02be758 T svc_process c015f8df: c015f6e8 t nfsd c0105594: c010556c T kernel_thread task: nfsd c0105ab4: c0105a48 T __down c0105c50: c0105c48 T __down_failed c02cb079: c02c76a4 T stext_lock c0163b62: c0163b18 T nfsd_commit c0169f59: c0169e34 t nfsd3_proc_commit c015fae3: c015fa10 t nfsd_dispatch c02be9e5: c02be758 T svc_process c015f8df: c015f6e8 t nfsd c0105594: c010556c T kernel_thread task: nfsd c01e6ccd: c01e6c20 T lock_wait c01e6d7c: c01e6d2c T mraccessf c01d14e6: c01d14cc t xfs_access c01b9546: c01b94c0 T xfs_ilock_ra c01b9563: c01b9550 T xfs_ilock c01d14e6: c01d14cc t xfs_access c01d14e6: c01d14cc t xfs_access c01e0a71: c01e0a54 T linvfs_permission c013d125: c013d0dc T permission c0165480: c01653d0 T nfsd_permission c0162116: c0161d4c T fh_verify c02bf5f6: c02bf084 t svc_udp_recvfrom c0121b4f: c0121b28 T nfstrace_event f896d320: c042b620 B ___strtok c0168d88: c0168c68 t nfsd3_proc_create c015fae3: c015fa10 t nfsd_dispatch c02be9e5: c02be758 T svc_process c015f8df: c015f6e8 t nfsd c0105594: c010556c T kernel_thread task: nfsd c01e6ccd: c01e6c20 T lock_wait c01e6d7c: c01e6d2c T mraccessf c01d14e6: c01d14cc t xfs_access c01b9546: c01b94c0 T xfs_ilock_ra c01b9563: c01b9550 T xfs_ilock c01d14e6: c01d14cc t xfs_access c01d14e6: c01d14cc t xfs_access c01e0a71: c01e0a54 T linvfs_permission c013d125: c013d0dc T permission c0165480: c01653d0 T nfsd_permission c0162116: c0161d4c T fh_verify c02bf5f6: c02bf084 t svc_udp_recvfrom c0121b4f: c0121b28 T nfstrace_event f896d320: c042b620 B ___strtok c0168d88: c0168c68 t nfsd3_proc_create c015fae3: c015fa10 t nfsd_dispatch c02be9e5: c02be758 T svc_process c015f8df: c015f6e8 t nfsd c0105594: c010556c T kernel_thread task: nfsd c0105ab4: c0105a48 T __down c0105c50: c0105c48 T __down_failed c02cb097: c02c76a4 T stext_lock c0168df4: c0168c68 t nfsd3_proc_create c015fae3: c015fa10 t nfsd_dispatch c02be9e5: c02be758 T svc_process c015f8df: c015f6e8 t nfsd c0105594: c010556c T kernel_thread task: nfsd c01e6ccd: c01e6c20 T lock_wait c01e6d7c: c01e6d2c T mraccessf c01d14e6: c01d14cc t xfs_access c01b9546: c01b94c0 T xfs_ilock_ra c01b9563: c01b9550 T xfs_ilock c01d14e6: c01d14cc t xfs_access c01d14e6: c01d14cc t xfs_access c01e0a71: c01e0a54 T linvfs_permission c013d125: c013d0dc T permission c0165480: c01653d0 T nfsd_permission c0162116: c0161d4c T fh_verify c02bf5f6: c02bf084 t svc_udp_recvfrom c0121b4f: c0121b28 T nfstrace_event f896d320: c042b620 B ___strtok c0168d88: c0168c68 t nfsd3_proc_create c015fae3: c015fa10 t nfsd_dispatch c02be9e5: c02be758 T svc_process c015f8df: c015f6e8 t nfsd c0105594: c010556c T kernel_thread task: nfsd c01e6ccd: c01e6c20 T lock_wait c01e6d7c: c01e6d2c T mraccessf c01d14e6: c01d14cc t xfs_access c01b9546: c01b94c0 T xfs_ilock_ra c01b9563: c01b9550 T xfs_ilock c01d14e6: c01d14cc t xfs_access c01d14e6: c01d14cc t xfs_access c01e0a71: c01e0a54 T linvfs_permission c013d125: c013d0dc T permission c0165480: c01653d0 T nfsd_permission c0162116: c0161d4c T fh_verify c02bf5f6: c02bf084 t svc_udp_recvfrom c0121b4f: c0121b28 T nfstrace_event f896d320: c042b620 B ___strtok c0168d88: c0168c68 t nfsd3_proc_create c015fae3: c015fa10 t nfsd_dispatch c02be9e5: c02be758 T svc_process c015f8df: c015f6e8 t nfsd c0105594: c010556c T kernel_thread task: lockd c0112f27: c0112f10 T schedule_timeout c0106e1d: c0106e18 t reschedule c02c042e: c02c0258 T svc_recv c016e1c4: c016e054 t lockd c0105594: c010556c T kernel_thread task: rpciod c02bd23c: c02bd080 t rpciod c0105594: c010556c T kernel_thread task: nfsd c01e6ccd: c01e6c20 T lock_wait c01e6d7c: c01e6d2c T mraccessf c01d14e6: c01d14cc t xfs_access c01b9546: c01b94c0 T xfs_ilock_ra c01b9563: c01b9550 T xfs_ilock c01d14e6: c01d14cc t xfs_access c01d14e6: c01d14cc t xfs_access c01e0a71: c01e0a54 T linvfs_permission c013d125: c013d0dc T permission c0165480: c01653d0 T nfsd_permission c0162116: c0161d4c T fh_verify c02bf5f6: c02bf084 t svc_udp_recvfrom c0121b4f: c0121b28 T nfstrace_event f896d320: c042b620 B ___strtok c0168d88: c0168c68 t nfsd3_proc_create c015fae3: c015fa10 t nfsd_dispatch c02be9e5: c02be758 T svc_process c015f8df: c015f6e8 t nfsd c0105594: c010556c T kernel_thread task: nfsd c01e6ccd: c01e6c20 T lock_wait c01e6d7c: c01e6d2c T mraccessf c01d14e6: c01d14cc t xfs_access c01b9546: c01b94c0 T xfs_ilock_ra c01b9563: c01b9550 T xfs_ilock c01d14e6: c01d14cc t xfs_access c01d14e6: c01d14cc t xfs_access c01e0a71: c01e0a54 T linvfs_permission c013d125: c013d0dc T permission c0165480: c01653d0 T nfsd_permission c0162116: c0161d4c T fh_verify c02bf5f6: c02bf084 t svc_udp_recvfrom c0121b4f: c0121b28 T nfstrace_event f896d320: c042b620 B ___strtok c0168d88: c0168c68 t nfsd3_proc_create c015fae3: c015fa10 t nfsd_dispatch c02be9e5: c02be758 T svc_process c015f8df: c015f6e8 t nfsd c0105594: c010556c T kernel_thread task: nfsd c0105ab4: c0105a48 T __down c0105c50: c0105c48 T __down_failed c02cb079: c02c76a4 T stext_lock c0163b62: c0163b18 T nfsd_commit c0169f59: c0169e34 t nfsd3_proc_commit c015fae3: c015fa10 t nfsd_dispatch c02be9e5: c02be758 T svc_process c015f8df: c015f6e8 t nfsd c0105594: c010556c T kernel_thread task: nfsd c0105ab4: c0105a48 T __down c0105c50: c0105c48 T __down_failed c02cb097: c02c76a4 T stext_lock c0168df4: c0168c68 t nfsd3_proc_create c015fae3: c015fa10 t nfsd_dispatch c02be9e5: c02be758 T svc_process c015f8df: c015f6e8 t nfsd c0105594: c010556c T kernel_thread task: nfsd c01e6ccd: c01e6c20 T lock_wait c01e6d7c: c01e6d2c T mraccessf c01d14e6: c01d14cc t xfs_access c01b9546: c01b94c0 T xfs_ilock_ra c01b9563: c01b9550 T xfs_ilock c01d14e6: c01d14cc t xfs_access c01d14e6: c01d14cc t xfs_access c01e0a71: c01e0a54 T linvfs_permission c013d125: c013d0dc T permission c0165480: c01653d0 T nfsd_permission c0162116: c0161d4c T fh_verify c02bf5f6: c02bf084 t svc_udp_recvfrom c0121b4f: c0121b28 T nfstrace_event f896d320: c042b620 B ___strtok c0168d88: c0168c68 t nfsd3_proc_create c015fae3: c015fa10 t nfsd_dispatch c02be9e5: c02be758 T svc_process c015f8df: c015f6e8 t nfsd c0105594: c010556c T kernel_thread task: nfsd c01e6ccd: c01e6c20 T lock_wait c01e6d7c: c01e6d2c T mraccessf c01d14e6: c01d14cc t xfs_access c01b9546: c01b94c0 T xfs_ilock_ra c01b9563: c01b9550 T xfs_ilock c01d14e6: c01d14cc t xfs_access c01d14e6: c01d14cc t xfs_access c01e0a71: c01e0a54 T linvfs_permission c013d125: c013d0dc T permission c0165480: c01653d0 T nfsd_permission c0162116: c0161d4c T fh_verify c02bf5f6: c02bf084 t svc_udp_recvfrom c0121b4f: c0121b28 T nfstrace_event f896d320: c042b620 B ___strtok c0168d88: c0168c68 t nfsd3_proc_create c015fae3: c015fa10 t nfsd_dispatch c02be9e5: c02be758 T svc_process c015f8df: c015f6e8 t nfsd c0105594: c010556c T kernel_thread task: nfsd c01e6ccd: c01e6c20 T lock_wait c01e6d7c: c01e6d2c T mraccessf c01d14e6: c01d14cc t xfs_access c01b9546: c01b94c0 T xfs_ilock_ra c01b9563: c01b9550 T xfs_ilock c01d14e6: c01d14cc t xfs_access c01d14e6: c01d14cc t xfs_access c01e0a71: c01e0a54 T linvfs_permission c013d125: c013d0dc T permission c0165480: c01653d0 T nfsd_permission c0162116: c0161d4c T fh_verify c02bf5f6: c02bf084 t svc_udp_recvfrom c0121b4f: c0121b28 T nfstrace_event f896d320: c042b620 B ___strtok c0168d88: c0168c68 t nfsd3_proc_create c015fae3: c015fa10 t nfsd_dispatch c02be9e5: c02be758 T svc_process c015f8df: c015f6e8 t nfsd c0105594: c010556c T kernel_thread task: nfsd c01e6ccd: c01e6c20 T lock_wait c01e6d7c: c01e6d2c T mraccessf c01d14e6: c01d14cc t xfs_access c01b9546: c01b94c0 T xfs_ilock_ra c01b9563: c01b9550 T xfs_ilock c01d14e6: c01d14cc t xfs_access c01d14e6: c01d14cc t xfs_access c01e0a71: c01e0a54 T linvfs_permission c013d125: c013d0dc T permission c0165480: c01653d0 T nfsd_permission c0162116: c0161d4c T fh_verify c02bf5f6: c02bf084 t svc_udp_recvfrom c0121b4f: c0121b28 T nfstrace_event f896d320: c042b620 B ___strtok c0168d88: c0168c68 t nfsd3_proc_create c015fae3: c015fa10 t nfsd_dispatch c02be9e5: c02be758 T svc_process c015f8df: c015f6e8 t nfsd c0105594: c010556c T kernel_thread task: nfsd c0105ab4: c0105a48 T __down c0105c50: c0105c48 T __down_failed c02cb079: c02c76a4 T stext_lock c0163b62: c0163b18 T nfsd_commit c0169f59: c0169e34 t nfsd3_proc_commit c015fae3: c015fa10 t nfsd_dispatch c02be9e5: c02be758 T svc_process c015f8df: c015f6e8 t nfsd c0105594: c010556c T kernel_thread task: nfsd c01e6ccd: c01e6c20 T lock_wait c01e6d7c: c01e6d2c T mraccessf c01d14e6: c01d14cc t xfs_access c01b9546: c01b94c0 T xfs_ilock_ra c01b9563: c01b9550 T xfs_ilock c01d14e6: c01d14cc t xfs_access c01d14e6: c01d14cc t xfs_access c01e0a71: c01e0a54 T linvfs_permission c013d125: c013d0dc T permission c0165480: c01653d0 T nfsd_permission c0162116: c0161d4c T fh_verify c02bf5f6: c02bf084 t svc_udp_recvfrom c0121b4f: c0121b28 T nfstrace_event f896d320: c042b620 B ___strtok c0168d88: c0168c68 t nfsd3_proc_create c015fae3: c015fa10 t nfsd_dispatch c02be9e5: c02be758 T svc_process c015f8df: c015f6e8 t nfsd c0105594: c010556c T kernel_thread task: nfsd c01e6ccd: c01e6c20 T lock_wait c01e6d7c: c01e6d2c T mraccessf c01d14e6: c01d14cc t xfs_access c01b9546: c01b94c0 T xfs_ilock_ra c01b9563: c01b9550 T xfs_ilock c01d14e6: c01d14cc t xfs_access c01d14e6: c01d14cc t xfs_access c01e0a71: c01e0a54 T linvfs_permission c013d125: c013d0dc T permission c0165480: c01653d0 T nfsd_permission c0162116: c0161d4c T fh_verify c02bf5f6: c02bf084 t svc_udp_recvfrom c0121b4f: c0121b28 T nfstrace_event f896d320: c042b620 B ___strtok c0168d88: c0168c68 t nfsd3_proc_create c015fae3: c015fa10 t nfsd_dispatch c02be9e5: c02be758 T svc_process c015f8df: c015f6e8 t nfsd c0105594: c010556c T kernel_thread task: nfsd c01e6ccd: c01e6c20 T lock_wait c01e6d7c: c01e6d2c T mraccessf c01d14e6: c01d14cc t xfs_access c01b9546: c01b94c0 T xfs_ilock_ra c01b9563: c01b9550 T xfs_ilock c01d14e6: c01d14cc t xfs_access c01d14e6: c01d14cc t xfs_access c01e0a71: c01e0a54 T linvfs_permission c013d125: c013d0dc T permission c0165480: c01653d0 T nfsd_permission c0162116: c0161d4c T fh_verify c02bf5f6: c02bf084 t svc_udp_recvfrom c0121b4f: c0121b28 T nfstrace_event f896d320: c042b620 B ___strtok c0168d88: c0168c68 t nfsd3_proc_create c015fae3: c015fa10 t nfsd_dispatch c02be9e5: c02be758 T svc_process c015f8df: c015f6e8 t nfsd c0105594: c010556c T kernel_thread task: nfsd c0105ab4: c0105a48 T __down c0105c50: c0105c48 T __down_failed c02cb079: c02c76a4 T stext_lock c0163b62: c0163b18 T nfsd_commit c0169f59: c0169e34 t nfsd3_proc_commit c015fae3: c015fa10 t nfsd_dispatch c02be9e5: c02be758 T svc_process c015f8df: c015f6e8 t nfsd c0105594: c010556c T kernel_thread task: nfsd c01e6ccd: c01e6c20 T lock_wait c01e6d7c: c01e6d2c T mraccessf c01d14e6: c01d14cc t xfs_access c01b9546: c01b94c0 T xfs_ilock_ra c01b9563: c01b9550 T xfs_ilock c01d14e6: c01d14cc t xfs_access c01d14e6: c01d14cc t xfs_access c01e0a71: c01e0a54 T linvfs_permission c013d125: c013d0dc T permission c0165480: c01653d0 T nfsd_permission c0162116: c0161d4c T fh_verify c02bf5f6: c02bf084 t svc_udp_recvfrom c0121b4f: c0121b28 T nfstrace_event f896d320: c042b620 B ___strtok c0168d88: c0168c68 t nfsd3_proc_create c015fae3: c015fa10 t nfsd_dispatch c02be9e5: c02be758 T svc_process c015f8df: c015f6e8 t nfsd c0105594: c010556c T kernel_thread task: nfsd c0105ab4: c0105a48 T __down c0105c50: c0105c48 T __down_failed c02cb097: c02c76a4 T stext_lock c0168df4: c0168c68 t nfsd3_proc_create c015fae3: c015fa10 t nfsd_dispatch c02be9e5: c02be758 T svc_process c015f8df: c015f6e8 t nfsd c0105594: c010556c T kernel_thread task: nfsd c0105ab4: c0105a48 T __down c0105c50: c0105c48 T __down_failed c02cb079: c02c76a4 T stext_lock c0163b62: c0163b18 T nfsd_commit c0169f59: c0169e34 t nfsd3_proc_commit c015fae3: c015fa10 t nfsd_dispatch c02be9e5: c02be758 T svc_process c015f8df: c015f6e8 t nfsd c0105594: c010556c T kernel_thread task: nfsd c01e6ccd: c01e6c20 T lock_wait c01e6d7c: c01e6d2c T mraccessf c01d14e6: c01d14cc t xfs_access c01b9546: c01b94c0 T xfs_ilock_ra c01b9563: c01b9550 T xfs_ilock c01d14e6: c01d14cc t xfs_access c01d14e6: c01d14cc t xfs_access c01e0a71: c01e0a54 T linvfs_permission c013d125: c013d0dc T permission c0165480: c01653d0 T nfsd_permission c0162116: c0161d4c T fh_verify c02bf5f6: c02bf084 t svc_udp_recvfrom c0121b4f: c0121b28 T nfstrace_event f896d320: c042b620 B ___strtok c0168d88: c0168c68 t nfsd3_proc_create c015fae3: c015fa10 t nfsd_dispatch c02be9e5: c02be758 T svc_process c015f8df: c015f6e8 t nfsd c0105594: c010556c T kernel_thread task: nfsd c01e6ccd: c01e6c20 T lock_wait c01e6d7c: c01e6d2c T mraccessf c01d14e6: c01d14cc t xfs_access c01b9546: c01b94c0 T xfs_ilock_ra c01b9563: c01b9550 T xfs_ilock c01d14e6: c01d14cc t xfs_access c01d14e6: c01d14cc t xfs_access c01e0a71: c01e0a54 T linvfs_permission c013d125: c013d0dc T permission c0165480: c01653d0 T nfsd_permission c0162116: c0161d4c T fh_verify c02bf5f6: c02bf084 t svc_udp_recvfrom c0121b4f: c0121b28 T nfstrace_event f896d320: c042b620 B ___strtok c0168d88: c0168c68 t nfsd3_proc_create c015fae3: c015fa10 t nfsd_dispatch c02be9e5: c02be758 T svc_process c015f8df: c015f6e8 t nfsd c0105594: c010556c T kernel_thread task: nfsd c01e6ccd: c01e6c20 T lock_wait c01e6d7c: c01e6d2c T mraccessf c01d14e6: c01d14cc t xfs_access c01b9546: c01b94c0 T xfs_ilock_ra c01b9563: c01b9550 T xfs_ilock c01d14e6: c01d14cc t xfs_access c01d14e6: c01d14cc t xfs_access c01e0a71: c01e0a54 T linvfs_permission c013d125: c013d0dc T permission c0165480: c01653d0 T nfsd_permission c0162116: c0161d4c T fh_verify c02bf5f6: c02bf084 t svc_udp_recvfrom c0121b4f: c0121b28 T nfstrace_event f896d320: c042b620 B ___strtok c0168d88: c0168c68 t nfsd3_proc_create c015fae3: c015fa10 t nfsd_dispatch c02be9e5: c02be758 T svc_process c015f8df: c015f6e8 t nfsd c0105594: c010556c T kernel_thread task: nfsd c0105ab4: c0105a48 T __down c0105c50: c0105c48 T __down_failed c02cb079: c02c76a4 T stext_lock c0163b62: c0163b18 T nfsd_commit c0169f59: c0169e34 t nfsd3_proc_commit c015fae3: c015fa10 t nfsd_dispatch c02be9e5: c02be758 T svc_process c015f8df: c015f6e8 t nfsd c0105594: c010556c T kernel_thread task: nfsd c01e6ccd: c01e6c20 T lock_wait c01e6d7c: c01e6d2c T mraccessf c01d14e6: c01d14cc t xfs_access c01b9546: c01b94c0 T xfs_ilock_ra c01b9563: c01b9550 T xfs_ilock c01d14e6: c01d14cc t xfs_access c01d14e6: c01d14cc t xfs_access c01e0a71: c01e0a54 T linvfs_permission c013d125: c013d0dc T permission c0165480: c01653d0 T nfsd_permission c0162116: c0161d4c T fh_verify c02bf5f6: c02bf084 t svc_udp_recvfrom c0121b4f: c0121b28 T nfstrace_event f896d320: c042b620 B ___strtok c0168d88: c0168c68 t nfsd3_proc_create c015fae3: c015fa10 t nfsd_dispatch c02be9e5: c02be758 T svc_process c015f8df: c015f6e8 t nfsd c0105594: c010556c T kernel_thread task: nfsd c0105ab4: c0105a48 T __down c0105c50: c0105c48 T __down_failed c02cb079: c02c76a4 T stext_lock c0163b62: c0163b18 T nfsd_commit c0169f59: c0169e34 t nfsd3_proc_commit c015fae3: c015fa10 t nfsd_dispatch c02be9e5: c02be758 T svc_process c015f8df: c015f6e8 t nfsd c0105594: c010556c T kernel_thread task: nfsd c0105ab4: c0105a48 T __down c0105c50: c0105c48 T __down_failed c02cb079: c02c76a4 T stext_lock c0163b62: c0163b18 T nfsd_commit c0169f59: c0169e34 t nfsd3_proc_commit c015fae3: c015fa10 t nfsd_dispatch c02be9e5: c02be758 T svc_process c015f8df: c015f6e8 t nfsd c0105594: c010556c T kernel_thread task: nfsd c01e6ccd: c01e6c20 T lock_wait c01e6d7c: c01e6d2c T mraccessf c01d14e6: c01d14cc t xfs_access c01b9546: c01b94c0 T xfs_ilock_ra c01b9563: c01b9550 T xfs_ilock c01d14e6: c01d14cc t xfs_access c01d14e6: c01d14cc t xfs_access c01e0a71: c01e0a54 T linvfs_permission c013d125: c013d0dc T permission c0165480: c01653d0 T nfsd_permission c0162116: c0161d4c T fh_verify c02bf5f6: c02bf084 t svc_udp_recvfrom c0121b4f: c0121b28 T nfstrace_event f896d320: c042b620 B ___strtok c0168d88: c0168c68 t nfsd3_proc_create c015fae3: c015fa10 t nfsd_dispatch c02be9e5: c02be758 T svc_process c015f8df: c015f6e8 t nfsd c0105594: c010556c T kernel_thread task: nfsd c0105ab4: c0105a48 T __down c0105c50: c0105c48 T __down_failed c02cb097: c02c76a4 T stext_lock c0168df4: c0168c68 t nfsd3_proc_create c015fae3: c015fa10 t nfsd_dispatch c02be9e5: c02be758 T svc_process c015f8df: c015f6e8 t nfsd c0105594: c010556c T kernel_thread task: nfsd c01e6ccd: c01e6c20 T lock_wait c01e6d7c: c01e6d2c T mraccessf c01d14e6: c01d14cc t xfs_access c01b9546: c01b94c0 T xfs_ilock_ra c01b9563: c01b9550 T xfs_ilock c01d14e6: c01d14cc t xfs_access c01d14e6: c01d14cc t xfs_access c01e0a71: c01e0a54 T linvfs_permission c013d125: c013d0dc T permission c0165480: c01653d0 T nfsd_permission c0162116: c0161d4c T fh_verify c02bf5f6: c02bf084 t svc_udp_recvfrom c0121b4f: c0121b28 T nfstrace_event f896d320: c042b620 B ___strtok c0168d88: c0168c68 t nfsd3_proc_create c015fae3: c015fa10 t nfsd_dispatch c02be9e5: c02be758 T svc_process c015f8df: c015f6e8 t nfsd c0105594: c010556c T kernel_thread task: nfsd c0105ab4: c0105a48 T __down c0105c50: c0105c48 T __down_failed c02cb097: c02c76a4 T stext_lock c0168df4: c0168c68 t nfsd3_proc_create c015fae3: c015fa10 t nfsd_dispatch c02be9e5: c02be758 T svc_process c015f8df: c015f6e8 t nfsd c0105594: c010556c T kernel_thread task: nfsd c01e6ccd: c01e6c20 T lock_wait c01e6d7c: c01e6d2c T mraccessf c01d14e6: c01d14cc t xfs_access c01b9546: c01b94c0 T xfs_ilock_ra c01b9563: c01b9550 T xfs_ilock c01d14e6: c01d14cc t xfs_access c01d14e6: c01d14cc t xfs_access c01e0a71: c01e0a54 T linvfs_permission c013d125: c013d0dc T permission c0165480: c01653d0 T nfsd_permission c0162116: c0161d4c T fh_verify c02bf5f6: c02bf084 t svc_udp_recvfrom c0121b4f: c0121b28 T nfstrace_event f896d320: c042b620 B ___strtok c0168d88: c0168c68 t nfsd3_proc_create c015fae3: c015fa10 t nfsd_dispatch c02be9e5: c02be758 T svc_process c015f8df: c015f6e8 t nfsd c0105594: c010556c T kernel_thread task: nfsd c01e6ccd: c01e6c20 T lock_wait c01e6d7c: c01e6d2c T mraccessf c01d14e6: c01d14cc t xfs_access c01b9546: c01b94c0 T xfs_ilock_ra c01b9563: c01b9550 T xfs_ilock c01d14e6: c01d14cc t xfs_access c01d14e6: c01d14cc t xfs_access c01e0a71: c01e0a54 T linvfs_permission c013d125: c013d0dc T permission c0165480: c01653d0 T nfsd_permission c0162116: c0161d4c T fh_verify c02bf5f6: c02bf084 t svc_udp_recvfrom c0121b4f: c0121b28 T nfstrace_event f896d320: c042b620 B ___strtok c0168d88: c0168c68 t nfsd3_proc_create c015fae3: c015fa10 t nfsd_dispatch c02be9e5: c02be758 T svc_process c015f8df: c015f6e8 t nfsd c0105594: c010556c T kernel_thread task: nfsd c01e6ccd: c01e6c20 T lock_wait c01e6d7c: c01e6d2c T mraccessf c01d14e6: c01d14cc t xfs_access c01b9546: c01b94c0 T xfs_ilock_ra c01b9563: c01b9550 T xfs_ilock c01d14e6: c01d14cc t xfs_access c01d14e6: c01d14cc t xfs_access c01e0a71: c01e0a54 T linvfs_permission c013d125: c013d0dc T permission c0165480: c01653d0 T nfsd_permission c0162116: c0161d4c T fh_verify c02bf5f6: c02bf084 t svc_udp_recvfrom c0121b4f: c0121b28 T nfstrace_event f896d320: c042b620 B ___strtok c0168d88: c0168c68 t nfsd3_proc_create c015fae3: c015fa10 t nfsd_dispatch c02be9e5: c02be758 T svc_process c015f8df: c015f6e8 t nfsd c0105594: c010556c T kernel_thread task: nfsd c0105ab4: c0105a48 T __down c0105c50: c0105c48 T __down_failed c02cb097: c02c76a4 T stext_lock c0168df4: c0168c68 t nfsd3_proc_create c015fae3: c015fa10 t nfsd_dispatch c02be9e5: c02be758 T svc_process c015f8df: c015f6e8 t nfsd c0105594: c010556c T kernel_thread task: nfsd c01e6ccd: c01e6c20 T lock_wait c01e6d7c: c01e6d2c T mraccessf c01d14e6: c01d14cc t xfs_access c01b9546: c01b94c0 T xfs_ilock_ra c01b9563: c01b9550 T xfs_ilock c01d14e6: c01d14cc t xfs_access c01d14e6: c01d14cc t xfs_access c01e0a71: c01e0a54 T linvfs_permission c013d125: c013d0dc T permission c0165480: c01653d0 T nfsd_permission c0162116: c0161d4c T fh_verify c02bf5f6: c02bf084 t svc_udp_recvfrom c0121b4f: c0121b28 T nfstrace_event f896d320: c042b620 B ___strtok c0168d88: c0168c68 t nfsd3_proc_create c015fae3: c015fa10 t nfsd_dispatch c02be9e5: c02be758 T svc_process c015f8df: c015f6e8 t nfsd c0105594: c010556c T kernel_thread task: nfsd c0105ab4: c0105a48 T __down c0105c50: c0105c48 T __down_failed c02cbdec: c02c76a4 T stext_lock c01dc486: c01dc384 T _pagebuf_find_lockable_buffer c01cd20d: c01cd1dc T xfs_trans_brelse c01e6abb: c01e6aac T kmem_zone_free c01a0670: c01a062c T xfs_btree_del_cursor c01cd34c: c01cd2f0 T xfs_trans_log_buf c01dc5b9: c01dc584 T _pagebuf_get_lockable_buffer c01d8e3f: c01d8e08 T pagebuf_get c01cce0d: c01ccd18 T xfs_trans_get_buf c01b540f: c01b4f9c t xfs_ialloc_ag_alloc c01d8e3f: c01d8e08 T pagebuf_get c01cd197: c01cced8 T xfs_trans_read_buf c01b696f: c01b6914 T xfs_ialloc_read_agi c01b5aea: c01b59dc T xfs_dialloc c01a800f: c01a7ff4 T xfs_dir2_block_lookup c01baee7: c01bae88 T xfs_ialloc c01ce3a0: c01ce328 T xfs_dir_ialloc c01d2c2c: c01d2814 t xfs_create c01da811: c01da7a0 T pagebuf_commit_write c01e0119: c01dfff8 T linvfs_common_cr f88d02f2: c042b620 B ___strtok c01d59a4: c01d5974 T xfs_rwunlock c027e868: c027e6d4 T csum_partial_copy_fromiovecend c0286343: c0286330 T qdisc_restart c02801ed: c02800ac T dev_queue_xmit c028eefe: c028ee10 T ip_output c02a8a28: c02a8a28 t udp_getfrag c01cc976: c01cc954 T xfs_trans_unlocked_item c01cc976: c01cc954 T xfs_trans_unlocked_item c01e0260: c01e0248 T linvfs_create c013e22a: c013e10c T vfs_create c0164194: c0163f00 T nfsd_create_v3 c0168df4: c0168c68 t nfsd3_proc_create c015fae3: c015fa10 t nfsd_dispatch c02be9e5: c02be758 T svc_process c015f8df: c015f6e8 t nfsd c0105594: c010556c T kernel_thread task: nfsd c0105ab4: c0105a48 T __down c0105c50: c0105c48 T __down_failed c02cb097: c02c76a4 T stext_lock c0168df4: c0168c68 t nfsd3_proc_create c015fae3: c015fa10 t nfsd_dispatch c02be9e5: c02be758 T svc_process c015f8df: c015f6e8 t nfsd c0105594: c010556c T kernel_thread task: nfsd c01e6ccd: c01e6c20 T lock_wait c01e6d7c: c01e6d2c T mraccessf c01d14e6: c01d14cc t xfs_access c01b9546: c01b94c0 T xfs_ilock_ra c01b9563: c01b9550 T xfs_ilock c01d14e6: c01d14cc t xfs_access c01d14e6: c01d14cc t xfs_access c01e0a71: c01e0a54 T linvfs_permission c013d125: c013d0dc T permission c0165480: c01653d0 T nfsd_permission c0162116: c0161d4c T fh_verify c02bf5f6: c02bf084 t svc_udp_recvfrom c0121b4f: c0121b28 T nfstrace_event f896d320: c042b620 B ___strtok c0168d88: c0168c68 t nfsd3_proc_create c015fae3: c015fa10 t nfsd_dispatch c02be9e5: c02be758 T svc_process c015f8df: c015f6e8 t nfsd c0105594: c010556c T kernel_thread task: nfsd c0105ab4: c0105a48 T __down c0105c50: c0105c48 T __down_failed c02cb097: c02c76a4 T stext_lock c0168df4: c0168c68 t nfsd3_proc_create c015fae3: c015fa10 t nfsd_dispatch c02be9e5: c02be758 T svc_process c015f8df: c015f6e8 t nfsd c0105594: c010556c T kernel_thread task: nfsd c01e6ccd: c01e6c20 T lock_wait c01e6d7c: c01e6d2c T mraccessf c01d14e6: c01d14cc t xfs_access c01b9546: c01b94c0 T xfs_ilock_ra c01b9563: c01b9550 T xfs_ilock c01d14e6: c01d14cc t xfs_access c01d14e6: c01d14cc t xfs_access c01e0a71: c01e0a54 T linvfs_permission c013d125: c013d0dc T permission c0165480: c01653d0 T nfsd_permission c0162116: c0161d4c T fh_verify c02bf5f6: c02bf084 t svc_udp_recvfrom c0121b4f: c0121b28 T nfstrace_event f896d320: c042b620 B ___strtok c0168d88: c0168c68 t nfsd3_proc_create c015fae3: c015fa10 t nfsd_dispatch c02be9e5: c02be758 T svc_process c015f8df: c015f6e8 t nfsd c0105594: c010556c T kernel_thread task: nfsd c0105ab4: c0105a48 T __down c0105c50: c0105c48 T __down_failed c02cb079: c02c76a4 T stext_lock c0163b62: c0163b18 T nfsd_commit c0169f59: c0169e34 t nfsd3_proc_commit c015fae3: c015fa10 t nfsd_dispatch c02be9e5: c02be758 T svc_process c015f8df: c015f6e8 t nfsd c0105594: c010556c T kernel_thread task: nfsd c01e6ccd: c01e6c20 T lock_wait c01e6d7c: c01e6d2c T mraccessf c01d14e6: c01d14cc t xfs_access c01b9546: c01b94c0 T xfs_ilock_ra c01b9563: c01b9550 T xfs_ilock c01d14e6: c01d14cc t xfs_access c01d14e6: c01d14cc t xfs_access c01e0a71: c01e0a54 T linvfs_permission c013d125: c013d0dc T permission c0165480: c01653d0 T nfsd_permission c0162116: c0161d4c T fh_verify c02bf5f6: c02bf084 t svc_udp_recvfrom c0121b4f: c0121b28 T nfstrace_event f896d320: c042b620 B ___strtok c0168d88: c0168c68 t nfsd3_proc_create c015fae3: c015fa10 t nfsd_dispatch c02be9e5: c02be758 T svc_process c015f8df: c015f6e8 t nfsd c0105594: c010556c T kernel_thread task: nfsd c01e6ccd: c01e6c20 T lock_wait c01e6d7c: c01e6d2c T mraccessf c01d14e6: c01d14cc t xfs_access c01b9546: c01b94c0 T xfs_ilock_ra c01b9563: c01b9550 T xfs_ilock c01d14e6: c01d14cc t xfs_access c01d14e6: c01d14cc t xfs_access c01e0a71: c01e0a54 T linvfs_permission c013d125: c013d0dc T permission c0165480: c01653d0 T nfsd_permission c0162116: c0161d4c T fh_verify c02bf5f6: c02bf084 t svc_udp_recvfrom c0121b4f: c0121b28 T nfstrace_event f896d320: c042b620 B ___strtok c0168d88: c0168c68 t nfsd3_proc_create c015fae3: c015fa10 t nfsd_dispatch c02be9e5: c02be758 T svc_process c015f8df: c015f6e8 t nfsd c0105594: c010556c T kernel_thread task: nfsd c0105ab4: c0105a48 T __down c0105c50: c0105c48 T __down_failed c02cb097: c02c76a4 T stext_lock c0168df4: c0168c68 t nfsd3_proc_create c015fae3: c015fa10 t nfsd_dispatch c02be9e5: c02be758 T svc_process c015f8df: c015f6e8 t nfsd c0105594: c010556c T kernel_thread task: nfsd c01e6ccd: c01e6c20 T lock_wait c01e6d7c: c01e6d2c T mraccessf c01d14e6: c01d14cc t xfs_access c01b9546: c01b94c0 T xfs_ilock_ra c01b9563: c01b9550 T xfs_ilock c01d14e6: c01d14cc t xfs_access c01d14e6: c01d14cc t xfs_access c01e0a71: c01e0a54 T linvfs_permission c013d125: c013d0dc T permission c0165480: c01653d0 T nfsd_permission c0162116: c0161d4c T fh_verify c02bf5f6: c02bf084 t svc_udp_recvfrom c0121b4f: c0121b28 T nfstrace_event f896d320: c042b620 B ___strtok c0168d88: c0168c68 t nfsd3_proc_create c015fae3: c015fa10 t nfsd_dispatch c02be9e5: c02be758 T svc_process c015f8df: c015f6e8 t nfsd c0105594: c010556c T kernel_thread task: nfsd c01e6ccd: c01e6c20 T lock_wait c01e6d7c: c01e6d2c T mraccessf c01d14e6: c01d14cc t xfs_access c01b9546: c01b94c0 T xfs_ilock_ra c01b9563: c01b9550 T xfs_ilock c01d14e6: c01d14cc t xfs_access c01d14e6: c01d14cc t xfs_access c01e0a71: c01e0a54 T linvfs_permission c013d125: c013d0dc T permission c0165480: c01653d0 T nfsd_permission c0162116: c0161d4c T fh_verify c02bf5f6: c02bf084 t svc_udp_recvfrom c0121b4f: c0121b28 T nfstrace_event f896d320: c042b620 B ___strtok c0168d88: c0168c68 t nfsd3_proc_create c015fae3: c015fa10 t nfsd_dispatch c02be9e5: c02be758 T svc_process c015f8df: c015f6e8 t nfsd c0105594: c010556c T kernel_thread task: nfsd c01e6ccd: c01e6c20 T lock_wait c01e6d7c: c01e6d2c T mraccessf c01d14e6: c01d14cc t xfs_access c01b9546: c01b94c0 T xfs_ilock_ra c01b9563: c01b9550 T xfs_ilock c01d14e6: c01d14cc t xfs_access c01d14e6: c01d14cc t xfs_access c01e0a71: c01e0a54 T linvfs_permission c013d125: c013d0dc T permission c0165480: c01653d0 T nfsd_permission c0162116: c0161d4c T fh_verify c02bf5f6: c02bf084 t svc_udp_recvfrom c0121b4f: c0121b28 T nfstrace_event f896d320: c042b620 B ___strtok c0168d88: c0168c68 t nfsd3_proc_create c015fae3: c015fa10 t nfsd_dispatch c02be9e5: c02be758 T svc_process c015f8df: c015f6e8 t nfsd c0105594: c010556c T kernel_thread task: nfsd c0105ab4: c0105a48 T __down c0105c50: c0105c48 T __down_failed c02cb097: c02c76a4 T stext_lock c0168df4: c0168c68 t nfsd3_proc_create c015fae3: c015fa10 t nfsd_dispatch c02be9e5: c02be758 T svc_process c015f8df: c015f6e8 t nfsd c0105594: c010556c T kernel_thread task: nfsd c01e6ccd: c01e6c20 T lock_wait c01e6d7c: c01e6d2c T mraccessf c01d14e6: c01d14cc t xfs_access c01b9546: c01b94c0 T xfs_ilock_ra c01b9563: c01b9550 T xfs_ilock c01d14e6: c01d14cc t xfs_access c01d14e6: c01d14cc t xfs_access c01e0a71: c01e0a54 T linvfs_permission c013d125: c013d0dc T permission c0165480: c01653d0 T nfsd_permission c0162116: c0161d4c T fh_verify c02bf5f6: c02bf084 t svc_udp_recvfrom c0121b4f: c0121b28 T nfstrace_event f896d320: c042b620 B ___strtok c0168d88: c0168c68 t nfsd3_proc_create c015fae3: c015fa10 t nfsd_dispatch c02be9e5: c02be758 T svc_process c015f8df: c015f6e8 t nfsd c0105594: c010556c T kernel_thread task: nfsd c01e710a: c01e702c T _sv_wait c01c1f1f: c01c1df8 t xlog_grant_log_space c01c04c9: c01c0448 T xfs_log_reserve c01cb8df: c01cb860 T xfs_trans_reserve c01d2a6b: c01d2814 t xfs_create c01e0119: c01dfff8 T linvfs_common_cr f88d02f2: c042b620 B ___strtok c01bde23: c01bde0c t xfs_setsize_fn c01cc976: c01cc954 T xfs_trans_unlocked_item c01b968b: c01b962c T xfs_iunlock c01d59a4: c01d5974 T xfs_rwunlock c0286343: c0286330 T qdisc_restart c02801ed: c02800ac T dev_queue_xmit c028427d: c02840d0 T neigh_resolve_output c028eefe: c028ee10 T ip_output c02a8a28: c02a8a28 t udp_getfrag c01cc976: c01cc954 T xfs_trans_unlocked_item c01cc976: c01cc954 T xfs_trans_unlocked_item c01e0260: c01e0248 T linvfs_create c013e22a: c013e10c T vfs_create c0164194: c0163f00 T nfsd_create_v3 c0168df4: c0168c68 t nfsd3_proc_create c015fae3: c015fa10 t nfsd_dispatch c02be9e5: c02be758 T svc_process c015f8df: c015f6e8 t nfsd c0105594: c010556c T kernel_thread task: nfsd c01e6ccd: c01e6c20 T lock_wait c01e6d7c: c01e6d2c T mraccessf c01d14e6: c01d14cc t xfs_access c01b9546: c01b94c0 T xfs_ilock_ra c01b9563: c01b9550 T xfs_ilock c01d14e6: c01d14cc t xfs_access c01d14e6: c01d14cc t xfs_access c01e0a71: c01e0a54 T linvfs_permission c013d125: c013d0dc T permission c0165480: c01653d0 T nfsd_permission c0162116: c0161d4c T fh_verify c02bf5f6: c02bf084 t svc_udp_recvfrom c0121b4f: c0121b28 T nfstrace_event f896d320: c042b620 B ___strtok c0168d88: c0168c68 t nfsd3_proc_create c015fae3: c015fa10 t nfsd_dispatch c02be9e5: c02be758 T svc_process c015f8df: c015f6e8 t nfsd c0105594: c010556c T kernel_thread task: nfsd c0105ab4: c0105a48 T __down c0105c50: c0105c48 T __down_failed c02cb079: c02c76a4 T stext_lock c0163b62: c0163b18 T nfsd_commit c0169f59: c0169e34 t nfsd3_proc_commit c015fae3: c015fa10 t nfsd_dispatch c02be9e5: c02be758 T svc_process c015f8df: c015f6e8 t nfsd c0105594: c010556c T kernel_thread task: nfsd c01e6ccd: c01e6c20 T lock_wait c01e6d7c: c01e6d2c T mraccessf c01d14e6: c01d14cc t xfs_access c01b9546: c01b94c0 T xfs_ilock_ra c01b9563: c01b9550 T xfs_ilock c01d14e6: c01d14cc t xfs_access c01d14e6: c01d14cc t xfs_access c01e0a71: c01e0a54 T linvfs_permission c013d125: c013d0dc T permission c0165480: c01653d0 T nfsd_permission c0162116: c0161d4c T fh_verify c02bf5f6: c02bf084 t svc_udp_recvfrom c0121b4f: c0121b28 T nfstrace_event f896d320: c042b620 B ___strtok c0168d88: c0168c68 t nfsd3_proc_create c015fae3: c015fa10 t nfsd_dispatch c02be9e5: c02be758 T svc_process c015f8df: c015f6e8 t nfsd c0105594: c010556c T kernel_thread task: nfsd c01e6ccd: c01e6c20 T lock_wait c01e6d7c: c01e6d2c T mraccessf c01d14e6: c01d14cc t xfs_access c01b9546: c01b94c0 T xfs_ilock_ra c01b9563: c01b9550 T xfs_ilock c01d14e6: c01d14cc t xfs_access c01d14e6: c01d14cc t xfs_access c01e0a71: c01e0a54 T linvfs_permission c013d125: c013d0dc T permission c0165480: c01653d0 T nfsd_permission c0162116: c0161d4c T fh_verify c02bf5f6: c02bf084 t svc_udp_recvfrom c0121b4f: c0121b28 T nfstrace_event f896d320: c042b620 B ___strtok c0168d88: c0168c68 t nfsd3_proc_create c015fae3: c015fa10 t nfsd_dispatch c02be9e5: c02be758 T svc_process c015f8df: c015f6e8 t nfsd c0105594: c010556c T kernel_thread task: nfsd c0105ab4: c0105a48 T __down c0105c50: c0105c48 T __down_failed c02cb097: c02c76a4 T stext_lock c0168df4: c0168c68 t nfsd3_proc_create c015fae3: c015fa10 t nfsd_dispatch c02be9e5: c02be758 T svc_process c015f8df: c015f6e8 t nfsd c0105594: c010556c T kernel_thread task: nfsd c01e6ccd: c01e6c20 T lock_wait c01e6d7c: c01e6d2c T mraccessf c01d14e6: c01d14cc t xfs_access c01b9546: c01b94c0 T xfs_ilock_ra c01b9563: c01b9550 T xfs_ilock c01d14e6: c01d14cc t xfs_access c01d14e6: c01d14cc t xfs_access c01e0a71: c01e0a54 T linvfs_permission c013d125: c013d0dc T permission c0165480: c01653d0 T nfsd_permission c0162116: c0161d4c T fh_verify c02bf5f6: c02bf084 t svc_udp_recvfrom c0121b4f: c0121b28 T nfstrace_event f896d320: c042b620 B ___strtok c0168d88: c0168c68 t nfsd3_proc_create c015fae3: c015fa10 t nfsd_dispatch c02be9e5: c02be758 T svc_process c015f8df: c015f6e8 t nfsd c0105594: c010556c T kernel_thread task: nfsd c01e6ccd: c01e6c20 T lock_wait c01e6d7c: c01e6d2c T mraccessf c01d14e6: c01d14cc t xfs_access c01b9546: c01b94c0 T xfs_ilock_ra c01b9563: c01b9550 T xfs_ilock c01d14e6: c01d14cc t xfs_access c01d14e6: c01d14cc t xfs_access c01e0a71: c01e0a54 T linvfs_permission c013d125: c013d0dc T permission c0165480: c01653d0 T nfsd_permission c0162116: c0161d4c T fh_verify c02bf5f6: c02bf084 t svc_udp_recvfrom c0121b4f: c0121b28 T nfstrace_event f896d320: c042b620 B ___strtok c0168d88: c0168c68 t nfsd3_proc_create c015fae3: c015fa10 t nfsd_dispatch c02be9e5: c02be758 T svc_process c015f8df: c015f6e8 t nfsd c0105594: c010556c T kernel_thread task: nfsd c0105ab4: c0105a48 T __down c0105c50: c0105c48 T __down_failed c02cb079: c02c76a4 T stext_lock c0163b62: c0163b18 T nfsd_commit c0169f59: c0169e34 t nfsd3_proc_commit c015fae3: c015fa10 t nfsd_dispatch c02be9e5: c02be758 T svc_process c015f8df: c015f6e8 t nfsd c0105594: c010556c T kernel_thread task: nfsd c0105ab4: c0105a48 T __down c0105c50: c0105c48 T __down_failed c02cb097: c02c76a4 T stext_lock c0168df4: c0168c68 t nfsd3_proc_create c015fae3: c015fa10 t nfsd_dispatch c02be9e5: c02be758 T svc_process c015f8df: c015f6e8 t nfsd c0105594: c010556c T kernel_thread task: nfsd c01e710a: c01e702c T _sv_wait c01c1e6d: c01c1df8 t xlog_grant_log_space c01c04c9: c01c0448 T xfs_log_reserve c01cb8df: c01cb860 T xfs_trans_reserve c01e27a1: c01e23e0 T xfs_strategy f88be460: c042b620 B ___strtok c01dc54b: c01dc384 T _pagebuf_find_lockable_buffer c019f187: c019f154 T xfs_bmbt_get_state c01972b9: c0196f6c T xfs_bmap_do_search_extents c01e0c91: c01e0c0c T linvfs_pb_bmap c01dc212: c01dc1d0 t pagebuf_delalloc_convert c01a80e5: c01a80b0 t xfs_dir2_block_lookup_int c01a4ab6: c01a4a98 t xfs_da_buf_make c01db2e0: c01db270 T pagebuf_write_full_page c01e0c0c: c01e0c0c T linvfs_pb_bmap c01a80e5: c01a80b0 t xfs_dir2_block_lookup_int c01e0e0b: c01e0dfc t linvfs_write_full_page c01e0c0c: c01e0c0c T linvfs_pb_bmap c0134e25: c0134dd0 T _write_buffer c0135ae8: c0135a34 T fsync_inode_buffers c01cc976: c01cc954 T xfs_trans_unlocked_item c01cd28b: c01cd1dc T xfs_trans_brelse c01a4db2: c01a4d24 T xfs_da_brelse c01a820f: c01a80b0 t xfs_dir2_block_lookup_int c01a800f: c01a7ff4 T xfs_dir2_block_lookup f88d02f2: c042b620 B ___strtok c0148005: c0147fb8 T iget4 c01e6121: c01e6100 T vn_put c01481b4: c014816c T iput c016160a: c0161518 t nfsd_iget c016168d: c0161624 t nfsd_get_dentry c0161a59: c0161a18 t find_fh_dentry c01da843: c01da82c T pagebuf_flush c01dd7b7: c01dd788 T fs_flush_pages c01d188e: c01d17ac t xfs_fsync c01dd1c5: c01dd184 t linvfs_fsync c0163592: c0163548 T nfsd_sync c0163b62: c0163b18 T nfsd_commit c0169f59: c0169e34 t nfsd3_proc_commit c015fae3: c015fa10 t nfsd_dispatch c02be9e5: c02be758 T svc_process c015f8df: c015f6e8 t nfsd c0105594: c010556c T kernel_thread task: nfsd c0105ab4: c0105a48 T __down c0105c50: c0105c48 T __down_failed c02cb097: c02c76a4 T stext_lock c0168df4: c0168c68 t nfsd3_proc_create c015fae3: c015fa10 t nfsd_dispatch c02be9e5: c02be758 T svc_process c015f8df: c015f6e8 t nfsd c0105594: c010556c T kernel_thread task: nfsd c0105ab4: c0105a48 T __down c0105c50: c0105c48 T __down_failed c02cb079: c02c76a4 T stext_lock c0163b62: c0163b18 T nfsd_commit c0169f59: c0169e34 t nfsd3_proc_commit c015fae3: c015fa10 t nfsd_dispatch c02be9e5: c02be758 T svc_process c015f8df: c015f6e8 t nfsd c0105594: c010556c T kernel_thread task: nfsd c01e6ccd: c01e6c20 T lock_wait c01e6d7c: c01e6d2c T mraccessf c01d14e6: c01d14cc t xfs_access c01b9546: c01b94c0 T xfs_ilock_ra c01b9563: c01b9550 T xfs_ilock c01d14e6: c01d14cc t xfs_access c01d14e6: c01d14cc t xfs_access c01e0a71: c01e0a54 T linvfs_permission c013d125: c013d0dc T permission c0165480: c01653d0 T nfsd_permission c0162116: c0161d4c T fh_verify c02bf5f6: c02bf084 t svc_udp_recvfrom c0121b4f: c0121b28 T nfstrace_event f896d320: c042b620 B ___strtok c0168d88: c0168c68 t nfsd3_proc_create c015fae3: c015fa10 t nfsd_dispatch c02be9e5: c02be758 T svc_process c015f8df: c015f6e8 t nfsd c0105594: c010556c T kernel_thread task: nfsd c0105ab4: c0105a48 T __down c0105c50: c0105c48 T __down_failed c02cb079: c02c76a4 T stext_lock c0163b62: c0163b18 T nfsd_commit c0169f59: c0169e34 t nfsd3_proc_commit c015fae3: c015fa10 t nfsd_dispatch c02be9e5: c02be758 T svc_process c015f8df: c015f6e8 t nfsd c0105594: c010556c T kernel_thread task: nfsd c01e6ccd: c01e6c20 T lock_wait c01e6d7c: c01e6d2c T mraccessf c01d14e6: c01d14cc t xfs_access c01b9546: c01b94c0 T xfs_ilock_ra c01b9563: c01b9550 T xfs_ilock c01d14e6: c01d14cc t xfs_access c01d14e6: c01d14cc t xfs_access c01e0a71: c01e0a54 T linvfs_permission c013d125: c013d0dc T permission c0165480: c01653d0 T nfsd_permission c0162116: c0161d4c T fh_verify c02bf5f6: c02bf084 t svc_udp_recvfrom c0121b4f: c0121b28 T nfstrace_event f896d320: c042b620 B ___strtok c0168d88: c0168c68 t nfsd3_proc_create c015fae3: c015fa10 t nfsd_dispatch c02be9e5: c02be758 T svc_process c015f8df: c015f6e8 t nfsd c0105594: c010556c T kernel_thread task: nfsd c0105ab4: c0105a48 T __down c0105c50: c0105c48 T __down_failed c02cb079: c02c76a4 T stext_lock c0163b62: c0163b18 T nfsd_commit c0169f59: c0169e34 t nfsd3_proc_commit c015fae3: c015fa10 t nfsd_dispatch c02be9e5: c02be758 T svc_process c015f8df: c015f6e8 t nfsd c0105594: c010556c T kernel_thread task: nfsd c01e6ccd: c01e6c20 T lock_wait c01e6d7c: c01e6d2c T mraccessf c01d14e6: c01d14cc t xfs_access c01b9546: c01b94c0 T xfs_ilock_ra c01b9563: c01b9550 T xfs_ilock c01d14e6: c01d14cc t xfs_access c01d14e6: c01d14cc t xfs_access c01e0a71: c01e0a54 T linvfs_permission c013d125: c013d0dc T permission c0165480: c01653d0 T nfsd_permission c0162116: c0161d4c T fh_verify c02bf5f6: c02bf084 t svc_udp_recvfrom c0121b4f: c0121b28 T nfstrace_event f896d320: c042b620 B ___strtok c0168d88: c0168c68 t nfsd3_proc_create c015fae3: c015fa10 t nfsd_dispatch c02be9e5: c02be758 T svc_process c015f8df: c015f6e8 t nfsd c0105594: c010556c T kernel_thread task: nfsd c01e6ccd: c01e6c20 T lock_wait c01e6d7c: c01e6d2c T mraccessf c01d14e6: c01d14cc t xfs_access c01b9546: c01b94c0 T xfs_ilock_ra c01b9563: c01b9550 T xfs_ilock c01d14e6: c01d14cc t xfs_access c01d14e6: c01d14cc t xfs_access c01e0a71: c01e0a54 T linvfs_permission c013d125: c013d0dc T permission c0165480: c01653d0 T nfsd_permission c0162116: c0161d4c T fh_verify c02bf5f6: c02bf084 t svc_udp_recvfrom c0121b4f: c0121b28 T nfstrace_event f896d320: c042b620 B ___strtok c0168d88: c0168c68 t nfsd3_proc_create c015fae3: c015fa10 t nfsd_dispatch c02be9e5: c02be758 T svc_process c015f8df: c015f6e8 t nfsd c0105594: c010556c T kernel_thread task: nfsd c01e6ccd: c01e6c20 T lock_wait c01e6d7c: c01e6d2c T mraccessf c01d14e6: c01d14cc t xfs_access c01b9546: c01b94c0 T xfs_ilock_ra c01b9563: c01b9550 T xfs_ilock c01d14e6: c01d14cc t xfs_access c01d14e6: c01d14cc t xfs_access c01e0a71: c01e0a54 T linvfs_permission c013d125: c013d0dc T permission c0165480: c01653d0 T nfsd_permission c0162116: c0161d4c T fh_verify c02bf5f6: c02bf084 t svc_udp_recvfrom c0121b4f: c0121b28 T nfstrace_event f896d320: c042b620 B ___strtok c0168d88: c0168c68 t nfsd3_proc_create c015fae3: c015fa10 t nfsd_dispatch c02be9e5: c02be758 T svc_process c015f8df: c015f6e8 t nfsd c0105594: c010556c T kernel_thread task: nfsd c0105ab4: c0105a48 T __down c0105c50: c0105c48 T __down_failed c02cb079: c02c76a4 T stext_lock c0163b62: c0163b18 T nfsd_commit c0169f59: c0169e34 t nfsd3_proc_commit c015fae3: c015fa10 t nfsd_dispatch c02be9e5: c02be758 T svc_process c015f8df: c015f6e8 t nfsd c0105594: c010556c T kernel_thread task: nfsd c0105ab4: c0105a48 T __down c0105c50: c0105c48 T __down_failed c02cb079: c02c76a4 T stext_lock c0163b62: c0163b18 T nfsd_commit c0169f59: c0169e34 t nfsd3_proc_commit c015fae3: c015fa10 t nfsd_dispatch c02be9e5: c02be758 T svc_process c015f8df: c015f6e8 t nfsd c0105594: c010556c T kernel_thread task: nfsd c0105ab4: c0105a48 T __down c0105c50: c0105c48 T __down_failed c02cb079: c02c76a4 T stext_lock c0163b62: c0163b18 T nfsd_commit c0169f59: c0169e34 t nfsd3_proc_commit c015fae3: c015fa10 t nfsd_dispatch c02be9e5: c02be758 T svc_process c015f8df: c015f6e8 t nfsd c0105594: c010556c T kernel_thread task: nfsd c0105ab4: c0105a48 T __down c0105c50: c0105c48 T __down_failed c02cb097: c02c76a4 T stext_lock c0168df4: c0168c68 t nfsd3_proc_create c015fae3: c015fa10 t nfsd_dispatch c02be9e5: c02be758 T svc_process c015f8df: c015f6e8 t nfsd c0105594: c010556c T kernel_thread task: nfsd c0105ab4: c0105a48 T __down c0105c50: c0105c48 T __down_failed c02cb097: c02c76a4 T stext_lock c0168df4: c0168c68 t nfsd3_proc_create c015fae3: c015fa10 t nfsd_dispatch c02be9e5: c02be758 T svc_process c015f8df: c015f6e8 t nfsd c0105594: c010556c T kernel_thread task: nfsd c01e6ccd: c01e6c20 T lock_wait c01e6d7c: c01e6d2c T mraccessf c01d14e6: c01d14cc t xfs_access c01b9546: c01b94c0 T xfs_ilock_ra c01b9563: c01b9550 T xfs_ilock c01d14e6: c01d14cc t xfs_access c01d14e6: c01d14cc t xfs_access c01e0a71: c01e0a54 T linvfs_permission c013d125: c013d0dc T permission c0165480: c01653d0 T nfsd_permission c0162116: c0161d4c T fh_verify c02bf5f6: c02bf084 t svc_udp_recvfrom c0121b4f: c0121b28 T nfstrace_event f896d320: c042b620 B ___strtok c0168d88: c0168c68 t nfsd3_proc_create c015fae3: c015fa10 t nfsd_dispatch c02be9e5: c02be758 T svc_process c015f8df: c015f6e8 t nfsd c0105594: c010556c T kernel_thread task: nfsd c0105ab4: c0105a48 T __down c0105c50: c0105c48 T __down_failed c02cb079: c02c76a4 T stext_lock c0163b62: c0163b18 T nfsd_commit c0169f59: c0169e34 t nfsd3_proc_commit c015fae3: c015fa10 t nfsd_dispatch c02be9e5: c02be758 T svc_process c015f8df: c015f6e8 t nfsd c0105594: c010556c T kernel_thread task: nfsd c0105ab4: c0105a48 T __down c0105c50: c0105c48 T __down_failed c02cb079: c02c76a4 T stext_lock c0163b62: c0163b18 T nfsd_commit c0169f59: c0169e34 t nfsd3_proc_commit c015fae3: c015fa10 t nfsd_dispatch c02be9e5: c02be758 T svc_process c015f8df: c015f6e8 t nfsd c0105594: c010556c T kernel_thread task: nfsd c01e6ccd: c01e6c20 T lock_wait c01e6d7c: c01e6d2c T mraccessf c01d14e6: c01d14cc t xfs_access c01b9546: c01b94c0 T xfs_ilock_ra c01b9563: c01b9550 T xfs_ilock c01d14e6: c01d14cc t xfs_access c01d14e6: c01d14cc t xfs_access c01e0a71: c01e0a54 T linvfs_permission c013d125: c013d0dc T permission c0165480: c01653d0 T nfsd_permission c0162116: c0161d4c T fh_verify c02bf5f6: c02bf084 t svc_udp_recvfrom c0121b4f: c0121b28 T nfstrace_event f896d320: c042b620 B ___strtok c0168d88: c0168c68 t nfsd3_proc_create c015fae3: c015fa10 t nfsd_dispatch c02be9e5: c02be758 T svc_process c015f8df: c015f6e8 t nfsd c0105594: c010556c T kernel_thread task: nfsd c0105ab4: c0105a48 T __down c0105c50: c0105c48 T __down_failed c02cb097: c02c76a4 T stext_lock c0168df4: c0168c68 t nfsd3_proc_create c015fae3: c015fa10 t nfsd_dispatch c02be9e5: c02be758 T svc_process c015f8df: c015f6e8 t nfsd c0105594: c010556c T kernel_thread task: nfsd c0105ab4: c0105a48 T __down c0105c50: c0105c48 T __down_failed c02cb079: c02c76a4 T stext_lock c0163b62: c0163b18 T nfsd_commit c0169f59: c0169e34 t nfsd3_proc_commit c015fae3: c015fa10 t nfsd_dispatch c02be9e5: c02be758 T svc_process c015f8df: c015f6e8 t nfsd c0105594: c010556c T kernel_thread task: nfsd c0105ab4: c0105a48 T __down c0105c50: c0105c48 T __down_failed c02cb079: c02c76a4 T stext_lock c0163b62: c0163b18 T nfsd_commit c0169f59: c0169e34 t nfsd3_proc_commit c015fae3: c015fa10 t nfsd_dispatch c02be9e5: c02be758 T svc_process c015f8df: c015f6e8 t nfsd c0105594: c010556c T kernel_thread task: nfsd c0105ab4: c0105a48 T __down c0105c50: c0105c48 T __down_failed c02cb097: c02c76a4 T stext_lock c0168df4: c0168c68 t nfsd3_proc_create c015fae3: c015fa10 t nfsd_dispatch c02be9e5: c02be758 T svc_process c015f8df: c015f6e8 t nfsd c0105594: c010556c T kernel_thread task: nfsd c0105ab4: c0105a48 T __down c0105c50: c0105c48 T __down_failed c02cb079: c02c76a4 T stext_lock c0163b62: c0163b18 T nfsd_commit c0169f59: c0169e34 t nfsd3_proc_commit c015fae3: c015fa10 t nfsd_dispatch c02be9e5: c02be758 T svc_process c015f8df: c015f6e8 t nfsd c0105594: c010556c T kernel_thread task: nfsd c01e6ccd: c01e6c20 T lock_wait c01e6d7c: c01e6d2c T mraccessf c01d14e6: c01d14cc t xfs_access c01b9546: c01b94c0 T xfs_ilock_ra c01b9563: c01b9550 T xfs_ilock c01d14e6: c01d14cc t xfs_access c01d14e6: c01d14cc t xfs_access c01e0a71: c01e0a54 T linvfs_permission c013d125: c013d0dc T permission c0165480: c01653d0 T nfsd_permission c0162116: c0161d4c T fh_verify c02bf5f6: c02bf084 t svc_udp_recvfrom c0121b4f: c0121b28 T nfstrace_event f896d320: c042b620 B ___strtok c0168d88: c0168c68 t nfsd3_proc_create c015fae3: c015fa10 t nfsd_dispatch c02be9e5: c02be758 T svc_process c015f8df: c015f6e8 t nfsd c0105594: c010556c T kernel_thread task: nfsd c0105ab4: c0105a48 T __down c0105c50: c0105c48 T __down_failed c02cb097: c02c76a4 T stext_lock c0168df4: c0168c68 t nfsd3_proc_create c015fae3: c015fa10 t nfsd_dispatch c02be9e5: c02be758 T svc_process c015f8df: c015f6e8 t nfsd c0105594: c010556c T kernel_thread task: nfsd c0105ab4: c0105a48 T __down c0105c50: c0105c48 T __down_failed c02cb097: c02c76a4 T stext_lock c0168df4: c0168c68 t nfsd3_proc_create c015fae3: c015fa10 t nfsd_dispatch c02be9e5: c02be758 T svc_process c015f8df: c015f6e8 t nfsd c0105594: c010556c T kernel_thread task: nfsd c01e6ccd: c01e6c20 T lock_wait c01e6d7c: c01e6d2c T mraccessf c01d14e6: c01d14cc t xfs_access c01b9546: c01b94c0 T xfs_ilock_ra c01b9563: c01b9550 T xfs_ilock c01d14e6: c01d14cc t xfs_access c01d14e6: c01d14cc t xfs_access c01e0a71: c01e0a54 T linvfs_permission c013d125: c013d0dc T permission c0165480: c01653d0 T nfsd_permission c0162116: c0161d4c T fh_verify c02bf5f6: c02bf084 t svc_udp_recvfrom c0121b4f: c0121b28 T nfstrace_event f896d320: c042b620 B ___strtok c0168d88: c0168c68 t nfsd3_proc_create c015fae3: c015fa10 t nfsd_dispatch c02be9e5: c02be758 T svc_process c015f8df: c015f6e8 t nfsd c0105594: c010556c T kernel_thread task: nfsd c01e6ccd: c01e6c20 T lock_wait c01e6d7c: c01e6d2c T mraccessf c01d14e6: c01d14cc t xfs_access c01b9546: c01b94c0 T xfs_ilock_ra c01b9563: c01b9550 T xfs_ilock c01d14e6: c01d14cc t xfs_access c01d14e6: c01d14cc t xfs_access c01e0a71: c01e0a54 T linvfs_permission c013d125: c013d0dc T permission c0165480: c01653d0 T nfsd_permission c0162116: c0161d4c T fh_verify c02bf5f6: c02bf084 t svc_udp_recvfrom c0121b4f: c0121b28 T nfstrace_event f896d320: c042b620 B ___strtok c0168d88: c0168c68 t nfsd3_proc_create c015fae3: c015fa10 t nfsd_dispatch c02be9e5: c02be758 T svc_process c015f8df: c015f6e8 t nfsd c0105594: c010556c T kernel_thread task: nfsd c01e6ccd: c01e6c20 T lock_wait c01e6d7c: c01e6d2c T mraccessf c01d14e6: c01d14cc t xfs_access c01b9546: c01b94c0 T xfs_ilock_ra c01b9563: c01b9550 T xfs_ilock c01d14e6: c01d14cc t xfs_access c01d14e6: c01d14cc t xfs_access c01e0a71: c01e0a54 T linvfs_permission c013d125: c013d0dc T permission c0165480: c01653d0 T nfsd_permission c0162116: c0161d4c T fh_verify c02bf5f6: c02bf084 t svc_udp_recvfrom c0121b4f: c0121b28 T nfstrace_event f896d320: c042b620 B ___strtok c0168d88: c0168c68 t nfsd3_proc_create c015fae3: c015fa10 t nfsd_dispatch c02be9e5: c02be758 T svc_process c015f8df: c015f6e8 t nfsd c0105594: c010556c T kernel_thread task: nfsd c01e6ccd: c01e6c20 T lock_wait c01e6d7c: c01e6d2c T mraccessf c01d14e6: c01d14cc t xfs_access c01b9546: c01b94c0 T xfs_ilock_ra c01b9563: c01b9550 T xfs_ilock c01d14e6: c01d14cc t xfs_access c01d14e6: c01d14cc t xfs_access c01e0a71: c01e0a54 T linvfs_permission c013d125: c013d0dc T permission c0165480: c01653d0 T nfsd_permission c0162116: c0161d4c T fh_verify c02bf5f6: c02bf084 t svc_udp_recvfrom c0121b4f: c0121b28 T nfstrace_event f896d320: c042b620 B ___strtok c0168d88: c0168c68 t nfsd3_proc_create c015fae3: c015fa10 t nfsd_dispatch c02be9e5: c02be758 T svc_process c015f8df: c015f6e8 t nfsd c0105594: c010556c T kernel_thread task: nfsd c01e6ccd: c01e6c20 T lock_wait c01e6d7c: c01e6d2c T mraccessf c01d14e6: c01d14cc t xfs_access c01b9546: c01b94c0 T xfs_ilock_ra c01b9563: c01b9550 T xfs_ilock c01d14e6: c01d14cc t xfs_access c01d14e6: c01d14cc t xfs_access c01e0a71: c01e0a54 T linvfs_permission c013d125: c013d0dc T permission c0165480: c01653d0 T nfsd_permission c0162116: c0161d4c T fh_verify c02bf5f6: c02bf084 t svc_udp_recvfrom c0121b4f: c0121b28 T nfstrace_event f896d320: c042b620 B ___strtok c0168d88: c0168c68 t nfsd3_proc_create c015fae3: c015fa10 t nfsd_dispatch c02be9e5: c02be758 T svc_process c015f8df: c015f6e8 t nfsd c0105594: c010556c T kernel_thread task: nfsd c01e6ccd: c01e6c20 T lock_wait c01e6d7c: c01e6d2c T mraccessf c01d14e6: c01d14cc t xfs_access c01b9546: c01b94c0 T xfs_ilock_ra c01b9563: c01b9550 T xfs_ilock c01d14e6: c01d14cc t xfs_access c01d14e6: c01d14cc t xfs_access c01e0a71: c01e0a54 T linvfs_permission c013d125: c013d0dc T permission c0165480: c01653d0 T nfsd_permission c0162116: c0161d4c T fh_verify c02bf5f6: c02bf084 t svc_udp_recvfrom c0121b4f: c0121b28 T nfstrace_event f896d320: c042b620 B ___strtok c0168d88: c0168c68 t nfsd3_proc_create c015fae3: c015fa10 t nfsd_dispatch c02be9e5: c02be758 T svc_process c015f8df: c015f6e8 t nfsd c0105594: c010556c T kernel_thread task: nfsd c01e6ccd: c01e6c20 T lock_wait c01e6d7c: c01e6d2c T mraccessf c01d14e6: c01d14cc t xfs_access c01b9546: c01b94c0 T xfs_ilock_ra c01b9563: c01b9550 T xfs_ilock c01d14e6: c01d14cc t xfs_access c01d14e6: c01d14cc t xfs_access c01e0a71: c01e0a54 T linvfs_permission c013d125: c013d0dc T permission c0165480: c01653d0 T nfsd_permission c0162116: c0161d4c T fh_verify c02bf5f6: c02bf084 t svc_udp_recvfrom c0121b4f: c0121b28 T nfstrace_event f896d320: c042b620 B ___strtok c0168d88: c0168c68 t nfsd3_proc_create c015fae3: c015fa10 t nfsd_dispatch c02be9e5: c02be758 T svc_process c015f8df: c015f6e8 t nfsd c0105594: c010556c T kernel_thread task: nfsd c0105ab4: c0105a48 T __down c0105c50: c0105c48 T __down_failed c02cb079: c02c76a4 T stext_lock c0163b62: c0163b18 T nfsd_commit c0169f59: c0169e34 t nfsd3_proc_commit c015fae3: c015fa10 t nfsd_dispatch c02be9e5: c02be758 T svc_process c015f8df: c015f6e8 t nfsd c0105594: c010556c T kernel_thread task: nfsd c0105ab4: c0105a48 T __down c0105c50: c0105c48 T __down_failed c02cb097: c02c76a4 T stext_lock c0168df4: c0168c68 t nfsd3_proc_create c015fae3: c015fa10 t nfsd_dispatch c02be9e5: c02be758 T svc_process c015f8df: c015f6e8 t nfsd c0105594: c010556c T kernel_thread task: nfsd c01e6ccd: c01e6c20 T lock_wait c01e6d7c: c01e6d2c T mraccessf c01d14e6: c01d14cc t xfs_access c01b9546: c01b94c0 T xfs_ilock_ra c01b9563: c01b9550 T xfs_ilock c01d14e6: c01d14cc t xfs_access c01d14e6: c01d14cc t xfs_access c01e0a71: c01e0a54 T linvfs_permission c013d125: c013d0dc T permission c0165480: c01653d0 T nfsd_permission c0162116: c0161d4c T fh_verify c02bf5f6: c02bf084 t svc_udp_recvfrom c0121b4f: c0121b28 T nfstrace_event f896d320: c042b620 B ___strtok c0168d88: c0168c68 t nfsd3_proc_create c015fae3: c015fa10 t nfsd_dispatch c02be9e5: c02be758 T svc_process c015f8df: c015f6e8 t nfsd c0105594: c010556c T kernel_thread task: nfsd c01e6ccd: c01e6c20 T lock_wait c01e6d7c: c01e6d2c T mraccessf c01d14e6: c01d14cc t xfs_access c01b9546: c01b94c0 T xfs_ilock_ra c01b9563: c01b9550 T xfs_ilock c01d14e6: c01d14cc t xfs_access c01d14e6: c01d14cc t xfs_access c01e0a71: c01e0a54 T linvfs_permission c013d125: c013d0dc T permission c0165480: c01653d0 T nfsd_permission c0162116: c0161d4c T fh_verify c02bf5f6: c02bf084 t svc_udp_recvfrom c0121b4f: c0121b28 T nfstrace_event f896d320: c042b620 B ___strtok c0168d88: c0168c68 t nfsd3_proc_create c015fae3: c015fa10 t nfsd_dispatch c02be9e5: c02be758 T svc_process c015f8df: c015f6e8 t nfsd c0105594: c010556c T kernel_thread task: nfsd c0105ab4: c0105a48 T __down c0105c50: c0105c48 T __down_failed c02cb097: c02c76a4 T stext_lock c0168df4: c0168c68 t nfsd3_proc_create c015fae3: c015fa10 t nfsd_dispatch c02be9e5: c02be758 T svc_process c015f8df: c015f6e8 t nfsd c0105594: c010556c T kernel_thread task: nfsd c0105ab4: c0105a48 T __down c0105c50: c0105c48 T __down_failed c02cb079: c02c76a4 T stext_lock c0163b62: c0163b18 T nfsd_commit c0169f59: c0169e34 t nfsd3_proc_commit c015fae3: c015fa10 t nfsd_dispatch c02be9e5: c02be758 T svc_process c015f8df: c015f6e8 t nfsd c0105594: c010556c T kernel_thread task: nfsd c01e6ccd: c01e6c20 T lock_wait c01e6d7c: c01e6d2c T mraccessf c01d14e6: c01d14cc t xfs_access c01b9546: c01b94c0 T xfs_ilock_ra c01b9563: c01b9550 T xfs_ilock c01d14e6: c01d14cc t xfs_access c01d14e6: c01d14cc t xfs_access c01e0a71: c01e0a54 T linvfs_permission c013d125: c013d0dc T permission c0165480: c01653d0 T nfsd_permission c0162116: c0161d4c T fh_verify c02bf5f6: c02bf084 t svc_udp_recvfrom c0121b4f: c0121b28 T nfstrace_event f896d320: c042b620 B ___strtok c0168d88: c0168c68 t nfsd3_proc_create c015fae3: c015fa10 t nfsd_dispatch c02be9e5: c02be758 T svc_process c015f8df: c015f6e8 t nfsd c0105594: c010556c T kernel_thread task: nfsd c0105ab4: c0105a48 T __down c0105c50: c0105c48 T __down_failed c02cb097: c02c76a4 T stext_lock c0168df4: c0168c68 t nfsd3_proc_create c015fae3: c015fa10 t nfsd_dispatch c02be9e5: c02be758 T svc_process c015f8df: c015f6e8 t nfsd c0105594: c010556c T kernel_thread task: nfsd c0105ab4: c0105a48 T __down c0105c50: c0105c48 T __down_failed c02cb097: c02c76a4 T stext_lock c0168df4: c0168c68 t nfsd3_proc_create c015fae3: c015fa10 t nfsd_dispatch c02be9e5: c02be758 T svc_process c015f8df: c015f6e8 t nfsd c0105594: c010556c T kernel_thread task: nfsd c0105ab4: c0105a48 T __down c0105c50: c0105c48 T __down_failed c02cb079: c02c76a4 T stext_lock c0163b62: c0163b18 T nfsd_commit c0169f59: c0169e34 t nfsd3_proc_commit c015fae3: c015fa10 t nfsd_dispatch c02be9e5: c02be758 T svc_process c015f8df: c015f6e8 t nfsd c0105594: c010556c T kernel_thread task: nfsd c01e6ccd: c01e6c20 T lock_wait c01e6d7c: c01e6d2c T mraccessf c01d14e6: c01d14cc t xfs_access c01b9546: c01b94c0 T xfs_ilock_ra c01b9563: c01b9550 T xfs_ilock c01d14e6: c01d14cc t xfs_access c01d14e6: c01d14cc t xfs_access c01e0a71: c01e0a54 T linvfs_permission c013d125: c013d0dc T permission c0165480: c01653d0 T nfsd_permission c0162116: c0161d4c T fh_verify c02bf5f6: c02bf084 t svc_udp_recvfrom c0121b4f: c0121b28 T nfstrace_event f896d320: c042b620 B ___strtok c0168d88: c0168c68 t nfsd3_proc_create c015fae3: c015fa10 t nfsd_dispatch c02be9e5: c02be758 T svc_process c015f8df: c015f6e8 t nfsd c0105594: c010556c T kernel_thread task: sh c02720f7: c0271f48 t vgacon_cursor c0112f27: c0112f10 T schedule_timeout c020887e: c02084d0 t read_chan c020472a: c0204658 t tty_read c0133f97: c0133f08 T sys_read c0106d6f: c0106d3c T system_call task: getty c0112f27: c0112f10 T schedule_timeout c0208de4: c0208c24 t write_chan c020887e: c02084d0 t read_chan c020472a: c0204658 t tty_read c0133f97: c0133f08 T sys_read c0106d6f: c0106d3c T system_call task: getty c0112f27: c0112f10 T schedule_timeout c0208de4: c0208c24 t write_chan c020887e: c02084d0 t read_chan c020472a: c0204658 t tty_read c0133f97: c0133f08 T sys_read c0106d6f: c0106d3c T system_call task: HostAgent c01193e5: c0119048 T sys_wait4 c0106d6f: c0106d3c T system_call task: diald c0145a69: c0145a50 T dput c0112f8a: c0112f10 T schedule_timeout c0112eb0: c0112eb0 t process_timeout c011da9c: c011d98c T sys_nanosleep c0106d6f: c0106d3c T system_call task: guiServer.sh c01193e5: c0119048 T sys_wait4 c0106d6f: c0106d3c T system_call task: sh c01193e5: c0119048 T sys_wait4 c0106d6f: c0106d3c T system_call task: java c0105ef3: c0105df8 T sys_rt_sigsuspend c0106d6f: c0106d3c T system_call task: java c011d4f4: c011d4d4 T update_process_times c0105ef3: c0105df8 T sys_rt_sigsuspend c0106d6f: c0106d3c T system_call task: java c013c8d2: c013c8ac t pipe_poll c0112f8a: c0112f10 T schedule_timeout c0112eb0: c0112eb0 t process_timeout c0142b7f: c0142ac4 t do_poll c0142d7d: c0142ba0 T sys_poll c0119410: c0119048 T sys_wait4 c0106d6f: c0106d3c T system_call task: java c0112f8a: c0112f10 T schedule_timeout c0112eb0: c0112eb0 t process_timeout c011da9c: c011d98c T sys_nanosleep c0106d6f: c0106d3c T system_call task: java c013c8d2: c013c8ac t pipe_poll c0112f8a: c0112f10 T schedule_timeout c0112eb0: c0112eb0 t process_timeout c0142b7f: c0142ac4 t do_poll c0142d7d: c0142ba0 T sys_poll c0106d6f: c0106d3c T system_call task: java c0112f8a: c0112f10 T schedule_timeout c0112eb0: c0112eb0 t process_timeout c011da9c: c011d98c T sys_nanosleep c0106d6f: c0106d3c T system_call task: java c0105ef3: c0105df8 T sys_rt_sigsuspend c0106d6f: c0106d3c T system_call task: java c0105ef3: c0105df8 T sys_rt_sigsuspend c0106d6f: c0106d3c T system_call task: java c0105ef3: c0105df8 T sys_rt_sigsuspend c0106d6f: c0106d3c T system_call task: java c0105ef3: c0105df8 T sys_rt_sigsuspend c0106d6f: c0106d3c T system_call task: java c0112f8a: c0112f10 T schedule_timeout c0112eb0: c0112eb0 t process_timeout c011da9c: c011d98c T sys_nanosleep c0106d6f: c0106d3c T system_call task: java c0105ef3: c0105df8 T sys_rt_sigsuspend c0106d6f: c0106d3c T system_call task: java c0105ef3: c0105df8 T sys_rt_sigsuspend c0106d6f: c0106d3c T system_call task: java c0112f8a: c0112f10 T schedule_timeout c0112eb0: c0112eb0 t process_timeout c011da9c: c011d98c T sys_nanosleep c0106d6f: c0106d3c T system_call task: java c0105ef3: c0105df8 T sys_rt_sigsuspend c0106d6f: c0106d3c T system_call task: java c0105ef3: c0105df8 T sys_rt_sigsuspend c0106d6f: c0106d3c T system_call task: java c0105ef3: c0105df8 T sys_rt_sigsuspend c0106d6f: c0106d3c T system_call task: java c0105ef3: c0105df8 T sys_rt_sigsuspend c0106d6f: c0106d3c T system_call task: java c0105ef3: c0105df8 T sys_rt_sigsuspend c0106d6f: c0106d3c T system_call task: java c027cf97: c027ceb8 T __kfree_skb c0112f8a: c0112f10 T schedule_timeout c0112eb0: c0112eb0 t process_timeout c011da9c: c011d98c T sys_nanosleep c0106d6f: c0106d3c T system_call task: java c0105ef3: c0105df8 T sys_rt_sigsuspend c0106d6f: c0106d3c T system_call task: java c0105ef3: c0105df8 T sys_rt_sigsuspend c0106d6f: c0106d3c T system_call task: java c0145a69: c0145a50 T dput c0112f8a: c0112f10 T schedule_timeout c0112eb0: c0112eb0 t process_timeout c011da9c: c011d98c T sys_nanosleep c0106d6f: c0106d3c T system_call task: java c0112f8a: c0112f10 T schedule_timeout c0112eb0: c0112eb0 t process_timeout c011da9c: c011d98c T sys_nanosleep c0106d6f: c0106d3c T system_call task: java c0105ef3: c0105df8 T sys_rt_sigsuspend c0106d6f: c0106d3c T system_call task: java c0145a69: c0145a50 T dput c0112f8a: c0112f10 T schedule_timeout c0112eb0: c0112eb0 t process_timeout c011da9c: c011d98c T sys_nanosleep c0106d6f: c0106d3c T system_call task: java c0112f27: c0112f10 T schedule_timeout c029660a: c02964f8 t wait_for_connect c0296789: c02966cc T tcp_accept c02aeea4: c02aee78 T inet_accept c027a996: c027a930 T sys_accept c011e6ac: c011e5b0 t kill_something_info c011ef05: c011eeb8 T sys_kill c0106147: c0106030 t restore_sigcontext c027b3ec: c027b338 T sys_socketcall c0106e60: c0106e2c t error_code c0106d6f: c0106d3c T system_call task: java c0105ef3: c0105df8 T sys_rt_sigsuspend c0106d6f: c0106d3c T system_call task: java c0112f8a: c0112f10 T schedule_timeout c0112eb0: c0112eb0 t process_timeout c011da9c: c011d98c T sys_nanosleep c0106d6f: c0106d3c T system_call task: java c0112f27: c0112f10 T schedule_timeout c029660a: c02964f8 t wait_for_connect c0296789: c02966cc T tcp_accept c02aeea4: c02aee78 T inet_accept c027a996: c027a930 T sys_accept c011e6ac: c011e5b0 t kill_something_info c011ef05: c011eeb8 T sys_kill c0112f90: c0112f10 T schedule_timeout c027b3ec: c027b338 T sys_socketcall c0106d6f: c0106d3c T system_call task: java c0105ef3: c0105df8 T sys_rt_sigsuspend c0106d6f: c0106d3c T system_call task: java c0105ef3: c0105df8 T sys_rt_sigsuspend c0106d6f: c0106d3c T system_call task: java c0112f8a: c0112f10 T schedule_timeout c0112eb0: c0112eb0 t process_timeout c011da9c: c011d98c T sys_nanosleep c0106d6f: c0106d3c T system_call task: java c0105ef3: c0105df8 T sys_rt_sigsuspend c0106d6f: c0106d3c T system_call task: java c0134c7e: c0134bb8 T fput c0105ef3: c0105df8 T sys_rt_sigsuspend c0106d6f: c0106d3c T system_call task: java c0112f8a: c0112f10 T schedule_timeout c0112eb0: c0112eb0 t process_timeout c011da9c: c011d98c T sys_nanosleep c0106d6f: c0106d3c T system_call task: java c0112f8a: c0112f10 T schedule_timeout c0112eb0: c0112eb0 t process_timeout c011da9c: c011d98c T sys_nanosleep c0106d6f: c0106d3c T system_call task: java c0105ef3: c0105df8 T sys_rt_sigsuspend c0106d6f: c0106d3c T system_call task: java c011a28f: c011a220 T do_softirq c0112f27: c0112f10 T schedule_timeout c027e9a2: c027e8d0 t wait_for_packet c027eadc: c027ea10 T skb_recv_datagram c02a9045: c02a8ff0 T udp_recvmsg c02af0e5: c02af0a8 T inet_recvmsg c0279e11: c0279dd4 T sock_recvmsg c027ad65: c027acb8 T sys_recvfrom c011ef05: c011eeb8 T sys_kill c027b4bb: c027b338 T sys_socketcall c0106d6f: c0106d3c T system_call task: java c0105ef3: c0105df8 T sys_rt_sigsuspend c0106d6f: c0106d3c T system_call task: java c0105ef3: c0105df8 T sys_rt_sigsuspend c0106d6f: c0106d3c T system_call task: java c0105ef3: c0105df8 T sys_rt_sigsuspend c0106d6f: c0106d3c T system_call task: java c0112f8a: c0112f10 T schedule_timeout c0112eb0: c0112eb0 t process_timeout c011da9c: c011d98c T sys_nanosleep c0106d6f: c0106d3c T system_call task: java c0112f8a: c0112f10 T schedule_timeout c0112eb0: c0112eb0 t process_timeout c011da9c: c011d98c T sys_nanosleep c0106d6f: c0106d3c T system_call task: java c0112f8a: c0112f10 T schedule_timeout c0112eb0: c0112eb0 t process_timeout c011da9c: c011d98c T sys_nanosleep c0106d6f: c0106d3c T system_call task: java c0112f8a: c0112f10 T schedule_timeout c0112eb0: c0112eb0 t process_timeout c011da9c: c011d98c T sys_nanosleep c0106d6f: c0106d3c T system_call task: java c0105ef3: c0105df8 T sys_rt_sigsuspend c0106d6f: c0106d3c T system_call task: java c0112f27: c0112f10 T schedule_timeout c027e9a2: c027e8d0 t wait_for_packet c027eadc: c027ea10 T skb_recv_datagram c02a9045: c02a8ff0 T udp_recvmsg c02af0e5: c02af0a8 T inet_recvmsg c0279e11: c0279dd4 T sock_recvmsg c027ad65: c027acb8 T sys_recvfrom c011e6ac: c011e5b0 t kill_something_info c011ef05: c011eeb8 T sys_kill c0279bb9: c0279ba8 T sockfd_lookup c027ae2e: c027ade4 T sys_setsockopt c027b4bb: c027b338 T sys_socketcall c0106d6f: c0106d3c T system_call task: java c0105ef3: c0105df8 T sys_rt_sigsuspend c0106d6f: c0106d3c T system_call task: java c0105ef3: c0105df8 T sys_rt_sigsuspend c0106d6f: c0106d3c T system_call task: java c0105ef3: c0105df8 T sys_rt_sigsuspend c0106d6f: c0106d3c T system_call task: java c0112f27: c0112f10 T schedule_timeout c027e9a2: c027e8d0 t wait_for_packet c027eadc: c027ea10 T skb_recv_datagram c02a9045: c02a8ff0 T udp_recvmsg c02af0e5: c02af0a8 T inet_recvmsg c0279e11: c0279dd4 T sock_recvmsg c027ad65: c027acb8 T sys_recvfrom c011e6ac: c011e5b0 t kill_something_info c011ef05: c011eeb8 T sys_kill c027b4bb: c027b338 T sys_socketcall c0106d6f: c0106d3c T system_call task: java c0112f8a: c0112f10 T schedule_timeout c0112eb0: c0112eb0 t process_timeout c011da9c: c011d98c T sys_nanosleep c0106d6f: c0106d3c T system_call task: java c0112f8a: c0112f10 T schedule_timeout c0112eb0: c0112eb0 t process_timeout c011da9c: c011d98c T sys_nanosleep c0106d6f: c0106d3c T system_call task: java c0112f8a: c0112f10 T schedule_timeout c0112eb0: c0112eb0 t process_timeout c011da9c: c011d98c T sys_nanosleep c0106d6f: c0106d3c T system_call task: java c0105ef3: c0105df8 T sys_rt_sigsuspend c0106d6f: c0106d3c T system_call task: java c0105ef3: c0105df8 T sys_rt_sigsuspend c0106d6f: c0106d3c T system_call task: nfstraced c0112f8a: c0112f10 T schedule_timeout c0112eb0: c0112eb0 t process_timeout c011da9c: c011d98c T sys_nanosleep c0106d6f: c0106d3c T system_call task: in.telnetd c0112f27: c0112f10 T schedule_timeout c014255e: c0142394 T do_select c0142900: c01425c0 T sys_select c0106d6f: c0106d3c T system_call ------_=_NextPart_000_01C1AAA8.0BA847D0-- From owner-linux-xfs@oss.sgi.com Thu Jan 31 16:17:11 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g110HBx14431 for linux-xfs-outgoing; Thu, 31 Jan 2002 16:17:11 -0800 Received: from deliverator.sgi.com (deliverator.sgi.com [204.94.214.10]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g110H7d14407 for ; Thu, 31 Jan 2002 16:17:07 -0800 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via SMTP id PAA09310 for ; Thu, 31 Jan 2002 15:12:40 -0800 (PST) mail_from (nathans@wobbly.melbourne.sgi.com) Received: from wobbly.melbourne.sgi.com (wobbly.melbourne.sgi.com [134.14.55.135]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id KAA25638; Fri, 1 Feb 2002 10:15:46 +1100 Received: (from nathans@localhost) by wobbly.melbourne.sgi.com (SGI-8.9.3/8.9.3) id KAA84390; Fri, 1 Feb 2002 10:15:46 +1100 (AEDT) Date: Fri, 1 Feb 2002 10:15:45 +1100 From: Nathan Scott To: "D. Stimits" Cc: "XFS: linux-xfs@oss.sgi.com" Subject: Re: [NEWS] Extended attributes interface changes Message-ID: <20020201101545.G88469@wobbly.melbourne.sgi.com> References: <20020201095217.F88469@wobbly.melbourne.sgi.com> <3C59CE74.E5D20B9D@idcomm.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <3C59CE74.E5D20B9D@idcomm.com>; from stimits@idcomm.com on Thu, Jan 31, 2002 at 04:08:36PM -0700 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 729 Lines: 20 On Thu, Jan 31, 2002 at 04:08:36PM -0700, D. Stimits wrote: > Nathan Scott wrote: > > > > >From an end-user point of view, we will need to make a transition > > from using our current system call interfaces for EAs and ACLs to > > the new interfaces. This affects both the kernel and a number of > > the userspace tools and libraries. We've considered attempting to > > Do I read this correctly, it appears that only tools and kernels change, > current XFS filesystems themselves will remain unchanged for this > purpose, and fully compatible with newer tools and kernels? Yes, the ondisk formats remain unchanged, incl. the ondisk ACL format (which is also the same as the IRIX/XFS Posix ACL format). cheers. -- Nathan From owner-linux-xfs@oss.sgi.com Thu Jan 31 16:22:09 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g110M9x14603 for linux-xfs-outgoing; Thu, 31 Jan 2002 16:22:09 -0800 Received: from smtpzilla5.xs4all.nl (smtpzilla5.xs4all.nl [194.109.127.141]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g110M6d14580 for ; Thu, 31 Jan 2002 16:22:06 -0800 Received: from auto-nb1.xs4all.nl (qn-212-58-167-191.quicknet.nl [212.58.167.191]) by smtpzilla5.xs4all.nl (8.12.0/8.12.0) with ESMTP id g0VNM0rX011624; Fri, 1 Feb 2002 00:22:00 +0100 (CET) Message-Id: <4.3.2.7.2.20020201001908.02cb9f48@pop.xs4all.nl> X-Sender: knuffie@pop.xs4all.nl X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 01 Feb 2002 00:20:27 +0100 To: stimits@idcomm.com, "XFS: linux-xfs@oss.sgi.com" From: Seth Mos Subject: Re: [NEWS] Extended attributes interface changes In-Reply-To: <3C59CE74.E5D20B9D@idcomm.com> References: <20020201095217.F88469@wobbly.melbourne.sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 548 Lines: 18 At 16:08 31-1-2002 -0700, D. Stimits wrote: >Do I read this correctly, it appears that only tools and kernels change, >current XFS filesystems themselves will remain unchanged for this >purpose, and fully compatible with newer tools and kernels? The on-disk format will not change. Doing so would break Irix compatibility. I don't think it will ever change, if it does it won't be called XFS but perhaps XFSv2 :-) Cheers -- Seth Every program has two purposes one for which it was written and another for which it wasn't I use the last kind. From owner-linux-xfs@oss.sgi.com Thu Jan 31 18:20:36 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g112Kak19427 for linux-xfs-outgoing; Thu, 31 Jan 2002 18:20:36 -0800 Received: from water.cc.mcgill.ca (water.CC.McGill.CA [132.206.27.29]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g112KWd19403 for ; Thu, 31 Jan 2002 18:20:33 -0800 Received: from comotion (comotion@[132.216.181.67]) by water.cc.mcgill.ca (8.12.1/8.11.0) with ESMTP id g111KGRG007492 for ; Thu, 31 Jan 2002 20:20:26 -0500 (EST) Date: Thu, 31 Jan 2002 20:22:37 -0500 From: King Kac To: linux-xfs@oss.sgi.com Subject: undelete - xfsrecover'ing deleted files in xfs Message-ID: <20020131202237.A966@comotion> Mime-Version: 1.0 Content-Type: text/plain; format=flowed; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Mailer: Balsa 1.2.3 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 430 Lines: 13 So I'm trying to recover some deleted files on my xfs-formatted hw raid array mounted on /home I read off of this newsgroup that xfsrestore was the tool to use. Here's what I'm trying to do: xfsdump -s comotion -J - /home | xfsrestore - /mnt/restore/ This obviously only copies the files already there, and does not recover unlinked files. So... what is the method to recover unlined files then?? cheers, Kacper Wysocki From owner-linux-xfs@oss.sgi.com Thu Jan 31 18:25:38 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g112Pcl19616 for linux-xfs-outgoing; Thu, 31 Jan 2002 18:25:38 -0800 Received: from pneumatic-tube.sgi.com (pneumatic-tube.sgi.com [204.94.214.22]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g112PYd19594 for ; Thu, 31 Jan 2002 18:25:34 -0800 Received: from relay1.corp.sgi.com (spindle.corp.sgi.com [198.29.75.13]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id RAA02455 for ; Thu, 31 Jan 2002 17:26:35 -0800 (PST) mail_from (sandeen@sgi.com) Received: from chuckle.americas.sgi.com (sandeen@chuckle.americas.sgi.com [128.162.211.44]) by relay1.corp.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) via ESMTP id RAA10445; Thu, 31 Jan 2002 17:25:00 -0800 (PST) Date: Thu, 31 Jan 2002 19:24:59 -0600 (CST) From: Eric Sandeen X-X-Sender: To: King Kac cc: Subject: Re: undelete - xfsrecover'ing deleted files in xfs In-Reply-To: <20020131202237.A966@comotion> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 697 Lines: 24 Sorry, xfsrestore is only good if you've previously xfsdumped. If you deleted a file, the data may still be there on disk (as with any other filesystem) but there's no automated way to recover it. -Eric On Thu, 31 Jan 2002, King Kac wrote: > So I'm trying to recover some deleted files on my xfs-formatted > hw raid array mounted on /home > I read off of this newsgroup that xfsrestore was the tool to use. > Here's what I'm trying to do: > > xfsdump -s comotion -J - /home | xfsrestore - /mnt/restore/ > > This obviously only copies the files already there, and does not > recover unlinked files. > So... what is the method to recover unlined files then?? > > cheers, > Kacper Wysocki > From owner-linux-xfs@oss.sgi.com Thu Jan 31 18:32:02 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g112W2Z19800 for linux-xfs-outgoing; Thu, 31 Jan 2002 18:32:02 -0800 Received: from methyl.vcp.monash.edu.au (methyl.vcp.monash.edu.au [130.194.217.45]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g112Vtd19778 for ; Thu, 31 Jan 2002 18:31:56 -0800 Received: from localhost (david@localhost) by methyl.vcp.monash.edu.au (SGI-8.9.3/8.9.3) with ESMTP id MAA30716; Fri, 1 Feb 2002 12:41:09 +1100 (EDT) X-Authentication-Warning: methyl.vcp.monash.edu.au: david owned process doing -bs Date: Fri, 1 Feb 2002 12:41:09 +1100 From: David Chalmers X-Sender: To: Eric Sandeen cc: David Chalmers , Subject: Re: Kernel panic during reboot (recovery) In-Reply-To: <1012493211.20484.6.camel@stout.americas.sgi.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 1558 Lines: 47 Hi again, Thanks to Eric Sandeen for his reply. I found that by mounting the disk in another machine and using xfs_repair (without the -L option) I was able to repair the disk. On Thu, 31 Jan 2002, Eric Sandeen wrote: > On Thu, 2002-01-31 at 00:46, David Chalmers wrote: > > Hi > > > > After some trouble with a machine running Redhat 7.1 with SGI-XFS-1.01 > > we get the following message. Is all lost? Can I recover this? > > > XFS: log mount/recovery failed > > Hi David - > > I don't recall offhand what type of recovery changes have been made > since 1.0.1... that was quite a while ago. You might try a more recent > kernel*, and see if recovery goes better. As a last resort, you could > use a rescue disk and a recent xfs_repair with the "-L" option to zero > the log - of course you will lose anything in the log, which could cause > file/data loss. > > Let's see if anyone else has better suggestions before you try that > drastic step... > > -Eric > > *booting the 1.0.2 installer in "rescue" mode will get you a 2.4.7 > kernel, for example. > > -- > Eric Sandeen XFS for Linux http://oss.sgi.com/projects/xfs > sandeen@sgi.com SGI, Inc. > > _____________________________________________________________________________ David Chalmers Lab: 9903 9110 Victorian College of Pharmacy Fax: 9903 9582 381 Royal Pde, Parkville, Vic 3053 http://synapse.vcp.monash.edu.au Australia David.Chalmers@vcp.monash.edu.au _____________________________________________________________________________ From owner-linux-xfs@oss.sgi.com Thu Jan 31 18:50:25 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g112oPV20227 for linux-xfs-outgoing; Thu, 31 Jan 2002 18:50:25 -0800 Received: from HOLYBOY.SYMMSYS.COM (usr436@[216.51.91.226]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g112oHd20203 for ; Thu, 31 Jan 2002 18:50:19 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Subject: XFS SB Validate error content-class: urn:content-classes:message X-MimeOLE: Produced By Microsoft Exchange V6.0.4712.0 Date: Thu, 31 Jan 2002 20:45:12 -0500 Message-ID: <29800F5ABF5EAC42998190CFF1846AA303C8C6@symlab0-srvr1.SYMMETRY.SYMMSYS.COM> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: XFS SB Validate error Thread-Index: AcGqws1ujEB3MSdWTKWU9PlTq70SBg== From: "Yom, Francis" To: Cc: , Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id g112oJd20204 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 1713 Lines: 40 Hi all, I am using Debian Woody on 2.4.17 that has the following patches: ACPI 20011218 Preempt-Kernel - Robert Love RMAP VM - rik van riel - RMAP12a XFS patch for 2.4.17 The machine is a Compaq Presario Laptop with 1 Gb of RAM and 48 GB Harddrive with 1.2 P3 processor. I run VMWare Workstation 3.0 with WinXP and Win2k Guest Os'es. I have been very happy with XFS and had no problems with it so far. I have been using this kernel for 2 weeks now, but have been working with XFS since 2.4.14. Today, while working in my XP VMWare session, I got an error saying that VMWare could not contact the disk drive. I went to an X console and checked my syslog and discovered that my /home partition (3,9) was unmounted my XFS because of a bad superblock. I had the dreaded SB Validate problem as stated in the FAQ. I ended up doing an xfs_repair after rebooting in single user mode. I could not get the log to replay so I ended up doing another xfs_repair with the -L switch which made me very nervous. Fortunately, my partition was fixed and I lost no data. Whew! I think I was lucky. I am posting this to see if anyone might know what could have caused this and if my kernel's config could have been a culprit. I only wish I had more information like log info from the xfs_repair to post, but I don't :-( The only thing I was doing at the time was reading Outlook mail from within the XP VMWare session. If this happens again, I will be sure to document this very carefully to present next time. I am just wondering if this scenario rings any bells. FWIW, I have found XFS to be extremely reliable. It has saved my ass a number of times when I have had to do cold reboots. Many thanks, Francis From owner-linux-xfs@oss.sgi.com Thu Jan 31 19:09:41 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1139f120675 for linux-xfs-outgoing; Thu, 31 Jan 2002 19:09:41 -0800 Received: from sgi.com (sgi-too.SGI.COM [204.94.211.39]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1139Wd20651 for ; Thu, 31 Jan 2002 19:09:32 -0800 Received: from water.cc.mcgill.ca (water.CC.McGill.CA [132.206.27.29]) by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id SAA06945 for ; Thu, 31 Jan 2002 18:09:24 -0800 (PST) mail_from (kacperw@online.no) Received: from comotion (comotion@[132.216.181.67]) by water.cc.mcgill.ca (8.12.1/8.11.0) with ESMTP id g11213RG010706 for ; Thu, 31 Jan 2002 21:01:06 -0500 (EST) Date: Thu, 31 Jan 2002 21:03:25 -0500 From: King Kac To: linux-xfs@oss.sgi.com Subject: Re: undelete - xfsrecover'ing deleted files in xfs Message-ID: <20020131210325.C966@comotion> References: <20020131202237.A966@comotion> 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 Thu, Jan 31, 2002 at 20:24:59 -0500 X-Mailer: Balsa 1.2.3 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 879 Lines: 32 That's what I was afraid of. What's the hard way of recovering it then? -Kacper On 2002.01.31 20:24 Eric Sandeen wrote: > Sorry, xfsrestore is only good if you've previously xfsdumped. > > If you deleted a file, the data may still be there on disk (as with > any > other filesystem) but there's no automated way to recover it. > > -Eric > > On Thu, 31 Jan 2002, King Kac wrote: > > > So I'm trying to recover some deleted files on my > xfs-formatted > > hw raid array mounted on /home > > I read off of this newsgroup that xfsrestore was the tool to use. > > Here's what I'm trying to do: > > > > xfsdump -s comotion -J - /home | xfsrestore - /mnt/restore/ > > > > This obviously only copies the files already there, and does not > > recover unlinked files. > > So... what is the method to recover unlined files then?? > > > > cheers, > > Kacper Wysocki > > > > > From owner-linux-xfs@oss.sgi.com Thu Jan 31 19:19:30 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g113JUq21006 for linux-xfs-outgoing; Thu, 31 Jan 2002 19:19:30 -0800 Received: from clubphoto.com (mail-gw.clubphoto.com [64.124.34.66]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g113JPd20983 for ; Thu, 31 Jan 2002 19:19:25 -0800 Received: from [192.168.168.136] ([192.168.168.136]) by clubphoto.com (8.9.3/8.9.3) with ESMTP id SAA02020; Thu, 31 Jan 2002 18:19:16 -0800 User-Agent: Microsoft-Entourage/10.0.0.1309 Date: Thu, 31 Jan 2002 18:19:28 -0800 Subject: Re: undelete - xfsrecover'ing deleted files in xfs From: "Gabe E. Nydick" To: King Kac , Message-ID: In-Reply-To: <20020131210325.C966@comotion> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 1057 Lines: 40 Pay about 10K anywhere up, depending on the size of the drive to have it professionally done. On 1/31/02 6:03 PM, "King Kac" wrote: > That's what I was afraid of. What's the hard way of recovering it then? > -Kacper > > On 2002.01.31 20:24 Eric Sandeen wrote: >> Sorry, xfsrestore is only good if you've previously xfsdumped. >> >> If you deleted a file, the data may still be there on disk (as with >> any >> other filesystem) but there's no automated way to recover it. >> >> -Eric >> >> On Thu, 31 Jan 2002, King Kac wrote: >> >>> So I'm trying to recover some deleted files on my >> xfs-formatted >>> hw raid array mounted on /home >>> I read off of this newsgroup that xfsrestore was the tool to use. >>> Here's what I'm trying to do: >>> >>> xfsdump -s comotion -J - /home | xfsrestore - /mnt/restore/ >>> >>> This obviously only copies the files already there, and does not >>> recover unlinked files. >>> So... what is the method to recover unlined files then?? >>> >>> cheers, >>> Kacper Wysocki >>> >> >> >> From owner-linux-xfs@oss.sgi.com Thu Jan 31 19:38:36 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g113caA21370 for linux-xfs-outgoing; Thu, 31 Jan 2002 19:38:36 -0800 Received: from sgi.com (sgi-too.SGI.COM [204.94.211.39]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g113cWd21347 for ; Thu, 31 Jan 2002 19:38:32 -0800 Received: from relay1.corp.sgi.com (corp.sgi.com [198.29.75.13]) by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id SAA04586 for ; Thu, 31 Jan 2002 18:38:29 -0800 (PST) mail_from (sandeen@sgi.com) Received: from chuckle.americas.sgi.com (sandeen@chuckle.americas.sgi.com [128.162.211.44]) by relay1.corp.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) via ESMTP id SAA81373; Thu, 31 Jan 2002 18:37:55 -0800 (PST) Date: Thu, 31 Jan 2002 20:37:54 -0600 (CST) From: Eric Sandeen X-X-Sender: To: "Yom, Francis" cc: , , Subject: Re: XFS SB Validate error In-Reply-To: <29800F5ABF5EAC42998190CFF1846AA303C8C6@symlab0-srvr1.SYMMETRY.SYMMSYS.COM> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 614 Lines: 14 On Thu, 31 Jan 2002, Yom, Francis wrote: > I have been very happy with XFS and had no problems with it so far. I > have been using this kernel for 2 weeks now, but have been working with > XFS since 2.4.14. Today, while working in my XP VMWare session, I got > an error saying that VMWare could not contact the disk drive. I went to > an X console and checked my syslog and discovered that my /home > partition (3,9) was unmounted my XFS because of a bad superblock. I had > the dreaded SB Validate problem as stated in the FAQ. Were there any messages in the log about a forced filesystem shutdown? -Eric From owner-linux-xfs@oss.sgi.com Thu Jan 31 20:11:29 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g114BTs22049 for linux-xfs-outgoing; Thu, 31 Jan 2002 20:11:29 -0800 Received: from deliverator.sgi.com (deliverator.sgi.com [204.94.214.10]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g114BPd22027 for ; Thu, 31 Jan 2002 20:11:25 -0800 Received: from relay1.corp.sgi.com (spindle.corp.sgi.com [198.29.75.13]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id TAA27935 for ; Thu, 31 Jan 2002 19:06:58 -0800 (PST) mail_from (sandeen@sgi.com) Received: from chuckle.americas.sgi.com (sandeen@chuckle.americas.sgi.com [128.162.211.44]) by relay1.corp.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) via ESMTP id TAA84289; Thu, 31 Jan 2002 19:10:50 -0800 (PST) Date: Thu, 31 Jan 2002 21:10:49 -0600 (CST) From: Eric Sandeen X-X-Sender: To: "Yom, Francis" cc: , , Subject: RE: XFS SB Validate error In-Reply-To: <29800F5ABF5EAC42998190CFF1846AA303C8C7@symlab0-srvr1.SYMMETRY.SYMMSYS.COM> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 657 Lines: 18 Ok, a couple things... There have been several changes in 2.4.17 - can you look at the bottom of pagebuf_write_full_page() in page_buf_io.c? About 8 lines from the bottom of the function, does it say block_flush_page(page,0), or _unmark_delalloc(page)? If it's the latter, then it was probably the forced shutdown that caused the corruption, although I'm not sure what's causing the shutdown. Are you doing anything fun with this filesystem? Using LVM snapshots, playing with xfs_freeze, realtime subvolumes? :) -Eric On Thu, 31 Jan 2002, Yom, Francis wrote: > Jan 31 17:21:09 sera kernel: EFSCORRUPTED returned from file > xfs_ialloc.c line 1265