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